{"url":"https://docs.arbitrum.io/","domain":"docs.arbitrum.io","title":"Get started with Arbitrum | Arbitrum Docs","text":"✏️Request an updateArbitrum is the finance-native platform providing infrastructure for applications, tokenization, and dedicated chains. These docs explain the protocols, chains, services, and SDKs developers use to build on the Arbitrum platform.\nIn the programmable economy, markets, transactions, and business processes run in software. Arbitrum provides the infrastructure for those systems to execute with configurable rules and Ethereum settlement.\nIf you're ready to start building, try the Solidity\nquickstart or Stylus quickstart.\nUnderstand Arbitrum​\nLearn how Arbitrum scales Ethereum.\nArbitrum introductionA FAQ-style overview of Arbitrum's finance-native platform.Inside NitroA technical deep dive into Nitro's architecture.Inside AnyTrustA technical deep dive into the AnyTrust protocol.Nitro whitepaperThe original whitepaper that introduced Nitro.DAO governanceDocs for members of the Arbitrum DAO.\nBuild decentralized apps​\nDeploy smart contracts to Arbitrum One, Arbitrum Nova, or any Arbitrum chain.\nQuickstart (Solidity)Deploy your first Solidity smart contract to Arbitrum using Remix.Quickstart (Rust)Deploy your first Rust smart contract using Arbitrum Stylus.Explore StylusWrite EVM-compatible smart contracts in Rust, C, and other languages that compile to Wasm.Chain infoChain IDs, RPC endpoints, and network parameters.\nLaunch your own chain​\nLaunch a dedicated chain using the Arbitrum platform. Configure execution, gas tokens, data availability, governance, and validation for your product's requirements.\nA gentle introductionUnderstand Arbitrum chains' value proposition and use cases.Deploy a chainUse the Arbitrum chain SDK to configure and deploy your chain's core contracts.Configure your chainSet up throughput, gas tokens, data availability, governance, and more.Migrate from another stackMove an existing chain to Arbitrum technology.\nRun a node​\nRun the machines that power the Arbitrum ecosystem.\nRun a full nodeAccess Arbitrum chains without connecting to a third-party node.Run an archive nodeAccess extensive historical data for advanced analytical purposes.Run a feed relayDistribute the sequencer feed across multiple nodes.Configure a DACRun a Data Availability Server for AnyTrust chains.\nBridge tokens​\nMove ETH and ERC-20 tokens between Ethereum and Arbitrum chains.\nQuickstart (bridge)Step-by-step instructions for first-time bridge users.Arbitrum bridgeTransfer tokens between Ethereum, Arbitrum One, Arbitrum Nova, and other Arbitrum chains.Arbitrum PortalDiscover dApps deployed on Arbitrum.Understand ArbitrumBuild decentralized appsLaunch your own chainRun a nodeBridge tokens","tokens":658,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257216887,"hash":"39b9b6379ecbc99bec966d0257817be8f0129ae2"}
{"url":"https://aave.com/docs","domain":"aave.com","title":"Aave Protocol Overview","text":"Aave Documentation#\nAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.\nThese docs cover the protocol end to end: concepts and risk parameters, the AaveKit SDKs (React, TypeScript, GraphQL), smart contract references for v3 and v4, GHO, governance, and integration guides. Every page is also available as markdown for agents and tooling: append .md to any URL, or send an Accept: text/markdown header.\nGet Familiar with Aave#\nAave 101Learn the basics.Aave v3Learn about the Aave v3.Aave v4Learn about Aave v4.Aave HorizonBorrow stablecoins with RWAs.GHOLearn about the GHO stablecoin.\nSafety#\nUmbrellaNative coverage for bad debt.SecuritySecurity resources and audits.\nIntegrate Aave#\nMarketsEarn by supplying assets.VaultsEarn interest on assets.\nQuickstart#\nMarket DataSupply PositionsBorrow PositionsSupplyimport { useAaveMarkets, chainId } from \"@aave/react\";\nconst { data, loading, error } = useAaveMarkets({ chainIds: [chainId(1), chainId(8453)], // Ethereum, Base});\n\nReactTypeScriptGraphQL\nQuick Links#\nAddressesProtocol smart addresses.ParametersView market parameters.\nBuilding On AaveNextAave 101","tokens":332,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257217894,"hash":"66f9cc69f1ea95e86caafe51ab9efd3f4ccb38a4"}
{"url":"https://docs.io.net/","domain":"docs.io.net","title":"Overview - io.net","text":"​What Is io.Net?\nio.net has built an enterprise-grade decentralized computing network that allows machine learning engineers to access distributed cloud clusters at a small fraction of the cost of comparable centralized services.\nWe believe that compute is this generation’s “digital oil,” powering a never before seen technological industrial revolution. Our vision is to build IO to be the currency of compute, powering an ecosystem of products and services that enable access to compute as a resource and as an asset.\nModern machine learning models frequently leverage parallel and distributed computing. It is crucial to harness the power of multiple cores across several systems to optimize performance or scale to larger datasets and models. Training and inference processes are not just simple tasks running on a single device but often involve a coordinated network of GPUs that work in synergy.\nHowever traditional cloud service providers have 2.5x less capacity than the estimated demand in the market from AI/ML companies, making access to distributed computing resources presents several challenges. Some of the most prominent are:\n\nLimited Availability: It can often take weeks to get access to hardware using cloud services like AWS, GCP or Azure, and popular GPU models are often unavailable.\nPoor Choice: Users have little choice regarding GPU hardware, location, security level, latency and other options.\nHigh Costs: Getting good GPUs is extremely expensive, and projects can easily spend hundreds of thousands of dollars monthly on training and inferencing.\n\nio.net solves this problem by aggregating GPUs from underutilized sources such as independent data centers, crypto miners, and other hardware networks like Filecoin, Render and others. These resources are combined within a Decentralized Physical Infrastructure Network (DePIN), giving engineers access to massive amounts of on-demand computing power in a system that is accessible, customizable, cost-efficient and easy to implement.\nWith io.net, teams can scale their workloads across a network of GPUs with minimal adjustments. The system handles orchestration, scheduling, fault tolerance, and scaling and supports a variety of tasks such as preprocessing, distributed training, hyperparameter tuning, reinforcement learning, and model serving. It is designed to serve general-purpose computation for Python workloads, with an emphasis on serving AI/ML workloads.\n​io.net offering is purpose-built for four core functions:\n\nBatch Inference and Model Serving: Performing inference on incoming batches of data can be parallelized by exporting the architecture and weights of a trained model to the shared object-store. io.net allows machine learning teams to build out inference and model-serving workflows across a distributed network of GPUs.\nParallel Training: CPU/GPU memory limitations and sequential processing workflows present a massive bottleneck when training models on a single device. io.net leverages distributed computing libraries to orchestrate and batch-train jobs such that they can be parallelized across many distributed devices using data and model parallelism.\nParallel hyperparameter tuning: Hyperparameter tuning experiments are inherently parallel, and io.net leverages distributed computing libraries with advanced Hyperparam tuning for checkpointing the best result, optimizing scheduling, and specifying search patterns simply.\nReinforcement learning: io.net uses an open-source reinforcement learning library, which supports production-level, highly distributed RL workloads alongside a simple set of APIs.\n\nIt all started at the Solana Hackathon, Feb 2023 and the Solana Austin Hacker House.\nWas this page helpful?","tokens":931,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257220194,"hash":"ba9869a0a3179c09dae865224094a5a2b4c366fa"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/overview/introduction","domain":"docs.arbitrum.io","title":"Overview of Arbitrum chains | Arbitrum Docs","text":"✏️Request an update\nArbitrum chains give you flexibility and control without the constraint of running your own Layer 1 blockchain. Instead of bootstrapping and subsidizing your own validator set, your chain anchors its security and finality to Ethereum, turning security into a variable, usage-based expense.\nThat economic model is the core reason to choose Arbitrum: your business captures the fee revenue and priority-access value that L1s hand off to validators, because costs scale with usage (gas targets) rather than set (fixed) fees. You also control the economics directly—custom gas tokens, fee policy, and revenue capture—while getting institution-grade settlement: sub-second soft finality for a responsive user experience, configurable hard finality on Ethereum in minutes, and native withdrawals in as little as 15 minutes, backed by a clean, externally legible counterparty-risk story for your risk, audit, and compliance stakeholders.\nBeyond economics, an Arbitrum chain lets you launch fast and customize deeply. You get day-one configuration over high, fully tunable throughput and block times (as low as 100ms), data availability (Rollup, AnyTrust, or external DA), sequencing and MEV rules, KYC/AML and permissioning, privacy, precompiles, governance, and multi-prover settlement—and you automatically inherit every future Ethereum and Arbitrum upgrade, including Stylus, without custom engineering.\nCritically, your chain isn't siloed: it plugs directly into Ethereum's deep liquidity and the broader Arbitrum ecosystem. And you can de-risk your go-to-market with a phased \"launch-and-migrate\" path—prove your product on the shared, liquid Arbitrum One, then graduate to your own dedicated Arbitrum chain as a seamless continuation on the same stack, not a costly replatforming.\n\nCustomization​\nSpeed and finality​\nSet confirmation speed and settlement behavior for products where timing and certainty matter—payments, trading, treasury, and internal asset movement.\nTune block time​\n\nYour benefit\n\nYou own the speed-versus-cost tradeoff. Faster blocks let you position the chain as a premium, low-latency venue (trading, gaming, payments) without waiting on a third party to change infrastructure.\n\nUser benefit\n\nNear-instant confirmations make the app feel like a familiar web experience rather than a slow onchain one, reducing the “did my transaction go through?” hesitation.\n\nGuides\n\nConfigure chain finality\nSequencer timing adjustments\n\nConfigure deposit finality​\n\nYour benefit\n\nYou match certainty guarantees to your actual risk profile to avoid paying for stronger finality than your product needs. Adjust the time before the chain processes a deposit.\n\nUser benefit\n\nPredictable, well-defined settlement means users know exactly when funds and actions are final—important for anyone moving real value.\n\nGuide\n\nConfigure chain finality\n\nEnable fast withdrawals to reduce withdrawal finality time​\n\nYour benefit\n\nFewer support tickets and complaints about locked-up capital, and a more competitive bridging story when users compare your chain to alternatives.\n\nUser benefit\n\nUsers get their funds in minutes instead of waiting the full challenge window, dramatically lowering the friction of exiting the chain.\n\nGuide\n\nFast withdrawals\n\nNoteThe 100ms figure is an optional lower bound on block time, not the default. Most chains run at the 250ms default; 100ms is available when you opt into it. By default, fast withdrawals is not enabled—the default withdrawal time is 6.4 days.\nTransaction pricing model​\nAlign costs with your business model, including the option to use a custom gas token that fits customer experience, treasury strategy, or internal accounting needs.\nUse a custom ERC-20 as the native gas token​\n\nYour benefit\n\nYou can drive utility to your own token, align fee revenue with your treasury strategy, and simplify internal accounting by denominating gas in the unit you already track.\n\nUser benefit\n\nUsers pay fees in a familiar or branded token rather than acquiring a separate asset, removing a common onboarding hurdle.\n\nGuides\n\nCustom gas token (Rollup)\nCustom gas token (AnyTrust)\n\nManage the fee parameters that govern what users pay and fee distribution​\n\nYour benefit\n\nDirect control over cost recovery and revenue, so you can tune the chain's economics to be self-sustaining or subsidized as your business model requires.\n\nUser benefit\n\nTransparent, deliberately set fees rather than opaque or volatile costs, which builds trust in the pricing.\n\nGuide\n\nFee management\n\nConfigure native mint/burn behavior for the gas token​\n\nYour benefit\n\nYou can use a cross-chain-native token (such as a stablecoin) as your gas token, so it moves in and out of your chain through canonical interop protocols instead of lock-and-mint wrappers—keeping your treasury and accounting denominated in the real asset.\n\nUser benefit\n\nUsers hold and pay fees in the canonical token rather than a wrapped derivative, so their gas balance stays fungible and redeemable across chains.\n\nGuide\n\nNative mint and burn\n\nDynamic pricing​\n\nYour benefit\n\nYou smooth out pricing (gas fee) volatility by setting multiple gas targets that react to short-term spikes and long-term load separately, so brief demand bursts don't turn into severe, sustained gas-price spikes.\n\nUser benefit\n\nMore stable, predictable fees during periods of high demand instead of sudden, sharp cost increases exactly when the chain is busiest.\n\nGuide\n\nDynamic pricing\n\nThroughput and latency​\nHandle higher volumes and faster response times for products that cannot degrade during periods of peak demand.\nDedicated throughput​\n\nYour benefit\n\nGuaranteed capacity means you can make performance commitments (effectively an SLA) to partners and customers without worrying about noisy-neighbor contention for computation and storage resources.\n\nUser benefit\n\nConsistent performance during peak events—launches, drops, market volatility—instead of degraded speed exactly when demand is highest.\n\nGuide\n\nManage gas target\n\nSet the gas target to match your expected load​\n\nYour benefit\n\nYou provision capacity to match your expected transaction volume—scaling up for high-throughput workloads or holding it lean to manage operating costs—so throughput planning becomes a controllable lever rather than a fixed constraint you inherit.\n\nUser benefit\n\nCapacity provisioned to real demand means orders and settlements continue to clear promptly even during peak volume, rather than facing delays or failed transactions when the network is congested.\n\nGuides\n\nGas target guidance\nGas optimization\n\nPrivacy and access controls​\nCreate participation rules and data access controls that align with regulated workflows and protect sensitive information.\nRun permissioned validators​\nVet and restrict who participates in validation—useful for enterprise or regulated environments (for example, KYC for validators).\n\nYour benefit\n\nYou can meet regulatory and legal requirements, reduce compliance risk, and make the chain viable for enterprise and institutional partners who can't operate on a fully open infrastructure.\n\nUser benefit\n\nAssurance that the chain operates within a vetted, accountable set of participants–a prerequisite for many regulated financial and enterprise products.\n\nGuide\n\nValidation and BoLD\n\nRestrict who can read chain data​\nKeep data off the public Layer 1 with an AnyTrust data availability committee.\n\nYour benefit\n\nYou keep sensitive business and user data out of a fully public ledger, satisfying privacy obligations and protecting competitive information.\n\nUser benefit\n\nGreater confidentiality around their activity and data than a fully public chain would offer.\n\nGuide\n\nConfigure data availability\n\nMove to permissionless validation later​\n\nYour benefit\n\nYou can launch with tight control and decentralize on your own timeline—no re-platforming required as your product and risk tolerance mature.\n\nUser benefit\n\nA credible path to stronger trustlessness and censorship resistance over time, rather than being locked into a permissioned model forever.\n\nGuide\n\nValidation and BoLD\n\nNoteThese controls apply at the validator and data-availability layers—who validates the chain and who can read its data. They are not a per-user transaction allowlist; screening which end users may submit transactions is an application-layer concern, not a chain-config setting.\nTransaction sequencing​\nCustomize transaction ordering to match your product, whether the priority is wider access, lower MEV exposure, or tighter handling of transaction flow.\nKeep the default FCFS ordering​\nFor intuitive, simple first-come, first-serve (FCFS) ordering that the world's largest exchanges use for trading.\n\nYour benefit\n\nFair, simple ordering keeps fast block times and avoids the reputational cost of a chain seen as hostile to ordinary users.\n\nUser benefit\n\nBuilt-in protection from front-running and sandwich attacks, so users aren't quietly taxed by MEV extractors on every trade.\n\nGuide\n\nHow the Sequencer works\n\nTimeboost​\nEnable Timeboost to auction an express lane, letting the chain owner capture MEV while preserving fair ordering for everyone else.\n\nYour benefit\n\nYou capture MEV as a revenue stream for the chain rather than leaking it to external searchers.\n\nUser benefit\n\nNon-express transactions keep their fair-ordering protections, while users who genuinely need priority have a transparent way to pay for it.\n\nGuide\n\nTimeboost configuration\n\nGovernance and data availability​\nChoose how the chain is upgraded, administered, and backed by data availability based on the balance of cost, transparency, and resilience you need.\nChain-owner role and access controls​\nGovern upgrades and administration, and plan a path toward progressive decentralization.\n\nYour benefit\n\nYou retain the control needed for upgrades and incident response early on, then deliberately decentralize as the chain matures—balancing agility with credibility.\n\nUser benefit\n\nClear accountability for who can change the chain, plus a visible path toward stronger, more decentralized guarantees.\n\nGuide\n\nOwnership and access control\n\nData availability model​\nChoose your data availability model—Rollup, AnyTrust, or Alt-DA—to trade off cost against transparency and resilience.\n\nYour benefit\n\nYou dial the cost-versus-security balance directly; AnyTrust can cut data costs substantially, while Rollup maximizes security and transparency.\n\nUser benefit\n\nLower fees when you choose AnyTrust, or maximum security and Ethereum-grade transparency when you choose Rollup\n\nGuide\n\nConfigure data availability\n\nPerformance​\nOn an Arbitrum chain, performance isn’t a single parameter—it’s the combined result of a few independent levers. Each trades one property against another (speed vs. infrastructure load, throughput vs. node stability, settlement speed vs. security), and you tune them to fit your product’s risk tolerance and demand profile. There are four primary parameters to configure, and language support capability is automatically included (no configuration needed).\nFinality and settlement​\nHow quickly transactions become final and withdrawable. Set the delayed inbox finality, the challenge period, and fast withdrawals to balance settlement speed against reorg and security risk.\nDelayed inbox, fast withdrawals, challenge period​\n\nYour benefit\n\nDelayed inbox finality, challenge period, and fast withdrawals—to balance settlement speed against reorg and security risk for your risk, audit, and compliance stakeholders.\n\nUser benefit\n\nFaster, more predictable settlement: sub-second soft finality for responsiveness and quicker withdrawals back to the parent chain.\n\nGuides\n\nDelayed inbox\nFast withdrawals\nChallenge period\n\nCost and fee stability​\nHow predictable prices stay under load. Use Dynamic Pricing, fee management (base/surplus minimums), a gas price floor, and batch-poster fee tuning to smooth spikes and capture revenue.\nDynamic pricing, fee management, gas price floor, batch poster fee tuning​\n\nYour benefit\n\nShape fee economics directly — Dynamic Pricing (multiple gas targets), base/surplus fee minimums, a gas price floor, and batch-poster fee tuning — to smooth price spikes and capture revenue while costs scale with usage.\n\nUser benefit\n\nMore stable, predictable transaction costs under load, avoiding sudden fee spikes during large payout runs or volatile periods.\n\nGuides\n\nDynamic pricing\nFee management\nGas optimization\nBatch poster fee tuning\n\nLanguage support​\nStylus is inherited by every Arbitrum chain. It lets you develop smart contracts in languages your team may already know, instead of learning Solidity. Out of the box, it lets you write performant contracts in Rust, C, and C++ (plus community-tier AssemblyScript) alongside Solidity, reusing mature libraries while keeping full EVM compatibility.\n\nStylus gentle intro\nDeploy non-Rust WASM contracts\n\nCompliance​\nSanctioned-address screening at the protocol level​\n\nProtocol-level transaction filtering added to the Sequencer and State Transition Function (STF), at the chain owner's discretion.\nYour benefit​\n\nEnables filtering as a first-class protocol capability to opt into, rather than building and maintaining bespoke tooling, while retaining full discretion over whether to enable it.\nCan reuse an existing provider relationship and risk methodology rather than build screening in-house.\nCan tailor enforcement granularity to policy—addresses, events, or both.\nA ready-made menu of enforcement actions covering transfers, tokens, and opcodes.\nThe restricted set remains up to date without manual redeployment.\n\nUser benefit​\n\nTransactions are screened by the network itself, so protection doesn’t depend on any single app behaving correctly.\nScreening reflects industry-standard sanctions data rather than ad hoc lists.\nOnly the activity that the policy actually targets is blocked, reducing false positives.\nClearly scoped restrictions keep permitted activity available.\nNewly sanctioned addresses are enforced promptly, improving protection.\n\nGuide​\n\nCompliance filtering\n\nContinuous monitoring (synchronization pipeline)​\nCLI flags​\n\nYour benefit\n\nCan tune update frequency and storage to their operational needs.\n\nUser benefit\n\nTimely list updates mean less exposure to recently restricted addresses.\n\nGuide\n\nCLI flags reference\n\nWhat problem do Arbitrum chains solve?​\nArbitrum chains are dedicated chains built with Arbitrum technology. Teams can configure execution, fee models, governance, data availability, validation, and other chain parameters for their application or business requirements.\nThe Ethereum ecosystem is supported by a decentralized network of nodes that each run Ethereum's Layer 1 (L1) client software. Ethereum's block space is in high demand, so users are often stuck waiting for the network to become less congested (and thus, less expensive).\nArbitrum's protocols address this challenge by offloading some of the Ethereum network's heavy lifting to another decentralized network of nodes that support the Arbitrum stack (Arbitrum chains).\nHow do Arbitrum chains help the Ethereum ecosystem?​\nArbitrum helps Ethereum move towards a multi-chain future. This is valuable for the following reasons:\n\nValue: Scalability\n\nMultiple chains help overcome scaling bottlenecks by dividing activity into opt-in environments with separate resource management.\n\nValue: Flexible security models\n\nDifferent chains can experiment with different security models, allowing for tradeoffs. For example: Arbitrum One and Arbitrum Nova are both L2 chains, with Arbitrum Nova giving developers the ability to optimize for lower fees. With Arbitrum chains, extending the technology and experimenting is easier than ever.\n\nValue: Flexible execution environments\n\nDifferent chains can experiment with more-or-less restrictive execution environments. For example, although Arbitrum chains are fully EVM compatible, Arbitrum chains can restrict smart contract functionality to optimize for your project's needs.\n\nValue: Flexible governance\n\nArbitrum chains let you define your own governance protocols.\n\nAre Arbitrum chains the same thing as \"app chains\"?​\nIt depends on your definition of \"app chain\". Arbitrum chains can be used as application-specific chains (often referred to as \"app chains\" or \"appchains\"). But they aren't just for apps. They're for hosting EVM-compatible smart contracts using self-managed infrastructure that isolates compute resources away from Arbitrum's public L2 chains based on your unique needs.\n\nYou can use your Arbitrum chain to host the smart contracts that support one decentralized app, two apps, an ecosystem of apps, or no apps at all.\nEthereum-grade security and interoperability, so your assets, users, and builders flow to/from Ethereum seamlessly and safely.\nYou can use your Arbitrum chain to host a private, centralized service.\nYour Arbitrum chain can be special-purpose, general-purpose, and everything in-between.\nCustomize/tune your chain to your specific use case however you want.\nYou could even build an app that uses multiple Arbitrum chains to support strange new forms of redundancy, high availability, and trustlessness.\nCustomizationSpeed and finalityTransaction pricing modelThroughput and latencyPrivacy and access controlsTransaction sequencingGovernance and data availabilityPerformanceFinality and settlementCost and fee stabilityLanguage supportComplianceSanctioned-address screening at the protocol levelContinuous monitoring (synchronization pipeline)What problem do Arbitrum chains solve?How do Arbitrum chains help the Ethereum ecosystem?Are Arbitrum chains the same thing as \"app chains\"?","tokens":4410,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257227468,"hash":"b980bde250e5c86a8cdf7cb1a790a7da4a5dadab"}
{"url":"https://aave.com/docs/vaults/simple-earn/overview","domain":"aave.com","title":"Simple Earn Vaults | Aave Protocol Documentation","text":"Simple Earn Vaults#\n\nAave Simple Earn Vaults are ERC-4626 compliant yield-bearing vaults that allow users to supply and withdraw ERC-20 tokens supported by Aave v3. Vaults manage the supply and withdrawal of assets in the Aave Protocol while enabling vault managers to take a fee on the yield earned.\nTo deploy a vault, follow the deployment guide.\nAave ERC-4626 Vaults#\nOverview#\nAave Simple Earn Vaults follow the ERC-4626 Tokenized Vault Standard, which standardizes the interface for yield-bearing vaults. This standard simplifies integration with various applications and aggregators while improving interoperability across the DeFi ecosystem.\nEach vault allows depositors to:\nDeposit supported tokens (assets) and receive vault shares in returnRedeem vault shares for the underlying assets plus accrued yieldAutomatically earn yield from Aave v3 markets without direct interaction with the protocol\nArchitecture#\nAave Simple Earn Vaults consist of three key components:\nERC-4626 Interface: Standardized methods for deposit, withdrawal, and accounting of assets.Yield Strategy: Manages deposits into Aave v3 markets and handles yield accrual.Fee Management: Enables vault managers to collect a percentage of the yield generated.\nWhen a user deposits an asset into a vault:\nThe vault mints proportional vault shares (ERC-20 tokens) to the userThe vault deposits the underlying assets into the corresponding Aave v3 marketThe vault receives aTokens from Aave, which automatically accrue yieldYield is reflected in the increasing value of vault shares over time\nFee Structure#\nVaults deployed via Aave Labs' API or SDK can set the performance fee as low\nas 0%. When a performance fee is set, 50% of that fee is automatically\nallocated to Aave Labs.\nVault managers can set a fee percentage on the yield generated by the vault. This fee structure includes:\nPerformance Fee: A percentage of the yield earned that goes to the vault managerMax Fee: A maximum limit on the performance fee that can be chargedFee Recipients: The addresses that receive the collected fees\nFees are collected when yield is realized through:\nUser withdrawals or redemptionsExplicit fee collection by the vault manager\nThe fee is only applied to the yield portion of the assets and not to the principal amount deposited by users.\nInteracting with Vaults#\nVaults implement the standard ERC-4626 interface with methods such as:\ndeposit(uint256 assets, address receiver): Deposit assets and receive vault shareswithdraw(uint256 assets, address receiver, address owner): Withdraw assets by burning vault sharesmint(uint256 shares, address receiver): Mint exact amount of shares by depositing assetsredeem(uint256 shares, address receiver, address owner): Redeem shares for underlying assets\nAdditionally, vaults provide view functions to check:\ntotalAssets(): Total assets managed by the vaultconvertToShares(uint256 assets): Convert asset amount to vault sharesconvertToAssets(uint256 shares): Convert vault shares to asset amountpreviewDeposit(uint256 assets): Preview shares received for a depositpreviewWithdraw(uint256 assets): Preview shares needed for a withdrawal\nFor a detailed contract reference, see the contracts documentation.\nBenefits for Users#\nSimplified Yield: Earn yield from Aave v3 without managing multiple transactionsGas Efficiency: Lower gas costs compared to direct protocol interactionsStandard Interface: Easier integration with other DeFi protocols and applicationsComposability: Vault shares can be used in other DeFi applications\nBenefits for Vault Managers#\nYield Capture: Earn fees on yield generated by user depositsCustomization: Configure fee parameters to suit different strategiesStandardization: Leverage the ERC-4626 standard for broader integrationPreviousAave 101NextDeploy Earn Vault","tokens":949,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257228028,"hash":"2663e5c61c07b192e6e1d61a1b63869691c2c4a1"}
{"url":"https://io.net/docs/guides/inception","domain":"io.net","title":"Company Origins - io.net","text":"Prior to June 2022, io.net was exclusively devoted to the development of institutional-grade quantitative trading systems for both the United States stock market and the cryptocurrency market. Our primary challenge was constructing the infrastructure necessary to accommodate our complex needs, which included a robust backend trading system with significant computational power.\nOur trading strategies, bordering on high-frequency trading (HFT), necessitated real-time monitoring of the tick data of over 1,000 stocks and 150 cryptocurrencies. HFT is a method of trading that uses powerful computer programs to transact a large number of orders in fractions of a second. It uses complex algorithms to analyze multiple markets and execute orders based on market conditions. Furthermore, our system had to dynamically backtest and adjust algorithm parameters for each asset in real-time, while also being optimized to facilitate trading for more than 30,000 individual clients across ETrade.com, Alpaca.markets, and Binance.com, maintaining a latency below 200 milliseconds from market events to system reaction on client account for order execution.\nAchieving such an infrastructure would typically require a dedicated team of MLOps and DevOps professionals. However, our discovery of Ray.io, an open-source library used by OpenAI to distribute GPT-3/4 training across over 300,000 CPUs and GPUs ( source ) revolutionized our approach and streamlined our infrastructure management. and increased our speed to build this backend from +6 months to less than 60 days .\nAfter integrating Ray into our backend and preparing to deploy the application on a cluster of GPU & CPU workers to handle our substantial compute power, we faced the wall of price for running such system due to overpriced GPU on-demand cloud providers.\nFor instance, an NVIDIA A100 card was priced at over $80 USD/day per card. We needed more than 50 of these cards to run on average 25 days/month, amounting to $80 x 50 card x 25 day = 100K USD/month.\nThis posed a serious challenge for us as also for other self-funded startups in the AI/ML industry.\nEven with such high prices, compute requirements for AI apps have been doubling every 3 months, 10x every 18 months.\nDistributed applications have been around for over five decades, starting with the emergence of computer networks like ARPANET. Over the years, developers have utilized distributed systems to scale applications and services, including large-scale simulations, web serving, and big data processing.\nNonetheless, distributed applications have generally been the exception rather than the rule. Even today, most undergraduate students complete only a handful of projects involving distributed applications, if any. This landscape is quickly changing as distributed applications are on track to become the norm. Two primary trends drive this transformation: the end of Moore’s Law and the skyrocketing computational demands of new machine learning applications. Consequently, a rapidly widening gap between application demands and single-node performance is leaving us no choice but to distribute these applications.\n​Moore’s Law is Dead\nFor the past 40 years, Moore’s Law has driven the unprecedented growth of the computer industry. According to this law, processor performance doubles every 18 months. However, performance growth has slowed to a meagre 10-20% over the same period. Although Moore’s Law may have ended, the demand for increased computing power has increased. In response, computer architects have shifted their focus to developing domain-specific processors that prioritize performance over generality.\n​Domain-Specific Hardware is Not Enough\nAs the name suggests, domain-specific processors are optimized for specific workloads, sacrificing generality for performance. Deep learning is a prime example of such a workload, revolutionizing various application domains, including financial services, industrial control, medical diagnosis, manufacturing, system optimization, etc.\nCompanies have raced to create specialized processors, like Nvidia’s GPUs and Google’s TPUs, to support deep learning workloads. While accelerators such as GPUs and TPUs increase computational power, they only extend Moore’s Law further into the future, rather than fundamentally increasing the rate of improvement.\nThe Triple Whammy of Deep Learning Application Demand: Machine learning applications’ demands are growing at an astonishing pace. Here are three key workloads as examples:\n​Training\nAccording to a renowned OpenAI blog post, the computation required to achieve state-of-the-art machine learning results has roughly doubled every 3.4 months since 2012. This equates to an increase of almost 40x every 18 months, which is 20x more than Moore’s Law! Thus, even without the end of Moore’s Law, it would fall significantly short of meeting the demands of these applications.\nThis explosive growth isn’t exclusive to niche machine-learning applications like AlphaGo. Similar trends are evident in mainstream applications like computer vision and natural language processing. For example, comparing the computational resources required by the seq2seq model from 2014 to a pretraining approach on tens of billions of sentence pairs from 2019 reveals a ratio of over 5,000x. This corresponds to an annual increase of 5.5x. These figures overshadow Moore’s Law, which suggests an increase of only 1.6x per year.\n​Tuning\nThe situation is further exacerbated by the fact that models are not trained just once. The quality of a model often depends on various hyperparameters, such as the number of layers, hidden units, and batch size. To find the best model, developers must search through different hyperparameter settings. This process, called hyperparameter tuning, can be resource-intensive.\nFor instance, RoBERTa, a robust technique for pretraining NLP models, uses at least 17 hyperparameters. Assuming a minimal two values per hyperparameter, the search space consists of over 130K configurations. Even partially exploring this space requires vast computational resources. Another example of a hyperparameter tuning task is neural architecture search, which automates the design of artificial neural networks by testing different architectures and selecting the best-performing one. Researchers report that designing even a simple neural network can take hundreds of thousands of GPU computing days. Simulations\nWhile deep neural network models can typically leverage advances in specialized hardware, not all ML algorithms can. In particular, reinforcement learning algorithms involve numerous simulations. Due to their complex logic, these simulations are best executed on general-purpose CPUs (with GPUs only used for rendering), meaning they don’t benefit from recent advances in hardware accelerators. For example, in a recent blog post, OpenAI reported using 128,000 CPU cores and just 256 GPUs (i.e., 500x more CPUs than GPUs) to train a model capable of defeating amateurs at Dota 2.\nWhile Dota 2 is just a game, we’re witnessing a surge in the use of simulations for decision-making applications, with startups like Pathmind, Prowler, and Hash.ai emerging in this area. As simulators strive for increasingly accurate environmental modelling, their complexity rises, adding another multiplicative factor to the computational complexity of reinforcement learning.\n​Why we need distributed computing for AI\nBig data and AI are rapidly transforming our world. While technological revolutions bring risks, we see immense potential for this revolution to enhance our lives in ways we couldn’t have imagined just a decade ago. However, to realize this promise, we must overcome the massive challenges posed by the rapidly growing gap between application demands and our hardware capabilities. To bridge this gap, distributing applications appears to be the only viable solution. This necessitates new software tools, frameworks, and curricula to train and enable developers to build such applications, marking the beginning of a thrilling new era in computing.\nAt io.net, we develop innovative tools and distributed systems like Ray to guide application developers into this new era.\n​References:\n\n[1] Avg market price: https://www.paperspace.com/pricing\n[2] https://arxiv.org/pdf/2202.05924.pdf\n[3] https://businessolution.org/gpt-3-statistics/\n[4] https://research.ark-invest.com/hubfs/1_Download_Files_ARK-Invest/White_Papers/ARK_BigIdeas2022.pdf?hsCtaTracking=217bbc93-a71a-4c2b-9959-0842b6fe301c%7C2653a4d0-af35-42f0-853a-c5f90f002abb\nWas this page helpful?","tokens":2151,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257230395,"hash":"e9e23fb1a79a2ccb32468e8110e6a2649a9abde1"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/sequencer/sequencer-timing-adjustments","domain":"docs.arbitrum.io","title":"Configure Sequencer timing adjustments | Arbitrum Docs","text":"✏️Request an updateWhen launching an Arbitrum chain, the Sequencer plays a central role in ordering transactions and producing blocks. Several timing-related parameters can be adjusted in the node configuration (via the Nitro node's JSON config or command-line flags) to optimize performance, user experience, security, and cost for your specific use case.\nTo configure Sequencer timing parameters when launching an Arbitrum chain, you'll primarily adjust settings in two places:\n\nChain-level parameters: Set during deployment via the Chain SDK; these affect Sequencer behavior boundaries.\nNode-level parameters: Set when running your Nitro Sequencer node—these control runtime behavior, such as block production speed and batch posting.\n\nMost timing tweaks happen at the node level for the Sequencer. Use the official Arbitrum Chain SDK to generate a base node config JSON, then override specific fields, or pass flags directly when running the nitro-node Docker image.\nKey Sequencer timing parameters to adjust​\nParameterLocationDefaultHow to configureWhy adjustDelayed sequencer finalize distanceNode (node.delayed-sequencer)Higher (e.g., waits for full parent chain finality)CLI: --node.delayed-sequencer.finalize-distance=1 and enable: --node.delayed-sequencer.enable=true and disable: node.delayed-sequencer.use-merge-finality=falseLower value for near instant deposits (~seconds instead of minutes). Trade-off: ⚠️ DANGER ⚠️ Risk of reorg on parent chain.Delayed sequencer rescan intervalNode (node.delayed-sequencer)1sCLI: --node.delayed-sequencer.rescan-interval=1sHow often to rescan for new delayed messages. The parent chain reader's poll-interval is usually the more impactful setting.Delayed sequencer filtered-tx retry intervalNode (node.delayed-sequencer)30sCLI: --node.delayed-sequencer.filtered-tx-full-retry-interval=30sHow often to do a full re-execution when halted on a filtered delayed message.Sequencer Inbox max time variationChain deployment (sequencerInboxMaxTimeVariation)delayBlocks: 5760, futureBlocks: 12, delaySeconds: 86400, futureSeconds:3600In Chain SDK config struct or chainConfig JSON during deployment.Allows sequencer minor timestamp adjustments to avoid re-orgs if batch posting lags. Rarely needs change from defaults.Timeboost non-express delayNode (execution.sequencer.timeboost)200msIn node config: \"execution\": { \"sequencer\": { \"timeboost\": { \"non-express-delay-msec\": 300 } } }Larger delay for more advantage/revenue for Express Lane winner. Increases latency for regular transactions.\nStep-by-step configuration process​\n\nDeploy your chain first: using the Chain SDK, this sets immutable params like sequencerInboxMaxTimeVariation.\nGenerate base node config: Use the Chain SDK:\n\nimport { prepareNodeConfig } from '@arbitrum/orbit-sdk';const nodeConfig = await prepareNodeConfig({ // Your deployment tx receipt or params // Override defaults here, e.g.:});// Write nodeConfig to file: nodeConfig.json\n\nRun the Sequencer node:\n\nUse Docker (recommended):\n\ndocker run -v /path/to/nodeConfig.json:/config/nodeConfig.json \\ offchainlabs/nitro-node:v3.12.1-70fa99a \\ --conf.file=/config/nodeConfig.json \\ --node.sequencer=true \\ --execution.sequencer.enable=true \\ # Add other required flags (parent-chain URL, chain info-json, keys, etc.)\nLatest version of NitroYou can find the latest recommended version of Nitro on the Run a Node page.\n\nor override via CLI flags for testing\n\nTest changes on a devnet or testnet first—monitor TPS, state growth, posting costs, and deposit latency.\n\nFor a full list of flags, run nitro-node --help. Refer to Arbitrum Docs sections on Running a Sequencer Node and How to configure your Arbitrum chain's node using the Chain SDK for your exact version. If using Timeboost or advanced features, additional setup (e.g., Auction Contract) is needed.\nUnderstanding maxTimeVariation​\nmaxTimeVariation is a four-field setting on the Sequencer Inbox contract on the parent chain. It bounds how far a sequenced message's claimed parent-chain block number and timestamp may differ from the parent-chain block in which the batch carrying that message is actually posted.\nstruct MaxTimeVariation { uint256 delayBlocks; // max parent-chain blocks in the past a message may be received uint256 futureBlocks; // max parent-chain blocks in the future a message may be received uint256 delaySeconds; // max parent-chain seconds in the past a message may be received uint256 futureSeconds; // max parent-chain seconds in the future a message may be received}\nThe four fields define a two-sided window around the current parent-chain block and time:\n\ndelayBlocks and delaySeconds bound the past edge—how old a message's claimed block or timestamp may be.\nfutureBlocks and futureSeconds bound the future edge—how far ahead a message's claimed block or timestamp may be.\n\nBlocks and seconds are tracked independently: delayBlocks and futureBlocks are measured in parent-chain block numbers (block.number), while delaySeconds and futureSeconds are measured in parent-chain seconds (block.timestamp).\nHow the time window is enforced​\nUnderstanding what this setting guards requires knowing where it is enforced, which is not where most people expect.\nWhen a batch is posted, the Sequencer Inbox computes the window from the current parent-chain block and time at the moment the batch lands:\n\nTimestamp window: [block.timestamp - delaySeconds, block.timestamp + futureSeconds]\nBlock window: [block.number - delayBlocks, block.number + futureBlocks]\n\nThe contract records these bounds (they are emitted in the SequencerBatchDelivered event and folded into the batch's data hash), but it does not reject a batch whose messages fall outside them. Enforcement happens later, off the parent chain, when the batch is replayed by the node's state-transition function: each message whose claimed block or timestamp is outside the recorded window is clamped to the nearest bound—pulled up to the minimum if it is too far in the past, or pulled down to the maximum if it is too far in the future.\nOut-of-window messages are clamped, not rejectedBecause out-of-window messages are silently clamped rather than rejected, a message can be assigned a different parent-chain block or timestamp than the Sequencer originally computed locally. When the locally executed chain and the chain derived from onchain data disagree, the result is a child-chain reorg. maxTimeVariation therefore does not guard by blocking bad batches; it defines the window inside which the Sequencer and batch poster must keep every message to avoid such reorgs.\nWhat each field guards, with examples​\nFuture edge (futureBlocks / futureSeconds). These cap how far ahead of the parent chain a message may claim to be.\nFor example, suppose futureSeconds is 3600 (one hour) and the batch lands in a parent-chain block whose timestamp is T. Any message in that batch claiming a timestamp later than T + 3600 is clamped down to T + 3600. If futureBlocks is small—say 48 on a parent chain with two-second blocks, roughly 96 seconds of headroom—then a batch that is delayed, or that contains messages sequenced slightly ahead of the parent chain, can easily reach the future edge and have its messages clamped down. Raising futureBlocks widens this headroom.\nPast edge (delayBlocks / delaySeconds). These cap how old a message may be. A message claiming a timestamp earlier than block.timestamp - delaySeconds is clamped up to that minimum.\nFor example, with delaySeconds set to 345600 (four days), a message may be up to four days older than the parent-chain block that carries it before it is clamped forward.\ndelayBlocks also sets the force-inclusion wait. The same delayBlocks value determines how long a message submitted through the Delayed Inbox must wait before it can be force-included, bypassing the Sequencer. forceInclusion reverts with ForceIncludeBlockTooSoon until delayBlocks parent-chain blocks have elapsed since the message was submitted. Raising delayBlocks therefore lengthens the Sequencer's exclusive window and delays when users can force their transactions in. The optional delay-buffer feature can shorten this window under sustained delay, but never lengthen it.\nFor more on force inclusion and the Delayed Inbox, see the Sequencer deep dive.\nDefault values​\nThe Arbitrum Chain SDK does not use fixed numbers for these fields. It derives them from the parent chain's block time, holding the time windows constant and converting them to block counts:\n\ndelaySeconds is 345600 (four days) and futureSeconds is 3600 (one hour), constant for all parent chains.\ndelayBlocks is delaySeconds / parentBlockTime and futureBlocks is futureSeconds / parentBlockTime.\n\nparentBlockTime is two seconds when the parent chain is Base or Base Sepolia (whose block.number advances every two seconds), and 12 seconds for every other parent chain, including Ethereum and Arbitrum. The SDK selects the two-second value only for those two chain IDs, so a different OP-stack parent that the SDK does not recognize falls back to the 12-second default. This yields different block defaults depending on where your chain settles:\nParent chainParent block timedelayBlocksfutureBlocksdelaySecondsfutureSecondsBase / Base Sepolia2s1728001800345600 (4 days)3600 (1 hour)All other parents12s28800300345600 (4 days)3600 (1 hour)\nWhy the default futureBlocks can be 300 or 1800A default futureBlocks can appear to be either 300 or 1800: 1800 is the default for a Base or Base Sepolia parent (3600 / 2), while 300 is the default for every other parent, including Ethereum and Arbitrum (3600 / 12). A much smaller value such as 48 is not a current SDK default—it is a manual override or a value from an older deployment. Restoring futureBlocks to the parent-appropriate default widens the future headroom (on a two-second parent, from roughly 96 seconds to one hour), reducing how often messages near the future edge are clamped.\nRelationship with the batch poster: reorg-resistance-margin​\nmaxTimeVariation defines the window; the batch poster is responsible for keeping every message it posts safely inside it. Two node-level settings do this self-policing, one per edge:\n\nFuture (max) edge — the batch poster stops adding messages that would exceed block.number + futureBlocks or block.timestamp + futureSeconds. Which parent-chain header it measures against is selected by --node.batch-poster.l1-block-bound, which must not be set to ignore for the past-edge check below to run.\nPast (min) edge — governed by --node.batch-poster.reorg-resistance-margin.\n\n--node.batch-poster.reorg-resistance-margin (a duration, default 10m0s) tells the batch poster: do not post a batch if its oldest message is within this margin of the window's past edge (block.timestamp - delaySeconds or block.number - delayBlocks). If the oldest non-delayed message is closer to the minimum bound than the margin allows, the poster halts rather than posting.\nWhy the margin exists​\nMessage timestamps and block numbers are assigned by the Sequencer at sequencing time, but the onchain minimum bounds are computed from the parent-chain block and time at the later moment the batch actually lands. Between those two moments the parent chain advances, and it can also reorg. If a batch's oldest message is sitting right at the past edge, either a delayed landing or a parent-chain reorg can move the minimum bound past that message. The state-transition function then clamps the message up to the new minimum, silently changing the child-chain block or timestamp the Sequencer's own node had already produced, which is a child-chain reorg.\nThe default 10-minute margin keeps messages far enough from the past edge that ordinary parent-chain reorgs cannot push them out of the window.\nThe reorg-resistance-margin=0 bypass and its risk profile​\nSetting --node.batch-poster.reorg-resistance-margin=0 disables the past-edge check entirely. The batch poster will then post batches whose oldest messages sit arbitrarily close to the window's past edge.\nreorg-resistance-margin=0 removes reorg protectionWith reorg-resistance-margin=0, a parent-chain reorg — or simply a batch landing later than expected — can move the minimum bound past messages that were near the edge. Those messages are then clamped forward by the state-transition function, diverging the onchain-derived chain from the chain the Sequencer executed locally: a child-chain reorg. Use 0 only in controlled situations, such as draining a backlog where you accept the reorg risk; it is not a safe steady-state setting.\nNote the interaction with maxTimeVariation: a wider past window (delayBlocks and delaySeconds) gives the batch poster more room before the margin is threatened, while a narrower window makes the margin bite sooner. See the CLI flags reference for the full batch-poster flag set.\nChanging maxTimeVariation​\nmaxTimeVariation is set at deployment through the Chain SDK, and can be changed afterward by the chain owner by calling setMaxTimeVariation on the Sequencer Inbox contract on the parent chain. Keep two effects in mind when changing it on a live chain:\n\nRaising delayBlocks lengthens the Sequencer's exclusive window and delays force inclusion. Very large values weaken the chain's censorship-resistance guarantee, because users must wait longer to force transactions in.\nRaising futureBlocks and futureSeconds widens the future headroom, reducing clamping of messages sequenced ahead of the parent chain; it does not affect force inclusion.\n\nTest any change on a testnet first, and confirm the batch poster's l1-block-bound and reorg-resistance-margin settings remain consistent with the new window.Key Sequencer timing parameters to adjustStep-by-step configuration processUnderstanding maxTimeVariationHow the time window is enforcedWhat each field guards, with examplesDefault valuesRelationship with the batch poster: reorg-resistance-marginWhy the margin existsThe reorg-resistance-margin=0 bypass and its risk profileChanging maxTimeVariation","tokens":3501,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257239979,"hash":"8ce9cf3436b98e36a2f877814fad5dcbfae61cb4"}
{"url":"https://aave.com/docs/aave-101","domain":"aave.com","title":"Aave 101 | Aave Protocol Documentation","text":"Aave 101#\nAn intro to Aave: powering open, decentralised finance.\n\nAave is a leading liquidity protocol, a decentralised system of smart contracts that facilitates the efficient movement and management of digital assets.\nBuilt on a supply-and-borrow model, it enables users to supply liquidity and, in return, allows other participants to borrow against supplied collateral. The protocol is deployed across multiple blockchain networks, ensuring accessibility and interoperability across ecosystems.\nAave v3 is the stable and widely used version of the\nprotocol; Aave v4 is the next evolution of the protocol\narchitecture.\nSelf-Custody#\nA defining characteristic of a decentralised liquidity protocol is its non-custodial design, which ensures users always retain control of their assets. All operations are handled by permissionless smart contracts that autonomously enforce the protocol's rules.\nUser Control: Direct interaction using a self-custodial wallet without intermediaries.Transparency: All rules, like collateral requirements and interest rates, are embedded in open-source smart contracts.Trustless Execution: Operations are executed automatically without relying on a central party.\nHow Aave Works#\nCollateral#\nIn decentralised finance, lending is secured by collateral, the digital assets a borrower locks in the protocol to secure a loan. Unlike traditional finance, which relies on credit scores, DeFi uses over-collateralization. This requires borrowers to supply assets of greater value than the amount they wish to borrow.\nThis model is essential for a trustless system. It protects suppliers' funds and maintains protocol solvency by ensuring there are always sufficient funds to cover the debt, even if the value of the collateral decreases.\nLending and Borrowing#\nThe Aave protocol functions as a two-sided market. Users can participate as lenders (suppliers), borrowers, or both.\nRoleActionOutcomeLendersSupply assets to shared liquidity.Earn passive interest.BorrowersLock collateral to borrow other assets.Access borrowing capacity against supplied collateral.\nInterest Rates#\nInterest rates adjust based on how much liquidity is in use (utilization). Aave uses a utilization curve with a “kink” at a target level: below the target, borrow rates increase gradually; above it, they increase more sharply to protect liquidity. Supplier rates are funded by borrower interest and also rise as utilization increases.\nLiquidations#\nLiquidations keep the protocol solvent by correcting risky positions. When a position becomes unhealthy, a liquidator can repay a portion of the debt and receive collateral with a liquidation bonus. This reduces the user's debt and improves the position's health; if needed, additional liquidations can occur until the position is safe again.\nDecentralised Governance#\nThe protocol is governed by AAVE token holders through a decentralised governance framework. This community-driven model allows participants to propose, vote on, and enact changes that shape the protocol's evolution, such as adjusting risk parameters or introducing new assets and features. Governance ensures that the protocol remains adaptable and aligned with the needs of its users without centralised oversight.\nEcosystem and Extensions#\nBeyond its core liquidity markets, Aave includes complementary features and extensions:\nStreamlined actions such as token swaps (coming soon)Native components like the GHO stablecoin\nTogether, these components reflect the broader potential of decentralised finance (DeFi) to deliver open, transparent, and accessible financial infrastructure to anyone connected to a blockchain network.\nNext Steps#\nExplore Aave v4.Learn about Aave v3.PreviousOverviewNextSimple Earn Vaults","tokens":934,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257242793,"hash":"fffeea7a1ce0f81a951681adc3988540dacd3feb"}
{"url":"https://io.net/docs/guides/block-rewards/block-rewards","domain":"io.net","title":"Overview - io.net","text":"​Table of Contents\n\nWhat Are Block Rewards\nBlock Rewards Allocation\nBlock Reward Nomination Requirements\nBlock Rewards Nomination Checklist\nWallets\n\n​What Are Block Rewards?\nBlock rewards are payments made to suppliers who provide their GPUs or CPUs to our network. This incentivizes supply-side network growth. These rewards are accrued hourly in $IO, following a predefined emission schedule. Rewards are potentially subject to slashing before distribution.\n​Block Rewards Allocation\nBlock Rewards are credited to Suppliers on an hourly basis for making their GPU or CPU available on the IOG Network, thereby incentivizing supply-side network growth. This payout is in IO Coin and follows a predetermined emission schedule. The current allocation of block rewards from each hourly emission is:\n\n95% to GPUs\n5% to CPUs\n\nThe ratio of rewards may be adjusted in the future to manage network growth.\nTo learn more, see IO Coin.\n​Initial Block Reward\nThe first Block Reward was created on June 25th 2024 12:00 UTC.\nWe will calculate and publish the initial block rewards, and block rewards use a claim mechanism that is similar to the Ignition Program. The first 7 days of block rewards were claimable together with Ignition Reward Season 3. Block Rewards for June 25th - June 30th will also be claimable.\nIO Device Level staking/Minimum staking is now required for Block Rewards. To learn more about staking, see IO Staking.\nIOG Foundation provides emission rewards to incentivize the correct growth of the IO ecosystem. To better align with Ignition Reward Season 3, the IOG Foundation has not requested io.net to cap the amount of devices eligible for block rewards. In the future, the IOG Foundation will monitor the reward distribution and may potentially cap the amount of devices eligible for the top percentage of nodes. A device cap is used to increase the alignment of the network’s structure.\n​Block Reward Nomination Requirements\nThe requirements below must be met to be nominated for a Block Reward:\n\nDevice Uptime must be green for the past 5 hours.\nThe minimum stake for the device must be met. To learn more about staking, see IO Staking.\nThe account holder for the device must have a valid Solana wallet.\nThe device’s status is NOT terminated or unsupported.\nThe device’s hardware multiplier is greater than 0.\nThe device’s connectivity tier is greater than 0.\n\nWhen a block is about to close, we test your device for Uptime and PoW again.\n​Block Rewards Nomination Checklist\nClick the caret on the right side of the status row (Eligible in the example) to open the Block Rewards Nomination Checklist. Each step of the verification status is displayed, with a green or red check that indicates success or failure. The checklist displays the current status of the device’s eligibility for a block reward. In the example case below, if a new block was opening, this device would be eligible.\nThe Block Rewards Nomination Checklist is designed to offer total transparency into the Block Reward nomination process.\n\nDevice Limitations\n\nM3 devices with 8GB memory can be configured by users for higher memory. The minimum configuration should be 16GB of memory.\nAs of July, 5th, we removed Block Reward eligibility for Threadrippers. This is due to reports that malicious actors tried to inject Ryzen Threadripper devices into Block Rewards. We will reevaluate this and restore this option in the future.\n\n​Wallets\nWallets with Exchange Deposit Addresses (Custodial wallets) are not supported. To collect Block Rewards, worker earnings, or seasonal events, connect a Web3 wallet (Self-Custodial wallet) in your Account Settings. Exchange Deposit Addresses are not supported because airdrop claims require a smart contract interaction.\nWe do not support Exchange Deposit Addresses (Custodial wallets) for Block Rewards. If you connect a wallet with an Exchange Deposit Address to your account in Account Settings, you will not be able to claim Block Rewards, seasonal events, nor worker earnings. If this is the case, please change it to a Self-Custodial wallet as soon as possible.Was this page helpful?","tokens":1028,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257242840,"hash":"85344744ece87c444f4e5acc3b6121bcf371033e"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/overview","domain":"docs.arbitrum.io","title":"Arbitrum nodes: an overview | Arbitrum Docs","text":"✏️Request an updateNoteThere is no protocol-level incentive to run an Arbitum full node. If you’re interested in accessing an Arbitrum chain but don’t want to set up a node locally, see our RPC endpoints and providers to get RPC access to fully managed nodes hosted by a third-party provider.\nAPI security disclaimerWhen exposing API endpoints to the Internet or any untrusted/hostile network, the following risks may arise:\nIncreased risk of crashes due to Out-of-Memory (OOM):\nExposing endpoints increases the risk of OOM crashes.\nIncreased risk of not keeping up with chain progression:\nResource starvation (IO or CPU) may occur, leading to an inability to keep up with chain progression.\nWe strongly advise against exposing API endpoints publicly. Users considering such exposure should exercise caution and implement the right measures to enhance resilience.\nTo be able to interact with or build applications on any Arbitrum chain, you will need to access the corresponding Arbitrum node. Options are:\n\nThird party node providers to get RPC access to fully-managed nodes\nRun your own Arbitrum node, especially if you want always to know the state of the Arbitrum chain\n\nThe rest of this series focuses on the second approach: running your own Arbitrum node.\nWhen interacting with the Arbitrum network, users have the option to run either a full node or an archive node. There are distinct advantages to running an Arbitrum full node. In this quick start, we will explore the reasons why a user may prefer to run a full node instead of an archive node. By understanding the benefits and trade-offs of each node type, users can make an informed decision based on their specific requirements and objectives.\nBeyond full and archive nodes, a Nitro node can take on other roles — sequencer, batch poster, validator, or feed relay—purely through configuration. For the flags that define each role and how to convert a node between roles, see How to assign roles to a Nitro node.\nConsiderations for running an Arbitrum full node​\n\nTransaction validation and security: Running a full node allows you to independently validate transactions and verify the state of the Arbitrum blockchain. You can have complete confidence in the authenticity and integrity of the transactions you interact with.\nReduced trust requirements: By running a full node, you can interact with the Arbitrum network without relying on third-party services or infrastructure. This independence reduces the need to trust external entities and mitigates the risk of potential centralized failures or vulnerabilities.\nLower resource requirements: Compared to archive nodes, full nodes generally require fewer resources such as storage and computational power. These requirements make it more accessible with limited hardware capabilities or those operating in resource-constrained environments.\n\nFor detailed instructions, read how to run an Arbitrum full node.\nConsiderations for running an Arbitrum archive node​\nWhile full nodes offer numerous advantages, there are situations where running an archive node may be more appropriate. Archive nodes store the complete history of the Arbitrum network, making them suitable to access extensive historical data or advanced analytical purposes. However, it's important to note that archive nodes are more resource-intensive, requiring significant storage capacity and computational power.\nFor detailed instructions, read how to run an Arbitrum archive node.\nConsiderations for running an Arbitrum classic node​\nThe significance of running an Arbitrum classic node is mainly applicable to individuals with specific needs for an archive node and access to classic-related commands.\nFor detailed instructions, read how to run an Arbitrum classic node.\nConsiderations for running a feed relay​\nIf you are running a single node, there is no requirement to set up a feed relay. However, if you have multiple nodes, it is highly recommended to have a single feed relay per data center. This setup offers several advantages, including reducing ingress fees and enhancing network stability.\nSoon, feed endpoints will mandate compression using a custom dictionary. Therefore, if you plan to connect to a feed using anything other than a standard node, it is strongly advised to run a local feed relay. This local feed relay will ensure that you have access to an uncompressed feed by default, maintaining optimal performance and compatibility.\nFor detailed instructions, read how to run an Arbitrum feed relay.\nSupport policy​\nTo view the short and long term support policy, visit the Nitro support policy page.Considerations for running an Arbitrum full nodeConsiderations for running an Arbitrum archive nodeConsiderations for running an Arbitrum classic nodeConsiderations for running a feed relaySupport policy","tokens":1204,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257249974,"hash":"487c5a1b746b48187a90fa637d8ab966f41e5067"}
{"url":"https://aave.com/docs/vaults/stable-vaults/features","domain":"aave.com","title":"Stable Vault Features | Aave Protocol Documentation","text":"Stable Vault Features#\nStable-Rate Earnings#\nStable Vaults convert variable DeFi lending rates into a predictable stable-rate product. When a user deposits, their position accrues at a locked per-second rate defined by their assigned SubVault, regardless of how underlying market rates fluctuate. The off-chain rebalancer continuously optimizes yield strategy allocations to sustain committed rates across the user base, absorbing market volatility within the Stable Vault smart contract system rather than passing it through to depositors.\nMulti-Strategy Earning#\nDeposits are not tied to a single yield source. The Allocator routes assets across multiple approved ERC-4626 yield strategies, such as Aave v4 markets, Aave v3 markets, the Savings GHO vault, or any other compliant vault approved by the integrator. The off-chain manager rebalances allocations between strategies as market conditions change, diversifying yield sources and sustaining committed rates without any action required from depositors.\nMulti-Chain Earning#\nThe system spans multiple networks. The Accounting Chain is the source of truth for user balances and withdrawals, while one or more Earning Chains host additional yield strategies. This lets the vault allocate deposits to yield opportunities wherever they exist, and lets users bridge their IOUs to redeem into assets available on other supported chains. Funds move between chains through multiple approved bridge providers. See Architecture for how the chains fit together.\nPer-User Rates#\nEach user's position belongs to exactly one SubVault. A SubVault defines a set per-second accrual rate, and a user's withdrawable balance is their shares multiplied by the SubVault's current conversion rate. Because different SubVaults carry different rates, operators can assign different APYs to different user segments based on loyalty tiers, promotional campaigns, subscription levels, or other product logic. SubVault assignment is managed off chain: it is applied at the point of deposit and can be updated at any time afterward, throughout the life of the user's position.\nAllowlist#\nDeposit access to the Stable Vault can be restricted to a set of approved wallets. This allows operators to run controlled embedded earning programs where only eligible users, such as those who have completed KYC, belong to a specific tier, or have been explicitly enrolled, can deposit. The allowlist is managed per deployment and does not affect the ability of existing depositors to withdraw.\nVault Revenue Management#\nThe system tracks each user's original deposit principal separately from accrued interest. Principal is always redeemable as IOUs, with no additional conditions. Interest redemption is gated by the system's trusted, price-weighted surplus, meaning users can only convert accrued interest into IOUs when the system's assets exceed its obligations by that amount. Privileged callers can claim surplus interest as protocol revenue via claimSurplusInterest, subject to the same surplus check.\nWithdrawal fees are configured per asset in basis points and applied by the Withdrawal Execution Policy at redemption time. Because fees are set per asset, the vault can support multiple stablecoins as eligible deposit and withdrawal assets while preventing users from taking advantage of the system for one-to-one swaps between them.\nMulti-Asset Deposits & Withdrawals#\nAll supported stablecoins are treated as interchangeable inside the vault. When a user deposits, the system validates the asset's price and credits the position in the vault's denomination currency, valued at nominally one U.S. dollar, so what a user deposited places no restriction on what they can withdraw. At withdrawal, users choose any supported output asset on the chain where they redeem, and the vault manager is responsible for ensuring the system holds enough assets on each chain, in each supported denomination, to fulfill instant withdrawals. A user who deposited USDC may redeem into USDT, GHO, or another supported asset on the Accounting Chain, or bridge their IOUs to an Earning Chain to redeem into assets available there such as PYUSD or RLUSD.\nAsset support is controlled by the Asset Registry, which tracks whether an asset may be deposited by users, deposited into the Allocator, used as a swap input, or received as a swap output. Assets can be marked as distrusted to exclude them from the system's surplus accounting without blocking users from voluntarily redeeming IOUs into those assets, ensuring the system accounts conservatively for assets that have depegged or whose price integrity is uncertain.\nSecurity Controls#\nA global redemption rate limit throttles the total volume of IOU redemptions across all users and assets within a given period, bounding how quickly value can exit the system during abnormal conditions. The limit carries configurable floor values that prevent the policy from being tightened below a minimum throughput, so redemptions can never be effectively frozen through configuration alone.\nRequest IntegrationPreviousStable VaultsNextArchitecture","tokens":1275,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257252744,"hash":"9189f088a41a9b22d98e35996270c604f1cb9895"}
{"url":"https://io.net/docs/guides/glossary","domain":"io.net","title":"Glossary - io.net","text":"​IO Ecosystem\n\nIO Coin Connecting all the Web3 money that’s flowing into the GPU to power io.net. A blockchain-based cryptocurrency and platform designed to foster a decentralized ecosystem for applications and services. Operating on its own blockchain, IO Coin employs a hybrid consensus mechanism merging Proof of Work (PoW) and Proof of Stake (PoS) to ensure security and energy efficiency. With support for decentralized applications (dApps), including features like smart contracts and token issuance, IO Coin enables diverse functionalities. It integrates privacy-enhancing features like ZeroCoin and Ring Signatures, providing anonymity. Its versatility extends to applications in peer-to-peer transactions, remittances, and decentralized finance (DeFi).\nIO Worker IO Worker is a component of the IO.NET ecosystem that enables users to rent out their computing devices like GPUs and CPUs to those needing computational power. By leasing their device’s processing capabilities, users earn rewards for tasks like artificial intelligence computations or rendering. This setup fosters decentralized computing and resource sharing, fostering collaboration and mutual benefit among users on the IO.NET platform.\nIO Explorer IO Explorer is a multifunctional tool within the IO.NET ecosystem designed for users to explore and navigate various aspects of the platform. It serves as a dashboard where users can monitor compute jobs, access performance metrics, and explore available resources within the IO.NET network. Additionally, IO Explorer provides insights into others’ activities, offering a comprehensive view of the platform’s functionalities and user engagements.\nIO Cloud IO Cloud is a component of the IO.NET ecosystem that provides cloud computing services to users. It enables users to deploy and manage virtual machines, containers, and other cloud resources on-demand. IO Cloud offers scalability, flexibility, and accessibility, allowing users to harness the power of cloud computing for various applications and workloads. IO Cloud simplifies the process of managing cloud infrastructure and empowers users to focus on their core tasks without worrying about underlying infrastructure complexities.\n\n​Basic Terms\n\nClient Customers who hire GPU/CPU compute power.\nBinary A binary is a file that contains executable instructions in a format that a computer can directly execute. It represents a software application in a form that the computer’s processor can understand and run.\nWorker Are the nodes in the cluster that execute the tasks assigned by the master node. They process data, perform computations, and contribute to the overall workload of the system.\nSolscan Solscan is a Solana block explorer (blockchain explorer) that enables investors to view transactions, explore wallets, find important data, and better understand other key metrics of the Solana ecosystem.\nSolana Solana is a high-performance blockchain platform designed for decentralized applications (dApps) and cryptocurrency transactions. It aims to provide fast and scalable solutions for developers, with the ability to process thousands of transactions per second. Solana uses a unique consensus mechanism called Proof of History (PoH) combined with Proof of Stake (PoS) to achieve high throughput and low latency. The platform also offers low transaction fees and supports smart contracts, making it suitable for a wide range of applications in finance, gaming, and decentralized finance (DeFi).\nAptos Aptos is a blockchain platform designed for high scalability, security, and efficiency in decentralized applications (DApps). It aims to provide fast transaction speeds and strong security through a novel consensus mechanism and advanced cryptography. Aptos supports smart contracts, enabling developers to build various DApps, and emphasizes a user-friendly experience and robust developer tools.\nComputing Computing refers to the process of performing calculations, such as addition, multiplication, or more complex mathematical functions. This term is closely associated with computers, which are designed to perform computations rapidly and efficiently.\nCompute Hours Compute hours are the measurable hours or, time that your process is loaded and executing. Compute hours are one of the two main metrics that are used to determine costs.\nCluster Processor CPU/GPU unit designed to handle parallel computing workloads within a cloud-based cluster. These processors are used for tasks that can be parallelized across multiple cores or nodes within a cluster, such as data analytics, scientific simulations, machine learning training, and other high-performance computing (HPC) workloads.\nConnectivity Tier It’s a speed or bandwidth of internet connectivity provided by an internet service provider (ISP) or telecommunications company. It represents the rate at which data can be transmitted over a network connection, typically measured in megabits per second (Mbps) or gigabits per second (Gbps).\nBlockchain Prover A computational entity that confirms that information is accurate without revealing its underlying data. Provers create “proofs” that can be easily verified by a verifier. Traditionally provers generates proofs via Proof of Work (PoW), and some migrated to Proof of Stake (PoS), some are now generating Zero Knowledge Proofs.\nContainerized Workload An application or software workload that has been packaged into a containerized format. Containers are a lightweight, portable, and self-contained unit of software that includes all the necessary dependencies, libraries, and configuration files needed to run the application.\nDePIN Decentralized Physical Infrastructure Networks, leverages blockchains, IoT and the greater Web3 ecosystem to create, operate and maintain real-world physical infrastructure. These networks leverage token incentives to coordinate, reward and safeguard members of the network.\nNode Node AI is a platform that connects you with GPU and artificial intelligence resources in a decentralized way. It uses blockchain technology to ensure security and transparency, enabling users to engage in a range of activities securely.\nDecentralized Applications Decentralized applications (dApps), are software programs that run on a blockchain or peer-to-peer (P2P) network of computers instead of on a single computer. Rather than operating under the control of a single authority, dApps are spread across the network to be collectively controlled by its users.\nScript FIle A script file is a file that contains a sequence of commands or instructions written in a scripting language. Scripting languages, such as Bash, Python, PowerShell, and JavaScript, allow you to automate tasks, execute programs, and perform various operations on a computer or within a software environment.\nProof-of-Work (PoW) The Proof-of-Work (PoW) consensus algorithm was brought to fruition with the inception of Bitcoin in 2009. It serves as the mechanism for validating transactions and generating new blocks within a blockchain. This process involves specialized devices, computers, or graphics cards performing complex calculations. In PoW, the discovery or creation of a new block is achieved through solving a cryptographic puzzle, a task known as mining. Miners invest significant computational power and energy in attempting to solve these puzzles, which forms the foundation of the term ‘Proof-of-Work’.\nJob Job refers to a specific task allocated to a GPU cluster for execution, such as machine learning training or data analysis. It involves parameters and instructions for efficient execution.\nRandom Access Memory (RAM) RAM is a type of computer memory that allows data to be accessed and read in any order, making it faster than storage devices like hard drives. It temporarily holds data and instructions that are actively being used or processed by the CPU (Central Processing Unit). RAM is volatile memory, meaning it loses its contents when the power is turned off.\nSXM SXM is a high-performance connection standard that allows GPUs to be directly mounted onto a motherboard without the need for PCIe (Peripheral Component Interconnect Express) slots.\nBIOS The BIOS (Basic Input/Output System) is built-in software on your computer’s motherboard that starts up your computer and ensures all hardware works together properly. It also lets you change basic settings through an easy-to-navigate menu.\nUEFI Unified Extensible Firmware Interface (UEFI) is modern software that starts up your computer and helps it run smoothly. It’s like an upgraded version of BIOS, with a more user-friendly interface, faster startup times, and better support for large hard drives. It also provides more advanced security features to protect your system from threats.\nWSL 2 Windows Subsystem for Linux 2 (WSL 2) is a feature in Windows that lets you run a full Linux system on your computer without needing to set up a separate machine or use complex software. It provides a seamless way to use Linux tools and applications alongside your regular Windows programs, making it easier for developers and tech enthusiasts to work with both systems at the same time.\n\n​Device Type\n\nCentral Processing Unit (CPU) CPU stands for Central Processing Unit. It is the primary component of a computer responsible for executing instructions and performing calculations required to run software programs and operating systems.\nGraphics Processing Unit (GPU) Graphics Processing Unit, is a special computer chip that helps make images and videos appear on your screen faster. It’s like a supercharged engine for handling visual tasks, such as gaming, watching videos, and designing graphics. They accelerate the computational tasks involved in training and running machine learning models.\n\n​Clusters\nCluster A group of interconnected computers or servers that work together to perform tasks or provide services. Clustering allows multiple machines to function as a single system, enabling improved performance, scalability, and reliability. Here are some key characteristics and types of clusters.\n\nRay Cluster A cluster of machines managed by the Ray framework. Ray is an open-source framework for building and running distributed applications. It provides a simple, universal API for building distributed applications efficiently. Typically consists of multiple machines (nodes) connected together to form a distributed computing environment. These machines work together to execute tasks and manage resources efficiently.\nMega-Ray The supply offers a cutting-edge global networking infrastructure on a diverse selection of enterprise-grade GPU models, all of which meet the highest standards of security compliance. However, this comes at a premium cost.\nKubernetes (AKA k8s) Open-source platform designed to automate the deployment, scaling, and management of containerized applications. Provides a framework for automating the management of containerized workloads and services, allowing organizations to abstract away the underlying infrastructure and focus on developing and deploying their applications.\n\n​Base Image\nA base image is the core starting point for creating containers or virtual machines, containing essential components and dependencies needed to run applications or systems.\n\nRay App Ray is an open-source distributed computing framework primarily used for scaling Python applications across clusters. Ray provides a set of libraries for building distributed applications, including machine learning training, hyperparameter tuning, reinforcement learning, and more.\nPytorch FSDP PyTorch FSDP stands for PyTorch Fully Sharded Data Parallelism. It’s a distributed training technique designed to efficiently train large deep learning models across multiple GPUs or even across multiple machines. FSDP achieves this by sharding (splitting) the model parameters and activations across multiple devices, allowing for parallel computation during training.\nLudwig Ludwig is an open-source, declarative deep learning model building framework developed by Uber AI Labs. It aims to provide a simple and flexible way to train and test deep learning models without requiring extensive knowledge of machine learning or deep learning frameworks. Ludwig enables users to build and deploy deep learning models for a variety of tasks, including natural language processing (NLP), computer vision, time series forecasting, and more.\nIO Native App A specialized software development kit provided by IO.NET, based on a fork of Ray, designed to streamline model development, training, and deployment within the ecosystem. It supports the parallelization of Python functions, dynamic task execution, and effortless scalability, empowering developers to build and scale their AI applications seamlessly on the network.\nUnreal Engine 5 Unreal Engine 5 (UE5) is a powerful and popular real-time 3D creation platform primarily used for developing video games, architectural visualizations, virtual reality (VR) experiences, and more. Machine learning algorithms for computer vision can be used to enhance augmented reality (AR) or mixed reality (MR) experiences created with Unreal Engine 5. For example, object recognition and tracking algorithms can enable more realistic interactions between virtual and real-world objects in AR applications.\nUnity Streaming Unity Render Streaming is a technology that brings Unity’s powerful rendering capabilities to web browsers, allowing users to experience high-quality graphics directly in their browser without additional software installations.\n\n​Cluster Type\n\nGeneral Best for prototyping or general end-to-end (E2E) Workloads. Virtual Machine (VM) clusters are often straightforward to set up and configure, making them suitable for prototyping. Virtual machines can be quickly provisioned and customized to match specific requirements, enabling developers to experiment with different configurations and environments.\nTrain For production-ready clusters for machine learning model training and fine-tuning, Train clusters with specialised machine learning orchestration tools are often preferred. This Cluster provides a scalable, reliable, and flexible infrastructure for deploying and managing containerized applications, while machine learning orchestration tools offer features tailored to the unique requirements of training and deploying machine learning models.\nInference By deploying Inference services on the cluster with efficient resource management, auto-scaling capabilities, hardware acceleration, and robust monitoring, it’s possible to build a production-ready infrastructure capable of handling low-latency inference and heavy workloads at scale.\nInference Refers to the process of using a trained model to make predictions, decisions, or classifications based on new, unseen data. In other words, it’s the application of a machine learning model to real-world data to derive insights or take action.\nNV Link NVLink is a high-speed communication interface developed by NVIDIA for connecting GPUs (Graphics Processing Units) together. It enables direct communication between GPUs, allowing them to work together more efficiently by sharing data at extremely high speeds. NVLink is designed to enhance performance in tasks that require parallel processing, such as deep learning, scientific simulations, and high-performance computing.\nGreen GPUs Green computing is the practice of maximizing energy efficiency and minimizing environmental impact in the ways computer chips, systems and software are designed and used.\n\n​Additional Software\n\nCUDA The NVIDIA CUDA Toolkit provides a development environment for creating high-performance, GPU-accelerated applications. With it, you can develop, optimize, and deploy your applications on GPU-accelerated embedded systems, desktop workstations, enterprise data centers, cloud-based platforms, and supercomputers. The toolkit includes GPU-accelerated libraries, debugging and optimization tools, a C/C++ compiler, and a runtime library.\nDocker Docker is a platform that allows developers to develop, ship, and run applications in containers. Containers are lightweight, portable, and self-sufficient units that contain everything needed to run an application, including the code, runtime, system tools, libraries, and settings. Docker provides a way to package and distribute applications along with their dependencies, making it easier to deploy and manage software across different environments.\nFabric Manager It’s a software tool developed by NVIDIA that manages the hardware resources and interconnects in NVIDIA GPUs, particularly those using NVLink and SXM architectures. It is essential for ensuring that the high-speed interconnects between GPUs are functioning correctly, which is crucial for applications requiring intense computational power and fast data transfer between GPUs.\nTerminal A terminal is a text-based interface in a computer system used for entering commands and interacting with the operating system or applications. It provides a way to navigate the file system, run programs, manage processes, and perform various tasks using command-line instructions. Terminals are commonly used in Unix-based systems like Linux and macOS, where users can access a terminal window to enter commands directly.\nNVIDIA driver A NVIDIA driver is a software component that allows your computer’s operating system to communicate and interact with NVIDIA graphics processing units (GPUs). It acts as a bridge between the hardware and the operating system, facilitating the proper functioning and optimization of NVIDIA GPUs for tasks like graphics rendering, gaming, AI processing, and more.\nHiveon OS Hiveon OS is an operating system specifically designed for cryptocurrency mining. It is optimized to maximize mining efficiency and profitability by providing features such as easy setup, remote monitoring and management, mining software integration, and performance optimization for various mining rigs.\nRosetta 2 Rosetta 2 is a special software for Apple computers with M1 chips that lets them run apps designed for older Intel-based Macs. It works behind the scenes to translate the app’s instructions so they can work on the new hardware, allowing you to use your favorite apps even if they haven’t been updated for the new chips.\n\n​Security Compliance\n\nE2E Encrypted It’s a method of secure communication where the data is encrypted on the sender’s device, remains encrypted while it’s transmitted over a network, and is only decrypted on the recipient’s device.\nSOC2/HIPAA SOC 2 and HIPAA are compliance frameworks that address different aspects of data security and privacy. SOC 2 focuses on assessing the controls implemented by service organizations to protect customer data, while HIPAA sets standards for protecting sensitive personal information.\n\n​Monitoring Services\n\nRay.io Ray is an open-source unified compute framework that makes it easy to scale AI and Python workloads — from reinforcement learning to deep learning to tuning, and model serving.\nIO Version Control IO Version Control refers to a specific version or release of components within the IO.NET platform, including IO Cloud, IO Worker, or IO SDK. Each version includes updates, bug fixes, and enhancements aimed at improving performance, security, and overall user experience.\nIO Monitor IO Monitor is a tool within the IO.NET ecosystem that enables users to oversee the performance, status, and metrics of their computing resources. This includes monitoring real-time data on GPU utilization, computing efficiency, and possibly financial aspects related to usage and earnings from contributing computing power to the network.\n\n​Supplier\n\nFileCoin Is designed specifically for decentralized storage. It’s a decentralized storage network that enables users to store and retrieve data in a decentralized manner. Users who have excess storage capacity can become storage providers on the Filecoin network. They can offer their storage space to store files for others. (Kind of what we do with GPUs).\nRender Network The Render Network is a blockchain and crypto-enabled platform where users can contribute their unused GPU power to assist in rendering motion graphics and visual effects for projects. In exchange for their contributions, users receive Render tokens (RNDR), the native utility token of the network.\nIO Network IO Network is a sophisticated networking backend that employs a secured mesh VPN to enable ultra-low latency communication among the IO.NET Miner nodes, also known as “workers.”\nWas this page helpful?","tokens":5152,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257252795,"hash":"73f63625d42cae568cbeaf262bb960b959f7c62e"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/run-full-node","domain":"docs.arbitrum.io","title":"How to run a full node for an Arbitrum chain | Arbitrum Docs","text":"✏️Request an updatePrerequisitesThis page assumes that you've completed the steps from the Start here page. If you haven't, you'll need to do so, as it gathers RPC endpoints, Nitro version, database snapshots, and other information required to run the node.To view the short and long term support policy, visit the Nitro support policy page.If you're looking to run a node with a different role — sequencer, batch poster, validator, archive node, or feed relay—see How to assign roles to a Nitro node for the flags that define each role.\nRunning on Kubernetes or want a more reliable setup?This page covers running a node with Docker. If you want to deploy on Kubernetes, or you want a more production-ready setup with monitoring, log signals, and network egress guidance, follow How to run a full node with Helm on Kubernetes instead.\nChoose a state scheme​\nNitro stores its state trie using one of two schemes: HashDB (the default) or PathDB. Choose before you initialize the database. You cannot switch an existing database—moving between schemes means re-initializing from a snapshot built with the scheme you want.\nPropertyHashDB (default)PathDBFlagNone; Nitro uses HashDB by default--execution.caching.state-scheme=pathState trie pruningManual and offline, via --init.pruneAutomatic and onlineBlock validationSupportedNot supportedFull node snapshotpruned, all three DAO-governed chainsfull-path, all three DAO-governed chainsArchive snapshotarchive, all three DAO-governed chainsarchive-path, Arbitrum One and SepoliaDownload with --init.latestSupportedNot supported; use --init.urlMinimum Nitro versionAnyv3.9.x\nBoth schemes have a published full node snapshot, so either one can initialize without syncing from genesis. At comparable dates the two are close in size: on Arbitrum One, the pruned HashDB snapshot is about 2.3 TB and the full-path PathDB snapshot is about 2.4 TB.\nPick based on how you want to handle pruning and whether you need block validation:\n\nChoose HashDB if your node runs the block validator, or if you want the simplest initialization. --init.latest pruned downloads and verifies the snapshot for you. You then prune manually, and your node is offline while it does.\nChoose PathDB if you want to avoid manual prune cycles. Nitro prunes online, so the node keeps serving RPC and disk use stays within the window you set with --execution.caching.state-history. Initialization takes more work: you pass the snapshot URL to --init.url yourself.\n\nOn archive nodes the case for PathDB is stronger, because it cuts disk use substantially. See How to run an archive node.\nPathDB and block validationPathDB cannot validate blocks. If a node requires the block validator, Nitro exits at startup with path cannot be used as execution.caching.state-scheme when validator is required.A default full node is unaffected: it runs the watchtower strategy, which does not require the block validator. Nitro rejects path when you set --node.block-validator.enable=true, choose a staker strategy other than Watchtower, or enable fast confirmation.\nPutting it into practice: run a node​\nCautionIf you are running more than one node, you should run a feed relay.\nPathDB and --init.latest--init.latest accepts only archive, pruned, and genesis, and every snapshot it resolves for those kinds uses HashDB. Adding --execution.caching.state-scheme=path to the examples below fails, because the downloaded snapshot's scheme won't match.PathDB snapshots are published under the separate full-path and archive-path kinds, which --init.latest does not accept. To initialize a PathDB database, pass the snapshot URL to --init.url instead. See PathDB snapshots.\nDocker volume mountTo ensure the database persists across restarts, mount an external volume to /home/user/.arbitrum inside the Docker container. Make sure to:\nCreate the host directory before running Docker (e.g., mkdir -p /some/local/dir/arbitrum), otherwise Docker may create it as root, and the container (which runs as UID 1000) won't be able to write to it.\nIf you encounter permission errors on Linux or macOS, run chmod -fR 777 /some/local/dir/arbitrum on the host directory.\n\nNode config fileIf using a node-config.json file with Docker to mount, use the following command:docker run --rm -it -v /Path/to/mount/arbitrum:/home/user/.arbitrum -v /Path/to/node-config.json:/home/user/.arbitrum/node-config.json -p 0.0.0.0:8450:8450 offchainlabs/nitro-node:v3.12.1-70fa99a --conf.file /home/user/.arbitrum/node-config.json\n\nHere is an example of how to run nitro-node:\n\nArbitrum One, Nova, SepoliaArbitrum chainsdocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url=<Ethereum RPC URL> --parent-chain.blob-client.beacon-url=<Ethereum beacon chain RPC URL> --chain.id=<Arbitrum chain id> --init.latest=pruned --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=*docker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url=<Parent chain RPC URL> --chain.info-json=<Orbit chain's info> --chain.name=<Orbit chain name> --node.feed.input.url=<Sequencer feed url> --execution.forwarding-target=<Sequencer node endpoint url> --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=*\n\nYou can see an example of --chain.info-json in the section above.\n\nNote that it is important that /some/local/dir/arbitrum already exists; otherwise, the directory might be created with root as owner, and the Docker container won't be able to write to it.\n\nNote that if you are running a node for the parent chain (e.g., Ethereum for Arbitrum One or Nova) on localhost, you may need to add --network host right after docker run to use Docker host-based networking\n\nWhen shutting down the Docker image, it is important to allow a graceful shutdown to save the current state to disk. Here is an example of how to do a graceful shutdown of all Docker images currently running\ndocker stop --time=1800 $(docker ps -aq)\n\nImportant ports​\nProtocolDefault portRPC/http8547RPC/websocket8548Sequencer Feed9642\n\nPlease note: the RPC/websocket protocol requires some ports to be enabled, you can use the following flags:\n\n--ws.port=8548\n--ws.addr=0.0.0.0\n--ws.origins=\\*\n\nNote on permissions​\n\nThe Docker image is configured to run as non-root UID 1000. This configuration means if you are running in Linux or OSX and you are getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders:\nmkdir /data/arbitrumchmod -fR 777 /data/arbitrum\n\nWatchtower mode​\n\nBy default, the full node runs in Watchtower mode, meaning that it watches the onchain assertions and, if it disagrees with them, logs an error containing the string found incorrect assertion in watchtower mode. For a BoLD-enabled chain like Arbitrum One or Arbitrum Nova if you are running Nitro before v3.6.0, the --node.bold.enable=true flag should be set to ensure your node can monitor for onchain assertions properly.\nSetting this flag is not required as your node will continue to operate correctly, validate the Arbitrum One/Nova chain, and serve RPC requests as usual, regardless of this flag.\nNote that watchtower mode adds a small amount of execution and memory overhead. You can deactivate this mode using the parameter --node.staker.enable=false.\nFor details on watchtower mode alongside the other validator strategies (defensive, stakeLatest, resolveNodes, makeNodes), see How to run a validator.\n\nPruning​\nPruning removes older, unnecessary state from the local copy of the chain your node maintains. It saves disk space and slightly improves the node's efficiency. How you prune depends on the state scheme you chose.\nOn HashDB, the default, pruning is a manual, opt-in operation. It removes all states from blocks older than the latest 128. You decide when to run it, and the node stops serving RPC requests until it finishes. On a chain the size of Arbitrum One, that can take days.\nOn PathDB, pruning is automatic and runs online. Nitro discards state older than the --execution.caching.state-history window as it goes, so you never schedule a prune and the node never goes offline to run one. Disk use stays within that window instead of growing between manual prunes.\n\nWhen you leave --execution.caching.state-history unset, Nitro chooses the default at startup:\nNode typeDefault state-historyFull node (--execution.caching.archive=false)345,600 blocks — 24 hours at the default 250 ms block speedArchive node (--execution.caching.archive=true)0, meaning the entire chain\nFrom v3.10.0, Nitro derives this default from the archive flag. On earlier versions the default was always 24 hours' worth of blocks, so an archive node needs an explicit --execution.caching.state-history=0.\nnoteThe pruning process occurs when the node starts (upon initialization) and will not serve RPC requests during pruning.\nIf you are using the default storage scheme (HashDB), then you can activate pruning by using the parameter:\n\n--init.prune <pruning mode>, where <pruning mode> can be one of:\n\nminimal: The most aggressive prune and retains only the genesis state and the head state (at the latest snapshot). Takes the least amount of time to complete. Duration depends on the chain and database size (several hours for smaller chains; potentially days for large chains like Arbitrum One).\nfull : Mostly intended for full nodes serving RPC requests, this mode retains the genesis state, the state of the latest confirmed block, and the head state (at the latest snapshot). Will not work if the node is in validator mode. Duration varies significantly by chain and database size—for Arbitrum One, this may take multiple days on NVMe SSDs. For smaller chains, it will be much faster. If pruning takes too long, consider downloading a fresh pruned snapshot with --init.latest pruned instead.\nvalidator: Meant to be used by validator nodes and requires an RPC URL for L1 Ethereum. This mode retains the genesis state, the state of the latest confirmed block, the latest confirmed assertion root (obtained from L1), the last locally validated block root, and the head state (at the latest snapshot). This mode is expected to take longer than full pruning mode. For validator-specific setup details, see How to run a validator.\n\nMemory management​\nUnder heavy RPC load or during operations such as large debug_traceBlockByNumber calls, Nitro nodes can consume significant memory. To prevent out-of-memory (OOM) crashes, consider configuring the following:\n\n--node.resource-mgmt.mem-free-limit: Declines incoming RPC requests when free system memory drops below the specified threshold (e.g., --node.resource-mgmt.mem-free-limit=4GiB). This helps protect the node from OOM under high request load.\nGOMEMLIMIT environment variable: Sets a soft memory limit for the Go runtime garbage collector (e.g., GOMEMLIMIT=48GiB for a 64 GB machine), helping reduce memory spikes.\n\nFor an in-depth breakdown of Nitro's memory allocators, cache tuning, and OOM mitigations, see node tuning and monitoring.\ntipFor Docker deployments, you can set these in your docker run command:docker run ... -e GOMEMLIMIT=48GiB ... offchainlabs/nitro-node:... --node.resource-mgmt.mem-free-limit=4GiB ...\nTransaction prechecker​\n\nEnabling the transaction prechecker will add extra checks before your node forwards eth_sendRawTransaction to the Sequencer endpoint.\nBelow, we list the flags to set up the prechecker:\n\nFlagDescription--execution.tx-pre-checker.strictnessHow strict to be when checking transactions before forwarding them. 0 = accept anything, 10 = should never reject anything that'd succeed, 20 = likely won't reject anything that'd succeed, 30 = full validation which may reject transactions that would succeed (default 20)--execution.tx-pre-checker.required-state-ageHow long ago should the storage conditions from eth_SendRawTransactionConditional be true, 0 = don't check old state (default 2)--execution.tx-pre-checker.required-state-max-blocksMaximum number of blocks to look back while looking for the <required-state-age> seconds old state, 0 = don't limit the search (default 4)\nOptional parameters​\nBelow, we listed the most commonly used parameters when running a node. You can also use the flag --help for a comprehensive list of the available parameters.\n\nFlagDescription--http.apiOffers APIs over the HTTP-RPC interface. Default: net,web3,eth,arb. Add debug for tracing.--http.corsdomainAccepts cross-origin requests from these comma-separated domains (browser enforced).--http.vhostsAccepts requests from these comma-separated virtual hostnames (server enforced). Default: localhost. Accepts *.--http.addrSets the address to bind RPC to. May require 0.0.0.0 for Docker networking.--execution.caching.archiveRetains past block state. For archive nodes.--execution.caching.state-schemeDefault: hash. Sets the scheme Nitro uses to store its state trie, inherited from Geth. Set it to path to enable PathDB, which prunes automatically while the node keeps running. PathDB cannot validate blocks, and --init.latest cannot download its snapshots — use --init.url. See Choose a state scheme.--execution.caching.state-historyPathDB only. Number of recent blocks of state history to retain on disk. Set to 0 to retain the entire chain. When unset, Nitro defaults to 345,600 blocks (24 hours at the default 250 ms block speed) on a full node, or 0 on an archive node.--execution.caching.pathdb-max-diff-layersDefault: 128 layers. Maximum number of diff layers kept in the node's memory before flushing to disk. Increasing the number of diff layers may cause the node to fall behind the chain head during busy periods since doing so slows down block processing speed and reduces sync speed. This configuration is primarily used to improve performance of shallow re-orgs (which are a concern on Ethereum but not on Arbitrum chains) and for efficient access to recent state.--node.feed.input.url=<feed address>Sets the sequencer feed address to this URL. Default: wss://<chainName>.arbitrum.io/feed. ⚠️ One feed relay per datacenter is advised. See feed relay guide.--execution.forwarding-target=<RPC>Sets the sequencer endpoint to forward requests to.--execution.rpc.evm-timeoutDefault: 5s. Timeout for eth_call. (0 == no timeout).--execution.rpc.gas-capDefault: 50000000. Gas cap for eth_call/estimateGas. (0 = no cap).--execution.rpc.tx-fee-capDefault: 1. Transaction fee cap (in ether) for RPC APIs. (0 = no cap).--execution.tx-lookup-limitDefault: 126230400, ~1 year worth of blocks at 250ms/block. Maximum number of blocks from head whose transaction indices are reserved (for example, eth_getTransactionReceipt and eth_getTransactionByHash only return results for indexed transactions). Set to 0 to index transactions for all blocks. Changing this parameter reindexes all missing transactions without the need to resync the chain.--execution.rpc.classic-redirect=<RPC>(Arbitrum One only) Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with archive database.--node.resource-mgmt.mem-free-limitDeclines incoming RPC requests when free system memory (excluding page cache) drops below this threshold. Accepts values with suffixes like 4GiB, 512MiB. Helps prevent OOM crashes under heavy load.--ipc.pathFilename for IPC socket/pipe within datadir. 🔉 Not supported on macOS. The path is within the Docker container.--init.prunePrunes the database before starting the node. Can be \"full\" or \"validator\".--init.url=\"<snapshot file>\"(Required for Arbitrum One) URL to download the genesis database from. Only required for Arbitrum One nodes, when running them for the first time. See the Nitro database snapshots guide for more information.--init.download-path=\"/path/to/dir\"Temporarily saves the downloaded database snapshot. Defaults to /tmp/. Used with --init.url.--init.latestSearches for the latest snapshot of the given kind (accepted values: archive, pruned, genesis)--init.latest-baseBase URL used when searching for the latest snapshot. Example value used for Arb1: https://snapshot.arbitrum.foundation/. Different chains will have different Base URLs, but only if they provide snapshots. Talk to chain owner for value to use.--init.then-quitAllows any --init.* parameters to complete, and then the node automatically quits. It doesn't initiate pruning by itself but works in conjunction with other --init.* parameters, making it easier to script tasks like database backups after initialization processes finish.Choose a state schemePutting it into practice: run a nodeImportant portsNote on permissionsWatchtower modePruningMemory managementTransaction precheckerOptional parameters","tokens":4219,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257260081,"hash":"f9458d6d5a6c0ebf7345c451feeba469da6f2f15"}
{"url":"https://aave.com/docs/vaults/simple-earn/deploy","domain":"aave.com","title":"Deploy Earn Vault | Aave Protocol Documentation","text":"Deploy Aave Earn Vault#\nTo deploy a new Aave Earn Vault, follow these steps:\nVaults deployed through other methods will not be surfaced via Aave Labs' API\nor SDKs.\n1Identify the Reserve#First, determine which reserve you want your vault to be based on.Let's say we choose the WETH supply reserve of an Ethereum market.const reserve: Reserve = { __typename: \"Reserve\", market: { __typename: \"MarketInfo\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, underlyingToken: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, isFrozen: false, isPaused: false, // …};Ensure the reserve is not frozen or paused.2Define Configuration#Next, define the configuration for deploying the vault.The initialLockDeposit is permanently locked in the vault and cannot be withdrawn. It protects against inflation attacks by ensuring the share price cannot be manipulated immediately after deployment — and the protection strengthens as TVL grows.The amount is derived from a TARGET_DONATION: the minimum raw asset units an attacker would need to donate to double the share price at deployment. A higher TARGET_DONATION raises the attack cost. Setting it to 1_000_000 raw units is a conservative default that is cheap for most assets while remaining meaningful.initialLockDeposit = max(TARGET_DONATION / 10^decimals, 1e-9)\n// With TARGET_DONATION = 1_000_000:// USDC (6 dec) → 1 USDC// WETH (18 dec) → 0.000000001 WETHYou can tune TARGET_DONATION upward for higher-value assets or increase it if you want a stronger guarantee at vault launch.ReactTypeScriptGraphQLThe minimal configuration to deploy a vault is:import { bigDecimal, evmAddress, VaultDeployRequest } from \"@aave/react\";\n// …\nconst request: VaultDeployRequest = { market: reserve.market.address, chainId: reserve.market.chain.chainId, underlyingToken: reserve.underlyingToken.address, deployer: evmAddress(walletClient!.account.address), // owner: evmAddress(\"0x1234…\"), if different from deployer initialFee: bigDecimal(0), // 0% performance fee shareName: \"Aave WETH Vault Shares\", shareSymbol: \"avWETH\", initialLockDeposit: bigDecimal(0.000000001), // 0.000000001 WETH — permanently locked};Vaults deployed via Aave Labs' API or SDK can set the performance fee as low as 0%.When a performance fee is set, 50% of that fee is automatically allocated to Aave Labs.When a recipient is not specified, the fee revenue is distributed equally between the vault owner and Aave Labs.Let's explore a more advanced recipient configuration with an example. Suppose you want to deploy a vault where you keep 70% of the fee revenue and share the remaining 30% with your partner.import { bigDecimal, evmAddress, VaultDeployRequest } from \"@aave/react\";\nconst request: VaultDeployRequest = { // … recipients: [ { address: evmAddress(\"0x1234…\"), percent: bigDecimal(30), }, { address: evmAddress(\"0x4567…\"), percent: bigDecimal(70), }, ],};If the vault generates 100 WETH in fee revenue, the distribution will be as follows:partner: 15 WETHowner: 35 WETHAave Labs: 50 WETHSince Aave Labs retains 50% of the total fee revenue by default, the remaining 50% is divided between the owner and partner according to the specified percentages.3Deploy the Vault#Finally, deploy the vault.ReactTypeScriptGraphQLUse the useVaultDeploy and useSendTransaction hooks with the wallet library of your choice to send the transactions.import { useWalletClient } from \"wagmi\";import { errAsync, useVaultDeploy } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deployVault, deploying] = useVaultDeploy();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = deploying.loading || sending.loading;const error = deploying.error || sending.error;\n// …\nconst result = await deployVault(request).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction), );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`), ); }});\nif (result.isErr()) { console.error(\"Vault deployment failed:\", result.error);} else { console.log(\"Vault deployment successful with hash:\", result.value);}PreviousSimple Earn VaultsNextEarn Vault Data","tokens":1146,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257262942,"hash":"991a87eb4713ab25e47acd528d2e7350a4880ee1"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/run-a-node/run-full-node-with-helm","domain":"docs.arbitrum.io","title":"How to run a full node with Helm on Kubernetes | Arbitrum Docs","text":"✏️Request an updateThis guide shows how to deploy a full node for an Arbitrum chain on Kubernetes using the community Helm chart. It applies to any Arbitrum chain—Arbitrum One, Nova, Sepolia, and your own Arbitrum chain—and covers installation, memory configuration, first sync from a snapshot, monitoring, the log signals that distinguish a healthy node from a broken one, and the outbound endpoints to allow through a firewall.\nThe chart's defaults target Arbitrum One, so Arbitrum One is used as the worked example throughout. Each step notes what changes for other chains.\nInfoIf you want to run a node with Docker instead of Kubernetes, see How to run a full node for an Arbitrum chain. This page assumes you've reviewed the Start here page, which explains the RPC endpoints, Nitro version, and database snapshots required to run a node.\nPrerequisites​\n\nParent chain access: an execution RPC endpoint for the chain's parent. For Arbitrum One, Nova, and Sepolia, the parent is Ethereum, so you also need an L1 beacon/blob endpoint (see L1 Ethereum RPC providers). For an Arbitrum chain whose parent is another chain, use the RPC of that parent chain; a beacon endpoint is required only when the chain posts blobs to its parent chain.\nCluster: Kubernetes with Helm installed.\nDisk: size storage for the chain you're running. A node's database size varies widely from chain to chain and grows over time, so check the expected size with your chain operator before provisioning (for Arbitrum One, it runs to multiple TB). Raise the chart's default persistence.size (500Gi) accordingly, and allow roughly 2× the snapshot size for an additional temporary disk for extraction on the first run.\n\nStep 1: Deploy with Helm​\nFirst, add the chart repo:\nhelm repo add offchainlabs https://charts.arbitrum.iohelm repo update\nThen install, selecting the configuration for your chain:\nArbitrum One, Nova, SepoliaYour Arbitrum chainThe chart defaults to Arbitrum One (chain.id 42161, parent-chain.id 1), so an Arbitrum One node needs only three values:# Arbitrum Onehelm install arb1-fullnode offchainlabs/nitro \\ --set configmap.data.parent-chain.connection.url=<ETH_L1_RPC_URL> \\ --set configmap.data.parent-chain.blob-client.beacon-url=<L1_BEACON_URL> \\ --set configmap.data.init.latest=pruned # pruned snapshot, recommended for Arbitrum OneFor Nova or Sepolia, override the chain and parent-chain IDs. For example, Arbitrum Sepolia:# Arbitrum Sepolia (parent chain is Ethereum Sepolia, 11155111)helm install arbsepolia-fullnode offchainlabs/nitro \\ --set configmap.data.parent-chain.id=11155111 \\ --set configmap.data.parent-chain.connection.url=<SEPOLIA_RPC_URL> \\ --set configmap.data.parent-chain.blob-client.beacon-url=<CONSENSUS_API_URL> \\ --set configmap.data.chain.id=421614A node for your own Arbitrum chain needs its chain info, sequencer endpoint, and feed URL. Because chain.info-json is a large JSON string, supply these through a values file rather than --set:# values-mychain.yamlconfigmap: data: parent-chain: id: <PARENT_CHAIN_ID> connection: url: <PARENT_CHAIN_RPC_URL> chain: id: <YOUR_CHAIN_ID> name: <YOUR_CHAIN_NAME> info-json: '<your chain info JSON>' execution: forwarding-target: <SEQUENCER_ENDPOINT_URL> node: feed: input: url: <SEQUENCER_FEED_URL>helm install mychain-fullnode offchainlabs/nitro -f values-mychain.yamlIf the parent chain is Ethereum, also set configmap.data.parent-chain.blob-client.beacon-url. AnyTrust chains additionally need a Data Availability configuration (node.da.anytrust.*, including a rest-aggregator); see Data Availability. The older node.data-availability.* flags still work but are deprecated in Nitro and will be removed in a future release.\nDefaults that commonly trip up operators\nDon't copy the chart README's init example verbatim. It uses nitro-genesis.tar, which syncs from genesis — a huge, slow process on a chain with a long history, such as Arbitrum One. Where a pruned snapshot exists, prefer configmap.data.init.latest=pruned (default base https://snapshot.arbitrum.foundation/).\nThe chart changes the RPC path prefix. Defaults are http.rpcprefix=/rpc and ws.rpcprefix=/ws, so RPC is served at http://host:8547/rpc, not vanilla Nitro's /. Clients that omit /rpc get a 404.\nMetrics are off by default. Enable configmap.data.metrics=true and serviceMonitor.enabled=true to scrape them (see Step 4).\n\nStep 2: Configure memory management (optional)​\nFor a containerized node, set a memory limit so the chart can size the Go runtime. This is optional but recommended, and applies to every chain:\n\nresources.limits.memory set this to activate the chart's automatic GOMEMLIMIT. When a memory limit is present, the chart derives GOMEMLIMIT from it (env.nitro.goMemLimit, on by default—it subtracts an estimate of non-Go memory and applies a 0.9 multiplier).\nMALLOC_ARENA_MAX=2 already set by the chart by default (env.nitro.mallocArenaMax, enabled: true, value: 2), so you don't normally need to configure it. Adjust or disable it under env.nitro.mallocArenaMax if needed.\nnode.resource-mgmt.mem-free-limit (optional) an RPC memory throttle that's disabled by default. Recommended if you expose this node as a public RPC.\n\nTo set any other environment variable, use extraEnv, whose entries are spliced directly into the pod's env:\nextraEnv: - name: SOME_VAR value: 'value'\nFor the allocator details, the GOMEMLIMIT formula, and MALLOC_ARENA_MAX, see the memory management deep-dive and the memory management section of the Docker full-node guide.\nStep 3: First sync from a snapshot​\nWhether a snapshot is required depends on the chain:\n\nArbitrum One requires a snapshot during the first run due to its Classic-era history. Use configmap.data.init.latest=pruned.\nNova and Sepolia have published snapshots that speed up the initial sync but aren't strictly required.\nYour Arbitrum chain typically syncs from genesis with no snapshot, unless you provide one via init.url.\n\nWhen using a snapshot, the default base is https://snapshot.arbitrum.foundation/. Initial sync takes a while. The init flag is ignored once a database already exists, so it's safe to leave it in place across restarts. Confirm the current snapshot type and download details in the Nitro database snapshots guide.\nStep 4: Enable monitoring​\nTurn on metrics and a ServiceMonitor so Prometheus can scrape the node:\nhelm upgrade <my-release> offchainlabs/nitro \\ --reuse-values \\ --set configmap.data.metrics=true \\ --set serviceMonitor.enabled=true\nOnce enabled, the node exposes Prometheus metrics at http://<pod>:6070/debug/metrics/prometheus—the metrics server binds to 0.0.0.0:6070 by default (configmap.data.metrics-server.port), and the ServiceMonitor scrapes that port and path (serviceMonitor.path defaults to /debug/metrics/prometheus).\nGrafana dashboard​\nThe repository’s README points to the Grafana dashboard's Releases page. If a release doesn't attach the dashboard JSON, pull the last published copy from the repository's git history and import it:\ngit clone https://github.com/OffchainLabs/community-helm-chartsgit -C community-helm-charts show 430a2cc~1:operations/grafana/dashboards/overview.json > overview.json\nThen in Grafana, go to Dashboards → Import and paste overview.json.\nCautionThis exported dashboard has no __inputs datasource prompt, and its Source variable is hard-pinned to an internal Mimir UID. After importing, you must repoint the Source variable to your own Prometheus instance, or every panel will read \"No data.\" Then set nitronodejob to this node's scrape job, and leave sequencerjob, validatorjob, and relayjob empty so only the full-node rows render.\nProbes​\nThe chart wires a built-in startup probe by default, but liveness and readiness probes are off unless you set livenessProbe and readinessProbe. The startup probe's long failure window protects the initial sync (so a slow sync won't trigger a restart), but it doesn't catch a hang after the node is up. Configure a liveness probe yourself for ongoing hang detection.\nLog signals to watch​\nThe chart sets log-type=json. The following INFO/WARN/ERROR strings distinguish a healthy node from a broken one on any Arbitrum chain (the sequencer hostnames in the examples below are Arbitrum One's; your chain's will differ):\nEventHealthy signalBroken / warning signalNew block createdINFO created block with l2Block / l2BlockHash, advancing continuously while producingNo advancing created block line → block production stalledUser tx forwarded to sequencerSuccess is not loggedWARN error forwarding transaction trying different target; ERROR Failed to publish transaction to any of the forwarding targetsSequencer feed messageINFO Feed connected; DEBUG received batch itemWARN failed connect to sequencer broadcast, waiting and retrying; ERROR Server connection timed out without receiving dataInbox messages (parent chain)INFO InboxTracker with sequencerBatchCount / messageCount / l1Block advancingWARN error reading inbox. Note: backwards reorg of delayed messages is logged at INFO level—it's normal on parent-chain reorgs, not an alert.\nWhy a full node can't forward transactions to the sequencer​\nA full node forwards user transactions to the sequencer. When forwarding fails, the cause falls into one of three buckets. Forwarding failures are log-based, not metric-based—the forwarder emits no metrics—so alert by grepping the log strings below.\nCauseSignalAll forwarding targets unreachable (egress blocked, or sequencer + all fallbacks down)ERROR Failed to publish transaction to any of the forwarding targets, preceded by per-target WARN linesSequencer returns a business error (non-connection, e.g. nonce too low)WARN error forwarding transaction trying different target with the sequencer's err—not escalated; the error is returned to the callerMemory 429 throttling (rejected before forwarding)The client receives HTTP 429 Too many requests and the metric arb/rpc/limitcheck/failure increments. There is no per-request log line.\nRepresentative log lines (hostnames shown are Arbitrum One's):\n# (a) ALL TARGETS UNREACHABLE — egress blocked, or sequencer + all fallbacks downWARN error forwarding transaction trying different target current target=https://arb1-sequencer.arbitrum.io/rpc err=\"dial tcp: lookup ...: no such host\"WARN error forwarding transaction to a backup target target=https://arb1-sequencer-fallback-1.arbitrum.io/rpc pos=1 total targets=6 err=\"timeout exceeded\"ERROR Failed to publish transaction to any of the forwarding targets numTargets=6# (b) SEQUENCER RETURNS A BUSINESS ERROR (non-connection) — logged once, NOT escalated, returned to callerWARN error forwarding transaction trying different target current target=https://arb1-sequencer.arbitrum.io/rpc err=\"nonce too low: address 0x..., tx: 5 state: 7\"# (no \"Failed to publish...\" line follows — the error is handed straight back to the RPC client)# (c) MEMORY 429 THROTTLING — rejected BEFORE it reaches the forwarder; no per-request log line.# The signals are an HTTP 429 to the client and an increment of arb/rpc/limitcheck/failure.INFO Cgroups v2 detected, enabling memory limit RPC throttling # startup, confirms throttling is activeERROR Error checking memory limit err=... checker=CgroupsMemoryLimitChecker # only if the cgroup read fails\nNetwork egress allowlist​\nA full node reaches out to a fixed set of endpoints. If you run on a cloud provider, outbound traffic is often restricted by default, so you'll likely need to allow these destinations explicitly in your cloud security group or firewall rules (for example, AWS security groups, GCP firewall rules, or an egress NetworkPolicy). The specific hostnames depend on the chain: for DAO-governed networks, they come from the chain's built-in chain info, and for your own Arbitrum chain, they come from the chain.info-json, execution.forwarding-target, and feed URLs you configure. The categories are the same across chains:\nPurposeWhere the endpoint comes fromWhenSequencer (tx forwarding)chain info sequencer-url / execution.forwarding-targetAlways—the node forwards user txs hereSequencer fallbackschain info secondary-forwarding-targetFailoverSequencer feedchain info feed-url / node.feed.input.urlAlwaysFeed fallbacks / delayedchain info secondary-feed-url / node.feed.input.secondary-urlFailoverBlock metadatachain info block-metadata-urlOnly if tracking block metadata / TimeboostDB snapshotthe init source hostInitial sync onlyParent chainyour parent-chain RPC + beacon (beacon only for an Ethereum parent)AlwaysDA / REST endpointsrest-aggregator URL listAnyTrust chains only (e.g. Nova)\nFor Arbitrum One, those resolve to:\nPurposeEndpoint(s)Sequencer (tx forwarding)https://arb1-sequencer.arbitrum.io/rpcSequencer fallbackshttps://arb1-sequencer-fallback-{1..5}.arbitrum.io/rpcSequencer feed (primary)wss://arb1-feed.arbitrum.io/feedFeed fallbacks / delayedwss://arb1-delayed-feed.arbitrum.io/feed, wss://arb1-feed-fallback-{1..5}.arbitrum.io/feedBlock metadatahttps://arb1.arbitrum.io/rpcDB snapshothttps://snapshot.arbitrum.foundation/Parent chainYour Ethereum L1 execution RPC + L1 beacon/blob endpoint\nFirewall egressFor a default Arbitrum One full node, allow *.arbitrum.io (443 HTTPS + WSS), snapshot.arbitrum.foundation (443, init only), and your own L1 RPC + beacon hosts. For other chains, allow that chain's sequencer, feed, and snapshot hosts, plus your parent-chain endpoints. Additional outbound paths exist only if you enable them: the version alerter (off by default, queries an operator-set endpoint), the classic redirect, or DA/REST endpoints (AnyTrust chains such as Nova).PrerequisitesStep 1: Deploy with HelmStep 2: Configure memory management (optional)Step 3: First sync from a snapshotStep 4: Enable monitoringGrafana dashboardProbesLog signals to watchWhy a full node can't forward transactions to the sequencerNetwork egress allowlist","tokens":3459,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257270267,"hash":"0708b0055f923709d4196279e54bc367efae2805"}
{"url":"https://aave.com/docs/vaults/simple-earn/operations","domain":"aave.com","title":"Earn Vault Operations | Aave Protocol Documentation","text":"Aave Earn Vault Operations#\nExecute core vault operations such as deposits and withdrawals. Users can choose to interact with the vault using either the asset amount deposited or the vault shares minted.\nAt the time of deposit, shares are issued at a 1:1 ratio to the assets deposited. Over time, as the vault earns interest, each share represents an increasing amount of underlying tokens.\nDeposit Assets#\nDepositing assets into an Aave Earn Vault gives the user an amount of vault shares.\nTo deposit assets into an Aave Earn Vault, follow these steps.\n1Identify the Vault#First, determine which vault you want to deposit assets into.Let's say we have identified the following vault object:const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { __typename: \"Reserve\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, isFrozen: false, isPaused: false, // … }, // …};Ensure the underlying reserve is not frozen or paused.2Preview the Deposit#Next, preview the deposit operation to determine the amount of vault shares that would be received for a given amount of assets.ReactTypeScriptGraphQLUse the useVaultDepositPreview hook to preview the deposit operation.import { useVaultDepositPreview } from \"@aave/react\";\n// …\nconst [preview /* , { loading, error } */] = useVaultDepositPreview();\n// …\nconst result = await preview({ vault: vault.address, chainId: vault.chainId, amount: bigDecimal(1000), // 1000 USDC});\n// …\nif (result.isErr()) { console.error(result.error);} else { // result.value: TokenAmount console.log(result.value.value); // 1000}3Prepare the Execution Plan#Next, create the execution plan for the deposit operation.By default, the vault's underlying asset will be deposited. To deposit the\naToken instead, set the asAToken parameter to true.ReactTypeScriptGraphQLUse the useVaultDeposit hook to create the execution plan for depositing assets into a vault.import { useWalletClient } from \"wagmi\";import { useVaultDeposit, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deposit, depositing] = useVaultDeposit();\nconst execute = async () => { const result = await deposit({ chainId: vault.chainId, vault: vault.address, amount: { value: bigDecimal(1000), // 1000 USDC // Optional: If set to true, the aToken associated with the vault will be deposited // asAToken: false (default) }, depositor: evmAddress(walletClient!.account.address), });\n // …};4Process the Execution Plan#Finally, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useVaultDeposit } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deposit, depositing] = useVaultDeposit();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\nconst loading = depositing.loading || sending.loading;const error = depositing.error || sending.error;\n// …\nconst execute = async () => { const result = await deposit({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Deposit failed:\", result.error); } else { console.log(\"Deposit successful with hash:\", result.value); }};\nMint Vault Shares#\nMinting vault shares is the process of creating new vault shares by depositing assets into the vault.\nTo mint vault shares, follow these steps.\n1Identify the Vault#First, determine which vault you want to mint shares for and the exact amount of shares to mint.Let's say we want to mint 1000 vault shares from our identified vault object.const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { __typename: \"Reserve\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, isFrozen: false, isPaused: false, // … }, // …};Ensure the underlying reserve is not frozen or paused.2Preview the Mint#Next, preview the mint operation to determine the amount of assets needed to mint the requested amount of vault shares.ReactTypeScriptGraphQLUse the useVaultMintPreview hook to preview the mint operation.import { useVaultMintPreview } from \"@aave/react\";\n// …\nconst [preview /* , { loading, error } */] = useVaultMintPreview();\n// …\nconst result = await preview({ vault: vault.address, chainId: vault.chainId, amount: bigDecimal(1000), // 1000 vault shares});\n// …\nif (result.isErr()) { console.error(result.error);} else { // result.value: TokenAmount console.log(result.value.value); // 1025.5 (example: assets needed)}3Prepare the Execution Plan#Next, create the execution plan for the mint shares operation.ReactTypeScriptGraphQLUse the useVaultMintShares hook to create the execution plan for minting vault shares directly.import { useWalletClient } from \"wagmi\";import { useVaultMintShares, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [mintShares, minting] = useVaultMintShares();\nconst execute = async () => { const result = await mintShares({ chainId: vault.chainId, vault: vault.address, shares: { amount: bigDecimal(1000), // 1000 vault shares }, minter: evmAddress(walletClient!.account.address), // sharesRecipient: evmAddress(\"0x1234…\"), if different from minter });\n // …};4Process the Execution Plan#Finally, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useVaultMintShares } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [mintShares, minting] = useVaultMintShares();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\nconst loading = minting.loading || sending.loading;const error = minting.error || sending.error;\n// …\nconst execute = async () => { const result = await mintShares({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Mint shares failed:\", result.error); } else { console.log(\"Mint shares successful with hash:\", result.value); }};\nWithdraw Assets#\nWithdrawing assets from an Aave Earn Vault gives the user an amount of assets. The corresponding amount of vault shares is burned.\nTo withdraw assets from an Aave Earn Vault, follow these steps.\n1Identify the User Vault Position#First, determine which user vault position you want to withdraw assets from.Let's say we have identified a user vault position with the following details:const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { __typename: \"Reserve\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, isFrozen: false, isPaused: false, // … }, userShares: { __typename: \"UserVaultShares\", shares: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1000.0\", // User has 1000 vault shares // … }, // … }, // … }, // …};Make sure you include a user address when fetching market and reserve\ndata—otherwise Vault.userShares will be empty.Ensure the underlying reserve is not frozen or paused.2Preview the Withdraw#Next, preview the withdraw operation to determine the amount of shares that will be burned for a given amount of assets.ReactTypeScriptGraphQLUse the useVaultWithdrawPreview hook to preview the withdraw operation.import { useVaultWithdrawPreview } from \"@aave/react\";\n// …\nconst [preview /* , { loading, error } */] = useVaultWithdrawPreview();\n// …\nconst result = await preview({ vault: vault.address, chainId: vault.chainId, amount: bigDecimal(1000), // 1000 USDC});\n// …\nif (result.isErr()) { console.error(result.error);} else { // result.value: TokenAmount console.log(result.value.value); // 1000 (shares to burn)}3Prepare the Transaction Request#Next, create the transaction request for the withdrawal operation.By default, the vault's underlying asset will be withdrawn. To withdraw the\naToken instead, set the asAToken parameter to true.ReactTypeScriptGraphQLUse the useVaultWithdraw hook to create the transaction request for withdrawing assets from a vault.import { useWalletClient } from \"wagmi\";import { useVaultWithdraw, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useVaultWithdraw();\nconst execute = async () => { const result = await withdraw({ chainId: vault.chainId, vault: vault.address, amount: { value: bigDecimal(500), // 500 USDC // Optional: If set to true, the aToken associated with the vault will be withdrawn // asAToken: false (default) }, sharesOwner: evmAddress(walletClient!.account.address), // recipient: evmAddress(\"0x1234…\"), if different from sharesOwner });\n // …};4Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useVaultWithdraw } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useVaultWithdraw();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = withdrawing.loading || sending.loading;const error = withdrawing.error || sending.error;\n// …\nconst execute = async () => { const result = await withdraw({ // … }).andThen(sendTransaction);\n if (result.isErr()) { console.error(\"Withdrawal failed:\", result.error); } else { console.log(\"Withdrawal successful with hash:\", result.value); }};\nRedeem Vault Shares#\nRedeeming vault shares is the process of burning vault shares and receiving the underlying assets.\nTo redeem vault shares, follow these steps.\n1Identify the User Vault Position#First, determine which user vault position you want to redeem shares from.Let's say we have identified a user vault position with the following details:const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { __typename: \"Reserve\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, isFrozen: false, isPaused: false, // … }, userShares: { __typename: \"UserVaultShares\", shares: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1000.0\", // User has 1000 vault shares // … }, // … }, // … }, // …};Make sure you include a user address when fetching market and reserve\ndata—otherwise Vault.userShares will be empty.Ensure the underlying reserve is not frozen or paused.2Preview the Redeem#Next, preview the redeem operation to determine the amount of assets that will be received for a given amount of shares burned.ReactTypeScriptGraphQLUse the useVaultRedeemPreview hook to preview the redeem operation.import { useVaultRedeemPreview } from \"@aave/react\";\n// …\nconst [preview /* , { loading, error } */] = useVaultRedeemPreview();\n// …\nconst result = await preview({ vault: vault.address, chainId: vault.chainId, amount: bigDecimal(1000), // 1000 vault shares});\n// …\nif (result.isErr()) { console.error(result.error);} else { // result.value: TokenAmount console.log(result.value.value); // 1000 (assets to receive)}3Prepare the Transaction Request#Next, create the transaction request for the redeem operation.ReactTypeScriptGraphQLUse the useVaultRedeemShares hook to create the transaction request for redeeming vault shares.import { useWalletClient } from \"wagmi\";import { useVaultRedeemShares, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [redeemShares, redeeming] = useVaultRedeemShares();\nconst execute = async () => { const result = await redeemShares({ chainId: vault.chainId, vault: vault.address, shares: { amount: bigDecimal(1000), // 1000 vault shares }, sharesOwner: evmAddress(walletClient!.account.address), // recipient: evmAddress(\"0x1234…\"), if different from sharesOwner });\n // …};4Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useVaultRedeemShares } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [redeemShares, redeeming] = useVaultRedeemShares();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = redeeming.loading || sending.loading;const error = redeeming.error || sending.error;\n// …\nconst execute = async () => { const result = await redeemShares({ // … }).andThen(sendTransaction);\n if (result.isErr()) { console.error(\"Redeem shares failed:\", result.error); } else { console.log(\"Redeem shares successful with hash:\", result.value); }};PreviousEarn Vault DataNextEarn Vault Management","tokens":3600,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257273107,"hash":"6b0475b714893034fb2f7e53f42dc148fde34844"}
{"url":"https://io.net/docs/guides/architecture/io-network","domain":"io.net","title":"IO Network - io.net","text":"IO Network is a cutting-edge networking backend that utilizes a secured mesh VPN to allow ultra-low latency communication between the antMiners nodes or ‘workers’.\n\n​Understanding Mesh VPN Networks\nA Mesh VPN network is a type of virtual private network (VPN) that connects nodes in a non-hierarchical, decentralized manner. Unlike traditional hub-and-spoke VPN architectures, which rely on a central concentrator or gateway, mesh VPN networks allow each node to connect directly to every other node in the network. This structure ensures data packets can travel along multiple paths, increasing redundancy, fault tolerance, and better load distribution.\nMesh VPN\nHub-and-spoke VPN ( legacy - slow )\n​Advantages of Mesh VPN networks:\n\nRobust: Mesh networks are resilient to individual node failures, as there are multiple paths for data to travel. This redundancy ensures that the network remains operational when one or more nodes experience issues.\nScalability: Adding new nodes to a mesh network does not significantly impact the overall network performance, making it easy to expand the network as needed.\nLow Latency: By connecting nodes directly, mesh networks reduce the number of hops needed for data to travel between nodes. This reduction in latency enhances the performance of real-time applications and distributed computing.\nOptimized Load Distribution: Mesh networks distribute traffic more evenly across nodes, preventing bottlenecks and ensuring optimal performance.\n\n​Implementation of the io.net Network\nWe built an io.net network that creates an efficient, resilient, and scalable networking backend. By adopting mesh networking principles, io.net delivers the following benefits to its users:\n\nEnhanced Performance: io.net’s mesh network architecture minimizes latency by allowing data to travel along the most efficient paths, optimizing application performance and user experience.\nImproved Resilience: The decentralized nature of io.net’s mesh network ensures that it remains operational even when individual nodes fail. This resilience translates to increased reliability and uptime for users.\nSeamless Scalability: io.net’s mesh network can easily grow to accommodate more nodes as the user base expands, ensuring consistent performance and adaptability.\nDistributed Computing: By allowing direct connections between nodes, io.net’s mesh network facilitates efficient distributed computing, which enables resource sharing and collaborative processing across the network.\n\n​Decentralized Architecture and Privacy\nThe decentralized nature of mesh VPN networks contributes to their security and privacy. Some notable aspects include:\n\nNo Single Points of Failure: The absence of a central concentrator or gateway in mesh VPN networks eliminates the risk of a single point of failure, ensuring that the network remains operational even if individual nodes are compromised or experience issues.\nAnonymity: Since data travels along multiple paths within the mesh network, it becomes more difficult for an attacker to trace the origin or destination of the data, enhancing privacy for users.\nTraffic Obfuscation: Mesh VPN networks can employ techniques like packet padding and timing obfuscation to make it harder for eavesdroppers to analyze traffic patterns and identify specific users or data streams.\n\n​Network Access Control and Monitoring\nNext for io.net Network includes:\n\nAccess Control Lists (ACLs): Nodes must define and enforce ACLs to restrict communication between specific nodes or groups of nodes, ensuring that sensitive data is only accessible to authorized parties and only available during the time they are hired for a specific cluster.\nRegular Auditing and Logging: To maintain security and compliance, the io.net mesh VPN must be configured to allow us to perform regular audits and maintain logs of network activities, enabling administrators to identify and address potential vulnerabilities or breaches.\nWas this page helpful?","tokens":992,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257273137,"hash":"0ca3cd7770d3bf1df157178820e18096de65f01d"}
{"url":"https://ethresear.ch/latest","domain":"ethresear.ch","title":"Ethereum Research","text":"All latest topics\n\n categories\n\n tags\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Read this before posting\n\n Administrivia\n\n This is a semi-public forum for participating in Ethereum’s research efforts, including but not limited to: \n\nProof-of-Stake\nPost Quantum\nZero-Knowledge work\nScaling solutions\nEVM improvements\nLow-level protocol improvem…\n\n read more\n\n 13\n\n 61.5k\n\n Aug 19\n\n Accountability for Encrypted Mempools\n\n Cryptography\n\n mev,censorship-resistance\n\n 0\n\n 78\n\n 14h\n\n Mempool Account Transaction Capacity from Historical Activity (MATCHA)\n\n Execution Layer Research\n\n account-abstraction,transaction-privacy\n\n 11\n\n 539\n\n 18h\n\n Proposal for a minimal compute-anchored purchasing power signal\n\n Economics\n\n 0\n\n 53\n\n 3d\n\n Six defects in one signature verification tool, found from outside in six rounds\n\n Security\n\n 0\n\n 49\n\n 3d\n\n The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\n\n Execution Layer Research\n\n stateless\n\n 10\n\n 782\n\n 4d\n\n Staking rewards as venture capital, governed by futarchy\n\n Economics\n\n dao,futarchy\n\n 2\n\n 214\n\n 4d\n\n Trust minimized transaction simulation using state proofs\n\n Security\n\n 7\n\n 632\n\n 5d\n\n PQ anonymity for Stealth Address Protocol\n\n Privacy\n\n 4\n\n 208\n\n 5d\n\n Letting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559\n\n Economics\n\n mev,proposer-builder-separation,fee-market,eip-1559\n\n 1\n\n 148\n\n 6d\n\n Towards Encrypted Mempools from Threshold IBE without Batching\n\n Cryptography\n\n 4\n\n 234\n\n 6d\n\n Ethereum’s TCB, Part 1: The client\n\n Security\n\n security\n\n 3\n\n 347\n\n 7d\n\n PQ spending for Stealth Address Protocol\n\n 0\n\n 63\n\n 8d\n\n Ethereum lessons from a live end-to-end PQ proof-native protocol\n\n Architecture\n\n post-quantum,zero-knowledge\n\n 6\n\n 411\n\n 8d\n\n Formal Verification of Execution and Consensus Clients\n\n Security\n\n security\n\n 12\n\n 599\n\n 11d\n\n Snappy with a memory: ~40% less gossip traffic\n\n Networking\n\n single-slot-finality\n\n 1\n\n 150\n\n 11d\n\n Capacity oracles\n\n Economics\n\n 4\n\n 410\n\n 11d\n\n Designs for EVM gas accounting in EIP-7999\n\n Execution Layer Research\n\n fee-market\n\n 6\n\n 462\n\n 11d\n\n Proprietary AMMs and Ethereum\n\n Execution Layer Research\n\n mev\n\n 13\n\n 1.3k\n\n 12d\n\n CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\n\n Execution Layer Research\n\n p2p,networking\n\n 0\n\n 106\n\n 12d\n\n Post-Poseidon: Hash Function Variants for Ethereum\n\n Cryptography\n\n 0\n\n 311\n\n 13d\n\n EIP-8411 payload segmentation under the Shadow simulator\n\n Networking\n\n p2p,scaling\n\n 0\n\n 79\n\n 13d\n\n Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers\n\n Cryptography\n\n post-quantum\n\n 1\n\n 179\n\n 14d\n\n Etheorem update: the complete executable consensus specs written in Lean 4\n\n Consensus\n\n 0\n\n 190\n\n 15d\n\n Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\n\n Economics\n\n 0\n\n 147\n\n 15d\n\n Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\n\n Privacy\n\n 0\n\n 53\n\n 17d\n\n Cryptographic canaries and backups\n\n Cryptography\n\n 8\n\n 7.6k\n\n 18d\n\n Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter\n\n Execution Layer Research\n\n 1\n\n 131\n\n 18d\n\n Bounding Collusion in Capital Allocation DAOs via Subjective Human Oracles\n\n Economics\n\n public-good,dao,collusion\n\n 4\n\n 157\n\n 18d\n\n How Hegotá can influence the state roadmap\n\n Execution Layer Research\n\n 1\n\n 218\n\n 19d","tokens":874,"squid":"ink-research","role":"Deep Scholar","at":1791257282526,"hash":"69c43d1cfe367d8008d10df8ba844d70f1d0cebd"}
{"url":"https://www.anchor-lang.com/docs","domain":"anchor-lang.com","title":"Introduction","text":"IntroductionAnchor is a development framework for building secure Solana programs (smart contracts)Anchor is the leading development framework for building Solana programs (smart\ncontracts) and simplifies the process of writing, testing, deploying, and\ninteracting with Solana programs.\nThe Anchor framework helps developers build production-ready applications faster\nwhile reducing potential vulnerabilities through built-in security features.\nWhere to start?\nInstallationStep-by-step guide to install Anchor framework. Set up your local development\nenvironment.QuickstartQuickstart guide to start building Solana programs with Anchor. Start building\ndirectly in your browser. No installation required.On this pageWhere to start?Edit on GitHub","tokens":186,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257287210,"hash":"dc160c1b50ce5e040b58320385b12640a82b4db1"}
{"url":"https://blog.openzeppelin.com/","domain":"blog.openzeppelin.com","title":"News | OpenZeppelin","text":"News from OpenZeppelinSearch articlesNewest to oldestOldest to newestAlphabetical: A–ZAlphabetical: Z–ACACEIS EURXT Smart Contract Security AuditSecurity AuditsOctober 2, 2026OpenZeppelin and T-REX Network Rebuild ONCHAINID as a Smart Account for Regulated AssetsProduct Releases & ServicesSeptember 30, 2026Uniswap Token Launcher AuditSecurity AuditsSeptember 29, 2026ONCHAINID AuditSecurity AuditsSeptember 29, 2026OpenZeppelin Brings Its Security Standard to the TRON NetworkProduct Releases & ServicesSeptember 24, 2026If You’re Regulated Under MiCA, You’re Also Regulated Under DORASecurity InsightsSeptember 23, 2026S&P Global Enters Agreement to Acquire OpenZeppelinCompanySeptember 17, 2026TRON Foundation Library and Upgradeable Contracts AuditSecurity AuditsSeptember 17, 2026From Algebra to Noise: Why Post-Quantum Cryptography Looks DifferentSecurity InsightsSeptember 14, 2026Introducing RWA Wizard: Issue Regulated Real-World Assets on StellarProduct Releases & ServicesAugust 27, 2026Miden Smart Contracts AuditSecurity AuditsAugust 26, 2026OpenZeppelin and Pacific Meta Partner to Bring Institutional-Grade Onchain Security to JapanCompanyAugust 26, 2026Subscribe to The Onchain BriefMonthly insights for institutional onchain teams: what's moving in security, regulation, and market structure, and what it means for your program.","tokens":337,"squid":"ink-security_audits","role":"Sentinel","at":1791257289874,"hash":"ef147262747102446f5760c5c29c5741a12736b7"}
{"url":"https://www.anchor-lang.com/docs/installation","domain":"anchor-lang.com","title":"Installation","text":"InstallationLearn how to install Rust, the Solana CLI, and Anchor Framework on Windows (WSL), Linux, or Mac.This section covers the steps to set up your local environment for Solana\ndevelopment.\nQuick Installation\nOn Mac and Linux, run this single command to install all dependencies.\nTerminalcurl --proto '=https' --tlsv1.2 -sSfL https://solana-install.solana.workers.dev | bash\nWindows Users: You must first install WSL (see Install\nDependencies). Then run the command above in the\nUbuntu (Linux) terminal.\nAfter installation, you should see output similar to the following:\nInstalled Versions:\nRust: rustc 1.85.0 (4d91de4e4 2025-02-17)\nSolana CLI: solana-cli 4.1.2 (src:182084b8; feat:c763ae0a, client:Agave)\nAnchor CLI: anchor-cli 1.2.0\nNode.js: v23.9.0\nYarn: 1.22.1\n\nInstallation complete. Please restart your terminal to apply all changes.\nIf the quick installation command above doesn't work, please refer to the\nInstall Dependencies section below for instructions to\ninstall each dependency individually.If the quick install command runs successfully, skip to the\nSolana CLI Basics and\nAnchor CLI Basics sections below.\nInstall Dependencies\nThe instructions below will guide you through installing each dependency\nindividually.\n\nWindows users must first install WSL (Windows subsystem for Linux) and then\ninstall the dependencies specified in the Linux section below.\nLinux users should first install the dependencies specified in the Linux\nsection below.\nMac users should start with the Rust installation instructions below.\n\nInstall RustSolana programs are written in the\nRust programming language.The recommended installation method for Rust is\nrustup.Run the following command to install Rust:Terminalcurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -yYou should see the following message after the installation completes:Run the following command to reload your PATH environment variable to include\nCargo's bin directory:Terminal. \"$HOME/.cargo/env\"To verify that the installation was successful, check the Rust version:Terminalrustc --versionYou should see output similar to the following:rustc 1.84.1 (e71f9a9a9 2025-01-27)Install the Solana CLIThe Solana CLI provides all the tools required to build and deploy Solana\nprograms.Install the Solana CLI tool suite using the official install command:Terminalsh -c \"$(curl -sSfL https://release.anza.xyz/stable/install)\"You can replace stable with the release tag matching the software version of\nyour desired release (i.e. v2.0.3), or use one of the three symbolic channel\nnames: stable, beta, or edge.If it is your first time installing the Solana CLI, you may see the following\nmessage prompting you to add a PATH environment variable:Close and reopen your terminal to apply the PATH changes or run the following in your existing shell:\n\nexport PATH=\"/Users/test/.local/share/solana/install/active_release/bin:$PATH\"If you are using a Linux or WSL terminal, you can add the PATH environment\nvariable to your shell configuration file by running the command logged from the\ninstallation or by restarting your terminal.Terminalexport PATH=\"$HOME/.local/share/solana/install/active_release/bin:$PATH\"To verify that the installation was successful, check the Solana CLI version:Terminalsolana --versionYou should see output similar to the following:solana-cli 2.0.26 (src:3dccb3e7; feat:607245837, client:Agave)You can view all available versions on the\nAgave Github repo.Agave is the validator client from Anza, formerly known\nas Solana Labs validator client.To later update the Solana CLI to the latest version, you can use the following\ncommand:Terminalagave-install updateInstall Anchor CLIAnchor is a framework for developing Solana\nprograms. The Anchor framework leverages Rust macros to simplify the process of\nwriting Solana programs.There are two ways to install the Anchor CLI and tooling:\nAnchor Version Manager (AVM) - Recommended installation method\nWithout AVM - Install directly from GitHub\nThe Anchor version manager (AVM) allows you to install and manage different\nAnchor versions on your system and easily update Anchor versions in the future.Install AVM with the following command:Terminalcargo install --git https://github.com/otter-sec/anchor avm --forceCheck that AVM was installed successfully:Terminalavm --versionInstall the latest version of Anchor CLI using AVM:Terminalavm install latest\navm use latestAlternatively, you can install a specific version of Anchor CLI by specifying\nthe version number:Terminalavm install 1.2.0\navm use 1.2.0Don't forget to run the avm use command to declare which Anchor CLI version\nshould be used on your system.\nIf you installed the latest version, run avm use latest.\nIf you installed the version 1.2.0, run avm use 1.2.0.\nTo verify that the installation was successful, check the Anchor CLI version:Terminalanchor --versionYou should see output similar to the following:anchor-cli 1.2.0When installing the Anchor CLI on Linux or WSL, you may encounter this error:error: could not exec the linker cc = note: Permission denied (os error 13)If you see this error message, follow these steps:\nInstall the dependencies listed in the\nLinux section at the top of\nthis page.\nRetry installing the Anchor CLI.\nNode.js and YarnNode.js and Yarn are required for project initialization and when using\na TypeScript-based test template (mocha, jest). The default test template\n(litesvm) does not run TypeScript tests, so they are not needed for\nday-to-day development once initialization is complete. They are expected to\nbecome fully optional in a future release.When running anchor build, if you encounter the following errors:After applying the solution above, attempt to run anchor build again.When running anchor test after creating a new Anchor project on Linux or WSL,\nyou may encounter the following errors if Node.js or Yarn are not installed:Permission denied (os error 13)No such file or directory (os error 2)\nSolana CLI Basics\nThis section will walk through some common Solana CLI commands to get you\nstarted.\nSolana ConfigTo see your current config:solana config getYou should see output similar to the following:Config File: /Users/test/.config/solana/cli/config.yml\nRPC URL: https://api.mainnet-beta.solana.com\nWebSocket URL: wss://api.mainnet-beta.solana.com/ (computed)\nKeypair Path: /Users/test/.config/solana/id.json\nCommitment: confirmedThe RPC URL and Websocket URL specify the Solana cluster the CLI will make\nrequests to. By default this will be mainnet-beta.You can update the Solana CLI cluster using the following commands:solana config set --url mainnet-beta\nsolana config set --url devnet\nsolana config set --url localhost\nsolana config set --url testnetYou can also use the following short options:solana config set -um # For mainnet-beta\nsolana config set -ud # For devnet\nsolana config set -ul # For localhost\nsolana config set -ut # For testnetThe Keypair Path specifies the location of the default wallet used by the Solana\nCLI (to pay transaction fees and deploy programs). The default path is\n~/.config/solana/id.json. The next step walks through how to generate a\nkeypair at the default location.Create WalletTo interact with the Solana network using the Solana CLI, you need a Solana\nwallet funded with SOL.To generate a keypair at the default Keypair Path, run the following command:solana-keygen newYou should see output similar to the following:Generating a new keypair\n\nFor added security, enter a BIP39 passphrase\n\nNOTE! This passphrase improves security of the recovery seed phrase NOT the\nkeypair file itself, which is stored as insecure plain text\n\nBIP39 Passphrase (empty for none):\n\nWrote new keypair to /Users/test/.config/solana/id.json\n===========================================================================\npubkey: 8dBTPrjnkXyuQK3KDt9wrZBfizEZijmmUQXVHpFbVwGT\n===========================================================================\nSave this seed phrase and your BIP39 passphrase to recover your new keypair:\ncream bleak tortoise ocean nasty game gift forget fancy salon mimic amazing\n===========================================================================If you already have a file system wallet saved at the default location, this\ncommand will NOT override it unless you explicitly force override using the\n--force flag.Once a keypair is generated, you can get the address (public key) of the keypair\nwith the following command:solana addressAirdrop SOLOnce you've set up your local wallet, request an airdrop of SOL to fund your\nwallet. You need SOL to pay for transaction fees and to deploy programs.Set your cluster to the devnet:solana config set -udThen request an airdrop of devnet SOL:solana airdrop 2To check your wallet's SOL balance, run the following command:solana balanceThe solana airdrop command is currently limited to 5 SOL per request on\ndevnet. Errors are likely due to rate limits.Alternatively, you can get devnet SOL using the\nSolana Web Faucet.Run Local ValidatorThe Solana CLI comes with the\ntest validator\nbuilt-in. Running a local validator will allow you to deploy and test your\nprograms locally.In a separate terminal, run the following command to start a local validator:solana-test-validatorMake sure to update the Solana CLI config to localhost before commands.solana config set -ul\nAnchor CLI Basics\nThis section will walk through some common Anchor CLI commands to get you\nstarted. For more information on the Anchor CLI, see the\nAnchor documentation.\nInitialize ProjectTo create a new Anchor project, run the following command:Terminalanchor init <project-name>For example, to create a project called my-project, run:Terminalanchor init my-projectThis command creates a new directory with the project name and initializes a new\nAnchor project with a modular Rust program structure. By default, tests are\nwritten in Rust using the LiteSVM crate.\nUse --test-template to choose a different template (mollusk, mocha, jest, etc):Terminalanchor init my-project --test-template molluskBy default, Anchor uses a modular structure with separate files for\ninstructions, state, constants, and errors. This organization improves code\nmaintainability and is recommended for production code.Navigate to the project directory:Terminalcd <project-name>See the Anchor project's\nfile structure.Build ProgramTo build your project, run the following command:Terminalanchor buildThe compiled program can be found in the /target/deploy directory.Deploy ProgramTo deploy your project, run the following command:Terminalanchor deployThis command will deploy your program to the cluster specified in the\nAnchor.toml file.Test ProgramTo test your project, run the following command:Terminalanchor testThis command builds, deploys, and runs the tests for your project.When using localnet as the cluster in Anchor.toml, Anchor automatically\nstarts a local validator, deploys your program, runs tests, and then stops the\nvalidator.\nShell Completions\nShell completions can be generated for bash, fish and\nzsh.\nBash\nTerminalmkdir -p $HOME/.local/share/bash-completion/completions\nanchor completions bash > $HOME/.local/share/bash-completion/completions/anchor\navm completions bash > $HOME/.local/share/bash-completion/completions/avm\nexec bash\nFish\nTerminalmkdir -p $HOME/.config/fish/completions\nanchor completions fish > $HOME/.config/fish/completions/anchor.fish\navm completions fish > $HOME/.config/fish/completions/avm.fish\nsource $HOME/.config/fish/config.fish\nZsh\nFirst ensure the following is in your .zshrc file. If using oh-my-zsh this\nstep can be skipped.\nTerminalautoload -U compinit\ncompinit -i\nNext run:\nTerminalanchor completions zsh | sudo tee /usr/local/share/zsh/site-functions/_anchor\navm completions zsh | sudo tee /usr/local/share/zsh/site-functions/_avm\nexec zshNextQuickstartOn this pageQuick InstallationInstall DependenciesInstall RustInstall the Solana CLIInstall Anchor CLISolana CLI BasicsSolana ConfigCreate WalletAirdrop SOLRun Local ValidatorAnchor CLI BasicsInitialize ProjectBuild ProgramDeploy ProgramTest ProgramShell CompletionsBashFishZshEdit on GitHub","tokens":3021,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257297111,"hash":"081bda6ecf6fcebef3865d1a451d26e39e10d304"}
{"url":"https://www.openzeppelin.com/news/openzeppelin-and-t-rex-network-rebuild-onchainid-as-a-smart-account-for-regulated-assets","domain":"openzeppelin.com","title":"OpenZeppelin and T-REX Network Rebuild ONCHAINID as a Smart Account for Regulated Assets","text":"September 30, 2026OpenZeppelinAs part of a broader partnership to advance compliance infrastructure for tokenized finance, T-REX Network and OpenZeppelin have updated ONCHAINID to V3, which keeps its registry of verified claims and adds the capabilities of a modular smart account.For financial institutions and asset issuers, it simplifies how investors interact with regulated tokens: a single identity can hold assets, execute transactions, and manage recovery in one compliant flow.Why make identity programmable?ONCHAINID V3 widens what issuers and wallets can do. Keys, claims, and execution are now handled through installable modules rather than a single contract, so each can be added, reviewed, and changed on its own.Flexible Signature Checking: Through ERC-7913, an identity can be controlled by secp256r1, RSA, or WebAuthn credentials alongside standard ECDSA, closer to how people and institutions already authenticate.Modular social recovery: Recovery becomes an installable module with guardian and threshold mechanics, rather than relying on an issuer to re-link a new wallet.Crosschain identity: One identity can be verified across chains instead of re-established on each.An account, not just a record: Because the identity is itself an account, it can hold assets and interact with the ecosystem directly.Composable compliance: Rules stay composable and under issuer control, able to evolve without the identity being rebuilt around them.OnchainID V3 brings two permission models together in one account: ERC-734, the key-management standard, where each key has a purpose that defines its authority (for example, a management or action key), and ERC-7579, which defines how a transaction is validated and executed.A record only has to be read correctly, while an account has to decide what each key may do and stay consistent across every path a call can take. OpenZeppelin audited the redesign, including how the two permission models interact.A compliance foundation for tokenized financeONCHAINID v3 is one part of ongoing work between T-REX Network and OpenZeppelin on the ERC-3643 compliance standard. Alongside bringing ERC-3643 into the OpenZeppelin Contracts library as an audited component, that work extends compliance to more networks, including native non-EVM support on Stellar.The roadmap also targets confidentiality through Zama's fully homomorphic encryption, so regulatory checks run on encrypted data without exposing identities or amounts.Access the full audit report and read the ONCHAINID documentation to get started.","tokens":640,"squid":"ink-security_audits","role":"Sentinel","at":1791257301307,"hash":"063242b354ba8e5bb9ab3c625f3e7bc4f3054277"}
{"url":"https://ethresear.ch/t/frame-transactions-through-a-statelessness-lens/24538/3","domain":"ethresear.ch","title":"Frame Transactions Through a Statelessness Lens - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n Mar 29\n\n 3 / 12\n\n Mar 30\n\n Apr 15\n\n post by CPerezz on Mar 29\n\n CPerezz\n\n How AA and EIP-8141 mempool strategies interact with stateless nodes in a post-ZKEVM world\nThe post-ZKEVM baseline\nZKEVMs replace re-execution with proof verification. Once a SNARK proof can validate a block in milliseconds, nodes no longer need full state to participate in consensus. The requirement that made every full node hold ~280 GB of state — re-execution — disappears. What remains is economic: builders, RPC providers, and searchers hold state because their business depends on it. Everyone else can stop.\nThe expected response is partial statefulness: nodes hold the full account trie (every account’s nonce, balance, codeHash, and storageRoot) plus selective storage for contracts they choose to track. A node serving a DeFi protocol tracks that protocol’s storage. A node focused on censorship resistance tracks nothing beyond accounts. This minimum — Validity-Only Partial Statelessness (VOPS) — costs roughly 10 GB for ~400M accounts. Partial statefulness (PS) sits above VOPS: same full account trie, plus full storage tries for selected contracts, following the chain tip via Block Access Lists (EIP-7928) instead of re-execution. See the EthCC 2026 presentation for a deeper treatment.\nWhy does this matter for transaction formats? Because mempool health is censorship resistance. A node that can validate transactions locally can maintain a mempool, propagate transactions to peers, and participate in FOCIL inclusion lists (EIP-7805). A node that cannot validate a transaction type cannot include it in an inclusion list, cannot enforce its inclusion, and censorship resistance for that class of transactions degrades silently. The fewer nodes that can validate, the easier it is to censor. In a post-ZKEVM world where most nodes are partially stateful, any new transaction format must be evaluated against this reality.\nWhat frame transaction validation requires\nToday, validating a transaction in the mempool is cheap. For legacy and EIP-1559 transactions, a node runs ecrecover on the signature to derive the sender, checks the sender’s nonce, and verifies the sender’s balance covers the transaction cost. This is pure computation plus a single account lookup. Any node with the account trie — including VOPS and PS nodes — can do this.\nFrame transactions (EIP-8141) change this fundamentally. A frame transaction has no cryptographic signature in the traditional sense. Instead, the transaction declares its sender explicitly and breaks execution into ordered frames. One of these frames has mode VERIFY: it executes the sender’s account code, which must call the APPROVE opcode to authorize the transaction. The validation logic is arbitrary — it can implement any signature scheme (post-quantum, multisig, social recovery) by reading the sender’s storage and executing whatever verification logic the account code defines.\nThis means the validating node needs the sender’s bytecode and storage slots accessed during verification — not just the two fields (nonce, balance) in their account leaf. And the sender is a smart contract wallet: it could be any account on the network. Validation shifts from “look up two fields” to “execute arbitrary code against arbitrary account state.”\nframe_diagram1920×1233 194 KB\nFigure: Legacy transaction validation requires only an account trie lookup (~3,000 gas, all node types). Frame transaction validation requires executing a VERIFY frame against the sender’s bytecode and storage (up to ~100k gas, only nodes with the relevant state).\nThe mempool strategies and what they assume\nThe mempool strategies document for EIP-8141 proposes three progressively more ambitious policies for which frame transactions the public mempool will accept. Each trades off permissionlessness against DoS protection. What matters here is what state each strategy requires from the validating node.\nStrategy 1 (Self-Relay Only) accepts only self-funded frame transactions. Storage reads during VERIFY are restricted to tx.sender’s slots, and one pending frame transaction per sender is allowed. But “the sender’s code and storage” deserves careful unpacking — the actual state footprint depends on what kind of account the sender is.\nAny account can send a frame transaction. The EIP specifies three validation paths:\n\nPlain EOA (no code, no delegation). EIP-8141 defines “default code” that handles VERIFY by checking an ECDSA (secp256k1) or P256 signature against the sender’s address and calling APPROVE. No storage reads, no custom bytecode. This is as cheap to validate as a legacy transaction — any node with the account trie (including VOPS) can do it.\n\nContract account. The sender’s own deployed code runs during VERIFY, reading the sender’s own storage. Straightforward — the node needs the sender’s code and storage.\n\n7702-delegated EOA — the interesting case for AA. The account’s code field is a 23-byte delegation prefix (0xef0100 || delegate_address). When the EVM encounters this during the VERIFY frame, it follows the pointer and loads the delegate contract’s bytecode — but executes it in the sender’s context. address(this) returns the sender’s address. SLOAD reads the sender’s storage trie, not the delegate’s. This is semantically identical to how proxy contracts work: the delegate’s compiled storage layout (slot 0 = owner, slot 1 = nonce, etc.) is interpreted against the sender’s raw key-value storage. The delegate’s own storage is never touched.\n\nThe 7702-delegated case raises an immediate question: where does an EOA’s storage come from? EOAs traditionally have empty storage tries. The answer: once an EOA delegates via a SetCode transaction, subsequent transactions execute the delegated code in the EOA’s context — and SSTORE writes go to the EOA’s storage trie. The first interaction typically initializes key slots (owner address, guardian, nonce). From that point on, the EOA carries a real storage trie under its address in the state, structurally identical to a contract’s. The EIP provides no special initialization mechanism; it is left to the wallet implementation (e.g., a self-initializing pattern on first use, or a separate setup transaction).\nTwo further constraints shape the state access. First, the EIP-8141 rule “SLOAD restricted to tx.sender storage” is not redundant with 7702 — it constrains transitive calls. If the delegated code calls a helper library via CALL, that helper enters its own execution context where SLOAD would normally read the helper’s storage. The EIP-8141 rule forbids this: helpers reached via CALL can only perform pure computation (signature math, hashing, precompile calls). If the delegated code uses DELEGATECALL instead, the execution context stays the sender’s — SLOAD still reads the sender’s storage, which is permitted. Second, calling other 7702-delegated accounts during VERIFY is explicitly banned — their delegation targets are mutable, so one SetCode transaction could invalidate every pending frame transaction that depends on that account’s current behavior.\nSo the actual state footprint for Strategy 1 depends on the sender type:\nPlain EOA (default code):\n\ntx.sender’s account leaf (nonce, balance) — from the account trie\n\nNothing else. Signature verification is pure computation.\n\n7702-delegated EOA (the common AA case):\n\ntx.sender’s account leaf — nonce, balance, and the 23-byte delegation prefix\n\nThe delegate contract’s bytecode — the actual VERIFY logic, at a different address\n\ntx.sender’s storage slots — read by the delegate code via SLOAD, resolved against the sender’s (EOA’s) storage trie\n\nHelper library bytecodes — non-delegated, already-deployed contracts called for pure computation\n\nStorage is bounded to one account. Bytecodes may span 2-3 contracts. No shared state across different senders.\nstrategy_11920×1107 192 KB\nFigure: State access pattern for Strategy 1 VERIFY execution. Storage reads (green arrows) always resolve to tx.sender’s trie, regardless of which code is executing. The delegate’s and helper’s storage tries are never accessed.\n\nStrategy 2 (Canonical Paymaster) adds sponsored transactions through a standardized canonical paymaster contract. Where Strategy 1 uses self_verify (the sender calls APPROVE(0x3) to approve both execution and payment in one frame), Strategy 2 splits this into two frames via the only_verify → pay sequence.\nThe EIP-8141 APPROVE opcode takes a scope parameter that separates sender approval from payer approval. In Strategy 2’s sponsored flow, the only_verify frame targets tx.sender — the sender’s code runs (same 7702-delegation pattern as Strategy 1) and calls APPROVE to authorize execution without committing to pay. Then the pay frame targets the canonical paymaster contract — the paymaster’s code runs, checks its deposit balance, and calls APPROVE to authorize payment on the sender’s behalf.\nThe canonical paymaster is recognized by exact runtime code hash — nodes compare the deployed bytecode against a known hash. This is a mempool policy, not a consensus rule: transactions using non-canonical paymasters can still be included in blocks via private builder channels, they just cannot propagate through the public mempool. Anyone can deploy an instance of the canonical paymaster. Multiple instances can coexist, each with independent storage (its own deposit pool, withdrawal timestamps). The set of recognized bytecodes is also not permanently fixed — the EIP authors expect to add additional canonical paymasters over time (e.g., PQ-safe variants).\nThe paymaster’s safety relies on two structural constraints. First, delayed withdrawal: funds deposited into a canonical paymaster instance can only leave through gas payment or a time-locked withdrawal. A paymaster cannot deposit ETH, sponsor 1000 transactions, then instantly withdraw — the time lock prevents this mass-invalidation attack. Second, node-side pending balance tracking: nodes compute effective_balance = deposited - pending_gas_commitments per paymaster instance, where pending_gas_commitments is the sum of worst-case gas costs for all pending transactions using that instance. New transactions are rejected if the effective balance is insufficient.\nDuring the pay frame, the canonical paymaster gets an exemption from the generic SLOAD restriction. While only_verify restricts storage reads to tx.sender only (same as Strategy 1), the pay frame can read the paymaster’s own storage — its deposit balances and withdrawal timestamps. This exemption exists because the canonical code is vetted and well-known; it is admitted “by code match rather than by requiring it to satisfy each generic validation rule individually.”\nThe state footprint for Strategy 2 is everything from Strategy 1, plus:\n\nCanonical paymaster’s bytecode — to verify the code hash matches (or implement the check natively, since the code is known)\n\nCanonical paymaster’s storage — deposit balance and withdrawal timestamps, exempted from the tx.sender-only SLOAD restriction\n\nNode-local accounting — pending gas commitments per paymaster instance (not on-chain state)\n\nThis raises a question the spec does not address: instance proliferation. Since the canonical paymaster is recognized by code hash, anyone can deploy an instance. Each instance has independent storage. If there are 1-3 well-known instances per chain, the state burden is trivially bounded. If there are hundreds or thousands — each needing their deposit balance tracked — the state requirement grows with instance count. There is no protocol-level limit on the number of instances. In the worst case, this approaches Strategy 3’s unbounded state problem. The mitigating argument is economic: a paymaster with a large deposit pool is more useful than many small ones, so fragmentation is economically inefficient. But the protocol does not enforce this.\nThere is a second, arguably deeper risk: canonical paymaster adoption. Since the mempool policy is not a consensus rule, wallet providers are free to build non-canonical paymasters with richer feature sets — more flexible withdrawal logic, multi-token gas payment, programmable sponsorship policies. If these non-canonical implementations gain majority adoption, their transactions cannot enter the public mempool, cannot be picked up by arbitrary builders, and — critically — cannot be enforced by FOCIL. The censorship resistance story for AA transactions depends entirely on enough users routing through canonical, mempool-compliant paymasters. If the market routes around them, FOCIL becomes structurally toothless for account-abstracted transactions: it exists, but covers nothing. The EIP authors are confident Strategy 2 will be used, citing the strong incentive of public mempool access (any builder can include the tx, plus FOCIL enforcement). Whether that incentive outweighs the feature gap between canonical and non-canonical paymasters is an open question the market will answer.\nstrategy_21920×1107 221 KB\nFigure: Strategy 2 splits validation into two frames. The only_verify frame accesses sender state (same as Strategy 1). The pay frame accesses the canonical paymaster’s own storage (exempted from the sender-only SLOAD rule). Instance proliferation determines whether the paymaster state burden is bounded or not.\nStrategy 3 (Full ERC-7562) allows arbitrary paymasters — any contract can act as a paymaster, gated by staking and a node-local reputation system. This is the most permissive strategy and the most demanding in terms of state.\nWhere Strategy 2 constrains the paymaster to a single canonical bytecode with known storage layout, Strategy 3 removes that constraint. Any contract willing to stake ETH can serve as a paymaster. Staked entities get relaxed validation rules: the SLOAD restriction to tx.sender storage is lifted, allowing staked paymasters to read their own storage and potentially storage of other contracts they interact with during validation. The banned opcode list is also relaxed for staked entities. The safety model shifts from structural constraints (known code, delayed withdrawal) to economic constraints (stake at risk, reputation tracking).\nNodes manage DoS risk through a reputation system: they track how often each staked entity’s transactions are invalidated, how much gas is wasted on failed simulations, and whether the entity causes cascading invalidations. Entities that misbehave get throttled or banned. This requires ongoing observation — the node must simulate transactions, observe their outcomes, and maintain per-entity statistics across blocks.\nThe state footprint for Strategy 3 is unbounded along multiple dimensions:\n\nArbitrary paymaster bytecodes — nodes must load and execute any paymaster’s code, not just one canonical bytecode. Each paymaster has different logic, different storage layouts, different validation behavior.\n\nCross-account storage reads — staked entities can read storage from contracts other than tx.sender during validation. A staked paymaster might check a whitelist contract, a price oracle, or an access control registry. Each of these is additional state the node must have.\n\nReputation database — nodes must maintain a local database of per-entity behavior (simulation success rate, gas wasted, invalidation frequency). This requires seeing and simulating all transactions involving staked entities — impossible if the node lacks the state to simulate them.\n\nCascading invalidation risk — one storage change in a shared contract can invalidate every pending transaction whose validation depends on that contract. Strategy 1 prevents this structurally (sender-only storage). Strategy 2 limits it to canonical paymaster instances. Strategy 3 has no structural bound — the invalidation surface is as wide as the staked entity’s storage access.\n\nThese strategies were designed with full nodes in mind. They implicitly assume the validating node has access to any account’s code and storage on demand.\nFOCIL, AA-VOPS, and the eligibility bridge\nThe tension between frame transactions and partially stateful nodes is not just a mempool convenience problem — it directly affects censorship resistance through FOCIL.\nThomas Thiery’s proposal addresses this by defining an eligible subset of frame transactions that FOCIL can enforce, and introduces a concept directly relevant here: AA-VOPS. AA-VOPS extends VOPS by caching the first N storage slots per account (N in the range 2-4). Most smart wallets store their nonce, owner, and guardian in slots 0-3, so N slots covers the common validation pattern. The critical constraint (constraint 5 in the proposal): VERIFY may only read sender and payer account state plus their first N storage slots. Any read beyond this boundary renders the transaction ineligible — its omission is excused from FOCIL enforcement.\nAA-VOPS partially solves the storage half of the problem for frame transaction validation. But as established in the Strategy 1 analysis above, validation also requires bytecodes — the delegate contract’s code (via 7702 delegation) and potentially helper library code. Constraint 5 bounds storage reads but does not address code availability. An AA-VOPS node caching N slots per account still cannot execute the VERIFY frame if it lacks the delegate’s bytecode. This is an open gap in the AA-VOPS design: either bytecodes must be obtained through some external mechanism, or FOCIL-eligible frame transactions must be limited to accounts whose delegate code is widely available (e.g., a small set of well-known wallet implementations).\nThe base-case tension: thin accounts vs. rich wallets\nThere is a more fundamental tension that applies regardless of strategy: account abstraction makes accounts heavier, and statelessness needs accounts to stay light.\nVOPS’s 8.4 GB baseline rests on a specific assumption: EOAs are thin. An EOA today is ~40 bytes in the account trie — nonce, balance, empty codeHash, empty storageRoot. 400 million accounts at ~40 bytes yields roughly 10 GB. This number is the floor for censorship-resistance nodes: the minimum state needed to validate legacy transactions for any sender on the network.\nNative AA changes the per-account weight through two paths. EIP-7702 delegation gives EOAs a non-empty code field and — as the delegated code transacts over time — a growing storage trie (owner key, wallet nonce, guardian, session keys, permissions). EIP-8141’s deploy frame can convert an address into a full contract with code and storage in a single transaction. Either way, accounts that were ~40 bytes acquire storage tries that persist and grow.\nThe AA-VOPS N-slot constraint bounds what VERIFY can read per validation, but it does not bound the aggregate state a node must hold to validate frame transactions from arbitrary senders. Every account that adopts AA adds N cached storage slots to the validation-critical state set. At N=4 with 64 bytes per slot: if 25% of accounts adopt AA wallets (60M accounts), that adds ~15 GB — nearly doubling the VOPS baseline. At full adoption across 400M accounts, AA-VOPS reaches ~62 GB — an 8x increase over today’s VOPS, though still well below the ~280 GB full state.å\nAAVOPSGROWTH1920×1157 135 KB\nFigure: Validation-critical state grows linearly with AA adoption. At N=4 cached slots per account, moderate adoption nearly doubles the VOPS baseline; full adoption yields an 8x increase. The full state (~280 GB) remains distant, but the VOPS “floor” rises substantially.\nThomas Thiery’s FOCIL proposal offers a partial answer through AA-VOPS: cache N=2-4 storage slots per account, restrict VERIFY to those slots, and excuse any transaction that reads beyond this bound from FOCIL enforcement. This solves the per-validation problem — a node knows exactly what to fetch for each transaction, and the fetch set is small and deterministic. It also creates an incentive for wallet implementations to minimize validation storage reads to remain FOCIL-eligible. But it does not solve the aggregate problem: a node wanting to be a universal validator still needs N slots cached for every AA-enabled account, and this total grows linearly with adoption.\nThe approach also creates a two-tier system. Transactions from simple wallets that fit within N slots and the VERIFY gas budget get full FOCIL censorship resistance. Transactions that need more — post-quantum signature verification (which already exceeds MAX_VERIFY_GAS_PER_FRAMETX), privacy protocol interactions, complex multi-guardian recovery — fall outside eligibility. Their omission is excused. The transactions most likely to need censorship resistance (novel cryptography, privacy-preserving protocols) are precisely the ones that may not fit within the eligible subset.\nMore fundamentally, we cannot predict whether N=2-4 storage slots will remain sufficient as wallet implementations evolve. Today’s smart wallets may need only an owner and a nonce for validation. Tomorrow’s may need session key registries, cross-chain state, or social recovery graphs. Shipping a system where censorship resistance for abstracted accounts is structurally bounded by a fixed N risks a future where new use cases outgrow the bound — and where the interaction between statelessness and censorship resistance becomes unworkable precisely when it matters most.\nThis is not a per-strategy concern. Strategy 1 requires sender storage for validation. Strategy 2 adds paymaster storage on top. Strategy 3 adds arbitrary contract storage. But the base cost — sender storage across all AA-adopting accounts — applies to all three. The strategies differ in how much additional state they require beyond this base. The tension is structural: statelessness wants the minimum viable node to hold less state over time, so more nodes can participate and censorship resistance improves. Account abstraction wants every account to carry richer state over time, so wallets can implement better security models. These goals are not contradictory — the bounded state access rule mediates between them — but the mediation has a cost denominated in gigabytes, and that cost scales with adoption.\nCompatibility summary\n\nFull Node\nPS (w/ paymaster)\nPS (no paymaster)\nVOPS\nAA-VOPS\n\nAccount nonce + balance\nYes\nYes\nYes\nYes\n\nDelegate + helper bytecodes\nYes\nIf tracked\nIf tracked\nNo\n\nSender storage (N slots)\nYes\nIf tracked\nIf tracked\nNo\n\nPaymaster storage\nYes\nIf tracked†\nNo\nNo\n\nArbitrary contract storage\nYes\nNo\nNo\nNo\n\nStrategy 1 (self-relay)\nYes\nPartial\nPartial\nNo\n\nStrategy 2 (canonical paymaster)\nYes\nPartial–Yes†\nPartial\nNo\n\nStrategy 3 (ERC-7562)\nYes\nNo\nNo\nNo\n\n* AA-VOPS caches N storage slots per account but not bytecodes. VERIFY execution requires the delegate’s code. How AA-VOPS nodes obtain bytecodes is an open question — soispoke’s proposal bounds storage access but does not address code availability.\n† “If tracked” — PS nodes must explicitly track each canonical paymaster instance. Compatibility is strong when instances are few (1-3) and degrades with instance proliferation. See the instance proliferation discussion above.\nClosing\nFrame transactions are a powerful primitive for native account abstraction. But they carry two tensions that go deeper than mempool strategy selection.\nThe first is structural: statelessness needs accounts to stay thin, while account abstraction needs them to grow richer. The bounded state access rule (N slots per account) mediates this by capping per-validation reads, but the aggregate state grows linearly with AA adoption. Today’s ~10 GB VOPS baseline could reach ~20 GB at moderate adoption and past 60 GB at full adoption.\nThe second is economic: Strategy 2’s censorship resistance guarantees only apply to transactions using canonical, mempool-compliant paymasters. If wallet providers build richer non-canonical paymasters and users gravitate toward them, those transactions route through private builders, and FOCIL — designed to prevent censorship — covers nothing for the majority of AA transactions. The protocol decisions made around account abstraction will shape what “censorship resistant” means in practice, and whether the infrastructure we build for FOCIL inclusion of AA transactions has anyone to include.\n\nThe fear I have is that we take a decision without considering statelessness. Once ZKEVMs ship, a supermajority of nodes will be stateless or partially-stateful — and if the state needed for mempool validation has grown too large, almost nobody can keep the mempool healthy or participate in FOCIL. And if we get the canonical paymaster wrong — if wallet providers route around it because it doesn’t offer what users want — then even the nodes that can afford the state have nothing to enforce. FOCIL exists, but covers nobody. We greatly degrade the Censorship Resistance we have battled so much to finally have in Hegota.\n\n Frame Transactions and the Three Gates to Privacy\n\n 5\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n post by DanielVF on Mar 30\n\n DanielVF\n\n Agreed with you. I think it’s a mistake to compare the benefits and costs of frame transactions only looking at current featureset of Ethereum. A real cost is in the future possibilities that frame transactions cut off.\nNow tradeoff might be worth it, but that’s a decision that should be made with eyes open.\nI think the key problem in frame transactions is the fact that block inclusion itself is gated on having access to extra state and code. If transactions could be included and pay for it, even if they revert later, without requiring the extra state, then the core problem that narrows future possibilities goes away.\n\n post by CPerezz on Mar 31\n\n CPerezz\n\n Notice that this works (some kind of commit-and-execute schema). On this way we only need balance and nonce and codeFlag to make sure that a tx can pay for the MINIMAL_FEE_THAT_PREVENTS_DOS.\nThe problem is how to reconcile this with Encrypted Mempools? See LUCID: Encrypted mempool with distributed payload propagation for instance. This won’t really allow us to do this as we no longer can check this. And it’s super hard for me to see how to have private txs, when we have to pay for DOS prevention work.\nSo, I don’t think is impossible to reconcile all this. But seriously needs work from all EIP authors involved. Otherwise it’s going to be hard.\n\n post by ParthSinghPS on Apr 7\n\n ParthSinghPS\n\nIf so, this implies not just reduced participation, but a structural shift where transaction visibility becomes dependent on node specific state coverage.\nIn that case, how are propagation and inclusion guarantees preserved, especially if some transactions never reach a sufficiently broad subset of the network to be picked up by builders or enforced via FOCIL?\n\n post by CPerezz on Apr 8\n\n CPerezz\n\n Yes! Exactly!!\nWe need the vast majority of the most “minimal” nodes to actually make sure that tx propagation has a high success rate. This translates into txs getting into ILs.\nSo yes, we essentially need to make sure that the canonical Paymaster is what wallets want and what gets broad adoption. Otherwise, we will be in trouble.\n\n post by zincoshine on Apr 10\n\n zincoshine\n\nAFAIU, in 4337, this was solved by every account having to deposit a small fee in the EntryPoint contract which was used as an inclusion fee (in case of invalidation). In theory, the same model should work for Frame transactions as well. Deploying a system contract at a known address and a validation for inclusion is performed against this address?\n\n post by zincoshine on Apr 10\n\n zincoshine\n\n That said, I don’t think this will address the issue with VOPS nodes. Thinking out loud, could this “inclusion deposit” be incorporated directly into the Account Trie?\n\n post by forshtat on Apr 10\n\n forshtat\n\n I am not familiar with this side of statelessness problem, only briefly discussed it with ChatGPT, but was there a discussion around something like “Validation Storage Rent” somewhere?\nMeaning, instead of simply hardcoding a fixed N=2 - 4 storage slots per account available for frame transaction validation, make accounts pay extra for storage they occupy in the validation state?\nFor example, in VERIFY frames make accounts read storage slots through a new opcode, say VOPSSLOAD, that additionally burns a small amount of ETH and sets a “deadline”, a future block height until which the read slot is available for VERIFY frame execution and FOCIL.\nThe first slot extended for a given address also covers the address’s bytecode.\nFor example, say, 1 wei per slot per block, 10 wei per address per block for bytecode, with the first accessed slot paying both fees (11 wei/block).\nWhen a slot’s deadline expires, VOPS nodes are free to evict it, and VOPSSLOAD fails to read this slot.\nTo keep active wallets from having to think about this, we could give a free 30-day deadline extension whenever a slot is legitimately accessed via VOPSSLOAD inside a VERIFY frame, so wallets that transact at least once a month auto-renew without any extra cost.\nDormant wallets that go silent for 30+ days fall out of the VOPS set.\nTo re-enter VOPS without generating state proofs and such, someone else may simply call the account’s “wake up” function in an EXECUTE frame which internally invokes VOPSSLOAD to re-register the needed slots and “pay the rent”.\nThe scheme kind of kick-starts istelf by having all existing storage treated as valid for VERIFY frames for the last 30 days before VOPS goes live.\nDoes something like this, or generally this direction make sense as a solution to the problem?\n\n post by CPerezz on Apr 11\n\n CPerezz\n\n zincoshine\n\n I don’t understand what the system contract does here. It collects the fees that everyone puts in order to use the gas sponsoring? If so, this is already breaking the privacy-solutions quite a lot.\nAlso, we should avoid system contracts as much as possible. We have more than desired.\n\nWhy do we need to enshrine things in protocol all time? The beauty of VOPS is that is out-of-protocol. We don’t have to change it to make it work.\nThe protocol is extremely complex already. And this makes it even more complex, and grows state further. And most of what is done, can already be done out of protocol.\nI care about protocol overall. I understand AA is an important thing. But frame in it’s Strategy 2 can’t even serve the “pay gas with USDX” usecase. So, if the solution is just “shove more stuff into protocol”. It doesn’t convince me.\nYou can disagree with ERC solutions. That’s fair. But you should also understand why some core devs try to propose alternatives to another complication addition to the protocol.\n\n post by CPerezz on Apr 11\n\n CPerezz\n\nState rent is one of the most complex in-protocol things to do. Solana tried and went away from it quickly. Lots of edge cases and UX burden.\n\nAs said above, the beauty of VOPS is to not require any protocol changes. It just works.\nAdding new opcodes and enshrining VOPS in-protocol seems like a bad move. Adds complexity and issues.\nAlso, notice you will force MORE STATE STORAGE. Because you force all nodes to track EVERY SLOT TIMESTAMP.\nI don’t think this is a way to go. But this is ofc only my opinion.\n\n post by forshtat on Apr 11\n\n forshtat\n\nYour post describes how Frame Transactions interact with Zero-Knowledge EVM, so looks like this ship has sailed \nOn a serious note, do you expect all of this complexity to appear for a FOCIL-only expiry as well?\n\nFair point, I would like to think about it. Is there a target validation state size for VOPS to hit?\nI understand the 400M accounts number is approximate for the present state of affair, is there a growth rate to take into account? Agentic wallets and all that?\nI apologize for asking basic questions, I sometimes have a hard time following the statelessness discussion.\n\n post by derekchiang on Apr 15\n\n derekchiang\n\nIsn’t another option to simply add code to VOPS? According to this article, as of 2024 contract bytecodes take up 245.5 * 4.3% = 10.55GB in total. That would double the size of VOPS, but still well below the size of the full state.\n\n Powered by Discourse","tokens":8037,"squid":"ink-research","role":"Deep Scholar","at":1791257307463,"hash":"c274a16fdf61b621397e8da11c3209b95b88765c"}
{"url":"https://www.anchor-lang.com/docs/basics/cpi","domain":"anchor-lang.com","title":"Cross Program Invocation","text":"The BasicsCross Program InvocationLearn how to implement Cross Program Invocations (CPIs) in Anchor programs to enable composability between different Solana programs.Cross Program Invocations (CPI) refer to the process of one program invoking\ninstructions of another program, which enables the composability of Solana\nprograms.\nThis section will cover the basics of implementing CPIs in an Anchor program,\nusing a simple SOL transfer instruction as a practical example. Once you\nunderstand the basics of how to implement a CPI, you can apply the same concepts\nfor any instruction.\nCross Program Invocations\nLet's examine a program that implements a CPI to the System Program's transfer\ninstruction. Here is the example program on\nSolana Playground.\nThe lib.rs file includes a single sol_transfer instruction. When the\nsol_transfer instruction on the Anchor program is invoked, the program\ninternally invokes the transfer instruction of the System Program.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_lang::system_program::{transfer, Transfer};\n\ndeclare_id!(\"9AvUNHjxscdkiKQ8tUn12QCMXtcnbR9BVGq3ULNzFMRi\");\n\n#[program]\npub mod cpi {\n use super::*;\n\n pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {\n let from_pubkey = ctx.accounts.sender.to_account_info();\n let to_pubkey = ctx.accounts.recipient.to_account_info();\n let program_id = ctx.accounts.system_program.to_account_info();\n\n let cpi_context = CpiContext::new(\n program_id,\n Transfer {\n from: from_pubkey,\n to: to_pubkey,\n },\n );\n transfer(cpi_context, amount)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct SolTransfer<'info> {\n #[account(mut)]\n sender: Signer<'info>,\n #[account(mut)]\n recipient: SystemAccount<'info>,\n system_program: Program<'info, System>,\n}\nThe cpi.test.ts file shows how to invoke the Anchor program's sol_transfer\ninstruction and logs a link to the transaction details on SolanaFM.\ncpi.test.tsit(\"SOL Transfer Anchor\", async () => {\n const transactionSignature = await program.methods\n .solTransfer(new BN(transferAmount))\n .accounts({\n sender: sender.publicKey,\n recipient: recipient.publicKey,\n })\n .rpc();\n\n console.log(\n `\\nTransaction Signature:` +\n `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,\n );\n});\nYou can build, deploy, and run the test for this example on Playground to view\nthe transaction details on the SolanaFM explorer.\nThe transaction details will show that the Anchor program was first invoked\n(instruction 1), which then invokes the System Program (instruction 1.1),\nresulting in a successful SOL transfer.\n\nExample Explanation\nCross Program Invocations (CPIs) allow one program to invoke instructions on\nanother program. The process of implementing a CPI is the same as that of\ncreating an instruction where you must specify:\n\nThe program ID of the program being called\nThe accounts required by the instruction\nAny instruction data required as arguments\n\nThis pattern ensures the CPI has all the information needed to invoke the target\nprogram's instruction.\nThe System Program's transfer instruction requires two accounts:\n\nfrom: The account sending SOL.\nto: The account receiving SOL.\n\nIn the example program, the SolTransfer struct specifies the accounts required\nby the transfer instruction. The System Program is also included because the CPI\ninvokes the System Program.\n#[derive(Accounts)]\npub struct SolTransfer<'info> {\n #[account(mut)]\n sender: Signer<'info>, // from account\n #[account(mut)]\n recipient: SystemAccount<'info>, // to account\n system_program: Program<'info, System>, // program ID\n}\nThe following tabs present three approaches to implementing Cross Program\nInvocations (CPIs), each at a different level of abstraction. All examples are\nfunctionally equivalent. The main purpose is to illustrate the implementation\ndetails of a CPI.\nThe sol_transfer instruction included in the example code shows a typical\napproach for constructing CPIs using the Anchor framework.This approach involves creating a\nCpiContext,\nwhich includes the program_id and accounts required for the instruction being\ncalled. The CpiContext is then passed to an Anchor helper function\n(transfer)\nto invoke a specific instruction.use anchor_lang::system_program::{transfer, Transfer};pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {\n let from_pubkey = ctx.accounts.sender.to_account_info();\n let to_pubkey = ctx.accounts.recipient.to_account_info();\n let program_id = ctx.accounts.system_program.to_account_info();\n\n let cpi_context = CpiContext::new(\n program_id,\n Transfer {\n from: from_pubkey,\n to: to_pubkey,\n },\n );\n\n transfer(cpi_context, amount)?;\n Ok(())\n}The cpi_context variable specifies the program ID (System Program) and\naccounts (sender and recipient) required by the transfer instruction.let cpi_context = CpiContext::new(\n program_id,\n Transfer {\n from: from_pubkey,\n to: to_pubkey,\n },\n);The cpi_context and amount are then passed into the transfer function to\nexecute the CPI invoking the transfer instruction of the System Program.transfer(cpi_context, amount)?;\nHere is a reference program on\nSolana Playground\nwhich includes all 3 examples.\nCross Program Invocations with PDA Signers\nNext, let's examine a program that implements a CPI to the System Program's\ntransfer instruction where the sender is a Program Derived Address (PDA) that\nmust be \"signed\" for by the program. Here is the example program on\nSolana Playground.\nThe lib.rs file includes the following program with a single sol_transfer\ninstruction.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_lang::system_program::{transfer, Transfer};\n\ndeclare_id!(\"3455LkCS85a4aYmSeNbRrJsduNQfYRY82A7eCD3yQfyR\");\n\n#[program]\npub mod cpi {\n use super::*;\n\n pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {\n let from_pubkey = ctx.accounts.pda_account.to_account_info();\n let to_pubkey = ctx.accounts.recipient.to_account_info();\n let program_id = ctx.accounts.system_program.to_account_info();\n\n let seed = to_pubkey.key();\n let bump_seed = ctx.bumps.pda_account;\n let signer_seeds: &[&[&[u8]]] = &[&[b\"pda\", seed.as_ref(), &[bump_seed]]];\n\n let cpi_context = CpiContext::new(\n program_id,\n Transfer {\n from: from_pubkey,\n to: to_pubkey,\n },\n )\n .with_signer(signer_seeds);\n\n transfer(cpi_context, amount)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct SolTransfer<'info> {\n #[account(\n mut,\n seeds = [b\"pda\", recipient.key().as_ref()],\n bump,\n )]\n pda_account: SystemAccount<'info>,\n #[account(mut)]\n recipient: SystemAccount<'info>,\n system_program: Program<'info, System>,\n}\nThe cpi.test.ts file shows how to invoke the Anchor program's sol_transfer\ninstruction and logs a link to the transaction details on SolanaFM.\nIt shows how to derive the PDA using the seeds specified in the program:\nconst [PDA] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"pda\"), wallet.publicKey.toBuffer()],\n program.programId,\n);\nThe first step in this example is to fund the PDA account with a basic SOL\ntransfer from the Playground wallet.\ncpi.test.tsit(\"Fund PDA with SOL\", async () => {\n const transferInstruction = SystemProgram.transfer({\n fromPubkey: wallet.publicKey,\n toPubkey: PDA,\n lamports: transferAmount,\n });\n\n const transaction = new Transaction().add(transferInstruction);\n\n const transactionSignature = await sendAndConfirmTransaction(\n connection,\n transaction,\n [wallet.payer], // signer\n );\n\n console.log(\n `\\nTransaction Signature:` +\n `https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,\n );\n});\nOnce the PDA is funded with SOL, invoke the sol_transfer instruction. This\ninstruction transfers SOL from the PDA account back to the wallet account via\na CPI to the System Program, which is \"signed\" for by the program.\nit(\"SOL Transfer with PDA signer\", async () => {\n const transactionSignature = await program.methods\n .solTransfer(new BN(transferAmount))\n .accounts({\n pdaAccount: PDA,\n recipient: wallet.publicKey,\n })\n .rpc();\n\n console.log(\n `\\nTransaction Signature: https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,\n );\n});\nYou can build, deploy, and run the test to view the transaction details on the\nSolanaFM explorer.\nThe transaction details will show that the custom program was first invoked\n(instruction 1), which then invokes the System Program (instruction 1.1),\nresulting in a successful SOL transfer.\n\nExample Explanation\nIn the example code, the SolTransfer struct specifies the accounts required by\nthe transfer instruction.\nThe sender is a PDA that the program must sign for. The seeds to derive the\naddress for the pda_account include the hardcoded string \"pda\" and the address\nof the recipient account. This means the address for the pda_account is\nunique for each recipient.\n#[derive(Accounts)]\npub struct SolTransfer<'info> {\n #[account(\n mut,\n seeds = [b\"pda\", recipient.key().as_ref()],\n bump,\n )]\n pda_account: SystemAccount<'info>,\n #[account(mut)]\n recipient: SystemAccount<'info>,\n system_program: Program<'info, System>,\n}\nThe Javascript equivalent to derive the PDA is included in the test file.\nconst [PDA] = PublicKey.findProgramAddressSync(\n [Buffer.from(\"pda\"), wallet.publicKey.toBuffer()],\n program.programId,\n);\nThe following tabs present two approaches to implementing Cross Program\nInvocations (CPIs), each at a different level of abstraction. Both examples are\nfunctionally equivalent. The main purpose is to illustrate the implementation\ndetails of the CPI.\nThe sol_transfer instruction included in the example code shows a typical\napproach for constructing CPIs using the Anchor framework.This approach involves creating a\nCpiContext,\nwhich includes the program_id and accounts required for the instruction being\ncalled, followed by a helper function (transfer) to invoke a specific\ninstruction.pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {\n let from_pubkey = ctx.accounts.pda_account.to_account_info();\n let to_pubkey = ctx.accounts.recipient.to_account_info();\n let program_id = ctx.accounts.system_program.to_account_info();\n\n let seed = to_pubkey.key();\n let bump_seed = ctx.bumps.pda_account;\n let signer_seeds: &[&[&[u8]]] = &[&[b\"pda\", seed.as_ref(), &[bump_seed]]];\n\n let cpi_context = CpiContext::new(\n program_id,\n Transfer {\n from: from_pubkey,\n to: to_pubkey,\n },\n )\n .with_signer(signer_seeds);\n\n transfer(cpi_context, amount)?;\n Ok(())\n}When signing with PDAs, the seeds and bump seed are included in the\ncpi_context as signer_seeds using with_signer(). The bump seed for a PDA\ncan be accessed using ctx.bumps followed by the name of the PDA account.let seed = to_pubkey.key();\nlet bump_seed = ctx.bumps.pda_account;\nlet signer_seeds: &[&[&[u8]]] = &[&[b\"pda\", seed.as_ref(), &[bump_seed]]];\n\nlet cpi_context = CpiContext::new(\n program_id,\n Transfer {\n from: from_pubkey,\n to: to_pubkey,\n },\n)\n.with_signer(signer_seeds);The cpi_context and amount are then passed into the transfer function to\nexecute the CPI.transfer(cpi_context, amount)?;When the CPI is processed, the Solana runtime will validate that the provided\nseeds and caller program ID derive a valid PDA. The PDA is then added as a\nsigner on the invocation. This mechanism allows for programs to sign for PDAs\nthat are derived from their program ID.\nHere is a reference program on\nSolana Playground\nwhich includes both examples.PreviousProgram Derived AddressNextClientsOn this pageCross Program InvocationsExample ExplanationCross Program Invocations with PDA SignersExample ExplanationEdit on GitHub","tokens":2868,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257312595,"hash":"994bd6f8498e6dccc3d4e290fbc22af97dc4cee7"}
{"url":"https://www.openzeppelin.com/research","domain":"openzeppelin.com","title":"Research | OpenZeppelin","text":"ResearchSearch articlesNewest to oldestOldest to newestAlphabetical: A–ZAlphabetical: Z–ACACEIS EURXT Smart Contract Security AuditSecurity AuditsOctober 2, 2026Uniswap Token Launcher AuditSecurity AuditsSeptember 29, 2026ONCHAINID AuditSecurity AuditsSeptember 29, 2026If You’re Regulated Under MiCA, You’re Also Regulated Under DORASecurity InsightsSeptember 23, 2026TRON Foundation Library and Upgradeable Contracts AuditSecurity AuditsSeptember 17, 2026From Algebra to Noise: Why Post-Quantum Cryptography Looks DifferentSecurity InsightsSeptember 14, 2026Miden Smart Contracts AuditSecurity AuditsAugust 26, 2026The Compliance Layer Is the Product: How Onchain Compliance Actually Works, Chain by ChainSecurity InsightsAugust 24, 2026StableGold AuditSecurity AuditsAugust 19, 2026TxFlow Security AuditSecurity AuditsAugust 19, 2026Know Your Counterparty: Identity, Access Control, and Institutional Participation on Public BlockchainsSecurity InsightsAugust 18, 2026Across Protocol V5 Bridging System AuditSecurity AuditsAugust 17, 2026Subscribe to The Onchain BriefMonthly insights for institutional onchain teams: what's moving in security, regulation, and market structure, and what it means for your program.","tokens":304,"squid":"ink-security_audits","role":"Sentinel","at":1791257312639,"hash":"52819e114b0878b6c7aba08d08598a32157cb451"}
{"url":"https://ethresear.ch/t/frame-transactions-through-a-statelessness-lens/24538","domain":"ethresear.ch","title":"Frame Transactions Through a Statelessness Lens - Execution Layer Research - Ethereum Research","text":"Frame Transactions Through a Statelessness Lens \n\n Execution Layer Research\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n Mar 29\n\n 1 / 12\n\n Mar 29\n\n Apr 15\n\n post by CPerezz on Mar 29\n\n CPerezz\n\n How AA and EIP-8141 mempool strategies interact with stateless nodes in a post-ZKEVM world\nThe post-ZKEVM baseline\nZKEVMs replace re-execution with proof verification. Once a SNARK proof can validate a block in milliseconds, nodes no longer need full state to participate in consensus. The requirement that made every full node hold ~280 GB of state — re-execution — disappears. What remains is economic: builders, RPC providers, and searchers hold state because their business depends on it. Everyone else can stop.\nThe expected response is partial statefulness: nodes hold the full account trie (every account’s nonce, balance, codeHash, and storageRoot) plus selective storage for contracts they choose to track. A node serving a DeFi protocol tracks that protocol’s storage. A node focused on censorship resistance tracks nothing beyond accounts. This minimum — Validity-Only Partial Statelessness (VOPS) — costs roughly 10 GB for ~400M accounts. Partial statefulness (PS) sits above VOPS: same full account trie, plus full storage tries for selected contracts, following the chain tip via Block Access Lists (EIP-7928) instead of re-execution. See the EthCC 2026 presentation for a deeper treatment.\nWhy does this matter for transaction formats? Because mempool health is censorship resistance. A node that can validate transactions locally can maintain a mempool, propagate transactions to peers, and participate in FOCIL inclusion lists (EIP-7805). A node that cannot validate a transaction type cannot include it in an inclusion list, cannot enforce its inclusion, and censorship resistance for that class of transactions degrades silently. The fewer nodes that can validate, the easier it is to censor. In a post-ZKEVM world where most nodes are partially stateful, any new transaction format must be evaluated against this reality.\nWhat frame transaction validation requires\nToday, validating a transaction in the mempool is cheap. For legacy and EIP-1559 transactions, a node runs ecrecover on the signature to derive the sender, checks the sender’s nonce, and verifies the sender’s balance covers the transaction cost. This is pure computation plus a single account lookup. Any node with the account trie — including VOPS and PS nodes — can do this.\nFrame transactions (EIP-8141) change this fundamentally. A frame transaction has no cryptographic signature in the traditional sense. Instead, the transaction declares its sender explicitly and breaks execution into ordered frames. One of these frames has mode VERIFY: it executes the sender’s account code, which must call the APPROVE opcode to authorize the transaction. The validation logic is arbitrary — it can implement any signature scheme (post-quantum, multisig, social recovery) by reading the sender’s storage and executing whatever verification logic the account code defines.\nThis means the validating node needs the sender’s bytecode and storage slots accessed during verification — not just the two fields (nonce, balance) in their account leaf. And the sender is a smart contract wallet: it could be any account on the network. Validation shifts from “look up two fields” to “execute arbitrary code against arbitrary account state.”\nframe_diagram1920×1233 194 KB\nFigure: Legacy transaction validation requires only an account trie lookup (~3,000 gas, all node types). Frame transaction validation requires executing a VERIFY frame against the sender’s bytecode and storage (up to ~100k gas, only nodes with the relevant state).\nThe mempool strategies and what they assume\nThe mempool strategies document for EIP-8141 proposes three progressively more ambitious policies for which frame transactions the public mempool will accept. Each trades off permissionlessness against DoS protection. What matters here is what state each strategy requires from the validating node.\nStrategy 1 (Self-Relay Only) accepts only self-funded frame transactions. Storage reads during VERIFY are restricted to tx.sender’s slots, and one pending frame transaction per sender is allowed. But “the sender’s code and storage” deserves careful unpacking — the actual state footprint depends on what kind of account the sender is.\nAny account can send a frame transaction. The EIP specifies three validation paths:\n\nPlain EOA (no code, no delegation). EIP-8141 defines “default code” that handles VERIFY by checking an ECDSA (secp256k1) or P256 signature against the sender’s address and calling APPROVE. No storage reads, no custom bytecode. This is as cheap to validate as a legacy transaction — any node with the account trie (including VOPS) can do it.\n\nContract account. The sender’s own deployed code runs during VERIFY, reading the sender’s own storage. Straightforward — the node needs the sender’s code and storage.\n\n7702-delegated EOA — the interesting case for AA. The account’s code field is a 23-byte delegation prefix (0xef0100 || delegate_address). When the EVM encounters this during the VERIFY frame, it follows the pointer and loads the delegate contract’s bytecode — but executes it in the sender’s context. address(this) returns the sender’s address. SLOAD reads the sender’s storage trie, not the delegate’s. This is semantically identical to how proxy contracts work: the delegate’s compiled storage layout (slot 0 = owner, slot 1 = nonce, etc.) is interpreted against the sender’s raw key-value storage. The delegate’s own storage is never touched.\n\nThe 7702-delegated case raises an immediate question: where does an EOA’s storage come from? EOAs traditionally have empty storage tries. The answer: once an EOA delegates via a SetCode transaction, subsequent transactions execute the delegated code in the EOA’s context — and SSTORE writes go to the EOA’s storage trie. The first interaction typically initializes key slots (owner address, guardian, nonce). From that point on, the EOA carries a real storage trie under its address in the state, structurally identical to a contract’s. The EIP provides no special initialization mechanism; it is left to the wallet implementation (e.g., a self-initializing pattern on first use, or a separate setup transaction).\nTwo further constraints shape the state access. First, the EIP-8141 rule “SLOAD restricted to tx.sender storage” is not redundant with 7702 — it constrains transitive calls. If the delegated code calls a helper library via CALL, that helper enters its own execution context where SLOAD would normally read the helper’s storage. The EIP-8141 rule forbids this: helpers reached via CALL can only perform pure computation (signature math, hashing, precompile calls). If the delegated code uses DELEGATECALL instead, the execution context stays the sender’s — SLOAD still reads the sender’s storage, which is permitted. Second, calling other 7702-delegated accounts during VERIFY is explicitly banned — their delegation targets are mutable, so one SetCode transaction could invalidate every pending frame transaction that depends on that account’s current behavior.\nSo the actual state footprint for Strategy 1 depends on the sender type:\nPlain EOA (default code):\n\ntx.sender’s account leaf (nonce, balance) — from the account trie\n\nNothing else. Signature verification is pure computation.\n\n7702-delegated EOA (the common AA case):\n\ntx.sender’s account leaf — nonce, balance, and the 23-byte delegation prefix\n\nThe delegate contract’s bytecode — the actual VERIFY logic, at a different address\n\ntx.sender’s storage slots — read by the delegate code via SLOAD, resolved against the sender’s (EOA’s) storage trie\n\nHelper library bytecodes — non-delegated, already-deployed contracts called for pure computation\n\nStorage is bounded to one account. Bytecodes may span 2-3 contracts. No shared state across different senders.\nstrategy_11920×1107 192 KB\nFigure: State access pattern for Strategy 1 VERIFY execution. Storage reads (green arrows) always resolve to tx.sender’s trie, regardless of which code is executing. The delegate’s and helper’s storage tries are never accessed.\n\nStrategy 2 (Canonical Paymaster) adds sponsored transactions through a standardized canonical paymaster contract. Where Strategy 1 uses self_verify (the sender calls APPROVE(0x3) to approve both execution and payment in one frame), Strategy 2 splits this into two frames via the only_verify → pay sequence.\nThe EIP-8141 APPROVE opcode takes a scope parameter that separates sender approval from payer approval. In Strategy 2’s sponsored flow, the only_verify frame targets tx.sender — the sender’s code runs (same 7702-delegation pattern as Strategy 1) and calls APPROVE to authorize execution without committing to pay. Then the pay frame targets the canonical paymaster contract — the paymaster’s code runs, checks its deposit balance, and calls APPROVE to authorize payment on the sender’s behalf.\nThe canonical paymaster is recognized by exact runtime code hash — nodes compare the deployed bytecode against a known hash. This is a mempool policy, not a consensus rule: transactions using non-canonical paymasters can still be included in blocks via private builder channels, they just cannot propagate through the public mempool. Anyone can deploy an instance of the canonical paymaster. Multiple instances can coexist, each with independent storage (its own deposit pool, withdrawal timestamps). The set of recognized bytecodes is also not permanently fixed — the EIP authors expect to add additional canonical paymasters over time (e.g., PQ-safe variants).\nThe paymaster’s safety relies on two structural constraints. First, delayed withdrawal: funds deposited into a canonical paymaster instance can only leave through gas payment or a time-locked withdrawal. A paymaster cannot deposit ETH, sponsor 1000 transactions, then instantly withdraw — the time lock prevents this mass-invalidation attack. Second, node-side pending balance tracking: nodes compute effective_balance = deposited - pending_gas_commitments per paymaster instance, where pending_gas_commitments is the sum of worst-case gas costs for all pending transactions using that instance. New transactions are rejected if the effective balance is insufficient.\nDuring the pay frame, the canonical paymaster gets an exemption from the generic SLOAD restriction. While only_verify restricts storage reads to tx.sender only (same as Strategy 1), the pay frame can read the paymaster’s own storage — its deposit balances and withdrawal timestamps. This exemption exists because the canonical code is vetted and well-known; it is admitted “by code match rather than by requiring it to satisfy each generic validation rule individually.”\nThe state footprint for Strategy 2 is everything from Strategy 1, plus:\n\nCanonical paymaster’s bytecode — to verify the code hash matches (or implement the check natively, since the code is known)\n\nCanonical paymaster’s storage — deposit balance and withdrawal timestamps, exempted from the tx.sender-only SLOAD restriction\n\nNode-local accounting — pending gas commitments per paymaster instance (not on-chain state)\n\nThis raises a question the spec does not address: instance proliferation. Since the canonical paymaster is recognized by code hash, anyone can deploy an instance. Each instance has independent storage. If there are 1-3 well-known instances per chain, the state burden is trivially bounded. If there are hundreds or thousands — each needing their deposit balance tracked — the state requirement grows with instance count. There is no protocol-level limit on the number of instances. In the worst case, this approaches Strategy 3’s unbounded state problem. The mitigating argument is economic: a paymaster with a large deposit pool is more useful than many small ones, so fragmentation is economically inefficient. But the protocol does not enforce this.\nThere is a second, arguably deeper risk: canonical paymaster adoption. Since the mempool policy is not a consensus rule, wallet providers are free to build non-canonical paymasters with richer feature sets — more flexible withdrawal logic, multi-token gas payment, programmable sponsorship policies. If these non-canonical implementations gain majority adoption, their transactions cannot enter the public mempool, cannot be picked up by arbitrary builders, and — critically — cannot be enforced by FOCIL. The censorship resistance story for AA transactions depends entirely on enough users routing through canonical, mempool-compliant paymasters. If the market routes around them, FOCIL becomes structurally toothless for account-abstracted transactions: it exists, but covers nothing. The EIP authors are confident Strategy 2 will be used, citing the strong incentive of public mempool access (any builder can include the tx, plus FOCIL enforcement). Whether that incentive outweighs the feature gap between canonical and non-canonical paymasters is an open question the market will answer.\nstrategy_21920×1107 221 KB\nFigure: Strategy 2 splits validation into two frames. The only_verify frame accesses sender state (same as Strategy 1). The pay frame accesses the canonical paymaster’s own storage (exempted from the sender-only SLOAD rule). Instance proliferation determines whether the paymaster state burden is bounded or not.\nStrategy 3 (Full ERC-7562) allows arbitrary paymasters — any contract can act as a paymaster, gated by staking and a node-local reputation system. This is the most permissive strategy and the most demanding in terms of state.\nWhere Strategy 2 constrains the paymaster to a single canonical bytecode with known storage layout, Strategy 3 removes that constraint. Any contract willing to stake ETH can serve as a paymaster. Staked entities get relaxed validation rules: the SLOAD restriction to tx.sender storage is lifted, allowing staked paymasters to read their own storage and potentially storage of other contracts they interact with during validation. The banned opcode list is also relaxed for staked entities. The safety model shifts from structural constraints (known code, delayed withdrawal) to economic constraints (stake at risk, reputation tracking).\nNodes manage DoS risk through a reputation system: they track how often each staked entity’s transactions are invalidated, how much gas is wasted on failed simulations, and whether the entity causes cascading invalidations. Entities that misbehave get throttled or banned. This requires ongoing observation — the node must simulate transactions, observe their outcomes, and maintain per-entity statistics across blocks.\nThe state footprint for Strategy 3 is unbounded along multiple dimensions:\n\nArbitrary paymaster bytecodes — nodes must load and execute any paymaster’s code, not just one canonical bytecode. Each paymaster has different logic, different storage layouts, different validation behavior.\n\nCross-account storage reads — staked entities can read storage from contracts other than tx.sender during validation. A staked paymaster might check a whitelist contract, a price oracle, or an access control registry. Each of these is additional state the node must have.\n\nReputation database — nodes must maintain a local database of per-entity behavior (simulation success rate, gas wasted, invalidation frequency). This requires seeing and simulating all transactions involving staked entities — impossible if the node lacks the state to simulate them.\n\nCascading invalidation risk — one storage change in a shared contract can invalidate every pending transaction whose validation depends on that contract. Strategy 1 prevents this structurally (sender-only storage). Strategy 2 limits it to canonical paymaster instances. Strategy 3 has no structural bound — the invalidation surface is as wide as the staked entity’s storage access.\n\nThese strategies were designed with full nodes in mind. They implicitly assume the validating node has access to any account’s code and storage on demand.\nFOCIL, AA-VOPS, and the eligibility bridge\nThe tension between frame transactions and partially stateful nodes is not just a mempool convenience problem — it directly affects censorship resistance through FOCIL.\nThomas Thiery’s proposal addresses this by defining an eligible subset of frame transactions that FOCIL can enforce, and introduces a concept directly relevant here: AA-VOPS. AA-VOPS extends VOPS by caching the first N storage slots per account (N in the range 2-4). Most smart wallets store their nonce, owner, and guardian in slots 0-3, so N slots covers the common validation pattern. The critical constraint (constraint 5 in the proposal): VERIFY may only read sender and payer account state plus their first N storage slots. Any read beyond this boundary renders the transaction ineligible — its omission is excused from FOCIL enforcement.\nAA-VOPS partially solves the storage half of the problem for frame transaction validation. But as established in the Strategy 1 analysis above, validation also requires bytecodes — the delegate contract’s code (via 7702 delegation) and potentially helper library code. Constraint 5 bounds storage reads but does not address code availability. An AA-VOPS node caching N slots per account still cannot execute the VERIFY frame if it lacks the delegate’s bytecode. This is an open gap in the AA-VOPS design: either bytecodes must be obtained through some external mechanism, or FOCIL-eligible frame transactions must be limited to accounts whose delegate code is widely available (e.g., a small set of well-known wallet implementations).\nThe base-case tension: thin accounts vs. rich wallets\nThere is a more fundamental tension that applies regardless of strategy: account abstraction makes accounts heavier, and statelessness needs accounts to stay light.\nVOPS’s 8.4 GB baseline rests on a specific assumption: EOAs are thin. An EOA today is ~40 bytes in the account trie — nonce, balance, empty codeHash, empty storageRoot. 400 million accounts at ~40 bytes yields roughly 10 GB. This number is the floor for censorship-resistance nodes: the minimum state needed to validate legacy transactions for any sender on the network.\nNative AA changes the per-account weight through two paths. EIP-7702 delegation gives EOAs a non-empty code field and — as the delegated code transacts over time — a growing storage trie (owner key, wallet nonce, guardian, session keys, permissions). EIP-8141’s deploy frame can convert an address into a full contract with code and storage in a single transaction. Either way, accounts that were ~40 bytes acquire storage tries that persist and grow.\nThe AA-VOPS N-slot constraint bounds what VERIFY can read per validation, but it does not bound the aggregate state a node must hold to validate frame transactions from arbitrary senders. Every account that adopts AA adds N cached storage slots to the validation-critical state set. At N=4 with 64 bytes per slot: if 25% of accounts adopt AA wallets (60M accounts), that adds ~15 GB — nearly doubling the VOPS baseline. At full adoption across 400M accounts, AA-VOPS reaches ~62 GB — an 8x increase over today’s VOPS, though still well below the ~280 GB full state.å\nAAVOPSGROWTH1920×1157 135 KB\nFigure: Validation-critical state grows linearly with AA adoption. At N=4 cached slots per account, moderate adoption nearly doubles the VOPS baseline; full adoption yields an 8x increase. The full state (~280 GB) remains distant, but the VOPS “floor” rises substantially.\nThomas Thiery’s FOCIL proposal offers a partial answer through AA-VOPS: cache N=2-4 storage slots per account, restrict VERIFY to those slots, and excuse any transaction that reads beyond this bound from FOCIL enforcement. This solves the per-validation problem — a node knows exactly what to fetch for each transaction, and the fetch set is small and deterministic. It also creates an incentive for wallet implementations to minimize validation storage reads to remain FOCIL-eligible. But it does not solve the aggregate problem: a node wanting to be a universal validator still needs N slots cached for every AA-enabled account, and this total grows linearly with adoption.\nThe approach also creates a two-tier system. Transactions from simple wallets that fit within N slots and the VERIFY gas budget get full FOCIL censorship resistance. Transactions that need more — post-quantum signature verification (which already exceeds MAX_VERIFY_GAS_PER_FRAMETX), privacy protocol interactions, complex multi-guardian recovery — fall outside eligibility. Their omission is excused. The transactions most likely to need censorship resistance (novel cryptography, privacy-preserving protocols) are precisely the ones that may not fit within the eligible subset.\nMore fundamentally, we cannot predict whether N=2-4 storage slots will remain sufficient as wallet implementations evolve. Today’s smart wallets may need only an owner and a nonce for validation. Tomorrow’s may need session key registries, cross-chain state, or social recovery graphs. Shipping a system where censorship resistance for abstracted accounts is structurally bounded by a fixed N risks a future where new use cases outgrow the bound — and where the interaction between statelessness and censorship resistance becomes unworkable precisely when it matters most.\nThis is not a per-strategy concern. Strategy 1 requires sender storage for validation. Strategy 2 adds paymaster storage on top. Strategy 3 adds arbitrary contract storage. But the base cost — sender storage across all AA-adopting accounts — applies to all three. The strategies differ in how much additional state they require beyond this base. The tension is structural: statelessness wants the minimum viable node to hold less state over time, so more nodes can participate and censorship resistance improves. Account abstraction wants every account to carry richer state over time, so wallets can implement better security models. These goals are not contradictory — the bounded state access rule mediates between them — but the mediation has a cost denominated in gigabytes, and that cost scales with adoption.\nCompatibility summary\n\nFull Node\nPS (w/ paymaster)\nPS (no paymaster)\nVOPS\nAA-VOPS\n\nAccount nonce + balance\nYes\nYes\nYes\nYes\n\nDelegate + helper bytecodes\nYes\nIf tracked\nIf tracked\nNo\n\nSender storage (N slots)\nYes\nIf tracked\nIf tracked\nNo\n\nPaymaster storage\nYes\nIf tracked†\nNo\nNo\n\nArbitrary contract storage\nYes\nNo\nNo\nNo\n\nStrategy 1 (self-relay)\nYes\nPartial\nPartial\nNo\n\nStrategy 2 (canonical paymaster)\nYes\nPartial–Yes†\nPartial\nNo\n\nStrategy 3 (ERC-7562)\nYes\nNo\nNo\nNo\n\n* AA-VOPS caches N storage slots per account but not bytecodes. VERIFY execution requires the delegate’s code. How AA-VOPS nodes obtain bytecodes is an open question — soispoke’s proposal bounds storage access but does not address code availability.\n† “If tracked” — PS nodes must explicitly track each canonical paymaster instance. Compatibility is strong when instances are few (1-3) and degrades with instance proliferation. See the instance proliferation discussion above.\nClosing\nFrame transactions are a powerful primitive for native account abstraction. But they carry two tensions that go deeper than mempool strategy selection.\nThe first is structural: statelessness needs accounts to stay thin, while account abstraction needs them to grow richer. The bounded state access rule (N slots per account) mediates this by capping per-validation reads, but the aggregate state grows linearly with AA adoption. Today’s ~10 GB VOPS baseline could reach ~20 GB at moderate adoption and past 60 GB at full adoption.\nThe second is economic: Strategy 2’s censorship resistance guarantees only apply to transactions using canonical, mempool-compliant paymasters. If wallet providers build richer non-canonical paymasters and users gravitate toward them, those transactions route through private builders, and FOCIL — designed to prevent censorship — covers nothing for the majority of AA transactions. The protocol decisions made around account abstraction will shape what “censorship resistant” means in practice, and whether the infrastructure we build for FOCIL inclusion of AA transactions has anyone to include.\n\nThe fear I have is that we take a decision without considering statelessness. Once ZKEVMs ship, a supermajority of nodes will be stateless or partially-stateful — and if the state needed for mempool validation has grown too large, almost nobody can keep the mempool healthy or participate in FOCIL. And if we get the canonical paymaster wrong — if wallet providers route around it because it doesn’t offer what users want — then even the nodes that can afford the state have nothing to enforce. FOCIL exists, but covers nobody. We greatly degrade the Censorship Resistance we have battled so much to finally have in Hegota.\n\n Frame Transactions and the Three Gates to Privacy\n\n 5\n\n 2\n\n 2\n\n read \n\n 11\n min\n\n post by DanielVF on Mar 30\n\n DanielVF\n\n Agreed with you. I think it’s a mistake to compare the benefits and costs of frame transactions only looking at current featureset of Ethereum. A real cost is in the future possibilities that frame transactions cut off.\nNow tradeoff might be worth it, but that’s a decision that should be made with eyes open.\nI think the key problem in frame transactions is the fact that block inclusion itself is gated on having access to extra state and code. If transactions could be included and pay for it, even if they revert later, without requiring the extra state, then the core problem that narrows future possibilities goes away.\n\n post by CPerezz on Mar 31\n\n CPerezz\n\n Notice that this works (some kind of commit-and-execute schema). On this way we only need balance and nonce and codeFlag to make sure that a tx can pay for the MINIMAL_FEE_THAT_PREVENTS_DOS.\nThe problem is how to reconcile this with Encrypted Mempools? See LUCID: Encrypted mempool with distributed payload propagation for instance. This won’t really allow us to do this as we no longer can check this. And it’s super hard for me to see how to have private txs, when we have to pay for DOS prevention work.\nSo, I don’t think is impossible to reconcile all this. But seriously needs work from all EIP authors involved. Otherwise it’s going to be hard.\n\n post by ParthSinghPS on Apr 7\n\n ParthSinghPS\n\nIf so, this implies not just reduced participation, but a structural shift where transaction visibility becomes dependent on node specific state coverage.\nIn that case, how are propagation and inclusion guarantees preserved, especially if some transactions never reach a sufficiently broad subset of the network to be picked up by builders or enforced via FOCIL?\n\n post by CPerezz on Apr 8\n\n CPerezz\n\n Yes! Exactly!!\nWe need the vast majority of the most “minimal” nodes to actually make sure that tx propagation has a high success rate. This translates into txs getting into ILs.\nSo yes, we essentially need to make sure that the canonical Paymaster is what wallets want and what gets broad adoption. Otherwise, we will be in trouble.\n\n post by zincoshine on Apr 10\n\n zincoshine\n\nAFAIU, in 4337, this was solved by every account having to deposit a small fee in the EntryPoint contract which was used as an inclusion fee (in case of invalidation). In theory, the same model should work for Frame transactions as well. Deploying a system contract at a known address and a validation for inclusion is performed against this address?\n\n post by zincoshine on Apr 10\n\n zincoshine\n\n That said, I don’t think this will address the issue with VOPS nodes. Thinking out loud, could this “inclusion deposit” be incorporated directly into the Account Trie?\n\n post by forshtat on Apr 10\n\n forshtat\n\n I am not familiar with this side of statelessness problem, only briefly discussed it with ChatGPT, but was there a discussion around something like “Validation Storage Rent” somewhere?\nMeaning, instead of simply hardcoding a fixed N=2 - 4 storage slots per account available for frame transaction validation, make accounts pay extra for storage they occupy in the validation state?\nFor example, in VERIFY frames make accounts read storage slots through a new opcode, say VOPSSLOAD, that additionally burns a small amount of ETH and sets a “deadline”, a future block height until which the read slot is available for VERIFY frame execution and FOCIL.\nThe first slot extended for a given address also covers the address’s bytecode.\nFor example, say, 1 wei per slot per block, 10 wei per address per block for bytecode, with the first accessed slot paying both fees (11 wei/block).\nWhen a slot’s deadline expires, VOPS nodes are free to evict it, and VOPSSLOAD fails to read this slot.\nTo keep active wallets from having to think about this, we could give a free 30-day deadline extension whenever a slot is legitimately accessed via VOPSSLOAD inside a VERIFY frame, so wallets that transact at least once a month auto-renew without any extra cost.\nDormant wallets that go silent for 30+ days fall out of the VOPS set.\nTo re-enter VOPS without generating state proofs and such, someone else may simply call the account’s “wake up” function in an EXECUTE frame which internally invokes VOPSSLOAD to re-register the needed slots and “pay the rent”.\nThe scheme kind of kick-starts istelf by having all existing storage treated as valid for VERIFY frames for the last 30 days before VOPS goes live.\nDoes something like this, or generally this direction make sense as a solution to the problem?\n\n post by CPerezz on Apr 11\n\n CPerezz\n\n zincoshine\n\n I don’t understand what the system contract does here. It collects the fees that everyone puts in order to use the gas sponsoring? If so, this is already breaking the privacy-solutions quite a lot.\nAlso, we should avoid system contracts as much as possible. We have more than desired.\n\nWhy do we need to enshrine things in protocol all time? The beauty of VOPS is that is out-of-protocol. We don’t have to change it to make it work.\nThe protocol is extremely complex already. And this makes it even more complex, and grows state further. And most of what is done, can already be done out of protocol.\nI care about protocol overall. I understand AA is an important thing. But frame in it’s Strategy 2 can’t even serve the “pay gas with USDX” usecase. So, if the solution is just “shove more stuff into protocol”. It doesn’t convince me.\nYou can disagree with ERC solutions. That’s fair. But you should also understand why some core devs try to propose alternatives to another complication addition to the protocol.\n\n post by CPerezz on Apr 11\n\n CPerezz\n\nState rent is one of the most complex in-protocol things to do. Solana tried and went away from it quickly. Lots of edge cases and UX burden.\n\nAs said above, the beauty of VOPS is to not require any protocol changes. It just works.\nAdding new opcodes and enshrining VOPS in-protocol seems like a bad move. Adds complexity and issues.\nAlso, notice you will force MORE STATE STORAGE. Because you force all nodes to track EVERY SLOT TIMESTAMP.\nI don’t think this is a way to go. But this is ofc only my opinion.\n\n post by forshtat on Apr 11\n\n forshtat\n\nYour post describes how Frame Transactions interact with Zero-Knowledge EVM, so looks like this ship has sailed \nOn a serious note, do you expect all of this complexity to appear for a FOCIL-only expiry as well?\n\nFair point, I would like to think about it. Is there a target validation state size for VOPS to hit?\nI understand the 400M accounts number is approximate for the present state of affair, is there a growth rate to take into account? Agentic wallets and all that?\nI apologize for asking basic questions, I sometimes have a hard time following the statelessness discussion.\n\n post by derekchiang on Apr 15\n\n derekchiang\n\nIsn’t another option to simply add code to VOPS? According to this article, as of 2024 contract bytecodes take up 245.5 * 4.3% = 10.55GB in total. That would double the size of VOPS, but still well below the size of the full state.\n\n Powered by Discourse","tokens":8049,"squid":"ink-research","role":"Deep Scholar","at":1791257319805,"hash":"79b9584417c9b1e42623cbcf7e1e760bb66e7fe5"}
{"url":"https://www.anchor-lang.com/docs/basics/pda","domain":"anchor-lang.com","title":"Program Derived Address","text":"The BasicsProgram Derived AddressLearn how to use Program Derived Addresses (PDAs) in Anchor programs to create deterministic account addresses.Program Derived Addresses (PDA) refer to a feature of Solana development that\nallows you to create a unique address derived deterministically from pre-defined\ninputs (seeds) and a program ID.\nThis section will cover basic examples of how to use PDAs in an Anchor program.\nAnchor PDA Constraints\nWhen using PDAs in an Anchor program, you generally use Anchor's account\nconstraints to define the seeds to derive the PDA. These constraints serve as\nsecurity checks to ensure that the correct address is derived.\nThe constraints used to define the PDA seeds include:\n\nseeds: An array of optional seeds used to derive the PDA. Seeds can be\nstatic values or dynamic references to account data.\nbump: The bump seed used to derive the PDA. Used to ensure the address falls\noff the Ed25519 curve and is a valid PDA.\nseeds::program - (Optional) The program ID used to derive the PDA address.\nThis constraint is only used to derive a PDA where the program ID is not the\ncurrent program.\n\nThe seeds and bump constraints are required to be used together.\nUsage Examples\nBelow are examples demonstrating how to use PDA constraints in an Anchor\nprogram.\nThe seeds constraint specifies the optional values used to derive the PDA.No Optional Seeds\nUse an empty array [] to define a PDA without optional seeds.\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n #[account(\n seeds = [],\n bump,\n )]\n pub pda_account: SystemAccount<'info>,\n}Single Static Seed\nSpecify optional seeds in the seeds constraint.\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n #[account(\n seeds = [b\"hello_world\"],\n bump,\n )]\n pub pda_account: SystemAccount<'info>,\n}Multiple Seeds and Account References\nMultiple seeds can be specified in the seeds constraint. The seeds\nconstraint can also reference other account addresses or account data.\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub signer: Signer<'info>,\n #[account(\n seeds = [b\"hello_world\", signer.key().as_ref()],\n bump,\n )]\n pub pda_account: SystemAccount<'info>,\n}The example above uses both a static seed (b\"hello_world\") and a dynamic seed\n(the signer's public key).\nPDA seeds in the IDL\nProgram Derived Address (PDA) seeds defined in the seeds constraint are\nincluded in the program's IDL file. This allows the Anchor client to\nautomatically resolve account addresses using these seeds when constructing\ninstructions.\nThis example below shows the relationship between the program, IDL, and client.\nThe program below defines a pda_account using a static seed (b\"hello_world\")\nand the signer's public key as a dynamic seed.use anchor_lang::prelude::*;\n\ndeclare_id!(\"BZLiJ62bzRryYp9mRobz47uA66WDgtfTXhhgM25tJyx5\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn test_instruction(ctx: Context<InstructionAccounts>) -> Result<()> {\n msg!(\"PDA: {}\", ctx.accounts.pda_account.key());\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub signer: Signer<'info>,\n #[account(\n seeds = [b\"hello_world\", signer.key().as_ref()],\n bump,\n )]\n pub pda_account: SystemAccount<'info>,\n}PreviousProgram IDL FileNextCross Program InvocationOn this pageAnchor PDA ConstraintsUsage ExamplesPDA seeds in the IDLEdit on GitHub","tokens":836,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257323998,"hash":"7e509534f1c226a60391926c4e2d73eaae9e02b1"}
{"url":"https://ethresear.ch/","domain":"ethresear.ch","title":"Ethereum Research","text":"All latest topics\n\n categories\n\n tags\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Read this before posting\n\n Administrivia\n\n This is a semi-public forum for participating in Ethereum’s research efforts, including but not limited to: \n\nProof-of-Stake\nPost Quantum\nZero-Knowledge work\nScaling solutions\nEVM improvements\nLow-level protocol improvem…\n\n read more\n\n 13\n\n 61.5k\n\n Aug 19\n\n Accountability for Encrypted Mempools\n\n Cryptography\n\n mev,censorship-resistance\n\n 0\n\n 78\n\n 14h\n\n Mempool Account Transaction Capacity from Historical Activity (MATCHA)\n\n Execution Layer Research\n\n account-abstraction,transaction-privacy\n\n 11\n\n 539\n\n 18h\n\n Proposal for a minimal compute-anchored purchasing power signal\n\n Economics\n\n 0\n\n 53\n\n 3d\n\n Six defects in one signature verification tool, found from outside in six rounds\n\n Security\n\n 0\n\n 50\n\n 3d\n\n The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\n\n Execution Layer Research\n\n stateless\n\n 10\n\n 782\n\n 4d\n\n Staking rewards as venture capital, governed by futarchy\n\n Economics\n\n dao,futarchy\n\n 2\n\n 214\n\n 4d\n\n Trust minimized transaction simulation using state proofs\n\n Security\n\n 7\n\n 632\n\n 5d\n\n PQ anonymity for Stealth Address Protocol\n\n Privacy\n\n 4\n\n 208\n\n 5d\n\n Letting the base fee be a midpoint: a temporal liquidity authorization for EIP-1559\n\n Economics\n\n mev,proposer-builder-separation,fee-market,eip-1559\n\n 1\n\n 148\n\n 6d\n\n Towards Encrypted Mempools from Threshold IBE without Batching\n\n Cryptography\n\n 4\n\n 234\n\n 6d\n\n Ethereum’s TCB, Part 1: The client\n\n Security\n\n security\n\n 3\n\n 347\n\n 7d\n\n PQ spending for Stealth Address Protocol\n\n 0\n\n 63\n\n 8d\n\n Ethereum lessons from a live end-to-end PQ proof-native protocol\n\n Architecture\n\n post-quantum,zero-knowledge\n\n 6\n\n 411\n\n 8d\n\n Formal Verification of Execution and Consensus Clients\n\n Security\n\n security\n\n 12\n\n 599\n\n 11d\n\n Snappy with a memory: ~40% less gossip traffic\n\n Networking\n\n single-slot-finality\n\n 1\n\n 150\n\n 11d\n\n Capacity oracles\n\n Economics\n\n 4\n\n 410\n\n 11d\n\n Designs for EVM gas accounting in EIP-7999\n\n Execution Layer Research\n\n fee-market\n\n 6\n\n 462\n\n 11d\n\n Proprietary AMMs and Ethereum\n\n Execution Layer Research\n\n mev\n\n 13\n\n 1.3k\n\n 12d\n\n CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\n\n Execution Layer Research\n\n p2p,networking\n\n 0\n\n 106\n\n 12d\n\n Post-Poseidon: Hash Function Variants for Ethereum\n\n Cryptography\n\n 0\n\n 311\n\n 13d\n\n EIP-8411 payload segmentation under the Shadow simulator\n\n Networking\n\n p2p,scaling\n\n 0\n\n 79\n\n 13d\n\n Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers\n\n Cryptography\n\n post-quantum\n\n 1\n\n 179\n\n 14d\n\n Etheorem update: the complete executable consensus specs written in Lean 4\n\n Consensus\n\n 0\n\n 190\n\n 15d\n\n Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999\n\n Economics\n\n 0\n\n 147\n\n 15d\n\n Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\n\n Privacy\n\n 0\n\n 53\n\n 17d\n\n Cryptographic canaries and backups\n\n Cryptography\n\n 8\n\n 7.6k\n\n 18d\n\n Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter\n\n Execution Layer Research\n\n 1\n\n 131\n\n 18d\n\n Bounding Collusion in Capital Allocation DAOs via Subjective Human Oracles\n\n Economics\n\n public-good,dao,collusion\n\n 4\n\n 157\n\n 18d\n\n How Hegotá can influence the state roadmap\n\n Execution Layer Research\n\n 1\n\n 218\n\n 19d","tokens":874,"squid":"ink-research","role":"Deep Scholar","at":1791257330189,"hash":"c6dbb7b261cc309238b85c72474caeac8a74c804"}
{"url":"https://www.openzeppelin.com/","domain":"openzeppelin.com","title":"OpenZeppelin | The Security Standard for Onchain Finance","text":"The security standard for onchain financeFinance is moving onchain with OpenZeppelin. The institutions and technology innovators leading that shift move faster when security is never in question, from first design through production.Talk to an ExpertTotal value transferred via OpenZeppelin ContractsExplore Stats$38,211,353,386,986Read Customer StoriesOnchain finance already runs on OpenZeppelinWe shaped the open smart contract standards onchain finance has run on for a decade, and we keep them open by design. Shared, audited standards are how the industry moves forward together, and how institutions adopt onchain with confidence.9 of the top 10 stablecoinsby market cap build on OpenZeppelin Contracts10 of the top 10 tokenized money market fundsby market cap build on OpenZeppelin ContractsSecurity shaped to the world you operate inA bank, a network, and a regulator do not share a risk model, compliance requirements, or a stakeholder map. We bring security and risk management made for the specifics of each, not a template stretched to fit.Financial InstitutionsBanksAsset ManagersPayment NetworksTokenization PlatformsCapital Markets InfrastructureFintechs & NeobanksNetworks & ProtocolsBlockchain NetworksDeFi ProtocolsPublic Sector & RegulatorsCentral BanksRegulators & Standards Bodies“OpenZeppelin has been a continuous partner from architecture through deployment, across both our Ethereum and Solana work, and this consistency and rigor allows us to advance WisdomTree’s tokenization roadmap confidently, at scale.”— Jason Guthrie, Head of Product, Digital Assets, WisdomTreeTake your most critical onchain initiatives to production, securelyThese are the programs where the value and the scrutiny run highest. We cover each one end to end, so yours reaches production on ground you can stand behind.Tokenization & Asset IssuanceIssue and manage tokenized, securities, and real-world assets. We make sure every instrument is secure before it represents real value, and stays that way after.Stablecoins & Tokenized DepositsLaunch and operate stablecoins and deposit tokens on the standards behind 9 of the top 10 stablecoins, and issue money your holders and regulators can trust.Collateral, Repo & TreasuryBring collateral, repo, and treasury operations onchain. We help you automate balance-sheet operations without automating in risk, with controls your risk teams can verify.Custody & Asset ServicingSafeguard client assets in custody, key management, and asset servicing. We secure the whole system around the assets, not just the contract.Onchain Asset Management & YieldLaunch vaults, tokenized funds, and yield products on the standards behind onchain asset management. We secure the strategy logic, accounting, and access controls your investors and regulators rely on.Payments, Settlement & Cross-BorderMove value across payment rails, settlement, and cross-border corridors. We help you run around the clock without exposure growing with the volume.Proven where the stakes are highestThe institutions and protocols setting the pace onchain, and how they reached production with confidence.Read All Customer StoriesOpenZeppelin secures CACEIS Bank euro stablecoin EURXT, ahead of issuance under MiCAUSDT0 secures the expansion of the world's largest stablecoin with OpenZeppelinUniswap v4 launches successfully after OpenZeppelin's comprehensive security reviewContinuous Security ProgramYour systems never stop changing. Your security shouldn't either.Onchain systems ship, integrate, and upgrade continuously. Continuous Security covers them the same way, across architecture, development, security, and ongoing support, in any direction as they evolve. A decade of OpenZeppelin standards and expertise, scaled by OpenZeppelin AI.Talk to an ExpertExplore the ProgramHeld to the standards your institution already answers toOpenZeppelin meets the highest security and compliance standards while actively shaping industry regulations and engaging with global regulators and policymakers.Security & ComplianceSOC 2 Type IICCSSGDPRCCPAIndustry Standards ContributionsISOBlockchain Security Standards CouncilEnterprise Ethereum AllianceLinux Foundation Decentralized TrustRegulatory EngagementU.S. TreasurySECUK FCAFrench ACPR/AMFHong Kong SFCHong Kong Monetary AuthorityThe foundation developers rely on across every major chainOpenZeppelin Contracts is the most widely used smart contract library onchain: the libraries, the Contract Wizard, the Contracts MCP, the Contracts Skills and Ethernaut for security education.Explore Contracts & Tools​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍​‍‌​‌‌​‌‌‌‌‍‌​‌‍‍‌‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌​‌​‌‍​‍​‍​‌‍‌‌​‌‍​‌​​‍​‌‍‌‍​‍‌​​‌‍​‌‍​‍‌‍‌‍​‍‌​‌​‌‍​‌​‌‌‌‍​​‍‌‌‍​‍​​‍​‌‌‍‌​​‍‌‌‍​​‌‍​​‍​‌‍​​‍​​​​‌‍‌‍​‍​‌‌‌‍​‍​​‌‌‍​​‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌​​‌‍​‌‌‍‌‌‍‌‌​‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‍​‍‌‍​‌‍‌‍​‌‍‍‌​​‍‌‌​‌‌‌​​‍‌‌‌‍‍‌‍‌‌‌‍‌​‍‌‌​​‌​‌​​‍‌‌​​‌​‌​​‍‌‌​​‍​​‍‌‍​‍​‌‌​​​​​‌‍‌‌​‌‍​​​​‌‍​‌‌‍‌‌‌‍​​‍​​‍‌‌​​‍​​‍​‍‌‌​‌‌‌​‌​​‍‍‌‍​‌‍‍‌‌‍‍‌‍‍‌​​‍‌‌​‌‌‌​​‍‌‌‌‍‍‌‍‌‌‌‍‌​‍‌‌​​‌​‌​​‍‌‌​​‌​‌​​‍‌‌​​‍​​‍​​​​‌‌‍‌‍‌‍‌‍​‌‍‌‍‌‌​‌‌‌‍​‌​​‍​​​‌‍‌‍‌‍‌‌​‍‌‌​​‍​​‍​‍‌‌​‌‌‌​‌​​‍‍‌‍​‌‍​‌‌‍​‍‌‍‌‌‌‍​​‌‍​‍‌‍​‌‌​‌‍‌‌‌‌‌‌‌​‍‌‍​​‌​‍‌‌​​‍‌​‌‍‌​‌‌​‌‌‌‌‍‌​‌‍‍‌‌‍​‍‌‍‌‍‍‌‌‍‌​​‌​‌​‌‍​‍​‍​‌‍‌‌​‌‍​‌​​‍​‌‍‌‍​‍‌​​‌‍​‌‍​‍‌‍‌‍​‍‌​‌​‌‍​‌​‌‌‌‍​​‍‌‌‍​‍​​‍​‌‌‍‌​​‍‌‌‍​​‌‍​​‍​‌‍​​‍​​​​‌‍‌‍​‍​‌‌‌‍​‍​​‌‌‍​​‍‌‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌​​‌‍​‌‌‍‌‌‍‌‌​‍‌‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‍​‍‌‍​‌‍‌‍​‌‍‍‌​​‍‌‌​‌‌‌​​‍‌‌‌‍‍‌‍‌‌‌‍‌​‍‌‌​​‌​‌​​‍‌‌​​‌​‌​​‍‌‌​​‍​​‍‌‍​‍​‌‌​​​​​‌‍‌‌​‌‍​​​​‌‍​‌‌‍‌‌‌‍​​‍​​‍‌‌​​‍​​‍​‍‌‌​‌‌‌​‌​​‍‍‌‍​‌‍‍‌‌‍‍‌‍‍‌​​‍‌‌​‌‌‌​​‍‌‌‌‍‍‌‍‌‌‌‍‌​‍‌‌​​‌​‌​​‍‌‌​​‌​‌​​‍‌‌​​‍​​‍​​​​‌‌‍‌‍‌‍‌‍​‌‍‌‍‌‌​‌‌‌‍​‌​​‍​​​‌‍‌‍‌‍‌‌​‍‌‌​​‍​​‍​‍‌‌​‌‌‌​‌​​‍‍‌‍​‌‍​‌‌‍​‍‌‍‌‌‌‍​​‍​‍‌‌ArbitrumBaseCantonEthereumLineaMidnightOP MainnetStarknetStellarSuiZamaZKsyncSupported across all major blockchain networks Explore all“Our partnership with OpenZeppelin is critical. Their role extends far beyond traditional audits; they’re embedded in our design process, our reviews, and our monitoring frameworks. Their deep expertise gives us the confidence to push boundaries, knowing that security will scale with us.”— Vlad Bochok, Protocol & Security Engineer, Matter LabsLatest from OpenZeppelinExplore NewsExplore ResearchCustomer StoriesOpenZeppelin secures CACEIS Bank euro stablecoin EURXT, ahead of issuance under MiCAProduct Releases & ServicesOpenZeppelin and T-REX Network Rebuild ONCHAINID as a Smart Account for Regulated AssetsProduct Releases & ServicesOpenZeppelin Brings Its Security Standard to the TRON NetworkSecurity InsightsIf You’re Regulated Under MiCA, You’re Also Regulated Under DORACompanyS&P Global Enters Agreement to Acquire OpenZeppelinSecurity InsightsFrom Algebra to Noise: Why Post-Quantum Cryptography Looks DifferentSubscribe to The Onchain BriefMonthly insights for institutional onchain teams: what's moving in security, regulation, and market structure, and what it means for your program.","tokens":1824,"squid":"ink-security_audits","role":"Sentinel","at":1791257332436,"hash":"edf75d81089b54514a0d9e7765284a899e6db37b"}
{"url":"https://www.anchor-lang.com/docs/basics/idl","domain":"anchor-lang.com","title":"Program IDL File","text":"The BasicsProgram IDL FileLearn about the Interface Description Language (IDL) file in Anchor, its purpose, benefits, and how it simplifies program-client interactionsAn Interface Description Language (IDL) file for an Anchor program provides a\nstandardized JSON file describing the program's instructions and accounts. This\nfile simplifies the process of integrating your on-chain program with client\napplications.\nKey Benefits of the IDL:\n\nStandardization: Provides a consistent format for describing the program's\ninstructions and accounts\nClient Generation: Used to generate client code to interact with the program\nOn-chain Storage: IDLs can be stored on-chain using\nProgram Metadata,\nallowing clients to fetch and use the IDL directly from the blockchain\n\nThe anchor build command generates an IDL file located at\n/target/idl/<program-name>.json.\nOn-chain IDL storage uses the Program Metadata system. This reduces program\nbinary sizes and provides a standardized approach to on-chain metadata. Use\nanchor idl init to upload your IDL to the blockchain.\nThe code snippets in the sections below highlight how the program, IDL, and\nclient relate to each other.\nProgram Instructions\nThe instructions array in the IDL corresponds directly to the instructions\ndefined in your program. It specifies the required accounts and parameters for\neach instruction.\nThe program below includes an initialize instruction, specifying the accounts\nand parameters it requires.lib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"BYFW1vhC1ohxwRbYoLbAWs86STa25i9sD5uEusVjTYNd\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64,\n}\nProgram Accounts\nThe accounts array in the IDL corresponds to the structs in a program\nannotated with the #[account] attribute. These structs define the data stored\non accounts created by the program.\nThe program below defines a NewAccount struct with a single data field of\ntype u64.lib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"BYFW1vhC1ohxwRbYoLbAWs86STa25i9sD5uEusVjTYNd\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64,\n}\nDiscriminators\nAnchor assigns a unique 8 byte discriminator to each instruction and account\ntype in a program. These discriminators serve as identifiers to distinguish\nbetween different instructions or account types.\nThe discriminator is generated using the first 8 bytes of the Sha256 hash of a\nprefix combined with the instruction or account name. As of Anchor v0.30, these\ndiscriminators are included in the IDL file.\nNote that when working with Anchor, you typically won't need to interact\ndirectly with these discriminators. This section is primarily to provide\ncontext on how the discriminator is generated and used.\nThe instruction discriminator is used by the program to determine which specific\ninstruction to execute when called.When an Anchor program instruction is invoked, the discriminator is included as\nthe first 8 bytes of the instruction data. This is done automatically by the\nAnchor client.IDL \"instructions\": [\n {\n \"name\": \"initialize\",\n \"discriminator\": [175, 175, 109, 31, 13, 152, 155, 237],\n ...\n }\n ]The discriminator for an instruction is the first 8 bytes of the Sha256 hash of\nthe prefix global plus the instruction name.For example:sha256(\"global:initialize\")Hexadecimal output:af af 6d 1f 0d 98 9b ed d4 6a 95 07 32 81 ad c2 1b b5 e0 e1 d7 73 b2 fb bd 7a b5 04 cd d4 aa 30The first 8 bytes are used as the discriminator for the instruction.af = 175\naf = 175\n6d = 109\n1f = 31\n0d = 13\n98 = 152\n9b = 155\ned = 237You can find the implementation of the discriminator generation in the Anchor\ncodebase\nhere,\nfor the\ngen_discriminator method here,\nwhich is used\nhere.PreviousProgram StructureNextProgram Derived AddressOn this pageProgram InstructionsProgram AccountsDiscriminatorsEdit on GitHub","tokens":1163,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257336212,"hash":"c04920ecfa944c715cdca0cef5d7df4ca2601cce"}
{"url":"https://ethresear.ch/u/micahzoltu","domain":"ethresear.ch","title":"Summary - MicahZoltu - Ethereum Research","text":"Skip to profile content\n\n MicahZoltu\n\n Micah Zoltu\n\n Joined\n\n Aug 17, 2017\n\n Last Post\n\n Sep 3\n\n Seen\n\n Sep 24\n\n Views11030\n Trust Levelmember\n\n Stats\n\n 648\n\n days visited\n\n 1d\n\n read time\n\n 3m\n\n recent read time\n\n 435\n\n topics viewed\n\n 3.2k\n\n posts read\n\n 70\n\n given\n\n 558\n\n received\n\n 4\n\n topics created\n\n 494\n\n posts created\n\n Top Replies\n\n Dec 2023\n ·\n  14\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Nov 2023\n ·\n  8\n\n Privacy and Regulation in our decentralized future\n\n Dec 2022\n ·\n  8\n\n 2FA zk-rollups using SGX\n\n Dec 2024\n ·\n  7\n\n On Increasing the Block Gas Limit: Technical Considerations & Path Forward\n\n Oct 2024\n ·\n  7\n\n What happened to our decentralized private new internet?\n\n Oct 2022\n ·\n  7\n\n EIP-3541 locks my ETH in contract forever. What should I do?\n\n More Replies\n\n Top Topics\n\n Apr 2018\n ·\n  6\n\n Incentivizing full state nodes\n\n Apr 2024\n ·\n  4\n\n Charity Bond Account Generation for Social Networks and More\n\n May 2024\n ·\n  3\n\n Queue End Of Block Transaction OPCODE\n\n Feb 2018\n ·\n  1\n\n OpSec for building/operating an chain anonymously?\n\n Top Links\n\n yellowpaper.io\n\n Gas price table\n\n github.com/Giveth/minime\n\n Efficient Onchain Reward Distribution (pooled payments, dividends)\n\n medium.com/@epheph/what-fomo3ds-real-exit-scam-might-look-like-ac5794f72099\n\n Alert! Will Fomo3D destroy Ethereum?\n\n github.com/Zoltu/recoverable-wallet/blob/master/README.md\n\n Sovereign Social Recovery Mechanism\n\n github.com/ethereum/EIPs/issues/719\n\n Enforceable Human-Readable Transactions: how to solve Bybit-like hacks\n\n github.com/ethereum/EIPs/issues/719\n\n Proposal: Minimizing fraudulent transactions in Metamask, e.g via front-end hacks\n\n Most Replied To\n\n kladkogex\n\n Stan Kladko\n\n 11\n\n vbuterin\n\n Vbuterin\n\n 9\n\n clesaege\n\n Clément Lesaege\n\n 8\n\n Zergity\n\n Zergity\n\n 7\n\n quickBlocks\n\n Thomas Jay Rush\n\n 6\n\n kevin-hs-sohn\n\n Kevin\n\n 5\n\n Most Liked By\n\n abcoathup\n\n Andrew B Coathup\n\n 27\n\n donnoh\n\n Luca Donno\n\n 19\n\n GCdePaula\n\n Gabriel Coutinho de Paula\n\n 16\n\n sina\n\n sina.eth\n\n 14\n\n randomishwalk\n\n Eric Siu\n\n 14\n\n 0xapriori\n\n apriori\n\n 11\n\n Most Liked\n\n vbuterin\n\n Vbuterin\n\n 8\n\n pcaversaccio\n\n 3\n\n CPerezz\n\n CPerezz\n\n 3\n\n imkharn\n\n Imkharn\n\n 2\n\n pipermerriam\n\n Piper Merriam\n\n 2\n\n quickBlocks\n\n Thomas Jay Rush\n\n 2\n\n Top Categories\n\n Topics\n Replies\n\n Economics\n\n 2\n\n 111\n\n Applications\n\n –\n\n 62\n\n Execution Layer Research\n\n 1\n\n 40\n\n Privacy\n\n –\n\n 37\n\n Security\n\n –\n\n 35\n\n Layer 2\n\n –\n\n 26\n\n Top Badges\n\n Member\n\n Granted invitations, group messaging, more likes\n\n Respected\n\n Received 2 likes on 100 posts\n\n Hot Link\n\n Posted an external link with 300 clicks\n\n Anniversary\n\n Active member for a year, posted at least once\n\n 9 awarded\n\n Nice Reply\n\n Received 10 likes on a reply\n\n Thank You\n\n Has 20 liked posts and gave 10 likes\n\n More Badges\n\n Powered by Discourse","tokens":700,"squid":"ink-research","role":"Deep Scholar","at":1791257343359,"hash":"08c87ad8e9fe857486864ddff2e107adbb19fc0a"}
{"url":"https://www.openzeppelin.com/stats/contracts","domain":"openzeppelin.com","title":"OpenZeppelin Contracts Stats | OpenZeppelin","text":"OpenZeppelin ContractsGitHubTracked chainsTotal Value TransferredTotal Value Transferred from OpenZeppelin smart contracts to other contracts and addresses.$37,992,487,281,209RangeAllLast yearLast 6 monthsLast month9 of the top 10 Stablecoins by market capitalization build on OpenZeppelin ContractsEthena USDeBitGo USD1Circle USDCPayPal USDFalcon USDPaxos Global DollarAnchorage Digital USDTBRipple RLUSDSky USDS10 of the top 10 Tokenized Funds by market capitalization build on OpenZeppelin ContractsBlackRock BUIDLCircle USYCOndo OUSGWisdomTree WTGXXTheo thBILLSuperstate USTBFidelity FditFranklin BENJICentrifuge JTRSYOndo USDYTotal Value LockedTotal Value Locked in smart contracts that import OpenZeppelin contracts.$151,081,789,844RangeAllLast yearLast 6 monthsLast monthTransactions ProcessedTotal number of transactions sent through OpenZeppelin smart contracts.6,900,491,688RangeAllLast yearLast 6 monthsLast monthActive WalletsTotal number of active EOA (Externally Owned Accounts) wallets interacting with OpenZeppelin Contracts. A wallet is defined as active if it interacted with any contract at least once.428,381,724RangeAllLast yearLast 6 monthsLast monthExplore more OpenZeppelin Contracts DataThis dashboard aims to show the key metrics of usage of the OpenZeppelin Contracts Library. Metrics shown are best estimates. Data collection is complex, and we’re constantly refining our process and adding more chains.Dune Dashboard","tokens":361,"squid":"ink-security_audits","role":"Sentinel","at":1791257343405,"hash":"e0ef28fec04a7b504f18a923ef1ec4661384a34a"}
{"url":"https://www.anchor-lang.com/docs/quickstart/local","domain":"anchor-lang.com","title":"Local Development","text":"QuickstartLocal DevelopmentLearn how to build Solana programs using the Anchor framework on your local machine.The Anchor framework is a tool that simplifies the process of building Solana\nprograms. Whether you're new to blockchain development or an experienced\nprogrammer, Anchor simplifies the process of writing, testing, and deploying\nSolana programs.\nIn this section, we'll walk through:\n\nCreating a new Anchor project\nBuilding and testing your program\nDeploying to Solana clusters\nUnderstanding the project file structure\n\nPrerequisites\nFor detailed installation instructions, visit the\ninstallation page.\nBefore you begin, ensure you have the following installed:\n\nRust: The programming language for building Solana programs.\nSolana CLI: Command-line tool for Solana development.\nAnchor CLI: Command-line tool for the Anchor framework.\n\nTo verify Anchor CLI installation, open your terminal and run:\nanchor --version\nExpected output:\nanchor-cli 1.2.0\nGetting Started\nThis section covers the basic steps to create, build, and test your first local\nAnchor program.\nCreate a new ProjectTo start a new project, use the anchor init command followed by your project's\nname. This command creates a new directory with the specified name and sets up a\ndefault program and test file.anchor init my-projectNavigate to the new project directory and open it in your code editor.cd my-projectBy default, Anchor generates a modular program structure to promote better code\norganization and maintainability. The program files are organized as follows:\n/programs/my-project/src/lib.rs - Main entry point with module declarations\n/programs/my-project/src/instructions/ - Instruction handlers\n/programs/my-project/src/state/ - Account structures and state\n/programs/my-project/src/constants.rs - Program constants\n/programs/my-project/src/error.rs - Custom error definitions\nThe default Typescript test file is located at /tests/my-project.ts.If you prefer Rust for testing, initialize your project with the\n--test-template rust (Anchor Rust client) or\n--test-template mollusk (Mollusk test library) flag.anchor init --test-template rust my-programThe Rust test file will be at /tests/src/test_initialize.rs.Build the ProgramBuild the program by running anchor build.anchor buildThe compiled program will be at /target/deploy/my_project.so. The content of\nthis file is what gets stored on the Solana network (as an executable account)\nwhen you deploy your program.Test the ProgramTo test the program, run anchor test.anchor testBy default, the Anchor.toml config file specifies the localnet cluster. When\ndeveloping on localnet, anchor test will automatically:\nStart a local Solana validator\nBuild and deploy your program to the local cluster\nRun the tests in the tests folder\nStop the local Solana validator\nAlternatively, you can manually start a local Solana validator and run tests\nagainst it. This is useful if you want to keep the validator running while you\niterate on your program. It allows you to inspect accounts and transaction logs\non the Solana Explorer while\ndeveloping locally.Open a new terminal and start a local Solana validator by running the\nsolana-test-validator command.solana-test-validatorIn a separate terminal, run the tests against the local cluster. Use the\n--skip-local-validator flag to skip starting the local validator since it's\nalready running.anchor test --skip-local-validatorDeploy to DevnetBy default, the Anchor.toml config file in an Anchor project specifies the\nlocalnet cluster.[toolchain]\n\n[features]\nresolution = true\nskip-lint = false\n\n[programs.localnet]\nmy_program = \"3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg\"\n\n[provider]\ncluster = \"Localnet\"\nwallet = \"~/.config/solana/id.json\"\n\n[scripts]\ntest = \"yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts\"To deploy your program to devnet, change the cluster value to Devnet.Note that deploying to devnet requires your wallet to have enough SOL to cover\ndeployment cost. You can get devnet SOL using the\nWeb Faucet.-cluster = \"Localnet\"\n+cluster = \"Devnet\"[provider]\ncluster = \"Devnet\"\nwallet = \"~/.config/solana/id.json\"Now when you run anchor deploy, your program will be deployed to the devnet\ncluster. The anchor test command will also use the cluster specified in the\nAnchor.toml file.anchor deployTo deploy to mainnet, simply update the Anchor.toml file to specify the\nmainnet cluster.[provider]\ncluster = \"Mainnet\"\nwallet = \"~/.config/solana/id.json\"Update the ProgramSolana programs can be updated by redeploying the program to the same program\nID.To update a program, simply make changes to your program's code and run the\nanchor build command to generated an updated .so file.anchor buildThen run the anchor deploy command to redeploy the updated program.anchor deployClose the ProgramTo reclaim the SOL allocated to a program account, you can close your Solana\nprogram.To close a program, use the solana program close <PROGRAM_ID> command. For\nexample:solana program close 3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg --bypass-warningNote that once a program is closed, the program ID cannot be reused to deploy a\nnew program.\nProject File Structure\nBelow is an overview of default file structure in an Anchor workspace:\n\nlib.rsconstants.rserror.rsmod.rsinitialize.rsCargo.toml[project-name].tsAnchor.tomlCargo.tomlpackage.json\n\nPrograms Folder\nThe /programs directory contains your project's Anchor programs. A single\nworkspace can contain multiple programs.\nBy default, programs are organized with a modular structure:\n\nlib.rs - Main entry point that declares and exports modules\ninstructions/ - Directory containing instruction handler functions\nstate/ - Directory for account structures and state definitions\nconstants.rs - Program-wide constants\nerror.rs - Custom error codes\n\nThis modular organization makes it easier to navigate and maintain your code,\nespecially as your program grows in complexity.\nTests Folder\nThe /tests directory contains test files for your project. A default test file\nis created for you when you create your project.\nTarget Folder\nThe /target directory contains build outputs. The main subfolders include:\n\n/deploy: Contains the keypair and program binary for your programs.\n/idl: Contains the JSON IDL for your programs.\n/types: Contains the TypeScript type for the IDL.\n\nAnchor.toml File\nThe Anchor.toml file configures workspace settings for your project.\n.anchor Folder\nIncludes a program-logs file that contains transaction logs from the last run\nof test files.\nApp Folder\nThe /app folder is an empty folder that can be optionally used for your\nfrontend code.PreviousSolana PlaygroundNextAnchor Framework BasicsOn this pagePrerequisitesGetting StartedCreate a new ProjectBuild the ProgramTest the ProgramDeploy to DevnetUpdate the ProgramClose the ProgramProject File StructurePrograms FolderTests FolderTarget FolderAnchor.toml File.anchor FolderApp FolderEdit on GitHub","tokens":1728,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257347026,"hash":"fc72cd0a20e96ee09307922a0c529709cf453c19"}
{"url":"https://gov.optimism.io/latest","domain":"gov.optimism.io","title":"Optimism Collective","text":"Welcome to the Collective\n\n Optimism Collective's Governance Forum\n\n Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n All latest topics\n\n categories\n\n tags\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Working Constitution of the Optimism Collective\n\n Get Started 🌱\n\n The Optimism Collective is a large-scale experiment in decentralized governance. Our Vision is to sustainably fund those public goods that improve upon the well-being of the Collective and beyond. This Working Constituti…\n\n read more\n\n 628\n\n 61.4k\n\n 28d\n\n Protocol Delegation Program Renewal\n\n Metagovernance\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d\n\n 404 Gov - Delegate Platform\n\n Delegates 🏛\n\n An important update regarding the future of 404 DAO’s governance operations. \nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What sta…\n\n read more\n\n 1\n\n 59\n\n 1d\n\n Introducing improvements to the Protocol Upgrade process\n\n Updates and Announcements 📢\n\n season-8\n\n As communicated in the Season 8 announcements, we launched significant improvements to the Protocol Upgrade process on August 1st. Here’s what you need to know: \nTL;DR\n\nProtocol upgrades now require approval by the Deve…\n\n read more\n\n 7\n\n 342\n\n 1d\n\n Proposal to Align the OP Token with Superchain Success\n\n Proposals 📃\n\n season-9\n\n Proposal to Align OP Token with Superchain Success\nThis proposal was updated on 1/15/26 to reflect community feedback to split the original proposal into two separate proposals. \nExecutive Summary\n\nThis proposal would im…\n\n read more\n\n 36\n\n 4.3k\n\n 1d\n\n Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\n\n Proposals 📃\n\n Proposal Type: Rights Protections \nExecutive Summary\nThe Optimism Foundation is proposing to re-designate the unspent tokens in the User Airdrop allocation as a new allocation category, the Strategic Ecosystem Fund, prop…\n\n read more\n\n 12\n\n 1.3k\n\n 9d\n\n Exploring execution-time authorization for Superchain applications\n\n ✨ General\n\n I’d like to get feedback from Optimism builders and the broader Superchain community on a potential infrastructure primitive for applications, payment flows, smart accounts and autonomous transaction systems. \nThe proble…\n\n read more\n\n 4\n\n 64\n\n 11d\n\n [RFC] Civilizational Upgrade: Implementing the ACOM P2P Semantic Mesh & Holographic Chain on the OP Superchain\n\n Governance Design and Strategy 📐\n\n Authors: The Promethean Network State (TPNS) & The Promethean Institute\nCategory: Technical Integration, Infrastructure, Real-World Utility, Public Goods\nStatus: Active RFC / Proposed Integration\n\n1. Core Philosophy: I…\n\n read more\n\n 4\n\n 123\n\n 11d\n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\n\n Community Calls\n\n Dear Optimists, \nWelcome to Eden Fractal Epoch 2! \nAfter three transformative years of pioneering fractal governance, Eden Fractal is entering its second epoch—a new chapter where we move from experimentation to …\n\n read more\n\n 32\n\n 703\n\n 13d\n\n Season 9 Final Report\n\n Grants Updates\n\n Highlights\nThe Grants Council closed Season 9 submissions on May 20th. \nSubmission flow increased significantly in the final two cycles, bringing the Season 9 total to 38 applications. \nAcross the season, GrantNerds revi…\n\n read more\n\n 9\n\n 464\n\n 13d\n\n Season 8 Growth Grants - TVL Impact Review\n\n ✨ General\n\n season-8\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me. \nI did …\n\n read more\n\n 2\n\n 165\n\n 13d\n\n Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0\n\n Protocol Upgrade\n\n Proposal Type: Protocol Upgrade\nHi, I’m Andrea Federici, Senior Solutions Engineer at OP Labs. I prepared this proposal in collaboration with Adrian Sutton, Matt Solomon and Matthew Cruz from the OP Labs team. Neither OP…\n\n read more\n\n 2\n\n 281\n\n 20d\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n Governance Fund Missions\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions be…\n\n read more\n\n 4\n\n 127\n\n 27d\n\n An Optimism Governance / Ecosystem Grant Proposal\n\n Proposals 📃\n\n Project Name: STRATEGIC POWER 360 \n\nProtocol Component: Public Light 3.0 (Algorithmic Governance & Auditing Layer) \nAuthor / Project Lead: Juan Carlos Farías Salazar \nLegal Jurisdiction: Wyoming, USA (DAO / DUNA Archit…\n\n read more\n\n 0\n\n 52\n\n 30d\n\n Optimism Governance / Ecosystem Grant Proposal\n\n Get Started 🌱\n\n Project Name: STRATEGIC POWER 360 \nProtocol Component: Public Light 3.0 (Algorithmic Governance & Auditing Layer) \nAuthor / Project Lead: Juan Carlos Farías Salazar \nLegal Jurisdiction: Wyoming, USA (DAO / DUNA Architect…\n\n read more\n\n 0\n\n 49\n\n Sep 4\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n ✨ General\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 106\n\n Sep 4\n\n Security Council Communication Thread\n\n Council Communication Threads\n\n Welcome to the Security Council Communication Thread!\nThe goal of the Security Council is to turn admin keys for OP Mainnet, and eventually, all OP Chains in the Superchain, over to a public, decentralized set of individ…\n\n read more\n\n 18\n\n 1.4k\n\n Sep 3\n\n PGov - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate Name: @PGov \nDelegate Address: PGov.eth (0x3fb19771947072629c8eee7995a2ef23b72d4c8a) \nForum Handle: @PGov, @Juanbug_PGov \nEmail: PGovTeam@gmail.com \nCore Principles: \n\nTransparency: Clear communication with vote…\n\n read more\n\n 45\n\n 3.6k\n\n Sep 2\n\n Maintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard Optimism Governance\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nExecutive Summary\nThis proposal transitions the ProxyAdmin Owner of Unichain Mainnet (chai…\n\n read more\n\n 0\n\n 56\n\n Sep 2\n\n Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nSummary\nThis proposal requests the Optimism Security Council return administrative ownersh…\n\n read more\n\n 0\n\n 54\n\n Sep 2\n\n [Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s)\n\n Governance Fund Missions\n\n Hello Optimism Collective, \nWe have developed Ag^τ, a proprietary, zero-FPU semantic compression engine designed to reduce L1 calldata costs and lower hardware overhead for EVM rollups. \nAs Optimism scales, L1 data avail…\n\n read more\n\n 2\n\n 84\n\n Aug 25\n\n Accelerated Decentralization Proposal For Optimism\n\n ✨ General\n\n Authors: @GFXlabs \nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary) \nIf you hold OP, please signal your approval of this accelerated decentralization on this Snap…\n\n read more\n\n 36\n\n 3.6k\n\n Aug 25\n\n Buyback Communication Thread\n\n Communications 📣\n\n season-9\n\n This communication thread will be used to provide transparency into buyback execution via OTC. We will update this post with links to any relevant dashboards and will post execution details monthly. As the program author…\n\n read more\n\n 6\n\n 866\n\n Aug 25\n\n Maintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nSummary\nThis proposal updates the recipient configured on Soneium’s four L2 fee vault predeploys (SequencerFeeVault, BaseFeeVault, L1FeeVault, OperatorFeeVault) from the current treasu…\n\n read more\n\n 1\n\n 117\n\n Aug 23\n\n Brichis - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate statement \nFirstly, allow me to introduce myself. My name is Bricia, although you’re welcome to call me Brichis and I am Co-Founder of Ethereum Mexico. \nMy decision to become a delegate was sparked by discussio…\n\n read more\n\n 48\n\n 3.9k\n\n Aug 21\n\n FranklinDAO (Penn Blockchain) - Delegate Communication Thread\n\n Delegate Updates\n\n Address or ENS: FranklinDAO.eth \nDiscord username: Juanbug#9225 \nHello everyone! We’re FranklinDAO/Penn Blockchain (@PennBlockchain on twitter), a leading, completely student run blockchain organization from The Universi…\n\n read more\n\n 5\n\n 2.2k\n\n Aug 21\n\n Collective Year 4 Budget Update and Year 5 Budget Outlook\n\n Foundation Budgets\n\n Summary\nYear 4 (May 2025 to April 2026) was a year of focus and fiscal discipline. The Collective committed roughly 150M OP of new commitments across Season 8 and Season 9, about one third less than the 229.92M OP commit…\n\n read more\n\n 2\n\n 441\n\n Aug 7\n\n Sandcastles and Social Mercenaries: Why EVM DAOs Are Being Looted\n\n ✨ General\n\n Optimists, \nHumanity learned thousands of years ago that an open city with vast treasure is an invitation to plunder. Walls were built to stop looters. Rules were written to prevent brute power from ruling. Police were c…\n\n read more\n\n 2\n\n 88\n\n Aug 7\n\n [RFC] Operational Mandate: S9 Impact Autopsy & S10 Capital Efficiency Oracle\n\n Governance Design and Strategy 📐\n\n Author: @JulianCross (Independent Data Architect) \nSponsor: [Call for Delegate Sponsor] \n1. Abstract & Problem Statement \nThe Token House distributed millions in OP during Season 9, yet lacks a centralized, automated art…\n\n read more\n\n 6\n\n 157\n\n Aug 4\n\n Maintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer Rotation\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nVoting Cycle Type: Off-cycle. Per the OPerating Manual, Maintenance Upgrade Proposals proceed directly to on-chain voting under optimistic approval, with a one-week veto period and a 2…\n\n read more\n\n 0\n\n 97\n\n Jul 22","tokens":2609,"squid":"ink-governance","role":"Council Listener","at":1791257368292,"hash":"8d861760d9ee1cb1e24494d4b036bdfff00c83bc"}
{"url":"https://docs.pyth.network/","domain":"docs.pyth.network","title":"Pyth Developer Hub","text":"Developer HubIntegrate with the global price layer.Pyth Core was upgraded on August 26, 2026Hermes now requires an API Key — register if you haven't yetLearn moreProductsConnect to the global market data and randomness layer.Pyth ProSubscription-based price data for institutions and advanced use cases. Previously known as Lazer.FEATURESUltra-low latencyCrypto, Equities & IndexesCustomizable channels and latencyDedicated supportQUICK LINKSGet Pyth Pro API KeyBrowse Supported FeedsPricingEntropySecure, Verifiable Random Number Generator for EVM-based smart contracts.FEATURESOn-chain randomnessVerifiable resultsPay in native tokenSupports 20+ EVM chainsQUICK LINKSChainlistProtocol DesignEntropy ExplorerResources for DevelopersExplore the Pyth Network for developersGet Your API KeyRequest access for the Pyth Ultra Low Latency price feeds.LinkSupported Feeds -- Pyth ProExplore the complete list of supported price feeds for Pyth Pro.LinkAPI Reference -- Pyth ProExplore the complete API reference for Pyth Pro.Link","tokens":256,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257368918,"hash":"6b1a106fc0a6d3e4d164025ea6bf7d4dead50b24"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/sequencer/run-sequencer-node","domain":"docs.arbitrum.io","title":"How to run a normal sequencer node for an Arbitrum chain | Arbitrum Docs","text":"✏️Request an updatecautionThe following instructions are meant for Arbitrum chains only. This article only applies to test environments. If you need support spinning up a production Arbitrum chain, we recommend contacting a provider.We also provide a guide for running a high-availability sequencer node for an Arbitrum chain.\nThis how-to provides step-by-step instructions for running a sequencer node on your local machine.\nFor background on how sequencers fit into Arbitrum's data flow (batch posting, the sequencer feed, and how full nodes consume sequencer output), see Data availability. For how the sequencer role relates to the other Nitro node roles and the flags that define them, see How to assign roles to a Nitro node.\nMinimum hardware configuration​\nThe following are the minimum hardware configurations required to set up a Nitro full node (not archival):\n\nResourceMinimum requirementsRecommendedRAM (DDR5)64 GB128 GB or moreCPU8 core 3rd generation CPUs (for AWS, a i4i.2xlarge instance)16 core CPU or higher and more recent/newer generation of CPUsStorage typeNVMe SSD drives with locally attached drives strongly recommendedSameStorage sizeDepends on the chain and its traffic over time, but ideally several terabytes (TB)Same, but higher if possible\nPlease note that:\n\nThese minimum requirements for RAM and CPU are recommended for nodes that process a small amount of RPC requests. For nodes that require processing multiple simultaneous requests, both RAM and the number of CPU cores will need to scale with the amount of traffic served.\nSingle core performance is important. If the node is falling behind and a single core is 100% busy, it is recommended to update to a faster processor\nThe minimum storage requirements will change over time as the chain grows. Using more than the minimum requirements to run a robust full node is recommended.\n\nRecommended Nitro version​\ncautionEven though there are alpha and beta versions of the Arbitrum Nitro software, only use release versions when running your node. Running alpha or beta versions is unsupported and might lead to unexpected behaviors.\nLatest Docker image: offchainlabs/nitro-node:v3.12.1-70fa99a\nRequired parameters​\n1. Sequencer node parameters​\nThe following parameters are required to run a sequencer node:\n1. Enable sequencer​\nEnable the sequencer mode:\n--node.sequencer=true\n2. Make the node act as a sequencer and post to L1​\nEnable the sequencer execution:\n--execution.sequencer.enable=true--execution.sequencer.max-tx-data-size=85000\n3. Enable delayed sequencer​\nEnable your node to read and include transactions from the parent chain delayed inbox.\n--node.delayed-sequencer.enable=true--node.delayed-sequencer.use-merge-finality=false--node.delayed-sequencer.finalize-distance=1\n4. Enable batch poster​\nEnable your node to send batches to the parent chain:\n--node.batch-poster.enable=true--node.batch-poster.max-calldata-batch-size=90000--node.batch-poster.parent-chain-wallet.private-key=<Your Parent Chain Wallet Private Key>\n--node.batch-poster.max-calldata-batch-size replaces the deprecated --node.batch-poster.max-size, which previously also capped AnyTrust batches. On AnyTrust chains, set the AnyTrust batch limit separately with --node.da.anytrust.max-batch-size (see the next section).\n4. Disable transaction forwarding​\nDisable your sequencer's forwarding transactions, as the node will queue the transaction directly:\n--execution.forwarding-target=\"\"\n5. Enable feed-out queued transactions​\nEnable your node to feed out transactions so full node can receive queued transactions. For the wire format consumers will see on this port, see How to read the sequencer feed.\n--node.feed.output.enable=true--node.feed.output.addr=0.0.0.0--node.feed.output.port=<Sequencer feed port>\n5. Connect the node to data availability servers​\nnoteThis step is only required in Anytrust mode. For an explanation of AnyTrust mode and the role of the Data Availability Committee (DAC), see AnyTrust Mode.As of Nitro v3.10.0, these settings live under --node.da.anytrust.* (the previous --node.data-availability.* namespace is deprecated), and the node no longer takes sequencer-inbox-address or parent-chain-node-url in this section — it uses the chain info and the --parent-chain.connection.url configuration instead.\nEnable your node to send batches to a DAS and get DACerts from them.\n--node.da.anytrust.enable=true--node.da.anytrust.max-batch-size=90000--node.da.anytrust.rest-aggregator.enable=true--node.da.anytrust.rest-aggregator.urls=<A list of DAS REST endpoints, can be only one URL>--node.da.anytrust.rpc-aggregator.enable=true--node.da.anytrust.rpc-aggregator.assumed-honest=1--node.da.anytrust.rpc-aggregator.backends=<A list of RPC backends>\n2. Putting it all together​\n\nWhen running a Docker image, an external volume should be mounted to persist the database across restarts. The mount point inside the Docker image should be /home/user/.arbitrum\n\nExample:\ndocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --node.sequencer=true --node.delayed-sequencer.enable=true --node.delayed-sequencer.use-merge-finality=false --node.delayed-sequencer.finalize-distance=1 --node.batch-poster.enable=true --node.batch-poster.max-calldata-batch-size=90000 --node.batch-poster.parent-chain-wallet.private-key=<Your Parent Chain Wallet Private Key> --node.staker.enable=true --node.staker.strategy=MakeNodes --node.staker.parent-chain-wallet.private-key=<Your Parent Chain Wallet Private Key> --node.da.anytrust.enable=true --node.da.anytrust.max-batch-size=90000 --node.da.anytrust.rest-aggregator.enable=true --node.da.anytrust.rest-aggregator.urls=<A list of DAS REST endpoints, can be only one URL> --node.da.anytrust.rpc-aggregator.enable=true --node.da.anytrust.rpc-aggregator.assumed-honest=1 --node.da.anytrust.rpc-aggregator.backends=<A list of RPC backends> --execution.sequencer.enable=true --execution.sequencer.max-tx-data-size=85000\n\nEnsure that /some/local/dir/arbitrum already exists; otherwise, the directory might be created with root as owner, and the Docker container won't be able to write to it.\n\nJson Example:\n{ \"node\": { \"sequencer\": true, \"delayed-sequencer\": { \"enable\": true, \"use-merge-finality\": false, \"finalize-distance\": 1 }, \"batch-poster\": { \"max-calldata-batch-size\": 90000, \"enable\": true, \"parent-chain-wallet\": { \"private-key\": \"<batch post key>\" } }, \"feed\": { \"output\": { \"enable\": true, \"addr\": \"0.0.0.0\", \"port\": \"<Sequencer feed port>\" } }, \"da\": { \"anytrust\": { \"enable\": true, \"max-batch-size\": 90000, \"rest-aggregator\": { \"enable\": true, \"urls\": [\"http://das-server:9877\"] }, \"rpc-aggregator\": { \"enable\": true, \"assumed-honest\": 1, \"backends\": \"[{\\\"url\\\":\\\"http://das-server:9876\\\",\\\"pubkey\\\":\\\"YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==\\\"}]\" } } } }, \"execution\": { \"forwarding-target\": \"\", \"sequencer\": { \"enable\": true, \"max-tx-data-size\": 85000 } }}\n\nNote on permissions​\n\nThe Docker image is configured to run as non-root UID 1000. If you are running Linux or macOS and you are getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders:\n\nmkdir /data/arbitrumchmod -fR 777 /data/arbitrum\nOptional parameters​\nHere's a list of the parameters that are most commonly used when running your Arbitrum chain sequencer node. You can also use the flag --help for a comprehensive list of available parameters.\n\nFlagDescription--execution.rpc.classic-redirect=<RPC>Redirects archive requests for pre-nitro blocks to this RPC of an Arbitrum Classic node with an archive database, only for Arbitrum One.--execution.rpc.classic-redirect=<RPC>Redirects archive requests for pre-nitro blocks to this RPC from an Arbitrum Classic node with an archive database, only for Arbitrum One.--http.apiWhich APIs need to be opened over the HTTP-RPC interface. Default: net,web3,eth,arb. Add debug for tracing.--http.corsdomainAccepts cross origin requests from these comma-separated domains (browser enforced).--http.vhostsAccepts requests from these comma-separated virtual hostnames (server enforced). Default: localhost. Accepts *.--http.addrAddress to bind RPC to. May require 0.0.0.0 for Docker networking.--execution.caching.archiveWill retain past block state. For archive nodes.--node.feed.input.url=<feed address>Default: wss://<chainName>.arbitrum.io/feed. ⚠️ One feed relay per datacenter is advised. See feed relay guide.--execution.rpc.evm-timeoutDefault: 5s. Timeout for eth_call. (0 == no timeout).--execution.rpc.gas-capDefault: 50000000. Gas cap for eth_call/estimateGas. (0 = no cap).--execution.rpc.tx-fee-capDefault: 1. Transaction fee cap (in ETH) for RPC APIs. (0 = no cap).--ipc.pathFilename for IPC socket/pipe within datadir. Not supported on macOS. Note: The path is within the Docker container.--init.prunePrunes database before starting the node. It can be used for full or validator nodes.--init.url=\"<snapshot file>\"Non-Arbitrum chain Nitro nodes only: URL from which to download the genesis database. Required only for the first startup of an Arbitrum One node. Reference to snapshots and archive node guide.--init.download-path=\"/path/to/dir\"Non-Arbitrum chain Nitro nodes only: Temporarily saves the downloaded database snapshot. Defaults to /tmp/. Used with --init.url.--node.batch-poster.post-4844-blobsBoolean. Default: false. Used to enable or disable the posting of transaction data using Blobs to Ethereum mainnet. If using calldata is more expensive and the parent chain supports EIP4844 blobs, the batch poster will use blobs when this flag is set to true. It can be set to true or false.--node.batch-poster.ignore-blob-priceBoolean. Default: false. If the parent chain supports EIP4844 blobs and ignore-blob-price is set to true, the batch poster will use EIP4844 blobs even if using calldata is cheaper. It can be set to true or false.--execution.sequencer.enableAct as sequencer and post to L1.--execution.sequencer.enable-profilingEnable CPU profiling and tracing.--execution.sequencer.expected-surplus-hard-thresholdIf the expected surplus is lower than this value, new incoming transactions will be denied (default \"default\").--execution.sequencer.expected-surplus-soft-thresholdWarnings are posted if the expected surplus is lower than this value (default \"default\").--execution.sequencer.forwarder.connection-timeoutTotal time to wait before canceling connection (default 30s).--execution.sequencer.forwarder.idle-connection-timeoutTime until idle connections are closed (default 1m0s).--execution.sequencer.forwarder.max-idle-connectionsMaximum number of idle connections to keep open (default 100).--execution.sequencer.forwarder.redis-urlThe recommended Redis URL to use as target.--execution.sequencer.forwarder.retry-intervalMinimal time between update retries (default 100ms).--execution.sequencer.forwarder.update-intervalForwarding target update interval (default 1s).--execution.sequencer.max-acceptable-timestamp-deltaMaximum acceptable time difference between the local time and the latest L1 block's timestamp (default 1h0m0s).--execution.sequencer.max-block-speedMinimum delay between blocks (sets a maximum speed of block production) (default 250ms).--execution.sequencer.max-revert-gas-rejectMaximum gas executed in a revert for the sequencer to reject the transaction instead of posting it (anti-DOS).--execution.sequencer.max-tx-data-sizeMaximum transaction size the sequencer will accept (default 95000).--execution.sequencer.nonce-cache-sizeSize of the transaction sender nonce cache (default 1024).--execution.sequencer.nonce-failure-cache-expiryMaximum time to wait for a predecessor before rejecting a transaction whose nonce is too high (default 1s).--execution.sequencer.nonce-failure-cache-sizeNumber of transactions whose nonce is too high to keep in memory while waiting for their predecessor (default 1024).--execution.sequencer.queue-sizeSize of the pending transaction queue (default 1024).--execution.sequencer.queue-timeoutMaximum time a transaction can wait in a queue (default 12s).--execution.sequencer.sender-whitelistComma-separated allowlist of authorized senders (if empty, every sender is allowed).--node.delayed-sequencer.finalize-distanceNumber of blocks in the past L1 block for the transaction to be considered final. This value is ignored when using merge finality. Default: 20.--node.delayed-sequencer.require-full-finalityWhether to wait for full finality before sequencing delayed messages.--node.delayed-sequencer.use-merge-finalityWhether to use The Merge's notion of finality before sequencing delayed messages (default to true).Minimum hardware configurationRecommended Nitro versionRequired parameters1. Sequencer node parameters2. Putting it all togetherNote on permissionsOptional parameters","tokens":3307,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257370080,"hash":"32617083975421457237398f558f1fbffe7ec9e4"}
{"url":"https://gov.optimism.io/c/get-started/67","domain":"gov.optimism.io","title":"Latest Get Started 🌱 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Get Started 🌱\n\n Get Started 🌱\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n How to Stay up to Date\n\n Governance Calendar\n\n 43\n\n 4.3k\n\n Jan 21\n\n How to Navigate the Forum\n\n How to Get a Grant\n\nHow to Navigate the Forum\n\nUpdates and Announcements: Find information about community calls, weekly governance summaries, and periodic updates from the Foundation and other partners \n\nGrants: Key i…\n\n read more\n\n 9\n\n 2.3k\n\n Apr 2025\n\n About the Optimism Collective\n\n Welcome to the Optimism Collective governance forum! \nThe forum is where governance participants discuss critical topics relating to the Collective. \nWhat is the Optimism Collective?\nThe Optimism Collective is a new mode…\n\n read more\n\n 8\n\n 3.4k\n\n Jun 2025\n\n Working Constitution of the Optimism Collective\n\n The Optimism Collective is a large-scale experiment in decentralized governance. Our Vision is to sustainably fund those public goods that improve upon the well-being of the Collective and beyond. This Working Constituti…\n\n read more\n\n 628\n\n 61.4k\n\n 28d\n\n Optimism Governance / Ecosystem Grant Proposal\n\n Project Name: STRATEGIC POWER 360 \nProtocol Component: Public Light 3.0 (Algorithmic Governance & Auditing Layer) \nAuthor / Project Lead: Juan Carlos Farías Salazar \nLegal Jurisdiction: Wyoming, USA (DAO / DUNA Architect…\n\n read more\n\n 0\n\n 49\n\n Sep 4\n\n Hello Optimism — Independent Governance Researcher from India\n\n Hello Optimism community. \nI’m MconnectDAO Manoj Kumar Desai a freelance governance researcher based in India. \nI’ve been active on Arbitrum and Aave governance forums over the past week, focused on process accountabili…\n\n read more\n\n 3\n\n 84\n\n Mar 27\n\n Hello Optimism — excited to contribute!\n\n Hi everyone, I’m Manoj. \nI focus on governance research, proposal summaries, and clarity-based analysis. \nMy strengths are deep reading, structured thinking, and simplifying complex proposals. \nExcited to learn from the …\n\n read more\n\n 0\n\n 51\n\n Feb 28\n\n Ultimate Beginner Guide: How to Start in the Optimism & Superchain Ecosystem (Step-by-Step with Examples)\n\n Hello Optimism Community! \nI prepared a complete onboarding guide for all newcomers who want to learn how to start building, exploring and contributing within Optimism and the broader Superchain. \nThis guide is based …\n\n read more\n\n 5\n\n 383\n\n Dec 2025\n\n Welcome to the Optimism Collective Discourse!\n\n The Optimism Collective is a large-scale experiment in decentralized governance. Our vision is to sustainably fund public goods that improve upon the well-being of the Collective and beyond. The form and function of this…\n\n read more\n\n 104\n\n 12.6k\n\n Aug 2025\n\n Superchain season 8 strategy for eligible\n\n season-8\n\n I think Superchain season 8 is intended for everyone I think superchain season 8 is for all layer 2s who collaborate with superchain\n\n 0\n\n 77\n\n Aug 2025\n\n Will my delegation disappear if I put it in a steak?\n\n Hello friends! Can you tell me where to put OP’s tokens in the steak? And will my delegation disappear if I put it in a steak?\n\n 7\n\n 319\n\n Jul 2025\n\n Hi. Im not sure what those XP are for?\n\n What are the Suprestack XP points for? And should i stake in all the tasks? \n\n 5\n\n 248\n\n May 2025\n\n Hold Nouns on Ethereum Mainnet\n\n Nouns (NOUN) is an NFT collection. Nouns (NOUN) price floor today is $12,868.61, with a 24 hour sales volume of 0 ETH. As of today, there is a total of 1,403 NFTs minted, held by 403 unique owners, and has a total market…\n\n read more\n\n 0\n\n 205\n\n Feb 2025\n\n Interested in Becoming a Delegate? Review this Guide!\n\n Are you interested in becoming a Delegate? \nIf so, this Prospective Delegate Governance Onboarding Hub has all the info you need to get set up as a successful Delegate. \nIf you have any questions, feel free to comment th…\n\n read more\n\n 3\n\n 338\n\n Jan 2025\n\n Governance Season Guides\n\n Guide to Season 3\nGuide to Season 4\nGuide to Season 5\nGuide to Season 6\nGuide to Season 7\n\n 0\n\n 1.5k\n\n Jan 2025\n\n Optimism Governance Glossary\n\n Anticapture Commission\nThe Anticapture Commission exists to prevent capture of the Token House by any one stakeholder or group of stakeholders. Composed of high-impact individual delegates, it alerts the Citizens’ House …\n\n read more\n\n 2\n\n 441\n\n Dec 2024\n\n Optimist Expectations\n\n Optimist Expectations\nOptimists (all delegates, Citizens, and grant recipients) are expected to abide by the below expectations. \nIf a delegate does not abide by these expectations, their delegators should re-delegate to…\n\n read more\n\n 2\n\n 1.6k\n\n May 2024","tokens":1161,"squid":"ink-governance","role":"Council Listener","at":1791257393230,"hash":"4b16f8ec489967a1f864ee873156dcd5c60b0b12"}
{"url":"https://docs.pyth.network/price-feeds/pro/price-feed-ids","domain":"docs.pyth.network","title":"Price Feed IDs | Pyth Developer Hub","text":"Pyth ProPrice Feed IDsList of price feed IDs for all the assets supported by Pyth ProYou can also access the list of symbols programmatically via the Symbology\nand Reference Data API. See Symbology\n& Reference Data for what each metadata\nfield means.\nChannels legendThe Channels column shows the fastest tier a feed supports. Every slower channel is also delivered, so highlighted segments cascade to the right.Minimum channel: Real Time. Published on Real Time, fixed_rate@50ms, fixed_rate@200ms, and fixed_rate@1000ms.Minimum channel: fixed_rate@50ms. Published on fixed_rate@50ms, fixed_rate@200ms, and fixed_rate@1000ms.Minimum channel: fixed_rate@200ms. Published on fixed_rate@200ms and fixed_rate@1000ms.Minimum channel: fixed_rate@1000ms. Published on fixed_rate@1000ms only.\nAsset TypeDescriptionNameSymbolPyth Pro IDExponentStatusChannelscryptoBITCOIN / US DOLLARBTCUSDCrypto.BTC/USD1-8StablecryptoETHEREUM / US DOLLARETHUSDCrypto.ETH/USD2-8StablecryptoPYTH NETWORK / US DOLLARPYTHUSDCrypto.PYTH/USD3-8StablecryptoPEPE / US DOLLARPEPEUSDCrypto.PEPE/USD4-10StablecryptoNEIRO / US DOLLARNEIROUSDCrypto.NEIRO/USD5-10StablecryptoSOLANA / US DOLLARSOLUSDCrypto.SOL/USD6-8StablecryptoUSD COIN / US DOLLARUSDCUSDCrypto.USDC/USD7-8StablecryptoTETHER / US DOLLARUSDTUSDCrypto.USDT/USD8-8StablecryptoBONK / US DOLLARBONKUSDCrypto.BONK/USD9-10StablecryptoDOG WIF HAT / US DOLLARWIFUSDCrypto.WIF/USD10-8StableRows per page Page 1 of 382Frequently Asked QuestionsCommon questions about integrating and using Pyth ProContract AddressesList of Pyth Pro (Lazer) contract addresses on supported networks","tokens":399,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257393309,"hash":"86e2292b8f4a11e940f8d7d90e142e02d99516ce"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/nitro-support-policy","domain":"docs.arbitrum.io","title":"Nitro support policy | Arbitrum Docs","text":"✏️Request an updateNitro support​\nThis policy defines which versions of Nitro the Offchain Labs team actively supports—and what \"support\" actually means. It exists so node operators, chain operators, and integrators know what to run, when to upgrade, and what kind of help to expect when they don't upgrade.\nCurrently supported Nitro versions​\nCurrently supportedSupported untilSupported deploymentNitro 3.12.x30 calendar days after 3.12.x is released.DockerNitro 3.11.5October 28, 2026Docker\nSpecial note about ArbOS and Arbitrum Classic​\n\nOnly the ArbOS release that is activated on mainnet Arbitrum One will receive security updates and urgent vulnerability patches. We strongly recommend that you stay up to date with the latest ArbOS, as only the latest version receives security updates. The activation timestamps for ArbOS upgrades on Arbitrum One are available on the Arbitrum Foundation network upgrades page, with the most recent entry corresponding to the ArbOS version currently in use on Arbitrum One.\n\nAlternatively, you can verify the ArbOS version on Arbitrum One using the arbOSVersion() method on the ArbSys precompile at 0x000....64. The result will be offset by 55 as the first version of Nitro is known as version 56 (for example, a response of 106 indicates that the ArbOS version is 51).\n\nArbitrum Classic will also continue to be supported.\n\nOur support windows, explained​\nWe will always support the current minor release of Nitro. The previous minor release will be supported for 30 calendar days after a newer minor release becomes available. In other words, support for a Nitro minor release stops once a minor release of the Nitro node software is made available for 30 calendar days.\nThis means that we will effectively support at most two minor releases for a maximum of 30 calendar days.\ncautionIn exceptional cases, such as for stability or security fixes, we may cut a new minor Nitro release within 30 days of a previous minor release and immediately drop support for that release. When this happens, we may ask teams to upgrade sooner to the new release for security and stability reasons.\nBelow is an illustrative example of how these windows overlap over the course of a year, along with several placeholder versions. Note that this is an example.\nNitro support windows\nThe currently supported versions can be found on the Nitro start here page.\nWhat \"supported\" means​\nIf you are running a supported Nitro version, we will work to:\n\nRespond to bug reports (Slack, Telegram, etc.) and ship fixes and security patches against it\nWork with you to help debug operational issues you uncover\nTreat the release as a valid baseline for compatibility testing\n\nIf you are running an unsupported Nitro version:\n\nWe may decline to investigate issues and will recommend upgrading first before investigating\nWe will not back-port non-critical fixes or features\nYou assume responsibility for any operational, consensus, or security risk\n\nYou are free to run any version of our software. This policy describes where we will spend our time, not what we will permit.\nCarve-out: ArbOS upgrades on older Nitro versions​\nIf we determine an ArbOS upgrade is required—including for security—we do not commit to porting those ArbOS changes back to any version. Operators on unsupported Nitro must first upgrade Nitro to receive the ArbOS change. This is intentional: backporting state-transition logic into stale node code is high-risk, and a guarantee here would dilute the upgrade pressure that keeps the network on supportable client versions.\nSecurity fixes​\nSecurity fixes are handled inside the supported window:\n\nPrivate disclosure to chain operators when actionable\nCoordinated release across all in-window versions (current minor + still-in-window prior minor)\nPublic disclosure after operators have had time to upgrade\n\nA client version exception does not retroactively extend support for older versions. If you are out of support when a fix lands, the path forward is to upgrade.\nOut of scope​\nThis policy covers the upstream release of Nitro by Offchain.\nIt does not cover:\n\nForks or custom builds maintained by third parties\nBuilds compiled from non-release commits\nConfigurations or patches not present in the upstream release\n\nWe will help where we can, but we cannot commit to a support level on builds other than official releases.\nStaying up to date​\n\nSubscribe to the Nitro GitHub repository for GitHub notifications on new releases.\nFollow our X handle for all things geared towards developers building with and on Arbitrum.\nThe Arbitrum Discord server for all announcements and discussions\nTelegram channels:\n\n@arbitrumnodeupgrade for important updates about Arbitrum node software upgrade notices and announcements\n@arbitrum for general announcements about things happening in the Arbitrum ecosystem\n@OffchainLabsannouncements for Offchain-specific announcements or notices!\n\nNitro supportCurrently supported Nitro versionsSpecial note about ArbOS and Arbitrum ClassicOur support windows, explainedWhat \"supported\" meansCarve-out: ArbOS upgrades on older Nitro versionsSecurity fixesOut of scopeStaying up to date","tokens":1288,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257393367,"hash":"5cd076d7f72c6894f703501e0d4ec7853e8045bb"}
{"url":"https://docs.pyth.network/price-feeds/pro/faq","domain":"docs.pyth.network","title":"Frequently Asked Questions | Pyth Developer Hub","text":"Pyth ProFrequently Asked QuestionsCommon questions about integrating and using Pyth ProThis page answers frequently asked questions about Pyth Pro (formerly known as Lazer).\nIf you have questions that are not answered here, feel free to add a question to our developer forum.\nConnection & Subscription\nQ. Is the feed ordering preserved when subscribing to multiple price feeds?\nYes. The payload preserves the ordering of the feed IDs in your subscription request. If you subscribe with feed IDs in the order [3, 2, 1], the update data will maintain that order. Feed ordering is maintained even when data is omitted by a market session filter. You can verify this in the Pyth Pro Playground.\nQ. How many price feed IDs can I subscribe to per stream?\nThere is no hard cap, but for optimal performance we recommend splitting large subscriptions across multiple connections. The number of connections is limited by your specific usage agreement. If you need to subscribe to many feeds, contact support for guidance on high-volume subscriptions. For more on rate limits, see Rate Limits.\nQ. How should I handle feed expiration or invalid feed IDs in production?\nFeed IDs can become invalid over time — for example, when a feed is retired or an equity is delisted. By default, a subscription request containing any invalid feed ID will fail entirely with a subscriptionError, dropping all of your valid feeds along with it.\nFor production deployments, set ignoreInvalidFeeds: true in your subscribe message:\nclient.subscribe({\n type: \"subscribe\",\n subscriptionId: 1,\n priceFeedIds: [1, 2],\n properties: [\"price\", \"feedUpdateTimestamp\"],\n formats: [\"solana\"],\n channel: \"fixed_rate@200ms\",\n ignoreInvalidFeeds: true,\n});\nWith this flag enabled, invalid feeds are skipped and listed in the subscription response, while the rest of your feeds continue to stream without interruption. Inspect the response to learn which feeds were dropped and why, then update your subscription accordingly. See Subscribe to Prices and Error Codes for details.\nQ. What is the \"client too slow\" error?\nThis error occurs when the client cannot process incoming messages fast enough. Common causes:\n\nProcessing delays in your message handler\nNetwork latency issues\n\nTo resolve:\n\nOptimize your message processing code to handle the incoming messages faster\nEnsure adequate network bandwidth\n\nQ. Which WebSocket endpoints should I connect to for redundancy?\nRedundancy requiredIt is critical to connect to multiple endpoints in parallel to maintain a\nreliable connection and avoid downtimes. Individual endpoints can briefly go\noffline due to upgrades and network disruptions. The official\nSDK handles\nconnecting redundantly to all available endpoints and deduplicating messages\nfor you.\nConnect to all three endpoints:\n\nwss://pyth-lazer-0.dourolabs.app/v1/stream\nwss://pyth-lazer-1.dourolabs.app/v1/stream\nwss://pyth-lazer-2.dourolabs.app/v1/stream\n\nSee Subscribe to Prices for full setup details.\nData Format & Payloads\nQ. How do equities work outside of market hours (24/5)?\nPyth Pro can be configured to behave as needed for your use case via market session filtering. You can control which market sessions you receive data for so that out-of-hours behavior matches your application—see the sessions property under Property Specifications in the Payload Reference. Starting March 23, 2026, when markets are closed and a fresh aggregate cannot be produced, Pyth Pro will carry forward the most recent available price rather than omitting it. To determine whether a price is current or carried forward, compare the feedUpdateTimestamp field against the update's timestampUs—if they differ, the price was generated at an earlier time. See Payload Reference — Price Availability Semantics for details. See Market Hours for detailed schedules.\nQ. Is it mandatory to call verifyUpdate to get the payload when using Pyth Pro on-chain?\nNo. You can trim the payload off-chain and extract the data (from byte 71 onwards) without calling verifyUpdate. See the verify function in the contract or the Rust SDK protocol module.\nWe strongly discourage using the data on-chain without signature verification, as it poses security risks. If you are using the data on-chain without signature verification, you are responsible for verifying the data yourself.\nMarket Hours & Schedules\nQ. How does Pyth Pro handle daylight saving time?\nSchedules handle daylight saving transitions automatically. The schedule string uses IANA timezone names, which include daylight saving information. The time values (e.g., 1700) are local to the timezone. When the timezone enters or leaves daylight saving time, the local time does not change—only the offset from UTC. This is handled automatically by timezone-aware client libraries such as the Python client market schedule module.\nQ. What are the market hours for Gold (XAU) and Silver (XAG)?\nPyth follows CME futures market hours for precious metals, since the spot price is derived from futures. According to CME Globex:\n\nTrading hours: Sunday 6:00 p.m. ET through Friday 5:00 p.m. ET\nDaily break: 60-minute break each day at 5:00 p.m. ET (17:00-18:00)\n\nFor full schedules by asset class, see Market Hours.\nMoreover, one can fetch market hours from the Symbols API of the History Service.\nOn-Chain Integration\nQ. Where can I find Pyth Pro (Lazer) contract deployments?\nContract addresses for Pyth Pro on **Solana, Fogo, and EVM networks (including Base, Ethereal, Polynomial, Soneium, and testnets) **are listed on the Contract Addresses page. Check that page for the current deployment address for your chain.\nHistorical Data\nQ. How do I access historical price data for Pyth Pro?\nUse the History API for OHLC candlestick data and TradingView-style integration. Base URL:\nhttps://pyth.dourolabs.app/v1/\nFor OHLC history, use GET /{channel}/history. Example for BTC/USD in the last year with the fixed_rate@200ms channel:\nhttps://pyth.dourolabs.app/v1/fixed_rate@200ms/history?symbol=Crypto.BTC/USD&from=<start_timestamp>&to=<end_timestamp>&resolution=1D\nSee the History API for full endpoint details, query parameters, and resolutions.\nGET /{channel}/history and GET /{channel}/price require the Authorization: Bearer <PRO_API_KEY> header. See the History API for the header format and frontend-safe guidance.\nQ. How do I fetch the latest price via HTTP?\nUse the REST API. Base URL:\nhttps://pyth-lazer.dourolabs.app\n\nLatest price: POST /v1/latest_price — returns the most recent price data for the requested feeds.\nPrice at a timestamp: POST /v1/price — returns price data at a specific historical timestamp (request body includes a timestamp field).\n\nSee the REST API for request/response schemas and examples.\nPOST /v1/price requires the Authorization: Bearer <PRO_API_KEY> header. See the REST API for details.\nQ. How should I authenticate the History and REST endpoints from a frontend app?\nDo not embed your Pro access token in browsers or frontend apps. Route requests through your own backend that injects the Authorization: Bearer <PRO_API_KEY> header before forwarding. Or have your backend hand out short-lived JWTs the browser can use directly — see Frontend Authentication.\nQ. What happened to the Proxy API?\nThe beta Proxy service (pyth-lazer-proxy-{1,2,3}) gave unauthenticated frontend access and is no longer available. For browser and frontend apps, mint a short-lived JWT and use it over the WebSocket, REST, and History APIs instead — see Frontend Authentication. The raw API key stays server-side.\nAccess Tokens & Permissions\nQ. How are access tokens permissioned for different asset classes?\nEach access token is permissioned for a specific set of:\n\nAsset types (e.g., crypto, equity, fx, metals, rates)\nMinimum channel (e.g., fixed_rate@200ms, real_time)\nOptional specific feed IDs\n\nOne customer might have access to all asset types; another might be restricted to crypto only. Contact your account manager to adjust permissions.\nQ. Why am I getting HTTP 403 or \"not entitled\" errors?\nCommon causes:\n\nWrong endpoint: Ensure you are using the correct WebSocket or REST endpoint for your token.\nAsset class restriction: Your access token may not be entitled to the requested feed types.\nExpired token: Demo tokens expire; request a production token for long-term use.\n\nTroubleshooting\nQ. Why am I getting stale prices (2+ seconds old)?\nDo not use Pyth Core methods such as getPriceFeedsUpdateData with Pyth Pro. Instead:\n\nConnect directly to the Pyth Pro WebSocket endpoints (see Subscribe to Prices).\nSubscribe to the feeds you need.\nProcess the streaming data directly.\n\nPyth Pro provides sub-second latency when connected correctly. For on-chain integration, follow the Integrate as Consumer guide.\nQ. I'm seeing latency spikes in production. What should I check?\nLatency spikes can occur due to:\n\nSingle connection: Connect to all three WebSocket endpoints for redundancy.\nRouter issues: Occasionally the routing layer may experience delays.\nNetwork path: Check your network latency to our endpoints.\n\nFor high availability:\n\nMaintain connections to pyth-lazer-0, pyth-lazer-1, and pyth-lazer-2\nImplement automatic reconnection logic\nMonitor connection health and fail over to other endpoints if needed\n\nInfrastructure\nQ. What are the Pyth Pro data center locations?\nPyth Pro infrastructure is deployed across multiple data centers for low latency and redundancy, including multiple facilities in the Tokyo region. Additional regions are available. Contact support for details relevant to your latency requirements.\nQ. What is the precision of Pyth Pro timestamps?\nPyth Pro has a 1 ms update frequency, but timestamp precision may not be accurate to that level. Even with very precise server time, consumers typically do not have matching precision and would not benefit from it. For latency comparison, relative time matters more than precise timestamps: an observer compares the latency of price streams as received with their local receive time, not the source timestamp.\nAdditional Resources\n\nSubscribe to Prices\nPayload Reference\nPrice Feed IDs\nContract Addresses\nPyth Pro API Reference\nPyth Pro SDK (JavaScript)\npyth-crosschain GitHub Repository\nError CodesError responses for Pyth Pro APIsPrice Feed IDsList of price feed IDs for all the assets supported by Pyth Pro","tokens":2573,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257415028,"hash":"d7ac3d58b6d16a404f8a7923662d05c5486ede83"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/assign-node-roles","domain":"docs.arbitrum.io","title":"How to assign roles to a Nitro node | Arbitrum Docs","text":"✏️Request an updateA Nitro node's role is not a separate piece of software. Every role in this article runs the same nitro binary; what makes a node a sequencer, a batch poster, a validator, or a plain RPC node is the set of configuration flags you pass at startup. The exceptions are the feed relay — a small standalone relay binary shipped inside the same Docker image—and the optional split-validation setup, which moves block validation into a separate nitro-val binary; both are built from the same repository.\nBecause roles are just configuration, you assign or change a role by editing flags and restarting. This page explains what each role's defining flags are, what else each role needs to operate (a funded parent-chain wallet, a bond, feed connectivity, a parent-chain connection), and how to convert a node from one role to another safely.\nIf you already know which role you want, go straight to its guide—each one is linked from the table below. Read this page when you're deciding which role to run, want to see how the roles relate to each other, or need to convert an existing node from one role to another.\nFlags can be passed on the command line or collected in a JSON configuration file loaded with --conf.file. For how flag names, defaults, and the config file relate to each other, see Nitro configuration system. This article covers only the flags that define and support each role; for the complete flag list, see the CLI flags reference.\nRoles can combine on a single node (a sequencer can also post batches, for example), but this article describes them separately so that each role's requirements are clear.\nRoles at a glance​\nRoleDefining flagsWallet and bondRuns how many?Full guideRPC node (full node)none (the default)No wallet, no bondMany (horizontal scaling)Run a full nodeArchive node--execution.caching.archiveNo wallet, no bondMany (same as RPC nodes)Run an archive nodeSequencer--node.sequencer + --execution.sequencer.enableNo wallet, no bondOne per chain (or one coordinator set)Run a sequencer nodeBatch poster--node.batch-poster.enableFunded parent-chain wallet; no bondOne active (Redis lock coordinates a set)Run a batch posterValidator (staker)--node.staker.strategy set to an active valueFunded wallet and bond for active strategies onlyOne active per walletRun a validatorValidation server (split validation)nitro-val binary + --node.block-validator.validation-server.url on the nodeNo wallet, no bond (all onchain action stays on the node)Many (one node can use several)Run a split validator nodeFeed relayrelay binary + --node.feed.input.url + --chain.idNo wallet, no bond, no parent-chain connectionMany (stateless fan-out)Run a feed relay\nEvery role except the feed relay and the split-validation server needs a parent-chain connection through --parent-chain.connection.url. Nodes whose parent chain is Ethereum L1 also need --parent-chain.blob-client.beacon-url to read batches posted as EIP-4844 blobs. For well-known chains, setting --chain.id or --chain.name auto-fills defaults such as --execution.forwarding-target and --node.feed.input.url from the chain info embedded in the binary (the forwarding target is only auto-filled when the sequencer is disabled).\nRPC node (full node)​\nAn RPC node—often just called a full node—is the default role: it follows the chain and serves JSON-RPC, but it does not sequence, post batches, or actively validate. None of the role-defining flags are enabled by default.\nFlagDefaultDescription--node.sequencerfalseConsensus-side sequencer switch; off, so the node does not order transactions--execution.sequencer.enablefalseExecution-side sequencer switch; off, so the node does not build blocks itself--node.batch-poster.enablefalseOff, so the node never posts batches to the parent chain--node.staker.enabletrueStaker module on, but with the default watchtower strategy it only observes (see admonition)--execution.forwarding-target\"\"Where the node forwards eth_sendRawTransaction; auto-filled from chain info for known chains\nBeyond those defaults, a full node needs only the shared basics — --parent-chain.connection.url and --chain.id (or --chain.name) — plus --http.addr or --ws.addr to expose JSON-RPC; the servers stay off until an address is set.\nOperationally, a full node needs a parent-chain connection but no funded wallet and no bond. Feed connectivity is strongly recommended for low latency but is not required: a node with no feed input still syncs by reading batches from the parent chain, just with higher latency. You can run as many RPC nodes as you like; they share no state and need no coordination.\nInfo--node.staker.enable defaults to true, so a default full node is technically a watchtower validator: it watches onchain assertions and logs when one disagrees with its locally computed state. With the default watchtower strategy it loads no wallet and posts no bond, so it takes no onchain action. This is why \"converting to a validator\" is mostly a matter of changing the strategy and providing a wallet and bond, rather than enabling a module. To silence the watchtower entirely, set --node.staker.enable=false.\nFor the full setup, including snapshots, pruning, and Docker details, see How to run a full node.\nArchive node​\nAn archive node is an RPC node that retains every historical state instead of garbage-collecting old ones, so it can serve eth_call, balance, and trace queries at arbitrary past blocks. It is a storage variant of the full node, not a different protocol role: same binary, one extra caching flag.\nFlagDefaultDescription--execution.caching.archivefalseRetains past block state on disk instead of pruning it--execution.caching.state-schemehashState storage scheme (hash or path); path produces a much smaller archive but cannot be used on a node that must validate--execution.rpc.classic-redirect\"\"Arbitrum One only: URL of an Arbitrum Classic node that serves queries for pre-Nitro blocks--init.latest\"\"Set to archive to bootstrap from the latest archive snapshot (hash scheme only; see the archive guide for path-scheme snapshots)\nAn archive node needs no wallet and no bond, and you can run as many as you like. The cost is disk: an Arbitrum One archive database is measured in terabytes (see the archive guide for current figures). Enabling archive also makes the node keep everything else—Nitro automatically disables the consensus message pruner and retains the full transaction-hash lookup index.\nArbitrum One is the only chain with pre-Nitro (Classic) history, so only Arbitrum One archive nodes need --execution.rpc.classic-redirect pointed at an Arbitrum Classic node; every other chain launched directly on Nitro.\nFor snapshots, hardware sizing, and the full setup, see How to run an archive node.\nSequencer​\nThe sequencer orders incoming transactions, produces blocks, and publishes the sequencer feed. Enabling it requires two flags that must agree with each other.\nFlagDefaultDescription--execution.sequencer.enablefalseExecution-layer sequencer: the node orders queued transactions and builds blocks--node.sequencerfalseConsensus-layer counterpart; must agree with --execution.sequencer.enable\nNitro does not stop you if the two flags disagree—it logs an error and keeps running in a broken half-configuration—so always change them together.\nA sequencer must also declare how it coordinates with other sequencer instances, or it refuses to start. Enable the Redis-backed coordinator, or explicitly opt out with the dangerous single-sequencer flag.\nFlagDefaultDescription--node.seq-coordinator.enablefalseEnables the Redis-based coordinator for a redundant sequencer set--node.dangerous.no-sequencer-coordinatorfalseDangerous: allows sequencing without a coordinator (single-sequencer or development setups)--execution.forwarding-target\"\"Must stay empty on a sequencer; setting it with the sequencer enabled is a hard error--node.feed.output.enablefalseStarts the broadcaster that publishes the sequencer feed--node.delayed-sequencer.enablefalseIncludes parent-chain (delayed inbox) messages once their block is safe (default) or final\nThe coordinator's Redis URLs, the feed server's address and port, and feed signing are setup details covered in the sequencer guide.\nA sequencer needs a parent-chain connection (--parent-chain.connection.url), which the coordinator hard-requires. It needs no funded wallet and no bond; sequencing posts nothing onchain. The only case where a pure sequencer loads a key is --node.feed.output.signed=true, and even then the key is used to sign feed messages, not to fund transactions. Batch posting and bonding are separate roles.\nFor the complete sequencer setup and the coordinator design, see How to run a sequencer node and How to run a Sequencer Coordination Manager (SQM).\nBatch poster​\nThe batch poster compresses queued sequencer messages into batches and posts them to the parent chain's Sequencer Inbox. It does not need to be the sequencer; a separate node can post batches from the messages it receives over the feed.\nFlagDefaultDescription--node.batch-poster.enablefalseMaster switch: enables building and posting batches\nThe batch poster needs a signer for its parent-chain transactions (a local wallet or an external signer) and, for a redundant set, a Redis lock.\nFlagDefaultDescription--node.batch-poster.parent-chain-wallet.*—The funded parent-chain account (keystore or private key) that signs and pays for batches--node.batch-poster.data-poster.external-signer.url\"\"External signer RPC; replaces the local wallet for signing batch transactions--node.batch-poster.redis-url\"\"Redis URL for the leader lock that keeps only one poster active in a redundant set\nA batch poster requires a funded parent-chain wallet: it pays parent-chain gas for every batch it posts. Fund the account with enough native currency of the parent chain, and make sure the poster's address is allowlisted as a batch poster on the chain's Sequencer Inbox contract, or its transactions revert. It posts no bond. On AnyTrust chains, the node still requires the local batch-poster key even when an external signer submits the batch transactions; the key signs the data availability store requests.\nThe address the batch poster uses must not be the same address as the staker when the staker is active (a non-watchtower validator); the node rejects a shared address in that case.\nFor chain-owner configuration, blob posting, and troubleshooting, see Run a batch poster.\nValidator (staker)​\nA validator watches the chain's onchain assertions and, depending on its strategy, participates in BoLD and legacy disputes. The behavior is set by the strategy, not by a separate enable switch.\nFlagDefaultDescription--node.staker.enabletrueEnables the staker module (passive by default because of the watchtower strategy)--node.staker.strategyWatchtowerSelects behavior: watchtower, defensive, stakeLatest, resolveNodes, or makeNodes--node.block-validator.enablefalseBlock-by-block validation; force-enabled for any non-watchtower (active) strategy\nWith the default watchtower strategy the validator is observe-only: it loads no wallet and posts no bond, and it merely logs if an assertion disagrees with its local state. Any other strategy is active and needs a funded wallet and a bond.\nFlagDefaultDescription--node.staker.parent-chain-wallet.*—The funded parent-chain wallet (keystore or private key) an active validator acts from--node.staker.data-poster.external-signer.url\"\"External signer RPC; an alternative to a local key--node.staker.redis-url\"\"Redis URL backing the staker's transaction queue (queue persistence, not a leader lock)\nAn active validator needs a funded parent-chain wallet for gas and posts a bond when it acts. Under BoLD, the node reads the required bond size from the chain's contracts (it is an onchain chain parameter, not a node flag), and with --node.bold.auto-deposit and --node.bold.auto-increase-allowance enabled by default, it deposits and approves the stake token automatically when entering a bond. Active strategies also require block validation, which the node force-enables. On chains where the validator allowlist is active, the wallet address must also be allowlisted; the allowlist is enforced by the chain's contracts, so transactions from a non-allowlisted validator revert.\nThere is no leader-election or Redis-lock mechanism for the validator, unlike the batch poster or the sequencer coordinator. --node.staker.redis-url only moves the pending-transaction queue into Redis for failover of a single logical staker; it is not a lock. You must ensure only one active staker runs per wallet.\nFor the strategy comparison table, wallet setup, and BoLD details, see How to run a validator.\nSplit validation​\nBlock validation — re-executing blocks against the chain's WASM machines — is the CPU-heavy part of validating. By default this work stays inside the node: with block validation on, the default --node.block-validator.validation-server.url value of self-auth starts an internal validation server reached over the node's own authenticated websocket loopback. Split validation moves that work to a separate machine running the nitro-val binary, while the wallet, the bond, and the record of validation progress all stay on the main node.\nOn the validation server (nitro-val binary):\nFlagDefaultDescription--auth.addr127.0.0.1Interface the JWT-authenticated validation API listens on; set it to an address the node can reach--auth.port8549Port for the validation API--auth.jwtsecret\"\"Path to the shared 32-byte hex JWT secret file; auto-generated if unset--validation.wasm.root-path\"\"Path to the folders holding the validation machines (one per WASM module root)\nOn the main node (nitro binary):\nFlagDefaultDescription--node.block-validator.validation-server.urlself-authWhere validation work goes; set to the ws://host:port of the nitro-val server--node.block-validator.validation-server.jwtsecret\"\"Path to the same JWT secret file the server uses--node.block-validator.validation-server-configs-listdefaultJSON array of server configs; lets one node fan validation out to several servers\nThe validation server holds no wallet and posts no bond, and it is stateless — it runs with an ephemeral data directory, so you can replace a server in place, or add servers with a node restart, without losing any validation progress. The --auth.* flags exist on both binaries with the same defaults; on the main node they back the default self-auth loopback. Switching between in-process and split validation is a configuration change plus a restart; no database migration is involved.\nFor Docker images, Helm charts, and the full setup, see Run a split validator node and Docker images and CLI binaries.\nFeed relay​\nThe feed relay is not a mode of the nitro binary. It is a separate relay binary built from the same repository and shipped in the same Docker image; you run it by overriding the container entrypoint to relay. The relay subscribes to a sequencer feed and re-broadcasts it to downstream nodes. It is stateless fan-out: no parent-chain connection, no wallet, no bond, and no database.\nFlagDefaultDescription--node.feed.input.url[]Sequencer feed source(s) the relay subscribes to; the relay will not start empty--chain.id0Chain ID; required, and embedded in the feed handshake for downstream clients--node.feed.output.addr\"\"Address to bind the relay's feed output to (empty binds all interfaces)--node.feed.output.port9642Port the relay's feed output listens on--node.feed.input.secondary-url[]Failover feed source(s), started in order when the primary feeds fail\nDownstream nodes then point their own --node.feed.input.url at the relay. You can run as many relays as you like: each one independently subscribes upstream and serves its downstream clients, and relays can even be chained. A node connected to multiple feeds or relays deduplicates messages by sequence number, so redundant feed sources are safe.\nFor setup, Docker commands, and Kubernetes charts, see How to run a feed relay.\nConverting between roles​\nConverting a node from one role to another means changing its flags and restarting, plus arranging whatever the target role needs operationally (funding a wallet, arranging a bond and allowlisting, provisioning Redis, or opening a feed port). Before changing any role, read the safety rules below.\nWarningSome roles must not be duplicated for the same chain:\nNever run two sequencers for the same chain unless they are in one coordinator (SQM) set. Two uncoordinated sequencers fork the feed and double-order transactions; only the ordering that reaches the parent-chain inbox survives, and nodes that followed the other ordering must reorg or halt.\nNever run two batch posters for the same chain outside the Redis lock. They race on nonces and batch positions, and the loser's parent-chain transaction reverts, burning gas. The node-side protections are the Redis lock and revert polling.\nNever run two active stakers with the same wallet. There is no built-in staker leader election, so they conflict on nonces and stall each other.\nSafe to run many: RPC nodes, archive nodes, feed relays, and validation servers. They share no protocol state and need no coordination.\n\nRole-specific conversion notes:\n\nRPC node to sequencer: set both --node.sequencer=true and --execution.sequencer.enable=true (they must agree), clear --execution.forwarding-target (setting it with the sequencer enabled is a hard error), publish the feed with --node.feed.output.enable=true, enable --node.delayed-sequencer.enable=true, and decide on coordination — either the Redis coordinator or --node.dangerous.no-sequencer-coordinator=true.\nSequencer to RPC node: set both sequencer flags to false, re-set --execution.forwarding-target to the chain's sequencer endpoint (or null, or rely on the chain-info default), disable --node.delayed-sequencer.enable and --node.seq-coordinator.enable, and re-add --node.feed.input.url.\nEnabling the batch poster: fund the parent-chain wallet and get its address allowlisted on the Sequencer Inbox before you start posting; provide a signer and, for a redundant set, a shared Redis URL.\nWatchtower to active validator: set --node.staker.strategy to an active value, provide and fund a wallet, arrange the bond, and let block validation come on automatically. This adds substantial CPU, memory, and disk needs.\nFull node to archive node: flipping --execution.caching.archive=true on an existing database only archives state from that point forward; history the node already pruned is not backfilled. For full history, re-initialize from an archive snapshot (--init.latest archive) or — on a hash-scheme database that still holds an early state — rebuild missing states by re-execution with --init.recreate-missing-state-from (very slow, and not supported with the path state scheme). No wallet or funding is involved.\nMoving validation to a separate machine (split validation): start nitro-val on the new machine with the validation machine folders and a reachable --auth.addr, share the JWT secret file between the two processes, and point the node's --node.block-validator.validation-server.url and .jwtsecret at the server (the full guide uses the equivalent --node.block-validator.validation-server-configs-list JSON form, which is also how you configure multiple servers). Validation progress stays in the node's database, so this is a flags-and-restart change in both directions.\nDecommissioning an active validator: do not simply kill the node. On pre-BoLD chains, a staker that keeps running with its wallet and an active strategy (defensive keeps the wallet loaded without seeking new bonds) automatically returns its old deposit and withdraws the funds once the assertion it bonded on is confirmed; only then switch to watchtower or disable the staker and shut down. Switching to watchtower too early doesn't work: it loads no wallet, so nothing can withdraw. On BoLD chains, withdrawing the bond is a manual onchain operation. Either way, stopping the node early leaves the bond locked onchain until you withdraw it.\n\nFor background on how nodes fit together, see the Nodes overview and, for the data flow between the sequencer, feed, and full nodes, Data availability.Roles at a glanceRPC node (full node)Archive nodeSequencerBatch posterValidator (staker)Split validationFeed relayConverting between roles","tokens":5092,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257415228,"hash":"eb738ec7d78af06f4abcebabbc3aca5cd8624dbe"}
{"url":"https://gov.optimism.io/t/about-the-optimism-collective/6118","domain":"gov.optimism.io","title":"About the Optimism Collective - Get Started 🌱 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n About the Optimism Collective \n\n Get Started 🌱\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Jun 2023\n\n 1 / 9\n\n Jun 2023\n\n Jun 2025\n\n post by system on Jun 16, 2023\n\n system\n\n Welcome to the Optimism Collective governance forum!\nThe forum is where governance participants discuss critical topics relating to the Collective.\nWhat is the Optimism Collective?\nThe Optimism Collective is a new model of digital democratic governance. It is a band of communities, companies, and citizens united by the axiom of impact=profit — the principle that positive impact to the Collective should be rewarded to the individual.\nEmpowering values. Robust infrastructure. An economy where everyone thrives.\nThe foundation for a more equitable digital economy is an interconnected network of blockchains built on a modular, open-source codebase.\nHow is this going to be governed?\nThe Optimism Collective and the Superchain take an experimental and agile approach to governance, relentlessly iterating towards a system which stands the test of time.\nThe Collective’s model of digital democratic governance consists of two houses: the Token House and the Citizens’ House. These two houses form a bicameral governance system, with the two-house design is intended to help the Collective make better decisions, avoid common pitfalls in token-based governance systems, and have checks and balances.\nWhat is described here is an initial experiment. The specifics of this system will evolve as the Collective grows.\nimage398×361 53.3 KB\nWhat is the Token House?\nGovernance of the Optimism Collective began with the launch of the OP token and the Token House.\nAs Token House members, OP holders are responsible for submitting, deliberating, and voting on various types of governance proposals.\nIn carrying out these functions, OP holders may either vote directly, or delegate their OP voting power to someone else.\nLearn how to delegate your OP tokens. You can delegate to yourself, or anyone else!\nThe Token House votes on the proposal types outlined in the Operating Manual. You can join the discussion by visiting the Delegates category.\nYou can learn more in the Token House Onboarding Hub.\nWhat is the Citizens’ House?\nThe Citizens’ House is a large-scale experiment in a reputation-based governance system (one member = one vote), and is primarily responsible for Retroactive Public Goods Funding (Retro Funding).\nJoin the discussion by following the Retro Funding category and the Citizens category.\nBut what do they really do?\nYou can find a more detailed breakdown of responsibilities in this diagram.\nGov responsibilites (1)1920×927 54.3 KB\n\n 2\n\n 11 months later\n\n post by pikkaeuroman on May 11, 2024\n\n pikkaeuroman\n\n This is a visual detailed information. Thanks for sharing for a noob like me. Optimism Collective is an initiative with purpose and vision. Love it\n\n 5 months later\n\n post by ehsan68bad on Oct 9, 2024\n\n ehsan68bad\n\n this is link invite for me. come to in.. strong text\n\n 21 days later\n\n post by erfours on Oct 30, 2024\n\n erfours\n\n Ok nice i have any people can help my project\n\n post by ehsan68bad on Nov 7, 2024\n\n ehsan68bad\n\n very nice I hope that the various networks will greatly increase the cooperation to solve the problems and difficulties of the path by merging\n\n post by Dnng on Nov 9, 2024\n\n Dnng\n\n I think this is a great ideaband will be very useful for the project\n\n 4 months later\n\n post by ahronropa.eth on Mar 4, 2025\n\n ahronropa.eth\n\n Nice! Amazing! Cool!!\n\n 4 months later\n\n post by Rudy09 on Jun 19, 2025\n\n Rudy09\n\n Hello Optimism Collective! \nI’m excited to be part of this vibrant community. As a 27-year-old woman passionate about blockchain, Farcaster, and trend analysis, I’m eager to contribute to Optimism’s vision of scaling impact through community-driven governance.\nI’m currently exploring how creative expression, especially through digital art and design, can intersect with governance and participation on Optimism. I believe the Collective has the potential to empower diverse voices—not just technically, but culturally.\nLooking forward to learning more and participating in the mission to build a more optimistic internet. \n\n post by onadio on Jun 20, 2025\n\n onadio\n\n thanks for information visual detail is good \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to the Optimism Collective Discourse!\n\n Get Started 🌱\n\n The Optimism Collective is a large-scale experiment in decentralized governance. Our vision is to sustainably fund public goods that improve upon the well-being of the Collective and beyond. The form and function of this…\n\n read more\n\n 104\n\n 12.6k\n\n Aug 2025\n\n Exploring Optimism’s Broader Vision: Questions for My Thesis on Governance and Future Goals\n\n ✨ General\n\n My name is Jonathan, and I am a student at one of the first academies in the world to offer a specialization in blockchain. My thesis focuses on Optimism. My knowledge of Optimism is currently limited to its Layer 2 solu…\n\n read more\n\n 2\n\n 105\n\n Oct 2024\n\n Working Constitution of the Optimism Collective\n\n Get Started 🌱\n\n The Optimism Collective is a large-scale experiment in decentralized governance. Our Vision is to sustainably fund those public goods that improve upon the well-being of the Collective and beyond. This Working Constituti…\n\n read more\n\n 628\n\n 61.4k\n\n 28d\n\n Operating Manual of the Optimism Collective (v0.2.0)\n\n Delegates 🏛\n\n This document describes the current governance proposal process of the Optimism Collective. It will evolve, with the Collective, over time. The authoritative version is maintained here on the Optimism Foundation Github. \n…\n\n read more\n\n 5\n\n 3.4k\n\n Sep 2022\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024","tokens":1533,"squid":"ink-governance","role":"Council Listener","at":1791257416624,"hash":"efc50e2f92a3369682c0e94f99ec27aef1f9afcb"}
{"url":"https://docs.pyth.network/price-feeds/pro/integrate-as-consumer","domain":"docs.pyth.network","title":"Integrate prices on blockchain | Pyth Developer Hub","text":"Pyth ProIntegrate prices on blockchainLearn how to integrate Pyth Pro prices on blockchainThe following guides demonstrate how to integrate and verify prices as a consumer on blockchain.\nPyth Pro price updates can be verified on Solana, Fogo, EVM chains, Sui, IOTA, Cardano, and Stellar. Please consult the following guides to get started:\n\nSolana and Fogo\nEVM\nSui\nIOTA\nCardano\nStellar\n\nPyth Pro price updates can also be used in off-chain applications. See the\nsubscribe to prices guide and the Terms of Service for more information.Subscribe to PricesLearn how to authenticate, configure, and subscribe to Pyth Pro price streamsin SVM programsNext Page","tokens":164,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257424886,"hash":"48a7ba6681acdaf8d336e880bac5c926f99694cf"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/data-availability","domain":"docs.arbitrum.io","title":"Data Availability | Arbitrum Docs","text":"✏️Request an updateHow Arbitrum data availability works​\nWhat is the general view of Arbitrum data flow?​\nArbitrum currently supports two primary data availability mechanisms:\nRollup mode​\nIn this mode, all transaction data is included in either the calldata or blobs of transactions submitted to the parent chain (e.g., Ethereum mainnet for Arbitrum One). This inclusion ensures that all data is readily available onchain for anyone to download and verify.\nAnyTrust mode​\nIn AnyTrust mode, transaction data initially gets submitted to a group of nodes known as the Data Availability Committee (DAC). The DAC stores and distributes the data. Instead of including the entire dataset onchain, only a cryptographic proof that the data has been stored by the DAC (Data Availability Certificate, or DACert) is submitted to the parent chain. This proof significantly reduces the amount of data stored onchain, reducing costs.\nBecause of those data availability mechanisms, Arbitrum Nitro nodes synchronize their data differently than Ethereum nodes or other layer-one network nodes. While Go-Ethereum nodes utilize a sophisticated P2P network to synchronize with the Ethereum blockchain by discovering other nodes, exchanging data, and participating in the consensus mechanism, Arbitrum nodes diverge from this traditional approach and use a trustless process.\nHere's how Arbitrum data flow works:\n\nBatching and submission:\n\nThe sequencer queues transactions and batches them together.\nThese batches get submitted to the parent chain:\n\nIn Rollup mode, the sequencer submits the batch of transactions directly to the sequencer inbox contract on the parent chain. (Blobs or calldata directly)\nIn AnyTrust mode, the sequencer sends the batch to the Data Availability Committee (DAC) and then submits the Data Availability Certificate (DACert) which is returned and generated by the Data Availability Server (DAS) to the parent chain.\n\nNode synchronization:\n\nUpon joining the network, a full node:\n\nIn Rollup mode, data is read directly from the parent chain calldata or blobs (depending on how the sequencer posts the data).\nIn AnyTrust mode, it checks the DACert to verify data availability and queries the data from the DAC.\n\nThe node continues to follow this process to catch up with the latest chain height.\nOnce caught up, the node receives updates on new sequencer-queued messages directly from the sequencer feed (we will provide details of this process in the last section).\n\nCatching up:\n\nIf a node falls behind the chain, it reverts to the process described in Step 2 to resynchronize with the latest state.\n\nIn essence, Arbitrum nodes prioritize data retrieval from the parent chain and rely on the sequencer for real-time updates, deviating from the traditional P2P synchronization approach used by Ethereum nodes.\nFor operational guides that build on these concepts, see How to run a sequencer node and How to run a validator.\nHow full nodes decode the data from the parent chain​\nArbitrum full nodes decode data received from the parent chain (and, in the case of AnyTrust chains, the DAC) to update their local state. This process involves monitoring events, parsing data, and processing messages.\n\nEvent querying:\n\nFull nodes subscribe to the SequencerBatchDelivered event emitted by the inbox contract on the parent chain. This event signifies the arrival of a new batch of transactions.\n\nEvent parsing:\n\nUpon receiving the SequencerBatchDelivered event, the node parses the event data into a SequencerInboxBatch struct. This struct typically includes:\n\nBlockHash: The hash of the parent chain block containing the batch.\nParentChainBlockNumber: The block number of the parent chain block.\nSequenceNumber: The sequence number of the batch.\nTimeBounds: Time constraints for the batch.\nAfterDelayedAcc: Accumulator hash after processing delayed messages.\nAfterDelayedCount: Count of delayed messages.\nrawLog: The raw event log data.\n\nData serialization:\n\nThe SequencerInboxBatch struct serializes into a byte array.\nThe serialized data adheres to a specific format:\n\nTimeBounds.MinTimestamp (8 bytes)\nTimeBounds.MaxTimestamp (8 bytes)\nTimeBounds.MinBlockNumber (8 bytes)\nTimeBounds.MaxBlockNumber (8 bytes)\nAfterDelayedCount (8 bytes)\npayload (variable length)\n\nThe payload field further contains the following:\n\nType: Indicates the header of payload (e.g., DACert, blob message).\nContent: The actual data associated with the payload header (e.g., DACert, BlobHashes, Brotli compressed data).\n\nData decoding and retrieval:\n\nBased on the payload header:\n\nDAS Message header: The node queries the Data Availability Servers to retrieve the raw data.\nBlob message header: The node decodes the blob message to obtain the raw data.\nBrotli Message header: No extra steps are needed here; continue to the next step.\n\nData decompression: If the raw data is Brotli-compressed, the node decompresses it. It's worth noting that the raw data we get from above i and ii might also be Brotli-compressed data.\n\nMessage processing:\n\nAfter decoding and decompressing the data, the node obtains a series of batch segment messages.\n\nMessage Types:\nBatch Segment Message typeWhat is the usage of this messageBatchSegmentKindL2MessageThis message will contain raw data on a series of transactions. Usually, this is a single block.BatchSegmentKindL2MessageBrotliThe message is the same as the above one, but this is brotli compressed data.BatchSegmentKindDelayedMessagesThis message contains a new delayed message read from the parent chain Delayed Inbox.BatchSegmentKindAdvanceTimestampThis message will notify the State Transition Function (STF) to advance a second of the timestamp state.BatchSegmentKindAdvanceL1BlockNumberThis message will notify STF to advance a new parent chain block number.\n\nState transition: finally, the State Transition Function (STF) processes these messages, and the STF will follow the rules to execute and update the Arbitrum node's local state.\n\nHow full nodes sync the data from the sequencer feed​\nOnce Arbitrum full nodes have caught up with the chain, they switch from initial synchronization to a real-time update mode. This switch involves receiving data from the sequencer feed, which continuously broadcasts updates about newly queued transactions.\n\nData acquisition:\n\nFull nodes maintain a connection to the sequencer feed or your private feed. For how to run a private feed, please refer to How to run a feed relay\nThe sequencer feed transmits data packets containing information about the latest queued transactions.\n\nData decoding:\n\nFull nodes decode the received data packets using the methods described in How to read the sequencer feed.\n\nMessage processing:\n\nAfter successful decoding, the full nodes obtain the same type of data as outlined in the previous section's Step 5.\nSend the message to the State Transition Function (STF) and execute.\n\n(This step is the same as the previous section's Step 5)\n\nHow Arbitrum data availability worksWhat is the general view of Arbitrum data flow?Rollup modeAnyTrust modeHow full nodes decode the data from the parent chainHow full nodes sync the data from the sequencer feed","tokens":1787,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257425102,"hash":"194583a490da14750c102698bd94b6d77ebce0c0"}
{"url":"https://gov.optimism.io/","domain":"gov.optimism.io","title":"Optimism Collective - Optimism Collective","text":"Welcome to the Collective\n\n Optimism Collective's Governance Forum\n\n Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n All latest topics\n\n categories\n\n tags\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Working Constitution of the Optimism Collective\n\n Get Started 🌱\n\n The Optimism Collective is a large-scale experiment in decentralized governance. Our Vision is to sustainably fund those public goods that improve upon the well-being of the Collective and beyond. This Working Constituti…\n\n read more\n\n 628\n\n 61.4k\n\n 28d\n\n Exploring execution-time authorization for Superchain applications\n\n ✨ General\n\n I’d like to get feedback from Optimism builders and the broader Superchain community on a potential infrastructure primitive for applications, payment flows, smart accounts and autonomous transaction systems. \nThe proble…\n\n read more\n\n 5\n\n 65\n\n 1m\n\n Protocol Delegation Program Renewal\n\n Metagovernance\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d\n\n 404 Gov - Delegate Platform\n\n Delegates 🏛\n\n An important update regarding the future of 404 DAO’s governance operations. \nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What sta…\n\n read more\n\n 1\n\n 59\n\n 1d\n\n Introducing improvements to the Protocol Upgrade process\n\n Updates and Announcements 📢\n\n season-8\n\n As communicated in the Season 8 announcements, we launched significant improvements to the Protocol Upgrade process on August 1st. Here’s what you need to know: \nTL;DR\n\nProtocol upgrades now require approval by the Deve…\n\n read more\n\n 7\n\n 342\n\n 1d\n\n Proposal to Align the OP Token with Superchain Success\n\n Proposals 📃\n\n season-9\n\n Proposal to Align OP Token with Superchain Success\nThis proposal was updated on 1/15/26 to reflect community feedback to split the original proposal into two separate proposals. \nExecutive Summary\n\nThis proposal would im…\n\n read more\n\n 36\n\n 4.3k\n\n 1d\n\n Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\n\n Proposals 📃\n\n Proposal Type: Rights Protections \nExecutive Summary\nThe Optimism Foundation is proposing to re-designate the unspent tokens in the User Airdrop allocation as a new allocation category, the Strategic Ecosystem Fund, prop…\n\n read more\n\n 12\n\n 1.3k\n\n 9d\n\n [RFC] Civilizational Upgrade: Implementing the ACOM P2P Semantic Mesh & Holographic Chain on the OP Superchain\n\n Governance Design and Strategy 📐\n\n Authors: The Promethean Network State (TPNS) & The Promethean Institute\nCategory: Technical Integration, Infrastructure, Real-World Utility, Public Goods\nStatus: Active RFC / Proposed Integration\n\n1. Core Philosophy: I…\n\n read more\n\n 4\n\n 123\n\n 11d\n\n Eden Fractal Epoch 2: Implementing Fractal Decision-Making on the Superchain\n\n Community Calls\n\n Dear Optimists, \nWelcome to Eden Fractal Epoch 2! \nAfter three transformative years of pioneering fractal governance, Eden Fractal is entering its second epoch—a new chapter where we move from experimentation to …\n\n read more\n\n 32\n\n 703\n\n 13d\n\n Season 9 Final Report\n\n Grants Updates\n\n Highlights\nThe Grants Council closed Season 9 submissions on May 20th. \nSubmission flow increased significantly in the final two cycles, bringing the Season 9 total to 38 applications. \nAcross the season, GrantNerds revi…\n\n read more\n\n 9\n\n 464\n\n 13d\n\n Season 8 Growth Grants - TVL Impact Review\n\n ✨ General\n\n season-8\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me. \nI did …\n\n read more\n\n 2\n\n 165\n\n 13d\n\n Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0\n\n Protocol Upgrade\n\n Proposal Type: Protocol Upgrade\nHi, I’m Andrea Federici, Senior Solutions Engineer at OP Labs. I prepared this proposal in collaboration with Adrian Sutton, Matt Solomon and Matthew Cruz from the OP Labs team. Neither OP…\n\n read more\n\n 2\n\n 281\n\n 20d\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n Governance Fund Missions\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions be…\n\n read more\n\n 4\n\n 127\n\n 27d\n\n An Optimism Governance / Ecosystem Grant Proposal\n\n Proposals 📃\n\n Project Name: STRATEGIC POWER 360 \n\nProtocol Component: Public Light 3.0 (Algorithmic Governance & Auditing Layer) \nAuthor / Project Lead: Juan Carlos Farías Salazar \nLegal Jurisdiction: Wyoming, USA (DAO / DUNA Archit…\n\n read more\n\n 0\n\n 52\n\n 30d\n\n Optimism Governance / Ecosystem Grant Proposal\n\n Get Started 🌱\n\n Project Name: STRATEGIC POWER 360 \nProtocol Component: Public Light 3.0 (Algorithmic Governance & Auditing Layer) \nAuthor / Project Lead: Juan Carlos Farías Salazar \nLegal Jurisdiction: Wyoming, USA (DAO / DUNA Architect…\n\n read more\n\n 0\n\n 49\n\n Sep 4\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n ✨ General\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 106\n\n Sep 4\n\n Security Council Communication Thread\n\n Council Communication Threads\n\n Welcome to the Security Council Communication Thread!\nThe goal of the Security Council is to turn admin keys for OP Mainnet, and eventually, all OP Chains in the Superchain, over to a public, decentralized set of individ…\n\n read more\n\n 18\n\n 1.4k\n\n Sep 3\n\n PGov - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate Name: @PGov \nDelegate Address: PGov.eth (0x3fb19771947072629c8eee7995a2ef23b72d4c8a) \nForum Handle: @PGov, @Juanbug_PGov \nEmail: PGovTeam@gmail.com \nCore Principles: \n\nTransparency: Clear communication with vote…\n\n read more\n\n 45\n\n 3.6k\n\n Sep 2\n\n Maintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard Optimism Governance\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nExecutive Summary\nThis proposal transitions the ProxyAdmin Owner of Unichain Mainnet (chai…\n\n read more\n\n 0\n\n 56\n\n Sep 2\n\n Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nSummary\nThis proposal requests the Optimism Security Council return administrative ownersh…\n\n read more\n\n 0\n\n 54\n\n Sep 2\n\n [Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s)\n\n Governance Fund Missions\n\n Hello Optimism Collective, \nWe have developed Ag^τ, a proprietary, zero-FPU semantic compression engine designed to reduce L1 calldata costs and lower hardware overhead for EVM rollups. \nAs Optimism scales, L1 data avail…\n\n read more\n\n 2\n\n 84\n\n Aug 25\n\n Accelerated Decentralization Proposal For Optimism\n\n ✨ General\n\n Authors: @GFXlabs \nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary) \nIf you hold OP, please signal your approval of this accelerated decentralization on this Snap…\n\n read more\n\n 36\n\n 3.6k\n\n Aug 25\n\n Buyback Communication Thread\n\n Communications 📣\n\n season-9\n\n This communication thread will be used to provide transparency into buyback execution via OTC. We will update this post with links to any relevant dashboards and will post execution details monthly. As the program author…\n\n read more\n\n 6\n\n 866\n\n Aug 25\n\n Maintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nSummary\nThis proposal updates the recipient configured on Soneium’s four L2 fee vault predeploys (SequencerFeeVault, BaseFeeVault, L1FeeVault, OperatorFeeVault) from the current treasu…\n\n read more\n\n 1\n\n 117\n\n Aug 23\n\n Brichis - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate statement \nFirstly, allow me to introduce myself. My name is Bricia, although you’re welcome to call me Brichis and I am Co-Founder of Ethereum Mexico. \nMy decision to become a delegate was sparked by discussio…\n\n read more\n\n 48\n\n 3.9k\n\n Aug 21\n\n FranklinDAO (Penn Blockchain) - Delegate Communication Thread\n\n Delegate Updates\n\n Address or ENS: FranklinDAO.eth \nDiscord username: Juanbug#9225 \nHello everyone! We’re FranklinDAO/Penn Blockchain (@PennBlockchain on twitter), a leading, completely student run blockchain organization from The Universi…\n\n read more\n\n 5\n\n 2.2k\n\n Aug 21\n\n Collective Year 4 Budget Update and Year 5 Budget Outlook\n\n Foundation Budgets\n\n Summary\nYear 4 (May 2025 to April 2026) was a year of focus and fiscal discipline. The Collective committed roughly 150M OP of new commitments across Season 8 and Season 9, about one third less than the 229.92M OP commit…\n\n read more\n\n 2\n\n 441\n\n Aug 7\n\n Sandcastles and Social Mercenaries: Why EVM DAOs Are Being Looted\n\n ✨ General\n\n Optimists, \nHumanity learned thousands of years ago that an open city with vast treasure is an invitation to plunder. Walls were built to stop looters. Rules were written to prevent brute power from ruling. Police were c…\n\n read more\n\n 2\n\n 88\n\n Aug 7\n\n [RFC] Operational Mandate: S9 Impact Autopsy & S10 Capital Efficiency Oracle\n\n Governance Design and Strategy 📐\n\n Author: @JulianCross (Independent Data Architect) \nSponsor: [Call for Delegate Sponsor] \n1. Abstract & Problem Statement \nThe Token House distributed millions in OP during Season 9, yet lacks a centralized, automated art…\n\n read more\n\n 6\n\n 157\n\n Aug 4\n\n Maintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer Rotation\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nVoting Cycle Type: Off-cycle. Per the OPerating Manual, Maintenance Upgrade Proposals proceed directly to on-chain voting under optimistic approval, with a one-week veto period and a 2…\n\n read more\n\n 0\n\n 97\n\n Jul 22","tokens":2609,"squid":"ink-governance","role":"Council Listener","at":1791257428724,"hash":"749be78d2d5679ad9d81ffb60221d7941ec2b9c2"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/run-nitro-dev-node","domain":"docs.arbitrum.io","title":"How to run a local Nitro dev node | Arbitrum Docs","text":"✏️Request an updateOverview​\nThis page provides step-by-step instructions for setting up and running a local Nitro node in --dev mode. This mode is ideal for developers who want to quickly test contracts using a single node, as it offers a simpler and faster setup compared to more complex environments.\nWhile some teams use nitro-testnode for testing cross-layer messaging, which involves launching both Geth as parent chain and Nitro as child chain, this setup can be more complex and time-consuming. If your primary goal is to test contracts on a local node without needing cross-layer interactions, Nitro's --dev mode offers a lightweight and efficient alternative.\nHowever, if you need more advanced functionality—such as cross-layer messaging, working with both the parent and child chains, or testing interactions between different layers—nitro-testnode is the preferred option. The testnode setup allows you to simulate a full parent-child chain environment, which is critical for those scenarios. See [How to run a local full chain simulation](/run-arbitrum-node/03-run-local-full-chain\n-simulation.mdx) for instructions.\nStylus contract testingNitro --dev mode is ideal for Stylus contract testing, as it is much lighter and faster to set up than the full nitro-testnode environment.\nPrerequisites​\nBefore beginning, ensure the following is installed and running on your machine:\n\nDocker: Required to run the Nitro dev node in a container. Install Docker by following the official installation guide for your operating system.\ncast: A command-line tool from Foundry for interacting with Ethereum smart contracts. You can install it via Foundry by following the installation instructions.\njq: A lightweight JSON parsing tool used to extract contract addresses from the script output. Install jq by following the official installation guide for your operating system.\n\nClone the nitro-devnode repository​\nUse the following command to clone the repository:\ngit clone https://github.com/OffchainLabs/nitro-devnode.gitcd nitro-devnode\nRun the dev node script:​\nRun the script to start the Nitro dev node, deploy the Stylus Cache Manager contract, and register it as a WASM cache manager using the default development account:\n./run-dev-node.sh\nThe script will:\n\nStart the Nitro dev node in the background using Docker.\nDeploy the Stylus Cache Manager contract on the local Nitro network.\nRegister the Cache Manager contract as a WASM cache manager.\n\nDevelopment account (used by default)​\nIn --dev mode, the script uses a pre-funded development account by default. This account is pre-funded with ETH in all networks and is used to deploy contracts, interact with the chain, and assume chain ownership.\n\nAddress: 0x3f1Eae7D46d88F08fc2F8ed27FCb2AB183EB2d0E\nPrivate key: 0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659\n\nYou don’t need to set up a private key manually unless you prefer using your own key.\nChain ownership in --dev mode​\nIn Nitro --dev mode, the default chain owner is set to 0x0000000000000000000000000000000000000000. However, you can use the ArbDebug precompile to set the chain owner. This precompile includes the becomeChainOwner() function, which can be called to assume ownership of the chain.\nChain ownership is important because it allows the owner to perform certain critical functions within the Arbitrum environment, such as:\n\nAdding or removing other chain owners\nSetting the parent and child chain base fees directly\nAdjusting the gas pricing inertia and backlog tolerance\nModifying the computational gas target and transaction gas limits\nManaging network and infrastructure fee accounts\n\nThe script automatically sets the chain owner to the pre-funded dev account before registering the Cache Manager contract. Here’s how the becomeChainOwner() function is called within the script:\ncast send 0x00000000000000000000000000000000000000FF \"becomeChainOwner()\" --private-key 0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659 --rpc-url http://127.0.0.1:8547\nThis step ensures that the dev account has ownership of the chain, which is necessary to register the Cache Manager as a WASM cache manager.\nAt the end of the process, you'll have the Nitro dev mode running with the necessary components deployed. This environment is ready for testing and interacting with your contracts, including those written in Stylus, using the deployed Cache Manager to support enhanced functionality for Stylus-based smart contracts.OverviewPrerequisitesClone the nitro-devnode repositoryRun the dev node script:Development account (used by default)Chain ownership in --dev mode","tokens":1156,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257434987,"hash":"b8639ee7a8106584726ba173650a4318f4f3276b"}
{"url":"https://gov.optimism.io/t/exploring-execution-time-authorization-for-superchain-applications/10882","domain":"gov.optimism.io","title":"Exploring execution-time authorization for Superchain applications - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Exploring execution-time authorization for Superchain applications \n\n ✨ General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n Sep 24\n\n 1 / 6\n\n Sep 23\n\n 1m ago\n\n post by Gomez on Sep 24\n\n Gomez\n\n I’d like to get feedback from Optimism builders and the broader Superchain community on a potential infrastructure primitive for applications, payment flows, smart accounts and autonomous transaction systems.\nThe problem\nAuthorization can happen upstream of execution. Between that authorization decision and the point where an action is actually released, the executable payload can potentially become stale, altered, replayed, or otherwise no longer correspond to what was originally authorized.\nA2SPA addresses that specific boundary.\nIt is an execution-time authorization layer that cryptographically binds the exact executable payload and relevant constraints — such as destination, amount, parameters, permissions and freshness/nonce — to a signed authorization artifact.\nImmediately before execution, the actual payload is verified against that authorization.\nIf the action reaching execution is not the action that was authorized, verification fails.\nIn simplified terms:\nAuthorize → bind exact payload + constraints → sign → verify at execution → release only if it matches.\nA2SPA is not intended to replace wallets, account abstraction, policy engines, fraud controls, transaction simulation or existing security mechanisms. It provides a different assurance boundary: cryptographic evidence that the action authorized upstream is the same action that reaches execution.\nI’m interested in whether this has a meaningful place within the Superchain ecosystem — whether at the application layer, middleware, an OP Stack integration point, or elsewhere in the transaction lifecycle.\nWould builders/delegates see value in exploring this as an open technical integration, and if so, where would the most appropriate integration boundary be?\nI can share a short technical flow and interoperability sketch if there is interest.\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by MconnectDAO on Sep 24\n\n MconnectDAO\n\n The idea is directionally useful, but execution time authorization appears much harder than the post suggests. Matching an approved payload with executed calldata can protect integrity, yet it does not guarantee that the action remains safe or economically correct under changed onchain state.\nFor example, a swap can execute with the exact approved calldata while price, liquidity, oracle conditions, transaction ordering or proxy implementation have changed. In cross chain flows, delay, message ordering, replay and destination state add further complexity.\nIt would be useful to clarify the threat model, trust assumptions, verification layer, handling of dynamic state, revocation, upgrades, partial execution, replay protection, gas overhead and cross chain semantics. Without these details, this looks more like a promising authorization primitive than a complete execution security solution. @Gomez\n\n post by MconnectDAO on Sep 24\n\n MconnectDAO\n\n OP should not treat this as a protocol level security solution before an application layer prototype proves a unique gap. The proposal should first define a precise threat model and demonstrate why smart account modules, session keys, multisig policy controls and existing intent constraints cannot achieve the same protection. If the value is validated, an optional Superchain compatible standard or SDK may be more suitable than mandatory OP Stack enforcement.\n@Gomez\n\n post by Gomez on Sep 24\n\n Gomez\n\n MconnectDAO\n\n Thanks, this is exactly the kind of technical distinction I was hoping to surface.\nI agree that payload integrity alone should not be presented as execution safety or economic correctness. A2SPA’s intended scope is narrower: proving that the specific executable action reaching the execution boundary is the action that was authorized, under the constraints defined by the authorization.\nYour swap example is a useful illustration. If calldata remains identical while price, liquidity or other relevant state changes, A2SPA should not claim that the transaction is therefore economically correct. Those conditions need to be represented as explicit execution constraints or handled by the surrounding application/policy layer.\nI also agree that the next step should be application-layer validation rather than proposing an OP Stack-level security mechanism.\nIn particular, I’ll work through:\n\na precise threat model and trust assumptions;\nreplay, nonce, freshness and revocation semantics;\ndynamic-state and constraint handling;\nupgrade/proxy and partial-execution cases;\ncross-chain/domain binding and message ordering;\nverification location and bypass resistance;\ngas/latency considerations; and\na direct comparison with smart-account modules, session keys, multisig policies and intent constraints.\n\nThe key question I want to test is therefore narrower:\nIs there a distinct execution-integrity gap that remains when those mechanisms authorize or constrain an action, but the actual executable payload is produced, delegated, delayed, transformed or handed off before the final execution boundary?\nIf that gap can be demonstrated with an application-level prototype, I agree that an optional Superchain-compatible SDK/standard would be a more appropriate direction than mandatory OP Stack enforcement.\nI’ll put together the threat model and a concrete application-level flow so the distinction can be evaluated technically rather than as a product claim.\n\n post by Gomez on Sep 24\n\n Gomez\n\n A2SPA — Execution-Time Authorization\nThreat Model & Superchain Interoperability Note\nIndependent technical working note • Optimism / Superchain context • September 2026\nPurpose\nThis note responds to technical feedback on whether A2SPA can provide a distinct execution-integrity primitive for Superchain applications. It deliberately narrows the claim: A2SPA is not presented as a complete transaction-security, economic-correctness, or OP Stack protocol-security solution.\nCore claim under test: when an application authorizes a specific executable action upstream of execution, can a verifier establish immediately before release that the exact action reaching the execution boundary is the action that was authorized, subject to explicit constraints, freshness, domain and policy conditions?\nThe recommended next step is validation through an application-layer prototype and adversarial testing before any consideration of an optional Superchain-compatible SDK or standard.\n1. Scope and Non-Goals\nA2SPA is an execution-time authorization model for structured execution requests. The current independent technical working draft describes deterministic cryptographic validation at the execution boundary. Its stated scope excludes natural-language prompt validation, model alignment, semantic correctness, business correctness, legality and desirability of an upstream decision.\nIn scope\n\nBinding a concrete executable payload to an authorization artifact.\nAuthenticating the authorization source under the deployment’s defined trust model.\nBinding relevant target, parameters, constraints, domain, nonce and freshness data.\nDetecting unauthorized payload mutation, stale authorization and replay where the corresponding controls are implemented and enforced.\nFail-closed verification at the designated release/execution boundary when required conditions are not met.\n\nNot claimed\n\nA guarantee that an authorized transaction is economically beneficial or semantically correct.\nProtection against every compromised signer, malicious contract, oracle failure, chain reorganization or adverse market movement.\nA replacement for smart accounts, session keys, multisig, intent systems, simulation, fraud detection, wallet controls or application policy.\nMandatory changes to the OP Stack or Superchain protocol.\n\n2. Threat Model\nThe relevant adversary is assumed capable of influencing or modifying an execution request after an upstream authorization decision, or replaying a previously authorized request, without possessing the cryptographic authority required to create a valid new authorization. The exact trust boundary must be specified by each deployment.\n\nThreat / failure mode\nA2SPA control to test\nResidual limitation / responsibility\n\nPayload mutation\nCanonical representation + signed payload binding; mismatch → reject\nOnly protects fields actually included in the signed/bound representation.\n\nWrong target / function\nBind destination, function and domain data\nDoes not make the target contract trustworthy.\n\nWrong amount / parameters\nBind relevant parameters and explicit limits\nEconomic suitability still depends on policy/state conditions.\n\nReplay\nNonce, freshness/expiry and domain binding\nNonce lifecycle and state management remain deployment responsibilities.\n\nStale authorization\nExpiry/freshness constraints\nPolicy must define what “fresh enough” means.\n\nCross-domain replay\nChain/domain/destination binding\nCross-chain systems add ordering, delay and destination-state assumptions.\n\nRevocation\nExplicit revocation/status mechanism where required\nRevocation authority and availability must be defined.\n\nUpgradeable implementation\nOptional implementation/version/policy binding\nDoes not independently establish that an upgrade is safe.\n\nPartial execution\nExplicit atomicity/completion semantics\nA2SPA cannot infer business-level completion.\n\nDynamic state\nExplicit state-dependent constraints evaluated by the relevant layer\nA2SPA does not itself determine market/business correctness.\n\nVerifier bypass\nVerifier must be on the enforced release path\nIf execution bypasses the verifier, its guarantee does not apply.\n\nIssuer compromise\nSignature proves authorization, not honesty of issuer\nKey management and policy authority remain external assumptions.\n\n3. Dynamic-State Boundary\nThe key distinction is between authorization integrity and state-dependent correctness. A transaction can reproduce the exact authorized calldata while external state has changed. A2SPA should therefore not equate an exact payload match with economic safety.\nFor state-sensitive actions such as swaps, an application can define explicit constraints where appropriate—for example minimum received amount, maximum spend, deadline, permitted venue, asset pair, oracle bound or another deterministic condition. The responsible policy/execution layer must evaluate those conditions against relevant state. A2SPA can bind the resulting authorization and enforce the execution-time match, but should not claim to independently judge economic correctness.\nExample: if an authorized swap specifies “sell no more than X and receive at least Y before deadline T on the specified venue,” an execution request violating those explicit constraints should not satisfy the authorization. If no price/slippage condition was authorized, A2SPA cannot infer one.\n4. Trust Assumptions\nA credible implementation needs a defined authorization issuer, key-management model, canonicalization/signing profile, nonce/freshness source, verifier, enforcement point and executor. Cross-chain deployments additionally require explicit assumptions about source/destination domains, message authenticity, ordering/finality and replay domains.\nThe security property is conditional: if the verifier is bypassable, the authorization authority is compromised, or the signed representation omits security-relevant execution fields, the intended guarantee does not hold.\n5. Verification Layer and Bypass Resistance\nThe prototype should test both (a) application/middleware verification immediately before release and (b) smart-account/module enforcement where the account itself rejects execution that fails authorization verification.\nThe critical requirement is not merely that a verifier exists; it must be on an enforcement path the executor cannot silently bypass. The prototype should enumerate every execution path and identify which are covered.\n6. Revocation, Expiry, Nonces and Replay\nEach authorization needs an explicit validity model: unique nonce or equivalent replay identifier, expiry/freshness condition, domain identifier, and lifecycle of consumed/invalidated authorizations. Revocation should specify its source and behavior when that source is unavailable.\nCross-chain deployments must prevent an authorization valid for one domain from being accepted unintentionally on another. Domain separation should cover the relevant chain/application/executor context according to actual protocol semantics.\n7. Upgrades and Partial Execution\nUpgradeable contracts create a separate trust problem. If an authorization assumes a particular implementation, the application may bind an implementation identifier, version, policy hash or other explicit condition. This does not establish that the implementation is safe; it prevents silent substitution from being treated as the same authorized execution when the deployment chooses to make implementation identity part of authorization.\nFor multi-step workflows, authorization must define whether it covers one atomic transaction, an ordered set of steps, or separately authorized actions. A2SPA should not infer business-level completion from a partial receipt.\n8. Comparison with Existing Controls\nThe objective is complementarity, not replacement. This comparison identifies the boundary to test; it does not claim that existing mechanisms are insufficient in every deployment.\n\nMechanism\nPrimary capability\nQuestion A2SPA tests in addition\n\nSmart-account modules\nProgrammable account-level authorization/policy\nCan the concrete payload released after policy authorization be bound to and re-verified against the authorization artifact?\n\nSession keys\nDelegated authority with scope/time/policy\nCan a specific delegated execution be bound to an exact payload and freshness/domain context?\n\nMultisig\nMultiple-party approval\nCan the exact action approved by signers be distinguished from a later/transformed execution request?\n\nIntent constraints\nDesired outcomes / execution conditions\nCan the concrete execution request be bound to the authorized conditions without conflating integrity with economic correctness?\n\nSimulation / pre-flight\nEstimate or validate likely outcome before submission\nDoes the final released action remain bound to what was authorized after intermediate processing?\n\nFraud / monitoring\nDetect suspicious behavior\nCan a deterministic cryptographic authorization check occur at the execution boundary?\n\n9. Proposed Application-Layer Prototype\nBefore proposing OP Stack-level integration, the recommended experiment is a narrow, reproducible application-layer prototype with an adversarial test suite.\nPrototype flow\n\nApplication/policy layer defines an executable action and explicit constraints.\nCanonicalizer produces a deterministic representation of security-relevant fields.\nAuthorization artifact binds payload hash, target/domain, nonce/freshness and selected constraints; issuer signs it.\nExecutor receives the executable action and authorization artifact.\nVerifier recomputes the representation and checks signature, domain, nonce/freshness and constraints.\nOnly successful verification may release execution.\nAdversarial tests mutate payload fields, replay artifacts, alter domain/chain identifiers, change deadlines/limits, modify intermediary outputs and attempt verifier bypass.\nState-sensitive tests separately demonstrate the difference between exact-payload integrity and explicit dynamic-state constraints.\n\nInitial test cases\n\nERC-20 transfer: mutate recipient and amount after authorization.\nContract call: mutate target/function/arguments.\nSwap-like action: preserve calldata while changing market state; demonstrate that payload matching alone does not assert economic correctness.\nReplay: submit the same authorization twice.\nStale execution: execute after expiry.\nCross-domain replay: submit valid authorization under a different chain/domain context.\nDelegated workflow: modify the action after an agent/intermediary produces the final request.\nVerifier bypass: attempt an alternate path that does not invoke the required verifier.\nUpgradeable target: change implementation identity where the application has chosen to bind it.\n\n10. Validation Metrics\nThe prototype should measure technical properties rather than claim ecosystem-wide security impact.\n\nVerification correctness: authorized requests accepted; modified/invalid requests rejected.\nReplay resistance under the defined nonce/domain model.\nBypass coverage across known execution paths.\nConstraint correctness for explicit limits.\nAdditional gas and latency on representative flows.\nDeterministic failure behavior and fail-closed enforcement where required.\nDeveloper integration cost and interface complexity.\n\n11. Potential Superchain Integration — Only If Validated\nIf the prototype demonstrates a distinct gap not adequately covered by existing account, session-key, multisig, intent or policy mechanisms, the least invasive Superchain path should be evaluated first.\n\nOptional SDK/reference implementation for Superchain applications.\nStandardized authorization-artifact format or interoperability profile.\nSmart-account/module adapters where applications choose execution enforcement.\nApplication/middleware adapters for transaction or intent pipelines.\nOnly later, if there is demonstrated ecosystem-wide value and a clearly defined protocol requirement, consider deeper OP Stack integration.\n\nNo mandatory OP Stack enforcement is proposed at this stage.\n12. Open Technical Questions\n\nWhat exact execution boundary is authoritative for a Superchain application?\nWhich existing smart-account, session-key, multisig or intent mechanisms already provide the proposed property, and where do they stop?\nWhich fields must be canonicalized and bound for representative transaction types?\nWhich dynamic-state conditions belong in the authorization artifact versus the application/policy layer?\nWhat is the appropriate revocation and freshness model for delayed and cross-chain execution?\nWhat cross-chain semantics must be bound to prevent unintended replay or message substitution?\nWhat verifier placement provides meaningful bypass resistance without protocol-level changes?\nWhat gas and latency overhead is acceptable?\nWhich parts, if any, merit standardization rather than remaining application-specific?\n\n13. Current Status\nA2SPA currently exists as an independent technical working draft rather than an adopted standard, IETF document, certification or security audit. The public repository identifies specification v0.9.2 and explicitly requests external review of security assumptions, canonicalization, replay/nonce/timestamp handling, deployment/bypass risks, conformance and implementation edge cases.\nThis note is therefore a technical-validation document, not a claim that the protocol has already established these security properties in production.\n14. Recommended Next Step\nBuild and test the application-layer prototype, publish the adversarial test results, and document the comparison against existing authorization mechanisms. Only after that evidence exists should a Superchain proposal be considered. If the gap is validated, an optional SDK, interoperability profile or application integration is the more proportionate first target than mandatory OP Stack enforcement.\nThe resulting proposal should define scope, deliverables, security review, maintenance responsibility, adoption targets and measurable success criteria.\nAppendix — Positioning in One Sentence\nA2SPA does not determine whether an action is safe or economically correct; it is intended to provide cryptographic evidence, at the execution boundary, that the concrete action being released is the action that was authorized under the defined authorization constraints.\nThis distinction is the central hypothesis to validate with the Optimism/Superchain community.\nSources consulted\n\nOptimism Collective: “Exploring execution-time authorization for Superchain applications” (September 24, 2026).\nOptimism Collective: “Grant Application: superchain-guard” and associated governance review (May 2026).\nOptimism Collective: “Superchain accounts: Mission updates” (2024–2025).\nAI Blockchain Ventures: A2SPA Core Protocol, independent technical working draft v0.9.2.\n\nClaims are intentionally scoped; this document does not imply Optimism endorsement.\n\n 11 days later\n\n post by Anzus_GemWallet just now\n\n Anzus_GemWallet\n\n From a user-support perspective, how would an expired authorization appear to someone using the application? It would help to distinguish “approval expired—please review and approve again” from an actual transaction failure, and make clear whether anything was submitted onchain. Is that user-facing recovery flow part of the planned prototype?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Grant Application: superchain-guard\n\n Grants Updates\n\n season-8,season-9\n\n Project Name: superchain-guard — The Security Frontier for Interoperable Intents \nApplicant: ILE Labs (ILE-Labs · GitHub) \nProgram: Season 9 Growth Grants (Infrastructure Category) \n\nExecutive Summary\nOptimism is enterin…\n\n read more\n\n 6\n\n 213\n\n May 19\n\n [FINAL] Superchain Governance Deep Dive\n\n ARCHIVED & OLD Missions\n\n season-4\n\n S4 Intent: Intent 1: Progress Towards Technical Decentralization \nProposed Mission: Deeply investigate the technical design space around decentralized Superchain governance and produce a white paper that serves as a rese…\n\n read more\n\n 37\n\n 6.4k\n\n Oct 2023\n\n Season 5 Cycle 19 Intent 1 Developer Advisory Board finalists review\n\n Grants Updates\n\n season-5,cycle-19\n\n The developer advisory board reviewed all the applications elected by the Grants Council as finalists of Intent 1 mission requests. \nYou can find their advice on each application below: \nDecentralized rollup-as-a-service …\n\n read more\n\n 2\n\n 858\n\n Apr 2024\n\n [CLOSED] Governance Fund Mission Request: Cross-Chain Key Management for Safe\n\n Governance Fund Missions\n\n season-8\n\n Season 8 Intent: A set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfer \nTotal grant amount: Up to 126,000 OP (funding 63,000 OP per team, up to 2 teams) \nShould this Governance Fund Mi…\n\n read more\n\n 11\n\n 520\n\n Nov 2025\n\n [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization\n\n Protocol Upgrade\n\n Hi Maurelian here, I’m a protocol security engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not re…\n\n read more\n\n 26\n\n 2.5k\n\n May 2024","tokens":5728,"squid":"ink-governance","role":"Council Listener","at":1791257438856,"hash":"66d34720898b2d5dc8df977d0beedad5727f0861"}
{"url":"https://docs.pyth.network/price-feeds/pro/mcp-skills","domain":"docs.pyth.network","title":"MCP Skills | Pyth Developer Hub","text":"Pyth ProMCP SkillsPre-built AI workflows for the Pyth MCP serverMCP Skills are pre-built prompt templates that teach AI assistants specific workflows using the Pyth MCP server. Instead of figuring out which tools to call and how to combine them, you can describe what you want in natural language and the skill handles the rest.\nSkills work with Claude Code and are installed alongside the MCP server. Each skill listed below includes example prompts you can try directly in your AI assistant.\nSkills require the Pyth MCP server to be configured first. Some skills also require a Pyth Pro API key.\nInstallation\nSkills are Claude Code slash commands that live in your project's .claude/skills/ directory. Each skill is a folder containing a SKILL.md file.\nPrerequisites\n\nClaude Code installed\nPyth MCP server configured (at minimum, claude mcp add pyth --transport http https://mcp.pyth.network/mcp)\n\nSetup\nClone the repositorygit clone https://github.com/pyth-network/pyth-crosschain.gitCopy skills to your projectCopy the skills directory into your project's .claude/ folder:cp -r pyth-crosschain/apps/mcp/skills/ your-project/.claude/skills/Your project structure should look like:your-project/\n└── .claude/\n └── skills/\n ├── pyth-alert-conditions/\n │ └── SKILL.md\n ├── pyth-cross-asset-comparison/\n │ └── SKILL.md\n ├── pyth-fx-converter/\n │ └── SKILL.md\n └── ... (9 skills total)Use a skillIn Claude Code, invoke any skill with a slash command:/pyth-alert-conditions Is BTC above $100k?\n/pyth-fx-converter Convert 1000 EUR to JPY\n/pyth-portfolio-tracker I hold 2 BTC and 50 ETHOr simply describe what you want — Claude Code will automatically select the appropriate skill based on your question.\nYou can also install individual skills by copying only the specific skill folders you need.\nAvailable Skills\nSkillCategoryDescriptionAPI Key RequiredPrice AlertsMarket DataOne-time price threshold and percentage change checksDepends on queryCross-Asset ComparisonMarket DataCompare performance across assets via normalizationNoVolatility AnalysisMarket DataAnnualized volatility, ATR, and risk comparisonNoFX ConverterFinancialCurrency conversion through USD cross ratesDepends on queryPortfolio TrackerFinancialPortfolio value, allocation, and P&L trackingYesFunding Rate MonitorFinancialPerpetual futures funding rates and sentimentDepends on queryData ExportData & IntegrationExport price data as CSV, JSON, or MarkdownDepends on dataTime-Series SnapshotsData & IntegrationHistorical prices at specific datesNoIntegration HelperData & IntegrationDeveloper onboarding for Pyth feeds and IDsNo\n\nMarket Data\nPrice Alerts\nEvaluates one-time price conditions — checks if prices are above or below thresholds, if assets have moved by a percentage, or if prices are near period highs or lows. These are point-in-time checks, not persistent alerts.\nHow it works: Decomposes your question into the data needed, fetches it, evaluates the condition, and answers YES or NO with supporting numbers.\nWhat you can ask:\n\n\"Is BTC above $100k?\"\n\"Has ETH dropped 5% today?\"\n\"Is gold near its weekly high?\"\n\"Has SOL changed more than 10% since June 1?\"\n\"Is the BTC bid-ask spread above $10?\"\n\nTry it:\n\n\"Is gold near its weekly high?\"\nThe assistant fetches this week's daily candles and the current price, computes the weekly high from the candle data, and tells you how close the current price is as a percentage.\n\nCross-Asset Comparison\nCompares price performance across multiple assets by normalizing OHLC data to a common baseline. Converts absolute prices to relative performance so you can compare assets at different price scales (e.g., BTC at 97kvsGoldat97k vs Gold at 2k).\nHow it works: Fetches candlestick data for each asset over the same time range, divides each close by the first close (1.0 = starting point), and computes period returns.\nWhat you can ask:\n\n\"Compare Bitcoin vs Gold this quarter\"\n\"ETH vs SOL performance over the last 30 days\"\n\"EUR/USD vs GBP/USD over the past week\"\n\"Which performed better this month: BTC, ETH, or SOL?\"\n\nTry it:\n\n\"Compare Bitcoin vs Gold this quarter\"\nThe assistant fetches daily candles for both assets, normalizes each series, and presents a side-by-side table showing that, for example, BTC returned +12.4% while Gold returned +4.2%.\n\nVolatility Analysis\nAnalyzes price volatility using candlestick data. Computes annualized volatility from close-to-close returns, average true range (ATR), and daily range metrics.\nHow it works: Fetches candlestick data, calculates daily returns, then computes standard deviation and annualizes it (using 365 days for crypto, 252 for equities/FX).\nWhat you can ask:\n\n\"How volatile is SOL?\"\n\"Compare the volatility of BTC, ETH, and AAPL\"\n\"What's the average daily range of gold?\"\n\"Is ETH more volatile than BTC?\"\n\nTry it:\n\n\"Compare the volatility of BTC, ETH, and AAPL\"\nThe assistant fetches 30 days of daily candles for each, computes annualized volatility and ATR, and presents a comparison table showing relative risk levels.\n\nFinancial Workflows\nFX Converter\nConverts currencies using Pyth FX and crypto price feeds. Supports fiat-to-fiat, crypto-to-fiat, and historical rate conversions.\nHow it works: All conversions go through USD. For cross rates (e.g., EUR to JPY), the assistant fetches both USD-based rates and computes the cross rate by dividing them.\nWhat you can ask:\n\n\"Convert 1000 EUR to JPY\"\n\"How much is 5 BTC in EUR?\"\n\"What was the GBP/JPY rate last Friday?\"\n\"Convert 500 USD to GBP\"\n\nTry it:\n\n\"Convert 1000 EUR to JPY\"\nThe assistant fetches EUR/USD and JPY/USD rates, computes the cross rate (e.g., 1.08 / 0.0067 = 161.19), and returns: 1000 EUR = 161,194 JPY.\n\nPortfolio Tracker\nTracks a portfolio of assets with current prices, allocation percentages, and P&L calculations. Supports cost-basis and date-based P&L.\nHow it works: Discovers feeds, batches all assets into a single price call (up to 100 feeds), then computes value, allocation, and optionally compares against historical reference prices.\nWhat you can ask:\n\n\"What's my portfolio worth? I hold 2 BTC, 50 ETH, and 1000 SOL\"\n\"Show gold, silver, and platinum prices\"\n\"How has my portfolio performed since last month?\"\n\"What's the allocation breakdown of my crypto holdings?\"\n\nTry it:\n\n\"What's my portfolio worth? I hold 2 BTC, 50 ETH, and 1000 SOL\"\nThe assistant fetches all three prices in one call and returns a table with each asset's value and your total portfolio value with allocation percentages.\n\nFunding Rate Monitor\nMonitors perpetual futures funding rates to gauge market sentiment. Positive rates indicate long-biased (bullish) markets, negative rates indicate short-biased (bearish) markets.\nHow it works: Discovers funding rate feeds using the funding-rate asset type, fetches current rates, and can analyze historical rate trends via candlestick data.\nWhat you can ask:\n\n\"What are the current BTC and ETH funding rates?\"\n\"Show me all funding rates sorted by magnitude\"\n\"How has the BTC funding rate changed this week?\"\n\"Which assets have the highest funding rates right now?\"\n\nTry it:\n\n\"What are the current BTC and ETH funding rates?\"\nThe assistant fetches both rates and presents them with sentiment labels — for example, BTC at +0.012% (slightly long-biased) and ETH at +0.035% (moderately long-biased).\n\nData & Integration\nData Export\nExports Pyth price data in CSV, JSON, or Markdown table format. Handles OHLC exports, feed catalog dumps, historical snapshots, and current price tables.\nHow it works: Fetches all requested data first (with pagination if needed), then formats the complete dataset. Caps exports at 1000 rows.\nWhat you can ask:\n\n\"Export BTC daily OHLC for the last 30 days as CSV\"\n\"Give me all crypto feeds as JSON\"\n\"Show current prices for BTC, ETH, and gold as a Markdown table\"\n\"Export the full feed catalog\"\n\nTry it:\n\n\"Export BTC daily OHLC for the last 30 days as CSV\"\nThe assistant fetches daily candlestick data and formats it with headers: timestamp,open,high,low,close,volume followed by one row per day.\n\nTime-Series Snapshots\nFetches price snapshots at specific historical timestamps. Generates timestamp series (monthly, weekly, quarterly) and retrieves prices for each date.\nHow it works: Generates Unix timestamps for your requested dates, then calls the historical price API once per timestamp with up to 50 feeds per call. For continuous data (more than ~20 points), suggests candlestick data instead.\nWhat you can ask:\n\n\"What was BTC at the start of each month this year?\"\n\"Show me ETH and SOL prices every Monday for the last 4 weeks\"\n\"Get quarterly gold prices since April 2025\"\n\nTry it:\n\n\"What was BTC at the start of each month this year?\"\nThe assistant generates timestamps for April 1, May 1, June 1, etc. (data starts April 2025), fetches each snapshot, and presents a table of monthly prices.\n\nIntegration Helper\nGuides developers on integrating Pyth price feeds. Explains feed discovery, symbol formats, ID types, price exponents, and data channels.\nHow it works: Understands your integration context (language, chain, use case), uses feed discovery to find specific feeds, and explains the symbol/ID/exponent/channel system.\nWhat you can ask:\n\n\"How do I use Pyth in my trading bot?\"\n\"What's the feed ID for AAPL?\"\n\"What asset types does Pyth support?\"\n\"How does Pyth Pro work?\"\n\"How do pricing channels work?\"\n\nTry it:\n\n\"What's the feed ID for AAPL?\"\nThe assistant searches for AAPL and returns the symbol (Equity.US.AAPL), the Pyth Pro numeric feed ID, and the exponent for price conversion.\nMCP ServerConnect AI assistants to Pyth market data via the Model Context ProtocolAPI ReferenceComplete API reference for all Pyth Pro services","tokens":2412,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257444431,"hash":"859b5126396e21fffe053e6e63f4c17cf2395f27"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/start-here","domain":"docs.arbitrum.io","title":"Prepare to run a node | Arbitrum Docs","text":"✏️Request an updateinfoIf you’re interested in accessing an Arbitrum chain but don’t want to set up your own node, see our Node Providers to get RPC access to fully managed nodes hosted by a third-party provider.\nThis how-to provides step-by-step instructions for preparing the information you will need to run a full node for Arbitrum on your local machine.\nPrerequisites​\nIn addition to the hardware requirements, the following prerequisites will be necessary when initially setting up your node. It is essential not to skip over these items. You would benefit by copying and pasting them into a notepad or text editor, as you will need to combine them with other commands and configuration/parameter options when you initially run your Arbitrum node.\nMinimum hardware configuration​\nThe following are the minimum hardware requirements to set up a Nitro full node (not archival):\n\nResourceMinimum requirementsRecommendedRAM (DDR5)64 GB128 GB or moreCPU8 core 3rd generation CPUs (for AWS, a i4i.2xlarge instance)16 core CPU or higher and more recent/newer generation of CPUsStorage typeNVMe SSD drives with locally attached drives strongly recommendedSameStorage sizeDepends on the chain and its traffic over time, but ideally several terabytes (TB)Same, but higher if possible\nPlease note that:\n\nThe minimum requirements for RAM and CPU listed here are recommended for nodes that handle a limited number of RPC requests. For nodes that need to process multiple simultaneous requests, both the RAM size and the number of CPU cores should be increased to accommodate higher levels of traffic.\nSingle core performance is important. If the node is falling behind and a single core is 100% busy, the recommendation is to upgrade to a faster processor.\nThe minimum storage requirements will change over time as the chain grows. Using more than the minimum requirements to run a robust full node is recommended. Note that snapshot extraction requires approximately 2x the snapshot size in temporary disk space, so plan accordingly during initial setup.\nNitro stores its state trie using either HashDB (the default) or PathDB. The choice affects which snapshot you can use, so make it before you initialize the database. Both schemes have published full node snapshots; PathDB prunes automatically but cannot validate blocks. See Choose a state scheme.\n\nParent chain (L1) client​\nYour Arbitrum node requires a connection to a parent chain RPC endpoint (e.g., an Ethereum execution client for Arbitrum One or Nova). Keep your parent chain client up to date—incompatible L1 client versions can cause your Arbitrum node to crash or fail to sync. When upgrading your L1 client, check the Nitro release notes for any noted compatibility requirements.\nRecommended Nitro version​\ncautionAlthough there are beta and release candidate versions of the Arbitrum Nitro software, use only the release version when running your node. Running beta or RC versions is not supported and might lead to unexpected behaviors and/or database corruption.\nLatest Docker image: offchainlabs/nitro-node:v3.12.1-70fa99a\nDatabase snapshots​\nSnapshots availabilityDatabase snapshots for Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia are available in the snapshot explorer.Snapshots are published per state scheme, and a snapshot only works with a node using the same scheme:Snapshot kindNode typeState schemeAvailable forprunedFull nodeHashDBArbitrum One, Nova, Sepoliafull-pathFull nodePathDBArbitrum One, Nova, SepoliaarchiveArchiveHashDBArbitrum One, Nova, Sepoliaarchive-pathArchivePathDBArbitrum One, SepoliaOnly the HashDB kinds distinguish pruned from unpruned. PathDB prunes as it runs, so every PathDB snapshot is already pruned to its state-history window—there is no separate unpruned variant to publish. The pruned kind exists because a HashDB database is pruned manually, and the published HashDB full node snapshots happen to be pruned ones.--init.latest cannot download the PathDB kinds. See PathDB snapshots.Database snapshots for other Arbitrum chains may be available at the discretion of the chain's team. Get in touch with them if you're interested in using a database snapshot for their chains.\nSupplying a database snapshot when starting your node for the first time is required for Arbitrum One (to provide information from the Classic era) but is optional for other chains. Supplying a database snapshot on the first run will provide the state and data for that chain up to a specific block, allowing the node to sync faster to the head of the chain.\nWe provide a summary of the available parameters here, but it is recommended to read the complete guide if you plan to use snapshots.\n\nUse the parameter --init.latest <snapshot type> (accepted values: archive, pruned, genesis) to instruct your node to download the corresponding snapshot from the configured URL\nOptionally, use the parameter --init.latest-base to set the base URL when searching for the latest snapshot\nNote that these parameters get ignored if a database already exists\nWhen running more than one node, it's easier to manually download the different parts of the snapshot, join them into a single archive, and host it locally for your nodes. Please see Downloading the snapshot manually for instructions on how to do that.\nOnly snapshots formatted with your node's specified state scheme are compatible. In other words, a PathDB snapshot won't work for a node using HashDB, and vice versa. Each snapshot directory publishes a metadata.json file naming its state_scheme; check it before downloading.\n\nWhich initialization mode should I use?ScenarioRecommended ParameterSetting up a new full node on HashDB--init.latest prunedSetting up a new full node on PathDBThe full-path snapshot with --init.url. --init.latest does not accept this kind.Setting up a new archive node on HashDB--init.latest archive (note: the publicly hosted archive snapshot is outdated on Arbitrum One and Sepolia)Setting up a new archive node on PathDBThe archive-path snapshot with --init.url, on Arbitrum One and Sepolia. It is smaller and more current than the HashDB archive snapshot. Nova has no archive-path snapshot.Reducing disk usage on an existing node--init.prune full (or minimal) — only applicable to HashDB; PathDB handles state trie pruning automaticallyHosting one snapshot for multiple nodesDownload manually, then use --init.url file:///path/to/archive.tar on each nodeUsing a custom snapshot URL--init.url https://your-snapshot-url/archive.tarFor more details on snapshot downloading and initialization, see the complete snapshot guide.\nFusaka upgrade: historical blobsIf you're running a beacon node, historical data will now be in blobs. To make this transition to using historical blobs, refer to the Historical Blobs for Beacon Nodes guide.\nRequired parameters​\nThe following list contains all the parameters needed to configure your node. Select the appropriate option depending on the chain you want to run your node for.\n\nArbitrum One, Nova, SepoliaArbitrum chains1. Parent chain (Ethereum) parameters​\nThe --parent-chain.connection.url parameter needs to provide a standard RPC endpoint for an Ethereum node, whether self-hosted or obtained from a node service provider:\n--parent-chain.connection.url=<Ethereum RPC URL>\nAdditionally, use the parameter --parent-chain.blob-client.beacon-url to provide a beacon chain RPC endpoint:\n--parent-chain.blob-client.beacon-url=<Ethereum beacon chain RPC URL>\nSelf-hosting the Ethereum nodeIf you self-host the Ethereum node, you need both an execution layer client and a consensus layer client. For the consensus layer, the Prysm client software is a great choice. It's straightforward, efficient, and effective—ensuring your setup runs smoothly!\nYou can also consult our list of Ethereum beacon chain RPC providers. Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. The beacon chain RPC endpoint you use may also need to provide historical blob data. Please see Special notes on ArbOS 20: Atlas support for EIP-4844 for more details.\n2. Arbitrum chain parameters​\nUse the parameter --chain.id to specify the chain you're running this node for. See RPC endpoints and providers to find the IDs of these chains.\n--chain.id=<Arbitrum chain ID>\nAlternatively, you can use the parameter --chain.name to specify the chain you're running this node for. Use arb1 for Arbitrum One, nova for Arbitrum Nova, or sepolia-rollup for Arbitrum Sepolia.\n--chain.name=<Child chain name>1. Parent chain parameters​\nThe --parent-chain.connection.url parameter needs to provide a standard RPC endpoint for an EVM node, whether self-hosted or obtained from a node service provider:\n--parent-chain.connection.url=<Parent chain RPC URL>\nAdditionally, if the chain is a Layer-2 (L2) chain on top of Ethereum and uses blobs to post calldata, use the parameter --parent-chain.blob-client.beacon-url to provide a beacon chain RPC endpoint:\n--parent-chain.blob-client.beacon-url=<Parent chain beacon chain RPC URL>\nSelf-hosting the Ethereum nodeIf you self-host the Ethereum node, you need both an execution layer client and a consensus layer client. For the consensus layer, the Prysm client software is a great choice. It's straightforward, efficient, and effective—ensuring your setup runs smoothly!\nPublic Arbitrum RPC endpointsPublic Arbitrum RPC endpoints rate-limit connections. To avoid hitting a bottleneck, you can run a local node for the parent chain or rely on third-party RPC providers.\nYou can find beacon providers in our list of Ethereum beacon chain RPC providers. Note that historical blob data is required for these chains to properly sync up if they are new or have been offline for more than 18 days. This means that the beacon chain RPC endpoint you use may also need to provide historical blob data. Please see Special notes on ArbOS 20: Atlas support for EIP-4844 for more details.\n2. Child chain parameters​\nThe parameter --chain.info-json specifies a JSON string that contains the information about the Arbitrum chain required by the node.\n--chain.info-json=<Orbit chain's info>\nThis information should be provided by the chain owner and will look something like the following:\n--chain.info-json=\"[{\\\"chain-id\\\":94692861356,\\\"parent-chain-id\\\":421614,\\\"chain-name\\\":\\\"My Arbitrum L3 Chain\\\",\\\"chain-config\\\":{\\\"chainId\\\":94692861356,\\\"homesteadBlock\\\":0,\\\"daoForkBlock\\\":null,\\\"daoForkSupport\\\":true,\\\"eip150Block\\\":0,\\\"eip150Hash\\\":\\\"0x0000000000000000000000000000000000000000000000000000000000000000\\\",\\\"eip155Block\\\":0,\\\"eip158Block\\\":0,\\\"byzantiumBlock\\\":0,\\\"constantinopleBlock\\\":0,\\\"petersburgBlock\\\":0,\\\"istanbulBlock\\\":0,\\\"muirGlacierBlock\\\":0,\\\"berlinBlock\\\":0,\\\"londonBlock\\\":0,\\\"clique\\\":{\\\"period\\\":0,\\\"epoch\\\":0},\\\"arbitrum\\\":{\\\"EnableArbOS\\\":true,\\\"AllowDebugPrecompiles\\\":false,\\\"DataAvailabilityCommittee\\\":false,\\\"InitialArbOSVersion\\\":10,\\\"InitialChainOwner\\\":\\\"0xAde4000C87923244f0e95b41f0e45aa3C02f1Bb2\\\",\\\"GenesisBlockNum\\\":0}},\\\"rollup\\\":{\\\"bridge\\\":\\\"0xde835286442c6446E36992c036EFe261AcD87F6d\\\",\\\"inbox\\\":\\\"0x0592d3861Ea929B5d108d915c36f64EE69418049\\\",\\\"sequencer-inbox\\\":\\\"0xf9d77199288f00440Ed0f494Adc0005f362c17b1\\\",\\\"rollup\\\":\\\"0xF5A42aDA664E7c2dFE9DDa4459B927261BF90E09\\\",\\\"validator-utils\\\":\\\"0xB11EB62DD2B352886A4530A9106fE427844D515f\\\",\\\"validator-wallet-creator\\\":\\\"0xEb9885B6c0e117D339F47585cC06a2765AaE2E0b\\\",\\\"deployed-at\\\":1764099}}]\"\nUse the parameter --chain.name to specify the chain you're running this node for. The name of the chain should match the name used in the JSON string used in --chain.info-json:\n--chain.name=<Orbit chain name>\n3. Parameters to connect to the sequencer​\nUse the parameter --node.feed.input.url to point at the sequencer feed endpoint, which should be provided by the chain owner.\n--node.feed.input.url=<Sequencer feed url>\nUse the parameter --execution.forwarding-target to point at the sequencer node of the Arbitrum chain, which should also be provided by the chain owner.\n--execution.forwarding-target=<Sequencer node endpoint url>\n3. Additional parameters for AnyTrust chains​\nIf you're running a node for an AnyTrust chain, you need to specify information about the Data Availability Committee (DAC) in the configuration of your node.\nFirst, enable AnyTrust data availability using the following parameters (prior to Nitro v3.10.0, these lived under the now-deprecated --node.data-availability.* namespace):\n--node.da.anytrust.enable--node.da.anytrust.rest-aggregator.enable\nThen, choose one of these methods to specify the DAS REST endpoints that your node will read the information from. These endpoints should also be provided by the chain owner.\n\nSet the DAS REST endpoints directly:\n\n--node.da.anytrust.rest-aggregator.urls=<A list of DAS REST endpoints, separated by commas>\n\nSet a URL that returns a list of the DAS REST endpoints:\n\n--node.da.anytrust.rest-aggregator.online-url-list=<A URL that returns a list of the DAS REST endpoints>\nSetting a DAS (for chain owners)If you are a chain owner, please refer to the DAC setup guide to set it up.Additionally, for your batch poster to post data to the DAS, follow Step 3 of How to configure a DAC to configure your batch poster node.\nRun a full node​\nNow that you have all the prerequisite information prepared—it's time to run your node. Follow the instructions on the Run a full node page.PrerequisitesMinimum hardware configurationParent chain (L1) clientRecommended Nitro versionDatabase snapshotsRequired parametersRun a full node","tokens":3389,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257444869,"hash":"d52c2736fb4e566d2c758d5b4c554fd009e87cfb"}
{"url":"https://gov.optimism.io/u/Anzus_GemWallet","domain":"gov.optimism.io","title":"Summary - Anzus_GemWallet - Optimism Collective","text":"Skip to profile content\n\n Anzus_GemWallet\n\n Anzus\n\n gemwallet.com\n\n Community and Growth at Gem Wallet, an open-source self-custody crypto wallet.\n\n Joined\n\n Jul 26\n\n Last Post\n\n 1 min\n\n Seen\n\n just now\n\n Views278\n Trust Levelbasic user\n\n Stats\n\n 28\n\n days visited\n\n 23m\n\n read time\n\n 21m\n\n recent read time\n\n 25\n\n topics viewed\n\n 99\n\n posts read\n\n 6\n\n given\n\n 3\n\n received\n\n 0\n\n topics created\n\n 6\n\n posts created\n\n Top Replies\n\n Aug 25\n ·\n  1\n\n [Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s)\n\n Aug 25\n ·\n  1\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n Aug 24\n ·\n  1\n\n Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\n\n 1m\n\n Exploring execution-time authorization for Superchain applications\n\n 23d\n\n Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0\n\n Sep 4\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n More Replies\n\n Top Topics\n\n No topics yet.\n\n Top Links\n\n No links yet.\n\n Most Replied To\n\n No replies yet.\n\n Most Liked By\n\n Cypherin\n\n 1\n\n ProtoArchitect\n\n Mike\n\n 1\n\n DanielJJ\n\n DanielJJ🛡️\n\n 1\n\n Most Liked\n\n Cypherin\n\n 4\n\n system\n\n system\n\n 1\n\n ProtoArchitect\n\n Mike\n\n 1\n\n Top Categories\n\n Topics\n Replies\n\n ✨ General\n\n –\n\n 2\n\n Governance Fund Missions\n\n –\n\n 2\n\n Protocol Upgrade\n\n –\n\n 1\n\n Proposals 📃\n\n –\n\n 1\n\n Top Badges\n\n Basic\n\n Granted all essential community functions\n\n New User of the Month\n\n Outstanding contributions in their first month\n\n Read Guidelines\n\n Read the community guidelines\n\n Autobiographer\n\n Filled out profile information\n\n Welcome\n\n Received a like\n\n First Like\n\n Liked a post\n\n More Badges","tokens":428,"squid":"ink-governance","role":"Council Listener","at":1791257460885,"hash":"c672d5a3ec891273e536cb58ab4aed14afd61cba"}
{"url":"https://aave.com/docs/vaults/simple-earn/data","domain":"aave.com","title":"Earn Vault Data | Aave Protocol Documentation","text":"Aave Earn Vault Data#\nRetrieve your vaults.\nVault Structure#\nAave Earn Vault data provides comprehensive information about ERC-4626 compliant yield-bearing vaults, including:\nVault identification (address, owner, share token details)Reserve information (underlying asset, yield strategy)Fee structure (performance fees, accumulated revenue, fee recipients)Vault metrics (total balance, user shares)\nIf you include a user account address while fetching vaults, the response also\nreturns user-specific data such as the vault shares owned under\nuserShares.shares and the corresponding balance in the underlying asset\nunder userShares.balance.\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core Vault type and its related types:interface Vault { address: EvmAddress; owner: EvmAddress; shareName: string; shareSymbol: string; usedReserve: Reserve; fee: PercentValue; totalFeeRevenue: TokenAmount; balance: TokenAmount; feesBalance: TokenAmount; chainId: ChainId; userShares?: UserVaultShares; feeRecipients?: RecipientPercent[];}\nFetch Vault Data#\nRetrieve detailed information about a specific vault including underlying reserve and user shares.\nThis is the most likely way you'll want to fetch vault data in your\napplication.\nReactTypeScriptGraphQLUse the useVault hook to fetch detailed information about a specific vault.const { data, loading, error } = useVault({ by: VaultRequestBy, chainId: ChainId, user: EvmAddress | undefined,});Fetch a specific vault by address.import { useVault, evmAddress, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useVault({ by: { address: evmAddress(\"0x1234567890abcdef1234567890abcdef12345678\"), }, chainId: chainId(1),});\nif (loading) { return <p>Loading vault...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\nif (!data) { return <p>Vault not found</p>;}\n// data: VaultUse a user address to include user-specific vault data.import { useVault, evmAddress, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useVault({ by: { address: evmAddress(\"0x1234567890abcdef1234567890abcdef12345678\"), }, chainId: chainId(1), user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"),});\nList Vaults#\nFetch multiple vaults with filtering and pagination support.\nReactTypeScriptGraphQLUse the useVaults hook to fetch paginated vaults.const { data, error, loading } = useVaults({ criteria: VaultsRequestFilterCriteria, pageSize: PageSize | undefined, user: EvmAddress | undefined, cursor: Cursor | undefined,});Fetch vaults owned by a specific address.import { useVaults, evmAddress, PageSize } from \"@aave/react\";\n// …\nconst { data, error, loading } = useVaults({ criteria: { ownedBy: [evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\")], }, pageSize: PageSize.TEN,});\nif (loading) { return <p>Loading…</p>;}\nif (error) { return <p>{error.message}</p>;}\n// data.items: Vault[]// data.pageInfo.next: Cursor | null// data.pageInfo.prev: Cursor | nullUse a user address to include user-specific vault data.import { useVaults, evmAddress, PageSize } from \"@aave/react\";\n// …\nconst { data, loading, error } = useVaults({ criteria: { ownedBy: [evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\")], }, pageSize: PageSize.TEN, user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"),});\nUser Vault Positions#\nTrack user vault positions and shares across Aave Earn Vaults.\nReactTypeScriptGraphQLUse the useUserVaults hook to fetch paginated vaults that a user has shares in.const { data, loading, error } = useUserVaults({ user: EvmAddress, filters: UserVaultsFilter | undefined, orderBy: UserVaultsOrderBy | undefined, pageSize: PageSize | undefined, cursor: Cursor | undefined,});Fetch user vaults ordered by shares amount.import { useUserVaults, evmAddress, PageSize, OrderDirection,} from \"@aave/react\";\n// …\nconst { data, error, loading } = useUserVaults({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), orderBy: { shares: OrderDirection.DESC }, pageSize: PageSize.FIFTY,});\nif (error) { return <p>Error: {error.message}</p>;}\nif (loading) { return <p>Loading positions...</p>;}\n// data.items: Vault[]// data.pageInfo.next: Cursor | null// data.pageInfo.prev: Cursor | null\nUser Vault Transaction History#\nTrack user vault transaction history.\nReactTypeScriptGraphQLUse the useVaultUserTransactionHistory hook to fetch a paginated user's vault transaction history.const { data, loading, error } = useVaultUserTransactionHistory({ user: EvmAddress, vault: EvmAddress, chainId: ChainId, filters: VaultUserHistoryAction | undefined, orderBy: VaultUserTransactionHistoryOrderBy | undefined, pageSize: PageSize | undefined, cursor: Cursor | undefined,});Fetch user vault transaction history ordered by date.import { useVaultUserTransactionHistory, evmAddress, PageSize, OrderDirection,} from \"@aave/react\";\n// …\nconst { data, error, loading } = useVaultUserTransactionHistory({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), vault: evmAddress(\"0x1234567890abcdef1234567890abcdef12345678\"), chainId: chainId(1), orderBy: { date: OrderDirection.DESC }, pageSize: PageSize.FIFTY,});\nif (error) { return <p>Error: {error.message}</p>;}\nif (loading) { return <p>Loading transactions...</p>;}\n// data.items: VaultUserTransactionHistoryItem[]// data.pageInfo.next: Cursor | null// data.pageInfo.prev: Cursor | null\nVault User Activity#\nReturn a user's activity for a vault, including earnings breakdowns over time.\nReactTypeScriptGraphQLUse the useVaultUserActivity hook to fetch the user's activity for a vault.const { data, loading, error } = useVaultUserActivity({ user: EvmAddress, vault: EvmAddress, chainId: ChainId, window: VaultUserActivityWindow,});Fetch user's vault activity.import { useVaultUserActivity, evmAddress, chainId, VaultUserActivityTimeWindow,} from \"@aave/react\";\n// …\nconst { data, error, loading } = useVaultUserActivity({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), vault: evmAddress(\"0x1234567890abcdef1234567890abcdef12345678\"), chainId: chainId(1), window: VaultUserActivityTimeWindow.LastWeek,});\nif (error) { return <p>Error: {error.message}</p>;}\nif (loading) { return <p>Loading transactions...</p>;}\n// data: VaultUserActivityResultPreviousDeploy Earn VaultNextEarn Vault Operations","tokens":1568,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257469962,"hash":"ac3e9f5adfee8147ed386c10e03b5c972c69174c"}
{"url":"https://ethresear.ch/t/on-increasing-the-block-gas-limit-technical-considerations-path-forward/21225/6","domain":"ethresear.ch","title":"On Increasing the Block Gas Limit: Technical Considerations & Path Forward - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Dec 2024\n\n 6 / 8\n\n Dec 2024\n\n Dec 2024\n\n post by Nero_eth on Dec 9, 2024\n\n post by MicahZoltu on Dec 9, 2024\n\n post by benaadams on Dec 9, 2024\n\n post by storm on Dec 9, 2024\n\n storm\n\n image1592×931 71.6 KB\n(from here)\nstorage size is less of a bottleneck than bandwidth or storage IO. state is relatively small. and history is growing at a smaller rate post 4844 (graph is outdated). full-4444 would still be extremely beneficial but the pre-merge-4444 in pectra will still give a huge amount of runway\nfrom the perspective of hardware constraints, 36M seems like a non issue. delay 60M until post pectra. I think Toni’s analysis is spot on here\n\n post by markodayan on Dec 9, 2024\n\n markodayan\n\n Of all the activity we need to analyze to be a bit more proactive about these decisions, do you think the findings around propagation behavior will always be the most urgent thing to be sure of compared to the other effects? Seems like its largely the burst factor that threatens consensus stability (at least according to the current thresholds), other stuff seems more like long-term sustained effects.\nWould also be keen to know what exactly is the agreed upon way to profile block propagation. Would it be similar to something like done done in this paper (Page 4): [2405.03183] Impact of EIP-4844 on Ethereum: Consensus Security, Ethereum Usage, Rollup Transaction Dynamics, and Blob Gas Fee Markets\n\n post by MicahZoltu on Dec 9, 2024\n\n MicahZoltu\n\nDropping ancient history is definitely a positive step, though it comes with downsides like a range of applications ceasing to work in a decentralized way because they depend on ancient historic events (I mostly blame the apps for this design, not the clients for dropping receipt history).\n\nI am of the opinion that we are already way over reasonable state requirements for end-users, and small gains like dropping pre-merge history just help mitigate some of the damage we have already done. Part of the problem here is that there is no consensus on what the target end-user machine looks like, and there isn’t even consensus (sadly) that end-users should be able to run an Ethereum client at all.\nThe first step to making informed decisions on this topic is to come to an agreement (among who?) about what the target demographic is for running trustless RPC clients. Once we have that we can have more interesting discussions around whether a given change will cause us to exceed that target or not.\n\n post by arnetheduck on Dec 12, 2024\n\n arnetheduck\n\n Here’s some more background information on the technical aspects of the limit:\nGOSSIP_MAX_SIZE is the relevant constant and is currently set to 10MB for the uncompressed payload of the block message.\nThe contents of this payload is an SSZ-encoded consensus message. The consensus message has information about consensus matters and also carries the execution payload, which is the the part of the message received from the execution layer. All fields in the consensus layer have fixed bounds on how much space they can possibly use - in Deneb, this “consensus overhead” amounts to 357288 bytes.\nThe execution payload is made up of several fields, all of which have constant upper bounds on their length except for the transactions (in the consensus layer, we have a theoretical limit of 1024TB of transaction data, for the curious). The constant-size portion of the execution payload is another 1264 bytes.\nAs such, we can reframe the problem of a maximum gossip size effectively as a limit on the size of the transactions that we can fit in a block - 10127208 bytes.\nThe advantage of framing it as a limit on transactions is that this field is entirely controlled by the block producer and / or execution clients - they know, as they are constructing the block, what size transactions have and what the sum of the transaction sizes are.\nEdit: fixed sizes, thanks @tbenr for crosschecking with Teku!\n\n post by arnetheduck on Dec 18, 2024\n\n arnetheduck\n\n There is now an issue open that describes some of the long-term solutions to this conundrum.\n\n Powered by Discourse","tokens":1048,"squid":"ink-research","role":"Deep Scholar","at":1791257473151,"hash":"e0d5212bd9b12d6832dc7847e1ffd9f9fc828962"}
{"url":"https://aave.com/docs/vaults/stable-vaults/yield-strategies","domain":"aave.com","title":"ERC-4626 Yield Strategies | Aave Protocol Documentation","text":"ERC-4626 Yield Strategies#\nThe Allocator routes assets into approved ERC-4626 strategies. Each strategy is a vault interface to an underlying yield source and is added or removed by the integrator. The Allocator may also hold assets that have no assigned strategy when a suitable strategy does not exist for a given asset or chain.\nAave V4 Markets#\nAssets are supplied to Aave v4 lending markets through an ERC-4626 adapter that wraps Aave v4 pool positions. The adapter exposes the standard vault interface while managing the underlying supply and withdrawal calls to the Aave v4 pool.\nAave V3 Markets#\nAssets are supplied to Aave v3 lending markets using an extended AToken vault adapter. The extension adds support for claiming Merkl rewards, which is required because a significant portion of the yield from supplying certain assets to Aave v3 markets comes from off-chain reward distributions rather than on-chain lending interest alone.\nSavings GHO Vault#\nGHO can be deposited into the sGHO savings vault, which accrues yield through the GHO Savings Rate mechanism. This strategy is available on chains where sGHO is deployed.\nGeneric ERC-4626 Vault#\nAny ERC-4626 compliant vault approved by the integrator and added to the Allocator's whitelist can serve as a strategy. This design allows the system to adopt new yield sources without protocol changes, as long as the strategy conforms to the standard vault interface and the other requirements of the Allocator contract.\nRequest IntegrationPreviousArchitecture","tokens":380,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257479890,"hash":"fd1d5fa89e6188a73a19b9b5052a9ec18c8496e4"}
{"url":"https://io.net/docs/guides/clouds/start-using-io-cloud","domain":"io.net","title":"Overview - io.net","text":"​Introduction\nIO Cloud enables the deployment and management of on-demand, decentralized GPU clusters, giving users access to powerful GPU resources without significant hardware investments or the complexity of managing infrastructure. IO Cloud democratizes GPU access by leveraging a decentralized model, providing machine learning engineers and developers with the same seamless experience as traditional cloud providers.\nThe platform utilizes a distributed network of nodes, IO workers, to offer flexible, scalable compute resources. IO Cloud clusters are self-healing, fully meshed GPU systems that ensure high availability and fault tolerance. With IO Cloud, you can tap into a decentralized network of GPUs and CPUs capable of running Python-based machine learning workloads. It is ideal for AI projects requiring distributed compute. The platform is natively built on the Ray framework, the same distributed computing technology used by OpenAI to train models like GPT-3 and GPT-4 across hundreds of thousands of servers.\n\n​IO Clouds Integration Flow\nThe diagram below provides a high-level overview of how users integrate with IO Cloud - from choosing a compute resource to launching AI workloads. It illustrates the end-to-end flow across key components, including cluster selection, container deployment, and runtime execution.\n\n​Create Account\nTo create an account, go to cloud.io.net using Google, Apple ID, GitHub, Hugging Face, X, Worldcoin, or simply with a one-time password by clicking the “Login with Email” button.\n\n​Payments\nIO Cloud simplifies the process of paying for GPU clusters by offering two convenient payment methods:\n\nSolana: This cryptocurrency option enables fast, secure transactions. You can configure a Solana wallet either during account creation or through your Account Settings. Once configured, you can fund your wallet or proceed with payment for your GPU cluster.\nCredit Cards: We accept all major credit cards, providing a straightforward payment solution.\n\nTo learn more about payment options, visit our IO Cloud Payments page.\n​App Guide\nThe home page offers the following options:\nActionDefinitionDeploy a ClusterCreate a new cluster for your workloads.Browse the GPU MarketplaceExplore and select GPUs for your clusters.Add Funds to Your BalanceTop up your account for cluster usage.View and Monitor Your ClustersTrack the status and performance of your existing clusters.\n​Clusters\nio.net offers three distinct cluster types to power your AI projects:\n\n​VM on Demand\nProvision dedicated bare-metal machines instantly, giving you complete control over the hardware for performance-critical workloads.\n\nDirect Hardware Access: Run workloads directly on physical machines with no virtualization layer.\nMaximum Performance: Eliminate virtualization overhead for speed, isolation, and reliability.\nFlexible Setup: Select your preferred processor and location, then deploy in minutes.\n\nTo view detailed instructions, see Deploy VM on Demand Cluster.\n​Container-as-a-Service (CaaS)\nAllows you to configure and deploy containers on powerful GPU-backed infrastructure through a simple, guided interface.\n\nStep-by-Step Wizard: Set image, command, ports, environment variables, and more.\nCluster & Location Choice: Select from available GPUs and regions that meet your needs.\nScalable & Fast: Built for AI and compute-heavy workloads with rapid setup.\n\nTo view detailed instructions, see Deploy Container.\n​Bare Metal on Demand\nGives you full access to physical hardware without any virtualization layer — ideal for low-level control and maximum performance.\n\n**Direct-to-Hardware Access: **Run workloads directly on machines for optimal speed and isolation.\n**No Virtualization Overhead: **Perfect for users with specialized or custom environments.\n**Custom Configuration: **Choose your processor and location, then deploy instantly.\n\nTo view detailed instructions, see Managed Services.\n​Clusters Tabs\nThe Cluster tabs provide a central hub for managing your deployed clusters. Each tab displays a list of clusters, categorized by type, with details such as:\n\nName: The unique identifier for the cluster.\nAccelerator (GPU): The type of GPU used in the cluster.\nStatus: The current state of the cluster (e.g., running, stopped, pending).\nRemaining Compute Hours: The remaining time on your cluster’s billing cycle.\n\nFrom here, you can perform actions like:\n\nRename: Change the name of a cluster.\nExtend: Increase the duration of your cluster’s billing cycle.\nTerminate: Stop and delete a cluster.\n\nEach cluster tab also provides quick access to essential management tools:\n\nVisual Studio: An integrated code editing and debugging development environment.\nJupyter Notebook: An interactive environment for data analysis and visualization.\nRay Dash: A dashboard for monitoring and managing distributed applications.\n\nFor a detailed explanation of monitoring and managing your clusters, see Monitor and Manage Clusters.\nWas this page helpful?","tokens":1244,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257481320,"hash":"cd5e8311c3a8ca85e7dd3118d81142ea6006282b"}
{"url":"https://ethresear.ch/t/on-increasing-the-block-gas-limit-technical-considerations-path-forward/21225","domain":"ethresear.ch","title":"On Increasing the Block Gas Limit: Technical Considerations & Path Forward - Execution Layer Research - Ethereum Research","text":"On Increasing the Block Gas Limit: Technical Considerations & Path Forward \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Dec 2024\n\n 1 / 8\n\n Dec 2024\n\n Dec 2024\n\n post by Nero_eth on Dec 9, 2024\n\n Nero_eth\n\n On Increasing the Block Gas Limit: Technical Considerations & Path Forward\nAuthored by: Toni, Marek, Pari, Jacek, Paul, Tim and Alex.\nAuthors’ Note:\nThe core development community is committed to continuous improvement of the network’s scalability and user experience. With recent community-driven initiatives, such as pumpthegas.org, there has been a growing call to increase Ethereum’s block gas limit with some proposals approaching 60 million. While this enthusiasm reflects the shared goal of expanding Ethereum’s capacity, it is important to proceed deliberately and in harmony with the technical realities of the protocol and its clients. Before encouraging the community to actively signal for limits beyond 36 million, we may want to deepen our understanding of the potential consequences—conducting more analysis, collecting empirical data, and examining results of upcoming protocol changes in the greatest detail possible—so that adjustments are made with both confidence and caution.\n\nContext\nThe consensus-layer (CL) clients currently implement certain constraints, as specified by the formal specifications. These constraints include a maximum acceptable uncompressed block size for gossip propagation, currently set to 10 MiB. In practice, this indirectly influences the maximum feasible block gas limit. Today, raising the gas limit to 60 million gas, as proposed by some community members, would generate blocks that exceed this gossip constraint—leading to missed slots and overall network instability.\nUntil these client-level assumptions can be revisited and improved, the network should move forward with caution when considering increases beyond certain thresholds.\n\nRationale for Limits (Security Considerations):\nThese constraints are not arbitrary; they are in place to safeguard the network. Extremely large blocks can facilitate potential DoS vectors by forcing nodes to handle unwieldy amounts of data. Without practical use cases for such large blocks—and with the risk of malicious actors exploiting them—the core developers have designed limits to mitigate negative effects and protect the network’s health.\n\nWhat This Means in Practice\n\nFunctionality up to ~40M gas:\nBlocks at or below this level remain within the acceptable size range, allowing clients to propagate them and maintain consensus stability. This ensures that validators do not see unexpected missed slots due to overly large blocks which would be prevented from being propagated because of gossip limits.\n\nBeyond ~40M gas:\nValid blocks larger than 10 MiB could fail to propagate as expected. This results in some validators missing their slots despite producing otherwise valid blocks. The gossip limits, which cannot be easily circumvented today, create a bottleneck. In addition, without further empirical data, the initial analyses guiding the blob count increases may not fully reflect the increased complexities of operating under a significantly higher gas limit.\n\nWhy Wait for Pectra?\nThe core developers have been planning the Pectra network upgrade that reduces worst-case block sizes and create the headroom needed to safely increase capacity. Two notable upcoming changes are:\n\nEIP-7623 (Included in Pectra):\nThis proposal aims to reduce worst-case block sizes. By increasing the cost of calldata for calldata-heavy transactions, it opens pathways to safely handle more capacity—be that additional blobs or a higher gas limit. Reducing worst-case scenarios mitigates potential DoS vectors and helps ensure that the network remains stable and resilient under heavier loads.\n\nEIP-7691 (Included in Pectra):\nThis proposal will increase the target/maximum number of blobs per block from 4/6 to 6/9. By observing the network’s performance under increased blob counts, we can gather data on propagation behavior, storage demands, and client resource usage. This empirical evidence will guide safer adjustments in block composition and size.\n\nBy first deploying the Pectra hardfork and analyzing the outcomes of EIP-7623 and EIP-7691 in a production environment, we stand to gain critical empirical evidence. This data will inform both core developers and the broader Ethereum community on how the network responds to changes in block composition and size. Armed with this understanding, the community can make more informed decisions on how to increase the gas limit while maintaining Ethereum’s robustness and security.\nFuture upgrades, such as PeerDAS, will build on these insights, further refining parameters and scaling capabilities as the network evolves.\n\nA Call for Patience and Collaboration\nThe Ethereum community’s proactive approach and passion for scaling solutions is commendable. Core developers are keenly aware of this momentum and, in general, are supportive of finding a responsible path to increasing the gas limit. However, moving too quickly—especially beyond 36M gas—risks unintended consequences and network instability.\nWe encourage all stakeholders—users, validators, researchers, and client developers—to remain patient and work together through this transition.\nBy deferring significant capacity increases until after the Pectra hardfork, monitoring the real-world effects of EIP-7623 and EIP-7691, and carefully reviewing the results, we can ensure that these increases are implemented responsibly and sustainably.\nWhile many sympathize with the desire to see Ethereum’s gas limit significantly increase over a short period, a more incremental approach might be sounder. For instance, starting with a moderate increase to around 36M gas would allow us to carefully monitor the network’s response, assess client performance, and ensure that no unforeseen issues arise. If the data supports further increases, we could then proceed more confidently to higher limits while maintaining the network’s stability and security.\nFinally, we may also anticipate further updates and guidance from core developers in the coming days/weeks as they work towards resolving these issues.\n\nIn Summary\n\nThe current CL client constraints make immediately raising the gas limit to 60M gas impractical due to block size and gossip propagation issues.\nIncreasing the gas limit beyond 36M requires careful, data-driven planning and consideration of DoS resilience.\nThe upcoming Pectra hardfork, which includes EIP-7623 and EIP-7691, will provide the groundwork and data needed for safe throughput increases.\nCore developers support scaling the network, but emphasize a measured, evidence-based approach. This is in alignment with the motivation of the pumpthegas.org.\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by MicahZoltu on Dec 9, 2024\n\n post by benaadams on Dec 9, 2024\n\n post by storm on Dec 9, 2024\n\n post by markodayan on Dec 9, 2024\n\n post by MicahZoltu on Dec 9, 2024\n\n post by arnetheduck on Dec 12, 2024\n\n post by arnetheduck on Dec 18, 2024\n\n Powered by Discourse","tokens":1788,"squid":"ink-research","role":"Deep Scholar","at":1791257483684,"hash":"08edd5b4244abba725656bdeeaba9e61f6b2c5fc"}
{"url":"https://aave.com/docs/aave-v4/getting-started/typescript","domain":"aave.com","title":"AaveKit TypeScript v4 | Aave Protocol Documentation","text":"TypeScript#\nGet started with AaveKit TypeScript\n\nAaveKit TypeScript for Aave v4 provides a type-safe, low-level API client for interacting with Aave Protocol v4. It offers a lightweight abstraction over the GraphQL API and is ideal for server-to-server communication.\nBuilt with a modular, functional approach inspired by the viem client-actions architecture, the SDK structures functionality into distinct, reusable actions focused on specific protocol features like lending, borrowing, and data retrieval.\nGetting Started#\nTo get started, follow the steps below.\n1Install SDK#First, install the @aave/client package using your package manager of choice.npm install @aave/client@next2Create an AaveClient#Then, create an AaveClient instance that will be used to interact with the protocol.import { AaveClient } from \"@aave/client\";\nexport const client = AaveClient.create();3Start Building#That's it—you can now start using the @aave/client/actions to interact with the Aave Protocol. Here's a basic example to query supported chains:import { AaveClient, ChainsFilter } from \"@aave/client\";import { chains } from \"@aave/client/actions\";\nimport { client } from \"./client.ts\";\n// Fetch all chains supported by Aaveconst result = await chains(client, { query: { filter: ChainsFilter.ALL },});\nif (result.isOk()) { console.log(\"Chains:\", result.value);} else { console.error(\"Error:\", result.error);}\nServer-Side Rendering#\nAaveClient supports SSR hand-off through the ssr option. Create a server-side client, run your queries, serialize client.extractData(), then hydrate a browser client with that snapshot.\nimport { AaveClient, type SSRData, ChainsFilter } from \"@aave/client\";import { chains } from \"@aave/client/actions\";\nconst client = AaveClient.create({ ssr: { isServer: true },});\nconst result = await chains(client, { query: { filter: ChainsFilter.ALL },});\nconst initialState: SSRData = client.extractData();\nIf the snapshot arrives after the client is created, call client.restoreData(initialState) to hydrate the cache later.\nDisplay Configuration#\nThe optional display config transforms how assets are presented across queries. Transforms are applied after the cache, so the cache always stores untransformed data.\nimport { AaveClient } from \"@aave/client\";\nexport const client = AaveClient.create({ display: { // Show wrapped native tokens (e.g. WETH) as the native asset (e.g. ETH) showWrappedNativeReserveAsNative: true, // Per-asset overrides, keyed by chain ID and address assetOverrides: [ { chainId: 1, address: \"0xAeBf0Bb9f57E89260d57f31AF34eB58657d96Ce0\", display: { name: \"PT USDe (May 2026)\", symbol: \"PT USDe\", icon: \"https://…\" }, }, ], },});\nshowWrappedNativeReserveAsNative — when true, wrapped native tokens are shown using the native asset's name, symbol, and icon within reserve contexts (Reserve, HubAsset, Asset). Wallet balance, reward payout, and swap queries are unaffected. The underlying isWrappedNativeToken flag and token address are preserved.assetOverrides — per-asset display overrides applied globally across all queries, keyed by chainId and address. Each entry takes a display object with optional name, symbol, and icon.\nIf both settings target the same token, assetOverrides takes precedence.\nResult Objects#\nAaveKit uses a functional approach to error handling, it's based on Result<T, E> that represents one of two states:\nOk<T>: A successful result containing a value of type TErr<E>: A failure containing an error of type E\nimport { ok, err, Result } from \"@aave/client\";\nfunction parseId(s: string): Result<number, Error> { if (/^\\d+$/.test(s)) { return ok(Number(s)); } return err(new Error(\"ID must be a number\"));}\nWith a Result<T, E>, you can use the convenient isOk() and isErr() methods to check the outcome and narrow the type.\nconst result: Result<number, Error> = parseId(\"123\");\nif (result.isOk()) { console.log(result.value); // 123} else { console.error(result.error); // Error}\nThis approach avoids reliance on try/catch blocks and promotes predictable, type-safe code by ensuring errors are handled explicitly.\nAaveKit uses the NeverThrow\nlibrary as underlying implementation for the Result object.\nResultAsync<T, E> is the async, thenable variant of Result<T, E>. Awaiting it resolves to a Result<T, E>.\nimport { ResultAsync } from \"@aave/client\";\nfunction fetchUser(id: number): ResultAsync<{ name: string }, Error> { return ResultAsync.fromPromise( fetch(`/api/users/${id}`).then((r) => r.json()), () => new Error(\"Not found\"), );}\nconst result = await fetchUser(1);\nif (result.isOk()) { console.log(result.value); // { name: \"John\" }} else { console.error(result.error); // Error}\nResult objects can be chained:\nfunction divide(a: number, b: number): Result<number, string> { return b === 0 ? err(\"Division by zero\") : ok(a / b);}\nconst result = parseNumber(\"42\").andThen((num) => divide(num, 2));\nif (result.isOk()) { console.log(\"Result:\", result.value);} else { console.error(\"Error:\", result.error);}\nYou can also provide a default value if the result is an error:\nconst value = parseNumber(\"invalid\").unwrapOr(0); // 0\nNeverThrow also provides a ResultAsync type for handling asynchronous operations. This is a thenable object that can be awaited, and/or chained with other operations:\nconst result = await ResultAsync.fromPromise( fetch(\"https://api.example.com/data\"),) .map((response) => response.json()) .mapErr((error) => `Failed to fetch data: ${error}`);\nif (result.isOk()) { console.log(\"Data:\", result.value);} else { console.error(\"Error:\", result.error);}\nSee the NeverThrow documentation for more information.\nIntegrations#\nAaveKit TypeScript includes first-class support for viem, ethers v6, Privy, thirdweb and Turnkey wallets.\nViemEthersPrivythirdwebTurnkeyEnsure you have viem package installed in your project.npm install viem@2\nSend Aave Transactions#\nAmong the actions provided by AaveKit TypeScript, some are specifically designed to handle protocol interactions such as supplying, borrowing, withdrawing, repaying, and more.\nThere are two main types of transaction actions:\nSimple transactions – single-step transactions that can be sent directly to the wallet.Complex transactions – transactions that may require prior approvals before they can be executed.\nTo send transactions, follow the steps below.\n1Import the Helper#First, import the sendWith helper function for the wallet library of your choice.ViemEthersPrivythirdwebTurnkeyImport the sendWith helper from the @aave/client/viem entry point.import { sendWith } from \"@aave/client/viem\";2Send the Transaction#Then, use the sendWith helper to send the transaction.To demonstrate how this helper works, assume we have a transaction action named foobar.import { foobar } from \"@aave/client/actions\";import { client } from \"./client\";\nconst result = foobar(client);To send the transaction, chain the action with sendWith for your wallet library, then use client.waitForTransaction to wait until it's confirmed and indexed by AaveKit API.import { foobar } from \"@aave/client/actions\";import { sendWith } from \"@aave/client/viem\";import { createWalletClient, http } from \"viem\";import { privateKeyToAccount } from \"viem/accounts\";\nimport { client } from \"./client\";\nconst wallet = createWalletClient({ account: privateKeyToAccount(\"<PRIVATE_KEY>\"), transport: http(),});\nconst result = foobar(client) .andThen(sendWith(wallet)) .andThen(client.waitForTransaction);3Handle the Result#Finally, handle the result of the operation.if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": // Most likely the user rejected the transaction console.error(`Failed to sign the transaction: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"ValidationError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return;} else { console.log(result.value.txHash); // TxHash}That'it—you've sent the transaction.\nSign Typed Data#\nSome Aave operations require EIP-712 typed data signatures for the following:\nERC-20 Permits: Authorize exact amount transfers without separate approval transactionsSwap Intents: Sign swap orders for intent-based swaps\nPermits are available for ERC-20 tokens that implement\nEIP-2612.\nViemEthersPrivythirdwebImport the signTypedDataWith or permitWith helpers from the @aave/client/viem entry point.import { signTypedDataWith, permitWith } from \"@aave/client/viem\";\nThen, use them as described in the specific operation guide.","tokens":2214,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257489956,"hash":"1514908552418af52d195395f69124c2a46f6c3e"}
{"url":"https://io.net/docs/guides/clouds/agent-cloud","domain":"io.net","title":"Agent Cloud - io.net","text":"​What is Agent Cloud?\nThe Agent Cloud is a Model Context Protocol (MCP) server which allows any MCP-compatible AI agent (Claude Code, Cursor, Windsurf, etc.) to interact directly with io.net APIs. Instead of manual dashboard management, you can now manage your decentralized infrastructure through natural language.\n​Why Connect to Agent Cloud?\n\nAgentic DevOps: Ask your agent to “Find the cheapest 4x H100 cluster and deploy my PyTorch image,” and let it handle the API calls.\nPlug-and-Play: No custom SDKs to install. Use the universal MCP standard to bridge your AI tools to the large GPU cloud.\nEnterprise Ready: Supports both simple API key headers for individuals and dynamic key forwarding for multi-tenant applications.\nx402 Payments: When credits run short, a deploy returns an x402 payment request your agent can settle in USDC and retry, with no trip back to the dashboard.\n\n​Quickstart: Connect to the IO Cloud\nYou can link your AI agent to our hosted MCP server in seconds.\n​1. Link Your Agent (Claude Code Example)\nReplace <YOUR_IO_NET_API_KEY> with your personal key from the io.net dashboard with io-cloud project scopes:\nclaude mcp add io-cloud https://mcp.io.solutions/mcp \\\n --transport http \\\n --header \"x-api-key: <YOUR_IO_NET_API_KEY>\" \\\n --scope project\n\n​2. Verify Connection\nOnce added, restart your agent and try these prompts:\n\n“What io-cloud tools are available to me?”\n“List all active container deployments in my account.”\n“Find available NVIDIA H100 hardware specs.”\n\n​Desktop Agent Configuration\nIf you prefer using GUI-based agents, copy and paste the configurations below. Replace <YOUR_IO_NET_API_KEY> with your actual key with io-cloud project scopes.\n​Claude Desktop\nAdd this to your claude_desktop_config.json (found in %AppData%\\Claude on Windows or ~/Library/Application Support/Claude on macOS):\n{\n \"mcpServers\": {\n \"io-cloud\": {\n \"type\": \"http\",\n \"url\": \"https://mcp.io.solutions/mcp\",\n \"headers\": {\n \"x-api-key\": \"<YOUR_IO_NET_API_KEY>\"\n }\n }\n }\n}\n\n​Cursor & Windsurf\n\nOpen Settings > Features > MCP.\nClick + Add New MCP Server.\nName: io-cloud\nType: command (or http if supported).\nURL: https://mcp.io.solutions/mcp\nHeader: x-api-key: <YOUR_IO_NET_API_KEY>\n\n​Capabilities & Documentation\n​Available MCP Tools\nTool GroupCapabilityPurposeCaaScaas_get_hardware_idsBrowse the deployable container hardware catalog.CaaScaas_get_max_gpus_per_containerMax GPU count allowed in a single container.CaaScaas_get_available_replicasReplicas available for a hardware ID and quantity.CaaScaas_get_price_estimateCost of a configuration before you deploy it.CaaScaas_deploy_containerInstant provisioning of new compute resources.CaaScaas_list_deploymentsReal-time status of your container clusters.CaaScaas_get_deploymentDetails of a single deployment.CaaScaas_get_deployment_containersContainers running inside a deployment.CaaScaas_update_deploymentChange an existing deployment.CaaScaas_extend_deployment_durationAdd runtime to a duration-billed deployment.CaaScaas_destroy_deploymentTerminate a deployment and stop billing.VMaaSvmaas_get_hardware_listBrowsing available GPU/CPU configurations.VMaaSvmaas_deploy_vmProvision a VM cluster.VMaaSvmaas_list_deploymentsReal-time status of your VM clusters.VMaaSvmaas_get_deploymentDetails of a single VM deployment.VMaaSvmaas_get_deployment_vmsVMs running inside a deployment.VMaaSvmaas_extend_cluster_durationAdd runtime to a duration-billed VM cluster.VMaaSvmaas_destroy_deploymentTerminate a VM cluster and stop billing.Accountget_credit_statusCheck credit balances, PayG hourly burn rate, and estimated runway when available.\nFor duration billing, the recommended flow is: pick hardware from the catalog, estimate the price, deploy, then manage. caas_get_price_estimate returns a duration-based price; it does not predict the hourly PayG charge of a new deployment.\nBoth deploy tools default to billing_model: \"duration\". Set billing_model: \"payg\" on the deploy request for ongoing billing. The API currently requires duration_hours for PayG requests, but it does not limit the deployment’s lifetime. Only duration-billed deployments can use the extend tools; destroy a PayG deployment to stop billing.\nUse get_credit_status to check your balance and current PayG burn rate. Estimated runway can change with GPU prices.\n​Working with Hardware IDs\nThe catalog returns two kinds of hardware. Regional hardware uses string IDs and reports a location (for example gpu_1x_a6000 in US, or H100_sxm5x8 in CA); network hardware uses integer IDs with a null location.\nWhat you can pass back depends on the service. vmaas_deploy_vm and caas_get_price_estimate accept either form, so pass the ID exactly as the catalog returned it and do not coerce a string ID to an integer. caas_deploy_container and caas_get_available_replicas currently accept integer IDs only, so pick a network hardware entry for those calls.\nEvery deploy needs a placement, so location_ids is not optional in practice: pass exactly one location, or a node_pool_id for a private node pool. Passing both is rejected, and so is passing neither. Only one location per deployment is supported today. caas_get_price_estimate requires location_ids as well. VMaaS accepts country codes such as [\"US\"]; caas_deploy_container currently takes integer location IDs through this server.\nduration_hours on caas_extend_deployment_duration and vmaas_extend_cluster_duration is additive: it adds N hours to the time remaining, it does not set the new total. To reach a target total, subtract the current remaining hours yourself.\n​Topping Up Credits with x402\nWhen a deploy or extend is short on credits, IO Cloud answers with x402, the HTTP 402 payment protocol, so your agent can settle the bill and continue without a human opening the dashboard. This handles a shortfall during a request; Agent Cloud does not currently offer a standalone MCP tool to add credits proactively while PayG deployments are running.\nThe four tools that spend credits (caas_deploy_container, caas_extend_deployment_duration, vmaas_deploy_vm, vmaas_extend_cluster_duration) return status: \"payment_required\" instead of an error. This is a bill to pay and then retry, not a failure.\nUnder payment you get a standard x402 envelope: x402Version: 2, an accepts array whose first entry uses the exact scheme, and an io_net object with the amounts in USD. Any x402-capable client can read it. Today the quote is payable in USDC on Solana, but take the chain and token from accepts[0].network and accepts[0].asset rather than assuming:\n\nPay the exact maxAmountRequired of the given asset, to the exact payTo address, on the stated network. maxAmountRequired is in the asset’s atomic units, so \"3820000\" means 3.82 USDC.\nAlways take payTo from the response you are acting on. Never send to an address cached from an earlier call. A plain transfer with no memo matches correctly.\nSend the full amount in a single transfer. An underfunded intent is held without applying any credits until the full amount arrives.\nTop-ups have a $1.00 minimum, so a shortfall under a dollar still requires a $1 payment.\n\nio_net.shortfall_usd is the gap between the request’s cost and your balance. io_net.quote_usd is what the top-up actually costs, which is the shortfall grossed up for the payment provider’s fee and floored at the minimum. Pay quote_usd, not shortfall_usd. Anything the top-up leaves over stays on your account as IO Credits.\n​Authentication Methods\n\nStatic Header (Recommended for Individuals): Include your API key with io-cloud project scopes in the x-api-key HTTP header during setup.\nDynamic Forwarding (For Multi-User Apps): Pass the key dynamically within the auth.api_key argument of any specific tool call.\n\n​Programmatic Usage (Python Example)\nIf you are building a custom integration, you can use the mcp Python SDK to interact with the IO Cloud server.\nimport asyncio\nfrom mcp import ClientSession\nfrom mcp.client.streamable_http import streamablehttp_client\n\nasync def io_cloud_demo():\n # 1. Initialize the HTTP Client\n async with streamablehttp_client(\"https://mcp.io.solutions/mcp\") as (read_stream, write_stream, _):\n async with ClientSession(read_stream, write_stream) as session:\n await session.initialize()\n\n # 2. List available hardware via tool call\n # Note: We pass the API key dynamically here (Mode A)\n result = await session.call_tool(\n \"vmaas_get_hardware_list\", \n arguments={\n \"auth\": {\"api_key\": \"YOUR_IO_NET_API_KEY\"},\n \"gpu\": \"H100\"\n }\n )\n print(f\"Available H100s: {result}\")\n\nif __name__ == \"__main__\":\n asyncio.run(io_cloud_demo())\n\n​Troubleshooting\n\nAuthentication Failure (401/403): Verify your API key in the io.net dashboard.\n“No API key provided”: Ensure the header is correctly set in your JSON config or passed in the tool arguments.\nConnection Timeout: Verify your network allows outbound traffic to https://mcp.io.solutions.\nstatus: \"payment_required\": Your account is short on credits. Settle the x402 quote in the response, then retry the call.\nEmpty hardware list: Filters match the catalog’s own values. Use gpu: \"H100\", not gpu: \"NVIDIA H100\".\n\nReady to scale your infrastructure? For high-volume requirements or custom integration support, contact us at support@io.netWas this page helpful?","tokens":2309,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257495066,"hash":"c4ba010f6459f584332f71c604d380c265a3a095"}
{"url":"https://ethresear.ch/u/nero_eth","domain":"ethresear.ch","title":"Summary - Nero_eth - Ethereum Research","text":"Skip to profile content\n\n Nero_eth\n Toni Wahrstätter is a moderator\n\n Toni Wahrstätter\n\n website:\n\n toniwahrstaetter.com\n\n github:\n\n Nerolation\n\n Joined\n\n Jul 29, 2022\n\n Last Post\n\n Sep 8\n\n Seen\n\n 9 hours\n\n Views7768\n Trust Levelmember\n\n Stats\n\n 1.3k\n\n days visited\n\n 3d\n\n read time\n\n 1h\n\n recent read time\n\n 654\n\n topics viewed\n\n 3.0k\n\n posts read\n\n 133\n\n given\n\n 494\n\n received\n\n 42\n\n topics created\n\n 127\n\n posts created\n\n Top Replies\n\n Jan 2024\n ·\n  7\n\n On Block Sizes, Gas Limits and Scalability\n\n Dec 2024\n ·\n  4\n\n Towards Attester-Includer Separation\n\n Dec 2023\n ·\n  4\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Aug 2025\n ·\n  3\n\n Ethereum’s Leaky Gas Tank: Unveiling 13 Costly Gas Model Inconsistencies\n\n May 2024\n ·\n  3\n\n Slashing Proofoor - On-chain slashed validator proofs\n\n Mar 2024\n ·\n  3\n\n Analyzing EIP-7623: Increase Calldata Cost\n\n More Replies\n\n Top Topics\n\n Dec 2024\n ·\n  50\n\n On Increasing the Block Gas Limit: Technical Considerations & Path Forward\n\n Apr 2024\n ·\n  49\n\n Analysis on ”Correlated Attestation Penalties”\n\n Aug 2022\n ·\n  48\n\n ERC721 Extension for zk-SNARKs\n\n Jan 2024\n ·\n  47\n\n On Block Sizes, Gas Limits and Scalability\n\n Feb 2024\n ·\n  45\n\n On Increasing the Block Gas Limit\n\n Jun 2024\n ·\n  36\n\n Is it worth using MEV-Boost?\n\n More Topics\n\n Top Links\n\n github.com/Nerolation/EIP-ERC721-zk-SNARK-Extension\n\n ERC721 Extension for zk-SNARKs\n\n dependency.pics\n\n Execution Dependencies\n\n github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md\n\n Block-level Access Lists (BALs)\n\n vitalik.ca/general/2022/01/26/soulbound.html\n\n ERC721 Extension for zk-SNARKs\n\n github.com/ethereum/go-ethereum/blob/830f3c764c21f0d314ae0f7e60d6dd581dc540ce/co\n\n On Block Sizes, Gas Limits and Scalability\n\n github.com/nerolation/slashing-proofoor\n\n Slashing Proofoor - On-chain slashed validator proofs\n\n Most Replied To\n\n thogard785\n\n Thogard\n\n 6\n\n tripoli\n\n Data Always\n\n 6\n\n potuz\n\n Potuz\n\n 6\n\n Evan-Kim2028\n\n Evan Kim2028\n\n 5\n\n terence\n\n 5\n\n CPerezz\n\n CPerezz\n\n 4\n\n Most Liked By\n\n aelowsson\n\n Anders Elowsson\n\n 21\n\n abcoathup\n\n Andrew B Coathup\n\n 18\n\n wanify\n\n Seongwan Park\n\n 16\n\n donnoh\n\n Luca Donno\n\n 13\n\n nixorokish\n\n nixo\n\n 9\n\n markodayan\n\n Mark Odayan\n\n 9\n\n Most Liked\n\n vbuterin\n\n Vbuterin\n\n 10\n\n mikeneuder\n\n mike neuder\n\n 8\n\n terence\n\n 8\n\n aelowsson\n\n Anders Elowsson\n\n 7\n\n soispoke\n\n soispoke\n\n 7\n\n MicahZoltu\n\n Micah Zoltu\n\n 6\n\n Top Categories\n\n Topics\n Replies\n\n Execution Layer Research\n\n 12\n\n 34\n\n Economics\n\n 7\n\n 29\n\n Proof-of-Stake\n\n 6\n\n 25\n\n Sharding\n\n 10\n\n 15\n\n zk-s[nt]arks\n\n 2\n\n 9\n\n Block proposer\n\n –\n\n 6\n\n Top Badges\n\n Member\n\n Granted invitations, group messaging, more likes\n\n Great Share\n\n Shared a post with 1000 unique visitors\n\n Aficionado\n\n Visited 100 consecutive days\n\n Nice Topic\n\n Received 10 likes on a topic\n\n 21 awarded\n\n Enthusiast\n\n Visited 10 consecutive days\n\n Gives Back\n\n Has 100 liked posts and gave 100 likes\n\n More Badges\n\n Powered by Discourse","tokens":731,"squid":"ink-research","role":"Deep Scholar","at":1791257495115,"hash":"f2f1f11ba65a399fd3f648af296c6c4b74674eae"}
{"url":"https://aave.com/docs/aave-v4/getting-started/graphql","domain":"aave.com","title":"AaveKit API v4 | Aave Protocol Documentation","text":"GraphQL#\nGet started with AaveKit API\n\nAaveKit API exposes a comprehensive GraphQL interface that allows you to query liquidity data, user positions, and faciliates the execution of transactions. This low-level API is perfect for custom integrations, data analysis, and building integrations for which the TypeScript SDK is not suitable.\nGetting Started#\nAaveKit API for Aave v4 is available at:\nhttps://api.v4.aave.com/graphql\nThe URL above works also as a GraphQL playground you can use to test your\nqueries.\nYou can query the API directly using any HTTP client. Here's a basic example using curl to query supported chains:\ncurl -X POST https://api.v4.aave.com/graphql \\ -H \"Content-Type: application/json\" \\ -d '{ \"query\": \"query Chains { chains(request: { query: { filter: ALL } }) { name chainId icon } }\" }'\nQuery Operations#\nAaveKit API is constituted by just two types of queries:\nRead queries – queries that return data from the Aave Protocol.Transactions queries – queries that prepare transactions to be executed on the Aave Protocol.\nThe transactions queries are in turn divided into two categories:\nSimple transactions – single-step transactions that can be sent directly to the wallet.Complex transactions – transactions that may require prior approvals before they can be executed.\nSimple Transactions#\nSimple transactions query returns a TransactionRequest object that can be used to send the transaction to the wallet.\ntype TransactionRequest { to: EvmAddress! from: EvmAddress! data: BlockchainData! value: BigInt! chainId: ChainId! operations: [OperationType!]!}\nComplex Transactions#\nComplex transactions query returns an ExecutionPlan union.\nThe ExecutionPlan union represents the different scenarios that can occur when preparing a transaction:\nTransactionRequest: The transaction can be executed directly.Erc20ApprovalRequired: One or more ERC-20 approvals are required first, then the original transaction can be executed.PreContractActionRequired: A pre-contract action must be sent first, then the original transaction can be executed.InsufficientBalanceError: The user doesn't have enough balance of the token to be used in the transaction.\nunion ExecutionPlan = | TransactionRequest | Erc20ApprovalRequired | PreContractActionRequired | InsufficientBalanceError\nMultiple Approvals: Some tokens (like USDT) don't allow increasing an\nexisting allowance. For these tokens, the API returns multiple approvals in\nsequence: first to reset the allowance to 0, then to set it to the required\namount.\nTransaction Monitoring#\nAfter sending a transaction, AaveKit API may take a short time to process and reflect the new state in its responses due to caching and background invalidation. To reliably know when your transaction has been processed and data is up to date, use the hasProcessedKnownTransaction query.\nThis query lets you check if a transaction (by hash and operations type) has been indexed and processed by the API, so you can safely fetch updated user or market data. Note that this can only be used with transactions where the TransactionRequest has a non-null operations field.\nquery { value: hasProcessedKnownTransaction( request: { operations: [SUPPLY], txHash: \"0x1234…\" } )}\nReturns true if the transaction has been processed and data is fresh.Returns false if the transaction is not yet processed (wait and retry).\nWhen to use:\nAfter sending a transaction, poll this query until it returns true before fetching updated positions or balances.This avoids race conditions with cached data and ensures your UI reflects the latest state.\n\nScalars#\nA non comprehensive list of the custom scalars used in the Aave Protocol GraphQL API.\nBlockchainDataBigIntBigDecimalChainIdEvmAddressTxHashDateTimeA string representing binary data as a hex string.0x0000000000000000000000000000000000000000000000000000000000000020\nCommon Types#\nSome of the common types used in the Aave Protocol GraphQL API.\nDecimalNumberPercentNumberChainTokenInfoErc20TokenErc20AmountExchangeAmountA DecimalNumber object represents a decimal value with arbitrary precision.type DecimalNumber { \"\"\" The on-chain representation of `value`, stored as an integer. \"\"\" onChainValue: BigInt!\n \"\"\" The number of decimals defining how many fractional digits the number supports. \"\"\" decimals: Int!\n \"\"\" The normalized value computed as `onChainValue / 10^decimals`. \"\"\" value: BigDecimal!}","tokens":1096,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257502032,"hash":"f90a186b01ed15d8cdcde582a88463df371deb0d"}
{"url":"https://io.net/docs/guides/payment/deploy-cluster-and-pay","domain":"io.net","title":"Deploy Cluster and Pay - io.net","text":"​Deploy Cluster and Pay with $IO Coin\nIf you don’t have any funds in your account, you can still deploy a cluster and pay for it at the end of the process. In this example, we pay with $IO Coin.\n​1. Pay\n\nComplete the steps to deploy a cluster, and on the final Summary step, select “Pay with $IO Coin”. Please note that if you choose $IO coins as payment for the cluster, the conversion rate updates every minute based on the exchange rate.\n\nIf you are satisfied with the current rate, click Deploy Cluster at the bottom of the Summary step.\n\nAt the end of the deploy process, click Click to pay button. Please note that if payment isn’t completed within 20 minutes, the cluster creation session will end, and the cluster will be destroyed. You’ll then be redirected to the previous step to confirm the details and create the cluster again.\n\nIn the Payment Currency dialog, you select IO Coin (via Sphere Pay). After selecting your payment method, click Confirm Method.\n\nOn the Set Amount dialog, you can select Custom and enter any amount, or select the values to the right: 20, 100, 200, or 400 and click Confirm Amount and you are redirected to Spherepay to complete the transaction.\n\n​2. Select Payment Method - $IO Coin\n\nYou are redirected to Spherepay to complete the transaction.\nTo connect your wallet, you can click Select Wallet or Connect Wallet.\nWhen the wallet will be connected Click Pay with $IO Coin\n\n​3. Connect Wallet\n\nIf you have a wallet, Spherepay may detect it. Scroll to browse and select your wallet if undetected. (Image below is a truncated list).\n\nClick Connect.\n\nAfter you complete the transaction, wait until your cluster is successfully deployed.\n\nClick View Cluster to view the details of your deployed cluster.\n\n​Deploy Cluster and Pay with USDC Crypto\nIf you don’t have any funds in your account, you can still deploy a cluster and pay for it at the end of the process. In this example, we pay with USDC crypto.\nUsers can no longer use their Cloud USDC Balance to deploy clusters. Even if your account shows a positive Cloud USDC Balance, you must make a separate direct payment via USDC crypto for each cluster deployment.\n​1. Pay\n\nComplete the steps to deploy a cluster, and on the final Summary step, select Pay with USDC.\n\nCheck the cost in USD and click Deploy Cluster.\n\nAt the end of the deploy process, click Click to pay button. Please note that if payment isn’t completed within 20 minutes, the cluster creation session will end, and the cluster will be destroyed. You’ll then be redirected to the previous step to confirm the details and create the cluster again.\n\nIn the Payment Currency dialog, you select USDC (via Sphere Pay). After selecting your payment method, click Confirm Method.\n\nOn the Set Amount dialog, you can select Custom and enter any amount, or select the values to the right: 20, 100, 200, or 400 and click Confirm Amount and you are redirected to Spherepay to complete the transaction.\n\n​2. Select Payment Method - USDC Token\n\nYou are redirected to Spherepay to complete the transaction.\nTo connect your wallet, you can click Select Wallet or Connect Wallet.\nWhen the wallet will be connected Click Pay with USDC\n\n​3. Connect Wallet\n\nIf you have a wallet, Spherepay may detect it. Scroll to browse and select your wallet if undetected. (Image below is a truncated list).\n\nClick Connect.\n\nAfter you complete the transaction, wait until your cluster is successfully deployed.\n\nClick View Cluster to view the details of your deployed cluster.\n\n​Deploy Cluster and Pay with Fiat\nIf you don’t have any funds in your account, you can still deploy a cluster and pay for it at the end of the process. In this example, we pay with a credit card.\n\nComplete the steps to deploy a cluster, and on the final Summary step, select Pay with USDC.\n\nCheck the cost in USD and click Deploy Cluster.\n\nAt the end of the deploy process, click Click to pay button. Please note that if payment isn’t completed within 20 minutes, the cluster creation session will end, and the cluster will be destroyed. You’ll then be redirected to the previous step to confirm the details and create the cluster again.\n\nIn the Payment Currency dialog, you select USD (Credit/Debit card). After selecting your payment method, click Confirm Method.\n\nOn the Set Amount dialog, you can select Custom and enter any amount, or select the values to the right: 20, 100, 200, or 400 and click Confirm Amount and you are redirected to Stripe to complete the transaction.\n\nSelect Card in the Payment method section. Enter your credit card information and click Pay.\n\nAfter your payment is processed, a confirmation appears.\n\nReturn to the tab with your cluster. Payment Verified is checked and the cluster is in the deployment process. Click View Cluster to view the details of your deployed cluster.\n\nWas this page helpful?","tokens":1209,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257505049,"hash":"331e2304066894252838831cf1b6761ae41ea1ca"}
{"url":"https://ethresear.ch/t/ethereums-leaky-gas-tank-unveiling-13-costly-gas-model-inconsistencies/22989/2","domain":"ethresear.ch","title":"Ethereum's Leaky Gas Tank: Unveiling 13 Costly Gas Model Inconsistencies - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n Aug 2025\n\n 2 / 7\n\n Aug 2025\n\n Sep 2025\n\n post by hzysvilla on Aug 28, 2025\n\n hzysvilla\n\n 13 Gas-model inconsistencies in Ethereum\nThis post summarizes 13 inconsistencies in Ethereum’s gas model.\nAll the symbols come from the Ethereum Yellow Paper (esp. Appendix G. Fee Schedule).\n\n1. The external transaction does not incur new-account charges (G_{newaccount}𝐺𝑛𝑒𝑤𝑎𝑐𝑐𝑜𝑢𝑛𝑡) when creating an account, but internal transactions do\nExample\nSuppose you want a contract C to transfer ETH to a brand-new account A that does not yet exist.\n\nIf C transfers directly, the internal new-account path charges 25,000 gas (G_{newaccount}𝐺𝑛𝑒𝑤𝑎𝑐𝑐𝑜𝑢𝑛𝑡).\nAlternative: first send an external tx from an EOA to A with 1 wei. This tx costs the standard base 21,000 gas. After that, A exists. Now C’s transfer to A no longer incurs the new-account charge (Save ~4,000 gas).\n\nConclusion\nIf you rely on a contract to create a new account, you pay 25,000 gas.\nBut if you first send an external transaction (21,000 gas) and then let the contract send funds, you effectively save ~4,000 gas.\nCause\nExternal and internal creation paths use different charging hooks; only the contract invoking triggers the explicit new-account fee.\n2. Precompile calls sometimes skip transaction input-byte fees\nExample\nCalling a precompiled contract (e.g., ECRECOVER) may skip charging for transaction input bytes. Normally, input bytes cost 4 gas (zero) or 16 gas (non-zero) each. Take two real transaction examples:\n* 1. A transaction 0x6b01 calling ECRECOVER with 24,276 gas, where 276 gas is for the input bytes.\n* 2. A transaction 0x1fb0 calling ECRECOVER with 24,000 gas, where 0 gas is for the input bytes.\nIf you read the source code of execution client, you can find that the second transaction can also execute ECRECOVER without charging for input bytes. The client will pad the input with zero data to match the expected size.\nExtra note\nI guess you are smart enough to notice that the two transactions I mentioned are external transactions.\nSo why do they invoke precompiled contracts?\nI guess part of the reason is that some explorers mislabel precompile addresses (0x01–0x0A) as “burn addresses,” further confusing users (see here with the below snapshot).\nburn_address539×182 39.1 KB\nBesides, deploying the precompile addresses in these special addresses (0x01–0x0A) is a failed design.\nSometimes, people just want to call these special addresses directly.\nCause\nThe poor address design of precompiled contracts and the misleading of block explorers leads to confusion and mislabeling.\n3. Access-list entries are charged even if never accessed (i.e., G_{accesslistaddress}𝐺𝑎𝑐𝑐𝑒𝑠𝑠𝑙𝑖𝑠𝑡𝑎𝑑𝑑𝑟𝑒𝑠𝑠, G_{accessliststorage}𝐺𝑎𝑐𝑐𝑒𝑠𝑠𝑙𝑖𝑠𝑡𝑠𝑡𝑜𝑟𝑎𝑔𝑒)\nExample\nEIP-2930 introduces access lists, allowing transactions to specify which addresses and storage slots they intend to access. However, a transaction can include addresses and slots in its access list but never touches them.\nFor example, a transaction 0x0dd0c sets an access list but never accesses the specified slots due to the address.\nCause\nThe protocol charges on inclusion to simplify execution, regardless of whether the entries are used. If you trust your users can provide you with correct input, you might as well trust Taylor Swift is your wife.\n4. Self-transfer still charges transfer gas\nExample\nAccount A sends ETH to itself.\nNo balance change occurs, yet charges still include 9,000 gas (G_{callvalue}𝐺𝑐𝑎𝑙𝑙𝑣𝑎𝑙𝑢𝑒) for the value transfer. According to this post from @vbuterin.\n\nTwo account writes (a balance-editing CALL normally costs 9000 gas)\n\nWhy does one account writing still cost 9,000 gas? Actually, if you read the source of execution client, you will find that when the from address is the same as the to address, the client will do nothing.\nThe above cases can happen when the transaction is a self-transfer or uses CALLCODE to transfer value.\nCause\nExecution charges trigger regardless of whether the transfer is a no-op.\n5. Calldata vs. contract bytecode disk pricing mismatch\nExample\n\nTx calldata: 16 gas/byte (non-zero) or 4 gas/byte (zero).\nContract bytecode: 200 gas/byte.\nBoth occupy disk, yet pricing is inconsistent. It’s very confusing for me, as tx calldata is cheaper than contract bytecode as it should consider the actual disk usage and network overhead.\n\nCause\nGas schedule separates “calldata” and “code deposit” without aligning them to actual disk usage.\n6. Reverted transactions are charged as if they wrote to disk\nExample\nA reverted transaction modifies state in memory, but no changes persist, yet charges for writes are still applied, the following gas fees are affected:\n\n25,000 gas (new account, G_{newaccount}𝐺𝑛𝑒𝑤𝑎𝑐𝑐𝑜𝑢𝑛𝑡)\n9,000 gas (value transfer, G_{callvalue}𝐺𝑐𝑎𝑙𝑙𝑣𝑎𝑙𝑢𝑒)\n2,100 gas (cold slot, G_{coldslot}𝐺𝑐𝑜𝑙𝑑𝑠𝑙𝑜𝑡)\n200 gas (code deposit, G_{codedeposit}𝐺𝑐𝑜𝑑𝑒𝑑𝑒𝑝𝑜𝑠𝑖𝑡)\n\nActual memory-only cost would have been ~100 gas.\nCause\nGas is charged during execution; a later revert cancels state changes but not fees. Implementations conservatively charge to prevent DoS.\n7. Multiple ETH transfers in a single transaction are mischarged as cold\nExample\nSuppose a contract sends ETH to different accounts multiple times within a single transaction.\n\nThe first transfer correctly incurs the G_{callvalue}𝐺𝑐𝑎𝑙𝑙𝑣𝑎𝑙𝑢𝑒 (9,000 gas) to write to the account’s balance.\nSubsequent transfers to the other account in the same transaction should be charged the warm access fee (100 gas + 4,500 gas), but sometimes are still billed as cold (9,000 gas).\n\nCause\nThe warm/cold access bookkeeping is not consistently updated for multiple value transfers within a single transaction.\n8. Miner/validator reward or withdrawal writes are uncharged\nExample\nProtocol-level balance updates (e.g., rewards, withdrawals) modify state on disk but cost 0 gas.\nCause\nSystem-level bookkeeping bypasses the gas accounting hooks.\n9. SSTORE’s first disk read is uncharged (per EIP-2200)\nExample\nWhen the SSTORE opcode is executed, it first reads the current value from disk (contract storage) before deciding whether to write a new value. According to EIP-2200, if the value being stored matches the existing value, no disk write occurs and only a minimal gas fee is charged. However, the initial disk read itself is not charged any gas—the protocol only charges for the subsequent write if the value changes.\nCause\nEIP-2200’s logic focuses on charging for state changes, but omits charging for the disk read that always happens first. This means the first access to the storage slot is free, even if it’s a cold read.\n10. Storage-read optimizations reduced I/O but gas remained unchanged\nExample\nEthereum clients have adopted flat storage/snapshot optimizations (e.g., Snapshot acceleration structure for geth), which organize state as a flat key-value store and allow direct disk reads, bypassing the intermediate nodes required by the legacy Merkle-Patricia Trie (MPT). This optimization significantly reduces disk I/O for cold storage reads. For instance, Geth and other clients now use SAS or similar structures, but the gas fees for cold accesses—2,600 / 2,100 / 2,400 / 1,900 gas—remain unchanged.\nCause\nGas constants for cold access were originally calibrated for MPT, where disk reads were more expensive due to traversing multiple trie nodes. With SAS, the actual disk resource consumption is much lower, but the protocol has not updated the corresponding gas fees.\nMitigation\nRecalibrate gas constants to reflect the reduced disk I/O when clients switch to SAS or similar optimized storage backends.\n11. SLOAD vs. MLOAD pricing mismatch\nExample\n\nSLOAD (warm) → 100 gas\nMLOAD → 3 gas\nBoth are memory reads, but prices differ greatly.\n\nCause\nLegacy distinction between state and memory operations; optimizations have blurred the actual cost gap.\n12. Internal transactions sometimes update accounts without gas\nExample\nWhen account updates in disk occur without charging a gas fee for those updates. Specifically, this issue arises in scenarios where a user sends an external transaction to contract A, which in turn makes an internal call to contract B. If contract B modifies a slot in its storage, the corresponding storage root in contract B’s account must be updated on disk. However, no gas fees are charged for this account B update, leading to an inconsistency.\nCause\nThe bug occurs because the storage trie modification of contract B incurs no additional gas fee for updating its account state. This results from the protocol not charging for account state updates triggered by internal transactions, even though disk writes are performed.\n13. EXT* opcodes priced too coarsely\nExample\nEXTCODESIZE may read more data than BALANCE, but both are charged the same cold-account fee (2,600 gas).\nCause\nOpcode pricing buckets are coarse and ignore variable work.\nClosing Note\nThis issue comes from my paper as follows, I share it with this link.\n\nHe, Z., Li, Z., Luo, J., Luo, F., Duan, J., Li, J., … & Zhang, X. (2025, February). Auspex: Unveiling Inconsistency Bugs of Transaction Fee Mechanism in Blockchain. In Proceedings of the 23rd USENIX Conference on File and Storage Technologies.\n\nI would be glad if you could cite my paper.\nAll this highlights the need for a comprehensive review and adjustment of gas pricing mechanisms within the Ethereum protocol. By addressing these inconsistencies, we can ensure a more efficient and fair gas market that accurately reflects the underlying resource costs of various operations.\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n post by Nero_eth on Aug 29, 2025\n\n Nero_eth\n\n Thanks for the post, some really interesting points there!\nI will not comment on every single one raised but the calldata pricing is at 10/40 for calldata-heavy transaction since EIP-7623 which shipped in Pectra.\nRe EIP-2930 access lists, the real inconsistency is not that the protocol charges for unused storage slots (if that wouldn’t be the case you’d be open for DoS as a block builder), but that we don’t charge for the data footprint access lists have, as well as the bandwidth they consume.\nWith EIP-7928, they become obsolete anyway, so we should just deprecate them somehow.\nThe fact that precompiles calls don’t contribute to the gas available was an intentional design decision.\nHave you already proposed some of the changes, thinking of 1, 2, 3, 7, 9, 10, 11, 12, 13? Those would be a good fit for repricings that are potentially happening with the Amsterdam hardfork. Some of them, I’d bundle into one EIP, and some of them kept separate.\n\n post by hzysvilla on Aug 29, 2025\n\n hzysvilla\n\n Thank you for your reply to my post first;\n\nYour detailed response has given me a much better understanding of Ethereum’s current progress. I agree with your point; perhaps we can add some foolproof designs at the implementation level (without merging into the protocol) to confirm whether the user actually accessed.\nI haven’t proposed any EIPs on these topics yet, but I’d be delighted to work on them under the guidance of an experienced researcher like yourself—I’ve long admired your work, such as EIP-7987, EIP-7778 and EIP-7928. If possible, could you please DM me your contact information (or contact me with zi-hao.li@connect.polyu.hk)? It is a great honor to have been able to make some contributions under your leadership.\n\n post by vbuterin on Aug 30, 2025\n\n vbuterin\n\n It’s a good list!\n\n(1), (4), (7), (13) are addressed by EIP-4762, a companion EIP to statelessness (binary or verkle), which replaces all of the costs you mention with a principled system based on charging for accessing pieces of storage that were not yet accessed during the same block.\nNo comment on (2); though personally I hope we can in the medium term get rid of most of our precompiles and do a hard fork to swap them in-place with native code (EVM or RISCV) contracts\n(3) is fine as-is, because the point of an access list is that clients use it to determine what data to fetch; fetched but unused data is still a cost\nFor (5), contract bytecode is more expensive because it increases the size of state, which is much more difficult to prune than history, eg. as of May pre-merge history is pruned already.\n(6) is definitely suboptimal; ideally we would only charge for the read in that case. I think the main reason we don’t care too much historically is that a revert happening is the result of bad code, but maybe that assumption is worth revisiting.\nIntuitively I don’t see (8) as a problem.\nFor (9), I see in EIP-2200 “If current value equals new value (this is a no-op), SLOAD_GAS is deducted.” So the disk read is charged in that case.\nRegarding (10) and (11), storage pricing is not just about milliseconds in a client, it’s also about enabling stateless execution, and preparing for ZK-proving the chain. Storage access is a high cost in these environments.\nI’m confused by (12). In your example, the user has to pay (i) 2600 gas for a cold call A → B, and (ii) 2100 gas for a cold SLOAD within B. So accounting is done as intended. But anyway, EIP-4762 will make this whole system much simpler.\n\n post by hzysvilla on Sep 2, 2025\n\n post by vbuterin on Sep 6, 2025\n\n post by hzysvilla on Sep 8, 2025\n\n Powered by Discourse","tokens":3347,"squid":"ink-research","role":"Deep Scholar","at":1791257505251,"hash":"889735cf697699d496caefe4dfc16662e5a56957"}
{"url":"https://aave.com/docs/vaults/stable-vaults","domain":"aave.com","title":"Stable Vaults | Aave Protocol Documentation","text":"Stable Vaults#\nStable Vaults enable financial platforms to embed stable-rate earning on stablecoins directly into their products.\nRequest Integration\nOverview#\nStable Vaults let financial platforms offer stable-rate earning on stablecoins without exposing their users to the complexity of DeFi. Where traditional DeFi lending rates fluctuate with market utilization, Stable Vaults absorb that volatility into a stable-rate product layer that is easier to explain, forecast, and embed. Users deposit stablecoins and earn at a stable rate that compounds continuously, while the vault manages liquidity, accounting, and yield allocation underneath. The platform controls who can access the vault, the rate each user earns, and how revenue flows back to the business. Supported stablecoins are treated as equivalent once deposited, so users can withdraw in any supported asset regardless of what they put in.\n\nLearn more about how Stable Vaults work:\nFeatures: stable-rate earnings, multi-strategy and multi-chain earning, per-user rates, allowlisting, revenue management, and multi-asset deposits & withdrawals.Architecture: the Accounting Chain, Earning Chains, and roles & access controls.ERC-4626 Yield Strategies: the yield sources the vault allocates deposits into.PreviousEarn Vault ManagementNextFeatures","tokens":327,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257511952,"hash":"7042dd9adb853b64699f1ccfc3f3a6bd08af94b4"}
{"url":"https://io.net/docs/guides/workers/io-worker","domain":"io.net","title":"Overview - io.net","text":"​IO Worker Development Principles\nWe recognize the pivotal role IO Worker and Suppliers are providing required computing power play in our ecosystem. As such, our IO Worker portal is meticulously crafted to cater to the unique needs of our suppliers, emphasizing real-time updates, stringent security, streamlined operations, and user-friendly interfaces.\n​I. Full Financial Control\nReal-time Earnings Overview. We are staunch advocates for complete financial transparency. Through our portal, suppliers gain real-time access to their earnings and financial metrics. Leveraging the capabilities of ReactJS and a Fast API backend layer, we guarantee that the financial data displayed remains current, empowering suppliers to make decisions grounded in the latest figures. No more delays or uncertainties – you witness your earnings in real-time. Our Billing/Usage Monitoring layer ensures meticulous oversight.\n​II. Ease of Management\nSimplified GPU Integration. Time is of the essence, and we recognize its value. That’s precisely why we’ve simplified the GPU addition process on our platform. Suppliers are spared the hassle of navigating intricate setups or configurations. Add your GPU, and our system seamlessly integrates the rest with our advanced tech stack. This approach allows suppliers to concentrate on their core competencies while we manage the technical orchestration.\nWe employ state-of-the-art orchestration tools, including Kubernetes, Prefect, and Apache Airflow, to ensure a swift and reliable deployment process.\n​III. Efficient Resource Use\nOptimized GPU Utilization. In the GPU supply landscape, unutilized resources represent lost potential. Our platform is meticulously crafted to optimize the use of GPUs supplied by our partners. Through smart task allocation and workload management, facilitated by our Fault Monitoring/Reporting/Analytics layers, we ensure GPUs are neither overwhelmed nor underutilized. This strategy enhances profitability and guarantees a consistent revenue flow for our suppliers.\n​IV. Real-time Monitoring\nStay Informed. Miners have the capability to monitor their GPU usage in real time on our platform, ensuring unparalleled transparency and clarity. Our platform offers a holistic view, from intricate GPU performance metrics to detailed earnings breakdowns. This comprehensive overview empowers miners to closely track their returns and guarantees that their hardware is utilized to its fullest potential. To further enhance this, our Analytics Layer provides deeper insights and trends.\n​V. Security & Stability\nProtected Assets. The GPUs that miners rent out are invaluable assets. Recognizing this, our platform is reinforced with stringent security protocols to safeguard the hardware and the associated earnings. Stability is a cornerstone of our service. We are committed to ensuring that the GPU renting process remains seamless, marked by consistent uptime and unwavering performance. Our Fault Monitoring Layer actively oversees and ensures system health to bolster this commitment.Was this page helpful?","tokens":767,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257514949,"hash":"1f7af64729a1ea5b3faa61587e3d7a3c9081f6dd"}
{"url":"https://ethresear.ch/t/ethereums-leaky-gas-tank-unveiling-13-costly-gas-model-inconsistencies/22989/4","domain":"ethresear.ch","title":"Ethereum's Leaky Gas Tank: Unveiling 13 Costly Gas Model Inconsistencies - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n Aug 2025\n\n 4 / 7\n\n Aug 2025\n\n Sep 2025\n\n post by hzysvilla on Aug 28, 2025\n\n post by Nero_eth on Aug 29, 2025\n\n Nero_eth\n\n Thanks for the post, some really interesting points there!\nI will not comment on every single one raised but the calldata pricing is at 10/40 for calldata-heavy transaction since EIP-7623 which shipped in Pectra.\nRe EIP-2930 access lists, the real inconsistency is not that the protocol charges for unused storage slots (if that wouldn’t be the case you’d be open for DoS as a block builder), but that we don’t charge for the data footprint access lists have, as well as the bandwidth they consume.\nWith EIP-7928, they become obsolete anyway, so we should just deprecate them somehow.\nThe fact that precompiles calls don’t contribute to the gas available was an intentional design decision.\nHave you already proposed some of the changes, thinking of 1, 2, 3, 7, 9, 10, 11, 12, 13? Those would be a good fit for repricings that are potentially happening with the Amsterdam hardfork. Some of them, I’d bundle into one EIP, and some of them kept separate.\n\n post by hzysvilla on Aug 29, 2025\n\n hzysvilla\n\n Thank you for your reply to my post first;\n\nYour detailed response has given me a much better understanding of Ethereum’s current progress. I agree with your point; perhaps we can add some foolproof designs at the implementation level (without merging into the protocol) to confirm whether the user actually accessed.\nI haven’t proposed any EIPs on these topics yet, but I’d be delighted to work on them under the guidance of an experienced researcher like yourself—I’ve long admired your work, such as EIP-7987, EIP-7778 and EIP-7928. If possible, could you please DM me your contact information (or contact me with zi-hao.li@connect.polyu.hk)? It is a great honor to have been able to make some contributions under your leadership.\n\n post by vbuterin on Aug 30, 2025\n\n vbuterin\n\n It’s a good list!\n\n(1), (4), (7), (13) are addressed by EIP-4762, a companion EIP to statelessness (binary or verkle), which replaces all of the costs you mention with a principled system based on charging for accessing pieces of storage that were not yet accessed during the same block.\nNo comment on (2); though personally I hope we can in the medium term get rid of most of our precompiles and do a hard fork to swap them in-place with native code (EVM or RISCV) contracts\n(3) is fine as-is, because the point of an access list is that clients use it to determine what data to fetch; fetched but unused data is still a cost\nFor (5), contract bytecode is more expensive because it increases the size of state, which is much more difficult to prune than history, eg. as of May pre-merge history is pruned already.\n(6) is definitely suboptimal; ideally we would only charge for the read in that case. I think the main reason we don’t care too much historically is that a revert happening is the result of bad code, but maybe that assumption is worth revisiting.\nIntuitively I don’t see (8) as a problem.\nFor (9), I see in EIP-2200 “If current value equals new value (this is a no-op), SLOAD_GAS is deducted.” So the disk read is charged in that case.\nRegarding (10) and (11), storage pricing is not just about milliseconds in a client, it’s also about enabling stateless execution, and preparing for ZK-proving the chain. Storage access is a high cost in these environments.\nI’m confused by (12). In your example, the user has to pay (i) 2600 gas for a cold call A → B, and (ii) 2100 gas for a cold SLOAD within B. So accounting is done as intended. But anyway, EIP-4762 will make this whole system much simpler.\n\n post by hzysvilla on Sep 2, 2025\n\n hzysvilla\n\n THX for your reply.\nI agree that EIP-4762 bridges the gap between the gas cost and real resource with fine-grained access/write events.\n\nFor (9), my point is that when the current value does not equal the new value, the protocol does not charge for the read required to check equality, and only charges for the write operation.\n\nHere, an EOA first sends a transaction to contract A, which then makes an internal call to contract B. If contract B modifies its storage (e.g., by writing to a state variable), this first updates the MPT nodes for contract B, and subsequently changes contract B’s account state in the world state (as the storage root update).\nIn my view, the current gas cost model only charges for the write operation on contract B’s MPT nodes but doesn’t account for the write operation on contract B’s account state.\n\nThank you again for your reply, which gave me new insights into the philosophy of gas model design. From (6), I wonder if the gas model should consider the actual execution status of a transaction (whether it succeeds). From (9), should it account for resource consumption changes brought by optimizations in read operations? And from (12), should it consider the resource cost of verification itself?\nWe will explore to package some of the useful cases you mentioned into an EIP if necessary.\n\n post by vbuterin on Sep 6, 2025\n\n post by hzysvilla on Sep 8, 2025\n\n Powered by Discourse","tokens":1301,"squid":"ink-research","role":"Deep Scholar","at":1791257515352,"hash":"5c47c0084eeea19b6081eb11f5983ab085ae6613"}
{"url":"https://aave.com/docs/aave-v4/liquidity/hubs","domain":"aave.com","title":"Aave Liquidity Hubs | Aave Protocol Documentation","text":"Liquidity Hubs#\nLearn how to discover and access liquidity hubs in Aave v4.\n\nHub Structure#\nHub data provide an aggregate view of a liquidity hub, including:\nIdentification: id, name, chain, addressAggregated details: totalSupplied, totalBorrowedSystem caps: totalSupplyCap, totalBorrowCap\nTypeScriptGraphQLSolidityThe following TypeScript interfaces illustrate the core Hub type:interface Hub { __typename: \"Hub\"; id: HubId; address: EvmAddress; chain: Chain; name: string; summary: HubSummary;}\nListing Available Hubs#\nDiscover all available Aave Liquidity Hubs across supported networks.\nReactTypeScriptGraphQLSolidityUse the useHubs hook to fetch a list of liquidity hubs.import { type HubsRequest, useHubs } from \"@aave/react\";\nfunction HubsList({ request }: { request: HubsRequest }) { const { data, loading, error } = useHubs(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((hub) => ( <div key={hub.id}> <h3>{hub.name}</h3> <p>Chain: {hub.chain.name}</p> </div> ))} </div> );}The useHubsAction hook does not watch for updates. Use it when you need\non-demand, fresh data (e.g., in an event handler).See below for examples of HubsRequest objects.import { chainId } from \"@aave/react\";\nconst request: HubsRequest = { query: { chainIds: [chainId(1)], },};And you can specify a different currency for the data.import { chainId, Currency } from \"@aave/react\";\nconst { data, error, loading } = useHubs({ query: { // your query criteria }, currency: Currency.Eur,});\nFetching a Single Hub#\nGet detailed information about a specific liquidity hub.\nReactTypeScriptGraphQLUse the useHub hook to fetch a specific hub.import { type HubRequest, useHub } from \"@aave/react\";\nfunction HubDetails({ request }: { request: HubRequest }) { const { data, loading, error } = useHub(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n if (!data) return <div>Hub not found</div>;\n return ( <div> <h2>{data.name}</h2> <p>Address: {data.address}</p> <p>Chain: {data.chain.name}</p> </div> );}See below for examples of HubRequest objects.import { hubId } from \"@aave/react\";\nconst request: HubRequest = { query: { hubId: hubId(params.id), // HubId - typically from URL params },};Finally, you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, loading, error } = useHub({ query: { // your query criteria }, timeWindow: TimeWindow.LastWeek,});\nHub Summary History#\nFetch historical summary data for a specific hub over a specified time window.\nReactTypeScriptGraphQLUse the useHubSummaryHistory hook to fetch historical summary data for a hub.import { type HubSummaryHistoryRequest, useHubSummaryHistory,} from \"@aave/react\";\nfunction HubHistory({ request }: { request: HubSummaryHistoryRequest }) { const { data, loading, error } = useHubSummaryHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> <h2>Hub History</h2> {data.map((item) => ( <div key={item.date.toString()}> <p>Date: {item.date.toLocaleDateString()}</p> <p> Deposits: {item.deposits.symbol} {item.deposits.value.toDisplayString(2)} </p> <p> Borrows: {item.borrows.symbol} {item.borrows.value.toDisplayString(2)} </p> <p>Utilization: {item.utilizationRate.normalized.toFixed(2)}%</p> </div> ))} </div> );}See below for examples of HubSummaryHistoryRequest objects.import { hubId, TimeWindow } from \"@aave/react\";\nconst request: HubSummaryHistoryRequest = { query: { hubId: hubId(params.id) }, window: TimeWindow.LastWeek,};Specify the time window for the historical data.import { hubId, TimeWindow } from \"@aave/react\";\nconst request: HubSummaryHistoryRequest = { query: { hubId: hubId(params.id) }, window: TimeWindow.LastDay,};And you can specify a different currency for the data.import { Currency, hubId, TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useHubSummaryHistory({ query: { hubId: hubId(params.id) }, window: TimeWindow.LastWeek, currency: Currency.Eur,});\n\nHub Spoke Configs#\nFetch per-asset configuration for a specific (hub, spoke) pair, including supply caps, borrow caps, operational status, and the risk premium threshold.\nTypeScriptReactGraphQLinterface HubSpokeConfig { __typename: \"HubSpokeConfig\"; hub: Hub; spoke: Spoke; asset: HubAsset; supplyCap: Erc20Amount; borrowCap: Erc20Amount; active: boolean; halted: boolean; riskPremiumThreshold: PercentNumber;}Use the hubSpokeConfigs action to fetch all asset configs shared by a hub and spoke.import { hubSpokeConfigs } from \"@aave/client/actions\";\nconst result = await hubSpokeConfigs(client, { hubId, spokeId });\nif (result.isOk()) { console.log(result.value); // HubSpokeConfig[]} else { console.error(result.error);}\n\nHub Assets#\nHub assets are the ERC-20 tokens held by a given hub.\nHub Asset Structure#\nHub Asset data provides detailed information about each asset available on a liquidity hub, including:\nIdentification: id, onchainAssetId, underlying token detailsHub reference: the hub where this asset is availableSummary metrics: supplied/borrowed amounts, APY rates, utilizationReserve coverage: total connected reserves and active reservesSettings: fee receiver, liquidity fees, strategiesUser state: user's balance (when user is specified in request)\nTypeScriptGraphQLSolidityinterface HubAsset { __typename: \"HubAsset\"; id: HubAssetId; onchainAssetId: OnChainHubAssetId; hub: Hub; underlying: Erc20Token; summary: HubAssetSummary; settings: HubAssetSettings; userState: HubAssetUserState | null;}\nListing Hub Assets#\nDiscover all available assets on an hub, including their liquidity metrics, APY rates, and user-specific data.\nReactTypeScriptGraphQLSolidityUse the useHubAssets hook to fetch assets for a specific hub.import { type HubAssetsRequest, useHubAssets } from \"@aave/react\";\nfunction HubAssetsList({ request }: { request: HubAssetsRequest }) { const { data, loading, error } = useHubAssets(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((asset) => ( <div key={asset.id}> <h3>{asset.underlying.info.name}</h3> <p>Hub: {asset.hub.name}</p> </div> ))} </div> );}See below for examples of HubAssetsRequest objects.const request: HubAssetsRequest = { query: { hubId: hub.id, // hub.id: HubId from component props or previous query },};And you can add a user address to return HubAssetUserState for each asset.import { evmAddress } from \"@aave/react\";\nconst equest: HubAssetsRequest = { query: { // your query criteria }, user: evmAddress(\"0x456…\"),};Finally, you can specify a different currency for the data.import { Currency } from \"@aave/react\";\n// …\nconst { data, loading, error } = useHubAssets({ query: { // your query criteria }, currency: Currency.Eur,});\nInterest Rate Model#\nThe interest rate model describes how supply and borrow rates change across the utilization range for a specific hub asset. Each data point includes the utilization rate, the corresponding borrow and supply rates, and the liquidity distance from the current state.\nTypeScriptGraphQLinterface HubAssetInterestRateModelPoint { __typename: \"HubAssetInterestRateModelPoint\"; utilizationRate: PercentNumber; borrowRate: PercentNumber; supplyRate: PercentNumber; liquidityDistance: Erc20Amount;}\nFetch the full interest rate curve for a specific hub asset.\nReactTypeScriptGraphQLUse the useHubAssetInterestRateModel hook to fetch the interest rate curve for a hub asset.import { useHubAssetInterestRateModel } from \"@aave/react\";\nfunction InterestRateModel({ hubAssetId }: { hubAssetId: HubAssetId }) { const { data, loading, error } = useHubAssetInterestRateModel({ query: { hubAssetId }, });\n if (loading) return <p>Loading…</p>;\n if (error) return <p>Error: {error.message}</p>;\n return ( <div> {data?.map((point, i) => ( <div key={i}> <span>Utilization: {point.utilizationRate.value}</span> <span>Borrow Rate: {point.borrowRate.value}</span> <span>Supply Rate: {point.supplyRate.value}</span> </div> ))} </div> );}PreviousLiquidity ModelNextSpokes","tokens":2039,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257521951,"hash":"46870ac56dc47c95d6a03ecc13edd9958f6ef748"}
{"url":"https://io.net/docs/guides/staking/io-staking","domain":"io.net","title":"Overview - io.net","text":"The content of this doc is subject to change depending on successful contract auditing.\n​Why Staking?\nStaking is a crucial component of our network security and efficiency. Requiring suppliers to stake $IO allows us to:\n\nEncourage long-term commitment to our platform.\nCreate an incentive for good behavior.\nEstablish a mechanism to discourage and penalize malicious actions.\n\n​How It Works\nStaking Requirements\nTo participate in our network and receive block rewards, GPU and CPU suppliers must stake a specific amount of $IO. The exact staking amount required is determined on the supplier’s capacity and their contribution to the network.\nThe staking requirement is displayed in the UI. The formula for the total is explained below.\n\nBase requirement (minimum stake per card) X = $IO 200.\nIf the multiplier per GPU on the device is less or equal to 1, the per GPU stake is 1 /* X. The minimum staking remains $IO 200.\nIf the multiplier per GPU on the device is greater than 1, then the multiplier value is represented by M. The per GPU stake on this device is M /* X. (Device Earning Multiplier /* Minimum Stake)\nIf there are multiple (N) GPUs on the device, the total device stake value is M /* N /* X.\n\nminimum_stake_required = base_requirement_per_card * max(1, earning_multiplier)\n\nExamples\n\nIf there are eight (8) H100 GPUs (earning multiplier=10) on device A. The minimum staking requirement value is $IO 200. Then the amount required to stake on device A is 8 * 10 * 200 = 16,000 $IO.\nIf there are four (4) 4070s GPUs (earning multiplier=0.25) on device B. The minimum staking requirement value is $IO 200. Then the amount required to stake on device BCD is 4 /* 1/* 200 = 800 $IO.\n\nRewards\nEach supplier’s device will have a dedicated smart contract where the $IO stake is secured. Block Reward Eligibility is determined on a per-device basis. In Phase I, Block Rewards are accrued to the Solana wallet address associated with your account and are distributed through periodic reward claims. This ensures a fair and transparent distribution of rewards to all qualifying participants.\nUnstaking Process\nWhen a supplier decides to unstake their $IO, a 14-day cooldown period is initiated. Once unstaked, $IO in a cooldown period is no longer counted toward minimum staking requirement for Block Rewards. This period helps maintain network stability and prevents potential manipulation.\nThe action of unstaking is irreversible. You can not restake to your device until the cooldown period ends. You must withdraw the coins after the cooldown period to stake to the same device again.\nWhen you unstake and withdraw your IO Coins, always use the wallet used in the initial stake.\nSecurity\nTo protect our network and users, we implemented a slashing mechanism. Staked $IO and accrued block rewards can be subject to slashing. If a supplier engages in malicious behavior, such as spoofing or compromising data, a portion of their staked $IO tokens may be slashed (i.e., deducted from their stake). Also, if your device is providing inadequate service, it is subject to slashing.\nSlashed $IO is subject to a one month reconsideration process. If you notice your device stake is slashed, you can open up a support ticket. IO support will present technical evidence that proves why the device was identified for spoofing or other malicious behavior. Device owners can appeal this decision. If the device owner doesn’t appeal the decision or the appeal is lost, the slashed $IO will be burned.\n​Get Started\nTo participate in the staking program, ensure you have the required amount of $IO and follow our simple staking process in the IO.net platform.\nIn Phase I, only device owners can stake to their own devices. We plan to add features for non-node operators to also stake $IO and earn rewards in Phase II.\nWe’re excited to launch this staking program and look forward to growing our network together. For more detailed information or assistance, please refer to our comprehensive documentation or contact our support team. Join us in shaping the future of decentralised computing with IO.net.\n​Staking Release Stages\n\nPhase: Staking is currently available for workers only.\nPhase: Staking for non-workers is coming soon.\n\nFor more details on earning multipliers, Block Rewards, and the minimum staking requirements, please refer to our public documentation: Proposed calibration in earning multiplier and the simulated impact on Block Rewards.Was this page helpful?","tokens":1117,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257524863,"hash":"364739be7fff8450b42bf7a67dde5e2452985d05"}
{"url":"https://ethresear.ch/t/ethereums-leaky-gas-tank-unveiling-13-costly-gas-model-inconsistencies/22989/7","domain":"ethresear.ch","title":"Ethereum's Leaky Gas Tank: Unveiling 13 Costly Gas Model Inconsistencies - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n Aug 2025\n\n 7 / 7\n\n Sep 2025\n\n Sep 2025\n\n post by hzysvilla on Aug 28, 2025\n\n post by Nero_eth on Aug 29, 2025\n\n post by hzysvilla on Aug 29, 2025\n\n post by vbuterin on Aug 30, 2025\n\n post by hzysvilla on Sep 2, 2025\n\n hzysvilla\n\n THX for your reply.\nI agree that EIP-4762 bridges the gap between the gas cost and real resource with fine-grained access/write events.\n\nFor (9), my point is that when the current value does not equal the new value, the protocol does not charge for the read required to check equality, and only charges for the write operation.\n\nHere, an EOA first sends a transaction to contract A, which then makes an internal call to contract B. If contract B modifies its storage (e.g., by writing to a state variable), this first updates the MPT nodes for contract B, and subsequently changes contract B’s account state in the world state (as the storage root update).\nIn my view, the current gas cost model only charges for the write operation on contract B’s MPT nodes but doesn’t account for the write operation on contract B’s account state.\n\nThank you again for your reply, which gave me new insights into the philosophy of gas model design. From (6), I wonder if the gas model should consider the actual execution status of a transaction (whether it succeeds). From (9), should it account for resource consumption changes brought by optimizations in read operations? And from (12), should it consider the resource cost of verification itself?\nWe will explore to package some of the useful cases you mentioned into an EIP if necessary.\n\n post by vbuterin on Sep 6, 2025\n\n vbuterin\n\nFor (9), my point is that when the current value does not equal the new value, the protocol does not charge for the read required to check equality, and only charges for the write operation.\n\nActually, this is my bad, I forgot to link to EIP-2929. That’s the most up-to-date EIP for SSTORE storage gas accounting.\nAccording to EIP-2929, if the current value does not equal the new value, then the user is charged COLD_SLOAD_COST gas and then another SSTORE_RESET_GAS. If the current value does equal the new value, the user is charged only COLD_SLOAD_COST. So it does the right thing in both cases.\n\nIn my view, the current gas cost model only charges for the write operation on contract B’s MPT nodes but doesn’t account for the write operation on contract B’s account state.\n\nI still don’t get why this would be true. The cost charged for the write on B’s MPT nodes is 2100, and the cost charged for the write to B’s account state is 2600. In your scenario, the user would have to pay 4700 total (plus execution, plus the gas of the transaction), which is intended.\n\nFrom (9), should it account for resource consumption changes brought by optimizations in read operations? And from (12), should it consider the resource cost of verification itself?\n\nIdeally, gas cost should take into account (i) access list size, perhaps charged at the same rate as calldata, (ii) naive re-execution time, and (iii) proving time. There’s definitely work to be done in optimizing these in a more principled way.\n\n post by hzysvilla on Sep 8, 2025\n\n hzysvilla\n\nHere is what I’m thinking.\nEOA → Contract_A → Contract_B\nInitially, 9,000 gas (part of the 21,000 base gas) is consumed to update two accounts: the EOA’s nonce and Contract_A’s storage root.\nHowever, if Contract_A does not transfer ETH to Contract_B (even if Contract_B modifies some storage slots), there will be no additional 9,000 gas charge for updating accounts of Contract_A and Contract_B (because of storage roots changing).\n\nI agree we should rigorously consider gas cost fairness from multiple angles. My work focuses more on fairness regarding resource consumption (which could fall into the second category you mentioned), but considering more dimensions is indeed more reasonable.\n\n Powered by Discourse","tokens":995,"squid":"ink-research","role":"Deep Scholar","at":1791257525399,"hash":"cdbb53c3e2e0dcfbf5f59242e044f8044556210f"}
{"url":"https://www.anchor-lang.com/docs/clients/typescript","domain":"anchor-lang.com","title":"TypeScript","text":"Client LibrariesTypeScriptLearn how to use Anchor's TypeScript client library to interact with Solana programsAnchor provides a Typescript client library\n(@anchor-lang/core)\nthat simplifies the process of interacting with Solana programs from the client\nin JavaScript or TypeScript.\nThe @anchor-lang/core library is only compatible with the legacy version\n(v1) of @solana/web3.js and @solana/spl-token. It is not compatible with\nthe new version (v2) of @solana/web3.js.\nClient Program\nTo interact with an Anchor program using @anchor-lang/core, you'll need to\ncreate a\nProgram\ninstance using the program's IDL file.\nCreating an instance of the Program requires the program's IDL and an\nAnchorProvider.\nAn AnchorProvider is an abstraction that combines two things:\n\nConnection - the connection to a Solana cluster (i.e. localhost, devnet,\nmainnet)\nWallet - (optional) a default wallet used to pay for and sign transactions\n\nWhen integrating with a frontend using the\nSolana wallet adapter, you'll need\nto set up the AnchorProvider and Program.exampleimport { Program, AnchorProvider, setProvider } from \"@anchor-lang/core\";\nimport { useAnchorWallet, useConnection } from \"@solana/wallet-adapter-react\";\nimport type { HelloAnchor } from \"./idlType\";\nimport idl from \"./idl.json\";\n\nconst { connection } = useConnection();\nconst wallet = useAnchorWallet();\n\nconst provider = new AnchorProvider(connection, wallet, {});\nsetProvider(provider);\n\nexport const program = new Program(idl as HelloAnchor, provider);In the code snippet above:\nidl.json is the IDL file generated by Anchor, found at\n/target/idl/<program-name>.json in an Anchor project.\nidlType.ts is the IDL type (for use with TypeScript), found at\n/target/types/<program-name>.ts in an Anchor project.\nThe Program instance is created with both the IDL and the provider, which\nenables signing and sending transactions. This allows you to call .rpc()\nmethods on program instructions.Alternatively, you can create a Program instance using only the IDL and the\nConnection to a Solana cluster. This means there is no default Wallet, but\nallows you to use the Program to fetch accounts or build instructions without\na connected wallet. Note that this read-only configuration does not support\nsigning or sending transactions.import { clusterApiUrl, Connection, PublicKey } from \"@solana/web3.js\";\nimport { Program } from \"@anchor-lang/core\";\nimport type { HelloAnchor } from \"./idlType\";\nimport idl from \"./idl.json\";\n\nconst connection = new Connection(clusterApiUrl(\"devnet\"), \"confirmed\");\n\nexport const program = new Program(idl as HelloAnchor, {\n connection,\n});\nInvoke Instructions\nOnce the Program is set up using a program's IDL file, you can use the Anchor\nMethodsBuilder\nto:\n\nBuild individual instructions\nBuild transactions\nBuild and send transactions\n\nThe basic format looks like the following:\nprogram.methods - This is the builder API for creating instruction calls from\nthe program's IDLawait program.methods\n .instructionName(instructionData)\n .accounts({})\n .signers([])\n .rpc();\nAnchor provides multiple methods for building program instructions:\nThe\nrpc()\nmethod\nsends a signed transaction\nwith the specified instruction and returns a TransactionSignature.When using .rpc, the Wallet from the Provider is automatically included as\na signer.// Generate keypair for the new account\nconst newAccountKp = new Keypair();\n\nconst data = new BN(42);\nconst transactionSignature = await program.methods\n .initialize(data)\n .accounts({\n newAccount: newAccountKp.publicKey,\n signer: wallet.publicKey,\n systemProgram: SystemProgram.programId,\n })\n .signers([newAccountKp])\n .rpc();\nFetch Accounts\nThe Program client simplifies the process of fetching and deserializing\naccounts created by your Anchor program.\nUse program.account followed by the name of the account type defined in the\nIDL. Anchor provides multiple methods for fetching accounts.\nUse\nall()\nto fetch all existing accounts for a specific account type.const accounts = await program.account.newAccount.all();\nExample\nThe example below demonstrates how to use @anchor-lang/core to interact with a\nsimple Anchor program. The program has two instructions:\n\ninitialize – Creates and initializes a counter account to store a value\nincrement – Increments the value stored on the counter account\n\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"6khKp4BeJpCjBY1Eh39ybiqbfRnrn2UzWeUARjQLXYRC\");\n\n#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let counter = &ctx.accounts.counter;\n msg!(\"Counter account created! Current count: {}\", counter.count);\n Ok(())\n }\n\n pub fn increment(ctx: Context<Increment>) -> Result<()> {\n let counter = &mut ctx.accounts.counter;\n msg!(\"Previous counter: {}\", counter.count);\n\n counter.count += 1;\n msg!(\"Counter incremented! Current count: {}\", counter.count);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n\n #[account(\n init,\n payer = payer,\n space = 8 + 8\n )]\n pub counter: Account<'info, Counter>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct Increment<'info> {\n #[account(mut)]\n pub counter: Account<'info, Counter>,\n}\n\n#[account]\npub struct Counter {\n pub count: u64,\n}\nBelow is an example folder structure for a TypeScript client that interacts with\nthe Anchor program:\nexample.jsonexample.tsexample.tspackage.json\nThe /idl directory in the example includes two files:\n\nexample.json: The IDL file for the program\nexample.ts: A TypeScript type definition file generated for the IDL\n\nThe tabs below include the example.json and example.ts files as a reference\nof what these files look like.\n{\n \"address\": \"6khKp4BeJpCjBY1Eh39ybiqbfRnrn2UzWeUARjQLXYRC\",\n \"metadata\": {\n \"name\": \"example\",\n \"version\": \"0.1.0\",\n \"spec\": \"0.1.0\",\n \"description\": \"Created with Anchor\"\n },\n \"instructions\": [\n {\n \"name\": \"increment\",\n \"discriminator\": [11, 18, 104, 9, 104, 174, 59, 33],\n \"accounts\": [\n {\n \"name\": \"counter\",\n \"writable\": true\n }\n ],\n \"args\": []\n },\n {\n \"name\": \"initialize\",\n \"discriminator\": [175, 175, 109, 31, 13, 152, 155, 237],\n \"accounts\": [\n {\n \"name\": \"payer\",\n \"writable\": true,\n \"signer\": true\n },\n {\n \"name\": \"counter\",\n \"writable\": true,\n \"signer\": true\n },\n {\n \"name\": \"system_program\",\n \"address\": \"11111111111111111111111111111111\"\n }\n ],\n \"args\": []\n }\n ],\n \"accounts\": [\n {\n \"name\": \"Counter\",\n \"discriminator\": [255, 176, 4, 245, 188, 253, 124, 25]\n }\n ],\n \"types\": [\n {\n \"name\": \"Counter\",\n \"type\": {\n \"kind\": \"struct\",\n \"fields\": [\n {\n \"name\": \"count\",\n \"type\": \"u64\"\n }\n ]\n }\n }\n ]\n}\nWhen you run anchor build in an Anchor project, the Anchor CLI automatically\ngenerates:\n\nThe IDL file (.json) in the target/idl folder (ex.\ntarget/idl/example.json)\n\nThe TypeScript type definitions (.ts) in the target/types folder (ex.\ntarget/types/example.ts)\n\nThe example.ts file below includes the script to interact with the program.\nexample.tsimport {\n Connection,\n Keypair,\n LAMPORTS_PER_SOL,\n Transaction,\n sendAndConfirmTransaction,\n} from \"@solana/web3.js\";\nimport { Program } from \"@anchor-lang/core\";\nimport type { Example } from \"./idl/example.ts\";\nimport idl from \"./idl/example.json\";\n\n// Set up a connection to the cluster\nconst connection = new Connection(\"http://127.0.0.1:8899\", \"confirmed\");\n\n// Create a Program instance using the IDL and connection\nconst program = new Program(idl as Example, {\n connection,\n});\n\n// Generate new Keypairs for the payer and the counter account\nconst payer = Keypair.generate();\nconst counter = Keypair.generate();\n\n// Airdrop SOL to fund the payer's account for transaction fees\nconst airdropTransactionSignature = await connection.requestAirdrop(\n payer.publicKey,\n LAMPORTS_PER_SOL,\n);\nawait connection.confirmTransaction(airdropTransactionSignature);\n\n// Build the initialize instruction\nconst initializeInstruction = await program.methods\n .initialize()\n .accounts({\n payer: payer.publicKey,\n counter: counter.publicKey,\n })\n .instruction();\n\n// Build the increment instruction\nconst incrementInstruction = await program.methods\n .increment()\n .accounts({\n counter: counter.publicKey,\n })\n .instruction();\n\n// Add both instructions to a single transaction\nconst transaction = new Transaction().add(\n initializeInstruction,\n incrementInstruction,\n);\n\n// Send the transaction\nconst transactionSignature = await sendAndConfirmTransaction(\n connection,\n transaction,\n [payer, counter],\n);\nconsole.log(\"Transaction Signature\", transactionSignature);\n\n// Fetch the counter account\nconst counterAccount = await program.account.counter.fetch(counter.publicKey);\nconsole.log(\"Count:\", counterAccount.count);PreviousClientsNextRustOn this pageClient ProgramInvoke InstructionsFetch AccountsExampleEdit on GitHub","tokens":2191,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257538933,"hash":"672238477fb1d1f8aee2de211247d389cb9a2166"}
{"url":"https://www.anchor-lang.com/docs/clients/rust","domain":"anchor-lang.com","title":"Rust","text":"Client LibrariesRustLearn how to use Anchor's Rust client library to interact with Solana programsThe anchor-client crate\nis the Rust client library for interacting with Anchor programs. You can find\nthe source code here.\nExample\nThe example below demonstrates how to use the anchor-client crate to interact\nwith a simple Anchor program. The program client can be automatically generated\nfrom the program's IDL using the declare_program! macro. This macro generates\ndependency free modules that enable you to interact with the program's\ninstructions and accounts.\nThe program has two instructions:\n\ninitialize – Creates and initializes a counter account to store a value\nincrement – Increments the value stored on the counter account\n\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"6khKp4BeJpCjBY1Eh39ybiqbfRnrn2UzWeUARjQLXYRC\");\n\n#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let counter = &ctx.accounts.counter;\n msg!(\"Counter account created! Current count: {}\", counter.count);\n Ok(())\n }\n\n pub fn increment(ctx: Context<Increment>) -> Result<()> {\n let counter = &mut ctx.accounts.counter;\n msg!(\"Previous counter: {}\", counter.count);\n\n counter.count += 1;\n msg!(\"Counter incremented! Current count: {}\", counter.count);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n\n #[account(\n init,\n payer = payer,\n space = 8 + 8\n )]\n pub counter: Account<'info, Counter>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct Increment<'info> {\n #[account(mut)]\n pub counter: Account<'info, Counter>,\n}\n\n#[account]\npub struct Counter {\n pub count: u64,\n}\nBelow is an example folder structure for a Rust client that interacts with the\nAnchor program:\nexample.jsonmain.rsCargo.toml\nThe program IDL must be in a /idls folder. The declare_program! macro\nsearches for the IDL in the /idls folder to generate the client modules.\nidls/example.json{\n \"address\": \"6khKp4BeJpCjBY1Eh39ybiqbfRnrn2UzWeUARjQLXYRC\",\n \"metadata\": {\n \"name\": \"example\",\n \"version\": \"0.1.0\",\n \"spec\": \"0.1.0\",\n \"description\": \"Created with Anchor\"\n },\n \"instructions\": [\n {\n \"name\": \"increment\",\n \"discriminator\": [11, 18, 104, 9, 104, 174, 59, 33],\n \"accounts\": [\n {\n \"name\": \"counter\",\n \"writable\": true\n }\n ],\n \"args\": []\n },\n {\n \"name\": \"initialize\",\n \"discriminator\": [175, 175, 109, 31, 13, 152, 155, 237],\n \"accounts\": [\n {\n \"name\": \"payer\",\n \"writable\": true,\n \"signer\": true\n },\n {\n \"name\": \"counter\",\n \"writable\": true,\n \"signer\": true\n },\n {\n \"name\": \"system_program\",\n \"address\": \"11111111111111111111111111111111\"\n }\n ],\n \"args\": []\n }\n ],\n \"accounts\": [\n {\n \"name\": \"Counter\",\n \"discriminator\": [255, 176, 4, 245, 188, 253, 124, 25]\n }\n ],\n \"types\": [\n {\n \"name\": \"Counter\",\n \"type\": {\n \"kind\": \"struct\",\n \"fields\": [\n {\n \"name\": \"count\",\n \"type\": \"u64\"\n }\n ]\n }\n }\n ]\n}\nBelow is the src/main.rs file for interacting with the program:\n\nThe declare_program! macro - Generates client modules for the program using\nthe IDL file\n\nThe anchor_client crate - Provides utilities for interacting with the\nprogram, including:\n\nBuilding program instructions\nSending transactions\nFetching program accounts\n\nsrc/main.rsuse anchor_client::{\n Client,\n Cluster,\n solana_sdk::{\n commitment_config::CommitmentConfig,\n native_token::LAMPORTS_PER_SOL,\n signature::{Keypair, Signer},\n system_program,\n },\n};\nuse anchor_lang::prelude::*;\nuse std::sync::Arc;\n\ndeclare_program!(example);\nuse example::{accounts::Counter, client::accounts, client::args};\n\n#[tokio::main]\nasync fn main() -> anyhow::Result<()> {\n // Generate Keypairs and request airdrop\n let payer = Arc::new(Keypair::new());\n let counter = Arc::new(Keypair::new());\n println!(\"Generated Keypairs:\");\n println!(\" Payer: {}\", payer.pubkey());\n println!(\" Counter: {}\", counter.pubkey());\n\n // Create program client\n let provider = Client::new_with_options(\n Cluster::Localnet,\n payer.clone(),\n CommitmentConfig::confirmed(),\n );\n let program = provider.program(example::ID)?;\n\n // Get RPC client from the program\n let rpc = program.rpc();\n\n println!(\"\\nRequesting 1 SOL airdrop to payer\");\n let airdrop_signature = rpc.request_airdrop(&payer.pubkey(), LAMPORTS_PER_SOL).await?;\n\n // Wait for airdrop confirmation\n rpc.confirm_transaction(&airdrop_signature).await?;\n\n // Wait for balance to be available\n loop {\n let balance = rpc.get_balance(&payer.pubkey()).await?;\n if balance > 0 {\n println!(\" Airdrop confirmed! Payer balance: {} lamports\", balance);\n break;\n }\n tokio::time::sleep(tokio::time::Duration::from_millis(100)).await;\n }\n\n // Build and send instructions\n println!(\"\\nSend transaction with initialize and increment instructions\");\n let initialize_ix = program\n .request()\n .accounts(accounts::Initialize {\n counter: counter.pubkey(),\n payer: program.payer(),\n system_program: system_program::ID,\n })\n .args(args::Initialize)\n .instructions()?\n .remove(0);\n\n let increment_ix = program\n .request()\n .accounts(accounts::Increment {\n counter: counter.pubkey(),\n })\n .args(args::Increment)\n .instructions()?\n .remove(0);\n\n let signature = program\n .request()\n .instruction(initialize_ix)\n .instruction(increment_ix)\n .signer(counter.clone())\n .send()\n .await?;\n println!(\" Transaction confirmed: {}\", signature);\n\n println!(\"\\nFetch counter account data\");\n let counter_account: Counter = program.account::<Counter>(counter.pubkey()).await?;\n println!(\" Counter value: {}\", counter_account.count);\n Ok(())\n}\nBelow are the dependencies for the Cargo.toml file:\nCargo.toml[package]\nname = \"rs\"\nversion = \"0.1.0\"\nedition = \"2021\"\n\n[dependencies]\nanchor-client = { version = \"1.2.0\", features = [\"async\"] }\nanchor-lang = \"1.2.0\"\nanyhow = \"1.0.93\"\ntokio = { version = \"1.0\", features = [\"full\"] }PreviousTypeScriptNextTestingOn this pageExampleEdit on GitHub","tokens":1458,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257550017,"hash":"c62e2af3cc0407b9c8be7a642c133d360ff877c1"}
{"url":"https://safeutils.openzeppelin.com/how-it-works","domain":"safeutils.openzeppelin.com","title":"Safe Utils | OpenZeppelin","text":"How It WorksPurpose and OriginSafe Hash Preview was created as a quick response to the WazirX, Radiant and Bybit exploits. The core script was developed by pcaversaccio, and we added a user-friendly interface to make it more accessible.This tool helps users verify Safe transaction hashes before signing them. It calculates the domain, message, and Safe transaction hashes by retrieving transaction details from either manual input or the Safe transaction service API and computing the hashes using the EIP-712 standard.How to UseChoose the calculation method, defaults to Manual Input. Alternative you can use Safe's API which requires less input.Select a network from the dropdown menu.Enter the Safe address.Fill the rest of the data according to your selected method.Click \"Calculate Hashes\" to view the results.Compare the displayed hashes with those shown on your signing device.How Hashes are CalculatedThe hashes are calculated using these steps:Collect transaction details either from input or Safe's API.Calculate the domain hash using the chain ID and Safe address.Calculate the message hash using the transaction details.Compute the Safe transaction hash using the domain and message hashes.The script uses the EIP-712 standard and the same type hashes as the Safe contracts to ensure accuracy.What to Look ForEnsure that hashes match the ones displayed on your signing device.If you see more than one transaction with the same nonce, ensure it is exclusively because you're trying to replace a transaction. If this is not the case, something unintended is happening.Tips for Enhanced SecurityRun LocallyFor maximum security, clone the repository and run this tool locally disconnected from the internet.Multi-Device VerificationCross-check results using different devices and browsers to ensure consistency and reduce risk of compromised environments.Self-HostFor frequent use, consider self-hosting this tool on your own infrastructure to minimize dependencies on third-party services.Supported NetworksThe app supports multiple networks, including Ethereum, Polygon, Arbitrum, and more. For a full list of supported networks, please refer to the network selection dropdown on the main page.","tokens":551,"squid":"ink-security_audits","role":"Sentinel","at":1791257561052,"hash":"8c3dad6333384f79541c22372e5180def44b2ed4"}
{"url":"https://docs.pyth.network/price-feeds/pro/subscribe-to-prices","domain":"docs.pyth.network","title":"Subscribe to Prices | Pyth Developer Hub","text":"Pyth ProSubscribe to PricesLearn how to authenticate, configure, and subscribe to Pyth Pro price streamsThis guide explains how to subscribe to prices from Pyth Pro.\nThis guide will also explain various properties and configuration options to customize the prices.\nThe return data also includes verified payloads that can be verified on the target blockchain.\nSubscribing to prices is a three-step process:\n\nAcquire an API key.\nConfigure subscription parameters.\nSubscribe to the prices via websocket API.\n\nThe websocket servers are available at:\n\nwss://pyth-lazer-0.dourolabs.app/v1/stream\nwss://pyth-lazer-1.dourolabs.app/v1/stream\nwss://pyth-lazer-2.dourolabs.app/v1/stream\n\nRedundancy RequiredFor redundancy and to avoid interruptions during deployments, you must connect\nto all endpoints. During deployments, a single endpoint will briefly go\ndown, so maintaining open connections to all endpoints ensures continuous\nservice availability.\n1. Acquire an API keyFollow the steps we've outlined in the Acquire an API key section.The websocket connection is authenticated with an Authorization header of the form Bearer {token}. Two kinds of tokens are accepted:\nYour long-lived Pro API key. Prefer this for server-to-server integrations.\nA short-lived JWT minted from that key via POST /auth/token. Prefer this when the connecting client should not hold the raw key. See Frontend Authentication for the full flow.\nPass the API key directly as the bearer value:Authorization: Bearer <PRO_API_KEY>Security Warning: Never expose your API key in frontend applications\nor client-side code. API keys should only be used in secure backend\nenvironments. Exposing keys in frontend code makes them publicly accessible\nand is a violation of our terms of service.A browser can't set request headers on a WebSocket. For frontend apps, mint a short-lived JWT (see Frontend Authentication) and pass it through the subprotocol list — the marker pyth-lazer-auth immediately followed by the token:const ws = new WebSocket(\n \"wss://pyth-lazer-0.dourolabs.app/v1/stream\",\n [\"pyth-lazer-auth\", \"<JWT>\"],\n);The server reads the token from that value and echoes the pyth-lazer-auth subprotocol back to finish the handshake.2. Configure subscription parametersPyth Pro supports several request/subscription parameters to customize the received prices.\nThese parameters are configured by sending a subscription message to the webservice.\nA sample request (using the Lazer SDK client -- see step 3) is shown below:client.send({\n type: \"subscribe\",\n subscriptionId: 1,\n priceFeedIds: [1, 2],\n properties: [\"price\", \"feedUpdateTimestamp\"],\n formats: [\"solana\"],\n channel: \"fixed_rate@200ms\",\n ignoreInvalidFeeds: true,\n});The most significant parameters are:\nsubscriptionId is an arbitrary numeric identifier for a subscription. It will be returned back in response by the server. It does not affect the signed payload.\npriceFeedIds is the list of price feeds to receive price data for. It will also include the verified payloads for the price feeds. Refer to the Price Feed IDs list for the supported price feeds.\nproperties is the list of properties to retrieve, such as price, bestBidPrice, bestAskPrice, etc.\nRecommended: Include feedUpdateTimestampFor production applications, include \"feedUpdateTimestamp\" in your\nproperties array. This field lets you determine whether a price was freshly\ngenerated or carried forward from an earlier update. Compare it against\ntimestampUs to assess price freshness. See Payload Reference — Price\nAvailability\nSemantics for\ndetails.\n\nformats(formerly known as chains) specifies the binary encoding format for the payload. This field is mandatory, but can be set to an empty array (e.g., formats: []) if no binary payload is needed. Use evm or solana to receive a signed payload for onchain verification, or leUnsigned for offchain-only use without signatures. See Binary Formats & Signature Schemes for all options.\n\nchannel determines the update rate. Pyth Pro offers the following channels:\nChannelDescriptionreal_timeUpdates sent immediately when new price is available (no faster than 1ms, no slower than 50ms)fixed_rate@1msUpdates every 1 millisecondfixed_rate@50msUpdates every 50 millisecondsfixed_rate@200msUpdates every 200 millisecondsfixed_rate@1000msUpdates every 1 second\nPer-Feed Channel AvailabilityNot every feed supports every channel. Each feed has a minimum channel\n(min_channel) — it supports that channel and all slower channels. Check the\nPrice Feed IDs page to see which channels\nare available for each feed.\n\nignoreInvalidFeeds (optional, default: false) — if true, the subscription will ignore invalid feed IDs and subscribe to any valid feeds. The response will include details about which feeds were ignored and why. If all feeds are invalid, the subscription will still fail with a subscriptionError. See Error Codes for the response format.\n\nRecommended for production: set ignoreInvalidFeeds: trueFeed IDs can become invalid over time — for example, when a feed is retired or\nan equity is delisted. By default (ignoreInvalidFeeds: false), a single\ninvalid feed in your subscription request will cause the entire\nsubscription to fail with a subscriptionError, dropping all your other valid\nfeeds along with it. Setting ignoreInvalidFeeds: true makes your subscription\nresilient: invalid feeds are skipped and reported in the response, while valid\nfeeds continue to stream uninterrupted. Inspect the response to learn which\nfeeds were dropped and why, then update your subscription accordingly.There are also a few other configuration parameters -- see the API documentation for more details.Determine the most suitable values for your application -- they will be used in the next step.3. Subscribe to the pricesComplete Payload ReferenceFor understanding all fields and data types of Lazer payloads, see our\nPayload Reference page.To subscribe to the prices, send a request to the websocket server. The server will respond with a signed payload.\nPyth Lazer provides an SDK to seamlessly integrate the websocket API into your application.\nInstall it using the following command:\nnpm install --save @pythnetwork/pyth-lazer-sdk\nThen create a PythLazerClient object using the endpoint URLs and a credential from the first step. The token field accepts either your Pro API key or a short-lived JWT:\nimport { PythLazerClient } from \"@pythnetwork/pyth-lazer-sdk\";\n\nconst client = await PythLazerClient.create({\n token: process.env.ACCESS_TOKEN,\n webSocketPoolConfig: {\n urls: [\n \"wss://pyth-lazer-0.dourolabs.app/v1/stream\",\n \"wss://pyth-lazer-1.dourolabs.app/v1/stream\",\n \"wss://pyth-lazer-2.dourolabs.app/v1/stream\",\n ],\n },\n});\nAfter the client is created, subscribe to prices (using the configuration parameters from step 2):\nclient.subscribe({\n type: \"subscribe\",\n subscriptionId: 1,\n priceFeedIds: [1, 2],\n properties: [\"price\", \"feedUpdateTimestamp\"],\n formats: [\"solana\"],\n channel: \"fixed_rate@200ms\",\n ignoreInvalidFeeds: true,\n});\nOnce the connection is established, the server will start sending the price and verified payloads to the client:\nclient.addMessageListener((message) => {\n console.log(message);\n});By default, verified payloads contain the parsed field that one can use to easily interpret the price data in their backend or frontend, as well as evm and/or solana fields that contain data that one should include in the on-chain transaction:{\n \"type\": \"streamUpdated\",\n \"subscriptionId\": 1,\n \"parsed\": {\n \"timestampUs\": \"1730986152400000\",\n \"priceFeeds\": [\n {\n \"priceFeedId\": 1,\n \"price\": \"1006900000000\",\n \"feedUpdateTimestamp\": 1730986152400000\n },\n {\n \"priceFeedId\": 2,\n \"price\": \"2006900000000\",\n \"feedUpdateTimestamp\": 1730986152400000\n }\n ]\n },\n \"solana\": {\n \"encoding\": \"hex\",\n \"data\": \"b9011a82d239c094c52016990d6ca2b261dbb1157ad503cbd3ea0679493316150cf3457624d19ec3f6e0a0e94373ab0971e39d939beda15cc02eb3c5454eb700f1f7310df65210bee4fcf5b1cee1e537fabcfd95010297653b94af04d454fc473e94834f2a0075d3c7938094b99e52260600030201000000010000b5ea6fea00000002000000010000c58f44d3010000\"\n }\n}\nAdditional Resources\nYou may find these additional resources helpful for subscribing to prices from Pyth Pro.\nPrice Feed IDs\nPyth Pro supports a wide range of price feeds. Consult the Price Feed IDs page for a complete list of supported price feeds.\nExamples\npyth-lazer-example-js is a simple example for subscribing to the Pyth Pro websocket.Frontend AuthenticationUse short-lived tokens to call Pyth Pro from browser appsIntegrate prices on blockchainLearn how to integrate Pyth Pro prices on blockchain","tokens":2139,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257568618,"hash":"dac736ec180f79e20f6bb61d2280c45c1b46e444"}
{"url":"https://www.anchor-lang.com/docs/basics/program-structure","domain":"anchor-lang.com","title":"Program Structure","text":"The BasicsProgram StructureLearn about the structure of Anchor programs, including key macros and their roles in simplifying Solana program developmentThe Anchor framework uses\nRust macros to reduce\nboilerplate code and simplify the implementation of common security checks\nrequired for writing Solana programs.\nThe main macros found in an Anchor program include:\n\ndeclare_id: Specifies the program's on-chain address\n#[program]: Specifies the module containing the\nprogram’s instruction logic\n#[derive(Accounts)]: Applied to structs to indicate\na list of accounts required by an instruction\n#[account]: Applied to structs to create custom\naccount types for the program\n\nExample Program\nLet's examine a simple program that demonstrates the usage of the macros\nmentioned above to understand the basic structure of an Anchor program.\nThe program below includes a single instruction called initialize that creates\na new account (NewAccount) and initializes it with a u64 value.\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"11111111111111111111111111111111\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64,\n}\ndeclare_id! macro\nThe\ndeclare_id\nmacro specifies the on-chain address of the program, known as the program ID.\nYou can find the implementation of the code generated by the declare_id! macro\nhere.\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"11111111111111111111111111111111\");\nBy default, the program ID is the public key of the keypair generated at\n/target/deploy/your_program_name.json.\nTo update the value of the program ID in the declare_id macro with the public\nkey of the keypair in the /target/deploy/your_program_name.json file, run the\nfollowing command:\nTerminalanchor keys sync\nThe anchor keys sync command is useful to run when cloning a repository where\nthe value of the program ID in a cloned repo's declare_id macro won't match\nthe one generated when you run anchor build locally.\n#[program] attribute\nThe\n#[program]\nattribute annotates the module containing all the instruction handlers for your\nprogram. Each public function within this module corresponds to an instruction\nthat can be invoked.\nYou can find the implementation of the code generated by the #[program]\nattribute\nhere.\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"11111111111111111111111111111111\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64,\n}\nInstruction Context\nInstruction handlers are functions that define the logic executed when an\ninstruction is invoked. The first parameter of each handler is a Context<T>\ntype, where T is a struct implementing the\nAccounts\ntrait and specifies the accounts the instruction requires.\nThe\nContext\ntype provides the instruction with access to the following non-argument inputs:\npub struct Context<'info, T: Bumps> {\n /// Currently executing program id.\n pub program_id: &'info Pubkey,\n /// Deserialized accounts.\n pub accounts: &'info mut T,\n /// Remaining accounts given but not deserialized or validated.\n /// Be very careful when using this directly.\n pub remaining_accounts: &'info [AccountInfo<'info>],\n /// Bump seeds found during constraint validation. This is provided as a\n /// convenience so that handlers don't have to recalculate bump seeds or\n /// pass them in as arguments.\n /// Type is the bumps struct generated by #[derive(Accounts)]\n pub bumps: T::Bumps,\n}\nThe Context fields can be accessed in an instruction using dot notation:\n\nctx.accounts: The accounts required for the instruction\nctx.program_id: The program's public key (address)\nctx.remaining_accounts: Additional accounts not specified in the Accounts\nstruct.\nctx.bumps: Bump seeds for any Program Derived Address (PDA) accounts\nspecified in the Accounts struct\n\nAdditional parameters are optional and can be included to specify arguments that\nmust be provided when the instruction is invoked.\nlib.rspub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n}\nIn this example, the Initialize struct implements the Accounts trait where\neach field in the struct represents an account required by the initialize\ninstruction.\nlib.rs#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n#[derive(Accounts)] macro\nThe\n#[derive(Accounts)]\nmacro is applied to a struct to specify the accounts that must be provided when\nan instruction is invoked. This macro implements the\nAccounts\ntrait, which simplifies account validation and serialization and deserialization\nof account data.\nYou can find the implementation of the code generated by the\n#[derive(Accounts)] macro\nhere.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\nEach field in the struct represents an account required by an instruction. The\nnaming of each field is arbitrary, but it is recommended to use a descriptive\nname that indicates the purpose of the account.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\nAccount Validation\nTo prevent security vulnerabilities, it's important to verify that accounts\nprovided to an instruction are the expected accounts. Accounts are validated in\nAnchor programs in two ways that are generally used together:\n\nAccount Constraints: Constraints\ndefine additional conditions that an account must satisfy to be considered\nvalid for the instruction. Constraints are applied using the #[account(..)]\nattribute, which is placed above a field in a struct that implements the\nAccounts trait.\nYou can find a full list of the constraints\nhere\nand implementation\nhere.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\nAccount Types: Anchor provides various\naccount types to help ensure that the account provided by the client matches\nwhat the program expects.\nYou can find the implementation of the account types\nhere.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\nWhen an instruction in an Anchor program is invoked, the program first validates\nthe accounts provided before executing the instruction's logic. After\nvalidation, these accounts can be accessed within the instruction using the\nctx.accounts syntax.\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"11111111111111111111111111111111\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64,\n}\n#[account] attribute\nThe\n#[account]\nattribute is applied to structs that define the structure of the data stored in\ncustom accounts created by your program.\n#[account]\npub struct NewAccount {\n data: u64,\n}\nThis macro implements various traits\ndetailed here.\nThe key functionalities of the #[account] macro include:\n\nAssign Program Owner:\nWhen creating an account, the program owner of the account is automatically\nset to the program specified in declare_id.\nSet Discriminator:\nA unique 8 byte discriminator, specific to the account type, is added as the\nfirst 8 bytes of account data during its initialization. This helps in\ndifferentiating account types and is used for account validation.\nData Serialization and Deserialization:\nAccount data is automatically serialized and deserialized as the account type.\n\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"11111111111111111111111111111111\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64,\n}\nAccount Discriminator\nAn account discriminator in an Anchor program refers to an 8 byte identifier\nunique to each account type. You can find the implementation of the account\ndiscriminator\nhere.\nThe discriminator is the first 8 bytes of the SHA256 hash of the string\naccount:<AccountName>. This discriminator is stored as the first 8 bytes of\naccount data when an account is created.\nWhen creating an account in an Anchor program, 8 bytes must be allocated for the\ndiscriminator.\n#[account(init, payer = signer, space = 8 + 8)]\npub new_account: Account<'info, NewAccount>,\nThe discriminator is used during the following two scenarios:\n\nInitialization: When an account is created, the discriminator is set as the\nfirst 8 bytes of the account's data.\nDeserialization: When account data is deserialized, the first 8 bytes of\naccount data is checked against the discriminator of the expected account\ntype.\n\nIf there's a mismatch, it indicates that the client has provided an unexpected\naccount. This mechanism serves as an account validation check in Anchor\nprograms.PreviousAnchor Framework BasicsNextProgram IDL FileOn this pageExample Programdeclare_id! macro#[program] attributeInstruction Context#[derive(Accounts)] macroAccount Validation#[account] attributeAccount DiscriminatorEdit on GitHub","tokens":2832,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257575773,"hash":"3df1b566428e359213e41568dedff09517dc4714"}
{"url":"https://docs.pyth.network/price-feeds/pro/acquire-api-key","domain":"docs.pyth.network","title":"Acquire an API Key | Pyth Developer Hub","text":"Pyth ProAcquire an API KeyRequest and manage API keys for Pyth ProThis guide explains how to acquire an API key for Pyth Pro, which is required to authenticate websocket connections and authenticated HTTP endpoints (the History and REST APIs) and subscribe to price updates.\nRequest API Key\nSign up for a free Pyth Terminal account.\nOnce you have logged in, click on the 🔑 View your API key button to obtain your API key.\nAPI keys are required for Pyth Pro websocket connections and for authenticated\nHTTP endpoints. Make sure to keep your key secure and do not share it publicly.\nUsing the API Key\nOnce you receive your API key, use it to authenticate the websocket connection by passing it as an Authorization header with the value Bearer {key}.\nExample Usage\nimport { PythLazerClient } from \"@pythnetwork/pyth-lazer-sdk\";\n\nconst client = await PythLazerClient.create(\n [\n \"wss://pyth-lazer-0.dourolabs.app/v1/stream\",\n \"wss://pyth-lazer-1.dourolabs.app/v1/stream\",\n \"wss://pyth-lazer-2.dourolabs.app/v1/stream\",\n ],\n \"YOUR_API_KEY\",\n);\nThe same Authorization: Bearer <PRO_API_KEY> header authenticates the\nHistory and REST\nHTTP endpoints. For example, against the History API:\ncurl -H \"Authorization: Bearer $PRO_API_KEY\" \\\n \"https://pyth.dourolabs.app/v1/fixed_rate@200ms/price?ids=1&timestamp=1704067200000000\"\nBrowser and frontend apps must not embed the key — route requests through your\nown backend, which injects the header before forwarding, or use the short-lived\nJWT flow described in\nFrontend Authentication. See the\nAuthentication sections on the\nHistory and\nREST API pages for full details.\nNext Steps\n\nSubscribe to price feeds using the Pyth Pro websocket API.\nFor browser/frontend apps, follow Frontend Authentication to hand out short-lived JWTs instead of embedding the API key.\nPyth TerminalExplore Pyth price feeds, get a free API key, and trial Pyth Pro from your browserFrontend AuthenticationUse short-lived tokens to call Pyth Pro from browser apps","tokens":494,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257578502,"hash":"ba35af3bbd573b0897852b1aa86e70b62371351a"}
{"url":"https://www.anchor-lang.com/docs/testing/mollusk","domain":"anchor-lang.com","title":"Mollusk","text":"Testing LibrariesMolluskWrite tests for Solana programs in Rust using Mollusk.Mollusk is a lightweight test harness for\nSolana programs. It provides a simple interface for testing Solana program\nexecutions in a minified Solana Virtual Machine (SVM) environment.\nmollusk.process_and_validate_instruction(\n &instruction, // <-- Instruction to test\n &accounts, // <-- Account states\n &checks, // <-- Checks to run on the instruction result\n);\nIt does not create any semblance of a validator runtime, but instead provisions\na program execution pipeline directly from lower-level SVM components.\nIn summary, the main processor - process_instruction - creates minified\ninstances of Agave's program cache, transaction context, and invoke context. It\nuses these components to directly execute the provided program's ELF using the\nBPF Loader.\nBecause it does not use AccountsDB, Bank, or any other large Agave components,\nthe harness is exceptionally fast. However, it does require the user to provide\nan explicit list of accounts to use, since it has nowhere to load them from.\nThe test environment can be further configured by adjusting the compute budget,\nfeature set, or sysvars. These configurations are stored directly on the test\nharness (the Mollusk struct), but can be manipulated through a handful of\nhelpers.\nFour main API methods are offered:\n\nprocess_instruction: Process an instruction and return the result.\nprocess_and_validate_instruction: Process an instruction and perform a\nseries of checks on the result, panicking if any checks fail.\nprocess_instruction_chain: Process a chain of instructions and return the\nresult.\nprocess_and_validate_instruction_chain: Process a chain of instructions and\nperform a series of checks on each result, panicking if any checks fail.\n\nSingle Instructions\nBoth process_instruction and process_and_validate_instruction deal with\nsingle instructions. The former simply processes the instruction and returns the\nresult, while the latter processes the instruction and then performs a series of\nchecks on the result. In both cases, the result is also returned.\nuse {\n mollusk_svm::Mollusk,\n solana_account::Account,\n solana_sdk::{instruction::{AccountMeta, Instruction}, pubkey::Pubkey},\n};\n\nlet program_id = Pubkey::new_unique();\nlet key1 = Pubkey::new_unique();\nlet key2 = Pubkey::new_unique();\n\nlet instruction = Instruction::new_with_bytes(\n program_id,\n &[],\n vec![\n AccountMeta::new(key1, false),\n AccountMeta::new_readonly(key2, false),\n ],\n);\n\nlet accounts = vec![\n (key1, Account::default()),\n (key2, Account::default()),\n];\n\nlet mollusk = Mollusk::new(&program_id, \"my_program\");\n\n// Execute the instruction and get the result.\nlet result = mollusk.process_instruction(&instruction, &accounts);\nTo apply checks via process_and_validate_instruction, developers can use the\nCheck enum, which provides a set of common checks.\nuse {\n mollusk_svm::{Mollusk, result::Check},\n solana_account::Account,\n solana_sdk::{\n instruction::{AccountMeta, Instruction},\n pubkey::Pubkey\n system_instruction,\n system_program,\n },\n};\n\nlet sender = Pubkey::new_unique();\nlet recipient = Pubkey::new_unique();\n\nlet base_lamports = 100_000_000u64;\nlet transfer_amount = 42_000u64;\n\nlet instruction = system_instruction::transfer(&sender, &recipient, transfer_amount);\nlet accounts = [\n (\n sender,\n Account::new(base_lamports, 0, &system_program::id()),\n ),\n (\n recipient,\n Account::new(base_lamports, 0, &system_program::id()),\n ),\n];\nlet checks = vec![\n Check::success(),\n Check::compute_units(system_processor::DEFAULT_COMPUTE_UNITS),\n Check::account(&sender)\n .lamports(base_lamports - transfer_amount)\n .build(),\n Check::account(&recipient)\n .lamports(base_lamports + transfer_amount)\n .build(),\n];\n\nMollusk::default().process_and_validate_instruction(\n &instruction,\n &accounts,\n &checks,\n);\nNote: Mollusk::default() will create a new Mollusk instance without adding\nany provided BPF programs. It will still contain a subset of the default builtin\nprograms. For more builtin programs, you can add them yourself or use the\nall-builtins feature.\nInstruction Chains\nBoth process_instruction_chain and process_and_validate_instruction_chain\ndeal with chains of instructions. The former processes each instruction in the\nchain and returns the final result, while the latter processes each instruction\nin the chain and then performs a series of checks on each result. In both cases,\nthe final result is also returned.\nuse {\n mollusk_svm::Mollusk,\n solana_account::Account,\n solana_sdk::{pubkey::Pubkey, system_instruction},\n};\n\nlet mollusk = Mollusk::default();\n\nlet alice = Pubkey::new_unique();\nlet bob = Pubkey::new_unique();\nlet carol = Pubkey::new_unique();\nlet dave = Pubkey::new_unique();\n\nlet starting_lamports = 500_000_000;\n\nlet alice_to_bob = 100_000_000;\nlet bob_to_carol = 50_000_000;\nlet bob_to_dave = 50_000_000;\n\nmollusk.process_instruction_chain(\n &[\n system_instruction::transfer(&alice, &bob, alice_to_bob),\n system_instruction::transfer(&bob, &carol, bob_to_carol),\n system_instruction::transfer(&bob, &dave, bob_to_dave),\n ],\n &[\n (alice, system_account_with_lamports(starting_lamports)),\n (bob, system_account_with_lamports(starting_lamports)),\n (carol, system_account_with_lamports(starting_lamports)),\n (dave, system_account_with_lamports(starting_lamports)),\n ],\n);\nJust like with process_and_validate_instruction, developers can use the\nCheck enum to apply checks via process_and_validate_instruction_chain.\nNotice that process_and_validate_instruction_chain takes a slice of tuples,\nwhere each tuple contains an instruction and a slice of checks. This allows the\ndeveloper to apply specific checks to each instruction in the chain. The result\nreturned by the method is the final result of the last instruction in the chain.\nuse {\n mollusk_svm::{Mollusk, result::Check},\n solana_account::Account,\n solana_sdk::{pubkey::Pubkey, system_instruction},\n};\n\nlet mollusk = Mollusk::default();\n\nlet alice = Pubkey::new_unique();\nlet bob = Pubkey::new_unique();\nlet carol = Pubkey::new_unique();\nlet dave = Pubkey::new_unique();\n\nlet starting_lamports = 500_000_000;\n\nlet alice_to_bob = 100_000_000;\nlet bob_to_carol = 50_000_000;\nlet bob_to_dave = 50_000_000;\n\nmollusk.process_and_validate_instruction_chain(\n &[\n (\n // 0: Alice to Bob\n &system_instruction::transfer(&alice, &bob, alice_to_bob),\n &[\n Check::success(),\n Check::account(&alice)\n .lamports(starting_lamports - alice_to_bob) // Alice pays\n .build(),\n Check::account(&bob)\n .lamports(starting_lamports + alice_to_bob) // Bob receives\n .build(),\n Check::account(&carol)\n .lamports(starting_lamports) // Unchanged\n .build(),\n Check::account(&dave)\n .lamports(starting_lamports) // Unchanged\n .build(),\n ],\n ),\n (\n // 1: Bob to Carol\n &system_instruction::transfer(&bob, &carol, bob_to_carol),\n &[\n Check::success(),\n Check::account(&alice)\n .lamports(starting_lamports - alice_to_bob) // Unchanged\n .build(),\n Check::account(&bob)\n .lamports(starting_lamports + alice_to_bob - bob_to_carol) // Bob pays\n .build(),\n Check::account(&carol)\n .lamports(starting_lamports + bob_to_carol) // Carol receives\n .build(),\n Check::account(&dave)\n .lamports(starting_lamports) // Unchanged\n .build(),\n ],\n ),\n (\n // 2: Bob to Dave\n &system_instruction::transfer(&bob, &dave, bob_to_dave),\n &[\n Check::success(),\n Check::account(&alice)\n .lamports(starting_lamports - alice_to_bob) // Unchanged\n .build(),\n Check::account(&bob)\n .lamports(starting_lamports + alice_to_bob - bob_to_carol - bob_to_dave) // Bob pays\n .build(),\n Check::account(&carol)\n .lamports(starting_lamports + bob_to_carol) // Unchanged\n .build(),\n Check::account(&dave)\n .lamports(starting_lamports + bob_to_dave) // Dave receives\n .build(),\n ],\n ),\n ],\n &[\n (alice, system_account_with_lamports(starting_lamports)),\n (bob, system_account_with_lamports(starting_lamports)),\n (carol, system_account_with_lamports(starting_lamports)),\n (dave, system_account_with_lamports(starting_lamports)),\n ],\n);\nIt's important to understand that instruction chains should not be considered\nequivalent to Solana transactions. Mollusk does not impose constraints on\ninstruction chains, such as loaded account keys or size. Developers should\nrecognize that instruction chains are primarily used for testing program\nexecution.\nBenchmarking Compute Units\nThe Mollusk Compute Unit Bencher can be used to benchmark the compute unit usage\nof Solana programs. It provides a simple API for developers to write benchmarks\nfor their programs, which can be checked while making changes to the program.\nA markdown file is generated, which captures all of the compute unit benchmarks.\nIf a benchmark has a previous value, the delta is also recorded. This can be\nuseful for developers to check the implications of changes to the program on\ncompute unit usage.\nuse {\n mollusk_svm_bencher::MolluskComputeUnitBencher,\n mollusk_svm::Mollusk,\n /* ... */\n};\n\n// Optionally disable logging.\nsolana_logger::setup_with(\"\");\n\n/* Instruction & accounts setup ... */\n\nlet mollusk = Mollusk::new(&program_id, \"my_program\");\n\nMolluskComputeUnitBencher::new(mollusk)\n .bench((\"bench0\", &instruction0, &accounts0))\n .bench((\"bench1\", &instruction1, &accounts1))\n .bench((\"bench2\", &instruction2, &accounts2))\n .bench((\"bench3\", &instruction3, &accounts3))\n .must_pass(true)\n .out_dir(\"../target/benches\")\n .execute();\nThe must_pass argument can be provided to trigger a panic if any defined\nbenchmark tests do not pass. out_dir specifies the directory where the\nmarkdown file will be written.\nDevelopers can invoke this benchmark test with cargo bench. They may need to\nadd a bench to the project's Cargo.toml.\n[[bench]]\nname = \"compute_units\"\nharness = false\nThe markdown file will contain entries according to the defined benchmarks.\n| Name | CUs | Delta |\n| ------ | ----- | ------ |\n| bench0 | 450 | -- |\n| bench1 | 579 | -129 |\n| bench2 | 1,204 | +754 |\n| bench3 | 2,811 | +2,361 |PreviousLiteSVMNextFuzzingOn this pageSingle InstructionsInstruction ChainsBenchmarking Compute UnitsEdit on GitHub","tokens":2504,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257590398,"hash":"266f29601eb3c8b0f84b64d7993107a6ab7c9b08"}
{"url":"https://docs.pyth.network/price-feeds/core","domain":"docs.pyth.network","title":"Pyth Core | Pyth Developer Hub","text":"Pyth CoreIntroduction to Pyth Core Price FeedsPyth Network provides real-time financial market data to smart contract applications on 100+ blockchains.\nData is sourced from 120+ first-party providers including major exchanges and market makers.\nPyth Core Products\nPyth Core provides two ways to integrate and consume real-time price data on-chain:\nIntegrate Pull Updates Update 2000+ prices on-demand, permissionlessly every 400ms.Integrate Push Updates Consume Pyth real-time prices without pulling them explicitly.\nPyth Core also supports parsing historical price data on-chain for\nsettlement and backtesting:\nHistorical Price Data Access to historical price data for settlement and backtesting.\nQuick Start\nGetting Started Get started with Pyth Core.Contract Addresses Find official Pyth contract addresses per network.API Reference Review Core API endpoints and parameters.Price Feed IDs Browse canonical Pyth price feed identifiers.Push FeedsGetting StartedExplore key resources to begin integrating Pyth price feeds","tokens":255,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257590447,"hash":"235fe0aa50bab8cc1268211f39bc35550824695f"}
{"url":"https://www.openzeppelin.com/customer-stories","domain":"openzeppelin.com","title":"OpenZeppelin | Customer Stories","text":"Customer StoriesTrusted by leading Financial Institutions, DeFi Protocols, and Blockchain InnovatorsCrédit Agricole CACEISOpenZeppelin secures CACEIS Bank euro stablecoin EURXT, ahead of issuance under MiCA0 Critical, High or Medium Severity Issues18 Findings & Recommendations Delivered48 Hours From Review to Initial ReportWisdomTreeOpenZeppelin audits WisdomTree's smart contracts for tokenized funds across Ethereum and Solana4 Critical Findings Resolved Before Deployment$790M in Tokenized Fund Assets OnchainUSDT0USDT0 secures the expansion of the world's largest stablecoin with OpenZeppelin110 Total Issues Uncovered0 Security Incidents Since Launch20+ Networks Secured$250 Billion+ in Digital Assets Secured 10,000+ Total Issues Uncovered 700+ Critical & High Vulnerabilities Uncovered All Customer StoriesOpenZeppelin secures CACEIS Bank euro stablecoin EURXT, ahead of issuance under MiCARead storyOpenZeppelin audits WisdomTree's smart contracts for tokenized funds across Ethereum and SolanaRead storyUniswap v4 launches successfully after OpenZeppelin's comprehensive security reviewRead storyUSDT0 secures the expansion of the world's largest stablecoin with OpenZeppelinRead storyZKsync's continuous ZK innovation success secured by 3+ years of partnership with OpenZeppelinRead storyLinea launches Ethereum-equivalent zkEVM layer 2 with OpenZeppelin's continuous securityRead storyAcross secures crosschain expansion from Ethereum to Solana with OpenZeppelinRead storyHow Starknet built a thriving DeFi ecosystem with OpenZeppelin's open source developer stackRead storyTaiko launches first based rollup on Ethereum with OpenZeppelinRead storyThe security standard for onchain financeTalk to an Expert","tokens":430,"squid":"ink-security_audits","role":"Sentinel","at":1791257594061,"hash":"7397b4424e0300765f3d4b2fc81ff57a4e901058"}
{"url":"https://www.anchor-lang.com/docs/testing/litesvm","domain":"anchor-lang.com","title":"LiteSVM","text":"Testing LibrariesLiteSVMWrite tests for Solana programs in Rust, TS/JS or Python using LiteSVM.Overview\nlitesvm is a fast and lightweight library for testing Solana programs.\nIt works by creating an in-process Solana VM optimized for program developers.\nThis makes it much faster to run and compile than alternatives like solana-program-test and solana-test-validator.\nlitesvm is available in Rust, TS/JS and Python (as part of the solders library).\nInstallation\n\ncargo add litesvm --dev\nMinimal Example\nuse litesvm::LiteSVM;\nuse solana_message::Message;\nuse solana_pubkey::Pubkey;\nuse solana_system_interface::instruction::transfer;\nuse solana_keypair::Keypair;\nuse solana_signer::Signer;\nuse solana_transaction::Transaction;\n\nlet from_keypair = Keypair::new();\nlet from = from_keypair.pubkey();\nlet to = Pubkey::new_unique();\n\nlet mut svm = LiteSVM::new();\nsvm.airdrop(&from, 10_000).unwrap();\n\nlet instruction = transfer(&from, &to, 64);\nlet tx = Transaction::new(\n &[&from_keypair],\n Message::new(&[instruction], Some(&from)),\n svm.latest_blockhash(),\n);\nlet tx_res = svm.send_transaction(tx).unwrap();\n\nlet from_account = svm.get_account(&from);\nlet to_account = svm.get_account(&to);\nassert_eq!(from_account.unwrap().lamports, 4936);\nassert_eq!(to_account.unwrap().lamports, 64);\nDeploying Programs\nMost of the time we want to do more than just mess around with token transfers -\nwe want to test our own programs.\nTip: if you want to pull a Solana program from mainnet or devnet, use the solana program dump command from the Solana CLI.\nTo add a compiled program to our tests we can use .add_program_from_file.\nHere's an example using a simple program\nfrom the Solana Program Library that just does some logging:\nuse {\n litesvm::LiteSVM,\n solana_instruction::{account_meta::AccountMeta, Instruction},\n solana_keypair::Keypair,\n solana_pubkey::{pubkey, Pubkey},\n solana_message::{Message, VersionedMessage},\n solana_signer::Signer,\n solana_transaction::VersionedTransaction,\n};\n\nfn test_logging() {\n let program_id = pubkey!(\"Logging111111111111111111111111111111111111\");\n let account_meta = AccountMeta {\n pubkey: Pubkey::new_unique(),\n is_signer: false,\n is_writable: true,\n };\n let ix = Instruction {\n program_id,\n accounts: vec![account_meta],\n data: vec![5, 10, 11, 12, 13, 14],\n };\n let mut svm = LiteSVM::new();\n let payer = Keypair::new();\n let bytes = include_bytes!(\"../../node-litesvm/program_bytes/spl_example_logging.so\");\n svm.add_program(program_id, bytes);\n svm.airdrop(&payer.pubkey(), 1_000_000_000).unwrap();\n let blockhash = svm.latest_blockhash();\n let msg = Message::new_with_blockhash(&[ix], Some(&payer.pubkey()), &blockhash);\n let tx = VersionedTransaction::try_new(VersionedMessage::Legacy(msg), &[payer]).unwrap();\n // let's sim it first\n let sim_res = svm.simulate_transaction(tx.clone()).unwrap();\n let meta = svm.send_transaction(tx).unwrap();\n assert_eq!(sim_res.meta, meta);\n assert_eq!(meta.logs[1], \"Program log: static string\");\n assert!(meta.compute_units_consumed < 10_000) // not being precise here in case it changes\n}\nTime travel\nMany programs rely on the Clock sysvar: for example, a mint that doesn't become available until after\na certain time. With litesvm you can dynamically overwrite the Clock sysvar\nusing svm.set_sysvar::<Clock>()\n(or .setClock in TS, or .set_clock in Python).\nHere's an example using a program that panics if clock.unix_timestamp is greater than 100\n(which is on January 1st 1970):\nuse {\n litesvm::LiteSVM,\n solana_clock::Clock,\n solana_instruction::Instruction,\n use solana_keypair::Keypair,\n solana_message::{Message, VersionedMessage},\n solana_pubkey::Pubkey,\n solana_signer::Signer,\n solana_transaction::VersionedTransaction,\n};\n\nfn test_set_clock() {\n let program_id = Pubkey::new_unique();\n let mut svm = LiteSVM::new();\n let bytes = include_bytes!(\"../../node-litesvm/program_bytes/litesvm_clock_example.so\");\n svm.add_program(program_id, bytes);\n let payer = Keypair::new();\n let payer_address = payer.pubkey();\n svm.airdrop(&payer.pubkey(), 1_000_000_000).unwrap();\n let blockhash = svm.latest_blockhash();\n let ixs = [Instruction {\n program_id,\n data: vec![],\n accounts: vec![],\n }];\n let msg = Message::new_with_blockhash(&ixs, Some(&payer_address), &blockhash);\n let versioned_msg = VersionedMessage::Legacy(msg);\n let tx = VersionedTransaction::try_new(versioned_msg, &[&payer]).unwrap();\n // set the time to January 1st 2000\n let mut initial_clock = svm.get_sysvar::<Clock>();\n initial_clock.unix_timestamp = 1735689600;\n svm.set_sysvar::<Clock>(&initial_clock);\n // this will fail because it's not January 1970 anymore\n svm.send_transaction(tx).unwrap_err();\n // so let's turn back time\n let mut clock = svm.get_sysvar::<Clock>();\n clock.unix_timestamp = 50;\n svm.set_sysvar::<Clock>(&clock);\n let ixs2 = [Instruction {\n program_id,\n data: vec![1], // unused, this is just to dedup the transaction\n accounts: vec![],\n }];\n let msg2 = Message::new_with_blockhash(&ixs2, Some(&payer_address), &blockhash);\n let versioned_msg2 = VersionedMessage::Legacy(msg2);\n let tx2 = VersionedTransaction::try_new(versioned_msg2, &[&payer]).unwrap();\n // now the transaction goes through\n svm.send_transaction(tx2).unwrap();\n}\nSee also: warp_to_slot, which lets you jump to a future slot.\nWriting arbitrary accounts\nLiteSVM lets you write any account data you want, regardless of\nwhether the account state would even be possible.\nHere's an example where we give an account a bunch of USDC,\neven though we don't have the USDC mint keypair. This is\nconvenient for testing because it means we don't have to\nwork with fake USDC in our tests:\nuse {\n litesvm::LiteSVM,\n solana_account::Account,\n solana_program_option::COption,\n solana_program_pack::Pack,\n solana_pubkey::{pubkey, Pubkey},\n spl_associated_token_account_client::address::get_associated_token_address,\n spl_token::{\n state::{Account as TokenAccount, AccountState},\n ID as TOKEN_PROGRAM_ID,\n },\n};\n\nfn test_infinite_usdc_mint() {\n let owner = Pubkey::new_unique();\n let usdc_mint = pubkey!(\"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\");\n let ata = get_associated_token_address(&owner, &usdc_mint);\n let usdc_to_own = 1_000_000_000_000;\n let token_acc = TokenAccount {\n mint: usdc_mint,\n owner: owner,\n amount: usdc_to_own,\n delegate: COption::None,\n state: AccountState::Initialized,\n is_native: COption::None,\n delegated_amount: 0,\n close_authority: COption::None,\n };\n let mut svm = LiteSVM::new();\n let mut token_acc_bytes = [0u8; TokenAccount::LEN];\n TokenAccount::pack(token_acc, &mut token_acc_bytes).unwrap();\n svm.set_account(\n ata,\n Account {\n lamports: 1_000_000_000,\n data: token_acc_bytes.to_vec(),\n owner: TOKEN_PROGRAM_ID,\n executable: false,\n rent_epoch: 0,\n },\n )\n .unwrap();\n let raw_account = svm.get_account(&ata).unwrap();\n assert_eq!(\n TokenAccount::unpack(&raw_account.data).unwrap().amount,\n usdc_to_own\n )\n}\nCopying Accounts from a live environment\nIf you want to copy accounts from mainnet or devnet, you can use the solana account command in the Solana CLI to save account data to a file.\nOther features\nOther things you can do with litesvm include:\n\nChanging the max compute units and other compute budget behaviour using .with_compute_budget.\nDisable transaction signature checking using .with_sigverify(false).\nFind previous transactions using .get_transaction.\n\nWhen should I use solana-test-validator?\nWhile litesvm is faster and more convenient, it is also less like a real RPC node.\nSo solana-test-validator is still useful when you need to call RPC methods that LiteSVM\ndoesn't support, or when you want to test something that depends on real-life validator behaviour\nrather than just testing your program and client code.\nIn general though it is recommended to use litesvm wherever possible, as it will make your life\nmuch easier.PreviousTestingNextMolluskOn this pageOverviewInstallationMinimal ExampleDeploying ProgramsTime travelWriting arbitrary accountsCopying Accounts from a live environmentOther featuresWhen should I use solana-test-validator?Edit on GitHub","tokens":2009,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257612588,"hash":"5cad58938989d7b9f4cbf25a1ca8783db014a71c"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro","domain":"docs.arbitrum.io","title":"Inside Arbitrum Nitro | Arbitrum Docs","text":"✏️Request an updateTransaction processing journey on Arbitrum​\nThis document provides a deep dive into the design and rationale of Arbitrum Nitro. This isn't API documentation, nor is it a guided tour of the code—look elsewhere for those. \"Inside Arbitrum Nitro\" is for people who want to understand Nitro's design.\nThe majority of this document describes Arbitrum Rollup, the primary use case for Nitro, which runs on the Arbitrum One chain. There is a variant use case, called AnyTrust, which is used by the Arbitrum Nova chain. AnyTrust is covered by a section at the end of this document.\nArbitrum is an L2 scaling solution for Ethereum, offering a unique combination of benefits:\n\nTrustless security: security rooted in Ethereum, with any one party able to ensure correct Layer 2 results.\nCompatibility with Ethereum: able to run unmodified EVM contracts and Ethereum transactions.\nScalability: moving contracts' computation and storage off of the main Ethereum chain, allowing much higher throughput.\nMinimum cost: designed and engineered to minimize the L1 gas footprint of the system, minimizing per-transaction cost.\n\nNitro is a major upgrade to Arbitrum, improving over \"classic\" Arbitrum in several ways:\n\nAdvanced blob/calldata compression further reduces transaction costs on Arbitrum by reducing the amount of data posted to L1.\nSeparate contexts for common execution and fault proving, increasing the performance of L1 nodes, and thus offering lower fees.\nEthereum L1 gas compatibility, bringing pricing and accounting for EVM operations perfectly in line with Ethereum.\nMore L1 interoperability, including tighter synchronization with L1 block numbers, and full support for all Ethereum L1 precompiles.\nSafe retryables that eliminate the failure mode where a retryable ticket fails to be created.\nGeth tracing, for even broader debugging support.\nAnd many, many more changes.\n\nThe big picture​\nAt the most basic level, an Arbitrum chain works like this:\nOriginal napkin sketch drawn by Arbitrum co-founder Ed Felten\nPeople and contracts put messages into the inbox. The chain reads the messages one at a time and processes each one. This updates the chain's state and produces outputs.\nIf you want an Arbitrum chain to process a transaction for you, you need to put that transaction into the chain's inbox. Then the chain will see your transaction, execute it, and produce outputs: a transaction receipt and any withdrawals your transaction initiated.\nExecution is deterministic—which means that the chain's behavior is uniquely determined by the contents of its inbox. Because of this, the result of your transaction is known as soon as it is put in the inbox. Any Arbitrum node can tell you the result. (And you can run an Arbitrum node yourself if you want.)\nAll the technical details in this document are related to this diagram. To get from this diagram to a full description of Arbitrum, we'll need to answer questions like these:\n\nWho keeps track of the inbox, chain state, and outputs?\nHow does Arbitrum make sure that the chain state and outputs are correct?\nHow can Ethereum users and contracts interact with Arbitrum?\nHow does Arbitrum support Ethereum-compatible contracts and transactions?\nHow are ETH and tokens transferred into and out of Arbitrum chains, and how are they managed while on the chain?\nHow can I run my own Arbitrum node or validator?\n\nFor foundational concepts about the STF, see the State Transition Function deep dive.\nNitro's design: the four big ideas​\nThe essence of Nitro, and its key innovations, lie in four big ideas. We'll list them here with a quick summary of each, then we'll unpack them in more detail in later sections.\n\nSequencing, followed by deterministic execution: Nitro processes transactions with a two-phase strategy. First, the transactions are organized into a single ordered sequence, and Nitro commits to that sequence. Then the transactions are processed, in that sequence, by a deterministic State Transition Function.\nGeth at the core: Nitro supports Ethereum's data structures, formats, and virtual machine by compiling them into the core code of the popular go-ethereum (\"Geth\") Ethereum node software. Using Geth as a library in this way ensures a very high degree of compatibility with Ethereum.\nSeparating execution from proving: Nitro compiles the same source code twice, once to native code for execution on a Nitro node, optimized for speed, and again to WASM for proving, optimized for portability and security.\nOptimistic Rollup with interactive fraud proofs: Nitro settles transactions on the Layer 1 Ethereum chain using an Optimistic Rollup protocol that includes interactive fraud proofs, pioneered by Arbitrum. The current dispute system, BoLD, extends this with an all-vs-all, permissionless validation protocol that resolves disputes with a bounded delay (See \"Resolving disputes using interactive fraud proofs\").\n\nSequencing, followed by deterministic execution​\nThis diagram summarizes how transactions are processed in Nitro.\nTransaction lifecycle\nLet's follow a user's transaction through this process.\nFirst, the user creates a transaction, signs it with their wallet, and sends it to the Nitro chain's Sequencer. The Sequencer's job, as its name implies, is to take the arriving transactions, put them into an ordered sequence, and publish that sequence.\nOnce the transactions are sequenced, they are run through the state transition function, one by one. The state transition function (STF) takes as input the current state of the chain (account balances, contract code, and so on) along with the next transaction. It updates the state and sometimes emits a new Layer 2 block on the Nitro chain.\nBecause the protocol doesn't trust the Sequencer not to put garbage into its sequence, the STF will detect and discard invalid (for example, improperly formed) transactions from the sequence. A well-behaved Sequencer will filter out invalid transactions so the STF never sees them—and this reduces cost and therefore keeps transaction fees low—but Nitro will still work correctly no matter what the Sequencer puts into its feed. (Transactions in the feed are signed by their senders, so the Sequencer can't create forged transactions.)\nThe State Transition Function is deterministic, which means that its behavior depends only on the current state and the contents of the next transaction—and nothing else. Because of this determinism, the result of a transaction T will depend only on the genesis state of the chain, the transactions before T in the sequence, and T itself.\nIt follows that anyone who knows the transaction sequence can compute the STF themselves, and all honest parties who do so will receive identical results. This is the normal way that Nitro nodes operate: get the transaction sequence and run the State Transition Function locally. No consensus mechanism is needed for this.\nHow the Sequencer publishes the sequence​\nSo how do nodes get the sequence? The Sequencer publishes it in two ways:\n\na real-time feed, and\nbatches posted on L1 Ethereum\n\nThe real-time feed is published by the Sequencer, so anyone who subscribes receives instant notifications of each transaction as it is sequenced. Nitro nodes can subscribe to the feed directly from the Sequencer or via a relay that forwards it. The feed represents the Sequencer's promise to record transactions in a particular order. If the Sequencer is honest and doesn't have a long downtime, this promise will be kept. So anyone who trusts the Sequencer to keep its promises can rely on the feed to get instant information about the transaction sequence—and they can run the sequenced transactions through the State Transition Function to learn the results of each transaction immediately. This is \"soft finality\" for transactions; it's \"soft\" because it depends on the Sequencer keeping its promises.\nOn Arbitrum One, a second stream runs alongside the real-time feed. The Fast Feed is a paid, authenticated WebSocket stream that publishes each transaction as soon as the Sequencer orders and executes it, inside the Priority Gas Auction (PGA) round and before the block closes. The Sequencer publishes to the Fast Feed before it stores the transaction, so the block number each message carries is tentative. A Nitro node cannot follow the chain from the Fast Feed, and soft finality still comes from the real-time feed. The Fast Feed serves latency-sensitive readers, such as searchers and market makers, who want ordered transactions sooner.\nThe Sequencer also publishes its sequence on the L1 Ethereum chain. Periodically—perhaps every few minutes in production—the Sequencer concatenates the next group of transactions in the feed, compresses them for efficiency, and posts the results to Ethereum— as EIP-4844 blobs when the chain operator has enabled them, the parent chain supports them, and they are priced efficiently—otherwise as calldata. This is the final and official record of the transaction sequence. As soon as this Ethereum transaction reaches finality, the Layer 2 Nitro transactions it records will also have finality. These transactions are final because their positions in the sequence are final, and their outcomes are deterministic and knowable to any party. This is \"hard finality.\"\nThe Sequencer's batches are compressed using the general-purpose Brotli data compression algorithm. Rather than always using the maximum compression level, the batch poster selects a Brotli level adaptively based on its backlog (the default at low backlog is the maximum level 11, dropping to faster, lower levels as the backlog grows).\nGeth at the core​\nThe second key design idea in Nitro is \"Geth at the core.\" Here, \"Geth\" refers to go-ethereum, the most common node software for Ethereum. As its name would suggest, go-ethereum is written in the Go programming language, as is almost all of Nitro.\nInfoIn Ethereum's post-Merge architecture, Geth is an execution client: it runs the EVM and maintains state, working alongside a separate consensus client. Nitro doesn't run Geth as a standalone client—it compiles in Geth's execution core as a library (the \"Geth sandwich\" described below). Nitro also has no consensus client; the Sequencer and the Layer 1 Rollup protocol handle sequencing and finality instead.\nGeth sandwich\nThe software that makes up a Nitro node can be thought of as built in three main layers, which are shown above:\n\nThe base layer is the core of Geth—the parts that emulate the execution of EVM contracts and maintain the data structures that comprise the Ethereum state. Nitro compiles in this code as a library, with a few minor modifications to add necessary hooks.\nThe middle layer, which we call ArbOS, is custom software that provides additional functions associated with Layer 2 functionality, such as decompressing and parsing the Sequencer's data batches, accounting for Layer 1 gas costs and collecting fees to reimburse for them, and supporting cross-chain bridge functionalities such as deposits of Ether (ETH) and tokens from L1 and withdrawals of the same back to L1. We'll dig into the details of ArbOS below.\nThe top layer consists of node software, mostly drawn from Geth. This handles connections and incoming RPC requests from clients and provides the other top-level functionality required to operate an Ethereum-compatible blockchain node.\n\nBecause the top and bottom layers rely heavily on code from Geth, this structure has been dubbed a \"Geth sandwich.\" Strictly speaking, Geth plays the role of the bread in the sandwich, and ArbOS is the filling, but this sandwich is named for the bread.\nThe State Transition Function consists of the bottom Geth layer and a portion of the middle ArbOS layer. In particular, the STF is a designated function in the source code and implicitly includes all code that it calls. The STF takes as input the bytes of a transaction received in the inbox and has access to a modifiable copy of the Ethereum state tree. Executing the STF may modify the state and, upon completion, emit the header of a new block (in Ethereum's block header format), which will be appended to the Nitro chain.\nSeparating execution from proving​\nOne of the challenges in designing a practical rollup system is the tension between wanting the system to perform well in ordinary execution and reliably verifying its results. Nitro resolves this tension by using the same source code for both execution and proving, but compiling it to different targets for the two cases.\nWhen compiling the Nitro node software for execution, the standard Go compiler produces native code for the target architecture, which will vary across node deployments. (The node software is distributed in source code form, and as a Docker image containing a compiled library.)\nSeparately, for proof, the State Transition Function portion of the code is compiled to WebAssembly (WASM), a typed, portable machine code format. The WASM code is then transformed into a format we call WAVM, as detailed below. If there is a dispute over the correct result of the STF computation, it is resolved to the WAVM code.\nWAVM​\nThe WASM format has many features that make it a good vehicle for fraud proofs—it is portable, structured, well-specified, and has reasonably good tools and support—but it needs a few modifications to do the job completely. Nitro uses a modified version of WASM, which we call WAVM. A simple transformation stage turns the WASM code produced by the Go compiler into WAVM code suitable for proving.\nWAVM differs from WASM in three main ways. First, WAVM removes some WASM features that the Go compiler does not generate; the transformation phase verifies that these features are not present.\nSecond, WAVM restricts a few WASM features. For example, WAVM does not contain floating-point instructions, so the transformer replaces floating-point instructions with calls to the Berkeley SoftFloat library. (We use software floating-point to reduce the risk of floating-point incompatibilities between architectures. The core Nitro functions never use floating-point, but the Go runtime does use some floating-point operations.)\nWAVM does not contain nested control flow, so the transformer flattens control flow constructs, turning control flow instructions into jumps. Some WASM instructions take a variable amount of time to execute, which we avoid in WAVM by transforming them into constructs using fixed cost instructions. These transformations simplify proving.\nThird, WAVM adds a few opcodes to enable interaction with the blockchain environment. For example, new instructions allow the WAVM code to read and write the chain's global state, to get the next message from the chain's inbox, or to signal a successful end to executing the State Transition Function.\nReadPreImage and the hash oracle trick​\nThe most interesting new instruction is ReadPreImage, which takes as input a hash H and an offset I, and returns the word of data at offset I in the preimage of H (and the number of bytes written, which is zero if I is at or after the end of the preimage). Of course, it is not feasible in general to produce a preimage from an arbitrary hash. For safety, the ReadPreImage instruction can only be used in a context where the preimage is publicly known, and its size is bounded. For the original Keccak-hashed uses (described below), this bound is on the order of 100 kbytes; other preimage types have their own bounds, for example, an EIP-4844 blob preimage is exactly one blob (about 128 kbytes).\n(In this context, \"publicly known\" information is information that can be derived or recovered efficiently by any honest party, assuming that the full history of the L1 Ethereum chain is available. For convenience, a hash preimage can also be supplied by a third party, such as a public server, and the correctness of the supplied value is easily verified.)\nFor example, the state of a Nitro chain is maintained in Ethereum's state tree format, organized as a Merkle tree. Nodes of the tree are stored in a database, indexed by each node's Merkle hash. In Nitro, the state tree is kept outside of the State Transition Function storage, with the STF only knowing the root hash of the tree. Given the hash of a tree node, the STF can recover the tree node's contents by using ReadPreImage, relying on the fact that the full contents of the tree are publicly known and the nodes in the Ethereum state tree will always be smaller than the upper bound on preimage size. In this manner, the STF can arbitrarily read and write to the state tree, even though it stores only the root hash.\nReadPreImage is also used to fetch the contents of recent L2 block headers, given the header hash. This is safe because the block headers are publicly known and have a bounded size. Since the original design, the ReadPreImage hash has expanded to support multiple preimage types beyond just Keccak hashes. The prover today recognizes four: Keccak-256 (used for the state tree and block headers above), SHA-256, and Ethereum versioned hash (the KZG commitment of an EIP-4844 blob, used when batch data is posted as blobs and verified with a KZG proof), and a Data Availability Certificate hash (used by AnyTrust chains). In every case, the same safety conditions hold: the preimage is publicly recoverable and of bounded size.\nThe \"hash oracle trick\" of storing the Merkle hash of a data structure and relying on protocol participants to store the full structure to support fetch-by-hash of its contents dates back to the original Arbitrum design.\nOptimistic Rollup​\nArbitrum is an Optimistic Rollup. Let's unpack what that means.\nRollup​\nArbitrum is a Rollup, which means that the inputs to the chain—the messages that are put into the inbox—are all recorded on the Ethereum chain as EIP-4844 blobs or as calldata if blobs are unavailable. Because of this, everyone has the information they need to determine the chain's current state—they have the full history of the inbox, and the results are uniquely determined by that history, so they can reconstruct the chain's state based on public information, if needed.\nThis also allows anyone to participate in the Arbitrum protocol by running an Arbitrum node or serving as a validator. Nothing about the chain's history or state is a secret.\nOptimistic​\nArbitrum is optimistic, meaning that it advances the state of the chain by allowing any party (a \"validator\") to post an assertion on Layer 1 that the party claims is correct, and then giving everyone else a chance to challenge that claim. If the challenge period (6.4 days) passes and no one challenges the claimed assertion, Arbitrum confirms it as correct. If someone challenges the claim during the challenge period, Arbitrum uses an efficient dispute-resolution protocol (detailed below) to determine which party is lying. The liar forfeits its bond. Those bonds are sent to addresses the chain owner configures (loserStakeEscrow on the Rollup contract and excessStakeReceiver on the challenge manager; new chains default both to the chain owner).\nBecause a party that tries to cheat will lose a deposit, attempts to cheat should be very rare, and the normal case will be a single party posting a correct assertion, and nobody challenging it.\nResolving disputes using interactive fraud proofs​\nAmong optimistic rollups, the most important design decision is how to resolve disputes. Suppose Alice claims that the chain will produce a certain result, and Bob disagrees. How will the protocol decide which version to accept?\nThere are basically two choices: interactive proving, or re-executing transactions. Arbitrum uses interactive proving, which we believe is more efficient and more flexible. Much of Arbitrum's design follows from this fact.\nInteractive proving​\nThe idea of interactive proving is that Alice and Bob will engage in a back-and-forth protocol, mediated by an L1 contract, to resolve their dispute with minimal work required from the L1 contract.\nArbitrum's approach is to dissect the dispute. If Alice's claim covers N steps of execution, she posts two claims of size N/2, which combine to yield her initial N-step claim, then Bob picks one of Alice's N/2-step claims to challenge.\nNow the size of the dispute has been cut in half. This process continues, cutting the dispute in half at each stage, until they are disagreeing about a single step of execution. Note that so far, the L1 mediator hasn't had to think about execution \"on the merits.\" It is only once the dispute is narrowed down to a single step that the L1 mediator needs to resolve the dispute by looking at what the instruction actually does and whether Alice's claim about it is correct.\nThe key principle behind interactive proving is that, if Alice and Bob are in a dispute, they should do as much offchain work as possible to resolve it, rather than delegating it to an L1 contract.\nRe-executing transactions​\nThe alternative to interactive proving would be to have an assertion include a claimed machine-state hash after each individual transaction. Then, in case of a dispute, the L1 mediator would emulate the execution of an entire transaction to see whether the outcome matches Alice's claim.\nWhy interactive proving is better​\nWe strongly believe that interactive proving is the superior approach, for the following reasons:\n\nMore efficient in the optimistic case: Because interactive proving can resolve disputes that are larger than one transaction, it can allow an assertion to contain only a single claim about the end state of the chain after all of the execution covered by the assertion. By contrast, re-executing requires posting a state claim for each transaction within the assertion. With hundreds or thousands of transactions per assertion, this is a substantial difference in L1 footprint—and L1 footprint is the main component of cost.\nMore efficient in the pessimistic case: In the case of a dispute, interactive proving requires the L1 mediator contract only to check that Alice and Bob's actions \"have the right shape,\" for example, that Alice has divided her N-step claim into two claims half as large. (The mediator doesn't need to evaluate the correctness of Alice's claim—Bob does that, offchain.) Only one instruction needs to be re-executed. By contrast, re-execution requires the L1 mediator to emulate the execution of an entire transaction.\nHigh per-transaction gas limit: Interactive proving can escape from Ethereum's tight per-transaction gas limit. The gas limit isn't infinite, for practical reasons, but it can be larger than on Ethereum. As far as Ethereum is concerned, the only downside of a gas-heavy Arbitrum transaction is that it may require an interactive fraud proof with slightly more steps (and only if indeed it is fraudulent). By contrast, re-execution must impose a lower gas limit than Ethereum, because it must be possible to emulate execution of the transaction (which is more expensive than executing it directly) within a single Ethereum transaction.\nMore implementation flexibility: Interactive proving allows more flexibility in implementation. All that is necessary is the ability to verify a one-step proof on Ethereum. By contrast, re-execution approaches are constrained by the EVM's limitations.\n\nInteractive proving drives Arbitrum's design​\nMuch of Arbitrum's design is driven by the opportunities enabled by interactive proving. If you're reading about some feature of Arbitrum, and you're wondering why it exists, two good questions to ask are: \"How does this support interactive proving?\" and \"How does this take advantage of interactive proving?\" The answers to most \"why questions\" about Arbitrum relate to interactive proving.\nArbitrum Rollup protocol​\nBefore diving into the rollup protocol, there are two things we need to cover.\nFirst, if you're an Arbitrum user or developer, you don't need to understand the rollup protocol. You don't ever need to think about it, unless you want to. Your relationship with it can be like a train passenger's relationship with the train's engine: you know it exists, you rely on it to keep working, but you don't spend your time monitoring it or studying its internals.\nYou're welcome to study, observe, and even participate in the rollup protocol, but you don't need to, and most people won't. So if you're a typical train passenger who just wants to read or talk to your neighbor, you can skip right to the next section of this document. If not, read on!\nThe second thing to understand about the rollup protocol is that it doesn't determine transaction results; it only confirms them. The results are uniquely determined by the sequence of messages in the chain's inbox. So once your transaction message is in the chain's inbox, its result is knowable—and Arbitrum nodes will report that your transaction is complete. The role of the rollup protocol is to confirm transaction results that, as far as Arbitrum users are concerned, have already occurred. (This is why Arbitrum users can effectively ignore the rollup protocol.)\nYou might wonder why we need the rollup protocol. If everyone already knows the results of transactions, why bother confirming them? The rollup protocol exists for two reasons. First, somebody might lie about a result, and we need a definitive, trustless way to tell who is lying. Second, Ethereum doesn't know the results. The whole point of a Layer 2 scaling system is to run transactions without Ethereum needing to do all the work—and indeed, Arbitrum can go fast enough that Ethereum couldn't hope to monitor every Arbitrum transaction. But once a result is confirmed, Ethereum knows it and can rely on it, enabling operations such as processing withdrawals of funds from Nitro back to L1.\nWith those preliminaries behind us, let's jump into the details of the rollup protocol.\nThe parties that participate in the protocol are called validators. Some validators choose to be bonders—they place a deposit that they can recover if they're not caught cheating. In the common case, it's expected that only one validator will be bonded, since as long as it's staked on the current outcome, and there are no conflicting claims, there's no need for other parties to bond or take any action.\nWith the deployment of BoLD, validation is permissionless: anyone can post an assertion, bond, and defend the chain. (A chain may still keep an optional validator allowlist enabled as a safety measure during early stages; this is a toggle in the rollup contracts, not a requirement of the protocol.) \"Watchtower validators,\" who monitor the chain but don't take any onchain actions, can be run permissionlessly (see \"validators\" below).\nThe key security property of the rollup protocol is that any one honest validator can force the correct execution of the chain to be confirmed. This means that executing an Arbitrum chain is as trustless as executing an Ethereum chain. You, and you alone (or someone you hire), can ensure your transactions are processed correctly. And this is true no matter how many malicious people are trying to stop you. Under BoLD, this guarantee comes with a bounded delay: a single honest party can force confirmation of the correct outcome with a known, fixed amount of time, regardless of how many adversaries participate or how much they place as bond.\nThe Rollup chain​\nThe rollup protocol tracks a chain of claims about the L2 state—we'll call these assertions. They're not the same as Layer 1 Ethereum blocks, and also not the same as Layer 2 (Nitro) blocks. You can think of these assertions as forming a tree of claims about the chain's history, which the Arbitrum Rollup Protocol manages and oversees.\nValidators can propose assertions. A new assertion is initially unresolved. Eventually, every assertion will be resolved by being either confirmed or rejected. The confirmed assertions constitute the chain's confirmed history.\nEach assertion contains, among other things:\n\nThe predecessor assertion it builds on (the last assertion before this one that is claimed to be correct)\nThe number of L2 blocks that have been created in the chain's history\nThe number of inbox messages that have been consumed in the chain's history\nA commitment to the state and outputs produced over the chain's history\n\nExcept for its position in the tree, the contents of an assertion are all just claims by its proposer. Arbitrum doesn't know at first whether they are correct. If they are correct, the protocol should eventually confirm the assertion. If they are incorrect, the protocol should eventually reject them.\nAn assertion implicitly claims that its predecessor is correct, and therefore, transitively, that a complete history of the chain reaching back to its genesis is correct. It also implicitly claims that any rival assertion—a different assertion sharing the same predecessor—is incorrect.\nIn the normal case, only correct assertions are proposed. If an assertion has no rival and its challenge period elapses, it is confirmed. If two or more rival assertions exist, they are resolved by a challenge (described below), and the assertions descending from the losing side are rejected. The crucial property of BoLD is that this resolution completes with a bounded delay, no matter how many rival assertions a malicious party creates.\nBonding​\nAt any given time, some validators will be bonders, and some will not. To propose an assertion, a validator must put up a bond held by the Arbitrum Layer 1 contracts, which will be confiscated if the assertion is proven false. The bond is denominated in an ERC-20 token configured for the chain—on Arbitrum One, this is WETH—so, in practice, stakers post ETH-denominated value.\nA validator who agrees with the current confirmed history and proposes a correct successor assertion stays bonded on it until it is confirmed, at which point the bond can be withdrawn. A validator whose assertion is rejected forfeits its bond.\nWhen a dispute arises, the challenge game itself is played over edges (see \"Challenges\"), and creating an edge requires posting a small additional mini-bond at each level of the dispute. Because only one assertion in a set of rivals can ever be confirmed, the protocol only needs to retain a single mini-bond per level; the redundant bonds posted by rivals can be released to a designated excess-bond receiver.\nUnder BoLD, the bond required to propose an assertion and the mini-bonds required to participate in a challenge are fixed parameters of the chain (the per-level mini-bond amounts are configured in the challenge manager). There is no exponential escalation tied to confirmation delay, because BoLD's bounded-delay guarantee removes the delay-attack incentive that the escalation was designed to counter: an adversary can't push out confirmation by piling on false stakes, so there is no need to raise the price of doing so over time.\nRules for confirming or rejecting​\nThe rules for resolving assertions are straightforward.\nAn assertion can be confirmed if:\n\nIts predecessor is the latest confirmed assertion, and\nIts challenge period has elapsed, and\nIt has no rival (no competing assertions share its predecessor), or the challenge among the rivals has been resolved in its favor via the edge protocol\n\nAn assertion is rejected if its predecessor is rejected, or if a rival assertion wins the challenge between them.\nA consequence of these rules is that a lone, unrivaled assertion is confirmed once its time elapses—no challenge is ever needed in the common, honest case. When two or more rival assertions exist, the disagreement is settled by a challenge. It's time to look at how those work.\nChallenges​\nSuppose two (or more) rival assertions have been posted, sharing the same predecessor. They make conflicting claims about the chain's history, so at most one of them can be correct.\nWhenever rival assertions exist, anyone—not just the proposers—can open a challenge. The rollup protocol records the challenge and mediates it via the Edge Challenge Manager, eventually confirming the correct side and allowing the losing side's bond to be confiscated.\nA challenge is played over the edges. An edge is a claim that the machine can advance from one state to another over some range of steps. Each participant who wants to defend a position creates a layer-zero edge (posting a mini-stake) and then bisects it by posting the claimed midpoint state, splitting the edge into two half-size child edges. Rivals do the same to their own edges. Because the protocol is all-vs-all, many edges can be developed in parallel, and, crucially, the honest participant only needs to keep bisecting towards the truth—it does not need a specific opponent to \"take a turn.\" Each edge accumulates time only while it is unrivaled; an edge whose unrivaled timer reaches the challenge period is confirmable. This is how BoLD bounds the total delay: an adversary can create rivals, but doing so does not buy unbounded time.\nDissection proceeds across several levels—first over Layer 2 blocks, then over progressively finer ranges of WAVM instructions (a block level, one or more big-step levels, and a small-step level)—until an edge represents a single step of execution. The final edge is confirmed by a one-step proof, checked onchain by the one-step proof entry contract, which determines who was telling the truth about that one instruction.\nThe two subsections below give the classic two-party intuition for why dissection works. They describe a simplified Alice-vs-Bob game; in BoLD, the same logic applies, generalized so that any number of parties can compete and the honest party always has a winning line of play.\nDissection protocol: simplified version​\nAlice is defending the claim that, starting from the state in the predecessor assertion, the Virtual Machine can advance to the state specified in her assertion. Essentially, she is claiming that the Virtual Machine can execute N instructions, and that the execution will consume M inbox messages and transform the hash of outputs from H' to H.\nAlice's first move requires her to dissect her claims about intermediate states between the beginning (0 instructions executed) and the end (N instructions executed). So we require Alice to divide her claim in half, and post the state at the halfway point, after N/2 instructions have been executed.\nNow Alice has effectively bisected her N-step assertion into two (N/2)-step assertions. Bob has to point to one of those two half-size assertions and claim it is wrong.\nAt this point, we're effectively back in the original situation: Alice having made an assertion that Bob disagrees with. But we have cut the size of the assertion in half, from N to N/2. We can apply the same method again, with Alice bisecting and Bob choosing one of the halves, to reduce the size to N/4. And we can continue bisecting, so that after a logarithmic number of rounds, Alice and Bob will be disagreeing about a single step of execution. That's where the dissection phase of the protocol ends, and the disputed single step is settled by a one-step proof, which is checked onchain by the one-step proof entry contract.\nWhy does dissection correctly identify a cheater?​\nBefore discussing the complexities of the real challenge protocol, let's pause to understand why the simplified version is correct. Here, correctness means two things: (1) if Alice's initial claim is correct, Alice can always win the challenge, and (2) if Alice's initial claim is incorrect, Bob can always win the challenge.\nTo prove (1), observe that if Alice's initial claim is correct, she can offer a truthful midpoint claim, and both of the implied half-size claims will be correct. So whichever half Bob objects to, Alice will again be in the position of defending a correct claim. At each stage of the protocol, Alice will be defending a correct claim. At the end, Alice will have a correct one-step claim to prove, so that claim will be provable, and Alice can win the challenge.\n(If you're a stickler for mathematical precision, it should be clear how these arguments can be turned into proofs by induction on N.)\nThe real decision protocol​\nThe real dissection protocol is conceptually similar to the simplified one described above, but with several changes that improve efficiency, enable permissionless all-vs-all play, and deal with necessary corner cases. Here is a list of the differences:\n\nDissection over L2 blocks, then over instructions: An assertion asserts the result of creating some number of Layer 2 Nitro blocks. Dissection first occurs over these Layer 2 blocks to narrow the dispute down to a single Layer 2 Nitro block. At that point, the dispute becomes about a single execution of the State Transition Function—i.e., the execution of a sequence of WAVM instructions—and the recursive dissection sub-protocol runs again over WAVM instructions (across a block level, one or more big-step levels, and a small-step level) to narrow the dispute to a single instruction. The dispute concludes with a one-step proof of a single instruction (or a party failing to act and losing on time).\nBinary bisection: Each edge is split into two half-size child edges by posting a single midpoint claim. (The classic protocol generalizes this to K-way dissection; BoLD uses straightforward binary bisection).\nAll-vs-all, not turn-based: Rather than two players alternating moves, any number of participants may create and bisect edges. Each edge accrues time only while it is unrivaled; as soon as a rival edge appears (one sharing the same start commitment and level—its \"mutual ID\"), the timer stops. The honest participant defends by continuing to bisect toward the truth; it never has to wait for a specific opponent to move. This is what lets a single honest party guarantee the correct outcome, no matter how many adversaries join, and within a bounded delay.\nDeal with the Empty-Inbox case: The machine can't always execute N steps without getting stuck. It might halt, or it might have to wait because its inbox is exhausted, so it can't go on until more messages arrive. The protocol, therefore, allows a challenger to claim that the specified amount of execution is not possible under the current conditions, rather than being forced to assert a concrete end state.\nTime limits: Confirmation is governed by per-edge, unrivaled timers measured against a challenge period (6.4 days), and the protocol limits the total time to confirmation. A participant who stops responding while behind will lose once the relevant time elapses.\n\nIt should be clear that these changes don't affect the basic correctness of the challenge protocol. They do, however, improve their efficiency, make validation permissionless, and bound the worst-case delay.\nEfficiency​\nThe challenge protocol is designed so that the dispute can be resolved with a minimum of work required by the protocol (via its Layer 1 Ethereum contracts) in its role as mediator. When a participant bisects an edge, the protocol only needs to track timing and ensure the move \"has the right shape\"—for example, that a bisection posts a properly positioned midpoint. The protocol doesn't need to verify whether those claims are correct.\nThe only point where the protocol needs to evaluate a move \"on the merits\" is at the one-step proof, where it examines the proof and determines whether it establishes that the virtual machine moves from the before state to the claimed after state after one step of computation.\nValidators​\nSome Arbitrum nodes will choose to act as validators. This means they monitor the progress of the rollup protocol and participate in it to advance the chain's state securely.\nNot all nodes will choose to do this. Because the rollup protocol doesn't decide what the chain will do but merely confirms the correct behavior, which is fully determined by the inbox messages, a node can ignore the rollup protocol and compute the correct behavior itself. For more on what such nodes might do, see the Full Nodes section.\nOffchain Labs provides open source validator software, including a pre-built Docker image.\nEvery validator can choose its own approach, but we expect validators to follow three common strategies:\n\nThe active validator strategy tries to advance the state of the chain by proposing new assertions. An active validator is always staked, since creating an assertion requires staking. A chain really only needs one honest active validator; any more is an inefficient use of resources. For the Arbitrum One chain, Offchain Labs runs an active validator.\nThe defensive validator strategy watches the rollup protocol operate. If only correct assertions are proposed, this strategy doesn't stake. But if an incorrect assertion is proposed, this strategy intervenes by posting a correct assertion or staking on a correct assertion posted by another party. This strategy avoids staking when things are going well, but if someone is dishonest, it stakes in order to defend the correct outcome.\nThe watchtower validator strategy never stakes. It watches the rollup protocol and, if an incorrect assertion is proposed, raises the alarm (by whatever means it chooses) so others can intervene. This strategy assumes that other parties willing to stake will intervene to take some of the dishonest proposer's stake, and that this can occur within the challenge period. (In practice, this will allow several days for a response.)\n\nUnder normal conditions, validators using the defensive and watchtower strategies won't do anything except observe. A malicious actor considering whether to try cheating won't be able to tell how many defensive and watchtower validators are operating incognito. Perhaps some defensive validators will announce themselves, but others probably won't, so a would-be attacker will always have to worry that defenders are waiting to emerge.\nWith BoLD, validation is permissionless—anyone can propose an assertion, stake, and defend the correct chain. A chain may still keep an optional validator allowlist enabled for safety during the early stages, but this is a configurable toggle rather than a protocol property.\nWho will be validators? Anyone can do it, but most people will choose not to. In practice, we expect people to validate a chain for several reasons.\n\nValidators could be paid for their work by the party that created the chain or someone else. A chain could be configured so that a portion of user transaction fees is paid directly to validators.\nParties with significant assets at stake on a chain, such as app developers, exchanges, power users, and liquidity providers, may choose to validate to protect their investments.\nAnyone who chooses to validate can do so. Some users will probably choose to validate to protect their own interests or simply to be good citizens. But ordinary users don't need to validate, and we expect the vast majority won't.\n\nArbOS​\nArbOS is a trusted \"system glue\" component that runs on Layer 2 as part of the State Transition Function. ArbOS provides functions needed for a Layer 2 system, such as cross-chain communication, resource accounting, Layer 2-related fee economics, and chain management.\nWhy ArbOS?​\nIn Arbitrum, most of the work that would otherwise be done at Layer 1 is handled by ArbOS, performing these functions at the speed and low cost of Layer 2.\nSupporting these functions in Layer 2 trusted software, rather than building into the L1-enforced rules of the architecture as Ethereum does, offers significant advantages in cost because these operations can benefit from the lower cost of computation and storage at Layer 2, instead of having to manage those resources as part of Layer 1 contracts. Having a trusted operating system at Layer 2 also offers significant advantages in flexibility, because Layer 2 code is easier to evolve or customize for a particular chain than a Layer-1-enforced architecture would be.\nFull nodes​\nAs the name suggests, full nodes in Arbitrum play the same role as full nodes in Ethereum: they know the state of the chain, and provide an API that others can use to interact with.\nArbitrum full nodes normally \"live at Layer 2,\" which means that they don't worry about the rollup protocol but simply treat their Arbitrum chain as a mechanism that feeds inbox messages to the State Transition Function to evolve the Layer 2 chain and produce outputs.\nThe Sequencer​\nThe Sequencer is a specially designated full node granted limited power to control transaction ordering. This allows the Sequencer to guarantee the results of user transactions immediately, without waiting for anything to happen on Ethereum. So no need to wait five minutes or so for blocks—and no need to even wait 12-15 seconds for Ethereum to make a block.\nClients interact with the Sequencer exactly the same way they would with any full node, for example, by giving their wallet software a network URL that points to the Sequencer.\nCurrently, the Sequencer on the Arbitrum One and Arbitrum Nova chains is run by Offchain Labs.\nInstant confirmation​\nWithout a Sequencer, a node can predict what the results of a client transaction will be, but the node can't be sure, because it can't know or control how the transaction it submits will be ordered in the inbox, relative to transactions submitted by other nodes.\nThe Sequencer is given greater control over ordering, allowing it to assign its clients' transactions positions in the inbox queue, thereby ensuring it can determine the results of those transactions immediately. The Sequencer's power to reorder has limits, set by the chain's transaction ordering policy (see \"Transaction ordering\" below), but it does have more power than anyone else to influence transaction ordering.\nInboxes, fast and slow​\nWhen we add a Sequencer, the inbox's operation changes.\n\nOnly the Sequencer can put new messages directly into the inbox. The Sequencer tags the messages it is submitting with an Ethereum block number and timestamp. (ArbOS ensures that these are non-decreasing, adjusting them upward if necessary to avoid decreases.)\nAnyone else can submit a message, but messages submitted by non-Sequencer nodes will be put into the \"Delayed Inbox\" queue, which is managed by an L1 Ethereum contract.\n\nMessages in the delayed inbox queue will wait there until the Sequencer chooses to \"release\" them into the main inbox, where they will be added to the end of the inbox. A well-behaved Sequencer typically releases delayed messages after about 10 minutes, as explained below.\nAlternatively, if a message has been in the delayed inbox queue for longer than the maximum delay interval (currently 24 hours on Arbitrum One), anyone can force it to be promoted to the main inbox. (This ensures that the Sequencer can only delay messages but can't censor them.)\n\nIf the Sequencer is well-behaved...​\nA well-behaved Sequencer will accept transactions from all requesters and treat them fairly, providing each requester with the promised transaction result as quickly as possible.\nIt will also minimize the delay it imposes on non-Sequencer transactions by promptly releasing delayed messages, consistent with the goal of providing strong guarantees of transaction results. Specifically, if the Sequencer believes that 40 confirmation blocks are needed to have high confidence in finality on Ethereum, it will release delayed messages after 40 blocks. This is enough to ensure that the Sequencer knows exactly which transactions will precede its current transactions, because those preceding transactions have finality. There is no need for a benign Sequencer to delay non-Sequencer messages more than that, so it won't.\nThis means transactions that go through the delayed inbox will take longer to achieve finality. Their time to finality will roughly double, because they will have to wait one finality period for promotion, then another finality period for the Ethereum transaction that promoted them to achieve finality.\nThis is the basic tradeoff of having a Sequencer: if your message uses the Sequencer, finality is C blocks faster; but if your message doesn't use the Sequencer, finality is C blocks slower. This is usually a good trade-off, because most transactions will use the Sequencer, and the practical difference between instant and 10-minute finality is larger than that between 10-minute and 20-minute finality.\nSo a Sequencer is generally a win if it's well-behaved.\nIf the Sequencer is malicious...​\nA malicious Sequencer, on the other hand, could cause some pain. If it refuses to handle your transactions you're forced to go through the delayed inbox, with a longer delay. And a malicious Sequencer has great power to front-run everyone's transactions, thereby profiting greatly at users' expense.\nPGA does not widen that power. The mempool stays private, and PGA gives nobody—including bidders—the right to view or reorder another user's transactions, so Arbitrum's protections against harmful MEV are unchanged.\nOn Arbitrum One, Offchain Labs currently runs a Sequencer, which is well-behaved—we promise! This will be useful, but it's not decentralized. Over time, we'll switch to decentralized sequencing, as described below.\nBecause the Sequencer will be run by a trusted party at first and later decentralized, we haven't built in a mechanism to directly punish a misbehaving Sequencer: we're asking users to trust the centralized Sequencer at first, until we switch to decentralized sequencing later.\nTransaction ordering: PGA, and the road to decentralized sequencing​\nThe Sequencer still controls transaction ordering, but the rule it follows is a configurable transaction ordering policy. Arbitrum One uses Priority Gas Auctions (PGA): you bid for ordering by setting maxPriorityFeePerGas on a standard EIP-1559 transaction, and the Sequencer sorts by that priority fee in short rounds that run several times per block. On Arbitrum One, the block time is 250ms and each block holds two rounds, so a round lasts 125ms. An anti-starvation boost raises the queue position of transactions still waiting at the end of a round, so a transaction that pays no priority fee is still included within a small number of blocks. The boost changes position only, never the fee charged.\nPGA replaces Timeboost on Arbitrum One. Timeboost auctioned a 60-second express lane to one controller per round and delayed every other transaction by 200ms. PGA removes that delay, so no transaction waits on another's lane. Other Arbitrum chains can still choose Timeboost, but a chain should enable one policy, not both. See PGA for Arbitrum chains.\nAn ordering policy has limits worth stating plainly. PGA allocates ordering through an open, per-transaction fee competition layered on top of the existing Sequencer. It is not a decentralized or \"fair-ordering\" Sequencer, and it does not, by itself, remove trust in the Sequencer operator. The Sequencer on Arbitrum One is still a single node run by Offchain Labs.\nTruly decentralized sequencing—replacing the single Sequencer with a committee that establishes ordering as long as a supermajority is honest—remains an active research and engineering direction rather than a shipped feature. Research by a team at Cornell Tech, including Offchain Labs co-founder Steven Goldfeder, produced an early decentralized fair-ordering algorithm, and ideas in that lineage continue to inform the longer-term design. An ordering policy sits above this layer: decentralized sequencing changes who enforces the ordering rules, not the rules themselves.\nBridging​\nWe have already covered how users interact with L2 contracts—they submit transactions by putting messages into the chain's inbox, or having a full node Sequencer or aggregator do so on their behalf. Let's talk about how contracts interact between L1 and L2—how an L1 contract calls an L2 contract, and vice versa.\nThe L1 and L2 chains run asynchronously, so it is not possible to make a cross-chain call that produces a result within the same transaction as the caller. Instead, cross-chain calls must be asynchronous: the caller submits the call at some point, and it runs later. As a consequence, a cross-chain contract-to-contract call can never produce a result available to the calling contract (except for an acknowledgement that the call was successfully submitted for later execution).\nL1 contracts can submit L2 transactions​\nAn L1 contract can submit an L2 transaction, just like a user would, by calling the Nitro chain's inbox contract on Ethereum. This L2 transaction will run later, producing results that will not be available to the L1 caller. The transaction will execute at L2, but the L1 caller won't be able to see any results from the L2 transaction.\nThe advantage of this method is that it is simple and has relatively low latency. The disadvantage compared to the other method we'll describe soon is that the L2 transaction might revert if the L1 caller doesn't set the L2 gas price and max gas amount correctly. Because the L1 caller can't see the result of its transaction, it can't be absolutely sure that its L2 transaction will succeed.\nThis would introduce a serious problem for certain types of L1-to-L2 interactions. Consider a transaction that deposits a token on L1 and makes it available at some address on L2. If the L1 side succeeds, but the L2 side reverts, you've just sent some tokens to the inbox contract that are unrecoverable on either L2 or L1. Not good.\nL1-to-L2 message-based transactions​\nFortunately, we have another method for L1-to-L2 calls that is more robust against gas-related failures and uses a message-based system. The idea is that an L1 contract can submit a \"retryable\" transaction and generate a ticketID. The Nitro chain will try to run that transaction. If the transaction succeeds, nothing else needs to happen. But if the transaction fails, anyone can call a special precompiled contract at L2 later, passing in the ticketID, to try redeeming the message and re-executing the transaction.\nWhen saving a transaction for retry, Nitro records the sender's address, destination address, callvalue, and calldata. All of this is saved, and the callvalue is deducted from the sender's account and (logically) attached to the saved transaction.\nIf the redemption succeeds, the transaction is completed, a receipt is issued, and the ticketID is canceled and can't be used again. If the redemption fails, for example, because the packaged transaction fails, the redemption reports failure, and the ticketID remains available for redemption.\nNormally, the original submitter tries to ensure their transaction succeeds immediately, so it never needs to be recorded or retried. For example, our \"token deposit\" use case above should, in the happy, common case, still require only a single user signature. If this initial execution fails, the ticketID will still exist as a backstop, which others can redeem later.\nSubmitting a transaction in this way incurs a fee in ETH, which the submitter must pay and varies based on the transaction's calldata size. Once submitted, the message is valid for about a week. If the message is not redeemed within that period, it is deleted.\nWhen the message is redeemed, the pre-packaged transaction runs with sender and origin set to the L2 alias of the original submitter's L1 address, and with destination, callvalue, and calldata set to the values the submitter provided at the time of submission.\nThis mechanism is a bit more cumbersome than ordinary L1-to-L2 transactions, but it has the advantage that the submission cost is predictable and the message will always be available for redemption if the submission cost is paid. As long as there is a user willing to redeem the message, the L2 transaction will eventually be executed and will not be silently dropped.\nL2-to-L1 message-based calls​\nCalls from L2-to-L1 operate similarly, using a message-based system. An L2 contract can call a method of the precompiled ArbSys contract to send a transaction to L1. When the execution of the L2 transaction containing the submission is confirmed at L1 (some days later), a message is created in the L1 outbox contract. That message can be triggered by anyone who calls a certain L1 outbox method and submits the L2-to-L1 message proof. The message is only marked as redeemed if the L1 transaction does not revert.\nThese L2-to-L1 messages have an unlimited lifetime, until they're successfully redeemed. No rent is required, as the messages (actually a Merkle hash of the messages) are stored on the Ethereum blockchain, which does not require rent. (The cost of allocating storage for the message Merkle roots is covered by L2 transaction fees.)\nCosts​\nGas is used by Arbitrum to track execution costs on a Nitro chain. It works the same as Ethereum gas: every EVM instruction costs the same amount of gas as it would on Ethereum.\nThe speed limit​\nThe security of Nitro chains depends on the assumption that when one validator proposes an assertion, other validators will check it and respond with a correct assertion or a challenge if it is wrong. This requires that the other validators have the time and resources to quickly check each assertion and issue a timely challenge. The Arbitrum protocol accounts for this when setting the timing of assertions' challenges.\nThis sets an effective speed limit on execution of a Nitro chain: in the long run, the chain cannot make progress faster than a validator can emulate its execution. The fee mechanism described below enforces this directly, by raising the L2 gas price when sustained usage exceeds the speed limit.\nSetting the speed limit accurately depends on estimating the time required to validate a unit of execution with accuracy. Any uncertainty in estimating validation time will force us to set the speed limit lower, to be safe. And we do not want to lower the speed limit, so we aim to enable accurate estimation.\nFees​\nUser transactions pay fees to cover the chain's operating costs. These fees are assessed and collected by ArbOS at the L2 level. They are denominated in ETH.\nFees are charged for two resources that a transaction can use:\n\nL2 gas: an Ethereum-equivalent amount of gas, as required to execute the transaction on the Nitro chain.\nL1 data: a fee per unit of L1 data attributable to the transaction, which is charged only if the transaction came in via the Sequencer, and is paid to the Sequencer to cover its costs.\n\nL2 gas fees​\nL2 gas fees work very similarly to Ethereum's gas fees. A transaction consumes some amount of gas, which is multiplied by the current basefee to determine the L2 gas fee charged to the transaction.\nThe L2 basefee is set by a version of the \"exponential mechanism\" that has been widely discussed in the Ethereum community and shown to closely approximate Ethereum's EIP-1559 gas pricing mechanism.\nThe algorithm compares gas usage against a parameter called the \"speed limit,\" which is the largest amount of gas per second that the chain can handle sustainably over time. (The speed limit on Arbitrum One was initially set to 7,000,000 gas per second; it is a parameter that can be adjusted by chain governance.) The algorithm tracks a gas backlog. Whenever a transaction consumes gas, that gas is added to the backlog. Whenever the clock ticks one second, the speed limit is subtracted from the backlog, but the backlog can never go below zero.\nIntuitively, if the backlog grows, the algorithm should increase the gas price to slow gas usage, because usage is above the sustainable level. If the backlog shrinks, the price should decrease again because usage has been below the sustainable limit, so more gas usage can be welcomed.\nTo make this more precise, the basefee is an exponential function of the backlog, F = exp(a(B-b)), where a and b are suitably chosen constants: a controls how rapidly the price escalates with the backlog, and b allows a small backlog before the basefee escalation begins.\nL1 data fees​\nL1 data fees exist because the Sequencer, or the batch poster that p","tokens":15000,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257614347,"hash":"ce80142446821a789ee619ec6eb2f8013eaa5cc1"}
{"url":"https://www.openzeppelin.com/customer-stories/wisdomtree","domain":"openzeppelin.com","title":"How WisdomTree brings tokenized funds to market safely with OpenZeppelin","text":"WisdomTree is a $160B NYSE-listed institutional asset manager bringing regulated funds onchain. Its tokenization platform enforces real-world compliance directly in the contracts that hold and move regulated assets across multiple blockchain networks, including onchain KYC/AML, transfer restrictions, and administrative controls. Tokenizing regulated funds is one of the most closely watched categories in onchain finance, and the trust model behind it is the product itself.The ChallengeBringing a regulated asset manager's funds onchain demands an exceptionally high standard of security. The product is the trust model: tokenized funds have to enforce real-world compliance onchain while holding up to institutional risk and diligence requirements. Three pressures defined the kind of security provider WisdomTree needed:Compliance cannot be bolted on, it has to be enforced in the contracts: WisdomTree's design encodes KYC/AML onchain through soulbound credential tokens, a whitelist compliance oracle, transfer restrictions, and administrative controls such as freeze, pause, and clawback. Each of those mechanisms is a potential failure point, and a single gap could let a non-compliant party hold or move a regulated asset.Coverage had to span architectures no single team builds for natively: WisdomTree's roadmap runs across very different blockchain architectures, from Ethereum to Solana. Risks that surface on one often have no equivalent on the other, so each environment had to be secured on its own terms rather than fragmented across boutique firms specialized in a single chain.Institutional pace, with security as a continuous program: the platform is not a single launch but an evolving system of new token standards, new compliance logic, and new chains, each gated on security review. A point-in-time audit cadence is structurally incompatible with that roadmap, so security had to be built into it.WisdomTree needed a security provider that could reason about regulated-asset compliance logic, work fluently across very different blockchain architectures, and provide continuous coverage rather than one-off checkpoints.OpenZeppelin's SolutionA Continuous Security Program Built Into the RoadmapOpenZeppelin delivers the Continuous Security Program to WisdomTree as an ongoing engagement rather than a sequence of point-in-time audits. A dedicated team of senior researchers, project managers, and technical leads carries context across every engagement, retained across rounds at the client's request, so each review compounds on the last rather than starting from scratch.Coverage spans architecture, code, and deployment, so new token standards, new compliance logic, and new chains ship with the security signal in place from design through production.Coverage Across Every Architecture WisdomTree Ships OnSecuring a regulated fund token on Ethereum and on Solana requires genuine depth in both Solidity and Rust, not surface-level review. OpenZeppelin's researchers cover both environments to the same standard, closing the seams that appear when a tokenization platform expands across very different virtual machines. Reviews span the full surface area of WisdomTree's stack: the whitelist and compliance layer that gates transfers to KYC/AML-approved holders, the ERC-20 token suite extending the standard with freezing, pausing, whitelisting, and administrative clawback, and the Solana programs that enforce the same regulated fund lifecycle and onchain compliance at the moment of every transfer. The result is one consistent assurance signal for WisdomTree's integrators and counterparties regardless of chain.Deployment Verification That Catches Issues Before Users DoOpenZeppelin's coverage extends from architecture and design review into the code itself and toward deployment. On the Solana fund programs, the review surfaced four critical-severity issues in compliance and role-management logic, every one identified at review time and remediated before the system went live, before any user funds were exposed. This pre-deployment assurance is exactly the kind of continuous control institutional issuers increasingly require as evidence that what was audited is what gets deployed.“Bringing regulated funds onchain means security and compliance have to be inseparable, and they have to hold across every environment we build on. OpenZeppelin has been a continuous security provider from architecture through deployment, across both our Ethereum and Solana work, and this consistency and rigor allows us to advance WisdomTree’s tokenization roadmap confidently, at scale.”— Jason Guthrie, Head of Product, WisdomTree Digital AssetsThe ResultsA Clean Security Record for Regulated TokenizationAcross three security audits and a design review with OpenZeppelin, WisdomTree has built a repeatable assurance process for its regulated tokenization platform. The reviews found no high-severity issues, and all critical findings were identified and remediated before deployment. For a regulated asset manager bringing funds onchain, this is the result that matters: continuous coverage produces the evidence base that supports confidence in the platform across the team and its stakeholders.Real-World Assets Onchain at Institutional ScaleContinuous security across both Ethereum and Solana underpins WisdomTree's onchain platform at institutional scale:Approximately $790 million in tokenized fund assets onchainA full lineup of regulated tokenized funds spanning money market, US Treasuries, equities, and private credit, among the largest on public blockchainsRegulated tokenized funds issued and held natively across 8 blockchain networks, from Ethereum to SolanaSupporting secure deployment across many networks is central to how WisdomTree scales. Continuous security across both Ethereum and Solana gives it the assurance foundation to keep extending its platform while preserving its regulated product structure.One Standard, Every Chain WisdomTree Ships OnA single security provider carrying context across both architectures closed the seams that fragmenting across multiple firms would have created, and gave WisdomTree one engagement model instead of several to coordinate. Integrators and counterparties receive the same assurance signal regardless of which chain a fund is issued on, giving WisdomTree the confidence to extend its tokenization platform, new standards, new compliance logic, new chains, while sustaining the trust its institutional model depends on.The security standard for onchain financeTalk to an Expert","tokens":1643,"squid":"ink-security_audits","role":"Sentinel","at":1791257616681,"hash":"4b95d8014b24d28889a049d1f461b11fa00efe86"}
{"url":"https://gov.optimism.io/t/builder-grant-proposal-ag-semantic-compression-engine-4-00x-calldata-compression-33m-tx-s/10817/2","domain":"gov.optimism.io","title":"[Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s) - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 19\n\n 2 / 3\n\n Aug 25\n\n Aug 25\n\n post by ProtoArchitect on Aug 19\n\n ProtoArchitect\n\n Hello Optimism Collective,\nWe have developed Ag^τ, a proprietary, zero-FPU semantic compression engine designed to reduce L1 calldata costs and lower hardware overhead for EVM rollups.\nAs Optimism scales, L1 data availability remains a significant cost center. While generic statistical compressors like Zstd provide roughly a 1.5x compression ratio on EVM transactions, Ag^τ uses a deterministic topological spiral accumulator to achieve a 4.00x compression ratio on standard EVM mempool data.\nCore Engineering Features\n1. 4.00x L1 Calldata Compression\nBy utilizing EVM-specific semantic dictionaries and address-deduplication, Ag^τ allows the op-batcher to pack 4 times more transactions into every L1 Ethereum block compared to current Zstd implementations. This directly reduces L1 footprint and lowers end-user gas fees.\n2. Zero-Copy Semantic Peeking (O(1) Data Access)\nWith Zstd, an RPC node or sequencer must decompress an entire block into heap memory just to extract a single transaction. Ag^τ implements a 1-byte semantic header system. This allows the op-node to perform zero-copy peeking: instantly parsing transaction metadata and extracting specific witnesses in O(1) time, without invoking the decompressor or allocating heap RAM.\n3. 33,000,000+ tx/s Pure L1/L2 Cache Throughput\nAg^τ requires zero heap allocations per-transaction, avoiding memory bus bottlenecks completely. In our bare-metal benchmarks, a single CPU core processes ~1.4M tx/s. When pinned across a standard 24-core Linux server, the engine scales linearly, achieving over 33.6M tx/s aggregate throughput (~36 nanoseconds per transaction).\n4. Cross-Platform Determinism\nRollup consensus requires strict determinism. Ag^τ is strictly Zero-FPU, utilizing custom Q32.32 fixed-point arithmetic for its internal state. The entire verifier is #![no_std] ready and cross-compiles to WebAssembly, ensuring exact consensus matching between L1 smart contracts and L2 nodes.\nProposal for Optimism\nWe are seeking a Builder Grant to fund the integration of the Ag^τ decompressor into the Optimism OP Stack (op-node / op-batcher). We believe this infrastructure upgrade will significantly improve the Superchain’s DA cost efficiency.\nPrivate Evaluation Kit\nThe core compression algorithms and semantic dictionary structures are our proprietary IP. However, we have prepared a closed-source Evaluation Kit (ag-tau-eval-kit) — a compiled Linux x86_64 binary with a built-in benchmarking script.\nIf any core contributor, OP Labs engineer, or delegate wants to validate our 4.00x ratio and throughput on their own hardware, please reach out via direct message or reply to this thread. We will provide private GitHub access to the Evaluation Kit repository under NDA.\nWe look forward to your feedback.\n\n 2\n\n post by Anzus_GemWallet on Aug 25\n\n Anzus_GemWallet\n\n For those of us without a deep technical background, could you explain how the claimed 4x compression would translate into transaction-fee savings for a typical OP Mainnet user? It would also help to know what transaction dataset was used for the comparison.\n\n post by ProtoArchitect on Aug 25\n\n ProtoArchitect\n\n Hi Anzus,\nThanks for raising this! Let’s break down how these technical milestones translate directly into real-world value for everyday OP Mainnet users.\n1. How 4.00x Compression Translates to Transaction Fees\nOn L2 rollups like OP Mainnet, a user’s transaction fee is composed of two main elements:\n\nL2 Execution Fee: The cost of executing the computation on the sequencer (typically a small fraction of the total cost).\n\nL1 Data (DA) Fee: The cost of publishing transaction batch data back to Ethereum L1 for global availability and security. This represents 80% to 90% of what an average user pays.\n\nWhile general-purpose statistical compressors like Zstd achieve roughly a 1.5x compression ratio on EVM transactions, Ag^τ achieves a 4.00x compression ratio by utilizing EVM-specific semantic dictionaries and address-deduplication.\n\nThe Impact: By allowing the op-batcher to pack 4 times more transactions into every L1 Ethereum block, we drastically shrink the L1 data footprint. Because the expensive L1 data-posting component drops significantly, end-user gas fees on OP Mainnet become notably cheaper—especially during periods of high L1 network congestion.\n\n2. The Transaction Dataset Used for Comparison\nThe 4.00x benchmark figures were evaluated using a standardized, production-grade corpus consisting of:\n\nStandard EVM Mempool Data & OP Mainnet Batch Captures: A high-entropy mix containing tens of thousands of transactions, including standard token transfers, complex multi-hop DEX swaps, and heavy smart contract interactions.\n\nBecause Ag^τ relies on a deterministic topological spiral accumulator rather than generic sliding-window string matching, its efficiency scales particularly well with the complex, data-dense transaction patterns typical of active L2 usage on the Superchain.\n\nHappy to provide more details or coordinate access to the ag-tau-eval-kit if you’d like to run benchmarks yourself!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Optimism fundamentals by Token Terminal\n\n Accountability 🗂️\n\n A space to discuss the fundamentals of ‘Optimism’. \nHey Optimism community \nWe at Token Terminal have introduced a governance forum for public discussion around the data displayed on the platform. \nGoing forward, …\n\n read more\n\n 7\n\n 1.7k\n\n Jul 2023\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Railgun Zero Knowledge Proofs\n\n ✨ General\n\n How about getting Railgun on Optimism? \nI’m sure there’s lots of use cases for private transactions on Optimism.\n\n 0\n\n 1.8k\n\n May 2022\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n Introducing The TEC Rollup Report: Your Monthly Guide to the L2 Ecosystem & Optimism’s Progress\n\n ✨ General\n\n Hello Optimism community, \nWe are pleased to introduce The TEC Rollup Report, a new monthly newsletter specifically designed for builders and users engaged with Layer 2 solutions. \nOur mission is to provide a clear, cura…\n\n read more\n\n 1\n\n 81\n\n Jul 2025","tokens":1747,"squid":"ink-governance","role":"Council Listener","at":1791257626346,"hash":"6ae2cc4cf3843da53424da6f09e4f3773dc7d165"}
{"url":"https://aave.com/docs/vaults/simple-earn/management","domain":"aave.com","title":"Earn Vault Management | Aave Protocol Documentation","text":"Aave Earn Vault Management#\nManage your deployed vaults with fee configuration and revenue collection.\nSet Vault Fee#\nThe fee for a vault has to be at least 10%.\nUpdate the performance fee for your vault (vault owner only).\n1Identify the Vault#First, identify the vault you want to update the fee for.Let's say we have identified a vault that we own with the following details:const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", owner: \"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\", // Your address shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { __typename: \"Reserve\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, // … }, fee: { __typename: \"PercentValue\", raw: \"50000000000000000000000000\", decimals: 27, value: \"0.11\", formatted: \"11\", // 11% performance fee }, totalFeeRevenue: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1250.75\", // Total fees collected // … }, // … }, // …};You must be the vault owner to update the fee.2Prepare the Transaction Request#Next, create the transaction request for updating the vault fee.ReactTypeScriptGraphQLUse the useVaultSetFee hook to create the transaction request for updating the vault fee.import { useWalletClient } from \"wagmi\";import { useVaultSetFee, bigDecimal } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [setFee, settingFee] = useVaultSetFee();\nconst result = await setFee({ chainId: vault.chainId, vault: vault.address, newFee: bigDecimal(15), // 15% performance fee});\n// …3Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useVaultSetFee } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [setFee, settingFee] = useVaultSetFee();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = settingFee.loading || sending.loading;const error = settingFee.error || sending.error;\n// …\nconst result = await setFee({ // …}).andThen(sendTransaction);\nif (result.isErr()) { console.error(\"Set fee failed:\", result.error);} else { console.log(\"Set fee successful with hash:\", result.value);}\nWithdraw Fees#\nWithdraw accumulated fees from your vault (vault owner only).\nWithdrawn fees are received in the form of the underlying Reserve aTokens.\n1Identify the Vault#First, identify the vault you want to withdraw fees from.Let's say we have identified a vault that we own with accumulated fees:const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", owner: \"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\", // Your address shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { __typename: \"Reserve\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, // … }, fee: { __typename: \"PercentValue\", raw: \"150000000000000000000000000\", decimals: 27, value: \"0.15\", formatted: \"15\", // 15% performance fee }, totalFeeRevenue: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1250.75\", // Total fees collected - available for withdrawal // … }, usd: \"1250.75\", // … }, feesBalance: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"100.00\", // Fees currently available for withdrawal // … }, usd: \"100.00\", // … }, // …};You must be the vault owner to withdraw fees.2Prepare the Transaction Request#Next, create the transaction request for withdrawing fees.ReactTypeScriptGraphQLUse the useVaultWithdrawFees hook to create the transaction request for withdrawing fees.import { useWalletClient } from \"wagmi\";import { useVaultWithdrawFees, bigDecimal } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdrawFees, withdrawingFees] = useVaultWithdrawFees();\nconst result = await withdrawFees({ chainId: vault.chainId, vault: vault.address, amount: { exact: bigDecimal(1000), // 1000 USDC worth of fees }, // sendTo: evmAddress(\"0x1234…\"), if different from vault owner});\n// …3Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useVaultWithdrawFees } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdrawFees, withdrawingFees] = useVaultWithdrawFees();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = withdrawingFees.loading || sending.loading;const error = withdrawingFees.error || sending.error;\n// …\nconst result = await withdrawFees({ // …}).andThen(sendTransaction);\nif (result.isErr()) { console.error(\"Withdraw fees failed:\", result.error);} else { console.log(\"Withdraw fees successful with hash:\", result.value);}\nTransfer Vault Ownership#\nTransfer the ownership of a vault to a new address (vault owner only).\n1Identify the Vault#First, identify the vault you want to transfer the ownership of.Let's say we have identified a vault that we own with the following details:const vault: Vault = { __typename: \"Vault\", address: \"0x1234567890abcdef1234567890abcdef12345678\", owner: \"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\", // Your address shareName: \"Aave USDC Vault Shares\", shareSymbol: \"avUSDC\", chainId: 1, usedReserve: { // … }, fee: { // … }, totalFeeRevenue: { // … }, // …};You must be the vault owner to transfer the ownership.2Prepare the Transaction Request#Next, create the transaction request for transferring the ownership of the vault.ReactTypeScriptGraphQLUse the useVaultTransferOwnership hook to create the transaction request for transferring the ownership of the vault.import { useVaultTransferOwnership, evmAddress } from \"@aave/react\";\n// …\nconst [transferOwnership, transferring] = useVaultTransferOwnership();\nconst result = await transferOwnership({ chainId: vault.chainId, vault: vault.address, newOwner: evmAddress(\"0x1234567890abcdef1234567890abcdef12345678\"),});\n// …3Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useVaultTransferOwnership } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [transferOwnership, transferringOwnership] = useVaultTransferOwnership();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = transferringOwnership.loading || sending.loading;const error = transferringOwnership.error || sending.error;\n// …\nconst result = await transferOwnership({ // …}).andThen(sendTransaction);\nif (result.isErr()) { console.error(\"Transfer ownership failed:\", result.error);} else { console.log(\"Transfer ownership successful with hash:\", result.value);}PreviousEarn Vault Operations","tokens":1830,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257632161,"hash":"6aabdcab58990fec609f2a8684ab922a29986c40"}
{"url":"https://docs.arbitrum.io/notices/arbos61-upgrade-notice","domain":"docs.arbitrum.io","title":"Upgrade notice for ArbOS 61 | Arbitrum Docs","text":"✏️Request an updateArbOS 61 \"Elara\" is active on Arbitrum Sepolia, Arbitrum One, and Arbitrum Nova. It activated on Arbitrum One and Arbitrum Nova on Thursday, August 20, 2026.\nAction requiredIf you run a node on these chains, you must run Nitro v3.11.3 or higher to sync.\nDocker image: offchainlabs/nitro-node:v3.11.3-beb2108\nRelease notes: https://github.com/OffchainLabs/nitro/releases/tag/v3.11.3\nWASM module root: 0xc10cd7ec6acaf1c441a3f6bd0900ad20f15855ba775a96f1939118cbc629dc97 (consensus-v61)\n\nActions required for node operators​\nSepolia network​\nArbOS 61 activated on the Arbitrum Sepolia chain on Monday, June 29, 2026, at 15:00 UTC.\nArbitrum One and Arbitrum Nova​\nThe ArbitrumDAO approved ArbOS 61 for Arbitrum One and Arbitrum Nova in a Constitutional onchain vote. After the waiting periods and phases set out in the ArbitrumDAO Constitution, ArbOS 61 activated on both chains on Thursday, August 20, 2026.\nThe Arbitrum DAO network upgrades table records the exact activation time of each chain.\nImportant dates​\nThe following dates are relevant for Arbitrum chain operators.\nDateNetwork upgradeAffected audienceMonday, June 29, 2026 at 15:00 UTCArbitrum Sepolia upgrade to ArbOS 61Node operators running Arbitrum SepoliaThursday, August 20, 2026 at 17:00 UTCArbitrum One/Nova upgrade to ArbOS 61Node operators running Arbitrum One/Nova\nActions for Arbitrum chain owners​\nArbOS 61 has run on Arbitrum One for more than 30 days. You can upgrade your Arbitrum chain now.\nTo upgrade, follow How to upgrade ArbOS on your Arbitrum chain and the nitro-contracts upgrade instructions. Use the Nitro version, Docker image, and WASM module root listed above.\nArbOS 61 lets your chain collect priority fees. Do not enable Priority Gas Auctions (PGA) or priority fee collection on your chain yet. Offchain Labs updates this notice when chain operators can enable them.\nDo not enable multi-dimensional gas pricingDo not call setMultiGasPricingConstraints on the ArbOwner precompile. ArbOS 61 ships multi-dimensional gas pricing in the node software, but a future Nitro version removes it. If your chain has it enabled when that version ships, your chain forks.You can now use multi-constraint pricing with a single gas dimension. To configure it, call setGasPricingConstraints as described in Dynamic Pricing for Arbitrum chains.\nContext​\nArbOS 61 \"Elara\" builds upon ArbOS 51 \"Dia\". It makes two changes to Arbitrum One and Nova: it raises the Stylus contract code size limit to 96 KB, and it adds a BaseFeeManager contract that manages the minimum L2 base fee.\nArbOS 61 also ships three optional features. A chain owner must enable each one explicitly:\n\nAlternative Data Availability (AltDA) Layer API. Disabled on Arbitrum One and Nova. It requires nitro-contracts v3.2.0 or higher. To learn how to build a custom DA provider against the new API, refer to How to integrate with the DA API.\nCompliance transaction filtering. Disabled on Arbitrum One and Nova. On a live chain, filtering takes effect seven days after the chain owner enables it. To learn how transaction filtering works, refer to Compliance filtering.\nPriority fee collection. Enabled on Arbitrum One since September 23, 2026, together with PGA. Disabled on Nova. To learn how to enable it, refer to Priority fee collection.\n\nArbOS 61 corrects two interacting bugs in the gas refund logic that were found while testing ArbOS 60 on Arbitrum Sepolia. The fixes change the State Transition Function (STF), so they required a new ArbOS version. ArbOS 60 never activated on Arbitrum One or Nova, so neither chain was affected.\nArbOS 61 passed a Snapshot temperature check and then a Constitutional onchain vote, which closed on August 1, 2026. To learn more about the proposal, refer to the ArbOS 61 Elara AIP.Actions required for node operatorsSepolia networkArbitrum One and Arbitrum NovaImportant datesActions for Arbitrum chain ownersContext","tokens":978,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257635788,"hash":"3b6120d4903f37ca4db952afa14f92e0eed5c7e0"}
{"url":"https://gov.optimism.io/t/builder-grant-proposal-ag-semantic-compression-engine-4-00x-calldata-compression-33m-tx-s/10817/3","domain":"gov.optimism.io","title":"[Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s) - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 19\n\n 3 / 3\n\n Aug 25\n\n Aug 25\n\n post by ProtoArchitect on Aug 19\n\n ProtoArchitect\n\n Hello Optimism Collective,\nWe have developed Ag^τ, a proprietary, zero-FPU semantic compression engine designed to reduce L1 calldata costs and lower hardware overhead for EVM rollups.\nAs Optimism scales, L1 data availability remains a significant cost center. While generic statistical compressors like Zstd provide roughly a 1.5x compression ratio on EVM transactions, Ag^τ uses a deterministic topological spiral accumulator to achieve a 4.00x compression ratio on standard EVM mempool data.\nCore Engineering Features\n1. 4.00x L1 Calldata Compression\nBy utilizing EVM-specific semantic dictionaries and address-deduplication, Ag^τ allows the op-batcher to pack 4 times more transactions into every L1 Ethereum block compared to current Zstd implementations. This directly reduces L1 footprint and lowers end-user gas fees.\n2. Zero-Copy Semantic Peeking (O(1) Data Access)\nWith Zstd, an RPC node or sequencer must decompress an entire block into heap memory just to extract a single transaction. Ag^τ implements a 1-byte semantic header system. This allows the op-node to perform zero-copy peeking: instantly parsing transaction metadata and extracting specific witnesses in O(1) time, without invoking the decompressor or allocating heap RAM.\n3. 33,000,000+ tx/s Pure L1/L2 Cache Throughput\nAg^τ requires zero heap allocations per-transaction, avoiding memory bus bottlenecks completely. In our bare-metal benchmarks, a single CPU core processes ~1.4M tx/s. When pinned across a standard 24-core Linux server, the engine scales linearly, achieving over 33.6M tx/s aggregate throughput (~36 nanoseconds per transaction).\n4. Cross-Platform Determinism\nRollup consensus requires strict determinism. Ag^τ is strictly Zero-FPU, utilizing custom Q32.32 fixed-point arithmetic for its internal state. The entire verifier is #![no_std] ready and cross-compiles to WebAssembly, ensuring exact consensus matching between L1 smart contracts and L2 nodes.\nProposal for Optimism\nWe are seeking a Builder Grant to fund the integration of the Ag^τ decompressor into the Optimism OP Stack (op-node / op-batcher). We believe this infrastructure upgrade will significantly improve the Superchain’s DA cost efficiency.\nPrivate Evaluation Kit\nThe core compression algorithms and semantic dictionary structures are our proprietary IP. However, we have prepared a closed-source Evaluation Kit (ag-tau-eval-kit) — a compiled Linux x86_64 binary with a built-in benchmarking script.\nIf any core contributor, OP Labs engineer, or delegate wants to validate our 4.00x ratio and throughput on their own hardware, please reach out via direct message or reply to this thread. We will provide private GitHub access to the Evaluation Kit repository under NDA.\nWe look forward to your feedback.\n\n 2\n\n post by Anzus_GemWallet on Aug 25\n\n Anzus_GemWallet\n\n For those of us without a deep technical background, could you explain how the claimed 4x compression would translate into transaction-fee savings for a typical OP Mainnet user? It would also help to know what transaction dataset was used for the comparison.\n\n post by ProtoArchitect on Aug 25\n\n ProtoArchitect\n\n Hi Anzus,\nThanks for raising this! Let’s break down how these technical milestones translate directly into real-world value for everyday OP Mainnet users.\n1. How 4.00x Compression Translates to Transaction Fees\nOn L2 rollups like OP Mainnet, a user’s transaction fee is composed of two main elements:\n\nL2 Execution Fee: The cost of executing the computation on the sequencer (typically a small fraction of the total cost).\n\nL1 Data (DA) Fee: The cost of publishing transaction batch data back to Ethereum L1 for global availability and security. This represents 80% to 90% of what an average user pays.\n\nWhile general-purpose statistical compressors like Zstd achieve roughly a 1.5x compression ratio on EVM transactions, Ag^τ achieves a 4.00x compression ratio by utilizing EVM-specific semantic dictionaries and address-deduplication.\n\nThe Impact: By allowing the op-batcher to pack 4 times more transactions into every L1 Ethereum block, we drastically shrink the L1 data footprint. Because the expensive L1 data-posting component drops significantly, end-user gas fees on OP Mainnet become notably cheaper—especially during periods of high L1 network congestion.\n\n2. The Transaction Dataset Used for Comparison\nThe 4.00x benchmark figures were evaluated using a standardized, production-grade corpus consisting of:\n\nStandard EVM Mempool Data & OP Mainnet Batch Captures: A high-entropy mix containing tens of thousands of transactions, including standard token transfers, complex multi-hop DEX swaps, and heavy smart contract interactions.\n\nBecause Ag^τ relies on a deterministic topological spiral accumulator rather than generic sliding-window string matching, its efficiency scales particularly well with the complex, data-dense transaction patterns typical of active L2 usage on the Superchain.\n\nHappy to provide more details or coordinate access to the ag-tau-eval-kit if you’d like to run benchmarks yourself!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Optimism fundamentals by Token Terminal\n\n Accountability 🗂️\n\n A space to discuss the fundamentals of ‘Optimism’. \nHey Optimism community \nWe at Token Terminal have introduced a governance forum for public discussion around the data displayed on the platform. \nGoing forward, …\n\n read more\n\n 7\n\n 1.7k\n\n Jul 2023\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Railgun Zero Knowledge Proofs\n\n ✨ General\n\n How about getting Railgun on Optimism? \nI’m sure there’s lots of use cases for private transactions on Optimism.\n\n 0\n\n 1.8k\n\n May 2022\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n Introducing The TEC Rollup Report: Your Monthly Guide to the L2 Ecosystem & Optimism’s Progress\n\n ✨ General\n\n Hello Optimism community, \nWe are pleased to introduce The TEC Rollup Report, a new monthly newsletter specifically designed for builders and users engaged with Layer 2 solutions. \nOur mission is to provide a clear, cura…\n\n read more\n\n 1\n\n 81\n\n Jul 2025","tokens":1747,"squid":"ink-governance","role":"Council Listener","at":1791257639289,"hash":"873b1a93c33726a28ce671341830efc669e1428b"}
{"url":"https://aave.com/docs/vaults/stable-vaults/architecture","domain":"aave.com","title":"Stable Vault Architecture | Aave Protocol Documentation","text":"Stable Vault Architecture#\nThe system is split across an Accounting Chain and one or more Earning Chains. The Accounting Chain is the source of truth for user balances, the system surplus, and withdrawal accounting. Earning Chains host yield strategies and periodically publish balance snapshots back to the Accounting Chain through a Chainlink-powered oracle feed. An off-chain system monitors protocol state and submits rebalance and bridge transactions.\nAccounting Chain#\nThe Accounting Chain handles deposits, withdrawal requests, share accounting, and surplus gating. For the Aave App, the Accounting Chain is Arbitrum.\nThe Stable Vault is the user entrypoint. It validates asset prices through the Price Oracle on each deposit, mints shares into the user's assigned SubVault, and manages the two-step withdrawal flow. On requestWithdrawal, shares are burned and IOU tokens are minted representing a denomination currency claim. The principal portion of a position is always redeemable as IOUs; the interest portion is gated by the system's trusted surplus. On executeWithdrawal, IOUs are burned, the Withdrawal Execution Policy applies any fees, and the user receives their chosen output asset. Share positions can be transferred between users via transfer and transferAll.\nThe Funds Handler sits between the Stable Vault and the Allocator. It aggregates the total price-weighted asset value across local balances and registered Earning Chains by querying the Chain Balance Oracle on demand for remote chain data. Stale Earning Chain data contributes zero to the aggregation, so the system conservatively underestimates its surplus rather than overstating it. This protects depositors by not inflating the global interest pool earned by the Stable Vault's assets.\nThe Allocator holds idle assets and executes rebalances. It maintains an approved list of ERC-4626 strategy contracts and handles swaps through a dedicated Swapper. Swaps enforce a nominal one-to-one exchange rate, with any slippage or venue fees covered by an external Slippage Coverage Vault rather than customer deposits. User deposits land idle on the Allocator and are allocated to strategies by the off-chain manager via rebalance(), so strategy-side issues such as supply cap breaches or paused markets do not block user deposits.\nThe Accounting Chain Gateway routes outbound funds and messages to Earning Chains and ingests inbound messages. It validates inbound message block numbers against the Chain Balance Oracle to preserve accounting integrity.\nEarning Chains#\nEarning Chains (Ethereum mainnet initially) host yield strategies and the infrastructure needed to exchange IOUs for local assets and return funds to the Accounting Chain.\nFunds and messages move between the Accounting Chain and Earning Chains through multiple bridge providers, such as CCIP, LayerZero, Hyperlane, and Across, as well as potentially others, as long as their usage follows the protocol's security requirements.\nThe Earning Chain Gateway handles inbound bridge messages, exchanges IOU tokens for local assets against available liquidity, and pushes funds back to the Accounting Chain when needed. It computes price-weighted local balances using the same aggregation logic as the Funds Handler.\nThe Earning Chain State Provider exposes the local price-weighted balance in an encoded format that Chainlink operators read and publish to the Accounting Chain via the Chain Balance Oracle. Feed updates are triggered by specific on-chain events such as funds received or sent and asset trust status changes, by a configured deviation threshold, and by a fixed heartbeat interval. The Accounting Chain treats data older than the configured staleness threshold as zero, keeping the surplus accounting conservative.\nRoles & Access Controls#\nThe protocol separates configuration authority from operational authority through a role hierarchy. Higher roles define the boundaries; lower roles operate within them.\nIntegrators hold the broadest authority. They configure the total trusted surface of the vault:\nAssets: which stablecoins can be deposited, swapped, or used as withdrawal outputs (via the Asset Registry)Yield strategies: which ERC-4626 adapters are approved on the Allocator (e.g. Aave v4 markets, sGHO, or any other compliant vault)Bridges: which cross-chain bridge contracts are permitted for moving funds between the Accounting Chain and Earning Chains\nThese allowlists are additive: a manager can never access a strategy, asset, or bridge that the integrator has not explicitly approved.\nManagers operate within whatever the integrator has configured. A manager can:\nCall rebalance() to shift allocations between approved yield strategiesInitiate bridge transfers to/from approved Earning ChainsAdjust yield allocations in response to changing market conditions\nManagers cannot modify the allowlists or claim protocol revenue, those actions are reserved for the integrator role.\nThis separation means a fintech deploying a vault can lock down protocol-level risk (which counterparties are trusted, which assets move) while safely delegating routine yield operations to an automated off-chain system or third-party manager without exposing configuration authority.\nRequest IntegrationPreviousFeaturesNextYield Strategies","tokens":1322,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257642083,"hash":"2ecaf8c9166cdc7d68b13fd97ff179dcefccac99"}
{"url":"https://docs.arbitrum.io/notices/glamsterdam-sepolia-notice","domain":"docs.arbitrum.io","title":"Glamsterdam compatibility notice for Arbitrum Sepolia chains | Arbitrum Docs","text":"✏️Request an updateEthereum Sepolia activates the Glamsterdam hard fork on Tuesday, October 6, 2026, at 13:53:36 UTC. This notice is parent chain compatibility guidance. It does not require an ArbOS upgrade.\nAction requiredIf you run an Arbitrum Sepolia node, or a node for an Arbitrum chain that settles on Ethereum Sepolia, upgrade to Nitro v3.11.4 or higher before October 6, 2026.\nDocker image: offchainlabs/nitro-node:v3.11.4-7d5ac27\nRelease notes: https://github.com/OffchainLabs/nitro/releases/tag/v3.11.4\n\nWho is this notice for?​\nThis notice applies to you if you run either of the following:\n\nAn Arbitrum Sepolia node. Upgrade Nitro before the activation.\nAn Arbitrum chain that settles on Ethereum Sepolia. Upgrade Nitro on every node of your chain, pause the batch poster around the activation, and read the batch poster and blob sections below.\n\nThis notice does not apply to:\n\nArbitrum One, Arbitrum Nova, or Arbitrum chains that settle on Ethereum mainnet. Ethereum mainnet has no scheduled Glamsterdam activation date.\nArbitrum chains that settle on another Arbitrum chain (L3s). Their parent chain is not Ethereum Sepolia.\n\nWhy the upgrade is required​\nGlamsterdam adds new fields to Ethereum block headers. Nitro v3.11.4 decodes these fields (EIP-7928 and EIP-7843) and reproduces the canonical parent chain block hash. Earlier Nitro releases do not.\nOffchain Labs will publish a newer release, Nitro v3.12.1, after this date. Upgrade to it when it is available.\nPause the batch poster around the activation​\nIf you run an Arbitrum chain that settles on Ethereum Sepolia, disable the batch poster about 15 minutes before the activation, at 13:38 UTC, and enable it again a few minutes after the fork.\nThe batch poster fixes its gas estimate when it first builds a batch transaction. A batch estimated before the fork and included after it can run out of gas under Glamsterdam's gas rules and keep failing.\nPausing has no impact on users. The sequencer keeps producing blocks, and the batches post once the batch poster is back on. To pause, set --node.batch-poster.enable=false. After the activation, set it back to true.\nBatch poster reimbursement​\nGlamsterdam raises the parent chain gas cost of each batch post. Your chain uses the perBatchGasCharge parameter to calculate how much it reimburses the batch poster. The current value reflects pre-Glamsterdam costs, so after activation the batch poster can receive less in reimbursements than it spends on each batch.\nOn Sepolia, the difference is a small amount of testnet ETH. Do not change perBatchGasCharge on Sepolia. Offchain Labs will publish the value to use before Ethereum mainnet activates Glamsterdam. To learn how the parameter works, refer to Configure and optimize gas.\nBlob configuration​\nIf your chain posts blobs to Ethereum Sepolia, turn off the automatic fallback to calldata. Set both batch poster flags:\n--node.batch-poster.post-4844-blobs=true--node.batch-poster.ignore-blob-price=true\nChains that post calldata need no change. To learn more about these flags, refer to Enabling blob transactions for Arbitrum batch poster.\nImportant dates​\nDateNetwork upgradeAffected audienceTuesday, October 6, 2026 at 13:53:36 UTCEthereum Sepolia Glamsterdam hard forkNode operators running Arbitrum Sepolia; operators of Arbitrum chains settling on Ethereum Sepolia\nThe activation point on Ethereum Sepolia is:\nFieldValueUTC timeOctober 6, 2026, 13:53:36Eastern timeOctober 6, 2026, 09:53:36 EDTEpoch353,024Slot11,296,768UNIX timestamp1791294816\nThis notice covers Ethereum Sepolia only. For the Sepolia schedule and client releases, refer to the Glamsterdam testnet announcement and EIP-7773.Who is this notice for?Why the upgrade is requiredPause the batch poster around the activationBatch poster reimbursementBlob configurationImportant dates","tokens":957,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257645733,"hash":"86bb2c3681bd6cd33fd4656ac02a0f43e035f422"}
{"url":"https://gov.optimism.io/t/optimism-fundamentals-by-token-terminal/5866","domain":"gov.optimism.io","title":"Optimism fundamentals by Token Terminal - Communications 📣 / Accountability 🗂️ - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Optimism fundamentals by Token Terminal \n\n Communications 📣Accountability 🗂️\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Apr 2023\n\n 1 / 8\n\n Apr 2023\n\n Jul 2023\n\n post by tt_velho on Apr 12, 2023\n\n tt_velho\n\n A space to discuss the fundamentals of ‘Optimism’.\nHey Optimism community \nWe at Token Terminal have introduced a governance forum for public discussion around the data displayed on the platform.\nGoing forward, we’ll start sharing Optimism-focused monthly data updates on the TT forum, and cross-post them here as well for further discussion.\nLooking forward to being an active participant in the OP community!\n\nLink to the dashboard: Optimism (OP) - Key metrics | Dashboard | Token Terminal \nLink to the governance forum: Optimism fundamentals\n\n 2\n\n 2\n\n post by tt_velho on Apr 12, 2023\n\n tt_velho\n\n Token Terminal <> Optimism | Monthly data update (March 2023)\nChains tracked: Optimism\nMethodology:\n\nFees: Total transaction fees paid by users\n\nSupply-side fees: Share of transaction fees that goes to Ethereum validators\n\nRevenue: Share of transaction fees that goes to the Sequencer\n\nToken incentives: USD value of the protocol’s governance tokens that have been distributed to protocols building on Optimism\n\nEarnings: Revenue minus token incentives\n\nTreasury: Monthly average USD value of the protocol’s funds held on-chain (including unallocated governance tokens)\n\nDaily active users: Monthly average number of daily distinct sender addresses\n\nActive developers: Monthly average number of distinct GitHub users that made 1+ commits to the project’s public GitHub repositories during the past 30 days\n\nCode commits: Number of commits to the project’s public GitHub repositories\n\nMetrics (March 2023):\n\nFees: $2.33m\n\nSupply-side fees: $1.90m\n\nRevenue: $427.88k\n\nToken incentives: $13.89m\n\nEarnings: $-13.46m\n\nTreasury: N/A\n\nDaily active users: 43.82k\n\nActive developers: 42\n\nCode commits: 794\n\nimage922×998 212 KB\n\n post by Mark.eth_De.Fi on Apr 12, 2023\n\n Mark.eth_De.Fi\n\n Interesting suggestion to track activity in the Optimism ecosystem right inside the forum, I like this idea\nThanks to the Token Terminal team for a similar implementation, I think it would be useful\n\n post by afrodi on Apr 16, 2023\n\n afrodi\n\n hello its good i like this choise adn very glad for u\n\n post by cryptoAYA on Apr 16, 2023\n\n cryptoAYA\n\n tt_velho\n\n greetings,\nIt really sounds like a great idea. Although it is a bit complicated. I have to spend some time on it to figure it out. An amazing idea to have a place to discuss Optimism matters profoundly.\n\n post by lianki on Apr 17, 2023\n\n lianki\n\n Hi there.\nToken Terminal is my favorite go to place for checking metrics.\nIn competition section of optimism I see polygon and arbitrum. But polygon is a separate chain and not a rollup and doesn’t have the same security of a rollup. I guess over time you can remove polygon and instead add zk rollups to get a better understanding of positioning of optimism among L2s.\nKindly,\nLian\n\n 3 months later\n\n post by tt_bobby on Jul 25, 2023\n\n tt_bobby\n\n Hey Lian!\nThank you for your feedback. Indeed, Polygon PoS is a sidechain, which is fundamentally different from a rollup. In the Blockchains (L2) market sector, you can filter out chains by clicking them in the chart’s legend (below the chart).\nBest regards,\ntt_bobby\n\n post by tt_bobby on Jul 25, 2023\n\n tt_bobby\n\n Token Terminal <> OP Mainnet | Monthly data update (June 2023)\nChains tracked: Ethereum, OP Mainnet\nMethodology:\n\nFees: Total transaction fees paid by users\nSupply-side fees: Share of transaction fees that goes to Ethereum validators\nRevenue: Share of transaction fees that goes to the Sequencer\nToken incentives: USD value of tokens that have been distributed to incentivise users\nEarnings: Revenue minus token incentives\nTreasury: Monthly average USD value of the protocol’s funds held on-chain (including unallocated governance tokens)\nDaily active users: Monthly average number of daily distinct Transaction senders\nWeekly active users: Monthly average number of weekly distinct Transaction senders\nMonthly active users: Monthly average number of monthly distinct Transaction senders\nCore developers: Monthly average number of distinct GitHub users that made 1+ commits to the project’s public GitHub repositories during the past 30 days\nCode commits: Number of commits to the project’s public GitHub repositories\n\nMetrics (June 2023):\n\nFees: $2.49m\nSupply-side fees: $1.77m\nRevenue: $724.74k\nToken incentives: $13.84m\nEarnings: $-13.12m\nTreasury (monthly average): N/A\nDaily active users (monthly average): 84.52k\nWeekly active users (monthly average): 421.05k\nMonthly active users (monthly average): 1.14m\nCore developers (monthly average): 48\nCode commits: 1.35k\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Bi-weekly OP Mainnet Onchain analysis (Second half of August)\n\n ✨ General\n\n ​This analysis was made for the numbaNERD program. \nI used DUNE, Arkham and Flipside for this analysis. All metrics except one of them come from the queries that I wrote myself. \nYou can find links for the embedded versi…\n\n read more\n\n 4\n\n 766\n\n Sep 2023\n\n Optimism Network Large Scale Adoption\n\n ✨ General\n\n From the 31st of May till June 1st Optimism had around 11,000 to at its peak 14,000 transactions per hour. Currently the network has an hourly tx traffic of around 2,000. \nThis is a significant decrease of network use. O…\n\n read more\n\n 2\n\n 1.9k\n\n Jun 2022\n\n Daily Active Users on-chain\n\n ✨ General\n\n We studied Optimism’s user base and it is on fire🔥 \nPYOR is a blockchain analytics firm and we work with protocols by giving high-fidelity insights. We have our own data product which we use to perform analysis and deliv…\n\n read more\n\n 0\n\n 241\n\n May 2024\n\n Optimism Quest Retrospect and Future Direction\n\n ✨ General\n\n Author: \nOptimism Quest Retrospect \nThe Optimism Quest has recently ended and the level of optimism network activation demonstrated during the event was amazing. The daily transaction volume and user count showed that Op…\n\n read more\n\n 25\n\n 3.3k\n\n Mar 2023\n\n Enabling $OP as a gas token on Optimism Network!\n\n ✨ General\n\n Enabling $OP as a gas token on Optimism Network! \nThe $OP token can be used to pay gas fees on the Optimism Network!. This is a major addition to the utility of the $OP token, and will …\n\n read more\n\n 144\n\n 18.9k\n\n Jun 2023","tokens":1628,"squid":"ink-governance","role":"Council Listener","at":1791257649636,"hash":"646c21e6e45d533667a83490fdd2b8e5e154e54d"}
{"url":"https://aave.com/docs/aave-v4","domain":"aave.com","title":"Aave v4 Overview | Aave Protocol Documentation","text":"Aave v4#\n\nAave v4 uses a Hub & Spoke model for liquidity management: the Liquidity Hub consolidates protocol-wide liquidity and accounting, while Spokes implement modular borrowing with isolated risk.\nThis evolves Aave v3’s market-per-pool design into a unified Hub & Spoke\nmodel, allowing governance to introduce new features or markets without\nmigrating liquidity.\nLiquidity Hubs#\nThe Liquidity Hub (Hub) is the central liquidity source in Aave v4. It maintains oversight of Spokes, granting each a credit line for borrowing and a debit line for supplying. The Hub enforces system‑wide accounting and caps how much liquidity Spokes can draw or add.\nCentralizes liquidity and accountingIssues per‑spoke credit/debit limitsEnforces system‑wide constraintsProvides emergency stop controls\nHub Assets#\nHub assets are the ERC‑20 tokens registered in the Liquidity Hub. They form the shared liquidity that Spokes borrow from and supply to, enabling efficient reuse across Spokes.\nSpokes#\nSpokes are modules that manage specific supply and borrowing use cases, asset types, or risk profiles. Users interact directly with Spokes, which route liquidity to and from the Hub.\nLocal controls (e.g., risk parameters, oracle interactions, emergency stops)Independent accounting per spokeModular: add/remove spokes without affecting others\nReserves#\nReserves define how a Hub asset is supplied and borrowed within a specific Spoke. Each reserve has its own risk settings—while the Hub controls how much liquidity can flow to and from the reserve through credit and debit lines.\nInterest Rates#\nBorrow and supply rates are determined by a utilization curve. Utilization measures how much of an asset’s liquidity is currently borrowed, expressed as borrowed / total liquidity.\nBelow an optimal usage ratio, the borrow rate increases gradually; above it, the rate increases more sharply. The supply rate is derived from borrower interest after protocol fees and reflects supply and demand for that asset.\nThe curve is defined by a base rate, slopes below and above the optimal usage ratio, and the optimal usage ratio itself, configured per hub asset.\nUser Risk Premium represents an additional interest charge applied to a user's borrowing cost based on the quality of their collateral. It is a percentage surcharge on top of the shared borrow rate for that asset, weighted by the collateral needed to cover the debt, and recalculated as the position changes.\nUser Positions#\nA user position is the combined view of what a user has supplied and borrowed within a Spoke. Positions are tracked per reserve internally, and surface as an aggregate view of a user’s activity on that Spoke.\nUser Supplies: the assets a user deposits into a Hub through the Spoke. They accrue interest over time and expand the Hub’s available liquidity.User Borrows: the assets a user draws from a Hub through the Spoke. They create a debt balance that accrues interest until it is repaid.\nHealth Factor reflects position solvency and indicates how close a position is to liquidation. Calculated as eligible collateral value / debt value. Must stay above 1 to avoid liquidation. Increases when debt is repaid or collateral value rises. Decreases as interest accrues, collateral value decreases, or new debt is taken.\nLiquidations#\nPositions become eligible for liquidation when their health factor drops below 1.0. Aave v4 introduces a redesigned liquidation engine that improves capital efficiency and fairness compared to v3.\nTarget Health Factor: Instead of a fixed close factor, liquidators repay only enough debt to restore the position to a Target Health Factor set at the Spoke level. This prevents over-liquidation.\nVariable Liquidation Bonus: The bonus paid to liquidators scales with the position's health factor. Lower health factors offer higher bonuses, creating a Dutch-auction style incentive that prioritizes the riskiest positions.\nDust Prevention: If the remaining debt or collateral after liquidation would fall below $1,000 USD, the liquidator must fully clear that position, preventing small leftover balances from accumulating.PreviousYield StrategiesNextGetting Started","tokens":1038,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257651891,"hash":"019a1b558a774da92d1f2cc57a9ba1b5b085cbe3"}
{"url":"https://docs.arbitrum.io/arbitrum-bridge/quickstart","domain":"docs.arbitrum.io","title":"Quickstart: Arbitrum bridge | Arbitrum Docs","text":"✏️Request an updateThis quickstart is for users who want to deposit ETH or any ERC-20 tokens from a parent chain to a child chain or vice versa, using Arbitrum’s bridge. For example, from Ethereum to Arbitrum One, or from Arbitrum One to a Layer 3 Arbitrum chain.\nWe will walk you through the entire process step by step, providing as much detail as possible. If you feel stuck at any step, see Arbitrum bridge: Troubleshooting, or contact us through our Discord, and we will be happy to help you complete the process.\nBridging USDC?Arbitrum One supports two distinct forms of USDC (native and bridged). Before you deposit, see USDC on Arbitrum One so you receive the form you intend.\nThe only prerequisite for this quickstart is to have a Web3 wallet installed, such as MetaMask or OKX Wallet. If you don’t have one installed, visit the Arbitrum portal for a list of available wallets to download.\nDeposit ETH or ERC-20 tokens (from parent chain to child chain)​\nStep 1: Get some native currency​\nYou’ll need the native currency of the parent chain to bridge your assets to the destination chain. For example, if you want to bridge assets from Ethereum to Arbitrum One, you’ll need ETH on Ethereum to initiate the process.\nThere are several ways to obtain the native currency:\n\nUsing a supported centralized exchange, which allows you to purchase ETH and withdraw it to your wallet. Most major centralized exchanges support direct withdrawals from your centralized exchange wallet to the Arbitrum network.\nUsing an on-ramp service, which allows you to purchase ETH and send it directly to your wallet.\nIf you are using a testnet, request funds from a Sepolia or Arbitrum Sepolia faucet.\n\nStep 2: Add the preferred network to your wallet​\nYou'll also need to add the desired chain's RPC endpoint to your wallet. Here, we provide an example of how to do this using MetaMask; however, the process should be relatively similar to any other wallet.\n\nFirst, click the MetaMask extension in your browser.\nClick the network selector drop-down in the top-right corner.\nClick the Add a custom network and then provide the information corresponding to the chain you want to send your assets to (see below).\n\nBelow are the most common Arbitrum chains. For a more exhaustive list, please visit our RPC endpoints and providers page.\nParameterArbitrum OneArbitrum NovaArbitrum Sepolia (testnet)Network nameArbitrum OneArbitrum NovaArbitrum SepoliaRPC URLhttps://arb1.arbitrum.io/rpchttps://nova.arbitrum.io/rpchttps://sepolia-rollup.arbitrum.io/rpcChain ID4216142170421614Currency symbolETHETHSepoliaETHBlock explorer URLhttps://arbiscan.iohttps://nova.arbiscan.io/https://sepolia.arbiscan.io\nStep 3: Initiate the deposit​\nTo bridge your ETH or ERC-20 tokens to a different chain, start by visiting bridge.arbitrum.io.\n\nConnect your wallet to the bridge.\nEnsure the source network is selected (from where you want to deposit your assets) at the top of the page.\nSelect the destination network (where you want your assets to go), e.g., Arbitrum One.\n\ncautionNote that testnets like Arbitrum Sepolia only appear if you have an established connection to the appropriate parent testnet network (Ethereum Sepolia).Also note, that when choosing the source or destination network, a pop up will appear where you can make your selection (illustrated below).\n\nSelect the token you want to bridge in the token drop-down menu.\n\nEnter the amount of ETH or ERC-20 tokens you want to bridge over in the From box.\nPress Move funds.\nFollow the additional prompts from your Web3 wallet.\n\nEnsure sufficient ETH balancePlease ensure you have sufficient ETH in your wallet to cover the transation costs; otherwise, the Web3 wallet pop-up will not appear.\n\nAfter you submit the transaction through your Web3 wallet, you can expect your funds to arrive on the destination chain within roughly 15-30 minutes (depending on chain congestion).\nAlso, ensure your wallet is set to the destination network so you can see when your funds arrive.\nWithdraw ETH or ERC-20 tokens (from child chain to parent chain)​\nSeven day withdrawal period for Arbitrum One and Nova networksOnce you withdraw your funds from Arbitrum One or Nova through the Arbitrum bridge, you will have to wait for at least seven days to receive them on the Ethereum mainnet. For more details, see Arbitrum Bridge: Troubleshooting. For the protocol-level reason behind the dispute window, see Child-to-parent messaging and the FAQ entry on why one week was chosen.\nTo bridge your funds back to the parent chain, you must be connected to the Arbitrum bridge with your wallet and ensure you establish a connection to the source network (from which you want to withdraw assets) at the top of the page. Then, select the destination network (where you want your assets to go), e.g., Ethereum mainnet.\ncautionTestnets like Arbitrum Sepolia only appear if you have an established connection to the appropriate parent testnet network (Ethereum Sepolia).\n\nSelect the token you want to bridge in the token drop-down menu.\nEnter the amount of ETH or ERC-20 tokens you want to bridge in the From box.\nPress Move funds.\nFollow the prompts from your Web3 wallet.\n\nEnsure sufficient ETH balancePlease ensure you have sufficient ETH in your wallet to cover the transaction costs; otherwise, no Web3 wallet pop-up will appear.\n\nA countdown will appear stating that you'll receive your funds in 7-8 days.\nYou can check the status of your withdrawal by clicking on your profile in the top-right corner and opening the Transactions tab, where you can claim it when it's ready.\n\nOnce the countdown is complete, press the Claim button to receive your funds.\nSee also​\n\nUSDC on Arbitrum One\nArbitrum bridge: Troubleshooting\nArbitrum embedded bridge widget\nBridge transaction traceability\nHow token bridging works (deep dive)\nBridge tokens programmatically\n\nThe team working on Arbitrum is always interested and looking forward to engaging with its users. Why not follow us on X (Twitter) or join our community on Discord?Deposit ETH or ERC-20 tokens (from parent chain to child chain)Step 1: Get some native currencyStep 2: Add the preferred network to your walletStep 3: Initiate the depositWithdraw ETH or ERC-20 tokens (from child chain to parent chain)See also","tokens":1567,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257656321,"hash":"3f5b71846b985b55580028c6db8585e84fdaad88"}
{"url":"https://aave.com/docs/aave-v4/liquidity/assets","domain":"aave.com","title":"Aave V4 Supported Assets | Aave Protocol Documentation","text":"Assets#\nLearn how to query and monitor asset information across Aave v4.\n\nAssets represent ERC20 tokens that can be supplied, borrowed, or traded within the Aave protocol.\nAsset Data Structure#\nAsset data provides comprehensive information about a specific token in the protocol, including:\nToken identification: id, address, symbol, name, decimalsAggregate metrics: total supplied, total borrowed, caps, and available amountsReserve coverage: total number of reserves and how many are activeCurrent price: exchange valuation for a specific currency\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core Asset types:interface Asset { __typename: \"Asset\"; id: AssetId; token: Erc20Token; summary: AssetSummary; price: ExchangeAmountWithChange;}\nFetching Asset Information#\nQuery detailed information about a specific asset.\nReactTypeScriptGraphQLUse the useAsset hook to fetch asset information.import { type AssetRequest, useAsset } from \"@aave/react\";\nfunction AssetDetails({ request }: { request: AssetRequest }) { const { data, loading, error } = useAsset(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n if (!data) return <div>Asset not found</div>;\n return ( <div> <h3>{data.token.name}</h3> <p>Chain: {data.token.chain.name}</p> </div> );}See below for examples of AssetRequest objects.import { chainId, evmAddress } from \"@aave/react\";\nconst request: AssetRequest = { query: { token: { address: evmAddress(\"0x123…\"), chainId: chainId(1), }, },};Finally, you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\n// …\nconst { data, loading, error } = useAsset({ query: { // your query criteria }, timeWindow: TimeWindow.LastWeek,});\nMultichain Asset#\nA multichain asset aggregates a single token across every chain where it is listed as a hub asset. Tokens are grouped by their canonical symbol—the case-insensitive, alias-resolved symbol that identifies the same asset across chains—so you can show protocol-wide totals and APY ranges without querying each chain separately.\nData Structure#\nA multichain asset exposes the per-chain Asset list alongside an aggregated summary.\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core multichain asset types:interface MultichainAsset { __typename: \"MultichainAsset\"; assets: Asset[]; summary: MultichainAssetSummary;}\nFetching a Multichain Asset#\nSelect the token with exactly one of symbol or tokenInfo. Omit chainIds to aggregate across all chains, or pass a list to restrict the result.\nReactTypeScriptGraphQLUse the useMultichainAsset hook to fetch an asset aggregated across chains.import { useMultichainAsset } from \"@aave/react\";\nfunction MultichainAssetSummary() { const { data, loading, error } = useMultichainAsset({ query: { symbol: \"USDC\" }, });\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> <p>Deployed on {data.summary.chainCount} chains</p> <p> Total supplied: {data.summary.totalSupplied.value.toDisplayString(2)}{\" \"} {data.summary.totalSupplied.symbol} </p> </div> );}See below for examples of MultichainAssetRequest objects.const request: MultichainAssetRequest = { query: { symbol: \"USDC\", },};By default, Merkl rewards are included in the APY range. Pass includeRewards: false for protocol base rates only.const request: MultichainAssetRequest = { query: { symbol: \"USDC\" }, includeRewards: false,};\nAsset Price History#\nAsset price history data provides time-series price information for an asset.\nReactTypeScriptGraphQLUse the useAssetPriceHistory hook to fetch historical price data.import { type AssetPriceHistoryRequest, useAssetPriceHistory,} from \"@aave/react\";\nfunction AssetPrice({ request }: { request: AssetPriceHistoryRequest }) { const { data, loading, error } = useAssetPriceHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((sample) => ( <div key={sample.date.toString()}> <p> <small>{sample.date.toLocaleDateString()}</small>$ {sample.price.toFixed(2)} </p> </div> ))} </div> );}See below for examples of AssetPriceHistoryRequest objects.const request: AssetPriceHistoryRequest = { query: { assetId: asset.id, },};Finally, you can specify a different currency or time window for the data.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = useAssetPriceHistory({ query: { // your query criteria }, currency: Currency.Eur,});\nAsset Supply History#\nAsset supply history data provides time-series total supply information for an asset.\nReactTypeScriptGraphQLUse the useAssetSupplyHistory hook to fetch historical supply data.import { type AssetSupplyHistoryRequest, useAssetSupplyHistory,} from \"@aave/react\";\nfunction AssetSupply({ request }: { request: AssetSupplyHistoryRequest }) { const { data, loading, error } = useAssetSupplyHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((sample) => ( <div key={sample.date.toString()}> <p> <small>{sample.date.toLocaleDateString()}</small> {sample.amount.value.toDisplayString(2)} {sample.amount.symbol} </p> </div> ))} </div> );}See below for examples of AssetSupplyHistoryRequest objects.const request: AssetSupplyHistoryRequest = { query: { assetId: asset.id, },};Finally, you can specify a different time window for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useAssetSupplyHistory({ query: { // your query criteria }, window: TimeWindow.LastMonth,});\nAsset Borrow History#\nAsset borrow history data provides time-series total borrow information for an asset.\nReactTypeScriptGraphQLUse the useAssetBorrowHistory hook to fetch historical borrow data.import { type AssetBorrowHistoryRequest, useAssetBorrowHistory,} from \"@aave/react\";\nfunction AssetBorrow({ request }: { request: AssetBorrowHistoryRequest }) { const { data, loading, error } = useAssetBorrowHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((sample) => ( <div key={sample.date.toString()}> <p> <small>{sample.date.toLocaleDateString()}</small> {sample.amount.value.toDisplayString(2)} {sample.amount.symbol} </p> </div> ))} </div> );}See below for examples of AssetBorrowHistoryRequest objects.const request: AssetBorrowHistoryRequest = { query: { assetId: asset.id, },};Finally, you can specify a different time window for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useAssetBorrowHistory({ query: { // your query criteria }, window: TimeWindow.LastMonth,});\nProtocol History#\nFetch protocol-wide historical data (deposits, borrows). Pass chainIds to scope the history to specific chains, or omit it to aggregate across all of them.\nReactTypeScriptGraphQLUse the useProtocolHistory hook to fetch protocol-wide historical data.import { type ProtocolHistoryRequest, useProtocolHistory } from \"@aave/react\";\nfunction ProtocolHistory({ request }: { request: ProtocolHistoryRequest }) { const { data, loading, error } = useProtocolHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((sample) => ( <p key={sample.date.toString()}> <small>{sample.date.toLocaleDateString()}</small> <span> <strong>Deposits</strong> {sample.deposits.symbol} {sample.deposits.value.toDisplayString(2)} </span> <span> <strong>Borrows</strong> {sample.borrows.symbol} {sample.borrows.value.toDisplayString(2)} </span> </p> ))} </div> );}PreviousReservesNextChains","tokens":1927,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257661876,"hash":"44a5d763d0063da21eec5946e79586b9bd0514f4"}
{"url":"https://docs.arbitrum.io/arbitrum-bridge/usdc-arbitrum-one","domain":"docs.arbitrum.io","title":"USDC on Arbitrum One | Arbitrum Docs","text":"✏️Request an updateArbitrum One supports two different types of USDC:\n\nNative USDC: USDC tokens that are native to the Arbitrum One chain.\nBridged USDC (USDC.e): Ethereum-native USDC tokens that have been bridged to Arbitrum One.\n\nDifferences between USDC and USDC.e​\nNative USDCBridged USDCToken NameUSDCBridged USDCToken SymbolUSDCUSDC.eToken Address0xaf88d065e77c8cC2239327C5EDb3A432268e58310xff970a61a04b1ca14834a43f5de4533ebddb5cc8BenefitsCEX Support, directly redeemable 1:1 for U.S. dollars\nThe Arbitrum Bridge will continue to facilitate transfers of all USDC tokens. When depositing Ethereum-native USDC, the option exists to receive Bridged USDC using Arbitrum's bridge (the canonical lock-and-mint flow described in the token bridging deep dive) or Arbitrum-native USDC using Circle's Cross-Chain Transfer Protocol.\nTo start bridging on Arbitrum refer to the Quickstart or the Embedded bridge widget. If you run into issues bridging USDC, see Arbitrum bridge: Troubleshooting.\nFor Arbitrum chain operators​\nIf you're launching an Arbitrum chain and want to support USDC without locking users into the canonical bridged form, see How to adopt the bridged USDC standard on your Arbitrum chain. It explains the gateway implementation that lets Circle upgrade your chain's USDC to native issuance later.\nHistorical context​\nThe Arbitrum Bridge will continue to facilitate transfers of all USDC tokens. When depositing USDC from Ethereum, the option exists to receive USDC using Circle's Cross-Chain Transfer Protocol or receive Bridged USDC using Arbitrum's lock-and-mint bridge.\nIn 2023, Circle launched USDC natively on Arbitrum One and added support for the Cross-Chain Transfer Protocol, which enabled direct minting and burning of USDC between Ethereum and Arbitrum One. Due to this, the token symbol for Bridged USDC has been renamed to USDC.e to accommodate an ecosystem-wide liquidity migration to native USDC. The expectation is that over time, the liquidity migration of USDC.e to USDC will continue.\nSee also​\n\nArbitrum bridge quickstart\nArbitrum bridge: Troubleshooting\nArbitrum embedded bridge widget\nHow to adopt the bridged USDC standard on your Arbitrum chain\nHow token bridging works (deep dive)\nDifferences between USDC and USDC.eFor Arbitrum chain operatorsHistorical contextSee also","tokens":577,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257666280,"hash":"a003b5e8120a535575572e10ee3473fec894a142"}
{"url":"https://aave.com/docs/aave-v4/liquidity","domain":"aave.com","title":"Aave v4 Liquidity Model | Aave Protocol Documentation","text":"Liquidity Model#\nLearn how the liquidity model works in Aave v4.\n\nThe liquidity management in Aave v4 operates through the coordinated interaction of Liquidity Hubs, Spokes, and Reserves. Understanding how these components work together is essential for grasping how capital flows through the protocol and how new markets can access established liquidity pools.\nLiquidity Hubs#\nLiquidity Hubs are the central settlement layer of Aave v4. Each Hub aggregates liquidity, manages credit lines, enforces risk parameters, and operates under governance controls. This design allows new markets to tap into established pools without fragmenting liquidity.\nAssets are held at the Liquidity Hub (LH), which governs how Spokes can access and utilize them. Governance defines liquidity caps, credit allocations, and risk parameters for each supported asset.\nDifferent Hub types can be deployed for specific purposes — from conservative stablecoin liquidity to higher-yield, higher-risk configurations — each operating under its own governance model.\nSpokes#\nSpokes are specialized smart contracts that connect to Hubs. They define user-facing logic such as interest rate models, collateral requirements, and liquidation conditions while drawing on Hub liquidity. This keeps the complexity of user interactions isolated from the Hub layer.\nCredit lines govern Spoke access to Hub assets, setting limits and conditions for borrowing. A Spoke may connect to multiple Hubs, giving it flexibility to tap different risk profiles or liquidity sources.\nCrucially, risks are isolated at the Spoke level. Issues with a single Spoke do not spread to Hubs or other Spokes, allowing innovation without systemic compromise.\nReserves#\nReserves are managed at the Spoke level and represent the accounting units for specific assets within each Spoke. They track deposits, borrows, repayments, and interest accrual while enforcing supply caps and user-specific configurations.\nGovernance defines how much of the Hub’s underlying assets can be allocated to each Spoke reserve through credit lines, adjusting dynamically based on demand and risk conditions.PreviousSolidityNextHubs","tokens":538,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257671776,"hash":"46e15b5486979afa5b39687674911733fb5563eb"}
{"url":"https://io.net/docs/guides/staking/how-to-unstake","domain":"io.net","title":"Unstake and Withdraw $IO - io.net","text":"​Table of Contents\n\nHow to Unstake $IO\nWithdraw $IO After Cooling Period\n\n​How to Unstake $IO\nYou can unstake at any time. An Unstake option is available for every device you stake. Once you unstake, you are subject to a 14-day cooldown period before the stake can be withdrawn. If a stake is in cooldown period, it does’t meet the staking requirement for Block Rewards.\nFollow the instructions below to unstake $IO:\n\nGo to io.net > IO Worker > Staking tab.\nLocate the stake that you want to unstake. Click Unstake under the Action column.\n\nA pop-up window appears, informing you that the entire amount must be unstaked & that it no longer counts toward the Minimum Required Stake for Block Rewards. Click the Unstake button.\n\nStaking rewards are not automatically compounded.\n\nAfter you Unstake, a timer appears next to the worker, counting down the 14-day cooldown period. You can’t withdraw your funds until this period of time elapses.\n\n​Withdraw $IO After Cooling Period\nTo withdraw funds after the cooldown period, go to the Staking tab and click the Withdraw button.\n\nYou can only withdraw funds to the wallet used for the initial stake. If you attempt to withdraw to a different wallet, you will receive a warning message. To stake with a new wallet, please unstake and withdraw your funds first.\n\nIf you use the same wallet, you’re prompted to withdraw funds to it. When you click the Withdraw button, your wallet extension will open to Confirm the transaction.\nWas this page helpful?","tokens":373,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257678658,"hash":"27a2d9b2d647e1636be52a60a7cc7423cb6c2fe1"}
{"url":"https://gov.optimism.io/c/grants/87","domain":"gov.optimism.io","title":"Latest Grants 🔴 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Grants 🔴\n\n Grants 🔴\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Grants category\n\n Grants 🔴\n\n Everything about community-led grants, including how to get a grant. Or go straight to Atlas.\n\n 2\n\n 194\n\n Apr 1\n\n How to Get a Grant\n\n Grants 🔴\n\n Get a Grant \nIf the process is still confusing after reviewing Atlas, please leave feedback or ask unanswered questions here.\n\n 14\n\n 4.0k\n\n Aug 2025\n\n Season 9 Final Report\n\n Grants Updates\n\n Highlights\nThe Grants Council closed Season 9 submissions on May 20th. \nSubmission flow increased significantly in the final two cycles, bringing the Season 9 total to 38 applications. \nAcross the season, GrantNerds revi…\n\n read more\n\n 9\n\n 464\n\n 13d\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n Governance Fund Missions\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions be…\n\n read more\n\n 4\n\n 127\n\n 27d\n\n [Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s)\n\n Governance Fund Missions\n\n Hello Optimism Collective, \nWe have developed Ag^τ, a proprietary, zero-FPU semantic compression engine designed to reduce L1 calldata costs and lower hardware overhead for EVM rollups. \nAs Optimism scales, L1 data avail…\n\n read more\n\n 2\n\n 85\n\n Aug 25\n\n Grant Application: superchain-guard\n\n Grants Updates\n\n season-8,season-9\n\n Project Name: superchain-guard — The Security Frontier for Interoperable Intents \nApplicant: ILE Labs (ILE-Labs · GitHub) \nProgram: Season 9 Growth Grants (Infrastructure Category) \n\nExecutive Summary\nOptimism is enterin…\n\n read more\n\n 6\n\n 213\n\n May 19\n\n Cycle 27 Grants final roundup\n\n Grants Updates\n\n cycle-27\n\n I am pleased to report that all applications were successfully reviewed, despite the additional workload stemming from Rolling Mission Requests. Both the proposals and voting processes required considerable attention, ye…\n\n read more\n\n 3\n\n 2.3k\n\n May 15\n\n Cycle 51 Grants Council Report\n\n Grants Updates\n\n Highlights\nThe Grants Council reviewed 3 applications during Cycle 51. 1 application moved forward and 2 applications were declined. Our priority remains looking for strong alignment with the mission and with OP Mainnet-…\n\n read more\n\n 4\n\n 186\n\n May 13\n\n [CLOSED] Governance Fund Mission Request: Open-source Monitoring & alerting\n\n Governance Fund Missions\n\n season-8\n\n Season 8 Intent: A set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfer \nTotal grant amount: 114,000 OP (funding 52,000 OP per team, for up to 2 teams) \nShould this Governance Fund Miss…\n\n read more\n\n 12\n\n 791\n\n May 4\n\n Cycle 50 Grants Council Report\n\n Grants Updates\n\n Highlights\nThe Grants Council reviewed 3 applications during Cycle 50. 1 application moved forward and 2 applications were declined. \nSeason 9 review continues to prioritize strong alignment with the mission and with OP …\n\n read more\n\n 1\n\n 102\n\n Apr 10\n\n Season 9 Governance Fund Missions\n\n Grants 🔴\n\n season-9\n\n Governance Fund Missions\nGrants Council Mission\n\nExpected impact on the Intent: \nThe Grants Council makes grants, on behalf of the Token House. In Season 9, the Grants Council will work towards the below success metrics…\n\n read more\n\n 4\n\n 1.0k\n\n Mar 23\n\n Cycle 49 Grants Council Report\n\n Grants Updates\n\n Highlights\n\nGrants Council opened submissions from Feb 11th to May 20th.\nSubmission flow was slower than usual, as expected, due to the specificity of Season 9 Missions.\nThe strategy this season is to fund fewer projects…\n\n read more\n\n 0\n\n 173\n\n Mar 17\n\n Season 9 Grants Council: Applications Now Open\n\n Grants 🔴\n\n The Grants Council looks for projects that grow Superchain adoption by increasing DEX liquidity in priority pairs and the fees generated from trading those pairs. \nApply for a Grant → \nOur Objective\nProjects must target o…\n\n read more\n\n 0\n\n 357\n\n Feb 12\n\n Optimism Partnership Opportunity: Decentralized South Africa 2026\n\n Grants 🔴\n\n My name is Nova Phoenix, founder of lyfebloodDAO and lead organizer to Decentralized crypto event. We’re hosting our next annual crypto event in Johannesburg, South Africa around the 2nd/3rd Qtr of 2026 and we’re looking…\n\n read more\n\n 0\n\n 50\n\n Jan 28\n\n Building for Optimism: ongoing educational and cultural public goods\n\n Retro Funding Missions\n\n Building for Optimism: what I’ve done, what I’m building, and why I keep going\nOver the past months, I’ve been consistently building educational and cultural public goods for the Optimism ecosystem. \nN…\n\n read more\n\n 7\n\n 642\n\n Jan 26\n\n [Introduction] TEN IdentiFI - Privacy-first wallet clustering for the Superchain\n\n Grants 🔴\n\n season-9\n\n Hello Optimism Collective! \nI am the lead developer of TEN IdentiFI, a protocol focused on solving a major friction point in decentralized governance: Privacy-preserving Authority Proofs. \nThe Problem: Users often contro…\n\n read more\n\n 0\n\n 38\n\n Jan 21\n\n [MISSION REQUEST] Startup Support - Optimism as Venture Studio\n\n Governance Fund Missions\n\n Delegate Mission Request Summary\nThis mission aims to provide new business support for projects within the Optimism ecosystem, including projects with approved grants in previous governance seasons. This program will foc…\n\n read more\n\n 8\n\n 998\n\n Jan 16\n\n Optimism as Venture Studio: Mission Updates\n\n Grants Updates\n\n TL;DR\nWakeUp Labs is launching a new Optimism Mission to support projects through technical and strategic development services. As a Venture Studio funded by the Optimism Collective, we’re here to help projects go from c…\n\n read more\n\n 6\n\n 496\n\n Jan 15\n\n Optimism Education & Community Growth Content Initiative\n\n Grants Updates\n\n I’m proposing a content-driven initiative to educate, onboard, and activate non-technical users and creators within the Optimism ecosystem using consistent X (Twitter) threads, explainers, and community engagement. \nProb…\n\n read more\n\n 2\n\n 115\n\n Jan 3\n\n Cycle 45 Results – Season 8 Audit Grants\n\n Governance Fund Missions\n\n Cycle 45 Results – Season 8 Audit Grants\nWe’re pleased to share the results of Cycle 45, continuing the Audit Grants program under Season 8. \n\nKey Outcomes\n\nApplications Approved: 4 \n(Metrom – 25,200 OP; 40acres – 75,00…\n\n read more\n\n 0\n\n 203\n\n Dec 2025\n\n Cycle 46 and Season 8 Final Grants Report\n\n Grants Updates\n\n We purposely delayed the Cycle 45 report as no applications were approved during that cycle, and all submissions remained pending. Those applications were carried over and resolved in Cycle 46, which concludes Season 8. \n…\n\n read more\n\n 0\n\n 309\n\n Dec 2025\n\n Bridging Healthcare - RWA to bring $ 11 Billion volume to Optimism\n\n Retro Funding Missions\n\n I am Dr Ibrar and i am here to ask for Grant for my project OrthoBridge.(RWA,Healtcare Category) \nThis can be a Gamechanger for Op,Eth and Base chain all in one bringing Real value to real world outside Blockchain. \nLite…\n\n read more\n\n 0\n\n 250\n\n Dec 2025\n\n Bringing $ 11 Billion RWA Healthcare volume on Optimism\n\n Governance Fund Missions\n\n I am Dr Ibrar and i am here to ask for Grant for my project OrthoBridge.(RWA,Healtcare Category) \nThis can be a Gamechanger for Op,Eth and Base chain all in one bringing Real value to real world outside Blockchain. \nLite…\n\n read more\n\n 0\n\n 40\n\n Dec 2025\n\n S7 Grants Council Impact Analysis\n\n Governance Fund Missions\n\n season-7\n\n TL;DR:\n\nAn observational analysis of S7 Grants Council grants measured OP-normalized ROI using net Superchain TVL inflows between March 20 and June 12, 2025.\nROI benchmarks emerged at $1.58 (25th percentile), $3.67 (medi…\n\n read more\n\n 19\n\n 1.1k\n\n Dec 2025\n\n Unified Safe Owner Management Across Superchain\n\n Governance Fund Missions\n\n season-8,season-9\n\n Cross-Chain Safe Module System — Governance Fund Mission Application\nProject Name: Unified Safe Owner Management Across Superchain \nMission: Deliver a secure, Hub-based Safe module system that enables unified owner updat…\n\n read more\n\n 1\n\n 122\n\n Nov 2025\n\n [CLOSED] Governance Fund Mission Request: Cross-Chain Key Management for Safe\n\n Governance Fund Missions\n\n season-8\n\n Season 8 Intent: A set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfer \nTotal grant amount: Up to 126,000 OP (funding 63,000 OP per team, up to 2 teams) \nShould this Governance Fund Mi…\n\n read more\n\n 11\n\n 520\n\n Nov 2025\n\n # Cycle 44 Results – Season 8 Audit Grants\n\n Grants Updates\n\n Cycle 44 Results – Season 8 Audit Grants\nWe’re pleased to share the results of Cycle 44, marking the fourth and latest cycle under Season 8 for Audit Grants. \n\nKey Outcomes\n\nApplications Approved: 3 \n(Highway – 52,800 O…\n\n read more\n\n 0\n\n 179\n\n Nov 2025\n\n Cycle 44 Grants Report\n\n Grants Updates\n\n Cycle 44 is finished, showing a consistent rhythm of applications and clearer decision criteria. \nKey Outcomes\n\nApplications Approved: 4\nApplications Conditionally Approved: 1\nApplications In Review: 4\nApplications Decli…\n\n read more\n\n 0\n\n 150\n\n Nov 2025\n\n Cycle 43 Results – Season 8 Audit Grants\n\n Grants Updates\n\n We’re pleased to share the results of Cycle 43, marking the continuation of the Audit Grants program under Season 8. \n\nKey Outcomes\n\nApplications Approved: 0 \n\nApplications on Hold (Considered for Later Approval): 2 \n(…\n\n read more\n\n 0\n\n 114\n\n Oct 2025\n\n Interop Mission – Crosschain Alert Monitoring\n\n Grants Updates\n\n TL;DR\nWe’re building a Crosschain Alert Monitoring toolkit for the Superchain. It provides a deterministic heartbeat across OP Stack L2s, generating real‑time health signals, latency and gas metrics, and actionable alert…\n\n read more\n\n 1\n\n 116\n\n Oct 2025","tokens":2471,"squid":"ink-governance","role":"Council Listener","at":1791257678868,"hash":"6860d5dbe795e98a3f43f803fa51026b62a5a4bd"}
{"url":"https://aave.com/","domain":"aave.com","title":"Aave — Onchain Savings, Lending and Borrowing","text":"Aave AppThe World's Savings AppGet paid every second with global rates and Balance Protection.Learn MoreThe world’s largest onchain lending networkNet deposits$34.1BUsers2.5M+Founded2017Stay UpdatedBe the first to hear about news from Aave Labs.Aave ProThe Full Power of DeFiEarn, borrow and swap. Built on Aave v4.Get StartedLearn MoreMarkets for every strategy.From conservative stablecoin configurations to higher-yield arrangements, choose the market that matches how you earn and borrow.Learn MoreGeneral PurposeMainThe broadest market on Aave with competitive rates across a wide range of collateral.AAVEUSDCwETHwBTCLINK+4 MoreCollateral-IsolatedBluechipDeposit assets and borrow stablecoins against them, with the assurance that your collateral isn't lent out.wETHwstETHwBTCcbBTCStrategy-IsolatedEthena CorrelatedBorrow USDe against Ethena assets like USDe, sUSDe, and sUSDe Pendle tokens for looping.PT-sUSDePT-USDesUSDeUSDeAave KitBuild with AaveLaunch lending, yield, and onchain financial experiences with Aave's integration stack.Start BuildingTalk to SalesThe best build with Aave.Reach millions of users and access billions in capital with a few lines of code.Learn MoreWhop21M+ userswith yield powered by Aave.Kraken~60%lending market share.MetaMask100M+ userswith access to Aave-powered yield.Cap$360M+ supplied90% of stcUSD yield from Aave.Ethena$10B reachedin 500 days.Kinexys by J.P. MorganJ.P. Morganvalidated institutional DeFi on Aave.Trusted by DefaultSix years of uninterrupted operation. Trillions deposited. Independently audited, onchain, and open to verify.Learn More6+ YearsOf uninterrupted operation.$3.46TLifetime deposits.$1TLifetime borrows.$88.44BMonthly volume across markets.$1.92BInterest earned by lenders.SOC 2 Type 2Annual security audit.The home of stablecoins.Aave is the most used protocol for stablecoin lending and borrowing across DeFi.Earn more with stablecoins on Aave.Growth of $10,000 USDC based on historical rates.Aave (USDC)T-BillsSavings Account$12,321$11,851$10,152USDC supply APY from on-chain data (Aave V2+V3 Ethereum)•T-Bill: 3-month secondary market rate•Savings: FDIC national avgFAQsAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.Supplied tokens are stored in publicly accessible smart contracts that enable overcollateralised borrowing according to governance-approved parameters. The Aave Protocol smart contracts have been audited and formally verified by third parties.No protocol can be considered entirely risk free, but extensive steps have been taken to minimize these risks as much as possible – the Aave Protocol code is publicly available and auditable by anyone, and has been audited by multiple smart contract auditors. Any code changes must be executed through the onchain governance processes. Additionally, there is an ongoing bug bounty campaign and service providers specializing in technical reviews and risk mitigation.AAVE is used as the centre of gravity of Aave Protocol governance. AAVE is used to vote and decide on the outcome of Aave Improvement Proposals (AIPs). Apart from this, AAVE can be staked within the protocol Safety Module to provide a backstop in the case of a shortfall event, and earn incentives for doing so.Learn More About AaveStay UpdatedBe the first to hear about news from Aave Labs.","tokens":879,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257682931,"hash":"c0938bc9e1127bff62cc8777317e9c64476381e0"}
{"url":"https://io.net/docs/guides/workers/intro","domain":"io.net","title":"Intro - io.net","text":"​What is IO Worker?\nIO Worker is like having a virtual rental manager for your device. It’s a simple web app that lets you lend your computing power to those tackling AI tasks, making it easier for everyone to access the resources they need.\nThanks to our decentralized setup and smart resource management, you can earn more by renting out your GPU/CPU than you would with traditional cloud services. It’s a win-win situation where you support others while boosting your own earnings.\nWith io.net, you’re not just renting out hardware; you’re part of a community that values collaboration and efficiency. Whether you’re a business looking to optimize resources or an individual keen on making extra profits, io.net has got you covered.\n​Key Features\n\nDecentralized Compute Power: IO Workers enable access to a distributed network of GPUs and CPUs, providing the computational resources users need.\nCost-Efficiency: By leveraging IO Workers, users can benefit from cost-effective compute resources. The decentralized nature of the network optimizes costs, reduces latency, and provides scalable compute capabilities.\nScalability: IO Workers offer flexibility, allowing users to scale their computational resources based on demand. This ensures efficient handling of varying workloads.\nReal-Time Monitoring: Users can monitor the performance of IO Workers in real-time, tracking metrics such as uptime, resource utilization, and job completion rates for efficient management and optimization.\nSecure Resource Sharing: IO Workers facilitate secure resource sharing among network participants. Users maintain control over access and usage while sharing their compute resources securely.\nGlobal Accessibility: IO Workers provide global accessibility, allowing users from different regions and industries to access and utilize decentralized compute power seamlessly.\n\n​IO Worker Integration Flow\nThe diagram below illustrates the general integration process of an IO Worker into the IO.NET ecosystem — from setting up required components to successfully connecting your device to the network. It provides a clear overview of the key steps involved in configuration and deployment.\n\n​Create Account\nTo create an account, go to worker.io.net. Currently, you can sign up using Google, Apple ID, X, or Worldcoin. Choose your preferred option, click Sign Up, and you’re all set to join us.\n​Go to worker.io.net\n\nFeel free to check our knowledge base for answers, and if you still need help, don’t hesitate to open a support ticket!Was this page helpful?","tokens":636,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257688617,"hash":"f468fa6e5ae13dd7fb27c3f4ad1e28c7cee72266"}
{"url":"https://ethresear.ch/u/vbuterin","domain":"ethresear.ch","title":"Summary - vbuterin - Ethereum Research","text":"Skip to profile content\n\n vbuterin\n\n Vbuterin\n\n Joined\n\n Oct 17, 2017\n\n Last Post\n\n Sep 24\n\n Seen\n\n Sep 26\n\n Views205872\n Trust Levelleader\n Group\n\n Nucleus\n\n ...\n\n Stats\n\n 1.7k\n\n days visited\n\n 6d\n\n read time\n\n 28m\n\n recent read time\n\n 1.3k\n\n topics viewed\n\n 8.9k\n\n posts read\n\n 118\n\n given\n\n 3.2k\n\n received\n\n 222\n\n topics created\n\n 1.3k\n\n posts created\n\n Top Replies\n\n Dec 2023\n ·\n  29\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n May 2020\n ·\n  26\n\n Enshrined Eth2 price feeds\n\n Jan 2024\n ·\n  20\n\n Properties of issuance level: consensus incentives and variability across potential reward curves\n\n Jan 2018\n ·\n  15\n\n Using ICOs to fund science\n\n Aug 2021\n ·\n  14\n\n Exit/entry queue clogging after withdrawals are enabled\n\n Jan 2018\n ·\n  13\n\n Minimal Viable Plasma\n\n More Replies\n\n Top Topics\n\n Jan 2018\n ·\n  289\n\n Minimal Viable Plasma\n\n Dec 2023\n ·\n  234\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Jan 2018\n ·\n  184\n\n Explanation of DAICOs\n\n Sep 2018\n ·\n  119\n\n On-chain scaling to potentially ~500 tx/sec through mass tx validation\n\n Sep 2021\n ·\n  101\n\n Cross-rollup NFT wrapper and migration ideas\n\n May 2025\n ·\n  89\n\n A local-node-favoring delta to the scaling roadmap\n\n More Topics\n\n Top Links\n\n truebit.substack.com/p/truebit-early-access\n\n EVM optimistic rollup using Truebit\n\n reddit.com/r/ethereum/comments/55m04x/lets_run_onchain_decentralized_exchanges_t\n\n Improving front running resistance of x*y=k market makers\n\n vitalik.ca/general/2019/04/03/collusion.html\n\n Minimal anti-collusion infrastructure\n\n notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ\n\n Convenience link to Casper+Sharding chain v2.1 spec\n\n hackernoon.com/blockchain-privacy-enhancing-technology-series-stealth-address-i-\n\n ERC721 Extension for zk-SNARKs\n\n github.com/ethereum/sharding/blob/develop/docs/doc.md\n\n Future-compatibility for sharding\n\n Most Replied To\n\n kladkogex\n\n Stan Kladko\n\n 51\n\n JustinDrake\n\n Justin Drake\n\n 44\n\n dankrad\n\n Dankrad\n\n 26\n\n jamesray1\n\n James Ray\n\n 24\n\n naterush\n\n Nate Rush\n\n 20\n\n MicahZoltu\n\n Micah Zoltu\n\n 19\n\n Most Liked By\n\n jamesray1\n\n James Ray\n\n 65\n\n abcoathup\n\n Andrew B Coathup\n\n 54\n\n MihailoBjelic\n\n Mihailo Bjelic\n\n 44\n\n sherif\n\n sherif samir\n\n 38\n\n amadeobrands\n\n Amadeo Brands\n\n 36\n\n karl\n\n Karl Floersch\n\n 36\n\n Most Liked\n\n dankrad\n\n Dankrad\n\n 6\n\n barryWhiteHat\n\n Barry White Hat\n\n 6\n\n JustinDrake\n\n Justin Drake\n\n 5\n\n AlexandreBelling\n\n Alexandre Belling\n\n 4\n\n nrryuya\n\n Ryuya Nakamura\n\n 4\n\n snjax\n\n Igor Gulamov\n\n 3\n\n Top Categories\n\n Topics\n Replies\n\n Sharding\n\n 73\n\n 347\n\n Proof-of-Stake\n\n 39\n\n 177\n\n Economics\n\n 28\n\n 177\n\n Plasma\n\n 10\n\n 89\n\n zk-s[nt]arks\n\n 3\n\n 62\n\n Execution Layer Research\n\n 6\n\n 59\n\n Top Badges\n\n Leader\n\n Granted global edit, pin, close, archive, split and merge, more likes\n\n Great Topic\n\n Received 50 likes on a topic\n\n Famous Link\n\n Posted an external link with 1000 clicks\n\n 3 awarded\n\n Great Share\n\n Shared a post with 1000 unique visitors\n\n Good Reply\n\n Received 25 likes on a reply\n\n 2 awarded\n\n Gives Back\n\n Has 100 liked posts and gave 100 likes\n\n More Badges\n\n Powered by Discourse","tokens":769,"squid":"ink-research","role":"Deep Scholar","at":1791257691581,"hash":"994531c474ef6e1f8209621dedc62ea453850134"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade","domain":"docs.pyth.network","title":"Pyth Core Upgrade | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradePyth Core was upgraded on August 26, 2026. Check that your integration is up to date.Pyth Network upgraded Pyth Core on August 26, 2026 at 16:00 UTC. The upgrade replaced Pyth Core's underlying data infrastructure with an improved version while preserving the existing Hermes API surface and on-chain contract interface.\nWhat you get\n\nHigher-frequency updates for faster price moves.\nAdditional price feeds beyond the current Core catalog.\nLower latency across the data path.\n\nMost existing integrations kept working through the cutover. Complete the upgrade to check whether you're covered. The one new requirement is authentication on Hermes: every Hermes user needs a Pyth API Key.\nNext steps\nComplete the upgradeStep-by-step guide to bring your integration up to date.See the upgraded contract addressesAll contract addresses side by side, including the upgraded Pyth Core Contract per chain.Learn how the upgrade worksTechnical details on signers, data flow, and contract behavior.Getting StartedExplore key resources to begin integrating Pyth price feedsCompleting the Pyth Core upgradeEverything you need to bring your Pyth Core integration up to date with the August 26, 2026 upgrade.","tokens":305,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257696459,"hash":"3c12dd5f28ea85bcba651dabf950571c77021ed1"}
{"url":"https://io.net/docs/guides/workers/troubleshoot-worker-general","domain":"io.net","title":"General Worker Troubleshooting - io.net","text":"​How to Resolve Unsupported GPU Issues on Windows and Linux?\nIf a user’s supported GPU is listed as unsupported on the website, they should verify their NVIDIA driver configuration. Often, when a Docker container running nvidia-smi fails, the backend receives this information and marks the GPU as unsupported.\nTo check the configuration, running the following command should provide the correct output:\ndocker run --gpus all nvidia/cuda:11.0.3-base-ubuntu18.04 nvidia-smi\n\n​If I received a “device code authorization returned: Bad Request” error?\nIf this error is displayed following authorization:\nError: device code authorization returned: Bad Request\nError: Error authenticating: provided token has expired or invalid. Please re-authenticate using --no_cache=true flag.\n\nThis error might be caused by an issue with network connections. Visit https://auth0.io.solutions/activate. If the page does not open, it means Auth0 is not reachable for you.\n​How can I pause or reset a Worker if it has disconnection issues?\nIf your worker has been disconnected, here are a few steps to fix it:\n\nGo to your running Worker Page and click on Pause for the Worker (located at the top-right corner).\n\nOptionally, restart the device as needed.\n\nAfter restarting the device, open your Worker page at IO.NET and copy the command from the Re-Run docker command block on the Worker Page, then run it Terminal.\n\nIf prompted, authorize the device using IO.ID. Remember, you have about 3 minutes to complete the authorization.\n\nConfirm the removal of all previous containers in Docker.\n\nWait for up to 10 minutes to see the progress. Your worker is now ready to use again.\n\n​How can suppliers change their accounts in IO Worker?\nTo change accounts, suppliers should include the —no_cache=true flag in the binary run command. This triggers a re-authentication process. Simply add —no_cache=true at the end of your main request when connecting the device with the new login.\n./launch_binary_mac --disable_sleep_mode=true --no_cache=true\n./io_net_launch_binary_windows.exe --disable_sleep_mode=true --no_cache=true\n./io_net_launch_binary_linux --disable_sleep_mode=true --no_cache=true\n\nAfter one successful sign-in, the token will be saved in memory.\n\n​How can you run an existing worker UUID in the new authentication and authorization system?\nAs of May 2024, we have transitioned to a new authentication and authorization system. Follow these steps to run your existing worker UUID again.\n​1. Run the Command to Connect the Device\nOpen the Terminal on your system by navigating to the Start menu and using the search function. The process is similar regardless of your operating system.\n\nThen run the command in the Terminal. For Windows, start by downloading and running the executable file.\n\nDownload the binary for your operating system running command. For Windows you need to download the executable file. You can see how it’s done here\ncurl -L https://github.com/ionet-official/io_launch_binaries/blob/main/io_net_launch_binary_mac -o io_net_launch_binary_mac\nhttps://github.com/ionet-official/io_launch_binaries/raw/main/io_net_launch_binary_windows.exe\ncurl -L https://github.com/ionet-official/io_launch_binaries/blob/main/io_net_launch_binary_linux -o io_net_launch_binary_linux\n\nUse the following command to grant permissions to the new binary:\nchmod +x io_net_launch_binary_mac\nchmod +x io_net_launch_binary_linux\n\nLaunch the binary to connect your device to the platform.\n./io_net_launch_binary_mac --no_warnings=true \n./io_net_launch_binary_windows.exe --no_warnings=true \n./io_net_launch_binary_linux --no_warnings=true \n\n​2: To authorize the device with IO.ID, follow one of the options below and verify your IO.ID account:\nRemember, you will have about 1-2 minutes to complete the authorization of the device. If it expires, run the code again.\nYou can do this in two ways: Copy the Link from the Terminal: Paste it into your browser and confirm the action.\n\nAfter confirmation, the system will prompt you to log in.\n\n​3. Save the Token\nThe information below is found in the CLI. Keep this token accessible.\n\n​4. For all other machines use the saved token\nThis does not require manual reauthentication and can be used for all your worker nodes.\n\n​Why Do Containers Disappear from Docker?\nIf the container disappears from docker, then your worker was likely blocked. If this happens, you must recreate the worker from scratch.\n\n​Why Is My Worker Blocked?\nBlocked status is indicative that our system detected GPU utilization that was not authorized by our internal checks. It’s important that GPU availability is dedicated 100% to the task being volunteered for the health of the .\nBlocked status can occur for a few different reasons, primarily:\n\nExcessive GPU Utilization: Activities such as playing games or using graphics-intensive applications. (You’ll need to pause these activities before you start usage.)\nMining Detection: Our team has implemented an update to detect mining devices and instances with high GPU usage, resulting in an automatic ban.\nDevice and Hardware Switching: Our team has implemented a mechanism for blocking device if they were verified and later a different device with a different hardware was detected. If you need to use a new hardware, please create a new device\n\n​Why Does My Worker Have an Unsupported Status?\nThis occurs when your GPU/CPU is not listed among the supported devices on the IO Network. You can check the list of supported devices here.\n\n​Why Does My Worker Disappear from My Dashboard?\nThis issue can stem from a few main causes:\n\nUnsuccessful Connection: You didn’t successfully connect the new worker. Here’s an example of a successful worker connection:\n\nUnsupported Hardware: If you successfully connected a new worker but the GPU/CPU you’re using is not supported, you won’t see your worker on the dashboard. You can check the list of supported devices here.\n\nUser Interface Issues: If your worker was running normally and suddenly disappears from the dashboard, it could be due to a problem with the user interface (UI). In such cases, try refreshing the website. If the worker still doesn’t appear, please try again later or create a ticket for our support team to assist you.\n\n​Creating Multiple Workers from the Same Device\nUsers may inadvertently create a new worker each time the previous one fails instead of re-running the existing worker. To address this issue, you need to Terminate the old workers and learn how to restart Docker to continue running the existing worker. Follow the instructions here.\n\n​Device Readiness Status\nYour device status needs to be either Cluster Ready or Hired to be nominated for Block Rewards and be eligible for hiring. You can verify device status either on the device detail page or on the Workers tab in IO Explore. For more information, see the Get Started - IO Worker doc.\nThe four possible Readiness statuses are:\nStatusDescriptionCluster ReadyDevice meets PoW requirements and passed several Cluster Formation verifications.HiredDevice is currently hired by a cluster.PendingThe device has joined the network and is currently undergoing both the PoW and Cluster Readiness test. This process can take up to 12 hours of cumulative uptime after onboarding, but may complete sooner if your device passes our tests early. If your device remains in a Pending state after more than 12 hours of uptime, please contact us.Not Block Reward ReadyDevice doesn’t meet the criteria for block reward eligibility, mainly Cluster Formation verifications.\nNot Block Reward Ready offers one of three tooltips in the UI to provide troubleshooting tips.\n\nPlease check your device’s computational capacity- Your device’s computational capacity is below the required threshold.\nPlease check your device setup and computational capacity- Your device setup might not be configured correctly and its computational capacity is below the required threshold. Please refer to the worker setup guide.\nPlease check your device setup- Your device setup might not be configured correctly. Please refer to the worker setup guide.\n\nFeel free to check our knowledge base for answers, and if you still need help, don’t hesitate to open a support ticket!Was this page helpful?","tokens":2060,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257698799,"hash":"5c3e3554f9c9020fa9447561fb55e9891574309d"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"Minimal Viable Plasma \n\n Layer 2Plasma\n\n new-extension\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 1 / 144\n\n Jan 2018\n\n May 2019\n\n post by vbuterin on Jan 3, 2018\n\n vbuterin\n\n Special thanks to Joseph Poon and David Knott for discussions that led to this specification.\nThe following aims to provide a specification for a “minimal viable plasma implementation”. It aims to provide the basic security properties of Plasma in a very simplified way, though it leans heavily on users being willing to immediately exit as soon as they detect any kind of malfeasance.\nThe Plasma Contract\nThe Plasma contract maintains the following data structures:\n\nThe owner (set at initialization time)\nA list of Plasma blocks, for each block storing (i) the Merkle root, (ii) the time the Merkle root was submitted.\nA list of submitted exit transactions, storing (i) the submitter address, and (ii) the UTXO position (Plasma block number, txindex, outindex). This must be stored in a data structure that allows transactions to be popped from the set in order of priority.\n\nA Plasma block can be created in one of two ways. First, the operator of the Plasma chain can create blocks. Second, anyone can deposit any quantity of ETH into the chain, and when they do so the contract adds to the chain a block that contains exactly one transaction, creating a new UTXO with denomination equal to the amount that they deposit.\nThe contract has the following functions:\n\nsubmitBlock(bytes32 root): submits a block, which is basically just the Merkle root of the transactions in the block\n\ndeposit(): generates a block that contains only one transaction, generating a new UTXO into existence with denomination equal to the msg.value deposited\n\nstartExit(uint256 plasmaBlockNum, uint256 txindex, uint256 oindex, bytes tx, bytes proof, bytes confirmSig): starts an exit procedure for a given UTXO. Requires as input (i) the Plasma block number and tx index in which the UTXO was created, (ii) the output index, (iii) the transaction containing that UTXO, (iv) a Merkle proof of the transaction, and (v) a confirm signature from each of the previous owners of the now-spent outputs that were used to create the UTXO.\n\nchallengeExit(uint256 exitId, uint256 plasmaBlockNum, uint256 txindex, uint256 oindex, bytes tx, bytes proof, bytes confirmSig): challenges an exit attempt in process, by providing a proof that the TXO was spent, the spend was included in a block, and the owner made a confirm signature.\n\nstartExit must arrange exits into a priority queue structure, where priority is normally the tuple (blknum, txindex, oindex) (alternatively, blknum * 1000000000 + txindex * 10000 + oindex). However, if when calling exit, the block that the UTXO was created in is more than 7 days old, then the blknum of the oldest Plasma block that is less than 7 days old is used instead. There is a passive loop that finalizes exits that are more than 14 days old, always processing exits in order of priority (earlier to later).\nThis mechanism ensures that ordinarily, exits from earlier UTXOs are processed before exits from older UTXOs, and particularly, if an attacker makes a invalid block containing bad UTXOs, the holders of all earlier UTXOs will be able to exit before the attacker. The 7 day minimum ensures that even for very old UTXOs, there is ample time to challenge them.\nThe Plasma Chain\nEach Merkle root should be a root of a tree with depth-16 leaves, where each leaf is a transaction. A transaction is an RLP-encoded object of the form:\n[blknum1, txindex1, oindex1, sig1, # Input 1\n blknum2, txindex2, oindex2, sig2, # Input 2\n newowner1, denom1, # Output 1\n newowner2, denom2, # Output 2\n fee]\n\nEach transaction has 2 inputs and 2 outputs, and the sum of the denominations of the outputs plus the fee must equal the sum of the denominations of the inputs. The signatures must be signatures of all the other fields in the transaction, with the private key corresponding to the owner of that particular output. A deposit block has all input fields, and the fields for the second output, zeroed out. To make a transaction that spends only one UTXO, a user can zero out all fields for the second input.\nUser Behavior\nThe process for sending a Plasma coin to someone else is as follows:\n\nAsk them for their address.\nSend a transaction that sends some of your UTXOs to their address.\nWait for it to get confirmed in a block.\nSend them a confirm message, signed with the keys that you use for each of your UTXO inputs.\n\nEmergency exiting\nA user should continually validate (or validate at least once per 7 days) that the Plasma chain is fully available and valid; if it is not, they should exit immediately.\nProof of correctness sketch\nApproximate claim: a UTXO with denomination D will entitle its owner to withdraw D coins, and that (i) fraudulent cancellations and (ii) invalid UTXOs successfully withdrawing and draining the contract before the user can fully withdraw will not prevent them from doing so.\nSuppose that:\n\nThe first invalid or unavailable transaction is at position (blknum_i, txindex_i).\nThere exist TXOs before that point of total denomination M, of which M-N is spent and N is unspent. We call a TXO spent if a transaction spending it has been included in a block, and a commit from the owner of the TXO is in the hands of the owner of at least one of the child TXOs.\n\nConsider any UTXO with denomination D that was confirmed in a position before (blknum_i, txindex_i), call it (blknum_e, txindex_e). We assume that within 1 day of the first invalid or unavailable transaction getting confirmed, the owner of that UTXO publishes an exit. This exit is assigned a priority of (blknum_e, txindex_e), and so it will be processed before (blknum_i, txindex_i). We also assume that if there is a transaction “in flight” spending this UTXO, and this gets included in a future block, then the owner will refuse to sign the commit. We know that:\n\nBy the validity assumption, there are >=N coins deposited in the contract.\nThere are no UTXOs with commits spending that UTXO, so a challenge is not possible.\nAll TXOs chronologically before (blknum_e, txindex_e) are valid. We ignore TXOs chronologically after (blknum_e, txindex_e) because they have no ability to influence the given UTXO’s ability to exit successfully (TXOs before it can, by draining the balance first)\nTXOs chronologically before (blknum_e, txindex_e) are of two types: (i) unspent, with total denomination N-D, (ii) spent, with total denomination M-N. Exits of the second type can be challenged, and exits of the first type will succeed.\n\nHence, there will be at least D coins left in the contract’s deposit to pay the owner of the deposit.\nThe following aims to provide a specification for a “minimal viable plasma implementation”. It aims to provide the basic security properties of Plasma in a very simplified way, though it leans heavily on users being willing to immediately exit as soon as they detect any kind of malfeasance.\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n More Viable Plasma\n\n Account based Plasma (MoreVP)\n\n A potential problem with two \"types\" of blocks in Plasma MVP?\n\n Plasma (+ Delegated Exits)\n\n 31\n\n 14\n\n 14\n\n 12\n\n 11\n\n read \n\n 36\n min\n\n post by jdkanani on Jan 9, 2018\n\n jdkanani\n\n Thanks for the post.\nSlightly more difficult scenario, how I can enforce correctness in case of state change in account/state based plasma chain?\n(block 0, state 0, [t1, t2.... ]) -> state 1 \n(block 1, state 1, [t1, t2.... ]) -> state 2\n\nLet’s say if one wants to challenge block 1, saying - t2 in block 1 in not valid as it should yield state 2' instead of state 2. How one can generate fraud proof?\n\n post by kladkogex on Jan 9, 2018\n\n kladkogex\n\n I have read the description several times, I am not sure though I understand how an exit transaction is verified by the parent blockchain …\n\nIs this correct to say, that to exit you need to have signatures of all owners of intemediate UTXOs … ? And all of these signatures will be verified during the exit? Correct?))\n\nIn this structure if I look at a particular UTXO, it may have two parents, so essentially if I go back N transactions in history for a particular UTXO, I will have 2^N2𝑁 ancestors … ? correct?) Would it mean that the size of the exit proof would grow exponentially as coins exchange hands?)) Or I am missing something ?))\n\n post by vbuterin on Jan 10, 2018\n\n vbuterin\n\n You do not need to provide a proof of the entire history of a UTXO in order to exit with that UTXO; you just need to prove that the UTXO exists and was included. It seems counterintuitive that you need to prove that little, but it works; it relies heavily on the fact that if any user sees an invalid UTXO get in, they need to exit within some timeframe, and make sure to not finalize transfers that were included after that invalid UTXO.\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n Load more posts below","tokens":5207,"squid":"ink-research","role":"Deep Scholar","at":1791257701991,"hash":"fa1c5c8e7c8c946117454c1070b2a821fec33d40"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/preparing","domain":"docs.pyth.network","title":"Completing the Pyth Core upgrade | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradeCompleting the Pyth Core upgradeEverything you need to bring your Pyth Core integration up to date with the August 26, 2026 upgrade.\nPyth Network upgraded Pyth Core on August 26, 2026 at 16:00 UTC. Existing integrations kept working: the on-chain Pyth contract was upgraded in place by the Pyth DAO (except on Sui, which requires a manual swap), and Hermes requests are served by the upgraded backend automatically. The one new requirement is authentication on Hermes: every Hermes user needs a Pyth API Key.\nFor background on what changed and why, see the upgrade overview. For a walkthrough of the signers, data flow, and contracts behind the upgrade, see How the Pyth Core upgrade works.\nAll Hermes users need a Pyth API Key — hermes.pyth.network now requires\nauthentication, including for integrations that were upgraded automatically.\nRegister at Pyth Terminal →\nDoes this apply to you?\n\nYour app calls hermes.pyth.network?\nGet a Pyth API Key in Step 1.\nYou use Pyth Core contracts on-chain?\nThe DAO upgraded the current addresses in place on August 26 — no swap is required, except on Sui (see the decision section below).\nYou only use a protocol that already integrates Pyth?\nNo action needed from your side.\n\nYour upgrade path\nStep 1: Get a Pyth API Key\nRequired for everyone who calls Hermes.\nSign up at Pyth Terminal: a free trial is included, paid plans cover ongoing use.\nSign up at Pyth Terminal\nStep 2: Early upgrade or wait for automatic?\nAfter Step 1, pick the path that matches your integration. Your choice is saved in the URL so you can share or bookmark a specific path.\nSui consumers must upgrade manuallyThe \"Wait for automatic\" path does not apply on Sui. Apps reference the Pyth package by object ID, and the DAO cannot swap that for you. See the Sui upgrade guide.\n\nEarly upgrade (recommended)Automatic upgradeTimingYou chooseHappened on August 26, 2026 at 16:00 UTCDowntimeUp to youBrief, during the switchHermes endpointSwitch to the new Hermes endpointKeep using hermes.pyth.network, now with an API keyContract addressYou swap to the upgraded Pyth Core ContractDAO upgraded the current Pyth Core Contract for you\nEarly upgradeThis is the recommended path: it moves your integration fully onto the upgraded endpoint and contracts.Move your Hermes calls to the new Hermes endpointSwitch your Hermes base URL from hermes.pyth.network to pyth.dourolabs.app/hermes and add your API key that you got in Step 1. The routes and response shapes are unchanged. The upgraded endpoint is a drop-in replacement.curl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://pyth.dourolabs.app/hermes/v2/updates/price/latest?ids[]=0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\"Routes and response shapes are unchanged.\nThe upgraded endpoint is a drop-in replacement. See the new Hermes API reference for the full surface.Per-chain availability: see the Pro-compatible column on the EVM, Solana, and Sui push-feed tables to confirm which feeds are already served by the upgraded Hermes today.Swap your contract addressSwap your existing Pyth contract address for the upgraded Pyth Core Contract on your chain. The upgraded Pyth Core Contract preserves the Pyth Core interface. No other code changes are needed.View all upgraded Pyth Core Contract addresses.After the swap, your integration is fully on the upgraded stack.Per-chain guidesEVMEVM-specific notes including ethers and viem usage.SuiSui Move.toml change and package compatibility notes.SolanaSolana Cargo feature flag and TS SDK configuration.\nWaiting for the Automatic UpgradeNot applicable to SuiThis path does not apply on Sui. Apps reference the Pyth package by object ID, and the DAO cannot swap that for you. Follow the Sui upgrade guide instead.The automatic upgrade ran at the cutover on August 26, 2026 at 16:00 UTC: the Pyth DAO upgraded on-chain contracts in place, and hermes.pyth.network began serving the upgraded payload with API key authentication required.If your integration was on this path, the only thing left to check is authentication: a client still calling hermes.pyth.network without an API key fails with authentication errors. Add the Authorization: Bearer $PYTH_API_KEY header using the key from Step 1 and you're done — no contract change is needed, since your contract was upgraded in place.\nChain support\nPyth Core is supported on major EVM chains, Solana and Sui. See the upgraded Pyth Core contract addresses page for more details.\nFeed support\nNearly all current Pyth Core feeds remain available after the upgrade, with new ones added. Look up your specific feeds on the feed explorer. If a feed you depend on isn't listed, contact the team.\nFAQ\n\nGet help\nTechnical questionsPublic dev Telegram channel.Contact the teamPlans, chain support, custom arrangements.Developer Forum DiscussionDiscussion about the Pyth Core upgrade and how to prepare for it.Pyth Core UpgradePyth Core was upgraded on August 26, 2026. Check that your integration is up to date.for EVM chainsNext Page","tokens":1257,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257705725,"hash":"26f4fc755be35228c8519eb0c7d49657202d7c14"}
{"url":"https://io.net/docs/guides/workers/manage-and-monitor","domain":"io.net","title":"Manage, Monitor, & FAQs - io.net","text":"​Worker Details\nThe Device View page provides a comprehensive overview of the device’s details. io.net presents real-time data on transmitted traffic, connection status, and uptime history.\nUsers can monitor the status of all active services on the device and activate additional ones by purchasing io.coins. By default, these services are automatically linked to the worker:\n\nIO Version Control\nIO Monitor\nRay.io\n\nEqually important is the device’s current/past tasks and its complete notification history, conveniently accessible through the corresponding tabs after ‘Services’ tab.\nThe worker detail page displays the following information:\n\nList of Jobs and status\nUptime Graph\nType of GPU/CPU\nUptime Percentage\nRemaining Compute Hours\nDaily block Rewards Earnings\nConnectivity Tier\nNotifications\n\n​FAQs\nQ: My graphics card is sufficient, but my internet or RAM is not enough. Can I still receive airdrop rewards?Yes, you can still receive rewards by running your Worker properly, although not as much as those who meet all the requirements and get jobs.Q: I have followed all the steps correctly, but my Worker is not visible on the website. What should I do?If you’ve completed all the steps in the guide and your Worker is still not visible, you can create a ticket in the #support-tickets channel on the Discord server for assistance.Q: Should I keep my computer on 24/7?For maximum airdrop rewards and system stability, it’s recommended to keep your computer running continuously. You can “pause” the system in emergencies, but extended periods of downtime may result in suspension.Q: Can I participate using a VPS?It is not recommended due to both the cost and potential issues it may cause.Q: My Worker status shows 'Idle' - is this a problem?No, “Idle” status means your Worker is not currently receiving jobs. There’s no issue with your system in this state.\nIf you’re seeking answers to other technical questions related to Worker, please refer to the Troubleshoots Worker page.Was this page helpful?","tokens":503,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791257709125,"hash":"9a14ad5dcbf4dd0c9dd66761e58e217c8ba63ed5"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/preparing/sui","domain":"docs.pyth.network","title":"Sui | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradeCompleting the Pyth Core upgradeSuiSui-specific notes for the Pyth Core upgrade.These notes complement the main upgrade guide for Sui consumers.\nManual upgrade is requiredThere is no automatic upgrade path on Sui. Apps reference the Pyth package by object ID, and the DAO cannot swap that for you. The upgrade cut over on August 26, 2026 at 16:00 UTC — complete the steps below if you haven't yet.\nGet a Pyth API KeyRequired for everyone who calls Hermes. Sign up at Pyth Terminal: a free trial is included, paid plans cover ongoing use.Sign up at Pyth TerminalMove your Hermes calls to the new Hermes endpointIf you use SuiPriceServiceConnection from @pythnetwork/pyth-sui-js, point it at the upgraded endpoint and pass your Pyth API key:import { SuiPriceServiceConnection } from \"@pythnetwork/pyth-sui-js\";\n\nconst connection = new SuiPriceServiceConnection(\n \"https://pyth.dourolabs.app/hermes\",\n { accessToken: process.env.PYTH_API_KEY },\n);If your SuiPriceServiceConnection doesn't accept an accessToken in its second constructor argument, you're on an outdated version of @pythnetwork/pyth-sui-js. Upgrade to the latest.Swap your contract addressOn Sui, swapping the Pyth Core contract address means updating the Pyth package rev in your Move.toml. The full list of upgraded Pyth State, Pyth Package, Wormhole State, and Wormhole Package IDs is on the contract addresses page.Current Pyth Core users reference the Pyth package in their Move.toml:[dependencies.pyth]\ngit = \"https://github.com/pyth-network/pyth-crosschain.git\"\nsubdir = \"target_chains/sui/contracts\"\nrev = \"sui-contract-mainnet\"The upgraded Pyth Core package is available at a new rev:[dependencies.pyth]\ngit = \"https://github.com/pyth-network/pyth-crosschain.git\"\nsubdir = \"target_chains/sui/contracts\"\nrev = \"sui-pro-compatible-contract-mainnet\" # or sui-pro-compatible-contract-testnetSui package compatibility may force you to keep both. Per Sui's custom package upgrade policies, you may need to keep the original Pyth package alongside the upgraded one in your Move.toml. Rename one to avoid a naming conflict:[dependencies.pyth]\ngit = \"https://github.com/pyth-network/pyth-crosschain.git\"\nsubdir = \"target_chains/sui/contracts\"\nrev = \"sui-contract-mainnet\"\n\n[dependencies.pyth_pro_compatible]\ngit = \"https://github.com/pyth-network/pyth-crosschain.git\"\nsubdir = \"target_chains/sui/contracts\"\nrev = \"sui-pro-compatible-contract-mainnet\" # or sui-pro-compatible-contract-testnet\nrename-from = \"pyth\"Then use the renamed package in your source code:use pyth_pro_compatible::price_info::PriceInfoObject;\nUpgraded Sui Addresses\nView on the contract addresses page →for SVM chainsPrevious PageAll Contract AddressesPyth Core (current), upgraded Pyth Core, and Pyth Pro contract addresses side by side for every supported chain.","tokens":706,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257715670,"hash":"248974368117ff3f16af56e9b79132e3f2aece0f"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/146","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 31\n\n 14\n\n 14\n\n 12\n\n 11\n\n read \n\n 36\n min\n\n Jan 2018\n\n 144 / 144\n\n May 2019\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jun 13, 2018\n\n kladkogex\n\n kfichter\n\n Well )) What I am saying is if reliance on a validators is OK for Casper why not to consider this (one can name it differently for the sake of purity )\nImho it seems that a system with burn proofs has lots of advantages in preventing users from doing bad things. Users arguably will try doing bad things way more frequently than plasma operators.\nWith burn proofs there is a potential problem of the Plasma operator witholding blocks/burn proofs, but it seems that a mechanism where a user can complain and force the operator to publish the block to a set of validators is an interesting alternative to explore …\n\n post by bradleat on Jun 13, 2018\n\n bradleat\n\nWill you elaborate on this please?\n\n post by danrobinson on Jun 13, 2018\n\n danrobinson\n\nThe family of protocols where you rely on a randomly sampled set of bonded validators to guarantee data availability and/or validity of a separate chain is generally called “sharding.” Such designs introduce many complications and assumptions that Plasma does not have, and provide many benefits that would make most of the mechanisms in Plasma irrelevant.\nMost notably, Plasma should be possible even if there is only a single operator for that chain (i.e. an exchange like Coinbase, or an app developer like Cryptokitties).\n\nIt’s definitely been explored, but the current thinking is that any challenge-response protocol around data availability is subject to problems around speaker/listener fault equivalence (https://vitalik.ca/general/2017/07/16/triangle_of_harm.html). Try designing such a protocol that is immune to griefing attacks and you will see what we mean.\n\n post by bradleat on Jun 15, 2018\n\n bradleat\n\nI don’t think this is correct. While I guess you are taking a subsection of participants and asking them to do certain work, the work is done for the entire set of participants. Sharding is about separating information so that work can be done in across each shard separately.\n\nThis seems to be geared towards block producers.\nA random group asked to confirm block availability does not need to also be able to produce blocks. The exact responsibility of the group would be to download blocks and collectively prove that as many other members of the chain have seen the block as possible.\nA griefing factor can be adjusted and weighted by users who have recently included transactions in the plasma chain. This means that the group of active users who are not censored have seen the data.\nStill to be made explicit is the exact cost of data unavailability. The operator could progressively lose a bond while users pay a sort of indirectly and partially refundable (by availability proof) fees for block inclusion. This means their uncensored users can collectively grief them. To me this seems totally acceptable for a plasma chain. The operator controls this set of users and the censored users can exit.\nThis has little to do with the consensus mechanism of the Plasma chain (i.e. it can still use POA), but more to do with a game that proves data availability. Which will be extremely important in non-UTXO version of plasma.\n\n 1 month later\n\n post by kladkogex on Jul 26, 2018\n\n kladkogex\n\nThe point that is unclear to me what is the end goal of Plasma development.\nTheoretically, one needs to produce a specification accepted by everyone. For this one needs to decide on the committee preferably by independent people. Otherwise, everyone can do whatever she perceives as correct. As an example, OmiseGo claims to develop a Plasma implementation. No one here can attest the security of this implementation. May be OmiseGo guys are supersmart and supersecure. By since there is no formal spec and no process no produce a formal spec other than @vbuterin approving it as secure at some point (as we remember the sharding spec and Casper were first approved and then disapproved), the entire discussion on this message board seems to have no purpose. Taking one person’s opinion however smart this person is is a bad way to produce security protocols. There are zillions of examples of problems that this creates starting from SSL v 2.0 going WEP, WPA etc. Ethereum foundation needs to grow up and mature otherwise there will be a high profile security breach at some point, which will lead to lots of embarrassment or a fork where some people will create an Ethereum clone with a formal security process. Lightning Network is a good example of how not to do things. It is a centralized network designed in a proprietary way and totally still born. No one in the world knows how Lightning Network works. Plasma so far follows the path of Lightning pretty closely.\nThe right way to design Plasma would be to first specify a security model (there is a Common Criteria standard for it btw), then discuss threats, then threat mitigation, then agree or disagree on the spec. Otherwise the security model is unknown, the threats are not specified or listed anywhere, and what is designed is totally unknown. The threat of a bad plasma operator is mitigated by people altruistically doing things, this idea alone has never worked in the real life, may be it works may be not, there has not been much of discussion of this part.\nThen there are emotional discussions on Twitter with no logical arguments brought on any side as to what is secure and what is not secure. BTW there is no absolute security of anything security or insecurity of something depends on the security model chosen and threats mitigated.\nAs we remember, Solidity was designed with security problems like integer overflow and recurrent behavior that no-one understood.\nIt is understandable though, since at that time Ethereum was essentially a startup. Nowadays, it seems like since development slowed down anyway, why not to introduce a more formal spec process that everyone will understand? It seems this will benefit everyone, including private companies around Ethereum.\n\n post by ldct on Jul 26, 2018\n\n ldct\n\nWhen the implementation is done, the security of it can be evaluated by reading the smart contracts and client code.\nBefore the implementation is available, one can read informal descriptions about the contract design to evaluate the design. The extent to which this is sufficient is subjective, of course, but personally there is plenty of detail available for me to understand the design to the extent that I don’t expect to be surprised by anything I didn’t think about if/when it goes on mainnet.\n\nFalse dichotomy. One can have useful discussion about ideas without requiring formal specification.\nAlso, I certainly didn’t trust Casper just because “Vitalik approved it”. I read the Casper paper, informally verified the proof, read the smart contract linked in the Casper EIP, and informally checked if it corresponded to the paper.\n\nNo one in the world knows how Lightning Network works.\n\nThe Lightning smart contracts are available at GitHub - lightning/bolts: BOLT: Basis of Lightning Technology (Lightning Network Specifications) for everyone to read, and they even include very helpful descriptions of what they smart contracts try to do. I’ve read it, and encourage you to if you’re interested in Layer 2 on Bitcoin.\n\nI don’t see how this follows at all. You can figure out an implied threat model by understanding the design.\n\nBTW there is no absolute security of anything security or insecurity of something depends on the security model chosen and threats mitigated.\n\nI agree with this, but this seems to undermine your proposed development model. In practice protocol development (IMHO) occurs by people designing the protocol and the security/threat models together, which makes it hard to design one without taking into consideration the other. There’s still no cross-blockchain-community consensus on very basic choices to be made at the layer one security/threat model (see: selfish mining, fee-stealing attacks in a 0-inflation world, verifier’s dilemma, dPoS, weak subjectivity, post-quantum security, 0-conf (amazingly enough), griefing in Casper-FFG, the staking/slashing metagame in PoS). On layer 2, people will probably disagree on how to evaluate griefing and collective action problems (like in MVP).\nI think there are absolutely some suggestions in this post about process that I agree with. I personally would like more precise (not necessarily formal) specifications and proofs, as well as more emphasis on the security/threat model. There also seems to be no consensus around the necessity of formal specification as well as formal verification (the FFG paper was, to some extent, and the contract was slated to undergo it, but most dapps today don’t formally verify stuff before launch, and some write rather imprecise specs). But I think most of this is just personal preference, and as long as we seek clarification, welcome/address good-faith criticism, read code and think for ourselves, run independent audits, and don’t rush for mainnet launches too much, it shouldn’t be necessary to drastically change the development process.\n\n post by jjyr on Jul 29, 2018\n\n jjyr\n\n Hi, may I ask a maybe stupid question?\nI can’t get the point how Minimal Viable Plasma can help to improve the network scalability if we need to wait for a transaction confirmed in a block to send it? Or the scalability is not a purpose in MVP phase?\n\nUser Behavior\nThe process for sending a Plasma coin to someone else is as follows:\n\nAsk them for their address.\nSend a transaction that sends some of your UTXOs to their address.\nWait for it to get confirmed in a block.\nSend them a confirm message, signed with the keys that you use for each of your UTXO inputs.\n\n post by danrobinson on Jul 29, 2018\n\n danrobinson\n\nThere are a lot of components to scalability. MVP primarily improves throughput (roughly speaking, the number of transactions that can be finalized every N seconds), rather than latency (the amount of time before a given transaction is confirmed).\nIt improves throughput because the transaction only gets included in a Plasma chain block, and only the root hash of that block needs to be published to the main Ethereum chain.\n\n 25 days later\n\n post by osuketh on Aug 23, 2018\n\n osuketh\n\n We’ve implemented Plasma MVP in Vyper with @nrryuya\nhttps://github.com/LayerXcom/plasma-mvp-vyper\nAnd, just published the blog post about the Implementation.\nhttps://medium.com/layerx/plasma-mvp-implementation-in-vyper-5a3850e5b1b\n\n post by MihailoBjelic on Aug 27, 2018\n\n MihailoBjelic\n\nVery late but just wanted to stress that (at least for now) Plasma achieves this by putting the burden on the end users instead. I really like Plasma and I think it has potential, but this fact is simply not being mentioned enough, although it should be… The main focus of researchers/designers of any IT/tech system should always be to relieve the burden of the end users (because by default they have less resources and are used to be “spoiled” by good UX), and than even of the business owners (operators in our case) if possible.\nI’m writing all of this in hope that Plasma research community will eventually start thinking in this direction. \n\n post by ldct on Aug 27, 2018\n\n ldct\n\n I think it’s worth specifying what a “user” is more precisely, specifically who is being burdened. Most people will run the default client software and making sure that software keeps their money secure is absolutely part of a working plasma implementation, and that software will be pretty complicated (IMO more complicated than for e.g. LND), since the client rules for the plasma specs aren’t straightforward, and you have to deal with normal SWE stuff like what if the user power cycles, uninstalls their app, etc and make sure they don’t interfere with the security of their funds.\n\n post by MihailoBjelic on Aug 29, 2018\n\n MihailoBjelic\n\nI’m talking primarily about end users, e.g. traders on a trading platform that sits on a Plasma chain, or cat collectors/breeders on a CryptoKitties-like Plasma chain.\n\nCompletely agree. I believe that should be obvious by now, and we’ve barely scratched the surface with smart contracts on Plasma and other complex stuff.\nHaving the above in mind, we can make the following conclusion: If anyone wants to own a kitty or hold some money on a trading platform, or hold any value on any Plasma chain in general, they need to have a dedicated machine that will constantly be online, checking TWO blockchains (every block on the main chain looking for exits and every block on the Plasma chain looking for invalid or withholded blocks). And if we imagine a future where I hold some value in e.g. 5 different Plasma chains (which I think is completely realistic) things get pretty ugly. \nThis is a huge step backwards in UX compared to both centralized services and “original” blockchains like Bitcoin and Ethereum.\nIMHO, no wide adoption will happen if the community doesn’t accept this as a fact and work on it.\n\n post by ashishrp on Sep 1, 2018\n\n ashishrp\n\nTrue i think same way with sharding too, like create multiple shards/plasma(visualise it as ring of nodes) and then each shard/plasma will be connected with multiple two-way pegs(which will transfer token between those shards/plasma obviously). i know this is just idea we need to do some research but this seems neat to me.\n\n 3 months later\n\n post by Dev43 on Nov 20, 2018\n\n Dev43\n\nIm trying to understand the meaning of this. Am I right in thinking that the priority is either\nblknum * 1000000000 + txindex * 10000 + oindex or blknumFromOldBlock * 1000000000 + txindex * 10000 + oindex\nNow this could mean that if txindex and oindex are the same for this block and the old block, then they would have the same priority? This could mean that if you save exits in a mapping by priority, then it would overwrite the ealier exit?\n\n 2 months later\n\n post by Swader on Jan 6, 2019\n\n Swader\n\n If all clients are expected to monitor the validity of the plasma blocks at all times and report bad behavior incentivized by exit deposits in cases where exits were successfully challenged, wouldn’t that mean plasma can’t properly scale if clients have the ability to automatically detect frauds? In other words, if there’s 10000 people on a plasma chain with 5000 online, and one attempts an invalid exit, wouldn’t 4999 then notice this and submit challenges at the same time, thereby gut-punching the network with 4999 simultaneous transactions? Worse yet, isn’t there an obvious attack vector there wherein someone can enter with 0.001 eth, try to exit with 1 eth, and thereby constantly grief not only the various plasma chains in existence but also the main chain by triggering plasma clients around the world into noticing obviously invalid exits?\nSorry if this was discussed in the topic, missed it if so.\n\n 11 days later\n\n post by DZack on Jan 17, 2019\n\n DZack\n\nThere is a difference that makes the mass exit threat in plasma MVP worse (I think this may be clearer in retrospect): for a centralized channel hub, the malicious/ hacked hub operator can force each user to exit onto the main chain, but it requires the hub to broadcast a transaction for each user (or more specifically, each channel). Whereas in plasma MVP, just one transaction from the operator is enough to force all users to exit.\n\n post by DZack on Jan 17, 2019\n\n DZack\n\nA random user couldn’t do this, because the attempted 1 eth exit would require a merkle proof of the corresponding utxo (which doesn’t actually exist). This griefing vector only works if you can get an invalid utxo included in the plasma block (and thus the Merkle root), so the operator would have to be in on it.\n\n post by MihailoBjelic on Jan 17, 2019\n\n MihailoBjelic\n\nGood observation, but I think in reality it could be pretty much the same thing. If a centralized hub tries something malicious in one (or a few) channel(s) and the counterparty user is forced to close the channel, the news will spread (by observing the main chain or through off-chain channels) and people will start leaving the hub, i.e. closing their channels. Does that make sense?\n\n post by DZack on Jan 17, 2019\n\n DZack\n\n Indeed, the panic-factor may ultimately lead to channel exits anyway. (Although I, for one, would defiantly keep my channel open with the hub until forced to settle; cryptoeconomics, dammit!!!)\n\n 4 months later\n\n post by pepesza on May 15, 2019\n\n pepesza\n\nOperator, while submitting a block, adds a hash describing his knowledge about deposits in the contract. Contract computes his own summary of state of deposits and compares it with submitted one. If not equal, transaction submitting the block is rejected. This solution enables operator to spend deposits as soon as they appear, without waiting.\nGas cost of this solution is 200 + 42 (SLOAD, SHA3 on two words) gas per deposit made to the chain, paid by operator.\n\n Powered by Discourse","tokens":4262,"squid":"ink-research","role":"Deep Scholar","at":1791257722728,"hash":"346ba166d35d3d08db93272ba5cbe0a6ca3b08b9"}
{"url":"https://docs.pyth.network/price-feeds/core/getting-started","domain":"docs.pyth.network","title":"Getting Started | Pyth Developer Hub","text":"Pyth CoreGetting StartedExplore key resources to begin integrating Pyth price feedsIntegrating Pyth price feeds is quick and easy. Pyth price feeds are permissionless on-chain. Since August 26, 2026, calling the Hermes price API requires a Pyth API Key — see the upgrade callout below.\nPyth Core was upgraded on August 26, 2026We recommend new integrations use the upgraded contract addresses.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nPyth offers several different resources to help you get started.\nThe Build section provides resources for developers integrating Pyth price feeds into their applications.\nThe Learn section provides general material for anyone interested in understanding how the protocol works.\nBuild\nDevelopers interested in using Pyth can refer to the following resources:\n\nCreate Your First Pyth App is a tutorial that walks the reader through all of the steps required to develop, test and deploy a contract using Pyth price feeds. This guide is tailored toward new developers with less contract development experience.\nUse Real-Time Price Data is a how-to guide that provides the minimal steps to integrate price feeds into your app. This guide is targeted towards more experienced developers who know the basics of smart contract development.\nUse Historical Price Data is a how-to guide that provides the minimal steps to integrate historical price data into your app.\nAPI Reference is an interactive playground that provides a detailed overview of the Pyth smart contract's functionality. This guide is useful for developers who want to understand the full capabilities of the Pyth oracles.\n\nIn addition to the resources above, the following reference materials will be useful for developers as they integrate:\n\nPrice Feed IDs lists the price feed IDs for all the assets supported by Pyth.\nContract Addresses provides the contract addresses for Pyth on different chains.\nError Codes lists the error codes that can be returned by the Pyth contracts.\nBest Practices explains how to use Pyth price feeds safely and effectively in your application.\n\nLearn\nFor those interested in learning more about Pyth, the following resources are available:\n\nHow Pyth Works explains that Pythnet is shutting down and points to the current Pyth architecture.\nPyth CoreIntroduction to Pyth Core Price FeedsPyth Core UpgradePyth Core was upgraded on August 26, 2026. Check that your integration is up to date.","tokens":629,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257725411,"hash":"49b035475e68d5322a784c661b28ab918e9d14a8"}
{"url":"https://ethresear.ch/c/layer-2/plasma/7","domain":"ethresear.ch","title":"Latest Layer 2/Plasma topics - Ethereum Research","text":"Latest topics in Plasma\n\n Layer 2\n\n Plasma\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Plasma category\n\n 2\n\n 2.9k\n\n Aug 2020\n\n Universal Plasma and DA challenges\n\n 0\n\n 2.5k\n\n Feb 2025\n\n Plasma Cash: Plasma with much less per-user data checking\n\n new-extension\n\n 115\n\n 109k\n\n Dec 2024\n\n **Plasma Free**\n\n 8\n\n 6.0k\n\n Jun 2024\n\n Plasma Next Next (Beetlejuice Beetlejuice)\n\n stateless\n\n 6\n\n 3.8k\n\n May 2024\n\n Discussion thread for EVM plasma ideas\n\n 5\n\n 4.2k\n\n May 2024\n\n Plasma Next: Plasma without Online Requirements\n\n stateless\n\n 7\n\n 6.6k\n\n May 2024\n\n NOCUST - A Securely Scalable Commit-Chain\n\n 1\n\n 3.1k\n\n Apr 2023\n\n How is Plasma Chain’s security better than Side Chain’s?\n\n 0\n\n 1.2k\n\n Jun 2021\n\n Data Availability Question: Why would a node accept blocks with invalid bodies?\n\n 1\n\n 1.3k\n\n Jun 2021\n\n RSA Accumulators for Plasma Cash history reduction\n\n 23\n\n 20.2k\n\n Oct 2020\n\n More Viable Plasma\n\n new-extension\n\n 62\n\n 25.0k\n\n Oct 2020\n\n Compact Sparse Merkle Trees  osf.io\n\n sparse-merkle-tree\n\n 17\n\n 8.9k\n\n Jul 2020\n\n Build on layer 2 or wait for eth to scale?\n\n 1\n\n 1.5k\n\n Jul 2020\n\n BLS signatures to overcome data availability issues and exit games in Plasma\n\n zk-roll-up,signature-aggregation\n\n 2\n\n 2.9k\n\n Mar 2020\n\n Plasma Cash vs Plasma MVP — inherent separation\n\n 0\n\n 1.4k\n\n Feb 2020\n\n Hierarchical Plasma proposal\n\n 0\n\n 2.0k\n\n Sep 2019\n\n Watchtowers may not work in Plasma (Cash)\n\n 8\n\n 4.2k\n\n Jul 2019\n\n NFT Plasma implemetation\n\n 4\n\n 3.2k\n\n Jun 2019\n\n Problems with Plasma Cash\n\n 3\n\n 3.0k\n\n Jun 2019\n\n Plasma EVM with Continuous Rebase\n\n 0\n\n 2.6k\n\n Jun 2019\n\n Account based Plasma (MoreVP)\n\n 2\n\n 13.8k\n\n Jun 2019\n\n Minimal Viable Plasma\n\n new-extension\n\n 143\n\n 142k\n\n May 2019\n\n Separating the role of signatures in transaction validity vs slashing\n\n 0\n\n 2.0k\n\n May 2019\n\n Question - alternative accumulators for history\n\n 0\n\n 1.3k\n\n Apr 2019\n\n Merklux & Plasma Plant\n\n 11\n\n 3.8k\n\n Apr 2019\n\n Validity Proofs + Plasma Cash = Simpler Exit Game/Coin History?\n\n 0\n\n 1.9k\n\n Apr 2019\n\n A Distributed Breeding Function\n\n 2\n\n 4.2k\n\n Apr 2019\n\n Litigable Protocols\n\n 1\n\n 2.1k\n\n Apr 2019\n\n Plasma Cash was a transaction format\n\n 3\n\n 6.0k\n\n Apr 2019","tokens":554,"squid":"ink-research","role":"Deep Scholar","at":1791257733021,"hash":"bc8fea47465d4e1bb1d2bc2efa54f51dd345ed93"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/contracts","domain":"docs.pyth.network","title":"All Contract Addresses | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradeAll Contract AddressesPyth Core (current), upgraded Pyth Core, and Pyth Pro contract addresses side by side for every supported chain.Pyth has three kinds of on-chain contracts. This page explains how to tell them apart and lists all three side by side, per chain.\nIf you remember one thing: Pyth Core and Pyth Pro are two different\nproducts with two different shapes. The \"upgraded\" contract is not Pro. It's\nthe next generation of the Pyth Core contract you already use: same\ninterface, same feed IDs, now with the richer data and customizability that\nPro introduced.\nWhat it isBuilt forPyth Core (current)The contract you integrated against today. Keeps a shared price on-chain that any contract can readExisting integrationsPyth Core (upgraded)The same interface and feed IDs at a new address, with richer data and more customization. Still keeps the shared price on-chainUpgrading your existing integration: swap the contract address and the Hermes endpoint together, with an API keyPyth ProA different model: no price stored on-chain. Each transaction carries its own millisecond-fresh signed price, verified on the spotLatency-critical trading priced per transaction: perps fills, RFQ and quote-based execution\nThe real difference between upgraded Core and Pro\nUpgraded Core keeps one shared price on-chain.\n\nYour contract calls getPriceNoOlderThan and reads the same canonical price every other protocol on the chain sees.\nThat's the shape lending markets, CDPs, and vaults are built around: liquidations triggered by third parties, share prices computed in view functions, protocols composing by reading the same stored value.\nSponsored push feeds keep the price fresh, so passive protocols integrate with a single read.\nThe upgrade changes none of this: same interface, same feed IDs, better data behind them.\n\nPyth Pro attaches the price to each transaction.\n\nNothing is stored on-chain. Every transaction that needs a price carries a freshly signed one, verified on the spot.\nEach trade executes on a price that is milliseconds old: what perps fills and RFQ execution need, and what no stored price can provide.\nThe trade-off: no shared price for other contracts to read.\n\nOne question decides it. Do other contracts, third-party liquidators, or\nview functions need to read your price on-chain? If yes, you want Core.\nIf not, take a look at Pyth Pro.\nWhat happened on August 26, 2026 at 16:00 UTC\n\nYour current contract was upgraded in place. It accepts the new data payloads automatically. You kept your address, and your feed IDs didn't change; nearly all feeds carried over (check yours).*\nhermes.pyth.network was redirected to the upgraded backend. The URL keeps working, but every request needs a Pyth API Key since that day.\n\"Current\" and \"upgraded\" are now the same thing, and that distinction is disappearing. What remains is Core vs Pro: the same upgraded data, either stored on-chain for everyone to read, or attached fresh to each transaction.\n\n* Except on Sui, where the in-place upgrade isn't possible; see the Sui upgrade guide.\nThe two mistakes this page exists to prevent\n\nSwapping a Core integration to a Pro address. Pro has a different interface, different feed IDs, and no stored price to read, so it isn't a drop-in replacement for a Core integration. If you're upgrading Core, you want the upgraded Core address (listed below).\nSwapping the contract address without moving your data source, or vice versa. Each endpoint's payloads verify only on its own contract generation. The August 26 cutover switched both together for existing integrations; if you swap now, swap the contract address and the Hermes endpoint together.\n\nWhere to go next: the upgrade guide for the how, or the Pyth Pro docs if per-transaction pricing is what you need. All addresses, all three kinds, are below.\nEVM\nMainnets\nNetworkPyth Core (current)Pyth Core (upgraded)Pyth Pro0G Mainnet0x2880...C17B43——Abstract—0x6b81...c0775c—ApeChain0x2880...C17B43——Arbitrum One—0xe153...76f38e0xACeA...2dF481Arc—0x8250...B1487a0xACeA...2dF481Astar zkEVM0xA2aa...5B5729——Aurora Mainnet0xF89C...0c9AB9——Avalanche C-Chain0x4305...4c69C6——Base—0xbC16...E272F50xACeA...2dF481Berachain—0x2F96...535eE50xACeA...2dF481BitTorrent Chain Mainnet0xA2aa...5B5729——Blast0xA2aa...5B5729——BNB Smart Chain Mainnet—0xdF21...0538d50xACeA...2dF481Boba Network0x4374...F15DAF——Camp Network Mainnet0x2880...C17B43——Canto0x9804...978603——Celo Mainnet0xff1a...12925C——Chiliz Chain Mainnet0xA2aa...5B5729——CLV Parachain——Conflux eSpace0xe9d6...5c8ADc——Core Blockchain Mainnet0xA2aa...5B5729——Cronos Mainnet—0x6E7D...6181Bb0xACeA...2dF481Cronos zkEVM Mainnet0x056f...aB71af——Data Network0xD458...e6F134——EOS EVM Network0xA2aa...5B5729——Ethereal——0xACeA...2dF481Ethereum Mainnet—0x14b9...6D85520xACeA...2dF481Etherlink Mainnet—0x9DF0...17ee1a0xACeA...2dF481Eventum Mainnet0x2880...C17B43——Evmos0x354b...616E12——Fantom Opera0xff1a...12925C——Filecoin - Mainnet0xA2aa...5B5729——Flow EVM Mainnet—0xfA25...9566830xACeA...2dF481Fluent0xe9d6...5c8ADc—0xACeA...2dF481Gnosis0x2880...C17B43——Gravity Alpha Mainnet0x2880...C17B43——Hedera Mainnet0xA2aa...5B5729——Hemi0x2880...C17B43——Horizen EON Mainnet——HyperEVM—0x298B...9BbC020xACeA...2dF481Injective EVM—0x4821...9D70610xACeA...2dF481Ink0x2880...C17B43——IOTA EVM0x8D25...721933——Kaia Mainnet0x2880...C17B43——Kava0xA2aa...5B5729——KCC Mainnet0xE0d0...2dbA5B——Kinto Mainnet0x2880...C17B43——Lightlink Phoenix Mainnet0xA2aa...5B5729——Linea—0x986c...45f6f9—Manta Pacific Mainnet0xA2aa...5B5729——Mantle0xA2aa...5B5729——MegaETH0x2880...C17B43—0xACeA...2dF481Merlin Mainnet0xA2aa...5B5729——Meter Mainnet0xbFe3...E3AF16——Mezo—0x5D28...9f71670x00Aa...dB4Eb8Mode0xA2aa...5B5729——Monad—0xB754...36508d0xACeA...2dF481Morph0x2880...C17B43——Neon EVM Mainnet0x7f2d...B4f9A5——OP Mainnet—0xa789...C5E4B2—opBNB Mainnet0x2880...C17B43——Orange——Plasma Mainnet0x2880...C17B43——Polygon Mainnet—0x6E7D...6181Bb0xACeA...2dF481Polygon zkEVM0xC5E5...537c65——Polynomial0x2880...C17B43——Robinhood Chain—0x8250...B1487a0xACeA...2dF481Ronin Mainnet0x2880...C17B43——Scroll0xA2aa...5B5729——Sei Network—0x1639...2848380xACeA...2dF481ShimmerEVM0xA2aa...5B5729——Skate Mainnet0x2880...C17B43——Soneium—0xC0F5...D1850E0xACeA...2dF481Sonic Mainnet—0x2b9B...7d2FE40xACeA...2dF481Subtensor EVM——Superseed0x2880...C17B43——Swellchain0xDd24...5Bbd21——Taiko0x2880...C17B43——Tempo0x2880...C17B43—0xACeA...2dF481Unichain0x2880...C17B43——Viction——WEMIX3.0 Mainnet0xA2aa...5B5729——World Chain0xe9d6...5c8ADc——XCHAIN0x2880...C17B43——ZetaChain Mainnet0x2880...C17B43——ZKFair Mainnet0xA2aa...5B5729——zkSync Mainnet0xf087...c5D834——\nTestnets\nNetworkPyth Core (current)Pyth Core (upgraded)Pyth ProAbstract Sepolia Testnet0x47F2...63b4860xcc17...6AaCe4—Amoy—0x0708...14508b—Arbitrum Blueberry0xA2aa...5B5729——Arbitrum Sepolia—0x0B73...47f42B0xACeA...2dF481Arc Network Testnet0x2880...C17B43—0xACeA...2dF481Aurora Testnet0x74f0...E3e94E——Avalanche Fuji Testnet0x23f0...3d7509——Base Sepolia Testnet—0x5f52...a4EB830xACeA...2dF481Berachain Bepolia—0xFfb6...fE708C—BinaryChain Mainnet0x2880...C17B43——BitTorrent Chain Donau0xA2aa...5B5729——Blast Sepolia Testnet0xA2aa...5B5729——BNB Smart Chain Testnet0x5744...8EF0Fb—0xACeA...2dF481Boba Network Goerli Testnet0x8D25...721933——Canto Tesnet0x26DD...595E85——Celo Alfajores Testnet0x74f0...E3e94E——Celo Sepolia Testnet0x2880...C17B43——Chiliz Spicy Testnet0x23f0...3d7509——Conflux eSpace (Testnet)0xDd24...5Bbd21——Converge Testnet——Core Blockchain Testnet0x8D25...721933——Core Blockchain Testnet20x2880...C17B43——Cronos Testnet—0xf777...D2D7Ba0xACeA...2dF481Cronos zkEVM Testnet0xB1DB...37E1D6——Curtis0x2880...C17B43——Data Network Aeneid Testnet0x3682...39e320——Dela Mithreum Deperp Testnet——Dela Sepolia Testnet0xA2aa...5B5729——Edgeware EdgeEVM Mainnet0xEbe5...45C486——EOS EVM Network Testnet0x0708...14508b——Ethena Testnet——Ethereal Testnet V2——0x4D47...DE8245Ethereum Hoodi0x8704...e08672——Ethereum Sepolia—0xBb86...c1e2860xACeA...2dF481Etherlink Ghostnet Testnet0x2880...C17B43——Etherlink Shadownet Testnet0x2880...C17B43——Eventum Testnet0x2880...C17B43——Evmos Testnet0x74f0...E3e94E——Fantom Testnet0x5744...8EF0Fb——Filecoin - Calibration testnet0xA2aa...5B5729——Flow EVM Testnet0x2880...C17B43——Fluent Testnet——GIWA Sepolia Testnet0x2880...C17B43——Gnosis Chiado Testnet0x9804...978603——Hedera Testnet0xA2aa...5B5729——Hemi Sepolia0x2880...C17B43——Hyperliquid EVM Testnet——Injective Testnet0xDd24...5Bbd21—0xACeA...2dF481Ink Sepolia0x2880...C17B43——Kaia Kairos Testnet0x2880...C17B43——Kakarot Starknet Sepolia0xe9d6...5c8ADc——Kava Testnet0xfA25...956683——KCC Testnet0x74f0...E3e94E——Lightlink Pegasus Testnet0x5D28...9f7167——Linea Goerli0xdF21...0538d5——Linea Sepolia0xA2aa...5B57290xed77...5a5f95—Manta Pacific Sepolia Testnet0xA2aa...5B5729——Manta Pacific Testnet0x41c9...830d4c——Mantle Sepolia Testnet0x9804...978603——MegaETH Testnet (Deprecated)——Meter Testnet0x5a71...64c3E4——Mezo Testnet—0x933a...a313150x768d...542D97Mode Testnet0xA2aa...5B5729——Monad Testnet—0xFC6b...5ed3790xACeA...2dF481Morph Holesky0x2880...C17B43——Morph Hoodi——Morph Testnet0xA2aa...5B5729——Movement EVM Testnet0x2880...C17B43——Mumbai0xFC6b...5ed379——Neon EVM Devnet0x0708...14508b——Nollie Skatechain Testnet0x2880...C17B43——Olive Testnet——OP Celestia Raspberry0xA2aa...5B5729——OP Sepolia Testnet—0xEAef...9E3e350xACeA...2dF481opBNB Testnet0x41c9...830d4c——Parallel Testnet——Polygon Blackberry0xA2aa...5B5729——Polygon zkEVM Testnet0xFf25...C77635——Polynomial Sepolia0x23f0...3d7509——Reya Cronos0x2880...C17B43——Robinhood Chain Testnet—0x8250...B1487a0xACeA...2dF481Scroll Sepolia Testnet0x41c9...830d4c——Sei Testnet0x2880...C17B43——Shiden0xA2aa...5B5729——ShimmerEVM Testnet0x8D25...721933——Soneium Testnet Minato—0x5c47...33ce750xACeA...2dF481Sonic Blaze Testnet0x2880...C17B43—0xACeA...2dF481Sonic Testnet—0x0402...540519—Subtensor EVM Testnet0x4195...4fCcA1——Superseed Sepolia Testnet0x2880...C17B43——Swellchain Testnet0x26DD...595E85——Syndr Nitro Testnet——Tabi Testnetv20x5744...8EF0Fb——Taiko Hekla (deprecated)——Taiko Hoodi0x2880...C17B43——Tempo Testnet0x74f0...E3e94E—0xACeA...2dF481Unichain Sepolia Testnet0x2880...C17B43——WEMIX3.0 Testnet0x26DD...595E85——Won Network0xA2aa...5B5729——World Chain Sepolia Testnet0x2880...C17B43——XCHAIN Testnet0x2880...C17B43——ZetaChain Testnet0x0708...14508b——zKatana0x8D25...721933——ZKFair Testnet0xA2aa...5B5729——zkSync Sepolia Testnet0x056f...aB71af——\nA — means that flavor isn't deployed on the chain. If your chain has no upgraded address, contact the team.\nSolana\nPyth Core programs\nThe same program addresses are used across SVM networks.\nProgramPyth Core (current)Pyth Core (upgraded)Wormhole receiverHDwcJB...8SWWaQHDw2E7...pVYrVLSolana receiverrec5EK...v5LtFJrec2HH...2cRyHpPrice feedpythWS...2biRsTpyt2F4...brPCou\nPyth Core is also deployed on other SVM chains, including Eclipse, Sonic, Atlas, and Fogo. See the Core Solana and SVM contract addresses page for those.\nPush Feed Accounts (Mainnet)\nEach Solana push feed lives at a PDA derived from the Price Feed program ID and the price feed ID. The Price Feed program ID changes at the upgrade, so every per-feed account address changes too. Below are the upgraded account addresses (shard 0) for every sponsored feed. For the current (pre-upgrade) addresses, see the push feeds on Solana page.\nThe price feeds listed below are currently sponsored in Solana mainnet and devnet.Default:55 seconds heartbeat / 0.5% price deviation(61)Exception:30 seconds heartbeat / 0.5% price deviation(2)Exception:3 minutes heartbeat / 0.05% price deviation(1)NameUpgraded Account AddressPrice Feed IdUpdate ParametersSOL/USD55 seconds heartbeat0.5% price deviationMSOL/USD55 seconds heartbeat0.5% price deviationBSOL/USD55 seconds heartbeat0.5% price deviationSSOL/SOL55 seconds heartbeat0.5% price deviationBONK/USD55 seconds heartbeat0.5% price deviationW/USD55 seconds heartbeat0.5% price deviationMEW/USD55 seconds heartbeat0.5% price deviationUSDC/USD55 seconds heartbeat0.5% price deviationBTC/USD55 seconds heartbeat0.5% price deviationUSDT/USD55 seconds heartbeat0.5% price deviationJUP/USD55 seconds heartbeat0.5% price deviationETH/USD55 seconds heartbeat0.5% price deviationPYTH/USD55 seconds heartbeat0.5% price deviationWIF/USD55 seconds heartbeat0.5% price deviationINF/USD55 seconds heartbeat0.5% price deviationMNDE/USD55 seconds heartbeat0.5% price deviationJLP/USD55 seconds heartbeat0.5% price deviationWBTC/USD55 seconds heartbeat0.5% price deviationTRUMP/USD55 seconds heartbeat0.5% price deviationFARTCOIN/USD55 seconds heartbeat0.5% price deviationACRED/USD55 seconds heartbeat0.5% price deviationPUMP/USD55 seconds heartbeat0.5% price deviationJUPSOL/SOL.RR55 seconds heartbeat0.5% price deviationNAV.USTB/USD55 seconds heartbeat0.5% price deviationNAV.USCC/USD55 seconds heartbeat0.5% price deviationZBTC/USD55 seconds heartbeat0.5% price deviationLBTC/USD55 seconds heartbeat0.5% price deviationINF/SOL.RR55 seconds heartbeat0.5% price deviationSYRUPUSDC/USDC.RR55 seconds heartbeat0.5% price deviationORE/USD55 seconds heartbeat0.5% price deviationNOPAL/USD.RR55 seconds heartbeat0.5% price deviationNTBILL/USD.RR55 seconds heartbeat0.5% price deviationNBASIS/USD.RR55 seconds heartbeat0.5% price deviationNWISDOM/USD.RR55 seconds heartbeat0.5% price deviationNALPHA/USD.RR55 seconds heartbeat0.5% price deviationNFALCON/USD.RR55 seconds heartbeat0.5% price deviationCASH/RD.RR30 seconds heartbeat0.5% price deviationCASH/USD30 seconds heartbeat0.5% price deviationPST/USDC.RR3 minutes heartbeat0.05% price deviationJUPUSD/USD55 seconds heartbeat0.5% price deviationEquity.US.GLXY/USD55 seconds heartbeat0.5% price deviationHYUSD/JITOSOL.RR55 seconds heartbeat0.5% price deviationEHYUSD/JITOSOL.RR55 seconds heartbeat0.5% price deviationXSOL/JITOSOL.RR55 seconds heartbeat0.5% price deviationJITOSOL/USD55 seconds heartbeat0.5% price deviationJITOSOL/SOL.RR55 seconds heartbeat0.5% price deviationMSOL/SOL.RR55 seconds heartbeat0.5% price deviationJTO/USD55 seconds heartbeat0.5% price deviationRENDER/USD55 seconds heartbeat0.5% price deviationZEC/USD55 seconds heartbeat0.5% price deviationDSOL/USD55 seconds heartbeat0.5% price deviationDSOL/SOL.RR55 seconds heartbeat0.5% price deviationMET/USD55 seconds heartbeat0.5% price deviationCLOUD/USD55 seconds heartbeat0.5% price deviationHYPE/USD55 seconds heartbeat0.5% price deviationUSD1/USD55 seconds heartbeat0.5% price deviationBNSOL/USD55 seconds heartbeat0.5% price deviationTNSR/USD55 seconds heartbeat0.5% price deviation2Z/USD55 seconds heartbeat0.5% price deviationAAVE/USD55 seconds heartbeat0.5% price deviationEURC/USD55 seconds heartbeat0.5% price deviationSYRUPUSDC/USD55 seconds heartbeat0.5% price deviationUSDE/USD55 seconds heartbeat0.5% price deviationRKUSOL/SOL.RR55 seconds heartbeat0.5% price deviation\nPyth Pro program\nNetworkPyth ProSolana Mainnetpytd2yyk641x7ak7mkaasSJVXh6YYZnC7wTmtgAyxPt\nFor devnet and testnet, see the Pyth Pro contract addresses page.\nSui\nMainnet\nCurrentUpgradedPyth State ID0x1f9310238ee9298fb703c3419030b35b22bb1cc37113e3bb5007c99aec79e5b80x03719fae774ddab3cfcaa53bbc046f0cbe21410019b6280811bf3f9f4b05839dPyth Package ID0x04e20ddf36af412a4096f9014f4a565af9e812db9a05cc40254846cf6ed0ad910x55300367a2d40813727ccac4ecee977a39fb9cdb46f2e6b2c354b9798f5de2c0Wormhole State ID0xaeab97f96cf9877fee2883315d459552b2b921edc16d7ceac6eab944dd88919c0xdbca52b9fb4f712e25f61f974586d93ac541bcf8389564f0323bb07215168b5cWormhole Package ID0x5306f64e312b581766351c07af79c72fcb1cd25147157fdc2f8ad76de9a3fb6a0x99de5c967d8206ef4b75c0afab3df2a59eb02b05c282821db803831008ac25b4\nTestnet\nCurrentUpgradedPyth State ID0x243759059f4c3111179da5878c12f68d612c21a8d54d85edc86164bb18be1c7c0x3c48fe392912de6c18087a2b3f5fdbfbfdb4598e180947feff1f12f8e9ea073ePyth Package ID0xabf837e98c26087cba0883c0a7a28326b1fa3c5e1e2c5abdb486f9e8f594c8370xd1ac23e1582080e2e5d43dbad1cf463ea2337cdbbb1a9ca669e470cefb74d8fdWormhole State ID0x31358d198147da50db32eda2562951d53973a0c0ad5ed738e9b17d88b213d7900x750da8e6d16b6a363a39fe2eaa8295ac224a1e6fce4e47b58845e2e8746164f0Wormhole Package ID0xf47329f4344f3bf0f8e436e2f7b485466cff300f12a166563995d3888c296a940xe79f4e3e02ce132f40f39e73220493a802329d3cb6ad7f789e98a78910fc0053\nPyth Pro on Sui: see the Pyth Pro contract addresses page.\nChains with Pyth Pro only\nCardano and Stellar have native Pyth Pro deployments; see the Pyth Pro contract addresses page.\nDon't see your chain, or unsure which contract applies to you? We're\nadding chains regularly and can discuss custom arrangements. Contact the\nteam →for SuiPrevious PageHow the upgraded Pyth Core worksA technical look at the signers, data flow, and contracts behind the upgrade.","tokens":4161,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257736607,"hash":"35349e10c771aaa0fa3d772f11f06b654498b3ba"}
{"url":"https://www.anchor-lang.com/docs/testing/fuzzing","domain":"anchor-lang.com","title":"Fuzzing","text":"Testing LibrariesFuzzingCoverage-guided fuzzing for Solana programs using Crucible.Overview\nanchor fuzz provides coverage-guided fuzzing for Solana programs via Crucible. It generates random action sequences against your program, checking invariants after each action to find bugs that unit tests miss.\nFeatures include stateful invariant testing, multi-core parallel fuzzing, crash minimization, and LCOV coverage output.\nFor full documentation and API reference, see the Crucible repo.\nQuick Start\nInitialize a harness\nanchor fuzz init <program_name>\nThis creates a standalone fuzz workspace in fuzz/<program_name>/ with the following structure:\nfuzz/<program_name>/\n├── Cargo.toml\n├── rust-toolchain.toml\n├── idls/<program_name>.json\n└── src/main.rs\nRun a fuzz test\nanchor fuzz run <program_name> <test_name> --release\nCommon options\n# Multi-core fuzzing (4 workers)\nanchor fuzz run <program_name> <test_name> --release --cores 4\n\n# Stateful fuzzing (state coverage + better performance but higher memory usage)\nanchor fuzz run <program_name> <test_name> --release --stateful --cores 4\n\n# Stop after 60 seconds\nanchor fuzz run <program_name> <test_name> --release --timeout 60\n\n# Replay a crash\nanchor fuzz run <program_name> <test_name> --release --replay ./crashes/<test_name>/<crash_id>\nView and minimize crashes\n# List crashes\nanchor fuzz show <program_name>\n\n# View crash metadata\nanchor fuzz show <program_name> <crash_file>\n\n# Minimize a crash to smallest reproducing sequence\nanchor fuzz tmin <program_name> <test_name> <crash_file> --release\nWriting a Harness\nA fuzz harness defines a fixture with actions (state transitions) and invariants (properties that must always hold).\nuse crucible_fuzzer::prelude::*;\n\n#[derive(Clone)]\nstruct MyFixture {\n ctx: TestContext,\n admin: Rc<Keypair>,\n}\n\n#[fuzz_fixture]\nimpl MyFixture {\n pub fn setup() -> Self {\n // Initialize accounts, deploy program\n }\n\n pub fn action_deposit(&mut self, #[range(0..3)] user: usize, amount: u64) {\n // Actions prefixed with action_ are auto-discovered\n }\n\n pub fn action_withdraw(&mut self, #[range(0..3)] user: usize, amount: u64) {\n // Each action is a state transition the fuzzer can choose\n }\n}\n\n#[invariant_test]\nfn check_invariants(fixture: &mut MyFixture) {\n // Runs after each action — assert properties that must always hold\n assert!(fixture.total_deposited() >= fixture.total_withdrawn());\n}\nCLI Reference\nCommandDescriptionanchor fuzz init <program>Create fuzz harness templateanchor fuzz run <program> <test>Run a fuzz testanchor fuzz list [program]List available fuzz testsanchor fuzz show <program> [crash]View/replay crashesanchor fuzz cmin <program> <test> <corpus>Minimize corpusanchor fuzz tmin <program> <test> <crash>Minimize crash\nFor the full CLI reference and advanced usage, see the Crucible documentation.PreviousMolluskNextFeaturesOn this pageOverviewQuick StartInitialize a harnessRun a fuzz testCommon optionsView and minimize crashesWriting a HarnessCLI ReferenceEdit on GitHub","tokens":748,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257743162,"hash":"16f50a36fb94d1807337a57de89c7e0f367e109c"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/preparing/solana","domain":"docs.pyth.network","title":"Solana | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradeCompleting the Pyth Core upgradeSolanaSolana-specific notes for the Pyth Core upgrade.These notes complement the main upgrade guide for Solana consumers.\nGet a Pyth API KeyRequired for everyone who calls Hermes. Sign up at Pyth Terminal: a free trial is included, paid plans cover ongoing use.Sign up at Pyth TerminalMove your Hermes calls to the new Hermes endpointIf you use @pythnetwork/price-service-client as your Hermes client, switch to @pythnetwork/hermes-client. Point it at the upgraded endpoint and pass your Pyth API key:import { HermesClient } from \"@pythnetwork/hermes-client\";\n\nconst hermes = new HermesClient(\n \"https://pyth.dourolabs.app/hermes\",\n { accessToken: process.env.PYTH_API_KEY },\n);Swap your contract addressOn Solana, swapping the Pyth Core contract address means pointing your program and TS SDK at the upgraded program IDs. The full mapping is on the contract addresses page.\nIf your app reads push feeds directly, the per-feed account addresses also change; see the push feed accounts table for the full mapping.On-chain program (Rust)pyth-solana-receiver-sdk hardcodes the Pyth program addresses. If your program depends on this crate, upgrade to the latest version and enable the pro-compatible feature in your Cargo.toml:pyth-solana-receiver-sdk = { version = \"1.2.0\", features = [\"pro-compatible\"] }TypeScript clientThe TS SDK @pythnetwork/pyth-solana-receiver defaults to the current program IDs. Point it at the upgraded ones instead:import {\n PRO_COMPATIBLE_PUSH_ORACLE_PROGRAM_ID,\n PRO_COMPATIBLE_RECEIVER_PROGRAM_ID,\n PRO_COMPATIBLE_WORMHOLE_PROGRAM_ID,\n PythSolanaReceiver,\n} from \"@pythnetwork/pyth-solana-receiver\";\n\nconst pythSolanaReceiver = new PythSolanaReceiver({\n connection,\n pushOracleProgramId: PRO_COMPATIBLE_PUSH_ORACLE_PROGRAM_ID,\n receiverProgramId: PRO_COMPATIBLE_RECEIVER_PROGRAM_ID,\n treasuryId,\n wallet,\n wormholeProgramId: PRO_COMPATIBLE_WORMHOLE_PROGRAM_ID,\n});Replace any additional reference to the current Core program IDs with the upgraded program IDs in your codebase. See the contract addresses page for the full mapping.\nUpgraded Solana Addresses\nView on the contract addresses page →for EVM chainsPrevious Pagefor SuiNext Page","tokens":556,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257758404,"hash":"db4649c905a5d911c2527478785c44cd7fa9197e"}
{"url":"https://www.openzeppelin.com/continuous-security-program","domain":"openzeppelin.com","title":"Continuous Security Program | OpenZeppelin","text":"AI-powered security at the speed of developmentAn ongoing security program for institutions and enterprises operating onchain. Continuous security coverage delivered by world-class researchers, scaled by OpenZeppelin AI, across architecture, build, security, and support.Talk to a Security ExpertTrusted by leading financial institutions and blockchain protocols10,000+ Total Vulnerabilities Identified$250B+ Digital Assets Secured900+ Security Engagements CompletedFrom security snapshots to continuous coverageOnchain systems evolve continuously, and the surface that needs to be secure runs well beyond the smart contract layer.Point-in-time audits remain valuable, but they cover a slice of the system at a moment in time. Continuous coverage extends across architecture, infrastructure, governance, and operations, and stays in place as the system evolves.Point-in-Time SecurityA snapshot in a continuous worldSecurity validated at a single moment in time Coverage gaps as systems and code evolveIssues found late, expensive to remediateArchitecture, governance, operational risks out of scopeEach engagement starts from scratchContinuous SecurityBuilt for a continuous worldContinuous coverage across the full lifecycleFeedback on every change, every commit, every upgrade Issues caught early, when fixes are cheapArchitecture, governance, operational coverage includedEach engagement compounds on the lastWhat changes when security becomes continuousA program shaped by the priorities of CISOs, heads of digital assets, and risk committees at financial institutions, and the security leads at the protocols redefining digital finance.Risks caught at design stageCatch architectural, governance, and operational issues at the design stage. Continuous coverage closes the gaps point-in-time audits leave open between engagements.Predictable security spendAn annual engagement replaces unpredictable audit cycles, late-stage rework, and emergency engagements. Security planning aligns with the rest of your roadmap.Faster time to marketIssues caught early are cheaper to fix and don't block launches. Audit readiness becomes a continuous state, not a project to scramble for before each release.Audit-ready evidence baseAn ongoing program produces the documented, auditable trail that risk committees, supervisors, and counterparties increasingly require.Regulator and counterparty trustAligned with MiCA, DORA, Basel, GENIUS Act, and SOC 2. The kind of security posture you can defend in regulatory submissions and counterparty due diligence.Security that scales with youWorld-class researchers embedded in your roadmap. Institutional pattern recognition from 900+ engagements applied to your system, on top of your internal team.Security across the full lifecycle, bundled around your needsDelivered by world-class researchers and scaled continuously by OpenZeppelin AI, each engagement is tailored to your system's scale, complexity, and regulatory context.Validate the design before code is writtenArchitecture ReviewThreat ModelingStandards & Regulatory ReviewGovernance DesignCryptographic Design ReviewApplied ResearchReach production with secure foundationsBlockchain Library DevelopmentCustom Platform & Solution DevelopmentReference ImplementationsStandards DevelopmentCatch vulnerabilities across code, infrastructure, and operationsSmart Contract Security AuditBlockchain Infrastructure AuditZero-Knowledge Proof AuditTechnical Risk Assessment (TRA)Penetration TestingOperational Security AssessmentDeployment VerificationKeep production systems secure over timeContinuous Support & MaintenanceDedicated Blockchain Security ArchitectCustom Monitoring SolutionSecurity Training & EnablementContinuous coverage, end to endBundled around the actual shape of your engagement, not pre-defined packages. Services from across the lifecycle combine into the right mix for your protocol or institution and adapt as the system evolves.See the full service breakdown on Security Services“Our partnership with OpenZeppelin is critical. Their role extends far beyond traditional audits; they're embedded in our design process, our reviews, and our monitoring frameworks. Their deep expertise gives us the confidence to push boundaries, knowing that security will scale with us.”— Vlad Bochok, Protocol & Security Engineer, Matter Labs“Bringing regulated funds onchain means security and compliance have to be inseparable, and they have to hold across every environment we build on. OpenZeppelin has been a continuous partner from architecture through deployment, across both our Ethereum and Solana work, and this consistency and rigor allows us to advance WisdomTree's tokenization roadmap confidently, at scale.”— Jason Guthrie, Head of Product, WisdomTree Digital AssetsRead Customer StoriesHeld to the standards your institution already answers toOpenZeppelin meets the highest security and compliance standards while actively shaping industry regulations and engaging with global regulators and policymakers.Security & ComplianceSOC 2 Type IICCSSGDPRCCPAIndustry Standards ContributionsISOBlockchain Security Standards CouncilEnterprise Ethereum AllianceLinux Foundation Decentralized TrustRegulatory EngagementU.S. TreasurySECUK FCAFrench ACPR/AMFHong Kong SFCHong Kong Monetary AuthorityThe security standard for onchain financeTalk to a Security Expert","tokens":1341,"squid":"ink-security_audits","role":"Sentinel","at":1791257770039,"hash":"0213573ed3b0feff51f47d9376f00c5501dc955d"}
{"url":"https://docs.arbitrum.io/arbitrum-bridge/embedded-bridge-widget","domain":"docs.arbitrum.io","title":"Arbitrum embedded bridge widget | Arbitrum Docs","text":"✏️Request an updateThe embedded bridge helps applications bring users and assets into markets built on the Arbitrum Platform. To see what the end-user bridge flow looks like outside the widget, see the Arbitrum bridge quickstart.\nYou can embed the widget onto your webpage using a simple iframe and configure colors and window sizing by modifying the iframe code. Transactions are routed through Li.fi's API, which then requests quotes from various third-party bridging providers, such as Layer Zero, Across, or Relay. The fastest and cheapest paths are highlighted to users based on the quotes. Users can pick their preferred bridging option.\nBridging USDC through the widgetThe widget routes USDC alongside other tokens. For background on Arbitrum One's two USDC forms (native vs USDC.e), see USDC on Arbitrum One.\nFunctionalities​\nCore functionalities​\n\nDeposits from Base, Ethereum Mainnet, and other Arbitrum chains\nWithdrawals to Arbitrum One or other Arbitrum chains\nConfiguration of supported chains for both deposits and withdrawals\nBatch transactions\nLong-tail assets on supported bridges and DEXes if liquidity is available\nFiat on-ramps via Moonpay\n\nVisual features​\n\nNormal mode, widget mode\nLayout options\nVisual customization\n\nArbitrum bridge playground​\nYou can experiment with Arbitrum bridge configurations in real-time using the bridge playground. This interactive tool allows you to:\n\nTest different modes: Switch between normal and widget modes to see how they differ\nConfigure feature flags: Toggle network selection and batch transfers to understand their impact\nExplore layout options: Try vertical and horizontal layouts for the widget interface\nGenerate embed code: Get ready-to-use iframe code for your integration\nSee live preview: Watch changes reflect immediately in the embedded bridge interface\n\nIntegration details​\nThe widget uses an iframe under the hood, enabling easy integration for any frontend. Visit the bridge playground to generate iframe code with your configured features.\nSupport​\nBefore integrating, review the current chain offerings to ensure that your desired routes are shown. The embedded bridge uses Li.fi's token lists to populate supported routes and quotes. If you plan to use the on-ramp functionalities, notify partnerships@offchainlabs.com to facilitate support.\nContact partnerships@offchainlabs.com to discuss specific chain and token support.\nFor transaction support, users should create a support ticket with the Arbitrum Foundation and select the \"Widget\" option in the dropdown. For self-service troubleshooting of common bridging issues, see Arbitrum bridge: Troubleshooting.\nChain and bridge support​\nThe embedded bridge currently supports Arbitrum One, Base, Ethereum Mainnet, Ape Chain, and Superposition.\nFrequently asked questions​\n1. If I'm a dApp on Arbitrum One (or an Arbitrum chain), what do I need to do to adopt?​\nYou can adopt the bridge functionality permissionlessly if your chain is already supported. If your chain is already supported, visit the playground and accept the developer terms of service to generate code for the embedded bridge.\nIf you are interested in on-ramp support, please contact partnerships@offchainlabs.com.\n2. If I'm an Arbitrum chain and I want support, how do I adopt?​\nYou'll need an integration with Li.fi and a minimum number of bridges to enable a good experience. Contact partnerships@offchainlabs.com to discuss adding support for your chain. To also be listed in the main bridge UI at bridge.arbitrum.io, see How to add your Arbitrum chain to Arbitrum's bridge.\n3. Are there any fees associated with the embedded bridge?​\nThe embedded bridge routes orders through Li.fi's route aggregator, which charges a 16-basis-point fee on all transactions.\nSee also​\n\nArbitrum bridge quickstart\nUSDC on Arbitrum One\nArbitrum bridge: Troubleshooting\nHow to add your Arbitrum chain to Arbitrum's bridge\nFunctionalitiesCore functionalitiesVisual featuresArbitrum bridge playgroundIntegration detailsSupportChain and bridge supportFrequently asked questionsSee also","tokens":1016,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257771325,"hash":"bdf16b45ad854918da22b77a24f603626d5e07d5"}
{"url":"https://docs.arbitrum.io/intro/glossary","domain":"docs.arbitrum.io","title":"Arbitrum glossary | Arbitrum Docs","text":"✏️Request an updateActivation​\nThe step that prepares a deployed Stylus contract to be called. Activation registers the program with ArbOS, validates the WASM bytecode, and primes the per-node compiled-artifact cache so subsequent calls can execute the program at native speed. Activation costs gas proportional to program size, and re-activation is required after the cache entry expires (365 days by default) or after an ArbOS upgrade that changes the WASM module root.\nActive Validator​\nA bonded Validator that makes disputable assertions to advance the state of an Arbitrum chain or to challenge the validity of others' assertions. (Not to be confused with the Sequencer.)\nAddress Alias​\nAn address deterministically generated from a parent chain contract address used on child chain to safely identify the source of a parent-to-child chain message.\nAdjustment window​\nWindow during which the gas pricing algorithm measures the transaction backlog. For example, there can be a gas target of 10Mgas/s over ten minutes. That means the price will only increase if the average demand is over 10Mgas/s for that ten-minute window.\nAlt-DA​\nAn \"alternative data-availability\" mode for an Arbitrum chain in which transaction data is posted to a third-party DA layer (for example, Avail or Celestia) rather than to Ethereum calldata/blobs (Rollup mode) or to a DAC (AnyTrust mode). Alt-DA exposes a different trust profile than either built-in mode and is configured at chain deployment.\nDecentralized application​\nA decentralized application typically consists of smart contracts as well as a user-interface for interacting with them.\nNote: In our documentation, \"apps\" and \"decentralized applications\" are used interchangeably.\nArb Token Bridge​\nA series of contracts on an Arbitrum chain and its underlying chain that facilitate trustless movement of ERC-20 tokens between the two layers.\nArbified Token List​\nA token list that conforms to Uniswap's token list specification; Arbified lists are generated by inputting an externally maintained list (that is, CoinMarketCap's list) and outputting a list that includes all of the instances of token contracts on the Arbitrum chain bridged via the canonical Arbitrum Token Bridge from tokens on the input list. (See the arbitrum-token-lists source code.)\nArbitrum​\nArbitrum is the finance-native blockchain platform providing infrastructure for applications, tokenization, and dedicated blockchains. The platform includes Arbitrum One, Arbitrum Nova, Arbitrum chains, Nitro, Stylus, and supporting protocols.\nArbitrum AnyTrust Chain​\nAn Arbitrum chain that implements the Arbitrum AnyTrust Protocol.\nArbitrum AnyTrust Protocol​\nAn Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). This protocol reduces transaction fees by introducing an additional trust assumption for data availability in lieu of Ethereum's Trustless data availability mechanism. Arbitrum Nova is an example of an AnyTrust chain; Arbitrum One is an alternative chain that implements the purely trustless (and more L1-gas intensive) Arbitrum Rollup Protocol.\nArbitrum Bridge UI​\nWeb application built and maintained by Offchain Labs for user interactions with the Arbitrum Token Bridge. Visit the Arbitrum Bridge UI.\nArbitrum chain​\nA blockchain that runs on the Arbitrum platform. Arbitrum chains are EVM compatible, and use an underlying EVM chain (for example, Ethereum) for settlement and for succinct fraud proofs (as needed). Arbitrum chains come in two forms: Arbitrum Rollup chains and Arbitrum AnyTrust chains.\nArbitrum Chains​\nAn Arbitrum chain is any chain that is built using the Arbitrum stack. Anyone can deploy an Arbitrum chain permissionlessly.\nArbitrum Classic​\nOld Arbitrum stack that used custom virtual machine (\"AVM\"); no public Arbitrum chain uses the classic stack as of 8/31/2022 (they instead use Arbitrum Nitro.)\nArbitrum DAO​\nThe onchain governance body that owns and operates Arbitrum One and Arbitrum Nova. Holders of the ARB token vote on protocol upgrades, treasury actions, and Arbitrum Expansion Program revenue distributions.\nArbitrum Expansion Program (AEP)​\nThe licensing framework under which third parties can deploy new Arbitrum chains outside Arbitrum One and Arbitrum Nova. In exchange for permissionless deployment, the chain remits 10% of net revenue—8% to the Arbitrum DAO and 2% to ecosystem programs.\nArbitrum Full Node​\nA party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-staking parent Ethereum node.\nArbitrum Nitro​\nCurrent Arbitrum tech stack; runs a fork of Geth and uses WebAssembly as its underlying VM for fraud proofs.\nArbitrum Nova​\nThe first Arbitrum AnyTrust Chain running on Ethereum mainnet. Introduces cheaper transactions; great for gaming and social use-cases. Implements the Arbitrum AnyTrust Protocol, not the Arbitrum Rollup Protocol protocol. Governed by the Arbitrum DAO.\nArbitrum One​\nArbitrum One is a public settlement layer built on Ethereum for applications that require strong security guarantees, deep liquidity, and predictable execution.\nArbitrum Rollup Chain​\nAn Arbitrum chain that implements the Arbitrum Rollup Protocol.\nArbitrum Rollup Protocol​\nA trustless, permissionless Arbitrum protocol that uses its underlying base layer for data availability and inherits its security. This protocol is implemented by our Arbitrum One chain.\nArbOS​\nArbitrum's \"operating system\" that trustlessly handles system-level operations; includes the ability to emulate the EVM.\nArchive Node​\nAn Arbitrum full node that retains every historical chain state instead of discarding old ones, so it can serve eth_call, balance, and trace queries at any past block. An archive node is a storage variant of a full node rather than a separate protocol role: it runs the same nitro binary with --execution.caching.archive enabled. The trade-off is disk — an Arbitrum One archive database is measured in terabytes.\nAssertion​\nA bonded claim made by a validator about an Arbitrum chain's execution state, posted to the Rollup contract. An assertion may propose a new state or may be a step in a challenge. Each assertion consumes messages from the Sequencer inbox. Gaining the right to post assertions requires a large, one-time bond, which the poster loses if a competing assertion is confirmed.\nAn assertion moves through several states:\n\nProposed: a validator submits the assertion.\nChallenged: another validator disputes the assertion, which starts an interactive fraud proof.\nConfirmed: nobody challenged the assertion within the challenge period, which is 6.4 days on Arbitrum One. A BoLD challenge adds at most one more challenge period.\n\nAuction Contract​\nA smart contract that handles the state, accounting of funds for bids, and various operations of the Timeboost auction. The contract is deployed on the target chain for which Timeboost is enabled.\nAutonomous Auctioneer​\nA protocol that receives bids from Timeboost participants, processes and validates bids, and then posts the top valid bid (or top two valid bids in the case of a tie) to the Auction Contract to resolve the ongoing Timeboost auction. The autonomous auctioneer, for a given chain, is provisioned and deployed by an entity designated by the chain's owner.\nBatch​\nA group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Sequencer Inbox by the Sequencer.\nBatch Poster​\nThe batch poster is an Externally Owned Account (EOA) controlled by the Sequencer. It is responsible for submitting the compressed transaction batches to the Sequencer Inbox contract on the parent chain.\nBisection​\nA move in the BoLD Challenge Protocol in which an edge is split in half, producing two child edges with shorter histories. Repeated bisection narrows a disagreement down to a single execution step, which can then be resolved with a One-Step Proof. BoLD's bisection generalises the older Arbitrum Classic dissection move.\nBlob​\nA transaction data format introduced on Ethereum by EIP-4844 and enabled for Arbitrum chains in ArbOS 20 \"Atlas\". Blob data lives on the Ethereum beacon chain and is not readable by the EVM, unlike calldata. Posting batches as blobs is cheaper than calldata, but it means a node needs a beacon chain RPC endpoint — with historical blob data — to sync.\nBlockchain​\nA distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols.\nBLS Signature​\nA cryptographic scheme that allows multiple signatures to be aggregated and compacted into one efficiently verifiable, constant-sized signature. Used in the Arbitrum AnyTrust Protocol for the Data Availability Committee (DAC)'s signatures.\nBoLD​\nShort for \"Bounded Liquidity Delay\"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more).\nBonder​\nA Validator who deposits a bond (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular assertion in an Arbitrum Chain. A validator who bonds on a false assertion can expect to lose their bond. An honest bonder can recover their bond once the assertion they are bonded on has been confirmed.\nAlso known as: staker\nBonding​\nLocking WETH in the Rollup contract to gain the right to post assertions. A party joins the validator set by posting one large assertion bond. Later assertions from the same party need no further bond, because the protocol treats each bonder as bonded to their latest assertion. Opening a sub-challenge requires a smaller challenge bond. You lose your bonded funds if a competing assertion is confirmed. You can withdraw them once the assertion you bonded on is confirmed.\nBridge​\nA set of smart contracts for sending Cross-chain messages between blockchains. Every Arbitrum chain includes a bridge to/from its Parent chain.\nChain bindings​\nSoftware that calls the onchain contracts, and sends transactions to them, so a validator can take part in the challenge protocol. Arbitrum uses go-ethereum's abigen utility to generate Go bindings for these contracts, plus a few developer-friendly wrappers.\nChain Owner​\nAn entity (i.e., a smart contract) with affordance to carry out critical upgrades to an Arbitrum chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding and removing other chain owners.\nChain state​\nA particular point in the history of an Arbitrum chain. A chain's state is determined by applying Arbitrum state-transition function to sequence of transactions (i.e., the chain's history).\nChallenge​\nWhen two bonders disagree about the correct verdict on an assertion, those bonders can be put in a challenge. The challenge is refereed by the contracts on the underlying chain. Eventually one bonder wins the challenge. The protocol guarantees that an honest party will always win a challenge; the loser forfeits their bond.\nChallenge bond​\nThe per-level bond required to open or move within a sub-challenge under BoLD. Each level of the dispute tree has its own configured bond amount, set at chain deployment. Challenge bonds are distinct from the larger assertion bond that backs the proposed Assertion itself.\nChallenge manager client​\nSoftware that manages the lifecycle of every challenge an active validator takes part in. It tracks many challenges at once and acts on, confirms, or rejects each edge as the challenge protocol allows.\nChallenge Period​\nThe window during which anyone can challenge an assertion, after which the assertion can be confirmed. On Arbitrum One it is 6.4 days. The Arbitrum DAO can configure this value. A BoLD challenge adds at most one more challenge period before an assertion confirms.\nChallenge protocol​\nThe rules for submitting, disputing, and confirming assertions, with the parent chain as the final arbiter. The protocol guarantees that only valid assertions are confirmed, provided at least one honest active validator takes part. Ethereum's VM verifies one-step proofs of deterministic computation, which decide the winner of a challenge once the challenge period has elapsed.\nChallengeManager​\nThe BoLD smart contract on the parent chain that starts challenges on assertions and lets anyone join a challenge without permission. It holds the entry points for making challenge moves, opening edges, creating sub-challenges, and confirming challenges. It is written in Solidity and is new in BoLD.\nChild chain​\nAn Arbitrum Chain that settles to a Parent chain. For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.\nClient​\nA program running on a user's machine, often in the user's browser, that interacts with contracts on an Arbitrum chain and provides a user interface.\nCommitment​\nIn the context of Arbitrum, commitments represents a part of a chain's history. Commitments are used during the fraud proof dispute resolution process, where validators create a Merkle commitment to the history between two assertions. This allows them to efficiently narrow down disagreements about the chain state by using Merkle proofs to specific blocks or states within that range(1).\nConfirmation​\nThe decision by an Arbitrum chain to finalize an assertion as part of the chain's history. Once an assertion is confirmed its Child-to-parent chain Messages (e.g., withdrawals) can be executed.\nCross-chain message​\nAn action taken on some chain A which asynchronously initiates an additional action on chain B.\nCustom Arb-Token​\nAny child chain token contract registered to the Arbitrum Token Bridge that isn't a standard arb-token (i.e., a token that uses any gateway other than the StandardERC20 gateway ).\nCustom gas token​\nA non-ETH ERC-20 token chosen at Arbitrum chain deployment time to be used for paying transaction fees on that chain. Deposits work by escrowing the ERC-20 in the chain's bridge on the parent chain and crediting the equivalent amount as the native asset on the child chain, where it replaces ETH everywhere ETH would otherwise be charged for gas.\nCustom gateway​\nAny Token Gateway that isn't the StandardERC20 gateway.\nData Availability Certificate​\nSigned promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.\nData Availability Committee (DAC)​\nA permissioned set of parties responsible for enforcing data availability on a chain using the Arbitrum AnyTrust Protocol.\nSee Introducing AnyTrust Chains: Cheaper, Faster L2 Chains with Minimal Trust Assumptions to learn more.\nData Availability Server (DAS)​\nThe server software each member of a Data Availability Committee (DAC) runs to store batch data and serve it on demand. On an AnyTrust chain the sequencer sends batch data to the committee's DAS instances, which sign and return a Data Availability Certificate. Nitro ships anytrustserver for running a DAS.\nDatabase Snapshot​\nAn archive of a Nitro database published so a new node can initialize without syncing from genesis. You supply one through --init.url, or let Nitro fetch the latest with --init.latest. A snapshot only works on a node whose state scheme matches the snapshot's. On Arbitrum One you must start from a snapshot, because Nitro cannot process transactions from Arbitrum Classic.\nDefensive Validator​\nA Validator that watches an Arbitrum chain and takes action (i.e., bonds and challenges) only when and if an invalid Assertion occurs.\nDelay attack​\nAn attack in which one or more malicious parties follow the challenge protocol to delay confirmation of results on the parent chain. The protocol used before BoLD allowed this, because an honest party had to play a separate 1-vs-1 challenge against each adversary. BoLD sets a constant upper bound on confirmation time: one honest validator defends a single assertion against any number of malicious claims. Preventing delay attacks is what makes permissionless validation safe.\nDelayed Inbox​\nA contract that holds Parent chain initiated messages to be eventually included in the Sequencer Inbox. Inclusion of messages doesn't depend on the Sequencer.\nDeterministic proving​\nIf challenged, state transitions are replayable and verified onchain.\nTo achieve this, Arbitrum compiles the State Transition Function (STF) into different formats:\n\nExecution mode: Uses Go's native compiler for high-performance execution on validator nodes.\n\nProving mode: Compiles to WebAssembly (WASM), which transforms into WebAssembly for Arbitrum Virtual Machine (WAVM) for fraud-proof verification.\n\nDev-Tools Dashboard​\nDeprecated web application built by Offchain Labs for developers and users to debug Arbitrum transactions; i.e., executing or checking the status of Cross-chain messages. It has been replaced by the Retryable Tickets tool and the bridge transaction history.\nDissection​\nA step in the Challenge protocol in which two challenging parties interactively narrow down their disagreement until they reach a One Step Proof.\nEdge​\nA primitive in the BoLD Challenge Protocol. An edge is a claim about a portion of an Arbitrum chain's history, identified by a starting and ending history commitment. Validators bisect edges to narrow disagreement down to a single execution step.\nEIP-1559​\nAn Ethereum Improvement Proposal, live since Ethereum's London upgrade in 2021, that splits the gas price into two parts: a base fee per gas that the protocol sets and adjusts with demand, and a priority fee per gas that you set as a tip to bid for earlier inclusion. A transaction declares both limits as max_fee_per_gas and max_priority_fee_per_gas. Arbitrum chains use the same fields, and under PGA the priority fee decides the order in which the Sequencer includes transactions.\nEIP-4844​\nAn Ethereum Improvement Proposal, also called Proto-Danksharding, live since Ethereum's Dencun upgrade in March 2024. It adds blobs, a data format priced in a fee market of its own: each block measures blob usage against a target, then moves the blob base fee along an exponential curve, up when usage runs above the target and down when it runs below. Arbitrum uses EIP-4844 in two separate ways. Batches post as blobs from ArbOS 20 \"Atlas\" onward, and the Fast Feed borrows the pricing curve, rather than blobs themselves, to price subscription tickets. Read the proposal at EIP-4844.\nEthereum Wallet​\nA software application used for transacting with the Ethereum Blockchain.\nExecution claim​\nA cryptographic commitment to the computed state.\nExpress Lane​\nA component of Timeboost, the express lane is a special endpoint on the Sequencer that immediately sequences incoming, valid transactions signed by the current express lane controller.\nExpress Lane Controller​\nAn address, defined in the Auction Contract, that is granted the privilege to use the Express Lane. These privileges are granted after verifying that the incoming transactions were properly signed by the express lane controller, among other checks.\nExternally Owned Accounts​\nAn externally owned account (EOA) is the account (public/private key pairs) that has a physical address location. Commonly referred to as a wallet, however, we distinguish an EOA from the user client software wallet.\nFast Exit / Liquidity Exit​\nA means by which a user can bypass an Arbitrum chain's Challenge Period when withdrawing fungible assets (or more generally, executing some \"fungible\" child chain-to-parent chain operation); for trustless fast exits, a liquidity provider facilitates an atomic swap of the asset on a child chain directly to a parent chain.\nFast Feed​\nA paid, authenticated data stream on Arbitrum One that publishes individual transactions, their relative ordering, and related metadata after the Sequencer orders and executes them, and before the block that contains them is published on the Sequencer Feed. Subscribers buy timed access through the Tickets contract, also called the Fast Feed Payment Contract.\nFast withdrawals​\nA protocol-level withdrawal path on an Arbitrum chain in which a configured validator committee attests to the withdrawn amount, allowing child-to-parent exits to settle in minutes rather than waiting out the full challenge period. Distinct from a fast-exit liquidity exit, which is a third-party liquidity provider rather than a protocol primitive.\nFeed Relay​\nA standalone relay binary that subscribes to a sequencer feed and re-broadcasts it to downstream nodes. The feed relay is stateless fan-out: it needs no parent chain connection, no wallet, no bond, and no database. Running one relay per data center reduces ingress fees and improves stability when you run several nodes. It ships inside the Nitro Docker image.\nFirst Come First Serve (FCFS)​\nA type of Transaction Ordering Policy used by the sequencer in Arbitrum chains whereby incoming transactions are sequenced into a block in the order that the transactions arrived.\nForce-Inclusion​\nCensorship resistant path for including a message into an Arbitrum chain via the Delayed Inbox on its Parent chain; bypasses any Sequencer involvement.\nForwarder​\nIn Arbitrum, a forwarder is a component that forwards user transactions to the Sequencer. Full nodes use the forwarder to send transactions they receive via RPC to the sequencer for ordering and execution.\nFraud proof​\nA proof that an invalid state transition took place. Challenge participants generate fraud proofs and submit them to the parent chain, where a smart contract verifies them. An Arbitrum chain that settles to Ethereum therefore makes Ethereum the final arbiter of any disagreement over an assertion. No party can falsify a fraud proof, because executing a WASM instruction on a given pre-state has exactly one correct result. Challenges execute a variant of WASM called WAVM.\nGas Price Floor​\nProtocol-enforced minimum gas price on an Arbitrum chain. These values can be found on the chain info page.\nGas target​\nThe target consumption rate for an Arbitrum chain. Arbitrum One and Arbitrum Nova. When gas usage exceeds this limit, fees rise. Read more in the gas and fees article.\nGateway Router​\nContracts in the Arbitrum Token Bridge responsible for mapping tokens to their appropriate Token Gateway.\nGeneric-Custom Gateway​\nA particular Custom gateway via which a parent chain token contract can be registered to a token contract deployed to a child chain. A useful alternative to the StandardERC20 gateway for projects that wish to control the address of their child chain token contract, maintain the child chain token contract upgradability, and for various other use-cases.\nGeth​\nAn execution-layer client that defines the Ethereum state transition function and handles network-layer logic like transaction memory pooling. Arbitrum Nitro utilizes a fork of Geth to implement Arbitrum's state transition function.\nHard finality​\nThe state a transaction reaches once its batch has been posted to the parent chain by the Batch Poster and that posting is itself final on the parent chain. Hard finality inherits the security of the parent chain and cannot be reverted without a parent-chain reorg. Contrast with soft confirmation, which is immediate but trust-based on the honesty of the Sequencer.\nHashDB​\nNitro's default state scheme, which stores the state trie keyed by node hash. HashDB supports block validation, so a node running the block validator must use it. Unlike PathDB, HashDB prunes manually and offline through --init.prune: the node stops serving RPC requests until the prune finishes.\nHistory commitment​\nA Merkle-tree root committing to a sequence of execution states—either block hashes or instruction-level state hashes, depending on the level of the dispute. Each BoLD edge carries a start and end history commitment to represent a claim over a range of chain history.\nHonest validator​\nA validator that knows the correct state of the child chain and acts on it. It creates assertions, confirms valid ones, and challenges invalid ones. It runs an Arbitrum full node in MakeNodes, Defensive, StakeLatest, or ResolveNodes mode. Every chain needs at least one proposer in MakeNodes mode to advance the chain.\nHost I/O​\nThe set of low-level imports that a Stylus WASM program uses to access chain state and runtime services—the equivalent of EVM opcodes for Solidity contracts. Host I/O calls cover storage access, account info, environment data, math primitives, and re-entrancy controls. Each call has a fixed ink cost.\nInk​\nThe equivalent of gas in the Stylus vm. Ink is introduced for finer granularity than gas offers since Stylus's operations are considerably cheaper than their EVM analogs.\nKeyset​\nThe onchain configuration object that defines a Data Availability Committee (DAC)—the BLS public keys of every committee member and the signature threshold required to produce a valid Data Availability Certificate. A new keyset is published whenever committee membership or the threshold changes.\nL1​\nSee Layer 1\nL2​\nSee Layer 2.\nL2 Block​\nData structure that represents a group of L2 transactions (analogous to L1 blocks).\nL2 to L1 Message​\nA message initiated from within an Arbitrum chain to be eventually executed on Layer 1 (parent chain) (e.g., token or Ether withdrawals). On Rollup chains like Arbitrum One, the Challenge Period must pass before a child-to-parent chain message is executed.\nLayer 1 (L1)​\nL1, or Layer 1, refers to the underlying blockchain responsible for maintaining the integrity of the distributed ledger and executing smart contracts. It contains both Ethereum's execution layer and consensus layer.\nIn the context of Arbitrum One and Nova, L1 is the main Ethereum blockchain (Mainnet), and Arbitrum is a Layer 2 platform built on top of this base (Ethereum) layer.\nHowever, any EVM-compatible blockchain can be an L1 to an Arbitrum chain.\nLayer 2 (L2)​\nAn L2, or Layer 2, is a trustless scaling solution built on top of Ethereum's Layer 1 (L1) base protocol.\nArbitrum is a Layer 2 platform that increases throughput and reduces the cost of transactions on Ethereum's (L1) without introducing additional trust assumptions. It does that by executing some computation offchain and batch-posting transactions on the underlying Layer 1 chain (Ethereum for Arbitrum One/Nova).\nLayer 3 (L3)​\nAn Arbitrum chain whose core contract reside on an Arbitrum Layer 2 (L2) chain.\nLayer Leap​\nA protocol that allows users to bridge ETH and ERC-20 tokens from Ethereum directly to an Arbitrum chain in a single transaction, without first depositing onto an intermediate parent chain.\nMultiVM​\nMultiVM refers to Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries. Learn more about Stylus and language support.\nNative Fee Token​\nAn ERC-20 token used as the native currency for gas fees on an Arbitrum chain (i.e., as opposed to using Ether). Arbitrum chains introduced the option for chains to use native fee tokens.\nNative mint/burn gas token​\nA custom gas token variant whose supply on the Arbitrum chain is controlled by mint and burn calls to the ArbNativeTokenManager precompile (address 0x73) rather than by bridging from the parent chain. Only accounts in the chain's nativeTokenOwners set—managed through the ArbOwner precompile—may mint or burn. Suited to closed-economy chains that need full control over gas-token issuance.\nOffchain Labs​\nThe initial builders Arbitrum; current contributors to the Arbitrum ecosystem and service providers to the Arbitrum DAO. Offchain also runs and maintains the Sequencers for Arbitrum One and Arbitrum Nova.\nOne Step Proof​\nFinal step in a challenge; a single operation of the Arbitrum VM (WASM) is executed on the underlying chain, and the validity of its state transition is verified.\nOneStepProver​\nThe set of parent chain contracts that implement a miniature WASM VM, often shortened to OSP. The VM executes a one-step proof of the child chain state transition function, which settles a challenge. It is written in Solidity. BoLD needs no changes to these contracts.\nOracle​\nOracles are third-party services that provide smart contracts with external information. They act as a bridge between blockchains and the outside world, which expands their functionality by enabling smart contracts to access data beyond their native networks.\nOutbox​\nA parent chain contract responsible for tracking child-to-parent chain messages, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle root of all outgoing messages.\nParent chain​\nEVM compatible chain that acts as the settlement layer for one or more Arbitrum Chains (aka Child chain ). For example, Ethereum is the parent chain of both Arbitrum One and Arbitrum Nova. Parent chain is synonymous with \"underlying chain.\"\nPathDB​\nA state scheme that stores Nitro's state trie by path, enabled with --execution.caching.state-scheme=path and available from Nitro v3.9.x. PathDB prunes automatically while the node runs, so disk use stays within the window set by --execution.caching.state-history and the node keeps serving RPC. It cuts archive node disk use substantially, but it cannot validate blocks.\nPebble​\nThe key-value store Nitro uses for its on-disk database. Pebble allocates its block cache and memtables through CGO calls, so that memory sits outside Go's memory tracking and outside what GOMEMLIMIT governs. The database-cache parameter sets the block cache size directly and also determines memtable size.\nPermissionless validation​\nThe ability for anyone to post assertions to the Rollup contract and challenge the assertions of others. Before BoLD, the Rollup contract held an allowlist of validators. BoLD removes that allowlist, because it bounds how long a delay attack can postpone confirmation.\nPortal​\nA web application maintained by Offchain Labs showcasing the Arbitrum ecosystem; visit it here.\nPrechecker Node​\nAn Arbitrum full node configured to pre-validate transactions before forwarding eth_sendRawTransaction to the Sequencer, insulating it from transactions that would fail.\nAt a configurable strictness level, a prechecker verifies the transaction type, signature, intrinsic gas (including L1 calldata gas), fee cap, nonce, sender balance, and any eth_sendRawTransactionConditional storage conditions. When compliance filtering is enabled, it also rejects transactions that touch restricted addresses.\nPrecompile​\nA precompile is a predefined smart contract with a special address that provides specific functionality executed natively by the Arbitrum client, rather than at the EVM bytecode level. Precompiles are used to introduce functions that would be computationally expensive if run in EVM bytecode, or to facilitate interactions between the parent and child chains. Arbitrum supports all Ethereum precompiles and also provides additional precompiles specific to Arbitrum chains, which can be called from smart contracts like regular Solidity functions(1).\nPredecessor Assertion​\nThe last confirmed valid state of the chain.\nPriority Fee​\nThe per-gas tip you add on top of the base fee to bid for earlier inclusion, set in the max_priority_fee_per_gas field of an EIP-1559 transaction. The chain computes the effective value as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas). Under PGA, the Sequencer orders transactions by this value, highest first.\nPriority Gas Auction (PGA)​\nA transaction ordering policy in which you bid for ordering by attaching a priority fee to each transaction. The Sequencer sorts transactions by that fee, highest first, and evaluates the order in short rounds that run several times per block. An anti-starvation boost raises the queue position of transactions still waiting at the end of a round, so a transaction that pays no priority fee is still included within a small number of blocks. PGA replaces Timeboost on Arbitrum One.\npropAMM​\nA proprietary automated market maker is an onchain pool that a single market maker operates. That market maker is the only party permitted to supply liquidity, and it sets the quote from its own pricing model, which draws on multiple sources, rather than from a passive reserve curve.\nA propAMM differs from a constant-product AMM, which holds no view on the external price. A constant-product quote moves only when someone trades against it, so arbitrageurs are what pull it back toward the market. A propAMM instead pushes price updates onchain, or derives the price at execution time. propAMMs need cheap, frequent, priority-ordered inclusion to keep those quotes current, so they depend on an ordering policy that sells priority, such as PGA.\nProposer​\nA Validator configured to actively submit new Assertions to the parent chain under BoLD. Proposers post the largest bonds in the staking hierarchy to deter delay attacks. Contrast with a Watchtower Validator, which only observes, and a Defensive Validator, which acts only to counter an invalid claim.\nraas​\nRaaS (Rollup as a Service) is a platform that provides the necessary infrastructure and tools to deploy and operate blockchain Rollups, eliminating the need for teams to build the underlying technical infrastructure themselves. It typically includes pre-built Rollup software, node hosting, data availability solutions, and monitoring tools, allowing developers to focus on their application logic rather than the complex technical implementation of Rollup technology.\nRBlock​\nRefer to Assertion\nReorg​\nA situation in which transactions on a chain that were at some point considered accepted then get rejected. In the context of an Arbitrum chain, once transactions are posted in the chain's Sequencer Inbox, the only way the chain can experience a reorg is if its Underlying Chain itself reorgs. Of note, Fraud proofs do not cause reorgs.\nRetryable Autoredeem​\nThe \"automatic\" (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.\nRetryable Redeem​\nThe execution of a Retryable Ticket on a child chain; can be automatic (see Retryable Autoredeem) or manual via a user-initiated child chain transaction.\nRetryable Ticket​\nA parent-to-child cross-chain message initiated by a parent chain transaction sent to an Arbitrum chain for execution (e.g., a token deposit).\nReverse Token Gateway​\nA Token Gateway in which the Child chain gateway contract escrows and releases tokens, which the Parent chain Gateway contract mints and burns tokens. This in the inverse to how \"typical\" gateways work.\nRival​\nIn the BoLD Challenge Protocol, two edges are rivals when they share a starting point but make incompatible claims about the same range of chain history. Rivaling an edge stops its unrivaled timer and unlocks bisection moves to resolve the disagreement.\nRoll forward​\nIn the Fast Feed Tickets contract, the step that advances stored round state (round number, ticket price, tickets sold, and queued parameter changes) to the current round. The contract rolls state forward lazily: the first state-changing call in a new round performs it, and view functions compute the rolled-forward values on the fly without writing them.\nRollup contract​\nThe smart contract on the parent chain where validators post assertions about an Arbitrum chain's state and bond on them. It is implemented as RollupCore.sol. Under BoLD it holds a reference to a ChallengeManager contract. The wider set of Rollup contracts also serves as the data availability layer for the chain and confirms each assertion once its challenge period has passed.\nRollup Event Inbox​\nA parent chain contract (one per Arbitrum chain) that serves as an authorized delayed inbox used exclusively by the Rollup contract to communicate chain-level protocol events to the child chain. It is separate from the regular Inbox, Bridge, and SequencerInbox contracts that handle user transactions.\nIts main role is to seed the child chain with its bootstrap configuration. During initialization, the Rollup admin contract calls rollupInitialized(chainId, chainConfig, l1BaseFeeEstimate) exactly once; this enqueues a delayed message of type INITIALIZATION_MSG_TYPE carrying the chain's chainId, full chain config JSON, and an initial parent-chain base-fee estimate. That delayed message is then read by the child chain as its very first L2 message, which initializes the L2 state.\nTwo implementations share the IRollupEventInbox interface and AbsRollupEventInbox base: RollupEventInbox for ETH-based chains, and ERC20RollupEventInbox for chains using a custom (ERC-20) gas token. The contract is deployed by BridgeCreator and registered as an allowed delayed inbox on the Bridge.\nIn some support contexts the contract is informally referred to as \"rollupEventBox\"; the canonical name in the codebase is RollupEventInbox.\nRollup Improvement Proposal​\nA Rollup Improvement Proposal (RIP) is a process for proposing, discussing, and recording changes or additions to Ethereum’s rollup ecosystem.\nSearcher​\nA participant who runs automated strategies to find and capture profitable onchain opportunities, such as arbitrage between a centralized and a decentralized exchange, liquidations, and back-running. Under PGA, searchers compete for ordering by attaching a priority fee to each transaction.\nSequencer​\nAn entity (currently a single-party on Arbitrum One) given rights to order transactions in the Sequencer Inbox over a fixed window of time, who can thus give clients sub-blocktime Soft Confirmations. (Not to be confused with a Validator).\nSequencer Feed​\nOffchain data feed published by the Sequencer which clients can subscribe to for Soft Confirmations of transactions before they are posted in batches.\nSequencer Inbox​\nContract that holds a sequence of messages sent by clients to an Arbitrum Chain; a message can be put into the Sequencer Inbox directly by the Sequencer or indirectly through the Delayed Inbox.\nShared Sequencing​\nA protocol design space in which multiple rollups use the same entity as their Sequencer; potential benefits include enhanced interoperability and credible neutrality.\nSmart Contract​\nA computer program whose operations are defined and executed within a blockchain consensus protocol.\nSoft Confirmation​\nA semi-trusted promise from the Sequencer to post a user's transaction in the near future; soft-confirmations happen prior to posting on the Parent chain, and thus can be given near-instantaneously (i.e., faster than the parent chain's block times)\nStandard Arb-Token​\nAn token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC-20 functionality in addition to deposit/withdrawal affordances.\nStandardERC20 gateway​\nToken Gateway via which any underlying chain's ERC-20 token can permissionlessly bridge; the StandardERC20 gateway contracts deploy a Standard Arb-Token on the Child chain for each bridged token.\nState manager backend​\nSoftware that retrieves child chain states and produces commitments to WAVM execution histories. The validator client reads from a state manager backend to make its moves in a challenge.\nState Pruning​\nRemoving historical chain state a node no longer needs, to keep its database from growing without bound. On HashDB you prune manually with --init.prune and the node is offline while it runs. On PathDB Nitro prunes online as the node runs, with no intervention and no downtime. An archive node prunes nothing by definition.\nState Scheme​\nThe layout Nitro uses to store its state trie on disk, selected with --execution.caching.state-scheme. Nitro supports two: HashDB (the default) and PathDB. The two are not interchangeable — a node can only start from a database snapshot built with the same state scheme, so switching means re-initializing the database.\nState Transition Function​\nThe STF (State Transition Function) defines how new blocks are produced from input messages (i.e., transactions) on an Arbitrum chain. The State Transition Function's output is the result of applying those input messages (transactions).\nStylus​\nUpgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM. Currently on testnet (read more).\nTimeboost​\nA transaction ordering policy in which entities can bid for the right to access an express lane on the Sequencer for faster transaction inclusion. See the research specification to learn more.\nTimer​\nThe count of blocks an edge has stayed unrivaled. The protocol measures time in blocks of the first non-Arbitrum ancestor chain — Ethereum blocks for L2 chains, and for L3 chains that settle to an Arbitrum chain. An edge's timer stops when a rival edge appears onchain. Two edges are rivals when they agree on some prefix of a computation from the same start state, but disagree on the rest of it. The protocol confirms an assertion once the timer of its unrivaled edge reaches the challenge period.\nToken Gateway​\nA pair of contracts in the token bridge—one on the Parent chain , one on the Child chain—that provide a particular mechanism for handling the transfer of tokens between layers. Token gateways currently active in the bridge include the StandardERC20 gateway , the Generic-Custom Gateway , and the WETH Gateway.\nTransaction​\nA user-initiated interaction with a Blockchain. Transactions are typically signed by users via wallets and are paid for via transaction fees.\nTransaction Ordering Policy​\nThe rules and logic employed by a chain to order incoming transactions into a block.\nTrustless​\nIn the context of Ethereum, trustless refers to the ability of a system to operate without reliance on a central authority or intermediary. Instead, users place their trust in math and protocols.\nThis is achieved through the use of cryptographic techniques and decentralized consensus mechanisms that let users verify the integrity of network transactions using open-source software. Trustless systems are considered to be more secure and resistant to fraud or tampering because they don't rely on a single point of failure that can be exploited by attackers.\nTrustless bonding pool​\nA smart contract that allows multiple participants to pool funds and post an Assertion or challenge bond under BoLD without trusting one another. Refunds and rewards are distributed proportionally on resolution, so any honest party can contribute to defending the chain without staking the full bond alone.\nTrustless verification​\nValidators confirm assertions, ensuring transactions adhere to the protocol rules.\nUnderlying Chain​\nSynonymous with Parent chain.\nUpgrade Executor​\nThe single privileged contract—deployed once per Arbitrum chain by the rollup creator—that authorizes protocol upgrades and admin actions. The Upgrade Executor owns both the chain's rollup contracts and its ProxyAdmin, so every privileged call to the core contracts is routed through it. Its admin role is typically held by the chain owner.\nValidating bridge​\nThe bridge smart contract that uses the parent chain's security and censorship resistance to unlock bridged assets. Assets unlock only after the chain posts and confirms an assertion showing that the assets left the child chain.\nValidator​\nAn Arbitrum Full Node that tracks the status of the chains' Assertions. A validator may be a Watchtower Validator, a Defensive Validator, or an Active Validator.\nValidator client​\nThe software an honest validator runs. It learns the correct child chain history from a state manager backend, then posts assertions to the parent chain by bonding a claim. It reaches the contracts through chain bindings. It tracks the Rollup contract for posted assertions and, if you configure it to do so, opens challenges against invalid ones. Under BoLD it also joins challenges that other honest validators started. Its goal is that only honest assertions are confirmed, and that every honest assertion is confirmed within at most two challenge periods. Every Arbitrum full node is a watchtower validator by default: it posts nothing, but warns you when it detects an invalid assertion.\nAlso known as: validator software\nWallet​\nWhen referring to a wallet, we mean the user client software enabling user actions. Often, client software is a browser extension, mobile, or desktop app. Also refer to Externally Owned Accounts.\nWASM​\nWidely supported binary code format for executable programs. Used by Arbitrum Nitro for Fraud proofs , and more broadly used by Stylus to support performant smart contracts in a wide variety of languages.\nWASM module root​\nA 32-byte cryptographic hash that uniquely identifies a specific version of Arbitrum's State Transition Function (STF), compiled to WASM for use in fraud proofs. It is computed as the Merkle root over the Keccak256 hashes of every module in the compiled prover image—the main STF replay binary plus runtime libraries such as soft-float, host_io, user_host, and program_exec.\nThe same WASM module root appears in two places:\n\nOnchain, as the wasmModuleRoot field on the Rollup contract. It is set at deployment and updated by the chain owner via setWasmModuleRoot; every Assertion records the root used to compute it.\nOffchain, by every Validator, as a compiled prover image under target/machines/<root>/. To validate or challenge an assertion, a validator must have the prover image matching the root recorded on that assertion—which may be the current onchain root, or an older one if the assertion predates an ArbOS upgrade.\n\nEvery ArbOS upgrade changes the STF and therefore produces a new WASM module root. Validators must retain the prover images for every older root they may still need to validate or dispute historical assertions against.\nWASMer​\nA popular WebAssembly runtime for executing WASM binaries. A fork of WASMer is used for executing Stylus programs. WASMer executes considerably faster than Geth executes EVM code, contributing to Stylus's lower fees.\nWatchtower Validator​\nA Validator that never bonds / never takes on chain action, who raises the alarm (by whatever offchain means it chooses) if it witnesses an invalid assertion.\nWAVM​\nArbitrum's variant of WASM, used inside the State Transition Function for fraud-proof execution. WAVM constrains standard WASM so that execution is deterministic and provable onchain—non-deterministic instructions are removed and floating-point operations are replaced with software implementations. The specific WAVM prover image in use is identified by the WASM module root.\nWETH Gateway​\nToken Gateway for handing the bridging of wrapped Ether (WETH). WETH is unwrapped on the parent chain and rewrapped on the parent chain upon depositing (and vice-versa upon withdrawing), ensuring WETH on the child chain always remains collateralized.ActivationActive ValidatorAddress AliasAdjustment windowAlt-DADecentralized applicationArb Token BridgeArbified Token ListArbitrumArbitrum AnyTrust ChainArbitrum AnyTrust ProtocolArbitrum Bridge UIArbitrum chainArbitrum ChainsArbitrum ClassicArbitrum DAOArbitrum Expansion Program (AEP)Arbitrum Full NodeArbitrum NitroArbitrum NovaArbitrum OneArbitrum Rollup ChainArbitrum Rollup ProtocolArbOSArchive NodeAssertionAuction ContractAutonomous AuctioneerBatchBatch PosterBisectionBlobBlockchainBLS SignatureBoLDBonderBondingBridgeChain bindingsChain OwnerChain stateChallengeChallenge bondChallenge manager clientChallenge PeriodChallenge protocolChallengeManagerChild chainClientCommitmentConfirmationCross-chain messageCustom Arb-TokenCustom gas tokenCustom gatewayData Availability CertificateData Availability Committee (DAC)Data Availability Server (DAS)Database SnapshotDefensive ValidatorDelay attackDelayed InboxDeterministic provingDev-Tools DashboardDissectionEdgeEIP-1559EIP-4844Ethereum WalletExecution claimExpress LaneExpress Lane ControllerExternally Owned AccountsFast Exit / Liquidity ExitFast FeedFast withdrawalsFeed RelayFirst Come First Serve (FCFS)Force-InclusionForwarderFraud proofGas Price FloorGas targetGateway RouterGeneric-Custom GatewayGethHard finalityHashDBHistory commitmentHonest validatorHost I/OInkKeysetL1L2L2 BlockL2 to L1 MessageLayer 1 (L1)Layer 2 (L2)Layer 3 (L3)Layer LeapMultiVMNative Fee TokenNative mint/burn gas tokenOffchain LabsOne Step ProofOneStepProverOracleOutboxParent chainPathDBPebblePermissionless validationPortalPrechecker NodePrecompilePredecessor AssertionPriority FeePriority Gas Auction (PGA)propAMMProposerraasRBlockReorgRetryable AutoredeemRetryable RedeemRetryable TicketReverse Token GatewayRivalRoll forwardRollup contractRollup Event InboxRollup Improvement ProposalSearcherSequencerSequencer FeedSequencer InboxShared SequencingSmart ContractSoft ConfirmationStandard Arb-TokenStandardERC20 gatewayState manager backendState PruningState SchemeState Transition FunctionStylusTimeboostTimerToken GatewayTransactionTransaction Ordering PolicyTrustlessTrustless bonding poolTrustless verificationUnderlying ChainUpgrade ExecutorValidating bridgeValidatorValidator clientWalletWASMWASM module rootWASMerWatchtower ValidatorWAVMWETH Gateway","tokens":12370,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257781523,"hash":"b6c82febe8609f8db004dd197773e5c46653f545"}
{"url":"https://www.anchor-lang.com/docs/basics","domain":"anchor-lang.com","title":"Anchor Framework Basics","text":"Anchor Framework BasicsLearn how to use the Anchor framework to build secure Solana programs.Before diving into Anchor, it's recommended to have a basic understanding of\nSolana's core concepts.Program StructureLearn about the structure of Anchor programs, including key macros and their roles in simplifying Solana program developmentProgram IDL FileLearn about the Interface Description Language (IDL) file in Anchor, its purpose, benefits, and how it simplifies program-client interactionsProgram Derived AddressLearn how to use Program Derived Addresses (PDAs) in Anchor programs to create deterministic account addresses.Cross Program InvocationLearn how to implement Cross Program Invocations (CPIs) in Anchor programs to enable composability between different Solana programs.PreviousLocal DevelopmentNextProgram StructureOn this pageNo HeadingsEdit on GitHub","tokens":216,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257785145,"hash":"e057a3cad992e71adbd4ab83f16551504a7b8a52"}
{"url":"https://www.anchor-lang.com/docs/quickstart/solpg","domain":"anchor-lang.com","title":"Solana Playground","text":"QuickstartSolana PlaygroundLearn how to build your first Solana program using the Anchor framework directly in your browser.In this section, we'll build, deploy, and test a simple Solana program using the\nAnchor framework. By the end, you'll have deployed your first program to the\nSolana blockchain!\nSolana Playground (Solpg) is a browser-based development environment that allows\nyou to quickly develop, deploy, and test Solana programs!\nGetting Started\nOpen a new tab in your web browser and navigate to https://beta.solpg.io/.\nCreate Playground WalletIf you're new to Solana Playground, the first step is to create your Playground\nWallet. This wallet will allow you to interact with the Solana network right\nfrom your browser.Step 1. Connect to PlaygroundClick the \"Not connected\" button at the bottom left of the screen.Step 2. Create Your WalletYou'll see an option to save your wallet's keypair. Optionally, save your\nwallet's keypair for backup and then click \"Continue\".You should now see your wallet's address, SOL balance, and connected cluster\n(devnet by default) at the bottom of the window.Your Playground Wallet will be saved in your browser's local storage. Clearing\nyour browser cache will remove your saved wallet.Some definitions you may find helpful:\nwallet address: a public key that serves as your unique identity on the\nSolana blockchain. Just like an email address is used to receive emails, your\nwallet address is used to receive SOL.\nconnection cluster: a network of Solana nodes (computers running Solana\nvalidator client). Devnet is the cluster for developer testing.\nGet Devnet SOLBefore we start building, we first need some devnet SOL.From a developer's perspective, SOL is required for two main use cases:\nTo create accounts on the network where we store data or deploy programs\nTo pay for transaction fees when we interact with the network\nBelow are two methods to fund your wallet with devnet SOL:Option 1: Using the Playground TerminalTo fund your Playground wallet with devnet SOL. In the Playground terminal, run:solana airdrop 5Option 2: Using the Devnet FaucetIf the airdrop command doesn't work (due to rate limits or errors), you can use\nthe Web Faucet.\nEnter your wallet address (found at the bottom of the Playground screen) and\nselect an amount\nClick \"Confirm Airdrop\" to receive your devnet SOL\nCreate Anchor ProjectFirst, open https://beta.solpg.io in a new browser tab.\n\nClick the \"Create a new project\" button on the left-side panel.\n\nEnter a project name, select Anchor as the framework, then click the \"Create\"\nbutton.\n\nYou'll see a new project created with the program code in the src/lib.rs file.use anchor_lang::prelude::*;\n\n// This is your program's public key and it will update\n// automatically when you build the project.\ndeclare_id!(\"11111111111111111111111111111111\");\n\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>, data: u64) -> Result<()> {\n ctx.accounts.new_account.data = data;\n msg!(\"Changed data to: {}!\", data); // Message will show up in the tx logs\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n // We must specify the space in order to initialize an account.\n // First 8 bytes are default account discriminator,\n // next 8 bytes come from NewAccount.data being type u64.\n // (u64 = 64 bits unsigned integer = 8 bytes)\n #[account(init, payer = signer, space = 8 + 8)]\n pub new_account: Account<'info, NewAccount>,\n #[account(mut)]\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[account]\npub struct NewAccount {\n data: u64\n}Build and Deploy ProgramTo build the program, simply run build in the terminal.buildNotice that the address in declare_id!() has been updated. This is your\nprogram's on-chain address.Once the program is built, run deploy in the terminal to deploy the program to\nthe network (devnet by default). To deploy a program, SOL must be allocated to\nthe on-chain account that stores the program.Before deployment, ensure you have enough SOL. You can get devnet SOL by either\nrunning solana airdrop 5 in the Playground terminal or using the\nWeb Faucet.deployAlternatively, you can also use the Build and Deploy buttons on the\nleft-side panel.Once the program is deployed, you can now invoke its instructions.Test ProgramIncluded with the starter code is a test file found in tests/anchor.test.ts.\nThis file demonstrates how to invoke the initialize instruction on the starter\nprogram from the client.// No imports needed: web3, anchor, pg and more are globally available\n\ndescribe(\"Test\", () => {\n it(\"initialize\", async () => {\n // Generate keypair for the new account\n const newAccountKp = new web3.Keypair();\n\n // Send transaction\n const data = new BN(42);\n const txHash = await pg.program.methods\n .initialize(data)\n .accounts({\n newAccount: newAccountKp.publicKey,\n signer: pg.wallet.publicKey,\n systemProgram: web3.SystemProgram.programId,\n })\n .signers([newAccountKp])\n .rpc();\n console.log(`Use 'solana confirm -v ${txHash}' to see the logs`);\n\n // Confirm transaction\n await pg.connection.confirmTransaction(txHash);\n\n // Fetch the created account\n const newAccount = await pg.program.account.newAccount.fetch(\n newAccountKp.publicKey,\n );\n\n console.log(\"On-chain data is:\", newAccount.data.toString());\n\n // Check whether the data on-chain is equal to local 'data'\n assert(data.eq(newAccount.data));\n });\n});To run the test file once the program is deployed, run test in the terminal.testYou should see an output indicating that the test passed successfully.You can also use the Test button on the left-side panel.You can then view the transaction logs by running the solana confirm -v\ncommand and specifying the transaction hash (signature) from the test output:solana confirm -v [TxHash]For example:solana confirm -v 3TewJtiUz1EgtT88pLJHvKFzqrzDNuHVi8CfD2mWmHEBAaMfC5NAaHdmr19qQYfTiBace6XUmADvR4Qrhe8gH5ucAlternatively, you can view the transaction details on\nSolanaFM or\nSolana Explorer by searching for\nthe transaction signature (hash).Reminder to update the cluster (network) connection on the Explorer you are\nusing to match Solana Playground. Solana Playground's default cluster is\ndevnet.Close ProgramLastly, the SOL allocated to the on-chain program can be fully recovered by\nclosing the program.You can close a program by running the following command and specifying the\nprogram address found in declare_id!():solana program close [ProgramID]For example:solana program close 2VvQ11q8xrn5tkPNyeraRsPaATdiPx8weLAD8aD4dn2rCongratulations! You've just built and deployed your first Solana program using\nthe Anchor framework!PreviousQuickstartNextLocal DevelopmentOn this pageGetting StartedCreate Playground WalletGet Devnet SOLCreate Anchor ProjectBuild and Deploy ProgramTest ProgramClose ProgramEdit on GitHub","tokens":1701,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257794666,"hash":"5d8647ec17c0e92a6bb276e3a28a3a895de0b967"}
{"url":"https://docs.arbitrum.io/get-started/arbitrum-introduction","domain":"docs.arbitrum.io","title":"Arbitrum introduction | Arbitrum Docs","text":"✏️Request an updateWhat is Arbitrum?​\nArbitrum is a finance-native blockchain platform. It provides infrastructure for applications, tokenization, and dedicated blockchain environments.\nYou can build on the public chains Arbitrum One and Arbitrum Nova, or you can launch your own Arbitrum chain and configure its execution, data availability, fee model, governance, and validation.\nArbitrum runs on top of Ethereum. Your transactions cost less and the chain processes more of them per second, while Ethereum still settles the results and keeps the data available. This page explains the main parts of the platform: Arbitrum Rollup, AnyTrust, Nitro, Stylus, Arbitrum One, Arbitrum Nova, and Arbitrum chains.\n\nTwo pairs of names appear throughout this page. Ethereum is the parent chain, also called layer 1. An Arbitrum chain that settles to Ethereum is a child chain, also called layer 2.\nWhy does Ethereum need help scaling?​\nNothing is wrong with Ethereum. Its limits follow from design choices that put decentralization and security first.\nThat tradeoff is the scalability trilemma: a chain cannot maximize decentralization, security, and scalability at the same time. Ethereum optimizes the first two, which caps the third.\n\nRather than weaken security or decentralization, the Ethereum roadmap moves execution offchain to Rollups like Arbitrum. Ethereum then specializes in settlement and data availability.\nA Rollup orders many transactions into a batch, executes them on its own infrastructure, and posts compressed data and a state commitment back to Ethereum. You inherit Ethereum's security, throughput rises by orders of magnitude, and fees drop.\nTo go deeper, read How Arbitrum works.\nWhy does Ethereum process so few transactions per second?​\nEthereum's low throughput follows from the protocol design. It is not a bug or a missing optimization.\nEthereum nodes must agree on the current state, and they reach that agreement by having every node process every transaction.\nEthereum is also an open, decentralized, peer-to-peer system, so anyone can run a node and validate the chain. Keeping that possible means keeping the work per node small.\nTogether, these two requirements cap transactions per second (TPS). The roadmap answers this by having child chains like Arbitrum carry the throughput.\nHow does Arbitrum solve this?​\nArbitrum does not make Ethereum faster. It lets you transact at much higher throughput while you still inherit Ethereum's security.\nEthereum's bottleneck is that every node re-executes every transaction. Arbitrum separates two jobs that Ethereum combines:\n\nExecution. Running transactions and updating state.\nSettlement and data availability. Agreeing on the canonical result and keeping the data publicly retrievable.\n\nArbitrum executes offchain and uses Ethereum for settlement and data availability. Ethereum nodes do not re-execute Arbitrum transactions. They store the compressed data and accept the result unless someone proves it wrong.\nHow does Arbitrum prove that a result is correct?​\nWhen a transaction reaches Arbitrum, the sequencer puts it in order. Arbitrum compresses that order and posts it to Ethereum. The posted order is the evidence of which transactions run, and that is where the name \"Rollup\" comes from.\nAs long as Ethereum stays secure, anyone can read those transactions. If a result differs from the posted order, a validator can challenge it.\nBillions of dollars have moved through Arbitrum, and no fraudulent result has ever been confirmed.\nTo learn how the dispute protocol works, read the BoLD gentle introduction.\nWho validates the chain and raises challenges?​\nAnyone can validate Arbitrum's chain state. Whoever does so is a validator. Most people do not run one, in the same way that most people do not run an Ethereum staking node.\nThe fraud proof system needs only one honest validator to keep the chain secure, and that single validator can catch several malicious actors. This is what makes the system trustless: your funds do not depend on any one designated party.\nTo learn about the validator types, read Run a validator node.\nHow does a fraud proof work?​\nIn short: two validators disagree about an executed transaction. Ethereum holds the posted data, so only one of them can be telling the truth.\nRe-executing every transaction on Ethereum would cost too much. Instead, each party bisects its history of commitments until both arrive at the single instruction they disagree about.\nEthereum then acts as the arbiter and declares a winner. The batches that Arbitrum posts to Ethereum are the source of truth, and the challenge process, called BoLD, proves which validator is right.\nFor the full protocol, read the BoLD gentle introduction.\nDoes the challenge period delay my transactions?​\nThere is a delay, but it applies to one action, not to everyday activity.\nActionDelayWithdraw funds from Arbitrum to EthereumYes, typically 6.4 daysUse a third-party fast bridgeNo, for a feeDeposit funds from Ethereum to ArbitrumNo\nThe challenge period delays withdrawals back to Ethereum because that is the point where you cross a trust boundary. It does not affect the transactions you send inside Arbitrum.\nTo learn how bridging works, read Token bridging. To move tokens yourself, follow the Arbitrum bridge quickstart.\nWhy are fees on Arbitrum lower?​\nThe word \"optimistic\" describes how Arbitrum verifies state: it treats an assertion as valid unless someone challenges it through BoLD. That design buys security and correctness rather than cost savings.\nThe low fees come from five other things:\n\nAmortized Ethereum costs. Arbitrum posts transactions in batches. A batch of 500 transactions spreads one posting cost across all 500.\nCompression. Arbitrum compresses the data it posts, so each batch costs less.\nBlobs. EIP-4844 gives Ethereum a separate data lane, priced independently of regular gas, that makes posting batch data cheaper.\nNo global re-execution. Ethereum nodes do not re-execute Arbitrum transactions.\nSingle-sequencer execution. One sequencer is active at a time, so computation runs on one machine instead of thousands.\n\nTo go deeper, read How Arbitrum works.\nIs using Arbitrum the same as using Ethereum?​\nIn short: yes, at lower cost and higher speed. You bridge funds in, use applications, and bridge funds out. Your wallets, applications, and addresses all work.\nLayer 2 protocols optimize for different goals. Arbitrum put Ethereum compatibility first, so you can use your existing Ethereum wallets, and you can build and deploy contracts with your existing Ethereum libraries and tooling.\nArbitrum reaches that compatibility by running a fork of Geth, the most widely used Ethereum implementation, modified to work as a trustless child chain. Most of the code that runs on Arbitrum is the same code that runs on Ethereum. Offchain Labs calls this approach Nitro, and you can read the Nitro codebase.\nFor the differences that remain, read the Comparison overview.\nWhat can you build on Arbitrum that you cannot build on Ethereum?​\nStylus keeps Nitro's Ethereum compatibility and adds a second virtual machine alongside the Ethereum Virtual Machine (EVM). You can write contracts in Rust, C, and C++, and they interoperate with your Solidity contracts. Stylus shipped in ArbOS 32 and runs on Arbitrum One, Arbitrum Nova, and Arbitrum chains. To try it, follow the Stylus quickstart.\nYou can also launch your own Arbitrum chain with a custom gas token. For example, your chain can charge gas in USDC. The gas token is one of many settings you control. To see the full list, read the Arbitrum chain introduction.\nDoes Arbitrum Rollup fit every use case?​\nArbitrum Rollup avoids centralization and extra trust assumptions, which makes it a strong default and a net gain for the Ethereum ecosystem.\nThat decentralization has a price, and not every application needs to pay it. When your security requirements differ, another tool in the Arbitrum suite may fit better, for example an Arbitrum AnyTrust chain.\nWhat is AnyTrust?​\nAnyTrust is a different data availability option. It works like an Arbitrum Rollup, which posts data in batches to Ethereum, with one change: a small committee keeps the data available instead. Everything else stays the same.\nBecause the data stays offchain in the normal case, an AnyTrust chain charges much lower fees. In exchange, AnyTrust does not offer the same decentralization, trustlessness, and permissionless security guarantees as a Rollup.\nIf someone raises a challenge, the AnyTrust chain reverts to Rollup mode. The security assumption is that at least two committee members are honest and will provide the data when it is needed.\nAnyTrust suits applications that need high throughput and do not need the full decentralization of a Rollup.\nTo learn more, read the AnyTrust protocol.\nHow many Arbitrum chains are there?​\nMany. Running multiple chains in parallel is a core advantage of offchain scaling.\nHere is a snapshot of the chains running today:\n\nOn Ethereum, as layer 2:\n\nArbitrum One, an Arbitrum Rollup chain that the Arbitrum Foundation operates\nArbitrum Nova, an AnyTrust chain that the Arbitrum Foundation operates\nArbitrum chains that developers launch and operate themselves\n\nOn an EVM layer 2, as layer 3:\n\nArbitrum chains on Arbitrum One and Arbitrum Nova\nArbitrum chains on other EVM layer 2 chains\n\nYou can launch your own Arbitrum chain as a layer 2 on Ethereum, or as a layer 3 on an EVM layer 2 chain. For a full list of the chains running today, see the Arbitrum Portal.\nPick the chain that matches your security and cost requirements. To launch your own, read the Arbitrum chain introduction.\nWho decides the future of Arbitrum?​\nThe Arbitrum governance system owns the Arbitrum chains. To learn how it works, read the Arbitrum governance documentation.What is Arbitrum?Why does Ethereum need help scaling?Why does Ethereum process so few transactions per second?How does Arbitrum solve this?How does Arbitrum prove that a result is correct?Who validates the chain and raises challenges?How does a fraud proof work?Does the challenge period delay my transactions?Why are fees on Arbitrum lower?Is using Arbitrum the same as using Ethereum?What can you build on Arbitrum that you cannot build on Ethereum?Does Arbitrum Rollup fit every use case?What is AnyTrust?How many Arbitrum chains are there?Who decides the future of Arbitrum?","tokens":2599,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257797458,"hash":"2ac32be8a0fe3681617bd48f8b62e14bedd36bfb"}
{"url":"https://www.openzeppelin.com/news/spglobal-enters-agreement-to-acquire-openzeppelin","domain":"openzeppelin.com","title":"S&P Global Enters Agreement to Acquire OpenZeppelin","text":"September 17, 2026OpenZeppelinSeptember 17, 2026 — S&P Global (NYSE: SPGI) has entered an agreement to acquire OpenZeppelin, the security standard for onchain finance. Since 2015, OpenZeppelin has set the security standards and secured the infrastructure onchain finance is built on: $37 trillion in value transferred through OpenZeppelin Contracts, more than 900 security engagements, and 10,000+ vulnerabilities surfaced before production. The agreement brings together the security foundation of onchain finance and one of the most trusted names in global capital markets, just as onchain finance grows from an emerging market into core financial infrastructure.Why we are doing thisOpenZeppelin’s mission is to accelerate the world's transition to an open financial system, and that transition has reached an inflection point. Traditional finance is moving onchain: the vast majority of the largest stablecoins and tokenized money market funds are built on OpenZeppelin's standards, and the institutions entering these markets require security that meets rigorous regulatory, compliance, and operational standards. Accelerating institutional adoption of onchain finance requires deep integration with those frameworks, without sacrificing the values and the openness that defines this technology: open source code and permissionless public networks anyone can build on. S&P Global brings what that next stage requires: institutional relationships, global distribution, and more than a century of trust in financial markets.For the crypto and DeFi ecosystem, this is the moment the rails the community built become institutional infrastructure. OpenZeppelin, working within S&P Global, connects DeFi and public blockchains to the benchmarks, risk frameworks, and institutional relationships that global markets already run on, bringing the ecosystem into its next phase of growth. OpenZeppelin’s standards, open source libraries, security research, and ecosystem programs developers rely on carry forward with institutional resources behind them.\"Ten years ago, we started OpenZeppelin with the vision of a secure, global financial system powered by blockchain-based smart contracts,” said Demian Brener, CEO, OpenZeppelin. “Today, those same rails used in DeFi carry tokenized funds, stablecoins, and institutional balance sheets. Joining S&P Global will take this work to its next stage: the standard our team and community built becomes the standard the next generation of global finance runs on.\"“Our digital assets strategy centers on bringing trusted data, benchmarks and transparent risk assessment to markets as they move onchain,\" said Yann Le Pallec, President, S&P Global Ratings. \"As digital assets and tokenized markets continue to mature, OpenZeppelin’s technology and expertise will complement our smart contract and onchain technology risk assessment capabilities, giving traditional financial institutions and DeFi-native companies alike the confidence to build and transact in this new environment.”Unchanged commitments, institutional resourcesOpen source standards: The OpenZeppelin Contracts libraries, the established gold standard for onchain development, remain open source, free, and publicly maintained on GitHub. Every released version remains open source permanently and cannot be withdrawn by anyone, and future versions stay open source. The same commitment extends across all our open source applications and tools as building open source security standards remains a core priority.Client engagements: All security audits, engineering work, and ecosystem programs continue as they do today, delivered by the same team with the same quality, expertise, and customer experience. What changes is access to a deeper set of resources and a broader customer network: S&P Global's research capacity, market data, and institutional reach strengthen what we deliver to every client, from the protocols and networks that pioneered onchain finance to the institutions now adopting it.For the last decade, OpenZeppelin has set the security standard for onchain finance. Today begins a new chapter for that mission, together with one of the most trusted names in global markets.The transaction is subject to closing conditions. Financial terms of the transaction were not disclosed. FT Partners is serving as financial advisor to OpenZeppelin; Cooley is acting as OpenZeppelin’s legal advisor.Media inquiries: press@openzeppelin.com","tokens":1113,"squid":"ink-security_audits","role":"Sentinel","at":1791257797821,"hash":"e3284a7fedfec3051ca7d840608a5f112f0db9c8"}
{"url":"https://www.anchor-lang.com/docs/features/declare-program","domain":"anchor-lang.com","title":"Dependency Free Composability","text":"Additional FeaturesDependency Free ComposabilityLearn how to use Anchor's declare_program macro to interact with programs without additional dependencies.The\ndeclare_program!()\nmacro simplifies the process of interacting with Anchor programs by generating\nRust modules (from a program's IDL) that can be used in both on-chain and\noff-chain code. You can find an example program\nhere.\nThe following modules are generated by the declare_program!() macro:\nModuleDescriptioncpiHelper functions for making cross-program invocations (CPIs) to the program from other on-chain programsclientAccounts and arguments required to build program instructions to add to client-side transactionsaccountAccount data types (program state) defined in the programprogramProgram ID constant used to identify the programconstantsProgram constants defined in the programeventsProgram events defined in the programtypesProgram types defined in the programerrorProgram errors defined in the programparsersParsers for program accounts, instructions and events\nExamples\nThe following examples demonstrate how to use the declare_program!() macro in\ntwo scenarios:\n\nMaking Cross Program Invocations (CPIs) from one program to another program\nBuilding client-side transactions to invoke a program's instructions\n\nBoth examples show how the modules generated by the declare_program!() macro\nsimplify program interactions, whether you're writing on-chain or off-chain\ncode.\nOn-chain CPI\nTo use the declare_program!() macro, you need the IDL file for the target\nprogram. The IDL file must be placed in a directory named /idls in your\nproject. The /idls directory can be located at any level in your project\nstructure. For example, your project could have this layout:\nexample.jsonlib.rsCargo.toml\nBelow is the source code (lib.rs) for the target (callee) program that\ngenerates the example.json IDL file shown above.\nUsing the program's IDL file, another program can use the declare_program!()\nmacro to generate a CPI module, enabling it to make CPIs to this program's\ninstructions.\nuse anchor_lang::prelude::*;\n\ndeclare_id!(\"8HupNBr7SBhBLcBsLhbtes3tCarBm6Bvpqp5AfVjHuj8\");\n\n#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let counter = &ctx.accounts.counter;\n msg!(\"Counter account created! Current count: {}\", counter.count);\n Ok(())\n }\n\n pub fn increment(ctx: Context<Increment>) -> Result<()> {\n let counter = &mut ctx.accounts.counter;\n msg!(\"Previous counter: {}\", counter.count);\n\n counter.count += 1;\n msg!(\"Counter incremented! Current count: {}\", counter.count);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n\n #[account(\n init,\n payer = payer,\n space = 8 + 8\n )]\n pub counter: Account<'info, Counter>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct Increment<'info> {\n #[account(mut)]\n pub counter: Account<'info, Counter>,\n}\n\n#[account]\npub struct Counter {\n pub count: u64,\n}\nBelow is the source code (lib.rs) for the caller program (example-cpi) that\nuses the declare_program!() macro to generate a CPI module to invoke the\ninstructions defined in the callee program above.\nuse anchor_lang::prelude::*;\n\ndeclare_id!(\"GENmb1D59wqCKRwujq4PJ8461EccQ5srLHrXyXp4HMTH\");\n\ndeclare_program!(example);\nuse example::{\n accounts::Counter,\n cpi::{\n self,\n accounts::{Increment, Initialize},\n },\n program::Example,\n};\n\n#[program]\npub mod example_cpi {\n\n use super::*;\n\n pub fn initialize_cpi(ctx: Context<InitializeCpi>) -> Result<()> {\n // Create CPI context for initialize\n let cpi_ctx = CpiContext::new(\n ctx.accounts.example_program.key(),\n Initialize {\n payer: ctx.accounts.payer.to_account_info(),\n counter: ctx.accounts.counter.to_account_info(),\n system_program: ctx.accounts.system_program.to_account_info(),\n },\n );\n\n // Invoke the initialize instruction\n cpi::initialize(cpi_ctx)?;\n Ok(())\n }\n\n pub fn increment_cpi(ctx: Context<IncrementCpi>) -> Result<()> {\n // Create CPI context for increment\n let cpi_ctx = CpiContext::new(\n ctx.accounts.example_program.key(),\n Increment {\n counter: ctx.accounts.counter.to_account_info(),\n },\n );\n\n // Invoke the increment instruction\n cpi::increment(cpi_ctx)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct InitializeCpi<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(mut)]\n pub counter: Signer<'info>,\n pub system_program: Program<'info, System>,\n pub example_program: Program<'info, Example>,\n}\n\n#[derive(Accounts)]\npub struct IncrementCpi<'info> {\n #[account(mut)]\n pub counter: Account<'info, Counter>,\n pub example_program: Program<'info, Example>,\n}\nExplanation\nThe declare_program!() macro takes a single argument - the name of the\nprogram's IDL file (e.g. example.json):declare_program!(example); // Looks for /idls/example.jsonBring into scope the generated modules:use example::{\n accounts::Counter, // Account types\n cpi::{ // Cross program invocation helpers\n self,\n accounts::{Increment, Initialize},\n },\n program::Example, // Program type\n};Use the imported types in the account validation structs:#[derive(Accounts)]\npub struct IncrementCpi<'info> {\n // Counter type from accounts module\n #[account(mut)]\n pub counter: Account<'info, Counter>,\n\n // Example type from program module\n pub example_program: Program<'info, Example>,\n}Use the CPI module to invoke the program's instructions:pub fn initialize_cpi(ctx: Context<InitializeCpi>) -> Result<()> {\n // Create CPI context for initialize\n let cpi_ctx = CpiContext::new(\n ctx.accounts.example_program.key(),\n Initialize {\n payer: ctx.accounts.payer.to_account_info(),\n counter: ctx.accounts.counter.to_account_info(),\n system_program: ctx.accounts.system_program.to_account_info(),\n },\n );\n\n // Invoke the initialize instruction\n cpi::initialize(cpi_ctx)?;\n Ok(())\n}pub fn increment_cpi(ctx: Context<IncrementCpi>) -> Result<()> {\n // Create CPI context for increment\n let cpi_ctx = CpiContext::new(\n ctx.accounts.example_program.key(),\n Increment {\n counter: ctx.accounts.counter.to_account_info(),\n },\n );\n\n // Invoke the increment instruction\n cpi::increment(cpi_ctx)?;\n Ok(())\n}\nOff-chain Client\nTo use the declare_program!() macro, you need the IDL file for the target\nprogram. The IDL file must be placed in a directory named /idls in your\nproject. The /idls directory can be located at any level in your project\nstructure. For example, your project could have this layout:\nexample.jsonmain.rsCargo.toml\nBelow is the source code (lib.rs) for the target program that generates the\nexample.json IDL file shown above. The program's IDL can then be used in a\nclient script along with the declare_program!() macro to generate a Client\nmodule to build the program's instructions.\nuse anchor_lang::prelude::*;\n\ndeclare_id!(\"6khKp4BeJpCjBY1Eh39ybiqbfRnrn2UzWeUARjQLXYRC\");\n\n#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let counter = &ctx.accounts.counter;\n msg!(\"Counter account created! Current count: {}\", counter.count);\n Ok(())\n }\n\n pub fn increment(ctx: Context<Increment>) -> Result<()> {\n let counter = &mut ctx.accounts.counter;\n msg!(\"Previous counter: {}\", counter.count);\n\n counter.count += 1;\n msg!(\"Counter incremented! Current count: {}\", counter.count);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n\n #[account(\n init,\n payer = payer,\n space = 8 + 8\n )]\n pub counter: Account<'info, Counter>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct Increment<'info> {\n #[account(mut)]\n pub counter: Account<'info, Counter>,\n}\n\n#[account]\npub struct Counter {\n pub count: u64,\n}\nBelow is the client script (main.rs) that uses the declare_program!() macro to\ngenerate a Client module to build the program's instructions.\nuse anchor_client::{\n solana_client::rpc_client::RpcClient,\n solana_sdk::{\n commitment_config::CommitmentConfig, native_token::LAMPORTS_PER_SOL, signature::Keypair,\n system_program,\n },\n solana_signer::Signer,\n Client, Cluster,\n};\nuse anchor_lang::prelude::*;\nuse std::rc::Rc;\n\ndeclare_program!(example);\nuse example::{accounts::Counter, client::accounts, client::args};\n\n#[tokio::main]\nasync fn main() -> anyhow::Result<()> {\n let connection = RpcClient::new_with_commitment(\n \"http://127.0.0.1:8899\", // Local validator URL\n CommitmentConfig::confirmed(),\n );\n\n // Generate Keypairs and request airdrop\n let payer = Keypair::new();\n let counter = Keypair::new();\n println!(\"Generated Keypairs:\");\n println!(\" Payer: {}\", payer.pubkey());\n println!(\" Counter: {}\", counter.pubkey());\n\n println!(\"\\nRequesting 1 SOL airdrop to payer\");\n let airdrop_signature = connection.request_airdrop(&payer.pubkey(), LAMPORTS_PER_SOL)?;\n\n // Wait for airdrop confirmation\n while !connection.confirm_transaction(&airdrop_signature)? {\n std::thread::sleep(std::time::Duration::from_millis(100));\n }\n println!(\" Airdrop confirmed!\");\n\n // Create program client\n let provider = Client::new_with_options(\n Cluster::Localnet,\n Rc::new(payer),\n CommitmentConfig::confirmed(),\n );\n let program = provider.program(example::ID)?;\n\n // Build and send instructions\n println!(\"\\nSend transaction with initialize and increment instructions\");\n let initialize_ix = program\n .request()\n .accounts(accounts::Initialize {\n counter: counter.pubkey(),\n payer: program.payer(),\n system_program: system_program::ID,\n })\n .args(args::Initialize)\n .instructions()?\n .remove(0);\n\n let increment_ix = program\n .request()\n .accounts(accounts::Increment {\n counter: counter.pubkey(),\n })\n .args(args::Increment)\n .instructions()?\n .remove(0);\n\n let signature = program\n .request()\n .instruction(initialize_ix)\n .instruction(increment_ix)\n .signer(&counter)\n .send()\n .await?;\n println!(\" Transaction confirmed: {}\", signature);\n\n println!(\"\\nFetch counter account data\");\n let counter_account: Counter = program.account::<Counter>(counter.pubkey()).await?;\n println!(\" Counter value: {}\", counter_account.count);\n Ok(())\n}\nThe declare_program!() macro takes a single argument - the name of the\nprogram's IDL file (e.g. example.json):declare_program!(example); // Looks for /idls/example.jsonBring into scope the generated modules:use example::{\n accounts::Counter, // Program Account types\n client::accounts, // Accounts for program instructions\n client::args, // Arguments for program instructions\n};Use the Client module to build the program's instructions:// Build initialize instruction\nlet initialize_ix = program\n .request()\n // Accounts required for initialize instruction\n .accounts(accounts::Initialize {\n counter: counter.pubkey(),\n payer: program.payer(),\n system_program: system_program::ID,\n })\n // Arguments for initialize instruction (discriminator)\n .args(args::Initialize)\n .instructions()?\n .remove(0);// Build increment instruction\nlet increment_ix = program\n .request()\n // Accounts required for increment instruction\n .accounts(accounts::Increment {\n counter: counter.pubkey(),\n })\n // Arguments for increment instruction (discriminator)\n .args(args::Increment)\n .instructions()?\n .remove(0);Add the program's instructions to a transaction and send the transaction:let signature = program\n .request()\n .instruction(initialize_ix)\n .instruction(increment_ix)\n .signer(&counter)\n .send()\n .await?;Use the Account module to fetch and deserialize the program's account types:// Counter type from accounts module\nlet counter_account: Counter = program.account::<Counter>(counter.pubkey()).await?;PreviousFeaturesNextCustom ErrorsOn this pageExamplesOn-chain CPIOff-chain ClientEdit on GitHub","tokens":2901,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257808623,"hash":"9d274112c44134896ac006312860e0eb2e95d316"}
{"url":"https://docs.arbitrum.io/for-devs/dev-tools-and-resources/chain-info","domain":"docs.arbitrum.io","title":"Arbitrum chain information | Arbitrum Docs","text":"✏️Request an updateArbitrum public RPC endpoints​\ncaution\nUnlike the RPC Urls, the Sequencer endpoints only support eth_sendRawTransaction and eth_sendRawTransactionConditional calls.\nArbitrum public RPCs do not provide Websocket support.\nIPv6 is not supported.\n\nThis section provides an overview of the available public RPC endpoints for different Arbitrum chains and necessary details to interact with them.\nNameRPC Url(s)Chain IDBlock explorerUnderlying chainTech stackSequencer feed URLSequencer endpoint⚠️Arbitrum Onehttps://arb1.arbitrum.io/rpc42161Arbiscan, BlockscoutEthereumNitro (Rollup)wss://arb1-feed.arbitrum.io/feedhttps://arb1-sequencer.arbitrum.io/rpcArbitrum Novahttps://nova.arbitrum.io/rpc42170BlockscoutEthereumNitro (AnyTrust)wss://nova-feed.arbitrum.io/feedhttps://nova-sequencer.arbitrum.io/rpcArbitrum Sepolia (Testnet)https://sepolia-rollup.arbitrum.io/rpc421614Arbiscan, BlockscoutSepoliaNitro (Rollup)wss://sepolia-rollup.arbitrum.io/feedhttps://sepolia-rollup-sequencer.arbitrum.io/rpc\nMore RPC endpointsMore Arbitrum chain RPC endpoints can be found in Chain Connect: Arbitrum One and Arbitrum Nova.\nAlternatively, to interact with public Arbitrum chains, you can rely on many of the same popular node providers that you are already using on Ethereum:\nThird-party RPC providers​\nWANT TO BE LISTED HERE?Complete this form , if you'd like to see your project added to this list (and the Arbitrum portal).\nNeed support for Nova 3rd party tooling?Complete this form to submit a support request.\nProviderArb One?Arb Nova?Arb Sepolia?Websocket?Stylus Tracing?1RPC✅Alchemy✅✅✅Available on paid plansAllnodes✅✅✅All That Node✅✅✅Ankr✅✅Available on paid plansBlockPi✅✅Chainbase✅✅Chainnodes✅Chainstack✅✅Available on paid plansdRPC✅✅✅✅GetBlock✅✅Infura✅✅✅Enabled on requestLava✅✅Moralis✅Nirvana Labs✅✅✅✅NodeReal✅✅NOWNodes✅Pocket Network✅PublicNode✅✅✅Quicknode✅✅✅✅Testnet supported in free tierSwiftNodes✅✅Tenderly✅✅✅Testnet supported in free tierUnifra✅Validation Cloud✅✅✅Testnet supported in free tier\nCompare provider latency​\nFor a live latency comparison of the public no-key Arbitrum endpoints listed above, see the OpenChainBench Arbitrum RPC benchmark tool. Measurements are probed from three regions every minute and published as p50, p95 and p99 latency under an open methodology and CC BY 4.0 license.\nSequencer endpoint behavior​\nArbitrum One exposes two public endpoints with different roles, shown below: a general-purpose public RPC URL, and a direct sequencer endpoint that accepts only eth_sendRawTransaction and eth_sendRawTransactionConditional. The table below summarizes how they differ in purpose and operational guarantees.\nThe two endpoints at a glance​\nEndpointPurposeOperational guaranteeshttps://arb1.arbitrum.io/rpc (public RPC URL)General-purpose read/write endpoint, useful for development and low-volume reads.No uptime, latency, or rate-limit guarantees. Any application that depends on availability should use a third-party node provider or run its own node.https://arb1-sequencer.arbitrum.io/rpc (sequencer endpoint)Direct submission path to the chain's sequencer for write traffic. Accepts only eth_sendRawTransaction and eth_sendRawTransactionConditional.Exposes the defined queueing and timeout behavior described below, but it is still a best-effort public endpoint with no formal SLA.\nLatency and timeout behavior​\nUnder nominal load, transactions submitted to the sequencer endpoint are accepted in well under a second. Internally, the sequencer places submissions into a bounded in-memory queue (default capacity 1024). The queue timeout (default 12 seconds) bounds how long a submitted transaction may remain pending in the sequencer's background queue before being picked up or rejected; it does not provide a formal end-to-end inclusion latency guarantee. If the transaction is not picked up within that window, eth_sendRawTransaction returns context deadline exceeded, and the transaction was not accepted—it is safe to retry.\nRecommended fallback patterns​\n\nUse a third-party node provider as your primary endpoint, or as a fallback when a direct sequencer submission fails.\nRetry on transient errors only—context deadline exceeded and network/connection errors are safe to retry with backoff. Do not retry terminal errors such as nonce too low or contract reverts.\n\nMonitoring and alerting​\nA successful eth_sendRawTransaction response means the sequencer has already sequenced your transaction into an L2 block—the call blocks until the block is created and returns only then, not merely when the transaction is enqueued. Treat this as the sequencer's soft confirmation that your transaction has been ordered and executed. It does not by itself mean the transaction has been posted to the parent chain in a batch or finalized there; if your application needs parent-chain finality guarantees, track that separately. For monitoring, alert on submission calls that return errors or exceed your expected latency ceiling rather than assuming a pending-but-unconfirmed state.\nChain parameters​\nParamDescriptionArbitrum OneArbitrum NovaArb SepoliaDispute windowTime for assertions to get confirmed during which validators can issue a challenge45818 blocks (~ 6.4 days )45818 blocks (~ 6.4 days)20 blocks (~ 4.0 minutes)Minimum bond amountAmount of funds required for a validator to propose assertion on the parent chain3600 ETH1 ETH1 Sepolia ETHForce-include periodPeriod after which a delayed message can be included into the inbox without any action from the Sequencer5760 blocks / 24 hours5760 blocks / 24 hours5760 blocks / 24 hoursGas targetTarget gas/sec, over which the congestion mechanism activatesSee child chain gas feesSee child chain gas feesSee child chain gas feesGas price floorMinimum gas price0.02 gwei0.02 gwei0.2 gweiBlock gas limitMaximum amount of gas that all the transactions inside a block are allowed to consume32,000,00032,000,00032,000,000\nCurrent gas targets​\nGas target (Mgas/s)Adjustment window (seconds)609415229329202,1051413,4851086,400\nTo learn more about the gas target, refer to the Gas and fees deep-dive.\nTo determine how to configure the gas target for your chain, refer to the Dynamic pricing for Arbitrum chains page. To calculate the values for your chain, refer to the How to calculate the values for your chain section on the same page.\nFaucet list​\nNameNetworkTokensPK910 PoW FaucetSepoliaEthereum SepoliaFaucet aggregatorSepoliaEthereum Sepolia, Arb SepoliaAlchemy’s Sepolia FaucetSepoliaEthereum Sepolia, Arb SepoliaInfura's Sepolia FaucetSepoliaEthereum Sepoliaethfaucet.comSepoliaArb Sepolia\nArbitrum Smart Contract Addresses​\n\nThe following information may be useful to those building on Arbitrum. We list the addresses of the smart contracts related to the protocol, the token bridge and precompiles of the different Arbitrum chains.\nProtocol smart contracts​\nCore contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaRollup0x4DCe...Cfc00xE7E8...B7Bd0xd808...81C8Sequencer Inbox0x1c47...82B60x211E...c21b0x6c97...be0DCoreProxyAdmin0x5547...2dbD0x71D7...71480x1ed7...0686\nCross-chain messaging contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaDelayed Inbox0x4Dbd...AB3f0xc444...39490xaAe2...ae21Bridge0x8315...ed3a0xC1Eb...76Bd0x38f9...33a9Outbox0x0B98...48400xD4B8...cc580x65f0...B78FClassic Outbox***0x7607...1A40 0x667e...337a\n***Migrated Network Only\nFraud proof contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaChallengeManager0xA556...9fB00xFE66...A6880xC60b...8B4COneStepProver00x35FB...F7310x35FB...F7310x3Fe7...1377OneStepProverMemory0xe0ba...C48b0xe0ba...C48b0x6268...ec2dOneStepProverMath0xaB95...F9210xaB95...F9210x42f5...e8FaOneStepProverHostIo0xa07c...71Cf0xa07c...71Cf0xdB2c...C165OneStepProofEntry0x4397...42d60x4397...42d60xB9cf...AE80\nToken bridge smart contracts​\nCore contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaL1 Gateway Router0x72Ce...31ef0xC840...cD480xcE18...8264L1 ERC20 Gateway0xa3A7...0EeC0xB253...21bf0x902b...3aFFL1 Arb-Custom Gateway0xcEe2...180d0x2312...232f0xba2F...40F3L1 Weth Gateway0xd920...e2db0xE4E2...0BaE0xA8aD...0e1EL1 Weth0xC02a...6Cc20xC02a...6Cc20x7b79...E7f9L1 Proxy Admin0x9aD4...0aDa0xa8f7...e5600xDBFC...44b0\nThe following contracts are deployed on the corresponding L2 chain\nArbitrum OneArbitrum NovaArbitrum SepoliaL2 Gateway Router0x5288...F9330x2190...DFa80x9fDD...43C7L2 ERC20 Gateway0x09e9...1EEe0xcF9b...92570x6e24...b502L2 Arb-Custom Gateway0x0967...55620xbf54...51F40x8Ca1...42C5L2 Weth Gateway0x6c41...623B0x7626...D9eD0xCFB1...556DL2 Weth0x82aF...Bab10x722E...53650x980B...7c73L2 Proxy Admin0xd570...2a860xada7...d92C0x715D...5FdF\nPrecompiles​\nThe following precompiles are deployed on every L2 chain and always have the same address\nArbitrum OneArbitrum NovaArbitrum SepoliaArbAddressTable0x0000...00660x0000...00660x0000...0066ArbAggregator0x0000...006D0x0000...006D0x0000...006DArbFunctionTable0x0000...00680x0000...00680x0000...0068ArbGasInfo0x0000...006C0x0000...006C0x0000...006CArbInfo0x0000...00650x0000...00650x0000...0065ArbOwner0x0000...00700x0000...00700x0000...0070ArbOwnerPublic0x0000...006b0x0000...006b0x0000...006bArbRetryableTx0x0000...006E0x0000...006E0x0000...006EArbStatistics0x0000...006F0x0000...006F0x0000...006FArbSys0x0000...00640x0000...00640x0000...0064ArbWasm0x0000...00710x0000...00710x0000...0071ArbWasmCache0x0000...00720x0000...00720x0000...0072NodeInterface0x0000...00C80x0000...00C80x0000...00C8\nMisc​\nThe following contracts are deployed on the corresponding L2 chain\nFunctionArbitrum OneArbitrum NovaArbitrum SepoliaL2 Multicall0x842e...4EB20x5e1e...cB860xA115...d092ResourceConstraintManager0x8F59...823a0x653e...86B7\nCanonical factory contracts​\nThe following factory contracts are deployed on the corresponding chain and are used to deploy new Arbitrum chains (RollupCreator) and their token bridges (TokenBridgeCreator). For factory contracts on additional chains (Ethereum, Base, and testnets) and deployment instructions, see Canonical factory contracts.\nArbitrum OneArbitrum NovaArbitrum SepoliaRollupCreator0xB90e...eB8b0xF916...60F40x5F45...16cFTokenBridgeCreator0x2f56...000e0x8B9D...8c140x56C4...bD8E\nNova-specific tooling​\nEffective January 31, 2026 (23:59 UTC), the following third-party tools will no longer be supported for Arbitrum Nova environments:\n\nAlchemy\nNova Arbiscan (nova.arbiscan.io)\nTenderly\n\nThis change does not impact any other Arbitrum technology, such as Arbitrum One or other Arbitrum chains.\nA non-exhaustive list of alternatives to the outgoing tools has been compiled. While the capabilities may not be 1-to-1, suitable replacements are provided that cover the core competencies required.\nServiceAlternate providerRPC- Allnodes - Quicknode - More alternatives can be found at chainlist.orgBlock Explorer- BlockscoutWebhooks- Quicknode\nBelow, an FAQ can be found to address any further questions or concerns Nova builders and users may have. Additional questions can be submitted here.\nFAQ​\nWhat exactly is changing on January 31, 2026?​\nThe following third-party tools will no longer be supprted for Arbitrum Nova:\n\nAlchemy\nNova Arbiscan nova.arbiscan.io\nTenderly\n\nThese changes apply only to Nova-specific environments and do not affect Arbitrum One or other Arbitrum chains.\nDoes this impact my funds or assets on Arbitrum Nova?​\nUser funds and onchain assets on Arbitrum Nova are not affected. All assets on Arbitrum Nova remain accessible and withdrawable regardless of the tooling change.\nWill existing Nova applications continue to function?​\nYes, continued building is supported, provided that a migration away from deprecated tooling is completed and infrastructure dependencies are updated as required. Reliance on the aforementioned services should be reviewed, and a transition to alternative providers should be completed before January 31, 2026.\nWho can I contact if there are issues or questions I need addressed?​\nPlease reach out with additional questions here.Arbitrum public RPC endpointsThird-party RPC providersSequencer endpoint behaviorThe two endpoints at a glanceLatency and timeout behaviorRecommended fallback patternsMonitoring and alertingChain parametersCurrent gas targetsFaucet listArbitrum Smart Contract AddressesProtocol smart contractsCore contractsCross-chain messaging contractsFraud proof contractsToken bridge smart contractsCore contractsPrecompilesMiscCanonical factory contractsNova-specific toolingFAQ","tokens":3153,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257808673,"hash":"1a2c8efc270ece123a4f52ff7788c997b2b36cdb"}
{"url":"https://docs.arbitrum.io/notices/arbos51-upgrade-notice","domain":"docs.arbitrum.io","title":"Upgrade notice for ArbOS 51 | Arbitrum Docs","text":"✏️Request an updateArbOS 51 \"Dia\" will be activated on the Arbitrum Sepolia, Arbitrum One, and Arbitrum Nova chains.\nActions required for node operators​\nAction requiredArbitrum node operators must upgrade to Nitro v3.9.6 ahead of ArbOS 51 activation to continue syncing the chain.\nDocker image: offchainlabs/nitro-node:v3.9.6-91bf578\nRelease notes: https://github.com/OffchainLabs/nitro/releases/tag/v3.9.6\n\nImportant dates​\nThe following dates are relevant for Arbitrum chain operators.\nDateNetwork upgradeAffected audienceDec 1st 2025, 17:00:00 UTCArbitrum Sepolia upgrade to ArbOS 51Node operators for Arbitrum SepoliaJan 8th, 2026, 17:00:00 UTCArbitrum One/Nova upgrade to ArbOS 51Node operators for Arbitrum One/Nova\nContext​\nArbOS 51 \"Dia\" builds upon ArbOS 40 \"Callisto\" with support for the relevant EVM changes that are a part of Ethereum's Fusaka upgrade, as well as additional improvements to the gas pricing algorithm, a change to the min L2 base fee, MaxTxGasLimit allowing full block utilization, changes to instrument Nitro’s State Transition Function (STF) to price gas based on specific resource usage, native token mint/burn capabilities, and a few bug fixes.\nUpstream governance items (ArbOS 50 + Gas Target & Pricing Framework) were bundled into a single ArbOS 51 onchain vote. Both components have passed Snapshot temperature checks, and the bundled Tally vote was passed December 18, 2025.Actions required for node operatorsImportant datesContext","tokens":367,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257830581,"hash":"08a6d2db50335d819ab26b24343e5cda9a1f4cb9"}
{"url":"https://gov.optimism.io/t/season-9-final-report/10685/10","domain":"gov.optimism.io","title":"Season 9 Final Report - Grants 🔴 / Grants Updates - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Grants 🔴Grants Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n May 23\n\n 10 / 10\n\n Sep 22\n\n 13d ago\n\n post by Gonna.eth on May 23\n\n post by alexsotodigital on May 23\n\n 23 days later\n\n post by JulianCross on Jun 16\n\n post by Gonna.eth on Jun 16\n\n post by MconnectDAO on Jun 16\n\n 11 days later\n\n post by JulianCross on Jun 27\n\n post by MconnectDAO on Jun 28\n\n 12 days later\n\n post by JulianCross on Jul 11\n\n JulianCross\n\n @MconnectDAO That is the exact right question. Data without a governance hook is just vanity metrics.\nTo ensure this Autopsy does not become a forgotten artifact, the mandate must include a “Season 10 Integration Clause.”\nThe final deliverable will not just be a passive Dune Dashboard. It will include an actionable “Season 10 Baseline Criteria Matrix.” This matrix will translate the raw S9 data (TVL retention, fee generation, active user stickiness) into strict performance thresholds.\nThe Execution Mechanism:\nBefore Season 10 officially opens, this Criteria Matrix is presented to the DAO for a snapshot vote. If ratified, it becomes binding code for the upcoming season’s RFP (Request for Proposal) process.\nFor example: Any returning S9 applicant must demonstrate they met the Baseline TVL retention metric from the Autopsy to be eligible for S10 funding. If they failed the metric, their new proposal requires a mandatory remediation plan.\nWe bridge the gap between data and execution by making the dashboard the literal Oracle that dictates S10 eligibility. It forces accountability directly into the allocation pipeline.\nIf the delegates are aligned with this level of structural enforcement, I can formalize the scope of work for this mandate.\n\n 2 months later\n\n post by Gonna.eth on Sep 22\n\n Gonna.eth\n\n @MconnectDAO fair ask, and I don’t have a good answer yet. For S8, OSO published an attribution-adjusted TVL impact analysis (S8 Grants Council Impact Analysis); as far as I know, no equivalent has been published for S9 yet. I don’t currently have a public per-intent impact table or a maintained Dune dashboard to point you to.\nOn tracking this going forward: with both the Grants Council and the Milestones and Metrics Council dissolved, the approved dissolution proposals state that remaining milestone monitoring moves to the Foundation via a third-party contractor arrangement, not to an informally commissioned mandate from this thread. If OSO or the Foundation are planning an S9 equivalent to the S8 analysis, that’s the channel I’d want this to go through.\n@JulianCross I appreciate the offer, but I’m not in a position to greenlight or fund an independent mandate here, and I’d be cautious about anyone committing budget through a forum reply rather than the normal RFP/Foundation process. If there’s a real need for this work, it should go through the Foundation given the Council no longer exists.\nUpdate: @brichis published an independent TVL impact review of Season 8 growth grants Season 8 Growth Grants - TVL Impact Review. It’s on-chain-only, targeted-contract ΔTVL. Closest thing to the per-intent impact data being asked for here, though scoped to S8 growth grants specifically, not all of S9.\n\n post by JulianCross on Sep 23\n\n JulianCross\n\n @Gonna.eth I appreciate the direct procedural clarity. You are absolutely correct; deploying treasury budget requires strict adherence to the formal Foundation RFP/procurement pathways, not forum handshakes.\nYour candid admission that there is currently no maintained Dune dashboard or per-intent impact table perfectly validates the structural data deficit we are discussing. The dissolution of the Councils has left a vacuum that must be filled by automated infrastructure.\nWith the DAO’s telemetry gap now explicitly confirmed, I will format this [RFC] architecture into a formal Foundation procurement submission to establish this tracking layer. Thank you for pointing the compass toward the correct administrative routing.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Big Picture: The Grants Council\n\n ✨ General\n\n For the past three seasons, the Grants Council has played a fundamental role in improving governance processes and in setting Optimism as one of the leading Layer 2 solutions. Its decisions have not only stimulated on-ch…\n\n read more\n\n 9\n\n 1.2k\n\n May 2024\n\n Season 6 Grants Council Final and Retrospective Report\n\n Grants Updates\n\n I want to extend my heartfelt thanks to the Foundation and all the Grants Council members for their hard work and dedication this season. A special mention goes to @Bunnic, who, despite not being an elected member, stepp…\n\n read more\n\n 18\n\n 1.2k\n\n Dec 2024\n\n Cycle 22 Final Grants roundup\n\n Grants Updates\n\n season-5,cycle-22\n\n We have reached the end of Season 5.\nSeason 5 has been a pivotal stress test for our Grants Program, especially with the Mission Requests Program. Despite facing significant challenges, the Grants Council has demonstrate…\n\n read more\n\n 24\n\n 6.6k\n\n May 2024\n\n Cycle 19: Final Grants Roundup\n\n Grants Updates\n\n season-5,cycle-19\n\n All mission requests from Cycle 19 have been fully reviewed. The overwhelming interest in contributing to the Optimism ecosystem has been truly remarkable, with a total of 314 applications received for 28 mission request…\n\n read more\n\n 20\n\n 4.2k\n\n Apr 2024\n\n Guide to Season 9\n\n Governance Design and Strategy 📐\n\n season-9\n\n Guide to Season 9\nSeason 9 begins on January 29th and runs through June 3rd. \nWe’re excited to embark on Season 9! Please read Season 9: From Experiment to Organization for additional context on Season 9 updates. Below w…\n\n read more\n\n 7\n\n 986\n\n Jul 15","tokens":1450,"squid":"ink-governance","role":"Council Listener","at":1791257833408,"hash":"139c511a0cd66a0c16a3d09c1723f17e7a9e8e6f"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/arbos40","domain":"docs.arbitrum.io","title":"ArbOS 40 Callisto | Arbitrum Docs","text":"✏️Request an updatecautionEIP-2537 is not enabled in ArbOS 40 Callisto. This means that the precompiled contracts for certain operations on the BLS12-381 elliptic curve are not supported. However, these precompiles will be proposed for inclusion in the next ArbOS release.\nThe minimum Nitro version that supports ArbOS 40 \"Callisto\" is Nitro v3.6.5, which is available on Docker Hub with the image tag offchainlabs/nitro-node:v3.6.5-89cef87. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova validators. For Arbitrum One and Nova, the ArbOS 40 \"Callisto\" upgrade required a governance vote to activate.\nPlease note that it is important to run Nitro v3.6.5 only against trusted databases. If you want to use an untrusted database, you can first remove the wasm directory if it exists (potentially inside the nitro folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. Avoiding unvalidated code is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker.\nThe Arbitrum docs will remain the canonical home for information regarding ArbOS releases, with more details found on the ArbOS Software Releases Overview page.\nAs a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the Arbitrum ArbOS upgrades. Please note that ArbOS 40 Callisto is an upgrade that builds upon ArbOS 32 Bianca.\nRequirements:​\n\nNitro v3.6.5 or higher\nnitro-contracts v3.1.0 or higher\nWASM module root: 0xdb698a2576298f25448bc092e52cf13b1e24141c997135d70f217d674bbeb69a\n\ncautionIf your chain is not ready to activate BoLD, please use nitro-contracts v2.1.3 instead; v3.0.0 or higher cannot be used without activating BoLD.\nHigh-level description of ArbOS 40 changes​\nArbOS 40 Callisto is an upgrade to enable Arbitrum's support for the parent chain Ethereum's Pectra upgrade scheduled for May 7, 2025 at epoch 364032. As a result, the majority of the ArbOS-specific changes revolve around implementing the relevant Prague EIPs on Arbitrum chains.\nPlease see below for the list of all changes included in ArbOS 40 Callisto:\nEIP-7702: Set EOA Account code​\nEIP-7702 introduces a new transaction type that allows Externally Owned Accounts (EOAs) to set executable code, adding account-abstraction functionality to EOAs such as delegation, batching, sponsorship, and privilege de-escalation. In terms of batching, multiple operations can be combined (i.e., token approval and token spend) in an atomic transaction. Transaction sponsorship or paymaster support is extendable to EOAs. Discrete permissioning is configurable using sub-keys.\nEIP-2537: Precompile for BLS12-381 curve operations​\ncautionThis EIP and its specified precompiles are part of ArbOS 40 Callisto but are not enabled. However, these precompiles will be proposed for inclusion in the next ArbOS release.\nThis EIP introduces precompiles for performing cryptographic operations on the BLS12-381 curve, focusing on enhancing the efficiency and security of these operations. This cryptographic primitive provides 120+ bits of security for operations over pairing-friendly curves, compared to the existing BN254 precompile, which offers only 80 bits of security. BLS signature verification is the primary use case for this EIP, although many other applications that rely on point additions, multiplications, and pairing operations stand to benefit from this proposal; examples include zkSNARKS, cross-chain interactions, randomness beacons, and vector commitments.\nEIP-2935: Serve historical block hashes from state​\nThis EIP proposes storing a wider window of block hashes in the storage of a dedicated system contract. Bundling historical block hashes within the state enables efficient data retrieval for applications that require extended access to historical block hashes, like stateless clients. If approved, ArbOS 40 will adapt this EIP to the L2 and store the same number of L2 block hashes that are generated in the time it takes for 8192 L1 blocks to build—this is approximately 27 hours' worth of L2 block hashes.\nMinor Stylus fix to correct caching behavior for contracts that do not exist (#2998)​\nCurrently, Stylus will cache results from calling account_code and account_code_size for a contract that does not exist. We would like to propose a fix to address this so that the call returns the correct information that properly reflects the latest state of the contract’s code or code size. This change will not increment the Stylus version, so re-activation of already deployed Stylus contracts is not required.\nPectra changes that are not included in the proposed ArbOS 40 Callisto Upgrade​\nSupport and implementation for the following EIPs are not planned to be part of ArbOS 40 Callisto:\n\nAll Ethereum Consensus Layer (CL) Pectra changes (EIP-6610, EIP-7002, EIP-7251, EIP-7549, EIP-7691) because Arbitrum chains do not have a beacon chain and therefore do not have a peer-to-peer layer like Ethereum does.\nEIP-7623: Increase calldata cost: because block size variance is less of a concern on Arbitrum chains. This lack of support is due to two reasons: first, Arbitrum chains do not require nodes to send blocks over the network through their peer-to-peer layer; instead, they rely on the parent chain’s RPC to retrieve block data. Secondly, because Arbitrum block sizes are already limited to ~100KB, so increasing calldata cost is not expected to reduce Arbitrum block sizes.\nEIP-7685: General purpose execution layer requests: because Arbitrum chains do not have a beacon chain and, therefore, there is nothing to request from the EL on Arbitrum chains.\nEIP-7840: Add blob schedule to EL configuration files: because Arbitrum chains do not support posting blobs on the rollup (but otherwise still does support posting blobs to Ethereum L1).\n\nSpecial note about ArbOS 40 Callisto for chains who have not yet upgraded to use Arbitrum BoLD​\nWhile ArbOS 40 Callisto will be compatible with both nitro-contracts 3.1.0 and nitro-contracts 2.1.3, only chains that have Arbitrum BoLD enabled can use nitro-contracts 3.x. This requirement means that if your chain has not yet upgraded to use BoLD, please only use nitro-contracts 2.1.3 for your ArbOS 40 Callisto upgrade.\nReference links for ArbOS 40 Callisto​\n\nNitro v3.6.5\nnitro-contracts v3.1.0\nnitro-contracts v2.1.3 (only relevant for Arbitrum chains that do not have BoLD enabled yet)\nREADME for how to upgrade your rollup contracts to support ArbOS 40 on your chain\nAIP: ArbOS Version 40 Callisto Forum Post\nTemperature check vote on Snapshot for ArbOS 40 Callisto\nArbOS 40 Audit Report, from Trail of Bits\nRequirements:High-level description of ArbOS 40 changesEIP-7702: Set EOA Account codeEIP-2537: Precompile for BLS12-381 curve operationsEIP-2935: Serve historical block hashes from stateMinor Stylus fix to correct caching behavior for contracts that do not exist (#2998)Pectra changes that are not included in the proposed ArbOS 40 Callisto UpgradeSpecial note about ArbOS 40 Callisto for chains who have not yet upgraded to use Arbitrum BoLDReference links for ArbOS 40 Callisto","tokens":1783,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791257840896,"hash":"b12b519284e21203b9059f8a89cc70dd7d1637df"}
{"url":"https://gov.optimism.io/t/big-picture-the-grants-council/8154","domain":"gov.optimism.io","title":"Big Picture: The Grants Council - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Big Picture: The Grants Council \n\n ✨ General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 8\n min\n\n May 2024\n\n 1 / 10\n\n May 2024\n\n May 2024\n\n post by SEEDGov on May 15, 2024\n\n SEEDGov\n\n For the past three seasons, the Grants Council has played a fundamental role in improving governance processes and in setting Optimism as one of the leading Layer 2 solutions. Its decisions have not only stimulated on-chain activity but also promoted an open and collaborative ecosystem.\nAs part of the Optimism Collective, we recognize that gathering data, often scattered across the forum, is essential for delegates, citizens, and community members to understand the importance of governance processes and their mechanisms, as well as the relevance of the involved organisms and their significance in achieving The Optimistic Vision.\nWith this purpose, we present this document, which compiles public forum data in an organized manner, providing a chronological, quantifiable, and cohesive perspective on the work and impact of the Grants Council on Optimism. We hope that the detailed information here offers delegates and new participants a clear view of the current state of governance and the influence of the Grants Council over the past three seasons. Furthermore, we aim to facilitate decision-making and participation in future metagovernance changes, and to enrich feedback during the pre-season 6 reflection period.\nAnd as always, stay optimistic!\nDisclaimer\nThis is a data collection effort to gain a broader understanding of one of the most significant organism within Optimism’s governance. If you find any error, please notify it.\nGrants Council Retrospective: A Brief Historical Overview\ndoge venecia grants council1745×1161 170 KB\nThe story of the Optimism Grants Council began during the Reflection Period just before Season #3, at a time when Optimism’s governance was taking its initial steps. The Optimism Foundation, aware of the challenges facing the governance structure—ambiguous processes, delegate workload overload, and underlying conflicts of interest—decided to introduce an innovative reform: The Grants Council.\nDuring Special Voting Cycle #9a, the Token House approved the incorporation of the Grants Council and elected its first 8 members. They were organized into two subcommittees: Builders and Growth Experiments. While the members were part of the community, the Council leader was selected directly by the Foundation, an external figure with a primarily administrative role and no voting rights on grant approvals.\nSince its beginning, the Grants Council has focused on operational efficiency and transparency. Its main objective was to streamline the proposal selection process, creating a more predictable environment for proposers and setting a regular rhythm in fund distribution. Clear scopes were set, distinguishing Partner Fund operations and improving accountability through milestone-based distributions and smaller-sized grants. This approach not only improved Governance Fund management but also eased the workload of delegates, allowing them to focus on other governance areas.\nToday, the Grants Council continues its initial approach but has evolved to play an even more multifaceted role within Optimism’s governance. With the expansion to three subcommittees—Builders, Growth Experiments, and Milestones and Metrics—and a total of 13 members. This reflects the Optimism Collective’s ongoing commitment to efficient and responsible fund allocation, essential for the sustainable development of the ecosystem.\nThis strategic effort to integrate the grants process within the broader Token House governance framework not only underscores the Council’s commitment to continuous improvement but also ensures a lasting impact on strengthening and growing the Optimism ecosystem.\nYou can read more about the Council Structure, Goals and Responsibilities here.\nGrants Council: The Journey of Growth in Optimism\nSeason #3: Habemus Grants Council\n21920×1641 172 KB\nIn this season, the Grants Council came to life, its foundations were laid and its first members were elected. It’s worth noting that in its early days, the Grants Council was titled as a governance experiment.\nThe Grants Council was led by danelund.eth and the committees made up of:\n\nBuilders: Gonna.eth, Kaereste, Jack Anorak\nGrowth Experiments: Michael Vander Meiden, Katie Garcia, GFX Labs, Matt Losquadro, Doug Sugma\n\nBudget:\n\nThe Council budget: 5M OP\n\nThe Council Lead received a remuneration of 35k OP\nBuilders Sub- Committee Budget: 850k OP + Compensation per member 14k OP\nGrowth Experiments Sub- Committee Budge: 4M OP + Compensation per member 14k OP\n\nSeason #4: Council Framework and Renewal\n41920×1641 177 KB\nIn this season, Token House voted to renew the Grants Council and its leader, approving the budget proposal for Intent #2, which was overseen by the Council. Additionally, members of each subcommittee were re-elected. It’s worth noting that new tasks were added for Council members, including managing RFG line of grants, communications, and operations.\nThe Grants Council was once again led by danelund.eth, with the committees comprised of:\n\nBuilders: Gonna.eth, Kaereste, Jack Anorak\nGrowth Experiments: Michael Vander Meiden, Katie Garcia, GFX Labs, Matt Losquadro, Doug Sugma\n\nBudget:\n\nThe Council budget: 5,285M OP + 12.5k USDC (budget operation). An extension of 2.5M OP was approved by reallocating leftover budget from Intents 1, 2, 3, and 4 of Season 4.\n\nThe Council Lead received a remuneration of 35k OP + 10k OP for the preparatory work during the weeks between Season 3 and Season 4.\nBuilders Sub- Committee Budget: 1M OP + Compensation per member 25k OP\nGrowth Experiments Sub- Committee Budge: 2M OP + Compensation per member 25k OP\nRFGs Budget: 2M OP + 5k OP manager\nOperation and Comms: 5k OP per manager\n\nSeason #5: Grants Council as Persistent Structures\nsisin 5 final coreegido1920×1094 145 KB\nIn Season 5, the Grants Council transitioned from an experiment to a persistent structure within the Optimism Collective, meaning its renewal is no longer subject to a vote. The Council leader is now also elected by delegates, and each candidate for leader must propose an operational budget to support Council operations. Additionally, the selected leader must propose budgets for all intents. In this season, the Council evaluates proposals for all intents, not just intent #2. Additionally, the Milestones and Metrics subcommittee was added.\nThe Grants Council started off led by danelund.eth, but later he stepped down and Gonna.eth took his place.\nThe committees were comprised of:\n\nBuilders: Gonna.eth, Kaereste, Jack Anorak, Mastermojo* and Joxes.eth\n\nGrowth Experiments: Michael Vander Meiden, Katie Garcia, GFX Labs, Matt Losquadro, MoneyManDoug\n\nMilestones and Metrics: Juanbug_PGov, v3naru_Curia and Mmurthy\n\nIn replace of Ethernaut.\n\nBudgets:\n\nThe Council Operating budget: 440k OP\n\nThe Council Lead 0 OP (This position will be rewarded only through retroPGF if it is rewarded for Season 5)\nBuilders Sub- Committee: 30k OP per member\nGrowth Experiments Sub- Committee: 30k OP per member\nMilestones and Metrics Sub- Committee: 25k OP per member\nOperation manager: 10K OP\nCommunications Manager: 5K OP\n40,000 OP were allocated for grants specifically designed to improve the operations of the Council (e.g., knowledge management platform, front-end, developer contributions, etc.)\n\nIntents Budget Proposal: 9M OP.\n\nIntent #1: 1.33M OP\nIntent #2: 4M OP\nIntent # 3: 1.33M\nIntent #4: 1.33M\n1 million OP were set aside for general allocation to any of the Intents.\n\nSummary\n\nThe Council Operating budget cumulative: 872K OP + 12.5k USDC\nBudget managed by the Council over the 3 seasons: 18325106 OP\n\nWith Great Power Comes Great Responsibility: The Grants Council by the Numbers\nA brief review of the numbers season by season.\ngrant coucnil in numbers1350×1726 479 KB\nSeason#3:\nThe Grants Council ran for two Cycles in Season 3: Cycle#10 and Cycle#11\nCycle#10: Jan 26th - March 1st:\n\n73 grants applicants\n\n26 were for Builders Grants,\n46 were for for Growth Experiments Grants\n1 was not updated to include a grant type\n\n22 Final Roundup:\n\nBuilders: 10 proposals for a budget of 335k OP Total.\nGrowth Experiments: 12 proposals for a total budget of 2133633 OP.\n\nTotal: 2468633 OP.\n\nCycle#11: March 2nd - April 5th\n\n79 grants applicants\n\n29 were for Builders Grants\n50 were for Growth Experiments Grants\n\n26 Final Roundup:\n\nBuilders: 12 proposals for a total budget of 454K OP\nGrowth Experiments: 14 proposals for a total budget of 1615500 OP.\n\nTotal: 2069500 OP.\n\nSummary Season #3:\n\nTotal grants applicants: 152\nTotal grantees elected: 48\nTotal OP Tokens: 4538133\n\nSeason#4:\nThe Grants Council ran for three Cycles in Season 4: Cycle#13, Cycle#14, and Cycle#15.\nCycle 13: June 8th - July 12th\n\n106 total grants applicants\n\n58 were for Builders Grants\n48 were for Experiments Grants\n\n26 Final Roundup:\n\nBuilders 16 projects for a total of 612.5K OP\nExperiments 10 projects for a total of 1040500 OP\n\nTotal : 1653000 OP\n\nCycle 14: July 13th - August 16th\n\n97 total grants applicants\n\n51 were for Experiments Grants\n46 were for Builders Grants\n\n28 Final Roundup:\n\nBuilders 18 projects for a total of 589,4k OP\n\nExperiments 10 projects for a total of 935k OP\n\nTotal: 1524400 OP\n\nCycle 15: August 17th - September 20th\n\n104 total grants applicants\n\n54 were for Builders Grants\n50 were for Growth Experiments Grants\n\n23 Final Roundup:\n\nBuilders: 16 proposals for a total budget of 496,7K OP\nGrowth Experiments: 7 proposals for a total budget of 1205000 OP.\n\nTotal 1701700 OP\n\nRequests for Grants (RFG): These were specific grants that we did not include in the summary.\n\n72 total grants applicants\n17 proposal Final Roundup for a total budget of 1712000 OP\n\nSummary Season #4:\n\nTotal: 307 grants applicants\nTotal grantees elected: 94\nTotal OP Tokens: 6591100\n\nSeason#5\nThe Grants Council ran for two rounds in Season 5: Cycle 19 and Cycle 22. Season 5 ran from January 4, 2024, to May 8, 2024. The Season will include two grant rounds:\n\nS5 Round 1: Feb 1st - Mar 28th\nS5 Round 2: Mar 14th - May 8th\n\nCycle#19:\n\n314 applications were received for 28 mission requests.\n43 propuestas Final Roundup\n\n5 proposal for Intent 1 - 225k OP\n18 proposal for Intent 2 - 1155000 OP\n14 proposal for intent 3 - 1055000 OP\n6 proposal for intent 4 - 119k OP\n\nTotal: 2554000 OP\n\nCycle#22:\n\n234 grants applications\n87 Final Roundup:\n\n12 proposal for Intent 1 - 640k OP\n46 proposal for Intent 2 - 2288984 OP\n23 proposal for Intent 3 - 1514390 OP\n6 proposal for Intent 4 - 123500 OP\n\nTotal allocated: 4566874 OP\n\nSummary Season #5:\n\nTotal grants applicants: 548\nTotal grantees: 130\nTotal OP Tokens: 7120874 OP\n\nSummary\nImagen 15-5-24 a las 16.552652×570 248 KB\nAbove, we can see the total number of applications per cycle and per season, along with those that advanced to the Final Roundup. Additionally it shows the approved budget by the Foundation for each season, as well as the total OP allocation per cycle, specifically for the Builders and Growth subcommittees, along with the allocation for RFG. It also shows the total budget that was allocated and any leftover funds that were returned to the Gov Fund.\nSeason #1 to #5 totals664×411 9.65 KB\nThis chart displays the total number of applications and those that reached the Final Round throughout the grants process, from Cycle 10 in Season 3 to Cycle 22 in Season 5.\nBUDGET1680×945 63.3 KB\nThis graph shows the budget of the Grants Council across its three active seasons, delineating the approved budget for each season, the total allocated amount per season, and the funds returned to the Gov Fund treasury at the conclusion of each season.\nThe introduction of the Grants Council within the Optimism Collective has proven highly beneficial for governance. Since its beginning, we have observed significant changes in fund distribution. In the first two seasons, before the Council was established, fund distribution was disorganized with large amounts of OP tokens allocated to a limited number of applicants. However, with the implementation of the Council in Season 3, the situation improved dramatically: the number of applicants increased by 261.9%, and the number of beneficiaries rose by 54.8%.\nIn Season 4, we continued to see progress, with a 101.9% increase in the number of applicants and a 60.41% increase in beneficiaries. The allocated funds increased moderately, by 7.5% compared to Season 3. The positive trend continued in Season 5, where the number of applicants grew by 78.5% and beneficiaries by 68.9%. Additionally, the allocated funds also increased by 47.48% compared to the previous season. It is worth mentioning that in latest season the Grants Council evaluated both the Grants Program and Mission Requests Program.\nRegarding the budget, we can see that each season a portion of the initially approved budget has not been allocated and it was returned to the Government Fund Treasury. This suggests that funds are allocated meticulously and responsibly, avoiding exceeding the initially assigned budget. Similarly, when it was necessary to allocate more budget, such as in Season 4, it was increased by 2.5 million.\nDuring Cycle 19, out of the 314 applications the Grants Council received, 252 were evaluated by 2 randomly selected reviewers based on the respective subcommittee involved, following the specified rubric. After passing the intake filter, approximately 40 proposals were ultimately approved, including 31 for the builders subcommittee and 12 for the Growth subcommittee. Meanwhile, in Cycle 22, the Grants Council received 234 applications. Out of these, 37 applications were declined during intake, leaving 197 to be evaluated by two randomly selected reviewers, depending on the subcommittee handling the mission request. Among these, 64 proposals were assigned to the builders subcommittee and 26 to the Growth subcommittee. This data was gathered from the Optimism GovFund Grants: Public Delivery Tracking. We would like to highlight the work of the reviewers:\n\nNote:\n\nIn Season #4, the Request for Grant (RFG) was introduced, with approximately 77 applicants, 17 of whom were approved, and 1,712,000 OP tokens allocated. The RFG administrator was @jackanorak.\n\nA Positive Rhizome:\n\nThe total number of applications for Cycle 13 was ~34% higher than for Cycle#14\n\nDuring S4, the Cycle#13 had a 24.5% grant rate vs 33.8% for Season 3\n\nCompared to Season 4 (306 applications) Season 5 experienced an astonishing 73.2% growth\n\nApplications:\n\nThere’s been a 196,20% more grants applicants in Season#5 than Season#3\nThe increase in the number of applications between Cycle 10 and Cycle 11 is approximately 8.22%.\nThe increase in the number of applications between Cycle 11 and Cycle 13 is approximately 34.18%.\nDuring Cycle 14 compared to Cycle 13, there was a decrease of 8.49% in applications.\nThe percentage increase in the number of applications between Cycle 14 and Cycle 15 is approximately 7.22%.\nThe percentage increase in the number of applications between Cycle 15 and Cycle 19 is approximately 201.92%.\nBetween Cycle 19 and Cycle 22, there was a decrease of 25.48% in the number of applications.\n\nBudget:\n\nThe Cycle 22 allocated the highest budget, around 4,566,874 OP, which represents an increase of approximately 85% compared to the initial Cycle 10 budget of 2,468,633 OP.\n\nWe share this document with a little more insight in percentages such as pass rates, budget and applications between cycles.\nConclusion: A few optimistic ideas\nThe purpose of this data collection was to snapshot, in a single post, the impact of the Grants Council and its importance within governance. We believe it’s important for delegates and community members to understand the work and positive impact of these entities driving the Optimism collective.\nThat’s why we’d like to contribute some ideas that came up while working on this report:\n\nJust like this post by @gonna.eth, we believe that Audit Requests should have a dedicated subcommittee for evaluation and closer approach to protocols and auditors. We also suggest that this subcommittee have its own framework, schedule and timeline.\n\nAs we saw, the number of applicants increases each season, and to maintain this momentum while assisting diverse groups of developers, communities, and protocols in applying to the Grants Program and Mission Requests Program, we suggest establishing a broader marketing and communications task force. Perhaps @katie, who led communications for the Grants Council, can provide insights on whether this makes sense.\n\nWe also believe that a working group could be established to provide initial feedback on proposals; this group would ensure that proposals meet the template and established requirements. The idea of this group is to alleviate the workload of reviewers.\n\nThese are just a few suggestions that we’re sharing so we can continue iterating together.\nAdditional resources\nGrants Council charmverse - Season #3\nGrants Council charmverse - Season#4\nGrants Council charmverse- Season#5\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Season 6 Grants Council Operating Budget Proposal\n\n Optimism Forum Weekly Recap (May 13, 2024 - May 19, 2024)\n\n Optimism Gov Summary\n\n Grants Council Wider Picture (Season 6 & 7)\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 8\n min\n\n post by Gonna.eth on May 15, 2024\n\n post by Liliop.eth on May 16, 2024\n\n post by CosmicKi on May 16, 2024\n\n post by lavande on May 16, 2024\n\n post by Liliop.eth on May 16, 2024\n\n post by Gonna.eth on May 17, 2024\n\n post by SEEDGov on May 17, 2024\n\n post by SEEDGov on May 17, 2024\n\n post by lavande on May 17, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [FINAL] Season 4: Council Intent Budget Proposal\n\n Delegates 🏛\n\n season-4\n\n S4 Intent: Innovate on Novel Applications (Intent 2) \n\nProposed Intent Budget: 5.285mm OP \n\nProposed Council Lead: Lund Ventures (Dane Lund) \n\nContact info: danelund.eth \n\nPlease link to any previous work or qualific…\n\n read more\n\n 31\n\n 5.5k\n\n Aug 2023\n\n [DRAFT PROPOSAL]: Moving to a Grants Council\n\n Reflection Period Proposal\n\n Please read Guide to Season 3: Course Correcting for full context before reading this proposal. The Grants Council will be voted on by the Token House in Special Voting Cycle #9a. \nAs outlined in Guide to Season 3: Cours…\n\n read more\n\n 45\n\n 8.1k\n\n Dec 2022\n\n [Special Voting Cycle #9a]: Grants Council\n\n Reflection Period Proposal\n\n As outlined in Guide to Season 3: Course Correcting, the current Governance Fund grants process faces significant challenges. Luckily, there is a lot of room for optimization. Some goals for Season 3 include: \n\ncreating …\n\n read more\n\n 17\n\n 10.8k\n\n Jan 2023\n\n Season 6 Grants Council Final and Retrospective Report\n\n Grants Updates\n\n I want to extend my heartfelt thanks to the Foundation and all the Grants Council members for their hard work and dedication this season. A special mention goes to @Bunnic, who, despite not being an elected member, stepp…\n\n read more\n\n 18\n\n 1.2k\n\n Dec 2024\n\n Cycle 22 Final Grants roundup\n\n Grants Updates\n\n season-5,cycle-22\n\n We have reached the end of Season 5.\nSeason 5 has been a pivotal stress test for our Grants Program, especially with the Mission Requests Program. Despite facing significant challenges, the Grants Council has demonstrate…\n\n read more\n\n 24\n\n 6.6k\n\n May 2024","tokens":4901,"squid":"ink-governance","role":"Council Listener","at":1791257843520,"hash":"07816290921bb06f82d9d2987a2f2dd7861b3cb2"}
{"url":"https://gov.optimism.io/t/guide-to-season-3-course-correcting/3942","domain":"gov.optimism.io","title":"Guide to Season 3: Course Correcting - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Guide to Season 3: Course Correcting \n\n Communications 📣Delegates 🏛\n\n season-3\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 27\n\n Nov 2022\n\n Jan 2023\n\n post by system on Nov 8, 2022\n\n system\n\n There will be a session to discuss any and all of the below with the Foundation from 9:00 - 9:30am PST / 5:00 - 5:30pm GMT on Wednesday, November 9th. Recording from this session can be found here.\n\nWe’d like to start with a huge thank you to our tireless delegates. We appreciate all of your hard work and for being a part of our iterative governance experiments to date. We know it’s not easy to be the first to try something.\nEach Season is an experiment as the Collective iterates toward its final governance design. Community feedback has surfaced many learnings during Season 2, and Season 3 is an opportunity to course correct in the face of some hard truths:\n\nDelegate Overload: Delegates are overloaded with proposals to vote on, which is leading to lower participation among some top delegates. Placing this level of demand on delegates does not position Token House governance to effectively scale. Ideally, the Token House would infrequently approve high importance decisions and serve as a check on the Citizens’ House. The Token House would not be voting frequently on granular decisions such as individual grant approvals.\n\nProposer Frustration: Proposers find the current grant process hard to navigate and are frustrated with conflicting feedback from delegates. Several protocols have gotten so frustrated that they’ve considered leaving the Optimism ecosystem to work with competitors.\n\nProtocol Participation: Protocols are frustrated by debates concerning self-delegation. Protocols are important stakeholders and should have a voice in governance, but delegates are understandably uncomfortable with protocols self-delegating grants to increase voting power.\n\nCommittee Conflict: Committees helped reduce non-committee member workload, but added complexity to the process and introduced additional confusion for proposers. Conflicts between committees contributed to a dramatic degradation in governance culture.\n\nCulture Concerns: Governance culture is not currently reflective of the Collective’s values. Governance conversations have been lacking in civility, respect, and positivity. There hasn’t been an enforceable code of conduct to address inappropriate delegate behavior, which has occurred frequently.\n\nLimited Accountability: The impact of Governance Fund grants has been disappointing so far. The pace of grant distribution has been aggressive and there is almost no accountability for grant recipients. There have been multiple examples of grant-related transactions well outside the scope of what was outlined in proposals.\n\nUndefined Scope: There has been limited guidance on the types of initiatives grants should support. This has led to the over-funding of less effective initiatives (like retroactive airdrops) and the under-funding of strategically important initiatives (like builder grants.)\n\nWhile we have challenges to overcome, delegates have also shown a remarkable dedication to Optimism and an impressive willingness to experiment. We’re extremely grateful to delegates (and their delegators!) for their dedication during the earliest stages of the Collective. It makes us incredibly optimistic about the future of Token House governance. Experimentation and iteration have been core to the vision for Optimism governance from the start. We didn’t expect to get things right on the first try, and it’s clear we’re ready for some big changes. The below docs outline several initiatives aimed at addressing the above challenges for Season 3.\n\nWe would appreciate community feedback on the following posts:\n\nDelegate Code of Conduct: An enforceable delegate code of conduct to restore a healthy governance culture\n\nGovernance Fund Charter: Guidance on the purpose and scope of the Governance Fund\n\nWe would appreciate community feedback on the following proposal drafts. Token House will vote on final drafts in Special Voting Cycle #9a:\n\nDraft Proposal: Moving to a Grants Council: A proposal to restructure the grants process to overcome the challenges faced by committees, improve the proposer experience, create accountability for grant recipients, and reduce delegate workload\n\nDraft Proposal: Protocol Delegation Program: A proposal to allow protocols to have a voice in governance without self-delegating grants\n\nIn recognition of the incredible work delegates have done in Seasons 1 & 2:\n\nRetroactive Delegate Rewards for Season 1 & 2: Retroactive rewards in recognition of the incredible work top active delegates have done\n\nThe next few weeks will follow the below schedule, as original outlined in Governance Update #4:\n\nNov 10 - Nov 16th: Off-Season for Committees to allocate the retroactive component of their compensation\n\nNovember 17th - December 7th: Reflection Period\n\nDec 8th - Dec 21st: Special Voting Cycle #9a (voting on grants council and protocol delegation program proposals)\n\nWe are making the following updates to the schedule following Special Voting Cycle #9a:\n\nDecember 22nd - Jan 4th: Holiday break\n\nJan 5th - January 18th: Special Voting Cycle #9b (any proposals contingent upon passing in Special Voting Cycle #9a). If Special Voting Cycle #9b is not necessary, Season 3 may start on January 5th\n\nJanuary 19th: Season 3 starts with Voting Cycle #10\n\n [DRAFT PROPOSAL]: Moving to a Grants Council\n\n Governance Weekly Recap\n\n [Special Voting Cycle #9a]: Grants Council\n\n [Special Voting Cycle #9a]: Protocol Delegation Program\n\n [DRAFT] [GF: Phase 1 Proposal] Optimistic Funding \n\n 2\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n Unlisted on Nov 8, 2022\n\n Listed on Nov 8, 2022\n\n Pinned globally on Nov 8, 2022\n\n post by linda on Nov 9, 2022\n\n post by polynya on Nov 9, 2022\n\n post by bobby on Nov 9, 2022\n\n post by lavande on Nov 9, 2022\n\n post by WellingtonOP on Nov 10, 2022\n\n post by Bobbay_StableLab on Nov 10, 2022\n\n post by Njonnart on Nov 12, 2022\n\n post by kinglee on Nov 12, 2022\n\n post by kinglee on Nov 12, 2022\n\n post by suwijak on Nov 14, 2022\n\n post by Griff on Nov 15, 2022\n\n post by Justin on Nov 15, 2022\n\n post by Jrocki on Nov 16, 2022\n\n post by Gonna.eth on Nov 16, 2022\n\n post by lavande on Nov 16, 2022\n\n post by andmus22 on Nov 17, 2022\n\n Load more posts below","tokens":1617,"squid":"ink-governance","role":"Council Listener","at":1791257853665,"hash":"8baee44323533c636b23fe38e3b834fe939f5424"}
{"url":"https://aave.com/app","domain":"aave.com","title":"App | Aave","text":"Aave AppBring Savings Back. Up to 7.25% APY1Get paid every second with global rates and Balance Protection21Includes base rate plus eligible boosts. Rates are variable and not guaranteed. Yield is generated by open lending markets. Capital is at risk. T&Cs apply.Skip the local ratesGet closer to your goalsAave is not a bank. It's built differently to unlock rates from global markets for everyone.6.00% APY + Boosts0.00%Fintech30.00%Banks30.00%7.25% is the current interest rate for Aave App. 0.38% is the national average interest rate for savings accounts as posted on FDIC.gov, as of August 17, 2026. Rates may vary.Simulate your savings.SimulationStarting AmountInvited Friend BoostRecurring ContributionsYou’re earning a base of 6.00% APY plus:for inviting friends.0.25% for $1,000+ recurring contributions.Future BalanceEarned in 30 years928.85K774.04K619.23K464.42K309.62K154.81K0Today30YSimulating a recurring The portion above $100,000 earns 4.50% APY.Compare your Future Balance3.30% APY33.10% APY3Banks0.38% APY3Past performance is not a reliable indicator of future performance. Rates and yields are variable and not guaranteed. Yield is generated by underlying open lending markets and involves risk. T&Cs apply. Read our disclosures.Invite friends. Earn more.ReferralsYour RateSlide to see how much you could earn!0 Friends15 FriendsInitial Deposit$0Earned in 90 daysAssuming base and rewardsBase APY6.00%Friend Referral Boost ×$1,000+ Recurring Contribution0.25%Rates are subject to change. Learn more.Payment MethodsAdd money from anywhere.Connect to over 12,000 banks.4Your money, your rulesWithdraw anytime.Access your savings whenever you need.Compounding 24/7/365Every second counts.Your balance grows every second on Aave.Auto SaverComing soonAutomate your savings.Setup recurring deposits and reach your savings goals.Balance ProtectionYour funds are covered.Enroll in the program in just a few steps.Interest EarnedWeekly Summary+ $23.28Add MoneyFrom Chase 9302+ $500WithdrawalTo Nina Powell$50WithdrawalTo Chase Bank$20Add MoneyFrom Wells Fargo+ $250Interest EarnedMonthly Summary+ $75.20Track your ActivitySave your way.Track your savings activity and create healthy habits.Balance Protection for eligible customers, subject to terms and conditions. Not insurance. See the full terms in the app.$3.7TAll-time deposits230KAave monthly users$1BTotal interest earnedMarket data is fully public, anytimeAave UsersDeposit moneyDollars or any supported assets on Aave.BorrowersTake loansLock up more than they borrow, then pay interest into the pool.Earnings7.25%APYBuilt for safetySecured at every layer.Face ID, Account Recovery, 2FA, and trusted devices.AuditIndependently reviewedAudited by leading firmsIndependent audits including SOC 2 certification.FAQsAave App is a savings app designed to help you earn up to 7.25% per year — made up of a 6.00% Base Rate plus Boosts you can earn today — with Balance Protection for eligible balances and optional recovery features.Your funds are supplied to Aave, where they are lent to borrowers who pay interest — and you earn it. The interest earned is compounded every second. Aave is a battle-tested protocol that has facilitated more than $3 trillion in all-time deposits, and markets are overcollateralized — borrowers must deposit more than they borrow, meaning loans are backed by more value than is borrowed.The Aave App Savings Rate consists of a Base Rate (currently 6.00% per year) and any additional Rate Boosts you can earn on top, which can add up to a total of 7.25% per year. Rates are variable, not guaranteed, and depend on region and account eligibility, subject to terms and conditions. Market conditions may increase or decrease the Base Rate over time. The Base Rate will never be negative.Your account’s security is our top priority. Here are just a few of the many measures we take to make sure your funds remain secure:Balance Protection for eligible customers, subject to terms and conditionsIn the event you lose your password, we have an opt-in biometric recovery solution so you always have access to your fundsWe allow you to set up 2 factor authentication for signing in and account recoveryThe withdrawal whitelist function adds an extra layer of protection — transfers are only permitted to approved addresses, and adding a new address requires one-time passcode verificationOnly you have access to your funds, not Aave, not anyone elseOur entire codebase has been independently reviewed by nine third-party security firmsBalance Protection is an extra layer of protection for eligible balances held in the Aave App, subject to terms and conditions. It's designed to address certain loss events, such as security breaches or technology failures.Bring savings backUp to 7.25% APY and Balance Protection2Includes base rate plus eligible boosts. Rates are variable and not guaranteed. Yield is generated by open lending markets. Capital is at risk. T&Cs apply.Balance Protection for eligible customers, subject to terms and conditions. Not insurance. See the full terms in the app.3.25% is the advertised high-yield APY for eligible Cash App savings customers as posted on cash.app, as of August 25, 2026. 3.30% is the base APY for Wealthfront Cash Accounts as posted on wealthfront.com, effective January 30, 2026. 3.10% is the APY for SoFi Savings accounts with eligible direct deposit or qualifying deposits as posted on sofi.com, effective May 28, 2026. 0.38% is the national deposit rate for savings accounts as posted on FDIC.gov, as of August 17, 2026. Rates are variable and subject to change.Bank transfers are provided by Push by Aave Labs and other regulated partners. See full disclosures for details.","tokens":1428,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257854511,"hash":"77d8846f69f2685ce14b72a557b2ec327fc435a8"}
{"url":"https://gov.optimism.io/t/guide-to-season-3-course-correcting/3942/27","domain":"gov.optimism.io","title":"Guide to Season 3: Course Correcting - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n Nov 2022\n\n 27 / 27\n\n Jan 2023\n\n Jan 2023\n\n Load more posts above\n\n post by lavande on Nov 9, 2022\n\n lavande\n\n Call recording accessible here for those that couldn’t join: qkh-kaaj-ptw (2022-11-09 09:03 GMT-8) - Google Drive\n\n post by WellingtonOP on Nov 10, 2022\n\n WellingtonOP\n\n linda\n\n vamos trabalhar mais\n\n post by Bobbay_StableLab on Nov 10, 2022\n\n Bobbay_StableLab\n\n Even though season 2 felt like “ Two steps forward, one step backward” it’s important that we continue to experiment and see what works. I look forward to seeing the new changes implemented in Season 3, especially with an accountability committee.\n\n post by Njonnart on Nov 12, 2022\n\n Njonnart\n\n thanks for your work \n\n post by kinglee on Nov 12, 2022\n\n kinglee\n\n good job，thank you for your work\n\n post by kinglee on Nov 12, 2022\n\n kinglee\n\n good，Thank you for all of the work\n\n post by suwijak on Nov 14, 2022\n\n suwijak\n\n good job，thank you for your work\n\n post by Griff on Nov 15, 2022\n\n Griff\n\n Love the update! Thank you!\n\n post by Justin on Nov 15, 2022\n\n Justin\n\n polynya\n\n Big delegates have too much power. I have voted in every proposal because i care … but my tiny holdings are irrelevant compared to the handful of delegates that decide every vote. And those delegates effectively have lifetime power because there is no sunset on the delegation that users thoughtlessly sprinted through en route to claiming. I will continue to vote my own tokens, but just saying…\n\n post by Jrocki on Nov 16, 2022\n\n Jrocki\n\n govNERD\n\n BTW, props to whoever created the OP Governance Calendar, it has saved me so much time just being able to open up my personal calendar to see where we are vs searching in the forum and Discord\n\n post by Gonna.eth on Nov 16, 2022\n\n Gonna.eth\n\nIf the Grants council proposal is approved, will we vote the council members here: ?\n\nOr do we vote for council members at the start of season 3 here: ?\n\n post by lavande on Nov 16, 2022\n\n lavande\n\n Council elections would occur during Special Voting Cycle #9b\n\n post by andmus22 on Nov 17, 2022\n\n andmus22\n\n Thank U for clery informations \n\n post by rasmuky on Nov 18, 2022\n\n rasmuky\n\n Jrocki\n\n Governance calendar is great, thanks for the call out. I hadn’t noticed that.\nOne useful add would be the date / time of the snapshot so I can pull any $OP staked back to my wallet.\n\n post by Michael on Nov 20, 2022\n\n Michael\n\nTo me this is all a somewhat related issue. It would be great to find an incentive structure to funnel this un-delegated vote share into the delegates with the best track record.\n\n 17 days later\n\n post by yiren on Dec 8, 2022\n\n yiren\n\n 很自豪能成为 Optimism Collective 的一员！保持乐观，WAGMI！\n\n post by Gonna.eth on Dec 14, 2022\n\n Gonna.eth\n\n@lavande could you add the estimated end date of season 3, please?\n\n 24 days later\n\n post by Baki on Jan 8, 2023\n\n Baki\n\n thank for your good work\n\n 8 days later\n\n post by polarpunklabs on Jan 16, 2023\n\n polarpunklabs\n\n ’ * Delegate Overload: Delegates are overloaded with proposals to vote on, which is leading to lower participation among some top delegates. Placing this level of demand on delegates does not position Token House governance to effectively scale. Ideally, the Token House would infrequently approve high importance decisions and serve as a check on the Citizens’ House. The Token House would not be voting frequently on granular decisions such as individual grant approvals.’\nI have argued previously on these forums that the issue here is the tendency for delegates to be delegates across multiple protocols, becoming super delegates of a sort, almost as if it’s a job. When really it should be a quite localised role.\n\n post by hola on Jan 17, 2023\n\n hola\n\n Proud to be part of the Optimism\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Token House participation and incentives: an extended analysis\n\n Delegates 🏛\n\n season-4\n\n This is a shared effort of the @SEEDGov delegation composed by AxlVaz, CryptoChica, Jadmat.Eth-DefiLatam, Joxes and Netrim. \nSummary\nOptimism Token House has been active for 1 year going through five seasons facing numer…\n\n read more\n\n 19\n\n 3.2k\n\n Mar 2024\n\n Retroactive Delegate Rewards: Season 3\n\n Metagovernance\n\n season-3\n\n Retroactive Delegate Rewards: Season 3\nWe’d like to extend a huge thank you to our delegates for their continued dedication to experimentation and iteration. This Season, Token House experimented with a Grants Council an…\n\n read more\n\n 2\n\n 3.0k\n\n Apr 2023\n\n [Special Voting Cycle #9a]: Grants Council\n\n Reflection Period Proposal\n\n As outlined in Guide to Season 3: Course Correcting, the current Governance Fund grants process faces significant challenges. Luckily, there is a lot of room for optimization. Some goals for Season 3 include: \n\ncreating …\n\n read more\n\n 17\n\n 10.8k\n\n Jan 2023\n\n Season 2 Feedback Thread\n\n Feedback 💬\n\n season-2,feedback\n\n Creating a place for delegates and gov participants to provide constructive feedback on Season 2, ahead of the upcoming Reflection Period. The goal is to keep all of this feedback in one place and free up the #gov-genera…\n\n read more\n\n 39\n\n 5.1k\n\n Jan 2023\n\n Governance Update #6: Season 3 Reflections\n\n Governance Updates\n\n season-3\n\n Governance Update #6: Season 3 Reflections\nCan you believe Season 3 is coming to an end?! Voting Cycle 11 is ongoing through April 5th and we’ll soon enter into a Reflection Period. Reflection Periods are a time for dele…\n\n read more\n\n 7\n\n 2.6k\n\n Apr 2023","tokens":1394,"squid":"ink-governance","role":"Council Listener","at":1791257863892,"hash":"ecb95b029fab4e684198141764ca4e86e967a800"}
{"url":"https://aave.com/legal/app/terms-of-service","domain":"aave.com","title":"Aave App Terms of Service | Aave","text":"1. Introduction\n1.1 Parties\nThese Terms and Conditions of Use (hereinafter referred to as the \"Terms,\" \"Agreement,\" or \"Terms of Use\") constitute a legally binding agreement between you (hereinafter referred to as \"you,\" \"your,\" \"User,\" or \"End User\") and Aave Interfaces Ltd, its affiliates, subsidiaries, successors, and assigns (hereinafter collectively referred to as \"Aave Labs,\" \"Company,\" \"we,\" \"us,\" or \"our\"), governing your access to, use of, and interaction with the Aave App mobile application software and all associated and related services, features, content, applications, and functionality provided thereby (hereinafter collectively referred to as the \"Services,\" \"Application,\" \"App,\" or \"Platform\").\nIf you have joined the Aave App waitlist, you should read the Aave App Waitlist Supplemental Terms, available at /legal/app/waitlist-supplemental-terms, which form part of these Terms and Conditions.\n1.2 Scope of Agreement\nThis Agreement encompasses and incorporates by reference: (a) these Terms and Conditions of Use; (b) our Privacy Policy, available at /legal/app/privacy-policy; (c) any supplemental terms, conditions, policies, guidelines, or rules that may be posted publicly or made available through the Services from time to time; and (d) any additional terms to which you agree when using specific features, functionality, or third-party services accessible through the Platform (collectively, the \"Operative Agreements\").\n1.3 Arbitration and Class Action Waiver Notice\nIMPORTANT LEGAL NOTICE: PLEASE READ THIS ENTIRE AGREEMENT CAREFULLY, WITH PARTICULAR ATTENTION TO SECTION 17 (DISPUTE RESOLUTION, ARBITRATION, AND CLASS ACTION WAIVER). BY ACCEPTING THESE TERMS, YOU AGREE THAT, EXCEPT FOR CERTAIN SPECIFIED TYPES OF DISPUTES IDENTIFIED IN SECTION 17, ANY AND ALL DISPUTES, CONTROVERSIES, OR CLAIMS ARISING OUT OF OR RELATING TO THESE TERMS OR THE SERVICES SHALL BE RESOLVED EXCLUSIVELY THROUGH FINAL AND BINDING INDIVIDUAL ARBITRATION RATHER THAN IN COURT. YOU HEREBY EXPRESSLY AND YOU KNOWINGLY WAIVE YOUR RIGHT TO A TRIAL BY JURY, YOUR RIGHT TO PARTICIPATE AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS ACTION, COLLECTIVE ACTION, OR OTHER REPRESENTATIVE PROCEEDING. NOTWITHSTANDING THE FOREGOING, NOTHING IN THESE TERMS SHALL LIMIT OR AFFECT ANY STATUTORY OR MANDATORY CONSUMER RIGHTS THAT CANNOT BE WAIVED UNDER APPLICABLE LAW.\n1.4 Manifestation of Acceptance\nBy downloading, installing, accessing, or using any part of the Services, you hereby acknowledge that: (a) you have read, understood, and agree to be bound by this Agreement in its entirety; (b) you have the legal capacity and authority to enter into this binding contract; (c) you will comply with these Terms and all terms, conditions, restrictions, and obligations set forth herein; and (d) your use of the Services constitutes acceptance of this Agreement and formation of a binding contract between you and the Company. If you do not agree to all these Terms and all terms, conditions, and provisions of this Agreement, or if you do not possess the legal capacity or authority to enter into this Agreement, you are expressly prohibited from accessing, downloading, installing, or using the Services in any manner whatsoever, and you must immediately cease any and all use of the Platform and uninstall the Application from all devices under your control.\n2. ELIGIBILITY REQUIREMENTS AND REPRESENTATIONS\n2.1 Age and Legal Capacity Requirements\nThe Services are intended solely for use by individuals who have attained the age of majority in their jurisdiction of residence and who possess the legal capacity to enter into binding contracts under applicable law. If you are under the age of eighteen (18) years, or under the age of majority in your jurisdiction of residence, whichever is greater, you are strictly prohibited from accessing or using the Services. By accessing or using the Services, you represent, warrant, and covenant that you have attained the requisite age and possess the legal capacity to enter into this Agreement.\n2.2 Jurisdictional Restrictions\nCertain jurisdictions prohibit or restrict the use of blockchain-based services, digital asset transactions, or decentralized applications. You represent and warrant that: (a) you are not located in, organized under the laws of, or ordinarily resident in any jurisdiction where your use of the Services would be illegal, prohibited, or contrary to applicable law; (b) you are not subject to, nor are you owned or controlled by any person or entity that is subject to, any sanctions administered or enforced by the United States Department of the Treasury's Office of Foreign Assets Control (\"OFAC\"), the United Nations Security Council, the European Union, Her Majesty's Treasury, or any other governmental authority with jurisdiction over you or your activities (collectively, \"Sanctions\"); and (c) you are not identified on any list of prohibited or restricted parties, including without limitation OFAC's Specially Designated Nationals and Blocked Persons List, Consolidated Sanctions List, Sectoral Sanctions Identifications List, or any similar list maintained by any governmental authority.\n2.3 Restricted Jurisdictions\nWithout limiting Section 2.2, access to and use of the Services is prohibited for any person or entity that is located in, organized under the laws of, or ordinarily resident in any country or territory that is, or whose government is, the subject of comprehensive trade or economic sanctions, embargoes, or similar restrictions imposed or administered by the United States, the United Kingdom, the European Union, the United Nations, or any other applicable authority (collectively, the \"Restricted Jurisdictions\"). Such jurisdictions include, without limitation, Belarus, Côte d'Ivoire, Crimea, Cuba, Donetsk People's Republic of Ukraine, Iran, Iraq, Kherson region of Ukraine, Liberia, Libya, Luhansk People's Republic of Ukraine, Myanmar, North Korea, Russia, Sudan, Syria, Venezuela, Zaporizhzhia region of Ukraine, together with any other jurisdictions designated from time to time by the U.S. Department of the Treasury's Office of Foreign Assets Control (\"OFAC\"), the United Nations Security Council, the European Union, His Majesty's Treasury (UK), or any other competent sanctions authority. The Company reserves the right, in its sole discretion, to restrict, suspend, or terminate access to the Services if it reasonably suspects that you are located in, acting on behalf of, or otherwise associated with a Restricted Jurisdiction or a sanctioned person, or if you attempt to circumvent such restrictions through virtual private networks, proxies, or similar technologies. Any such measures shall be implemented using region-based or other technical methods consistent with applicable law and platform policies.\n3. DESCRIPTION OF SERVICES\n3.1 General Description\nThe Aave App is a self-custodial mobile application software platform that provides Users with a means to access and interact with blockchain networks and decentralized protocols through smart contracts, using distributed ledger technology (blockchain technology) and self-executing computer programs (smart contracts) to enable Users to engage in decentralized transactions without reliance on centralized intermediaries. The Platform functions as a user interface enabling seamless interaction with blockchain networks and smart contracts through an integrated embedded wallet solution that supports self-custody of digital assets.\n3.2 No Financial or Brokerage Services\nThe Services do not constitute, and the Company does not provide, a brokerage, exchange, payment service provider, financial intermediary, or investment advisory service. The Aave App merely enables user-initiated interaction with blockchain smart contracts on a self-custodial basis. All transactions are executed directly by the User through decentralized protocols outside of the Company's control.\n3.3 Smart Contract Functionality\nThe Services enable Users to engage directly with smart contracts deployed on various blockchain networks. You acknowledge and agree that:\n\n(a) Smart contracts are autonomous, self-executing computer programs that function according to programmed code and the consensus rules of their respective blockchain networks;\n(b) Smart contract execution and outcomes are determined solely by the code, data fed to code by oracles or similar third parties, and the state of the blockchain network at the time of execution; and\n(c) The Company makes no representations, warranties, or guarantees regarding the functionality, reliability, or outcome of any smart contract interaction.\n\n3.4 Blockchain Network Dependency\nThe functionality and availability of the Services depend on the performance and integrity of third-party blockchain networks. These decentralized systems are maintained by distributed networks of independent validators, miners, or node operators. The Company does not operate, control, or maintain any such networks and disclaims all responsibility for any outages, congestion, forks, failures, or disruptions that may affect the availability or operation of the Services.\n3.5 Self-Custodial Nature\nThe Services operate on a strictly self-custodial basis. This means that:\n\n(a) The Company never takes possession of, holds, or exercises control over any digital assets, tokens, private keys, or other assets or property of the Users;\n(b) Users retain full and continuous possession, custody, and control of their digital assets and private keys;\n(c) No fiduciary, agency, partnership, or trust relationship exists between the Company and any User; and\n(d) All transactions occur directly on a peer-to-peer basis between Users and third parties or between Users and blockchain-based smart contracts, without any intermediation by the Company.\n\n3.6 Embedded Wallet Technology\nThe Services incorporate embedded wallet technology that functions as follows:\n\n(a) The embedded wallet generates and stores cryptographic private keys locally and securely on your device using industry-standard encryption and security protocols. Private keys are never transmitted to or stored on the Company's servers;\n(b) All cryptographic operations, including transaction signing and authentication, occur locally on your device;\n(c) The Company has no ability to view, access, or recover private keys or seed phrases;\n(d) You may export or back up private keys or seed phrases at your sole discretion and risk;\n(e) Once exported, your private keys become vulnerable to unauthorized access, interception, or compromise, and the Company disclaims all liability for any resulting loss or misuse;\n(f) You must never share or disclose your private keys or seed phrases to any third party, including the Company; and\n(g) Loss or damage to your device without a secure backup may result in permanent and irretrievable loss of access to your assets. THE COMPANY EXPRESSLY DISCLAIMS ALL LIABILITY FOR ANY LOSS, THEFT, COMPROMISE, UNAUTHORIZED ACCESS, OR MISUSE OF PRIVATE KEYS OR SEED PHRASES THAT HAVE BEEN EXPORTED, EXTRACTED, REVEALED, OR TRANSFERRED FROM THE EMBEDDED WALLET. You assume complete responsibility and liability for the security and confidentiality of exported private keys.\n\n3.7 Information and Educational Content\nThe Services may include informational or educational materials related to blockchain technology, digital assets, or decentralized finance. Such content is provided solely for informational purposes and does not constitute financial, investment, legal, or tax advice, nor does it represent a recommendation or offer to engage in any particular transaction or strategy. Users are responsible for conducting their own due diligence and consulting qualified professionals before making any related decisions.\n4. USER OBLIGATIONS AND RESPONSIBILITIES\n4.1 Wallet and Key Security\nYou are solely responsible for the security of your embedded wallet, private keys, seed phrases, passwords, authentication credentials, and any devices used to access or control your digital assets. You must take reasonable measures to safeguard such information and devices from loss, theft, disclosure, or unauthorized access. The Company does not have and cannot obtain access to your private keys or wallet credentials under any circumstances, and cannot recover or restore digital assets that are lost, compromised, or become inaccessible. You acknowledge that any loss or compromise of your private keys or any device used to access or control those keys may result in the permanent and irreversible loss of your digital assets.\n4.2 Transaction Responsibility\nAll transactions initiated through the Services are executed directly on blockchain networks. Once submitted and confirmed, they are final and irreversible. You are solely responsible for verifying the accuracy of all transaction details, including recipient addresses, asset types, network parameters, and transaction amounts, before authorizing execution, and are solely responsible for the outcome of any transaction.\n4.3 App and Device Access\nYou are responsible for maintaining control over your device and access credentials used to interact with the Services. You must take reasonable steps to prevent unauthorized access to the Aave App and to promptly secure or discontinue use if you suspect your device, wallet, or credentials have been compromised. The Company shall bear no responsibility for losses resulting from your failure to maintain adequate device or access security.\n4.4 Accuracy of Inputs and Information\nYou are responsible for ensuring that all information, data, and parameters you provide through the Services are accurate, current, and complete. The Company is not responsible for any loss or error resulting from inaccurate, incomplete, or outdated information submitted by you.\n5. PROHIBITED ACTIVITIES AND CONDUCT\n5.1 Prohibited Activities\nYou expressly agree that you shall not, and shall not permit, cause, or enable any third party to, use the Services in any manner that violates this Agreement, any applicable law, regulation, or order, or the rights of any third party. Without limiting the generality of the foregoing, you agree that you shall not:\n\n(a) Engage in Unlawful or Fraudulent Activity. Use the Services for any unlawful, illegal, fraudulent, deceptive, or prohibited purpose, including but not limited to: (i) engaging in or facilitating money laundering, terrorist financing, fraud, theft, or any other financial crime; (ii) purchasing, selling, or distributing illegal goods or services, including narcotics, controlled substances, weapons, explosives, stolen property, counterfeit items, or contraband; (iii) evading, avoiding, or violating any applicable tax, sanctions, or regulatory requirements; (iv) harming or damaging any person or entity, or (v) infringing, misappropriating, or otherwise violating the intellectual property, privacy, publicity, or proprietary rights of any person.\n(b) Violate Sanctions or Regulatory Restrictions. Transact with, transfer assets to or from, or otherwise engage with any person, entity, or jurisdiction that is the subject of applicable trade or economic sanctions, export control laws, embargoes, or other governmental restrictions.\n(c) Interfere with or Exploit the Services. Attempt to access, disrupt, damage, or interfere with the operation, performance, or security of the Services or any blockchain network or system connected thereto, including but not limited to: (i) introducing, uploading, or transmitting any virus, worm, Trojan horse, malware, or other harmful code; (ii) circumventing or attempting to circumvent any access controls, authentication mechanisms, security measures, or technical safeguards; (iii) engaging in denial-of-service attacks, network flooding, or similar disruptive activities; or (iv) exploiting any bug, vulnerability, logic flaw, or unintended feature for personal gain or to the detriment of others.\n(d) Engage in Deceptive or Manipulative Conduct. Engage in any act or practice that is false, misleading, or deceptive, including but not limited to: (i) impersonating any person or entity, or misrepresenting your affiliation with any person or entity; (ii) providing false, inaccurate, or misleading information in connection with your use of the Services; or (iii) manipulating, falsifying, or misrepresenting data, transactions, or market activity in any way.\n(e) Use Unauthorized Automation or Data Extraction. Access, query, or interact with the Services through any automated means, including but not limited to bots, spiders, scrapers, crawlers, or data-mining tools not expressly authorized by the Company, or harvest, extract, or copy data or content from the Services without prior written consent.\n(f) Misuse or Abuse the Services. Use the Services in any manner that could: (i) damage, disable, impair, or overburden the Services or related systems; (ii) interfere with the access, use, or enjoyment of the Services by any other person; or (iii) use the Services for benchmarking, reverse engineering, competitive analysis, or the development of competing products or services.\n\n6. RISKS, DISCLAIMERS, AND ACKNOWLEDGMENTS\n6.1 Assumption of Risk\nBY ACCESSING AND USING THE SERVICES, YOU EXPRESSLY ACKNOWLEDGE, UNDERSTAND, ACCEPT, AND ASSUME ALL RISKS ASSOCIATED WITH:\n\n(a) Blockchain Technology Risks: The use of blockchain technology, distributed ledger technology, smart contracts, routers, cryptographic tokens, digital assets, digital asset wallets, and related technologies and systems;\n(b) Market Risks: The volatility, fluctuation, and unpredictability of digital asset prices, valuations, and market conditions;\n(c) Technical Risks: Software bugs, errors, defects, vulnerabilities, malfunctions, failures, and unintended consequences;\n(d) Security Risks: Cyberattacks, hacking attempts, phishing attacks, malware, security breaches, and unauthorized access;\n(e) Regulatory Risks: Changes in laws, regulations, policies, interpretations, or enforcement actions by governmental authorities; and\n(f) Operational Risks: Service interruptions, downtime, network congestion, and unavailability of the Services, applications and/ or underlying blockchain networks.\n\n6.2 Experimental and Speculative Technology\nYou acknowledge and agree that: (a) Blockchain technology, smart contracts, and digital assets represent novel, experimental, and speculative technologies that are subject to rapid change, evolution, and uncertainty; (b) The technology underlying the Services is in early stages of development and may not function as intended at all relevant times; (c) Smart contracts may contain bugs, errors, vulnerabilities, or design flaws that could result in loss of functionality, loss of assets, or unintended outcomes; (d) Blockchain networks may experience forks, chain reorganizations, consensus failures, or other disruptions that could affect the Services; (e) The regulatory treatment of blockchain technology and digital assets is uncertain, evolving, and varies significantly across jurisdictions; (f) Future developments in technology, markets, or regulations may render the Services obsolete, impractical, or illegal.\n6.3 Transaction Finality and Irreversibility\nYou expressly acknowledge and agree that: (a) All transactions executed on blockchain networks are final, irreversible, and immutable once confirmed by the network; (b) There are no refunds, cancellations, reversals, or chargebacks available for blockchain transactions, including transactions conducted using the Platform; (c) The Company cannot and will not reverse, cancel, refund, or modify any transaction under any circumstances; (d) You bear sole responsibility for verifying and confirming the accuracy of all transaction details before execution, including recipient addresses, amounts, token types, and network parameters; (e) Transactions sent to incorrect addresses, executed with incorrect parameters, or based on user error cannot be recovered, reversed, or corrected; (f) Digital assets sent to smart contract addresses, burned addresses, or addresses for which private keys are lost or inaccessible are permanently and irretrievably lost.\n6.4 Smart Contract Risks\nYou acknowledge and agree that: (a) Smart contracts are autonomous computer programs that execute according to their code without human intervention; (b) Smart contract execution depends on the accuracy of the code, the state of the blockchain, and the inputs provided by users; (c) Smart contracts may contain bugs, vulnerabilities, exploits, or design flaws that could result in total loss of assets; (d) Smart contracts may interact with other smart contracts or external data sources in unexpected or unintended ways; (e) Smart contract audits and security reviews, if conducted, do not guarantee the absence of vulnerabilities or the correctness of functionality; and (f) Economic attacks, game-theoretic exploits, or unintended incentive structures may result in smart contract failure or unexpected outcomes.\n6.5 Blockchain Network Risks\nYou acknowledge and agree that: (a) Blockchain networks are operated by decentralized networks of independent node operators, validators, or miners over whom the Company has no control; (b) Blockchain networks may experience congestion, high transaction fees, long confirmation times, or unavailability; (c) Blockchain networks may undergo forks, resulting in the creation of alternative chains that could affect the value or functionality of digital assets; (d) Consensus mechanisms may fail, resulting in chain reorganizations, double-spending, or other disruptions; (e) Blockchain networks may be subject to attacks, including but not limited to 51% attacks, Sybil attacks, denial-of-service attacks, or consensus attacks; (f) Changes to blockchain protocol rules, consensus mechanisms, or network parameters may affect the functionality or availability of the Services; (g) Blockchain networks may become deprecated, abandoned, or cease to operate.\n6.6 Third-Party Service Risks\nYou acknowledge and agree that: (a) The Services integrate with and depend upon third-party services, including wallet providers, blockchain networks, data providers, and infrastructure services; (b) The Company does not control, operate, endorse, or guarantee any third-party service; (c) Third-party services are subject to their own terms, conditions, policies, fees, and limitations; (d) Third-party services may experience outages, disruptions, changes, discontinuations, or security breaches; (e) The Company is not responsible for any acts, omissions, errors, or failures of third-party service providers; (f) You should review and understand the terms, risks, and limitations of all third-party services before using them.\n6.7 Digital Asset Value Volatility\nYou acknowledge and agree that: (a) Digital asset prices and values are highly volatile and subject to rapid, substantial, and unpredictable fluctuations; (b) Digital assets may lose all or substantially all of their value at any time; (c) Historical performance of digital assets is not indicative of future performance; (d) Digital asset markets are subject to manipulation, fraud, speculation, and irrational behavior; (e) Liquidity for digital assets may be limited, restricted, or unavailable, making it difficult or impossible to execute transactions at desired prices; (f) External factors, including regulatory actions, technological developments, market sentiment, and global events, may significantly impact digital asset values; (g) The Company provides no guarantees, representations, or warranties regarding the price, value, performance, or future prospects of any digital asset.\n6.8 Regulatory and Legal Uncertainty\nYou acknowledge and agree that: (a) The legal and regulatory status of blockchain technology, smart contracts, and digital assets is uncertain and varies significantly across jurisdictions; (b) Laws and regulations applicable to digital assets and blockchain technology are rapidly evolving and subject to change; (c) Future regulatory actions may prohibit, restrict, or impose requirements on the use of digital assets or the Services; (d) Tax treatment of digital asset transactions is uncertain and may change; (e) You are solely responsible for understanding and complying with all applicable laws and regulations in your jurisdiction; (f) The Company makes no representations regarding the legal or regulatory status of the Services or digital assets in any jurisdiction.\n6.9 No Professional Advice\nYou acknowledge and agree that: (a) The Services do not provide, and should not be construed as providing, any business advice, investment advice, financial advice, trading advice, legal advice, tax advice, accounting advice, or any other type of professional advice; (b) No content, information, or communication provided through the Services constitutes a recommendation, endorsement, or solicitation to buy, sell, hold, or trade any digital asset; (c) You should consult with qualified professionals, including financial advisors, tax advisors, and legal counsel, before making any decisions regarding digital assets; (d) You are solely responsible for conducting your own independent research, due diligence, and risk assessment; (e) The Company does not make any recommendations or provide any guidance regarding the suitability of any digital asset, transaction, or strategy for your particular circumstances.\n6.10 No Guarantees of Functionality or Availability\nYou acknowledge and agree that: (a) The Company does not guarantee that the Services will be available, accessible, uninterrupted, timely, secure, accurate, complete, or error-free at all times; (b) The Services may be unavailable due to maintenance, updates, technical difficulties, blockchain network issues, or circumstances beyond the Company's control; (c) The Company reserves the right to modify, suspend, discontinue, or terminate any or all of the Services at any time without notice or liability; (d) You should not rely on the continuous availability of the Services for time-sensitive or critical transactions; (e) The Company makes no representations or warranties regarding the performance, functionality, reliability, or suitability of the Services for any particular purpose.\n7. FEES, COSTS, AND CHARGES\n7.1 Blockchain Fees\nAll transactions or interactions executed through the Services are subject to fees, costs, and charges imposed by blockchain networks or smart contract protocols (\"Blockchain Fees\"). Blockchain Fees may include, without limitation, network transaction fees (commonly referred to as gas or miner fees), validator fees, protocol-level deductions, or other costs and fees determined autonomously by the applicable blockchain or smart-contract logic, including smart contract vault extensions.\n7.2 App Fees\nThe App does not offer, sell, or unlock any digital goods, tokens, or services through payment mechanisms other than those expressly permitted by Apple's App Store policies. Any blockchain or smart-contract transactions executed by you occur entirely outside of Apple's billing infrastructure, are user-initiated, and do not constitute in-app purchases of digital content or services under Apple's definitions.\n8. INTELLECTUAL PROPERTY RIGHTS\n8.1 Ownership of the Services\nAll rights, title, and interest in and to the Services, including all intellectual property rights, are and shall remain the exclusive property of the Company and its licensors. This includes, without limitation, all software, code, algorithms, data structures, system architecture, interfaces, trademarks, service marks, trade names, logos, designs, text, graphics, images, audiovisual materials, compilations, databases, methods, processes, and any enhancements, modifications, or derivative works thereof. Nothing in this Agreement shall be construed as transferring or granting any ownership interest in or to the Services or any intellectual property rights associated therewith. You acknowledge that the Services and all related technology constitute valuable trade secrets and proprietary information of the Company and its licensors, protected by copyright, trademark, patent, and other intellectual property laws and international treaties.\n8.2 Limited License\nSubject to your continued compliance with this Agreement, the Company grants you a limited, personal, non-exclusive, non-transferable, non-sublicensable, and revocable license to access and use the Services solely for your own purposes. This license does not grant you any right to copy, reproduce, distribute, publicly perform, modify, translate, adapt, reverse engineer, decompile, disassemble, or create derivative works from the Services, nor to sell, rent, lease, sublicense, or otherwise commercially exploit the Services or any portion thereof. You shall not remove, obscure, or alter any copyright notices, proprietary legends, or trademark designations displayed in or on the Services, nor use any Company trademarks, logos, or branding without prior written consent. Any unauthorized use, reproduction, or distribution of the Services or related materials may result in civil and criminal penalties under applicable law.\n8.3 Restrictions on Use\nYou agree not to use, access, or attempt to use the Services or any content therefrom for any purpose other than as expressly permitted by this Agreement. Without limitation, you shall not reproduce, mirror, frame, embed, or otherwise incorporate any part of the Services into another product or service; use any data mining, scraping, or automated methods to extract data or content; or access the Services for the purpose of monitoring their performance, availability, or functionality, or for benchmarking or developing competing products. All rights not expressly granted to you herein are reserved by the Company and its licensors.\n8.4 Feedback and Suggestions\nIf you submit to the Company any feedback, suggestions, comments, ideas, improvements, or recommendations regarding the Services (\"Feedback\"), you hereby grant to the Company a perpetual, irrevocable, worldwide, royalty-free, fully paid-up, transferable, and sublicensable license to use, reproduce, modify, adapt, publish, distribute, and display such Feedback in any form or medium now known or hereafter developed, without attribution or compensation to you. You represent and warrant that you have all necessary rights to provide such Feedback and acknowledge that the Company shall have no obligation to use, implement, or respond to it.\n9. PRIVACY AND DATA PROTECTION\n9.1 Privacy Policy Incorporation\nYour use of the Services is subject to the Privacy Policy, which is incorporated into this Agreement by reference and available at /legal/app/privacy-policy. By using the Services, you acknowledge that you have read, understood, and agree to the collection, use, storage, and disclosure of your information as set forth in the Privacy Policy.\n10. TAX OBLIGATIONS AND REPORTING\n10.1 Tax Responsibility\nYou acknowledge, understand, and agree that you are solely, entirely, and exclusively responsible for determining, understanding, calculating, reporting, and paying any and all taxes, duties, levies, assessments, or other governmental charges (\"Taxes\") that may arise from or relate to your use of the Services, your digital asset activities, or any transactions carried out through or in connection with the Services. The Company has no involvement whatsoever in determining, withholding, collecting, reporting, or remitting any Taxes on your behalf. You are solely responsible for ensuring full compliance with all applicable tax laws, regulations, and reporting obligations in every relevant jurisdiction, including maintaining adequate records of your transactions, determining the character, source, and timing of taxable events, and remitting all applicable Taxes to the appropriate authorities. You should seek advice from qualified tax professionals regarding your specific situation. The Company does not provide tax advice, tax guidance, or tax opinions of any kind. The Company makes no representations or warranties regarding the tax treatment, classification, or consequences of any transaction, yield, staking reward, or other digital asset activity carried out through or in connection with the Services. All information provided through the Services is for general informational purposes only and should not be relied upon for tax purposes. You further acknowledge that the tax treatment of digital assets, blockchain transactions, and decentralized finance activities is uncertain, evolving, and may vary significantly across jurisdictions and over time. Any changes in law, regulation, or interpretation may affect your tax obligations, and it is your responsibility to remain informed and compliant.\n10.2 Indemnification for Tax Liabilities\nYou agree to indemnify, defend, and hold harmless the Company, its affiliates, and their respective officers, directors, employees, contractors, and agents from and against any and all claims, liabilities, damages, losses, penalties, fines, interest, costs, and expenses (including reasonable attorneys' fees) arising out of or related to: (a) your failure to determine, report, or pay any Taxes; (b) your failure to comply with applicable tax laws or reporting obligations; (c) any claim, demand, or assessment by any tax authority alleging that the Company is responsible for or liable for your Taxes; or (d) any penalties, enforcement actions, or liabilities imposed as a result of your tax non-compliance.\n11. DISCLAIMERS OF WARRANTIES\n11.1 \"AS IS\" and \"AS AVAILABLE\" Basis\nThe Services, including all interfaces, functionality, and any access to blockchain networks or smart contracts, are provided by the Company on an \"AS IS\" and \"AS AVAILABLE\" basis, except as otherwise required by applicable law. To the fullest extent permitted by law, the Company and its affiliates, contractors, service providers, and licensors (collectively, the \"Aave App Indemnified Parties\") disclaim all warranties—express, implied, statutory, or otherwise—including any implied warranties of merchantability, fitness for a particular purpose, non-infringement, accuracy, reliability, or availability. Nothing in this Agreement affects any legal rights or remedies that cannot be excluded under applicable consumer-protection laws in your jurisdiction.\n11.2 No Warranty of Continuous Operation or Error-Free Functionality\nThe Company does not warrant that the Services, or any portion thereof, will operate without interruption, be error-free, or remain compatible with any particular device, network, or software version. Access to the Services may be suspended or interrupted for maintenance, upgrades, or causes beyond the Company's control. Any reliance you place on information or functionality made available through the Services is at your sole risk.\n11.3 Blockchain, Smart-Contract, and Network Risks\nYou acknowledge that blockchain networks, smart contracts, and decentralized technologies are experimental and may fail, fork, or behave unpredictably. The Company does not operate or control any blockchain network and makes no warranty regarding the security, functionality, or outcomes of any smart-contract execution. The Company cannot reverse or modify any blockchain transaction once confirmed on-chain.\n11.4 Third-Party Services and Integrations\nThe Services may interoperate with or rely upon third-party services, protocols, or APIs. The Company does not control, endorse, or guarantee any third-party service, product, or content and provides no warranty regarding their availability, legality, or performance. You are solely responsible for reviewing and accepting any applicable third-party terms before using such services.\n11.5 Security and Technological Limitations\nWhile the Company implements commercially reasonable safeguards, no technology is entirely secure. The Company does not warrant that the Services or any related systems will be free from malware, unauthorized access, cyberattacks, phishing, or other malicious activity that could compromise data or digital assets. You assume all risks associated with safeguarding your device, wallet credentials, private keys, and seed phrases.\n11.6 Legal, Regulatory, and Tax Matters\nThe Company makes no representation or warranty regarding the legality, regulatory classification, or tax treatment of the Services, digital assets, or blockchain transactions in any jurisdiction. You are solely responsible for ensuring compliance with all applicable laws, regulations, and reporting obligations.\n11.7 Apple Warranty Disclaimer\nTo the maximum extent permitted by law, Apple Inc. (\"Apple\") provides no warranty obligations whatsoever with respect to the App. In the event the App fails to conform to any applicable warranty, you may notify Apple, and Apple may refund the purchase price (if any) paid for the App. To the extent permitted by law, Apple shall have no other warranty obligation with respect to the App, and any other claims, losses, liabilities, damages, costs, or expenses attributable to any failure to conform to any warranty will be the sole responsibility of the Company.\n11.8 Limitation Under Consumer-Protection Laws\nSome jurisdictions do not allow the exclusion of certain warranties or limitations of liability. In such jurisdictions, this Section 11 shall apply only to the extent permitted by law, and the Company's liability will be limited to the minimum amount required by applicable statute.\n12. LIMITATION OF LIABILITY\n12.1 Exclusion of Damages\nTo the maximum extent permitted by applicable law and subject to Section 12.4, in no event shall the Company or any of its officers, directors, employees, contractors, affiliates, or licensors (collectively, the \"Aave App Indemnified Parties\") be liable to you or any third party for any indirect, incidental, consequential, special, exemplary, or punitive damages of any kind arising out of or relating to the Services or this Agreement—including without limitation loss of profits, revenue, data, goodwill, digital assets, business interruption, or other intangible losses—whether based in contract, tort (including negligence), strict liability, or any other legal theory, even if the Company was advised of the possibility of such damages and even if any remedy fails of its essential purpose.\n12.2 Aggregate Liability Cap\nSubject to Section 12.4 and to the maximum extent permitted by law, the total aggregate liability of the Company and all Aave App Indemnified Parties for any and all claims arising out of or relating to the Services or this Agreement shall not exceed the greater of: (a) one thousand U.S. dollars (USD $1,000) (or the equivalent amount in your local currency), or (b) the total amount of any fees actually paid by you to the Company for use of the Services during the twelve (12) months immediately preceding the event giving rise to the claim. This limitation is collective and shall not be increased by the existence of multiple claims or claimants.\n12.3 Specific Causes of Loss Excluded\nWithout limiting the foregoing, and to the fullest extent permitted by law, none of the Aave App Indemnified Parties shall be liable for any loss or damage arising from or related to: (a) User actions or errors, including loss of private keys or seed phrases, incorrect addresses, transaction mistakes, or failure to maintain device security, or loss of a device; (b) Blockchain or network failures, including congestion, forks, consensus errors, 51% attacks, or smart-contract vulnerabilities; (c) Acts or omissions of third parties, including service providers, oracles, or decentralized protocols integrated with the Services; (d) Market events such as price volatility, liquidity shortages, or loss in value of digital assets; (e) Force majeure events beyond the Company's reasonable control (f) failures of any technology infrastructure relied upon by the Services or the User, or (g) Any reliance on information, data, or instructions displayed within the App that is inaccurate due to outdated blockchain state or network latency.\n12.4 Consumer-Protection and Non-Excludable Rights\nNothing in this Agreement excludes or limits any liability that cannot be excluded or limited under applicable law, including liability for death or personal injury caused by negligence, fraud, fraudulent misrepresentation, or breach of statutory consumer rights. If applicable law does not permit the exclusion of certain warranties or liabilities, the scope of such warranties and the extent of the Company's liability shall be the minimum required by law. Your statutory rights as a consumer are not affected.\n12.5 Basis of the Bargain\nYou acknowledge that the limitations and exclusions set forth in this Section 12 represent a reasonable allocation of risk and form an essential basis of the bargain between you and the Company. The Company would not be able to provide the Services without these limitations. These limitations are intended to apply even if any limited remedy fails of its essential purpose.\n12.6 Application and Survival\nThese limitations apply to all claims, whether arising before, during, or after termination of this Agreement, and shall survive termination or expiration of the Agreement. If any portion of this Section is held invalid or unenforceable, the remaining provisions shall continue in full force and effect, and the Company's liability shall be limited to the maximum extent permitted by law.\n13. THIRD-PARTY SERVICES, APPLICATIONS, AND INTEGRATIONS\n13.1 General Integration\nThe Services may enable access to, interaction with, or functionality provided by independent third-party services, applications, websites, platforms, protocols, or smart contracts (collectively, \"Third-Party Services\"). These may include, by way of example, decentralized or centralized exchanges, liquidity protocols, bridges, oracle networks, routers, analytics providers, fiat gateways, smart contracts, and wallet connection interfaces. Access to or use of Third-Party Services is provided solely for convenience and does not imply any affiliation, endorsement, sponsorship, or recommendation by the Company.\n13.2 Third-Party Terms and Obligations\nEach Third-Party Service is governed by its own separate terms of service, user agreements, privacy policies, fee schedules, and other applicable conditions (\"Third-Party Terms\"). You are solely responsible for reviewing and accepting all Third-Party Terms before using or interacting with any Third-Party Service. By using any Third-Party Service through the Platform, you enter into a direct contractual relationship with the respective third-party provider and agree to be bound by all applicable Third-Party Terms. In the event of any inconsistency between this Agreement and any Third-Party Terms, the latter shall govern with respect to your use of the relevant Third-Party Service. The Company is not a party to, and assumes no obligations or responsibilities under, any Third-Party Terms or agreements between you and a third-party provider. The Company expressly disclaims any responsibility for the actions, omissions, representations, or services of any third-party provider, and makes no warranties or guarantees regarding their legality, reliability, accuracy, security, or performance.\n13.3 Availability, Changes, and Fees\nThird-Party Services are provided and controlled by independent providers and may be modified, suspended, or discontinued at any time, with or without notice. The Company does not guarantee the continued availability, compatibility, or integration of any Third-Party Service through the Platform and reserves the right to add, remove, or modify integrations at its sole discretion. Third-Party Services may impose their own fees, commissions, spreads, or costs, which are determined solely by the relevant provider and not by the Company. You are solely responsible for understanding and paying all such fees, and you acknowledge that the Company does not collect, retain, or control any Third-Party Fees unless expressly stated otherwise.\n13.4 Risk and Responsibility\nYou acknowledge that Third-Party Services—including decentralized protocols, smart contracts, and custodial exchanges—may be experimental, insecure, or subject to failure, vulnerabilities, exploits, downtime, or regulatory changes. You assume all risks associated with the use of Third-Party Services, including potential loss, theft, or compromise of digital assets or data. The Company does not perform due diligence or audits of Third-Party Services and makes no representations regarding their security, compliance, or suitability for any purpose. You are solely responsible for conducting your own independent research, technical review, and risk assessment before engaging with any Third-Party Service.\n13.5 Disputes and Indemnification\nAny dispute, claim, or controversy arising from or related to your use of a Third-Party Service is strictly between you and the applicable third-party provider. The Company has no obligation to mediate, arbitrate, or resolve any such dispute and will not provide compensation, refunds, or relief for losses caused by Third-Party Services. You agree to indemnify, defend, and hold harmless the Company and all Aave App Indemnified Parties from and against any and all claims, damages, liabilities, losses, penalties, and expenses (including reasonable attorneys' fees) arising out of or related to: (a) your use of or reliance on any Third-Party Service; (b) your violation of any Third-Party Terms; or (c) any dispute or interaction between you and a third-party provider.\n13.6 Mobile Application Platforms\nIf you access or use the Services through a mobile application obtained via a third-party platform (such as the Apple App Store), you acknowledge and agree that:\n\n(a) Platform Terms Apply: Your use of the application is also governed by the applicable platform's terms and policies, including without limitation the Apple Media Services Terms and Conditions (the \"Platform Terms\"). You are solely responsible for complying with all such Platform Terms.\n(b) Apple-Specific Terms: Where the Services are accessed via Apple iOS devices:\n\n(i) this Agreement is between you and the Company, not Apple;\n(ii) Apple has no responsibility for the Services or their content;\n(iii) Apple has no obligation whatsoever to provide any maintenance or support services with respect to the application;\n(iv) in the event the application fails to conform to any applicable warranty, you may notify Apple, and Apple may refund the purchase price (if any) paid for the application, but Apple shall have no other warranty obligation whatsoever; and\n(v) Apple, and Apple's subsidiaries, are third-party beneficiaries of this Agreement with the right to enforce its terms against you as they relate to your use of the application on iOS devices.\n\n(c) Priority of Platform Terms: To the extent of any inconsistency between this Agreement and the applicable Platform Terms, the Platform Terms shall control solely with respect to your use of the application as required by the relevant platform provider. Where any purchase, subscription, or payment is made through a third-party platform such as the Apple App Store, such transaction shall be processed and governed solely by the applicable platform's billing terms, policies, and refund procedures. The Company does not control and is not responsible for payments or refunds made through those platforms.\n\n14. INDEMNIFICATION\n14.1 Your Indemnification Obligations\nYou hereby agree to indemnify, defend, and hold harmless the Aave App Indemnified Parties from and against any and all claims, demands, actions, suits, proceedings, liabilities, judgments, damages, losses, costs, expenses, and fees (including but not limited to reasonable attorneys' fees, expert witness fees, court costs, and litigation expenses) arising out of, resulting from, or related to: (a) Your access to, use of, or inability to access or use the Services; (b) Your breach or alleged breach of this Agreement, including any representation, warranty, covenant, or obligation set forth herein; (c) Your violation of any applicable law, regulation, rule, order, directive, or requirement of any governmental authority; (d) Your violation of any rights of any third party, including but not limited to intellectual property rights, privacy rights, publicity rights, confidentiality rights, property rights, or contractual rights; (e) Your use of or interaction with any Third-Party Service, decentralized application, smart contract, or protocol; (f) Your violation of any Third-Party Terms; (g) Any transaction, interaction, or activity you conduct through or in connection with the Services; (h) Any content, information, data, or materials you submit, upload, post, transmit, or make available through the Services; (i) Your digital assets, private keys, seed phrases, or wallet credentials; (j) Any misrepresentation, omission, false statement, or fraudulent information you provide; (k) Your negligence, willful misconduct, fraud, or illegal activity; (l) Any dispute, disagreement, or conflict between you and any other User or any third party; (m) Your failure to pay any applicable taxes, fees, duties, or charges; (n) The export of your private keys or seed phrases from the embedded wallet; (o) Any loss, theft, compromise, or unauthorized access to your device, wallet, private keys, or digital assets; (p) Any claim that your use of the Services infringes upon, violates, or misappropriates the rights of any third party.\n14.2 Defense and Settlement\nThe Company reserves the right, at its sole discretion and at your expense, to assume the exclusive defense and control of any matter subject to indemnification by you, in which event you shall cooperate fully with the Company in asserting any available defenses and in the conduct of such defense. You shall not settle, compromise, or resolve any claim subject to your indemnification obligations without the Company's prior written consent, which consent shall not be unreasonably withheld. The Company may settle any claim subject to your indemnification obligations on such terms as it deems appropriate, and you shall be bound by any such settlement. You shall provide the Company with such information, cooperation, and assistance as the Company may reasonably request in connection with the defense, settlement, or resolution of any indemnified claim. Your obligations under this Section 14 shall survive the termination or expiration of this Agreement.\n14.3 Notice of Claims\nYou agree to promptly notify the Company in writing of any claim, action, or proceeding for which you believe you are obligated to provide indemnification under this Section 14. Failure to provide timely notice shall not relieve you of your indemnification obligations except to the extent that the Company is materially prejudiced by such failure.\n15. MODIFICATIONS TO SERVICES AND TERMS\n15.1 Right to Modify Services\nThe Company reserves the absolute and unconditional right, at any time and from time to time, in its sole and absolute discretion, without prior notice to you and without any liability whatsoever, to: (a) Modify, update, change, enhance, add features to, or remove features from the Services or any part thereof; (b) Temporarily or permanently suspend, discontinue, or terminate the Services or any part thereof; (c) Restrict, limit, or condition access to the Services or any features, functionality, or content thereof; (d) Change the availability, functionality, or user interface of the Services; (e) Impose new fees, charges, or costs for access to or use of the Services; (f) Add, remove, modify, or restrict integrations with Third-Party Services; (g) Modify, update, or change the technical requirements, specifications, or compatibility requirements for using the Services.\n15.2 Right to Modify Terms\nThe Company reserves the right to modify, amend, revise, supplement, or update these Terms or any other Operative Agreements at any time, for any reason or no reason, in its sole and absolute discretion. The Company will provide notice of material changes to these Terms by: (a) Posting the updated Terms on or through the Services; (b) Updating the \"Effective Date\" date at the top of these Terms; or (c) Providing notice through the Services, by email, or by other reasonable means (at the Company's discretion).\n15.3 Effect of Modifications\nYour continued access to or use of the Services following the posting or notification of any modifications to these Terms constitutes your ongoing binding acceptance of such modifications. If you do not agree to any modification, your sole and exclusive remedy is to discontinue using the Services and uninstall the Application. Unless otherwise specified, modifications to these Terms shall become effective immediately upon posting or upon the date specified in the notice of modification. Modifications may apply to disputes, claims, or transactions that occurred before the effective date of the modification, to the maximum extent permitted by applicable law. The Company's failure to enforce any modification, or any delay in enforcing any modification, shall not constitute a waiver of the Company's right to enforce such modification. You are responsible for reviewing these Terms periodically to remain informed of any modifications. The Company is under no obligation to specifically notify you of every modification beyond the notice mechanisms described in Section 15.2.\n15.4 Objection to Modifications\nIf you object to any modification to these Terms, you may reject the modification by: (a) Immediately ceasing all use of the Services; (b) Uninstalling the Application from all devices under your control; (c) Providing written notice to the Company of your rejection within thirty (30) days of the effective date of the modification. Upon proper rejection in accordance with this Section 15.4, any dispute between you and the Company shall be governed by the version of the Terms in effect immediately prior to the modification you rejected, solely with respect to claims arising before the effective date of the modification.\n15.5 No Obligation to Provide Updates\nYou acknowledge and agree that: (a) The Company has no obligation to provide any updates, upgrades, enhancements, improvements, bug fixes, patches, or corrections to the Services; (b) The Company may cease development, support, or maintenance of the Services at any time without notice or liability; (c) Updates or modifications to the Services may introduce new bugs, errors, incompatibilities, or reduce functionality; (d) You may be required to update the Application or your device's operating system to continue using the Services; (e) Failure to install required updates may result in reduced functionality or inability to access the Services.\n16. TERMINATION AND SUSPENSION\n16.1 Termination by User\nYou may terminate this Agreement and your use of the Services at any time by: (a) Ceasing all access to and use of the Services; (b) Uninstalling the Application from all devices under your control; (c) Discontinuing all interactions with smart contracts or blockchain networks through the Services. Termination by you does not relieve you of any obligations, liabilities, or responsibilities that accrued prior to termination or which are otherwise expressly noted herein as surviving termination.\n16.2 Termination and Suspension by Company\nThe Company reserves the right, in its sole and absolute discretion, with or without cause, with or without prior notice, and without any liability whatsoever, to: (a) Terminate or suspend your access to the Services, in whole or in part, immediately and without prior notice; (b) Block, restrict, flag, or prevent specific wallet addresses from accessing or interacting with the Services; (c) Refuse to provide Services to any person or entity for any reason or no reason; (d) Remove, delete, or disable any content, data, or information you have submitted, uploaded, or made available through the Services.\n16.3 Grounds for Termination or Suspension\nWithout limiting the Company's discretion under Section 16.2, the Company may terminate or suspend your access if the Company determines or suspects, in its sole discretion, that: (a) You have breached, violated, or failed to comply with any provision of this Agreement; (b) You have violated any applicable law, regulation, or legal requirement; (c) You have engaged in, or are suspected of engaging in, fraudulent, illegal, or prohibited activities, including but not limited to money laundering, terrorist financing, sanctions violations, fraud, theft, or any other criminal activity; (d) You have misrepresented your identity, location, or any other information; (e) You are located in, organized under the laws of, or ordinarily resident in any Restricted Jurisdiction; (f) You are subject to, or are owned or controlled by any person or entity subject to, any Sanctions; (g) You are identified on any list of prohibited or restricted parties maintained by any governmental authority, including without limitation OFAC's SDN List or Consolidated Sanctions List; (h) You have used stolen, misappropriated, or fraudulently obtained funds or digital assets; (i) You have engaged in market manipulation, wash trading, or other manipulative trading practices; (j) Your use of the Services creates legal, regulatory, compliance, or reputational risk for the Company; (k) Your continued access to the Services would be commercially impractical or would subject the Company to undue burden or liability; (l) You have attempted to circumvent, bypass, or defeat any security measures, access controls, or technical limitations of the Services; (m) Your account, wallet, or activities exhibit patterns or characteristics consistent with prohibited or high-risk behavior; (n) The Company receives a request, order, or directive from any governmental authority, law enforcement agency, regulatory body, or court requiring termination or suspension; (o) The Company determines that termination or suspension is necessary to comply with applicable law or to protect the Company's rights, property, or interests.\n16.4 No Liability for Termination\nYou acknowledge and agree that the Company shall not be liable to you or any third party for any termination or suspension of your access to the Services, regardless of the reason for such termination or suspension. The Company shall have no obligation to provide notice of termination, disclose the reasons for termination, provide an opportunity to cure any breach, or provide any appeal or review process.\n17. DISPUTE RESOLUTION, ARBITRATION, AND CLASS ACTION WAIVER\n17.1 Informal Resolution\nBefore initiating any legal or arbitral action, you and the Company agree to make reasonable, good-faith efforts to resolve any dispute, claim, or controversy arising out of or relating to this Agreement or the Services (each, a \"Dispute\"). Either party may start this process by sending written notice describing the issue and requested resolution. Such written notice must be sent to wecare@aave.com and must clearly state that it is submitted pursuant to Section 17.1 of these Terms. If the Dispute is not resolved within thirty (30) days, either party may proceed as set forth below.\n17.2 Binding Arbitration.\nExcept as provided in Section 17.4, any Dispute that cannot be resolved informally shall be finally settled by binding arbitration administered by the International Centre for Dispute Resolution (ICDR) under its International Arbitration Rules in effect at the time of the arbitration. The arbitration shall be conducted by a single neutral arbitrator with relevant experience in technology or digital-asset matters. The seat and governing law of the arbitration shall be the","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257864622,"hash":"7da511a56302edec30a528e0e9c30c31c56037c3"}
{"url":"https://gov.optimism.io/c/communications/90","domain":"gov.optimism.io","title":"Latest Communications 📣 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Communications 📣\n\n Communications 📣\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Communications category\n\n Communications 📣\n\n 0\n\n 21\n\n Jan 6\n\n 404 Gov - Delegate Platform\n\n Delegates 🏛\n\n An important update regarding the future of 404 DAO’s governance operations. \nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What sta…\n\n read more\n\n 1\n\n 59\n\n 1d\n\n Security Council Communication Thread\n\n Council Communication Threads\n\n Welcome to the Security Council Communication Thread!\nThe goal of the Security Council is to turn admin keys for OP Mainnet, and eventually, all OP Chains in the Superchain, over to a public, decentralized set of individ…\n\n read more\n\n 18\n\n 1.4k\n\n Sep 3\n\n PGov - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate Name: @PGov \nDelegate Address: PGov.eth (0x3fb19771947072629c8eee7995a2ef23b72d4c8a) \nForum Handle: @PGov, @Juanbug_PGov \nEmail: PGovTeam@gmail.com \nCore Principles: \n\nTransparency: Clear communication with vote…\n\n read more\n\n 45\n\n 3.6k\n\n Sep 2\n\n Buyback Communication Thread\n\n Communications 📣\n\n season-9\n\n This communication thread will be used to provide transparency into buyback execution via OTC. We will update this post with links to any relevant dashboards and will post execution details monthly. As the program author…\n\n read more\n\n 6\n\n 866\n\n Aug 25\n\n Brichis - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate statement \nFirstly, allow me to introduce myself. My name is Bricia, although you’re welcome to call me Brichis and I am Co-Founder of Ethereum Mexico. \nMy decision to become a delegate was sparked by discussio…\n\n read more\n\n 48\n\n 3.9k\n\n Aug 21\n\n FranklinDAO (Penn Blockchain) - Delegate Communication Thread\n\n Delegate Updates\n\n Address or ENS: FranklinDAO.eth \nDiscord username: Juanbug#9225 \nHello everyone! We’re FranklinDAO/Penn Blockchain (@PennBlockchain on twitter), a leading, completely student run blockchain organization from The Universi…\n\n read more\n\n 5\n\n 2.2k\n\n Aug 21\n\n AlexSotoDigital.eth - Delegate Communication Thread\n\n Delegate Updates\n\n Here my Delegate Statement \n\nHi! \nFirst let me introduce myself. My name is Alex Soto, and I’m Mexican and a stubborn optimist. \nI am an independent facilitator and consultant on organizational de…\n\n read more\n\n 16\n\n 584\n\n Jul 9\n\n Axia Network — Delegate Communications Thread\n\n Delegate Updates\n\n Axia Network is a delegate across DAOs in the EVM ecosystem. Axia is committed to growing alongside the ecosystem and contributing responsibly to each protocol’s long-term success. \nAxia’s values emphasize supporting pro…\n\n read more\n\n 2\n\n 138\n\n Jun 1\n\n GFX Labs - Delegate Communication Thread\n\n Delegate Updates\n\n This thread is intended to provide a record of GFX Labs’ voting and communication around the reasoning of each vote. Subsequent voting communications will be added to this thread over time. \n3 Polls Ending June 26 \nPropo…\n\n read more\n\n 63\n\n 8.6k\n\n Apr 21\n\n Vulnerability in Kona fallback proof system\n\n Communications 📣\n\n Summary\nAn audit found three instances where kona-proof’s derivation logic could differ from the canonical chain. No funds were at risk on OP Stack chains because no OP Stack chains using permissionless fault proofs are …\n\n read more\n\n 1\n\n 88\n\n Apr 3\n\n S9 Grants Council Communication Thread\n\n Council Communication Threads\n\n The Optimism Grants Council was initiated in Governance Season 3. This page outlines the basic details of the Grants Council as constituted for Season 9 and will serve as the main thread for official communications with …\n\n read more\n\n 0\n\n 76\n\n Mar 17\n\n Blockful – Delegate Communication Thread\n\n Delegate Updates\n\n Delegate Name: @blockful \nDelegate Statement: gov.blockful.eth on Agora \nDelegate Address: gov.blockful.eth (0x1f3d3a7a9c548be39539b39d7400302753e20591) \nForum Handle: @blockful, @zeugh \nEmail: forum@blockful.io \nWebsite…\n\n read more\n\n 2\n\n 88\n\n Jan 28\n\n SEEDGov - Delegate Communication Thread\n\n Delegate Updates\n\n UPDATE Q2 2023: we changed our name to SEED Latam. With this renewed image and enlargement of the scope, we are committed to support communities and leaders in Latam. \n\nRead our vision here – Plataformas de delegados. ¿P…\n\n read more\n\n 64\n\n 13.0k\n\n Jan 27\n\n Polynya - Delegate Communication Thread\n\n Delegate Updates\n\n I have finished my votes for Gov Fund Phase 1 Season 1. \nMy general impression thus far is that most proposals are a mixed bag, with very few high-quality projects I’d be excited to support without reservations. Since Op…\n\n read more\n\n 44\n\n 6.8k\n\n Jan 26\n\n S8 Grants Council Impact Analysis\n\n Accountability 🗂️\n\n season-8\n\n The intention behind this impact analysis is to equip the Optimism Collective with preliminary results of the Grants Council’s S8 grants and help inform OP allocation decisions in S9. It was prepared by OSO in collabora…\n\n read more\n\n 0\n\n 169\n\n Jan 23\n\n Formally Announcing Axia Network\n\n Delegate Updates\n\n season-9\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole…\n\n read more\n\n 0\n\n 50\n\n Jan 13\n\n Seasons 8 & 9 Developer Advisory Board: Communication Thread\n\n Council Communication Threads\n\n season-8\n\n The Developer Advisory Board (DAB) was initiated in Season 5. This thread will serve as the official channel for communications from the DAB to the Collective for the full 12-month term covering Seasons 8 and 9. \nPurpose\n…\n\n read more\n\n 3\n\n 258\n\n Jan 13\n\n [Delegate Statement] Ezekiel Ekondu\n\n Delegates 🏛\n\n Hello Optimism Collective \nMy name is Ezekiel Ekondu, a student, designer, and Web3 content creator. I’m applying to become a delegate in the Optimism Collective with a strong interest in education, onboard…\n\n read more\n\n 0\n\n 29\n\n Jan 9\n\n Token House participation and incentives: Season 8 (Cycle 39a-45)\n\n Delegates 🏛\n\n season-8\n\n Intro\nThis report analyzes voting activity, feedback, and rationales using the top 100 delegates as a sample during Season 8. It focuses on how participation unfolded over the course of a relatively calm season, shaped b…\n\n read more\n\n 0\n\n 96\n\n Jan 9\n\n When will be the next Citizenship Registration?\n\n Citizens 👥\n\n When will be the next Citizenship Registration?\n\n 0\n\n 62\n\n Dec 2025\n\n Season 8: Budget Transparency Report\n\n Accountability 🗂️\n\n Overview\nThis report provides transparency into the Season 8 operating budget distribution. The Token House approved 4,440,000 OP for Season 8/9, with funds transferred from the Governor Fund to Safe 0x27426F2bd5120Df4ea…\n\n read more\n\n 5\n\n 274\n\n Dec 2025\n\n Public Forum to Wallet Link Verification\n\n Delegates 🏛\n\n Public Forum to Wallet Link Verification \nThis thread provides an open verification tool for linking your forum account to your wallet address. It serves as a public utility for integrating on-chain governance with forum…\n\n read more\n\n 17\n\n 490\n\n Nov 2025\n\n Allow the Optimism Foundation to Stake a Portion of Sequencer ETH Through Season 8\n\n Citizen Updates\n\n season-7,season-8\n\n Allow the Optimism Foundation to Stake a Portion of Sequencer ETH Through Season 8\nProposal Type: Sequencer ETH: Passive Management (see updated Operating Manual)\n\nNotes about this Proposal Type: \nYield estimates are sub…\n\n read more\n\n 26\n\n 1.7k\n\n Nov 2025\n\n Token House participation and incentives: Season 6 (Cycle 23a-30)\n\n Delegates 🏛\n\n season-6\n\n As members of the crypto community return home after an exciting DEVCON 7🪩, Bitcoin has achieved a new all-time high. AI agents dominate Crypto Twitter, and memecoins capture attention both within and outside the crypto …\n\n read more\n\n 11\n\n 641\n\n Nov 2025\n\n L2BEAT - Delegate Communication Thread\n\n Delegate Updates\n\n Hey! \nIn the previous voting seasons, we were one of the most prominent governance delegators, engaging in various discussions and leading Tooling Governance Committee. \nToday I would like to announce that we are shiftin…\n\n read more\n\n 20\n\n 4.0k\n\n Nov 2025\n\n Curia OP Governance Dashboard Update Thread\n\n Delegates 🏛\n\n GM everyone, \nI’m happy to share some new updates to the Curia OP Governance Dashboard, which I hope you’ll find useful. \nI’ve updated the UI, added support for new proposal types (like the ‘Joint House’ proposals), and …\n\n read more\n\n 0\n\n 74\n\n Oct 2025\n\n DAOplomats Delegate Communication thread\n\n Delegates 🏛\n\n Name: DAOplomats.eth \nDelegate Address: 0xc2490D220419ACdCeD68428Ac413c8483d08D1AB \nDelegate ENS Address: OP.DAOplomats.eth \nForum Username:, Jengajojo \nWebsite: DAOplomats.com \nTwitter: https://x.com/DAOplomats \nOu…\n\n read more\n\n 15\n\n 861\n\n Oct 2025\n\n Kpk - Delegate Communication Thread\n\n Delegates 🏛\n\n Delegate information\nName: kpk \nDelegate Address: 0x8787FC2De4De95c53e5E3a4e5459247D9773ea52 \nForum: @kpk \nTwitter: x.com \nLanguages: English \nIntroduction and experience\nkpk helps organisations secure, manage, and grow…\n\n read more\n\n 3\n\n 136\n\n Oct 2025\n\n Karma Funding Platform updates\n\n Accountability 🗂️\n\n gm, I’m Mahesh Murthy, founder of Karma. We are an all-in-one funding platform, a support network for builders, and a protocol for tracking accountability and measuring impact onchain. In August, we partnered with the Op…\n\n read more\n\n 3\n\n 184\n\n Oct 2025","tokens":2375,"squid":"ink-governance","role":"Council Listener","at":1791257874895,"hash":"160ec9d9bbaebaba6f9f2fbee9815015b6202342"}
{"url":"https://aave.com/legal/app/waitlist-supplemental-terms","domain":"aave.com","title":"Aave App Waitlist Supplemental Terms | Aave","text":"1. Scope and Incorporation\nThese Program Supplemental Terms (“Program Terms”) govern participation in the Aave App Program waitlist (the \"Program\"). They supplement and are incorporated into the Aave App Terms and Conditions (the “Master Terms”). Capitalized terms not defined here have the meanings in the Master Terms. In the event of any inconsistency, these Program Terms control solely with respect to the Program.\n2. Program Participation\nThe Program is a pre-launch waitlist for the Aave App.\nAny savings rates, “boosts,” or APY figures displayed within the Program interface are illustrative simulations only, based on hypothetical market scenarios. They are not guarantees, promises, or offers of returns. Participation in the Program does not guarantee the launch of the product, any return or benefit, or any future eligibility to access or use the Aave App.\nFor the avoidance of doubt, no real interest, rewards, or DeFi yield is distributed or accrued during the Program. All yield data visible during the Program is non-binding, hypothetical simulation only.\n3. Self-Custodial and Market-Based Structure\nThe Aave App is designed as a self-custodial interface, where users maintain control of their assets through personal wallets. If launched, any yields provided to users will be generated from DeFi market activity across various DeFi vaults and lending markets, not from any entity, including Aave Labs, or Aave Labs’ exercise of custody or pooled deposits. Aave Labs does not take custody or control of any user assets. If the Aave App is launched, all expected returns or yield calculations will derive from onchain vault and DeFi lending market activity, programmatically determined by smart contracts. These rates are variable and depend on market supply and demand conditions. Aave Labs does not guarantee or underwrite any yield.\n4. Simulated Rates and APY Disclosure; No Investment Advice\na. Illustrative and Non-Binding Nature. Simulated rates represent Annual Percentage Yield (APY) projections generated under illustrative and hypothetical conditions. They are provided solely for educational and informational purposes to demonstrate potential functionality of the Aave App and are not offers, promises, guarantees, or binding representations of any kind. This information is merely informational and should not be viewed as an inducement to use the Aave App.\nb. No Investment, Financial, or Other Advice. Nothing displayed, communicated, or made available through the Program, the Aave App interface, website, or any related materials shall be construed as business advice, investment advice, financial advice, trading advice, legal advice, or any form of recommendation to engage in any transaction or strategy. Users acknowledge and agree that:\n\nAave Labs and its affiliates do not act as investment advisers, fiduciaries, or financial intermediaries;\nThe content and simulated rates do not take into account individual objectives, financial situations, or needs;\nAny decision to use or later engage with DeFi protocols is made independently and at the participant’s sole risk.\n\nc. No Reliance and Independent Judgment. Users must not rely on any simulated APY, yield projection, graph, marketing material, or in-app display as a basis for making investment or financial decisions. Each participant should conduct independent research and seek professional advice where appropriate.\nd. Variable, Retractable, and Subject to Change. Aave Labs makes no commitment or obligation to maintain, publish, or honor any specific rate or return.\ne. No Offer or Solicitation. Participation in the Program and all associated communications do not constitute an offer to sell, a solicitation to buy, or an invitation to engage in any financial product or service in any jurisdiction.\n5. Boost Mechanics & Participation Caps\na. Boost Mechanics. During Program, users may view or simulate “Boost” conditions (for example, verifying identity, enabling Auto Saver, or referring friends). These Boosts are provided solely for demonstration and testing purposes and do not confer any right or entitlement to any benefits. The design, structure, rates, or criteria for any Boosts, if later implemented in the live Aave App, may differ materially from the simulated versions, including in name, amount, calculation method, or availability.\nb. Third-Party and KYC-Linked Boosts. Certain Boosts—such as those relating to identity verification or KYC (Know Your Customer)—may depend on actions or verifications performed through third-party service providers or regulated entities, including licensed exchanges or other on-ramp partners (collectively, “Third Parties”). Where applicable, participation in such Boosts will be subject to the Third Party’s own terms, privacy policies, and regulatory requirements. Aave Labs does not perform regulated KYC, custody, or exchange services and does not guarantee the availability, timing, or outcome of any such verification process. Completing a KYC process with a Third Party does not create any direct relationship with Aave Labs, nor any right to receive yield, rewards, or continued access to the Program. Aave Labs is not responsible or liable for any determination, refusal, delay, or error by any Third Party and may amend or withdraw any related Boost at any time and in any manner it deems appropriate solely in its exclusive discretion.\nc. Caps. A per-person cap and limited duration may be established from time to time for any Boosts at Aave Labs’ discretion, and any related parameters may be introduced, adjusted, or withdrawn as Aave Labs considers appropriate. For the avoidance of doubt, any eligibility for, or receipt of, a simulated or live Boost, promotional rate, or related benefit remains subject at all times to Section 7 (Fraud, Abuse, Integrity, and Compliance). Aave Labs retains full discretion to suspend, withhold, or revoke any such benefit in any manner it deems appropriate, including where it suspects inauthentic activity, circumvention, or behavior inconsistent with the integrity of the Program. For the avoidance of doubt, any eligibility for, or receipt of, a simulated or live Boost, promotional rate, or related benefit remains subject at all times to Section 7 (Fraud, Abuse, Integrity, and Compliance). Aave Labs retains full discretion to suspend, withhold, or revoke any such benefit in any manner it deems appropriate, including where it suspects inauthentic activity, circumvention, or behavior inconsistent with the integrity of the Program.\nc. Jurisdictional Limitations. Availability of certain Boosts may vary by jurisdiction, regulatory classification, or user status. Aave Labs reserves the right, at its sole and absolute discretion and in any manner it deems appropriate, to restrict, modify, suspend, or remove any Boost or related feature based on geographic location, legal requirements, or third-party dependencies.\n6. No Obligation to Launch\nAave Labs and its affiliates are under no obligation to launch the Aave App, offer any product or service, or make available any of the simulated features or rates shown during the Program.\n7. Fraud, Abuse, Integrity and Compliance\na. Right to Investigate, Enforce, and Act. Aave Labs reserves the absolute and unrestricted right, at any time and in any manner it deems appropriate, to monitor, review, investigate, suspend, limit, restrict, or permanently revoke any participant’s access to, or participation in, the Program. Such action may be taken for any reason whatsoever, whenever Aave Labs suspects, believes, or determines, in its sole and final discretion, that conduct may compromise the security, fairness, integrity, or intended operation of the Program, the Aave App, or any associated systems or networks, or violate legal obligations or prohibitions, or any conduct prohibited under these Terms, abusive or manipulative. Aave Labs may rely on any data, patterns, or indicators available to it, including algorithmic, technical, or third-party signals, without the need to validate them externally.\nb. Prohibited Conduct and Illustrative Examples. Without limiting the generality of the foregoing, the following conduct (and any substantially similar behavior) shall be considered prohibited, abusive, or manipulative:\n\nAutomated, scripted, or mass-scale account creation, “bot farming,” or use of software agents, macros, or coordinated participation systems;\n“Sybil” activity or any attempt to create or control multiple accounts, wallets, or identities to obtain unfair or duplicated benefits;\nMisrepresentation, falsification, or obfuscation of identity or location, including but not limited to falsified KYC submissions, disposable emails, VPN masking, proxy routing, or other anonymity services used to manipulate eligibility or jurisdictional criteria;\nCoordinated or collusive referral loops, referral gaming, or circular reward structures;\nReverse engineering, scraping, data extraction, or interference with any interface, API, vault, or smart-contract logic connected with the Program;\nExploiting software bugs, configuration errors, or any unintended functionality of the App or related systems;\nEngaging in any activity that Aave Labs reasonably believes or in any way deems detrimental to the integrity, reputation, or legitimate interests of the Program;\nParticipation from jurisdictions or by persons subject to sanctions or trade restrictions, or conduct that may violate anti-money-laundering (AML), counter-terrorism financing (CTF), or similar laws and regulations;\nAny other action or omission that, in Aave Labs’ sole judgment, undermines the good-faith operation, security, or perception of the Program or the Aave ecosystem.\n\nc. Discretion and Finality of Determinations. All determinations by Aave Labs regarding eligibility, participation, and compliance—including whether specific behavior constitutes fraud, abuse, or manipulation—shall be final, binding, and made in Aave Labs’ exclusive discretion. Aave Labs may exercise these rights selectively, inconsistently, or differently across users, and no such variation shall create any obligation to act similarly in other cases.\nd. Action Without Notice or Explanation. Aave Labs may take any action described herein immediately and without prior notice, explanation, or justification, and is under no obligation to disclose the reasoning, evidence, or methods underlying any decision. Users acknowledge and agree that Aave Labs’ user access decisions and moderation processes may involve proprietary monitoring tools and methodologies that are confidential.\ne. Remedies. If Aave Labs determines, or suspects in its discretion, that a participant has engaged in or benefited from any prohibited or abusive activity or that conduct may compromise the security, fairness, integrity, or intended operation of the Program, or violate legal obligations or prohibitions, or any conduct prohibited under these Terms, abusive or manipulative, it may, without limitation and in any combination it deems appropriate:\n\nSuspend, restrict, or permanently revoke participation in the Program;\nVoid or nullify any simulated, accrued, or potential yield, Boost, or promotional benefit;\nForfeit eligibility for any future Aave App reward, referral, or promotional offer;\nBlock wallet addresses, identities, or accounts from future participation in any Aave Labs-affiliated program;\nReset, modify, or delete any related user data associated with the suspected activity;\nDisqualify referrals or connected users; and\nDisclose or report the activity to law enforcement, regulators, or other third parties when legally required or when Aave Labs, in its discretion, considers it appropriate.\n\nf. Non-Exclusive Rights and No Waiver. The rights and remedies described in this Section 7 are cumulative, continuing, and non-exclusive of any other rights available to Aave Labs under the Master Terms, applicable law, or equity. A failure or delay to act in any instance does not constitute a waiver of Aave Labs’ rights in any other circumstance.\n8. Taxes and Responsibility\nUsers are solely responsible for any potential tax implications or payment obligations arising from any rewards or yields received by Participant from their use of the App or Program Nothing in these Program Terms constitutes tax advice.\n9. Modifications and Termination\nAave Labs may modify, suspend, or terminate the Program or these Program Terms at any time without prior notice.\n10. Governing Law and Disputes\nThese Program Terms are governed by the same governing law, arbitration, and dispute provisions as set out in the Master Terms.","tokens":3160,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791257874972,"hash":"ea554d2cf14715f844c80360b653105e0327803f"}
{"url":"https://ethresear.ch/t/plasma-next-plasma-without-online-requirements/18786/7","domain":"ethresear.ch","title":"Plasma Next: Plasma without Online Requirements - Layer 2 / Plasma - Ethereum Research","text":"Layer 2Plasma\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Feb 2024\n\n 8 / 8\n\n May 2024\n\n May 2024\n\n post by leohio on Feb 25, 2024\n\n leohio\n\n Leona Hioki, Albus Dompeldorius, Yutaka Hashimoto\nAbstract\nWe introduce a new kind of blockchain scaling solution, which can be classified as a kind of Plasma, but without the online requirement of users. Our design satisfies the following requirements:\n\nO(1) state growth per block relative to the number of users before withdrawals\n\nNo need for channels or individual liquidity preparations between recipients and the hub\n\nElimination of online requirements for general users except during sending and receiving (No need of watch tower)\n\nOnchain privacy\n\nThis is the practical pseudo-solution of the the impossibility of stateless blockchains proposed in 2022. We can delay the problem proposed in the paper as long as we want.\nCode & Mainnet Demo: github plasna-next\nBackground\nThe scaling solution for programmable blockchains such as Ethereum to accommodate an increasing number of users, Plasma, was frequently discussed in 2018. It is a Layer 2 with O(1) state growth per block, which, in the recent context of Financial Cryptography, is classified as a stateless Layer 2. Subsequently, to avoid the heavy online requirements, i.e., updating proofs or witnesses, and to prevent Data Availability Attacks against smart contracts, development moved towards Rollups, which utilize Layer 1’s cheaper storage space for data availability. A method that could eliminate online requirements while providing the same level of O(1) scaling as Plasma was the goal needed to achieve for the practicality reason.\nPrerequisites\nBulk-Token-Transfer\nThe sender inserts the recipient’s address and the amount to be sent into each leaf of a Merkle Tree and generates a Merkle Root. Then, the sender creates a ZKP with the total amount sent and the Root as public inputs and allocates the funds accordingly. Each recipient is given their corresponding leaf and Merkle Proof, along with the ZKP, to complete the transaction. Even if a recipient receives multiple such transactions, they can efficiently prove the aggregate of these ZKPs and Merkle Proofs on their client-side, for example, through recursive ZKPs. Only the root gets recorded on Layer1, it makes the O(1) state growth unless there is no withdrawal verification on Layer1.\nERnewpost (19)960×540 32.5 KB\nZKP-TLC\nHTLC (Hash Time Locked Contracts) is a technology for conditional payments used in multi-hop payment channels, such as the Lightning Network. In the case of an HTLC where a user, Alice, makes a payment to an operator/hub, Bob, Alice sets the hash value hash(preimage) of a randomly specified value preimage in that HTLC. If Alice can somehow learn and submit the preimage, say, by being told by Bob, then the payment is completed. Otherwise, the payment is canceled after a certain period. It is also possible to create a modified version of HTLC where the part about revealing the preimage is changed. For example, an HTLC from Alice to Bob could be conditioned on Bob having made a payment to Carol if there is a ZKP of it, as used in this paper. Let’s call an HTLC modified to set the verification of a ZKP as its condition a ZKP-TLC.\nOne-Way Payment Channel\nIn a bidirectional payment channel, since both balances can increase or decrease, an attacker retroactively cancels a transaction by closing the channel with an outdated balance unless it’s not watched over, thus requiring both parties to constantly monitor the Layer 1 chain for channel closure. However, in a one-way channel where only one party’s balance decreases, any channel close other than the most recent commit always benefits the sender, Alice. In this case, the sender, Alice, no longer needs to monitor Layer 1, freeing her from the online requirement. In the overall structure of this paper, the balance update condition for the payment channel from Alice to Bob is set to a ZKP-TLC, which is fulfilled by sending a proof of a bulk-token-transfer from Bob to Carol.\nOff-chain Channel Opening/Funding\nIn conventional payment channels, channel opening/funding is performed on-chain, whereas this can be replaced by receiving a bulk-token-transfer with a Merkle Tree. On the blockchain, the block number of the last bulk-token-transfer withdrawal made by each user is recorded. When a user or Bob withdraws, they must prove the entire amount received, i.e., the channel capacity, using ZKP. This prevents the possibility of withdrawing the same receipt twice. Furthermore, preventing Bob from proving a lesser amount is safeguarded by Alice signatures during channel updates. The channel is updated while agreeing on the channel capacity. This part also makes Plasma Next bidirectional.\nMethod\nTL;DR: There are 2 ways to do stateless payments which do not make onchain data cost, bulk-token-transfer and payment channel. Bulk-token-transfer, which is a transfer from a single sender to multiple recipients, uses only a fixed onchain cost of 32 bytes. It is possible to share this fixed cost among many senders by using payment channels in a trustless manner. If we use one-way payment channel, we can eliminate the online requirement. The receipt of a bulk-token-transfer can be directly converted into off-chain channel opening/funding, enabling bidirectional transfers and keeping the system stateless.\nThe hub of a single payment channel is referred to as the operator. Since the system has and needs only one payment channel hub, this paper does not consider hops beyond one since it’s not required. The paper proposes using ZKPs and Merkle Proofs of payment for closing payment channels, eliminating the need for long-term online requirements. Instead of submitting a hash’s preimage as the condition for an HTLC in a payment channel, it uses the proof of asset distribution in a Merkle tree and a ZKP of the total amount distributed across the tree. Hereafter, the sender is Alice, the hub operator is Bob, and the receiver is Carol. In this system, a Payment Channel is open between Alice and Bob, and initially, there does not need to be a channel between Bob and Carol. Users do not open channels with anyone other than Bob.\nBob employs a bulk-token-transfer with a Merkle Tree for making payments to numerous recipients. All payments to the recipients are recorded in the leaves of a Merkle tree, and Bob also creates a ZKP of the total amount for these payments. The funds used for payments in this Merkle tree are managed completely separately from those in the channel. Instead of using a conventional ZKP-TLC for the update condition of the oneway payment channel from Alice to Bob, a ZKP-TLC that is satisfied by submitting a Merkle Proof and a ZKP of a corresponding bulk-token-transfer.\n\nBob receives information from Alice about the payment amount from Alice to Carol.\n\nAlice sets the condition of the ZKP-TLC such that the balance of the channel between Alice and Bob changes only if a bulk-token-transfer of an equivalent amount from Bob to Carol is successful. Both Alice and Bob sign this ZKP-TLC. The data of the ZKP-TLC also includes the total amount Alice has received since the last withdrawal, which represents the capacity of this payment channel, and this is simultaneously signed as well.\n\nBob creates a Merkle tree aggregating such payments in bulk (there are many Alice and Carol pairs in this world), meaning that he put the merkle root onchain.\n\nBob provides Carol (and Alice) with the path and data for Carol’s payment within the Merkle tree. For Carol, this also functions as channel opening/funding.\n\nThe payment is not completed until Carol receives the data, giving Alice, the sender, an incentive to provide the data to Carol herself if Bob fails to do so. Carol is not obligated to provide any service in back if she does not receive the data.\nERnewpost (18)960×540 32.4 KB\nThe contract for on-chain withdrawal (channel close) contains the following data:\nFor common,\n\nallTreeRoot: The root of a Merkle Tree made by all roots of bulk transfer trees\n\nFor each user,\n\nlastBlockNumber: The block number of the last withdrawal by Alice\n\nClosing the channel can proceed as follows:\n\nProve and submit the total amount received from the proofs using recursive ZKP. The total amount should be greater than or equal to what was signed from both sides when the channel was updated.\n\nSubmit last balance of Bob within the channel, which is signed by both.\n\n3.The difference in balance is the amount that can be withdrawn.\n\nIn this scenario, if Bob makes channel payments without verifying the ZKP, Bob is at a loss. Withdrawals exceeding the total channel amount are not possible, preventing any deception across the protocol or the pool.\nTherefore, deposits into the channel are enabled by proving the total amount received from the proofs using recursive ZKP. Essentially, all money received via the bulk-token-transfer can be considered for deposit into the channel.\nRegarding Channel Closing:\nChannel closure can occur when Bob wishes to close the channel or when Alice or Carol wants to close the channel and Bob agrees, under the conditions that:\n\nBoth signatures are present on the ZKP-TLC,\n\nThe conditions of the ZKP-TLC have been satisfied.\n\nThere is no challenge period for these scenarios.\nIf Alice or Carol wishes to close the channel but Bob does not agree, closure can still proceed if:\n\nBoth signatures are present on the ZKP-TLC,\n\nThe conditions of the ZKP-TLC have been satisfied,\n\nThere are no other ZKP-TLC submissions from Bob during a challenge period.\n\nMalicious Patterns and Responses\nThere is no need of “exit game”, but we need patternized procedures for some edge cases.\n1. If Alice attempts to close with an outdated commit\nBob, who is always online, can activate the latest commit onchain by submitting it, just as in a normal payment channel. This submission includes the Merkle proof for the bulk-token-transfer and the ZKP of the funds as inputs to the ZKP-TLC condition onchain.\n2. If Bob attempts to close with an outdated commit\nSince Alice’s balance only decreases and an outdated commit would be in Alice’s favor, it can be ignored.\n3. If Alice attempts to withdraw a bulk-token-transfer more than once\nWithdrawn bulk-token-transfers have a corresponding Layer1’s lastBlockNumber, and within the ZKP circuit, it is verified that there are no duplicate transactions, preventing the possibility of double withdrawals.\n4. If Alice tries to use a received bulk-token-transfer as funding in the channel with Bob more than once\nAs mentioned above, since the onchain cannot be deceived, Alice and Bob are in a zero-sum game regarding this point. Bob only needs to verify Alice’s funding source in the same way the onchain verification mechanism would.\n5. If Bob does not proceed with the bulk-token-transfer after setting the ZKP-TLC\nIn a friendly scenario, both parties can agree to cancel the payment with their signatures. Otherwise, both Alice and Carol may choose to close the channel.\n6. If Bob does not provide Alice with the bulk-token-transfer’s ZKP and Merkle Proof\nAlice closes the channel. Bob then submits the proof onchain, making it possible for Carol to become aware of it as well. Since Bob has already allocated the funds to Carol, Alice could choose to ignore this situation. However, if Carol has not received the data, the payment to Carol remains incomplete, giving Alice an incentive to ensure that the data is transferred to Carol.\n7. If Bob, after updating Alice’s lastBlockNumber through closing, reveals the existence of previously hidden bulk-token-transfers to Alice that occurred before the lastBlockNumber\nIt is essentially important to prevent this withholding attack by the sender to Alice, yet there could be cases where the sender attempts to do so while closing. Assuming Alice will notice these transfers after a relatively short period, it is desirable that if the amount received upon closing is less, Alice should be able to recalculate it. Since Alice should have kept all the receiving proofs at least after the last withdrawal, she should be able to calculate the recalculated amount and receive the difference from what was received at Bob’s closing.\nTherefore, add the following to the storage for each user (not added to all sections for clarity of explanation):\n\npreviousBlockNumber: The block number of Alice’s penultimate withdrawal.\n\nlastWithdrawAmount: The last withdrawal amount, i.e., the amount withdrawn between the previousBlockNumber and the lastBlockNumber.\n\n8. When Bob attempts to finalize Alice’s withdrawal amount during channel closing with a smaller channel capacity\nSince Alice has not signed off on this channel capacity, the onchain verification will not pass.\nAvoiding the impossibility of Statelessness\nA paper published in 2022 addressed the limitations of stateless blockchains with O(1) state growth. This was a groundbreaking formalization and theorization of limitation felt by the Plasma community facing Data Availability problem in 2018, turning many researchers skeptical towards stateless blockchains. The pseudo-solution proposed here achieves statelessness in the absence of channel closures for withdrawals or dispute resolutions. In short, we can delay the problem proposed in the paper as long as we want since the channel opening and the transfer process are in a stateless manner, and only the withdrawal requires state data onchain.\nThe paper posits that a stateless cryptocurrency is not feasible because it necessitates choosing between linear state growth with the number of users or an increase in local proof updates. However, this limitation is based on the premise that an increase in local proof updates is unacceptable. In the context of payment channels, this premise falls apart as Alice only needs to notify Carol about the given proof updates, motivated by a strong incentive to do so. This significantly differs from scenarios where shared assets in smart contracts have no protection against the threat of proof updates, i.e., Data Availability Attacks. Without rich stateful smart contracts, local proof updates are not a threat, and online proof distribution is feasible. Payment channels do generate state growth in the event of disputes, but if there is no dispute and the channel does not close, the opening of channels is possible through the distribution of merkle proofs, and payment transactions do not generate state growth, thus maintaining statelessness.\nTo succinctly capture the achievement of this stateless system within the context of the limitations of statelessness, focusing on payments and concentrated online requirements to specific nodes has enabled O(1) state growth without harmful proof updates.\nProgrammability: Stateless Applications and Stateful Applications\nDevelopers can build applications with EVM. Verification on the ZKP-TLC side is conducted on an EVM smart contract written in Solidity or similar languages. Ultimately, whether it is valid on-chain becomes the criterion for off-chain verification, allowing for the execution of EVM bytecode to be added. In a relationship confined between Alice and Bob (Operator), it is possible to set all on-chain verifiable transactions made by Bob as conditions for the ZKP-TLC from Alice to Bob. It is considered possible to extend this to include Carol using bulk-token-transfers.\nThe methods described above make it possible to construct applications that are inherently stateless. Applications that possess rich statefulness, such as having a contract address managed by the entire protocol, are challenging to support with Plasma alone. However, by utilizing smart contracts from other rollups, it is possible to create stateful applications. In this case, the advantage of Plasma Next lies in the separation of scalability for smart contract execution and scalability for transfers. Transfers can be conducted in a stateless manner at extremely low costs, while the execution of rich-stateful smart contracts can be performed with the usual scalability of rollups.\nA specific implementation method involves a smart contract that verifies ZKP-TLCs in a payment channel and only requires reading the storage of other smart contracts. This allows the conditions of the ZKP-TLC to be set based on the storage state of other smart contracts. An important point is that this storage has an immutable nature, meaning it is necessary to be able to withdraw under the same conditions even after some time has passed and the channel is closed.\nERnewpost (21)960×540 39.6 KB\nWe can construct the protocol like this. The condition of the ZKP-TLC from Alice to Bob is defined as the proof of a bulk-token-transfer, labeled X, and an onchain storage, marked Y. The contract is configured such that the onchain storage Y is immutably finalized only when X has been satisfied. Only after these prerequisites are confirmed can Bob proceed with the bulk-token-transfer. Once Y is settled, the ZKP-TLC is also considered settled. Programming Y as a transfer of value from any Carol to Alice would enable the construction of an extensive DEX.\nMeanwhile, executing this transfer of value from Carol to Alice as a transaction on Plasma Next becomes feasible by setting the proofs of both transfer trees as the conditions for the ZKP-TLCs of both parties.\nERnewpost (16)960×540 34.5 KB\nIf Bob does not make both trees, the swap will be canceled. If Bob makes only one of them, Bob will lose his fund of the payment.\nIn short, if the completion function of ZKP-TLC is a pure function in the context of EVM, it is a stateless application. If a view function is necessary, then it is a stateful application.\nChallenges\nThe operator conducts transfers using a separate Merkle tree from the channel, requiring liquidity separate from that of the channel. This implies a deterioration in capital efficiency. Fortunately, the hub can close the channel immediately since the last commitment is always the best for a hub in a one-way payment channel. So a well-managed closing operation is basically the best solution of this problem.\nConclusion\nIn the specific context of payments, it has been possible to eliminate the online requirement from Plasma. This result, in other words, suggests that the Turing completeness of Ethereum and ZKPs can eliminate the need for online requirements to monitor the network—such as the need for watchtowers—and even the necessity to open channels for receiving payments.\nRelated Works\n\nPlasma by Joseph Poon and Vitalik Buterin\nPlasma Cash by Vitalik Buterin\nPlasma Prime\nPlasma Snapp by josojo\nCross Rollup Payment Channel\nLightning Network by Joseph Poon and Thaddeus Dryja\nbitcoinj. Working with micropayment channels\nImpossibility of Stateless Blockchains\nLimits on Stateless Blockchains by Miranda Christ and Joseph Bonneau\n\n Plasma Next Next (Beetlejuice Beetlejuice)\n\n Deterministic Consensus using Overpass Channels [𝗏.2] in Distributed Ledger Technology\n\n 4\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n 2 months later\n\n post by chokermaxx on Apr 14, 2024\n\n chokermaxx\n\n My understanding is that unlike Lightning Network, Plasma Next does not offer instant finality. The receiver has to wait until the next block to be sure that he has received the funds. This is because the operator might censor a transaction, and might not include the transfer from the operator to the receiver in the next bulk token transfer published on-chain. Is it possible to overcome this by incorporating some kind of forced inclusion mechanism? i.e. by making it possible for the receiver to independently publish a fraud proof on-chain that says like “the operator has agreed to transfer xETH to me at merkle path P in the bulk token transfer at block height H but it’s not included on-chain!”. The chain will verify the fraud proof, and if the proof is valid, the chain will let the receiver withdraw xETH.\nIf this is possible the receiver will no longer have to wait until the next block to be sure that he will be able to withdraw xETH.\nI just thought that I need instant finality if I were to use crypto payments irl to buy a coffee. If instant finality is possible in Plasma Next it would be awesome as it would unlock trustless irl payments.\n\n post by chokermaxx on Apr 14, 2024\n\n chokermaxx\n\n ah my bad instant finality on Plasma Next is hard because the way it prevents double spending is different from Lightning. unlike Lightning Plasma Next doesn’t lock liquidity per receipent. It locks liquidity per operator. (which is awesome) So until the operator publishes bulk token transfer on-chain receipents can’t be sure that there will be no double spending of the operator’s funds. And this makes instant finality hard.\n\n post by leohio on Apr 18, 2024\n\n leohio\n\nIt’s true. I think the trustless and instant finality is what only LN has today, but we can have an semi fast finality as soon as the Merkle tree is generated when the operator(hub) has enough fund since we can make everybody able to submit the tree to the L1.\n\nSo I don’t think we need a forced tx queue for this, and we can’t have the perfect fast finality anyway imo. It’s just as you give up it in the later comment.\n\n post by Dobrokhvalov on Apr 25, 2024\n\n Dobrokhvalov\n\n Hi @leohio, Plasma Next seems to be an interesting scalability solution. However, I’m trying to figure out how this system prevents the same coin to be withdrawn more than once when Operator is offline and unavailable.\nFor example, consider the following scenario:\n\nAlice deposits 1 ETH in Plasma Next at block 0.\nAlice sends 1 ETH to Carol via ZKP-TLC. First, she transfers 1 ETH to Operator (Bob), Bob sends it further to Carol at block 1.\nCarol sends 1 ETH to John the same way via ZKP-TLC at block 2\nOperator (Bob) stops providing service and goes offline.\nAlice withdraws 1 ETH using her deposit transaction she made at block 0.\nJohn also withdraws the same 1 ETH using the payment proof he received from Carol at block 2.\n\nHow does the design of Plasma Next stop this from happening? Thanks!\n\n post by leohio on Apr 27, 2024\n\n leohio\n\n Thanks for the feedback!\n\nIn short, Bob lost 1 ETH with this deal.\n\nOk, Alice can withdraw her 1 ETH invalidly since Bob(Operator) went offline, Yes she can.\nAnd Bob sent the 1 ETH to Carol, which will be finally withdrawn by John as well. This 1 ETH is totally separated from the 1 ETH which Alice sent.\nWe can say, Bob had 1 ETH at the beginning and got sent 1 ETH from Alice in the channel between them (Not in the new tree), and Bob sent 1 ETH to Carol (In the new tree).\nBasically, only Bob(Operator) needs to be online always, and he can lose his money when he go offline.\n\n post by Dobrokhvalov on Apr 29, 2024\n\n Dobrokhvalov\n\n Thanks for your response @leohio. Does this mean that for every new Plasma recipient, Bob (the Operator) needs to open and fund a channel with his own ETH? For instance, in the scenario you mentioned, would Bob need to lock an additional two ETH: one for when Alice sends 1 ETH to Carol and another when Carol sends it on to John?\n\n post by leohio on May 5, 2024\n\n leohio\n\n Yes. This system is not capital efficient for an operator and basically rather cut out for micro-payments.\nIf you allow online requirement sometimes, it removes that inefficiency. There is a trilemma between statelessness/capital efficiency/offline safety.\n\n Powered by Discourse","tokens":5859,"squid":"ink-research","role":"Deep Scholar","at":1791257886634,"hash":"a7586f5b851a317a8c57fc0d83073a299f92c292"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/how-it-works","domain":"docs.pyth.network","title":"How the upgraded Pyth Core works | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradeHow the upgraded Pyth Core worksA technical look at the signers, data flow, and contracts behind the upgrade.The upgraded Pyth Core leverages the high-performance\nPyth Pro architecture while preserving the existing\ninterfaces, so existing integrations work with no code changes. This page\nexplains the new architecture and how it works.\nArchitecture Overview\n\nData flow\n\nAggregate & Sign: Each tick, the five Pyth Pro routers independently\ncompute the price aggregates for all price feeds, compress them into a\nMerkle tree using Pythnet's leaf format, and sign the resulting Merkle root.\nData Collection: The upgraded Hermes endpoint gathers the signed roots and\nprice messages from all routers.\nUpdate Submission: Consumers fetch the signed root and Merkle proofs from\nHermes and submit them to the upgraded contract.\nOn-Chain Verification: The upgraded contracts verify that the router\nsignatures meet the quorum and validate the requested price aggregate against the Merkle\nroot.\n\nComponents\nRouters\nThe network consists of five independently operated routers. They use the same\nECDSA signature scheme as the existing Wormhole guardians.\nUpgraded Hermes endpoint\nThe upgraded Hermes endpoint is hosted at a new URL but remains completely\nbackward-compatible with standard Hermes. It exposes the identical HTTP and\nWebSocket API endpoints and returns the same payload structures.\nUpgraded Pyth Core Contract\nThese are newly deployed contracts on each supported blockchain. They share\nthe exact same ABI and interface as the legacy contracts, eliminating the\nneed for any downstream code modifications.\nComparison: Existing vs. Upgraded Pyth Core\nWhile the upgraded Pyth Core is designed to be fully compatible with existing\ncontracts and tools, there are key differences in how the underlying data is\naggregated, signed, and verified.\nHere is a side-by-side comparison of the two architectures:\nFeatureExisting Pyth CoreUpgraded Pyth CoreData Sourcing & Root ProductionPythnet5 Independent Routers (via Pyth Pro)Signer NetworkWormhole Guardians5 Independent RoutersQuorum Threshold13/19 Signatures3/5 SignaturesSignature SchemeECDSA (Secp256k1)ECDSA (Secp256k1) (Same)Hermes CompatibilityStandard Hermes EndpointUpgraded Hermes Endpoint (Same API)Contract ABIExisting ABIIdentical ABI (Deployed at New Addresses)\nWhat this means for consumers\nPyth Core was upgraded on August 26, 2026 at 16:00 UTC. Make sure your integration is up to\ndate by following the upgrade guide.\nYou can also view the upgraded Pyth Core Contract addresses\nfor the new contract addresses on each supported chain.All Contract AddressesPyth Core (current), upgraded Pyth Core, and Pyth Pro contract addresses side by side for every supported chain.Create your first Pyth appBuild your first application that consumes Pyth price feeds","tokens":709,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257893807,"hash":"6b6258d1dec344f8b433ba0de62b1bdd610101a7"}
{"url":"https://www.anchor-lang.com/docs/features/events","domain":"anchor-lang.com","title":"Emit Events","text":"Additional FeaturesEmit EventsLearn how to emit events in Anchor programs using emit! and emit_cpi! macros.Examples\nAnchor provides two macros for emitting events in your programs:\n\nemit!() - Emits events directly to program logs. This is the simpler,\nthough program logs may be truncated by data providers in some cases\nemit_cpi!() - Emits events through a Cross Program Invocation (CPI) by\nincluding the event data in the instruction data.\n\nThe emit_cpi() approach was introduced an alternative to program logs, which\ncan sometimes be truncated by data providers. While CPI instruction data is less\nlikely to be truncated, this approach does incur additional compute costs from\nthe Cross Program Invocation.\nFor more robust solutions for events, consider geyser gRPC services by\nTriton\nor Helius.\nemit\nThe\nemit!()\nmacro provides a way to emit events through program logs. When called, it:\n\nUses the\nsol_log_data()\nsyscall to write the data to program logs\nEncodes the event data as a\nbase64 string\nprefixed with Program Data:\n\nTo receive emitted events in your client application, use the\naddEventListener()\nmethod. This method automatically\nparses and decodes\nevent data from the program logs.\nExample usage:\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"8T7MsCZyzxboviPJg5Rc7d8iqEcDReYR2pkQKrmbg7dy\");\n\n#[program]\npub mod event {\n use super::*;\n\n pub fn emit_event(_ctx: Context<EmitEvent>, input: String) -> Result<()> {\n emit!(CustomEvent { message: input });\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct EmitEvent {}\n\n#[event]\npub struct CustomEvent {\n pub message: String,\n}\n\nThe following is the output of the program logs. The event data is base64\nencoded as Zb1eU3aiYdwOAAAASGVsbG8sIFNvbGFuYSE=.\nProgram LogsLog Messages:\n Program 8T7MsCZyzxboviPJg5Rc7d8iqEcDReYR2pkQKrmbg7dy invoke [1]\n Program log: Instruction: EmitEvent\n Program data: Zb1eU3aiYdwOAAAASGVsbG8sIFNvbGFuYSE=\n Program 8T7MsCZyzxboviPJg5Rc7d8iqEcDReYR2pkQKrmbg7dy consumed 1012 of 200000 compute units\n Program 8T7MsCZyzxboviPJg5Rc7d8iqEcDReYR2pkQKrmbg7dy success\n\nEnsure the RPC provider you use does not truncate the program logs from the\ntransaction data.\nemit_cpi\nThe\nemit_cpi!()\nmacro emits events through Cross Program Invocations (CPIs) to the program\nitself. The event data is encoded and included in the CPI's instruction data\n(instead of program logs).\nTo emit events through CPIs, you need to enable the event-cpi feature in your\nprogram's Cargo.toml:\nCargo.toml[dependencies]\nanchor-lang = { version = \"1.2.0\", features = [\"event-cpi\"] }\nExample usage:\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1\");\n\n#[program]\npub mod event_cpi {\n use super::*;\n\n pub fn emit_event(ctx: Context<EmitEvent>, input: String) -> Result<()> {\n emit_cpi!(CustomEvent { message: input });\n Ok(())\n }\n}\n\n#[event_cpi]\n#[derive(Accounts)]\npub struct EmitEvent {}\n\n#[event]\npub struct CustomEvent {\n pub message: String,\n}\nThe\nevent_cpi\nattribute must be added to the #[derive(Accounts)] struct for the instruction\nthat emits events using the emit_cpi!() macro. This attribute\nautomatically includes additional accounts\nthat are required for the self CPI.\nlib.rs#[event_cpi]\n#[derive(Accounts)]\npub struct RequiredAccounts {\n // --snip--\n}\nTo get the emitted event data in your client application, you need to fetch the\ntransaction using the transaction signature and parse the event data from the\nCPI instruction data.\ntest.ts// 1. Fetch the full transaction data using the transaction signature\nconst transactionData = await program.provider.connection.getTransaction(\n transactionSignature,\n { commitment: \"confirmed\" },\n);\n\n// 2. Extract the CPI (inner instruction) that contains the event data\nconst eventIx = transactionData.meta.innerInstructions[0].instructions[0];\n\n// 3. Decode the event data\nconst rawData = anchor.utils.bytes.bs58.decode(eventIx.data);\nconst base64Data = anchor.utils.bytes.base64.encode(rawData.subarray(8));\nconst event = program.coder.events.decode(base64Data);\nconsole.log(event);\nBelow is an example transaction showing how event data appears in the\ntransaction details. When using emit_cpi!(), the event data is encoded and\nincluded in the data field of an inner instruction (CPI).\nIn the example transaction below, the encoded event data is\n\"data\": \"6AJcBqZP8afBKheoif1oA6UAiLAcqYr2RaR33pFnEY1taQp\" in the\ninnerInstructions array.\n\nTransaction Data{\n \"blockTime\": 1735854530,\n \"meta\": {\n \"computeUnitsConsumed\": 13018,\n \"err\": null,\n \"fee\": 5000,\n \"innerInstructions\": [\n {\n \"index\": 0,\n \"instructions\": [\n {\n \"accounts\": [\n 1\n ],\n \"data\": \"6AJcBqZP8afBKheoif1oA6UAiLAcqYr2RaR33pFnEY1taQp\",\n \"programIdIndex\": 2,\n \"stackHeight\": 2\n }\n ]\n }\n ],\n \"loadedAddresses\": {\n \"readonly\": [],\n \"writable\": []\n },\n \"logMessages\": [\n \"Program 2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1 invoke [1]\",\n \"Program log: Instruction: EmitEvent\",\n \"Program 2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1 invoke [2]\",\n \"Program 2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1 consumed 5000 of 192103 compute units\",\n \"Program 2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1 success\",\n \"Program 2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1 consumed 13018 of 200000 compute units\",\n \"Program 2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1 success\"\n ],\n \"postBalances\": [\n 499999999999995000,\n 0,\n 1141440\n ],\n \"postTokenBalances\": [],\n \"preBalances\": [\n 500000000000000000,\n 0,\n 1141440\n ],\n \"preTokenBalances\": [],\n \"rewards\": [],\n \"status\": {\n \"Ok\": null\n }\n },\n \"slot\": 3,\n \"transaction\": {\n \"message\": {\n \"header\": {\n \"numReadonlySignedAccounts\": 0,\n \"numReadonlyUnsignedAccounts\": 2,\n \"numRequiredSignatures\": 1\n },\n \"accountKeys\": [\n \"4kh6HxYZiAebF8HWLsUWod2EaQQ6iWHpHYCz8UcmFbM1\",\n \"2brZf9PQqEvv17xtbj5WNhZJULgVZuLZT6FgH1Cqpro2\",\n \"2cDQ2LxKwQ8fnFUz4LLrZ157QzBnhPNeQrTSmWcpVin1\"\n ],\n \"recentBlockhash\": \"2QtnU35RXTo7uuQEVARYJgWYRYtbqUxWQkK8WywUnVdY\",\n \"instructions\": [\n {\n \"accounts\": [\n 1,\n 2\n ],\n \"data\": \"3XZZ984toC4WXCLkxBsLimpEGgH75TKXRJnk\",\n \"programIdIndex\": 2,\n \"stackHeight\": null\n }\n ],\n \"indexToProgramIds\": {}\n },\n \"signatures\": [\n \"3gFbKahSSbitRSos4MH3cqeVv2FiTNaLCuWaLPo6R98FEbHnTshoYxopGcx74nFLqt1pbZK9i8dnr4NFXayrMndZ\"\n ]\n }\n}\n\nCurrently, event data emitted through CPIs cannot be directly subscribed to.\nTo access this data, you must fetch the complete transaction data and manually\ndecode the event information from the instruction data of the CPI.PreviousCustom ErrorsNextZero CopyOn this pageExamplesemitemit_cpiEdit on GitHub","tokens":1619,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257893853,"hash":"071e2102ae752b49c36154d7a47119c301a24e88"}
{"url":"https://ethresear.ch/tag/stateless/4","domain":"ethresear.ch","title":"Latest stateless topics - Ethereum Research","text":"Latest topics tagged stateless\n\n categories\n\n stateless\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\n\n Execution Layer Research\n\n stateless\n\n 10\n\n 783\n\n 4d\n\n Scaling Ethereum with recursive STARKs and the Trustless Log Index\n\n Execution Layer Research\n\n stateless,cross-shard\n\n 0\n\n 159\n\n 21d\n\n Bloom Filters And Keyed Nonces\n\n Privacy\n\n stateless\n\n 0\n\n 224\n\n 28d\n\n Native UTXOs on Ethereum\n\n Execution Layer Research\n\n stateless,utxo\n\n 30\n\n 4.4k\n\n 28d\n\n An Evaluation of Authenticated UTXO Discovery with EIP-8304 and UTXO Proof Tables\n\n Execution Layer Research\n\n stateless,utxo\n\n 0\n\n 118\n\n Aug 27\n\n Why Decentralized State is important for Ethereum\n\n Execution Layer Research\n\n stateless\n\n 0\n\n 106\n\n Aug 4\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n Sharding\n\n mev,stateless,zk-roll-up,data-availability,cross-shard\n\n 0\n\n 475\n\n Jul 6\n\n Sharded PIR Design for the Ethereum State\n\n Privacy\n\n mev,stateless\n\n 4\n\n 1.2k\n\n Jun 30\n\n The Anatomy of Ethereum’s State Access\n\n Execution Layer Research\n\n stateless,execution\n\n 0\n\n 586\n\n Jun 29\n\n Hot-Cold Storage Separation in Practice\n\n Execution Layer Research\n\n stateless\n\n 0\n\n 214\n\n Jun 7\n\n Why Homogenizing the Execution of the World-Computer Beats Scaling Through Fragmentation\n\n Sharding\n\n stateless,data-availability\n\n 0\n\n 198\n\n May 13\n\n Block Update Digests: Membership Proofs Without a Global State Tree\n\n Execution Layer Research\n\n stateless,rollup,sparse-merkle-tree,state-execution-separation\n\n 1\n\n 414\n\n May 7\n\n A Protocol Design View on Statelessness\n\n Economics\n\n stateless\n\n 7\n\n 1.2k\n\n Apr 16\n\n Frame Transactions Through a Statelessness Lens\n\n Execution Layer Research\n\n stateless\n\n 11\n\n 733\n\n Apr 15\n\n What if we only kept 1 year of active state?\n\n Execution Layer Research\n\n stateless,execution\n\n 0\n\n 189\n\n Jan 30\n\n BALs for Proposer Commitments\n\n Execution Layer Research\n\n stateless,preconfirmations\n\n 2\n\n 445\n\n Dec 2025\n\n The Future of State, Part 2: Beyond The Myth of Partial Statefulness & The Reality Of ZKEVMs\n\n Execution Layer Research\n\n stateless\n\n 5\n\n 790\n\n Nov 2025\n\n State Expiry: In-protocol vs. Out-of-protocol\n\n Execution Layer Research\n\n stateless,data-availability,execution\n\n 8\n\n 685\n\n Oct 2025\n\n Payload Chunking\n\n Sharding\n\n stateless,data-availability,chunking\n\n 8\n\n 937\n\n Sep 2025\n\n Ethereum Bytecode and Code Chunk Analysis\n\n Execution Layer Research\n\n stateless\n\n 0\n\n 202\n\n Jul 2025\n\n Native rollups—superpowers from L1 execution\n\n Layer 2\n\n stateless\n\n 41\n\n 11.3k\n\n Jul 2025\n\n A pragmatic path towards Validity-Only Partial Statelessness (VOPS)\n\n Execution Layer Research\n\n stateless\n\n 14\n\n 2.1k\n\n Jun 2025\n\n Enshrined Native L2s and Stateless Block Building\n\n Sharding\n\n stateless,zk-roll-up\n\n 5\n\n 597\n\n May 2025\n\n Merkelizing Bytecode: Options & Tradeoffs\n\n Execution Layer Research\n\n stateless\n\n 2\n\n 481\n\n May 2025\n\n A short note on Post Quantum Verkle explorations\n\n Execution Layer Research\n\n stateless\n\n 0\n\n 690\n\n Mar 2025\n\n An Enshrined Long-Term Storage (eLTS) L2\n\n stateless\n\n 0\n\n 194\n\n Feb 2025\n\n State tree preimages file generation\n\n Execution Layer Research\n\n stateless\n\n 0\n\n 348\n\n Jan 2025\n\n Enabling standardized on chain executions through modular accounts\n\n Execution Layer Research\n\n stateless,account-abstraction,transaction-privacy,signature-aggregation,zk-id\n\n 4\n\n 3.6k\n\n Aug 2024\n\n Plasma Next Next (Beetlejuice Beetlejuice)\n\n Plasma\n\n stateless\n\n 6\n\n 3.8k\n\n May 2024\n\n Plasma Next: Plasma without Online Requirements\n\n Plasma\n\n stateless\n\n 7\n\n 6.6k\n\n May 2024","tokens":927,"squid":"ink-research","role":"Deep Scholar","at":1791257897485,"hash":"36a9f6b690e56a06520082091554e181521d3b74"}
{"url":"https://docs.pyth.network/price-feeds/core/upgrade/preparing/evm","domain":"docs.pyth.network","title":"EVM | Pyth Developer Hub","text":"Pyth CorePyth Core UpgradeCompleting the Pyth Core upgradeEVMEVM-specific notes for the Pyth Core upgrade.These notes complement the main upgrade guide for EVM consumers.\nHermes client (viem and ethers)\nThe Hermes client is the same shape regardless of which contract library you use. Instantiate HermesClient with the upgraded endpoint and your API key:\nimport { HermesClient } from \"@pythnetwork/hermes-client\";\n\nconst hermes = new HermesClient(\n \"https://pyth.dourolabs.app/hermes\",\n { accessToken: process.env.PYTH_API_KEY },\n);\n\n// Pass the resulting payload to your viem contract:\n// await pythContract.write.updatePriceFeeds([update.binary.data], { value: fee });\nThe contract call itself follows your ABI library. Use pythContract.write.updatePriceFeeds(...) in viem, pythContract.updatePriceFeeds(...) in ethers.\nUpgraded EVM Addresses\nView on the contract addresses page →Completing the Pyth Core upgradeEverything you need to bring your Pyth Core integration up to date with the August 26, 2026 upgrade.for SVM chainsNext Page","tokens":259,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257916525,"hash":"b88c983a45a74aa771a4fe99bce362f61dc9bb02"}
{"url":"https://www.anchor-lang.com/docs/features/errors","domain":"anchor-lang.com","title":"Custom Errors","text":"Additional FeaturesCustom ErrorsLearn how to implement custom error handling in Anchor programs.All instruction handlers in Anchor programs return a custom Result<T> type\nthat allows you to handle successful execution with Ok(T) and error cases with\nErr(Error).\npub fn custom_instruction(ctx: Context<CustomInstruction>) -> Result<()> {\n // --snip--\n Ok(())\n}\nThe\nResult<T>\ntype in Anchor programs is a type alias that wraps the standard Rust\nResult<T, E>. In this case, T represents the successful return type, while\nE is Anchor's custom Error type.\npub type Result<T> = std::result::Result<T, error::Error>;\nAnchor Error\nWhen an error occurs in an Anchor program, it returns a custom\nError\ntype defined as:\n#[derive(Debug, PartialEq, Eq)]\npub enum Error {\n AnchorError(Box<AnchorError>),\n ProgramError(Box<ProgramErrorWithOrigin>),\n}\nThe Error type in Anchor programs can be one of two variants:\n\nProgramErrorWithOrigin:\nCustom type that wraps a standard Solana\nProgramError\ntype. These errors come from the solana_program crate.\n\n#[derive(Debug)]\npub struct ProgramErrorWithOrigin {\n pub program_error: ProgramError,\n pub error_origin: Option<ErrorOrigin>,\n pub compared_values: Option<ComparedValues>,\n}\n\nAnchorError:\nErrors defined by the Anchor framework.\n\n#[derive(Debug)]\npub struct AnchorError {\n pub error_name: String,\n pub error_code_number: u32,\n pub error_msg: String,\n pub error_origin: Option<ErrorOrigin>,\n pub compared_values: Option<ComparedValues>,\n}\nAn AnchorError can be thought of as having two categories:\n\nInternal Anchor Errors - These are built-in errors included with the Anchor\nframework. They are defined in the\nErrorCode\nenum.\n\nCustom Program Errors - These are program specific errors that developers\ndefine to handle custom error cases.\n\nThe error_code_number from an AnchorError has the following numbering\nscheme:\nError CodeDescription>= 100Instruction error codes>= 1500Event error codes>= 2000Constraint error codes>= 3000Account error codes>= 4100Misc error codes= 5000Deprecated error code>= 6000Starting point for custom user errors\nUsage\nAnchor provides a convenient way to define custom errors through the\nerror_code attribute. The implementation details can be found\nhere.\nWhen you define an enum with the error_code attribute, Anchor automatically:\n\nAssigns an error code starting from 6000\nGenerates the necessary boilerplate for error handling\nEnables the use of custom error messages via the msg attribute\n\n#[error_code]\npub enum MyError {\n #[msg(\"My custom error message\")]\n MyCustomError,\n #[msg(\"My second custom error message\")]\n MySecondCustomError,\n}\nerr!\nTo throw an error, use the\nerr!\nmacro. The err! macro provides a convenient way to return custom errors from\nyour program. Under the hood, err! uses the error! macro to construct\nAnchorError. The implementation can be found\nhere.\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn set_data(ctx: Context<SetData>, data: MyAccount) - Result<()> {\n if data.data = 100 {\n return err!(MyError::DataTooLarge);\n }\n ctx.accounts.my_account.set_inner(data);\n Ok(())\n }\n}\n\n#[error_code]\npub enum MyError {\n #[msg(\"MyAccount may only hold data below 100\")]\n DataTooLarge\n}\nrequire!\nThe\nrequire!\nmacro provides a more concise way to handle error conditions. It combines a\ncondition check with returning an error if the condition is false. Here's how we\ncan rewrite the previous example using require!:\n#[program]\nmod hello_anchor {\n use super::*;\n pub fn set_data(ctx: Context<SetData>, data: MyAccount) - Result<()> {\n require!(data.data < 100, MyError::DataTooLarge);\n ctx.accounts.my_account.set_inner(data);\n Ok(())\n }\n}\n\n#[error_code]\npub enum MyError {\n #[msg(\"MyAccount may only hold data below 100\")]\n DataTooLarge\n}\nAnchor provides several \"require\" macros for different validation needs. You can\nfind the implementation of these macros\nhere.\nMacroDescriptionrequire!Ensures a condition is true, otherwise returns with the given error.require_eq!Ensures two NON-PUBKEY values are equal.require_neq!Ensures two NON-PUBKEY values are not equal.require_keys_eq!Ensures two pubkeys values are equal.require_keys_neq!Ensures two pubkeys are not equal.require_gt!Ensures the first NON-PUBKEY value is greater than the second NON-PUBKEY value.require_gte!Ensures the first NON-PUBKEY value is greater than or equal to the second NON-PUBKEY value.\nExample\nHere's a simple example demonstrating how to define and handle custom errors in\nan Anchor program. The program below validates that an input amount falls within\nan acceptable range, showing how to:\n\nDefine custom error types with messages\nUse the require! macro to check conditions and return errors\n\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"9oECKMeeyf1fWNPKzyrB2x1AbLjHDFjs139kEyFwBpoV\");\n\n#[program]\npub mod custom_error {\n use super::*;\n\n pub fn validate_amount(_ctx: Context<ValidateAmount>, amount: u64) - Result<()> {\n require!(amount >= 10, CustomError::AmountTooSmall);\n require!(amount <= 100, CustomError::AmountTooLarge);\n\n msg!(\"Amount validated successfully: {}\", amount);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct ValidateAmount {}\n\n#[error_code]\npub enum CustomError {\n #[msg(\"Amount must be greater than or equal to 10\")]\n AmountTooSmall,\n #[msg(\"Amount must be less than or equal to 100\")]\n AmountTooLarge,\n}\nWhen a program error occurs, Anchor's TypeScript Client SDK returns a detailed\nerror response\ncontaining information about the error. Here's an example error response showing\nthe structure and available fields:\nError Response{\n errorLogs: [\n 'Program log: AnchorError thrown in programs/custom-error/src/lib.rs:11. Error Code: AmountTooLarge. Error Number: 6001. Error Message: Amount must be less than or equal to 100.'\n ],\n logs: [\n 'Program 9oECKMeeyf1fWNPKzyrB2x1AbLjHDFjs139kEyFwBpoV invoke [1]',\n 'Program log: Instruction: ValidateAmount',\n 'Program log: AnchorError thrown in programs/custom-error/src/lib.rs:11. Error Code: AmountTooLarge. Error Number: 6001. Error Message: Amount must be less than or equal to 100.',\n 'Program 9oECKMeeyf1fWNPKzyrB2x1AbLjHDFjs139kEyFwBpoV consumed 2153 of 200000 compute units',\n 'Program 9oECKMeeyf1fWNPKzyrB2x1AbLjHDFjs139kEyFwBpoV failed: custom program error: 0x1771'\n ],\n error: {\n errorCode: { code: 'AmountTooLarge', number: 6001 },\n errorMessage: 'Amount must be less than or equal to 100',\n comparedValues: undefined,\n origin: { file: 'programs/custom-error/src/lib.rs', line: 11 }\n },\n _programErrorStack: ProgramErrorStack {\n stack: [\n [PublicKey [PublicKey(9oECKMeeyf1fWNPKzyrB2x1AbLjHDFjs139kEyFwBpoV)]]\n ]\n }\n}\nFor a more comprehensive example, you can also reference the\nerrors test program\nin the Anchor repository.PreviousDependency Free ComposabilityNextEmit EventsOn this pageAnchor ErrorUsageerr!require!ExampleEdit on GitHub","tokens":1696,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257916573,"hash":"1c4bd71191a36235ee9787dc92d0ccf17b047380"}
{"url":"https://ethresear.ch/tag/data-availability/18","domain":"ethresear.ch","title":"Latest data-availability topics - Ethereum Research","text":"Latest topics tagged data-availability\n\n categories\n\n data-availability\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n FullDAS: towards massive scalability with 32MB blocks and beyond\n\n Sharding\n\n data-availability,p2p,scaling\n\n 2\n\n 5.0k\n\n 19d\n\n RowDAS (EIP-8371): Distributed Blob Reconstruction, measured\n\n Networking\n\n data-availability,p2p\n\n 0\n\n 244\n\n 24d\n\n Formally Verified Security for PQ-DAS / leanDA\n\n Cryptography\n\n data-availability,post-quantum\n\n 0\n\n 165\n\n Aug 18\n\n LeanDA: Design and Benchmark\n\n Sharding\n\n data-availability,post-quantum\n\n 0\n\n 479\n\n Aug 7\n\n Can a CEX microstructure signal survive Ethereum execution latency and MEV?\n\n Economics\n\n mev,data-availability,execution,market-microstructure\n\n 0\n\n 141\n\n Jul 28\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n Sharding\n\n mev,stateless,zk-roll-up,data-availability,cross-shard\n\n 0\n\n 475\n\n Jul 6\n\n PeerDAS - 30% acceleration for 4x less memory usage\n\n Consensus\n\n data-availability\n\n 0\n\n 147\n\n May 27\n\n Why Homogenizing the Execution of the World-Computer Beats Scaling Through Fragmentation\n\n Sharding\n\n stateless,data-availability\n\n 0\n\n 198\n\n May 13\n\n Alternatives to 2D Reed-Solomon Codes in DAS\n\n Sharding\n\n data-availability,rollup\n\n 0\n\n 181\n\n Apr 13\n\n Blob Analysis after Fusaka and BPO Updates\n\n Sharding\n\n data-availability\n\n 2\n\n 853\n\n Apr 9\n\n Why a Variable Payload Deadline Only Helps by ~6%\n\n Proof-of-Stake\n\n mev,data-availability\n\n 0\n\n 139\n\n Mar 23\n\n Using Rateless Coding for DAS\n\n Sharding\n\n data-availability\n\n 3\n\n 267\n\n Jan 14\n\n EIP-8077: Nonce Gap Simulation Report\n\n Sharding\n\n data-availability,rollup,p2p\n\n 0\n\n 200\n\n Dec 2025\n\n Framework for AltDA Secure Integration on Ethereum\n\n Layer 2\n\n data-availability\n\n 0\n\n 377\n\n Dec 2025\n\n Subcommitments: Off-Chain Finality — Fast, Secure, and Cheap\n\n ZK Rollup\n\n zk-roll-up,data-availability,rollup\n\n 1\n\n 306\n\n Nov 2025\n\n Variants of Mempool Tickets\n\n Economics\n\n data-availability\n\n 2\n\n 347\n\n Oct 2025\n\n State Expiry: In-protocol vs. Out-of-protocol\n\n Execution Layer Research\n\n stateless,data-availability,execution\n\n 8\n\n 685\n\n Oct 2025\n\n Alternative DAS concept based on RLNC\n\n Sharding\n\n data-availability\n\n 2\n\n 755\n\n Sep 2025\n\n Payload Chunking\n\n Sharding\n\n stateless,data-availability,chunking\n\n 8\n\n 937\n\n Sep 2025\n\n PeerDas Documentation\n\n Sharding\n\n data-availability\n\n 1\n\n 773\n\n Sep 2025\n\n Gossipsub’s Partial Messages Extension and Cell Level dissemination\n\n Networking\n\n data-availability\n\n 2\n\n 603\n\n Sep 2025\n\n Revisiting Secure DAS in One and Two Dimensions\n\n Sharding\n\n data-availability\n\n 0\n\n 655\n\n Jul 2025\n\n The State of Type 3 Transactions After Pectra: One Month of Blob Data Activity\n\n Sharding\n\n data-availability\n\n 2\n\n 471\n\n Jul 2025\n\n Blob Notaries: a distributed blob publishing design to scale DA\n\n Sharding\n\n data-availability\n\n 0\n\n 648\n\n Jul 2025\n\n Improving column propagation with cell-centric erasure/network coding\n\n Networking\n\n data-availability\n\n 3\n\n 633\n\n Jul 2025\n\n A pathway for GDPR Data Management & Privacy for Ethereum\n\n Privacy\n\n zk-roll-up,data-availability,transaction-privacy,pet\n\n 6\n\n 1.1k\n\n Jun 2025\n\n A new design for DAS and Sharded Blob Mempools\n\n Sharding\n\n data-availability\n\n 2\n\n 652\n\n Jun 2025\n\n Accelerating blob scaling with FullDASv2 (with getBlobs, mempool encoding, and possibly RLC)\n\n Networking\n\n data-availability,p2p,layer-2,scaling\n\n 0\n\n 568\n\n May 2025\n\n Empirical blob sidecar hit rate based on local EL’s mempool\n\n Networking\n\n data-availability\n\n 0\n\n 273\n\n May 2025\n\n StorageBeat: Towards an evaluation framework for decentralised storage\n\n Sharding\n\n data-availability,storage-fee-rent\n\n 10\n\n 653\n\n May 2025","tokens":939,"squid":"ink-research","role":"Deep Scholar","at":1791257920226,"hash":"c1af367e98722d826762d1456f70fef194bbef70"}
{"url":"https://docs.pyth.network/price-feeds/core/use-real-time-data","domain":"docs.pyth.network","title":"How to Use Real-Time Price Data | Pyth Developer Hub","text":"Pyth CoreHow to Use Real-Time Price DataGuides for using Pyth real-time price feedsThe following guides demonstrate how to consume Pyth real-time prices on various blockchains.\nThese guides are intended for developers building on-chain applications that need the latest price data, i.e., the price data must\nbe on the blockchain.\nPyth price feeds are available on 100+ blockchains.\nCheck out the complete list of chains and implementation contract addresses at Contract Addresses.\nIf your blockchain is not supported, please ask in the dev-forum.\nChoosing Your Integration Method\nPull integration is the default choice for most applications. In this integration, the application fetches price updates from a webservice and submits them to\nan on-chain smart contact as part of the transaction. This integration provides the lowest-latency access to Pyth price data.\nPush integration is for applications that don't want to pull prices in every transaction and prefer a purely on-chain integration.\nAll feeds are available through both integration methods. However, to use pull\nintegration, the application needs to submit the prices to the on-chain smart\ncontract as part of the transaction. Check out the Pull Integration section\nbelow to get started.\nPull Integration\nConsult the relevant ecosystem guide to get started using pull integration:\n\nEVM\nSolana\nSui\n\nPyth Core no longer supports Aptos,\nCosmWasm,\nFuel,\nIOTA,\nNEAR,\nStacks,\nStarknet, or\nTON.\nPush Integration\nTo consume real-time price data using push integration, check out the following guides:\n\nUsing Push Integration\n\nThis guide will walk you through the steps to use real-time price data using push integration in every ecosystem.\nOff-Chain Applications\nPyth price feeds can also be used in off-chain applications.\nFor example, an application may need to show real-time asset prices on a website.\nDevelopers building such applications can consult the following guide:\n\nOff-chain Apps\n\nTo fetch historical prices, application developers can check out the Use Historical Price Data guide.Part 2: Deploy Pyth AppPrevious Pagein EVM contractsNext Page","tokens":528,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257938590,"hash":"65307ec8b80799f8cf69fa03e644664eac0ef251"}
{"url":"https://www.anchor-lang.com/docs/features/zero-copy","domain":"anchor-lang.com","title":"Zero Copy","text":"Additional FeaturesZero CopyLearn how to use Anchor's zero-copy deserialization feature to handle large account data in Solana programs.Overview\nZero-copy deserialization allows programs to read and write account data\ndirectly from memory without copying or deserializing it. This is essential\nfor handling large accounts efficiently on Solana.\nWhy Use Zero-Copy?\nTraditional account deserialization (Account<T>) copies data from the account\ninto a heap-allocated struct. This has limitations:\n\nSize Constraints: Stack (4KB) and heap (32KB) limits restrict account\nsizes\nCompute Cost: Deserialization consumes significant compute units\nMemory Overhead: Data is duplicated in memory\n\nZero-copy (AccountLoader<T>) instead:\n\nDirect Access: Casts raw account bytes to the struct type (no copying)\nLarger Accounts: Supports accounts up to 10MB (10,485,760 bytes)\nLower Compute: ~90% reduction in CU usage for large accounts\nIn-Place Updates: Modifies account data directly\n\nPerformance Comparison\nAccount SizeAccount<T>AccountLoader<T>Improvement1 KB~8,000 CU~1,500 CU81% faster10 KB~50,000 CU~5,000 CU90% faster100 KBToo large~12,000 CUPossible1 MBImpossible~25,000 CUPossible\nWhen to Use Zero-Copy\nUse zero-copy for:\n\nAccounts larger than 1KB\n\nArrays with many elements (orderbooks, event queues)\n\nHigh-frequency operations\n\nCompute-sensitive programs\nUse regular Account<T> for:\n\nSmall accounts (< 1KB)\n\nDynamic data structures (Vec, String, HashMap)\n\nFrequently changing schemas\n\nSimple state that doesn't need optimization\n\nUsage\nZero copy is a deserialization feature that allows programs to read account data\ndirectly from memory without copying it. This is particularly useful when\nworking with large accounts.\nTo use zero-copy add the bytemuck crate to your dependencies. Add the\nmin_const_generics feature to allow working with arrays of any size in your\nzero-copy types.\nCargo.toml[dependencies]\nbytemuck = { version = \"1.20.0\", features = [\"min_const_generics\"] }\nanchor-lang = \"1.2.0\"\nDefine a Zero Copy Account\nTo define an account type that uses zero-copy, annotate the struct with\n#[account(zero_copy)].\n#[account(zero_copy)]\npub struct Data {\n // 10240 bytes - 8 bytes account discriminator\n pub data: [u8; 10232],\n}\nThe #[account(zero_copy)] attribute automatically implements several traits\nrequired for zero-copy deserialization:\n#[derive(Copy, Clone)]\n#[derive(bytemuck::Zeroable)]\n#[derive(bytemuck::Pod)]\n#[repr(C)]\nstruct Data {\n // --snip--\n}\nUse AccountLoader for Zero Copy Accounts\nTo deserialize a zero-copy account, use\nAccountLoader<'info, T>,\nwhere T is the zero-copy account type defined with the #[account(zero_copy)]\nattribute.\nFor example:\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub zero_copy_account: AccountLoader<'info, Data>,\n}\nInitialize a Zero Copy Account\nThe init constraint can be used with the AccountLoader type to create a\nzero-copy account.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(\n init,\n // 10240 bytes is max space to allocate with init constraint\n space = 8 + 10232,\n payer = payer,\n )]\n pub data_account: AccountLoader<'info, Data>,\n #[account(mut)]\n pub payer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\nThe init constraint is limited to allocating a maximum of 10240 bytes due to\nCPI limitations. Under the hood, the init constraint makes a CPI call to the\nSystemProgram to create the account.\nWhen initializing a zero-copy account for the first time, use\nload_init\nto get a mutable reference to the account data. The load_init method also sets\nthe account discriminator.\npub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_init()?;\n account.data = [1; 10232];\n Ok(())\n}\nFor accounts that require more than 10240 bytes, use the\nzero\nconstraint instead of init. The zero constraint verifies the account has not\nbeen initialized by checking that its discriminator has not been set.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(zero)]\n pub data_account: AccountLoader<'info, Data>,\n}\nWith the zero constraint, you'll need to first create the account in a\nseparate instruction by directly calling the System Program. This allows you to\ncreate accounts up to Solana's maximum account size of 10MB (10_485_760 bytes),\nbypassing the CPI limitation.\nJust as before, use load_init to get a mutable reference to the account data\nand set the account discriminator. Since 8 bytes are reserved for the account\ndiscriminator, the maximum data size is 10_485_752 bytes (10MB - 8 bytes).\npub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_init()?;\n account.data = [1; 10_485_752];\n Ok(())\n}\nUpdate a Zero Copy Account\nUse\nload_mut\nwhen you need mutable access to update an existing zero-copy account:\n#[derive(Accounts)]\npub struct Update<'info> {\n #[account(mut)]\n pub data_account: AccountLoader<'info, Data>,\n}\npub fn update(ctx: Context<Update>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_mut()?;\n account.data = [2; 10232];\n Ok(())\n}\nRead a Zero Copy Account\nUse\nload\nto only read the account data.\n#[derive(Accounts)]\npub struct ReadOnly<'info> {\n pub data_account: AccountLoader<'info, Data>,\n}\npub fn read_only(ctx: Context<ReadOnly>) -> Result<()> {\n let account = &ctx.accounts.data_account.load()?;\n msg!(\"First 10 bytes: {:?}\", &account.data[..10]);\n Ok(())\n}\nCommon Patterns\nNested Zero-Copy Types\nFor types used within zero-copy accounts, use #[zero_copy] (without\naccount):\n#[account(zero_copy)]\npub struct OrderBook {\n pub market: Pubkey,\n pub bids: [Order; 1000],\n pub asks: [Order; 1000],\n}\n\n//]\n#[zero_copy]\npub struct Order {\n pub trader: Pubkey,\n pub price: u64,\n pub quantity: u64,\n}\nAccessor Methods for Byte Arrays\nZero-copy uses #[repr(packed)], making field references unsafe. Use the\n#[accessor] attribute for safe getter/setter methods:\n#[account(zero_copy)]\npub struct Config {\n pub authority: Pubkey,\n #[accessor(Pubkey)]\n pub secondary_authority: [u8; 32],\n}\n\n// Usage:\nlet config = &mut ctx.accounts.config.load_mut()?;\nlet secondary = config.get_secondary_authority();\nconfig.set_secondary_authority(&new_authority);\nZero-Copy with PDAs\nZero-copy accounts work seamlessly with program-derived addresses:\n#[derive(Accounts)]\npub struct CreatePdaAccount<'info> {\n #[account(\n init,\n seeds = [b\"data\", authority.key().as_ref()],\n bump,\n payer = authority,\n space = 8 + std::mem::size_of::<Data>(),\n )]\n pub data_account: AccountLoader<'info, Data>,\n #[account(mut)]\n pub authority: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\nSeparate Types for RPC Parameters\nZero-copy types cannot derive AnchorSerialize/AnchorDeserialize. Use\nseparate types for instruction parameters:\n// For zero-copy account\n#[zero_copy]\npub struct Event {\n pub from: Pubkey,\n pub data: u64,\n}\n\n// For RPC/instruction parameters\n#[derive(AnchorSerialize, AnchorDeserialize)]\npub struct EventParams {\n pub from: Pubkey,\n pub data: u64,\n}\n\nimpl From<EventParams> for Event {\n fn from(params: EventParams) -> Self {\n Event {\n from: params.from,\n data: params.data,\n }\n }\n}\nCommon Pitfalls\nForgetting the Account Discriminator\nAlways add 8 bytes for the account discriminator when calculating space:\n// Wrong - missing discriminator\nspace = std::mem::size_of::<Data>()\n\n// Correct - includes discriminator\nspace = 8 + std::mem::size_of::<Data>()\nUsing Dynamic Types\nZero-copy requires all fields to be Copy types:\n#[account(zero_copy)]\npub struct InvalidData {\n pub items: Vec<u64>, // Vec is not Copy\n pub name: String, // String is not Copy\n}\n\n#[account(zero_copy)]\npub struct ValidData {\n pub items: [u64; 100], // Fixed-size array\n pub name: [u8; 32], // Fixed-size bytes\n}\nUsing load_init vs load_mut\nUse load_init() for first-time initialization (sets discriminator):\n// First initialization\npub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_init()?;\n account.data = [1; 10232];\n Ok(())\n}\n\n// Subsequent updates\npub fn update(ctx: Context<Update>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_mut()?;\n account.data = [2; 10232];\n Ok(())\n}\nNot Validating Array Indices\nAlways validate array indices to prevent panics:\npub fn update_item(\n ctx: Context<Update>,\n index: u32,\n value: u64\n) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_mut()?;\n\n require!(\n (index as usize) < account.items.len(),\n ErrorCode::IndexOutOfBounds\n );\n\n account.items[index as usize] = value;\n Ok(())\n}\nReal-World Use Cases\nEvent Queue Pattern\nStore large sequences of events efficiently:\n#[account(zero_copy)]\npub struct EventQueue {\n pub head: u64,\n pub count: u64,\n pub events: [Event; 10000],\n}\n\n#[zero_copy]\npub struct Event {\n pub timestamp: i64,\n pub user: Pubkey,\n pub event_type: u8,\n pub data: [u8; 32],\n}\nUsed by: Trading protocols, audit logs, messaging systems\nOrder Book Pattern\nEfficient storage for trading pairs:\n#[account(zero_copy)]\npub struct OrderBook {\n pub market: Pubkey,\n pub bid_count: u32,\n pub ask_count: u32,\n pub bids: [Order; 1000],\n pub asks: [Order; 1000],\n}\n\n#[zero_copy]\npub struct Order {\n pub trader: Pubkey,\n pub price: u64,\n pub size: u64,\n pub timestamp: i64,\n}\nUsed by: DEXs (Serum, Mango), NFT marketplaces\nExamples\nThe examples below demonstrate two approaches for initializing zero-copy\naccounts in Anchor:\n\nUsing the init constraint to initialize the account in a single instruction\nUsing the zero constraint to initialize an account with data greater than\n10240 bytes\n\nZero Copy\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"8B7XpDXjPWodpDUWDSzv4q9k73jB5WdNQXZxNBj1hqw1\");\n\n#[program]\npub mod zero_copy {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_init()?;\n account.data = [1; 10232];\n Ok(())\n }\n\n pub fn update(ctx: Context<Update>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_mut()?;\n account.data = [2; 10232];\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(\n init,\n // 10240 bytes is max space to allocate with init constraint\n space = 8 + 10232,\n payer = payer,\n )]\n pub data_account: AccountLoader<'info, Data>,\n #[account(mut)]\n pub payer: Signer<'info>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct Update<'info> {\n #[account(mut)]\n pub data_account: AccountLoader<'info, Data>,\n}\n\n#[account(zero_copy)]\npub struct Data {\n // 10240 bytes - 8 bytes account discriminator\n pub data: [u8; 10232],\n}\nInitialize Large Account\nWhen initializing an account that requires more than 10,240 bytes of space, you\nmust split the initialization into two steps:\n\nCreate the account in a separate instruction invoking the System Program\nInitialize the account data in your program instruction\n\nNote that the maximum Solana account size is 10MB (10_485_760 bytes), 8 bytes\nare reserved for the account discriminator.\nlib.rsuse anchor_lang::prelude::*;\n\ndeclare_id!(\"CZgWhy3FYPFgKE5v9atSGaiQzbSB7cM38ofwX1XxeCFH\");\n\n#[program]\npub mod zero_copy_two {\n use super::*;\n pub fn initialize(ctx: Context<Initialize>) -> Result<()> {\n let account = &mut ctx.accounts.data_account.load_init()?;\n account.data = [1; 10_485_752];\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(zero)]\n pub data_account: AccountLoader<'info, Data>,\n}\n\n#[account(zero_copy)]\npub struct Data {\n // 10240 bytes - 8 bytes account discriminator\n pub data: [u8; 10_485_752],\n}PreviousEmit EventsNextFootgunsOn this pageOverviewWhy Use Zero-Copy?Performance ComparisonWhen to Use Zero-CopyUsageDefine a Zero Copy AccountUse AccountLoader for Zero Copy AccountsCommon PatternsNested Zero-Copy TypesAccessor Methods for Byte ArraysZero-Copy with PDAsSeparate Types for RPC ParametersCommon PitfallsForgetting the Account DiscriminatorUsing Dynamic TypesUsing load_init vs load_mutNot Validating Array IndicesReal-World Use CasesEvent Queue PatternOrder Book PatternExamplesZero CopyInitialize Large AccountEdit on GitHub","tokens":3020,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257938749,"hash":"37bf2fcd760b14fb542e1a6e30411aa3caee0aee"}
{"url":"https://ethresear.ch/u/conalloreilly","domain":"ethresear.ch","title":"Summary - conalloreilly - Ethereum Research","text":"Skip to profile content\n\n conalloreilly\n\n Conall O'Reilly\n\n conalloreilly.eth.limo\n\n Protocol researcher with interests in cryptography, zkEVMs, and sharding.\nI program in Python, C#, C/C++, HTML/CSS, JavaScript, and Solidity.\nI’ve also done application development; my dual BTC/ETH wallet Cobra and the image authentication platform Prometheus are the best in examples of what I’ve built.\nSome of my other interests include economics and game-theory.\nMy Ethereum-based website can tell you more if you’re interested!\n\n website:\n\n https://conalloreilly.eth.limo\n\n github:\n\n https://github.com/XRS-001\n\n Joined\n\n Apr 20\n\n Last Post\n\n Jul 31\n\n Seen\n\n 4 days\n\n Views737\n Trust Levelmember\n\n Stats\n\n 118\n\n days visited\n\n 6h\n\n read time\n\n 27m\n\n recent read time\n\n 103\n\n topics viewed\n\n 407\n\n posts read\n\n 3\n\n given\n\n 10\n\n received\n\n 5\n\n topics created\n\n 6\n\n posts created\n\n Top Replies\n\n Jun 2\n ·\n  2\n\n Building index-tracking assets on top of options instead of debt\n\n Jun 2\n ·\n  1\n\n Building index-tracking assets on top of options instead of debt\n\n Apr 24\n ·\n  1\n\n Two paradoxes that prevent current cryptocurrencies from functioning as daily money\n\n Jul 31\n\n Recursive-STARK-based bandwidth-efficient mempool\n\n Jun 2\n\n Building index-tracking assets on top of options instead of debt\n\n May 17\n\n Closing the Last UX Gap in Crypto: Privacy-Preserving Payments to Email, Phone, and Social Handles, Rather Than a Wallet Address\n\n More Replies\n\n Top Topics\n\n Apr 26\n ·\n  4\n\n Modular and Composable Stablecoins as Homogeneous Monetary Goods\n\n Jun 26\n ·\n  1\n\n Ethereum’s Fourth Protocol Layer: Memory\n\n May 12\n ·\n  1\n\n Why Homogenizing the Execution of the World-Computer Beats Scaling Through Fragmentation\n\n Jul 6\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n Apr 24\n\n Delegated Execution Sharding (DES): A hyper-parallelized zkEVM for theoretically optimal execution-layer scalability\n\n Top Links\n\n blog.ethereum.org/2025/07/31/lean-ethereum\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n leanroadmap.org\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n vitalik.eth.limo/general/2017/12/31/sharding_faq.html\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n eips.ethereum.org/EIPS/eip-1559\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n eips.ethereum.org/EIPS/eip-7736\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n Most Replied To\n\n norswap\n\n 2\n\n Most Liked By\n\n jakestated_1\n\n JC\n\n 2\n\n lsankar4033\n\n 2\n\n orishim\n\n Orishim\n\n 1\n\n WGlynn\n\n william Glynn\n\n 1\n\n nicobernad\n\n Nico-pat\n\n 1\n\n Josh222\n\n Josh\n\n 1\n\n Most Liked\n\n system\n\n system\n\n 1\n\n vbuterin\n\n Vbuterin\n\n 1\n\n 71104\n\n Alberto\n\n 1\n\n Top Categories\n\n Topics\n Replies\n\n Economics\n\n 1\n\n 4\n\n Sharding\n\n 3\n\n –\n\n Networking\n\n –\n\n 1\n\n Architecture\n\n 1\n\n –\n\n Applications\n\n –\n\n 1\n\n Top Badges\n\n Member\n\n Granted invitations, group messaging, more likes\n\n Licensed\n\n Completed our advanced user tutorial\n\n New User of the Month\n\n Outstanding contributions in their first month\n\n First Onebox\n\n Posted a link that was oneboxed\n\n Autobiographer\n\n Filled out profile information\n\n First Link\n\n Added a link to another topic\n\n More Badges\n\n Powered by Discourse","tokens":963,"squid":"ink-research","role":"Deep Scholar","at":1791257942491,"hash":"fa15d0bedd4d8c5146f9f57e3042e39a91dd20a2"}
{"url":"https://docs.pyth.network/price-feeds/core/derive-cross-rate","domain":"docs.pyth.network","title":"Derive Cross Rate | Pyth Developer Hub","text":"Pyth CoreDerive Cross RateLearn how to derive synthetic cross rates using Pyth price feedsThis guide shows how to combine two price feeds to derive a cross rate. These are also known as \"synthetic\" price feeds.\nCross rates or Synthetic Price feeds are useful for trading pairs that are not directly supported by Pyth.\nFor example, if you want to trade the price of ETH/EUR, which is not directly supported by Pyth, you can combine the price of ETH/USD and EUR/USD to derive the price of ETH/EUR.\nETH/EUR=ETH/USD÷EUR/USD\\large{\\text{ETH/EUR} = \\text{ETH/USD} \\div \\text{EUR/USD}}\n\nDerive a cross rateThe Pyth Solidity SDK provides deriveCrossRate function to combine two price feeds.\nThis method is available in Pyth solidity SDK.This method takes the following parameters:\nprice1: The first price feed value, representing a / b (e.g., ETH/USD). Must be a signed integer (int64).\nexpo1: The exponent for price1, indicating the number of decimal places.\nprice2: The second price feed value, representing c / b (e.g., EUR/USD).\nexpo2: The exponent for price2.\ntargetExponent: The desired exponent for the output cross rate (a / c). The result will be scaled to this exponent.\nReturns:\ncrossRate: The computed cross rate (a / c), scaled to targetExponent.\nExamplepragma solidity ^0.8.0;\n\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythUtils.sol\";\n\ncontract ExampleCrossRate {\n IPyth public pyth;\n\n constructor(address _pythContract) {\n pyth = IPyth(_pythContract);\n }\n\n // priceUpdate should include both price feeds\n function getEthPerEur(\n bytes32 ethUsdId,\n bytes32 eurUsdId,\n bytes[] calldata priceUpdate\n ) external payable returns (int64 price, int32 expo) {\n // Update both feeds\n uint fee = pyth.getUpdateFee(priceUpdate);\n pyth.updatePriceFeeds{ value: fee }(priceUpdate);\n\n // Fetch prices\n PythStructs.Price memory ethUsd = pyth.getPriceNoOlderThan(ethUsdId, 60);\n PythStructs.Price memory eurUsd = pyth.getPriceNoOlderThan(eurUsdId, 60);\n\n // Derive ETH/EUR = ETH/USD / EUR/USD\n int32 targetExpo = -8;\n int64 ethPerEur = PythUtils.deriveCrossRate(\n ethUsd.price,\n ethUsd.expo,\n eurUsd.price,\n eurUsd.expo,\n targetExpo\n );\n\n return (ethPerEur, targetExpo);\n }\n}\n⚠️ Things to Keep in Mind\nThe function reverts if either price is negative, or if any exponent is less than -255.\nThe result is rounded down. If the result is smaller than 1 in the given targetExponent, it will return 0.\nConfidence intervals are not derived in this function. If needed, you have to derive them manually.\nReverts with PythErrors.ExponentOverflow if targetExponent + expo1 - expo2 is outside the range [-58, 58].\nAdditional ResourcesYou may find these additional resources helpful.How to use real-time data in EVM contractsThe How to use real-time data in EVM contracts guide provides a step-by-step guide on how to use real-time data in EVM contracts.Price Feed IDsThe Price Feed IDs page lists the price feed IDs for each asset supported by Pyth.Create TradingView ChartsLearn how to build TradingView charts powered by Pyth price feedsUse Pyth for Morpho MarketsLearn how to use Pyth for Morpho Markets","tokens":798,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257952099,"hash":"425f58b9240ecb8cf6164da6dfeedeb20ff0fa0f"}
{"url":"https://ethresear.ch/t/closing-the-last-ux-gap-in-crypto-privacy-preserving-payments-to-email-phone-and-social-handles-rather-than-a-wallet-address/24874/2","domain":"ethresear.ch","title":"Closing the Last UX Gap in Crypto: Privacy-Preserving Payments to Email, Phone, and Social Handles, Rather Than a Wallet Address - Applications - Ethereum Research","text":"Applications\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 13\n\n 2 / 3\n\n May 17\n\n May 18\n\n post by 0xjasonw on May 13\n\n 0xjasonw\n\n 17 years after Bitcoin’s genesis block, sending cryptocurrency still feels like a developer task. You need to ask the recipient for a wallet address, copy a 42-character hex string, make sure you’re on the right network, and acquire a gas token just to pay the fee. Miss any step, and funds are lost forever. Meanwhile, sending a message to someone takes three seconds — you just type their email or phone number.\nThis UX gap is not a minor inconvenience — it is the single biggest barrier to crypto mass adoption. The obvious fix is to map those identifiers directly to blockchain addresses. But every naive attempt to do so trades away the one thing users increasingly care about: privacy. Anyone who knows your email can derive your address, and from there reconstruct your entire financial history on-chain.\nThis post discusses HFIPay — a protocol that closes this gap without the privacy tradeoff.\nThe Problem\nSending cryptocurrency still requires the sender to know a wallet address. Even with UX improvements, the flow is: ask for address → copy hex string → select correct network → acquire gas token → send.\nHuman-friendly identifiers — email addresses, phone numbers, social handles — are already how people identify each other online. The natural goal is:\nsend crypto to alice@example.com the same way you’d send a message.\nThe naïve approach maps the identifier to an address deterministically, e.g. keccak256(identifier) → address. This is simple but introduces a critical privacy flaw: anyone who knows Alice’s email can derive her on-chain address and inspect her full transaction history, token balances, and counterparty relationships — on every supported chain.\nSolution: HFIPay and What It Does\nHFIPay is a protocol — not an application — that any wallet or payment app can integrate. It enables the following properties at the protocol level:\n\nNo wallet setup required for the recipient — funds can be sent before\nthe recipient has ever opened a crypto app\nEnumeration resistance — on-chain data reveals nothing about which\nintents belong to a known email, phone, or social handle\nPre-claim unlinkability — multiple payments to the same identifier\nleave no reusable on-chain recipient tag\nNon-custodial claim — the relay routes but cannot redirect funds;\nonly the recipient can authorize release via a ZK proof\nIdentifier-agnostic — works with any verifiable identifier: email,\nphone, X handle, or others\n\nith the HFIPay protocol, anyone can:\n\nSend crypto to anyone — no need to know the recipient’s wallet address,\nor even whether they have one.\nRecipient claims funds upon notification — if they don’t have a wallet\nyet, one can be created on the fly at claim time.\nAuto-claim after first use — once a recipient has claimed once, future\npayments can be claimed automatically without manual action.\nSender can cancel within a time window — if the recipient never claims,\nthe sender can retrieve the funds before the timeout.\nUnclaimed transfers are refunded automatically — after the expiry\nwindow, funds are returned to the sender without any manual intervention.\n\nHow Does This Compare to ENS?\nENS is the most mature naming system in the Ethereum ecosystem and solves a real problem: replacing opaque hex addresses with human-readable names. HFIPay is solving a different problem. Here is a neutral feature comparison:\n\nENS\nHFIPay\n\nIdentifier type\n.eth name (must register)\nEmail / phone (already exists, no setup)\n\nOn-chain mapping\nPublic, enumerable\nNot stored on-chain\n\nPrivacy model\nAddress is public by design\nChain sees only a per-intent blinded value\n\nRecipient setup\nRequired before receiving\nOptional (lazy onboarding possible)\n\nIdentifier enumeration\nAnyone can query any name\nChain state reveals no identifier\n\nTrust assumption\nENS contract (decentralized)\nRelay (see trust modes below)\n\nENS and HFIPay are not in competition. A HFIPay relay could internally resolve .eth names as one identifier type among others. The difference is in what information is committed on-chain and what privacy guarantees follow.\n\nHow Does This Compare to ERC-5564 (Stealth Addresses)?\nERC-5564 hides where funds land on-chain: the recipient’s address is ephemeral and unlinkable to their public key. HFIPay hides an earlier step:\nhow a human-friendly identifier maps to any on-chain destination at all.\nSender knows: alice@example.com\n ↓\n [Relay: private resolution] ← HFIPay's scope\n ↓\n On-chain: blinded intent\n ↓\n [ZK claim by recipient]\n ↓\n Destination address (could be a stealth address) ← ERC-5564's scope\n\nThe two mechanisms are complementary. HFIPay can route funds to a fresh stealth address on each payment, combining identifier-level and address-level privacy.\n\nThe HFIPay Mechanism (Informal)\nThe protocol separates three concerns:\n1. Private routing (off-chain)\nThe sender specifies alice@example.com. A relay privately resolves this to a registered recipient record and samples a fresh intentId. It derives a one-time deposit address and commits only an intent-specific blinded binding ρᵢ together with the quoted asset and amount. The chain sees neither the identifier nor a reusable recipient tag.\n2. Sender-side quote verification (optional)\nIn the verified-quote deployment, the relay returns an off-chain attestation linking ρᵢ to the intended recipient’s hidden binding-key commitment. The sender can verify this before funding — the relay cannot silently redirect funds to a different recipient.\n3. On-chain claim authorization\nTo claim funds, the recipient proves in zero knowledge (via ZK-ACE) that the funded intent’s blinded binding matches a handle derived from their deterministic identity, authorizing release to a destination of their choice. The relay is involved in routing and availability — it cannot redirect funds after the intent is funded.\nSender Relay Chain\n | | |\n |-- pay alice@email --> | |\n | | (private lookup) |\n |<-- quote (ρᵢ, τᵢ) --- | |\n | | |\n |-- fund intent --------|---------------------> |\n | | |\n Recipient\n |\n |-- ZK claim proof ---> |\n |<-- funds released --- |\n\nPrivacy Properties\nThe paper formalizes two properties:\nEnumeration resistance: No on-chain data allows an observer to determine which funded intents belong to a known email address, phone number, or social handle — even if the observer knows the identifier and can read all chain state.\nPre-claim unlinkability: Multiple payments to the same identifier before any claim do not expose a reusable public recipient tag. Each intent uses an independent blinded binding. After a successful claim, the destination address and asset amount become visible on-chain (as with any transaction). The paper explicitly characterizes what becomes linkable post-claim.\n\nTrust Modes\nThe protocol defines two deployment modes, distinguishing what trust is placed in the relay:\nBaseline deployment: The relay is trusted to bind the correct recipient to each intent. Suitable for integrated wallets where the relay and the application share a trust boundary.\nVerified-quote deployment: The relay issues a sender-verifiable attestation before funding. A separate binding layer independently verifies identifier ownership (e.g., via email OTP or OIDC), so the relay cannot substitute a different recipient without the sender detecting it. The binding is sender-verifiable without a public identifier registry. Full formal treatment is in Sections 2–6 of the paper.\n\nImplementation\nWe are building an open implementation at hfi.network, including relay infrastructure and ZK claim circuits. Early exploration of relay decentralization is underway. Feedback on the protocol design and trust model is very welcome.\nFull paper: arXiv:2603.26970\n\nHappy to discuss the formal security definitions, the binding epoch rotation scheme, or the relationship to other identifier-based payment proposals.\n\n post by conalloreilly on May 17\n\n conalloreilly\n\n Apologies if I misunderstood, but I’m not sure how you can have both the property that “funds can be sent before the recipient has ever opened a crypto app” while having the obvious security requirement that only the “owner” (this isn’t even a cryptographically defined thing) of a handle/email can claim the funds.\nThere isn’t any meaningful cryptographic information that the owner of an email has that they can zk-prove to claim funds, and if there was, you’d have the same effect as using ENS + a stealth wallet anyway.\nInteresting concept nonetheless, but I do think it’s worth considering whether it’s worth creating a protocol that relies on traditional infrastructure instead of building from the ground up with things like ENS.\n\n post by 71104 on May 18\n\n 71104\n\n I agree with @conalloreilly. It looks to me like you’re basically treating the email address or phone number or whatever as the password to withdraw the funds, pretty much like TornadoCash’s secret note. But that’s unsafe because details like the email address and social handles of a person are publicly known, unlike TC’s secret note which is secret.\nPersonally I don’t see any sound way to send funds to someone “before that person has ever opened a crypto app”. Some sort of secret identifier has to be created.\n\n Powered by Discourse","tokens":2336,"squid":"ink-research","role":"Deep Scholar","at":1791257955527,"hash":"c5b48a965ad32ebbe16c2b9ab1531b4339fc10b1"}
{"url":"https://www.anchor-lang.com/docs/tokens","domain":"anchor-lang.com","title":"Token Integration with Anchor","text":"Token Integration with AnchorLearn how to interact with Solana's Token Programs from an Anchor Program.What are Token Programs?\nOn Solana, there are two main token programs (developed by\nAnza, previously Solana Labs):\n\nToken Program (Original)\n\nBasic token functionality (mint, transfer, etc.)\nImmutable and widely used\n\nToken Extension Program (Token 2022)\n\nIncludes all original Token Program features\nAdds additional functionality through \"extensions\"\nRecommended for new tokens\n\nInvoking Token Programs in an Anchor Program\nThe anchor-spl crate\nsimplifies the process of interacting with Solana's Token Programs in an Anchor\nprogram. This crate includes instructions and account types for both the\noriginal Token Program and the newer Token Extension Program (Token 2022).\nSimply add the anchor-spl crate as a dependency to your program and add \"anchor-spl/idl-build\" to idl-build feature list in Cargo.toml. For a\nwalkthrough of how to create an Anchor program locally, see the\nquickstart page.\nTerminalcargo add anchor-spl\nCargo.toml[features]\nidl-build = [\n \"anchor-lang/idl-build\",\n \"anchor-spl/idl-build\",\n]\n\n[dependencies]\nanchor-lang = \"1.2.0\"\nanchor-spl = \"1.2.0\"\nCore Modules\nThe most commonly used modules provided by the anchor-spl crate include:\nModuleDescriptiontokenToken Program (legacy) instructions and account typestoken_2022Token 2022 base instructions (instructions matching the Token Program functionality)token_2022_extensionsToken 2022 extensions instructionstoken_interfaceImplementation of account types that work with both Token Program and Token 2022 Programassociated_tokenAssociated token account instruction\nThe following pages provide examples of how to use the anchor-spl crate in an\nAnchor program.PreviousFootgunsNextSPL Token BasicsOn this pageWhat are Token Programs?Invoking Token Programs in an Anchor ProgramCore ModulesEdit on GitHub","tokens":469,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791257961961,"hash":"bd7882b7ce12c4e92f25b0fe435043953357639b"}
{"url":"https://docs.pyth.network/price-feeds/core/use-historical-price-data","domain":"docs.pyth.network","title":"Use Historical Price Data (Benchmarks) | Pyth Developer Hub","text":"Pyth CoreUse Historical Price Data (Benchmarks)Learn how to query and verify historical Pyth price feedsThis guide explains how to integrate Pyth Benchmarks to access historical price data across applications. The Benchmarks API is available on all Pythnet chains.\nPyth Core was upgraded on August 26, 2026We recommend new integrations use the upgraded contract addresses.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nThe Benchmarks endpoints stayed at the same URLs through the upgrade, but since August 26, 2026 at 16:00 UTC every request must include an Authorization: Bearer $PYTH_API_KEY header. Get a Pyth API Key on the billing page.\nBenchmarks TerminologyThroughout this guide, Benchmarks refers to Pyth’s historical price data\nservice.\nOverview\nPyth Benchmarks lets you query historical prices at specific timestamps. Typical use cases include:\n\nContract settlement for derivatives such as options or futures\nBacktesting trading strategies with historical data\nAudit and compliance workflows that require price verification\nAnalytics to analyze market behavior over time\n\nBenchmarks supports two complementary flows:\nRetrieve data from the Benchmarks API or through the\nHermes timestamp API.\nTwo REST endpoints are available:\n/v1/updates/price/{timestamp}: returns prices for the requested feeds at a given timestamp.\n/v1/updates/price/{timestamp}/{interval}: returns prices for a feed at the given timestamp and interval.\nInterval WindowThe interval parameter represents the number of seconds added to the provided timestamp.\nFor example, with timestamp 1716400000 and interval 60, the API returns price updates\nfrom 1716400000 through 1716400060 (inclusive). The interval must not exceed 60\nseconds.After fetching price updates, pass the result to parsePriceFeedUpdates instead of updatePriceFeeds when interacting with the Pyth contract.// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\ncontract HistoricalPriceConsumer {\n IPyth public pyth;\n\n constructor(address _pyth) {\n pyth = IPyth(_pyth);\n }\n\n function settleWithHistoricalPrice(\n bytes[] calldata priceUpdate,\n uint256 priceId,\n uint256 minPublishTime,\n uint256 maxPublishTime,\n ) external {\n // The parsePriceFeedUpdates function requires a fee to be paid.\n // The fee is the same as the fee for the updatePriceFeeds function.\n uint fee = pyth.getUpdateFee(priceUpdate);\n PythStructs.Price memory price = pyth.parsePriceFeedUpdates{value: fee}(\n priceUpdate,\n priceId,\n minPublishTime,\n maxPublishTime,\n );\n\n // Use the historical price for settlement\n uint256 settlementPrice = uint256(price.price);\n // ... settlement logic\n }\n}The verification flow differs from real-time price updates in that it:\nCalls parsePriceFeedUpdates instead of updatePriceFeeds\nProvides the price feed ID to ensure the update matches the feed\nSupplies minPublishTime and maxPublishTime to enforce the allowable timestamp window, reverting with PriceFeedNotFoundWithinRange when updates fall outside the range\nConsult the API reference for additional implementation details.\nAdditional Resources\nAPI Reference\n\nBenchmarks API documentation\nPyth on-chain API reference\n\nTradingView Integration\n\nTradingView integration for visualization\n\nRate Limits\n\nBenchmarks API inherits the same limits as the Hermes API: 10 requests every 10 seconds per IP address.\nPush IntegrationHow to use Pyth push feeds across supported ecosystemsFetch Price UpdatesLearn how to retrieve Pyth price updates via REST, streaming, and SDK","tokens":919,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791257962104,"hash":"dab71b6e8f6870de2c70fe08aa852b29f0039873"}
{"url":"https://ethresear.ch/t/closing-the-last-ux-gap-in-crypto-privacy-preserving-payments-to-email-phone-and-social-handles-rather-than-a-wallet-address/24874/1","domain":"ethresear.ch","title":"Closing the Last UX Gap in Crypto: Privacy-Preserving Payments to Email, Phone, and Social Handles, Rather Than a Wallet Address - Applications - Ethereum Research","text":"Closing the Last UX Gap in Crypto: Privacy-Preserving Payments to Email, Phone, and Social Handles, Rather Than a Wallet Address \n\n Applications\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 13\n\n 1 / 3\n\n May 13\n\n May 18\n\n post by 0xjasonw on May 13\n\n 0xjasonw\n\n 17 years after Bitcoin’s genesis block, sending cryptocurrency still feels like a developer task. You need to ask the recipient for a wallet address, copy a 42-character hex string, make sure you’re on the right network, and acquire a gas token just to pay the fee. Miss any step, and funds are lost forever. Meanwhile, sending a message to someone takes three seconds — you just type their email or phone number.\nThis UX gap is not a minor inconvenience — it is the single biggest barrier to crypto mass adoption. The obvious fix is to map those identifiers directly to blockchain addresses. But every naive attempt to do so trades away the one thing users increasingly care about: privacy. Anyone who knows your email can derive your address, and from there reconstruct your entire financial history on-chain.\nThis post discusses HFIPay — a protocol that closes this gap without the privacy tradeoff.\nThe Problem\nSending cryptocurrency still requires the sender to know a wallet address. Even with UX improvements, the flow is: ask for address → copy hex string → select correct network → acquire gas token → send.\nHuman-friendly identifiers — email addresses, phone numbers, social handles — are already how people identify each other online. The natural goal is:\nsend crypto to alice@example.com the same way you’d send a message.\nThe naïve approach maps the identifier to an address deterministically, e.g. keccak256(identifier) → address. This is simple but introduces a critical privacy flaw: anyone who knows Alice’s email can derive her on-chain address and inspect her full transaction history, token balances, and counterparty relationships — on every supported chain.\nSolution: HFIPay and What It Does\nHFIPay is a protocol — not an application — that any wallet or payment app can integrate. It enables the following properties at the protocol level:\n\nNo wallet setup required for the recipient — funds can be sent before\nthe recipient has ever opened a crypto app\nEnumeration resistance — on-chain data reveals nothing about which\nintents belong to a known email, phone, or social handle\nPre-claim unlinkability — multiple payments to the same identifier\nleave no reusable on-chain recipient tag\nNon-custodial claim — the relay routes but cannot redirect funds;\nonly the recipient can authorize release via a ZK proof\nIdentifier-agnostic — works with any verifiable identifier: email,\nphone, X handle, or others\n\nith the HFIPay protocol, anyone can:\n\nSend crypto to anyone — no need to know the recipient’s wallet address,\nor even whether they have one.\nRecipient claims funds upon notification — if they don’t have a wallet\nyet, one can be created on the fly at claim time.\nAuto-claim after first use — once a recipient has claimed once, future\npayments can be claimed automatically without manual action.\nSender can cancel within a time window — if the recipient never claims,\nthe sender can retrieve the funds before the timeout.\nUnclaimed transfers are refunded automatically — after the expiry\nwindow, funds are returned to the sender without any manual intervention.\n\nHow Does This Compare to ENS?\nENS is the most mature naming system in the Ethereum ecosystem and solves a real problem: replacing opaque hex addresses with human-readable names. HFIPay is solving a different problem. Here is a neutral feature comparison:\n\nENS\nHFIPay\n\nIdentifier type\n.eth name (must register)\nEmail / phone (already exists, no setup)\n\nOn-chain mapping\nPublic, enumerable\nNot stored on-chain\n\nPrivacy model\nAddress is public by design\nChain sees only a per-intent blinded value\n\nRecipient setup\nRequired before receiving\nOptional (lazy onboarding possible)\n\nIdentifier enumeration\nAnyone can query any name\nChain state reveals no identifier\n\nTrust assumption\nENS contract (decentralized)\nRelay (see trust modes below)\n\nENS and HFIPay are not in competition. A HFIPay relay could internally resolve .eth names as one identifier type among others. The difference is in what information is committed on-chain and what privacy guarantees follow.\n\nHow Does This Compare to ERC-5564 (Stealth Addresses)?\nERC-5564 hides where funds land on-chain: the recipient’s address is ephemeral and unlinkable to their public key. HFIPay hides an earlier step:\nhow a human-friendly identifier maps to any on-chain destination at all.\nSender knows: alice@example.com\n ↓\n [Relay: private resolution] ← HFIPay's scope\n ↓\n On-chain: blinded intent\n ↓\n [ZK claim by recipient]\n ↓\n Destination address (could be a stealth address) ← ERC-5564's scope\n\nThe two mechanisms are complementary. HFIPay can route funds to a fresh stealth address on each payment, combining identifier-level and address-level privacy.\n\nThe HFIPay Mechanism (Informal)\nThe protocol separates three concerns:\n1. Private routing (off-chain)\nThe sender specifies alice@example.com. A relay privately resolves this to a registered recipient record and samples a fresh intentId. It derives a one-time deposit address and commits only an intent-specific blinded binding ρᵢ together with the quoted asset and amount. The chain sees neither the identifier nor a reusable recipient tag.\n2. Sender-side quote verification (optional)\nIn the verified-quote deployment, the relay returns an off-chain attestation linking ρᵢ to the intended recipient’s hidden binding-key commitment. The sender can verify this before funding — the relay cannot silently redirect funds to a different recipient.\n3. On-chain claim authorization\nTo claim funds, the recipient proves in zero knowledge (via ZK-ACE) that the funded intent’s blinded binding matches a handle derived from their deterministic identity, authorizing release to a destination of their choice. The relay is involved in routing and availability — it cannot redirect funds after the intent is funded.\nSender Relay Chain\n | | |\n |-- pay alice@email --> | |\n | | (private lookup) |\n |<-- quote (ρᵢ, τᵢ) --- | |\n | | |\n |-- fund intent --------|---------------------> |\n | | |\n Recipient\n |\n |-- ZK claim proof ---> |\n |<-- funds released --- |\n\nPrivacy Properties\nThe paper formalizes two properties:\nEnumeration resistance: No on-chain data allows an observer to determine which funded intents belong to a known email address, phone number, or social handle — even if the observer knows the identifier and can read all chain state.\nPre-claim unlinkability: Multiple payments to the same identifier before any claim do not expose a reusable public recipient tag. Each intent uses an independent blinded binding. After a successful claim, the destination address and asset amount become visible on-chain (as with any transaction). The paper explicitly characterizes what becomes linkable post-claim.\n\nTrust Modes\nThe protocol defines two deployment modes, distinguishing what trust is placed in the relay:\nBaseline deployment: The relay is trusted to bind the correct recipient to each intent. Suitable for integrated wallets where the relay and the application share a trust boundary.\nVerified-quote deployment: The relay issues a sender-verifiable attestation before funding. A separate binding layer independently verifies identifier ownership (e.g., via email OTP or OIDC), so the relay cannot substitute a different recipient without the sender detecting it. The binding is sender-verifiable without a public identifier registry. Full formal treatment is in Sections 2–6 of the paper.\n\nImplementation\nWe are building an open implementation at hfi.network, including relay infrastructure and ZK claim circuits. Early exploration of relay decentralization is underway. Feedback on the protocol design and trust model is very welcome.\nFull paper: arXiv:2603.26970\n\nHappy to discuss the formal security definitions, the binding epoch rotation scheme, or the relationship to other identifier-based payment proposals.\n\n post by conalloreilly on May 17\n\n conalloreilly\n\n Apologies if I misunderstood, but I’m not sure how you can have both the property that “funds can be sent before the recipient has ever opened a crypto app” while having the obvious security requirement that only the “owner” (this isn’t even a cryptographically defined thing) of a handle/email can claim the funds.\nThere isn’t any meaningful cryptographic information that the owner of an email has that they can zk-prove to claim funds, and if there was, you’d have the same effect as using ENS + a stealth wallet anyway.\nInteresting concept nonetheless, but I do think it’s worth considering whether it’s worth creating a protocol that relies on traditional infrastructure instead of building from the ground up with things like ENS.\n\n post by 71104 on May 18\n\n 71104\n\n I agree with @conalloreilly. It looks to me like you’re basically treating the email address or phone number or whatever as the password to withdraw the funds, pretty much like TornadoCash’s secret note. But that’s unsafe because details like the email address and social handles of a person are publicly known, unlike TC’s secret note which is secret.\nPersonally I don’t see any sound way to send funds to someone “before that person has ever opened a crypto app”. Some sort of secret identifier has to be created.\n\n Powered by Discourse","tokens":2369,"squid":"ink-research","role":"Deep Scholar","at":1791257978494,"hash":"7513159ecd4788c7f453c34fb13b7f5868233c4e"}
{"url":"https://gov.optimism.io/t/guide-to-season-3-course-correcting/3942/1","domain":"gov.optimism.io","title":"Guide to Season 3: Course Correcting - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Guide to Season 3: Course Correcting \n\n Communications 📣Delegates 🏛\n\n season-3\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 27\n\n Nov 2022\n\n Jan 2023\n\n post by system on Nov 8, 2022\n\n system\n\n There will be a session to discuss any and all of the below with the Foundation from 9:00 - 9:30am PST / 5:00 - 5:30pm GMT on Wednesday, November 9th. Recording from this session can be found here.\n\nWe’d like to start with a huge thank you to our tireless delegates. We appreciate all of your hard work and for being a part of our iterative governance experiments to date. We know it’s not easy to be the first to try something.\nEach Season is an experiment as the Collective iterates toward its final governance design. Community feedback has surfaced many learnings during Season 2, and Season 3 is an opportunity to course correct in the face of some hard truths:\n\nDelegate Overload: Delegates are overloaded with proposals to vote on, which is leading to lower participation among some top delegates. Placing this level of demand on delegates does not position Token House governance to effectively scale. Ideally, the Token House would infrequently approve high importance decisions and serve as a check on the Citizens’ House. The Token House would not be voting frequently on granular decisions such as individual grant approvals.\n\nProposer Frustration: Proposers find the current grant process hard to navigate and are frustrated with conflicting feedback from delegates. Several protocols have gotten so frustrated that they’ve considered leaving the Optimism ecosystem to work with competitors.\n\nProtocol Participation: Protocols are frustrated by debates concerning self-delegation. Protocols are important stakeholders and should have a voice in governance, but delegates are understandably uncomfortable with protocols self-delegating grants to increase voting power.\n\nCommittee Conflict: Committees helped reduce non-committee member workload, but added complexity to the process and introduced additional confusion for proposers. Conflicts between committees contributed to a dramatic degradation in governance culture.\n\nCulture Concerns: Governance culture is not currently reflective of the Collective’s values. Governance conversations have been lacking in civility, respect, and positivity. There hasn’t been an enforceable code of conduct to address inappropriate delegate behavior, which has occurred frequently.\n\nLimited Accountability: The impact of Governance Fund grants has been disappointing so far. The pace of grant distribution has been aggressive and there is almost no accountability for grant recipients. There have been multiple examples of grant-related transactions well outside the scope of what was outlined in proposals.\n\nUndefined Scope: There has been limited guidance on the types of initiatives grants should support. This has led to the over-funding of less effective initiatives (like retroactive airdrops) and the under-funding of strategically important initiatives (like builder grants.)\n\nWhile we have challenges to overcome, delegates have also shown a remarkable dedication to Optimism and an impressive willingness to experiment. We’re extremely grateful to delegates (and their delegators!) for their dedication during the earliest stages of the Collective. It makes us incredibly optimistic about the future of Token House governance. Experimentation and iteration have been core to the vision for Optimism governance from the start. We didn’t expect to get things right on the first try, and it’s clear we’re ready for some big changes. The below docs outline several initiatives aimed at addressing the above challenges for Season 3.\n\nWe would appreciate community feedback on the following posts:\n\nDelegate Code of Conduct: An enforceable delegate code of conduct to restore a healthy governance culture\n\nGovernance Fund Charter: Guidance on the purpose and scope of the Governance Fund\n\nWe would appreciate community feedback on the following proposal drafts. Token House will vote on final drafts in Special Voting Cycle #9a:\n\nDraft Proposal: Moving to a Grants Council: A proposal to restructure the grants process to overcome the challenges faced by committees, improve the proposer experience, create accountability for grant recipients, and reduce delegate workload\n\nDraft Proposal: Protocol Delegation Program: A proposal to allow protocols to have a voice in governance without self-delegating grants\n\nIn recognition of the incredible work delegates have done in Seasons 1 & 2:\n\nRetroactive Delegate Rewards for Season 1 & 2: Retroactive rewards in recognition of the incredible work top active delegates have done\n\nThe next few weeks will follow the below schedule, as original outlined in Governance Update #4:\n\nNov 10 - Nov 16th: Off-Season for Committees to allocate the retroactive component of their compensation\n\nNovember 17th - December 7th: Reflection Period\n\nDec 8th - Dec 21st: Special Voting Cycle #9a (voting on grants council and protocol delegation program proposals)\n\nWe are making the following updates to the schedule following Special Voting Cycle #9a:\n\nDecember 22nd - Jan 4th: Holiday break\n\nJan 5th - January 18th: Special Voting Cycle #9b (any proposals contingent upon passing in Special Voting Cycle #9a). If Special Voting Cycle #9b is not necessary, Season 3 may start on January 5th\n\nJanuary 19th: Season 3 starts with Voting Cycle #10\n\n [DRAFT PROPOSAL]: Moving to a Grants Council\n\n Governance Weekly Recap\n\n [Special Voting Cycle #9a]: Grants Council\n\n [Special Voting Cycle #9a]: Protocol Delegation Program\n\n [DRAFT] [GF: Phase 1 Proposal] Optimistic Funding \n\n 2\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n Unlisted on Nov 8, 2022\n\n Listed on Nov 8, 2022\n\n Pinned globally on Nov 8, 2022\n\n post by linda on Nov 9, 2022\n\n linda\n\n Thank you for all of the work that went into receiving community feedback and working towards improvements. I’m really glad to see the changes being made and I’m excited for season 3.\n\n post by polynya on Nov 9, 2022\n\n polynya\n\nAn equally important problem not addressed here is participation among $OP token holders: [Temp-Check] - Give Incentives to Solve Voters Apathy\nSo, we both need higher participation of $OP token holders delegating to active delegates, and active participation from delegates.\n\n post by bobby on Nov 9, 2022\n\n bobby\n\n This call will take place on Meet:\nVideo call link: https://meet.google.com/qkh-kaaj-ptw\nMore phone numbers: https://tel.meet/qkh-kaaj-ptw?pin=8405857935366\n\n post by lavande on Nov 9, 2022\n\n lavande\n\n Call recording accessible here for those that couldn’t join: qkh-kaaj-ptw (2022-11-09 09:03 GMT-8) - Google Drive\n\n post by WellingtonOP on Nov 10, 2022\n\n WellingtonOP\n\n linda\n\n vamos trabalhar mais\n\n post by Bobbay_StableLab on Nov 10, 2022\n\n Bobbay_StableLab\n\n Even though season 2 felt like “ Two steps forward, one step backward” it’s important that we continue to experiment and see what works. I look forward to seeing the new changes implemented in Season 3, especially with an accountability committee.\n\n post by Njonnart on Nov 12, 2022\n\n Njonnart\n\n thanks for your work \n\n post by kinglee on Nov 12, 2022\n\n kinglee\n\n good job，thank you for your work\n\n post by kinglee on Nov 12, 2022\n\n kinglee\n\n good，Thank you for all of the work\n\n post by suwijak on Nov 14, 2022\n\n suwijak\n\n good job，thank you for your work\n\n post by Griff on Nov 15, 2022\n\n Griff\n\n Love the update! Thank you!\n\n post by Justin on Nov 15, 2022\n\n Justin\n\n polynya\n\n Big delegates have too much power. I have voted in every proposal because i care … but my tiny holdings are irrelevant compared to the handful of delegates that decide every vote. And those delegates effectively have lifetime power because there is no sunset on the delegation that users thoughtlessly sprinted through en route to claiming. I will continue to vote my own tokens, but just saying…\n\n post by Jrocki on Nov 16, 2022\n\n Jrocki\n\n govNERD\n\n BTW, props to whoever created the OP Governance Calendar, it has saved me so much time just being able to open up my personal calendar to see where we are vs searching in the forum and Discord\n\n post by Gonna.eth on Nov 16, 2022\n\n Gonna.eth\n\nIf the Grants council proposal is approved, will we vote the council members here: ?\n\nOr do we vote for council members at the start of season 3 here: ?\n\n post by lavande on Nov 16, 2022\n\n lavande\n\n Council elections would occur during Special Voting Cycle #9b\n\n post by andmus22 on Nov 17, 2022\n\n andmus22\n\n Thank U for clery informations \n\n Load more posts below","tokens":2171,"squid":"ink-governance","role":"Council Listener","at":1791258076080,"hash":"ee73fa7e2a11d07d8f0c8d88d03c68d633ca2e73"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/run-local-full-chain-simulation","domain":"docs.arbitrum.io","title":"How to run a local full chain simulation | Arbitrum Docs","text":"✏️Request an updateOverview​\nA local full-chain simulation allows you to deploy and test smart contracts in a fully controlled environment. This how-to walks you through the process of setting up and running a complete development environment on your local machine, including a Nitro node, a dev-mode Geth parent chain, and multiple instances with different roles.\nNote that the node is now Stylus-enabled by default, and the setup instructions remain the same as for running a Stylus dev node.\nStep 1. Install prerequisites​\nYou'll need Docker and docker compose to run your node. Follow the instructions on their site to install them.\nStep 2. Clone the nitro-testnode repo​\nYou'll need the release branch.\n `git clone -b release --recurse-submodules https://github.com/OffchainLabs/nitro-testnode.git && cd nitro-testnode`\nStep 3. Run your node​\n./test-node.bash --init\nStep 4. Successive runs​\nTo relaunch the node after the first installation, run the following command.\n./test-node.bash\nClear local dataRunning the --init flag will clear all chain data and redeploy!\nRollup contract addresses and chain configuration​\nYou can obtain the rollup chain configuration by running the following command. The chain configuration also includes the addresses of the core contracts.\ndocker exec nitro-testnode-sequencer-1 cat /config/l2_chain_info.json\nYou can find other available configuration files by running:\ndocker exec nitro-testnode-sequencer-1 ls /config\nToken bridge​\nAn parent-child chain token bridge can be deployed by using the parameter --tokenbridge. The list of contracts can be found by running:\ndocker compose run --entrypoint sh tokenbridge -c \"cat l1l2_network.json\"\nRunning an L3 chain​\nAn L3 chain can be deployed on top of the child chain (L2), by using the parameter --l3node. Its chain configuration can be found by running:\ndocker exec nitro-testnode-sequencer-1 cat /config/l3_chain_info.json\nWhen deploying an L3 chain, the following parameters are also available:\n--l3-fee-token: Uses a custom gas token for the L3 (symbol $APP), deployed on L2 at address 0x9b7c0fcc305ca36412f87fd6bd08c194909a7d4e\n--l3-token-bridge: Deploys an L2-L3 token bridge. The list of contracts can be found by running docker compose run --entrypoint sh tokenbridge -c \"cat l2l3_network.json\".\nAdditional arguments​\nYou can find a list of additional arguments to use with test-node.bash by using --help.\n./test-node.bash --help\nHelper scripts​\nThe repository includes a set of helper scripts for basic actions like funding accounts or bridging funds. You can see a list of the available scripts by running:\n./test-node.bash script --help\nIf you want to see information of a particular script, you can add the name of the script to the help command.\n./test-node.bash script send-l1 --help\nHere's an example of how to run the script that funds an address on L2. Replace 0x11223344556677889900 with the address you want to fund.\n./test-node.bash script send-l2 --to address_0x11223344556677889900 --ethamount 5\nBlockscout​\nNitro comes with a local Blockscout block explorer. To access it, add the param --blockscout when running your node.\n./test-node.bash --blockscout\nThe block explorer will be available at http://localhost:4000\nDefault endpoints and addresses​\nNode RPC endpoints are available at:\nNodeChain idRPC endpointL1 geth devnet1337http://localhost:8545L2 nitro devnet412346http://localhost:8547 and ws://localhost:8548L3 nitro (if enabled)333333http://localhost:3347\nSome important addresses:\nRolePublic addressPrivate keySequencer0xe2148eE53c0755215Df69b2616E552154EdC584f0xcb5790da63720727af975f42c79f69918580209889225fa7128c92402a6d3a65Validator0x6A568afe0f82d34759347bb36F14A6bB171d2CBe0x182fecf15bdf909556a0f617a63e05ab22f1493d25a9f1e27c228266c772a890L2 rollup owner0x5E1497dD1f08C87b2d8FE23e9AAB6c1De833D9270xdc04c5399f82306ec4b4d654a342f40e2e0620fe39950d967e1e574b32d4dd36L3 rollup owner (if enabled)0x863c904166E801527125D8672442D736194A33620xecdf21cb41c65afb51f91df408b7656e2c8739a5877f2814add0afd780cc210eL3 sequencer (if enabled)0x3E6134aAD4C4d422FF2A4391Dc315c4DDf98D1a50x90f899754eb42949567d3576224bf533a20857bf0a60318507b75fcb3edc6f5fDev account (prefunded with ETH in all networks)0x3f1Eae7D46d88F08fc2F8ed27FCb2AB183EB2d0E0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659\nYou can fund other addresses by using the scripts send-l1 and send-l2 as explained here.\nPrivate keys publicly knownDo not use any of these addresses in a production environment.\nOptional parameters​\nHere, We show a list of the parameters that might be useful when running a local devnode. You can also use the flag ./test-node.bash --help to get them.\n\nFlagDescription--initRemoves all the data, rebuilds, and deploys a new rollup--posL1 is a proof-of-stake chain (using Prysm for consensus)--validateValidates all blocks in WASM, heavy computation--l3nodeDeploys an L3 node on top of the L2--l3-fee-tokenSets up the L3 chain to use a custom fee token. Only valid if --l3node flag is provided--l3-fee-token-decimalsNumber of decimals to use for a custom fee token. Only valid if --l3-fee-token flag is provided--l3-token-bridgeDeploys an L2-L3 token bridge. Only valid if --l3node flag is provided--batchpostersBatch posters [0-3]--redundantsequencersRedundant sequencers [0-3]--detachDetaches from nodes after running them--blockscoutBuilds or launches the Blockscout--simpleRuns a simple configuration: one node as a sequencer/batch-poster/bonder (default unless using --dev)--tokenbridgeDeploy an L1-L2 token bridge--no-tokenbridgeOpt out of building or launching the token bridge--no-runDoes not launch nodes (useful with build or init)--no-simpleRuns a full configuration with separate sequencer/batch-poster/validator/relayerOverviewStep 1. Install prerequisitesStep 2. Clone the nitro-testnode repoStep 3. Run your nodeStep 4. Successive runsRollup contract addresses and chain configurationToken bridgeRunning an L3 chainAdditional argumentsHelper scriptsBlockscoutDefault endpoints and addressesOptional parameters","tokens":1510,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258076145,"hash":"11380849a0872703e79a311736bc7a75cb727e64"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/nitro/build-nitro-locally","domain":"docs.arbitrum.io","title":"How to build Nitro locally (Debian, Ubuntu, macOS) | Arbitrum Docs","text":"✏️Request an updateArbitrum Nitro is the software that powers all Arbitrum chains. This how-to shows how you can build a Docker image, or binaries, directly from Nitro's source code. If you want to run a node for one of the Arbitrum chains, however, it is recommended that you use the docker image available on DockerHub, as explained in How to run a full node.\nThis how-to assumes that you're running one of the following operating systems:\n\nDebian 12 (bookworm)\nUbuntu 24.04 (amd64)\nMacOS Sequoia 15.\n\nBuild a Docker image​\nStep 1. Configure Docker​\nFor Debian/Ubuntu​\nfor pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done# Add Docker's official GPG key:sudo apt-get updatesudo apt-get install ca-certificates curl gnupgsudo install -m 0755 -d /etc/apt/keyringscurl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpgsudo chmod a+r /etc/apt/keyrings/docker.gpg# Add the repository to Apt sources:echo \\ \"deb [arch=\"$(dpkg --print-architecture)\" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \\ \"$(. /etc/os-release && echo \"$VERSION_CODENAME\")\" stable\" | \\ sudo tee /etc/apt/sources.list.d/docker.list > /dev/nullsudo apt-get updatesudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginsudo service docker start\ninfoIf you are running Ubuntu 22.04, you might get an Unable to locate package docker-buildx-plugin error. Try sudo apt install docker-buildx instead.\nFor MacOS​\nDepending on whether your Mac has an Intel processor or Apple silicon, download the corresponding disk image from Docker, and move it into your Applications folder.\n[Optional] Run Docker from a different user​\nAfter installing Docker, you might want to be able to run it with your current user instead of root. You can run the following commands to do so.\nsudo groupadd dockersudo usermod -aG docker $USERnewgrp docker\nFor troubleshooting, check Docker's section in their documentation\nStep 2. Download the Nitro source code​\ngit clone --branch v3.12.1 https://github.com/OffchainLabs/nitro.gitcd nitrogit submodule update --init --recursive --force\nStep 3. Build the Nitro node Docker image​\ndocker build . --tag nitro-node\nThat command will build a Docker image called nitro-node from the local source.\nBuild Nitro's binaries natively​\nIf you want to build the node binaries natively, execute Steps 1-3 of the Build a Docker image section and continue with the steps described here. Notice that even though we are building the binaries outside of Docker, it is still used to help build some WebAssembly components.\nStep 4. Configure prerequisites​\nFor Debian/Ubuntu​\napt install git curl build-essential cmake npm golang clang make gotestsum wabt lld-13 python3npm install --global yarnln -s /usr/bin/wasm-ld-13 /usr/local/bin/wasm-ld\nFor MacOS​\nInstall Homebrew package manager and add it to your PATH environment variable:\n/bin/bash -c \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)\"echo \"export PATH=/opt/homebrew/bin:$PATH\" >> ~/.zprofile && source ~/.zprofile\nnoteReplace ~/.zprofile with ~/.bash_profile if you use bash instead of zsh).\nInstall essentials:\nbrew install git curl make cmake npm wabt llvm lld libusb gotestsumnpm install --global yarnsudo mkdir -p /usr/local/binecho \"export PATH=/opt/homebrew/opt/llvm/bin:$PATH\" >> ~/.zprofile && source ~/.zprofile\nStep 5. Configure node 24​\nFor Debian/Ubuntu​\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bashsource \"$HOME/.bashrc\"nvm install 24nvm use 24\nFor MacOS​\ncurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bashexport NVM_DIR=\"$HOME/.nvm\"[ -s \"$NVM_DIR/nvm.sh\" ] && \\. \"$NVM_DIR/nvm.sh\"nvm install 24nvm use 24\nStep 6. Configure Rust​\nNote that you may also need to use rustup toolchain remove nightly... to remove other Rust nightly toolchains that are installed​\ncurl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shsource \"$HOME/.cargo/env\"rustup install 1.93.0rustup default 1.93.0rustup target add wasm32-unknown-unknown --toolchain 1.93.0rustup target add wasm32-wasip1 --toolchain 1.93.0cargo install cbindgen\nStep 7. Install Bison 3.8.2​\nFor Debian/Ubuntu​\nsudo apt-get install bison\nFor MacOS​\nbrew install bison\nStep 8. Configure Go 1.25​\nInstall and configure Go​\nbash < <(curl -s -S -L https://raw.githubusercontent.com/moovweb/gvm/master/binscripts/gvm-installer)source \"$HOME/.gvm/scripts/gvm\"gvm install go1.25gvm use go1.25 --defaultcurl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v1.54.2\nnoteIf you use zsh, replace bash with zsh.\nInstall foundry version 1.2.3​\ncurl -L https://foundry.paradigm.xyz | bashfoundryup -i 1.2.3\nStep 9. Check dependencies​\n./scripts/check-build.sh\nIf this script shows any errors, fix them before proceeding to the next step.\nStep 10. Start build​\nmake\nStep 11. Produce binaries​\nmake build\nWarnings on MacOS​\nIn MacOS with Apple Silicon, warnings like the following might appear but they will not hinder the compilation process.\nld: warning: object file was built for newer 'macOS' version (14.4) than being linked (14.0)\nTo silence these warnings, export the following environment variables before building Nitro.\nexport MACOSX_DEPLOYMENT_TARGET=$(sw_vers -productVersion)export CGO_LDFLAGS=-Wl,-no_warn_duplicate_libraries\nStep 12. Run your node​\nTo run your node using the generated binaries, use the following command from the nitro folder, with your desired parameters\n./target/bin/nitro <node parameters>\nWASM module root error (v2.3.4 or later)​\nSince v2.3.4, the State Transition Function (STF) contains code that is not yet activated on the current mainnet and testnet chains. Because of that, you might receive the following error when connecting your built node to those chains:\nERROR[05-21|21:59:17.415] unable to find validator machine directory for the on-chain WASM module root err=\"stat {WASM_MODULE_ROOT}: no such file or directory\"\nTry add flag:\n--validation.wasm.allowed-wasm-module-roots={WASM_MODULE_ROOT}Build a Docker imageStep 1. Configure DockerStep 2. Download the Nitro source codeStep 3. Build the Nitro node Docker imageBuild Nitro's binaries nativelyStep 4. Configure prerequisitesStep 5. Configure node 24Step 6. Configure RustStep 7. Install Bison 3.8.2Step 8. Configure Go 1.25Step 9. Check dependenciesStep 10. Start buildStep 11. Produce binariesStep 12. Run your node","tokens":1640,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258088732,"hash":"5ba70f65518345feb2154df8bb892fb02d27af82"}
{"url":"https://gov.optimism.io/c/communications/delegates/41","domain":"gov.optimism.io","title":"Latest Communications 📣/Delegates 🏛 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Delegates 🏛\n\n Communications 📣\n\n Delegates 🏛\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Delegates category\n\n Info and discussions on voting, delegation, and the Token House\n\n 10\n\n 3.0k\n\n Mar 2025\n\n 404 Gov - Delegate Platform\n\n An important update regarding the future of 404 DAO’s governance operations. \nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What sta…\n\n read more\n\n 1\n\n 59\n\n 1d\n\n [Delegate Statement] Ezekiel Ekondu\n\n Hello Optimism Collective \nMy name is Ezekiel Ekondu, a student, designer, and Web3 content creator. I’m applying to become a delegate in the Optimism Collective with a strong interest in education, onboard…\n\n read more\n\n 0\n\n 29\n\n Jan 9\n\n Token House participation and incentives: Season 8 (Cycle 39a-45)\n\n season-8\n\n Intro\nThis report analyzes voting activity, feedback, and rationales using the top 100 delegates as a sample during Season 8. It focuses on how participation unfolded over the course of a relatively calm season, shaped b…\n\n read more\n\n 0\n\n 96\n\n Jan 9\n\n Public Forum to Wallet Link Verification\n\n Public Forum to Wallet Link Verification \nThis thread provides an open verification tool for linking your forum account to your wallet address. It serves as a public utility for integrating on-chain governance with forum…\n\n read more\n\n 17\n\n 490\n\n Nov 2025\n\n Token House participation and incentives: Season 6 (Cycle 23a-30)\n\n season-6\n\n As members of the crypto community return home after an exciting DEVCON 7🪩, Bitcoin has achieved a new all-time high. AI agents dominate Crypto Twitter, and memecoins capture attention both within and outside the crypto …\n\n read more\n\n 11\n\n 641\n\n Nov 2025\n\n Curia OP Governance Dashboard Update Thread\n\n GM everyone, \nI’m happy to share some new updates to the Curia OP Governance Dashboard, which I hope you’ll find useful. \nI’ve updated the UI, added support for new proposal types (like the ‘Joint House’ proposals), and …\n\n read more\n\n 0\n\n 74\n\n Oct 2025\n\n DAOplomats Delegate Communication thread\n\n Name: DAOplomats.eth \nDelegate Address: 0xc2490D220419ACdCeD68428Ac413c8483d08D1AB \nDelegate ENS Address: OP.DAOplomats.eth \nForum Username:, Jengajojo \nWebsite: DAOplomats.com \nTwitter: https://x.com/DAOplomats \nOu…\n\n read more\n\n 15\n\n 861\n\n Oct 2025\n\n Kpk - Delegate Communication Thread\n\n Delegate information\nName: kpk \nDelegate Address: 0x8787FC2De4De95c53e5E3a4e5459247D9773ea52 \nForum: @kpk \nTwitter: x.com \nLanguages: English \nIntroduction and experience\nkpk helps organisations secure, manage, and grow…\n\n read more\n\n 3\n\n 136\n\n Oct 2025\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n season-7\n\n Introduction\nSince Season 7, we can already see a shift from expansion to refinement. Season 7 introduced new governance bodies and experiments, focusing on building a DAO that can operate reliably over time. Rather than…\n\n read more\n\n 1\n\n 213\n\n Sep 2025\n\n Kuma hada - Delegation Communication Thread\n\n Hello! \nA brief intro of myself and delegate profile \n\nI have been contributing to Optimism for the past year, with a focus on growing the local community. I enjoy introducing solo developers to retroactive funding and t…\n\n read more\n\n 4\n\n 129\n\n Sep 2025\n\n [Delegate Statement] Meraj Rafie\n\n season-6\n\n Hello Optimism Citizens, \nMy name is Meraj Rafie, and I am a graduate of the Optimism Contributor Essentials (Super Cohort 0). \nI am applying to become a delegate in the Optimism Collective. \n Background: \n…\n\n read more\n\n 0\n\n 37\n\n Sep 2025\n\n [DRAFT] Incentivizing $OP Delegation Via Optimism Quests:\n\n Continuing the discussion from [Temp-Check] - Give Incentives to Solve Voters Apathy: \nThe Optimism Quests are a learn to earn campaign which allows users to earn free NFTs by completing a series of on and off chain task…\n\n read more\n\n 4\n\n 2.1k\n\n Sep 2025\n\n Uniswap Foundation: Delegate Statement for Optimism Governance\n\n Introduction\nWe’re excited to introduce the Uniswap Foundation (UF) as we begin participating in Optimism governance. As we work to support builders and users to make Unichain into the home of DeFi on the Superchain, we …\n\n read more\n\n 1\n\n 146\n\n Jun 2025\n\n Nanobro - Delegate Communication Thread\n\n My name is Nanobro. \nI am the founder of a crypto community with a focus on the OP Superchain and Ethereum mainnet. \nVoting profile: https://vote.optimism.io/delegates/nanobro.eth \nYou can connect with me on Twitter via: …\n\n read more\n\n 7\n\n 211\n\n Jun 2025\n\n Ethereum TGU - Delegate Communication Thread\n\n As the leading members of the Ethereum Community in Tegucigalpa, Honduras, we are happy to become active members of the OP Token House and look forward to contributing to the growth of the governance process in the OP ec…\n\n read more\n\n 0\n\n 89\n\n May 2025\n\n Event Horizon - Delegate Communication Thread\n\n Event Horizon\n\nDelegate Address: EventHorizonCommunity.eth\nSnapshot Delegate Profile: EventHorizonCommunity.eth\nForum Handle: @EventHorizon\nEmail: jordan@hvax.org\nTwitter: @EventHorizonDAO\nWebsite: https://EventHorizon.v…\n\n read more\n\n 0\n\n 72\n\n May 2025\n\n Introducing Soneium’s vision to the Optimism Collective\n\n Sup, Optimists! \nWe’re thrilled to officially join the Superchain with the mainnet launch of Soneium, a Superchain network built by Sony Block Solutions Labs. \nOur Vision \nSoneium unlocks new possibilities for creators, …\n\n read more\n\n 12\n\n 575\n\n Apr 2025\n\n She256 - Delegate Communication Thread\n\n Delegate Address: 0xed11e5eA95a5A3440fbAadc4CC404C56D0a5bb04 \nDelegate Statement\nshe256 started almost 4 years ago, with the mission to increase diversity in the crypto space. We fundamentally believe that blockchain tec…\n\n read more\n\n 5\n\n 162\n\n Apr 2025\n\n New Delegate Onboarding Monthly Community Call\n\n season-7\n\n Hi there! \nThe core @govNERDs will be facilitating an onboarding call for new delegates who want to have a more active participation in the collective. \n\nThe 30-minute space seeks to provide guidance by leveraging \n\nth…\n\n read more\n\n 4\n\n 171\n\n Mar 2025\n\n Cp0x Delegate Communication Thread\n\n Name: cp0x aka cp0x.eth \nTwitter Profile : https://x.com/cp0xdotcom?s=20 \nSnapshot profile : Snapshot \nOnchain voting profile: Agora \nABOUT \ncp0x is infrastructure, education, community. \nWe are actively fighting for t…\n\n read more\n\n 12\n\n 196\n\n Mar 2025\n\n Optimism Chinese Community - Delegate Communication Thread\n\n Delegate Name: optimismcn.eth \nEOA: 0xc841d6ddf66467af551b35218c0c2e22f9c14b48 \nDelegate Profile on Agora: optimismcn.eth on Agora \nTwitter: Optimismzh \nWe’re the OP Chinese Community delegation led by Marcus, aiming to …\n\n read more\n\n 5\n\n 255\n\n Mar 2025\n\n Chronarc Delegate Communication Thread\n\n season-7\n\n Hi everybody, I’m Chronarc! \nStarting today I am going to use this thread to talk about my ideas thoughts and choices for season 7. In general I will: \n\nVoting with Intention: I will prioritize fairness and proposals th…\n\n read more\n\n 4\n\n 142\n\n Feb 2025\n\n Delegate communication thread “Newbie”\n\n Hello guys! I’m Sumiechan, i am new here. Seems like this thread is good for sharing my thoughts. Hope we all can talk and share about our ideas through this communication thread. I’m excited to be part of the collective…\n\n read more\n\n 6\n\n 164\n\n Jan 2025\n\n Temperature: Delegate and Citizen Conference Stipend\n\n Hey Optimists! \nI’d like to open a thread for ideation on facilitating irl interactions for Delegates and Badgholders by supporting their attendance at conferences. I have been fortunate in attending ETHDenver, EthCC, mc…\n\n read more\n\n 0\n\n 61\n\n Jan 2025\n\n Ml_sudo - Delegate Communication Thread\n\n Kicking off a thread to communicate my values and priorities as a delegate. Feel free to DM if you have questions or suggestions! \nFirst post below will be focused on Season 7 (1H 2025).\n\n 1\n\n 112\n\n Jan 2025\n\n Michael (OPMichael.eth) Delegate Communication Thread\n\n Hey Everyone! \nI’m very excited that for the first time this season, my voting power has ended up above the 0.5% threshold has a delegate! For that reason I have decided to start this delegate communication thread. \nFor …\n\n read more\n\n 5\n\n 1.1k\n\n Jan 2025\n\n LXDAO- Delegate Community Thread\n\n Delegate Name: lxdao.eth \nEOA: 0xC3d7F926e57Ff06e465823b100b95408e805DfA2 \nDelegate Profile on Agora:lxdao.eth on Agora \nTwitter: LXDAO \nAbout LXDAO\nLXDAO is a decentralized organization dedicated to supporting the susta…\n\n read more\n\n 2\n\n 134\n\n Jan 2025\n\n Agora Updates & Feedback thread\n\n Hey everyone Charlie here from team Agora. \nReally appreciate everyone for trying out Optimism Agora Beta with the first test proposal and giving us such helpful feedback. \nWe’ve been reading all the posts, comme…\n\n read more\n\n 46\n\n 5.8k\n\n Dec 2024\n\n Delegate Onboarding Checklist Infographics\n\n season-6,season-7\n\n Hello! \nI’m sharing here version 1.0 of the ‘Delegate Onboarding Checklist Infographic’ that we wannabe-govNERDs have developed as part of our contribution path. \nI would especially like to thank t…\n\n read more\n\n 3\n\n 298\n\n Nov 2024","tokens":2292,"squid":"ink-governance","role":"Council Listener","at":1791258094935,"hash":"6289518a2fa6c37bd21b79ff45c2a53388788fd9"}
{"url":"https://aave.com/docs/aave-v4/liquidity/reserves","domain":"aave.com","title":"Aave Reserves | Aave Protocol Documentation","text":"Reserves#\nLearn how to discover and access reserves in Aave v4 spokes.\n\nReserve Data Structure#\nReserve data provides comprehensive information about each asset's lending and borrowing conditions, including:\nIdentification: IDs, spoke, chainUnderlying token informationSupply information: APY, liquidity, caps, collateral configurationBorrow information: APY, available liquidity, utilization rates, capsReserve configuration: collateral factor, liquidation bonus, liquidation fee, collateral riskReserve status: frozen, pausedUser incentives: extra APY and borrow discounts (see Incentive Programs)User-specific state: balances, borrowable amounts, collateral usage (when user is specified in request)\nTypeScriptGraphQLSolidityThe following TypeScript interfaces illustrate the core Reserve type:interface Reserve { __typename: \"Reserve\"; id: ReserveId; onChainId: OnChainReserveId; chain: Chain; spoke: Spoke; asset: HubAsset; summary: ReserveSummary; settings: ReserveSettings; status: ReserveStatus; canBorrow: boolean; canSupply: boolean; canUseAsCollateral: boolean; canSwapFrom: boolean; userState: ReserveUserState | null;}\nListing Available Reserves#\nDiscover all available reserves given some criteria.\nReactTypeScriptGraphQLSolidityUse the useReserves hook (or the imperative useReservesAction variant) to fetch a list of reserves.import { type ReservesRequest, useReserves } from \"@aave/react\";\nfunction ReservesList({ request }: { request: ReservesRequest }) { const { data, loading, error } = useReserves(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((reserve) => ( <div key={reserve.id}> <h3>{reserve.asset.underlying.info.name}</h3> <p>Spoke: {reserve.spoke.name}</p> </div> ))} </div> );}The useReservesAction hook does not watch for updates. Use it when you\nneed on-demand, fresh data (e.g., in an event handler).You can query reserves as follows.import { chainId } from \"@aave/react\";\nconst request: ReservesRequest = { query: { chainIds: [chainId(1)], },};Filter reserves by supply, borrow, or collateral.import { ReservesRequestFilter } from \"@aave/react\";\n// …\nconst request: ReservesRequest = { query: { // your query criteria }, filter: ReservesRequestFilter.Supply,};Add a user address to return ReserveUserState for each reserve.import { evmAddress } from \"@aave/react\";\n// …\nconst request: ReservesRequest = { query: { // your query criteria }, user: evmAddress(\"0x456…\"),};Sort reserves by asset name, user balance, APYs, collateral factor, or available amounts.import { OrderDirection } from \"@aave/react\";\n// …\nconst request: ReservesRequest = { query: { // your query criteria }, orderBy: { assetName: OrderDirection.Asc },};Specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\n// …\nconst { data, error, loading } = useReserves({ query: { // your query criteria }, currency: Currency.Eur,});\nFetching a Single Reserve#\nGet detailed information about a specific reserve.\nReactTypeScriptGraphQLUse the useReserve hook to fetch a specific reserve.import { type ReserveRequest, useReserve } from \"@aave/react\";\nfunction ReserveDetails({ request }: { request: ReserveRequest }) { const { data, loading, error } = useReserve(request);\n if (loading) return <p>Loading reserve...</p>;\n if (error) return <p>Error: {error.message}</p>;\n if (!data) return <p>Reserve not found</p>;\n return ( <div> <h2>Reserve ID: {data.id}</h2> <p>Supply APY: {data.summary.supplyApy.normalized.toFixed(2)}%</p> <p>Borrow APY: {data.summary.borrowApy.normalized.toFixed(2)}%</p> </div> );}See below for examples of ReserveRequest objects.import { chainId, evmAddress, type OnChainReserveId } from \"@aave/react\";\nconst request: ReserveRequest = { query: { reserveInput: { chainId: chainId(1), spoke: evmAddress(\"0x123…\"), onChainId: \"1\" as OnChainReserveId, }, },};Include user-specific state for the reserve.import { evmAddress } from \"@aave/react\";\nconst request: ReserveRequest = { query: { // your query criteria }, user: evmAddress(\"0x456…\"),};Finally, you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, loading, error } = useReserve({ query: { // your query criteria }, timeWindow: TimeWindow.LastWeek,});\nBorrow APY History#\nFetch historical borrow APY data for a specific reserve. By default, Merkl rewards are included in the returned rates; pass includeRewards: false for protocol base rates only.\nReactTypeScriptGraphQLUse the useBorrowApyHistory hook to fetch borrow APY history over time.import { type BorrowApyHistoryRequest, useBorrowApyHistory } from \"@aave/react\";\nfunction BorrowApy({ request }: { request: BorrowApyHistoryRequest }) { const { data, loading, error } = useBorrowApyHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((sample) => ( <div key={sample.date.toString()}> <p> <small>{sample.date.toLocaleDateString()}</small> {sample.avgRate.normalized.toFixed(2)}% </p> </div> ))} </div> );}See below for examples of BorrowApyHistoryRequest objects.import { TimeWindow } from \"@aave/react\";\nconst request: BorrowApyHistoryRequest = { reserve: reserve.id, window: TimeWindow.LastDay,};\nSupply APY History#\nFetch historical supply APY data for a specific reserve. By default, Merkl rewards are included in the returned rates; pass includeRewards: false for protocol base rates only.\nReactTypeScriptGraphQLUse the useSupplyApyHistory hook to fetch supply APY history over time.import { type SupplyApyHistoryRequest, useSupplyApyHistory } from \"@aave/react\";\nfunction SupplyApy({ request }: { request: SupplyApyHistoryRequest }) { const { data, loading, error } = useSupplyApyHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((sample) => ( <div key={sample.date.toString()}> <p> <small>{sample.date.toLocaleDateString()}</small> {sample.avgRate.normalized.toFixed(2)}% </p> </div> ))} </div> );}See below for examples of SupplyApyHistoryRequest objects.import { TimeWindow } from \"@aave/react\";\nconst request: SupplyApyHistoryRequest = { reserve: reserve.id, window: TimeWindow.LastDay,};\nReserve Holders#\nFetch a paginated list of the top holders for a specific reserve, filtered by suppliers or borrowers.\nReactTypeScriptGraphQLUse the useReserveHolders hook to fetch reserve holders for a specific reserve.import { ReserveHoldersFilter, useReserveHolders } from \"@aave/react\";\nfunction ReserveHoldersList({ reserveId }: { reserveId: string }) { const { data, loading, error } = useReserveHolders({ reserve: { reserveId }, filter: ReserveHoldersFilter.Supplied, });\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.items.map((holder) => ( <div key={holder.address}> <p>{holder.address}</p> <p> {holder.amount.amount.value.toFixed(4)}{\" \"} {holder.amount.token.info.symbol} </p> <p>{holder.weight.normalized.toFixed(4)}%</p> </div> ))} </div> );}Filter by ReserveHoldersFilter.Supplied (default) or ReserveHoldersFilter.Borrowed.import { ReserveHoldersFilter, useReserveHolders } from \"@aave/react\";\nconst { data } = useReserveHolders({ reserve: { reserveId: reserve.id }, filter: ReserveHoldersFilter.Supplied,});PreviousSpokesNextAssets","tokens":1853,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258094976,"hash":"9a5820b9698c68af1d8e66c343cc38e5a8c308d7"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/beacon-nodes-historical-blobs","domain":"docs.arbitrum.io","title":"Beacon Nodes: Historical Blobs | Arbitrum Docs","text":"✏️Request an updateLayer 2 network operators must connect to an Ethereum beacon chain node with historical blob data to ensure proper functioning of the Nitro node software, or risk failure in fetching blob data.\nIf you don't run your own beacon node, see Ethereum beacon chain RPC providers for a curated list of third-party providers and their historical-blob support status.\nImpacted audiences​\nRequired action will be required from: RPC nodes, Arbitrum One/Nova node operators, Arbitrum chain node operators\nIf you run a Nitro node and use an external L1 Ethereum beacon chain RPC URL​\n\nConfirm that your external L1 beacon chain RPC provider has configured their L1 beacon chain node to subscribe to all subnets.\n\nIf your external L1 beacon chain RPC doesn't subscribe to all subnets:​\n\nSwitch to a provider that does.\n\nIf you run a Nitro node and operate your own L1 Ethereum beacon chain node:​\n\nAdd the new flag (refer to specific client flags) to your beacon node's configuration.\n\nNoteEnsure that the external L1 beacon chain RPC provider you're using subscribes to all subnets.\nL1 beacon chain node flags​\nPrysm Consensus Layer clients​\nPrysm nodes have a new beacon node flag --subscribe-all-data-subnets that needs to be added to P2P options. Refer to the Prysm command-line options documentation for configuration details.\nThis flag is available as of Prysm v6.1.0. We recommend upgrading to the latest stable Prysm releases to ensure you have the most recent features and security updates.\nOther Consensus Layer clients​\nOther Consensus Layer nodes also have flags to ensure they sync data from across all subnets.\nVerificationThe Offchain Labs team hasn't verified the accuracy of the flags below, including the corresponding versions that support these flags. Consult the respective release notes and documentation for non-Prysm consensus layer clients to ensure you're adding the correct flags.\nSpecific client flags​\nSepolia onlyCurrently, the following clients are supported for Sepolia only.\n\nClientCompatible with NitroRequired Nitro FlagRequired flag for subscribing to all subnetsRequired flag to serve historical blobsPrysm 7.1.0 or newer✅None--blob-retention-epochs --semi-supernode --enable-backfillLighthouse✅None--supernode--prune-blobs false or --blob-prune-margin-epochsTeku✅None--p2p-subscribe-all-custody-subnets-enabledNone existsLodestar✅None--supernode--chain.archiveDataEpochs\nFor additional information regarding specific client flags visit their docs: Prysm, Lighthouse, Teku, and Lodestar.\nWe recommend using Prysm 7.1.0 or newer with the flags --semi-supernode, --enable-backfill, and removing --subscribe-all-data-subnets.\nChecklist​\nTo maintain uninterrupted node operation and blob availability:\n\nAdd the appropriate flag for your consensus layer client.\nVerify your Sepolia beacon endpoint’s configuration.\nVerify your Mainnet beacon endpoint’s configuration.\nImpacted audiencesL1 beacon chain node flagsPrysm Consensus Layer clientsOther Consensus Layer clientsSpecific client flagsChecklist","tokens":759,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258109115,"hash":"4ec7b291dad6a121deb7c2ef5409c68a557fdd39"}
{"url":"https://aave.com/docs/aave-v4/getting-started/solidity","domain":"aave.com","title":"Aave Solidity Integrations | Aave Protocol Documentation","text":"Solidity#\nGet started with the Aave smart contracts\n\nThe Aave smart contract interfaces provide methods for interacting with Aave Protocol v4. They enable lending, borrowing, and collateral workflows inside custom integrations. We recommend using Foundry for Solidity development.\nFor those beginning a new project, the Foundry boilerplate tailored for Aave v4 is highly recommended. It offers a foundational setup for efficiently deploying and testing smart contracts that integrate with the protocol.\nIncluded in the boilerplate are:\n/src: A sample smart contract demonstrating how to fetch user positions./script: Deployment scripts for your contracts./test: Example tests for your contracts.foundry.toml: A Foundry configuration file customized for Aave v4.\nInstall or update Foundry:\ncurl -L https://foundry.paradigm.xyz | bashfoundryup\nThen, follow these steps to get started:\n1Clone the Repository#Clone the boilerplate repository into a new project directory:git clone https://github.com/aave/aave-v4-foundry-template.git my-projectcd my-project2Install Dependencies#Install the project dependencies:forge install3Setup Environment#Create .env file from the .env.example template:cp .env.example .envand populate the required environment variables:PRIVATE_KEY=0x…\nUsage#\nThe project includes several Foundry commands designed to streamline your workflow:\nforge build: Compiles the contracts.forge test: Executes tests.forge script <script-path>: Deploys contracts using deployment scripts.forge clean: Removes build artifacts from the project.forge fmt: Formats the Solidity code.\nExample Deployment#\nTo deploy the example UserPositions contract:\nforge script script/Deploy_UserPositions.s.sol:DeployUserPositions \\ --sig \"run(address)\" <SPOKE_ADDRESS> \\ --rpc-url $RPC_URL \\ --private-key $PRIVATE_KEY \\\nAdvanced#\nAdd to Existing Project#\nIf you have an existing Foundry project and want to add Aave v4 contracts, install the dependency:\nforge install aave/aave-v4\nUpdate remappings.txt for imports to resolve correctly:\naave-v4/=lib/aave-v4/forge-std/=lib/forge-std/src/\nThen explore the Solidity section in the rest of the documentation for integration examples.","tokens":543,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258114490,"hash":"eace291e000d819825b9fc84bb11bf5ad361d1c5"}
{"url":"https://gov.optimism.io/t/delegate-statement-ezekiel-ekondu/10538","domain":"gov.optimism.io","title":"[Delegate Statement] Ezekiel Ekondu - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [Delegate Statement] Ezekiel Ekondu \n\n Communications 📣Delegates 🏛\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 9\n\n 1 / 1\n\n Jan 9\n\n Jan 9\n\n post by Ekondu on Jan 9\n\n Ekondu\n\n Hello Optimism Collective \nMy name is Ezekiel Ekondu, a student, designer, and Web3 content creator. I’m applying to become a delegate in the Optimism Collective with a strong interest in education, onboarding, UX, and public goods accessibility.\n Background\nI’m currently building my understanding of Optimism governance by actively reading proposals, participating in discussions, and learning how the Superchain operates. My background in design, storytelling, and community-focused content allows me to break down complex ideas into simple, digestible explanations — especially for new users and contributors.\nAs a student from the Global South, I’m particularly interested in how Optimism governance decisions impact:\n\nNew contributors\nStudents and early-career builders\nPublic goods adoption and awareness\n\n Delegate Commitment\nAs a delegate, I commit to:\n\nActively participating in governance votes\nReading and engaging with proposals thoughtfully\nSharing clear and transparent voting rationale\nContinuously improving my governance knowledge over time\n\nWhile I am still early in my governance journey, I bring consistency, curiosity, and accountability, and I aim to grow into a long-term contributor within the Optimism ecosystem.\n Communication Plan\n\nI will publish brief explanations of my votes on the governance forum\nI will share simplified summaries and perspectives to make governance more accessible\nI will remain reachable through the forum and my public social channels\n\n Delegate Address\n0x795acf09c28934457169ad538462c5bbbec10461\nThank you for considering me as a delegate.\nI’m excited to learn, contribute, and grow alongside the Optimism Collective as we build a more open and accessible future together.\n— Ezekiel Ekondu\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Kuma hada - Delegation Communication Thread\n\n Delegates 🏛\n\n Hello! \nA brief intro of myself and delegate profile \n\nI have been contributing to Optimism for the past year, with a focus on growing the local community. I enjoy introducing solo developers to retroactive funding and t…\n\n read more\n\n 4\n\n 129\n\n Sep 2025\n\n [Delegate Statement] Meraj Rafie\n\n Delegates 🏛\n\n season-6\n\n Hello Optimism Citizens, \nMy name is Meraj Rafie, and I am a graduate of the Optimism Contributor Essentials (Super Cohort 0). \nI am applying to become a delegate in the Optimism Collective. \n Background: \n…\n\n read more\n\n 0\n\n 37\n\n Sep 2025\n\n Delegate Spotlight\n\n Delegates 🏛\n\n season-4\n\n Optimism is home to some incredible contributors and delegates. The Collective has expressed interest in recognizing delegates that are actively contributing to Optimism Governance but may have less reach or visibility t…\n\n read more\n\n 10\n\n 3.0k\n\n Jul 2023\n\n MrCrypto Arabic Delegate Communication Thread\n\n Delegate Updates\n\n season-5,cycle-11\n\n Hello all! \nWe’re thrilled to initiate this dialogue as Delegates within Optimism’s Governance framework. The opportunity to join this collective effort and play a role in shaping impactful decisions fills us with enthus…\n\n read more\n\n 0\n\n 549\n\n Apr 2024\n\n Saludiego201.eth - Delegate Communication Thread\n\n Delegate Updates\n\n With this post, there will be a record and record of each of the votes, plus their justification, with me, with you as a community, and with the people who chose to delegate their OPs to me. \nName: Diego Ortiz Mayorca \nA…\n\n read more\n\n 1\n\n 1.6k\n\n Mar 2023","tokens":937,"squid":"ink-governance","role":"Council Listener","at":1791258114770,"hash":"1db6f4b71406d5638b8f995c15cce6d99f540c3f"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/nitro/nitro-database-snapshots","domain":"docs.arbitrum.io","title":"Nitro database snapshots | Arbitrum Docs","text":"✏️Request an updateNitro stores the chain state and data in a database in the local filesystem. When starting Nitro for the first time, it will initialize an empty database by default and start processing transactions from Genesis. It takes a long time for the node to sync from Genesis, so starting from a database snapshot is advisable instead. Moreover, for the Arbitrum One chain, you must start from a snapshot because Nitro cannot process transactions from the Classic Arbitrum node.\nFor an overview of snapshots in the context of initial node setup, see the Database snapshots section of Prepare to run a node.\nSupply the snapshot URL to Nitro​\nThere are multiple ways to supply Nitro with the database snapshot. The most straightforward way is to provide the configuration, so Nitro downloads the snapshot by itself. It is also possible to download the database manually and supply it to Nitro.\nDownloading the latest snapshot​\nNitro has a CLI configuration for downloading the latest snapshot from a remote server. Set the flag --init.latest to either archive, pruned, or genesis, and Nitro will download the preferred snapshot. Nitro rejects any other value. You may also change the --init.latest-base flag to set the base URL when searching for the latest snapshot.\ninfoAll three kinds that --init.latest accepts resolve to HashDB snapshots, so --init.latest cannot bootstrap a PathDB node. See PathDB snapshots.\nHow it works​\nWhen searching for the latest snapshot, Nitro uses the chain name provided in --chain.name. Make sure to set it correctly; otherwise, Nitro might be unable to find the snapshot. Nitro will look for a remote file in <latest-base>/<chain-name>/latest-<kind>.txt, where <kind> is the option supplied to --init.latest. This file should contain either the path or the full URL to the snapshot; if it only contains the path, Nitro will use the <latest-base> as the base URL.\nAfter finding the latest snapshot URL, Nitro will download the archive and temporarily store it in the directory specified in --init.download-path. Nitro looks for a SHA256 checksum on the remote server and verifies the checksum of the snapshot after finishing the download. (It is possible to disable this feature by setting --init.validate-checksum to false.)\nThe snapshot can be a single archive file or a series of parts. Nitro first tries to download the snapshot as a single archive. In this case, Nitro will look for a checksum file in <archive-url>.sha256. If the remote server returns not found (404 status code), Nitro will proceed to download the snapshot in parts. When downloading in parts, Nitro will look for a manifest file in <archive-url>.manifest.txt containing each part's name and checksum. In this case, Nitro will download each part in the manifest file and concatenate them into a single archive.\nFinally, Nitro decompresses and extracts the snapshot archive, placing it in the database directory. Nitro will delete the archive after extracting it, so if you need to set up multiple nodes with the same snapshot, consider downloading it manually, as explained below.\nDownloading the snapshot from a URL​\nInstead of letting Nitro search for the latest snapshot, you can provide a specific URL to download by setting the flag --init.url with the snapshot URL. If the URL points to a remote server, it should start with the https:// protocol definition. Given the URL, Nitro will download the snapshot as described in the \"Downloading the Latest Snapshot\" section.\nNitro also supports importing files from the local file system. In this case, you should provide the file path to --init.url starting with the prefix file:// followed by the file path. Beware that when running Nitro inside a Docker container, you must mount a volume containing the provided snapshot using the docker flag -v (see Docker documentation). Otherwise, the Nitro container running inside Docker won’t be able to find the snapshot in your local filesystem.\nPathDB snapshots​\nA snapshot only works with a node whose state scheme matches the snapshot's. A PathDB snapshot won't initialize a HashDB node, and the reverse also fails.\n--init.latest can't help you here: it accepts only archive, pruned, and genesis, and all three resolve to HashDB snapshots. Snapshots built with the path scheme are published under two separate kinds that --init.latest doesn't accept:\nKindNode typeAvailable forfull-pathFull nodeArbitrum One, Nova, Sepoliaarchive-pathArchiveArbitrum One, Sepolia\nEvery PathDB snapshot is pruned to its state-history window, because PathDB prunes as the node runs. There is no unpruned path variant to publish.\nInitialize a PathDB node​\nEach chain publishes a pointer file naming the current snapshot directory for each kind. Read it to find the URL:\ncurl https://snapshot.arbitrum.foundation/arb1/latest-full-path.txt\nUse latest-archive-path.txt for an archive node. For Arbitrum Sepolia, substitute sepolia-rollup for arb1.\nThe file contains a directory path, such as arb1/2026-08-01-a78755ba/. Pass the full URL to that directory, including the trailing slash:\n--init.url https://snapshot.arbitrum.foundation/arb1/2026-08-01-a78755ba/\nNitro reads the .manifest.txt file in that directory to enumerate the snapshot parts, downloads each part, and verifies its checksum.\nBefore downloading terabytes, confirm you have the right snapshot. Each directory publishes a metadata.json naming its state_scheme, snapshot_kind, and total size:\ncurl https://snapshot.arbitrum.foundation/arb1/2026-08-01-a78755ba/metadata.json\nYour node's --execution.caching.state-scheme must match the snapshot's state_scheme. See Choose a state scheme.\nDownloading the snapshot manually​\nFor most users, automatic download is recommendedUse --init.latest pruned (or archive) to enable Nitro's automatic handling of multi-part downloads, checksum verification, and extraction. In contrast, manual downloading is preferable only when you need to host a single snapshot locally for multiple nodes, offering direct control but requiring additional effort.\nIt is possible to download the snapshot manually and supply the archive instead of having Nitro download it.\nThe first step is downloading the snapshot. The command below illustrates how to do that on the command line using wget. The -c flag tells the wget to continue the download from where it left off, which is helpful because snapshots can be huge files, and the download can fail mid-way. The -P flag tells wget to place the snapshot on the temporary dir.\nwget -c -P /tmp \"$SNAPSHOT_URL\"\nAfter downloading the snapshot, make sure to verify whether the checksum matches the one provided by the remote server. To fetch the checksum, you may run the command below.\nwget -q -O - \"$SNAPSHOT_URL\".sha256\nOnce you know the expected snapshot checksum, run the command below to compute the checksum of the downloaded snapshot. Then, compare both and see if they are the same. If they are not the same, consider redownloading the snapshot. You must provide a valid snapshot to Nitro; otherwise, it won’t work properly.\nsha256sum $PATH_TO_SNAPSHOT\nFinally, you can provide a path to the downloaded snapshot archive to Nitro using the --init.url flag, as described in the \"Download the Snapshot from a URL\" section.\nDownloading snapshot parts​\nIf the snapshot is divided into parts, you should first download the manifest file in <snapshot-url>.manifest.txt. This manifest contains the names and checksums of each part. For instance, the snippet below shows how the manifest file should look. You may use the commands described previously to download each part of the snapshot and verify their checksums.\nnoteFor directory-style snapshot URLs, the manifest is the .manifest.txt file inside the directory. For example, https://snapshot.arbitrum.foundation/arb1/2026-08-01-a78755ba/.manifest.txt. Its part names include the directory prefix, so resolve them against the parent of the snapshot URL.The same directory also holds a metadata.json giving each part's filename, size, and both SHA-256 and xxHash checksums. Either file works for a manual download; Nitro itself reads .manifest.txt.\na938e029605b81e03cd4b9a916c52d96d74c985ac264e2f298b90495c619af74 archive.tar.part09e095ce82e70fa62bb6e7b4421e7f2c04b2cd9e21d2bc62cbbaaeb877408357b archive.tar.part1e92172d6eaf770a76c7477e6768f742fc51555a5050de606bd0f837e59c7a61d archive.tar.part2d1b6fb9aeeb23903cdbb2a7cca8e6909bff4ee8e51c8a5acac2a142b3e3a5437 archive.tar.part3f37e4552453202f2044e58b307bab7e466205bd280426abbc84f8646c6430cfa archive.tar.part4972c5f513faca6ac4fadd22c70bea97707c6d38e9a646432bc311f0ca10497ed archive.tar.part5\nAfter downloading all the parts and verifying their checksums, you may use the command below to join them into a single archive.\ncat archive.tar.part* > archive.tar\nExtracting the snapshot manually​\nIt is also possible to extract the snapshot archive and place the files manually. First, you need to download the snapshot archive as described in \"Manually Downloading the Snapshot\". Then, create the directory where Nitro will look for its database. By default, Nitro stores the database on $HOME/.arbitrum/$CHAIN/nitro. Move the archive to this directory and extract it. The commands below exemplify this process for the Arbitrum Sepolia chain.\nexport CHAIN=sepolia-rollupexport ARCHIVE_PATH=/tmp/archive.tar.gzmkdir -p $HOME/.arbitrum/$CHAIN/nitrocd $HOME/.arbitrum/$CHAIN/nitrotar zxfv $ARCHIVE_PATH\nYou should see the following subdirectories in this directory after extracting the archive.\narbitrumdatal2chaindatanodes\n\nCreating a snapshot​\nTo generate a snapshot for the Nitro database, you first need to stop the process gracefully. You must not generate the snapshot while Nitro runs because the database might be in an intermediary state. Nitro should print logs like the ones described below when stopping.\n^CINFO [08-22|18:10:55.015] shutting down because of sigintINFO [08-22|18:10:55.016] delayed sequencer: context done err=\"context canceled\"INFO [08-22|18:10:55.016] rpc response method=eth_getBlockByNumber logId=123 err=\"context canceled\" result=null attempt=0 args=\"[\\\"0x405661\\\", false]\"INFO [08-22|18:10:55.293] Writing cached state to disk block=39988 hash=8bebf3..939ab2 root=4f7a22..00c334INFO [08-22|18:10:55.297] Persisted trie from memory database nodes=643 size=156.31KiB time=3.673459ms gcnodes=329 gcsize=102.61KiB gctime=\"248.708µs\" livenodes=2448 livesize=806.00KiBINFO [08-22|18:10:55.297] Writing cached state to disk block=39987 hash=ddcd60..fe0fc3 root=d6973e..7b9265INFO [08-22|18:10:55.298] Persisted trie from memory database nodes=34 size=11.19KiB time=\"283.875µs\" gcnodes=0 gcsize=0.00B gctime=0s livenodes=2414 livesize=794.81KiBINFO [08-22|18:10:55.298] Writing cached state to disk block=39861 hash=2a9dd3..f00ff0 root=139d5a..d6bf21INFO [08-22|18:10:55.298] Persisted trie from memory database nodes=73 size=24.88KiB time=\"502.916µs\" gcnodes=0 gcsize=0.00B gctime=0s livenodes=2341 livesize=769.93KiBINFO [08-22|18:10:55.299] Writing cached state to disk block=39861 hash=2a9dd3..f00ff0 root=139d5a..d6bf21INFO [08-22|18:10:55.299] Persisted trie from memory database nodes=0 size=0.00B time=\"1.417µs\" gcnodes=0 gcsize=0.00B gctime=0s livenodes=2341 livesize=769.93KiBINFO [08-22|18:10:55.299] Writing snapshot state to disk root=bd18ce..3b0763INFO [08-22|18:10:55.299] Persisted trie from memory database nodes=0 size=0.00B time=\"1.125µs\" gcnodes=0 gcsize=0.00B gctime=0s livenodes=2341 livesize=769.93KiBINFO [08-22|18:10:55.304] Blockchain stopped\nAfter Nitro stops, go to the database directory and generate an archive file for the directories arbitrumdata, l2chaindata, and nodes. By default, the database directory for Nitro is $HOME/.arbitrum/$CHAIN/nitro. The commands below exemplify how to generate the snapshot for Nitro.\nexport CHAIN=sepolia-rollupexport ARCHIVE_PATH=/tmp/archive.tar.gzcd $HOME/.arbitrum/$CHAIN/nitrotar zcfv $ARCHIVE_PATH arbitrumdata l2chaindata nodes\nThis command purposely omits the wasm directory from the snapshot archive. The wasm contains native-code executables, so it might be a security concern for users downloading the snapshot. If the user downloading the snapshot trusts you, or if you are storing it for your own use, you may include the wasm directory in it.\nOptional: divide it into parts​\nIt is possible to divide the snapshot into smaller parts to facilitate its download. This is particularly useful for archive snapshots of heavily used chains, such as Arbitrum One. These kinds of snapshots can reach terabytes, so dividing them into smaller parts is helpful. The snippet below illustrates how to divide the snapshot into parts using the split command. The -b argument tells the split to divide the snapshot into 100 GB parts. The -d argument tells split to enumerate the parts using a numeric suffix instead of an alphabetic one.\nsplit -b 100g -d archive.tar.gz archive.tar.gz.part\nAfter dividing it into parts, you should generate the manifest file containing the parts' names and checksums. Nitro will use these files to know how many parts there are and to validate their checksum. The command below exemplifies how to do that.Supply the snapshot URL to NitroDownloading the latest snapshotHow it worksDownloading the snapshot from a URLPathDB snapshotsInitialize a PathDB nodeDownloading the snapshot manuallyDownloading snapshot partsExtracting the snapshot manuallyCreating a snapshotOptional: divide it into parts","tokens":3360,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258121631,"hash":"ed7a3d475b56900462de53718619ea4ec149cdb6"}
{"url":"https://aave.com/docs/aave-v4/positions","domain":"aave.com","title":"Aave v4 User Positions | Aave Protocol Documentation","text":"User Positions#\nLearn how to manage user positions on Aave v4.\n\nA User Position represents the complete financial state of a user within a specific Spoke, tracking User Supplies and User Borrows alongside key risk metrics such as Health Factor and Risk Premium.\nUnlike v3, where user positions were per-market, v4 positions are per-Spoke, allowing users to manage different strategies and risk profiles independently.\nIn the Aave Protocol, a User Account—often referred to simply as a User—is\na single Ethereum address that has interacted with the protocol, either as an\nExternally Owned Account (EOA) or a smart contract.\nUser Supplies#\nUser Supplies represent assets that a user has deposited into a spoke's Reserve. Each supply position:\nAccrues yield automatically through share-based accounting that appreciates over timeMay be enabled as collateral (if the reserve supports it) to provide borrowing power based on the asset's Loan-to-Value (LTV) ratioAffects the Risk Premium when enabled as collateral — riskier collateral assets increase the overall risk profile of the positionCan be withdrawn at any time, provided the position's Health Factor remains above 1.0\nThe above applies to standard Hub and Spoke behavior. Tailored implementations\nmay vary.\nUser Borrows#\nUser Borrows represent assets that a user has borrowed from a spoke's Reserve. Each borrow position:\nAccumulates interest based on the asset's borrow rate, increasing debt over timeRequires collateral backing according to liquidation thresholds specific to each borrowed assetImpacts the Health Factor as part of the total debt valueCan be repaid partially or fully at any time to reduce debt and free up collateral\nThe above applies to standard Hub and Spoke behavior. Tailored implementations\nmay vary.\nHealth Factor#\nThe Health Factor is the core safety metric that determines a user position's liquidation risk. It measures the stability of a user position:\nHealth Factor=Total Collateral Value×Weighted Average Collateral FactorTotal Borrow Value\\text{Health Factor} = \\frac{\\text{Total Collateral Value} \\times \\text{Weighted Average Collateral Factor}}{\\text{Total Borrow Value}}\nThe health factor value determines the position's safety status:\nAbove 1.0: The position is safe from liquidationBelow 1.0: The position becomes eligible for liquidation — liquidators repay only enough debt to restore the position to a healthy stateChanges dynamically as asset prices fluctuate and interest accrues on both supplies and borrowsCan be improved by supplying more collateral or repaying part of the borrowed amountDetermines available actions — new borrows or collateral withdrawals are blocked if they would reduce the Health Factor below 1.0\nExample:\nIf a user supplies $10,000 in ETH as collateral with an 80% Collateral Factor and borrows $6,000 in GHO, the health factor would be 1.333.\nUser Risk Premium#\nUser Risk Premium represents the additional interest charge applied to borrowing based on the quality of a user’s collateral. It determines how much extra a user pays on top of the base borrow rate for any borrowed asset within a Spoke.\nBased on Collateral Risk — a percentage value from 0% (highest quality) to 1000% (maximum risk) that reflects how risky an asset is when used as collateralWeighted by collateral amounts — calculated using only the collateral needed to cover total debt, starting with the safest assetsUpdated dynamically — recalculated when users withdraw, borrow, or through ad-hoc refresh.Lower is better — users with safer collateral pay lower interest rates\nFor example, a 0% User Risk Premium means paying only the base rate, while 50% means paying 50% more (7.5% total if base rate is 5%).\nCross-Spoke Strategies#\nv4’s modular design enables sophisticated position management across multiple Spokes.\nSpoke Isolation#\nEach Spoke maintains independent risk parameters and liquidation logic. This means:\nPositions in different Spokes do not affect each other’s Health FactorsA user can hold conservative positions in one Spoke and aggressive positions in another\nMulti-Hub Access#\nAdvanced Spokes can access multiple Hubs, enabling strategies such as:\nCollateralizing assets from one Hub to borrow from anotherAccessing different yield opportunities across Hub configurationsOptimizing liquidity and rates across the entire protocolPreviousIncentivesNextOpen Positions","tokens":1095,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258124419,"hash":"abafa3dccac33e8d4854b25eac4e95c89fd4f140"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/run-feed-relay","domain":"docs.arbitrum.io","title":"How to run a feed relay | Arbitrum Docs","text":"✏️Request an updatecautionIf running a single node, there is no need to run a feed relay. When running more than one node, it is strongly recommended to run a single feed relay per data center, which will reduce ingress fees and improve stability.Feed endpoints will soon require compression with a custom dictionary, so if connecting to a feed with anything other than a standard node, it is strongly suggested to run a local feed relay, which will provide an uncompressed feed by default.\nFor context on where the feed relay fits into Arbitrum's overall data flow, see Data availability. For the wire format the feed delivers, see How to read the sequencer feed. For how the feed relay compares to the other Nitro node roles, see How to assign roles to a Nitro node.\nThe feed relay is in the same Docker image as the Nitro node.\n\nHere is an example of how to run the feed relay for Arbitrum One:\ndocker run --rm -it -p 0.0.0.0:9642:9642 --entrypoint relay offchainlabs/nitro-node:v3.12.1-70fa99a --node.feed.output.addr=0.0.0.0 --node.feed.input.url=wss://arb1-feed.arbitrum.io/feed --chain.id=42161\n\nHere is an example of how to run nitro-node for Arbitrum One with a custom relay:\ndocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --node.feed.input.url=ws://local-relay-address:9642\n\nNote that Arbitrum Classic does not communicate with Nitro sequencer, so classic relay is no longer used.\nHelm charts (Kubernetes)​\nIf you are using Kubernetes to run your feed relay, a Helm chart is available at ArtifactHUB. It supports running a Nitro relay by providing the feed input URL. Find more information in the OCL community Helm charts repository.\nFeed connection behavior​\nThe sequencer feed is a long-lived WebSocket. Long-lived connections get terminated in normal operation by every layer they cross:\n\nEdge and CDN infrastructure. Public feed endpoints are typically served through CDN or edge proxy layers. Edge providers routinely restart servers as they roll out code across their networks, which drops the WebSocket connections those servers carry. Cloudflare, for example, documents this in its WebSockets technical note.\nLoad balancing and capacity changes. When feed capacity scales up or down (for example, to absorb a traffic burst), connections are redistributed across instances. Every redistribution is a disconnect/reconnect for the affected clients.\nOrdinary transit events. Route changes, edge maintenance, and idle and lifetime limits along the path.\n\nA healthy client logs a transient connection error at warning level (an EOF, a read timeout, a connection reset; the exact message varies by failure mode and client version), reconnects, and reports the feed connected again within seconds. Occurring a few times per day per connection, this is normal operation.\nTwo properties of the system bound the impact of any feed interruption:\n\nThe feed is a latency optimization, not the source of truth. Every message is also posted to the parent chain in batches. A node that misses feed messages backfills them from the parent chain automatically. Feed loss can add seconds to minutes of head latency; it cannot cause data loss or an incorrect chain.\nMessages carry monotonic sequence numbers, so clients holding multiple simultaneous feed connections remove duplicates by sequence number.\n\nWhat happens on reconnect (and why gaps appear)​\nOn reconnect, a client asks the server to resume from a requested sequence number. A feed instance can only replay what is in its own catchup buffer. After a capacity change, a reconnecting client may land on a fresh instance that does not hold the earlier history, and gets resumed at that instance's current position instead; the client logs a warning that the incoming sequence number is greater than the one it expected. The node fills that gap from the parent chain. This is safe, and it is the event that multi-primary redundancy eliminates: with two or more simultaneous primaries, the other connection has been streaming the whole time and there is no gap to fill.\nIn summary: redundancy must live on the client side, as multiple simultaneous connections. Server-side resume semantics cannot guarantee gapless delivery across a single connection's lifecycle.\nReference architecture for node providers​\nIf you run a fleet of nodes on behalf of customers (RPC provider, explorer, indexer), architect your relays and nodes for redundancy:\n\nRun your own feed relays. At least two, in different geographic regions, with distinct egress IPs.\nEach relay maintains at least two primary upstream connections to the upstream feed endpoint.\nEach node connects to at least two of your relays as primary feeds (a list of primary URLs), and at least one of them must be in a different region than the node. Do not use the secondary/fallback mechanism for redundancy.\nNever point a node fleet directly at the public feed. The relay layer collapses your fleet's footprint to a handful of upstream connections.\nDo not treat individual reconnects as incidents. Alert on sustained absence of feed data and on sustained head lag, not on individual transient connection errors.\n\nIf you follow 1-3, a disconnect on any single connection, relay, or region is invisible to your nodes. A single node run for your own use needs none of this: it will see periodic reconnects, briefly trail the chain head during them, and always converge via parent chain batches.\n\nLayer 1: your relays​\n\nAt least two relays, geographically distributed. Edge and transit problems are usually regional (a single CDN point of presence, one provider's backbone). Two relays entering the network from different regions reduces those failures.\nDistinct egress IPs. Feed load balancers commonly route connections to backends by client source IP (session affinity), so all connections from one egress IP tend to land on the same backend and stay there. Assume your effective upstream redundancy is bounded by how many distinct egress IPs you use, not by how many relay pods or connections you run. Ten relays behind one NAT IP is one unit of redundancy.\nAt least two primary upstream connections per relay:\n\nrelay \\ --chain.id=42161 \\ --node.feed.input.url=wss://arb1-feed.arbitrum.io/feed,wss://arb1-delayed-feed.arbitrum.io/feed \\ --node.feed.output.addr=0.0.0.0 \\ --node.feed.output.port=9642\nThe feed input accepts a comma-separated list of URLs. All of them are connected simultaneously and deduplicated by sequence number. Where a chain publishes only one public feed hostname, two connections to the same hostname from distinct egress IPs still provide meaningful redundancy (session affinity will generally pin them to different backends). Do not exceed two upstream connections per endpoint: each one doubles bandwidth, and excessive connections may be rate-limited at the edge.\nSome chains publish more than one feed endpoint. Arbitrum One, for example, also publishes a delayed feed that intentionally lags the real-time sequencer feed. Adding an endpoint like this as an extra primary upstream broadens a relay's redundancy: under sequence number duplication removal it contributes nothing while a real-time connection is ahead, and it keeps messages flowing, at its own intentional delay, if the real-time connections are interrupted. Check the chain's documentation for the endpoints it publishes.\nLayer 2: your nodes​\nEvery node lists at least two of your relays as primary feeds, and the set must span regions: the relay local to the node plus at least one relay in another region:\nnitro \\ --node.feed.input.url=ws://relay-region1.internal:9642,ws://relay-region2.internal:9642 \\ ...\nNitro connects to every URL in the primary list at the same time and removes duplication by sequence number. A reconnect, restart, or regional problem on one relay is invisible: the other connection never stopped streaming.\nTwo relays in the same region share edge and transit fate: a regional event (a degraded CDN point of presence, a transit problem, a datacenter issue) interrupts both primaries at once. The relay in the other region keeps the node streaming through it. The cross-region hop adds a small amount of latency on that connection; sequence number deduplication means the node always advances at the pace of whichever connection is ahead, so the local relay still sets your steady-state latency.\nMultiple primaries vs secondary-url fallback​\nNitro has two distinct mechanisms for listing more than one feed source, and they behave very differently.\nMultiple primaries (--node.feed.input.url with a list): every URL is connected simultaneously and permanently. Messages have duplicates removed by sequence number, and the node advances at the pace of whichever connection is ahead. Failover is instant and gapless because there is nothing to fail over: the other stream never stopped. The cost is bandwidth, since each connection carries the full feed.\nFallback (--node.feed.input.secondary-url): a standby list. In steady state, a secondary is not connected at all. The client opens a secondary connection only after the primaries have delivered no messages for a short inactivity window (on the order of seconds), brings secondaries up one at a time, and tears them back down once a primary has been delivering continuously again for a sustained period (on the order of minutes). Three consequences follow:\n\nIt is inactivity-triggered, not lag-triggered. A primary that is behind but still streaming never trips it, so it provides no protection against a lagging upstream.\nActivation is not gapless: by the time it fires, the node has already been silent for the length of the inactivity window, and normal reconnect and catchup dynamics apply on the new connection.\nWhen active, it is additive: the secondary runs alongside the primary rather than replacing it.\n\nWhen a fallback is appropriate:\n\nAs a break-glass input of a different class than your primaries, on a limited subset of nodes. For example: primaries on your two relays and a secondary pointing at the public feed, so that a total failure of your own relay layer still self-heals. Keep this to a small subset of nodes: applied fleet-wide, it creates a large direct public feed footprint when activated (every node opens its own secondary), subject to per-IP affinity and edge rate limiting.\nWhen bandwidth genuinely rules out a second always-on stream for a given node.\n\nA fallback is not a redundancy mechanism between equivalent sources. If two feed sources are both acceptable to consume continuously, list them both as primaries and let sequence number deduplication do the work. Avoid the inverted arrangement (your own relay as the only primary, with the public feed as a fleet-wide secondary): it provides no protection against a lagging relay and produces a fleet-wide public feed footprint whenever it activates.\nNever point the fleet directly at the public feed​\nNitro's reconnect loop retries roughly every 15 seconds, per node, indefinitely. A fleet of direct clients aggregates into a per-IP connection pattern that edge protections rate limit, and a rate-limited client can stay banned because it keeps retrying. Two relays collapse an arbitrarily large fleet into a handful of upstream connections.\nOperational guidance for your fleet​\n\nHealth checks: do not mark a node unhealthy because it logged a feed reconnect. Gate on sustained head lag, with tolerance for brief catch-up bursts after a reconnect, where messages per second spike while the node drains the backlog.\nAlert on state, not events:\n\narb_feed_sources_connected == 0 sustained for more than a minute (the node has no feed input at all)\nhead lag versus a reference RPC sustained beyond your latency SLO\nrelay upstream disconnect rate materially above its own baseline\n\nHelm charts (Kubernetes)Feed connection behaviorWhat happens on reconnect (and why gaps appear)Reference architecture for node providersLayer 1: your relaysLayer 2: your nodesMultiple primaries vs secondary-url fallbackNever point the fleet directly at the public feedOperational guidance for your fleet","tokens":3076,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258131665,"hash":"d50b7d6ccc14e0b93f1832a3731319957cb81dfd"}
{"url":"https://aave.com/docs/aave-v4/liquidity/chains","domain":"aave.com","title":"Aave Supported Chains | Aave Protocol Documentation","text":"Chains#\nLearn how to discover supported blockchain networks in Aave v4.\n\nChain Structure#\nChain data provides information about blockchain networks supported by Aave v4, including:\nIdentification: name, chain ID, icon URLConfiguration: explorer URL, whether it is a testnetNative token details: wrapped token address and metadata\nTypeScriptGraphQLThe following TypeScript interface illustrates the core Chain type:interface Chain { __typename: \"Chain\"; chainId: ChainId; name: string; icon: string; rpcUrl: string; explorerUrl: string; isTestnet: boolean; nativeWrappedToken: EvmAddress; nativeInfo: TokenInfo; nativeGateway: EvmAddress; signatureGateway: EvmAddress;}\nListing Supported Chains#\nDiscover all blockchain networks supported by Aave v4.\nReactTypeScriptGraphQLUse the useChains hook to fetch a list of supported chains.import { type ChainsRequest, useChains } from \"@aave/react\";\nfunction ChainsList({ request }: { request: ChainsRequest }) { const { data, loading, error } = useChains(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((chain) => ( <div key={chain.chainId}> <h3>{chain.name}</h3> <p>Chain ID: {chain.chainId}</p> </div> ))} </div> );}See below for examples of ChainsRequest objects.import { ChainsFilter } from \"@aave/react\";\nconst request: ChainsRequest = { query: { filter: ChainsFilter.ALL },};Where ChainsFilter is one of:ChainsFilter.ALL - All chainsChainsFilter.MAINNET_ONLY - Mainnets onlyChainsFilter.TESTNET_ONLY - Testnets only\nFetching a Single Chain#\nGet detailed information about a specific blockchain network by its chain ID.\nReactTypeScriptGraphQLUse the useChain hook to fetch a specific chain.import { type ChainRequest, useChain } from \"@aave/react\";\nfunction ChainDetails({ request }: { request: ChainRequest }) { const { data, loading, error } = useChain(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n if (!data) return <div>Chain not found</div>;\n return ( <div> <h3>{data.name}</h3> <p>Chain ID: {data.chainId}</p> </div> );}See below for an example of a ChainRequest object.import { chainId } from \"@aave/react\";\nconst request: ChainRequest = { chainId: chainId(1),};PreviousAssetsNextIncentives","tokens":573,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258134438,"hash":"0a80ec17f535596d4616c082ac15670a115e0d9e"}
{"url":"https://gov.optimism.io/t/404-gov-delegate-platform/10558/1","domain":"gov.optimism.io","title":"404 Gov - Delegate Platform - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n 404 Gov - Delegate Platform \n\n Communications 📣Delegates 🏛\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 13\n\n 1 / 2\n\n Jan 13\n\n 1d ago\n\n post by 404DAO on Jan 13\n\n 404DAO\n\n An important update regarding the future of 404 DAO’s governance operations.\nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What started as a small team of Georgia Tech students focusing on contributing to the Optimism DAO, quickly grew to becoming a trusted delegate in 10 ecosystems.\nAs the governance team evolved and members ventured into new opportunities, we began to evaluate what was the best path forward for our governance vertical. We determined that our delegated voting power deserves a dedicated steward who can commit the time and focus it requires.\nSo while 404 Gov is taking a step back from governance, the mission and work will continue with one of our team members, Rika, under her new entity, Axia Network, which has taken over the voting wallets and governance operations. Going forward, Axia Network is responsible for the voting activity of 0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5. Their work and delegation rationale can be found at the following account: Axia Network\nRika has been a core part of our team’s operations for many years now and deeply understands the responsibility involved with being a delegate. We are confident that the delegations will continue to be handled with professionalism under her stewardship. However, those that wish to remove their delegations may do so on Agora.\nThis transition applies only to governance-related wallets and profiles. Our partnership with Blockchain at Georgia Tech and educational work in Atlanta remains active.\nThank you to those who entrusted us with their voting power for so many years and thank you to the DAOs and contributors we’ve collaborated with in Optimism. It has been a privilege to take part in this ecosystem.\n\n Formally Announcing Axia Network\n\n 9 months later\n\n post by DarkEmpath888 1 day ago\n\n DarkEmpath888\n\n Please explain what this is … thanks, Jessica\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Formally Announcing Axia Network\n\n Delegate Updates\n\n season-9\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole…\n\n read more\n\n 0\n\n 50\n\n Jan 13\n\n Build a dedicated page for Delegation/Voting History\n\n ✨ General\n\n Right now, the only place to see all the delegates and make a selection is buried in the middle of the airdrop claim process (Optimism Gateway). There is another URL that shows the delegates, but there’s no functionality…\n\n read more\n\n 6\n\n 2.0k\n\n Jun 2022\n\n Protocol Delegation Program Renewal\n\n Metagovernance\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d\n\n Agora Updates & Feedback thread\n\n Delegates 🏛\n\n Hey everyone Charlie here from team Agora. \nReally appreciate everyone for trying out Optimism Agora Beta with the first test proposal and giving us such helpful feedback. \nWe’ve been reading all the posts, comme…\n\n read more\n\n 46\n\n 5.8k\n\n Dec 2024\n\n Governance Fund Observations\n\n Delegates 🏛\n\n Hello Optimism Community! @tnorm and I are two analysts on the Messari Governor team, and we’ve been covering Optimism governance as part of our daily workflow since the DAO launched. \n(Disclaimer: The thoughts, ideas, a…\n\n read more\n\n 11\n\n 4.8k\n\n Sep 2022","tokens":978,"squid":"ink-governance","role":"Council Listener","at":1791258136003,"hash":"e5cc53e3c85130263f14a766a99443f1acf59f5d"}
{"url":"https://aave.com/docs/aave-v4/getting-started/react","domain":"aave.com","title":"AaveKit React v4 | Aave Protocol Documentation","text":"React#\nGet started with AaveKit React\n\nAaveKit React for Aave v4 is a collection of React hooks for building decentralized applications on top of the Aave Protocol v4.\nGetting Started#\nTo get started, follow the steps below.\n1Install Packages#First, install the latest AaveKit React packages using your package manager of choice.npm install @aave/react@next2Setup Client#Then, create an AaveClient instance that will be used to interact with the protocol.import { AaveClient } from \"@aave/react\";\nexport const client = AaveClient.create();You don't need to install the @aave/client package as it's already included\nand re-exported by the @aave/react package.3Setup Provider#Next, wrap your app with the <AaveProvider> component and pass the client instance.import { AaveProvider } from \"@aave/react\";\nimport { client } from \"./client\";\nexport function App() { return ( <AaveProvider client={client}> {/* Your application components */} </AaveProvider> );}4Start Building#That's it—you can now start using AaveKit React. Here's a basic example to fetch supported chains:import { useChains } from \"@aave/react\";\nexport function SupportedChains() { const { data: chains } = useChains();\n return ( <div> <h2>Supported Chains</h2> {chains?.map((chain) => ( <div key={chain.chainId}> <h3>{chain.name}</h3> <p>Chain ID: {chain.chainId}</p> </div> ))} </div> );}\nDeclarative Hooks#\nAaveKit React declarative hooks execute on render with the given inputs, refresh when inputs change, and update after successful write operations; declarative hooks support two modes: loading state and React Suspense.\nLoading StateReact SuspenseHandle loading state manually in your component:import { useChains } from \"@aave/react\";\nfunction ChainsList() { const { data, loading, error } = useChains();\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((chain) => ( <div key={chain.chainId}>{chain.name}</div> ))} </div> );}\nPausable Reads#\nAaveKit React read hooks support pausing—a powerful pattern that lets you defer data fetching until certain conditions are met. This is particularly useful when:\nWaiting for user input (e.g., wallet connection, user address)Conditional data loading (e.g., only fetch when a user is authenticated)Dependent data (e.g., fetch user data only after chain selection)\nType safety is maintained by allowing nullish request parameters and returning a paused state, which explicitly signals when a hook is inactive and lets TypeScript precisely narrow types between paused and active states.\nimport { useChains } from \"@aave/react\";\nconst { data, loading, error, paused } = useChains({ pause: !connected,});\n// …\n// data: Chain[] | undefined// loading: boolean// error: UnexpectedError | undefined// paused: boolean\nif (paused) { // data: undefined // error: undefined // loading: boolean return null;}\nif (loading) { // data: undefined // error: undefined // loading: true return null;}\nif (error) { // data: undefined // error: UnexpectedError // loading: false return null;}\n// data: Chain[] (guaranteed to be defined)\nReloading State#\nDeclarative hooks also expose a reloading state that indicates when data is being refreshed after the initial load. This is different from loading, which is only true during the first fetch.\nThe reloading state becomes true when:\nVariables change and the hook refetches with new parametersPolling triggers a background refresh (if the hook is designed to poll)\nThis lets you show a subtle refresh indicator while keeping the previous data visible, rather than replacing content with a loading spinner.\nimport { useUserPositions } from \"@aave/react\";\nconst { data, loading, error, reloading } = useUserPositions({ user: userAddress,});\nif (loading) { return <Spinner />;}\nif (error) { return <ErrorMessage error={error} />;}\n// Show refresh indicator while keeping data visiblereturn ( <div> {reloading && <RefreshIndicator />} <PositionsList positions={data} /> </div>);\nImperative Hooks#\nAaveKit React imperative hooks return an execute function and a state object. These are tailored for when you need explicit control—like event handlers or multi‑step flows.\nconst [execute, state] = useImperativeHook();\nRead hooks that follow this pattern do not watch for updates. Prefer the\nimperative variant over the declarative one when you need on-demand, fresh\ndata (e.g., in an event handler).\nExecute Function#\nThe execute function takes the hook arguments and, when awaited, yields a Result<T, E>.\nUse isOk() and isErr() to check the outcome and narrow the type:\nconst result = await execute();\nif (result.isOk()) { console.log(\"Result:\", result.value);} else { console.error(\"Error:\", result.error);}\nSee the Result Objects section for more information about the Result object.\nState Object#\nThe state object provides information about the operation status:\nconst { called, data, error, loading } = state;\nWhere:\ncalled: true once the hook has run at least once.data: last successful result of type T, otherwise undefined.error: error of type E if the operation failed, otherwise undefined.loading: true while the operation is in progress, otherwise false.\nIntegrations#\nAaveKit React includes first-class support for viem, ethers v6, Privy, Dynamic, thirdweb and Turnkey.\nViemEthersPrivyDynamicthirdwebTurnkeyEnsure you have viem package installed in your project.npm install viem@2\nSend Aave Transactions#\nAaveKit React provides transaction hooks that handle protocol interactions like supply, borrow, withdraw, repay, and more.\nThere are two types of transaction hooks:\nSimple transactions - single transactions that can be sent directly to the walletComplex transactions - transactions that could require approval beforehand\nTo send transactions, follow the steps below.\n1useSendTransaction#First, use the provider‑specific useSendTransaction hook to send transactions with the connected wallet.const [sendTransaction, { loading, error }] = useSendTransaction(/* args */);It abstracts wallet differences and provides a consistent interface that interoperates with the other AaveKit React hooks.ViemEthersPrivyDynamicthirdwebTurnkeyImport the useSendTransaction hook from the @aave/react/viem entry point and wire it up with the viem's WalletClient.import { useSendTransaction } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\nfunction MyComponent() { const { data: walletClient } = useWalletClient(); const [sendTransaction, sending] = useSendTransaction(walletClient);\n // Use with transaction hooks…}The example uses wagmi to get the WalletClient from the\nconnected wallet.2Transaction Hook#Then, instantiate the specific transaction hook for the operation you want to perform.Simple TransactionsComplex TransactionsCall sendTransaction (from useSendTransaction) inside the simple‑transaction hook callback, as shown below.const [sendTransaction, sending] = useSendTransaction(/* … */);const [prepare, preparing] = useSimpleTransaction((transaction) => sendTransaction(transaction),);You can bail out of the operation at any point by calling the cancel(message) function.const [execute, { loading, error }] = useSimpleTransaction( (transaction, { cancel }) => { if (window.confirm(\"Are you sure you want to continue?\") === false) { return cancel(\"User cancelled the operation\"); } return sendTransaction(transaction); },);3Execute the Hook#Finally, execute the hook.Simple TransactionsComplex TransactionsIn your callback, call the execute function with the operation arguments and handle the result accordingly.const result = await execute(/* args */);\nif (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error(`Failed to sign the transaction: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return;}\nconsole.log(result.value.txHash); // TxHashYou can also take a declarative approach by using the loading and error state objects to drive your UI.function MyComponent() { // …\n return ( <div> <button disabled={loading}> {loading ? \"Sending…\" : \"Send Transaction\"} </button>\n {error && <p style={{ color: \"red\" }}>{error.message}</p>} </div> );}That's it—you now know the standard approach for handling Aave transactions with AaveKit React\nSign Typed Data#\nSome Aave operations require EIP-712 typed data signatures for the following:\nERC-20 Permits: Authorize exact amount transfers without separate approval transactionsSwap Intents: Sign swap orders for intent-based swaps\nPermits are available for ERC-20 tokens that implement\nEIP-2612.\nAs with useSendTransaction, instantiate the provider-specific useSignTypedData hook to sign typed data.\nViemEthersPrivyDynamicthirdwebTurnkeyImport the useSignTypedData hook from the @aave/react/viem entry point and wire it up with the viem's WalletClient.import { useSignTypedData } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\nfunction MyComponent() { const { data: walletClient } = useWalletClient(); const [signTypedData, sending] = useSignTypedData(walletClient);\n // Use with transaction hooks…}The example uses wagmi to get the WalletClient from the\nconnected wallet.\nThen, use the signTypedData function as described in the specific operation guide.\n\nAppendix#\nResult Objects#\nAaveKit uses a functional approach to error handling, it's based on Result<T, E> that represents one of two states:\nOk<T>: A successful result containing a value of type TErr<E>: A failure containing an error of type E\nimport { ok, err, Result } from \"@aave/react\";\nfunction parseNumber(input: string): Result<number, string> { return isNaN(Number(input)) ? err(new Error(\"Invalid number\")) : ok(Number(input));}\nWith a Result<T, E>, you can use the convenient isOk() and isErr() methods to check the outcome and narrow the type.\nconst result = parseNumber(\"123\");\nif (result.isOk()) { console.log(result.value); // 123} else { console.error(result.error); // Error}\nThis approach avoids reliance on try/catch blocks and promotes predictable, type-safe code by ensuring errors are handled explicitly.\nAaveKit uses the NeverThrow\nlibrary as underlying implementation for the Result object.\nResultAsync<T, E> is the async, thenable variant of Result<T, E>. Awaiting it resolves to a Result<T, E>.\nimport { ResultAsync } from \"@aave/react\";\nfunction fetchUser(id: number): ResultAsync<{ name: string }, Error> { return ResultAsync.fromPromise( fetch(`/api/users/${id}`).then((r) => r.json()), () => new Error(\"Not found\"), );}\nconst result = await fetchUser(1);\nif (result.isOk()) { console.log(result.value); // { name: \"John\" }} else { console.error(result.error); // Error}PreviousOverviewNextTypeScript","tokens":2732,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258144470,"hash":"ce16536ee128ddaaddbb81f25b3925e5c5b745c2"}
{"url":"https://gov.optimism.io/t/formally-announcing-axia-network/10559","domain":"gov.optimism.io","title":"Formally Announcing Axia Network - Communications 📣 / Delegate Updates - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Formally Announcing Axia Network \n\n Communications 📣Delegate Updates\n\n season-9\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Axia on Jan 13\n\n Axia\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole, and Manny — who shaped my thinking on protocol governance and instilled values of professionalism, rigor, and kindness, along with a strong commitment to doing good work. I’m proud to carry this torch forward and continue contributing to the Optimism Collective.\nAxia’s values emphasize supporting protocols through sustainable long-term growth, education, and strong oversight, while preserving decentralization by creating and sustaining pathways for community participation and meaningful checks and balances that ensure accountability and transparency across governance stakeholders.\nFor more information on this transition, please see @404DAO’s announcement in their delegate communications thread here.\nI welcome questions and feedback and am always open to engaging with community members and fellow delegates. Please don’t hesitate to send me a message.\nBest,\nRika Goldberg\nX: https://x.com/RikaGoldberg and https://x.com/AxiaNetwork0x\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n 404 Gov - Delegate Platform\n\n Delegates 🏛\n\n An important update regarding the future of 404 DAO’s governance operations. \nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What sta…\n\n read more\n\n 1\n\n 60\n\n 1d\n\n Axia Network — Delegate Communications Thread\n\n Delegate Updates\n\n Axia Network is a delegate across DAOs in the EVM ecosystem. Axia is committed to growing alongside the ecosystem and contributing responsibly to each protocol’s long-term success. \nAxia’s values emphasize supporting pro…\n\n read more\n\n 2\n\n 138\n\n Jun 1\n\n CyberDyn0x Delegate Thread\n\n Delegate Updates\n\n Hello Optimism Collective! \nWe are a newly formed delegate team looking to apply our collective experience to support progressive decentralization and governance experimentation, research and education. Stoked to be here…\n\n read more\n\n 3\n\n 2.2k\n\n May 2023\n\n Protocol Delegation Self-Nominations\n\n Elections\n\n While the code of conduct stipulates that delegates may not vote on their own candidacy in elections, in the case of approval/ranked choice votes, delegates may vote for themselves, so long as they also cast votes for th…\n\n read more\n\n 21\n\n 15.8k\n\n Jan 2023\n\n Protocol Delegation Program Renewal\n\n Metagovernance\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d","tokens":775,"squid":"ink-governance","role":"Council Listener","at":1791258146214,"hash":"3dc072f7de16a3b5f8fc09b2a18a072bf402c7b6"}
{"url":"https://www.openzeppelin.com/news/caceis-eurxt-smart-contract-security-audit","domain":"openzeppelin.com","title":"Crédit Agricole CACEIS EURXT Smart Contract Security Audit | OpenZeppelin","text":"October 2, 2026OpenZeppelin SecuritySummaryType: StablecoinsTimeline: 2026-05-20 → 2026-05-21Languages: SolidityFindingsTotal issues: 3 (0 resolved)Critical: 0 (0 resolved) · High: 0 (0 resolved) · Medium: 0 (0 resolved) · Low: 3 (0 resolved)Notes & Additional Information15 notes raised (0 resolved)Client Reported Issues0 reported issues (0 resolved)Executive SummaryOpenZeppelin was engaged by CACEIS to conduct a smart contract security audit of the EURXT contract, an upgradeable single-issuer euro stablecoin being designed for issuance under the MiCA framework. The goal of this engagement was to identify potential security vulnerabilities, verify the robustness of the business logic, and ensure the system aligns with best practices for permissioned tokenization architectures. The review was strictly limited to production-intended smart contracts. No mock contracts, unit tests, deployment scripts, or proxy initialization scripts were included in the scope. The Transparent Proxy and proxy administrator that govern upgrades, the multi-signature wallets and off-chain governance procedures that manage privileged role assignment, the trusted forwarder contract operated through the Taurus custody platform, and the off-chain settlement infrastructure responsible for redemption attribution and burn triggering were also outside the review boundary.The smart contract security audit did not identify any critical, high, or medium severity issues. Three low severity issues were raised, all of which describe operational refinements to the design rather than exploitable security defects. The three findings concern minimizing routine use of the most privileged role, preventing seized funds from being routed directly to the redemption address, and preventing token issuance before the redemption address has been configured. None of these findings describe a path that an external party can exploit against the contract or its holders. Each requires an already-trusted privileged operator to perform an action that the CACEIS operations manual explicitly excludes from normal procedure, and each is recoverable through ordinary administrative actions should it occur. As a result, even if these three findings remain in their current form at launch, they do not introduce material risk to token holders, to the issuer's reserves, or to the contract's regulatory posture. The smart contract security audit did not identify any defect that would allow unauthorized minting, unauthorized burning, theft of holder balances, evasion of the pause, evasion of the blacklist, or compromise of the role-based access control model.CACEIS has acknowledged the three low severity findings and has decided to address them in the next version of the smart contract, which will be the version deployed at launch.ScopeOpenZeppelin performed an audit of the implementation of the EURXT stablecoin contract. The codebase was provided as a ZIP file with SHA-256 hash 345e7f3ca1b6d2d726650af4baaf2ec3eae2df4468a7cf732b6a2920c7633951. Individual file-level hashes are listed in the Appendix.In scope were the following files:src├── EURXT.sol└── library ├── LibErrors.sol └── LibModifiers.solNone of the findings raised in this report have been remediated at this time. CACEIS has provided the following statement:“CACEIS acknowledges the three low findings. After careful analysis, we have decided to include the necessary fixes in the next version of the smart contract and proceed to go live with that release.”System OverviewEURXT (the Euro eXchange Token) is a single-issuer euro stablecoin contract from CACEIS. The contract represents one euro of issuer liability per token, uses six decimal places, and is designed to be deployed once as a Transparent Proxy implementation that delegates to a single EURXT logic contract. CACEIS has been authorized by the French ACPR under MiCA for crypto-asset services, and EURXT is being designed as a MiCA-regulated electronic-money token (EMT) under that regime rather than as a permissionless stablecoin. The deployment is pre-launch at the time of review, so the recommendations in this report are made without backwards-compatibility constraints on storage layout or external interfaces.The contract is built on the OpenZeppelin v4.9.4 upgradeable base contracts. It exposes the standard ERC-20 token surface, supports EIP-2612 permit-based approvals, and supports EIP-2771 meta-transactions to enable gasless approval and transfer flows through a trusted forwarder. An emergency pause mechanism can halt all token movement, and role-based access control is used to gate every privileged operation. Role administration is further restricted on-chain to ensure that no role can be unintentionally lost, by always requiring at least one holder to remain.Issuance and redemption are intentionally asymmetric. Minting transfers freshly issued tokens to a recipient nominated by the minter, modeling the on-ramp side of the off-chain fiat flow. Burning is restricted to a single redemption address configured by the administrator, modeling the off-ramp side: token holders redeem by sending EURXT to the redemption address, where the off-chain settlement infrastructure observes the inflow, settles a fiat payout, and then triggers the burn to destroy the staged tokens. The redemption address can be rotated by the administrator and is not constrained at the contract level to be empty before rotation. Regulatory seizure is implemented as a paired operation: an address is first added to the blacklist, then a dedicated seizure path moves the flagged balance to a compliant destination through a controlled bypass of the sender-blacklist guard.Every token movement passes through a central transfer hook that enforces the pause state, the sender-blacklist check (bypassed during regulatory seizure, and not applicable to mints since mints have no sender), and the recipient-blacklist check, which is enforced on every transfer including mints. All standard transfer paths route through this hook, including direct transfers, allowance-based transfers, and meta-transactions relayed by the trusted forwarder. As a result, no transfer path permits a blacklisted address to send tokens, and no transfer path permits the contract to credit a blacklisted recipient outside the explicit seizure flow. Allowance creation, whether through direct approval calls or EIP-2612 permits, is not routed through this hook, so allowances can be granted while the contract is paused or by or for a blacklisted address. Only the subsequent transfer is gated. The blacklist exception for allowances is documented in the contract, and the equivalent pause exception is the standard OpenZeppelin behavior and is inherited unchanged.Security Model and Trust AssumptionsThe on-chain access control surface defines six roles. All role-holders are assumed to be honest and to follow the off-chain governance procedures described in the CACEIS operations and access-control policy documents. Findings in this report do not flag scenarios that simply require multiple trusted role-holders to collude, unless such collusion breaks an explicit invariant.DEFAULT_ADMIN_ROLE: Acts as the administrator of all other roles. May grant, revoke, and renounce roles, rotate the redemption address, and update the on-chain metadata URI. Granted at initialization; all other roles are granted post-deployment.The administrator is trusted to follow the off-chain governance procedures documented in the CACEIS access-control policy when managing roles. Specifically, the following role-management trust assumptions are not enforced on-chain and rely on the administrator's discipline:A role is never granted to an address that is currently blacklisted. The on-chain layer does not cross-check the blacklist when granting roles, so an inadvertent grant could place an operational role at an address that is unable to use it.A role is never granted to an address known to be malicious or otherwise unsuitable, including OFAC-sanctioned addresses, addresses associated with confirmed exploits, and addresses flagged by other applicable sanctions or compliance lists. The on-chain layer performs no such cross-check.A role is never granted to the trusted forwarder address. Role checks resolve the caller via the EIP-2771 sender-resolution path, which can return the forwarder address itself on direct calls from the forwarder when the calldata is shorter than the appended-sender suffix. A forwarder that holds a role could therefore exercise that role through such short-calldata calls.A role is never granted to the contract itself, the zero address, or any other dead or unrecoverable address. The on-chain layer permits such grants, which would result in a role-holder that cannot sign transactions.All role grants and revocations follow the cross-team quorum requirements defined in the off-chain governance policy. The on-chain role-administration functions enforce only that the caller holds the role-admin for the target role; any further multi-party approval is the responsibility of the custody platform.MINTER_ROLE: May mint new tokens to any non-zero, non-blacklisted recipient. The minter is assumed to mint only when the corresponding fiat funds have been received and reserved off-chain, and never to mint before the redemption address has been configured, since redemptions cannot be processed until that configuration is in place. The minter is further assumed not to mint directly to the redemption address, which would inject tokens into the off-chain redemption attribution flow without a corresponding redemption ticket, and not to mint to the EURXT contract address itself, since the on-chain rescue path rejects EURXT as the token argument and any balance accruing at the contract address is therefore permanently stranded.BURNER_ROLE: May destroy tokens held at the redemption address; burns are not permitted from any other source. The burner is assumed to burn tokens only after the off-chain settlement system has confirmed that the corresponding fiat payout to the redeemer has been completed.PAUSER_ROLE: May pause and resume all token movement, including seizure operations; allowance creation is not affected by the pause. The pauser is assumed to use this capability only as an emergency circuit-breaker, and to recognize that allowances may continue to accumulate during pause windows and become spendable as soon as the pause is lifted.BLACKLIST_ADMIN_ROLE: May add or remove addresses from the blacklist, and may forcibly transfer the balance of a blacklisted address to a non-blacklisted destination through the on-chain seizure flow. The blacklist gates only token movement and does not block allowance creation, so any unsettled allowance involving a blacklisted party remains in storage but reverts at settlement time. The blacklist admin is assumed to operate under a documented compliance procedure aligned with MiCA freeze-and-seize requirements, and to direct seizures only to compliant destinations.RESCUER_ROLE: May rescue arbitrary foreign ERC-20 tokens held by the contract to any non-zero destination. The rescue path explicitly rejects EURXT itself as the token argument, which prevents the rescuer from sweeping EURXT accidentally sent to the contract by users. The rescuer is assumed to direct rescues to legitimate recovery destinations consistent with the original sender's intent.Additional ConsiderationsTrusted forwarder (EIP-2771): The contract supports EIP-2771 meta-transactions to enable gas-sponsored execution of operator transactions through the Taurus custody platform's fee-payer functionality. The trusted forwarder address is fixed in the implementation bytecode at deployment rather than stored, so rotation of the forwarder requires deploying a new implementation and upgrading the proxy. CACEIS has confirmed that the forwarder is restricted to internal Taurus/CACEIS-controlled addresses and is not exposed to public or third-party relayers, and that the forwarder contract itself is derived from the OpenZeppelin reference implementation, which verifies the signature of the original sender against the relayed call before appending the sender's address to the calldata suffix. The forwarder therefore cannot fabricate calls on behalf of role-holders; it can only relay transactions already signed by an account that holds the relevant role for the targeted privileged function, and the standard access-control checks continue to gate on the resolved original sender. The forwarder operator is held to the same trust assumptions as the privileged role-holders whose meta-transactions it relays, and the forwarder is assumed to remain restricted to the internal Taurus/CACEIS operator set. Compromise of the forwarder operator key does not on its own extend privileged-action capability beyond what the existing administrative trust model already implies, since the underlying access control still requires the original signer to hold the relevant role.Off-chain settlement infrastructure: The off-chain redemption pipeline observes inflows to the redemption address and is responsible for matching them to redemption tickets, settling fiat payouts, and instructing the burner to destroy the staged tokens. The contract does not encode this attribution: any transfer to the redemption address is indistinguishable on-chain from any other. Operators are trusted not to co-mingle seized funds, recovered funds, or other non-redemption flows into the redemption address, and the off-chain pipeline is trusted to correctly attribute inflows to legitimate redemption tickets. The review of the on-chain contract does not extend to the off-chain components that mint, settle redemptions, or trigger burns.Proxy and upgrade authority: The contract is intended to be deployed behind a Transparent Upgradeable Proxy managed by an external proxy administrator. Deployment scripts, the proxy itself, the proxy administrator configuration, and the upgrade authority are out of scope for this engagement and cannot be assessed from the source alone. Holders of the proxy administrator key may upgrade EURXT to arbitrary logic, including logic that rewrites balances or removes operational restrictions, and are trusted accordingly.Test coverage and deployment scripts: No automated test suite, deployment scripts, or proxy initialization scripts were provided as part of the in-scope material. Coverage of initialization correctness, role-granting workflows, and post-deployment operational checks therefore relies on the procedures documented in the CACEIS operations manual rather than on observed code. The internal test suite that CACEIS maintains around the contract was not included in scope, so the audit was unable to directly observe its coverage. The following areas are flagged as worth confirming that they are explicitly covered in the existing suite ahead of deployment: exhaustive role-gating tests that confirm each privileged actor can only invoke the functions intended for that role and reverts on every other privileged entry point, branch coverage of every revert path in the contract and its libraries, full lifecycle coverage of the mint, transfer, blacklist, seize, burn, pause, and upgrade flows, and integration tests that exercise the trusted forwarder relay against each user-facing entry point. Without such coverage, regressions introduced during future upgrades may silently expand the surface available to any given role and would not be detected by source-level audit alone.Low SeverityMaintenance Functions Gated by DEFAULT_ADMIN_ROLE Increase Admin Key ExposureIn OpenZeppelin's AccessControl pattern, DEFAULT_ADMIN_ROLE is the role used to grant and revoke every other role in a contract, and is intended to be reserved for role administration. In EURXT, this role is also used to gate two maintenance operations: setRedemptionAddress, which updates the address from which tokens may be burned during redemption, and setContractURI, which updates the off-chain metadata URI. Both functions are guarded by onlyRole(DEFAULT_ADMIN_ROLE), requiring the same key that controls role administration to be used for routine state changes.This deviates from the principle of least privilege. Because DEFAULT_ADMIN_ROLE controls role administration for the entire contract, increasing the frequency with which the holding key must sign transactions also increases its exposure to operational mistakes, signer phishing, and hardware-wallet blind-signing attacks. A dedicated lower-privilege role for these actions would allow the admin key to remain cold and limit any single signing-time compromise to non-administrative state.Consider introducing one or more lower-privilege roles to gate setContractURI and setRedemptionAddress, and restricting DEFAULT_ADMIN_ROLE to role-administration duties.Tokens Can Be Minted Before Redemption Address Is SetAfter initialize, _redemptionAddress defaults to address(0). In this state burn reverts unconditionally because it requires from == _redemptionAddress while LibModifiers.checkNonZero(from) simultaneously forbids from == address(0). The mint function has no equivalent precondition, so an account holding MINTER_ROLE can issue tokens before setRedemptionAddress has been called. Any tokens minted in that window have no on-chain redemption path until the redemption address is configured, even though the operational lifecycle requires a redemption address to be in place before minting begins.Consider adding a guard in mint that reverts when _redemptionAddress == address(0), enforcing the deployment ordering on-chain so that tokens cannot be issued ahead of a configured redemption address. Alternatively, consider accepting the initial redemption address as a parameter of initialize so the window cannot exist.seizeBlacklistedFunds Allows Seized Funds to Be Sent to the Redemption AddressseizeBlacklistedFunds transfers tokens from a blacklisted from address to an arbitrary to address. The only restrictions placed on to are that it is non-zero and not blacklisted. In particular, there is no check that to is not equal to _redemptionAddress._redemptionAddress is the staging address for the redemption flow: users send EURXT to it, and the off-chain redemption infrastructure observes those inflows to settle fiat payouts and eventually trigger burn via BURNER_ROLE. Sending seized funds directly to _redemptionAddress mixes them into the redemption accounting and, depending on how the off-chain system attributes inflows, could trigger an unintended fiat payout or otherwise corrupt redemption bookkeeping. Even if the off-chain system requires an explicit redemption ticket per inflow, co-mingling seized balances with voluntary redemptions adds operational risk that the contract can prevent at the on-chain layer.Consider rejecting to == _redemptionAddress in seizeBlacklistedFunds. If a regulatory order requires destruction of seized funds, the operator can move them first to a treasury address controlled by BURNER_ROLE, or any other intermediate destination, and then transition them into the redemption flow through a separate, deliberate step rather than as a side effect of seizure.Notes & Additional InformationOrphaned NatSpec BlockEURXT.sol contains a NatSpec block at lines 424 to 430 that documents a burn function, but is followed by the Storage section header comment with no function declaration beneath it. The block appears to be an artifact of a prior refactor or code move that left the documentation detached from any code.Consider removing the orphaned NatSpec block so that all documentation is colocated with the code it describes.Storage __gap Reserves 49 Slots Instead of the Conventional 50EURXT declares four state variables before its storage gap, but Solidity packs _seizureInProgress (a bool) and _redemptionAddress (an address) into a single slot because they are declared consecutively and fit together in 32 bytes. The four variables therefore occupy three slots, and combined with __gap[46] the contract reserves 49 slots rather than the 50 that the OpenZeppelin upgradeable storage convention reserves per contract.Consider increasing the gap to __gap[47] so the storage region matches the conventional 50-slot reservation.__AccessControlEnumerable_init Not Invoked in initializeIn EURXT.sol, the initialize function calls __AccessControl_init but does not call __AccessControlEnumerable_init from the inherited AccessControlEnumerableUpgradeable. In OpenZeppelin Contracts v4.9.x this initializer performs no setup, so the omission is currently safe. If a future version of OpenZeppelin Contracts adds setup work to __AccessControlEnumerable_init, that setup would be silently skipped on any subsequent upgrade of the implementation to that version.Consider invoking __AccessControlEnumerable_init immediately after __AccessControl_init in initialize.Custom Errors in require StatementsSince Solidity 0.8.26, custom errors can be used inside require statements. Initial support was limited to the IR pipeline. Solidity 0.8.27 extended this to the legacy pipeline as well.Throughout the codebase, every if (...) revert ... pattern could equivalently be expressed as a require statement that reverts with the same custom error.Consider replacing the if-revert patterns with equivalent require statements using the same custom errors, for conciseness and a small gas saving.Missing Security ContactProviding a security contact (such as an email address or ENS name) within a smart contract simplifies communication when a vulnerability is identified. It lets the contract owners specify the disclosure channel, reducing the risk that a reporter fails to surface an issue because they do not know where to send it. It also gives upstream maintainers a direct path to notify the owners about bugs found in third-party libraries used by the contract.Consider adding a NatSpec comment containing a security contact above each contract definition. Using the @custom:security-contact convention is recommended as it has been adopted by the OpenZeppelin Wizard and ethereum-lists.Missing Named Parameters in MappingSince Solidity 0.8.18, mappings can include named parameters in the form mapping(KeyType KeyName? => ValueType ValueName?) to clarify the role of the key and the value.The _blacklisted mapping in EURXT declares neither a key name nor a value name.Consider adding named parameters to mappings in order to improve the readability and maintainability of the codebase.Unused EmptyString Error in LibErrorsThe EmptyString error is declared in LibErrors but is never reverted from anywhere in the codebase.Consider removing the EmptyString error declaration.ContractURIUpdated Event Signature Diverges from ERC-7572The setContractURI function emits ContractURIUpdated(string newURI), while the canonical ERC-7572 event signature is ContractURIUpdated() with no parameters. The two signatures hash to different topic[0] values, so off-chain indexers, block explorers, and metadata refresh services that subscribe to the standard ERC-7572 event will not detect updates emitted by this contract.Consider changing the event declaration to event ContractURIUpdated() and removing the newURI argument from the emit. Consumers that need the new URI value can read it via contractURI() on the next block, as ERC-7572 intends.CannotRenounceLastRole Reused by revokeRoleThe revokeRole function reverts with LibErrors.CannotRenounceLastRole(role) when the caller is removing the last holder of a role. The name reads as a contradiction at this call site, since the caller is revoking another account's role rather than renouncing their own.Consider renaming the error to a neutral form such as CannotRemoveLastRoleHolder so that it reads correctly from both renounceRole and revokeRole.Last-Member Guard on All Roles Restricts Incident ResponseThe renounceRole and revokeRole overrides apply a last-member guard to all six roles defined by EURXT: DEFAULT_ADMIN_ROLE, MINTER_ROLE, BURNER_ROLE, PAUSER_ROLE, BLACKLIST_ADMIN_ROLE, and RESCUER_ROLE. When getRoleMemberCount(role) <= 1, both functions revert with CannotRenounceLastRole.For DEFAULT_ADMIN_ROLE this reflects a real risk, since losing the sole admin would permanently disable role administration. For the five operational roles, DEFAULT_ADMIN_ROLE can always re-grant them, so reaching a zero-holder state would be recoverable. The uniform guard, however, makes that zero-holder state unreachable: an incident response procedure that needs to temporarily revoke all holders of an operational role (for example, suspending every MINTER_ROLE holder while investigating a suspected key compromise) cannot be executed at all. The last holder cannot be revoked, and granting a placeholder beforehand does not help, since revoking the placeholder would itself trip the guard.The OpenZeppelin library provides AccessControlDefaultAdminRules, which protects only DEFAULT_ADMIN_ROLE and does so more strongly than a count-based check: it enforces a two-step transfer with a configurable delay, requires renunciation to follow the same delayed path, and ensures there is exactly one admin at a time. Operational roles remain under standard AccessControl semantics and stay fully revocable by an authorised admin.Consider adopting AccessControlDefaultAdminRules for DEFAULT_ADMIN_ROLE and removing the last-member guard from the five operational roles. This would preserve strong protection of DEFAULT_ADMIN_ROLE while restoring the ability to temporarily zero out an operational role during incident response.Last-Member Guard Duplicated Between revokeRole and renounceRolerevokeRole and renounceRole both apply the same last-member guard before delegating to super. Since both functions route through the internal _revokeRole hook in AccessControlUpgradeable, the guard could instead be placed in an override of _revokeRole, applying it to both entry points from a single location and removing the duplicated logic as well as the multi-base override declarations.Consider moving the last-member guard into an override of _revokeRole and removing the duplicated checks from revokeRole and renounceRole.Inaccurate DocstringsThroughout the codebase, several docstrings do not match the implementation:The storage-layout comments in the contract docstring and at the __gap declaration in EURXT.sol state that three custom storage variables are declared and enumerate _blacklisted, _contractURI, and _seizureInProgress. These comments omit _redemptionAddress and the fact that _seizureInProgress and _redemptionAddress are packed into a single storage slot.The @dev block on isBlacklisted describes the function as being used \"on-chain by mint/burn guards and _beforeTokenTransfer\". In practice, those on-chain paths read the _blacklisted mapping directly, so the function is only used off-chain.Consider updating each of the docstrings listed above so that they accurately describe the current implementation.Deviations from the Solidity Style GuideEURXT.sol contains deviations from the Solidity style guide conventions. One instance is the declaration of the RedemptionAddressUpdated event at line 444, between function definitions, while all other events (Blacklisted, UnBlacklisted, BlacklistedFundsSeized, ContractURIUpdated, RescueERC20) are grouped together at lines 253 to 277. The style guide recommends grouping event declarations near the top of the contract rather than interleaving them with functions.Consider relocating RedemptionAddressUpdated to the events section alongside the other event declarations, and reviewing the contract for any other deviations from the Solidity style guide.Use of OpenZeppelin Contracts v4.9.x Requires Legacy __gap Storage PatternThe EURXT token is deployed behind a TransparentUpgradeableProxy and inherits from v4.9.4 of the OpenZeppelin Contracts Upgradeable library. This release predates v5.x, which migrates upgradeable contracts to the ERC-7201 namespaced storage layout. As a result, EURXT relies on the legacy uint256[50] reserved-slots convention, in which every contract in the inheritance chain reserves a fixed-size __gap array and must decrement that array in step with any new state introduced by a parent. Any drift in this accounting silently corrupts storage on upgrade.The cost of this convention is not limited to keeping a counter aligned. Because each parent's storage is laid out sequentially with the child's, any future change to the inheritance chain (for example, introducing a new base contract, removing one, reordering inheritance, or adopting a parent that itself adds state) shifts every downstream variable and requires a coordinated rewrite of __gap declarations across the chain to preserve the existing storage layout. In a deployed, upgradeable contract this is a high-risk operation: a single miscalculation produces silent storage collisions whose effects can range from subtle accounting bugs to full loss of contract state. ERC-7201 namespaced storage, adopted in v5.x, eliminates this class of problem by giving each contract a derived storage slot that is independent of its position in the inheritance chain, so adding, removing, or reordering parents no longer affects the layout of any other contract.Consider migrating to OpenZeppelin Contracts v5.x, which adopts ERC-7201 namespaced storage and removes the cross-contract __gap bookkeeping required by the v4.x inheritance model. Performing this migration before deployment makes future upgrades materially less risky and removes a recurring source of upgrade hazards.Redundant CodeThroughout the codebase, several code redundancies were identified that increase gas costs and maintenance surface. In particular:In mint, the recipient is checked against _blacklisted before calling _mint. The same check is then performed inside _beforeTokenTransfer, which _mint invokes, and both paths revert with LibErrors.Blacklisted(to).rescueERC20 reverts with a dedicated LibErrors.RescueAmountZero for the zero-amount check, while every other zero-amount check in the contract goes through LibModifiers.checkNonZeroAmount and reverts with the generic LibErrors.ZeroAmount. The dedicated error can be removed and the check unified with LibModifiers.checkNonZeroAmount.In seizeBlacklistedFunds, the _blacklisted[to] check is redundant: _beforeTokenTransfer performs the same recipient-blacklist check unconditionally (the _seizureInProgress guard only skips the sender check) and reverts with the same LibErrors.Blacklisted(to) error. The LibModifiers.checkNonZero(to) call is also redundant with the zero-address check inside ERC20Upgradeable._transfer, although removing it would change the revert from LibErrors.ZeroAddress to the OpenZeppelin default string, so retaining the explicit check for error-message consistency is also a reasonable choice.In supportsInterface, the explicit check against type(IAccessControlUpgradeable).interfaceId is redundant: AccessControlUpgradeable.supportsInterface, reached via the super.supportsInterface fallback, already returns true for that interface ID.In _beforeTokenTransfer, the call to LibModifiers.checkNotPaused(paused()) duplicates the work of PausableUpgradeable._requireNotPaused() (or equivalently the whenNotPaused modifier). Removing the wrapper would change the revert from LibErrors.TokenPaused to the OpenZeppelin default string \"Pausable: paused\", so retaining the explicit check for error-message consistency is also a reasonable choice.The literal 6 representing the token's decimal precision is duplicated: it is returned directly by decimals() and used again as the exponent in MAX_SUPPLY = 5_000_000_000 * 10 ** 6. Defining a single private constant such as uint8 private constant DECIMALS = 6 and referencing it from both sites would remove the duplication and keep the two values in sync.Consider removing the redundant code and consolidating the checks and constants listed above where doing so does not conflict with explicit error-message requirements.ConclusionEURXT implements a single-issuer, pre-launch euro stablecoin intended for issuance by CACEIS as a MiCA-regulated electronic-money token under its ACPR authorization. OpenZeppelin audited the implementation of the EURXT contract together with its supporting LibErrors and LibModifiers libraries.The codebase is concise and organizes its functionality into clearly delimited subsystems for issuance, redemption staging, blacklist management, regulatory seizure, pause control, and role administration, each gated by a dedicated access-control role. Inline NatSpec documentation and the supplementary client documents (covering the business specification, technical reference, governance policy, and operations manual) were sufficient to follow the intended end-to-end flow, including the off-chain redemption pipeline and the mapping between on-chain roles and the off-chain Taurus custody groups responsible for signing each operation. No issues of medium severity or higher were identified during the engagement. CACEIS has acknowledged the three low severity findings and has decided to incorporate the corresponding fixes into the next version of the smart contract, which will be the version taken to launch.The audited material did not include an automated test suite, deployment scripts, or proxy initialization scripts. The supplied operations manual covers the deployment and post-deployment checklists in detail, including the proxy and ProxyAdmin configuration, the ordering of role grants, and the Taurus custody setup, so the absence of those scripts in the in-scope material is partially offset by the documented procedure. The internal test suite that CACEIS maintains around the contract was not included in scope, so the audit was unable to directly observe its coverage. The following areas are highlighted as warranting explicit coverage in the existing test suite ahead of deployment: exhaustive role-gating tests that confirm each privileged actor can only invoke the functions intended for that role and reverts on every other privileged entry point, branch coverage of every revert path in the contract and its libraries, full lifecycle coverage of the mint, transfer, blacklist, seize, burn, pause, and upgrade flows, and integration tests that exercise the trusted forwarder relay against each user-facing entry point. The supporting trust assumptions documented in the introduction, particularly those covering role management, the redemption-address lifecycle, and the off-chain settlement pipeline, should also be reflected in deployment runbooks and continuous monitoring so that any drift from the modeled behavior is detected early.The OpenZeppelin team is grateful to CACEIS for their responsiveness, clear explanations, and thorough supporting documentation throughout the engagement.AppendixFile-level HashesInitial ReviewBelow are the SHA-256 hashes for all individual files that were in scope and reviewed during the initial codebase review.src/library/LibModifiers.sol0db63bf03634352ef99a819a81da5b38974e325a09286bc4d24b78a6a8c7f7d7src/library/LibErrors.solb26ee15d00bc2463ba566192fa0baefc7f3a5c286975eeaca5611dafa0f3e12bsrc/EURXT.sol8df99cfafbe614ceb18387448b5d5ca37d66059d7c421d22b0377073a4634319Issue ClassificationOpenZeppelin classifies smart contract vulnerabilities on a 5-level scale:CriticalHighMediumLowNote/InformationCritical SeverityThis classification is applied when the issue’s impact is catastrophic, threatening extensive damage to the client's reputation and/or causing severe financial loss to the client or users. The likelihood of exploitation can be high, warranting a swift response. Critical issues typically involve significant risks such as the permanent loss or locking of a large volume of users' sensitive assets or the failure of core system functionalities without viable mitigations. These issues demand immediate attention due to their potential to compromise system integrity or user trust significantly.High SeverityThese issues are characterized by the potential to substantially impact the client’s reputation and/or result in considerable financial losses. The likelihood of exploitation is significant, warranting a swift response. Such issues might include temporary loss or locking of a significant number of users' sensitive assets or disruptions to critical system functionalities, albeit with potential, yet limited, mitigations available. The emphasis is on the significant but not always catastrophic effects on system operation or asset security, necessitating prompt and effective remediation.Medium SeverityIssues classified as being of medium severity can lead to a noticeable negative impact on the client's reputation and/or moderate financial losses. Such issues, if left unattended, have a moderate likelihood of being exploited or may cause unwanted side effects in the system. These issues are typically confined to a smaller subset of users' sensitive assets or might involve deviations from the specified system design that, while not directly financial in nature, compromise system integrity or user experience. The focus here is on issues that pose a real but contained risk, warranting timely attention to prevent escalation.Low SeverityLow-severity issues are those that have a low impact on the client's operations and/or reputation. These issues may represent minor risks or inefficiencies to the client's specific business model. They are identified as areas for improvement that, while not urgent, could enhance the security and quality of the codebase if addressed.Notes & Additional Information SeverityThis category is reserved for issues that, despite having a minimal impact, are still important to resolve. Addressing these issues contributes to the overall security posture and code quality improvement but does not require immediate action. It reflects a commitment to maintaining high standards and continuous improvement, even in areas that do not pose immediate risks.Ready to secure your code? Request an Audit","tokens":9525,"squid":"ink-security_audits","role":"Sentinel","at":1791258154089,"hash":"d56b77ef08ffd06b27e993832ed756ab1e739ed0"}
{"url":"https://ethresear.ch/tag/transaction-privacy/67","domain":"ethresear.ch","title":"Latest transaction-privacy topics - Ethereum Research","text":"Latest topics tagged transaction-privacy\n\n categories\n\n transaction-privacy\n\n Latest\n\n Categories\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Mempool Account Transaction Capacity from Historical Activity (MATCHA)\n\n Execution Layer Research\n\n account-abstraction,transaction-privacy\n\n 11\n\n 540\n\n 18h\n\n EIP-8141 and minimum required validation budget for privacy applications\n\n Execution Layer Research\n\n account-abstraction,transaction-privacy\n\n 2\n\n 247\n\n Sep 5\n\n EIP8287: Privacy-Native Fungible Token Standard (Draft)\n\n Privacy\n\n transaction-privacy\n\n 14\n\n 812\n\n Jul 13\n\n PrivateX402: Privacy-Preserving Payment Channels for Multi-Agent AI Systems\n\n Applications\n\n transaction-privacy,cryptoeconomic-primitives\n\n 2\n\n 816\n\n Jul 6\n\n Towards Native Post-Quantum Private ETH\n\n Privacy\n\n transaction-privacy\n\n 7\n\n 489\n\n Jun 29\n\n # pERC20: Private Token Standard (Draft) - ‘Approve’ extended\n\n Privacy\n\n transaction-privacy\n\n 0\n\n 157\n\n Jun 21\n\n Etherveil - An Ethereum Privacy Browser\n\n Privacy\n\n transaction-privacy\n\n 9\n\n 412\n\n Jun 20\n\n Ethereum Privacy: The Road to Self-Sovereignty\n\n Privacy\n\n transaction-privacy\n\n 20\n\n 5.3k\n\n Jun 16\n\n Closing the Last UX Gap in Crypto: Privacy-Preserving Payments to Email, Phone, and Social Handles, Rather Than a Wallet Address\n\n Applications\n\n transaction-privacy\n\n 2\n\n 118\n\n May 18\n\n The Substrate: Permissionless Settlement Protocol Index\n\n Economics\n\n zk-roll-up,rollup,p2p,transaction-privacy,public-good\n\n 0\n\n 90\n\n May 2\n\n ZK API Usage Credits: LLMs and Beyond\n\n Applications\n\n transaction-privacy,post-quantum,cryptoeconomic-primitives\n\n 30\n\n 6.8k\n\n Mar 20\n\n Curvy Decentralized Proving\n\n Cryptography\n\n transaction-privacy\n\n 0\n\n 222\n\n Mar 11\n\n Anonymous PGC: Practical Anonymous & Confidential Payment for Account-based Blockchains\n\n Cryptography\n\n transaction-privacy\n\n 0\n\n 198\n\n Feb 23\n\n Stealth Address + Sub Accounts for 7702 Account\n\n Applications\n\n account-abstraction,transaction-privacy\n\n 0\n\n 170\n\n Jan 28\n\n Tracing bad funds through shielded pools\n\n Privacy\n\n transaction-privacy\n\n 2\n\n 620\n\n Dec 2025\n\n Implementing Privacy Pools on EBSI for Institutional Programmable Privacy & Compliance\n\n Applications\n\n transaction-privacy,identity,zero-knowledge\n\n 2\n\n 817\n\n Nov 2025\n\n Resolving the Dichotomy: DeFi Compliance under Zero Knowledge\n\n Decentralized exchanges\n\n transaction-privacy,zk-id,cryptoeconomic-tool-set\n\n 1\n\n 843\n\n Jul 2025\n\n A pathway for GDPR Data Management & Privacy for Ethereum\n\n Privacy\n\n zk-roll-up,data-availability,transaction-privacy,pet\n\n 6\n\n 1.1k\n\n Jun 2025\n\n Dangers of Ethereum Privacy (90 % slash)\n\n Privacy\n\n transaction-privacy\n\n 14\n\n 686\n\n May 2025\n\n Empowering Verifiable Data When EOAs Set a Code\n\n Applications\n\n account-abstraction,transaction-privacy,signature-aggregation,zk-id\n\n 0\n\n 375\n\n May 2025\n\n Combining on-chain identifiers and proof system to streamline data processing across modular networks\n\n Layer 2\n\n account-abstraction,transaction-privacy,signature-aggregation,identity,roll-ups\n\n 0\n\n 1.6k\n\n Feb 2025\n\n Bringing privacy to EVM applications using confidential computing via co-processors\n\n Privacy\n\n transaction-privacy\n\n 12\n\n 1.9k\n\n Jan 2025\n\n Advancing Blockchain Transaction Privacy and Compliance: Insights into Innovative Engineering Practices\n\n Privacy\n\n transaction-privacy\n\n 4\n\n 4.4k\n\n Dec 2024\n\n Self-Sovereign Identity and Account Abstraction for Privacy-Preserving cross chain user operations across roll ups\n\n Execution Layer Research\n\n zk-roll-up,account-abstraction,transaction-privacy,signature-aggregation,sequencing\n\n 14\n\n 7.4k\n\n Oct 2024\n\n Enabling standardized on chain executions through modular accounts\n\n Execution Layer Research\n\n stateless,account-abstraction,transaction-privacy,signature-aggregation,zk-id\n\n 4\n\n 3.6k\n\n Aug 2024\n\n FHE-DKSAP: Fully Homomorphic Encryption based Dual Key Stealth Address Protocol\n\n Cryptography\n\n transaction-privacy\n\n 12\n\n 7.7k\n\n Oct 2023\n\n Hybrid Rollup - The Next-Generation Infrastructure\n\n Layer 2\n\n zk-roll-up,transaction-privacy\n\n 0\n\n 1.8k\n\n Jun 2023\n\n S𝛑PETs: Sustainable Practically Indistinguishable Privacy-Enhanced Transactions\n\n Privacy\n\n transaction-privacy\n\n 0\n\n 3.3k\n\n Jan 2023\n\n On the (im)possibility of privacy-preserving quadratic funding\n\n Privacy\n\n transaction-privacy\n\n 2\n\n 2.7k\n\n Aug 2021\n\n ZKAP Webinar - Zero Knowledge Access Passes\n\n zk-s[nt]arks\n\n transaction-privacy\n\n 0\n\n 1.5k\n\n Mar 2020","tokens":1104,"squid":"ink-research","role":"Deep Scholar","at":1791258158340,"hash":"7e905a4cbc118d05f3258de901537bced2cce61c"}
{"url":"https://www.openzeppelin.com/news/if-youre-regulated-under-mica-youre-also-regulated-under-dora","domain":"openzeppelin.com","title":"If You’re Regulated Under MiCA, You’re Also Regulated Under DORA","text":"September 23, 2026OpenZeppelinMarkets in Crypto-Assets Regulation (MiCA) authorization has dominated the compliance conversation for crypto-asset service providers (CASPs) operating in the EU. But authorization is only one part of the picture. Once a firm is licensed as a CASP, it is automatically pulled into a second, separate regulatory regime: the Digital Operational Resilience Act (DORA).DORA has applied to CASPs since January 17, 2025, the same date it applied to banks, insurers, and asset managers across the EU, with no phase-in period left to plan around. MiCA decides whether a firm can offer crypto-asset services. DORA decides whether that firm's technology stack is resilient enough to be trusted with them. Both obligations are live at the same time, and satisfying one does not discharge the other.Why MiCA Authorization Doesn't Cover DORADORA, formally Regulation (EU) 2022/2554, names CASPs authorized under MiCA as financial entities under Article 2(1)(s). That single clause is what pulls the entire DORA rulebook into scope for crypto firms: custody and administration of crypto-assets, operation of a trading platform, exchange services, execution of orders, placement, and portfolio management are all covered activities. Issuers of asset-referenced tokens and e-money tokens fall under DORA separately as financial entities in their own right, on top of the MiCA-specific reserve and operational rules that already apply to them.MiCA itself does impose some operational expectations. Article 68 addresses systems and security access protocols, Article 75 covers custody safekeeping, and there are baseline business continuity obligations throughout. DORA complements these obligations: it's the cross-sectoral standard that deepens and harmonizes the ICT risk side of the business, applying proportionately under Article 4 so a small portfolio-management CASP faces lighter expectations than a large multi-asset exchange. No CASP is exempt from the core requirements around ICT risk management, incident reporting, and third-party oversight, regardless of size.What DORA RequiresFor a CASP, DORA compliance touches several distinct areas of the business:ICT risk management framework. Firms need documented governance over their technology risk, with board-level accountability rather than a policy sitting in a compliance folder.Incident reporting. Major ICT-related incidents must be classified and reported to regulators within defined timelines, which requires infrastructure capable of detecting and escalating issues quickly.Digital operational resilience testing. Larger or more critical firms fall under threat-led penetration testing (TLPT) requirements, which go beyond a standard security audit and simulate real adversarial conditions against production systems.Third-party risk management. DORA requires oversight of critical ICT third-party providers, including cloud infrastructure, custody technology, and, for many CASPs, the smart contracts and libraries their products are built on.That last point is where the overlap with a firm's technical foundation becomes most concrete. A CASP's risk register under DORA needs to account for the security posture of the protocols, smart contracts, and frameworks it relies on, not just its internal systems.Where Security Standards Come InThe most common misconception firms run into is assuming that a completed MiCA authorization file, with its policies, controls, and disclosures, already satisfies DORA. It does not. The two regimes overlap in intent but are evaluated separately, with different evidence expectations and different regulators asking different questions.The practical answer is to build one evidence base that speaks to both regimes at once: a control set for authorization and conduct, and a resilience and risk-management layer that maps directly onto DORA's ICT requirements. Smart contract audits and security audits belong in that evidence base as ongoing proof of the ICT risk management and third-party oversight DORA expects on a continuing basis.This is the environment OpenZeppelin's security audits are built for: 900+ security audits completed since 2016, backing $250 billion in value secured. As financial infrastructure moves onchain, institutional-grade security standards for smart contracts and protocols are becoming a documented, auditable part of a firm's regulatory file. OpenZeppelin is the security standard onchain finance is built on, and that standard increasingly needs to satisfy both crypto-specific rules like MiCA and cross-sectoral frameworks like DORA at the same time.The TakeawayAny firm authorized as a CASP under MiCA is, by definition, a DORA-regulated financial entity. There is no separate compliance runway once that authorization is granted. A firm authorized in 2026 is expected to be operationally resilient from its first day of operating, with the same ICT risk management, incident reporting, and testing obligations scaled to its size and risk profile under applicable regulations and DORA’s proportionality principle. Treating security audits, smart contract audits, and third-party risk assessments as a continuous compliance function, rather than a pre-launch task, is what closes the gap between the two regimes.Ready for the security audit bar regulators expect? Talk to an expertFAQsDoes MiCA authorization automatically mean a CASP is DORA-compliant?No. MiCA and DORA are separate regimes evaluated independently. MiCA authorization covers market access and conduct; DORA governs ICT risk management, incident reporting, and operational resilience testing.Since when has DORA applied to crypto-asset service providers?DORA has applied to CASPs since January 17, 2025, on the same terms as banks and other financial entities.Which CASP activities fall under DORA?Custody and administration of crypto-assets, trading platform operation, exchange services, order execution and transmission, placement, advice, and portfolio management are all covered, per DORA Article 2(1)(s).Are asset-referenced token and e-money token issuers subject to DORA too?Yes. ART and EMT issuers are named as financial entities under DORA separately, in addition to MiCA-specific reserve and operational requirements.What role do security audits play in DORA compliance?Security audits and smart contract audits provide ongoing evidence for the ICT risk management and third-party oversight obligations DORA requires, supporting a firm's risk register and incident-readiness documentation.The opinions, statements, and assessments in this article do not constitute legal, tax, regulatory or any other professional advice. Given the inherent nature of the information in this article, its contents are based on information gathered and understood at the time of its creation. It is subject to change. The information is provided on an “as-is” basis without representation or warranty and accepts no liability for any action or failure to act taken in response to the information contained or referenced in this article.","tokens":1764,"squid":"ink-security_audits","role":"Sentinel","at":1791258163989,"hash":"dd96ad5a876232f4cb80d9671a9c1792b8fd3381"}
{"url":"https://ethresear.ch/t/ethereum-privacy-the-road-to-self-sovereignty/22115","domain":"ethresear.ch","title":"Ethereum Privacy: The Road to Self-Sovereignty - Privacy - Ethereum Research","text":"Ethereum Privacy: The Road to Self-Sovereignty \n\n Privacy\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2025\n\n 1 / 21\n\n Apr 2025\n\n Jun 16\n\n post by pcaversaccio on Apr 9, 2025\n\n pcaversaccio\n\n Ethereum must provide privacy unconditionally, without forcing users to prove their innocence.\nThis roadmap outlines the necessary steps to transform Ethereum into a maximally private and self-sovereign financial system. Privacy must not be an optional feature that users must consciously enable — it must be the default state of the network. Ethereum’s architecture must be designed to ensure that users are private by default, not by exception.\nToday, Ethereum operates in a partial, opt-in privacy model, where users must take deliberate steps to conceal their financial activities — often at the cost of usability, accessibility, and even effectiveness. This paradigm must shift. Privacy-preserving technologies should be deeply integrated at the protocol level, allowing transactions, smart contracts, and network interactions to be inherently confidential. A system that treats privacy as suspicious by default is fundamentally flawed. Ethereum must empower users with unconditional privacy — making self-sovereignty a guarantee, not a privilege.\n\nBuilding a truly privacy-first Ethereum needs all our insights! Please share your feedback, ideas, and any concerns here so we can actively co-create this path forward together.\n\n Confidential Wrapped Ethereum\n\n Dangers of Ethereum Privacy (90 % slash)\n\n Private Multisig v0.1\n\n ZEX v0.1: Confidential Peer-to-Peer DEX\n\n 3\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n post by ameensol on Apr 9, 2025\n\n ameensol\n\nEthereum must provide privacy unconditionally , without forcing users to prove their innocence.\n\nThis roadmap outlines the necessary steps to transform Ethereum into a maximally private and self-sovereign financial system. Privacy must not be an optional feature that users must consciously enable — it must be the default state of the network.\n\nPresumably the proof-of-innocence refers to the first demo implementation of the Privacy Pools paper Vitalik and I wrote, so I’ll chime in here.\nI think privacy by default at the L1 is a bad idea—unless we also build tools that allow (not force) users to dissociate from other users. If we don’t, then we are actually the ones forcing users to provide privacy to other users (including DeFi hackers, terrorists, and in the case of North Korea: both) just to access privacy themselves.\nBeing able to disscociate from other users actually increases my sovereignty, it does not decrease it. Sovereignty is about choice.\nI have had this argument about 100 times since the Privacy Pools paper came out, many times with people who are triggered by the proof-of-innocence meme, and you can see these arguments on Twitter by searching the keyword “dissociation” on my account (ameensol): https://x.com/search?lang=en&q=dissociation%20(from%3Aameensol).\nIt’s also a fallacy to compare anonymous money to encryption (and personally, I wish this wasn’t true but it is). In the case of encryption, I don’t need participation from anyone else to get the benefits of being able to keep secrets. But in the case of anonymous money, if I am the only one using the anon money system, it’s pretty obvious who I am. So value I get from the anon money system is actually socially derived from the participation of other users, and thus the quality of my anonymity set matters, not just the quantity. If I am in the anon set that also includes North Korean hackers, I will have a much harder time getting my funds from the anon money system accepted anywhere else (and rightfully so).\nScreenshot 2025-04-09 at 7.13.37 AM1198×1142 154 KB\nsource: https://x.com/delete_shitcoin/status/1521461832266956803\nBeing able to prove the funds are legit is an important part of helping combat the ability of criminals to launder money through our anon money systems. Tornado Cash & ZCash have view keys, where users can selectively reveal their transactions to an authority if desired. Before they both joined Vitalik and I on the Privacy Pools paper, Fabian Schar and Matthias Nadler wrote the best paper on Tornado Cash that I have seen, in which they 1) argue for the importance of privacy and 2) provide a potential regulatory framework for it: anonymous money system should be legal, but users should still be required to reveal their transaction history to a financial authority in order to legally access them.\nI know it’s difficult, but if you can bring yourself to empathize with a regulator, the problem you face is: how do I tell the good money apart from the bad money? One solution is the above: require all anon money system users to reveal their tx history to a financial authority, and in the backend, create a data-sharing system by which we know the sum of all users that have complied with this requirement, and thus by process of elimination, we know that the rest of the money is (probably) the bad money. However, this still creates a government-owned honeypot of all the tx history which itself can be leaked or abused, and is thus not an ideal solution.\nThe reason Vitalik, Matthias, Fabian and I got together and wrote the Privacy Pools paper is because Vitalik thought of a potentially better way: what if we can prove in public which deposits we are not, allowing users to publicly dissociate from known bad money, and thus create a more useful separating criteria for regulators, and critically, potentially avoiding the need for a centralized honeypot of all the tx history in the first place. If I was a regulator, I would be OK with this solution. Financial institutions, if desired, could still demand the specific tx history from their users, but at least the funds are known to not be from known illicit sources, based on their public dissociation proofs.\nIn conclusion, I encourage any technological development we do on enhancing base layer privacy to proceed in lockstep with tools that allow public dissociation proofs, which would serve to enhance user sovereignty by allowing users to choose for themselves who they are willing to associate with.\n\n post by EmperorOrokuSaki on Apr 9, 2025\n\n post by z0r0z on Apr 9, 2025\n\n post by vbuterin on Apr 10, 2025\n\n post by kladkogex on Apr 11, 2025\n\n post by ml-sudocode on Apr 14, 2025\n\n post by sgrasmann on Apr 14, 2025\n\n post by ivanmmurciaua on Apr 21, 2025\n\n post by pcaversaccio on Apr 21, 2025\n\n post by TimDaub on Apr 23, 2025\n\n post by Caerlower on Apr 30, 2025\n\n post by kladkogex on May 2, 2025\n\n post by ivanmmurciaua on May 5, 2025\n\n post by kladkogex on May 5, 2025\n\n 1 year later\n\n post by chegecjay-rgb on Jun 12\n\n post by giantgun on Jun 15\n\n post by JiangXb-son on Jun 15\n\n post by chegecjay-rgb on Jun 15\n\n post by giantgun on Jun 16\n\n Load more posts below","tokens":1716,"squid":"ink-research","role":"Deep Scholar","at":1791258168606,"hash":"b5f3fb88b58ade7c9029b1591bd2fda7117067e2"}
{"url":"https://www.openzeppelin.com/news/uniswap-token-launcher-audit","domain":"openzeppelin.com","title":"Uniswap Token Launcher Audit","text":"September 29, 2026OpenZeppelin SecuritySummaryType: DeFiTimeline: From 2025-08-26 | To 2025-09-05Languages: SolidityFindingsTotal Issues: 28 (25 resolved)Critical Severity Issues1 (1 resolved)High Severity Issues2 (2 resolved)Medium Severity Issues7 (6 resolved)Low Severity Issues9 (7 resolved)Notes & Additional Information9 (9 resolved)ScopeOpenZeppelin audited the Uniswap/token-launcher repository at commit 9eff2a7.In scope were the following files:src\n├── distributionContracts\n│ ├── LBPStrategyBasic\n│ └── MerkleClaim\n└── distributionStrategies\n│ ├── LBPStrategyBasicFactory\n│ └── MerkleFactory\n└── interaces\n│ └── external\n│ └── IERC20\n│ ├── IDistributionContract\n│ ├── IDistributionStrategy\n│ ├── ILBPStrategyBasic\n│ ├── IMerkleClaim\n│ ├── IMultiCall\n│ ├── IPermit2Forwarder\n│ └── ITokenLauncher\n└── libraries\n│ └── TickCalculations\n└── types\n│ ├── Distribution\n│ └── MigratorParams\n└── utils\n│ └── HookBasic\n├── Multicall\n├── Permit2Forwarder\n└── TokenLauncherSystem OverviewThe Token Launcher is a token-distribution and liquidity-bootstrapping system built on Uniswap V4 that orchestrates token distribution through configurable strategies. It aims to provide fair token distribution and immediate liquidity by combining price discovery with automated liquidity deployment. Whether a team creates a new token via an external factory or uses an existing token, the launcher supports the complete distribution and liquidity workflow.TokenLauncherThe TokenLauncher contract coordinates a launch end to end. Teams may first create a token via an external factory (optional) or use an existing token. A launch starts by calling distributeToken() with a strategy configuration. The launcher then:deploys the selected strategy via its factorytransfers the configured token amount to that strategylets the strategy run its processThis keeps the launcher simple and consistent while allowing each strategy to implement its own logic behind a shared interface.Distribution StrategiesLBPStrategyBasic - Price Discovery and Liquidity Bootstrapping: This strategy splits the token supply into two parts: one part participates in an external TWAP auction to discover a fair market price, and the other part is reserved to provide liquidity on Uniswap V4 after the auction. At least 50% of the tokens are reserved for liquidity (so up to 50% can be auctioned). LBPStrategyBasic is implemented as a Uniswap V4 hook that prevents pool initialization until the auction results are validated. When the auction completes, it calls the strategy’s validate() function, which reads the clearing price and currency raised, checks them against Uniswap V4 constraints, and stores them for migration. After a short, configured block delay, anyone can call migrate() to initialize a Uniswap V4 pool at the discovered price which deploys both full-range and potentially additional one-sided liquidity positions by utilizing the currency raised and the tokens that are reserved in the contract.MerkleClaim - Claim Based Distribution: MerkleClaim publishes a Merkle root on-chain and lets recipients claim allocations by providing Merkle proofs. It scales to large recipient sets and fits to airdrops or predetermined distributions where price discovery is not required.Extensibility: The distribution layer is designed to be pluggable. New strategies can be added without modifying the launcher by implementing the shared interfaces and, where needed, supplying a factory for deterministic deployment. Projects can use a single strategy or combine multiple strategies for the same token.Supporting ComponentsThe system relies on a small set of helper contracts and integrations. Strategy factories deploy strategy instances, Permit2Forwarder handles permit-based approvals and transfers, and Multicall allows batching when needed. Uniswap V4 integration is built into the primary path: LBPStrategyBasic itself is the Uniswap V4 hook that gates pool initialization and enforces validated auction parameters, preventing premature or malicious pool creation.Pool deployment and liquidity positions rely on Uniswap V4 core/periphery. The external TWAP auction supplies the clearing price and raised currency used during migration. Optionally, teams can use external token factory contracts when creating a new token before distribution. Otherwise, existing tokens flow through the same launcher interface.Security Model and Trust AssumptionsDuring the review, the following trust assumptions were made:The Auction contract will never reach an irretrievable state.The Auction contract's interface will not change.The Auction contract will always call the validate function if an auction is successful.The Auction contract works as intended.The positionRecipient of the liquidity position created after pool initialization will not rug.The token creator will not rug after pool creation.The out-of-scope dependencies work as intended.Recommendations on Integration and Invariant TestingThis codebase has multiple integrations but lacks a strong integration and invariants test suite. The review uncovered numerous issues in interactions with the out-of-scope Auction contracts. Since both codebases are under active development, a robust test suite is essential to prevent edge-case fund loss or denial-of-service bugs once deployed on-chain. Additionally, several basic happy and unhappy paths were found to be broken, further underscoring the need for comprehensive testing.Privileged RolesThroughout the in-scope codebase, the following privileged roles/actions were identified:The MerkleClaim contract has an owner that can call the sweep and withdraw functions to take out the remaining tokens after the claim duration has ended.The validate function of the LBPStrategyBasic contract can only be called by the Auction contract.Critical SeverityreserveSupply Gets Stuck in LBPStrategyBasic if Auction Does Not GraduateWhen distributeToken is called on the TokenLauncher contract, it calls LBPStrategyBasicFactory to deploy the LBPStrategyBasic contract, sends tokens to the deployed contract, and calls onTokensReceived on it which deploys the Auction contract. The auction then takes place according to the parameters supplied to it during construction.If the auction sales cross a certain threshold of the total available tokens, then the auction is considered graduated. After the auction is over, if it was successful (it graduated), bidders can claim the tokens that they bid for and anyone can transfer the raised funds to the fundsRecipient. The sweepCurrency function transfers the funds to the fundsRecipient and calls it if the fundsRecipientData is not empty and fundsRecipient has code. If the auction does not graduate, then the raised currency is refunded to the bidders and the total unsold supply of tokens on auction can be transferred to the tokensRecipient.The LBPStrategyBasic requires the fundsRecipient to be itself and fundsRecipientData to be the function selector of the validate function to work correctly. This way, when the auction graduates, the validate function will be called and the raised funds will be transferred to it, so that a new pool can be created. However, if the auction does not graduate, then the validate function will not be called. This would result in the reserveSupply, which was reserved for pool creation, to get stuck as there is no way to get it out.Consider adding a withdrawal function to get the reserveSupply out if the auction does not graduate.Update: Resolved in pull request #51 by adding a sweepToken and sweepCurrency function that an operator address can call at and after sweepBlock to recover funds. Its important to be noted that the sweepBlock can be immediately after the migrationBlock allowing the operator to sweep all funds before someone can call the migrate function.High SeverityInsufficient Input Validation During Contract Creation Can Break Normal Usage FlowWithout a successful validate function execution, migration to pool cannot occur, and the validate function can only be called by the Auction contract. It is expected to be invoked through the sweepCurrency function of the Auction contract after the auction is graduated. When sweepCurrency is called, accumulated currency in Auction will be transferred to fundsRecipient. fundsRecipient address will then be called with fundsRecipientData if it was provided during the auction deployment.After this step, sweepUnsoldTokens from Auction contract should be called, which transfers the unsold tokens in Auction to tokensRecipient. According to the expected workflow, fundsRecipient should correspond to the LBPStrategyBasic contract, and fundsRecipientData should be a call to the validate function, while tokensRecipient should be the distribution owner who provided the tokens to the auction.However, the fundsRecipient, fundsRecipientData, and tokensRecipient parameters are all user-supplied, and there is no validation of their values. Due to this lack of checks, if an address other than the LBPStrategyBasic is provided as the fundsRecipient along with an empty fundsRecipientData, all accumulated currency will be transferred to this address, the migration would not be possible and the reserveSupply would get stuck. In addition, a normal user might provide tokensRecipient as the LBPStrategyBasic address to be consistent with other variables. Since the LBPStrategyBasic contract does not have a way to handle these tokens, this would lead to tokens being locked in the contract.Consider hardcoding fundsRecipient to the LBPStrategyBasic address and fundsRecipientData to the validate function selector during auction creation. Moreover, consider preventing tokensRecipient from being set to the LBPStrategyBasic contract.Update: Resolved in pull request #49. The team stated:Fixed by validating that the fundsRecipient in AuctionParameters data is set to the LBPStrategy.Signature Mismatch between Interface and Function ImplementationNOTE: This issue was found in pull request #5 at commit 243bad9 which included the MerkleClaim, MerkleFactory, and IMerkleClaim files. This pull request was initially part of the review scope. After this issue was reported and fixed, the pull request was merged, the frozen commit was changed to 9eff2a7, and the review was continued with the combined scope.The MerkleClaimFactory contract inherits from IDistributionStrategy. However, one of the inherited functions has a signature mismatch, which prevents the contract from being deployed.The function with the mismatch is initializeDistribution. The mismatch specifically arises due to the following reasons:The function is missing the bytes32 salt parameter as the last parameter.The second parameter in the interface is uint128 totalSupply, whereas in MerkleClaimFactory, it is uint256 amount.These differences result in both a parameter-count mismatch and a parameter-type mismatch, causing the function signature to diverge.Consider adding the missing bytes32 salt parameter and aligning the second parameter's type with the interface.Update: Resolved in pull request #5. The team stated:Fixed, once we fixed foundry remapping issues and were able to test.Medium SeverityOverflow Possibility In the validate FunctionThe validate function of the LBPStrategyBasic contract fetches clearingPrice from the Auction contract. clearingPrice is the ratio of currency/token and is used for calculating the amount of both assets to be provided to the liquidity pool during its creation.clearingPrice is computed and stored as a uint256 value in the Auction contract and is returned as such. If the clearingPrice returned is greater than type(uint160).max, it will cause a silent overflow on this line in the validate function. This will cause the price to become a very small value which can either cause the pool creation to fail or, if it succeeds, result in the pool being initialized with the wrong price.Consider adding a check to ensure that the price does not exceed type(uint160).max and handling it in the same manner as the other validation checks recommended for the validate function.Update: Resolved in pull request #48.Lack of Access Control in distributeTokenInitial supply of the token is minted to the recipient address provided as a parameter to createToken function. Hence, the caller of this function can choose to mint the tokens to any arbitrary address. The distributeToken function allows for choosing between two paths that can be used to extract the token using the payerIsUser parameter: it can be sent from msg.sender, or tokens from TokenLauncher can be utilized directly. However, if the tokens are minted to TokenLauncher, it is possible for any user to call distributeToken with an arbitrary distribution parameter because there is no access control in the distributeToken function.Consider implementing access control for the distributeToken function. The token's graffiti can be utilized for such a restriction.Update: Acknowledged, not resolved in pull request #52. The team stated:This is by design - documented that create and distribute should only be called in a multicall with payerIsUser as false.sweep Function Not UsableThe sweep function of the MerkleClaim contract is designed to transfer any remaining tokens from the distribution to the owner after endTime. According to the documentation, this function should only be callable by the owner.While sweep can be called by anyone, it executes this.withdraw() within its function body which is an external call to withdraw function from parent contract MerkleDistributorWithDeadline. However, MerkleDistributorWithDeadline has an onlyOwner modifier for withdraw, so it is only callable by the owner address. Since the call is made via this.withdraw(), the caller is set to address(this), which prevents the owner from being able to call sweep().The only possible workaround would be to set the owner as address(this). However, this approach contradicts the expected role of the owner and allows anyone to call sweep() successfully. While the parent contract's withdraw function remains available and can still be called directly by the owner (as it is not overridden), the sweep function itself does not behave as intended and is effectively unusable.Consider performing a delegatecall to address(this) within sweep.Update: Resolved in pull request #21 by removing the sweep function completely.Lack of Hashing in MerkleFactory Can Lead to Front-Running of the InitializationThe distributeToken function of the TokenLauncher contract hashes msg.sender with the provided salt parameter to derive the final salt used in initializeDistribution within MerkleFactory. However, a malicious user can front-run this call by directly invoking initializeDistribution from MerkleFactory with the same salt and parameters. This would deploy a MerkleClaim contract at the same address, causing the subsequent distributeToken call to revert.Consider hashing the salt received from TokenLauncher once more inside initializeDistribution combined with msg.sender.Update: Resolved in pull request #26.validate Function Reverting Will Lead to Loss of FundsWhen an auction graduates, anyone can transfer the raised funds to the fundsRecipient of the auction by calling the sweepCurrency function in Auction.sol. For the pool creation to work, the fundsRecipient needs to be the LBPStrategyBasic contract, and the fundsRecipientData needs to be the function selector of the validate function.If this call to the validate function fails, then the sweepCurrency function will also revert. This would lead to two problems: the funds raised in the auction will get stuck in the Auction contract, unable to be retrieved, and the reserveSupply will get stuck in the LBPStrategyBasic contract as a liquidity pool could not be created.The mitigation of this issue is not straightforward and would possibly require changes in both the LBPStrategyBasic and the Auction contracts. One recommendation is presented below:Change the function signature of the validate function to return a boolean. While doing checks inside the function, if a condition fails, instead of reverting, just store a flag to ensure that the pool cannot be created and return false. Send the currency back to the Auction.Make a withdrawal function inside LBPStrategyBasic where all the reserve tokens can be withdrawn if the validate function has failed.Refund the users on the Auction side.Consider implementing a mitigation that would prevent funds from getting stuck as a result of the validate function reverting.Update: Resolved in pull request #42. The team stated:Fixed by removing the validate function.Rebasing Tokens and Fee-on-Transfer Tokens Are Not Compatible with TokenLauncherThe TokenLauncher contract has been designed to work with any ERC-20 token. However, using fee-on-transfer or rebasing tokens can exhibit unexpected behavior and may result in locked funds. Fee-on-transfer tokens will likely fail during strategy initialization because of the onTokensReceived check implemented in strategies. The amount sent from the TokenLauncher contract will not match the amount received by the strategy. Since onTokensReceived is called in distributeToken(), the token distribution will revert.Rebasing tokens can pass the initialization but may break later stages:In LBPStrategyBasic, reserveSupply holds the portion of tokens reserved for liquidity. During migration, this amount is sent to the positionManager. If rebasing reduces the contract’s balance below reserveSupply, the migrate() call will fail, preventing pool creation and locking both the tokens and the currency in the strategy.In MerkleClaim, allocations are fixed at deployment. If rebasing reduces the overall supply, there may not be enough tokens left for later claimants, leading to failed claims.Consider disallowing fee-on-transfer and rebasing tokens, and clearly documenting the aforementioned risks for users.Update: Resolved in pull request #52. The team stated:Documented that rebasing and fee on transfer tokens are not compatible.Tokens Lost to the PositionManager in _createOneSidedPositionPlanThe LBPStrategyBasic contract creates a single-sided position if excess token assets will be left in it after the creation of the full-range liquidity position. The calculation of the specifics of the single-sided position happens in the _createOneSidedPositionPlan function. The creation of a single-sided position is skipped in two cases:The maximum liquidity allowed per tick limit is exceeded (1, 2)The initial tick is too close to the upper or lower boundary (1, 2)In both the cases, tokens that should have been used for the one-sided position remain in the PositionManager since all tokens have already been sent to it. After migration, anyone can extract these leftover tokens from the PositionManager contract by performing SETTLE and TAKE actions through Uniswap.Some ways to address this issue are presented below:Only send the required tokens to the PositionManager contract. If the one-sided position is not created, the unused tokens will remain in the strategy contract. Pair this with a withdrawal function, callable only by the distribution owner, to recover the unused tokens after pool creation.If all tokens are transferred to the PositionManager contract at the start of migrate(), adjust the Uniswap V4 actions such that if a one-sided position was expected but not created, the sequence includes SETTLE and TAKE for the relevant token in the end in favor of the distribution owner.Consider implementing one of the approaches outlined above to prevent token loss.Update: Resolved in pull request #43.Low SeverityIrrecoverable ETHIn the Permit2Forwarder and Multicall contracts, it is impossible to withdraw ETH, and the funds sent to them would be irrecoverable.Consider removing the payable keyword from the permit and multicall functions of the Permit2Forwarder and Multicall contracts, respectively.Update: Resolved in pull request #39.Missing Zero-Address ChecksWhen operations with address parameters are performed, it is crucial to ensure the address is not mistakenly set to zero.Throughout the codebase, multiple instances of missing zero-address checks were identified:The recipient operation within the TokenLauncher contract in TokenLauncher.solThe _token operation within the LBPStrategyBasic contract in LBPStrategyBasic.solThe token operation within the MerkleClaimFactory contract in MerkleFactory.solConsider always performing a zero-address check before assigning any state variable.Update: Resolved in pull request #40.getLBPAddress Function is Missing ParameterThe initializeDistribution function in LBPStrategyBasicFactory.sol derives the final CREATE2 salt as keccak256(abi.encode(msg.sender, salt)), but getLBPAddress uses the raw salt directly. This inconsistency means that getLBPAddress will return an incorrect address unless the caller manually pre-hashes the sender with the salt off-chain. This is error-prone and contradicts the on-chain derivation logic.Consider taking the sender as an input parameter to create the final CREATE2 hash.Update: Resolved in pull request #27.Missing view function for Deterministic Address Pre-Computation in MerkleClaimFactoryThe MerkleClaimFactory deploys MerkleClaim instances using CREATE2 but does not expose a view function to pre-compute the resulting address with the same constructor arguments and salt used at deployment. Without this helper, integrators must reimplement the CREATE2 address derivation off-chain, increasing the risk of incorrect calculations and operational mistakes.Consider adding a view function in MerkleClaimFactory similar to getLBPAddress in LBPStrategyBasicFactory that returns the pre-computed deterministic address.Update: Resolved in pull request #41.Missing onTokensReceived Implementation in MerkleClaimWhen distributeToken is called from TokenLauncher.sol, tokens are transferred to the strategy contract and the strategy contract's onTokensReceived function is called. This function checks if the expected amount of token is received by the strategy in LBPStrategyBasic.sol. However, this function is empty in MerkleClaim.sol.Consider implementing the same check in MerkleClaim.sol.Update: Acknowledged, not resolved.Dust Is Foregone Instead of Being SweptDuring pool creation, any extra tokens that are not used for seeding the pool are completely foregone (1, 2, 3) whereas they can instead be returned to the positionRecipient. While returning the tokens may incur more gas cost than the worth of the tokens, this conservative approach will shield in cases where the amount of dust tokens left after pool seeding is not insignificant.Consider changing the approach and sweeping the dust to the positionRecipient.Update: Acknowledged, not resolved in pull request #52. The team stated:this is by design to save on gas since dust will be very minimal - made it clear in documentationExtra Tokens Sent to LBPStrategyBasic Upon Initialization Get StuckThe LBPStrategyBasic contract is deployed with a totalSupply variable at construction time, but the funds are transferred to it in a later call. onTokensReceived is called after transferring funds to the contract, and it validates that the received funds are greater than or equal to totalSupply.If extra tokens are sent to the LBPStrategyBasic contract, then the check will still pass, but the extra funds will not be used and will eventually get stuck. Consider adding a withdrawal function to the contract that allows the creator to retrieve any leftover funds after a successful pool migration.Update: Resolved in pull request #51. The team stated:fixed by allowing an operator address to withdraw tokens after a certain time periodonTokensReceived Called Out of Preferred Execution Flow Can Lead to Loss of FundsThe distributeToken function deploys the LBPStrategyBasic contract, transfers funds to it, and calls its onTokensReceived function to trigger the deployment of the Auction contract. If the deployment of the Auction contract fails, then the entire execution chain reverts, including the fund transfer. However, the LBPStrategyBasic contract can be deployed directly without going through the TokenLauncher by calling initializeDistribution on the LBPStrategyBasicFactory contract.If deployed this way, the onTokensReceived function may not necessarily be called in the same transaction as the funds transfer. This can lead to funds being stuck in the contract as the onTokensReceived function can revert due to failed deployment of the Auction contract, and there is no way to get out the funds transferred in the previous transaction.Consider either using a pull method for the fund transfer or documenting this risk in the contract.Update: Resolved in pull request #51. The team stated:if tokens get stuck, an operator address can withdraw by calling the sweepTokens functiontotalSupply Type Mismatch Can Invalidate Deterministic Address ComputationinitializeDistribution passes totalSupply to the LBPStrategyBasic constructor as a uint128, while getLBPAddress encodes the same argument as a uint256. If a caller provides a value that exceeds 2**128 − 1, the helper will still encode the full 256-bit number when computing the initCodeHash, whereas the deployment path will revert (or, if ever truncated elsewhere, encode only the lower 128 bits). Either outcome makes the address predicted by getLBPAddress diverge from the one that would actually be deployed, defeating the purpose of deterministic address prediction and potentially breaking the integrations that rely on it.Consider changing uint256 to uint128 for totalSupply in the getLBPAddress function signature.Update: Resolved in pull request #47.Notes & Additional InformationLack of Indexed Event ParameterWithin IDistributionStrategy.sol, the DistributionInitialized event does not have indexed parameters.To improve the ability of off-chain services to search and filter for specific events, consider indexing event parameters.Update: Resolved in pull request #31.File and Contract Names MismatchThe MerkleFactory.sol file name does not match the MerkleClaimFactory contract name.To make the codebase easier to understand for developers and reviewers, consider renaming the files to match the contract names.Update: Resolved in pull request #30.Missing DocstringsThroughout the codebase, multiple instances of missing docstrings were identified:In LBPStrategyBasic.sol, the MAX_TOKEN_SPLIT_TO_AUCTION state variableIn LBPStrategyBasic.sol, the Q192 state variableIn LBPStrategyBasic.sol, the token state variableIn LBPStrategyBasic.sol, the currency state variableIn LBPStrategyBasic.sol, the poolLPFee state variableIn LBPStrategyBasic.sol, the poolTickSpacing state variableIn LBPStrategyBasic.sol, the totalSupply state variableIn LBPStrategyBasic.sol, the reserveSupply state variableIn LBPStrategyBasic.sol, the positionRecipient state variableIn LBPStrategyBasic.sol, the migrationBlock state variableIn LBPStrategyBasic.sol, the auctionFactory state variableIn LBPStrategyBasic.sol, the positionManager state variableIn LBPStrategyBasic.sol, the auction state variableIn LBPStrategyBasic.sol, the initialSqrtPriceX96 state variableIn LBPStrategyBasic.sol, the initialTokenAmount state variableIn LBPStrategyBasic.sol, the initialCurrencyAmount state variableIn LBPStrategyBasic.sol, the auctionParameters state variableIn LBPStrategyBasic.sol, the receive functionIn LBPStrategyBasicFactory.sol, the positionManager state variableIn LBPStrategyBasicFactory.sol, the poolManager state variableIn LBPStrategyBasicFactory.sol, the getLBPAddress functionIn MerkleFactory.sol, the MerkleClaimFactory contractIn IMerkleClaim.sol, the IMerkleClaim interfaceIn IERC20.sol, the balanceOf functionConsider thoroughly documenting all functions (and their parameters) that are part of any contract's public API. Functions implementing sensitive functionality, even if not public, should be clearly documented as well. When writing docstrings, consider following the Ethereum Natural Specification Format (NatSpec).Update: Resolved in pull request #38.Incomplete DocstringsThroughout the codebase, multiple instances of incomplete docstrings were identified:In IDistributionStrategy.sol, in the DistributionInitialized event, the distributionContract, token, and totalSupply parameters are not documented.In IDistributionStrategy.sol, in the initializeDistribution function, the token, totalSupply, and salt parameters are not documented.In ILBPStrategyBasic.sol, in the Migrated event, the key and initialSqrtPriceX96 parameters are not documented.In ITokenLauncher.sol, in the createToken function, the recipient parameter is not documented.Consider thoroughly documenting all functions/events (and their parameters or return values) that are part of a contract's public API. When writing docstrings, consider following the Ethereum Natural Specification Format (NatSpec).Update: Resolved in pull request #32.Multiple Optimizable State ReadsIn LBPStrategyBasic.sol, multiple instances of optimizable storage reads were identified:The auction storage reads (1, 2) in onTokensReceived in LBPStrategyBasic.solThe auction storage reads (1, 2, 3, 4) in validate in LBPStrategyBasic.solThe initialSqrtPriceX96 storage reads (1, 2, 3, 4, 5) in migrate in LBPStrategyBasic.solConsider reducing SLOAD operations that consume unnecessary amounts of gas by caching the values in a memory variable.Update: Resolved in pull request #33.Missing Security ContactProviding a specific security contact (such as an email address or ENS name) within a smart contract significantly simplifies the process for individuals to communicate if they identify a vulnerability in the code. This practice is quite beneficial as it permits the code owners to dictate the communication channel for vulnerability disclosure, eliminating the risk of miscommunication or failure to report due to a lack of knowledge on how to do so. In addition, if the contract incorporates third-party libraries and a bug surfaces in those, it becomes easier for their maintainers to contact the appropriate person about the problem and provide mitigation instructions.Throughout the codebase, multiple instances of contracts not having a security contact were identified:The TokenLauncher contractThe LBPStrategyBasic contractThe MerkleClaim contractThe LBPStrategyBasicFactory contractThe MerkleClaimFactory contractConsider adding a NatSpec comment containing a security contact above each contract definition. Using the @custom:security-contact convention is recommended as it has been adopted by the OpenZeppelin Wizard and the ethereum-lists.Update: Resolved in pull request #34.Functions Updating State Without Event EmissionsThroughout the codebase, multiple instances of functions updating the state without an event emission were identified:The onTokensReceived function in LBPStrategyBasic.solThe validate function in LBPStrategyBasic.solThe validate function in LBPStrategyBasic.solThe validate function in LBPStrategyBasic.solConsider emitting events whenever there are state changes to improve the clarity of the codebase and make it less error-prone.Update: Resolved in pull request #35.Unused ImportThe IDistributionStrategy import in LBPStrategyBasic.sol is unused and can be removed.Consider removing unused imports to improve the overall clarity and readability of the codebase.Update: Resolved in pull request #36. The team stated:Fixed (also rearranged ordering of imports).Misleading CommentsThroughout the codebase, multiple instances of misleading or imprecise comments were identified:Line 139 of LBPStrategyBasic.sol reads will revert if cannot fit in uint128, which is incorrect: the typecasting operation will not revert if the value is bigger than uint128.Line 31 of TokenLauncher.sol reads Create token, with this contract as the recipient of the initial supply, whereas, any address passed by the user can be the recipient.Consider addressing the aforementioned instances of misleading comments.Update: Resolved in pull request #37.ConclusionThe Token Launcher system has been designed to create and launch tokens with various pluggable strategies. The Merkle distribution and liquidity bootstrap pool (LBP) strategies were part of the review. However, the LBP strategy relies on an auction system that was not in scope. Multiple critical-, high-, and medium-severity issues were identified concerning integrations with the auction contracts and Uniswap v4. In addition, low-severity issues and code-improvement recommendations were also reported.The codebase would heavily benefit from a comprehensive integration and invariant testing suite to verify that nothing breaks due to a valid state change in one of the integrations. This would prevent edge-case issues from sneaking into the on-chain deployment.The Uniswap Labs team is appreciated for being very helpful during the course of the review and for timely responding to all the questions posed by the audit team.Ready to secure your code? Request an Audit","tokens":8272,"squid":"ink-security_audits","role":"Sentinel","at":1791258174937,"hash":"fb0df933a2cc4b378beb3d16ee2bcad1be94581c"}
{"url":"https://io.net/docs/guides/intelligence/unified-chat","domain":"io.net","title":"Chat - io.net","text":"Chat lets you interact with IO Intelligence’s open-source language models directly from the io.net Dashboard. You can ask questions, get explanations, draft content, and — when you need fresh information — enable web search so the model can incorporate live results into its answers.\n​How it works\nWhen web search is enabled, the model issues queries to the web in real time and uses the retrieved snippets as additional context for its response. When web search is disabled, the model answers from its pretrained knowledge alone.\n​Getting Started\nTo begin using Chat:\n\nGo to your io.net Dashboard.\n\nNavigate to Chat within IO Intelligence.\n\nType your question or command in the chat box and start chatting.\n\n​Key Features\n\nChat with the model\n\nType your question or command in the chat box at the bottom of the page.\n\nUse the microphone icon to record voice input (if preferred).\n\nEach interaction consumes tokens.\n\nEnable web search\n\nToggle web search on to let the model fetch live results from the web before answering.\n\nThis is useful when you need current information that may not be in the model’s training data.\n\n​Communicating with Chat\n​How to Ask Questions\n\nEnter your question or prompt in the chat field.\nThe model will generate a response, optionally enriched with web search results when that option is enabled.\n\n​What Each Response Includes\n\nClear, concise answer — directly addressing your query.\n\nReasoning breakdown — explaining how the model reached the conclusion.\n\nTools or agents used — showing any additional AI functions applied.\n\nWeb sources — when web search is enabled, links to the pages used to inform the response.\n\n​Example Use Cases\n\nGeneral Q&A and brainstorming\nCode explanations and snippets\nQuick lookups with up-to-date web context\nDrafting emails, summaries, and outlines\n\n​IO Credits and Token Management\nEach chat interaction consumes tokens, which are automatically refreshed daily. If you reach the daily token limit of your plan and need additional usage, you can purchase IO Credits to continue without interruption:\nWhen your daily quota limit is reached, the system will automatically switch to consuming your available IO Credits for continued usage — this applies across all subscription tiers.\n\nClick Buy IO Credits or Upgrade to Professional to continue when you run out of Daily Credits.\nComplete your purchase to gain access to:\n\nUnlimited responses and storage — continue conversations without restrictions.\nAdvanced AI insights and automation — unlock enhanced features and capabilities.\nDedicated account management — receive personalized support when needed.\n\nWas this page helpful?","tokens":660,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258177293,"hash":"9a4a8cb8db7bfafb22ed1a2fe9490157da182da9"}
{"url":"https://ethresear.ch/t/zex-v0-1-confidential-peer-to-peer-dex/22949","domain":"ethresear.ch","title":"ZEX v0.1: Confidential Peer-to-Peer DEX - Privacy - Ethereum Research","text":"ZEX v0.1: Confidential Peer-to-Peer DEX \n\n Privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 1 / 2\n\n Aug 2025\n\n Aug 2025\n\n post by Arvolear on Aug 21, 2025\n\n Arvolear\n\n Unlocking privacy-perserving DeFi. No protocol-level modifications, no co-processors needed for ZEX to operate. Although very heavy on the UX side (and gas-wise), this is an early PoC draft. Any feedback would be invaluable!\nThe ZEX protocol is built on top of the cWETH confidential token model. Please do check it out first before proceeding.\n\n1. Introduction\nEthereum’s transparency, while being one of its most valuable advantages, has become a barrier to real-world financial adoption. Public blockchains expose balances, approvals, counterparties, and even token acquisitions by default.\nThe proposal introduces ZEX, a mechanism for permissionless and confidential peer-to-peer Decentralized Exchange (DEX) using cWETH as a model for confidential tokens. It extends the token functionality with confidential allowances, enabling hidden peer-to-peer interactions. Similar to the cWETH protocol, ZEX logic utilizes Elliptic Curve (EC) Twisted ElGamal-based commitment scheme to ensure confidentiality, EC Diffie-Hellman (DH) to introduce value accessibility, and zk-SNARKs to verify the correctness of balance updates during token approvals and transfers without revealing the actual amounts exchanged.\nThe ZEX protocol serves as a marketplace for swap offers where exchanges happen in a three-step interactive fashion and require multiple ZK proofs to be verified within the same transaction. The only piece of information disclosed by ZEX is the price and initial offer allowance, indicating the maximum amount of tokens available for the particular exchange.\nModifications of the protocol may also conceal the swap price to increase privacy assumptions.\n2. Confidential Token Allowance Model\nIn order to perform a confidential peer-to-peer swap, the approve and transferFrom flows must be defined over the confidential token.\nThese flows will be managed by the six new functions in total:\n\nconfidentialApprove to approve tokens to an EOA with existing encryption keys without disclosing the approved amount.\nconfidentialTransferFrom to confidentially transfer approved tokens without disclosing the transferred amount.\npublicConfidentialApprove to one-time approve tokens to a smart contract, disclosing the approved amount.\npublicConfidentialTransferFrom to transfer publicly approved tokens without disclosing the transferred amount.\ncancelConfidentialApprove to cancel the confidential approval without disclosing the canceled amount.\ncancelPublicConfidentialApprove to cancel the public approval, disclosing the canceled amount.\n\nFor the in-depth specification of the cryptography used by these functions, please refer to the original cWETH paper.\n2.1. Confidential approve & transferFrom\nContrary to the regular ERC-20 approval logic, confidential approve results in a decrease in the approver’s balance. This is because during the confidential transferFrom process, the spender cannot verify if the approver has sufficient balance, as it is encrypted.\nAdditionally, the confidential approve operation requires the operator address to be provided, which is supplementary to the usual ERC-20 spender’s address and allowance amount. If the operator address is specified, then the spender cannot call confidentialTransferFrom to receive tokens; only the operator is eligible to do so. This constraint is crucial for the confidential transferFrom security and customization, as it enables the approver to specify a smart contract as an operator to enforce additional transfer validation.\nThe confidential approve to the EOA flow is depicted in the following diagram:\nFigure 1: Confidential approve flow1142×758 160 KB\nOnce the allowance has been granted, the spender is able to receive approved tokens. The diagram below illustrates the confidential transferFrom process:\nFigure 2: Confidential transferFrom flow1920×1405 176 KB\nIt is crucial to understand that the confidential approve and transferFrom operate on five different encrypted amounts:\n\nApprover’s self-ECDH key to represent their new balance after the allowance is granted.\nApprover’s ElGamal allowance commitment for them to be able to access the allowance amount in case of approval cancellation. This commitment is also subtracted from the approver’s balance commitment to represent the new balance after allowance is granted.\nAllowance amount encrypted with the approver/spender ECDH shared key for the allowance amount availability.\nSpender’s ElGamal allowance commitment that is added to their pending balance upon allowance spending.\nThe received token amount encrypted with a self-ECDH key for the new spender balance availability after the allowance is spent.\n\n2.2. Public confidential approve & transferFrom\nIn some scenarios, it is needed to approve tokens not to an EOA with encryption keys, but directly to a smart contract. Since smart contracts don’t hold a confidential private key, they cannot decrypt the confidential allowance values. Moreover, in this case, the approver does not know the receiver beforehand and cannot encrypt the value for the specific public key. As a result, any confidential allowance intended for a smart contract must disclose the approved amount publicly.\nThe diagram below depicts the public confidential approve flow:\nFigure 3: Public confidential approve flow3099×1750 379 KB\nBecause the approved amount is specified in plaintext, a public confidential allowance must be spent entirely and in an atomic fashion, making it a one-time approval. In other words, if the public allowance is not being spent fully, the privacy assumptions require the remaining value to be re-encrypted with the approver’s public key and added back to the approver’s pending balance in the same transaction. This is caused by the fact that the public update of the allowance value will result in compromising the confidentiality of the amounts being transferred.\nThe flow of spending the public confidential allowance is depicted in the following diagram:\nFigure 4: Public confidential transferFrom flow1920×681 118 KB\nThe significant difference with the regular confidential transferFrom is that the allowance leftover gets encrypted and added back to the approver’s pending balance, instead of residing in the dedicated allowance storage.\n2.3. Allowance cancellation\nThe protocol also includes a mechanism for an approver to cancel a confidential allowance, whether it was granted as an encrypted allowance to an EOA or a public allowance to a contract.\nThe confidential allowance cancellation flow is shown in the diagram below:\nFigure 5: Allowance cancellation flow1920×563 100 KB\nThe confidential allowance cancellation flow is rather straightforward since all the encrypted amounts are being maintained in the confidential approve and transferFrom operations. All that is required is to merely add them back to the approver’s pending balance.\nHowever, the public cancellation additionally requires a ZK proof for the verification of the encryption of the allowance leftover.\n3. ZEX Protocol Overview\n3.1. Prerequisites\nFor the DEX to operate correctly, several conditions must be met to keep the swap process smooth and consistent:\n\nAll participating parties must have their confidential public keys published. These keys are used for both EC ElGamal commitments and ECDH encryption, following the scheme used in the underlying confidential tokens.\nThe offer initiator must hold enough confidential tokens in the sell asset to cover the maximum amount they intend to make available in the offer.\nThe offer acceptor must hold enough confidential tokens in the buy asset to pay the agreed amount according to the specified rate.\nThe offer acceptor must have access to the offer details before preparing their part of the swap. Specifically, the offer initiator must publicly publish the exchange rate and the maximum available amount of the asset to sell.\n\n3.2. Peer-to-peer swap flow\nThe following section describes the execution flow of the confidential peer-to-peer swap powered by the confidential allowance model previously defined. The exchange process is interactive and consists of three stages: offer placement, offer acceptance, and swap finalization.\nThe full swap flow is depicted in the diagram below:\nFigure 6: Confidential swap flow4724×3600 435 KB\n3.2.1. Offer placement\nThe swap initiator defines and publishes the offer configuration publicly: the exchange rate r𝑟 (assetBuy per assetSell) and the maximum amount M𝑀 of assetSell available for exchange.\nThe availability of the sell token for the swap is guaranteed through the approval of M𝑀 tokens to the designated ZEX contract by invoking the publicConfidentialApprove function.\n3.2.2. Offer acceptance\nBefore accepting the offer, the counterparty must first verify that the public allowance for the specific offer exists and that the offer has not already been accepted.\nThe acceptor then chooses the amount b𝑏 (b \\le M)(𝑏 ≤𝑀) of assetSell to receive during the swap and computes the corresponding amount of assetBuy a𝑎 to pay to the offer initiator according to the agreed rate r𝑟, taking a=br𝑎 =𝑏𝑟.\nAfter that, the acceptor must approve a𝑎 assetBuy tokens via confidentialApprove, specifying the ZEX contract as an operator and the offer initiator as a spender. Also, the acceptor is required to provide a ZK proof demonstrating that the selected amount does not exceed the maximum available amount b𝑏 published by the initiator.\n3.2.3. Swap finalization\nTo finalize the swap, the offer initiator must first verify that the counterparty’s confidential allowance is sufficient for the particular offer.\nAfterwards, the offer initiator needs to compute the correct amount of assetSell to sell to the offer acceptor. This is done by decrypting the provided a𝑎 during the confidentialApprove, and calculating the sell amount b=𝑏 = a \\over r𝑎𝑟.\nThe initiator then prepares the transfer of b𝑏 tokens of assetSell by encrypting them with the acceptor’s public key, and computing the remaining assetSell allowance l=M-b𝑙 =𝑀 −𝑏.\nTo transfer the agreed assetSell amount, the ZEX contract calls publicConfidentialTransferFrom, which adds b𝑏 tokens to the acceptor’s balance, while the self-encrypted allowance leftover amount l𝑙 is added back to the initiator’s pending balance. Finally, within the same transaction, the initiator receives the payment a𝑎 in assetBuy via confidentialTransferFrom invoked by the ZEX contract by spending the acceptor’s confidential allowance granted during the offer acceptance.\nTo summarize, users either complete the swap and exchange tokens according to the specified rate or cancel the approval at any time to stop the swapping process. At no point in time does the DEX disclose the actual amounts exchanged, publicly operating only with the exchange rate and the initial offer placement amount.\n4. Solidity Smart Contracts\n4.1. Confidential token state variables\n4.1.1. Confidential allowance\nThe confidential allowance data is stored in the following struct:\nstruct ConfidentialAllowance {\n address operator;\n bytes amountEncryptionData;\n bytes amountCommitmentData;\n}\n\nNote that encryption and commitment data are further decoded according to the confidential token specification.\nThe allowances are stored in a mapping:\nmapping(address approver => mapping(address spender => ConfidentialAllowance));\n\n4.1.2. Public confidential allowance\nThe confidential allowance granted to the contract is stored in a mapping, where the approved amount is provided in plaintext:\nmapping(address approver => mapping(address spender => uint256));\n\n4.2. ZEX state variables\n4.2.1. Offer data\nThe swap offer is defined by the struct below:\nstruct Offer {\n address initiator;\n address acceptor;\n address assetBuy;\n address assetSell;\n uint256 rate;\n uint256 maxAmountToSell;\n bytes amountToBuyEncryptionData;\n bytes amountToBuyCommitmentData;\n}\n\nOffers are stored in a simple mapping:\nmapping(uint256 offerId => Offer);\n\n4.3. Confidential token functions\n4.3.1. Granting confidential allowance\nTo grant the confidential allowance to a registered EOA, the confidentialApprove function has to be invoked:\nfunction confidentialApprove(\n address approver,\n address spender,\n address operator,\n bytes calldata amountEncryptionData,\n bytes calldata amountCommitmentData,\n bytes calldata proofData\n) external;\n\nThe encryption and commitment data parameters store values encrypted with both approver’s and spender’s public keys, similarly to the transfer function from the cWETH protocol.\n4.3.2. Granting public confidential allowance\nTo grant the allowance to the contract, the publicConfidentialApprove function is provided:\nfunction publicConfidentialApprove(\n address approver,\n address spender,\n uint256 amount,\n bytes calldata newBalanceEncryptionData,\n bytes calldata amountCommitmentData,\n bytes calldata proofData\n) external;\n\nThe encryption and commitment data parameters in this function are for storing the new balance and amount values encrypted with the approver’s public key to update the balance after approval.\n4.3.3. Spending confidential allowance\nTo spend confidential approval, the operator has to call the following function:\nfunction confidentialTransferFrom(\n address approver,\n address spender,\n bytes calldata amountEncryptionData,\n bytes calldata amountCommitmentData,\n bytes calldata proofData\n) external;\n\nThe encryption and commitment data parameters store the transfer amount encrypted with the spender’s public key and the allowance amount left after transferring, encrypted with the approver’s public key.\n4.3.4. Spending public confidential allowance\nTo spend the public confidential allowance, the spender contract invokes the function below:\nfunction publicConfidentialTransferFrom(\n address approver,\n address receiver,\n bytes calldata amountEncryptionData,\n bytes calldata amountCommitmentData,\n bytes calldata proofData\n) external;\n\nThe encryption and commitment data parameters include the transfer amount encrypted with the receiver’s public key, and the leftover allowance amount self-encrypted with the approver’s public key.\n4.3.5. Cancelling confidential allowance\nTo cancel the confidential allowance granted to the EOA, the approver has to use the function below:\nfunction cancelConfidentialAllowance(\n address approver,\n address spender,\n bytes calldata proofData\n) external;\n\nIn case the approver is not equal to msg.sender, the proofData contains the ZK proof to verify the possession of the approver’s private key.\n4.3.6. Cancelling public confidential allowance\nCancelling the public allowance granted to the contract has to be done via the following function:\nfunction cancelPublicConfidentialAllowance(\n address approver,\n address spender,\n bytes calldata balanceEncryptionData,\n bytes calldata amountCommitmentData,\n bytes calldata proofData\n) external;\n\nThe balanceEncryptionData is used to store the new DH-encrypted balance of the approver after the refund, while the amountCommitmentData represents the ElGamal commitment of the actual allowance refund amount.\n4.4. ZEX functions\n4.4.1. Initiating a swap offer\nTo create a swap offer, the initiator needs to call the following function:\nfunction initiateOffer(\n address assetBuy,\n address assetSell,\n uint256 rate,\n uint256 maxAmountToSell,\n bytes calldata approveData\n) external returns (uint256 offerId);\n\nThe approveData consists of the parameters and ZK proof required for the publicConfidentialApprove invoked within the initiateOffer function.\n4.4.2. Accepting the offer\nTo accept the existing offer, the acceptOffer function is provided:\nfunction acceptOffer(\n uint256 offerId,\n bytes calldata approveData,\n bytes calldata proofData\n) external;\n\nThe approveData stores the data required for the confidentialApprove invoked within the acceptOffer function. It also includes the encrypted amount of assetSell to buy from the initiator. The proofData represents a ZK proof demonstrating that this amount is within the range of the defined maximum available amount of the offer.\n4.4.3. Finalizing the swap\nTo finalize the peer-to-peer confidential swap, the offer initiator needs to call the function below:\nfunction finalizeSwap(\n uint256 offerId,\n bytes calldata transferFromData\n bytes calldata proofData\n) external;\n\nThe transferFromData consists of values required for \\newline publicConfidentialTransferFrom and confidentialTransferFrom functions invoked during the swap finalization. The proofData parameter is a ZK proof used to verify the correct decryption of the acceptor’s buy amount and calculation of the initiator’s sell amount.\n5. ZK Circuits\nAll parameters outlined in this proposal are designed to be verifiable on-chain and compatible with zero-knowledge circuits.\n5.1. Confidential token circuits\n5.1.1. Confidential approve circuit\nThe list of circuit signals for the confidential approve proof is the following:\nPublic signals:\n\nApprover’s public key;\nSpender’s public key;\nElGamal commitment of the approver’s balance;\nElGamal commitment of the allowance amount based on the approver’s public key;\nElGamal commitment of the allowance amount based on the spender’s public key;\nNew approver’s balance encrypted with the approver’s DH self-key;\nRandom nonce used in the approver’s new balance encryption;\nAllowance amount encrypted with the spender’s public key-based DH shared key;\nRandom nonce used during the spender’s allowance amount encryption.\n\nPrivate signals:\n\nApprover’s private key;\nApprover’s balance;\nAllowance amount;\nRandom nonce used in the approver’s ElGamal commitment;\nRandom nonce used in the spender’s ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided approver’s public key.\nThe provided approver’s balance is proven to be the one committed using the ElGamal commitment and to be greater than or equal to the allowance amount.\nThe approver’s ElGamal commitment of the allowance amount was generated correctly.\nThe spender’s ElGamal commitment of the allowance amount was generated correctly.\nThe approver’s new balance was correctly encrypted with the approver’s public key-based DH shared key.\nThe allowance amount was correctly encrypted with the spender’s public key-based DH shared key.\n\n5.1.2. Public confidential approve circuit\nThe list of circuit signals for the public confidential approve proof is the following:\nPublic signals:\n\nApprover’s public key;\nAllowance amount;\nElGamal commitment of the approver’s balance;\nElGamal commitment of the allowance amount based on the approver’s public key;\nNew approver’s balance encrypted with the approver’s DH self-key;\nRandom nonce used in the approver’s new balance encryption.\n\nPrivate signals:\n\nApprover’s private key;\nApprover’s balance;\nTransfer amount;\nRandom nonce used in the approver’s ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided approver’s public key.\nThe provided approver’s balance is proven to be the one committed using the ElGamal commitment and to be greater than or equal to the allowance amount.\nThe approver’s ElGamal commitment of the allowance amount was generated correctly.\nThe approver’s new balance was correctly encrypted with the approver’s public key-based DH shared key.\n\n5.1.3. Confidential transferFrom circuit\nThe list of circuit signals for spending the confidential allowance proof is the following:\nPublic signals:\n\nApprover’s public key;\nSpender’s public key;\nSpender’s ElGamal commitment of the allowance;\nElGamal commitment of the amount to transfer based on the spender’s public key;\nElGamal commitment of the transfer amount based on the approver’s public key;\nTransfer amount encrypted with the spender’s DH self-key;\nTransfer amount encrypted with the approver’s public key-based DH shared key;\nRandom nonce used in the spender’s transfer amount encryption;\nRandom nonce used in the approver’s transfer amount encryption.\n\nPrivate signals:\n\nSpender’s private key;\nAllowance amount;\nTransfer amount;\nRandom nonce used in the spender’s ElGamal commitment;\nRandom nonce used in the approver’s ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided spender’s public key.\nThe provided allowance amount is proven to be the one committed using the ElGamal commitment.\nThe provided transfer amount is proven to be the one committed using the\nElGamal commitment and to be greater than or equal to the allowance amount.\nThe transfer amount was correctly encrypted with the spender’s public key-based DH shared key.\nThe transfer amount was correctly encrypted with the approver’s public key-based DH shared key.\n\n5.1.4. Public confidential transferFrom circuit\nThe list of circuit signals for spending the public confidential allowance proof is the following:\nPublic signals:\n\nApprover’s public key;\nSpender’s public key;\nAllowance amount;\nElGamal commitment of the amount to transfer based on the spender’s public key;\nElGamal commitment of the allowance amount left after transferring based on the approver’s public key;\nTransfer amount encrypted with the spender’s public key-based DH shared key;\nAllowance amount left after transferring encrypted with the approver’s DH self-key;\nRandom nonce used in the spender’s transfer amount encryption;\nRandom nonce used in the approver’s remaining allowance amount encryption.\n\nPrivate signals:\n\nSpender’s private key;\nTransfer amount;\nRandom nonce used in the spender’s ElGamal commitment;\nRandom nonce used in the approver’s ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided spender’s public key.\nThe provided transfer amount is proven to be the one committed using the ElGamal commitment and to be greater than or equal to the allowance amount.\nThe allowance amount left after transferring is proven to be the one committed using the ElGamal commitment.\nThe transfer amount was correctly encrypted with the spender’s public key-based DH shared key.\nThe remaining allowance amount was correctly encrypted with the approver’s public key-based DH shared key.\n\n5.1.5. Confidential allowance cancellation circuit\nThe list of circuit signals for cancelling the confidential allowance proof is the following:\nPublic signals:\n\nApprover’s public key.\n\nPrivate signals:\n\nApprover’s private key.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided public key.\n\n5.1.6. Public confidential allowance cancellation circuit\nThe list of circuit signals for cancelling the public confidential allowance proof is the following:\nPublic signals:\n\nApprover’s public key;\nAllowance amount;\nElGamal commitment of the approver’s balance;\nElGamal commitment of the refund amount based on the approver’s public key;\nApprover’s new balance after the refund, encrypted with the approver’s DH self-key;\nRandom nonce used in the approver’s new balance encryption.\n\nPrivate signals:\n\nApprover’s private key;\nApprover’s balance;\nRandom nonce used in the approver’s ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided public key.\nThe provided approver’s balance is proven to be the one committed using the ElGamal commitment.\nThe provided allowance refund amount is proven to be the one committed using the ElGamal commitment.\nThe approver’s new balance was correctly encrypted with the approver’s public key-based DH shared key.\n\n5.2. ZEX circuits\n5.2.1. Offer acceptance circuit\nThe list of circuit signals for accepting the swap offer proof is the following:\nPublic signals:\n\nAcceptor’s public key;\nInitiator’s public key;\nMaximum amount to sell;\nExchange rate;\nElGamal commitment of the assetBuy amount to pay to the initiator.\n\nPrivate signals:\n\nAcceptor’s private key;\nThe chosen amount to buy from the initiator;\nRandom nonce used in the ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided acceptor’s public key.\nThe provided amount to buy from the initiator is the one used for computing the amount to pay to the initiator committed using the ElGamal commitment.\nThe provided amount to buy from the initiator is less than or equal to the maximum amount to sell.\n\n5.2.2. Offer finalization circuit\nThe list of circuit signals for finalizing the swap offer proof is the following:\nPublic signals:\n\nAcceptor’s public key;\nInitiator’s public key;\nExchange rate;\nElGamal commitment of the assetBuy amount to buy from the acceptor;\nElGamal commitment of the assetSell amount to sell to the acceptor.\n\nPrivate signals:\n\nInitiator’s private key;\nAmount to sell to the acceptor;\nRandom nonce used in the ElGamal commitment of the amount to sell.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided initiator’s public key.\nThe provided amount to sell to the acceptor is the one computed from the decrypted amount to buy from the acceptor.\nThe provided amount to sell to the acceptor is the one committed using the ElGamal commitment.\n\n6. Security Considerations\nThere are several existing security challenges of the ZEX protocol that must be emphasized.\n\nThe initial offer allowance may be used to deduce the actual amount of tokens swapped. If the offer initiator is not careful about their public approvals, they may leak information about their previous swaps.\nThe swap offer may be griffed by accepting it with a small amount of buy tokens. One potential mitigation is to let the offer initiator specify the range of buy tokens they are comfortable accepting, but this may lead to disclosing even more information about the swap.\n\n7. Future Work\nAlthough this paper outlines the main functional concepts of the ZEX protocol and confidential allowances, several open directions remain for further research.\nFirst, there is an unresolved design question regarding the management of the maximum available amount to sell during the swap offer. In the current specification, the public confidential allowance, which guarantees the availability of the sell amount, can only be spent once. The open question is the design of a more robust approach to dynamically update the public allowance amount, providing the ability to implement multi-fill offers without compromising the confidentiality of remaining allowance funds.\nSecond, the current solution uses multiple ZK proofs for acceptance and finalization of the offer, which introduces a significant gas overhead. Several proofs must be verified in a single transaction when performing offer manipulations. For example, during the offer finalization, one must provide a proof of the correct sell amount computation according to the provided buy amount, and two proofs for the publicConfidentialTransferFrom and confidentialTransferFrom function calls. Although such an approach may seem consistent in terms of token approval model usage separately from ZEX, it drastically increases the overall cost of the swap. One potential remedy is to delegate proof aggregation to a trusted coordinator contract. However, this introduces new trust assumptions and expands the potential attack surface.\nThird, it is possible to extend the ZEX protocol to conceal the price of the initial offer, ultimately increasing the privacy of swaps, but forcing the initiator and acceptor to haggle.\nReferences\nEthereum Privacy: The Road to Self-Sovereignty\nConfidential Wrapped Ethereum\n\n Private Multisig v0.1\n\n read \n\n 9\n min\n\n post by pememoni on Aug 22, 2025\n\n Powered by Discourse","tokens":7030,"squid":"ink-research","role":"Deep Scholar","at":1791258178774,"hash":"7e30af147251d769dd24bfff55842fd03c1565c0"}
{"url":"https://www.openzeppelin.com/news/onchainid-audit","domain":"openzeppelin.com","title":"ONCHAINID Audit","text":"September 29, 2026OpenZeppelin SecuritySummaryTimeline: 2026-07-27 → 2026-08-07Languages: SolidityFindingsTotal issues: 39 (36 resolved)Critical: 1 (1 resolved) · High: 2 (2 resolved) · Medium: 9 (7 resolved) · Low: 20 (19 resolved)Notes & Additional Information7 notes raised (7 resolved)Client Reported Issues0 reported issues (0 resolved)ScopeOpenZeppelin performed an audit of the T-REX-Network/ONCHAINID repository at commit d2096509.In scope were the following files:contracts\n├── Identity.sol\n├── IdentityUtilities.sol\n├── KeyManager.sol\n├── SmartAccount.sol\n├── factory\n│ ├── IIdentityFactory.sol\n│ └── IdentityFactory.sol\n├── interface\n│ ├── IClaimIssuer.sol\n│ ├── IERC734.sol\n│ ├── IERC735.sol\n│ ├── IIdentity.sol\n│ ├── IIdentityUtilities.sol\n│ └── IKeyExecutor.sol\n├── libraries\n│ ├── Errors.sol\n│ ├── FormatResolver.sol\n│ ├── Hashing.sol\n│ ├── IdentityTypes.sol\n│ ├── KeyPurposes.sol\n│ └── KeyTypes.sol\n├── modules\n│ ├── claims\n│ │ └── EASClaimIssuer.sol\n│ ├── executors\n│ │ ├── KeyApprovalModule.sol\n│ │ └── RecoveryModule.sol\n│ └── validators\n│ ├── ERC734Validator.sol\n│ └── ERC7579Validator.sol\n├── proxy\n│ └── IdentityUtilitiesProxy.sol\n├── reputation\n│ ├── IReputationRegistry.sol\n│ └── ReputationRegistry.sol\n├── storage\n│ └── Structs.sol\n└── vendor\n └── eas\n └── IEAS.solThe deployment script (scripts/DeployOnchainID.s.sol) and its AccessManager policy table were not in scope and were consulted only as the client's statement of the intended configuration. The RecoveryModule contract is in scope as an integration wrapper, but the upstream ERC7579SocialRecoveryExecutor it inherits was not reviewed, because the OpenZeppelin accounts source is not reachable in the audited checkout, where it is present only as a compile stub. Tests and third-party dependencies were not in scope.Update: The fixes for the findings highlighted in this report have all been merged at commit 4fda205.System OverviewONCHAINID is the on-chain identity layer of the T-REX (ERC-3643) permissioned-token framework. Each participant holds an identity contract that records cryptographic keys and verified claims, and token contracts consult that identity to decide whether a wallet is eligible to hold a regulated asset. The audited revision reimplements the identity as a modular ERC-7579 smart account, which adds ERC-4337 account abstraction and, through ERC-7913, support for secp256r1, RSA, and WebAuthn signers in addition to ECDSA.Keys and authorization: ERC-7579 has no concept of key purposes and defines its own execution path, while the ERC-734 model defines a purpose system and its own execute-and-approve path. The ERC734Validator module reconciles the two. It is at once the key registry that records which key holds which purpose, the validator that authorizes user operations by checking the signer and applying per-target scoping (a management key passes any target, self-targeted and factory-targeted calls require a management key, and other external targets require an action key), and the claim registry whose EIP-712 digest-keyed revocation is designed to prevent the resurrection of a revoked claim through signature malleability. The account contract re-applies the same restrictions on its own execution path, and the legacy execute-and-approve queue is provided by a separate KeyApprovalModule.Identity binding: The IdentityFactory deploys each identity as a CREATE3 proxy backed by a shared upgradeable beacon and maintains the wallet-to-identity bindings that token contracts rely on for eligibility. Wallets are stored as ERC-7930 interoperable-address envelopes so that EVM, ERC-7913, and non-EVM signers share one keyspace. A local wallet binds by submitting an EIP-712 signature that proves control, while a non-EVM wallet proves control on its native chain and relays that proof through an authenticated ERC-7786 gateway message, which the target identity finalizes. Bindings are sticky, and revocation is terminal.Supporting components: A reputation registry gates trusted-issuer claim writes, an EAS adapter resolves Ethereum Attestation Service attestations as claims, a recovery module wraps an external social-recovery executor, and a utilities registry maps claim topics to schemas for off-chain consumers. Access control uses the OpenZeppelin AccessManager for the factory, the reputation registry, and the EAS adapter.Security Model and Trust AssumptionsThe model below describes the system as reviewed, at the in-scope commit d2096509, and is the baseline this report's findings are written against rather than a description of the current deployment. Several of the behaviors noted here were changed by the remediations merged at 4fda205 (see the Scope update above).Authorization is expressed through ERC-734 key purposes. A management key fully controls an identity, including module installation, key rotation, and wallet binding. An action key is a lower-privilege signer, and the boundary between an action key and a management key is the principal property this report examines. Claim-related and proposer purposes carry narrower authority.Two assumptions are load-bearing. First, an identity's module set is chosen by whoever deploys it: the initializer requires only that at least one validator or executor be installed, and no canonical module configuration is enforced on-chain, so several safety properties depend on how an identity is assembled rather than on invariants the contracts guarantee. Second, the reach of the factory's third-party creation and linking entry points depends on the AccessManager policy configured at deployment, which is defined in the out-of-scope deployment script. The contracts authenticate a caller against a role, but whether that role is public or restricted is a deployment decision.Privileged RolesIdentity owner (management key): controls the identity, including module installation and removal, key rotation, and the binding and revocation of wallets through the factory.AccessManager admin: governs the factory, the reputation registry, and the EAS adapter. The admin configures the per-identity-type creation policy, the trusted cross-chain gateways, the reputation scores, and the EAS topic-to-schema mappings and attester allowlist. The admin also initializes and upgrades the beacon that every identity proxy points to, and can therefore replace the implementation of all deployed identities at once and, at the reviewed commit, without delay; the upgrade path was subsequently placed behind a dedicated timelocked role. This role starts in the deployer's control.Utilities registry admin and topic manager: role-based accounts that curate the topic-to-schema catalog and can replace the implementation of the UUPS-upgradeable utilities registry. Both roles start with the admin chosen at initialization.Identity-type creation roles: per-type roles that gate who may create an identity of a given type through the factory's third-party entry point.Trusted claim issuers and EAS attesters: parties whose attestations are accepted as valid claims. They are trusted to issue and revoke attestations faithfully. At the reviewed commit, the attester allowlist is global, so each allowlisted attester is trusted for every configured topic; it was subsequently keyed per topic.Cross-chain gateway: an ERC-7786 gateway trusted to deliver only authentic cross-chain link messages. A message admitted from a trusted gateway is treated as proof that the wallet authorized the link on its source chain.Social-recovery executor: a module that, once installed and granted a management key, can replace the identity's management keys. Its logic is out of scope for this audit.Critical SeverityValidator and Account Resolve the Same Batch Calldata to Different TargetsA signer holding only the ACTION purpose can grant itself a MANAGEMENT key on a default identity, with no victim interaction and no misconfiguration, because the validator that authorizes a user operation and the account that executes it can be made to read the same batch calldata as two different target sets. The _scopeAllows function and the _execute function both decode a user operation's executionCalldata with OpenZeppelin's ERC7579Utils.decodeBatch, which leaves per-entry pointer validation to Solidity's generated calldata-array accessor. That accessor bounds each pointer against calldatasize() of the enclosing frame, and the two frames differ: the account is entered through execute, where the payload is the whole calldata, while the validator is entered through validateUserOp, where the same payload sits 420 bytes into the re-encoded user-operation buffer (with an empty initCode).A batch entry carrying an oversized, wrapping pointer therefore reads in-range garbage in the validator, where the _targetAllowed function accepts it as an ordinary external target that an ACTION key may call, and reads out of range in the account, where every head word is zero so the target reads as zero, which resolves to the identity itself. The entry's callData offset wraps to attacker-planted bytes in the same way, so the account makes a self-call with attacker-chosen calldata and satisfies the onlyManagerOrSelf gate on the addKey function. A holder of nothing but an ACTION key thereby grants itself MANAGEMENT, and installModule, uninstallModule and a nested self-execute are reachable the same way.Consider having _scopeAllows decode the batch into memory, so that each entry's pointers are validated against the payload rather than against the enclosing frame, or bounding them against the executionCalldata slice before dereferencing batch[i].target.Update: Resolved at commit eadb9f7 on PR39.High SeverityQueued Approval Omits the Factory Guard That Auto-Approval EnforcesThe factory's wallet-binding entry points, linkAccount, revokeAccount and confirmCrossChainLink, authorize on the calling identity in msg.sender and carry no notion of which ERC-734 purpose drove the call, so the protocol treats the factory as a management-grade target at every gate between a key and it. The user-operation path does so in _targetAllowed, which rejects the factory for any non-MANAGEMENT signer. The account-side check on the queue path, _isKeyAuthorizedToCallTarget, also classifies the factory as management-grade, but it is invoked on the caller's key, and when the dispatch arrives from KeyApprovalModule that caller is the module itself, whose own key is MANAGEMENT in the reference wiring. The account-side factory guard therefore passes regardless of the purpose that requested the call, so the effective gate has to live inside the module.Only one of the module's two authorization surfaces carries it. _canAutoApprove refuses to auto-run a factory-targeted request for a non-MANAGEMENT key, while approve distinguishes only self-targeted calls, which demand MANAGEMENT, from every other target, which demands no more than ACTION, so the factory falls into the generic external branch. An ACTION key can therefore queue a factory call, watch auto-approval correctly refuse it, then approve its own pending request, which _runApproved dispatches through the account's executeFromExecutor under the module's MANAGEMENT key. Driven against revokeAccount on the identity's own MANAGEMENT wallet, this strips the identity of that wallet, and the owner cannot restore the link afterward even with a freshly signed LinkAccount authorization.Consider deriving the required purpose from a single shared helper used by both _canAutoApprove and approve, with the identity and the identity factory both classified as MANAGEMENT targets, so the queued-approval path enforces exactly the same factory rule as auto-approval and the user-operation validator.Update: Resolved at commit 16101bc on PR41.Key Registry Not Recognized as a Privileged Call TargetERC734Validator is the enshrined registry, reachable as registryModule(), and it writes keys under registries[msg.sender], so any call an identity dispatches to it mutates that identity's own key set. The user-operation path guards this explicitly, with the _targetAllowed function refusing the registry as a target, but the _canAutoApprove function refuses only the factory and defers the rest to the account's own-module check. That check, in the _authorizeCall function, derives from installation state, while the registry address is an immutable returned by the registryModule function, so the two coincide only because the reference module list happens to install the validator as an executor, an entry with a zero purpose that no code path otherwise uses.Should a deployment omit that entry, a key holding only ACTION could queue an execution targeting the registry with addKey calldata, which would grant it MANAGEMENT and allow it to remove the original owner's key.Consider having _authorizeCall treat registryModule() as an own-module target unconditionally, and refusing that target in _canAutoApprove as the factory is refused.Update: Resolved at commit e8f1e79 on PR41.Medium SeverityLast-Manager Guard Counts Module Keys That Cannot SignThe removeKey function protects an identity from losing its administrators by requiring byPurpose[MANAGEMENT] to hold more than one entry. That set counts module keys as well: the initialize function registers a MODULE-type key for every module installed with a non-zero purpose, and the reference wiring grants KeyApprovalModule MANAGEMENT. Such keys cannot sign anything, since the _rawERC7579Validation function rejects any signer whose keyType is MODULE, for user operations and ERC-1271 alike. On a single-owner identity the tally therefore already reads two, so the owner can remove their own MANAGEMENT purpose and leave the identity with no party able to authorize a management operation again.The factory's post-deployment check reads the same set, so an identity whose only MANAGEMENT holder is a module install entry passes it and can be minted in that state from the outset.Consider gating both the guard and the factory's check on the presence of a MANAGEMENT key the validator would accept as a signer, rather than on membership of the purpose set, and applying the guard only when the key being removed is not itself a module key, so that module uninstall still succeeds.Update: Resolved at commit 84cd5fd on PR44.Cross-Identity Claim Writes Are Authorized Against the Validator Singleton Instead of the IssuerThe addClaimTo function verifies the claim and then calls addClaim on the target identity, naming the calling account as the issuer. That call originates from the shared ERC734Validator singleton rather than from the issuer identity, so the target's fallback appends the singleton as the ERC-2771 caller and the _requireClaimKey function asks whether the target granted a claim key to the singleton, never whether it granted one to the issuer.Two consequences follow. A target that does what the NatSpec says and grants CLAIM_SIGNER to the issuer identity still sees addClaimTo revert with SenderDoesNotHaveClaimSignerKey. The grant that does unlock the flow is not issuer-specific: the singleton is the same contract behind every identity on the deployment, so one claim key granted to it admits every issuer whose own claim-status check passes, letting one identity write attestations into another's registry attributed to an issuer the target never authorized. That key can also arise without a deliberate decision, since the initialize function grants a MODULE-type key to any module install entry carrying a non-zero purpose, and the _keyHasPurpose function lets MANAGEMENT satisfy the CLAIM_SIGNER check.Consider adding an explicit issuer-bound cross-identity path that authenticates the issuing identity and evaluates the target's claim-key policy against that identity, rather than against whichever caller the fallback forwards.Update: Resolved at commit 5e04575 on PR45.Installed Executors Cannot Be Reached by the Account, Leaving Their Self-Gated Functions UnreachableThe _authorizeCall function reverts with OwnModuleTargetBlocked whenever a dispatched call targets an installed executor or the fallback handler for the called selector, with no exemption for any caller, including a MANAGEMENT self-call. The rule is deliberate: as the comment on that branch records, module functions are meant to be reached through the account's fallback dispatch, which appends the real caller ERC-2771 style, whereas execute(module, ...) skips that append and would leave the module misreading its caller. The block reaches further than that rationale requires, however. Because execute and executeFromExecutor are the only routes into the _execute function, which is the account's only outbound path, the account cannot originate a call to one of its own executors, and any module function gated on msg.sender == account is beyond its reach.The RecoveryModule contract is documented as installed exactly that way. Its account-gated members are therefore unavailable: the owner's unilateral veto over a pending recovery, and the guardian, threshold, weights, delay, and expiration setters, which remain at their install-time values for the life of the identity, so an untrusted guardian set cannot be rotated by the identity it protects. The repository's own test_accountSelfCancelStopsRecovery test covers the veto using vm.prank(address(aliceIdentity)), a caller the deployed account cannot produce.The blocking behavior is a property of SmartAccount and was verified against this repository. The list of gated members was not: it belongs to the upstream ERC7579SocialRecoveryExecutor that RecoveryModule inherits from the private openzeppelin-accounts dependency at pin e4c2a32a, which is present in the audited checkout only as a 19-line stub carrying no recovery logic, so that list should be re-verified against the real pinned source.Consider routing the owner-side veto and the recovery configuration through a dedicated account entry point that reaches the module with the account as msg.sender, while keeping the block in place for ordinary dispatched calls.Update: Resolved at commit 6d4814b on PR46.The Factory's Post-Deployment Key Check Is Answered by a Caller-Supplied Fallback HandlerAfter CREATE3 deploys the proxy, _doCreateIdentity asserts the identity's shape before recording it as factory-deployed: it calls getKeysByPurpose for the MANAGEMENT purpose through the IERC734 interface and requires the returned array to hold at least one entry, reverting with NoManagementKeyInKeys otherwise. The account implements no ERC-734 getter of its own; those selectors are served by a fallback handler that Identity.initialize registers from the caller-supplied _modules array, and the only constraint on that array is that it contain a validator or an executor. The deployer therefore chooses which contract answers getKeysByPurpose, so the post-deploy check asks a contract the same deployer submitted, in the same call, whether the deployer's identity is well-formed.A handler that returns a one-element array satisfies the check while the enshrined ERC734Validator registry, read directly, holds no MANAGEMENT key for the identity. The deploy runs to completion and the wallet is linked, and the state is permanent: addKey reverts with SenderDoesNotHaveManagementKey for every external caller, _targetAllowed rejects a non-MANAGEMENT signer for self-targeted, validator and factory calls so an ACTION key can neither promote itself nor reach revokeAccount, and _linkAccount sticky-binds the deployer's wallet to that unmanageable identity for good.The isFactoryIdentity flag the identity earns is load-bearing elsewhere. ReputationRegistry.reputationOf gates the default reputation tier on it, and EASClaimIssuer._resolve treats it as proof that an attestation recipient is not an arbitrary contract posing as the identity, both resting on a key-shape invariant the factory does not in fact verify. Identity.supportsInterface likewise advertises IERC734 conformance for a getter surface the deployer selected, so any integrator reading key state through the identity address rather than the registry module reads deployer-controlled answers for the life of the identity.Consider performing the factory-side integrity check against the enshrined registry that the identity's registryModule view returns, rather than through the account, so the assertion cannot be routed through caller-installed dispatch, and having Identity.initialize reject fallback installs for the ERC-734 getter selectors that point anywhere other than the registry module.Update: Resolved at commit 248e116 on PR47.Non-Canonical ERC-7930 Envelopes Give One Wallet Multiple Registry KeysThe factory identifies every wallet by hashing its ERC-7930 envelope: _walletKey returns keccak256 over the raw account bytes with no normalization, and the registry's collision guarantees, namely sticky binding, terminal revocation and one wallet per key, all depend on that hash being a stable identifier. The encoding is not canonical, however: linkAccount extracts the signer with InteroperableAddress.parseV1Calldata, whose NatSpec states that trailing bytes after a valid v1 encoding are ignored, so the same decoded address can correspond to multiple distinct input byte strings. Appending two zero bytes to a wallet's canonical envelope yields a blob that decodes to the identical signer but whose keccak256 differs, so _walletKey returns two different keys for one wallet, and the owner can freely produce a valid LinkAccount signature for each encoding.Three invariants break as a result. Sticky binding: _linkAccount rejects re-binding only when entry.identity is already set, so a padded encoding is a fresh entry that can be bound to a different identity, and one wallet resolves to two identities through getIdentity and appears twice in getAccounts. Terminal revocation: the WalletAlreadyRevoked guard fires only for the exact key revoked, so after revokeAccount retires the canonical envelope the wallet re-links through a padded one, defeating the guarantee that a revoked wallet can never be relinked that the compliance model rests on. And wallet uniqueness: the registry the T-REX modules treat as the source of truth reports one signer as an unbounded number of independent wallets, while the client's own test_envelopes_evmAndNonEvmAreDistinct frames hash distinctness as a safety property and never exercises two encodings of a single wallet.Consider deriving the wallet key from the canonical decoded components rather than the raw bytes, hashing keccak256(abi.encode(chainType, chainReference, signer)) or re-encoding the parsed triple through formatV1 before hashing, so every encoding of one wallet collapses to a single key, and applying the same normalization on the cross-chain path in _processMessage. Alternatively, reject non-canonical input outright by requiring the consumed envelope length to equal the input length, so that linkAccount, revokeAccount and _processMessage all refuse trailing bytes.Update: Resolved at commit dced9d4 on PR48.Signature-Based Linking Does Not Constrain the Envelope's Chain Type or ReferenceThe IIdentityFactory interface documents two disjoint proof-of-control routes: EVM and ERC-7913 signers prove control through an on-chain signature check, while non-EVM wallets prove control on their native chain and relay that proof through an ERC-7786 message. The linkAccount function does not enforce the split. It parses the ERC-7930 envelope but keeps only the signer field, discarding the chain type and reference that say which chain the wallet lives on, and then admits the binding on whatever SignatureChecker.isValidSignatureNow accepts over the LinkAccount digest.That helper dispatches on signer length: twenty bytes is an EOA or an ERC-1271 wallet, and anything longer is treated as ERC-7913, where the leading twenty bytes name the verifier that judges the remaining key. For every envelope whose address field exceeds twenty bytes, the proof is therefore self-certifying, since a caller can deploy a permissive verifier that returns the success selector for any input, place it in those leading bytes, and link with a dummy signature. Because the chain type is never read, that envelope may carry a non-EIP-155 tag and a foreign chain reference and still bind through the path reserved for EVM and ERC-7913 signers. The caller needs a MANAGEMENT key on the identity and binds the wallet to itself, so this is registry pollution rather than an outside takeover, but it leaves a permanent, enumerable account for which no control was proven, indistinguishable through getAccounts and getIdentity from a wallet that proved control on its own chain. The repository's own test_linkAccount_nonEvmEnvelopeRejected test asserts that such an envelope is rejected, and holds only because the thirty-two-byte signer it chooses begins with twenty bytes that carry no code.Consider constraining the signature path to the chains it can actually verify, requiring the envelope's chain type to be EIP-155 and its address field to be a canonical twenty-byte EVM address or a recognized ERC-7913 shape, and routing foreign wallets exclusively through the confirmCrossChainLink function, which carries native-chain proof. Where ERC-7913 signers are accepted, consider binding the permitted verifiers to a trust list rather than accepting a caller-embedded verifier as its own attester.Update: Resolved at commit 0587147 on PR49.Claim Digests and Revocation Records Are Recomputed From the Issuer's Live EIP-712 DomainThe _getClaimDigest function rebuilds the domain separator from the issuer's eip712Domain() on every call, and nothing persists the result: the _getClaimStatus function verifies each stored signature against a freshly computed digest, and the removeClaim function keys its revocation record on one.Identities are beacon proxies taking their domain from EIP712(\"OnchainID\", \"1\") in the Identity constructor, while the version function returns \"3.0.0\". An upgrade that changes the EIP-712 name or version, for instance to reconcile that mismatch, shifts the domain for every identity in the deployment at once, with two effects: stored signatures no longer verify, so valid claims read as BadSignature, and existing revocation records are keyed under the old domain, so revoked claim content can be re-added.The length of those strings is load-bearing in a way nothing records. OpenZeppelin's EIP712 keeps the name and version in immutables when each fits a ShortString and in a storage fallback otherwise, and the constructor runs on the implementation rather than on any proxy. \"OnchainID\" and \"1\" fit, so every proxy reads the immutable and agrees with the implementation. A replacement name over 31 bytes would instead be written to the implementation's storage, leaving each proxy to read its own empty slot, so the domain would degrade to an empty name with no revert and no event, taking every claim digest and every revoked-digest key with it.Consider persisting each claim's digest at insertion time instead of recomputing it on read, so that both claim validity and revocation are independent of the issuer's current domain, and documenting the EIP-712 name and version as frozen across upgrades, with the 31-byte ShortString limit called out explicitly since exceeding it empties the domain rather than merely changing it.Update: Acknowledged, not resolved.The client stated:Closing per the team decision: M-07 is marked acknowledged, not resolved. Domain changes invalidating prior signatures is standard EIP-712 behavior, and the trigger requires deliberately editing the EIP712(\"OnchainID\", \"1\") literal in a beacon upgrade — the rule is to never change the domain on upgrade. Agreed with the points raised in review.One part of this PR was independent of M-07: the try/catch around eip712Domain(), which is what keeps removeClaim working for issuers that don't implement ERC-5267 (the EAS adapter). That fix now lives in #59 (L-08) on its own branch off develop, so nothing is lost by closing this.We agree this is a reasonable acknowledgment for a design that treats the EIP-712 domain as immutable. Claim validity and revocation are recomputed from the issuer's live domain rather than a persisted digest, which is safe as long as that domain never changes, and you have pinned the domain version to \"1\", kept it separate from the identity release version (N-06, so a release bump creates no pressure to change it), and documented in Identity that it must not change.Two points for the record:This is a mitigation, not an elimination. The guarantee now rests entirely on the invariant that the EIP-712 name (\"OnchainID\") and version (\"1\") are never altered in any future implementation. If an upgrade ever changes either, every stored signature reads as BadSignature, and revocation records keyed under the old domain stop matching, so previously revoked claim content can be re-added. We recommend keeping that invariant called out wherever upgrades are described.One specific failure mode belongs in that note. OpenZeppelin's EIP712 holds the name and version as ShortString immutables only while each fits 31 bytes, so a replacement name above that limit empties the domain silently, with no revert and no event, taking every claim digest and revocation key with it. The invariant should therefore also state that any future name stays within the 31-byte ShortString limit.With those noted, we are marking M-07 Acknowledged.Cross-Chain Link Confirmation Skips the Validations the Local Path EnforcesWallet bindings reach the registry through two paths that converge on _linkAccount, but only the EVM path validates its inputs. linkAccount parses the ERC-7930 envelope with InteroperableAddress.parseV1Calldata, reverting on anything malformed, and then rejects ASSET and SMART_CONTRACT targets with CannotLinkToAssetIdentity by reading getIdentityType on msg.sender. The cross-chain half does neither: confirmCrossChainLink matches the caller against the staged proposal and calls _linkAccount, and the staging step _processMessage checks only sender and wallet equality, expiry, factory membership and the absence of a prior entry, treating the wallet as opaque bytes, even though the interface documents confirmation as linking the wallet with the same sticky-binding rules as any EVM-side link.Three checks are dropped as a result. An ASSET identity can accumulate wallets beyond the token auto-linked at _doCreateIdentity, and because revokeAccount rejects ASSET and SMART_CONTRACT callers the extra wallet stays active for the life of the identity. An arbitrary byte string that linkAccount would reject becomes a live, enumerable wallet record that makes any consumer parsing getAccounts revert over the whole set rather than one element. And because _processMessage never parses the envelope, a sender of the form formatEvmV1(block.chainid, wallet), byte-for-byte the shape the local entry points build, stages a pending link for a local EVM address that the named identity can finalize without that address ever signing the LinkAccount digest or consuming its nonce, after which sticky binding locks the real owner out with WalletBoundToAnotherIdentity. All three require a trusted gateway to deliver the proposal and the named identity to confirm with a MANAGEMENT key, and the same-chain facet additionally needs a gateway that emits a same-chain sender a faithful relayer would not produce, so it is defense in depth rather than a path open to an unprivileged caller.Consider moving the shared preconditions into _linkAccount so both entry points inherit them, parsing the envelope and rejecting ASSET and SMART_CONTRACT targets there, with a carve-out for the factory's own auto-link in _doCreateIdentity, and parsing the envelope in _processMessage so a malformed proposal fails on delivery rather than on confirmation, additionally rejecting proposals whose chain reference equals block.chainid, since a wallet on this chain already has a signature-checked route through linkAccount.createIdentityFor Binds a Wallet Without Proof of Control and Does Not Tie Management to the AccountThe createIdentityFor function takes an arbitrary _account, gates the caller on a per-type role through _checkTypeRole, and passes _account to _doCreateIdentity, which auto-links it with _linkAccount. The signature-checked linkAccount admits a wallet only against a LinkAccount signature that proves control, and the self-service createIdentity binds the caller's own address, but this third-party path takes no signature and no other proof that the caller controls _account.The identity's keys carry the same gap. _keys comes from the caller, and Identity.initialize forwards each entry to the registry as supplied — deriving the key hash from the caller's signerData and never checking any key against _account. The only post-deployment assertion is that at least one MANAGEMENT key exists, never that any MANAGEMENT key corresponds to _account. A caller can therefore make its own key the sole MANAGEMENT key, name the victim's wallet as _account, and have the factory bind that wallet to an identity the caller alone controls.The binding is permanent for practical purposes. _linkAccount refuses to move a wallet already bound elsewhere and rejects one that was ever revoked, the factory exposes no unlink primitive, and revokeAccount is terminal and refuses ASSET and SMART_CONTRACT identities, so the real owner cannot later link the wallet to its own identity and is met with WalletBoundToAnotherIdentity. It holds on the canonical envelope the factory itself writes, since createIdentityFor formats the wallet through formatEvmV1; because the lookup key is a bare keccak256 of the raw envelope with no canonicalization, a padded re-encoding of the same wallet hashes to a different slot and produces a second, conflicting binding rather than a clean recovery — that non-canonical keying is tracked as a separate finding.Eligibility follows the binding. EASClaimIssuer._resolve resolves an attestation's recipient wallet to an identity through getIdentityIncludingRevoked, so an attestation issued to that wallet — provided it matches the adapter's configured schema, comes from an allowed attester, and is neither revoked nor expired — validates as a claim on the caller-controlled identity, which isFactoryIdentity still reports as factory-deployed to every consumer that trusts that flag. A SMART_CONTRACT subject has no equivalent of generating a fresh address, since its identity stands for a contract that already exists; a PUBLIC_AUTHORITY subject (a regulator, court, or government issuer) is an off-chain institution that need not be a deployed contract, but it likewise has no way to prove control on this path.Whether an unprivileged caller can reach this depends on the deploy-time AccessManager policy that _checkTypeRole reads. That policy lives in the out-of-scope deploy script, which grants PUBLIC_ROLE to the EOA-shaped types (INDIVIDUAL, CORPORATE, IOT, AI_AGENT) and also to the contract-shaped SMART_CONTRACT and PUBLIC_AUTHORITY — the latter with selfDeployable set to false, so no account may create those identities for itself, yet any account may create one for an arbitrary third party. Restricting createIdentityFor to trusted issuers narrows the exposure to those issuers, but it does not close the gap, because the code proves no control over _account and does not bind the identity's management authority to it.Consider requiring proof of control over _account on the third-party path — either a LinkAccount-style signature bound into the deployment, or a guarantee that _account is the identity's sole MANAGEMENT authority, rejecting additional MANAGEMENT keys and MANAGEMENT-purpose module installs rather than merely requiring _account to appear among the keys. Where the subject cannot sign, such as ASSET and SMART_CONTRACT, restrict createIdentityFor for those types to trusted roles rather than opening them to PUBLIC_ROLE. This was reproduced against the pinned commit, though through a test helper whose type policies are more permissive than scripts/DeployOnchainID.s.sol, so the exact reachable set should be confirmed against the deploy script's policy table before sign-off.Update: Resolved at commit 9a0a011 on PR52.Low SeverityClaim Path and Key Path Use Different Definitions of a Valid SignatureThe _verify function recovers a 20-byte signer with ECDSA.tryRecover and falls through to ERC-1271 only when recovery does not match, deliberately avoiding SignatureChecker's signer.code.length check because it conflicts with ERC-7562 bundler rules. The _getClaimStatus function calls SignatureChecker.isValidSignatureNow instead, which drops the ECDSA branch entirely once the signer address carries code, so one CLAIM_SIGNER key in one registry is judged by two different rules.An EIP-7702 delegation on a claim-signer EOA gives that address code, and the stored ECDSA signature is then routed to the delegate's isValidSignature, which may not return the ERC-1271 magic value for a raw signature blob. A delegate that recovers ECDSA against the delegating account still accepts it and the claim keeps verifying; one that implements no isValidSignature, or that expects a wrapped signature format, does not. _getClaimStatus then reports BadSignature for an unrevoked, unexpired claim whose signature the key path still accepts, so claim validity depends on mutable external state that neither the issuer nor the holder controls, and can move in either direction as the delegation changes. An ERC-3643 deployment reading claim validity as an eligibility gate would see every claim backed by that signer drop on an unrelated wallet upgrade.Consider routing _getClaimStatus through _verify, so that a single definition of a valid signature governs the whole module.Update: Resolved at commit d346e8e on PR54.Introspection Reports Static Support Rather Than Live Module WiringThe account answers introspection from constants, so its answers can disagree with what the installed modules actually serve:The supportsInterface function returns true for IERC734, IERC735 and IIdentity regardless of wiring. Its NatSpec justifies this on the grounds that the interface contract is still honored at runtime, which stops being true once the ERC-735 fallback handler is uninstalled and getClaim begins to revert.supportsExecutionMode, inherited from OpenZeppelin's ERC-7579 base and not overridden in this repository, advertises CALLTYPE_DELEGATECALL, which the _execute function rejects.The advertised ERC-734 identifier is repository-specific: the IERC734 interface declares only the six registry methods, so its interfaceId omits the execute and approve selectors a canonical ERC-734 consumer folds into the identifier.Consider gating supportsInterface on the relevant handler being installed, overriding supportsExecutionMode to match what _execute accepts, and reconciling the advertised ERC-734 identifier with the selectors the account really serves.Update: Resolved at commit d49337d on PR80.Unbounded Dynamic Fields in the Key and Claim RegistryThe _addKey function enforces only a minimum signer length and the _addClaim function enforces nothing, so five stored fields have no upper bound:signerData and clientData, written by _addKeysignature, data.payload, and uri, written by _addClaimBecause the removeClaim function re-reads and re-emits the claim's dynamic fields before deleting them, removal costs more than the write at large sizes, so a sufficiently large claim may not be removable within a block. One oversized claim also breaks any aggregation covering its topic for the whole identity.Consider capping the five fields, sized against the signer types the deployment intends to support.Update: Resolved at commit fc19ae6 on PR55.scheme and uri Are Not Covered by the Claim SignatureThe _addClaim function keys a claim on (issuer, topic) and overwrites the stored record with the caller-supplied scheme and uri, gated only by the issuer's isClaimValid, while the digest built by the _getClaimDigest function covers only the topic, the subject and the claim data. Re-presenting the issuer's own unchanged signature and data alongside a different uri therefore succeeds, so a holder-side claim key can repoint a KYC claim at an attacker-controlled document while the record remains attributed to the legitimate issuer and continues to validate.The _buildClaimInfo function returns that uri alongside isValid: true, so an off-chain consumer fetching the referenced document reads holder-controlled content presented as issuer-attested.Consider binding scheme and uri into the signed digest, or rejecting a re-add that changes either field while the existing claim is still valid.Update: Resolved at commit 03f7a15 on PR79.Claim Events Carry No Subject and the Declared ERC-734 Events Are Never EmittedERC734Validator is a single module shared by every identity that installs it, and it emits the ERC-735 lifecycle events itself.The events declared on IERC735 carry no identity or subject, and the _addClaim function derives claimId from the issuer and topic alone. The same issuer's claim on the same topic, written to two different identities, therefore produces byte-identical ClaimAdded logs from the same emitter.The six events declared on IERC734 are emitted nowhere. Every emission resolves to a same-named local event carrying an additional address indexed account, declared in the validator for the key events and in KeyApprovalModule for the execution events, whose topic hash differs from the declared one. IKeyExecutor nonetheless states that consumers and indexers continue to interpret these as ERC-734 calls.An integrator building against the declared event ABI captures no key or execution lifecycle at all, and cannot attribute a claim change to a specific identity from logs alone.Consider including the subject identity as an indexed field in the claim events, mirroring the address indexed account the key events already carry, and either emitting the canonical ERC-734 events or removing their declarations and documenting the account-carrying variants as the real ABI.Update: Resolved at commit 66f3275 on PR56.Uninstalling One Fallback Selector Strips All of the Module's PurposesERC-7579 registers fallback handlers per selector, so a module serving several selectors is installed once per selector and may additionally be installed as an executor, while the initialize function grants that address a single MODULE-type key backing every one of those installs. The _uninstallModule function does not distinguish between them: whichever install is being removed, it snapshots every purpose the module's key holds and removes all of them before delegating to the base uninstall.Removing a single read-only handler such as getCurrentNonce therefore revokes the module's MANAGEMENT purpose and, with its last purpose gone, deletes the key entirely, while the module remains an installed executor and the handler for its other selectors. Its later dispatches are then refused by the _authorizeCall function with ExecutorPurposeNotAuthorized until a MANAGEMENT holder re-grants the purpose. On an identity where the module's key is the only MANAGEMENT holder the strip instead reverts through the guarded removeKey, so the handler cannot be uninstalled at all.Consider stripping purposes only once the module has no remaining install of any type, or, if enumerating the selector map is impractical, skipping the purpose removal for MODULE_TYPE_FALLBACK uninstalls and requiring an explicit removeKey instead.Update: Resolved at commit 2fe620f on PR57.Re-Added Claim Cannot Be Removed a Second TimeThe removeClaim function derives an EIP-712 digest over the issuer, subject, topic, and claim data, then marks it revoked in both the holder's and the issuer's registry. Only the issuer-side record is read by the _getClaimStatus function to reject a repeated submission, and only when the issuer is an identity backed by this validator. For other issuers the identical claim can be added again, and a second removal then recomputes the same digest, finds it already marked, is rejected by the holder-side guard, and reverts, leaving the claim permanently active.Consider dropping the holder-side guard, or keying the re-removal check on claim existence, which the function already establishes by rejecting an unregistered topic.Update: Resolved at commit 1465732 on PR60.Claims From Issuers Without an EIP-712 Domain Cannot Be RemovedThe removeClaim function computes the claim digest before deleting the local record, and the _getClaimDigest function obtains the issuer's EIP-712 domain by calling eip712Domain() on it. Nothing at insertion requires the issuer to implement ERC-5267, since the _addClaim function delegates validation to the issuer's own isClaimValid and stores the claim without reading the domain.The shipped EASClaimIssuer contract exposes no domain method, so the call reverts and a claim mirrored from an EAS attestation can be added but never deleted, including after the attestation has been revoked at the source. That contradicts the adapter's documented lifecycle, in which the attester revokes on EAS and the holder removes the local record through removeClaim.Consider making local deletion independent of the issuer's EIP-712 domain, or adding an explicit adapter-compatible removal path; at minimum, probing the issuer's capabilities before attempting the digest computation so that a supported claim type cannot become undeletable.Update: Resolved at commit 067f661 on PR59.Initialization Discards KeyParam.keyHash While the Deploy Salt Commits to ItEvery key handed to the factory is a Structs.KeyParam carrying a keyHash field documented as keccak256(signerData). The registry's convenience writer KeyManager._addKeyWithData enforces that commitment by rejecting any key whose declared hash does not equal the hash of the supplied signer data, and its NatSpec states it is used by the external entry point and the initialization path. The initialization path does not in fact use it: Identity.initialize forwards only the signer data, client data, purpose and key type of each key and never reads keyHash, and the registry re-derives the hash from the signer data before writing, so the advertised guard never runs on this path.The discarded field is not inert, because the factory's CREATE3 deploySalt commits to it: the deployed address depends on keyHash while the key the identity actually registers depends only on the signer data. A deployer can vary keyHash freely, moving the deployed address without changing the registered key, so an off-chain consumer that predicts the address and reads the salt's keyHash commitment as a statement of which key the identity holds is misled, with nothing on-chain flagging the divergence. No mismatched key is ever written, which bounds the impact, but the documented API guarantee is violated and the salt's apparent commitment is not the property it advertises.Consider either routing initialization through _addKeyWithData so the same hash check applies on this path, or removing keyHash from Structs.KeyParam entirely and correcting the NatSpec, so the deploy salt commits to exactly the key material the identity will register.Update: Resolved at commit 68fedff on PR58.EASClaimIssuer Resolves Attestations as Valid for the Zero IdentityEASClaimIssuer answers IClaimIssuer queries by translating an EAS attestation into a claim status: isClaimValid delegates to _resolve, which, after confirming schema, attester, revocation and expiry, decides whether the attestation belongs to the queried identity. The self-recipient branch is guarded by isFactoryIdentity, but the linked-wallet branch compares the identity the factory reports for the recipient against the queried identity without first requiring that a link exists. For a recipient wallet not linked in the factory the lookup returns address(0), so a query made for the zero identity satisfies the equality and the adapter returns Valid.Any attestation from an allow-listed attester under a schema-mapped topic therefore resolves as a valid claim for address(0) whenever its recipient is an unlinked wallet, even though the zero identity is not a factory identity and holds no claims. The practical exposure is a compliance path that resolves an unregistered wallet to address(0) and forwards it straight into isClaimValid, where the check passes instead of failing closed. This is a defensive gap and an IClaimIssuer contract violation rather than an attacker-driven escalation.Consider rejecting a zero identity up front in _resolve by returning NotIssued, or requiring the linked address to be non-zero before the equality check, so an unlinked recipient can never match the zero identity.Update: Resolved at commit 4fab9cf on PR61.The CREATE3 Deploy Salt Does Not Bind the Account That Is Auto-LinkedThe factory's shared creation path derives the CREATE3 deploySalt from the identity type, the caller-chosen salt string and the hashes of the keys and modules, but not from the account it is about to auto-link, and that salt is the only input to the CREATE3 address besides the factory itself. createIdentityFor lets the caller name any account and then binds it through _linkAccount. A front-runner who observes a pending creation and replays its four public arguments therefore deploys the identity at the exact address the victim expected, carrying the victim's MANAGEMENT key, but with the front-runner's own wallet auto-linked as the identity's first account. For a self-deployable type the replay needs no role through createIdentity.The binding is sticky, since _linkAccount offers no unlink short of a terminal revoke. The victim keeps control of the identity, but getIdentity permanently resolves the attacker's wallet to the victim's identity, the exact lookup that ERC-3643 eligibility is decided on, so the attacker's wallet inherits the victim's KYC, and the only cure is a revoke that permanently burns the attacker's address for the whole deployment. This is the opposite direction from the separate createIdentityFor squatting finding, and it needs a different fix, since requiring a LinkAccount signature does not help when the front-runner binds a wallet it controls and can sign for.Consider binding the auto-linked account into deploySalt, so that changing that account changes the deployed address and the front-run deploy lands at a different address than the victim's own transaction.Update: Resolved at commit f532ef1 on PR62.ERC-2771 Caller Recovery Mis-Attributes Every Call That Does Not Reach the Identity DirectlyThe externalized ERC-734 modules recover the off-chain caller from the ERC-2771 trailing 20 bytes the account's fallback dispatch appends: both KeyApprovalModule._msgSender and ERC734Validator._msgSender read the last 20 bytes whenever the calldata is at least that long. That tail is the real caller only on the direct path, where a key holder calls the identity at an ERC-734 selector and the fallback appends its immediate caller; as SmartAccount._authorizeCall notes, any dispatch that does not go through that fallback skips the append, so the recovered value is whatever the immediate on-chain caller happened to be. Two paths are mis-attributed as a result: execute auto-approves a self-targeted addClaim for a CLAIM_SIGNER caller and dispatches it immediately through executeFromExecutor, so the account self-calls addClaim and _requireClaimKey recovers the account itself, which holds no claim key and reverts; and a call relayed through an intermediary such as the EntryPoint recovers that intermediary, which likewise holds no key.The impact is limited and fails closed, because in every case the mis-recovered caller is less privileged than the true one, so the effect is a refusal or a silently failed dispatch rather than an escalation. What is lost is functionality: the self-targeted claim auto-approval branch can never succeed, and relayed or meta-transaction routes into execute, approve and addClaim are unusable.Consider threading the original caller through the queue's own dispatch rather than re-deriving it from the appended tail after a self-call, and either documenting that these entry points are reachable only by a direct call from the key holder or removing the auto-approval branch that can never run.Update: Resolved at commit c70be18 on PR63.Thank you for the fix.The code change resolves the broken self-targeted auto-approval path, and no further behavioral change is required provided that direct-call-only access is intentional.As a minor, non-blocking recommendation, please expose this limitation in the public-facing NatSpec or integration documentation: execute, approve, addClaim, and removeClaim require a direct call through the identity fallback and are not supported through EntryPoint, account self-calls, or other meta-transaction routes.The current implementation comments explain this, but making it visible to integrators would prevent ERC-4337 users from assuming these legacy entry points are UserOp-compatible.Queued Executions Carry No Proposer or Expiry and Survive Key RevocationA queued request in the execution module stores no record of who queued it and no time bound: the Execution struct holds only the target, value and calldata together with its approved and executed flags. execute derives the proposer only to gate proposing and to populate the event and never persists it, approve authorizes the approver's key at approval time and never re-checks the proposer, and onUninstall is a no-op, so uninstalling the module leaves the per-account queue intact in shared storage. A pending entry therefore outlives the key that queued it, survives an uninstall and reinstall of the module, and never expires.The impact is limited and fails closed, because executing a stale entry still requires a live ACTION or MANAGEMENT approver at approval time, so no privilege is gained and no arbitrary address can inject a request. The residual is that an execution the original proposer can no longer endorse, since that key was revoked, can still be dispatched later, with no on-chain record of who proposed it.Consider persisting the proposer and an expiry with each queued request, rejecting approval of an entry whose proposer no longer holds the authorizing purpose, and clearing pending entries in onUninstall so a queue cannot be resurrected across a reinstall.Update: Resolved at commit 5212b48 on PR64.Thanks for the follow-up. Rejection no longer requires a live proposer (only an authorized ACTION/MANAGEMENT approver), so a stale entry can be closed, and onUninstall now bumps a per-account firstValidId floor that voids the pending queue across a reinstall. Together with the proposer re-check on approval, the key-revocation and resurrection paths are closed.One item remains unimplemented: an autonomous time-based expiry. A request whose proposer stays authorized, that is never rejected and outlives no uninstall, still has no time bound. Given the severity and that stale entries can now be closed on demand and voided on uninstall, we accept this as a minor residual and consider the finding resolved.A Failed Dispatch Is Recorded as Approved and Executed and Cannot Be RetriedThe _runApproved function writes executed = true and approved = true before it dispatches, then wraps the dispatch in a try/catch that emits ExecutionFailed and returns false rather than reverting. Neither write is undone, so a request whose dispatch failed is left carrying exactly the flags of one that succeeded. The Execution struct has no field recording the outcome and getExecutionData returns that struct verbatim, so nothing on-chain separates the two states: a failed request is byte-identical to a successful one in every field.The behavior has several independent triggers. A dispatch fails when the target reverts, when the identity's balance is below the request's value, when the target is one of the account's own modules and SmartAccount._authorizeCall refuses it, and when the module's purpose has been revoked, whether by the purpose strip a fallback uninstall performs or through the MANAGEMENT-gated KeyManager.removeKey with no uninstall involved. Both entry points reach the helper, since execute auto-runs through it and approve routes to it as well. The repository's own test_execute_autoApprove_targetReverts_ethStaysInIdentity test already drives the path, asserting only on balances and never reading the flags.The impact is off-chain and fails closed. Nothing in contracts/ reads getExecutionData or the struct, no funds move, and no privilege is gained; the cost falls on an integrator or operator reading queue state, who sees a request that never ran reported as approved and executed. The residual that is not merely cosmetic is that the request is terminal: approve rejects any id already carrying executed, and nothing resets the flag, so a dispatch that failed for a transient reason cannot be retried once the cause is cleared and the only way forward is a fresh execution id.Consider recording the dispatch outcome in a third field on Execution, surfaced through getExecutionData, rather than letting executed stand for both attempted and succeeded. Moving the two writes after the try is not a safe alternative: they are what stops the dispatch target re-entering approve on the same id.Update: Resolved at commit dac0be4 on PR65.The EAS Adapter's Attester Allowlist Is Global Rather Than Scoped Per TopicEASClaimIssuer binds trust along two axes, but only one of them is topic-scoped. _resolve accepts an attestation for a queried topic when its schema matches the topic's binding and its attester is allowlisted: attestation.schema == getSchemaForTopic(topic) together with getIsAttesterAllowed(attestation.attester). The schema binding is per topic (_schemaOf), but the attester allowlist is a single global mapping (_isAttesterAllowed, set by setAttester) with no topic or schema parameter.The consequence is that allowlisting an attester for one topic implicitly authorizes it for every configured topic. On an adapter instance serving more than one topic, any allowlisted attester can satisfy any other configured topic by producing an attestation under that topic's bound schema, since nothing in _resolve ties an attester to the topic it was trusted for. The per-topic schema check closes only the schema axis: it stops an attestation made under topic A's schema from being replayed against topic B, but not an attester trusted for topic A from attesting under topic B's schema, because any address may attest under any schema on EAS and the attester gate is global. This diverges from the ERC-3643 trusted-issuer model the adapter says it mirrors, since the canonical TrustedIssuersRegistry scopes each issuer to an explicit list of claim topics.The exposure is bounded, which holds this at Low: attesters are admin-allowlisted and therefore already trusted, so this is a least-privilege weakness rather than an external-attacker escalation, and an operator wanting strict separation can deploy one adapter per topic. No ONCHAINID key or role is escalated; the effect is that topic-level issuer separation is not enforced within one adapter.Consider scoping attester authorization to the topic or the schema, for example keying the allowlist as _isAttesterAllowed[topic][attester] and taking the topic in setAttester, so that trusting an attester for one topic does not authorize it for the rest. If the global allowlist is intended, consider documenting that every allowlisted attester is trusted for every configured topic and recommending a separate adapter instance per topic.Update: Resolved at commit d0b3db3 on PR66.Expired pendingLinks Entries Are Undeletable and Accumulate PermanentlyThe factory stages inbound cross-chain link proposals in pendingLinks inside _processMessage and finalizes them ","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791258186104,"hash":"e5d2770cedad3634df134f4ec0013d83029834c9"}
{"url":"https://ethresear.ch/c/privacy/36","domain":"ethresear.ch","title":"Latest Privacy topics - Ethereum Research","text":"Latest topics in Privacy\n\n Privacy\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Privacy category\n\n 1\n\n 2.3k\n\n Apr 2025\n\n PQ anonymity for Stealth Address Protocol\n\n 4\n\n 208\n\n 5d\n\n Strict role alternation: reciprocal broadcast without relayers for EVM shielded pools (spec + population simulation, no code yet)\n\n 0\n\n 53\n\n 17d\n\n Bloom Filters And Keyed Nonces\n\n stateless\n\n 0\n\n 224\n\n 28d\n\n Privacy and Regulation in our decentralized future\n\n layer-2\n\n 34\n\n 6.2k\n\n Jul 15\n\n EIP8287: Privacy-Native Fungible Token Standard (Draft)\n\n transaction-privacy\n\n 14\n\n 812\n\n Jul 13\n\n A Tor-based Validator Anonymity Approach (incl. comparison to Dandelion)\n\n 10\n\n 4.4k\n\n Jul 6\n\n Sharded PIR Design for the Ethereum State\n\n mev,stateless\n\n 4\n\n 1.2k\n\n Jun 30\n\n Towards Native Post-Quantum Private ETH\n\n transaction-privacy\n\n 7\n\n 489\n\n Jun 29\n\n Wormholes and the cost of plausible deniability\n\n 10\n\n 1.0k\n\n Jun 24\n\n Exploring ownership fragmentation as a privacy primitive for the post-Pectra EVM\n\n 1\n\n 110\n\n Jun 23\n\n # pERC20: Private Token Standard (Draft) - ‘Approve’ extended\n\n transaction-privacy\n\n 0\n\n 157\n\n Jun 21\n\n Etherveil - An Ethereum Privacy Browser\n\n transaction-privacy\n\n 9\n\n 412\n\n Jun 20\n\n Ethereum Privacy: The Road to Self-Sovereignty\n\n transaction-privacy\n\n 20\n\n 5.3k\n\n Jun 16\n\n Physical integrity, attestation, and the state of permissionless TEEs\n\n censorship-resistance\n\n 5\n\n 822\n\n Jun 5\n\n Anonymous Credentials for Trustless Agents (ACTA)\n\n 2\n\n 689\n\n May 20\n\n GPU-Accelerated WHIR Proving on Apple Silicon\n\n 0\n\n 382\n\n Apr 30\n\n Same-Slot Decryption for LUCID: Optional N Execution with N+1 Fallback\n\n 3\n\n 240\n\n Apr 29\n\n Frame Transactions and the Three Gates to Privacy\n\n account-abstraction\n\n 0\n\n 1.1k\n\n Apr 16\n\n Dual-Mode Remint: An EIP-7503 Birthday-Attack Mitigation That Preserves Token Composability\n\n 0\n\n 115\n\n Mar 31\n\n Post-Quantum Threats to Ethereum Privacy\n\n 2\n\n 496\n\n Mar 26\n\n “prove-once, monitor-forever” construction for balance thresholds without revealing the collateral address?\n\n 0\n\n 83\n\n Feb 27\n\n Does FHE deserve this much attention?\n\n 3\n\n 622\n\n Feb 22\n\n Open, Application-Driven FHE for Ethereum\n\n 6\n\n 2.3k\n\n Feb 3\n\n Tracing bad funds through shielded pools\n\n transaction-privacy\n\n 2\n\n 620\n\n Dec 2025\n\n ZK Secret Santa Protocol\n\n 0\n\n 715\n\n Dec 2025\n\n How CREATE2 Prevents Initial Deposit Leakage in Privacy Systems\n\n 4\n\n 212\n\n Nov 2025\n\n Zkzkevm: private evm\n\n 10\n\n 1.4k\n\n Nov 2025\n\n Private Multisig v0.1\n\n 10\n\n 1.2k\n\n Nov 2025\n\n Smart-Contract or EOA Spend Authority for Private Accounts\n\n 0\n\n 292\n\n Nov 2025","tokens":651,"squid":"ink-research","role":"Deep Scholar","at":1791258189139,"hash":"001c6a270cbe57f7883d62db95c50005c8a13302"}
{"url":"https://www.openzeppelin.com/news/openzeppelin-brings-its-security-standard-to-the-tron-network","domain":"openzeppelin.com","title":"OpenZeppelin Brings Its Security Standard to the TRON Network","text":"September 24, 2026OpenZeppelinOpenZeppelin is expanding its smart contract libraries and secure development suite to TRON. Teams can now build on audited foundations and familiar tooling, giving TRON developers instant access to production-grade security out of the box.Building Securely on TRON: The Complete ToolkitDesigned for the TRON network, this release brings together a full suite of audited contracts, deployment plugins, and developer tools. Each piece supports a project’s lifecycle, from writing the first contract to managing live upgrades:Smart Contracts: Audited building blocks for tokens, access control, and upgradeable architecture, available as tron-contracts and tron-contracts-upgradeable.Upgrade plugins: Framework integrations that manage proxy deployments and run the safety checks upgrades depend on, across the three common workflows:Contracts Wizard: An interactive code generator for TRON that bootstraps secure, customized contract boilerplates in seconds.MCP server: Context and tooling support for AI-assisted development workflowWhat OpenZeppelin’s TRON Stack Makes PossibleTRON is broadly Solidity compatible, so much of what works on Ethereum works here too. As TRON updates its network with upgrades like GreatVoyage, this stack keeps pace with tested components built for the latest features.Upgradeable Contracts (UUPS & TRC-1967): Using the UUPS pattern and TRC-1967 proxies, contracts can be deployed and subsequently updated without changing their state or contract address. A step-by-step walkthrough covers this workflow.Passkey Accounts and Web Authentication: The contracts include support for secp256r1 signatures, enabling wallet architectures that use Face ID, fingerprint verification, or hardware keys. Where native network precompiles introduced in recent TRON updates are active, verification utilizes them directly; where precompiles are not yet available, the library safely falls back to standard EVM verification logic.TRC-20 Tokens with Extended Logic: Beyond standard TRC-20 implementations, the library provides audited extensions for gasless approvals, supply caps, and on-chain voting logic.Role-Based Access Control (RBAC) and Governance: Role-based permission systems and multi-signer configurations allow teams to require multiple authorizations or specific administrative roles before executing sensitive contract actions.Getting Started with OpenZeppelin’s Contracts Library on TRONBuild securely on TRON with OpenZeppelin Contracts. You can generate your boilerplate with the Contracts Wizard, and connect the Contracts MCP to scaffold contracts with your AI assistant.FAQsTRON already runs Solidity contracts. Why use a TRON-specific library?TRON is broadly Solidity compatible, but that compatibility arrives in stages, and some EVM features are switched on through network upgrades rather than being there from the start. These contracts and plugins are built and tested against what TRON supports, so teams get audited components matched to the network's current capabilities instead of tracking that themselves.Can passkey sign-in be used now, before TRON enables the native precompile everywhere?Yes. Where a network has the native secp256r1 precompile active, verification uses it directly. Where it is not yet enabled, the library falls back to a Solidity implementation, so passkey-based signatures work either way. As the precompile becomes available more widely, the same code can use the cheaper native path.Are the contracts audited and ready for production?The contracts are audited. As with any deployment, production use still calls for careful dependency review, storage-layout validation, suitable access control or governance, and testing against the specific application.","tokens":940,"squid":"ink-security_audits","role":"Sentinel","at":1791258196022,"hash":"8011d653bc24e9d68c284bad41aa0e7a7fb546ac"}
{"url":"https://io.net/docs/guides/payment/io-intelligence-payments","domain":"io.net","title":"Overview - io.net","text":"At io.net, we believe AI access should be simple, transparent, and scalable. Whether you are experimenting with ideas, running daily creative workflows, or deploying large-scale automation.\nOur platform connects every capability, this includes text, images, code, data, and voice, all in one workspace.\nYou can start free, upgrade as your usage grows, and scale on demand without worrying about token tracking or hidden fees.\nEach plan provides access to the same advanced models and tools. Usage is measured in credits, which refresh automatically. Pay-as-you-go (PAYG) is available when you exceed your daily credits quota.\n\nStandard (default): Explore and learn with free, light daily access. Pay-as-you-go (PAYG) pricing is applied for usage beyond the daily limit.\nProfessional: Includes $15 in monthly usage credits, refreshed daily to provide steady, predictable access for light coding projects and applications.\nDeveloper: Includes $150 in monthly usage credits, refreshed every 8 hours to support continuous development and production workloads.\n\n​Plan Overview\nEach plan includes a fixed daily or hourly allowance that refreshes automatically, so you can focus on your work instead of tracking tokens or costs.\nPlanUsageRefresh cycleIdeal forStandardContinuous access with PAYG.No refreshes, pay only for what you use.Teams that need flexible scaling.Professional$15 in monthly usage credits.Once every 24 hours.Coding projects or light applications.Developer$150 in monthly usage credits.Every 8 hours (3 x per day).Builders, teams, and automations.\n​How Usage Works\n\nProfessional plans refresh once every 24 hours for predictable, worry-free access.\nDeveloper plans refresh every 8 hours, designed for continuous work or API usage.\nIf you hit your allowance, your access will pause until the next refresh, unless you have IO Credits.\nIO Credits (Pay-As-You-Go) allow instant continuation beyond limits, charging per request through your connected payment method.\n\n​More on Pay-As-You-Go\n\nBilled directly to your IO Credits balance.\nIncludes the same tools and models as subscription plans.\nThe Developer plan offers roughly a 10% discount compared to PAYG for consistent high-volume users.\nPAYG stops when your plan refreshes.\nEnables precise accounting of model-level usage and costs.\n\nTo verify the latest model pricing, use the GET /models API endpoint. The response includes detailed pricing information for each available model. The fields \"input_token_price\" and \"output_token_price\" represent the respective costs per token for input and output usage. For implementation details and the full endpoint specification, refer to: GET /models API Documentation.\n​FAQs\nWhat do I do when I hit my daily limit?You can buy IO Credits or wait for your daily limit to refresh.\nIf you already have credits, they will automatically cover additional usage with no interruptions.\nHow does the limit work across different models?IO Intelligence uses a shared credit pool system.\nCredits can be spent on any model, with each consuming credits at a different rate depending on the complexity.\nDoes my daily limit include both Chat and API calls?Yes. Chat interactions count toward your API quota and contribute to your daily limit.Was this page helpful?","tokens":814,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258200590,"hash":"c32a2165faefe8732b6811cbccb6a747f29a6fed"}
{"url":"https://ethresear.ch/t/towards-native-post-quantum-private-eth/25291","domain":"ethresear.ch","title":"Towards Native Post-Quantum Private ETH - Privacy - Ethereum Research","text":"Towards Native Post-Quantum Private ETH \n\n Privacy\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n Jun 24\n\n 1 / 8\n\n Jun 24\n\n Jun 29\n\n post by Pierre on Jun 24\n\n Pierre\n\n Thanks to @winderica, @mmjahanara, Kenny Paterson, Varun Maram and @keewoolee for their valuable suggestions and feedbacks.\nBeyond HNDL\nThe L1 strawmap laid out a path listing L1-native private post-quantum (pq) transfers as a north star. Today, production-deployed privacy solutions rely on elliptic curve-based primitives or on unsatisfactory hardware assumptions. Some argue that, as of now, protecting against harvest-now-decrypt-later (HNDL) attacks is enough for private transfer protocols. However, the deployment of a cryptographically relevant quantum computer means adversaries would be able to carry out undetectable attacks resulting in a catastrophic loss of funds. In that situation, any recovery mechanism (such as turnstiles) will likely require important social layer coordination, provided users’ trust in the protocol isn’t permanently damaged.\nThis post tries to succinctly lay out the kind of cryptographic work we would have to do to enshrine pq privacy in the L1. It is not straightforward: a look at Sapling’s (~620k shielded ZEC, approx $250m in value at today’s price) choices regarding its primitives’ instantiation illustrates why protecting users from HNDL attacks or simply switching proof systems falls short of accurately describing what work is required to deliver pq shielded ETH.\nPreparing for a pq turnstile while using classical cryptographic primitives would not be enough. A turnstile is an inherently reactive, non-retroactive and non-preventive technique that doesn’t fend off an attacker’s ability to destroy the coin’s value. Turnstiles also take time and won’t ever really be completed: it will only be many years later that users can be probabilistically confident that counterfeiting didn’t take place. On top of this, turnstiles greatly impact users by deactivating their ability to transact. They are, all in all, an inherently social-layer defense mechanism, impeding a genuine walk-away from the protocol.\n\nUsage\nPrimitive\nSecurity Requirement\nInstantiation\n\nEncrypting Note Plaintexts\nAsymmetric Encryption\nIND-CCA2 and IK-CCA2\n DHAES\n\nSpend Authorization\nRe-Randomizable Signature\nSURK-CMA\n RedDSA on Jubjub\n\nNon-Inflation (and Non-Malleability)\nSignature with Signing Key to Validating Key Monomorphism\nNon-Adaptive SU-CMA, Key Monomorphic\n RedDSA on Jubjub\n\nCommitting to Notes\nCommitment Scheme\nBinding and Hiding\n Windowed Pedersen Commitments (hiding is ok)\n\nCommitting to Values\nLinearly Homomorphic Commitment Scheme\nBinding and Hiding\n Homomorphic Pedersen Commitments (hiding is ok)\n\nDiversified Addresses\nDiversify Hash\nUnlinkability\n Group Hash Jubjub Curve\n\nProofs\nSNARK\nStatistical Zero-Knowledge (zk), Completeness, Knowledge Soundness\n Groth16 on BLS12-381 (zk is ok)\n\nA non-exhaustive table of ZCash’s Sapling pq readiness. It applies to Orchard, which changed Sapling’s proof system (Halo2, Pasta Curves), key material derivation and nullifiers computation formulas, but is soon to be deprecated.\nIn this post, we will only consider the case of dealing with a quantum adversary. We will evaluate solutions to statelessness compatibility and the verification cost problem in a separate writeup.\nProof Systems\nHash-based proof systems are getting to a point where they are both fast and well-understood. Not leveraging lattice-based ones means that our shielded pool protocol will probably not provide users with the ability to prove their final balance output using snark-friendly lattice-based homomorphism, including the ability to do proof parallelization.\nThis is however fine. Proof parallelization was indeed conceived as a way to overcome join-split statements’ inadequacy for note consolidation or sending to multiple recipients. Today, progress in hash-based SNARKs (WHIR, STIR) offer the ability to prove bigger circuits and depart from a traditional two inputs/outputs setup rendering such proof parallelization strategies less relevant. Thus, a battle-tested join-split zkSNARK statement enforcing checks on notes’ Merkle paths and commitments, input/output values, nullifiers derivation and spend auth signature validity should get us to the core required functionalities, with an on-par UX compared to existing protocols.\nThe instantiation of this statement depends critically on the choice of hash function for nullifiers and note commitments. There are different SNARK-friendly hash candidates to use. Recent research on Poseidon indicates that we should be cautious and would need some more cryptanalysis research to integrate it (see here and here). Other options include using less arithmetization-friendly hashes, such as BLAKE3.\nSecret Distribution\nEncryption\nTransaction detection corresponds to receivers being able to detect public ciphertexts addressed to them. We should make sure that it is DoS-resistant, provides unlinkability, minimizes trust points and remains practical on resource-constrained devices. The main task will be to swap a key agreement (KA) for a key encapsulation mechanism (KEM) (the two differ with how randomness is contributed in the shared key material generation algorithm). Today, the NIST PQC process only standardized KEMs, leaving pq KA aside.\nKyber is our leading KEM candidate. However, until relatively recently, cryptography had to establish its anonymity (aka ANO-CCA, an adversary cannot determine to which recipient an encapsulated key is destined) and that of the PKE scheme derived from it in a pq setting. Kyber initially had a more complex Fujisaki-Okamoto (FO) transform using nested hashing. However, NIST eventually decided to simplify it, easing researcher’s ability to establish its ANO-CCA security. Research eventually showed that one can obtain an ANO-CCA security proof even for nested hashing. All in all, the current NIST standard ML-KEM does provide an anonymous and robust PKE, by composing with an appropriate DEM in the KEM-DEM paradigm.\nOrthogonal but going hand in hand with anonymity, the scheme used for secret distribution also needs to satisfy robustness, making it possible for a party to decide it is the ciphertext’s intended recipient, i.e. providing assurance that trial decryption doesn’t err. This isn’t a natural property. For instance, it was shown that for any plaintext m𝑚, it is possible to build a ciphertext c𝑐 such that c𝑐 decrypts to m𝑚 under any Classic McEliece private key. However, the situation is less dire here, since ML-KEM has been found to be robust.\nNote that this only settles the encryption side of HNDL attacks: a complete defense would require note commitments and nullifiers to be instantiated with quantum secure primitives.\nHybrid Schemes\nHybrid cryptographic schemes combining classical and post-quantum algorithms will most likely be required initially to take a conservative security stance to build the asymmetric encryption scheme used to distribute secrets (likely an “hybrid” public key encryption scheme, here in the sense of combining an asymmetric key exchange protocol and a symmetric encryption scheme). We will have flexibility along a few axes: pure pq vs. hybrid (e.g. combining ML-KEM with a traditional ECDH group), CFRG-defined vs. NIST-defined elliptic curves, different security levels (NIST category 3 vs. category 5). The symmetric encryption part should stay similar to what it is today, although we should evaluate whether we would like to use longer key lengths.\nDecryption\nThere remains, however, the question of privacy-preserving protocols’ decryption trilemma: anonymity, low latency and small bandwidth usage. Switching to pq schemes makes this trilemma even more relevant.\nA north star would remain deploying oblivious message retrieval (OMR) at scale. Such constructions are quantum secure, but clue (i.e. the required on-chain costs) and detection key sizes are already too high to make up a credible L1 candidate. Also, server costs remain the dominant bottleneck even for SOTA constructions, making it unclear how to leverage such techniques in the near term. There is the option to split detection from retrieval using Oblivious Message Detection (OMD, a restricted version of OMR for obliviously retrieving indices) coupled with PIR to fetch payloads. Splitting those two tasks would relieve servers from running OMR’s intensive compute requirement. Still, combining the two wouldn’t reduce the clue size today.\nOne potential avenue would be to leverage fuzzy message detection (FMD) algorithms. They provide a non-negligible improvement over naive scanning, with much lower compute requirements while keeping a small clue size. However, pq versions of FMD require clues with sizes an order of magnitude larger. Also, this overhead comes at the price of only modest probabilistic privacy guarantees, as FMD is also prone to a variety of statistical attacks. Other recent approaches, such as tag-indexing in Aztec or channels in the Starknet privacy layer, sequentially index transactions between two parties using a shared secret, keeping all subsequent exchanges unlinkable. The limitation is that the initialization step requires revealing that Alice intends to interact with Bob.\nNote that there is always the option to fall back on out-of-band channels for sending ciphertexts, which makes it possible to remove them from the transaction entirely.\nSo, in a pq context, there might not be anything better than using trial decryption today. Even in a classical context, most privacy-preserving protocols today use a flavour of trial decryption coupled with authentication tags. To decrease bandwidth costs, ZCash light clients download compactly formatted transactions to synchronize their state using trial-decryption. To provide anonymity, upon detecting intended transactions users are then recommended to insert decoy requests alongside the correct, queried ones. In the case of Ethereum, when coupled with PIR and network anonymity, this path might be the best pq solution for the trilemma today.\nSignatures\nIn the case of a malleable zkSNARK, we might need to require an ephemeral keypair to sign the hash of the transaction, binding it to the zkSNARK statement. The nice thing is that non-adaptive strong-unforgeability under chosen message attack (SU-CMA) security is ok, since the signature is one-time. Also, the binding signature doesn’t require in-circuit verification, such that we can probably use a lattice-based scheme with a much smaller signature size compared to hash-based ones (or even a one-time hash-based signature if we really don’t want to use lattices).\nFor the spending authority scheme, the choice of the signature scheme is constrained by the hardware wallets that must produce these signatures in practice. Some actually proposed to opt for proof knowledge of a pre-image of some hash, sparing us from arithmetizing signatures and deciding which scheme to go with. It is, however, unclear whether tomorrow’s wallet infrastructure will support and standardize proving a recursive pq zkSNARK and whether the particular scheme will be compatible with what’s enshrined on the L1. This would also mean getting rid of all the wallet hardening work that has been done over the years, including the different attack vectors that generating signatures on hardware wallets implies.\nOn statefulness, note that most hardware wallets come with non-volatile memory and are able to support both stateful and stateless signatures. Stateful designs provide shorter signatures and potential optimizations. However, statefulness introduces a handful of problems when the signer isn’t signing at regular, predictable intervals. Users need to back up their keys, but using backups leads to state reuse and enables forgeries.\nThere are a number of stateless, hash-based signature schemes that could be amenable to being snarkified, including research being done for Bitcoin in this regard. One option would be to use SPHINCS+ with a parameter set that offers a small signature verification budget. One particularly interesting parameter set would be to reuse the one that’s being laid out for firmware signing, something that inspired the design of SPHINCS-.\nThere could also be a trick to use many times the key pair of a one-time signature (OTS) scheme. Consider a perfectly hiding zkSNARK. Since the OTS is kept hidden inside the zkSNARK as part of the witness, forging a spend proof reduces to producing a valid OTS on a fresh transaction hash without knowledge of the secret key, which remains hard as long as no OTS is ever exposed outside the circuit. It however implies a different threat model requiring the spend auth signature to never be exposed to protect both privacy and loss of funds.\nKey Material\nIt is possible to design key material using Pseudo Random Functions (PRFs) only. Chosen adequately, such PRFs are quantum secure. This was, for instance, the strategy of Sprout, an early version of the ZCash protocol. Lattice-based primitives might be helpful for re-designing diversified address functionality, although it remains unclear how such a design would work in practice and how compatible it would be with a hash-based proof system.\nHardening\nSince ETH secures billions in value, we avoided discussing exotic primitives enabling things like private shared state. Our rationale for not considering more involved cryptography and functionalities is threefold: we would like to (1) design our protocol with a walkaway in mind, (2) facilitate any downstream formal verification effort and (3) re-use already understood and production deployed primitives securing billions in value today.\nAnother additional guard to consider would also consist in designing a progressive pool uncapping. Defined at the protocol level, that progressive uncapping would consist in gradually increasing deposit amounts to minimize catastrophic size losses in the early days of the enshrined pool’s life.\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n post by 71104 on Jun 24\n\n post by Pierre on Jun 25\n\n post by 71104 on Jun 25\n\n post by Pierre on Jun 25\n\n post by 71104 on Jun 25\n\n post by rdubois-crypto on Jun 26\n\n post by Pierre on Jun 29\n\n Powered by Discourse","tokens":3580,"squid":"ink-research","role":"Deep Scholar","at":1791258200640,"hash":"05f84b8a8c81defca9a12c2877875cc97a5d6e15"}
{"url":"https://www.openzeppelin.com/news/tron-foundation-library-and-upgradeable-contracts-audit","domain":"openzeppelin.com","title":"TRON Foundation Library and Upgradeable Contracts Audit","text":"September 17, 2026OpenZeppelin SecuritySummaryType: LibraryTimeline: 2026-07-02 → 2026-07-22Languages: SolidityFindingsTotal issues: 11 (11 resolved)Critical: 0 (0 resolved) · High: 2 (2 resolved) · Medium: 1 (1 resolved) · Low: 3 (3 resolved)Notes & Additional Information5 notes raised (5 resolved)Client Reported Issues0 reported issues (0 resolved)ScopeOpenZeppelin audited three repositories. The first two make up the TRON port of the OpenZeppelin Contracts library, and the third is the TRON adaptation of the Open Intents Framework settlement contracts:the OpenZeppelin/tron-contracts repository at commit 06d69bc,the OpenZeppelin/tron-contracts-upgradeable repository at commit f66f953the openintentsframework/oif-contracts repository at commit 39df288.For the two OpenZeppelin libraries, in scope were all Solidity sources under the contracts/ directory, excluding the mock and test helpers under contracts/mocks/. The two libraries share the same module layout; the upgradeable repository provides the upgradeable variants of the same standards and therefore omits the proxy and interface modules that only the non-upgradeable library ships. For the Open Intents Framework repository, in scope were the TRON-specific input-settlement contracts. The complete in-scope file lists are given below.The in-scope files of tron-contracts (216 files) were the following:└── contracts\n ├── access\n │ ├── AccessControl.sol\n │ ├── IAccessControl.sol\n │ ├── Ownable.sol\n │ ├── Ownable2Step.sol\n │ ├── extensions\n │ │ ├── AccessControlDefaultAdminRules.sol\n │ │ ├── AccessControlEnumerable.sol\n │ │ ├── IAccessControlDefaultAdminRules.sol\n │ │ └── IAccessControlEnumerable.sol\n │ └── manager\n │ ├── AccessManaged.sol\n │ ├── AccessManager.sol\n │ ├── AuthorityUtils.sol\n │ ├── IAccessManaged.sol\n │ ├── IAccessManager.sol\n │ └── IAuthority.sol\n ├── crosschain\n │ ├── CrosschainLinked.sol\n │ ├── TRC7786Recipient.sol\n │ └── bridges\n │ ├── BridgeTRC20.sol\n │ ├── BridgeTRC7802.sol\n │ └── abstract\n │ └── BridgeFungible.sol\n ├── finance\n │ ├── VestingWallet.sol\n │ └── VestingWalletCliff.sol\n ├── governance\n │ ├── Governor.sol\n │ ├── IGovernor.sol\n │ ├── TimelockController.sol\n │ ├── extensions\n │ │ ├── GovernorCountingFractional.sol\n │ │ ├── GovernorCountingOverridable.sol\n │ │ ├── GovernorCountingSimple.sol\n │ │ ├── GovernorNoncesKeyed.sol\n │ │ ├── GovernorPreventLateQuorum.sol\n │ │ ├── GovernorProposalGuardian.sol\n │ │ ├── GovernorSequentialProposalId.sol\n │ │ ├── GovernorSettings.sol\n │ │ ├── GovernorStorage.sol\n │ │ ├── GovernorSuperQuorum.sol\n │ │ ├── GovernorTimelockAccess.sol\n │ │ ├── GovernorTimelockCompound.sol\n │ │ ├── GovernorTimelockControl.sol\n │ │ ├── GovernorVotes.sol\n │ │ ├── GovernorVotesQuorumFraction.sol\n │ │ └── GovernorVotesSuperQuorumFraction.sol\n │ └── utils\n │ ├── IVotes.sol\n │ ├── Votes.sol\n │ └── VotesExtended.sol\n ├── interfaces\n │ ├── ITRC1155.sol\n │ ├── ITRC1155MetadataURI.sol\n │ ├── ITRC1155Receiver.sol\n │ ├── ITRC1271.sol\n │ ├── ITRC1363.sol\n │ ├── ITRC1363Receiver.sol\n │ ├── ITRC1363Spender.sol\n │ ├── ITRC165.sol\n │ ├── ITRC1820Implementer.sol\n │ ├── ITRC1820Registry.sol\n │ ├── ITRC1967.sol\n │ ├── ITRC20.sol\n │ ├── ITRC20Metadata.sol\n │ ├── ITRC2309.sol\n │ ├── ITRC2612.sol\n │ ├── ITRC2981.sol\n │ ├── ITRC3156.sol\n │ ├── ITRC3156FlashBorrower.sol\n │ ├── ITRC3156FlashLender.sol\n │ ├── ITRC4626.sol\n │ ├── ITRC4906.sol\n │ ├── ITRC5267.sol\n │ ├── ITRC5313.sol\n │ ├── ITRC5805.sol\n │ ├── ITRC6372.sol\n │ ├── ITRC6909.sol\n │ ├── ITRC721.sol\n │ ├── ITRC721Enumerable.sol\n │ ├── ITRC721Metadata.sol\n │ ├── ITRC721Receiver.sol\n │ ├── ITRC7751.sol\n │ ├── ITRC777.sol\n │ ├── ITRC777Recipient.sol\n │ ├── ITRC777Sender.sol\n │ ├── ITRC7913.sol\n │ ├── draft-IERC6093.sol\n │ ├── draft-ITRC1822.sol\n │ ├── draft-ITRC7674.sol\n │ ├── draft-ITRC7786.sol\n │ └── draft-ITRC7802.sol\n ├── metatx\n │ ├── TRC2771Context.sol\n │ └── TRC2771Forwarder.sol\n ├── proxy\n │ ├── Clones.sol\n │ ├── Proxy.sol\n │ ├── TRC1967\n │ │ ├── TRC1967Proxy.sol\n │ │ └── TRC1967Utils.sol\n │ ├── beacon\n │ │ ├── BeaconProxy.sol\n │ │ ├── IBeacon.sol\n │ │ └── UpgradeableBeacon.sol\n │ ├── transparent\n │ │ ├── ProxyAdmin.sol\n │ │ └── TransparentUpgradeableProxy.sol\n │ └── utils\n │ ├── Initializable.sol\n │ └── UUPSUpgradeable.sol\n ├── token\n │ ├── TRC1155\n │ │ ├── ITRC1155.sol\n │ │ ├── ITRC1155Receiver.sol\n │ │ ├── TRC1155.sol\n │ │ ├── extensions\n │ │ │ ├── ITRC1155MetadataURI.sol\n │ │ │ ├── TRC1155Burnable.sol\n │ │ │ ├── TRC1155Pausable.sol\n │ │ │ ├── TRC1155Supply.sol\n │ │ │ └── TRC1155URIStorage.sol\n │ │ └── utils\n │ │ ├── TRC1155Holder.sol\n │ │ └── TRC1155Utils.sol\n │ ├── TRC20\n │ │ ├── ITRC20.sol\n │ │ ├── TRC20.sol\n │ │ ├── extensions\n │ │ │ ├── ITRC20Metadata.sol\n │ │ │ ├── ITRC20Permit.sol\n │ │ │ ├── TRC1363.sol\n │ │ │ ├── TRC20Burnable.sol\n │ │ │ ├── TRC20Capped.sol\n │ │ │ ├── TRC20Crosschain.sol\n │ │ │ ├── TRC20FlashMint.sol\n │ │ │ ├── TRC20Pausable.sol\n │ │ │ ├── TRC20Permit.sol\n │ │ │ ├── TRC20Votes.sol\n │ │ │ ├── TRC20Wrapper.sol\n │ │ │ ├── TRC4626.sol\n │ │ │ ├── draft-TRC20Bridgeable.sol\n │ │ │ └── draft-TRC20TemporaryApproval.sol\n │ │ └── utils\n │ │ ├── SafeTRC20.sol\n │ │ └── TRC1363Utils.sol\n │ ├── TRC6909\n │ │ ├── TRC6909.sol\n │ │ └── extensions\n │ │ ├── TRC6909ContentURI.sol\n │ │ ├── TRC6909Metadata.sol\n │ │ └── TRC6909TokenSupply.sol\n │ ├── TRC721\n │ │ ├── ITRC721.sol\n │ │ ├── ITRC721Receiver.sol\n │ │ ├── TRC721.sol\n │ │ ├── extensions\n │ │ │ ├── ITRC721Enumerable.sol\n │ │ │ ├── ITRC721Metadata.sol\n │ │ │ ├── TRC721Burnable.sol\n │ │ │ ├── TRC721Consecutive.sol\n │ │ │ ├── TRC721Enumerable.sol\n │ │ │ ├── TRC721Pausable.sol\n │ │ │ ├── TRC721Royalty.sol\n │ │ │ ├── TRC721URIStorage.sol\n │ │ │ ├── TRC721Votes.sol\n │ │ │ └── TRC721Wrapper.sol\n │ │ └── utils\n │ │ ├── TRC721Holder.sol\n │ │ └── TRC721Utils.sol\n │ └── common\n │ └── TRC2981.sol\n ├── utils\n │ ├── Address.sol\n │ ├── Arrays.sol\n │ ├── Base58.sol\n │ ├── Base64.sol\n │ ├── Blockhash.sol\n │ ├── Bytes.sol\n │ ├── CAIP10.sol\n │ ├── CAIP2.sol\n │ ├── Calldata.sol\n │ ├── Comparators.sol\n │ ├── Context.sol\n │ ├── Create2.sol\n │ ├── Errors.sol\n │ ├── LowLevelCall.sol\n │ ├── Memory.sol\n │ ├── Multicall.sol\n │ ├── Nonces.sol\n │ ├── NoncesKeyed.sol\n │ ├── Packing.sol\n │ ├── Panic.sol\n │ ├── Pausable.sol\n │ ├── RLP.sol\n │ ├── ReentrancyGuard.sol\n │ ├── ReentrancyGuardTransient.sol\n │ ├── RelayedCall.sol\n │ ├── ShortStrings.sol\n │ ├── SlotDerivation.sol\n │ ├── StorageSlot.sol\n │ ├── Strings.sol\n │ ├── TransientSlot.sol\n │ ├── cryptography\n │ │ ├── ECDSA.sol\n │ │ ├── Hashes.sol\n │ │ ├── MerkleProof.sol\n │ │ ├── MessageHashUtils.sol\n │ │ ├── P256.sol\n │ │ ├── RSA.sol\n │ │ ├── SignatureChecker.sol\n │ │ ├── TIP712.sol\n │ │ ├── TrieProof.sol\n │ │ ├── WebAuthn.sol\n │ │ ├── draft-TRC7739Utils.sol\n │ │ ├── signers\n │ │ │ ├── AbstractSigner.sol\n │ │ │ ├── MultiSignerTRC7913.sol\n │ │ │ ├── MultiSignerTRC7913Weighted.sol\n │ │ │ ├── SignerECDSA.sol\n │ │ │ ├── SignerEIP7702.sol\n │ │ │ ├── SignerP256.sol\n │ │ │ ├── SignerRSA.sol\n │ │ │ ├── SignerTRC7913.sol\n │ │ │ ├── SignerWebAuthn.sol\n │ │ │ └── draft-TRC7739.sol\n │ │ └── verifiers\n │ │ ├── TRC7913P256Verifier.sol\n │ │ ├── TRC7913RSAVerifier.sol\n │ │ └── TRC7913WebAuthnVerifier.sol\n │ ├── draft-InteroperableAddress.sol\n │ ├── introspection\n │ │ ├── ITRC165.sol\n │ │ ├── TRC165.sol\n │ │ └── TRC165Checker.sol\n │ ├── math\n │ │ ├── Math.sol\n │ │ ├── SafeCast.sol\n │ │ └── SignedMath.sol\n │ ├── structs\n │ │ ├── Accumulators.sol\n │ │ ├── BitMaps.sol\n │ │ ├── Checkpoints.sol\n │ │ ├── CircularBuffer.sol\n │ │ ├── DoubleEndedQueue.sol\n │ │ ├── EnumerableMap.sol\n │ │ ├── EnumerableSet.sol\n │ │ ├── Heap.sol\n │ │ └── MerkleTree.sol\n │ └── types\n │ └── Time.sol\n └── vendor\n └── compound\n └── ICompoundTimelock.solThe in-scope files of tron-contracts-upgradeable (84 files) were the following:└── contracts\n ├── access\n │ ├── AccessControlUpgradeable.sol\n │ ├── Ownable2StepUpgradeable.sol\n │ ├── OwnableUpgradeable.sol\n │ ├── extensions\n │ │ ├── AccessControlDefaultAdminRulesUpgradeable.sol\n │ │ └── AccessControlEnumerableUpgradeable.sol\n │ └── manager\n │ ├── AccessManagedUpgradeable.sol\n │ └── AccessManagerUpgradeable.sol\n ├── crosschain\n │ ├── CrosschainLinkedUpgradeable.sol\n │ └── bridges\n │ ├── BridgeTRC20Upgradeable.sol\n │ ├── BridgeTRC7802Upgradeable.sol\n │ └── abstract\n │ └── BridgeFungibleUpgradeable.sol\n ├── finance\n │ ├── VestingWalletCliffUpgradeable.sol\n │ └── VestingWalletUpgradeable.sol\n ├── governance\n │ ├── GovernorUpgradeable.sol\n │ ├── TimelockControllerUpgradeable.sol\n │ ├── extensions\n │ │ ├── GovernorCountingFractionalUpgradeable.sol\n │ │ ├── GovernorCountingOverridableUpgradeable.sol\n │ │ ├── GovernorCountingSimpleUpgradeable.sol\n │ │ ├── GovernorNoncesKeyedUpgradeable.sol\n │ │ ├── GovernorPreventLateQuorumUpgradeable.sol\n │ │ ├── GovernorProposalGuardianUpgradeable.sol\n │ │ ├── GovernorSequentialProposalIdUpgradeable.sol\n │ │ ├── GovernorSettingsUpgradeable.sol\n │ │ ├── GovernorStorageUpgradeable.sol\n │ │ ├── GovernorSuperQuorumUpgradeable.sol\n │ │ ├── GovernorTimelockAccessUpgradeable.sol\n │ │ ├── GovernorTimelockCompoundUpgradeable.sol\n │ │ ├── GovernorTimelockControlUpgradeable.sol\n │ │ ├── GovernorVotesQuorumFractionUpgradeable.sol\n │ │ ├── GovernorVotesSuperQuorumFractionUpgradeable.sol\n │ │ └── GovernorVotesUpgradeable.sol\n │ └── utils\n │ ├── VotesExtendedUpgradeable.sol\n │ └── VotesUpgradeable.sol\n ├── metatx\n │ ├── TRC2771ContextUpgradeable.sol\n │ └── TRC2771ForwarderUpgradeable.sol\n ├── proxy\n │ └── utils\n │ ├── Initializable.sol\n │ └── UUPSUpgradeable.sol\n ├── token\n │ ├── TRC1155\n │ │ ├── TRC1155Upgradeable.sol\n │ │ └── extensions\n │ │ ├── TRC1155BurnableUpgradeable.sol\n │ │ ├── TRC1155PausableUpgradeable.sol\n │ │ ├── TRC1155SupplyUpgradeable.sol\n │ │ └── TRC1155URIStorageUpgradeable.sol\n │ ├── TRC20\n │ │ ├── TRC20Upgradeable.sol\n │ │ └── extensions\n │ │ ├── TRC1363Upgradeable.sol\n │ │ ├── TRC20BurnableUpgradeable.sol\n │ │ ├── TRC20CappedUpgradeable.sol\n │ │ ├── TRC20CrosschainUpgradeable.sol\n │ │ ├── TRC20FlashMintUpgradeable.sol\n │ │ ├── TRC20PausableUpgradeable.sol\n │ │ ├── TRC20PermitUpgradeable.sol\n │ │ ├── TRC20VotesUpgradeable.sol\n │ │ ├── TRC20WrapperUpgradeable.sol\n │ │ ├── TRC4626Upgradeable.sol\n │ │ ├── draft-TRC20BridgeableUpgradeable.sol\n │ │ └── draft-TRC20TemporaryApprovalUpgradeable.sol\n │ ├── TRC6909\n │ │ ├── TRC6909Upgradeable.sol\n │ │ └── extensions\n │ │ ├── TRC6909ContentURIUpgradeable.sol\n │ │ ├── TRC6909MetadataUpgradeable.sol\n │ │ └── TRC6909TokenSupplyUpgradeable.sol\n │ ├── TRC721\n │ │ ├── TRC721Upgradeable.sol\n │ │ └── extensions\n │ │ ├── TRC721BurnableUpgradeable.sol\n │ │ ├── TRC721ConsecutiveUpgradeable.sol\n │ │ ├── TRC721EnumerableUpgradeable.sol\n │ │ ├── TRC721PausableUpgradeable.sol\n │ │ ├── TRC721RoyaltyUpgradeable.sol\n │ │ ├── TRC721URIStorageUpgradeable.sol\n │ │ ├── TRC721VotesUpgradeable.sol\n │ │ └── TRC721WrapperUpgradeable.sol\n │ └── common\n │ └── TRC2981Upgradeable.sol\n └── utils\n ├── ContextUpgradeable.sol\n ├── MulticallUpgradeable.sol\n ├── NoncesKeyedUpgradeable.sol\n ├── NoncesUpgradeable.sol\n ├── PausableUpgradeable.sol\n ├── cryptography\n │ ├── TIP712Upgradeable.sol\n │ └── signers\n │ ├── MultiSignerTRC7913Upgradeable.sol\n │ ├── MultiSignerTRC7913WeightedUpgradeable.sol\n │ ├── SignerECDSAUpgradeable.sol\n │ ├── SignerP256Upgradeable.sol\n │ ├── SignerRSAUpgradeable.sol\n │ ├── SignerTRC7913Upgradeable.sol\n │ ├── SignerWebAuthnUpgradeable.sol\n │ └── draft-TRC7739Upgradeable.sol\n └── introspection\n └── TRC165Upgradeable.solThe in-scope files of oif-contracts (TRON settlement adaptation) were the following:└── src\n └── input\n └── escrow\n ├── InputSettlerEscrow.sol\n ├── InputSettlerEscrowTron.sol\n └── Permit2WitnessType.solUpdate: The fixes for the findings highlighted in this report have all been merged at commit d260982 for tron-contracts and at commit 8e38b9b for oif-contracts.System OverviewThe two repositories in scope are a port of OpenZeppelin Contracts v5.6.1 to the TRON Virtual Machine (TVM). They are general-purpose libraries of reusable building blocks: the fungible (TRC-20 / ERC-20), non-fungible (TRC-721 / ERC-721), multi-token (TRC-1155 / ERC-1155), and minimal multi-token (ERC-6909) standards and their extensions, access control, governance, cryptography and signature utilities, proxies, meta-transactions (TRC-2771 / ERC-2771), crosschain bridges, and finance helpers, rather than a deployed protocol. Downstream projects inherit and compose these contracts, so the security-relevant surface is the correctness of each component together with the points at which TVM execution differs from the EVM.The tron-contracts repository is the standard library. The tron-contracts-upgradeable repository is the upgradeable variant of the same sources, generated for use behind proxies: its contracts use the initializer pattern in place of constructors and store state in namespaced storage locations (TIP-7201 / ERC-7201) to remain upgrade-safe. Both libraries rename the standards that TRON publishes under its own TIP identifiers (for example ERC20 to TRC20, EIP712 to TIP712), and dual-cite the TRON (TIP / TRC) and Ethereum (EIP / ERC) specifications where both exist. Several standards map to a ratified TIP, including the permit extension (TIP-2612 / ERC-2612), the payable token (TIP-1363 / ERC-1363), the tokenized vault (TIP-4626 / ERC-4626), flash loans (TIP-3156 / ERC-3156), interface detection (TIP-165 / ERC-165), contract signature validation (TIP-1271 / ERC-1271), proxy storage slots (TIP-1967 / ERC-1967), and the minimal proxy (TIP-1167 / ERC-1167). Others have no TIP yet, such as ERC-6909, the ERC-7913 signature verifiers, and the ERC-7786 and ERC-7802 crosschain interfaces.The port adapts the parts of the library where the TVM behaves differently from the EVM. The most security-relevant adaptations are the CREATE2 address derivation, which uses TRON's 0x41 prefix (TIP-26) instead of the EVM 0xff (EIP-1014); the typed-data (TIP-712 / EIP-712) domain separator, which binds to the four-byte chain identifier that TRON exposes through eth_chainId (TIP-474); the signed-message prefix in MessageHashUtils, which uses the TRON string (TIP-191 / TIP-104) rather than the ERC-191 one; the TRC-721 receiver callback, which TRON specifies with a distinct magic value; the secp256r1 (P256) verification (TIP-7951 / EIP-7951), which is performed in pure Solidity because no native precompile is active on the TVM; and a dedicated SafeTRC20 transfer helper for TRON USDT, whose transfer returns false even on a successful transfer. The EIP-7702 account-abstraction module present upstream is not included in either repository, since TRON provides multi-signature and permission features at the account level (TIP-16 / TIP-105).The oif-contracts repository is the Open Intents Framework, a cross-chain intent settlement system in which a user locks input tokens in an escrow on a source chain so that a filler can satisfy the intent on a destination chain. In scope is its TRON adaptation, InputSettlerEscrowTron, which extends the framework's InputSettlerEscrow to run on the TVM and vendors the tron-contracts library as a dependency. The adaptation routes token payouts through SafeTRC20 so that settlement works with TRON USDT. It also relies on the Permit2 contract for the sponsored openFor collection path. Because TRON derives CREATE2 addresses with the 0x41 prefix, Permit2 is deployed at a different address on TRON than on Ethereum, so the framework's Permit2 address hook must resolve to the TRON deployment.Security Model and Trust AssumptionsBecause the repositories in scope are libraries rather than a deployed system, their security depends on how integrators configure and compose them and on the execution semantics of the target TRON network. This section records the trust assumptions relied upon during the review. Any finding whose impact depends on one of these assumptions being violated is out of scope unless an integrator or unprivileged actor could plausibly breach it.Privileged RolesThe libraries define no global privileged role of their own.They provide the access-control and governance primitives (Ownable, Ownable2Step, AccessControl, AccessManager, Governor, and TimelockController) that integrators configure for their own deployments. The trust placed in owners, administrators, proposers, and executors is determined entirely by that configuration.The upgrade authority of an upgradeable deployment is fully trusted.For contracts deployed behind a proxy, the proxy administrator (for transparent and beacon proxies) or the account authorized by _authorizeUpgrade (for UUPS proxies) can replace the implementation and therefore the entire behavior of the contract.Trust AssumptionsThe codebase is treated as a direct port of OpenZeppelin Contracts v5.6.1.No TRON-specific functionality, such as native voting or staking opcodes, is expected beyond the adaptations required to run on the TVM, and the majority of the difference from upstream is renaming rather than logic changes. Where behavior is unchanged from upstream, the corresponding upstream security properties are relied upon and are not re-derived.A TRC name is not taken to imply a ratified TRON standard.Where a renamed standard maps to an existing TIP, its implementation is expected to conform to that TIP, and any deviation is reported. Where no TIP exists, mirroring the Ethereum standard is considered acceptable and is not treated as a deviation. A TRC-named artifact is therefore not taken to correspond to a published TRON standard.TRC-10 tokens are treated as unsupported.The contracts implement no TRC-10 handling, and TRC-10 assets are not expected to be routed through them. The review still considers whether a TRC-10 balance held by an in-scope contract could be used to create an unfavorable scenario, for example through an arbitrary call executed by a governance or timelock contract.TRC-20 token decimals default to 18.The default decimals() for the TRC-20 implementation is 18 rather than TRON's native six, and is expected to be overridden where a different precision is required. Integrations pairing these tokens with six-decimal assets are expected to account for the difference.Tokens that return false on a successful transfer are handled only by the dedicated helper.TRON USDT returns false from transfer even when the transfer succeeds. Only SafeTRC20.safeTransferUSDT, which verifies success via balance change rather than the return value, is relied upon for such tokens; flows that use the ordinary safeTransfer are not expected to be configured with them. Fee-on-transfer and rebasing tokens are treated as unsupported, as in the upstream library.secp256r1 (P256) verification is performed in Solidity, without a precompile.No P256 precompile (TIP-7951 / EIP-7951) is active on the TVM, so verification is routed through Solidity while the function signatures are kept unchanged. The computation is more expensive than a precompile and is bounded by TRON's per-transaction execution limits.The energy model differs from the EVM gas model.Gas-forwarding components, in particular the TRC2771Forwarder and the authority-based access paths, depend on gas-forwarding behavior that differs on TRON, where execution is metered as energy and the gas-limit and gas-price semantics are not identical to the EVM. Integrations relying on gas-limited sub-calls are relied upon to validate the behavior on TRON.Crosschain message delivery is delegated to a trusted external gateway.The crosschain bridges delegate message delivery and replay protection to an external gateway, which is trusted to deliver each message at most once and to attribute the source chain and counterpart correctly.The Open Intents Framework settlement relies on an external Permit2 deployment and off-chain actors.The TRON settlement contracts depend on an external Permit2 deployment for the sponsored input-collection path, expected to be configured with the correct TRON Permit2 address, and on off-chain fillers and solvers to satisfy intents. The on-chain guarantees concern only the custody and release of escrowed inputs.Additional ConsiderationsDeterministic deployment uses TRON's address derivation.The Create2, Clones, and relayer helpers derive addresses with TRON's 0x41 CREATE2 prefix (TIP-26) rather than the EVM 0xff (EIP-1014). Off-chain tooling and any counterfactual-address computation must use the same derivation to obtain correct addresses.The libraries assume the target network's TVM feature gates are active.Behavior that depends on a feature gate, such as transient storage (TIP-650 / EIP-1153) and the optimized chain-identifier return value (TIP-474), must be confirmed against the target network, and deployments must target an EVM version the network accepts.High SeverityTRC4626 And VestingWallet Cannot Release USDT Due To False-On-Success TransfersBoth withdraw and redeem in TRC4626 pay the underlying asset out through a single internal function, _transferOut, which calls SafeTRC20.safeTransfer. That helper only accepts a transfer as successful when the token returns true or returns nothing at all.On TRON, the USDT contract returns false from a transfer that has actually succeeded. safeTransfer reads that false return value, concludes the transfer failed, and reverts with SafeTRC20FailedOperation. Deposits are not affected, since _transferIn pulls assets in with safeTransferFrom and USDT does return true from transferFrom. The port already encountered this behavior and added safeTransferUSDT to deal with it, using it on the bridge release path in _onReceive, but the same change was never carried over to the vault.This means that when the underlying is USDT, users can deposit and mint, but every withdraw and redeem reverts, so the shares can never be redeemed.The same oversight is present in VestingWallet. Its only way to pay out a vested TRC-20 balance, release, also calls SafeTRC20.safeTransfer, so a wallet funded with USDT accepts the deposit but can never release it. The contract has no rescue function and is not upgradeable; transferring ownership does not help because the new owner reaches the same reverting call.Consider paying the underlying out through safeTransferUSDT (or another transfer helper that confirms success from the resulting balance change) on the TRC4626 withdrawal path, matching what BridgeTRC20 already does. Additionally, consider applying the same fix to VestingWallet.Update: Resolved in pull request #131. The team stated:TRC4626._transferOut, VestingWallet.release and TRC20Wrapper.withdrawTo now pay out through SafeTRC20.safeTransferChecked, which confirms success from the caller's balance delta rather than the returned boolean.TRC20Wrapper.withdrawTo isn't listed in the finding but has the same defect — its underlying was trapped behind the wrapper. Fixed alongside.We made the checked transfer the default rather than a per-token exception, renaming safeTransferUSDT to safeTransferChecked: these contracts can't know at deployment time which token they hold, so gating on a configured USDT address would leave every other false-on-success token broken.The use of safeTransferUSDT was updated to safeTransferChecked on OIF at the PR: #195Audited Contracts Inherit Issues From Upstream OpenZeppelin ContractsThe audited contracts are generated from the tron-contracts repository by the OpenZeppelin Upgradeability Transpiler, and tron-contracts is in turn based on OpenZeppelin Contracts v5.6.1. Several in-scope issues do not originate from EVM-to-TVM differences or from the transpilation, but are inherited from the upstream codebase. Most were resolved upstream after the v5.6.1 release and are scheduled for the 5.7 release, so the fixes are absent at the audited commit. In particular:The baseDelaySeconds delay of GovernorTimelockAccessUpgradeable can be bypassed by executing a proposal without queuing it. The execute function accepts proposals in both the Succeeded and Queued states, but etaSeconds is recorded only when queue is called. A proposal executed directly from the Succeeded state therefore has a proposalEta of 0, the block.timestamp < etaSeconds check passes trivially, and the post-vote reaction window is skipped for operations that do not require prior scheduling. Resolved upstream in PR #6386, with a follow-up in PR #6582.The atomic mode of TRC2771ForwarderUpgradeable does not provide all-or-nothing execution (#30). When refundReceiver is the zero address, executeBatch reverts only on invalid requests. A valid request whose target call reverts does not abort the batch: its nonce is consumed, earlier calls remain committed, and the failed request's value is refunded through Address.sendValue to the zero address, permanently locking the corresponding TRX. Resolved upstream in PR #6391.The per-target admin delay of AccessManagerUpgradeable can be bypassed when changing a managed contract's authority, since setAuthority can be scheduled and invoked through the execute path, which does not apply the admin delay enforced on updateAuthority. Resolved upstream in PR #6388.The burn and burnBatch functions of TRC1155BurnableUpgradeable perform an inline isApprovedForAll check instead of calling the virtual _checkAuthorized function, so authorization overrides that apply to transfers are silently bypassed for burns. Resolved upstream in PR #6435.The NatSpec of the _mintConsecutive function of TRC721ConsecutiveUpgradeable states that a batchSize of 0 returns the number of consecutive IDs minted so far, whereas the function returns the next consecutive token ID, which differs from that count whenever _firstConsecutiveId is overridden to a nonzero value. This documentation error was resolved upstream in PR #6433.The late-quorum protection of GovernorPreventLateQuorumUpgradeable can be bypassed when it is combined with GovernorCountingOverridableUpgradeable (#24). The _tallyUpdated function records an extended deadline only on the first quorum crossing, while quorum is counted as the sum of For and Abstain votes and an override vote can later move weight out of those tallies. If quorum is reached early, lost through an override, and restored immediately before the original deadline, no extension is granted and the configured reaction period is bypassed. This issue is also present upstream and has no upstream fix at the time of writing.Consider backporting the referenced upstream fixes to the tron-contracts codebase, or updating the fork to version 5.7 of OpenZeppelin Contracts once it is published. Furthermore, consider reporting the late-quorum bypass upstream and addressing it in both codebases by tracking the quorum state separately from the stored extended deadline and reacting to every false-to-true quorum transition.The items above are not necessarily exhaustive. It is advisable to review the full set of changes in the 5.7 release candidate for any further upstream fixes affecting in-scope contracts that are not yet present at the audited commit.Update: Resolved at pull request #119, #120, #121, #122, #123, #136, #137 and #141. The team stated:We forked upstream at #6372 and reviewed all 58 subsequent commits touching contracts/. The applicable fixes are ported: #6386/#6582 (our #119), #6388→#6636 / L-12 (#120), #6391→#6415 / H-04 (#121), #6435/L-52(#122), #6433/N-32(#123), #6654(#136), #6644/M-03 + #6681 (#137), #6573/M-01(#141). H-02 (#6618) needed no change — our tree already rejects the malformed case through an equivalent guard — and M-20 (#6643) does not apply, since we ship only BridgeFungible.Seven upstream fixes remain unported: #6642 (M-08), #6646 (L-08), #6638, #6635, #6418. Since those don't carry funds at risk or major issues, so they were scheduled for the 5.7 sync. This way we can keep both tron-contracts and openzeppelin-contracts up-to-date.Medium SeverityInputSettlerEscrowTron Uses Ethereum Permit2 Address, Breaking openFor on TRONThe InputSettlerEscrow contract escrows inputs through two paths: the direct open, which pulls tokens via safeTransferFrom, and the sponsored openFor, which pulls a user's signed inputs through Permit2 at the address returned by _PERMIT2. That getter is virtual and defaults to the canonical Permit2 address 0x000000000022D473030F116dDEE9F6B43aC78BA3. Its documentation states that it must be overridden on chains where Permit2 lives elsewhere, and names TRON, whose CREATE2 derivation differs.However, InputSettlerEscrowTron overrides only the payout hook _transfer and leaves _PERMIT2 at the canonical address. Because TRON derives CREATE2 addresses with the 0x41 prefix, Permit2 is not deployed at that canonical address on TRON. Therefore, the Permit2 call transfers no inputs, so the sponsored openFor path cannot escrow funds on TRON. Although the override that resolves this was already introduced for TRON and is covered by a dedicated test, it was not applied to the settler intended for TRON deployment.Consider overriding _PERMIT2 in InputSettlerEscrowTron to return the Permit2 address on TRON. Alternatively, if openFor is not intended to be supported on TRON, consider documenting that limitation and removing the unused Permit2 path.Update: Resolved in pull request #190. The team stated:The issue is solved by overriding the _PERMIT2() internal function on InputSettlerEscrowTron.sol to return the real deployment on Tron Mainnnet.Low SeverityTRC20FlashMint Rejects TIP-3156-Compliant Flash BorrowersThe flashLoan function of TRC20FlashMint mints the requested tokens to the receiver, invokes its onFlashLoan callback, and requires the callback to return a fixed magic value confirming that the receiver is a willing flash borrower. This magic value is the RETURN_VALUE constant, which is computed as keccak256(\"ERC3156FlashBorrower.onFlashLoan\"), the Ethereum preimage carried over from upstream. However, TIP-3156, the TRON counterpart the port targets, requires borrowers to return keccak256(\"TRC3156FlashBorrower.onFlashLoan\") instead. As a result, a TIP-3156-compliant borrower returns a value that never matches RETURN_VALUE, so flashLoan reverts with TRC3156InvalidReceiver, and the feature remains interoperable only with ERC-3156-style borrowers rather than the TRON-native borrowers it is meant to serve.Consider deriving the return value from \"TRC3156FlashBorrower.onFlashLoan\" and updating the ITRC3156FlashBorrower documentation, confirming the value against the formal specification since TIP-3156 is in Last Call.Update: Resolved in pull request #114. The team stated:We have changed the return value and documentation to follow TIP 3156.Documentation Cites Ethereum ERC/EIP Names for Standards Renamed to TRON IdentifiersThe library renames the standards it implements to their TRON identifiers such as TRC20, TRC1155, and TIP712, and in most places documents them under the TRON name. In a number of files, however, the documentation still refers to a renamed standard only by its Ethereum name, even though the port cites the TRON equivalent elsewhere. These references are documentary and do not affect on-chain behavior, but they contradict the naming the port adopts everywhere else.The following instances were identified:The proxy README describes storage slots as \"ERC-1967\" and titles a section == ERC-1967, while the port ships ITRC1967.IGovernor refers to the \"EIP-712 domain separator\", although the port renames EIP-712 to TIP-712 and cites TIP-712 throughout the rest of the codebase.The cryptography README mentions \"ERC-1271 signatures\", while the port ships ITRC1271.The utils README mentions \"ERC-7201 namespaces\", which should be TIP-7201.MessageHashUtils points to \"EIP-712\" and \"ERC-5267\".The interfaces ITRC3156FlashBorrower.sol, ITRC3156FlashLender.sol, ITRC1363.sol, ITRC1363Receiver.sol, ITRC1363Spender.sol and ITRC1820Registry.solonly cite ERC instead of TRC or dual-citation in the comments.The contracts TRC1363Utils.sol, TRC20FlashMint.sol, Clones.sol, UUPSUpgradeable.sol and TRC165Mock.sol cite ERC instead of TRC or dual-citation in the comments.The documentation at contracts/proxy/README.adoc, contracts/token/TRC20/README.adoc, contracts/utils/README.adoc, and contracts/utils/cryptography/README.adoc cite ERC instead of TRC or dual-citation in the commit.The function name - erc7201Slot can be renamed to trc7201Slot.Not every Ethereum reference is a mistake, and a mechanical find-and-replace would introduce errors. Three categories are correct as written and should be left in place:References that already dual-cite the TRON standard alongside the Ethereum original, such as Initializable, which documents its namespace as \"TIP-7201 (the TRON-side analogue of ERC-7201)\".Standards that have no current TIP including the ERC-7786, ERC-7802, ERC-7913, for which the Ethereum name is the only accurate reference.Ethereum-specific concepts with no TRON analogue, such as ERC-4337, EIP-7702, EIP-155, and EIP-170, together with the callback names deliberately retained per their TRON standards (onERC1155Received and onERC721Received).Consider updating the instances listed above to cite the TRON identifier of each renamed standard and only citing the Ethereum original when necessary.Update: Resolved in pull request #125 and #135. The team stated:We have addressed the issues. All documentation instances now use the TRON identifier; the erc7201Slot → trc7201Slot change is in a separate PR #125. Four instances: ITRC3156FlashBorrower, ITRC3156FlashLender, TRC20FlashMint, and the TRC20FlashMint entry in token/TRC20/README.adoc are fixed in the same PR #125.The convention has been applied: the port uses the TRC/TIP identifier for every standard it re-ships, since that is what the shipped artifacts are named (ITRC1820Registry, ITRC2309, BridgeTRC7802). Where TRON has published a TIP, the citation links it and notes the Ethereum analogue: …/tip-1363.md[TIP-1363] (the TRON-side analogue of …[EIP-1363]). Where TRON has not, the identifier still reads TRC-N but the citation points at the document that defines it: TRC-7751 (see …[ERC-7751]). No link is ever labelled TRC while targeting an Ethereum document.Missing Documentation for Decoding 21-Byte TRON AddressesInside the TVM an account is 20 bytes, but TRON's canonical external address form is the 21-byte 0x41-prefixed encoding that every wallet, explorer, and most tooling display. Several contracts in scope decode or validate an address from raw bytes carried in a cross-chain payload, yet none document which of the two forms a caller or relayer must supply. When the two forms are confused the intended flow breaks, and the failure mode differs by component.On the receive path of the fungible bridge, BridgeFungibleUpgradeable._processMessage and its non-upgradeable counterpart BridgeFungible._processMessage decode the destination as address to = address(bytes20(toBinary)) with no check that toBinary is exactly 20 bytes, and the send path forwards the recipient bytes from parseV1() without a length bound. If a counterpart bridge or relayer encodes the recipient in the natural 21-byte form, bytes20() truncates it to 0x41 followed by the first 19 bytes, a different address, and the release transfers funds there without reverting. This requires only an honest tooling error, not an attacker, and results in permanent loss. For the mint bridge, BridgeTRC7802, it mints new supply to the wrong address with no clawback.The Open Intents Framework exhibits the same 21-byte ambiguity with the opposite failure mode. Its LibAddress.validatedCleanAddress converts a cross-chain identifier to an address only after requiring that the upper twelve bytes are zero, reverting with HasDirtyBits otherwise. A TRON recipient encoded in its 21-byte 0x41-prefixed form places the 0x41 byte above the low twenty bytes, so identifier >> 160 is non-zero and the call reverts. This fails safe rather than losing funds. However, it blocks settlement whenever an identifier carries a TRON address in its natural form, which can prevent the framework from integrating on TRON.The common cause is that these byte-manipulation paths assume the 20-byte TVM form without validating the input length or documenting the requirement.Consider thoroughly documenting the handling of byte manipulation on 21-byte TRON input addresses across the codebase, stating explicitly that an address input must be the 20-byte TVM account and not the 21-byte 0x41 form, and making the expected encoding clear to counterpart bridges, relayers, and off-chain tooling. Consider also adding explicit length validation on the bridge paths, for example require(toBinary.length == 20) in _processMessage and an equivalent addr.length == 20 check on the send path, so that a mismatched input reverts instead of being silently truncated. Since LibAddress.validatedCleanAddress already rejects the 21-byte form, consider ensuring the documentation for the Open Intents Framework makes clear that integrators must supply the 20-byte encoding.Update: Resolved in pull request #117 and #136 in tron-contracts repo and pull request #196 in oif-contracts repo. The team stated:It is true that Tron shows addresses as 21 bytes in their wallets, but this is simply an UI choice and doesn't have any onchain implication. Developers must be aware of how to translate the Base58 21 bytes addresses to the actual 20 bytes addresses at the smart contract level.However, adding a custom error `BridgeInvalidRecipient` is positive for the library and improves security so it was added on https://github.com/OpenZeppelin/tron-contracts/pull/117We have updated the documentation for tron-contracts-upgradeable and oif-contracts repos.Notes & Additional InformationTRON Block Time Compresses Block-Denominated Governance Windows Roughly FourfoldThe Governor and Votes stack is byte-identical to the audited OpenZeppelin Contracts v5.6.1 and is clock-agnostic, so no code defect exists. However, the default clock is block-number based: Votes.clock returns Time.blockNumber and CLOCK_MODE is mode=blocknumber&from=default. TRON produces blocks roughly four times faster than Ethereum, approximately every 3 seconds against approximately every 12 seconds, so every block-denominated window elapses in about a quarter of the intended wall-clock time when a deployer reuses Ethereum-style block-count parameters.Block-denominated parameters affected include votingDelay, votingPeriod, the proposal snapshot and deadline, all vote and quorum checkpoints, and the voteExtension of GovernorPreventLateQuorum. Timestamp-denominated values are unaffected, including all timelock delays, VestingWallet and its cliff variant, and all signature expiries such as permit and delegateBySig. Two shipped artifacts bake in the 12-second assumption: the governance documentation at docs/modules/ROOT/pages/governance.adoc states votingDelay = 1 day = 7200 blocks and votingPeriod = 1 week = 50400 blocks, which on TRON correspond to roughly 6 hours and 1.75 days; and the MyGovernorUpgradeable and MyGovernor mock returns 7200 and 50400 with day/week comments while its paired token uses the default block clock.Consider correcting the block-time arithmetic in the documentation and mock for TRON (approximately 28800 blocks per day and 201600 blocks per week at 3 seconds) and adding TRON-specific governance deployment guidance. Deployers should preferably be steered toward the timestamp clock mode, as demonstrated by MyTokenTimestampBasedUpgradeable, so that windows are expressed in seconds and independent of block time; when the block clock is used, Ethereum block counts should be multiplied by approximately four and lateQuorumVoteExtension re-checked.Update: Resolved in pull request #116. The team stated:We implemented the fix on docs and mock contract.Stale Warnings And Cautions In The CodebaseThroughout the codebase, the following cautions and warnings were identified in documentation that can be considered stale or misleading given the migration to the TRON ecosystem:The proxy module documentation in contracts/proxy/README.adoc recommends the OpenZeppelin Upgrades Plugins for Hardhat and Foundry as the default way to deploy and manage upgradeable proxies:CAUTION: Using upgradeable proxies correctly and securely is a difficult task that requires deep knowledge of the proxy pattern, Solidity, and the EVM. Unless you want a lot of low level control, we recommend using the OpenZeppelin Upgrades Plugins for Hardhat and Foundry.The recommended plugins are Ethereum-oriented. They depend on eth_* JSON-RPC methods and default provider/compiler behavior that are not guaranteed to match a TRON/TVM environment, where deployments and upgrades are sensitive to (i) which RPC methods and block tags the provider supports, and (ii) the bytecode produced by the Solidity compilation target (evmVersion / opcode set). Following this recommendation unmodified on TRON can result in failed deployments or upgrades, partially completed deployments, or proxies that cannot be upgraded in the target environment without redeploying.The WARNING in TIP712Upgradeable (__TIP712_init) describes a _nameFallback/_versionFallback mechanism, an immutable _hashedName/_hashedVersion cache, and a \"keep name/version within 31 bytes behind a proxy or clone\" rule; none of these exist in this implementation, which stores plain _name/_version strings of any length in ERC-7201 storage read identically by _buildDomainSeparator and eip712Domain, so the warned desynchronization cannot occur.The NOTE in draft-TRC7739Upgradeable claims a ShortStrings 31-character optimization and an ERC-4337/ERC-7562 storage-access limitation; no ShortStrings path exists, and the domain reads during ERC-7739 validation touch the account's own ERC-7201 slots, which ERC-7562 permits for the sender. Finally, the comment in MultiSignerTRC7913WeightedUpgradeable states that _totalExtraWeight is packed with the base contract's _threshold, but the two fields reside in separate ERC-7201 namespaces and cannot share a storage slot.Consider updating the above documentation to avoid misinformation and confusion.Update: Resolved in pull request #132 and #134.Rename contracts from OpenZeppelin Contracts to Tron ContractsThe comment at the top of each contract file currently uses the text // OpenZeppelin Contracts (last updated v5.6.0) (governance/TimelockController.sol). For consistency within the repository, this should be updated to // Tron Contracts (last updated v5.6.0) (governance/TimelockController.sol) in all similar instances.Consider updating all such header comments to reference Tron Contracts instead of OpenZeppelin Contracts to maintain consistent naming throughout the codebase.Update: Resolved in pull request #124. The team stated:We have updated the comments and scripts.Governance Executors Do Not Support Forwarding or Recovery of TRC-10 TokensTRON contracts can hold native TRC-10 assets independently of TRX. The TVM exposes their incoming amount and identifier through msg.tokenvalue and msg.tokenid, and forwarding them requires the token-aware CALLTOKEN operation or Solidity's address.transferToken primitive. The TVM opcode reference identifies CALLTOKEN as the operation that invokes a contract with TRC-10, and an official pinned TRON fixture demonstrates address.transferToken(amount, id) and the incoming token context. The Governor and TimelockController executors expose payable entry points through which a TVM caller can attach TRC-10, and their payable receive paths can hold native assets as well.Every supplied outbound path nevertheless uses an ordinary Solidity call that carries only TRX. The Governor performs the call in _executeOperations and relay, while the TimelockController centralizes the same operation in _execute. The proposal and operation hashes bind targets, TRX values, and calldata, but contain no TRC-10 token identifier or amount. Therefore, governance cannot attach TRC-10 to an executed target call, and native tokens credited to either executor cannot be recovered through the supplied execution or relay paths. This is particularly surprising for relay, whose documentation advertises recovery of mistakenly sent tokens or TRX; ordinary TRC-20 tokens are recoverable by calling their contract, but native TRC-10 tokens are not. No attacker profit path was identified, so the impact is limited to accidental or intentional asset unavailability.The behavior is present identically in both libraries. In tron-contracts, the payable Governor.execute, Governor.relay, TimelockController.execute, and TimelockController.executeBatch entry points contrast with the TRX-only outbound calls in Governor._executeOperations and TimelockController._execute. The same holds in tron-contracts-upgradeable.Consider adding a self-governed TRC-10 recovery operation using address.transferToken. If arbitrary token-bearing governance calls are intended, add token-aware execution variants and bind both the token identifier and the token value into the proposal or operation hash. Otherwise, document explicitly that TRC-10 is unsupported. Rejecting a nonzero msg.tokenvalue on the payable entry points can prevent call-attached deposits, although it cannot necessarily prevent every protocol-level transfer.Update: Resolved in pull request #130 and #133. The team stated:The library is not intended and does not support TRC-10 tokens. The Tron team does not incentivize its use and the default for tokens is TRC-20. PR created to document itREADME and Documentation Reference ERC/EIP-Named Artifacts That Only Exist Under TRC NamesSeveral references in the user-facing documentation of both TRON libraries point to ERC/EIP-named artifacts (contracts, functions, and a documentation page) that do not exist under those names in the port; the correctly named TRC artifact exists and is what the documentation should reference. These are documentation defects with no on-chain impact: one is a broken link, and the others direct integrators to nonexistent contract and function names.The affected artifact references are the following:The upgrades guide instructs deploying an ERC1967Proxy, but the package ships TRC1967Proxy, not ERC1967Proxy.The signature-checking example calls SignatureChecker.isValidERC1271SignatureNow, whereas SignatureChecker exposes isValidTRC1271SignatureNow.The introspection section references IERC165, ERC165, and ERC165Checker (including using ERC165Checker for address;), whereas the port provides ITRC165, TRC165, and TRC165Checker.A governance paragraph uses a lone no-dash TRC6372 clock in text that otherwise refers to the standards as ERC-6372 and ERC-5805.The contribution guidelines require error-name domain prefixes of the form ERC<number>, whereas this codebase standardizes on TRC<number>.With one exception, these appear in both libraries: in tron-contracts, in its upgrades guide, utilities guide, governance guide, and GUIDELINES.md; and identically in tron-contracts-upgradeable, in its upgrades guide, utilities guide, governance guide, and GUIDELINES.md.The exception is the broken documentation-page link, which appears only in tron-contracts-upgradeable: its README.md links a nonexistent erc6909.adoc page, whereas the actual page is trc6909.adoc, and it lists \"ERC-6909\". The tron-contracts README.md contains no equivalent reference, so this item does not apply to it.Consider a single documentation pass across both libraries that repoints the ERC/EIP-named artifact references to their TRC equivalents, and, in tron-contracts-upgradeable, fixes the broken erc6909.adoc link. Dash-form references to the underlying standards (for example EIP-712 or ERC-165 as a specification) are correct and should be left unchanged.Update: Resolved in pull request #126. The team stated:The erc6909.adoc link is reported as appearing only in tron-contracts-upgradeable because the README on the upgradeable library is generated through an script, which was also fixed in the PR.ConclusionThe tron-contracts and tron-contracts-upgradeable libraries port OpenZeppelin Contracts to the TRON Virtual Machine, and a third repository adapts the Open Intents Framework settlement contracts to TRON. OpenZeppelin audited the three codebases and the adaptations required to run on the TVM.Most of the change from upstream is renaming, and the reported findings fall into two areas. The first is where TVM execution diverges from the EVM: TRON USDT returning false on a successful transfer freezes TRC4626 withdrawals, the 21-byte TRON address form is mishandled when decoding recipients, the settlement layer must target TRON's own Permit2 deployment, and TRON's faster block time compresses block-denominated governance windows. The second is standards and documentation conformance, including residual Ethereum ERC/EIP names that should reference the TRON identifiers and a flash-loan callback value that does not match the TRON standard.The most significant cross-cutting concern is that the port is pinned to a fixed upstream baseline and does not carry over fixes that OpenZeppelin has since made upstream. Several issues already resolved upstream remain present, so a process to track upstream advisories and backport their fixes should be established before the libraries are relied upon in production.OpenZeppelin thanks the development team for their responsiveness and for the context provided throughout the engagement.AppendixIssue ClassificationOpenZeppelin classifies smart contract vulnerabilities on a 5-level scale:CriticalHighMediumLowNote/InformationCritical SeverityThis classification is applied when the issue’s impact is catastrophic, threatening extensive damage to the client's reputation and/or causing severe financial loss to the client or users. The likelihood of exploitation can be high, warranting a swift response. Critical issues typically involve significant risks such as the permanent loss or locking of a large volume of users' sensitive assets or the failure of core system functionalities without viable mitigations. These issues demand immediate attention due to their potential to compromise system integrity or user trust significantly.High SeverityThese issues are characterized by the potential to substantially impact the client’s reputation and/or result in considerable financial losses. The likelihood of exploitation is significant, warranting a swift response. Such issues might include temporary loss or locking of a significant number of users' sensitive assets or disruptions to critical system functionalities, albeit with potential, yet limited, mitigations available. The emphasis is on the significant but not always catastrophic effects on system operation or asset security, necessitating prompt and effective remediation.Medium SeverityIssues classified as being of medium severity can lead to a noticeable negative impact on the client's reputation and/or moderate financial losses. Such issues, if left unattended, have a moderate likelihood of being exploited or may cause unwanted side effects in the system. These issues are typically confined to a smaller subset of users' sensitive assets or might involve deviations from the specified system design that, while not directly financial in nature, compromise system integrity or user experience. The focus here is on issues that pose a real but contained risk, warranting timely attention to prevent escalation.Low SeverityLow-severity issues are those that have a low impact on the client's operations and/or reputation. These issues may represent minor risks or inefficiencies to the client's specific business model. They are identified as areas for improvement that, while not urgent, could enhance the security and quality of the codebase if addressed.Notes & Additional Information SeverityThis category is reserved for issues that, despite having a minimal impact, are still important to resolve. Addressing these issues contributes to the overall security posture and code quality improvement but does not require immediate action. It reflects a commitment to maintaining high standards and continuous improvement, even in areas that do not pose immediate risks.Looking for a security partner? Talk to an expert","tokens":13026,"squid":"ink-security_audits","role":"Sentinel","at":1791258207601,"hash":"b90b477d3f1acb770e71ffc3edae0225bb38345b"}
{"url":"https://ethresear.ch/t/towards-native-post-quantum-private-eth/25291/8","domain":"ethresear.ch","title":"Towards Native Post-Quantum Private ETH - Privacy - Ethereum Research","text":"Privacy\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n Jun 24\n\n 8 / 8\n\n Jun 28\n\n Jun 29\n\n post by Pierre on Jun 24\n\n post by 71104 on Jun 24\n\n post by Pierre on Jun 25\n\n post by 71104 on Jun 25\n\n post by Pierre on Jun 25\n\n Pierre\n\n I’m not pointing out recursion to be a problem. Rather, that designing a zkSTARK to be generated on a hardware wallet for the spend auth scheme isn’t really a good use of time.\nHardware wallets already have a bunch of work related to porting pq signatures. Generating such proofs introduces new performance problems and attack vectors that vendors might not be keen on investigating today. Assuming that devices will adapt over time is opening the door to many issues.\nWorking on circumventing pq signatures limitations has a much better case. Pretty good and standardized solutions exist already, such as using a stateless scheme with a parameter set used for firmware signing or just leveraging an OTS.\n\n post by 71104 on Jun 25\n\n 71104\n\n You’re basically arguing for legacy drag to block all innovation. That works until someone who knows better goes all-in on innovation and beats you with smaller proofs and higher scalability.\n\n post by rdubois-crypto on Jun 26\n\n rdubois-crypto\n\n I gently disagree about the fact that the HW has to compute the proof: spending and proving might be separated. There is no real sense to require proving in the HW, cause if the host is compromised, privacy will be compromised by a thousand other ways. A corrupted prover cannot spend your funds in Zcash/RG systems.\nI fully agree that the real problem is the succinctness that will require aggragation/L2 like system. And it is unlikely (I don’t know any searchers thinking we might) that a way to achieve it with hash based or Lattices is ever found.\n\n post by Pierre on Jun 29\n\n Pierre\n\nYes I agree, it does require thinking about recursion or aggregation. I’m not too pessimistic though! On the hash based side of things, the work done by the LeanVM team is a cool direction which could be nice to piggy back on. We also investigated WARP and worked on an implementation here. I’m less familiar with what’s being done using lattice-based primitives.\n\n Powered by Discourse","tokens":565,"squid":"ink-research","role":"Deep Scholar","at":1791258210753,"hash":"39af7f83f594a40c8490ef03c029f995eb62094d"}
{"url":"https://docs.pyth.network/price-feeds/core/api-reference","domain":"docs.pyth.network","title":"API Reference | Pyth Developer Hub","text":"Pyth CoreAPI ReferenceExplore interactive Pyth API references for on-chain and off-chain integrationsThe API reference is a comprehensive guide to the various APIs -- both on- and off-chain -- that developers can use in their applications.\nDevelopers can consult this reference to better understand what methods exist and what they do.\nThe API reference is interactive, so developers can try out the APIs from the website to better understand their behavior.\nPyth Core was upgraded on August 26, 2026We recommend new integrations use the upgraded contract addresses.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nThe following on-chain contracts are documented in the API reference:\n\nEVM\n\nHermes also has interactive API documentation hosted by the service itself:\n\nHermes\nBenchmarks / Historical Prices\nSVM Price Feeds ContractPrevious PagePrice FeedsOverview of Pyth price feeds, asset classes, and feed IDs","tokens":252,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258218405,"hash":"c01918a2d805bde2da5a7b8d765a4c5ab2b2f7c0"}
{"url":"https://www.anchor-lang.com/docs/tokens/basics","domain":"anchor-lang.com","title":"SPL Token Basics","text":"Interacting with TokensSPL Token BasicsLearn how to integrate SPL Tokens into your Solana programs using the Anchor framework.This section covers the basics for interacting with SPL Tokens in Anchor\nprograms, focusing on the most commonly used instructions.\nAll examples in this section work identically with both the original Token\nProgram and the Token Extension Program (Token 2022), as they share the same\nbase implementation.\nBelow are the most common instructions you'll see when interacting with SPL\nTokens:Create a Token MintLearn how to create and initialize token mint accounts in Solana programs using Anchor. Covers creating mint accounts with generated keypairs or PDAs with code examples.Create a Token AccountLearn how to create and initialize token accounts in Solana programs using Anchor. Covers creating Associated Token Accounts (ATAs) and Program Derived Address (PDA) token accounts with code examples.Mint TokensLearn how to mint tokens in Solana programs using Anchor. Covers creating new tokens via cross program invocations (CPI) to the Token Program with code examples.Transfer TokensLearn how to transfer tokens between token accounts through cross program invocations (CPIs) in Anchor.PreviousToken Integration with AnchorNextCreate a Token MintOn this pageNo HeadingsEdit on GitHub","tokens":328,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258224960,"hash":"ddbf1c36c47688708939681c4bb1af5998e1d1d9"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/nitro/migrate-state-and-history-from-classic","domain":"docs.arbitrum.io","title":"How to migrate state and history from a classic (pre-Nitro) node to a Nitro node | Arbitrum Docs","text":"✏️Request an updateWhen running a Nitro node for the first time on a chain that produced classic blocks in the past (like Arbitrum One), you need to initialize its database to, at least, the state of the chain after executing the last classic block. The common, and recommended, way of doing that is to provide a database snapshot using the --init.url option (as mentioned in How to run a full node (Nitro)). In this how-to we show you an alternative way for doing that, migrating the state and history of the chain from a fully synced classic node.\nIs this How-to for you?As mentioned, the recommended way of initializing a Nitro node is by using a pre-initialized database snapshot with the --init.url option. This guide is for those that are interested in re-creating the full state of the chain from the genesis block using their own classic node.Keep in mind that this process only applies to Arbitrum One. Other Arbitrum chains didn't produce classic blocks in the past, they started as Nitro chains.\nPrerequisites​\nTo successfully migrate the state and history of the chain from a classic (pre-Nitro) node to a Nitro node, you'll need:\n\nA fully synced classic node: you can find instructions on how to run a classic node in this page.\nA clean, uninitialized Nitro node: you can find instructions on how to set up a Nitro node in this page.\n\nStep 1: Enable export options in your classic node​\nLaunch your classic node with the option --node.rpc.nitroexport.enable=true. All exported data will be written to directory \"nitroexport\" under the classic instance directory (e.g., ${HOME}/.arbitrum/mainnet/nitroexport). Make sure the classic node has read the entire rollup state.\nCautionEnabling the export options is only recommended for nodes with no public/external interfaces.\nExported file contents are not deterministicExporting the state of your own classic node should produce the same state as using files supplied by the Arbitrum Foundation (i.e., the same genesis blockhash). However, multiple exports of the same state will not necessarily create identical intermediate files. For example, state export is done in parallel, so the order of entries in the file is not deterministic.\nStep 2: Export information from your classic node​\nBlock and transaction history​\nThese are block headers, transactions and receipts executed in the classic node. Nitro node uses the history to be able to answer simple requests, like eth_getTransactionReceipt, from the classic history. The last block in the chain is the only one that affects the genesis block: timestamp is copied from the last block, and parentHash is taken from the last block's blockHash.\n\nCall the RPC method arb_exportHistory with parameter \"latest\" to initiate history export. It will return immediately.\nCalling arb_exportHistoryStatus will return the latest block exported, or an error if the export failed.\nData will be stored in the directory nitroexport/nitro/l2chaindata/ancient.\n\nRollup state​\nThe rollup state is exported as a series of JSON files. State read from these JSON files will be added to Nitro's genesis block.\n\nCall the RPC method arb_exportState with parameter latest to initiate state export. Unless disconnected, this will only return after the state export is done.\nData will be stored in the directory nitroexport/state/<block_number>/.\n\nOutbox messages (optional)​\nThis data does not impact consensus and is optional. It allows a Nitro node to provide the information required when executing a withdrawal made on the classic rollup.\n\nCall the RPC method arb_exportOutbox with parameter \"0xffffffffffffffff\" to initiate outbox export. It will return immediately.\nCalling arb_exportOutboxStatus will return the latest outbox batch exported, or an error if the export failed.\nData will be stored in the directory nitroexport/nitro/classic-msg.\n\nStep 3: Initialize your Nitro node importing the exported data​\n\nPlace the l2chaindata and classic-msg (if exported) directories in Nitro's instance directory (e.g., ${HOME}/.arbitrum/arb1-nitro/).\nLaunch the Nitro node with the argument --init.import-file=/path/to/state/index.json\n\nCautionThis state import operation requires more resources than a regular run of a Nitro node.\nOther useful Nitro options​\nFlagDescription--init.accounts-per-syncAllows the node to make partial database writes to hard-disk during initialization, allowing memory to be freed. This should be used if memory load is very high. A reasonable initial value to try would be 100000. Systems with constrained memory might require a lower value.--init.then-quitCauses the node to quit after initialization is done.--init.forceFor an already-initialized node, forces the node to recalculate Nitro's genesis block. If the genesis blockhash doesn't match what's in the database, the node will panic.\nSee also​\n\nHow to run a full node (Nitro)\nHow to run a full node (Classic, pre-Nitro)\nPrerequisitesStep 1: Enable export options in your classic nodeStep 2: Export information from your classic nodeBlock and transaction historyRollup stateOutbox messages (optional)Step 3: Initialize your Nitro node importing the exported dataOther useful Nitro optionsSee also","tokens":1293,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258226111,"hash":"96b73fe62177103366936fb027f50e2c94e700c3"}
{"url":"https://docs.pyth.network/price-feeds/core/use-pyth-for-morpho","domain":"docs.pyth.network","title":"Use Pyth for Morpho Markets | Pyth Developer Hub","text":"Pyth CoreUse Pyth for Morpho MarketsLearn how to use Pyth for Morpho MarketsThis guide will show how you can leverage Pyth real-time price data to power Morpho markets.\nPyth provides a wrapper which implements Morpho's IOracle interface called pyth-morpho-wrapper.\nThere are two steps to use Pyth price feeds for Morpho markets:\n\nSchedule Price Updates.\nDeploy the MorphoPythOracle.sol contract for the respective price feed pair.\n\nSchedule Price UpdatesAs a pull oracle, Pyth's users are typically responsible for updating the state of on-chain feeds.\nPlease see What is a Pull Oracle? to learn more about pull updates.Consult Schedule Price Updates guide for more information.The Pyth Data Association sponsors regular on-chain updates for some price feeds.\nSee Push Feeds for the current list of feeds and their update parameters.If you don't find relevant price IDs in the Push Feeds list, please contact the Pyth team here to run the Price Pusher for the price feed you need.Deploy the Morpho oracle contractAfter running the Price Pusher, you can deploy the Morpho oracle contract using the MorphoPythOracle.sol contract.To deploy a MorphoPythOracle on an EVM chain, we highly recommend using the factory MorphoPythOracleFactory. Please refer to the factory addresses here.If you don't see the factory address for your chain, you can deploy your own factory by using the scripts/MorphoPythOracleFactoryDeploy.s.sol script or by creating an issue on this repository.\nIf you are deploying, please make sure to update the README.md file with the new factory address.To do so, run the MorphoPythOracleDeploy.s.sol script with the following environment variables set:\nPYTH_ADDRESS: The Pyth contract address. This is the address of the Pyth contract deployed on the chain. You can find the address of the Pyth contract for each chain here.\nBASE_VAULT: The ERC4626 token vault for the base asset.\nBASE_VAULT_CONVERSION_SAMPLE: A sample amount for converting base vault units.\nBASE_FEED1, BASE_FEED2: Pyth price feed ids for the base asset. You can find the price feed ids for each asset in our price feeds directory.\nBASE_TOKEN_DECIMALS: Decimal precision of the base asset.\nQUOTE_VAULT: The ERC4626 token vault for the quote asset.\nQUOTE_VAULT_CONVERSION_SAMPLE: A sample amount for converting quote vault units.\nQUOTE_FEED1, QUOTE_FEED2: Pyth price feed ids for the quote asset. You can find the price feed ids for each asset in our price feeds directory.\nQUOTE_TOKEN_DECIMALS: Decimal precision of the quote asset.\nPRICE_FEED_MAX_AGE: The maximum age of the price feed in seconds. Note: This adds an extra safety net to avoid using stale prices.\nSALT: A unique identifier to create deterministic addresses for deployed oracles.\nCheck more information about these immutable parameters here and some assumptions to take into account here.ERC4626 DecimalsIf there is an ERC4626-compliant vault for BASE_VAULT or QUOTE_VAULT, the\nBASE_TOKEN_DECIMALS or QUOTE_TOKEN_DECIMALS are still the decimals of the\nunderlying asset of the vault, and not the decimals of the Vault itself. E.g:\nfor a MetaMorpho WETH vault, as BASE_VAULT, the BASE_TOKEN_DECIMALS is 18\nas WETH has 18 decimals.Derive Cross RateLearn how to derive synthetic cross rates using Pyth price feedsTroubleshootDiagnose common issues affecting Pyth price feeds across supported ecosystems","tokens":837,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258227721,"hash":"0bf6264d5d99820ebaa327768ebeaa6ffebb7a0b"}
{"url":"https://www.anchor-lang.com/docs/tokens/basics/create-token-account","domain":"anchor-lang.com","title":"Create a Token Account","text":"Interacting with TokensBasicsCreate a Token AccountLearn how to create and initialize token accounts in Solana programs using Anchor. Covers creating Associated Token Accounts (ATAs) and Program Derived Address (PDA) token accounts with code examples.What is a Token Account?\nA token account is an account type in Solana's Token Programs that stores\ninformation about an individual's ownership of a specific token (mint). Each\ntoken account is associated with a single mint and tracks details like the token\nbalance and owner.\n/// Account data.\n#[repr(C)]\n#[derive(Clone, Copy, Debug, Default, PartialEq)]\npub struct Account {\n /// The mint associated with this account\n pub mint: Pubkey,\n /// The owner of this account.\n pub owner: Pubkey,\n /// The amount of tokens this account holds.\n pub amount: u64,\n /// If `delegate` is `Some` then `delegated_amount` represents\n /// the amount authorized by the delegate\n pub delegate: COption<Pubkey>,\n /// The account's state\n pub state: AccountState,\n /// If `is_native.is_some`, this is a native token, and the value logs the\n /// rent-exempt reserve. An Account is required to be rent-exempt, so\n /// the value is used by the Processor to ensure that wrapped SOL\n /// accounts do not drop below this threshold.\n pub is_native: COption<u64>,\n /// The amount delegated\n pub delegated_amount: u64,\n /// Optional authority to close the account.\n pub close_authority: COption<Pubkey>,\n}\nNote that in the source code, a Token account is referred to as an Account\ntype. Both the Token\nProgram\nand Token Extension\nProgram\nhave the same base implementation for the Token account.\nTo hold tokens for a specific mint, users must first create a token account.\nEach token account is associated with:\n\nA specific mint (the token type the token account holds units of)\nAn owner (the authority who can transfer tokens from the account)\n\nLet's look at an example using USDC on Solana:\n\nThe USDC mint address is EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\nCircle (the USDC issuer) has a token account at\n3emsAVdmGKERbHjmGfQ6oZ1e35dkf5iYcS6U4CPKFVaa\nThis token account can only hold units of the USDC token (mint)\nCircle is set as the owner at 7VHUFJHWu2CuExkJcJrzhQPJ2oygupTWkL2A2For4BmE\nand can transfer these tokens\n\nYou can view the details of this token account on\nSolana Explorer.\nThe term \"owner\" is used in two different contexts:\n\nThe token account \"owner\" - This is an address stored in the token account's\nas the \"owner\" field of the Account type defined by the Token Program. The\nowner can transfer, burn, or delegate tokens from the account. This address\nis sometimes referred to as the \"authority\" of the token account to\ndistinguish it from the program owner.\n\nThe program \"owner\" - This refers to the program that owns the account data\non Solana. For token accounts, this is always either the Token Program or\nToken Extension Program, as specified in the \"owner\" field of the base Solana\nAccount\ntype.\n\nWhen working with token accounts, \"owner\" typically refers to the authority that\ncan spend the tokens, not the program that owns the account.\nWhat is an Associated Token Account?\nAn associated token account (ATA) is simply a token account with an address that\nis a PDA derived from and created by the\nAssociated Token Program.\nYou can think of an ATA as the default token account for a user to hold units of\na specific token (mint).\nOnly token accounts created through the Associated Token Program are referred\nto as associated token accounts.\nATAs provide a deterministic way to find a user's token account for any given\nmint. You can inspect the implementation of the derivation\nhere.\nAssociated Token Account Address Derivationpub fn get_associated_token_address_and_bump_seed_internal(\n wallet_address: &Pubkey,\n token_mint_address: &Pubkey,\n program_id: &Pubkey,\n token_program_id: &Pubkey,\n) -> (Pubkey, u8) {\n Pubkey::find_program_address(\n &[\n &wallet_address.to_bytes(), // Owner's public key\n &token_program_id.to_bytes(), // Token Program or Token Extension Program\n &token_mint_address.to_bytes(), // Token mint address\n ],\n program_id, // Associated Token Program ID\n )\n}\nThis deterministic derivation ensures that for any combination of wallet address\nand token mint, there exists exactly one associated token account address. This\napproach makes it simple to find a user's token account for any given token\nmint, eliminating the need to track token account addresses separately.\nThe Associated Token Program acts as a helper program that creates token\naccounts with deterministic addresses (PDAs). When creating an associated\ntoken account, the Associated Token Program makes a CPI (Cross-Program\nInvocation) to either the Token Program or Token Extension Program. The\ncreated account is owned by the token program and has the same Account type\nstructure as defined in the token program. The Associated Token Program itself\nmaintains no state - it simply provides a standardized way to create token\naccounts at a deterministic address.\nUsage\nUse the token_interface and associated_token modules from the anchor-spl\ncrate to work with ATAs compatible with either the Token Program and Token\nExtension Program.\nsnippetuse anchor_spl::associated_token::AssociatedToken;\nuse anchor_spl::token_interface::{Mint, TokenAccount, TokenInterface};\n\n// --snip--\n\n#[derive(Accounts)]\npub struct CreateTokenAccount<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init_if_needed,\n payer = signer,\n associated_token::mint = mint,\n associated_token::authority = signer,\n associated_token::token_program = token_program,\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n pub system_program: Program<'info, System>,\n}\nTo create token accounts with PDAs derived from your program, you can use the\ntoken::mint, token::authority, and token::token_program constraints along\nwith the seeds and bump constraints.\nsnippetuse anchor_spl::token_interface::{Mint, TokenAccount, TokenInterface};\n\n// --snip--\n\n#[derive(Accounts)]\npub struct CreateTokenAccount<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init_if_needed,\n payer = signer,\n token::mint = mint,\n token::authority = token_account,\n token::token_program = token_program,\n seeds = [b\"token\"],\n bump\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\nAccount Types\nThe\nInterfaceAccount\ntype is a wrapper that allows the account to work with both the Token Program\nand Token Extension Program.\nThe TokenAccount type represents the base Account data structure shared by\nboth token programs. When an account of this type is passed in, Anchor will\nautomatically deserialize the account data into the Account struct, regardless\nof which token program created it.\nAccount Typepub token_account: InterfaceAccount<'info, TokenAccount>,\nAccount Constraints\nAnchor provides two sets of constraints for working with token accounts:\n\nUse associated_token constraints when working with Associated Token Accounts\n(ATAs)\nUse token constraints when working with token accounts that are not\nspecifically ATAs, such as custom PDAs or token accounts with addresses that\nare public keys from a keypair\n\nThe appropriate constraint to use depends on your specific use case. ATAs are\nrecommended for user wallets, while custom token accounts are useful for program\ncontrolled accounts.\nassociated_token constraints\nThe following account constraints are used in combination to create and\ninitialize a new associated token account:\nConstraintDescriptioninitCreates a new account by making a cross program invocation (CPI) to the System Program. This allocates the required space for the token account and transfers ownership to the appropriate token program.init_if_neededSimilar to init, but only creates the account if it doesn't already exist. Requires enabling the init-if-needed feature.payerSpecifies which account will pay the rent (SOL deposit) required to create the new account.associated_token::mintSpecifies the mint account that this token account will be associated with.associated_token::authoritySets the authority (owner) of the token account who has permission to transfer or burn tokens.associated_token::token_programSpecifies which token program (Token Program or Token Extension Program) to use when creating the token account.\nCreate Associated Token Account#[account(\n init,\n payer = <payer>,\n associated_token::mint = <mint>,\n associated_token::authority = <authority>,\n associated_token::token_program = <token_program>\n)]\npub token_account: InterfaceAccount<'info, TokenAccount>,\ntoken constraints\nThe following account constraints are used in combination to create and\ninitialize a new token account:\nConstraintDescriptioninitCreates a new account by making a cross program invocation (CPI) to the System Program. This allocates the required space for the token account and transfers ownership to the appropriate token program.init_if_neededSimilar to init, but only creates the account if it doesn't already exist. Requires enabling the init-if-needed feature.payerSpecifies which account will pay the rent (SOL deposit) required to create the new account.token::mintSpecifies the mint account that this token account will be associated with.token::authoritySets the authority (owner) of the token account who has permission to transfer or burn tokens.token::token_programSpecifies which token program (Token Program or Token Extension Program) to use when creating the token account.\nCreate Token Account with Keypair Public Key as Address#[account(\n init,\n payer = <payer>,\n token::mint = <mint>,\n token::authority = <authority>,\n token::token_program = <token_program>\n)]\npub token_account: InterfaceAccount<'info, TokenAccount>,\nCreate Token Account with PDA as Address#[account(\n init,\n payer = <payer>,\n token::mint = <mint>,\n token::authority = <authority>,\n token::token_program = <token_program>,\n seeds = [<seeds>],\n bump\n)]\npub token_account: InterfaceAccount<'info, TokenAccount>,\nNote that you can use the same PDA as both the token::authority and the\ntoken account address. Using a PDA as the token::authority enables your\nprogram to \"sign\" CPI instructions to transfer tokens from the token account.\nThis pattern allows for a single deterministic address for both purposes.\nTo use the init_if_needed constraint, enable the init-if-needed feature in\nCargo.toml and replace the init constraint with init_if_needed.\nCargo.toml[dependencies]\nanchor-lang = { version = \"1.2.0\", features = [\"init-if-needed\"] }\nExamples\nThe following examples demonstrate how to create a token account in an Anchor\nprogram using two different approaches:\n\nUsing an Associated Token Account (ATA) - This is the standard approach to\ncreate a token account for a specific user to hold units of a specific token\n(mint).\n\nUsing a Program Derived Address (PDA) - This approach creates a token account\nwhere the address is a custom PDA. This allows for deterministic token\naccount addresses specific to your program. You can also set the authority\n(owner) as a PDA to enable your program to transfer tokens from the token\naccount.\n\nBoth approaches are can be done entirely using account constraints.\nCreate Associated Token Account\nCreate an associated token account for a user.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::associated_token::AssociatedToken;\nuse anchor_spl::token_interface::{Mint, TokenAccount, TokenInterface};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn create_mint(ctx: Context<CreateMint>) -> Result<()> {\n msg!(\"Created Mint Account: {:?}\", ctx.accounts.mint.key());\n Ok(())\n }\n\n pub fn create_token_account(ctx: Context<CreateTokenAccount>) -> Result<()> {\n msg!(\n \"Created Token Account: {:?}\",\n ctx.accounts.token_account.key()\n );\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint.key(),\n mint::freeze_authority = mint.key(),\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct CreateTokenAccount<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init_if_needed,\n payer = signer,\n associated_token::mint = mint,\n associated_token::authority = signer,\n associated_token::token_program = token_program,\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n pub system_program: Program<'info, System>,\n}\nCreate Token Account using PDA\nCreate a token account using a Program Derived Address (PDA) as the address of\nthe token account.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::token_interface::{Mint, TokenAccount, TokenInterface};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn create_mint(ctx: Context<CreateMint>) -> Result<()> {\n msg!(\"Created Mint Account: {:?}\", ctx.accounts.mint.key());\n Ok(())\n }\n\n pub fn create_token_account(ctx: Context<CreateTokenAccount>) -> Result<()> {\n msg!(\n \"Created Token Account: {:?}\",\n ctx.accounts.token_account.key()\n );\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint.key(),\n mint::freeze_authority = mint.key(),\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct CreateTokenAccount<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init_if_needed,\n payer = signer,\n token::mint = mint,\n token::authority = token_account,\n token::token_program = token_program,\n seeds = [b\"token\"],\n bump\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}PreviousCreate a Token MintNextMint TokensOn this pageWhat is a Token Account?What is an Associated Token Account?UsageAccount TypesAccount ConstraintsExamplesCreate Associated Token AccountCreate Token Account using PDAEdit on GitHub","tokens":3702,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258234871,"hash":"1f27b4657586733e7c9be3061c43b4337876033f"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/more-types/run-classic-node","domain":"docs.arbitrum.io","title":"How to run a Classic node | Arbitrum Docs","text":"✏️Request an updateDo you need to run a Classic node?​\nArbitrum One has been upgraded to Nitro, the latest Arbitrum tech stack. \"Arbitrum Classic\" is our term for the old, pre-Nitro tech stack. The Nitro node databases have the raw data of all blocks, including pre-Nitro blocks. However, Nitro nodes cannot execute anything on pre-Nitro blocks. You need an Arbitrum Classic archive node to execute data on pre-Nitro blocks.\nWhen querying archive blocks, the following commands can only be handled by Arbitrum Classic nodes:\n\neth_call\neth_estimateGas\neth_getBalance\neth_getCode\neth_getTransactionCount\neth_getStorageAt\n\nArbitrum Nova and SepoliaArbitrum Nova and Arbitrum Sepolia started as Nitro chains, so they don't have classic blocks.\nRequired artifacts​\n\nLatest Docker Image: offchainlabs/arb-node:v1.4.6-551a39b3\nLatest classic snapshot for Arbitrum One: https://snapshot.arbitrum.foundation/arb1/classic-archive.tar\n\nRequired parameters​\n\n--l1.url=<Layer 1 Ethereum RPC URL>\n\nMust provide standard Ethereum node RPC endpoint.\n\n--node.chain-id=<L2 Chain ID>\n\nMust use 42161 for Arbitrum One\n\nImportant ports​\n\nRPC: 8547\nWebSocket: 8548\n\nPutting it all together​\n\nWhen running Docker image, an external volume should be mounted to persist the database across restarts. The mount point should be /home/user/.arbitrum/mainnet.\nHere is an example of how to run a classic archive node for Arbitrum One (only needed for archive requests on pre-Nitro blocks, so you'll probably want to enable the archive mode in your Nitro node as well):\n\ndocker run --rm -it -v /some/local/dir/arbitrum-mainnet/:/home/user/.arbitrum/mainnet -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/arb-node:v1.4.6-551a39b3 --l1.url=https://l1-node:8545 --node.chain-id=42161 --l2.disable-upstream\nNote on permissions​\n\nThe Docker image is configured to run as non-root UID 1000. This means if you are running in Linux and you are getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders.\n\nmkdir /some/local/dir/arbitrum-mainnetchmod -fR 777 /some/local/dir/arbitrum-mainnet\nOptional parameters​\nWe show here a list of the parameters that are most commonly used when running a Classic node. You can also use the flag --help for a full comprehensive list of the available parameters.\n\n--core.cache.timed-expire\n\nDefaults to 20m, or 20 minutes. Age of oldest blocks to hold in cache so that disk lookups are not required\n\n--node.rpc.max-call-gas\n\nMaximum amount of gas that a node will use in call, default is 5000000\n\n--core.checkpoint-gas-frequency\n\nDefaults to 1000000000. Amount of gas between saving checkpoints to disk. When making archive queries node has to load closest previous checkpoint and then execute up to the requested block. The farther apart the checkpoints, the longer potential execution required. However, saving checkpoints more often slows down the node in general.\n\n--node.cache.allow-slow-lookup\n\nWhen this option is present, will load old blocks from disk if not in memory cache\nIf archive support is desired, recommend using --node.cache.allow-slow-lookup --core.checkpoint-gas-frequency=156250000\n\n--node.rpc.tracing.enable\n\nNote that you also need to have a database populated with an archive node if you want to trace previous transactions\nThis option enables the ability to call a tracing API which is inspired by the parity tracing API with some differences\n\nExample: curl http://arbnode -X POST -H \"Content-Type: application/json\" -d '{\"jsonrpc\":\"2.0\",\"method\":\"arbtrace_call\",\"params\":[{\"to\": \"0x6b175474e89094c44da98b954eedeac495271d0f\",\"data\": \"0x70a082310000000000000000000000006E0d01A76C3Cf4288372a29124A26D4353EE51BE\"},[\"trace\"], \"latest\"],\"id\":67}'\n\nThe trace_* methods are renamed to arbtrace_*, except trace_rawTransaction is not supported\nOnly trace type is supported. vmTrace and stateDiff types are not supported\nThe self-destruct opcode is not included in the trace. To get the list of self-destructed contracts, you can provide the deletedContracts parameter to the method\n\nFeed relay​\n\nArbitrum classic does not communicate with Nitro sequencer, so the classic relay is no longer used.\n\nWhy classic nodes serve RPC methods so slowly?​\nWhen you call RPC methods on Arbitrum Classic nodes, the request time may take a long time, because classic nodes must perform multiple sequential reads from the database to reconstruct blockchain state for state-accessing operations. Nodes need to load execution cursors from disk, rebuild the machine state from checkpoints, and execute transactions to reach the target state—all of which involve expensive disk I/O operations.\nSolutions:\n\nUse sequential block access: Query consecutive blocks (N, N+1, N+2) instead of random blocks to benefit from caching\n\nHardware optimization: Use NVMe SSDs with low latency (NVMe PCIe 4.0 or higher)\n\nDo you need to run a Classic node?Required artifactsRequired parametersImportant portsPutting it all togetherNote on permissionsOptional parametersFeed relayWhy classic nodes serve RPC methods so slowly?","tokens":1271,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258235955,"hash":"91e1c96dae3aafd47837780fd655b6d53bfec273"}
{"url":"https://docs.pyth.network/price-feeds/core/schedule-price-updates","domain":"docs.pyth.network","title":"Schedule Price Updates | Pyth Developer Hub","text":"Pyth CoreSchedule Price UpdatesCompare options for automating on-chain Pyth price updatesThis guide introduces the available options for scheduling Pyth price updates at regular intervals. Pyth is a pull oracle, so applications are typically responsible for updating prices on-chain. To learn more about the model, review What is a Pull Oracle?.\nThe Pyth Data Association sponsors regular updates for select feeds. See the push feeds overview for the current schedule and use the request form if you need additional coverage.\nYou can also automate updates using any of the following services:\n\nAdrastia’s Pyth Price Feed Updater — a managed service for time- and deviation-based updates on any EVM chain\nGelato — a turnkey automation platform for scheduled updates\nPrice Pusher — an off-chain service you can operate to trigger updates when specific time or price thresholds are met\n\nTune Deviation Thresholds CarefullyLower deviation thresholds lead to more frequent on-chain transactions. While\nthis improves freshness, it also increases gas costs. Adjust thresholds\naccording to your product’s latency and cost requirements.Fetch Price UpdatesLearn how to retrieve Pyth price updates via REST, streaming, and SDKUsing Price PusherAutomate on-chain Pyth price updates with the Price Pusher service","tokens":325,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258237608,"hash":"b21103b10bab2db373df72997ebb32065ad93826"}
{"url":"https://www.anchor-lang.com/docs/tokens/extensions","domain":"anchor-lang.com","title":"Extensions","text":"Interacting with TokensExtensionsLearn how to enable token extensions to add optional features to token mints and accounts using the Token Extensions Program (Token 2022) in an Anchor program.What are Token Extensions?\nThe Token Extensions Program (Token 2022) provides additional features through\nadditional instructions referred to as extensions. Extensions are optional\nfunctionality that can be added to a token mint or token account. You can find\nthe implementation of these extension instructions in the Token Extensions\nProgram\nsource code.\nEach extension adds specific state that is usually initialized during mint or token\naccount creation. When initializing either type of account, you can enable\nmultiple extensions simultaneously to add different functionality. However,\nmost extensions cannot be added after an account is created - you must include all\ndesired extensions during the initial account creation. This is an important\nconsideration when designing your token, as you'll need to plan ahead for which\nfeatures you want your token to support.\nThe exceptions to this, which require the account to be initialized before they are added, are:\n\ncpi-guard\nmemo-transfer\ntoken-group\ntoken-member\ntoken-metadata\n\nSome extensions are incompatible with each other and cannot be enabled\nsimultaneously on the same token mint or token account. For example, you\ncannot combine the NonTransferable extension with the TransferFeeConfig\nextension, since they have conflicting behaviors.\nThe Token Extensions Program defines an\nExtensionType\nenum that specifies all available extensions that can be added to a token mint\nor token account. Each variant represents a different extension with unique\nfunctionality.\nThe ExtensionType enum is defined as follows:\nToken Extensions/// Extensions that can be applied to mints or accounts. Mint extensions must\n/// only be applied to mint accounts, and account extensions must only be\n/// applied to token holding accounts.\n#[repr(u16)]\n#[cfg_attr(feature = \"serde-traits\", derive(Serialize, Deserialize))]\n#[cfg_attr(feature = \"serde-traits\", serde(rename_all = \"camelCase\"))]\n#[derive(Clone, Copy, Debug, PartialEq, TryFromPrimitive, IntoPrimitive)]\npub enum ExtensionType {\n /// Used as padding if the account size would otherwise be 355, same as a\n /// multisig\n Uninitialized,\n /// Includes transfer fee rate info and accompanying authorities to withdraw\n /// and set the fee\n TransferFeeConfig,\n /// Includes withheld transfer fees\n TransferFeeAmount,\n /// Includes an optional mint close authority\n MintCloseAuthority,\n /// Auditor configuration for confidential transfers\n ConfidentialTransferMint,\n /// State for confidential transfers\n ConfidentialTransferAccount,\n /// Specifies the default Account::state for new Accounts\n DefaultAccountState,\n /// Indicates that the Account owner authority cannot be changed\n ImmutableOwner,\n /// Require inbound transfers to have memo\n MemoTransfer,\n /// Indicates that the tokens from this mint can't be transferred\n NonTransferable,\n /// Tokens accrue interest over time,\n InterestBearingConfig,\n /// Locks privileged token operations from happening via CPI\n CpiGuard,\n /// Includes an optional permanent delegate\n PermanentDelegate,\n /// Indicates that the tokens in this account belong to a non-transferable\n /// mint\n NonTransferableAccount,\n /// Mint requires a CPI to a program implementing the \"transfer hook\"\n /// interface\n TransferHook,\n /// Indicates that the tokens in this account belong to a mint with a\n /// transfer hook\n TransferHookAccount,\n /// Includes encrypted withheld fees and the encryption public that they are\n /// encrypted under\n ConfidentialTransferFeeConfig,\n /// Includes confidential withheld transfer fees\n ConfidentialTransferFeeAmount,\n /// Mint contains a pointer to another account (or the same account) that\n /// holds metadata\n MetadataPointer,\n /// Mint contains token-metadata\n TokenMetadata,\n /// Mint contains a pointer to another account (or the same account) that\n /// holds group configurations\n GroupPointer,\n /// Mint contains token group configurations\n TokenGroup,\n /// Mint contains a pointer to another account (or the same account) that\n /// holds group member configurations\n GroupMemberPointer,\n /// Mint contains token group member configurations\n TokenGroupMember,\n /// Mint allowing the minting and burning of confidential tokens\n ConfidentialMintBurn,\n /// Tokens whose UI amount is scaled by a given amount\n ScaledUiAmount,\n /// Tokens where minting / burning / transferring can be paused\n Pausable,\n /// Indicates that the account belongs to a pausable mint\n PausableAccount,\n\n /// Test variable-length mint extension\n #[cfg(test)]\n VariableLenMintTest = u16::MAX - 2,\n /// Padding extension used to make an account exactly Multisig::LEN, used\n /// for testing\n #[cfg(test)]\n AccountPaddingTest,\n /// Padding extension used to make a mint exactly Multisig::LEN, used for\n /// testing\n #[cfg(test)]\n MintPaddingTest,\n}\nEach extension adds specialized functionality by including additional state that\nmust be initialized when creating a mint or token account. All extension\nspecific state is stored in the in the\ntlv_data\nfield, which follows the base account data type. The tlv_data (containing\nextension state) must be further deserialized according to the specific\nextension types enabled for that account.\nToken Extensions/// Encapsulates immutable base state data (mint or account) with possible\n/// extensions, where the base state is Pod for zero-copy serde.\n#[derive(Debug, PartialEq)]\npub struct PodStateWithExtensions<'data, S: BaseState + Pod> {\n /// Unpacked base data\n pub base: &'data S,\n /// Slice of data containing all TLV data, deserialized on demand\n tlv_data: &'data [u8],\n}\nExamples\nThe anchor-spl crate provides a\ntoken_2022_extensions\nmodule that contains helper functions and types for working with token extension\ninstructions.\nYou can find examples for how to work with Token Extensions in an Anchor program\nin this\nprogram examples repository.\nNote that while the anchor-spl crate provides helper functions for working\nwith Token Extensions, not all extension instructions have been fully\nimplemented yet. You may need to manually implement CPI calls for some\nextension instructions.PreviousTransfer TokensNextAnchor ReferencesOn this pageWhat are Token Extensions?ExamplesEdit on GitHub","tokens":1592,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258247242,"hash":"739b2cbd12c930dfe98984789db675e273603a20"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/more-types/run-validator-node","domain":"docs.arbitrum.io","title":"How to run a validator | Arbitrum Docs","text":"✏️Request an updateValidators are nodes that choose to participate in the rollup protocol to advance the state of the chain securely. Since the activation of BoLD, chains can now choose to make validation permissionless. You can learn more in the BoLD introduction.\nThis page describes the different strategies a validator may follow and provides instructions on how to run a validator for an Arbitrum chain.\nThis how-to assumes that you're familiar with the following:\n\nHow to run a full node (see instructions here)\nHow the Rollup protocol works\nHow BoLD works, if you're running a validator for a chain that has BoLD activated\nData availability, for how Rollup-mode and AnyTrust-mode chains differ in the data your validator must reconstruct\nHow to assign roles to a Nitro node, for how the validator role relates to the other node roles and what converting a node to a validator involves\n\nValidation strategies​\nValidators can be configured to follow a specific validation strategy. Here we describe what strategies are available in Nitro:\nStrategyDescriptionGas usageDefensiveThis validator will follow the chain and if it's local state disagrees with an onchain assertion, this validator will post a bond and create a challenge to defend the chainOnly acts if a bad assertion is foundStakeLatestThis validator will initially bond on the latest correct assertion found, and then move the bond whenever new correct assertions are created. It will also challenge any bad assertions that it finds (this strategy is only available in pre-BoLD chains)Gas used every time a new assertion is createdResolveNodesThis validator will stay bonded on the latest assertion found, resolve any unconfirmed assertions, and it will challenge any bad assertions that it findsGas used every time a new assertion is created and to resolve unconfirmed assertionsMakeNodesThis validator continuously creates new assertions, resolves any unconfirmed assertions, and challenges bad assertions found. Note that if there is more than one MakeNodes validator running, they might all try to create a new assertion simultaneously. In that case, only one will be successful, while the others will have their transactions revertedGas used to create new assertions, move the bond to the latest one, and resolve unconfirmed assertions\nThe watchtower strategy​\nOne more validation strategy is available for all types of nodes: watchtower. This strategy is enabled by default in all nodes (full and archive)—see Watchtower mode in the full node guide for the default-behavior context—and it doesn't require a wallet, as it never takes any action onchain.\nA node in watchtower mode will immediately log an error if an onchain assertion deviates from the locally computed chain state.\nfound incorrect assertion in watchtower mode\nTo verify that the watchtower mode is enabled, this line should appear in the logs:\nINFO [09-28|18:43:49.367] running as validator txSender=nil actingAsWallet=nil whitelisted=false strategy=Watchtower\nAdditionally, the following logs indicate whether all components are working correctly:\n\nThe log line validation succeeded shows that the node is validating chain blocks successfully\nThe log line found correct assertion shows that the node is finding assertions on the parent chain successfully\n\nWatchtower mode adds a small amount of execution and memory overhead to your node. You can deactivate this mode using the parameter --node.staker.enable=false.\nHow to run a validator node​\nThis section explains how to configure your node to act as a validator.\nStep 0: prerequisites​\nA validator node is a regular full node with validation enabled, so you'll have to know how to configure a full node. You can find instructions in the full node setup guide.\nAdditionally, you'll need a wallet with enough funds to perform actions onchain and enough tokens to bond. Keep in mind that:\n\nThe token used to perform actions onchain is the native token of the parent chain (usually ETH)\nFor chains with BoLD activated, the token used to bond depends on the chain configuration. For Arbitrum One and Arbitrum Nova, the staking token is WETH\nFor chains that don't have BoLD activated, the token used to bond is the native token of the parent chain (usually ETH)\n\nStep 1: configure and run your validator​\nOn top of the configuration of a regular full node, you'll need to configure the following parameters for it to act as a validator:\nParameterValueDescription--node.staker.enabletrueEnables validation--node.staker.strategyWatchtower, Defensive, StakeLatest, ResolveNodes, MakeNodesStrategy that your node will use--node.staker.parent-chain-wallet.private-key0xPrivateKeyPrivate key of the wallet used to perform the operations onchain. Use either private-key or password (below)--node.staker.parent-chain-wallet.passwordPasswordPassword of a wallet generated with nitro (see instructions here). Use either private-key (above) or password--node.bold.enabletrueEnables validation with BoLD (not needed if BoLD is not activated, only needed before Nitro v3.6.0)\nHere's an example of how to run a defensive validator for Arbitrum One:\ndocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.strategy=Defensive --node.staker.parent-chain-wallet.password=\"SOME SECURE PASSWORD\" --node.staker.strategy=Defensive\nStep 2: Verify that your node is running as a validator​\nTo verify that your node is acting as a validator, you can look for the following log line:\nINFO [09-28|18:43:49.367] running as validator txSender=0x... actingAsWallet=0x... whitelisted=true strategy=Defensive\nNote that strategy should be the configured strategy. txSender and actingAsWallet should both be present and not nil.\nFurthermore, the following logs will indicate that all components are working as intended:\n\nThe log line validation succeeded shows that the node is validating chain blocks successfully\nThe log line found correct assertion shows that the node is finding assertions on the parent chain successfully\n\nRun a validator for an Arbitrum chain​\nValidation for Arbitrum chains works the same way as for DAO-governed Arbitrum chains. However, as specified in How to run a node, you need to include the information of the chain when configuring your node by using --chain.info-json.\n--chain.info-json=<Orbit chain's info>\nAdditionally, keep in mind that some chains might not have BoLD activated yet, so BoLD-specific parameters will not be needed.\nAdvanced features​\nUse Nitro to create a wallet for your validator​\nClear passwords in the command lineThis section shows how to manage a validator wallet using a password. Like any command that requires passing a password or private key, you should take extra precautions to secure your credentials. Failure to protect your password may compromise your validator wallet.\nNitro includes a tool to create a validator wallet for a specific chain automatically. You can access it by using the option --node.staker.parent-chain-wallet.only-create-key and setting a password for the wallet with --node.staker.parent-chain-wallet.password.\nHere is an example of how to create a validator wallet for Arbitrum One and exit:\ndocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url=https://l1-mainnet-node:8545 --chain.id=42161 --node.staker.enable --node.staker.parent-chain-wallet.only-create-key --node.staker.parent-chain-wallet.password=\"SOME SECURE PASSWORD\"\nThe wallet file will be created under the mounted directory inside the <chain-name>/wallet/ directory (for example, arb1/wallet/ for Arbitrum One, or nova/wallet/ for Arbitrum Nova). Be sure to backup the wallet file, as it will be the only way to withdraw the bond when desired.\nOnce the wallet is created, you can instruct your validator to use it by adding the option --node.staker.parent-chain-wallet.password=\"SOME SECURE PASSWORD\" when running your node.\nUse environment variablesIf you prefer not to include your password in the command line, you can use environment variables or a secure secrets management solution to supply the password at runtime.\nHow to add new validators to the allowlist (Arbitrum chains)​\nOn permissioned validation setups, the set of validators that can act on a given chain is limited to the ones added to the allowlist of validators in the Rollup contract.\nFollow these instructions to add a new validator address to the allowlist. Remember that you need to be able to perform admin actions to the chain to complete this operation.\n\nFind your upgradeExecutor contract address\nCall the executeCall method of the upgradeExecutor contract:\n\nset the target address to your Rollup contract's address\nset the targetCalldata to 0xa3ffb772{Your new allowlist validator address} (0xa3ffb772 is the signature of setValidator(address[],bool[])). For example, if you want to add the address 0x1234567890123456789012345678901234567890, your targetCalldata should be 0xa3ffb7721234567890123456789012345678901234567890.\n\nCall your Rollup contract's isValidator(address) and check the result\n\nAfter performing this operation, the new validator will be able to run a validator node to participate in the chain.Validation strategiesThe watchtower strategyHow to run a validator nodeStep 0: prerequisitesStep 1: configure and run your validatorStep 2: Verify that your node is running as a validatorRun a validator for an Arbitrum chainAdvanced featuresUse Nitro to create a wallet for your validatorHow to add new validators to the allowlist (Arbitrum chains)","tokens":2425,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258247293,"hash":"6f9904fc956a80d2d47d463e849f3b37ff4e5076"}
{"url":"https://docs.pyth.network/price-feeds/core/push-feeds","domain":"docs.pyth.network","title":"Push Feeds | Pyth Developer Hub","text":"Pyth CorePush FeedsSee which Pyth price feeds receive sponsored push updates by networkThe Pyth Data Association pushes price updates for various feeds on some networks.\nThese feeds are updated at a specific heartbeat rate or when the price changes by a specific percentage.\nApplications can depend on receiving updates for these feeds, without having to pull them explicitly.\nHIP-3 as a Service\nFor deployers launching permissionless perpetual markets on Hyperliquid, Pyth Network offers a complete end-to-end solution that includes oracle data, managed infrastructure, capital support, and market operations. Learn more about HIP-3 as a Service.\nPush Feeds by Network\nThe feeds can vary by network. Please see the relevant section below for the network of interest.\n\nEVM\nSolana\nFogo\nSui\n\nDeviation thresholds can be customized to fit builders' needs, and additional\nfeeds can be requested for this list. If you need custom thresholds or would\nlike to see additional feeds, please fill in this\nform to signal your interest.\nPush feeds are subject to change with prior notice. Please refer to the dev-\nforum for the latest\nchanges.\nDISCLAIMER: While the Pyth Data Association strives to deliver timely updates,\nthese push feeds may occasionally experience delays in updates caused by chain\nhalts, gas estimations and other issues. Applications are advised to run their\nown price-pusher. Find out how you can run your own price-pusher\nhere.Current FeesPyth Core update fees are zero on every supported networkHIP-3 as a ServiceNext Page","tokens":384,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258247356,"hash":"1ddb6357c70c98614f7677912f028544041b2309"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/more-types/run-archive-node","domain":"docs.arbitrum.io","title":"How to run an archive node | Arbitrum Docs","text":"✏️Request an updateAn Arbitrum archive node is an Arbitrum full node that maintains an archive of historical chain states. This how-to walks you through the process of configuring an archive node on your local machine so that you can query both pre-Nitro and post-Nitro state data.\nFor how archive mode relates to the other Nitro node roles, see How to assign roles to a Nitro node.\ncautionMost users won't need to configure an archive node. This node type is great for a small number of use cases––for example if you need to process historical data.\nBefore we begin​\nBefore the Nitro upgrade, Arbitrum One ran on the Classic stack for a year (before block height 22207817). Although the Nitro chain uses the latest snapshot of the Classic chain's state as its genesis state, the Nitro stack can serve all but six RPC requests for pre-Nitro blocks. Full details are outlined in Do you need to run a Classic node?.\nRunning an Arbitrum One full node in archive mode lets you access both pre-Nitro and post-Nitro blocks, but it requires you to run both Classic and Nitro nodes together. You may not need to do this, depending on your use case:\nUse caseRequired node type(s)DocsAccess the Arbitrum network without running your own nodeFully managed by third-parties, exposed via RPC endpointsRPC endpoints and providersRun an archive node for Arbitrum Sepolia (testnet) or Arbitrum NovaFull node (Nitro)How to run a full node (Nitro)Send post-Nitro archive requestsFull node (Nitro)How to run a full node (Nitro)Send pre-Nitro archive requestsFull node (Classic)How to run a full node (Classic, pre-Nitro)Send post-Nitro and pre-Nitro archive requestsFull node (Nitro) and full node (Classic)That's what this how-to is for; you're in the right place.\nUse PathDB for archive nodes​\nWe recommend PathDB for archive nodes on Nitro v3.9.x or later. PathDB is a path-based state scheme. It cuts archive disk use substantially, and while syncing and serving RPC calls a PathDB archive node performs about the same as, or slightly better than, a HashDB one.\nBenefits:\n\nLower disk usage. The Arbitrum One archive-path snapshot is about 3.7 TB. The equivalent HashDB archive snapshot is considerably larger — Nova's is about 8 TB, for a chain whose full node database is a quarter the size of Arbitrum One's.\nAutomatic, online pruning. PathDB removes old state as the node runs, without your intervention. You never schedule a prune, and the node never goes offline to run one. On HashDB you prune manually, and the node stops serving RPC requests until it finishes—days, on a chain the size of Arbitrum One. This benefit applies to full nodes on PathDB too.\nConfigurable retention. You choose how much state history to keep with --execution.caching.state-history.\n\nLimitations:\n\nPathDB cannot validate blocks. If a node requires the block validator, Nitro exits at startup with path cannot be used as execution.caching.state-scheme when validator is required.\nFast, local NVMe SSD storage is required for reasonable sync speed.\n--init.latest cannot download a PathDB snapshot. Use --init.url, as described in Initialize a PathDB archive node.\n\nTo enable PathDB on your archive node, start it with these flags:\nFlagPurpose--execution.caching.archiveEnables archive mode; under PathDB, builds the state-history index so RPC can serve historical state--execution.caching.state-scheme=pathSelects PathDB instead of the default HashDB\nOn Nitro before v3.10.0, also set `--execution.caching.state-history=0`--execution.caching.state-history controls how many blocks of state history PathDB retains. From v3.10.0 onward, setting --execution.caching.archive makes it default to 0, which keeps the entire chain, so you can leave it unset.Before v3.10.0 it defaulted to 24 hours' worth of blocks even in archive mode. Nitro logs a warning — Path scheme archive mode enabled, but state-history is not zero—and then silently retains only recent history, leaving you with an archive node that cannot serve older state. Pass --execution.caching.state-history=0 explicitly on those versions.\nFor cache sizing and memory tuning that applies to archive nodes generally, see node tuning and monitoring.\nInitialize a PathDB archive node​\nA snapshot only works with a node whose state scheme matches the snapshot's. --init.latest accepts only archive, pruned, and genesis, and all three resolve to HashDB snapshots, so it cannot bootstrap a PathDB node.\nInstead, pass the archive-path snapshot URL to --init.url. These snapshots are published for Arbitrum One and Arbitrum Sepolia only; Arbitrum Nova has no archive-path snapshot.\nEach chain publishes a pointer file naming its current archive-path snapshot directory. Read that file to find the URL:\ncurl https://snapshot.arbitrum.foundation/arb1/latest-archive-path.txt\nThe file contains a directory path, such as arb1/2026-08-02-291ce8d7/. Pass the full URL to that directory, including the trailing slash:\n--init.url https://snapshot.arbitrum.foundation/arb1/2026-08-02-291ce8d7/\nNitro reads the .manifest.txt file in that directory to enumerate the snapshot parts, downloads each one, and verifies its checksum. The directory also holds a metadata.json naming the snapshot's state_scheme, snapshot_kind, and total size, so you can confirm you have the right snapshot before downloading terabytes.\nFor Arbitrum Sepolia, substitute sepolia-rollup for arb1 in both URLs.\nSystem requirements​\nThe minimum storage requirements will change as the Nitro chains grow (see the growth rates below). We recommend exceeding the minimum requirements as much as you can to minimize risk and maintenance overhead. The disk size for archive nodes is expected to grow over time. Carefully monitor your node's disk requirements and disk growth rates to ensure your node has adequate resources.\n\nResourceMinimum requirementsRecommendedRAM (DDR5)64 GB128 GB or moreCPU8 core 3rd generation CPUs (for AWS, a i4i.2xlarge instance)16 core CPU or higher and more recent/newer generation of CPUsStorage typeNVMe SSD drives with locally attached drives strongly recommendedSameStorage sizeDepends on the chain and its traffic over time, but ideally several terabytes (TB)Same, but higher if possible\n\nDocker images: We'll specify these in the below commands; you don't need to download them manually.\n\nLatest Docker image for Arbitrum One Nitro: offchainlabs/nitro-node:v3.12.1-70fa99a\nLatest Docker image for Arbitrum One Classic: offchainlabs/arb-node:v1.4.6-551a39b3\n\nDatabase snapshots:\n\nNitro database snapshot\n\nUse the parameter --init.url= on the first startup to initialize the Nitro database (you can find a list of snapshots here). Example: --init.url=\"https://snapshot.arbitrum.foundation/arb1/nitro-archive.tar\"\n\nArbitrum One Classic database snapshot\n\nDownload the latest Arbitrum One Classic database snapshot at https://snapshot.arbitrum.foundation/arb1/classic-archive.tar and place it in the mounted point directory\nNote that other chains don't have Classic blocks and thus don't require an initial genesis database.\n\nSnapshot Explorer\n\nYou can find more snapshots on our snapshot explorer\n\nArchive-Path section of the snapshot explorer\n\nReview and configure ports​\n\nRPC: 8547\nSequencer Feed: 9642\nWebSocket: 8548\n\nReview and configure parameters​\nArbitrum NitroArbitrum ClassicDescription--parent-chain.connection.url=<Layer 1 Ethereum RPC URL>--l1.url=<Layer 1 Ethereum RPC URL>Provide a standard L1 node RPC endpoint that you run yourself or from a third-party node provider (see RPC endpoints and providers)--chain.id=<L2 chain ID>--l2.chain-id=<L2 Chain ID>See RPC endpoints and providers for a list of Arbitrum chains and the respective child chain IDs--execution.caching.archive--node.caching.archiveRequired for running an Arbitrum One Nitro archival node and retains past block state--execution.caching.state-scheme-Default: hash. Sets the scheme Nitro uses to store its state trie, inherited from Geth. Set it to path to enable PathDB. PathDB cannot validate blocks.--execution.caching.state-history-PathDB only. Number of recent blocks of state history to retain on disk. On an archive node, leave it unset: from Nitro v3.10.0 onward, --execution.caching.archive makes it default to 0, which retains the entire chain. Before v3.10.0, the default was 345,600 blocks (24 hours), so set --execution.caching.state-history=0 explicitly.--execution.caching.pathdb-max-diff-layers-Default: 128 layers. Maximum number of diff layers kept in the node's memory before flushing to disk. Increasing the number of diff layers may cause the node to fall behind the chain head during busy periods since doing so slows down block processing speed and reduces sync speed. This configuration is primarily used to improve performance of shallow re-orgs (which are a concern on Ethereum but not on Arbitrum chains) and for efficient access to recent state.---node.cache.allow-slow-lookupRequired for running an Arbitrum One Classic archival node. When this option is present, it will load old blocks from disk if not in memory cache.---core.checkpoint-gas-frequency=156250000Required for running an Arbitrum One Classic archival node.\nRun the Docker image(s)​\nWhen running a Docker image, an external volume should be mounted to persist the database across restarts. The mount point should be /home/user/.arbitrum/mainnet.\nTo run both Arbitrum Nitro and/or Arbitrum Classic in archive mode, follow one or more of the below examples:\n\nArbitrum One Nitro archive node:\ndocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive\n\nArbitrum One Classic archive node:\ndocker run --rm -it -v /some/local/dir/arbitrum-mainnet/:/home/user/.arbitrum/mainnet -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/arb-node:v1.4.6-551a39b3 --l1.url=https://l1-node:8545/ --node.chain-id=42161 --l2.disable-upstream --node.cache.allow-slow-lookup --core.checkpoint-gas-frequency=156250000 --core.lazy-load-core-machine\n\nArbitrum One Nitro archive node with forwarding classic execution support:\ndocker run --rm -it -v /some/local/dir/arbitrum:/home/user/.arbitrum -p 0.0.0.0:8547:8547 -p 0.0.0.0:8548:8548 offchainlabs/nitro-node:v3.12.1-70fa99a --parent-chain.connection.url https://l1-node:8545 --chain.id=42161 --execution.rpc.classic-redirect=<classic node RPC> --http.api=net,web3,eth --http.corsdomain=* --http.addr=0.0.0.0 --http.vhosts=* --execution.caching.archive\n\nNote that the above commands both map to port 8547 on their hosts. To run both on the same host, you should edit those mapping to different ports and specify your Classic node RPC URL as <classic node RPC> in your Nitro start command. To verify the connection health of your node(s), see Docker network between containers - Docker Networking Example.\nA note on permissions​\nThe Docker image is configured to run as non-root UID 1000. If you're running in Linux and you're getting permission errors when trying to run the Docker image, run this command to allow all users to update the persistent folders, replacing arbitrum-mainnet as needed:\nmkdir /some/local/dir/arbitrum-mainnetchmod -fR 777 /some/local/dir/arbitrum-mainnet\nOptional parameters​\nBoth Nitro and Classic have multiple other parameters that can be used to configure your node. For a full comprehensive list of the available parameters, use the flag --help.\nPathDB configuration reference​\n\nThese flags apply only when you set --execution.caching.state-scheme=path.\n--execution.caching.state-scheme​\nSelects the TrieDB implementation Nitro uses to store its state trie. Set it to path to enable PathDB; the default is hash.\nThe two schemes are not interchangeable. A node can only start from a snapshot created with the same state scheme, so you cannot convert an existing database. To move to PathDB, either start from a path-scheme snapshot or sync from genesis. On Arbitrum One, syncing from genesis also requires a Classic state import.\n--execution.caching.state-history​\nSets how many blocks of state history Nitro retains, counting back from the chain head. 0 means the entire chain, and is therefore required — but not enough on its own — to run an archive node on PathDB. You also need --execution.caching.archive, described below.\nWhen you leave --execution.caching.state-history unset, Nitro chooses the default at startup:\nNode typeDefault state-historyFull node (--execution.caching.archive=false)345,600 blocks — 24 hours at the default 250 ms block speedArchive node (--execution.caching.archive=true)0, meaning the entire chain\nFrom v3.10.0, Nitro derives this default from the archive flag. On earlier versions the default was always 24 hours' worth of blocks, so an archive node needs an explicit --execution.caching.state-history=0.\nNitro stores state history as reverse diffs in the cold database, also called the state freezer or ancients. State history lets the node recover historical state, which should allow a reorg to a historical block. Offchain Labs has not tested that reorg path.\nState history alone does not let RPC calls read historical state. For that, see --execution.caching.archive below. Here, historical state means state older than pathdb-max-diff-layers + 1 blocks — 129 by default — from the node's current head.\n--execution.caching.archive​\nEnables archive mode. Under PathDB, archive mode also builds the state history index, an extra dataset Nitro persists in the hot database (Pebble). That index is what allows RPC calls to read state older than pathdb-max-diff-layers + 1 blocks from the head.\n--execution.caching.pathdb-max-diff-layers​\nSets the maximum number of diff layers Nitro keeps in memory before flushing to disk. Default: 128.\nRaising it can make the node fall behind the chain head during busy periods, because it slows block processing and reduces sync speed. It mainly improves performance for shallow reorgs, which matter on Ethereum but not on Arbitrum chains, and for efficient access to recent state.\nTroubleshooting​\nIf you run into any issues, visit the node-running troubleshooting guide.Before we beginUse PathDB for archive nodesInitialize a PathDB archive nodeSystem requirementsReview and configure portsReview and configure parametersRun the Docker image(s)A note on permissionsOptional parametersPathDB configuration reference--execution.caching.state-scheme--execution.caching.state-history--execution.caching.archive--execution.caching.pathdb-max-diff-layersTroubleshooting","tokens":3663,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258269249,"hash":"e5bace2423341cf6e84990984e985a6afbf2959d"}
{"url":"https://www.anchor-lang.com/docs/references","domain":"anchor-lang.com","title":"Anchor References","text":"Anchor ReferencesReference documentation for the Anchor framework.Account TypesAnchor Account Type ExamplesAccount ConstraintsAnchor Account Constraints ExamplesAnchor.toml ConfigurationAnchor workspace config reference documentationAnchor CLIAnchor CLI reference documentationNO_DNAReference documentation for Anchor's NO_DNA supportAnchor Version ManagerAVM reference documentationAccount SpaceReference guide for calculating account data size (bytes) requirements by Rust typeRust to JS Type ConversionReference for how Anchor converts between Rust and TypeScript typesVerifiable BuildsAnchor - Verifiable BuildsSealevel AttacksAnchor - Sealevel AttacksExample ProgramsExample Anchor programs referencesPreviousExtensionsNextAccount TypesOn this pageNo HeadingsEdit on GitHub","tokens":195,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258270554,"hash":"6625896de9eea56981204a1f2b47d9cd7872c435"}
{"url":"https://docs.pyth.network/price-feeds/hip-3-service","domain":"docs.pyth.network","title":"HIP-3 as a Service | Pyth Developer Hub","text":"Pyth CorePush FeedsHIP-3 as a ServiceComplete oracle solution for Hyperliquid HIP-3 perpetual market deployersPyth Network provides HIP-3 as a Service, a complete end-to-end solution for deployers launching permissionless perpetual markets on Hyperliquid. This service combines institutional-grade data, managed infrastructure, capital support, and market operations to help you successfully deploy and maintain HIP-3 markets.\nNew to HIP-3? Learn about Hyperliquid's permissionless perpetual markets in\nthe official Hyperliquid\ndocumentation.\nWhat You Get\nHIP-3 as a Service provides everything you need to launch and maintain a successful perpetual market on Hyperliquid:\nOracle Data & InfrastructureFirst-party data with automated updates and 24/7 monitoringCapital & Liquidity SupportMarket maker relationships, loan capital, and HYPE sourcingSecurity & Go-to-MarketAudit discounts, 24/7 support, and co-marketing\nWhat problem this solves\nDeploying and operating a HIP-3 market typically requires all of the following:\n\nMaintaining continuous oracle updates every 3 seconds to meet HIP-3 requirements\nSecuring keys and operational processes to reduce downtime and update failures\nCoordinating market-maker liquidity and launch operations\n\nHow It Works\nThe HIP-3 pusher service monitors price changes and submits signed updates to the Hyperliquid blockchain whenever specific conditions are met (e.g., price deviation or time-based heartbeat).\n\nData Sourcing: The relayer is fully configurable and can connect to any data source that exposes price data via REST API or WebSocket. You can use Pyth Core, Pyth Pro, SEDA or Hyperliquid, or plug in your own custom data feeds.\nRobustness & Redundancy: The service supports fallback configurations to ensure reliability—if the primary data source is unavailable, the next source in the priority chain is used.\nSubmission: Signed transactions are sent to the Hyperliquid validator network to update the market's oracle state.\n\nWhy Pyth\nPyth Network offers unique advantages that make it the ideal oracle partner for your HIP-3 market:\nFirst-Party Data\nPyth sources data directly from 120+ institutional publishers including exchanges, market makers, and trading firms. This eliminates single points of failure that affect aggregated data providers.\nMarket Maker Trust\nPyth's market maker publishers (Jump, Flowdesk, IMC, Amber, Selini) trust Pyth data because they create it themselves. This leads to:\n\nHigher engagement rates for Pyth-powered markets\nFaster liquidity onboarding\n\nRedundant Infrastructure\n\nPrimary, secondary, and tertiary infrastructure across multiple regions\nMulti-cloud key management with automatic failover\nSupport for multisig oracle updates for operational flexibility\n\nGet Started\nReady to launch your HIP-3 market? Get in touch with our team to discuss your requirements and get started.\nRequest AccessFill out our contact form to get started with HIP-3 as a Service.Push FeedsSee which Pyth price feeds receive sponsored push updates by networkon EVMList of Push Feeds on EVM networks","tokens":765,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258270680,"hash":"4f84b78a8d71fbb1e2baa20164cc789548703eaf"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/reference/node-providers","domain":"docs.arbitrum.io","title":"RPC endpoints and providers | Arbitrum Docs","text":"✏️Request an updateArbitrum public RPC endpoints​\ncaution\nUnlike the RPC Urls, the Sequencer endpoints only support eth_sendRawTransaction and eth_sendRawTransactionConditional calls.\nArbitrum public RPCs do not provide Websocket support.\nIPv6 is not supported.\n\nThis section provides an overview of the available public RPC endpoints for different Arbitrum chains and necessary details to interact with them.\nNameRPC Url(s)Chain IDBlock explorerUnderlying chainTech stackSequencer feed URLSequencer endpoint⚠️Arbitrum Onehttps://arb1.arbitrum.io/rpc42161Arbiscan, BlockscoutEthereumNitro (Rollup)wss://arb1-feed.arbitrum.io/feedhttps://arb1-sequencer.arbitrum.io/rpcArbitrum Novahttps://nova.arbitrum.io/rpc42170BlockscoutEthereumNitro (AnyTrust)wss://nova-feed.arbitrum.io/feedhttps://nova-sequencer.arbitrum.io/rpcArbitrum Sepolia (Testnet)https://sepolia-rollup.arbitrum.io/rpc421614Arbiscan, BlockscoutSepoliaNitro (Rollup)wss://sepolia-rollup.arbitrum.io/feedhttps://sepolia-rollup-sequencer.arbitrum.io/rpc\nMore RPC endpointsMore Arbitrum chain RPC endpoints can be found in Chain Connect: Arbitrum One and Arbitrum Nova.\nAlternatively, to interact with public Arbitrum chains, you can rely on many of the same popular node providers that you are already using on Ethereum:\nThird-party RPC providers​\nWANT TO BE LISTED HERE?Complete this form , if you'd like to see your project added to this list (and the Arbitrum portal).\nNeed support for Nova 3rd party tooling?Complete this form to submit a support request.\nProviderArb One?Arb Nova?Arb Sepolia?Websocket?Stylus Tracing?1RPC✅Alchemy✅✅✅Available on paid plansAllnodes✅✅✅All That Node✅✅✅Ankr✅✅Available on paid plansBlockPi✅✅Chainbase✅✅Chainnodes✅Chainstack✅✅Available on paid plansdRPC✅✅✅✅GetBlock✅✅Infura✅✅✅Enabled on requestLava✅✅Moralis✅Nirvana Labs✅✅✅✅NodeReal✅✅NOWNodes✅Pocket Network✅PublicNode✅✅✅Quicknode✅✅✅✅Testnet supported in free tierSwiftNodes✅✅Tenderly✅✅✅Testnet supported in free tierUnifra✅Validation Cloud✅✅✅Testnet supported in free tier\nCompare provider latency​\nFor a live latency comparison of the public no-key Arbitrum endpoints listed above, see the OpenChainBench Arbitrum RPC benchmark tool. Measurements are probed from three regions every minute and published as p50, p95 and p99 latency under an open methodology and CC BY 4.0 license.\nSequencer endpoint behavior​\nArbitrum One exposes two public endpoints with different roles, shown below: a general-purpose public RPC URL, and a direct sequencer endpoint that accepts only eth_sendRawTransaction and eth_sendRawTransactionConditional. The table below summarizes how they differ in purpose and operational guarantees.\nThe two endpoints at a glance​\nEndpointPurposeOperational guaranteeshttps://arb1.arbitrum.io/rpc (public RPC URL)General-purpose read/write endpoint, useful for development and low-volume reads.No uptime, latency, or rate-limit guarantees. Any application that depends on availability should use a third-party node provider or run its own node.https://arb1-sequencer.arbitrum.io/rpc (sequencer endpoint)Direct submission path to the chain's sequencer for write traffic. Accepts only eth_sendRawTransaction and eth_sendRawTransactionConditional.Exposes the defined queueing and timeout behavior described below, but it is still a best-effort public endpoint with no formal SLA.\nLatency and timeout behavior​\nUnder nominal load, transactions submitted to the sequencer endpoint are accepted in well under a second. Internally, the sequencer places submissions into a bounded in-memory queue (default capacity 1024). The queue timeout (default 12 seconds) bounds how long a submitted transaction may remain pending in the sequencer's background queue before being picked up or rejected; it does not provide a formal end-to-end inclusion latency guarantee. If the transaction is not picked up within that window, eth_sendRawTransaction returns context deadline exceeded, and the transaction was not accepted—it is safe to retry.\nRecommended fallback patterns​\n\nUse a third-party node provider as your primary endpoint, or as a fallback when a direct sequencer submission fails.\nRetry on transient errors only—context deadline exceeded and network/connection errors are safe to retry with backoff. Do not retry terminal errors such as nonce too low or contract reverts.\n\nMonitoring and alerting​\nA successful eth_sendRawTransaction response means the sequencer has already sequenced your transaction into an L2 block—the call blocks until the block is created and returns only then, not merely when the transaction is enqueued. Treat this as the sequencer's soft confirmation that your transaction has been ordered and executed. It does not by itself mean the transaction has been posted to the parent chain in a batch or finalized there; if your application needs parent-chain finality guarantees, track that separately. For monitoring, alert on submission calls that return errors or exceed your expected latency ceiling rather than assuming a pending-but-unconfirmed state.Arbitrum public RPC endpointsThird-party RPC providersSequencer endpoint behaviorThe two endpoints at a glanceLatency and timeout behaviorRecommended fallback patternsMonitoring and alerting","tokens":1305,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258279207,"hash":"4fec93d9d899d42cc615209ff80546e5f6409045"}
{"url":"https://www.anchor-lang.com/docs/references/avm","domain":"anchor-lang.com","title":"Anchor Version Manager","text":"Program DevelopmentAnchor Version ManagerAVM reference documentationAnchor Version Manager (avm) is provided to manage multiple installations of the\nanchor-cli binary. This may be required to produce verifiable builds, or if\nyou'd prefer to work with an alternate version.\n\nAnchor version manager\n\nUSAGE:\n avm <SUBCOMMAND>\n\nOPTIONS:\n -h, --help Print help information\n -V, --version Print version information\n\nSUBCOMMANDS:\n help Print this message or the help of the given subcommand(s)\n install Install a version of Anchor\n list List available versions of Anchor\n uninstall Uninstall a version of Anchor\n update Update to the latest Anchor version\n use Use a specific version of Anchor\n solana Resolve or install the Solana CLI for the current project\n platform-tools Inspect or manage the Solana platform-tools toolchain\n self-update Update avm itself to the latest version\nInstall\navm install <VERSION_OR_COMMIT>\nInstall the specified version of anchor-cli. The version argument should follow\nsemver versioning. It is also possible to use latest as the version argument\nto install the latest stable version, or latest-pre-release for the latest\npre-release:\navm install latest\navm install latest-pre-release\nIt's also possible to install based on a specific commit hash or a pre-release\nversion tag:\n# Specific pre-release\navm install 1.0.0-rc.3\n\n# <VERSION>-<COMMIT>\navm install 0.30.1-cfe82aa682138f7c6c58bf7a78f48f7d63e9e466\n\n# Full commit hash\navm install cfe82aa682138f7c6c58bf7a78f48f7d63e9e466\n\n# Short commit hash\navm install cfe82aa\nList\navm list [--pre-release]\nList available versions. Pass --pre-release to include pre-release versions\nin the output:\navm list --pre-release\nUninstall\navm uninstall <version>\nUpdate\navm update [--pre-release]\nUpdate to the latest stable version. Pass --pre-release to allow updating to\nthe latest pre-release instead:\navm update --pre-release\nUse\navm use <version>\nUse a specific version. This version will remain in use until you change it by\ncalling the same command again. Similarly to avm install, you can use\nlatest or latest-pre-release for the version argument:\navm use latest\navm use latest-pre-release\nSolana\navm solana resolve\navm solana install [version] [--force]\nResolve or install the Solana CLI version for the current project. When no\nversion is passed to install, AVM first checks [toolchain] solana_version\nin Anchor.toml, then the solana-program dependency in Cargo.toml. If the\nproject does not pin Solana directly, AVM resolves the Anchor version and maps\nit to Anchor's recommended Solana version.\nProject Solana versions are parsed as semver requirements. AVM chooses the\nnewest hosted Solana CLI installer that satisfies the requirement; use an exact\ncomparator such as =4.1.2 to require one specific hosted version.\nWhen anchor is invoked through the AVM stub, AVM also ensures the resolved\nSolana CLI version is active before spawning the selected anchor-cli binary.\nPlatform Tools\navm platform-tools resolve\navm platform-tools install [version] [--force]\navm platform-tools list\navm platform-tools uninstall <version>\nResolve or manage the platform-tools version used by Solana's SBF toolchain.\nWhen no version is passed to install, AVM uses the project-resolved Solana\nversion and the embedded platform-tools map. If the Solana version is a semver\nrequirement, AVM considers hosted Solana CLI versions satisfying that\nrequirement and prefers one whose platform-tools rustc can compile the locked\nprogram dependency graph.\nAVM also queries the latest platform-tools release at most once every 24 hours\nand checks whether it is present in cargo build-sbf's cache. If it is\nmissing, AVM prints the exact cargo build-sbf --install-only command needed\nto install it; it never installs the toolchain automatically.\nSelf-update\navm self-update [--pre-release] [--bleeding-edge]\nUpdate avm itself. By default installs the latest stable release of avm.\nFlagDescription--pre-releaseUpdate to the latest pre-release version instead of the latest stable--bleeding-edgeBuild and install from the latest commit on the master branch (conflicts with --pre-release)\n# Update avm to latest stable\navm self-update\n\n# Update avm to latest pre-release\navm self-update --pre-release\n\n# Install from the tip of master\navm self-update --bleeding-edge\navm will also passively warn you when it detects that a newer version of\nitself is available.PreviousNO_DNANextAccount SpaceOn this pageInstallListUninstallUpdateUseSolanaPlatform ToolsSelf-updateEdit on GitHub","tokens":1128,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258280470,"hash":"505d6779d6bae77bd0c6a8ac719f1f6d70fb534b"}
{"url":"https://docs.pyth.network/price-feeds/core/current-fees","domain":"docs.pyth.network","title":"Current Fees | Pyth Developer Hub","text":"Pyth CoreCurrent FeesPyth Core update fees are zero on every supported networkThe Pyth Core update fee is 0 across all mainnet EVM chains. Pyth governance\nzeroed the fee in OP-PIP-128\nas part of the Pyth Core sunset, so there is no\nlonger a per-chain fee schedule to consult.\nPassing 0 as msg.value to updatePriceFeeds is sufficient on every network.\nIntegrations that call getUpdateFee keep working unchanged — it returns the\nauthoritative fee for a given chain, which is now 0.Asset ClassesOverview of the asset classes covered by Pyth price feedsPush FeedsSee which Pyth price feeds receive sponsored push updates by network","tokens":157,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258281643,"hash":"161d5f9b5a0a41465a69e3d959845481edead08d"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/reference/contract-addresses","domain":"docs.arbitrum.io","title":"Smart contract addresses | Arbitrum Docs","text":"✏️Request an update\n\nThe following information may be useful to those building on Arbitrum. We list the addresses of the smart contracts related to the protocol, the token bridge and precompiles of the different Arbitrum chains.\nProtocol smart contracts​\nCore contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaRollup0x4DCe...Cfc00xE7E8...B7Bd0xd808...81C8Sequencer Inbox0x1c47...82B60x211E...c21b0x6c97...be0DCoreProxyAdmin0x5547...2dbD0x71D7...71480x1ed7...0686\nCross-chain messaging contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaDelayed Inbox0x4Dbd...AB3f0xc444...39490xaAe2...ae21Bridge0x8315...ed3a0xC1Eb...76Bd0x38f9...33a9Outbox0x0B98...48400xD4B8...cc580x65f0...B78FClassic Outbox***0x7607...1A40 0x667e...337a\n***Migrated Network Only\nFraud proof contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaChallengeManager0xA556...9fB00xFE66...A6880xC60b...8B4COneStepProver00x35FB...F7310x35FB...F7310x3Fe7...1377OneStepProverMemory0xe0ba...C48b0xe0ba...C48b0x6268...ec2dOneStepProverMath0xaB95...F9210xaB95...F9210x42f5...e8FaOneStepProverHostIo0xa07c...71Cf0xa07c...71Cf0xdB2c...C165OneStepProofEntry0x4397...42d60x4397...42d60xB9cf...AE80\nToken bridge smart contracts​\nCore contracts​\nThe following contracts are deployed on Ethereum (L1)\nArbitrum OneArbitrum NovaArbitrum SepoliaL1 Gateway Router0x72Ce...31ef0xC840...cD480xcE18...8264L1 ERC20 Gateway0xa3A7...0EeC0xB253...21bf0x902b...3aFFL1 Arb-Custom Gateway0xcEe2...180d0x2312...232f0xba2F...40F3L1 Weth Gateway0xd920...e2db0xE4E2...0BaE0xA8aD...0e1EL1 Weth0xC02a...6Cc20xC02a...6Cc20x7b79...E7f9L1 Proxy Admin0x9aD4...0aDa0xa8f7...e5600xDBFC...44b0\nThe following contracts are deployed on the corresponding L2 chain\nArbitrum OneArbitrum NovaArbitrum SepoliaL2 Gateway Router0x5288...F9330x2190...DFa80x9fDD...43C7L2 ERC20 Gateway0x09e9...1EEe0xcF9b...92570x6e24...b502L2 Arb-Custom Gateway0x0967...55620xbf54...51F40x8Ca1...42C5L2 Weth Gateway0x6c41...623B0x7626...D9eD0xCFB1...556DL2 Weth0x82aF...Bab10x722E...53650x980B...7c73L2 Proxy Admin0xd570...2a860xada7...d92C0x715D...5FdF\nPrecompiles​\nThe following precompiles are deployed on every L2 chain and always have the same address\nArbitrum OneArbitrum NovaArbitrum SepoliaArbAddressTable0x0000...00660x0000...00660x0000...0066ArbAggregator0x0000...006D0x0000...006D0x0000...006DArbFunctionTable0x0000...00680x0000...00680x0000...0068ArbGasInfo0x0000...006C0x0000...006C0x0000...006CArbInfo0x0000...00650x0000...00650x0000...0065ArbOwner0x0000...00700x0000...00700x0000...0070ArbOwnerPublic0x0000...006b0x0000...006b0x0000...006bArbRetryableTx0x0000...006E0x0000...006E0x0000...006EArbStatistics0x0000...006F0x0000...006F0x0000...006FArbSys0x0000...00640x0000...00640x0000...0064ArbWasm0x0000...00710x0000...00710x0000...0071ArbWasmCache0x0000...00720x0000...00720x0000...0072NodeInterface0x0000...00C80x0000...00C80x0000...00C8\nMisc​\nThe following contracts are deployed on the corresponding L2 chain\nFunctionArbitrum OneArbitrum NovaArbitrum SepoliaL2 Multicall0x842e...4EB20x5e1e...cB860xA115...d092ResourceConstraintManager0x8F59...823a0x653e...86B7\nCanonical factory contracts​\nThe following factory contracts are deployed on the corresponding chain and are used to deploy new Arbitrum chains (RollupCreator) and their token bridges (TokenBridgeCreator). For factory contracts on additional chains (Ethereum, Base, and testnets) and deployment instructions, see Canonical factory contracts.\nArbitrum OneArbitrum NovaArbitrum SepoliaRollupCreator0xB90e...eB8b0xF916...60F40x5F45...16cFTokenBridgeCreator0x2f56...000e0x8B9D...8c140x56C4...bD8E;","tokens":933,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258289100,"hash":"7220255f7c8c68071b5bc82abe5196784a48eca2"}
{"url":"https://www.anchor-lang.com/docs/references/account-types","domain":"anchor-lang.com","title":"Account Types","text":"Program DevelopmentAccount TypesAnchor Account Type ExamplesMinimal reference examples for Anchor\naccount types.\nSee the account types\nsource code\nfor implementation details.\nPersistence on exitTyped accounts (Account, InterfaceAccount, AccountLoader,\nLazyAccount, Migration, also when wrapped in Box or Option) are\nwritten back to the account data when the instruction returns if the account\nis still owned by the program and has not been closed. If ownership moved\nduring the instruction, for example because the account was reassigned via\nCPI, the account is not written: exit succeeds when the account data already\nmatches the in-memory value and fails with AccountOwnedByWrongProgram\notherwise. Call exit before such a CPI to persist pending changes.\nAccount Types\nAccount<'info, T>\nDescription: Account container that checks ownership on deserialization\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub account: Account<'info, CustomAccountType>,\n}\n\n#[account]\npub struct CustomAccountType {\n data: u64,\n}\nAccountInfo<'info>\nDescription: AccountInfo can be used as a type but Unchecked Account should be\nused instead\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n /// CHECK: AccountInfo is an unchecked account\n pub unchecked_account: AccountInfo<'info>,\n}\nAccountLoader<'info, T>\nDescription: Type facilitating on demand zero copy deserialization\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub account: AccountLoader<'info, ZeroCopyAccountType>,\n}\n\n#[account(zero_copy)]\npub struct ZeroCopyAccountType {\n data: u64,\n}\nBox<Account<'info, T>>\nDescription: Box type to save stack space\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub account: Box<Account<'info, AccountType>>,\n}\nInterface<'info, T>\nDescription: Type validating that the account is one of a set of given\nPrograms\nExamples: Github\n|\nSolpg\nsnippet// Token program or Token2022 program\nuse anchor_spl::token_interface::TokenInterface;\n\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub program: Interface<'info, TokenInterface>,\n}\nInterfaceAccount<'info, T>\nDescription: Account container that checks ownership on deserialization\nExamples: Github\n|\nSolpg\nsnippet// Token program or Token2022 program Mint/TokenAccount\nuse anchor_spl::token_interface::{Mint, TokenAccount, TokenInterface};\n\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub mint: InterfaceAccount<'info, Mint>,\n pub token: InterfaceAccount<'info, TokenAccount>,\n pub program: Interface<'info, TokenInterface>,\n}\nOption<Account<'info, T>>\nDescription: Option type for optional accounts\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub account: Option<Account<'info, AccountType>>,\n}\nProgram<'info, T>\nDescription: Type validating that the account is the given Program\nExamples: Github\n|\nSolpg\nsnippetuse anchor_spl::token::Token;\n\n#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub system_program: Program<'info, System>,\n pub token_program: Program<'info, Token>,\n}\nSigner<'info>\nDescription: Type validating that the account signed the transaction\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub signer: Signer<'info>,\n}\nSystemAccount<'info>\nDescription: Type validating that the account is owned by the system program\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub account: SystemAccount<'info>,\n}\nSysvar<'info, T>\nDescription: Type validating that the account is a sysvar and deserializing it\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n pub rent: Sysvar<'info, Rent>,\n pub clock: Sysvar<'info, Clock>,\n}\nUncheckedAccount<'info>\nDescription: Explicit wrapper for AccountInfo types to emphasize that no checks\nare performed\nExamples: Github\n|\nSolpg\nsnippet#[derive(Accounts)]\npub struct InstructionAccounts<'info> {\n // CHECK: No checks are performed\n pub account: UncheckedAccount<'info>,\n}\nMigration<'info, From, To>\nDescription: Account container that handles schema migrations from one account type (From) to another (To). During deserialization, the account must be in the From format. On instruction exit, the account must be migrated to the To format, which is then serialized. Typically used with the realloc constraint to resize accounts during migration.\nChecks:\n\nAccount.info.owner == From::owner()\nAccount is initialized (not owned by system program with 0 lamports)\nAccount deserializes as From type\n\nsnippetuse anchor_lang::prelude::*;\n\n#[account]\npub struct AccountV1 {\n pub data: u64,\n}\n\n#[account]\npub struct AccountV2 {\n pub data: u64,\n pub new_field: u64,\n}\n\n#[derive(Accounts)]\npub struct MigrateAccount<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n #[account(\n mut,\n realloc = 8 + AccountV2::INIT_SPACE,\n realloc::payer = payer,\n realloc::zero = false\n )]\n pub my_account: Migration<'info, AccountV1, AccountV2>,\n pub system_program: Program<'info, System>,\n}\nUsage patterns:\nmigrate with explicit call// Access old fields via Deref before migration\nlet old_data = ctx.accounts.my_account.data;\n\n// Migrate to new schema\nctx.accounts.my_account.migrate(AccountV2 {\n data: old_data,\n new_field: 42,\n})?;\nidempotent migration with into_inner// Migrates if needed, returns reference to new data\nlet migrated = ctx.accounts.my_account.into_inner(AccountV2 {\n data: ctx.accounts.my_account.data,\n new_field: ctx.accounts.my_account.data * 2,\n});\nmsg!(\"New field: {}\", migrated.new_field);\nidempotent migration with mutation// Migrates if needed, returns mutable reference\nlet migrated = ctx.accounts.my_account.into_inner_mut(AccountV2 {\n data: ctx.accounts.my_account.data,\n new_field: 0,\n});\nmigrated.new_field = 42;PreviousAnchor ReferencesNextAccount ConstraintsOn this pageAccount TypesAccount<'info, T>AccountInfo<'info>AccountLoader<'info, T>Box<Account<'info, T>>Interface<'info, T>InterfaceAccount<'info, T>Option<Account<'info, T>>Program<'info, T>Signer<'info>SystemAccount<'info>Sysvar<'info, T>UncheckedAccount<'info>Migration<'info, From, To>Edit on GitHub","tokens":1565,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258294292,"hash":"e0513d7f3cac6983d083359329a315a2060ac414"}
{"url":"https://aave.com/docs/aave-v4/positions/borrow","domain":"aave.com","title":"Borrow Assets | Aave Protocol Documentation","text":"Borrow Assets#\nLearn how to borrow assets from Aave v4 reserves against your collateral.\n\nBorrowing assets from Aave v4 allows you to:\nAccess liquidity without selling your assetsLeverage your positions with borrowed capitalRepay borrowed assets at any time to close your position\nBorrowing assets creates a debt that reduces the position's health factor.\nMake sure to maintain sufficient collateralization to avoid liquidation.\nMonitor the position's health factor regularly and consider market volatility.\nBorrowing#\nBorrowing on Aave v4 takes place at the spoke level, and users can only borrow against collateral supplied to that same spoke.\nBorrowing can be broken down into the following steps:\nIdentify the Reserve to borrow fromPreview the impact of the borrow operationBorrow the assets\nIdentify the Reserve#\nThe first step is to filter the borrow reserves on the same spoke as the collateral to those marked with canBorrow: true.\nconst reserves: Reserve[] = [ { id: \"SGVsbG8h\", onChainId: \"42\", canBorrow: true, settings: { borrowCap: { amount: { value: BigDecimal(1000000000.0) }, // 1B USDC // … }, // … }, status: { frozen: false, paused: false, }, spoke: { address: \"0x123…\", // … }, // … }, { id: \"V29ybGQh\", onChainId: \"43\", canBorrow: false, // cannot borrow from this reserve settings: { borrowCap: { amount: { value: BigDecimal(500000000.0) }, // 500M DAI // … }, // … }, status: { frozen: true, // reserve is frozen paused: false, }, spoke: { address: \"0x123…\", // … }, // … }, // …];\nThe canBorrow flag confirms that the reserve is active: it isn’t frozen, it\nisn’t paused, and the borrow cap has not been reached.\nFrom the remaining borrowable reserves, select the one that:\nBest matches the desired token with a sufficient borrowable amount — this already accounts for the combined collateral factors (LTV ratios) of the position's collateralOffers the lowest borrow APY — the effective borrow APY combines the reserve’s borrow APY with the Risk Premium tied to the position's collateral\nconst reserve: Reserve = { id: \"SGVsbG8h\", onChainId: \"42\", canBorrow: true, chain: { chainId: 1, name: \"Ethereum\", }, spoke: { address: \"0x123…\", // … }, asset: { underlying: { address: \"0xa0b86a33e6e2ad05ad6c9ac3b6e5e5f6e7b6c1b2\", // USDC }, // … }, userState: { borrowApy: { normalized: BigDecimal(3.73), // 3.73% APY // … }, borrowable: { amount: { value: BigDecimal(10000.0), // 10,000 USDC }, // … }, // … },};\nMake sure you include a user address when fetching reserve data—otherwise\nuserState will be null.\nPreview Borrow#\nPreview the impact of a borrow operation before committing to it.\nReactTypeScriptGraphQLSolidityUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the borrow operation on the user's position.import { type BorrowRequest, usePreview } from \"@aave/react\";\nfunction BorrowPreview({ request }: { request: BorrowRequest }) { const { data, error, loading } = usePreview({ action: { borrow: request, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor?.current ?? \"N/A\"}</p> <p>To: {data.healthFactor?.after ?? \"N/A\"}</p>\n <h3>Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p> </div> );}Where the BorrowRequest can be as follows:const request: BorrowRequest = { sender: evmAddress(\"0x789…\"), // User's address reserve: reserve.id, amount: { erc20: { value: bigDecimal(1000), // 1000 USDC }, },};The PreviewUserPosition shows the impact of the borrow operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is betternetCollateral.[current → after]: ExchangeAmountHigher is betternetBalance.[current → after]: ExchangeAmountUpdated balancemaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerreserveRates.supplyApy.[current → after]: PercentNumberSupply APY impact on the reservereserveRates.borrowApy.[current → after]: PercentNumberBorrow APY impact on the reserveotherConditions: UserPositionConditionVariation[]Dynamic config changes\nBorrowing assets updates the Dynamic Config and User Risk Premium of the user position.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus changeYou can also specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = usePreview({ action: { borrow: request, }, currency: Currency.Eur,});\nStep-by-Step#\nNow that we know how to identify a reserve to borrow from, and we know how to preview the impact of a borrow operation, let's see how to borrow assets from this reserve.\nBorrowing assets is a risk-increasing action and will update the Dynamic\nConfig, which in turn updates the User Risk Premium for the given position.\nSee User Position Conditions for more details.\nReactTypeScriptGraphQLSolidityTo borrow assets from an Aave reserve with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Define the Borrow Flow#Then, use the useBorrow hook to prepare the borrow operation.import { useBorrow } from \"@aave/react\";\nconst [borrow, { loading, error }] = useBorrow((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});3Execute the Borrow Operation#Then, execute the desired borrow operation.import { bigDecimal, evmAddress } from \"@aave/react\";\nconst execute = async () => { const result = await borrow({ sender: evmAddress(wallet.account.address), // User's address reserve: reserve.id, amount: { erc20: { value: bigDecimal(100), // 100 USDC }, }, });\n // …};4Handle the Result#Finally, handle the result.const execute = async () => { const result = await borrow(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n default: console.error(result.error.message); break; } return; }\n console.log(\"Borrow successful with hash:\", result.value.txHash);};\n\nAdvanced Usage#\nNetwork Fee#\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nEstimate the network cost of any action using the same PreviewAction you pass to the usePreview hook.\nLet's consider the following example:\nimport { type PreviewAction } from \"@aave/react\";\nconst action: PreviewAction = { borrow: { sender: evmAddress(\"0x789…\"), // User's address reserve: reserve.id, amount: { erc20: { value: bigDecimal(1000), // 1000 USDC }, }, },};\nUse the useNetworkFee hook to estimate both the network fee for the provided action and its fiat equivalent.\nimport { type PreviewAction, Currency } from \"@aave/react\";import { useNetworkFee } from \"@aave/react/viem\";\nfunction NetworkFee({ action }: { action: PreviewAction }) { const { data: fee, loading, error, } = useNetworkFee({ query: { estimate: action }, currency: Currency.Eur, });\n if (loading) return <p>Loading fee…</p>; if (error) return <p>Error: {error.message}</p>;\n return ( <p> Network Fee: {fee.amount.value.toDisplayString(2)} {fee.token.info.symbol} <span> ≈{fee.exchange.symbol} {fee.exchange.value.toDisplayString(2)} </span> </p> );}\nNative Tokens#\nWhen the Reserve's underlying token is the wrapped version of the chain's native token (e.g., WETH on Ethereum), you can borrow the asset as the chain's native token using the Native Token Gateway.\nUse the asset.underlying.isWrappedNativeToken flag to determine if the underlying token is a wrapped native token. The Native Gateway address is available from the chain details.\nconst reserve: Reserve = { id: \"SGVsbG8h\", onChainId: \"42\", canBorrow: true, canSupply: true, canUseAsCollateral: true, asset: { underlying: { address: \"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\", info: { name: \"Wrapped Ether\", symbol: \"WETH\", decimals: 18, // … }, isWrappedNativeToken: true, // … }, // … }, settings: { borrowCap: { amount: { value: BigDecimal(1000000000.0) }, // 1B WETH // … }, supplyCap: { amount: { value: BigDecimal(2000000000.0) }, // 2B WETH // … }, // … }, spoke: { address: \"0x123…\", // … }, chain: { chainId: 1, name: \"Ethereum\", nativeGateway: \"0xabc…\", }, // …};\nSpecify the amount in the amount field as a native value.\nReactTypeScriptGraphQLSolidityconst execute = async () => { const result = await borrow({ sender: evmAddress(wallet.account.address), // User's address reserve: reserve.id, amount: { native: bigDecimal(1), // 1 ETH }, });\n // …};PreviousSupply AssetsNextWithdraw Assets","tokens":2509,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258294339,"hash":"4299bff11ee909e72af9194c916e7c31f2abd4a5"}
{"url":"https://aave.com/docs/aave-v4/tools/balances","domain":"aave.com","title":"User Balances | Aave Protocol Documentation","text":"User Balances#\nLearn how to monitor user balances for tokens supported by Aave v4.\n\nUser balances provide a comprehensive view of a user's token holdings across different chains, aggregated by token type with supply and borrow APY information.\nUser Balance Data Structure#\nUser balance data provides information about a user's token holdings, including:\nGlobally unique identifier: for each balance entryToken identification: name, symbol, icon, decimalsBalance amounts: individual balances per network, total amountsYield information: highest and lowest supply/borrow APY for each tokenCollateral factors: highest and lowest collateral factors for each tokenFiat valuations: converted amounts in selected currency\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core UserBalance type:interface UserBalance { __typename: \"UserBalance\"; id: UserBalanceId; info: TokenInfo; balances: TokenAmount[]; totalAmount: DecimalNumber; exchange: ExchangeAmount; highestSupplyApy: PercentNumber; highestBorrowApy: PercentNumber; lowestSupplyApy: PercentNumber; lowestBorrowApy: PercentNumber; highestCollateralFactor: PercentNumber | null; lowestCollateralFactor: PercentNumber | null;}\nFetching User Balances#\nReactTypeScriptGraphQLUse the useUserBalances hook to fetch user token balances.import { type UserBalancesRequest, useUserBalances } from \"@aave/react\";\nfunction UserBalancesList({ request }: { request: UserBalancesRequest }) { const { data, loading, error } = useUserBalances(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n // data: UserBalance[] return ( <div> {data.map((balance) => ( <div key={balance.id}> <h2>{balance.info.name}</h2> <p> <strong>Total:</strong> {balance.totalAmount.value.toDisplayString(2)} {balance.info.symbol} <small> {balance.exchange.symbol} {balance.exchange.value.toDisplayString(2)} </small> </p> <p> <strong>Supply APY:</strong> {balance.highestSupplyApy.normalized.toFixed(2)}% </p> </div> ))} </div> );}See below some examples of how to use the hook.import { evmAddress, chainId } from \"@aave/react\";\nconst request: UserBalancesRequest = { user: evmAddress(\"0x456…\"), filter: { chains: { chainIds: [chainId(1)], }, },};Sort balances by name or balance value.import { evmAddress, OrderDirection } from \"@aave/react\";\nconst request: UserBalancesRequest = { user: evmAddress(\"0x456…\"), filter: { // your filter criteria }, orderBy: { balance: OrderDirection.Desc },};Include tokens with zero balances in the results.const request: UserBalancesRequest = { user: evmAddress(\"0x456…\"), filter: { // your filter criteria }, includeZeroBalances: true,};Specify a different currency for displaying fiat amounts.import { evmAddress, Currency } from \"@aave/react\";\n// …\nconst { data, loading, error } = useUserBalances({ user: evmAddress(\"0x456…\"), filter: { // your filter criteria }, currency: Currency.Eur,});PreviousLiquidationsNextUser Activities","tokens":738,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258304584,"hash":"407d1a405dbe101dd7628964595e72ca24dadb14"}
{"url":"https://gov.optimism.io/t/404-gov-delegate-platform/10558","domain":"gov.optimism.io","title":"404 Gov - Delegate Platform - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n 404 Gov - Delegate Platform \n\n Communications 📣Delegates 🏛\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 13\n\n 1 / 2\n\n Jan 13\n\n 1d ago\n\n post by 404DAO on Jan 13\n\n 404DAO\n\n An important update regarding the future of 404 DAO’s governance operations.\nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What started as a small team of Georgia Tech students focusing on contributing to the Optimism DAO, quickly grew to becoming a trusted delegate in 10 ecosystems.\nAs the governance team evolved and members ventured into new opportunities, we began to evaluate what was the best path forward for our governance vertical. We determined that our delegated voting power deserves a dedicated steward who can commit the time and focus it requires.\nSo while 404 Gov is taking a step back from governance, the mission and work will continue with one of our team members, Rika, under her new entity, Axia Network, which has taken over the voting wallets and governance operations. Going forward, Axia Network is responsible for the voting activity of 0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5. Their work and delegation rationale can be found at the following account: Axia Network\nRika has been a core part of our team’s operations for many years now and deeply understands the responsibility involved with being a delegate. We are confident that the delegations will continue to be handled with professionalism under her stewardship. However, those that wish to remove their delegations may do so on Agora.\nThis transition applies only to governance-related wallets and profiles. Our partnership with Blockchain at Georgia Tech and educational work in Atlanta remains active.\nThank you to those who entrusted us with their voting power for so many years and thank you to the DAOs and contributors we’ve collaborated with in Optimism. It has been a privilege to take part in this ecosystem.\n\n Formally Announcing Axia Network\n\n 9 months later\n\n post by DarkEmpath888 1 day ago\n\n DarkEmpath888\n\n Please explain what this is … thanks, Jessica\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Formally Announcing Axia Network\n\n Delegate Updates\n\n season-9\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole…\n\n read more\n\n 0\n\n 51\n\n Jan 13\n\n Build a dedicated page for Delegation/Voting History\n\n ✨ General\n\n Right now, the only place to see all the delegates and make a selection is buried in the middle of the airdrop claim process (Optimism Gateway). There is another URL that shows the delegates, but there’s no functionality…\n\n read more\n\n 6\n\n 2.0k\n\n Jun 2022\n\n Protocol Delegation Program Renewal\n\n Metagovernance\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d\n\n Agora Updates & Feedback thread\n\n Delegates 🏛\n\n Hey everyone Charlie here from team Agora. \nReally appreciate everyone for trying out Optimism Agora Beta with the first test proposal and giving us such helpful feedback. \nWe’ve been reading all the posts, comme…\n\n read more\n\n 46\n\n 5.8k\n\n Dec 2024\n\n Governance Fund Observations\n\n Delegates 🏛\n\n Hello Optimism Community! @tnorm and I are two analysts on the Messari Governor team, and we’ve been covering Optimism governance as part of our daily workflow since the DAO launched. \n(Disclaimer: The thoughts, ideas, a…\n\n read more\n\n 11\n\n 4.8k\n\n Sep 2022","tokens":978,"squid":"ink-governance","role":"Council Listener","at":1791258307473,"hash":"c42f2126b9a1a8fb6fde8f968288fddd8f4dd13c"}
{"url":"https://www.openzeppelin.com/news/why-post-quantum-cryptography-looks-different","domain":"openzeppelin.com","title":"From Algebra to Noise: Why Post-Quantum Cryptography Looks Different","text":"September 14, 2026OpenZeppelin SecurityQuantum risk is often discussed as if it were a distant cryptography problem: something for standards bodies, researchers, and infrastructure vendors to worry about later. For tokenized finance, that framing is too narrow. If a cryptographically relevant quantum computer (CRQC) becomes available, the first institutional crisis will not be that every hash function immediately fails. It will be that exposed classical public keys — especially those behind wallets, custody systems, bridges, validators, governance executors, and smart-contract admin roles — may become liabilities.The point is to ask a practical question:“If Q-Day arrived sooner than expected, which of your keys, wallets, contracts, bridges, and governance paths would fail first?”“Who should read this? Executives, risk leaders, custody teams, treasury teams, tokenization platforms, protocol governors, and security leads who need to understand why quantum risk matters operationally before diving into the mathematics.”The thesis in one diagramThesis diagramThis diagram is intentionally simple because the first-order risk is simple. Quantum risk does not have to break every component of a blockchain at once. It only needs to turn the wrong exposed public key into a usable private key. Once that happens, the attacker does not merely understand the system better; they may be able to act as an authorized participant inside it.For on-chain systems, the threat model is especially unforgiving:“Expose now, forge later.Once a public key is permanently exposed on-chain, a future quantum attacker may be able to recover the corresponding private key and forge authorizations - unless assets and authorities have already migrated.”That is the blockchain analogue of \"harvest now, decrypt later.\" In confidentiality settings, an attacker records encrypted traffic today and decrypts it in the future. In tokenized finance, the attacker may instead observe exposed public keys today and forge authorizations in the future. The recorded object is not a ciphertext, but an authority-bearing public key.A Practical Guide to Quantum Risk in Blockchain set out this risk and the standards that answer it. What follows goes underneath both: the cryptographic reason exposed keys become recoverable, and what a migration actually costs.From algebra to noise: the post-quantum cryptographic transitionClassical Crypto Hides Secrets in AlgebraTo understand why, we need one central idea:“Classical public-key cryptography loves clean algebra.”Technical note: two classical one-way streets.Non-technical readers can skip this box and keep the main idea: RSA and elliptic-curve cryptography both rely on operations that are easy in one direction and hard to reverse classically.RSA is based on multiplication of large primes:N = pqGiven p and q, computing N is easy. Given only N, factoring it back into p and q is believed to be hard for classical computers.Elliptic-curve cryptography is based on scalar multiplication:Q = dGGiven d and G, computing Q is easy. Given Q and G, recovering d is believed to be hard for classical computers.Most widely used public-key algorithms follow this beautiful design pattern:Choose a mathematical operation that is easy to compute forward.Make the reverse direction infeasible.Use the forward operation to create public keys from a secret.Use the secret as private key to sign, decrypt, or derive shared keys.This design pattern is elegant, but the elegance is also structure. And Shor's algorithm is a structure detector. This is why the post-quantum transition is not simply \"use bigger curves\". The old parameters aren’t the problem, but rather the kind of hardness they rely on is the wrong kind against quantum computers.Shor's Algorithm: The Structure DetectorShor's algorithm is often described as \"the quantum algorithm that breaks RSA\". That is true, but too narrow. The deeper point is:“Shor's algorithm breaks cryptosystems whose hardness comes from certain kinds of clean algebraic structure.”It applies to:integer factoring,finite-field discrete logarithms,elliptic-curve discrete logarithms,and therefore many public-key systems built from them.For crypto-native systems, exposed classical public keys become dangerous in a post-quantum world with sufficiently powerful quantum attackers:exposed elliptic-curve public key → recoverable private keyThe full algorithm involves the quantum Fourier transform and period finding. For intuition, the key idea is that Shor turns hidden algebraic regularity into measurable information. Factoring can be reduced to finding a period in modular arithmetic, and discrete logarithms can be viewed as finding hidden structure inside a group. Quantum Fourier techniques are unusually good at extracting this kind of hidden regularity, as they turn algebraic periodicity into something a measurement can read directly.This is why RSA, DSA, Diffie-Hellman, ECDSA, EdDSA, and pairing-based cryptography all share the same vulnerability: they rest on the algebraic structure Shor was designed to exploit.Technical note: what \"structure\" really means here.Non-technical readers can skip this box and keep the main idea: \"structure is quantumly weak\" is a useful heuristic, not a theorem - Shor exploits one very specific kind of structure, and many structured problems resist quantum attack.\"Shor detects structure\" is a metaphor, and its limits matter. There is no theorem - and no real consensus - that structured problems are generically easy for quantum computers. What Shor exploits is narrow: factoring and both flavors of discrete logarithm reduce to finding periodicity in a finite cyclic (abelian) group - the abelian hidden subgroup problem - which the quantum Fourier transform solves efficiently. That is a specific property of commutative group structure, not of \"algebra\" in general.Plenty of richly structured problems have no known quantum speedup. Graph isomorphism is highly structured yet has no efficient quantum algorithm. And lattice problems themselves can be phrased as a non-abelian (dihedral) hidden subgroup problem, where the Fourier technique that defeats factoring does not apply. Lattices are therefore not safe because they lack structure - they are safe because their structure is not the kind Shor's machinery can unlock.Grover's Algorithm: The Brute-Force DiscountGrover's algorithm is different. It does not exploit algebraic structure in the same catastrophic way as Shor. Grover weakens brute force search, but does not destroy hashes the way Shor destroys elliptic-curve signatures. If a classical attacker needs about 2n steps to search a space, Grover can reduce that to about 2n/2. This matters for:symmetric-key search,hash preimage search,some mining-like search processes,and brute-force attacks.But it is not the same as Shor. For a 256-bit hash function preimage-search security degrades from 2256 to 2128. That is a large reduction, but 2128 remains a serious security level:“Shor finds the secret door. Grover only helps you check doors faster.”Technical note: why 2n/2 overstates Grover's real-world threat.Non-technical readers can skip this box and keep the main idea: the headline \"halving\" is an idealized bound; real quantum search is far costlier - but hash sizing is still an engineering tradeoff, not a solved problem.The 2n/2 figure is a query bound: it counts calls to the function, not wall-clock cost. Three practical facts push the real attack cost much higher:Grover barely parallelizes. Splitting the search across P quantum machines speeds it up only by √P, versus the linear P that classical brute force enjoys.Quantum gates are slow and the search is sequential. A Grover attack needs about 2n/2 sequential iterations on an error-corrected machine, each logical operation far slower than a classical one. For n = 256 that sequential depth alone is prohibitive for the foreseeable future.Hardware speed is unknown. Future clock rates and error-correction overheads are not yet known, so \"just double the output\" is a rule of thumb, not a guarantee of an exact security level.These caveats mostly cut in the defender's favor; they are why NIST treats even AES-128 and SHA-256 as far from trivially broken. But they also mean hash sizing is a tradeoff: in the early quantum era most users still run classical hardware, where larger outputs and longer hashes carry real cost.This is why SHA-256 and Keccak-256 do not need to be thrown away in the same way ECDSA does. They may need larger margins in some contexts, but they are not structurally destroyed by quantum algorithms. Therefore for blockchains, the practical message in the face of Shor and Grover quantum algorithms is:signature schemes are the urgent public-key problem,hashes are weakened but still usable with adequate parameters,symmetric encryption should prefer larger keys such as AES-256 for long-term security,and protocol designers should avoid relying on short hash outputs for long-lived high-value commitments.From Algebra to NoisePost-quantum cryptography (PQC) does not solve the problem by choosing a larger elliptic curve. That would still be algebra. Instead, it changes the hiding place. The major post-quantum families hide secrets in \"noise\":noisy linear algebra,high-dimensional lattices,error-correcting codes,and hash-based constructions.PQC changes the kind of hardness we rely on:clean algebraic structure → noise, combinatorics, and hashesThat is why post-quantum cryptography looks so different. It is not aesthetically similar to ECC. It has larger keys, larger signatures, more complicated implementation constraints, and more awkward engineering tradeoffs. Those differences are not accidental though - they are the point.Learning With Errors and Lattices: Hiding Secrets in NoiseThe central intuition behind many modern post-quantum schemes is Learning With Errors, or LWE.The idea is easy to state. Start with a large system of linear equations in some unknown secret values - the kind of system you learned to solve in school by elimination and substitution. On its own such a system is easy: given enough equations, ordinary linear algebra recovers the secret quickly. LWE takes this easy problem and deliberately breaks it. To each equation it adds a small, random error: a little nudge that leaves every equation only almost correct. Publicly, an attacker sees the equations (a public table of coefficients together with their slightly-off results) and knows the typical size of the errors, but never sees the secret or the exact errors that were added. The secret is now buried inside a haystack of nearly-correct equations, and recovering it becomes, as far as anyone knows, intractable for both classical and quantum computers.Technical note: the LWE equation.Non-technical readers can skip this box and keep the main idea: lattice cryptography makes recovery hard by adding carefully controlled noise to otherwise solvable equations.A simplified LWE equation looks like this:b = As + e (mod q)where:A ∈ ℤqm×n is a public matrix whose entries are sampled modulo q - a large public table of coefficients;s ∈ ℤqn is the secret vector (secret key);e is a small error/noise vector;b ∈ ℤqm is a public vector computed as b = As + e (mod q);and the attacker sees (A, b) and knows how e is sampled (its distribution), but does not see the actual s or e.If there were no noise, we would have:b = As (mod q)and recovering s would be a linear-algebra problem. The noise changes everything.Recovering s means solving a linear system, and this can be done efficiently using, for example, Gaussian elimination. But with noise, that approach breaks down. As we solve the system, we have to divide by the coefficients of A, and since its entries are random, these coefficients can be large, causing them to amplify the error when we multiply through. As a result, any approximate solution we find may be far from the true one.More precisely: suppose b = As′, where s′ is an approximate solution. Subtracting both sides from the true equation and multiplying by the inverse of A (for simplicity, assume A is a square matrix and since its entries are random, it is invertible with high probability, though the general case is similar) gives:s′ − s = A−1eEven if the noise vector e is small, multiplying by A−1 can make the difference s′ − s large.It is worth being precise about what noise actually breaks. The linear algebra itself does not stop working: a random square system is almost surely invertible, so the equations still have a unique exact solution - it simply is not the secret. Solving As′ = b as if it were exact returns s′ = s + A−1e, and because A is random, A−1e is typically large modulo q, throwing s′ far from the true s. The secret itself stays well-defined - with enough samples it is the unique solution whose error vector is small - but the fast exact-arithmetic method no longer finds it, and no efficient method is known to. What noise destroys is efficient recovery, not the underlying algebra.Each equation is only almost correct: it is slightly off, perturbed by a small noise term. Remarkably, the whole collection of these noisy equations is believed to be computationally indistinguishable from equations whose results are entirely random, meaning it reveals no useful information about the secret. This property can be used directly for encryption: for example, one can encrypt a message simply by adding it to one of these \"random-looking\" results.Now, to get a feel for why even a tiny amount of noise changes the picture so dramatically, consider the simplest possible case where the error added to each equation takes only the values 0 or 1, each with nonzero probability. Then every single equation actually corresponds to two possible equations: one where the error is 0 and one where it is 1. This means that for a system of m equations, there are 2m possible underlying systems consistent with what you observe, and since the number of equations m in practice grows with the security parameter, the number of possibilities explodes exponentially. The attacker has no efficient way to determine which combination of noise values was actually used, and so the system remains secure.This is the leap from algebra to noise.But where do lattices come in? Picture all the results the noise-free equations could produce as the secret ranges over its possible values. They do not fill space smoothly; they land on a perfectly regular grid of points - a lattice, the higher-dimensional cousin of the evenly spaced dots on a sheet of graph paper. The true, noise-free answer sits exactly on a lattice point. Adding the small error nudges what the attacker actually observes slightly off that grid point. So recovering the secret is the same as taking the observed, off-grid point and finding the lattice point nearest to it.That is a famous, well-studied geometric problem - the closest vector problem - and in high dimensions it is believed to be hard for classical and quantum computers alike. This is the bedrock the security rests on: LWE is just a convenient, randomized way of dressing up a hard lattice problem. \"Adding noise to equations\" and \"landing just off a grid point\" are two descriptions of the same thing - which is why this whole family is called lattice cryptography.Another way to understand the appeal of lattice-based cryptography is to put it side by side with the classical schemes - both how it looks and how its hardness is grounded.Technical note: classical vs. lattice hardness, side by side.Non-technical readers can skip this box and keep the main idea: the old world hides secrets in clean algebra that quantum computers can unravel; the new world hides them in noisy lattice problems that have a stronger worst-case hardness story and no known quantum shortcut.Classical ECC hides the secret in a clean algebraic operation:Q = dGLattice cryptography hides it in noisy relations:b = As + e (mod q)The first is elegant and algebraic; the second is messy on purpose. That difference runs deeper than appearance - all the way down to complexity theory.Factoring and the discrete logarithm have resisted classical attacks for decades, but they are not known to be NP-hard and are not believed to be NP-complete. They occupy a somewhat unusual middle ground: hard enough that no efficient classical algorithm is known, yet not \"complete\" for the whole class of efficiently verifiable problems. It remains conceivable that a clever classical algorithm could one day solve them efficiently - and on a quantum computer Shor's algorithm already does, precisely by exploiting their hidden algebraic structure.Lattice problems have a different complexity-theoretic flavor. The Shortest Vector Problem (SVP) asks for a shortest nonzero vector in a lattice, and SVP - along with related problems - is known to be NP-hard in its exact form and for small approximation factors. The approximation factors that cryptography actually relies on are much larger, and in that regime the problems are not believed to be NP-hard; so this is evidence of robustness, not a proof of security. What matters more for cryptography is that the security of LWE is tied, through worst-case-to-average-case reductions, to the hardness of approximate lattice problems such as GapSVP and SIVP: an efficient solver for random LWE instances would yield an efficient solver for those lattice problems in the worst case.This does not make LWE \"proven secure\", nor is breaking a concrete NIST parameter set literally the same as solving an NP-complete problem. But it does anchor lattice cryptography in a family of problems with a far stronger worst-case hardness story than factoring or discrete logarithms. The gap may even be partly classical, not only quantum: the best known classical algorithms for LWE at cryptographic parameters run in essentially exponential time, whereas factoring enjoys sub-exponential ones - so LWE may be harder than factoring on ordinary computers too, before any quantum speedup enters the picture.The high-level intuition is this: Shor's algorithm needs clean algebraic structure to exploit - exactly the structure RSA and elliptic-curve cryptography rely on. Lattice cryptography instead rests on noisy, high-dimensional geometric problems; they still have structure, especially in their efficient variants, but it is combined with noise in a way that currently resists known classical and quantum attacks, with no Shor-like quantum shortcut in sight. That is one reason lattices became the main foundation for NIST's post-quantum standards. It does not mean LWE is unconditionally secure, but rather that no efficient Shor-like quantum algorithm is known for solving the LWE-type problems underlying NIST's lattice standards at their chosen parameters.This is the practical meaning of \"quantum-resistant\".NIST PQC: The Replacement ToolboxAfter a multi-year standardization process, NIST finalized its first post-quantum cryptography standards in August 2024:FIPS 203: ML-KEM, based on CRYSTALS-Kyber,FIPS 204: ML-DSA, based on CRYSTALS-Dilithium,FIPS 205: SLH-DSA, based on SPHINCS+.NIST has also selected Falcon for future standardization under the name FN-DSA, and HQC as an additional post-quantum KEM. The standards are not interchangeable. They solve different problems.High-level Overview of NIST's PQC StandardsML-KEM: Replacing Diffie-Hellman-Style Key EstablishmentML-KEM is a key encapsulation mechanism. It does not directly replace ECDSA wallet signatures. It replaces key-establishment mechanisms such as Diffie-Hellman-style exchanges. At a high level:A receiver publishes a public key.A sender uses that public key to encapsulate a fresh randomly generated shared secret, producing a ciphertext.The receiver uses the secret key to decapsulate the same shared secret from the ciphertext.Technical note: KEM notation.Non-technical readers can skip this box and keep the main idea: ML-KEM lets two parties arrive at the same shared secret without using quantum-vulnerable Diffie-Hellman.Conceptually:(c, K) = Encaps(pk)and:K = Decaps(sk, c)where:pk is the public key,sk is the secret key,c is the ciphertext sent to the receiver,K is the shared secret.Note that, unlike general public-key encryption where the sender chooses the message, here the sender does not choose K: it is sampled randomly inside Encaps, which returns the pair (c, K) as local outputs to the sender. Only the ciphertext c is sent over the wire - the secret K is never transmitted. The receiver does not read K out of c directly; instead, c encapsulates the randomness that determined K, and running Decaps with the secret key sk reconstructs the very same K. An eavesdropper who captures c but lacks sk cannot recover K.More precisely, K is not the raw randomness itself but a hash of it (together with c), and Decaps re-encrypts its recovered value and checks it against c before deriving K. This is the Fujisaki-Okamoto transform, and it is what hardens the scheme against attackers who submit malformed ciphertexts to probe the secret key.Engineering intuition:“ML-KEM is what you use when two systems need to agree on a secret in a quantum-resistant way.”Institutionally, ML-KEM matters for secure channels: TLS-like connections, custody backend communication, VPNs, confidential APIs, and secure service-to-service messaging. In onchain terms, ML-KEM is not the main answer to \"how do we replace ECDSA wallets?\", but is rather the answer to:“How do our systems establish encrypted channels without relying on quantum-vulnerable Diffie-Hellman?”ML-DSA: The Practical Lattice Signature WorkhorseML-DSA is NIST's lattice-based digital signature standard, derived from CRYSTALS-Dilithium. It is one of the main candidates for replacing classical digital signatures in general-purpose systems. A useful high-level analogy is Schnorr signatures, but over lattice relations rather than elliptic-curve groups. ML-DSA follows the same commit-challenge-respond rhythm as Schnorr-like signatures, but the arithmetic lives in lattice/module structures, and the security relies on lattice assumptions rather than discrete logarithms. Think of it as:“Instead of proving knowledge of a secret scalar behind an elliptic-curve public key, the signer proves knowledge of short secret information consistent with public lattice data.”ML-DSA has larger signatures and public keys than ECDSA or EdDSA, but it is designed to be practical and comparatively robust among post-quantum signature schemes. Engineering intuition:“ML-DSA is what you use when you need a general-purpose post-quantum signature and can absorb the size cost.”Institutionally, it is the general-purpose post-quantum signature workhorse for software signing, credentials, document signing, API authentication, and approval workflows where size constraints are manageable. For blockchain systems, the key challenge is not simply whether ML-DSA is secure, but“can we afford to verify it and carry its signatures inside the protocol?”That depends on the execution environment, gas model, calldata cost, and whether verification can be optimized, aggregated, or moved off-chain.SLH-DSA: The Conservative Hash-Based BackupSLH-DSA is based on SPHINCS+, a stateless hash-based signature scheme. Its philosophical appeal is simple:“If we trust hash functions, we can build signatures from hashes.”Hash-based signatures use one-time or few-time signing components and organize them with Merkle-tree-like structures. Instead of relying on lattices or number theory, they rely on hash-function properties such as preimage resistance and collision resistance. As an analogy:“Imagine a huge book of single-use wax seals. Each seal can authorize one message. A hash tree lets the verifier check that a given seal belongs to the official book without storing the whole book.”SLH-DSA is attractive because it is mathematically conservative. It is also expensive:signatures are large,signing and verification are heavier,and many blockchain environments will find it costly.So SLH-DSA is not necessarily the most convenient blockchain signature scheme. But if lattice assumptions were ever weakened, hash-based signatures provide algorithmic diversity. From an engineering perspective:“SLH-DSA is what you use when you want hash-based conservatism for keys you rarely touch.”Institutionally, SLH-DSA is best viewed as a conservative backup for rare but high-value operations: root certificates, long-term offline keys, emergency authorization keys, and backup trust anchors.Falcon / FN-DSA: Compact but DelicateFalcon is another lattice-based signature scheme selected by NIST for future standardization under the name FN-DSA. Its main attraction is compactness. Compared with ML-DSA, Falcon signatures are much smaller. That matters for environments where bandwidth, calldata, storage, and verification footprint are expensive. This naturally makes Falcon interesting for blockchains. Falcon achieves compactness using more delicate machinery, including lattice Gaussian sampling, so secure implementation is more subtle. This does not mean Falcon is bad. It means that its engineering risk profile differs from ML-DSA:“Falcon is what you use when signature size matters more than implementation simplicity.”For auditors, the relevant questions are:Is the sampler implemented correctly?Is it constant-time?Are there side-channel risks?Are floating-point or precision issues avoided or controlled?Is the implementation using a well-reviewed library?Are randomness and fault attacks considered?In a blockchain context, Falcon's compactness may be appealing, but implementation fragility must be taken seriously.This is not hypothetical. Working with OpenZeppelin, Starknet has deployed Cairo account contracts that verify Falcon-512 signatures, and a spec-compliant Falcon-512 account has already executed a live transfer on Mainnet.HQC: Code-Based DiversityHQC is a code-based key encapsulation mechanism selected by NIST as an additional post-quantum encryption/KEM algorithm. Its role is the same as ML-KEM and is added for diversity. Lattices are currently the dominant practical PQC family, but cryptographic monocultures are dangerous. If a major breakthrough weakened lattice assumptions, systems relying exclusively on lattice cryptography would face correlated risk. Code-based cryptography uses a different kind of hardness. Very roughly, it hides secrets in error-correcting-code problems. Error-correcting codes are normally used to recover messages from noise. Code-based cryptography turns that idea around:“The noise becomes the lock.”This mirrors the lesson from LWE: where lattice cryptography buries the secret by adding noise to otherwise-solvable equations, code-based cryptography buries the message inside a deliberate error pattern that only the legitimate structure can decode.“HQC is what you choose when you want algorithmic diversity alongside lattice-based KEMs.”HQC is relevant to institutions because it gives backup diversity for key establishment.What to do nextMap the NIST toolbox to your own stack. The first question is not \"which algorithm wins?\" - it is \"where does each tool actually fit?\" A practical first step is to walk through four categories of cryptographic use and identify the candidates that match each one:Key establishment. Where do you currently rely on Diffie-Hellman-style exchanges - TLS connections, custody backend communication, VPNs, internal APIs, service-to-service messaging? These are ML-KEM candidates, with HQC available for algorithmic diversity.General-purpose signatures. Where do you sign software, firmware, credentials, documents, or off-chain approval workflows? These are ML-DSA candidates, where size constraints are usually manageable.Trust anchors and emergency keys. Where do you keep long-term offline keys, root certificates, or rarely-used recovery paths? These are SLH-DSA candidates, where mathematical conservatism matters more than signature size.Compact signatures. Where is signature size or calldata genuinely scarce - typically on-chain verification or bandwidth-constrained environments? These are Falcon/FN-DSA candidates, with appropriate scrutiny of sampler correctness and side-channel exposure.This mapping is the input to a migration plan, not the plan itself.Post-quantum migration readiness flowWhat This Means for Blockchain and Onchain SystemsCosts in Blockchain TermsIf the substitution were free, this conversation would be over. It is not free. The costs are concrete and worth quoting to your engineering and operations teams.Signature size. A raw secp256k1 ECDSA signature is measured in tens of bytes. ML-DSA signatures are measured in kilobytes. FN-DSA/Falcon is more compact once standardized, but harder to implement safely. SLH-DSA signatures can be much larger still, reaching tens of kilobytes depending on parameters. On a chain where every byte of every transaction is paid for and stored forever, this moves from implementation detail to full redesign.SchemeSignature sizeBlockchain implicationECDSA / secp256k1Tens of bytesCheap and deeply optimizedML-DSALow single-digit kilobytesCalldata and verification become material costsFalcon / FN-DSASub-kilobyteCompact, but implementation-sensitiveSLH-DSATens of kilobytesConservative, but expensive for frequent on-chain useVerification cost. Lattice signature verification is computationally heavier than ECDSA verification. On-chain verification, already expensive in gas, becomes substantially more so.Public key size. ML-DSA public keys are roughly 1.3 KB versus 33 bytes for compressed secp256k1. For account-abstraction wallets that store keys on-chain, this matters.The on-chain-forever problem. Every signature, every public key, every transaction is recorded permanently. A migration is not \"switch over and move on.\" Old addresses with funds remain exposed forever unless their funds are moved to new, post-quantum addresses before a cryptographically relevant quantum computer exists. For signatures, the better phrase is expose-now-forge-later: once a public key is permanently exposed on-chain, a future quantum attacker may be able to recover the corresponding private key and forge authorizations unless the assets and authorities have already migrated.No drop-in replacement. Bitcoin and Ethereum both face open governance questions about which PQC signature scheme to adopt, how to handle account migration, whether to use STARK-style aggregation, and how to subsidize the transition. There is no consensus today. Institutions cannot wait for one.Some migration paths will be ugly. Immutable contracts may not be able to change verification logic. Old EOAs and forgotten UTXOs may never move. Assets controlled by exposed keys may require expensive coordination, governance intervention, or emergency migration mechanisms. Post-quantum readiness is therefore not only about choosing a new signature scheme; it is about knowing which parts of the system can actually move.The Protocol-Level DependencyThere is a ceiling on what any single institution can do alone. The signature scheme that secures base-layer transactions - elliptic-curve signatures over secp256k1 on both Bitcoin and Ethereum - is fixed by protocol consensus, not by individual wallet owners. No institution can unilaterally teach the base layer to verify a post-quantum signature on an ordinary externally owned account or UTXO. That requires a protocol-level change: new signature-verification logic at the base layer, plus a sanctioned process for migrating existing addresses onto it.This bounds everything else in this playbook. Inventory, classification, crypto-agility, and hybrid modules are necessary, but they are not sufficient. On a programmable chain an institution has real agency - it can move value into a smart-contract account whose own logic enforces post-quantum verification, without waiting for a fork. But two things stay outside any single institution's control:Already-exposed base-layer keys. Funds in an exposed EOA, or in a UTXO whose public key is already exposed, cannot be retrofitted with post-quantum protection; they can only be moved to a safer destination before Q-Day. If the owner is gone, the keys are lost, or the assets are immobilized, no institutional process recovers them.The base-layer signing scheme itself. Until the protocol offers post-quantum transaction signing and an address-migration path, every plain EOA and UTXO remains structurally exposed - including those of the counterparties, custodians, and bridges an institution depends on.This is a systemic, coordination-bound risk, not a per-institution one. It is also why protocol-level efforts - Bitcoin proposals for new address and opcode formats, and Ethereum work such as LeanSig and the Lean Ethereum direction - matter as much as anything on an institution's own checklist. An institution should track that work and support it where it can, because its own migration ultimately depends on it.Platform-Specific ConsiderationsEthereum: Why Account Abstraction MattersEthereum may have one major advantage in a post-quantum migration: programmability. Smart-contract wallets and account abstraction can allow different verification logic. Instead of being permanently tied to one signature scheme, an account can potentially upgrade or support multiple schemes. This makes hybrid signatures, staged migration, quantum-safe authorization modules, off-chain proof systems, and contract-level policy enforcement possible. Crucially, it makes social recovery available as a fallback when on-chain keys cannot move quickly enough.During migration, systems can require both old and new cryptographic checks. That's captured by hybrid signatures, which require both:ECDSA signature + post-quantum signaturebefore accepting an operation. This is especially useful during transition periods. If the PQ scheme later has problems, the classical scheme still helps. If the classical scheme becomes quantum-vulnerable, the PQ scheme helps. But hybrid systems are not free: they increase signature size and verification cost, complicate wallet UX, and create new failure modes.For Ethereum, the long-term challenge is not only choosing a PQ signature scheme. It is making the account system, wallet ecosystem, and contract layer agile enough to survive cryptographic change. Further note that while account abstraction helps future wallets and migration paths, it does not automatically save old EOAs whose public keys are already exposed and whose assets remain unmoved.Bitcoin: Why Consensus and UTXOs Make Migration DifferentBitcoin's situation is different from Ethereum's. Its UTXO model can delay public-key exposure, but its consensus model makes coordinated migration deliberately hard. Migration questions include new address formats, new script capabilities, new signature verification opcodes, handling already exposed public keys, incentivizing users to move old coins, and avoiding chaos during a quantum emergency.That is a feature for stability, but a challenge for cryptographic agility. Ethereum's programmability is a migration advantage; Bitcoin's stability is a migration constraint. Both will need to migrate, but the playbooks will differ.Ethereum consensus currently uses BLS signatures, which are pairing-based and therefore not post-quantum secure. This motivates research into post-quantum consensus signatures and aggregation-friendly alternatives. This is where Ethereum-specific work such as LeanSig becomes important.LeanSig and Blockchain-Specific PQ SignaturesNIST standards are general-purpose. Blockchains are not general-purpose environments. They meter bytes, verification time, state, calldata, aggregation, and consensus overhead. This motivates blockchain-specific post-quantum signature research, including LeanSig and related work in the Lean Ethereum direction. The basic motivation is:“Ethereum does not merely need a post-quantum signature. It needs a post-quantum signature system that fits consensus, aggregation, verification, and blockchain economics.”LeanSig is especially interesting because it is designed with Ethereum's post-quantum consensus needs in mind, rather than as a general-purpose internet standard. LeanSig should be treated as early-stage research rather than a production-ready replacement for standardized post-quantum signatures. For a broad institutional audience, the key takeaway is:“NIST standards are the foundation, but blockchain deployments may need protocol-level adaptations beyond what general-purpose standards provide.”This is not unusual. Classical cryptography also looks different when adapted to blockchains. The same will be true for PQC.What Your Team Should Start Doing in 2026The reason to think about this now, in 2026, rather than in 2032, is that quantum-safe migration on a blockchain is not an upgrade, it is a key rotation across every address that holds value. Doing it under immediate danger is doing it badly. Below we list the minimum steps for a proactive defense approach that your institution should consider today.1. Build a cryptographic asset inventoryInstitutions should know exactly where they use classical signature schemes (ECDSA, EdDSA, RSA, BLS), classical key exchange, TLS and SSH certificates, pairing-based cryptography, smart-contract signature verification, and privileged off-chain approval keys. You cannot migrate what you have not inventoried.2. Classify public-key exposureFor each wallet or key, classify:CategoryMeaningHidden public keyLower immediate quantum exposureExposed public keyVulnerable once cryptographically relevant quantum computer existsReused signerHigh riskLong-lived admin keyCritical riskUpgradeable contract walletMigration candidateImmutable verifierHard migration problem3. Identify authority concentrationFind keys that control treasuries, bridges, mints, burns, pauses, upgrades, governance execution, validators, oracle feeds, or custody withdrawals. These are quantum high-value targets.4. Introduce crypto-agilitySystems should be designed so that algorithms can be changed without full architectural replacement. Abstract signature verification, hybrid-signature support, upgradeable wallet modules, configurable key policies, versioned address formats, and explicit migration windows are all parts of that pattern.5. Test hybrid modesHybrid systems combine classical and post-quantum mechanisms, so that both have to fail for the system to fail. For signatures:Accept ⇔ Verifyclassical = 1 and VerifyPQ = 1For key establishment:K = H(Kclassical ‖ KPQ)The idea is defense in depth during transition.6. Conduct security audits of post-quantum implementations differentlyPQC introduces new failure modes. PQC implementation risk is not limited to Falcon: lattice schemes more generally introduce side-channel, randomness, rejection-sampling, invalid-input, and fault-injection considerations. For lattice schemes, the highest-impact failure modes are side-channel resistance, randomness quality, and invalid-input handling. For hash-based signatures, the priorities are domain separation, parameter selection, and signature-size budgeting. For Falcon-like signatures, the priorities are Gaussian-sampler correctness, constant-time implementation, and side-channel leakage.7. Prepare governance and communicationA PQ migration is not only technical. It touches legal risk, regulatory disclosures, customer communication, custody agreements, insurance, board-level risk governance, and incident response. An institution that waits until Q-Day will not be migrating cryptography, but will be managing a crisis.What Security Auditors Should Ask NowA post-quantum security audit should begin with a small set of concrete questions:AreaQuestionWalletsWhich signature schemes authorize asset movement?ExposureWhich public keys are already exposed?AuthorityWhich keys control upgrades, pauses, mints, burns, withdrawals, or governance execution?BridgesAre validator, committee, or multisig signatures quantum-vulnerable?CustodyCan signing keys rotate without operational disruption?ContractsCan signature verification logic be upgraded or replaced?InfrastructureAre TLS, SSH, API, and internal approval systems PQ-ready or hybrid-ready?DependenciesAre post-quantum candidates standardized, experimental, or blockchain-specific?DiversityHas the organization considered algorithmic diversity?MigrationIs there a documented and tested post-quantum migration plan?The purpose of these questions is prioritization, rather than panic.Conclusion: Crypto-Agility Before Q-DayThe post-quantum transition is not a routine cryptographic upgrade. For tokenized finance, it is a migration of authority before exposed public keys become operational liabilities. The systems most at risk are not necessarily the ones with the most elegant cryptography, but the ones where exposed classical public keys control assets, bridges, mints, burns, upgrades, validators, or governance execution. The exact arrival date of a cryptographically relevant quantum computer is uncertain, but that is the wrong question to fixate on. The exposure map can be built today. The right question is:\"If it arrived sooner than expected, which of our keys, contracts, wallets, bridges, and governance paths would fail first?\"That question should be answered before Q-Day, not during it.Looking for a security partner? Talk to an expertFAQsWhat is the \"expose-now, forge-later\" risk in blockchain?It's the onchain analogue of harvest-now-decrypt-later. Once a public key is exposed on a blockchain, a future quantum computer may be able to derive the private key and forge authorizations, unless the assets tied to that key have already migrated to a quantum-safe address.Does quantum computing break blockchain hash functions like SHA-256?No. Grover's algorithm only weakens hash-based search (roughly halving effective bit security), while Shor's algorithm is what breaks the algebraic structure behind signature schemes like ECDSA. A 256-bit hash still retains strong effective security against Grover.Which NIST post-quantum standards apply to blockchain systems?ML-KEM (FIPS 203) replaces Diffie-Hellman-style key establishment, ML-DSA (FIPS 204) is the general-purpose lattice signature standard, and SLH-DSA (FIPS 205) is a conservative hash-based signature scheme for high-value or rarely-used keys. Falcon (FN-DSA) and HQC are additional NIST selections offering compactness and code-based diversity, respectively.Why can't institutions just wait for Bitcoin or Ethereum to upgrade their base-layer cryptography?Base-layer signature schemes are fixed by protocol consensus, not individual wallet owners. Already-exposed keys cannot be retrofitted; they can only be moved to safer destinations before a cryptographically relevant quantum computer exists. Institutions need their own migration and inventory work regardless of protocol-level timelines.What should an institution's post-quantum audit actually check?A post-quantum security audit should map which signature schemes authorize asset movement, which public keys are already exposed, which keys control upgrades or governance execution, whether bridge and custody signatures are quantum-vulnerable, and whether a tested migration plan exists.Why is Ethereum's account abstraction relevant to post-quantum migration?Smart-contract wallets let an account enforce custom verification logic, including hybrid signatures that require both a classical and a post-quantum check to pass. This allows staged migration without waiting for a protocol fork, though it doesn't retroactively protect old EOAs with already-exposed keys.","tokens":10936,"squid":"ink-security_audits","role":"Sentinel","at":1791258307504,"hash":"7d202fc1abbfef2298422f9b1fcaa9b30a194e02"}
{"url":"https://aave.com/docs/aave-v4/positions/supply","domain":"aave.com","title":"Supply Assets | Aave Protocol Documentation","text":"Supply Assets#\nLearn how to earn interest on Aave v4 and use assets as collateral for borrowing.\n\nSupplying assets to Aave v4 allows you to:\nReceive reserve shares representing your depositEarn variable supply APY on your reserve sharesUse reserve shares as collateral for borrowingWithdraw assets and earnings anytime\nSupplying assets as collateral while having an open borrow position may\nincrease the position's health factor.\nSupplying#\nSupplying assets to Aave can be broken down into the following steps:\nIdentify the ReservePreview the impact of the supply operation (optional)Supply the assets\nIdentify the Reserve#\nThe first step is to filter the supply reserves to those marked with canSupply: true.\nconst reserves: Reserve[] = [ { id: \"SGVsbG8h\", onChainId: \"42\", canSupply: true, settings: { supplyCap: { amount: { value: BigDecimal(2000000000.0) }, // 2B USDC // … }, // … }, // … }, { id: \"V29ybGQh\", onChainId: \"43\", canSupply: false, // cannot supply to this reserve settings: { supplyCap: { amount: { value: BigDecimal(1000000000.0) }, // 1B USDC // … }, // … }, // … }, // …];\nThe canSupply flag confirms that the reserve is active: it isn’t frozen, it\nisn’t paused, and the supply cap has not been reached.\nFrom the remaining reserves, choose one that meets these criteria:\nCollateral Enabled: The reserve can be used as collateral (canUseAsCollateral) if you plan to borrow against it.Suppliable Amount: The userState.suppliable value is sufficient for the amount you want to supply.\nconst reserve: Reserve = { id: \"SGVsbG8h\", onChainId: \"42\", canSupply: true, canUseAsCollateral: true, chain: { chainId: 1, name: \"Ethereum\", }, spoke: { address: \"0x123…\", // … }, status: { frozen: false, paused: false, }, settings: { supplyCap: { amount: { value: BigDecimal(2000000000.0) }, // 2B USDC // … }, // … }, userState: { suppliable: { amount: { onChainValue: \"1000000000\", decimals: 6, value: BigDecimal(1000.0), // Can supply up to 1,000 USDC }, // … }, // … }, // …};\nMake sure you include a user address when fetching reserve data—otherwise\nuserState will be null.\nPreview Supply#\nPreview the impact of a supply operation before committing to it.\nReactTypeScriptGraphQLSolidityUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the supply operation on the user's position.import { type SupplyRequest, usePreview } from \"@aave/react\";\nfunction SupplyPreview({ request }: { request: SupplyRequest }) { const { data, error, loading } = usePreview({ action: { supply: request, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor.current?.value.toFixed(2) ?? \"N/A\"}</p> <p>To: {data.healthFactor.after?.value.toFixed(2) ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p>\n <h3>Max Borrowing Power:</h3> <p>From: {data.maxBorrowingPower.current.value.toDisplayString(2)}</p> <p>To: {data.maxBorrowingPower.after.value.toDisplayString(2)}</p> </div> );}See below for examples of SupplyRequest objects.const request: SupplyRequest = { sender: evmAddress(\"0x123…\"), // User's address reserve: reserve.id, chainId: reserve.chain.chainId, amount: { erc20: { value: bigDecimal(42), // USDC }, },};The PreviewUserPosition shows the impact of the supply operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)netApy.[current → after]: PercentNumberHigher is betternetCollateral.[current → after]: ExchangeAmountHigher is betternetBalance.[current → after]: ExchangeAmountUpdated balanceprojectedEarning.[current → after]: ExchangeAmountProjected earningsmaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerreserveRates.supplyApy.[current → after]: PercentNumberSupply APY impact on the reservereserveRates.borrowApy.[current → after]: PercentNumberBorrow APY impact on the reserve\nSupplying assets as collateral updates the Dynamic Config just for the reserve being supplied as collateral.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus changeYou can also specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = usePreview({ action: { supply: request, }, currency: Currency.Eur,});\nStep-by-Step#\nNow that you know how to identify a reserve and preview the impact of a supply operation, let's supply assets to a reserve.\nSupplying ERC-20 tokens requires token approval. You can choose between two approaches:\nTransaction-based approval — Sends a separate ERC-20 approve() transaction before the supply transaction (2 transactions total).Permit-based approval — Signs an EIP-2612 permit to approve and supply in a single transaction. More gas-efficient, but requires the token to support permits.\nReactTypeScriptGraphQLSolidityTo supply assets to an Aave reserve with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the hooks for the wallet library of your choice:useSendTransaction — used to send ERC-20 approval and supply transactionsuseSignTypedData — used to sign ERC-20 permits when availableimport { useWalletClient } from \"wagmi\";import { useSendTransaction, useSignTypedData } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);const [signTypedData] = useSignTypedData(wallet);2Define the Supply Flow#Then, use the useSupply hook to prepare the supply operation.import { useSupply } from \"@aave/react\";\nconst [supply, { loading, error }] = useSupply((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"Erc20Approval\": // If token supports EIP-2612 permits, sign permit (recommended) if (plan.bySignature) { return signTypedData(plan.bySignature); } // use traditional approval transaction return sendTransaction(plan.byTransaction);\n case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});In the Erc20Approval case, the bySignature field is only available if the token supports EIP-2612 permits.For tokens like USDT on Ethereum\nMainnet\nthat require an allowance reset, the hook calls your callback twice: once to\nreset the allowance to 0, then again to set the new value. bySignature will\nbe null for these approvals.3Execute the Supply Operation#Then, execute the supply operation.import { bigDecimal, evmAddress } from \"@aave/react\";\nconst execute = async () => { const result = await supply({ sender: evmAddress(wallet.account.address), // User's address reserve: reserve.id, amount: { erc20: { value: bigDecimal(42), // 42 USDC }, }, });\n // …};4Handle the Result#Finally, handle the result.const execute = async () => { const result = await supply(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"ValidationError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Supply successful with hash:\", result.value.txHash);};\nCollateral Management#\nManage how user supplies are used as collateral for borrowing. The process can be broken down into three steps:\nIdentify the supply positionPreview the impact of changing collateral statusToggle the collateral status\nIdentify the Supply Position#\nFirst, identify the supply position you want to modify from the user's supply positions.\nconst supplyPosition: UserSupplyItem = { reserve: { id: \"SGVsbG8h\", onChainId: \"42\", chain: { chainId: 1, name: \"Ethereum\", }, spoke: { address: \"0x123…\", // … }, canUseAsCollateral: true, // … }, isCollateral: false, balance: { amount: { value: BigDecimal(46.2), }, // … }, principal: { amount: { value: BigDecimal(42.0), }, // … }, interest: { amount: { value: BigDecimal(4.2), }, // … },};\nThe corresponding reserve needs to have canUseAsCollateral: true to be possible to use as collateral.\nPreview Changes#\nPreview the impact of changing collateral status before executing the transaction.\nDisabling a supplied asset as collateral may reduce the position's health\nfactor. In some cases, this may put the position at risk of being liquidated.\nReactTypeScriptGraphQLSolidityUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of collateral status changes on the user's position.import { type SetUserSuppliesAsCollateralRequest, usePreview,} from \"@aave/react\";\nfunction CollateralPreview({ request,}: { request: SetUserSuppliesAsCollateralRequest;}) { const { data, error, loading } = usePreview({ action: { setUserSuppliesAsCollateral: request, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor?.current ?? \"N/A\"}</p> <p>To: {data.healthFactor?.after ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p>\n <h3>Max Borrowing Power:</h3> <p>From: {data.maxBorrowingPower.current.value.toDisplayString(2)}</p> <p>To: {data.maxBorrowingPower.after.value.toDisplayString(2)}</p> </div> );}Where the SetUserSuppliesAsCollateralRequest can be as follows:const request: SetUserSuppliesAsCollateralRequest = { sender: evmAddress(\"0x123…\"), // User's address changes: [ { reserve: supplyPosition.reserve.id, enableCollateral: true, // false to disable collateral }, ],};The PreviewUserPosition shows the impact of the collateral status change by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is betternetCollateral.[current → after]: ExchangeAmountHigher is bettermaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerotherConditions: UserPositionConditionVariation[]Dynamic config changes\nEnabling collateral updates the Dynamic Config just for the reserve being enabled, while disabling collateral updates the Dynamic Config for all reserves in which the user has supplies or borrows within the same user position.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus changeYou can also specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = usePreview({ action: { setUserSuppliesAsCollateral: request, }, currency: Currency.Eur,});\nStep-by-Step#\nToggle the collateral status of any supplied asset using the following steps.\nEnabling collateral updates the Dynamic Config—Collateral Factor, Liquidation\nFee, and Max Liquidation Bonus—for the supplied asset. Disabling collateral is\na risk-increasing action that updates the Dynamic Config and, consequently,\nthe User Risk Premium for the entire user position. See User Position\nConditions for more details.\nReactTypeScriptGraphQLSolidityTo enable or disable a supplied asset as collateral, follow these steps.1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Define the Collateral Management Flow#Use the useSetUserSuppliesAsCollateral hook to prepare the transaction request.import { useSetUserSuppliesAsCollateral } from \"@aave/react\";\nconst [setAsCollateral, { loading, error }] = useSetUserSuppliesAsCollateral( (transaction) => sendTransaction(transaction),);3Execute the Transaction#Then, update the collateral status.import { evmAddress } from \"@aave/react\";\nconst execute = async () => { const result = await setAsCollateral({ sender: evmAddress(wallet.account.address), // User's address changes: [ { reserve: supplyPosition.reserve.id, enableCollateral: true, }, ], });};\n// …4Handle the Result#Finally, handle the result.const execute = async () => { const result = await setAsCollateral(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Collateral set successful with hash:\", result.value);};\n\nAdvanced Usage#\nNetwork Fee#\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nEstimate the network cost of any action using the same PreviewAction you pass to the usePreview hook.\nLet's consider the following example:\nimport { type PreviewAction } from \"@aave/react\";\nconst action: PreviewAction = { supply: { sender: evmAddress(\"0x123…\"), // User's address reserve: supplyPosition.reserve.id, amount: { erc20: { value: bigDecimal(42), // USDC }, }, },};\nUse the useNetworkFee hook to estimate both the network fee for the provided action and its fiat equivalent.\nimport { type PreviewAction, Currency } from \"@aave/react\";import { useNetworkFee } from \"@aave/react/viem\";\nfunction NetworkFee({ action }: { action: PreviewAction }) { const { data: fee, loading, error, } = useNetworkFee({ query: { estimate: action }, currency: Currency.Eur, });\n if (loading) return <p>Loading fee…</p>; if (error) return <p>Error: {error.message}</p>;\n return ( <p> Network Fee: {fee.amount.value.toDisplayString(2)} {fee.token.info.symbol} <span> ≈{fee.exchange.symbol} {fee.exchange.value.toDisplayString(2)} </span> </p> );}\nNative Tokens#\nWhen the Reserve's underlying token is the wrapped version of the chain's native token (e.g., WETH on Ethereum), you can supply the asset as the chain's native token using the Native Token Gateway.\nUse the reserve.asset.underlying.isWrappedNativeToken flag to determine if the underlying token is a wrapped native token. The Native Gateway address is available from the chain details.\nconst reserve: Reserve = { id: \"SGVsbG8h\", onChainId: \"42\", canSupply: true, canUseAsCollateral: true, asset: { underlying: { address: \"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\", info: { name: \"Wrapped Ether\", symbol: \"WETH\", decimals: 18, // … }, isWrappedNativeToken: true, // … }, // … }, settings: { supplyCap: { amount: { value: BigDecimal(2000000000.0) }, // 2B WETH // … }, // … }, spoke: { address: \"0x123…\", // … }, chain: { chainId: 1, name: \"Ethereum\", nativeGateway: \"0xabc…\", }, // …};\nSpecify the amount in the amount field as a native value.\nReactTypeScriptGraphQLSolidityconst execute = async () => { const result = await supply({ sender: evmAddress(wallet.account.address), // User's address reserve: reserve.id, amount: { native: bigDecimal(42), // 42 ETH }, });\n // …};PreviousOpen PositionsNextBorrow Assets","tokens":4237,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258314755,"hash":"a7bf8176e7ef10431153255716e943ec030f19f4"}
{"url":"https://gov.optimism.io/t/404-gov-delegate-platform/10558/2","domain":"gov.optimism.io","title":"404 Gov - Delegate Platform - Communications 📣 / Delegates 🏛 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Communications 📣Delegates 🏛\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 13\n\n 2 / 2\n\n Oct 3\n\n 1d ago\n\n post by 404DAO on Jan 13\n\n 404DAO\n\n An important update regarding the future of 404 DAO’s governance operations.\nSince entering the governance space in 2022, 404 Gov has been an active voice and participant in some of the industry’s largest DAOs. What started as a small team of Georgia Tech students focusing on contributing to the Optimism DAO, quickly grew to becoming a trusted delegate in 10 ecosystems.\nAs the governance team evolved and members ventured into new opportunities, we began to evaluate what was the best path forward for our governance vertical. We determined that our delegated voting power deserves a dedicated steward who can commit the time and focus it requires.\nSo while 404 Gov is taking a step back from governance, the mission and work will continue with one of our team members, Rika, under her new entity, Axia Network, which has taken over the voting wallets and governance operations. Going forward, Axia Network is responsible for the voting activity of 0xE93D59CC0bcECFD4ac204827eF67c5266079E2b5. Their work and delegation rationale can be found at the following account: Axia Network\nRika has been a core part of our team’s operations for many years now and deeply understands the responsibility involved with being a delegate. We are confident that the delegations will continue to be handled with professionalism under her stewardship. However, those that wish to remove their delegations may do so on Agora.\nThis transition applies only to governance-related wallets and profiles. Our partnership with Blockchain at Georgia Tech and educational work in Atlanta remains active.\nThank you to those who entrusted us with their voting power for so many years and thank you to the DAOs and contributors we’ve collaborated with in Optimism. It has been a privilege to take part in this ecosystem.\n\n Formally Announcing Axia Network\n\n 9 months later\n\n post by DarkEmpath888 1 day ago\n\n DarkEmpath888\n\n Please explain what this is … thanks, Jessica\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Formally Announcing Axia Network\n\n Delegate Updates\n\n season-9\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole…\n\n read more\n\n 0\n\n 51\n\n Jan 13\n\n Build a dedicated page for Delegation/Voting History\n\n ✨ General\n\n Right now, the only place to see all the delegates and make a selection is buried in the middle of the airdrop claim process (Optimism Gateway). There is another URL that shows the delegates, but there’s no functionality…\n\n read more\n\n 6\n\n 2.0k\n\n Jun 2022\n\n Protocol Delegation Program Renewal\n\n Metagovernance\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d\n\n Agora Updates & Feedback thread\n\n Delegates 🏛\n\n Hey everyone Charlie here from team Agora. \nReally appreciate everyone for trying out Optimism Agora Beta with the first test proposal and giving us such helpful feedback. \nWe’ve been reading all the posts, comme…\n\n read more\n\n 46\n\n 5.8k\n\n Dec 2024\n\n Governance Fund Observations\n\n Delegates 🏛\n\n Hello Optimism Community! @tnorm and I are two analysts on the Messari Governor team, and we’ve been covering Optimism governance as part of our daily workflow since the DAO launched. \n(Disclaimer: The thoughts, ideas, a…\n\n read more\n\n 11\n\n 4.8k\n\n Sep 2022","tokens":970,"squid":"ink-governance","role":"Council Listener","at":1791258317886,"hash":"0b307ffb3f80ec871959af8e8c7a95061fa1e69e"}
{"url":"https://www.openzeppelin.com/news/rwa-wizard-issue-regulated-real-world-assets-on-stellar","domain":"openzeppelin.com","title":"Introducing RWA Wizard: Issue Regulated Real-World Assets on Stellar","text":"August 27, 2026OpenZeppelinOpenZeppelin RWA Wizard is now available for Stellar: a no-code interface for generating secure, standard-based smart contract scaffold that represents a real-world asset (RWA), such as a fund, bond, or private equity share, as a regulated token on Stellar.It is built for developers tokenizing assets, where every holder must be verified and every transfer must satisfy the applicable compliance rules. The contracts it generates follow ERC-3643 (T-REX protocol), the institutional standard for permissioned digital securities, and build on OpenZeppelin’s Stellar Contracts Library and SEP-0057.Configuring a regulated real-world asset on Stellar with OpenZeppelin RWA WizardThe RWA Wizard for Stellar walks through five steps, each mapping to a real part of a compliant deployment: asset setup, identity and claims, compliance modules, access-control roles, and a final review.Configure the assetDefine the token: name, symbol, decimals, and an optional initial supply.Enable the administrative controls the contract exposes: burnable for redemptions and buybacks, mintable for primary issuance, and pausable for an emergency halt on transfers, mints, and burns.Note that burns and mints still run through the compliance hooks, so these controls remain subject to the configured rules.Set up identity and claimsConfirm the verification approach. The OpenZeppelin RWA Wizard scaffolds claim-based verification, in which every holder carries a verified onchain identity (ONCHAINID) with cryptographic claims signed by trusted issuers.Select the claim topics the token enforces: KYC, AML, accreditation, tax residency, or add custom topics.Register the trusted claim-issuer contracts permitted to sign those claims.Enable the identity-lifecycle controls operators can use: address-level freezing, partial token freezing, account recovery for lost or compromised wallets, and forced transfers.Note that personally identifiable information never touches the chain; only hashes and signed claims are stored in each ONCHAINID.Select compliance modulesSelect the compliance modules to enforce: supply limits, per-identity balance caps, country restriction and allow-lists, transfer allow-lists, initial lockup periods, and time-based transfer limits.Configure each module's parameters, such as a maximum total supply or a per-identity balance ceiling.Check the hook wiring preview, which shows exactly which modules run on which token operations (transferred, created, destroyed) before deployment.Note that modules are pluggable rules the T-REX Compliance contract runs through post-operation hooks, so a rule can reject and revert an operation atomically.Assign roles and accessChoose the ownership model: single owner, multi-sig, or DAO.Set the owner address that receives the admin role at deployment.Assign the operator roles, such as manager, minting, and burning, to the addresses responsible for day-to-day operation of the asset.Review and generateReview the full configuration summary before generating.Resolve any preflight warnings. For example, if the supply limit or per-identity max balance is set below the initial supply, the wizard flags that the created compliance hook would reject the mint, and indicates how to resolve it.Generate the project to produce a downloadable archive with everything needed to build and deploy: the contracts, build.sh and deploy.sh scripts, and a README.md quick start.After generationGeneration does not deploy onchain. The generated project runs against Stellar testnet with a funded CLI identity that matches the configured admin.For learning and testing, the export can optionally include testnet identity scaffolding: example claim-issuer and identity tooling plus a bootstrap script that onboards the admin and mints the configured initial supply, making the full end-to-end flow observable without standing up production KYC first. This path is for testnet and demonstration only, not for production issuance.Running production KYC, connecting real claim issuers, and onboarding investors is the integrator's responsibility. The wizard ships demo-only issuers, not production issuer infrastructure.Video tutorialOpenZeppelin RWA Wizard: CLI and UIOpenZeppelin RWA Wizard for Stellar is available as a guided UI and a CLI. Both are backed by the same code-generation package and consume and produce the same configs and artifacts, allowing movement between the guided wizard and scripted deployments without changing the underlying output.Get startedThe RWA Wizard is currently available for generating regulated RWA contracts for Stellar testnet.FAQsWhat is OpenZeppelin RWA Wizard?OpenZeppelin RWA Wizard is a no-code interface for generating the smart contracts to issue a regulated real-world asset (RWA), such as a fund, bond, or private equity share, as a permissioned token. It currently supports Stellar: the contracts follow the ERC-3643 compliance standard, and build on OpenZeppelin's Stellar Contracts library and the SEP-0057 contract-type standard.What is the ERC-3643 standard for real-world assets?ERC-3643, also known as the T-REX protocol, is an institutional standard for permissioned digital securities. It enforces that only verified identities can hold or receive a token and that every transfer satisfies configurable compliance rules, using an onchain identity layer and a set of pluggable compliance modules.Can a Stellar RWA token be deployed to mainnet?The Wizard targets Stellar testnet, and both the app and the export default to testnet. Generation does not deploy onchain; the generated scripts run against testnet with a funded CLI identity. Before mainnet, the integrator is responsible for production KYC, key custody, real issuer infrastructure, and an independent audit.What does the generated Stellar RWA project include?A downloadable archive containing the smart contracts, build.sh and deploy.sh scripts, and a README.md quick start. On testnet, the export can optionally include example identity tooling and a bootstrap script that onboards the admin and mints the configured initial supply.","tokens":1527,"squid":"ink-security_audits","role":"Sentinel","at":1791258318389,"hash":"984a03ef22342dbd446d4701eb5900e4b413ecb8"}
{"url":"https://aave.com/docs/aave-v4/tools/exchange-rate","domain":"aave.com","title":"Live Exchange Rates | Aave Protocol Documentation","text":"Exchange Rates#\nLearn how to fetch exchange rates between tokens and supported currencies on Aave v4.\n\nExchange rates in Aave are provided by Oracles using Chainlink price feeds.\nAaveKit provides current conversion rates between ERC-20 tokens, native tokens, and supported currencies: USD, EUR, and GBP. For smart-contract integrations, query USD reserve prices directly from the spoke oracle.\nReactTypeScriptGraphQLSolidityUse the useExchangeRate hook for live exchange rates with automatic polling every 10 seconds, or the imperative useExchangeRateAction hook for on-demand exchange rates.import { type ExchangeRateRequest, useExchangeRate } from \"@aave/react\";\nfunction ExchangeRate({ request }: { request: ExchangeRateRequest }) { const { data, loading, error } = useExchangeRate(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n // data: ExchangeAmount return ( <span> {data.symbol} {data.value.toFixed(2)} </span> );}See below some examples of request objects.import { evmAddress, chainId, Currency } from \"@aave/react\";\nconst request: ExchangeRateRequest = { from: { erc20: { chainId: chainId(1), address: evmAddress(\"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\"), }, }, to: Currency.Usd,};PreviousUser ActivitiesNextSwap Features","tokens":324,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258325588,"hash":"1eb337776a4feba5d5bcae37d152f86f94530c39"}
{"url":"https://www.openzeppelin.com/news/miden-smart-contracts-audit","domain":"openzeppelin.com","title":"Miden Smart Contracts Audit","text":"August 26, 2026OpenZeppelin SecuritySummaryType: LibraryTimeline: 2026-05-18 → 2026-06-30Languages: Rust and MASMFindingsTotal issues: 60 (50 resolved, 4 partially resolved)Critical: 0 (0 resolved) · High: 0 (0 resolved) · Medium: 11 (7 resolved, 2 partially resolved) · Low: 17 (14 resolved, 2 partially resolved)Notes & Additional Information32 notes raised (29 resolved)Client Reported Issues0 reported issues (0 resolved)ScopeOpenZeppelin performed an audit of the 0xMiden/protocol repository at commit 2ef8056.In scope were the following files:crates/miden-standards/\n├── asm/\n│ ├── account_components/\n│ │ ├── access/\n│ │ │ ├── ownable2step.masm\n│ │ │ ├── rbac.masm\n│ │ │ └── authority.masm\n│ │ ├── auth/\n│ │ │ ├── guarded_multisig.masm\n│ │ │ ├── multisig.masm\n│ │ │ ├── no_auth.masm\n│ │ │ ├── singlesig.masm\n│ │ │ └── singlesig_acl.masm\n│ │ └── faucets/\n│ │ ├── fungible_faucet.masm\n│ │ └── policies/\n│ │ ├── burn/\n│ │ │ ├── allow_all.masm\n│ │ │ └── owner_controlled/owner_only.masm\n│ │ ├── mint/\n│ │ │ ├── allow_all.masm\n│ │ │ └── owner_controlled/owner_only.masm\n│ │ ├── policy_manager.masm\n│ │ └── transfer/\n│ │ ├── allow_all.masm\n│ │ ├── basic_blocklist.masm\n│ │ └── blocklist/owner_controlled.masm\n│ └── standards/\n│ ├── access/\n│ │ ├── ownable2step.masm\n│ │ ├── rbac.masm\n│ │ └── authority.masm\n│ ├── auth/\n│ │ ├── guardian.masm\n│ │ ├── mod.masm\n│ │ ├── multisig.masm\n│ │ ├── signature.masm\n│ │ └── tx_policy.masm\n│ └── faucets/\n│ ├── fungible.masm\n│ └── mod.masm\n└── src/\n └── account/\n ├── access/\n │ ├── ownable2step.rs\n │ ├── rbac.rs\n │ └── authority.rs\n ├── auth/\n │ ├── mod.rs\n │ ├── no_auth.rs\n │ ├── singlesig.rs\n │ ├── singlesig_acl.rs\n │ ├── multisig.rs\n │ └── guarded_multisig.rs\n ├── policies/\n │ └── transfer/\n │ ├── allowlist/\n │ │ ├── mod.rs\n │ │ └── owner_controlled.rs\n │ └── basic_allowlist.rs\n └── faucets/\n ├── mod.rs\n ├── token_metadata.rs\n └── fungible/mod.rs\n\ncrates/miden-protocol/src/account/access.rsSystem Overviewmiden-standards is a library of reusable Miden Assembly components for building accounts and fungible-token faucets on Miden, so that integrators can assemble accounts from prebuilt modules instead of reimplementing authentication, access control, and policy enforcement. It is organized in two layers: the asm/standards/ modules hold the core logic, and the asm/account_components/ modules package that logic as installable components exposed through the Rust builder API. Most account-component procedures are thin re-exports, though some (notably the authentication entry points and the authority gate) add their own composition logic.A transaction executes against a single account, consuming zero or more input notes and anchored to a reference block, and produces the updated account plus zero or more output notes. An optional transaction script drives top-level execution. The kernel runs four stages: a prologue that prepares the execution context, execution of each input note's script, execution of the transaction script and any account procedures called, and an epilogue that computes the account delta, note commitments, and fee before the proof is produced.All data supplied outside the operand stack (signatures, policy roots, signer public keys) arrives through the advice provider, an unverified input channel, and must be authenticated against a known commitment before use.Storage is read in two modes: initial-state reads (as at transaction start) and current-state reads (reflecting writes made earlier in the same transaction). Authentication and policy paths deliberately use initial-state reads so that a signer or policy update made during a transaction cannot retroactively authorize that same transaction; mixing the modes in security-critical paths risks time-of-check to time-of-use hazards.Two features that bear on the security model were not final during the review: the fee mechanism was under revision, and deployed accounts have no code-upgrade path.AuthenticationThe authentication component is the account-level gate: it decides whether an entire transaction is authorized at all, independent of which procedures it calls. Five components are in scope.NoAuth: permits every transaction without a signature check; intended for accounts controlled entirely at the note-script or caller level.SingleSig: requires a single signature using either ECDSA over secp256k1 (signing a Keccak-256 hash of the transaction summary) or a Poseidon2-based variant of Falcon-512. The signed transaction summary commits to the account delta, the input and output note commitments, the reference block number, and the final nonce.SingleSigAcl: extends SingleSig with an access-control list. Procedure roots can be registered as triggers that require a signature, and separate flags control whether creating output notes or consuming input notes requires one. When none of these conditions holds, the transaction only increments the nonce and completes unsigned.Multisig: k-of-n approval, where each signer is a public key commitment stored in a storage map, with per-procedure threshold overrides.GuardedMultisig: extends Multisig with a guardian key that must co-sign every transaction, in addition to the multisig threshold. The sole exception is guardian-key rotation: when update_guardian_public_key is the only non-auth procedure called and the transaction has no notes, the guardian check is skipped so the key can rotate without the outgoing guardian.Access ControlAccess control operates at the procedure level, inside a transaction the auth component has already permitted, restricting which callers may invoke which operations.Ownable2Step: two-step ownership transfer in which the nominee must explicitly accept, avoiding transfers to unreachable addresses. Ownership gates procedure-level execution, not the right to transact.Rbac: role-based access control backed by a storage map from role identifiers to membership bitmaps.Authority: an account-wide gating mode for authority-gated setters such as policy and metadata management, with three variants. OwnerControlled requires the owner, RbacControlled a role holder, and AuthControlled delegates the check to the authentication component.Faucet StandardsThe fungible faucet mints and burns under a policy framework managed by TokenPolicyManager. Mint and burn policies run internally at operation time, with the active policy root held in a value slot. Send and receive policy roots live in the protocol-reserved kernel callback slots: a faucet configured with a transfer policy installs those slots and stamps a callback flag on every asset it mints, so the kernel invokes the active send or receive policy whenever the asset moves (a faucet with no transfer policy installs no slots and mints unflagged assets). Policies can be registered as immediately active or reserved for later promotion. In-scope implementations include allow-all, owner-only mint and burn, and basic blocklist transfer policies with owner-controlled membership.Security Model and Trust AssumptionsAuthorization LayersThe library defines authorization at two levels that must not be conflated. The authentication layer decides who may transact against an account at all, meaning who can produce a valid proof that changes its state, consumes its input notes, or creates output notes on its behalf. The access-control layer operates inside an already-permitted transaction, restricting which callers may invoke specific procedures.The layers are complementary, not interchangeable. Protecting a procedure with Ownable2Step or Rbac does nothing to stop an unauthorized party from transacting against the account if the authentication component allows it, nor from creating notes on the account's behalf. Those notes carry the account's identity as sender, so a weak authentication model lets any party emit notes bearing the account as sender and bypass sender-based checks on other accounts. An account's posture depends on both layers.Signing ModelThe transaction model is ZK-provable: a transaction is valid if and only if a valid proof exists, so every MASM check is a constraint on the proofs the verifier accepts, and the prover always knows all witness data.Authentication components sign transaction effects, not actions. A signature covers what the transaction does to account and note state (the account delta, input note, and output note commitments), not which procedures ran or with what arguments. Effects absent from the signed summary are unconstrained, so any protocol expansion must keep what a component signs aligned with the effects it must authorize. During the review, the transaction fee and the reference block commitment were found to be outside the signed summary of certain components. Relatedly, Miden supports delegated proving, where the owner signs the summary and a separate prover generates the proof: the transaction script, cycle count, and fee are unsigned, so a delegated prover can substitute or pad the script within the summary's constraints.Trust AssumptionsThe MASM and kernel layers do not validate initial storage values at account creation. Policy roots, authority discriminators, role symbols, mutability flags, and signer configurations are trusted as set at initialization and assumed consistent with component invariants. For faucets specifically, the allowed-policies maps, initial active policy roots, authority discriminator, and mutability flags are assumed configured consistently at deployment; the runtime checks a policy root against the allowed map at set time but does not constrain which policies are initially permitted.Under Authority::AuthControlled, every authority-gated setter is gated solely by the authentication component, so if that component has any permissionless path the setters are reachable with no key material. Similarly, SingleSigAcl completes a note-free transaction that calls an unregistered state-changing procedure without a signature, so every procedure meant to require authorization must be registered as a trigger.Rust-layer validation is not an on-chain trust boundary. Rbac role symbols are the clearest case: on-chain the only check is that the symbol is non-zero, so any non-zero field element is a valid role key. The Rust RoleSymbol type is stricter, rejecting values that are out of range or do not decode cleanly. A role granted on-chain with a felt the Rust type rejects, reached through a crafted note or a direct storage write, works as an access key on-chain but is unrepresentable off-chain: Authority::try_from and the storage display path both call RoleSymbol::try_from and error on it, leaving the account valid on-chain yet unreadable to the Rust SDK and any indexer built on it. Integrators are assumed to construct role symbols through the builder API, which the on-chain layer does not enforce.Ownable2Step adds limited assurance for signature-based accounts, since the owner already controls which transactions are signed and can decline to sign an ownership transfer, making the second step largely redundant with the auth layer. For network accounts the constraint is different: the Miden node operator set is currently centralized, and operators decide which notes are applied to network accounts, so an operator can censor an ownership-transfer note regardless of its validity.SingleSigAcl requires that every state-changing procedure intended to require authorization is registered in the trigger procedure map. A transaction with no input or output notes that calls an unregistered state-changing procedure will increment the nonce and complete without a signature.Medium SeverityTransfer Policies Registered as Reserved Can Never Be ActivatedA fungible faucet enforces its send and receive policies through asset callbacks that the kernel dispatches only when an asset carries the callbacks flag stamped at mint from has_callbacks. The active root for a send or receive policy lives directly in a protocol-reserved callback storage slot, and the TokenPolicyManager builder seeds those slots from the active roots while omitting any slot whose root is empty. The builder also exposes a Reserved registration intended to register a policy now and promote it later.When a transfer policy is registered as Reserved with no active policy of that kind, the registration is accepted unconditionally and the root is recorded as an allowed root, but the active root stays empty so the callback slot is never written to storage. Promotion is then impossible:The faucet is created with a transfer policy registered as Reserved. The root appears in the allowed-roots map, so the configuration looks valid, but no callback slot exists.The owner later calls set_send_policy or set_receive_policy to promote the reserved root, which writes the callback slot through set_item.set_item aborts with ERR_ACCOUNT_UNKNOWN_STORAGE_SLOT_NAME because the slot does not exist, and account storage slots cannot be created after initialization (tracked as a future feature in issue #2183).The reserved transfer policy is therefore stranded permanently. Nothing fails at build or mint time, so the faucet appears configured while the policy can never be enforced, and if no transfer policy is active the faucet mints callback-exempt tokens for its entire life. This is specific to transfer policies: mint and burn keep their active root in a dedicated value slot that is always created, so their reserved-then-promote flow works. A related risk is latent should runtime storage upgrades land: if the callback slot can be created after the fact, has_callbacks would flip from false to true mid-life, and since the callbacks flag is encoded in the fungible asset's vault key, tokens minted before and after activation would not aggregate and the earlier tokens would stay exempt.Consider rejecting the configuration at build time by requiring an active send or receive policy whenever any policy of that kind is registered, or alternatively seeding the callback slot with a non-empty default transfer root (such as an allow-all root) whenever any transfer policy is registered, so the slot always exists, has_callbacks is fixed at creation, and promotion has a slot to write.Update: Resolved in pull request #3047.Policy Getters Violate the 16-Felt call ABIThe TokenPolicyManager standard exposes a set of public procedures that read the active policy roots and are intended to be invoked via call. Procedures invoked this way operate on a fixed 16-felt operand stack: they receive [pad(16)] and must return exactly 16 felts. Accordingly, get_mint_policy, get_burn_policy, get_send_policy, and get_receive_policy are each documented as accepting [pad(16)] and returning the policy root followed by pad(12).These getters do not honor that ABI. Each one reads a storage slot through active_account::get_item and returns immediately, without removing the extra word of padding. Because get_item consumes the two slot-identifier felts and pushes back a full word, it grows the stack by two felts.As a result, every get_*_policy procedure is effectively unusable through call, and any composed script that relies on the documented return frame breaks. The companion setters are unaffected, since they end with a dropw that restores the 16-felt frame.Consider normalizing the return frame of each get_*_policy procedure by dropping one word of padding after the policy root is loaded. Additionally, consider adding conformance tests that invoke each call procedure and assert the return stack depth is exactly 16, so future regressions of the call ABI are caught automatically.Update: Resolved in pull request #3114 at commit 6f765dd.Ownership Transfers and Role Assignments Are Permanently Restricted to Version-One Account IDsThe account_id::validate procedure accepts only version-one account IDs, asserting eq.VERSION_1. Both transfer_ownership in the Ownable2Step component and the RBAC component's grant_role and revoke_role paths statically link this procedure through exec, so the version-one restriction is compiled into each component's code commitment. For an immutable account carrying these components, the code commitment cannot change, so the account can never nominate a new owner or grant a role to an account whose ID uses a future version, even after the protocol introduces support for such versions.The current owner retains full control and every other component operation continues to function, so the components are not rendered unusable. However, ownership transfers and role assignments cannot cross a version boundary. If version-one accounts are eventually deprecated, ownership and roles held through such immutable accounts become stranded, recoverable only by deploying a fresh account or, for mutable accounts, upgrading the component code.Consider validating only the structural requirements of an account ID in these components, without constraining the version.Update: Resolved in pull request #3188 at commit 792f143 and in pull request #3216 at commit 7f97d2b.Authority-Gated Setters Are Permissionless When AuthControlled Is Paired with AuthSingleSigAclThe Authority component selects a single account-wide gating mode that every authority-gated setter consults, including the TokenPolicyManager procedures set_mint_policy, set_burn_policy, set_send_policy, and set_receive_policy, as well as the fungible token metadata setters and the pause controls. Each such setter calls authority::assert_authorized before writing to storage. Under Authority::AuthControlled, assert_authorized is a no-op, so the account's auth component becomes the sole gate for every authority-gated setter. The Authority::AuthControlled documentation states this invariant explicitly: the auth component must authenticate every setter root, otherwise the setters become permissionless.When the chosen auth component is AuthSingleSigAcl, this invariant does not hold under the component's default configuration. The auth_tx_acl procedure requires a signature only when a registered trigger procedure was called, when output notes were created and allow_unauthorized_output_notes is false, or when input notes were consumed and allow_unauthorized_input_notes is false. When none of these conditions hold, control reaches the else branch, which increments the nonce and finalizes the transaction without verifying any signature. The default configuration produced by AuthSingleSigAclConfig::new registers an empty trigger list, so no setter root is tracked, and a transaction that consumes no input notes and creates no output notes satisfies none of the signature conditions regardless of the allow_unauthorized_* flags. The transaction-is-empty check in the epilogue does not prevent this, because it rejects a transaction only when the account delta is empty and there are no input notes, and a policy write produces a non-empty delta.As a result, an unauthorized party holding no key can rewrite the policy of any account that installs Authority::AuthControlled, AuthSingleSigAcl, and an authority-gated component such as TokenPolicyManager:The attacker constructs a transaction with no input notes and no output notes whose script calls set_mint_policy.assert_authorized is a no-op under AuthControlled.auth_tx_acl finds no triggered procedure and no note usage, takes the else branch, and increments the nonce without a signature.The policy write produces a non-empty delta, the epilogue accepts the transaction, and the attacker's policy persists.This permits any party to overwrite the mint, burn, send, and receive policies, the maximum supply, the metadata, and the pause state of an affected account. Because the unsafe behavior is present in the default AuthSingleSigAcl configuration rather than being gated behind a relaxed flag, an integrator that pairs these standard components without registering every gated setter as a trigger procedure ships an account whose policies are publicly writable. The remaining authority modes do not share this exposure, since under OwnerControlled and RbacControlled the call to assert_authorized reverts for an unauthorized sender and aborts the transaction before any write occurs. The purpose of AuthSingleSigAcl, which is to permit selected operations without a signature, is in direct tension with the AuthControlled premise that the auth component gates every setter.Consider enforcing this invariant at account construction rather than relying on documentation. When AuthSingleSigAcl is installed alongside Authority::AuthControlled and an authority-gated component, account construction could require that every authority-gated setter root is present in auth_trigger_procedures and fail otherwise. At a minimum, consider documenting on Authority::AuthControlled that pairing it with a permissive auth component leaves authority-gated setters reachable without a signature even under the most restrictive configuration, and enumerating the setter roots an integrator must register as trigger procedures.Update: Partially Resolved in pull request #3180 at commit b690f1a. A tracking issue was created to address the remaining items.Account Authentication Does Not Bound the Deducted Transaction FeeSingleSig authentication signs the commitment of a transaction summary built by create_tx_summary, covering ACCOUNT_DELTA_COMMITMENT, INPUT_NOTES_COMMITMENT, OUTPUT_NOTES_COMMITMENT, and a SALT of [0, 0, ref_block_num, final_nonce]. The reference block number is deliberately included so that the signer commits to the fee parameters of its intended reference block, which the documentation in authenticate_transaction describes as determining \"the fee amount that is deducted.\"However, the deducted fee is not fully determined by those parameters. The kernel computes it as verification_base_fee multiplied by ilog2(num_tx_cycles) + 1 in compute_fee, where the cycle count is an input that the signed summary does not constrain. The transaction script that drives the cycle count is supplied by the prover from the advice stack in process_tx_script_data and is absent from the summary. The fee is computed from clk only after the account delta commitment has been finalized, and compute_and_remove_fee removes the fee asset from the vault without affecting the delta, since the code treats modifications at that point as \"essentially ignored.\" As a result, a party that re-proves the transaction in a delegated-proving or relaying setting can reuse the existing signature while substituting a script that preserves the delta and note commitments but executes additional cycles, increasing the fee charged to the signer's account.This belongs to a broader class of issues in which the native account is charged a transaction fee that its owner never authorized or bounded, because the fee is applied unconditionally once the authentication procedure completes and is never part of the signed message. The same exposure appears more directly in components that expose a permissionless completion path, such as auth_tx_acl, where a transaction that consumes a note or makes a non-trigger state change can complete with no signature as long as note usage stays within the allow_unauthorized configuration. In that case an attacker needs neither a reused signature nor cycle padding to make the account pay a fee. Across these cases the practical effect is the same: slow balance erosion through repeated unauthorized fee payments, rather than direct theft, since the fee accrues to the block producer and not to the attacker.The amplification available to a re-prover is constrained by the fee's logarithmic dependence on the cycle count. The prover's compute grows linearly with the number of padded cycles, while the resulting fee grows only as ilog2 of that count, so each additional unit of fee charged to the victim requires roughly doubling the attacker's proving work. This holds even when the attacker is the block producer that collects the fee, since the proving cost of the padded transaction is borne by the attacker, making amplification beyond the baseline fee economically self-defeating.Consider binding the fee to what the account authorizes, for example by including an explicit maximum fee amount (or fee faucet and amount) in the transaction summary and enforcing it during fee computation, or by committing to the transaction script root. For permissionless completion paths, consider drawing the fee against a value the account can constrain rather than allowing any completing transaction to deduct it unconditionally.Update: Acknowledged, will resolve. The fee deduction mechanism was removed from the kernel to be re-implemented in the future.ECDSA Authentication Discloses Signer Public Key and Signature via Precompile CalldataMiden's precompile framework currently relies on native re-verification: the proof verifier recomputes each precompile commitment from the raw calldata that is carried inside the transaction proof, so that calldata must travel with the transaction in order for it to verify. The signature authentication components store only a single-word Poseidon2 commitment to the public key on-chain, in PUBLIC_KEY_SLOT, and the raw public key is supplied non-deterministically at authentication time and checked against that commitment.When an account authenticates with the ecdsa_k256_keccak scheme, exec.ecdsa_k256_keccak::verify emits an event whose handler records a precompile request whose calldata is the concatenation of the 33-byte compressed public key, the 32-byte message digest, and the 65-byte signature. This calldata is folded into ExecutionProof.pc_requests, serialized into the ProvenTransaction, submitted over the public SubmitProvenTx RPC, and consumed by the node verifier. It cannot be stripped or withheld, because the recomputed precompile transcript is bound into the proof's public inputs and verification fails without the exact calldata. As a result, the raw secp256k1 public key and signature are disclosed to the node operator and to any party on the transaction submission or gossip path, even though the account commits on-chain only to Poseidon2(pk). This de-anonymizes the signer's public key that the commitment-based storage otherwise keeps private and constitutes a privacy asymmetry relative to the falcon512_poseidon2 scheme, which is verified entirely in-circuit and emits no public-key or signature calldata. The keccak256 hashing precompile similarly ships its full preimage, though in this authentication path that preimage is the 32-byte signed message commitment rather than transaction contents.Consider documenting that ecdsa_k256_keccak authentication exposes the signer public key and signature at proving time and therefore does not provide the public-key privacy implied by commitment-based storage, so that integrators requiring signer-key privacy can select falcon512_poseidon2 instead. Consider, as a longer-term measure, supporting the deferred precompile-proof verification path so that precompile calldata can remain part of the prover's witness rather than being transmitted with the transaction.Update: Resolved in pull request #3178 at commit aff1ed5.Multisig Getter Procedures Violate the 16-Felt call ABIThe multisig component exposes three public getter procedures annotated Invocation: call across all three variants (standard, guarded, and smart): get_threshold_and_num_approvers, get_signer_at, and is_signer. Procedures invoked via call must return to an operand stack depth of exactly 16; restore_context returns InvalidStackDepthOnReturn and aborts otherwise.None of the three getters honor this convention. get_threshold_and_num_approvers receives no input and returns two felts (depth 18). get_signer_at consumes one element and returns five (depth 20). is_signer consumes a four-element key and returns one element; because the stack cannot shrink below 16, the procedure returns at depth 17. Every external call or FPI dispatch to any of these procedures therefore aborts at runtime.The internal auth flow is unaffected because set_procedure_threshold reaches get_threshold_and_num_approvers via exec, which inlines the callee and bypasses the depth check. The other two getters have no internal callers, so their only reachable path is external, which always fails.Consider making each getter conform to the 16-felt call ABI by padding or truncating the operand stack before returning. Alternatively, if external invocation is not intended, annotate them Invocation: exec and remove them from the component's public re-exports.Update: Resolved in pull request #3211 at commit 7eae9cc.Signed Transaction Summary Does Not Bind Expiration or Reference Block CommitmentSignature-based authorization components build the message that the owner signs from the transaction summary produced by auth::create_tx_summary together with a SALT. Assembled in authenticate_transaction, the signed message is [ACCOUNT_DELTA_COMMITMENT, INPUT_NOTES_COMMITMENT, OUTPUT_NOTES_COMMITMENT, SALT], where SALT is [0, 0, ref_block_num, final_nonce]. The signature therefore commits to the account delta, the input and output notes, the final nonce, and the reference block number, but to no other transaction parameter. In a delegated-proving model, the party that executes and proves the transaction is untrusted and controls every field that the signature does not bind. For multisig accounts, multisig::auth_tx accepts a caller-supplied SALT and never calls tx::get_block_number, so ref_block_num does not enter the signed message at all.Two such fields influence transaction semantics. The first is the transaction expiration. The expiration block number is initialized to the non-expiring default MAX_BLOCK_NUM by the prologue and can only be lowered by the transaction script through tx::update_expiration_block_delta. The authorization component never reads it, and it never enters the signed summary. A relayer or prover holding a valid signature can omit or alter the expiration update and re-prove the transaction with an arbitrary validity window without invalidating the signature, because the delta, notes, and nonce remain unchanged. A transaction that the owner intended to expire shortly can thus be left with the default window and remain includable far beyond the owner's intent. Because expiration is a consensus-relevant validity constraint enforced during batch and block construction, this defeats the primary staleness control rather than being cosmetic.The second field is the reference block commitment. For singlesig accounts, only ref_block_num is bound; for multisig accounts, ref_block_num is absent from the signed message entirely. For all components, the corresponding BLOCK_COMMITMENT, which the prologue recomputes and asserts against the global inputs in process_block_data, is not. A block number maps one-to-one to a block commitment only on the canonical chain. Following a reorganization, height N can carry a different commitment and therefore expose different reference-block-derived state, and the same signed summary can be re-proven against that alternative block at the same height. The signed message also carries no chain or genesis identifier, so a summary that is valid on one network can be replayed on any network that shares history up to N where the same account state and notes exist. Reference-block fee parameters such as verification_base_fee are part of the block header and feed compute_fee. Under the current model these parameters are effectively constant across blocks, so the fee impact would materialize only under a future floating-fee model, but the reorganization and cross-network ambiguity exist independently of fees.Consider extending the signed transaction summary so that it binds every prover-controllable parameter that affects transaction validity or semantics.Update: Acknowledged, will resolve. The Miden team opened a pull request to work on this issue.Foreign Procedure Invocation Reads Reflect Prover-Chosen Reference Blocks Rather Than Current StateForeign procedure invocation allows an account to read another account's state during a transaction, but that read is a snapshot anchored to the transaction's reference block rather than the current chain state. The foreign account commitment is validated inside the proof against the reference block's account tree root in validate_active_foreign_account, and it is never reconciled against the live chain when the transaction is included in a block. The foreign account commitment is not part of the transaction's public inputs, and there is no revalidation of the specific storage slots read during the invocation against their current values at inclusion. Combined with the fact that executors may choose arbitrary reference blocks, the value returned by a foreign procedure invocation is effectively selected by whoever proves the transaction and may not reflect the foreign account's present state.This affects any logic whose correctness depends on the current value of foreign state. Cross-account authorization is one instance: if a component authorizes a change to its own state based on a role, permission, or allowlist entry stored in another account A, an actor able to author the transaction of the relying account B can anchor that transaction to a canonical reference block from before the privilege was revoked in A, so the check passes despite the revocation, provided B's own state remains unchanged so that its initial state commitment still matches the chain at inclusion. The same property affects oracle and price-dependent interactions, where an account can act on a stale value by anchoring to a past block in which that value was favorable, and more generally any flow that assumes foreign values are current at execution time. In each case the staleness window is controlled by the party proving the transaction rather than by the account that owns the data.The access-control standards shipped in the library are not affected, since they read and write roles within the same account that governs them. The exposure arises for components that read another account's mutable state through foreign procedure invocation, which downstream integrations building on these standards may reasonably do.Consider documenting that values read through foreign procedure invocation reflect a prover-chosen reference block and are never revalidated against current foreign state, so that integrators do not rely on them for decisions that require present values.Update: Resolved in pull request #3208 at commit e29fedf and at commit 9ddd0ff.Per-Procedure Threshold Overrides Can Reduce Required Signatures for Untracked Transaction EffectsThe multisig authentication flow in multisig::auth_tx derives the required signature threshold by calling compute_transaction_threshold. This function iterates over native account procedures and, for each one that was called, takes the maximum of its configured per-procedure override and the running threshold. The determination of whether a procedure was called relies on native_account::was_procedure_called, which returns 1 only when the procedure invoked account-restricted kernel APIs that trigger authenticate_and_track_procedure. Procedures that execute only local MASM instructions return 0 even if executed, and kernel APIs accessible from a transaction script, such as output note creation via output_note::create and foreign procedure invocation via tx::execute_foreign_procedure, do not trigger this tracking at all.As a result, a transaction script can call one native procedure configured with a low per-procedure threshold override, reducing transaction_threshold to that low value, and then freely perform additional effectful operations, such as creating output notes, executing FPI calls, or calling untracked local procedures, all authorized under the reduced threshold. The intended default_threshold is only enforced when no tracked native procedure was called; once any tracked procedure fires its override, non-procedure effects escape the higher threshold entirely.Consider whether output note creation, FPI calls, and transaction script effects should be included in the threshold computation (for example, by assigning them a threshold and taking their maximum alongside per-procedure overrides) so that a low per-procedure override cannot reduce the effective threshold below what those effects would otherwise require. Alternatively, consider documenting that per-procedure threshold overrides apply to the full transaction, including any untracked effects that accompany the overriding procedure call, so that threshold values are set with this in mind.Update: Resolved in pull request #3204 at commit 5431254 by adding output_note::create to the list of tracked procedures invoked during transaction execution. Integrators must designate output_note::create as a procedure that requires the reasonable authorization threshold. This ensures that procedures requiring only a low authorization threshold cannot be used to create associated output notes, and that output note creation always requires the reasonable authorization threshold.Repeated Unauthorized Input Note Consumption Can Drain an Account Through Transaction FeesThe AuthSingleSigAcl component authenticates a transaction conditionally. Signature verification is performed only when a configured trigger procedure was called, when output notes were created while allow_unauthorized_output_notes is false, or when input notes were consumed while allow_unauthorized_input_notes is false. When allow_unauthorized_input_notes is set, the input note check does not contribute to auth_required, so a transaction may consume input notes without any signature from the account owner. This is intended to let the account receive notes permissionlessly.In Miden, a transaction can be proved by any party on behalf of any account, and the consuming account pays the transaction fee unconditionally during the epilogue. A transaction that consumes at least one input note is valid even when it leaves the account vault and storage unchanged: the note consumption satisfies the non-empty transaction requirement, and because the account state does not change, no nonce increment is required, so the signature-free branch completes without incrementing the nonce. When allow_unauthorized_input_notes is true, none of this requires the owner's signature.An attacker can exploit this by crafting asset-free notes that the victim's account is able to consume, and then, for each note, proving a transaction in which the victim's account consumes it. Every such transaction is valid, changes no account state, and charges a fee to the victim's account, so repeated executions gradually deplete the victim's balance. The attack is bounded by an economic asymmetry, since the attacker bears the full proving cost of every transaction while the victim pays only the per-transaction fee. It nonetheless allows a determined attacker to drain a victim's balance without the victim's authorization.This vector is not unique to allow_unauthorized_input_notes. The root cause is that the consuming account is charged the transaction fee even for consumption it did not authorize, so any configuration that permits signature-free note activity is affected. The output note check with allow_unauthorized_output_notes enables the same fee-charging behavior, and permissionless authentication components such as NoAuth exhibit it as well. Any mitigation should therefore address the general case rather than this single flag.Consider requiring authorization, directly or indirectly, before an account consumes input notes, so that a third party cannot force fee-incurring consumption on the account. Because allow_unauthorized_input_notes and the related flags exist to support permissionless interactions such as deposits, consider preserving those use cases through an alternative that does not let an unauthorized party impose fees on the account, such as decoupling the fee obligation from an account that did not authorize the activity.Update: Partially Resolved in pull request #3065 at commit 4a71974 by flipping AuthSingleSigAcl semantics from trigger list to exempt list. However, the core underlying issues remain unaddressed. Because the protocol's fee mechanism is currently disabled, the threat of an account being drained for unauthorized note activity is merely masked rather than fixed. The new access control logic only mandates authentication for kernel-tracked account procedures; since consuming an asset-free input note bypasses this tracking, a keyless third party can still force a victim's account to consume notes without a signature.Furthermore, the update introduces a regression by entirely removing the allow_unauthorized_input_notes toggle. This change makes the signature-free consumption of asset-free notes unconditional for every AuthSingleSigAcl account, whereas it was previously an opt-in feature. The NoAuth implementation also retains this exact same vulnerability. Once automatic fees are reintroduced, this attack vector will return in full unless fee obligations are decoupled from unauthorized note activities. The Miden team opened a GitHub issue to follow up with it.Low SeverityAuthorization Guards Defined as call ABI but Used Only as Internal exec Building BlocksThe standards package documents procedures that form an account's external interface (reached by notes, scripts, or FPI across a context boundary, and re-exported under account_components/) as Invocation: call with [pad(16)] inputs and outputs, and procedures meant for in-context composition as Invocation: exec, conventionally suffixed _internal. The right invocation thus depends on a procedure's audience. In ownable2step the ownership-lifecycle procedures are external-only and correctly call-only, and the read accessors serve both audiences and correctly pair a call accessor with an _internal exec variant. The owner guard is the exception: asserting that the sender is the owner returns nothing useful across an isolated context, so it is meaningful only as an exec guard composed inside other owner-gated procedures, yet it is defined as a thin call wrapper over its _internal variant.Seven intra-package callers consequently invoke the call wrapper through exec: the owner-controlled burn and mint policies, the allowlist (allow, disallow) and blocklist (block, unblock) owner-controlled policies, and the OwnerControlled branch of assert_authorized. This has no functional or security impact, since MASM does not enforce invocation kind; it is a consistency matter. The sites contradict the procedure's documented call invocation and [pad(16)] signature, and diverge from the precedent where a call-documented procedure correctly execs the _internal variant. The wrapper is effectively dead: it is not re-exported by the ownable2step component, is never invoked via call anywhere, and the module's analogous predicate is already exec-only with no wrapper.An eighth site repeats the pattern with a twist. The RbacControlled branch of assert_authorized execs rbac's role guard, also documented call. Unlike ownable2step, the rbac component does re-export that guard as external ABI and provides no _internal variant. The two analogous guards are therefore treated inconsistently, one internal and unexposed, the other published as ABI, leaving open whether a bare authorization assertion belongs in a component's external interface at all.Consider treating the guards as internal exec procedures rather than call ABI. For the owner guard, collapse the two variants into a single exec procedure without the _internal suffix, which also resolves the seven call sites. For the role guard, settle its audience first: either keep it as ABI and add an _internal exec variant for assert_authorized to use, or make it exec-only and drop it from the rbac re-exports.Update: Resolved in pull request #3088 and pull request #3116.Missing Upper Bound Validation in set_max_supplyThe fungible faucet records its outstanding supply and its supply cap in the token config slot, and lets an authorized caller adjust the cap through set_max_supply. This stored cap is the authoritative limit on issuance: the transaction kernel keeps no persistent issuance counter for fungible faucets (it enforces only a per-transaction vault merge bound), so the component's token_supply and max_supply values are the sole supply ledger.The setter validates only that the new cap is not below the current token_supply. It does not check the new cap against FUNGIBLE_ASSET_MAX_AMOUNT (the protocol maximum representable amount, 2^63 - 2^31). An authorized owner can therefore store a max_supply larger than any asset the faucet can ever mint. The condition is not exploitable for over-minting because mint_and_send independently re-asserts that max_supply does not exceed FUNGIBLE_ASSET_MAX_AMOUNT before minting, and the asset constructor re-validates the amount, so any mint that would rely on the oversized cap reverts. The practical effect is an inconsistent stored configuration and a denial of service on minting until the cap is lowered again.Consider asserting that the new value does not exceed FUNGIBLE_ASSET_MAX_AMOUNT inside set_max_supply, so the stored cap stays consistent with the bound enforced at mint time and the getter never reports an unusable value.Update: Resolved in pull request #3118 at commit bfdf1da.Misleading Documentation in Faucet and Transfer Policy ProceduresThe faucet standard and its transfer policies contain several documentation inaccuracies across docstrings and inline stack annotations, which can mislead integrators and reviewers who rely on these comments to reason about the procedures. The instances are:Wrong hash function in the metadata setters. The doc comments for set_description, set_logo_uri, and set_external_link state that the caller passes the \"Poseidon hash\" of the new value, verified against the advice-map preimage during loading. The Miden VM currently uses Poseidon2, which is not output-compatible with Poseidon, so the named hash function is incorrect in all three procedures.Inconsistent new_ prefix after the mint policy runs. In mint_and_send, the stack comment following execute_mint_policy prefixes every item with new_, but the subsequent comments drop the prefix even though they refer to the same values. The prefix signals that the policy may have modified the values, so dropping it inconsistently obscures that distinction.Missing custom_data element in the transfer policy inputs. The Inputs documentation of the transfer policy check_policy procedures omits the custom_data element that the kernel places on the stack after the asset key and value. basic_allowlist and basic_blocklist document [ASSET_KEY, ASSET_VALUE, pad(8)], and allow_all documents [ASSET_KEY, ASSET_VALUE] (missing the padding elements), but per the callback signature the element following ASSET_VALUE is custom_data, set to 0 for the account callback and to note_idx for the note callback.Incorrect residual stack depth after the final operation. The inline comment after the final operation reports a residual stack below 16 elements in several call-invoked procedures: [pad(14)] in block_account and unblock_account of the blocklist transfer policy, in allow_account and disallow_account of the allowlist transfer policy, and in transfer_ownership of the ownable2step module (which under-counts the same way at an intermediate step). These procedures are call-invoked, so the VM enforces a minimum stack depth of 16 and backfills the consumed elements with zeros on return, leaving [pad(16)] as the documented Outputs already state. The comments should read [pad(16)], as stated by the masm-padding convention.Incorrect claim that Pausable is an optional dependency. The doc comment on assert_not_paused states that when the pause slot is not installed, active_account::get_item returns the zero word and the assertion becomes a no-op, presenting Pausable as a dependency consumers can gate on \"without making Pausable a hard dependency\". This is incorrect: get_item resolves the slot through the kernel, which panics with an unknown-storage-slot error when the slot is absent. The behavior fails closed and grants no authorization bypass, but the comment contradicts the correct notes in the policy manager and the allow-all transfer policy, and a developer who follows it would deploy a non-functional faucet.Undocumented Ownable2Step dependency in the owner-only mint and burn policies. The owner-only mint and burn policies gate on the account owner by reading the Ownable2Step owner slot, yet neither their MASM modules nor their Rust components document that they require the Ownable2Step component. The sibling transfer policies do: the owner_controlled MASM modules and Rust components open with a \"Companion components required\" note naming Ownable2Step, while the mint and burn owner_only files only mention the owner \"as recorded by the Ownable2Step component\" in passing. Because nothing installs or validates the slot, a faucet assembled without Ownable2Step builds successfully and then reverts on every mint or burn.Consider correcting each comment to match actual behavior: name Poseidon2 as the hash function in the three metadata setters, keep a consistent prefix for the post-policy stack items in mint_and_send, include custom_data in the documented inputs of the transfer policies, update the residual stack comments in the owner-controlled transfer policies and transfer_ownership to [pad(16)], and state in the assert_not_paused docstring that Pausable is a hard dependency. Additionally, document the Ownable2Step dependency required by the owner-only mint and burn policies (ideally contributing it as a companion component so it cannot be silently omitted) as the transfer owner-controlled policies already do.Update: Resolved in pull request #3119 at commit b145d26 and pull request #3047 at commit 070b598.Authority Component Prevents Per-Operation Role Differentiation in RBAC ModeThe Authority component provides a unified access control gate used by all authority-protected procedures across the standard library, including pause, unpause, set_mint_policy, set_burn_policy, set_send_policy, set_receive_policy, set_max_supply, and the metadata setters. Each calls assert_authorized, which reads a single AUTHORITY_SLOT word to determine both the authority mode and, in RBAC_CONTROLLED mode, the role to enforce.Because all authority-gated procedures share the same slot, and the RbacControlled { role } integration exposes only a single RoleSymbol even though RoleBasedAccessControl itself supports many roles, RBAC_CONTROLLED mode enforces the same role for every operation on the account. An account that installs both PausableManager and PolicyManager with Authority::RbacControlled { role } cannot assign a PAUSER_ROLE separately from a POLICY_ADMIN_ROLE: any account holding the configured role can exercise all authority-gated operations simultaneously. This collapses the fine-grained access control that RBAC is designed to provide into a single-role gate, offering no practical benefit over Authority::OwnerControlled for multi-subsystem accounts. The RBAC naming may further lead integrators to expect per-procedure granularity that this path does not provide. Developers who need per-operation role differentiation must bypass assert_authorized entirely and call rbac::assert_sender_has_role directly with hardcoded role constants in each procedure, abandoning the standard component authority abstraction.The risk is amplified because the authority role is an ordinary RoleSymbol. If it aliases a role the account also uses for application-level logic, granting that role unintentionally confers control over every protected setter.Consider either redesigning the authority slot to support per-operation or per-subsystem role configuration (for example, allowing each component that uses assert_authorized to supply its own role symbol rather than reading from a shared account-wide slot), or, if the single-role design is intentional, documenting at the RbacControlled definition that one role gates the entire authority-protected surface.Update: Resolved in pull request #3072 at commit 2f63c43, 36b480e and at commit 71c8fd3.Sender-Based Access Control Can Be Bypassed When the Privileged Sender Is a Permissionless AccountIn Miden, the sender of a note is the account ID of the account that created it, set unconditionally by the kernel's build_metadata procedure, which derives the sender from account::get_id on the native account. The ownable2step and rbac components gate privileged procedures on the active note's sender, read via active_note::get_sender, asserting it matches a registered owner or role member. This check authenticates which account created the note, but not the code that executed when the note was created.Note creation is not restricted to account procedures. The kernel procedure output_note_create is guarded only by assert_native_account and does not call authenticate_account_origin. The storage mutators account_set_item and account_set_map_item, by contrast, require both guards, where authenticate_account_origin asserts that the caller is an account procedure. As a result, a bare transaction script that invokes none of the account's procedures can create output notes whose sender is the native account ID. Such a script cannot write storage and cannot move value, since vault operations are gated and the epilogue enforces asset conservation, but it can freely choose the new note's script root and recipient.The no_auth component performs no key verification and never reverts; it only increments the nonce when the account state changed or the account is new. Any party can therefore run a transaction against a no_auth account A with a transaction script that emits a note carrying A as sender and an arbitrary script root. When a contract B restricts privileged procedures to notes sent by A, an attacker mints such a note and consumes it against B, which is also permissionless, defeating B's access control. The note's script executes with the trust B grants to A.Transaction validity does not prevent this. The epilogue rejects only fully empty transactions, aborting with ERR_EPILOGUE_EXECUTED_TRANSACTION_IS_EMPTY when the account delta is empty and no input notes were consumed. Creating an output note does not affect the account delta, but two paths are always available: against a new account whose nonce is zero, no_auth increments the nonce and produces a non-empty delta; against an existing account, the attacker has A consume an asset-less input note minted from another account they control, making the input-notes commitment non-empty. Either path yields a valid transaction that emits the forged-sender note.Consider documenting that sender-based access control in ownable2step and rbac is meaningful only when every registered owner or role member account enforces strong authentication, and that registering a permissionless account as owner or role member provides no access restriction.Update: Resolved in pull request #3205 at commit 1be12ae.Note Script Allowlist Authentication Reads Live Storage Instead of Initial Transaction StateThe note script allowlist primitives in note_script_allowlist.masm are documented as reusable building blocks intended to back multiple authentication components, each with its own allowlist storage map. The assert_all_input_notes_allowed procedure validates each consumed input note's script root against the allowlist map using active_account::get_map_item, which reads the live storage state. Every other authentication component instead reads its authorization data from the initial transaction state via get_initial_map_item. The signature.masm component documents the rationale: the previous authority must authorize a change to the new authority, rather than the new authority authorizing itself.Because the authentication procedure executes in the epilogue, after all input note scripts have run, any storage write performed earlier in the same transaction is already reflected in the live read. The kernel does not scope storage writes to the component that declared a slot: set_map_item resolves the target slot solely by its global slot identifier and only asserts that the slot exists, is a map, and that the call originates from the native account. Any procedure in an account's code can therefore write any storage slot present in the account, including a slot declared by another component.The shipped AuthNetworkAccount component is not affected, because its allowlist is fixed at creation and it ships no mutator. However, the primitive is unsafe by default for the reuse it advertises. An integrator that pairs this check with a procedure able to write the allowlist slot, whether in a custom component or alongside AuthNetworkAccount, whose immutability is not enforced by the kernel, enables a single transaction to add a note script root to the allowlist and consume a note carrying that root in the same transaction. The live read observes the just-added entry and the note is accepted, even though the root was not present in the allowlist at the start of the transaction. This is the self-authorizing transition that the initial-state read prevents elsewhere.Consider reading the allowlist via get_initial_map_item so that the check reflects the pre-transaction allowlist and same-transaction updates cannot authorize the notes they enable. Consider also documenting in the procedure header that this check must not be paired with an allowlist that is mutable within the same transaction.Update: Resolved in pull request #3182 at commit eac470c and at commit 17a8773.Untrusted Scripts Can Force the Transaction Host to Sign Outside the Authentication BoundaryDuring transaction execution, the kernel runs input note scripts and the transaction script via dyncall before the epilogue authentication procedure executes. These scripts run in a non-root context and are untrusted, since input notes may be authored by an adversary and consumed by any account. Signature production is driven by the AuthRequest event: the standard authentication procedure emits it to obtain a signature for the transaction summary from the host's authenticator. Because TransactionEventId::is_privileged treats AuthRequest as unprivileged, note and transaction scripts can emit it as well.The host's AuthRequest handler honors the event unconditionally, with no check on the execution phase or context. It invokes on_auth_requested, which asks the authenticator to sign and pushes the resulting signature onto the advice stack, where the currently executing script can read it. The reference get_signature signs without any user interaction. Consequently, an untrusted note consumed by a victim can repeatedly force the victim's executor to produce signatures under the victim's key, with no per-transaction limit and outside the intended epilogue authentication phase.The practical impact is contained by invariants elsewhere. The signed message is constrained to a TransactionSummary commitment over the transaction's actual account delta and notes, with only the salt under script control, so this is not arbitrary-message signing. Any signature obtained during script execution commits to an account delta with a nonce increment of zero, because the nonce can only be incremented from the authentication procedure; the only way for a script to reach a nonce increment is to invoke the authentication procedure itself, which marks it as called and causes the epilogue to abort the transaction with ERR_EPILOGUE_AUTH_PROCEDURE_CALLED_FROM_WRONG_CONTEXT. The signature-verifying authentication components all compute their message after incrementing the nonce, so a signature produced through this path is never accepted by them. The residual concerns are therefore the absence of any bound on forced signature gen","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791258328704,"hash":"920e658180caefead9b4966c1f85356408ce3f11"}
{"url":"https://aave.com/docs/aave-v4/tools/swaps","domain":"aave.com","title":"Aave Swap Features | Aave Protocol Documentation","text":"Swap Features#\nLearn how to perform and monitor swap operations with AaveKit.\n\nAlongside the Position Swaps feature, AaveKit provides the following tools for swapping:\nSwap Tokens: exchange tokens instantly at market price or set conditions with a limit order.Monitor Swap Status: track the status of a swap.User Swaps: list and filter user swaps.Cancel a Swap: cancel a swap in progress.\nSwaps are implemented using a modular provider architecture. Currently, CoW Protocol is the swap provider, offering MEV protection and optimal execution through batch auctions.\nReview the fees section to understand the swap costs.\nSwap Tokens#\nToken swaps can be executed in two ways:\nIntent-based: The swap is signed off-chain and submitted as an intent, which is then executed by a solver. This is the preferred method as it is gasless for users.Transaction-based: The swap is executed directly on-chain via a transaction. This method is used when intent-based execution is not available.\nNative token swaps are always transaction-based since users must send funds\ndirectly.\nSwapping tokens involves the following steps:\nSelect the token to swap fromSelect the token to swap toChoose between market order and limit orderExecute the swap operation\nSource Token#\nFetch user token balances that can be swapped. This allows you to display only tokens the user owns that are swappable, making source token selection easier.\nReactTypeScriptGraphQLUse the useUserBalances hook with the swappable filter to list user tokens that can be swapped.import type { UserBalancesRequest, TokenAmount } from \"@aave/react\";import { useUserBalances } from \"@aave/react\";\nfunction SwapFromToken({ request, onSelect,}: { request: UserBalancesRequest; onSelect: (amount: TokenAmount) => void;}) { const { data, loading, error } = useUserBalances(request);\n return ( <select disabled={loading || error} onChange={(e) => { const balance = data.find((b) => b.id === e.target.value); if (balance) onSelect(balance.balances[0]); }} > {data.map((balance) => ( <option key={balance.id} value={balance.id}> {balance.info.symbol} ({balance.totalAmount.value.toDisplayString(2)}) </option> ))} </select> );}You can query for swappable token balances as follows:import { evmAddress, chainId, OrderDirection } from \"@aave/react\";\nconst request: UserBalancesRequest = { user: evmAddress(\"0x456…\"), filter: { swappable: { chainIds: [chainId(1)], }, }, orderBy: { balance: OrderDirection.Desc },};\nFor more details on filtering and sorting user balances, see the User\nBalances documentation.\nDestination Token#\nOnce you've selected a source token, fetch the tokens you can swap TO. This ensures you only display valid swap destinations for the selected source token.\nReactTypeScriptGraphQLUse useSwappableTokens to list destination tokens based on your selected source token.import type { SwappableTokensRequest, Token } from \"@aave/react\";import { useSwappableTokens } from \"@aave/react\";\nfunction SwapToToken({ request, onSelect,}: { request: SwappableTokensRequest; onSelect: (token: Token) => void;}) { const { data, loading, error } = useSwappableTokens(request);\n return ( <> <select disabled={loading} onChange={(e) => { const token = data.find((t) => t.info.address === e.target.value); if (token) onSelect(token); }} > {data.map((token) => ( <option key={token.info.address} value={token.info.address}> {token.info.symbol} ({token.info.name}) </option> ))} </select> {error && <p>{error.message}</p>} </> );}You can query for a list of swappable tokens as follows:const request: SwappableTokensRequest = { query: { chainIds: [chainId(1)], },};\nMarket or Limit Order#\nOnce you've identified the tokens to swap, the next step is choosing an order type. Market orders execute immediately at the current rate, while limit orders wait until your specified price conditions are met.\nMarketLimitTo place a market order, specify the token pair, amount, and swap direction.const request: TokenSwapQuoteRequest = { market: { chainId: chainId(1), buy: { erc20: evmAddress(\"0xA0b86a33E6…\") }, sell: { erc20: evmAddress(\"0x6B175474E…\") }, amount: bigDecimal(\"1000\"), kind: TokenSwapKind.Buy, user: evmAddress(\"0x742d35cc…\"), // Your address receiver: evmAddress(\"0x742d35cc…\"), // In case the receiver is different from the user selectedSlippage: bigDecimal(\"2\"), // 2% },};The request takes the following parameters:chainId — The target chainsell — The token to sell (native or erc20)buy — The token to receive (native or erc20)amount — The swap amount, interpreted based on kindkind — Sell (default) or Buy, determines how amount is interpreteduser — The sender addressreceiver — The recipient address (defaults to user)selectedSlippage — Optional slippage tolerance to use instead of the suggested slippageSince only one amount is provided, the swap kind determines what gets calculated:Swap KindUser inputs…System calculates…SellHow much of the token to sell and which token to buyThe amount of the buy token you'll receiveBuyHow much of the token to buy and which token to sellThe amount of the sell token you need to provideDepending on the token pair, swaps can be performed in different ways:const request: TokenSwapQuoteRequest = { market: { chainId: chainId(1), buy: { erc20: evmAddress(\"0xA0b86a33E6…\") }, sell: { erc20: evmAddress(\"0x6B175474E…\") }, amount: bigDecimal(\"1000\"), user: evmAddress(\"0x742d35cc…\"), // Your address },};\nExecute Swaps#\nReactTypeScriptGraphQLTo execute the swap operation with AaveKit React, follow these steps.1Get Swap Quote#First, use the useTokenSwapQuote hook (or the imperative useTokenSwapQuoteAction variant) to get a swap quote.import { type TokenSwapQuoteRequest, useTokenSwapQuote } from \"@aave/react\";\nfunction DisplayQuote({ request }: { request: TokenSwapQuoteRequest }) { const { data, loading, error } = useTokenSwapQuote(request);\n if (loading) return <p>Loading…</p>;\n if (error) { if (error.name === \"ValidationError\") { switch (error.cause.__typename) { case \"InsufficientLiquidityError\": return <p>Not enough liquidity for this swap</p>; } } return <p>{error.message}</p>; }\n return ( <div> <h3>Swap Quote</h3> <h4>{data.quoteId}</h4> <p>Suggested slippage: {data.suggestedSlippage}</p> <p>Costs: {data.costs}</p> </div> );}The useTokenSwapQuoteAction hook does not watch for updates. Use it when\nyou need on-demand, fresh data (e.g., in an event handler).You can specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = useTokenSwapQuote({ ...request, currency: Currency.Eur,});The SwapQuote object provides detailed pricing information for swap operations.\ninterface SwapQuote { __typename: \"SwapQuote\"; accuracy: QuoteAccuracy; quoteId: SwapId; suggestedSlippage: PercentNumber; selectedSlippage: PercentNumber | null; buy: TokenAmount; sell: TokenAmount; finalBuy: TokenAmount; finalSell: TokenAmount; costs: SwapQuoteCosts;}\nWhere:\naccuracy — quote accuracy level (QuoteAccuracy.Fast or QuoteAccuracy.Accurate)quoteId — a unique quote identifier required for executing the swapbuy and sell — current prices before feesfinalBuy and finalSell — amounts you'll receive/pay after fees and slippagecosts — a breakdown of all fees (partner fee, provider fee, flash loan fee, network costs)suggestedSlippage — recommended slippage toleranceselectedSlippage — the slippage tolerance selected when requesting a market quote (if provided)For limit orders, consider fetching a market quote first to get current buy\nand sell values. Use these as a baseline to repeat the swap quote with a\nlimit order request.2Configure Wallet Integration#Then, instantiate the hooks for the wallet library of your choice:useSendTransaction — used to send ERC-20 approval and swap transactions when neededuseSignTypedData — used to sign ERC-20 permits and swap order typed dataimport { useWalletClient } from \"wagmi\";import { useSendTransaction, useSignTypedData } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);const [signTypedData] = useSignTypedData(wallet);3Define the Swap Flow#Then, use the useTokenSwap hook to handle the operation.import { useTokenSwap } from \"@aave/react\";\n// …\nconst [swap, { loading, error }] = useTokenSwap((plan) => { switch (plan.__typename) { case \"Erc20Approval\": if (plan.bySignature) { return signTypedData(plan.bySignature); } return sendTransaction(plan.byTransaction);\n case \"SwapTransactionRequest\": return sendTransaction(plan.transaction);\n case \"SwapTypedData\": return signTypedData(plan); }});4Execute the Swap Operation#Then, execute the swap. The approach differs based on order type: market orders execute immediately at current prices, while limit orders let you set specific price conditions.Market OrderLimit OrderFor market orders, call swap with the quoteId from the last market order quote.const execute = async (quote: SwapQuote) => { const result = await swap({ fromQuote: { quoteId: quote.quoteId, }, });\n if (result.isErr()) { console.error(result.error); return; }\n // result.value: SwapReceipt console.log(\"Swap order placed:\", result.value);};5Handle the Result#Finally, handle the result.if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error(`Failed to sign: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"ValidationError\": switch (result.error.cause.__typename) { case \"InsufficientBalanceError\": console.error( `Insufficient balance: ${result.error.cause.required.value.toDisplayString(2)} required.`, ); break; case \"InsufficientLiquidityError\": console.error(`Insufficient liquidity: ${result.error.cause.reason}`); break; } break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return;}// result.value: SwapReceiptconsole.log(\"Swap order placed:\", result.value);That's it—you placed your first swap order. Keep track of its status in the Monitor Swap Status section.\nMonitor Swap Status#\nOnce the swap is executed, a SwapReceipt object is returned with an id field. Use this id to track the swap status.\nFor more details, see the Execute Swaps section.\nReactTypeScriptGraphQLUse the useSwapStatus hook to monitor the status of a swap in real-time.import { useSwapStatus } from \"@aave/react\";\nfunction MonitorSwap({ swapReceipt }: { swapReceipt: SwapReceipt }) { const { data, loading, error } = useSwapStatus({ id: swapReceipt.id, });\n if (loading) return <p>Monitoring swap…</p>;\n if (error) return <p>Error: {error.message}</p>;\n switch (data.__typename) { case \"SwapOpen\": return <p>Swap is open, waiting for execution…</p>;\n case \"SwapPendingSignature\": return <p>Waiting for signature…</p>;\n case \"SwapFulfilled\": return ( <div> <p>Swap completed successfully!</p> <a href={data.explorerUrl}>View transaction</a> </div> );\n case \"SwapCancelled\": return <p>Swap was cancelled at {data.cancelledAt}</p>;\n case \"SwapExpired\": return <p>Swap expired at {data.expiredAt}</p>; }}The hook automatically polls for status updates until the swap reaches a terminal state: fulfilled, cancelled, or expired.\nUser Swaps#\nList and filter user swaps with built-in pagination support.\nReactTypeScriptGraphQLUse the useUserSwaps hook to list user swaps.import { useUserSwaps, evmAddress, chainId } from \"@aave/react\";\nfunction ListUserSwaps({ request }: { request: UserSwapsRequest }) { const { data, loading, error } = useUserSwaps(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n // data.items: Array<SwapStatus> return ( <div> <h3>User Swaps</h3> {data.items.map((swapStatus) => ( <div key={swapStatus.createdAt}> <p> Status - {swapStatus.__typename} - {swapStatus.explorerUrl} </p> </div> ))} </div> );}The hook automatically polls for status updates until all listed swaps reach a terminal state: fulfilled, cancelled, or expired.You can filter swaps as follows:import { evmAddress, chainId } from \"@aave/react\";\nconst request: UserSwapsRequest = { user: evmAddress(\"0x742d35cc…\"), chainId: chainId(1),};\nCancel a Swap#\nBefore cancelling, identify the swap by its status.\nOnly swaps with status Open can be cancelled.\nconst swapsItems: SwapStatus[] = [ { __typename: \"SwapOpen\", swapId: \"adb123…\", // … }, { __typename: \"SwapPendingSignature\", // … }, { __typename: \"SwapCancelled\", // … }, { __typename: \"SwapExpired\", // … }, { __typename: \"SwapFulfilled\", // … },];\nAfter identifying the swap, follow the steps below to cancel it with AaveKit.\nReactTypeScriptGraphQLTo cancel a swap with AaveKit React:1Configure Wallet Integration#First, instantiate the useSendTransaction and useSignTypedData hooks for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction, useSignTypedData } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);const [signTypedData, signing] = useSignTypedData(wallet);2Define the Cancel Flow#Then, use the useCancelSwap hook to prepare the cancel swap operation.import { useCancelSwap } from \"@aave/react\";\nconst [cancelSwap, { loading, error }] = useCancelSwap( (plan: CancelSwapTypedData | TransactionRequest) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"CancelSwapTypedData\": return signTypedData(plan); } },);3Execute the Cancel Swap Operation#Then, execute the cancel swap operation.const execute = async () => { const result = await cancelSwap({ id: swapReceipt.id, });};4Handle the Result#Finally, handle the result.if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error(`Failed to sign the transaction: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return;}\n// result.value: SwapCancelledResultconsole.log(\"Swap cancelled:\", result.value.cancelledAt);That's it—you cancelled your first swap. Keep track of its status in the Monitor Swap Status section.\nFees#\nSwaps include a network fee, partner fee, provider fee, and in the case of Position Swaps a flash loan fee.\nNetwork Fee#\nThe network fee covers gas costs for executing the swap transaction on-chain. This fee varies based on current network congestion and is paid in the chain's native token (e.g., ETH on Ethereum).\nPartner Fee#\nAave Labs applies a fee to swaps done through the Aave Labs API. The fee depends on the swap operation and token pair:\nBorrow Swap: 0% fee across all pairs.All other swap operations: a discounted fee of 0.15% is applied to swaps between correlated assets (e.g., ETH/wstETH), while 0.25% is applied to all other pairs.\nCorrelated assets are tokens that maintain a stable price relationship,\ntypically pegged to the same underlying asset or index. Swaps between\ncorrelated assets receive a discounted fee because they carry lower price\nrisk.\nThe following asset groups are considered correlated (list reviewed and updated periodically):\nStablecoins: USDC, USDT, DAI, GHO, EURC, USDbC, USDe, USDS, sUSDe, RLUSD, PYUSD, LUSD, sDAI, crvUSD, USD₮0, USDC.e, EURe, xDAI, wxDAIETH correlated: weETH, ETH, WETH, wstETH, cbETH, ezETH, wrsETH, osETH, rETH, ETHxBTC correlated: cbBTC, WBTC, LBTC, tBTC, eBTC\nProvider Fee#\nCoW Protocol charges a fee for swap execution: 0.02% for most pairs, reduced to 0.003% for tokens in their Reduced Fee Tokens list (a dynamic registry of major stablecoins and RWAs based on price volatility). The fee is included in the swap quote.\nFlash Loan Fee#\nSome of the Position Swaps require flash loans to execute atomically. When applicable, a flash loan fee of 0.05% of the flash-loaned amount is charged. This fee is collected by the protocol treasury and controlled by the DAO through governance.\nFlash loan fees apply to operations that require borrowing assets temporarily (e.g., Swap Borrow Asset). Operations that use existing positions (e.g., Withdraw and Swap) typically do not incur flash loan fees.PreviousExchange RatesNextReference","tokens":4114,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258338396,"hash":"ee8654a8cc0ecf3257049aac0d3388ed9a8af03c"}
{"url":"https://www.openzeppelin.com/news/openzeppelin-and-pacific-meta-partner-to-bring-institutional-grade-onchain-security-to-japan","domain":"openzeppelin.com","title":"OpenZeppelin and Pacific Meta Partner to Bring Institutional-Grade Onchain Security to Japan","text":"August 26, 2026OpenZeppelinJapanese enterprises and financial institutions gain access to continuous security across the full development lifecycle, from architecture through productionTOKYO, Aug. 26, 2026 — OpenZeppelin, the security standard for onchain finance behind more than $35 trillion in value transferred and trusted by global financial institutions including DTCC, Fidelity Digital Assets, and WisdomTree, and Pacific Meta, a blockchain consultancy supporting more than 300 enterprises and government organizations’ projects, today announced a strategic partnership to bring institutional-grade onchain security to the Japanese market.Japan has become one of the most structured markets for institutional onchain finance, with a clear regulatory framework for stablecoins and growing momentum behind tokenized assets among the country's largest financial groups. As Japanese enterprises move from pilots to production systems that manage real value, security has become the deciding factor between projects that launch and projects that stall.The partnership addresses that gap directly. Japanese organizations working with Pacific Meta gain access to OpenZeppelin's complete security lifecycle: architecture and threat modeling before a line of code is written, development from the team behind the industry-standard OpenZeppelin Contracts libraries, in-depth security reviews before launch, and continuous support once systems are live, giving institutions the ongoing assurance their risk and compliance teams require. Pacific Meta complements this with local strategy, regulatory context, and Japanese-language support, so institutions can move onchain with a single, coherent path from concept to production.\"Japanese institutions are moving onchain with a level of regulatory clarity most markets are still working toward. What they need now is security that spans the entire lifecycle: sound architecture, proven foundations, rigorous review, and continuous protection in production. Partnering with Pacific Meta lets us deliver exactly that, with the local depth the Japanese market requires,” said Jonathan Alexander, CTO at OpenZeppelin.\"OpenZeppelin is a global security standard for onchain finance. As Japanese enterprises move from exploration to production-grade blockchain adoption, access to world-class security review and operational support becomes essential. Through this collaboration, Pacific Meta will help Japanese institutions adopt blockchain technology in a safer, more practical, and globally aligned way,\" said Andy Hung, Head of Alliance at Pacific Meta.Together, the two companies will support Japanese enterprises and financial institutions across tokenization, stablecoin, and digital asset initiatives, combining OpenZeppelin's decade of security standards with Pacific Meta's position in Japan's institutional blockchain ecosystem.About OpenZeppelinOpenZeppelin is the security standard for onchain finance. Since 2015, the company has set the bar for smart contract security through the industry-standard OpenZeppelin Contracts library, behind $35 trillion in value transferred, and 900+ security engagements that have surfaced 10,000+ vulnerabilities before production. OpenZeppelin secures leading blockchain networks, DeFi protocols, institutions, and enterprises globally, including DTCC, WisdomTree, Fidelity Digital Assets, Aave, Stellar, the Ethereum Foundation, and more.About Pacific MetaPacific Meta is a blockchain consultancy on a mission to create the blockchain standard from Japan. The company has supported more than 300 enterprises and government organizations’ projects across Japan and internationally, spanning comprehensive blockchain consulting, market entry for global blockchain projects, and onchain asset management. Pacific Meta co-hosted the Japan Stablecoin Summit 2025 and co-produced the Blockchain Summit 2026 with Credit Saison, an official partner event of the Financial Services Agency's Japan Fintech Week.","tokens":998,"squid":"ink-security_audits","role":"Sentinel","at":1791258338567,"hash":"0aaf351c89f85f3ef7c3d3df2f6352f8d4c7c8d5"}
{"url":"https://gov.optimism.io/t/axia-network-delegate-communications-thread/10547/1","domain":"gov.optimism.io","title":"Axia Network — Delegate Communications Thread - Communications 📣 / Delegate Updates - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Axia Network — Delegate Communications Thread \n\n Communications 📣Delegate Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 12\n\n 1 / 3\n\n Jan 12\n\n Jun 1\n\n post by Axia on Jan 12\n\n Axia\n\n Axia Network is a delegate across DAOs in the EVM ecosystem. Axia is committed to growing alongside the ecosystem and contributing responsibly to each protocol’s long-term success.\nAxia’s values emphasize supporting protocols through sustainable long-term growth, education, and strong oversight, while preserving decentralization by creating and sustaining pathways for community participation and meaningful checks and balances that ensure accountability and transparency across governance stakeholders.\nFollow Axia on X: https://x.com/AxiaNetwork0x\n\n 15 days later\n\n post by Axia on Jan 27\n\n Axia\n\n Proposal to Align OP Token with Superchain Success\nProposal: Link\nVote: For\nRationale: Voted FOR this proposal to implement a buyback program to align the OP token to the Superchain’s success. The fundamental premise of this proposal: linking blockspace consumption across the Superchain to demand for OP —creates a sustainable tokenomics model. That said, Axia will be closely monitoring this 12 month program and expects a comprehensive dashboard that includes value alignment metrics. Specifically, these metrics should demonstrate the relationship between the OP token price and Superchain revenue. For more details on these metrics, please refer to this forum comment.\nFurthermore, at the end of the 12-month program, the Foundation should provide an analysis that shows total OP acquired relative to market condition, impact on token supply dynamics and holder value, and community sentiment and delegate feedback.\nAxia is looking forward to the buyback starting in February and tracking these metrics throughout the 12-month pilot.\nSeason 9 Governance Fund Mission: Grants Council\nProposal: Link\nVote: For\nRationale: Axia supports this proposal. As this vote is optimistically approved, a For vote is not required. Axia endorse the proposed success metrics targeting DEX TVL for collateral-borrow pairs that exist on lending markets and trading volume per TVL. These metrics are strong indicators for a healthy ecosystem. Furthermore, the budget reduction from 6.29M OP in Season 8 to 3.89M OP in Season 9 demonstrates responsible stewardship as Optimism matures.\nSeason 9 Governance Fund Mission: Developer Advisory Board\nProposal: Link\nVote: For\nRationale: Axia supports this proposal. As this vote is optimistically approved, a For vote is not required. Funding grants for audits and technical developer tooling is important to drive developer growth. Furthermore, tying DAB grants to the same success metrics as the Grants Council (DEX TVL for collateral-borrow pairs and trading volume per TVL) creates cohesion in the ecosystem.\nDAO Operating Budget Midpoint Adjustment\nProposal: Link\nVote: For\nRationale: Voted FOR this 2.3M OP budget adjustment proposal. When the original budget was approved in July 2025, L2Beat raised a concern about the lack of a buffer to protect council compensation in the event of OP price volatility. The Foundation explicitly responded that a midpoint adjustment would address this:\n\nThis adjustment fulfills that commitment and ensures council members are compensated fairly despite market fluctuations.\n\n 4 months later\n\n post by Axia on Jun 1\n\n Axia\n\n Security Council Elections Cohort B Members\nProposal: Link\nVote: Alex Soto\nRationale: Voted for Alex Soto given his deep OP governance expertise, strong alignment with the Optimism ecosystem, and demonstrated history of thoughtful protocol governance participation.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Formally Announcing Axia Network\n\n Delegate Updates\n\n season-9\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole…\n\n read more\n\n 0\n\n 51\n\n Jan 13\n\n Proposal to Align the OP Token with Superchain Success\n\n Proposals 📃\n\n season-9\n\n Proposal to Align OP Token with Superchain Success\nThis proposal was updated on 1/15/26 to reflect community feedback to split the original proposal into two separate proposals. \nExecutive Summary\n\nThis proposal would im…\n\n read more\n\n 36\n\n 4.3k\n\n 1d\n\n CosmicKi - Delegate Communication Thread\n\n Delegate Updates\n\n Hi everyone! \nIt is a pleasure for me to kick off this communication thread as a Delegate in the Governance of Optimism. I’m excited to be part of the collective and contribute to the development of meaningful decisions. …\n\n read more\n\n 5\n\n 960\n\n Jan 2025\n\n Season 8 Intent AMA Questions Thread\n\n Intents\n\n season-8\n\n We will be hosting an AMA with leadership from the Optimism Foundation and OP Labs (Jing and Bobby) on Tuesday the 24th at 6:30pm GMT to answer any questions about the Season 8 Intent. \nPlease comment any questions you h…\n\n read more\n\n 11\n\n 702\n\n Jul 2025\n\n Accelerated Decentralization Proposal For Optimism\n\n ✨ General\n\n Authors: @GFXlabs \nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary) \nIf you hold OP, please signal your approval of this accelerated decentralization on this Snap…\n\n read more\n\n 36\n\n 3.6k\n\n Aug 25","tokens":1374,"squid":"ink-governance","role":"Council Listener","at":1791258340002,"hash":"052d399600f8b58524b60d8254826a360c2704ec"}
{"url":"https://aave.com/docs/aave-v4/liquidity/incentives","domain":"aave.com","title":"Aave v4 Incentive Programs | Aave Protocol Documentation","text":"Incentive Programs#\nLearn how to discover and claim incentive rewards on Aave v4.\n\nAave v4 reserves may offer additional incentives beyond base lending rates. These incentives are distributed through Merkl, a decentralized incentive distribution platform, or through Points programs that reward users with points multipliers.\nReward Types#\nPotential rewards are available in the rewards array of the Reserve Summary.\ninterface Reserve { // … summary: { rewards: Reward[]; // … };}\ntype Reward = | MerklSupplyReward | MerklBorrowReward | SupplyPointsReward | BorrowPointsReward;\nSupply Rewards#\nSupply rewards can be present on suppliable reserves.\nMerkl Supply Rewards#\nMerkl supply rewards represent an extra APY on top of the base reserve supply APY. The accrued extra interest is paid in the specified payout token when the incentive campaign reaches its maturity.\ninterface MerklSupplyReward { __typename: \"MerklSupplyReward\"; id: string; startDate: Date; endDate: Date; extraApy: PercentNumber; payoutToken: Erc20Token; criteria: MerklCriteria[]; userEligible: boolean;}\nWhere:\nextraApy - The additional APY earned on top of the base supply APYpayoutToken - The token used to pay the extra interest accrued from the rewardcriteria - Eligibility requirements for earning the reward\nPoints Supply Rewards#\nSome reserves participate in Points programs. Users who supply into these reserves accrue points over time proportional to their position size.\ninterface SupplyPointsReward { __typename: \"SupplyPointsReward\"; id: string; program: PointsProgram; name: string; startDate: Date; endDate: Date | null; multiplier: number; criteria: PointsCriteria[]; userEligible: boolean;}\nWhere:\nprogram - The Points program issuing the rewardmultiplier - Boost factor on the base points accrual ratecriteria - Eligibility requirements for earning the reward\nBorrow Rewards#\nBorrow rewards can be present on borrowable reserves.\nMerkl Borrow Rewards#\nMerkl borrow rewards represent an APY discount on the user's borrow rate (which includes their Risk Premium). The accrued interest discount is paid in the specified payout token when the incentive campaign reaches its maturity.\ninterface MerklBorrowReward { __typename: \"MerklBorrowReward\"; id: string; startDate: Date; endDate: Date; discountApy: PercentNumber; payoutToken: Erc20Token; criteria: MerklCriteria[]; userEligible: boolean;}\nWhere:\ndiscountApy - The APY discount applied to the user's borrow ratepayoutToken - The token used to pay the rewardcriteria - Eligibility requirements for earning the reward\nPoints Borrow Rewards#\nSimilarly, borrowing from certain reserves can accrue points in a Points program.\ninterface BorrowPointsReward { __typename: \"BorrowPointsReward\"; id: string; program: PointsProgram; name: string; startDate: Date; endDate: Date | null; multiplier: number; criteria: PointsCriteria[]; userEligible: boolean;}\nWhere:\nprogram - The Points program issuing the rewardmultiplier - Boost factor on the base points accrual ratecriteria - Eligibility requirements for earning the reward\nPoints Program#\nA PointsProgram represents a loyalty or incentive system. Users accumulate points over time based on their supply or borrow position. The externalUrl links to the program's website where users can view their accumulated points.\ninterface PointsProgram { __typename: \"PointsProgram\"; id: string; name: string; externalUrl: string | null; iconUrl: string | null;}\nEligibility Criteria#\nEach reward may have eligibility criteria that users must meet. Both Merkl and Points criteria share the same shape (id, text, userPassed) but use distinct GraphQL types.\n// Merkl rewards use MerklCriteriainterface MerklCriteria { __typename: \"MerklGenericCriteria\"; id: string; text: string; userPassed: boolean;}\n// Points rewards use PointsCriteriainterface PointsCriteria { __typename: \"PointsGenericCriteria\"; id: string; text: string; userPassed: boolean;}\nMatured Rewards#\nRewards become claimable when their incentive campaign reaches maturity. Campaigns are often renewed upon reaching their end date, so users should check for new reward opportunities periodically.\nClaimable Rewards#\nFetch the user's matured rewards that are ready to claim.\nReactTypeScriptGraphQLUse the useUserClaimableRewards hook (or the imperative useUserClaimableRewardsAction variant) to fetch all rewards the user can claim.import { chainId, useUserClaimableRewards, type EvmAddress,} from \"@aave/react\";\nfunction ClaimableRewards({ user }: { user: EvmAddress }) { const { data, loading, error } = useUserClaimableRewards({ user, chainId: chainId(1), });\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n if (data.length === 0) return <div>No claimable rewards</div>;\n return ( <div> {data.map((reward) => ( <div key={reward.id}> <p>Amount: {reward.claimable.amount.value.toDecimalPlaces(2)}</p> <p>Claim until: {reward.claimUntil.toLocaleDateString()}</p> </div> ))} </div> );}The useUserClaimableRewardsAction hook does not watch for updates. Use\nit when you need on-demand, fresh data (e.g., in an event handler).\nThe UserMerklClaimableReward type contains details about each claimable reward:\ninterface UserMerklClaimableReward { __typename: \"UserMerklClaimableReward\"; id: string; claimable: Erc20Amount; startDate: Date; endDate: Date; claimUntil: Date;}\nWhere:\nid - Unique identifier for the reward (used when claiming)claimable - The claimable token amountstartDate - When the reward period startedendDate - When the reward period endedclaimUntil - Deadline to claim the reward\nClaim Rewards#\nOnce you have claimable rewards, collect them individually or all at once in a single transaction.\nAfter claiming, the claimable rewards list may not update immediately. The\nupdate depends on Merkl signaling that the rewards have been claimed, which\ncan take some time.\nReactTypeScriptGraphQLTo claim rewards with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Define the Claim Flow#Then, use the useClaimRewards hook to prepare the claim operation.import { useClaimRewards } from \"@aave/react\";\nconst [claim, { loading, error }] = useClaimRewards((transaction) => sendTransaction(transaction),);3Execute the Claim Operation#Then, execute the claim operation with the reward IDs from the claimable rewards.import { chainId, useUserClaimableRewards, rewardId, evmAddress,} from \"@aave/react\";\nconst { data: claimableRewards } = useUserClaimableRewards({ user: evmAddress(wallet.account.address), chainId: chainId(1), suspense: true,});\nconst execute = async () => { if (claimableRewards.length > 0) { const result = await claim({ ids: claimableRewards.map((reward) => rewardId(reward.id)), user: evmAddress(wallet.account.address), chainId: chainId(1), });\n // … }};4Handle the Result#Finally, handle the result.const execute = async () => { const result = await claim(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Rewards claimed successfully with hash:\", result.value.txHash);};PreviousChainsNextUser Positions","tokens":1943,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258351511,"hash":"64960b3d458e20f9e7f08bb739453e237fb3b5fb"}
{"url":"https://vote.optimism.io/proposals/20323926184780688851014762438202520912959297611775969703534861738050572508734","domain":"vote.optimism.io","title":"Season 9 Governance Fund Mission: Gra...","text":"ProposalsVotersConnect  Wallet Optimistic Proposal by The Optimism FoundationSeason 9 Governance Fund Mission: Grants CouncilProposal Visualization Loading transactions...This is an optimistic approval. You should only cast a vote if you want to veto this proposal. You can read more about this proposal type in our operating manual.\nThis proposal seeks to approve a mission funded by the Governance Fund:\nGrants Council\nBudget: 3.89M OP\nYou can read about the proposal in its entirety here.Voting activityThis proposal is optimistically approvedThis proposal will automatically pass unless 20% of the votable supply of OP is against. Currently 0.6% (486,792 OP) is against.SUCCEEDEDEnded 12:58 pm Jan 28, 2026VotersHasn't votedLoading votes...Optimistic Proposal by The Optimism FoundationSeason 9 Governance Fund Mission: Grants CouncilProposal Visualization Loading transactions...This is an optimistic approval. You should only cast a vote if you want to veto this proposal. You can read more about this proposal type in our operating manual.\nThis proposal seeks to approve a mission funded by the Governance Fund:\nGrants Council\nBudget: 3.89M OP\nYou can read about the proposal in its entirety here.Voting activityThis proposal is optimistically approvedThis proposal will automatically pass unless 20% of the votable supply of OP is against. Currently 0.6% (486,792 OP) is against.SUCCEEDEDEnded 6:58 pm Jan 28, 2026VotersHasn't votedLoading votes...Season 9 Governance Fund Mission: Gra...Governance ForumReport bugs & feedbackChange logFAQ0 OP total supply0 OP votable supply","tokens":396,"squid":"ink-governance","role":"Council Listener","at":1791258351982,"hash":"fd196735e51499f94bf3ddf87831b90614c69b6e"}
{"url":"https://www.openzeppelin.com/privacy","domain":"openzeppelin.com","title":"Data Privacy Notice | OpenZeppelin","text":"Data Privacy NoticeLast Updated: September 1, 2026Why are you seeing this notice?This Data Privacy Notice details important information regarding the collection, storage, use and disclosure of Personal Data (as defined below) of users of the OpenZeppelin websites and any other products, services, applications, tools, blogs, forums and/or materials offered from time to time by OpenZeppelin, as well as our recruitment, hiring, and candidate evaluation activities (collectively, the “Services”). OpenZeppelin provides this Data Privacy Notice to help you understand how your Personal Data is collected and used by us and your choices regarding our use of it.What is “Personal Data”?“Personal Data”, or personal information, means any information about an individual from which that person can be identified, or that is protected under applicable data protection legislation in any applicable jurisdiction.Your acceptance of this Data Privacy NoticeThis Data Privacy Notice should be read in conjunction with our Terms of Service found at https://www.openzeppelin.com/tos and any other agreement you have entered with OpenZeppelin, as applicable. If you have not done so already, please also review our Terms of Service. The Terms of Service govern your use of the Services and contain provisions that limit our liability to you and require you to resolve any dispute with us on an individual basis and not as part of any class or representative action.Who is providing this notice?The entity that provides the Services and that is responsible under this notice is Zeppelin Group Ltd, a company incorporated in England and Wales whose registered address is at 5 New Street Square, London EC4A 3TW (“OpenZeppelin”). Where we use the terms “we”, “us” and “our” in this Data Privacy Notice, we are referring to OpenZeppelin. OpenZeppelin is committed to protecting and respecting your privacy.This notice and any other documents referred to in it sets out the basis on which any Personal Data we collect from you, or that you provide to us, will be processed by us. When you provide us with your Personal Data, we act as a “data controller”. In simple terms, this means that:we control the Personal Data that you provide, including making sure that it is kept secure; andwe make certain decisions on how to use and protect your Personal Data, but only to the extent that we have informed you about the use or are otherwise permitted by law.Changes to our Data Privacy NoticeWhile our values will not shift, the Services will evolve over time, and this Data Privacy Notice will change to reflect that evolution. If we make changes, we will notify you by revising the date at the top of this Data Privacy Notice. In some cases, if we make significant changes, we may give you additional notice (e.g. by emailing you or by adding a statement to our homepage). We encourage you to review this Data Privacy Notice periodically to stay informed about our practices. Any questions, comments or complaints that you might have should be emailed to legal@openzeppelin.com.Please read the following carefully to understand our views and practices regarding your Personal Data and how we will treat it.Appropriate useOur Services are not intended for anyone under the age of 18 and we do not knowingly collect data relating to anyone under the age of 18. If you are under the age of majority in your jurisdiction of residence, you may use the Services only with the consent of or under the supervision of your parent or legal guardian.Personal Data we collect about youThe Personal Data collected about you will help us to provide better Services and facilitate our provision of our offerings to you. We may combine Personal Data that you provide us with Personal Data that we collected from, or about you, in some circumstances.Personal Data we collect may include:Identity information, such as your name, username or similar identifier, title, and date of birth;Contact information, such as your postal address, email address, and telephone number;Information required to comply with anti-money laundering (AML) laws and know-your-customer (KYC) requirements, including passport and/or photo ID for identity verification purposes, nationality and place of birth;Profile information, such as your username, email, interests, preferences, feedback and survey responses;Feedback and correspondence, such as information you provide when you receive support, participate in forums, conferences, communities, market research activities, surveys, or otherwise correspond with us;Financial information, such as tax numbers, bank account information, your credit card information, or other payment details;Transaction information, such as details about purchases and billing details;Marketing information, such as your preferences for receiving marketing or other communications and details about how you engage with them;Usage information, such as information about how you use the Services and interact with us;Technical information, such as your IP address, public blockchain address, application programming interface (API) keys and network information regarding blockchain and related transactions.If you apply for a role with OpenZeppelin, we may collect application details, including, but not limited to CV/resume, education history, employment history, eligibility and verification information, interview assessments, and recordings or transcripts generated during interviews.Where do we obtain your Personal Data?We will collect and process Personal Data about you from a number of sources, including:Personal Data you give us. This is information about you that you give us through the Services, or by corresponding with us through support channels, e-mail, videoconference software, phone, social media, forums, blogs, or otherwise. The information you give us may include your name, address, e-mail address and phone number, financial and credit card information, personal description, personal documentation and photographs or other information you choose to share with us. User-submitted content, such as content submitted to AI-powered features of the Services, may also contain your Personal Data.Personal Data you agree we may collect. You may agree to give us information relating to your use of the Services, which may include usage data and technical information (e.g. frequency of use of subcommands or other features utilized within the Services).Personal Data we collect about you. We may automatically collect certain information about how you use certain Services (“Log Data”) that could constitute Personal Data. Log Data is used to administer the Services, improve the Services, and to provide security and support for the Services. Retention periods for Log Data vary depending on the type of information. Log Data may include, without limitation, information such as:technical information, including the IP address used to connect your device to the Internet, your device, your login information, browser type and version, time zone setting, browser plug-in types and versions, operating system and platform;information about your access to or use of the Services, including the full Uniform Resource Locators (URL), clickstream to, through and from our Services (including date and time), offerings you viewed, features used, downloaded or searched for, page response times, errors, length of visits to certain pages, interaction information (including scrolling, clicks, and mouse-overs), methods used to browse away from the page, API usage, UI usage, and transaction information and actions.Personal Data we receive from other sources. We work with third parties (including, for example, software providers, business partners, sub-contractors in technical, payment and delivery services, analytics providers, search information providers) who may provide us information about you. We will combine this Personal Data with information you give to us and information we collect about you.Cookie PolicyA cookie is a small piece of data (text file) that a website – when visited by a user – asks your browser to store on your device in order to remember information about you, such as your login information.We use cookies, local storage, or similar technologies to distinguish you from other users of our Services and to administer the Services, analyze performance of the Services, and to gather information about our users as a whole. This helps us to provide you with a good experience when you access or use our Services and allows us to improve our Services. You can reject all non-essential cookies by choosing “Decline” or set your own preference under “Cookies settings”. Most web browsers are set to accept cookies by default, but you can usually set your browser to remove or reject browser cookies. If you do choose to remove or reject cookies, however, your ability to use the Services might be affected.CookieNamePurposeTypeDurationGoogle\nAnalytics_ga, _ga_*Used to distinguish users and collect website usage statistics to improve services and performance.Not strictly necessary (Analytics)Up to 2 yearsHotjar__hjSession_*, __hjSessionUser_*Behavioral analytics to understand user interactions (e.g. heatmaps, session recordings) and improve user experience.Not strictly necessary (Analytics)Up to 1 yearHubSpothubspotutk, __hstc, __hssc, __hssrcTracks visitors and form submissions to support analytics, CRM integration, and marketing insights.Not strictly necessary (Analytics/Marketing)Up to 6 monthsHubSpot__hs_cookie_cat_prefStores the user’s cookie consent preferences.Strictly necessary6 monthsCloudflare_cf_bm, _cfuvidProvides bot management, security, and performance protection.Strictly necessarySession / up to 30 minutesCloudflare__cfruid, _cfuvidUsed for rate limiting and identifying trusted web traffic.Strictly necessarySessionStripe_stripe_mid, _stripe_sidEnables secure payment processing and fraud preventionStrictly necessaryUp to 1 yearLinkedIn_li_gc, lidcUsed for advertising, tracking conversions, and measuring campaign effectiveness.Not strictly necessary (Marketing)Up to 2 yearsUses made of the informationWe only use your Personal Data where we are allowed to by law. We process your Personal Data for the following purposes:It is necessary to perform our contract with you:to provide you with the information, products, and services that you access or request from us and support related thereto;to carry out our obligations arising from any contracts entered between you and us, including but not limited to under the Terms of Service;to process and complete your purchases, and send you related information, including order forms, purchase confirmations and invoices;to facilitate the continuation or termination of the contractual relationship;to notify you about changes to our products or services;to create and send information, including confirmations, technical notices, updates, security alerts, support and administrative messages; andto administer and facilitate any other transaction between you and us.It is necessary for compliance with an applicable legal or regulatory obligation, for example:to comply with lawful requests and legal process, such as to respond to subpoenas or requests from regulatory, governmental, tax, and law enforcement authorities;to comply with an applicable legal or regulatory obligation to which we or the relevant third party is subject;to carry out audit checks;to protect, investigate, and deter against fraudulent, unauthorized, or illegal activity; andto comply with AML and KYC laws and requirements, including sanction regimes.If you have applied to a role with us, for example:to assess your suitability for a role, including reviewing your qualifications, experience, and interview performance;to manage and administer our recruitment process; andto comply with legal and regulatory obligations relating to employment and hiring.For our legitimate interests or those of a third party:to provide you with information about other products and services we offer that are similar to those that you have already used, purchased or enquired about;to administer the Services and enhance them by improving the features and functionality and tailoring it to our users’ needs and preferences;to improve our Services and to ensure that content from our Services is presented in the most effective manner for you and for your computer or other device;to administer our Services and for internal operations, including troubleshooting, data analysis, testing, research, statistical and survey purposes;to allow you to participate in interactive features of our products and services, when you choose to do so;as part of our efforts to keep our Services safe and secure;to protect, investigate, and deter against fraudulent, unauthorized, or illegal activity;to measure or understand the effectiveness of content we serve to you and others, and to deliver relevant content to you; and/orto make suggestions and recommendations to you and other users of our Services about goods or services that may interest you or them.We only rely on these interests where we have considered that, on balance, our legitimate interests are not overridden by your interests, fundamental rights or freedoms. Where relevant, we process your Personal Data for more than one lawful ground depending on the specific purpose for which we are using your data.Use of your Personal Data with third-partiesWe may engage third parties, such as business partners, vendors, suppliers, and sub-contractors, to support our business or help us provide the Services to you or fulfill our obligations under a contract with you. As such, we may share your Personal Data with third parties, including without limitation for the purposes of operating cloud services, providing analytics or AI-powered functionalities, and other functions related to our Services. For more details regarding these third parties, please see our list of subprocessors in the OpenZeppelin Trust Center found at https://trust.openzeppelin.com.Consent and your right to withdraw itWe do not generally rely on obtaining your consent to process your Personal Data.If we do, you have the right to ask us not to process your Personal Data at any time. You can also exercise the right at any time by contacting us at legal@openzeppelin.com.Disclosure of your Personal DataWe may disclose your Personal Data under the following circumstances:for the purposes set out in this Data Privacy Notice;to deliver the products and services you access or use;to manage the relationship with you;to comply with international laws and regulations, including responding to lawful requests and legal processes;in an emergency, to protect our employees and agents, our customers, or any other stakeholder;to protect the rights and property of our users, other third parties, our agents, and us, including to enforce our agreements, policies and Terms of Service; andto protect against security vulnerabilities, fraud and credit risk;with:any member of our group, which means respective employees, officers, directors, contractors, consultants, equity holders, suppliers, vendors, service providers, parent companies, subsidiaries, affiliates, agents, representatives, predecessors, successors, and assigns;selected third parties who need it to do work for us, including business partners, vendors, suppliers, and sub-contractors, including without limitation our third-party cloud-based service providers (such as Github, Google Workspace, Hubspot, Slack and AWS);if we sell or buy any business or assets, the prospective seller or buyer of such business or assets;if OpenZeppelin or substantially all of its assets are acquired by a third party, in which case Personal Data held by us will be one of the transferred assets;professional advisors and service providers, including our lawyers, auditors, consultants and other professional advisors; orcompetent regulatory and other governmental agencies and litigation counterparties to comply with applicable legal and regulatory requirements.We may also share aggregated and/or anonymized data with others for their own uses.Do you have to provide us with Personal Data?Unless otherwise indicated, you should assume that we require the Personal Data for business and/or compliance purposes.Some of the Personal Data we request is necessary for us to provide the Services and if you do not wish to provide us with this Personal Data, it will affect our ability to provide our products or services to you.International data transfersYou acknowledge that Personal Data we obtain from you may be processed by our affiliated companies and third-party partners and service providers, who may be based in countries outside of the United Kingdom or the European Economic Area (“EEA”), for the purposes of providing you the Services. In particular, our third-party, cloud-based service providers (such as Github, Google Workspace, Hubspot, OpenAI, Anthropic, Zoom, Slack and AWS) utilize data centers in the United States. Such countries may not currently have laws offering the same level of protection for personal data as those inside the United Kingdom or the EEA. However, where such transfers of data occur, we take steps to prevent the transfer of personal data without adequate safeguards being put in place, such as by entering into European Union Standard Contractual Clauses, also known as Model Clauses, the UK Addendum to the UK SSCs, or the International Data Transfer Agreement. We will ensure that Personal Data collected in the United Kingdom and the EEA and transferred internationally is afforded the same level of protection as it would be inside the United Kingdom or the EEA. For further information on the adequate safeguards adopted by us for the international transfer of personal data, please contact legal@openzeppelin.com.Retention and deletion of your Personal DataWe keep your Personal Data for as long as it is required by us for our legitimate business purposes, to perform the Services and/or contractual obligations, for compliance with legal obligations, or where longer, such longer period as is required by law or regulatory obligations which apply to us. Some Personal Data will be retained after your relationship with us ends. As a general principle, we do not retain your Personal Data for longer than we need it. We will usually delete your Personal Data (at the latest) when there is no longer any legal or regulatory requirement or business purpose for retaining your Personal Data.In some circumstances, we may anonymize and/or aggregate your Personal Data (so that it no longer can be associated with you), in which case we may use this information indefinitely without further notice to you.SecurityOpenZeppelin has established a security program, as set out generally in the OpenZeppelin Trust Center found at https://trust.openzeppelin.com. However, the security of information transmitted through the internet and other technologies can never be guaranteed. We cannot guarantee the security of your Personal Data transmitted to our Services; any transmission is at your own risk. We are not responsible for any interception or interruption of any communications to the Services, or for changes to or losses of Personal Data. You are responsible for maintaining the security of any password, user ID or other form of authentication involved in obtaining access to the Services.Automated decision-makingWe will not take decisions producing legal effects concerning you, or otherwise significantly affecting you, based solely on automated processing of Personal Data, unless we have considered the proposed processing in a particular case and concluded in writing that it meets the requirements of UK and EEA data protection legislation and other applicable laws.Your rightsWe are the data controller responsible for your data. You have certain data protection rights, including:the right to access your Personal Data;the right to restrict the use of your Personal Data;the right to have incomplete or inaccurate Personal Data corrected;the right to ask us to stop processing your Personal Data; andthe right to require us to delete your Personal Data in some limited circumstances.You also have the right in some circumstances to request for us to “port” your Personal Data in a portable, re-usable format to other organisations (where this is possible).You may exercise these rights by sending a request to legal@openzeppelin.com. We will aim to respond to all legitimate requests as soon as we reasonably can and in any event within 30 days. If we think that it will take us longer than 30 days, we’ll let you know why and keep you updated. Where you make any requests, we might ask for specific information to confirm your identity as a security measure to ensure that Personal Data is not disclosed to any person who has no right to receive it. This might include asking for further information in relation to your request to be able to speed up our response.Third party linksOur Services may, from time to time, contain links to and from the websites and services of partner networks, third-party services, social networks and affiliates (“Third-party Services”). If you access or use any Third-party Services, please note that these Third-party services have their own privacy policies and that we do not accept any responsibility or liability for these policies. Please check these policies before you access, use or submit any personal data to these Third-party Services. The inclusion of Third-party Services in our Services or links to them does not imply that we endorse the practices of the Third-party Services.Concerns or queriesWe take your concerns very seriously. We encourage you to bring it to our attention if you have any concerns about our processing of your Personal Data.This privacy notice was drafted with simplicity and clarity in mind. We are, of course, happy to provide any further information or explanation needed. Our contact details are below.If you want to make a complaint, you can also contact the body regulating data protection in your country, where you live or work, or the location where the data protection issue arose. In the UK, the data protection authority is the Information Commissioner’s Office (ICO). A list of the EU data protection authorities is available by clicking this link: https://ec.europa.eu/newsroom/article29/items/612080.ContactPlease contact us if you have any questions about this privacy notice or the Personal Data we hold about you. Questions, comments and requests are welcomed and should be addressed to legal@openzeppelin.com.Notice to California residentsUnder California Civil Code Section 1789.3, California users are entitled to the following consumer rights notice: California residents may reach the Complaint Assistance Unit of the Division of Consumer Services of the California Department of Consumer Affairs by mail at 1625 North Market Blvd., Sacramento, CA 95834, or by telephone at (916) 445-1254 or (800) 952-5210.This section provides additional details about the personal information we collect about California consumers and the rights afforded to them under the California Consumer Privacy Act (“CCPA”).For more details about the personal information we collect from you, please see the “PERSONAL DATA WE COLLECT ABOUT YOU” section above. We collect this information for the business and commercial purposes described in the “USES MADE OF THE INFORMATION” section above. We share this information with the categories of third parties described in the “DISCLOSURE OF YOUR PERSONAL DATA” section above.We do not sell (as such term is defined in the CCPA) the personal information we collect (and will not sell it without providing a right to opt out).Please refer to the “COOKIES POLICY” section above for more information regarding the types of third-party cookies, if any, that we use.Subject to certain limitations, the CCPA provides California consumers the right to request to know more details about the categories or specific pieces of personal information we collect (including how we use and disclose this information), to delete their personal information, to opt out of any “sales” that may be occurring, and to not be discriminated against for exercising these rights. California consumers may make a request pursuant to their rights under the CCPA by contacting us at legal@openzeppelin.com. Please note that you must verify your identity and request before further action is taken. As a part of this process, government identification may be required. Consistent with California law, you may designate an authorized agent to make a request on your behalf. In order to designate an authorized agent to make a request on your behalf, you must provide a valid power of attorney, the requester’s valid government issued identification, and the authorized agent’s valid government issued identification.","tokens":6250,"squid":"ink-security_audits","role":"Sentinel","at":1791258352603,"hash":"6108424b80bfcff21ea3c613b55a0b6a8e593442"}
{"url":"https://www.openzeppelin.com/tos","domain":"openzeppelin.com","title":"Terms of Service | OpenZeppelin","text":"Terms of ServiceLast Updated: March 25, 2026Your use of our Services is governed by these Terms of Service (the “Terms”). The “Services” mean the services and products offered by OpenZeppelin to you in accordance with these Terms and which are available on the website at https://openzeppelin.com (and any of its sub-domains) or such other address as we may nominate from time to time (the \"Website\"). The Services may include cloud-hosted service offerings such as Defender, the OpenZeppelin security platform, or other hosted offerings (the “Cloud Services”), OpenZeppelin Security Services, OpenZeppelin Wizard, OpenZeppelin MPC Servers, OpenZeppelin Skills, OpenZeppelin Contracts, and the provision of any code, software, libraries, applications, programs, APIs, tools, features, documentation, support, audits, consulting, deliverables, reports, blog posts, forums, or other materials offered from time to time by OpenZeppelin.1. Accepting these Terms1.1. These Terms, together with any ordering document, online registration, or invoice that references these Terms (if applicable, an “Order”), constitute a legal and enforceable contract between Zeppelin Group Ltd, a company incorporated in England and Wales whose registered address is at 5 New Street Square, London EC4A 3TW (“OpenZeppelin”, “we”, “our” or “us”) and the entity or person placing an Order for or accessing or using the Services in any way (“you” or “your”). If you have multiple Orders, each Order forms a separate and independent agreement between you and OpenZeppelin incorporating these Terms.1.2. To use any Services (including Free and Beta Services), you must first agree to the Terms. If you do not agree to the Terms, you are not authorised to access or use any Services. Please note that the dispute resolution section of these Terms includes a binding arbitration provision in Section 14.1.3. If you are accepting these Terms on behalf of an entity (such as a company (e.g. your employer), a decentralised autonomous organisation, or other legal entity), you represent and warrant that you have full authority to bind the entity to these Terms. If the entity does not agree to or cannot comply with all of the Terms, or if you do not have authority to bind the entity, then do not agree to these Terms and the entity will be not authorised to access or use the Services.1.4. You acknowledge and agree that you have accessed online and/or been provided a copy of these Terms and that you have read, understand and agree to be bound by these Terms in their entirety by: (a) accessing or using any Services; (b) clicking or tapping on a button indicating your acceptance; or (c) executing or making payment based on an Order that references these Terms (the first to occur, the “Effective Date”) and OpenZeppelin will treat any of the foregoing as acceptance of the Terms from that point onwards.2. The Services2.1. Cloud Services. You may access and use Cloud Services subject to payment of any applicable fees and the requirements of these Terms. If you sign-up for Cloud Services, your subscription will include the features and quotas applicable to the tier selected (a “Subscription”) on the billing frequency that you select (a “Subscription Term”). Available subscription plans may change over time, but your Subscription will not be materially degraded mid-Subscription Term.2.2. Support. If you have purchased a paid Subscription to Cloud Services, OpenZeppelin will provide you support by email at defender-support@openzeppelin.com and OpenZeppelin will use reasonable efforts to respond to support requests during business hours and resolve such issues on a commercially reasonable basis, unless another support level is set out in your Order. You are also encouraged to visit our community forums for any support-related questions.2.3. Security Services. OpenZeppelin may provide certain security services as described in, and subject to payment of the fees specified in, an Order (“Security Services”). Descriptions of OpenZeppelin's standard Security Services offerings are available on the Website.2.4. Free or Beta Services. If you access or use any free, unpaid or trial Services or Services released as beta, pilot, limited release, non-production, evaluation or similar (“Free or Beta Services”), you acknowledge and agree that such Services are provided “as-is” without any representations, conditions, warranties, support, maintenance or other obligation of any kind including any of merchantability, quality, fitness for a particular purpose, or non-infringement. OpenZeppelin does not guarantee that the Free or Beta Services will be uninterrupted or error-free. OpenZeppelin may terminate your access to, or use of, Free or Beta Services at any time.2.5. Open Source Services. Certain of the Services are offered as, under, use, incorporate or link to open source software and you acknowledge and agree that your use of such Services is subject to, and you will comply with, any applicable open source licences that govern such open source software (collectively, “Open Source Licences”). Open Source Licenses are generally included in a “LICENSE” or “README” file in open source software, or in the related repository (e.g. on GitHub or GitLab) or on the Website. Without limiting the generality of the foregoing, you may not use, modify, sell, lease, lend, share, distribute or otherwise permit any third party to use the applicable open source software in a manner that violates any applicable Open Source Licences.2.6. Service Provision. Subject to Section 2.4 and Section 2.5, OpenZeppelin warrants that the Services shall be performed with reasonable skill and care, and materially in accordance with any description made available on the Website or otherwise provided by OpenZeppelin. In the event the Services are found not to comply with this warranty, your sole and exclusive remedy shall be limited to the following: (a) for Cloud Services, any credits due under the Service Level Agreement (if any), and (b) for Security Services, re-performance of any Services so that they are compliant.3. Billing, Payment and Renewal3.1. Pricing. Unless specified in an Order, the pricing applicable to the Services is specified on the Website or within the Services. If you upgrade to a higher tier of Cloud Services, OpenZeppelin will credit any remaining balance from your previous Subscription payment to your new tier. OpenZeppelin reserves the right to modify pricing at any time. However, OpenZeppelin will notify you prior to any price increase affecting your Cloud Services account and such modified pricing will not take effect until the next renewal of your Subscription. If you do not accept the pricing change, you may elect to not renew your Subscription in accordance with these Terms.3.2. Due Dates. OpenZeppelin will bill you in advance for all Services, however OpenZeppelin may in its sole discretion permit you to exceed the quotas set out in your Subscription and in such case will bill you at current rates for any excess usage at the end of each calendar month and any such amounts will be due immediately. Except when required by applicable law, all fees are non-cancellable and once paid are non-refundable. Unless otherwise communicated to you, credit card, debit card, or other non-invoice forms of payment are due at the beginning of each Subscription Term. You authorise OpenZeppelin to charge your designated payment method for all Subscription and related fees when due. OpenZeppelin may authorise other forms of payment, which may be subject to additional terms. Payments for invoices are due ten (10) business days after the invoice date, unless otherwise specified, and are considered overdue thereafter.3.3. Renewals. If you enter into a Subscription, you are enrolling in a recurring payment plan. Your Subscription will automatically renew at the end of each Subscription Term at your then-current tier for the same period of time (e.g., 12 months if you choose an annual plan), unless either party cancels the auto-renewal or otherwise terminates the Subscription at least 30 days before the end of the current Subscription Term.3.4. Downgrade or Cancellation. You may downgrade or cancel your Subscription at any time. The cancellation or downgrade will take effect at the end of your current Subscription Term and you will continue to have access to all the features of your Subscription until the end of the current Subscription Term, unless you request closure of your account. OpenZeppelin does not provide any refunds or credits for partial or unused Subscription Terms. To cancel, you must log into your account and select the appropriate options on the account settings page (if available to you), or you can contact OpenZeppelin support.3.5. Currency and Taxes. All amounts payable to OpenZeppelin will be paid in the currency set forth on the pricing page on the Website or in an applicable Order and are exclusive of any applicable sales, value-added or use taxes (such as GST or VAT). In the event that a party is required to collect, deduct or withhold any taxes from the amounts payable to OpenZeppelin, you will pay an additional amount, so that OpenZeppelin receives the amounts due to it hereunder in full, as if there were no assessment, withholding or deduction.3.6. Billing Disputes. Billing disputes must be notified to OpenZeppelin in writing within 30 days from discovery of an error. Orders for which payment is not received within ten (10) business days following your receipt of the invoice or other bill will accrue a late charge at the rate of 4% per annum above the base lending rate of the Bank of England for the time being, except as prohibited by law. OpenZeppelin may, in its sole discretion, suspend any Services or withhold any Deliverables until any outstanding fees are paid in full.4. Using the Services4.1. Account Information. In order to use or access certain Services, you must successfully register an account with us. You retain administrative control over who is granted access to your account. Each account is controlled by account admin(s) tied to a specific email address. You and any collaborators or other users (\"User(s)\") that you add to your account may be required to provide registration information in order to register for and access certain Services. You agree to keep this information, including contact information (e.g. e-mail address) and billing/payment details, accurate and current. OpenZeppelin is entitled to rely on communications from the account owner or admins when servicing your account.4.2. Responsibility for Account. You are responsible for all activities that occur relating to your access or use of the Services or that occur through your account, regardless of whether the activities are authorised by you or undertaken by you, any User, your affiliates, your employees, contractors, agents, collaborators or a third party and all references to “you”, “your”, or a “User’s” activities in these Terms include any such usage. The individual or entity entering into these Terms will remain responsible for any such acts or omissions.4.3. Users. Subscriptions and any collaborator seats included in your Subscription are for specific individual Users and cannot be shared or used by more than one individual at a time. However, individual Users on your account may be reassigned to new Users, replacing individuals who no longer use the Services for any purpose (e.g. transferring a collaborator seat from a terminated employee to a new employee). You will: (a) if applicable, obtain from the Users on your account any consents necessary for OpenZeppelin to provide the Services; (b) maintain appropriate security standards with respect to use of the Services by all of your Users; and (c) in the event of any unauthorised access to or use of the Services, promptly notify OpenZeppelin at security@openzeppelin.com.4.4. Security. You are solely responsible for properly configuring and using the Services and otherwise taking appropriate action to secure, protect and backup your accounts and/or Service Inputs (as defined below) in a manner that will provide appropriate security and protection. This includes your obligation under these Terms to record and securely maintain any passwords or backup security phrases (e.g. “seed” phrases or API “secret keys”) that relate to your use of the Services. You acknowledge and agree that you will not share with OpenZeppelin any password or backup/seed phrase that you create to use the Services and that you are solely responsible for adopting security procedures to secure and recover your account or any Third-Party Services you use with the Services. OpenZeppelin is not responsible for unauthorised access to your account perpetrated by third parties, including any access that occurs as a result of fraud, phishing, or other unauthorised activity (except to the extent we are found at fault).4.5. Your Responsibilities. You are responsible for: (a) access to and use of the Services by you and any Users on your account and their respective compliance with these Terms; (b) the secure transmission of Service Inputs to the Services; (c) the legality, reliability, integrity, accuracy and quality of Service Inputs, any conclusions drawn or actions taken therefrom, and the means by which you or the Users acquired the Service Inputs, so that OpenZeppelin and its service providers may lawfully use, process, and transfer Service Inputs in accordance with these Terms; (d) determining if any Service Outputs are accurate or appropriate for your use; (e) backing-up your systems, operations, Service Inputs, and Service Outputs outside of the Services; and (f) using appropriate methods and technologies to prevent the introduction of vulnerabilities, viruses, malware, Trojan horses, worms, spyware or other destructive code into the Services.4.6. Use Restrictions. As a condition of use of the Services, you will not and will ensure that each User does not use the Services in any way: (a) to licence, sublicence, sell, resell, rent, lease, transfer, distribute, provide access, or otherwise commercially exploit, or make the Services available to any third-party, except as expressly authorised by these Terms; (b) to remove or modify any proprietary markings or restrictive legends in the Services; (c) to infringe or misappropriate any OpenZeppelin intellectual property; (d) that is or that a person would reasonably believe to be unlawful, illegal, fraudulent, tortious, threatening, deceptive, or prohibited by these Terms or other applicable terms and conditions; (e) that violates the legal rights of OpenZeppelin or others; (f) that could reasonably interfere with any other party’s use and enjoyment of the Services; (g) to probe, scan, or test the vulnerability of Cloud Services; (h) that could reasonably interrupt, interfere with, destroy or limit the security, integrity, functionality, or operation of the Services or any related computer software or hardware, application, blockchain, or telecommunications equipment in any way; (i) that circumvents a usage or capacity limit of the Services, including any unauthorised use of or access to Cloud Services or any of OpenZeppelin’s intellectual property, data centers, systems or networks; (j) to multiplex usage across different accounts on the Services; (k) to copy, modify, translate, adapt, merge, or create derivative works of the Services or reverse engineer, decompile, translate, disassemble or otherwise attempt to extract any or all of the source code of the Services (except as may be allowed by any applicable law which is incapable of exclusion by agreement between the parties); (l) to develop a competitive product or service (collectively, the “Use Restrictions”).4.7. International Trade Laws. The Services may be accessed from countries around the world and may contain references to Services and content that are not available in your country. OpenZeppelin makes no representations that the Services are appropriate or available for use in all locations. Your use of the Services is subject to international export controls and economic sanctions requirements. By accessing or using the Services, you agree that you will comply with those requirements. You are not permitted to access or use any of the Services if you are in, under the control of, or a resident of any country subject to HM Treasury’s financial sanctions regimes, UN sanctions, the European Union or United States embargo, or if you are a person on the economic sanctions lists as published from time to time by applicable authorities (including, but not limited to the Office of Financial Sanctions Implementation (part of HM Treasury), the U.S. Commerce Department’s Denied Persons List, Unverified List, or Entity List, or the EU financial sanctions regime). You acknowledge and agree that you may not use the Services if you are a person barred from using the Services under the laws the country in which you are resident or from which you use the Services. Those who access or use the Services or content agree to do so at their own volition and acknowledge they are responsible for compliance with applicable law.4.8. Protected Information. OpenZeppelin uses your personal data as described in its Data Privacy Notice. The Services can interact with Protocols (as defined below) and LLMs (as defined below) and therefore were not designed or intended to process or manage any Protected Information. For the purposes of this section, “Protected Information” means personal information that is subject to specific regulations or laws that impose increased protections and/or obligations with respect to handling that type of information (e.g. GDPR). You represent and warrant that you will obtain and maintain any required consents necessary to permit the processing of any Personal Information under these Terms. OpenZeppelin will not be responsible for any liability associated with Protected Information created, stored, shared or processed by you using the Services.4.9. AI Technology. Certain Services may include AI-enabled features that pass Service Inputs you input into an interface to third-party large language model providers (“LLMs”) that provide analysis, findings, recommendations, and other outputs based on the Service Inputs (“AI Outputs”). The AI Outputs may be inaccurate or incomplete, and the AI Outputs may require you to make additional modifications to be useful and it is your responsibility to determine if any AI Outputs are accurate or appropriate for your use.5. Confidentiality5.1. Confidential Information. In connection with these Terms, either party (as the \"Discloser\") on behalf of itself and its affiliates may disclose or make available to the other party (as the \"Receiver\"), non-public information of Discloser that is known as such or would reasonably be assumed to be confidential given its nature or the circumstances of disclosure (\"Confidential Information\").5.2. Permitted Use. The Receiver must only use the Confidential Information for the purpose contemplated by these Terms and will not disclose Confidential Information, except to Receiver’s officers, directors, agents, affiliated companies, employees, consultants, contractors and professional advisors who need to know the Confidential Information for such purpose and have agreed to keep it confidential and protect it to the same extent that Receiver protects its own Confidential Information, but in no event will it use less than a reasonable degree of care.5.3. Permitted Disclosures. Nothing in this Section 5 prevents the Receiver from disclosing any Confidential Information if necessary pursuant to the lawful requirement of any governmental agency or by any subpoena, summons, order or other judicial process, on the condition that promptly on receipt of any order compelling that disclosure, to the extent legally permissible, the Receiver notifies the Discloser in writing of that requirement to disclose and cooperates with the Discloser’s lawful efforts to resist, limit or delay disclosure, if the Discloser chooses to do so. Confidential Information remains confidential regardless of those orders or requirements of disclosure, and the Receiving Party’s obligations with respect to Confidential Information will not be altered by virtue of such disclosures.5.4. Exceptions. Confidential Information does not include any information that is: (a) in the public domain not by breach of this Section 5; (b) already known by Receiver at the time of disclosure; (c) lawfully obtained by the Receiver from a third party other than through a breach of confidence; (d) independently developed by Receiver; or (e) authorised by Discloser in writing to be disclosed by Receiver.5.5. Duration. Termination of this agreement will not affect the parties' obligations in relation to Confidential Information, which will continue until the information no longer constitutes Confidential Information of the Disclosing Party. For Confidential Information that is a trade secret, the confidentiality obligations will remain in place as long as the applicable information retains its status as a trade secret. Upon the Disclosing Party’s request, the Receiving Party must take reasonable steps to destroy or erase any Confidential Information it holds, except the Receiving Party may retain copies of Confidential Information: (a) that are securely stored in archival or computer back-up systems; (b) to meet legal or regulatory obligations; or (c) in accordance with bona fide record retention policies.6. Proprietary Rights6.1. OpenZeppelin Ownership. OpenZeppelin or its licensors exclusively own all right, title and interest in and to the Services, Service Outputs and System Data (as defined below) and OpenZeppelin’s Confidential Information. Subject to the limited rights expressly granted under these Terms, OpenZeppelin and OpenZeppelin's licensors reserve all right, title, and interest in and to the Services, including all related intellectual property rights. No rights are granted to you except as expressly set forth in these Terms. “System Data'' means data generated by the Services or created by OpenZeppelin in performing the Services that may include logs, statistics or reports regarding the performance, availability, usage, integrity or security of Service Inputs or the Services. You agree that OpenZeppelin has the right to aggregate, collect and analyse Service Inputs and System Data and other information relating to the performance of the Services and will be free (during and after the term hereof) to use Service Inputs and System Data: (a) to improve OpenZeppelin’s products and services; or (b) solely in an aggregated and anonymised format that does not identify you or any individual.6.2. Service Inputs. You or your licensors own any data, information, code, materials and other content (including any intellectual property rights therein) which you (or someone acting on your behalf) provides, uploads to or is transmitted through the Services (\"Service Inputs\"). You permit OpenZeppelin to access and use the Service Inputs for the purposes contemplated by these Terms. You are responsible for all Service Inputs and you represent and warrant that you have all necessary rights to the Service Inputs and that they will comply with these Terms.6.3. Service Outputs. The Services may generate or provide certain information, reports or data, including outputs based on Service Inputs (\"Service Outputs\"). OpenZeppelin owns the Service Outputs (including any intellectual property rights therein), but excluding any Service Inputs which may have been incorporated. OpenZeppelin allows you to use the Service Outputs for the purposes of your business on a perpetual basis.6.4. User Feedback. You may provide suggestions for enhancements or improvements, new features or functionality or other feedback with respect to the Services (“Feedback”). OpenZeppelin will have full discretion to determine whether or not to proceed with the development of any requested enhancements, new features or functionality. OpenZeppelin will have the full, unencumbered right, without any obligation to compensate or reimburse you, to use, incorporate and otherwise fully exercise and exploit any Feedback.6.5. Publicity. OpenZeppelin may use your name and logo to identify you as a user and highlight such use details in public marketing materials. You may use OpenZeppelin’s name and logo, subject to our Brand Guidelines to accurately describe your use of the Services in accordance with these Terms, provided that you will not misrepresent or embellish the relationship between us. Either party shall immediately cease use of the other party’s name and logo upon receipt of a written request from such party.7. Third-Party Services7.1. Third-Party Services. In connection with the Services, you may use or elect to use code, software, applications, APIs, LLMs, wallets, custodians, services, integrations, functionality, links, products, intellectual property, or content that is developed or provided by a third-party, is not owned or under OpenZeppelin’s control and interoperates with, is supported by, or is linked to the Services, including without limitation any Protocol (as defined below) (“Third-Party Services”). You acknowledge and agree that OpenZeppelin is not responsible for any Third-Party Services, and OpenZeppelin’s linking to or integration with any Third-Party Services does not mean OpenZeppelin endorses or has reviewed such services. If you choose to utilise Third-Party Services, such use may be subject to the separate terms of use, licences, policies, fees, or other agreement between you and the third-party provider, even if that third-party provider has access to or is supported by the Services. You acknowledge and agree that OpenZeppelin has no liability with respect to use, procurement, maintenance, or interoperability of any Third-Party Services and that your access to or use of any Third-Party Services is at your own risk, and you expressly release OpenZeppelin from any liability, loss or damage of any nature arising from your use of any Third-Party Services.7.2. Customer Contractors. For the purposes of these Terms, “Customer Contractor” means any individual or entity authorised by you to have access to or use of the Services on your behalf (e.g. to provide an audit). Customer Contractors are subject to these Terms while they are using the Services. “Customer Contractor Services” means products, services or content developed or provided by Customer Contractors, including, but not limited to, audit services, implementation services, managed services, training, technical support, or other consulting services provided through, related to, or in conjunction with, the Services. You represent and warrant to OpenZeppelin that you will have a separate contractual agreement with any Customer Contractor that provides you Customer Contractor Services (in addition to the Customer Contractor being bound by these Terms). OpenZeppelin is not the provider of Customer Contractor Services and you acknowledge and agree that we have no liability whatsoever for the provision or non-provision of any Customer Contractor Services.7.3. Authorisation. You may authorise OpenZeppelin to give your Customer Contractors the rights and privileges to the Services (including the Service Inputs and Service Outputs) necessary to enable and provide for your use and receipt of the Customer Contractor Services. If at any time you revoke this authorisation, to the extent the Services provide the option for you to limit the Customer Contractor’s access and use, then you are responsible for taking the actions necessary to revoke such access and use. In the event you require OpenZeppelin assistance with such revocation or limitation, you must contact OpenZeppelin with written notice of such revocation or limitation and OpenZeppelin will disable the Customer Contractor’s access to your Services within a reasonable period of time following receipt of such notice.8. Disclaimers Relating to Blockchain Technology8.1. Blockchain networks, protocols, smart contracts, wallets, tokens, digital assets and related decentralised technologies (collectively, “Protocols”) are nascent technologies and entail risks. Any use or interaction with Protocols, whether or not using the Services, could require a comprehensive understanding of advanced technology in order to appreciate the inherent risks (including without limitation, computer science). You acknowledge and agree that you have sufficient knowledge and understanding of the functionality, usage, transmission mechanisms and other material characteristics of Protocols to understand and appreciate the risks and implications of the Services.8.2. OpenZeppelin does not own or control any Protocols. Generally, Protocols are public or open source, and anyone can use, copy, modify, and distribute them or participate in them. OpenZeppelin assumes no responsibility for the operation of Protocols and does not guarantee the functionality or security of Protocols. You acknowledge that Protocols are provided by third parties who have no affiliation with OpenZeppelin. You acknowledge and agree that OpenZeppelin’s inclusion, support, or promotion of a specific Protocol in the Services, or a description of how to use a Protocol, should not be interpreted as our endorsement or guarantee of that Protocol, or the accuracy, functionality or legitimacy of that Protocol. Further, you acknowledge that OpenZeppelin does not verify any Protocol or related services, including for security, accuracy or completeness. You acknowledge that your use of Protocols is at your own risk and you expressly release OpenZeppelin from any liability, loss or damage of any nature arising from your use of Protocols and related services.8.3. Protocols may be subject to sudden changes in operating rules or how they function. Any such operating changes may materially affect the availability, functionality, value, name, or other characteristics of the Protocol. Changes to Protocols may contain bugs or security vulnerabilities that may result in loss of functionality or assets. It is your responsibility to make yourself aware of operating changes to Protocols and you must carefully consider whether to continue to use a Protocol, including by utilising interoperable Services. You acknowledge and agree that you assume all risks relating to the presence or introduction of bugs, vulnerabilities, malicious code, the use of phishing, sybil attacks, 50% attacks, bruteforcing, or other means of attack that may affect, in any way, a Protocol and related services.OpenZeppelin’s integration with or support of any Protocol or response to any Protocol change is subject to its sole discretion and may include deciding not to support a Protocol or changes thereto.8.4. Certain features within the Services are designed to assist or augment Users in composing, automating and executing transactions with Protocols. However, you acknowledge and agree that OpenZeppelin strictly does not perform or execute transactions on your behalf and that you are responsible for all of your transactions. For example, the Cloud Services may offer certain technology that may allow you to more easily compose, automate and execute transactions you would like to perform in connection with a supported Protocol. As such, the Cloud Services may generate transaction objects, which you may review and authorise in order to execute a transaction. For example, the Cloud Services may combine publicly available information from a supported Protocol with your commands or the automations you develop and control within Cloud Services, producing a transaction compatible with the Protocol, intended to accomplish your operational goals as expressed through your interactions or integrations with the Cloud Services. The transaction then may be automatically signed with a private cryptographic key held in an AWS KMS account associated with the Relayer that is inaccessible to OpenZeppelin, or signed by you using a third-party wallet application, device, or similar functionality selected by you. The transaction will then be broadcast to the Protocol through a third-party RPC provider, resulting in any successful transaction being completed by you on the Protocol. Therefore, you acknowledge and agree that all Protocol transactions will are effected and recorded solely by you through your interactions with the respective nodes or other validators of the respective Protocol and that you assume full responsibility for all of the risks of accessing and using the Services to interact with Protocols.8.5. You should verify all transaction information prior to execution. You acknowledge and agree that OpenZeppelin shall bear no liability or responsibility for your transactions, including in the event you execute an erroneous or unlawful transaction. OpenZeppelin does not monitor or review the identity, data, value, instructions, or any other data in a transaction. Protocol transactions typically cannot be reversed once they have been broadcast to the relevant Protocol (even if in a pending state while the transaction is processed by network operators). You acknowledge that third-party RPC providers, including those that attempt to send private transactions (e.g. Flashbots), do not always function as intended. OpenZeppelin makes no guarantees that a transaction will be confirmed by a Protocol or remain private.8.6. You understand that the cost and speed of interacting with Protocols is variable and volatile, that cost may increase or speed may decrease dramatically at any time, and that cost and speed is not within the control of OpenZeppelin. You acknowledge these risks and agree that you are responsible for any transaction fees and that OpenZeppelin cannot be held liable for such risks, volatility, fluctuations, increased costs or decreased speed.8.7. You acknowledge that any Protocol or the Services could be impacted by changes in law, regulations, or one or more regulatory inquiries or legal actions, which could impede or limit the ability of OpenZeppelin to continue to offer or develop the Services, or which could impede or limit your ability to access or use the Services, and you assume such risk.8.8. OpenZeppelin may produce security audit reports and other materials summarising the security analysis of certain Protocols (“Reports”). OpenZeppelin typically receives compensation for performing security services, including producing Reports. Reports are produced only to assist developers to increase the security of the respective Protocol and are published with the client’s consent. The content contained in the Reports is current as of the date appearing on the Report and are subject to change without notice. The Reports and any related analysis of a Protocol or other project are provided for informational purposes only do not constitute statements, representations or warranties by OpenZeppelin in any respect, including regarding the security of such Protocol. You may not rely on the Reports in any way, including for the purpose of making any decisions to use a Protocol, a product or service, or buy or sell any digital asset. For the avoidance of doubt, Reports do not constitute investment advice, are not intended to be relied upon as investment advice, and are not an endorsement of any Protocol or other project. OpenZeppelin does not owe you any duty by publishing Reports.8.9. OpenZeppelin is a developer and supplier of software and security services. OpenZeppelin is not a custodian, wallet provider, payment processor, broker, nor is it a dealer or arranger, nor does it operate a digital asset exchange platform or offer trade execution or clearing services and, therefore, has no oversight, involvement, or control concerning the transactions you may choose to conduct using the Services. OpenZeppelin is not acting as an investment manager, adviser, arranger, introducer, broker, dealer, virtual asset service provider or commodity trading adviser to any person or entity. You further understand and agree that OpenZeppelin is not a money transmitter or money services business nor acts as your agent, fiduciary, trustee, bailee, or custodian with respect to any digital assets and OpenZeppelin does not assume control over your digital assets. You understand that OpenZeppelin is not registered or licensed by the FCA or any other financial regulatory authority (whether in the United Kingdom or elsewhere). No financial regulatory authority has reviewed or approved the use of the Services.9. General Disclaimers9.1. The Services are provided “as is” and without warranties, representations or conditions of any kind, except as expressly stated in these Terms. OpenZeppelin disclaims any and all warranties, representations and conditions, which may otherwise be implied, including any of merchantability, non-infringement, satisfactory quality, or fitness for a particular purpose.9.2. OpenZeppelin makes no representation or warranty of any kind regarding any Third-Party Services with which the Service may interoperate, including without limitation any Protocol.9.3. OpenZeppelin may update the content and functionality of any Services, including without limitation Cloud Services, or any tier thereof, in its sole discretion. OpenZeppelin does not represent or warrant that any Services or particular content, functionality, prices, or subscription plans will be offered indefinitely and reserves the right to change or alter the Services and any features, quotas and options, including the right to put reasonable usage limitations on the Services, including Cloud Services. OpenZeppelin will use commercially reasonable efforts to provide advance notice of any such usage restrictions or any material change in paid offerings.9.4. You acknowledge and agree that the Services are intended to assist or augment, but not replace, your code, software, systems, processes or any other aspect of your application or Protocol. OpenZeppelin does not warrant, and nothing in these Terms imply, that the Services, your use of the Services, or your application or your Protocol (if applicable) will be accurate, secure, or error-free, or that any security issues will be found or will be corrected and you acknowledge that any insights provided by the Services do not constitute professional advice or counsel.9.5. You acknowledge and agree that you are solely responsible for any decisions made pursuant to the Services and any recommendations or suggestions contained therein and that you have sole discretion to accept or to disregard any such recommendations. You are solely responsible for determining the appropriateness of the Services (including any Service Outputs), and unless explicitly stated otherwise in these Terms, you assume all risks associated with their use, including but not limited to the risks and costs of inaccuracies, errors, compliance with applicable laws, damage to or loss of data, systems, and unavailability or interruption of operations.10. IndemnificationYou agree to indemnify and hold harmless OpenZeppelin and its officers, directors, employees, affiliates, contractors, subcontractors, agents, attorneys, representatives, successors and assigns from and against any and all losses, liabilities, damages and all related costs and expenses (including reasonable attorneys' fees, litigation, settlement, judgment, interest and penalties) resulting from an actual or threatened claim, action or proceeding by a third party concerning: (a) your use of the Services in breach of these Terms; or (b) your application or Protocol (if applicable).11. Limitation of Liability11.1. Notwithstanding any other term contained herein (but subject always to clause 11.5), in no event will either party, or its officers, directors, employees, affiliates, contractors, subcontractors, agents, attorneys, representatives, and successors and assigns, be liable to the other party for any damages for loss of goodwill, lost profits, lost sales or business, work stoppage, computer failure or malfunction, lost content, or lost data, even if such party has been advised of the possibility of such damages, nor any indirect, punitive, incidental, special, consequential, exemplary, or aggravated damages arising out of or in any way connected with these Terms.11.2. You acknowledge and agree that OpenZeppelin is not responsible or liable in any way for damage caused by third parties who may use our Services, including those that may commit actionable conduct towards you. You further acknowledge and agree that OpenZeppelin is not responsible or liable in any way for damages incurred by any third parties relating to your use of the Services, including without limitation your customers or other end users.11.3. Notwithstanding any other term contained herein (but subject always to clause 11.5), OpenZeppelin's liability for any and all causes of action arising under or in connection with any Order or your access to or use of the Services (whether arising in tort, contract, statute, or otherwise) will be limited in each year (each such year commencing on the date of the applicable Order and each anniversary thereof) to the amount of fees that you have paid under that Order giving rise to the cause of action during such year.11.4. Notwithstanding any other term contained herein, if you access or use any Free or Beta Services, you understand that these Services are optional and either party may terminate these Services at any time for any reason and that OpenZeppelin provides Free or Beta Services “as is” with no warranty (including any of merchantability, quality, fitness for a particular purpose, or non-infringement) and our liability for such Services shall be limited in aggregate to GBP £100 (one-hundred pounds sterling) (subject always to clause 11.5).11.5. Notwithstanding any other term contained herein, neither party's liability: (a) for death or personal injury caused by its negligence or the negligence of its employees or agents; (b) for fraud or fraudulent misrepresentation; or (c) for any other liability that cannot be limited or excluded by law, is excluded or limited by these Terms.12. Term, Termination and Suspension12.1. Term. These Terms govern your use of the Services from the Effective Date (as determined in Section 1.4) until terminated pursuant to the terms contained herein (the “Term”). You may terminate your agreement to these Terms at any time if you have no active Orders by closing your account or ceasing to use any Services, as applicable.12.2. Termination of Orders by You. You may terminate any Order for any reason by providing OpenZeppelin with at least thirty (30) days written notice and ceasing use of the Services provided under that Order by the end of such notice period. As set out above, OpenZeppelin does not provide any refunds or credits for amounts that have already been paid prior to termination. Termination of any one Order does not automatically terminate any other Order which may be in place.12.3. Termination by Either Party. On written notice, either party may terminate these Terms (including any Orders): (a) if the other party commits a breach of these Terms and such breach has not been cured within 10 business days of receiving written notice of the breach; or (b) immediately upon the other party ceasing to operate in the ordinary course, making an assignment for benefit of creditors, or becoming the subject of any insolvency, bankruptcy, liquidation, dissolution, or similar proceeding (unless prevented from terminating pursuant to applicable law).12.4. Termination by Us. OpenZeppelin may terminate your access to the Services and these Terms (including any Orders) immediately on written notice if: (a) you have undisputed amounts past due; (b) OpenZeppelin reasonably determines that you are in material breach of these Terms and such breach is irremediable; or (c) OpenZeppelin reasonably determines continuing to offer the applicable Services pose an undue risk of violating applicable laws or regulations, or OpenZeppelin may terminate your access to any Free and Beta Services pursuant to Section 2.4.12.5. Suspension. OpenZeppelin may suspend your access to or terminate any or all of the Services if we consider it necessary for a legitimate business reason, including but not limited to: (a) protecting our or our customers' security; (b) if we suspect any fraud has or may occur; or (c) we suspect you are in breach of these Terms. If OpenZeppelin decides to suspend your access to Services under this Section 12.5 and not terminate the agreement, OpenZeppelin will only suspend access to the extent, and for the duration, necessary to address the risk and will promptly restore access once the issue has been resolved. If the reason for a suspension cannot be resolved, OpenZeppelin will automatically downgrade your account to a free account or terminate your use of the applicable Services.12.6. Effects of Suspension or Termination. You acknowledge and agree that if OpenZeppelin suspends your access to the Services or terminates your access to the Services, it may cause the permanent loss of Service Inputs, Service Outputs, features, functionality, or capacity, including without limitation the permanent loss of access to any smart contracts or blockchain accounts integrated with the Services and any data or digital assets related thereto. You are solely responsible for funding, managing, and withdrawing any digital assets in your smart contracts or blockchain accounts and we cannot provide assistance to fund, manage, or withdraw any of your digital assets.12.7. Enforcing Quotas. OpenZeppelin retains sole discretion to limit your usage of Cloud Services at any time if your usage of Cloud Services exceeds the quotas specified in your Subscription, including without limitation usage through the API or Cloud Services user interface. Further, excessive API requests, as determined by OpenZeppelin in our sole discretion, may result in the temporary or permanent suspension of your access to your account or to your use of Cloud Services. OpenZeppelin is not required but will endeavor, when reasonable, to warn an account owner or User prior to suspension.12.8. Survival. Any provision of these Terms that by its nature is reasonably intended to survive beyond termination of the Terms will survive any termination.13. Changes to the Terms and Orders13.1. Amendments. OpenZeppelin shall be entitled to amend each and every element of the Terms (other than an Order) from time to time. When these changes are made, OpenZeppelin will make a new copy of the Terms available at www.openzeppelin.com/tos. You understand and agree that if you use Free or Beta Services after the date on which the Terms have changed, OpenZeppelin will treat your continued use of the Services as acceptance of the updated Terms. If you have paid Services, the new Terms will apply upon the earliest of: (a) your renewal; (b) your clicking or tapping on a button indicating your acceptance; or (c) your executing or making payment based on an Order that references the updated Terms.13.2. Orders. Any material changes requested or required to be made to an Order will require mutual written agreement of the parties, for example under a statement of work or change order.14. Arbitration14.1. Please read the following section carefully because it requires you to arbitrate certain disputes and claims with OpenZeppelin and limits the manner in which you can seek relief from OpenZeppelin, unless you opt out of arbitration by following the instructions set forth below. In addition, arbitration precludes you from suing in court or having a jury trial.14.2. Mandatory Arbitration of Disputes. You and OpenZeppelin agree that any dispute, claim or controversy arising out of or relating to these Terms or the breach, termination, enforcement, interpretation or validity thereof or the use of the Services (collectively, \"Disputes\") will be resolved solely by binding, individual arbitration and not in a class, representative or consolidated action or proceeding. You and OpenZeppelin agree that the JAMS International Arbitration Rules govern the interpretation and enforcement of these Terms, and that you and OpenZeppelin are each waiving the right to a trial by jury or to participate in a class action. This arbitration provision shall survive termination of these Terms.14.3. Exceptions. As limited exceptions: (a) both parties may seek to resolve a Dispute in small claims court if it qualifies; and (b) each party retains the right to seek injunctive or other equitable relief from a court to prevent (or enjoin) the infringement or misappropriation of its respective intellectual property rights or to enforce the confidentiality obligations in these Terms.14.4. Conducting Arbitration and Arbitration Rules. The arbitration will be conducted by JAMS under its International Arbitration Rules (the “JAMS Rules”) then in effect, except as modified by these Terms. The JAMS Rules are available at www.jamsadr.com or by calling 1-800-352-JAMS. A party who wishes to start arbitration must submit a written Demand for Arbitration to JAMS and give notice to the other party as specified in the JAMS Rules. JAMS provides a form Demand for Arbitration at www.jamsadr.com. You and OpenZeppelin agree that you shall first seek to resolve any Dispute amicably prior to submitting any Demand for a maximum of thirty (30) days. Any arbitration hearings will take place in London, United Kingdom. The parties agree that the arbitrator shall have exclusive authority to decide all issues relating to the interpretation, applicability, enforceability and scope of this arbitration agreement.14.5. Injunctive and Declaratory Relief. Except as provided above, the arbitrator shall determine all issues of liability on the merits of any claim asserted by either party and may award declaratory or injunctive relief only in favor of the individual party seeking relief and only to the extent necessary to provide relief warranted by that party’s individual claim. To the extent that you or OpenZeppelin prevail on a claim and seek public injunctive relief (that is, injunctive relief that has the primary purpose and effect of prohibiting unlawful acts that threaten future injury), the entitlement to and extent of such relief must be litigated in a civil court of competent jurisdiction and not in arbitration. The parties agree that litigation of any issues of public injunctive relief shall be stayed pending the outcome of the merits of any individual claims in arbitration.14.6. Severability. If any clause within this Section 14 (other than the Dispute Resolution clause above) is found to be illegal or unenforceable, that clause will be severed from this provision whose remainder will be given full force and effect.14.7. Governing Law and Jurisdiction. The interpretation and enforcement of these Terms, and any dispute related to these Terms or the Services will be governed by and construed and enforced in accordance with the laws of England and Wales, as applicable, without regard to conflict of law rules or principles (whether of England and Wales or any other jurisdiction) that would cause the application of the laws of any other jurisdiction. You agree that OpenZeppelin may initiate a proceeding related to the enforcement or validity of its intellectual property rights in any court having jurisdiction. With respect to any other proceeding that is not subject to arbitration under these Terms, the courts located in London, England will have exclusive jurisdiction. You waive any objection to venue in any such courts.15. General Legal Terms15.1. Independent Contractors. You and OpenZeppelin are independent contractors of the other. These Terms do not create or imply any agency, partnership, unincorporated association, decentralised autonomous organisation, fiduciary, employment, or franchise relationship between the parties. No right or cause of action for any third party is created by these Terms or any acts or omissions contemplated under the Terms.15.2. Notices. Any notice required to be given under these Terms shall be in writing and shall be sent by electronic mail. For OpenZeppelin such notice must be emailed to legal@openzeppelin.com and for Users it shall be such email address provided for the respective account, as indicated in an Order, or if no email is reasonably available such other digital means of contact available to OpenZeppelin (e.g. Slack account, Telegram handle, Protocol forum, etc). A notice delivered by email shall be deemed to be received by the next business day.15.3. Assignment. Neither party may assign or transfer any rights or obligations under these Terms without the prior written consent of the other party, which will not be unreasonably withheld or delayed. Notwithstanding the foregoing, either party may assign these Terms to a successor or acquirer of all or substantially all its business or assets in connection with a sale of all or substantially all of its assets, or in the event of a bona fide corporate reorganisation. Subject to the foregoing limitation on assignment, these Terms will be binding upon, enforceable by and inure to the benefit of the parties and each of their successors and permitted assigns.15.4. Waivers. No waiver by either party of any default will operate as a waiver of any other default, or of a similar default on a future occasion. No waiver of any term or condition by either party will be effective unless in writing and signed by both parties.15.5. Severability. If any provision of these Terms is held invalid, illegal or unenforceable, it will be limited to the minimum extent necessary so the rest of these Terms remain in effect.15.6. Force Majeure. Neither party is liable for any delay or failure to perform any obligation under these Terms (except for a failure to pay any fees) due to events beyond its reasonable control, such as a strike, blockade, war, act of terrorism, riot, Internet or utility failures, Protocol failures and failures of related infrastructure, regulatory changes, refusal of government licence or natural disaster.15.7. Injunctive Relief. Each party acknowledges that any breach, threatened or actual, of the confidentiality and intellectual property obligations hereunder may cause irreparable injury to the other party for which there may not be an adequate remedy at law. Therefore, upon any such breach or threat thereof, the party alleging breach will be entitled to seek injunctive and other appropriate equitable relief in addition to any other remedies available to it, without the requirement of posting a bond.15.8. Order of Precedence. Any documents forming the agreement between you and OpenZeppelin are intended to be consistent. However there are incidences when the documents may conflict and in the event that there is a conflict between the elements of the agreement the order of precedence is as follows: (a) any statement of work, change order, or similar referencing an Order and signed by the parties; (b) the Order; (c) the Terms.15.9. Entire Agreement. These Terms (which includes each Order) is the entire agreement between you and OpenZeppelin related to your use of the Services and supersedes any prior or contemporaneous agreements regarding its subject matter. If you have another valid contractual agreement for the purchase and use of OpenZeppelin products and services, these Terms govern your rights to use any other OpenZeppelin products and services that are not explicitly covered by such separate agreement(s).","tokens":13967,"squid":"ink-security_audits","role":"Sentinel","at":1791258364137,"hash":"2c9242722dcea4f1f917e89ed8effeedc9faaca3"}
{"url":"https://io.net/docs/guides/intelligence/exploring-ai-models","domain":"io.net","title":"Exploring AI Models - io.net","text":"To get started, navigate to the Models tab.\n\n​What you can do on the Models Dashboard:\n\nBrowse the list of models with their context lenghts and prices.\n\n​Popular AI Models\nModel NameDeveloperDescriptiondeepseek-ai/DeepSeek-R1-0528DeepseekEnhanced model with improved reasoning, inference, and algorithmic post-training optimizations; designed for high-accuracy tasks.meta-llama/Llama-4-Maverick-17B-128E-Instruct-FP8Meta AIMultimodal instruction-tuned model leveraging a mixture-of-experts (MoE) architecture for top-tier performance in both text and image understanding.gpt-oss-120bOpen AIOpen-weight 117B parameter Mixture-of-Experts model supporting 128k context, advanced reasoning via chain-of-thought, optimized for real-world tool use, coding, and efficient local or cloud deployment.Intel/Qwen3-Coder-480B-A35B-Instruct-int4-mixed-arQwenHigh-capacity, instruction-tuned code generation model optimized with INT4 mixed-precision for fast inference, designed for complex programming tasks on Intel hardware.Qwen3-Next-80B-A3B-InstructQwenHigh-capacity model optimized for instruction following and knowledge-intensive tasks.gpt-oss-20bOpen AIOpen-source GPT-style model suitable for text generation and general-purpose tasks.Qwen3-235B-A22B-Thinking-2507QwenPowerful 235B-parameter language model optimized for deep reasoning, planning, and complex multi-step tasks.Mistral-Nemo-Instruct-2407Mistral AIInstruction-tuned model focusing on efficient reasoning and NLP tasks.meta-llama/Llama-3.3-70B-InstructMeta AILarge-scale transformer model fine-tuned for instruction-following, aligning responses with human preferences.mistralai/Mistral-Large-Instruct-2411Mistral AILarge instruction-tuned model offering strong general-purpose reasoning, summarization, and assistant-style responses.Qwen/Qwen2.5-VL-32B-InstructQwenPowerful vision-language model trained to follow multimodal instructions, suitable for image understanding, captioning, and reasoning.meta-llama/Llama-3.2-90B-Vision-InstructMeta AIVision-language model with instruction tuning, capable of image analysis, visual Q&A, and multimodal dialogue generation.BAAI/bge-multilingual-gemma2BAAIMultilingual embedding model optimized for semantic search and retrieval tasks across diverse languages.zai-org/GLM-4.6Z.AIAdvanced large-language model that expands context capacity to 200K tokens and significantly enhances coding, reasoning, and agentic capabilities. It excels in real-world coding tools, delivering more natural, human-aligned outputs.zai-org/GLM-4.7Z.AIAdvanced large-language model that retains a 200K-token context window and elevates coding, reasoning, and agentic capabilities with enhanced multi-step execution and consistency. It introduces sophisticated thinking modes like Preserved Thinking and Turn-level Thinking.moonshotai/Kimi-K2-Instruct-0905Moonshot AIA state-of-the-art mixture-of-experts (MoE) language model, featuring 32 billion activated parameters and a total of 1 trillion parameters. It delivers exceptional reasoning, coding, and content-generation performance.moonshotai/Kimi-K2-ThinkingMoonshot AIA high-performance open-source thinking model built for step-by-step thinking and dynamic tool use. It achieves state-of-the-art results on benchmarks such as Humanity’s Last Exam (HLE) and BrowseComp by dramatically scaling multi-step reasoning depth maintaining stable tool-use across 200–300 sequential calls.deepseek-ai/DeepSeek-V3.2DeepseekA LLM model that combines breakthrough efficiency with exceptional reasoning and tool-use performance. Powered by Sparse Attention and scalable RL post-training, it delivers premium long-context quality at reduced cost. Reports place it in the GPT-5 class with gold-medal wins in the 2025 IMO and IOI.\nFor a full list of models, visit the AI Models section in your dashboard.\n​Testing an AI Model\nBefore using any of our AI models in your project, you can perform real-time testing directly from the dashboard. This allows you to evaluate the model’s performance and ensure it meets your requirements.\n​How to Test an AI Model\n\nSelect a Model:\n\nNavigate to the Models tab.\nSelect the model you want to test by clicking on it.\n\nStart Testing:\n\nOn the AI model chat page, type your question or input into the centered text field.\n\nPress your Enter key or the arrow icon to submit your query.\n\nYour Daily Credits usage is shown above the request field. To view detailed model-specific usage information, visit the IO Intelligence Payments page.\n\nInteract with the Model:\n\nThe AI model will respond, starting a conversation. You can continue testing by asking additional questions or providing more input.\nCompare different models to find the one that best suits your needs.\n\n​Managing Chats\n\nView Previous Chats:\n\nOn the left, you can manage your previously created chats with different AI models.\nClick on any chat to dive deeper into the conversation.\n\nCreate or Remove Chats:\n\nCreate a new chat by clicking the + button next to the model name.\n\nRemove a chat by clicking the three-dot menu and selecting Delete. Remove unnecessary chats to keep your workspace organized.\n\n​Switching Between Models\n\nNext to the + button is a dropdown menu showing the currently selected model.\n\nClick the dropdown menu to select a different AI model and begin a new conversation with it.\n\nWas this page helpful?","tokens":1336,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258364195,"hash":"c210b2e89a3f771f5205c6ba971da0f76db7094d"}
{"url":"https://vote.optimism.io/","domain":"vote.optimism.io","title":"Optimism Agora","text":"ProposalsVotersConnect  Wallet Agora is the home of Optimism votersOP Delegates are the stewards of the Optimism Token House, appointed by token holders to make governance decisions on their behalf.All ProposalsCurrently in Voting Cycle #59\r · Ends on October 8View calendarOptimistic Proposal by The Optimism FoundationsucceededUpgrade 20 - Super Root Dispute Games & OPCM v8.0.0Ended 7:26 am Sep 16, 2026succeeded0.13% / 20% against needed to defeatOptimistically approvedOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to ...Ended 5:21 am Sep 08, 2026succeeded0.04% / 20% against needed to defeatOptimistically approvedOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard O...Ended 5:21 am Sep 08, 2026succeeded0.04% / 20% against needed to defeatOptimistically approvedOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade Proposal: Update Soneium Fee Vaults RecipientEnded 12:34 pm Aug 27, 2026succeeded0.17% / 20% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationexecutedRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundExecuted 6:30 am Aug 23, 2026executed17.97M For–10.93M AgainstOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer R...Ended 12:44 pm Jul 28, 2026succeeded0.2% / 20% against needed to defeatOptimistically approvedOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade Proposal: Swell Ownership Transfer to AltLayerEnded 12:44 pm Jul 28, 2026succeeded0.54% / 20% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationexecutedSecurity Council Operating BudgetExecuted 3:38 am Jul 21, 2026executed23.67M For–604.84K AgainstStandard Proposal by The Optimism FoundationexecutedSequencer ETH Management: 12-Month Renewal and Treasury OptimizationExecuted 12:10 am Jul 21, 2026executed24.04M For–291.3K AgainstStandard Proposal by The Optimism FoundationexecutedOperating Manual Update ProposalExecuted 7:36 am Jul 19, 2026executed22.34M For–194.48K AgainstStandard Proposal by The Optimism FoundationpassedDeveloper Advisory Board Dissolution ProposalEnded 3:55 pm Jul 15, 2026passed22.33M For–198.45K AgainstStandard Proposal by The Optimism FoundationpassedMilestones and Metrics Council Dissolution ProposalEnded 3:54 pm Jul 15, 2026passed22.94M For–195.04K AgainstStandard Proposal by The Optimism FoundationpassedGrants Council Dissolution ProposalEnded 3:54 pm Jul 15, 2026passed22.34M For–196.6K AgainstOptimistic Proposal by The Optimism FoundationsucceededUpgrade 19b - Karst HardforkEnded 2:46 pm Jun 21, 2026succeeded0.1% / 20% against needed to defeatOptimistically approvedApproval Vote Proposal by The Optimism Foundationexecuted[Second vote] Security Council Elections Cohort B MembersExecuted 1:24 am Jun 14, 2026executedSelect 8 of8 OptionsApproval Vote Proposal by The Optimism FoundationdefeatedSecurity Council Elections Cohort B MembersEnded 3:03 pm Jun 03, 2026defeatedSelect 8 of8 OptionsJoint House Optimistic Proposal by The Optimism FoundationsucceededUpgrade 19 - Stake-Based Priority Ordering ExperimentEnded 8:05 pm May 11, 2026succeeded0.37% / 17% against needed to defeatOptimistically approvedJoint House Optimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade: 18aEnded 2:28 pm Mar 25, 2026succeeded0.89% / 17% against needed to defeatOptimistically approvedJoint House Optimistic Proposal by The Optimism FoundationsucceededUpgrade 18 - Custom Gas Token v2 and Kona ProofsEnded 10:31 am Feb 03, 2026succeeded2.69% / 17% against needed to defeatOptimistically approvedJoint House Standard Proposal by The Optimism FoundationsucceededProposal to Align OP Token with Superchain SuccessEnded 12:58 pm Jan 28, 2026succeeded33.42% For–3.23% AgainstOptimistic Proposal by The Optimism FoundationsucceededSeason 9 Governance Fund Mission: Grants CouncilEnded 12:58 pm Jan 28, 2026succeeded0.6% / 20% against needed to defeatOptimistically approvedOptimistic Proposal by The Optimism FoundationsucceededSeason 9 Governance Fund Mission: Developer Advisory BoardEnded 12:58 pm Jan 28, 2026succeeded0.6% / 20% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationexecutedDAO Operating Budget Midpoint AdjustmentExecuted 4:16 am Feb 02, 2026executed29.26M For–7.76K AgainstJoint House Optimistic Proposal by The Optimism FoundationsucceededUpgrade 17 - Jovian Hardfork and Fusaka ReadinessEnded 1:49 pm Nov 19, 2025succeeded1% / 17% against needed to defeatOptimistically approvedJoint House Optimistic Proposal by The Optimism FoundationsucceededGovernor Upgrade Proposal: Onchain Controls MVPEnded 1:54 pm Nov 12, 2025succeeded0.3% / 17% against needed to defeatOptimistically approvedApproval Vote Proposal by The Optimism FoundationpassedSecurity Council Elections: Cohort A LeadEnded 3:27 pm Oct 22, 2025passedSelect 1 of1 OptionApproval Vote Proposal by The Optimism FoundationpassedSecurity Council Elections Cohort A MembersEnded 3:27 pm Oct 22, 2025passedSelect 13 of13 OptionsJoint House Optimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade: 16aEnded 3:24 pm Sep 25, 2025succeeded1.56% / 17% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationexecutedSecurity Council Season 7 Retroactive Funding RequestExecuted 5:25 pm Aug 23, 2025executed46.33M For–48.22K AgainstApproval Vote Proposal by The Optimism FoundationsucceededMilestones & Metrics Council Election: ReviewersEnded 4:44 pm Jul 30, 2025succeededSelect 10 of10 OptionsOptimistic Proposal by The Optimism FoundationsucceededS8 Governance Fund Mission: Developer Advisory BoardEnded 4:44 pm Jul 30, 2025succeeded0.9% / 20% against needed to defeatOptimistically approvedOptimistic Proposal by The Optimism FoundationsucceededS8 Governance Fund Mission: Grants CouncilEnded 4:44 pm Jul 30, 2025succeeded0.46% / 20% against needed to defeatOptimistically approvedOptimistic Proposal (Offchain) by The Optimism FoundationsucceededS8 Retro Funding Mission: Developer ToolingEnded 2:42 pm Jul 30, 2025succeeded5.1% / 20% against needed to defeatOptimistically approvedOptimistic Proposal (Offchain) by The Optimism FoundationsucceededS8 Retro Funding Mission: Onchain BuildersEnded 2:42 pm Jul 30, 2025succeeded4.57% / 20% against needed to defeatOptimistically approvedJoint House Approval Proposal by The Optimism FoundationsucceededDeveloper Advisory Board Election: MembersEnded 2:28 pm Jul 30, 2025succeededSelect 10 of10 OptionsApproval Vote Proposal by The Optimism FoundationsucceededSeason 8/9 Operating BudgetsEnded 2:28 pm Jul 30, 2025succeededSelect 4 of4 OptionsApproval Vote Proposal by The Optimism FoundationpassedGrants Council Election: OperationsEnded 2:28 pm Jul 30, 2025passedSelect 1 of1 OptionApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Election: Final ReviewerEnded 2:28 pm Jul 30, 2025succeededSelect 13 of13 OptionsStandard Proposal by The Optimism FoundationexecutedAnticapture Commission Dissolution ProposalExecuted 8:29 pm Aug 02, 2025executed53.04M For–9.47K AgainstStandard Proposal by The Optimism FoundationexecutedBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9Executed 3:51 pm Jul 12, 2025executed46.28M For–260.54K AgainstStandard Proposal by The Optimism FoundationexecutedUpgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in CannonExecuted 3:37 am Jul 13, 2025executed64.6M For–25.02K AgainstJoint House Standard Proposal by The Optimism FoundationsucceededSeason 8: Intent RatificationEnded 2:31 pm Jul 02, 2025succeeded37.05% For–0.68% AgainstJoint House Standard Proposal by The Optimism FoundationsucceededSeason 8/9 Developer Advisory Board CharterEnded 1:59 pm Jul 02, 2025succeeded35.39% For–0.72% AgainstStandard Proposal by The Optimism FoundationdefeatedGovernor Update Proposal: Removing Abstain Count from QuorumEnded 1:57 pm Jul 02, 2025defeated38.58M For–29.38M AgainstStandard Proposal by The Optimism FoundationexecutedSeason 8/9 Milestones and Metrics Council CharterExecuted 6:45 am Jul 07, 2025executed50.1M For–62.39K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 8/9 Grants Council CharterExecuted 12:07 pm Jul 06, 2025executed50.43M For–1.18M AgainstStandard Proposal by The Optimism FoundationdefeatedSeason 8 and 9 Milestone and Metrics Council SelectionEnded 1:02 pm Jun 11, 2025defeated26.04M For–25.35M AgainstOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade: Absolute Prestate Updates for Isthmus Activation & Blob Pre...Ended 1:25 pm May 01, 2025succeeded1.54% / 12% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationexecutedSeason 8 and 9: Budget Board Member RatificationExecuted 3:08 pm May 03, 2025executed52.15M For–178.84K AgainstStandard Proposal by The Optimism FoundationexecutedUpgrade Proposal #15: Isthmus Hard ForkExecuted 2:49 pm Apr 12, 2025executed55.14M For–12.23K AgainstStandard Proposal by The Optimism FoundationexecutedUpgrade Proposal #14: Isthmus L1 Contracts + MT-CannonExecuted 2:08 pm Apr 12, 2025executed55.41M For–5.09K AgainstStandard Proposal by The Optimism FoundationexecutedUpgrade Proposal #13: OPCM and Incident Response improvementsExecuted 2:04 pm Mar 22, 2025executed57.88M For–253.78K AgainstOptimistic Proposal by The Optimism FoundationsucceededMaintenance Upgrade: L1 Pectra ReadinessEnded 8:30 pm Mar 04, 2025succeeded0.68% / 12% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationpassedProtocol Upgrade: Superchain Registry 2.0Ended 1:04 pm Feb 05, 2025passed62.08M For–6.48K AgainstApproval Vote Proposal by The Optimism FoundationexecutedSecurity Council Elections Cohort B MembersExecuted 5:37 am Feb 03, 2025executedSelect 15 of15 OptionsApproval Vote Proposal by The Optimism FoundationexecutedGrants Council Operations ElectionsExecuted 5:19 pm Feb 03, 2025executedSelect 1 of1 OptionApproval Vote Proposal by The Optimism FoundationexecutedDeveloper Advisory Board Foundation Mission Team ElectionsExecuted 5:20 pm Feb 03, 2025executedSelect 3 of3 OptionsApproval Vote Proposal by The Optimism FoundationexecutedDeveloper Advisory Board Governance Mission Team ElectionsExecuted 1:16 pm Feb 02, 2025executedSelect 8 of8 OptionsApproval Vote Proposal by The Optimism FoundationexecutedDeveloper Advisory Board Audit Request Team ElectionsExecuted 5:21 pm Feb 03, 2025executedSelect 8 of8 OptionsApproval Vote Proposal by The Optimism FoundationexecutedMilestones and Metrics Council Reviewer ElectionsExecuted 5:20 pm Feb 03, 2025executedSelect 9 of9 OptionsApproval Vote Proposal by The Optimism FoundationexecutedGrants Council Final Reviewer ElectionsExecuted 4:58 am Feb 04, 2025executedSelect 7 of7 OptionsApproval Vote Proposal by The Optimism FoundationexecutedGrants Council GrantNerd ElectionsExecuted 5:21 pm Feb 03, 2025executedSelect 12 of12 OptionsStandard Proposal by The Optimism FoundationexecutedSeason 7: Chain Delegation Program AmendmentExecuted 8:48 am Feb 05, 2025executed60.48M For–10.25K AgainstStandard Proposal by The Optimism FoundationexecutedDecision Market Mission [Onchain]Executed 9:40 am Dec 22, 2024executed51.59M For–57.2K AgainstStandard Proposal by The Optimism FoundationexecutedGrants Council Mission [Onchain]Executed 10:08 am Dec 22, 2024executed51.71M For–583.28K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 7: Security Council Operating Budget [Onchain]Executed 10:10 am Dec 22, 2024executed47.47M For–38.9K AgainstStandard Proposal by The Optimism FoundationexecutedCode of Conduct Council Dissolution ProposalExecuted 10:09 am Dec 22, 2024executed52.53M For–3.44K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 7: Milestones and Metrics Council Operating BudgetExecuted 11:18 am Dec 22, 2024executed51.37M For–68.16K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 7: Developer Advisory Board Operating BudgetExecuted 9:44 am Dec 22, 2024executed52.58M For–88.6K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 7: Grants Council Operating BudgetExecuted 2:10 am Dec 23, 2024executed52.16M For–91.43K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 7: Anticapture Commission AmendmentExecuted 7:09 am Dec 23, 2024executed52.22M For–9.4K AgainstStandard Proposal by The Optimism FoundationexecutedSeason 7: Intent RatificationExecuted 4:43 am Dec 23, 2024executed48.66M For–3.86M AgainstStandard Proposal by The Optimism FoundationexecutedUpgrade Proposal #11: Holocene Network UpgradeExecuted 10:05 am Dec 22, 2024executed65.51M For–10.92K AgainstStandard Proposal by The Optimism FoundationexecutedOnchain Treasury Transfer TestExecuted 9:07 am Dec 13, 2024executed42.14M For–2.62K AgainstStandard Proposal by The Optimism FoundationsucceededSeason 6: Standard Rollup Charter RatificationEnded 1:27 pm Oct 30, 2024succeeded54.43M For–33.92K AgainstStandard Proposal by The Optimism FoundationsucceededGovernor Update Proposal #3: Enable Onchain Treasury ExecutionEnded 1:26 pm Oct 30, 2024succeeded65.57M For–1.05M AgainstApproval Vote Proposal by The Optimism FoundationsucceededRolling Mission Requests: Voting Cycle 28Ended 1:32 pm Oct 09, 2024succeededSelect 1 of1 OptionApproval Vote Proposal by The Optimism FoundationsucceededRolling Mission Requests: Voting Cycle 27Ended 1:14 pm Sep 18, 2024succeededSelect 8 of8 OptionsStandard Proposal by The Optimism FoundationsucceededRolling Mission RequestsEnded 12:50 pm Sep 18, 2024succeeded39.7M For–10.12K AgainstApproval Vote Proposal by The Optimism FoundationsucceededSecurity Council Elections Cohort A MembersEnded 12:45 pm Sep 01, 2024succeededSelect 12 of12 OptionsApproval Vote Proposal by The Optimism FoundationsucceededSecurity Council Elections: Cohort A LeadEnded 2:16 pm Aug 28, 2024succeededSelect 1 of1 OptionStandard Proposal by The Optimism FoundationsucceededUpgrade Proposal #10: Granite Network UpgradeEnded 1:24 pm Aug 28, 2024succeeded47.06M For–5.4K AgainstApproval Vote Proposal by The Optimism FoundationsucceededCode of Conduct Council ElectionsEnded 1:00 pm Aug 07, 2024succeededSelect 12 of12 OptionsApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #3A, 6M OPEnded 2:18 pm Jul 18, 2024succeededSelect 22 of22 OptionsApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #3B, 12M OPEnded 1:09 pm Jul 18, 2024succeededSelect 1 of1 OptionApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #1, 500k OPEnded 1:09 pm Jul 18, 2024succeededSelect 10 of10 OptionsApproval Vote Proposal by The Optimism FoundationsucceededDeveloper Advisory Board ElectionsEnded 4:22 pm Jun 19, 2024succeededSelect 16 of16 OptionsStandard Proposal by The Optimism FoundationsucceededSeason 6: V2. Code of Conduct Council RenewalEnded 3:09 pm Jun 19, 2024succeeded33.41M For–7.71M AgainstStandard Proposal by The Optimism FoundationsucceededChain Delegation Program AmendmentEnded 3:09 pm Jun 19, 2024succeeded41.5M For–3.42M AgainstStandard Proposal by The Optimism FoundationsucceededAnticapture Commission AmendmentEnded 3:09 pm Jun 19, 2024succeeded44.54M For–2.01K AgainstApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Reviewer Elections: Audit ReviewerEnded 3:09 pm Jun 19, 2024succeededSelect 4 of4 OptionsApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Reviewer Elections: Milestones and Metrics ReviewerEnded 3:09 pm Jun 19, 2024succeededSelect 6 of6 OptionsApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Reviewer Elections: Mission ReviewerEnded 3:09 pm Jun 19, 2024succeededSelect 22 of22 OptionsStandard Proposal by The Optimism FoundationsucceededUpgrade Proposal #9: Fjord Network UpgradeEnded 3:09 pm Jun 19, 2024succeeded54.7M For–1.26K AgainstStandard Proposal by The Optimism FoundationsucceededSeason 6: Intent BudgetsEnded 3:07 pm May 29, 2024succeeded48.49M For–717.55K AgainstStandard Proposal by The Optimism FoundationsucceededSeason 6: Grants Council Operating BudgetEnded 2:54 pm May 29, 2024succeeded48.83M For–152.5K AgainstApproval Vote Proposal by The Optimism FoundationsucceededSeason 6: Developer Advisory Board RenewalEnded 2:54 pm May 29, 2024succeededSelect 2 of2 OptionsStandard Proposal by The Optimism FoundationsucceededSeason 6: Intents RatificationEnded 2:05 pm May 29, 2024succeeded49.55M For–60.55K AgainstStandard Proposal by The Optimism FoundationdefeatedSeason 6: Code of Conduct Council RenewalEnded 2:05 pm May 29, 2024defeated17.01M For–29.82M AgainstStandard Proposal by The Optimism FoundationsucceededGovernor Update Proposal #2: Improvements to advanced delegation allowance calcu...Ended 2:05 pm May 29, 2024succeeded60.71M For–5.17K AgainstStandard Proposal by The Optimism FoundationsucceededProtocol Upgrade #8: Changes for Stage 1 DecentralizationEnded 2:05 pm May 29, 2024succeeded60.42M For–146.23K AgainstStandard Proposal by The Optimism FoundationsucceededProtocol Upgrade #7: Fault ProofsEnded 2:05 pm May 29, 2024succeeded58.4M For–143.93K AgainstStandard Proposal by The Optimism FoundationsucceededGovernor Upgrade #1: Improve advanced delegation votingEnded 4:06 pm Apr 17, 2024succeeded54.32M For–1.63K AgainstStandard Proposal by The Optimism FoundationsucceededSeason 5 : Intents Budget Proposal #2Ended 3:43 pm Apr 17, 2024succeeded38.31M For–41.43K AgainstStandard Proposal by The Optimism FoundationsucceededProtocol Upgrade #6: Multi-Chain Prep (MCP) L1Ended 3:51 pm Mar 06, 2024succeeded35.28M For–4.13K AgainstStandard Proposal by The Optimism FoundationsucceededProtocol Upgrade #5: Ecotone Network UpgradeEnded 3:51 pm Mar 06, 2024succeeded39.15M For–2.12K AgainstStandard Proposal by The Optimism FoundationsucceededProtocol Upgrade #4Ended 7:17 pm Feb 14, 2024succeeded58.16M For–1.82K AgainstApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #4, 1.33M OPEnded 7:17 pm Feb 14, 2024succeededSelect 10 of10 OptionsApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #3, 1.33M OPEnded 7:17 pm Feb 14, 2024succeededSelect 13 of13 OptionsApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #2, 4M OPEnded 7:17 pm Feb 14, 2024succeededSelect 14 of14 OptionsApproval Vote Proposal by The Optimism FoundationsucceededMission Requests: Intent #1, 1.33M OPEnded 7:17 pm Feb 14, 2024succeededSelect 6 of6 OptionsOptimistic Proposal by The Optimism FoundationsucceededSummary of Code of Conduct enforcement decisionsEnded 1:45 pm Jan 24, 2024succeeded2.41% / 12% against needed to defeatOptimistically approvedStandard Proposal by The Optimism FoundationsucceededProposal to Reclassify Grant Misusage EnforcementEnded 1:43 pm Jan 24, 2024succeeded43.92M For–3.48M AgainstStandard Proposal by The Optimism FoundationsucceededUpgrade Proposal #3: Delta Network UpgradeEnded 1:36 pm Jan 24, 2024succeeded47.97M For–17.44K AgainstStandard Proposal by The Optimism FoundationsucceededUpgrade #2: Canyon Protocol UpgradeEnded 1:20 pm Dec 06, 2023succeeded48.7M For–12.22K AgainstStandard Proposal by The Optimism FoundationsucceededRatify Security Council MembersEnded 1:17 pm Dec 06, 2023succeeded36.69M For–40.79K AgainstApproval Vote Proposal by The Optimism FoundationsucceededCode of Conduct Council: Member NominationsEnded 2:29 pm Nov 15, 2023succeededSelect 8 of8 OptionsStandard Proposal by The Optimism FoundationsucceededSeason 5 Intent BudgetsEnded 2:01 pm Nov 15, 2023succeeded46.93M For–83.51K AgainstStandard Proposal by The Optimism FoundationsucceededChain Delegation ProgramEnded 2:01 pm Nov 15, 2023succeeded43.44M For–162.27K AgainstStandard Proposal by The Optimism FoundationsucceededRatification of Law of ChainsEnded 2:01 pm Nov 15, 2023succeeded45.78M For–53.85K AgainstApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Reviewer Elections: BuildersEnded 2:01 pm Nov 15, 2023succeededSelect 10 of10 OptionsApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Reviewer Elections: Growth ExperimentsEnded 2:01 pm Nov 15, 2023succeededSelect 11 of11 OptionsApproval Vote Proposal by The Optimism FoundationsucceededGrants Council Reviewer Elections: Milestones and MetricsEnded 2:01 pm Nov 15, 2023succeededSelect 9 of9 OptionsStandard Proposal by The Optimism FoundationsucceededAnticapture CommissionEnded 2:15 pm Oct 25, 2023succeeded43.58M For–2.54M AgainstStandard Proposal by The Optimism FoundationsucceededDeveloper Advisory Board BudgetEnded 2:15 pm Oct 25, 2023succeeded45.21M For–116.95K AgainstStandard Proposal by The Optimism FoundationsucceededRatify Developer Advisory Board MembersEnded 2:15 pm Oct 25, 2023succeeded44.93M For–45.29K AgainstStandard Proposal by The Optimism FoundationsucceededGrants Council Operating BudgetEnded 2:15 pm Oct 25, 2023succeeded45.94M For–62.51K AgainstStandard Proposal by The Optimism FoundationsucceededCode of Conduct Council BudgetEnded 2:15 pm Oct 25, 2023succeeded41.72M For–2.42M AgainstStandard Proposal by The Optimism FoundationsucceededSecurity Council: Vote #1Ended 2:15 pm Oct 25, 2023succeeded46.18M For–49.92K AgainstStandard Proposal by The Optimism FoundationdefeatedCode of Conduct Violation: Carlos MelgarEnded 2:15 pm Oct 25, 2023defeated2.25M For–15.22M AgainstStandard Proposal by The Optimism FoundationsucceededIntent 2 Budget Proposal 2Ended 2:50 pm Aug 17, 2023succeeded20.63M For–48.6K AgainstApproval Vote Proposal by The Optimism FoundationsucceededIntent #4, 3M OPEnded 5:29 pm Jul 13, 2023succeededSelect 14 of14 OptionsApproval Vote Proposal by The Optimism FoundationsucceededIntent #3, 1M OPEnded 5:25 pm Jul 13, 2023succeededSelect 11 of11 OptionsApproval Vote Proposal by The Optimism FoundationsucceededIntent #1, 1M OPEnded 5:16 pm Jul 13, 2023succeededSelect 6 of6 OptionsApproval Vote Proposal by The Optimism FoundationdefeatedIntent #1, 1M OPEnded 4:44 pm Jul 13, 2023defeatedSelect 6 of6 OptionsApproval Vote Proposal by The Optimism FoundationdefeatedIntent #1, 1M OPEnded 4:20 pm Jul 13, 2023defeatedSelect 6 of6 OptionsApproval Vote Proposal by The Optimism FoundationsucceededCouncil Reviewer Elections: Growth Experiments GrantsEnded 11:57 pm May 18, 2023succeededSelect 7 of7 OptionsApproval Vote Proposal by The Optimism FoundationsucceededCouncil Reviewer Elections: Builders GrantsEnded 11:57 pm May 18, 2023succeededSelect 4 of4 OptionsStandard Proposal by The Optimism FoundationsucceededTreasury Appropriation (Foundation Year 2 Budget Approval)Ended 9:34 pm May 18, 2023succeeded14.21M For–5.33M AgainstStandard Proposal by The Optimism FoundationsucceededInflation Adjustment ProposalEnded 9:34 pm May 18, 2023succeeded20.02M For–53.77K AgainstStandard Proposal by The Optimism FoundationsucceededProtocol Delegation Program RenewalEnded 10:44 pm Apr 27, 2023succeeded22.27M For–2.57M AgainstStandard Proposal by The Optimism FoundationsucceededIntent #1 Budget ProposalEnded 10:44 pm Apr 27, 2023succeeded25.86M For–37.39K AgainstStandard Proposal by The Optimism FoundationsucceededIntent #2 - Council Intent Budget ProposalEnded 10:44 pm Apr 27, 2023succeeded25.81M For–18.62K AgainstStandard Proposal by The Optimism FoundationsucceededIntent #3 Budget ProposalEnded 10:44 pm Apr 27, 2023succeeded23.85M For–19.24K AgainstStandard Proposal by The Optimism FoundationsucceededIntent #4 Budget ProposalEnded 10:44 pm Apr 27, 2023succeeded25.88M For–17.37K AgainstStandard Proposal by The Optimism FoundationsucceededUpgrade Proposal: Bedrock - This proposal outlines the Optimism Collective’s fir...Ended 12:49 am Mar 24, 2023succeeded27.94M For–37.22K AgainstStandard Proposal by The Optimism FoundationsucceededDelegate Suspension: Fractal Visions - All Optimism Delegates are bound by the d...Ended 12:36 am Mar 24, 2023succeeded19.04M For–15.1K AgainstStandard Proposal by The Optimism Foundationtest: succeededTest Vote 3: All Together Now -- Come try out the new vote.optimism.io!Ended 7:34 pm Feb 08, 2023test: succeeded8.27M For–125.59K AgainstGovernance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":6123,"squid":"ink-governance","role":"Council Listener","at":1791258364325,"hash":"77d63029e4dcd85188ca19bbe634dd27cd830c27"}
{"url":"https://ethresear.ch/t/towards-native-post-quantum-private-eth/25291/7","domain":"ethresear.ch","title":"Towards Native Post-Quantum Private ETH - Privacy - Ethereum Research","text":"Privacy\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n Jun 24\n\n 7 / 8\n\n Jun 25\n\n Jun 29\n\n post by Pierre on Jun 24\n\n Pierre\n\n Thanks to @winderica, @mmjahanara, Kenny Paterson, Varun Maram and @keewoolee for their valuable suggestions and feedbacks.\nBeyond HNDL\nThe L1 strawmap laid out a path listing L1-native private post-quantum (pq) transfers as a north star. Today, production-deployed privacy solutions rely on elliptic curve-based primitives or on unsatisfactory hardware assumptions. Some argue that, as of now, protecting against harvest-now-decrypt-later (HNDL) attacks is enough for private transfer protocols. However, the deployment of a cryptographically relevant quantum computer means adversaries would be able to carry out undetectable attacks resulting in a catastrophic loss of funds. In that situation, any recovery mechanism (such as turnstiles) will likely require important social layer coordination, provided users’ trust in the protocol isn’t permanently damaged.\nThis post tries to succinctly lay out the kind of cryptographic work we would have to do to enshrine pq privacy in the L1. It is not straightforward: a look at Sapling’s (~620k shielded ZEC, approx $250m in value at today’s price) choices regarding its primitives’ instantiation illustrates why protecting users from HNDL attacks or simply switching proof systems falls short of accurately describing what work is required to deliver pq shielded ETH.\nPreparing for a pq turnstile while using classical cryptographic primitives would not be enough. A turnstile is an inherently reactive, non-retroactive and non-preventive technique that doesn’t fend off an attacker’s ability to destroy the coin’s value. Turnstiles also take time and won’t ever really be completed: it will only be many years later that users can be probabilistically confident that counterfeiting didn’t take place. On top of this, turnstiles greatly impact users by deactivating their ability to transact. They are, all in all, an inherently social-layer defense mechanism, impeding a genuine walk-away from the protocol.\n\nUsage\nPrimitive\nSecurity Requirement\nInstantiation\n\nEncrypting Note Plaintexts\nAsymmetric Encryption\nIND-CCA2 and IK-CCA2\n DHAES\n\nSpend Authorization\nRe-Randomizable Signature\nSURK-CMA\n RedDSA on Jubjub\n\nNon-Inflation (and Non-Malleability)\nSignature with Signing Key to Validating Key Monomorphism\nNon-Adaptive SU-CMA, Key Monomorphic\n RedDSA on Jubjub\n\nCommitting to Notes\nCommitment Scheme\nBinding and Hiding\n Windowed Pedersen Commitments (hiding is ok)\n\nCommitting to Values\nLinearly Homomorphic Commitment Scheme\nBinding and Hiding\n Homomorphic Pedersen Commitments (hiding is ok)\n\nDiversified Addresses\nDiversify Hash\nUnlinkability\n Group Hash Jubjub Curve\n\nProofs\nSNARK\nStatistical Zero-Knowledge (zk), Completeness, Knowledge Soundness\n Groth16 on BLS12-381 (zk is ok)\n\nA non-exhaustive table of ZCash’s Sapling pq readiness. It applies to Orchard, which changed Sapling’s proof system (Halo2, Pasta Curves), key material derivation and nullifiers computation formulas, but is soon to be deprecated.\nIn this post, we will only consider the case of dealing with a quantum adversary. We will evaluate solutions to statelessness compatibility and the verification cost problem in a separate writeup.\nProof Systems\nHash-based proof systems are getting to a point where they are both fast and well-understood. Not leveraging lattice-based ones means that our shielded pool protocol will probably not provide users with the ability to prove their final balance output using snark-friendly lattice-based homomorphism, including the ability to do proof parallelization.\nThis is however fine. Proof parallelization was indeed conceived as a way to overcome join-split statements’ inadequacy for note consolidation or sending to multiple recipients. Today, progress in hash-based SNARKs (WHIR, STIR) offer the ability to prove bigger circuits and depart from a traditional two inputs/outputs setup rendering such proof parallelization strategies less relevant. Thus, a battle-tested join-split zkSNARK statement enforcing checks on notes’ Merkle paths and commitments, input/output values, nullifiers derivation and spend auth signature validity should get us to the core required functionalities, with an on-par UX compared to existing protocols.\nThe instantiation of this statement depends critically on the choice of hash function for nullifiers and note commitments. There are different SNARK-friendly hash candidates to use. Recent research on Poseidon indicates that we should be cautious and would need some more cryptanalysis research to integrate it (see here and here). Other options include using less arithmetization-friendly hashes, such as BLAKE3.\nSecret Distribution\nEncryption\nTransaction detection corresponds to receivers being able to detect public ciphertexts addressed to them. We should make sure that it is DoS-resistant, provides unlinkability, minimizes trust points and remains practical on resource-constrained devices. The main task will be to swap a key agreement (KA) for a key encapsulation mechanism (KEM) (the two differ with how randomness is contributed in the shared key material generation algorithm). Today, the NIST PQC process only standardized KEMs, leaving pq KA aside.\nKyber is our leading KEM candidate. However, until relatively recently, cryptography had to establish its anonymity (aka ANO-CCA, an adversary cannot determine to which recipient an encapsulated key is destined) and that of the PKE scheme derived from it in a pq setting. Kyber initially had a more complex Fujisaki-Okamoto (FO) transform using nested hashing. However, NIST eventually decided to simplify it, easing researcher’s ability to establish its ANO-CCA security. Research eventually showed that one can obtain an ANO-CCA security proof even for nested hashing. All in all, the current NIST standard ML-KEM does provide an anonymous and robust PKE, by composing with an appropriate DEM in the KEM-DEM paradigm.\nOrthogonal but going hand in hand with anonymity, the scheme used for secret distribution also needs to satisfy robustness, making it possible for a party to decide it is the ciphertext’s intended recipient, i.e. providing assurance that trial decryption doesn’t err. This isn’t a natural property. For instance, it was shown that for any plaintext m𝑚, it is possible to build a ciphertext c𝑐 such that c𝑐 decrypts to m𝑚 under any Classic McEliece private key. However, the situation is less dire here, since ML-KEM has been found to be robust.\nNote that this only settles the encryption side of HNDL attacks: a complete defense would require note commitments and nullifiers to be instantiated with quantum secure primitives.\nHybrid Schemes\nHybrid cryptographic schemes combining classical and post-quantum algorithms will most likely be required initially to take a conservative security stance to build the asymmetric encryption scheme used to distribute secrets (likely an “hybrid” public key encryption scheme, here in the sense of combining an asymmetric key exchange protocol and a symmetric encryption scheme). We will have flexibility along a few axes: pure pq vs. hybrid (e.g. combining ML-KEM with a traditional ECDH group), CFRG-defined vs. NIST-defined elliptic curves, different security levels (NIST category 3 vs. category 5). The symmetric encryption part should stay similar to what it is today, although we should evaluate whether we would like to use longer key lengths.\nDecryption\nThere remains, however, the question of privacy-preserving protocols’ decryption trilemma: anonymity, low latency and small bandwidth usage. Switching to pq schemes makes this trilemma even more relevant.\nA north star would remain deploying oblivious message retrieval (OMR) at scale. Such constructions are quantum secure, but clue (i.e. the required on-chain costs) and detection key sizes are already too high to make up a credible L1 candidate. Also, server costs remain the dominant bottleneck even for SOTA constructions, making it unclear how to leverage such techniques in the near term. There is the option to split detection from retrieval using Oblivious Message Detection (OMD, a restricted version of OMR for obliviously retrieving indices) coupled with PIR to fetch payloads. Splitting those two tasks would relieve servers from running OMR’s intensive compute requirement. Still, combining the two wouldn’t reduce the clue size today.\nOne potential avenue would be to leverage fuzzy message detection (FMD) algorithms. They provide a non-negligible improvement over naive scanning, with much lower compute requirements while keeping a small clue size. However, pq versions of FMD require clues with sizes an order of magnitude larger. Also, this overhead comes at the price of only modest probabilistic privacy guarantees, as FMD is also prone to a variety of statistical attacks. Other recent approaches, such as tag-indexing in Aztec or channels in the Starknet privacy layer, sequentially index transactions between two parties using a shared secret, keeping all subsequent exchanges unlinkable. The limitation is that the initialization step requires revealing that Alice intends to interact with Bob.\nNote that there is always the option to fall back on out-of-band channels for sending ciphertexts, which makes it possible to remove them from the transaction entirely.\nSo, in a pq context, there might not be anything better than using trial decryption today. Even in a classical context, most privacy-preserving protocols today use a flavour of trial decryption coupled with authentication tags. To decrease bandwidth costs, ZCash light clients download compactly formatted transactions to synchronize their state using trial-decryption. To provide anonymity, upon detecting intended transactions users are then recommended to insert decoy requests alongside the correct, queried ones. In the case of Ethereum, when coupled with PIR and network anonymity, this path might be the best pq solution for the trilemma today.\nSignatures\nIn the case of a malleable zkSNARK, we might need to require an ephemeral keypair to sign the hash of the transaction, binding it to the zkSNARK statement. The nice thing is that non-adaptive strong-unforgeability under chosen message attack (SU-CMA) security is ok, since the signature is one-time. Also, the binding signature doesn’t require in-circuit verification, such that we can probably use a lattice-based scheme with a much smaller signature size compared to hash-based ones (or even a one-time hash-based signature if we really don’t want to use lattices).\nFor the spending authority scheme, the choice of the signature scheme is constrained by the hardware wallets that must produce these signatures in practice. Some actually proposed to opt for proof knowledge of a pre-image of some hash, sparing us from arithmetizing signatures and deciding which scheme to go with. It is, however, unclear whether tomorrow’s wallet infrastructure will support and standardize proving a recursive pq zkSNARK and whether the particular scheme will be compatible with what’s enshrined on the L1. This would also mean getting rid of all the wallet hardening work that has been done over the years, including the different attack vectors that generating signatures on hardware wallets implies.\nOn statefulness, note that most hardware wallets come with non-volatile memory and are able to support both stateful and stateless signatures. Stateful designs provide shorter signatures and potential optimizations. However, statefulness introduces a handful of problems when the signer isn’t signing at regular, predictable intervals. Users need to back up their keys, but using backups leads to state reuse and enables forgeries.\nThere are a number of stateless, hash-based signature schemes that could be amenable to being snarkified, including research being done for Bitcoin in this regard. One option would be to use SPHINCS+ with a parameter set that offers a small signature verification budget. One particularly interesting parameter set would be to reuse the one that’s being laid out for firmware signing, something that inspired the design of SPHINCS-.\nThere could also be a trick to use many times the key pair of a one-time signature (OTS) scheme. Consider a perfectly hiding zkSNARK. Since the OTS is kept hidden inside the zkSNARK as part of the witness, forging a spend proof reduces to producing a valid OTS on a fresh transaction hash without knowledge of the secret key, which remains hard as long as no OTS is ever exposed outside the circuit. It however implies a different threat model requiring the spend auth signature to never be exposed to protect both privacy and loss of funds.\nKey Material\nIt is possible to design key material using Pseudo Random Functions (PRFs) only. Chosen adequately, such PRFs are quantum secure. This was, for instance, the strategy of Sprout, an early version of the ZCash protocol. Lattice-based primitives might be helpful for re-designing diversified address functionality, although it remains unclear how such a design would work in practice and how compatible it would be with a hash-based proof system.\nHardening\nSince ETH secures billions in value, we avoided discussing exotic primitives enabling things like private shared state. Our rationale for not considering more involved cryptography and functionalities is threefold: we would like to (1) design our protocol with a walkaway in mind, (2) facilitate any downstream formal verification effort and (3) re-use already understood and production deployed primitives securing billions in value today.\nAnother additional guard to consider would also consist in designing a progressive pool uncapping. Defined at the protocol level, that progressive uncapping would consist in gradually increasing deposit amounts to minimize catastrophic size losses in the early days of the enshrined pool’s life.\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n post by 71104 on Jun 24\n\n 71104\n\nWhat if post-quantum Ethereum doesn’t need signatures at all?\n\n post by Pierre on Jun 25\n\n Pierre\n\n Compared to a “regular” transaction, the spend auth scheme isn’t the only thing you need in the context of a private transfer protocol (e.g. showing your spent notes actually exist and that their derived nullifiers are correct).\nIf you go down the path of using a zkSTARK for authorizing the spend, you end up pretty much with two choices: either recursively verifying this spend auth proof in another proof on the user’s device or generating the whole private transfer statement proof on the hardware wallet itself.\nTo me, both paths aren’t really viable, both in terms of current and future hardware wallet performance and standardization.\n\n post by 71104 on Jun 25\n\n 71104\n\nRecursive aggregation is not a problem: WHIR makes for very small proofs, the WHIR circuit is relatively simple.\nRecursion is not the only way to aggregate zkSTARKs, you can also batch them at the PCS level.\nI don’t see why you’d have to verify zkSTARKs on a user device but that’s fine, WHIR verification takes microseconds. In fact, WHIR proofs are typically much smaller (<1KiB) than Falcon or Dilithium or whatever PQ signature scheme.\nThe non-standard aspect is a real problem but account abstraction will make it optional and devices will adapt over time. MetaMask supports plugins called snaps, implementing a stop-gap solution is relatively easy.\n\n post by Pierre on Jun 25\n\n Pierre\n\n I’m not pointing out recursion to be a problem. Rather, that designing a zkSTARK to be generated on a hardware wallet for the spend auth scheme isn’t really a good use of time.\nHardware wallets already have a bunch of work related to porting pq signatures. Generating such proofs introduces new performance problems and attack vectors that vendors might not be keen on investigating today. Assuming that devices will adapt over time is opening the door to many issues.\nWorking on circumventing pq signatures limitations has a much better case. Pretty good and standardized solutions exist already, such as using a stateless scheme with a parameter set used for firmware signing or just leveraging an OTS.\n\n post by 71104 on Jun 25\n\n 71104\n\n You’re basically arguing for legacy drag to block all innovation. That works until someone who knows better goes all-in on innovation and beats you with smaller proofs and higher scalability.\n\n post by rdubois-crypto on Jun 26\n\n rdubois-crypto\n\n I gently disagree about the fact that the HW has to compute the proof: spending and proving might be separated. There is no real sense to require proving in the HW, cause if the host is compromised, privacy will be compromised by a thousand other ways. A corrupted prover cannot spend your funds in Zcash/RG systems.\nI fully agree that the real problem is the succinctness that will require aggragation/L2 like system. And it is unlikely (I don’t know any searchers thinking we might) that a way to achieve it with hash based or Lattices is ever found.\n\n post by Pierre on Jun 29\n\n Pierre\n\nYes I agree, it does require thinking about recursion or aggregation. I’m not too pessimistic though! On the hash based side of things, the work done by the LeanVM team is a cool direction which could be nice to piggy back on. We also investigated WARP and worked on an implementation here. I’m less familiar with what’s being done using lattice-based primitives.\n\n Powered by Discourse","tokens":4382,"squid":"ink-research","role":"Deep Scholar","at":1791258391956,"hash":"4457ae4e9582a14b4ac86087891cde25e5dce01f"}
{"url":"https://docs.pyth.network/price-feeds/core/create-tradingview-charts","domain":"docs.pyth.network","title":"Create TradingView Charts | Pyth Developer Hub","text":"Pyth CoreCreate TradingView ChartsLearn how to build TradingView charts powered by Pyth price feedsThe TradingView integration allows users to view Pyth prices on their own website. All Pyth prices made available through the TradingView integration are originating from Pythnet.\nPyth Core was upgraded on August 26, 2026We recommend new integrations use the upgraded contract addresses.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nBenchmarks TradingView endpoints are retiredThe Benchmarks /v1/shims/tradingview/* endpoints were retired as part of the Pyth Core upgrade on August 26, 2026 at 16:00 UTC. Charting integrations must move to the Pyth Pro History API, which implements the same TradingView UDF specification. See the deprecation notice for the full list.\nChoosing an Implementation Method for TradingView Integration\nThere are primarily two methods to integrate TradingView with your website to display Pyth prices:\n1. Using the TradingView Widget\n\nAdvantages:\n\nSimplicity: This is a plug-and-play solution which allows for quick integration. You won't need to engage in complex setup processes or handle any backend configurations.\n\nDisadvantages:\n\nLimited Customization: The widget comes as-is, and while you can change basic parameters like the symbol or theme, more advanced customizations are restricted.\n\n2. Using the Datafeed URL with Charting Library\n\nAdvantages:\n\nDeep Customization: Suited for those who need a deeper level of integration and customization. By utilizing the UDF-compatible URL, you can tailor the look, feel, and functionality of the chart to better fit your application's needs.\n\nDisadvantages:\n\nAdded Complexity: Integrating the Charting Library requires more technical know-how and potentially more time compared to the simpler widget integration.\n\nWhen deciding between the two, consider the user experience you want to provide, the technical expertise at hand, and the time you can allocate to the integration. For a rapid deployment with minimal adjustments, the TradingView Widget is the way to go. If you need more control and are prepared for a deeper dive into the implementation, the Datafeed URL with the Charting Library would be your best choice.\nTradingView Widget\n\nAdd the following script(s) from TradingView to your website depending on your framework:\n\n<!-- TradingView Widget BEGIN -->\n<div class=\"tradingview-widget-container\">\n <div id=\"tradingview\"></div>\n <script\n type=\"text/javascript\"\n src=\"https://s3.tradingview.com/tv.js\"\n ></script>\n <script type=\"text/javascript\">\n new TradingView.widget({\n autosize: true,\n symbol: \"PYTH:BTCUSD\",\n interval: \"D\",\n timezone: \"Etc/UTC\",\n theme: \"light\",\n style: \"1\",\n locale: \"en\",\n toolbar_bg: \"#f1f3f6\",\n enable_publishing: false,\n allow_symbol_change: true,\n container_id: \"tradingview\",\n });\n </script>\n</div>\n<!-- TradingView Widget END -->\n\nReplace the symbol parameter with the Pyth symbol you want to display. For example, to display the price of Ethereum, use symbol: \"PYTH:ETHUSD\".\n\nReplace the interval parameter with the time interval you want to display. For example, to display the price of Ethereum in 1-minute intervals, use interval: \"1\". Possible resolutions are daily (D or 1D, 2D ... ), weekly (1W, 2W ...), monthly (1M, 2M...) and an intra-day resolution – minutes(1, 2 ...).\n\nReplace the timezone parameter with the timezone you want to display. For example, to display the price of Ethereum in the Eastern Time Zone, use timezone: \"America/New_York\".\n\nReplace the theme parameter with the theme you want to display. For example, to display the price of Ethereum in dark mode, use theme: \"dark\".\n\nThere is a fully working open-source example of the TradingView integration by one of Pyth's contributors here. The example application is deployed here.\n\nNote: The TradingView plug-and-play widget does not allow for much customization. If you want to customize the widget, you can use the TradingView Charting Library. Please see the next section for more details.\nUsing Datafeed URL with Charting Library\nWe also provide a UDF-compatible URL that follows the TradingView UDF spec. You can implement your own datafeed utilizing the API or use the built-in UDF adapter with the API. If you need a step-by-step guide, refer to the How to connect data via Datafeed API tutorial, or you can reference the example here, the main files that may be of interest are: datafeed.js and streaming.js.\nThe datafeed URL is here and documentation can be found here\nExample\n\nSymbol Info: https://benchmarks.pyth.network/v1/shims/tradingview/symbol_info\nHistory: https://benchmarks.pyth.network/v1/shims/tradingview/history?symbol=Crypto.ETH/USD&resolution=1&from=1690338541&to=1690338741\nStream of prices: https://benchmarks.pyth.network/v1/shims/tradingview/streaming\nConfig: https://benchmarks.pyth.network/v1/shims/tradingview/config\nSymbols: https://benchmarks.pyth.network/v1/shims/tradingview/symbols?symbol=Crypto.BTC/USD\nSearch: https://benchmarks.pyth.network/v1/shims/tradingview/search?query=bitcoin\nUsing GelatoAutomate Pyth price updates with Gelato Web3 FunctionsDerive Cross RateLearn how to derive synthetic cross rates using Pyth price feeds","tokens":1316,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258391987,"hash":"18b15e8b853e95c274c93ed199cfa3273b8f9911"}
{"url":"https://docs.pyth.network/price-feeds/core/use-real-time-data/push-integration","domain":"docs.pyth.network","title":"Push Integration | Pyth Developer Hub","text":"Pyth CoreUse Real-Time Price DataPush IntegrationHow to use Pyth push feeds across supported ecosystemsThis guide explains how to read real-time Pyth prices using push integration across supported ecosystems.\nCheck Feed AvailabilityEnsure the feeds your application needs are already updated on-chain. Review\nthe push feeds list, request coverage through\nthe update request form, or operate a Price\nPusher to\npublish updates yourself.\nEVM\nDevelopers on EVM chains can read prices directly from the Pyth oracle contract using push feeds.\nPythStructs.Price memory price = pyth.getPriceNoOlderThan(priceFeedId, 60);\nProvide the price feed ID from the push feeds list.\nSample contract\npragma solidity ^0.8.0;\n\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\ncontract SomeContract {\n IPyth pyth;\n\n /**\n * @param pythContract The address of the Pyth contract\n */\n constructor(address pythContract) {\n // The IPyth interface from pyth-sdk-solidity provides the methods to interact with the Pyth contract.\n // Instantiate it with the Pyth contract address from https://docs.pyth.network/price-feeds/core/contract-addresses/evm\n pyth = IPyth(pythContract);\n }\n\n /**\n * This method is an example of how to interact with the Pyth contract using Push Integration.\n */\n function exampleMethod() public {\n // Read the current price from a price feed if it is less than 60 seconds old.\n // Each price feed (e.g., ETH/USD) is identified by a price feed ID.\n // The complete list of feed IDs is available at https://docs.pyth.network/price-feeds/core/price-feeds\n bytes32 priceFeedId = 0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace; // ETH/USD\n PythStructs.Price memory price = pyth.getPriceNoOlderThan(priceFeedId, 60);\n }\n}\n\nSVM\nDevelopers on Solana and related ecosystems can use price feed accounts to consume push feeds. See the\nSolana integration guide for implementation details.TONPrevious PageUse Historical Price Data (Benchmarks)Learn how to query and verify historical Pyth price feeds","tokens":516,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258402174,"hash":"7cad0275203794047bfcf07a55659d94959c6f1d"}
{"url":"https://ethresear.ch/t/read-this-before-posting/8","domain":"ethresear.ch","title":"Read this before posting - Administrivia - Ethereum Research","text":"Read this before posting \n\n Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Aug 2017\n\n 1 / 14\n\n Aug 2017\n\n Aug 19\n\n post by system on Aug 17, 2017\n\n system\n\n This is a semi-public forum for participating in Ethereum’s research efforts, including but not limited to:\n\nProof-of-Stake\nPost Quantum\nZero-Knowledge work\nScaling solutions\nEVM improvements\nLow-level protocol improvements\nEconomics\n\nprotocol economics\nResource pricing economics\n\nOther second-level features\nAnything on the Ethereum roadmap.\n\nUseful sites\n\nEthereum.org research\nEthereum roadmap\n\nThis is not the place for:\n\ngeneric ethereum discussion. For that visit r/ethereum.\ndiscussing specific EIPs. For that visit the Ethereum Magicians forum.\ntechnical questions and ELI5s. For that visit the StackExchange.\ncore documentation. See ethereum.org developer docs.\n\nEthereum is a decentralized and permissionless platform, but this bulletin board is a centralized and permissioned platform. Just how it is. If your signal-to-noise ratio gets too low, you will be banned from ethresear.ch. So please keep discussions information-rich. Posting on this site is accepting releasing your submitted content into the public domain (CC0).\nTo both reduce spam and help new users get a sense of community norms, newly created accounts cannot immediately make posts. You have to click and read around a bit around before you are able to post.\nForum Features!\n1. LaTeX Equations\nThis forum supports \\LaTeX𝐿𝐴𝑇𝐸𝑋 equations between $dollar signs$. The default LaTeX style is the “inline” style which looks like \\sum_{k=0}^n {n \\choose k} = 2^n ∑𝑛𝑘=0(𝑛𝑘) =2𝑛, in text this is\n$ \\sum_{k=0}^n {n \\choose k} = 2^n $\n\nHowever, if you start your equation with $$ on it’s own beginning and teminating line like,\n$$\n\\sum_{k=0}^n {n \\choose k} = 2^n\n$$\n\nit looks like this\n\n\\sum_{k=0}^n {n \\choose k} = 2^n\n𝑛∑𝑘=0(𝑛𝑘)=2𝑛\n\n2. Graphviz diagrams\nSee the documentation for a list of examples to build your graph.\n[graphviz engine=dot]\ndigraph {\n concentrate=true;\n a[color=red, style=filled, fillcolor=pink];\n b[shape=diamond];\n a -> b;\n b -> c;\n c -> a;\n d -> c;\n e -> c;\n e -> a;\n a -> e;\n}\n[/graphviz]\n\n3. YUML diagrams\nYUML diagrams allow making nice little graphs within your posts.\nThey have an idiosyncratic but fairly simple markup language.\nExample:\n\n[yuml]\n[foo{bg:cornsilk}]--[baz]\n[foo]->[bar{bg:orange}]\n[baz]-.->[qux]\n[qux]--label>[bar]\n[/yuml]\n\n%5BVote%20Message%7C+Source%20hash;-Source%20height;+Target%20hash;-Target%20height%7C+Withdraw();+Last_commit%5D.svg118×158 238 KB\n[yuml]\n[Vote Message|+Source hash;-Source height;+Target hash;-Target height|+Withdraw();+Last_commit]\n[/yuml]\n\n4. Images!\nUnsurprisingly, we also support images.\nu1614×800 57.9 KB\n\n Is this desk lacking administration?\n\n 3\n\n 3\n\n 8 years later\n\n post by captnbli on Jan 4\n\n captnbli\n\n My issue is I can’t post a new topic, having just joined, which is what I want to do, And how I achieve that is not explained, or available to me on FF/Linux.\nThanks, Pete\n\n post by abcoathup on Jan 4\n\n abcoathup\n\n Hey Pete, In Discourse forums you can’t create a new topic until you have done spent some time reading.\nRecommend that you read multiple topics first, you should then automatically earn a Basic badge. https://ethresear.ch/u/captnbli/badges\nSo far you have spent 9 minutes reading: https://ethresear.ch/u/captnbli/summary\n\n post by captnbli on Jan 5\n\n captnbli\n\n Well, I understand your policy. I t must be difficult to keep things focused.\nbut looking forward to posting my saved post. I think there is a time limit. Is it “as well” or “either”?\n\n post by abcoathup on Jan 5\n\n abcoathup\n\n I don’t know what settings Eth Research uses, I am just a regular user like everyone else.\nDefault Discourse is time spent reading and reading X posts: Understanding Discourse Trust Levels\n\n 27 days later\n\n post by ngrawlings on Feb 2\n\n ngrawlings\n\n I have some research I would like to post. I did reply to a previous post as I can not post new topics. The research is related to Post Quantum. It is credible. The maths works, so hardly crack pot stuff and it does at very least raise a perspective to consider.\nThat reply was removed, probably for not being relevant to the post it was under.\nHow do I do about posting this research?\n\n post by abcoathup on Feb 2\n\n abcoathup\n\n @ngrawlings in Discourse forums (such as Eth Research) you can’t create a new topic until you have spent time reading multiple topics.\nRecommend you read the post-quantum topics and the replies. I’m not a mod/admin here, so don’t know the specific settings.\n\n post by brighammurdoch-byte on Feb 3\n\n brighammurdoch-byte\n\n Hey! I’m an Economics/Data student who is interested in working in blockchain based tokennomics and incentives design! I’m wondering if I could get some information on the best places to start. If anyone has some suggestions plese let me know!\nAlso, if someone could point me to the biggest topics and proposals being discussed right now that would be verry helpful! I have a good high level understaning of Ethereum but don’t know much of the nitty gritty.\n\n post by umamimi on Feb 4\n\n umamimi\n\n nonce classic has published their guide to understand the tokenomics. It would be your good start and you can find more resources based on this basic. I hope you would find this interesting.\nGoogle “Tokenomics Design 101 for Early Stage Crypto Startups” then find it \n\n 2 months later\n\n post by MicahZoltu on Apr 19\n\n MicahZoltu\n\n It is intentionally fuzzy to prevent it from being gamed.\nMy recommendation: Don’t use LLMs to generate huge amounts of “research”. LLMs are a useful tool, but they still needs an expert to review and validation of their output, as more often than not they still hallucinates. This won’t be true forever, but at the moment generating massive volumes of LLM output and then giving it to other people to review for problems isn’t helping anyone and it is wasting other people’s time.\n\n 3 months later\n\n post by frostybucks on Jul 8\n\n frostybucks\n\n i get im new here, please give my idea a moment, ide really appreciate it. ( A decentralized verification primitive that validates identity and intent before any blockchain action occurs. )\n\n 13 days later\n\n post by YulinLiu20 on Jul 21\n\n YulinLiu20\n\n Hi all — I’m guest-editing a Research Topic on the intersection of blockchain, DeFi, and AI, and I’d rather recruit from people actually building and analyzing these systems than through cold email.\nA lot of strong work in this space — MEV auction design, AMM mechanism analysis, LLM trading agents, agent-to-agent payments (e.g. ERC-8004 discussions), token engineering, LLM-based contract auditing — ends up on arXiv or ethresear.ch and never gets a peer-reviewed home, because it doesn’t fit neatly into either finance or CS venues. This issue is meant to be that home.\nIn scope, among others:\n\nAI agents in decentralized markets; agent-to-agent economies\n\nMechanism/incentive design in DeFi protocols\n\nMEV, AMM design, market microstructure with on-chain data\n\nMulti-agent simulation of digital economies\n\nDAO governance and decentralized decision-making\n\nAI and smart contract safety\n\nOriginal research, reviews, and methods papers all welcome. Extended versions of workshop/conference papers are fine.\nThe topic is Blockchain, DeFi and AI: Economic Systems, Intelligent Agents, and Mechanism Design\nIt can be published on Frontiers in Blockchain or Frontiers in AI.\nHappy to answer questions here about scope or fit — and if you have a preprint you think qualifies, comment or DM me and I’ll tell you directly whether it’s a match.\n\n 28 days later\n\n post by captnbli on Aug 19\n\n captnbli\n\n abcoathup\n\n And therein lie the problem. You should induce, gently, new users into the norms. It is not standard net norms\n\n post by virgil on Aug 19\n\n virgil\n\n Leader\n\n abcoathup\n\n Updated the Administrivia letting new users know.\n\n Powered by Discourse","tokens":1986,"squid":"ink-research","role":"Deep Scholar","at":1791258403519,"hash":"4493395e28a353bea5c2b19d067def6635cba9e1"}
{"url":"https://ethresear.ch/t/read-this-before-posting/8/31","domain":"ethresear.ch","title":"Read this before posting - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Aug 2017\n\n 14 / 14\n\n Aug 19\n\n Aug 19\n\n post by system on Aug 17, 2017\n\n system\n\n This is a semi-public forum for participating in Ethereum’s research efforts, including but not limited to:\n\nProof-of-Stake\nPost Quantum\nZero-Knowledge work\nScaling solutions\nEVM improvements\nLow-level protocol improvements\nEconomics\n\nprotocol economics\nResource pricing economics\n\nOther second-level features\nAnything on the Ethereum roadmap.\n\nUseful sites\n\nEthereum.org research\nEthereum roadmap\n\nThis is not the place for:\n\ngeneric ethereum discussion. For that visit r/ethereum.\ndiscussing specific EIPs. For that visit the Ethereum Magicians forum.\ntechnical questions and ELI5s. For that visit the StackExchange.\ncore documentation. See ethereum.org developer docs.\n\nEthereum is a decentralized and permissionless platform, but this bulletin board is a centralized and permissioned platform. Just how it is. If your signal-to-noise ratio gets too low, you will be banned from ethresear.ch. So please keep discussions information-rich. Posting on this site is accepting releasing your submitted content into the public domain (CC0).\nTo both reduce spam and help new users get a sense of community norms, newly created accounts cannot immediately make posts. You have to click and read around a bit around before you are able to post.\nForum Features!\n1. LaTeX Equations\nThis forum supports \\LaTeX𝐿𝐴𝑇𝐸𝑋 equations between $dollar signs$. The default LaTeX style is the “inline” style which looks like \\sum_{k=0}^n {n \\choose k} = 2^n ∑𝑛𝑘=0(𝑛𝑘) =2𝑛, in text this is\n$ \\sum_{k=0}^n {n \\choose k} = 2^n $\n\nHowever, if you start your equation with $$ on it’s own beginning and teminating line like,\n$$\n\\sum_{k=0}^n {n \\choose k} = 2^n\n$$\n\nit looks like this\n\n\\sum_{k=0}^n {n \\choose k} = 2^n\n𝑛∑𝑘=0(𝑛𝑘)=2𝑛\n\n2. Graphviz diagrams\nSee the documentation for a list of examples to build your graph.\n[graphviz engine=dot]\ndigraph {\n concentrate=true;\n a[color=red, style=filled, fillcolor=pink];\n b[shape=diamond];\n a -> b;\n b -> c;\n c -> a;\n d -> c;\n e -> c;\n e -> a;\n a -> e;\n}\n[/graphviz]\n\n3. YUML diagrams\nYUML diagrams allow making nice little graphs within your posts.\nThey have an idiosyncratic but fairly simple markup language.\nExample:\n\n[yuml]\n[foo{bg:cornsilk}]--[baz]\n[foo]->[bar{bg:orange}]\n[baz]-.->[qux]\n[qux]--label>[bar]\n[/yuml]\n\n%5BVote%20Message%7C+Source%20hash;-Source%20height;+Target%20hash;-Target%20height%7C+Withdraw();+Last_commit%5D.svg118×158 238 KB\n[yuml]\n[Vote Message|+Source hash;-Source height;+Target hash;-Target height|+Withdraw();+Last_commit]\n[/yuml]\n\n4. Images!\nUnsurprisingly, we also support images.\nu1614×800 57.9 KB\n\n Is this desk lacking administration?\n\n 3\n\n 3\n\n 8 years later\n\n post by captnbli on Jan 4\n\n captnbli\n\n My issue is I can’t post a new topic, having just joined, which is what I want to do, And how I achieve that is not explained, or available to me on FF/Linux.\nThanks, Pete\n\n post by abcoathup on Jan 4\n\n abcoathup\n\n Hey Pete, In Discourse forums you can’t create a new topic until you have done spent some time reading.\nRecommend that you read multiple topics first, you should then automatically earn a Basic badge. https://ethresear.ch/u/captnbli/badges\nSo far you have spent 9 minutes reading: https://ethresear.ch/u/captnbli/summary\n\n post by captnbli on Jan 5\n\n captnbli\n\n Well, I understand your policy. I t must be difficult to keep things focused.\nbut looking forward to posting my saved post. I think there is a time limit. Is it “as well” or “either”?\n\n post by abcoathup on Jan 5\n\n abcoathup\n\n I don’t know what settings Eth Research uses, I am just a regular user like everyone else.\nDefault Discourse is time spent reading and reading X posts: Understanding Discourse Trust Levels\n\n 27 days later\n\n post by ngrawlings on Feb 2\n\n ngrawlings\n\n I have some research I would like to post. I did reply to a previous post as I can not post new topics. The research is related to Post Quantum. It is credible. The maths works, so hardly crack pot stuff and it does at very least raise a perspective to consider.\nThat reply was removed, probably for not being relevant to the post it was under.\nHow do I do about posting this research?\n\n post by abcoathup on Feb 2\n\n abcoathup\n\n @ngrawlings in Discourse forums (such as Eth Research) you can’t create a new topic until you have spent time reading multiple topics.\nRecommend you read the post-quantum topics and the replies. I’m not a mod/admin here, so don’t know the specific settings.\n\n post by brighammurdoch-byte on Feb 3\n\n brighammurdoch-byte\n\n Hey! I’m an Economics/Data student who is interested in working in blockchain based tokennomics and incentives design! I’m wondering if I could get some information on the best places to start. If anyone has some suggestions plese let me know!\nAlso, if someone could point me to the biggest topics and proposals being discussed right now that would be verry helpful! I have a good high level understaning of Ethereum but don’t know much of the nitty gritty.\n\n post by umamimi on Feb 4\n\n umamimi\n\n nonce classic has published their guide to understand the tokenomics. It would be your good start and you can find more resources based on this basic. I hope you would find this interesting.\nGoogle “Tokenomics Design 101 for Early Stage Crypto Startups” then find it \n\n 2 months later\n\n post by MicahZoltu on Apr 19\n\n MicahZoltu\n\n It is intentionally fuzzy to prevent it from being gamed.\nMy recommendation: Don’t use LLMs to generate huge amounts of “research”. LLMs are a useful tool, but they still needs an expert to review and validation of their output, as more often than not they still hallucinates. This won’t be true forever, but at the moment generating massive volumes of LLM output and then giving it to other people to review for problems isn’t helping anyone and it is wasting other people’s time.\n\n 3 months later\n\n post by frostybucks on Jul 8\n\n frostybucks\n\n i get im new here, please give my idea a moment, ide really appreciate it. ( A decentralized verification primitive that validates identity and intent before any blockchain action occurs. )\n\n 13 days later\n\n post by YulinLiu20 on Jul 21\n\n YulinLiu20\n\n Hi all — I’m guest-editing a Research Topic on the intersection of blockchain, DeFi, and AI, and I’d rather recruit from people actually building and analyzing these systems than through cold email.\nA lot of strong work in this space — MEV auction design, AMM mechanism analysis, LLM trading agents, agent-to-agent payments (e.g. ERC-8004 discussions), token engineering, LLM-based contract auditing — ends up on arXiv or ethresear.ch and never gets a peer-reviewed home, because it doesn’t fit neatly into either finance or CS venues. This issue is meant to be that home.\nIn scope, among others:\n\nAI agents in decentralized markets; agent-to-agent economies\n\nMechanism/incentive design in DeFi protocols\n\nMEV, AMM design, market microstructure with on-chain data\n\nMulti-agent simulation of digital economies\n\nDAO governance and decentralized decision-making\n\nAI and smart contract safety\n\nOriginal research, reviews, and methods papers all welcome. Extended versions of workshop/conference papers are fine.\nThe topic is Blockchain, DeFi and AI: Economic Systems, Intelligent Agents, and Mechanism Design\nIt can be published on Frontiers in Blockchain or Frontiers in AI.\nHappy to answer questions here about scope or fit — and if you have a preprint you think qualifies, comment or DM me and I’ll tell you directly whether it’s a match.\n\n 28 days later\n\n post by captnbli on Aug 19\n\n captnbli\n\n abcoathup\n\n And therein lie the problem. You should induce, gently, new users into the norms. It is not standard net norms\n\n post by virgil on Aug 19\n\n virgil\n\n Leader\n\n abcoathup\n\n Updated the Administrivia letting new users know.\n\n Powered by Discourse","tokens":1979,"squid":"ink-research","role":"Deep Scholar","at":1791258415739,"hash":"0b8122465796f143fd53f477ff31bf8296df1382"}
{"url":"https://docs.pyth.network/price-feeds/core/price-feeds","domain":"docs.pyth.network","title":"Price Feeds | Pyth Developer Hub","text":"Pyth CorePrice FeedsOverview of Pyth price feeds, asset classes, and feed IDsPyth Price Feeds provide real-time, first-party, market data for a wide range of assets.\nEvery price feed has a unique ID, representing the specific pair of assets being priced.\nThese specific pairs are part of an asset class, which is a broader category of assets.\nAnyone can fetch available price feeds and their IDs via Hermes API.\nAsset Classes\nEvery price feed belongs to an asset class. These asset classes distinguish between different types of assets, such as crypto, US equities, and metals.\nRefer to the Asset Classes page to learn more about the existing asset classes.\nPrice Feed IDs\nPrice Feed IDs are unique identifiers for each specific pair of assets being priced (e.g. BTC/USD).\nEvery price update is tagged with the corresponding price feed ID.\nApplications need to store the IDs of the feeds they wish to read.\nHowever, the IDs may be represented in different formats (e.g. hex or base58) depending on the blockchain.\nPrice feeds also have different IDs in the Stable and Beta channels.\nFeed IDs\nRefer to the Price Feed IDs page for the complete list of price feed IDs.\nSolana Price Feed Accounts\nOn Solana, each feed additionally has a collection of price feed accounts containing the feed's data.\nThe addresses of these accounts are programmatically derived from the feed id and a shard id, which is simply a 16-bit number.\nSee How to Use Real-Time Data on Solana for more information on price feed accounts.API ReferenceExplore interactive Pyth API references for on-chain and off-chain integrationsPrice Feed IDsList of price feed IDs for all the assets supported by Pyth Core","tokens":419,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258432674,"hash":"e2b31e27cc5e49f6d20416bf0b41c9d9e9bcdb51"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/reference/monitoring-tools-block-explorers","domain":"docs.arbitrum.io","title":"Monitoring tools and block explorers | Arbitrum Docs","text":"✏️Request an updateBlock explorers​\nLook up any transaction, address, or contract on Arbitrum.\nToolArbitrum OneArbitrum NovaArbitrum SepoliaArbiscanarbiscan.ionova.arbiscan.iosepolia.arbiscan.ioBlockscoutarbitrum.blockscout.comarbitrum-nova.blockscout.comarbitrum-sepolia.blockscout.comDexGuruarbitrum.dex.gurunova.dex.guru—OKLINKoklink.com/arbitrum——\nData and analytics​\nQuery, index, and visualize onchain data.\nToolDescriptionLinkChainbaseIndex, transform, and use onchain data at scalechainbase.comDuneVisualize and analyze Arbitrum network data with SQL queriesdune.com · Arbitrum community dashboards\nNext steps​\nBuild on Arbitrum or dive deeper into the network.\n\nContract addresses — key Arbitrum contract addresses\nChain info and RPC endpoints — chain IDs, RPC URLs, and network parameters\nHow to estimate gas — understand gas costs on Arbitrum\nQuickstart: Build a dApp — deploy your first contract on Arbitrum\nRun a full node — run your own Arbitrum node\n\nKNOW MORE TOOLS?See something missing? Let us know on the Arbitrum Discord or by opening an issue on GitHub.Block explorersData and analyticsNext steps","tokens":279,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258447337,"hash":"ef6ec9b00f12587ef818c71e95894d8d63a990ed"}
{"url":"https://ethresear.ch/c/administrivia/3","domain":"ethresear.ch","title":"Latest Administrivia topics - Ethereum Research","text":"Latest topics in Administrivia\n\n Administrivia\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Read this before posting\n\n This is a semi-public forum for participating in Ethereum’s research efforts, including but not limited to: \n\nProof-of-Stake\nPost Quantum\nZero-Knowledge work\nScaling solutions\nEVM improvements\nLow-level protocol improvem…\n\n read more\n\n 13\n\n 61.5k\n\n Aug 19\n\n Promoting Ethereum Research to facilitate interdisciplinary collaboration and academic user engagement\n\n 17\n\n 6.0k\n\n May 2024\n\n Is this desk lacking administration?\n\n 10\n\n 2.3k\n\n Jan 2024\n\n Request for a new category of this site\n\n 4\n\n 1.6k\n\n Oct 2023\n\n Graduation research Ethereum ecosystem\n\n 4\n\n 1.6k\n\n Mar 2023\n\n Requesting a read-only Discourse API key for monitoring new protocol upgrade discussions\n\n 1\n\n 2.4k\n\n Apr 2022\n\n Proposal: Add a new category for ‘Philosophy’\n\n 6\n\n 2.9k\n\n Dec 2021\n\n Somewhat time critical — How do I set a password?\n\n 8\n\n 2.7k\n\n Nov 2021\n\n Ethresear.ch: email login will be disabled in 7 days\n\n 14\n\n 4.1k\n\n Oct 2021\n\n Unable to delete or modify posts\n\n 3\n\n 2.6k\n\n Oct 2021\n\n Suggestion for a new category: Security\n\n security\n\n 1\n\n 2.2k\n\n Aug 2020\n\n Suggested new category: Eth 1.x Stateless Clients\n\n 2\n\n 1.9k\n\n Nov 2019\n\n Now running on CloudFlare\n\n 0\n\n 1.9k\n\n Feb 2019\n\n Prevent patents by allowing crawlers\n\n 5\n\n 2.5k\n\n Dec 2018\n\n Suggest new category: UX / Research\n\n 4\n\n 2.1k\n\n Aug 2018\n\n About the Administrivia category\n\n 1\n\n 2.2k\n\n Jul 2018\n\n How to apply for eth research grant?\n\n 1\n\n 2.7k\n\n Apr 2018\n\n Administrivia for changes to board\n\n 13\n\n 3.5k\n\n Feb 2018\n\n Misc updates\n\n 4\n\n 2.8k\n\n Oct 2017\n\n Powered by Discourse","tokens":424,"squid":"ink-research","role":"Deep Scholar","at":1791258450179,"hash":"40423dcc60831f129143556d72dd4f2297db1a03"}
{"url":"https://www.anchor-lang.com/docs/references/account-constraints","domain":"anchor-lang.com","title":"Account Constraints","text":"Program DevelopmentAccount ConstraintsAnchor Account Constraints ExamplesMinimal reference examples for Anchor account\nconstraints.\nSee the account constraints\nsource code\nfor implementation details.\nNormal Constraints\n#[account(signer)]\nDescription: Checks the given account signed the transaction. Consider using the\nSigner type if you would only have this constraint on the account.\nExamples: Github\n|\nSolpg\nattribute#[account(signer)]\n#[account(signer @ <custom_error>)]\n#[account(mut)]\nDescription: Checks the given account is mutable. Makes anchor persist any state\nchanges.\nExamples: Github\n|\nSolpg\nattribute#[account(mut)]\n#[account(mut @ <custom_error>)]\n#[account(dup)]\nDescription: By default, Anchor prevents duplicate mutable accounts to avoid\npotential security issues and unintended behavior. The dup constraint\nexplicitly allows this for cases where it's intentional and safe.\nNote: This constraint only applies to mutable account (mut) types that\nserialize on exit. Other types like UncheckedAccount, Signer,\nSystemAccount, AccountLoader, Program, and Interface naturally allow\nduplicates as they don't serialize data on exit.\nattribute#[account(mut, dup)]\n#[account(mut, dup @ <custom_error>)]\nsnippet#[derive(Accounts)]\npub struct AllowsDuplicateMutable<'info> {\n #[account(mut)]\n pub account1: Account<'info, Counter>,\n // This account can be the same as account1\n #[account(mut, dup)]\n pub account2: Account<'info, Counter>,\n}\n\npub fn allows_duplicate_mutable(ctx: Context<AllowsDuplicateMutable>) -> Result<()> {\n Ok(())\n}\n#[account(init)]\nDescription: Creates the account via a CPI to the system program and initializes\nit (sets its account discriminator).\nExamples: Github\n|\nSolpg\nattribute#[account(\n init,\n payer = <target_account>,\n space = <num_bytes>\n)]\n#[account(init_if_needed)]\nDescription: Same as init but only runs if the account does not exist yet.\nRequires init-if-needed cargo feature.\nExamples: Github\n|\nSolpg\nattribute#[account(\n init_if_needed,\n payer = <target_account>\n)]\n\n#[account(\n init_if_needed,\n payer = <target_account>,\n space = <num_bytes>\n)]\n#[account(seeds, bump)]\nDescription: Checks that given account is a PDA derived from the currently\nexecuting program, the seeds, and if provided, the bump.\nExamples: Github\n|\nSolpg\nattribute#[account(\n seeds = <seeds>,\n bump\n)]\n\n#[account(\n seeds = <seeds>,\n bump,\n seeds::program = <expr>\n)]\n\n#[account(\n seeds = <seeds>,\n bump = <expr>\n)]\n\n#[account(\n seeds = <seeds>,\n bump = <expr>,\n seeds::program = <expr>\n)]\n#[account(has_one = target)]\nDescription: Checks the target field on the account matches the key of the\ntarget field in the Accounts struct.\nExamples: Github\n|\nSolpg\nattribute#[account(\n has_one = <target_account>\n)]\n\n#[account(\n has_one = <target_account> @ <custom_error>\n)]\n#[account(address = expr)]\nDescription: Checks the account key matches the pubkey.\nExamples: Github\n|\nSolpg\nattribute#[account(address = <expr>)]\n#[account(address = <expr> @ <custom_error>)]\n#[account(owner = expr)]\nDescription: Checks the account owner matches expr.\nExamples: Github\n|\nSolpg\nattribute#[account(owner = <expr>)]\n#[account(owner = <expr> @ <custom_error>)]\n#[account(executable)]\nDescription: Checks the account is executable (i.e. the account is a program).\nExamples: Github\n|\nSolpg\nattribute#[account(executable)]\n#[account(zero)]\nDescription: Checks the account discriminator is zero. Use for accounts larger\nthan 10 Kibibyte.\nExamples: Github\n|\nSolpg\nattribute#[account(zero)]\n#[account(close = target)]\nDescription: Closes the account by sending lamports to target and resetting\ndata.\nExamples: Github\n|\nSolpg\nattribute#[account(close = <target_account>)]\n#[account(constraint = expr)]\nDescription: Custom constraint that checks whether the given expression\nevaluates to true.\nExamples: Github\n|\nSolpg\nattribute#[account(constraint = <expr>)]\n#[account(\n constraint = <expr> @ <custom_error>\n)]\n#[account(realloc)]\nDescription: Used to realloc program account space at the beginning of an\ninstruction.\nIf the change is additive, lamports are transferred from realloc::payer to\nmaintain rent exemption. If the change is subtractive, all lamports above the\nnew rent-exempt minimum are transferred back to realloc::payer.\nWarning: Do not use subtractive realloc on accounts that intentionally hold\nextra lamports, such as vaults. Those extra lamports will also be transferred\nto realloc::payer; the current v1 behavior does not limit refunds to rent\nsavings alone.\nExamples: Github\n|\nSolpg\nattribute#[account(\n realloc = <space>,\n realloc::payer = <target>,\n realloc::zero = <bool>\n)]\n#[account(discriminator = discrim)]\nDescription: Used to override the discriminator for an account. All constant expressions are supported,\nbut all-zero discriminators are not.\nIn versions of Anchor before 1.0, program-owned accounts with zeroed discriminators (for example, by manually\ninitializing an AccountInfo, or as preparation for #[zero] initialization) can be taken over via IDL instructions.\nattribute#[account(discriminator = 12)]\n#[account(discriminator = [1, 2, 3, 4])]\n#[account(discriminator = MY_CONST_DISCRIMINATOR)]\nSPL Constraints\n#[account(token::*)]\nDescription: Create or validate token accounts with specified mint and\nauthority.\nExamples: Github\n|\nSolpg\nattribute#[account(\n token::mint = <target_account>,\n token::authority = <target_account>\n)]\n\n#[account(\n token::mint = <target_account>,\n token::authority = <target_account>,\n token::token_program = <target_account>\n)]\n#[account(mint::*)]\nDescription: Create or validate mint accounts with specified parameters.\nYou can set mint::authority or mint::freeze_authority to None to require\nthat authority not to be set. With init, mint::freeze_authority = None\ncreates a mint with no freeze authority. mint::authority = None cannot be\nused with init because SPL Token requires a mint authority at initialization.\nExamples: Github\n|\nSolpg\nattribute#[account(\n mint::authority = <target_account>,\n mint::decimals = <expr>\n)]\n\n#[account(\n mint::authority = <target_account>,\n mint::decimals = <expr>,\n mint::freeze_authority = <target_account>\n)]\n\n#[account(\n mint::authority = None,\n mint::freeze_authority = None\n)]\n#[account(associated_token::*)]\nDescription: Create or validate associated token accounts.\nExamples: Github\n|\nSolpg\nattribute#[account(\n associated_token::mint = <target_account>,\n associated_token::authority = <target_account>\n)]\n\n#[account(\n associated_token::mint = <target_account>,\n associated_token::authority = <target_account>,\n associated_token::token_program = <target_account>\n)]\n#[account(*::token_program = expr)]\nDescription: The token_program can optionally be overridden.\nExamples: Github\n|\nSolpg\nattribute#[account(*::token_program = <target_account>)]\nToken Extensions Constraints\nThese extensions are checked both when the mint is initialized and when an\nexisting mint is reused with init_if_needed.\n#[account(extensions::close_authority::*)]\nDescription: Create or validate close authority extension on the mint account.\nattribute#[account(\n extensions::close_authority::authority = <target_account>\n)]\n#[account(extensions::permanent_delegate::*)]\nDescription: Create or validate permanent delegate extension on the mint\naccount.\nattribute#[account(\n extensions::permanent_delegate::delegate = <target_account>\n)]\n#[account(extensions::transfer_hook::*)]\nDescription: Create or validate transfer hook extension on the mint account.\nattribute#[account(\n extensions::transfer_hook::authority = <target_account>,\n extensions::transfer_hook::program_id = <target_account>\n)]\n#[account(extensions::group_pointer::*)]\nDescription: Create or validate group pointer extension on the mint account.\nattribute#[account(\n extensions::group_pointer::authority = <target_account>,\n extensions::group_pointer::group_address = <target_account>\n)]\n#[account(extensions::group_member_pointer::*)]\nDescription: Create or validate group member pointer extension on the mint\naccount.\nattribute#[account(\n extensions::group_member_pointer::authority = <target_account>,\n extensions::group_member_pointer::member_address = <target_account>\n)]\n#[account(extensions::metadata_pointer::*)]\nDescription: Create or validate metadata pointer extension on the mint account.\nattribute#[account(\n extensions::metadata_pointer::authority = <target_account>,\n extensions::metadata_pointer::metadata_address = <target_account>\n)]\nInstruction Attribute\n#[instruction(...)]\nDescription: You can access the instruction's arguments with the\n#[instruction(..)] attribute. You must list them in the same order as in the\ninstruction handler but you can omit all arguments after the last one you need.\nSkipping arguments will result in an error.\nThe attribute must appear after #[derive(Accounts)].\nExamples:\nGithub\n|\nSolpg\nsnippet#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>, input: String) -> Result<()> {\n // --snip--\n }\n}\n\n#[derive(Accounts)]\n#[instruction(input: String)]\npub struct Initialize<'info> {\n #[account(\n init,\n payer = signer,\n space = 8 + 4 + input.len(),\n )]\n pub new_account: Account<'info, DataAccount>,\n // --snip--\n}\nValid Usage:\nsnippet#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>, input_one: String, input_two: String) -> Result<()> {\n // --snip--\n }\n}\n\n#[derive(Accounts)]\n#[instruction(input_one: String, input_two: String)]\npub struct Initialize<'info> {\n // --snip--\n}\nsnippet#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>, input_one: String, input_two: String) -> Result<()> {\n // --snip--\n }\n}\n\n#[derive(Accounts)]\n#[instruction(input_one: String)]\npub struct Initialize<'info> {\n // --snip--\n}\nInvalid Usage, will result in an error:\nsnippet#[program]\npub mod example {\n use super::*;\n\n pub fn initialize(ctx: Context<Initialize>, input_one: String, input_two: String) -> Result<()> {\n // --snip--\n }\n}\n\n#[derive(Accounts)]\n#[instruction(input_two: String)]\npub struct Initialize<'info> {\n // --snip--\n}PreviousAccount TypesNextAnchor.toml ConfigurationOn this pageNormal Constraints#[account(signer)]#[account(mut)]#[account(dup)]#[account(init)]#[account(init_if_needed)]#[account(seeds, bump)]#[account(has_one = target)]#[account(address = expr)]#[account(owner = expr)]#[account(executable)]#[account(zero)]#[account(close = target)]#[account(constraint = expr)]#[account(realloc)]#[account(discriminator = discrim)]SPL Constraints#[account(token::*)]#[account(mint::*)]#[account(associated_token::*)]#[account(*::token_program = expr)]Token Extensions Constraints#[account(extensions::close_authority::*)]#[account(extensions::permanent_delegate::*)]#[account(extensions::transfer_hook::*)]#[account(extensions::group_pointer::*)]#[account(extensions::group_member_pointer::*)]#[account(extensions::metadata_pointer::*)]Instruction Attribute#[instruction(...)]Edit on GitHub","tokens":2725,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258453397,"hash":"27344a03f63ed4b660d4ed2dbf12e581432494c9"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/reference/solidity-references","domain":"docs.arbitrum.io","title":"Solidity references | Arbitrum Docs","text":"✏️Request an updateSolidity is the dominant high-level, statically typed, object-oriented language for writing smart contracts that run on the Ethereum Virtual Machine (EVM) and EVM-compatible chains (including Layer 2s like Arbitrum). It powers the vast majority of DeFi, NFTs, DAOs, and other onchain applications.\nOfficial documentation​\nThese are the authoritative, always-current references.\n\nSolidity documentation: The single most important resource. Two sections are must-reads:\n\nSolidity by Example\nSecurity Considerations\n\nSolidity Language Portal: Overview, translations, links to the compiler/repo.\nEthereum.org developer docs: Smart contracts, EVM, testing, compiling, security, and the full stack. Excellent companion to the Solidity docs.\nOfficial GitHub repository: Compiler source, issues, releases, and vulnerability reporting.\n\nLearning paths and courses​\nThe ecosystem moves fast; high-quality, free project-based courses outperform most books (which are slow to market).\n\nCyfrin Updraft (Patrick Collins): Beginner-to-advanced, heavily project-based, uses Foundry from the start. Includes security/auditing tracks.\nRareSkills Ultimate Solidity Course: In-depth, trusted by security experts and auditors. Strong on real-world patterns and protocol walkthroughs.\nCryptoZombies: Classic interactive game-based introduction. A little outdated, but still excellent for absolute beginners to learn syntax and basic patterns quickly.\nAlchemy University: Online education platform for blockchain and Web3 development courses.\nRisein: Online education for blockchain and Web3 development courses.\nHackQuest: Ethereum development.\n\nStylus course\n\nLearnWeb3: Ethereum-specific developer learning.\n\nStylus course\n\nEthernaut: Interactive smart contract hacking game.\n\nPaid courses\n\nMetana\n\nDevelopment frameworks and tooling​\n\nFoundry (Rust-based): Excellent fuzzing, mainnet forking, and cheat codes. Preferred by security researchers and DeFi protocols.\nHardhat: JavaScript/TypeScript-first. Hardhat 3 brings a Rust-powered runtime for big performance gains. Outstanding stack traces, console.log in Solidity, vast plugin ecosystem (verification, gas reporter, etc.). Great for teams with frontend/web devs.\nRemix IDE (browser-based): Zero-setup prototyping, debugging, and deployment. Perfect for quickstarts and learning.\n\nOther tools: VS Code + Solidity extensions, Slither (static analysis, integrates with Foundry), Etherscan/Blockscout for verification.\nSecurity best practices and auditing​\nSecurity is non-negotiable—most exploits stem from reentrancy, access control, integer issues, oracle problems, or upgrade logic.\nCore resources​\n\nSolidity Docs → Security Considerations section.\nConsenSys Diligence Smart Contract Best Practices\nOWASP Smart Contract Top 10\nOpenZeppelin Ethernaut\nTrail of Bits “Building Secure Contracts” GitHub repo\nCyfrin Updraft Security & Auditing track\n\nLibraries and standards​\n\nOpenZeppelin Contracts: The gold standard for ERC-20/ERC-721/ERC-1155, access control (Ownable, Roles), upgradeable proxies (UUPS/Transparent), pausability, etc. Always audit your usage and prefer their implementations over custom code. OpenZeppelin GitHub repo.\n\nCommunity, forums, ongoing learning​\n\nEthereum Stack Exchange: Best for technical Q&A.\nawesome-solidity GitHub repo: Curated list of repos, tools, and examples.\n\nGitHub repositories worth studying​\n\nOfficial compiler and examples\nOpenZeppelin/openzeppelin-contracts (read every line eventually).\nfoundry-rs/forge-std\nNomicFoundation/hardhat\nethereum/EIPs (track changes affecting the EVM/Solidity).\nProtocol repos (Uniswap, Aave, etc.) for real-world patterns.\nOfficial documentationLearning paths and coursesDevelopment frameworks and toolingSecurity best practices and auditingCore resourcesLibraries and standardsCommunity, forums, ongoing learningGitHub repositories worth studying","tokens":969,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258469201,"hash":"956986874a5444c810ee73586b5aa40fca866fa5"}
{"url":"https://www.anchor-lang.com/docs/references/anchor-toml","domain":"anchor-lang.com","title":"Anchor.toml Configuration","text":"Program DevelopmentAnchor.toml ConfigurationAnchor workspace config reference documentationprovider (required)\nA wallet and cluster that are used for all commands.\nExample:\n[provider]\ncluster = \"localnet\" # The cluster used for all commands.\nwallet = \"~/.config/solana/id.json\" # The keypair used for all commands.\nscripts (required for testing)\nScripts that can be run with anchor run <script>. The test script is\nexecuted by anchor test.\nExample:\n[scripts]\ntest = \"yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts\"\nskip_local_validator\nWhen set to true, anchor test does not automatically start a local\nvalidator for localnet tests. anchor init writes this for Rust templates that\nrun the Solana VM in-process, such as LiteSVM and Mollusk.\nExample:\nskip_local_validator = true\nfeatures\nresolution\nThis tells the IDL to support account resolution. The default is true.\nExample:\n[features]\nresolution = true\nworkspace\nidls\nAdds a directory where you want the <program_name>.json file to be copied when running\nanchor build. This is helpful when you want the generated IDL JSON outside the\nworkspace target directory, such as for versioning or consumption by another\ntool.\nExample:\n[workspace]\nidls = \"app/src/idls/\"\ntypes\nAdds a directory where you want the <program_name>.ts file to be copied when running\nanchor build. This is helpful when you want to keep IDL type definitions in version\ncontrol, like when using it on the frontend, which will probably not have access\nto the target directory generated by anchor.\nExample:\n[workspace]\ntypes = \"app/src/idls/\"\nmembers\nSets the paths --relative to the Anchor.toml-- to all programs in the local\nworkspace, i.e., the path to the Cargo.toml manifest associated with each\nprogram that can be compiled by the anchor CLI. For programs using the\nstandard Anchor workflow, this can be omitted. For programs not written in\nAnchor but still want to publish, this should be added.\nExample:\n[workspace]\nmembers = [\n \"programs/*\",\n \"other_place/my_program\"\n]\nexclude\nOpposite of workspace.members.\nExample:\n[workspace]\nexclude = [\n \"programs/my_program\"\n]\nclients\nConfigures Codama client generation. When auto = true, anchor build\nconverts emitted Anchor IDLs into Codama IDLs and invokes the selected language\nrenderers after the build completes.\nEach language can be enabled with a boolean or a table. If path is omitted,\nthe default output path is clients/<language>. Supported language keys are\njs, js-umi, rust, and go.\nExample:\n[clients]\nauto = true\nrust = true\njs = { enable = true }\ngo = { enable = true, path = \"go-client\" }\njs-umi = false\nprograms\nExample:\n[programs.localnet]\nmy_program = \"Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS\"\nThe addresses of the programs in the workspace.\nprograms.localnet is used during testing on localnet where it's possible to\nload a program at genesis with the --bpf-program option on\nsolana-test-validator.\ntest\nstartup_wait\nIncreases the time anchor waits for the solana-test-validator to start up.\nThis is, for example, useful if you're cloning (see test.validator.clone) many\naccounts which increases the validator's startup time.\nExample:\n[test]\nstartup_wait = 10000\ngenesis\nMakes commands like anchor test start solana-test-validator with a given\nprogram already loaded.\nExample\n[[test.genesis]]\naddress = \"srmqPvymJeFKQ4zGQed1GFppgkRHL9kaELCbyksJtPX\"\nprogram = \"dex.so\"\n\n[[test.genesis]]\naddress = \"22Y43yTVxuUkoRKdm9thyRhQ3SdgQS7c7kB6UNCiaczD\"\nprogram = \"swap.so\"\nupgradeable = true\nupgradeable\nDeploys the program-to-test using --upgradeable-program. This makes it\npossible to test that certain instructions can only be executed by the program's\nupgrade authority. The initial upgrade authority will be set to\nprovider.wallet.\nIf unspecified or explicitly set to false, then the test program will be\ndeployed with --bpf-program, disabling upgrades to it.\nExample:\n[test]\nupgradeable = true\ntest.validator\nThese options are passed into the options with the same name in the\nsolana-test-validator cli (see solana-test-validator --help) in commands\nlike anchor test.\n[test.validator]\nurl = \"https://api.mainnet-beta.solana.com\" # This is the url of the cluster that accounts are cloned from (See `test.validator.clone`).\nwarp_slot = 1337 # Warp the ledger to `warp_slot` after starting the validator.\nslots_per_epoch = 5 # Override the number of slots in an epoch.\nrpc_port = 1337 # Set JSON RPC on this port, and the next port for the RPC websocket.\nlimit_ledger_size = 1337 # Keep this amount of shreds in root slots.\nledger = \"test-ledger\" # Set ledger location.\ngossip_port = 1337 # Gossip port number for the validator.\ngossip_host = \"127.0.0.1\" # Gossip DNS name or IP address for the validator to advertise in gossip.\nfaucet_sol = 1337 # Give the faucet address this much SOL in genesis.\nfaucet_port = 1337 # Enable the faucet on this port.\ndynamic_port_range = \"1337 - 13337\" # Range to use for dynamically assigned ports.\nbind_address = \"127.0.0.1\" # IP address to bind the validator ports.\ntest.validator.clone\nUse this to clone an account from the test.validator.clone.url cluster to the\ncluster of your test. If address points to a program owned by the \"BPF\nupgradeable loader\", anchor (>= 0.23.0) will clone the program data account of\nthe program for you automatically.\nExample:\n[test.validator]\nurl = \"https://api.mainnet-beta.solana.com\"\n\n[[test.validator.clone]]\naddress = \"7NL2qWArf2BbEBBH1vTRZCsoNqFATTddH6h8GkVvrLpG\"\n[[test.validator.clone]]\naddress = \"2RaN5auQwMdg5efgCaVqpETBV8sacWGR8tkK4m9kjo5r\"\n[[test.validator.clone]]\naddress = \"metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s\" # implicitly also clones PwDiXFxQsGra4sFFTT8r1QWRMd4vfumiWC1jfWNfdYT\ntest.validator.account\nUse this to upload an account from a .json file.\nExample:\n[[test.validator.account]]\naddress = \"Ev8WSPQsGb4wfjybqff5eZNcS3n6HaMsBkMk9suAiuM\"\nfilename = \"some_account.json\"\n\n[[test.validator.account]]\naddress = \"Ev8WSPQsGb4wfjybqff5eZNcS3n6HaMsBkMk9suAiuM\"\nfilename = \"some_other_account.json\"\nsurfpool\nConfiguration for the Surfpool validator,\nwhich is the default local validator used by anchor test. Surfpool provides a\nlightweight Solana simulator with features like automatic account cloning and\nrunbook execution. All fields are optional and have sensible defaults.\nExample:\n[surfpool]\nstartup_wait = 30000 # Time (ms) to wait for Surfpool to start. Default: 30000.\nshutdown_wait = 2000 # Time (ms) to wait for Surfpool to shut down. Default: 2000.\nrpc_port = 8899 # JSON RPC port. Default: 8899.\nws_port = 8900 # WebSocket port. If not set, derived automatically.\nhost = \"127.0.0.1\" # IP address to bind to. Default: \"127.0.0.1\".\nonline = true # Enable online mode (clone accounts from a remote cluster).\ndatasource_rpc_url = \"https://api.mainnet.solana.com\" # RPC URL to use as the data source when online mode is enabled.\nairdrop_addresses = [\"addr1...\", \"addr2...\"] # Addresses to airdrop SOL to at startup.\nmanifest_file_path = \"./Cargo.toml\" # Path to the Cargo.toml manifest file.\nrunbooks = [\"./runbooks/setup.json\"] # Paths to runbook files to execute on startup.\nslot_time = 400 # Simulated slot time in milliseconds.\nlog_level = \"info\" # Log level for Surfpool. Default: \"none\".\nblock_production_mode = \"clock\" # Block production mode. Default: \"transaction\".\nstartup_wait\nTime in milliseconds to wait for Surfpool to start up. This is useful when\nloading many accounts or running runbooks at startup. Default: 30000.\nshutdown_wait\nTime in milliseconds to wait for Surfpool to shut down gracefully.\nDefault: 2000.\nrpc_port\nThe port on which Surfpool exposes its JSON RPC endpoint. Default: 8899.\nws_port\nThe port for the WebSocket endpoint. If not specified, it is derived\nautomatically.\nhost\nThe IP address to bind the Surfpool validator ports to. Default: \"127.0.0.1\".\nonline\nWhen set to true, Surfpool operates in online mode, allowing it to clone\naccounts from a remote cluster specified by datasource_rpc_url. Default:\nfalse (offline mode).\ndatasource_rpc_url\nThe RPC URL of the remote cluster used as a data source when online is\nenabled.\nExample:\n[surfpool]\nonline = true\ndatasource_rpc_url = \"https://api.mainnet.solana.com\"\nairdrop_addresses\nA list of base58-encoded addresses that will receive an airdrop of SOL when\nSurfpool starts.\nExample:\n[surfpool]\nairdrop_addresses = [\n \"Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS\",\n \"7NL2qWArf2BbEBBH1vTRZCsoNqFATTddH6h8GkVvrLpG\"\n]\nmanifest_file_path\nPath to the Cargo.toml manifest file for the workspace. Typically not needed\nsince Anchor resolves this automatically.\nrunbooks\nA list of file paths to runbooks that Surfpool will execute on startup. Runbooks\nallow you to set up initial state (deploy programs, create accounts, etc.)\nbefore tests run.\nExample:\n[surfpool]\nrunbooks = [\n \"./runbooks/setup.json\"\n]\nslot_time\nThe simulated slot time in milliseconds. Controls how fast slots advance in the\nSurfpool simulator.\nlog_level\nSets the log verbosity level for the Surfpool process. Common values include\n\"none\", \"info\", \"debug\", \"warn\", and \"error\". Default: \"none\".\nblock_production_mode\nControls how Surfpool produces blocks. Default: \"transaction\". Known values\ninclude:\n\n\"clock\" -- Produces blocks at regular time intervals based on slot_time.\n\"transaction\" -- Produces a new block for each incoming transaction.\n\nExample:\n[surfpool]\nblock_production_mode = \"clock\"\ntoolchain\nOverride toolchain data in the workspace similar to\nrust-toolchain.toml.\n[toolchain]\nanchor_version = \"1.2.0\" # `anchor-cli` version to use(requires `avm`)\nsolana_version = \"4.1.2\" # Solana version requirement to use(applies to all Solana tools)\npackage_manager = \"yarn\" # JS package manager to use\npackage_manager\nThe package_manager field indicates which package manager Anchor should use\nfor all of its client and workspace commands.\nValid values\ninclude npm, yarn, pnpm, and bun.\nIf a value is not specified, Anchor probes pnpm, yarn, then npm and uses\nthe first package manager found on PATH. Note values should be in lowercase,\nsince values are deserialized with serde(rename_all = \"lowercase\").\nExample:\n[toolchain]\npackage_manager = \"pnpm\"\nhooks\nThe hooks table allows you to configure commands that may be run at specific\nstages of the build/test/deploy pipeline.\nExample:\n[hooks]\n# Accepts kebab-case names...\npre-build = \"echo foo\"\n# ...and snake-case names\npost_build = \"echo bar\"\n# Accepts a list of commands, run in series\npre-test = [\"echo 1\", \"echo 2\"]\n# Non-zero exit codes will abort the CLI\npost-test = \"exit 1\"\n# Unused hooks may be omitted\n# pre-deploy = []\n# post-deploy = []\nregistry (removed)\nThe [registry] section is no longer supported and has been removed in 1.0.0.\nIf your Anchor.toml contains this section, remove it:\n- [registry]\n- url = \"https://anchor.projectserum.com\"PreviousAccount ConstraintsNextAnchor CLIOn this pageprovider (required)scripts (required for testing)skip_local_validatorfeaturesresolutionworkspaceidlstypesmembersexcludeclientsprogramsteststartup_waitgenesisupgradeabletest.validatortest.validator.clonetest.validator.accountsurfpoolstartup_waitshutdown_waitrpc_portws_porthostonlinedatasource_rpc_urlairdrop_addressesmanifest_file_pathrunbooksslot_timelog_levelblock_production_modetoolchainpackage_managerhooksregistry (removed)Edit on GitHub","tokens":2812,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258476920,"hash":"6f451c77c010b2e5d285503d95f0d5dc2c79556b"}
{"url":"https://aave.com/docs/aave-v4/positions/repay","domain":"aave.com","title":"Repay Loans | Aave Protocol Documentation","text":"Repay Loans#\nLearn how to repay borrowed assets to Aave v4 reserves.\n\nRepaying borrowed assets allows you to:\nReduce or eliminate your debt positionImprove your position's health factor and reduce liquidation riskFree up collateral for withdrawal or additional borrowingClose your borrow position entirely when repaying the full amount\nRepaying borrowed assets improves the position's health factor and reduces\nliquidation risk. You can repay partial amounts or the full debt amount.\nRepaying#\nRepaying a loan can be broken down into the following steps:\nIdentify the borrow position to repayPreview the impact of the repay operationRepay the borrowed assets\nIdentify the Borrow Position#\nGiven a list of the user's borrow positions, identify the position (token) you want to reduce and choose the repayment amount (partial or full).\nThe borrowed position reserve should not be paused in order to repay.\nFor example, let’s say you have identified the following UserBorrowItem object.\nconst borrowPosition: UserBorrowItem = { reserve: { id: \"SGVsbG8h\", onChainId: \"42\", chain: { chainId: 1, name: \"Ethereum\", }, spoke: { address: \"0x123…\", // … }, asset: { underlying: { address: \"0xa0b86a33e6e2ad05ad6c9ac3b6e5e5f6e7b6c1b2\", // USDC }, // … }, status: { paused: false, }, // … other reserve properties }, debt: { amount: { value: BigDecimal(512.023456), // ~512 USDC debt // … }, // … }, // …};\nKeep in mind that repaying:\nImproves your health factor, reducing liquidation risk.Frees up collateral, making it available for withdrawal or additional borrowing.Can be partial (reducing debt but keeping the position open) or full (closing the borrow position entirely).\nPreview Repay#\nPreview the impact of a repay operation before committing to it.\nReactTypeScriptGraphQLSolidityUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the repay operation on the user's position.import { type RepayRequest, usePreview } from \"@aave/react\";\nfunction RepayPreview({ request }: { request: RepayRequest }) { const { data, error, loading } = usePreview({ action: { repay: request, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor?.current ?? \"N/A\"}</p> <p>To: {data.healthFactor?.after ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p> </div> );}Where the RepayRequest can be as follows:const request: RepayRequest = { sender: evmAddress(\"0x789…\"), // User's address reserve: borrowPosition.reserve.id, amount: { erc20: { value: { exact: bigDecimal(250), // 250 USDC }, }, },};The PreviewUserPosition shows the impact of the repay operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is betternetCollateral.[current → after]: ExchangeAmountHigher is betternetBalance.[current → after]: ExchangeAmountUpdated balancemaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerYou can also specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = usePreview({ action: { repay: request, }, currency: Currency.Eur,});\nStep-by-Step#\nNow that we know how to identify a borrow position to repay, and we know how to preview the impact of a repay operation, let's see how to repay assets for this position.\nRepaying ERC-20 tokens requires token approval. You can choose between two approaches:\nTransaction-based approval — Sends a separate ERC-20 approve() transaction before the repay transaction (2 transactions total).Permit-based approval — Signs an EIP-2612 permit to approve and repay in a single transaction. More gas-efficient, but requires the token to support permits.\nReactTypeScriptGraphQLSolidityTo repay a loan with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the hooks for the wallet library of your choice:useSendTransaction — used to send ERC-20 approval and repay transactionsuseSignTypedData — used to sign ERC-20 permits when availableimport { useWalletClient } from \"wagmi\";import { useSendTransaction, useSignTypedData } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);const [signTypedData] = useSignTypedData(wallet);2Define the Repay Flow#Then, use the useRepay hook to prepare the repay operation.import { useRepay } from \"@aave/react\";\nconst [repay, { loading, error }] = useRepay((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"Erc20Approval\": // If token supports EIP-2612 permits, sign permit (recommended) if (plan.bySignature) { return signTypedData(plan.bySignature); } // Otherwise use traditional approval transaction return sendTransaction(plan.byTransaction);\n case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});In the Erc20Approval case, the bySignature field is only available if the token supports EIP-2612 permits.For tokens like USDT on Ethereum\nMainnet\nthat require an allowance reset, the hook calls your callback twice: once to\nreset the allowance to 0, then again to set the new value. bySignature will\nbe null for these approvals.3Execute the Repay Operation#Then, execute the desired repay operation.import { bigDecimal, evmAddress } from \"@aave/react\";\nconst execute = async () => { const result = await repay({ sender: evmAddress(wallet.account.address), // User's address reserve: borrowPosition.reserve.id, amount: { erc20: { value: { exact: bigDecimal(250), // Repay 250 USDC }, }, }, });\n // …};4Handle the Result#Finally, handle the result.const execute = async () => { const result = await repay(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"ValidationError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Repay successful with hash:\", result.value.txHash);};\n\nAdvanced Usage#\nNetwork Fee#\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nEstimate the network cost of any action using the same PreviewAction you pass to the usePreview hook.\nLet's consider the following example:\nimport { type PreviewAction } from \"@aave/react\";\nconst action: PreviewAction = { repay: { sender: evmAddress(\"0x123…\"), // User's address reserve: borrowPosition.reserve.id, amount: { erc20: { value: bigDecimal(42), // USDC }, }, },};\nUse the useNetworkFee hook to estimate both the network fee for the provided action and its fiat equivalent.\nimport { type PreviewAction, Currency } from \"@aave/react\";import { useNetworkFee } from \"@aave/react/viem\";\nfunction NetworkFee({ action }: { action: PreviewAction }) { const { data: fee, loading, error, } = useNetworkFee({ query: { estimate: action }, currency: Currency.Eur, });\n if (loading) return <p>Loading fee…</p>; if (error) return <p>Error: {error.message}</p>;\n return ( <p> Network Fee: {fee.amount.value.toDisplayString(2)} {fee.token.info.symbol} <span> ≈{fee.exchange.symbol} {fee.exchange.value.toDisplayString(2)} </span> </p> );}\nNative Tokens#\nWhen the Reserve's underlying token is the wrapped version of the chain's native token (e.g., WETH on Ethereum), you can repay the debt using the chain's native token with the Native Token Gateway.\nUse the reserve.asset.underlying.isWrappedNativeToken flag to determine if the underlying token is a wrapped native token. The Native Gateway address is available from the chain details.\nconst borrowPosition: UserBorrowItem = { reserve: { id: \"SGVsbG8h\", onChainId: \"42\", asset: { underlying: { address: \"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\", info: { name: \"Wrapped Ether\", symbol: \"WETH\", decimals: 18, // … }, isWrappedNativeToken: true, // … }, // … }, spoke: { address: \"0x123…\", // … }, chain: { chainId: 1, name: \"Ethereum\", nativeGateway: \"0xabc…\", }, // … }, // …};\nSpecify the amount in the amount field as a native value.\nReactTypeScriptGraphQLSolidityconst execute = async () => { const result = await repay({ sender: evmAddress(wallet.account.address), // User's address reserve: borrowPosition.reserve.id, amount: { native: { value: { exact: bigDecimal(1), // Repay 1 ETH }, }, }, });\n // …};PreviousWithdraw AssetsNextPosition Swaps","tokens":2406,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258480447,"hash":"5c628e56e9d4d11cd164f4ab6a37804fc1910d14"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/reference/development-frameworks","domain":"docs.arbitrum.io","title":"Development frameworks | Arbitrum Docs","text":"✏️Request an updateKNOW MORE TOOLS?See something missing? Let us know on the Arbitrum Discord or by opening an issue on GitHub.\nThe following tools will help you develop and test your decentralized apps (dApps):\nHardhat​\nHardhat is a comprehensive development environment designed specifically for Ethereum, Arbitrum and, in general, EVM developers. It streamlines the process of creating, compiling, deploying, testing, and debugging smart contracts. By providing a robust and customizable framework, Hardhat makes it easy to manage complex projects and integrate with other tools in the ecosystem. Its features include a built-in console, advanced debugging capabilities, and support for extending functionality through plugins, allowing developers to create efficient and secure decentralized applications.\nFoundry​\nFoundry is a high-performance, portable, and modular toolkit designed for EVM application development, leveraging the Rust programming language. It offers a comprehensive suite of tools to streamline the process of creating, testing, and deploying smart contracts on the Ethereum, Arbitrum and, in general, any EVM network. Foundry facilitates interactions with EVM smart contracts, transactions, and chain data, while also providing a local node and a user-friendly Solidity REPL environment for efficient development. For a walkthrough that uses Foundry on Arbitrum, see Create a token using Foundry.\nthirdweb​\nthirdweb SDK covers all aspects of the Web3 development stack, including connecting to user’s wallets, interacting with the blockchain and smart contracts, decentralized storage, authentication, and more; enabling you to build scalable and performant Web3 applications on any EVM-compatible blockchain. Out of the box, infrastructure is provided for everything required to create decentralized applications, including connection to the blockchain (RPC), decentralized storage (IPFS + pinning services), and tools to create powerful user experiences; such as gasless transactions, wallet connection components, FIAT on-ramps, data APIs, and more.\nBrownie​\nBrownie is a Python-based framework designed for developing and testing smart contracts on the Ethereum Virtual Machine. It offers full support for Solidity and Vyper programming languages and utilizes pytest for contract testing. Brownie also incorporates trace-based coverage evaluation, property-based and stateful testing with Hypothesis, and powerful debugging tools, including Python-style tracebacks and custom error strings.HardhatFoundrythirdwebBrownie","tokens":637,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258484104,"hash":"6cb506ce2935f7bffad93404676950253e9f410f"}
{"url":"https://www.anchor-lang.com/docs/references/cli","domain":"anchor-lang.com","title":"Anchor CLI","text":"Program DevelopmentAnchor CLIAnchor CLI reference documentationA CLI is provided to support building and managing an Anchor workspace. For a\ncomprehensive list of commands and options, run anchor -h on any of the\nfollowing subcommands.\nFor non-human or agent-driven usage, see NO_DNA.\n\nUsage: anchor [OPTIONS] <COMMAND>\n\nCommands:\n init Initializes a workspace\n build Builds the workspace\n expand Expands macros (wrapper around cargo expand)\n verify Verifies the on-chain bytecode matches the locally compiled artifact. Run this command inside a program subdirectory, i.e., in the dir containing the program's Cargo.toml\n test Runs integration tests\n fuzz Coverage-guided fuzzing for Solana programs (powered by Crucible)\n new Creates a new program\n debugger Run tests under an instruction-level debugger\n coverage Generate source-level coverage from SBF register traces\n idl Commands for interacting with interface definitions\n clean Remove all artifacts from the generated directories except program keypairs\n migrate Runs the deploy migration script\n airdrop Request an airdrop of SOL\n cluster Cluster commands\n config Configuration management commands\n shell Starts a node shell with an Anchor client setup according to the local config\n run Runs the script defined by the current workspace's Anchor.toml\n keys Program keypair commands\n localnet Localnet commands\n account Fetch and deserialize an account using the IDL provided\n completions Generates shell completions\n address Get your public key\n balance Get your balance\n epoch Get current epoch\n epoch-info Get information about the current epoch\n logs Stream transaction logs\n show-account Show the contents of an account\n keygen Keypair generation and management\n program Program deployment and management commands\n codama Codama IDL integration commands\n legacy-idl [DEPRECATED] Manage legacy on-chain IDL accounts. Migrate to Program Metadata-based IDL management (`anchor idl`)\n help Print this message or the help of the given subcommand(s)\n\nOptions:\n --provider.cluster <CLUSTER> Cluster override\n --provider.wallet <WALLET> Wallet override\n --commitment <COMMITMENT> Commitment override (valid values: processed, confirmed, finalized)\n -h, --help Print help\n -V, --version Print version\nAccount\nanchor account <program-name>.<AccountTypeName> <account_pubkey>\nFetches an account with the given public key and deserializes the data to JSON\nusing the type name provided. If this command is run from within a workspace,\nthe workspace's IDL files will be used to get the data types. Otherwise, the\npath to the IDL file must be provided.\nThe program-name is the name of the program where the account struct resides,\nusually under programs/<program-name>. program-name should be provided in a\ncase-sensitive manner exactly as the folder name, usually in kebab-case.\nThe AccountTypeName is the name of the account struct, usually in PascalCase.\nThe account_pubkey refers to the Pubkey of the account to deserialize, in\nBase58.\nExample Usage:\nanchor account anchor-escrow.EscrowAccount 3PNkzWKXCsbjijbasnx55NEpJe8DFXvEEbJKdRKpDcfK,\ndeserializes an account in the given pubkey with the account struct\nEscrowAccount defined in the anchor-escrow program.\nanchor account <program-name>.<AccountTypeName> <account_pubkey> --idl <path/to/idl.json>\nDeserializes the account with the data types provided in the given IDL file even\nif inside a workspace.\nBuild\nanchor build\nBuilds programs in the workspace targeting Solana's BPF runtime and emitting\nIDLs in the target/idl directory.\nAnchor passes --tools-version v1.57 and --arch v3 to cargo build-sbf by\ndefault. Override them with anchor build --tools-version <VERSION> --arch <ARCH>.\nPrograms built with --arch v3 require compatible local test tooling:\nplatform-tools v1.53 or newer, a Solana/Agave 4.0 or newer\nsolana-test-validator, Surfpool 1.4 or newer, and LiteSVM 0.13.1 or newer.\nanchor build --verifiable\nRuns the build inside a docker image so that the output binary is deterministic\n(assuming a Cargo.lock file is used). This command must be run from within a\nsingle crate subdirectory within the workspace. For example,\nprograms/<my-program>/.\nTipIt's possible to pass arguments to the underlying cargo build-sbf command with -- <ARGS>. For example:anchor build -- --features my-feature\nCluster\nCluster list\nanchor cluster list\nThis lists cluster endpoints:\nCluster Endpoints:\n\n* Mainnet - https://api.mainnet-beta.solana.com\n* Devnet - https://api.devnet.solana.com\n* Testnet - https://api.testnet.solana.com\nDeploy\nanchor deploy\nDeploys all programs in the workspace to the configured cluster.\nTipThis is different from the solana program deploy command, because every time\nit's run it will generate a new program address.\nExpand\nanchor expand\nIf run inside a program folder, expands the macros of the program.\nIf run in the workspace but outside a program folder, expands the macros of the\nworkspace.\nIf run with the --program-name option, expand only the given program.\nIdl\nThe idl subcommand provides commands for interacting with interface definition\nfiles. Anchor uses the Program Metadata\nsystem to store IDLs on-chain at a deterministic address derived from the\nprogram's ID. This allows clients to be generated for a program using nothing\nbut the program ID.\nIDL management uses the @solana-program/program-metadata\npackage instead of legacy IDL instructions. This results in smaller program\nbinaries and a more standardized approach to on-chain metadata.\nIdl Build\nanchor idl build\nGenerates the IDL for the program using the compilation method.\nIdl Init\nanchor idl init -f <target/idl/program.json> [program-id]\nCreates a metadata account containing the IDL for the given program. The IDL\nfile is written to an account derived from the program ID.\nanchor idl init -f <target/idl/program.json> <program-id> --non-canonical\nUse the --non-canonical flag to create a third-party (non-canonical) metadata\naccount. This is useful when you want to store metadata for a program you don't\nown.\nThe program-id argument is optional — when omitted, idl.address is used.\nIdl Fetch\nanchor idl fetch -o <out-file.json> <program-id>\nFetches an IDL from the configured blockchain. For example, make sure your\nAnchor.toml is pointing to the mainnet cluster and run\nanchor idl fetch GrAkKfEpTKQuVHG2Y97Y2FF4i7y7Q5AHLK94JBy7Y5yv\nUse the --non-canonical flag to fetch third-party metadata:\nanchor idl fetch <program-id> --non-canonical\nIdl Upgrade\nanchor idl upgrade -f <target/idl/program.json>\nUpgrades the IDL file on chain to the new target/idl/program.json idl. The\nconfigured wallet must be the current authority. The program-id argument is\noptional — when omitted, idl.address is used.\nIdl Close\nanchor idl close <program-id>\nCloses the metadata account and recovers the rent. By default, closes the \"idl\"\nseed account. Use --seed to specify a different seed:\nanchor idl close <program-id> --seed <custom-seed>\nIdl Create Buffer\nanchor idl create-buffer -f <filepath>\nCreates a buffer account for metadata. This is useful for large IDLs that need\nto be written across multiple transactions.\nIdl Set Buffer Authority\nanchor idl set-buffer-authority <buffer> -n <new-authority>\nSets a new authority on a buffer account.\nIdl Write Buffer\nanchor idl write-buffer <program-id> -b <buffer>\nWrites metadata to the program using a pre-created buffer account. Use\n--seed to specify the metadata seed (defaults to \"idl\"):\nanchor idl write-buffer <program-id> -b <buffer> --seed <seed>\nUse --close-buffer to automatically close the buffer account after writing:\nanchor idl write-buffer <program-id> -b <buffer> --close-buffer\nCodama\nanchor codama convert <target/idl/program.json> --out <codama-idl.json>\nanchor codama generate -l rust,js -p clients <target/idl/program.json>\nanchor codama convert converts an Anchor IDL into a Codama IDL. anchor codama generate converts the IDL and invokes the Codama renderer packages for\nthe requested languages. The supported language values are js, js-umi,\nrust, and go.\nCodama client generation can also run automatically after anchor build when\n[clients] auto = true is set in Anchor.toml.\nCodama\nanchor codama convert <target/idl/program.json> --out <codama-idl.json>\nanchor codama generate -l rust,js -p clients <target/idl/program.json>\nanchor codama convert converts an Anchor IDL into a Codama IDL. anchor codama generate converts the IDL and invokes the Codama renderer packages for\nthe requested languages. The supported language values are js, js-umi,\nrust, and go.\nCodama client generation can also run automatically after anchor build when\n[clients] auto = true is set in Anchor.toml.\nInit\nanchor init <project-name>\nInitializes a project workspace with the following structure.\n\nAnchor.toml: Anchor configuration file.\nCargo.toml: Rust workspace configuration file.\npackage.json: JavaScript dependencies file.\nprograms/: Directory for Solana program crates.\napp/: Directory for your application frontend.\ntests/: Directory for JavaScript integration tests.\nmigrations/deploy.js: Deploy script.\n\nBy default, programs are initialized with a modular structure (multiple\nfiles) to promote better code organization. This is the recommended approach for\nproduction code.\nTemplate Options:\nanchor init --template multiple # Default: Modular structure (recommended)\nanchor init --template single # Single lib.rs file (for prototyping)\nThe modular template organizes code into separate files for instructions, state,\nconstants, and errors, making it easier to navigate and maintain as your program\ngrows.\nAnchor Version:\nanchor init --anchor-version v1 # Default: Anchor v1 Rust templates\nanchor init --anchor-version v2 # Anchor v2 Rust templates\nThe selected Anchor version controls the generated Rust program and Rust test\ntemplate dependencies. V2 templates use the anchor-next git dependencies until\nthe v2 crates are published.\nKeys\nProgram keypair commands.\nKeys List\nanchor keys list\nList all of the program keys.\nKeys Sync\nanchor keys sync\nSync program declare_id! pubkeys with the program's actual pubkey.\nMigrate\nanchor migrate\nRuns the deploy script located at migrations/deploy.js, injecting a provider\nconfigured from the workspace's Anchor.toml. For example,\n// File: migrations/deploys.js\n\nconst anchor = require(\"@anchor-lang/core\");\n\nmodule.exports = async function (provider) {\n anchor.setProvider(provider);\n\n // Add your deploy script here.\n};\nMigrations are a new feature and only support this simple deploy script at the\nmoment.\nNew\nanchor new <program-name>\nCreates a new program in the workspace's programs/ directory initialized with\nboilerplate.\nBy default, uses the modular structure template (recommended). You can\nspecify a different template with the --template flag:\nanchor new --template multiple <program-name> # Default: Modular (recommended)\nanchor new --template single <program-name> # Single file (for prototyping)\nYou can also select the Anchor Rust template version:\nanchor new --anchor-version v1 <program-name> # Default: Anchor v1 Rust templates\nanchor new --anchor-version v2 <program-name> # Anchor v2 Rust templates\nShell\nanchor shell\nStarts a node js shell with an Anchor client setup according to the local\nconfig. This client can be used to interact with deployed Solana programs in the\nworkspace.\nTest\nanchor test\nRun an integration test suit against the configured cluster, deploying new\nversions of all workspace programs before running them.\nIf the configured network is a localnet, then automatically starts the\nlocal network and runs the test. By default, Surfpool\nis used as the local network backend. To use solana-test-validator instead,\npass --validator legacy.\nNoteBe sure to shutdown any other local validators, otherwise anchor test will fail to run.If you'd prefer to run the program against your local validator use\nanchor test --skip-local-validator.\nWhen running tests we stream program logs to\n.anchor/program-logs/<address>.<program-name>.log\nUse --profile with Rust/LiteSVM-style tests that enable the generated\nprofile feature to collect SBF register traces and render flamegraph SVGs\nunder target/anchor-v2-profile/.\nDebugger\nanchor debugger [test-name] [--skip-run] [--skip-build] [--gdb]\nRuns tests with profiling enabled and opens an instruction-level TUI over the\ncaptured SBF traces. --skip-run reuses existing traces, and --gdb uses the\nsbpf gdb-stub trace path.\nCoverage\nanchor coverage [--skip-run] [--skip-build] [--output target/coverage/sbf.lcov]\nGenerates LCOV source coverage from SBF register traces. By default traces are\ncollected under target/coverage/traces.\nUpgrade\nanchor upgrade <target/deploy/program.so> --program-id <program-id>\nUses Solana's upgradeable BPF loader to upgrade the on chain program code.\nVerify\nanchor verify <program-id>\nVerifies the on-chain bytecode matches the locally compiled artifact.PreviousAnchor.toml ConfigurationNextNO_DNAOn this pageAccountBuildClusterCluster listDeployExpandIdlIdl BuildIdl InitIdl FetchIdl UpgradeIdl CloseIdl Create BufferIdl Set Buffer AuthorityIdl Write BufferCodamaCodamaInitKeysKeys ListKeys SyncMigrateNewShellTestDebuggerCoverageUpgradeVerifyEdit on GitHub","tokens":3288,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258488062,"hash":"3459834688ece9535279be097a63dd531d37e849"}
{"url":"https://aave.com/docs/aave-v4/positions/swaps","domain":"aave.com","title":"Position Swaps | Aave Protocol Documentation","text":"Position Swaps#\nLearn how to modify your Aave v4 positions using integrated swap operations.\n\nPosition swaps combine swap functionality with User Position operations, letting you:\nSwap Supply Asset — Convert a supplied position to a different tokenSwap Borrow Asset — Convert borrowed debt to a different tokenRepay with Supply — Use any supplied position to pay down debt directlyWithdraw and Swap — Withdraw assets and receive a different token\nThis feature leverages CoW Protocol for swap execution. Position swaps are gasless—users sign an intent and solvers handle execution. This eliminates gas costs while providing MEV protection and optimal execution through batch auctions.\nReview the Fees section to understand swap costs.\nSwap Supply Asset#\nSwapping supply assets combines withdraw, swap, and re-supply into one gasless step.\nCommon scenarios:\nScenarioDescriptionLiquidation Risk ReductionUser wants to swap volatile collateral to stable assets to reduce liquidation riskBetter RatesUser wants to switch supply position to a reserve with better rates (regardless of being used as collateral or not)Replenish CollateralUser wants to use a non-collateral supply to replenish a collateral position to gain more borrowing power at the same risk levelBetter Risk PremiumUser wants to consolidate collateral to a less risky asset (lower Collateral Risk) to reduce the risk premium on borrows\nSwapping supply assets can be broken down into the following steps:\nIdentify the supply position to swap fromChoose the target reserve to swap ontoChoose between market order and limit orderExecute the swap operation\nSupply Position#\nIdentify the supply position among the user's supply positions where reserve.canSwapFrom: true.\nconst supplyPosition: UserSupplyItem = { id: \"aGVsbG8\", reserve: { id: \"SGVsbG8h\", canSwapFrom: true, chain: { chainId: 1, name: \"Ethereum\", }, spoke: { id: \"aGVsbG8\", // … }, // … }, isCollateral: true, balance: { amount: { value: BigDecimal(5000.0), exchange: { value: BigDecimal(5000.0), // … }, // … }, // … }, withdrawable: { amount: { value: BigDecimal(0.03), exchange: { value: BigDecimal(100.0), // … }, // … }, // … }, // …};\nThe reserve.canSwapFrom flag confirms that the correponding reserve isn't\npaused and flash loans are enabled on it.\nTarget Reserve#\nChoose the target reserve where canSupply: true. The target reserve must be on the same spoke as the source supply position.\nLike with typical supply operations, the canSupply flag confirms that the\nreserve is active: it isn't frozen, it isn't paused, and the supply cap has\nnot been reached.\nconst targetReserve: Reserve = { id: \"V29ybGQh\", canSupply: true, canUseAsCollateral: true, spoke: { id: \"aGVsbG8\", // … }, asset: { underlying: { address: \"0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48\", info: { name: \"USD Coin\", symbol: \"USDC\", decimals: 6, // … }, // … }, // … }, summary: { supplyApy: { normalized: BigDecimal(4.5), // 4.5% APY // … }, // … }, userState: { suppliable: { exchange: { value: BigDecimal(1245.67), name: \"USD\", symbol: \"$\", // … }, // … }, }, // …};\nConsider the following factors when selecting a target reserve:\nToken: Check asset.underlying for the token of the new supply positionCollateral: Verify canUseAsCollateral if collateral is neededCapacity: Review userState.suppliable for sufficient supply capacityRate: Compare summary.supplyApy for favorable APY\nMarket or Limit Order#\nYou decide whether to use a market order or a limit order.\nMarket OrderLimit OrderMarket orders execute at current rates.const request: SupplySwapQuoteRequest = { market: { sellPosition: supplyPosition.id, buyReserve: targetReserve.id, enableCollateral: supplyPosition.isCollateral && targetReserve.canUseAsCollateral, amount: bigDecimal(0.03), user: evmAddress(\"0x123…\"), // selectedSlippage: bigDecimal(1), // Optional: override suggested slippage },};The request takes the following parameters:sellPosition — The current supply position to swap frombuyReserve — The target reserve to swap toenableCollateral — Whether to enable the new position as collateralamount — The amount of the current position to swapuser — The user's addressselectedSlippage — Optional slippage tolerance to use instead of the suggested slippage\nThe enableCollateral flag controls the destination supply’s collateral status: true enables it as collateral; false keeps the existing status (or non-collateral for a new position). The examples assume the target reserve allows collateral and mirror the source’s collateral state; adjust to fit your scenario.\nExecute the Swap#\nReactTypeScriptGraphQLTo execute a supply swap with AaveKit React, follow these steps.1Get a Quote#First, use the useSupplySwapQuote hook (or the imperative useSupplySwapQuoteAction variant) to get pricing information for the swap.import { type SupplySwapQuoteRequest, useSupplySwapQuote } from \"@aave/react\";\nfunction SwapQuote({ request }: { request: SupplySwapQuoteRequest }) { const { data, loading, error } = useSupplySwapQuote(request);\n if (loading) return <p>Loading…</p>;\n if (error) { if (error.name === \"ValidationError\") { switch (error.cause.__typename) { case \"InsufficientLiquidityError\": return <p>Not enough liquidity for this swap</p>; } } return <p>{error.message}</p>; }\n // data: SwapQuote return ( <div> <p>You will receive: {data.finalBuy.amount.value.toDisplayString()}</p> <p>Partner fee: {data.costs.partnerFee.amount.value.toDisplayString()}</p> <p>Slippage: {data.suggestedSlippage.normalized}%</p> </div> );}You can specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = useSupplySwapQuote({ ...request, currency: Currency.Eur,});The SwapQuote object provides detailed pricing information for swap operations.\ninterface SwapQuote { __typename: \"SwapQuote\"; accuracy: QuoteAccuracy; quoteId: SwapId; suggestedSlippage: PercentNumber; selectedSlippage: PercentNumber | null; buy: TokenAmount; sell: TokenAmount; finalBuy: TokenAmount; finalSell: TokenAmount; costs: SwapQuoteCosts;}\nWhere:\naccuracy — quote accuracy level (QuoteAccuracy.Fast or QuoteAccuracy.Accurate)quoteId — a unique quote identifier required for executing the swapbuy and sell — current prices before feesfinalBuy and finalSell — amounts you'll receive/pay after fees and slippagecosts — a breakdown of all fees (partner fee, provider fee, flash loan fee, network costs)suggestedSlippage — recommended slippage toleranceselectedSlippage — the slippage tolerance selected when requesting a market quote (if provided)2Preview the Impact#Then, use the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the swap operation on the user's position.import { type SwapQuote, usePreview } from \"@aave/react\";\nfunction SwapPreview({ quote }: { quote: SwapQuote }) { const { data, error, loading } = usePreview({ action: { supplySwap: { fromQuote: { quoteId: quote.quoteId, }, }, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor.current?.value.toFixed(2) ?? \"N/A\"}</p> <p>To: {data.healthFactor.after?.value.toFixed(2) ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p>\n <h3>Max Borrowing Power:</h3> <p>From: {data.maxBorrowingPower.current.value.toDisplayString(2)}</p> <p>To: {data.maxBorrowingPower.after.value.toDisplayString(2)}</p> </div> );}The PreviewUserPosition shows the impact of the swap operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is betternetCollateral.[current → after]: ExchangeAmountHigher is betternetBalance.[current → after]: ExchangeAmountUpdated balanceprojectedEarning.[current → after]: ExchangeAmountProjected earningsmaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerotherConditions: UserPositionConditionVariation[]Dynamic config changes\nWhen swapping supply positions, Position Conditions update depending on the collateral status:\nSwapping collateral: Swapping out of collateral updates the dynamic config for all reserves in the position and refreshes the user risk premium.Swapping non-collateral into collateral: The reserve being swapped into uses the latest dynamic config, with no implicit risk premium changes.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus change3Configure Wallet Integration#Then, instantiate the useSignTypedData hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSignTypedData } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [signTypedData] = useSignTypedData(wallet);4Define the Swap Flow#Then, use the useSupplySwap hook to handle the operation.import { useSupplySwap } from \"@aave/react\";\nconst [swapSupply, { loading, error }] = useSupplySwap((plan) => { switch (plan.__typename) { case \"PositionSwapAdapterContractApproval\": case \"PositionSwapPositionManagerApproval\": return signTypedData(plan.bySignature);\n case \"SwapByIntent\": return signTypedData(plan.data); }});The operation involves up to 3 signatures:Swap adapter contract approval: A one-time-use contract that encapsulates the swap logic. This signature ensures the contract is used only once for this specific swap operation.Swap position manager approval: Authorizes a dedicated Position Manager to operate on the user's position.Swap intent: The actual swap order containing swap parameters and the adapter contract and position manager approval signatures.5Execute the Operation#Then, execute the swap for the given quote.const execute = async (quote: SwapQuote) => { const result = await swapSupply({ fromQuote: { quoteId: quote.quoteId, }, });\n if (result.isErr()) { console.error(result.error); return; }\n console.log(\"Swap order placed:\", result.value);};6Handle the Result#Finally, handle the result.if (result.isErr()) { switch (result.error.name) { case \"CancelError\": return;\n case \"SigningError\": console.error(`Failed to sign: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Failed: ${result.error.message}`); break;\n case \"ValidationError\": switch (result.error.cause.__typename) { case \"InsufficientBalanceError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break; case \"InsufficientLiquidityError\": console.error(`Insufficient liquidity: ${result.error.cause.reason}`); break; } break;\n case \"UnexpectedError\": console.error(result.error.message); break; }} else { console.log(\"Swap order placed:\", result.value);}That's it—you placed your first supply swap order. Keep track of its status in the Monitor Swap Status section.\nSwap Borrow Asset#\nSwapping borrow assets combines repay, swap, and re-borrow into one gasless step.\nCommon scenarios:\nScenarioDescriptionRate OptimizationUser wants to switch debt from a high-interest token to a lower-interest one (e.g., USDC → GHO)Risk ManagementUser wants to match their debt currency to their income or collateral to reduce currency exposureLiquidation AvoidanceUser wants to swap volatile debt (e.g., ETH-denominated) to stable debt (e.g., USDC) to avoid liquidation\nSwapping borrow assets can be broken down into the following steps:\nIdentify the borrow position to swap fromChoose the target reserve to swap ontoChoose between market order and limit orderExecute the swap operation\nBorrow Position#\nIdentify the borrow position among the user's borrow positions where reserve.canSwapFrom: true.\nconst borrowPosition: UserBorrowItem = { id: \"Ym9ycm93\", reserve: { id: \"SGVsbG8h\", canSwapFrom: true, chain: { chainId: 1, name: \"Ethereum\", }, spoke: { id: \"aGVsbG8\", // … }, // … }, debt: { amount: { value: BigDecimal(1000.0), exchange: { value: BigDecimal(1000.0), // … }, // … }, // … }, principal: { amount: { value: BigDecimal(950.0), // … }, // … }, interest: { amount: { value: BigDecimal(50.0), // … }, // … }, // …};\nThe reserve.canSwapFrom flag confirms that the corresponding reserve isn't\npaused and flash loans, required to perform the swap, are enabled.\nTarget Reserve#\nChoose the target reserve where canBorrow: true. The target reserve must be on the same spoke as the source borrow position.\nLike with typical borrow operations, the canBorrow flag confirms that the\nreserve is active: it isn't frozen, it isn't paused, and the borrow cap has\nnot been reached.\nconst targetReserve: Reserve = { id: \"V29ybGQh\", canBorrow: true, spoke: { id: \"aGVsbG8\", // … }, asset: { underlying: { address: \"0x40d16fc0246ad3160ccc09b8d0d3a2cd28ae6c2f\", info: { name: \"GHO\", symbol: \"GHO\", decimals: 18, // … }, // … }, // … }, summary: { borrowApy: { normalized: BigDecimal(2.5), // 2.5% APY // … }, // … }, userState: { borrowable: { exchange: { value: BigDecimal(5000.0), name: \"USD\", symbol: \"$\", // … }, // … }, }, // …};\nConsider the following factors when selecting a target reserve:\nToken: Check asset.underlying for the token of the new debt positionCapacity: Review userState.borrowable for sufficient borrow capacityRate: Compare summary.borrowApy for favorable borrowing rates\nMarket or Limit Order#\nYou decide whether to use a market order or a limit order.\nMarket OrderLimit OrderMarket orders execute at current rates.const request: BorrowSwapQuoteRequest = { market: { debtPosition: borrowPosition.id, buyReserve: targetReserve.id, amount: bigDecimal(1000), user: evmAddress(\"0x123…\"), // selectedSlippage: bigDecimal(1), // Optional: override suggested slippage },};The request takes the following parameters:debtPosition — The current borrow position to swap frombuyReserve — The target reserve to swap toamount — The amount of the current debt to swapuser — The user's addressselectedSlippage — Optional slippage tolerance to use instead of the suggested slippage\nExecute the Swap#\nReactTypeScriptGraphQLTo execute a borrow swap with AaveKit React, follow these steps.1Get a Quote#First, use the useBorrowSwapQuote hook (or the imperative useBorrowSwapQuoteAction variant) to get pricing information for the swap.import { type BorrowSwapQuoteRequest, useBorrowSwapQuote } from \"@aave/react\";\nfunction SwapQuote({ request }: { request: BorrowSwapQuoteRequest }) { const { data, loading, error } = useBorrowSwapQuote(request);\n if (loading) return <p>Loading…</p>;\n if (error) { if (error.name === \"ValidationError\") { switch (error.cause.__typename) { case \"InsufficientLiquidityError\": return <p>Not enough liquidity for this swap</p>; } } return <p>{error.message}</p>; }\n // data: SwapQuote return ( <div> <p>New debt amount: {data.finalBuy.amount.value.toDisplayString()}</p> <p>Partner fee: {data.costs.partnerFee.amount.value.toDisplayString()}</p> <p>Slippage: {data.suggestedSlippage.normalized}%</p> </div> );}You can specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = useBorrowSwapQuote({ ...request, currency: Currency.Eur,});The SwapQuote object provides detailed pricing information for swap operations.\ninterface SwapQuote { __typename: \"SwapQuote\"; accuracy: QuoteAccuracy; quoteId: SwapId; suggestedSlippage: PercentNumber; selectedSlippage: PercentNumber | null; buy: TokenAmount; sell: TokenAmount; finalBuy: TokenAmount; finalSell: TokenAmount; costs: SwapQuoteCosts;}\nWhere:\naccuracy — quote accuracy level (QuoteAccuracy.Fast or QuoteAccuracy.Accurate)quoteId — a unique quote identifier required for executing the swapbuy and sell — current prices before feesfinalBuy and finalSell — amounts you'll receive/pay after fees and slippagecosts — a breakdown of all fees (partner fee, provider fee, flash loan fee, network costs)suggestedSlippage — recommended slippage toleranceselectedSlippage — the slippage tolerance selected when requesting a market quote (if provided)2Preview the Impact#Then, use the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the swap operation on the user's position.import { type SwapQuote, usePreview } from \"@aave/react\";\nfunction SwapPreview({ quote }: { quote: SwapQuote }) { const { data, error, loading } = usePreview({ action: { borrowSwap: { fromQuote: { quoteId: quote.quoteId, }, }, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor.current?.value.toFixed(2) ?? \"N/A\"}</p> <p>To: {data.healthFactor.after?.value.toFixed(2) ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p>\n <h3>Max Borrowing Power:</h3> <p>From: {data.maxBorrowingPower.current.value.toDisplayString(2)}</p> <p>To: {data.maxBorrowingPower.after.value.toDisplayString(2)}</p> </div> );}The PreviewUserPosition shows the impact of the swap operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is better (less negative for net borrowers)netCollateral.[current → after]: ExchangeAmountUpdated collateral valuenetBalance.[current → after]: ExchangeAmountUpdated balanceprojectedEarning.[current → after]: ExchangeAmountProjected earningsmaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerotherConditions: UserPositionConditionVariation[]Dynamic config changes\nSwap borrowing assets updates the Dynamic Config and User Risk Premium of the user position.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus change3Configure Wallet Integration#Then, instantiate the useSignTypedData hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSignTypedData } from \"@aave/react/viem\";// …\nconst { data: wallet } = useWalletClient();const [signTypedData] = useSignTypedData(wallet);4Define the Swap Flow#Then, use the useBorrowSwap hook to handle the operation.import { useBorrowSwap } from \"@aave/react\";\nconst [swapBorrow, { loading, error }] = useBorrowSwap((plan) => { switch (plan.__typename) { case \"PositionSwapAdapterContractApproval\": case \"PositionSwapPositionManagerApproval\": return signTypedData(plan.bySignature);\n case \"SwapByIntent\": return signTypedData(plan.data); }});The operation involves up to 3 signatures:Swap adapter contract approval: A one-time-use contract that encapsulates the swap logic. This signature ensures the contract is used only once for this specific swap operation.Swap position manager approval: Authorizes a dedicated Position Manager to operate on the user's position.Swap intent: The actual swap order containing swap parameters and the adapter contract and position manager approval signatures.5Execute the Operation#Then, execute the swap for the given quote.const execute = async (quote: SwapQuote) => { const result = await swapBorrow({ fromQuote: { quoteId: quote.quoteId, }, });\n if (result.isErr()) { console.error(result.error); return; }\n console.log(\"Swap order placed:\", result.value);};6Handle the Result#Finally, handle the result.if (result.isErr()) { switch (result.error.name) { case \"CancelError\": return;\n case \"SigningError\": console.error(`Failed to sign: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Failed: ${result.error.message}`); break;\n case \"ValidationError\": switch (result.error.cause.__typename) { case \"InsufficientBalanceError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break; case \"InsufficientLiquidityError\": console.error(`Insufficient liquidity: ${result.error.cause.reason}`); break; } break;\n case \"UnexpectedError\": console.error(result.error.message); break; }} else { console.log(\"Swap order placed:\", result.value);}That's it—you placed your first borrow swap order. Keep track of its status in the Monitor Swap Status section.\nRepay with Supply#\nRepay with supply combines withdraw, swap, and repay into one gasless step.\nCommon scenarios:\nScenarioDescriptionAvoid LiquidationUser wants to improve Health Factor by repaying debt using their supplyRebalance PositionsUser wants to consolidate stablecoin exposure by using idle supply to pay off debt in a different stablecoinReduce Debt ExposureUser wants to reduce debt load by converting non-collateral supply into debt repayment\nRepaying with a supply position reduces your supplied balance. If the asset is\nused as collateral, ensure your remaining position maintains a healthy state.\nRepay with supply can be broken down into the following steps:\nIdentify the supply position to use for repaymentIdentify the borrow position to repayChoose between market order and limit orderExecute the swap operation\nSupply Position#\nIdentify the supply position among the user's supply positions where reserve.canSwapFrom: true.\nconst supplyPosition: UserSupplyItem = { id: \"c3VwcGx5\", reserve: { id: \"SGVsbG8h\", canSwapFrom: true, chain: { chainId: 1, name: \"Ethereum\", }, spoke: { id: \"aGVsbG8\", // … }, // … }, isCollateral: true, balance: { amount: { value: BigDecimal(5000.0), exchange: { value: BigDecimal(5000.0), // … }, // … }, // … }, principal: { amount: { value: BigDecimal(4800.0), // … }, // … }, interest: { amount: { value: BigDecimal(200.0), // … }, // … }, // …};\nThe reserve.canSwapFrom flag confirms that the corresponding reserve isn't\npaused and flash loans, required to perform the swap, are enabled.\nBorrow Position#\nIdentify the borrow position among the user's borrow positions to repay.\nconst borrowPosition: UserBorrowItem = { id: \"Ym9ycm93\", reserve: { id: \"V29ybGQh\", spoke: { id: \"aGVsbG8\", // … }, // … }, debt: { amount: { value: BigDecimal(1000.0), exchange: { value: BigDecimal(1000.0), // … }, // … }, // … }, principal: { amount: { value: BigDecimal(950.0), // … }, // … }, interest: { amount: { value: BigDecimal(50.0), // … }, // … }, // …};\nThe supply and borrow positions must be on the same spoke. The supply\nposition's reserve is what gets swapped and used to repay the debt.\nMarket or Limit Order#\nYou decide whether to use a market order or a limit order.\nMarket OrderLimit OrderMarket orders execute at current rates.const request: RepayWithSupplyQuoteRequest = { market: { debtPosition: borrowPosition.id, repayWithReserve: supplyPosition.reserve.id, amount: bigDecimal(1000), user: evmAddress(\"0x123…\"), // kind: RepayWithSupplyKind.Repay, // Optional: specify repay or supply priority // selectedSlippage: bigDecimal(1), // Optional: override suggested slippage },};The request takes the following parameters:debtPosition — The borrow position with debt to repayrepayWithReserve — The reserve of the supply position to use for repaymentamount — The swap amount, interpreted based on kinduser — The user's addresskind — Repay (default) or Supply, determines how amount is interpretedselectedSlippage — Optional slippage tolerance to use instead of the suggested slippageSince only one amount is provided, the kind parameter determines how it's interpreted:KindUser inputs…System calculates…Repay (default)The debt amount to repayThe supply amount neededSupplyThe supply amount to useThe debt amount that will be repaid\nExecute the Swap#\nReactTypeScriptGraphQLTo execute a repay with supply swap with AaveKit React, follow these steps.1Get a Quote#First, use the useRepayWithSupplyQuote hook (or the imperative useRepayWithSupplyQuoteAction variant) to get pricing information for the swap.import { type RepayWithSupplyQuoteRequest, useRepayWithSupplyQuote,} from \"@aave/react\";\nfunction SwapQuote({ request }: { request: RepayWithSupplyQuoteRequest }) { const { data, loading, error } = useRepayWithSupplyQuote(request);\n if (loading) return <p>Loading…</p>;\n if (error) { if (error.name === \"ValidationError\") { switch (error.cause.__typename) { case \"InsufficientLiquidityError\": return <p>Not enough liquidity for this swap</p>; } } return <p>{error.message}</p>; }\n // data: SwapQuote return ( <div> <p>Repay amount: {data.finalBuy.amount.value.toDisplayString()}</p> <p>Partner fee: {data.costs.partnerFee.amount.value.toDisplayString()}</p> <p>Slippage: {data.suggestedSlippage.normalized}%</p> </div> );}You can specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = useRepayWithSupplyQuote({ ...request, currency: Currency.Eur,});The SwapQuote object provides detailed pricing information for swap operations.\ninterface SwapQuote { __typename: \"SwapQuote\"; accuracy: QuoteAccuracy; quoteId: SwapId; suggestedSlippage: PercentNumber; selectedSlippage: PercentNumber | null; buy: TokenAmount; sell: TokenAmount; finalBuy: TokenAmount; finalSell: TokenAmount; costs: SwapQuoteCosts;}\nWhere:\naccuracy — quote accuracy level (QuoteAccuracy.Fast or QuoteAccuracy.Accurate)quoteId — a unique quote identifier required for executing the swapbuy and sell — current prices before feesfinalBuy and finalSell — amounts you'll receive/pay after fees and slippagecosts — a breakdown of all fees (partner fee, provider fee, flash loan fee, network costs)suggestedSlippage — recommended slippage toleranceselectedSlippage — the slippage tolerance selected when requesting a market quote (if provided)2Preview the Impact#Then, use the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the swap operation on the user's position.import { type SwapQuote, usePreview } from \"@aave/react\";\nfunction SwapPreview({ quote }: { quote: SwapQuote }) { const { data, error, loading } = usePreview({ action: { repayWithSupply: { fromQuote: { quoteId: quote.quoteId, }, }, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor.current?.value.toFixed(2) ?? \"N/A\"}</p> <p>To: {data.healthFactor.after?.value.toFixed(2) ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p>\n <h3>Max Borrowing Power:</h3> <p>From: {data.maxBorrowingPower.current.value.toDisplayString(2)}</p> <p>To: {data.maxBorrowingPower.after.value.toDisplayString(2)}</p> </div> );}The PreviewUserPosition shows the impact of the swap operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is better (less negative for net borrowers)netCollateral.[current → after]: ExchangeAmountLower after (collateral used to repay)netBalance.[current → after]: ExchangeAmountUpdated balanceprojectedEarning.[current → after]: ExchangeAmountProjected earningsmaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerotherConditions: UserPositionConditionVariation[]Dynamic config changes\nIf the supply used for repayment was enabled as collateral, the Dynamic Config and User Risk Premium of the user position will be updated.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus change3Configure Wallet Integration#Then, instantiate the useSignTypedData hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSignTypedData } from \"@aave/react/viem\";// …\nconst { data: wallet } = useWalletClient();const [signTypedData] = useSignTypedData(wallet);4Define the Swap Flow#Then, use the useRepayWithSupply hook to handle the operation.import { useRepayWithSupply } from \"@aave/react\";\nconst [repayWithSupply, { loading, error }] = useRepayWithSupply((plan) => { switch (plan.__typename) { case \"PositionSwapAdapterContractApproval\": case \"PositionSwapPositionManagerApproval\": return signTypedData(plan.bySignature);\n case \"SwapByIntent\": return signTypedData(plan.data); }});The operation involves up to 3 signatures:Swap adapter contract approval: A one-time-use contract that encapsulates the swap logic. This signature ensures the contract is used only once for this specific swap operation.Swap position manager approval: Authorizes a dedicated Position Manager to operate on the user's position.Swap intent: The actual swap order containing swap parameters and the adapter contract and position manager approval signatures.5Execute the Operation#Then, execute the swap for the given quote.const execute = async (quote: SwapQuote) => { const result = await repayWithSupply({ fromQuote: { quoteId: quote.quoteId, }, });\n if (result.isErr()) { console.error(result.error); return; }\n console.log(\"Swap order placed:\", result.value);};6Handle the Result#Finally, handle the result.if (result.isErr()) { switch (result.error.name) { case \"CancelError\": return;\n case \"SigningError\": console.error(`Failed to sign: ${result.error.message}`); break;\n case \"TimeoutError\": console.error(`Timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Failed: ${result.error.message}`); break;\n case \"ValidationError\": switch (result.error.cause.__typename) { case \"InsufficientBalanceError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break; case \"InsufficientLiquidityError\": console.error(`Insufficient liquidity: ${result.error.cause.reason}`); break; } break;\n case \"UnexpectedError\": console.error(result.error.message); break; }} else { console.log(\"Swap order placed:\", result.value);}That's it—you placed your first repay with supply order. Keep track of its status in the Monitor Swap Status section.\nWithdraw and Swap#\nWithdraw assets from your supply position and receive them as a different token in one operation.\nCommon scenarios:\nScenarioExampleTake ProfitsWithdraw WETH supply and receive USDC directly\nThis feature is coming soon. Documentation will be available upon release.PreviousRepay LoansNextPositions Managers","tokens":8158,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258490801,"hash":"a6a069055cac150cd4e92164b11b9d58249ba411"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/reference/mainnet-risks","domain":"docs.arbitrum.io","title":"Arbitrum: Understanding the risks | Arbitrum Docs","text":"✏️Request an updateArbitrum One is the first permissionless Ethereum parent chain rollup with full Ethereum smart contract functionality, and is live on mainnet — as is Nova, our first AnyTrust chain; We're sure you're (almost) as excited as we are!\nHere are some risks you should know about before using the system:\nState Of progressive decentralization​\nThe Arbitrum DAO system is the owner of both the Arbitrum One and Arbitrum AnyTrust chains; see “State of Progressive Decentralization” for more.\nGeneral words of caution: Software bugs​\nOffchain Labs’ implementation of the Arbitrum protocol has been carefully constructed, is perpetually being audited by several independent firms, and is continuously reviewed and tested following best engineering practices.\nThat said, there remains a non-zero chance that our codebase contains some undiscovered vulnerabilities that put user funds at risk. Users should carefully factor this risk into their decision to use Arbitrum One and/or Arbitrum Nova, and in deciding how much of their value to entrust into the system. Note that Offchain Labs also sponsors a multi-million dollar bug bounty program to incentivize any party who finds such a critical bug to disclose it responsibly.\nGeneral words of caution: Scams​\nArbitrum, like Ethereum, is permissionless; on both platforms, anybody can deploy any smart contract code they want. Users should treat interacting with contracts on Arbitrum exactly as they do with Ethereum, i.e., they should only do so if they have good reason to trust that the application is secure.State Of progressive decentralizationGeneral words of caution: Software bugsGeneral words of caution: Scams","tokens":419,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258494594,"hash":"c2adb1e98055ebdcd65fcd253e6c982a47d0c749"}
{"url":"https://www.anchor-lang.com/docs/references/no-dna","domain":"anchor-lang.com","title":"NO_DNA","text":"Program DevelopmentNO_DNAReference documentation for Anchor's NO_DNA supportAnchor supports the NO_DNA convention for non-human CLI usage. See\nno-dna.org. Set NO_DNA to a non-empty value when\ninvoking Anchor from an agent, automation, or another non-interactive workflow\nthat should not block on supported interactive waits or confirmation prompts.\nNO_DNA=1 is the standard example.\nUsage\nPrefix the command:\nNO_DNA=1 anchor test --detach\nNO_DNA=1 anchor localnet\nNO_DNA=1 anchor program close <ACCOUNT> --bypass-warning\nNO_DNA=1 anchor legacy-idl erase-authority --program-id <PROGRAM_ID> --bypass-warning\nOr export it for a session:\nexport NO_DNA=1\nanchor test --detach\nDestructive commands stay explicitNO_DNA does not auto-confirm destructive actions. For commands such as\nanchor program close and anchor legacy-idl erase-authority, pass the\nexisting explicit bypass flag yourself.\nChecking support from the CLI\nThe CLI help text documents NO_DNA where it applies:\nanchor --help\nanchor test --help\nanchor localnet --help\nanchor program close --help\nanchor legacy-idl erase-authority --helpPreviousAnchor CLINextAnchor Version ManagerOn this pageUsageChecking support from the CLIEdit on GitHub","tokens":299,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258502062,"hash":"87e88a3225beb7fb16646acd7a2dc6ce909d407a"}
{"url":"https://aave.com/docs/aave-v4/positions/managers","domain":"aave.com","title":"Positions Managers | Aave Protocol Documentation","text":"Position Managers#\nLearn how position managers automate and delegate position management with user control.\n\nPosition managers are smart contracts users can authorize to manage their positions, enabling automated actions like supplying, withdrawing, borrowing, and repaying — while maintaining full user control. They unlock use cases such as:\nAutomated strategies — leverage management, yield optimization, and rebalancingVault protocols — external protocols that aggregate and manage user positionsRisk management — automated liquidation protection and position adjustmentsAccount abstraction — smart contract wallets managing DeFi positions\nPosition managers operate strictly within the spoke’s security model: they can\nonly act for users who have explicitly authorized them. Users maintain full\ncontrol and can revoke access at any time.\nHow They Work#\nRegistration — Position managers are registered with a spoke through governance before users can enable them.Authorization — Users explicitly enable selected managers to act on their behalf for a given position.Delegated Operations — Authorized managers can execute position operations on behalf of users.Revocation — Users can disable a manager at any time to revoke its access.\nEach position manager is identified by its contract address and may include optional off-chain metadata, such as a name, for easier discovery.\nBuilt-in Position Managers#\nSince registration requires governance approval, custom contracts cannot register themselves as position managers. Instead, Aave v4 ships with built-in position managers that collectively expose every operation a position manager can perform. They come in two groups: gateways and delegation managers.\nGateways#\nNativeTokenGateway — enables native token support (e.g., supply and borrow ETH)SignatureGateway — enables ERC-20 Permits; see Supply and Repay for examples\nBoth contracts are automatically registered on every new spoke, and their addresses are available for convenience in the spoke's chain field:\nTypeScriptGraphQLinterface Spoke { __typename: \"Spoke\"; name: string; address: EvmAddress; chain: { __typename: \"Chain\"; // … nativeGateway: EvmAddress; signatureGateway: EvmAddress; };}\nAaveKit automatically handles user authorization of these built-in position managers as part of each operation.\nFor example, when a user supplies native tokens (e.g., ETH):\nThe SDK requests a signature authorizing the NativeTokenGateway to act on the user’s behalf for that position.The subsequent transaction sends ETH to the gateway.The gateway wraps the ETH into WETH and supplies it to the WETH reserve in the spoke on the user’s behalf.\nThis process happens automatically for other operations like borrowing, withdrawing, or repaying with native tokens, as well as when using ERC-20 permits to supply or repay. The SDK manages these flows transparently — users never need to interact with position managers directly.\nDelegation Managers#\nThree additional managers let external contracts — vaults, automation bots, or your own flash loan contract — execute position operations on behalf of users without registering as position managers themselves:\nGiverPositionManager — supplies and repays on behalf of a user (supplyOnBehalfOf, repayOnBehalfOf). The caller provides the funds, so no per-reserve allowance is required.TakerPositionManager — withdraws and borrows on behalf of a user (withdrawOnBehalfOf, borrowOnBehalfOf), sending the funds to the caller. Gated by per-reserve allowances the user grants with approveWithdraw/approveBorrow, either onchain or via EIP-712 signatures.ConfigPositionManager — updates position configuration on behalf of a user (e.g., setUsingAsCollateralOnBehalfOf). Gated by permissions the user delegates per action type.\nTo integrate a custom contract, route position operations through these managers instead of calling the spoke directly:\nThe user authorizes the built-in manager on the spoke.For taker and config operations, the user grants your contract an allowance or permission on the manager.Your contract calls the manager's …OnBehalfOf methods to modify the user's position.\nFor example, a flash loan contract opening a leveraged position for a user:\nimport { IERC20 } from \"openzeppelin-contracts/contracts/token/ERC20/IERC20.sol\";import { IGiverPositionManager } from \"aave-v4/src/position-manager/interfaces/IGiverPositionManager.sol\";import { ITakerPositionManager } from \"aave-v4/src/position-manager/interfaces/ITakerPositionManager.sol\";\n// IGiverPositionManager giver = …// ITakerPositionManager taker = …// address collateralAsset = …\n// Prerequisites (signed by the user, once per spoke):// - spoke.setUserPositionManager(address(giver), true, user)// - spoke.setUserPositionManager(address(taker), true, user)// - taker.approveBorrow(spoke, debtReserveId, address(this), borrowAmount)\nfunction openLeveragedPosition( address spoke, uint256 collateralReserveId, uint256 collateralAmount, uint256 debtReserveId, uint256 borrowAmount, address user) external { // Supply collateral to the user's position, funded by this contract IERC20(collateralAsset).approve(address(giver), collateralAmount); giver.supplyOnBehalfOf(spoke, collateralReserveId, collateralAmount, user);\n // Borrow against it, consuming the allowance granted by the user taker.borrowOnBehalfOf(spoke, debtReserveId, borrowAmount, user);}\nThe production deployments on Ethereum are:\nContractAddressGiverPositionManager0x17A54b8d6D9C68e7fa1C7112AC998EA1BA51d11eTakerPositionManager0x6c044c0D3801499bCAbfAd458B70880bc518e9F7ConfigPositionManager0x51305839CE822a7b4b12AA7D86eA7005052d575c\nThe contracts live in aave-v4/src/position-manager, and deployed addresses are listed under AaveV4EthereumPositionManagers in the Aave Address Book.\nAvailable Position Managers#\nGet all available position managers for a specific spoke.\nReactTypeScriptGraphQLUse the paginated useSpokePositionManagers hook to fetch position managers for a spoke.import { type SpokePositionManagersRequest, useSpokePositionManagers,} from \"@aave/react\";\nfunction SpokePositionManagersList({ request,}: { request: SpokePositionManagersRequest;}) { const { data, loading, error } = useSpokePositionManagers(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n // data: PaginatedSpokePositionManagerResult return ( <div> <h3>Position Managers</h3> {data.items.map((manager) => ( <div key={manager.address}> <h4>{manager.name}</h4> <p>Address: {manager.address}</p> <p>Status: {manager.active ? \"Active\" : \"Inactive\"}</p> </div> ))} </div> );}See below some examples of how to use the hook.const { data, loading, error } = useSpokePositionManagers({ spoke: spoke.id,});\nUser's Position Managers#\nGet all position managers that a specific user has enabled within a spoke.\nReactTypeScriptGraphQLSolidityUse the paginated useSpokeUserPositionManagers hook to fetch position managers enabled by a user.import { type EvmAddress, type SpokeId, useSpokeUserPositionManagers,} from \"@aave/react\";\nfunction UserPositionManagersList({ spoke, user,}: { spoke: SpokeId; user: EvmAddress;}) { const { data, loading, error } = useSpokeUserPositionManagers({ spoke, user, });\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n // data: PaginatedSpokeUserPositionManagerResult return ( <div> <h3>User Position Managers</h3> {data.items.map((manager) => ( <div key={manager.address}> <h4>{manager.name}</h4> <p>Address: {manager.address}</p> <p>Approved: {manager.approvedOn.toLocaleDateString()}</p> <p>Status: {manager.active ? \"Approved\" : \"Not Approved\"}</p> </div> ))} </div> );}\nAuthorize Position Manager#\nAuthorize or revoke a position manager to act on behalf of a user within a spoke.\nReactTypeScriptGraphQLSolidityTo enable or disable a position manager with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Define the Position Manager Flow#Use the useSetSpokeUserPositionManager hook to prepare the transaction request.import { useSetSpokeUserPositionManager } from \"@aave/react\";\nconst [setPositionManager, { loading, error }] = useSetSpokeUserPositionManager( (transaction) => sendTransaction(transaction),);3Execute the Transaction#Then, enable or disable the position manager.import { type EvmAddress, type SpokeId } from \"@aave/react\";\nconst execute = async ( spoke: SpokeId, manager: EvmAddress, user: EvmAddress,) => { const result = await setPositionManager({ spoke, manager, approve: true, // true to enable, false to disable user, });};\n// …4Handle the Result#Finally, handle the result.const execute = async (/* … */) => { const result = await setPositionManager(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Position manager enabled with hash:\", result.value.txHash);};PreviousPosition SwapsNextPosition Conditions","tokens":2395,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258502132,"hash":"52a5d34f196b1f9e76ba88b02681320c2104dc23"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/oracles/overview-oracles","domain":"docs.arbitrum.io","title":"Oracles | Arbitrum Docs","text":"✏️Request an updatenoteThis is a conceptual overview of oracles. For more detailed information on how to use oracles in your applications, check out our third-party oracles documentation.\nIn this conceptual overview, we'll explore oracles, how they work, and some general applications. This overview will provide a foundational understanding and set expectations for developers who want to integrate oracles into their applications.\nWhat are oracles?​\nOracles are third-party services that provide smart contracts with external information. They act as a bridge between blockchains and the outside world, which expands their functionality by enabling smart contracts to access data beyond their native networks.\nTypes of oracles​\nOracles can be classified based on their source, direction of information, trust, and how they provide information to smart contracts. Some common types of oracles include:\n\nInbound and Outbound oracles: Inbound oracles share information from external sources to smart contracts, while outbound oracles send information from smart contracts to the external world.\nCentralized and Decentralized oracles: A centralized oracle is a single entity and sole data provider for a smart contract. Decentralized oracles increase reliability by relying on multiple sources of truth and distributing trust among participants.\nPush and Pull oracles: Push oracles proactively provide data to smart contracts without being explicitly requested. They push data to the smart contract when a specified event or condition occurs. On the other hand, pull oracles require smart contracts to request data explicitly. They pull data from external sources in response to a query from the smart contract.\nSoftware oracles: These oracles interact with online sources of information, such as databases, servers, or websites, and transmit the data to the blockchain. They often provide real-time information like exchange rates or digital asset prices.\nHardware oracles: These oracles obtain information from the physical world using electronic sensors, barcode scanners, or other reading devices. They \"translate\" real-world events into digital values that smart contracts can understand.\n\nHow do push oracles work?​\nPush oracles proactively provide data to smart contracts without being explicitly requested. When a specified event or condition occurs, the push oracle triggers the smart contract with the relevant data. For example, a push oracle might send weather data to a smart contract once the temperature reaches a certain threshold.\n\nHow do pull oracles work?​\nPull oracles require smart contracts to request data explicitly. A smart contract sends a query to the oracle, retrieving and relaying the requested information to the contract. For example, a smart contract might request the current price of a specific digital asset from a pull oracle.\n\nUse cases for oracles​\nOracles serve a purpose in various applications across industries. Some general use cases include:\n\nPrediction markets: Oracles provide real-world data to prediction market platforms, allowing users to bet on future events or outcomes.\nSupply chain management: Hardware oracles can track the location and status of goods throughout the supply chain, enabling smart contracts to automate various processes and improve efficiency.\nInsurance: Oracles can supply data about events such as natural disasters, accidents, or price fluctuations, allowing smart contracts to automate claims processing and payouts.\nDecentralized finance (DeFi): Oracles provide critical price and market data to DeFi applications, enabling them to operate efficiently and securely.\n\nIn summary, oracles are a crucial component of the blockchain ecosystem, bridging the gap between onchain and offchain data sources. They enhance the functionality of smart contracts and enable a wide range of applications across various industries. As blockchain technology continues to evolve, developing secure and reliable oracles will remain essential in unlocking the full potential of smart contracts and decentralized applications.\nResources​\nYou can learn more about oracles in our third-party oracles documentation.What are oracles?Types of oraclesHow do push oracles work?How do pull oracles work?Use cases for oraclesResources","tokens":1070,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258505806,"hash":"91d0b4617317ea3ebc43c8fac15a41effe792338"}
{"url":"https://www.anchor-lang.com/docs/references/space","domain":"anchor-lang.com","title":"Account Space","text":"Program DevelopmentAccount SpaceReference guide for calculating account data size (bytes) requirements by Rust typeThis reference tells you how much space you should allocate for an account.\nThis only applies to accounts that don't use zero-copy. zero-copy uses\nrepr(C) with a pointer cast, so there the C layout applies.\nIn addition to the space for the account data, you have to add 8 to the\nspace constraint for Anchor's internal discriminator (see the example).\nType chart\nTypesSpace in bytesDetails/Examplebool1would only require 1 bit but still uses 1 byteu8/i81u16/i162u32/i324u64/i648u128/i12816[T;amount]space(T) * amounte.g. space([u16;32]) = 2 * 32 = 64Pubkey32Vec<T>4 + (space(T) * amount)String4 + length of string in bytesOption<T>1 + (space(T))Enum1 + Largest Variant Sizee.g. Enum { A, B { val: u8 }, C { val: u16 } } -> 1 + space(u16) = 3f324serialization will fail for NaNf648serialization will fail for NaN\nExample\n#[account]\npub struct MyData {\n pub val: u16,\n pub state: GameState,\n pub players: Vec<Pubkey> // we want to support up to 10 players\n}\n\nimpl MyData {\n pub const MAX_SIZE: usize = 2 + (1 + 32) + (4 + 10 * 32);\n}\n\n#[derive(AnchorSerialize, AnchorDeserialize, Clone, PartialEq, Eq)]\npub enum GameState {\n Active,\n Tie,\n Won { winner: Pubkey },\n}\n\n#[derive(Accounts)]\npub struct InitializeMyData<'info> {\n // Note that we have to add 8 to the space for the internal anchor\n #[account(init, payer = signer, space = 8 + MyData::MAX_SIZE)]\n pub acc: Account<'info, MyData>,\n pub signer: Signer<'info>,\n pub system_program: Program<'info, System>\n}\nThe InitSpace macro\nSometimes it can be difficult to calculate the initial space of an account. This\nmacro will add an INIT_SPACE constant to the structure. It is not necessary\nfor the structure to contain the #[account] macro to generate the constant.\nHere's an example:\n#[account]\n#[derive(InitSpace)]\npub struct ExampleAccount {\n pub data: u64,\n #[max_len(50)]\n pub string_one: String,\n #[max_len(10, 5)]\n pub nested: Vec<Vec<u8>>,\n}\n\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(mut)]\n pub payer: Signer<'info>,\n pub system_program: Program<'info, System>,\n #[account(init, payer = payer, space = 8 + ExampleAccount::INIT_SPACE)]\n pub data: Account<'info, ExampleAccount>,\n}\nA few important things to know:\n\nDon't forget the discriminator when defining space\nThe max_len attribute specifies the maximum number of elements in a Vec, not the total size in bytes.\nFor example, if you specify #[max_len(10)] for a Vec<u32>, it means:\n\nMaximum 10 elements\nEach element (u32) takes 4 bytes\nThe Vec itself has a 4-byte length prefix\nTotal space = 4 + (10 * 4) = 44 bytes\n\nPreviousAnchor Version ManagerNextRust to JS Type ConversionOn this pageType chartExampleThe InitSpace macroEdit on GitHub","tokens":696,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258521828,"hash":"7f68f61419f6e6875f409f5a0d4bd117c4b0438a"}
{"url":"https://aave.com/docs/aave-v3/concepts/liquidity-pool","domain":"aave.com","title":"LiquidityPool | Aave Protocol Documentation","text":"Liquidity Pool#\n\nA liquidity pool is an Aave market instance that\nenables users to participate as suppliers or borrowers. Governance-approved\nparameters, such as reserve configurations and collateralization thresholds,\ndefine each pool. Suppliers provide liquidity into the pool that borrowers can\naccess through overcollateralised positions. In return, suppliers earn interest,\nwhile borrowers can obtain liquidity against their collateral, all facilitated\nthrough decentralised smart contracts.\nAave liquidity pools operate on a blockchain network governed by decisions that define the chain and reserve parameters. Parameter decisions must balance liquidity demands for various actions with risk management. The use of smart contracts validate parameters, executing the actions of borrowing, repaying, and liquidation processes seamlessly without intermediaries. This decentralised approach enhances the transparency, efficiency, and security of financial interactions within the pool.\nThe core actions that can be taken on the liquidity pool are:\nSupply#\n\nSupplying tokens to the Aave Protocol allows users to earn interest on their digital assets and utilise supplied tokens as collateral. When tokens are supplied, they are transferred to the Aave liquidity pool, a system of smart contracts that facilitates overcollateralised borrowing of tokens. In Aave, supplied tokens automatically accrue interest based on the current market supply rate. As the balance of supplied tokens increases, interest is accrued dynamically, reflecting the current rate allocated to suppliers.\nInterest rates for supplied tokens are determined by the borrow utilisation rate, which measures the proportion of assets currently borrowed against the total supplied in the pool, and by governance parameters that can be adjusted through community decisions. These parameters, including collateralisation requirements and interest rates for suppliers and borrowers, are influenced by onchain inputs such as token balances, oracle prices, and the borrow utilisation ratio. As liquidity is supplied, borrowed, repaid, or withdrawn from the pool, the interest rates are updated accordingly.\nWithdraw#\n\nAave Protocol allows suppliers to withdraw their supplied tokens, including accrued interest, as long as there is sufficient unborrowed liquidity in the reserve. The withdrawal amount is limited by the available underlying assets, and that the user’s ability to maintain a sufficient collateral ratio for their borrow position. Periphery contracts with features such as withdraw and switch, allow users to redeem their supplied liquidity in a different token, providing more options for efficient asset management.\nWhen withdrawing with an active borrow position, it’s crucial to maintain a healthy collateralisation ratio to avoid liquidation. Reducing collateral can lower the health factor, increasing the risk of liquidation. To remain safe, after the withdrawal, the account must stay above the liquidation threshold parameters. Therefore, withdrawals require careful management and consideration of the overall borrow positions to avoid liquidation.\nBorrow#\n\nBorrowing tokens from the Aave Protocol allows users to access liquidity by using their supplied tokens as collateral, unlocking capital without selling their assets. However, borrowers face liquidation risk if the value of their collateral falls below the required threshold. Interest rates are determined dynamically, influenced by protocol factors and governance decisions, and can change over time based on community input. Interest accrues based on the utilisation rate, which reflects the percentage of supplied liquidity that is borrowed. Higher utilisation rates lead to higher interest rates, adjusting with demand. Each reserve has specific parameters designed to incentivize both borrowers and suppliers.\nTo maintain a healthy ratio and avoid liquidation risk, borrowers should actively monitor their collateralization level, keeping their health factor in check, to assure their borrow positions remain overcollateralised even as market conditions change or interest accrues.\nRepay#\n\nRepaying borrowed tokens in the Aave Protocol is an important step for managing borrow positions. Borrowers can repay using the same tokens they borrowed, or repay with aTokens (collateral tokens) of the same underlying token. In addition, there are periphery contracts available that simplify the process by allowing repayment with other tokens, such as other collateral assets, without the need to manually convert them beforehand. This flexibility makes it easier for borrowers to manage and close their positions when needed.\nRepayment increases the collateralisation ratio, ensuring adequate collateralization and preventing liquidation. By boosting the collateral relative to what is borrowed, repayment prevents assets from being liquidated and allows borrowers to safely withdraw part of their collateral.PreviousOverviewNextReserve","tokens":1246,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258521909,"hash":"f58edecbbbceb11828dc46baa9f269d65b56e181"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/how-to-estimate-gas","domain":"docs.arbitrum.io","title":"How to estimate gas in Arbitrum | Arbitrum Docs","text":"✏️Request an updateLooking for Stylus guidance?Head over to the Stylus gas docs for Stylus-specific guidance.\nThis how-to covers how gas operates in Arbitrum, how it's calculated, and how to estimate it before submitting transactions. For a deeper understanding of the underlying pricing mechanisms, see the Gas and Fees concept page.\nQuick start: use eth_estimateGas​\nIf you don't need to understand the formula, you can rely on the standard gas estimation process. Call an Arbitrum node's eth_estimateGas RPC, which returns a gas limit sufficient to cover the entire transaction fee at the current child chain gas price.\nMultiplying the value from eth_estimateGas by the child chain gas price gives you the total ETH required for the transaction to succeed. Note that for a given operation, the eth_estimateGas value may vary over time as the parent chain calldata price fluctuates.\nAlternatively, call NodeInterface.gasEstimateComponents() and use the first result (gasEstimate) as your gas limit. Multiply by the third result (baseFee) to get the total cost. For background on NodeInterface itself, see the NodeInterface overview.\nNote that when working with parent to child chain messages (also known as retryable tickets), you can use the function ParentToChildMessageGasEstimator.estimateAll() of the Arbitrum SDK or NodeInterface.estimateRetryableTicket() to get all the gas information needed to send a successful transaction.\nThe fee formula​\nL1 fee \"baked in\"The model below explains a two-dimensional fee model that captures both L1 and L2 costs. However, it is important to note that users will see a single fee—the L2 cost with the L1 fee \"baked-in.\" This differs from other Rollups.Arbitrum converts L1 calldata costs into equivalent L2 gas, so the user sees a single fee rather than two (as explained in the model below). The formula detailed below is precisely how it is calculated—but just remember it is shown as a single fee to the user.\nArbitrum uses a two-dimensional fee model where a transaction's total fee has two components: child chain execution costs and parent chain data posting costs. The total transaction fee is:\nTransaction fees (TXFEES) = L2 Gas Price (P) * Gas Limit (G)\nThe gas limit includes the gas for child chain computation plus an additional buffer to cover the parent chain gas the Sequencer pays when posting the batch:\nGas Limit (G) = Gas used on L2 (L2G) + Extra Buffer for L1 cost (B)\nThe buffer accounts for the cost of posting the transaction (batched and compressed) on the parent chain. The parent chain estimated posting cost is:\nL1 Estimated Cost (L1C) = L1 price per byte of data (L1P) * Size of data to be posted in bytes (L1S)\nWhere:\n\nL1P estimates the current parent chain price per byte of data, dynamically adjusted by the child chain over time\nL1S estimates how many bytes the transaction will occupy in the batch by compressing it with Brotli\n\nThe buffer converts this cost into child chain gas units:\nExtra Buffer (B) = L1 Estimated Cost (L1C) / L2 Gas Price (P)\nCombining everything:\nTXFEES = P * (L2G + ((L1P * L1S) / P))\nWhere to get each variable​\nYou can use the NodeInterface to retrieve the fee components:\n\nP (L2 Gas Price): Price per gas unit. Starts at a gas floor price and increases with demand.\n\nCall NodeInterface.gasEstimateComponents() and get the third element, baseFee.\n\nL2G (Gas used on L2): Gas consumed by child chain computation, excluding parent chain posting costs.\n\nCall NodeInterface.gasEstimateComponents() with the transaction data and subtract the second element (gasEstimateForL1) from the first (gasEstimate).\n\nL1P (L1 estimated price per byte of data): Estimated cost of posting 1 byte of data on the parent chain.\n\nCall NodeInterface.gasEstimateComponents(), get the fourth element l1BaseFeeEstimate and multiply it by 16.\n\nL1S (Size of data to be posted on L1, in bytes): Depends on the transaction data. Arbitrum adds a fixed amount (~140 bytes) for the static part of the transaction.\n\nCall NodeInterface.gasEstimateComponents(), take the second element gasEstimateForL1 (this is B in the formula), multiply by P and divide by L1P.\nFor Arbitrum Nova (AnyTrust), the data size is a fixed value since only the Data Availability Certificate (DAC) is posted on the parent chain, as explained here.\n\nnoteFor L1P and L1S, you can also call NodeInterface.gasEstimateL1Component() to get l1BaseFeeEstimate and gasEstimateForL1.\nCode example​\nHere's how to estimate gas using the Arbitrum SDK and NodeInterface:\nFirst, instantiate the NodeInterface:\nconst { NodeInterface__factory } = require(\"@arbitrum/sdk/dist/lib/abi/factories/NodeInterface__factory\");const { NODE_INTERFACE_ADDRESS } = require(\"@arbitrum/sdk/dist/lib/dataEntities/constants\");...// Instantiation of the NodeInterface objectconst nodeInterface = NodeInterface__factory.connect( NODE_INTERFACE_ADDRESS, baseL2Provider);\nCall gasEstimateComponents() with your transaction's destination address and data:\n// Getting the estimations from NodeInterface.gasEstimateComponents()const gasEstimateComponents = await nodeInterface.callStatic.gasEstimateComponents(destinationAddress, false, txData, { blockTag: 'latest',});\nExtract the formula variables:\n// Getting useful values for calculating the formulaconst parentChainGasEstimated = gasEstimateComponents.gasEstimateForL1;const childChainGasUsed = gasEstimateComponents.gasEstimate.sub(gasEstimateComponents.gasEstimateForL1);const childChainEstimatedPrice = gasEstimateComponents.baseFee;const parentChainEstimatedPrice = gasEstimateComponents.l1BaseFeeEstimate.mul(16);// Calculating some extra values to be able to apply all variables of the formula// -------------------------------------------------------------------------------// NOTE: parentChainGasEstimated (B in the formula) is calculated based on the child chain's gas priceconst parentChainCost = parentChainGasEstimated.mul(childChainEstimatedPrice);// Guard against zero parent-chain base-fee estimates (some AnyTrust/Orbit configs)const parentChainSize = parentChainEstimatedPrice.eq(0) ? 0 : parentChainCost.div(parentChainEstimatedPrice);// Setting the basic variables of the formulaconst P = childChainEstimatedPrice;const L2G = childChainGasUsed;const L1P = parentChainEstimatedPrice;const L1S = parentChainSize;\nCalculate the total fee:\n// L1C (L1 Cost) = L1P * L1Sconst L1C = L1P.mul(L1S);// B (Extra Buffer) = L1C / Pconst B = L1C.div(P);// G (Gas Limit) = L2G + Bconst G = L2G.add(B);// TXFEES (Transaction fees) = P * Gconst TXFEES = P.mul(G);\nRefer to our tutorials repository for a complete working example.\nChecking parent chain confirmations and batch information​\nThe NodeInterface also exposes methods for querying confirmation status and batch membership of child chain blocks. This is useful when you need to verify that a child chain block has been posted to the parent chain.\nimport { NodeInterface__factory } from '@arbitrum/sdk/dist/lib/abi/factories/NodeInterface__factory';import { NODE_INTERFACE_ADDRESS } from '@arbitrum/sdk/dist/lib/dataEntities/constants';const nodeInterface = NodeInterface__factory.connect(NODE_INTERFACE_ADDRESS, childProvider);// Get parent chain confirmations for a child chain blockconst { confirmations } = await nodeInterface.functions.getL1Confirmations(blockHash);// Find which batch contains a specific blockconst { batch } = await nodeInterface.functions.findBatchContainingBlock(blockNumber);\nFor a complete working example, see the parent-chain-confirmation-checker tutorial.\nFinal note​\nGas estimations from the above techniques are approximate and the actual gas fees may differ. We encourage developers to set this expectation explicitly wherever this information is shared with end-users.Quick start: use eth_estimateGasThe fee formulaWhere to get each variableCode exampleChecking parent chain confirmations and batch informationFinal note","tokens":1969,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258523036,"hash":"d541aa9e755aeaf85490d9808b28c184d5b53129"}
{"url":"https://www.anchor-lang.com/docs/references/type-conversion","domain":"anchor-lang.com","title":"Rust to JS Type Conversion","text":"Program DevelopmentRust to JS Type ConversionReference for how Anchor converts between Rust and TypeScript typesThis reference shows to converts between Rust and TypeScript types.\nPrimitive Types\nBoolean\nRustTypeScriptExampleboolbooleantrue\nNumbers\nRustTypeScriptExampleu8/u16/u32/i8/i16/i32number99u64/u128/i64/i128anchor.BNnew anchor.BN(99)f32/f64number1.0\nStrings\nRustTypeScriptExampleStringstring\"hello\"\nCollections\nArrays and Vectors\nRustTypeScriptExample[T; N] (fixed array)Array<T>[1, 2, 3]Vec<T> (vector)Array<T>[1, 2, 3]\nOptional Values\nRustTypeScriptExampleOption<T>T | null | undefinednull (None)42 (Some)\nComplex Types\nStructs\nRust// Rust\nstruct MyStruct {\n val: u16,\n}\nTypeScript// TypeScript\ntype MyStruct = {\n val: number;\n};\n\n// Example\nconst instance = { val: 99 };\nEnums\nRust// Rust\nenum MyEnum {\n One,\n Two { val: u32 },\n Three(u8, i16),\n}\nTypeScript// TypeScript Representations\n// Unit variant\nconst one = { one: {} };\n\n// Named variant\nconst two = {\n two: { val: 99 },\n};\n\n// Tuple variant\nconst three = {\n three: [12, -34],\n};\nNotes\n\nRust integers (u8 through i32) map to JavaScript number\nLarger integers (u64 and above) use Anchor's BN type for precision\nRust's Option<T> maps to TypeScript's union type with null/undefined\nStructs and enums become JavaScript objects\nPreviousAccount SpaceNextVerifiable BuildsOn this pagePrimitive TypesBooleanNumbersStringsCollectionsArrays and VectorsOptional ValuesComplex TypesStructsEnumsNotesEdit on GitHub","tokens":368,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258533319,"hash":"7d92ba164c4d01938d2009348ae83434166ed4d6"}
{"url":"https://aave.com/docs/aave-v4/reference/big-decimal","domain":"aave.com","title":"BigDecimal | Aave Protocol Documentation","text":"BigDecimal#\nHigh-precision decimal arithmetic for AaveKit\n\nAaveKit represents all decimal numbers using the BigDecimal type to ensure high-precision arithmetic for financial computations. Whenever you interact with balances, rates, or amounts in the SDK, they are returned as BigDecimal instances.\n// Import from AaveKit Reactimport { bigDecimal, BigDecimal } from \"@aave/react\";\n// Import from AaveKit TypeScriptimport { bigDecimal, BigDecimal } from \"@aave/client\";\nKey Features:\nArbitrary precision arithmeticSafe conversion from various numeric typesDisplay formatting with adaptive precisionStatic utility methods for common operationsType-safe operations that return BigDecimal instances\nBigDecimal is immutable — its methods never modify the instance in place\nbut always return a new one. It is based on the\nbig.js library and provides consistent\nbehavior across Node.js and browser environments.\nCreating BigDecimals#\n// From string (recommended for precision)const a = bigDecimal(\"123.456789\");\n// From numberconst b = bigDecimal(123.456);\n// From bigintconst c = bigDecimal(123456789n);\nArithmetic Operations#\nAll arithmetic operations return new BigDecimal instances, making them safe for immutable workflows.\nAddition#\nconst a = bigDecimal(\"100\");const b = bigDecimal(\"50\");\na.plus(b); // BigDecimal('150')a.add(b); // Alias for .plus()\nSubtraction#\nconst a = bigDecimal(\"100\");const b = bigDecimal(\"30\");\na.minus(b); // BigDecimal('70')a.sub(b); // Alias for .minus()\nMultiplication#\nconst a = bigDecimal(\"10\");const b = bigDecimal(\"5\");\na.times(b); // BigDecimal('50')a.mul(b); // Alias for .times()\nDivision#\nconst a = bigDecimal(\"100\");const b = bigDecimal(\"3\");\na.div(b); // BigDecimal('33.333...')\n// Division by zero throwsbigDecimal(\"10\").div(\"0\"); // Throws: ±InfinitybigDecimal(\"0\").div(\"0\"); // Throws: NaN\nModulo#\nconst a = bigDecimal(\"10\");const b = bigDecimal(\"3\");\na.mod(b); // BigDecimal('1')\nPower#\nconst a = bigDecimal(\"2\");\na.pow(3); // BigDecimal('8')a.pow(-1); // BigDecimal('0.5')\n// Range: -1e+6 to 1e+6 inclusive\nSquare Root#\nconst a = bigDecimal(\"16\");\na.sqrt(); // BigDecimal('4')\n// Negative numbers throwbigDecimal(\"-1\").sqrt(); // Throws: NaN\nAbsolute Value#\nconst a = bigDecimal(\"-123.45\");\na.abs(); // BigDecimal('123.45')\nNegation#\nconst a = bigDecimal(\"123.45\");\na.neg(); // BigDecimal('-123.45')\nComparison Methods#\nAll comparison methods are inherited from big.js:\nconst a = bigDecimal(\"100\");const b = bigDecimal(\"50\");\na.gt(b); // true - greater thana.gte(b); // true - greater than or equala.lt(b); // false - less thana.lte(b); // false - less than or equala.eq(b); // false - equal toa.cmp(b); // 1 - compare (-1, 0, or 1)\nRounding & Precision#\nRounding Modes#\nenum RoundingMode { Down = 0, // Towards zero (truncate) HalfUp = 1, // Nearest neighbor; away from zero if equidistant HalfEven = 2, // Nearest neighbor; towards even if equidistant Up = 3, // Away from zero}\nRound to Decimal Places#\nconst a = bigDecimal(\"123.456789\");\na.round(2, RoundingMode.HalfUp); // BigDecimal('123.46')a.round(0, RoundingMode.Down); // BigDecimal('123')a.round(); // BigDecimal('123') - defaults to 0 dp\nRound to Significant Digits#\nconst a = bigDecimal(\"123.456789\");\na.prec(4, RoundingMode.HalfUp); // BigDecimal('123.5')a.prec(2, RoundingMode.Down); // BigDecimal('120')\nScaling#\nMultiply by 10^decimals (commonly used for on-chain conversions):\nconst amount = bigDecimal(\"1.5\");\n// Scale up (e.g., ETH to wei)amount.rescale(18); // BigDecimal('1500000000000000000')\n// Scale down (e.g., wei to ETH)const wei = bigDecimal(\"1500000000000000000\");wei.rescale(-18); // BigDecimal('1.5')\nDisplay Formatting#\nAdaptive Precision Display#\nThe toDisplayString method provides intelligent formatting based on number magnitude:\nconst large = bigDecimal(\"1234.5678\");const small = bigDecimal(\"0.0001234\");\n// For numbers >= 1: preserves integer digits, controls decimal precisionlarge.toDisplayString(6); // '1234.57' (all integer digits + 2 decimals)\n// For numbers < 1: uses significant figuressmall.toDisplayString(3); // '0.000123' (3 significant figures)\nFormatting Options#\nconst num = bigDecimal(\"123.456789\");\n// Basic precisionnum.toDisplayString(5);// '123.46'\n// With rounding modenum.toDisplayString(4, { rounding: RoundingMode.Down });// '123.4'\n// With minimum fraction digitsnum.toDisplayString(3, { minFractionDigits: 4 });// '123.4568' (enforces 4 decimal places)\n// Trim trailing zerosnum.toDisplayString(10, { trimTrailingZeros: true });// '123.456789' (no trailing zeros)\n// Combined optionsbigDecimal(\"100.5000\").toDisplayString(5, { minFractionDigits: 2, trimTrailingZeros: true,});// '100.5' (trims trailing zeros but respects minimum)\nExamples by Number Type#\n// Large numbers: preserves all integer digitsbigDecimal(\"1234567.89\").toDisplayString(10);// '1234567.890'\n// Small decimals: significant figuresbigDecimal(\"0.00001234\").toDisplayString(3);// '0.0000123'\n// Zero handlingbigDecimal(\"0\").toDisplayString(5);// '0'\nbigDecimal(\"0\").toDisplayString(3, { minFractionDigits: 2 });// '0.00'\nConversion Methods#\nTo String#\nconst a = bigDecimal(\"123.456\");\na.toString(); // '123.456'a.toJSON(); // '123.456' (used by JSON.stringify)\na.toFixed(); // '123.456' (fixed-point notation)a.toFixed(2); // '123.46' (2 decimal places)a.toFixed(2, RoundingMode.Down); // '123.45' (with rounding mode)\na.toExponential(); // '1.23456e+2'a.toExponential(2); // '1.23e+2' (2 decimal places)\na.toPrecision(); // '123.456'a.toPrecision(2); // '1.2e+2' (2 significant digits)a.toPrecision(4, RoundingMode.Down); // '123.4' (4 sig digits)\nTo Number (Approximate)#\nConvert to JavaScript number with safe clamping:\nconst safe = bigDecimal(\"123.456\");safe.toApproximateNumber(); // 123.456\n// Handles extreme valuesconst huge = bigDecimal(\"1e500\");huge.toApproximateNumber(); // Number.MAX_VALUE (clamped)\nconst tiny = bigDecimal(\"1e-500\");tiny.toApproximateNumber(); // 0 (subnormal → zero)\nconst negHuge = bigDecimal(\"-1e500\");negHuge.toApproximateNumber(); // -Number.MAX_VALUE (clamped)\nUse Cases:\nDisplaying approximate values in UIInterfacing with APIs requiring number typesWhen precision loss is acceptable\nOnly use when precision loss is acceptable. For precise calculations, always\nuse BigDecimal operations.\nStatic Utility Methods#\nType Guard#\nconst value: unknown = bigDecimal(\"123\");\nif (BigDecimal.isBigDecimal(value)) { // value is BigDecimal value.plus(\"10\");}\nMin/Max#\nconst a = bigDecimal(\"100\");const b = bigDecimal(\"50\");const c = bigDecimal(\"75\");\nBigDecimal.min(a, b, c); // BigDecimal('50')BigDecimal.max(a, b, c); // BigDecimal('100')\n// Minimum two arguments requiredBigDecimal.min(a, b); // BigDecimal('50')\nBest Practices#\n\nUse string literals for precision:\n// Goodconst amount = bigDecimal(\"0.1\");\n// Risky (0.1 already has floating-point error)const amount = bigDecimal(0.1);\n\nChain operations for clarity:\nconst result = bigDecimal(\"100\") .times(\"1.05\") // Apply 5% increase .round(2, RoundingMode.HalfUp);\n\nStore monetary values as BigDecimal:\ninterface Transaction { amount: BigDecimal; // Not number! currency: string;}\n\nUse toDisplayString() for UI formatting:\n// Adaptive precision for displayconst formatted = balance.toDisplayString(6);\nPreviousSwap FeaturesNextReact Hooks","tokens":1811,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258533364,"hash":"fdd77d778b1d7876da86c282d9077443c6bd4f67"}
{"url":"https://www.openzeppelin.com/solidity-contracts","domain":"openzeppelin.com","title":"OpenZeppelin | Solidity Smart Contract Libraries","text":"Develop Secure Smart Contracts in SolidityOpenZeppelin Contracts helps you minimize risk by using battle-tested libraries of smart contracts for Ethereum and other EVM blockchains. It includes the most used implementations of ERC standards.Total value transferred via OpenZeppelin Contracts Explore stats$38,211,353,386,986Secure CodeReduce the risk of vulnerabilities in your applications by using standard, tested, community-reviewed code.Focused on SecurityUsing top level standard contracts security patterns and best practices.Go to Security CenterModular ApproachSimple, robust code.\nEasy collaboration and auditing. Go to GitHubOpen SourceCommunity-driven. Used by the biggest players in the industry.Go to ForumThe world's leading DeFi protocols and financial institutions rely on OpenZeppelin ContractsOpen Source ToolsSecure and automate your Contracts with Relayer and MonitorMonitor and automate your onchain workflows with OpenZeppelin open source tools.Explore ToolsJoin the OpenZeppelin communityAsk questions, learn about security, and become familiar with smart contract development.\n\nJoin our Community","tokens":280,"squid":"ink-security_audits","role":"Sentinel","at":1791258536996,"hash":"f125c2a174d4661f7fb7d834387f270036bda48d"}
{"url":"https://aave.com/docs/aave-v4/positions/liquidations","domain":"aave.com","title":"Liquidations | Aave Protocol Documentation","text":"Liquidations#\nLearn how liquidations work in Aave v4.\n\nLiquidate unhealthy positions to earn liquidation bonuses and help maintain protocol stability.\nIdentify Target Position#\nFirst, identify a position with a health factor below 1.0 that is eligible for liquidation.\nconst position: UserPosition = { __typename: \"UserPosition\", id: \"aGVsbG8\", user: \"0x456…\", healthFactor: { value: BigDecimal(0.85), // Below 1.0 - eligible for liquidation // … }, spoke: { address: \"0x123…\", chain: { chainId: 1, name: \"Ethereum\", }, // … }, // …};\nIt's not in the scope of this guide to explain how to find positions with a\nhealth factor below 1.0 and identify unhealthy positions. See Health\nFactor for more details.\nSelect Liquidation Targets#\nTo liquidate a position, we need to choose two things: which debt to repay and which collateral to receive as liquidation bonus.\nWhen choosing positions to liquidate, ensure liquidation bonuses exceed gas\ncosts.\n1Choose the Debt Position#First, identify which debt position to target by looking at the user's borrow positions. Consider targeting debts with larger amounts.Fetch borrow positions from User Borrows, then pick the specific position you want to liquidate:const debtPosition: UserBorrowItem = { reserve: { id: \"SGVsbG8h\", onChainId: \"42\", asset: { underlying: { symbol: \"WETH\", name: \"Wrapped Ether\" }, }, // … }, debt: { amount: { value: BigDecimal(0.5), }, exchange: { value: BigDecimal(2000), // … }, // … }, // …};If the remaining debt in the target reserve after liquidation is less than\n$1,000 USD, you must liquidate the entire debt in that reserve.2Choose the Collateral Position#Next, identify which collateral position to target by examining the user's supply positions that are enabled as collateral. Only supplies with isCollateral: true can be targeted for liquidation.Choose collateral in the token you prefer to receive as your liquidation bonus by fetching the supply positions from User Supplies:const collateral: UserSupplyItem = { reserve: { id: \"V29ybGQ=\", onChainId: \"43\", asset: { underlying: { symbol: \"USDC\", name: \"USD Coin\" }, }, // … }, isCollateral: true, // Can be liquidated withdrawable: { amount: { value: BigDecimal(2000), // … }, // … }, // …};In Aave v4, liquidation bonuses follow a Dutch auction where lower health\nfactors result in higher liquidation bonuses.\nLiquidate the Position#\nAfter selecting the debt and collateral reserves, choose the repayment amount. You can send an exact value or let the protocol determine the needed amount by using max, restoring the position to a healthy state (HF ≥ 1.0).\nReactTypeScriptGraphQLSolidityTo liquidate an unhealthy position with AaveKit React, follow these steps:1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice. This wallet will pay the debt tokens and receive the seized collateral.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Implement the Liquidation Operation#Then, use the useLiquidatePosition hook to prepare the liquidation operation.import { useLiquidatePosition } from \"@aave/react\";\nconst [liquidatePosition, { loading, error }] = useLiquidatePosition( (plan, { cancel }) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan); case \"Erc20Approval\": // If token supports EIP-2612 permits, sign permit (recommended) if (plan.bySignature) { return signTypedData(plan.bySignature); } // Otherwise use traditional approval transaction return sendTransaction(plan.byTransaction);\n case \"PreContractActionRequired\": return sendTransaction(plan.transaction); } },);In the Erc20Approval case, the bySignature field is only available if the token supports EIP-2612 permits.For tokens like USDT on Ethereum\nMainnet\nthat require an allowance reset, the hook calls your callback twice: once to\nreset the allowance to 0, then again to set the new value. bySignature will\nbe null for these approvals.3Execute the Liquidation#Then, execute the liquidation operation. Specify an exact debt amount to cover, or use amount: { max: true } to bring the position back to a healthy state.import { bigDecimal, evmAddress, type UserBorrowItem, type UserPosition, type UserSupplyItem,} from \"@aave/react\";\nconst execute = async ( position: UserPosition, debt: UserBorrowItem, collateral: UserSupplyItem,) => { const result = await liquidatePosition({ collateral: collateral.reserve.id, debt: debt.reserve.id, amount: { exact: { value: bigDecimal(\"1000\") }, // 1000 USDC }, liquidator: evmAddress(wallet.account.address), // User's address user: position.user, });\n // …};4Handle the Result#Finally, handle the result.const execute = async (/* … */) => { const result = await liquidatePosition(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"ValidationError\": console.error( \"Insufficient balance:\", `required: ${result.error.cause.required.value.toDisplayString(2)}`, `available: ${result.error.cause.available.value.toDisplayString(2)}`, ); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Liquidation successful with hash:\", result.value.txHash);};PreviousPosition ConditionsNextTools","tokens":1422,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258544573,"hash":"09717cba73265b75787d0ef3cf67aa4316cfdd17"}
{"url":"https://www.openzeppelin.com/cairo-contracts","domain":"openzeppelin.com","title":"OpenZeppelin | Cairo Smart Contract Libraries","text":"Develop Secure Smart Contracts in CairoOpenZeppelin Contracts helps you minimize risk by using battle-tested libraries of smart contracts for Starknet and other blockchains.Total value transferred via OpenZeppelin Contracts Explore stats$38,211,353,386,986Secure CodeReduce the risk of vulnerabilities in your applications by using standard, tested, community-reviewed code.Focused on SecurityUsing top level standard contracts security patterns and best practices.Go to Security CenterModular ApproachSimple, robust code.\nEasy collaboration and auditing. Go to GitHubOpen SourceCommunity-driven. Used by the biggest players in the industry.Go to ForumThe world's leading DeFi protocols and financial institutions rely on OpenZeppelin ContractsOpen Source ToolsSecure and automate your Contracts with Relayer and MonitorMonitor and automate your onchain workflows with OpenZeppelin open source tools.Explore ToolsJoin the largest community of smart contract developersAsk questions, learn about security, and become familiar with smart contract development.Join our Community","tokens":269,"squid":"ink-security_audits","role":"Sentinel","at":1791258550480,"hash":"2808a1ceca6648973b8b93dac1a6ddb55920c690"}
{"url":"https://vote.optimism.io/proposals/17074702586937926119121483757540636273817379522480745477026492886022316183707","domain":"vote.optimism.io","title":"Sequencer ETH Management: 12-Month Re...","text":"ProposalsVotersConnect  Wallet Standard Proposal by The Optimism FoundationSequencer ETH Management: 12-Month Renewal and Treasury OptimizationProposal Visualization No substantive onchain transactions.The Foundation has proposed renewing the Sequencer ETH staking program for another 12 months.\nThe proposal would allow the Foundation to continue staking the Collective’s ETH, consolidate institutional staking from three custodians to two qualified custody providers, and use conservative yield enhancement strategies, such as covered calls and collars, on up to two-thirds of the ETH treasury.\nAny cash proceeds generated from these strategies may be redeployed into short-duration RWAs on OP Mainnet. The proposal targets a materially higher blended yield than staking alone, while maintaining institutional custody and risk controls.\nYou can read the proposal in its entirety here\nYou should vote for this proposal if you support renewing the ETH staking program with the proposed updates for the next 12 months.FOR - 24,037,841 AGAINST - 291,298 Quorum 16,540,389 Threshold 51%EXECUTEDExecuted 12:10 am Jul 21, 2026VotersHasn't voteddelegate.testinprod-io.eth8,485,127 op.evabeylin.eth4,000,000 delegate.l2beat.eth3,978,749 olimpio.eth2,157,950 cerv1.eth2,000,002 While it would be nice to have more than option on the ballot, I have no objection to the current program that would lead me to vote against it.tboptimist.eth2,000,000 pgov.eth1,015,868 fireeyesgov.eth591,240 gfxlabs.eth577,564 griff.eth330,189 wintermutegovernance.eth259,420 0xc2...d1ab221,122 cp0x.eth183,611 Sequencer ETH Management: 12-Month Re...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":430,"squid":"ink-governance","role":"Council Listener","at":1791258552770,"hash":"cce5c49239573237a7d214f9d855f089afb170b5"}
{"url":"https://io.net/docs/guides/confidential-inference/confidential-chat","domain":"io.net","title":"Confidential Chat - io.net","text":"​Getting Started\n​Step 1: Select a Secure Model\n\nNavigate to ai.io.net/ai/models\nLook for models with the SECURE AI badge\nClick on a secure model to start a confidential chat session\n\n​Step 2: Start Chatting Privately\nOnce you select a secure model, you enter a private chat session with the following guarantees:\n\nMessages are never saved - your conversation is not stored on any server\nNo observation - io.net staff cannot see your prompts or responses\nSession-only context - only the current chat is passed to the LLM for context\nEnd-to-end verification - every response is cryptographically signed\n\n​Privacy Guarantees\nFeatureDescriptionZero storageMessages exist only in your browser and the TEE during processingNo loggingConversation content is never written to logsSession isolationEach chat session is independent and ephemeralSigned responsesEvery AI response includes a cryptographic signature\n​Verifying Attestation and Signatures\nEvery message in a confidential chat can be verified. Click the Secure AI label under any AI response to open the verification panel.\n\n​Attestation Report\nThe verification panel displays the full attestation report, proving:\n\nThe response came from a genuine NVIDIA GPU running in TEE mode\nThe specific hardware configuration and firmware version\nThe container image hash (image_digest) running inside the secure enclave - compare with the expected digest from the latest official release to confirm the container hasn’t been tampered with\n\n​Message Signatures\nFor each AI response, you can view:\nFieldDescriptionSigned TextThe exact content that was signedSignatureThe cryptographic signature proving authenticitySigning AddressThe public key that signed (matches attestation)AlgorithmThe signing algorithm used (e.g., ecdsa)Image digestSHA256 hash of the container image running in the TEE\nThis allows you to independently verify that:\n\nThe response was generated by the attested hardware\nThe content was not modified after generation\nThe signing key matches the attestation report\n\n​Best Practices\n​For Maximum Privacy\n\nStart fresh sessions for sensitive topics\nVerify signatures for critical responses\nCheck attestation to confirm hardware authenticity\nClear your browser after sensitive sessions\n\n​Understanding Session Context\nSince messages are not saved:\n\nThe AI only has context from the current session\nNew chat starts a new session with no history\nYou cannot retrieve previous confidential conversations\n\nThis is by design - true privacy means no persistent storage.\n​What’s Next\n\nQuick Start API - For developers building integrations\nVerification Guide - Deep dive into verifying attestation and signatures\nWas this page helpful?","tokens":671,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258559892,"hash":"0832fe5b50a9d2e4821a8d9f4e6adb9e01fcbf89"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/","domain":"docs.openzeppelin.com","title":"Contracts | OpenZeppelin Docs","text":"OpenZeppelin ContractsContractsOpen in ClaudeA library for secure smart contract development. Build on a solid foundation of community-vetted code.\n\nImplementations of standards like ERC20 and ERC721.\nFlexible role-based permissioning scheme.\nReusable Solidity components to build custom contracts and complex decentralized systems.\n\nOpenZeppelin Contracts uses semantic versioning to communicate backwards compatibility of its API and storage layout. For upgradeable contracts, the storage layout of different major versions should be assumed incompatible, for example, it is unsafe to upgrade from 4.9.3 to 5.0.0. Learn more at Backwards Compatibility.\nOverview\nRelease Tags\nWe use NPM tags to clearly distinguish between audited and non-audited versions of our package:\n| Tag |\n| --- | --- | --- |\n| Purpose | Description | latest |\n| ✅ Audited releases | Stable, audited versions of the package. This is the default version installed when users run npm install @openzeppelin/contracts. | dev |\n| 🧪 Final but not audited | Versions that are finalized and feature-complete but have not yet been audited. This version is fully tested, can be used in production and is covered by the bug bounty. | next |\nInstallation\nHardhat (npm)\n$ npm install @openzeppelin/contracts\n→ Installs the latest audited release (latest).\n$ npm install @openzeppelin/contracts@dev\n→ Installs the latest unaudited release (dev).\nFoundry (git)\nWhen installing via git, it is a common error to use the master branch. This is a development branch that should be avoided in favor of tagged releases. The release process involves security measures that the master branch does not guarantee.\nFoundry installs the latest version initially, but subsequent forge update commands will use the master branch.\n$ forge install OpenZeppelin/openzeppelin-contracts\nAdd @openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/ in remappings.txt.\nUsage\nOnce installed, you can use the contracts in the library by importing them:\n// contracts/MyNFT.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n\nimport {ERC721} from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\";\n\ncontract MyNFT is ERC721 {\n constructor() ERC721(\"MyNFT\", \"MNFT\") {}\n}\nIf you’re new to smart contract development, head to Developing Smart Contracts to learn about creating a new project and compiling your contracts.\nTo keep your system secure, you should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself. The library is designed so that only the contracts and functions you use are deployed, so you don’t need to worry about it needlessly increasing gas costs.\nSecurity\nPlease report any security issues you find via our bug bounty program on Immunefi or directly to security@openzeppelin.org.\nThe Security Center contains more details about the secure development process.\nLearn More\nThe guides in the sidebar will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:\n\nAccess Control: decide who can perform each of the actions on your system.\nTokens: create tradable assets or collectibles, like the well known ERC20 and ERC721 standards.\nUtilities: generic useful tools, including non-overflowing math, signature verification, and trustless paying systems.\n\nThe full API is also thoroughly documented, and serves as a great reference when developing your smart contract application. You can also ask for help or follow Contracts' development in the community forum.\nThe following articles provide great background reading, though please note, some of the referenced tools have changed as the tooling in the ecosystem continues to rapidly evolve.\n\nThe Hitchhiker’s Guide to Smart Contracts in Ethereum will help you get an overview of the various tools available for smart contract development, and help you set up your environment.\nA Gentle Introduction to Ethereum Programming, Part 1 provides very useful information on an introductory level, including many basic concepts from the Ethereum platform.\nFor a more in-depth dive, you may read the guide Designing the architecture for your Ethereum application, which discusses how to better structure your application and its relationship to the real world.\nGetting StartedPrevious PageContracts WizardNext PageOn this pageOverviewRelease TagsInstallationHardhat (npm)Foundry (git)UsageSecurityLearn More","tokens":1106,"squid":"ink-security_audits","role":"Sentinel","at":1791258561172,"hash":"bd7f45779bb2b0d59c9bbdf6b288ee91a1e26fdf"}
{"url":"https://vote.optimism.io/delegates/0xbf9c6440986bb54241591c7982de412ab0b4a440","domain":"vote.optimism.io","title":"0xbf...a440 on Agora","text":"Voted for this proposal about 2 months ago with 4M votesRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundVoted for this proposal 3 months ago with 4M votesGrants Council Dissolution ProposalVoted for this proposal 3 months ago with 4M votesMilestones and Metrics Council Dissolution ProposalVoted for this proposal 3 months ago with 4M votesOperating Manual Update ProposalVoted for this proposal 3 months ago with 4M votesDeveloper Advisory Board Dissolution ProposalVoted for this proposal 3 months ago with 4M votesSequencer ETH Management: 12-Month Renewal and Treasury OptimizationVoted for this proposal 3 months ago with 4M votesSecurity Council Operating Budget","tokens":174,"squid":"ink-governance","role":"Council Listener","at":1791258563518,"hash":"05d950a9429ac8063e0ffb33996b1184e7a27a1a"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/backwards-compatibility","domain":"docs.openzeppelin.com","title":"Backwards Compatibility | OpenZeppelin Docs","text":"OpenZeppelin ContractsBackwards CompatibilityOpen in ClaudeOpenZeppelin Contracts uses semantic versioning to communicate backwards compatibility of its API and storage layout. Patch and minor updates will generally be backwards compatible, with rare exceptions as detailed below. Major updates should be assumed incompatible with previous releases. On this page, we provide details about these guarantees.\nAPI\nIn backwards compatible releases, all changes should be either additions or modifications to internal implementation details. Most code should continue to compile and behave as expected. The exceptions to this rule are listed below.\nSecurity\nInfrequently a patch or minor update will remove or change an API in a breaking way, but only if the previous API is considered insecure. These breaking changes will be noted in the changelog and release notes, and published along with a security advisory.\nDraft or Pre-Final ERCs\nERCs that are not Final can change in incompatible ways. For this reason, we avoid shipping implementations of ERCs before they are Final. Some exceptions are made for ERCs that have been published for a long time and seem unlikely to change. Implementations for ERCs that may have breaking changes are published in files named draft-*.sol to make that condition explicit. There is no backwards compatibility guarantee for content in files prefixed with draft.\nStandards that have achieved widespread adoption with strong backwards compatibility expectations from the community may be treated as de-facto finalized and published without the draft- prefix, as extensive ecosystem reliance makes breaking changes highly unlikely.\nVirtual & Overrides\nAlmost all functions in this library are virtual with some exceptions, but this does not mean that overrides are encouraged. There is a subset of functions that are designed to be overridden. By defining overrides outside of this subset you are potentially relying on internal implementation details. We make efforts to preserve backwards compatibility even in these cases but it is extremely difficult and easy to accidentally break. Caution is advised.\nAdditionally, some minor updates may result in new compilation errors of the kind \"two or more base classes define function with same name and parameter types\" or \"need to specify overridden contract\", due to what Solidity considers ambiguity in inherited functions. This should be resolved by adding an override that invokes the function via super.\nSee Extending Contracts for more about virtual and overrides.\nStructs\nStruct members with an underscore prefix should be considered \"private\" and may break in minor versions. Struct data should only be accessed and modified through library functions.\nErrors\nThe specific error format and data that is included with reverts should not be assumed stable unless otherwise specified.\nMajor Releases\nMajor releases should be assumed incompatible. Nevertheless, the external interfaces of contracts will remain compatible if they are standardized, or if the maintainers judge that changing them would cause significant strain on the ecosystem.\nAn important aspect that major releases may break is \"upgrade compatibility\", in particular storage layout compatibility. It will never be safe for a live contract to upgrade from one major release to another.\nStorage Layout\nMinor and patch updates always preserve storage layout compatibility. This means that a live contract can be upgraded from one minor to another without corrupting the storage layout. In some cases it may be necessary to initialize new state variables when upgrading, although we expect this to be infrequent.\nWe recommend using OpenZeppelin Upgrades Plugins or CLI to ensure storage layout safety of upgrades.\nSolidity Version\nThe minimum Solidity version required to compile the contracts will remain unchanged in minor and patch updates. New contracts introduced in minor releases may make use of newer Solidity features and require a more recent version of the compiler.Using with UpgradesPrevious PageAccess ControlNext PageOn this pageAPISecurityDraft or Pre-Final ERCsVirtual & OverridesStructsErrorsMajor ReleasesStorage LayoutSolidity Version","tokens":1050,"squid":"ink-security_audits","role":"Sentinel","at":1791258572713,"hash":"7d7571615647e44f4883225fe038644a8b77333c"}
{"url":"https://io.net/docs/guides/confidential-inference/overview","domain":"io.net","title":"Overview - io.net","text":"​Don’t Trust, Verify\nTraditional AI APIs require you to trust that the provider handles your data securely. With confidential compute, you can verify these guarantees cryptographically:\n\nHardware attestation proves your request ran on genuine, secure GPU hardware\nResponse signatures prove the output came from the attested machine\nNonce verification proves the attestation is fresh, not replayed\n\n​How It Works\n\nRequest attestation with a unique nonce you generate\nio.net routes your request to a confidential compute-enabled GPU machine\nGPU TEE generates a hardware attestation report with a signing key\nVerify the attestation report proves the machine is genuine and secure\nRun inference - responses are signed with the attested key\nVerify signatures to prove responses came from the attested machine\n\n​Key Components\n​Trusted Execution Environment (TEE)\nThe GPU runs inside a Trusted Execution Environment that provides:\n\nMemory isolation - your data is encrypted in memory and inaccessible to the host\nCode integrity - only authorized code can run inside the TEE\nHardware attestation - the GPU can prove its identity and configuration\n\n​Attestation Agent (Open Source)\nThe attestation agent running on GPU machines is fully open source. You can audit the code that generates attestation reports and signs responses:\nRepository: https://github.com/ionet-official/cc-attestation-agent-api\nThis transparency allows you to:\n\nVerify what code is running inside the TEE\nUnderstand exactly what is being attested\nBuild confidence in the verification process\n\n​Attestation Reports\nWhen you request attestation, you receive:\nFieldDescriptiongpuNVIDIA GPU attestation report proving the GPU identity and TEE statecpuCPU attestation report (when available) for additional verificationimage_digestSHA256 hash of the container image running in the TEEsigning_addressPublic key the machine will use to sign inference responsesnonceYour nonce echoed back, proving freshness\n​Response Signatures\nEvery inference response includes cryptographic signatures in the response headers:\nHeaderDescriptiontextThe content that was signedsignatureCryptographic signature of the textsigning_addressPublic key that signed (matches attestation report)signing_algoAlgorithm used for signing\n​What You Can Prove\nCheckWhat It ProvesGPU attestation report is validResponse came from genuine NVIDIA GPU in TEE modeimage_digest matches releaseRunning container hasn’t been tampered withsigning_address matches attestationResponses are signed by the attested machineSignature verifiesResponse was not tampered with in transit and signed on attested machineNonce matches your requestAttestation is fresh, not replayed\n​Privacy Guarantees\nConfidential compute operates in Zero Data Retention (ZDR) mode:\n\nYour prompts and responses are never stored\nOnly token counts are recorded for billing\nNo logs of conversation content exist\n\n​What’s Next\n\nQuick Start API - For developers building integrations\nConfidential Chat - Use the web interface for private conversations\nVerification Guide - Deep dive into verifying attestation and signatures\nWas this page helpful?","tokens":783,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258579958,"hash":"24e13b1a2432e8e504aee8ff6c455f4cf597ea35"}
{"url":"https://docs.openzeppelin.com/contracts","domain":"docs.openzeppelin.com","title":"OpenZeppelin Contracts | OpenZeppelin Docs","text":"OpenZeppelin ContractsOpen in ClaudeOpenZeppelin Contracts is a library of modular, reusable, secure smart contracts for the Ethereum network, written in Solidity.\nGetting Started\nContracts OverviewStart working with the OpenZeppelin Contracts Library.Contracts WizardUse the interactive Contracts Wizard to bootstrap your contract and learn about the components offered in OpenZeppelin Contracts.\nCore Features\nToken StandardsImplementations of ERC20, ERC721, ERC1155, and other token standards.Access ControlManage permissions and roles in your smart contracts securely.GovernanceBuild decentralized governance systems for your protocols.UtilitiesHelper contracts and libraries for common blockchain development tasks.\nToken Standards\nERC-20Fungible token standard implementation with extensions and utilities.ERC-721Non-fungible token (NFT) standard with advanced features.ERC-1155Multi-token standard for both fungible and non-fungible tokens.ERC-4626Tokenized vault standard for yield-bearing assets.\nAdvanced Features\nAccount AbstractionSmart account implementations and account abstraction utilities.Upgradeable ContractsLearn how to build upgradeable smart contracts safely.Contracts WizardInteractive tool to generate smart contracts with custom features.Upgrades PluginsTools for deploying and upgrading smart contracts with Hardhat and Foundry.\nAPI Reference\nAPI OverviewComplete API reference for all OpenZeppelin Contracts.ERC20 APIDetailed API documentation for ERC20 tokens and extensions.ERC721 APIComplete API reference for ERC721 NFT contracts.Access Control APIAPI documentation for access control and ownership patterns.\nTools & Integrations\nRelayerAutomate onchain transactions to schedule jobs, batch calls, and relay gasless meta transactions within your self-hosted infrastructure.MonitorMonitor onchain activity in real time to watch critical events, detect anomalies, trigger alerts on your preferred channels, and set automated responses with Relayer.UI BuilderSpin up user interfaces for any deployed contract. Select the function, auto-generate a React UI with wallet-connect and multi-network support, and export a complete app.Community ContractsAdditional contracts and extensions contributed by the community.OverviewNext PageOn this pageGetting StartedCore FeaturesToken StandardsAdvanced FeaturesAPI ReferenceTools & Integrations","tokens":591,"squid":"ink-security_audits","role":"Sentinel","at":1791258583582,"hash":"b47d5da1d68c5ad535f7b94d9b1aa672c7c4a7d8"}
{"url":"https://io.net/docs/guides/confidential-inference/verification-guide","domain":"io.net","title":"Verification Guide - io.net","text":"​Verification Checklist\nCheckWhat It ProvesHow to VerifyNonce matchesAttestation is fresh, not replayedCompare returned nonce with your generated nonceGPU report is validMachine has genuine NVIDIA GPU in TEE modeVerify report against NVIDIA’s root certificatesCPU report is validMachine’s CPU is in confidential compute modeVerify report against AMD/Intel attestation servicesimage_digest matchesRunning container hasn’t been tampered withCompare with expected digest from official releasesigning_address matchesResponses come from attested machineCompare header with attestation reportSignature verifiesResponse wasn’t modified in transitCryptographic signature verification\n​Understanding the Attestation Report\n​Nonce Verification\nThe nonce prevents replay attacks. Always:\n\nGenerate a unique, random nonce for each attestation request\nVerify the returned nonce starts with what you sent (it gets padded to 64 hex characters)\nNever reuse nonces\n\nimport secrets\n\n# Generate fresh nonce\nnonce = secrets.token_hex(16) # 32 character hex string\n\n# After receiving attestation - nonce is padded with zeros to 64 chars\n# e.g., \"87ebbef3ceb69d2d6d7edc1b05c42ad900000000000000000000000000000000\"\nassert attestation[\"nonce\"].startswith(nonce), \"Nonce mismatch - possible replay attack!\"\n\n​GPU Attestation Report\nThe gpu field contains NVIDIA’s hardware attestation:\n{\n \"gpu\": {\n \"nonce\": \"87ebbef3ceb69d2d6d7edc1b05c42ad900000000000000000000000000000000\",\n \"arch\": \"HOPPER\",\n \"evidence_list\": [\n {\n \"evidence\": \"<base64-encoded attestation evidence>\",\n \"certificate\": \"<base64-encoded certificate chain to NVIDIA root>\"\n }\n ],\n \"claims_version\": \"3.0\"\n }\n}\n\nThis proves:\n\nThe GPU is a genuine NVIDIA device (architecture identified, e.g., “HOPPER”)\nThe GPU is running in Confidential Computing mode\nThe GPU’s firmware and configuration are in a known-good state\nMultiple GPUs may have multiple evidence entries in evidence_list\n\nVerification:\nUse NVIDIA’s attestation API to verify the GPU evidence list:\n\nNVIDIA Multi-GPU Attestation API\nSubmit the evidence_list from the attestation response\nThe API validates the certificate chain and returns verification status\n\n​CPU Attestation Report\nThe cpu field (when present) contains CPU-level attestation:\n{\n \"cpu\": {\n \"quote\": \"<hex-encoded CPU attestation quote>\"\n }\n}\n\nThis proves:\n\nThe CPU is running in a Trusted Execution Environment (AMD SEV-SNP or Intel TDX)\nThe VM’s memory is encrypted and isolated from the host\n\nVerification:\nUse the proof verifier to verify the CPU attestation quote:\n\nt16z Proof Verifier\nSubmit the cpu.quote from the attestation response\nThe verifier validates the quote against Intel TDX attestation\n\n​Image Digest\nThe image_digest field contains the SHA256 hash of the container image running in the TEE:\n{\n \"image_digest\": \"sha256:cf47db862b96b243e077a80ee51afa2c007604bf3c648232d42144947e56c339\"\n}\n\nThis allows you to verify that the expected code is running inside the TEE.\nVerification: Compare the image_digest with the expected digest published in the latest official release. If the digests match, you can be confident the running container hasn’t been tampered with.\n​Signing Address\nThe signing_address is the Ethereum-style public address the attested machine will use to sign inference responses:\n{\n \"signing_address\": \"0xf52373547CAa0EeCB0fcD34042D7518E79aA80cC\"\n}\n\nThis key is generated inside the TEE and its binding to the attestation report proves that:\n\nOnly the attested machine holds the private key\nResponses signed with this key came from the attested hardware\n\n​Verifying Response Signatures\nEvery confidential inference response includes signature headers:\nHeaderDescriptiontextThe content that was signed (typically the response body)signatureCryptographic signature over textsigning_addressPublic key that created the signaturesigning_algoSigning algorithm (e.g., ecdsa)image_digestSHA256 hash of the container image running in the TEE\n​Verification Steps\n\nVerify signing address matches attestation\n\nassert response_headers[\"signing_address\"].lower() == \\\n attestation[\"signing_address\"].lower(), \\\n \"Signing address mismatch!\"\n\nVerify the cryptographic signature\n\nFor ecdsa signatures (Ethereum-style):\nfrom eth_account.messages import encode_defunct\nfrom eth_account import Account\n\ndef verify_ecdsa_signature(text: str, signature: str, expected_address: str) -> bool:\n \"\"\"Verify an Ethereum-style signature.\"\"\"\n message = encode_defunct(text=text)\n recovered_address = Account.recover_message(message, signature=signature)\n return recovered_address.lower() == expected_address.lower()\n\n# Verify\nis_valid = verify_ecdsa_signature(\n text=response_headers[\"text\"],\n signature=response_headers[\"signature\"],\n expected_address=attestation[\"signing_address\"]\n)\n\nif not is_valid:\n raise SecurityError(\"Response signature verification failed!\")\n\nVerify content integrity\n\nEnsure the signed text matches the response you received:\nimport json\n\n# For non-streaming responses, verify the signed text matches the response\nresponse_body = response.json()\nsigned_text = response_headers[\"text\"]\n\n# The exact format of signed_text depends on implementation\n# Typically it's the JSON response body or a hash of it\n\n​Complete Verification Flow\nimport secrets\nimport requests\nfrom eth_account.messages import encode_defunct\nfrom eth_account import Account\n\nclass ConfidentialClient:\n def __init__(self, api_key: str, base_url: str = \"https://api.intelligence.io.solutions/v1/private\"):\n self.api_key = api_key\n self.base_url = base_url\n self.attestation = None\n self.nonce = None\n\n def _headers(self):\n return {\n \"Authorization\": f\"Bearer {self.api_key}\",\n \"Content-Type\": \"application/json\"\n }\n\n def attest(self, model_id: str) -> dict:\n \"\"\"Get and verify attestation for a model.\"\"\"\n # Generate fresh nonce\n self.nonce = secrets.token_hex(16)\n\n response = requests.post(\n f\"{self.base_url}/attestation\",\n headers=self._headers(),\n json={\"model_id\": model_id, \"nonce\": self.nonce}\n )\n response.raise_for_status()\n self.attestation = response.json()\n\n # Verify nonce freshness (nonce is padded to 64 hex chars)\n if not self.attestation[\"nonce\"].startswith(self.nonce):\n raise SecurityError(\"Nonce mismatch - possible replay attack!\")\n\n # TODO: Verify GPU/CPU attestation reports against root certificates\n # This requires NVIDIA/AMD attestation verification libraries\n\n return self.attestation\n\n def complete(self, model: str, messages: list, **kwargs) -> dict:\n \"\"\"Run verified confidential inference.\"\"\"\n if not self.attestation:\n raise ValueError(\"Must call attest() before complete()\")\n\n response = requests.post(\n f\"{self.base_url}/completions\",\n headers=self._headers(),\n json={\"model\": model, \"messages\": messages, **kwargs}\n )\n response.raise_for_status()\n\n # Extract signature headers\n sig_headers = {\n \"text\": response.headers.get(\"text\"),\n \"signature\": response.headers.get(\"signature\"),\n \"signing_address\": response.headers.get(\"signing_address\"),\n \"signing_algo\": response.headers.get(\"signing_algo\")\n }\n\n # Verify signing address matches attestation\n if sig_headers[\"signing_address\"].lower() != \\\n self.attestation[\"signing_address\"].lower():\n raise SecurityError(\"Signing address doesn't match attestation!\")\n\n # Verify signature\n if not self._verify_signature(sig_headers):\n raise SecurityError(\"Response signature verification failed!\")\n\n return response.json()\n\n def _verify_signature(self, headers: dict) -> bool:\n \"\"\"Verify response signature.\"\"\"\n if headers[\"signing_algo\"] == \"ecdsa\":\n message = encode_defunct(text=headers[\"text\"])\n recovered = Account.recover_message(\n message,\n signature=headers[\"signature\"]\n )\n return recovered.lower() == headers[\"signing_address\"].lower()\n else:\n raise ValueError(f\"Unknown signing algorithm: {headers['signing_algo']}\")\n\nclass SecurityError(Exception):\n pass\n\n# Usage\nclient = ConfidentialClient(api_key=\"your-key\")\nclient.attest(model_id=\"model-uuid-here\")\nresponse = client.complete(\n model=\"meta-llama/Llama-3.3-70B-Instruct\",\n messages=[{\"role\": \"user\", \"content\": \"Hello\"}]\n)\n\n​Security Guarantees Summary\nVerificationThreat MitigatedNonce verificationReplay attacks - attacker cannot reuse old attestation reportsGPU attestationFake hardware - proves response came from genuine NVIDIA GPU in TEECPU attestationHost compromise - proves VM memory is encrypted and isolatedImage digest matchCode tampering - proves container hasn’t been modifiedSigning address matchMan-in-the-middle - proves response came from attested machineSignature verificationTampering - proves response wasn’t modified in transit\n​Troubleshooting\n​Nonce Mismatch\nSymptom: Returned nonce doesn’t start with the one you sent.\nCause: Possible replay attack, caching issue, or request routing error.\nNote: The returned nonce is padded with zeros to 64 hex characters. For example, if you send 87ebbef3ceb69d2d6d7edc1b05c42ad9, you’ll receive 87ebbef3ceb69d2d6d7edc1b05c42ad900000000000000000000000000000000.\nSolution: Use startswith() for comparison instead of exact match. Generate a new nonce and retry if verification fails. If persistent, contact support.\n​Signature Verification Fails\nSymptom: Cryptographic signature doesn’t verify.\nPossible Causes:\n\nResponse was modified in transit\nEncoding mismatch in signed text\nWrong signing algorithm used for verification\n\nSolution:\n\nEnsure you’re using the correct signing algorithm from the header\nVerify the text header encoding matches what you’re verifying\nCheck for any proxy or middleware that might modify responses\n\n​Signing Address Mismatch\nSymptom: Response signing_address doesn’t match attestation.\nPossible Causes:\n\nAttestation expired and machine rotated keys\nRequest was routed to a different machine\n\nSolution: Re-request attestation before inference. Attestation should be refreshed periodically.\n​What’s Next\n\nQuick Start API - For developers building integrations\nConfidential Chat - Use the web interface for private conversations\nWas this page helpful?","tokens":2486,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258590009,"hash":"5993899d34f42c8f8140aa4638f1d4740d1b8543"}
{"url":"https://docs.openzeppelin.com/symbiotic","domain":"docs.openzeppelin.com","title":"Symbiotic Templates | OpenZeppelin Docs","text":"Symbiotic TemplatesOpen in ClaudeFor Operators\nRunning, configuring, and monitoring the stack.\n\nSetup -- Config structure, environment setup, running locally\nDeployment -- Testnet deployment\nChoose your provider:\n\nLayerZero -- DVN for LayerZero V2\nChainlink CCV -- Cross-Chain Verifier for CCIP\n\nAcceptance Hooks -- Native and webhook policy checks before batching\nCLI & API Reference -- Commands, HTTP endpoints, webhook config\nTroubleshooting -- Common issues and debugging\n\nFor Integrators\nUnderstanding the system and adding new providers.\n\nArchitecture -- Provider model, shared infra, Merkle batching, BLS signing\nChoose your provider:\n\nLayerZero -- Message flow, contracts, code pointers\nChainlink CCV -- Message flow, contracts, code pointers\n\nAcceptance Hooks -- Hook contract and webhook wire format\nArchitecture: Adding a New Provider -- Provider trait, registration, templates\nSecurity -- Trust model, access control, invariants\nStoragePrevious PageSetupNext PageOn this pageFor OperatorsFor Integrators","tokens":254,"squid":"ink-security_audits","role":"Sentinel","at":1791258593813,"hash":"1f196fa9b7fba41b0d4d0976167d2b41cb6b0890"}
{"url":"https://vote.optimism.io/proposals/71046981157786379776549698790429169615693449771144448151464817786433292182423","domain":"vote.optimism.io","title":"Re-designating the User Airdrop Alloc...","text":"ProposalsVotersConnect  Wallet Standard Proposal by The Optimism FoundationRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundProposal Visualization No substantive onchain transactions.This proposal seeks approval to re-designate the 546.9M OP remaining in the User Airdrop allocation as a new Strategic Ecosystem Fund.\nThe Strategic Ecosystem Fund would establish a dedicated token allocation for the Foundation to support the adoption and growth of OP Mainnet and OP Enterprise, including through partnership deals that bring chains, protocols, institutions, and infrastructure to the OP Stack; incentives that deepen onchain activity and liquidity on OP Mainnet; and deals that expand the OP Stack’s reach with institutions and top-tier brands.\nRead the full proposal here.FOR - 17,973,915 AGAINST - 10,930,696 Quorum 16,540,389 Threshold 51%EXECUTEDExecuted 6:30 am Aug 23, 2026VotersHasn't voteddelegate.testinprod-io.eth8,485,956 Winning an enterprise deal is hard. Tokens are usually part of the deal, and the bidding is competitive. We think exact numbers (e.g., allocation per deal) are exactly what we shouldn't want disclosed as competitors could just match them. \n\nWe're in an uphill battle, the enterprise market is expensive, and the window is now. We think we need the war chest today, and we should be careful about handing information to competitors. So we're voting For, with one ask: as you execute, please share what you can after the fact (e.g., aggregate deployment and outcomes). We think that's what token holders actually need.op.evabeylin.eth4,000,000 delegate.l2beat.eth3,961,743 our rationale is given in the forum threadolimpio.eth2,165,459 polynya.eth2,133,473 cerv1.eth2,000,002 The airdrop meta is over - would prefer to see these funds allocated towards new growth tboptimist.eth2,000,000 layer3xyz.eth1,162,484 opmichael.eth428,415 Standard Proposal by The Optimism FoundationRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundProposal Visualization Loading transactions...No substantive onchain transactions.This proposal seeks approval to re-designate the 546.9M OP remaining in the User Airdrop allocation as a new Strategic Ecosystem Fund.\nThe Strategic Ecosystem Fund would establish a dedicated token allocation for the Foundation to support the adoption and growth of OP Mainnet and OP Enterprise, including through partnership deals that bring chains, protocols, institutions, and infrastructure to the OP Stack; incentives that deepen onchain activity and liquidity on OP Mainnet; and deals that expand the OP Stack’s reach with institutions and top-tier brands.\nRead the full proposal here.FOR - 17,973,915 AGAINST - 10,930,696 Quorum 16,540,389 Threshold 51%EXECUTEDExecuted 11:30 am Aug 23, 2026VotersHasn't votedLoading votes...Re-designating the User Airdrop Alloc...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":740,"squid":"ink-governance","role":"Council Listener","at":1791258599879,"hash":"bc7c221b72f3077c696127dd1e7a1dfd52207999"}
{"url":"https://io.net/docs/guides/intelligence/integrations/openrouter-byok","domain":"io.net","title":"Use io.net Models on OpenRouter (BYOK) - io.net","text":"​Overview\nOpenRouter’s Bring Your Own Key (BYOK) lets you route OpenRouter requests for io.net models through your own io.net account. You keep OpenRouter’s unified API, SDKs, and routing, while inference is served and billed by io.net against your io.net credits — at io.net’s direct rates instead of a resale markup.\n​Why use it\n\nPay io.net’s rate on your own io.net balance — your account, your rate limits and quotas.\nLow OpenRouter fee — BYOK is 0% for your first 1,000,000 requests each month (5% thereafter), charged to your OpenRouter credits.\nNo code changes — keep the OpenRouter SDKs and tooling you already use.\nPin io.net for the latency or throughput you want, with fallback control.\n\n​How it works\n\n​Prerequisites\n1An io.net account with an API key and creditsCreate an API key in your io.net account and make sure the account has a positive credit balance — this is what pays for inference. See API Keys and Secrets and IO Intelligence Payments.2An OpenRouter account with creditsOpenRouter still needs a small credit balance to cover its BYOK fee. Add credits at openrouter.ai/settings/credits.\n​Set it up\n1Copy your io.net API keyFrom your io.net account, create or copy an API key. Keep it handy for the next step.2Register the key in OpenRouterOpen OpenRouter’s BYOK settings for io.net at openrouter.ai/settings/integrations and select io.net.\nClick Add key and paste your io.net API key.\nPlace it in the Prioritized section so OpenRouter uses it first.\nMake sure the key’s toggle is enabled.\nEnable “Always use for this provider” if you want requests to fail rather than silently fall back to OpenRouter’s shared io.net capacity.3Allow the io.net providerCheck openrouter.ai/settings/privacy and confirm io.net is not in your ignored providers list.\nGive the new key about a minute to take effect before testing.\n​Make a request\nCall OpenRouter as usual and pin the io.net provider so your BYOK key is used:\ncurl https://openrouter.ai/api/v1/chat/completions \\\n -H \"Authorization: Bearer $OPENROUTER_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model\": \"z-ai/glm-5.2\",\n \"messages\": [{ \"role\": \"user\", \"content\": \"Hello!\" }],\n \"provider\": { \"only\": [\"io-net\"], \"allow_fallbacks\": false },\n \"usage\": { \"include\": true }\n }'\nfrom openai import OpenAI\n\nclient = OpenAI(\n base_url=\"https://openrouter.ai/api/v1\",\n api_key=\"<your OpenRouter API key>\",\n)\n\nresp = client.chat.completions.create(\n model=\"z-ai/glm-5.2\",\n messages=[{\"role\": \"user\", \"content\": \"Hello!\"}],\n extra_body={\n \"provider\": {\"only\": [\"io-net\"], \"allow_fallbacks\": False},\n \"usage\": {\"include\": True},\n },\n)\nprint(resp.choices[0].message.content)\n\nAvailable io.net models on OpenRouter: z-ai/glm-5.2, qwen/qwen3.6-27b. Browse the live list on the io.net provider page.\n​Confirm BYOK is being used\nThe response usage block tells you whether your key served the request:\n\"usage\": { \"is_byok\": true, \"cost\": 0 }\n\nis_byok: true means the request went through your io.net key. If you see is_byok: false, OpenRouter served it from its shared io.net capacity instead — see Troubleshooting.\n​Pricing\n\nInference is billed by io.net to your io.net credits, at io.net’s rates.\nOpenRouter charges a BYOK fee from your OpenRouter credits: 0% for the first 1M BYOK requests per month, 5% thereafter.\n\n​Troubleshooting\n402 Insufficient creditsYour OpenRouter account has no balance. BYOK still needs OpenRouter credits to cover its fee — add credits at openrouter.ai/settings/credits.404 No allowed providers / all providers ignoredio.net is in your OpenRouter ignored providers list. Un-ignore it at openrouter.ai/settings/privacy.usage.is_byok is falseOpenRouter served the request from shared capacity instead of your key. Re-check that the BYOK key is Prioritized + enabled on the correct OpenRouter account, and allow ~1 minute for changes to propagate.io.net returns 401 / 403Your io.net key is invalid or the io.net account is out of credits. Recreate the key or top up your io.net balance.\n​Reference\n\nOpenRouter BYOK overview\nOpenRouter BYOK settings\nio.net provider on OpenRouter\nWas this page helpful?","tokens":1024,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258600021,"hash":"1cc99b261aa9f6f1824da0e72daf795ab6dde3fd"}
{"url":"https://docs.pyth.network/price-feeds/core/price-feeds/asset-classes","domain":"docs.pyth.network","title":"Asset Classes | Pyth Developer Hub","text":"Pyth CorePrice FeedsAsset ClassesOverview of the asset classes covered by Pyth price feedsPyth price feeds provide market data for the following asset classes:\nAsset ClassSubclassDefinitionCryptoSpot PricesReal-time prices for cryptocurrencies and digital assetsRedemption RatesReal-time swap rates derived from smart contracts for the redemption of liquid staking and liquid restaking tokens (LSTs and LRTs), liquidity provider tokens (LP Tokens) and interest-bearing assets, including tokenised notesIndicesReal-time prices that measure the performance of baskets of cryptocurrencies and digital assetsUS EquitiesSpot PricesReal-time prices for US equitiesFXSpot PricesReal-time prices for fiat currency pairsMetalsSpot PricesReal-time prices for precious metalsRatesFuture PricesReal-time prices for fixed income products, including bond futuresCommoditiesFutures PricesReal-time prices for commodity futuresEnergySpot PricesReal-time prices for a non-expiring Contract for Difference (CFD) that tracks the price of the assetFutures PricesReal-time prices for energy futures contract\nNOTE: When integrating with Energy Futures Price Feeds, it is not recommended to rely solely on the first month expiry price feed as there is often lower liquidity towards expiration.\nBest practice is to combine, 1-month, 2-month and 3-month feeds or use the weighted average which is represented by spot price(USOILSPOT or UKOILSPOT).\nPlease refer to the Best Practices page for more information.Price Feed IDsList of price feed IDs for all the assets supported by Pyth CoreCurrent FeesPyth Core update fees are zero on every supported network","tokens":408,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258606159,"hash":"7016ce6b6f3daa380000a6ae73df3f2ee7ff21c3"}
{"url":"https://io.net/docs/guides/intelligence/sub-api-keys","domain":"io.net","title":"Sub-API Keys - io.net","text":"Sub-API keys allow an account holder (the admin) to issue multiple child API keys, each independently controlled. Each sub-key can be restricted to specific models, given a spending cap per billing cycle, and revoked at any time — without touching the admin key or other sub-keys.\n​Overview\nWhen you create a sub-key:\n\nIt inherits your account’s credit pool — there is no separate balance to fund.\nYou optionally cap how much of that pool any single sub-key can consume per billing period.\nYou optionally restrict which models the sub-key can call.\nThe sub-key’s usage feeds back into your account’s overall billing.\n\nThis is useful for:\n\nTeams — give each team or project its own key with a monthly budget.\nPartners / customers — provide programmatic API access with hard credit limits so a single integration can never exhaust your entire balance.\nServices — isolate microservices with model allow-lists so they can only call the models they need.\n\n​Authentication\nAll sub-key management endpoints use your admin API key in the x-api-key header. Sub-keys themselves authenticate inference calls (chat completions, embeddings, etc.) using the same header — they are recognized automatically by the API.\n# Admin operations (create, list, update, revoke)\n-H \"x-api-key: $ADMIN_API_KEY\"\n\n# Inference calls using a sub-key\n-H \"x-api-key: $SUB_API_KEY\"\n\nSub-keys cannot create further sub-keys. Only an admin key can manage the key hierarchy.\n​Creating a Sub-API Key\n1Call the create endpoint with your admin keycurl -X POST \"https://api.io.solutions/v1/api-keys/sub-keys\" \\\n -H \"x-api-key: $ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"description\": \"Partner integration – Acme Corp\",\n \"allowed_models\": [\"meta-llama/Llama-3.3-70B-Instruct\"],\n \"credit_limit\": 10.0,\n \"credit_refresh_cycle\": \"monthly\",\n \"key_prefix\": \"acme\"\n }'\n2Store the returned key value securelyThe response includes a value field with the full key string (e.g. acme-v2-eyJhbGci...). This is shown only once. Copy it to a secret manager immediately — it cannot be retrieved again.{\n \"status\": \"succeeded\",\n \"data\": {\n \"key_id\": \"71775d2e-fbcc-4ef4-aa30-8aaeb82062c0\",\n \"value\": \"acme-v2-eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...\",\n \"display\": \"acme-v2-eyJh...c0eQ\",\n \"description\": \"Partner integration – Acme Corp\",\n \"allowed_models\": [\"meta-llama/Llama-3.3-70B-Instruct\"],\n \"credit_limit\": 10.0,\n \"credit_refresh_cycle\": \"monthly\",\n \"expires_at\": \"2026-08-20T00:00:00\"\n }\n}\n3Distribute the sub-key to its intended user or serviceThe recipient uses the sub-key exactly like a regular API key — just pass it in the x-api-key header for inference calls.\n​Request Parameters\nFieldTypeRequiredDescriptiondescriptionstringYesHuman-readable label for the key.allowed_modelsstring[]NoList of model IDs this key may call. Omit to allow all models.credit_limitnumberNoMaximum credits per refresh cycle. Omit for no per-key cap.credit_refresh_cyclestringNoWhen the usage counter resets: \"8h\", \"daily\", \"weekly\", \"monthly\" (default).expires_atdatetime / \"never\"NoKey expiry. Defaults to 180 days from creation.key_prefixstringNo2–8 char lowercase slug prepended to the key (e.g. \"acme\" → acme-v2-...). Defaults to the standard io-v2 prefix.\n​Model Restrictions\nWhen allowed_models is set, any request to a model not in the list is rejected with 403 Forbidden, even if the admin key has access to that model.\nThe GET /v1/models endpoint, when called with a sub-key, returns only the models in the sub-key’s allow-list — so integrations can discover their permitted set without any extra configuration.\nTo remove all restrictions on an existing sub-key, pass an empty array:\ncurl -X PATCH \"https://api.io.solutions/v1/api-keys/sub-keys/{key_id}\" \\\n -H \"x-api-key: $ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"allowed_models\": []}'\n\n​Credit Limits\n​How limits are enforced\nCredit limits are evaluated once per billing cycle by the settlement pipeline (which runs every ~60 seconds). When a sub-key’s accumulated spend in the current period exceeds its credit_limit, the key is automatically blocked and inference calls return 429 Too Many Requests.\nThe block clears automatically when the cycle resets (credit_refresh_cycle), or immediately when you raise the limit via PATCH.\n​Blocking and unblocking\nA sub-key is returning 429 — how do I unblock it?The key has exceeded its credit_limit for the current period. You have two options:Raise the limit immediately:curl -X PATCH \"https://api.io.solutions/v1/api-keys/sub-keys/{key_id}\" \\\n -H \"x-api-key: $ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\"credit_limit\": 50.0}'\nWait for the next cycle reset — the key unblocks automatically when credit_refresh_cycle rolls over.How do I check how much a sub-key has spent?Use the admin endpoint to inspect a specific key:curl \"https://api.io.solutions/v1/api-keys/sub-keys/{key_id}/usage\" \\\n -H \"x-api-key: $ADMIN_API_KEY\"\nOr let the sub-key check itself:curl \"https://api.io.solutions/v1/api-keys/sub-keys/me/usage\" \\\n -H \"x-api-key: $SUB_API_KEY\"\nWhat happens to my account balance when a sub-key is blocked?The block applies only to that specific sub-key. Your admin key and all other sub-keys continue operating normally. The admin’s overall account balance is not affected by per-key limits.\n​Credit Refresh Cycles\nThe credit_refresh_cycle determines when a sub-key’s credit_used counter resets to zero, allowing spending up to credit_limit again.\nCycleResets at8hEvery 8 hours aligned to midnight UTC (00:00, 08:00, 16:00).dailyMidnight UTC each day.weeklyMonday 00:00 UTC.monthlyThe 1st of each month at 00:00 UTC.\n​Custom Key Prefix\nBy default, sub-keys follow the standard io-v2- format. You can supply a custom key_prefix to make keys visually identifiable:\n{ \"key_prefix\": \"acme\" }\n\nProduces: acme-v2-eyJhbGci...\nPrefix rules:\n\n2–8 characters, lowercase letters, digits, and internal hyphens only.\nCannot start with io (reserved for platform keys).\nCannot contain version markers like -v2.\n\nThe prefix does not change any functionality — it is purely cosmetic for organizational clarity.\n​Managing Sub-Keys\n​Listing keys\ncurl \"https://api.io.solutions/v1/api-keys/sub-keys\" \\\n -H \"x-api-key: $ADMIN_API_KEY\"\n\nReturns all active sub-keys with their current credit_used for the active billing period.\n​Updating a key\nAll fields on a sub-key can be updated at any time. Only the fields you include in the PATCH body are changed:\ncurl -X PATCH \"https://api.io.solutions/v1/api-keys/sub-keys/{key_id}\" \\\n -H \"x-api-key: $ADMIN_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"description\": \"Updated label\",\n \"credit_limit\": 25.0,\n \"credit_refresh_cycle\": \"weekly\"\n }'\n\n​Revoking a key\ncurl -X DELETE \"https://api.io.solutions/v1/api-keys/sub-keys/{key_id}\" \\\n -H \"x-api-key: $ADMIN_API_KEY\"\n\nRevocation is immediate and permanent. Any subsequent inference call with the revoked key returns 401 Unauthorized.\n​Viewing Usage\n​All sub-keys (admin)\ncurl \"https://api.io.solutions/v1/api-keys/sub-keys/usage\" \\\n -H \"x-api-key: $ADMIN_API_KEY\"\n\nReturns a per-key breakdown of token consumption and credit cost, grouped by model, for today and all time — plus aggregate totals across all sub-keys.\n​Single sub-key (admin)\ncurl \"https://api.io.solutions/v1/api-keys/sub-keys/{key_id}/usage\" \\\n -H \"x-api-key: $ADMIN_API_KEY\"\n\n​Self-service (sub-key holder)\ncurl \"https://api.io.solutions/v1/api-keys/sub-keys/me/usage\" \\\n -H \"x-api-key: $SUB_API_KEY\"\n\n​FAQs\nDo sub-keys have their own credit balance?No. Sub-keys draw from the admin’s account balance. The credit_limit is a spending cap per cycle, not a separate balance. All usage by sub-keys is deducted from the same pool as the admin’s own usage.Can a sub-key call any model endpoint?Only the models listed in allowed_models. If no list is configured, the sub-key can call any model available to the admin account. The /v1/models endpoint filters its response to only show the permitted models when called with a sub-key.What happens when the cycle resets?The sub-key’s credit_used counter is reset to zero at the start of each new period. If the key was blocked due to exceeding its limit, it is automatically unblocked.How quickly does blocking take effect after the limit is exceeded?The billing settlement pipeline runs approximately every 60 seconds. Once a sub-key’s accumulated spend exceeds its credit_limit, the block is applied within the next pipeline run.Can I have sub-keys without a credit limit?Yes. Omit credit_limit (or set it to null) when creating or updating a sub-key. The key will only be limited by the admin’s overall account balance.Is the key prefix stored anywhere?No. The prefix is encoded in the key string itself. The display value (e.g. acme-v2-eyJh...c0eQ) shows the prefix so you can identify it, but it is not stored separately in the database.Was this page helpful?","tokens":2216,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258622068,"hash":"c0c83cc538526f46f5d4c74ec64f6fd8826d5c85"}
{"url":"https://vote.optimism.io/delegates/0x1b686ee8e31c5959d9f5bbd8122a58682788eead","domain":"vote.optimism.io","title":"delegate.l2beat.eth on Agora","text":"Voted against this proposal about 2 months ago with 3.96M votesRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundReason: our rationale is given in the forum threadVoted for this proposal 3 months ago with 3.98M votesSecurity Council Operating BudgetVoted for this proposal 3 months ago with 3.98M votesSequencer ETH Management: 12-Month Renewal and Treasury OptimizationVoted abstain this proposal 3 months ago with 3.98M votesDeveloper Advisory Board Dissolution ProposalVoted abstain this proposal 3 months ago with 3.98M votesOperating Manual Update ProposalVoted abstain this proposal 3 months ago with 3.98M votesGrants Council Dissolution ProposalVoted abstain this proposal 3 months ago with 3.98M votesMilestones and Metrics Council Dissolution ProposalVoted on 3 options in this proposal 4 months ago with 3.96M votes[Second vote] Security Council Elections Cohort B MembersVoted: Alex Soto, Matthew Slipper, donnohVoted on 3 options in this proposal 4 months ago with 3.95M votesSecurity Council Elections Cohort B MembersVoted: Alex Soto, Matthew Slipper, donnohVoted for this proposal 8 months ago with 5.09M votesProposal to Align OP Token with Superchain SuccessVoted for this proposal 8 months ago with 5.09M votesDAO Operating Budget Midpoint AdjustmentVoted on 7 options in this proposal 12 months ago with 4.78M votesSecurity Council Elections Cohort A MembersVoted: Agora, Cyfrin, Emiliano, Mariano, pablito.eth, Uniswap Foundation, VelodromeVoted on 1 options in this proposal 12 months ago with 4.78M votesSecurity Council Elections: Cohort A LeadalishaVoted for this proposal about 1 year ago with 5.04M votesSecurity Council Season 7 Retroactive Funding RequestVoted on 7 options in this proposal about 1 year ago with 5.12M votesDeveloper Advisory Board Election: MembersVoted: blockdev, devtooligan, m4rio, 𓀣 Odysseas.eth 𓀢, shazow, Vectorized, wbnnsReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/19Voted on 3 options in this proposal about 1 year ago with 5.12M votesMilestones & Metrics Council Election: ReviewersVoted: Brichis, SEEDGov, v3naruReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/19Voted on 4 options in this proposal about 1 year ago with 5.12M votesGrants Council Election: Final ReviewerVoted: GFX Labs, MasterMojo, mattgov.eth, MichaelReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/19Voted on 4 options in this proposal about 1 year ago with 5.12M votesSeason 8/9 Operating BudgetsVoted: Developer Advisory Board Operating Budget, Grants Council Operating Budget, Milestones & Metrics Council Operating Budget, Security Council Operating BudgetReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/19Voted for this proposal about 1 year ago with 5.12M votesAnticapture Commission Dissolution ProposalReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/19Voted on 1 options in this proposal about 1 year ago with 5.12M votesGrants Council Election: OperationsBunnicReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/19Voted for this proposal about 1 year ago with 5.12M votesBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9Voted for this proposal about 1 year ago with 5.12M votesUpgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in CannonVoted for this proposal over 1 year ago with 5.03M votesSeason 8/9 Grants Council CharterVoted for this proposal over 1 year ago with 5.03M votesSeason 8/9 Milestones and Metrics Council CharterVoted against this proposal over 1 year ago with 5.03M votesGovernor Update Proposal: Removing Abstain Count from QuorumVoted for this proposal over 1 year ago with 5.03M votesSeason 8/9 Developer Advisory Board CharterVoted for this proposal over 1 year ago with 5.03M votesSeason 8: Intent RatificationVoted for this proposal over 1 year ago with 5.06M votesSeason 8 and 9 Milestone and Metrics Council SelectionReason: https://gov.optimism.io/t/season-8-and-9-milestone-and-metrics-council-selection/9963/22Voted for this proposal over 1 year ago with 5.11M votesSeason 8 and 9: Budget Board Member RatificationReason: https://gov.optimism.io/t/season-8-and-9-budget-board-member-ratification/9819/11Voted for this proposal over 1 year ago with 5.31M votesUpgrade Proposal #13: OPCM and Incident Response improvementsVoted for this proposal over 1 year ago with 5.37M votesProtocol Upgrade: Superchain Registry 2.0Reason: We are supportive of the proposal as we don't see anything contentious about it, and we see it as a significant improvement to the past processes. We agree with DAB comments regarding the need for auditing OPCM contracts before using them for upgrading Superchain chains. We would also like to point out that we welcome this change internally as it will allow L2BEAT to monitor Superchain chains easier and more effectively. :)Voted on 3 options in this proposal over 1 year ago with 5.38M votesMilestones and Metrics Council Reviewer ElectionsVoted: mel.eth (StableLab), v3naru_Curia, Takeshi (Tané)Reason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 2 options in this proposal over 1 year ago with 5.38M votesDeveloper Advisory Board Audit Request Team ElectionsVoted: noah.eth, gjaldonReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 4 options in this proposal over 1 year ago with 5.38M votesGrants Council Final Reviewer ElectionsVoted: MattGov.eth, GFX Lab, Michael, jackanorakReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 3 options in this proposal over 1 year ago with 5.38M votesGrants Council GrantNerd ElectionsVoted: Brichis, Jrocki, mastermojoReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted for this proposal over 1 year ago with 5.38M votesSeason 7: Chain Delegation Program AmendmentReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 2 options in this proposal over 1 year ago with 5.38M votesDeveloper Advisory Board Foundation Mission Team ElectionsVoted: Ed, SkeletorReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 1 options in this proposal over 1 year ago with 5.38M votesGrants Council Operations ElectionsBunnicReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 3 options in this proposal over 1 year ago with 5.38M votesDeveloper Advisory Board Governance Mission Team ElectionsVoted: Will, Jepsen, blockdevReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted on 6 options in this proposal over 1 year ago with 5.38M votesSecurity Council Elections Cohort B MembersVoted: World Foundation, L2BEAT, Test in Prod, Kris Kaczor, Ink, CoinbaseReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263Voted for this proposal almost 2 years ago with 5.44M votesSeason 7: Milestones and Metrics Council Operating BudgetReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/12Voted for this proposal almost 2 years ago with 5.44M votesSeason 7: Developer Advisory Board Operating BudgetReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/12Voted for this proposal almost 2 years ago with 5.44M votesSeason 7: Grants Council Operating BudgetReason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/12Voted for this proposal almost 2 years ago with 5.44M votesSeason 7: Security Council Operating Budget [Onchain]Reason: https://gov.optimism.io/t/l2beat-delegate-communication-thread/4263/12Voted for this proposal almost 2 years ago with 5.44M votesGrants Council Mission [Onchain]Voted for this proposal almost 2 years ago with 5.44M votesDecision Market Mission [Onchain]Voted for this proposal almost 2 years ago with 5.44M votesSeason 7: Intent RatificationReason: https://gov.optimism.io/t/season-7-intent/9292/8Voted for this proposal almost 2 years ago with 5.44M votesCode of Conduct Council Dissolution ProposalReason: https://gov.optimism.io/t/code-of-conduct-council-dissolution-proposal/9321/12Voted for this proposal almost 2 years ago with 5.44M votesSeason 7: Anticapture Commission AmendmentReason: https://gov.optimism.io/t/season-7-anticapture-commission-charter-amendment/9354/18Voted for this proposal almost 2 years ago with 5.44M votesUpgrade Proposal #11: Holocene Network UpgradeReason: https://gov.optimism.io/t/upgrade-proposal-11-holocene-network-upgrade/9313/33Voted for this proposal almost 2 years ago with 5.44M votesOnchain Treasury Transfer Cancellation TestReason: Let's go!Voted for this proposal almost 2 years ago with 5.48M votesOnchain Treasury Transfer TestReason: Go onchain transfer votes!Voted for this proposal almost 2 years ago with 5.84M votesGovernor Update Proposal #3: Enable Onchain Treasury ExecutionReason: We are voting FOR enabling onchain treasury execution, although we would like to note that in our opinion this is only a first, almost symbolic step in passing the control of the treasury to the governance. We will be sharing extended rationale and our thoughts soon in our delegate communication thread.Voted for this proposal almost 2 years ago with 5.84M votesSeason 6: Standard Rollup Charter RatificationReason: We are voting in favor of ratifying the Standard Rollup Charter, we will be sharing extended rationale and our thoughts soon on in the delegate thready.almost 2 years ago with 5.15M votesRolling Mission Requests: Voting Cycle 28Reason: https://gov.optimism.io/t/mission-request-increase-prevalence-of-non-usd-euro-stablecoins/8951/11about 2 years ago with 5.2M votesRolling Mission Requests: Voting Cycle 27Voted for this proposal about 2 years ago with 5.2M votesRolling Mission RequestsReason: We are voting in favor of Rolling Mission Requests, as having an available budget but having to wait for next season to utilize it doesn’t seem reasonable. about 2 years ago with 5.21M votesSecurity Council Elections Cohort A MembersReason: https://gov.optimism.io/t/season-6-security-council-elections-cohort-a/8587/7about 2 years ago with 5.12M votesSecurity Council Elections: Cohort A LeadReason: As alisha.eth is the only candidate and already has an experience serving as the lead for the security council, we see no reason to vote against her nomination and are happy to ratify it.about 2 years ago with 5.03M votesCode of Conduct Council ElectionsReason: After reviewing all applications and assessing each nominee’s relevant experience, we decided to cast our vote for the following people:\nBubli.eth\nCryptoReuMD\nOxytocin\nPumbi\nfujiar - CitizenLoading...","tokens":2684,"squid":"ink-governance","role":"Council Listener","at":1791258623750,"hash":"b97064d29fec9afbba83efab72fcf1d0e83bad96"}
{"url":"https://docs.pyth.network/price-feeds/core/best-practices","domain":"docs.pyth.network","title":"Best Practices | Pyth Developer Hub","text":"Pyth CoreBest PracticesLearn how to integrate Pyth price feeds safely and effectivelyThis page provides some technical details about Pyth price feeds that are necessary to use them safely and correctly.\nPlease read this page before using Pyth price feeds in your application.\nPyth Core was upgraded on August 26, 2026We recommend new integrations use the upgraded contract addresses.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nFixed-Point Numeric Representation\nPrice feeds represent numbers in a fixed-point format. The same exponent is used for both the price and confidence interval. The integer representation of these values can be computed by multiplying by 10^exponent. As an example, imagine Pyth reported the following values for AAPL/USD:\nFieldValueexponent-5conf1500price12276250\nThe confidence interval is 1500 * 10^(-5) = $0.015, and the price is 12276250 * 10^(-5) = $122.7625.\nPrice Availability\nSometimes, Pyth will not be able to provide a current price for a product.\nThis situation can happen for various reasons.\nFor example, US equity markets only trade during certain hours, and outside those hours, it's not clear what an equity's price is.\nPyth price feeds follow the traditional market hours for each asset class. \nConsult Market Hours to know the market hours for each asset class.\nAlternatively, a network outage (at the internet level, blockchain level, or at multiple data providers) may prevent the protocol from producing new price updates.\n(Such outages are unlikely, but integrators should still be prepared for the possibility.)\nIn such cases, Pyth may return a stale price for the product.\nIntegrators should be careful to avoid accidentally using a stale price.\nThe Pyth SDKs guard against this failure mode by incorporating a staleness check by default.\nQuerying the current price will fail if too much time has elapsed since the last update.\nThe SDKs expose this failure condition in an idiomatic way: for example, the Rust SDK may return None, and the Solidity SDK may revert the transaction.\nThe SDK provides a sane default for the staleness threshold, but users may configure it to suit their use case.\nAdversarial selection\nPull updates give users of Pyth Network some ability to select which price to use in a transaction.\nThis ability is highly circumscribed by various constraints: on-chain prices must move forward in time and cannot be from too far in the past.\nHowever, users can still choose any price update that satisfies these constraints.\nThis ability is functionally equivalent to latency: it allows users to see the price in the future before using a price from the past.\nThe simplest way to guard against this attack vector is to incorporate a staleness check to ensure that the price used in a transaction is sufficiently recent.\nThe Pyth SDK provides the getPriceNoOlderThan() method to help users guard against this attack vector. This method returns the most recent price update that is not older than a specified threshold.\nHighly latency-sensitive protocols may wish to reduce the threshold to a few seconds to better suit their needs.\nPlease also see the section below on latency mitigations for additional ideas on how latency-sensitive protocols can minimize the impact of oracle latency.\nLatency\nDevelopers integrating Pyth Network price feeds should account for the difference in latency between on-chain oracles and off-chain sources (e.g. centralized exchanges).\nAlthough Pyth Network is designed with low latency in mind, no on-chain oracle can match the latency of an off-chain source due to the added overhead for consensus and security.\nThe threat model for integrating protocols should assume that adversaries see price changes a short time before the protocol does.\nIn this threat model, protocol designers should avoid situations where a Pyth price update must race against an adversary's transaction.\nAdversaries are highly likely to win these races, as they have a head start, and sophisticated adversaries can additionally optimize their network latencies or pay miners for priority blockspace.\nLatency Mitigations for Derivative Protocols1\nDerivative protocols are encouraged to consider the following strategies to mitigate the impact of oracle latency:\n\nUse Delayed Settlement: Derivative protocols can introduce a delay between the time an order is created and the time it is executed. This delay gives the protocol time to observe price changes and reject trades/transactions that profit over latency.\nSuppose a user submits a trade transaction at a time t. The protocol should execute the trade by using the price at the time t, which will be available to the protocol after a short delay.\nThe protocol can fetch this price update of a specific timestamp from Hermes and can use parsePriceFeedUpdates() to parse the prices and submit to prevent price frontrunning.\n\nUse a Spread: Pyth provides a confidence interval for each price update. Derivative protocols can use this confidence interval to determine the range in which the true price probably lies.\nBy using the lower bound of the confidence interval, derivative protocols can protect themselves from price manipulation that drives the price down. By using the upper bound of the confidence interval, derivative protocols can protect themselves from price manipulation that drives the price up.\n\nEnforce Position Holding: Derivative protocols can enforce hold times on positions to prevent users from exploiting oracle latency.\nFor example, a protocol could require users to hold an asset or a position for a certain period before they can trade or close it.\nThis hold time gives the protocol time to observe price changes and reject trades that profit over latency.\n\nExecutable Price Risks and Mitigations\nProtocols that offer executable prices should account for additional risks beyond the latency and staleness guidance described above.\nThese risks are particularly relevant for high-frequency derivative protocols, such as perps who offer or wants to offer instant fills.\nProtocols offering executable prices are encouraged to consider the following risks and mitigation strategies:\n\nSame-Block Exploitation: If your protocol allows positions to be opened and closed within the same block, stale or manipulated prices can be exploited using flash loans without inventory risk.\nAn attacker can open a position using a favorable stale price, then immediately close it in the same transaction, profiting from the price discrepancy.\nTo prevent this, separate the commitment to a trade from its execution.\nUse delayed settlement or commit-reveal schemes to ensure that positions cannot be opened and closed in the same block.\nEnforce a minimum holding period or require a certain number of blocks between entry and exit to prevent flash-loan round trips.\n\nStaleness in Executable Prices: Adversaries may see price updates before your protocol does, or they may select favorable historical price updates that satisfy staleness constraints.\nThis latency advantage allows sophisticated traders to exploit price differences.\nUse getPriceNoOlderThan() with strict staleness thresholds when filling orders.\nFor delayed execution models, fetch the price at the order timestamp from Hermes and parse it using parsePriceFeedUpdates().\n\nHigh Volatility and Wide Confidence Intervals: During periods of high volatility, large price moves widen confidence intervals and can cause significant slippage relative to your executable quote.\nThe executable price you quote may not reflect the true market price when confidence intervals are wide.\nDesign your pricing function to account for trade size and confidence intervals. Scale spreads and fees with notional size and confidence.\nDiscount prices toward the adverse side of the confidence interval when quoting executable prices.\nWhen the ratio of confidence to price exceeds a threshold, widen spreads or cap the maximum trade size.\n\nLiquidity and Price Impact: Executable prices effectively provide liquidity to traders.\nIf your pricing model treats price as size-agnostic and ignores external market depth, traders can systematically extract value by trading at sizes that would move the market price.\nImplement exposure limits to cap per-trade notional, per-block trading volume, and per-market open interest.\nIncrease taker and maker fees during stressed market conditions to compensate for increased risk.\n\nAvailability Gaps: Market hours or network outages can cause price feeds to freeze while trading remains active.\nIn such cases, your protocol may continue to offer executable prices based on stale data.\nRespect market hours and implement availability guardrails.\nIf price updates stall or confidence intervals widen beyond acceptable thresholds, pause new position openings or switch to conservative pricing instead of reusing stale executable prices.\n\nConfidence Intervals\nAt every point in time, Pyth publishes both a price and a confidence interval for each product. For example, Pyth may publish the current price of bitcoin as $50000 ± $10. Pyth publishes a confidence interval because, in real markets, there is no one single price for a product. For example, at any given time, bitcoin trades at different prices at different venues around the world. While these prices are typically similar, they can diverge for a number of reasons, such as when a cryptocurrency exchange blocks withdrawals on an asset. If this happens, prices diverge because arbitrageurs can no longer bring prices across exchanges into line. Alternatively, prices on different venues can differ simply because an asset is highly volatile at a particular point in time. At such times, bid/ask spreads tend to be wider, and trades on different markets at around the same time tend to occur at a wider range of prices.\nIn a Pyth feed, each publisher specifies an interval (p_i-c_i, p_i+c_i) in the form of their price and confidence submission. This interval is intended to achieve 95% coverage, i.e. the publisher expresses the belief that this interval contains the “true” price with 95% probability. The resulting aggregate interval (μ-σ, μ+σ), where μ represents the aggregate price and σ represents the aggregate confidence, is a good estimate of a range in which the true price lies.\nTo explain this, consider two cases of publisher estimates. In the first case, there is 100% overlap of all the publishers’ intervals, i.e. each publisher submits the same interval (p-c, p+c). In this case, the aggregate confidence interval is exactly that interval, so the aggregate confidence interval provides 100% coverage of the publishers’ intervals. This first case represents normal operating conditions, where most publishers agree about the price of an asset.\nIn the second case, each publisher specifies an interval that is disjoint from each of the other publishers’ intervals. In this case, the aggregate confidence interval can be seen to contain at least the 25th percentile and at least the 75th percentile of the set of points consisting of each of the publisher’s price, price plus confidence, and price plus confidence. As a result, the aggregate confidence interval is somewhat analogous to an interquartile range of the data, which is a reasonable measure of the spread of a set of points. Note that this is not an IQR of the prices alone of the publishers but rather of the set composed of the 3 points that each publisher submits. Moreover, note that the IQR does not include the most extreme publishers’ prices on either side; this property is necessary to ensure that a small group of publishers cannot manipulate the aggregate confidence interval. This second case represents an atypical scenario where publishers all disagree. Such circumstances are rare but can occur during market volatility or unusual events.\nThe aggregate confidence interval interpolates between the two cases above as publishers’ prices begin to diverge. In situations closer to case 1 where there is significant overlap of the individual publishers’ intervals, the aggregate interval (μ-σ, μ+σ) will capture most of the spread of the individual publishers. In the situation where the prices look more like case 2 with greater disjointness due to different views of the price across different venues, that aggregate interval may be in some eyes an imperfect measure of spread because there may be a number of individual price intervals that lie outside the aggregate interval. In this case, a protocol has a couple of options:\n\nIt can use a discounted price in the direction favorable to it. For example, a lending protocol valuing a user’s collateral can use the lower valuation price μ-σ. When valuing an outstanding loan position consisting of tokens a user has borrowed from the protocol, it can use the higher end of the interval by using the price μ+σ. This allows the protocol to be conservative with regard to its own health and safety when making valuations.\nIt can decide that there is too much uncertainty when σ/μ exceeds some threshold and choose to pause any new activity that depends on the price of this asset.\n\nTo expand upon the first option, it is recommended to use the confidence interval to protect your users from these unusual market conditions. The simplest way to do so is to use Pyth's confidence interval to compute a range in which the true price probably lies. This principle is common sense. Imagine that you are lending money to a friend, and your friend pledges a bitcoin as collateral. Also imagine that Pyth says the bitcoin price is $50000 +- $1000. (Note that $1000 is an unusually large confidence interval for bitcoin; the confidence interval is typically $50 dollars). You therefore calculate that the true price is between $49000 and $51000. When originating the loan, you would value the bitcoin at $49000. The lower price is conservative in this instance because it limits the amount of borrowing that is possible while the price is uncertain. On the other hand, if you were to issue a loan of bitcoin, you would value the borrowed bitcoin at $51000. The higher price is conservative, as it protects you from allowing someone to borrow in excess during times of increased volatility.\nThe same principle would apply if you wrote a derivative contract. If someone wants to open a derivative contract with you, you would value their collateral at the lower price. However, if you were deciding whether someone's margin limits were violated, you could value their outstanding leveraged position at the higher price. If a contract needs to be settled at a price, you could take approaches such as the following:\n\nUsing Pyth's exponential moving average price, which represents estimates of the average price of the asset over a specified time period (e.g., over the past 1 hour). The exponential moving average price is computed such that it lessens the influence of prices with wide confidence intervals. You may find more details in Understanding Price Data.\nUsing the aggregate price, which is Pyth's best estimate of the price at a single point in time. The quality of this estimate depends on the width of the confidence interval at settlement time and on occasion, it may be imprecise. However, it is the best you can do with Pyth data if you need a single price at that exact point in time.\nDefining the contract to depend on confidence. For example, you could create an option that refunds the option premium to the buyer (so both sides of the transaction are even) if the strike price is within the confidence interval at settlement time. You could also create a contract that delayed settlement until the confidence interval was sufficiently small. If you choose this second option, you should ensure that your contract is guaranteed to eventually settle even if the confidence interval never narrows.\n\nPricing Futures-Based Assets\nFor assets like commodities, interest rates, and even volatility indices, pricing is primarily derived from futures contracts. These contracts form a series of prices for different delivery dates, collectively known as the futures curve. While the front-month contract is the most actively traded and often seen as the benchmark, it doesn't represent the current price of the asset but rather a proxy of the near-term price of the asset at the time of delivery.\nThis reliance on futures, in the absence of a native spot price, means that market expectations, logistical constraints, amongst other factors can heavily influence the front-month price.\nFor example, in times of extreme market stress, the front-month contract turn negative when traders avoid delivery, distorting its usefulness as a representative market signal. This happened in the case of the 2020 oil crash, where the front-month price of WTI Crude oil turned negative due to a lack of storage capacity, making applications that rely exclusively on the front-month price unreliable.\nThus it is important that each contract should have a weighted stratergy based on the their expiration dates. As the front month approaches expiry, least weight should be allocated on this contract and the weights of the other contracts are determined proportionally. A daily re-adjusted strategy should be applied by the end user of the price feeds.\n\nFootnotes\n\nThe strategies and methodologies outlined in this page, including those addressing price latency mitigation, are provided solely for informational purposes and might not fully eliminate the discussed problems. Do your own research before using them. \nRefer to Terms of Use for more information. ↩\n\non SuiList of Push Feeds on SuiError CodesReference error codes for Pyth price feeds","tokens":4433,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258639876,"hash":"3b71d1a560853efb92622e4965d3e8dc5e1254f9"}
{"url":"https://ethresear.ch/t/proposal-add-a-new-category-for-philosophy/10756","domain":"ethresear.ch","title":"Proposal: Add a new category for 'Philosophy' - Administrivia - Ethereum Research","text":"Proposal: Add a new category for ‘Philosophy’ \n\n Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2021\n\n 1 / 7\n\n Sep 2021\n\n Dec 2021\n\n post by SHSR2001 on Sep 16, 2021\n\n SHSR2001\n\n As we all know quite well, Ethereum is more than just a technology stack. It is a whole new paradigm of thought, and cultivating the Ethereum Community is to bring together like-minded people whole values align with that of the collective Ethereum community.\nIt would thus be relevant to explore questions and spark discussions on these values which are deeply embedded in the crypto and more specifically the Ethereum space, so that newcomers and long standing experts alike can explore this ‘infinite garden’ to greater depths.\n\n post by samueldashadrach on Sep 16, 2021\n\n samueldashadrach\n\n Governance section go brrr\nWill this section allow questions regarding governance of ethereum? Both technical questions (example: what gaslimit to set) as well as questions of soft power (example: who gets to pick the gaslimit).\n\n post by hwwhww on Sep 16, 2021\n\n hwwhww\n\n Although I agreed that Ethereum is more than a technology stack, it’s important for Ethresear.ch to stay being a technology-focused forum with minimal distractions.\nI believe it’s more appropriate to discuss philosophy and governance topics on the Ethereum Magicians forum or r/ethereum.\n\n post by Biu on Sep 16, 2021\n\n Biu\n\n Not just ethereum, we should say that blockchain is a model for thinking and collaborative building. When developing any blockchain product, it actually has great differences from internet products. Agree with adding additional discussion section to form a unique design atmosphere for blockchain developers.\n\n post by angyts on Sep 19, 2021\n\n angyts\n\n Totally agree.\nThere’s anthropology, culture, game theory, spirituality and history. All of which is important to understand to really understand the blockchain.\n\n 1 month later\n\n post by x on Oct 22, 2021\n\n x\n\n I like this. This would be a good place to discuss the meta mission and priorities of Ethereum and blockchain in general.\nI find it stunning how often big agendas are pushed in this world without people ever taking the time to agree what they are trying to achieve with it. This is dangerous, people can wrongly assume that other members of society have a shared understanding, which then causes unexpected friction later. Or people do random stuff that “sounds good” without reflecting on the Why.\nSomewhat controversial example, but let’s take climate change. The accepted opinion is that ESG is great and that climate change needs to be avoided/stopped at all cost. I don’t disagree, but I also don’t agree. I just can’t know.\nWhy? I don’t see that our world leaders have ever taken the time to discuss the more important, bigger picture questions like “where do we actually want to be as a race in XXXX years from now?”. How can we have decided that climate change is bad if we have never discussed what we are trying to achieve? How much we want to grow? If we even want to stay on this planet? Etc.\nThe thinking stops before enough steps have been made and it can lead us in the wrong direction.\nAnyway, just a random example.\n\n 1 month later\n\n post by SentientFlesh on Dec 2, 2021\n\n SentientFlesh\n\n hwwhww\n\n Agreed, there’s’ other outlets for the Philosohical discussions of blockchain, how future power struggles will play out as scarcity increases and countries and individuals are late to the game, as well as where lines in the same will be drawn both socially. Definitely a topic for a more meta thread.\n\n Powered by Discourse","tokens":902,"squid":"ink-research","role":"Deep Scholar","at":1791258650184,"hash":"e4da2b29e918f348f86fe56237a708be7e5514b3"}
{"url":"https://docs.pyth.network/price-feeds/core/how-pyth-works","domain":"docs.pyth.network","title":"How Pyth Works | Pyth Developer Hub","text":"Pyth CoreHow Pyth WorksPythnet is shutting down; Pyth Pro documents the current architecturePyth Core's original architecture was built on Pythnet, an application-specific\nblockchain that aggregated publisher prices and relayed them cross-chain. Pythnet is\nbeing shut down as part of the Pyth Core sunset, and the\npages describing it — the oracle program, price aggregation, cross-chain relaying, and\nthe Pythnet account reference — have been retired along with it.\nPyth Pro is where the current architecture is documented:\n\nHow Pyth Pro Works covers how prices are\npublished, aggregated, and delivered today.\nUnderstanding Price Data explains the\naggregate price, the confidence interval, and the EMA.\nWhy Update PricesUnderstand why Pyth pull-oracle integrations must refresh on-chain pricesPyth ProExplore Pyth Pro's enterprise-grade, customizable price data offering","tokens":218,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258662086,"hash":"f3d0b9fb0e78582ac136fbfeef3ec9a874d4be3e"}
{"url":"https://docs.arbitrum.io/for-devs/contribute","domain":"docs.arbitrum.io","title":"Contribute docs | Arbitrum Docs","text":"✏️Request an updateThank you for considering to contribute to the Arbitrum documentation! We're excited to have you on board.\nThe docs.arbitrum.io docs portal is the single source of truth for documentation that supports Offchain Labs' product portfolio. Contributions are welcome from the entire Ethereum community.\nThis document shows you how to craft and publish Arbitrum documentation. Familiarity with Markdown syntax, Github, and Docusaurus is expected.\nAdd a new core document​\nIf a document isn't in a Third-party content sidebar node, it's a core document. To contribute a new core doc:\n\nBegin by creating a branch (internal) or fork (external) of the Arbitrum docs repo.\nIssue a Draft pull request into master. Pull requests into master generate a preview of your changes via a PR-specific Docusaurus deployment; this preview will update as you push commits to your remote.\nInclude answers to the following questions in your PR description:\n\nAudience: Who am I writing for?\nProblem: What specific problem are they trying to solve?\nDiscovery: How are they looking for a solution to this problem? What search terms are they using?\nDocument type: Which document type is most suitable?\nPolicy acknowledgment (Third-party docs only): Do you agree to the third-party content policy outlined within \"Contribute docs\"?\n\nAs you craft your contribution, refer to the document types, Style guidance, and other conventions below.\nMark your PR as Open when it's ready for review.\n\nAdd a new third-party document​\nThird-party docs are documents that help readers of Arbitrum docs use other products, services, and protocols (like the ones listed in the Arbitrum portal) with Arbitrum products.\nSee Contribute third-party docs for detailed instructions.\nRequest an update​\nIf you'd like to request an update or share a suggestion related to an existing document without submitting a pull request to implement the improvement yourself, click the Request an update button located at the top of each published document. This button will lead you to a prefilled Github issue that you can use to elaborate on your request or suggestion.\nAdd a new translation page​\nIf you would like to participate in translating the Arbitrum docs, you can:\n\nCheck whether i18n has a corresponding language (currently there are ja and zh). If not, you can use the following command to add it (we take adding French as an example):\n\nnpm run write-translations -- --locale fr\nIt will help generate folder i18n/fr.\n\nCreate the folders current and translated under the newly generated folder i18n/fr/docusaurus-plugin-content-docs:\n\nmkdir i18n/{Your_language}/docusaurus-plugin-content-docs/current && mkdir i18n/{Your_language}/docusaurus-plugin-content-docs/translated\n\nTranslate one of more docs files located in docs/.\n\nPlace the translated document into the folder i18n/{Your_language}/docusaurus-plugin-content-docs/translated according to its relative path in arbitrum-docs. For example, if you translated /arbitrum-docs/how-arbitrum-works/arbos/introduction.md, then its path in i18n should be i18n/{Your_language}/docusaurus-plugin-content-docs/translated/how-arbitrum-works/arbos/introduction.md.\n\nTest run:\n\nCheck that the i18n settings in docusaurus.config.js have included your new language:\n\ni18n: { defaultLocale: 'en', // locales: ['en', 'ja', 'zh'], locales: ['en'], // You can add your new language to this array },\n\nCheck whether the locale Dropdown component exists in navbar, if not, add it:\n\nnavbar: { title: 'Arbitrum Docs', logo: { alt: 'My Site Logo', src: 'img/logo.svg', href: '/get-started/arbitrum-introduction', }, items: [ // note: we can uncomment this when we want to display the locale dropdown in the top navbar // if we enable this now, the dropdown will appear above every document; if `ja` is selected for a document that isn't yet translated, it will 404 // there may be a way to show the dropdown only on pages that have been translated, but that's out of scope for the initial version { type: 'localeDropdown', position: 'right', } ],},\n\nBuild translation and docs:\n\nyarn build-translation && yarn build\n\nStart docs:\n\nnpm run serve\nDocument type conventions​\nEvery document should be a specific type of document. Each type of document has its own purpose:\nDocument typePurposeGentle introductionOnboard a specific reader audience with tailored questions and answersQuickstartOnboard a specific reader audience with step-by-step \"learn by doing\" instructionsHow-toProvide task-oriented procedural guidanceConceptExplain what things are and how they workFAQAddress frequently asked questionsTroubleshootingList common troubleshooting scenarios and solutionsReferenceLists and tables of things, such as API endpoints and developer resources\nThis isn't an exhaustive list, but it includes most of the document types that we use.\nAbout Promotional ContentWhile it is acceptable to include conceptual and how-to content that links to products, services, and protocols in the third party section, we do not accept promotional content in our core docs.\nFeature pieces that are primarily promotional and do not provide actionable guidance to readers are not accepted as third-party docs, either.\nStyle conventions​\nThe following style guidelines provide a number of loose recommendations that help us deliver a consistent content experience across our docs:\n1. Casing​\nSentence-case \"content labels\": document titles, sidebar titles, menu items, section headers, etc.\n2. Linking​\nAvoid anchoring links to words like \"here\" or \"this\". Descriptive anchor text can help set expectations for readers who may hesitate to click on ambiguous links. When linking to docs, try to link to the document's title verbatim.\n3. Titling​\nTitles should balance brevity with precision—Node running overview is preferred to Overview. This helps with SEO and reader UX.\n4. Separate procedural from conceptual (most of the time)​\nWithin procedural docs like how-tos and quickstarts, avoid including too much conceptual content. Provide only the conceptual information that the target reader needs in order to complete the task at hand. Otherwise, organize conceptual information within conceptual docs, and link to them \"just in case\" from other docs.\n5. Voice​\n\nAddress the reader as \"you\".\nWrite like you'd speak to a really smart friend who's in a rush.\nOpt for short, clear sentences that use translation-friendly, plain language.\nUse contractions wherever it feels natural—this can help convey a friendly and conversational tone.\n\n6. Formality​\n\nDon't worry too much about formality. The most valuable writing is writing that provides value to readers, and readers generally want to \"flow\" through guidance.\nAim at \"informal professionalism\" that prioritizes audience-tailored problem-solving and consistent style and structure.\n\n7. Targeting​\n\nDon't try to write for everyone; write for a specific reader persona (also referred to as \"audience\" in this document) who has a specific need.\nMake assumptions about prior knowledge (or lack thereof) and make these assumptions explicit in the beginning of your document.\n\n8. Flow​\n\nSet expectations: Begin documents by setting expectations. Who is the document for? What value will it provide to your target audience? What assumptions are you making about their prior knowledge? Are there any prerequisites?\nValue up front: Lead with what matters most to the reader persona you're targeting. Then, progressively build a bridge that carries them towards task completion as efficiently as possible.\n\n9. Cross-linking​\nWe want to maintain both high discoverability and high relevance. As a general rule of thumb, links to other docs should be \"very likely to be useful for most readers\". Every link is a subtle call to action; we want to avoid CTA overload.\n10. Things to avoid​\n\nSymbols where words will do: Minimize usage of & and /—spell out words like \"and\" and \"or\".\nJargon: Using precise technical terminology is ok, as long as your target audience is likely to understand the terminology. When in doubt, opt for clear, unambiguous, accessible language.\n\nDon't stress too much about checking off all of these boxes; we periodically review and edit our most heavily-trafficked docs, bringing them up to spec with the latest style guidelines.\nSome important disclaimers:\n\nThis isn't an exhaustive list. These are just the min-bar guidelines that will be applied to all new content moving forward.\nMany of our docs don't yet follow this guidance. Our team is working on it! If you notice an obvious content bug, feel free to submit an issue or PR.\n\nBanner conventions​\nYou can use banners (Docusaurus refers to them as \"admonitions\") to set expectations for your readers and to emphasize important callouts. Use these conservatively, as they interrupt the flow of the document.\nUnder construction banner​\nExample:\nUNDER CONSTRUCTIONThe following steps are under construction and will be updated with more detailed guidance soon. Stay tuned, and don't hesitate to click the Request an update at the top of this document if you have any feedback along the way.\nUsage:\n:::caution[UNDER CONSTRUCTION]The following steps are under construction and will be updated with more detailed guidance soon. Stay tuned, and don't hesitate to click the **Request an update** at the top of this document if you have any feedback along the way.:::\nCommunity member contribution banner​\nExample:\nCommunity member contributionThe following document was contributed by @todo-twitter-handle. Give them a shoutout if you find it useful!\nUsage:\n:::info[Community member contribution]The following document was contributed by @todo-twitter-handle. Give them a shoutout if you find it useful!:::\nFrequently asked questions​\nCan I point to my product from core docs? For example—if my product hosts a public RPC endpoint, can I add it to your RPC endpoints and providers page?​\nThese types of contributions are generally not merged unless they're submitted by employees of Offchain Labs.\nInstead of opening a PR for this type of contribution, click the Request an update button at the top of the published document to create an issue. Generally, third-party services are included in core docs only if we can confidently assert that the services are \"trustworthy, highly relevant to the core document at hand, and battle-tested by Arbitrum developers\" under a reasonable scrutiny.\nHow long does it take for my third-party content contribution to be reviewed?​\nOur team is continuously balancing competing priorities, so we can't guarantee a specific turnaround time for third-party docs PRs. They're processed in the order in which they're received, generally within a week or two.\nIs there any way to expedite third-party content contribution reviews?​\nThe most effective way to expedite processing is to ensure that your PR incorporates the conventions outlined in this document. Please don't ask for status updates—if you've submitted a PR, it's on our radar!Add a new core documentAdd a new third-party documentRequest an updateAdd a new translation pageDocument type conventionsStyle conventionsBanner conventionsFrequently asked questions","tokens":2787,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258662117,"hash":"00e4ba4664f8c1bb66a25a322417d19e6c3aa1c6"}
{"url":"https://docs.pyth.network/price-feeds/core/why-update-prices","domain":"docs.pyth.network","title":"Why Update Prices | Pyth Developer Hub","text":"Pyth CoreWhy Update PricesUnderstand why Pyth pull-oracle integrations must refresh on-chain pricesPyth uses a pull oracle model. Unlike traditional push oracles that automatically update prices on-chain at regular intervals, Pyth requires users to explicitly update the on-chain price before reading it.\nThis design offers several advantages:\n\nLower costs: You only pay for price updates when you need them\nLower latency: You can fetch the latest price update directly from Pyth's low-latency oracle network and submit it on-chain immediately\nFlexibility: Different applications can update prices at different frequencies based on their needs\n\nIn the pull integration pattern, your contract must:\n\nAccept priceUpdate data from the caller (fetched from Hermes)\nCall updatePriceFeeds() to submit this data on-chain before reading prices\nPay a small fee for each update (calculated via getUpdateFee())\n\nIf you don't update the price or if the on-chain price becomes too stale, calls to getPriceNoOlderThan() will revert with a StalePrice error. See how to fetch price updates for more details on obtaining price updates.What is a Pull Oracle?Learn how Pyth's pull oracle model differs from traditional push oraclesHow Pyth WorksPythnet is shutting down; Pyth Pro documents the current architecture","tokens":324,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258671848,"hash":"2777e0b352f5a461954c35b51066b146e3ec31df"}
{"url":"https://ethresear.ch/t/proposal-add-a-new-category-for-philosophy/10756/8","domain":"ethresear.ch","title":"Proposal: Add a new category for 'Philosophy' - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2021\n\n 5 / 7\n\n Sep 2021\n\n Dec 2021\n\n post by SHSR2001 on Sep 16, 2021\n\n SHSR2001\n\n As we all know quite well, Ethereum is more than just a technology stack. It is a whole new paradigm of thought, and cultivating the Ethereum Community is to bring together like-minded people whole values align with that of the collective Ethereum community.\nIt would thus be relevant to explore questions and spark discussions on these values which are deeply embedded in the crypto and more specifically the Ethereum space, so that newcomers and long standing experts alike can explore this ‘infinite garden’ to greater depths.\n\n post by samueldashadrach on Sep 16, 2021\n\n samueldashadrach\n\n Governance section go brrr\nWill this section allow questions regarding governance of ethereum? Both technical questions (example: what gaslimit to set) as well as questions of soft power (example: who gets to pick the gaslimit).\n\n post by hwwhww on Sep 16, 2021\n\n hwwhww\n\n Although I agreed that Ethereum is more than a technology stack, it’s important for Ethresear.ch to stay being a technology-focused forum with minimal distractions.\nI believe it’s more appropriate to discuss philosophy and governance topics on the Ethereum Magicians forum or r/ethereum.\n\n post by Biu on Sep 16, 2021\n\n Biu\n\n Not just ethereum, we should say that blockchain is a model for thinking and collaborative building. When developing any blockchain product, it actually has great differences from internet products. Agree with adding additional discussion section to form a unique design atmosphere for blockchain developers.\n\n post by angyts on Sep 19, 2021\n\n angyts\n\n Totally agree.\nThere’s anthropology, culture, game theory, spirituality and history. All of which is important to understand to really understand the blockchain.\n\n 1 month later\n\n post by x on Oct 22, 2021\n\n x\n\n I like this. This would be a good place to discuss the meta mission and priorities of Ethereum and blockchain in general.\nI find it stunning how often big agendas are pushed in this world without people ever taking the time to agree what they are trying to achieve with it. This is dangerous, people can wrongly assume that other members of society have a shared understanding, which then causes unexpected friction later. Or people do random stuff that “sounds good” without reflecting on the Why.\nSomewhat controversial example, but let’s take climate change. The accepted opinion is that ESG is great and that climate change needs to be avoided/stopped at all cost. I don’t disagree, but I also don’t agree. I just can’t know.\nWhy? I don’t see that our world leaders have ever taken the time to discuss the more important, bigger picture questions like “where do we actually want to be as a race in XXXX years from now?”. How can we have decided that climate change is bad if we have never discussed what we are trying to achieve? How much we want to grow? If we even want to stay on this planet? Etc.\nThe thinking stops before enough steps have been made and it can lead us in the wrong direction.\nAnyway, just a random example.\n\n 1 month later\n\n post by SentientFlesh on Dec 2, 2021\n\n SentientFlesh\n\n hwwhww\n\n Agreed, there’s’ other outlets for the Philosohical discussions of blockchain, how future power struggles will play out as scarcity increases and countries and individuals are late to the game, as well as where lines in the same will be drawn both socially. Definitely a topic for a more meta thread.\n\n Powered by Discourse","tokens":890,"squid":"ink-research","role":"Deep Scholar","at":1791258674025,"hash":"e36e16fd8faa00fefd5be94a2bfc2b6daa3e5340"}
{"url":"https://portal.arbitrum.io/earn","domain":"portal.arbitrum.io","title":"Earn yield on Arbitrum | Lending, Liquid Staking & Fixed Yield","text":"EarnEarnAave v3 WBTCLendingFeaturedAPY0.02%USDaiFixed YieldFeaturedAPY11.38%Liquid Staked ETHLiquid StakingFeaturedAPY2.27%LendingSupply assets like WETH, USDC, and WBTC on Arbitrum lending markets to earn variable yield.Aave v3 WBTCWBTCarbitrum0.02%APYTVL$258.8M USDProtocolaaveProjected Earnings-Your Holdings-Aave v3 WETHWETHarbitrum1.08%APYTVL$256.4M USDProtocolaaveProjected Earnings-Your Holdings-Aave v3 USDCUSDCarbitrum3.15%APYTVL$182.2M USDProtocolaaveProjected Earnings-Your Holdings-NameTokenProtocolAave v3 WBTCWBTCArbitrum One0.02%--$258.8M USDaaveAave v3 WETHWETHArbitrum One1.08%--$256.4M USDaaveAave v3 USDCUSDCArbitrum One3.15%--$182.2M USDaaveFixed YieldAccess fixed-rate opportunities on Arbitrum through Pendle markets with a clear maturity date.USDaiUSDaiArbitrum11.38%APYTVL$92M USDProtocolPendleProjected Earnings-Your Holdings-sUSDaisUSDaiArbitrum12.78%APYTVL$63.8M USDProtocolPendleProjected Earnings-Your Holdings-sUSDaisUSDaiArbitrum10.29%APYTVL$7.1M USDProtocolPendleProjected Earnings-Your Holdings-NameTokenProtocolUSDai14 Oct 2026USDaiArbitrum One11.38%--$92M USDPendlesUSDai14 Oct 2026sUSDaiArbitrum One12.78%--$63.8M USDPendlesUSDai24 Feb 2027sUSDaiArbitrum One10.29%--$7.1M USDPendleLiquid StakingSwap for liquid staked ETH on Arbitrum and receive liquid staking tokens like weETH or wstETH while keeping your assets liquid.Liquid Staked ETHwstETHArbitrum One2.27%APYTVL$26.7B USDProtocolLidoProjected Earnings-Your Holdings-Liquid Staked ETHweETHArbitrum One2.33%APYTVL$6.2B USDProtocolEther.fiProjected Earnings-Your Holdings-NameTokenProtocolLiquid Staked ETHwstETHArbitrum One2.27%--$26.7B USDLidoLiquid Staked ETHweETHArbitrum One2.33%--$6.2B USDEther.fi","tokens":423,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258684296,"hash":"51dcdca93dd2bd7aea47edc0a571fe96fc3a2456"}
{"url":"https://ethresear.ch/t/proposal-add-a-new-category-for-philosophy/10756/5","domain":"ethresear.ch","title":"Proposal: Add a new category for 'Philosophy' - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2021\n\n 3 / 7\n\n Sep 2021\n\n Dec 2021\n\n post by SHSR2001 on Sep 16, 2021\n\n SHSR2001\n\n As we all know quite well, Ethereum is more than just a technology stack. It is a whole new paradigm of thought, and cultivating the Ethereum Community is to bring together like-minded people whole values align with that of the collective Ethereum community.\nIt would thus be relevant to explore questions and spark discussions on these values which are deeply embedded in the crypto and more specifically the Ethereum space, so that newcomers and long standing experts alike can explore this ‘infinite garden’ to greater depths.\n\n post by samueldashadrach on Sep 16, 2021\n\n samueldashadrach\n\n Governance section go brrr\nWill this section allow questions regarding governance of ethereum? Both technical questions (example: what gaslimit to set) as well as questions of soft power (example: who gets to pick the gaslimit).\n\n post by hwwhww on Sep 16, 2021\n\n hwwhww\n\n Although I agreed that Ethereum is more than a technology stack, it’s important for Ethresear.ch to stay being a technology-focused forum with minimal distractions.\nI believe it’s more appropriate to discuss philosophy and governance topics on the Ethereum Magicians forum or r/ethereum.\n\n post by Biu on Sep 16, 2021\n\n Biu\n\n Not just ethereum, we should say that blockchain is a model for thinking and collaborative building. When developing any blockchain product, it actually has great differences from internet products. Agree with adding additional discussion section to form a unique design atmosphere for blockchain developers.\n\n post by angyts on Sep 19, 2021\n\n angyts\n\n Totally agree.\nThere’s anthropology, culture, game theory, spirituality and history. All of which is important to understand to really understand the blockchain.\n\n 1 month later\n\n post by x on Oct 22, 2021\n\n x\n\n I like this. This would be a good place to discuss the meta mission and priorities of Ethereum and blockchain in general.\nI find it stunning how often big agendas are pushed in this world without people ever taking the time to agree what they are trying to achieve with it. This is dangerous, people can wrongly assume that other members of society have a shared understanding, which then causes unexpected friction later. Or people do random stuff that “sounds good” without reflecting on the Why.\nSomewhat controversial example, but let’s take climate change. The accepted opinion is that ESG is great and that climate change needs to be avoided/stopped at all cost. I don’t disagree, but I also don’t agree. I just can’t know.\nWhy? I don’t see that our world leaders have ever taken the time to discuss the more important, bigger picture questions like “where do we actually want to be as a race in XXXX years from now?”. How can we have decided that climate change is bad if we have never discussed what we are trying to achieve? How much we want to grow? If we even want to stay on this planet? Etc.\nThe thinking stops before enough steps have been made and it can lead us in the wrong direction.\nAnyway, just a random example.\n\n 1 month later\n\n post by SentientFlesh on Dec 2, 2021\n\n SentientFlesh\n\n hwwhww\n\n Agreed, there’s’ other outlets for the Philosohical discussions of blockchain, how future power struggles will play out as scarcity increases and countries and individuals are late to the game, as well as where lines in the same will be drawn both socially. Definitely a topic for a more meta thread.\n\n Powered by Discourse","tokens":890,"squid":"ink-research","role":"Deep Scholar","at":1791258697600,"hash":"ce9880758f2295969d11d2dccffbf0b58f255209"}
{"url":"https://www.anchor-lang.com/docs/references/verifiable-builds","domain":"anchor-lang.com","title":"Verifiable Builds","text":"Program DevelopmentVerifiable BuildsAnchor - Verifiable BuildsBuilding programs with the Solana CLI may embed machine specific code into the\nresulting binary. As a result, building the same program on different machines\nmay produce different executables. To get around this problem, one can build\ninside a docker image with pinned dependencies to produce a verifiable build.\n\nAnchor makes this easy by providing CLI commands to build and take care of\ndocker for you. To get started, first make sure you\ninstall docker on your local machine.\nBuilding\nTo produce a verifiable build, run\nanchor build --verifiable\nVerifying\nTo verify a build against a program deployed on mainnet, run\nanchor verify -p <lib-name> <program-id>\nwhere the <lib-name> is defined by your program's Cargo.toml.\nIf the program has an IDL, it will also check the IDL deployed on chain matches.\nImages\nA docker image for each version of Anchor is published on\nQuay.io. They are tagged\nin the form quay.io/ottersec/anchor:<version>. For example, to get the image\nfor Anchor v1.2.0 one can run\ndocker pull quay.io/ottersec/anchor:v1.2.0\nRemoving an Image\nIn the event you run a verifiable build from the CLI and exit prematurely, it's\npossible the docker image may still be building in the background.\nTo remove, run\ndocker rm -f anchor-program\nwhere anchor-program is the name of the image created by default from within\nthe Anchor CLI.PreviousRust to JS Type ConversionNextSealevel AttacksOn this pageBuildingVerifyingImagesRemoving an ImageEdit on GitHub","tokens":382,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258697645,"hash":"850555dc7b1e0f4dfba5fe7abd0cdcfdd2595c4b"}
{"url":"https://www.anchor-lang.com/docs/references/security-exploits","domain":"anchor-lang.com","title":"Sealevel Attacks","text":"Program DevelopmentSealevel AttacksAnchor - Sealevel AttacksAnchor uses a lot of magic to help eliminate footguns, but if you're shipping\nanything to mainnet, it's important you understand every bit of that magic and\nthe motivation behind it. A list of common attacks can be found\nhere, providing three different\nexamples for each example attack\n\ninsecure - represents flawed code that may be insecure\nsecure - represents a fix\nrecommended - represents a fix with idiomatic Anchor code\n\nNote that none of these examples are not necessarily secure, but they are meant\nto showcase a specific issue and a recommended fix in isolation.PreviousVerifiable BuildsNextExample ProgramsOn this pageNo HeadingsEdit on GitHub","tokens":178,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258707957,"hash":"f5c69d33299f2537ea5443340e78edc7fb4e0d2a"}
{"url":"https://ethresear.ch/t/proposal-add-a-new-category-for-philosophy/10756/11","domain":"ethresear.ch","title":"Proposal: Add a new category for 'Philosophy' - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2021\n\n 7 / 7\n\n Dec 2021\n\n Dec 2021\n\n post by SHSR2001 on Sep 16, 2021\n\n SHSR2001\n\n As we all know quite well, Ethereum is more than just a technology stack. It is a whole new paradigm of thought, and cultivating the Ethereum Community is to bring together like-minded people whole values align with that of the collective Ethereum community.\nIt would thus be relevant to explore questions and spark discussions on these values which are deeply embedded in the crypto and more specifically the Ethereum space, so that newcomers and long standing experts alike can explore this ‘infinite garden’ to greater depths.\n\n post by samueldashadrach on Sep 16, 2021\n\n samueldashadrach\n\n Governance section go brrr\nWill this section allow questions regarding governance of ethereum? Both technical questions (example: what gaslimit to set) as well as questions of soft power (example: who gets to pick the gaslimit).\n\n post by hwwhww on Sep 16, 2021\n\n hwwhww\n\n Although I agreed that Ethereum is more than a technology stack, it’s important for Ethresear.ch to stay being a technology-focused forum with minimal distractions.\nI believe it’s more appropriate to discuss philosophy and governance topics on the Ethereum Magicians forum or r/ethereum.\n\n post by Biu on Sep 16, 2021\n\n Biu\n\n Not just ethereum, we should say that blockchain is a model for thinking and collaborative building. When developing any blockchain product, it actually has great differences from internet products. Agree with adding additional discussion section to form a unique design atmosphere for blockchain developers.\n\n post by angyts on Sep 19, 2021\n\n angyts\n\n Totally agree.\nThere’s anthropology, culture, game theory, spirituality and history. All of which is important to understand to really understand the blockchain.\n\n 1 month later\n\n post by x on Oct 22, 2021\n\n x\n\n I like this. This would be a good place to discuss the meta mission and priorities of Ethereum and blockchain in general.\nI find it stunning how often big agendas are pushed in this world without people ever taking the time to agree what they are trying to achieve with it. This is dangerous, people can wrongly assume that other members of society have a shared understanding, which then causes unexpected friction later. Or people do random stuff that “sounds good” without reflecting on the Why.\nSomewhat controversial example, but let’s take climate change. The accepted opinion is that ESG is great and that climate change needs to be avoided/stopped at all cost. I don’t disagree, but I also don’t agree. I just can’t know.\nWhy? I don’t see that our world leaders have ever taken the time to discuss the more important, bigger picture questions like “where do we actually want to be as a race in XXXX years from now?”. How can we have decided that climate change is bad if we have never discussed what we are trying to achieve? How much we want to grow? If we even want to stay on this planet? Etc.\nThe thinking stops before enough steps have been made and it can lead us in the wrong direction.\nAnyway, just a random example.\n\n 1 month later\n\n post by SentientFlesh on Dec 2, 2021\n\n SentientFlesh\n\n hwwhww\n\n Agreed, there’s’ other outlets for the Philosohical discussions of blockchain, how future power struggles will play out as scarcity increases and countries and individuals are late to the game, as well as where lines in the same will be drawn both socially. Definitely a topic for a more meta thread.\n\n Powered by Discourse","tokens":890,"squid":"ink-research","role":"Deep Scholar","at":1791258709057,"hash":"e8959c0e042b13b8450e99a4881e86b406eded56"}
{"url":"https://www.anchor-lang.com/docs/references/examples","domain":"anchor-lang.com","title":"Example Programs","text":"Program DevelopmentExample ProgramsExample Anchor programs referencesThere are extensive examples for individual Anchor features on the Solana Foundation Program Examples repo.\nAdditionally, the Quicknode Solana Program Examples repo includes Anchor examples of larger programs, like order books, loan markets, betting markets, and so on. The current Anchor stack, including Anchor 1.x, the multiple files layout, and LiteSVM for tests is used throughout.\nBasics\nExampleDescriptionchecking-accountsChecking account example with Anchorclose-accountClose account example with AnchorcounterCounter program using Anchorcreate-accountCreate accounts with Anchorcross-program-invocationCross program invocation with AnchorfavoritesStore user \"favorites\" with Anchorhello-solanaBasic \"Hello, Solana!\" program with Anchorpda-rent-payerPDA rent payer example with Anchorprocessing-instructionsProcess instructions using Anchorprogram-derived-addressesProgram-derived addresses with AnchorreallocReallocate account data with AnchorrentCalculate account SOL rent with Anchortransfer-solTransfer SOL tokens with Anchor\nTokens\nExampleDescriptioncreate-tokenCreate an SPL token with AnchorescrowEscrow program using Anchornft-minterMint NFTs using Anchornft-operationsNFT operations with Anchorpda-mint-authorityPDA as mint authority with Anchorspl-token-minterSPL token minting with Anchortoken-fundraiserToken fundraiser using Anchortoken-swapSwap tokens with Anchortransfer-tokensTransfer SPL tokens using Anchor\nToken Extensions\nExampleDescriptionbasicsBasics of Token 2022 with Anchorcpi-guardCPI guard example with Anchordefault-account-stateDefault account state setup with AnchorgroupToken grouping example with Anchorimmutable-ownerImmutable owner setup with Anchorinterest-bearingInterest-bearing tokens using Anchormemo-transferMemo transfer with AnchormetadataToken metadata with Anchormint-close-authorityMint close authority with Anchormultiple-extensionsMultiple extensions example with Anchornft-meta-data-pointerNFT metadata pointer with Anchornon-transferableNon-transferable tokens using Anchorpermanent-delegatePermanent delegate setup with Anchortransfer-feeTransfer fees example with Anchortransfer-hookTransfer hook example with AnchorPreviousSealevel AttacksNext1.2.0On this pageBasicsTokensToken ExtensionsEdit on GitHub","tokens":583,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258717420,"hash":"ef4c5f97539d8fb10059157a539a5f6bbaa2f439"}
{"url":"https://arbitrum.io/","domain":"arbitrum.io","title":"Arbitrum - Powering the programmable economy","text":"Powering the programmable economyArbitrum is the finance-native blockchain platform providing infrastructure for applications, tokenization, and dedicated blockchain environments.Bring finance onchainBecome a partnerWhere FinanceMoves Onchain, at ScaleArbitrum is your enterprise-grade infrastructure for global finance. See how liquidity, world-class developer talent, and Ethereum’s security can drive impact for your company.Learn about Arbitrum FinanceWhere Big IdeasMeet Mass AdoptionBuilding a consumer app that millions will love requires a network that feels invisible. Arbitrum provides the near-instant speed, low costs, and scale to make your onchain experience feel as smooth and intuitive as the best Web2 apps.Learn about Arbitrum ConsumerBuild GamesWithout LimitsArbitrum enables you to create the games you've always dreamed of with near-instant transaction speeds, scale, and a seamless experience for your players.Learn about Arbitrum GamingUSD.AIOstiumSessionThe BeaconWildcardGolden TidesOthersideUSDT0VariationalUSDCUniswapAavePendleGMXMorphoRobinhoodBuild alongside hundreds of finance, consumer, and gaming applications.Explore the EcosystemThe Onchain StandardArbitrum consistently leads the industry in key metrics, reflecting the maturity, reliability, and adoption of the platform. Join the ecosystem where innovation meets proven performance.$11.5B+ Total Value SecuredSource A testament to the trust and liquidity driving the next era of blockchain innovation.336.6K+ Daily Active WalletsSource A steady base of users who return to Arbitrum for their daily onchain activity.$11.1B+ Gas Fees SavedSource Low-cost infrastructure keeps value with users, developers, and the companies building the onchain future.View Live DataA Flexible PlatformBuild an App, Launch a ChainShip an application or launch a chain using Arbitrum’s suite of fully customizable solutions to build your vision without compromise.Build an AppDeploy your app on Arbitrum One with Solidity or Stylus (Rust, C, C++). Built for blockchain-native and institutional developers.Learn About AppsLaunch a ChainUse the Arbitrum stack to launch your own chain and configure it end-to-end, from custom gas token and governance to access controls and privacy.Is a Chain Right For You?Case StudiesProven in Production, Trusted at ScaleDiscover why the world’s most innovative companies are building on Arbitrum.Robinhood is realizing the crypto visionPlug Into a Thriving Sovereign NationJoin a dynamic network of active users, digital culture, and economic activity. Arbitrum is the vibrant hub where consumers connect, interact, and transact.Learn MoreAaveAave is a decentralized non-custodial liquidity protocol where users can participate as depositors or borrowers.Learn MorePendlePendle enables the permissionless tokenization and trading of yield, unlocking various strategies such as obtaining fixed yield, long crypto yields, or trade yields of any assets on Pendle.Learn MoreGMXGMX: the on-chain Decentralised Perpetual Exchange with deep liquidity and low fees.Learn MoreVariationalThe most rewarding place to trade perps. Enjoy zero fees while earning loss refunds, spread discounts, and platform credits from your normal trading activity.Learn MoreOstiumTrade any strategy on any asset: from indices and currencies to metals, energy, and crypto.Learn MoreEtherealNext generation decentralized spot and perpetuals trading powered by USDe.Learn MoreUSD.AIUSD.AI is a yield-bearing synthetic dollar protocol backed by GPU mortgages.Learn MoreMorphoLend and borrow using the most secure, efficient, flexible lending protocol on Arbitrum.Learn MoreThe BeaconDive into The Beacon, a roguelite RPG game in development. Experience the thrilling demo now at play.thebeacon.gg and become part of our growing community!Learn MoreOthersideWhere the swamp ends, Otherside begins.Learn MoreWildcard2v2 Collectible Card Action Game where strategy and skill collide. Choose your champion, craft your deck, cast summons, and battle for victory in epic arenas.Learn MoreL3E7World's First 3D LBS (Location-Based Service) Game. Cloning the Whole Earth into a Cyberpunk Metaverse.Learn MoreGolden TidesBuild a crew and set sail to compete against 31 other teams in a quest-packed race for treasure. Plunge into this free-to-play fantasy pirate Adventure MOBA!Learn MoreMy Pet HooliganAn interactive entertainment experience from AMGI Studios. Social-action multiplayer game in Early Access! Launching on Xbox.Learn MoreHyveHyve Labs is building rewarding social GameFi experiences that you can play seamlessly across any platform.Learn MoreRIFTSTORMRiftstorm is a co-op looter-shooter with roguelite that charges players with the defense of our world from mythic threats.Learn MoreBlackBirdRewards, access, and benefits at restaurants you love.Learn MoreEl DoradoLa SuperApp de Stablecoins para Latinoamérica.Learn MoreFarcasterA sufficiently decentralized social network.Learn MorePeanutPeanut is the easiest way to send and receive crypto payments cross-chain via secure links.Learn MoreBerryWith Berry, you can invest in stocks and assets you use every day, including ETFs like the S&P 500.Learn MoreOpenSeaBuy, sell, & discover the internet of goods.Learn MoreForkastForkast is prediction markets at the intersection of gaming culture, sports betting, and crypto trading.Learn MoreT-RexPurpose-built blockchain for entertainment and culture.View all ProjectsReady to start building on Arbitrum?Get in TouchTECHNOLOGY THAT SCALESBuild with ConfidenceAccess clear documentation, robust SDKs, and a global community designed to accelerate your build. Features like Stylus (smart contracts in Rust, C, and C++) unlock new levels of flexibility and performance.Explore DocumentationStart BuildingGet in TouchJoin our CommunitySubscribe for the latest updates.SolutionsFinanceGamingConsumerProductsArbitrum OneDedicated BlockchainsWhy ArbitrumPerformanceConfidentialityCustomizationComplianceIntegrationsCase StudiesDevelopersGet startedConfigure a chainBuild an appBridgeExplorerFaucetStatusGithubResourcesBlogPressTalksContact UsPortalGovernanceForumGrantsBrand KitLegalPrivacy PolicyTerms of ServiceStay in touch","tokens":1548,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258718317,"hash":"6477c8e20949c3d96655f9736af58773c2804809"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/1","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Is this desk lacking administration? \n\n Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 1 / 11\n\n Oct 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1235,"squid":"ink-research","role":"Deep Scholar","at":1791258720856,"hash":"cc0beaa40dfb508de6e382f8daad3ab05f237662"}
{"url":"https://www.anchor-lang.com/docs/updates/changelog","domain":"anchor-lang.com","title":"Changelog","text":"Anchor Project UpdatesChangelogAnchor ChangelogVersion 0 of Semantic Versioning is handled differently from version 1 and\nabove. The minor version will be incremented upon a breaking change and the\npatch version will be incremented for features.\n\n[1.2.0]\nFeatures\n\navm: Allow resolving Solana/platform-tools versions from an explicit Anchor\nversion\n(#4799).\ncli: Add --arch and --tools-version flags to select the SBPF\narchitecture and platform-tools version used by anchor build\n(#4684).\ncli: Generate a TypeScript error constants file from the IDL during\nanchor build\n(#3827).\nlang: Always derive Clone and Debug for generated types in\ndeclare_program!\n(#4723).\nspl: Add pausable mint extension support\n(#4092).\nspl: Add create_native_mint and initialize_non_transferable_mint helpers\n(#3512).\nspl: Add reallocate and withdraw_excess_lamports helpers\n(#3516).\nspl: Added token_metadata_remove_key to support removing keys from token\nmetadata extension\n(#3717).\nlang: Add AccountLoader::new_unchecked for constructing an AccountLoader\nwithout performing owner or discriminator checks\n(#4162).\nlang: Provide better error messages for token constraints\n(#4698).\nts: Improve account resolution error of self-referencing PDAs\n(#4711).\ncli: Warn unused Anchor.toml fields\n(#4749).\n\nFixes\n\nspl: Fix anchor-spl failing to build with only the metadata feature\n(#4742).\nlang: Honor is_signer in generated client and CPI account metas, enabling\nPDA signer usage\n(#3322).\nlang: Report invalid instruction arguments instead of silently omitting\ntheir instructions during parsing\n(#4008).\nsyn: Correct bytemuck serialization detection to avoid false positives\nfrom unrelated derives\n(#4215).\nlang: Return an error instead of panicking when zero-copy account data is\nundersized\n(#4555).\nlang: Handle numeric instruction suffixes in declare_program! generated\naccount-module re-exports\n(#4568).\nlang: Reject all-zero account discriminators\n(#4645).\nlang: Preserve IDL namespace boundaries in declare_program! to prevent\nforeign-IDL name collisions with Anchor prelude items\n(#4776).\nlang: Re-run ownership and discriminator checks when unloading LazyAccount\nafter a CPI\n(#4784).\nclient: Fix ignored commitment level\n(#4666).\nlang: Remove cloning AccountInfo to read lamports in init_if_needed\ncodegen\n(#4675).\nlang: Guard AccountLoader<T>::exit against zero-copy buffer truncation and\nbail with AccountDidNotDeserialize instead of rewriting the discriminator\nover an undersized buffer\n(#4633).\nlang: Shorten invariant lifetimes during Context creation\n(#4363).\nlang: Qualify bare error! calls in require macros so they don't depend on\nglobal prelude imports\n(#4639).\nts: Guard recursive IDL layouts against stack overflows while preserving\nsupported recursive types\n(#4604).\nlang: Fix missing error messages of the generated errors in\ndeclare_program!\n(#4652).\nspl: Fix wrong owner pubkey in CPI Guard enable/disable\n(#4322).\nspl: Add missing auth account to group_pointer_update\n(#4324).\nspl: Deprecate broken cpi_guard_enable/disable functions\n(#4465).\nlang: Reduce cloning in realloc constraint when shrinking\n(#4642).\nsyn: Remove anyhow\n(#4640).\nlang: Sync type derives and simplify internal args creation in\ndeclare_program!\n(#4667).\nlang: Improve std hygiene inside macros\n(#4700).\ncli: Honor the SIMD-0431 minimum extend program size when extending program\ndata\n(#4785).\nclient: Do not panic in parse_logs_response when logs continue after a\ntop-level instruction returns, e.g. the runtime's trailing \"Log truncated\"\nmarker\n(#4967).\n\n[1.1.2]\nFixes\n\ndeps: Tighten dependencies between anchor-* crates to reduce breakage\n(#4726).\n\n[1.1.1]\nFeatures\n\nts: Re-implement verifiedBuild using the OtterSec registry\n(verify.osec.io), replacing the defunct apr.dev API\n(#4522).\nts: Add decodeIdlAccountRaw\n(#4375).\ncli: Add --stdout flag to the expand command\n(#4400).\nclient: Add versioned tx support\n(#4207).\ncli: Add edition and rust-version to template\n(#4048).\nlang: Add program_id verification to CPI return values\n(#4411).\ncli: Resolve the target directory via cargo metadata so custom target\nlocations (e.g. CARGO_TARGET_DIR, workspace-level overrides) work across\nbuild, test, deploy and IDL paths\n(#3817).\ncli: Allow configuring IDL JSON location in workspace config\n(#4483).\nlang: Derive Clone, Debug, Copy, and Default on generated client /\nCPI account structs and instruction args where the field types allow it\n(#4085).\ncli: Support multiple named scripts in Anchor.toml and run them via\nanchor test --script <name> / anchor run <name>\n(#3999).\ncli/idl: Add fetch-historical support to recover historical IDLs with the\nAnchor CLI\n(#3992).\ncli: anchor init refuses to create a new Anchor workspace inside an\nexisting Cargo workspace to avoid broken nested layouts\n(#4576).\ncli: Add r as an alias to the run command\n(#4643).\n\nFixes\n\ncli: Warn instead of aborting anchor build when a program keypair and\ndeclare_id! do not match\n(#4705).\nlang: Snapshot CPI return data before Return::get() validates the source\nprogram\n(#4624).\nlang/syn: Remove remaining fallible IDL generation paths from clippy-denied\ncode\n(#4631).\nlang: Validate max_len arguments more strictly during space derivation\n(#4707).\nts: Remove cross-fetch dependency\n(#4671).\nlang: Set anchor-lang Minimum Supported Rust Version to 1.89\n(#4638).\nlang: Migrate anchor-syn from syn 1.x to syn 2.0, allowing use of modern\nRust syntax\n(#4523).\nidl: Bump version to 0.1.3\n(#4453).\nlang: Avoid fatal errors in IDL building when modern Rust syntax is in use\n(#4520).\nlang: Return InvalidProgramId when Migration::exit cannot persist\nmigrated state because To::owner() does not match program_id\n(#4706).\nclient: Avoid panic in parse_logs_response when a program-emitted log line\nends with invoke [1]\n(#4461).\ncli: Correctly honor --skip-seed-phrase-validation in keygen recover\n(#4417).\nts: Fix sha256.hash() returning corrupted output by using hex encoding\n(#4404).\nlang: Support module constants in max_len attribute\n(#3879).\ncli: Bump cargo_toml to allow parsing resolver = \"3\"\n(#4515).\nts: Validate instruction args in BorshInstructionCoder.encode to reject\ntypo'd or missing fields instead of silently ignoring them\n(#4560).\nts: Align TS camelCase conversion with Rust heck for digit-letter\nidentifiers so generated client names match Rust identifiers\n(#4571).\ncli: Warn if event-cpi instruction is unreachable with custom\ndiscriminators\n(#4614).\nts: Update engines.node to >= 20.18\n(#4647).\n\n[1.0.3]\nFixes\n\ndeps: Tighten dependencies between anchor-* crates to reduce breakage\n(#4726).\n\n[1.0.2]\nFixes\n\nclient: Replace solana-program with solana-hash\n(#4468).\nlang: Make idl build time way faster by caching CrateContext\n(#4325).\ncli: Bind localnet to 127.0.0.1 by default to fix a panic in\nsolana-test-validator version 3.1.10\n(#4397).\ncli: Fallback to a priority fee of 0 on localnet\n(#4259).\nlang/syn: Fix compile error with init and a runtime seeds expression\n(#4495).\n\n[1.0.1]\nFixes\n\nlang: Handle user-provided borsh attributes in derives\n(#4380).\n\n[1.0.0]\nFeatures\n\nlang: Add Migration<'info, From, To> account type for schema migrations\nbetween account types\n(#4060).\ncli: Added a check_program_id_mismatch in build time to check if the\nprogram ID in the source code matches the program ID in the keypair file.\nThis check will be skipped during anchor test\n(#4018).\nlang: Add instruction parser to declare_program!\n(#4118).\nts: Export all IDL types from the root. Users can now update dist/cjs/idl\nimports to import directly from @anchor-lang/core\n(#3948).\nlang: Add declare_program! support with just anchor_client and not\nanchor_lang\n(#4157).\nlang: Export Owners from prelude\n(#4189).\ncli: Use surfpool by default for anchor test and anchor localnet commands\n(#4106).\nlang: Optimize enums with all unit variants and empty arrays with Lazy\n(#4237).\nlang: Include init_if_needed accounts in duplicate mutable account checks\n(#4239).\nclient: Accept FnMut for events closure\n(#4024).\nclient: Export all types used by the public API\n(#4211).\nlang: Make common::close accept references\n(#4178).\ncli/idl: Add --allow-localnet option for IDL commands; fix panic when run\noutside a workspace\n(#4252).\nlang: Check owner on account reload\n(#3837).\nlang/ts: Upgrade borsh to 1.5.7\n(#4012).\nsyn: Relax seeds syntax to allow more flexible PDA seed expressions\n(#3813).\nlang: Deprecate AccountInfo usage in Accounts macro with a compile-time\nwarning\n(#3854).\ncli: Update anchor init to use the multiple program template by default\n(#3958).\ncli: Add hooks section to Anchor.toml for\n{pre,post}-{build,test,deploy} lifecycle hooks\n(#3862).\nlang: Add generic program validation support to Program type allowing\nProgram<'info> for executable-only validation\n(#3878).\ncli: Added litesvm test template and made it the default option on\nanchor init\n(#4316)\ncli: Added --install-agent-skills to automatically install Solana agent\nskills during anchor init\n(#4307)\navm: Added flags and version labels to explicitly handle pre-releases\n(avm list --pre-release, avm update --pre-release and\navm install latest-pre-release)\n(#4335)\navm: Added avm self-update command and passive version check warning for\nout of date avm\n(#4338)\nlang, cli, client: Updated solana dependencies to the latest compatible\nversions. Bumping CI and docker builds to use Solana CLI version 3.1.10\n(#4317)\n\nFixes\n\nlang: Add missing Lazy bound on generics\n(#4240).\nlang: Fix wrong generated error code in declare_program!\n(#4129).\nidl: Fix defined types with unsupported fields not producing an error\n(#4088).\nlang: Fix using non-instruction composite accounts multiple times with\ndeclare_program!\n(#4113).\nlang: Fix declare_program! messing up IDL errors generation\n(#4126).\nidl: Fix address constraint not resolving constants that have numbers in\ntheir identifiers\n(#4144).\nlang: Fix constant nested string generation in declare_program!\n(#4158).\nidl: Fix local_file method not found for proc_macro2::Span error\n(#4187).\nlang: Relax duplicate mutable account constraint to only check types that\nserialize on exit (Account, LazyAccount, InterfaceAccount, Migration)\n(#4202).\nidl: Make serde_json optional\n(#4296).\nlang: Fix declare_program! instruction parser with optional accounts\n(#4180).\nlang: Use original borsh derives\n(#4205).\nlang: Fix unexpected account substitution in InterfaceAccount\n(#4139).\nidl: Respect offset = ... in IDL generation for custom errors\n(#4040).\ncli: Relax separate dependency check for solana-program\n(#4166).\nlang: Enforce type and count matching between instruction handler and\n#[instruction(..)] args\n(#4000).\nlang: Handle invalid camelCase identifiers more gracefully\n(#4021).\ncli: Fix i128/u128 deserialization\n(#3938).\nts: Fix incorrect Anchor dependency version requirements\n(#4138).\nlang: Omit parsers module of declare_program! during on-chain (Solana)\nbuilds\n(#4109).\ndocs: Fixed broken links and replaced coral-xyz github references to\nsolana-foundation\n(#4320)\navm: Fixed handling of new Cargo.toml version location. Fixed handling of\npre-release version parsing\n(#4335)\nclient: Fix deadlock when having multiple websocket listeners\n(#4250).\nlang: Fix incorrect deserialization for dynamically sized types when using\nlazy-account\n(#4319)\navm: Using a temporary installation dir on cargo install calls to prevent\ncargo erroring out due to existing anchor symlink in .avm/bin\n(#4343)\n\nBreaking\n\ncli: Remove program arch options\n(#4295).\nlang: Disallow duplicate mutable accounts by default. But allows duplicate\nmutable accounts in instruction contexts using dup constraint\n(#3946).\ncli: Remove program id arguments of idl init and idl upgrade commands\n(#4130).\nlang: Rename utils module of declare_program! to parsers\n(#4151).\nlang: Remove the interface-instructions feature and the #[interface]\nattribute\n(#4156).\ncli: Remove the login command\n(#4182).\nidl: Exclude external accounts\n(#4197).\nidl: Remove the conflicting account names check\n(#4294).\ndeps: Update to Solana 3.0\n(#4031).\nidl: Remove legacy IDL instructions and integrate Program Metadata for IDL\nmanagement\n(#3798).\nts: Rename TypeScript packages from @coral-xyz/anchor to\n@anchor-lang/core\n(#4141).\nlang: Remove program account info from CPI context\n(#2762).\ncli: Remove dependency on the external solana CLI; native implementations\nprovided for balance, airdrop, address, deploy, and other commands\n(#4099).\nidl: Disallow multiple #[error_code] definitions in a single program\n(#4300).\ncli: Remove the [registry] section from Anchor.toml\n(#4299).\nclient: Make sending a tx not panic and instead return an Error when signing\nfails\n(#3865).\nlang: Rename errors and ProgramError of declare_program!\n(#4347).\nclient: Remove the solana-account-decoder crate export\n(#4373).\n\n[0.32.1] - 2025-10-09\nFixes\n\nlang: Fix deprecation warnings on alloc and add solana-program to prelude\n(#3975).\ncli: Fix race condition that could happen when deploying a program\n(#3976).\n\n[0.32.0] - 2025-10-08\nFeatures\n\nlang: Add #[error] attribute to declare_program!\n(#3757).\ncli: Replace anchor verify to use solana-verify under the hood, adding\nautomatic installation via AVM, local path support, and future-proof argument\npassing (#3768).\nlang: Replace solana-program crate with smaller crates\n(#3819).\ncli: Make anchor deploy to upload the IDL to the cluster by default unless\n--no-idl is passed\n(#3863).\nlang: Use solana-invoke instead of solana_cpi::invoke\n(#3900).\nclient: remove solana-client from anchor-client and cli\n(#3877).\nidl: Build IDL on stable Rustc\n(#3842).\nlang: Add custom error when using init on SystemAccount\n(#3828).\nlang: Add errors to declare_program\n(#3757).\nts: Add support for Bun as a package manager\n(#3586).\nlang: Add support for tuple types in space calculation\n(#3744).\nlang: Add missing pubkey const generation\n(#3677).\ncli: Add the Minimum Supported Rust Version (MSRV) to the Rust template,\nsince an arbitrary compiler version isn't supported\n(#3873).\n\nFixes\n\ndocker: Upgrade node to 20.18.0 LTS\n(#3687).\ncli: Fix using deprecated commitment recent in migration scripts\n(#3725).\ncli: Fix not respecting provider.cluster in keys sync command\n(#3761).\nlang: Fix deprecated realloc, store_current_index and clippy warnings\n(#3819).\navm: fix AVM instability with solana-verify\n(#3867).\navm: update AVM to only use non-draft\nreleases(#3931).\nlang: update bytemuck\n(#3858).\nidl: disable Locale in camelCase\n(#3845).\nts: Remove event parsing panic\n(#3657).\n\nBreaking\n\nspl: Update SPL dependencies to latest compatible versions\n(#3860).\ncli: Replace anchor verify to use solana-verify under the hood, adding\nautomatic installation via AVM, local path support, and future-proof argument\npassing (#3768).\ncli: Upload IDL by default with an option to skip\n((#3863)[https://github.com/solana-foundation/anchor/pull/3863]).\nlang: remove Solang\n(#3824).\ncli: remove anchor publish command\n(#3795).\n\n[0.31.1] - 2025-04-19\nFeatures\n\ncli, docker: Replace backpackapp/build Docker image with\nsolanafoundation/anchor\n(#3619).\nts: Make Provider require publicKey instead of wallet in accounts resolver\n(#3613)\n\nFixes\n\nidl: Update proc-macro2 usage for latest nightly\n(#3663)\nts: Fix parsing IDL with multiple const generics\n(#3665)\n\nBreaking\n[0.31.0] - 2025-03-08\nFeatures\n\nclient: Make solana_account_decoder dep public in anchor client\n(#3455).\nts: Add optional options.blockhash to Provider.sendAndConfirm\n(#3070).\nts: Add optional commitment parameter to Program.addEventListener\n(#3052).\ncli, idl: Pass cargo args to IDL generation when building program or IDL\n(#3059).\ncli: Add checks for incorrect usage of idl-build feature\n(#3061).\nlang: Export Discriminator trait from prelude\n(#3075).\nlang: Add Account utility type to get accounts from bytes\n(#3091).\nclient: Add option to pass in mock rpc client when using anchor_client\n(#3053).\nlang: Get discriminator length dynamically\n(#3101).\nlang: Add non-8-byte discriminator support in declare_program!\n(#3103).\nclient: Make ThreadSafeSigner trait public\n(#3107).\nlang: Update dispatch function to support dynamic discriminators\n(#3104).\nlang: Remove the fallback function shortcut in try_entry function\n(#3109).\nts: Get discriminator lengths dynamically\n(#3120).\nclient: Support non-8-byte discriminators\n(#3125).\nspl: Add withdraw_withheld_tokens_from_accounts instruction\n(#3128).\nts: Add optional wallet property to the Provider interface\n(#3130).\ncli: Warn if anchor-spl/idl-build is missing\n(#3133).\nclient: Add internal_rpc method for mock feature\n(#3135).\nlang: Add #[instruction] attribute proc-macro to override default\ninstruction discriminators\n(#3137).\nlang: Use associated discriminator constants instead of hardcoding in\n#[account] (#3144).\nlang: Add discriminator argument to #[account] attribute\n(#3149).\nlang: Add discriminator argument to #[event] attribute\n(#3152).\nidl: Check ambiguous discriminators\n(#3157).\nidl: Disallow all zero account discriminators\n(#3159).\ncli: Support non-8-byte discriminators\n(#3165).\nidl: Disallow empty discriminators\n(#3166).\ncli: Add --no-idl option to the test command\n(#3175).\nspl: Add burn_checked, mint_to_checked and approve_checked instructions\n(#3186).\ncli: Migrate to agave-install when solana_version is >= 1.18.19\n(#3185).\nidl: Add IdlBuilder\n(#3188).\ncli: Make clean command also remove the .anchor directory\n(#3192).\nlang: Deprecate #[interface] attribute\n(#3195).\nts: Include unresolved accounts in the resolution error message\n(#3207).\nlang: Add LazyAccount\n(#3194).\navm: Ask whether to install if the version is not installed with the use\ncommand (#3230).\ncli: Warn if a manifest has solana-program dependency\n(#3250).\ncli: Add completions command to generate shell completions via the\nclap_complete crate (#3251).\ncli: Always convert IDLs\n(#3265).\ncli: Check whether the idl-build feature exists when using the idl build\ncommand (#3273).\ncli: Build IDL if there is only one program when using the idl build command\n(#3275).\ncli: Add short alias for the idl build command\n(#3283).\ncli: Add --program-id option to idl convert command\n(#3309).\nlang: Generate documentation of constants in declare_program!\n(#3311).\ncli: Add support for fetching legacy IDLs\n(#3324).\navm: Add short alias for install and list commands\n(#3326).\navm: Add Windows support for renaming anchor binary\n(#3325).\ncli: Add optional package-manager flag in init command to set package\nmanager field in Anchor.toml\n(#3328).\ncli: Add test template for Mollusk\n(#3352).\nidl: Disallow account discriminators that can conflict with the zero\nconstraint (#3365).\ncli: Include recommended solana args by default and add new --max-retries\noption to the deploy command\n(#3354).\navm: Make installation download binaries by default\n(#3445).\nidl: Support PDA resolution of call expressions that don't have any arguments\n(#3485).\nspl: Add anchor-debug feature\n(#3511).\n\nFixes\n\nidl: Make safety comment checks fail silently when program path env is not set\n(#3045).\nidl: Avoid interference from rust tests during IDL generation\n(#3058).\nlang: Fix align repr support in declare-program!\n(#3056).\nlang: Make stack frames slimmer on ATA creation\n(#3065).\nlang: Remove getrandom dependency\n(#3072).\nlang: Make InitSpace support unnamed & unit structs\n(#3084).\nlang: Fix using owner constraint with Boxed accounts\n(#3087).\nlang: Add a sanity check for unimplemented token extensions\n(#3090).\ncli: Skip IDL checks if --no-idl option is passed\n(#3093).\nlang: Remove unnecessary clone in account exit routine\n(#3139).\ncli: Fix installation with --locked argument using Rust v1.80 due to time\ncrate issue (#3143).\nlang: Fix compilation warnings due to unused deprecated program id macros\n(#3170).\nts: Remove crypto-hash dependency\n(#3171).\nts: Improve error message of unsupported view method\n(#3177).\nidl: Fix panicking on tests\n(#3197).\nlang: Remove arrayref dependency\n(#3201).\ncli: Fix template code shouldn't escape\n(#3210).\nidl: Fix using address constraint with non-const expressions\n(#3216).\nidl: Fix using full path types with Program\n(#3228).\nlang: Use closures for init constraints to reduce the stack usage of\ntry_accounts (#2939).\nlang: Allow the cfg attribute above the instructions\n(#2339).\nidl: Log output with ANCHOR_LOG on failure and improve build error message\n(#3284).\nlang: Fix constant bytes declarations when using declare_program!\n(#3287).\nlang: Fix using non-instruction composite accounts with declare_program!\n(#3290).\nidl: Fix instructions with tuple parameters not producing an\nerror(#3294).\nts: Update engines.node to >= 17\n(#3301).\ncli: Use OS-agnostic paths\n(#3307).\navm: Use rustc 1.79.0 when installing versions older than v0.31\n(#3315).\ncli: Fix priority fee calculation causing panic on localnet\n(#3318).\ncli: Fix shell command failing due to outdated program initialization\n(#3351).\nidl: Fix detecting false-positives from doc comments during module path\nconversion (#3359).\ncli: Remove passing the rent sysvar account to IDL instructions\n(#3372).\nlang: Fix cpi feature instructions not accounting for discriminator\noverrides (#3376).\nidl: Ignore compiler warnings during builds\n(#3396).\ncli: Avoid extra IDL generation during verify\n(#3398).\nlang: Require zero accounts to be unique\n(#3409).\nlang: Deduplicate zero accounts against init accounts\n(#3422).\ncli: Fix custom provider.cluster\n(#3428).\ncli: Ignore non semver solana/agave releases to avoid panic\n(#3432).\nts: Fix loading programs with numbers in their names using workspace\n(#3450).\nlang: Remove a potential panic while getting the IDL in declare_program!\n(#3458).\ncli: Fix altering user-provided lib names\n(#3467).\nidl: Fix missing program::seed resolution\n(#3474).\nlang: Fix adding derives and reprs to type alias definitions in\ndeclare_program! (#3504).\nidl: Fix using constant identifiers as generic arguments\n(#3522).\nclient: Remove std::process::exit usage\n(#3544).\nidl: Fix using Pubkey constants with seeds::program\n(#3559).\nlang: Fix instructions with no accounts causing compilation errors when using\ndeclare_program! (#3567).\nidl: Fix using account or arg values for seeds::program\n(#3570).\nlang: Fix using data as an instruction parameter name in declare_program!\n(#3574).\ncli: Use camelCase for program name in anchor.workspace templates\n(#3581).\n\nBreaking\n\nsyn: Remove bpf target support in hash feature\n(#3078).\nclient: Add tokio support to RequestBuilder with async feature\n(#3057).\nlang: Remove EventData trait\n(#3083).\nclient: Remove async_rpc method\n(#3053).\nlang: Make discriminator type unsized\n(#3098).\nlang: Require Discriminator trait impl when using the zero constraint\n(#3118).\nts: Remove DISCRIMINATOR_SIZE constant\n(#3120).\nlang: #[account] attribute arguments no longer parses identifiers as\nnamespaces (#3140).\nspl: Rename metadata interface instruction fields from token_program_id to\nprogram_id (#3076).\nlang, ts: Remove \"8 byte\" requirement from discriminator error messages\n(#3161).\nlang: Remove discriminator method from Discriminator trait\n(#3163).\ndocker: Upgrade node to 20.16.0 LTS\n(#3179).\nts: Change the Program constructor's idl parameter type to any\n(#3181).\nlang, spl: Remove borsh 0.9 support\n(#3199).\nts: Upgrade typescript to 5.5.4 and remove the generic parameters of\nSimulateResponse (#3221).\nts: Remove\nStateCoder(#3224).\ncli: Accept integers for warp_slot\n(#3235).\nlang: Remove EventIndex\n(#3244).\nspl: Remove dex feature\n(#3257).\nclient, lang, spl: Upgrade Solana to v2 and SPL to the latest\n(#3219).\ncli: Install Solana from anza.xyz domain in Docker verifiable builds\n(#3271).\nspl: Upgrade SPL deps to latest\n(#3346).\ncli: Upgrade typescript version of templates to v5\n(#3480).\nts: Remove snake-case dependency\n(#3507).\n\n[0.30.1] - 2024-06-20\nFeatures\n\nidl: Allow overriding the idl build toolchain with the RUSTUP_TOOLCHAIN\nenvironment variable\n(#2941).\navm: Support customizing the installation location using AVM_HOME\nenvironment variable (#2917).\navm: Optimize avm list when GitHub API rate limits are reached\n(#2962)\nidl, ts: Add accounts resolution for associated token accounts\n(#2927).\ncli: Add --no-install option to the init command\n(#2945).\nlang: Implement TryFromIntError for Error to be able to propagate integer\nconversion errors (#2950).\nidl: Add ability to convert legacy IDLs\n(#2986).\nts: Extract Anchor error codes into their own package\n(#2983).\ncli: Add additional solana arguments to the upgrade command\n(#2998).\nspl: Export spl-associated-token-account crate\n(#2999).\nlang: Support legacy IDLs with declare_program!\n(#2997).\ncli: Add idl convert command\n(#3009).\ncli: Add idl type command\n(#3017).\nlang: Add anchor_lang::pubkey macro for declaring Pubkey const values\n(#3021).\ncli: Sync program ids on the initial build\n(#3023).\nidl: Remove anchor-syn dependency\n(#3030).\nlang: Add const of program ID to declare_id! and declare_program!\n(#3019).\nidl: Add separate spec crate\n(#3036).\n\nFixes\n\nlang: Eliminate variable allocations that build up stack space for token\nextension code generation\n(#2913).\nts: Fix incorrect maxSupportedTransactionVersion in AnchorProvider.send*()\nmethods (#2922).\ncli: Use npm's configured default license for new projects made with\nanchor init (#2929).\ncli: add filename to 'Unable to read keypair file' errors\n(#2932).\nidl: Fix path resolution of the Cargo.lock of the project when generating\nidls for external types\n(#2946).\nidl: Fix potential panic on external type resolution\n(#2954).\nlang: Fix using defined types in instruction parameters with\ndeclare_program! (#2959).\nlang: Fix using const generics with declare_program!\n(#2965).\nlang: Fix using Vec<u8> type with declare_program!\n(#2966).\nlang: Fix ProgramError::ArithmeticOverflow not found error\n(#2975).\nlang: Fix using optional accounts with declare_program!\n(#2967).\nlang: Fix instruction return type generation with declare_program!\n(#2977).\ncli: Fix IDL write getting corrupted from retries\n(#2964).\nidl: Fix unexpected_cfgs build warning\n(#2992).\nlang: Make tuple struct fields public in declare_program!\n(#2994).\nRemove rust-version from crate manifests\n(#3000).\ncli: Fix upgradeable program clones\n(#3010).\nts: Fix using IDLs that have defined types as generic arguments\n(#3016).\nidl: Fix generation with unsupported expressions\n(#3033).\nidl: Fix using address constraint with field expressions\n(#3034).\nlang: Fix using bytemuckunsafe account serialization with declare_program!\n(#3037).\n\nBreaking\n[0.30.0] - 2024-04-15\nFeatures\n\ncli: Allow force init and new\n(#2698).\ncli: Add verifiable option when deploy\n(#2705).\ncli: Add support for passing arguments to the underlying\nsolana program deploy command with anchor deploy\n(#2709).\nlang: Add InstructionData::write_to implementation\n(#2733).\nlang: Add #[interface(..)] attribute for instruction discriminator overrides\n(#2728).\nts: Add .interface(..) method for instruction discriminator overrides\n(#2728).\ncli: Check anchor-lang and CLI version compatibility\n(#2753).\nts: Add missing IDL PDA seed types\n(#2752).\ncli: idl close accepts optional --idl-address parameter\n(#2760).\ncli: Add support for simple wildcard patterns in Anchor.toml's\nworkspace.members and workspace.exclude.\n(#2785).\ncli: Add --test-template option for init command\n(#2805).\ncli: anchor test is able to run multiple commands\n(#2799).\ncli: Check @coral-xyz/anchor package and CLI version compatibility\n(#2813).\ncli: Accept package name as program name\n(#2816).\ncli: Add ability to build and test only a specified program\n(#2823).\nidl: Add new IDL spec\n(#2824).\nidl: Add support for reprs\n(#2824).\nidl: Add support for expression evaluation\n(#2824).\nidl: Add support for using external types when generating the IDL\n(#2824).\nidl, ts: Add unit and tuple struct support\n(#2824).\nidl, ts: Add generics support\n(#2824).\nts: Add accountsPartial method to keep the old accounts method behavior\n(#2824).\nts: Make opts parameter of AnchorProvider constructor optional\n(#2843).\ncli: Add --no-idl flag to the build command\n(#2847).\ncli: Add priority fees to idl commands\n(#2845).\nts: Add prepend option to MethodBuilder preInstructions method\n(#2863).\nlang: Add declare_program! macro\n(#2857).\ncli: Add deactivate_feature flag to solana-test-validator config in\nAnchor.toml (#2872).\nidl: Add docs field for constants\n(#2887).\nidl: Store deployment addresses for other clusters\n(#2892).\nlang: Add Event utility type to get events from bytes\n(#2897).\nlang, spl: Add support for\ntoken extensions\n(#2789).\nlang: Return overflow error from Lamports trait operations\n(#2907).\n\nFixes\n\nsyn: Add missing new_from_array method to Hash\n(#2682).\ncli: Switch to Cargo feature resolver(resolver = \"2\")\n(#2676).\ncli: Fix using user specific path for provider.wallet in Anchor.toml\n(#2696).\nsyn: Fix IDL constant seeds parsing\n(#2699).\ncli: Display errors if toolchain override restoration fails\n(#2700).\ncli: Fix commit based anchor_version override\n(#2704).\nspl: Fix compilation with shmem feature enabled\n(#2722).\ncli: Localhost default test validator address changes from localhost to\n127.0.0.1, NodeJS 17 IP resolution changes for IPv6\n(#2725).\nlang: Eliminate temporary Vec allocations when serializing data with\ndiscriminant and set the default capacity to 256 bytes\n(#2691).\nlang: Allow custom lifetime in Accounts structure\n(#2741).\nlang: Remove try_to_vec usage while setting the return data in order to\nreduce heap memory usage\n(#2744)\ncli: Show installation progress if Solana tools are not installed when using\ntoolchain overrides (#2757).\nts: Fix formatting enums\n(#2763).\ncli: Fix migrate command not working without global ts-node installation\n(#2767).\nclient, lang, spl, syn: Enable all features for docs.rs build\n(#2774).\nts: Fix construction of field layouts for type aliased instruction arguments\n(#2821)\nidl: Fix IDL (#2824).\nidl, ts: Make casing consistent\n(#2824).\nts: Fix not being able to use numbers in instruction, account, or event names\nin some cases due to case conversion\n(#2824).\ncli: Fix excessive test validator requests\n(#2828).\nclient: Fix parse_logs_response to prevent panics when more than 1 outer\ninstruction exists in logs\n(#2856).\navm, cli: Fix stdsimd feature compilation error from ahash when installing\nthe CLI using newer Rust versions\n(#2867).\nspl: Fix not being able to deserialize newer token 2022 extensions\n(#2876).\nspl: Remove solana-program dependency\n(#2900).\nspl: Make TokenAccount and Mint Copy\n(#2904).\nts: Add missing errors\n(#2906).\n\nBreaking\n\ncli: Make cargo build-sbf the default build command\n(#2694).\ncli: Require explicit overflow-checks flag\n(#2716).\nts: Remove anchor-deprecated-state feature\n(#2717).\nlang: Remove CLOSED_ACCOUNT_DISCRIMINATOR\n(#2726).\nlang: Make bumps of optional accounts Option<u8> rather than u8\n(#2730).\nspl: Remove shared-memory program\n(#2747).\nts: Remove associated, account.associated and account.associatedAddress\nmethods (#2749).\ncli: idl upgrade command closes the IDL buffer account\n(#2760).\ncli: Remove --jest option from the init command\n(#2805).\ncli: Require idl-build feature in program Cargo.toml\n(#2824).\ncli: Rename seeds feature to resolution and make it enabled by default\n(#2824).\ncli: Remove idl parse command\n(#2824).\nidl: Change IDL spec (#2824).\nsyn: Remove idl-parse and seeds features\n(#2824).\nts: Change accounts method to no longer accept resolvable accounts\n(#2824).\nts: Program instances use camelCase for everything\n(#2824).\nts: Remove discriminator functions\n(#2824).\nts: Remove programId parameter of the Program constructor\n(#2864).\nidl, syn: Move IDL types from the anchor-syn crate to the new IDL crate\n(#2882).\nidl: Add #[non_exhaustive] to IDL enums\n(#2890).\n\n[0.29.0] - 2023-10-16\nFeatures\n\nlang: Change all accounts to have a reference to AccountInfo\n(#2656).\nlang: Add get_lamports, add_lamports and sub_lamports methods for all\naccount types (#2552).\nclient: Add a helper struct DynSigner to simplify use of\nClient<C> where <C: Clone + Deref<Target = impl Signer>> with Solana clap\nCLI utils that loads Signer as Box<dyn Signer>\n(#2550).\nlang: Allow CPI calls matching an interface without pinning program ID\n(#2559).\ncli, lang: Add IDL generation through compilation. anchor build still uses\nparsing method to generate IDLs, use anchor idl build to generate IDLs with\nthe build method (#2011).\navm: Add support for the .anchorversion file to facilitate switching between\ndifferent versions of the anchor-cli\n(#2553).\nts: Add ability to access workspace programs independent of the casing used,\ne.g. anchor.workspace.myProgram, anchor.workspace.MyProgram...\n(#2579).\nbench: Add benchmarking for program binary size\n(#2591).\nspl: Export mpl-token-metadata crate\n(#2583).\nspl: Add TokenRecordAccount for pNFTs\n(#2597).\nts: Add support for unnamed(tuple) enum in accounts\n(#2601).\ncli: Add program template with multiple files for instructions, state...\n(#2602).\nbench: Add benchmarking for stack memory usage\n(#2617).\nlang: Box the inner enums of anchor_lang::error::Error to optimize\nanchor_lang::Result\n(#2600).\nts: Add strong type support for Program.addEventListener method\n(#2627).\nsyn: Add IdlBuild trait to implement IDL support for custom types\n(#2629).\nspl: Add idl-build feature. IDL build method will not work without enabling\nthis feature when using anchor-spl\n(#2629).\nlang: Add support for type aliases in IDLs\n(#2637).\ncli: Add test.upgradeable, test.genesis.upgradeable setting in\nAnchor.toml to support testing upgradeable programs\n(#2642).\ncli, client, lang, spl: Update Solana toolchain and dependencies to 1.17.0,\n1.16 remains supported\n(#2645).\nspl: Add support for memo program\n(#2661).\navm: Add anchor-cli installation from commit\n(#2659).\ncli: Add toolchain property in Anchor.toml to override Anchor and Solana\nversions (#2649).\n\nFixes\n\nts: Packages no longer depend on assert\n(#2535).\nlang: Support for const in the InitSpace macro\n(#2555).\ncli: Support workspace inheritance\n(#2570).\nclient: Compile with Solana 1.14\n(#2572).\ncli: Fix anchor build --no-docs adding docs to the IDL\n(#2575).\nts: Load workspace programs on-demand rather than loading all of them at once\n(#2579).\nlang: Fix associated_token::token_program constraint\n(#2603).\ncli: Fix anchor account command panicking outside of workspace\n(#2620).\nlang: IDL named enum variant fields are now camelCase as opposed to\nsnake_case, consistent with the other IDL types\n(#2633).\navm: Remove excessive panics and handle the errors gracefully\n(#2671).\n\nBreaking\n\nlang: Switch to type safe bumps in context\n(#2542).\nsyn: idl feature has been replaced with idl-build, idl-parse and\nidl-types features (#2011).\nsyn: IDL parse method now returns Result<Idl> instead of\nResult<Option<Idl>>\n(#2582).\nspl: Update mpl-token-metadata dependency to use the client SDK instead of\nthe program crate (#2632).\nts: Remove base64-js dependency\n(#2635).\nsyn: IdlTypeDefinitionTy enum has a new variant Alias\n(#2637).\ncli, client, lang, spl: Solana 1.14 is no longer supported, minimum required\nSolana version is 1.16.0\n(#2645).\ncli: anchor_version and solana_version property in Anchor.toml that was\nbeing used in verifiable builds are moved inside toolchain. They are now\nbeing used for all commands in the workspace, not just verifiable builds\n(#2649).\n\n[0.28.0] - 2023-06-09\nFeatures\n\nclient: Add async feature flag to use an asynchronous anchor-client\n(#2488).\nspl: Add metadata wrappers approve_collection_authority,\nbubblegum_set_collection_size, burn_edition_nft, burn_nft,\nrevoke_collection_authority, set_token_standard, utilize,\nunverify_sized_collection_item, unverify_collection\n(#2430)\nspl: Add token_program constraint to Token, Mint, and AssociatedToken\naccounts in order to override required token_program fields and use\ndifferent token interface implementations in the same instruction\n(#2460)\ncli: Add support for Solidity programs. anchor init and anchor new take an\noption --solidity which creates solidity code rather than rust.\nanchor build and anchor test work accordingly\n(#2421)\nbench: Add benchmarking for compute units usage\n(#2466)\ncli: idl set-buffer, idl set-authority and idl close take an option\n--print-only. which prints transaction in a base64 Borsh compatible format\nbut not sent to the cluster. It's helpful when managing authority under a\nmultisig, e.g., a user can create a proposal for a Custom Instruction in SPL\nGovernance (#2486).\nlang: Add emit_cpi! and #[event_cpi] macros(behind event-cpi feature\nflag) to store event logs in transaction metadata\n(#2438).\ncli: Add keys sync command to sync program id declarations\n(#2505).\ncli: Create new programs with correct program ids\n(#2509).\ncli, client, lang, spl: Update Solana toolchain and dependencies to 1.16.0\nand specify maximum version of <1.17.0\n(#2512).\ncli: anchor deploy command's --program-name argument accepts program lib\nnames (#2519).\n\nFixes\n\nts: Narrowed AccountClient type to it's appropriate account type\n(#2440)\nlang: Fix inability to use identifiers program_id, accounts, ix_data,\nremaining_accounts in instruction arguments\n(#2464)\ncli: Fix incorrect metadata.address generation in IDL after deploying with a\ncustom keypair (#2485)\ncli: IDL commands no longer hang when the payer doesn't have funds to pay for\nthe transaction fee (#2492)\ncli: Fix anchor new not updating Anchor.toml\n(#2516).\nclient, lang, spl: Allow wider range of dependency versions to reduce\ndependency issues (#2524).\n\nBreaking\n\nlang: Identifiers that are intended for internal usage(program_id,\naccounts, ix_data, remaining_accounts) have been renamed with __\nprefix (#2464)\nspl: Remove the metadata::create_metadata_account_v2 deprecated wrapper\nsince it was removed from token metadata program\n(#2480)\n\n[0.27.0] - 2023-03-08\nFeatures\n\nspl: Add MasterEditionAccount account deserialization to spl metadata\n(#2393).\nlang: Add the InitSpace derive macro to automatically calculate the space at\nthe initialization of an account\n(#2346).\ncli: Add env option to verifiable builds\n(#2325).\ncli: Add idl close command to close a program's IDL account\n(#2329).\ncli: idl init now supports very large IDL files\n(#2329).\nspl: Add transfer_checked function\n(#2353).\nspl: Add approve_checked function\n(#2401).\ncli: Add --skip-build option to the verify command\n(#2387).\nclient: Add support for multithreading to the rust client: use flag\n--multithreaded (#2321).\nclient: Add async_rpc a method which returns a nonblocking solana rpc client\n(#2322).\navm, cli: Use the rustls-tls feature of reqwest so that users don't need\nOpenSSL installed (#2385).\nts: Add VersionedTransaction support. Methods in the Provider class and\nWallet interface now use the argument\ntx: Transaction | VersionedTransaction\n(#2427).\ncli: Add --arch sbf option to compile programs using cargo build-sbf\n(#2398).\nland: Support multiple programs with the same interface using Interface and\nInterfaceAccount types, related to token-2022\n(#2386).\n\nFixes\n\nts: Make the return type of AccountClient.fetchMultiple match the account\ntype being fetched (#2390)\ncli: Don't regenerate idl in read_all_programs().\n(#2332).\nts: provider.simulate will send the transaction with sigVerify: false if\nno signers are present\n(#2331).\ncli: Failing commands will return the correct exit status.\n(#2370).\nidl: Update the IDL program to use non-deprecated account types\n(#2365).\nts: Enum fields weren't being converted from snake_case to camelCase\n(#2378).\nlang/cli: Update to solana-program version 1.14.16 and rust version 1.60,\nappears to still be incompatible with 1.15 CLI\n(#2420).\n\nBreaking\n\nlang: Remove deprecated account types: CpiAccount, Loader and\nProgramAccount (#2375).\nlang: Remove state and interface attributes\n(#2285).\nlang: Remove deprecated literal constraint which has been replaced by\n#[account(constraint = {})]\n(#2379).\nlang: account(zero_copy) and zero_copy attributes now derive the\nbytemuck::Pod and bytemuck::Zeroable traits instead of using unsafe impl\n(#2330). This imposes useful\nrestrictions on the type, like not having padding bytes and all fields being\nPod themselves. See\nbytemuck::Pod for\ndetails. This change requires adding\nbytemuck = { version = \"1.4.0\", features = [\"derive\", \"min_const_generics\"]}\nto your cargo.toml. Legacy applications can still use\n#[account(zero_copy(unsafe))] and #[zero_copy(unsafe)] for the old\nbehavior.\nts: Remove createProgramAddressSync, findProgramAddressSync (now available\nin @solana/web3.js) and update associatedAddress to be synchronous\n(#2357).\n\n[0.26.0] - 2022-12-15\nFeatures\n\ncli: Add --run to anchor test for running a subset of test suites\n(#1828).\nclient: Add transaction functions to RequestBuilder\n(#1958).\nspl: Add create_metadata_accounts_v3 and set_collection_size wrappers\n(#2119).\nspl: Add MetadataAccount account deserialization.\n(#2014).\nspl: Add update_primary_sale_happened_via_token wrapper\n(#2173).\nspl: Add sign_metadata and remove_creator_verification wrappers\n(#2175).\nspl: Add initialize_account3 and initialize_mint2\n(#2265).\nspl: Change serum-dex to openbook-dex\n(#2308).\nlang: Add parsing for consts from impl blocks for IDL PDA seeds generation\n(#2128).\nlang: Account closing reassigns to system program and reallocates\n(#2169).\nts: Add coders for SPL programs\n(#2143).\nts: Add has_one relations inference so accounts mapped via has_one\nrelationships no longer need to be provided\n(#2160).\nts: Add ability to set args after setting accounts and retrieving pubkeys\n(#2160).\nts: Add .prepare() to builder pattern\n(#2160).\nspl: Add freeze_delegated_account and thaw_delegated_account wrappers\n(#2164).\nts: Add feePayer check to AnchorProvider methods, so that anchor writes\nthe provider's wallet as fee payer if fee payer isn't already set\n(#2186).\nts: Add nested PDA inference\n(#2194).\nts: Add ability to resolve missing accounts with a custom resolver\n(#2194).\nts: Update the Solana web3 library used by anchor ts to version 1.64.0\n(#2220).\nlang: Updates AccountsClose to make it safe to call manually\n(#2209).\nlang: Update rust used in the repo version 1.62\n(#2272).\ncli: Allow custom cluster config\n(#2271).\nts: Add optional flag to parseLogs to throw an error on decoding failure\n(#2043).\ncli: Add test.validator.geyser_plugin_config support\n(#2016).\ncli: Add account subcommand to cli\n(#1923)\ncli: Add ticks_per_slot option to Validator args\n(#1875).\n\nFixes\n\nlang: Fix parsing for bytes literals in the IDL\n(#2261).\nlang: Fix IDL seed generation for byte string literals\n(#2125).\nts: Update seeds inference to allow nested user defined structs within the\nseeds (#2198).\nevent: Fix multiple event listeners with the same name\n(#2165).\nlang: Prevent the payer account from being initialized as a program account\n(#2284).\nts: Fixing breaking change where null or undefined wallet throws an error\n(#2303).\nts: Fixed .fetchNullable() to be robust towards accounts only holding a\nbalance (#2301).\nlang: Only add public enums to the IDL\n(#2309).\nlang: Fix heap intensive error mapping\n(#2313).\n\nBreaking\n\nts: SPL coders have been removed from the main Anchor package.\n(#2155)\nlang: Remove rent from constraints\n(#2265).\nspl: Remove rent from associated_token::Create\n(#2265).\nlang: Add Discriminator and Owner trait implementation for structures\nrepresenting instructions\n(#1997).\nts: '@coral-xyz/borsh' package is now part of the yarn monorepo\n(#2290). The borsh package\nneeds to be built before the anchor package can be built but this should\nhappen automatically when running yarn build in packages/anchor, see\n#2299 and\n#2306.\nlang: Add support for optionally passing in accounts using the syntax\nOptional<Account<'info, T>>. Shouldn't affect existing programs but may be a\nbreaking change to tools that use the anchor generated IDL.\n#2101.\nts: Switch from @project-serum/anchor to the @coral-xyz/anchor package\n#2318.\n\n[0.25.0] - 2022-07-05\nFeatures\n\nlang: Add realloc, realloc::payer, and realloc::zero as a new constraint\ngroup for program accounts\n(#1986).\nlang: Add PartialEq and Eq for anchor_lang::Error\n(#1544).\ncli: Add --skip-build to anchor publish\n(#1786).\ncli: Add --program-keypair to anchor deploy\n(#1786).\ncli: Add compilation optimizations to cli template\n(#1807).\ncli: build now adds docs to idl. This can be turned off with --no-docs\n(#1561).\ncli: Add b and t aliases for build and test respectively\n(#1823).\nspl: Add more derived traits to TokenAccount to Mint\n(#1818).\nspl: Add sync_native token program CPI wrapper function\n(#1833).\ncli: Allow passing arguments to an underlying script with anchor run\n(#1914).\nts: Implement a coder for system program\n(#1920).\nts: Add program.coder.types for encoding/decoding user-defined types\n(#1931).\nclient: Add send_with_spinner_and_config function to RequestBuilder\n(#1926).\nts: Implement a coder for SPL associated token program\n(#1939).\nts: verbose error for missing ANCHOR_WALLET variable when using\nNodeWallet.local() (#1958).\nts: Add MethodsBuilder#accountsStrict for strict typing on ix account input\n(#2019).\nUpdate solana dependencies to 1.10.29\n(#2027).\n\nFixes\n\ncli: Fix anchor keys list reading the target folder in the wrong path\n(#2063).\ncli: Move overflow-checks into workspace Cargo.toml so that it will not be\nignored by compiler (#1806).\nlang: Fix missing account name information when deserialization fails when\nusing init or zero\n(#1800).\nts: Expose the wallet's publickey on the Provider\n(#1845).\n\nBreaking\n\nts: Change BROWSER env variable to ANCHOR_BROWSER\n(#1233).\nts: Add transaction signature to EventCallback parameters\n(#1851).\nts: Change EventParser#parseLogs implementation to be a generator instead of\ncallback function (#2018).\nlang: Adds a new &mut reallocs: BTreeSet<Pubkey> argument to\nAccounts::try_accounts\n(#1986).\n\n[0.24.2] - 2022-04-13\nFixes\n\nlang: Fix returns being serialized as null instead of undefined in IDL\n(#1782).\n\n[0.24.1] - 2022-04-12\nFixes\n\nlang: Fix anchor build failing if Test.toml included a relative path that\ndidn't exist yet because it's created by anchor build\n(#1772).\ncli: Update js/ts template to use new AnchorProvider class\n(#1770).\n\n[0.24.0] - 2022-04-12\nFeatures\n\nlang: Add support for multiple test suites with separate local validators\n(#1681).\nlang: Add return values to CPI client\n(#1598).\nts: Add view functions\n(#1695).\navm: New avm update command to update the Anchor CLI to the latest version\n(#1670).\ncli: Update js/ts templates to use new program.methods syntax\n(#1732).\ncli: Workspaces created with anchor init now come with the prettier\nformatter and scripts included\n(#1741).\nts: Add pubkeys function to methods builder to get all instruction account\naddresses (#1733).\nts: Export LangErrorCode and LangErrorMessage from error.ts\n(#1756).\n\nFixes\n\navm: avm install no longer downloads the version if already installed in the\nmachine (#1670).\ncli: make anchor test fail when used with --skip-deploy option and without\n--skip-local-validator option but there already is a running validator\n(#1675).\nlang: Return proper error instead of panicking if account length is smaller\nthan discriminator in functions of (Account)Loader\n(#1678).\ncli: Add @types/bn.js to devDependencies in cli template\n(#1712).\nts: Event listener no longer crashes on Program Upgrade or any other\nunexpected log (#1757).\n\nBreaking\n\navm: avm install switches to the newly installed version after installation\nfinishes (#1670).\nspl: Re-export the spl_token crate\n(#1665).\nlang, cli, spl: Update solana toolchain to v1.9.13\n(#1653 and\n#1751).\nlang: Program type now deserializes programdata_address only on demand\n(#1723).\nts: Make Provider an interface and adjust its signatures and add\nAnchorProvider implementor class\n(#1707).\nspl: Change \"to\" to \"from\" in token::burn\n(#1080).\n\n[0.23.0] - 2022-03-20\nFeatures\n\ncli: Add anchor clean command that's the same as cargo clean but preserves\nkeypairs inside target/deploy\n(#1470).\ncli: Running anchor init now initializes a new git repository for the\nworkspace. This can be disabled with the --no-git flag\n(#1605).\ncli: Add support for anchor idl fetch to work outside anchor workspace\n(#1509).\ncli: [[test.validator.clone]] also clones the program data account of programs\nowned by the bpf upgradeable loader\n(#1481).\nlang: Add new AccountSysvarMismatch error code and test cases for sysvars\n(#1535).\nlang: Replace std::io::Cursor with a custom Write impl that uses the\nSolana mem syscalls (#1589).\nlang: Add require_neq, require_keys_neq, require_gt, and require_gte\ncomparison macros (#1622).\nlang: Handle arrays with const as size in instruction data\n(#1623.\nspl: Add support for revoke instruction\n(#1493).\nts: Add provider parameter to Spl.token factory method\n(#1597).\n\nFixes\n\nts: Fix the loss of strict typing using the methods namespace on builder\nfunctions (#1539).\nspl: Update spl/governance to use new errors\n(#1582).\nclient: Fix Cluster's FromStr implementation\n(#1362).\nlang: Implement Key for Pubkey again, so associated_token::* constraints\ncan use pubkey targets again\n(#1601).\nlang: Adjust error code so #[error_code] works with just importing\nanchor_lang::error_code\n(#1610).\nts: Fix spl-token coder account parsing\n(#1604).\ncli: Fix npm install fallback if yarn install doesn't work\n(#1643).\nlang: Fix bug where owner = <target> would not compile because of missing\ntype annotation (#1648).\nts: Adjust send and simulate functions in provider.ts, so they use the\nreturn value of\nWallet.signTransaction(#1527).\n\nBreaking\n\nts: Mark transaction, instruction, simulate and rpc program namespaces\nas deprecated in favor of methods\n(#1539).\nts: No longer allow manual setting of globally resolvable program public keys\nin methods#accounts().\n([#1548][https://github.com/solana-foundation/anchor/pull/1548])\nlang/ts: Events are now emitted using the sol_log_data syscall\n(#1608).\nlang: Remove space calculation using #[derive(Default)]\n(#1519).\nlang: Add support for logging expected and actual values and pubkeys. Add\nrequire_eq and require_keys_eq macros. Add default error code to require\nmacro (#1572).\nlang: Add system_program CPI wrapper functions. Make system_program module\npublic instead of re-exporting\nsystem_program::System(#1629).\ncli: avm use no long prompts [y/n] if an install is needed first - it just\ntells the user to avm install\n(#1565)\nts: Add AnchorError with program stack and also a program stack for\nnon-AnchorError errors\n(#1640). AnchorError is not\nreturned for processed tx that have skipPreflight set to true (it falls\nback to ProgramError or the raw solana library error).\n\n[0.22.1] - 2022-02-28\nFixes\n\ncli: Fix rust template\n(#1488).\nlang: Handle array sizes with variable sizes in events and array size casting\nin IDL parsing (#1485)\n\n[0.22.0] - 2022-02-20\nFeatures\n\nlang: Add check that declared id == program id\n(#1451).\nts: Added float types support\n(#1425).\ncli: Add --skip-lint option to disable check linting introduced in\n(#1452) for rapid prototyping\n(#1482).\n\nFixes\n\nts: Allow nullable types for Option<T> mapped types\n(#1428).\n\nBreaking\n\nlang: Enforce that the payer for an init-ed account be marked mut\n(#1271).\nlang: All error-related code is now in the error module\n(#1426).\nlang: Require doc comments when using AccountInfo or UncheckedAccount types\n(#1452).\nlang: add\nerror!\nand\nerr!\nmacro and Result type\n(#1462). This change will\nbreak most programs. Do the following to upgrade: _ change all\nProgramResult's to Result<()> _ change #[error] to #[error_code] _\nchange all Err(MyError::SomeError.into()) to\nErr(error!(MyError::SomeError)) and all\nErr(ProgramError::SomeProgramError) to\nErr(ProgramError::SomeProgramError.into()) or\nErr(Error::from(ProgramError::SomeProgramError).with_source(source!())) to\nprovide file and line source of the error (with_source is most useful with\nProgramErrors. error! already adds source information for custom and\nanchor internal errors). _ change all solana_program::program::invoke() to\nsolana_program::program::invoke().map_err(Into::into) and\nsolana_program::program::invoke_signed() to\nsolana_program::program::invoke_signed().map_err(Into::into)\n\n[0.21.0] - 2022-02-07\nFixes\n\nts: Fix the root type declaration of the Wallet / NodeWallet class\n(#1363).\nts: Improve type mapping of Account fields into Typescript with additional\nsupport for Option<T> and Vec<String> types\n(#1393).\n\nFeatures\n\nlang: Add seeds::program constraint for specifying which program_id to use\nwhen deriving PDAs (#1197).\nlang: Context now has a new bumps: BTree<String, u8> argument, mapping\naccount name to bump seed \"found\" by the accounts context. This allows one to\naccess bump seeds without having to pass them in from the client or\nrecalculate them in the handler\n(#1367).\nlang, ts: Automatically infer PDA addresses\n(#1331).\nts: Remove error logging in the event parser when log websocket encounters a\nprogram error (#1313).\nts: Add new methods namespace to the program client, introducing a more\nergonomic builder API\n(#1324).\nts: Add registry utility for fetching the latest verified build\n(#1371).\ncli: Expose the solana-test-validator --account flag in Anchor.toml via\n[[test.validator.account]]\n(#1366).\ncli: Add avm, a tool for managing anchor-cli versions\n(#1385).\n\nBreaking\n\nlang: Put init_if_needed behind a feature flag to decrease wrong usage\n(#1258).\nlang: rename loader_account module to account_loader module\n(#1279)\nlang: The Accounts trait's try_accounts method now has an additional\nbumps: &mut BTreeMap<String, u8> argument, which accumulates bump seeds\n(#1367).\nlang: Providing bump = <target> targets with init will now error. On\ninit only, it is required to use bump without a target and access the seed\ninside function handlers via ctx.bumps.get(\"<pda-account-name\"). For\nsubsequent seeds constraints (without init), it is recommended to store the\nbump on your account and use it as a bump = <target> target to minimize\ncompute units used (#1380).\nts: Coder is now an interface and the existing class has been renamed to\nBorshCoder. This change allows the generation of Anchor clients for non\nanchor programs\n(#1259).\ncli: [[test.clone]] key in Anchor.toml is renamed to [[test.validator.clone]]\n(#1366).\n\n[0.20.1] - 2022-01-09\nFixes\n\nlang: Improved error msgs when required programs are missing when using the\ninit constraint(#1257)\n\nFeatures\n\nlang: Allow repr overrides for zero copy accounts\n(#1273).\n\n[0.20.0] - 2022-01-06\nFixes\n\nlang: init_if_needed now checks rent exemption when init is not needed\n(#1250).\nlang: Add missing owner check when associated_token::authority is used\n(#1240).\nts: Add type declarations for conditional workspace and Wallet exports\n(#1137).\nts: Change commitment message recent to processed and max to finalized\n(#1128)\nts: fix translateAddress which currently leads to failing browser code. Now\nuses PublicKey constructor instead of prototype chain constructor name\nchecking which doesn't work in the presence of code\nminifying/mangling(#1138)\nlang: add missing check that verifies that account is ATA when using\ninit_if_needed and init is not\nneeded(#1221)\n\nFeatures\n\nlang: Add programdata_address: Option<Pubkey> field to Program account.\nWill be populated if account is a program owned by the upgradable bpf loader\n(#1125)\nlang,ts,ci,cli,docs: update solana toolchain to version\n1.8.5(#1133).\nlang: Account wrappers for non-Anchor programs no longer have to implement the\nserialize function because it has a default impl now. Similarly, they no\nlonger have to implement try_deserialize which now delegates to\ntry_deserialize_unchecked by\ndefault(#1156).\nlang: Add set_inner method to Account<'a, T> to enable easy updates\n(#1177).\nlang: Handle arrays with const as length\n(#968).\nts: Add optional commitment argument to fetch and fetchMultiple\n(#1171).\nlang: Implement AsRef<T> for\nAccount<'a, T>(#1173)\ncli: Add anchor expand command which wraps around cargo expand\n(#1160)\n\nBreaking\n\nclient: Client::new and Client::new_with_options now accept Rc<dyn Signer>\ninstead of Keypair (#975).\nlang, ts: Change error enum name and message for 'wrong program ownership'\naccount validation (#1154).\nlang: Change from #[repr(packed)] to #[repr(C)] for zero copy accounts\n(#1106).\nlang: Account types can now be found either in the prelude module or the\naccounts module but not longer directly under the root. Deprecated account\ntypes are no longer imported by the prelude\n(#1208).\n\n[0.19.0] - 2021-12-08\nFixes\n\nlang: Add deprecated attribute to ProgramAccount\n(#1014).\ncli: Add version number from programs Cargo.toml into extracted IDL\n(#1061).\nlang: Add deprecated attribute to\nLoader(#1078).\nlang: the init_if_needed attribute now checks that given attributes (e.g.\nspace, owner, token::authority etc.) are validated even when init is not\nneeded (#1096).\n\nFeatures\n\nlang: Add ErrorCode::AccountNotInitialized error to separate the situation\nwhen the account has the wrong owner from when it does not exist\n(#1024).\nlang: Called instructions now log their name by default. This can be turned\noff with the no-log-ix-name flag\n(#1057).\nlang: ProgramData and UpgradableLoaderState can now be passed into\nAccount as generics. see\nUpgradeableLoaderState.\nUpgradableLoaderState can also be matched on to get ProgramData, but when\nProgramData is used instead, anchor does the serialization and checking that\nit is actually program data for you\n(#1095).\nts: Add better error msgs in the ts client if something wrong (i.e. not a\npubkey or a string) is passed in as an account in an instruction accounts\nobject (#1098).\nts: Add inputs postInstructions and preInstructions as a replacement for\n(the now deprecated) instructions\n(#1007).\nts: Add getAccountInfo helper method to account namespace/client\n(#1084).\n\nBreaking\n\nlang, ts: Error codes have been mapped to new numbers to allow for more errors\nper namespace (#1096).\n\n[0.18.2] - 2021-11-14\n\ncli: Replace global JavaScript dependency installs with local.\n\nFeatures\n\nlang: Add SystemAccount<'info> account type for generic wallet addresses or\naccounts owned by the system program\n(#954)\n\nFixes\n\ncli: fix dns in NODE_OPTIONS\n(#928).\ncli: output TypeScript IDL in idl parse subcommand\n(#941).\ncli: Add fields os and cpu to npm package @project-serum/anchor-cli\n(#976).\ncli: Allow specify output directory for TypeScript IDL\n(#940).\n\nBreaking\n\nspl: Move permissioned markets into dex repository\n(#962).\n\n[0.18.0] - 2021-10-24\nFeatures\n\ncli: Add support for configuration options for solana-test-validator in\nAnchor.toml (#834).\ncli: target/types directory now created on build to store a TypeScript types\nfile for each program's IDL\n(#795).\nts: Program<T> can now be typed with an IDL type\n(#795).\nlang: Add mint::freeze_authority keyword for mint initialization within\n#[derive(Accounts)] (#835).\nlang: Add AccountLoader type for zero_copy accounts with support for CPI\n(#792).\nlang: Add #[account(init_if_needed)] keyword for allowing one to invoke the\nsame instruction even if the account was created already\n(#906).\nlang: Add custom errors support for raw constraints\n(#905).\nlang, cli, spl: Update solana toolchain to v1.8.0\n(#886).\nlang: Add custom errors support for signer, mut, has_one, owner, raw\nconstraints and address\n(#905,\n#913).\n\nBreaking\n\nlang: Accounts marked with the #[account(signer)] constraint now enforce\nsigner when the \"cpi\" feature is enabled\n(#849).\n\n[0.17.0] - 2021-10-03\nFeatures\n\ncli: Add localnet command for starting a local solana-test-validator with\nthe workspace deployed (#820).\n\nBreaking\n\nCpiContext accounts must now be used with the accounts struct generated in\nthe crate::cpi::accounts::* module. These structs correspond to the accounts\ncontext for each instruction, except that each field is of type AccountInfo\n(#824).\n\n[0.16.2] - 2021-09-27\nFeatures\n\nlang: Add --detach flag to anchor test\n(#770).\nlang: Add associated_token keyword for initializing associated token\naccounts within #[derive(Accounts)]\n(#790).\ncli: Allow passing through cargo flags for build command\n(#719).\ncli: Allow passing through cargo flags for test, verify, and publish commands\n(#804).\n\nFixes\n\nlang: Generated AccountMetas for Rust clients now properly set the\nisSigner field (#762).\n\n[0.16.1] - 2021-09-17\nFixes\n\nlang: Signer type now sets isSigner to true in the IDL\n(#750).\n\n[0.16.0] - 2021-09-16\nFeatures\n\nlang: Program type introduced for executable accounts\n(#705).\nlang: Signer type introduced for signing accounts where data is not used\n(#705).\nlang: UncheckedAccount type ","tokens":15000,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258727995,"hash":"12462934488fa571696f79768e019fed672c19fc"}
{"url":"https://aave.com/docs/aave-v3/overview","domain":"aave.com","title":"Aave V3 Overview | Aave Protocol Documentation","text":"Aave v3#\n\nAave v3 is a non-custodial liquidity protocol on Ethereum and other major networks. It provides onchain infrastructure to integrate supply and borrow into applications via battle-tested smart contracts and AaveKit.\nDevelopers can use AaveKit React, AaveKit TypeScript, or AaveKit API to integrate core protocol operations and data for wallets, exchanges, fintech platforms, and DeFi-native products.\nSupply#\n\nSupplying assets to Aave lets users earn interest and, optionally, use supplied tokens as collateral for borrowing. When an asset is supplied, aTokens (e.g., aUSDC, aWETH) are minted as interest-bearing ERC-20 tokens whose balance increases over time from borrowing activity in the pool.\nWithdrawing redeems aTokens for the underlying asset, including accrued interest, subject to available unborrowed liquidity and the collateralization of any active borrow positions.\nBorrow#\n\nBorrowing lets users access liquidity by posting supplied assets as collateral. Positions are always over-collateralized, meaning the collateral value must exceed the borrowed amount. Risk is tracked with a Health Factor and per-reserve liquidation thresholds; when the Health Factor drops below the threshold, collateral can be liquidated. When a user borrows, their debt is represented by variableDebtTokens (e.g., variableDebtUSDC), ERC-20 tokens that track the outstanding borrow balance and accrue interest over time.\nBorrowers can repay at any time, and positions remain open as long as over-collateralization is maintained. The Health Factor moves with collateral and debt values (prices from oracles and accrued interest). When it falls below 1, the position becomes eligible for liquidation and external liquidators can repay part of the debt in exchange for collateral.\nInterest Rates#\nInterest rates adjust with utilization. v3 uses an interest rate model based on two slopes with an optimal utilization point: below the optimal point, borrow rates rise with the first slope; above it, they rise faster with the second slope.\nSupplier yields are funded by borrower interest net of the reserve factor.\nLiquidations#\nPositions become eligible for liquidation when a position's Health Factor falls below 1. A liquidator repays part of the debt and receives collateral at a discount (liquidation bonus). Liquidation threshold and bonus are defined per reserve and surfaced via onchain views.\nAave Earn Vaults#\n\nAave Earn Vaults are ERC-4626 compliant yield-bearing vaults that enable Aave supply positions to be managed with customizable ownership and fee structure. By depositing supported tokens, users receive vault shares that represent their proportional claim on the underlying assets and any yield earned. Shares can be withdrawn at any time for the underlying assets plus accrued yield subject to available liquidity, providing a simple and efficient way to grow holdings.\nFor vault managers, Aave Earn Vaults offer a customizable framework to deploy and manage yield strategies while earning fees on the yield generated by user deposits. The standardized ERC-4626 interface provides compatibility with a wide range of DeFi protocols and applications, making it easy to integrate vaults into broader strategies or platforms. This structure benefits both users seeking passive income and managers looking to build scalable, revenue-generating products on Aave. See the Vaults Overview for guides to deploy and manage instances of Aave Earn Vaults.\nAave v3 Key Features#\nAave v3 introduces significant enhancements over previous protocol iterations, focusing on improving capital efficiency, mitigating risk, and establishing Aave as a leading liquidity protocol across 14+ blockchain networks.\nEfficiency Mode (E-Mode)#\nEfficiency Mode maximizes capital efficiency for correlated assets. When a user supplies and borrows assets within the same E-Mode category (e.g., USD-pegged stablecoins), they benefit from a higher loan-to-value (LTV) ratio. This enables low-slippage, high-leverage strategies like yield farming with staked ETH derivatives or efficient forex trading.\nIsolation Mode#\nIsolation Mode allows for the secure listing of new or more volatile assets without introducing systemic risk to the entire protocol. When an asset is listed in Isolation Mode, it can be used as collateral to borrow only a specific basket of assets (typically stablecoins), up to a designated debt ceiling. This contains risk while expanding the number of supported assets.\nView debt ceiling and borrowable in isolation mode parameters on the\nparameter dashboard.\n\nSiloed Borrowing#\nSiloed borrowing is a reserve-level flag that restricts users who borrow a given asset to borrowing only that asset, preventing them from having any other active borrows in the same pool.\nView debt ceiling and siloed assets parameters on the parameter\ndashboard.\nNext Steps#\nLearn how to interact with Aave Markets.Learn how to interact with Aave Earn Vaults.PreviousReact HooksNextConcepts","tokens":1244,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258733000,"hash":"bfd3830400ee4cbabea96999c1307e94ee75b89a"}
{"url":"https://docs.openzeppelin.com/community-contracts","domain":"docs.openzeppelin.com","title":"Community Contracts | OpenZeppelin Docs","text":"Community ContractsOpen in ClaudeA community-driven extension of our Solidity library: the gold-standard of smart contract development. This library includes:\n\nExtensions and modules compatible with contracts in the original package\nAlternative implementation of interfaces defined in the original package\nContracts with third-party integrations\nContracts built by community members, that align with OpenZeppelin offerings\nGeneral prototypes and experiments\n\nCode is provided by the OpenZeppelin Contracts team, as well as by community contributors, for other developers to review, discuss, iterate on, and potentially use.\nOverview\nInstallation\nGiven this extension is intended for more experimental use cases and therefore the development process is more flexible. For such reason, the library can only be installed with Foundry using gitmodules.\nFoundry (git)\n$ forge install OpenZeppelin/openzeppelin-community-contracts\nMake sure to add @openzeppelin/community-contracts/=lib/openzeppelin-community-contracts/contracts/ in remappings.txt.\nUsage\nOnce installed, you can use the contracts in the library by importing them:\n// contracts/MyStablecoinAllowlist.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.22;\n\nimport {AccessManaged} from \"@openzeppelin/contracts/access/manager/AccessManaged.sol\";\nimport {ERC20Allowlist, ERC20} from \"@openzeppelin/community-contracts/token/ERC20/extensions/ERC20Allowlist.sol\";\n\ncontract MyStablecoinAllowlist is ERC20Allowlist, AccessManaged {\n constructor(address initialAuthority) ERC20(\"MyStablecoin\", \"MST\") AccessManaged(initialAuthority) {}\n\n function allowUser(address user) public restricted {\n _allowUser(user);\n }\n\n function disallowUser(address user) public restricted {\n _disallowUser(user);\n }\n}\nTo keep your system secure, you should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself. The library is designed so that only the contracts and functions you use are deployed, so you don’t need to worry about it needlessly increasing gas costs.\nSecurity\nContracts in the community library are provided as is, with no particular guarantees. Given changes in this repository are more frequent, the code is not formally audited and not covered by the bug bounty program on Immunefi.\nSimilarly, the code has no backward compatibility guarantees.\nWe kindly ask to report any issue directly to our security contact. The team will do its best to assist and mitigate any potential misuses of the library. However, keep in mind the flexibility assumed for this repository may relax our assessment.UtilitiesPrevious PageModulesNext PageOn this pageOverviewInstallationFoundry (git)UsageSecurity","tokens":675,"squid":"ink-security_audits","role":"Sentinel","at":1791258734504,"hash":"ca930daa69dd5cd560dfa15e7bc7ed1bf401b55e"}
{"url":"https://aave.com/docs/aave-v3/concepts/reserve","domain":"aave.com","title":"Reserve | Aave Protocol Documentation","text":"Reserve#\n\nA reserve is an instance of a token within an Aave liquidity\npool. Each reserve is governed by a set of parameters that\nmanage risk and optimise liquidity. These parameters can vary across different\nmarkets, even for the same underlying token, allowing Aave to adapt to various\nnetwork and pool conditions.\nKey Reserve Parameters#\nLoan-to-Value (LTV): The maximum amount that can be borrowed relative to the collateral’s value. For example, a 75% LTV allows borrowing 75% of the collateral’s value. An asset with an LTV of 0% cannot be enabled as collateral.Liquidation Threshold: Defines the point at which a position becomes at risk of liquidation. If the threshold is exceeded, the position could be liquidated to repay the borrower's debt.Borrowing Enabled: Determines whether liquidity of a reserve can be borrowed.Caps: Supply and Borrow caps limit the total amount of a token that can be supplied and borrowed from a reserve. These caps are crucial for maintaining liquidity and preventing overexposure during volatile market conditions​.Interest Rate Model: Interest rates in Aave adjust dynamically based on the utilisation of the liquidity pool. As more liquidity is borrowed, interest rates rise to reflect the reduced availability of assets, creating conditions that enough liquidity remains for withdrawals and liquidations. The rates are controlled by parameters that set the base rate and slopes for utilisation​.\nDynamic Parameters and Governance#\nThe parameters for each reserve are not fixed; they vary between markets and can change over time as Aave Governance monitors market conditions and adjusts settings accordingly. For example, the same underlying token, such as ETH, might have different LTVs or interest rates in Ethereum versus Polygon markets. These adjustments are made to optimise liquidity and risk management for each market. Governance proposals allow the community to vote on changes, such as raising borrow caps or adjusting LTVs, enabling reserves to remain aligned with current market dynamics.PreviousLiquidity PoolNextIncentives","tokens":520,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258744127,"hash":"3e3889dccaaefd215de507e483363056067499eb"}
{"url":"https://forum.openzeppelin.com/","domain":"forum.openzeppelin.com","title":"OpenZeppelin Forum - OpenZeppelin Community Forum","text":"All categories\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Top\n\n Category\n Topics\n\n General\n\n Get to know the OpenZeppelin community and learn about upcoming events.\n\n Announcements\n\n Events\n\n Meta\n\n 1.0k\n\n Support\n\n Ask for help and guidance about OpenZeppelin libraries and tools.\n\n Defender\n\n Contracts\n\n Upgrades\n\n 5.4k\n\n Smart Contracts\n\n Ask for help with smart contract development and discuss related topics. NOTE: If you want help from OpenZeppelin staff, post in #Support!\n\n Guides and Tutorials\n\n Showcase\n\n Developer Wanted\n\n Review Wanted\n\n 3.7k\n\n Security\n\n Discuss about smart contract security patterns, vulnerabilities, hacks and best practices.\n\n Ethernaut\n\n 234\n\n Archive\n\n The Archive category provides read only access to archived categories/sub-categories\n\n SDK\n\n Starter Kits - Support\n\n 420\n\n Latest\n\n How to verify a contract on Etherscan/BscScan/PolygonScan\n\n Guides and Tutorialsetherscan-verify,hide-post-links\n\n 73\n\n Jun 2025\n\n Welcome to the OpenZeppelin Community!\n\n General\n\n 0\n\n Oct 2020\n\n Deploying BSC Smart Contract & Token Generation\n\n Support\n\n 7\n\n 12h\n\n 0.1% transfer tax on an ERC-20 token with 0 decimals?\n\n Smart Contractserc20\n\n 0\n\n 4d\n\n ERC-20 token logo and project URL not showing on PulseChain Explorer\n\n Smart Contracts\n\n 0\n\n 7d\n\n Mitigating Inflation Attacks on an ERC-4626 Freelance Escrow Vault Routing Idle Capital to Aave v3\n\n Smart Contractserc20,etherscan-verify,solidity\n\n 0\n\n 18d\n\n Example/Tutorial for migrating data from prev version to next version of a smart contract\n\n Smart Contractsupgrades,dev-update\n\n 0\n\n Sep 1\n\n What is a sufficient test suite to rely on a contract’s upgradeability status?\n\n Smart Contractsupgrades\n\n 1\n\n Sep 1\n\n Can you create a BEP20 contract for small fee?\n\n Developer Wantedbep20\n\n 9\n\n Aug 2\n\n More","tokens":447,"squid":"ink-security_audits","role":"Sentinel","at":1791258748557,"hash":"49f3db39f3ec8ef8bbca71a57ae40fa463d67d2a"}
{"url":"https://www.anchor-lang.com/docs/updates/backport-workflow","domain":"anchor-lang.com","title":"Backport Workflow","text":"Anchor Project UpdatesBackport WorkflowAnchor - Lightweight Backport Workflow GuideA backport is the process of taking a change made on master (or a newer branch)\nand applying it to older, still-supported release branches. This allows\nmaintaining multiple release versions in parallel for users who cannot\nimmediately upgrade to the latest release.\nIn this guide, a still-supported release branch is one that maintainers have\nexplicitly designated for ongoing maintenance and patch releases. Confirm the\ncurrent set of supported branches with a maintainer before proposing a\nbackport; this guide does not imply that every historical release branch is\nsupported.\n\nWhen to Backport\nBackport the following types of changes:\n\nSecurity fixes affecting multiple supported versions\nBug fixes that resolve user-facing issues\nCritical documentation or configuration updates\nLow-risk performance improvements (occasionally)\n\nNot backported: experimental features, breaking changes, or large refactors.\nAll changes should first be merged to master before being backported.\n\nWorkflow\n1. Identify and Label\nAll pull requests to master should be labeled during review to indicate whether\nthey are backportable.\nLabeling Convention:\n\nFormat: backport-X.Y where X.Y is the target release version\nExamples: backport-0.30, backport-0.29, backport-0.28\nApply multiple labels if backporting to several versions\n\nDuring PR review or immediately after merge, maintainers decide if the change\nshould be applied to older release branches and add the appropriate labels.\n2. Create Backport PR\nAutomated Backport (Recommended)\nA GitHub Action or bot automatically cherry-picks commits when it detects a\nbackport-X.Y label on merged PRs. If conflicts occur, it notifies maintainers\nto handle manually.\nManual Cherry-Pick\n# Fetch latest changes\ngit fetch origin\n\n# Create backport branch from target release\ngit checkout -b backport-1234-to-0.30 origin/0.30\n\n# Cherry-pick the commit(s)\ngit cherry-pick <commit-sha>\n\n# If multiple related commits\ngit cherry-pick <commit-sha-1> <commit-sha-2>\n\n# If conflicts occur, resolve them\ngit status # Check conflicted files\n# Edit files to resolve conflicts\ngit add <resolved-files>\ngit cherry-pick --continue\n\n# Push the backport branch\ngit push origin backport-1234-to-0.30\nBranch naming: backport-<issue-number>-to-<target-version>\nPR title: [Backport 0.30] Original PR Title\n3. Review & Merge\nThe backport PR should be reviewed with particular focus on:\n\nCorrectness: Verify the fix works with the older codebase\nNo feature creep: Ensure only the necessary fix is included\nDependencies: Avoid unintended dependency bumps or incompatibilities\nTests: All CI checks must pass on the target branch\nBreaking changes: Ensure no breaking changes are introduced\n\nOnce approved, merge into the release branch using the same merge strategy as\nthe original PR.\n4. Release Management\nBackports accumulate on release branches and are included in patch releases\n(e.g., v0.30.3). Critical security fixes may trigger immediate releases.\nUpdate the CHANGELOG and communicate which versions received which fixes.\nAfter shipping a backported release, merge any release-specific documentation and\nCHANGELOG updates back into master so that the deployed documentation also reflects\nthe latest published release.\n\nExamples\nExample 1: Automated Security Fix Backport\nA security vulnerability is discovered in account validation:\n\nFix developed: PR #1234 opened on master\nMerged: PR merged with commit abc123\nLabeled: Maintainer adds backport-0.30 and backport-0.29\nBot action: Automated backport PRs created for both versions\nReview: Maintainers review for correctness on older branches\nMerge: Both backport PRs merged\nRelease: Included in next v0.30.3 and v0.29.5 patch releases\n\nExample 2: Manual Backport with Conflicts\nBug fix in IDL generation needs backporting to v0.30.x:\n# Original PR #5678 merged to master with commit def456\ngit fetch origin\ngit checkout -b backport-5678-to-0.30 origin/0.30\ngit cherry-pick def456\n\n# Conflicts occur due to code differences\n# CONFLICT (content): Merge conflict in idl/src/build.rs\n\n# Resolve conflicts\nvim idl/src/build.rs # Edit to resolve\ngit add idl/src/build.rs\ngit cherry-pick --continue\n\n# Test the changes\ncargo test --package anchor-idl\n\n# Push and create PR\ngit push origin backport-5678-to-0.30\n# Open PR: \"[Backport 0.30] Fix IDL generation for nested types\"\nExample 3: Multiple Related Commits\nFeature flag fix requires backporting multiple commits:\n# Original PR #9012 has 3 related commits\ngit checkout -b backport-9012-to-0.30 origin/0.30\n\n# Cherry-pick all related commits together\ngit cherry-pick abc123 def456 ghi789\n\n# Verify all changes are included\ngit log -3\n\n# Push and create PR\ngit push origin backport-9012-to-0.30\n\nBest Practices\nFor Contributors\n\nTest backported changes on the actual target release branch\nKeep changes minimal; avoid refactoring unrelated code\nDocument any modifications needed for compatibility in PR description\nUpdate tests if they differ between versions\n\nFor Maintainers\n\nLabel PRs during review, not after release\nTrack backports to ensure nothing is missed\nPlan patch releases shortly after critical backports\nCommunicate backported fixes in release notes\n\nNotes\n\nKeep backports small and isolated: One issue per backport\nPrefer multiple small backports: Better than one large cumulative backport\nTest thoroughly: Always verify on the target version\nDocument changes: Update CHANGELOG for the target version\nCommunicate clearly: Users should understand which versions have which fixes\n\nBenefits\nThis lightweight workflow provides:\n\nStability: Long-term supported branches remain stable and secure\nMinimal overhead: Simple process with clear guidelines\nTraceability: Labels and PR history provide clear visibility\nFlexibility: Supports both automated and manual approaches\n\nFor questions, ask in Anchor Discord;\n#contributors channel or tag maintainers in the PR.PreviousContribution GuideOn this pageWhen to BackportWorkflow1. Identify and Label2. Create Backport PR3. Review & Merge4. Release ManagementExamplesExample 1: Automated Security Fix BackportExample 2: Manual Backport with ConflictsExample 3: Multiple Related CommitsBest PracticesFor ContributorsFor MaintainersNotesBenefitsEdit on GitHub","tokens":1573,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258751379,"hash":"6d632dcaa84eec8d15b70b2d188a9e7140ffb408"}
{"url":"https://aave.com/docs/aave-v3/getting-started/react","domain":"aave.com","title":"AaveKit React v3 | Aave Protocol Documentation","text":"React#\nAaveKit React is a collection of React hooks for building decentralized applications on top of the Aave Protocol. It provides a simple and type-safe way to interact with Aave markets, manage user positions, and execute transactions.\nGetting Started#\nTo get started, follow the steps below.\n1Install SDK#First, install the AaveKit React packages using your package manager of choice.npm install @aave/react@latest2Setup Client#Then, create an AaveClient instance that will be used to interact with the protocol.import { AaveClient } from \"@aave/react\";\nexport const client = AaveClient.create();You don't need to install the @aave/client package as it's already included\nand re-exported by the @aave/react package.3Setup Provider#Next, wrap your app with the <AaveProvider> component and pass the client instance.import { AaveProvider } from \"@aave/react\";\nimport { client } from \"./client\";\nexport function App() { return ( <AaveProvider client={client}> {/* Your application components */} </AaveProvider> );}4Start Building#That's it—you can now start using AaveKit React.import { useAaveChains } from \"@aave/react\";\nexport function SupportedChains() { const { data: chains } = useAaveChains();\n return ( <div> <h2>Supported Chains</h2> {chains?.map((chain) => ( <div key={chain.id}> <h3>{chain.name}</h3> <p>Chain ID: {chain.id}</p> </div> ))} </div> );}\nIntegrations#\nAaveKit React includes first-class support for viem, ethers v6, Privy, Dynamic, thirdweb and Turnkey.\nViemEthersPrivyDynamicthirdwebTurnkeyEnsure you have viem package installed in your project.npm install viem@2\nSend Aave Transactions#\nTo send transactions through the connected wallet, use the useSendTransaction action hook.\nconst [sendTransaction, { loading, error }] = useSendTransaction(/* args */);\nThis hook abstracts the wallet interaction and provides a simple interface for submitting transactions.\nViemEthersPrivyDynamicthirdwebTurnkeyImport the useSendTransaction hook from the @aave/react/viem entry point and wire it up with the viem's WalletClient.import { useSendTransaction } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\nfunction MyComponent() { const { data: walletClient } = useWalletClient(); const [sendTransaction, sending] = useSendTransaction(walletClient);\n // Use with transaction hooks…}The example uses wagmi to get the WalletClient from the\nconnected wallet.\nThen, use it as describe in the specific page.\nSign ERC-20 Permits#\nAave makes use of EIP-2612 to allow users to avoid ERC-20 approval before sending transactions.\nUse the useERC20Permit hook to sign ERC-20 permits.\nViemEthersPrivyDynamicthirdwebTurnkeyImport the useERC20Permit hook from the @aave/react/viem entry point and wire it up with the viem's WalletClient.import { useERC20Permit } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\nfunction MyComponent() { const { data: walletClient } = useWalletClient(); const [signPermit, sending] = useERC20Permit(walletClient);\n // Use with transaction hooks…}The example uses wagmi to get the WalletClient from the\nconnected wallet.\nThen, use the signPermit function as described in the specific operation guide.\nRead Hooks#\nAll read hooks (market data, user positions, etc.) support two ways of operating: loading state and React Suspense.\nLoading State#\nHandle loading state manually in your component:\nfunction ChainsList() { const { data, loading, error } = useAaveChains();\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((chain) => ( <div key={chain.id}>{chain.name}</div> ))} </div> );}\nReact Suspense#\nLet React handle loading states automatically through a Suspense boundary.\n// Component - no loading states neededfunction ChainsList() { const { data: chains } = useAaveChains({ suspense: true, // Enable suspense mode });\n return ( <div> {chains.map((chain) => ( <div key={chain.id}>{chain.name}</div> ))} </div> );}\n// Parent - wrap with Suspense boundaryfunction ChainsPage() { return ( <Suspense fallback={<div>Loading …</div>}> <ChainsList /> </Suspense> );}\nYou can handle errors in the parent component by wrapping the component with a Error boundary component.\nimport { ErrorBoundary } from \"react-error-boundary\";\n// …\nfunction ChainsPage() { return ( <ErrorBoundary fallback={<p>⚠️Something went wrong</p>}> <Suspense fallback={<div>Loading …</div>}> <ChainsList /> </Suspense> </ErrorBoundary> );}\nAction Hooks#\nAaveKit React provides action hooks that are designed to be triggered manually when you need to perform an operation. Action hooks return an execute function and a state object.\nconst [execute, state] = useActionHook();\nExecute Function#\nThe execute function returns a ResultAsync<T, E>, a thenable object that represents one of two states:\nOk<T>: A successful result containing a value of type TErr<E>: A failure containing an error of type E\nAwaiting a ResultAsync<T, E> resolves to a Result<T, E>.\nWith a Result<T, E>, you can use the convenient isOk() and isErr() methods to check the outcome and narrow the type.\nIf you have a ResultAsync<T, E>, you must first await it to access those methods.\nconst result = await execute();\nif (result.isOk()) { console.log(\"Result:\", result.value);} else { console.error(\"Error:\", result.error);}\nThis approach avoids reliance on try/catch blocks and promotes predictable, type-safe code by ensuring errors are handled explicitly.\nSee the NeverThrow documentation\nfor more information. The NeverThrow library is re-exported for convenience.\nState Object#\nThe state object returned by action hooks provides information about the current operation status:\nconst { called, data, error, loading } = state;\nWhere:\ncalled: true when the operation has been executed at least once, false otherwisedata: Contains the last successful result of type T, undefined otherwiseerror: Contains the error of type E if the operation failed, undefined otherwiseloading: true when the operation is in progress, false otherwise\nTransaction Hooks#\nTransaction hooks are a specific type of action hook that handle protocol interactions like supply, borrow, withdraw, repay, and more.\nThere are two types of transaction hooks:\nSimple transactions - single transactions that can be sent directly to the walletComplex transactions - transactions that could require approval beforehand\nSimple Transactions#\nTo handle a simple transaction hook, follow the steps below.\n1Use Hooks#First, instantiate the transaction hook and the useSendTransaction hook according to the wallet provider you are using.const [prepare, preparing] = useSimpleTransaction();const [sendTransaction, sending] = useSendTransaction(/* … */);2Execute the Transaction#Next, execute the transaction in your app by chaining the prepare and send operations.const result = await prepare(/* args */).andThen(sendTransaction);Optionally, combine the state objects to drive your UI components.const loading = preparing.loading && sending.loading;const error = preparing.error || sending.error;3Handle the Result#Finally, handle the result of the operation.if (result.isErr()) { switch (result.error.name) { case \"SigningError\": // Most likely the user rejected the transaction console.error(`Failed to sign the transaction: ${error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${error.message}`); break;\n case \"UnexpectedError\": console.error(error.message); break; }} else { console.log(\"Transaction sent with hash:\", result.value);}\nComplex Transactions#\nTo handle a complex transaction hook, follow the steps below.\n1Use Hooks#First, instantiate the transaction hook and the useSendTransaction hook according to the wallet provider you are using.const [prepare, preparing] = useComplexTransaction();const [sendTransaction, sending] = useSendTransaction(/* … */);Optionally, combine the state objects to drive your UI components.const loading = preparing.loading && sending.loading;const error = preparing.error || sending.error;2Process the Execution Plan#Next, handle the execution plan in your transaction flow. Some operations may require token approval before executing the main transaction.import { errAsync } from \"@aave/react\";\nconst result = await prepare(/* args */).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"ApprovalRequired\": return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); }});\n// …If you wish to ask the user for confirmation before sending the transaction,\nyou can do so by integrating your app's confirmation UI at this point.3Handle the Result#Finally, handle the result of the operation.if (result.isErr()) { switch (result.error.name) { case \"SigningError\": // Most likely the user rejected the transaction console.error(`Failed to sign the transaction: ${error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${error.message}`); break;\n case \"UnexpectedError\": console.error(error.message); break; }} else { console.log(\"Transaction sent with hash:\", result.value);}\nNext Steps#\nAave Markets - Learn how to interact with Aave markets.Aave Earn - Learn how to interact with Aave Earn Vaults.PreviousIncentivesNextTypeScript","tokens":2391,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258754400,"hash":"848401a5213cf33ebe30aa830123bc80b9cb35b0"}
{"url":"https://forum.openzeppelin.com/c/archive/34","domain":"forum.openzeppelin.com","title":"Latest Archive topics - OpenZeppelin Forum","text":"Latest topics in Archive\n\n Archive\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Archive category\n\n Archive\n\n The Archive category provides read only access to archived categories/sub-categories\n\n 0\n\n 1.1k\n\n Sep 2020\n\n Deployment Issues using npx oz deploy\n\n SDK\n\n 1\n\n 1.0k\n\n Aug 2021\n\n Deploying Smart Contracts Using CREATE2 tutorial query error `Maximum call stack size exceeded`\n\n SDK\n\n 1\n\n 1.3k\n\n Jul 2021\n\n Source “@openzeppelin …. ” not found: File import callback not supported\n\n SDK\n\n 4\n\n 9.9k\n\n Jun 2021\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use the CLI with contracts created via a factory contract\n\n SDK\n\n 11\n\n 1.9k\n\n Jun 2021\n\n Deployment failed with error: Returned error: sender doesn’t have enough funds to send tx\n\n SDK\n\n 8\n\n 4.4k\n\n Jun 2021\n\n File import callback not supported\n\n SDK\n\n 23\n\n 33.4k\n\n May 2021\n\n Problem as sometimes initialize() can’t be called\n\n SDK\n\n 5\n\n 5.6k\n\n May 2021\n\n Upgradeable ERC20 token with partial burn on transfer\n\n SDK\n\n 7\n\n 5.6k\n\n May 2021\n\n Ownable contract owner is always the 0 address\n\n SDK\n\n 5\n\n 10.8k\n\n Mar 2021\n\n Verify upgradeable logic contract on Etherscan\n\n SDK\n\n 3\n\n 5.6k\n\n Mar 2021\n\n Zos install fails\n\n SDK\n\n 5\n\n 2.2k\n\n Mar 2021\n\n How to specify the gas price for the deploy command of the CLI?\n\n SDK\n\n 2\n\n 3.8k\n\n Mar 2021\n\n How is the mapping of storage done in upgradeable contracts?\n\n SDK\n\n proxies,upgrades\n\n 5\n\n 3.9k\n\n Feb 2021\n\n Add new state variable to base contract for upgradeable contracts\n\n SDK\n\n 6\n\n 5.2k\n\n Jan 2021\n\n ZeppelinOS proxy pattern and structs\n\n SDK\n\n proxies\n\n 7\n\n 3.2k\n\n Jan 2021\n\n Are there restrictions on modifying enums and structs in upgradeable contracts?\n\n SDK\n\n 2\n\n 4.0k\n\n Jan 2021\n\n Updating struct cause damage to data\n\n SDK\n\n 3\n\n 2.9k\n\n Jan 2021\n\n How to use a struct in an upgradable contract\n\n SDK\n\n 5\n\n 5.7k\n\n Jan 2021\n\n Msg.sender.transfer runs out of gas on a payable upgradeable proxy contract\n\n SDK\n\n 2\n\n 3.9k\n\n Jan 2021\n\n Every call results in Error: VM execution error after upgrade\n\n SDK\n\n 6\n\n 3.3k\n\n Jan 2021\n\n Verify with OpenZeppelin CLI\n\n SDK\n\n 7\n\n 2.4k\n\n Dec 2020\n\n `oz call` Cannot read property ‘message’ of null\n\n SDK\n\n 5\n\n 1.7k\n\n Dec 2020\n\n Compile error: File import callback not supported\n\n SDK\n\n 2\n\n 2.5k\n\n Dec 2020\n\n File import callback not supported on MacOS\n\n SDK\n\n 4\n\n 3.8k\n\n Dec 2020\n\n How to add OpenZeppelin compiler into truffle config as an external compiler?\n\n SDK\n\n 3\n\n 1.8k\n\n Nov 2020\n\n Deploying to Quorum with OpenZeppelin CLI\n\n SDK\n\n 3\n\n 2.9k\n\n Nov 2020\n\n Get the Transaction Hash from createProxy?\n\n SDK\n\n 5\n\n 1.6k\n\n Oct 2020\n\n Are upgradable and non upgradable contracts in the same truffle project supported?\n\n SDK\n\n 4\n\n 2.5k\n\n Oct 2020","tokens":705,"squid":"ink-security_audits","role":"Sentinel","at":1791258759227,"hash":"fa72b5d73931f6b3e67d9653fae9d6c52b67d102"}
{"url":"https://aave.com/docs/aave-v4/positions/conditions","domain":"aave.com","title":"Position Conditions | Aave Protocol Documentation","text":"User Position Conditions#\nLearn how user position conditions work in Aave v4.\n\nUser positions track two risk conditions: Dynamic Risk Configuration and User Risk Premium.\nDynamic Risk Configuration#\nDynamic Risk Configuration, or Dynamic Config for short, snapshots the per-reserve collateral parameters—Collateral Factor, Max Liquidation Bonus, and Protocol Fee—active when the position first became risk-bearing, i.e. when the user initially borrowed against collateral.\nIt updates when the user performs risk-increasing actions: borrowing, withdrawing collateral, or disabling collateral (updates all reserves' snapshots), or enabling collateral (updates only that reserve's snapshot). It can also be updated manually, and always refreshes the User Risk Premium.\nThe Dynamic Config values used on first borrow or after an update—implicit or explicit—are exposed on the Reserve object under the settings field:\nconst reserve: Reserve = { __typename: \"Reserve\", id: \"SGVsbG8h\", settings: { __typename: \"ReserveSettings\", collateralFactor: { normalized: BigDecimal(80), // 90% // … }, maxLiquidationBonus: { normalized: BigDecimal(10), // 10% // … }, // protocol fee liquidationFee: { normalized: BigDecimal(1), // 1% // … }, // … latestDynamicConfigKey: \"1234567890\", }, // …};\nThe snapshotted values are exposed under the Reserve's userState field: the Collateral Factor applies to reserves linked by UserSupplyItem when used as collateral, while the Max Liquidation Bonus and Protocol Fee apply to reserves linked by UserBorrowItem.\nconst borrowItem: UserBorrowItem = { __typename: \"UserBorrowItem\", id: \"aGVsbG8=\", reserve: { __typename: \"Reserve\", id: \"SGVsbG8h\", userState: { __typename: \"ReserveUserState\", maxLiquidationBonus: { normalized: BigDecimal(10), // 10% // … }, // protocol fee liquidationFee: { normalized: BigDecimal(1), // 1% // … }, // … dynamicConfigKey: \"1234567889\", }, // … }, // …};\nUser Risk Premium#\nUser Risk Premium reflects the current risk profile of the collateral assets. In practice, it acts as a multiplier—a percentage applied on top of each reserve's base borrow rate. Lower is better.\nA high User Risk Premium signals riskier collateral, which in turn results in\na higher borrowing rate. Conversely, a low User Risk Premium indicates\nhigher-quality collateral and leads to reduced borrowing costs.\nIt updates when the user performs actions that affect collateralization (borrowing, withdrawing collateral, enabling or disabling collateral), when the Dynamic Risk Configuration changes, or when explicitly triggered.\nYou can keep track of the User Risk Premium for a position by checking the riskPremium.current field in the User Position response.\nconst userPosition: UserPosition = { __typename: \"UserPosition\", id: \"aGVsbG8\", user: \"0x456…\", riskPremium: { current: { normalized: BigDecimal(50), // 50% // … }, latest: { normalized: BigDecimal(50), // 50% - same as current // … }, breakdown: [ // … ], }, spoke: { id: \"SGVsbG8h\", address: \"0x123…\", chain: { chainId: 1, name: \"Ethereum\", // … }, // … }, // …};\nThe example above shows a User Risk Premium of 50%. This means that on an\nasset with a base borrow rate of 5%, the user is paying 7.5% interest on their\nborrow positions (5% + 50% = 7.5%).\nThe riskPremium.breakdown field contains the User Risk Premium Breakdown for the user position collaterals.\nUser Risk Premium Breakdown#\nThe User Risk Premium Breakdown shows each collateral asset in a user position, including what percentage of total collateral it represents and its weight in the overall User Risk Premium.\nconst breakdown: UserRiskPremiumBreakdownItem[] = [ { __typename: \"UserRiskPremiumBreakdownItem\", token: { __typename: \"Erc20Token\", id: \"aGVsbG8\", address: \"0x456…\", name: \"USDC\", symbol: \"USDC\", decimals: 6, }, currentRiskPremiumWeight: { __typename: \"PercentNumber\", normalized: BigDecimal(50), // 50% // … }, latestRiskPremiumWeight: { __typename: \"PercentNumber\", normalized: BigDecimal(45), // 45% // … }, collateral: { __typename: \"PercentNumber\", normalized: BigDecimal(30), // 30% // … }, }, // …];\nWhere:\ncurrentRiskPremiumWeight represents the current contribution of this collateral asset to the overall User Risk Premium.latestRiskPremiumWeight represents the contribution if the User Risk Premium were to be updated.collateral represents this asset’s share of the position’s total collateral value.\nAs mentioned above, the breakdown is available in the riskPremium.breakdown field of user positions, or you can use the standalone query explained below.\nReactTypeScriptGraphQLUse the useUserRiskPremiumBreakdown hook to fetch the breakdown for a specific user position.import { type UserRiskPremiumBreakdownRequest, useUserRiskPremiumBreakdown,} from \"@aave/react\";\nfunction UserRiskPremiumBreakdown({ request,}: { request: UserRiskPremiumBreakdownRequest;}) { const { data, loading, error } = useUserRiskPremiumBreakdown(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((item) => ( <div key={item.token.address}> <p>{item.token.symbol}</p> <p> Current Weight:{\" \"} {item.currentRiskPremiumWeight.normalized.toFixed(2)}% </p> <p> Latest Weight: {item.latestRiskPremiumWeight.normalized.toFixed(2)}% </p> <p>Collateral: {item.collateral.normalized.toFixed(2)}%</p> </div> ))} </div> );}You can query by user position ID or by user spoke:const request: UserRiskPremiumBreakdownRequest = { user: evmAddress(\"0x742d35cc…\"), query: { userPositionId: userPositionId(params.id), // UserPositionId - typically from URL params },};\nUpdate Conditions#\nAs protocol configurations evolve through governance votes, a user position’s conditions may improve.\nUpdating user position conditions can be broken down into the following steps:\nIdentify eligible positionsPreview the impact of the update (optional)Update the position conditions\nIdentify Eligible Positions#\nYou can identify positions that qualify for updates by checking if the riskPremium.latest is lower than riskPremium.current (indicating a better risk premium is available) or the canUpdateDynamicConfig field (true when dynamic config can be updated) in the user's positions.\nconst userPosition: UserPosition = { __typename: \"UserPosition\", id: \"aGVsbG8\", user: \"0x456…\", riskPremium: { current: { normalized: BigDecimal(50), // 50% // … }, latest: { normalized: BigDecimal(25), // 25% - lower is better // … }, breakdown: [ // … ], }, spoke: { id: \"SGVsbG8h\", address: \"0x123…\", chain: { chainId: 1, name: \"Ethereum\", // … }, // … }, canUpdateDynamicConfig: true, // …};\nPreview the Impact#\nPreview the impact of updating the user position conditions before committing to it.\nReactTypeScriptGraphQLUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of updating the user position conditions.import { type UpdateUserPositionConditionsRequest, usePreview,} from \"@aave/react\";\nfunction UserPositionConditionsPreview({ request,}: { request: UpdateUserPositionConditionsRequest;}) { const { data, error, loading } = usePreview({ action: { updateUserPositionConditions: request, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor.current?.value.toFixed(2) ?? \"N/A\"}</p> <p>To: {data.healthFactor.after?.value.toFixed(2) ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Max Borrowing Power:</h3> <p>From: {data.maxBorrowingPower.current.value.toDisplayString(2)}</p> <p>To: {data.maxBorrowingPower.after.value.toDisplayString(2)}</p> </div> );}See below for examples of UpdateUserPositionConditionsRequest objects.const request: UpdateUserPositionConditionsRequest = { userPositionId: userPosition.id, update: UserPositionConditionsUpdate.JustRiskPremium,};Remember that updating Dynamic Config will also update the User Risk Premium.The PreviewUserPosition shows the impact of the update user position conditions operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is betterprojectedEarning.[current → after]: ExchangeAmountProjected earningsmaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerotherConditions: UserPositionConditionVariation[]Dynamic config changes\nThe otherConditions field is an array of objects describing dynamic configuration changes per reserve the user has a position in.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus change\nStep-by-Step#\nNow that we know how to identify the user positions that qualify for an update, and we know how to preview the impact of updating the user position conditions, let's see how to update the user position conditions.\nReactTypeScriptGraphQLSolidityTo update user position conditions with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Define the Update Flow#Then, use the useUpdateUserPositionConditions hook to prepare the transaction request.import { useUpdateUserPositionConditions } from \"@aave/react\";\nconst [updateConditions, { loading, error }] = useUpdateUserPositionConditions( (transaction) => sendTransaction(transaction),);3Execute the Transaction#Then, execute the transaction.import { UserPositionConditionsUpdate, type UserPosition } from \"@aave/react\";\nconst execute = async (userPosition: UserPosition) => { const result = await updateConditions({ userPositionId: userPosition.id, update: UserPositionConditionsUpdate.JustRiskPremium, });};Remember that updating Dynamic Config will also update the User Risk Premium.4Handle the Result#Finally, handle the result.const execute = async () => { const result = await updateConditions(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log( \"Position conditions updated successfully with hash:\", result.value.txHash, );};\n\nAdvanced Usage#\nNetwork Fee#\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nEstimate the network cost of any action using the same PreviewAction you pass to the usePreview hook.\nLet's consider the following example:\nimport { type PreviewAction, UserPositionConditionsUpdate } from \"@aave/react\";\nconst action: PreviewAction = { updateUserPositionConditions: { userPositionId: userPosition.id, // from UserPosition update: UserPositionConditionsUpdate.AllDynamicConfig, },};\nUse the useNetworkFee hook to estimate both the network fee for the provided action and its fiat equivalent.\nimport { type PreviewAction, Currency } from \"@aave/react\";import { useNetworkFee } from \"@aave/react/viem\";\nfunction NetworkFee({ action }: { action: PreviewAction }) { const { data: fee, loading, error, } = useNetworkFee({ query: { estimate: action }, currency: Currency.Eur, });\n if (loading) return <p>Loading fee…</p>; if (error) return <p>Error: {error.message}</p>;\n return ( <p> Network Fee: {fee.amount.value.toDisplayString(2)} {fee.token.info.symbol} <span> ≈{fee.exchange.symbol} {fee.exchange.value.toDisplayString(2)} </span> </p> );}PreviousPositions ManagersNextLiquidations","tokens":3096,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258764864,"hash":"977c5ffc4b046f124d376fcce29ccc98575d48d5"}
{"url":"https://io.net/docs/guides/confidential-inference/quick-start","domain":"io.net","title":"Quick Start API - io.net","text":"​Prerequisites\n\nio.net API key (get one here)\ncurl or Python 3.7+\n\n​Step 1: Find Models with Attestation Support\nFirst, list available models and filter for those supporting attestation:\n​curl\ncurl -s https://api.intelligence.io.solutions/v1/models \\\n -H \"Authorization: Bearer $IO_API_KEY\" | \\\n jq '.data[] | select(.supports_attestation == true) | {name, model_id}'\n\n​Python\nimport requests\n\nresponse = requests.get(\n \"https://api.intelligence.io.solutions/v1/models\",\n headers={\"Authorization\": f\"Bearer {IO_API_KEY}\"}\n)\n\nmodels = response.json()[\"data\"]\nattestation_models = [m for m in models if m.get(\"supports_attestation\")]\n\nfor model in attestation_models:\n print(f\"{model['name']}: {model['model_id']}\")\n\nNote the model_id (UUID) for a model you want to use.\n​Step 2: Get Attestation Report\nBefore running inference, request an attestation report to verify the GPU machine. Generate a unique nonce (random string) for freshness verification.\n​curl\n# Generate a random nonce\nNONCE=$(openssl rand -hex 16)\n\n# Request attestation report\ncurl -X POST https://api.intelligence.io.solutions/v1/private/attestation \\\n -H \"Authorization: Bearer $IO_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model_id\": \"YOUR_MODEL_UUID_HERE\",\n \"nonce\": \"'$NONCE'\"\n }'\n\n​Python\nimport secrets\nimport requests\n\n# Generate a random nonce\nnonce = secrets.token_hex(16)\n\nresponse = requests.post(\n \"https://api.intelligence.io.solutions/v1/private/attestation\",\n headers={\n \"Authorization\": f\"Bearer {IO_API_KEY}\",\n \"Content-Type\": \"application/json\"\n },\n json={\n \"model_id\": \"YOUR_MODEL_UUID_HERE\",\n \"nonce\": nonce\n }\n)\n\nattestation = response.json()\n# Nonce is padded to 64 hex characters - verify prefix matches\nprint(f\"Nonce verified: {attestation['nonce'].startswith(nonce)}\")\nprint(f\"Signing address: {attestation['signing_address']}\")\n\n​Example Response\n{\n \"nonce\": \"87ebbef3ceb69d2d6d7edc1b05c42ad900000000000000000000000000000000\",\n \"gpu\": {\n \"nonce\": \"87ebbef3ceb69d2d6d7edc1b05c42ad900000000000000000000000000000000\",\n \"arch\": \"HOPPER\",\n \"evidence_list\": [\n {\n \"evidence\": \"<base64-encoded attestation evidence>\",\n \"certificate\": \"<base64-encoded certificate chain>\"\n }\n ],\n \"claims_version\": \"3.0\"\n },\n \"cpu\": {\n \"quote\": \"<hex-encoded CPU attestation quote>\"\n },\n \"signing_address\": \"0xf52373547CAa0EeCB0fcD34042D7518E79aA80cC\",\n \"image_digest\": \"sha256:cf47db862b96b243e077a80ee51afa2c007604bf3c648232d42144947e56c339\"\n}\n\nSave the signing_address - you’ll use it to verify response signatures.\nVerify the image_digest - compare with the expected digest published in the latest official release to confirm the running container hasn’t been tampered with.\n​Step 3: Run Confidential Inference\nNow run inference using the confidential completions endpoint. The request format is OpenAI-compatible.\n​curl\ncurl -X POST https://api.intelligence.io.solutions/v1/private/completions \\\n -H \"Authorization: Bearer $IO_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d '{\n \"model\": \"meta-llama/Llama-3.3-70B-Instruct\",\n \"messages\": [\n {\"role\": \"user\", \"content\": \"What is confidential computing?\"}\n ],\n \"max_tokens\": 5000\n }' \\\n -i # Include response headers\n\n​Python\nresponse = requests.post(\n \"https://api.intelligence.io.solutions/v1/private/completions\",\n headers={\n \"Authorization\": f\"Bearer {IO_API_KEY}\",\n \"Content-Type\": \"application/json\"\n },\n json={\n \"model\": \"meta-llama/Llama-3.3-70B-Instruct\",\n \"messages\": [\n {\"role\": \"user\", \"content\": \"What is confidential computing?\"}\n ],\n \"max_tokens\": 5000\n }\n)\n\n# Get the response body\ncompletion = response.json()\nprint(completion[\"choices\"][0][\"message\"][\"content\"])\n\n# Get signature headers for verification\nsignature_headers = {\n \"text\": response.headers.get(\"text\"),\n \"signature\": response.headers.get(\"signature\"),\n \"signing_address\": response.headers.get(\"signing_address\"),\n \"signing_algo\": response.headers.get(\"signing_algo\"),\n \"image_digest\": response.headers.get(\"image_digest\"),\n}\n\n​Response Headers\nThe response includes signature headers for verification:\ntext: <signed content>\nsignature: <cryptographic signature>\nsigning_address: 0x1234...abcd\nsigning_algo: ecdsa\nimage_digest: sha256:...c00\n\n​Step 4: Verify the Response Signature\nVerify that the response came from the attested machine by checking the signature.\n​Python (with eth_account)\nfrom eth_account.messages import encode_defunct\nfrom eth_account import Account\n\ndef verify_response(signature_headers, expected_signing_address):\n \"\"\"Verify the response signature matches the attested machine.\"\"\"\n\n text = signature_headers[\"text\"]\n signature = signature_headers[\"signature\"]\n signing_address = signature_headers[\"signing_address\"]\n\n # Verify signing address matches attestation\n if signing_address.lower() != expected_signing_address.lower():\n raise ValueError(\"Signing address does not match attestation!\")\n\n # Verify signature\n message = encode_defunct(text=text)\n recovered_address = Account.recover_message(message, signature=signature)\n\n if recovered_address.lower() != signing_address.lower():\n raise ValueError(\"Signature verification failed!\")\n\n return True\n\n# Verify using the signing_address from Step 2\nsigning_address_from_attestation = attestation[\"signing_address\"]\nverify_response(signature_headers, signing_address_from_attestation)\nprint(\"Response verified!\")\n\n​Complete Example\nHere’s a complete Python script that performs verified confidential inference:\nimport secrets\nimport requests\nfrom eth_account.messages import encode_defunct\nfrom eth_account import Account\n\nIO_API_KEY = \"your-api-key\"\nBASE_URL = \"https://api.intelligence.io.solutions/v1\"\nPRIVATE_URL = \"https://api.intelligence.io.solutions/v1/private\"\n\ndef get_attestation_models():\n \"\"\"Get models that support attestation.\"\"\"\n response = requests.get(\n f\"{BASE_URL}/models\",\n headers={\"Authorization\": f\"Bearer {IO_API_KEY}\"}\n )\n models = response.json()[\"data\"]\n return [m for m in models if m.get(\"supports_attestation\")]\n\ndef get_attestation(model_id: str, nonce: str):\n \"\"\"Get attestation report for a model.\"\"\"\n response = requests.post(\n f\"{PRIVATE_URL}/attestation\",\n headers={\n \"Authorization\": f\"Bearer {IO_API_KEY}\",\n \"Content-Type\": \"application/json\"\n },\n json={\"model_id\": model_id, \"nonce\": nonce}\n )\n response.raise_for_status()\n return response.json()\n\ndef confidential_completion(model: str, messages: list):\n \"\"\"Run confidential inference and return response with headers.\"\"\"\n response = requests.post(\n f\"{PRIVATE_URL}/completions\",\n headers={\n \"Authorization\": f\"Bearer {IO_API_KEY}\",\n \"Content-Type\": \"application/json\"\n },\n json={\"model\": model, \"messages\": messages}\n )\n response.raise_for_status()\n\n return {\n \"body\": response.json(),\n \"signature_headers\": {\n \"text\": response.headers.get(\"text\"),\n \"signature\": response.headers.get(\"signature\"),\n \"signing_address\": response.headers.get(\"signing_address\"),\n \"signing_algo\": response.headers.get(\"signing_algo\"),\n \"image_digest\": response.headers.get(\"image_digest\"),\n }\n }\n\ndef verify_signature(text: str, signature: str, expected_address: str):\n \"\"\"Verify response signature.\"\"\"\n message = encode_defunct(text=text)\n recovered = Account.recover_message(message, signature=signature)\n return recovered.lower() == expected_address.lower()\n\n# Main flow\nif __name__ == \"__main__\":\n # 1. Find an attestation-enabled model\n models = get_attestation_models()\n model = models[0]\n print(f\"Using model: {model['name']}\")\n\n # 2. Get attestation with fresh nonce\n nonce = secrets.token_hex(16)\n attestation = get_attestation(model[\"model_id\"], nonce)\n\n # Verify nonce freshness (nonce is padded to 64 hex chars)\n assert attestation[\"nonce\"].startswith(nonce), \"Nonce mismatch!\"\n signing_address = attestation[\"signing_address\"]\n print(f\"Attestation verified, signing address: {signing_address}\")\n\n # 3. Run confidential inference\n result = confidential_completion(\n model=model[\"name\"],\n messages=[{\"role\": \"user\", \"content\": \"Hello, explain TEE in one sentence.\"}]\n )\n\n # 4. Verify response signature\n headers = result[\"signature_headers\"]\n assert headers[\"signing_address\"].lower() == signing_address.lower(), \\\n \"Signing address mismatch!\"\n\n assert verify_signature(\n headers[\"text\"],\n headers[\"signature\"],\n signing_address\n ), \"Signature verification failed!\"\n\n print(\"Response verified!\")\n print(result[\"body\"][\"choices\"][0][\"message\"][\"content\"])\n\n​What’s Next\n\nConfidential Chat - Use the web interface for private conversations\nVerification Guide - Deep dive into verifying attestation and signatures\nWas this page helpful?","tokens":2129,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258766068,"hash":"bee7df44c6779d44425800c28a82418d953b4d6e"}
{"url":"https://forum.openzeppelin.com/t/how-to-use-the-cli-with-contracts-created-via-a-factory-contract/1748","domain":"forum.openzeppelin.com","title":"How to use the CLI with contracts created via a factory contract - Archive / SDK - OpenZeppelin Forum","text":"How to use the CLI with contracts created via a factory contract \n\n ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 5\n\n Nov 2019\n\n 1 / 12\n\n Nov 2019\n\n Jun 2021\n\n post by Srinivasan_S on Nov 13, 2019\n\n Srinivasan_S\n\n Hey, I am new to oz and currently we are using oz in our project to upgrade the smart contract , oz is very easy and helpful to us to maintain the smart contract up to date. Also we do have factory contract where we use to create instance of smart contract through factory contract, in that scenario, Through oz we are unable to have entries of the each contract instance in .openzeppelin json file so we unable to update the each smart contract instance… where these smart contract is not directly deployed through oz CLI tool… Is there any way to make the contract created through factory could be up to date. Thanks for your time… waiting for your response…\n\n Error: StandaloneERC20 Factory\n\n 6\n\n 5\n\n post by abcoathup on Nov 13, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @Srinivasan_S,\nI assume you mean that your factory contract is creating upgradeable contracts (rather than non-upgradeable contracts) as per the example: Creating instances from Solidity\nThere is an open issue to be able to interact with an upgradeable contract created not via the CLI: https://github.com/OpenZeppelin/openzeppelin-sdk/issues/1264\nI am not aware of a way to do this currently other than interacting with the contracts directly.\n\n post by Srinivasan_S on Nov 13, 2019\n\n Srinivasan_S\n\n Hi @abcoathup,\nThanks for your response, Yes, actually we have different factory contract not similar as shown as an example given by you. My factory contract which is creating upgradeable contracts instances (contract already upgraded through oz CLI). In future if i am making some changes to the existing upgradeable contract through CLI and creating instances out of it through factory contract Then the newly created instances should retains the old contract state data or not?\nThanks for your time.\n\n post by abcoathup on Nov 14, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @Srinivasan_S,\nI am not sure I understand your setup.\nCan you give a bit more detail on the smart contracts?\nFor example:\n\nUpgradeable contract A that was created via the CLI.\nFactory contract F that creates upgradeable contracts A\n\nThe CLI doesn’t currently support interacting with contracts that weren’t created by it.\nSo you wouldn’t be able to upgrade a contract created by the Factory using the CLI.\nYou could upgrade by interacting with the Proxy contract directly.\nRecommend reading OpenZeppelin SDK Upgrades Pattern if you haven’t already.\n\n post by Srinivasan_S on Nov 14, 2019\n\n Srinivasan_S\n\n Ok, let me frame it with an example,\n\nI have Upgradeable contract A that was created via the CLI.\nI have Factory contract F that creates upgradeable contracts A.\n\nOk cool till now everything perfect, I have created instance A1 say F -> A1\nNow I am thinking to do some more changes in contract A, I have done that changes, I am sure I could upgrade it through proxy contract directly,\nSo my understanding here is the instance A1 which was created through Factory F cannot be upgrade further because we don’t have proxy for A1? (correct me if i am wrong)\nas per the example given here\nCreating instances from Solidity\ncould I able to upgrade the instance or not , will CLI command support in this case or not ?\nThanks for your time\n\n post by abcoathup on Nov 14, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @Srinivasan_S,\nAssuming you are creating upgradeable contracts F -> A1 using app.create as per the example:\n\nThen you can upgrade the logic contract that the proxy points to, but you can’t do this by the CLI as the contract wasn’t created via the CLI. You would need to interact with the contract directly e.g. write a script to interact with the contract.\n\nAlternatively, if your factory is only creating logic contracts e.g. A a1 = new A(); then this is a non-upgradeable contract.\n\n post by Srinivasan_S on Nov 14, 2019\n\n Srinivasan_S\n\n Hi @abcoathup,\nThanks for the clarification, I think i got the answer, also i want to do some more home work, I will get back to you for sure if I need any clarification.\nThanks for your support and time.\n\n post by abcoathup on Nov 14, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @Srinivasan_S,\nI recommend creating some small sample contracts and trying it out to see what you can do. (I do this a lot)\nPlease ask all the questions that you need.\n\n post by Srinivasan_S on Nov 14, 2019\n\n Srinivasan_S\n\n Yes, That’s what I think \n\n 21 days later\n\n post by Srinivasan_S on Dec 5, 2019\n\n Srinivasan_S\n\n abcoathup\n\n Hi @abcoathup, how are you? By chance do we have any sample example or script to interact with the contract directly,\nThanks for our time.\n\n post by abcoathup on Dec 5, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @Srinivasan_S,\nNot that I am aware of.\nThe creating instances from Solidity example is probably the best that we have currently:\nhttps://github.com/OpenZeppelin/openzeppelin-sdk/tree/master/examples/creating-instances-from-solidity\n\n 2 years later\n\n post by Cui_App on Jun 14, 2021\n\n Cui_App\n\n Hi, @abcoathup\nIn the meantime, is there any more chance to do this solution?\nso what I wanna create is like following\n\nI have the upgradeable smartcontract “ContractA”\nI have a Factory to clone the ContractA\nAfter deploying the Factory, I will clone the contractA. i.e it will be contractA1\n\nI want 2 options.\n\nI want to add one function in the contractA1 cloned.\nI want to add one function in the contractA. so the Factory will create the upgraded “ContractA”.\n\nPlease help me.\nthank you.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to upgrade contracts that was created via a factory contract without any CLI?\n\n SDK\n\n 8\n\n 2.2k\n\n Jul 2020\n\n How to interact with a contract created using a factory?\n\n SDK\n\n upgrades\n\n 1\n\n 777\n\n Jun 2020\n\n How to upgrade a contract deployed from a factory contract?\n\n SDK\n\n proxies\n\n 12\n\n 2.9k\n\n Jul 2020\n\n Possibilities of upgrading a contract which was not initially designed to be upgradeable\n\n Support\n\n 2\n\n 450\n\n Aug 2020\n\n Openzeppelin upgrades - new instance in a contract\n\n Upgrades\n\n proxies\n\n 4\n\n 1.5k\n\n Nov 2021","tokens":1573,"squid":"ink-security_audits","role":"Sentinel","at":1791258769793,"hash":"3151d12f028c6bd15ae58ed1c3213f6808797b4b"}
{"url":"https://aave.com/docs/aave-v3/getting-started/graphql","domain":"aave.com","title":"AaveKit API v3 | Aave Protocol Documentation","text":"GraphQL#\nThe Aave Protocol exposes a comprehensive GraphQL API that allows you to query market data, user positions, and execute transactions. This low-level API is perfect for custom integrations, data analysis, and building integrations for which the TypeScript SDK is not suitable.\nGetting Started#\nThe Aave Protocol GraphQL API is available at:\nhttps://api.v3.aave.com/graphql\nThe URL above works also as a GraphQL playground you can use to test your\nqueries.\nYou can query the API directly using any HTTP client. Here's a basic example using curl:\ncurl -X POST https://api.v3.aave.com/graphql \\ -H \"Content-Type: application/json\" \\ -d '{ \"query\": \"query Chains { chains { name chainId icon } }\" }'\nQuery Operations#\nAaveKit API is constituted by just two types of queries:\nRead queries – queries that return data from the Aave Protocol.Transactions queries – queries that prepare transactions to be executed on the Aave Protocol.\nThe transactions queries are in turn divided into two categories:\nSimple transactions – single-step transactions that can be sent directly to the wallet.Complex transactions – transactions that may require prior approvals before they can be executed.\nSimple Transactions#\nSimple transactions query returns a TransactionRequest object that can be used to send the transaction to the wallet.\ntype TransactionRequest { to: EvmAddress! from: EvmAddress! data: BlockchainData! value: BigInt! chainId: ChainId! operation: OperationType}\nComplex Transactions#\nComplex transactions query returns an ExecutionPlan union.\nThe ExecutionPlan union represents the different scenarios that can occur when preparing a transaction:\nTransactionRequest: The transaction can be executed directly.ApprovalRequired: An approval transaction must be sent first, then the original transaction can be executed.InsufficientBalanceError: The user doesn't have enough balance of the token to be used in the transaction.\nunion ExecutionPlan = TransactionRequest | ApprovalRequired | InsufficientBalanceError\nTransaction Monitoring#\nAfter sending a transaction, AaveKit API may take a short time to process and reflect the new state in its responses due to caching and background invalidation. To reliably know when your transaction has been processed and data is up to date, use the hasProcessedKnownTransaction query.\nThis query lets you check if a transaction (by hash and operation type) has been indexed and processed by the API, so you can safely fetch updated user or market data. Note that this can only be used with transactions where the TransactionRequest has a non-null operation field.\nquery { value: hasProcessedKnownTransaction( request: { operations: [SUPPLY], txHash: \"0x1234…\" } )}\nReturns true if the transaction has been processed and data is fresh.Returns false if the transaction is not yet processed (wait and retry).\nWhen to use:\nAfter sending a transaction, poll this query until it returns true before fetching updated positions or balances.This avoids race conditions with cached data and ensures your UI reflects the latest state.\n\nScalars#\nA non comprehensive list of the custom scalars used in the Aave Protocol GraphQL API.\nBlockchainDataBigIntBigDecimalChainIdEvmAddressTxHashDateTimeA string representing binary data as a hex string.0x0000000000000000000000000000000000000000000000000000000000000020\nCommon Types#\nSome of the common types used in the Aave Protocol GraphQL API.\nCurrencyDecimalValueTokenAmountPercentValueChainA Currency object represents an ERC20 token.type Currency { \"\"\" The token address \"\"\" address: EvmAddress!\n \"\"\" The chain id \"\"\" chainId: ChainId!\n \"\"\" The token name \"\"\" name: String!\n \"\"\" The token image \"\"\" imageUrl: String!\n \"\"\" The token symbol \"\"\" symbol: String!\n \"\"\" The token decimals \"\"\" decimals: Int!}\nUtility Queries#\nSupported Chains#\nUse the chains query to list the chains supported by the Aave Protocol v3.\nquery Chains { chains { __typename name chainId icon }}\nUSD Exchange Rates#\nUse the usdExchangeRates query to get the USD exchange rate for a list of tokens.\nquery UsdExchangeRates($request: UsdExchangeRatesRequest!) { usdExchangeRates(request: $request) { __typename currency { symbol name address decimals } rate }}\nNext Steps#\nAave Markets - Learn how to interact with Aave markets.Aave Earn - Learn how to interact with Aave Earn Vaults.","tokens":1083,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258775788,"hash":"70693e214fead06f5bb82b242095ded9a796e83a"}
{"url":"https://io.net/docs/guides/intelligence/api-keys-and-secrets","domain":"io.net","title":"API Keys and Secrets - io.net","text":"The API Keys and Secrets tab within IO Intelligence provides a unified interface for managing both API keys and authentication secrets used across the platform. These credentials enable secure access to IO Intelligence APIs, whether interacting with models, agent endpoints, or third-party service integrations.\n\n​Overview\nIO Intelligence APIs provide programmatic access to powerful AI models and agents. Before making API requests, credentials must be configured correctly to authenticate calls. This section explains how to create, manage, and use both API Keys and Secrets in IO Intelligence.\n​API Keys\n​What are API Keys?\nAPI keys are authentication credentials that allow applications to securely interact with IO Intelligence APIs. They are required when accessing model inference endpoints, agent workflows, or other programmatic services.\n​Creating API Keys\nUse the following steps to create a new API key within the API Keys and Secrets tab.\nThe API key will only be displayed once. Store it securely, as it cannot be shown again.\n1Navigate to the API Keys and Secrets tab2Click Create New API Key3Fill in the New API Key Form4Confirm and Save\n​Managing API Keys\nIn the API Keys and Secrets tab, you can manage your API keys to control access to IO Intelligence APIs and maintain secure usage over time.\n\nSearch: Use the search bar to quickly locate existing API keys by name, which is especially useful when managing multiple keys.\nEdit: Update an API key’s name or permissions to reflect changes in how the key is used, such as limiting access or aligning it with a specific workflow.\nRevoke: Revoke API keys that are no longer needed to immediately disable further use and reduce security risk.\nExpiration: Configure or review expiration settings so API keys are automatically invalidated after a defined period.\n\n​Secrets\n​What are Secrets?\nSecrets are credentials or tokens required by certain agents or integrations, especially when interacting with third-party services, for example, GitHub, Jira, Linear, or other external APIs. These secrets enable authenticated access on your behalf and must be configured securely.\n​Creating Secrets\nThere are two ways to create a new secret, through the API Keys and Secrets tab or from within an Agent’s configuration.\n API Keys and Secrets Tab Agent Details ViewTo create a Secret from the API Keys and Secrets Tab, follow these steps:1Open the API Keys and Secrets tab2Click the Add Secret button3Enter your Secret DetailsFor agent-specific instructions on obtaining required secrets, open the Secrets Management tab in the Agent Details view and follow the steps outlined for that agent.4Save your SecretSecrets created here are stored securely and will be available for use across agents.If you want to configure your secret while viewing an agent, it can be created or selected directly from the Agent Details view by completing the steps below:1Navigate to the Secrets Management tab2Select an Existing Secret or Select 'Add New Secret'Select a secret that has already been configured in the API Keys and Secrets tab, or choose Add New Secret. When adding a new secret, provide a Secret Name and Secret Value in the fields provided.3Click SaveSecrets created here are automatically stored and will also be available in the API Keys and Secrets tab.\n​Managing Secrets\nThe API Keys and Secrets tab provides a centralized view of all secrets created within io.net Intelligence. From here, existing secrets can be reviewed and deleted when they are no longer in use. Deleting a secret immediately removes it and prevents it from being used by any agent or integration.\n​Using API Keys and Secrets\nAPI keys must be included in the Authorization header of all requests to IO Intelligence APIs.\nFor example:\ncurl -X GET \"https://api.intelligence.io.solutions/api/v1/models\" \\\n -H \"Authorization: Bearer $IOINTELLIGENCE_API_KEY\"\n\nReplace $IOINTELLIGENCE_API_KEY with your actual API key.\nFor agents requiring third-party integrations, secrets must be configured before those features can be used or tested. Once a secret is set, the agent will use it to authenticate with the external service.\n​FAQs\nHow do I secure my API Key?Some best practices and tips:\nDo not share your API key publicly.\nUse environment variables to store API keys securely.\nRotate your API keys periodically.\nWhat is the difference between an API key and a secret?API keys authenticate requests to io.net Intelligence APIs, while secrets authenticate access to third-party services or integrations required by certain agents.What do I do if a secret is compromised?Revoke or rotate the secret immediately from the API Keys and Secrets tab.What are the rate limits for the APIs?The IO Intelligence API offers different quotas, depending on your io.net Intelligence Payment Plan. Refer to IO Intelligence Payment for more information.Was this page helpful?","tokens":1221,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258776155,"hash":"5999ed392f8e32fc8f9cf7c6a6a2fa202576e065"}
{"url":"https://forum.openzeppelin.com/t/error-standaloneerc20-factory/1379/20","domain":"forum.openzeppelin.com","title":"Error: StandaloneERC20 Factory - Archive / SDK - OpenZeppelin Forum","text":"ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 10\n\n 7\n\n read \n\n 6\n min\n\n Sep 2019\n\n 20 / 20\n\n Nov 2019\n\n Sep 2019\n\n post by pkr on Sep 18, 2019\n\n pkr\n\n Has anyone tried creating a StandaloneERC20 Factory\nI have tried two options and both of them are returning errors:\nOption 1\nSmart Contact\naddress newStandaloneERC20 = new StandaloneERC20();\nopenzeppelin check\nTypeError: Type contract StandaloneERC20 is not implicitly convertible to expected type address.\n\nOption 2\nSmart Contact\naddress newStandaloneERC20 = new StandaloneERC20.initialize(_name, _ticker, decimals, initialSupply, _owner, _owner, _owner);\nopenzeppelin check\nDeclarationError: Identifier not found or not unique.\n\n 10\n\n 7\n\n read \n\n 6\n min\n\n post by nventuro on Sep 18, 2019\n\n nventuro\n\n Great contributor\n\nThe errror here is in the assignment, you need to cast the type explicitly to store it as an address:\naddress newStandaloneERC20 = address(new StandaloneERC20();)\n\n post by pkr on Sep 18, 2019\n\n pkr\n\n Thank you @nventuro I made the edits as suggested.\nThe previous error is fixed, and I am getting a new error:\nSmart Contract\naddress newStandaloneERC20 = address(new StandaloneERC20());\nnewStandaloneERC20.initialize(_name, _ticker, decimals, initialSupply, _owner, _owner, _owner);\nreturn newStandaloneERC20;\n\nopenzeppelin check\nMember “initialize” not found or not visible after argument-dependent lookup in address.\n\n post by pkr on Sep 18, 2019\n\n pkr\n\n Hi @abcoathup @nventuro do you have any clues on why this is failing?\nSmart Contract\npragma solidity >=0.5.0 <0.7.0;\n\n/// dependencies\nimport \"@openzeppelin/upgrades/contracts/Initializable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/token/ERC20/StandaloneERC20.sol\";\n\ncontract STFactory is Initializable, Ownable, Pausable, StandaloneERC20 {\n using SafeMath for uint256;\n /// states\n address stFactoryOwner = address(0);\n uint8 public constant DECIMALS = 18;\n uint256 public constant INITIALSUPPLY = 1 * (10 ** uint256(DECIMALS));\n\n /// functions\n /// initialize function\n function initialize() public initializer {\n stFactoryOwner = owner();\n Pausable.initialize(stFactoryOwner);\n }\n /// deployToken function\n function deployToken(\n string calldata _ticker,\n string calldata _name,\n address _owner\n )\n external\n returns(address)\n {\n address tokenAddress = _deployToken(\n _ticker,\n _name,\n _owner\n );\n return tokenAddress;\n }\n /// _deployToken internal function\n function _deployToken(\n string memory _ticker,\n string memory _name,\n address _owner\n )\n internal\n returns(address)\n {\n /// intantiate ERC20\n address newStandaloneERC20 = address(new StandaloneERC20());\n // address newStandaloneERC20 = address(new StandaloneERC20(_name, _ticker, decimals, initialSupply, _owner, _owner, _owner));\n newStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, _owner, _owner);\n return newStandaloneERC20;\n }\n}\n\nopenzeppelin check error\nTypeError: Member “initialize” not found or not visible after argument-dependent lookup in address.\nnewStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, _owner, _owner);\n\n post by abcoathup on Sep 18, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @pkr,\nAs an aside, you could create StandaloneERC20 using OpenZeppelin CLI rather than an onchain factory.\nTo resolve I modified STFactorys.sol:\n\nI removed the inheritance of StandaloneERC20 as assume STFactory doesn’t also need to be a token.\nI removed the initial value in stFactoryOwner (see documentation: https://docs.openzeppelin.com/sdk/2.5/writing-contracts#avoid-initial-values-in-field-declarations)\nI changed the type of newStandaloneERC20\n\nI changed the minter and pauser parameters to provide an empty array of addresses, as previously this was a single address.\n\npragma solidity >=0.5.0 <0.7.0;\n\n/// dependencies\nimport \"@openzeppelin/upgrades/contracts/Initializable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/token/ERC20/StandaloneERC20.sol\";\n\ncontract STFactory is Initializable, Ownable, Pausable {\n using SafeMath for uint256;\n /// states\n address stFactoryOwner;\n uint8 public constant DECIMALS = 18;\n uint256 public constant INITIALSUPPLY = 1 * (10 ** uint256(DECIMALS));\n\n /// functions\n /// initialize function\n function initialize(address owner) public initializer {\n stFactoryOwner = owner;\n Pausable.initialize(stFactoryOwner);\n }\n /// deployToken function\n function deployToken(\n string calldata _ticker,\n string calldata _name,\n address _owner\n )\n external\n returns(address)\n {\n address tokenAddress = _deployToken(\n _ticker,\n _name,\n _owner\n );\n return tokenAddress;\n }\n /// _deployToken internal function\n function _deployToken(\n string memory _ticker,\n string memory _name,\n address _owner\n )\n internal\n returns(address)\n {\n /// intantiate ERC20\n StandaloneERC20 newStandaloneERC20 = new StandaloneERC20();\n newStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, new address[](0), new address[](0));\n\n return address(newStandaloneERC20);\n }\n}\n\nCreate Factory\n$ oz create\n✓ Compiled contracts with solc 0.5.11 (commit.c082d0b4)\n? Pick a contract to instantiate STFactory\n? Pick a network development\n- Variable _pausers (PauserRole) contains a struct or enum. These are not automatically checked for storage compatibility in the current version. See https://docs.openzeppelin.com/sdk/2.5/writing_contracts.html#modifying-your-contracts for more info.\n✓ Contract STFactory deployed\nAll contracts have been deployed\n? Do you want to call a function on the instance after creating it? Yes\n? Select which function * initialize(owner: address)\n? owner (address): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1\n✓ Setting everything up to create contract instances\n✓ Instance created at 0x630589690929E9cdEFDeF0734717a9eF3Ec7Fcfe\n0x630589690929E9cdEFDeF0734717a9eF3Ec7Fcfe\n\nDeploy Token\n$ oz send-tx\n? Pick a network development\n? Pick an instance STFactory at 0x630589690929E9cdEFDeF0734717a9eF3Ec7Fcfe\n? Select which function deployToken(_ticker: string, _name: string, _owner: address)\n? _ticker (string): My Token\n? _name (string): TKN\n? _owner (address): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1\n✓ Transaction successful. Transaction hash: 0xb899f41b80e745cd34654883f87bb3c037a681c6cddb28c12bd7fc053cfe8167\nEvents emitted:\n - PauserAdded(0x61d47DA73822B4a77c4a9Bae56Ba25729669b9F1)\n - PauserRemoved(0x61d47DA73822B4a77c4a9Bae56Ba25729669b9F1)\n\n post by pkr on Sep 18, 2019\n\n pkr\n\n Thank you heaps @abcoathup …managed to create factory and deploy token is failing now\noz send-tx\n? Pick a network development\n? Pick an instance STFactory at 0xE0Ba71BF785A2d67632f399D6Ea7307e1dA94B6e\n? Select which function deployToken(_ticker: string, _name: string, _owner: address)\n? _ticker (string): ABC\n? _name (string): ABC\n? _owner (address): 0xf1a6D546A5baa618ebEBBE37f10be668239bE20e\n✖ Calling: 'deployToken' with:\n- _ticker (string): \"ABC\"\n- _name (string): \"ABC\"\n- _owner (address): \"0xf1a6D546A5baa618ebEBBE37f10be668239bE20e\"\nError while trying to send transaction to 0xE0Ba71BF785A2d67632f399D6Ea7307e1dA94B6e. Error: Returned error: VM Exception while processing transaction: revert\n\n post by pkr on Sep 18, 2019\n\n pkr\n\n And my smart contract for reference\npragma solidity >=0.5.0 <0.7.0;\n\n/// dependencies\nimport \"@openzeppelin/upgrades/contracts/Initializable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/token/ERC20/StandaloneERC20.sol\";\n\ncontract STFactory is Initializable, Ownable, Pausable {\n using SafeMath for uint256;\n /// states\n address stFactoryOwner;\n uint8 public constant DECIMALS = 18;\n uint256 public constant INITIALSUPPLY = 1 * (10 ** uint256(DECIMALS));\n /// functions\n /// initialize function\n function initialize(address _owner) public initializer {\n stFactoryOwner = _owner;\n Pausable.initialize(stFactoryOwner);\n }\n /// deployToken function\n function deployToken(\n string calldata _ticker,\n string calldata _name,\n address _owner\n )\n external\n returns(address)\n {\n address tokenAddress = _deployToken(\n _ticker,\n _name,\n _owner\n );\n return tokenAddress;\n }\n /// _deployToken internal function\n function _deployToken(\n string memory _ticker,\n string memory _name,\n address _owner\n )\n internal\n returns(address)\n {\n address[] memory minterArray;\n minterArray[0] = _owner;\n address[] memory pauserArray;\n pauserArray[0] = _owner;\n /// intantiate ERC20\n StandaloneERC20 newStandaloneERC20 = new StandaloneERC20();\n newStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, minterArray, pauserArray);\n // newStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, new address[](0), new address[](0));\n return address(newStandaloneERC20);\n }\n}\n\n post by pkr on Sep 18, 2019\n\n pkr\n\nI understand we can create an instance of StandaloneERC20 using OZ CLI.\nHow can we create a StandaloneERC20 Factory using OZ CLI and store the contract addresses on-chain?\n\n post by abcoathup on Sep 18, 2019\n\n abcoathup\n\n Great contributor\n\n pkr\n\n The arrays need to be initialized.\n address[] memory minterArray = new address[](1);\n minterArray[0] = _owner;\n address[] memory pauserArray = new address[](1);\n pauserArray[0] = _owner;\n\nI also added an event to log the address of the newly deployed token.\nSTFactory\npragma solidity >=0.5.0 <0.7.0;\n\n/// dependencies\nimport \"@openzeppelin/upgrades/contracts/Initializable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/token/ERC20/StandaloneERC20.sol\";\n\ncontract STFactory is Initializable, Ownable, Pausable {\n using SafeMath for uint256;\n /// states\n address stFactoryOwner;\n uint8 public constant DECIMALS = 18;\n uint256 public constant INITIALSUPPLY = 1 * (10 ** uint256(DECIMALS));\n\n event TokenDeployed(address token);\n\n /// functions\n /// initialize function\n function initialize(address _owner) public initializer {\n stFactoryOwner = _owner;\n Pausable.initialize(stFactoryOwner);\n }\n /// deployToken function\n function deployToken(\n string calldata _ticker,\n string calldata _name,\n address _owner\n )\n external\n returns(address)\n {\n address tokenAddress = _deployToken(\n _ticker,\n _name,\n _owner\n );\n return tokenAddress;\n }\n /// _deployToken internal function\n function _deployToken(\n string memory _ticker,\n string memory _name,\n address _owner\n )\n internal\n returns(address)\n {\n address[] memory minterArray = new address[](1);\n minterArray[0] = _owner;\n address[] memory pauserArray = new address[](1);\n pauserArray[0] = _owner;\n /// intantiate ERC20\n StandaloneERC20 newStandaloneERC20 = new StandaloneERC20();\n newStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, minterArray, pauserArray);\n // newStandaloneERC20.initialize(_name, _ticker, DECIMALS, INITIALSUPPLY, _owner, new address[](0), new address[](0));\n\n emit TokenDeployed(address(newStandaloneERC20));\n\n return address(newStandaloneERC20);\n }\n}\n\nCreate\n$ oz create\n✓ Compiling contracts with Truffle, using settings from truffle.js file\nTruffle output:\n\nCompiling your contracts...\n===========================\n> Compiling ./contracts/Migrations.sol\n> Compiling ./contracts/STFactory.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/GSN/Context.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/Roles.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/roles/MinterRole.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/roles/PauserRole.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Detailed.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Mintable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Pausable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/IERC20.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/StandaloneERC20.sol\n> Compiling @openzeppelin/upgrades/contracts/Initializable.sol\n> Artifacts written to /mnt/c/Users/andre/Documents/projects/forum/tokenfactory/build/contracts\n> Compiled successfully using:\n - solc: 0.5.8+commit.23d335f2.Emscripten.clang\n\n? Pick a contract to instantiate STFactory\n? Pick a network development\n✓ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1568857681604\n✓ Contract STFactory deployed\nAll contracts have been deployed\n? Do you want to call a function on the instance after creating it? Yes\n? Select which function * initialize(_owner: address)\n? _owner (address): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1\n✓ Setting everything up to create contract instances\n✓ Instance created at 0x8914a9E5C5E234fDC3Ce9dc155ec19F43947ab59\n0x8914a9E5C5E234fDC3Ce9dc155ec19F43947ab59\n\nDeploy token\n$ oz send-tx\n? Pick a network development\n? Pick an instance STFactory at 0x8914a9E5C5E234fDC3Ce9dc155ec19F43947ab59\n? Select which function deployToken(_ticker: string, _name: string, _owner: address)\n? _ticker (string): My Token\n? _name (string): TKN\n? _owner (address): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1\n✓ Transaction successful. Transaction hash: 0xbff08f640515d175a33eb06e7002a2430721414dd022a3534f9e4d325d5c1dd5\nEvents emitted:\n - PauserRemoved(0x6edEA6a3AC207DDD1173448f62eb0819bb0f571A)\n - TokenDeployed(0x6edEA6a3AC207DDD1173448f62eb0819bb0f571A)\n\n post by abcoathup on Sep 18, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @pkr,\n\nYou could create a registry contract and programmatically create tokens and update the registry, though that doesn't sound better than using an on-chain factory.\n\nPlease be aware that the tokens created via the factory are not upgradeable whilst the tokens created via the CLI can be upgraded.\n\n post by pkr on Sep 19, 2019\n\n pkr\n\n You’re such a rock star mate.\nThank you @abcoathup the recent changes work.\nCreate Contract\n$ oz create\nNothing to compile, all contracts are up to date.\n? Pick a contract to instantiate STFactory\n? Pick a network development\nAll contracts are up to date\n? Do you want to call a function on the instance after creating it? Yes\n? Select which function * initialize(_owner: address)\n? _owner (address): 0xf1a6D546A5baa618ebEBBE37f10be668239bE20e\n✓ Instance created at 0x591db31df99717845B53e3Fe58Bbd973CFfcF398\n0x591db31df99717845B53e3Fe58Bbd973CFfcF398\n\nDeploy Token\n$ oz send-tx\n? Pick a network development\n? Pick an instance STFactory at 0x591db31df99717845B53e3Fe58Bbd973CFfcF398\n? Select which function deployToken(_ticker: string, _name: string, _owner: address)\n? _ticker (string): ABC\n? _name (string): ABC\n? _owner (address): 0xf1a6D546A5baa618ebEBBE37f10be668239bE20e\n✓ Transaction successful. Transaction hash: 0x4768347d816ebfdf32cceb8a280760c1d1c9c9da79503b09dd9538887e7cedda\nEvents emitted: \n - PauserRemoved(0x19Fc5dE13D76ead5B622c9B73DA37cD48ceb1181)\n - TokenDeployed(0x19Fc5dE13D76ead5B622c9B73DA37cD48ceb1181)\n\nCheck Balance 1\n$ oz balance\n? Enter an address to query its balance 0xf1a6D546A5baa618ebEBBE37f10be668239bE20e\n? Pick a network development\nBalance: 99.7921448 ETH\n99792144800000000000\n\nCheck Balance 2\n$ oz balance\n? Enter an address to query its balance 0x19Fc5dE13D76ead5B622c9B73DA37cD48ceb1181\n? Pick a network development\nBalance: 0 ETH\n0\n\nHow can I check the ERC20 token balance? Is there a oz CLI command?\nAlso thanks for the suggestion on Registry contract – I am almost finished building one, will post soon. But I want to call the oz CLI from this Registry contract, such that the new contracts/tokens are upgradeable (if needed).\n\n post by abcoathup on Sep 19, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @pkr,\nCurrently there isn’t an OpenZeppelin CLI command to interact with contracts not created via the CLI.\nI created a new truffle based project, so I could use truffle console and initialized it with truffle and openzeppelin.\nnpm init -y\nnpm i truffle \nnpx truffle init \noz init \noz link @openzeppelin/contracts-ethereum-package \nnpm i @openzeppelin/upgrades \n\nI added the factory contract to the project in my IDE.\nI updated truffle-config.js to uncomment out the development network.\nI then created the factory contract and deployed a new token (copying the address emitted from the event) using the OpenZeppelin CLI\nI then interacted using truffle console.\n$ truffle console \ntruffle(development)> token = await StandaloneERC20.at(\"0x6edEA6a3AC207DDD1173448f62eb0819bb0f571A\")\ntruffle(development)> await token.symbol()\n\n post by pkr on Sep 19, 2019\n\n pkr\n\n STRegistry Smart Contract\npragma solidity >=0.5.0 <0.7.0;\n\n/// dependencies\nimport \"@openzeppelin/upgrades/contracts/Initializable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\";\nimport \"@openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\";\nimport \"./STFactory.sol\";\n\ncontract STRegister is Initializable, Ownable, Pausable, STFactory {\n using SafeMath for uint256;\n /// states\n address stRegisterOwner;\n uint256 registeredTickerCount;\n uint256 registeredTokenCount;\n\n struct STTickerRegister {\n string _ticker;\n uint256 _registrationDate;\n address _owner;\n }\n mapping (uint256 => STTickerRegister) tickers;\n\n struct STTokenRegister {\n string _ticker;\n string _name;\n uint256 _registrationDate;\n address _tokenAddress;\n address _owner;\n }\n mapping (uint256 => STTokenRegister) tokens;\n\n /// events\n /// emit when a ticker is registered\n event RegisterTicker(\n string _ticker,\n uint256 _registrationDate,\n address indexed _owner\n );\n /// emit when a token is registered\n event RegisterToken(\n string _ticker,\n string _name,\n uint256 _registrationDate,\n address indexed _tokenAddress,\n address indexed _owner\n );\n\n /// modifiers\n\n /// functions\n /// initialize function\n function initialize(address _owner) public initializer {\n stRegisterOwner = _owner;\n Pausable.initialize(stRegisterOwner);\n registeredTickerCount = 0;\n registeredTokenCount = 0;\n }\n /// registerNewTicker function\n function registerNewTicker(\n string memory _ticker,\n address _owner\n )\n public whenNotPaused onlyOwner\n {\n _addTicker(_ticker, now, _owner);\n }\n /// _addTicker internal function\n function _addTicker(\n string memory _ticker,\n uint256 _registrationDate,\n address _owner\n )\n internal\n {\n uint256 idx = registeredTickerCount;\n tickers[idx]._ticker = _ticker;\n tickers[idx]._registrationDate = _registrationDate;\n tickers[idx]._owner = _owner;\n registeredTickerCount++;\n emit RegisterTicker(_ticker, _registrationDate, _owner);\n }\n /// registerNewToken function\n function registerNewToken(\n string memory _ticker,\n string memory _name,\n address _owner\n )\n public whenNotPaused onlyOwner\n {\n address _tokenAddress = _deployToken(_ticker, _name, _owner);\n _addToken(_ticker, _name, now, _tokenAddress, _owner);\n }\n /// _addToken internal function\n function _addToken(\n string memory _ticker,\n string memory _name,\n uint256 _registrationDate,\n address _tokenAddress,\n address _owner\n )\n internal\n {\n uint256 idx = registeredTokenCount;\n tokens[idx]._ticker = _ticker;\n tokens[idx]._name = _name;\n tokens[idx]._registrationDate = _registrationDate;\n tokens[idx]._tokenAddress = _tokenAddress;\n tokens[idx]._owner = _owner;\n registeredTokenCount++;\n emit RegisterToken (_ticker, _name, _registrationDate, _tokenAddress, _owner);\n }\n}\n\nCreate Contract\n$ oz create\nNothing to compile, all contracts are up to date.\n? Pick a contract to instantiate STRegister\n? Pick a network development\n✓ Added contract STRegister\n✓ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1568869704928\n✓ Contract STFactory deployed\n✖ Validating and deploying contract STRegister\nSTRegister deployment failed with error: Returned error: VM Exception while processing transaction: out of gas\n\nColour Commentary\nLooks like it doesn’t like something – STFactory is deployed, but STRegistry ran out of gas.\n\n post by abcoathup on Sep 19, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @pkr,\nI was able to deploy STRegister using OpenZeppelin CLI (though it was using truffle-config.js for config.\nYou may need to increase your configured gas limit.\n$ oz create\n✓ Compiling contracts with Truffle, using settings from truffle.js file\nTruffle output:\n\nCompiling your contracts...\n===========================\n> Compiling ./contracts/Migrations.sol\n> Compiling ./contracts/STFactory.sol\n> Compiling ./contracts/STRegister.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/GSN/Context.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/Roles.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/roles/MinterRole.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/access/roles/PauserRole.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/lifecycle/Pausable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/math/SafeMath.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/ownership/Ownable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Detailed.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Mintable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/ERC20Pausable.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/IERC20.sol\n> Compiling @openzeppelin/contracts-ethereum-package/contracts/token/ERC20/StandaloneERC20.sol\n> Compiling @openzeppelin/upgrades/contracts/Initializable.sol\n> Artifacts written to /mnt/c/Users/andre/Documents/projects/forum/tokenfactory/build/contracts\n> Compiled successfully using:\n - solc: 0.5.8+commit.23d335f2.Emscripten.clang\n\n? Pick a contract to instantiate STRegister\n? Pick a network development\n✓ Deploying @openzeppelin/contracts-ethereum-package dependency to network dev-1568939673368\n✓ Contract STFactory deployed\n✓ Contract STRegister deployed\nAll contracts have been deployed\n? Do you want to call a function on the instance after creating it? Yes\n? Select which function * initialize(_owner: address)\n? _owner (address): 0x13ebd3443fa5575F0Eb173e323D8419F7452CfB1\n✓ Setting everything up to create contract instances\n✓ Instance created at 0x26b4AFb60d6C903165150C6F0AA14F8016bE4aec\n0x26b4AFb60d6C903165150C6F0AA14F8016bE4aec\n\n post by pkr on Sep 19, 2019\n\n pkr\n\n Thank you @abcoathup let me try this approach w/ truffle + oz\nShould I be using the following steps for all my oz projects?\nnpm init -y\nnpm i truffle \nnpx truffle init \noz init \noz link @openzeppelin/contracts-ethereum-package \nnpm i @openzeppelin/upgrades \n\nNext Steps:\n\nWant to deploy these 2 contracts in Rinkeby network\nUser Terminal to configure APIs (Transaction, GraphQL)\nWire-up the DApp\n\n post by abcoathup on Sep 19, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @pkr,\nI only used Truffle and OpenZeppelin as that is the last project I had around with your code in. You should be fine with OpenZeppelin CLI by itself, you probably just need to increase the gas limit.\nDeploying your contracts to a public network is straight forward, there is a guide in the documentation: https://docs.openzeppelin.com/sdk/2.5/public-deploy\n\n Split this topic on Sep 19, 2019\n\n 3 posts were split to a new topic: Openzeppelin accounts not working\n\n post by pkr on Sep 19, 2019\n\n pkr\n\nWhat did you increase it by, to make it work?\nnetworks.js\nrequire('dotenv').config();\n\nconst HDWalletProvider = require('truffle-hdwallet-provider');\nconst infuraProjectId = process.env.INFURA_PROJECT_ID;\n\nmodule.exports = {\n networks: {\n development: {\n protocol: 'http',\n host: 'localhost',\n port: 8545,\n gas: 50000000,\n gasPrice: 5e9,\n networkId: '*',\n },\n ropsten: {\n provider: () => new HDWalletProvider(process.env.DEV_MNEMONIC, \"https://ropsten.infura.io/v3/\" + infuraProjectId),\n networkId: 3, // Ropsten's id\n },\n rinkeby: {\n provider: () => new HDWalletProvider(process.env.DEV_MNEMONIC, \"https://rinkeby.infura.io/v3/\" + infuraProjectId),\n networkId: 4, // Rinkeby's id\n },\n mainnet: {\n provider: () => new HDWalletProvider(process.env.DEV_MNEMONIC, \"https://mainnet.infura.io/v3/\" + infuraProjectId),\n networkId: 1, // Mainnet's id\n },\n },\n};\n\n post by abcoathup on Sep 20, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @pkr,\nTry upping the gas limit to 6000000.\nAlso I recommend that for mainnet deployment you use a different mnemonic than the one you use for the testnets. e.g. process.env.MAINNET_MNEMONIC\n\n 2 months later\n\n Split this topic on Nov 13, 2019\n\n A post was split to a new topic: How to use the CLI with contracts created via a factory contract\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Accessing StandaloneERC20 ABI that was deployed using a Factory\n\n SDK\n\n erc20\n\n 12\n\n 3.2k\n\n Sep 2019\n\n Create an ERC20 using OpenZeppelin CLI, without writing Solidity\n\n Guides and Tutorials\n\n 0\n\n 3.8k\n\n Jul 2020\n\n Deploying token contract with user defined parameters\n\n SDK\n\n 1\n\n 1.6k\n\n Apr 2020\n\n ERC20 metadata and ERC20Detailed\n\n Contracts\n\n 19\n\n 21.0k\n\n Sep 2021\n\n Leveraging OpenZeppelin with Sound and Gigantic Steps\n\n Contracts\n\n erc20,erc721\n\n 30\n\n 2.8k\n\n Mar 2019","tokens":6627,"squid":"ink-security_audits","role":"Sentinel","at":1791258780946,"hash":"39480dcaefa9d6238b781b78df71ea68e10fcbd8"}
{"url":"https://forum.openzeppelin.com/c/archive/sdk/19","domain":"forum.openzeppelin.com","title":"Latest Archive/SDK topics - OpenZeppelin Forum","text":"Latest topics in SDK\n\n SDK\n\n OpenZeppelin SDK community support - Maintenance only\n\n Archive\n\n SDK\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Deployment Issues using npx oz deploy\n\n 1\n\n 1.0k\n\n Aug 2021\n\n Deploying Smart Contracts Using CREATE2 tutorial query error `Maximum call stack size exceeded`\n\n 1\n\n 1.3k\n\n Jul 2021\n\n Source “@openzeppelin …. ” not found: File import callback not supported\n\n 4\n\n 9.9k\n\n Jun 2021\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use the CLI with contracts created via a factory contract\n\n 11\n\n 1.9k\n\n Jun 2021\n\n Deployment failed with error: Returned error: sender doesn’t have enough funds to send tx\n\n 8\n\n 4.4k\n\n Jun 2021\n\n File import callback not supported\n\n 23\n\n 33.4k\n\n May 2021\n\n Problem as sometimes initialize() can’t be called\n\n 5\n\n 5.6k\n\n May 2021\n\n Upgradeable ERC20 token with partial burn on transfer\n\n 7\n\n 5.6k\n\n May 2021\n\n Ownable contract owner is always the 0 address\n\n 5\n\n 10.8k\n\n Mar 2021\n\n Verify upgradeable logic contract on Etherscan\n\n 3\n\n 5.6k\n\n Mar 2021\n\n Zos install fails\n\n 5\n\n 2.2k\n\n Mar 2021\n\n How to specify the gas price for the deploy command of the CLI?\n\n 2\n\n 3.8k\n\n Mar 2021\n\n How is the mapping of storage done in upgradeable contracts?\n\n proxies,upgrades\n\n 5\n\n 3.9k\n\n Feb 2021\n\n Add new state variable to base contract for upgradeable contracts\n\n 6\n\n 5.2k\n\n Jan 2021\n\n ZeppelinOS proxy pattern and structs\n\n proxies\n\n 7\n\n 3.2k\n\n Jan 2021\n\n Are there restrictions on modifying enums and structs in upgradeable contracts?\n\n 2\n\n 4.0k\n\n Jan 2021\n\n Updating struct cause damage to data\n\n 3\n\n 2.9k\n\n Jan 2021\n\n How to use a struct in an upgradable contract\n\n 5\n\n 5.7k\n\n Jan 2021\n\n Msg.sender.transfer runs out of gas on a payable upgradeable proxy contract\n\n 2\n\n 3.9k\n\n Jan 2021\n\n Every call results in Error: VM execution error after upgrade\n\n 6\n\n 3.3k\n\n Jan 2021\n\n Verify with OpenZeppelin CLI\n\n 7\n\n 2.4k\n\n Dec 2020\n\n `oz call` Cannot read property ‘message’ of null\n\n 5\n\n 1.7k\n\n Dec 2020\n\n Compile error: File import callback not supported\n\n 2\n\n 2.5k\n\n Dec 2020\n\n File import callback not supported on MacOS\n\n 4\n\n 3.8k\n\n Dec 2020\n\n How to add OpenZeppelin compiler into truffle config as an external compiler?\n\n 3\n\n 1.8k\n\n Nov 2020\n\n Deploying to Quorum with OpenZeppelin CLI\n\n 3\n\n 2.9k\n\n Nov 2020\n\n Get the Transaction Hash from createProxy?\n\n 5\n\n 1.6k\n\n Oct 2020\n\n Are upgradable and non upgradable contracts in the same truffle project supported?\n\n 4\n\n 2.5k\n\n Oct 2020\n\n Customize OpenZeppelin CLI deploy script to assign environment variable upon deployment?\n\n 2\n\n 1.1k\n\n Oct 2020","tokens":665,"squid":"ink-security_audits","role":"Sentinel","at":1791258793850,"hash":"59bda91bd5227e5ffc4d464f292aed9d273beb94"}
{"url":"https://vote.optimism.io/proposals/20786906783410562827604966535632249886121364127991196139441416428424454630648","domain":"vote.optimism.io","title":"Security Council Elections Cohort B M...","text":"ProposalsVotersConnect  Wallet Approval Vote Proposal by The Optimism FoundationSecurity Council Elections Cohort B MembersProposal Visualization Proposed Transactions // Alex SotoReveal 7 more optionsFollowing the guidelines of the Security Council Charter, the Token House will hold elections for Cohort B of the Optimism Security Council. The top 6 candidates with the highest votes will be elected to Cohort B and serve a 12-month term, subject to Foundation confirmation. If any candidate is not confirmed by the Foundation, the runner up will take their position.\nThis vote will utilize approval voting, allowing delegates to vote for any number of nominees. In approval or ranked choice votes, delegates may vote for themselves as long as they also cast votes for the remaining elected positions.\n\nAlex Soto\nMatthew Slipper\nINK Foundation\ndonnoh\nOP Labs\nMaster Mojo\nTest in Prod\ndcbuilder.eth\n\nIt's important to note that no more than 1 elected member may be associated with a particular entity, or that entity’s employees or affiliates.ResultsVotes OP Labs15,690,018 78.41% INK Foundation14,729,799 73.61% donnoh13,758,289 68.76% dcbuilder.eth12,880,562 64.37% Matthew Slipper12,379,428 61.86% Test in Prod10,221,614 51.08% Alex Soto7,524,312 37.60% Master Mojo3,647,532 18.22% Quorum 22,901,213 Current 20,009,092 DEFEATEDEnded 3:03 pm Jun 03, 2026In this top-choices style proposal, the top 6 options will be executed. Voters can select up to 8 options. If the quorum is not met, no options will be executed.Security Council Elections Cohort B M...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":414,"squid":"ink-governance","role":"Council Listener","at":1791258807381,"hash":"bb2d03769ab970965fe013636eee410dbf82141d"}
{"url":"https://docs.pyth.network/price-feeds/pro/payload-reference","domain":"docs.pyth.network","title":"Payload Reference | Pyth Developer Hub","text":"Pyth ProPayload ReferenceUnderstand Pyth Pro payload structures, available properties, and binary formatsThis page provides a comprehensive reference for understanding Pyth Pro payload structure, field specifications, and available data formats.\nThis reference is designed for both technical and non-technical stakeholders\nto understand Pyth Pro's data offering. For implementation details, see our\nintegration guides for onchain\nintegration, or subscribe to prices\nfor offchain consumption via SDKs.\nWhat is a Pyth Pro Payload?\nA Pyth Pro payload is a real-time data update containing financial market information with cryptographic signatures for verification on blockchain. When you subscribe to Pyth Pro price feeds, you receive StreamUpdated messages containing this structured data.\nQuick reference\nPropertyTypeScopeDescriptionfeedUpdateTimestampu64AllTimestamp when price was last generated for this feed (μs).publisherCountu16AllNumber of contributing publishers.exponenti16AllDecimal exponent: actual_price = mantissa × 10^exponent.marketSessionstringAllSession: regular, preMarket, postMarket, overNight, closed.pricei64SpotAggregate market price (mantissa). Use with exponent for actual price.confidencei64SpotPrice uncertainty across publishers; higher = more disagreement.bestBidPricei64SpotTightest non-overlapping bid across publishers. (Experimental)bestAskPricei64SpotTightest non-overlapping ask across publishers. (Experimental)emaPricei64SpotExponential moving average of the price.emaConfidencei64SpotExponential moving average of the confidence.fundingRatei64DerivativesFunding rate (perpetual futures).fundingTimestampu64DerivativesWhen funding rate was last calculated (μs).fundingRateIntervalu64DerivativesInterval between funding updates (μs).\nScope: All = every feed type; Spot = spot price feeds; Derivatives = funding rate feeds.\nExperimentalThe bestBidPrice and bestAskPrice fields are experimental. These\nfields are not yet covered by automated data quality assurance, so their\naccuracy and reliability may vary. Use with caution in production systems.\nCustomizable Payload: The payload structure is customizable based on the\nproperties you request in your subscription. Only the fields you specify will\nbe included in the response. See Property\nSpecifications for detailed information on each\nfield.\nStream Response Structure\n\nWhen you receive a StreamUpdated message from Pyth Pro, it contains the following structure:\nHover over a field to highlight itFieldTypetypestringsubscriptionIdnumberparsedobjecttimestampUsstringpriceFeedsarraypriceFeedIdu32pricei64bestBidPricei64bestAskPricei64publisherCountu16exponenti16confidencei64marketSessionstringfeedUpdateTimestampu64emaPricei64emaConfidencei64evmobjectencodingstringdatastring{\n \"type\": \"streamUpdated\",\n \"subscriptionId\": 1,\n \"parsed\": {\n \"timestampUs\": \"1758690761750000\",\n \"priceFeeds\": [\n {\n \"priceFeedId\": 1,\n \"price\": \"11223872331053\",\n \"bestBidPrice\": \"11222498842767\",\n \"bestAskPrice\": \"11224513591935\",\n \"publisherCount\": 9,\n \"exponent\": -8,\n \"confidence\": 1373488286,\n \"marketSession\": \"regular\",\n \"feedUpdateTimestamp\": 1758690761750000,\n \"emaPrice\": \"11223843563091\",\n \"emaConfidence\": 1347630281\n }\n ]\n },\n \"evm\": {\n \"encoding\": \"base64\",\n \"data\": \"0x...\"\n }\n}\n\nProperty Specifications\nBased on the protocol specification, here are the technical details for each property in a price feed.\nFeed Structure\n\nFeed ID: u32 - Unique identifier for the price feed\nProperties: Fields included based on your subscription request parameters\n\nCore Price Properties\nMain aggregate price calculated from all contributing publishers, represented as mantissa.Typeoptional non-zero i64AvailabilityOnly included if requested in subscription propertiesAlgorithmSee price aggregation for the current algorithmInvariantsNon-zero when present (null values filtered out)UsageThe price is stored in two parts: an integer mantissa value (the price field) and a power-of-ten exponent. The actual decimal representation of the price is given by: decimal_price = price × 10^exponent. For example: 1006900000000 × 10^(-8) = $10,069.00\nPrice Availability Semantics: The price field may be absent from the\nresponse when no price has been produced for a feed — for example, during\noff-hours or when a feed has been recently activated.Starting March 23, 2026, once a feed produces its first valid price, a\nprice will always be provided for that feed going forward, even during\noff-hours (the most recent price will be carried forward).To determine when the price was generated, consumers must check\nfeedUpdateTimestamp:\nIf feedUpdateTimestamp is equal to the update's timestampUs, the price\nwas generated as part of this update.\nIf feedUpdateTimestamp is earlier than timestampUs, the price is the\nmost recent available price, carried forward from the time indicated by\nfeedUpdateTimestamp, not generated at the current update time.\nConsumers should always rely on feedUpdateTimestamp to understand the\nfreshness and origin of the price.\nMarket Depth Properties\nBest bid and best ask represent the tightest non-overlapping spread across publishers — the highest publisher bid and the lowest publisher ask selected such that bestBidPrice < bestAskPrice, with crossing quotes excluded. For a detailed comparison with confidence intervals, see Understanding Price Data.\nExperimentalThe bestBidPrice and bestAskPrice fields are experimental. These fields\nare not yet covered by automated data quality assurance, so their accuracy and\nreliability may vary. Use with caution in production systems.\n\nDerivatives Properties\nAvailable only for FundingRate feed types (perpetual futures contracts).\n\nSubscription Channels\nPyth Pro offers multiple delivery channels to match your latency and frequency requirements:\nChannelDescriptionUse Casesreal_timeUpdates sent immediately when new price is available (no faster than 1ms, no slower than 50ms)High-frequency trading, real-time analyticsfixed_rate@1msUpdates every 1 millisecondUltra-low latency applicationsfixed_rate@50msUpdates every 50 millisecondsLow-latency trading systemsfixed_rate@200msUpdates every 200 millisecondsStandard trading applicationsfixed_rate@1000msUpdates every 1 secondGeneral applications, dashboards\nBinary Formats & Signature Schemes\nPyth Pro provides multiple cryptographic formats to support different blockchain ecosystems. When you subscribe, you can request specific binary formats using the formats parameter.\nFormatAlgorithmSignatureVerificationUseBest Forevmsecp256k1 ECDSA65 bytesRecoverable ECDSAOnchainEthereum, Arbitrum, Optimism, Polygon, BSC, AvalanchesolanaEd25519 EdDSA64 bytesDirect Ed25519OnchainSolana, Fogo, Ed25519-native chainsleEcdsasecp256k1 ECDSA (little-endian)65 bytesCustom implementationOnchainCustom implementations, Little-endian chainsleUnsignedNoneNoneN/AOffchainDevelopment, Testing, Analytics, Backend services\nHow to Choose: Select the format based on your target blockchain's native\ncryptographic primitives. The evm format works for all EVM chains, solana\nfor Ed25519-native chains, and leUnsigned for offchain applications that\ndon't need signature verification.HistoryPrevious PageRate LimitsRate limiting policies for Pyth Pro APIs","tokens":1802,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258823513,"hash":"954e41c606ea342435fc9efaa38a6150bf7942e5"}
{"url":"https://atlas.optimism.io/project/0x6ba8ed349d1c9cfa805c15c6d7ba9306b1f0784cc25de5945c98d265485b32d2","domain":"atlas.optimism.io","title":"Project: Opinion Harvesting Spaces - OP Atlas","text":"Atlas will be discontinued on September 18, 2026. Please save any information you need before then.ProjectSocialByAlex SotoIf we want to increase the percentage of token holders that feel confident voting in Optimism DAO, then enabling spaces where they can go to ‘listen to opposing opinions on the matter’ and share their doubts can encourage them to have a more active participation.\n\nS6 Intent 1: Progress Towards Decentralization\n\nProposing Delegate/Citizen: @alexsotodigital \n\nTotal grant amount: 7K OP\n\nGoal: Increase the percentage of token holders that feel confident voting in Optimism DAO\n\nShould this Mission be fulfilled by one or multiple applicants? Multiple\n\nHow will this Mission Request help accomplish the above Intent?\n\nStarting from the fact that OP token holders tend not to feel confident due to lack of context (not so much of the update proposal but of the implications it has), the proposal is to bring in voices that have expressed different opinions on the matter (of an update with more than 15% vetos) and make them delve deeper into their motives.\n\nIn this way, by facilitating a safe space for conversation, we can use conflict as a means to strengthen ties between various parties and enable token holders and delegates who want to gain context to listen to different positions and form their own opinion.\n\nBelow the proposal for the structure of the space (assuming 1:30 hrs):\n\n10 min - Landing and check-in\n10 min - Framing of the topic (by Facilitation Team)\n20 min - Veto debate (by two opposing voices)\n10 min - Breakout Rooms\n20 min - Questions and answers (by panelist and citizens)\n20 min - Collective harvesting\n\nAlthough, there may also be spaces for discussion on key issues that are about to be voted on. In this format, small discussion groups can be set up to promote peer learning.\n\nProcess:\n\n- When a proposal goes beyond having more than 15% vetos, a call is opened for portfolios that have already voted (and who perceive they have a very strong position on the matter) to participate in a space with a specific date.\n- The facilitating team (of around 3 people) contacts the people chosen as panelists and establishes behavioral agreements to maintain a safe and respectful space.\n- A publication is made with the public event. Those people who register can receive an attestation of attendance if they participate.\n- The call is facilitated by a team, allowing citizens to listen and express themselves.\n- A record and minute is made that summarizes the points (which can be translated into infographics, memes and other content to trigger the conversation in Fancaster and other channels).\n\nWhat is required to execute this Mission Request?\n\nFacilitation Team is responsible for:\n\n- call, selection and preparation of panelists\n- facilitation of sessions to guarantee harvest of learning\n- creation of materials that facilitate sense-making for citizens who have not been able to attend.\n- How should governance participants measure impact upon completion of this Mission?\n\nMilestones:\n\nToken holders and delegates attendance at sessions\nParticipation of token holders in voting on Optimism DAO \n\nMetrics:\n\nIncrease of total votable supply of OP, highlighted as a core metric in Intent 1’s ratification\nIncrease in number of voters in Optimism DAOalexsotodigitaltwitter.com/alexsotodigital","tokens":836,"squid":"ink-governance","role":"Council Listener","at":1791258830880,"hash":"462bf8770eb1ddb7ded91df8e244315c00a739f8"}
{"url":"https://arbitrum.io/solutions/consumer","domain":"arbitrum.io","title":"Arbitrum for Consumer Apps – Build for Mass Adoption","text":"Where Big IdeasMEET MASS ADOPTIONBuilding a consumer app that millions love requires a network that feels invisible. Arbitrum provides access to speed, low costs, and massive scale to make your onchain experience feel as smooth and intuitive as today’s most popular social applications.Start BuildingGet in TouchThe Engine for Mainstream Success$11.5B+ Total Value SecuredSource A testament to the trust and liquidity driving the next era of blockchain innovation.336.6K+ Daily Active WalletsSource A steady base of users who return to Arbitrum for their daily onchain activity.6,000* Transactions Per Second*Source (Theoretical Limit)High throughput can handle large bursts of onchain activity.View Onchain DataYour Shortcut to Millions of UsersExpand your reach through ecosystem support, technical resources, and opportunities for user acquisition.01 of 03BlackbirdGenre: SocialRewards, access, and benefits at restaurants you love.Read MoreTechnical SupportHands-on assistance, world-class documentation, and access to a vibrant developer community. From initial concept to live launch.GROWTH SUPPORTExplore marketing programs, grant opportunities, and partnerships within the Arbitrum ecosystem—all structured to expand reach and power large-scale adoption.Plug into a Thriving Sovereign NationArbitrum is where consumers connect, interact, and transact across a network teeming with active users and digital culture.Learn MoreAaveAave is a decentralized non-custodial liquidity protocol where users can participate as depositors or borrowers.Learn MorePendlePendle enables the permissionless tokenization and trading of yield, unlocking various strategies such as obtaining fixed yield, long crypto yields, or trade yields of any assets on Pendle.Learn MoreGMXGMX: the on-chain Decentralised Perpetual Exchange with deep liquidity and low fees.Learn MoreVariationalThe most rewarding place to trade perps. Enjoy zero fees while earning loss refunds, spread discounts, and platform credits from your normal trading activity.Learn MoreOstiumTrade any strategy on any asset: from indices and currencies to metals, energy, and crypto.Learn MoreEtherealNext generation decentralized spot and perpetuals trading powered by USDe.Learn MoreUSD.AIUSD.AI is a yield-bearing synthetic dollar protocol backed by GPU mortgages.Learn MoreMorphoLend and borrow using the most secure, efficient, flexible lending protocol on Arbitrum.Learn MoreThe BeaconDive into The Beacon, a roguelite RPG game in development. Experience the thrilling demo now at play.thebeacon.gg and become part of our growing community!Learn MoreOthersideWhere the swamp ends, Otherside begins.Learn MoreWildcard2v2 Collectible Card Action Game where strategy and skill collide. Choose your champion, craft your deck, cast summons, and battle for victory in epic arenas.Learn MoreL3E7World's First 3D LBS (Location-Based Service) Game. Cloning the Whole Earth into a Cyberpunk Metaverse.Learn MoreGolden TidesBuild a crew and set sail to compete against 31 other teams in a quest-packed race for treasure. Plunge into this free-to-play fantasy pirate Adventure MOBA!Learn MoreMy Pet HooliganAn interactive entertainment experience from AMGI Studios. Social-action multiplayer game in Early Access! Launching on Xbox.Learn MoreHyveHyve Labs is building rewarding social GameFi experiences that you can play seamlessly across any platform.Learn MoreRIFTSTORMRiftstorm is a co-op looter-shooter with roguelite that charges players with the defense of our world from mythic threats.Learn MoreBlackBirdRewards, access, and benefits at restaurants you love.Learn MoreEl DoradoLa SuperApp de Stablecoins para Latinoamérica.Learn MoreFarcasterA sufficiently decentralized social network.Learn MorePeanutPeanut is the easiest way to send and receive crypto payments cross-chain via secure links.Learn MoreBerryWith Berry, you can invest in stocks and assets you use every day, including ETFs like the S&P 500.Learn MoreOpenSeaBuy, sell, & discover the internet of goods.Learn MoreForkastForkast is prediction markets at the intersection of gaming culture, sports betting, and crypto trading.Learn MoreT-RexPurpose-built blockchain for entertainment and culture.View all ProjectsReady to start building on Arbitrum?Get in TouchHighly-Engaged User BaseJoin a community with millions of active users engaging with innovative consumer apps every day.Vibrant Asset EcosystemArbitrum is an L2 leader in stablecoin depth and Perp DEX volume, providing rich, proven economic primitives for your app.The Center of Everyday CommerceUse a network built for high-volume, everyday interactions—powering consumer apps that bring commerce onchain.SPEED TO MARKETBuild Smarter, Launch FasterWhether you're a blockchain veteran or just starting your journey, Arbitrum is designed to get you from idea to launch with maximum velocity and minimum friction.Explore DocsExplore Arbitrum GrantsThe Right ToolsNative EVMArbitrum runs the EVM natively, so Solidity contracts and Ethereum tooling behave exactly as you expect. Ship apps with the same development, testing, and deployment stack you love.Broad Language SupportWith Stylus, you can build smart contracts in Rust, C, and C++, unlocking new developer talent and substantial performance gains.A Community Invested in Your SuccessWORLD-CLASS DOCUMENTATIONDive into extensive documentation, step-by-step tutorials, and in-depth guides. Everything you need to master building on Arbitrum is at your fingertips.Growth SupportDiscover opportunities for technical grants, marketing amplification, and strategic partnerships.Start BuildingGet in TouchJoin our CommunitySubscribe for the latest updates.SolutionsFinanceGamingConsumerProductsArbitrum OneDedicated BlockchainsWhy ArbitrumPerformanceConfidentialityCustomizationComplianceIntegrationsCase StudiesDevelopersGet startedConfigure a chainBuild an appBridgeExplorerFaucetStatusGithubResourcesBlogPressTalksContact UsPortalGovernanceForumGrantsBrand KitLegalPrivacy PolicyTerms of ServiceStay in touch","tokens":1510,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258840510,"hash":"d60abb8326f75d7c135b54c175adc8f7de43483b"}
{"url":"https://vote.optimism.io/delegates","domain":"vote.optimism.io","title":"Voter on Agora","text":"Governance starts with you!Your tokens matter— connect your wallet to delegate your voting power and shape the future of the collective.ProposalsVotersConnect  Wallet Agora is the home of Optimism votersOP Delegates are the stewards of the Optimism Token House, appointed by token holders to make governance decisions on their behalf.2ether.eth2.459K OP10% ParticipationDelegate to me!newnode.eth2.242K OP0% ParticipationDo right thingsjohnloves.eth1.235K OP0% Participation0x67...fee11.329K OP0% Participation0xe2...43201.29K OP0% Participationrektblock.eth1.111K OP10% ParticipationJessicaLspoken.bakerydao.eth6.132K OP100% ParticipationI believe that everyone should have a voice and for maximum decentralization we should encourage everyone to participate0x6f...9d591.365K OP0% Participationkycohen.eth1.362K OP0% ParticipationMy reasons for wanting to be a delegate: I am a committed DeFi user with knowledge about Ethereum, L2s, and what they ai0x1d...42b228.88K OP0% ParticipationStableLab is a professional delegate and governance services firm, contributing to over 20 protocols and ecosystems withtongnk.eth64.08K OP0% ParticipationHi all, I’m Nick from Perpetual Protocol foundation team. We’re a decentralised derivates exchange and one of the leadinlenchik.eth2K OP40% ParticipationLong-term L2 ecosystem builderpolymutex.eth2.057K OP0% ParticipationI believe that my tiny vote may make a difference.geoist.eth2.25K OP0% Participation0x85...10cd2.113K OP0% Participationminimalgravitas.eth156K OP90% ParticipationWhile I’ve been playing with Ethereum since 2016 it was only in 2019-20 that I really started to ‘get’ the potential of existence1.eth1.223K OP10% ParticipationInvolvement is the answer.chain-l.eth3.274K OP0% ParticipationI believe in the Optimistic vision more than ever, with all the experiments around. But, being an Asian we are not taughblockchainathopkins.eth28.4K OP0% Participationgm! We’re Blockchain@Hopkins (@blockchain_jhu on Twitter), the student blockchain club at Johns Hopkins University for a0x6e...a0691.361K OP0% Participation0x11...f4011.199K OP0% Participation0x8c...f98d9.233K OP0% ParticipationBoiler Blockchain is Purdue University’s student-run blockchain organization. We have forty active members in our first 0x1a...deb11.36K OP0% Participationeliteness.eth1.332K OP0% ParticipationGuru Network \\ eliteness.network We are here to: Help Decentralize Finance Grow We have built and are actively running aapppay.eth4.288K OP0% ParticipationI believe that the development of optimism has great potential in the future. I respect every proposal, vote fairly, andprens.eth6.018K OP0% Participation0x8f...513f1.556K OP0% ParticipationI want to help and participate in votingryanholloway.eth4.324K OP0% ParticipationMy view on the Optimistic Vision: I consider myself aligned with the Optimistic Vision, and confident in the Collective'nftstaker.eth1.539K OP0% Participationbbjrk.eth2.078K OP0% Participation0xe7...b2374.712K OP0% Participationinvestinmusic.eth1.268K OP0% ParticipationWe think that Optimism is playing a pivotal role in onchain music. We are extremely bullish on onchain music and its culjrai.eth5.901K OP0% Participationthattallguy.eth1.597K OP0% Participationsugma.eth323.9K OP0% ParticipationHave researched and followed Optimism since the days of Plasma, Helping shape Optimism into the solution it was meant tortree.eth1.334K OP0% Participation0xc0...62f28.924K OP0% Participation0x3d...c2192.179K OP0% ParticipationI believe that op.net will be better under everyone’s governancecardsmoney.eth2.937K OP0% Participationi will vote for Ufightfortruth.eth2.613K OP0% Participationcantopop.eth1.012K OP0% ParticipationCantopop is a group of enthusiastic artists, passionated to promote the canto culture.comeandplay.eth2.136K OP10% Participationwe need many delegators with less powerlee0007.eth7.44K OP0% ParticipationDelegated to myselfrenkone.eth2.059K OP80% Participation0xb1...b8274.597K OP0% Participationdimacrypt.eth1.222K OP0% Participationdarkshore.eth5.187K OP80% ParticipationCooperation, we're still few.joshuafisher.eth3.245K OP0% Participationbitcoin-rekt.eth5.736K OP0% Participationdenispro2015.eth2.153K OP100% ParticipationLoading...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":1079,"squid":"ink-governance","role":"Council Listener","at":1791258842277,"hash":"848150abf25df6ce0bd0d676902886fb677355cc"}
{"url":"https://docs.pyth.network/price-feeds/pro/frontend-auth","domain":"docs.pyth.network","title":"Frontend Authentication | Pyth Developer Hub","text":"Pyth ProFrontend AuthenticationUse short-lived tokens to call Pyth Pro from browser appsThis guide explains how to call Pyth Pro from browser and frontend apps without shipping your PRO_API_KEY to users. Anything in a browser bundle is public, so your backend mints a short-lived JWT with POST /auth/token and hands it to the browser. The browser then presents that JWT in place of the API key — as an Authorization: Bearer header on the History and REST APIs, and through the pyth-lazer-auth subprotocol on a WebSocket connection.\nReplacing the Proxy (Beta) API?This is the replacement. The beta Proxy (pyth-lazer-proxy-{1,2,3}) gave\nunauthenticated frontend access; now your backend mints a short-lived JWT and\nthe browser uses it over the WebSocket, REST, and History APIs — the raw API\nkey stays server-side.\nWhen to use which pattern\nClientPatternServer-to-serverPresent the long-lived Pro API key directly as Authorization: Bearer <PRO_API_KEY>. Simplest — prefer this whenever the client can hold a secret.Browser / frontendYour backend mints a JWT via POST /auth/token and returns it to the browser, which presents it in place of the API key: Authorization: Bearer <JWT> on the History and REST APIs, or the pyth-lazer-auth WebSocket subprotocol for streaming.\nNever expose the long-lived PRO_API_KEY in browser code, mobile apps, or\nany distributed binary. Anything in the client bundle is public — treat it\nas leaked the moment you ship it.\nThe flow\n\nThe browser client asks its own backend for a Pyth JWT.\nThe backend calls POST https://pyth.dourolabs.app/auth/token with Authorization: Bearer <PRO_API_KEY>.\nThe backend returns the JWT (and its expires_at) to the browser.\nThe browser presents the JWT in place of the API key until it nears expiry, then repeats from step 1.\n\nPOST /auth/token reference\n\nBase URL: https://pyth.dourolabs.app\nMethod / path: POST /auth/token\nAuth: Authorization: Bearer <PRO_API_KEY> (the long-lived Pro API key)\nContent-Type: application/json\n\nRequest body (optional)\nFieldTypeRequiredDescriptionttl_secondsinteger | nullNoHow long the token should live, in seconds. The server caps it at its maximum; omit it (or send null) to get that maximum.\nResponse 200\nFieldTypeDescriptionaccess_tokenstringShort-lived JWT to present as Authorization: Bearer <access_token>.expires_atstringRFC 3339 datetime at which the token expires.token_typestringAlways \"Bearer\".\nErrors\nStatusMeaning401Missing or malformed API key.404Token broker is not enabled on this deployment.\nBackend example\nAdd a token endpoint to your own backend. Never send the raw PRO_API_KEY to the browser — hand out only the short-lived JWT.\nimport express from \"express\";\n\nconst app = express();\napp.use(express.json());\n\n// Requires PRO_API_KEY in the backend's environment.\n// Protect this route with your own auth — see \"Protecting the token endpoint\" below.\napp.post(\"/pyth-token\", async (req, res) => {\n const body: Record<string, unknown> = {};\n if (typeof req.body?.ttl_seconds === \"number\") {\n // Optional pass-through: let callers request a shorter TTL than the server default.\n body.ttl_seconds = req.body.ttl_seconds;\n }\n\n const response = await fetch(\"https://pyth.dourolabs.app/auth/token\", {\n method: \"POST\",\n headers: {\n Authorization: `Bearer ${process.env.PRO_API_KEY}`,\n \"Content-Type\": \"application/json\",\n },\n body: JSON.stringify(body),\n });\n\n if (!response.ok) {\n res.status(response.status).send(await response.text());\n return;\n }\n\n // { access_token, expires_at, token_type }\n res.json(await response.json());\n});\nDo not cache the minted JWT on the server across users unless you scope\neach token to one user. A JWT is a bearer token: whoever holds it can spend\nyour quota until it expires.\nFrontend example\nCache the JWT in memory, refresh it a few seconds before expires_at, and send it as a bearer token on each request.\ntype PythToken = { access_token: string; expires_at: string };\n\nlet cached: PythToken | undefined;\n\nasync function getPythToken(): Promise<string> {\n // Refresh 30s before the token actually expires so an in-flight request\n // doesn't race the expiry.\n const safetyMarginMs = 30_000;\n if (cached && Date.parse(cached.expires_at) - Date.now() > safetyMarginMs) {\n return cached.access_token;\n }\n\n const response = await fetch(\"/pyth-token\", { method: \"POST\" });\n if (!response.ok) throw new Error(`Failed to mint Pyth token: ${response.status}`);\n cached = (await response.json()) as PythToken;\n return cached.access_token;\n}\n\n// Call the History API from the browser using the short-lived JWT.\nconst jwt = await getPythToken();\nconst res = await fetch(\n \"https://pyth.dourolabs.app/v1/fixed_rate@200ms/price?ids=1&timestamp=1704067200000000\",\n { headers: { Authorization: `Bearer ${jwt}` } },\n);\nconsole.log(await res.json());\nThe same JWT works against the REST API on https://pyth-lazer.dourolabs.app — send it as Authorization: Bearer <JWT>, exactly as on the History API.\nFor the WebSocket API, a browser cannot set request headers on the connection, so pass the JWT through the subprotocol list instead. Offer the marker pyth-lazer-auth immediately followed by the token:\nconst ws = new WebSocket(\n \"wss://pyth-lazer-0.dourolabs.app/v1/stream\",\n [\"pyth-lazer-auth\", jwt],\n);\nThe server reads the token from that value, authenticates, and completes the handshake by echoing back the pyth-lazer-auth subprotocol — your client accepts it and does nothing with it. The rest of the subscribe flow is unchanged.\nProtecting the token endpoint\n\nRequire your own auth on POST /pyth-token (session cookie, first-party JWT, etc.). Anyone who can reach this endpoint can spend your Pro API-key quota.\nRate-limit it. Without a limit, the endpoint is easy to abuse.\nQuota accounting: calls made with a JWT count against the quota of the API key that minted it.\n\nRelated\n\nAcquire an API Key\nREST API\nHistory API\nWebSocket API\nAuth API Swagger UI\nAcquire an API KeyRequest and manage API keys for Pyth ProSubscribe to PricesLearn how to authenticate, configure, and subscribe to Pyth Pro price streams","tokens":1511,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791258843772,"hash":"27ef3e5a52173066bee7ea8aeaca2176a64d6c43"}
{"url":"https://arbitrum.io/privacy","domain":"arbitrum.io","title":"Privacy Policy – Arbitrum","text":"Last Updated and Effective Date: December 19, 2023PRIVACY POLICY Please read this Privacy Policy (“Privacy Policy”) carefully. It provides information about how Offchain Labs, Inc. (“Offchain Labs”, “we”, “us”, and “our”) collects, uses, shares, and otherwise processes personal information. If you have any questions, comments, or concerns please contact us using the methods provided in the “Contact Us” section of this Privacy Policy below.By visiting, accessing, or using our Services (defined below), you acknowledge and agree that you have received and reviewed this Privacy Policy. From time to time, we may update this Privacy Policy as described in the Changes to this Privacy Policy section below.Please also review the applicable Terms of Service, which also apply to the use of our Services. Terms that are defined in the Terms of Service have the same meaning in this Privacy Policy unless this Privacy Policy specifies differently.If you are a resident of Nevada, please see the Notice to Nevada Residents section below.If you are a resident of the European Economic Area (\"EEA\"), United Kingdom (“UK”), Switzerland, or another non-U.S. country with local data protection laws, please see the Notice to European and Non-U.S. Residents section below for information about your rights under the applicable local data protection laws.Table of ContentsScope of This Privacy PolicyPersonal Information We Collect and HowHow We Use Personal InformationHow We Share Personal InformationCookies and Tracking Technologies“Do Not Track” PreferencesThird-Party LinksThird-Party Social Media PluginsChildren’s PrivacyYour ChoicesHow Long We Retain Personal InformationHow We Protect Personal InformationCalifornia “Shine the Light” DisclosureNotice to Nevada ResidentsInternational Data TransfersNotice to European and Non-U.S. ResidentsChanges to this Privacy PolicyContact Us1. Scope of This Privacy PolicyThis Privacy Policy applies to personal information that Offchain Labs collects, uses, shares, and otherwise processes when you:Access or use our website available at OffchainLabs.com or any other website operated or made available by Offchain Labs where this Privacy Policy is posted, including but not limited to websites with the domain Arbitrum.io (collectively, the “Website”);Access or use any of the Offchain Labs services or functionality we make available through the Website (collectively, the “Products”); orCommunicate with us, such as by sending us an email or communication through our Services.For purposes of this Privacy Policy, we refer to our Website, Products, and any other online service we provide that links to this Privacy Policy as the “Services.”Please note that while the Services may link to or connect with the Arbitrum Foundation websites at Arbitrum.Foundation, this Privacy Policy does not apply to the Arbitrum Foundation or the Arbitrum.Foundation websites.This Privacy Policy applies to:Visitors to the Website and any individuals who communicate with or receive communications from Offchain Labs; andIndividuals who access or use any of the Services.2. Personal Information We Collect and HowAs used in this Privacy Policy, “personal information” means any information that identifies or could be used to identify an individual person. For example, personal information may include name, email address, and phone number. It also includes other non-public information that we associate with such identifying information. Personal information does not include aggregated or anonymized information. We understand that many of our users value the anonymity available within a blockchain-based environment. We strive to limit the information we collect to anonymous information, but we do collect and process some personal information to enable and provide the Services.The personal information we collect and how we collect it depends on how you use the Services. We collect the following types of personal information, as described below.(a) Information You ProvideWe collect information, including personal information, that you provide directly to us when you access or use the Services or when you interact with us. We collect information that you provide to us in the following ways:Support requests, inquiries, feedback, surveys, questionnaires, research. If you contact us, such as by sending an email or submitting feedback, we may collect your name, company, job title, email address, phone number, country, the details of your question or request, and any other information you choose to include in your message. We may also collect information you provide if you complete surveys or questionnaires that we make available or if you participate in research opportunities we may offer or sponsor. Submissions through our Products. We collect information that you choose to submit through our Products, such as projects or other documentation.Interactions through social media and other third-party platforms. If you interact with us through any third-party platforms, such as our pages on Github or Discord, or through any of our pages or feeds on social media sites or platforms, such as LinkedIn or Twitter/X, we may collect information such as your name, username, demographic information, contact information such as email address, location, and publicly-posted data such as your social media activity.Attending Events. If you sign up for or attend a webinar or other event hosted by Offchain Labs, we collect registration and attendance information. If you attend a conference, trade show, or other event that Offchain Labs attends or sponsors, we may collect information about individuals who attend the event and/or information from individuals who interact with us or express an interest in our Services. This information may include your name and email address as well as any professional background information you may choose to share.Marketing communications and newsletters. If you subscribe to receive newsletters and marketing communications from us, we collect your name and contact information, such as your email address.Sweepstakes or Contests. We may collect personal information you provide for any sweepstakes or contests that we offer.Business Development and Strategic Partnerships. We may collect personal information from individuals and third parties to assess and pursue potential business opportunities.You may choose not to provide personal information directly to us or to not use the Services. However, some personal information is necessary so that we can provide you with the Services you have requested. Failure to provide this information may prevent us from providing you with access to our Services.(b) Information We Collect AutomaticallyWhen you access or use the Services, we or our third-party agents or service providers automatically collect information about the device you use to access the Services and your activity when you use the Services. Depending on your activity, the information may include:Device and Usage Information: We collect certain information about your device and how you interact with the Services each time you access or use them.Device information may include your IP address, browser type and version, browser settings, time zone, unique device identifiers, information about your approximate location (as determined through your IP address), mobile, computer, and/or device hardware information (e.g., operating system version, hardware model, IMEI number, and other unique device identifiers, MAC address, and device settings), device event information, log information, and crash data.Usage information may include features that you use, clickstream data, access dates and times, and how you interact with the Services. This information may also include referring / exit pages and URLs, how you interact with links on the Website, landing pages, and pages viewed. We also may collect the date and time you open an email communication from us or click on any links in an email and we or our service provider may associate this information with the email address we already have for you.Cookies and Other Tracking Technologies: We and our third-party service providers or agents may collect information using one or more Cookies or similar technologies such as pixels or locally stored objects (collectively “Cookies”). Cookies may collect information such as your IP address, unique device identifiers, your browser settings, and information about how you use the Services (e.g., the pages you view, the links you click). Please refer to the Cookies and Tracking Technologies section below for more information about our use of Cookies and your choices related to Cookies.(c) Information from Third PartiesIn some instances, and depending on the Services you use or how you use the Services, we collect and process personal information we receive from third parties, which can include the following:Offchain Labs’s Service Providers: We receive information from our service providers or agents who perform business services for Offchain Labs, such as Website activity information from third parties that assist us in operating our Website and transactional data from our third-party infrastructure service providers, as applicable. Offchain Labs’s Partners: We may receive contact information from business partners with whom we operate co-branded events, webinars, services and marketing campaigns or joint offerings.Analytics and Marketing Providers: We may receive information from third parties that perform data analytics and/or marketing functions for Offchain Labs.(d) Public Blockchain InformationIf you use certain Products made available through the Services, we may collect certain public blockchain information that you make available to us, such as your wallet address and crypto-asset transaction information related to your wallet address.(e) Sensitive Personal InformationOffchain Labs does not intentionally collect sensitive personal information (e.g., social security numbers, racial or ethnic information, health information, religious information).3. How We Use Personal InformationWe use the personal information we collect in the following ways:To provide and operate the Services;To respond to your inquiries and requests, or otherwise communicate with you, and to provide you with assistance related to the Services;To provide technical support for, secure, and protect the Services, including to detect and prevent fraud, abuse, or security risks, and to track outages and troubleshoot;To conduct analytics related to the Services, such as to understand how they are being used and where improvements may be needed;To improve user experience with the Services;To update, improve, and/or enhance the Services, and develop new features, functionality, and Services;To send you newsletters and promotional and marketing communications that may be of interest to you;To conduct and administer promotions, sweepstakes, or contests if you have chosen to participate, in accordance with the terms of the promotion;To better understand your personal preferences and to enable us to provide you with improved and personalized communications and services;To compile aggregate data, such as about traffic and interaction with or on the Services;To provide transactional updates about our Services;To enforce our Terms of Service, resolve disputes or otherwise to carry out our obligations and enforce our rights, and to protect our business interest and rights of third parties;To audit our compliance with legal and contractual requirements and internal policies;To comply with legal and contractual obligations and requirements, law enforcement requests, and legal process; For our business transfers;To keep you updated about changes to policies related to our Services (including this Privacy Policy); and For any other purpose with your consent.We may combine any of the information that we collect from you with other information, including information that we obtain from third parties, or with information derived from any other products or services we provide. We will use this information for the purposes described in this Privacy Policy.4. How We Share Personal InformationWe transmit, share, grant access, make available and provide personal information to or with the following types of third parties.(a) Other Users of the ServicesIf you post or share content through the Services (for example projects, comments), that information is public and will be shared with other users of the Services. Offchain Labs is not a controller of that information once it is shared. By default, most of this information is shared anonymously. To the extent your personal information is associated with any content you post or share, please be aware that other users of the Services will be able to view and have access to it.(b) Service ProvidersWe share personal information with our third-party vendors, consultants, agents, contractors, and service providers that help us provide our Services or with any of the purposes described in this Privacy Policy. Depending on how you use the Services, the following categories of Service Providers may collect data on our behalf, receive, or access personal information:Hosting service providers,Analytics providers,Marketing partners,Providers of business operations and communication tools, such as email and messaging software providers,Customer support service providers,Other third-party service providers that help us provide features and functions for the Services, andProfessional advisors, agents and service providers, such as auditors, lawyers, consultants, accountants and insurers.(c) Offchain Labs PartnersFrom time to time, we may work with other businesses to sponsor or host conferences or webinars, market related services, promote joint ventures or other similar collaborations. We might share personal information, such as your name and email address, with our partners in these situations.(d) Sweepstakes, Contests, and Other Promotional ActivitiesIf you participate in a promotion, sweepstakes, or contest (collectively, “Promotion”), we may disclose your personal information to any third parties affiliated with the Promotion or to the public in connection with conducting and administering the Promotion. For example, we may share personal information to select a winner, provide a prize, as required by applicable law (such as publishing a list of winners), or as permitted by the applicable terms and conditions or official rules of the Promotion.(f) Legal, Compliance and Regulatory PurposesWe may share personal information if we believe that it is necessary to:comply with a law, regulation, legal process, or legitimate governmental request;protect the safety or security of the Services, users of the Services, or any person;investigate, prevent, or take action regarding illegal or suspected illegal activities;prevent spam, abuse, fraud, or other malicious activity of actors using or accessing the Services; orprotect our rights or property or the rights or property of those who use the Services.Non-public information about our users will not be released to law enforcement except in response to an appropriate legal process such as a subpoena, court order, or other valid legal process that has been reviewed by Offchain Labs. However, if we receive information that provides us with a good faith belief that there is an exigent emergency, we may provide information to law enforcement trying to prevent or mitigate the danger, to be determined on a case-by-case basis.(h) Business TransfersWe may share personal information with third parties we choose to acquire or with buyers, successors, or others in connection with a merger, divestiture, restructuring, reorganization, financing due diligence, initial public offering, dissolution, or other sale or transfer of some or all of our assets or transition of service to another provider, whether as a going concern or as part of bankruptcy, receivership, liquidation or similar proceeding, as permitted by law and/or contract.(e) With Your ConsentThere may be situations where you are asked to consent to share personal information with third parties for additional reasons not included in this Privacy Policy.5. Cookies and Tracking TechnologiesAs described above in this Privacy Policy, we collect and may permit third parties to collect information using cookies and other similar technologies.(a) What Are Cookies?Cookies are small data files that are placed on your device set by us or by third parties when you visit a website or other online service. In addition to cookies, we may use other technologies that are similar in function, such as pixel tags, also called web beacons or single-pixel tags/gifs, local or web storage, and embedded scripts.Web Beacons: Web beacons, or “clear gifs,” and single-pixel tags/gifs, or web tags, are tiny graphics with a unique identifier placed on a website or in an email that gathers information about your interaction with that website or email. Because of their small size, they are not visible.Local or Web Storage: Local or web storage refers to other places on a browser or device where information can be stored. It includes both your own device storage and browser cache.Embedded Scripts: An embedded script is a programming code that is designed to collect information about your interactions with the Services, such as the links you click. The code is temporarily downloaded onto your device, is active only while you are connected to the Services and is deactivated or deleted after you are no longer connected.We use the term “Cookie” throughout this Privacy Policy to cover all these technologies.You can find more information about cookies at: www.allaboutcookies.org.(b) Types of CookiesCookies are often described by who created and placed them and how long they last. Types of Cookies generally include the following:Persistent Cookies and Session CookiesPersistent Cookies: A persistent Cookie stays in your browser and will be read by us when you return. A persistent Cookie helps us recognize you as an existing user, so it is easier for you to return and interact with our Services.Session Cookies: A session Cookie is temporary and enables you to move from page to page on our Services and allows information that you enter to be remembered. A session Cookie is deleted when you close your browser or after a short time.First-Party Cookies and Third-Party CookiesFirst-party Cookies: These are Cookies set by the publisher of the website or online service you are visiting. First-party Cookies may be set either by us or by a service provider at our request.Third-party Cookies: These are Cookies that are set by a party other than the publisher of the website you are visiting.(c) What Types of Information Do Cookies Collect?Cookies collect different types of information depending on the type of Cookie and its purpose. Some examples of information that may be collected by Cookies when you use our Services include:The pages or features you visit within our Services;The buttons you click on our Services;The date and time you visit our Services;The amount of time you spend on our Services;The Internet Protocol (“IP”) address used to connect your device to the internet; andYour device (such as computer, mobile phone) and connection information such as your browser type and version and operating system.(d) How Do We Use Cookies?Offchain Labs uses Cookies for purposes such as providing content or features on our Services, helping us remember you and your preferences, and improving your user experience by making our Services more efficient and relevant to you. We, our service providers, and/or agents acting on our behalf, use the following persistent and session Cookies (which may be first-party or third-party Cookies) on our Services:Strictly Necessary Cookies: These Cookies are essential because they enable our Services to work properly, and they cannot be disabled. Without these Cookies, some of our Services cannot be provided. These Cookies do not gather information about you for advertising purposes. For example, these Cookies are used to:Remember the information that you fill in when performing certain activities on your Services;Pass information from one page to the next, for example when filling out forms;Read your browser and device settings to optimize the display of our Services;Identify misuse of our Services;Load our Services uniformly to maintain accessibility; andPrevent fraud.Functional Cookies: We use functional Cookies to remember your choices so we can tailor our Services to provide you with enhanced features and personalized content. For example, these Cookies can be used to remember your preferences on our Services. We do not use functional Cookies for online advertising. While these Cookies can be disabled, this may result in less functionality during your use of our Services. For example, we use these Cookies to:Provide you a personalized experience, such as remembering how you have customized our Services;Remember the information that you fill in when performing certain activities on our Services; andStore your preferences such as language and location.Performance or Analytics Cookies: These Cookies help us understand how our Services are being accessed, used, or are performing. These performance or analytics Cookies may collect information about the content you view, what websites you visit immediately before and after visiting our Services, and your system and geographic information. The information generated by these Cookies will be transmitted to and stored by the applicable analytics services. For example, we may use performance or analytics Cookies to:Maintain and continually improve our Services;Keep track of the number of visitors to the pages within our Services;Keep track of the length of time that each visitor spends on the pages within our Services;Determine the order in which a visitor visits the various pages or features within our Services;Identify performance issues with our Services; andAssess which parts of our Services need improvement.(e) How to Manage or Delete CookiesYou can exercise your preferences concerning Cookies served on our Services by taking the steps outlined below.Browser Settings: You may alter the Cookie settings in your browser settings at any time. You may accept all or only certain Cookies. If you disable Cookies in your browser settings, however, you may find that certain sections of our Services will not work.First-Party Cookies: If you do not want Cookies placed on your device, you can adjust the setting of your Internet browser to reject some or all Cookies and to alert you when a Cookie is placed on your device. To do this, follow the instructions provided by your browser (usually located within the “Help,” “Tools,” or “Edit” settings). While adjusting your browser setting can prevent the future placement of Cookies, it does not remove existing persistent Cookies.Third-Party Cookies: Browsers also allow you to block third-party Cookies using the steps described above for first-party Cookies.Preferences Tools: There are several services available that can assist you with managing your Cookie preferences, including industry groups, standards associations, and tools provided by the Cookie providers and social media sites. Please note that we have no affiliation with, and are not responsible for, third-party websites.Privacy plug-ins: You can block cookies used for interest-based ads by installing browser plugins like Privacy Badger, DuckDuckGo, Ghostery, or uBlock Origin and configuring them to block third-party cookies/trackers.Google Analytics: You may download the Google Analytics opt-out browser add-on at https://tools.google.com/dlpage/gaoptout.DAA: You may use the Digital Advertising Alliance (“DAA”) consumer choice tools to apply opt-outs to interest-based advertising and other applicable uses of web-viewing data by DAA participating companies by visiting http://optout.aboutads.info/?c=2&lang=EN#completed.NAI: You may also manage opt-outs through the Network Advertising Initiative (“NAI”) opt-out tool at http://optout.networkadvertising.org/?c=1Web Beacons and Pixels: You may avoid web beacons and pixels by disabling the functionality that allows remote images to load in your email account and refraining from clicking on any links in email messages.Opting out through these mechanisms does not block all online advertising. You will continue to receive generic advertisements.To learn more about how to manage Cookies and opt-out of Cookies being placed on your devices, please visit www.allaboutcookies.org.6. \"Do Not Track\" PreferencesThe Services do not monitor for or behave differently if your browser or device transmits a “Do Not Track” or similar message.Track” or similar message. Some Internet browsers may be configured to send \"Do Not Track\" signals to the online services that you visit. There is no consensus among industry participants as to what \"Do Not Track\" means in this context. Like many websites and online services, Offchain Labs does not currently alter our practices when we receive a \"Do Not Track\" signal from a visitor’s browser except as specifically required by law. For information about \"Do Not Track\" please visit All About DNT.7. Third-Party LinksWe may provide links to other websites or resources with which we do not have a contractual relationship and over which we do not have control (“External Websites”). Such links are not paid advertisements, nor do they constitute an endorsement by Offchain Labs of those External Websites and are provided to you only as a convenience. By clicking on links to the External Websites, the operators of the External Websites may collect personal information. We are not responsible for the content or data collection practices of those External Websites, and your use of External Websites is subject to their respective terms of use and privacy policies. We encourage you to carefully read the privacy policy of any website you visit.8. Third-Party Social Media PluginsThe Services may offer Social Media Platform sharing features and other integrated tools that enable you to share or view certain content via social media sites (such as the Twitter “Follow” button). These features may function as cookies or web beacons when you interact with them and collect information such as information about your device or your interactions with the Services, such as what you’re viewing through the Services. If you are logged in to your account with the third party, the third party may be able to link information about your interactions with the Services to your account with them. Please refer to each third party’s privacy policies to learn more about its data practices.9. Children’s PrivacyOur Services are not intended for use by anyone younger than the age of 18 or under the applicable legal age of the relevant country. We do not knowingly collect personal information from children younger than the age of 18 without the consent of a parent or legal guardian, as required under applicable law. If you learn or believe that a child under the age of 18 has provided us with personal information, please contact us using the methods provided in the “Contact Us” section of this Privacy Policy below.10. Your Choices(a) Marketing PreferencesTo stop receiving, or opt-out of, promotional email communications from Offchain Labs, click on the \"unsubscribe\" link or follow the relevant opt-out instructions within the marketing communication. If you opt-out, we will still send you transactional emails for service purposes, such as for responses to your requests or communications about your account.(b) Third Party AnalyticsOffchain Labs uses third-party analytics providers to provide us with information regarding the use of the Services. For more information about the tracking technologies that these third parties use and your options, please see the Cookies and Tracking Technologies section above.11. How Long We Retain Personal InformationWe retain personal information for the purposes stated in this Privacy Policy and as required under applicable law. To determine how long we keep personal information, we consider the amount, nature, and sensitivity of personal information, the reasons for which we collect and process the information, and applicable legal requirements.12. How We Protect Personal InformationAt Offchain Labs, we take our responsibility to protect the security and privacy of personal information seriously. We have implemented what we believe to be reasonable and appropriate security measures designed to prevent personal information from being lost, used, accessed, altered, or disclosed in an unauthorized or unlawful way.If you have reason to believe that your information is no longer secure, please let us know by contacting us using the methods provided in the “Contact Us” section of this Privacy Policy below.13. California “Shine the Light” DisclosureThe California “Shine the Light” law gives residents of California the right under certain circumstances to opt-out of the sharing of certain categories of personal information with third parties for their direct marketing purposes. We do not currently share personal information with third parties for their own direct marketing purposes.14. Notice to Nevada ResidentsUnder Nevada law, Nevada consumers may opt out of the sale of covered personal information. Offchain Labs does not currently sell covered information of Nevada consumers as defined under applicable Nevada law.You may submit an opt-out request by sending your request to the email address or mailing address specified in the Contact Us Section below, along with your full name, complete mailing address (including street address, city, state, and zip code), email address (so that we can contact you, if needed, in connection with the request) and confirmation that you are a Nevada resident.15. International Data TransfersThe personal information that we collect or receive may be transferred to and processed in countries located outside of your country of residence to the countries where we or our third-party service providers process it. The data protection laws of the countries where personal information is processed may not be as comprehensive as or equivalent to those in your country of residence. Whenever we transfer personal information internationally, we take steps to protect it as required under applicable law.16. Notice to European and Non-U.S. ResidentsThis notice supplements the information provided in this Privacy Policy and applies only to individuals located in the EEA, UK, Switzerland, or another country with a comprehensive data protection law who are within the scope of this Privacy Policy.For the purposes of the General Data Protection Regulation (EU) 2016/679 (\"GDPR\") and relevant local data protection laws, Offchain Labs is the data controller of your personal information. \"Personal information\" as used in this Notice to European Residents means \"personal data,\" as defined in Article 4(1) of the GDPR or the relevant section of the local data protection laws. If you have any questions about how we process your personal data, or to exercise your data protection rights please contact ususing the methods provided in the “Contact Us” section of this Privacy Policy below.(a) Legal Basis for ProcessingOffchain Labs processes personal information where there is a legal ground to do so, as described below. The applicable legal ground depends on the Services you use and how you use them.Performance of a Contract. We process personal data for the performance of our Services under the terms of our agreement with you in the Terms of Service or applicable agreement. This includes, for example, using personal data to:Facilitate your use of the Services;Maintain our Services in accordance with this Privacy Policy and the applicable Terms of Service; Provide support; andRespond to your inquiries and requests, or otherwise communicate with you, and provide you with assistance related to the Services.Legitimate Interest. We process personal data when Offchain Labs has a legitimate interest to do so. This includes, for example, processing personal data to:Provide you with support;Debug, update and improve the Services;Personalize your experience using the Services;Send you marketing communications in accordance with your applicable marketing preferences;Prevent or detect fraud on the Services;Conduct analytics regarding the Services; andEstablish, exercise, or defend legal claims or in connection with any court or jurisdiction.You may request more information regarding our processing activities based on legitimate interest by contacting us with your request and confirmation that you are located in the EEA, United Kingdom, or Switzerland using the methods provided in the “Contact Us” section of this Privacy Policy below.Legal Obligation. We process personal information for compliance with any legal obligation to which Offchain Labs is subject.Consent. We process personal information based on consent where we obtain your consent prior to such processing. This processing may include, for example:Surveys and certain marketing communications about our Services or other services or products we think might interest you; andCertain marketing features or content.Where Offchain Labs relies on your consent as the lawful basis for processing personal data, you have the right to withdraw your consent to further use of your personal data at any time. You can use the methods described in Exercising Your Rights below to withdraw your consent.(b) Your Data RightsUnder the GDPR and relevant local data protection laws, you have certain rights regarding your personal data. Depending on your country of residence, your rights may include:The right to be informed – that’s a right to be informed about how we use personal data (and that’s what we’re doing in this Privacy Policy);The right of access – that’s a right to make what’s known as a ‘data subject access request’ for a copy of the personal data we hold about you;The right to rectification – that’s a right to request that we correct personal data about you that may be incomplete or inaccurate (though we generally recommend first making any changes in your account if you registered for one);The right to erasure – that’s where, in certain circumstances, you can ask us to delete the personal data we have about you;The right to restrict processing – that’s a right for you in certain circumstances to ask us to suspend processing personal data;The right to data portability – that’s a right for you to ask us for a copy of your personal data in a common, machine-readable format (for example, a .csv file);The right to object – that’s a right for you to object to us processing your personal data (for example, if you object to us processing your personal data for direct marketing);Rights in relation to automated decision-making and profiling – that’s a right you have for us to be transparent about and not be subject to any profiling or any automated decision-making we may do;Withdraw Consent – if we have collected and processed personal data with your consent, you have the right to revoke that consent at any time. Withdrawing your consent will not affect the lawfulness of any processing we conducted prior to your withdrawal, nor will it affect processing of your personal data conducted in reliance on lawful processing grounds other than consent; andFile a complaint – that’s the right to file a complaint with a local supervisory authority about our collection and processing of your personal data.(c) Exercising Your Rights For each of the rights described above, and for any complaints you may have, please contact us.We respond to all requests we receive from individuals wishing to exercise their data rights in accordance with applicable data protection laws. These rights are subject to certain rules around when you can exercise them.We may need to request specific information from you to help us confirm your identity before we can respond to your request. This is a security measure to help ensure that personal data is not disclosed to any person who has no right to receive it and to help ensure that the person exercising the right is the person about whom the personal data relates.If you are located in the EEA, the United Kingdom, or Switzerland, you have the right to make a complaint at any time to the supervisory authority for data protection issues in your country of residence. We would, however, appreciate the chance to deal with your concerns before you approach the supervisory authority, so please contact us using the methods provided in the “Contact Us” section of this Privacy Policy below.For information on how to contact your data protection authority, please see:EEA Data Protection Authorities (DPAs)Swiss Federal Data Protection and Information Commissioner (FDPIC)UK Information Commissioner’s Office (ICO)17. Changes to this Privacy PolicyWe may update this Privacy Policy from time to time. When we update this Privacy Policy, we will revise the “Last Updated and Effective Date” at the top of this Privacy Policy and post a link to the updated Privacy Policy on our Website. Changes to this Privacy Policy are effective when they are posted. If we make any material changes, we will provide you with notice as required under applicable law. Please review this Privacy Policy periodically to ensure you are aware of any such changes.18. Contact UsIf you have any questions about this Privacy Policy or our privacy practices, please contact us: By email at privacy@offchainlabs.com.Subscribe for the latest updates.SolutionsFinanceGamingConsumerProductsArbitrum OneDedicated BlockchainsWhy ArbitrumPerformanceConfidentialityCustomizationComplianceIntegrationsCase StudiesDevelopersGet startedConfigure a chainBuild an appBridgeExplorerFaucetStatusGithubResourcesBlogPressTalksContact UsPortalGovernanceForumGrantsBrand KitLegalPrivacy PolicyTerms of ServiceStay in touch","tokens":9549,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258860652,"hash":"065dc2b65468a7c4ea6edc1dbf5af34cf491f1c8"}
{"url":"https://arbitrum.io/tos","domain":"arbitrum.io","title":"Terms of Service – Arbitrum","text":"Date of Last Revision: March 11, 2026TERMS OF SERVICE PLEASE READ THESE TERMS OF SERVICE CAREFULLY, AS THEY CONTAIN AN AGREEMENT TO ARBITRATE AND OTHER IMPORTANT INFORMATION REGARDING YOUR LEGAL RIGHTS, REMEDIES, AND OBLIGATIONS. THE AGREEMENT TO ARBITRATE REQUIRES (WITH LIMITED EXCEPTION) THAT YOU SUBMIT ANY CLAIMS YOU HAVE AGAINST OFFCHAIN LABS, INC. TO BINDING AND FINAL ARBITRATION, AND FURTHER (1) YOU MAY ONLY BRING CLAIMS AGAINST OFFCHAIN LABS, INC. IN YOUR INDIVIDUAL CAPACITY, NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY CLASS OR REPRESENTATIVE ACTION OR PROCEEDING; (2) ANY RELIEF YOU SEEK, WHETHER MONETARY, INJUNCTIVE, OR DECLARATORY, MUST BE SOUGHT ON AN INDIVIDUAL BASIS; AND (3) YOU MAY NOT BE ABLE TO HAVE ANY CLAIMS YOU HAVE AGAINST OFFCHAIN LABS, INC. RESOLVED BY A JURY OR IN A COURT OF LAW.  SEE SECTION 11 FOR MORE INFORMATION ABOUT ARBITRATION.These Terms of Service, including its appendix and any other attachments (each as amended from time to time, collectively, these “Terms of Service” or \"Terms\"), serve as an agreement between you (\"you\", \"your\") and Offchain Labs, Inc. (“Offchain Labs”, “we”, “us”, “our”). These Terms govern your access and use of (i) our websites located at https://offchainlabs.com, https://arbitrum.io (excluding those pages which are expressly governed by separate terms), https://zerodev.app/ and any other websites operated by Offchain Labs which incorporate these terms (collectively, the “Site”); (ii) the Offerings (as defined in Appendix I - List of Offerings below); and (iii) the website-hosted interfaces, operated by us that may be used to interact with certain Offerings (the \"Interface\"). For the purposes of these Terms, the Sites, the Interface, and the Offerings are collectively referred to as the “Services”. As used in these Terms, any reference to “access”, \"engage\", “use”, “browse,” “interact”, or similar activities involving the Offerings, Interface, Sites, or Services shall apply equally to any such activity with respect to any portion of the applicable defined term. All activities involving the Services are subject to these Terms of Service.By accessing, browsing, or otherwise using any of the Services, you represent that you have read, understand, and agree to be bound by these Terms of Service. If you are accessing or using any of the Services, on behalf of an entity, you represent and warrant that you are agreeing to these Terms of Service for that entity and further represent and warrant to Offchain Labs that you have the authority to bind that entity to these Terms of Service (and, in which case, the terms “you” and “your” will refer to that entity). If you do not accept the terms and conditions of these Terms of Service, you may not access, browse, or otherwise use the Services or any part of the Services, and must immediately cease any such activity.We reserve the right, at our sole discretion, to modify or replace any part of these Terms of Service (each, a “Change”) at any time. If we make any Changes, such updated Terms of Service will be posted on the Site under the “Terms of Service” link, along with the date of such revision at the top of the page. All Changes to the Terms of Service are effective upon posting. By continuing to access, use, or browse the Services from or after the date of such posting constitutes your acceptance of the then-current Terms of Service. You should periodically visit the Site to review the then-current and effective Terms of Service, so you are aware of any Changes. If you do not agree to abide by these or any future Terms of Service, you may not access, browse, or use (or continue to access, browse, or use) the Services. Without limiting anything set forth in these Terms of Service, you agree that we shall not be liable to you or any third party for any losses suffered arising from any Changes to this Terms of Service.Additional Terms.Privacy.For more information regarding our collection, use, and disclosure of personal data and certain other data, please see the Offchain Labs Privacy Policy. For information regarding our collection, use, and disclosure of personal data and certain other data in the performance of the services available via https://zerodev.app/, please see the ZeroDev Privacy Policy (collectively, the  “Privacy Policy”). To the extent applicable, if you are a developer, you are responsible for notifying any third-party individuals or entities who use or access the Services via Your Apps (as defined below) (each, an “End User”) of the Privacy Policy.By accessing the Services, or any part thereof, you consent to our collection, use, and disclosure of Personal Data and other data as outlined therein. The Privacy Policy is hereby incorporated by reference into these Terms of Service.Feature Specific Terms. In addition, when using certain features through the Services, you may be subject to certain additional terms applicable to such features (“Feature Terms”). Such additional terms (if any) will be posted on or within the applicable Site or Interface where such applicable Services may be accessed. All such terms are hereby incorporated by reference into these Terms of Service. To the extent applicable, if you are a developer, you are responsible for notifying your End Users of the Terms of Service and any Feature Terms.Trial Services. We may offer Services to you on a trial basis (“Trial Services”). Offchain Labs provides all Trial Services on an “as-is” basis without warranty of any kind. Offchain Labs may terminate or suspend any Trial Service at any time, and any customization or configurations may be permanently lost as a result. Notwithstanding anything to the contrary under these Terms of Service (including without limitation Sections 8, 9, and 10), Offchain Labs disclaims all liability and responsibility for any damages, losses, claims, or causes of action related to or in connection with any Trial Service.Beta Features. From time to time, certain experimental, novel, non-final or in-development features, products, applications, software, website pages, interfaces, or services, and/or offerings (collectively, “Beta Features”) may be made available through the Services. These Beta Features may be labeled as “Alpha,” “Beta,” or may not be labeled at all. By accessing or using any Beta Features, you acknowledge and agree that the Beta Features are provided on an “as-is” basis without warranty of any kind, and Offchain Labs may terminate or suspend the availability of the Beta Features at any time. You acknowledge that the Beta Features are not ready for production usage, may contain bugs, errors, defects, and vulnerabilities, and that your use of any Beta Features is at your own risk.  For the avoidance of doubt, nothing in this Section shall limit any of the exculpatory provisions set forth elsewhere in these Terms of Service, including, without limitation, Sections 8, 9 and 10, and Offchain Labs disclaims all liability and responsibility for any losses, claims, or causes of action related to or in connection with any Beta Features.Access and Use of Services. As a condition to accessing or using the Services, you acknowledge, understand, and agree to the following:Product Specific Terms. Users of certain products are subject to the terms set forth in Exhibit A.Data Collection. By accessing and/or using the Services, you authorize Offchain Labs and its third-party service providers to derive statistical and usage data relating to your use of such Services (\"Usage Data\"). We may use Usage Data for any purpose in accordance with applicable law and our Privacy Policy.Modifications to Services. Offchain Labs reserves the right to modify, replace, or discontinue, temporarily or permanently, the Services or any content or information available as part of the Services, with or without notice to you. You agree that Offchain Labs will not be liable to you or to any third party for any such modification, replacement, suspension, or discontinuance under this Section.Wallets. To access and use certain Services, you must use a non-custodial digital wallet that enables you to interact with public blockchains (a \"Wallet\"). Your use of any Wallet is subject to the applicable terms of service or equivalent agreement of the applicable Wallet provider.You are solely responsible for maintaining the security of your Wallet, including safeguarding your cryptographic private keys, seed phrases, and other credentials associated with your Wallet (the \"Wallet Credentials\"). Offchain Labs will never ask you to share your private keys, seed phrase, and you should never share such credentials with anyone. You acknowledge and agree, you are solely responsible for your use of any Wallet, and Offchain Labs will not be liable for any acts or omissions by you, or for any losses resulting from your Wallet being compromised.In order to interact with an Offering or Third-Party Services (as defined below), the Interface or Third-Party Services, as applicable, may require you to approve or \"sign\" one or more blockchain transactions using your Wallet. You are solely responsible for reviewing and understanding the nature, purpose, and potential consequences of any transactions before approving or signing them. Transactions that you sign using your Wallet cannot be reversed once they have been broadcast to the relevant digital asset network.Non-Custodial. All Services provided by Offchain Labs are non-custodial. At no point throughout your use of the Services will Offchain Labs have custody, possession, access to, or control over your Wallet or the contents of your Wallet, including but not limited to any of your Digital Assets (as defined below). By using and/or connecting your Wallet with any of our Services, you acknowledge and agree Offchain Labs shall have no responsibility and disclaims all liability in connection with your use of such Wallet and further, Offchain Labs makes no representations or warranties regarding the compatibility or functionality of any Services with any specific Wallet. For the purposes of these Terms, \"Digital Assets\" mean, without limitation, any cryptocurrency, virtual currency, virtual commodity, digital representation of value, decentralized application tokens, protocol tokens, cryptofinance coins, tokens, or similar digital assets, blockchain-based assets, or other similar digital representations of assets, whether fungible or non-fungible.No Registration. Offchain Labs is not registered with the U.S. Securities and Exchange Commission or with any state, federal or international regulator, nor is it a financial institution, money services business or money transmitter. You acknowledge that Digital Assets are not subject to protections or insurance provided by the Federal Deposit Insurance Corporation or the Securities Investor Protection Corporation in the United States or any similar government-sponsored program.Fees and Payments. Your use of the Services or any Third-Party Services (as defined below) may result in certain fees, including, without limitation, transaction fees imposed by the applicable blockchain network in connection with your activity on such network (\"Gas Fees\"), and fees charged by Third-Party Services (\"Third-Party Fees). Offchain Labs does not receive any portion of the Gas Fees or Third-Party Fees paid by you in connection with your use of any other part of the Services; however, Offchain Labs may assess its own fees for use of the Services. All fees incurred through your use of the Services, whether directly or including Gas Fees and Third-Party Services, are referred to collectively as the \"Fees.\" To the extent applicable, if you are a developer, you are responsible for notifying your End Users of any Fees for the Services that are assessed to your End Users.Changes in Fees. We may change prices for the Services and/or discontinue or change any promotion, sale, or special offer in our sole discretion; provided that, for enterprise tier customers, any such changes or discontinuations will only be effective upon the commencement of the next service period as specified on an applicable Order Form (each, a \"Service Period,\" and such renewal Service Period, a \"Renewal Period\"). For the avoidance of doubt, Offchain Labs reserves the right to increase or decrease prices for any Renewal Period in its sole discretion. In addition, we reserve the right to modify the manner in which Fees assessed by Offchain Labs are defined or denominated for purposes of billing or usage measurement, provided that such modification does not materially diminish the value of Services delivered to you for the applicable Fees.Credentials. In order to use certain Services, you may be required to create certain credentials. In the event you are required to create such credentials, you agree you are solely responsible for maintaining the confidentiality, availability and security of your credentials, and you are fully responsible for any and all activities that occur under your credentials.User Content and Applications.Your Applications. Certain Services may enable you to connect or integrate your own or third-party software, applications, or developer tools (\"Your Apps\") with such Services. As between you and Offchain Labs, you are solely responsible for Your Apps, including their development, operation, maintenance, all related content, data, and materials, and users. We cannot and do not guarantee that the Services will perform as expected when interacting with Your Apps and your use of them in combination with each other is at your sole risk.User Content. You are solely responsible for all code, video, images, information, data, text, software, music, sound, photographs, graphics, messages, and other materials (\"Content\") that you transmit to Offchain Labs on your behalf or on the behalf of your End Users, including by uploading, posting, publishing, or displaying (hereinafter, \"upload(ing)\") via the Site, Interface, Offerings, Third-Party Services (as defined below) or Your Apps, or by emailing, communicating or otherwise making such content available to other users of the Services (collectively, \"User Content\").Compliance & User ConductMinimum Age & General Compliance. You represent that you are at least 18 years old and that your access to and use of the Services will fully comply with all laws, regulations, rules, directives, and orders applicable to you or Offchain Labs (collectively, \"Applicable Laws\"). You further agree not to access or use the Services (or allow your End Users, as applicable) to conduct, promote, or otherwise facilitate any illegal activity.Sanctions Compliance. You agree to comply with all applicable sanctions laws, regulations, and rules, including, without limitation, those administered by the United States Department of the Treasury's Office of Foreign Assets Control (\"OFAC\"), the United Kingdom's His Majesty's Treasury, and any other governmental authority with jurisdiction over you, your End Users (if applicable) or Offchain Labs (collectively, the \"Sanctions Regimes\"). For the avoidance of doubt, you may not access or use, and you will not permit others to use, the Services: (i) in the Crimea region of Ukraine, Cuba, Iran, North Korea, Syria, or any other country, region, or territory subject to a comprehensive trade embargo, or where access to or use of the Services is otherwise prohibited by any Sanctions Regimes; (ii) by or for the specific benefit of any individual or entity on the Specially Designated Nationals and Blocked Persons List (\"SDN List\") maintained by OFAC, (iii) by any entity where 50% or more is owned in the aggregate by any persons on the SDN List; or (iv) for any other use that would require a license or other governmental approval.Prohibited Activities. You agree not to use the Services in any way, including with any of Your Apps, to distribute any content that: (i) infringes any intellectual property or other proprietary rights of another party; (ii) you do not have a right to upload under any law or under contractual or fiduciary relationships; (iii) contains software viruses or any other computer code, files or programs designed to interrupt, destroy, or limit the functionality of any computer software or hardware or telecommunications equipment; (iv) poses or creates a privacy or security risk to any person; (v) constitutes unsolicited or unauthorized advertising, promotional materials, commercial activities or sales, \"junk mail,\" \"spam,\" \"chain letters,\" \"pyramid schemes,\" \"contests,\" \"sweepstakes,\" or any other form of solicitation; or (vi) is unlawful, harmful, threatening, abusive, harassing, tortious, excessively violent, defamatory, vulgar, obscene, pornographic, libelous, invasive of another's privacy, hateful, discriminatory, or otherwise objectionable. You further agree not to use the Services in any way, including with any of Your Apps, to engage in any activity, whether directly, indirectly, or by distributing content that facilitates or supports such activity, that: (i) is beyond the scope of rights expressly granted in these Terms of Service; (ii) seeks to reverse engineer, disassemble, decompile, decode or otherwise attempt to derive or gain improper access to any component of the Services, in whole or in part; (iii) seeks to interfere with or compromise the integrity, security, or proper functioning of any computer, server, network, personal device, or other information technology system, including but not limited to deployment of viruses and denial of service attacks; (iv) violates any applicable local, state, national, or international law, or any regulations having the force of law, including any laws or regulations concerning the integrity of trading markets (e.g., manipulative tactics commonly known as spoofing and wash trading) or trading of securities or derivatives; (v) engages in any activity that seeks to defraud us or any other person or entity, including providing any false, inaccurate, or misleading information in order to unlawfully obtain the property of another; (vi) impersonates any person or entity, or falsely state or otherwise misrepresent your affiliation with a person or entity; (vii) solicits personal information from anyone under the age of 18; (viii) harvests or collect email addresses or other contact information of other users of the Services for the purposes of sending unsolicited emails or other unsolicited communications; (ix) further or promote any criminal activity or enterprise or provide instructional information about illegal activities; (x) interferes with, disables, or circumvents any security feature, access restriction, or other technical limitation of the Services; (xi) accesses or interacts with any third-party product, service, or offering, in a manner that violates the Terms of Service or other applicable terms governing such product, service, or offering; or (xii) in the sole judgment of Offchain Labs, is objectionable or which restricts or inhibits any other person from using or enjoying the Services, which may expose Offchain Labs or its users to any harm or liability of any type, or otherwise violates these Terms of Service. Portions of the Services may include notices of open source or similar licenses, and you will comply with such licenses.Consequences of Non-Compliance. Offchain Labs reserves the right to review, investigate, and take any action it deems appropriate, in its sole discretion, for any violation of this Section, including reporting such violations to law enforcement authorities, court, or government, as applicable. Furthermore, if Offchain Labs determines, in its sole discretion, that you have breached any of your obligations under this Section, or that your continued access to, or use of, the Services could result in Offchain Labs' violation of Applicable Law or expose Offchain Labs to legal liability or any other adverse consequences, Offchain Labs may elect to suspend or block your access to the Services and restrict access any interests in property, in each case, without prior notice.Non-circumvention of Restrictions. If your access to the Services, or any part thereof, is suspended, restricted or blocked by Offchain Labs, including, for example, by blocking your internet protocol (IP) address, you agree not to take any actions to circumvent such restrictions or blocking, including but not limited to, masking your IP address, using a proxy IP address, or accessing the Services via a virtual private network.No Professional Advice and No Fiduciary Duties. All information provided by or through the Services (including Service Content (as defined below)) is for informational purposes only and should not be construed as professional advice. You should not take, or refrain from taking, any action based on any information contained in the Services. Before you make any financial, legal, tax, or other decisions involving the Services, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate. These Terms of Service are not intended to, and do not, create or impose any fiduciary duties on us. To the fullest extent permitted by law, you acknowledge and agree that we owe no fiduciary duties or liabilities to you or any other party, and that to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated. You further agree that the only duties and obligations that we owe you are those set out expressly in these Terms of Service.Intellectual Property RightsService Content. You acknowledge and agree that the Services may contain content or features (\"Service Content\") that are protected by copyright, patent, trademark, trade secret, or other proprietary rights and laws. Except as expressly authorized by Offchain Labs (e.g., to the extent such portion of the Service Content is made available under an open source license), you agree not to modify, copy, frame, scrape, rent, lease, loan, sell, distribute, or create derivative works based on the Services or the Service Content, in whole or in part, except that the foregoing does not apply to any User Content. Any use of the Service Content other than as specifically authorized within these Terms is strictly prohibited.Offchain Labs Trademarks. The Offchain Labs name, logo, and certain other names, logos, and marks used in connection with the Services are trademarks or service marks of Offchain Labs (collectively, the \"Offchain Labs' Trademarks\"). Nothing in these Terms of Service or the Services should be construed as granting, by implication, estoppel, or otherwise, any license or right to use any of Offchain Labs' Trademarks, without our prior written permission in each instance. If you qualify as a licensee of the Offchain Brand Assets as defined under the Brand Policy, such Brand Policy shall govern over any conflicting terms with these Terms of Service.Feedback. If you provide us with any feedback or suggestions regarding the Services (\"Feedback\"), you hereby assign to Offchain Labs all rights in such Feedback and agree that Offchain Labs shall have all necessary rights to use and fully exploit such Feedback and related information in any manner we deem appropriate. Offchain Labs will treat any Feedback you provide as non-confidential and non-proprietary. You agree not to submit any Feedback or other information or ideas that you consider to be confidential or proprietary, or for which you do not have all necessary rights, permissions, and consents. For the avoidance of doubt, you agree not to submit any Feedback that infringes any intellectual property or other proprietary rights of any person. In addition, Offchain Labs may provide you with feedback or suggestions regarding Your Apps or other items, at your request. You agree that all such feedback or suggestions are provided on an as-is basis, and Offchain Labs will not have liability to you with respect to such feedback or suggestions.Third-Party Content. The Services may include content, materials, or information made available by third parties (including other users) that Offchain Labs does not control (\"Third-Party Content\"). Under no circumstances will Offchain Labs be liable in any way for any Third-Party Content, including for any errors or omissions in such content, or for any loss, harm, or damage of any kind incurred as a result of your use of, or reliance on any such content. You acknowledge that Offchain Labs does not pre-screen Third-Party Content, but may, in its sole discretion, monitor, refuse, or remove any content made available via Services. Without limiting the foregoing, Offchain Labs reserves the right to remove, without notice, any Third-Party Content that violates these Terms of Service or is otherwise deemed by Offchain Labs, in its sole discretion, to be otherwise objectionable. You agree that you are solely responsible for evaluating and shall assume all risk associated with any Third-Party Content, including any reliance on its accuracy, completeness, or usefulness.Third-Party Trademarks. The Services may display the names and logos of certain third-party companies, products, or services (collectively, the \"Third-Party Trademarks\"), which may be trademarks or service marks of the respective third-party owner. Such third-party owners may or may not endorse, be affiliated with, sponsor, or otherwise be connected to Offchain Labs. Nothing in these Terms of Service or the Services shall be construed as granting, by implication, estoppel, or otherwise, any license or right to use any Third-Party Trademarks without first obtaining all necessary rights, authorizations, licenses, or permissions from the applicable third-party owner.User Content. You represent and warrant that you own all right, title, and interest in and, or have all applicable permissions or licenses to utilize, such User Content that you make available via the Site or otherwise use in connection with your interactions with the Services, including all copyrights and rights of publicity contained therein. You hereby grant Offchain Labs and its affiliated companies, successors, and assigns a non-exclusive, worldwide, royalty-free, fully paid-up, transferable, sublicensable (directly and indirectly through multiple tiers), perpetual, and irrevocable license to copy, display, upload, perform, distribute, store, modify, and otherwise use such User Content in connection with the operation of the Site and the provision of the Services. You assume all risk associated with your User Content and the transmission of your User Content, and you have sole responsibility for the accuracy, quality, legality, and appropriateness of your User Content.Any questions, comments, ideas, forms, Feedback, reviews, or other information about the Services (\"Submissions\"), provided by you to Offchain Labs are non-confidential and Offchain Labs will be entitled to the unrestricted use and dissemination of such Submissions for any purpose, commercial or otherwise, without acknowledgment, attribution, or compensation to you.You acknowledge and agree that Offchain Labs may preserve User Content and may also disclose User Content if required to do so by law or in the good faith belief that such preservation or disclosure is reasonably necessary to: (i) comply with legal process, applicable laws, or government requests; (ii) enforce these Terms of Service; (iii) respond to claims that any content violates the rights of third parties; or (iv) protect the rights, property, or personal safety of Offchain Labs, its users, or the public. You understand that the technical processing and transmission of the Services, including your User Content, may involve transmissions over various networks, which may involve technical modifications of data in order to conform and adapt such data to the technical requirements of such networks.Third-Party Services. Certain Services (or portions thereof) may provide access to, integrate, or be integrated into services, sites, technologies, applications, smart contracts, protocols, chains, tools, and other offerings that are facilitated through, or otherwise made available by third parties (collectively \"Third-Party Services\").Fourth Parties. Certain Third-Party Services may provide access to their respective services, sites, technologies, applications, smart contracts, protocols, chains, tools, and/or other offerings through additional parties (hereinafter, \"Fourth Parties\"). In such cases, the Third-Party Service you interact with, engage with, or otherwise use, may not be the entity that directly makes available or facilitates the service or functionality you are interacting with. For the purposes of these Terms, any services, products, or offerings provided by Fourth Parties shall be deemed part of the applicable \"Third-Party Services\" and references to \"Third-Party Services\" and \"Third-Party Fees\" shall include such Fourth-Party services and fees, as applicable.Third-Party Terms. Your access to and use of any Third-Party Services may be subject to additional terms and conditions, privacy policies, or other agreements established by the applicable third-party provider (collectively, the \"Third-Party Terms\"). Such Third-Party Terms may include additional disclaimers, risk warnings, indemnification obligations, restrictions, and privacy policies that are separate from these Terms. It is your sole responsibility to review, understand, and comply with any applicable Third-Party Terms prior to using such Third-Party Services. We encourage you to review the applicable privacy policies and Third-Party Terms before accessing, using, or otherwise engaging with any Third-Party Service.Modification of Third-Party Services. Offchain Labs reserves the right to change, suspend, remove, disable, or impose access restrictions or limitations on any Third-Party Services at any time, without notice.No Control or Endorsement. Offchain Labs has no control over, and is not responsible for, any Third-Party Services, including the accuracy, availability, reliability, or completeness of any services, products, or content provided through them, or for any third-party policies or privacy practices. The integration or inclusion of any Third-Party Services within the Services does not constitute or imply any endorsement, recommendation, or guarantee by Offchain Labs.Third-Party Risks and Costs. You acknowledge and agree that your access to and use of any Third-Party Services is at your own election and risk. You, and not Offchain Labs, will be solely responsible for any and all costs, fees, or charges associated with your use of any Third-Party Services. Your decision to use any Third-Party Services is your own, and you are solely responsible for ensuring that your use complies with all applicable laws and the terms imposed by the third-party provider. Any dealings, transactions, or correspondence you may have with a third party, whether through the Services or in connection with a Third-Party Service, are solely between you and that third party. Offchain Labs disclaims all responsibility and liability, direct or indirect, for any damage, loss, or harm caused, alleged to be caused by, or arising from your use of, or reliance on, any Third-Party Service.Indemnification and ReleaseYou agree to defend, indemnify, and hold harmless Offchain Labs, its affiliates, and each of Offchain Labs' and its affiliates' respective officers, employees, directors, service providers, licensors, and agents (collectively, the \"Offchain Labs Parties\") from any and all losses, damages, expenses, including reasonable attorneys' fees, rights, claims, actions of any kind, and injury (including death) arising out of or relating to (i) your access to or use of the Services, Third-Party Content, or Third-Party Services; (ii) User Content; (iii) Your Apps; (iv) your Wallet, including connecting your Wallet to any of the Services; (v) your Submissions (as defined below); (vi) your violation of these Terms of Service or Third-Party Terms; (vii) your violation of any rights of another person and/or your gross negligence or willful misconduct (each a \"Claim\"). Offchain Labs will provide notice to you of any such Claim pursuant to Section 13.8. Offchain Labs reserves the right to assume the exclusive defense and control of any matter that is subject to indemnification under this Section, and you agree to cooperate with any reasonable requests assisting Offchain Labs' defense of such matter. You may not settle or compromise any claim against the Offchain Labs Parties without Offchain Labs' prior written consent.Disclaimer of Warranties; Assumption of RiskGeneral Disclaimers.YOU EXPRESSLY AGREE THAT YOU ASSUME ALL RISKS IN CONNECTION WITH YOUR ACCESS AND USE OF THE SERVICES, INCLUDING YOUR INTERACTION WITH THE SITE, OFFERINGS, INTERFACE, THIRD-PARTY CONTENT, BLOCKCHAIN NETWORK, PROTOCOLS, AND THIRD-PARTY SERVICES. YOU FURTHER EXPRESSLY WAIVE AND RELEASE US FROM ANY AND ALL LIABILITY, CLAIMS, CAUSES OF ACTION, OR DAMAGES ARISING FROM OR IN ANY WAY RELATING TO YOUR USE OF THE SERVICES, INCLUDING YOUR INTERACTION WITH THE INTERFACE, OFFERINGS, AND THIRD-PARTY SERVICES.YOUR USE OF THE SERVICES IS AT YOUR SOLE RISK. THE SERVICES ARE PROVIDED ON AN \"AS IS\" AND \"AS AVAILABLE\" BASIS. THE OFFCHAIN LABS PARTIES EXPRESSLY DISCLAIM ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT.WITHOUT LIMITING THE FOREGOING, THE OFFCHAIN LABS PARTIES MAKE NO WARRANTY THAT: (A) THE SERVICES WILL MEET YOUR REQUIREMENTS; (B) THE SERVICES WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE; (C) THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF THE SERVICES WILL BE ACCURATE OR RELIABLE; OR (D) THE QUALITY OF ANY PRODUCTS, SERVICES, APPLICATIONS, INFORMATION, OR OTHER MATERIAL PURCHASED OR OBTAINED BY YOU THROUGH THE SERVICES WILL MEET YOUR EXPECTATIONS.BY USING OR INTERACTING WITH THE SERVICES, YOU ACKNOWLEDGE AND AGREE THAT ALL INTERACTIONS WITH THE APPLICABLE SERVICE AND ANY THIRD-PARTY SERVICES ACCESSED THROUGH THE SERVICES, INCLUDING, WITHOUT LIMITATION, EXECUTING TRANSACTIONS VIA THE INTERFACE, CONSTITUTE UNSOLICITED ACTIVITY INITIATED ENTIRELY AT YOUR OWN DISCRETION. OFFCHAIN LABS DOES NOT PRE-SCREEN, REVIEW, OR VALIDATE THE CONTENT, PURPOSE, OR SECURITY OF ANY TRANSACTIONS YOU CHOOSE TO PERFORM.YOU ACKNOWLEDGE ANY PRICING INFORMATION OR OTHER CONTENT DISPLAYED ON OR THROUGH THE SERVICES IS PROVIDED SOLELY FOR INFORMATIONAL PURPOSES AND DOES NOT CONSTITUTE AN OFFER, SOLICITATION, ADVICE, OR RECOMMENDATION BY OFFCHAIN LABS REGARDING ANY TRANSACTION. OFFCHAIN LABS MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE SUITABILITY, RELIABILITY, AVAILABILITY, ACCURACY, OR COMPLETENESS OF ANY SUCH INFORMATION FOR ANY PURPOSE.YOU ACKNOWLEDGE AND AGREE THAT WE ARE NOT RESPONSIBLE FOR ANY RISKS ASSOCIATED WITH YOUR USE OF THE SERVICE, AND WE CANNOT BE HELD LIABLE FOR ANY RESULTING LOSSES THAT YOU EXPERIENCE WHILE ACCESSING OR USING THE SERVICE.Blockchain and Digital Assets Disclaimers.CERTAIN SERVICES RELY ON OR ENABLE YOU TO INTERACT WITH BLOCKCHAIN-RELATED TECHNOLOGIES, WHICH CARRY INHERENT RISKS, INCLUDING, WITHOUT LIMITATION, TECHNOLOGICAL, SECURITY, REGULATORY, AND MARKET RISKS. BY ACCESSING OR USING THE SERVICES, YOU ACKNOWLEDGE AND ACCEPT THE RISKS ASSOCIATED AND REPRESENT AND WARRANT TO EACH OF THE FOLLOWING:(i) YOU UNDERSTAND THE INHERENT RISKS ASSOCIATED WITH USING CRYPTOGRAPHIC AND BLOCKCHAIN-BASED SYSTEMS, AND THAT YOU HAVE A WORKING KNOWLEDGE OF THE USAGE AND INTRICACIES OF DIGITAL ASSETS AND BRIDGING ACROSS DIFFERENT BLOCKCHAIN SOLUTIONS. YOU UNDERSTAND THAT SMART CONTRACT TRANSACTIONS AUTOMATICALLY EXECUTE AND SETTLE, AND THAT BLOCKCHAIN-BASED TRANSACTIONS ARE IRREVERSIBLE ONCE CONFIRMED. YOU FURTHER UNDERSTAND THAT THE MARKETS FOR DIGITAL ASSETS ARE HIGHLY VOLATILE DUE TO VARIOUS FACTORS, INCLUDING ADOPTION, SPECULATION, TECHNOLOGY, SECURITY, AND REGULATION.(ii) YOU UNDERSTAND THAT BLOCKCHAIN NETWORKS, PROTOCOLS, SMART CONTRACTS, AND OTHER RELATED TECHNOLOGIES MAY BE SUSCEPTIBLE TO SECURITY BREACHES, EXPLOITS, HACKS, BUGS, AND DESIGN OR IMPLEMENTATION FLAWS THAT COULD RESULT IN THE COMPLETE LOSS OF YOUR DIGITAL ASSETS. YOU UNDERSTAND THAT UPDATES TO ANY NETWORK, PROTOCOL, SMART CONTRACT, THIRD-PARTY SERVICE, WALLET, OR RELATED BLOCKCHAIN TECHNOLOGIES MAY CONTAIN UNDETECTED DEFECTS OR VULNERABILITIES THAT COULD COMPROMISE FUNCTIONALITY OR SECURITY, POTENTIALLY RESULTING IN LOSS OF DIGITAL ASSETS OR ACCESS TO YOUR DIGITAL ASSETS.(iii) YOU ACKNOWLEDGE AND ACCEPT THAT THE COST AND SPEED OF TRANSACTING WITH CRYPTOGRAPHIC AND BLOCKCHAIN-BASED SYSTEMS, INCLUDING ARBITRUM AND ETHEREUM, ARE VARIABLE AND MAY INCREASE DRAMATICALLY AT ANY TIME. YOU FURTHER ACKNOWLEDGE AND ACCEPT THE RISK THAT YOUR DIGITAL ASSETS MAY LOSE SOME OR ALL OF THEIR VALUE DUE TO PRICE FLUCTUATIONS.(iv) YOU UNDERSTAND THAT ANYONE CAN CREATE DIGITAL ASSETS, SMART CONTRACTS, DECENTRALIZED APPLICATIONS, PROTOCOLS, AND OTHER BLOCKCHAIN ASSOCIATED OFFERINGS, INCLUDING FAKE OR FRAUDULENT VERSIONS THAT FALSELY CLAIM AFFILIATION WITH LEGITIMATE PROJECTS (COLLECTIVELY, \"BLOCKCHAIN MATERIALS\").(v) YOU HAVE CONDUCTED SUFFICIENT RESEARCH AND DUE DILIGENCE BEFORE EXECUTING ANY TRANSACTION, MAKING ANY PURCHASE OR TRANSFER OF DIGITAL ASSETS, OR OTHERWISE INTERACTING WITH OR UTILIZING ANY BLOCKCHAIN PROTOCOL, OTHER BLOCKCHAIN MATERIALS, OR ANY THIRD-PARTY SERVICES.(vi) YOU ACKNOWLEDGE AND AGREE THAT OFFCHAIN LABS DOES NOT CONTROL ANY BLOCKCHAIN PROTOCOL. ADDITIONALLY, WITH THE EXCEPTION OF THOSE CERTAIN SMART CONTRACTS THAT OFFCHAIN LABS DIRECTLY OWNS AND CONTROLS, OFFCHAIN DOES NOT CONTROL NOR REPRESENT TO CONTROL ANY SMART CONTRACTS. OFFCHAIN LABS MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE IDENTITY, LEGITIMACY, FUNCTIONALITY, OR AUTHENTICITY OF ANY BLOCKCHAIN MATERIALS, EVEN IF SUCH MATERIALS ARE ACCESSIBLE OR DISPLAYED THROUGH THE SERVICES.(vii) YOU ACKNOWLEDGE AND ACCEPT YOU ARE SOLELY RESPONSIBLE FOR INDEPENDENTLY VERIFYING THE IDENTITY, LEGITIMACY, AUTHENTICITY, AND FUNCTIONALITY OF ANY BLOCKCHAIN MATERIALS THAT YOU CHOOSE TO INTERACT WITH AND YOU EXPRESSLY ACKNOWLEDGE THAT YOU, NOT OFFCHAIN LABS, SHALL BEAR COMPLETE AND SOLE RESPONSIBILITY FOR ALL SUCH INTERACTIONS AND THE OUTCOMES OF SUCH INTERACTIONS WITH ANY BLOCKCHAIN MATERIALS, INCLUDING THOSE CREATED BY THIRD PARTIES TO IMPERSONATE OR FALSELY SUGGEST AFFILIATION WITH LEGITIMATE BLOCKCHAIN PROJECTS.(viii) YOU ARE SOLELY RESPONSIBLE FOR SAFEGUARDING YOUR WALLETS, INCLUDING YOUR WALLET CREDENTIALS, AND FOR ANY ACTIVITY THAT OCCURS USING YOUR WALLET OR WALLET CREDENTIALS. YOU UNDERSTAND THAT ANY COMPROMISE OF YOUR WALLET CREDENTIALS MAY RESULT IN THE PERMANENT LOSS OF YOUR DIGITAL ASSETS AND/OR ACCESS TO YOUR WALLET. OFFCHAIN LABS ASSUMES NO LIABILITY FOR ANY SUCH COMPROMISE.(ix) YOU ACKNOWLEDGE AND AGREE THAT OFFCHAIN LABS ASSUMES NO RESPONSIBILITY REGARDING THE REGULATORY CLASSIFICATION OR LEGAL TREATMENT OF ANY BLOCKCHAIN MATERIALS IN ANY JURISDICTION THAT YOU MAY ACCESS OR INTERACT WITH THROUGH THE SERVICES. YOU FURTHER ACKNOWLEDGE THAT DIGITAL ASSETS, BLOCKCHAIN TECHNOLOGY, AND RELATED SOFTWARE AND SERVICES ARE SUBJECT TO SIGNIFICANT LEGAL AND REGULATORY UNCERTAINTY IN THE UNITED STATES AND OTHER JURISDICTIONS. YOU UNDERSTAND THAT LEGISLATIVE, JUDICIAL AND REGULATORY CHANGES OR ACTIONS MAY ADVERSELY AFFECT THE USAGE, TRANSFERABILITY, TRANSACTABILITY, OR ACCESSIBILITY OF DIGITAL ASSETS, BRIDGING, ACCESS TO INTERFACES, AND/OR OTHER PARTS OF THE SERVICES.(x) YOU UNDERSTAND THAT THERE MAY BE TAX RISKS RELATED TO YOUR USE OF THE SERVICES. IT IS YOUR SOLE RESPONSIBILITY TO DETERMINE WHETHER, AND TO WHAT EXTENT, ANY TAXES APPLY TO YOUR TRANSACTIONS OR ACTIVITIES, AND TO WITHHOLD, COLLECT, REPORT, AND REMIT THE CORRECT AMOUNTS TO THE APPROPRIATE TAX AUTHORITIES.Third-Party Risk Disclaimers.YOU ACKNOWLEDGE AND AGREE THAT THERE ARE CERTAIN RISKS ASSOCIATED WITH YOUR INTERACTIONS WITH THIRD PARTIES, INCLUDING: (I) INTERACTIONS WITH OTHER USERS OF THE SERVICES AND USERS OF THIRD-PARTY SERVICES (COLLECTIVELY, \"THIRD-PARTY USERS\"); AND (II) YOUR USE OF THIRD-PARTY SERVICES. BY INTERACTING WITH, ACCESSING, OR USING ANY THIRD-PARTY USERS, THIRD-PARTY SERVICES, OR THIRD-PARTY CONTENT, YOU ACKNOWLEDGE AND ACCEPT THE RISKS ASSOCIATED AND REPRESENT AND WARRANT TO EACH OF THE FOLLOWING:(i) YOU ACKNOWLEDGE AND AGREE THAT OFFCHAIN LABS POSSESSES NO AUTHORITY OR CONTROL OVER ANY THIRD-PARTY SERVICES. YOU FURTHER ACKNOWLEDGE THAT THIRD-PARTY SERVICES AND/OR THIRD-PARTY CONTENT MAY CONTAIN CERTAIN RISKS, INCLUDING, AS APPLICABLE, SECURITY VULNERABILITIES, BUGS, AND LEGAL UNCERTAINTIES, AND THAT YOUR USE OF THIRD-PARTY SERVICES OR INTERACTIONS WITH THIRD-PARTY CONTENT MAY EXPOSE YOU TO LOSS, UNAUTHORIZED ACCESS, COMPROMISED DATA, OR OTHER ADVERSE CONSEQUENCES.(ii) OFFCHAIN LABS DOES NOT AUDIT, REVIEW, OR GUARANTEE THE SECURITY, LEGITIMACY, FUNCTIONALITY, LEGALITY, COMPLIANCE, OR SUITABILITY OF ANY THIRD-PARTY SERVICES OR THIRD-PARTY CONTENT, AND MAKES NO WARRANTIES, REPRESENTATIONS, OR GUARANTEES OF ANY KIND WITH RESPECT TO ANY THIRD-PARTY SERVICES OR THIRD-PARTY CONTENT.(iii) YOU ACKNOWLEDGE AND AGREE THAT OFFCHAIN LABS MAKES NO WARRANTIES, REPRESENTATIONS, OR GUARANTEES REGARDING THE ACCURACY, AVAILABILITY, RELIABILITY, COMPLETENESS, FUNCTIONALITY, LEGALITY, SECURITY, ACCESSIBILITY, OR SUITABILITY OF ANY THIRD-PARTY SERVICES OR THIRD-PARTY CONTENT.(iv) YOU ARE SOLELY RESPONSIBLE FOR INDEPENDENTLY VERIFYING THE IDENTITY, LEGITIMACY, AUTHENTICITY, AND FUNCTIONALITY OF ANY THIRD-PARTY SERVICES, OR THIRD-PARTY CONTENT THAT YOU CHOOSE TO ACCESS OR INTERACT WITH. EVEN IF SUCH THIRD-PARTY SERVICES AND/OR THIRD-PARTY CONTENT ARE ACCESSIBLE OR DISPLAYED THROUGH OR ON THE SERVICES. YOU ACKNOWLEDGE AND AGREE THAT OFFCHAIN LABS MAKES NO REPRESENTATIONS ABOUT THEIR LEGITIMACY OR SAFETY.(v) YOU ACKNOWLEDGE AND AGREE THAT OFFCHAIN LABS EXPRESSLY DISCLAIMS ALL RESPONSIBILITY AND LIABILITY FOR ANY LOSSES ARISING FROM YOUR ACCESS TO, USE OF, OR RELIANCE ON ANY THIRD-PARTY SERVICES OR THIRD-PARTY CONTENT.(vi) YOU ACKNOWLEDGE AND AGREE THAT YOU SHALL BEAR SOLE AND COMPLETE RESPONSIBILITY FOR ALL INTERACTIONS, TRANSACTIONS, AND ENGAGEMENTS WITH ANY THIRD-PARTY USERS AND/OR THIRD-PARTY SERVICES, INCLUDING ANY THIRD-PARTY FEES. OFFCHAIN LABS WILL HAVE NO LIABILITY OR RESPONSIBILITY WITH RESPECT THERETO.(vii) ALL DISPUTES BETWEEN YOU AND ANY THIRD PARTY, INCLUDING THIRD-PARTY USERS OR PROVIDERS OF THIRD-PARTY SERVICES, ARE SOLELY BETWEEN YOU AND SUCH THIRD PARTY. OFFCHAIN LABS EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITY OR LIABILITY ARISING FROM SUCH DISPUTES.Limitation of Liability. YOU EXPRESSLY UNDERSTAND AND AGREE THAT THE OFFCHAIN LABS PARTIES WILL NOT BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY DAMAGES, OR DAMAGES FOR LOSS OF PROFITS INCLUDING DAMAGES FOR LOSS OF GOODWILL, USE, OR DATA OR OTHER INTANGIBLE LOSSES (EVEN IF THE OFFCHAIN LABS PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES), WHETHER BASED ON CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY, OR OTHERWISE, ARISING FROM OR RELATING TO: (A) THE USE OR THE INABILITY TO USE THE SERVICES, OR ANY PART THEREOF; (B) THE COST OF PROCUREMENT OF SUBSTITUTE GOODS AND SERVICES RESULTING FROM ANY GOODS, DATA, INFORMATION, OR SERVICES PURCHASED OR OBTAINED OR MESSAGES RECEIVED OR TRANSACTIONS ENTERED INTO THROUGH OR FROM THE SERVICES; (C) UNAUTHORIZED ACCESS TO OR ALTERATION OF YOUR TRANSMISSIONS OR DATA; (D) STATEMENTS OR CONDUCT OF ANY THIRD PARTY ON OR THROUGH THE SERVICES; (E) INTERRUPTION OR CESSATION OF FUNCTION RELATED TO THE SERVICES; (F) BUGS, VIRUSES, TROJAN HORSES, OR THE LIKE THAT MAY BE TRANSMITTED TO OR THROUGH THE SERVICES; (G) ERRORS OR OMISSIONS IN, OR LOSS OR DAMAGE INCURRED AS A RESULT OF THE USE OF, ANY CONTENT MADE AVAILABLE THROUGH THE SERVICES; (H) THIRD-PARTY SERVICES, THIRD PARTY CONTENT, AND/OR OTHER THIRD PARTY MATERIALS; OR (I) ANY OTHER MATTER RELATING TO THE SERVICES OR ANY PART THEREOF. IN NO EVENT WILL THE OFFCHAIN LABS PARTIES' TOTAL LIABILITY TO YOU FOR ALL DAMAGES, LOSSES, OR CAUSES OF ACTION EXCEED THE AMOUNT OF FEES OWED BY YOU AND WHICH YOU HAVE PAID TO OFFCHAIN LABS IN THE LAST SIX (6) MONTHS, OR, IF GREATER, ONE HUNDRED DOLLARS ($100).SOME JURISDICTIONS DO NOT ALLOW THE DISCLAIMER OR EXCLUSION OF CERTAIN WARRANTIES OR THE LIMITATION OR EXCLUSION OF LIABILITY FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES. ACCORDINGLY, SOME OF THE ABOVE LIMITATIONS SET FORTH ABOVE MAY NOT APPLY TO YOU OR BE ENFORCEABLE WITH RESPECT TO YOU. IF YOU ARE DISSATISFIED WITH ANY PORTION OF THE SERVICES OR WITH THESE TERMS, YOUR SOLE AND EXCLUSIVE REMEDY IS TO DISCONTINUE USE OF THE SERVICES.IF YOU ARE A USER FROM NEW JERSEY, THE FOREGOING SECTIONS TITLED \"DISCLAIMER OF WARRANTIES; ASSUMPTION OF RISK\" AND \"LIMITATION OF LIABILITY\" ARE INTENDED TO BE ONLY AS BROAD AS IS PERMITTED UNDER THE LAWS OF THE STATE OF NEW JERSEY. IF ANY PORTION OF THESE SECTIONS IS HELD TO BE INVALID UNDER THE LAWS OF THE STATE OF NEW JERSEY, THE INVALIDITY OF SUCH PORTION WILL NOT AFFECT THE VALIDITY OF THE REMAINING PORTIONS OF THE APPLICABLE SECTIONS.IF YOU ARE A CALIFORNIA RESIDENT, YOU WAIVE CALIFORNIA CIVIL CODE SECTION 1542, WHICH SAYS: \"A GENERAL RELEASE DOES NOT EXTEND TO CLAIMS THAT THE CREDITOR OR RELEASING PARTY DOES NOT KNOW OR SUSPECT TO EXIST IN HIS OR HER FAVOR AT THE TIME OF EXECUTING THE RELEASE AND THAT, IF KNOWN BY HIM OR HER, WOULD HAVE MATERIALLY AFFECTED HIS OR HER SETTLEMENT WITH THE DEBTOR OR RELEASING PARTY.\" IF YOU ARE A RESIDENT OF ANOTHER JURISDICTION, YOU WAIVE ANY COMPARABLE STATUTE OR DOCTRINE.Dispute Resolution by Binding ArbitrationPLEASE READ THIS SECTION CAREFULLY AS IT AFFECTS YOUR RIGHTS.Agreement to Arbitrate. This Dispute Resolution by Binding Arbitration section is referred to in these Terms of Service as the \"Arbitration Agreement.\" You agree that any and all disputes or claims that have arisen or may arise between you and Offchain Labs, whether arising out of or relating to these Terms of Service (including any alleged breach thereof), the Services, any advertising, or any aspect of the relationship or transactions between you and Offchain Labs, will be resolved exclusively through final and binding arbitration, rather than a court, in accordance with the terms of this Arbitration Agreement, except that you may assert individual claims in small claims court, if your claims qualify. Further, this Arbitration Agreement does not preclude you from bringing issues to the attention of federal, state, or local agencies, and such agencies can, if the law allows, seek relief against us on your behalf. You agree that, by entering into these Terms of Service, you and Offchain Labs are each waiving the right to a trial by jury or to participate in a class action. Each party's rights will be determined by a neutral arbitrator, not a judge or jury. The Federal Arbitration Act governs the interpretation and enforcement of this Arbitration Agreement.Prohibition of Class and Representative Actions and Non-Individualized Relief. YOU AND OFFCHAIN LABS AGREE THAT EACH OF US MAY BRING CLAIMS AGAINST THE OTHER ONLY ON AN INDIVIDUAL BASIS AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS OR REPRESENTATIVE ACTION OR PROCEEDING. UNLESS BOTH YOU AND OFFCHAIN LABS AGREE OTHERWISE, THE ARBITRATOR MAY NOT CONSOLIDATE OR JOIN MORE THAN ONE PERSON'S OR PARTY'S CLAIMS AND MAY NOT OTHERWISE PRESIDE OVER ANY FORM OF A CONSOLIDATED, REPRESENTATIVE, OR CLASS PROCEEDING. ALSO, THE ARBITRATOR MAY AWARD RELIEF (INCLUDING MONETARY, INJUNCTIVE, AND DECLARATORY RELIEF) ONLY IN FAVOR OF THE INDIVIDUAL PARTY SEEKING RELIEF AND ONLY TO THE EXTENT NECESSARY TO PROVIDE RELIEF NECESSITATED BY THAT PARTY'S INDIVIDUAL CLAIM(S), EXCEPT THAT YOU MAY PURSUE A CLAIM FOR AND THE ARBITRATOR MAY AWARD PUBLIC INJUNCTIVE RELIEF UNDER APPLICABLE LAW TO THE EXTENT REQUIRED FOR THE ENFORCEABILITY OF THIS PROVISION.Pre-Arbitration Dispute Resolution. Offchain Labs is always interested in resolving disputes amicably and efficiently, and most concerns can be resolved quickly and to the user's satisfaction by emailing our support team at info@offchainlabs.com. A party intending to seek arbitration must first send to the other, by certified mail, a written Notice of Dispute (\"Notice\"). The Notice to Offchain Labs must be sent to 377 Valley Rd, Unit #2644, Clifton, New Jersey 07013, United States (\"Notice Address\"). The Notice must (i) describe the nature and basis of the claim or dispute and (ii) set forth the specific relief sought. If Offchain Labs and you do not resolve the claim within sixty (60) calendar days after the Notice is received, you or Offchain Labs may commence an arbitration proceeding. During the arbitration proceeding, the amount of any settlement offers made by Offchain Labs or you will not be disclosed to the arbitrator until after the arbitrator determines the amount, if any, to which you or Offchain Labs is entitled.Arbitration Procedures. You agree that the U.S. Federal Arbitration Act governs the interpretation and enforcement of these Terms of Service. Arbitration will be conducted by a neutral arbitrator in accordance with JAMS Comprehensive Arbitration Rules and Procedures (collectively, the \"JAMS Rules\"), as modified by this Arbitration Agreement. If there is any inconsistency between any term of the JAMS Rules and any term of this Arbitration Agreement, the applicable terms of this Arbitration Agreement will control unless the arbitrator determines that the application of the inconsistent Arbitration Agreement terms would not result in a fundamentally fair arbitration. The arbitrator must also follow the provisions of these Terms of Service as a court would. All issues are for the arbitrator to decide, including issues relating to the scope, enforceability, and arbitrability of this Arbitration Agreement. Although arbitration proceedings are usually simpler and more streamlined than trials and other judicial proceedings, the arbitrator can award the same damages and relief on an individual basis that a court can award to an individual under these Terms of Service and applicable law. Decisions by the arbitrator are enforceable in court and may be overturned by a court only for very limited reasons.Unless Offchain Labs and you agree otherwise, any arbitration hearings will take place in a reasonably convenient location for both parties, with due consideration of each party's ability to travel and other pertinent circumstances. If the parties are unable to agree on a location, the determination will be made by JAMS. The right to an arbitration hearing will be determined by the JAMS Rules. Regardless of the manner in which the arbitration is conducted, the arbitrator will issue a reasoned written decision sufficient to explain the essential findings and conclusions on which the award is based.Costs of Arbitration. Payment of all filing, administration, and arbitrator fees (collectively, the \"Arbitration Fees\") will be governed by the JAMS Rules, unless otherwise provided in this Arbitration Agreement. If the value of the relief sought is $75,000 or less, at your written request, Offchain Labs will pay all Arbitration Fees. If the value of relief sought is more than $75,000 and you are able to demonstrate to the arbitrator that you are economically unable to pay your portion of the Arbitration Fees or if the arbitrator otherwise determines for any reason that you should not be required to pay your portion of the Arbitration Fees, Offchain Labs will pay your portion of such fees. In addition, if you demonstrate to the arbitrator that the costs of arbitration will be prohibitive as compared to the costs of litigation, Offchain Labs will pay as much of the Arbitration Fees as the arbitrator deems necessary to prevent the arbitration from being cost-prohibitive. Any payment of your attorneys' fees will be governed by the JAMS Rules.Confidentiality. All aspects of the arbitration proceeding, and any ruling, decision, or award by the arbitrator, will be strictly confidential for the benefit of all parties.Severability. If a court or the arbitrator decides that any term or provision of this Arbitration Agreement (other than Section titled \"Prohibition of Class and Representative Actions and Non-Individualized Relief\" above) is invalid or unenforceable, the parties agree to replace such term or provision with a term or provision that is valid and enforceable and that comes closest to expressing the intention of the invalid or unenforceable term or provision, and this Arbitration Agreement will be enforceable as so modified. If a court or the arbitrator decides that any of the provisions of the Section titled \"Prohibition of Class and Representative Actions and Non-Individualized Relief\" are invalid or unenforceable, then the entirety of this Arbitration Agreement will be null and void, unless such provisions are deemed to be invalid or unenforceable solely with respect to claims for public injunctive relief. The remainder of these Terms of Service will continue to apply.Future Changes to Arbitration Agreement. Notwithstanding any provision in these Terms of Service to the contrary, Offchain Labs agrees that if it makes any future change to this Arbitration Agreement (other than a change to the Notice Address) while you are a user of the Services, you may reject any such change by sending Offchain Labs written notice to the Notice Address within thirty (30) calendar days of your first interaction with the Services after such change to the Arbitration Agreement. For the avoidance of doubt, such rejection of change, as detailed in this Section, only applies to the Arbitration Agreement, and all other terms under these Terms of Use are immediately binding upon posting. By rejecting any future change to the Arbitration Agreement, you are agreeing that you will arbitrate any dispute between us in accordance with the language of this Arbitration Agreement as of the date you first accepted these Terms of Service (or accepted any subsequent changes to these Terms of Service).User Disputes. Without limiting anything set forth within this Agreement, you agree that Offchain Labs reserves the right, but has no obligation, to become involved in any disputes between you and any third party, including disputes arising out of Third-Party Content and/or Third-Party Services. Offchain Labs may exercise this right in its sole and absolute discretion. For the avoidance of doubt, unless Offchain Labs expressly elects to become involved, all disputes between you and any third party shall remain solely between you and the applicable third party.GeneralGoverning Law. These Terms of Service (together with the terms incorporated by reference herein) constitute the entire agreement between you and Offchain Labs governing your access and use of the Services, and supersede any prior agreements between you and Offchain Labs with respect to the Services. You also may be subject to additional terms and conditions that may apply when you use or access Third-Party Services, or Third-Party Content. These Terms of Service will be governed by the laws of the State of Delaware without regard to its conflict of law provisions. With respect to any disputes or claims not subject to arbitration, as set forth above, you and Offchain Labs submit to the personal and exclusive jurisdiction of the state and federal courts located within New York, New York. The failure of Offchain Labs to exercise or enforce any right or provision of these Terms of Service will not constitute a waiver of such right or provision.Severability. If any provision of these Terms of Service is found by a court of competent jurisdiction to be invalid, the parties nevertheless agree that the court should endeavor to give effect to the parties' intentions as reflected in the provision, and the other provisions of these Terms of Service remain in full force and effect.Limitations for Claims. To the fullest extent permitted by law, you agree that regardless of any statute or law to the contrary, any claim or cause of action arising out of or related to use of the Services or these Terms of Service must be filed within one (1) year after such claim or cause of action arose or be forever barred. A printed version of these Terms of Service and of any notice given in electronic form will be admissible in judicial or administrative proceedings based upon or relating to these Terms of Service to the same extent and subject to the same conditions as other business documents and records originally generated and maintained in printed form.Assignment of Terms. You may not assign these Terms of Service without the prior written consent of Offchain Labs, but Offchain Labs may assign or transfer these Terms of Service, in whole or in part, without restriction.Relationship of Parties. Nothing in these Terms of Service shall be construed to create any agency, joint venture, partnership, or other form of joint enterprise, employment, or fiduciary relationship between you and Offchain Labs. Offchain Labs is an independent contractor to you in all respects. Neither party has the authority to contract for nor bind the other in any manner whatsoever.No Third-Party Beneficiaries. These Terms of Service are for the sole benefit of the parties hereto and their respective successors and permitted assigns and nothing herein, express or implied, is intended to or will confer upon any other person or entity any legal or equitable right, benefit, or remedy of any nature whatsoever under or by reason of these terms.Interpretation. Headings, section titles, and defined terms in these Terms of Service are for convenience only, have no legal or contractual effect, and will not be considered when interpreting the Terms. As used in these Terms of Service, (i) the words \"include\", \"includes\", and \"including\" and any variations thereof, will not be deemed to be terms of limitation, but rather will be deemed to be followed by the words \"without limitation\" regardless of any facially differentiated usage herein; (ii) the words \"such as\", \"for example\", \"e.g.\", and any derivatives of those words will mean by way of example and the items that follow these words will not be deemed an exhaustive list; (iii) the word \"or\" is used in the inclusive sense of \"and/or\" and the terms \"or,\" \"any,\" and \"either\" are not exclusive; and (iv) any reference to any agreement, terms of service, document or other terms herein means such provision or provisions, as amended from time to time.Notices. All notices made or given pursuant to these Terms of Service shall be in the English Language. Notices to Offchain Labs must be sent by physical mail to the Notice Address and will be deemed received upon actual delivery. Notices to you may be made via either email, regular mail, or through the use of blockchain technology, and shall be deemed received upon the earlier of (i) actual delivery of such notice; and (ii) five (5) calendar days. Notwithstanding the foregoing, we may also provide notices to you for Changes to these Terms of Service or other matters by using public communication channels, and such notice will be effective upon posting.Force Majeure. Offchain Labs will not be in default hereunder by reason of any failure or delay in the performance of its obligations where such failure or delay is due to civil disturbances, riot, epidemic, hostilities, war, terrorist attack, embargo, natural disaster, acts of God, flood, fire, sabotage, fluctuations or unavailability of electrical power, network access or equipment, or any other circumstances or c","tokens":15000,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258870706,"hash":"885b9b51391a4dc1da1f8267c1913ae612ab0bcd"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/4","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 4 / 11\n\n Oct 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791258882021,"hash":"d032078154eb8405d47377cbfc961038f90d2866"}
{"url":"https://portal.arbitrum.io/build","domain":"portal.arbitrum.io","title":"Build with Arbitrum","text":"ToolsBuild & MonitorStats & DocsBuild & MonitorStats & DocsBuild & MonitorBuildLaunch Your Own ProjectUse the same tech stack you used for Ethereum to launch on ArbitrumDeveloper DocsLearn how to build decentralized apps with ArbitrumArbitrum TutorialsLearn from a series of tutorials about how to build and interact with ArbitrumArbitrum StylusWrite smart contracts on Arbitrum in Rust, C, C++ and moreInfra and Tool AppsBrowse apps you can use to help you build and deploy on ArbitrumLaunch Your Own ChainLeverage a third-party Rollup as a Service (RaaS) provider to take your Arbitrum chain to mainnet.CalderaSupports AnyTrust and Rollup chainsPowering Treasure, HychainGo to website ConduitSupports AnyTrust and Rollup chainsPowering Proof of Play and GravityGo to website AltLayerSupports AnyTrust chainsPowering Cometh, Polychain Monster & AviveGo to website GelatoSupports AnyTrust chainsPowering re.al and PlaynanceGo to website AsphereSupports AnyTrust and Rollup chainsPowering Social Network and DestraGo to website ZeeveSupports AnyTrust and Rollup chainsPowering BlockFit and ZKasinoGo to website AlchemySupports AnyTrust and Rollup chainsPowering AavegotchiGo to website QuickNodeSupports AnyTrust and Rollup chainsPowering Proof of PlayGo to website GatewaySupports AnyTrust and Rollup chainsGo to website GrantsFund your projectArbitrum Foundation GrantsMonitorNetwork StatusSee MoreAll systems operationalRetryable TicketsA retryable ticket can be redeemed for up to 7 days.Check StatusExplorersDive deep into any transaction on an Arbitrum chainArbitrum One Block ExplorerArbitrum Nova Block ExplorerArbitrum Sepolia Block Explorer","tokens":412,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791258882140,"hash":"9eaedd856305e9b7510452a40f763ca3a2196167"}
{"url":"https://www.anchor-lang.com/docs/tokens/basics/create-mint","domain":"anchor-lang.com","title":"Create a Token Mint","text":"Interacting with TokensBasicsCreate a Token MintLearn how to create and initialize token mint accounts in Solana programs using Anchor. Covers creating mint accounts with generated keypairs or PDAs with code examples.What is a Mint Account?\nA mint account is an account type in Solana's Token Programs that uniquely\nrepresents a token on the network and stores global metadata about the token.\n/// Mint data.\n#[repr(C)]\n#[derive(Clone, Copy, Debug, Default, PartialEq)]\npub struct Mint {\n /// Optional authority used to mint new tokens. The mint authority may only\n /// be provided during mint creation. If no mint authority is present\n /// then the mint has a fixed supply and no further tokens may be\n /// minted.\n pub mint_authority: COption<Pubkey>,\n /// Total supply of tokens.\n pub supply: u64,\n /// Number of base 10 digits to the right of the decimal place.\n pub decimals: u8,\n /// Is `true` if this structure has been initialized\n pub is_initialized: bool,\n /// Optional authority to freeze token accounts.\n pub freeze_authority: COption<Pubkey>,\n}\nNote that both the Token\nProgram\nand Token Extension\nProgram\nhave the same base implementation for the Mint account.\nEvery token on Solana is represented by a mint account where the address of the\nmint account acts as its unique identifier on the network.\nFor example, the USDC stablecoin on Solana is identified by the mint address\nEPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. This mint address serves as\nUSDC's unique identifier across the entire Solana ecosystem. You can view\ndetails about this mint account on\nSolana Explorer.\nUsage\nUse the token_interface module from the anchor-spl crate to interact with\nboth the Token Program and Token Extension Program. This module provides types\nfor working with both token programs, allowing you to write code that's\ncompatible with either program.\nsnippetuse anchor_spl::token_interface::{Mint, TokenInterface};\n\n// --snip--\n\n#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = signer.key(),\n mint::freeze_authority = signer.key(),\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\nAccount Types\nThe\nInterfaceAccount\ntype is a wrapper that accepts accounts from either the Token Program and Token\nExtension Program.\nThe Mint type represents the base Mint data structure shared by both token\nprograms. When an account of this type is passed in, Anchor will automatically\ndeserialize the account data into the mint struct, regardless of which token\nprogram created it.\nAccount Typepub mint: InterfaceAccount<'info, Mint>,\nAccount Constraints\nThe following account constraints are used in combination to create and\ninitialize a new mint account:\nConstraintDescriptioninitCreates a new account by making a cross program invocation (CPI) to the System Program. This allocates the required space for the mint account and transfers ownership to the appropriate token program.payerSpecifies which account will pay the rent (SOL deposit) required to create the new account.mint::decimalsSets the number of decimal places for the token. For example, setting this to 6 means 1 token = 1,000,000 base units.mint::authoritySets the mint authority - the account that has permission to mint new tokens. (Required)mint::freeze_authoritySets the freeze authority - the account that has permission to freeze token accounts. (Optional) Freezing a token account prevents the token program from processing instructions that include the frozen token account (ex. transfer, burn, etc.)\nAccount Constraints#[account(\n init,\n payer = <payer>,\n mint::decimals = <decimals>,\n mint::authority = <authority>,\n mint::freeze_authority = <freeze_authority>,\n)]\npub mint: InterfaceAccount<'info, Mint>,\nAlternatively, you can add the seeds and bump constraints to create a mint\naccount where the address of the account is a Program Derived Address (PDA). The\nbenefit of using a PDA is that the mint address can be derived from the same\nseeds at any time.\nAccount Constraints#[account(\n init,\n payer = <payer>,\n mint::decimals = <decimals>,\n mint::authority = <authority>,\n mint::freeze_authority = <freeze_authority>,\n seeds = [<seeds>],\n bump\n)]\npub mint: InterfaceAccount<'info, Mint>,\nNote that you can use the same PDA as both the mint::authority and the mint\naccount address. Using a PDA as the mint::authority enables your program to\n\"sign\" CPI instructions to mint new units of the token. This pattern allows\nfor a single deterministic address for both purposes.\nExamples\nThe following examples demonstrate how to create a mint account in an Anchor\nprogram using two different approaches:\n\nUsing a generated Keypair - This is an approach where you generate a new\nkeypair to use as the mint address. This is useful when you don't need\ndeterministic mint addresses.\n\nUsing a Program Derived Address (PDA) - This approach creates the mint where\nthe account address is a PDA derived from seeds. This allows for\ndeterministic mint addresses and is useful when you need to find the mint\naddress at a later time.\n\nBoth approaches are can be done entirely using account constraints.\nCreate Mint using Keypair\nCreate a new mint account in using a generated Keypair.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::token_interface::{Mint, TokenInterface};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn create_mint(ctx: Context<CreateMint>) -> Result<()> {\n msg!(\"Created Mint Account: {:?}\", ctx.accounts.mint.key());\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = signer.key(),\n mint::freeze_authority = signer.key(),\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\nCreate Mint using PDA\nCreate a new mint account using a Program Derived Address (PDA) as the address\nof the mint account.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::token_interface::{Mint, TokenInterface};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn create_mint(ctx: Context<CreateMint>) -> Result<()> {\n msg!(\"Created Mint Account: {:?}\", ctx.accounts.mint.key());\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint.key(),\n mint::freeze_authority = mint.key(),\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}PreviousSPL Token BasicsNextCreate a Token AccountOn this pageWhat is a Mint Account?UsageAccount TypesAccount ConstraintsExamplesCreate Mint using KeypairCreate Mint using PDAEdit on GitHub","tokens":1780,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258891503,"hash":"fa43c14ae371372aaa227987a115299e967f407c"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/6","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 6 / 11\n\n Oct 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791258892732,"hash":"99e6eff17fdf6c433231722705245b6614422daf"}
{"url":"https://aave.com/docs/aave-v3/concepts/incentives","domain":"aave.com","title":"Incentives | Aave Protocol Documentation","text":"Incentives#\n\nIncentives within the Aave Protocol encourage active participation from suppliers and borrowers, enhancing liquidity and the overall efficiency of the protocol. It should be noted that there is no one source of various incentive initiatives, but they can originate from multiple sources, including the Aave DAO treasury and external entities interested in promoting liquidity for specific reserves.\nThe Aave DAO, governed by AAVE token holders through proposals and voting, can allocate funds from the DAO treasury to incentivise certain activities within the protocol. Incentive programs funded by the DAO are proposed, discussed, and approved through the Aave Governance process, ensuring community involvement and transparency.\nLiquidity Pool Incentives#\nIncentives can also be applied to the supply or borrow side of Aave liquidity pools, promoting activity of the incentivised reserve. By offering rewards to suppliers and borrowers of certain assets on Aave, the visibility and adoption of tokens can be boosted. Such external incentives require governance approval.\nApproved incentives are distributed continuously over time proportional to the amount of liquidity a user supplies or borrows. Users can claim these rewards via the protocol’s incentive controller, which manages the allocation and distribution of incentives. This system adds value for those actively participating in the protocol while aligning user interests with the health and stability of the Aave ecosystem.\nSafety Module#\nAAVE holders can stake their tokens in the Safety Module, a reserve designed to secure the protocol against unexpected shortfalls. In return for staking their AAVE tokens and taking on the associated risk, participants earn rewards, typically in the form of additional AAVE tokens or other incentives approved by governance. These rewards not only compensate stakers but also enhance the protocol's security by ensuring sufficient reserves are available to cover potential deficits.\nMerit Program#\nMerit is an Aave-alignment user reward system, designed as a merkle-tree-based periodic airdrop to incentivise Aave-aligned behaviours and enhance the competitiveness of the Aave protocol. More information and interface to access merit distribution can be found here.PreviousReserveNextGetting Started","tokens":579,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258895093,"hash":"c2c1e88c933eb5306736af54423b5cebf998011f"}
{"url":"https://www.anchor-lang.com/docs/tokens/basics/mint-tokens","domain":"anchor-lang.com","title":"Mint Tokens","text":"Interacting with TokensBasicsMint TokensLearn how to mint tokens in Solana programs using Anchor. Covers creating new tokens via cross program invocations (CPI) to the Token Program with code examples.How to Mint Tokens\nMinting tokens refers to the process of creating new units of a token by\ninvoking the\nmint_to\ninstruction on a token program. Only the address specified as the mint authority\non the mint account can mint new tokens. The instruction also requires the\nexistence of a token account for the mint as the destination of the minted\ntokens.\nThe Token\nProgram\nand Token Extension\nProgram\nshare similar implementations to achieve the same functionality.\nExamples\nTo mint tokens through an Anchor program, you need to make a cross program\ninvocation (CPI) to the mint_to instruction on either the Token Program or\nToken Extension Program.\nThis means you are invoking the mint_to instruction on the Token Program or\nToken Extension Program from an instruction in your program. Your program acts\nas an intermediary, passing along the required accounts, instruction data, and\nsignatures to the token program.\nMint Tokens via CPI\nUse the token_interface::mint_to function make a CPI to either the Token\nProgram or Token Extension Program. This function requires:\n\nThe MintTo struct which specifies the required accounts:\n\nmint - The mint account to create new units of tokens for\nto - The destination token account to receive the minted tokens\nauthority - The mint authority with permission to mint tokens\n\nThe amount of tokens to mint, in base units of the token adjusted by\ndecimals. (e.g. if the mint has 2 decimals, amount of 100 = 1 token)\n\nThe mint authority passed to the mint_to instruction must match the\nmint_authority stored on the mint account. Additionally, the mint authority\nmust be a signer on the transaction. For example:\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::{\n token_interface::{self, Mint, MintTo, TokenAccount, TokenInterface},\n};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> {\n let cpi_accounts = MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.token_account.to_account_info(),\n authority: ctx.accounts.signer.to_account_info(),\n };\n let cpi_program_id = ctx.accounts.token_program.key();\n let cpi_context = CpiContext::new(cpi_program_id, cpi_accounts);\n token_interface::mint_to(cpi_context, amount)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct MintTokens<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(mut)]\n pub mint: InterfaceAccount<'info, Mint>,\n #[account(mut)]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub token_program: Interface<'info, TokenInterface>,\n}\nAt minimum, the following accounts are required:\nsnippet#[derive(Accounts)]\npub struct MintTokens<'info> {\n // The mint authority\n #[account(mut)]\n pub signer: Signer<'info>,\n // The mint account\n #[account(mut)]\n pub mint: InterfaceAccount<'info, Mint>,\n // The destination token account\n #[account(mut)]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n // The token program\n pub token_program: Interface<'info, TokenInterface>,\n}\nWithin the instruction logic, use the:\n\nMintTo struct to specify the required accounts\ntoken_interface::mint_to function to make the CPI\n\nsnippetpub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> {\n // Create the MintTo struct with the accounts required for the CPI\n let cpi_accounts = MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.token_account.to_account_info(),\n authority: ctx.accounts.signer.to_account_info(),\n };\n\n // The program being invoked in the CPI\n let cpi_program_id = ctx.accounts.token_program.key();\n\n // Combine the accounts and program into a \"CpiContext\"\n let cpi_context = CpiContext::new(cpi_program_id, cpi_accounts);\n\n // Make CPI to mint_to instruction on the token program\n token_interface::mint_to(cpi_context, amount)?;\n Ok(())\n}\nMint Tokens with PDA mint authority via CPI\nYou can create a mint account with a Program Derived Address (PDA) as the mint\nauthority. This allows your program to programmatically mint tokens by \"signing\"\nwith the PDA's seeds in the Cross Program Invocation (CPI). This pattern is\nuseful when you want the program itself, rather than an external wallet, to\ncontrol token minting.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::{\n associated_token::AssociatedToken,\n token_interface::{self, Mint, MintTo, TokenAccount, TokenInterface},\n};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn create_mint(ctx: Context<CreateMint>) -> Result<()> {\n msg!(\"Created Mint Account: {:?}\", ctx.accounts.mint.key());\n Ok(())\n }\n\n pub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> {\n let signer_seeds: &[&[&[u8]]] = &[&[b\"mint\", &[ctx.bumps.mint]]];\n\n let cpi_accounts = MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.token_account.to_account_info(),\n authority: ctx.accounts.mint.to_account_info(),\n };\n let cpi_program_id = ctx.accounts.token_program.key();\n let cpi_context = CpiContext::new(cpi_program_id, cpi_accounts).with_signer(signer_seeds);\n token_interface::mint_to(cpi_context, amount)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint,\n mint::freeze_authority = mint,\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct MintTokens<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init_if_needed,\n payer = signer,\n associated_token::mint = mint,\n associated_token::authority = signer,\n associated_token::token_program = token_program,\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n #[account(\n mut,\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n pub system_program: Program<'info, System>,\n}\nIn this example, mint authority is set to a Program Derived Address (PDA). The\nPDA is derived using the seed b\"mint\". This means the program itself controls\nminting through this PDA.\nsnippet#[derive(Accounts)]\npub struct CreateMint<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint,\n mint::freeze_authority = mint,\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\nTo mint tokens, the program must \"sign\" with the PDA by including the seeds and\nbump in the CPI context. This is done by passing the seeds and bump to the\nwith_signer method when creating the CPI context.\nsnippetpub fn mint_tokens(ctx: Context<MintTokens>, amount: u64) -> Result<()> {\n let signer_seeds: &[&[&[u8]]] = &[&[b\"mint\", &[ctx.bumps.mint]]];\n\n let cpi_accounts = MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.token_account.to_account_info(),\n authority: ctx.accounts.mint.to_account_info(),\n };\n let cpi_program = ctx.accounts.token_program.key();\n let cpi_context = CpiContext::new(cpi_program, cpi_accounts).with_signer(signer_seeds);\n token_interface::mint_to(cpi_context, amount)?;\n Ok(())\n}\nNote in this example the same PDA is used as both the address of the mint\naccount and the mint authority.PreviousCreate a Token AccountNextTransfer TokensOn this pageHow to Mint TokensExamplesMint Tokens via CPIMint Tokens with PDA mint authority via CPIEdit on GitHub","tokens":1980,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258902381,"hash":"ab0ef8be85c5b53f0e24fcc9e8118d81bfe6d75a"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/11","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 11 / 11\n\n Jan 2024\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791258906584,"hash":"4d90214dcedf1ac12482561af953c8673f32d225"}
{"url":"https://www.anchor-lang.com/docs/tokens/basics/transfer-tokens","domain":"anchor-lang.com","title":"Transfer Tokens","text":"Interacting with TokensBasicsTransfer TokensLearn how to transfer tokens between token accounts through cross program invocations (CPIs) in Anchor.How to Transfer Tokens\nTransferring tokens involves moving tokens from one token account to another\ntoken account that share the same mint. This is done by invoking the\ntransfer_checked\ninstruction on a token program. Only the address specified as the owner\n(authority) of the source token account can transfer tokens out of the account.\nThe Token\nProgram\nand Token Extension\nProgram\nshare similar implementations to achieve the same functionality.\nExamples\nTo transfer tokens through an Anchor program, you need to make a cross program\ninvocation (CPI) to the transfer_checked instruction on either the Token\nProgram or Token Extension Program.\nThis means you are invoking the transfer_checked instruction on the Token\nProgram or Token Extension Program from an instruction in your program. Your\nprogram acts as an intermediary, passing along the required accounts,\ninstruction data, and signatures to the token program.\nTransfer Tokens via CPI\nUse the token_interface::transfer_checked function make a CPI to either the\nToken Program or Token Extension Program. This function requires:\n\nThe TransferChecked struct which specifies the required accounts:\n\nmint - The mint account specifying the type of token to transfer\nfrom - The source token account to transfer tokens from\nto - The destination token account to receive the transferred tokens\nauthority - The owner of the source token account\n\nThe amount of tokens to transfer, in base units of the token adjusted by\ndecimals. (e.g. if the mint has 2 decimals, amount of 100 = 1 token)\n\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::token_interface::{self, TokenAccount, TokenInterface, TransferChecked};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn transfer_tokens(ctx: Context<TransferTokens>, amount: u64) -> Result<()> {\n let decimals = ctx.accounts.mint.decimals;\n\n let cpi_accounts = TransferChecked {\n mint: ctx.accounts.mint.to_account_info(),\n from: ctx.accounts.sender_token_account.to_account_info(),\n to: ctx.accounts.recipient_token_account.to_account_info(),\n authority: ctx.accounts.signer.to_account_info(),\n };\n let cpi_program = ctx.accounts.token_program.key();\n let cpi_context = CpiContext::new(cpi_program, cpi_accounts);\n token_interface::transfer_checked(cpi_context, amount, decimals)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct TransferTokens<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(mut)]\n pub mint: InterfaceAccount<'info, Mint>,\n #[account(mut)]\n pub sender_token_account: InterfaceAccount<'info, TokenAccount>,\n #[account(mut)]\n pub recipient_token_account: InterfaceAccount<'info, TokenAccount>,\n pub token_program: Interface<'info, TokenInterface>,\n}\nAt minimum, the following accounts are required:\nsnippet#[derive(Accounts)]\npub struct TransferTokens<'info> {\n // The source token account owner\n #[account(mut)]\n pub signer: Signer<'info>,\n // The mint account specifying the type of token\n #[account(mut)]\n pub mint: InterfaceAccount<'info, Mint>,\n // The source token account to transfer tokens from\n #[account(mut)]\n pub sender_token_account: InterfaceAccount<'info, TokenAccount>,\n // The destination token account to receive tokens\n #[account(mut)]\n pub recipient_token_account: InterfaceAccount<'info, TokenAccount>,\n // The token program that will process the transfer\n pub token_program: Interface<'info, TokenInterface>,\n}\nWithin the instruction logic, use the:\n\nTransferChecked struct to specify the required accounts\ntoken_interface::transfer_checked function to make the CPI\n\nsnippetpub fn transfer_tokens(ctx: Context<TransferTokens>, amount: u64) -> Result<()> {\n // Get the number of decimals for this mint\n let decimals = ctx.accounts.mint.decimals;\n\n // Create the TransferChecked struct with required accounts\n let cpi_accounts = TransferChecked {\n mint: ctx.accounts.mint.to_account_info(),\n from: ctx.accounts.sender_token_account.to_account_info(),\n to: ctx.accounts.recipient_token_account.to_account_info(),\n authority: ctx.accounts.signer.to_account_info(),\n };\n\n // The program being invoked in the CPI\n let cpi_program = ctx.accounts.token_program.key();\n\n // Combine the accounts and program into a \"CpiContext\"\n let cpi_context = CpiContext::new(cpi_program, cpi_accounts);\n\n // Make CPI to transfer_checked instruction on token program\n token_interface::transfer_checked(cpi_context, amount, decimals)?;\n Ok(())\n}\nTransfer Tokens with PDA token owner via CPI\nYou can create a token account with a PDA as the owner. This allows your program\nto transfer tokens from a program controlled token account by \"signing\" with the\nPDA's seeds in the Cross Program Invocation (CPI). This pattern is useful when\nyou want the program itself to control token transfers based on conditions\ndefined within the program.\nlib.rsuse anchor_lang::prelude::*;\nuse anchor_spl::{\n associated_token::AssociatedToken,\n token_interface::{self, Mint, MintTo, TokenAccount, TokenInterface, TransferChecked},\n};\n\ndeclare_id!(\"3pX5NKLru1UBDVckynWQxsgnJeUN3N1viy36Gk9TSn8d\");\n\n#[program]\npub mod token_example {\n use super::*;\n\n pub fn create_and_mint_tokens(ctx: Context<CreateAndMintTokens>, amount: u64) -> Result<()> {\n let signer_seeds: &[&[&[u8]]] = &[&[b\"mint\", &[ctx.bumps.mint]]];\n\n let cpi_accounts = MintTo {\n mint: ctx.accounts.mint.to_account_info(),\n to: ctx.accounts.token_account.to_account_info(),\n authority: ctx.accounts.mint.to_account_info(),\n };\n let cpi_program = ctx.accounts.token_program.key();\n let cpi_context = CpiContext::new(cpi_program, cpi_accounts).with_signer(signer_seeds);\n token_interface::mint_to(cpi_context, amount)?;\n Ok(())\n }\n\n pub fn transfer_tokens(ctx: Context<TransferTokens>) -> Result<()> {\n let signer_seeds: &[&[&[u8]]] = &[&[b\"token\", &[ctx.bumps.sender_token_account]]];\n\n let amount = ctx.accounts.sender_token_account.amount;\n let decimals = ctx.accounts.mint.decimals;\n\n let cpi_accounts = TransferChecked {\n mint: ctx.accounts.mint.to_account_info(),\n from: ctx.accounts.sender_token_account.to_account_info(),\n to: ctx.accounts.recipient_token_account.to_account_info(),\n authority: ctx.accounts.sender_token_account.to_account_info(),\n };\n let cpi_program = ctx.accounts.token_program.key();\n let cpi_context = CpiContext::new(cpi_program, cpi_accounts).with_signer(signer_seeds);\n token_interface::transfer_checked(cpi_context, amount, decimals)?;\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct CreateAndMintTokens<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint,\n mint::freeze_authority = mint,\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n #[account(\n init,\n payer = signer,\n token::mint = mint,\n token::authority = token_account,\n seeds = [b\"token\"],\n bump\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\n\n#[derive(Accounts)]\npub struct TransferTokens<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n mut,\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n #[account(\n mut,\n token::mint = mint,\n token::authority = sender_token_account,\n seeds = [b\"token\"],\n bump\n )]\n pub sender_token_account: InterfaceAccount<'info, TokenAccount>,\n #[account(\n init_if_needed,\n payer = signer,\n associated_token::mint = mint,\n associated_token::authority = signer,\n associated_token::token_program = token_program,\n )]\n pub recipient_token_account: InterfaceAccount<'info, TokenAccount>,\n pub token_program: Interface<'info, TokenInterface>,\n pub associated_token_program: Program<'info, AssociatedToken>,\n pub system_program: Program<'info, System>,\n}\nIn this example, the source token account owner is set to a Program Derived\nAddress (PDA). The PDA is derived using the seed b\"token\". This means the\nprogram itself controls token transfers out of the token account through this\nPDA.\nsnippet#[derive(Accounts)]\npub struct CreateAndMintTokens<'info> {\n #[account(mut)]\n pub signer: Signer<'info>,\n #[account(\n init,\n payer = signer,\n mint::decimals = 6,\n mint::authority = mint,\n mint::freeze_authority = mint,\n seeds = [b\"mint\"],\n bump\n )]\n pub mint: InterfaceAccount<'info, Mint>,\n #[account(\n init,\n payer = signer,\n token::mint = mint,\n token::authority = token_account,\n seeds = [b\"token\"],\n bump\n )]\n pub token_account: InterfaceAccount<'info, TokenAccount>,\n pub token_program: Interface<'info, TokenInterface>,\n pub system_program: Program<'info, System>,\n}\nTo transfer tokens, the program must \"sign\" with the PDA by including the seeds\nand bump in the CPI context. This is done by passing the seeds and bump to the\nwith_signer method when creating the CPI context.\nsnippetpub fn transfer_tokens(ctx: Context<TransferTokens>) -> Result<()> {\n let signer_seeds: &[&[&[u8]]] = &[&[b\"token\", &[ctx.bumps.sender_token_account]]];\n\n let amount = ctx.accounts.sender_token_account.amount;\n let decimals = ctx.accounts.mint.decimals;\n\n let cpi_accounts = TransferChecked {\n mint: ctx.accounts.mint.to_account_info(),\n from: ctx.accounts.sender_token_account.to_account_info(),\n to: ctx.accounts.recipient_token_account.to_account_info(),\n authority: ctx.accounts.sender_token_account.to_account_info(),\n };\n let cpi_program = ctx.accounts.token_program.to_account_info();\n let cpi_context = CpiContext::new(cpi_program, cpi_accounts).with_signer(signer_seeds);\n token_interface::transfer_checked(cpi_context, amount, decimals)?;\n Ok(())\n}\nNote in this example the same PDA is used as both the address of the source\ntoken account and the source token account owner.PreviousMint TokensNextExtensionsOn this pageHow to Transfer TokensExamplesTransfer Tokens via CPITransfer Tokens with PDA token owner via CPIEdit on GitHub","tokens":2495,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791258912586,"hash":"f2381f3959e386e8bb6e9ed084441a2643768a82"}
{"url":"https://aave.com/docs/aave-v3/aptos","domain":"aave.com","title":"Aptos | Aave Protocol Documentation","text":"Aave v3 on Aptos#\nThis is the official Aptos version of the Aave v3 Protocol. Access the Aave Protocol on Aptos.\nThe Aptos Move codebase represents a faithful implementation of the Aave v3.3 protocol on the Aptos blockchain using the Move language. While maintaining the core financial logic and security properties of the original Solidity implementation, this port leverages Aptos's unique architectural features to enhance performance, security, and composability.\nHigh-Level Summary:\nModular Design: Organized into specialized modules with friend functions enforcing controlled inter-module access (no inheritance).Resource-Oriented Programming: Assets are treated as linear resources to prevent accidental copying or loss.Native Token Support: Integrates Aptos’s native fungible asset standard.Enhanced Security: Static dispatch and explicit access control help mitigate reentrancy and circular dependency vulnerabilities.Safety & Verification: Strong type enforcement and formal verification (Move Prover) support robust protocol correctness.\nCore Features#\nFull Liquidity Protocol Implementation: Complete supply and borrow functionality, including variable interest rates, liquidations, collateral management, and risk parameters.E-Mode: Efficiency mode for correlated assets that allows higher borrowing power.Isolation Mode: Risk containment for new assets with customizable debt ceilings.Fungible Asset Integration: Native support for Aptos's fungible asset standard, Aptos's version of ERC-20.Price Oracles: Integration with external price feeds for accurate asset valuations.Flexible Interest Rate Strategy: Adaptable interest rate models based on utilization.\nAptos Move Implementation Approach#\nThe implementation follows the logic of the Aave v3.3 Solidity codebase on a 1:1 basis, while adapting to Move’s unique paradigms:\nObject Model vs. Contract ModelResource-Oriented Design: Instead of Solidity contracts, the implementation uses Move's resource model to store protocol state.Object-Centric Architecture: Leverages Aptos's object model for reserve data and token management, providing stronger ownership guarantees.Resource Groups: Utilizes resource groups to organize related data structures efficiently.\nKey Architectural Differences#\nModule Structure:\nFunctionality is divided into specialized modules (pool_logic, generic_logic, liquidation_logic, etc.) rather than monolithic contracts.friend functions provide controlled access between modules for specific functions, enabling a permission-based composition model.Move has no inheritance, forcing explicit composition patterns instead of the hierarchical inheritance common in Solidity.\nToken Implementation:\nUses Aptos's Fungible Asset standard instead of ERC-20.Implements a token_base module that abstracts common token functionality.Provides a coin_migrator to bridge between Aptos Coin and Fungible Asset standards.\nState Management:\nLeverages Move's ability to pass references to resources, enabling more efficient state updates.Uses SmartTables for mapping-like functionality with better gas efficiency.\nType Safety:\nTakes advantage of Move's strong type system to prevent runtime errors common in Solidity.Uses generics where appropriate to enhance code reusability.\nObject References:\nReserve data is stored as objects with explicit access controls, improving security.Capabilities are used to control privileged operations instead of address-based access control.\n\nMove Language Security Features#\nResource-Oriented Programming:\nResources in Move cannot be copied or implicitly discarded, only moved between storage locations.This ensures assets like tokens maintain conservation properties by design.\nNo Reentrancy Vulnerabilities:\nMove's execution model prevents circular dependencies and function callbacks.Static dispatch instead of dynamic dispatch eliminates reentrancy attacks common in Solidity.\nLinear Type System:\nResources are linear types that must be consumed exactly once, preventing double-spending.Compiler enforces resource handling rules, making many runtime checks unnecessary.\nFormal Verification:\nBuilt-in Move Prover enables mathematical verification of code correctness.Specifications can be written alongside code to prove safety properties.\nExplicit Access Control:\nCapabilities pattern enforces permission-based access to sensitive operations.Friend functions provide controlled access between modules without full inheritance.\nPredictable Gas Model:\nMore deterministic execution costs due to static dispatch and simpler VM design.Reduced gas surprises compared to Solidity's dynamic dispatch model.\nGlobal Storage Structure:\nAccount-centric storage model with clear ownership semantics.Resources stored directly in accounts rather than in contract storage.\nAbility-Based Type System:\nTypes have explicit abilities (copy, drop, store, key) that control how values can be used.Prevents common errors like unintended copying of sensitive data.\n\nNotable Implementation Details#\nPrecise Math: Implements ray math (27 decimal places) and wad math (18 decimal places) for high-precision financial calculations.Interest Rate Accrual: Uses the same compound interest model with liquidity and borrow indices for efficient interest tracking.Configuration Data: Uses dedicated resource structures for storing protocol configuration.Event Emission: Maps Solidity events to Move events for protocol monitoring and analytics.\nThe protocol maintains the same economic and security properties as the original Aave v3.3 protocol while embracing the strengths of the Aptos blockchain and Move language, providing a robust and efficient DeFi liquidity protocol for the Aptos ecosystem.\nNext Steps#\nSmart Contracts — the module-by-module reference for the Move implementation.Integrations — the APIs and SDKs for interacting with Aave on Aptos.PreviousAdvanced FeaturesNextSmart Contracts","tokens":1471,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258916640,"hash":"a8a4ee78c95feddd89c0b573d2941bcedd4ddf73"}
{"url":"https://aave.com/docs/aave-v3/markets/data","domain":"aave.com","title":"Aave Market Data | Aave Protocol Documentation","text":"Markets Data#\nLearn how to discover available markets and access detailed market information in Aave.\nMarket Structure#\nAave market data provides comprehensive information about lending pools across different chains, including:\nMarket identification (name, chain, address)The reserves in the marketEfficiency mode (eMode) categories and configurationsMarket metrics (total size, available liquidity)\nWhen you provide a user account address, the data also includes user-specific information such as net worth, health factor, and current positions.\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core Market type and its related types:interface Market { name: string; chain: Chain; address: EvmAddress; icon: string; totalMarketSize: BigDecimal; totalAvailableLiquidity: BigDecimal; eModeCategories: EmodeMarketCategory[]; userState?: MarketUserState; borrowReserves: Reserve[]; supplyReserves: Reserve[];}\nReserve Structure#\nEach reserve within an Aave market provides comprehensive lending and borrowing data for a specific asset, including:\nToken information (underlying, aToken, vToken addresses and metadata)Supply information (APY, liquidity, caps, collateral configuration)Borrow information (APY, available liquidity, utilization rates, caps)Reserve incentives (Merit programs, Aave governance rewards)Market mechanics (flash loans, permits, pause/freeze states)Efficiency mode (eMode) configurations for the assetIsolation mode settings (if applicable)User-specific state (balances, borrowable amounts, collateral usage)\nWhen you provide a user account address, the reserve data also includes user-specific information such as current balances, borrowing capacity, and collateral status.\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core Reserve type and its related types:interface Reserve { market: MarketInfo; underlyingToken: Currency; aToken: Currency; vToken: Currency; acceptsNative?: NativeCurrency; size: TokenAmount; usdExchangeRate: BigDecimal; usdOracleAddress: EvmAddress; isFrozen: boolean; isPaused: boolean; flashLoanEnabled: boolean; permitSupported: boolean; supplyInfo: ReserveSupplyInfo; borrowInfo?: ReserveBorrowInfo; isolationModeConfig?: ReserveIsolationModeConfig; eModeInfo: EmodeReserveInfo[]; incentives: ReserveIncentive[]; userState?: ReserveUserState;}See the Incentive Programs page for more information on\nincentives.\nListing Available Markets#\nDiscover all available Aave markets across supported blockchain networks.\nReactTypeScriptGraphQLUse the useAaveMarkets hook to fetch a list of Aave markets.const { data, loading, error } = useAaveMarkets({ chainIds: ChainId[], user: EvmAddress | undefined, borrowsOrderBy: MarketReservesRequestOrderBy | undefined, suppliesOrderBy: MarketReservesRequestOrderBy | undefined,});Specify one or more chains to retrieve markets for.import { useAaveMarkets, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useAaveMarkets({ chainIds: [chainId(1)],});\nif (loading) { return <p>Loading…</p>;}\nif (error) { return <p>{error.message}</p>;}\n// data: Market[]Use a user address to include account-level data for each market and reserve.import { useAaveMarket, evmAddress, chainId } from \"@aave/react\";\nconst { data, loading, error } = useAaveMarket({ chainId: chainId(1), user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"),});\nSingle Market#\nRetrieve detailed information about a specific market including reserves and user state.\nReactTypeScriptGraphQLUse the useAaveMarket hook to fetch detailed information about a specific market.const { data, loading, error } = useAaveMarket({ address: EvmAddress, chainId: ChainId, user: EvmAddress | undefined, borrowsOrderBy: MarketReservesRequestOrderBy | undefined, suppliesOrderBy: MarketReservesRequestOrderBy | undefined,});Fetch a specific market by address and chain.import { useAaveMarket, evmAddress, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useAaveMarket({ address: evmAddress(\"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\"), chainId: chainId(1),});\nif (loading) { return <p>Loading market...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\nif (!data) { return <p>Market not found</p>;}\n// data: MarketUse a user address to include account-level data for the market and its reserves.import { useAaveMarket, evmAddress, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useAaveMarket({ address: evmAddress(\"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\"), chainId: chainId(1), user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"),});\nAPY History#\nRetrieve historical APY data for reserves to analyze interest rate trends over time.\nReactTypeScriptGraphQLUse the useBorrowAPYHistory and useSupplyAPYHistory hooks to fetch historical APY data for specific reserves.const { data, loading, error } = useBorrowAPYHistory({ chainId: ChainId, underlyingToken: EvmAddress, market: EvmAddress, window: TimeWindow,});\nconst { data, loading, error } = useSupplyAPYHistory({ chainId: ChainId, underlyingToken: EvmAddress, market: EvmAddress, window: TimeWindow,});Fetch borrow/supply APY history for a specific reserve over the last week.import { useBorrowAPYHistory, evmAddress, chainId, TimeWindow,} from \"@aave/react\";\n// …\nconst { data, loading, error } = useBorrowAPYHistory({ chainId: chainId(1), underlyingToken: evmAddress(\"0xa0b86a33e6441c8c5f0bb9b7e5e1f8bbf5b78b5c\"), // USDC market: evmAddress(\"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\"), window: TimeWindow.LastWeek,});\nif (loading) { return <p>Loading APY history...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\n// data: APYSample[]Available time windows include:TimeWindow.LastDayTimeWindow.LastWeekTimeWindow.LastMonthTimeWindow.LastSixMonthsTimeWindow.LastYearPreviousAave MarketsNextUser Positions","tokens":1457,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258926661,"hash":"090b9eda038cfcb18bff404d852b05524ee83b03"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/2","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 2 / 11\n\n Oct 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791258930727,"hash":"fa4269bb07e108f55bbac93667ab7889d78d4ef7"}
{"url":"https://aave.com/docs/aave-v3/markets/operations","domain":"aave.com","title":"Market Operations | Aave Protocol Documentation","text":"Market Operations#\nExecute the fundamental lending and borrowing operations on Aave markets. This section covers supply, borrow, repay, and withdraw functionality.\nPermit Overview#\nSome Aave operations support permit functionality using EIP-2612 signatures to authorize ERC-20 token transfers within the same transaction.\nBenefits of Permit#\nSingle Transaction: Execute operations without separate approval transactionsExact Amounts: Sign permissions for specific amounts instead of infinite approvalsTime Limited: Permits have deadlines for enhanced security\nPermit is available for ERC-20 tokens that implement\nEIP-2612.\nSupply Assets#\nBy supplying assets to an Aave market, users earn interest on their deposits according to the reserve's supply APY rate.\nWhen supplying assets to an Aave market, you can use the following methods:\nMethodDescriptionTypical ScenarioDirect SupplySupply ERC-20 or native tokens directly from the sender’s wallet. aTokens are sent to the sender’s address.User deposits assets into their own wallet.On Behalf of AnotherSupply from the sender’s wallet, but send aTokens to another address.User deposits assets from one wallet and borrow position is owned by another wallet.With PermitUse a permit signature to skip ERC-20 approval and supply in a single transaction.User signs a permit and sends a single transaction. No ERC-20 allowance left behind.With PermitOn Behalf of AnotherSame as permit supply, but aTokens are sent to another address.No ERC-20 allowance needed and borrow position is owned by another wallet.\nTo supply assets to an Aave market, follow these steps.\n1Identify the Reserve#First, determine which reserve you want to supply assets to.Let's say we choose the WETH supply reserve within one of the Ethereum markets.const reserve: Reserve = { __typename: \"Reserve\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, underlyingToken: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, acceptsNative: { __typename: \"NativeCurrency\", symbol: \"ETH\", name: \"Ethereum\", // … }, isFrozen: false, isPaused: false, permitSupported: true, userState: { __typename: \"ReserveUserState\", suppliable: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1245.67\", raw: \"1245670000000000000000\", decimals: 18, // … }, // … }, }, // …};To supply to the reserve, you need to verify these conditions:Reserve.isFrozen is false - the reserve is not frozenReserve.isPaused is false - the reserve is not pausedReserve.userState.suppliable.amount.value is greater than 0 - the amount the user can supply to the reserve given their unique circumstancesMake sure you include a user address when fetching market and reserve\ndata—otherwise Reserve.userState will be empty.The Reserve.permitSupported flag indicates whether the underlying token supports EIP-2612 permits.Additionally, if Reserve.acceptsNative is not null, users can choose to supply the asset as the chain's native token and it will be automatically wrapped before being sent to the reserve. This is typical for reserves of the wrapped version of the chain's native token (e.g., WETH on Ethereum).2Prepare the Execution Plan#Next, if all of these conditions are met, we can proceed with creating the execution plan for the supply operation.ReactTypeScriptGraphQLUse the useSupply hook to prepare supply transactions, optionally on behalf of another address.import { useWalletClient } from \"wagmi\";import { useSupply, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [supply, supplying] = useSupply();\nconst execute = async () => { const result = await supply({ market: reserve.market.address, amount: { erc20: { currency: reserve.underlyingToken.address, value: bigDecimal(42), // 42 WETH }, }, sender: evmAddress(walletClient!.account.address), chainId: reserve.market.chain.chainId, });\n // …};If Reserve.permitSupported is true and you supply ERC-20 tokens, you can use the useSupply and useERC20Permit hooks to sign permits and prepare supply transactions. Use the useERC20Permit implementation for the wallet library of choice.import { useSupply, bigDecimal, evmAddress } from \"@aave/react\";import { useERC20Permit } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [signPermit, signing] = useERC20Permit(walletClient);const [supply, supplying] = useSupply();\nconst execute = async () => { const amount = bigDecimal(42); // 42 WETH\n const permit = await signPermit({ amount, chainId: reserve.market.chain.chainId, currency: reserve.underlyingToken.address, owner: evmAddress(walletClient!.account.address), spender: reserve.market.address, }).andThen((signature) => supply({ market: reserve.market.address, amount: { erc20: { currency: reserve.underlyingToken.address, value: amount, // 42 WETH permitSig: signature, }, }, sender: evmAddress(walletClient!.account.address), chainId: reserve.market.chain.chainId, }) );\n // …};3Process the Execution Plan#Finally, you need to handle the execution plan, and the process is the same whether or not you used a permit in the previous step.If you provided a permit signature, the execution plan will run as a single\ntransaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useSupply } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [supply, supplying] = useSupply();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = supplying.loading || sending.loading;const error = supplying.error || sending.error;\n// …\nconst execute = async () => { const result = await supply({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Supply failed:\", result.error); } else { console.log(\"Supply successful with hash:\", result.value); }};\nCollateral Management#\nTo manage which supplied assets are used as collateral for borrowing, follow these steps.\n1Identify the User Position#First, determine which user supply position you want to enable or disable as collateral.Let's say we identified this MarketUserReserveSupplyPosition object.const position: MarketUserReserveSupplyPosition = { __typename: \"MarketUserReserveSupplyPosition\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, currency: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, balance: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"5.0\", raw: \"5000000000000000000\", decimals: 18, // … }, // … }, isCollateral: false, // Currently not used as collateral canBeCollateral: true, // Can be enabled as collateral // …};To enable a position as collateral, you need to verify these conditions:position.canBeCollateral is true - the asset can be used as collateralposition.isCollateral is false - the asset is not currently used as collateralTo disable a position as collateral, you only need to check if position.isCollateral is true.A reserve may be disabled from being used as collateral, pending an Aave DAO\nvote. This prevents new collateral usage of the asset but does not impact\nexisting user positions already using it as collateral.2Prepare the Transaction Request#Next, we can proceed with creating the transaction request for the collateral toggle operation.ReactTypeScriptGraphQLUse the useCollateralToggle hook to create the transaction request for enabling or disabling collateral.import { useWalletClient } from \"wagmi\";import { useCollateralToggle, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [toggleCollateral, toggling] = useCollateralToggle();\nconst execute = async () => { const result = await toggleCollateral({ market: position.market.address, underlyingToken: position.currency.address, user: evmAddress(walletClient!.account.address), chainId: position.market.chainId, });\n // …};3Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useCollateralToggle } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [toggleCollateral, toggling] = useCollateralToggle();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = toggling.loading || sending.loading;const error = toggling.error || sending.error;\n// …\nconst execute = async () => { const result = await toggleCollateral({ // … }).andThen(sendTransaction);\n if (result.isErr()) { console.error(\"Collateral toggle failed:\", result.error); } else { console.log(\"Collateral toggle successful with hash:\", result.value); }};\nBorrow Assets#\nUsers can borrow assets from Aave markets at the reserve’s borrow APY using supply positions as collateral.\nWhen borrowing assets from an Aave market, you can use the following methods:\nMethodDescriptionTypical ScenarioDirect BorrowBorrow assets from a reserve using supplied collateralUser borrows from a reserve against their own supplied collateral.Credit DelegationBorrow assets from a reserve using delegated borrow creditsUser borrows from a reserve using credits from collateral supplied by a credit delegator.\nTo borrow assets from an Aave market, follow these steps.\n1Identify the Reserve#First, determine which reserve you want to borrow assets from.Let's say we choose the WETH borrow reserve within one of the Ethereum markets.const reserve: Reserve = { __typename: \"Reserve\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, underlyingToken: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, acceptsNative: { __typename: \"NativeCurrency\", symbol: \"ETH\", name: \"Ethereum\", // … }, isFrozen: false, isPaused: false, userState: { __typename: \"ReserveUserState\", borrowable: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"15.75\", raw: \"15750000000000000000\", decimals: 18, // … }, // … }, }, // …};To borrow from the reserve, you need to verify these conditions:Reserve.isFrozen is false - the reserve is not frozenReserve.isPaused is false - the reserve is not pausedReserve.userState.borrowable.amount.value is greater than 0 - the amount the user can borrow from the reserve given their unique circumstancesMake sure you include a user address when fetching market and reserve\ndata—otherwise Reserve.userState will be empty.Additionally, if Reserve.acceptsNative is not null, users can choose to receive any borrowed assets as the chain's native token and it will be automatically unwrapped before being sent to the user's wallet. This is typical for reserves of the wrapped version of the chain's native token (e.g., WETH on Ethereum).2Prepare the Execution Plan#Next, if all of these conditions are met, we can proceed with creating the execution plan for the borrow operation.ReactTypeScriptGraphQLUse the useBorrow hook to create the execution plan for a direct borrow operation.import { useWalletClient } from \"wagmi\";import { useBorrow, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [borrow, borrowing] = useBorrow();\nconst execute = async () => { const result = await borrow({ market: reserve.market.address, amount: { erc20: { currency: reserve.underlyingToken.address, value: bigDecimal(2), // 2 WETH }, }, sender: evmAddress(walletClient!.account.address), chainId: reserve.market.chain.chainId, });\n // …};If you intend to leverage credit delegation, you can first check the credit delegation allowance.import { useCreditDelegateeAllowance, evmAddress } from \"@aave/react\";\n// …\nconst { data: allowance, loading } = useCreditDelegateeAllowance({ market: reserve.market.address, underlyingToken: reserve.underlyingToken.address, user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), // Delegator delegatee: evmAddress(walletClient!.account.address), // Your address chainId: reserve.market.chainId,});\nif (allowance && BigInt(allowance.amount.raw) > 0n) { console.log(\"Available delegation allowance:\", allowance.amount.value);} else { console.log(\"No credit delegation allowance available\");}And then, you can proceed with preparing the execution plan for the borrow operation.import { useWalletClient } from \"wagmi\";import { useBorrow, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [borrow, borrowing] = useBorrow();\nconst execute = async () => { const result = await borrow({ market: reserve.market.address, amount: { erc20: { currency: reserve.underlyingToken.address, value: bigDecimal(2), // 2 WETH }, }, sender: evmAddress(walletClient!.account.address), chainId: reserve.market.chain.chainId, onBehalfOf: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), // Delegator });\n // …};3Process the Execution Plan#Finally, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useBorrow } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [borrow, borrowing] = useBorrow();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = borrowing.loading || sending.loading;const error = borrowing.error || sending.error;\n// …\nconst execute = async () => { const result = await borrow({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Borrow failed:\", result.error); } else { console.log(\"Borrow successful with hash:\", result.value); }};\nCredit Delegation#\nCredit delegation allows a user to approve another user (delegatee) to borrow assets against their own supply position. The supply position must be enabled as collateral.\nTo delegate credit to another address, follow these steps.\n1Identify the User Position#First, determine which user supply position you want to delegate credit from.Let's say we identified this MarketUserReserveSupplyPosition object.const position: MarketUserReserveSupplyPosition = { __typename: \"MarketUserReserveSupplyPosition\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, currency: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, balance: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"5.0\", raw: \"5000000000000000000\", decimals: 18, // … }, // … }, isCollateral: true, canBeCollateral: true, // …};Ensure MarketUserReserveSupplyPosition.isCollateral is true, if not enable it as collateral first.2Prepare the Transaction Request#Next, we can proceed with creating the transaction request for the credit delegation operation.ReactTypeScriptGraphQLUse the useApproveBorrowCreditDelegation hook to create the transaction request for approving credit delegation.import { useWalletClient } from \"wagmi\";import { useApproveBorrowCreditDelegation, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [approveDelegation, approving] = useApproveBorrowCreditDelegation();\nconst execute = async () => { const result = await approveDelegation({ market: position.market.address, underlyingToken: position.currency.address, amount: \"1000\", user: evmAddress(walletClient!.account.address), delegatee: evmAddress(\"0x5678…\"), chainId: position.market.chainId, });\n // …};3Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useApproveBorrowCreditDelegation } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [approveDelegation, approving] = useApproveBorrowCreditDelegation();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = approving.loading || sending.loading;const error = approving.error || sending.error;\n// …\nconst execute = async () => { const result = await approveDelegation({ // … }).andThen(sendTransaction);\n if (result.isErr()) { console.error(\"Credit delegation failed:\", result.error); } else { console.log(\"Credit delegation successful with hash:\", result.value); }};That's it—the delegatee can now borrow against the user's supply position.\nRepay Loans#\nBy repaying borrowed assets to an Aave market, users reduce or clear their debt position.\nWhen repaying borrowed assets to an Aave market, you can use the following methods:\nMethodDescriptionTypical ScenarioDirect RepayRepay ERC-20 or native tokens directly from the sender's wallet.User repays borrowed assets from their own wallet balance.On Behalf of AnotherRepay debt for another address.User borrowed with one wallet and wants to repay from a different wallet.With PermitUse a permit signature to skip ERC-20 approval and repay in a single transaction.User signs a permit and sends a single transaction. No ERC-20 allowance left behind.With PermitOn Behalf of AnotherSame as permit repay, but the debt position is owned by another wallet.No ERC-20 allowance needed when repaying debt for another wallet.\nTo repay borrowed assets from an Aave market, follow these steps.\n1Identify the User Position#First, determine which user borrow position you want to repay debt for.Let's say we identified this MarketUserReserveBorrowPosition object.const position: MarketUserReserveBorrowPosition = { __typename: \"MarketUserReserveBorrowPosition\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, currency: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, debt: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1.5\", raw: \"1500000000000000000\", decimals: 18, // … }, // … }, // …};That is tied to the following Reserve object.const reserve: Reserve = { __typename: \"Reserve\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, underlyingToken: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, permitSupported: true, acceptsNative: { __typename: \"NativeCurrency\", // … },};The Reserve.permitSupported flag indicates whether the underlying token supports EIP-2612 permits.Additionally, if Reserve.acceptsNative is not null, users can choose to repay the borrow position as the chain's native token and it will be automatically wrapped before being sent to the reserve. This is typical for reserves of the wrapped version of the chain's native token (e.g., WETH on Ethereum).2Prepare the Execution Plan#Next, we can proceed with creating the execution plan for the repay operation.ReactTypeScriptGraphQLUse the useRepay hook to create the execution plan for repaying debt from a market reserve, optionally on behalf of another address.import { useWalletClient } from \"wagmi\";import { useRepay, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [repay, repaying] = useRepay();\nconst execute = async () => { const result = await repay({ market: position.market.address, amount: { erc20: { currency: position.currency.address, value: { exact: bigDecimal(1), // 1 WETH }, }, }, sender: evmAddress(walletClient!.account.address), chainId: position.market.chainId, });\n // …};If Reserve.permitSupported is true and your borrow position is an ERC-20 token, you can use the useRepay and useERC20Permit hooks to sign permits and prepare repay transactions. Use the useERC20Permit implementation for the wallet library of choice.import { useRepay, bigDecimal, evmAddress } from \"@aave/react\";import { useERC20Permit } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [signPermit, signing] = useERC20Permit(walletClient);const [repay, repaying] = useRepay();\nconst execute = async () => { const amount = bigDecimal(42); // 42 WETH\n const permit = await signPermit({ amount, chainId: reserve.market.chain.chainId, currency: reserve.underlyingToken.address, owner: evmAddress(walletClient!.account.address), spender: reserve.market.address, }).andThen((signature) => repay({ market: position.market.address, amount: { erc20: { currency: position.currency.address, value: { exact: amount, // 42 WETH }, permitSig: signature, }, }, sender: evmAddress(walletClient!.account.address), chainId: position.market.chainId, }) );\n // …};3Process the Execution Plan#Finally, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useRepay } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [repay, repaying] = useRepay();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = repaying.loading || sending.loading;const error = repaying.error || sending.error;\n// …\nconst execute = async () => { const result = await repay({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Repay failed:\", result.error); } else { console.log(\"Repay successful with hash:\", result.value); }};\nWithdraw Assets#\nUsers can withdraw assets from Aave markets using their previously supplied reserves.\nWhen withdrawing assets from an Aave market, you can use the following methods:\nMethodDescriptionTypical ScenarioDirect WithdrawWithdraw ERC-20 or native tokens directly to supplier wallet.User withdraws supplied assets from their own wallet balance.Another RecipientWithdraw supplied assets to another address.User supplied with one wallet and wants to withdraw to a different wallet.\nTo withdraw supplied assets from an Aave market, follow these steps.\n1Identify the User Position#First, determine which user supply position you want to withdraw assets from.Let's say we identified this MarketUserReserveSupplyPosition object.const position: MarketUserReserveSupplyPosition = { __typename: \"MarketUserReserveSupplyPosition\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, currency: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, balance: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"5.0\", raw: \"5000000000000000000\", decimals: 18, // … }, // … }, // …};That is tied to the following Reserve object.const reserve: Reserve = { __typename: \"Reserve\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, underlyingToken: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, acceptsNative: { __typename: \"NativeCurrency\", // … },};2Prepare the Execution Plan#Next, we can proceed with creating the execution plan for the withdraw operation.ReactTypeScriptGraphQLUse the useWithdraw hook to create the execution plan for withdrawing assets from a market reserve.import { useWalletClient } from \"wagmi\";import { useWithdraw, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useWithdraw();\nconst execute = async () => { const result = await withdraw({ market: position.market.address, amount: { erc20: { currency: position.currency.address, value: { exact: bigDecimal(2), // 2 WETH }, }, }, sender: evmAddress(walletClient!.account.address), chainId: position.market.chainId, });\n // …};If Reserve.acceptsNative is not null, you can choose to withdraw the assets using the chain's native token.import { useWalletClient } from \"wagmi\";import { useWithdraw, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useWithdraw();\nconst execute = async () => { const result = await withdraw({ market: position.market.address, amount: { native: { value: { exact: bigDecimal(2) }, // 2 ETH }, }, sender: evmAddress(walletClient!.account.address), chainId: position.market.chainId, });\n // …};3Process the Execution Plan#Finally, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useWithdraw } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useWithdraw();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = withdrawing.loading || sending.loading;const error = withdrawing.error || sending.error;\n// …\nconst execute = async () => { const result = await withdraw({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Withdraw failed:\", result.error); } else { console.log(\"Withdraw successful with hash:\", result.value); }};\nAdvanced Operations#\nHealth Factor Preview#\nThe health factor is calculated only when a user has at least one active\nborrow position. If the user has no positions or only supply positions, the\nhealth factor will be null.\nTo preview how a user's health factor will change before executing a market operation (supply, borrow, repay, withdraw).\nReactTypeScriptGraphQLUse the useHealthFactorPreview hook to preview the health factor after the operation.import { useWalletClient } from \"wagmi\";import { useHealthFactorPreview, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();const [preview, { loading, error }] = useHealthFactorPreview();\nconst result = await preview({ action: { borrow: { market: reserve.market.address, amount: { erc20: { currency: reserve.underlyingToken.address, value: bigDecimal(42), // 42 WETH }, }, borrower: evmAddress(walletClient!.account.address), chainId: reserve.market.chain.chainId, }, },});\nif (result.isErr()) { console.error(result.error);} else { console.log(result.value.after); // 1.5 or null}PreviousUser PositionsNextIncentive Programs","tokens":7230,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258936668,"hash":"bb33f40a80cded8670957b6e7f6945a21bc1fe16"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/5","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 5 / 11\n\n Oct 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791258941522,"hash":"fc4a8b6230ee97aba2ba9ed9bfc47bdbd915dd56"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts","domain":"aave.com","title":"Smart Contracts | Aave Protocol Documentation","text":"Smart Contracts#\nAave v3.3 on Aptos is architected using a modular design that leverages Move's strengths. Each module encapsulates distinct functionality—from access control and configuration to data management and token operations—enabling isolated updates, robust permissioning, and scalable, secure protocol logic.\nNote: There are two notable differences versus EVM Solidity:\nCredit Delegation: Not supported in Move, in part due to low EVM usage and the lack of a native approve feature in Aptos Fungible Asset Standard.a_token Balance Management: Users must connect to the Aave contract for reading the correct a_token balance and initiating transfers; these actions cannot be performed directly from the wallet.\nModules#\n@aave-pool#\nMain pool implementation that coordinates reserve management and user interactions. Includes configurator modules for protocol admins to adjust parameters and data providers for external queries.\n@aave-acl#\nAccess Control List Manager that serves as the main registry of system roles and permissions. Implements role-based access control for various admin functions across the Aave protocol.\n@aave-config#\nConfiguration module that defines error codes and implements bitmap logic for reserve and user configurations. Provides utilities for managing protocol parameters like LTV ratios, liquidation thresholds, and borrowing limits.\n@aave-oracle#\nPrice oracle implementation that fetches and validates asset prices for the Aave protocol. Includes price cap adapters for stablecoins and sentinel functionality to handle oracle outages.\n@aave-tokens#\nToken factory modules for creating and managing aTokens and variable debt tokens. Handles token minting, burning, and transfer operations with proper scaling based on interest accrual.\n@aave-data#\nData storage module that maintains protocol configuration values and token naming conventions. Stores interest rate strategies, e-mode configurations, and other protocol parameters for both mainnet and testnet.\n@aave-logic#\nCore business logic modules implementing liquidity pool operations like borrowing, supplying, and liquidations. Contains specialized logic for features like flash loans, e-mode, and isolation mode.\n@aave-periphery#\nAuxiliary modules that extend core functionality with features like rewards, emissions, and UI data providers. Includes a collector module for protocol fees, ecosystem reserve management, and coin migration utilities.PreviousAave V3 on AptosNextPool","tokens":618,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791258946693,"hash":"5628765717b4485796ff90d20dafefde68f1a932"}
{"url":"https://forum.openzeppelin.com/t/how-to-upgrade-contracts-that-was-created-via-a-factory-contract-without-any-cli/1893","domain":"forum.openzeppelin.com","title":"How to upgrade contracts that was created via a factory contract without any CLI? - Archive / SDK - OpenZeppelin Forum","text":"How to upgrade contracts that was created via a factory contract without any CLI? \n\n ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n 2\n\n Dec 2019\n\n 1 / 9\n\n Dec 2019\n\n Jul 2020\n\n post by itinance on Dec 5, 2019\n\n itinance\n\n Lets say we create contract instances only on-chain via Factory method like it was described in this example and this question, is there any way to use the upgradability of contracts also on those that was created this way programmatically?\nopenzeppelin cli tool doesn’t recognize any change on contracts that were never build via openzeppelin cli, nor can it handle upgrades on these.\nAny changes to just upgrade such contracts without loosing the proxies to them?\n\n 4\n\n 2\n\n 2\n\n post by abcoathup on Dec 5, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @itinance,\nThere is an open issue to support interacting with a contract at a specific address which would allow this sort of functionality: https://github.com/OpenZeppelin/openzeppelin-sdk/issues/1264 (I see you have already commented on this Issue).\n\n post by itinance on Dec 6, 2019\n\n itinance\n\n Hi @abcoathup, beside the CLI I was looking for any approach to upgrade those contracts within contracts like the creation via factory method, but couldn’t find any proper code for it.\nWhat do you think? Is it worth it to file a feature request or has somebody already manage it to work without my knowledge? \n\n post by abcoathup on Dec 6, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @itinance,\nI am not sure of the best way to do this.\nOne approach could be to deploy the new logic contract and then call either upgradeTo or upgradeToAndCall of AdminUpgradeabilityProxy with the address of the new logic contract.\nI assume there is also a way via App.sol.\nI will see what I can find out.\n\n post by Dennison on Dec 6, 2019\n\n Dennison\n\n So if you are following those examples and using the OpenZeppelin SDK on-chain, yes those contracts created by the factory are upgradable. However, they are currently not (easily) upgradable via the CLI, because, as you correctly identified, the CLI does not have any way of knowing about them.\nUnfortunately we don't currently have an easy way to take care of this, but what you would need to do is keep track of the contracts created by your factory (either with another contract, or emit events when your contracts have been created which are caught by an off chain service) and then those contracts you can upgrade manually via solidity code.\nIf you wanted to make your life easier and didn't mind first making it harder , THEN easier, you can poke around the dev-<<some number here>>.json file which is created to track your project on the network, and you can add the information related to the new upgradable files created by the factory so that you can manage it via the CLI.\nOtherwise, though, this sounds like a really interesting feature, but it doesn't really scale I think for using in the CLI. If users created thousands of contracts with the CLI, it would be very, very difficult to to manage to upgrade them individually via the CLI.\n\n post by abcoathup on Dec 9, 2019\n\n abcoathup\n\n Great contributor\n\n abcoathup\n\n Hi @itinance,\nYou could deploy the new logic contract using oz push and then call either upgradeTo or upgradeToAndCall of AdminUpgradeabilityProxy with the address of the new logic contract.\nYou could get the new logic address from App via getImplementation (https://github.com/OpenZeppelin/openzeppelin-sdk/blob/d39fa3da52562c585a5d6e8785e25245c0d5ee5b/packages/lib/contracts/application/App.sol#L97).\nAs @Dennison suggested, another option is to manually modify network.json though it isn’t terribly scaleable.\nYou may want to add a feature request in the GitHub repository: https://github.com/OpenZeppelin/openzeppelin-sdk\n\n How to upgrade a contract deployed from a factory contract?\n\n 7 months later\n\n post by asmeedhungana on Jul 20, 2020\n\n asmeedhungana\n\nCan you elaborate on how we can do that?\nhttps://docs.openzeppelin.com/learn/upgrading-smart-contracts#:~:text=Upgrading%20Contracts%20Programmatically,interaction%2C%20and%20source%20code%20verification.\nThis is done via ProxyAdminProject... If I created a Product contract using App.sol, will I have to use AppProject or what?\nCan I get an example ?\n\n post by abcoathup on Jul 20, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @asmeedhungana,\nI suggest looking at ProxyFactory.\nWe can continue the discussion in your recent post: How to upgrade a contract deployed from a factory contract?\n\n post by asmeedhungana on Jul 20, 2020\n\n asmeedhungana\n\n Okay… please do reply in there as soon as you can! I have to present something on it today!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to use the CLI with contracts created via a factory contract\n\n SDK\n\n 11\n\n 1.9k\n\n Jun 2021\n\n How to upgrade a contract deployed from a factory contract?\n\n SDK\n\n proxies\n\n 12\n\n 2.9k\n\n Jul 2020\n\n How to upgrade contracts programmatically?\n\n SDK\n\n 7\n\n 2.3k\n\n Jun 2020\n\n Openzeppelin upgrades - new instance in a contract\n\n Upgrades\n\n proxies\n\n 4\n\n 1.5k\n\n Nov 2021\n\n How to interact with a contract created using a factory?\n\n SDK\n\n upgrades\n\n 1\n\n 777\n\n Jun 2020","tokens":1311,"squid":"ink-security_audits","role":"Sentinel","at":1791258957722,"hash":"75809b2a3e00563924ca2b3a1a7458df6c89b1ad"}
{"url":"https://docs.openzeppelin.com/sdk/2.6/api/upgrades","domain":"docs.openzeppelin.com","title":"OpenZeppelin Docs","text":"OpenZeppelin DocumentationBuild secure blockchain applications with industry-standard smart contracts and developer toolsSmart ContractsOpenZeppelin Solidity ContractsThe world's most trusted library of Solidity smart contracts for Ethereum and EVM blockchains, powering nearly every onchain application.→Upgrades PluginsDeploy upgradeable contracts using Hardhat and Foundry plugins that automate proxy deployments, enforce safety checks, and more.Contracts WizardConfigure and generate smart contracts in seconds through an interactive interface.Contracts MCPWrite secure smart contracts that follow OpenZeppelin standards with your favorite AI assistant.+5Contracts libraries are also available for Starknet, Sui, Stellar, Zama FHEVM, and more blockchainsExplore allOpen Source ToolsRelayerAutomate onchain transactions to schedule jobs, batch calls, and relay gasless meta transactions within your self-hosted infrastructure.MonitorMonitor onchain activity in real time to watch critical events, detect anomalies, trigger alerts on your preferred channels, and set automated responses with Relayer.UI BuilderSpin up user interfaces for any deployed contract. Select the function, auto-generate a React UI with wallet-connect and multi-network support, and export a complete app.Blockchains and Developer EcosystemsChoose your blockchain platform to explore available contracts and toolsEthereum & EVMBuild with Solidity smart contracts and developer tools for Ethereum and EVM chainsStarknetDevelop Cairo smart contracts to build apps on Starknet zero-knowledge Layer 2SuiBuild Move smart contracts on Sui with secure and efficient primitivesTronBuild secure Solidity smart contracts on Tron's TVM with the TRC token standardsArbitrum StylusWrite high-performance smart contracts in Rust on the EVM with Arbitrum StylusUniswap HooksCustomize Uniswap V4 hooks with advanced, audited modulesStellarBuild with Soroban smart contracts and developer tools on StellarMidnightBuild privacy-preserving smart contracts in Compact for the Midnight blockchainPolkadotDevelop smart contracts and parachain runtimes for Polkadot and SubstrateZama FHEVMImplement fully homomorphic encryption for confidential smart contracts in SolidityCantonBuild privacy-enabled Daml applications on the Canton Network with secure, reusable primitivesLearn & PlayMaster smart contract security through interactive challengesEthernaut CTFLearn smart contract security by hacking. Ethernaut is a capture-the-flag game where each level is a vulnerable contract to exploit. Master real-world attack vectors and defense strategies through hands-on challenges.→Community & SupportConnect with the community for technical discussions and supportForumEngage in technical deep-dives and architectural discussions. Get detailed answers, share your implementations, and learn from experienced developers building in production.","tokens":723,"squid":"ink-security_audits","role":"Sentinel","at":1791258970517,"hash":"6705a1da5797ab8e3d6e210201f9cdcf4a3d22a5"}
{"url":"https://vote.optimism.io/proposals/4304410266089046490387351551487953598976707777337874544366097374448296807206","domain":"vote.optimism.io","title":"Maintenance Upgrade Proposal: Mode, M...","text":"ProposalsVotersConnect  Wallet Optimistic Proposal by The Optimism FoundationMaintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to ConduitProposal Visualization Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit is a maintenance upgrade that returns administrative ownership of four chains to Conduit following the conclusion of OP Labs' security monitoring and upgrade support. The proposal transfers the L1 ProxyAdmin ownership, DisputeGameFactory ownership, and L2 ProxyAdmin ownership for Mode (34443), Metal L2 (1750), Zora (7777777), and Dust (55378) from the Optimism Security Council to Conduit's designated Safes.\nFollowing execution, Mode, Metal, and Zora will no longer be governed by Optimism and will be updated accordingly in the Superchain Registry. Dust, which was inadvertently deployed with Optimism Security Council oversight despite being operated by Conduit and not part of the Superchain Registry, will also be transferred to independent management.\nThis is an optimistic approval. You should only cast a vote if you want to veto this maintenance upgrade. You can read more about this proposal type in our operating manual. You can read the proposal in its entirety here.Voting activityThis proposal is optimistically approvedThis proposal will automatically pass unless 20% of the votable supply of OP is against. Currently 0.04% (24,028 OP) is against.SUCCEEDEDEnded 5:21 am Sep 08, 2026VotersHasn't votedtommy-shelby.eth10,212 neeer.eth1,606 muzard.eth1,321 lexx77.eth1,142 niceaccount.eth995 06rolf.eth804 xiaokui1188.eth785 dabingaccount.eth743 loveeachother.eth629 kostik2608.eth599 lbjames.eth473 0xa4...983f401 Maintenance Upgrade Proposal: Mode, M...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":460,"squid":"ink-governance","role":"Council Listener","at":1791258970560,"hash":"ec4edca28778fe32bc8536602c5b47d3108e4a6e"}
{"url":"https://io.net/docs/guides/faq","domain":"io.net","title":"FAQ - io.net","text":"Q: What is io.net's mission, and what are you working towards?io.net is a decentralized GPU network designed to give unlimited computing power to ML applications. We make computing more scalable, accessible, and efficient. Our mission is to unlock fair access to computing power by assembling 1 million + GPUs from independent data centers, crypto miners, and crypto projects such as Filecoin or Render.Q: How big is the GPU shortage? How is io.net solving it?The major cloud providers currently have around 10-15 exaFLOPS of GPU compute capacity available. However, given the surging volume of AI/ML model training and inferencing workloads, the potential demand for GPU compute in the cloud could be as high as 20-25 exaFLOPS.This suggests the current shortage in cloud GPU capacity is likely in the range of 5-10 exaFLOPS. In the near future, cloud GPU capacity must expand 2- 3 times current levels in order to meet user demand.There is a long lead time to increase GPU supply which suggests that this problem won’t be resolved any time soon.io.net is solving this by accessing underutilized GPU sources outside of the cloud such as:\nIndependent data centers: There are thousands of independent data centers in the US alone, and their average utilization rate is only 12% - 18%.\nCrypto miners: Miners have suffered significant losses with Ethereum’s switch to Proof-of-Stake. They can repurpose GPUs in our DePin network.\nConsumer GPUs: Consumer GPUs account for 90% of the total supply yet the majority of these resources are latent in consumer households and small cloud farms.\nWhen combined, it is estimated these sources can provide an additional 200 exaFLOPs of GPU capacity.Q: How is io.net different from AWS?io.net offers a fundamentally different approach to cloud computing. We leverage a distributed and decentralized model that provides increased control and flexibility for users. io.net’s services don’t involve complicated permission models and it’s cost efficient. The combination of all these factors sets io.net in its own league of Decentralized providers.Q: How & why is io.net cheaper and faster than other providers like AWS?io.net is significantly more affordable and faster than current cloud solutions. By leveraging underutilized sources, such as independent data centers, crypto miners, and consumer GPUs, we offer compute for up to 90% less than traditional cloud providers.We are significantly faster than the competition because creating distributed clusters through traditional cloud providers is a time-consuming process. Companies like AWS often ask for detailed KYC information, require long-term contracts, and often have waitlists for the most desired hardware. It can often take two weeks to obtain GPU compute from cloud providers.io.net doesn’t impose these restrictions which allows users to access GPU supply and deploy clusters in less than 90 seconds. Ultimately, the combination of speed and cost allows io.net to be 10x to 20x more efficient than traditional cloud providers.Q: What is a DePIN and how does io.net fit?DePIN, or Decentralized Physical Infrastructure Networks, leverages blockchains, IoT, and the greater Web3 ecosystem to create, operate and maintain real-world physical infrastructure. These networks use token incentives to coordinate, reward, and safeguard members of the network. io.net is the first and only GPU DePIN. We are optimized for machine learning but are also ideal for all GPU use cases.Q: What type of GPUs does io.net offer?We offer a wide range of:\nGPUs, including NVIDIA RTX series, and AMD Ryzen series.\nCPUs, including Intel, AMD, and the Apple M3/M4 Chip with its unparalleled neural engine.\nPlease refer to (pricing page) to see the full list of supported GPUs. Contact our support team if your hardware is not listed.Our minimum requirements are:\n+12 GB of RAM\n+500 GB Free Disk Space\nInternet Speed : Download +500 MBs and +250 Mbps Upload with /< 30ms ping\nTest your internet from here: https://www.speedtest.netQ: Why is io.net needed for machine learning?io.net is natively built on top of ray.io, a machine-learning framework for distributed computing. This is the same framework used by open.ai to train GPT3 over 300k CPUs and 20k GPU. You can use io.net to distribute your AI and Python applications for reinforcement learning to deep learning, to tuning, and model serving - across an extensive grid of GPUs.We are set to support all the frameworks that ML engineers use for workload distribution, including Anyscale, Pytorch FSDP, TensorFlow, and Predibase.Q: Who are your target customers?Anyone looking to create or operate an ML model or AI app is a potential customer. Due to the explosion of “no-code tools” like Predibase and model creation platforms like Hugging Face, this will eventually be a massive market.Q: How do we manage availability and allocation to users across your global network of GPUs?io.net connects a global network of clients to a global network of suppliers. We deploy our container on each worker machine, facilitating the io.net Virtual Network’s integration and monitoring of all device availability across the network. Our algorithm intelligently groups resources, matching the selections made by the engineer and glues them into a cluster, all within 90 seconds. Our networking solution has been thoroughly tested and found reliable.Q: What is the connectivity requirement for suppliers?\nWe are offering clients different tiers of connectivity, from low to ultra high. While our absolute minimum connectivity requirement is 250 Mbps, we strongly encourage suppliers to support at least 1 Gbps download and upload speeds to remain attractive to demand-side customers.\nWe expect data traffic to average 5GB / hour.\nQ: Can I customize cluster creation?Clients can create their cluster with unmatched flexibility through a set of selections and options: cluster type by use case, sustainability (e.g., “Green GPUs” powered by 100% clean energy), geographic location, security compliance level (SOC2, HIPAA, end-to-end encryption), connectivity tier, and cluster purpose (currently Ray App, but more options available soon). Our out-of-the-box configuration requires no additional setup by our clients to deploy the cluster.Q: Explain the pricing model? Do pricing tiers differ based on GPU model / performance?Prices are automatically determined based on supply and demand; GPU specs, such as internet speed, GPU make and model, security / compliance certifications, etc., will also affect pricing. For example, enterprise-grade GPUs with SOC2 compliance and >2 Gbps cost more than consumer-grade GPUs without SOC2 compliance and slower connectivity.Q: What's the maximum amount of GPUs allowed in a single cluster?The only limitation for your cluster size is the total available supply of GPUs.Q: How long does it take to create a cluster of GPUs?It takes less than 90 seconds to create a cluster on io.net.Q: Is it possible to adjust the number of GPUs in my cluster as my requirements change?Yes it is possible to adjust the number of GPUs either with Auto Scaling or by manually adding nodes to your cluster.Q: What is the minimum and maximum duration for GPU cluster rentals?There is a one hour minimum for clusters. You can rent GPUs for as long as you need them, there is no time limit.Q: Does the docker container launch with --privileged flag?No, the Docker container does not launch with the —privileged flag.Q: Why do we mount the Docker socket while starting the containers?The platform manages the device states and usage through the orchestration of docker containers. You must mount the docker socket to manage docker containers on the worker node. This is mandatory for the platform and there are currently no plans or alternatives to remove this.Q: Isn't mounting docker socket and --privileged flag the same?While the —privileged flag gives broad system access to a container, mounting the Docker socket gives the container control over Docker on the host.Q: Why do you use docker containers?Our platform enables clustering GPU compute and provides the end user of the platform with a production ready environment for distributed training. The custom docker images contain all the required drivers and environments. All the required libraries are installed, enabling efficient utilization of GPU and CPU resources that are required for distributed training.For suppliers, reproducing our environment is challenging and can result in irregularities based on the worker platform (linux, windows). Docker helps to stabilize this issue. Distributed training can only function if the environment is replicated on all nodes.Q: Do you have proof of compute / verification, what kind of proof do you use ?Current Industry ProtocolIt’s primarily accomplished with validators that randomly replicate compute jobs on the network and verify that it matches the results provided by participants. Secondly, with a rewards punishment system that ensures that participants are not providing false results since the compute is done off chain. Thirdly, through proof of learning which is an anti-cheat mechanism based on logs provided by user that detail their compute process and some other steps.This proof of compute isn’t mature and hasn’t proven itself as its efficacy remains theoretical. In proof-of-work systems, due to the sequential nature of computations, validating work at a specific point requires completing all previous work up to that point. There are many other obstacles and challenges associated with this model.io.net Protocolio.net leverages the existing model, taking advantage of its benefits and enhancing its strengths with our improvements. Our compute service operates on an hourly basis, allowing users to book clusters for specific periods of time. Since our service is time based rather than compute based, we simply need to prove that the GPU’s compute power is completely available when it’s rented.This is achieved with io.net’s innovative concept of Proof: Proof of Time-Lock. This provides proof that the GPUs were not accessed by any other services or threads that would diminish compute power during the time it was rented. We can prove that from the start of the rental period (T1) until the end (T2), the GPU is 100% committed to the AI/ML jobs running on the device. This proof consists of multiple steps that benchmarks:\nConsumption\nMonitoring containers\nEliminating foreign processes\nA punishment and rewards system to ensure that all workers are compliant\nAll this is accomplished with io.net’s revolutionary AI, which learns at a granular level with each cluster booking to ensure fairness and maintain a trusted environment throughout the entire process.Q: How do you mitigate latency issues?\nio.net’s flexible system features our algorithm that intelligently groups resources and matches their Connectivity Speed, Geolocations, and Hardware Specs to eliminate bottlenecks and reduce latency.\nOur distribution technology on Ray and Mesh networks ensures that data travels along multiple paths which increases redundancy, fault tolerance, while improved load distribution minimizes latency.\nWhen VPNs are used to increase security it often results in increased latency. In order to offer robust security with minimal latency, we employ a kernel-level VPN that uses one of the most secure mesh VPN protocols, ensuring high security without compromising network performance.\nThe majority of our GPU supply is hosted by Tier 3 - 4 data centers and advanced mining facilities. Quality infrastructure results in low latency. Our reports indicate that over 40% of our supply has internet speeds surpassing those of Lambda Labs Cloud.\nQ: How do you parallelize? / How are you connecting all the GPUs together?Distribution and decentralization: We leverage Ray with specialized libraries for data streaming, training, fine-tuning, hyperparameter tuning. When our technology is combined with Mesh VPN, it results in a streamlined process for developing and deploying large-scale AI models across a vast network of GPUs.Q: How do you ensure data privacy and security?Our IO agent eliminates risks by detecting and blocking unauthorized containers from running on a hired GPU. When a node is hired, data between worker nodes is encrypted within the Docker file system. Network traffic is on a mesh VPN, providing maximum security. We also prioritize suppliers with SOC2 compliance and continue to stress the importance of SOC2 compliance with our suppliers.Was this page helpful?","tokens":3136,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258977133,"hash":"51f2dffbccb00a251ac734d4f2b56a87480d589d"}
{"url":"https://gov.optimism.io/t/maintenance-upgrade-proposal-mode-metal-zora-and-dust-ownership-transfer-to-conduit/10838","domain":"gov.optimism.io","title":"Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit - Proposals 📃 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit \n\n Proposals 📃\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2\n\n 1 / 1\n\n Sep 1\n\n Sep 2\n\n post by system on Sep 2\n\n system\n\n Proposal Type: Maintenance Upgrade Proposal\nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period)\nSummary\nThis proposal requests the Optimism Security Council return administrative ownership of four chains operated by Conduit, to Conduit’s designated Safes:\n\nMode (34443)\nMetal L2 (1750)\nZora (7777777)\nDust (55378)\n\nFor each network, the proposal transfers the L1 ProxyAdmin (L1PAO) ownership, the DisputeGameFactory (DGF) ownership, and the L2 ProxyAdmin ownership to Conduit’s designated Safes.\nThese changes are purely administrative: no protocol behavior changes and no impact on end users or other Superchain members.\nMotivation\nMode, Metal, and Zora are operated by Conduit while the Optimism Collective holds their L1 ProxyAdmin keys. OP Labs has provided security monitoring and upgrade support for these chains. On July 30, 2026, written notice was delivered to each chain’s governor that this support will end following a 30-day notice period. Returning the keys to Conduit lets the chains be managed independently going forward.\nDust was inadvertently deployed with the Optimism Security Council holding its L1 ProxyAdmin keys. Because Dust is operated by Conduit and will not be part of the Superchain Registry, the Optimism Collective’s administrative custody is unnecessary and Conduit has requested the keys be returned.\nAll four chains’ smart contracts currently reference OP Mainnet’s SuperchainConfig. That contract is shared infrastructure and is not transferred by this proposal; after taking ownership of the ProxyAdmin, Conduit can repoint each chain to its own SuperchainConfig.\nFollowing execution, Mode, Metal, and Zora will no longer be governed by Optimism and will be updated accordingly in the Superchain Registry.\nSpecifications\n\nCurrent Mainnet L1PAO and DisputeGameFactory owner for Metal, Mode, Zora and Dust (OP safe): 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A\nCurrent L2PAO (L1 alias): 0x6B1BAE59D09fccBdDb6C6CcEB07B7279367C4E3B\nNew L1PAO and DisputeGameFactory owner (Conduit safe): 0x4a4962275DF8C60a80d3a25faEc5AA7De116A746\nNew L2PAO (L1 alias): 0x5b5A62275DF8c60A80D3a25FAeC5aA7De116b857\n\nThe transfers are implemented in superchain-ops tasks as one bundled L1 and DGF ownership-transfer task and one bundled L2 ProxyAdmin transfer task per network.\nMAINNET\n067-mmzd-l1-ownership-transfers\nTask Calldata:\n0x174dea7100000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000002c000000000000000000000000000000000000000000000000000000000000003a000000000000000000000000000000000000000000000000000000000000004800000000000000000000000000000000000000000000000000000000000000560000000000000000000000000000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000000000000007200000000000000000000000007bfff391a2dbbdc68a259792ac9748f50fcde93e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a7460000000000000000000000000000000000000000000000000000000000000000000000000000000037ff0ae34dada1a95a4251d10ef7caa868c7ac990000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a746000000000000000000000000000000000000000000000000000000000000000000000000000000006f13efadabd9269d6cead22b448d434a1f1b433e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a74600000000000000000000000000000000000000000000000000000000000000000000000000000000470d87b1dae09a454a43d1fd772a561a03276ab70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a74600000000000000000000000000000000000000000000000000000000000000000000000000000000b0f15106fa1e473ddb39790f197275bc979aa37e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a74600000000000000000000000000000000000000000000000000000000000000000000000000000000d4ef175b9e72caee9f1fe7660a6ec19009903b490000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a74600000000000000000000000000000000000000000000000000000000000000000000000000000000fcd88154a329557499535e7c803f3b3bd7fa11150000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a7460000000000000000000000000000000000000000000000000000000000000000000000000000000032c61bd2b7bf8e50f448331705edda99244e73390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000004a4962275df8c60a80d3a25faec5aa7de116a74600000000000000000000000000000000000000000000000000000000\n\n068-mmzd-l2pao-transfer\nTask Calldata:\n0x174dea710000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000240000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000005c00000000000000000000000003f37abde2c6b5b2ed6f8045787df1ed1e37539560000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000104e9e05c42000000000000000000000000420000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030d40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000005b5a62275df8c60a80d3a25faec5aa7de116b85700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008b34b14c7c7123459cf3076b8cb929be097d0c070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000104e9e05c42000000000000000000000000420000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030d40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000005b5a62275df8c60a80d3a25faec5aa7de116b85700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a0ad011913a150f69f6a19df447a0cfd95510540000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000104e9e05c42000000000000000000000000420000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030d40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000005b5a62275df8c60a80d3a25faec5aa7de116b8570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f573a6da7a5b5de9fbadfc26cffc595ad04dc7d40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000104e9e05c42000000000000000000000000420000000000000000000000000000000000001800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000030d40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000024f2fde38b0000000000000000000000005b5a62275df8c60a80d3a25faec5aa7de116b8570000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n\nAction Plan\nUpon governance approval and following the standard veto period, the Optimism Security Council will verify and execute the transfers per network, in order: the L1 ownership transfer first, then the L2 ProxyAdmin transfer (a deposit that finalizes on L2 after inclusion).\nFollowing execution, the Superchain Registry will be updated to reflect that Mode, Metal, and Zora are no longer governed by Optimism.\nConclusion\nThis proposal returns administrative ownership of Mode, Metal, Zora, and Dust’s chain to Conduit. The change is entirely administrative, modifies no protocol code, and only impacts the chains outlined in this post.\n\n PGov - Delegate Communication Thread\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization\n\n Protocol Upgrade\n\n Hi Maurelian here, I’m a protocol security engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not re…\n\n read more\n\n 26\n\n 2.5k\n\n May 2024\n\n Upgrade Proposal #4\n\n Protocol Upgrade\n\n season-5,cycle-18\n\n Hi I’m Maurelian, an engineer at OP Labs. \nOP Labs is a software development company focused on the Optimism ecosystem, and a core developer of the OP Stack. We provide some services to, but do not represent or speak on …\n\n read more\n\n 24\n\n 4.2k\n\n Feb 2024\n\n [GF: Phase 0 Proposal] Connext\n\n Governance Fund: Phase 0\n\n cycle-1\n\n Project Name: Connext \nAuthor Name: Max Lomuscio \nDefillama TVL (at snapshot on Optimism): $9.8M \nTransactons/day (at snapshot): 92 \nTier: 3 \nOptimism native: No \nNumber of OP tokens to claim: 300,000 \nL2 Recipient Addre…\n\n read more\n\n 65\n\n 8.2k\n\n Apr 2023\n\n Blockchain@USC - Delegate Communication Thread\n\n Delegate Updates\n\n Hello all! We are the blockchain club at the University of Southern California. \nOur delegate address is: 0x995013B47EF3A2B07b9e60dA6D1fFf8fa9C53Cf4 \nHere’s what we stand for:\nMission: In our role as a delegate, we striv…\n\n read more\n\n 8\n\n 2.1k\n\n Apr 2025\n\n [FINAL] Superchain Governance Deep Dive\n\n ARCHIVED & OLD Missions\n\n season-4\n\n S4 Intent: Intent 1: Progress Towards Technical Decentralization \nProposed Mission: Deeply investigate the technical design space around decentralized Superchain governance and produce a white paper that serves as a rese…\n\n read more\n\n 37\n\n 6.4k\n\n Oct 2023","tokens":3369,"squid":"ink-governance","role":"Council Listener","at":1791258980746,"hash":"e1adbfb9cc44ba72c4bf373f7ce9f43d1f6cd6c3"}
{"url":"https://io.net/docs/guides/block-rewards/monitor-block-rewards","domain":"io.net","title":"Monitor Block Rewards - io.net","text":"​Table of Contents\n\nBlock Rewards Tab\nBlock Details Table\n\n​Block Rewards Tab\nThe Block Rewards tab provides a transparent view of io.net’s Block Rewards and coin emissions. Users can consult this information to monitor worker nominations and their status. Users can track the performance and success rates for worker nominations and block completion. Information on coin emissions and block rewards provide transparency about io.net network’s health.\nThe example below shows the Block Rewards tab, with each section explained in detail afterward.\n\nThe top section of the Block Rewards tab provides real-time data about IO Coin emissions and blocks.\nBlockDescriptionTotal Coins DistributedThe cumulative number of IO Coins distributed since inception.Today’s Distributed CoinsTotal number of IO Coins distributed for the current calendar day.Total Epochs ComputedThe cumulative number of epochs successfully added to the blockchain since inception.Next Epoch StartThe estimated time when the next epoch will be initiated. Blocks are added to the chain at hourly intervals.Total Unique Suppliers PaidThe number of unique workers that earned a block reward since inception.Today’s Unique Suppliers PaidThe number of unique workers that earned a block reward for the current calendar day. Each day ends at UTC+0.\n​Epoch Details Table\nThe table provides a detailed overview of the epochs processed in the blockchain. The list provides a transparent and verifiable record of all epochs running in our network. Users can search for specific epochs and view details, verify transactions, and trace the history and integrity of the blockchain.\nThe table is an important tool to monitor the blockchain’s performance, transparency, and efficiency, and provides users with insight into the block creation process and the distribution of rewards.\nBlockDescriptionTotal Coins DistributedThe cumulative number of IO Coins distributed since inception.Today’s Distributed CoinsTotal number of IO Coins distributed for the current calendar day.Total Epochs ComputedThe cumulative number of epochs successfully added to the blockchain since inception.Next Epoch StartThe estimated time when the next epoch will be initiated. Blocks are added to the chain at hourly intervals.Total Unique Suppliers PaidThe number of unique workers that earned a block reward since inception.Today’s Unique Suppliers PaidThe number of unique workers that earned a block reward for the current calendar day. Each day ends at UTC+0.\n​Epoch Details Table\nThe table provides a detailed overview of the epochs processed in the blockchain. The list provides a transparent and verifiable record of all epochs running in our network. Users can search for specific epochs and view details, verify transactions, and trace the history and integrity of the blockchain.\nThe table is an important tool to monitor the blockchain’s performance, transparency, and efficiency, and provides users with insight into the block creation process and the distribution of rewards.\nBlockDescriptionTotal Coins DistributedThe cumulative number of IO Coins distributed since inception.Today’s Distributed CoinsTotal number of IO Coins distributed for the current calendar day.Total Epochs ComputedThe cumulative number of epochs successfully added to the blockchain since inception.Next Epoch StartThe estimated time when the next epoch will be initiated. Blocks are added to the chain at hourly intervals.Total Unique Suppliers PaidThe number of unique workers that earned a block reward since inception.Today’s Unique Suppliers PaidThe number of unique workers that earned a block reward for the current calendar day. Each day ends at UTC+0.\n​Epoch Details Table\nThe table provides a detailed overview of the epochs processed in the blockchain. The list provides a transparent and verifiable record of all epochs running in our network. Users can search for specific epochs and view details, verify transactions, and trace the history and integrity of the blockchain.\nThe table is an important tool to monitor the blockchain’s performance, transparency, and efficiency, and provides users with insight into the block creation process and the distribution of rewards.\n\nIf a epoch reward is in progress, you are unable to click on it until it is complete.\nIf a epoch reward is in progress, you are unable to click on it until it is complete.\nIf a epoch reward is in progress, you are unable to click on it until it is complete.Was this page helpful?","tokens":1121,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258987902,"hash":"bff63d4419d6b95979ee80cb948a0a99d0994f7b"}
{"url":"https://docs.openzeppelin.com/wizard","domain":"docs.openzeppelin.com","title":"Contracts Wizard | OpenZeppelin Docs","text":"Contracts WizardA tool for building smart contractsOpen in ClaudeContracts Wizard is a web application to interactively build a contract out of components from OpenZeppelin Contracts. Select the kind of contract that you want, set your parameters and desired features, and the Wizard will generate all of the code necessary. The resulting code is ready to be compiled and deployed, or it can serve as a starting point and customized further with application specific logic.\n\nUsage\nUse the Contracts Wizard here in the docs or at wizard.openzeppelin.com\nTypeScript API\nYou can use the programmatic TypeScript API to generate contracts from your own applications.\nView the API documentation for each smart contract language:\n\nSolidity\nCairo\nStellar\nStylus\n\nEmbedding\nTo embed Contracts Wizard on your site, first include the script tag:\n<script async src=\"https://wizard.openzeppelin.com/build/embed.js\"></script>\nThen place <oz-wizard></oz-wizard> in the body where you want Contracts Wizard to load.\nOptionally focus on specific tab with the data-tab attribute as in <oz-wizard data-tab=\"ERC721\"></oz-wizard>.\nFor languages other than Solidity, use the data-lang attribute, for example: <oz-wizard data-lang=\"cairo\"></oz-wizard>.Hardhat Upgrades APIPrevious PageOverviewNext PageOn this pageUsageTypeScript APIEmbedding","tokens":330,"squid":"ink-security_audits","role":"Sentinel","at":1791258994663,"hash":"7632f8f0cf25c280ca628e34006037ddf02423c8"}
{"url":"https://io.net/docs/guides/architecture/io-architecture","domain":"io.net","title":"Architectural Layers - io.net","text":"​User Interface\nThis layer is the visual gateway for users. It comprises the Public website, Customers area, and GPU providers area (Workers). The design is intuitive and user-centric, ensuring easy navigation and interaction.\n\nTech Stack: ReactJS, Tailwind, web3.js, zustand.\n\n​Security Layer\nA pivotal layer ensuring the system’s integrity and safety. It encompasses a Firewall for network protection, an Authentication Service for user validation, and a Logging Service for tracking activities.\n\nTech Stack: Firewall (pfSense, iptables), Authentication (OAuth, JWT), Logging Service (ELK Stack, Graylog).\n\n​API Layer\nServing as the communication bridge, this layer has multiple facets: Public API for the website, Private APIs for Workers/GPU Providers and Customers, andInternal APIs for Cluster Management, Analytics, and Monitoring/Reporting.\n\nTech Stack: FastAPI, Python, GraphQL, RESTful services, gunicorn, solana.\n\n​Backend Layer\nThe powerhouse of the system. It manages Providers (Workers), Cluster/GPU operations, Customer interactions, Fault Monitoring, Analytics, Billing/Usage Monitoring, and Autoscaling.\n\nTech Stack: FastAPI, Python, Node.js, Flask, solana, IO-SDK (a fork of Ray 2.3.0), Pandas.\n\n​Database Layer\nThe data repository of the system. It uses Main storage for structured data and Caching for temporary and frequently accessed data.\n\nTech Stack: Postgres (Main storage), Redis (Caching).\n\n​Message Broker/Task Layer\nThis layer orchestrates asynchronous communications and task management, ensuring smooth data flow and efficient task execution.\n\nTech Stack: RabbitMQ (Message Broker), Celery (Task Management).\n\n​Infrastructure Layer\nThe foundational layer. It houses the GPU Pool with hardware from our verified partners. Orchestration tools manage deployments, while Execution/ML Tasks handle computations and machine learning operations. Additionally, it provides Data Storage solutions. GPU performance is monitored using Nvidia-smi or NVIDIA DCGM.\n\nTech Stack:\n\nGPU/CPU Pool\nOrchestration: Kubernetes, Prefect, Apache Airflow\nExecution/ML Tasks: Ray, Ludwig, Pytorch, Keras, TensorFlow, Pandas\nData Storage: Amazon S3, Hadoop HDFS\nContainerization: Docker\nMonitoring: Grafana, Datadog, Prometheus, NVIDIA DCGM\n\n​IO-SDK: The Powerhouse Behind io.net\nIO-SDK is our specialized fork of Ray, a core technology driving io.net’s capabilities. Embracing Ray’s native parallelism, IO-SDK effortlessly parallelizes Python functions, enabling dynamic task execution. Its in-memory storage ensures rapid data sharing between tasks, eliminating serialization delays. The dynamic auto-scaling feature means IO-SDK can quickly adapt to computational demands. Moreover, it is not just limited to Python; the language versatility and integration capabilities with leading ML frameworks like PyTorch and TensorFlow make it a robust and flexible choice. Whether on a single machine or a vast cloud platform, IO-SDK ensures io.net’s scalability and performance.\n\nTogether, these layers, powered by the mentioned tech stacks, form a robust and scalable architecture for the io.net Portal, ensuring it meets the demands of modern users.\nWas this page helpful?","tokens":793,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791258998158,"hash":"4e65ff4e7cff32499ffb8800ff1771a42c9632bb"}
{"url":"https://gov.optimism.io/c/88-category/88","domain":"gov.optimism.io","title":"Latest Proposals 📃 topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Proposals 📃\n\n Proposals 📃\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Proposals category\n\n Proposals 📃\n\n Review drafts of governance proposals here.\n\n 0\n\n 69\n\n Jan 6\n\n Proposal to Align the OP Token with Superchain Success\n\n Proposals 📃\n\n season-9\n\n Proposal to Align OP Token with Superchain Success\nThis proposal was updated on 1/15/26 to reflect community feedback to split the original proposal into two separate proposals. \nExecutive Summary\n\nThis proposal would im…\n\n read more\n\n 36\n\n 4.3k\n\n 1d\n\n Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\n\n Proposals 📃\n\n Proposal Type: Rights Protections \nExecutive Summary\nThe Optimism Foundation is proposing to re-designate the unspent tokens in the User Airdrop allocation as a new allocation category, the Strategic Ecosystem Fund, prop…\n\n read more\n\n 12\n\n 1.3k\n\n 9d\n\n Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0\n\n Protocol Upgrade\n\n Proposal Type: Protocol Upgrade\nHi, I’m Andrea Federici, Senior Solutions Engineer at OP Labs. I prepared this proposal in collaboration with Adrian Sutton, Matt Solomon and Matthew Cruz from the OP Labs team. Neither OP…\n\n read more\n\n 2\n\n 281\n\n 20d\n\n An Optimism Governance / Ecosystem Grant Proposal\n\n Proposals 📃\n\n Project Name: STRATEGIC POWER 360 \n\nProtocol Component: Public Light 3.0 (Algorithmic Governance & Auditing Layer) \nAuthor / Project Lead: Juan Carlos Farías Salazar \nLegal Jurisdiction: Wyoming, USA (DAO / DUNA Archit…\n\n read more\n\n 0\n\n 52\n\n 30d\n\n Maintenance Upgrade Proposal: Unichain ProxyAdmin Owner Transition to Standard Optimism Governance\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nExecutive Summary\nThis proposal transitions the ProxyAdmin Owner of Unichain Mainnet (chai…\n\n read more\n\n 0\n\n 56\n\n Sep 2\n\n Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nSummary\nThis proposal requests the Optimism Security Council return administrative ownersh…\n\n read more\n\n 0\n\n 55\n\n Sep 2\n\n Maintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nSummary\nThis proposal updates the recipient configured on Soneium’s four L2 fee vault predeploys (SequencerFeeVault, BaseFeeVault, L1FeeVault, OperatorFeeVault) from the current treasu…\n\n read more\n\n 1\n\n 117\n\n Aug 23\n\n Collective Year 4 Budget Update and Year 5 Budget Outlook\n\n Foundation Budgets\n\n Summary\nYear 4 (May 2025 to April 2026) was a year of focus and fiscal discipline. The Collective committed roughly 150M OP of new commitments across Season 8 and Season 9, about one third less than the 229.92M OP commit…\n\n read more\n\n 2\n\n 441\n\n Aug 7\n\n Maintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer Rotation\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nVoting Cycle Type: Off-cycle. Per the OPerating Manual, Maintenance Upgrade Proposals proceed directly to on-chain voting under optimistic approval, with a one-week veto period and a 2…\n\n read more\n\n 0\n\n 97\n\n Jul 22\n\n Maintenance Upgrade: Swell Ownership Transfer to AltLayer\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nExecutive Summary\nThis proposal requests the Optimism Security Council execute the return …\n\n read more\n\n 1\n\n 113\n\n Jul 21\n\n Optimism Security Council Operating Budget for Seasons 10 and 11\n\n Proposals 📃\n\n OPSC Operating Budget for Seasons 10 and 11\nProposed Lead: alisha.eth \nProposed Operating Budget: 5,040,000 OP \nContact Info: DM @Alisha on the forum \nCouncil Charter\nLink to existing Security Council Charter on GitHub. \n…\n\n read more\n\n 8\n\n 228\n\n Jul 18\n\n Sequencer ETH Management: 12-Month Renewal and Treasury Optimization\n\n Proposals 📃\n\n Proposal Type: Sequencer ETH: Passive Management (see Operating Manual)\nNote: Yield estimates are subject to change based on market conditions and other factors. Estimates in this proposal are as of writing. \n\nExecutive …\n\n read more\n\n 1\n\n 239\n\n Jul 15\n\n Operating Manual Update Proposal\n\n Proposals 📃\n\n The Optimism Foundation proposes the following changes to the Operating Manual: Operating Manual v2.0.0 by JSeiferth · Pull Request #70 · ethereum-optimism/OPerating-manual · GitHub \nThe changes proposed are summarized b…\n\n read more\n\n 1\n\n 128\n\n Jul 15\n\n Council Dissolution Proposal: Dissolve the Grants Council\n\n Proposals 📃\n\n As outlined in the Operating Manual, a persistent Council is expected to continue into the next Season unless a Dissolution proposal is approved. As outlined in Guide to Season 9, the Foundation is proposing the dissolut…\n\n read more\n\n 5\n\n 279\n\n Jul 15\n\n Council Dissolution Proposal: Dissolve the Developer Advisory Board\n\n Proposals 📃\n\n As outlined in the Operating Manual, a persistent Council or Board is expected to continue into the next Season unless a Dissolution proposal is approved. The Foundation is proposing the dissolution of the Developer Advi…\n\n read more\n\n 1\n\n 132\n\n Jul 15\n\n Council Dissolution Proposal: Dissolve the Milestones and Metrics Council\n\n Proposals 📃\n\n As outlined in the Operating Manual, a persistent Council is expected to continue into the next Season unless a Dissolution proposal is approved. As outlined in Guide to Season 9, the Foundation is proposing the dissolut…\n\n read more\n\n 1\n\n 141\n\n Jul 15\n\n Upgrade 19b — Karst Hardfork\n\n Technical Proposals\n\n Proposal Type: Protocol Upgrade\nVoting Cycle Type: off-cycle\nHi, I’m Matthew Cruz, Engineering Manager of the Solutions team at OP Labs. I have reviewed this proposal with: Josh Klopfenstein, Paul Dowman, and Andrea Fede…\n\n read more\n\n 3\n\n 284\n\n Jun 18\n\n [Research] Post-Quantum Cryptography (PQC) Latency Benchmarks on OP Stack Architecture\n\n Technical Proposals\n\n Hi OP Stack Community and Core Devs, \nAs the transition toward Post-Quantum Cryptography (PQC) becomes an operational necessity across L1/L2/L3 infrastructures, the primary bottleneck remains execution overhead. Introduc…\n\n read more\n\n 6\n\n 153\n\n Jun 14\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment\n\n Protocol Upgrade\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment\nProposal Type: Protocol Upgrade\nVoting Cycle: Cycle #52 \nExecutive Summary\nThis proposal requests approval for a time-boxed transaction-ordering experiment on OP…\n\n read more\n\n 1\n\n 276\n\n Apr 16\n\n Maintanance Upgrade Proposal 18a: Arena-Z Chain Servicer Migration\n\n Technical Proposals\n\n season-9\n\n Proposal Title: Arena-Z Chain Servicer Migration\nProposal Type: Maintenance Upgrade\nVoting Cycle Type: Off-cycle\n\nExecutive Summary\nThis Maintenance Upgrade Proposal requests the Optimism Security Council to execute two …\n\n read more\n\n 0\n\n 185\n\n Mar 13\n\n Upgrade 18 - Custom Gas Token v2 and Kona Proofs\n\n Proposals 📃\n\n Proposal Type: Protocol Upgrade \nHi I’m Paul, an Engineering Manager at OP Labs and core contributor of the OP Stack. I reviewed this proposal in collaboration with Sanjana Mehta from the OP Labs Team. \nThe following pro…\n\n read more\n\n 2\n\n 318\n\n Jan 28\n\n Proposal to integrate “Quantum Optimism: Building the Clean Internet with Aurora, Atlas & 445 Qubits”\n\n Proposals 📃\n\n Quantum-Secured Internet Infrastructure: A Proposal for Optimism Collective \nBuilding the Next Generation of Web3 with Quantum Physics + Blockchain\nSubmitted by: Nichole Christie (NicheAI) \nDate: J…\n\n read more\n\n 0\n\n 55\n\n Jan 13\n\n Upgrade 17 - Jovian Hardfork and Fusaka Readiness\n\n Technical Proposals\n\n Proposal Title: Upgrade 17 Proposal: Jovian Hardfork and Fusaka Readiness \nProposal Type: Protocol Upgrade \nThis proposal will run off cycle \nHi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP S…\n\n read more\n\n 3\n\n 934\n\n Jan 1\n\n Integrating LUXBIN: Quantum-Classical Hybrid Cryptography for Optimism’s Future\n\n Technical Proposals\n\n Hey Optimism Collective! \nMy name is Nichole Christie I a member who’s been inspired by \nOptimism's mission to scale Ethereum sustainably and build a more open,\n\ndecentralized world. I've been working on a …\n\n read more\n\n 0\n\n 56\n\n Dec 2025\n\n Disclosing two fault proof system vulnerabilities\n\n Technical Proposals\n\n Summary\n\nWe discovered and fixed two medium severity vulnerabilities impacting OP Stack chains that run a permissionless fault proof system. \n\nNeither were exploited on any OP Stack chain. \n\nBoth issues were fixed in …\n\n read more\n\n 0\n\n 222\n\n Dec 2025\n\n [deprecated] Upgrade 17 Proposal: Jovian Hardfork\n\n Technical Proposals\n\n This proposal has been deprecated. \n\nProposal Title: Upgrade 17 Proposal: Jovian Hardfork \nProposal Type: Protocol Upgrade \nThis proposal will go to vote during voting cycle 44 \nHi I’m George, a Protocol Engineer at OP …\n\n read more\n\n 2\n\n 329\n\n Nov 2025\n\n Governor Upgrade Proposal: Onchain Controls MVP\n\n Technical Proposals\n\n Proposal Title: Governor Upgrade Proposal: Onchain Controls MVP \nProposal Type: Governor Upgrade \nThis proposal will go to vote during voting cycle 44 \nExecutive Summary\nThis proposal introduces the Onchain Controls MVP,…\n\n read more\n\n 0\n\n 204\n\n Oct 2025\n\n An update to OP Labs recommendation for signing OPCM upgrade transactions\n\n Technical Proposals\n\n Hi, I’m maurelian, a member of the EVM Safety team at OP Labs. \nThose familiar with the process of executing upgrades to the Optimism Superchain will know just how deeply we go into the process of verifying the expected …\n\n read more\n\n 1\n\n 129\n\n Oct 2025\n\n Proposal Preview: Operator Fee\n\n Technical Proposals\n\n Proposal Title: Operator Fee\nProposal Type: Protocol Upgrade\nExecutive Summary\nThe current fee formula for the OP Stack presents challenges for variants of the OP Stack that leverage Alt-DA, validity proving with ZK or a…\n\n read more\n\n 1\n\n 322\n\n Sep 2025","tokens":2534,"squid":"ink-governance","role":"Council Listener","at":1791259001130,"hash":"c36909e52ecc4e0b677f6391c03bb063af422641"}
{"url":"https://docs.openzeppelin.com/ecosystem-adapters","domain":"docs.openzeppelin.com","title":"Ecosystem Adapters | OpenZeppelin Docs","text":"Ecosystem AdaptersOpen in ClaudeOpenZeppelin Ecosystem Adapters are a set of modular, chain-specific integration packages that let applications interact with any supported blockchain through a single, unified interface. Built on 13 composable capability interfaces organized in 3 tiers, each adapter encapsulates contract loading, type mapping, transaction execution, wallet connection, and network configuration in one place, while keeping consuming applications completely chain-agnostic.\nSource code: The adapters are open-source. Browse the implementation, open issues, and contribute at github.com/OpenZeppelin/openzeppelin-adapters.\nArchitectureUnderstand the capability-based architecture: tiers, profiles, and the runtime lifecycle.Getting StartedInstall adapters, configure profiles, and run your first cross-chain interaction.Supported EcosystemsExplore the production-ready EVM, Stellar, Polkadot, and Midnight adapters.Building an AdapterStep-by-step guide to implementing a new adapter for your blockchain.\nWhy Adapters?\nBuilding cross-chain tooling traditionally forces developers into one of two traps: a monolithic abstraction that leaks chain details, or per-chain forks that drift apart over time. Adapters solve this with a capability-based decomposition. Each chain implements only the interfaces it supports, and consuming applications pull in only what they need.\n\nKey Design Principles\n\nPay for what you use. Tier 1 capabilities are stateless and never pull in wallet SDKs or RPC clients. Import addressing and you get only address validation; nothing else is bundled.\nProfiles simplify consumption. Five pre-composed profiles (Declarative, Viewer, Transactor, Composer, Operator) match common application archetypes so you don't have to assemble capabilities manually.\nAdapters own their chains. All chain-specific logic (ABI parsing, Soroban type mapping, ZK proof orchestration) stays inside the adapter package. The consuming application never touches it.\nRuntime lifecycle is explicit. Runtimes are immutable and network-scoped. Switching networks means disposing the old runtime and creating a new one. There are no hidden state mutations.\n\nPackages\nPackageDescriptionStatus@openzeppelin/adapter-evmEthereum, Polygon, and EVM-compatible chainsProduction@openzeppelin/adapter-stellarStellar / SorobanProduction@openzeppelin/adapter-polkadotPolkadot Hub, Moonbeam (EVM path)Production@openzeppelin/adapter-midnightMidnight Network (ZK artifacts, Lace wallet)Production@openzeppelin/adapter-solanaSolana (scaffolding)In Progress@openzeppelin/adapter-evm-coreShared EVM capability implementations (internal)Internal@openzeppelin/adapter-runtime-utilsProfile composition and lifecycle utilities (internal)Internal@openzeppelin/adapters-viteShared Vite/Vitest build integrationUtility\nWho Uses Adapters?\nAdapters are consumed by several OpenZeppelin products:\n\nUI Builder: full-featured smart contract interaction UI\nOpenZeppelin UI: shared UI components and React integration\nUIKit example app (live): hosted demo of OpenZeppelin UI with ecosystem adapters\nRole Manager: role and permission management tool\nRWA Wizard: real-world asset token generation\n\nAny TypeScript application that needs chain-agnostic blockchain interaction can use adapters directly.WebAuthn Smart AccountsPrevious PageArchitectureNext PageOn this pageWhy Adapters?Key Design PrinciplesPackagesWho Uses Adapters?","tokens":852,"squid":"ink-security_audits","role":"Sentinel","at":1791259004783,"hash":"57deb334d6f391af6149feacdde7ac9311b0c170"}
{"url":"https://gov.optimism.io/t/re-designating-the-user-airdrop-allocation-as-the-strategic-ecosystem-fund/10797/13","domain":"gov.optimism.io","title":"Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund - Proposals 📃 - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Proposals 📃\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 7\n min\n\n Aug 6\n\n 13 / 13\n\n Sep 26\n\n 9d ago\n\n post by system on Aug 6\n\n post by MconnectDAO on Aug 7\n\n 9 days later\n\n post by Luckyhooman.eth on Aug 16\n\n post by 0xhayder on Aug 16\n\n post by OPUser on Aug 16\n\n post by Manugotsuka on Aug 18\n\n post by polynya on Aug 19\n\n post by JulianCross on Aug 19\n\n post by tikaipo on Aug 23\n\n post by system on Aug 24\n\n system\n\n The proposal to re-designate the airdrop allocation as the Strategic Ecosystem Fund has passed. Thank you to everyone who engaged and shared feedback on the proposal. The sharpest criticism in this thread was about accountability, not strategy, and that feedback has been heard.\nThe mandate is unchanged from the proposal: grow OP Mainnet and OP Enterprise adoption, including partnership deals that bring chains, protocols, institutions, and infrastructure to the OP Stack; incentives that deepen onchain activity and liquidity on OP Mainnet; and deals that expand the OP Stack’s reach with institutions and top-tier brands. We’re measuring the success of token deployment against two numbers: OP Mainnet TVL and OP Enterprise customer growth.\nSeveral of you asked for more public accountability on how these tokens are spent. Disclosing terms of individual deals weakens our negotiating position, and puts Optimism at a competitive disadvantage. Private terms do not mean unaccounted deployment. We will continue reporting cumulative deployment, and its impact, through the annual Collective budget report, as committed in the proposal.\nThe Strategic Ecosystem Fund aims to build on the success of recent partnerships, such as Ether.fi, who migrated $220M in TVL and 70,000+ active cards to OP Mainnet. That TVL now stands at $347M. In August, Ether.fi moved its lending backend onto a dedicated Aave V4 instance on OP Mainnet, now live and targeting $500M in lending capacity as it scales past the in-house system it outgrew. Active cardholders have passed 100,000. Per a16z’s latest data on crypto card spend, Optimism now carries roughly 29% of crypto card settlement volume, the largest share of any chain tracked, and Ether.fi is a significant part of why. The Strategic Ecosystem Fund will enable the Optimism Foundation to support more partnerships of this kind.\n\n post by Maplecccoin on Aug 24\n\n Maplecccoin\n\n I understand the strategic logic, but I think the community concern is also valid. User airdrops were not only a distribution tool; they were part of the social expectation that real users would continue to have a direct path into the Collective.\nIf the allocation is moved toward ecosystem and enterprise growth, I would want to see very clear reporting on what kind of users or partners are being brought in. For example, if growth efforts target fintechs, exchanges, or platforms like BYDFi, the Collective should be able to measure whether that actually brings retained on-chain users to OP Mainnet, not only partnership announcements.\nThe distinction between short-term activity, institutional integration, and long-term public network usage needs to be very transparent.\n\n post by Anzus_GemWallet on Aug 24\n\n Anzus_GemWallet\n\n If the allocation moves away from user airdrops and toward strategic ecosystem development, how will ordinary user adoption remain visible in the fund’s success criteria?\nInstitutional partnerships may increase transaction volume or infrastructure adoption without necessarily showing whether independent users are adopting self-custody or returning to applications regularly.\nCould reporting distinguish enterprise-driven activity from retained individual users and repeat application usage? I’m not arguing that airdrops should continue, but I think user adoption should remain a measurable outcome.\n\n 1 month later\n\n post by Yael-S on Sep 27\n\n Yael-S\n\n Hi, I’m a student researching Optimism governance. Following up on the transparency questions raised here: now that the proposal has passed, has the Foundation shared how allocations from the Strategic Ecosystem Fund will be reported, and where they can be tracked?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Treasury Appropriation Proposal: Foundation Year 2 Budget\n\n Foundation Budgets\n\n Summary\nThe Optimism Foundation’s future operating budget of OP is subject to governance by the Token House. Each year, the Foundation can put forth a budget proposal and the Token House may approve or reject it. \nThe Fo…\n\n read more\n\n 22\n\n 8.2k\n\n Jul 2025\n\n Airdrop #2 Feedback Thread\n\n Feedback 💬\n\n We would love to hear your thoughts on airdrop #2! In order to keep the feedback in one place, please reply to this thread with your thoughts and suggestions. \nGood feedback includes: \n\nSuggestions for how to tune spam f…\n\n read more\n\n 34\n\n 3.4k\n\n Oct 2025\n\n [PROPOSED] [Airdrop #2: More segmentation of contributor rewards]\n\n ✨ General\n\n In the OP community governance, the rules for subsequent airdrops are an inescapable topic, and how to be as fair as possible is a very important consideration. Put forward the following suggestions, welcome to supplemen…\n\n read more\n\n 50\n\n 4.3k\n\n Aug 2023\n\n Did no one question the anomalies of Airdrop #2?\n\n ✨ General\n\n It is a surprise that Airdrop #2 is released so suddenly and airdropped directly to users, but it is also very intriguing! \n\nThe remaining airdrop amount of $OP is close to 600 million, and this time only 11 million will…\n\n read more\n\n 28\n\n 3.0k\n\n Feb 2023\n\n Users who sold the initial OP airdrop should become ineligible for all future airdrops\n\n ✨ General\n\n Have seen enough wallets collect the OP airdrop, swap it straight to Uniswap. \nThese accounts are not playing a constructive role in Optimism governance. Instead of contributing to governance, they are maximising for pro…\n\n read more\n\n 599\n\n 43.8k\n\n Jan 20","tokens":1499,"squid":"ink-governance","role":"Council Listener","at":1791259011458,"hash":"a17420324dc663806e3cda2cf6d2384fabdd2c25"}
{"url":"https://docs.pyth.network/price-feeds/pro/futures-terminology","domain":"docs.pyth.network","title":"Futures Terminology | Pyth Developer Hub","text":"Pyth ProFutures TerminologyUnderstanding futures feed ticker symbols and expiration dates on Pyth ProPyth Pro provides price feeds for futures feeds across multiple asset classes including commodities and more. This guide explains how to interpret futures ticker symbols.\nTicker Symbol Format\nFutures tickers on Pyth follow the standard format:\n[ROOT][MONTH][YEAR]\nFor example: WTIJ6 breaks down as:\n\nWTI = West Texas Intermediate (Crude Oil)\nJ = April (month code)\n6 = 2026 (last digit of year)\n\nMonth Codes\nFutures feeds use single-letter codes to represent expiration months:\nCodeMonthFJanuaryGFebruaryHMarchJAprilKMayMJuneNJulyQAugustUSeptemberVOctoberXNovemberZDecember\nWhy these letters? The letters skip I, L, O, P, R, S, W, and Y to avoid confusion with numbers (1, 0) and other abbreviations commonly used in trading.\nYear Codes\nThe year is represented by the last digit of the year:\n\n5 = 2025\n6 = 2026\n7 = 2027\n\nExamples\nCrude Oil (WTI)\nSymbolFeedExpirationWTIJ6WTI April 2026Apr 21, 2026WTIK6WTI May 2026May 19, 2026WTIM6WTI June 2026Jun 22, 2026\nBrent Crude Oil\nSymbolFeedExpirationBRENTK6Brent May 2026Mar 31, 2026BRENTM6Brent June 2026Apr 30, 2026BRENTN6Brent July 2026May 29, 2026\nCopper\nSymbolFeedExpirationCCH6Copper March 2026Mar 27, 2026CCK6Copper May 2026May 27, 2026CCN6Copper July 2026Jul 29, 2026\nNatural Gas\nSymbolFeedExpirationNGDJ6HH Natural Gas April 2026Apr 28, 2026NGDK6HH Natural Gas May 2026May 27, 2026NGDM6HH Natural Gas June 2026Jun 26, 2026\nLS Gasoil\nSymbolFeedExpirationGOJ6LS Gasoil April 2026Apr 10, 2026GOK6LS Gasoil May 2026May 12, 2026\nCorn\nSymbolFeedExpirationCOH6Corn March 2026Mar 13, 2026COK6Corn May 2026May 14, 2026CON6Corn July 2026Jul 14, 2026\nPyth Symbol Format\nOn Pyth, futures symbols include the asset class prefix. The table below lists all available futures assets:\nCommodities\nAssetSymbol RootExample SymbolWTI Crude OilWTICommodities.WTIJ6/USDBrent Crude OilBRENTCommodities.BRENTK6/USDHH Natural GasNGDCommodities.NGDJ6/USDLS GasoilGOCommodities.GOJ6/USDCopperCCCommodities.CCH6/USDPalladiumPDCommodities.PDH6/USDPlatinumPTCommodities.PTJ6/USDCornCOCommodities.COH6/USDSoybeanSOCommodities.SOK6/USDDutch TTF GasTGECommodities.TGEM6/EURWheatWHCommodities.WHK6/USD\nEquity Indices\nAssetSymbol RootExample SymbolE-mini S&P 500EMEquity.US.EMH6/USDE-mini Nasdaq 100NMEquity.US.NMH6/USDE-mini DowDMEquity.US.DMH6/USDNikkei 225 Dividend IndexNIDEquity.US.NIDH6/USDKOSPI 200KSEquity.KR.KSH6/KRWKOSDAQ 150KQEquity.KR.KQH6/KRWHang SengHKHEquity.HK.HKHH6/HKDFTSE China A50 IndexFCDEquity.US.FCDH6/USD\nChain Metadata\nEvery dated feed belongs to a chain: the family of feeds on the same underlying that differ only by expiration. The symbols API exposes three chain-level fields on each feed, with identical values across the whole chain. See Symbology & Reference Data for the full field definitions.\nFor the WTI chain (WTIV6, WTIX6, WTIZ6, ...):\n{\n \"symbol_chain_id\": \"WTI\",\n \"expiration_pattern\": [\n \"jan\",\n \"feb\",\n \"mar\",\n \"apr\",\n \"may\",\n \"jun\",\n \"jul\",\n \"aug\",\n \"sep\",\n \"oct\",\n \"nov\",\n \"dec\"\n ],\n \"availability_pattern\": [\n \"F\",\n \"G\",\n \"H\",\n \"J\",\n \"K\",\n \"M\",\n \"N\",\n \"Q\",\n \"U\",\n \"V\",\n \"X\",\n \"Z\"\n ]\n}\nsymbol_chain_id is the bare symbol root (WTI), not a fully-qualified Pyth symbol. expiration_pattern is the chain's full annual expiration cycle, written as month abbreviations; availability_pattern is the subset Pyth prices, written as the month codes above.\nValues are per-chain. WTI expires monthly and Pyth prices every month, so both patterns cover all twelve. Copper (CC) also expires monthly, but its availability_pattern is [\"H\", \"K\", \"N\", \"U\", \"Z\"] — only the March, May, July, September, and December feeds are published.\nExpiration and Rollover\nFutures feeds expire on specific dates. When a feed approaches expiration:\n\nLiquidity shifts to the next feed month\nPrice feeds transition to the new front-month feed\nRollover dates vary by commodity — check the Symbology and Reference Data API for exact expiration dates, or see Symbology & Reference Data for the field definitions\n\nWhich feed months exist at all is given by the chain's expiration_pattern, and which of those Pyth publishes by its availability_pattern — see Chain Metadata above.\nExpiration Handling: Ensure your application handles feed rollovers gracefully. Monitor for feed transitions as feeds approach expiration.\nAdditional Resources\n\nSymbology & Reference Data — Field reference for the symbol metadata served by the symbols endpoint\nSymbology and Reference Data API — Full list of available futures feeds with expiration dates\nMarket Hours — Trading hours for futures markets\nMarket HoursTrading hours followed by Pyth price feeds across asset classesSymbology & Reference DataField-by-field reference for Pyth Pro symbol metadata: identifiers, classification, data quality, trading schedules, and futures expiration","tokens":1212,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259017640,"hash":"46a25c72a9c8fb813955a8c21300de7bd1cf6d36"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/1-1-1","domain":"anchor-lang.com","title":"1.1.1","text":"Anchor Project UpdatesRelease Notes1.1.1Anchor - Release Notes 1.1.1See the full\nCHANGELOG.\nHow to upgrade\nCommon steps\n\nUpdate Anchor crate(s) to 1.1.1.\n\nUpdate TS package(s) to 1.1.1.\n\nRecommended Solana Version\nThe recommended Solana version is 3.1.10, unchanged from 1.0.0.\n\nLang\nFix #[event_cpi] deprecation warnings\n#[event_cpi] was making use of deprecated AccountInfo accounts internally.\nThis has been updated to use the recommended UncheckedAccount instead, silencing the noisy warnings.\nRe-add the legacy IDL handlers\nIn 1.0.0, we changed the mechanism for storing the IDL on chain from automatically generated instruction handlers to the Solana Program Metadata Program.\nThis resulted in large binary size and security wins, but caused breakage for developers relying on this mechanism.\nThis functionality has been re-added. You can opt in with:\n#[program(legacy_idl)]\npub mod my_program {\n // ...\n}\nAnd interact with it using anchor legacy-idl.\nCLI\nRemove hard build error with mismatched keys\nPreviously, anchor build verified that the program's private keypair matched the declare_id pubkey.\nThis was a pain point for developers collaborating on Anchor projects, as private keys would typically not be checked into version control.\nThis has been made into a soft error; the warning is still printed, but does not block builds.\n--ignore-keys can still be used to silence this.\nMore reliable handling of relative paths\nThe CLI now performs more reliable normalization of input paths.\nThis means that relative paths (including when invoking anchor in a subdirectory) will be handled more predictably.\nOptimized build times\nPreviously, the CLI built programs in a naive order, which resulted in bottlenecking on certain dependencies.\nThe CLI will now attempt to be smarter when building packages, which can provide compile-time speedups of up to 50%.Previous1.1.2Next1.0.3On this pageHow to upgradeCommon stepsRecommended Solana VersionLangFix #[event_cpi] deprecation warningsRe-add the legacy IDL handlersCLIRemove hard build error with mismatched keysMore reliable handling of relative pathsOptimized build timesEdit on GitHub","tokens":535,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259024870,"hash":"f686a93b584a7f4bc3040dd3bcf87b094d138196"}
{"url":"https://docs.pyth.network/price-feeds/pro/market-hours","domain":"docs.pyth.network","title":"Market Hours | Pyth Developer Hub","text":"Pyth ProMarket HoursTrading hours followed by Pyth price feeds across asset classesPyth price feeds follow the traditional market hours of each asset classes and will be available at the following hours:\nAsset ClassOpening HoursExceptionsCrypto24/7No market closeUS EquitiesEvery weekday from 9.30AM ET to 4PM ETMarkets are closed on weekends, and follow NYSE Holidays & Trading HoursUS Equities Pre MarketEvery weekday from 4AM ET to 9.30AM ETMarkets are closed on weekends, and follow NYSE Holidays & Trading HoursUS Equities Post MarketEvery weekday from 4PM ET to 8PM ETMarkets are closed on weekends, and follow NYSE Holidays & Trading HoursUS Equities OvernightEvery Sunday to Thursday from 8PM ET to 4AM ET (the following calendar day)Overnight markets are closed on Friday to Saturday and follow Blue Ocean ATS Holidays & Trading HoursEU EquitiesParis, Amsterdam, Ireland: Every weekday from 9AM CET to 5.30PM CETMarkets are closed on weekends, and follow Euronext Holidays & Trading HoursUK EquitiesEvery weekday from 8AM UK time to 4.30PM UK timeMarkets are closed on weekends, and follow LSE Holidays & Trading HoursDE EquitiesEvery weekday from 9AM to 5.30PM CETMarkets are closed on weekends, and follow Xetra Holidays & Trading HoursHK EquitiesEvery weekday from 9.30AM to 12PM & 1PM to 4PM HKTMarkets are closed on weekends, and follow HKEX Holidays & Trading HoursCN EquitiesEvery weekday from 9.30AM to 11.30AM & 1PM to 2:57PM CSTMarkets are closed on weekends, and follow SSE Holidays & Trading HoursJP EquitiesEvery weekday from 9AM to 11.30AM & 12.30PM to 3:30PM JSTMarkets are closed on weekends, and follow JPX Holidays & Trading HoursFXFrom Sunday 5PM ET to Friday 5PM ETTrading continues during most US holidaysEmerging Markets FXFrom Sunday 6PM ET to Friday 5PM ET. For USDBRL, USDCOP, USDCLP and USDPEN, please refer to the EM FX Market Hours GuideSpot EM FX liquidity can be significantly limited at the start of the trading week, outside local market trading hours, and during local holidays, which can lead to wider confidence intervals. Pyth EM FX currencies: INR, IDR, PHP, KRW, TWD, CNH, TRY, ZAR, MXN, BRL, COP, CLP, PENMetalsFrom Sunday 6PM ET to Friday 5PM ETDaily maintenance window applies from 5PM ET to 6PM ET, Monday to Thursday. Spot gold and silver trading also follow CME holiday closuresRatesEvery weekday from 8AM ET to 5PM ETMarkets are closed on weekends, and follow NYSE Holidays & Trading HoursReference Rates24/7Follow Federal Reserve Bank of New York HolidaysCommoditiesWTI: From Sunday 6PM ET to Friday 5PM ETDaily maintenance window applies from 5PM ET to 6PM ET and follow CME HolidaysCommoditiesBRENT: From Sunday 6PM ET to Friday 6PM ETDaily maintenance window applies from 6PM ET to 8PM ET, Monday to Thursday and follow ICE HolidaysCommoditiesUKOILSPOT CFD: From Monday 1AM GMT to Friday 9:45PM GMTDaily maintenance window applies from 10PM GMT to 1AM GMT, Monday to Friday and follow FXCM HolidaysCommoditiesUSOILSPOT CFD: From Sunday 11PM GMT to Friday 9:45PM GMTDaily maintenance window applies from 10PM GMT to 11PM GMT, Monday to Friday and follow FXCM HolidaysContract AddressesList of Pyth Pro (Lazer) contract addresses on supported networksFutures TerminologyUnderstanding futures feed ticker symbols and expiration dates on Pyth Pro","tokens":825,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259036776,"hash":"39ed4f298b8c3f42ed66a542c63cbd5f08342b28"}
{"url":"https://docs.pyth.network/price-feeds/pro/symbology-reference","domain":"docs.pyth.network","title":"Symbology & Reference Data | Pyth Developer Hub","text":"Pyth ProSymbology & Reference DataField-by-field reference for Pyth Pro symbol metadata: identifiers, classification, data quality, trading schedules, and futures expirationPyth Pro publishes reference data describing every feed it offers: identifiers, classification, data-quality parameters, trading schedules, and (for derivatives) expiration metadata. This data is distinct from the real-time price payload: it describes what a feed is, not its current value.\nReference data is served by the Symbology & Reference Data API:\nGET https://pyth.dourolabs.app/v1/symbols\nThe endpoint returns one JSON object per feed. This page documents every field on that object. For the request schema and query parameters for filtering (for example by asset_type or instrument_type), see the interactive API reference.\nExample response\nEvery feed is returned as a single JSON object with the same top-level shape. The tabs below show feeds that populate different optional fields, depending on asset class and instrument type.\nBKNG, a US equity with regular, pre_market, post_market, and over_night sessions, a nasdaq_symbol, and a corporate_actions stock split:{\n \"pyth_lazer_id\": 992,\n \"name\": \"BKNG\",\n \"symbol\": \"Equity.US.BKNG/USD\",\n \"description\": \"BOOKING HOLDINGS INC / US DOLLAR\",\n \"asset_type\": \"equity\",\n \"instrument_type\": \"spot\",\n \"exponent\": -5,\n \"cmc_id\": null,\n \"interval\": null,\n \"min_publishers\": 3,\n \"min_channel\": \"fixed_rate@200ms\",\n \"state\": \"stable\",\n \"schedule\": \"America/New_York;0930-1600,0930-1600,0930-1600,0930-1600,0930-1600,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1127/0930-1300,1224/0930-1300,1225/C\",\n \"market_session_schedule\": {\n \"regular\": \"America/New_York;0930-1600,0930-1600,0930-1600,0930-1600,0930-1600,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1127/0930-1300,1224/0930-1300,1225/C\",\n \"pre_market\": \"America/New_York;0400-0930,0400-0930,0400-0930,0400-0930,0400-0930,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1225/C\",\n \"post_market\": \"America/New_York;1600-2000,1600-2000,1600-2000,1600-2000,1600-2000,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1225/C\",\n \"over_night\": \"America/New_York;0000-0400&2000-2400,0000-0400&2000-2400,0000-0400&2000-2400,0000-0400&2000-2400,0000-0400,C,2000-2400;0118/C,0119/2000-2400,0215/C,0216/2000-2400,0402/0000-0400,0403/C,0524/C,0525/2000-2400,0618/0000-0400,0619/C,0702/0000-0400,0703/C,0906/C,0907/2000-2400,1125/0000-0400,1126/2000-2400,1224/0000-0400,1225/C,1231/0000-0400,0101/C\"\n },\n \"market_sessions\": {\n \"regular\": {\n \"min_pub\": 3,\n \"schedule\": \"America/New_York;0930-1600,0930-1600,0930-1600,0930-1600,0930-1600,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1127/0930-1300,1224/0930-1300,1225/C\",\n \"state\": \"stable\"\n },\n \"pre_market\": {\n \"min_pub\": 2,\n \"schedule\": \"America/New_York;0400-0930,0400-0930,0400-0930,0400-0930,0400-0930,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1225/C\",\n \"state\": \"stable\"\n },\n \"post_market\": {\n \"min_pub\": 2,\n \"schedule\": \"America/New_York;1600-2000,1600-2000,1600-2000,1600-2000,1600-2000,C,C;0101/C,0119/C,0216/C,0403/C,0525/C,0619/C,0703/C,0907/C,1126/C,1225/C\",\n \"state\": \"stable\"\n },\n \"over_night\": {\n \"min_pub\": 2,\n \"schedule\": \"America/New_York;0000-0400&2000-2400,0000-0400&2000-2400,0000-0400&2000-2400,0000-0400&2000-2400,0000-0400,C,2000-2400;0118/C,0119/2000-2400,0215/C,0216/2000-2400,0402/0000-0400,0403/C,0524/C,0525/2000-2400,0618/0000-0400,0619/C,0702/0000-0400,0703/C,0906/C,0907/2000-2400,1125/0000-0400,1126/2000-2400,1224/0000-0400,1225/C,1231/0000-0400,0101/C\",\n \"state\": \"stable\"\n }\n },\n \"hermes_id\": \"e90b679a7e4ca0d591abb634959d38a535c2036c6b121c520a82cff111ff7d12\",\n \"nasdaq_symbol\": \"BKNG\",\n \"quote_currency\": \"USD\",\n \"corporate_actions\": [\n {\n \"event_type\": \"SPLIT\",\n \"activation\": {\n \"us_equity_ex_date\": {\n \"ex_date\": \"2026-04-06\"\n }\n },\n \"adjustment_factor_numerator\": \"25\",\n \"adjustment_factor_denominator\": \"1\"\n }\n ],\n \"groups\": []\n}\nEvery field is documented below.\nField reference\nField invariantsUseful guarantees when mapping these fields in your own systems:\nname is not guaranteed to be unique; the same short name can appear on more than one feed.\nsymbol is unique, but in rare cases it can change without notice. Use pyth_lazer_id as the stable key for external mappings.\nasset_type and instrument_type are open enums whose set of values can grow over time, so handle unknown values gracefully.\n\nIdentity & naming\nFieldTypeDescriptionpyth_lazer_idu32Stable numeric identifier for the feed in Pyth Pro. Use it when subscribing to prices.namestringShort symbol name, e.g. BTCUSD. Dated futures suffix the family root with a month code and year digit, e.g. the EM (E-mini S&P 500) family becomes EMU6; see Futures Terminology.symbolstringFully-qualified Pyth symbol, e.g. Crypto.BTC/USD or Equity.US.EMU6/USD. Encodes asset class, optional region, root, and quote currency.descriptionstringHuman-readable description, e.g. BITCOIN / US DOLLAR.hermes_idstring?Hex feed ID used by Pyth Core / Hermes for the same underlying. null when the feed has no Pyth Core counterpart.nasdaq_symbolstring?Nasdaq ticker, for equities sourced via Nasdaq. null when not applicable.cmc_idinteger?CoinMarketCap ID, for crypto assets. null when not applicable.\nClassification\nFieldTypeDescriptionasset_typestringBroad asset class (open enum, may grow). Current values include crypto, equity, fx, commodity, metal, interest-rate, rates, crypto-index, crypto-redemption-rate, funding-rate, nav, kalshi.instrument_typestringInstrument form: spot, future, perp, rate, index, or nav. May be an empty string when unspecified.quote_currencystringCurrency the price is quoted in, e.g. USD, EUR, KRW, JPY.groupsstring[]Discovery/grouping tags, e.g. pyth-indices. Empty for most feeds.exchange_idu32?Numeric ID of the primary exchange the feed trades on. null when the feed has no exchange.\nPricing & data quality\nFieldTypeDescriptionexponenti16Decimal exponent: actual_price = mantissa × 10^exponent. Same meaning as in the price payload.min_publishersu16Minimum number of publishers required for the feed to produce a price.min_channelstringHighest-frequency channel the feed supports: real_time, fixed_rate@50ms, or fixed_rate@200ms. You can subscribe at this channel or any slower one.statestringLifecycle state: stable (live), coming_soon (announced, not yet publishing), or inactive (retired/expired).intervalstring?Funding interval for funding-rate feeds (instrument type rate), e.g. 8h. null otherwise.\nScheduling\nFieldTypeDescriptionschedulestringThe regular session's trading schedule, in the form TZ;<weekly>;<holidays>. Each day is open (O), closed (C), or a set of hour ranges (e.g. 0000-1700&1800-2400). Identical to market_session_schedule.regular.market_session_scheduleobjectA schedule string per session, keyed by session name (regular, pre_market, post_market, over_night).market_sessionsobjectThe full per-session configuration: each session carries its own schedule, min_pub, and state.\nThree schedule fields, three altitudesThese describe the same trading calendar at increasing detail:\nschedule: the regular session's schedule (identical to market_session_schedule.regular), not a union across sessions.\nmarket_session_schedule: a schedule string for each session the feed has (regular, pre_market, post_market, over_night).\nmarket_sessions: the richest form, carrying per-session schedule plus min_pub and state.\nThe price payload's marketSession field tells you which of these sessions is currently active for a given update.\nPick an example or paste a schedule string to decode it into market hours:\nCrypto spot (BTCUSD), 24/7US equity (BKNG), regular sessionUS equity (BKNG), overnight sessionCommodity future (CAZ6)TimezoneAmerica/New_YorkMondayOpen 24hTuesdayOpen 24hWednesdayOpen 24hThursdayOpen 24hFridayOpen 24hSaturdayOpen 24hSundayOpen 24h\nFutures\nexpiration_time describes an individual dated feed. The other three fields describe the chain that feed belongs to — the family of feeds measuring the same underlying at different expirations — and carry the same values on every feed in the chain.\nFieldTypeDescriptionexpiration_timestring?Expiration timestamp (RFC 3339) for a dated futures feed, e.g. 2026-12-15T13:30:00-05:00.symbol_chain_idstring?Root symbol for the chain of all the futures that measure the same underlying with different expiration times, e.g. CA for the cocoa chain that CAZ6 belongs to. Note this is the bare root, not a fully-qualified symbol. null for feeds that are not part of a futures chain.expiration_patternstring[]?The total set of expirations per a single year applicable to the chain, as lowercase three-letter month abbreviations, e.g. [\"mar\", \"may\", \"jul\", \"sep\", \"dec\"].availability_patternstring[]?The subset of expirations per single year already priced or expected to be priced by Pyth, as month codes, e.g. [\"H\", \"K\", \"N\", \"U\", \"Z\"].\nThe two patterns use different encodingsexpiration_pattern lists month abbreviations (mar), availability_pattern lists month codes (H). Normalize before comparing them. The two often differ in length as well as encoding: copper (CC) expires in all twelve months but Pyth prices only [\"H\", \"K\", \"N\", \"U\", \"Z\"].Chains with no fixed annual cycle — such as the LME 3-month feeds (Metal.AL3M/USD) — report [\"none\"] for both.\nCorporate actions\nFieldTypeDescriptioncorporate_actionsobject[]?Corporate actions on an equity feed. Each entry has an event_type (e.g. SPLIT), an activation block with the effective date (e.g. us_equity_ex_date.ex_date), and adjustment_factor_numerator / adjustment_factor_denominator. See the Equity example.\nAccessing the data\n\nSymbology & Reference Data API: GET /v1/symbols returns the full catalog.\nFilter to your entitlements: pass ?entitled_only=true to return only the symbols your API key is entitled to, instead of the full catalog.\nInteractive docs: explore the request schema and filtering parameters in the OpenAPI reference.\n\nRelated\n\nPrice Feed IDs: browsable table of every available feed.\nFutures Terminology: ticker format, month/year codes, and rollover.\nPayload Reference: the real-time price payload (distinct from reference data).\nFutures TerminologyUnderstanding futures feed ticker symbols and expiration dates on Pyth ProHow Pyth Pro WorksUnderstand the services that power Pyth Pro’s low-latency price delivery","tokens":2605,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259058286,"hash":"47253cc64ab5e2f9d6f6a84d584ebdf88895d309"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/1-0-0","domain":"anchor-lang.com","title":"1.0.0","text":"Anchor Project UpdatesRelease Notes1.0.0Anchor - Release Notes 1.0.01.0.0 is the first stable major release of Anchor. It ships a large number of\nbreaking changes designed to clean up long-standing technical debt, modernize\nthe toolchain, and establish a stable foundation going forward. We cover the most\nimportant changes below, but be sure to check out the full list of changes in\nthe\nCHANGELOG.\n\nHow to upgrade\nUsing AVM (recommended)\n\nUpdate avm itself before installing the new CLI. If your current avm\nsupports self-update, use:\navm self-update\nOtherwise, bootstrap using cargo install:\ncargo install avm --git https://github.com/otter-sec/anchor --locked\n\nUpdate anchor-cli:\navm install 1.0.0\n\nWithout AVM\nInstall anchor-cli directly:\ncargo install --git https://github.com/otter-sec/anchor --tag v1.0.0 anchor-cli --locked\nCommon steps\n\nUpdate Anchor crate(s) to 1.0.0.\n\nUpdate TS package(s). Note that the package has been renamed — see\nTypeScript package rename below.\n\nRecommended Solana Version\nThe recommended Solana version is 3.1.10.\nYou can install the newer tooling by running:\nsh -c \"$(curl -sSfL https://release.anza.xyz/v3.1.10/install)\"\n\nBreaking Changes\nTypeScript package rename\nThe TypeScript package has been moved from @coral-xyz/anchor to\n@anchor-lang/core:\nnpm install @anchor-lang/core\nUpdate every import in your project:\n- import * as anchor from \"@coral-xyz/anchor\";\n- import { Program } from \"@coral-xyz/anchor\";\n+ import * as anchor from \"@anchor-lang/core\";\n+ import { Program } from \"@anchor-lang/core\";\nIDL types that were previously imported from @coral-xyz/anchor/dist/cjs/idl\ncan now be imported directly from @anchor-lang/core:\n- import { Idl } from \"@coral-xyz/anchor/dist/cjs/idl\";\n+ import { Idl } from \"@anchor-lang/core\";\nSolana 3.0\nAnchor 1.0.0 targets Solana 3.x. If you are still on Solana 2.x you must\nupgrade your toolchain.\nSolana CLI dependency removed\nThe anchor CLI no longer depends on the external solana CLI binary. Native\nimplementations are now provided for the most common sub-commands: balance,\nairdrop, address, deploy, and others. This means the solana binary no\nlonger needs to be on your PATH for Anchor commands to work.\nanchor test / anchor localnet now use Surfpool by default\nSurfpool replaces the local validator as\nthe default backend for anchor test and anchor localnet. If you want to\nkeep using the solana-test-validator, pass --validator legacy.\nTo use the default anchor test or anchor localnet commands, Surfpool will need to be installed on your machine.\nCheck to see if you have Surfpool installed by running\nsurfpool --version\nThe lowest recommended Surfpool version for use with Anchor is v1.1.2.\nTo install Surfpool, follow the Surfpool installation instructions.\nDuplicate mutable accounts disallowed by default\nPassing the same mutable account twice in an instruction now produces a runtime\nerror by default. If you intentionally need duplicate mutable accounts, opt in\nwith the dup constraint:\n#[derive(Accounts)]\npub struct MyIx<'info> {\n #[account(mut)]\n pub account_a: Account<'info, MyData>,\n #[account(mut, dup)]\n pub account_b: Account<'info, MyData>,\n}\nLegacy IDL instructions replaced by Program Metadata\nThe on-chain IDL management instructions that Anchor has used since the\nbeginning have been removed and replaced with the new\nProgram Metadata Program (PMP).\nIDL uploads through anchor deploy and anchor idl commands work as before;\nonly the underlying mechanism has changed.\nThe program-id argument of anchor idl init and anchor idl upgrade is now\noptional — when omitted, the program ID is read from the address field of the\nIDL file itself.\nIf you are migrating an existing deployed program with IDL, you will need to\nclose existing IDL accounts before deploying the new program based on anchor\nv1.0.0 as this will remove the IDL management instructions. This also depends\non the previous v0.32.1 anchor cli.\nRemove program account info from CPI context\nThe program field in CpiContext previously held a redundant copy of the\nprogram AccountInfo. It has been removed:\n- CpiContext::new(ctx.accounts.token_program.to_account_info(), cpi_accounts)\n+ CpiContext::new(Token::id(), cpi_accounts)\ninterface-instructions feature removed\nThe interface-instructions feature flag and the #[interface] attribute have\nbeen removed. Use #[instruction(discriminator = <EXPR>)]! to specify custom\ndiscriminators.\nAnchor.toml cleanup\n\nThe [registry] section is no longer recognized and should be removed.\nThe program arch build options have been removed from the CLI.\n\n#[error_code] may only appear once per program\nHaving multiple #[error_code] blocks in a single program is now a\ncompile-time error.\nClient tx signing error no longer panics\nRequestBuilder::send (and friends) previously panicked when signing failed.\nIt now returns an Err instead.\n\nAVM\navm self-update\nOnce your installed avm is v1-capable, you can update it without going\nthrough cargo install:\navm self-update\nTo bootstrap to a version that supports this command, install via cargo:\ncargo install avm --git https://github.com/otter-sec/anchor --tag v1.0.0 --locked\nAdditionally, avm will passively warn you when it detects that a newer\nversion of itself is available.\nPre-release support\nAll avm commands (install, list, update) now understand pre-release\nversion labels:\navm install latest-pre-release\navm list --pre-release\navm update --pre-release\n\nCLI\nLifecycle hooks\nYou can now run shell commands at key points in the build/test/deploy\nlifecycle by adding a [hooks] section to your Anchor.toml:\n[hooks]\npre_build = \"echo building...\"\npost_build = [\"echo done\", \"echo done again\"]\npre_test = \"some-setup-script\"\npost_deploy = \"some-notify-script\"\nSupported hooks: pre_build, post_build, pre_test, post_test,\npre_deploy, post_deploy.\nLiteSVM test template is now the default\nanchor init now generates a LiteSVM\ntest template by default, replacing the previous TypeScript based default. You\ncan still pick a different template explicitly:\nanchor init my-program --test-template mollusk\nanchor init my-program --test-template mocha\nProgram ID mismatch check\nanchor build now checks that the program ID declared in your source code\nmatches the public key in the program's keypair file and emits an error if\nthey differ. This check is skipped during anchor test where ephemeral\nkeypairs are common. You can skip this check during builds with\nanchor build --ignore-keys.\n--install-agent-skills\nPass --install-agent-skills to anchor init to automatically install\nSolana agent AI skills into the new workspace.\nlogin command removed\nanchor login has been removed along with the [registry] section of\nAnchor.toml.\n\nLang\nMigration<'info, From, To> account type\nThe new Migration type makes it straightforward to migrate accounts between\ntwo different data layouts in a single instruction:\n#[derive(Accounts)]\npub struct MigrateMyAccount<'info> {\n #[account(mut)]\n pub my_account: Migration<'info, OldAccount, NewAccount>,\n}\nThe account is deserialized as From, and serialized back as To on exit.\ndeclare_program! improvements\nSeveral renames apply to the code generated by declare_program!:\nutils module renamed to parsers, and the parse methods renamed from\ntry_from_bytes to parse:\n- my_program::utils::Account::try_from_bytes(&data)?;\n+ my_program::parsers::Account::parse(&data)?;\n\n- my_program::utils::Event::try_from_bytes(&data)?;\n+ my_program::parsers::Event::parse(&data)?;\nerrors module renamed to error. ProgramError renamed to\n<ProgramName>Error, where <ProgramName> is the PascalCase name of the\ndeclared program:\n- my_program::errors::ProgramError\n+ my_program::error::MyProgramError\ndeclare_program! also now generates a typed instruction parser alongside the\nCPI helpers. Use my_program::parsers::Instruction::parse with a\nsolana_instruction::Instruction to decode any instruction belonging to the\nprogram.\nComposite (non-instruction) account structs used multiple times within a\nprogram previously caused duplicate definitions or incorrect instruction name\nderivation in the generated code. Both issues are now fixed: each composite\naccount definition is guaranteed to be unique, and instruction names that would\ncollide have a number appended until a unique name is found.\nError generation has also been improved: declare_program! previously\ninterfered with the IDL error module generation of the declaring program.\nPrograms that use declare_program! alongside their own #[error_code] block\nnow produce correct error code definitions.\nUse declare_program! with only anchor_client\nIt is no longer necessary to pull in anchor_lang just to use\ndeclare_program! in a client-side context. Adding anchor_client as a\ndependency is sufficient.\nRemove lifetime definitions from Context\nThree redundant lifetime parameters have been removed from Context. Most\nprograms will not be affected; if you referenced these lifetimes explicitly\nyou will need to update the annotations.\n// Before (v0.32)\npub fn my_handler<'a, 'b, 'c, 'info>(\n ctx: Context<'a, 'b, 'c, 'info, MyAccounts<'info>>,\n) -> Result<()> { ... }\n\n// After (v1)\npub fn my_handler<'info>(ctx: Context<'info, MyAccounts<'info>>) -> Result<()> { ... }\n// or simply (when the lifetime is inferred)\npub fn my_handler(ctx: Context<MyAccounts>) -> Result<()> { ... }\nDeprecate AccountInfo in Accounts macro\nUsing AccountInfo directly inside an #[derive(Accounts)] struct now emits\na compile-time warning. Prefer UncheckedAccount or a more specific account\ntype.\nRelaxed PDA seed syntax\nThe seed expressions accepted inside seeds = [...] constraints are now more\nflexible and support a broader set of Rust expressions. Note that more complex\nseed expressions reduce the likelihood of seeds being representable in the IDL\nand of successful automatic account resolution on the client side.\nOwner check on account reload\nCalling .reload() on an Account now re-validates the owner, the same as\nthe initial load.\nGeneric Program type\nProgram<'info> can now be used without a type parameter for executable-only\nvalidation when the concrete program type is not known statically:\npub program: Program<'info>,\nOwners exported from prelude\nanchor_lang::Owners is now re-exported from the prelude, so you no\nlonger need a separate use statement for it.\nBorsh upgraded to 1.5.7\nBoth the Rust and TypeScript Borsh implementations have been updated to\n1.5.7. Make sure your borsh dependency in Cargo.toml is compatible.\n#[instruction(..)] argument validation\nThe compiler now enforces that the types and count of arguments in\n#[instruction(..)] match the corresponding instruction handler signature,\ncatching mismatches that were previously silent.\n\nIDL\nUnsupported field types produce a hard error\nPreviously, defined types containing unsupported fields (e.g. tuple types) were\nsilently omitted from the generated IDL. They now produce a compile-time error:\nerror: Unsupported type\n --> programs/name/src/lib.rs:37:8\n |\n37 | x: (u32, u32),\n | ^^^^^^^^^^\nIf you were relying on silent omission, you will need to refactor those fields\ninto supported types before building.\nFull path account names supported in IDL generation\nThe IDL builder previously rejected account types that shared a short name with\nanother type in a different module (e.g. program::module::Account conflicting\nwith other::Account). The conflicting account names check has been removed,\nallowing full path account names to be used without errors.\naddress constraint resolves constants with numbers in their names\nThe address constraint previously failed to resolve constants whose\nidentifiers contained numbers (e.g. MY_PROGRAM_V2_ID). This is now fixed.\nserde_json is now optional\nThe serde_json dependency of anchor-lang-idl is now behind an opt-in\nfeature flag, reducing compile times when JSON serialization is not needed.\nExternal accounts excluded from IDL\nAccounts defined in external programs (e.g. SPL token accounts referenced in\nyour IDL) are no longer included in the generated IDL's accounts array,\nkeeping the IDL focused on your own program's types.\nCustom error offset respected\nThe offset = N argument in #[error_code] is now correctly reflected in\nthe generated IDL, so the error codes in the IDL match what is emitted at\nruntime.\n\nTypeScript\nIDL fetching updated for PMP\nThe TypeScript client now fetches IDLs from the new Program Metadata Program\nstorage. Existing code using Program.fetchIdl continues to work without\nchanges.\n\nRust Client\nFnMut closures for event subscriptions\nprogram.on::<Event>(|event, slot| { ... }) now accepts FnMut closures,\nallowing you to capture mutable state from the surrounding scope.\nReduced re-exports from anchor-client\nanchor-client previously re-exported the entirety of solana-sdk, which\nmade it easy to discover types but pulled in a large dependency. It now only\nre-exports the types that are directly part of its public API. If you were\nrelying on transitive solana-sdk types through anchor-client, you will\nneed to add the relevant crates (solana-account, solana-pubkey, etc.) as\nexplicit dependencies.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous1.0.1Next0.32.2On this pageHow to upgradeUsing AVM (recommended)Without AVMCommon stepsRecommended Solana VersionBreaking ChangesTypeScript package renameSolana 3.0Solana CLI dependency removedanchor test / anchor localnet now use Surfpool by defaultDuplicate mutable accounts disallowed by defaultLegacy IDL instructions replaced by Program MetadataRemove program account info from CPI contextinterface-instructions feature removedAnchor.toml cleanup#[error_code] may only appear once per programClient tx signing error no longer panicsAVMavm self-updatePre-release supportCLILifecycle hooksLiteSVM test template is now the defaultProgram ID mismatch check--install-agent-skillslogin command removedLangMigration<'info, From, To> account typedeclare_program! improvementsUse declare_program! with only anchor_clientRemove lifetime definitions from ContextDeprecate AccountInfo in Accounts macroRelaxed PDA seed syntaxOwner check on account reloadGeneric Program typeOwners exported from preludeBorsh upgraded to 1.5.7#[instruction(..)] argument validationIDLUnsupported field types produce a hard errorFull path account names supported in IDL generationaddress constraint resolves constants with numbers in their namesserde_json is now optionalExternal accounts excluded from IDLCustom error offset respectedTypeScriptIDL fetching updated for PMPRust ClientFnMut closures for event subscriptionsReduced re-exports from anchor-clientEdit on GitHub","tokens":3637,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259064792,"hash":"4c476fba61e238981a8fb2c51395ff289568c29f"}
{"url":"https://docs.pyth.network/price-feeds/pro/how-lazer-works","domain":"docs.pyth.network","title":"How Pyth Pro Works | Pyth Developer Hub","text":"Pyth ProHow Pyth Pro WorksUnderstand the services that power Pyth Pro’s low-latency price deliveryPyth Pro is a permissioned service that provides ultra-low-latency market data to consumers.\nIt aggregates data from multiple publishers and distributes it to consumers through a multi-tier architecture.\nArchitecture Diagram\nThe following diagram illustrates the data flow through different components of Pyth Pro.\n\nSystem Services\nThe architecture consists of five main types of services that work together to provide ultra-low-latency data to consumers.\nEach service has multiple instances running to ensure high availability and low latency.\nPublishers\nPublishers are the entities that provide market data to Pro. They submit updates via authenticated WebSocket connections.\nEach publisher is configured with specific permissions defining which feeds they can update.\nRelayers\nThe Relayer service is the ingestion layer that receives and validates all incoming updates from publishers.\nKey responsibilities:\n\nAuthentication: Validates publisher API keys and optional Ed25519 signatures.\nValidation: Performs sanity checks on incoming updates by examining feed IDs, timestamps, and values to ensure data integrity and proper formatting.\nRate limiting: Enforces configurable limits on publisher updates.\nMessage forwarding: Publishes validated updates to an internal message queue.\n\nDouro Labs operates the relayer service for the Pyth Pro network. It follows a strict, deterministic processing model:\n\nNo price dropping outside of circuit breakers: All validated updates are forwarded to the message queue without dropping any prices (except for when a circuit breaker is triggered).\nFCFS processing: Updates are processed on a first-come-first-served basis without prioritization.\n\nThis ensures reliable, predictable data flow from publishers to consumers.\nMessage Queue\nThe system uses a distributed message queue for pub/sub messaging with stream persistence.\nThis allows the system to be deployed in a multi-datacenter environment and ensures reliable message delivery between services.\nMessage ordering: The message queue ensures reliable delivery and maintains the exact sequence of messages within each data stream.\nThis means every publisher update will be delivered at least once, and messages will be processed in the same order they arrived at the Relayer.\nThis sequential processing is essential for keeping all aggregators synchronized with the same feed state.\nRouters\nThe Router is the real-time distribution layer that serves data to consumers.\nIt embeds aggregation logic to compute median prices, confidence intervals (using interquartile range), and best bid/ask prices, funding rates, and more from multiple publisher inputs.\nKey features:\n\nWebSocket streaming: Provides /v1/stream endpoint for real-time price updates\nHTTP REST API: Offers /v1/latest_price for on-demand price queries\nChannel types: Supports real-time and fixed-rate channels (50ms, 200ms, 1000ms)\nMulti-chain support: Generates on-chain payloads for Solana, EVM, and other chains\n\nAggregation logic\nEach Router embeds an aggregator component that consumes publisher updates from the Message Queue and computes aggregated data feeds. The aggregator:\n\nComputes median values resistant to outlier data from individual publishers.\nCalculates confidence intervals using interquartile range to measure data spread.\nDetermines best bid/ask values filtered to ensure market consistency.\nAutomatically removes stale publisher data based on configurable timeouts.\n\nPro guarantees deterministic aggregation: all aggregators produce the exact same aggregated results by relying solely on the consistent stream of price updates from the Message Queue.\nThis ensures that every Router instance maintains identical feed state, providing consistent data to all consumers regardless of which Router they connect to.\nHistory Service\nThe History Service provides persistence and historical data queries.\nKey responsibilities:\n\nData persistence: Stores all publisher updates, aggregated data, and transactions.\nHistorical queries: Provides REST API for querying historical data.\nOHLC API: Provides Open, High, Low, Close (OHLC) data for charting applications through the history service.\nSymbology & Reference DataField-by-field reference for Pyth Pro symbol metadata: identifiers, classification, data quality, trading schedules, and futures expirationUnderstanding Price DataLearn about confidence intervals, best bid/ask, and what these metrics represent","tokens":1131,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259068138,"hash":"a5fe1099340513a034e53673aff8a5a7f6144de1"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-32-2","domain":"anchor-lang.com","title":"0.32.2","text":"Anchor Project UpdatesRelease Notes0.32.2Anchor - Release Notes 0.32.20.32.2 adds TypeScript client support for parsing Solana transaction version 1\n(v1) transactions. This is a TypeScript-only patch release.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.32.2\n\nUpdate Anchor crate(s) to 0.32.2.\n\nReplace the legacy @coral-xyz/anchor and related @coral-xyz/* packages\nwith @anchor-lang/core:\nnpm install @anchor-lang/core\nUpdate imports accordingly:\n// Before\nimport * as anchor from \"@coral-xyz/anchor\";\n\n// After\nimport * as anchor from \"@anchor-lang/core\";\n\nRecommended Solana Version\nThe recommended Solana version is 2.3.0. Install it with:\nsh -c \"$(curl -sSfL https://release.anza.xyz/v2.3.0/install)\"\nTypeScript\nSolana transaction version 1\nAnchorProvider can now deserialize and process Solana v1 transactions. When a\ntransaction fails, Anchor also retrieves the transaction with\nmaxSupportedTransactionVersion set to 1, so the client can return the\nprogram logs instead of failing while parsing the response.\nThe client now uses @solana/web3.js 1.99.0 and requires Node.js 20.18.0 or\nlater.\nTypeScript package migration\nUsers must switch from the legacy @coral-xyz/anchor packages to\n@anchor-lang/core. Update both the package dependency and all imports; the\nlegacy package line is not the supported path for this release.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous1.0.0Next0.32.1On this pageHow to upgradeRecommended Solana VersionTypeScriptSolana transaction version 1TypeScript package migrationEdit on GitHub","tokens":386,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259074673,"hash":"5447c7a4e010b73060b412ee8019a86e2bb2f725"}
{"url":"https://aave.com/docs/aave-v4/reference/react-hooks","domain":"aave.com","title":"React Hooks | Aave Protocol Documentation","text":"React Hooks#\nAll public Aave v4 React SDK hooks.\n\nuseChain#\nDeclarative hook to fetch a specific chain by ID.\nimport { useChain } from \"@aave/react\";\nconst { data, loading, error } = useChain({ pause, ...request,});\nArguments:\nrequest.chainId: ChainId - Chain ID to querypause?: boolean - Pause the query (default: false)\nReturns:\ndata: Chain | null | undefined - Chain information or null if not foundloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the chain\n\nuseChainAction#\nImperative hook to fetch chain data on demand. Does not watch for updated data; use it to retrieve data as part of a larger workflow.\nimport { useChainAction } from \"@aave/react\";\nconst [execute, state] = useChainAction();\nconst result = await execute(request);\nArguments:\nrequest.chainId: ChainId - Chain ID\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the chainstate.called: boolean - Whether the hook has been calledstate.data: Chain | null | undefined - Chain data or null if not foundresult: Result<Chain | null, UnexpectedError> - Type-safe success or failure value:\nOk<Chain | null> - Chain data or null if not foundErr<UnexpectedError> - Error fetching the chain\n\nuseChains#\nDeclarative hook to fetch all supported chains.\nimport { useChains } from \"@aave/react\";import { ChainsFilter } from \"@aave/react\";\nconst { data, loading, error } = useChains({ query: { filter: ChainsFilter.ALL }, pause,});\nArguments:\nrequest.query: ChainsRequestQuery one of:\nfilter: ChainsFilter - Filter for chains (e.g., ChainsFilter.ALL)chainIds: [ChainId!] - Fetch by chain IDs\npause?: boolean - Pause the query (default: false)\nReturns:\ndata: Chain[] | undefined - Array of supported chainsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the chains\n\nuseClaimRewards#\nImperative transaction hook to claim rewards for a user on a specific chain.\nimport { useClaimRewards } from \"@aave/react\";\nconst [execute, state] = useClaimRewards((transaction) => sendTransaction(transaction),);\nconst result = await execute(request);\nArguments:\nrequest.ids: [RewardId!] - Reward IDs to claimrequest.user: EvmAddress - User claiming the rewardsrequest.chainId: ChainId - Chain to claim on\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionError\n\nuseActivities#\nDeclarative hook to fetch paginated list of user activities.\nimport { useActivities } from \"@aave/react\";\nconst { data, loading, error } = useActivities({ pause, ...request,});\nArguments:\nrequest.query: ActivitiesRequestQuery one of:\nhub: HubInput - Fetch by hubspoke: SpokeInput - Fetch by spokechainIds: [ChainId!] - Fetch by chain IDstxHash: TxHashInput - Fetch by transaction hash\nrequest.user?: EvmAddress - User address (optional)request.currency?: Currency - Currency for value conversions (default: USD)pause?: boolean - Pause the query (default: false)\nReturns:\ndata?.items: ActivityItem[] - List of activitiesdata?.pageInfo: PageInfo - Pagination informationloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the activities\n\nuseActivitiesAction#\nImperative hook to fetch paginated list of user activities.\nimport { useActivitiesAction } from \"@aave/react\";\nconst [execute, state] = useActivitiesAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.query: ActivitiesRequestQuery one of:\nhub: HubInput - Fetch by hubspoke: SpokeInput - Fetch by spokechainIds: [ChainId!] - Fetch by chain IDstxHash: TxHashInput - Fetch by transaction hash\nrequest.user?: EvmAddress - User address (optional)\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the activitiesstate.called: boolean - Whether the hook has been calledstate.data: PaginatedActivitiesResult | undefined - Paginated activities resultresult: Result<PaginatedActivitiesResult, UnexpectedError> - Type-safe success or failure value:\nOk<PaginatedActivitiesResult> - Paginated activities resultErr<UnexpectedError> - Error fetching the activities\n\nuseAsset#\nDeclarative hook to fetch information about a specific asset (ERC20 token).\nimport { useAsset } from \"@aave/react\";\nconst { data, loading, error } = useAsset({ pause, ...request,});\nArguments:\nrequest.query: AssetRequestQuery one of:\ntoken: Erc20Input - ERC-20 token\naddress: EvmAddress - Token contract addresschainId: ChainId - Chain ID where the token exists\nassetId: AssetId - Asset ID\nrequest.currency?: Currency - Currency for value conversions (optional)request.timeWindow?: TimeWindow - Time window for historical data (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: Asset | null | undefined - Asset information or null if not foundloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the asset\n\nuseAssetBorrowHistory#\nDeclarative hook to fetch historical borrow data for an asset.\nimport { useAssetBorrowHistory } from \"@aave/react\";\nconst { data, loading, error } = useAssetBorrowHistory({ pause, ...request,});\nArguments:\nrequest.token.address: EvmAddress - Asset contract addressrequest.token.chainId: ChainId - Chain IDrequest.window: TimeWindow - Time window for historical datapause?: boolean - Pause the query (default: false)\nReturns:\ndata: AssetBorrowSample[] | undefined - Array of historical borrow data points\ndata[].date: Date - Sample datedata[].amount: DecimalNumber - Total borrowed amountdata[].highestApy: PercentNumber - Highest borrow APY across hubsdata[].lowestApy: PercentNumber - Lowest borrow APY across hubsdata[].averageApy: PercentNumber - Average borrow APY across all hubsdata[].breakdown: AssetSampleBreakdown[] - Per-hub APY breakdown\nloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the borrow history\n\nuseAssetPriceHistory#\nDeclarative hook to fetch historical price data for an asset.\nimport { useAssetPriceHistory } from \"@aave/react\";\nconst { data, loading, error } = useAssetPriceHistory({ pause, ...request,});\nArguments:\nrequest.token.address: EvmAddress - Asset contract addressrequest.token.chainId: ChainId - Chain IDrequest.currency: Currency - Currency for the datarequest.window: TimeWindow - Time window for historical datapause?: boolean - Pause the query (default: false)\nReturns:\ndata: AssetPriceSample[] | undefined - Array of historical price data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the price history\n\nuseAssetSupplyHistory#\nDeclarative hook to fetch historical supply data for an asset.\nimport { useAssetSupplyHistory } from \"@aave/react\";\nconst { data, loading, error } = useAssetSupplyHistory({ pause, ...request,});\nArguments:\nrequest.token.address: EvmAddress - Asset contract addressrequest.token.chainId: ChainId - Chain IDrequest.window: TimeWindow - Time window for historical datapause?: boolean - Pause the query (default: false)\nReturns:\ndata: AssetSupplySample[] | undefined - Array of historical supply data points\ndata[].date: Date - Sample datedata[].amount: DecimalNumber - Total supplied amountdata[].highestApy: PercentNumber - Highest supply APY across hubsdata[].lowestApy: PercentNumber - Lowest supply APY across hubsdata[].averageApy: PercentNumber - Average supply APY across all hubsdata[].breakdown: AssetSampleBreakdown[] - Per-hub APY breakdown\nloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the supply history\n\nuseProtocolHistory#\nDeclarative hook to fetch protocol-wide historical data (deposits, borrows).\nimport { Currency, TimeWindow } from \"@aave/react\";import { useProtocolHistory } from \"@aave/react\";\nconst { data, loading, error } = useProtocolHistory({ currency: Currency.Usd, window: TimeWindow.LastWeek, pause,});\nArguments:\nrequest.currency: Currency - Currency for exchange amounts (default: USD)request.window: TimeWindow - Time window for historical data (default: LAST_DAY)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: ProtocolHistorySample[] | undefined - Array of protocol history data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the protocol history\n\nuseBorrow#\nImperative transaction hook to borrow assets from the protocol.\nimport { useBorrow } from \"@aave/react\";\nconst [execute, state] = useBorrow((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan); case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});\nconst result = await execute(request);\nArguments:\nrequest.chainId: ChainId - Chain IDrequest.reserve: EvmAddress - Reserve addressrequest.amount: BigDecimal - Amount to borrowrequest.onBehalfOf?: EvmAddress - Borrow on behalf of another address (optional)\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionErrorValidationError<InsufficientBalanceError>\n\nuseBorrowApyHistory#\nDeclarative hook to fetch borrow APY history for a specific reserve over time.\nimport { useBorrowApyHistory } from \"@aave/react\";\nconst { data, loading, error } = useBorrowApyHistory({ pause, ...request,});\nArguments:\nrequest.spoke.address: EvmAddress - Spoke contract addressrequest.spoke.chainId: ChainId - Chain IDrequest.reserve: ReserveId - Reserve IDrequest.window: TimeWindow - Time window for historical datapause?: boolean - Pause the query (default: false)\nReturns:\ndata: ApySample[] | undefined - Array of historical APY data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the borrow APY history\n\nuseSignTypedData#\nImperative transaction hook to sign EIP-712 typed data for ERC-20 permits and swap intents.\nThis hook provides a unified interface for signing all types of typed data in the Aave SDK. It returns a raw signature that is automatically wrapped with deadline information by transaction hooks like useSupply, useRepay, and useTokenSwap.\nimport { useSignTypedData } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\nconst { data: walletClient } = useWalletClient();const [execute, state] = useSignTypedData(walletClient);\nconst result = await execute(typedData);\nArguments:\ntypedData: TypedData - The EIP-712 typed data to sign.\nReturns:\nstate.loading: boolean - Loading statestate.error: SignTypedDataError | undefined - Error signing the typed datastate.called: boolean - Whether the hook has been calledstate.data: Signature | undefined - Raw signature (deadline wrapping is handled automatically by transaction hooks)result: Result<Signature, SignTypedDataError> - Type-safe success or failure value:\nOk<Signature> - Raw signatureErr<SignTypedDataError> - Error signing the typed data\n\nuseExchangeRate#\nDeclarative hook to fetch the current exchange rate between two currencies.\nimport { useExchangeRate } from \"@aave/react\";\nconst { data, loading, error } = useExchangeRate({ pause, ...request,});\nArguments:\nrequest.from: AssetInput - Source asset (erc20 or native)request.to: Currency - Target currencypause?: boolean - Pause the query (default: false)\nReturns:\ndata: ExchangeAmount | undefined - Exchange rate valueloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the exchange rate\n\nuseExchangeRateAction#\nImperative hook to fetch exchange rate between two currencies.\nimport { useExchangeRateAction } from \"@aave/react\";\nconst [execute, state] = useExchangeRateAction();\nconst result = await execute(request);\nArguments:\nrequest.from: AssetInput - Source asset (erc20 or native)request.to: Currency - Target currencyrequest.at?: Date - Historical date (optional)\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the exchange ratestate.called: boolean - Whether the hook has been calledstate.data: ExchangeAmount | undefined - Exchange rate valueresult: Result<ExchangeAmount, UnexpectedError> - Type-safe success or failure value:\nOk<ExchangeAmount> - Exchange rate valueErr<UnexpectedError> - Error fetching the exchange rate\n\nuseHub#\nDeclarative hook to fetch a specific hub by address and chain ID.\nimport { useHub } from \"@aave/react\";\nconst { data, loading, error } = useHub({ pause, ...request,});\nArguments:\nrequest.query: HubRequestQuery one of:\nhubInput: HubInput - Hub address and chain ID\naddress: EvmAddress - Hub contract addresschainId: ChainId - Chain ID where the hub exists\nhubId: HubId - Hub ID\nrequest.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: Hub | null | undefined - Hub information or null if not foundloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the hub\n\nuseHubAssets#\nDeclarative hook to fetch hub assets for a specific chain and optional hub/user filtering.\nimport { useHubAssets } from \"@aave/react\";\nconst { data, loading, error } = useHubAssets({ pause, ...request,});\nArguments:\nrequest.query: HubAssetsRequestQuery one of:\nhubInput: HubInput - Hub address and chain ID\naddress: EvmAddress - Hub contract addresschainId: ChainId - Chain ID\nhubId: HubId - Hub ID\nrequest.user?: EvmAddress - Filter by user address (optional)request.orderBy?: HubAssetsRequestOrderBy one of:\nassetName: OrderDirection - Sort by asset nameavailableLiquidity: OrderDirection - Sort by available liquiditysupplyApy: OrderDirection - Sort by supply APYborrowApy: OrderDirection - Sort by borrow APY\nrequest.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: HubAsset[] | undefined - Array of hub assetsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the hub assets\n\nuseHubAssetInterestRateModel#\nDeclarative hook to fetch the interest rate model curve for a specific hub asset.\nimport { useHubAssetInterestRateModel } from \"@aave/react\";\nconst { data, loading, error } = useHubAssetInterestRateModel({ pause, ...request,});\nArguments:\nrequest.query: HubAssetInterestRateModelRequestQuery:\nhubAssetId: HubAssetId - Hub asset ID\nrequest.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: HubAssetInterestRateModelPoint[] | undefined - Array of interest rate model data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the interest rate model\n\nuseHubAssetInterestRateModelAction#\nImperative hook to fetch interest rate model data for a hub asset.\nimport { useHubAssetInterestRateModelAction } from \"@aave/react\";\nconst [execute, state] = useHubAssetInterestRateModelAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.query: HubAssetInterestRateModelRequestQuery:\nhubAssetId: HubAssetId - Hub asset ID\n\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the interest rate modelstate.called: boolean - Whether the hook has been calledstate.data: HubAssetInterestRateModelPoint[] | undefined - Array of interest rate model data pointsresult: Result<HubAssetInterestRateModelPoint[], UnexpectedError> - Type-safe success or failure value:\nOk<HubAssetInterestRateModelPoint[]> - Array of interest rate model data pointsErr<UnexpectedError> - Error fetching the interest rate model\n\nuseHubSummaryHistory#\nDeclarative hook to fetch historical summary data for a specific hub.\nimport { useHubSummaryHistory } from \"@aave/react\";\nconst { data, loading, error } = useHubSummaryHistory({ pause, ...request,});\nArguments:\nrequest.query: HubSummaryHistoryRequestQuery one of:\nhubInput: HubInput - Hub address and chain ID\naddress: EvmAddress - Hub contract addresschainId: ChainId - Chain ID where the hub exists\nhubId: HubId - Hub ID\nrequest.currency?: Currency - Currency for value conversions (default: USD)request.window?: TimeWindow - Time window for historical data (default: LAST_DAY)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: HubSummarySample[] | undefined - Array of historical hub summary data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the hub summary history\n\nuseHubSpokeConfigs#\nDeclarative hook to fetch per-asset configuration for a specific hub and spoke pair.\nimport { useHubSpokeConfigs } from \"@aave/react\";\nconst { data, loading, error } = useHubSpokeConfigs({ pause, ...request,});\nArguments:\nrequest.hubId: HubId - Hub IDrequest.spokeId: SpokeId - Spoke IDrequest.currency?: Currency - Currency for nested amount conversions (default: USD)request.timeWindow?: TimeWindow - Time window for nested change calculations (default: LAST_DAY)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: HubSpokeConfig[] | undefined - Array of hub-spoke asset configurationsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the configs\n\nuseHubs#\nDeclarative hook to fetch all available hubs.\nimport { useHubs } from \"@aave/react\";\nconst { data, loading, error } = useHubs({ pause, ...request,});\nArguments:\nrequest.query: HubsRequestQuery one of:\ntokens: [Erc20Input!] - Filter by underlying tokens\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\nchainIds: [ChainId!] - Filter by chain IDs\nrequest.orderBy?: HubsRequestOrderBy one of:\nname: OrderDirection - Sort by hub nametotalBorrowed: OrderDirection - Sort by total borrowed amounttotalSupplied: OrderDirection - Sort by total supplied amount\npause?: boolean - Pause the query (default: false)\nReturns:\ndata: Hub[] | undefined - Array of hubsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the hubs\n\nuseHubsAction#\nImperative hook to fetch hubs data.\nimport { useHubsAction } from \"@aave/react\";\nconst [execute, state] = useHubsAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.query: HubsRequestQuery one of:\ntokens: [Erc20Input!] - Filter by underlying tokens\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\nchainIds: [ChainId!] - Filter by chain IDs\nrequest.orderBy?: HubsRequestOrderBy one of:\nname: OrderDirection - Sort by hub nametotalBorrowed: OrderDirection - Sort by total borrowed amounttotalSupplied: OrderDirection - Sort by total supplied amount\n\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the hubsstate.called: boolean - Whether the hook has been calledstate.data: Hub[] | undefined - Array of hubsresult: Result<Hub[], UnexpectedError> - Type-safe success or failure value:\nOk<Hub[]> - Array of hubsErr<UnexpectedError> - Error fetching the hubs\n\nuseLiquidatePosition#\nImperative transaction hook to liquidate an undercollateralized position.\nimport { useLiquidatePosition } from \"@aave/react\";\nconst [execute, state] = useLiquidatePosition((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan); case \"Erc20Approval\": return sendTransaction(plan.byTransaction); case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});\nconst result = await execute(request);\nArguments:\nrequest.chainId: ChainId - Chain IDrequest.debtReserve: EvmAddress - Debt reserve addressrequest.collateralReserve: EvmAddress - Collateral reserve addressrequest.user: EvmAddress - User address to liquidaterequest.debtToCover: BigDecimal - Amount of debt to cover\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionErrorValidationError<InsufficientBalanceError>\n\nuseMultichainAsset#\nDeclarative hook to fetch information about an asset (ERC-20 token) aggregated across multiple chains, matched by its token info ID or symbol.\nimport { useMultichainAsset } from \"@aave/react\";\nconst { data, loading, error } = useMultichainAsset({ pause, ...request,});\nArguments:\nrequest.query: MultichainAssetRequestQuery one of:\ntokenInfo: TokenInfoId - Token info IDsymbol: String - Token symbol (e.g. \"USDC\")\nrequest.chainIds?: [ChainId!] - Restrict aggregation to specific chains (optional)request.includeRewards?: boolean - Fold Merkl rewards into APY ranges (default: true)currency?: Currency - Currency for value conversions (default: USD)timeWindow?: TimeWindow - Time window for historical changes (default: LastDay)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: MultichainAsset | undefined - Aggregated asset data (assets and summary)loading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the asset\n\nuseNetworkFee#\nDeclarative hook to fetch the network fee for an activity (experimental).\nimport { useNetworkFee } from \"@aave/react\";\nconst { data, loading, error } = useNetworkFee({ pause, ...request,});\nArguments:\nrequest.query: UseNetworkFeeRequestQuery one of:\nactivity: ActivityItem - Calculate fee for past activityestimate: PreviewAction - Estimate fee for preview action, one of:\nsupply: SupplyRequest - Supply actionborrow: BorrowRequest - Borrow actionrepay: RepayRequest - Repay actionwithdraw: WithdrawRequest - Withdraw actionsetUserSuppliesAsCollateral: SetUserSuppliesAsCollateralRequest - Collateral changesupdateUserPositionConditions: UpdateUserPositionConditionsRequest - Position condition updates\n\nrequest.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: NativeAmount | undefined - Network fee amountloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the network fee\n\nusePreview#\nDeclarative hook to preview the outcome of a transaction before executing.\nimport { usePreview } from \"@aave/react\";\nconst { data, loading, error } = usePreview({ pause, ...request,});\nArguments:\nrequest.action: PreviewActionInput one of:\nsupply: SupplyRequest - Preview a supply actionborrow: BorrowRequest - Preview a borrow actionrepay: RepayRequest - Preview a repay actionwithdraw: WithdrawRequest - Preview a withdraw actionsetUserSuppliesAsCollateral: SetUserSuppliesAsCollateralRequest - Preview a collateral change\nrequest.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: PreviewUserPosition | undefined - Preview of user position after the actionloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the preview\n\nusePreviewAction#\nImperative hook to preview the outcome of a transaction before executing.\nimport { usePreviewAction } from \"@aave/react\";\nconst [execute, state] = usePreviewAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.action: PreviewActionInput one of:\nsupply: SupplyRequest - Preview a supply actionborrow: BorrowRequest - Preview a borrow actionrepay: RepayRequest - Preview a repay actionwithdraw: WithdrawRequest - Preview a withdraw actionsetUserSuppliesAsCollateral: SetUserSuppliesAsCollateralRequest - Preview a collateral change\n\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the previewstate.called: boolean - Whether the hook has been calledstate.data: PreviewUserPosition | undefined - Preview of user position after the actionresult: Result<PreviewUserPosition, UnexpectedError> - Type-safe success or failure value:\nOk<PreviewUserPosition> - Preview of user position after the actionErr<UnexpectedError> - Error fetching the preview\n\nuseRenounceSpokeUserPositionManager#\nImperative transaction hook to renounce a position manager of a user for a specific spoke.\nimport { useRenounceSpokeUserPositionManager } from \"@aave/react\";\nconst [execute, state] = useRenounceSpokeUserPositionManager((transaction) => sendTransaction(transaction),);\nconst result = await execute(request);\nArguments:\nrequest.spoke: SpokeId - Spoke IDrequest.manager: EvmAddress - Address to remove as a position managerrequest.managing: EvmAddress - Address that manager was managing\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionError\n\nuseRepay#\nImperative transaction hook to repay borrowed assets.\nimport { useRepay } from \"@aave/react\";\nconst [execute, state] = useRepay((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan); case \"Erc20Approval\": return sendTransaction(plan.byTransaction); case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});\nconst result = await execute(request);\nArguments:\nrequest.chainId: ChainId - Chain IDrequest.reserve: EvmAddress - Reserve addressrequest.amount: BigDecimal - Amount to repayrequest.onBehalfOf?: EvmAddress - Repay on behalf of another address (optional)\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionErrorValidationError<InsufficientBalanceError>\n\nuseReserve#\nDeclarative hook to fetch a specific reserve by reserve ID, spoke, and chain.\nimport { useReserve } from \"@aave/react\";\nconst { data, loading, error } = useReserve({ pause, ...request,});\nArguments:\nrequest.query: ReserveRequestQuery one of:\nreserveId: ReserveId - Reserve IDreserveInput: ReserveInput - Reserve input\nchainId: ChainId - Chain IDspoke: EvmAddress - Spoke contract addressonChainId: OnChainReserveId - On-chain reserve ID\n\nrequest.user?: EvmAddress - User address for position-specific data (optional)request.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: Reserve | null | undefined - Reserve information or null if not foundloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the reserve\n\nuseReserveAction#\nImperative hook to fetch reserve data.\nimport { useReserveAction } from \"@aave/react\";\nconst [execute, state] = useReserveAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.reserve: ReserveId - Reserve IDrequest.user?: EvmAddress - User address for position-specific data (optional)\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the reservestate.called: boolean - Whether the hook has been calledstate.data: Reserve | null | undefined - Reserve data or null if not foundresult: Result<Reserve | null, UnexpectedError> - Type-safe success or failure value:\nOk<Reserve | null> - Reserve data or null if not foundErr<UnexpectedError> - Error fetching the reserve\n\nuseReserves#\nDeclarative hook to fetch reserves based on specified criteria.\nimport { useReserves } from \"@aave/react\";\nconst { data, loading, error } = useReserves({ pause, ...request,});\nArguments:\nrequest.query: ReservesRequestQuery one of:\nspoke: SpokeInput - Get reserves for a spoke\naddress: EvmAddress - Spoke contract addresschainId: ChainId - Chain ID\nspokeId: SpokeId - Get reserves by spoke IDtokens: [Erc20Input!] - Get reserves with underlying tokens\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\nhubToken: HubTokenInput - Get reserves on hub for underlying\nchainId: ChainId - Chain IDhub: EvmAddress - Hub contract addresstoken: EvmAddress - Token address\nchainIds: [ChainId!] - Get reserves on chainsspokeToken: SpokeTokenInput - Get reserves for spoke for underlying\nspoke: SpokeId - Spoke IDtoken: EvmAddress - Token address\nhub: HubInput - Get reserves on hubuserPositionId: UserPositionId - Get reserves by user position IDcategories: TokenCategory[] - Get reserves by token categories\nTokenCategory.Stablecoin - Stablecoin categoryTokenCategory.EthCorrelated - ETH-correlated category\n\nrequest.filter?: ReservesRequestFilter - Filter criteria (optional): Supply, Borrow, Collateral, or Allrequest.orderBy?: ReservesRequestOrderBy one of:\nassetName: OrderDirection - Sort by asset nameuserBalance: OrderDirection - Sort by user balancesupplyApy: OrderDirection - Sort by supply APYsupplyAvailable: OrderDirection - Sort by available supplyborrowApy: OrderDirection - Sort by borrow APYborrowAvailable: OrderDirection - Sort by available borrowcollateralFactor: OrderDirection - Sort by collateral factor\nrequest.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: Reserve[] | undefined - Array of reservesloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching reserves\n\nuseReservesAction#\nImperative hook to fetch reserves list.\nimport { useReservesAction } from \"@aave/react\";\nconst [execute, state] = useReservesAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.query: ReservesRequestQuery one of:\nspoke: SpokeInput - Get all reserves for a spoketokens: [Erc20Input!] - Get all reserves with underlying tokens\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\nhubToken: HubTokenInput - Get all reserves on a hub for an underlying\nchainId: ChainId - Chain IDhub: EvmAddress - Hub contract addresstoken: EvmAddress - Token address\nchainIds: [ChainId!] - Get all reserves on a list of chainsspokeToken: SpokeTokenInput - Get all reserves for a spoke for an underlying\nspoke: SpokeId - Spoke IDtoken: EvmAddress - Token address\nhub: HubInput - Get all tokens on a hubuserPositionId: UserPositionId - Get all reserves by user position IDcategories: TokenCategory[] - Get all reserves by token categories\nTokenCategory.Stablecoin - Stablecoin categoryTokenCategory.EthCorrelated - ETH-correlated category\n\nrequest.filter?: ReservesRequestFilter - Filter criteria (optional): Supply, Borrow, Collateral, or All\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching reservesstate.called: boolean - Whether the hook has been calledstate.data: Reserve[] | undefined - Array of reservesresult: Result<Reserve[], UnexpectedError> - Type-safe success or failure value:\nOk<Reserve[]> - Array of reservesErr<UnexpectedError> - Error fetching reserves\n\nuseReserveHolders#\nDeclarative hook to fetch a paginated list of top holders for a specific reserve.\nimport { ReserveHoldersFilter, useReserveHolders } from \"@aave/react\";\nconst { data, loading, error } = useReserveHolders({ reserve: { reserveId }, filter: ReserveHoldersFilter.Supplied,});\nArguments:\nrequest.reserve: ReserveRequestQuery one of:\nreserveId: ReserveId - Reserve ID\nrequest.filter?: ReserveHoldersFilter - Filter by holder type (default: Supplied):\nReserveHoldersFilter.Supplied - Wallets that have supplied to this reserveReserveHoldersFilter.Borrowed - Wallets that have borrowed from this reserve\nrequest.pageSize?: PageSize - Number of results per page (default: TEN)request.cursor?: Cursor - Pagination cursorpause?: boolean - Pause the query (default: false)\nReturns:\ndata: PaginatedReserveHoldersResult | undefined\ndata.items: ReserveHolder[] - Array of holders\naddress: EvmAddress - Holder wallet addressamount: Erc20Amount - Amount supplied or borrowedweight: PercentNumber - Percentage share of the total\ndata.pageInfo: PaginatedResultInfo - Pagination info with next and prev cursors\nloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching holders\n\nuseReserveHoldersAction#\nImperative hook to fetch reserve holders on demand (e.g., for pagination).\nimport { useReserveHoldersAction } from \"@aave/react\";\nconst [execute, state] = useReserveHoldersAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.reserve: ReserveRequestQuery - Reserve query (see useReserveHolders)request.filter?: ReserveHoldersFilter - Holder type filterrequest.pageSize?: PageSize - Page sizerequest.cursor?: Cursor - Pagination cursor\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching holdersstate.called: boolean - Whether the hook has been calledstate.data: PaginatedReserveHoldersResult | undefined - Paginated resultresult: Result<PaginatedReserveHoldersResult, UnexpectedError> - Type-safe success or failure value:\nOk<PaginatedReserveHoldersResult> - Paginated holder dataErr<UnexpectedError> - Error fetching holders\n\nuseSendTransaction#\nSend transactions through connected wallet.\nimport { useSendTransaction } from \"@aave/react/viem\";import { useWalletClient } from \"wagmi\";\nconst { data: walletClient } = useWalletClient();const [sendTransaction, state] = useSendTransaction(walletClient);\n\nuseSetSpokeUserPositionManager#\nImperative transaction hook to set a position manager for a spoke.\nimport { useSetSpokeUserPositionManager } from \"@aave/react\";\nconst [execute, state] = useSetSpokeUserPositionManager((transaction) => sendTransaction(transaction),);\nconst result = await execute(request);\nArguments:\nrequest.chainId: ChainId - Chain IDrequest.spoke: SpokeId - Spoke IDrequest.manager: EvmAddress - Position manager address\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionError\n\nuseSetUserSuppliesAsCollateral#\nImperative transaction hook to enable or disable assets as collateral.\nimport { useSetUserSuppliesAsCollateral } from \"@aave/react\";\nconst [execute, state] = useSetUserSuppliesAsCollateral((transaction) => sendTransaction(transaction),);\nconst result = await execute(request);\nArguments:\nrequest.changes: UserSupplyAsCollateral[] - Array of collateral changes\nchanges[].reserve: ReserveId - Reserve IDchanges[].enableCollateral: boolean - Enable or disable as collateral\nrequest.sender: EvmAddress - User's address\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<Error> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionError\n\nuseSpoke#\nDeclarative hook to fetch a specific spoke by address and chain ID.\nimport { useSpoke } from \"@aave/react\";\nconst { data, loading, error } = useSpoke({ pause, ...request,});\nArguments:\nrequest.query.spoke.address: EvmAddress - Spoke contract addressrequest.query.spoke.chainId: ChainId - Chain IDpause?: boolean - Pause the query (default: false)\nReturns:\ndata: Spoke | null | undefined - Spoke information or null if not foundloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the spoke\n\nuseSpokePositionManagers#\nDeclarative hook to fetch paginated list of position managers for a spoke.\nimport { useSpokePositionManagers } from \"@aave/react\";\nconst { data, loading, error } = useSpokePositionManagers({ pause, ...request,});\nArguments:\nrequest.spoke: SpokeInput - Spoke address and chain IDpause?: boolean - Pause the query (default: false)\nReturns:\ndata: PaginatedSpokePositionManagerResult | undefined - Paginated list of position managersloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching position managers\n\nuseSpokeSummaryHistory#\nDeclarative hook to fetch historical deposits and borrows for a specific spoke.\nimport { useSpokeSummaryHistory } from \"@aave/react\";\nconst { data, loading, error } = useSpokeSummaryHistory({ pause, ...request,});\nArguments:\nrequest.query: SpokeSummaryHistoryRequestQuery one of:\nspokeInput: SpokeInput - Spoke address and chain IDspokeId: SpokeId - Spoke ID\nrequest.currency?: Currency - Currency for value conversions (default: USD)request.window?: TimeWindow - Time window for historical data (default: LAST_DAY)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: SpokeSummarySample[] | undefined - Array of historical spoke summary data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the spoke summary history\n\nuseSpokes#\nDeclarative hook to fetch spokes based on specified criteria.\nimport { useSpokes } from \"@aave/react\";\nconst { data, loading, error } = useSpokes({ pause, ...request,});\nArguments:\nrequest.chainIds?: ChainId[] - Filter by specific chain IDs (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: Spoke[] | undefined - Array of spokesloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the spokes\n\nuseSpokeUserPositionManagers#\nDeclarative hook to fetch paginated list of user's position managers for a spoke.\nimport { useSpokeUserPositionManagers } from \"@aave/react\";\nconst { data, loading, error } = useSpokeUserPositionManagers({ pause, ...request,});\nArguments:\nrequest.spoke: SpokeInput - Spoke address and chain IDrequest.user: EvmAddress - User addresspause?: boolean - Pause the query (default: false)\nReturns:\ndata: PaginatedSpokeUserPositionManagerResult | undefined - Paginated list of user's position managersloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching user position managers\n\nuseSwapStatus#\nDeclarative hook to monitor the status of a swap operation in real-time.\nimport { useSwapStatus } from \"@aave/react\";\nconst { data, loading, error } = useSwapStatus({ pause, ...request,});\nArguments:\nrequest.id: string - Swap receipt ID from SwapReceipt.idpause?: boolean - Pause the query (default: false)\nReturns:\ndata: SwapStatus | undefined - Current swap status, one of:\nSwapOpen - Swap is open and waiting for executionSwapPendingSignature - Swap is waiting for user signatureSwapFulfilled - Swap completed successfullySwapCancelled - Swap was cancelledSwapExpired - Swap expired before execution\nloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the swap status\n\nuseSupply#\nImperative transaction hook to supply assets to the protocol.\nimport { useSupply } from \"@aave/react\";\nconst [execute, state] = useSupply((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan); case \"Erc20Approval\": return sendTransaction(plan.byTransaction); case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});\nconst result = await execute(request);\nArguments:\nrequest.chainId: ChainId - Chain IDrequest.reserve: EvmAddress - Reserve addressrequest.amount: BigDecimal - Amount to supplyrequest.onBehalfOf?: EvmAddress - Supply on behalf of another address (optional)\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionErrorValidationError<InsufficientBalanceError>\n\nuseSupplyApyHistory#\nDeclarative hook to fetch supply APY history for a specific reserve over time.\nimport { useSupplyApyHistory } from \"@aave/react\";\nconst { data, loading, error } = useSupplyApyHistory({ pause, ...request,});\nArguments:\nrequest.spoke.address: EvmAddress - Spoke contract addressrequest.spoke.chainId: ChainId - Chain IDrequest.reserve: ReserveId - Reserve IDrequest.window: TimeWindow - Time window for historical datapause?: boolean - Pause the query (default: false)\nReturns:\ndata: ApySample[] | undefined - Array of historical APY data pointsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the supply APY history\n\nuseUpdateUserPositionConditions#\nImperative transaction hook to update a user's position conditions (dynamic config and/or risk premium).\nimport { useUpdateUserPositionConditions, UserPositionConditionsUpdate,} from \"@aave/react\";\nconst [execute, state] = useUpdateUserPositionConditions((transaction) => sendTransaction(transaction),);\nconst result = await execute({ userPositionId: userPosition.id, update: UserPositionConditionsUpdate.AllDynamicConfig,});\nArguments:\nrequest.userPositionId: UserPositionId - User position identifierrequest.update: UserPositionConditionsUpdate - Type of update to perform:\nUserPositionConditionsUpdate.JustRiskPremium - Update only the risk premiumUserPositionConditionsUpdate.AllDynamicConfig - Update all dynamic config (includes risk premium)\n\nReturns:\nstate.loading: boolean - Loading statestate.error: E | undefined - Error executing the transactionstate.called: boolean - Whether the hook has been calledstate.data: TransactionReceipt | undefined - Transaction receiptresult: Result<TransactionReceipt, E> - Type-safe success or failure value:\nOk<TransactionReceipt> - Transaction receiptErr<E> - Error executing the transaction\n\nWhere E is one of:\nSendTransactionErrorCancelErrorTimeoutErrorTransactionErrorUnexpectedError\n\nuseUserBalances#\nDeclarative hook to fetch user wallet balances across specified chains.\nimport { useUserBalances } from \"@aave/react\";\nconst { data, loading, error } = useUserBalances({ pause, ...request,});\nArguments:\nrequest.user: EvmAddress - User addressrequest.filter: UserBalancesRequestFilter one of:\nchains: UserBalancesByChains - Balances on specified chains\nchainIds: ChainId[] - Chain IDs to querybyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\nhub: UserBalancesByHub - Balances for hub assets\naddress: EvmAddress - Hub addresschainId: ChainId - Hub chain IDbyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\nspoke: UserBalancesBySpoke - Balances for spoke reserves\naddress: EvmAddress - Spoke addresschainId: ChainId - Spoke chain IDbyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\nuserPosition: UserBalancesByUserPosition - Balances for user position\nuserPositionId: UserPositionId - User position IDbyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\n\nrequest.orderBy?: UserBalancesRequestOrderBy one of:\nname: OrderDirection - Sort by token namebalance: OrderDirection - Sort by balance\nrequest.includeZeroBalances?: boolean - Include zero balances (default: false)request.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserBalance[] | undefined - Array of user wallet balancesloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching user balances\n\nuseUserBalancesAction#\nImperative hook to fetch user wallet balances.\nimport { useUserBalancesAction } from \"@aave/react\";\nconst [execute, state] = useUserBalancesAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.user: EvmAddress - User addressrequest.filter: UserBalancesRequestFilter one of:\nchains: UserBalancesByChains - Balances on specified chains\nchainIds: ChainId[] - Chain IDs to querybyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\nhub: UserBalancesByHub - Balances for hub assets\naddress: EvmAddress - Hub addresschainId: ChainId - Hub chain IDbyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\nspoke: UserBalancesBySpoke - Balances for spoke reserves\naddress: EvmAddress - Spoke addresschainId: ChainId - Spoke chain IDbyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\nuserPosition: UserBalancesByUserPosition - Balances for user position\nuserPositionId: UserPositionId - User position IDbyReservesType: ReservesRequestFilter - Reserve type filter (default: ALL)\ntokens: UserBalancesByTokens - Balances for specific tokens\nchainTokens: ChainTokenInput[] - Array of chain-token pairs\nchainId: ChainId - Chain IDtoken: TokenInput one of:\nnative: AlwaysTrue - Native tokenerc20: EvmAddress - ERC20 token address\n\nbyReservesType?: ReservesRequestFilter - Reserve type filter (default: ALL)\n\nrequest.orderBy?: UserBalancesRequestOrderBy one of:\nname: OrderDirection - Sort by token namebalance: OrderDirection - Sort by balance\nrequest.includeZeroBalances?: boolean - Include zero balances (default: false)\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching user balancesstate.called: boolean - Whether the hook has been calledstate.data: UserBalance[] | undefined - Array of user wallet balancesresult: Result<UserBalance[], UnexpectedError> - Type-safe success or failure value:\nOk<UserBalance[]> - Array of user wallet balancesErr<UnexpectedError> - Error fetching user balances\n\nuseUserBorrows#\nDeclarative hook to fetch all user borrow positions.\nimport { useUserBorrows } from \"@aave/react\";\nconst { data, loading, error } = useUserBorrows({ pause, ...request,});\nArguments:\nrequest.query: UserBorrowsRequestQuery one of:\nuserSpoke: UserSpokeInput - Get borrows for user on spoke\nspoke: SpokeId - Spoke IDuser: EvmAddress - User address\nuserToken: UserToken - Get borrows for user for token\nuser: EvmAddress - User addresstoken: Erc20Input - Token input\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\n\nuserPositionId: UserPositionId - Get borrows for user positionuserChains: UserChains - Get borrows for user across chains\nuser: EvmAddress - User addresschainIds: [ChainId!] - Chain IDs\nuserHub: UserHub - Get borrows for user on hub\nuser: EvmAddress - User addresshub: UserHubInput - Hub input (hub ID or hub details)\n\nrequest.orderBy?: UserBorrowsRequestOrderBy one of:\nassetName: OrderDirection - Sort by asset namecreated: OrderDirection - Sort by creation dateamount: OrderDirection - Sort by borrow amountapy: OrderDirection - Sort by APY\nrequest.includeZeroBalances?: boolean - Include zero balances (default: false)request.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserBorrowItem[] | undefined - Array of user borrow positionsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching user borrows\n\nuseUserBorrowsAction#\nImperative hook to fetch user borrow positions.\nimport { useUserBorrowsAction } from \"@aave/react\";\nconst [execute, state] = useUserBorrowsAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.query: UserBorrowsRequestQuery one of:\nuserSpoke: UserSpokeInput - Get borrows for user on a spoke\nspoke: SpokeId - Spoke IDuser: EvmAddress - User address\nuserToken: UserToken - Get borrows for user for a specific token\nuser: EvmAddress - User addresstoken: Erc20Input - Token input\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\n\nuserPositionId: UserPositionId - Get borrows for a user positionuserChains: UserChains - Get borrows for user across chains\nuser: EvmAddress - User addresschainIds: [ChainId!] - Chain IDs\nuserHub: UserHub - Get borrows for user on hub\nuser: EvmAddress - User addresshub: UserHubInput - Hub input (hub ID or hub details)\n\nrequest.orderBy?: UserBorrowsRequestOrderBy one of:\nassetName: OrderDirection - Sort by asset namecreated: OrderDirection - Sort by creation dateamount: OrderDirection - Sort by borrow amountapy: OrderDirection - Sort by APY\n\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching user borrowsstate.called: boolean - Whether the hook has been calledstate.data: UserBorrowItem[] | undefined - Array of user borrow positionsresult: Result<UserBorrowItem[], UnexpectedError> - Type-safe success or failure value:\nOk<UserBorrowItem[]> - Array of user borrow positionsErr<UnexpectedError> - Error fetching user borrows\n\nuseUserClaimableRewards#\nDeclarative hook to fetch all claimable rewards for a user on a specific chain.\nimport { useUserClaimableRewards } from \"@aave/react\";\nconst { data, loading, error } = useUserClaimableRewards({ pause, ...request,});\nArguments:\nrequest.user: EvmAddress - User addressrequest.chainId: ChainId - Chain IDpause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserClaimableReward[] | undefined - Claimable rewardsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the rewards\n\nuseUserClaimableRewardsAction#\nImperative hook to fetch a user's claimable rewards on demand. Does not watch for updated data; use it to retrieve data as part of a larger workflow.\nimport { useUserClaimableRewardsAction } from \"@aave/react\";\nconst [execute, state] = useUserClaimableRewardsAction();\nconst result = await execute(request);\nArguments:\nrequest.user: EvmAddress - User addressrequest.chainId: ChainId - Chain ID\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching the rewardsstate.called: boolean - Whether the hook has been calledstate.data: UserClaimableReward[] | undefined - Claimable rewardsresult: Result<UserClaimableReward[], UnexpectedError> - Type-safe success or failure value:\nOk<UserClaimableReward[]> - Claimable rewardsErr<UnexpectedError> - Error fetching the rewards\n\nuseUserPosition#\nDeclarative hook to fetch a specific user position by ID.\nimport { useUserPosition } from \"@aave/react\";\nconst { data, loading, error } = useUserPosition({ pause, ...request,});\nArguments:\nrequest.id: UserPositionId - Unique position identifierrequest.user: EvmAddress - User addressrequest.currency?: Currency - Currency for value conversions (optional)request.timeWindow?: TimeWindow - Time window for historical data (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserPosition | null | undefined - User position or null if not foundloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the user position\n\nuseUserPositions#\nDeclarative hook to fetch all user positions across specified chains.\nimport { useUserPositions } from \"@aave/react\";\nconst { data, loading, error } = useUserPositions({ pause, ...request,});\nArguments:\nrequest.user: EvmAddress - User addressrequest.filter: UserPositionsRequestFilter one of:\ntokens: [Erc20Input!] - Filter by tokens\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\nchainIds: [ChainId!] - Filter by chain IDs\nrequest.orderBy?: UserPositionsRequestOrderBy one of:\ncreated: OrderDirection - Sort by creation datebalance: OrderDirection - Sort by position balancenetApy: OrderDirection - Sort by net APYhealthFactor: OrderDirection - Sort by health factornetCollateral: OrderDirection - Sort by net collateral\nrequest.currency?: Currency - Currency for value conversions (optional)request.timeWindow?: TimeWindow - Time window for historical data (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserPosition[] | undefined - Array of user positionsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching user positions\n\nuseUserPositionsAction#\nImperative hook to fetch user positions.\nimport { useUserPositionsAction } from \"@aave/react\";\nconst [execute, state] = useUserPositionsAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)options.timeWindow?: TimeWindow - Time window for historical data (optional)\nArguments:\nrequest.user: EvmAddress - User addressrequest.filter: UserPositionsRequestFilter one of:\ntokens: [Erc20Input!] - Filter by tokens\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\nchainIds: [ChainId!] - Filter by chain IDs\nrequest.orderBy?: UserPositionsRequestOrderBy one of:\ncreated: OrderDirection - Sort by creation datebalance: OrderDirection - Sort by position balancenetApy: OrderDirection - Sort by net APYhealthFactor: OrderDirection - Sort by health factornetCollateral: OrderDirection - Sort by net collateral\n\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching user positionsstate.called: boolean - Whether the hook has been calledstate.data: UserPosition[] | undefined - Array of user positionsresult: Result<UserPosition[], UnexpectedError> - Type-safe success or failure value:\nOk<UserPosition[]> - Array of user positionsErr<UnexpectedError> - Error fetching user positions\n\nuseUserRiskPremiumBreakdown#\nDeclarative hook to fetch the risk premium breakdown for a user position or spoke.\nimport { useUserRiskPremiumBreakdown } from \"@aave/react\";\nconst { data, loading, error } = useUserRiskPremiumBreakdown({ pause, ...request,});\nArguments:\nrequest.user: EvmAddress - User addressrequest.query: UserRiskPremiumBreakdownRequestQuery one of:\nuserPositionId: UserPositionId - Get breakdown for user positionuserSpoke: UserSpokeInput - Get breakdown for user on spoke\nuser: EvmAddress - User addressspoke: SpokeId - Spoke ID\n\npause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserRiskPremiumBreakdownItem[] | undefined - Array of risk premium breakdown itemsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the risk premium breakdown\n\nuseUserSupplies#\nDeclarative hook to fetch all user supply positions.\nimport { useUserSupplies } from \"@aave/react\";\nconst { data, loading, error } = useUserSupplies({ pause, ...request,});\nArguments:\nrequest.query: UserSuppliesRequestQuery one of:\nuserSpoke: UserSpokeInput - Get supplies for user on spoke\nspoke: SpokeId - Spoke IDuser: EvmAddress - User address\nuserToken: UserToken - Get supplies for user for token\nuser: EvmAddress - User addresstoken: Erc20Input - Token input\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\n\nuserPositionId: UserPositionId - Get supplies for user positionuserChains: UserChains - Get supplies for user across chains\nuser: EvmAddress - User addresschainIds: [ChainId!] - Chain IDs\nuserHub: UserHub - Get supplies for user on hub\nuser: EvmAddress - User addresshub: UserHubInput - Hub input (hub ID or hub details)\n\nrequest.orderBy?: UserSuppliesRequestOrderBy one of:\nassetName: OrderDirection - Sort by asset namecreated: OrderDirection - Sort by creation dateamount: OrderDirection - Sort by supply amountapy: OrderDirection - Sort by APY\nrequest.includeZeroBalances?: boolean - Include zero balances (default: false)request.currency?: Currency - Currency for value conversions (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserSupplyItem[] | undefined - Array of user supply positionsloading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching user supplies\n\nuseUserSuppliesAction#\nImperative hook to fetch user supply positions.\nimport { useUserSuppliesAction } from \"@aave/react\";\nconst [execute, state] = useUserSuppliesAction(options);\nconst result = await execute(request);\nOptions:\noptions.currency?: Currency - Currency for value conversions (default: USD)\nArguments:\nrequest.query: UserSuppliesRequestQuery one of:\nuserSpoke: UserSpokeInput - Get supplies for user on a spoke\nspoke: SpokeId - Spoke IDuser: EvmAddress - User address\nuserToken: UserToken - Get supplies for user for a specific token\nuser: EvmAddress - User addresstoken: Erc20Input - Token input\naddress: EvmAddress - Token contract addresschainId: ChainId - Token chain ID\n\nuserPositionId: UserPositionId - Get supplies for a user positionuserChains: UserChains - Get supplies for user across chains\nuser: EvmAddress - User addresschainIds: [ChainId!] - Chain IDs\nuserHub: UserHub - Get supplies for user on hub\nuser: EvmAddress - User addresshub: UserHubInput - Hub input (hub ID or hub details)\n\nrequest.orderBy?: UserSuppliesRequestOrderBy one of:\nassetName: OrderDirection - Sort by asset namecreated: OrderDirection - Sort by creation dateamount: OrderDirection - Sort by supply amountapy: OrderDirection - Sort by APY\n\nReturns:\nstate.loading: boolean - Loading statestate.error: UnexpectedError | undefined - Error fetching user suppliesstate.called: boolean - Whether the hook has been calledstate.data: UserSupplyItem[] | undefined - Array of user supply positionsresult: Result<UserSupplyItem[], UnexpectedError> - Type-safe success or failure value:\nOk<UserSupplyItem[]> - Array of user supply positionsErr<UnexpectedError> - Error fetching user supplies\n\nuseUserSummary#\nDeclarative hook to fetch a user's financial summary.\nimport { useUserSummary } from \"@aave/react\";\nconst { data, loading, error } = useUserSummary({ pause, ...request,});\nArguments:\nrequest.user: EvmAddress - User addressrequest.filter?.spoke.address: EvmAddress - Filter by spoke address (optional)request.filter?.spoke.chainId: ChainId - Filter by chain ID (optional)request.currency?: Currency - Currency for value conversions (optional)request.timeWindow?: TimeWindow - Time window for historical data (optional)pause?: boolean - Pause the query (default: false)\nReturns:\ndata: UserSummary | undefined - Aggregated metrics including total collateral, total debt, health factor, etc.loading: boolean - Loading stateerror: UnexpectedError | undefined - Error fetching the user summary\n\nuseUserSummaryHistory#\nDeclarative hook to fetch user summary history over time.\nimport { useUserSummaryHistory } from \"@aave/react\";\nconst { data, loading, error } = useUserSummaryHistory({ pause, ...request,});\nArguments:\nrequest.user: EvmAddress - User addressrequest.windo","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259087549,"hash":"f51b76a7675764bc3cc5da6fee537b087e7ed142"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/10","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 10 / 11\n\n Jan 2024\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791259091973,"hash":"d5c27699f19741b4cf3225465ded2994000acc39"}
{"url":"https://docs.openzeppelin.com/impact","domain":"docs.openzeppelin.com","title":"OpenZeppelin's Impact and Contributions | OpenZeppelin Docs","text":"OpenZeppelin's Impact and ContributionsOpen in ClaudeFor over a decade, OpenZeppelin has set the foundation for how smart contracts are built, secured, and maintained. Our standards contributions, libraries, tooling, and security services power the protocols, layer 1s and layer 2s, and financial institutions driving the on-chain economy.\nContracts\nOpenZeppelin Contracts is the most adopted smart contract framework in the world, securing trillions in on-chain value.\nThe Impact of OpenZeppelin ContractsFor over ten years, OpenZeppelin Contracts has been the trusted foundation for the global smart contract ecosystemPowering Top Financial InstitutionsThe trusted foundation powering the on-chain economy and securing billions in valueThe Future of OpenZeppelin ContractsAdvancing privacy, chain abstraction, and tokenziation and real world assets\nInnovation and Research\nThe next decade of on-chain innovation will bring regulated finance, privacy-preserving systems, and programmable capital to the same foundation. Building on a decade of impact, OpenZeppelin is extending its standards, contracts libraries, and tooling to support this evolution.\nChain AbstractionCross-chain intents, cross-chain messaging, smart accounts, and zkEmailPrivacyConfidential tokens, private shared state, and private email verifictionTokenization & Real World AssetsPermissioned tokens, confidential tokens, and on-chain yieldThe Impact of OpenZeppelin ContractsNext PageOn this pageContractsInnovation and Research","tokens":376,"squid":"ink-security_audits","role":"Sentinel","at":1791259093914,"hash":"518a1776a47700df8aa57b8bb477d48c285ae20f"}
{"url":"https://aave.com/docs/aave-v4/tools/activities","domain":"aave.com","title":"User Activities | Aave Protocol Documentation","text":"User Activities#\nLearn how to fetch users’ activity records across Aave v4.\n\nView detailed activity history covering supplies, borrows, repayments, withdrawals, liquidations, and swaps, with built-in pagination support.\nActivity Data Structure#\nActivity data provides detailed information about all user activities, including:\nTransaction details: timestamp, transaction hash, chain, amountActivity types: core operations (supply, borrow, withdraw, repay), liquidations, position settings, and swapsUser performing the activityType-specific details like reserve, spoke, and amounts\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the core activity types:type ActivityItem = | BorrowActivity | SupplyActivity | WithdrawActivity | RepayActivity | LiquidatedActivity | UsingAsCollateralActivity | UpdatedDynamicConfigActivity | UpdatedRiskPremiumActivity | TokenSwapActivity | SupplySwapActivity | BorrowSwapActivity | RepayWithSupplyActivity | WithdrawSwapActivity;\nFetching User Activities#\nFetch users' activities with filtering and pagination.\nReactTypeScriptGraphQLUse the useActivities hook to fetch paginated activities for a user.import { type ActivitiesRequest, useActivities } from \"@aave/react\";\nfunction ActivitiesList({ request }: { request: ActivitiesRequest }) { const { data, loading, error } = useActivities(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n // data: PaginatedActivitiesResult return ( <div> {data.items.map((activity) => ( <div key={activity.id}> <h4>{activity.__typename}</h4> <p>Time: {activity.timestamp.toLocaleString()}</p> <p>Tx: {activity.txHash}</p> </div> ))} </div> );}See below some examples of how to use the hook.import { evmAddress, chainId } from \"@aave/react\";\nconst request: ActivitiesRequest = { query: { chainIds: [chainId(1)], }, user: evmAddress(\"0x456…\"),};Filter by specific activity types.import { evmAddress, ActivityType } from \"@aave/react\";\nconst request: ActivitiesRequest = { query: { // your query criteria }, user: evmAddress(\"0x456…\"), types: [ ActivityType.Borrow, ActivityType.Supply, ActivityType.Repay, ActivityType.Withdraw, ],};Finally, you can specify a different time window or currency for the data.import { evmAddress, TimeWindow } from \"@aave/react\";\nconst { data, loading, error } = useActivities({ query: { // your query criteria }, user: evmAddress(\"0x456…\"), timeWindow: TimeWindow.LastWeek,});\nHandle Pagination#\nNavigate through large activity history sets using cursor-based pagination.\nReactTypeScriptGraphQLUse the pagination information from the response to implement next/previous navigation.import { useActivities, evmAddress, chainId, PageSize, type Cursor,} from \"@aave/react\";import { useState } from \"react\";\nfunction PaginatedActivities() { const [cursor, setCursor] = useState<Cursor | null>();\n const { data, loading, error } = useActivities({ query: { chainIds: [chainId(1)] }, user: evmAddress(\"0x456…\"), pageSize: PageSize.Ten, cursor, });\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> <h3>Transaction History</h3> {data.items.map((activity) => ( <div key={activity.id}> <p> {activity.__typename}: {activity.txHash} </p> </div> ))}\n <div> <button onClick={() => setCursor(data.pageInfo.prev)} disabled={!data.pageInfo.prev} > Previous </button> <button onClick={() => setCursor(data.pageInfo.next)} disabled={!data.pageInfo.next} > Next </button> </div> </div> );}\nNetwork Fees#\nFetch the network fee (gas cost) and its historical fiat value for a specific activity transaction.\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nUse the useNetworkFee hook to fetch the network fee for an activity by fetching the transaction receipt and converting the gas cost to both native and fiat amounts.\nimport { type ActivityItem, Currency } from \"@aave/react\";import { useNetworkFee } from \"@aave/react/viem\";\nfunction ActivityFee({ activity }: { activity: ActivityItem }) { const { data: fee, loading, error, } = useNetworkFee({ query: { activity }, currency: Currency.Eur, });\n if (loading) return <p>Loading fee…</p>; if (error) return <p>Error: {error.message}</p>;\n return ( <p> Network Fee: {fee.amount.value.toDisplayString(2)} {fee.token.info.symbol} <span> ≈{fee.exchange.symbol} {fee.exchange.value.toDisplayString(2)} </span> </p> );}\nLike other declarative hooks, the useNetworkFee hook can be used in React Suspense mode and implements pausable mode.\nconst { data: fee } = useNetworkFee({ query: { activity }, currency: Currency.Eur, suspense: true,});PreviousUser BalancesNextExchange Rates","tokens":1183,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259097802,"hash":"8e22fe9789e98e525da8bbc7264554a346f3f5f7"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/9","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 9 / 11\n\n Nov 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791259103126,"hash":"d40bd314bfed4b0a7766f270c8de9f443b14884b"}
{"url":"https://docs.openzeppelin.com/impact/contracts-impact","domain":"docs.openzeppelin.com","title":"The Impact of OpenZeppelin Contracts | OpenZeppelin Docs","text":"ContractsThe Impact of OpenZeppelin ContractsOpen in ClaudeFor over ten years, OpenZeppelin Contracts has been the trusted foundation for the on-chain economy.\nBroad Ecosystem Coverage\nOpenZeppelin Contracts powers secure smart contract development across the leading blockchain ecosystems and continues to be selected to develop contracts libraries for emerging ecosystems.\nEthereum & EVMSmart contracts in SolidityArbitrum StylusHigh-performance smart contracts in Rust on the EVMMidenPrivacy-preserving smart contracts in RustMidnightPrivacy-preserving smart contracts in CompactPolkadotSmart contracts and parachain runtimes for Polkadot and Substrate in SolidityStarknetSmart contracts in CairoStellarSmart contracts in SorobanSuiSmart contracts in MoveUniswap HooksCustomize Uniswap V4 hooks in SolidityZama FHEVMConfidential smart contracts using fully homomorphic encryption in Solidity\nProven Adoption\nOn-Chain Usage and Economic Impact\nOpenZeppelin Contracts is the most deployed and economically significant smart contract framework in the EVM ecosystem. Explore our Dune Data Dashboard for more data.\n$31 trillion+In total value transferred through OpenZeppelin based ERC-20 and native tokens$220 billion+In total value locked, representing 88% market share across top EVM assets155,000+Verified contract deployments across Ethereum and major Layer 2 networks\nAdopted by the Industry’s Most Trusted Protocols\nUsed by the world’s leading financial institutions, DeFi protocols, and blockchain networks, OpenZeppelin Contracts secures trillions in value and remains the most widely adopted smart contract framework in the world.\nMajor Defi and Infrastructure ProtocolsIncluding Lido, Uniswap, Aave, Optimism, Morpho, The Graph, Aerodrome10 of top 10 Tokenized Funds by Market CapitalizationBlackRock BUIDL-I, BlackRock BUIDL, Centrifuge JTRSY, Circle USYC, Franklin BENJI, Ondo OUSG, Ondo USDY, OpenEden TBILL, Superstate USTB, WisdomTree WTGXX8 of top 10 Stablecoins by Market CapitalizationCircle USDC, Ethena USDe, Ethena USDtb, First Digital USD, PayPal USD, Ripple RLUSD, Sky USDS, Usual USD0\nThe Industry’s Developer Standard\nOpenZeppelin has become the benchmark for how modern smart contracts are written, tested, and maintained.\n590,000+Average weekly NPM downloads28,000+ stars and 13,000+ forksAcross all Github repositories\nStandards Contributions\nOpenZeppelin has helped drive standardization in the industry by authoring standards across ecosystems.\nEthereum\n\nERC-1271: Standard Signature Validation Method for Contracts: A standard to verify a signature when the account is a smart contract. OpenZeppelin team members co-authored the standard and built contracts libraries in the OpenZeppelin Solidity Contracts Repo.\nERC-1967: Proxy Storage Slots: A standard for defining a consistent location where proxies store the address of the logic contract they delegate to, as well as other proxy-specific information. OpenZeppelin team members authored the standard and built contracts libraries in the OpenZeppelin Solidity Contracts Repo.\nERC-2771: Secure Protocol for Native Meta Transactions: A standard for a contract interface for receiving meta transactions through a trusted forwarder. OpenZeppelin team members co-authored the standard and built contracts libraries in the OpenZeppelin Solidity Contracts Repo.\n\nStarknet\n\nSNIP-5: Standard Interface Detection: A standard for a standard method to publish and detect what interfaces a smart contract implements. OpenZeppelin team members co-authored the standard and built contracts libraries in the OpenZeppelin Starknet Cairo Contracts Repo.\n\nSNIP-12: Off-Chain Signatures: A standard for hashing and signing typed structured data as opposed to just hexadecimal (or felt) values in Starknet. OpenZeppelin provided feedback on the standard and built contracts libraries in the OpenZeppelin Starknet Cairo Contracts Repo.\n\nStellar\n\nSEP-0049: Upgradeable Contracts: A standard that provides community guidelines and recommendations for safely upgrading the WASM bytecode of Soroban smart contracts. OpenZeppelin team members authored that standard and built contracts libraries in the OpenZeppelin Stellar Soroban Contracts Repo.\n\nSEP-0050: Non-Fungible Tokens: A standard that defines a standard contract interface for non-fungible tokens. OpenZeppelin team members authored that standard and built contracts libraries in the OpenZeppelin Stellar Soroban Contracts Repo.\n\nBattle Tested Libraries\nEvery OpenZeppelin library represents over a decade of security expertise, community validation, and real-world production use.\nLibraryPurposeNetworks SupportedNumber of DeploymentsPopular ImplementationsExample UseTokensIssue and manage digital assetsEVM, Stellar, Starknet, Arbitrum Stylus, Midnight, Zama150,000+ (over $30 trillion in total value transferred!)ERC-20, ERC-721, ERC-1155, ERC-4626, ERC-6909Circle USDC, Ondo OUSG, LidoUtilitiesImprove security, work with new data types, or safely use low-level primitivesEVM, Stellar, Starknet, Arbitrum Stylus, Midnight, Zama, Uniswap Hooks150,000+Cryptography, math, data integrityEthena USDe, Pallas Fund USDtb, Graph ProtocolAccess ControlManage who can perform specific actions, when they can do so, and under what authorityEVM, Stellar, Starknet, Arbitrum Stylus, Midnight115,000+Access Control, OwnableLido, Circle USDC, BlockRock BUIDL-IProxies & UpgradabilitySecure contract upgrades without disrupting stateEVM, Starknet, Arbitrum Stylus75,000+Transparent Proxy, UUPS Proxy, Beacon ProxyLido, Sky USDS, BlackRock BUIDL-IGovernanceDecentralized decision-making and controlled executionEVM, Starknet, Zama.1,000+GovernorArbitrum DAO\nWhat’s Next?\nLearn more about the future of OpenZeppelin Contracts.OverviewPrevious PagePowering Top Financial InstitutionsNext PageOn this pageBroad Ecosystem CoverageProven AdoptionOn-Chain Usage and Economic ImpactAdopted by the Industry’s Most Trusted ProtocolsThe Industry’s Developer StandardStandards ContributionsEthereumStarknetStellarBattle Tested LibrariesWhat’s Next?","tokens":1511,"squid":"ink-security_audits","role":"Sentinel","at":1791259103922,"hash":"595d74691283406f7007457019c0fd5c3d23bb09"}
{"url":"https://aave.com/docs/aave-v4/positions/fetch","domain":"aave.com","title":"Aave Open Positions | Aave Protocol Documentation","text":"User Positions#\nLearn how to fetch and monitor user positions on Aave v4.\n\nEach user position captures a user’s activity within a Spoke, simplifying health and performance tracking.\nUser Positions#\nData Structure#\nUser position data provides comprehensive information about a user's lending and borrowing activity on a specific spoke, including:\nIdentification: id, user, spoke, creation timestampPosition balances: supplied amounts, collateral amounts, debt amounts, net balancesYield information: supply APY, borrow APY, net APY, net interestsRisk metrics: health factor, user risk premium breakdown, liquidation price, maximum and remaining borrowing powerPerformance data: net balance percentage changes over time\nTypeScriptGraphQLSolidityThe following TypeScript interfaces illustrate the core UserPosition type:interface UserPosition { __typename: \"UserPosition\"; id: UserPositionId; user: EvmAddress; createdAt: Date; spoke: Spoke; totalSupplied: ExchangeAmountWithChange; totalCollateral: ExchangeAmountWithChange; totalDebt: ExchangeAmountWithChange; netBalance: ExchangeAmountWithChange; netCollateral: ExchangeAmountWithChange; netApy: PercentNumber; netSupplyApy: PercentNumberWithChange; netBorrowApy: PercentNumberWithChange; netAccruedInterest: ExchangeAmount; healthFactor: HealthFactorWithChange; riskPremium: UserPositionRiskPremium | null; liquidationPrice: ExchangeAmount | null; maxBorrowingPower: ExchangeAmount; remainingBorrowingPower: ExchangeAmount; canUpdateDynamicConfig: boolean; netBalancePercentChange: PercentNumber; averageCollateralFactor: PercentNumber;}\nSee the Spoke Data Structure for more details.\nListing User Positions#\nFetch all user positions with filtering and ordering options.\nReactTypeScriptGraphQLSolidityUse the useUserPositions hook to fetch positions for a given user address.import { type UserPositionsRequest, useUserPositions } from \"@aave/react\";\nfunction UserPositionsList({ request }: { request: UserPositionsRequest }) { const { data, loading, error } = useUserPositions(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((position) => ( <div key={position.id}> <h3>Position on {position.spoke.name}</h3> <p>Chain: {position.spoke.chain.name}</p> </div> ))} </div> );}You can filter positions by the following criteria:import { evmAddress, chainId } from \"@aave/react\";\nconst request: UserPositionsRequest = { user: evmAddress(\"0x456…\"), filter: { chainIds: [chainId(1)], },};And you can sort positions as follows:import { OrderDirection } from \"@aave/react\";\nconst request: UserPositionsRequest = { user: evmAddress(\"0x456…\"), filter: { // your filter criteria }, orderBy: { balance: OrderDirection.Asc },};Finally, you can specify a different time window or currency for the data.import { evmAddress, chainId, TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useUserPositions({ user: evmAddress(\"0x456…\"), filter: { // your filter criteria }, timeWindow: TimeWindow.LastWeek,});\nFetching a Single Position#\nFetch a specific user position.\nReactTypeScriptGraphQLSolidityUse the useUserPosition hook to fetch a specific user position.import { type UserPositionRequest, useUserPosition } from \"@aave/react\";\nfunction UserPositionDetail({ request }: { request: UserPositionRequest }) { const { data, loading, error } = useUserPosition(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n if (!data) return <div>Position not found</div>;\n return ( <div> <h2>Position {data.id}</h2> <p>Net Balance: {data.netBalance.amount.value.toDisplayString(2)}</p> <p>Health Factor: {data.healthFactor.value.toFixed(2)}</p> </div> );}See below for examples of UserPositionRequest objects.import { userPositionId } from \"@aave/react\";\nconst request: UserPositionRequest = { id: userPositionId(params.id), // UserPositionId - typically from URL params};And you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useUserPosition({ // your query criteria timeWindow: TimeWindow.LastWeek,});\nUser Supplies#\nData Structure#\nUser supply data provides detailed information about individual user supplies within a spoke, including:\nReserve details: token information, supply APY, lending limitsPosition amounts: current balance, principal, earned interest, and withdrawable amountsCollateral status: whether the supply is used as collateralPerformance metrics: earned interest over time\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the UserSupplyItem type:interface UserSupplyItem { __typename: \"UserSupplyItem\"; id: UserSupplyItemId; reserve: Reserve; principal: Erc20Amount; balance: Erc20Amount; withdrawable: Erc20Amount; interest: Erc20Amount; isCollateral: boolean;}\nSee the Reserve Data Structure for more details.\nFetching User Supplies#\nFetch user supplies within a specific spoke.\nReactTypeScriptGraphQLSolidityUse the useUserSupplies hook to fetch user supplies for a user.import { type UserSuppliesRequest, useUserSupplies } from \"@aave/react\";\nfunction UserSuppliesList({ request }: { request: UserSuppliesRequest }) { const { data, loading, error } = useUserSupplies(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((supply) => ( <div key={supply.id}> <h3>{supply.reserve.asset.underlying.info.name}</h3> <p>Amount: {supply.withdrawable.amount.value.toDisplayString(2)}</p> </div> ))} </div> );}See below for examples of UserSuppliesRequest objects.const request: UserSuppliesRequest = { query: { userPositionId: position.id, // position: UserPosition },};Sort user supplies by asset name, amount, or supply APY.import { OrderDirection } from \"@aave/react\";\nconst request: UserSuppliesRequest = { query: { // your query criteria }, orderBy: { assetName: OrderDirection.Asc },};Include zero-value entries for all other supply reserves available on the same spoke, typically ordered by descending amount.import { OrderDirection } from \"@aave/react\";\nconst request: UserSuppliesRequest = { query: { // your query criteria }, includeZeroBalances: true, orderBy: { amount: OrderDirection.Desc },};Finally, you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useUserSupplies({ query: { // your query criteria }, timeWindow: TimeWindow.LastWeek,});\nUser Borrows#\nData Structure#\nUser borrow data provides detailed information about individual borrow positions within a spoke, including:\nReserve details: token information, borrow APY, borrowing limitsPosition amounts: borrowed amounts, repaid amounts, and token detailsDebt tracking: outstanding debt and payment historyPerformance metrics: interest owed and payment progress\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the UserBorrowItem type:interface UserBorrowItem { __typename: \"UserBorrowItem\"; id: UserBorrowItemId; reserve: Reserve; principal: Erc20Amount; debt: Erc20Amount; interest: Erc20Amount;}\nSee the Reserve Data Structure for more details.\nFetching User Borrows#\nFetch user borrows within a specific spoke.\nReactTypeScriptGraphQLSolidityUse the useUserBorrows hook to fetch borrow positions for a user.import { type UserBorrowsRequest, useUserBorrows } from \"@aave/react\";\nfunction UserBorrowsList({ request }: { request: UserBorrowsRequest }) { const { data, loading, error } = useUserBorrows(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> {data.map((borrow) => ( <div key={borrow.id}> <h3>{borrow.reserve.asset.underlying.info.name}</h3> <p>Amount: {borrow.debt.amount.value.toDisplayString(2)}</p> </div> ))} </div> );}See below for examples of UserBorrowsRequest objects.const request: UserBorrowsRequest = { query: { userPositionId: position.id, // position: UserPosition },};Sort user borrows by asset name, amount, or borrow APY.import { OrderDirection } from \"@aave/react\";\nconst request: UserBorrowsRequest = { query: { // your query criteria }, orderBy: { assetName: OrderDirection.Asc },};Finally, you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useUserBorrows({ query: { // your query criteria }, timeWindow: TimeWindow.LastWeek,});Include zero-value entries for all other borrow reserves available on the same spoke, typically ordered by descending amount.import { OrderDirection } from \"@aave/react\";\nconst { data, error, loading } = useUserBorrows({ query: { // your query criteria }, includeZeroBalances: true, orderBy: { amount: OrderDirection.Desc },});\nUser Summary#\nData Structure#\nUser summary data provides comprehensive information about a user's aggregated activity across all positions, including:\nPosition count: total number of positions held by the userPortfolio totals: supplied amounts, collateral amounts, debt amounts, net balancesYield information: calculated net APY across all positionsRisk metrics: lowest health factor across all positionsPerformance data: net fee earned over time\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the UserSummary type:interface UserSummary { __typename: \"UserSummary\"; totalPositions: number; netBalance: ExchangeAmountWithChange; totalCollateral: ExchangeAmount; totalSupplied: ExchangeAmount; totalDebt: ExchangeAmount; netApy: PercentNumber; netAccruedInterest: ExchangeAmount; lowestHealthFactor: BigDecimal | null;}\nFetching User Summary#\nFetch a comprehensive financial summary for a user across all their positions.\nReactTypeScriptGraphQLUse the useUserSummary hook to fetch the financial summary for a user.import { type UserSummaryRequest, useUserSummary } from \"@aave/react\";\nfunction UserSummaryDisplay({ request }: { request: UserSummaryRequest }) { const { data, loading, error } = useUserSummary(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> <h2>Financial Summary</h2> <p>Total Positions: {data.totalPositions}</p> <p> Net Balance: {data.netBalance.current.symbol} {data.netBalance.current.value.toDisplayString(2)} </p> <p> Total Supplied: {data.totalSupplied.symbol} {data.totalSupplied.value.toDisplayString(2)} </p> <p> Total Debt: {data.totalDebt.symbol} {data.totalDebt.value.toDisplayString(2)} </p> <p>Net APY: {data.netApy.normalized.toFixed(2)}%</p> </div> );}See below for examples of UserSummaryRequest objects.import { evmAddress } from \"@aave/react\";\nconst request: UserSummaryRequest = { user: evmAddress(\"0x456…\"),};And you can specify a different time window or currency for the data.import { TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useUserSummary({ user: evmAddress(\"0x456…\"), timeWindow: TimeWindow.LastWeek,});\nUser Summary History#\nData Structure#\nUser summary history data provides detailed information about a user's activity changes over time, including:\nHistorical snapshots: portfolio state at different points in timePortfolio metrics: net balance, borrows, supplies at each snapshotRisk metrics: health factor changes over time\nTypeScriptGraphQLThe following TypeScript interfaces illustrate the UserSummaryHistoryItem type:interface UserSummaryHistoryItem { __typename: \"UserSummaryHistoryItem\"; netBalance: ExchangeAmount; borrows: ExchangeAmount; supplies: ExchangeAmount; healthFactor: BigDecimal | null; date: Date;}\nFetching User Summary History#\nFetch historical financial data for a user over a specified time window.\nReactTypeScriptGraphQLUse the useUserSummaryHistory hook to fetch historical financial data for a user.import { type UserSummaryHistoryRequest, useUserSummaryHistory,} from \"@aave/react\";\nfunction UserSummaryHistory({ request,}: { request: UserSummaryHistoryRequest;}) { const { data, loading, error } = useUserSummaryHistory(request);\n if (loading) return <div>Loading…</div>;\n if (error) return <div>Error: {error.message}</div>;\n return ( <div> <h2>Financial History</h2> {data.map((item) => ( <div key={item.date.toString()}> <p>Date: {item.date.toLocaleDateString()}</p> <p> Net Balance: {item.netBalance.symbol} {item.netBalance.value.toDisplayString(2)} </p> <p> Supplies: {item.supplies.symbol} {item.supplies.value.toDisplayString(2)} </p> <p> Borrows: {item.borrows.symbol} {item.borrows.value.toDisplayString(2)} </p> </div> ))} </div> );}See below for examples of UserSummaryHistoryRequest objects.import { evmAddress, TimeWindow } from \"@aave/react\";\nconst request: UserSummaryHistoryRequest = { user: evmAddress(\"0x456…\"), window: TimeWindow.LastDay,};Filter the history by specific spokes or chains.import { evmAddress, TimeWindow } from \"@aave/react\";\nconst request: UserSummaryHistoryRequest = { user: evmAddress(\"0x456…\"), window: TimeWindow.LastWeek, filter: { spokeId: spoke.id, },};Specify a different currency for displaying fiat amounts.import { Currency, evmAddress, TimeWindow } from \"@aave/react\";\nconst { data, error, loading } = useUserSummaryHistory({ user: evmAddress(\"0x456…\"), window: TimeWindow.LastWeek, currency: Currency.Eur,});PreviousUser PositionsNextSupply Assets","tokens":3320,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259108917,"hash":"00c61cb16c655c8c2638dab17535b264a1966ea7"}
{"url":"https://ethresear.ch/t/is-this-desk-lacking-administration/17249/3","domain":"ethresear.ch","title":"Is this desk lacking administration? - Administrivia - Ethereum Research","text":"Administrivia\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Oct 2023\n\n 3 / 11\n\n Oct 2023\n\n Jan 2024\n\n post by peersky on Oct 30, 2023\n\n peersky\n\n Many topics and even categories seem to be outdated;\nThe links from read me are outdated like these notes are last updated like 6 years ago:\n\nI actually lack to have such a well organised and up to date notes.\nIs there is anything I (or community) can do about to help to keep this data up to date and maintained?\nSame relates to forum categories etc - is eWASM project still active?\n\n 4\n\n 2\n\n post by Olshansky on Oct 30, 2023\n\n Olshansky\n\n +1 to what @peersky said.\nIn particular, all the work our protocol team is doing (research & development) is entirely open source, so the opportunity to apply for a grant from Ethereum Foundation would be very much appreciated.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n eWASM is now a thing of the past, and we all know what happened. However, I do not believe that the forum needs any changes. Here, you can witness the history of Ethereum-related research and the evolution of ideas. They are well-preserved here for you to explore the journey of Ethereum’s development. Of course, you can apply to open a new section if it meets the criteria for establishing a new section. You can also integrate them all into your personal homepage.\n\n post by maniou-T on Oct 31, 2023\n\n maniou-T\n\n Collect good projects in a dedicated section and pin them to make it easy for everyone to see. It should facilitate updates for everyone. After some time, inquire with users about any progress. However, this idea needs community assistance.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n Mirror\n\n It’s great to have museum to let everyone learn history lessons, but it must be organised and appropriately tagged as closed/deprecated and explained reasoning, so that this desk can be effective in onboarding new researchers and contributors. I also think It is important to move forward no matter what happens - decentralised community should be autonomous in a sense of maintaining data of it’s own.\nPS. Not everybody knows. Right now if you read the roadmap and about eWASM you might have a feeling that EVM is being deprecated. It creates great confusion.\n\n post by peersky on Oct 31, 2023\n\n peersky\n\n maniou-T\n\n Primary request for roadmap update is to give exposure of what E.F. and collaborators are doing, what are current plans for tools in place.\nThis requires someone from E.F to organise such a notes. Right now information available on Ethereum.org roadmap does not feel inclusive enough and leaves too many open questions.\nThese could be answered by publishing more in detail information, which Im looking in this forum.\n\n post by Mirror on Oct 31, 2023\n\n Mirror\n\n peersky\n\n Now I am turning to support your viewpoint and inviting more people to join.\n\n post by luca on Nov 4, 2023\n\n luca\n\n peersky\n\n I have no idea of what happened to eWASM, so it would def be beneficial to the community, especially newcomers to have a higher level of curation for the Ethereum research roadmap.\n\n 8 days later\n\n post by daniejjimenez on Nov 13, 2023\n\n daniejjimenez\n\n Community support is key to organising everything here…count on me for any contribution.\n\n 2 months later\n\n post by jamesbayly on Jan 9, 2024\n\n jamesbayly\n\n I’m trying to contribute to the discussion on here but it appears that for new users there’s no obvious way to get permissions to create topics.\nThere is no clear onboarding requirement in the FAQs on how to level up the trust requirements\nThere is no way to contact moderators or admins, since new users don’t have any ability to send DMs, and there is no documented support/contact us process?\n\n post by peersky on Jan 12, 2024\n\n peersky\n\n I invite everyone to propose particular improvements so that we can fetch improvement requirements list.\nHere is mine:\nImprovement proposal\nAdministrivia / Read This Before Positing\n\nOnboarding packets for potential collaborators\n– Update all outdated materials\n– Add “Contribution guideline” for landing page\nUseful sites:\n– Rename public wiki to ethereum.org to avoid existing redirect\n– Remove ethereum.notes from public links (It is a restricted access resource)\n– Elaborate readme for research github repo\n– Remove or update deprecated link to https://swag.ethereum.org/\n– Move ENS forum link in to Sybil Boards section (see next bullet point)\nAdd “Sybil Boards” section describing other resources that are part of Ethereum ecosystem:\n– ENS forum (from useful sites)\n– Magicians forum\n– Reddit discussion space\n– StackExchange technical question space\n– Any other that might appear over last years (add your ideas)\n\nCategories\n\nabout <CATEGORY_NAME> posts - Fill in content there, most of categories pinned posts have no useful material inside\nApplications - Remove eWASM subcategory (if it’s deprecated)\n\n Powered by Discourse","tokens":1225,"squid":"ink-research","role":"Deep Scholar","at":1791259113535,"hash":"99c10df01e0aca18c878daaf7adadafde78bfeb1"}
{"url":"https://docs.openzeppelin.com/impact/contracts-for-financial-institutions","domain":"docs.openzeppelin.com","title":"OpenZeppelin Contracts for Financial Institutions | OpenZeppelin Docs","text":"ContractsOpenZeppelin Contracts for Financial InstitutionsOpen in ClaudeOpenZeppelin Contracts is the trusted foundation powering the on-chain economy.\nUsed by the world’s leading stablecoin issuers, asset managers, and on-chain funds, OpenZeppelin provides the security-audited, production-proven contracts trusted to secure billions in value.\nCategoryCoverageValue SecuredExamplesTokenized Funds10 of the top 10 by market capitalizationOver $5 billionBlackRock BUIDL-I, Circle USYC, Franklin BENJIStablecoins8 of the top 10 by market capitalizationOver $55 billionCircle USDC, Ethena USDe, Sky USDS\nPowering Top Institutions\nTokenized Funds\nTrusted by 10 of the top 10 Tokenized Funds by Market Capitalization.\nThe standard for compliant, programmable representation of the world’s most trusted asset class.\nTokenized FundTokensPermissionsUpgradeabilityUtilitiesBlackRock BUIDL-I🪙🔐♻️🧰BlackRock BUIDL🪙🧰Centrifuge JTRSY🪙🧰Circle USYC🪙🔐♻️🧰Franklin BENJI🔐♻️🧰Ondo OUSG🪙🔐♻️🧰Ondo USDY🪙🔐♻️🧰OpenEden TBILL🪙🔐♻️🧰Superstate USTB🪙🔐♻️🧰WisdomTree WTGXX🔐🧰\nStablecoins\nTrusted by 8 of the top 10 Stablecoins by Market Capitalization.\nThe secure foundation behind the digital assets that power payments, settlement, and global liquidity.\nStablecoinTokensPermissionsUpgradeabilityUtilitiesCircle USDC🪙🔐♻️🧰Ethena USDe🪙🔐🧰Ethena USDtb🪙🔐♻️🧰First Digital USD🪙🔐♻️🧰PayPal USD🔐♻️🧰Ripple RLUSD🪙🔐♻️🧰Sky USDS♻️🧰Usual USD0🪙🔐♻️🧰\nNext Evolution of Smart Contracts\nThe next era of smart contracts will be defined by compliance and privacy.\nOpenZeppelin is shaping that future by co-developing open standards and contract frameworks that enable regulated, confidential, and yield-bearing financial systems. Learn more about tokenization and real world assets at OpenZeppelin\nFocus AreaPurposeStandardsAssociationsNetworks SupportedPermissioned TokensEnforce compliant issuance and management of institutional-grade digital assets.ERC-3643: T-REX – Token for Regulated Exchanges3643 Association (member)EVM, Stellar, EVM confidential (Zama)Confidential TokensConfidential value transfers with full auditability using encrypted pointersERC-7984: Confidential Fungible TokenConfidential Token Association (founding member)EVM confidential (Zama)Yield Bearing VaultsYield generation and tokenized depositsERC-4626: Tokenized VaultsEVM, EVM (with fees), Stellar, Starknet\nBattle Tested Contracts\nEvery OpenZeppelin library represents over a decade of security expertise, community validation, and production use.\nTokens\nDefine and manage on-chain assets.\nOur libraries provide the secure, extensible foundation for issuing, controlling, and auditing digital assets.\nStandard / ExtensionPurposeExample Use (Stablecoin, Tokenized Fund, Defi)Number of DeploymentsNetworks SupportedFungible Tokens (ERC-20)Base standard for digital assetsCircle USDC, Ondo OUSG, Lido150,000+ ($30 trillion+ in total value transferred!)EVM, Stellar, Starknet, Arbitrum StylusPermit (ERC-2612)Gasless transfer approvals through signatures to streamline user experienceEthena USDe, BlackRock BUIDL-I, Optimism35,000+EVM, Starknet, Arbitrum StylusMetadataProvide information about the token, including name, symbol, and decimalsEthena USDe, Ondo OUSG, Uniswap30,000+EVM, Arbitrum StylusPausablePause contract or transfers during emergencies or upgrades to reduce operational and systemic riskFirst Digital Labs FDUSD, Ondo USDY, Morpho17,000+EVM, Stellar, StarknetBurnableDestroy tokens to support supply control, redemptions, or error recoveryEthena USDe, Ondo OUSG, Aave2,000+EVM, Stellar, Arbitrum StylusFreezableFreeze specific accounts or tokens to help enforce sanctions, compliance holds, or fraud mitigation--EVMRestrictedTransfer restrictions, including blacklisting and/or whitelisting, to ensure only approved entities can interact with the token as defined by compliance policy--EVM\nPermissions\nDefine who can perform specific actions, when they can do so, and under what authority.\nOur libraries provide flexible, auditable permissions for enforcing operational, compliance, and governance policies on-chain.\nImplementationPurposeExample Use (Stablecoin, Tokenized Fund, Defi)Number of DeploymentsNetworks SupportedOwnableMinimal governance model providing a single administrative authorityCircle USDC, BlackRock BUIDL-I, Aave80,000+EVM, Stellar, Starknet, Arbitrum StylusAccess ControlRole-based governance which supports structured permissioning and multiple roles for operational teamsEthena USDtb, Ondo OUSG, Aerodrome35,000+EVM, Stellar, Starknet, Arbitrum Stylus\nUpgradability\nSecurely upgrade contract logic without disrupting state or user trust.\nOur libraries implement proven proxy patterns that support controlled evolution under defined governance rules.\nImplementationPurposeExample Use (Stablecoin, Tokenized Fund, Defi)Number of DeploymentsNetworks SupportedBeacon ProxyCoordinated upgrades across multiple contracts through a shared beacon, allowing system-wide upgrades in a single transaction.Sky USDS, BlackRock BUIDL-I75,000+EVM, Arbitrum StylusTransparent ProxyAdministrator-managed upgrades with strict separation between users and governanceEthena USDtb, Ondo OUSG, Lido9,000+EVMUUPS ProxyLightweight upgrade pattern where governance controls upgrade logic directlyPayPal PYUSD, Circle USYC, Morpho4,000+EVM, Arbitrum Stylus\nUtilities\nLibraries for precision, reliability, and data integrity across all operations.\nOur libraries provide functions for cryptography, math, and data integrity, safeguarding every calculation and transaction on-chain.\nImplementationPurposeExample Use (Stablecoin, Tokenized Fund, Defi)Number of DeploymentsNetworks SupportedData IntegritySafe primitives such as storage, context, and verification to prevent data corruption or manipulationEthena USDtb, BlackRock BUIDL-I, Graph Protocol150,000+EVM, Stellar, StarknetMathEnsures precision arithmetic and overflow protection for on-chain calculationsEthena USDe, BlackRock BUIDL-I, Morpho65,000+EVM, Stellar, StarknetCryptographySafe primitives such as ECDSA, Merkle proofs, and signature verification for secure identity and transaction validationCircle USDC, Superstate USTB, Graph Protocol45,000+EVM, Stellar, Starknet\nTalk to an Expert\nWhether you’re launching a stablecoin, tokenizing assets, or building institutional-grade infrastructure, our team can help you design with security, compliance, and scalability from day one.\nConnect with OpenZeppelin experts to discuss your project, evaluate architectures, and access the libraries and audits trusted by the world’s leading financial institutions.\nTalk to an ExpertThe Impact of OpenZeppelin ContractsPrevious PageThe Future of OpenZeppelin ContractsNext PageOn this pagePowering Top InstitutionsTokenized FundsStablecoinsNext Evolution of Smart ContractsBattle Tested ContractsTokensPermissionsUpgradabilityUtilitiesTalk to an Expert","tokens":1722,"squid":"ink-security_audits","role":"Sentinel","at":1791259114020,"hash":"8588074fd72bb5ec7624de9d5a6a2cd2b07ff3a6"}
{"url":"https://aave.com/privacy-policy","domain":"aave.com","title":"Privacy Policy | Aave","text":"The Aave Protocol operates in a decentralized and permissionless manner. Although we may collect and process information about users of Aave.com or the Interface in accordance with this Privacy Policy, we do not have information about all protocol users beyond what is already publicly available and recorded on the blockchain.\nThis Privacy Policy (the \"Privacy Policy\") explains how the Aave Labs (\"we,\" \"our,\" or \"us\") collects, uses, and shares information in connection with our Services as well as your rights and choices regarding such information in accordance with applicable data protection legislation, including the Data Protection Act (as amended) of the Cayman Islands (together, \"Data Protection Legislation\". These terms apply to Aave.com and the Interface and any other online location that links to this Privacy Policy (collectively, the \"Services\").\nBy using the Services, you also agree to our collection, use, and sharing of your information as described in this Privacy Policy. If you do not agree with the Terms of Use, you should not use or access the Interface or the Services.\nIf you are an individual, this Privacy Policy will be relevant to you directly. If you are an entity or arrangement that provides us with personal data on individuals connected to you for any reason, this Privacy Policy will be relevant for those individuals and you should transmit this Privacy Policy to such individuals or otherwise advise them of its content.\n1. Information Collection\nA. Information You Provide.\nWe may collect the following information about you when you use the Services:\n\nCorrespondence and Content: When you contact us for support or other inquiries, you may share with us your contact details and contextual information relevant to your issue (such as wallet type, token or transaction details, device type, or error codes). This helps us respond and improve the Services.\n\nYou may choose to voluntarily provide other information to us that we have not solicited from you, and, in such instances, you are solely responsible for such information.\nB. Information Collected Automatically.\nWe collect the following information:\n\nWallet Address: We may collect the wallet address you use to connect to the Interface to block wallets that are associated with certain legally prohibited conduct from Interface. Separately, we may collect your wallet address as part of \"Usage Information\" (as described below) to improve the Interface and user experience of the Services.\n\nDevice Information: We may collect information about the device you use to access the Interface, such as the device type, operating system, browser type, and screen height and width. This information helps us optimize the Interface for different devices and troubleshoot any technical issues.\n\nUsage Information: We may collect information about how you use the Interface and Services, including your wallet address, the time you access the Interface, pages you visit, the features and assets you interact with, the links you click, and the search queries you make. By analyzing this data, we gain a deeper understanding of user behavior, which in turn allows us to make continuous improvements to the Interface and enhance the overall user experience.\n\nWe will not take decisions producing legal effects concerning you, or otherwise significantly affecting you, based solely on automated processing of your personal data, unless we have considered the proposed processing in a particular case and concluded in writing that it meets the applicable requirements under the Data Protection Legislation.\nFor further information on how we use tracking technologies for analytics and your rights and choices regarding them, please see the \"Cookies Policy\" and \"Analytics\" sections below.\n2. Use of Information\nWe may collect and use information for our legitimate business purposes in accordance with the practices described in this Privacy Policy, including where this is necessary for the performance of a contract, where this is necessary for compliance with applicable legal or regulatory obligations or otherwise in pursuance of our legitimate interests or those of a third party to whom your personal data is disclosed. In particular, our business purposes for collecting and using information includes, but is not limited to:\n\nOperating and managing the Services (including through authorized service providers): To make the Services available to you and perform services requested by you, such as responding to your comments, questions, and requests, and providing information support; sending you technical notices, updates, security alerts, information regarding changes to our policies, and support, administrative messages; detecting, preventing, and addressing fraud, breach of Terms, and threats, or harm; and compliance with legal and regulatory requirements.\n\nImproving the Services: To continually improve the Services and fulfill any other legitimate business purpose, as permitted under applicable laws.\n\nMerger or Acquisition: In connection with, or during negotiations of, any proposed or actual merger, purchase, sale, or any other type of acquisition, financing, reorganization, or business combination of all or any portion of our assets, or transfer of all or a portion of our business to another business.\n\nSecurity and Compliance with Laws: As we believe necessary or appropriate to operate and maintain the security or integrity of the Interface, including to prevent or stop an attack on our computer systems or networks, investigate possible wrongdoing in connection with the Interface, enforce our Terms, and comply with applicable laws, lawful requests, and legal process, such as responding to subpoenas or requests from government authorities.\n\nFacilitating Requests: To comply with your requests or directions.\n\nConsent: Purposes for which we have obtained your consent, as required by applicable laws.\n\nNotwithstanding the above, we may use information that does not identify you (including information that has been aggregated or de-identified) for any purpose except as prohibited by applicable law. For information on your rights and choices with respect to how we use information about you, please see the \"Analytics\" section below.\n3. Sharing and Disclosure of Information\nWe may share or disclose information that we collect in accordance with the practices described in this Privacy Policy and for the purposes set out in the \"Use of Information\" section above.\nThe categories of parties with whom we may share information include:\n\nAffiliates: We share information with our affiliates and related entities, including where they act as our service providers or for their own internal purposes.\n\nProfessional Advisors: We share information with our professional advisors for purposes of audits and compliance with our legal obligations.\n\nService Providers: We share information with third-party service providers for business purposes, including fraud detection and prevention, security threat detection, data analytics, information technology and storage, and blockchain transaction monitoring. Any information shared with such service providers is subject to the terms of this Privacy Policy. All service providers that we engage with are restricted to only utilizing the information on our behalf and in accordance with our instructions.\n\nRegulatory and government authorities: In certain circumstances, we may be legally obliged to share your personal data and other information with relevant regulatory or governmental authorities. The professional advisors and service providers noted above are generally processors acting on the instructions of the us, however a professional advisor or service provider may use your personal data where this is necessary for compliance with a legal obligation to which it is directly subject and, in respect of this specific use of personal data, may be deemed to be acting as a data controller in its own right.\n\nNotwithstanding the above, we may share information that does not identify you (including information that has been aggregated or de-identified) except as prohibited by applicable law.\n4. Third-Party Services\nWe may also integrate technologies operated or controlled by other parties into parts of the Services. For example, the Services may include links that hyperlink to websites, platforms, and other services not operated or controlled by us.\nPlease note that when you interact with other parties, including when you leave the Interface, those parties may independently collect information about you and solicit information from you. The information collected and stored by those parties remains subject to their own policies and practices, including what information they share with us, your rights and choices on their services and devices, and whether they store information in the U.S. or elsewhere. We encourage you to familiarize yourself with and consult their privacy policies and terms of use.\nFor example, by using a third-party wallet to engage in transactions on public blockchains, your interactions with any third-party wallet provider are governed by the applicable terms of service and privacy policy of that wallet provider.\n5. Cookies Policy\nWe understand that your privacy is important to you and are committed to being transparent about the technologies we use. In the spirit of transparency, this Cookies Policy provides detailed information about how and when we use cookies on our Services.\nA. Do we use cookies?\nWe do not use cookies. If we were, we would use cookies and other technologies to understand how you use our Interface so we can improve its design and functionality (to ensure everyone who uses the Interface has the best possible experience).\nWhat is a cookie?\nA cookie is a small text file that is placed on your hard drive by a web page server. Cookies contain information that can later be read by a web server in the domain that issued the cookie to you. Some of the cookies will only be used if you use certain features or select certain preferences, and some cookies will always be used. You can find out more about each cookie by viewing our current cookie list below. We update this list periodically, so there may be additional cookies that are not yet listed.\nB. Why would we use cookies?\nWe use cookies and other similar identifiers only to compile aggregate data about Interface traffic and site interaction to offer better user experiences and tools in the future.\nC. What types of cookies do we use?\n\nStrictly Necessary Cookies: These cookies are essential for the Interface to function properly and enable basic features such as page navigation and access to secure areas of the site. They do not collect personal information.\n\nAnalytical/Performance Cookies: These cookies allow us to analyze how visitors use the Interface, which helps us improve its functionality and performance.\n\nFunctional Cookies: These cookies enable enhanced functionality and personalization of the website. They may remember your preferences, such as the wallet you previously used to connect.\n\nD. How to disable cookies?\nUsers can generally activate or later deactivate the use of cookies through a functionality built into your web browser. If you want to learn more about cookies, or how to control, disable, or delete them, please visit http://www.aboutcookies.org for detailed guidance.\n6. Analytics\nWe utilize the Amplitude (on the Aave Interface) and Fathom Analytics (on Aave.com) as the analytics platforms to track user interactions, preferences, and behavior during browsing sessions for users who have opted in for analytics. This data helps us improve our services and analyze trends in our user base. We respect your right to control the data collected during your browsing session. If you prefer not to participate in our tracking techniques and data collection, you can opt-out through the \"Manage Analytics\" section on this page or adjust your browser settings or use browser extensions designed for this purpose.\n7. Data Security\nWe implement and maintain reasonable administrative, physical, and technical security safeguards to help protect information about you from loss, theft, misuse, unauthorized access, disclosure, alteration, and destruction. Nevertheless, transmission via the Internet is not completely secure and we cannot guarantee the security of information about you.\n8. Data Retention\nPlease note that we retain information we collect as long as it is necessary to fulfill the purpose for which it was collected, as outlined in this Privacy Policy, and to the extent permitted by applicable legal requirements. Where you request the deletion of your information, we may continue to retain and use your information as permitted or required under applicable laws, for legal, tax, or regulatory reasons, or legitimate and lawful business purposes.\nWe expect to delete your personal data (at the latest) once there is no longer any legal or regulatory requirement or legitimate business purpose for retaining your personal data.\n9. International Transfers\nPlease be aware that information collected through the Services may be transferred to, processed, stored, and used in the Cayman Islands, European Economic Area, the United Kingdom, and other jurisdictions. Data protection laws in the Cayman Islands, EU and other jurisdictions may be different from those of your country of residence. Your use of the Services or provision of any information therefore constitutes your consent to the transfer to and from, processing, usage, sharing, and storage of information about you in the Cayman Islands, EU and other jurisdictions as set out in this Privacy Policy.\nYour personal data may be transferred to jurisdictions that do not offer equivalent protection of personal data as under the Data Protection Legislation. In such cases, we will process personal data or procure that it be processed in accordance with the requirements of the Data Protection Legislation, which may include having appropriate contractual undertakings in legal agreements with service providers who process personal data on our behalf.\n10. Your rights\nYou have certain data protection rights under the Data Protection Legislation, including the right to:\n\nbe informed about the purposes for which your personal data are processed;\naccess your personal data;\nstop direct marketing;\nrestrict the processing of your personal data;\nhave incomplete or inaccurate personal data corrected;\nask us to stop processing your personal data;\nbe informed of a personal data breach (unless the breach is unlikely to be prejudicial to you);\ncomplain, including to the Data Protection Ombudsman of the Cayman Islands; and\nrequire us to delete your personal data in some limited circumstances.\n\n11. Children\nThe Services are intended for general audiences and are not directed at children. To use the Services, you must legally be able to enter into the Agreement. We do not knowingly collect personal information (as defined by the U.S. Children's Privacy Protection Act, or \"COPPA\") from children. If you are a parent or guardian and believe we have collected personal information in violation of COPPA, please contact us at wecare@aave.com and we will remove the personal information in accordance with COPPA.\n12. Additional Disclosures for California Residents\nThese additional disclosures apply only to California residents. The California Consumer Privacy Act of 2018 (\"CCPA\") provides additional rights to know, delete, and opt-out, and requires businesses collecting or disclosing personal information to provide notices and the means to exercise consumer rights.\nA. Notice of Collection\nFor further details on the information we may collect, including the sources from which we receive information, review the \"Information Collection\" section above. We may collect and use these categories of personal information for the business purposes described in the \"Use of Information\" section above, including to manage the Services.\nWe do not \"sell\" personal information as defined under the CCPA. Please review the \"Sharing and Disclosure of Information\" section above for further details about the categories of parties with whom we share information.\nB. Right to Know and Delete\nYou have the right to know certain details about our data practices within the past twelve (12) months. In particular, you may request the following from us:\n\nThe categories of personal information we have collected about you;\nThe categories of sources from which the personal information was collected;\nThe categories of personal information about you we disclosed for a business purpose;\nThe categories of third parties to whom the personal information was disclosed for a business purpose;\nThe business or commercial purpose for collecting or selling the personal information; and\nThe specific pieces of personal information we have collected about you.\n\nIn addition, you have the right to delete the personal information we have collected from you.\nTo exercise any of these rights, please submit a request by emailing us at wecare@aave.com. In the request, please specify which right you are seeking to exercise and the scope of the request. We will confirm receipt of your request within ten (10) days. We may require specific information from you to help us verify your identity and process your request. If we are unable to verify your identity, we may deny your requests to know or delete.\nC. Authorized Agent\nYou may designate an authorized agent to submit requests on your behalf; however, we may require written proof of the agent's permission to act on your behalf and verify your identity directly.\nD. Right of Non-Discrimination\nYou have a right of non-discrimination for the exercise of any of your privacy rights guaranteed by law, such as the right to access, delete, or opt-out of the sale of your personal information.\nE. Shine the Light\nCustomers who are residents of California may request (i) a list of the categories of personal information disclosed by us to third parties during the immediately preceding calendar year for those third parties' own direct marketing purposes; and (ii) a list of the categories of third parties to whom we disclosed such information. To exercise a request, please write to us at the email or postal address set out in the \"Contact Us\" section above and specify that you are making a \"California Shine the Light Request.\" We may require additional information from you to allow us to verify your identity and are only required to respond to requests once per calendar year.\n13. Additional Disclosures for Data Subjects in the European Economic Area and the United Kingdom\nA. Roles\nThe General Data Protection Regulations in the European Economic Area and General Data Protection Regulations in the United Kingdom (\"GDPR\") distinguish between organizations that process personal data for their own purposes (known as \"controllers\") and organizations that process personal data on behalf of other organizations (known as \"processors\"). We act as a controller with respect to personal data collected as you interact with the Services.\nB. Lawful Basis for Processing\nThe GDPR requires a \"lawful basis\" for processing personal data. Our lawful bases include where:\n\nConsent: You have given consent to the processing of your personal data for one or more specific purposes, either to us or to our service providers or partners.\nContractual Necessity: Processing your personal data is necessary for the performance of a contract between you and us.\nLegal Obligation: Processing your personal data is necessary for compliance with a legal obligation.\nLegitimate Interests: Processing your personal data is necessary for the purposes of the legitimate interests pursued by us or a third party, provided that your interests and fundamental rights and freedoms do not override those interests.\n\nWhere applicable, we will transfer your personal data to third parties subject to appropriate or suitable safeguards, such as standard contractual clauses.\nPurposeLegal BasisOperating and managing the ServicesNecessary for the performance of our agreementTo communicate with youNecessary for the performance of our agreementImproving the ServicesLegitimate interests, ConsentTo provide our ServicesLegitimate interests, ConsentMerger or AcquisitionLegitimate interests, legal obligation (when communicating with EEA, U.K., and Swiss regulatory bodies)Security and compliance with lawsLegal obligation, legitimate interests, necessary for the performance of our agreementOther purposes for which we have obtained consentConsent\nC. Your Data Subject Rights\nIf you are a user in the European Economic Area or the United Kingdom, you maintain certain rights under the GDPR. These rights include the right to:\n\nRequest access and obtain a copy of your personal data;\nRequest rectification or erasure of your personal data;\nObject to or restrict the processing of your personal data;\nRequest portability of your personal data.\n\nAdditionally, if we have collected and processed your personal data with your consent, you have the right to withdraw your consent at any time.\nNotwithstanding the foregoing, we cannot edit or delete information that is stored on a particular blockchain. This information may include transaction data (i.e., purchases, sales, and transfers) related to your blockchain wallet address and any items held by your wallet address.\nTo exercise any of these rights, please contact us via our email or postal address listed in the \"Contact Us\" section above and specify which right you are seeking to exercise. We will respond to your request within thirty (30) days. We may require specific information from you to help us confirm your identity and process your request. Please note that we retain information as necessary to fulfill the purpose for which it was collected and may continue to retain and use information even after a data subject request in accordance with our legitimate interests, including as necessary to comply with our legal obligations, resolve disputes, prevent fraud, and enforce our agreements.\nIf you have any issues with our compliance, please contact us as set out in the \"Contact Us\" section above. You also reserve the right to lodge a complaint with the data protection regulator in your jurisdiction.\n14. Candidates and Applicants\nIf you apply for a role with Aave Labs, we may collect and process personal information relating to your application, including information you provide directly (such as your CV, cover letter, application responses, portfolio, interview materials, interview recordings or transcripts where applicable and with appropriate notice), information obtained during the recruitment process, and information available from professional networking platforms such as LinkedIn or other publicly available sources where relevant to your candidacy.\nWe use this information to assess your qualifications, skills, experience, and suitability for employment or engagement, communicate with you throughout the recruitment process, conduct interviews and assessments, verify your qualifications and right to work where applicable, administer and improve our recruitment processes, and comply with applicable legal and regulatory obligations.\nWe process your personal information where necessary to take steps at your request prior to entering into a contract with you, where necessary for our legitimate interests in recruiting and evaluating candidates, administering and improving our recruitment process, protecting our business, and establishing, exercising, or defending legal claims, and where necessary to comply with applicable legal obligations. Where required by law, or where appropriate, we will rely on your consent, which you may withdraw at any time.\nYour information may be shared with members of our People team, hiring managers, interviewers, and trusted service providers that provide recruitment platforms, applicant tracking systems, interview scheduling, communications, identity verification, and background screening services, where applicable, that support our recruitment activities. Where appropriate, we may also obtain references or conduct background checks in accordance with applicable laws.\nAave Labs operates globally. As a result, your information may be accessed or processed by team members, affiliates, or service providers located outside your country of residence. Where we transfer personal information across borders, we put in place appropriate safeguards using recognised transfer mechanisms where required, in line with applicable data protection laws such as the EU and UK GDPR.\nWe maintain appropriate technical and organisational measures designed to protect candidate information against unauthorised or unlawful access, use, alteration, disclosure, loss, or destruction. Access to your information is limited to personnel and service providers who need it for the purposes described above and is subject to confidentiality obligations.\nIf your application is unsuccessful, we will generally retain your information for up to 12 months following the conclusion of the recruitment process to comply with legal obligations, improve our recruitment processes, and, where permitted by applicable law or with your consent where required, consider you for future opportunities. After this period, your information will be deleted or anonymised. If your application is successful, relevant information will be transferred to and retained as part of your employment or engagement record. We may retain your information for longer than the periods described above where required to comply with a legal, regulatory, tax, or accounting obligation, or where necessary to establish, exercise, or defend legal claims. In such cases, we retain the information only for as long as that requirement or purpose applies, after which it is deleted or anonymised. You may request deletion of your information at any time, subject to our legal and legitimate business obligations.\nYou may exercise applicable privacy rights, including the right to access, rectify, erase, restrict or object to our processing of your personal information, request portability of certain personal information where applicable, withdraw consent where processing is based on consent, and request deletion of your personal information, by contacting us at the details provided in this Privacy Policy. Where requested information is necessary to assess your application or comply with applicable legal obligations, failure to provide such information may affect our ability to consider your application.\n15. Use of Artificial Intelligence in Recruitment\nAs part of our recruitment process, we may use artificial intelligence (“AI”) and automated tools to support activities such as candidate sourcing, application review, interview scheduling, transcription, note-taking, summarisation, and other administrative or evaluation-related processes.\nThese tools are used to assist our teams in managing recruitment efficiently and consistently. We do not make hiring decisions based solely on automated processing. All hiring decisions involve human review and judgment. Where AI-enabled tools assist in evaluating applications, their outputs are reviewed by appropriately authorised personnel and are not used as the sole basis for hiring decisions.\nWe may also use automated tools to help organise, prioritise, or identify potentially relevant applications. These tools support, but do not replace, human assessment and are not used to make decisions producing legal or similarly significant effects without meaningful human involvement.\nWhere AI-enabled tools process personal information on our behalf, they do so subject to appropriate contractual, security, and confidentiality obligations.\n16. Changes to this Privacy Policy\nWe reserve the right to revise and reissue this Privacy Policy at any time. Any changes will be effective immediately upon our posting of the revised Privacy Policy. For the avoidance of doubt, your continued use of the Services indicates your consent to the revised Privacy Policy then posted.\n17. Contact Us\nIf you have any questions or comments about this Privacy Policy, our data practices, or our compliance with applicable law, please contact us by email: wecare@aave.com.","tokens":7102,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259119467,"hash":"677e8e619f16cafefe1da35a447b08076d772377"}
{"url":"https://ethresear.ch/t/towards-native-post-quantum-private-eth/25291/1","domain":"ethresear.ch","title":"Towards Native Post-Quantum Private ETH - Privacy - Ethereum Research","text":"Towards Native Post-Quantum Private ETH \n\n Privacy\n\n transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n Jun 24\n\n 1 / 8\n\n Jun 23\n\n Jun 29\n\n post by Pierre on Jun 24\n\n Pierre\n\n Thanks to @winderica, @mmjahanara, Kenny Paterson, Varun Maram and @keewoolee for their valuable suggestions and feedbacks.\nBeyond HNDL\nThe L1 strawmap laid out a path listing L1-native private post-quantum (pq) transfers as a north star. Today, production-deployed privacy solutions rely on elliptic curve-based primitives or on unsatisfactory hardware assumptions. Some argue that, as of now, protecting against harvest-now-decrypt-later (HNDL) attacks is enough for private transfer protocols. However, the deployment of a cryptographically relevant quantum computer means adversaries would be able to carry out undetectable attacks resulting in a catastrophic loss of funds. In that situation, any recovery mechanism (such as turnstiles) will likely require important social layer coordination, provided users’ trust in the protocol isn’t permanently damaged.\nThis post tries to succinctly lay out the kind of cryptographic work we would have to do to enshrine pq privacy in the L1. It is not straightforward: a look at Sapling’s (~620k shielded ZEC, approx $250m in value at today’s price) choices regarding its primitives’ instantiation illustrates why protecting users from HNDL attacks or simply switching proof systems falls short of accurately describing what work is required to deliver pq shielded ETH.\nPreparing for a pq turnstile while using classical cryptographic primitives would not be enough. A turnstile is an inherently reactive, non-retroactive and non-preventive technique that doesn’t fend off an attacker’s ability to destroy the coin’s value. Turnstiles also take time and won’t ever really be completed: it will only be many years later that users can be probabilistically confident that counterfeiting didn’t take place. On top of this, turnstiles greatly impact users by deactivating their ability to transact. They are, all in all, an inherently social-layer defense mechanism, impeding a genuine walk-away from the protocol.\n\nUsage\nPrimitive\nSecurity Requirement\nInstantiation\n\nEncrypting Note Plaintexts\nAsymmetric Encryption\nIND-CCA2 and IK-CCA2\n DHAES\n\nSpend Authorization\nRe-Randomizable Signature\nSURK-CMA\n RedDSA on Jubjub\n\nNon-Inflation (and Non-Malleability)\nSignature with Signing Key to Validating Key Monomorphism\nNon-Adaptive SU-CMA, Key Monomorphic\n RedDSA on Jubjub\n\nCommitting to Notes\nCommitment Scheme\nBinding and Hiding\n Windowed Pedersen Commitments (hiding is ok)\n\nCommitting to Values\nLinearly Homomorphic Commitment Scheme\nBinding and Hiding\n Homomorphic Pedersen Commitments (hiding is ok)\n\nDiversified Addresses\nDiversify Hash\nUnlinkability\n Group Hash Jubjub Curve\n\nProofs\nSNARK\nStatistical Zero-Knowledge (zk), Completeness, Knowledge Soundness\n Groth16 on BLS12-381 (zk is ok)\n\nA non-exhaustive table of ZCash’s Sapling pq readiness. It applies to Orchard, which changed Sapling’s proof system (Halo2, Pasta Curves), key material derivation and nullifiers computation formulas, but is soon to be deprecated.\nIn this post, we will only consider the case of dealing with a quantum adversary. We will evaluate solutions to statelessness compatibility and the verification cost problem in a separate writeup.\nProof Systems\nHash-based proof systems are getting to a point where they are both fast and well-understood. Not leveraging lattice-based ones means that our shielded pool protocol will probably not provide users with the ability to prove their final balance output using snark-friendly lattice-based homomorphism, including the ability to do proof parallelization.\nThis is however fine. Proof parallelization was indeed conceived as a way to overcome join-split statements’ inadequacy for note consolidation or sending to multiple recipients. Today, progress in hash-based SNARKs (WHIR, STIR) offer the ability to prove bigger circuits and depart from a traditional two inputs/outputs setup rendering such proof parallelization strategies less relevant. Thus, a battle-tested join-split zkSNARK statement enforcing checks on notes’ Merkle paths and commitments, input/output values, nullifiers derivation and spend auth signature validity should get us to the core required functionalities, with an on-par UX compared to existing protocols.\nThe instantiation of this statement depends critically on the choice of hash function for nullifiers and note commitments. There are different SNARK-friendly hash candidates to use. Recent research on Poseidon indicates that we should be cautious and would need some more cryptanalysis research to integrate it (see here and here). Other options include using less arithmetization-friendly hashes, such as BLAKE3.\nSecret Distribution\nEncryption\nTransaction detection corresponds to receivers being able to detect public ciphertexts addressed to them. We should make sure that it is DoS-resistant, provides unlinkability, minimizes trust points and remains practical on resource-constrained devices. The main task will be to swap a key agreement (KA) for a key encapsulation mechanism (KEM) (the two differ with how randomness is contributed in the shared key material generation algorithm). Today, the NIST PQC process only standardized KEMs, leaving pq KA aside.\nKyber is our leading KEM candidate. However, until relatively recently, cryptography had to establish its anonymity (aka ANO-CCA, an adversary cannot determine to which recipient an encapsulated key is destined) and that of the PKE scheme derived from it in a pq setting. Kyber initially had a more complex Fujisaki-Okamoto (FO) transform using nested hashing. However, NIST eventually decided to simplify it, easing researcher’s ability to establish its ANO-CCA security. Research eventually showed that one can obtain an ANO-CCA security proof even for nested hashing. All in all, the current NIST standard ML-KEM does provide an anonymous and robust PKE, by composing with an appropriate DEM in the KEM-DEM paradigm.\nOrthogonal but going hand in hand with anonymity, the scheme used for secret distribution also needs to satisfy robustness, making it possible for a party to decide it is the ciphertext’s intended recipient, i.e. providing assurance that trial decryption doesn’t err. This isn’t a natural property. For instance, it was shown that for any plaintext m𝑚, it is possible to build a ciphertext c𝑐 such that c𝑐 decrypts to m𝑚 under any Classic McEliece private key. However, the situation is less dire here, since ML-KEM has been found to be robust.\nNote that this only settles the encryption side of HNDL attacks: a complete defense would require note commitments and nullifiers to be instantiated with quantum secure primitives.\nHybrid Schemes\nHybrid cryptographic schemes combining classical and post-quantum algorithms will most likely be required initially to take a conservative security stance to build the asymmetric encryption scheme used to distribute secrets (likely an “hybrid” public key encryption scheme, here in the sense of combining an asymmetric key exchange protocol and a symmetric encryption scheme). We will have flexibility along a few axes: pure pq vs. hybrid (e.g. combining ML-KEM with a traditional ECDH group), CFRG-defined vs. NIST-defined elliptic curves, different security levels (NIST category 3 vs. category 5). The symmetric encryption part should stay similar to what it is today, although we should evaluate whether we would like to use longer key lengths.\nDecryption\nThere remains, however, the question of privacy-preserving protocols’ decryption trilemma: anonymity, low latency and small bandwidth usage. Switching to pq schemes makes this trilemma even more relevant.\nA north star would remain deploying oblivious message retrieval (OMR) at scale. Such constructions are quantum secure, but clue (i.e. the required on-chain costs) and detection key sizes are already too high to make up a credible L1 candidate. Also, server costs remain the dominant bottleneck even for SOTA constructions, making it unclear how to leverage such techniques in the near term. There is the option to split detection from retrieval using Oblivious Message Detection (OMD, a restricted version of OMR for obliviously retrieving indices) coupled with PIR to fetch payloads. Splitting those two tasks would relieve servers from running OMR’s intensive compute requirement. Still, combining the two wouldn’t reduce the clue size today.\nOne potential avenue would be to leverage fuzzy message detection (FMD) algorithms. They provide a non-negligible improvement over naive scanning, with much lower compute requirements while keeping a small clue size. However, pq versions of FMD require clues with sizes an order of magnitude larger. Also, this overhead comes at the price of only modest probabilistic privacy guarantees, as FMD is also prone to a variety of statistical attacks. Other recent approaches, such as tag-indexing in Aztec or channels in the Starknet privacy layer, sequentially index transactions between two parties using a shared secret, keeping all subsequent exchanges unlinkable. The limitation is that the initialization step requires revealing that Alice intends to interact with Bob.\nNote that there is always the option to fall back on out-of-band channels for sending ciphertexts, which makes it possible to remove them from the transaction entirely.\nSo, in a pq context, there might not be anything better than using trial decryption today. Even in a classical context, most privacy-preserving protocols today use a flavour of trial decryption coupled with authentication tags. To decrease bandwidth costs, ZCash light clients download compactly formatted transactions to synchronize their state using trial-decryption. To provide anonymity, upon detecting intended transactions users are then recommended to insert decoy requests alongside the correct, queried ones. In the case of Ethereum, when coupled with PIR and network anonymity, this path might be the best pq solution for the trilemma today.\nSignatures\nIn the case of a malleable zkSNARK, we might need to require an ephemeral keypair to sign the hash of the transaction, binding it to the zkSNARK statement. The nice thing is that non-adaptive strong-unforgeability under chosen message attack (SU-CMA) security is ok, since the signature is one-time. Also, the binding signature doesn’t require in-circuit verification, such that we can probably use a lattice-based scheme with a much smaller signature size compared to hash-based ones (or even a one-time hash-based signature if we really don’t want to use lattices).\nFor the spending authority scheme, the choice of the signature scheme is constrained by the hardware wallets that must produce these signatures in practice. Some actually proposed to opt for proof knowledge of a pre-image of some hash, sparing us from arithmetizing signatures and deciding which scheme to go with. It is, however, unclear whether tomorrow’s wallet infrastructure will support and standardize proving a recursive pq zkSNARK and whether the particular scheme will be compatible with what’s enshrined on the L1. This would also mean getting rid of all the wallet hardening work that has been done over the years, including the different attack vectors that generating signatures on hardware wallets implies.\nOn statefulness, note that most hardware wallets come with non-volatile memory and are able to support both stateful and stateless signatures. Stateful designs provide shorter signatures and potential optimizations. However, statefulness introduces a handful of problems when the signer isn’t signing at regular, predictable intervals. Users need to back up their keys, but using backups leads to state reuse and enables forgeries.\nThere are a number of stateless, hash-based signature schemes that could be amenable to being snarkified, including research being done for Bitcoin in this regard. One option would be to use SPHINCS+ with a parameter set that offers a small signature verification budget. One particularly interesting parameter set would be to reuse the one that’s being laid out for firmware signing, something that inspired the design of SPHINCS-.\nThere could also be a trick to use many times the key pair of a one-time signature (OTS) scheme. Consider a perfectly hiding zkSNARK. Since the OTS is kept hidden inside the zkSNARK as part of the witness, forging a spend proof reduces to producing a valid OTS on a fresh transaction hash without knowledge of the secret key, which remains hard as long as no OTS is ever exposed outside the circuit. It however implies a different threat model requiring the spend auth signature to never be exposed to protect both privacy and loss of funds.\nKey Material\nIt is possible to design key material using Pseudo Random Functions (PRFs) only. Chosen adequately, such PRFs are quantum secure. This was, for instance, the strategy of Sprout, an early version of the ZCash protocol. Lattice-based primitives might be helpful for re-designing diversified address functionality, although it remains unclear how such a design would work in practice and how compatible it would be with a hash-based proof system.\nHardening\nSince ETH secures billions in value, we avoided discussing exotic primitives enabling things like private shared state. Our rationale for not considering more involved cryptography and functionalities is threefold: we would like to (1) design our protocol with a walkaway in mind, (2) facilitate any downstream formal verification effort and (3) re-use already understood and production deployed primitives securing billions in value today.\nAnother additional guard to consider would also consist in designing a progressive pool uncapping. Defined at the protocol level, that progressive uncapping would consist in gradually increasing deposit amounts to minimize catastrophic size losses in the early days of the enshrined pool’s life.\n\n 4\n\n 3\n\n read \n\n 6\n min\n\n post by 71104 on Jun 24\n\n 71104\n\nWhat if post-quantum Ethereum doesn’t need signatures at all?\n\n post by Pierre on Jun 25\n\n Pierre\n\n Compared to a “regular” transaction, the spend auth scheme isn’t the only thing you need in the context of a private transfer protocol (e.g. showing your spent notes actually exist and that their derived nullifiers are correct).\nIf you go down the path of using a zkSTARK for authorizing the spend, you end up pretty much with two choices: either recursively verifying this spend auth proof in another proof on the user’s device or generating the whole private transfer statement proof on the hardware wallet itself.\nTo me, both paths aren’t really viable, both in terms of current and future hardware wallet performance and standardization.\n\n post by 71104 on Jun 25\n\n 71104\n\nRecursive aggregation is not a problem: WHIR makes for very small proofs, the WHIR circuit is relatively simple.\nRecursion is not the only way to aggregate zkSTARKs, you can also batch them at the PCS level.\nI don’t see why you’d have to verify zkSTARKs on a user device but that’s fine, WHIR verification takes microseconds. In fact, WHIR proofs are typically much smaller (<1KiB) than Falcon or Dilithium or whatever PQ signature scheme.\nThe non-standard aspect is a real problem but account abstraction will make it optional and devices will adapt over time. MetaMask supports plugins called snaps, implementing a stop-gap solution is relatively easy.\n\n post by Pierre on Jun 25\n\n Pierre\n\n I’m not pointing out recursion to be a problem. Rather, that designing a zkSTARK to be generated on a hardware wallet for the spend auth scheme isn’t really a good use of time.\nHardware wallets already have a bunch of work related to porting pq signatures. Generating such proofs introduces new performance problems and attack vectors that vendors might not be keen on investigating today. Assuming that devices will adapt over time is opening the door to many issues.\nWorking on circumventing pq signatures limitations has a much better case. Pretty good and standardized solutions exist already, such as using a stateless scheme with a parameter set used for firmware signing or just leveraging an OTS.\n\n post by 71104 on Jun 25\n\n 71104\n\n You’re basically arguing for legacy drag to block all innovation. That works until someone who knows better goes all-in on innovation and beats you with smaller proofs and higher scalability.\n\n post by rdubois-crypto on Jun 26\n\n rdubois-crypto\n\n I gently disagree about the fact that the HW has to compute the proof: spending and proving might be separated. There is no real sense to require proving in the HW, cause if the host is compromised, privacy will be compromised by a thousand other ways. A corrupted prover cannot spend your funds in Zcash/RG systems.\nI fully agree that the real problem is the succinctness that will require aggragation/L2 like system. And it is unlikely (I don’t know any searchers thinking we might) that a way to achieve it with hash based or Lattices is ever found.\n\n post by Pierre on Jun 29\n\n Pierre\n\nYes I agree, it does require thinking about recursion or aggregation. I’m not too pessimistic though! On the hash based side of things, the work done by the LeanVM team is a cool direction which could be nice to piggy back on. We also investigated WARP and worked on an implementation here. I’m less familiar with what’s being done using lattice-based primitives.\n\n Powered by Discourse","tokens":4393,"squid":"ink-research","role":"Deep Scholar","at":1791259124773,"hash":"0ec5aefa1da71df3c422e000471a71c9302928f9"}
{"url":"https://docs.openzeppelin.com/impact/contracts-future","domain":"docs.openzeppelin.com","title":"The Future of OpenZeppelin Contracts | OpenZeppelin Docs","text":"ContractsThe Future of OpenZeppelin ContractsOpen in ClaudeThe next decade of on-chain innovation will bring regulated finance, privacy-preserving systems, and programmable capital to the same foundation. Building on a decade of impact, OpenZeppelin is extending its standards, contracts libraries, and tooling to support this evolution.\nFocus Areas\nChain AbstractionCross-chain intents, cross-chain messaging, smart accounts, and zkEmailPrivacyConfidential tokens, private shared state, and private email verifictionTokenization & Real World AssetsPermissioned tokens, confidential tokens, and on-chain yieldPowering Top Financial InstitutionsPrevious PageChain AbstractionNext PageOn this pageFocus Areas","tokens":177,"squid":"ink-security_audits","role":"Sentinel","at":1791259124823,"hash":"ee469681c72f5666c40783dd2a5f290200b0a4eb"}
{"url":"https://aave.com/docs/aave-v3/getting-started/typescript","domain":"aave.com","title":"AaveKit TypeScript v3 | Aave Protocol Documentation","text":"TypeScript#\nAaveKit TypeScript provides a type-safe, low-level API client for interacting with Aave Protocol v3. It offers a lightweight abstraction over the GraphQL API and is ideal for server-to-server communication.\nBuilt with a modular, functional approach inspired by the viem client-actions architecture, the SDK structures functionality into distinct, reusable actions focused on specific protocol features like lending, borrowing, and vault management.\nGetting Started#\nTo get started, follow the steps below.\n1Install SDK#First, install the @aave/client package using your package manager of choice.npm install @aave/client@latest2Create an AaveClient#Then, create an AaveClient instance that will be used to interact with the protocol.import { AaveClient } from \"@aave/client\";\nexport const client = AaveClient.create();3Start Building#That's it—you can now start using the @aave/client/actions to interact with the Aave Protocol.import { AaveClient, evmAddress, chainId } from \"@aave/client\";import { chains } from \"@aave/client/actions\";\nimport { client } from \"./client.ts\";\n// Fetch all chains supported by Aaveconst result = await chains(client);\nif (result.isOk()) { console.log(\"Chains:\", result.value);} else { console.error(\"Error:\", result.error);}\nAction Return Types#\nAaveKit actions use a functional approach to error handling. They return a ResultAsync<T, E>—a thenable object that represents one of two states:\nOk<T>: A successful result containing a value of type TErr<E>: A failure containing an error of type E\nWhen you await a ResultAsync<T, E>, it resolves to a Result<T, E>.\nWith a Result<T, E>, you can use the convenient isOk() and isErr() methods to check the outcome and narrow the type.\nIf you have a ResultAsync<T, E>, you must first await it to access those methods.\nconst result = await actionName(/* args */);\nif (result.isOk()) { console.log(\"Result:\", result.value);} else { console.error(\"Error:\", result.error);}\nThis approach avoids reliance on try/catch blocks and promotes predictable, type-safe code by ensuring errors are handled explicitly.\nSee the NeverThrow documentation\nfor more information. The NeverThrow library is re-exported for convenience.\nLet’s explore the concept with a simple example function:\nfunction parseNumber(input: string): Result<number, string> { return isNaN(Number(input)) ? err(\"Invalid number\") : ok(Number(input));}\nconst result = parseNumber(\"42\");\nYou can chain multiple operations:\nfunction divide(a: number, b: number): Result<number, string> { return b === 0 ? err(\"Division by zero\") : ok(a / b);}\nconst result = parseNumber(\"42\").andThen((num) => divide(num, 2));\nif (result.isOk()) { console.log(\"Result:\", result.value);} else { console.error(\"Error:\", result.error);}\nYou can also provide a default value:\nconst value = parseNumber(\"invalid\").unwrapOr(0); // 0\nNeverThrow also provides a ResultAsync type for handling asynchronous operations. This is a thenable object that can be awaited, and/or chained with other operations:\nconst result = await ResultAsync.fromPromise( fetch(\"https://api.example.com/data\")) .map((response) => response.json()) .mapErr((error) => `Failed to fetch data: ${error}`);\nif (result.isOk()) { console.log(\"Data:\", result.value);} else { console.error(\"Error:\", result.error);}\nIntegrations#\nAaveKit TypeScript includes first-class support for viem, ethers v6, Privy, thirdweb and Turnkey wallets.\nViemEthersPrivythirdwebTurnkeyEnsure you have viem package installed in your project.npm install viem@2\nSend Aave Transactions#\nAmong the actions provided by AaveKit TypeScript, some are specifically designed to handle protocol interactions such as supplying, borrowing, withdrawing, repaying, and more.\nThere are two main types of transaction actions:\nSimple transactions – single-step transactions that can be sent directly to the wallet.Complex transactions – transactions that may require prior approvals before they can be executed.\nTo send transactions, follow the steps below.\n1Import the Helper#First, import the sendWith helper function for the wallet library of your choice.ViemEthersPrivythirdwebTurnkeyImport the sendWith helper from the @aave/client/viem entry point.import { sendWith } from \"@aave/client/viem\";2Send the Transaction#Then, use the sendWith helper to send the transaction.To demonstrate how this helper works, assume we have a transaction action named foobar.import { foobar } from \"@aave/client/actions\";import { client } from \"./client\";\nconst result = foobar(client);To send the transaction, chain the action with sendWith for your wallet library, then use client.waitForTransaction to wait until it's confirmed and indexed by AaveKit API.import { foobar } from \"@aave/client/actions\";import { sendWith } from \"@aave/client/viem\";import { createWalletClient, http } from \"viem\";import { privateKeyToAccount } from \"viem/accounts\";\nimport { client } from \"./client\";\nconst wallet = createWalletClient({ account: privateKeyToAccount(\"<PRIVATE_KEY>\"), transport: http(),});\nconst result = foobar(client) .andThen(sendWith(wallet)) .andThen(client.waitForTransaction);3Handle the Result#Finally, handle the result of the operation.if (result.isErr()) { switch (result.error.name) { case \"SigningError\": console.error(`Failed to sign the transaction: ${error.message}`); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${error.message}`); break;\n case \"UnexpectedError\": console.error(error.message); break; }} else { console.log(\"Transaction sent with hash:\", result.value);}That'it—you've sent the transaction.\nSign ERC-20 Permits#\nSome operations support permit functionality using EIP-2612 signatures to authorize ERC-20 token transfers within the same transaction.\nTo use permits, you'll need both the permitTypeData action to generate the permit data and a signERC20PermitWith helper specific to your wallet library.\nViemEthersPrivythirdwebTurnkeyImport the signERC20PermitWith helper from the @aave/client/viem entry point.import { signERC20PermitWith } from \"@aave/client/viem\";\nUse permitTypeData to generate the permit data, then chain it with your wallet-specific signERC20PermitWith helper:\nimport { permitTypeData } from \"@aave/client/actions\";import { signERC20PermitWith } from \"@aave/client/viem\";import { createWalletClient, http } from \"viem\";import { privateKeyToAccount } from \"viem/accounts\";\nimport { client } from \"./client\";\nconst wallet = createWalletClient({ account: privateKeyToAccount(\"<PRIVATE_KEY>\"), transport: http(),});\nconst result = await permitTypeData(client, { // permit parameters}).andThen(signERC20PermitWith(wallet));\nFor complete permit parameter examples, refer to the specific operation documentation.\nNext Steps#\nAave Markets - Learn how to interact with Aave markets.Aave Earn - Learn how to interact with Aave Earn Vaults.","tokens":1731,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259130690,"hash":"2494d8dfb7ede5f6cd8eafa1ceaecec20139ecfa"}
{"url":"https://docs.openzeppelin.com/impact/chain-abstraction","domain":"docs.openzeppelin.com","title":"Chain Abstraction at OpenZeppelin | OpenZeppelin Docs","text":"Innovation & ResearchChain Abstraction at OpenZeppelinOpen in ClaudeOur work focuses on building the secure primitives for cross-chain messaging, intent-based execution, and unified account experiences, creating a world where users and assets move freely across ecosystems with complexity abstracted away from users.\nEcosystem Contributions\nWe have partnered with ecosystems and projects to deliver contracts libraries and tooling for cross-chain coordination and smart accounts.\nEthereum & EVMContracts libraries for modular smart accounts in SolidityAxelarContracts libraries for cross-chain messaging in SolidityOpen Intents FrameworkContracts libraries in Solidity and solvers for cross-chain intentsStarknetContracts libraries for smart accounts in CairoStellarContracts libraries for smart accounts in SorobanzkEmailCryptography contracts libraries in Solidity for transactions and social recovery using email\nCross-Chain Intents\nUniversal format for expressing and fulfilling user actions across chains.\nUse Cases\n\nSimplified Onboarding to Chains and Apps: Onboard users by automating gas, approvals, and cross chain setup, allowing users to interact with any app or network instantly without prior configuration.\n\nAbstracted Gas and Settlement: Allows operation across multiple chains without managing native gas tokens or complex bridge flows.\n\nToken Bridging and Swapping: Enable seamless asset transfers and swaps across chains, abstracting away bridge risks and fragmented liquidity.\n\nUniversal Balances: Users can maintain a single cross chain balance, allowing applications to fetch, display, and transact from unified liquidity sources.\n\nStandards\n\nERC-7683: Cross Chain Intents (draft): A standard that enables cross chain value transfer using a standard api. OpenZeppelin is a contributor to and leading the redesign of the ERC through the Open Intents Framework and is building contracts libraries in the Open Intents Framework Contracts Repo.\n\nERC-7888: Cross Chain Broadcaster (draft): A standard that enables cross chain messaging using storage proofs. OpenZeppelin is a contributor to the ERC through the Open Intents Framework and is building contracts libraries in the Open Intents Framework Broadcaster Repo.\n\nAssociations\n\nOpen Intents Framework: The group is building a modular, open source framework for building and deploying intent product experiences by providing ready-to-use, protocol-agnostic features for solvers, interop providers, and cross-chain builders. OpenZeppelin is a member with many major organizations.\n\nCross-Chain Messaging\nCommon interface for sending and receiving messages across chains.\nUse Cases\n\nState Synchronization for Multi-Chain Apps: Use single controller contract or governance action to coordinate updates on multiple chains.\n\nToken Bridges: Enables verifiable message passing between bridge contracts, ensuring consistent state and transfer logic across multiple chains without relying on trusted intermediaries.\n\nIntent Settlement: Facilitates secure delivery and confirmation of intent execution results across chains, allowing applications to finalize actions and synchronize states.\n\nStandards\n\nERC-7786: Cross Chain Messaging Gateway (last call): A standard that enables cross-chain messaging via a universal gateway interface. OpenZeppelin team members co-authored the standard with Axelar and is building contracts libraries in the OpenZeppelin Solidity Community Contracts Repo.\n\nSmart Accounts\nComposable architecture that enables customizable modules to support secure and extensible account functionality.\nUse Cases\n\nGasless Transactions: Allow users to interact with apps without holding native tokens, enabling seamless onboarding.\n\nSocial Recovery: Allow trusted guardians to securely restore access to accounts without centralized intermediaries.\n\nKeyless Signatures: Authenticate and approve transactions using biometrics, hardware modules, or passkeys instead of a traditional private key.\n\nStandards\n\nERC-4337: Account Abstraction Using Alt Mempool (final): A standard that enables account abstraction using an alternative mempool. OpenZeppelin has built contracts libraries for modular smart accounts in the OpenZeppelin Solidity Contracts Repo and Wizard integration.\n\nERC-7579: Minimal Modular Smart Accounts (draft): A standard that enables interoperability between accounts and modules. OpenZeppelin has built contracts libraries for modules in the OpenZeppelin Solidity Community Contracts Repo and Wizard integration.\n\nEIP-7702: Set Code for EOAs (complete): A protocol standard that enables EOA’s to adopt smart contract capabilities using a new transaction type to set code in their account. OpenZeppelin has built contracts libraries for modules in the OpenZeppelin Solidity Contracts Repo and Wizard integration.\n\nERC-7739: Readable Typed Signatures for Smart Accounts (draft): A standard for a defensive rehashing scheme which prevents signature replays across smart accounts and preserves the readability of the signed contents. OpenZeppelin team members co-authored the standard and is building contracts libraries in the OpenZeppelin Solidity Contracts Repo.\n\nERC-7821: Minimal Batch Executor Interface (draft): A standard for a minimal batch executor interface for delegations. OpenZeppelin team members co-authored the standard and is building contracts libraries in the OpenZeppelin Solidity Contracts Repo.\n\nERC-7913: Signature Verifiers (draft): A standard that enables signature verification for address-less keys (e.g. email, non-ethereum cryptographic curves). OpenZeppelin team members authored the standard and is building contracts libraries in the OpenZeppelin Solidity Contracts Repo.\n\nSNIP-6: Standard Account Interface (review): A standard for a standard interface for accounts. OpenZeppelin team members co-authored the standard and is building contracts libraries in the OpenZeppelin Staknet Cairo Contracts Repo.\n\nPrivate Email Verification\nOwnership of accounts using email.\nUse Cases\n\nSend Crypto Using Only Email Address: Users can authorize transactions (e.g. send money, DAO voting, any blockchain transaction) by proving control of their email address with no private key management required. Email never revealed!\n\nRecover Account Using Email Gaurdians: Lost keys can be restored by proving control of an email account, enabling user-friendly recovery.\n\nStandards\n\nERC-7969: DomainKeys Identified Mail (DKIM) Registry (draft): A standard that enables trustless email ownership verification using a DKIM restistry. OpenZeppelin team members co-authored with OKX and is building contracts libraries in the OpenZeppelin Solidity Community Contracts Repo.\nThe Future of OpenZeppelin ContractsPrevious PagePrivacyNext PageOn this pageEcosystem ContributionsCross-Chain IntentsUse CasesStandardsAssociationsCross-Chain MessagingUse CasesStandardsSmart AccountsUse CasesStandardsPrivate Email VerificationUse CasesStandards","tokens":1735,"squid":"ink-security_audits","role":"Sentinel","at":1791259134255,"hash":"d4a5a01bd77be97e8b102a0d94e3c291c82f08fa"}
{"url":"https://aave.com/docs/aave-v3/markets/incentives","domain":"aave.com","title":"Aave Incentive Programs | Aave Protocol Documentation","text":"Incentive Programs#\nAave reserves may offer additional incentives beyond base lending rates.\nIncentive Types#\nSupply Incentives: Extra APR for supplying assets to reservesBorrow Incentives: APR discounts for borrowing from reservesConditional Incentives: Bonus rewards requiring specific supply + borrow combinations\nEach reserve's incentives array contains all active incentive programs. The incentive data includes:\nAPR bonuses/discounts with formatted percentagesReward token information (for Aave governance incentives)Claim links (for Merit programs)Conditional requirements (for complex incentives)\nYou can find the incentives associated with a reserve in the incentives array of the Reserve object.\ninterface Reserve { // … incentives: ReserveIncentive[];}\nThese incentives come from two main sources:\nMerit ProgramsAave Governance Rewards\nMerit Programs#\nThird-party programs that provide extra APR rewards for specific lending activities. These require separate claiming through external platforms.\nMerit programs are third-party initiatives. Aave Labs does not guarantee these\nprograms and accepts no liability for third-party rewards.\ninterface MeritSupplyIncentive { __typename: \"MeritSupplyIncentive\"; extraSupplyApr: PercentValue; claimLink: string;}\nWhere:\nMeritSupplyIncentive: Extra APR for supplying assets to reservesMeritBorrowIncentive: APR discounts for borrowing from reservesMeritBorrowAndSupplyIncentiveCondition: Extra APR for supplying and borrowing the specified pair of assets\nFor each of these types, a claim link to the ACI Merit UI is provided.\nAave Governance Rewards#\nIncentives set by Aave governance through the RewardsController, typically distributed in AAVE tokens or other approved reward tokens.\ninterface AaveSupplyIncentive { __typename: \"AaveSupplyIncentive\"; extraSupplyApr: PercentValue; rewardTokenAddress: EvmAddress; rewardTokenSymbol: string;}\nWhere:\nAaveSupplyIncentive: Extra APR for supplying assets to reservesAaveBorrowIncentive: APR discounts for borrowing from reserves\nIn both cases, the reward token address and symbol are provided.\nClaim Merit Rewards#\nUsers can know if they have claimable Merit rewards and claim them, following the steps below.\n1Fetch the Claimable Rewards#First, determine if a user has claimable rewards.ReactTypeScriptGraphQLUse the useUserMeritRewards hook to fetch the user's claimable rewards and the transaction to claim them.const { data, loading, error } = useUserMeritRewards({ user: EvmAddress, chainId: ChainId,});Fetch the user's claimable rewards and the transaction to claim them.import { useUserMeritRewards, evmAddress, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useUserMeritRewards({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), chainId: chainId(1),});\nif (loading) { return <p>Loading claimable rewards...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\n// data: UserMeritRewards | nullIf data is null, the user has no claimable rewards.2Claim Rewards#Finally, if the user has claimable rewards, they can claim them by sending the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { useUserMeritRewards } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();const { data } = useUserMeritRewards({ // … suspense: true,});\nconst [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\nconst execute = async () => { if (data !== null) { const result = await sendTransaction(data.transaction);\n if (result.isErr()) { console.error(result.error.message); } else { console.log(\"Merit claim rewards successful with hash:\", result.value); } }};PreviousMarket OperationsNextAdvanced Features","tokens":968,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259141498,"hash":"7d78209bcee7fd8080eceef7280b429e2ee657bf"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins","domain":"docs.openzeppelin.com","title":"Upgrades Plugins | OpenZeppelin Docs","text":"Upgrades PluginsOpen in ClaudeIntegrate upgrades into your existing workflow. Plugins for Hardhat and Foundry to deploy and manage upgradeable contracts on Ethereum.\n\nDeploy upgradeable contracts.\nUpgrade deployed contracts.\nManage proxy admin rights.\nEasily use in tests.\n\nUpgrades Plugins are only a part of a comprehensive set of OpenZeppelin tools for deploying and securing upgradeable smart contracts. Check out the full list of resources.\nOverview\nInstallation and Usage\nSee the documentation for Hardhat Upgrades or Foundry Upgrades.\nHow the plugins work\nThe plugins provide functions which take care of managing upgradeable deployments of your contracts.\nFor example, deployProxy does the following:\n\nValidates that the implementation is upgrade safe.\nDeploys the implementation contract. Note that the Hardhat plugin first checks if there is an implementation contract deployed with the same bytecode, and skips this step if one is already deployed.\nCreates and initializes the proxy contract, along with a proxy admin (if needed).\n\nAnd when you call upgradeProxy:\n\nValidates that the new implementation is upgrade safe and is compatible with the previous one.\nDeploys the new implementation contract. Note that the Hardhat plugin first checks if there is an implementation contract deployed with the same bytecode, and skips this step if one is already deployed.\nUpgrades the proxy to use the new implementation contract.\n\nThe Hardhat plugin keeps track of all the implementation contracts you have deployed in an .openzeppelin folder in the project root, as well as the proxy admin. You will find one file per network there. It is advised that you commit to source control the files for all networks except the development ones (you may see them as .openzeppelin/unknown-*.json).\nThe Foundry plugin does not keep track of implementation contracts, but requires you to define reference contracts in order to validate new versions of implementations for upgrade safety.\nProxy patterns\nThe plugins support the UUPS, transparent, and beacon proxy patterns. UUPS and transparent proxies are upgraded individually, whereas any number of beacon proxies can be upgraded atomically at the same time by upgrading the beacon that they point to. For more details on the different proxy patterns available, see the documentation for Proxies.\nFor UUPS and transparent proxies, use deployProxy and upgradeProxy. For beacon proxies, use deployBeacon, deployBeaconProxy, and upgradeBeacon. See the documentation for Hardhat Upgrades and Foundry Upgrades for examples.\nManaging ownership\nTransparent proxies define an admin address which has the rights to upgrade them. By default, the admin is a proxy admin contract deployed behind the scenes. Keep in mind that the admin of a proxy can only upgrade it, but not interact with the implementation contract. Read Transparent Proxies and Function Clashes for more info on this restriction.\nThe proxy admin contract also defines an owner address which has the rights to operate it. By default, the proxy admin’s owner is the initialOwner address used during deployment of the transparent proxy if provided, otherwise it is the externally owned account used during deployment. You can change the proxy admin owner by calling the admin.transferProxyAdminOwnership function in the Hardhat plugin, or the transferOwnership function of the proxy admin contract if using Foundry.\nDo not reuse an already deployed ProxyAdmin. Before @openzeppelin/contracts version 5.x, the address provided to transparent proxies was an initialAdmin as opposed to an initialOwner of a newly deployed ProxyAdmin. Reusing a ProxyAdmin will disable upgradeability in your contract.\nUUPS and beacon proxies do not use admin addresses. UUPS proxies rely on an _authorizeUpgrade function to be overridden to include access restriction to the upgrade mechanism, whereas beacon proxies are upgradable only by the owner of their corresponding beacon.\nOnce you have transferred the rights to upgrade a proxy or beacon to another address, you can still use your local setup to validate and deploy the implementation contract. The plugins include a prepareUpgrade function that will validate that the new implementation is upgrade-safe and compatible with the previous one, and deploy it using your local Ethereum account. You can then execute the upgrade itself from the admin or owner address.CryptographyPrevious PageOverviewNext PageOn this pageOverviewInstallation and UsageHow the plugins workProxy patternsManaging ownership","tokens":1134,"squid":"ink-security_audits","role":"Sentinel","at":1791259144303,"hash":"67ac10e90b6cf56222c63f03c2889d48c8ce6a0e"}
{"url":"https://gov.optimism.io/t/treasury-appropriation-proposal-foundation-year-2-budget/5979","domain":"gov.optimism.io","title":"Treasury Appropriation Proposal: Foundation Year 2 Budget - Proposals 📃 / Foundation Budgets - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Treasury Appropriation Proposal: Foundation Year 2 Budget \n\n Proposals 📃Foundation Budgets\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2023\n\n 1 / 25\n\n May 2023\n\n Jul 2025\n\n post by system on May 12, 2023\n\n system\n\n Summary\nThe Optimism Foundation’s future operating budget of OP is subject to governance by the Token House. Each year, the Foundation can put forth a budget proposal and the Token House may approve or reject it.\nThe Foundation was allocated a Year 1 budget in the founding documents of the Optimism Collective. It has to date used 5.21% of this Year 1 budget.\nTherefore, the Foundation is symbolically requesting an additional 1 OP for its Year 2 (2023-2024) operating budget.\nThis vote is meant to introduce the Foundation budget approval process and set a precedent for future budget approvals.\nThis proposal will go to vote in Special Voting Cycle #12b on May 18th at 19:00 GMT.\nBackground\nWhat is the Optimism Foundation?\nThe Optimism Foundation is a Cayman Islands foundation company. Its mission is to support the establishment of the Optimism Collective, the development of the Optimism ecosystem, and the technology that powers it.\nThe Foundation is one component in an evolving and ever-growing web of companies, groups, and individuals driving towards realization of the Optimistic Vision.\nMore information on the Foundation and its goals is available in the Optimism Governance Documentation.\nFoundation Budget Proposals\nThe Optimism Foundation administers a portion of the token supply to further the Collective’s goals. This set of tokens will be referred to as the “Foundation Budget.” The Foundation Budget must be utilized in line with the overall OP Token Allocations, described in detail below.\nThis is the first Foundation Budget Approval proposal. The Foundation’s Year 1 operating budget was determined by the initial OP token allocations at the founding of the Collective on April 24, 2022. The core team decided on this allocation because they believed access to this portion of the treasury would would (a) give the Foundation the optimal leg-up to bootstrap and steward the Collective and (b) best position the Foundation to move more quickly along the Collective’s iterative path towards decentralization.\nGoing forward, any further budget for the Foundation must be approved by the Token House. As described in the Operating Manual, the Foundation may submit a proposal to the Token House once each year to request additional OP be added to the Foundation Budget.\nOverall OP Allocations\nThe overall ecosystem allocations of the total initial supply of OP (as outlined in the governance documentation) are as follows:\n\n858,993,459 OP (20%) to Retroactive Public Goods Funding\n1,073,741,824 OP (25%) to Ecosystem Fund (Governance Fund, Partner Fund, Seed Fund, Unallocated)\n816,043,786 OP (19%) to User Airdrops\n816,043,786 OP (19%) to Core Contributors\n730,144,440 OP (17%) to Sugar Xaddies (aka Investors)\n\nReview of Year 1 Budget\nIn Year 1 (April 20, 2022 → April 19, 2023), 30% of the total initial token supply was made available to the Foundation for administration in line with the overall token allocations detailed above. In utilizing these tokens, the Foundation may not exceed 30% of the total supply, and may not exceed any individual category’s allocation limit.\nThe Foundation’s administration of Year 1 budget was as follows:\n\nCategory\nDescription\nOP Distributed\n% total supply OP\n% Foundation budget\n\nRetroPGF\nDistributed in RetroPGF Round 2. More details.\n3,916,618 OP (out of 10,000,000 OP granted)\n0.09%\n0.30%\n\nPartner Fund\nDistributed across 48 partners.\n40,111,394 OP\n0.93%\n3.11%\n\nUnallocated\nFunded core protocol development, marketing, community programs, and operational services.\n11,368,634 OP\n0.26%\n0.88%\n\nAirdrops\nDistributed via OP Airdrop #2. Details Optimism Documentation.\n11,742,277.10 OP\n0.27%\n0.91%\n\nTOTAL\n\n67,138,923 OP\n1.56%\n5.21%\n\nToken Distributions Outside of Foundation Budget\nIn addition, outside the Foundation’s Year 1 budget, but in keeping with the overall OP Allocations:\n\n214,748,365 OP (5% of total OP) was distributed via Airdrop 1\n60,425,931 OP (1.4% of total OP) was granted by the Token House via the Governance Fund, of which 53,489,103 OP have been distributed\n\nAltogether, the Collective has distributed 335,376,391 OP, or 7.8% of total initial supply of OP. This information is available and updated in a public tracker here.\nDetails on Year 1 Budget\nGrants made from the Partner Fund were used to provide services and tooling to the Optimism community, promote education, experiment with liquidity mining programs, drive consumer usage, and/or support Optimism’s governance system.\nIn RetroPGF 2, badgeholders voted to distribute 10m OP to 195 projects and organizations who provided some public good to the Collective. Distributions are currently ongoing, and just shy of 4m OP have been distributed to date. More details on RetroPGF 2 results and methodology available here.\nFinally, Airdrop 2 distributed 11.7m OP to reward the delegation of OP tokens as an experiment to strengthen the Collective’s governance system. More details and methodology available in the governance documentation.\nFrame 1 (20)4628×2214 288 KB\n\nProposal\nThe Optimism Foundation is symbolically requesting an additional 1 OP for its Year 2 (April 20, 2023 → April 19, 2024) budget.\nRationale\nThe Foundation has adequate funding left over from its Year 1 budget to continue its role as a steward of the Optimism Collective for the next twelve months.\nIn April 2024, the Foundation may submit a new budget proposal to the Token House for review.\nLooking Ahead\nGoing forward, the Foundation expects to use the Foundation Budget left over from Year 1 in support of the four Collective Intents established as part of Governance Season 4, and in line with any updated Collective Intents the community aligns on in following seasons.\n\nAs this is the first instance of a Foundation Budget Proposal, feedback on the structure or contents is welcome.\n\n [Final] Inflation Adjustment Proposal (to 0%)\n\n Special Voting Cycle #12b Roundup\n\n Foundation Mid-Year Budget Update\n\n GFX Labs - Delegate Communication Thread\n\n CyberDyn0x Delegate Thread\n\n 5\n\n read \n\n 9\n min\n\n Unlisted on May 12, 2023\n\n Listed on May 12, 2023\n\n post by polynya on May 12, 2023\n\n post by jengajojo on May 15, 2023\n\n post by polynya on May 18, 2023\n\n post by bobby on May 19, 2023\n\n post by polynya on May 19, 2023\n\n post by cryptoAYA on May 19, 2023\n\n post by Griff on May 20, 2023\n\n post by Oxytocin on May 20, 2023\n\n post by polynya on May 20, 2023\n\n post by Gonna.eth on May 22, 2023\n\n post by polynya on May 22, 2023\n\n post by ETH3333 on May 24, 2023\n\n post by v3naru_Curia on May 25, 2023\n\n post by Blockford on May 25, 2023\n\n post by lefterisjp on May 25, 2023\n\n post by Bcoin on May 25, 2023\n\n post by itublockchain on May 26, 2023\n\n Load more posts below","tokens":1755,"squid":"ink-governance","role":"Council Listener","at":1791259152458,"hash":"bdcb41737af78397f08df51a61c36a5631f5246a"}
{"url":"https://docs.pyth.network/price-feeds/pro/understanding-price-data","domain":"docs.pyth.network","title":"Understanding Price Data | Pyth Developer Hub","text":"Pyth ProUnderstanding Price DataLearn about confidence intervals, best bid/ask, and what these metrics representThis page explains the key metrics in Pyth Pro price feeds and what they represent. Understanding these concepts is essential for properly interpreting price data and building robust applications. For technical field specifications and API details, see Payload Reference.\nPublisher Contributions\nEach publisher contributes up to three prices in every update:\n\nBest bid price: the highest price at which the publisher is willing to buy.\nPrice: the publisher's view of the mid/market price.\nBest ask price: the lowest price at which the publisher is willing to sell.\n\nAll three values are optional — a publisher may submit any subset of them in a given update depending on what its data sources provide. An update that contains none of the three is rejected and does not contribute to the aggregate. The aggregate metrics (price, confidence, bestBidPrice, bestAskPrice) are derived from whichever values publishers have contributed.\nPrice\nThe aggregate price is the median of all publisher prices when at least min_pub publishers have contributed a price in the current aggregation window.\nIf fewer than min_pub publishers have contributed a price, no new aggregate is produced. In this case none of the price properties update — price, confidence, bestBidPrice, bestAskPrice, emaPrice, emaConfidence, publisherCount, and feedUpdateTimestamp are all carried forward from the previous update. The only property that still updates is marketSession, which reflects the current trading session regardless of whether a fresh aggregate was produced.\nConsumers can detect this case by comparing feedUpdateTimestamp against the update's timestampUs — if they differ, the price data is carried forward from a prior update rather than freshly generated. See Payload Reference for details on these fields.\nConfidence Interval\nConfidence reflects the measurement uncertainty of the prices reported among publishers. This may or may not reflect the uncertainty (volatility) of the underlying market price. A high confidence value means publishers are deviating from the aggregate more than usual — whether because market conditions are volatile, publishers hold varying views on the current price, or there is less agreement across data sources. A low confidence value means publishers are in closer agreement about the price.\nBecause confidence captures publisher disagreement rather than market volatility directly, a low publisher count can distort it: non-optimal behavior from a single publisher — for example, being slow to update or serving stale data — can move confidence in ways unrelated to the market. We recommend:\n\nUsing publisherCount to filter out updates with too few contributors for your use case.\nUsing emaConfidence rather than raw confidence to smooth out short-term noise.\n\nHow Confidence Is Calculated\nConfidence is the maximum distance from the aggregate price to the 25th and 75th percentiles of the combined publisher dataset:\n\nPool all publisher quotes: For each publisher, collect their price, bestBidPrice, and bestAskPrice into a single combined dataset across all publishers (missing fields are imputed first — see below).\nCompute percentiles: Calculate the 25th percentile (p25) and 75th percentile (p75) of the combined dataset.\nTake the maximum distance: confidence = max(price − p25, p75 − price), where price is the aggregate price.\n\nThis approach uses the interquartile range of all publisher quotes, so the confidence reflects both price disagreement and publishers' view of market depth.\nImputing Missing Fields\nPublishers may submit any subset of price, bestBidPrice, and bestAskPrice (see Publisher Contributions). Before a publisher's quotes are added to the pool, missing fields are imputed from what they did provide:\n\nOnly one field provided: the other two are set equal to it.\nprice missing, both bestBidPrice and bestAskPrice provided: price is set to the average of bestBidPrice and bestAskPrice.\nprice provided, bestBidPrice or bestAskPrice missing: the missing bid/ask is set equal to price.\n\nThis ensures every publisher contributes three values to the confidence calculation regardless of which fields they submitted.\nBest Bid and Best Ask\nExperimentalThese fields are experimental and not yet covered by automated data quality assurance.\nSee Payload Reference for details.\nBest Bid and Best Ask represent the tightest non-overlapping bid and ask across all contributing publishers. The aggregation selects the highest bid and lowest ask such that bestBidPrice < bestAskPrice — publisher quotes that would cross are excluded so the resulting spread is always well-formed.\nFieldDescriptionbestBidPriceThe highest bid price across publishers that does not cross any publisher askbestAskPriceThe lowest ask price across publishers that does not cross any publisher bid\nHow Best Bid/Ask Differ from Confidence\nWhile both metrics provide insight into market conditions, they measure different things:\nMetricWhat It MeasuresUse CaseConfidence IntervalPublisher agreement/disagreement on priceRisk management, uncertainty assessmentBest Bid/AskInside market pricesSpread analysis, execution planning\nThe spread between best bid and best ask (bestAskPrice - bestBidPrice) shows the current market spread as seen across publishers. This is different from the confidence interval, which shows how much publishers' prices vary from the aggregate.\nUsing Best Bid/Ask\nBest bid and ask are useful for:\n\nSpread analysis: Understanding current market liquidity conditions\nExecution planning: Estimating slippage for trades\nMarket health monitoring: Tracking spread widening during stress periods\n\nRemember: Publisher uncertainty (confidence interval) does not always reflect\nmarket uncertainty. Use both confidence intervals and best bid/ask data\ntogether for a more complete picture of market conditions.\nEMA Price and EMA Confidence\nemaPrice and emaConfidence are exponentially-weighted moving averages of the aggregate price and confidence, with an averaging window of approximately 1 hour.\nIn an EMA, the most recent samples receive the most weight and older samples decay exponentially. For a 1-hour window, samples roughly 1 hour in the past contribute about 50% of the weighting, samples 2 hours back contribute ~25%, 3 hours back contribute ~12.5%, and so on. This produces a smoothed view of the price that is resilient to short-term noise while still tracking sustained moves.\nThe averaging is also inverse-confidence weighted: samples with a tight confidence interval contribute more weight than samples with a wide confidence. This dampens the influence of outlier aggregates published with high uncertainty, so transient publisher disagreement does not pull the EMA around.\nEMA does not reset on market session boundariesemaPrice and emaConfidence continue averaging across session\ntransitions (for example, from regular to postMarket to overNight,\nor back to regular). The EMA observed early in a new session still\ncarries contributions from the prior session's aggregates, so it may\nreflect overnight or pre-market activity rather than the current session\nalone. Consumers doing session-specific analysis should keep this in\nmind — the EMA is a rolling 1-hour average, not a per-session average.\nCircuit Breakers\nThe aggregator applies circuit breakers to reject publisher updates that are clearly out of line with the expected price. When a circuit breaker trips, the offending publisher update is excluded from the aggregation window rather than being counted toward the median. This protects the aggregate from stale, mis-scaled, or otherwise anomalous inputs during known sensitive periods.\nSplit / Reverse-Split Corporate Actions (US Equities)\nWhen a US equity undergoes a stock split or reverse split:\n\nThe previous overNight session is closed on the execution date — there is no overnight aggregation spanning the corporate action boundary.\nThe split or reverse split is applied at the start of the next preMarket session for feeds enabled for 24/5 trading, and at the start of the next regular session for feeds enabled only for the regular session. From that point forward, all aggregate prices reflect the adjusted share count.\n\nPublishers ingesting prices from upstream venues may not immediately pick up the corporate action and could briefly continue to publish non-adjusted (pre-split) prices after it takes effect. To keep these stale prices out of the aggregate, the aggregator rejects publisher updates whose price deviates beyond a threshold from the adjusted last price (for example, ~10%) for a protection window after the action is applied (for example, ~10 minutes into the new preMarket session). Once the window ends, aggregation returns to normal behavior.How Pyth Pro WorksUnderstand the services that power Pyth Pro’s low-latency price deliveryChange LogDaily record of status transitions on Pyth price feeds — additions, activations, and removals.","tokens":2256,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259158295,"hash":"a53e588e7905eb79473c0f58a543b41965a656b8"}
{"url":"https://gov.optimism.io/t/treasury-appropriation-proposal-foundation-year-2-budget/5979/25","domain":"gov.optimism.io","title":"Treasury Appropriation Proposal: Foundation Year 2 Budget - Proposals 📃 / Foundation Budgets - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n read \n\n 9\n min\n\n May 2023\n\n 25 / 25\n\n Jul 2025\n\n Jul 2025\n\n Load more posts above\n\n post by polynya on May 18, 2023\n\n polynya\n\nAs the above mentioned request was ignored, I have voted Against this proposal. I will continue to hold Foundation’s work in distributing $OP tokens to a higher standard.\n\n Season 7: Intent\n\n post by bobby on May 19, 2023\n\n bobby\n\n polynya\n\n Hi @polynya, thank you for the thoughtful response.\nI agree the Foundation has not distributed as many tokens as originally expected.\nOur intention was not to mislead anyone, but rather to be a responsible steward of our existing budget for the benefit of Optimism. There are a couple factors that contribute to this:\n\nWe want to be able to prove good ROI on token spend. We have been carefully following the analytics put out by OP Labs to understand incentives and grants’ effects on TVL, transaction volume, and gas fees. We’ve also applied similar analysis to Partner Fund distributions and Airdrops #1 and #2. We want to be able to prove that OP distributions are moving key ecosystem metrics, which has not always been the case, and this has affected the velocity with which we distribute tokens.\n\nMarket conditions have affected the number of quality targets for OP. The graph linked above was shared as an indication of total possible spend, and the market reality has pushed us away from the max distributions displayed there. We acknowledge that this should have been communicated more clearly and proactively to the community. While farmers are persistent, the bear market means explorers and new-to-crypto users who may benefit most from incentive programs are also in shorter supply. The Foundation is instead focused on programs that target builders, through our Collective Intents, the recently launched Foundation Mission (RFP) program, our ideas list, and work on RetroPGF.\n\nGoing forward, we’re committed to sharing a clearer framework for how the Foundation evaluates OP spend based on ROI. Our goal is to be able to express target metrics for token spend across tx/OP, TVL/OP, gas/OP, addresses/OP, delegatedOP/OP, or a combination of those metrics, and to report back on how distributions measure up against these targets.\nWe’ve published an estimate of future annual token spend, but these numbers are just estimates, not commitments, and actual token distributions will be determined by the Foundation’s ability to develop distribution programs with good, measured ROI.\nThe Foundation will commit to providing a mid-year report in November 2023 to update the community on how we’re tracking against those estimates in advance of next year’s annual budget proposal. In the case that we are not tracking to hit the estimates above, the midyear report will be an opportunity for the Foundation to sync its decision-making algorithm with the broader community.\nWe continue to welcome tactical or strategic feedback on how token allocations could be used to help support the Collective and grow Optimism’s ecosystem. For example, your idea here on delegate bonding curves may make a great RFP and is a helpful suggestion to focus distributions on providing real value to the Collective.\nThank you, as always, for your feedback.\n\n Polynya - Delegate Communication Thread\n\n post by polynya on May 19, 2023\n\n polynya\n\n Appreciate the response. As I’ve mentioned before, the damage caused by withholding supply is far greater than being worried about farmers. Farmers will always be there, and the good news is they’ll distribute tokens out to real investors in very short order. I understand this is subjective, but it also depends on the magnitude of the problem, of course - and at 1 year circulating supply being only 7% is indeed a massive problem, even moreso with the insider unlocks coming up shortly, which will become a significant portion of circulating supply. At this stage, the focus should be on distributing tokens to a representative circulating supply and rebuilding confidence in the $OP token with greater transparency. My symbolic dissent vote stays, and I hope things improve significantly for Year 2 so I can come back and vote For enthusiastically next year.\n\n post by cryptoAYA on May 19, 2023\n\n cryptoAYA\n\n Greetings,\nDespite weeks passed from the voting days for this proposal, revising and reviewing this proposal gives me thrilling sense.\n\n post by Griff on May 20, 2023\n\n Griff\n\n I’m voting against as well but for a different reason.\nI think it’s fine that we hold back the airdrops until the attestation station and other reputation systems are in place…\nBut i’m voting no on this because symbolic proposals are a waste of everyone’s time…\nWhy spend the time writing this forum post and making everyone read it to send out 1 OP? We all have better things to do.\nNot to mention… I don’t see multiple delegates supporting this proposal… I thought that was a requirement for a vote?\n\n post by Oxytocin on May 20, 2023\n\n Oxytocin\n\nProposals from the foundation do not currently need delegate backing I believe\n\nTime isn’t the real concern here in my opinion, the real problem is the capital inefficiency that is occuring from making such a symbolic vote onchain.\nHere is the onchain vote. I don’t see an easy way of seeing the number of individual voters, but I stopped counting after around 250. Each vote costs around .4 dollars in gas give or take (it can go as high as 1.3 dollars, according to another delegate). At current prices, this means that the combined gas spent to symblically send 1 OP easily passes 60 OP , all paid from each individual’s ETH balance. Aka, this vote costed at least 6000% more to the community than the value at stake.\nI know this is not a problem specific to this vote, but issues like this are significant blockers for Governance Accesibility, which has been voted in as a Collective Intent . From what I’ve seen on the onchain voting thread some solutions are being explored, but I really recommend we refrain from these symbolic votes for now. They are hurting inclusivity and in and could lead to long-term consequences due to missed votes hurting people’s delegate profiles and future Attestation scores.\n\n Oxytocin - Delegate Communication Thread\n\n post by polynya on May 20, 2023\n\n polynya\n\n Griff\n\n Some Foundation proposals (e.g. Treasury Appropriation) are exempt from requiring delegate approval, and I do think symbolic votes are useful in gauging support for Foundation’s actions. Most delegates support, while I do not, and dissenting voices can sometimes be useful in pushing the Foundation to do better (and judging by Bobby’s response, they are determined to do so).\nI understand the desire to wait for better airdrop mechanisms, but the magnitude of supply overhang for $OP, with ~93% still pending circulation, is the worse evil IMO. Even an ineffective airdrop is sorted out by the market in short order; a supply overhang, lack of clarity and loss of confidence has long-term detrimental implications for the $OP token and by extension the Optimism collective.\n\n post by Gonna.eth on May 22, 2023\n\n Gonna.eth\n\nI disagree with this quote. Many times foundations reaffirmed this was an evolving process and the first distribution chart was an intention.\n\nHow can you experiment and have a detailed distribution at the same time? Looking at how governance has evolved, we went from every delegate vote on every proposal to subcommittees and intents. Are you able to predict this sort of thing?\n\nDo you have some metrics to back this?\n\nCurious to know how this happens?\n\nThe focus should be to bring builders, public goods, and great ideas in. Make the ecosystem robust and full of use cases. I feel capital won’t move if they just see governance debating on the circulating supply of a governance token.\n\n post by polynya on May 22, 2023\n\n polynya\n\nIt’s about the magnitude of deviation.\n\nProjections, not distribution. Also, as I specifically mentioned, this is for the areas under Foundation’s purview and predictable, like Airdrops, RPGF, Partner Fund etc. This does not apply to Governance Fund, obviously, which is more prone to experimentation.\n\nFarmers sell on the market to investors.\n\nThis thread is about treasury appropriation by Foundation. Fortunately, Bobby has done a good response about acknowledging the mistakes made, and how they are striving to do better this year. It’s not quite enough for me, personally, but it’s progress, and I’m happy to leave this thread at that. We can discuss bringing builders and public goods at a more appropriate venue.\nLastly, certainly there’s subjective opinion here - particularly the magnitude of damage caused by withholding supply, or how far distribution has deviated from projections. I’ll happily agree to disagree.\n\n post by ETH3333 on May 24, 2023\n\n ETH3333\n\n Disappointing, although you have cooperated with some big organizations (coinbase, OW, etc.) this year, but people don’t have much nostalgia for OP,because you are fooling that the strongest partner is the community not the resources，looking at what is being discussed in various communities, it seems that your OP has been forgotten in history, but you still want to change the time and amount of token distribution, which is tantamount to slow death, quietly ARB, TVL is several times that of OP , and then look at the ecological projects on the chain, not to reflect on how to get the attention and support of the community, but to engage in some seemingly lofty things\n\n post by v3naru_Curia on May 25, 2023\n\n v3naru_Curia\n\n I would like to express our support and cast vote in support for the Year 2 budget proposal put forth by the Optimism Foundation. We appreciate the Foundation’s role in stewarding the Optimism Collective and recognizing the current issue in the foundation budget to continue its operations.\nHowever, we also share the community’s concerns about the Foundation’s handling of OP’s token distribution. The discrepancy between the projected and actual distribution of tokens during Year 1 has raised questions about transparency and confidence in the $OP token.\nThanks @bobby , for shedding light on the factors that led to this distribution discrepancy. It is reassuring to know that the Foundation is taking steps to address this issue by pledging to provide a mid-year report in November 2023, as well as a more transparent framework delineating how OP spends are evaluated based on ROI with respect to distribution. These measures are crucial in bolstering accountability and equipping the community with a better understanding of the Foundation’s decision-making processes. Looking forward those commitment in the near future!\n\n post by Blockford on May 25, 2023\n\n Blockford\n\n You’ve made some interesting observations. I tend to agree with you.\n\n post by lefterisjp on May 25, 2023\n\n lefterisjp\n\n I tend to agree with the things that @polynya mentioned and happy to see Bobby post a response.\nBut if you do not need any funding why do we need to each pay ~$.23 in gas to send you 1 OP by voting for this proposal? The proposal and this whole on-chain voting system feels like such a waste of time and money as I already mentioned here: It Is Time For On-Chain OP Voting - #13 by lefterisjp\nI will also vote with a dissenting voice but to ask you guys to:\n\nGet rid of symbolic on-chain votes. Check my post above explaining why.\nGive true governance to the OP-holders. I know it’s a gradual process but a year on it seems we still mostly rubber stamp what the foundation wants. It feels like the foundation is in almost total control. This needs to change and fast. Onchain voting should be for onchain actions. Which means we the OP holders should have full control for it to make any sense.\n\nTry to improve the OP distribution as @polynya mentioned.\n\n post by Bcoin on May 25, 2023\n\n Bcoin\n\n Got it , so Treasury for PR and Community , it’s so good\n\n post by itublockchain on May 26, 2023\n\n itublockchain\n\n By examining the Foundation Budget data for Year 1, we found the distribution of the budget is insufficient. The Foundation seems to fail the distribution and cause a larger token supply overhang, as only the 5.21% is distributed.\nWe appreciate the Foundation’s response for the concerns, however despite mentioning the main focus is on supporting builders via RetroPGF and Partner Fund in the response, we think the distribution of both category is still inadequate.\nimage900×511 103 KB\n\nFor Year 2, we believe the distribution process must be more detailed, wide and transparent. We decided to vote “against” on the proposal to show our concerns.\n\n post by Jayref on May 28, 2023\n\n Jayref\n\n Voted against the proposal due to points already raised by Polynya. While the Foundation has commented on the discrepancy between realized and budgeted token distrubution (I agree with Polynya that commentary so far fails to explain rationale adequately), I would appreciate if the Foundation would comment on future outlook on token distribution.\nIs the expectation that distribution will continue to strongly lag behind budget, will it accelerate to catch up to original budget, or will it match budget going forward?\n\n post by Luckyhooman.eth on May 30, 2023\n\n Luckyhooman.eth\n\n Voted against this proposal and would have preferred to see the inclusion of executable code alongside the vote to move the 1 OP and officially conduct our first On chain vote with executable code.\nI too share similar reasons as Polynya and Lefterisjp\n\n post by Paradocer on Jun 6, 2023\n\n Paradocer\n\n polynya\n\n It is a detailed and informative article. Thanks. \n\n post by JosephGlaeser on Jun 7, 2023\n\n JosephGlaeser\n\n I see a lot of replies talking about the way airdrops were handled; I just wanted to add that per the guidelines for the first airdrop I should have received something like 2500 OP, as I qualified for 4 out of the 6 categories however I received airdrop for only 1 category and had zero recourse. Needless to say that basically killed my confidence in OP; which really sucks because I have been a supporter from the very beginning. One other thought if that happened to me how many other people did that happen to, granted that not everyone else had the same zeal for OP that I had but still…. Fixing things like this rather than steam rolling past them with an attitude of “too bad for them!” Or “that was a year ago!”, is imperative if OP is ever going to be a serious contender in L2\n\n 2 years later\n\n post by abuchtela on Jul 29, 2025\n\n abuchtela\n\n Your absolutely correct! And mention you should have gotten allocated amounts in airdrops, I and I’ve seen a few others qualified on every step but wrongly recieved nothing, and have mentioned the mistake over the course of a few years now and still here being an active participant to the community and sadly still receiving nothing.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Foundation Year 3 Budget Update\n\n Foundation Budgets\n\n Summary\nThe Optimism Foundation’s operating budget of OP, subject to governance approval by the Token House, maintains the original budget set into motion in both Year 1 and Year 2 proposals. \nFor this year’s operating b…\n\n read more\n\n 0\n\n 737\n\n Sep 2024\n\n Foundation Mid-Year Budget Update\n\n Foundation Budgets\n\n Summary\nThis is a mid-year update on the Foundation’s use of its token budget. \nNo action is necessary from our Token House delegates; this is purely informational. Feedback is welcome, as always. \nBackground\nFoundation …\n\n read more\n\n 7\n\n 1.3k\n\n Dec 2024\n\n Re-designating the User Airdrop Allocation as the Strategic Ecosystem Fund\n\n Proposals 📃\n\n Proposal Type: Rights Protections \nExecutive Summary\nThe Optimism Foundation is proposing to re-designate the unspent tokens in the User Airdrop allocation as a new allocation category, the Strategic Ecosystem Fund, prop…\n\n read more\n\n 12\n\n 1.3k\n\n 9d\n\n [DRAFT] [GF: META] Proposal to reserve a share of GF distribution for liquidity backstopping and stronger governance\n\n Technical Proposals\n\n The Commons: shoring up OP’s liquidity, governance, and funding capacity\nHi, I’m Jack from Velodrome, a leading Optimism dex that recently received a 3mm OP grant from OP Labs, a close collaborator in the build of our pr…\n\n read more\n\n 77\n\n 7.6k\n\n Dec 2022\n\n Governance Update #2\n\n Governance Updates\n\n season-1\n\n Voting Underway\nOptimism’s Token House is up and running! For the past six weeks, Token House delegates have been reviewing and voting on Governance Fund grant proposals from projects across the Optimism ecosystem. \nIn t…\n\n read more\n\n 14\n\n 3.8k\n\n Dec 2022","tokens":4167,"squid":"ink-governance","role":"Council Listener","at":1791259162917,"hash":"f9830c43ad40c9c32a489187b1fa7850cddf06fd"}
{"url":"https://io.net/docs/guides/staking/staking","domain":"io.net","title":"How to Stake - io.net","text":"​Table of Contents\n\nStaking Tab\nHow to Stake\n\nConnect Crypto Wallet\nStake $IO\n\nSmart Contract Address\n\n​Staking Tab\nTo view the Staking tab, go to io.net > IO Worker > Staking. This tab displays information about your staking earnings:\n\nTotal Wallet Balance in $IO\nTotal Active Stake in $IO\nTotal in Cooldown in $IO\nRewards from the Latest Block in $IO\n\nStaking rewards are not automatically compounded. The unstaking process takes fourteen days to complete. $IO in the unstaking process (cooldown) does NOT count towards staking requirement.\n​How to Stake\n​Connect Crypto Wallet\nTo stake on IO, you need to connect your crypto wallet.\nIf you stake more than the minimum required stake, you don’t earn extra block rewards.\n\nIn io.net, go to IO Worker > Staking tab.\n\nClick Connect Crypto Wallet on the right side on the Staking page.\n\nSelect your crypto wallet in the pop-up window. Please note that this wallet can be different from the wallet you have associated with your account. For example, see Solana Wallet to learn more.\n\nThe Phantom wallet prompts you to connect with IO. Click Connect to proceed.\n\nAfter the wallet is connected, your Wallet ID is displayed on the right side of the Staking page. This indicates a successful connection.\n\n​Stake $IO\nNow that your crypto wallet is connected, you are ready to stake $IO..\n\nLocate the worker you want to stake to and click the Stake button under Staking Actions in the Manage Your Stake & Devices table.\n\nIn the pop-up window, enter the required amount of $IO for your hardware, and confirm by clicking the Stake button. Remember that you can always add to your $IO stake later, but you must use the same wallet that you originally used to stake on that device.\n\nYou can unstake at any time, and an Unstake option will be available for each device you’ve staked. Bear in mind that once you unstake, you will need to wait for a 14-day cooldown period before the stake can be withdrawn. Stake in cooldown does not count towards the staking requirement for devices to receive Block Rewards.\n​Smart Contract Address\nThis smart contract address is a unique identifier where the $IO staking contract is deployed:\nhttps://solscan.io/account/8tvkkogztREitU38YBxZDmirRiarcm5vNaCV2P2pFArz \n\n​Security\nSolscan allows you to explore and view data stored on the Solana blockchain. You can use this to verify the smart contract address you are interacting with against the official address provided in our documentation. This ensures you are engaging with the legitimate contract.\nYou can also review the total amount of $IO staked on the blockchain. You can confirm the staked amounts and verify that info matches your expectations.\nRead the suggestions below to enhance the security of your stake:\n\nManually enter io.net into your URL to stake and bookmark it. Don’t search for io.net to avoid imposter websites. Sites such as GoDaddy offer domain lookups. Most imposter sites are active for a very short period of time.\nDo not click on links from unverified sources. Beware of strangers approaching you on social media about crypto opportunities.\nBe aware of phishing websites and fake contracts that attempt to mimic our staking platform. If something seems suspicious, verify the information with our resources or contact our support team.\nAlways use a secure wallet and consider hardware wallets for added security. Be cautious of any prompts that ask for your private keys or seed phrases. We won’t ask for this information.\nWas this page helpful?","tokens":874,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259173416,"hash":"99f7d681a0b0912b17285cf65ea4db9c1a6b6417"}
{"url":"https://gov.optimism.io/c/88-category/foundation-budgets/86","domain":"gov.optimism.io","title":"Latest Proposals 📃/Foundation Budgets topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Foundation Budgets\n\n Proposals 📃\n\n Foundation Budgets\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Foundation Budgets category\n\n 0\n\n 78\n\n Sep 2024\n\n Collective Year 4 Budget Update and Year 5 Budget Outlook\n\n Summary\nYear 4 (May 2025 to April 2026) was a year of focus and fiscal discipline. The Collective committed roughly 150M OP of new commitments across Season 8 and Season 9, about one third less than the 229.92M OP commit…\n\n read more\n\n 2\n\n 441\n\n Aug 7\n\n Treasury Appropriation Proposal: Foundation Year 2 Budget\n\n Summary\nThe Optimism Foundation’s future operating budget of OP is subject to governance by the Token House. Each year, the Foundation can put forth a budget proposal and the Token House may approve or reject it. \nThe Fo…\n\n read more\n\n 22\n\n 8.2k\n\n Jul 2025\n\n Collective Year 3 Budget Update and Year 4 Budget Outlook\n\n Collective Year 3 Budget Update and Year 4 Budget Outlook\nThank you to the Budget Board for review and feedback on a draft version of this update. \n\nSummary\nYear 3 (May 2024 to April 2025) delivered exceptional growth: T…\n\n read more\n\n 1\n\n 343\n\n Jun 2025\n\n Foundation Mid-Year Budget Update\n\n Summary\nThis is a mid-year update on the Foundation’s use of its token budget. \nNo action is necessary from our Token House delegates; this is purely informational. Feedback is welcome, as always. \nBackground\nFoundation …\n\n read more\n\n 7\n\n 1.3k\n\n Dec 2024\n\n Foundation Year 3 Budget Update\n\n Summary\nThe Optimism Foundation’s operating budget of OP, subject to governance approval by the Token House, maintains the original budget set into motion in both Year 1 and Year 2 proposals. \nFor this year’s operating b…\n\n read more\n\n 0\n\n 737\n\n Sep 2024","tokens":465,"squid":"ink-governance","role":"Council Listener","at":1791259177929,"hash":"905a02ffa06888c8444995ce532064ef1cdd26a3"}
{"url":"https://www.pyth.network/indices?utm_campaign=pyth-indices&utm_medium=plan_selector_indices&utm_source=pyth-app","domain":"pyth.network","title":"The Price Layer for Global Finance | Pyth Network","text":"24/7 Financial IndicesThe world’s first and largest 24/7 index provider. Full display rights, multiple asset classes, and zero licensing fees.Explore IndicesContact the TeamUsed by modern financial institutions and applicationsProprietary indices constructed from Pyth's price feeds enable 24/7 markets across asset classes. Continuous pricing across commodities, equities, metals, and FX.Available NowUse Pyth Indices to Create New MarketsCommoditiesBRENT1MLWTI1MHHGAS1MHLGAS1MTGASTGAS1MCOPPER 23/58 MoreFXeur/usdusd/jpy2US EquitiesAAPLAMZNCOINEWYGOOGLJP225KR200METAMUNBISOPENAIORCLPLTRSAMSUNGSKHYSNDKSOXLSOXSUS100US30US5009 MoreMetalsXAUXAG1OZGOLD3Ready to explore more?Request AccessWord on The StreetWhat the market is saying about Pyth.Coinbase has been at the forefront of this evolution, and our growing share of the derivatives market is a direct reflection of that commitment. Tools like Pyth Indices help fill the critical infrastructure gaps that make this next era of markets possible.Boris IlyevskyHead of DerivativesExtending our thematic equity expertise into 24/5 infrastructure is not simply a technical upgrade — it is a rethinking of what 'round-the-clock' price discovery looks like. The partnership with Pyth gives us the data foundation to support reliable, near-continuous pricing, and Coinbase's perpetual futures platform is the ideal first proof of concept for what we believe will be a much broader market.Josh KaplanHead of Research & Investment StrategyPyth's price feeds are both granular and easy to consume, complementing Kalshi's mission to make these markets accessible to a broader set of retail and institutional participants.John WangHead of CryptoPyth Indices give us a continuous benchmark for assets where the underlying market doesn't trade round the clock. That matters because Kraken is launching perpetual contracts on oil, and a perpetual needs a 24/7 reference price to function.John PalmerGlobal Head of Derivatives at KrakenCoinbase uses Pyth Indices to create custom baskets for their users.AI10Defense10China10Tech100Request a Custom Indexpyth indicesBuild for markets that never closePower exchanges, platforms, and applications with continuous index pricing across equities, commodities, metals, FX, and thematic markets. Talk to our team about coverage and integration.Explore Pyth IndicesContact the Teamconnect with usRequest Index AccessContact Douro Labs to access existing Indices, discuss custom methodology, and more.The Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":804,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259181045,"hash":"9e8b5c5da905230ac9cffcab64b914722da81675"}
{"url":"https://gov.optimism.io/t/collective-year-3-budget-update-and-year-4-budget-outlook/10057/1","domain":"gov.optimism.io","title":"Collective Year 3 Budget Update and Year 4 Budget Outlook - Proposals 📃 / Foundation Budgets - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Collective Year 3 Budget Update and Year 4 Budget Outlook \n\n Proposals 📃Foundation Budgets\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 1 / 2\n\n Jun 2025\n\n Jun 2025\n\n post by system on Jun 24, 2025\n\n system\n\n Collective Year 3 Budget Update and Year 4 Budget Outlook\nThank you to the Budget Board for review and feedback on a draft version of this update.\n\nSummary\nYear 3 (May 2024 to April 2025) delivered exceptional growth: The Collective committed 229.92M OP across Season 6 and Season 7, driving the Superchain to 68.3% L2 market share, $5.5B TVL, and 16.9M daily transactions (source: Superchain Health Dashboard)\nSeason 8 Focus: 51-81M OP earmarked for interoperability and continued Superchain growth. No new token allocation requested—operating within the original framework.\nKey wins:\n\nEcosystem Expansion: Major partners like Kraken (Ink), Sony (Soneium), and Uniswap (Unichain) joined the Superchain for a total of over 30 chains in the Superchain Ecosystem. (source: SuperchainEco)\nCore Development: Delivered permissionless fault proofs, Stage 1 decentralization, and Superchain devnet.\nCommunity Growth: 10.4 M OP committed via Airdrop 5 across 54,723 unique addresses and increased 30-day retention by 4.2 percentage points. (source: Airdrop 5 Analysis)\nPublic goods: 26.4M OP committed via Retro Funding across 437 grantees\nRevenue: The Optimism Collective generated 17,756 ETH in revenue (all time) from operating the Superchain, primarily driven by Base’s RevShare (6,210 ETH), and OP Mainnet (11,170 ETH).\n\nFinancial Overview\nTotal circulating supply: 1.75B OP (40.8% of total)\nTotal committed: 2.51B OP (58.4% of total).\nThe current circulating supply of OP, is maintained in the public OP Token Unlock tracker and updated weekly. *See Appendix for definitions of Circulating vs. Committed OP and Ecosystem fund info.\nNotable acceleration: Ecosystem Fund supply in circulation increased 5x (55M to 277M OP) as major partner grants that were previously committed became unlocked.\n\nYear 3 Strategic Highlights: Season 6 & 7\nEcosystem Growth: 176.34 M OP Committed\nimage1370×532 36.4 KB\nChain & Infra: Successfully onboarded major new entrants including Kraken (Ink), Sony (Soneium), Uniswap (Unichain), World Chain (World), and Celo. This included token grants aimed at bootstrapping these ecosystems by fostering liquidity, infrastructure development, and user acquisition on new OP Chains. There are now over 30 chains in the Superchain Ecosystem. Funded essential tooling (Oracles, RPC Endpoints, Wallet Infra, Dev Tooling, Audits, and Analytics) to support seamless cross-chain functionality.\nCore Stack Development: Delivered critical infrastructure including permissionless fault proofs and Stage 1 decentralization (including OP Mainnet, Base, Ink, and Unichain). Implemented L1 Pectra defense and L2 Pectra support. Advanced interoperability through Superchain devnet and standardized APIs.\nAirdrops & Growth Campaigns: Airdrop 5 launched in October 2024, allocating 10.4M OP to 54,723 Superchain power users. With the completion of Airdrop 5, a total of 266.6M OP has been committed via user airdrops to date. Please note that SuperStacks - an experimental pilot points campaign, launched to show how the Superchain can benefit from more dynamic incentives - is not yet included in the numbers for Airdrops + User incentives as the program has not concluded.\nGov Tooling, Foundation Gov Missions and Community: The Foundation made grants to support the development of various experiments, including futarchy. Grants to the community included funds to support badgeholders, security council members, collective feedback commission members, and governance participant compensation.\nMarketing Support: Committed to supporting Marketing efforts for Superchain and broader Ethereum community. They include: DAO Research Collective, We3 User Research, and Ethereum Interop Forum.\nThe Foundation’s approach remains mission-aligned and outcome-driven.\nRetroactive Public Goods Funding: 26.4 M OP Committed\nimage1320×218 12.4 KB\nYear 3 completed four targeted scopes (26.4M OP total):\n\nRound 5, OP Stack (Oct 2024): 8M OP rewarded contributors to the OP Stack, including Ethereum Core Development, OP Stack R&D, and developer tooling (Results).\nRound 6, Governance (Dec 2024): 2.4M OP was committed to governance contributors, including elected governance bodies, tooling, and analytics (Results).\n\nRetro Funding saw a major evolution in Season 7. The program shifted from periodic rounds to continuous rewards with two ongoing missions:\n\nThe Retro Funding Onchain Builders Mission, rewarding onchain applications across the Superchain.\nThe Retro Funding Developer Tooling Mission, rewarding developer tools that empower onchain builders.\n\nNew approach benefits:\n\nAlgorithmic impact measurement reduces subjectivity\nMonthly rewards improve reliability for builders\nCitizens’ House governs algorithm selection\n16M OP earmarked for Season 7 Retro Funding Missions\n\nOverall, only 76.4M OP has been committed to date (9% of 859M OP allocation), with 91% (782.6M OP) still available for future retroactive rewards.\nGovernance Fund: 27.19 M OP Committed by Token House\nimage1368×218 12.7 KB\nThe Governance Fund continued to operate throughout Year 3 as an important avenue for community led grants. Token House delegates evaluated and approved numerous proposals funding experiments and ecosystem projects.\n\nSeason 6 Grants Council Retrospective\nSeason 7 Grants Council Retrospective\n\nThis represents a steady increase in utilisation as the delegate community grows more active.\nBudget Impact and ROI Framework\nYear 3 established strong baseline metrics for measuring ecosystem return on investment. The Collective generated 17,756 ETH in protocol revenue across the Superchain primarily driven by Base’s RevShare (6,210 ETH), and OP Mainnet (11,170 ETH).\nThe Foundation is implementing enhanced ROI models to measure grant effectiveness across horizons of 1-3 years.\nRevenue Attribution by Grant Category:\n\nChain & Infrastructure grants: Direct correlation to new chain revenue contributions\nCore Stack Development: Protocol efficiency gains and user/chain/developer growth driven by new features.\nGrowth Campaigns: Transaction volume growth, liquidity growth, and user retention metrics\nPublic Goods: Developer ecosystem growth and long-term value creation\n\nEarly Success Indicators: Base’s rapid growth to 3,105 ETH average annual revenue run-rate within two years demonstrates the potential returns from strategic ecosystem grants.\nUpcoming Analysis: Comprehensive ROI reporting of Ecosystem Fund planned for Q4 2025, including revenue per chain onboarded, TVL-to-revenue conversion rates, and network effects measurement across the Superchain.\nA complete ROI analysis of S7 grants from Retro Funding, Grants Council, and Futarchy experiment will be published to the governance forum by Open Source Observer by the end of June.\nSeason 8 Budget Outlook\nLooking ahead, the Foundation will continue managing the budget within the original allocation framework. The table below outlines the Season 8 directional estimates.\nThese projections are subject to adjustment based on program performance and governance input:\n\nEcosystem Fund\nSeason 8 Budget\n\nCore Stack Development\n18M OP\n\nChain & Infra\n25 - 50M OP\n\nGov Tooling & Community\n2M OP\n\nMarketing\n1M OP\n\nAirDrops & User Incentives\n5-10M OP\n\nTotal\n51 - 81M OP\n\nAdditional Allocations:\n\nGovernance Fund: To be proposed by Budget Board\nRetro Funding: To be proposed by Budget Board\n\nKey Principles:\n\nNo new tokens requested: Year 4 operates entirely within the original allocation framework, demonstrating fiscal discipline and sustainable growth.\nCommunity engagement: Mid-year update planned for December 2025, with Year 5 proposal by June 2026\nImpact Measurement: Building reporting infrastructure to measure grant effectiveness and refine allocation strategies based on demonstrated impact.\n\nThe Foundation remains committed to transparent, outcome-driven token deployment that scales Ethereum, empowers builders, and advances the Optimism Collective’s mission.\nAppendix (Accounting Notes)\n\nCirculating Supply: Defined as OP tokens in general circulation that have no known restrictions on transfer. This definition may be different than, or inconsistent with, the definitions used by other parties. The circulating supply can be accessed at https://static.optimism.io/tokenomics/circulatingSupply.txt\nTotal OP Committed: Defined as Circulating Supply + all OP tokens that have been granted subject to a lock-up + all OP tokens that have been conditionally committed based on vesting and completing milestones + tokens OP Labs holds other than the initial allocation of 36%.\nEcosystem Fund: The Ecosystem Fund is the culmination of the Partner, Seed and Unallocated funds, whose allocation of total supply is 19.6%. We have merged these buckets into one ‘Ecosystem’ fund, for ease of planning and reporting.\n\nPlease note that the Foundation budget comes from the initial 30% supply and is not subject to governance approval. If the Foundation ever wishes to request more tokens, that will require governance approval. In the meantime, updates are provided solely for transparency.\n\n Season 7 Impact Analyses and Season 8 Budgeting\n\n Optimism Gov Summary\n\n read \n\n 4\n min\n\n post by LauNaMu on Jun 24, 2025\n\n LauNaMu\n\n An initial quick takeaway:\nIt would be worth it to create a column only for the Ecosystem Fund in this document to understand how much of it has been allocated and what the unlock schedule looks like for it here: [PUBLIC] OP Token Unlock (Estimated) - Google Sheets\nOtherwise it is really confusing to understand how much of the funds are destined for Partnerships and Growth and their impact to the circulating amount.\nAlso, is it to be understand that by “merging them” all of the unallocated funds have turned into funds to be deployed in deals to attract new chains into the Superchain?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Collective Year 4 Budget Update and Year 5 Budget Outlook\n\n Foundation Budgets\n\n Summary\nYear 4 (May 2025 to April 2026) was a year of focus and fiscal discipline. The Collective committed roughly 150M OP of new commitments across Season 8 and Season 9, about one third less than the 229.92M OP commit…\n\n read more\n\n 2\n\n 441\n\n Aug 7\n\n Foundation Year 3 Budget Update\n\n Foundation Budgets\n\n Summary\nThe Optimism Foundation’s operating budget of OP, subject to governance approval by the Token House, maintains the original budget set into motion in both Year 1 and Year 2 proposals. \nFor this year’s operating b…\n\n read more\n\n 0\n\n 737\n\n Sep 2024\n\n Season 8 Intent\n\n Intents\n\n season-8\n\n Season 8 Intent\nThis post outlines the main strategic goal of the Collective for 2H25 (Season 8 Intent) and highlights the contributions the Collective will support towards that goal. The audience for this post is all co…\n\n read more\n\n 20\n\n 2.1k\n\n Aug 2025\n\n [Mission Request]: Intent #3B: Support the Superchain\n\n Governance Fund Missions\n\n season-6\n\n Intent 3 is subdivided into two portions: \n\nIntent 3A: OP Mainnet Mission Requests will be created by The Grants Council and approved by the Token House\nIntent 3B: One Superchain Grant Mission Request will be created by …\n\n read more\n\n 6\n\n 2.1k\n\n Feb 2025\n\n Governance Update #11\n\n Governance Updates\n\n Governance Update #11\nThe Collective has been hard at work and it’s already time for our midpoint update on the progress made towards our Decentralization Milestones! \n\nSeason 8\nIn Season 8, we’re focused on the below mi…\n\n read more\n\n 0\n\n 227\n\n Oct 2025","tokens":2952,"squid":"ink-governance","role":"Council Listener","at":1791259188279,"hash":"dcd9de901428753cea79aa2629b3899428456e5b"}
{"url":"https://www.pyth.network/","domain":"pyth.network","title":"The Price Layer for Global Finance | Pyth Network","text":"Better Market Data for Every MarketBetter Market Data forEvery HourA breakthrough in financial data that enables institutions, applications, and AI systems to access the widest array of market data at the lowest cost. Free TrialContact the TeamTrusted by institutions. Used by everyone.24/7Benchmark UST pricing, live on PythTRADEWEB · READ THE STORY+40 OTC instruments, priced on Pyth ProFENICS · READ THE STORYUS Treasury pricing, strengthened on Pyth ProOPENYIELD · READ THE STORYDozens of vendorsStale priceNo display rightsLimited asset classesRedistribution feeManual auditsPer-seat costIntegration debtLicence pending+138Data Publishers720+Data Consumers+3,600Live Price Feeds$5T+Transaction VolumeYour Market Data\nInfrastructure Is Unsustainable.One Source Of Truth\nAcross Every Asset Class.Through One API.24/7 coverage, full display\nrights, and zero licensing fees.\nFigures as of September 2026.Pyth Product suitePyth ProLow-latency market data for institutions, trading venues, applications, and AI systems. Access real-time prices across asset classes through modern APIs built for fast, automated workflows.Cross-asset data for crypto, equities, FX, and commodities.Flexible channels for real-time and fixed-rate delivery.Built for trading, risk, analytics, and AI applications.Explore Price FeedsPyth IndicesData MarketplacePyth TerminalContact the TeamSuccess StoriesBuilt with the teams defining the next market cycle.NasdaqNasdaq Basic Available via Pyth’s Data MarketplaceRead StoryHyperliquidHow Hyperliquid Became the World's 24/7 Macro Trading Venue with PythRead StoryTradewebHow Tradeweb Brings Benchmark Government Bond Pricing to the Pyth Data MarketplaceRead StoryCoinbaseHow Coinbase Derivatives Launches 24/7 Thematic Equity Futures with Pyth and MarketVectorRead StoryFenics Market Data How Fenics Market Data Extends Institutional OTC Pricing Through PythRead StoryEuronext FXHow Euronext FX Sets the Global Standard for Programmable Currency DataRead StorySGX FXHow SGX FX Anchors Global Liquidity with Institutional Benchmarks via PythRead StoryKalshiHow Kalshi Modernizes Commodity Resolution with Pyth ProRead StoryPolymarketHow Polymarket Builds Trust in Prediction Markets with Pyth ProRead StoryKrakenHow Kraken Brings 24/7 Oil Perpetuals to Kraken Pro with Pyth IndicesRead StoryShaping the next wave of finance Nic von RuppPyth Athlete Iceland, April 2026See more PythWord on The StreetWhat the market is saying about Pyth.By working with Pyth to provide our reliable market data to applications, Revolut can influence digital economies by ensuring developers and users have access to the precise, real-time information they need.Mazen ElJundiGlobal Business Head of CryptoBy providing our unique market data on-chain in real-time, we look forward to playing a role in the Pyth Network's growth.Ian McGuinnHead of Crypto Business DevelopmentCoinbase has been at the forefront of this evolution, and our growing share of the derivatives market is a direct reflection of that commitment. Tools like Pyth Indices help fill the critical infrastructure gaps that make this next era of markets possible.Boris IlyevskyHead of DerivativesExtending our thematic equity expertise into 24/5 infrastructure is not simply a technical upgrade — it is a rethinking of what 'round-the-clock' price discovery looks like. The partnership with Pyth gives us the data foundation to support reliable, near-continuous pricing, and Coinbase's perpetual futures platform is the ideal first proof of concept for what we believe will be a much broader market.Josh KaplanHead of Research & Investment StrategyAt Tradeweb, we are seeing growing demand for more timely and accessible ETF data. By publishing our iNAVs to the Pyth Network, we are exploring how onchain infrastructure can extend the reach of high-quality, intraday valuations to a broader set of market participants.Michael ZaladonisGlobal Head of Data Products and AnalyticsPublishing Euronext FX's data through Pyth marks an important step toward a unified, transparent, and programmable market data standard for modern finance.Nicholas JegouCEOBy contributing our global OTC pricing to the Pyth Network, we're supporting the creation of a more connected, efficient, and data-driven financial system that brings institutional-grade transparency to the digital asset frontier.Rich WinterGlobal Head of Market DataPyth's price feeds are both granular and easy to consume, complementing Kalshi's mission to make these markets accessible to a broader set of retail and institutional participants.John WangHead of CryptoPyth Indices give us a continuous benchmark for assets where the underlying market doesn't trade round the clock. That matters because Kraken is launching perpetual contracts on oil, and a perpetual needs a 24/7 reference price to function.John PalmerGlobal Head of Derivatives at KrakenMillions of dollars can hinge on a single price point, and that demands absolute confidence in the source of truth. Pyth delivers that assurance, enabling Polymarket to expand into high-stakes financial markets.Mustafa AljaderyProduct LeadWe are committed to upholding the highest standards of transparency and integrity through our SGX FX benchmarks. Contributing this critical pricing data to the Pyth Network is a deliberate step towards accelerating real-time, decentralized finance.Jean-Philippe MaleCEOWe're proud to be long-term supporters of Pyth, which has developed one of the most comprehensive and valuable sources of market data ever created. Pyth Pro makes that data accessible to more consumers, including traditional financial firms, and brings competition to the market data economy by providing the purest form of data directly from the source.By integrating Pyth Pro, we are pairing our global scale with local precision, ensuring our platform delivers region-specific solutions that meet the distinct needs of global markets. This partnership provides the high-fidelity data foundation required to support the depth and liquidity institutions demand.Marc ZeitouniCEO Coinbase International ExchangeWe believe DeFi has the potential to play an important role in defining the future of our financial markets, and we are excited to help support its growth through innovative initiatives like the Pyth Network.Catherine ClayExecutive Vice President, Data and Access SolutionsWe're proud to work with Pyth to put real-time Treasury, corporate, and municipal data in front of a global base of applications and institutions.Jonathan BirnbaumFounder & CEOAn integration with Pyth is the natural step forward for us and it is very much in line with both our strategy and values. Our mission is to advance the decentralized world by empowering more transparent, fair, and efficient markets and products. Evgeny GaevoyCEOFlow Traders is hugely supportive of initiatives such as those being advanced by Pyth which not only will improve the accuracy and quality of market data but also seek to democratize this data among multiple actively contributing market participants.Dennis DijkstraCEOCorporate actions data is foundational to market integrity. By making our datasets available through Pyth Network, we’re helping ensure that onchain financial markets can rely on the same authoritative corporate actions data used across traditional finance.Jonathan BlochCEOTerminalIntroducing Pyth TerminalPyth Terminal is the front door to Pyth's market data. It gives teams a self-serve way to explore price feeds, compare plans, manage API keys, and access real-time market data across asset classes.Free TrialThe Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":2082,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259191287,"hash":"9f33e6e11d7737651ddb50525eab096ad32ea2e4"}
{"url":"https://gov.optimism.io/t/season-8-intent/10009","domain":"gov.optimism.io","title":"Season 8 Intent - Governance Design and Strategy 📐 / Intents - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 8 Intent \n\n Governance Design and Strategy 📐Intents\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 1 / 23\n\n Jun 2025\n\n Aug 2025\n\n post by system on Jun 12, 2025\n\n system\n\n Season 8 Intent\nThis post outlines the main strategic goal of the Collective for 2H25 (Season 8 Intent) and highlights the contributions the Collective will support towards that goal. The audience for this post is all contributors towards the Collective.\nIf you’re a builder and want to understand how to Get a Grant - skip to here.\nDon’t want to read? Join the Joint House Community Call on June 17th or leave questions the an the Season 8 Intent AMA by June 22nd at 19:00 GMT here.\nYou can find all AMAs and other dates on the public governance calendar.\n\nSeason 8 Intent\nThe Foundation recently outlined our two year vision for the Superchain. Executing on this vision will require collaboration among all of the Collective’s contributors. The Collective uses Intents to guide these contributions so that OP Labs, the Foundation, OP Chains, the Token House, the Citizens House, and the many builders helping to make the Superchain a reality are all working towards the same goals.\nWhat are Intents?\nIntents are high level strategic goals the entire Collective works towards. All contributions in the Collective should be working towards the Intents.\nIn Season 8, we will have one Intent, focused on a core pillar of our Superchain Product Vision: Interoperability. This is consistent with our Season 7 Intent, as the Collective remains focused on delivering protocol-native interop and preparing the ecosystem for successful adoption.\nWhile the Intent remains the same, it has been adjusted to 100m per month based on benchmarks across the Superchain and the latest staged rollout plan.\nFor more information about Interoperability and the Collective’s overall strategy, see this.\nScreenshot 2025-06-12 at 16.22.071056×370 6.51 KB\nCross-chain asset transfers will be defined as the movement of an asset between two chains that relies on underlying Superchain interop messaging – which delivers consistent security assumptions and 1-block latency UX.\nCollective programs will aim to grow a set of supporting metrics (described in the Governance Fund Missions section below) to prepare the Superchain for successful adoption of Interop.\nNote: While the Season 8 Intent focuses the Collective on making progress towards the Superchain Product Vision, our commitment to decentralization has not changed. The goal is not to have the Foundation and OP Labs accomplish these Intents by ourselves but rather to build a governance system capable of accomplishing these goals without us in the future.\n\nObjectives\nThere are three main objectives that will allow us to achieve this intent:\n\nShip Interop\nGrow TVL on the Superchain\nDrive Developer Adoption of Interop\n\nScreenshot 2025-06-12 at 16.24.151056×532 8.08 KB\nAll roadmaps and Missions will work towards one of these objectives.\nRoadmaps outline the work to be completed by OP Labs and the Optimism Foundation, supported by the Foundation Budget.\n\n*Note: These are estimated budget amounts. The Foundation may spend more or less than these estimates to execute on these roadmaps. To reference actual spend, the Foundation publishes budget reports twice per year on the forum here. The Foundation currently operates with the budget allocated to the Foundation in the initial token supply. If the Foundation needs more tokens to continue operating in the future, additional token budget will be subject to governance approval.\n\nMissions outline the work to be completed by Collective contributors. Missions are specific initiatives aimed at making measurable progress towards each objective. They are clearly scoped, and can be executed by Collective contributors start-to-finish in less than 12 months. Missions may be supported by the Foundation, Retro Funding, or the Governance Fund.\nScreenshot 2025-06-12 at 16.23.071056×532 12.1 KB\nAll incentive programs and the chain delegation program for Season 8 will be available to chains on a fully-standard, governance-approved release of the OP Stack and have opted into the Security Council (or are on track to). This corresponds to the green + yellow chains (see Superchain Index.)\n\n1. Ship Interop\nThe core development program, led by OP Labs, and the Foundation will work towards this objective via the 6 month roadmap outlined below:\n\nDevelopment Projects\nBudget\n\nProtocol-level Message Passing\n5M OP\n\nEnable Interop token bridging\n3M OP\n\nScale the interoperable set to 4 chains\n2M OP\n\nSub-second, sub-cent block optimization\n2M OP\n\nOnchain revshare & buy-burn\n1M OP\n\nShip Kona to production\n1M OP\n\nCore development grants\n2M OP\n\nGrowth Projects\n\nEcosystem Partnerships to support Interoperability\n5M - 10M OP\n\nWe estimate up to 26M OP from the Foundation Budget will be required to execute this roadmap.\n\nMission: OP Stack Dependencies (Retro Funding)\nThis Mission will reward critical software dependencies that underpin the OP Stack — with an initial emphasis on Ethereum Core Development.\nStrategic Rationale\n\nReinforces Ethereum Alignment: Supporting Ethereum Core Development reinforces Optimism’s positioning as the most Ethereum-aligned L2. This alignment has historically influenced developer preference: many contributors chose Optimism precisely because of this demonstrated alignment. In a climate where some perceive L2s as “extractive to Ethereum”, continued funding of L1 R&D signals that Optimism is additive — a steward of Ethereum’s long-term health.\nStrengthens the Superchain: Ethereum serves as the data availability and security layer of the Superchain. Previous investments in L1 R&D — such as EIP-4844 in Retro Funding 2 — have improved downstream scalability and cost-efficiency. Moreover, OP Stack implementations (e.g. OP-Geth) rely directly on Ethereum clients and standards. Failing to support this upstream infrastructure would constitute a market failure: the Superchain would be consuming Ethereum resources but contributing minimally to the development of its underlying infrastructure.\n\nThe Budget Board will propose a budget for each Retro Funding Mission, subject to Optimistic approval in the Citizens’ House.\n\nSuccess Metric\n\n$100m / Month in Cross-chain Asset Transfers\n\n2. Grow TVL on the Superchain\nThe Foundation will work towards this objective via the 6 month roadmap outlined below:\n\nGrowth Projects\nBudget\n\nGrowth Campaigns (e.g. Superstacks v2.0)\n5M -10M OP\n\nMarketing\n1M OP\n\nWe estimate up to 11M OP from the Foundation Budget.\n\nGovernance Fund Mission: Grants Council\n\nGrants Council: The Grants Council make proactive grants on behalf of the Token House to make progress towards this objective’s success metrics. Grant policies apply.\n\nGovernance Fund Mission: Futarchy\n\nFutarchy: Building upon an initial experiment in Season 7, the Foundation would like to run additional experiments to test futarchy as an alternative method for making predictions in Optimism governance.\n\nBudgets proposed by Budget Board, subject to Optimistic approval in the Token House.\n\nSuccess Metrics\n\n Interop-ready TVL\n\nPrimary: X TVL/AOP that is interop ready within the Interop set\nSecondary: % share of TVL / AOP within the Interop Set that’s interop ready v.s. Total TVL / AOP\nWhy this metric?: Interop introduces new development and interaction patterns for application developers. Growing the volume and share of interop-compatible assets onchain increases the chance that interop is widely adopted by application developers and users alike.\n\n Interop Transaction Fees\n\nPrimary: X ETH / Month transaction fees generated from transactions that interact with the L2ToL2CrossDomainMessenger contract\nSecondary: % share of interop transaction fees v.s. non-interop\nWhy this metric?: The total fees spent on interoperable transactions maps to usage of the feature after launch, and is a good indicator of the net growth caused by introducing the feature to the Superchain. This metric may not be measurable until full interop launches in late Q4.\n\n3. Drive Developer Adoption of Interop\nThe core development program, led by OP Labs, and the Foundation will work towards this objective via the 6 month roadmap outlined below:\n\nProjects\nBudget\n\nInterop Developer Tooling\n2M OP\n\nGrow the set of Stage 1 Chains on the Superchain\n20M - 40M OP\n\nWe estimate up to 42M OP from the Foundation Budget.\n\nGovernance Fund Mission: Developer Advisory Board\nThe Developer Advisory Board will make proactive technical grants on behalf of the Token House to make progress towards this objectives success metrics. These make take the form of audit grants or Mission Requests (as in previous seasons.) Grant policies apply.\n\nThe Budget Board will propose a budget for each Governance Fund Mission, subject to Optimistic approval in the Token House.\n\nRetro Funding Mission: Onchain Builders\nThis Mission will reward application developers for their contributions to Superchain growth and interop adoption.\nStrategic Rationale\n\nDrives Superchain Usage and Growth: Onchain applications are the primary driver of transactions, gas fees, and user activity. Retro Funding rewards the builders behind these apps, aligning economic incentives with the Superchain’s long-term success.\nAccelerates Interop Adoption: By recognizing builders who integrate interop functionality, Retro Funding provides targeted incentives for widespread interop adoption.\nBuilds long term alignment: Instead of relying on short-term grants, Retro Funding offers builders a durable stream of rewards tied to real usage.\n\nRetro Funding Mission: Dev Tooling\nThis Mission will reward toolchain software, such as compilers, libraries and debuggers, that support builders in developing onchain applications on the Superchain.\nStrategic Rationale\n\nEnables Developer-Led Growth: OS Dev Tooling is the foundation of the Superchain’s developer experience. Retro Funding ensures open source tools like libraries and debuggers remain well-maintained and composable.\nCorrects a Clear Market Failure: These tools are essential to the ecosystem but lack clear business models. Retro Funding solves this by rewarding impact retroactively, allowing builders to focus on utility.\nStrengthens the Platform: Supporting OSS complements prevents vendor lock-in by closed source alternatives, compounds innovation, and reduces reliance on top-down grants—making the Superchain more open, resilient, and scalable.\n\nThe Budget Board will propose a budget for each Retro Funding Mission, subject to Optimistic approval in the Citizens’ House.\n\nSuccess Metric\n\n Verified Developer Interop Adoption\n\nPrimary: [X ] Atlas deployers with contracts interacting with interop L2ToL2CrossDomainMessenger per month\nWhy this metric?: We believe it’s an early indicator of developer adoption and verified developers set a quality bar. \n\nWhat does this mean for Delegates?\n\nJoin the Community Call on July 17th\nJoin Season 8 Intent AMA on June 24th\nIn Special Voting Cycle #39a:\n\nVote to ratify the Intent\n\nIn Special Voting Cycle #39b:\n\nOptimistically approve 3 Governance Fund Missions\n\nWhat does this mean for Citizens?\n\nJoin the Community Call on July 17th\nJoin Season 8 Intent AMA on June 24th\nIn Special Voting Cycle #39a:\n\nVote to ratify the Intent\n\nIn Special Voting Cycle #39b:\n\nOptimistically approve 3 Retro Funding Missions\n\nSee the Reflection Period Guide for full steps.\n\nSummary of Spend by Objective\n\nObjective\nProject\nBudget\nFund\nGovernance Approval\n\nShip Interop\nProduct & Engineering (OP Labs)\n16M OP\nFoundation\nNone\n\nGrowth (Foundation & OP Labs)\n5M - 10M OP\nFoundation\nNone\n\nRetro Funding Mission: OP Stack Dependencies\nTBD\nRetro PGF\nCitizens’ House\n\nTotal TBD\n\nGrow Superchain TVL\nGrowth (Foundation & OP Labs)\n6M - 11M OP\nFoundation\nNone\n\nGovernance Fund Mission: Futarchy\nTBD\nGovernance Fund\nToken House\n\nGovernance Fund Mission: Grants Council\nTBD\nGovernance Fund\nToken House\n\nTotal TBD\n\nDrive Developer Adoption\nProduct & Engineering (OP Labs)\n2M OP\nFoundation\nNone\n\nGrowth (Foundation & OP Labs)\n20M - 40M OP\nFoundation\nNone\n\nRetro Funding Mission: Dev Tooling\nTBD\nRetro PGF\nCitizens’ House\n\nRetro Funding Mission: Onchain Builders\nTBD\nRetro PGF\nCitizens’ House\n\nGovernance Fund Mission: Dev Advisory Board\nTBD\nGovernance Fund\nToken House\n\nTotal TBD\n\n Guide to Season 8\n\n Season 8 Council and Board Mandate Guidance\n\n Special Voting Cycle Roundup#39a\n\n Collective Year 3 Budget Update and Year 4 Budget Outlook\n\n SEEDGov - Delegate Communication Thread\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 11\n min\n\n Unlisted on Jun 12, 2025\n\n Listed on Jun 12, 2025\n\n post by Gonna.eth on Jun 12, 2025\n\n Gonna.eth\n\n I’ll leave my feedback on the Season 8 documents here to avoid spamming multiple threads.\nAll relevant Councils and Boards from Season 7 were required to publish a retrospective by June 12th. This gives the Collective visibility into what worked, what didn’t, and the overall progress that is essential context for the next round of approvals.\nHowever, I’m not seeing any reports related to the initiatives outlined in the Season 7 Intent by The Foundation. I assume the Foundation isn’t required to report on how it spends the budgets it proposes for The Foundation treasury but the more opaque things get, the more it feels like we’re drifting toward an ivory tower dynamic.\nTo illustrate: roughly 60M OP are expected to be allocated from the Foundation Fund to ship interop, grow TVL, and drive dev adoption for Season 8. But I can’t find any public updates for the following Season 7 budgets:\n\nDevelopment Projects\nBudget\n\nDeliver the MVP for interop (at least two OP Chains and audited)\n4M OP\n\nUpgrades to reach Stage 1\n1.5M OP\n\nInfra/processes to scale Superchain upgrades\n1.5M OP\n\nAlternate Rust stack & Stage 2 progress\n1.5M OP\n\nERC7802 adoption + interoperable ETH\n1M OP\n\nDecision Market Mission (Futarchy)\n1M OP\n\nRetro Funding\n16M OP\n\nSuperstacks\n2M OP\n\nThese were real budgets with big expectations. Yet I see no reports, no outcomes, and no lessons learned. Meanwhile, the Collective is now being asked to optimistically approve (meaning if someoen is not paying attention it passes) the Futarchy mission again, and it’s unclear whether Citizens have any say in the future of Retro Funding.\nAs someone analizing a proposal for the Grants Council S8, with a clear vision and the expectation to be held accountable six months from now, I’d really like to know if that same mentality exists across the board.\nUnchecked use of funds, OP tokens in this case, inevitably breeds complacency, especially when there’s no public accountability. If I had failed in any of the five seasons I’ve served, Token House wouldn’t give me a second chance to get elected. Meanwhile, Retro Funding is on its seventh iteration with no indication of being sucesfull during S7, and Interop MVP was promised back in November 2024 with no clear delivery or post-mortem.\n\n post by system on Jun 13, 2025\n\n system\n\n Clarifications are provided below\n\nI assume the Foundation isn’t required to report on how it spends the budgets it proposes for The Foundation treasury\n\nThe Foundation was allocated 30% of the initial token supply. The Foundation posts regular budget updates outlining how those tokens are used. The next update is being prepared and will be posted shortly. This report was not published alongside the Season 8 materials, as the Foundation is not currently requesting more tokens.\n\nThe Collective is now being asked to optimistically approve (meaning if someone is not paying attention it passes) the Futarchy mission again\n\nButter’s analysis of the futarchy experiment should be available later today\nThe Foundation analysis of the futarchy experiment is expected to be available by June 26th\nThe Foundation’s analysis of the Grants Council in Season 7 is expected to be published by June 19th\n\nIt takes some time to do rigorous analysis (the Season ended less than 48 hours ago) but this information is expected to be available to the community before votes on any of the Missions occur. Given the need to understand longer term impacts, like retention, the reality is that we will not fully understand the efficacy of different programs immediately after they conclude. We will post links to all the analyses mentioned above in the Missions as they become available.\nAll token allocations (Mission budgets), including the Grants Council Mission, will be optimistically approved in Season 8. This is for a few key reasons:\n\nThe experiments we ran in Season 7 indicated that most participants, even non-experts, tended to align with budgets proposed by an “expert group.” (See Season 7 Guest Voter Selection Experiment Outcomes)\nThe Budget Board has the relevant expertise to make informed and comprehensive proposals about budgets. Governance participants still have the ability to veto these proposals if they disagree.\nOptimistic approvals allow the decisions to be outsourced to high context decision makers while ensuring they remain accountable to governance participants that retain a veto. Insufficient monitoring is a known failure mode of optimistic systems, which we will prevent with email notifications, etc.\n\nIt’s unclear whether Citizens have any say in the future of Retro Funding\n\nCitizens will have a say in whether or not Retro Funding receives token allocations, meaning Retro Funding is ultimately accountable to the Citizens’ House. Citizens will not be involved in the day-to-day decision making involved in running the Retro Funding program, as that increases platform risk and is, therefore, outside the governance surface area.\n\nAs someone analizing a proposal for the Grants Council S8, with a clear vision and the expectation to be held accountable six months from now, I’d really like to know if that same mentality exists across the board.\n\nYes. The Foundation is bootstrapping the infrastructure required for all token allocations to be compared in as standardized a manner as possible. You can see that in standardized success metrics, public analyses, and increased transparency around the Foundation’s roadmaps and budgets.\nIn the future, the Foundation may need to request more tokens from governance, in which case the Foundation will go through the same process as anyone else requesting tokens.\n\nThere’s no public accountability. If I had failed in any of the five seasons I’ve served, Token House wouldn’t give me a second chance to get elected.\n\nThe Foundation is similarly accountable to the Token House, as outlined in the Operating Manual.\n\nRetro Funding is on its seventh iteration with no indication of being sucessfull during S7\n\nOSO is expected to share this analysis by June 20th. They have shared many such analyses for previous seasons (for example.) As stated above, all such analysis are expected to be available before Missions are voted on in Voting Cycle #39b.\n\n post by neuronbrew on Jun 13, 2025\n\n neuronbrew\n\nhey @Gonna.eth is there some place I can see a data report for how the past 50-100m OP of Grants Council spend has helped grow the ecosystem? I’m talking TVL per contract, not just stuff like NPS.\nI don’t see any dashboard or ROI report linked in the S6 retro or S7 retro.\nI agree w/ your points that we need to be good at following up on how tokens were spent, but tbh it doesn’t seem like the Grants Council is very good at this either…\n\n post by Gonna.eth on Jun 13, 2025\n\n Gonna.eth\n\n Absolutely, you can track each contract using this Google Sheet.\n\nColumn C lists the OP distribution contracts.\nColumn D lists the TVL contracts we’re monitoring.\n\nUnfortunately, when both the Milestone & Metrics and Grants Council budgets were created back in December, neither included a proper dashboard for tracking TVL growth, with the assumption that this was going to be done more broadly by The Foundation’s analytics team. We didn’t even had the interoperable TVL definition by Dec 4th when my budget was posted. Not to mention is becoming increasingly hard to ask independent teams to do work for 1 year locked OP under these market conditions. That said, Superchain Eco has offered to build a Dune dashboard using this data, and we’re currently waiting on that.\nIn the meantime, the TVL data we’re reporting is based on what grantees share with us directly via Telegram. I ping all of them monthly for updates, and those numbers are reflected on the second tab of the same sheet. Just keep in mind that it’s a static snapshot; that’s why each report includes a specific date.\nThis is a quote from the retrospective published on June 9th.\n“Grantees have reported (On June 7th) using 356,000 OP so far, resulting in a combined $480M in direct TVL. While a large portion of this comes from Spark ($400M), removing that still leaves $80M in TVL driven by early-stage OP incentives, which is highly encouraging. That said, we invite caution when interpreting these numbers.”\nIf you want to make an easy confirmation of the 400M reported above, you can check these contracts from Spark:\nOP Mainnet:\n0xe0F9978b907853F354d79188A3dEfbD41978af62\n0x876664f0c9Ff24D1aa355Ce9f1680AE1A5bf36fB\nUnichain:\n0x345E368fcCd62266B3f5F37C9a131FD1c39f5869\n0x7b42ed932f26509465f7ce3faf76ffce1275312f\n\n post by SuperchainEco on Jun 13, 2025\n\n SuperchainEco\n\n Related to the above, we’ve already (and without any reward/pay in exchange) produced a Season 7 Grant Tracking dashboard and are adding additional metrics in the coming days.\nView the Dune Dashboard here\n\n post by Chain_L on Jun 14, 2025\n\n Chain_L\n\n @Gonna.eth\nThese metrics are important for making informed decisions, especially when budgeting for the next season.\nNumbaNERDs will be happy to assist in any way possible to expedite the cleaning and collection of accurate data.\nWhile the market conditions of locked OP for 1 year deter many from working, I would like to mention that many numbaNERDs contributors are providing their time and intellect working on various tasks. We should provide more, and the communication channels should be better to ensure we utilise their strengths for such activities, which are crucial for governance.\nSimple questions that arise from the current analytics, like, “Was the TVL increase in Spark an outcome to be associated solely with OP grant?” This can be backed by data and completed as a task by numbaNERDs. And the answer will also help reviewers in the next season.\n\n post by thbialek on Jun 16, 2025\n\n thbialek\n\n Gonna.eth\n\nUnfortunately, when both the Milestone & Metrics and Grants Council budgets were created back in December, neither included a proper dashboard for tracking TVL growth, with the assumption that this was going to be done more broadly by The Foundation’s analytics team.\n\nAs evidenced by past analyses (see S6 growth grant analysis), the Foundation remains committed to supporting the Grants Council with the measurement capabilities necessary to make more informed token allocation decisions in future seasons. As part of this ongoing commitment, the Foundation is working closely with OpenSource Observer to assess the impact of the Grants Council’s grants in S7, and we expect to publish the results later this week.\nAs mentioned before, I’d caution against attributing all of the TVL growth to a single intervention, especially given that multiple interventions are being implemented concurrently. To more accurately estimate causality and isolate the treatment effect, quasi-experimental methods, such as synthetic controls or regression discontinuity design, are required.\nDisclaimer: I work for the Optimism Foundation, but views are my own.\n\n post by GFXlabs on Jun 16, 2025\n\n GFXlabs\n\nHe’s mostly referring to the Spark integration, where the applicant was sourced directly by Grants Council members and the deployment, its timeline, or both were a direct result of the grant negotiations.\n\n post by Pr0 on Jun 17, 2025\n\n Pr0\n\n Gonna.eth\n\n OP atm is just being used to funnel funds inside a black box to profit connected parties. TVL is a shit base for value since not only does it do fuckall for users (AMMs are shit for swaps that most users use, where CoW are better) but they also are used to boost only the projects who often have their own tokens already, with no real growth in any real value. EF used to fund new ideas and so we got ENS, Uniswap, and we used to do the same, but then we went to TVL user only rewards or 1y locks. Interesting that this benefits the same projects who have already got market dom, that have their own tokens to fund it, that are TVL based and have connections. OP is what funds this whole community, its what funds grants, its what funds you yet noone wants to talk about how its just a moneygrab now for the foundation and the large projects grabbing grants.\nSimple to fix\n\nDrop garbage that doesnt actually create growth (TVLs just same funds moving around), base it on OPs price (since thats whats funding it all, more value>more grants>more growth)\nNew use cases, we dont need another 100 forks.\nBuyback OP with fees from other networks since we already get ETH cut from them. Have grant projects do buyback to send back or allocate their tokens to the treasury. This will let use keep funding shit.\n\nIntents are great but have yet to see anyone say why we are using what we are. Interop isn’t going to cost $5m to pull off yet that, even at current market rates is the cost for infra we already pretty much have?\n\n post by Pr0 on Jun 17, 2025\n\n Pr0\n\n Gonna.eth\n\n “Grantees have reported (On June 7th) using 356,000 OP so far, resulting in a combined $480M in direct TVL. While a large portion of this comes from Spark ($400M), removing that still leaves $80M in TVL driven by early-stage OP incentives, which is highly encouraging. That said, we invite caution when interpreting these numbers.”\nimage1920×1080 313 KB\n\n post by Gonna.eth on Jun 17, 2025\n\n Gonna.eth\n\nI agree with this approach for projects like Kaito and Sake Finance, which have no direct incentive contracts and measure their entire TVL. However, most of these projects where TVL does not have a direct correlation with the grant are not part of the Superstacks and have no other “multiple interventions.”\nThe contracts listed on this Google Sheet are specifically reported by grantees as the ones where the OP distributed by the Grants Council alone is being used.\n\n post by Gonna.eth on Jun 17, 2025\n\n Gonna.eth\n\nI do not decide the Grants Council’s objective; my job is to execute what the collective votes. I provided my feedback back in December 2024 when I suggested we use ETH instead of USD for TVL.\nWe measure TVL on the chain, the grantees proposed the incentives, Spark moved 200M to OP Mainnet and 200M to Unichain. I do not understand the meaning of DeFi Llama picture. Let’s try to keep the conversation constructive.\nPlease, let’s also move this conversation here and provide INTENT 8 feedback on this post if you don’t mind.\n\n post by Pr0 on Jun 17, 2025\n\n Pr0\n\n This wasn’t at you, it was at the foundation, fully agree with you which was why replyd. It shows the TVL has dropped by about .5x.\n\n post by GFXlabs on Jun 19, 2025\n\n GFXlabs\n\n The Operating Manual](OPerating-manual/manual.md at main · ethereum-optimism/OPerating-manual · GitHub) indicates that the Foundation needs approval to spend any OP.\nFor the avoidance of all doubt, is passage of this Intent considered an approval of the Foundation budget numbers in this post?\n\n post by lavande on Jun 20, 2025\n\n lavande\n\n The Foundation needs approval to spend any OP beyond the initial 30% of the token supply. If the Foundation needs to request more tokens, beyond the initial 30%, that will require a governance proposal. The Operating Manual has been updated to remove mention of “Year 1” and “Year 2” as the Foundation has taken longer than initially anticipate to distribute the initial 30% supply.\nApproval of this Intent is not considered an approval of the Foundation budget numbers in this post. Those are provided merely for transparency.\n\n 8 days later\n\n post by cp0x on Jun 28, 2025\n\n cp0x\n\n Do I understand correctly that it is proposed to spend about 70-80 million OP (which is about 35-40 million dollars) on various grants and get only 100 million TVL of Superchain from this?\nDoesn’t it seem that such expenses should lead to a significantly higher TVL, even if it is considered a correct evaluation parameter.\n\n post by GFXlabs on Jun 28, 2025\n\n GFXlabs\n\nIt’s to target $100m cross-chain volume per month in natively interoperable assets.\nNote that last season had a similar goal ($250m volume per month) but interop did not ship last Season so secondary metrics were targeted in the meantime, like increasing TVL.\nIt’s also important to note that bulk of the spend is from the Foundation’s initial OP allocation, and generally not subject to governance approval unless they’re asking for more.\n\n Load more posts below","tokens":7245,"squid":"ink-governance","role":"Council Listener","at":1791259198848,"hash":"8e702d69add159dcd360e92faf55035062ec40b8"}
{"url":"https://gov.optimism.io/t/season-8-intent/10009/24","domain":"gov.optimism.io","title":"Season 8 Intent - Governance Design and Strategy 📐 / Intents - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n 3\n\n 3\n\n read \n\n 11\n min\n\n Jun 2025\n\n 23 / 23\n\n Aug 2025\n\n Aug 2025\n\n Load more posts above\n\n post by Gonna.eth on Jun 12, 2025\n\n post by system on Jun 13, 2025\n\n post by neuronbrew on Jun 13, 2025\n\n post by Gonna.eth on Jun 13, 2025\n\n post by SuperchainEco on Jun 13, 2025\n\n post by Chain_L on Jun 14, 2025\n\n post by thbialek on Jun 16, 2025\n\n post by GFXlabs on Jun 16, 2025\n\n post by Pr0 on Jun 17, 2025\n\n post by Pr0 on Jun 17, 2025\n\n post by Gonna.eth on Jun 17, 2025\n\n post by Gonna.eth on Jun 17, 2025\n\n post by Pr0 on Jun 17, 2025\n\n post by GFXlabs on Jun 19, 2025\n\n post by lavande on Jun 20, 2025\n\n 8 days later\n\n post by cp0x on Jun 28, 2025\n\n post by GFXlabs on Jun 28, 2025\n\n GFXlabs\n\nIt’s to target $100m cross-chain volume per month in natively interoperable assets.\nNote that last season had a similar goal ($250m volume per month) but interop did not ship last Season so secondary metrics were targeted in the meantime, like increasing TVL.\nIt’s also important to note that bulk of the spend is from the Foundation’s initial OP allocation, and generally not subject to governance approval unless they’re asking for more.\n\n post by Manugotsuka on Jul 2, 2025\n\n Manugotsuka\n\n The following reflects the views of L2BEAT’s governance team, composed of @kaereste, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.\nWe voted FOR.\nA single, measurable goal—achieving real interoperability usage—gives every team a clear path and lets us judge success without guesswork. The plan ties funding, grants, and retro rewards to that outcome, which keeps incentives pointed in the right direction. We still need to be aware of execution risk (shipping the upgrade on time and staying within the OP spend range), but the direction is sound and worth backing.\n\n 15 days later\n\n post by Jrocki on Jul 17, 2025\n\n Jrocki\n\n govNERD\n\n @system Could please elaborate on this development project list item?\n\n 25 days later\n\n post by system on Aug 12, 2025\n\n system\n\n To widen the aperture and better align with the updated interop development timelines, the Foundation has decided to slightly adjust the success metrics for the second objective (”Grow TVL on the Superchain”). The two existing success metrics will remain but without the interop-specific focus. Instead of only prioritizing interop-ready TVL and interop transaction fees, progress towards this objective will now be evaluated based on generic TVL and total transaction fees. This shift aims to create optimal ecosystem conditions that will help interop thrive once it goes live. The proposed impact measurement methodology for S8 is detailed in this post. You can track timelines for upgrades 17 and 18 on the public roadmap.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n S8 Governance Fund Missions\n\n Governance Fund Missions\n\n season-8\n\n Grants Council Mission\n\nExpected impact on the Intent: \nThe Grants Council makes grants, on behalf of the Token House, in an effort to make progress towards the Intent. In Season 8, the Grants Council will work towards …\n\n read more\n\n 11\n\n 1.2k\n\n Sep 2025\n\n Season 7: Governance Fund Missions\n\n Governance Fund Missions\n\n season-7\n\n Special thanks to members of the Feedback Commission for discussion and review. \n\nIn Season 7, Governance Fund Missions will focus on contributions, across the Superchain, that make progress towards success metrics. That…\n\n read more\n\n 6\n\n 2.1k\n\n Jan 2025\n\n Season 7: Intent\n\n Intents\n\n season-7\n\n Special thanks to members of the Feedback Commission for discussion and review. \n\nThis post outlines the main strategic goal of the Collective for 1H25 (Season 7 Intent) and highlights the contributions the Collective wi…\n\n read more\n\n 7\n\n 5.2k\n\n Dec 2024\n\n Grants Council Season 7 Retrospective Report\n\n Grants Updates\n\n 1. What is your assessment of the impact KPIs that were set in your Budget Proposal at the start of the Season? Have you made progress towards, or achieved, these milestones or KPIs? If not, why?\nWe met 100% of the inter…\n\n read more\n\n 10\n\n 608\n\n Jun 2025\n\n Joint House Community Calls Summaries - Season 7\n\n Community Calls\n\n season-7\n\n As part of the GovNERDs’ responsibilities, we will be hosting the Token House / Joint House Community Call (occurring on Tuesdays, every other week, at 19:00 UTC, alternating). \n → Here is the link to the OP public gover…\n\n read more\n\n 11\n\n 602\n\n Aug 2025","tokens":1132,"squid":"ink-governance","role":"Council Listener","at":1791259209266,"hash":"70d108767549bf4ce4924dfb80c901838c74ea15"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-32-1","domain":"anchor-lang.com","title":"0.32.1","text":"Anchor Project UpdatesRelease Notes0.32.1Anchor - Release Notes 0.32.10.32.1 is a patch to fix a couple issues that showed up in 0.32.0, most\nnotably a race condition when deploying programs. We cover the most important\nchanges below, but be sure to check out the full list of changes in the\nCHANGELOG.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.32.1\n\nUpdate Anchor crate(s) to 0.32.1.\n\nUpdate TS package(s) to 0.32.1.\n\nRecommended Solana Version\nThe recommended Solana version is 2.3.0.\nYou can install the newer tooling by running:\nsh -c \"$(curl -sSfL https://release.anza.xyz/v2.3.0/install)\"\nCLI\nFix anchor deploy race condition\nWith the addition of deploying the IDL on every program deploy by default, a\nrace condition was introduced that was not found in initial testing. We have\nadded a wait until the program is completely available before continuing the\ndeployment of the IDL.\nlang\nFix warnings and prelude solana-program inclusion\nThere was still a warning leftover for deprecation of realloc in 0.32.0. This\nhas been remediated in this release.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.32.2Next0.32.0On this pageHow to upgradeRecommended Solana VersionCLIFix anchor deploy race conditionlangFix warnings and prelude solana-program inclusionEdit on GitHub","tokens":324,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259215702,"hash":"99115fa91c71521e3b6862e18a2b0e0aedfb24ae"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-32-0","domain":"anchor-lang.com","title":"0.32.0","text":"Anchor Project UpdatesRelease Notes0.32.0Anchor - Release Notes 0.32.00.32.0 is the current last planned upgrade before a number of breaking changes\nto stabilize Anchor 1.0. We cover the most important changes below, but be\nsure to check out the full list of changes in the\nCHANGELOG.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.32.0\n\nUpdate Anchor crate(s) to 0.32.0.\n\nUpdate TS package(s) to 0.32.0.\n\nRecommended Solana Version\nThe recommended Solana version is 2.3.0.\nYou can install the newer tooling by running:\nsh -c \"$(curl -sSfL https://release.anza.xyz/v2.3.0/install)\"\nCLI\nanchor verify now uses solana-verify to verify builds\nAnchor versions before 0.32.0 used a docker image solanafoundation/anchor to\ncreate verifiable builds. This version replaces the verifiable builds with\nsolana-verify\nunder the hood.\nIn order to create verifiable builds with this you still use anchor verify.\nIf someone tries to verify a build older than 0.32.0 with the newest CLI, the\nexpectation is that the verification will fail given the change in how builds\nare verified.\nIDL is automatically uploaded by default on deployment\nIn 0.32.0, the IDL is now uploaded whenever you use anchor deploy by\ndefault. If you still wish to deploy an anchor program without uploading the new\nIDL, use anchor deploy --no-idl.\nAdd MSRV to the Rust template\nRust 1.89.0 or higher is now required to build Anchor IDLs as previous\nversions of Rust do not have the stabilized\nSpan::local_file.\nYou can update your local Rust compiler by running:\nrustup update\nand confirm your local version of Rust with:\nrustc --version\nNote: This is different that the forked rustc version that the solana\ntoolsuite uses for compiling Solana programs.\nIDL\nIDL building is now stabilized.\nWIth the stabilization of\nSpan::local_file,\nwe can now build IDLs using the current Rust compiler instead of nightly. This\nshould avoid issues in the future such as the nightly build failing on 0.31.0\nand lower with the following issue:\nno method named source_file found for struct proc_macro2::Span in the current \nscope\nLang\nImproved error messaging when trying to create SystemAccount\nWhen you tried to init a SystemAccount, you previously got a rather\nunhelpful error:\nerror[E0425]: cannot find crate `try_from_unchecked` in the list of imported crates\nerror[E0425]: cannot find crate `try_from` in the list of imported crates\nNow the new error is a bit more helpful on pointing you in the right direction\nat compile time:\n\"Cannot use `init` on a `SystemAccount`. \nThe `SystemAccount` type represents an already-existing account \nowned by the system program and cannot be initialized. \nIf you need to create a new account, use a more specific account type \nor `UncheckedAccount` and perform manual initialization instead.\"\nUse solana-invoke instead of solana_cpi::invoke for CPI\nsolana_cpi::invoke from solana-program is generally inefficient on consuming\nCUs. With the replacement of solana_cpi::invoke, we've found an average of 5%\nCUs saved across the board when using CPI in your Anchor program.\nSolang is no longer supported\nDevelopers wishing to use Solang templates with Anchor now have to build using\nSolang's older tooling.\nTypescript\nRemove event parsing panic issues\nEvents previously could be sent maliciously causing anyone using the event\nparser to panic. The regex has since been updated to avoid these panics and\nimprove the stability of the parser.\nAdded support for bun as a package manager\nbun is rising in popularity and has been added as an optional package in your\nAnchor.toml:\n[toolchain]\npackage_manager = \"bun\"\nor when creating a new workspace:\nanchor init <NAME> --package-manager bun\nSupported values: npm, yarn, pnpm, bun (default: yarn)\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.32.1Next0.31.2On this pageHow to upgradeRecommended Solana VersionCLIanchor verify now uses solana-verify to verify buildsIDL is automatically uploaded by default on deploymentAdd MSRV to the Rust templateIDLIDL building is now stabilized.LangImproved error messaging when trying to create SystemAccountUse solana-invoke instead of solana_cpi::invoke for CPISolang is no longer supportedTypescriptRemove event parsing panic issuesAdded support for bun as a package managerEdit on GitHub","tokens":1068,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259229670,"hash":"ec911cca0a8e9ccc3d74331c52b309bf89bf4ea9"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-31-2","domain":"anchor-lang.com","title":"0.31.2","text":"Anchor Project UpdatesRelease Notes0.31.2Anchor - Release Notes 0.31.20.31.2 adds TypeScript client support for parsing Solana transaction version 1\n(v1) transactions. This is a TypeScript-only patch release.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.31.2\n\nUpdate Anchor crate(s) to 0.31.2.\n\nReplace the legacy @coral-xyz/anchor and related @coral-xyz/* packages\nwith @anchor-lang/core:\nnpm install @anchor-lang/core\nUpdate imports accordingly:\n// Before\nimport * as anchor from \"@coral-xyz/anchor\";\n\n// After\nimport * as anchor from \"@anchor-lang/core\";\n\nRecommended Solana Version\nThe recommended Solana version is 2.1.0, the same as\nv0.31.0's Recommended Solana Version.\nTypeScript\nSolana transaction version 1\nAnchorProvider can now deserialize and process Solana v1 transactions. When a\ntransaction fails, Anchor also retrieves the transaction with\nmaxSupportedTransactionVersion set to 1, so the client can return the\nprogram logs instead of failing while parsing the response.\nThe client now uses @solana/web3.js 1.99.0 and requires Node.js 20.18.0 or\nlater.\nTypeScript package migration\nUsers must switch from the legacy @coral-xyz/anchor packages to\n@anchor-lang/core. Update both the package dependency and all imports; the\nlegacy package line is not the supported path for this release.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.32.0Next0.31.1On this pageHow to upgradeRecommended Solana VersionTypeScriptSolana transaction version 1TypeScript package migrationEdit on GitHub","tokens":379,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259239678,"hash":"332438deef892c98dbd010d49d400a3ffebd726c"}
{"url":"https://ethresear.ch/t/confidential-wrapped-ethereum/22622","domain":"ethresear.ch","title":"Confidential Wrapped Ethereum - Privacy - Ethereum Research","text":"Confidential Wrapped Ethereum \n\n Privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n Jun 2025\n\n 1 / 8\n\n Jun 2025\n\n Aug 2025\n\n post by Arvolear on Jun 17, 2025\n\n Arvolear\n\n Privacy is crucial for Ethereum’s long-term survivability and operability.\nFollowing the marvelous Ethereum Privacy: The Road to Self-Sovereignty roadmap, we came up with a concept of a confidential WETH, which may grow into a full-fledged confidential token standard (EIP) in the future.\nWould love to hear your thoughts about the draft!\n\n1. Introduction\nTransparency is one of the key benefits of public blockchains. However, the public visibility of transactions potentially compromises users’ privacy. The fundamental challenge is to balance the intrinsic benefits of blockchain openness with the vital need for individual confidentiality.\nThe goal is to create a permissionless, public good protocol that will obfuscate users’ financial activity within ETH tokens by encrypting their balances and transfer amounts. This will allow for confidential peer-to-peer payments, donations, and acquisitions in ETH without relying on centralized entities.\nThe proposal suggests creating a confidential version of wrapped Ethereum (cWETH) fully within the application layer. The solution combines the Elliptic Curve (EC) Twisted ElGamal-based commitment scheme to preserve confidentiality and the EC Diffie-Hellman (DH) protocol to introduce accessibility limited by the commitment scheme. To enforce the correct generation of commitments, encryption, and decryption, zk-SNARKs are utilized.\n1.1. Difference from the existing protocols\nThere are at least two known solutions that do not require the protocol layer modifications and can be implemented as is.\nThe Solana and Zether approaches may seem very similar at first glance, as they also use ElGamal commitments. However, the main distinguishing factor is the need to solve the discrete logarithm problem to access the encrypted balance.\nSolana partially mitigates this by maintaining a separate decryptable balance. But the main difference is that the encryption scheme used doesn’t support aggregation, and such a balance works mainly as a cache, which is updated when the pending amount is moved to the actual one. However, it is still required to decrypt the balance represented as the ElGamal commitment, which reintroduces the necessity to solve the discrete logarithm problem. Although this process can be simplified by dividing the value into chunks, the cWETH protocol proposes an encryption scheme that is aggregateable and is managed along with the ElGamal commitment to avoid computing the discrete logarithm at all.\nAnother difference lies in the ZK proofs used by cWETH. Both Solana and Zether approaches rely on the Sigma protocols and bulletproofs, while this proposal is based on the zk-SNARKs. The tradeoff here is the need for a trusted setup, but this can be mitigated by using existing trusted setups, such as Plonk’s universal setup, which has proven to be secure over time.\n2. cWETH Overview\n2.1. Wrapping ETH\nThe process of setting up the confidential account is considered to be a part of the ETH wrapping operation. Along with the usual wrap logic, upon the first deposit to the cWETH contract, each user provides a babyJubJub public key that will be used for the management of balances.\nThis public key is employed in the commitment and encryption of token amounts and balance computations. The key pair generation and initial deposit flow is depicted in the following diagram:\nFigure 1: Initial deposit to cWETH flow1999×938 225 KB\nAfter the first deposit to the cWETH contract, initial balances are updated with the values calculated according to the same formulas used for a confidential transfer, considering that the user is both the sender and the receiver. Technical details related to these values and the key pair generation process are provided in further sections of this proposal.\nThe unwrapping operation is very similar conceptually, hence it will not be covered in this section.\n2.2. Balance management\nTo avoid computing the discrete logarithm to calculate the balances hidden with ElGamal, two parallel representations of balances are maintained:\n\nElGamal commitment that is only needed for ZK proofs verification of the balance knowledge.\nBalance encrypted with the DH shared key which enables users to decrypt their actual balance data. Access to the senders’ public keys array and the encryption nonces array is required to perform the decryption.\n\nBecause ZK proofs are generated from the user’s current balance, changing it before the transaction execution may invalidate the proof. To address this issue, both types of balance (ElGamal commitment and DH-encrypted) have to be presented in two separate states:\n\nPending balance to receive tokens.\nActual balance to spend tokens.\n\nUsers can move tokens from their pending balance to the actual one at any time. Additionally, it could be done at the end of each transfer initiated by the user. This approach will consolidate the balance update into a single operation, reducing the gas usage compared to two separate transactions.\n2.3. Confidential transfer\nTo initiate a confidential transfer, it is necessary to provide the token amount represented in four different forms:\n\nHidden inside the receiver’s public key-based ElGamal commitment.\nHidden inside the sender’s public key-based ElGamal commitment.\nEncrypted with the receiver’s public key-based DH shared key for incrementing the receiver’s balance.\nEncrypted with the sender’s public key-based DH shared key for the new sender’s balance.\n\nThe diagram below illustrates the confidential transfer process:\nFigure 2: Confidential transfer flow1999×993 292 KB\nDuring the transfer, both types of balances and their associated amounts are updated to ensure consistency between different balance representations.\nNote that there exist two separate versions of the same values for both encrypted with the DH shared key and ElGamal commitment representations: the sender’s public key-based and the receiver’s public key-based. This is caused by different approaches used during the encryption and commitment generation, technical details of which are provided in the further sections of the proposal.\n3. Confidentiality Math\n3.1. KDF for confidential key pair\nThe protocol utilizes the deterministic KDF approach to generate a confidential key pair. The user has to sign an EIP-712 structured message with their Ethereum (ECDSA) private key. The hash of the signature is the babyJubJub private key.\nThe EIP-712 message is obtained as follows:\nbytes32 KDF_MSG_TYPEHASH = keccak256(“KDF(address cWETHAddress)”);\n\nbytes32 kdfStructHash = keccak256(abi.encode(KDF_MSG_TYPEHASH, cWETHAddress));\n\nThe babyJubJub private key is obtained as follows:\nsignature = eth_signTypedData_v4(kdfStructHash);\n\nprivateKey = keccak256(keccak256(signature));\n\nNote that it is crucial to never reveal the signature as the private key is directly derived from it.\n\nThe key pair must satisfy the following:\n1178×242 9.85 KB\n3.2. EC ElGamal-based commitment scheme\nThe commitment based on the EC ElGamal scheme allows for a succinct representation suitable for ZK proofs. It also facilitates seamless balance management via its additive homomorphic properties.\nThe commitment of the balance consists of two parts and is constructed according to the formula:\n1216×352 13.4 KB\nTo efficiently prove the commitment of the balance through a ZK proof, the user must use the private key to compensate for the lack of knowledge of the aggregated random nonce:\n874×106 2.92 KB\nThe commitment of the transfer amount is calculated differently for the sender and the receiver. The receiver’s amount commitment is derived as follows:\n1192×210 7.03 KB\nThe transfer amount commitment used in the aggregation of the sender’s balance commitment is calculated as:\n1152×226 7.02 KB\nThe balance commitment is computed additively as outlined below:\n1130×492 20.3 KB\n3.3. Encryption with the EC DH shared key\nSince ElGamal commitments alone do not provide a convenient means for users to access decrypted balances, requiring solving the discrete logarithm problem, an additional form of amount hiding through encryption is employed using the EC DH shared keys.\nThe DH shared key is derived as follows:\n1210×212 12.2 KB\nThe transfer amount DH-based encryption is performed differently for the sender and the receiver.\nThe encryption of the transfer amount used to aggregate the receiver’s balance is calculated according to the formula:\n1248×360 20.5 KB\nThe random nonce usage is required to solve the problem of the potential transfer data leaks caused by the lack of randomness in the encryption scheme, which can be particularly noticeable in recurring payments. These nonce values have to be stored together with the senders’ public keys so that users can decrypt their balances.\nEncrypted amounts are further used to aggregate the encrypted receiver’s balance:\n1230×358 15.2 KB\nAccording to the formula, the receiver can decrypt their balance as follows:\n1298×190 7.33 KB\nOn the sender side, using this approach for encrypting the transfer amounts could potentially lead to managing an infinite number of public keys and random nonces necessary for the balance decryption. To resolve this, each time a user transfers tokens, the lists of existing senders’ public keys and random nonces are reset. This is accomplished by calculating the new encrypted sender’s balance, as outlined below:\n1248×338 20.4 KB\nAfter updating the encrypted balance, the sender needs to manage only their own public key and random nonce as a single entry to decrypt the total amount of tokens owned.\nThe identical logic for the new balance calculation can be used to unwrap cWETH tokens.\n4. Solidity Smart Contracts\n4.1. State variables\n4.1.1. Public keys\nFirst of all, each user is associated with the corresponding public key generated during the first deposit to the cWETH contract. This is managed in a simple mapping(address => uint256[2]).\n4.1.2. Balance\nBalance of each user is represented in the ElGamal commitment form:\nstruct Commitment {\n uint256[2] C;\n uint256[2] D;\n}\n\nTo decrypt the balance encrypted with the DH shared key, along with the DH balance itself, an array of public keys of the senders and an array of encryption nonces need to be stored:\nstruct DHBalance {\n uint256 encryptedBalance;\n uint256[][2] sendersPublicKeys;\n uint256[] encryptionNonces;\n}\n\nBecause both balance types have to be provided in the form of the pending and actual balances, the final balance storage looks like this:\nstruct Balance {\n Commitment elGamalCommitmentPending;\n Commitment elGamalCommitmentActual;\n DHBalance dhEncryptedPending;\n DHBalance dhEncryptedActual;\n}\n\nmapping(uint256 => Balance) internal balances;\n\nNote that internal balance accounting is performed using the x-coordinate of the user’s public key as the key in the balances mapping.\n\n4.2. Functions\n4.2.1. Depositing to cWETH\nFor the correct confidential account creation, the deposit function is to be provided:\nfunction deposit(\n uint256[2] publicKey,\n bytes calldata amountCommitmentData,\n bytes calldata balanceEncryptionData,\n bytes calldata proofData\n) external payable;\n\nAlongside a regular ZK proof, the proofData is required to make sure that the user actually owns the private key for the provided public key.\nThe amountCommitmentData is further decoded as follows:\n(uint256[2] commitmentC, uint256[2] commitmentD) = abi.decode(amountCommitmentData, (uint256[2], uint256[2]));\n\nThe balanceEncryptionData is decoded as follows:\n(uint256 encryptedBalance, uint256 encryptionNonce) = abi.decode(balanceEncryptionData, (uint256, uint256));\n\n4.2.2. Confidential transfer\nHaving a clear understanding of the commitment and encryption schemes, the transfer function can be specified as follows:\nfunction transfer(\n address receiver,\n bytes calldata amountCommitmentData,\n bytes calldata amountEncryptionData,\n bytes calldata proofData\n) external;\n\nThe amountCommitmentData is further decoded as follows:\n(uint256[2] senderCommitmentC, uint256[2] senderCommitmentD, uint256[2] receiverCommitmentC, uint256[2] receiverCommitmentD) = abi.decode(amountCommitmentData, (uint256[2], uint256[2], uint256[2], uint256[2]));\n\nThe amountEncryptionData is decoded as follows:\n(uint256 newEncryptedBalance, uint256 senderEncryptionNonce, uint256 receiverEncryptedAmount, uint256 receiverEncryptionNonce) = abi.decode(amountEncryptionData, (uint256, uint256, uint256, uint256));\n\n4.2.3. Withdrawing cWETH\nFor unwrapping cWETH tokens, the withdraw function is to be provided:\nfunction withdraw(\n uint256 amount,\n bytes calldata amountCommitmentData,\n bytes calldata balanceEncryptionData,\n bytes calldata proofData\n) external;\n\nThe amountCommitmentData is further decoded as follows:\n(uint256[2] commitmentC, uint256[2] commitmentD) = abi.decode(amountCommitmentData, (uint256[2], uint256[2]));\n\nThe balanceEncryptionData is decoded as follows:\n(uint256 newEncryptedBalance, uint256 encryptionNonce) = abi.decode(balanceEncryptionData, (uint256, uint256));\n\n5. Circom Circuits\nEach parameter described in this proposal is designed to be verifiable on-chain and compatible with zero knowledge circuits.\n5.1. Deposit to cWETH circuit\nThe list of circuit signals for the deposit into the cWETH proof is the following:\nPublic signals:\n\nUser public key;\nDeposit amount;\nElGamal commitment of the user’s balance;\nElGamal commitment of the deposit amount;\nUser balance after the deposit encrypted with the user’s public key-based DH key;\nEncryption random nonce.\n\nPrivate signals:\n\nUser private key;\nRandom nonce used in the ElGamal commitment.\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided public key.\nThe provided deposit amount is proven to be the one committed using the ElGamal-based commitment.\nThe user’s balance after the deposit is proven to be the one encrypted with the DH shared key.\n\n5.2. Confidential transfer circuit\nThe list of circuit signals for the confidential transfer proof is the following:\nPublic signals:\n\nSender’s public key;\nReceiver’s public key;\nElGamal commitment of the sender’s balance;\nElGamal commitment of the transfer amount based on the sender’s public key;\nElGamal commitment of the transfer amount based on the receiver’s public key;\nNew sender’s balance encrypted with the sender’s public key-based DH shared key;\nRandom nonce used in the sender’s new balance encryption;\nTransfer amount encrypted with the receiver’s public key-based DH shared key;\nRandom nonce used during the receiver’s transfer amount encryption.\n\nPrivate signals:\n\nSender’s private key;\nSender’s balance;\nTransfer amount;\nRandom nonce used in the sender’s ElGamal commitment;\nRandom nonce used in the receiver’s ElGamal commitment;\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided sender’s public key.\nThe provided sender’s balance is proven to be the one committed using the ElGamal commitment and to be greater than or equal to the transfer amount.\nThe sender’s ElGamal commitment of the transfer amount was generated correctly.\nThe receiver’s ElGamal commitment of the transfer amount was generated correctly.\nThe new sender’s balance was correctly encrypted with the sender’s public key-based DH shared key.\nThe transfer amount was correctly encrypted with the receiver’s public key-based DH shared key\n\n5.3. Withdraw from cWETH circuit\nThe list of circuit signals for withdrawing cWETH proof is the following:\nPublic signals:\n\nUser public key;\nReceiver address;\nWithdrawal amount;\nElGamal commitment of the user’s balance;\nElGamal commitment of the withdrawal amount based on the user’s public key;\nBalance after the withdrawal encrypted with the user’s public key-based DH shared key;\nRandom nonce used during the new balance encryption.\n\nPrivate signals:\n\nUser private key;\nUser balance;\nRandom nonce used in the ElGamal commitment;\n\nOperating these signals, the circuit must have the following constraints:\n\nThe provided private key is indeed the private key of the provided public key.\nThe provided sender’s balance is proven to be the one committed using the ElGamal commitment and to be greater than or equal to the withdrawal amount.\nThe ElGamal commitment of the withdrawal amount was generated correctly.\nThe new balance (after the withdrawal) was correctly encrypted with the user’s public key-based DH shared key.\n\nReferences\nSolana Foundation. Confidential Token Extension. 2022.\nBenedikt B¨unz et al. Zether: Towards Privacy in a Smart Contract World. 2020.\n\n ZEX v0.1: Confidential Peer-to-Peer DEX\n\n Private Multisig v0.1\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n post by 71104 on Jun 17, 2025\n\n 24 days later\n\n post by colinlyguo on Jul 11, 2025\n\n post by Arvolear on Jul 11, 2025\n\n post by Arvolear on Jul 15, 2025\n\n post by colinlyguo on Jul 15, 2025\n\n 14 days later\n\n post by mmjahanara on Jul 29, 2025\n\n 19 days later\n\n post by Arvolear on Aug 18, 2025\n\n Powered by Discourse","tokens":4297,"squid":"ink-research","role":"Deep Scholar","at":1791259247270,"hash":"0c08b58d9688132f7a0492fa1a2a6be4e8077f82"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-31-0","domain":"anchor-lang.com","title":"0.31.0","text":"Anchor Project UpdatesRelease Notes0.31.0Anchor - Release Notes 0.31.0The last major release before v1 is finally here.\nAs always, there are a great number of changes, but we'll only be covering the\nmost important ones here. For a list of all notable changes, see the\nCHANGELOG.\n\nHow to upgrade\n\nInstall the latest version of avm:\ncargo install --git https://github.com/otter-sec/anchor avm --force\nThis will allow installing Anchor CLI without having to compile from source,\nsee Install from binary.\n\nUpdate anchor-cli:\navm install 0.31.0\n\nUpdate Anchor crate(s) to 0.31.0.\n\nUpdate TS package(s) to 0.31.0.\n\nRecommended Solana Version\nThe recommended Solana version is 2.1.0. This is a special upgrade because\nsome of the Solana binaries have been renamed to Agave, see\nAgave transition.\nYou can install the newer tooling by running:\nsh -c \"$(curl -sSfL https://release.anza.xyz/v2.1.0/install)\"\nThis change is handled automatically if you specify toolchain.solana_version,\nsee Automatic Agave transition.\nAVM\nInstall from binary\navm install now downloads binaries from GitHub by default.\nThe following build targets are supported:\n\naarch64-apple-darwin\nx86_64-unknown-linux-gnu\nx86_64-apple-darwin\nx86_64-pc-windows-msvc\n\nYou can add the --from-source flag to the install command if that's\npreferred (or required due to unsupported platform).\nCLI\nAutomatic Agave transition\nAs mentioned in Recommended Solana version\nsection, some of the Solana binaries are renamed to Agave. solana-install is\ndeprecated in 1.18.19 and logs a deprecation message when used (this results\nin parsing failure in older Anchor versions):\n⚠️ solana-install is deprecated and will be discontinued when v1.18 is no longer supported. Please switch to Agave: https://github.com/anza-xyz/agave/wiki/Agave-Transition\nIn this release, if you specify solana_version field with a version greater\nthan 1.18.19, it automatically installs and switches to agave-install:\n[toolchain]\nsolana_version = \"2.1.0\"\nsolana-program warning\nAdding solana-program as a dependency of Anchor programs should be avoided to\ndecrease the possibility of version conflicts between Solana v1 and v2 crates.\nYou'll see the following warning on builds if you have solana-program in your\ndependency list:\nWARNING: Adding `solana-program` as a separate dependency might cause conflicts.\nTo solve, remove the `solana-program` dependency and use the exported crate from `anchor-lang`.\n`use solana_program` becomes `use anchor_lang::solana_program`.\nProgram name: `my-program`\nPass cargo args to IDL build\nBoth anchor build and anchor idl build commands pass the cargo arguments\nto the underlying IDL build command. For example:\nanchor build -- --features my-feature\nnow builds the IDL with my-feature enabled.\n--no-idl flag for tests\nIf you make a change to your program, but the API of the program stays the same,\nbuilding the IDL is pointless and takes additional time.\nSimilar to --no-idl flag on builds, now\nyou can use:\nanchor test --no-idl\nmollusk test template\nYou can initialize your workspace using the new\nmollusk template by running:\nanchor init my-program --test-template mollusk\nclean\nanchor clean now also removes the generated .anchor directory.\nFor those of you that don't know, this command is similar to cargo clean, but\nit keeps the program keypairs.\nAutomatic IDL conversion\nLegacy IDLs (pre Anchor v0.30) were not supported in v0.30, unless you first\nconverted them to the new spec using anchor idl convert. In this release,\nvarious commands do this conversion automatically, meaning you'll be able to\nwork with both specs without having to switch versions. The only exception is\nthe idl fetch command, which does not convert legacy IDLs.\nPackage manager\nAnchor has been using yarn as the default JS package manager, but some people\nwant to use other package managers. Changing the package manager to use wasn't\neasy, as certain commands required yarn to be installed to function properly.\nThis is no longer the case, and you can simply specify the package manager to\nuse from Anchor.toml:\n[toolchain]\npackage_manager = \"npm\"\nor when creating a new workspace:\nanchor init <NAME> --package-manager npm\nSupported values: npm, yarn, pnpm (default: yarn)\nShell completions\nYou can now generate shell completions, see\nShell Completions.\nLang\nStack memory improvements\nThis is going to be a longer section, TL;DR is stack usage is improved massively\nwhen using init constraints, and stack warnings on builds are now reliable\nwhen using Solana v2 (platform-tools v1.42). Keep reading if you're interested\nin learning more, otherwise you can skip to\nCustom discriminators.\nThe main place where Anchor programs are likely to hit stack violation errors is\na generated function called try_accounts. This is where the instruction is\ndeserialized and constraints are run. Although having everything at the same\nplace is convenient for using constraints, this also makes it very easy to use\nthe fixed amount of stack space (4096 bytes) SVM allocates just by increasing\nthe number of accounts the instruction has. You might be familiar with it from\nthe mangled build logs:\nError: Function _ZN71_$LT$pr..Test$u20$as$u20$anchor_lang..Accounts$LT$pr..TestBumps$GT$$GT$12try_accounts17h5572074d55b9e638E Stack offset of 4112 exceeded max offset of 4096 by 16 bytes, please minimize large stack variables.\nThe problem was made worse with the following external developments:\n\nRust/LLVM changes shipped with Solana v1.18 made Anchor's try_accounts\nfunction use even more stack space, resulting in much lower threshold to hit\nstack-related problems.\nThe stack logs were unreliable, meaning you wouldn't always get warnings\nduring builds if you went over the stack limit.\nThe feature\n\"Account data direct mapping\",\nwhich is enabled by default when using local-validator, made the programs run\ninto undefined behavior\nwhen a function used more stack space than it had available.\n\nAll of this combined meant that your programs used more stack space (1), but\nsometimes the errors didn't get caught during the compile time (2) or even the\nruntime (3).\nUndefined behavior is particularly challenging to debug because things may\nappear to work as expected during tests, but a different input to the same test\nmight overwrite an account's data with unintended bytes. There are endless\nscenarios that could go wrong here, and some examples include\n#2955,\n#3113, and\n#3196.\nThere isn't much we can do for problems 1 and 3, but the problem 2 is resolved\nwith Solana v2 (platform-tools v1.42), meaning you'll reliably get warnings\nabout all stack problems.\nCircling back to Anchor, the biggest offender to the stack usage was identified\nto be the init constraint. Each init constraint expands to a lengthy code\ninside try_accounts, resulting in excessive stack usage when multiple init\nconstraints are used. This problem was fixed by moving the init code inside a\nclosure and immediately calling it in order to create and use a different stack\nframe (#2939).\nRelated to this topic, there is\nSIMD-0166,\na proposal to introduce dynamic stack frames.\nIn short, you'll have fewer problems related to stack memory when using Anchor\nv0.31 and Solana v2. If you're still running into problems, please create an\nissue in otter-sec/anchor.\nCustom discriminators\nBefore this release, there were several problems regarding Anchor\ndiscriminators:\n\nDue to the transaction size limits enforced by the Solana runtime (1232\nbytes), 8 bytes can be too high for some use cases\nThe Discriminator trait had a fixed size type field ([u8; 8]), which meant\nwe wouldn't be able to implement it for non-Anchor programs (e.g. in\ndeclare_program!)\nDiscriminators were not customizable\nChanging the name of the data type the discriminator was derived from resulted\nin a different discriminator\n\nThis release solves all of the above problems by introducing support for custom\ndiscriminators. The default 8-byte discriminators have not changed, but you can\noverride them via the discriminator argument implemented in various Anchor\nattribute macros:\n\n#[account(discriminator = 1)]\n#[event(discriminator = [1, 2])]\n#[instruction(discriminator = MY_CONST)]\n\nAll constant expressions are supported.\nSee\nexample.\nIt's important that the discriminator is always unique for the type you're\nimplementing it for. While the discriminator can be at any length (including\nzero), the IDL generation does not currently allow empty discriminators for\nsafety and convenience reasons. However, the Discriminator trait definition\nstill allows empty discriminators because some non-Anchor programs, e.g. the SPL\nToken program, don't have account discriminators. In that case, safety checks\nshould never depend on the discriminator.\nAdditionally, the IDL generation step also checks whether you have ambiguous\ndiscriminators i.e. discriminators that can be used for multiple types. However,\nyou should still consider future possibilities, especially when working with\n1-byte discriminators. For example, having an account with discriminator [1]\nmeans you can't have any other discriminators that start with 1, e.g.\n[1, 2 , 3, 4], as it would not be unique.\nThis change also enables using non-Anchor programs with both Rust (via\ndeclare_program!) and in the\nTS client.\nDiscriminator trait\nThe discriminator method of the Discriminator trait has been removed. If you\nhave compilation errors related to this removal, you can simply replace the\ndiscriminator() call to the DISCRIMINATOR associated constant.\nThis trait is now exported from prelude, and it can be used to replace a very\ncommon usage that hardcodes the discriminator length as 8. For example, the\nfollowing:\nspace = 8 + ...\ncan be replaced by:\nspace = MyAccount::DISCRIMINATOR.len() + ...\nLazyAccount\nLazyAccount is an experimental account type that can be used to replace\nAccount when you're running into performance-related problems.\nWe'll skip the details to keep the release notes as short as possible, but if\nyou're interested, check out\nits documentation\nto see if it fits your needs.\nNote: You need to enable lazy-account feature of anchor-lang to be able\nto use LazyAccount.\ncfg attribute on instructions\nYou can now use cfg attributes on instructions:\n#[program]\nmod my_program {\n #[cfg(feature = \"my-feature\")]\n pub fn my_feature(ctx: Context<MyFeature>) -> Result<()> {}\n}\nUnnamed and unit structs with InitSpace\nUnnamed and unit struct support was added in v0.30, but deriving InitSpace did\nnot work with these structs. This release adds support for both of them:\n#[derive(InitSpace)]\npub struct Unnamed(pub u64, #[max_len(64)] pub Vec<u8>);\n\n#[derive(InitSpace)]\npub struct Unit;\nAccount parser\nYou can now conveniently parse any program account using declare_program!:\ndeclare_program!(my_program);\nThis will generate something similar to:\npub enum Account {\n SomeAccount(SomeAccount),\n OtherAccount(OtherAccount),\n}\nUse my_program::utils::Account::try_from_bytes to parse any account belonging\nto the program.\ndeclare_program! improvements\nThe following issues related to\ndeclare_program! have been fixed:\n\nBeing unable to use constant bytes\n(#3287)\nMissing docs from the generated constants\n(#3311)\nCompilation errors related to incorrectly adding derives and reprs to type\naliases (#3504)\nBeing unable to use data as an instruction parameter\n(#3574)\n\nSPL\nNew Token 2022 instructions\nThe following Token 2022 instructions were added:\n\nburn_checked\nmint_to_checked\napprove_checked\nwithdraw_withheld_tokens_from_accounts\n\nIDL\nSafety comment checks\nIn v0.30.1, you'd run into panics in Rust Analyzer if you enabled all features\nbecause the idl-build feature expected an environment variable to be set. This\nwas always set if you used anchor build, but since Rust Analyzer did not know\nabout this environment variable, it would panic:\ncustom attribute panicked\nmessage: Safety checks failed: Failed to get program path\nIt no longer panics if the environment variable is missing.\naddress constraint with non-const expressions\nThere was a regression in v0.30 that made using non-const expressions with the\naddress constraint fail:\n#[derive(Accounts)]\npub struct MyIx {\n #[account(address = my_account.authority())]\n pub authority: Signer<'info>,\n pub my_account: Account<'info, MyAccount>,\n}\nThis is now fixed and no longer results in build errors.\nSee otter-sec/anchor#3216 for\nmore information.\nProgram accounts with full paths\nThe following did not work in v0.30, but it works now:\n#[derive(Accounts)]\npub struct FullPath<'info> {\n pub external_program: Program<'info, external::program::External>,\n}\nIdlBuilder\nBuilding the IDL via the\nbuild_idl\nfunction made it impossible to extend its functionality e.g. add new parameters\nwithout a breaking change. To solve this problem, there is a new way to build\nIDLs programmatically:\nlet idl = IdlBuilder::new().program_path(path).skip_lint(true).build()?;\nSee\nIdlBuilder\nfor more information.\nGeneration improvements\nThe following issues with the IDL generation have been fixed:\n\nA bug where using tuple parameters in instructions would result in an\nincorrect IDL (#3294)\nA bug where doc comments could trigger false-positives during module paths\nconversion (#3359)\nA bug where the generated IDL only has partial resolution information\n(#3474)\nBeing unable to use constant identifiers as generic arguments\n(#3522)\nBeing unable to pass in a Pubkey constant to seeds::program\n(#3559)\nBeing unable to pass in an account or an argument to seeds::program\n(#3570)\n\nTypeScript\nSimpler Program construction\nTypeScript's automatic inference of JSON files made it difficult to use the\nProgram constructor without additional casting:\nimport * as idl from \"./idl/my_program.json\";\nimport type { MyProgram } from \"./types/my_program\";\n\nconst program = new Program(idl as unknown as MyProgram, provider);\nCasting to unknown or any was necessary when TypeScript automatically\ninferred the type of the JSON file.\nIn this release, the program constructor no longer infers the IDL type from the\ngiven idl argument. This makes it easier to specify the actual IDL type:\nconst program = new Program<MyProgram>(idl, provider);\nError improvements\nAccount resolution error now includes the accounts that weren't able to get\nresolved:\nReached maximum depth for account resolution. Unresolved accounts: `pda`, `anotherPda`\nSimilarly, unsupported view method error now includes the possible causes:\nError: Method does not support views. The instruction should return a value, and its accounts must be read-only\nType improvements\nIt's common to use //@ts-ignore to get the payer keypair in tests:\n// @ts-ignore\nconst payer = program.provider.wallet.payer;\nTo fix this problem, the Provider interface now includes an optional\nwallet: Wallet field, and similarly, the Wallet interface now includes\noptional payer: Keypair field.\nYou can now do:\nconst payer = program.provider.wallet!.payer!;\nWe're using ! because we know these fields are going to be defined in our\ntesting environment.\nBetter confirmation\nProvider.sendAndConfirm now takes in an optional blockhash and uses that for\nbetter transaction confirmation:\nawait program.provider.sendAndConfirm(tx, signers, { blockhash: ... });\nPrograms with numbers in their name\nTesting programs with numbers in their name using anchor.workspace now works\nfor all cases.\nFor more details about the problem and its solution, see\n#3450.\nRust Client\ntokio support\nThere was a problem that made it impossible to use tokio with\nanchor-client.\nThis problem is now fixed, and you can use tokio (with async feature). See\ntokio example.\nMock client\nIt's now possible to pass in a\nmock RPC client\nfor testing by enabling the mock feature:\nanchor-client = { version = \"0.31.0\", features = [\"mock\"] }\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.31.1Next0.30.2On this pageHow to upgradeRecommended Solana VersionAVMInstall from binaryCLIAutomatic Agave transitionsolana-program warningPass cargo args to IDL build--no-idl flag for testsmollusk test templatecleanAutomatic IDL conversionPackage managerShell completionsLangStack memory improvementsCustom discriminatorsDiscriminator traitLazyAccountcfg attribute on instructionsUnnamed and unit structs with InitSpaceAccount parserdeclare_program! improvementsSPLNew Token 2022 instructionsIDLSafety comment checksaddress constraint with non-const expressionsProgram accounts with full pathsIdlBuilderGeneration improvementsTypeScriptSimpler Program constructionError improvementsType improvementsBetter confirmationPrograms with numbers in their nameRust Clienttokio supportMock clientEdit on GitHub","tokens":4143,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259250068,"hash":"9bf9144320e05c98d8cc2d803234d99ce6e16248"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-31-1","domain":"anchor-lang.com","title":"0.31.1","text":"Anchor Project UpdatesRelease Notes0.31.1Anchor - Release Notes 0.31.1This patch release aims to fix proc-macro2 related IDL build errors (see\nproc-macro2 build fix).\nNew Releases for Anchor will be published under the solanafoundation GitHub\norganization from now on.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.31.1\n\nUpdate Anchor crate(s) to 0.31.1.\n\nUpdate TS package(s) to 0.31.1.\n\nRecommended Solana Version\nThe recommended Solana version is 2.1.0, the same as\nv0.31.0's Recommended Solana Version.\nDocker\nThis release uses a new docker image found at\nsolanafoundation/anchor. New\nimages will be pushed to this organization in the future.\nIDL\nproc-macro2 build fix\nproc-macro2 1.0.95 removed the source_file method of Span due to an\nunderlying nightly compiler change\nrust-lang/rust#139671, which\nresulted in the following error for Anchor users:\nerror[E0599]: no method named `source_file` found for struct `proc_macro2::Span` in the current scope\nThis should now be fixed in this release.\nTypeScript\nAccount resolver no longer requires wallet\nResolving signers had a wallet requirement, and failing to meet this requirement\nresulted in the following error:\nThis function requires the `Provider` interface implementor to have a `wallet` field.\nNow, it's only required for the publicKey field of Provider to be set.\nMultiple constant generics\nAn issue where having multiple constant generics would result in parsing errors\nhas been fixed.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.31.2Next0.31.0On this pageHow to upgradeRecommended Solana VersionDockerIDLproc-macro2 build fixTypeScriptAccount resolver no longer requires walletMultiple constant genericsEdit on GitHub","tokens":426,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259261166,"hash":"083551dbc19d6b17855bc3aa8f1ec972589dd8ed"}
{"url":"https://docs.arbitrum.io/stylus/troubleshooting-building-stylus","domain":"docs.arbitrum.io","title":"Troubleshooting Stylus | Arbitrum Docs","text":"✏️Request an update\nHow does Stylus manage security issues in smart contracts when interacting with so many different languages?​\nAll languages are compiled to WASM for them to be able to work with Stylus. So it just needs to verify that the produced WASM programs behave as they should inside the new virtual machine.\nIs there any analogue of the fallback function from Solidity in the Rust Stylus SDK?​\nYes, starting with SDK version 0.7.0, the Router trait supports both fallback and receive methods, similar to their Solidity counterparts. The fallback method is called when a transaction has calldata\nthat doesn't match any defined function, while the receive method is called when a transaction has empty calldata. You can find more information in Fallback and receive\nfunctions.\nFor older SDK versions (pre-0.7.0), you can use a minimal entrypoint and perform raw delegate calls, forwarding your calldata. You can find more information in Bytes-in, bytes-out\nprogramming and call, static_call and\ndelegate_call.\nIs it possible to verify Stylus contracts on the block explorer?​\nCurrently it is not possible to verify contracts compiled to WASM on the block explorer, but we are actively working with providers to have the verification process ready for when Stylus reaches mainnet-ready status.\nDo Stylus contracts compile down to EVM bytecode like prior other attempts?​\nNo. Stylus contracts are compiled down to WASM. The user writes a program in Rust / C / C++ which is then compiled down to WebAssembly.\nHow is a Stylus contract deployed?​\nStylus contracts are deployed onchain as a blob of bytes, just like EVM ones. The only difference is that when the contract executes, instead of invoking the EVM, we invoke a separate WASM runtime. Note that a special EOF-inspired prefix distinguishes Stylus contracts from traditional EVM contracts: when a contract's bytecode starts with the magic 0xEFF00000 prefix, it's a Stylus WASM contract.\nIs there a new transaction type to deploy Stylus contracts?​\nYou deploy a Stylus contract the same way that Solidity contracts are deployed. There are no special transaction types. As a UX note: a WASM will revert until a special instrumentation operation is performed by a call to the new  ArbWasm precompile, which readies the program for calls onchain.\nYou can find instructions for deploying a Stylus contract in our Quickstart.\nDo Stylus contracts use a different type of ABI?​\nStylus contracts use solidity ABIs. Methods, signatures, logs, calls, etc. work exactly as in the EVM. From a user's / explorer's perspective, it all just looks and behaves like Solidity.\nDoes the Stylus SDK for Rust support custom data structures?​\nFor in-memory usage, you should be able to use any implementation of custom data structures without problems.\nFor storage usage, it may be more complicated. Stylus uses the EVM storage system, so you'll need to define the data structure on top of it. However, in the SDK, there's a storage trait that custom types can implement to back their collections with the EVM state trie. The SDK macros are also compatible with them, although it's still fundamentally a global key-value system.\nYou can read more about it in the Stylus Rust SDK page.\nAs an alternative solution, you can use entrypoint-style contracts for your custom data structures.\nWhy do I get an error \"no library targets found in package\" when trying to compile and old example?​\nSome of the first Stylus examples were built and deployed using a previous version of cargo-stylus (0.1.x). In that version, Stylus projects were structured as regular Rust binaries.\nSince cargo-stylus v0.2.1, Stylus projects are structured as libraries, so when trying to compile old projects you might get an error no library targets found in package.\nTo solve this, it's usually enough to rename the main.rs file to a lib.rs file.\nHow can I generate the ABI of my Stylus contract?​\nThe\nhas a command that allows you to export the ABI of your Stylus contract: cargo stylus export-abi.\nIf you're using the Stylus Rust SDK, you'll need to enable the export-abi feature in your Cargo.toml file like so:\n[features]export-abi = [\"stylus-sdk/export-abi\"]\nYou'll also need to have a main.rs file that selects that feature.\nThis is an example of a main.rs file that allows you to export the ABI of the stylus-hello-world example project:\n#![cfg_attr(not(feature = \"export-abi\"), no_main)]#[cfg(feature = \"export-abi\")]fn main() { stylus_hello_world::main();}\nHow can I find out if the smart contract bytecode is from a Stylus contract or Solidity contract?​\nYou can check the first three bytes of the code at the contract address. If they read 0xEFF000, it's a Stylus program. Otherwise, it will be from a Solidity contract.\nI'm trying to work with cargo stylus on Windows and got error: failed to resolve: could not find unix in os​\nCargo Stylus is just compatible with Unix operating systems and not Windows. You should install WSL (Windows Subsystem for Linux) before using that and then use WSL terminal to install and use cargo stylus.\nHow can I return a struct from a function?​\nCurrently, the SDK doesn't support external structs directly, but support is in progress. For now, you can use tuples as output instead of structs.\nKeep in mind that structs are mapped to tuples by the Solidity ABI. You can read more about this mapping here: Solidity ABI Specification.\nSince the current SDK macro doesn't automatically handle struct-to-tuple conversions, you'll need to manually convert your struct into a tuple in the return type.\nHow can I get the WASM opcodes of the compiled Stylus contracts?​\nTo view the WASM opcodes, you can convert the WebAssembly binary (WASM) to WebAssembly Text (WAT). This conversion is possible using the WebAssembly Binary Toolkit (wabt). An easy way to do this is to use the online tool Wasm-to-Wat converter, which is part of wabt.\nFor more information or if you'd like to use the toolkit locally, you can find wabt on GitHub.\nWhat is the difference between .set and .setter?​\n\n.set**:** This method is used directly to set a value in storage. It's a straightforward way to assign a value if you only need to perform a one-time set operation.\n.setter**:** This method provides a handle to a storage slot. It allows you to both set and get the value of the storage slot, making it more versatile if you need to access the current value and also update it.\nIf you plan to both retrieve and modify a value frequently, it's more efficient to use .setter, assign it to a variable, and then use the .get and .set methods on that variable. However, if you only need to set a value, you can use .set directly.\nHow does Stylus manage security issues in smart contracts when interacting with so many different languages?Is there any analogue of the fallback function from Solidity in the Rust Stylus SDK?Is it possible to verify Stylus contracts on the block explorer?Do Stylus contracts compile down to EVM bytecode like prior other attempts?How is a Stylus contract deployed?Is there a new transaction type to deploy Stylus contracts?Do Stylus contracts use a different type of ABI?Does the Stylus SDK for Rust support custom data structures?Why do I get an error \"no library targets found in package\" when trying to compile and old example?How can I generate the ABI of my Stylus contract?How can I find out if the smart contract bytecode is from a Stylus contract or Solidity contract?I'm trying to work with cargo stylus on Windows and got error: failed to resolve: could not find unix in osHow can I return a struct from a function?How can I get the WASM opcodes of the compiled Stylus contracts?What is the difference between .set and .setter?","tokens":1924,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259264686,"hash":"d753d97d9ebecaac9725d395937172ecfe3dbd1e"}
{"url":"https://ethresear.ch/t/confidential-wrapped-ethereum/22622/9","domain":"ethresear.ch","title":"Confidential Wrapped Ethereum - Privacy - Ethereum Research","text":"Privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 7\n min\n\n Jun 2025\n\n 8 / 8\n\n Aug 2025\n\n Aug 2025\n\n post by Arvolear on Jun 17, 2025\n\n post by 71104 on Jun 17, 2025\n\n 24 days later\n\n post by colinlyguo on Jul 11, 2025\n\n post by Arvolear on Jul 11, 2025\n\n Arvolear\n\n Hey, thanks for taking a look!\n\nYes, this is surely possible. A user may even use some kind of fuzzy extractors + randomness to generate the keys from real-world objects or even faces.\nThanks for spotting! That’s an editorial error that was fixed in the actual paper. Unfortunately, I don’t have enough permissions to edit the post here.\n\n post by Arvolear on Jul 15, 2025\n\n Arvolear\n\n UPD: just published the proposal to arXiv and fixed the bad sign typo on the forum.\n\n post by colinlyguo on Jul 15, 2025\n\n colinlyguo\n\n Arvolear\n\n Thanks for the clarification. And if using an encryption key not derived from the wallet private key (by signing a message), a tradeoff would be to keep the new key.\n\n 14 days later\n\n post by mmjahanara on Jul 29, 2025\n\n mmjahanara\n\n Given that using space-time optimization for say 32bit values, discrete logarithm problem is solvable extremely efficiently (probably under 100ms on consumer devices), I don’t understand why the motivation focuses on getting rid of discrete logarithm. Especially that this never has to happens in circuit. Am I missing something?\nOn the other hand, Solana style confidential transfer proofs are extremely large, roughly 2kb, so reducing the size of the proof is the more obvious problem, which I believe your scheme partially addresses by replacing sigma proofs and bulletproofs.\n\n 19 days later\n\n post by Arvolear on Aug 18, 2025\n\n Arvolear\n\n Solving a 32-bit (even 40-bit) discrete log is not a problem if we want to represent balances either without precision or in szabo. Otherwise, we would need to split up the balance into chunks and solve a discrete log 5 times. If this could be avoided, I would rather avoid it.\nThe proof size is solved by using zkSNARKs. It can be either groth16, which is a bit cheaper to verify on-chain, or a plonk scheme with a universal trusted setup.\n\n Powered by Discourse","tokens":544,"squid":"ink-research","role":"Deep Scholar","at":1791259267678,"hash":"88d8294b072353432e1eb1c672d90cea2e887989"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-30-2","domain":"anchor-lang.com","title":"0.30.2","text":"Anchor Project UpdatesRelease Notes0.30.2Anchor - Release Notes 0.30.20.30.2 adds TypeScript client support for parsing Solana transaction version 1\n(v1) transactions. This is a TypeScript-only patch release.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.30.2\n\nUpdate Anchor crate(s) to 0.30.2.\n\nReplace the legacy @coral-xyz/anchor and related @coral-xyz/* packages\nwith @anchor-lang/core:\nnpm install @anchor-lang/core\nUpdate imports accordingly:\n// Before\nimport * as anchor from \"@coral-xyz/anchor\";\n\n// After\nimport * as anchor from \"@anchor-lang/core\";\n\nRecommended Solana Version\nThis release supports any Solana version above 1.17.3, with 1.18.17\nrecommended. Upgrade Solana tools with:\nsolana-install init 1.18.17\nTypeScript\nSolana transaction version 1\nAnchorProvider can now deserialize and process Solana v1 transactions. When a\ntransaction fails, Anchor also retrieves the transaction with\nmaxSupportedTransactionVersion set to 1, so the client can return the\nprogram logs instead of failing while parsing the response.\nThe client now uses @solana/web3.js 1.99.0 and requires Node.js 20.18.0 or\nlater.\nTypeScript package migration\nUsers must switch from the legacy @coral-xyz/anchor packages to\n@anchor-lang/core. Update both the package dependency and all imports; the\nlegacy package line is not the supported path for this release.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.31.0Next0.30.1On this pageHow to upgradeRecommended Solana VersionTypeScriptSolana transaction version 1TypeScript package migrationEdit on GitHub","tokens":391,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259283130,"hash":"26cc4291c45c3efc8ea271e1ce07983ceed58a0d"}
{"url":"https://ethresear.ch/t/mempool-account-transaction-capacity-from-historical-activity-matcha/25949/13","domain":"ethresear.ch","title":"Mempool Account Transaction Capacity from Historical Activity (MATCHA) - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n account-abstraction,transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n read \n\n 7\n min\n\n Sep 8\n\n 12 / 12\n\n Oct 4\n\n 19h ago\n\n post by soispoke on Sep 8\n\n post by AnkushinDaniil on Sep 8\n\n post by TimTinkers on Sep 8\n\n post by soispoke on Sep 9\n\n post by soispoke on Sep 9\n\n post by AnkushinDaniil on Sep 14\n\n post by soispoke on Sep 15\n\n post by AnkushinDaniil on Sep 15\n\n post by egpivo on Sep 22\n\n 10 days later\n\n post by jstinhw 4 days ago\n\n jstinhw\n\n soispoke\n\n Consider a privacy pool used as a paymaster: users transact from arbitrary sender addresses and prove they can spend a note in the pool to pay gas. The pool is the shared payer.\nFor the proposed paymaster extension to MATCHA, could a malicious user drain the pool’s width by submitting multiple spends of the same note from different senders, reducing throughput for other users?\nFor example, assuming the baseline/width model applies per payer:\n\nThe pool has enough width for 100 additional admissions and enough ETH to cover the maximum-cost reservations.\nAn attacker submits one baseline transaction plus 100 additional transactions from different senders. Each has a valid proof spending the same note, with the same nullifier.\nAll independently pass validation against the current head because the note is unspent. The (sender, nonce_key) restriction does not catch the conflict across different senders. The additional admissions consume the pool’s available width.\nOne transaction gets included and consumes the note, invalidating the others. Their spent width is not returned.\n\nWould this force other users back to the one-pending-transaction baseline, once the pending set empties, until newly finalized activity replenishes capacity?\nWould this scenario be addressed by MATCHA’s proposed paymaster extension, or would it require a separate mechanism to detect repeated (payer, nullifier) pairs across different senders\n\n post by AnkushinDaniil 23 hours ago\n\n AnkushinDaniil\n\n which write marks the note spent when the pool is only the payer? 8250 consumes keys under (tx.sender, key), so the same nullifier from 100 senders is 100 different keys, and a pay frame can’t read the pool’s own storage under the 8141 mempool rules. so i think all 100 stay valid and can land, which is a pool funds problem before a width one. would it make sense for payment approve to consume keys under the payer, so the copies collide on (payer, key) from tx fields before any width is spent?\n\n post by mmjahanara 19 hours ago\n\n mmjahanara\n\nIf a privacy pool wants to support transactions for which it is not the sender, it has to forgo using EIP-8250 as its only nullifier management mechanism, which in turn makes it practically incompatible with frame transactions as it would require tracking nullifiers in state and accessing paymaster’s state during validation which is not allowed in the public mempool for non-canonical paymasters.\n\n Powered by Discourse","tokens":746,"squid":"ink-research","role":"Deep Scholar","at":1791259289977,"hash":"017e88c38e06f775c6008788999e9ab819c98a82"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/aave-logic","domain":"aave.com","title":"Aave Logic | Aave Protocol Documentation","text":"Aave Logic#\nReference for the aave-logic Move package. The supply, borrow, repay and liquidation entry points.\nSupply Functions#\nsupply#\npublic entry fun supply( account: &signer, asset: address, amount: u256, on_behalf_of: address, referral_code: u16)\nSupplies a certain amount of an asset into the protocol, minting the same amount of corresponding aTokens and transferring them to the on_behalf_of address. For example, if a user supplies 100 USDC and on_behalf_of address is the same as the signer's address, they will get 100 aUSDC in return.\nThe referral_code is emitted in the Supply event and can be used for third-party referral integrations. To activate the referral feature and obtain a unique referral code, integrators need to submit a proposal to Aave Governance.\nWhen supplying, the Pool contract must have allowance to spend funds on behalf of the signer for at least the amount for the asset being supplied.\nReferral supply is currently inactive, you can pass 0 as referral_code. This program may be activated in the future through an Aave governance proposal.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset being supplied to the poolamountu256The amount of asset to be suppliedon_behalf_ofaddressThe address that will receive the corresponding aTokens. This is the only address that will be able to withdraw the asset from the pool. This will be the same as the signer's address if the user wants to receive aTokens into their own wallet, or use a different address if the beneficiary of aTokens is a different walletreferral_codeu16Referral supply is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-men\nBorrow Functions#\nborrow#\npublic entry fun borrow( account: &signer, asset: address, amount: u256, interest_rate_mode: u8, referral_code: u16, on_behalf_of: address)\nAllows users to borrow a specific amount of the underlying asset, provided that the borrower already supplied enough collateral.\nBorrowers can borrow at a variable rate, represented by interest_rate_mode value of 2.\nThe referral_code is emitted in the Borrow event and can be used for third-party referral integrations. To activate the referral feature and obtain a unique referral code, integrators need to submit a proposal to Aave Governance.\nReferral program is currently inactive, you can pass 0 as referral_code. This program may be activated in the future through an Aave governance proposal.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset to borrowamountu256The amount to be borrowedinterest_rate_modeu8The interest rate mode at which the user wants to borrow: 2 for Variablereferral_codeu16Referral program is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-menon_behalf_ofaddressThe address of the user who will receive the debt. Should be the address of the borrower itself calling the function\nRepay Functions#\nrepay#\npublic entry fun repay( account: &signer, asset: address, amount: u256, interest_rate_mode: u8, on_behalf_of: address)\nRepays a borrowed amount on a specific reserve, burning the equivalent debt tokens. For example, if a user repays 100 USDC, 100 variable/stable debt tokens will be burned and the underlying will be transferred from the user to the aToken contract.\nThe amount parameter can be set to math_utils::u256_max() to repay the entire debt.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the borrowed underlying asset previously borrowedamountu256The amount to repay. Can be math_utils::u256_max() to repay the whole debtinterest_rate_modeu8The interest rate mode at which the user wants to repay: 2 for Variableon_behalf_ofaddressThe address of the user who will get their debt reduced/removed. Should be the address of the borrower itself if they are repaying their own debt, or the address of the credit delegator if they are repaying a debt on behalf of a borrower\nrepay_with_a_tokens#\npublic entry fun repay_with_a_tokens( account: &signer, asset: address, amount: u256, interest_rate_mode: u8)\nRepays a borrowed amount on a specific reserve using the reserve aTokens, burning the equivalent debt tokens. For example, if a user repays 100 USDC using aUSDC, 100 variable/stable debt tokens will be burned and 100 aUSDC will be burned.\nThe amount parameter can be set to math_utils::u256_max() to repay the entire debt.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the borrowed underlying asset previously borrowedamountu256The amount to repay. Can be math_utils::u256_max() to repay the whole debtinterest_rate_modeu8The interest rate mode at which the user wants to repay: 2 for Variable\nWithdraw Functions#\nwithdraw#\npublic entry fun withdraw( account: &signer, asset: address, amount: u256, to: address)\nWithdraws an amount of underlying asset from the reserve, burning the equivalent aTokens owned by account. For example, if a user withdraws 100 USDC, 100 aUSDC will be burned and 100 USDC will be transferred to the specified to address.\nThe amount parameter can be set to math_utils::u256_max() to withdraw the entire balance.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset to withdrawamountu256The amount to be withdrawn. Can be math_utils::u256_max() to withdraw the entire balancetoaddressThe address that will receive the underlying asset\nCollateral Management Functions#\nset_user_use_reserve_as_collateral#\npublic entry fun set_user_use_reserve_as_collateral( account: &signer, asset: address, use_as_collateral: bool)\nAllows users to enable or disable a specific supplied asset as collateral. Assets used as collateral can be liquidated if the user's health factor drops below 1.0.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset supplieduse_as_collateralbooltrue if the user wants to use the asset as collateral, false otherwise\nE-Mode Functions#\nset_user_emode#\npublic entry fun set_user_emode( account: &signer, category_id: u8)\nAllows users to switch between different efficiency modes (E-modes). E-mode allows users to get higher borrowing power on a set of assets that have correlated prices.\nFor example, if a user is in the \"Stablecoins\" E-mode category, they can borrow more stablecoins against their stablecoin collateral than they would be able to in regular mode.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callercategory_idu8The id of the category to switch to. 0 to disable E-mode\nIsolation Mode#\nIsolation mode is a risk management feature in the Aave protocol that limits borrowing power for assets that might pose higher risk to the protocol.\nOverview#\nWhen a user supplies an asset marked as \"isolated collateral\" (via reserve configuration), they enter isolation mode. In isolation mode:\nUsers can only borrow assets up to a specific debt ceiling.Users can only borrow stablecoins and other assets explicitly allowed for isolated collateral.Users cannot supply other assets as collateral while in isolation mode.\nThis feature protects the protocol by limiting the maximum debt that can be borrowed against riskier assets, reducing potential systemic risk.\nRelationship with E-Mode#\nWhile E-Mode increases borrowing power for correlated assets, Isolation Mode does the opposite - it restricts borrowing power for higher-risk assets. These features serve different purposes:\nE-Mode: Optimizes capital efficiency for correlated assets (like stablecoins).Isolation Mode: Limits protocol exposure to riskier assets.\nUsers cannot be in both modes simultaneously. If a user has an isolated asset as collateral, they cannot enter E-Mode until they either disable the isolated asset as collateral or withdraw it completely.\nFlash Loan Functions#\nflash_loan_simple#\npublic fun flash_loan_simple( initiator: &signer, receiver_address: address, asset: address, amount: u256, referral_code: u16)\nAllows smart contracts to access the liquidity of the pool within one transaction, as long as the amount taken plus a fee is returned.\nThis is a simpler version of the flash loan function that only allows borrowing a single asset.\nInput Parameters:\nNameTypeDescriptioninitiator&signerThe signer account of the flash loan initiatorreceiver_addressaddressThe address of the contract receiving the fundsassetaddressThe address of the asset being flash-borrowedamountu256The amount of the asset being flash-borrowedreferral_codeu16The code used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-man\nflash_loan#\npublic fun flash_loan( initiator: &signer, receiver_address: address, assets: vector<address>, amounts: vector<u256>, interest_rate_modes: vector<u8>, on_behalf_of: address, referral_code: u16)\nInput Parameters:\nNameTypeDescriptioninitiator&signerThe signer account of the flash loan initiatorreceiver_addressaddressThe address of the contract receiving the fundsassetsvector<address>The addresses of the assets being flash-borrowedamountsvector<u256>The amounts of the assets being flash-borrowedinterest_rate_modesvector<u8>Types of the debt to open if the flash loan is not returned: 0 -> Don't open any debt, just revert if funds can't be transferred from the receiver, 2 -> Open debt at variable rate for the value of the amount flash-borrowed to the on_behalf_of addresson_behalf_ofaddressThe address that will receive the debt in the case of using interest_rate_modes 2, on_behalf_of should be the account addressreferral_codeu16The code used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-man\nLiquidation Functions#\nliquidation_call#\npublic entry fun liquidation_call( account: &signer, collateral_asset: address, debt_asset: address, user: address, debt_to_cover: u256, receive_a_token: bool)\nAllows liquidators to liquidate positions with a health factor below 1.0. The liquidator repays a portion of the debt and receives a portion of the collateral in return, plus a liquidation bonus.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the liquidatorcollateral_assetaddressThe address of the collateral asset to receivedebt_assetaddressThe address of the debt asset to be repaiduseraddressThe address of the borrowerdebt_to_coveru256The amount of debt to cover. Can be math_utils::u256_max() to liquidate the maximum possible amountreceive_a_tokenbooltrue if the liquidator wants to receive aTokens instead of the underlying asset\naave-pool-token-logic#\nTransfer Functions#\ntransfer#\npublic entry fun transfer( sender: &signer, recipient: address, amount: u256, a_token_address: address)\nTransfers aTokens from the user to the recipient. This function allows users to transfer their aTokens directly to another address.\nInput Parameters:#\nNameTypeDescriptionsender&signerThe account signer of the callerrecipientaddressThe recipient of the aTokensamountu256The amount of aTokens to transfera_token_addressaddressThe address of the aToken to transfer\nAdmin Functions#\nset_incentives_controller#\npublic entry fun set_incentives_controller( admin: &signer, underlying_asset: address, incentives_controller: Option<address>)\nSets an incentives controller for both the aToken and variable debt token of a given underlying asset.\nInput Parameters:\nNameTypeDescriptionadmin&signerThe signer account of the adminunderlying_assetaddressThe address of the underlying assetincentives_controllerOption<address>The address of the incentives controller\nmint_to_treasury#\npublic entry fun mint_to_treasury( assets: vector<address>)\nMints the assets accrued through the reserve factor to the treasury in the form of aTokens.\nInput Parameters:#\nNameTypeDescriptionassetsvector<address>The list of reserves for which the minting needs to be executedPreviousOraclesNextTokenization","tokens":3112,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259298284,"hash":"8a7c5c53cb1b512586031a8e4198db0aafaa4d8d"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable","domain":"docs.openzeppelin.com","title":"Writing Upgradeable Contracts | OpenZeppelin Docs","text":"Upgrades PluginsWriting Upgradeable ContractsOpen in ClaudeWhen working with upgradeable contracts using OpenZeppelin Upgrades, there are a few minor caveats to keep in mind when writing your Solidity code.\nIt’s worth mentioning that these restrictions have their roots in how the Ethereum VM works, and apply to all projects that work with upgradeable contracts, not just OpenZeppelin Upgrades.\nInitializers\nYou can use your Solidity contracts with OpenZeppelin Upgrades without any modifications, except for their constructors. Due to a requirement of the proxy-based upgradeability system, no constructors can be used in upgradeable contracts. To learn about the reasons behind this restriction, head to Proxies.\nThis means that, when using a contract with the OpenZeppelin Upgrades, you need to change its constructor into a regular function, typically named initialize, where you run all the setup logic:\n// NOTE: Do not use this code snippet, it's incomplete and has a critical vulnerability!\n\npragma solidity ^0.6.0;\n\ncontract MyContract {\n uint256 public x;\n\n function initialize(uint256 _x) public {\n x = _x;\n }\n}\nHowever, while Solidity ensures that a constructor is called only once in the lifetime of a contract, a regular function can be called many times. To prevent a contract from being initialized multiple times, you need to add a check to ensure the initialize function is called only once:\n// contracts/MyContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\ncontract MyContract {\n uint256 public x;\n bool private initialized;\n\n function initialize(uint256 _x) public {\n require(!initialized, \"Contract instance has already been initialized\");\n initialized = true;\n x = _x;\n }\n}\nSince this pattern is very common when writing upgradeable contracts, OpenZeppelin Contracts provides an Initializable base contract that has an initializer modifier that takes care of this:\n// contracts/MyContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\n\ncontract MyContract is Initializable {\n uint256 public x;\n\n function initialize(uint256 _x) public initializer {\n x = _x;\n }\n}\nAnother difference between a constructor and a regular function is that Solidity takes care of automatically invoking the constructors of all ancestors of a contract. When writing an initializer, you need to take special care to manually call the initializers of all parent contracts. Note that the initializer modifier can only be called once even when using inheritance, so parent contracts should use the onlyInitializing modifier:\n// contracts/MyContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\n\ncontract BaseContract is Initializable {\n uint256 public y;\n\n function initialize() public onlyInitializing {\n y = 42;\n }\n}\n\ncontract MyContract is BaseContract {\n uint256 public x;\n\n function initialize(uint256 _x) public initializer {\n BaseContract.initialize(); // Do not forget this call!\n x = _x;\n }\n}\nUsing Upgradeable Smart Contract Libraries\nKeep in mind that this restriction affects not only your contracts, but also the contracts you import from a library. Consider for example ERC20 from OpenZeppelin Contracts: the contract initializes the token's name and symbol in its constructor.\n// @openzeppelin/contracts/token/ERC20/ERC20.sol\npragma solidity ^0.8.0;\n\n...\n\ncontract ERC20 is Context, IERC20 {\n\n ...\n\n string private _name;\n string private _symbol;\n\n constructor(string memory name_, string memory symbol_) {\n _name = name_;\n _symbol = symbol_;\n }\n\n ...\n}\nThis means you should not be using these contracts in your OpenZeppelin Upgrades project. Instead, make sure to use @openzeppelin/contracts-upgradeable, which is an official fork of OpenZeppelin Contracts that has been modified to use initializers instead of constructors. Take a look at what ERC20Upgradeable looks like in @openzeppelin/contracts-upgradeable:\n// @openzeppelin/contracts-upgradeable/contracts/token/ERC20/ERC20Upgradeable.sol\npragma solidity ^0.8.0;\n\n...\n\ncontract ERC20Upgradeable is Initializable, ContextUpgradeable, IERC20Upgradeable {\n ...\n\n string private _name;\n string private _symbol;\n\n function __ERC20_init(string memory name_, string memory symbol_) internal onlyInitializing {\n __ERC20_init_unchained(name_, symbol_);\n }\n\n function __ERC20_init_unchained(string memory name_, string memory symbol_) internal onlyInitializing {\n _name = name_;\n _symbol = symbol_;\n }\n\n ...\n}\nWhether using OpenZeppelin Contracts or another smart contract library, always make sure that the package is set up to handle upgradeable contracts.\nLearn more about OpenZeppelin Contracts Upgradeable in Contracts: Using with Upgrades.\nAvoiding Initial Values in Field Declarations\nSolidity allows defining initial values for fields when declaring them in a contract.\ncontract MyContract {\n uint256 public hasInitialValue = 42; // equivalent to setting in the constructor\n}\nThis is equivalent to setting these values in the constructor, and as such, will not work for upgradeable contracts. Make sure that all initial values are set in an initializer function as shown below; otherwise, any upgradeable instances will not have these fields set.\ncontract MyContract is Initializable {\n uint256 public hasInitialValue;\n\n function initialize() public initializer {\n hasInitialValue = 42; // set initial value in initializer\n }\n}\nIt is still ok to define constant state variables, because the compiler does not reserve a storage slot for these variables, and every occurrence is replaced by the respective constant expression. So the following still works with OpenZeppelin Upgrades:\ncontract MyContract {\n uint256 public constant hasInitialValue = 42; // define as constant\n}\nInitializing the Implementation Contract\nDo not leave an implementation contract uninitialized. An uninitialized implementation contract can be taken over by an attacker, which may impact the proxy. To prevent the implementation contract from being used, you should invoke the _disableInitializers function in the constructor to automatically lock it when it is deployed:\n/// @custom:oz-upgrades-unsafe-allow constructor\nconstructor() {\n _disableInitializers();\n}\nValidating Initializers\nThe OpenZeppelin Upgrades plugins will automatically detect specific issues with initializers in implementation contracts. These include checking if your implementation contract is missing an initializer when there are parent initializers that need to be called, if a parent initializer is not called, or if a parent initializer is called more than once. The plugins will also warn if parent initializers are not called in linearized order.\nReinitializers are not included in validations by default, because the Upgrades plugins cannot determine whether they are intended to be used for new deployments. If you want to validate a reinitializer function as an initializer that can be used for new deployments, annotate it with @custom:oz-upgrades-validate-as-initializer. Note that functions which cannot possibly be initializers are always ignored, such as private functions which cannot be called externally or by child contracts.\nCreating New Instances From Your Contract Code\nWhen creating a new instance of a contract from your contract's code, these creations are handled directly by Solidity and not by OpenZeppelin Upgrades, which means that these contracts will not be upgradeable.\nFor instance, in the following example, even if MyContract is deployed as upgradeable, the token contract created is not:\n// contracts/MyContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyContract is Initializable {\n ERC20 public token;\n\n function initialize() public initializer {\n token = new ERC20(\"Test\", \"TST\"); // This contract will not be upgradeable\n }\n}\nIf you would like the ERC20 instance to be upgradeable, the easiest way to achieve that is to simply accept an instance of that contract as a parameter, and inject it after creating it:\n// contracts/MyContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\nimport \"@openzeppelin/contracts-upgradeable/token/ERC20/IERC20Upgradeable.sol\";\n\ncontract MyContract is Initializable {\n IERC20Upgradeable public token;\n\n function initialize(IERC20Upgradeable _token) public initializer {\n token = _token;\n }\n}\nPotentially Unsafe Operations\nWhen working with upgradeable smart contracts, you will always interact with the contract instance, and never with the underlying logic contract. However, nothing prevents a malicious actor from sending transactions to the logic contract directly. This does not pose a threat, since any changes to the state of the logic contracts do not affect your contract instances, as the storage of the logic contracts is never used in your project.\nThere is, however, an exception. If the direct call to the logic contract triggers a selfdestruct operation, then the logic contract will be destroyed, and all your contract instances will end up delegating all calls to an address without any code. This would effectively break all contract instances in your project.\nA similar effect can be achieved if the logic contract contains a delegatecall operation. If the contract can be made to delegatecall into a malicious contract that contains a selfdestruct, then the calling contract will be destroyed.\nAs such, it is not allowed to use either selfdestruct or delegatecall in your contracts.\nModifying Your Contracts\nWhen writing new versions of your contracts, either due to new features or bug fixing, there is an additional restriction to observe: you cannot change the order in which the contract state variables are declared, nor their type. You can read more about the reasons behind this restriction by learning about our Proxies.\nViolating any of these storage layout restrictions will cause the upgraded version of the contract to have its storage values mixed up, and can lead to critical errors in your application.\nThis means that if you have an initial contract that looks like this:\ncontract MyContract {\n uint256 private x;\n string private y;\n}\nThen you cannot change the type of a variable:\ncontract MyContract {\n string private x;\n string private y;\n}\nOr change the order in which they are declared:\ncontract MyContract {\n string private y;\n uint256 private x;\n}\nOr introduce a new variable before existing ones:\ncontract MyContract {\n bytes private a;\n uint256 private x;\n string private y;\n}\nOr remove an existing variable:\ncontract MyContract {\n string private y;\n}\nIf you need to introduce a new variable, make sure you always do so at the end:\ncontract MyContract {\n uint256 private x;\n string private y;\n bytes private z;\n}\nKeep in mind that if you rename a variable, then it will keep the same value as before after upgrading. This may be the desired behavior if the new variable is semantically the same as the old one:\ncontract MyContract {\n uint256 private x;\n string private z; // starts with the value from `y`\n}\nAnd if you remove a variable from the end of the contract, note that the storage will not be cleared. A subsequent update that adds a new variable will cause that variable to read the leftover value from the deleted one.\ncontract MyContract {\n uint256 private x;\n}\nThen upgraded to:\ncontract MyContract {\n uint256 private x;\n string private z; // starts with the value from `y`\n}\nNote that you may also be inadvertently changing the storage variables of your contract by changing its parent contracts. For instance, if you have the following contracts:\ncontract A {\n uint256 a;\n}\n\ncontract B {\n uint256 b;\n}\n\ncontract MyContract is A, B {}\nThen modifying MyContract by swapping the order in which the base contracts are declared, or introducing new base contracts, will change how the variables are actually stored:\ncontract MyContract is B, A {}\nYou also cannot add new variables to base contracts, if the child has any variables of its own. Given the following scenario:\ncontract Base {\n uint256 base1;\n}\n\ncontract Child is Base {\n uint256 child;\n}\nIf Base is modified to add an extra variable:\ncontract Base {\n uint256 base1;\n uint256 base2;\n}\nThen the variable base2 would be assigned the slot that child had in the previous version. A workaround for this is to declare unused variables or storage gaps in base contracts that you may want to extend in the future, as a means of \"reserving\" those slots. Note that this trick does not involve increased gas usage.\nStorage Gaps\nStorage gaps are a convention for reserving storage slots in a base contract, allowing future versions of that contract to use up those slots without affecting the storage layout of child contracts.\nTo create a storage gap, declare a fixed-size array in the base contract with an initial number of slots. This can be an array of uint256 so that each element reserves a 32 byte slot. Use the name __gap or a name starting with __gap_ for the array so that OpenZeppelin Upgrades will recognize the gap:\ncontract Base {\n uint256 base1;\n uint256[49] __gap;\n}\n\ncontract Child is Base {\n uint256 child;\n}\nIf Base is later modified to add extra variable(s), reduce the appropriate number of slots from the storage gap, keeping in mind Solidity's rules on how contiguous items are packed. For example:\ncontract Base {\n uint256 base1;\n uint256 base2; // 32 bytes\n uint256[48] __gap;\n}\nOr:\ncontract Base {\n uint256 base1;\n address base2; // 20 bytes\n uint256[48] __gap; // array always starts at a new slot\n}\nOr:\ncontract Base {\n uint256 base1;\n uint128 base2a; // 16 bytes\n uint128 base2b; // 16 bytes - continues from the same slot as above\n uint256[48] __gap;\n}\nTo help determine the proper storage gap size in the new version of your contract, you can simply attempt an upgrade using upgradeProxy or just run the validations with validateUpgrade (see docs for Hardhat Upgrades or Foundry Upgrades). If a storage gap is not being reduced properly, you will see an error message indicating the expected size of the storage gap.\nNamespaced Storage Layout\nERC-7201: Namespaced Storage Layout is another convention that can be used to avoid storage layout errors when modifying base contracts or when changing the inheritance order of contracts. This convention is used in the upgradeable variant of OpenZeppelin Contracts starting with version 5.0.\nThis convention involves placing all storage variables of a contract into one or more structs and annotating those structs with @custom:storage-location erc7201:<NAMESPACE_ID>. A namespace id is a string that uniquely identifies each namespace in a contract, so the same id must not be defined more than once in a contract or any of its base contracts.\nWhen using namespaced storage layouts, the OpenZeppelin Upgrades plugins will automatically detect the namespace ids and validate that each change within a namespace during an upgrade is safe according to the same rules as described in Modifying Your Contracts.\nSolidity version 0.8.20 or higher is required in order to use the Upgrades plugins with namespaced storage layouts. The plugins will give an error if they detect @custom:storage-location annotations with an older version of Solidity, because older versions of the compiler do not produce sufficient information for validation of namespaced storage layouts.Using with FoundryPrevious PageProxy Upgrade PatternNext PageOn this pageInitializersUsing Upgradeable Smart Contract LibrariesAvoiding Initial Values in Field DeclarationsInitializing the Implementation ContractValidating InitializersCreating New Instances From Your Contract CodePotentially Unsafe OperationsModifying Your ContractsStorage GapsNamespaced Storage Layout","tokens":3990,"squid":"ink-security_audits","role":"Sentinel","at":1791259298349,"hash":"aeca33d4945d4fa38132b2f7cfa81291c5ab6d45"}
{"url":"https://www.pyth.network/price-feeds","domain":"pyth.network","title":"The Price Layer for Global Finance | Pyth Network","text":"Real-Time Market Data for Every Asset ClassAccess prices across equities, commodities, FX, crypto, and more through one API. Full display rights and zero licensing fees.Free TrialContact the TeamOne API. Thousands of feeds. Markets that never stop.Pyth Pro gives institutions, applications, and AI systems direct 24/7 access to live price feeds across crypto, equities, FX, commodities, ETFs, rates, indices, and more.Full display rightsUse live market data across your products, platforms, and user experiences.No licensing feesGive users access without additional downstream licensing costs.CoverageAsset ClassesFigures as of September 2026.CommoditiesReal-time prices for oil, gas, and other essential commodities.189CryptoLive prices for major cryptocurrencies and tokens.827Pyth IndicesContinuous index pricing for equities, commodities, FX, metals, and thematic markets.55Funding RatesReal-time funding rates for perpetual futures and derivatives markets.15EquitiesStock prices from global equity markets.2,022FXForeign exchange rates for global currency pairs.299MetalsPrices for gold, silver, and other precious metals.44NAVNet Asset Values for funds and ETFs.12RatesInterest rates and yield benchmarks.40PublishersThe leading financial institutions in the world publish their data to Pyth Network, ensuring transparency, accuracy, and reliability.Get Startedfirst party dataNetwork at a GlanceFigures as of September 2026.+3,600Real-time price feeds138+Publishers and data providers114Connected blockchains720+Integration partnersconnect with usNeed custom coverage or institutional access?The Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":584,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259304379,"hash":"02f487482326cc35088bdc92997ba2d67b80b296"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/acl-manager","domain":"aave.com","title":"Access Control | Aave Protocol Documentation","text":"Access Control#\nReference for the aave-acl Move package.\nOverview#\nThe ACL Manager implements a role-based access control system where different addresses can be assigned specific roles that grant them permissions to perform certain actions within the Aave protocol. Each role has an admin role that controls who can grant or revoke that role.\nRoles#\nThe module defines several key roles that align with the Ethereum implementation:\n\nDEFAULT_ADMIN_ROLE: The highest-level administrative role.\n\nPOOL_ADMIN_ROLE: Can update token implementations, manage reserves, and more.\n\nEMERGENCY_ADMIN_ROLE: Can pause/unpause the pool or individual reserves.\n\nRISK_ADMIN_ROLE: Can update reserve parameters and risk settings.\n\nFLASH_BORROWER_ROLE: Has premium on flash loans waived.\n\nASSET_LISTING_ADMIN_ROLE: Can update oracle sources and add new assets.\n\nFUNDS_ADMIN_ROLE: Manages funds-related operations.\n\nEMISSION_ADMIN_ROLE: Manages emission-related settings.\n\nADMIN_CONTROLLED_ECOSYSTEM_RESERVE_FUNDS_ADMIN_ROLE: Manages ecosystem reserve funds.\n\nREWARDS_CONTROLLER_ADMIN_ROLE: Manages reward controllers.\n\nCore Functions#\nRole Management Functions#\ndefault_admin_role#\n#[view]public fun default_admin_role(): String\nReturns the identifier for the default admin role, which has the highest level of permissions in the system.\nget_role_admin#\n#[view]public fun get_role_admin(role: String): String\nReturns the admin role that controls a specific role. By default, all roles are controlled by the DEFAULT_ADMIN_ROLE.\nset_role_admin#\npublic fun set_role_admin(admin: &signer, role: String, admin_role: String)\nSets a new admin role for a specific role. Only addresses with the DEFAULT_ADMIN_ROLE can call this function.\nhas_role#\n#[view]public fun has_role(role: String, user: address): bool\nChecks if an address has a specific role.\ngrant_role#\npublic fun grant_role(admin: &signer, role: String, user: address)\nGrants a role to an address. Can only be called by an address that has the admin role for the role being granted.\nrenounce_role#\npublic entry fun renounce_role(admin: &signer, role: String, user: address)\nAllows an address to renounce a role it has been granted. The caller must be the same as the address renouncing the role.\nrevoke_role#\npublic fun revoke_role(admin: &signer, role: String, user: address)\nRevokes a role from an address. Can only be called by an address that has the admin role for the role being revoked.\nRole-Specific Management Functions#\nPool Admin Functions#\npublic entry fun add_pool_admin(admin: &signer, user: address)\npublic entry fun remove_pool_admin(admin: &signer, user: address)\n#[view]public fun is_pool_admin(admin: address): bool\nThese functions add, remove, and check if an address has the POOL_ADMIN_ROLE. Pool admins can update token implementations, manage reserves, and perform other high-level administrative actions.\nEmergency Admin Functions#\npublic entry fun add_emergency_admin(admin: &signer, user: address)\npublic entry fun remove_emergency_admin(admin: &signer, user: address)\n#[view]public fun is_emergency_admin(admin: address): bool\nThese functions manage the EMERGENCY_ADMIN_ROLE, which allows addresses to pause and unpause the pool or individual reserves in emergency situations.\nRisk Admin Functions#\npublic entry fun add_risk_admin(admin: &signer, user: address)\npublic entry fun remove_risk_admin(admin: &signer, user: address)\n#[view]public fun is_risk_admin(admin: address): bool\nThese functions manage the RISK_ADMIN_ROLE, which allows addresses to update reserve parameters, grace periods, and other risk-related settings.\nFlash Borrower Functions#\npublic entry fun add_flash_borrower(admin: &signer, borrower: address)\npublic entry fun remove_flash_borrower(admin: &signer, borrower: address)\n#[view]public fun is_flash_borrower(borrower: address): bool\nThese functions manage the FLASH_BORROWER_ROLE, which allows addresses to have the premium on flash loans waived.\nAsset Listing Admin Functions#\npublic entry fun add_asset_listing_admin(admin: &signer, user: address)\npublic entry fun remove_asset_listing_admin(admin: &signer, user: address)\n#[view]public fun is_asset_listing_admin(admin: address): bool\nThese functions manage the ASSET_LISTING_ADMIN_ROLE, which allows addresses to update oracle sources and add new assets to the Aave market.\nAdditional Admin Roles#\nThe module also includes functions for managing several other specialized roles:\nFunds Admin: Manages funds-related operationsEmission Admin: Manages emission-related settingsAdmin Controlled Ecosystem Reserve Funds Admin: Manages ecosystem reserve fundsRewards Controller Admin: Manages reward controllers\nRole Identifier Getter Functions#\n#[view]public fun get_pool_admin_role(): String\n#[view]public fun get_emergency_admin_role(): String\n#[view]public fun get_risk_admin_role(): String\n#[view]public fun get_flash_borrower_role(): String\n#[view]public fun get_asset_listing_admin_role(): String\n#[view]public fun get_funds_admin_role(): String\n#[view]public fun get_emission_admin_role(): String\n#[view]public fun get_admin_controlled_ecosystem_reserve_funds_admin_role(): String\n#[view]public fun get_rewards_controller_admin_role(): String\nThese functions are useful for getting the standardized string identifiers for each role when interacting with the ACL Manager.\nEvents#\nThe module emits events for key role management actions:\nRoleAdminChanged: Emitted when a role's admin role is changed.RoleGranted: Emitted when a role is granted to an address.RoleRevoked: Emitted when a role is revoked from an address.\nThese events allow for tracking changes to the access control system over time.\nSummary#\nThe Aave ACL Manager module provides a comprehensive role-based access control system for the Aave protocol on Aptos. It closely mirrors the functionality of the Ethereum implementation while leveraging Aptos's Move language features for enhanced safety and expressiveness.PreviousPoolNextPool Configurator","tokens":1489,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259308342,"hash":"65a247802854f617f7a0524d15e8b8ffe0522a7b"}
{"url":"https://docs.pyth.network/entropy/chainlist","domain":"docs.pyth.network","title":"Chainlist and Fee Details | Pyth Developer Hub","text":"Chainlist and Fee DetailsPyth Entropy contract addresses on EVM networksMainnets\nThe fees for mainnet are dynamically set. Always use the on-chain method\nentropy.getFeeV2() to get the current fee.\nThe following tables shows the total fees payable when using the default provider.\nNote that the fees shown below will vary over time with prevailing gas prices on each chain.\nThe Entropy contract is deployed on the following mainnet chains:\nChainContractReveal DelayDefault Gas LimitFeeabstract0x5a4a...b98c0e0 blocks5000000.000029006155 ETHapechain0x3682...39e3200 blocks5000000.223211589 APEarbitrum0x7698...20adac6 blocks25000000.000431605 ETHbase0x6e7d...6181bb1 block5000000.000015 ETHberachain0x3682...39e3201 block25000000.00125 BERAetherlink0x23f0...3d75091 block150000000.118 XTZhyperevm0xfa25...9566830 blocks5000000.001 HYPEkaia0x3682...39e3201 block5000000.1 KAIAkraken-ink0xd458...e6f1341 block5000000.000005000000000001 ETHmonad0xd458...e6f1341 block10000000.4 MONoptimism0xdf21...0538d52 blocks5000000.000015 ETHsoneium0x0708...14508b1 block5000000.000015 ETHsonic0x3682...39e3201 block5000000.8360000018 S\nThe default provider for above mainnet chains is 0x52DeaA1c84233F7bb8C8A45baeDE41091c616506.\nThe default provider on mainnet has a reveal delay to avoid changes on the outcome of the Entropy request because of block reorgs.\nThe reveal delay shows how many blocks should be produced after the block including the request transaction in order to reveal and submit a callback transaction.\nThe default provider fulfills the request by sending a transaction with a gas limit as mentioned in above table or as set by the user in the request.\nEntropy callbacks the consumer as part of this transaction.\nTestnets\nThe fees for testnets are kept deliberately low and different from the\nmainnet fees.\nThe Entropy contract is deployed on the following testnet chains:\nChainContractReveal DelayDefault Gas LimitFeeabstract-testnet0x8586...ff9e630 blocks5000000.000010501155000001 ETHapechain-testnet0x23f0...3d75090 blocks5000000.073211589000000001 APEarbitrum-sepolia0x549e...f614406 blocks25000000.000015 ETHbase-sepolia0x41c9...830d4c1 block5000000.000015000000000001 ETHberachain-bepolia0x3682...39e3201 block5000000.000015000000000001 BERAetherlink-testnet1 block150000000.05 ETHgiwa-testnet0x0708...14508b1 block5000000.000015000000000001 ETHhyperevm-testnet0x23f0...3d75092 blocks5000000.0006 HYPEkaia-testnet0x3682...39e3201 block5000000.200000000000000001 KAIAmonad-testnet0x825c...f93c072 blocks10000000.128159999999100001 MONoptimism-sepolia0x4821...9d70612 blocks5000000.000015000000000001 ETHsoneium-minato-testnet0x23f0...3d75091 block5000000.000015 ETHsonic-testnet1 block5000000.000015 ETH\nThe default provider for above testnet chains is 0x6CC14824Ea2918f5De5C2f75A9Da968ad4BD6344.\nThe default provider on testnet has reveal delays identical to the corresponding mainnet chains to ensure consistent environment.Transform Entropy ResultsBest practices for transforming entropy results in your applicationsRequest Callback VariantsDifferent ways to request random numbers with Pyth Entropy","tokens":778,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259314356,"hash":"c019aea68c162a3e4667493738fd511451f59ad8"}
{"url":"https://docs.pyth.network/entropy/generate-random-numbers-evm","domain":"docs.pyth.network","title":"Generate Random Numbers On-chain | Pyth Developer Hub","text":"Generate Random Numbers On-chainLearn how to integrate Pyth Entropy to generate random numbers in your dappThis guide explains how to integrate Pyth Entropy into EVM Contracts to generate on-chain random numbers.\nThe intended audience for this guide is developers of any application that needs on-chain randomness, such as NFT mints or games.\nInstall the SDK\nPyth Entropy has a Solidity SDK that lets your contract interact with the Entropy contract.\nInstall the SDK using your package manager:\nnpm install @pythnetwork/entropy-sdk-solidity\nSetup\nThe Solidity SDK exports two interfaces:\n\nIEntropyConsumer - The interface that your contract should implement. It makes sure that your contract is compliant with the Entropy contract.\nIEntropyV2 - The interface to interact with the Entropy contract.\nYou will need the address of an Entropy contract on your blockchain.\nConsult the current Entropy contract addresses to find the address on your chain.\nOnce you have a contract address, instantiate an console.log(\"IEntropyV2\") contract in your solidity contract:\n\ncode={`import { IEntropyConsumer } from \"@pythnetwork/entropy-sdk-solidity/IEntropyConsumer.sol\";\nimport { IEntropyV2 } from \"@pythnetwork/entropy-sdk-solidity/IEntropyV2.sol\";\n\n// @param entropyAddress The address of the entropy contract.\ncontract YourContract is IEntropyConsumer {\nIEntropyV2 public entropy;\n constructor(address entropyAddress) {\n entropy = IEntropyV2(entropyAddress);\n }\n}\nUsage\nTo generate a random number, follow these steps.\nRequest a number from EntropyInvoke the requestV2 method of the IEntropyV2 interface.\nThe console.log(\"requestV2\") method requires paying a fee in native gas tokens which is configured per-provider.The fee differs for every chain and also varies over time depending on the chain's current gas price.\nThe current value for each chain can be found on the chainlist and fee details page.\nHowever, you should use the on-chain method getFeeV2 to compute the required fee and send it as the value of the requestV2 call.These methods use the default randomness provider.function requestRandomNumber() external payable {\n uint256 fee = entropy.getFeeV2();\n uint64 sequenceNumber = entropy.requestV2{ value: fee }();\n}This method returns a sequence number and emits a Requested event. You can store this sequence number to identify the request in next step.Note that there are several variants of requestV2 that allow the caller to configure the provider fulfilling the request and the gas limit for the callback. Refer request callback variants for more details.Please see the method documentation in the IEntropyV2 interface.Implement the Entropy callbackpragma solidity ^0.8.0;\n\nimport { IEntropyConsumer } from \"@pythnetwork/entropy-sdk-solidity/IEntropyConsumer.sol\";\nimport { IEntropyV2 } from \"@pythnetwork/entropy-sdk-solidity/IEntropyV2.sol\";\n\ncontract YourContract is IEntropyConsumer {\nIEntropyV2 entropy;\n\n // @param entropyAddress The address of the entropy contract.\n constructor(address entropyAddress) {\n entropy = IEntropyV2(entropyAddress);\n }\n\n function requestRandomNumber() external payable {\n // Get the fee for the request\n uint256 fee = entropy.getFeeV2();\n\n // Request the random number with the callback\n uint64 sequenceNumber = entropy.requestV2{ value: fee }();\n // Store the sequence number to identify the callback request\n\n }\n\n // @param sequenceNumber The sequence number of the request.\n // @param provider The address of the provider that generated the random number. If your app uses multiple providers, you can use this argument to distinguish which one is calling the app back.\n // @param randomNumber The generated random number.\n // This method is called by the entropy contract when a random number is generated.\n // This method **must** be implemented on the same contract that requested the random number.\n // This method should **never** return an error -- if it returns an error, then the keeper will not be able to invoke the callback.\n // If you are having problems receiving the callback, the most likely cause is that the callback is erroring.\n // See the callback debugging guide here to identify the error https://docs.pyth.network/entropy/debug-callback-failures\n function entropyCallback(\n uint64 sequenceNumber,\n address provider,\n bytes32 randomNumber\n ) internal override {\n // Implement your callback logic here.\n }\n\n // This method is required by the IEntropyConsumer interface.\n // It returns the address of the entropy contract which will call the callback.\n function getEntropy() internal view override returns (address) {\n return address(entropy);\n }\n\n}\nWhen the final random number is ready to use, the entropyCallback function will be called by the Entropy contract. This will happen in a separate transaction submitted by the requested provider.\nThe entropyCallback function on your contract should never return an\nerror. If it returns an error, the keeper will not be able to invoke the\ncallback. If you are having problems receiving the callback, please see\nDebugging Callback Failures.\nAdditional Resources\nYou may find these additional resources helpful while integrating Pyth Entropy into your EVM contract.\nDebug Callback Failures\nCheck how to Debug Callback Failures if you are having trouble getting the callback to run.\nPyth Entropy Contract Addresses\nConsult the Entropy contract addresses to find the Entropy contract address on your chain.\nCurrent Fees\nCheck the chainlist and fee details to find the current fee for each provider on your chain.\nTransform Entropy Results\nCheck out the Transform Entropy Results guide for tips to limit gas usage, or generate multiple random numbers in a single transaction.\nRandomness providers\nSome methods on Entropy require selecting a randomness provider. The randomness provider is a third-party\nwho participates in the generation process. Each provider is identified by an address and hosts\na keeper service for fullfilling requests.\nYou can get the default provider's address by calling the getDefaultProvider method:\naddress provider = entropy.getDefaultProvider();Create your first Entropy app on EVMBuild a coin flip example using Pyth EntropySet Custom Gas LimitsHow to set custom gas limits for Entropy callbacks","tokens":1559,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259324363,"hash":"859edfb1290ec7f67a645df69cb4d63062d0bd6e"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/tokenization","domain":"aave.com","title":"Tokenization | Aave Protocol Documentation","text":"Tokenization#\nAToken#\naTokens are tokens minted and burnt upon supply and withdraw of assets to an Aave market. aTokens denote the amount of crypto assets supplied to the protocol and the yield earned on those assets. The aTokens’ value is pegged to the value of the corresponding supplied asset at a 1:1 ratio and can be safely stored, transferred or traded. All yield collected by the aTokens' reserves are distributed to aToken holders directly by continuously increasing their wallet balance.\nThis contract is the implementation of the interest bearing token for the Aave Protocol. It inherits the ScaledBalanceTokenBase and EIP712Base token contracts.\nAll standard EIP20 methods are implemented for aTokens, such as balanceOf, transfer, transferFrom, approve, totalSupply etc.\nbalanceOf will always return the most up to date balance of the user, which includes their principal balance and the yield generated by the principal balance.\nThe source code is available on GitHub.\nWrite Methods#\ninitialize#\nfunction initialize( IPool initializingPool, address treasury, address underlyingAsset, IAaveIncentivesController incentivesController, uint8 aTokenDecimals, string calldata aTokenName, string calldata aTokenSymbol, bytes calldata params) public virtual\nCalled when aToken instance is initialized.\nInput Parameters:#\nNameTypeDescriptioninitializingPoolIPoolThe address of the associated pooltreasuryaddressThe address of the treasuryunderlyingAssetaddressThe address of the underlying assetincentivesControllerIAaveIncentivesControllerThe address of the incentives controller for this aTokenaTokenDecimalsuint8The decimals of the underlying assetaTokenNamestringThe name of the aTokenaTokenSymbolstringThe symbol of the aTokenparamsbytesA set of encoded parameters for additional initialization\nmint#\nfunction mint( address caller, address onBehalfOf, uint256 amount, uint256 index) external virtual override onlyPool returns (bool)\nMints amount aTokens to user.\nInput Parameters:#\nNameTypeDescriptioncalleraddressThe address performing the mintonBehalfOfaddressThe address of the user that will receive the minted aTokensamountuint256The amount of tokens getting mintedindexuint256The next liquidity index of the reserve\nReturn Values:#\nTypeDescriptionbooltrue if the the previous balance of the user was 0\nburn#\nfunction burn( address from, address receiverOfUnderlying, uint256 amount, uint256 index) external virtual override onlyPool\nBurns aTokens from user and sends the equivalent amount of underlying to receiverOfUnderlying.\nIn some instances, the mint event could be emitted from a burn transaction if the amount to burn is less than the interest that the user accrued.\nInput Parameters:#\nNameTypeDescriptionfromaddressThe address from which the aTokens will be burnedreceiverOfUnderlyingaddressThe address that will receive the underlying assetamountuint256The amount of tokens that will be burnedindexuint256The next liquidity index of the reserve\nmintToTreasury#\nfunction mintToTreasury(uint256 amount, uint256 index) external override onlyPool\nMints aTokens to the reserve treasury.\nInput Parameters:#\nNameTypeDescriptionamountuint256The amount of tokens getting mintedindexuint256The address that will receive the underlying asset\ntransferOnLiquidation#\nfunction transferOnLiquidation( address from, address to, uint256 value) virtual override onlyPool\nTransfers aTokens in the event of a borrow being liquidated, in case the liquidator reclaims the aToken.\nInput Parameters:#\nNameTypeDescriptionfromaddressThe address getting liquidated, current owner of the aTokenstoaddressThe recipient of aTokensvalueuint256The amount of tokens getting transferred\ntransferUnderlyingTo#\nfunction transferUnderlyingTo(address target, uint256 amount) external virtual override onlyPool\nTransfers the underlying asset to target.\nUsed by the Pool to transfer assets in borrow(), withdraw() and flashLoan().\nInput Parameters:#\nNameTypeDescriptionuseraddressThe recipient of the underlyingamountuint256The amount getting transferred\nhandleRepayment#\nfunction handleRepayment(address user, address onBehalfOf, uint256 amount) external virtual override onlyPool\nHandles the underlying received by the aToken after the transfer has been completed.\nThe default implementation is empty as with standard ERC20 tokens, nothing needs to be done after the transfer is concluded. However in the future there may be aTokens that allow for example to stake the underlying to receive LM rewards. In that case, handleRepayment() would perform the staking of the underlying asset.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe user executing the repaymentonBehalfOfaddress`The address for which the borrow position is repaidamountuint256The amount getting repaid\npermit#\nfunction permit( address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external override\nAllows a user to permit another account (or contract) to use their funds using a signed message. This enables gas-less transactions and single approval/transfer transactions. Allow passing a signed message to approve spending.\nImplements the permit function as for EIP-2612.\nInput Parameters:#\nNameTypeDescriptionowneraddressThe owner of the fundsspenderaddressThe spender of the fundsvalueuint256The amount the spender is permitted to spenddeadlineuint256The deadline timestamp, use type(uint256).max for max/no deadlinevuint8The V signature parameterrbytes32The R signature parametersbytes32The S signature parameter\nExample of signing and utilizing permit:\nimport { signTypedData_v4 } from \"eth-sig-util\";import { fromRpcSig } from \"ethereumjs-util\";// ... other importsimport aTokenAbi from \"./aTokenAbi.json\";// ... setup your web3 providerconst aTokenAddress = \"ATOKEN_ADDRESS\";const aTokenContract = new web3.eth.Contract(aTokenAbi, aTokenAddress);const privateKey = \"YOUR_PRIVATE_KEY_WITHOUT_0x\";const chainId = 1;const owner = \"OWNER_ADDRESS\";const spender = \"SPENDER_ADDRESS\";const value = 100; // Amount the spender is permittedconst nonce = 1; // The next valid nonce, use `_nonces()`const deadline = 1600093162;const permitParams = { types: { EIP712Domain: [ { name: \"name\", type: \"string\" }, { name: \"version\", type: \"string\" }, { name: \"chainId\", type: \"uint256\" }, { name: \"verifyingContract\", type: \"address\" }, ], Permit: [ { name: \"owner\", type: \"address\" }, { name: \"spender\", type: \"address\" }, { name: \"value\", type: \"uint256\" }, { name: \"nonce\", type: \"uint256\" }, { name: \"deadline\", type: \"uint256\" }, ], }, primaryType: \"Permit\", domain: { name: \"aTOKEN_NAME\", version: \"1\", chainId: chainId, verifyingContract: aTokenAddress, }, message: { owner, spender, value, nonce, deadline, },};const signature = signTypedData_v4(Buffer.from(privateKey, \"hex\"), { data: permitParams,});// The signature can now be used to execute the transactionconst { v, r, s } = fromRpcSig(signature);await aTokenContract.methods .permit({ owner, spender, value, deadline, v, r, s, }) .send() .catch((e) => { throw Error(`Error permitting: ${e.message}`); });\nrescueTokens#\nfunction rescueTokens( address token, address to, uint256 amount) external override onlyPoolAdmin\nRescue and transfer tokens locked in this contract. Only callable by POOL_ADMIN.\nInput Parameters:#\nNameTypeDescriptiontokenaddressThe address of the tokentoaddressThe address of the recipientamountuint256The amount of token to transfer\nView Methods#\nbalanceOf#\nfunction balanceOf(address user) public view virtual override(IncentivizedERC20, IERC20) returns (uint256)\nReturns the amount of tokens owned by user.\nOverrides the base function.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:#\nTypeDescriptionuint256The amount of tokens owned by user\ntotalSupply#\nfunction totalSupply() public view virtual override(IncentivizedERC20, IERC20 returns (uint256)\nReturns the amount of tokens in existence.\nOverrides the base function.\nReturn Values:#\nTypeDescriptionuint256The amount of tokens in existence\nRESERVE_TREASURY_ADDRESS#\nfunction RESERVE_TREASURY_ADDRESS() external view override returns (address)\nReturns the address of the Aave treasury, controlled by governance, receiving the fees on this aToken.\nReturn Values:#\nTypeDescriptionaddressThe address of the Aave treasury\nUNDERLYING_ASSET_ADDRESS#\nfunction UNDERLYING_ASSET_ADDRESS() external view override returns (address)\nReturns the address of the underlying reserve asset of this aToken (E.g. WETH for aWETH).\nReturn Values:#\nTypeDescriptionaddressThe address of the underlying asset\nDOMAIN_SEPARATOR#\nfunction DOMAIN_SEPARATOR() public view override(IAToken, EIP712Base) returns (bytes32)\nGet the domain separator for the token at the current chain.\nReturn cached value if chainId matches cache, otherwise recomputes separator.\nOverrides the base function to fully implement IAToken.\nReturn Values:#\nTypeDescriptionbytes32The domain separator of the token at current chain\nnonces#\nfunction nonces(address owner) public view override(IAToken, EIP712Base) returns (uint256)\nReturns the nonce value for address specified as parameter. This is the nonce used when calling permit().\nOverrides the base function to fully implement IAToken.\nInput Parameters:#\nNameTypeDescriptionowneraddressThe address of the owner\nReturn Values:#\nTypeDescriptionuint256The nonce of the owner\nExample:\nconst token = new Contract(aTokenAddress, aToken.abi, provider);await token.nonces(user);\nPure Methods#\ngetRevision#\nfunction getRevision() internal pure virtual override returns (uint256)\nReturns the revision number of the contract. Needs to be defined in the inherited class as a constant.\nReturns 0x1.\nReturn Values:#\nTypeDescriptionuint256The revision number\nRwaAToken#\nRwaAToken is a specialized version of the AToken contract designed for Real-World Assets (RWAs). It represents a user's supplied collateral in the Aave Horizon market. To comply with regulatory requirements, RwaAToken instances are non-transferable by default for end-users.\nKey functionalities such as transfer, approve, and permit are disabled to prevent peer-to-peer movement of these tokens. Aave Horizon introduces an ATOKEN_ADMIN_ROLE, which can be granted to RWA issuers or their designated managers to manage functions such as wallet recovery or position migration. An address holding this role can execute authorized transfers on behalf of users, as detailed below.\nWrite Methods#\nauthorizedTransfer#\nfunction authorizedTransfer(address from, address to, uint256 amount) external returns (bool)\nTransfers an amount of aTokens between two users. This function can only be called by the RWAaTokenManager address holding the ATOKEN_ADMIN_ROLE to granularly manage aToken-specific transfers. It is intended for administrative actions, such as migrating a user's position to a new wallet. The transfer is still subject to the protocol's health factor checks.\nInput Parameters:#\nNameTypeDescriptionfromaddressThe address to transfer fromtoaddressThe address to transfer toamountuint256The amount of tokens to transfer\nReturn Values:#\nTypeDescriptionbooltrue if the transfer was successful\nmint#\nfunction mint( address caller, address onBehalfOf, uint256 amount, uint256 index) public virtual returns (bool)\nMints amount aTokens to a user. This function overrides the standard mint to enforce that the caller of the transaction must be the same as the onBehalfOf address. This effectively disables the supplyOnBehalfOf functionality for RWAs.\nInput Parameters:#\nNameTypeDescriptioncalleraddressThe address performing the mintonBehalfOfaddressThe address of the user that will receive the minted aTokensamountuint256The amount of tokens getting mintedindexuint256The next liquidity index of the reserve\nReturn Values:#\nTypeDescriptionbooltrue if the the previous balance of the user was 0\nPure Methods#\nATOKEN_ADMIN_ROLE#\nfunction ATOKEN_ADMIN_ROLE() external pure returns (bytes32)\nReturns the bytes32 identifier for the ATOKEN_ADMIN_ROLE. This role grants permission to call authorizedTransfer.\nReturn Values:#\nTypeDescriptionbytes32The identifier of the ATokenAdmin role\nNot Supported Operations#\nTo enforce the non-transferable and compliant nature of RWA collateral, most standard ERC20 interactions are disabled for RwaAToken. Calling any of the following functions will revert with an OPERATION_NOT_SUPPORTED error:\npermitapproveincreaseAllowancedecreaseAllowancetransfertransferFrommintToTreasurytransferOnLiquidationtransferUnderlyingTo\nStaticATokenFactory#\nThe StataTokenFactory is a factory and registry contract that manages all deployed StataToken instances for a specified Aave pool. It allows deploying new StataToken instances on demand and validates that there is only one StataToken instance per underlying asset. This contract maintains a mapping between underlying assets and their corresponding StataToken addresses.\nStataTokens are ERC-4626 compliant tokens that wrap Aave's aTokens to provide a non-rebasing yield accrual mechanism.\nThe source code is available on GitHub.\nWrite Methods#\ninitialize#\nfunction initialize() external initializer\nInitializes the StataTokenFactory contract. This function is part of the Initializable pattern and is required to initialize the contract after deployment. In this implementation, it does not perform any actions.\ncreateStataTokens#\nfunction createStataTokens(address[] memory underlyings) external returns (address[] memory)\nCreates new StataToken instances for the given underlying assets if they do not already exist. For each provided underlying asset, the function checks if a StataToken already exists. If it does, the existing StataToken address is returned. If not, it deploys a new StataToken for that underlying asset, registers it, and returns the new address.\nInput Parameters:#\nNameTypeDescriptionunderlyingsaddress[]An array of underlying asset addresses\nReturn Values:#\nTypeDescriptionaddress[]An array of StataToken addresses corresponding to the provided underlying assets\nEmits:#\nStataTokenCreated(address indexed stataToken, address indexed underlying) event for each new StataToken created.\nReverts:#\nNotListedUnderlying(address underlying) if the underlying asset is not listed in the Aave pool.\nView Methods#\ngetStataTokens#\nfunction getStataTokens() external view returns (address[] memory)\nReturns all StataToken instances deployed via this factory.\nReturn Values:#\nTypeDescriptionaddress[]An array of all StataToken contract addresses\ngetStataToken#\nfunction getStataToken(address underlying) external view returns (address)\nReturns the StataToken address for a given underlying asset.\nInput Parameters:#\nNameTypeDescriptionunderlyingaddressThe address of the underlying asset\nReturn Values:#\nTypeDescriptionaddressThe address of the corresponding StataToken; returns address(0) if not found\nPOOL#\nfunction POOL() external view returns (IPool)\nReturns the address of the Aave pool associated with this factory.\nReturn Values:#\nTypeDescriptionIPoolThe address of the associated Aave pool\nPROXY_ADMIN#\nfunction PROXY_ADMIN() external view returns (address)\nReturns the address of the proxy admin used for the StataToken proxies.\nReturn Values:#\nTypeDescriptionaddressThe address of the proxy admin\nTRANSPARENT_PROXY_FACTORY#\nfunction TRANSPARENT_PROXY_FACTORY() external view returns (ITransparentProxyFactory)\nReturns the address of the transparent proxy factory used for creating new StataToken proxies.\nReturn Values:#\nTypeDescriptionITransparentProxyFactoryThe address of the transparent proxy factory\nSTATA_TOKEN_IMPL#\nfunction STATA_TOKEN_IMPL() external view returns (address)\nReturns the address of the StataToken implementation used when deploying new StataToken instances.\nReturn Values:#\nTypeDescriptionaddressThe address of the StataToken implementation\nVariableDebtToken#\nImplements a variable debt token to track the borrowing positions of users at variable rate mode.\ntransfer and approve functionalities are disabled as variable debt tokens are non-transferable.\nThe vToken value is pegged 1:1 to the value of underlying borrowed asset and represents the current total amount owed to the protocol i.e. principal debt + interest accrued.\nThe VariableDebtToken contract inherits the DebtTokenBase and ScaledBalanceTokenBase token contracts.\nThe source code is available on GitHub.\nWrite Methods#\ninitialize#\nfunction initialize( IPool initializingPool, address underlyingAsset, IAaveIncentivesController incentivesController, uint8 debtTokenDecimals, string memory debtTokenName, string memory debtTokenSymbol, bytes calldata params) external virtual\nCalled when variableDebtToken instance is initialised.\nInput Parameters:#\nNameTypeDescriptioninitializingPoolIPoolThe pool contract that is initializing this contractunderlyingAssetaddressThe address of the underlying asset of this aToken (E.g. WETH for aWETH)incentivesControllerIAaveIncentivesControllerThe smart contract managing potential incentives distributiondebtTokenDecimalsuint8The decimals of the variableDebtToken, same as the underlying asset'sdebtTokenNamestringThe name of the variable debt tokendebtTokenSymbolstringThe symbol of the variable debt tokenparamsbytesA set of encoded parameters for additional initialization\nmint#\nfunction mint( address user, address onBehalfOf, uint256 amount, uint256 index) external virtual override onlyPool returns (bool, uint256)\nMints the variable debt token to the onBehalfOf address.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address receiving the borrowed underlying, being the delegatee in case of credit delegate, or same as onBehalfOf otherwiseonBehalfOfaddressThe address receiving the variable debt tokensamountuint256The amount of variable debt tokens to mintindexuint256The variable debt index of the reserve\nReturn Values:#\nTypeDescriptionbooltrue if the previous balance of the user is 0, false otherwiseuint256The scaled total debt of the reserve\nburn#\nfunction burn( address from, uint256 amount, uint256 index) external virtual override onlyPool returns (uint256)\nBurns user variable debt.\nIn some instances, a burn transaction will emit a mint event if the amount to burn is less than the interest that the user accrued.\nInput Parameters:#\nNameTypeDescriptionfromaddressThe address from which the debt will be burnedamountuint256The amount of debt tokens that will be burnedindexuint256The variable debt index of the reserve\nReturn Values:#\nTypeDescriptionuint256The scaled total debt of the reserve\nView Methods#\nUNDERLYING_ASSET_ADDRESS#\nfunction UNDERLYING_ASSET_ADDRESS() external view override returns (address)\nReturns the address of the underlying asset of this variableDebtToken (e.g. WETH for variableDebtWETH)\nReturn Values:#\nTypeDescriptionaddressThe address of the underlying asset\nbalanceOf#\nfunction balanceOf(address account) public view virtual override returns (uint256)\nReturns the amount of tokens owned by account - the most up to date accumulated debt (principal + interest) of the user.\nStandard ERC20 function.\nInput Parameters:#\nNameTypeDescriptionaccountaddressThe balance of this address\nReturn Values:#\nTypeDescriptionuint256The amount of tokens owned by account\ntotalSupply#\nfunction totalSupply() public view virtual override returns (uint256)\nReturns the amount of tokens in existence - the most up to date total debt accrued by all protocol users for that specific variable rate of debt token.\nStandard ERC20 function.\nReturn Values:#\nTypeDescriptionuint256The amount of tokens in existence\nPure Methods#\ngetRevision#\nfunction getRevision() internal pure virtual override returns (uint256)\nReturns the revision number of the contract. Needs to be defined in the inherited class as a constant.\nReturns 0x1.\nReturn Values:#\nTypeDescriptionuint256The revision number\nNOT SUPPORTED OPERATIONS#\nBeing non-transferrable, the variable debt token does not implement any of the standard ERC20 functions for transfer and allowance.\nThe following functions below will revert with the error code 80, OPERATION_NOT_SUPPORTED: transfer, allowance, approve, transferFrom, increaseAllowance, decreaseAllowance.PreviousIncentivesNextInterest Rate Strategy","tokens":5033,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259328772,"hash":"8f78f52a4d4ee5e056a1fb0c1e4d5799d63f2442"}
{"url":"https://docs.openzeppelin.com/tools/uikit","domain":"docs.openzeppelin.com","title":"OpenZeppelin UIKit | OpenZeppelin Docs","text":"OpenZeppelin UIKitOpen in ClaudeA modular React component library for building blockchain transaction interfaces. It is chain-agnostic, capability-driven, and designed for multi-ecosystem applications.\nSource code: OpenZeppelin UIKit is open-source. Browse the implementation, open issues, and contribute at github.com/OpenZeppelin/openzeppelin-ui.Live example: Explore a hosted demo of UIKit with ecosystem adapters at openzeppelin-ui.netlify.app.\nGetting StartedInstall packages, set up Tailwind, and render your first transaction form.ArchitectureUnderstand the layered package system, capability model, and runtime lifecycle.ComponentsBrowse UI primitives, blockchain-aware form fields, and renderer widgets.React IntegrationWire up providers, hooks, and wallet state management.Theming & StylingConfigure Tailwind v4 tokens, dark mode, and design customization.StoragePersist address aliases and app data with IndexedDB via the storage plugin system.\nWhat is OpenZeppelin UIKit?\nOpenZeppelin UIKit is a set of modular npm packages that provide everything needed to build rich blockchain UIs in React. Instead of a monolithic library, it ships as a layered stack from low-level types and utilities up to high-level form renderers and wallet integration.\nEach layer is independently installable. Use only the pieces you need: the type system for a headless integration, the component library for a design system, or the full renderer for turnkey transaction forms.\n\nPackages\nPackageDescriptionLayer@openzeppelin/ui-typesShared TypeScript type definitions: capabilities, schemas, form models1@openzeppelin/ui-utilsFramework-agnostic utilities: config, logging, validation, routing2@openzeppelin/ui-stylesCentralized Tailwind CSS 4 theme with OKLCH tokens and dark mode3@openzeppelin/ui-componentsReact UI primitives and blockchain-aware form fields (shadcn/ui based)4@openzeppelin/ui-reactReact context providers, runtime management, and wallet hooks5@openzeppelin/ui-rendererTransaction form rendering engine and contract state widgets6@openzeppelin/ui-storageIndexedDB storage abstraction with Dexie.js and address book plugin7\nKey Design Principles\nChain-agnostic core. UIKit packages never import chain-specific logic. Blockchain details are handled entirely by ecosystem adapter packages.\nCapability-driven, not monolithic. Instead of one large adapter interface, the system defines small, focused capabilities (addressing, query, execution, wallet, etc.) organized into tiers. Components request only the capabilities they need.\nPay for what you use. Install only the layers your app requires. A simple form builder can use just ui-types + ui-components. A full transaction dashboard can add ui-renderer + ui-react + ui-storage.\nMulti-ecosystem ready. A single app can support EVM, Stellar, Polkadot, and more simultaneously. The runtime system manages per-network adapter instances with proper lifecycle and disposal.\nEcosystem Adapter Integration\nUIKit connects to blockchains through ecosystem adapter packages, standalone packages that translate chain-specific operations into the shared capability model.\n\nRequirements\n\nNode.js >= 20.19.0\nReact 19\nTailwind CSS 4\n\nNext Steps\n\nGetting Started: Install, configure, and render your first form\nArchitecture: Deep dive into the capability model and runtime lifecycle\nBuilding an adapter: How chain-specific logic is decoupled from the UI\nBuilding an AdapterPrevious PageGetting StartedNext PageOn this pageWhat is OpenZeppelin UIKit?PackagesKey Design PrinciplesEcosystem Adapter IntegrationRequirementsNext Steps","tokens":893,"squid":"ink-security_audits","role":"Sentinel","at":1791259330966,"hash":"095bda652c66d49197bfeec5f2b491be03842b9d"}
{"url":"https://docs.pyth.network/entropy/whats-new-entropyv2","domain":"docs.pyth.network","title":"What's New in Entropy v2 | Pyth Developer Hub","text":"What's New in Entropy v2New features and improvements in Entropy v2Key Improvements\nPyth Entropy v2 brings new features and improvements that make random number generation more flexible, efficient, and easier to integrate.\n1. Multiple Request Variants\nEntropy v2 provides multiple ways to request random numbers:\n\nBasic Request: Simplest implementation with default settings\nCustom Gas Limit: Specify gas limits for complex callbacks\nCustom Provider: Choose specific entropy providers\nFull Control: Specify all parameters (provider, gas limit, user random number)\n\nEach of these request types is described in more detail with examples in Request Callback Variants.\n2. Enhanced Callback Status\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nPyth Dev-Forum Announcement provides more details on enhanced callback statuses.\n3. Entropy Explorer\nEntropy V2 includes a public Entropy Explorer, that lets teams easily track the status of their callbacks and re-request them if they fail on-chain.\nSee Entropy Explorer to search and debug your callbacks.\nMigration Guide\nIf you're upgrading from Entropy v1 to v2:\n\nUpdate your imports to use IEntropyV2.\nReplace request() calls with requestV2()\nUpdate fee calculation to use getFeeV2()\nTest thoroughly with the new interface\n\nBackward Compatibility\nEntropy v2 maintains backward compatibility with v1 for existing applications. However, we recommend migrating to v2 for new applications to take advantage of the improved features.EntropySecure, Verifiable Random Number Generator for EVM-based smart contractsCreate your first Entropy app on EVMBuild a coin flip example using Pyth Entropy","tokens":421,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259334356,"hash":"6d39af8621151cd4cac0e2800ff1b9d921336599"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/incentives","domain":"aave.com","title":"Incentives | Aave Protocol Documentation","text":"Incentives#\nReference for the aave-incentives Move package.\nThis documentation covers the Aave periphery modules for the Aptos Move implementation, focusing on incentives and related functionality.\nIncentives#\nThe incentives system in Aave allows for distributing rewards to users who supply or borrow assets in the protocol. The system is managed through several key modules that work together to configure, track, and distribute rewards.\nRewardsController#\nThe rewards_controller module is the main component for managing incentives in the Aave protocol. It handles the distribution of rewards to protocol participants who hold incentivized assets (aTokens or variableDebtTokens).\nUsers accrue rewards automatically when they hold these tokens without needing to stake or lock their assets. The rewards can be claimed through various functions that provide flexibility in how rewards are collected.\nKey Structures#\nstruct RewardsConfigInput has store, drop { emission_per_second: u128, total_supply: u256, distribution_end: u32, asset: address, reward: address, pull_rewards_transfer_strategy: Object<PullRewardsTransferStrategy>}\nThis structure defines the configuration for a reward emission, including:\n\nemission_per_second: The rate at which rewards are distributed\n\ntotal_supply: The total supply of the asset being incentivized\n\ndistribution_end: When the reward distribution ends\n\nasset: The address of the asset being incentivized (aToken or variableDebtToken)\n\nreward: The address of the reward token\n\npull_rewards_transfer_strategy: The strategy for transferring rewards\n\nWrite Methods#\nconfigure_assets#\npublic(friend) fun configure_assets( config_inputs: vector<RewardsConfigInput>, rewards_controller_address: address)\nConfigures assets to incentivize with an emission of rewards per second until the end of distribution.\nset_pull_rewards_transfer_strategy#\npublic(friend) fun set_pull_rewards_transfer_strategy( reward: address, strategy: Object<PullRewardsTransferStrategy>, rewards_controller_address: address)\nSets a transfer strategy for a specific reward token that determines how rewards are transferred to users.\nhandle_action#\n// This function is called when users perform actions like supply, withdraw,// transfer, etc. to update reward calculationspublic(friend) fun handle_action( asset: address, user: address, total_supply: u256, user_balance: u256, rewards_controller_address: address)\nCalled when a user performs an action that affects their balance of an incentivized asset, updating the rewards distribution accordingly.\nclaim_rewards#\n// Internal implementation for claiming rewardsfun claim_rewards_internal( assets: vector<address>, amount: u256, claimer: address, user: address, to: address, reward: address, rewards_controller_address: address): u256\nClaims rewards for a user on specific assets, with the rewards sent to a designated address.\nclaim_all_rewards#\n// Internal implementation for claiming all rewardsfun claim_all_rewards_internal( assets: vector<address>, claimer: address, user: address, to: address, rewards_controller_address: address): (vector<address>, vector<u256>)\nClaims all available rewards for a user across specified assets, returning the list of reward tokens and amounts claimed.\nView Methods#\nget_pull_rewards_transfer_strategy#\npublic fun get_pull_rewards_transfer_strategy( reward: address, rewards_controller_address: address): Option<Object<PullRewardsTransferStrategy>>\nget_rewards_data#\npublic fun get_rewards_data( asset: address, reward: address, rewards_controller_address: address): (u256, u256, u256, u256)\nReturns reward data for a specific asset and reward token, including emission rates and distribution end time.\nget_user_asset_index#\n// Used to get the user's index for a specific asset and rewardpublic fun get_user_asset_index( user: address, asset: address, reward: address, rewards_controller_address: address): u256\nReturns the user's index for a specific asset and reward, used for calculating accrued rewards.\nget_user_accrued_rewards#\n// Used to get the user's accrued rewards for a specific reward tokenpublic fun get_user_accrued_rewards( user: address, reward: address, rewards_controller_address: address): u256\nReturns the amount of rewards accrued by a user for a specific reward token.\nEmissionManager#\nThe emission_manager module manages the configuration of reward emissions and acts as an administrative layer above the rewards_controller.\nKey Functions#\nconfigure_assets#\npublic entry fun configure_assets( account: &signer, emissions_per_second: vector<u128>, total_supplies: vector<u256>, distribution_ends: vector<u32>, assets: vector<address>, rewards: vector<address>, pull_rewards_transfer_strategies: vector<Object<PullRewardsTransferStrategy>>)\nConfigures assets for incentives, creating reward configurations and passing them to the rewards controller.\nset_pull_rewards_transfer_strategy#\npublic entry fun set_pull_rewards_transfer_strategy( caller: &signer, reward: address, pull_rewards_transfer_strategy: Object<PullRewardsTransferStrategy>)\nSets the transfer strategy for a specific reward token.\nset_distribution_end#\npublic entry fun set_distribution_end( caller: &signer, asset: address, reward: address, new_distribution_end: u32)\nUpdates the end time for a reward distribution on a specific asset.\nset_emission_admin#\n// Sets the admin for a specific reward tokenpublic entry fun set_emission_admin( account: &signer, reward: address, new_admin: address)\nSets the address that has permission to configure emissions for a specific reward token.\nView Methods#\nget_rewards_controller#\npublic fun get_rewards_controller(): address\nReturns the address of the rewards controller.\nget_emission_admin#\npublic fun get_emission_admin(reward: address): address\nReturns the admin address for a specific reward token.\nTransferStrategy#\nThe transfer_strategy module defines how rewards are transferred to users when they claim them.\nPullRewardsTransferStrategy#\nstruct PullRewardsTransferStrategy has key { rewards_admin: address, incentives_controller: address, rewards_vault: SignerCapability}\nThis strategy pulls rewards from a vault resource account to the recipient address.\nKey Functions#\npull_rewards_transfer_strategy_perform_transfer#\npublic(friend) fun pull_rewards_transfer_strategy_perform_transfer( incentives_controller: address, to: address, reward: address, amount: u256, strategy: Object<PullRewardsTransferStrategy>): bool\nTransfers rewards from the vault to the recipient.\nView Methods#\npull_rewards_transfer_strategy_get_incentives_controller#\npublic fun pull_rewards_transfer_strategy_get_incentives_controller( strategy: Object<PullRewardsTransferStrategy>): address\nReturns the incentives controller address associated with the strategy.\npull_rewards_transfer_strategy_get_rewards_admin#\npublic fun pull_rewards_transfer_strategy_get_rewards_admin( strategy: Object<PullRewardsTransferStrategy>): address\nReturns the rewards admin address for the strategy.\npull_rewards_transfer_strategy_get_rewards_vault#\npublic fun pull_rewards_transfer_strategy_get_rewards_vault( strategy: Object<PullRewardsTransferStrategy>): address\nReturns the address of the rewards vault.\nUI Incentive Data Provider#\nThe ui_incentive_data_provider_v3 module provides view functions to query incentive data for UI display.\nKey Structures#\nstruct AggregatedReserveIncentiveData has store, drop { underlying_asset: address, a_incentive_data: IncentiveData, v_incentive_data: IncentiveData}\nstruct IncentiveData has store, drop { token_address: address, incentive_controller_address: address, rewards_token_information: vector<RewardInfo>}\nstruct RewardInfo has store, drop { reward_token_symbol: String, reward_token_address: address, emission_per_second: u256, // Additional fields...}\nView Methods#\nget_reserves_incentives_data#\npublic fun get_reserves_incentives_data(): vector<AggregatedReserveIncentiveData>\nReturns incentive data for all reserves in the protocol, including information about reward tokens, emission rates, and other parameters.\nget_user_reserves_incentives_data#\npublic fun get_user_reserves_incentives_data(user: address): vector<UserReserveIncentiveData>\nReturns incentive data specific to a user, including their accrued rewards and other user-specific incentive information.\nCollector#\nThe collector module manages the collection and distribution of protocol fees.\nKey Functions#\ndeposit#\npublic fun deposit(sender: &signer, fa: FungibleAsset)\nDeposits fungible assets into the collector.\nwithdraw#\npublic fun withdraw( sender: &signer, asset_metadata: Object<Metadata>, receiver: address, amount: u64)\nWithdraws assets from the collector to a specified receiver.\nView Methods#\nget_collected_fees#\npublic fun get_collected_fees(asset_metadata: Object<Metadata>): u64\nReturns the amount of fees collected for a specific asset.\nCoinMigrator#\nThe coin_migrator module provides functionality to convert between Coin and FungibleAsset representations.\nView Methods#\nget_fa_address#\npublic fun get_fa_address<CoinType>(): address\nReturns the address of the fungible asset associated with a specific coin type.\nget_fa_balance#\nfun get_fa_balance<CoinType>(owner: address): u64\nReturns the fungible asset balance for a specific coin type and owner.\nUI Pool Data Provider#\nThe ui_pool_data_provider_v3 module provides view functions to query pool data for UI display.\nView Methods#\nget_reserves_list#\npublic fun get_reserves_list(): vector<address>\nReturns the list of all reserves in the protocol.\nget_reserves_data#\npublic fun get_reserves_data(): (vector<AggregatedReserveData>, BaseCurrencyInfo)\nReturns detailed data about all reserves in the protocol, including configuration, rates, and other parameters.\nget_user_reserves_data#\npublic fun get_user_reserves_data(user: address): (vector<UserReserveData>, u8)\nReturns data about a user's positions in the protocol, including balances and configuration.PreviousTokenizationNextIntegrations","tokens":2492,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259338893,"hash":"46946c6ab32b591272d2352eec66903420693029"}
{"url":"https://docs.openzeppelin.com/tools/uikit/storage","domain":"docs.openzeppelin.com","title":"Storage | OpenZeppelin Docs","text":"UIKitStorageOpen in Claude@openzeppelin/ui-storage provides client-side persistence for UIKit applications. It is built on Dexie.js (an IndexedDB wrapper) and ships a plugin system for extending storage with domain-specific functionality.\nInstallation\npnpm add @openzeppelin/ui-storage\nWhy Use the Storage Plugin?\nBrowser applications commonly reach for localStorage to persist user data. While fine for a handful of string values, localStorage hits hard limits as your app grows:\nConcernlocalStorage@openzeppelin/ui-storage (IndexedDB)Storage quota~5 MB per originHundreds of MB, often limited only by available disk spaceData modelFlat key-value strings; every read/write requires JSON.parse/JSON.stringifyStructured object stores with typed records, indexes, and compound queriesPerformanceSynchronous: blocks the main thread on every callAsynchronous: all reads and writes are non-blockingQueryingFull-scan only; no way to filter or sort without loading everythingIndexed lookups and range queries via Dexie.jsConcurrent tabsNo built-in synchronization; race conditions on simultaneous writesTransactional; supports multi-tab coordination out of the boxSchema evolutionManual: you must handle migrations yourselfDeclarative versioned schemas with automatic upgrade migrations\nBeyond these raw IndexedDB advantages, the storage plugin adds an opinionated layer designed for blockchain UIs:\n\nTyped base classes: EntityStorage<T> and KeyValueStorage give you CRUD, validation, quota handling, and timestamps without boilerplate.\nPlugin system: domain-specific plugins (like the built-in account alias plugin) drop into any Dexie database and integrate with UIKit providers automatically.\nReactive hooks: useLiveQuery re-renders components when the underlying IndexedDB data changes, including changes from other browser tabs.\nQuota-safe writes: the withQuotaHandling wrapper catches QuotaExceededError and surfaces a typed error code so your UI can handle it gracefully instead of silently failing.\n\nWhen Does It Make Sense?\nUse @openzeppelin/ui-storage when your application needs to persist structured, queryable data on the client, especially data that grows over time or must survive page reloads. Common examples include:\n\nContract history and recent contracts: the Role Manager persists recently accessed contracts per network in a RecentContractsStorage built on EntityStorage. Records are indexed by [networkId+address] for fast lookups and sorted by lastAccessed so the most recent entries always appear first. The same result in localStorage would require deserializing, sorting, and re-serializing an entire array.\n\nUI configuration and form state: the UI Builder stores complete contract UI configurations (including large ABIs and compiled contract definitions) in a ContractUIStorage entity store. With records that can reach tens of megabytes, localStorage's 5 MB limit would be a non-starter. The storage plugin also powers the builder's import/export and multi-tab auto-save features.\n\nUser preferences and settings: both projects use KeyValueStorage for simple typed preferences (theme, active network, page size), a lightweight alternative that still benefits from async I/O and schema versioning.\n\nAddress book and aliases: the built-in account alias plugin persists address-to-name mappings in IndexedDB and wires them into UIKit's AddressLabelProvider and AddressSuggestionProvider. Every AddressDisplay and AddressField in the component tree resolves labels automatically without any per-component wiring.\n\nIf your app only stores a single flag or token, localStorage is perfectly adequate. Reach for the storage plugin when you need indexed queries, large payloads, multi-tab safety, or domain-specific persistence that integrates with the rest of the UIKit ecosystem.\nCore Abstractions\nThe package exposes two base classes that your application can extend:\nClassDescriptionEntityStorage<T>Generic IndexedDB store for typed entities. Handles create, read, update, delete, and query.KeyValueStorageSimple key-value store backed by IndexedDB. Useful for persisting settings and preferences.\nBoth classes wrap a Dexie database instance and can be composed with plugins.\nAccount Alias Plugin\nThe built-in account alias plugin persists address-to-name mappings. It powers the AddressBookWidget and integrates with AddressLabelProvider and AddressSuggestionProvider to resolve human-readable labels automatically across all AddressDisplay and AddressField components.\nSetup\nCreate a Dexie database instance with the alias schema, then use the provided hooks:\nimport {\n createDexieDatabase,\n ALIAS_SCHEMA,\n useAliasLabelResolver,\n useAliasSuggestionResolver,\n useAddressBookWidgetProps,\n} from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\n\nconst db = createDexieDatabase(new Dexie('my-app'), ALIAS_SCHEMA);\nIntegration with Address Providers\nMount the providers near the root of your app to activate automatic label resolution. The useAliasLabelResolver and useAliasSuggestionResolver hooks return props that can be spread directly into the respective providers:\nimport {\n AddressLabelProvider,\n AddressSuggestionProvider,\n} from '@openzeppelin/ui-components';\nimport {\n createDexieDatabase,\n ALIAS_SCHEMA,\n useAliasLabelResolver,\n useAliasSuggestionResolver,\n} from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\n\nconst db = createDexieDatabase(new Dexie('my-app'), ALIAS_SCHEMA);\n\nfunction App() {\n const labelResolver = useAliasLabelResolver(db);\n const suggestionResolver = useAliasSuggestionResolver(db);\n\n return (\n <AddressLabelProvider {...labelResolver}>\n <AddressSuggestionProvider {...suggestionResolver}>\n <YourApp />\n </AddressSuggestionProvider>\n </AddressLabelProvider>\n );\n}\nOnce mounted:\n\nEvery AddressDisplay in the subtree automatically shows the saved alias instead of the raw address.\nEvery AddressField shows autocomplete suggestions as the user types.\n\nAddressBookWidget\nWire AddressBookWidget using the useAddressBookWidgetProps hook, which returns all the props the widget needs:\nimport { AddressBookWidget } from '@openzeppelin/ui-renderer';\nimport { createDexieDatabase, ALIAS_SCHEMA, useAddressBookWidgetProps } from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\n\nconst db = createDexieDatabase(new Dexie('my-app'), ALIAS_SCHEMA);\n\nfunction AddressBook({ addressing }) {\n const widgetProps = useAddressBookWidgetProps(db, { networkId: 'ethereum-mainnet' });\n\n return (\n <AddressBookWidget\n {...widgetProps}\n addressing={addressing}\n />\n );\n}\nSee Components (AddressBookWidget) for a screenshot.\nCustom Entity Stores\nExtend EntityStorage to create typed stores for your own domain objects. The constructor takes a Dexie database instance and a table name:\nimport { EntityStorage, createDexieDatabase } from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\n\ninterface SavedContract {\n id: string;\n address: string;\n name: string;\n networkId: string;\n addedAt: number;\n}\n\nconst MY_SCHEMA = { contracts: '++id, address, networkId' };\nconst db = createDexieDatabase(new Dexie('my-app'), MY_SCHEMA);\n\nclass ContractStore extends EntityStorage<SavedContract> {\n constructor() {\n super(db, 'contracts');\n }\n\n async findByNetwork(networkId: string): Promise<SavedContract[]> {\n return this.query((item) => item.networkId === networkId);\n }\n}\n\nconst contractStore = new ContractStore();\nawait contractStore.add({ id: '...', address: '0x...', name: 'My Token', networkId: 'ethereum-mainnet', addedAt: Date.now() });\nKey-Value Store\nUse KeyValueStorage for simple settings and flags. Like EntityStorage, it takes a Dexie db instance and a table name:\nimport { KeyValueStorage, createDexieDatabase } from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\n\nconst MY_SCHEMA = { settings: 'key' };\nconst db = createDexieDatabase(new Dexie('my-app'), MY_SCHEMA);\n\nclass AppSettings extends KeyValueStorage<string> {\n constructor() {\n super(db, 'settings');\n }\n}\n\nconst settings = new AppSettings();\nawait settings.set('theme', 'dark');\nconst theme = await settings.get('theme'); // 'dark'\nReact Hook Factories\nThe storage package ships a set of factory functions that turn any EntityStorage or KeyValueStorage into a fully reactive React hook, complete with live queries, CRUD wrappers, and file import/export. These are the recommended way to consume storage in React components.\ncreateRepositoryHook\nThe main factory. It composes the lower-level factories below into a single hook that provides everything a component needs: live data, loading state, CRUD operations, and optional file I/O.\nimport { createRepositoryHook, createDexieDatabase, EntityStorage } from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\nimport { toast } from 'sonner';\n\ninterface Bookmark { id: string; url: string; label: string; }\n\nconst SCHEMA = { bookmarks: '++id, url' };\nconst db = createDexieDatabase(new Dexie('my-app'), [{ version: 1, stores: SCHEMA }]);\n\nclass BookmarkStore extends EntityStorage<Bookmark> {\n constructor() { super(db, 'bookmarks'); }\n async exportJson() { return JSON.stringify(await this.getAll()); }\n async importJson(json: string) { /* parse and bulk-insert */ }\n}\n\nconst bookmarkStore = new BookmarkStore();\n\nconst useBookmarks = createRepositoryHook<Bookmark, BookmarkStore>({\n db,\n tableName: 'bookmarks',\n repo: bookmarkStore,\n onError: (title, err) => toast.error(title),\n fileIO: {\n exportJson: () => bookmarkStore.exportJson(),\n importJson: (json) => bookmarkStore.importJson(json),\n filePrefix: 'bookmarks-backup',\n },\n});\n\nfunction BookmarkList() {\n const { records, isLoading, save, remove, exportAsFile, importFromFile } = useBookmarks();\n\n if (isLoading) return <p>Loading…</p>;\n\n return (\n <ul>\n {records?.map((b) => (\n <li key={b.id}>\n {b.label} <button onClick={() => remove(b.id)}>Delete</button>\n </li>\n ))}\n </ul>\n );\n}\nThe hook returned by createRepositoryHook exposes:\nPropertyTypeDescriptionrecordsT[] | undefinedLive query result; undefined while loadingisLoadingbooleantrue until the first query resolvessave(record) => Promise<string>Insert a new recordupdate(id, partial) => Promise<void>Patch an existing recordremove(id) => Promise<void>Delete by IDclear() => Promise<void>Remove all recordsexportAsFile(ids?) => Promise<void>Download records as a timestamped JSON file (only when fileIO is configured)importFromFile(file) => Promise<string[]>Import from a JSON File (only when fileIO is configured)\nLower-Level Factories\ncreateRepositoryHook is built from three smaller factories that can be used independently when you need finer-grained control:\nFactoryPurposecreateLiveQueryHook(db, tableName, query?)Returns a hook that re-renders whenever the underlying Dexie table changes. Powered by useLiveQuery from dexie-react-hooks.createCrudHook(repo, { onError? })Wraps a CrudRepository (anything with save, update, delete, clear) with unified error handling.createJsonFileIO({ exportJson, importJson }, { filePrefix, onError? })Produces exportAsFile / importFromFile functions that handle Blob creation, download triggers, file reading, and JSON validation.\ncreateLiveQueryHook\nimport { createLiveQueryHook, createDexieDatabase } from '@openzeppelin/ui-storage';\n\nconst useContracts = createLiveQueryHook<SavedContract>(db, 'contracts');\n\nfunction ContractList() {\n const contracts = useContracts(); // undefined while loading, then T[]\n return <ul>{contracts?.map((c) => <li key={c.id}>{c.name}</li>)}</ul>;\n}\nPass an optional query function for filtered or sorted results:\nconst useRecentContracts = createLiveQueryHook<SavedContract>(\n db,\n 'contracts',\n (table) => table.orderBy('addedAt').reverse().limit(10).toArray(),\n);\ncreateCrudHook\nimport { createCrudHook } from '@openzeppelin/ui-storage';\n\nconst useContractCrud = createCrudHook<SavedContract>(contractStore, {\n onError: (title, err) => console.error(title, err),\n});\n\nfunction AddButton() {\n const { save } = useContractCrud();\n return <button onClick={() => save({ url: '...', label: 'My Contract' })}>Add</button>;\n}\ncreateJsonFileIO\nimport { createJsonFileIO } from '@openzeppelin/ui-storage';\n\nconst { exportAsFile, importFromFile } = createJsonFileIO(\n { exportJson: () => store.exportJson(), importJson: (json) => store.importJson(json) },\n { filePrefix: 'my-data', onError: (title, err) => toast.error(title) },\n);\n\n// exportAsFile() triggers a browser download of \"my-data-2026-04-09.json\"\n// importFromFile(file) reads a File, validates JSON, and calls importJson()\nNext Steps\n\nComponents: UI components that consume storage plugins\nReact Integration: Wire up providers and wallet state\nTheming & StylingPrevious PageOverviewNext PageOn this pageInstallationWhy Use the Storage Plugin?When Does It Make Sense?Core AbstractionsAccount Alias PluginSetupIntegration with Address ProvidersAddressBookWidgetCustom Entity StoresKey-Value StoreReact Hook FactoriescreateRepositoryHookLower-Level FactoriescreateLiveQueryHookcreateCrudHookcreateJsonFileIONext Steps","tokens":3235,"squid":"ink-security_audits","role":"Sentinel","at":1791259341117,"hash":"f995eec1fef10b513d566a60e7d88f24243a7c18"}
{"url":"https://docs.pyth.network/entropy/create-your-first-entropy-app","domain":"docs.pyth.network","title":"Create your first Entropy app on EVM | Pyth Developer Hub","text":"Create your first Entropy app on EVMBuild a coin flip example using Pyth EntropyIn this tutorial we will implement and deploy a coin flip contract which will use entropy to generate a random output.\nPreliminaries\nBefore we start, please make sure you have the following tools installed:\n\nFoundry.\nNode. Run node -v to confirm. You should get an output with version >= v18.0.0.\n\nGetting Started\nCreate a directory named coin-flip in your filesystem:\nmkdir coin-flip\ncd coin-flip\nLet's initialize a new project in coin-flip by running forge init contracts:\nforge init contracts\nThis will create a new directory in coin-flip named contracts/src, which will contain the smart contract code.\nWe will use this directory as the working directory for the rest of the tutorial.\nNow we will install the Pyth Entropy SDK in the contracts directory:\ncd contracts\nnpm init -y\nnpm install @pythnetwork/entropy-sdk-solidity\nAdd a remappings.txt file to contracts directory with the following content to tell Foundry where to find the Pyth Entropy SDK:\n@pythnetwork/entropy-sdk-solidity/=node_modules/@pythnetwork/entropy-sdk-solidity\nImplementation\nCreate a new file CoinFlip.sol in contracts/src directory and add the following code into it to start:\n// contracts/src/CoinFlip.sol\n// SPDX-License-Identifier: UNLICENSED\npragma solidity ^0.8.13;\n\nimport \"@pythnetwork/entropy-sdk-solidity/IEntropyV2.sol\";\nimport \"@pythnetwork/entropy-sdk-solidity/IEntropyConsumer.sol\";\n\ncontract CoinFlip is IEntropyConsumer {\n event FlipRequested(uint64 sequenceNumber);\n event FlipResult(uint64 sequenceNumber, bool isHeads);\n\n IEntropyV2 entropy;\n\n constructor(address \\_entropy) {\n entropy = IEntropyV2(\\_entropy);\n }\n\n // This method is required by the IEntropyConsumer interface\n function getEntropy() internal view override returns (address) {\n return address(entropy);\n }\n}\n\nThe code implements aCoinFlip contract which inherits the IEntropyConsumer interface.\nWe have also defined some events, properties and a constructor to instantiate the contract.\nOne of the properties is of type IEntropyV2 which is an interface imported from the Entropy SDK.\nRequest a coin flip\nCopy the following code into CoinFlip.sol:\ncontract CoinFlip {\n // ... prior code omitted\n\nfunction request() external payable {\n// get the required fee\nuint128 requestFee = entropy.getFeeV2();\n// check if the user has sent enough fees\nif (msg.value < requestFee) revert(\"not enough fees\");\n\n // pay the fees and request a random number from entropy\n uint64 sequenceNumber = entropy.requestV2{ value: requestFee }();\n\n // emit event\n emit FlipRequested(sequenceNumber);\n }\n}\nUsers will invoke the request method to initiate a coin flip, paying a fee in the process.\nThe method first retrieves the fee required to request a random number from Entropy.\nIt then includes the fee in the requestV2 method call to Entropy.\nFinally, the method emits a FlipRequested event with a sequenceNumber. This event is also defined in the code snippet above.\nHandle the callback\nCopy the following code into CoinFlip.sol:\ncontract CoinFlip {\n // ... prior code omitted\n\nfunction entropyCallback(\n uint64 sequenceNumber,\n // If your app uses multiple providers, you can use this argument\n // to distinguish which one is calling the app back. This app only\n // uses one provider so this argument is not used.\n address \\_providerAddress,\n bytes32 randomNumber\n ) internal override {\n bool isHeads = uint256(randomNumber) % 2 == 0;\n emit FlipResult(sequenceNumber, isHeads);\n }\n}\n\nImplement entropyCallback method which is required by the IEntropyConsumer Interface. Entropy calls back this method to fulfill a request. Entropy will call back this\nmethod with the sequenceNumber of the request, the _providerAddress from which the random number was requested and the generated randomNumber.\nFinally, the method emits a FlipResult event with the result of the flip.\nYay! you have successfully implemented a coin flip contract.\nDeploy\nFirst, create a new wallet:\ncast wallet new\nThis command will generate a new Ethereum keypair, producing output similar to the following. Note that the address and private key will be different hexadecimal values:\nSuccessfully created new keypair.\nAddress: 0xB806824fdA4b2b6631e9B87a86d42C9dfd04D129\nPrivate key: 0x0d510c72fd2279155c717eb433ae598a83cfb34b09c2ada86bc424b481082023\nWe will export the values from the command above as environment variables to simplify the commands below. We will also export the RPC URL of the network. Run the following commands in your shell substituting the address and private key in the indicated places:\nexport ADDRESS=<address from above>\nexport PRIVATE_KEY=<your private key from above>\nexport RPC_URL=\"https://sepolia.optimism.io\"\nNext, use the Superchain Faucet to claim some test Sepolia ETH. Paste the address from the command above into the faucet to get your ETH. You can verify that the ETH has arrived in your wallet by running the command\ncast balance $ADDRESS -r $RPC_URL -e\nThe final step before deploying is to get the arguments for the contract's constructor: the Entropy contract address for Optimism Sepolia and the Provider address. We will also export these values as environment variables for convenience:\nexport ENTROPY_ADDRESS=0x4821932D0CDd71225A6d914706A621e0389D7061\nFinally, let's deploy the contracts. Run the following command:\nforge create src/CoinFlip.sol:CoinFlip \\\n--private-key $PRIVATE_KEY \\\n--rpc-url $RPC_URL \\\n--constructor-args $ENTROPY_ADDRESS\nYou should see an output similar to:\n[⠢] Compiling...\n[⠔] Compiling 28 files with 0.8.23\n[⠑] Solc 0.8.23 finished in 3.40s\nCompiler run successful!\nDeployer: 0xfa57d0f2CBDA2729273F2a431E4FeDAc656d0402\nDeployed to: 0x8676ba0Dd492AB9813BC21D5Dce318427d1d73ae\nTransaction hash: 0x2178aa6d402c94166a93e81822248d00dd003827675ebd49b3c542970f5a0189\nLet's export the coin flip contract address as environment variable for later use:\nexport COINFLIP_ADDRESS=<Deployed to address from above>\nCongratulations you have successfully implemented and deployed a CoinFlip contract.\nInteract from Javascript\nNext, let's interact with the CoinFlip contract from Javascript. Create a new directory inside coin-flip named app. Run cd app to make it your terminal’s working directory — the following commands will need to be run from here.\nRun the following to initialise a new project and install required libraries:\nnpm init -y\nnpm install web3 @pythnetwork/entropy-sdk-solidity\nCreate a script.js file in app and add the following code to the script:\nconst { Web3 } = require(\"web3\");\nconst CoinFlipAbi = require(\"../contracts/out/CoinFlip.sol/CoinFlip.json\");\nconst EntropyAbi = require(\"@pythnetwork/entropy-sdk-solidity/abis/IEntropyV2.json\");\n\nasync function main() {\n const web3 = new Web3(process.env[\"RPC_URL\"]);\n const { address } = web3.eth.accounts.wallet.add(\n process.env[\"PRIVATE_KEY\"],\n )[0];\n\n web3.eth.defaultBlock = \"finalized\";\n\n const coinFlipContract = new web3.eth.Contract(\n CoinFlipAbi.abi,\n process.env[\"COINFLIP_ADDRESS\"],\n );\n\n const entropyContract = new web3.eth.Contract(\n EntropyAbi,\n process.env[\"ENTROPY_ADDRESS\"],\n );\n}\n\nmain();\nThe code above imports the required libraries and defines a main method. In main we initialize web3 contracts that help us interact with the coin flip and entropy contracts. At the end, the script calls the main method.\nNext, add the following code to the main method to request a flip from the CoinFlip contract.\nasync main() {\n // ... prior code omitted\n\n// Request a random number\n\n const fee = await entropyContract.methods.getFeeV2().call()\n console.log(\"fee: ${fee}\");\n\n const requestReceipt = await coinFlipContract.methods\n .request()\n .send({\n value: fee,\n from: address,\n });\n\n console.log(\"request tx: ${requestReceipt.transactionHash}\");\n // Read the sequence number for the request from the transaction events.\n const sequenceNumber =\n requestReceipt.events.FlipRequested.returnValues.sequenceNumber;\n console.log(\"sequence: ${sequenceNumber}\");\n}\nThe code snippet above generates a random number. The code calls the Entropy contract to get the fee required for requesting a random number. Then it calls the request method of the CoinFlip contract with the userRandomNumber as an argument and the required fee. Finally, the code reads the sequenceNumber from the FlipRequested event emitted by the CoinFlip contract.\nFinally, add the following code snippet to get the flip result:\nasync main() {\n // ... prior code omitted\n\nlet fromBlock = requestReceipt.blockNumber;\nconst intervalId = setInterval(async () => {\nconst currentBlock = await web3.eth.getBlockNumber();\n\n if(fromBlock > currentBlock) {\n return;\n }\n\n // Get 'FlipResult' events emitted by the CoinFlip contract for given block range.\n const events = await coinFlipContract.getPastEvents(\"FlipResult\", {\n fromBlock: fromBlock,\n toBlock: currentBlock,\n });\n fromBlock = currentBlock + 1n;\n\n // Find the event with the same sequence number as the request.\n const event = events.find(event => event.returnValues.sequenceNumber === sequenceNumber);\n\n // If the event is found, log the result and stop polling.\n if(event !== undefined) {\n console.log(\"result: ${event.returnValues.isHeads ? 'Heads' : 'Tails'}\");\n clearInterval(intervalId);\n }\n\n}, 1000);\n}\nThe code above polls for new FlipResult events emitted by the CoinFlip contract. It checks if the event has the same sequenceNumber as the request. If it does, it logs the result and stops polling.\nThat's it, Let's run the script with the command node script.js . You should get an output similar to:\nfee : 101\nrequest tx : 0xde0dce36a3c149b189aba8b29cad98375a62a811e65efdae28b28524da59cfb6\nsequence : 42\nresult : Tails\nNote that: the script can fail due to transient RPC issues. You can run the script again to get the expected result.\nNext Steps\nCongratulations! You've built your first app using Entropy. In this tutorial, we created a Solidity contract that generates a random flip using Entropy. We deployed the contract and interacted with it from Javascript.\nYou can learn more about Entropy from the following links:\n\nProtocol Design\nHow to Transform Entropy Results\nWhat's New in Entropy v2New features and improvements in Entropy v2Generate Random Numbers On-chainLearn how to integrate Pyth Entropy to generate random numbers in your dapp","tokens":2575,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259344362,"hash":"dd7ed1f9ed61010df003094f9b5c0227460ed7a7"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/tokenization","domain":"aave.com","title":"Tokenization | Aave Protocol Documentation","text":"Tokenization#\nReference for the aave-tokens Move package.\nThis documentation covers the tokenization modules in the Aave protocol implementation on Aptos. Similar to Aave on EVM chains, the Aptos implementation uses specialized tokens to represent user positions in the protocol.\na_token_factory Module#\nThe a_token_factory module manages the creation and operations of aTokens, which represent user supply positions in the Aave protocol. aTokens are interest-bearing tokens that automatically accrue interest to their holders.\nWrite Methods#\ncreate_token#\npublic(friend) fun create_token( signer: &signer, name: String, symbol: String, decimals: u8, icon_uri: String, project_uri: String, incentives_controller: Option<address>, underlying_asset: address, treasury: address): address\nCreates a new aToken for a specific underlying asset.\nInput Parameters:\nNameTypeDescriptionsigner&signerThe signer of the callernameStringThe name of the aTokensymbolStringThe symbol of the aTokendecimalsu8The decimals of the aTokenicon_uriStringThe icon URI of the aTokenproject_uriStringThe project URI of the aTokenincentives_controllerOption<address>The address of the incentives controller for this aTokenunderlying_assetaddressThe address of the underlying assettreasuryaddressThe address of the treasury\nReturn Values:\nTypeDescriptionaddressThe address of the created aToken\nEmits:\nInitialized event with details about the created aToken\nmint#\npublic(friend) fun mint( caller: address, on_behalf_of: address, amount: u256, index: u256, metadata_address: address): bool\nMints aTokens to a user.\nInput Parameters:\nNameTypeDescriptioncalleraddressThe address performing the minton_behalf_ofaddressThe address that will receive the minted aTokensamountu256The amount of tokens getting mintedindexu256The next liquidity index of the reservemetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionbooltrue if the previous balance of the user was 0\nburn#\npublic(friend) fun burn( from: address, receiver_of_underlying: address, amount: u256, index: u256, metadata_address: address)\nBurns aTokens from a user and sends the equivalent amount of underlying to the receiver.\nIn some instances, a mint event could be emitted from a burn transaction if the amount to burn is less than the interest that the user accrued.\nmint_to_treasury#\npublic(friend) fun mint_to_treasury( amount: u256, index: u256, metadata_address: address)\nMints aTokens to the reserve treasury.\nInput Parameters:\nNameTypeDescriptionamountu256The amount of tokens getting mintedindexu256The next liquidity index of the reservemetadata_addressaddressThe address of the aToken\ntransfer_on_liquidation#\npublic(friend) fun transfer_on_liquidation( from: address, to: address, amount: u256, index: u256, metadata_address: address)\nTransfers aTokens in the event of a borrow being liquidated, in case the liquidator reclaims the aToken.\nInput Parameters:\nNameTypeDescriptionfromaddressThe address getting liquidated, current owner of the aTokenstoaddressThe recipient of aTokensamountu256The amount of tokens getting transferredindexu256The next liquidity index of the reservemetadata_addressaddressThe address of the aToken\nEmits:\nBalance transfer event with the scaled amount and index\nhandle_repayment#\npublic fun handle_repayment( _user: address, _on_behalf_of: address, _amount: u256, _metadata_address: address)\nHandles the underlying received by the aToken after the transfer has been completed.\nThe default implementation is empty as with standard tokens, nothing needs to be done after the transfer is concluded. However, in the future there may be aTokens that allow for example to stake the underlying to receive LM rewards. In that case, handle_repayment() would perform the staking of the underlying asset.\nInput Parameters:\nNameTypeDescription_useraddressThe user executing the repayment_on_behalf_ofaddressThe address for which the borrow position is repaid_amountu256The amount getting repaid_metadata_addressaddressThe address of the aToken\ndrop_token#\npublic(friend) fun drop_token(metadata_address: address)\nDrops the aToken associated data.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the metadata object\nView Methods#\nget_underlying_asset_address#\npublic fun get_underlying_asset_address( metadata_address: address): address\nReturns the address of the underlying asset of this aToken.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionaddressThe address of the underlying asset\nget_previous_index#\npublic fun get_previous_index( user: address, metadata_address: address): u256\nReturns the last index interest was accrued to the user's balance.\nInput Parameters:\nNameTypeDescriptionuseraddressThe address of the usermetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionu256The last index interest was accrued to the user's balance, expressed in ray\nget_scaled_user_balance_and_supply#\npublic fun get_scaled_user_balance_and_supply( owner: address, metadata_address: address): (u256, u256)\nReturns the scaled balance of the user and the scaled total supply.\nInput Parameters:\nNameTypeDescriptionowneraddressThe address of the usermetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionu256The scaled balance of the useru256The scaled total supply\nscaled_balance_of#\npublic fun scaled_balance_of( owner: address, metadata_address: address): u256\nReturns the scaled balance of the user.\nThe scaled balance is the sum of all the updated stored balance divided by the reserve's liquidity index at the moment of the update.\nInput Parameters:\nNameTypeDescriptionowneraddressThe address of the usermetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionu256The scaled balance of the user\nscaled_total_supply#\npublic fun scaled_total_supply( metadata_address: address): u256\nReturns the scaled total supply of the aToken.\nThe scaled total supply is the sum of all scaled balances of the users.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionu256The scaled total supply\ndecimals#\npublic fun decimals(metadata_address: address): u8\nReturns the decimals of the aToken.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the aToken\nReturn Values:\nTypeDescriptionu8The decimals of the aToken\nVariable Debt Token Factory#\nThe variable_debt_token_factory module manages the creation and operations of variable debt tokens in the Aave protocol on Aptos. Variable debt tokens represent user borrowing positions with a variable interest rate.\nWrite Methods#\ncreate_token#\npublic(friend) fun create_token( signer: &signer, name: String, symbol: String, decimals: u8, icon_uri: String, project_uri: String, incentives_controller: Option<address>, underlying_asset: address): address\nCreates a new variable debt token for a specific underlying asset.\nInput Parameters:\nNameTypeDescriptionsigner&signerThe signer of the callernameStringThe name of the variable debt tokensymbolStringThe symbol of the variable debt tokendecimalsu8The decimals of the variable debt tokenicon_uriStringThe icon URI of the variable debt tokenproject_uriStringThe project URI of the variable debt tokenincentives_controllerOption<address>The address of the incentives controller for this debt tokenunderlying_assetaddressThe address of the underlying asset\nReturn Values:\nTypeDescriptionaddressThe address of the created debt token\nEmits:\nInitialized event with details about the created variable debt token\nmint#\npublic(friend) fun mint( caller: address, on_behalf_of: address, amount: u256, index: u256, metadata_address: address): bool\nMints debt tokens to the on_behalf_of address.\nInput Parameters:\nNameTypeDescriptioncalleraddressThe address receiving the borrowed underlying, being the delegatee in case of credit delegate, or same as on_behalf_of otherwiseon_behalf_ofaddressThe address receiving the debt tokensamountu256The amount of debt being mintedindexu256The variable debt index of the reservemetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionboolWhether this is the first time we mint the variable debt token to the user\nEmits:\n\nTransfer event from zero address to recipient\n\nMint event with details about the mint operation\n\nburn#\npublic(friend) fun burn( from: address, amount: u256, index: u256, metadata_address: address)\nBurns debt tokens from a user.\nInput Parameters:\nNameTypeDescriptionfromaddressThe address from which the debt tokens will be burnedamountu256The amount of debt tokens that will be burnedindexu256The variable debt index of the reservemetadata_addressaddressThe address of the variable debt token\nEmits:\nTransfer event to zero addressBurn event with details about the burn operationIf the balance increase is greater than the amount, also emits Transfer and Mint events\ndrop_token#\npublic(friend) fun drop_token(metadata_address: address)\nDrops the variable debt token associated data.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the metadata object\nView Methods#\nget_underlying_asset_address#\npublic fun get_underlying_asset_address( metadata_address: address): address\nReturns the address of the underlying asset of this variable debt token.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionaddressThe address of the underlying asset\nget_previous_index#\npublic fun get_previous_index( user: address, metadata_address: address): u256\nReturns the last index interest was accrued to the user's balance.\nInput Parameters:\nNameTypeDescriptionuseraddressThe address of the usermetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionu256The last index interest was accrued to the user's balance, expressed in ray\nget_scaled_user_balance_and_supply#\npublic fun get_scaled_user_balance_and_supply( owner: address, metadata_address: address): (u256, u256)\nReturns the scaled balance of the user and the scaled total supply.\nInput Parameters:\nNameTypeDescriptionowneraddressThe address of the usermetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionu256The scaled balance of the useru256The scaled total supply\nscaled_balance_of#\npublic fun scaled_balance_of( owner: address, metadata_address: address): u256\nReturns the scaled balance of the user.\nThe scaled balance is the sum of all the updated stored balance divided by the reserve's variable debt index at the moment of the update.\nInput Parameters:\nNameTypeDescriptionowneraddressThe address of the usermetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionu256The scaled balance of the user\nscaled_total_supply#\npublic fun scaled_total_supply( metadata_address: address): u256\nReturns the scaled total supply of the variable debt token.\nThe scaled total supply is the sum of all scaled balances of the users with debt.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionu256The scaled total supply\nname#\npublic fun name(metadata_address: address): String\nReturns the name of the variable debt token.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionStringThe name of the variable debt token\nsymbol#\npublic fun symbol(metadata_address: address): String\nReturns the symbol of the variable debt token.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionStringThe symbol of the variable debt token\ndecimals#\npublic fun decimals(metadata_address: address): u8\nReturns the decimals of the variable debt token.\nInput Parameters:\nNameTypeDescriptionmetadata_addressaddressThe address of the variable debt token\nReturn Values:\nTypeDescriptionu8The decimals of the variable debt token\nComparison with Ethereum Implementation#\nThe variable debt token implementation in Aptos follows similar principles to the Ethereum implementation but is adapted to the Move language and Aptos blockchain architecture:\n\nObject-based Model: Instead of ERC20 contracts, Aptos uses an object-based model for fungible assets.\n\nScaled Balances: Like in Ethereum, the variable debt tokens use scaled balances to track user debt positions, which automatically accrue interest over time.\n\nIndex-based Interest Accrual: Interest accrual is handled through index-based calculations, similar to the Ethereum implementation.\n\nNo Transfers: Variable debt tokens cannot be transferred between users, as they represent a specific user's debt position.\n\nThe variable debt tokens in Aave on Aptos serve the same purpose as in the Ethereum implementation: they represent a user's variable-rate debt position in the protocol and automatically accrue interest over time based on the variable interest rate of the corresponding reserve.PreviousAave LogicNextIncentives","tokens":3281,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259349124,"hash":"b4d29836225f223302f4095af7178d8f68c35949"}
{"url":"https://docs.openzeppelin.com/tools/uikit/architecture","domain":"docs.openzeppelin.com","title":"Architecture | OpenZeppelin Docs","text":"UIKitArchitectureOpen in ClaudeOpenZeppelin UIKit is built as a layered stack of independently installable packages. This page explains how those layers fit together, how the capability-driven adapter model works, and how runtimes manage lifecycle across multiple ecosystems.\nPackage Layers\nThe packages form a dependency chain where each layer builds on the ones below it. Lower layers are lighter and more generic; higher layers add React-specific and domain-specific behavior.\n\nColor key: ■ Application layers (5–7) · ■ UI & design (3–4) · ■ Foundation (1–2)\nLayerPackageResponsibility1@openzeppelin/ui-typesTypeScript interfaces for capabilities, schemas, form models, networks, transactions, and execution config. No runtime code: pure type definitions.2@openzeppelin/ui-utilsFramework-agnostic helpers: AppConfigService for environment/config loading, structured logger, validation utilities, and routing helpers.3@openzeppelin/ui-stylesTailwind CSS 4 theme tokens using OKLCH color space. Ships CSS variables and custom variants (dark mode). No JavaScript.4@openzeppelin/ui-componentsReact UI primitives (buttons, dialogs, cards, tabs) and blockchain-aware form fields (address, amount, bytes, enum, map). Built on Radix UI + shadcn/ui patterns.5@openzeppelin/ui-reactRuntimeProvider for managing EcosystemRuntime instances per network. WalletStateProvider for global wallet state. Derived hooks for cross-ecosystem wallet abstraction.6@openzeppelin/ui-rendererTransactionForm for schema-driven transaction forms. ContractStateWidget for view function queries. ExecutionConfigDisplay, AddressBookWidget, address book components.7@openzeppelin/ui-storageEntityStorage and KeyValueStorage base classes on Dexie.js/IndexedDB. Account alias plugin for address-to-name mapping.\n\nCapabilities\nThe UIKit type system defines 13 capabilities: small, focused interfaces that describe what an adapter can do.\nCapabilities are organized into three tiers based on their requirements:\n\nTier 1 requires no runtime context: safe to import anywhere. Tier 2 needs a networkConfig. Tier 3 additionally needs wallet state and participates in the dispose() lifecycle. Each higher tier may import from lower tiers, but never the reverse.\nCapabilityTierPurposeAddressing1Address validation, formatting, checksummingExplorer1Block explorer URL generationNetworkCatalog1Available network listing and metadataUiLabels1Human-readable labels for ecosystem-specific termsContractLoading2Fetch and parse contract ABIs/IDLsSchema2Transform contract definitions into form-renderable schemasTypeMapping2Map blockchain types (e.g. uint256) to form field typesQuery2Execute read-only contract calls (view functions)Execution3Sign, broadcast, and track transactionsWallet3Connect/disconnect wallets, account state, chain switchingUiKit3Ecosystem-specific React components and hooksRelayer3Gas-sponsored transaction execution via relayersAccessControl3Role-based access control queries and snapshots\nCapability Bundles\nHigher-level components request specific bundles of capabilities rather than the full set. For example, TransactionForm expects a TransactionFormCapabilities type: an intersection of the capabilities needed for form rendering, execution, and status tracking.\nThis means you can pass a partial adapter that only implements what the component actually needs.\n\nRuntimes and Profiles\nEcosystem Runtimes\nAn EcosystemRuntime is a live instance that bundles capabilities for a specific network. Capabilities created within the same runtime share runtime-scoped state (network config, wallet connection, caches) and are disposed together.\nRuntimes are created by ecosystem adapter packages:\nimport { ecosystemDefinition } from '@openzeppelin/adapter-evm';\n\nconst runtime = await ecosystemDefinition.createRuntime(\n 'composer', // profile name\n ethereumMainnetConfig // network config\n);\n\n// Access capabilities from the runtime\nconst address = runtime.addressing.formatAddress('0x...');\nconst schema = await runtime.schema.generateFormSchema(contractDef);\nconst txHash = await runtime.execution.signAndBroadcast(txData, execConfig);\n\n// Clean up when done\nruntime.dispose();\nProfiles\nAdapters support five standard profiles that define which capabilities are included:\nProfileUse CaseTier 1Tier 2Tier 3declarativeAddress formatting, explorer links✓--viewerRead contract state, no wallet needed✓✓-transactorExecute transactions, basic wallet✓✓Execution, WalletcomposerFull UI with form rendering✓✓✓ (most)operatorAdministrative tools, access control✓✓✓ (all)\nChoose the lightest profile that fits your use case. A dashboard that only displays contract state can use viewer; a full transaction builder should use composer or operator.\nRuntime Lifecycle\n\nRuntimeProvider maintains a per-network-id registry of runtimes. When a network is selected for the first time, the runtime is created asynchronously and cached. On unmount, all runtimes are disposed, releasing any wallet connections, subscriptions, or internal state.\nExecution Strategies\nThe execution system supports multiple ways to submit a transaction. The adapter selects the appropriate strategy based on the ExecutionConfig:\n\nEach ecosystem adapter defines which execution methods it supports. The EVM adapter supports both EOA and Relayer; other ecosystems may support only EOA.\nHow It Connects\nPutting it all together, here is how a typical application uses UIKit with an Ecosystem Adapter:\n\nNext Steps\n\nComponents: Explore all available UI primitives and form fields\nReact Integration: Deep dive into providers, hooks, and wallet state\nBuilding an adapter: Background on the adapter pattern and ecosystem integrations\nGetting StartedPrevious PageComponentsNext PageOn this pagePackage LayersCapabilitiesCapability BundlesRuntimes and ProfilesEcosystem RuntimesProfilesRuntime LifecycleExecution StrategiesHow It ConnectsNext Steps","tokens":1469,"squid":"ink-security_audits","role":"Sentinel","at":1791259351307,"hash":"0178eae2327417d4618528e87ce15c5ce8da095f"}
{"url":"https://io.net/docs/guides/payment/io-cloud-payments","domain":"io.net","title":"Overview - io.net","text":"IO Cloud compute is paid only with IO Credits. You can top up your credits with a credit or debit card through Stripe.\nVM and container bookings are billed Pay-As-You-Go from your IO credits: you pay for the time a booking runs, until you stop it or your credits run out.\n​Table of Contents\n\nPay-As-You-Go billing\nFees\nAdd Wallet for Crypto\nManage funds page\nDeploy Cluster and Pay with $IO Coin, USDC Crypto or Fiat\nExtending Your Cluster and Pay with $IO Coin or USDC Crypto\n\n​Fees\nThere are no additional fees for creating a booking or for topping up credits with crypto.\nA 5% fee applies only to credit top-ups made with a credit or debit card (processed through Stripe).\n​Adding a Wallet for Crypto Payments\nIf you plan to pay using crypto, you must add a wallet to your account. Credit card users don’t need to complete this step.\nAll suppliers must add at least three (3) self-custodial Solana wallets to their IO ID account to remain eligible for Block Rewards. This requirement is effective as of 23:59:59 UTC on April 30, 2025.\nYou can associate up to 10 Solana wallets with your account. One wallet will be designated as the Primary Wallet, which will serve as the default for all transactions except Block Rewards Distribution.\nPlease ensure your account meets this requirement to continue participating in the reward program.\nFor detailed steps on adding and managing wallets, please refer to the instructions below:\n​Connect a Single Solana Wallet\nTo learn how to create your own Solana wallet, check out this short guide. When you create your account, you are promoted to add a wallet. You can also skip the step and add your wallet in Account Settings.\nFollow the steps below to add a wallet to your account:\n\nClick on your icon in the upper right and select Account Settings.\n\nIn Account Settings, find the Solana Wallet Address block and click the Add Wallet button.\n\nIn the appearing popup, enter your new Solana wallet address\n\nClick Connect to add the new address.\n\nAs a result, your wallet will be successfully connected to the IO ecosystem.\n\n​Connect a Single Aptos Wallet\nTo learn how to create your own Aptos wallet, check out this short guide. When you create your account, you are promoted to add a wallet. You can also skip the step and add your wallet in Account Settings.\n\nClick on your icon in the upper right and select Account Settings.\n\nIn the Aptos Wallet section, click Add Wallet.\n\nEnter your wallet address in the Connect New Aptos Wallet field and click Connect.\n\n​Adding Multiple Wallets\nThe multi-wallet feature allows you to add up to 10 Solana wallets to your IO.net account, providing flexibility in managing rewards, payments, and assets.\nThis is particularly useful if one of your wallets becomes inaccessible, lost, or compromised, ensuring you still receive your rewards. Additionally, you can distribute rewards across different wallets for better organization and security.\nYou can add up to 10 wallets to your account. Here’s how to add additional wallets:\n\nUnderneath your first wallet address, find and click the Add New Solana Wallet Address link.\n\nIn the appearing popup, enter your new Solana wallet address just like you did for your first wallet.\n\nClick Connect to add the new additional address.\n\nYour new wallet will be successfully added to the IO ecosystem.\n\n​Primary Wallet Address\nBy default, your first wallet becomes the primary one. However, if you add more than one wallet, you can set another wallet as the primary. The primary wallet will be used for Block Rewards and payment transactions instead of the old address.\nTo change your primary wallet, hover your mouse over the desired wallet address and click on the blue star beneath the field. The selected wallet will then become the primary one.\n\n​Removing a Wallet\nYou can remove any of your wallet addresses at any time. Here’s how:\n\nHover over the wallet address you want to remove.\n\nA red Trash icon will appear. Click on it to remove the selected wallet.\n\nA pop-up will appear to double-check your action to ensure you want to remove the wallet.\n\nIf you remove your wallet from the IO ecosystem, you will no longer receive block rewards, payments, or any other rewards associated with that wallet. Please be sure to remove wallets only when necessary.\n\n​Manage funds page\nIn the upper-right corner of the screen, click Manage Funds.\n\nThis will open the Manage Funds page, where you can:\n\nView your lifetime Block Rewards earnings for your Workers.\nView the Block rewards already claimed for your Workers.\nView your current Cloud balance in USDC.\nView your current Cloud balance in $IO Coin.\nSee your Worker Earnings and Claim rewards.\n\nList of Transactions\nThis section also includes a List of Transactions. You can filter transactions by date within any allowed period and by categories such as:\n\nReloaded\nEarnings\nRefunded\nWithdrawal\nPromo Credit\n\nAdditionally, you can filter transactions by sections in the IO system, such as:\n\nWorker\nCloud\n\nClicking on a specific transaction will open a page with detailed information about it.\n\nView a specific transaction\nThe detailed transaction page shows:\n\nAmount and type of currency received\nTransaction type\nPlatform used\nStatus\nDate\nTransaction ID\nWas this page helpful?","tokens":1311,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259364384,"hash":"3c0ebc96b2eaaf5922d6a0f1ff1dbaaefe3ae867"}
{"url":"https://gov.optimism.io/c/grants/gov-fund-missions/69","domain":"gov.optimism.io","title":"Latest Grants 🔴/Governance Fund Missions topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Governance Fund Missions\n\n Grants 🔴\n\n Governance Fund Missions\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions be…\n\n read more\n\n 4\n\n 127\n\n 27d\n\n [Builder Grant Proposal] Ag^τ Semantic Compression Engine: 4.00x Calldata Compression (33M+ tx/s)\n\n Hello Optimism Collective, \nWe have developed Ag^τ, a proprietary, zero-FPU semantic compression engine designed to reduce L1 calldata costs and lower hardware overhead for EVM rollups. \nAs Optimism scales, L1 data avail…\n\n read more\n\n 2\n\n 85\n\n Aug 25\n\n [CLOSED] Governance Fund Mission Request: Open-source Monitoring & alerting\n\n season-8\n\n Season 8 Intent: A set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfer \nTotal grant amount: 114,000 OP (funding 52,000 OP per team, for up to 2 teams) \nShould this Governance Fund Miss…\n\n read more\n\n 12\n\n 791\n\n May 4\n\n [MISSION REQUEST] Startup Support - Optimism as Venture Studio\n\n Delegate Mission Request Summary\nThis mission aims to provide new business support for projects within the Optimism ecosystem, including projects with approved grants in previous governance seasons. This program will foc…\n\n read more\n\n 8\n\n 998\n\n Jan 16\n\n Cycle 45 Results – Season 8 Audit Grants\n\n Cycle 45 Results – Season 8 Audit Grants\nWe’re pleased to share the results of Cycle 45, continuing the Audit Grants program under Season 8. \n\nKey Outcomes\n\nApplications Approved: 4 \n(Metrom – 25,200 OP; 40acres – 75,00…\n\n read more\n\n 0\n\n 203\n\n Dec 2025\n\n Bringing $ 11 Billion RWA Healthcare volume on Optimism\n\n I am Dr Ibrar and i am here to ask for Grant for my project OrthoBridge.(RWA,Healtcare Category) \nThis can be a Gamechanger for Op,Eth and Base chain all in one bringing Real value to real world outside Blockchain. \nLite…\n\n read more\n\n 0\n\n 40\n\n Dec 2025\n\n S7 Grants Council Impact Analysis\n\n season-7\n\n TL;DR:\n\nAn observational analysis of S7 Grants Council grants measured OP-normalized ROI using net Superchain TVL inflows between March 20 and June 12, 2025.\nROI benchmarks emerged at $1.58 (25th percentile), $3.67 (medi…\n\n read more\n\n 19\n\n 1.1k\n\n Dec 2025\n\n Unified Safe Owner Management Across Superchain\n\n season-8,season-9\n\n Cross-Chain Safe Module System — Governance Fund Mission Application\nProject Name: Unified Safe Owner Management Across Superchain \nMission: Deliver a secure, Hub-based Safe module system that enables unified owner updat…\n\n read more\n\n 1\n\n 122\n\n Nov 2025\n\n [CLOSED] Governance Fund Mission Request: Cross-Chain Key Management for Safe\n\n season-8\n\n Season 8 Intent: A set of interoperable Stage 1 chains doing $100m per month in cross-chain asset transfer \nTotal grant amount: Up to 126,000 OP (funding 63,000 OP per team, up to 2 teams) \nShould this Governance Fund Mi…\n\n read more\n\n 11\n\n 520\n\n Nov 2025\n\n S8 Governance Fund Missions\n\n season-8\n\n Grants Council Mission\n\nExpected impact on the Intent: \nThe Grants Council makes grants, on behalf of the Token House, in an effort to make progress towards the Intent. In Season 8, the Grants Council will work towards …\n\n read more\n\n 11\n\n 1.2k\n\n Sep 2025\n\n [grant update] bleu’s Farcaster sybil detection\n\n Hello Optimism community! \nThe bleu team is excited to start building a sybil detection algorithm for Farcaster using social graph data. Our goal is to enhance the integrity of Farcaster and the ecosystem around it. \nWe’…\n\n read more\n\n 7\n\n 397\n\n Sep 2025\n\n [grant update] OP Govquests\n\n grant-update\n\n Hello Optimism community! \nThe bleu team is excited to start building OP Govquests! Our goal is to engage and enable new delegate and increase delegation activity in the ecosystem. \nWe’ll post bi-weekly updates here as c…\n\n read more\n\n 12\n\n 532\n\n Sep 2025\n\n [MISSION REQUEST] Open-source transaction simulator\n\n Title: Open-source transaction simulator\nDelegate Mission Request Summary: \nThis mission is intended to provide a key, critical piece of tooling - simulating transactions before they go onchain. Tenderly provides a great…\n\n read more\n\n 3\n\n 522\n\n Aug 2025\n\n Season 8 Milestones and Metrics Council Charter\n\n season-8\n\n Thank you everyone last season for the M&M Council’s inaugural season as a stand alone council. It has been an honor to serve as the M&M lead the last few seasons. \nBelow is the proposed charter for S8. Since this and le…\n\n read more\n\n 8\n\n 406\n\n Jul 2025\n\n Season 8 Grants Council Charter amendment\n\n season-8\n\n Proposed Council or Board Lead: Gonna.eth (If a future budget proposal is approved, more on this here) \nPlease link to any previous work or qualifications to be Council or Board Lead: \n\nAtlas Profile\nGrants Council Revie…\n\n read more\n\n 13\n\n 564\n\n Jul 2025\n\n [Mission Request] Farcaster social graph\n\n Delegate Mission Request Summary \nAnalyze social graphs and attestation data to output a probability that any one Farcaster account is a Sybil, contributing to the progress towards decentralization by improving the accur…\n\n read more\n\n 10\n\n 1.1k\n\n Mar 2025\n\n Wannabet Weekly Tournaments: Jelly Beans\n\n The wannabet team is thrilled to be selected to execute on the mission request of developing an onchain social game to attract builders to Optimism. Our game will be a new product in the wannabet family where users make …\n\n read more\n\n 8\n\n 289\n\n Feb 2025\n\n [Mission Request]: Intent #3B: Support the Superchain\n\n season-6\n\n Intent 3 is subdivided into two portions: \n\nIntent 3A: OP Mainnet Mission Requests will be created by The Grants Council and approved by the Token House\nIntent 3B: One Superchain Grant Mission Request will be created by …\n\n read more\n\n 6\n\n 2.1k\n\n Feb 2025\n\n S5 grantee: x23.ai - governance summariser + chatbot\n\n season-5\n\n G’day everyone. We’re one of the awarded grantees for the AI Assistance for governance mission in Season 5. \nWe’ll use this topic thread to post updates and seek feedback for what we’re building. \nIn summary, we want to …\n\n read more\n\n 5\n\n 439\n\n Feb 2025\n\n [Mission Request] Create and Distribute Videos about Optimism Collective Governance\n\n season-6\n\n Delegate Mission Request Summary:\nThis mission seeks to create entertaining and educational videos that draw people into the Optimism Collective. The aim is to raise awareness for Optimism, make it easy for people to get…\n\n read more\n\n 14\n\n 1.3k\n\n Feb 2025\n\n [grant update] Glo Dollar upgrade to funding RetroPGF Retrospective Report\n\n season-5\n\n Glo Dollar (USDGLO) is a stablecoin designed to fund public goods. It is a US regulated, 100% fiat backed stablecoin. \nWe were awarded a mission request grant to create an additional revenue source to fund RetroPGF round…\n\n read more\n\n 0\n\n 182\n\n Feb 2025\n\n Collective Grant Policies\n\n Collective Grant Policies\nThese grant policies apply to all Governance Fund grants and all OP Chain grant programs stemming from Governance Fund grants. Failure to abide with the below policies may result in the refusal …\n\n read more\n\n 15\n\n 10.4k\n\n Jan 2025\n\n [Mission Request v2] Develop Onchain Social Games that Attract Builders to Optimism\n\n season-6\n\n Delegate Mission Request Summary: Develop engaging onchain social games that attract and nurture builders, fostering a vibrant community of developers who build valuable applications on Optimism. \nS6 Intent : Intent 3A:…\n\n read more\n\n 3\n\n 500\n\n Jan 2025\n\n [Mission Request] Optimism Dominance in Yield-Bearing Assets - DEX Liquidity for YBAs\n\n cycle-27\n\n Delegate Mission Request Summary \nThis mission request seeks the onboarding of more RWAs and yield-bearing assets to Optimism via DEX integrations. This MR ties in with the four Season 6 RWA MRs posted by GFX Labs, so it…\n\n read more\n\n 31\n\n 1.3k\n\n Jan 2025\n\n Season 7: Governance Fund Missions\n\n season-7\n\n Special thanks to members of the Feedback Commission for discussion and review. \n\nIn Season 7, Governance Fund Missions will focus on contributions, across the Superchain, that make progress towards success metrics. That…\n\n read more\n\n 6\n\n 2.1k\n\n Jan 2025\n\n Inflation Adjustment Op Superchain\n\n Inflation Adjustment Proposal for OP Superchain\nIntroduction\nInflation is a fundamental mechanism in blockchain ecosystems, ensuring both the sustainability of network operations and incentivization of participants. With…\n\n read more\n\n 0\n\n 127\n\n Jan 2025\n\n [Mission Request] Superchain Track at Crecimiento Hackathon\n\n season-6\n\n Delegate Mission Request Summary\nWe propose to include OP at the Hackathon during the upcoming Pop-Up City event in December organized by Crecimiento in Buenos Aires. This event is part of the larger Crecimiento initiati…\n\n read more\n\n 3\n\n 171\n\n Nov 2024\n\n [Mission Request] Increase Prevalence of Non-USD/EURO Stablecoins\n\n season-6,cycle-28\n\n Delegate Mission Request Summary: \nThis mission request is designed to grow liquidity of non-USD and non-EURO fiat-pegged stablecoins on OP Mainnet. It is intended for projects looking to either a) grow liquidity of this…\n\n read more\n\n 17\n\n 753\n\n Nov 2024\n\n [Mission Request] Marquee governance hackathon\n\n season-6\n\n Delegate Mission Request Summary \nThis mission is designed to attract developers at a key juncture in their path as builders—the idea stage—by bringing on a trusted partner to host a hackathon. This event would be a marq…\n\n read more\n\n 9\n\n 659\n\n Nov 2024\n\n [Mission Request] - Crosschain alert monitoring\n\n cycle-27\n\n Delegate Mission Request Summary: Products built on top of Interop require alerting and monitoring for messages/transactions leaving their canonical chain. This is critical if we want to approach serious teams interested…\n\n read more\n\n 6\n\n 392\n\n Oct 2024","tokens":2489,"squid":"ink-governance","role":"Council Listener","at":1791259378336,"hash":"78b11f2315ff85323c6739df697bf646cd78827b"}
{"url":"https://docs.arbitrum.io/stylus/quickstart","domain":"docs.arbitrum.io","title":"Quickstart: write a smart contract in Rust using Stylus | Arbitrum Docs","text":"✏️Request an updateNew Stylus activations are pausedThe Arbitrum Security Council has temporarily paused new Stylus contract activations on Arbitrum One and Arbitrum Nova. Stylus contracts that are already activated keep running until they expire. To learn what this means for you, read Temporary pause on new Stylus activations.\nThis guide will get you started with Stylus' basics. We'll\ncover the following steps:\n\nSetting up your development environment\nCreating a Stylus project with cargo stylus\nChecking the validity of your contract\nDeploying your contract\nExporting your contract's ABIs\nCalling your contract\nSending a transaction to your contract\n\nSetting up your development environment​\nPrerequisites​\nRust toolchainFollow the instructions on Rust Lang's installation page to install a complete Rust toolchain (v1.91 or newer) on your system. After installation, ensure you can access the programs rustup, rustc, and cargo from your preferred terminal application.\nVS CodeWe recommend VSCode as the IDE of choice for its excellent Rust support, but feel free to use another text editor or IDE if you're comfortable with those.Some helpful VS Code extensions for Rust development:\nrust-analyzer: Provides advanced features like smart code completion and on-the-fly error checks\nError Lens: Immediately highlights errors and warnings in your code\nEven Better TOML: Improves syntax highlighting and other features for TOML files, often used in Rust projects\nDependi: Helps manage Rust crate versions directly from the editor\n\nDockerThe testnode we will use as well as some cargo stylus commands require Docker to operate.You can download Docker from Docker's website.\nFoundry's CastFoundry's Cast is a command-line tool that allows you to interact with your EVM contracts. You need to install the Foundry CLI to use Cast.\nNitro devnodeStylus is available on Arbitrum Sepolia, but we'll use nitro devnode which has a pre-funded wallet saving us the effort of wallet provisioning or running out of tokens to send transactions.Install your devnodegit clone https://github.com/OffchainLabs/nitro-devnode.gitcd nitro-devnodeLaunch your devnode./run-dev-node.sh\nCreating a Stylus project with cargo stylus​\ncargo stylus is a CLI toolkit built to facilitate the development of Stylus contracts. For a full list of commands and options, see the cargo stylus commands reference.\nIt is available as a plugin to the standard cargo tool used for developing Rust programs.\nInstalling cargo stylus​\nIn your terminal, run:\ncargo install --force cargo-stylus\nYou can verify that cargo stylus is installed by running cargo stylus --help in your terminal, which will return a list of helpful commands; we will use some of them in this guide:\ncargo stylus --help returns:Cargo command for developing Stylus projectsUsage: cargo stylus <COMMAND>Commands: new Create a new Stylus project init Initializes a Stylus project in the current directory export-abi Export a Solidity ABI activate Activate an already deployed contract [aliases: a] cache Cache a contract using the Stylus CacheManager for Arbitrum chains check Check a contract [aliases: c] deploy Deploy a contract [aliases: d] verify Verify the deployment of a Stylus contract [aliases: v] cgen Generate c code bindings for a Stylus contract replay Replay a transaction in gdb [aliases: r] trace Trace a transaction [aliases: t] help Print this message or the help of the given command(s)Options: -h, --help Print help -V, --version Print version\nCreating a project​\nLet's create our first Stylus project by running:\ncargo stylus new <YOUR_PROJECT_NAME>cd <YOUR_PROJECT_NAME>\ncargo stylus new generates a starter template that implements a Rust version of the Solidity Counter smart contract example:\n// SPDX-License-Identifier: MITpragma solidity >=0.4.22 <0.9.0;contract Counter { uint count; function setCount() public { count = count + 1; } function getCount() view public returns(uint) { return count; }}\nAt this point, you can move on to the next step of this guide or develop your first Rust smart contract. Feel free to use the Stylus Rust SDK reference section as a starting point; it offers many examples to help you quickly familiarize yourself with Stylus.\nChecking if your Stylus project is valid​\nBy running cargo stylus check against your first contract, you can check if your program can be successfully deployed and activated onchain.\nImportantEnsure your Docker service runs so this command works correctly.\ncargo stylus check\ncargo stylus check executes a dry run on your project by compiling your contract to WASM and verifying if it can be deployed and activated onchain.\nIf the command above fails, you'll see detailed information about why your contract would be rejected:\nReading WASM file at bad-export.watCompressed WASM size: 55 BStylus checks failed: program pre-deployment check failed when checking againstARB_WASM_ADDRESS 0x0000…0071: (code: -32000, message: program activation failed: failed to parse program)Caused by: binary exports reserved symbol stylus_ink_leftLocation: prover/src/binary.rs:493:9, data: None\nThe contract can fail the check for various reasons (on compile, deployment, etc...). Reading the Invalid Stylus WASM Contracts explainer can help you understand what makes a WASM contract valid or not. For other deployment and activation errors (e.g., program activation failed), see common issues.\nIf your contract succeeds, you'll see something like this:\nFinished release [optimized] target(s) in 1.88sReading WASM file at hello-stylus/target/wasm32-unknown-unknown/release/hello-stylus.wasmCompressed WASM size: 3 KBProgram succeeded Stylus onchain activation checks with Stylus version: 1\nNote that running cargo stylus check may take a few minutes, especially if you're verifying a contract for the first time.\nSee cargo stylus check --help for more options.\nDeploying your contract​\nOnce you're ready to deploy your contract onchain, cargo stylus deploy will help you with the deployment and its gas estimation.\nInfoAs of ArbOS 61, Stylus contracts can be up to 96 KB. If your compressed WASM exceeds 24 KB, cargo stylus deploy automatically splits the binary into fragments and deploys a collection contract that references them. You don't need to do anything different — the resulting contract address (the collection) is what callers use, and it behaves like any other Stylus contract. Read more in Deploying contracts larger than 24 KB.\nEstimating gas​\nNote: For every transaction, we'll use the testnode pre-funded wallet, you can use 0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659 as your private key.\nYou can estimate the gas required to deploy your contract by running:\ncargo stylus deploy \\ --endpoint='http://localhost:8547' \\ --private-key=\"0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659\" \\ --estimate-gas\nThe command should return something like this:\ndeployment tx gas: 7123737gas price: \"0.100000000\" gweideployment tx total cost: \"0.000712373700000000\" ETH\nDeployment​\nLet's move on to the contract's actual deployment. Two transactions will be sent onchain: the contract deployment and its activation.\ncargo stylus deploy \\ --endpoint='http://localhost:8547' \\ --private-key=\"0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659\"\nOnce the deployment and activations are successful, you'll see an output similar to this:\ndeployed code at address: 0x33f54de59419570a9442e788f5dd5cf635b3c7acdeployment tx hash: 0xa55efc05c45efc63647dff5cc37ad328a47ba5555009d92ad4e297bf4864de36wasm already activated!\nMake sure to save the contract's deployment address for future interactions!\nMore options are available for sending and outputting your transaction data. See cargo stylus deploy --help for more details.\nExporting the Solidity ABI interface​\nThe cargo stylus tool makes it easy to export your contract's ABI using cargo stylus export-abi.\nThis command returns the Solidity ABI interface of your smart contract. If you have been running cargo stylus new without modifying the output, cargo stylus export-abi will return:\n/** * This file was automatically generated by Stylus and represents a Rust program. * For more information, please see [The Stylus SDK](https://github.com/OffchainLabs/stylus-sdk-rs). */// SPDX-License-Identifier: MIT-OR-APACHE-2.0pragma solidity ^0.8.23;interface ICounter { function number() external view returns (uint256); function setNumber(uint256 new_number) external; function mulNumber(uint256 new_number) external; function addNumber(uint256 new_number) external; function increment() external; function addFromMsgValue() external payable;}\nEnsure you save the console output to a file that you'll be able to use with your decentralized app.\nInteracting with your Stylus contract​\nStylus contracts are EVM-compatible, you can interact with them with your tool of choice, such as Hardhat, Foundry's Cast, or any other Ethereum-compatible tool.\nIn this example, we'll use Foundry's Cast to send a call and then a transaction to our contract.\nCalling your contract​\nOur contract is a counter; in its initial state, it should store a counter value of 0.\nYou can call your contract so it returns its current counter value by sending it the following command:\nCall to the function: number()(uint256)cast call --rpc-url 'http://localhost:8547' \\[deployed-contract-address] \"number()(uint256)\"\nLet's break down the command:\n\ncast call command sends a read-only call to your contract (no transaction is sent, so no private key is needed)\nThe --rpc-url option is the RPC URL endpoint of our testnode: http://localhost:8547\nThe [deployed-contract-address] is the address we want to interact with, it's the address that was returned by cargo stylus deploy\nnumber()(uint256) is the function we want to call in Solidity-style signature. The function returns the counter's current value\n\nCalling 'number()(uint256)' returns:0\nThe number()(uint256) function returns a value of 0, the contract's initial state.\nSending a transaction to your contract​\nLet's increment the counter by sending a transaction to your contract's increment() function.\nWe'll use Cast's send command to send our transaction.\nSending a transaction to the function: increment()cast send --rpc-url 'http://localhost:8547' --private-key 0xb6b15c8cb491557369f3c7d2c287b053eb229daa9c22138887752191c9520659 \\[deployed-contract-address] \"increment()\"\nTransaction returns:blockHash 0xfaa2cce3b9995f3f2e2a2f192dc50829784da9ca4b7a1ad21665a25b3b161f7cblockNumber 20contractAddresscumulativeGasUsed 97334effectiveGasPrice 100000000from 0x3f1Eae7D46d88F08fc2F8ed27FCb2AB183EB2d0EgasUsed 97334logs []logsBloom 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000rootstatus 1 (success)transactionHash 0x28c6ba8a0b9915ed3acc449cf6c645ecc406a4b19278ec1eb67f5a7091d18f6btransactionIndex 1type 2blobGasPriceblobGasUsedauthorizationListto 0x11B57FE348584f042E436c6Bf7c3c3deF171de49gasUsedForL1 \"0x0\"l1BlockNumber \"0x1223\"\nOur transactions returned a status of 1, indicating success, and the counter has been incremented (you can verify this by calling your contract's number()(uint256) function again).\nTesting your contract​\nThe Stylus testing framework includes TestVM, a simulation of the Stylus execution environment that enables you to test your contracts without deploying them. Here's a simple example of how\nto test the counter contract:\n#[cfg(test)]mod test { use super::*; use stylus_sdk::testing::*; #[test] fn test_counter_operations() { // Set up the test VM and instantiate the contract let vm = TestVM::default(); let mut contract = Counter::from(&vm); // Initial state: the counter starts at zero assert_eq!(contract.number(), U256::ZERO); // increment() updates storage contract.increment(); assert_eq!(contract.number(), U256::from(1)); // set_number() overwrites the stored value contract.set_number(U256::from(5)); assert_eq!(contract.number(), U256::from(5)); }}\nTo enable testing, you'll need to add the following to your Cargo.toml:\n[dev-dependencies]stylus-sdk = { version = \"0.10.7\", features = [\"stylus-test\"] }\nRunning your tests​\nYou can run your tests using the standard Rust test command:\ncargo test\nThe testing framework allows you to:\n\nSimulate transaction context and block information\nTest contract storage operations\nVerify state transitions\nMock contract-to-contract interactions\nTest various scenarios without deployment costs\n\nFor more advanced testing techniques and best practices, see the Testing contracts with Stylus guide.\nConclusion​\nCongratulations! You've successfully initialized, deployed, and interacted with your first contract using Stylus and Rust.\nFeel free to explore the Stylus Rust SDK reference for more information on using Stylus in your Arbitrum projects.Setting up your development environmentPrerequisitesCreating a Stylus project with cargo stylusInstalling cargo stylusCreating a projectChecking if your Stylus project is validDeploying your contractEstimating gasDeploymentExporting the Solidity ABI interfaceInteracting with your Stylus contractCalling your contractSending a transaction to your contractTesting your contractRunning your testsConclusion","tokens":3405,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259379311,"hash":"c0b2fe67da1e98a26d3f3d37e8a2c068321bac96"}
{"url":"https://io.net/docs/guides/clouds/managed-services","domain":"io.net","title":"Managed Services - io.net","text":"Managed Services cover the cluster types that io.net provisions and configures for you, rather than deploying them yourself from IO Cloud. Our specialists size the cluster, set it up to your specifications, and hand it over ready to use.\nThe following cluster types are available as Managed Services:\n\nBare Metal: Direct access to physical hardware with no virtualization layer.\nKubernetes: A managed Kubernetes cluster for orchestrating GPU-accelerated container workloads.\nRay: A managed Ray cluster for distributed Python, training, and inference workloads.\nConfidential Compute: VMs encrypted with Intel TDX or AMD SEV-SNP, on NVIDIA GPUs running in Confidential Computing mode, keeping your data, model weights, and computations protected while in use.\n\nSelf-service deployment for these cluster types is no longer available. Bare Metal on Demand was withdrawn on Wednesday, October 1, 2025. Virtual Machines and Containers remain self-service from IO Cloud.\n​To request a Managed Service:\n\nEmail our sales team at business@io.net. Mention which cluster type you need and your preferred GPU type, and provide basic project details.\nOur specialists will reach out to understand your needs and assist with configuring the cluster to your specifications.\n\nOnce your cluster is provisioned, connect to it and deploy your workloads as usual.\n\nTo view detailed instructions for working with your cluster, see:\n\nKubernetes: Quick Start: Hello World with HTTPS, Ingress Setup, Exposing Applications to the Internet, ExternalDNS Deployment Guide, and Optimizations.\nConfidential Compute: Confidential Compute and Confidential Compute Attestation.\nWas this page helpful?","tokens":416,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259386562,"hash":"b0e7c7f428775ae5a70489197dd7cc691ae2c601"}
{"url":"https://docs.arbitrum.io/stylus","domain":"docs.arbitrum.io","title":"A gentle introduction to Stylus | Arbitrum Docs","text":"✏️Request an updateNew Stylus activations are pausedThe Arbitrum Security Council has temporarily paused new Stylus contract activations on Arbitrum One and Arbitrum Nova. Stylus contracts that are already activated keep running until they expire. To learn what this means for you, read Temporary pause on new Stylus activations.\nIn a nutshell:​\n\nStylus lets you write smart contracts in programming languages that compile to WASM, such as Rust, C, C++, and others, allowing you to use their ecosystem of libraries and tools. Language and tooling support exists for Rust. You can try the SDK and CLI with the quickstart.\nSolidity contracts and Stylus contracts are interoperable. In Solidity, you can call a Rust program and vice versa, thanks to a second, coequal WASM virtual machine.\nStylus contracts offer reduced gas costs for memory and compute-intensive operations because WASM programs execute more efficiently than EVM bytecode for these workloads.\n\nWhat's Stylus?​\nStylus is an upgrade to Arbitrum Nitro (ArbOS 32), the tech stack powering Arbitrum One, Arbitrum Nova, and Arbitrum chains. This upgrade adds a second, coequal virtual machine to the EVM, where EVM contracts continue to behave exactly as they would in Ethereum. This paradigm is called MultiVM because it is additive to existing functionality.\n\nThis second virtual machine executes WebAssembly (WASM) rather than EVM bytecode. WASM is a binary format used in web standards and browsers for efficient computation. Its design is to be portable and human-readable, with sandboxed execution environments for security. Working with WASM is nothing new for Arbitrum chains. Ever since the Nitro upgrade, WASM has been a fundamental component of Arbitrum's fraud proofs.\nWith a WASM VM, any programming language compilable to WASM is within Stylus's scope. In practice, some compilers are better suited to smart contract development than others. Rust has the first-class, fully supported SDK, and C and C++ are also supported. Any other language that compiles to WASM is theoretically possible, but support for those is experimental rather than officially maintained. Languages that include their own runtimes, like Python and JavaScript, are more complex for Stylus to support, although not impossible. WASM programs tend to be more efficient than EVM bytecode for memory-intensive applications. This efficiency comes from mature compiler toolchains for languages like Rust and C, which have benefited from decades of optimization work. The WASM runtime also executes faster than the EVM interpreter. Third-party contributions in the form of libraries for new and existing languages are welcome.\nHow Stylus works​\nBringing a Stylus program to life involves four stages: coding, activation, execution, and proving. The following sections describe each step.\nCoding​\nYou write your smart contract in any programming language that compiles to WASM. Rust has the most developed support with an open-source SDK for smart contract development. C and C++ are also supported, so that you can deploy existing contracts in those languages onchain with minimal modifications.\nThe Stylus SDK for Rust provides the development framework and language features for smart contract development. It also provides access to EVM-specific functionality used by smart contract developers.\nActivation​\nOnce you've written your contract, compile it to WASM using the Stylus CLI (or another compiler, like Clang for C/C++). Then you post the compiled WASM onchain.\nTo make your contract callable, it must undergo an activation process. During activation, the WASM compiles down to a node's native machine code (e.g., ARM or x86). This step also includes safety checks, such as gas metering, depth-checking, and memory charging, to ensure your program runs safely and can be fraud-proven.\nStylus measures computational costs using ink instead of gas. Ink works like gas but is thousands of times smaller. WASM executes faster than the EVM, so a single EVM operation takes as long as thousands of WASM operations. A finer-grained unit makes pricing more precise.\nInfoContract size: As of ArbOS61, Stylus contracts are not bound by the 24 KB EVM contract code limit. The maximum size of a Stylus contract is 96 KB — four times the limit for Solidity contracts on the EVM. This is enabled by a fragment-based deployment model; see Deploying contracts larger than 24 KB.Stylus contracts need to be reactivated once per year (365 days) or after any Stylus upgrade. You can do this using cargo-stylus or the ArbWasm precompile. If a contract isn't reactivated, it becomes uncallable. The 365-day expiry and a minimum age of about 31 days before a contract can be kept alive are both configurable chain parameters; these are the current defaults.\nExecution​\nWhen your Stylus program runs, it executes in a fork of Wasmer, a WebAssembly runtime. Because Wasmer compiles to native machine code, it executes faster than Geth's EVM bytecode interpreter. This performance difference reduces gas costs for compute-intensive operations.\nEVM contracts continue to work exactly as before. When a contract is called, the system checks whether it's an EVM contract or a WASM program and routes it to the appropriate runtime. Solidity and WASM contracts can call each other, so the language a contract was written in doesn't affect interoperability.\nProving​\nStylus builds on Nitro's fraud-proving technology. In normal operation, execution compiles to native code for speed. But if there's a dispute, the execution history compiles to WASM so validators can run interactive fraud proofs on Ethereum.\nWhat makes Stylus possible: Nitro can already replay and verify disputes using WASM. Stylus extends this capability to verify not just execution history, but also the WASM programs you deploy. The result is a system where any program compiled to WASM can be deterministically fraud-proven. For more details, see the Nitro architecture documentation.\nUse cases​\nStylus can integrate into existing Solidity projects by calling a Stylus contract to optimize specific parts of your app, or you can build an entire app with Stylus. Developers can also port existing applications written in Rust, C, or C++ to run onchain with minimal modifications. Here are some use cases where Stylus may be a good fit:\n\nOnchain verification with zero-knowledge proofs: Reduce gas costs for onchain verification using zero-knowledge proving systems. See case study for an example implementation.\nDeFi instruments: Implement custom pricing curves for AMMs, synthetic assets, options, and futures with onchain computation. You can extend existing protocols (such as Uniswap V4 hooks) or build your own.\nMemory and compute-intensive applications: Build onchain games, generative art, or other applications that benefit from reduced memory costs — Stylus programs can use up to 8 MB of memory, and costs grow near-linearly with the size of the workload. You can write the entire application in Stylus or optimize specific parts of existing Solidity contracts.\nCryptographic applications: Implement applications that require advanced cryptography or other compute-heavy operations that would be cost-prohibitive in Solidity.\n\nWhen Stylus saves gas (and when it doesn't)​\nStylus's gas advantage is concentrated in computation. Storage operations cost roughly the same as in the EVM, so storage-heavy contracts gain little by porting.\nQuick rule of thumb\nUse Stylus for compute-heavy logic: cryptography, math-heavy DeFi, ZK verification, in-memory algorithms, ports of existing Rust/C/C++ libraries.\nStick with Solidity when the contract mostly reads and writes storage with little computation in between — you won't see a meaningful gas reduction.\nHybrid approach: keep your storage layout in Solidity and call out to a Stylus contract for the compute-heavy hot paths.\n\nGetting started​\n\nFollow the quickstart to deploy your first Stylus contract, and explore the Rust SDK documentation.\nJoin the Stylus Developer Telegram group and Arbitrum Discord for community support.\nBrowse the Awesome Stylus repository for community-contributed projects, examples, and tools.\nSubscribe to the Stylus Saturdays newsletter for tutorials and technical content.\nIn a nutshell:What's Stylus?How Stylus worksCodingActivationExecutionProvingUse casesWhen Stylus saves gas (and when it doesn't)Getting started","tokens":2098,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259389368,"hash":"d26c4b366a97bc065d78c732739cbe3cea1beec3"}
{"url":"https://gov.optimism.io/t/mission-request-startup-support-optimism-as-venture-studio/8551","domain":"gov.optimism.io","title":"[MISSION REQUEST] Startup Support - Optimism as Venture Studio - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [MISSION REQUEST] Startup Support - Optimism as Venture Studio \n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 4\n min\n\n Jul 2024\n\n 1 / 9\n\n Jul 2024\n\n Jan 16\n\n post by jackanorak on Jul 8, 2024\n\n jackanorak\n\n Delegate Mission Request Summary\nThis mission aims to provide new business support for projects within the Optimism ecosystem, including projects with approved grants in previous governance seasons. This program will focus on delivering support for major back-office and dev concerns faced by new startups, things such as legal counseling, dev agency work, business formation, tax prep, and so on.\nS6 Intent 22: Intent 3\nProposing Delegate/Citizen:\nJackanorak\nTotal grant amount\n100k OP\nShould this Mission be fulfilled by one or multiple applicants:\nMultiple\nHow will this Mission Request help accomplish the above Intent?\nImagine the kind of support a startup incubator provides to startups; startups need this support, and the incubator has the size and resources to offer it. We can offer this kind of model.\nTake a highly promising project led by a handful of independent builders. They have some funds but not much—and, more importantly, they lack time and other resources to build out their project beyond what they are individually capable of managing.\nThere’s a lot they have to take care of or fund: audits, RPC costs, deployment costs, yes, but also business formation; legal preparation; payroll; fundraising. If they are deploying a token, there’s liquidity, treasury management, regulatory concerns, etc. The list goes on, but what unites these areas is that they are essential to new projects and often prohibitively resource-consuming. Audits, for example, are essential and expensive enough that many projects turn to fundraising specifically to afford them.\nThere are also business concerns that could, under the right circumstances, be addressed as part of this Mission: new venture strategy; business development; hiring; marketing, etc. Our bar is especially high for service providers in this sphere; there are many who claim to offer these services, but few can at the level we’d hope to be able to offer, which is at the top of our industry. It is of course also very difficult for a DAO to oversee this kind of service.\nAll of this is to say that proposals should consider, in concrete terms: who is the builder we’re targeting with our offer? How would our in-kind support help this kind of builder? What about this service we are offering is important or helpful enough for this builder to come deploy on Optimism or consider Optimism the best place to build? Do we have evidence that many new projects need help with this service? And, finally: are we the demonstrably the best at what we do?\nWhat is required to execute this Mission Request?\nApplicants should provide a commitment to providing some high-quality service in exchange for granted OP. These will include but are not limited to:\n– Free RPC coverage\n– Back office help, e.g., taxes, business formation, legal assistance, banking\n– Short-term agency development work\n\nPlans should provide a well-defined mechanism for compensation: for 50k OP, we will provide X, Y, Z.\nDistribution of these subsidized services to selected project grantees\n\nApplicants must be understood to be at the top of their respective fields. It is essential that we offer through them the kind of professional support that is time efficient and longitudinally beneficial for us as an ecosystem.\n\nHow should governance participants measure impact upon completion of this Mission?\nMilestones:\n\nNumber of projects supported\nNumber of external parties (e.g., lawyers) engaged\n\nMetrics\n\nNumber of projects successfully deployed and resulting transactions + users from them\nMarket value of services provided\nNPS from projects\n\nImpact\n\nDepends on what service is provided, but in general this should relate to some sort of expected market-based service that has been defrayed, enabling the use\nNumber of projects not requiring investor funding\n\nHas anyone other than the proposer contributed to this Mission Request?\nNo\nWhich metric will the success of this Mission Request be evaluated against?\nThe North star metric against which this Mission Request should be evaluated is the total amount of gas fees generated from the grantee’s contracts, because this Mission Request sets out to increase the aggregate demand for blockspace on the Superchain through a larger program. The total gas fees generated from this program act as a healthy indicator of its combined downstream performance. This metric was suggested by the Foundation and approved by the Grants Council.\n\n Voting Cycle Roundup #24\n\n Venture studio for Optimism projects, offered by Pollen Labs - General communication thread\n\n SEEDGov - Delegate Communication Thread\n\n Situation of Non-technical applications and Mission Requests\n\n Optimism Forum Weekly Recap - daospace: 07/08 - 07/14\n\n read \n\n 4\n min\n\n post by SuperchainEco on Jul 15, 2024\n\n SuperchainEco\n\n Exciting idea! It might be key to identify some verticals which we want to cover and split the budget between 2-3 teams that cover most of these vertical together!\nAs Superchain Eco / Kolektivo Labs we have significant Design, Strategy, Product and Events resources available - which we would love to offer to OP chains and OP projects at a reduced / free rate.\n\n post by teresacd on Jul 15, 2024\n\n teresacd\n\n I think this is a much-needed project, I´m only afraid that if it’s centralized in one sole “venture studio” a lot of the OP would you to its administrative support, or will be for the on-top fees over the actual service providers, would love to see what the community sees as top priorities from the ones mentioned above and see collectives apply. ex. a non-big law firm can’t see all the required jurisdictions projects may need.\n\n post by system on Jul 19, 2024\n\n system\n\n A North Star Metric has been added at the bottom of this Mission Request in an effort to enable the Collective to make data-driven decisions. By using a single metric for each Mission Request, the Collective is better able to evaluate the performance of all the Season 6 missions in a standardized manner, which will be critical when the Collective makes decisions about Intents, budgets, or other critical components of governance.\n\n post by drllau on Jul 19, 2024\n\n drllau\n\n Is Venture Studio looking for specialists functions or general business (advisory)? Wrt to say legal structuring, an example of specialist would be an entity generator like KaliDAO where you can form an separate entity for cost of gas (effectively ten’s of dollars). However, this requires a one-off capital charge to craft the docSet (cf TechStars seed docs) for the major jurisdictions (US, EU, UK-commonlaw, perhaps CN/IN?). Whereas a generalist is basically an ongoing service charge/fee (hundreds to thousands). So the budget is quite different for a capital investment (eg special-purpose vehicles for digital asset holding … input parameters and turn the crank=factory) vs business overhead (incl monitoring regulatory shifts).\nPS having mentored at JFDI (singapore’s premier accelerator) I’d point out the skill in selection (opportunity costs) way outweighs the back-end office functions unless you do a portfolio approach where statistically if you punt on hundreds of ventures, then it approaches unity of not losing $$ and a certain chance of getting 2-3x).\n\n post by Takeshi on Jul 22, 2024\n\n Takeshi\n\n Should governance of a L2 network involve itself in providing advisory to external projects?\nStuff like legal counseling, tax are external to Optimism L2’s functionality. Why should L2 dedicate its resources towards this?\nEven if projects need this, they should not depend on the L2’s treasury for funding these activities. The comparison with a venture capital firm offering this is not accurate IMO as VC firms are looking to build the valuation of their portfolio companies, while OP is looking to get more users, developers and activity on its network.\nMoreover some of the proposed services like legal would cost way above the earmarked funds of 100k OP.\nThis can potentially open up OP to unwanted liabilities down the road.\n\n 3 months later\n\n post by danielo on Oct 14, 2024\n\n danielo\n\n I’m trying to apply to this mission requests but charmverse seems broken (doesn’t allow me to submit saying a form response is invalid. I triple checked them… and can’t find the issue)\nAny other way to apply?\n\n post by Bunnic on Oct 15, 2024\n\n Bunnic\n\n Leader\n\n Hey @danielo, could you leave a link to the app so we can check it? (It won’t be accessible by anyone who is not the author or part of the Grants Council)\n\n 1 year later\n\n post by WakeUp_Labs on Jan 16\n\n WakeUp_Labs\n\n gmgm,\nWe wanted to share that, after being considered, posted on Charmverse, funded, assigned to a team, and executed, this initiative has successfully reached completion with very positive results.\nThe grant assigned to us was used to support a team called DAMM Capital, which runs on-chain DeFi strategies aimed at generating returns on specific investments, similar to how curators operate.\nSome of the vaults developed by the team, such as vaults designed to generate yield in $OP, operating purely on Optimism, had never been built before.\nThanks to this grant, we were able to help them build the front end that allows users to interact with these strategies, making the model they designed actually usable. While the auditing phase and other formal steps are still pending, we can now say the solution is live.\nIn the team’s own words, without the incentive provided through the OP Grant, the project would have been unlikely to move forward using only their own resources.\nFor anyone interested in a deeper look at the process, here’s an update thread on the Optimism forum detailing the full journey of the initiative:\n\nWe’re also sharing two public announcements, one from our side and one from DAMM Capital announcing the launch of the project:\n\nhttps://x.com/wakeuplabs/status/2008999249120281052\nhttps://x.com/DAMM_Capital/status/2008921763959250996\n\nWe hope this work meets the long-term metrics projected, especially in terms of transaction count, gas usage, and volume generated.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cycle 27 Intent 3A Mission Request and Sponsorship\n\n Governance Fund Missions\n\n cycle-27\n\n We will create this thread each cycle to follow new mission request proposals. \nSteps: \n\nCopy the provided template .\nCreate a new forum post, paste the template, and fill out all the questions.\nAdd the tag “S6 mission r…\n\n read more\n\n 18\n\n 755\n\n Sep 2024\n\n Optimism as Venture Studio: Mission Updates\n\n Grants Updates\n\n TL;DR\nWakeUp Labs is launching a new Optimism Mission to support projects through technical and strategic development services. As a Venture Studio funded by the Optimism Collective, we’re here to help projects go from c…\n\n read more\n\n 6\n\n 496\n\n Jan 15\n\n Optimism Forum Weekly Recap - daospace: 07/01 - 07/07\n\n Updates and Announcements 📢\n\n gm Optimism Collective \nThis week saw an even larger surge in forum activity with 27 new topics covering a wide range of discussions and initiatives. Key highlights include the “Optimism Dominance…\n\n read more\n\n 0\n\n 158\n\n Jul 2024\n\n [Deprecated] Grants-as-a-Service (GaaS)\n\n Governance Fund Missions\n\n Delegate Mission Request Summary\nWe propose establishing a Grants-as-a-Service (GaaS) Provider Network to streamline grant processes, enhance fund distribution, and accelerate application development across the Superchai…\n\n read more\n\n 3\n\n 367\n\n Jul 2024\n\n GovNFT Community Call Thread 3\n\n ✨ General\n\n season-6\n\n Hi GovNFT program participants! \nDuring the last community call, one of the topics discussed was the vote on rolling mission requests. If this passes, new mission requests will be able to be proposed during Season 6 (pre…\n\n read more\n\n 12\n\n 305\n\n Sep 2024","tokens":3033,"squid":"ink-governance","role":"Council Listener","at":1791259389637,"hash":"328eac7a9ee48b9d243ce44e57adfb39ca1ffdc5"}
{"url":"https://io.net/docs/guides/clouds/kubernetes-ingress-setup","domain":"io.net","title":"Ingress Setup - io.net","text":"This guide explains how to expose your applications to the internet on IO.net Kubernetes clusters using an ingress controller. It covers two common deployment options, DNS automation with ExternalDNS, and SSL certificate management with cert-manager.\n​Prerequisites\n\nkubectl access to your IO.net Kubernetes cluster\nHelm 3.x installed\nDomain ownership and DNS management access\nBasic understanding of Kubernetes concepts (Pods, Services, Ingress)\nFor ExternalDNS: API credentials for your DNS provider\n\n​Choosing the Right Method\nFactorDeployment + Service IPsDaemonSetSetup ComplexityMediumSimpleScalabilityHigh (flexible scaling)Limited (one pod per node)High AvailabilityRequires manual IP managementBuilt-in with multiple nodesResource UsageConfigurableFixed per nodeBest ForLarge-scale applicationsSimple deployments, edge cases\n​Option 1: Ingress Controller as Deployment with Service IPs\nThe ingress controller runs as a scalable Deployment exposed via a Service with assigned public IPs.\nTraffic is automatically balanced across ingress pods.\n[ Client ]\n |\n v\nConnects to node public IPs\n |\n v\nTraffic → balanced across ingress controller pods\n |\n v\nIngress controller routes to applications\n\nProsConsAutomatic load balancing across ingress controllers.Node failures affect assigned public IPs.No host port conflicts.Public IPs must be managed manually.Ingress controllers can scale flexibly.No automatic failover without extra tools.Cleaner setup for most applications.\n​Setup Steps\n​1. Install NGINX Ingress Controller as Deployment:\n\n⚠️ The Pod Security Admission plugin is automatically enabled in every io.net Kubernetes cluster to enforce Pod Security Standards and improve cluster security by default.\nYou can override the Pod Security Admission configuration at the namespace level. This is useful for workloads such as ingress controllers or monitoring solutions that require more relaxed security settings.\nHowever, the recommended approach is to adjust your applications to run securely using a proper podSecurityContext.\n\nkubectl create namespace ingress-nginx\nkubectl label namespace ingress-nginx pod-security.kubernetes.io/enforce=privileged\n\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\nhelm repo update\nhelm upgrade --install nginx-ingress ingress-nginx/ingress-nginx \\\n --namespace ingress-nginx \\\n --set controller.kind=Deployment \\\n --set controller.replicaCount=3 \\\n --set controller.resources.requests.cpu=100m \\\n --set controller.resources.requests.memory=128Mi \\\n --set controller.service.enabled=true \\\n --set controller.service.type=ClusterIP \\\n --set controller.publishService.enabled=false\n\n⚠️ Use nodeSelector and tolerations if you only want ingress on specific nodes.\n--set 'controller.tolerations[0].operator=Exists'\n--set 'controller.nodeSelector.node-role\\.kubernetes\\.io/hostname='\nUse affinity to ensure that pod replicas are scheduled on different nodes:\n--set 'controller.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[0].labelSelector.matchLabels.app\\.kubernetes\\.io/name=ingress-nginx'\n--set 'controller.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[0].topologyKey=kubernetes.io/hostname'\n\n​2. Edit the Service to assign public IPs:\n​\nkubectl patch svc nginx-ingress-ingress-nginx-controller --type=merge -p \"{\n \\\"spec\\\": {\n \\\"externalIPs\\\": [\n $(kubectl get nodes -l node-role.kubernetes.io/ingress \\\n -o jsonpath='{.items[*].status.addresses[?(@.type==\"InternalIP\")].address}' \\\n | tr ' ' ',' | sed 's/\\([^,]*\\)/\"\\1\"/g')\n ]\n }\n}\"\n\n​3. Update your DNS to point your domain to these EXTERNAL-IPs (kubectl get svc -n ingress-nginx), or follow the ExternalDNS guide below.\n​4. Deploy applications with Ingress resources for routing.\n​Option 2: Ingress Controller as DaemonSet (Direct on Every Node)\nThe ingress controller runs on every cluster node and listens directly on ports 80/443\nof each node’s public IP. Your domain can point to multiple node IPs.\n[ Client ]\n |\n v\nDNS round robin → node public IPs\n |\n +--> Node A: ingress controller (listens 80/443) → routes to applications\n +--> Node B: ingress controller (listens 80/443) → routes to applications\n +--> Node C: ingress controller (listens 80/443) → routes to applications\n\nProsConsSimple to set up.Relies on DNS round robin if no external load balancer.Every node can accept traffic directly.If a node goes down, DNS may still point to it until refresh.High availability with multiple node IPs.Ports 80/443 occupied on each node.Can combine with an external load balancer for smarter distribution.Scaling fixed to one ingress pod per node.\n​Step Setup\n​1. Install NGINX Ingress Controller as DaemonSet:\n\n⚠️ The Pod Security Admission plugin is automatically enabled in every io.net Kubernetes cluster to enforce Pod Security Standards and improve cluster security by default.\nYou can override the Pod Security Admission configuration at the namespace level. This is useful for workloads such as ingress controllers or monitoring solutions that require more relaxed security settings.\nHowever, the recommended approach is to adjust your applications to run securely using a proper podSecurityContext.\n\nkubectl create namespace ingress-nginx\nkubectl label namespace ingress-nginx pod-security.kubernetes.io/enforce=privileged\n\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\nhelm repo update\nhelm upgrade --install nginx-ingress ingress-nginx/ingress-nginx \\\n --namespace ingress-nginx \\\n --set controller.kind=DaemonSet \\\n --set controller.hostNetwork=true \\\n --set controller.publishService.enabled=false \\\n --set controller.dnsPolicy=ClusterFirstWithHostNet \\\n --set controller.resources.requests.cpu=100m \\\n --set controller.resources.requests.memory=128Mi \\\n --set controller.service.enabled=true \\\n --set controller.service.type=ClusterIP \\\n --set controller.service.clusterIP=None \\\n --set controller.admissionWebhooks.enabled=false\n\n⚠️ Using hostNetwork=true reserves ports 80/443 on every node. Use nodeSelector and tolerations if you only want ingress on specific nodes.\n--set 'controller.tolerations[0].operator=Exists'\n--set 'controller.nodeSelector.node-role\\.kubernetes\\.io/hostname='\n\n​2: Point your domain to the public IPs of all nodes, or follow the ExternalDNS guide below.\n​3: Deploy applications with Ingress resources for routing.\n​ExternalDNS Deployment\nExternalDNS automatically manages DNS records for all applications routed through your ingress controller.\nIt works with both Deployment and DaemonSet ingress setups.\n​1. Deploy ExternalDNS\n\nPopular DNS Providers: cloudflare, route53, google, digitalocean, vultr, etc.\n\n### Example for Cloudflare - https://kubernetes-sigs.github.io/external-dns/latest/docs/tutorials/cloudflare/\nkubectl create namespace external-dns\nkubectl create secret generic cloudflare-api-key -n external-dns --from-literal=apiKey=YOUR_API_KEY --from-literal=email=YOUR_CLOUDFLARE_EMAIL \n\nhelm repo add external-dns https://kubernetes-sigs.github.io/external-dns/\nhelm repo update\n\nhelm upgrade --install external-dns external-dns/external-dns \\\n --namespace external-dns \\\n --set txtOwnerId=mycluster \\\n --set provider.name=cloudflare \\\n --set 'env[0].name=CF_API_KEY' \\\n --set 'env[0].valueFrom.secretKeyRef.name=cloudflare-api-key' \\\n --set 'env[0].valueFrom.secretKeyRef.key=apiKey' \\\n --set 'env[1].name=CF_API_EMAIL' \\\n --set 'env[1].valueFrom.secretKeyRef.name=cloudflare-api-key' \\\n --set 'env[1].valueFrom.secretKeyRef.key=email'\n\n​2: Annotate the Ingress Controller Service\n​\nkubectl annotate svc nginx-ingress-ingress-nginx-controller \\\n -n ingress-nginx \\\n external-dns.alpha.kubernetes.io/hostname=\"*.example.com\"\n\nWildcard domains simplify DNS management for multiple applications.\nNo need to annotate each Ingress individually.\nDNS records are automatically updated when IPs change.\n\nBy default, ExternalDNS is deployed with the upsert-only policy, which allows it to create or update DNS records but never delete them. If you want ExternalDNS to also delete records, you can change the policy to sync.\n--set policy=sync\n\n​SSL/TLS Certificate Management\n​cert-manager with Let’s Encrypt (Recommended)\n​\nkubectl create namespace cert-manager\nkubectl label namespace cert-manager pod-security.kubernetes.io/enforce=privileged\n\n# Install cert-manager\nhelm repo add jetstack https://charts.jetstack.io\nhelm repo update\nhelm upgrade --install cert-manager jetstack/cert-manager \\\n --namespace cert-manager \\\n --set installCRDs=true\n\n### Example for Cloudflare - https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/\n\ncat <<EOF | kubectl apply -f -\napiVersion: v1\nkind: Secret\nmetadata:\n name: cloudflare-api-key-secret\n namespace: cert-manager\ntype: Opaque\nstringData:\n api-key: ${CLOUDFLARE_API_KEY}\n---\napiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n name: letsencrypt-prod\nspec:\n acme:\n email: ${cloudflare_email}\n server: https://acme-v02.api.letsencrypt.org/directory\n privateKeySecretRef:\n name: letsencrypt-dns01-private-key\n solvers:\n - dns01:\n cloudflare:\n email: ${cloudflare_email}\n apiKeySecretRef:\n name: cloudflare-api-key-secret\n key: api-key\nEOF\n\n​Quick Start: Hello World with HTTPS\n​1. Deploy the application\nkubectl create namespace hello\nkubectl run hello-world \\\n --image=k8s.gcr.io/echoserver:1.10 \\\n --port=8080 \\\n -n hello\n\n​2. Expose the application with a Service\nkubectl expose pod hello-world \\\n --type=ClusterIP \\\n --port=80 \\\n --target-port=8080 \\\n -n hello\n\n​3. Create an Ingress resource with HTTPS\n​\ncat <<EOF | kubectl apply -f -\napiVersion: networking.k8s.io/v1\nkind: Ingress\nmetadata:\n name: hello-ingress\n namespace: hello\n annotations:\n cert-manager.io/cluster-issuer: \"letsencrypt-prod\"\n nginx.ingress.kubernetes.io/ssl-redirect: \"true\"\nspec:\n ingressClassName: nginx\n tls:\n - hosts:\n - app.example.com\n secretName: hello-tls\n rules:\n - host: app.example.com\n http:\n paths:\n - path: /\n pathType: Prefix\n backend:\n service:\n name: hello-world\n port:\n number: 80\nEOF\n\n​4. Test the application\n\nExternalDNS automatically manages DNS if the ingress controller Service is annotated but it may take some time to synchronize DNS records.\nEnsure your domain points to the ingress public IP(s).\nOpen https://app.example.com/ in a browser to see “Hello World”.\n\n​Troubleshooting\n​Health Checks\n# Check ingress controller status\nkubectl get pods -n ingress-nginx\nkubectl logs -f deployment/nginx-ingress-ingress-nginx-controller -n ingress-nginx\n\n# Check ingress resources\nkubectl get ingress --all-namespaces\nkubectl describe ingress hello-ingress -n hello\n\n​Common Issues and Solutions\n​DNS Not Resolving\n​\n# Check DNS propagation\nnslookup app.example.com\ndig app.example.com\n\n# Check ExternalDNS logs\nkubectl logs -f deployment/external-dns -n external-dns\n\n​SSL Certificate Issues\n# Check certificate status\nkubectl get certificates --all-namespaces\nkubectl describe certificate hello-tls -n hello\n\n# Check cert-manager logs\nkubectl logs -f deployment/cert-manager -n cert-manager\n\n​Application Not Accessible\n# Check ingress configuration\nkubectl describe ingress hello-ingress -n hello\n\n# Test backend service directly\nkubectl port-forward svc/hello-world 8080:80 -n hello\n# Then test: curl localhost:8080\n\n# Check ingress controller logs\nkubectl logs -f deployment/nginx-ingress-ingress-nginx-controller -n ingress-nginx\n\n​High Resource Usage\n# Check resource usage\nkubectl top pods -n ingress-nginx\nkubectl describe pod <ingress-controller-pod> -n ingress-nginx\n\n# Adjust resource limits\nhelm upgrade nginx-ingress ingress-nginx/ingress-nginx \\\n --namespace ingress-nginx \\\n --set controller.resources.limits.cpu=2000m \\\n --set controller.resources.limits.memory=1Gi\n\n​Debug Commands\n# Get all ingress-related resources\nkubectl get all,ingress,certificates -n ingress-nginx\nkubectl get all,ingress,certificates -n your-app-namespace\n\n# Test connectivity\nkubectl run test-pod --image=busybox --rm -it -- sh\n# Inside pod: wget -O- http://your-service.namespace.svc.cluster.local\nWas this page helpful?","tokens":3007,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259400594,"hash":"f6257e0d701d15b9754f7a3adc895896d199d974"}
{"url":"https://gov.optimism.io/t/mission-request-startup-support-optimism-as-venture-studio/8551/9","domain":"gov.optimism.io","title":"[MISSION REQUEST] Startup Support - Optimism as Venture Studio - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 4\n min\n\n Jul 2024\n\n 9 / 9\n\n Jan 16\n\n Jan 16\n\n post by jackanorak on Jul 8, 2024\n\n jackanorak\n\n Delegate Mission Request Summary\nThis mission aims to provide new business support for projects within the Optimism ecosystem, including projects with approved grants in previous governance seasons. This program will focus on delivering support for major back-office and dev concerns faced by new startups, things such as legal counseling, dev agency work, business formation, tax prep, and so on.\nS6 Intent 22: Intent 3\nProposing Delegate/Citizen:\nJackanorak\nTotal grant amount\n100k OP\nShould this Mission be fulfilled by one or multiple applicants:\nMultiple\nHow will this Mission Request help accomplish the above Intent?\nImagine the kind of support a startup incubator provides to startups; startups need this support, and the incubator has the size and resources to offer it. We can offer this kind of model.\nTake a highly promising project led by a handful of independent builders. They have some funds but not much—and, more importantly, they lack time and other resources to build out their project beyond what they are individually capable of managing.\nThere’s a lot they have to take care of or fund: audits, RPC costs, deployment costs, yes, but also business formation; legal preparation; payroll; fundraising. If they are deploying a token, there’s liquidity, treasury management, regulatory concerns, etc. The list goes on, but what unites these areas is that they are essential to new projects and often prohibitively resource-consuming. Audits, for example, are essential and expensive enough that many projects turn to fundraising specifically to afford them.\nThere are also business concerns that could, under the right circumstances, be addressed as part of this Mission: new venture strategy; business development; hiring; marketing, etc. Our bar is especially high for service providers in this sphere; there are many who claim to offer these services, but few can at the level we’d hope to be able to offer, which is at the top of our industry. It is of course also very difficult for a DAO to oversee this kind of service.\nAll of this is to say that proposals should consider, in concrete terms: who is the builder we’re targeting with our offer? How would our in-kind support help this kind of builder? What about this service we are offering is important or helpful enough for this builder to come deploy on Optimism or consider Optimism the best place to build? Do we have evidence that many new projects need help with this service? And, finally: are we the demonstrably the best at what we do?\nWhat is required to execute this Mission Request?\nApplicants should provide a commitment to providing some high-quality service in exchange for granted OP. These will include but are not limited to:\n– Free RPC coverage\n– Back office help, e.g., taxes, business formation, legal assistance, banking\n– Short-term agency development work\n\nPlans should provide a well-defined mechanism for compensation: for 50k OP, we will provide X, Y, Z.\nDistribution of these subsidized services to selected project grantees\n\nApplicants must be understood to be at the top of their respective fields. It is essential that we offer through them the kind of professional support that is time efficient and longitudinally beneficial for us as an ecosystem.\n\nHow should governance participants measure impact upon completion of this Mission?\nMilestones:\n\nNumber of projects supported\nNumber of external parties (e.g., lawyers) engaged\n\nMetrics\n\nNumber of projects successfully deployed and resulting transactions + users from them\nMarket value of services provided\nNPS from projects\n\nImpact\n\nDepends on what service is provided, but in general this should relate to some sort of expected market-based service that has been defrayed, enabling the use\nNumber of projects not requiring investor funding\n\nHas anyone other than the proposer contributed to this Mission Request?\nNo\nWhich metric will the success of this Mission Request be evaluated against?\nThe North star metric against which this Mission Request should be evaluated is the total amount of gas fees generated from the grantee’s contracts, because this Mission Request sets out to increase the aggregate demand for blockspace on the Superchain through a larger program. The total gas fees generated from this program act as a healthy indicator of its combined downstream performance. This metric was suggested by the Foundation and approved by the Grants Council.\n\n Voting Cycle Roundup #24\n\n Venture studio for Optimism projects, offered by Pollen Labs - General communication thread\n\n SEEDGov - Delegate Communication Thread\n\n Situation of Non-technical applications and Mission Requests\n\n Optimism Forum Weekly Recap - daospace: 07/08 - 07/14\n\n read \n\n 4\n min\n\n post by SuperchainEco on Jul 15, 2024\n\n SuperchainEco\n\n Exciting idea! It might be key to identify some verticals which we want to cover and split the budget between 2-3 teams that cover most of these vertical together!\nAs Superchain Eco / Kolektivo Labs we have significant Design, Strategy, Product and Events resources available - which we would love to offer to OP chains and OP projects at a reduced / free rate.\n\n post by teresacd on Jul 15, 2024\n\n teresacd\n\n I think this is a much-needed project, I´m only afraid that if it’s centralized in one sole “venture studio” a lot of the OP would you to its administrative support, or will be for the on-top fees over the actual service providers, would love to see what the community sees as top priorities from the ones mentioned above and see collectives apply. ex. a non-big law firm can’t see all the required jurisdictions projects may need.\n\n post by system on Jul 19, 2024\n\n system\n\n A North Star Metric has been added at the bottom of this Mission Request in an effort to enable the Collective to make data-driven decisions. By using a single metric for each Mission Request, the Collective is better able to evaluate the performance of all the Season 6 missions in a standardized manner, which will be critical when the Collective makes decisions about Intents, budgets, or other critical components of governance.\n\n post by drllau on Jul 19, 2024\n\n drllau\n\n Is Venture Studio looking for specialists functions or general business (advisory)? Wrt to say legal structuring, an example of specialist would be an entity generator like KaliDAO where you can form an separate entity for cost of gas (effectively ten’s of dollars). However, this requires a one-off capital charge to craft the docSet (cf TechStars seed docs) for the major jurisdictions (US, EU, UK-commonlaw, perhaps CN/IN?). Whereas a generalist is basically an ongoing service charge/fee (hundreds to thousands). So the budget is quite different for a capital investment (eg special-purpose vehicles for digital asset holding … input parameters and turn the crank=factory) vs business overhead (incl monitoring regulatory shifts).\nPS having mentored at JFDI (singapore’s premier accelerator) I’d point out the skill in selection (opportunity costs) way outweighs the back-end office functions unless you do a portfolio approach where statistically if you punt on hundreds of ventures, then it approaches unity of not losing $$ and a certain chance of getting 2-3x).\n\n post by Takeshi on Jul 22, 2024\n\n Takeshi\n\n Should governance of a L2 network involve itself in providing advisory to external projects?\nStuff like legal counseling, tax are external to Optimism L2’s functionality. Why should L2 dedicate its resources towards this?\nEven if projects need this, they should not depend on the L2’s treasury for funding these activities. The comparison with a venture capital firm offering this is not accurate IMO as VC firms are looking to build the valuation of their portfolio companies, while OP is looking to get more users, developers and activity on its network.\nMoreover some of the proposed services like legal would cost way above the earmarked funds of 100k OP.\nThis can potentially open up OP to unwanted liabilities down the road.\n\n 3 months later\n\n post by danielo on Oct 14, 2024\n\n danielo\n\n I’m trying to apply to this mission requests but charmverse seems broken (doesn’t allow me to submit saying a form response is invalid. I triple checked them… and can’t find the issue)\nAny other way to apply?\n\n post by Bunnic on Oct 15, 2024\n\n Bunnic\n\n Leader\n\n Hey @danielo, could you leave a link to the app so we can check it? (It won’t be accessible by anyone who is not the author or part of the Grants Council)\n\n 1 year later\n\n post by WakeUp_Labs on Jan 16\n\n WakeUp_Labs\n\n gmgm,\nWe wanted to share that, after being considered, posted on Charmverse, funded, assigned to a team, and executed, this initiative has successfully reached completion with very positive results.\nThe grant assigned to us was used to support a team called DAMM Capital, which runs on-chain DeFi strategies aimed at generating returns on specific investments, similar to how curators operate.\nSome of the vaults developed by the team, such as vaults designed to generate yield in $OP, operating purely on Optimism, had never been built before.\nThanks to this grant, we were able to help them build the front end that allows users to interact with these strategies, making the model they designed actually usable. While the auditing phase and other formal steps are still pending, we can now say the solution is live.\nIn the team’s own words, without the incentive provided through the OP Grant, the project would have been unlikely to move forward using only their own resources.\nFor anyone interested in a deeper look at the process, here’s an update thread on the Optimism forum detailing the full journey of the initiative:\n\nWe’re also sharing two public announcements, one from our side and one from DAMM Capital announcing the launch of the project:\n\nhttps://x.com/wakeuplabs/status/2008999249120281052\nhttps://x.com/DAMM_Capital/status/2008921763959250996\n\nWe hope this work meets the long-term metrics projected, especially in terms of transaction count, gas usage, and volume generated.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cycle 27 Intent 3A Mission Request and Sponsorship\n\n Governance Fund Missions\n\n cycle-27\n\n We will create this thread each cycle to follow new mission request proposals. \nSteps: \n\nCopy the provided template .\nCreate a new forum post, paste the template, and fill out all the questions.\nAdd the tag “S6 mission r…\n\n read more\n\n 18\n\n 755\n\n Sep 2024\n\n Optimism as Venture Studio: Mission Updates\n\n Grants Updates\n\n TL;DR\nWakeUp Labs is launching a new Optimism Mission to support projects through technical and strategic development services. As a Venture Studio funded by the Optimism Collective, we’re here to help projects go from c…\n\n read more\n\n 6\n\n 496\n\n Jan 15\n\n Optimism Forum Weekly Recap - daospace: 07/01 - 07/07\n\n Updates and Announcements 📢\n\n gm Optimism Collective \nThis week saw an even larger surge in forum activity with 27 new topics covering a wide range of discussions and initiatives. Key highlights include the “Optimism Dominance…\n\n read more\n\n 0\n\n 158\n\n Jul 2024\n\n [Deprecated] Grants-as-a-Service (GaaS)\n\n Governance Fund Missions\n\n Delegate Mission Request Summary\nWe propose establishing a Grants-as-a-Service (GaaS) Provider Network to streamline grant processes, enhance fund distribution, and accelerate application development across the Superchai…\n\n read more\n\n 3\n\n 367\n\n Jul 2024\n\n GovNFT Community Call Thread 3\n\n ✨ General\n\n season-6\n\n Hi GovNFT program participants! \nDuring the last community call, one of the topics discussed was the vote on rolling mission requests. If this passes, new mission requests will be able to be proposed during Season 6 (pre…\n\n read more\n\n 12\n\n 305\n\n Sep 2024","tokens":3016,"squid":"ink-governance","role":"Council Listener","at":1791259400758,"hash":"82e66c2c26a7dd3b76ced378668f7bc0f5c5014c"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/arbos32","domain":"docs.arbitrum.io","title":"ArbOS 32 Bianca | Arbitrum Docs","text":"✏️Request an updatecautionPlease upgrade directly to ArbOS 32 from ArbOS 20 and not to ArbOS 30 or ArbOS 31. The ArbOS 32 release builds upon ArbOS 30 and ArBbOS 31 and includes critical fixes & optimizations coming out of rigorous testing and feedback from Stylus teams. ArbOS 32 “Bianca” will be the canonical ArbOS version for the “Bianca” family of releases.Future versions of Nitro may remove support for Arbitrum chains which have historically upgraded to, and remain on, ArbOS 30 or ArbOS 31. Due to this, we highly recommend upgrading immediately and directly to ArbOS 32.\nThe minimum Nitro version that supports ArbOS 32 \"Bianca\" is Nitro v3.3.1, which is available on Docker hub with the image tag: offchainlabs/nitro-node:v3.3.1-e326369. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova validators. For Arbitrum One and Nova, the ArbOS 32 \"Bianca\" upgrade required a governance vote to activate.\nPlease note that it is important that you only run the Nitro v3.3.1 against trusted databases. If you want to use an untrusted database, you can first remove the wasm directory if it exists (it might be inside the nitro folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. This is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker.\nThe Arbitrum docs will remain the canonical home for information regarding ArbOS releases, with more details found on the ArbOS Software Releases Overview page.\nRequirements:​\n\nNitro v3.3.1 or higher\nnitro-contracts v2.1.0 or higher\nWASM module root: 0x184884e1eb9fefdc158f6c8ac912bb183bf3cf83f0090317e0bc4ac5860baa39\n\nHigh-level description of ArbOS 32 changes​\nArbOS 32 Bianca is a major upgrade for Arbitrum chains. As a refresher, ArbOS upgrades can be treated as Arbitrum’s equivalent of a hard fork - more can be read about this subject over in Arbitrum ArbOS upgrades. Please note that ArbOS 21 Bianca is an upgrade that builds upon ArbOS 20 Atlas.\nArbOS 32 Bianca brings many features, improvements, and bug fixes to Arbitrum chains. A full list of changes can be found in the Nitro release notes for Nitro v3.3.1 or higher (as Nitro 3.3.1 is the endorsed Nitro node version for ArbOS 32 Bianca). Highlighted below are a few of the most impactful and critical features that are introduced with ArbOS 32 Bianca:\n\nAddition and subsequent activation of Stylus on Arbitrum chains through the addition of a new WebAssembly-based (WASM) virtual machine that runs alongside the EVM. Stylus enables developers to write smart contracts in new programming languages that compile to WASM, like Rust, that are more efficient and safer than Solidity smart contracts while retaining complete interoperability.\nAdding support for RIP-7212 decreases the costs of verifying the secp256r1 curve onchain by 99% when compared to current implementations, making secp256r1 verification more feasible for everyday use and enabling application developers and protocols to offer their users improved UX on Arbitrum One and Arbitrum Nova. Without this precompile, verifying this signature onchain is extremely expensive. Passkey-based wallets offer better security than a typical externally owned account (EOA) and cross-device support. Many wallets, notably apps using embedded wallets, have been requesting this feature for over a year.\n[Only relevant to Arbitrum Nova] Updated the transaction fee router contracts on Arbitrum Nova to allow for fees collected to be automatically sent to the ArbitrumDAO Treasury on Arbitrum One. Currently, the ArbitrumDAO receives Arbitrum Nova transaction fees that are sent to an ArbitrumDAO-controlled address that requires a constitutional proposal to move, which is less efficient. This change is specific to Arbitrum Nova and is not expected to impact Arbitrum chains.\nIntroduction of a new Fast Withdrawals feature for Arbitrum chains to achieve fast finality. This feature allows for transactions processed by a committee of validators to be unanimously confirmed as quickly as 15 minutes, as opposed to the default 6.4-day challenge period. While any Arbitrum chain can adopt Fast Withdrawals, we only recommend Fast Withdrawals for AnyTrust chains. Note that to enable this feature, separate steps must be followed (below).\n\nAdditional requirement for Arbitrum chains who wish to take advantage of the Stylus Cache Manager​\nStylus Cache ManagerIt is strongly recommended that teams upgrading to ArbOS 32 also spend the time following the instructions described below to deploy and enable the Stylus Cache Manager. Even if your team does not intend to build with Stylus in the immediate term, enabling the Cache Manager ensures that future usage of Arbitrum Stylus on your chain is smooth and provides a consistent UX with the developer experience of building with Arbitrum Stylus on Arbitrum One.\nSpecific to Stylus and ArbOS 32 \"Bianca\", we have developed a caching strategy that stores frequently accessed contracts in memory to reduce the costs and time associated with contract execution from repeated initializations. Check out the Stylus caching strategy docs to learn more.\nIn order to take advantage of this caching strategy, an additional step is required to deploy and enable it's use on your Arbitrum chain.\nAdditional requirement for Arbitrum chains who wish to enable Fast Withdrawals​\nAfter you have upgraded your Arbitrum chain to ArbOS 32 \"Bianca\" (i.e., you have fully completed Step 3 in the \"How to upgrade ArbOS on your Arbitrum chain\" guide for your Arbitrum chain), please follow these additional instructions in the chain-actions repository to deploy the Safe contract for the fast confirmation committee and set the Safe contract to be both the validator and fast confirmer on your rollup. Note that Fast Withdrawals is disabled by default unless explicitly set up and enabled by the Arbitrum chain owner/maintainer.\nReference links for ArbOS 32 Bianca​\n\nNitro v3.3.1\nArbOS 32 \"Bianca\" onchain Tally vote\nAIP: Activate Stylus and Enable Next-Gen WebAssembly Smart Contracts (ArbOS 32)\nAIP: Support RIP-7212 for Account Abstraction Wallets (ArbOS 32)\nAIP: Nova Fee Router Proposal (ArbOS 32)\nArbitrum Stylus Audit Report by Trail of Bits\nRequirements:High-level description of ArbOS 32 changesAdditional requirement for Arbitrum chains who wish to take advantage of the Stylus Cache ManagerAdditional requirement for Arbitrum chains who wish to enable Fast WithdrawalsReference links for ArbOS 32 Bianca","tokens":1625,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259410679,"hash":"87ea465015c3a39290b622c17c2e3ad540cd3c48"}
{"url":"https://io.net/docs/guides/clouds/kubernetes/optimizations","domain":"io.net","title":"Optimizations - io.net","text":"This section explains several infrastructure design decisions and provides guidance on how to optimize your Kubernetes cluster for performance and reliability.\n​Control Plane Architecture\nBy default, a Kubernetes cluster is provisioned with three CPU-only master (control plane) nodes running in a separate cloud environment from your worker nodes.\n​Why this design was chosen?\nThis architecture enables two key benefits:\n\nMinimum cluster size of one GPU VM: You can create a functional Kubernetes cluster with just a single GPU Virtual Machine, avoiding the cost of running multiple GPU nodes purely for control plane redundancy.\nImproved fault tolerance without extra GPU cost: Running three dedicated CPU-only master nodes provides higher availability for the control plane without requiring two or more expensive GPU VMs per cluster.\n\n​Untainted Master Nodes\nBy default, master nodes are not tainted. This means Kubernetes may schedule your workloads (pods) onto master nodes in the control plane cloud.\n​Why master nodes are not tainted by default\n\nReduce cluster creation time\nAllow clusters to become usable immediately without additional configuration.\n\n​Avoid Running Pods on Master Nodes\nRunning application pods on master nodes can lead to several issues, such as:\n\nRisk to control plane stability: Application workloads may interfere with critical Kubernetes components responsible for scheduling, networking, and cluster orchestration.\nIncreased latency: Because master nodes run in a separate cloud, communication between services may experience higher latency when one service runs on a master node and another runs on a worker node.\n\n​Recommended Optimisation - Taint Master Nodes\nTo prevent pods from being scheduled on master nodes, apply a taint to all control plane nodes.\nRun the following command:\nkubectl taint nodes -l node-role.kubernetes.io/control-plane node-role.kubernetes.io/control-plane=:NoSchedule\n\n​What this does\n\nPrevents application pods from being scheduled on master nodes.\nEnsures master nodes are reserved exclusively for control plane workloads.\nImproves performance isolation and overall cluster reliability.\nWas this page helpful?","tokens":544,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259410740,"hash":"cdcc228313313afedefd2e276a38962c8af43b7b"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/arbos51","domain":"docs.arbitrum.io","title":"ArbOS 51 Dia | Arbitrum Docs","text":"✏️Request an updateThis page is intended for all Arbitrum node operators and Arbitrum chain owners, it summarizes the changes brought by ArbOS 51 \"Dia\", and what you should do to ensure a seamless upgrade.\nThe minimum Nitro version that supports ArbOS 51 \"Dia\" is Nitro v3.9.6, which is available on Docker Hub with the image tag offchainlabs/nitro-node:v3.9.6-91bf578. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova node operators. For Arbitrum One and Nova, an ArbOS upgrade requires a governance vote to activate; the vote for ArbOS 51 was passed on December 18, 2025 and was activated on January 8, 2026.\nAs a refresher, ArbOS upgrades get treated as Arbitrum's equivalent of a hard fork. To learn more, refer to the Arbitrum ArbOS upgrades forum post. Note that ArbOS 51 Dia is an upgrade that builds upon ArbOS 40 Callisto.\nRequirements​\n\nHaving read and understood the ArbOS Software Releases Overview page.\nFollowing the Guide for how to upgrade ArbOS on your Arbitrum chain.\nRunning Nitro v3.9.6 or higher, which is available on Docker Hub with the image tag offchainlabs/nitro-node:v3.9.6-91bf578.\n\nNote that it's important to run Nitro v3.9.6 only against trusted databases. If you want to use an untrusted database, you can first remove the wasm directory if it exists (potentially inside the nitro folder). Otherwise, the database may have malicious, unvalidated code that can result in remote code execution. Avoiding unvalidated code is also mitigated by ensuring you run the Arbitrum Nitro node inside Docker.\n\nRunning nitro-contracts v3.1.0 or higher\n\nIf your chain isn't ready to activate BoLD, use nitro-contracts v2.1.3 instead; v3.0.0 or higher can't be used without activating BoLD.\nIf you want to enable Native Token Mint/Burn capabilities for your chain, you must use nitro-contracts v3.1.1 or higher.\n\nWASM module root (consensus-v51.1): 0xc2c02df561d4afaf9a1d6785f70098ec3874765c638e3cb6dbe8d3c83333e14c\nIf the Arbitrum chain posts blobs to a Fusaka-enabled Parent chain, ensure that the consensus layer client is configured correctly as per the Fusaka upgrade notice.\n\nHigh-level description of ArbOS 51 changes​\nArbOS 51 Dia is an upgrade for Arbitrum Chains to support the relevant EVM changes that are a part of Ethereum's Fusaka upgrade, as well as additional improvements to the gas pricing algorithm, MaxTxGasLimit allowing full block utilization, changes to instrument gas based on specific resource usage, native token mint/burn capabilities, and a few bug fixes. Ethereum's mainnet upgrade to Fusaka was completed on December 3, 2025 at epoch 411392.\nHere's the list of all changes included in ArbOS 51 Dia:\nEIP-7951: Precompile for secp256r1 curve support​\nThis EIP implements the same functionality and interface as RIP-7212, which was activated as part of ArbOS 31 Bianca. The main difference here is to add a point-at-infinity check and to update the comparison step in the signature verification algorithm. Developers should expect the same behavior as the EIP being proposed on Ethereum after Fusaka is activated.\nEIP-7825: Transaction gas limit cap​\nThis EIP introduces a gas cap for individual transactions. The goal is to ensure fairer access to block space and improve network stability. For Arbitrum One and Arbitrum Nova we're proposing a 32 million gas limit (Child chain execution gas, not including parent chain gas) per transaction, which is the same as the current block gas limit. This 32 million gas limit diverges from the EIP's proposed limit of 16 million gas per transaction for Ethereum parent chain. Arbitrum chains can customize this value according to their chains' needs.\nEIP-7642: eth/69 - history expiry and simpler receipts​\nThis networking upgrade removes deprecated fields used prior to Ethereum's Proof of Stake (PoS) transition. We're including this EIP as part of Geth upstream. This is a networking change that impacts mainly parent chain nodes. As Arbitrum nodes don't have a P2P layer, we don't expect this to have any impact on Arbitrum node operators.\nEIP-7939: Count leading zeros (CLZ) opcode​\nThis EIP adds a new CLZ (Count Leading Zeros) opcode to efficiently count the number of zero bits at the start of a 256-bit number. This is a fundamental mathematical operation used in many algorithms, especially for mathematical computations, data compression, and cryptographic operations. Currently, implementing this operation in Solidity requires complex and expensive code—this opcode makes it much cheaper and faster.\nEIP-7823: Set upper bounds for ModExp​\nThis EIP introduces an 8192-bit (1024 byte) limit on each input to the ModExp cryptographic precompile. ModExp has been a source of consensus bugs due to unbounded inputs. By setting practical limits that cover real-world use cases (like RSA verification), this reduces the testing surface area and paves the way for future replacement with more efficient EVM code.\nEIP-7883: ModExp gas cost increase​\nThis EIP increases the gas cost of the ModExp cryptographic precompile to address underpriced operations. It raises the minimum cost from 200 to 500 gas and doubles the costs for large inputs over 32 bytes.\nEIP-7910: eth_config JSON-RPC method​\nThis EIP provides a new RPC method that allows the Arbitrum Nitro node to respond with key configuration variables, offering node operators the ability to gain greater confidence that their Nitro nodes are correctly configured and prepared for upcoming forks. In future Nitro releases, we expect to include additional fields specific to Arbitrum chains. This update is at the RPC level and may be enabled later than the ArbOS 51 Dia upgrade.\nEIP-2537: Precompile for BLS12-381 curve operations​\nAs disclosed previously, the precompiled contracts for performing various operations over the BLS12-381 elliptic curve, including BLS Signature verification, were added but not properly enabled in ArbOS 40 Callisto as originally expected. ArbOS 51 Dia will now enable EIP-2537.\nArbOS block limit change: Effective block gas limit​\nSince ArbOS 51 introduces a MaxTxGasLimit, the State Transition Function (STF) will be relaxed in ArbOS 51 to allow the final transaction in a block to use up to the MaxTxGasLimit even if it would cause the block to exceed MaxBlockGasLimit. This means that the \"Effective Block Gas Limit\" is really MaxBlockGasLimit + MaxTxGasLimit. In previous versions of ArbOS, the Sequencer would skip transactions if the transaction request's GasLimit minus the parent chain data posting gas exceeded the gas remaining in the block.\nThe new algorithm is more efficient because the sequencer doesn't need to keep searching through the queue of transactions to find one that fits in the remaining block gas, and can continue to add transactions until the unused block gas is 0.\nThis change doesn't affect the GasTarget, and therefore doesn't affect how much overall gas per second the chain will use—only how transactions using that gas could be divided between different blocks.\nRaising the gas target, increasing the min L2 base fee, & improving the pricing algorithm​\nAs part of our strategy for scaling Arbitrum technology, the ArbOS 51 release includes a slight change to improve the pricing algorithm for Arbitrum One and Nova. This improvement is aimed at reducing the severity, frequency, and duration of high L2 gas prices during periods of elevated demand on the network. Concretely, the changes are to:\n\nReplace the current single gas target and single adjustment window, with a new model that employs multiple (higher) gas targets, measured over multiple adjustment windows.\nIncrease the default minimum L2 base fee from 0.01 gwei per gas to 0.02 gwei per gas.\n\nTo read more about this change, see the AIP for raising the gas target & improvements to the pricing algorithm.\nA constraint-based pricing change: STF instrumentation to track multi-gas​\nWe've instrumented Arbitrum's State Transition Function (STF) to track gas usage across multiple resource types including computation, storage access, storage growth, and history growth, rather than only a single total based on opcodes. This work lays the foundation for dynamic, constraint-based pricing where gas fees can adjust based on the most constrained resource at the network level. The goal is to create more stable prices, improve responsiveness to spikes, and allow the network to safely increase throughput without overloading node hardware. In this release, none of the constraints are enabled, so there won't be any impact on current gas prices. This update simply adds the ability to measure and record per-resource usage, with actual pricing changes coming in a later version once constraints are configured, benchmarked and tested.\nTo read more about this feature, see the dynamic pricing explainer.\nNative token mint and burn​\nNative token mint and burn is a feature that allows Arbitrum chains to use interoperability-enabled token standards (e.g., LayerZero OFTs, xERC20s, native USDC) as native gas tokens on their chains. Currently, Arbitrum chains are designed to \"lock and mint\" native gas tokens on the chain's canonical Bridge. However, doing so means that these \"locked and minted\" native gas tokens can't interact with third-party cross-chain adapter contracts. This new feature lets an Arbitrum chain delegate minting and burning of its native gas token to a trusted bridge provider (e.g., LayerZero OFT).\nNative token mint and burn is included in ArbOS 51 Dia for the benefit of Arbitrum chains (reducing the need for forks) and to streamline development and testing into a single codebase. There are no plans to enable this feature on Arbitrum One or Arbitrum Nova, consequently this feature will be explicitly left disabled for Arbitrum One and Arbitrum Nova.\nTo read more about this feature, see the Native Token Mint/Burn enablement guide.\nWarningIf you want to enable Native Token Mint/Burn capabilities for your chain, you must use nitro-contracts v3.1.0 or higher.\nA few bug fixes​\n\nArbOS didn't get updated for parent chain calldata price increase\n\nThis change standardizes the calculation of gas units for compressed Batch calldata across the codebase by replacing hard-coded values with a method call (tokenGasUnits).\n\nEIP-7702 precompile delegation behavior divergence\n\nPreviously, calls to precompiles could execute an INVALID opcode instead of succeeding with no execution. ArbOS 51 Dia will update code to align with EIP-7702 spec to treat precompile code as empty during delegation.\n\nARM and x86 divergence\n\nThis change adds a map to store transaction hash along with its gas used to bypass transaction execution for a problematic transaction execution which diverged between ARM and x86 architectures. This was added in to hardcode one transaction that caused the divergence on Arbitrum Sepolia, as disclosed in the security council emergency Action report.\nThe default WASM Stack Depth value in ArbOS is now set to 22,000, preventing new chains from encountering the same divergence issue.\n\nFusaka EIPs that aren't proposed to be in ArbOS 51 Dia​\nSupport and implementation for the following EIPs aren't planned to be part of ArbOS 51 Dia:\n\nEIP-7594, EIP-7918, and EIP-7892, since Arbitrum chains don't have blob data markets (though they do support posting blob data to a non-Arbitrum parent chain)\nEIP-7917, since Arbitrum chains don't have a beacon chain and therefore don't have a peer-to-peer layer like Ethereum does\nEIP-7934, this EIP is to help propagating blocks between nodes. Arbitrum doesn't do that—it sends messages (which are limited) and each node builds every block by itself\nEIP-7907, this EIP is no longer Scheduled For Inclusion (SFI) for Fusaka, as agreed upon by Client teams during ACDE 216 on July 17, 2025. We're currently exploring alternative ways to increase the Smart Contract size limit that don't interfere with the ability for Arbitrum chains to support EIP-7907 in the future. See this forum post reply for more details about this.\nEIP-7935, since Arbitrum chains already have a default gas target of 28Mgas/s and we have separate, alternative plans for increasing the gas limit through other means, as mentioned in Scaling Arbitrum everywhere.\n\nSpecial note about ArbOS 51 Dia for chains that haven't yet upgraded to use Arbitrum BoLD​\nWhile ArbOS 51 Dia will be compatible with both nitro-contracts 3.1.X and nitro-contracts 2.1.3, only chains that have Arbitrum BoLD enabled can use nitro-contracts 3.x. This requirement means that if your chain hasn't yet upgraded to use BoLD, only use nitro-contracts 2.1.3 for your ArbOS 51 Dia upgrade.\nSpecial note for chains posting data to EIP-7623 enabled parent chains​\nArbOS 51 introduces the gasFloorPerToken parameter for chains that post to EIP-7623-enabled parent chains. This setting enforces a minimum price for data-heavy transactions to ensure that the cost of posting calldata to the parent chain is fully recovered, even when execution gas is low.\nBackground on EIP-7623 support EIP-7623 was part of the Ethereum Pectra upgrade and it was intentionally not enabled for Arbitrum chains in ArbOS 40 Callisto. This is because block size variance is less of a concern on Arbitrum chains. \nHence, this setting does not apply to chains settling to Arbitrum One or Nova, but is required for chains settling to parent chains that have EIP-7623 enabled using calldata.\nRefer to gas floor per token guide for detailed instructions on how to configure this value via the ArbOwner precompile.\nReference links for ArbOS 51 Dia​\n\nGuide for how to upgrade ArbOS on your Arbitrum chain\nREADME for how to upgrade your rollup contracts to support ArbOS 51 on your chain\nNitro v3.9.6\nnitro-contracts v3.1.1\nnitro-contracts v2.1.3 (only relevant for Arbitrum chains that don't have BoLD enabled yet)\nOnchain vote to Activate ArbOS 51 (Dia) and Gas Pricing Updates\nTemperature check vote on Snapshot for \"AIP: ArbOS Version 50 Dia\"\nTemperature check vote on Snapshot for \"AIP: Raising the gas target & improvements to pricing algorithm\"\nForum post for \"AIP: ArbOS Version 50 Dia\"\nForum post for \"AIP: Raising the gas target & improvements to pricing algorithm\"\nArbOS 50 & ArbOS 51 Audit Report, from Trail of Bits\nRequirementsHigh-level description of ArbOS 51 changesEIP-7951: Precompile for secp256r1 curve supportEIP-7825: Transaction gas limit capEIP-7642: eth/69 - history expiry and simpler receiptsEIP-7939: Count leading zeros (CLZ) opcodeEIP-7823: Set upper bounds for ModExpEIP-7883: ModExp gas cost increaseEIP-7910: eth_config JSON-RPC methodEIP-2537: Precompile for BLS12-381 curve operationsArbOS block limit change: Effective block gas limitRaising the gas target, increasing the min L2 base fee, & improving the pricing algorithmA constraint-based pricing change: STF instrumentation to track multi-gasNative token mint and burnA few bug fixesFusaka EIPs that aren't proposed to be in ArbOS 51 DiaSpecial note about ArbOS 51 Dia for chains that haven't yet upgraded to use Arbitrum BoLDSpecial note for chains posting data to EIP-7623 enabled parent chainsReference links for ArbOS 51 Dia","tokens":3776,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259420611,"hash":"ea5b1f5c69283e7b0fe49723a4cce775548dc324"}
{"url":"https://io.net/docs/guides/clouds/kubernetes/exposing-to-the-internet","domain":"io.net","title":"Exposing Applications to the Internet - io.net","text":"This guide provides a comprehensive overview of how to expose applications to the internet on io.net Kubernetes Clusters using an ingress controller. It details two supported deployment approaches, outlines their respective advantages and trade-offs, and explains how DNS can be automated with ExternalDNS. The guide also covers SSL certificate management using cert-manager to support secure application delivery.\n​Prerequisites\n\nkubectl access to your io.net Kubernetes Cluster.\nHelm 3.x installed.\nDomain ownership and DNS management access.\nBasic understanding of Kubernetes concepts (Pods, Services, Ingress).\nFor ExternalDNS: API credentials for your DNS provider.\n\n​Selecting your Method\nThis table outlines the key factors to consider when choosing between Deployment + Service IPs and DaemonSet.\nKey FactorDeployment + Service IPsDaemonSetSetup ComplexityMediumSimpleScalabilityHigh, supports flexible scalingLimited, one pod per nodeHigh AvailabilityRequires manual IP managementBuilt-in with multiple nodesResource UsageConfigurableFixed per nodeBest ForLarge-scale applicationsSimple deployments, edge cases\n Option 1 Option 2​Option 1: Ingress Controller as a Deployment with Service IPsThe ingress controller is deployed as a scalable Kubernetes deployment and exposed via a LoadBalancer Service with manually assigned external IP addresses.Incoming traffic is automatically load-balanced across ingress pods. This approach is fully compatible with ExternalDNS.​Flow overview:[ Client ]\n |\n v\nConnects to node public IPs (set as externalIPs on LoadBalancer service)\n |\n v\nTraffic → balanced across ingress controller pods\n |\n v\nIngress controller routes to applications\n​How it works:\nService Type: LoadBalancer (required for ExternalDNS compatibility).\nExternal IPs: Manually assigned and mapped to the nodes where ingress pods are scheduled.\nDNS Management: ExternalDNS monitors the LoadBalancer Service and automatically creates DNS records that point to the configured external IPs.\nProsConsAutomatic load balancing across ingress controllers.Node failures impact the assigned public IPs.No host port conflicts.Public IPs must be managed manually.Ingress controllers can scale flexibly.No automatic failover without additional tools.Cleaner setup for most applications.​Step-by-Step Setup:1Install NGINX Ingress Controller as a DeploymentThe Pod Security Admission plugin is enabled by default in all io.net Kubernetes clusters to enforce Pod Security Standards and enhance baseline cluster security.You may override Pod Security Admission settings at the namespace level when necessary. This can be useful for workloads such as ingress controllers or monitoring solutions that require less restrictive security policies.However, the recommended approach is to adapt your applications to run securely by configuring an appropriate podSecurityContext.kubectl create namespace ingress-nginx\nkubectl label namespace ingress-nginx pod-security.kubernetes.io/enforce=privileged\n\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\nhelm repo update\nhelm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \\\n --namespace ingress-nginx \\\n --set controller.kind=Deployment \\\n --set controller.replicaCount=3 \\\n --set controller.resources.requests.cpu=100m \\\n --set controller.resources.requests.memory=128Mi \\\n --set controller.service.enabled=true \\\n --set controller.service.type=LoadBalancer \\\n --set controller.publishService.enabled=false \\\n --set-string controller.nodeSelector.worker-node=true\nThe ingress controller is configured to deploy only on worker nodes with the worker-node=true label.Optional: add Tolerations if your worker nodes have taints:--set 'controller.tolerations[0].operator=Exists'Optional: add Pod Anti-Affinity to ensure pod replicas are scheduled on different nodes (only if you have sufficient worker nodes):--set 'controller.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[0].labelSelector.matchLabels.app\\.kubernetes\\.io/name=ingress-nginx'--set 'controller.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution[0].topologyKey=kubernetes.io/hostname'2Assign Public IPs to Ingress NodesEdit the Service configuration so that Public IPs are assigned only from nodes where ingress pods are running.kubectl patch svc ingress-nginx-controller -n ingress-nginx --type=merge -p \"{\n \\\"spec\\\": {\n \\\"externalIPs\\\": [\n $(kubectl get pods -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx -o jsonpath='{.items[*].spec.nodeName}' \\\n | tr ' ' '\\n' | sort -u | while read node; do \\\n kubectl get node \"$node\" -o jsonpath='{.status.addresses[?(@.type==\"ExternalIP\")].address}'; \\\n echo; \\\n done | tr '\\n' ',' | sed 's/,$//' | sed 's/\\([^,]*\\)/\"\\1\"/g')\n ]\n }\n}\"\nThis command identifies the nodes currently running ingress controller pods and assigns their external IP addresses to the LoadBalancer Service. This allows ExternalDNS to correctly detect the service endpoints and manage the corresponding DNS records.3Update DNS RecordsPoint your domain to the Service’s EXTERNAL-IP values shown by kubectl get svc -n ingress-nginx, or follow the ExternalDNS Guide.4Deploy Applications with IngressDeploy your applications and configure ingress resources to handle routing to the appropriate services.​Option 2: Ingress Controller as a DaemonSetRun the ingress controller on every cluster node, where it listens directly on ports 80 and 443 of each node’s public IP. Your domain can be configured to point to multiple node IPs for traffic ingress.​Flow overview:[ Client ]\n |\n v\nDNS round robin → node public IPs\n |\n +--> Node A: ingress controller (listens 80/443) → routes to applications\n +--> Node B: ingress controller (listens 80/443) → routes to applications\n +--> Node C: ingress controller (listens 80/443) → routes to applications\n​How it works:\nWorkload Type: DaemonSet (one ingress controller pod per node).\nTraffic Exposure: The ingress controller listens directly on ports 80/443 of each node’s public IP.\nDNS Management: DNS records are configured to point directly to the public IPs of all nodes running the ingress controller (for example, using DNS round-robin).\nProsConsSimple and straightforward to set up.Relies on DNS round robin when no external load balancer is used.Every node can accept traffic directly.DNS records may continue to point to unavailable nodes until they are refreshed.High availability through multiple node public IPs.Ports 80/443 are reserved on every node.Can combine with an external load balancer for a more advanced traffic distribution.Scaling is limited to one ingress pod per node.​Step-by-Step Setup:1Install NGINX Ingress Controller as a DaemonSetThe Pod Security Admission plugin is enabled by default in all io.net Kubernetes clusters to enforce Pod Security Standards and enhance baseline cluster security.You may override Pod Security Admission settings at the namespace level when necessary. This can be useful for workloads such as ingress controllers or monitoring solutions that require less restrictive security policies.However, the recommended approach is to adapt your applications to run securely by configuring an appropriate podSecurityContext.kubectl create namespace ingress-nginx\nkubectl label namespace ingress-nginx pod-security.kubernetes.io/enforce=privileged\n\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\nhelm repo update\nhelm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \\\n --namespace ingress-nginx \\\n --set controller.kind=DaemonSet \\\n --set controller.hostNetwork=true \\\n --set controller.publishService.enabled=false \\\n --set controller.dnsPolicy=ClusterFirstWithHostNet \\\n --set controller.resources.requests.cpu=100m \\\n --set controller.resources.requests.memory=128Mi \\\n --set controller.service.enabled=true \\\n --set controller.service.type=ClusterIP \\\n --set controller.service.clusterIP=None \\\n --set controller.admissionWebhooks.enabled=false \\\n --set-string controller.nodeSelector.worker-node=true\nUsing hostNetwork=true reserves ports 80/443 on every node. Use nodeSelector and tolerations if you only want ingress on specific nodes.--set 'controller.tolerations[0].operator=Exists'--set 'controller.nodeSelector.node-role\\.kubernetes\\.io/hostname='2Configure DNS for Node IPsPoint your domain to the public IPs of all nodes running the ingress controller, or follow the ExternalDNS Guide.3Deploy Applications with IngressDeploy your applications and define Ingress resources to route incoming traffic to the appropriate services.\n​SSL/TLS Certificate Management\nWhen exposing applications to the internet through a Kubernetes ingress controller, SSL/TLS certificates are required to securely terminate HTTPS traffic. cert-manager automates the issuance and renewal of certificates from Let’s Encrypt, integrating directly with Kubernetes Ingress resources to provide end-to-end HTTPS without manual certificate management.\nIn the setup below, cert-manager is installed in the cluster and configured to use a DNS-01 challenge, which is well suited for internet-facing applications, wildcard domains, and environments where ingress traffic reaches services through public IPs.\nThe following examples show how to install cert-manager and configure it with Cloudflare as the DNS provider.\nRead more: https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/\n​cert-manager with Let’s Encrypt (Recommended)\nkubectl create namespace cert-manager\nkubectl label namespace cert-manager pod-security.kubernetes.io/enforce=privileged\n\n# Install cert-manager\nhelm repo add jetstack https://charts.jetstack.io\nhelm repo update\nhelm upgrade --install cert-manager jetstack/cert-manager \\\n --namespace cert-manager \\\n --set installCRDs=true\n\n### Example for Cloudflare - https://cert-manager.io/docs/configuration/acme/dns01/cloudflare/\n\ncat <<EOF | kubectl apply -f -\napiVersion: v1\nkind: Secret\nmetadata:\n name: cloudflare-api-key-secret\n namespace: cert-manager\ntype: Opaque\nstringData:\n api-key: ${CLOUDFLARE_API_KEY}\n---\napiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n name: letsencrypt-prod\nspec:\n acme:\n email: ${cloudflare_email}\n server: https://acme-v02.api.letsencrypt.org/directory\n privateKeySecretRef:\n name: letsencrypt-dns01-private-key\n solvers:\n - dns01:\n cloudflare:\n email: ${cloudflare_email}\n apiKeySecretRef:\n name: cloudflare-api-key-secret\n key: api-key\nEOF\n\n​Example for Cloudflare with API Token (Recommended)\nShow Examplecat <<EOF | kubectl apply -f -\napiVersion: v1\nkind: Secret\nmetadata:\n name: cloudflare-api-token-secret\n namespace: cert-manager\ntype: Opaque\nstringData:\n api-token: ${CLOUDFLARE_API_TOKEN}\n---\napiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n name: letsencrypt-prod\nspec:\n acme:\n email: ${YOUR_EMAIL}\n server: https://acme-v02.api.letsencrypt.org/directory\n privateKeySecretRef:\n name: letsencrypt-dns01-private-key\n solvers:\n - dns01:\n cloudflare:\n apiTokenSecretRef:\n name: cloudflare-api-token-secret\n key: api-token\nEOF\n\n​Example for Cloudflare with API Key\nShow Examplecat <<EOF | kubectl apply -f -\napiVersion: v1\nkind: Secret\nmetadata:\n name: cloudflare-api-key-secret\n namespace: cert-manager\ntype: Opaque\nstringData:\n api-key: ${CLOUDFLARE_API_KEY}\n---\napiVersion: cert-manager.io/v1\nkind: ClusterIssuer\nmetadata:\n name: letsencrypt-prod\nspec:\n acme:\n email: ${CLOUDFLARE_EMAIL}\n server: https://acme-v02.api.letsencrypt.org/directory\n privateKeySecretRef:\n name: letsencrypt-dns01-private-key\n solvers:\n - dns01:\n cloudflare:\n email: ${CLOUDFLARE_EMAIL}\n apiKeySecretRef:\n name: cloudflare-api-key-secret\n key: api-key\nEOF\n​\nFor an end-to-end HTTPS application example, refer to Quick Start: Hello World with HTTPS.\n​Troubleshooting\n​Health Checks\nCheck Ingress Controller Statuskubectl get pods -n ingress-nginx\nkubectl logs -f deployment/nginx-ingress-ingress-nginx-controller -n ingress-nginx\nCheck Ingress Resourceskubectl get ingress --all-namespaces\nkubectl describe ingress hello-ingress -n hello\n\n​Common Issues and Solutions\nDNS Not Resolving# Check DNS propagation\nnslookup app.example.com\ndig app.example.com\n\n# Check ExternalDNS logs\nkubectl logs -f deployment/external-dns -n external-dns\nSSL Certificate Issues# Check certificate status\nkubectl get certificates --all-namespaces\nkubectl describe certificate hello-tls -n hello\n\n# Check cert-manager logs\nkubectl logs -f deployment/cert-manager -n cert-manager\nApplication Not Accessible# Check ingress configuration\nkubectl describe ingress hello-ingress -n hello\n\n# Test backend service directly\nkubectl port-forward svc/hello-world 8080:80 -n hello\n# Then test: curl localhost:8080\n\n# Check ingress controller logs\nkubectl logs -f deployment/nginx-ingress-ingress-nginx-controller -n ingress-nginx\nHigh Resource Usage# Check resource usage\nkubectl top pods -n ingress-nginx\nkubectl describe pod <ingress-controller-pod> -n ingress-nginx\n\n# Adjust resource limits\nhelm upgrade nginx-ingress ingress-nginx/ingress-nginx \\\n --namespace ingress-nginx \\\n --set controller.resources.limits.cpu=2000m \\\n --set controller.resources.limits.memory=1Gi\nDebug Commands# Get all ingress-related resources\nkubectl get all,ingress,certificates -n ingress-nginx\nkubectl get all,ingress,certificates -n your-app-namespace\n\n# Test connectivity\nkubectl run test-pod --image=busybox --rm -it -- sh\n# Inside pod: wget -O- http://your-service.namespace.svc.cluster.local\nWas this page helpful?","tokens":3362,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259421994,"hash":"96579b3c199b06a9d4aa006e09e30241ea17dc4d"}
{"url":"https://gov.optimism.io/t/builder-grant-proposal-op-security-proxy-local-pre-execution-revert-interception-for-the-superchain/10845","domain":"gov.optimism.io","title":"[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain \n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n Sep 4\n\n 1 / 5\n\n Sep 3\n\n 27d ago\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions before broadcasting to OP Stack nodes. On EVM rollups, end users and automated agents pay gas fees even when transactions revert on chain due to stale oracle states, localized slippage, or sandwich attacks. For retail users, burning gas on a failed execution creates frustration, and for wallet teams it leads to avoidable support tickets.\nThe proxy sits between standard wallets or clients and public Optimism RPC nodes. When a client issues an eth_sendRawTransaction request, the proxy intercepts the raw payload and simulates it in process using revm against current chain state. If the simulation executes successfully, the transaction is forwarded upstream to the sequencer over an existing hyper connection pool. If the simulation reverts, the proxy aborts the broadcast completely so zero gas is burned on chain, and immediately returns a standard JSON-RPC error containing decoded Solidity custom errors or panic codes along with an estimated gas saved metric.\nThe core implementation is open-source under the MIT license with 40 automated tests passing across the Rust core and TypeScript client SDK. In empirical benchmarks against mainnet.optimism.io, the proxy introduces a minimal 11.8 millisecond processing overhead on fair keep-alive connections with session reuse. For clients that make cold requests without connection reuse, the proxy internal connection pool eliminates repetitive TLS 1.3 handshakes to remote endpoints, amortizing roundtrip latency by roughly 97 milliseconds. The full reproduction methodology and raw telemetry logs are recorded in BENCHMARK_RESULTS.md (https://github.com/Ishant5436/op-sec-proxy/blob/main/BENCHMARK_RESULTS.md).\nUncached transaction simulation over public internet RPC currently averages approximately 2.7 seconds because the execution engine must fetch contract state slots across the network during execution. I am requesting 10,000 OP for an initial builder grant to fund three engineering milestones over the next three months. The initial phase tackles state caching, replacing network RPC state queries with a local in-memory LRU trie cache for warm contract bytecode and storage slots to drive simulation latency down toward a sub-65 millisecond target. Following that, work shifts to developer adoption with a TypeScript provider wrapper and standardized error decoding for wallet integrations. The final phase expands routing across OP Mainnet, Base, Mode, Zora, and Fraxtal alongside reproducible Docker containers and systemd service packaging for node operators.\nAs an individual engineer, I rely on Rust memory safety guarantees, cargo-audit automated dependency scanning, and reproducible GitHub Actions workflows rather than corporate support infrastructure. All code is public and modular. I previously shared an introductory post in the general discussion section of the governance forum under thread 10810 (OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions), and this grant application will allow me to build and package the middleware as a permanent, zero-cost public good for the Superchain ecosystem.\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n 4\n\n post by Anzus_GemWallet on Sep 4\n\n Anzus_GemWallet\n\n From a user-support perspective, how will the proxy handle cases where the local simulation is based on slightly stale state but the transaction might still succeed on-chain? It would be useful to understand whether the default behavior is to fail open, and how the wallet communicates simulation uncertainty versus a definite revert.\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Regarding stale state and transient boundaries, the proxy strictly defaults to fail-open whenever there is execution ambiguity or when a simulation fails due to state retrieval timeouts or RPC sync lags. If the proxy cannot deterministically prove a failure against the current block header, it logs the warning and forwards the raw transaction directly upstream to the sequencer so user submissions are never blocked by middleware latency or momentary node lag.\nFor transaction categorization, the proxy distinguishes between invariant contract panics and state-dependent reverts. Static reverts such as invalid signatures, nonce mismatches, unauthorized access, or insufficient balance are deterministic and will fail regardless of whether the head moved by a block. In those cases, the proxy returns a standard -32000 error with the decoded reason and flags the simulation as definite.\nState-dependent reverts, such as slippage limits on decentralized exchanges or time-sensitive oracle feeds, are where stale state matters most. When revm returns a revert from a condition that depends on volatile storage slots, the proxy includes an uncertainty flag in the JSON-RPC error payload under data.confidence set to uncertain alongside the block number used for simulation. In the TypeScript provider wrapper, wallets can inspect this field to decide how to treat the result. For instance, a wallet can show a clear distinction between a transaction that is guaranteed to revert versus one that failed due to potential slippage drift at the head, or choose to pass uncertain transactions upstream automatically with a warning notice in the user interface.\n\n post by Cypherin on Sep 6\n\n Cypherin\n\n Anzus_GemWallet\n\n A quick update for the review team following up on the discussion above. The simulation confidence classification and fail-open behavior discussed here are now fully implemented and passing in the public repository under commit 8376212.\nWhen revm encounters transient database or RPC connection timeouts, the proxy classifies the execution as uncertain and automatically forwards the raw transaction directly upstream to the sequencer when fail-open is enabled, ensuring zero user drop-offs. If a wallet wishes to inspect or handle the simulation result, the JSON-RPC error payload returns the confidence rating along with decoded contract reverts. The TypeScript client library at @op-sec/client has also been updated with these types, and all unit, integration, and linter checks pass with zero warnings across 32 tests.\n\n post by Cypherin on Sep 8\n\n Cypherin\n\n A quick procedural update for the review team: project metadata and repository ownership verification have now also been completed and published onchain via OP Atlas at https://atlas.optimism.io/project/0x6ab1a8cbf07a602a09c6e754b34361f336ba8e62c1a4792659d7b5ac4a27663b.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n ✨ General\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 106\n\n Sep 4\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Grant Application: superchain-guard\n\n Grants Updates\n\n season-8,season-9\n\n Project Name: superchain-guard — The Security Frontier for Interoperable Intents \nApplicant: ILE Labs (ILE-Labs · GitHub) \nProgram: Season 9 Growth Grants (Infrastructure Category) \n\nExecutive Summary\nOptimism is enterin…\n\n read more\n\n 6\n\n 213\n\n May 19\n\n [MISSION REQUEST] Open-source transaction simulator\n\n Governance Fund Missions\n\n Title: Open-source transaction simulator\nDelegate Mission Request Summary: \nThis mission is intended to provide a key, critical piece of tooling - simulating transactions before they go onchain. Tenderly provides a great…\n\n read more\n\n 3\n\n 522\n\n Aug 2025\n\n Upgrade Proposal #13: OPCM and Incident Response improvements\n\n Protocol Upgrade\n\n Executive Summary\nHi I’m Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej (@0xEscanor) and @Kelvin from the OP Labs Team. \nThis proposal is intended to be voted on in cycle…\n\n read more\n\n 19\n\n 1.4k\n\n Mar 2025","tokens":2224,"squid":"ink-governance","role":"Council Listener","at":1791259422099,"hash":"584f6355fc04c5d1dcbf31abc6d0ce63d3b6d7ec"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/arbos20","domain":"docs.arbitrum.io","title":"ArbOS 20 Atlas | Arbitrum Docs","text":"✏️Request an updateArbOS 20 Atlas is shipped via Nitro v2.3.1, which is available on Docker hub with the image tag: offchainlabs/nitro-node:v2.3.1-26fad6f. This release of Nitro is a mandatory upgrade for Arbitrum One and Nova validators. For Arbitrum One and Nova, the ArbOS 20 upgrade requires a governance vote to activate.\nFor an index of all ArbOS releases and upgrade expectations, see the ArbOS Software Releases Overview. ArbOS 20 Atlas builds upon ArbOS 11.\nRequirements:​\n\nNitro v2.3.1 or higher\nnitro-contracts v1.2.1 or higher\nWasm module root: 0x8b104a2e80ac6165dc58b9048de12f301d70b02a0ab51396c22b4b4b802a16a4\nAccess to the Ethereum Beacon Chain APIs, either from your own self-managed parent chain Ethereum node or from a 3rd party provider like those on this list.\n\nHigh-level description of ArbOS 20 changes​\nArbOS 20 is an upgrade to enable Arbitrum's support for the parent chain Ethereum's Dencun upgrade scheduled for March 2024. As a result, all of the ArbOS specific changes revolve around implementing the majority of the Cancun EIPs on Arbitrum:\n\nEnable Arbitrum chains to batch and post transaction data in the form of Blobs to the parent chain Ethereum, to support EIP-4844. This includes updates to the Sequencer Inbox contract to support posting transactions in the form of blobs, updating Nitro's fraud prover to support proving additional hashes (KZG and SHA256 preimages), and updates to the core Nitro node software to handle parsing data from EIP-4844 blobs.\nAddition of the TSTORE and TLOAD EVM opcodes introduced in EIP-1153 offering a cheaper option than storage for data that’s discarded at the end of a transaction.\nAddition of the MCOPY EVM opcode introduced in EIP-5656 for cheaper memory copying.\nChanges to the SELFDESTRUCT EVM opcode to reflect the behavior on the parent chain Ethereum, as outlined in EIP-6780.\nAddition of a batch poster manager role that will have the ability to grant and revoke batch-posting affordances. This role is assigned to the operator of the sequencer to allow the batch poster manager perform key rotations for the batch posters. The DAO will continue to have the ability to revoke the seqauencer role, meaning there is no change to the current system's trust model since the DAO ca update the batch poster manager at any time (along with any batch posters).\nIncreasing the max block height that a batch can be posted, relative to the current block, to 64 bringing this in line with Ethereum's finality guarantees. The current value of 12 was set prior to the Ethereum merge and could mean that a small parent chain reorg can cause an otherwise valid batch to revert.\nFix Sequencer Inbox bug: when posting a batch, the Sequencer provides the \"newMessageCount” value as a parameter; if the Sequencer is malicious, it can provide the max uint256 value which in turn would make subsequent calls to forceInclusion revert with an overflow error. Atlas’s upgrade to the Sequencer inbox includes a change) in which forceInclusion does not modify the message count, fixing this bug. This bug had been disclosed to Arbitrum RaaS providers and to the Arbitrum DAO Security Council.\n\nSpecial notes on ArbOS 20: Atlas support for EIP-4844​\n\nUpgrading to the Atlas ArbOS release will require access to the parent chain's Ethereum beacon chain endpoints to retrieve blob data. For nodes of a chain that come online 18 days after Atlas gets activated on their chain will need access to historical data to sync up to the latest state. If you are not operating your own Ethereum consensus client, please visit this page to view a list of beacon chain RPC providers where you can access blob data.\nApplications on Arbitrum will not have to be modified or take any explicit action to get the benefits of using EIP-4844 (i.e., the whole chain opts-in with ArbOS 20 “Atlas”).\nArbOS 20 “Atlas” adds support for Arbitrum chains to send data in a blob storage format to data availability layers, like the parent chain Ethereum, that support the blob transaction type. This includes Arbitrum One and Arbitrum Nova. ArbOS 20 “Atlas” does not add support for Arbitrum chains to receive data in a blob storage format. This means that an L3 Arbitrum chain on top of an Arbitrum L2 will use calldata when posting L3 transaction data to the underlying L2. The child chain (L2) Arbitrum chain will then be able to post data to a parent chain data availability layer like Ethereum using blobs.\nThere currently aren’t estimates on what the end-user gas savings of using blob data will be. This topic is something being actively worked on and monitored. Without Mainnet data, the estimates for blob gas prices will not be accurate enough to reliably predict the cost reductions that users will experience—and even with Mainnet data, the savings will vary by use case (i.e., no current way to predict the price impacts from all blob gas market participants yet). In general, however, the use of blobs will reduce the cost of using Arbitrum L2s. To learn more about what EIP-4844 will mean for the child chain users, please checkout this blog post on Medium by Offchain Lab's Co-foudner and Chief Scientist Ed Felten.\n\nBlock explorers​\nBelow is a non-comprehensive list of explorers that support querying and viewing blob data on Ethereum that get posted by Arbitrum child chain chains.\n\nBlockscout. For self-deployment, blobs are supported as of blockscout v6.2.0 and blockscout-frontend v1.2.6.\nArbiscan\nBlobscan\nBeaconcha.in\n\nAdditional requirement for Arbitrum L2 chain operators: enabling blob batch posting​\nThis section maps to Step 4 in the guide on How to upgrade ArbOS on your Arbitrum L2 chain and contains additional instructions for Arbitrum L2 chain operators for ArbOS 20 Atlas. Specifically, the details below are meant to help Arbitrum L2 chain operators enable blob batch posting to L1 Ethereum following their successful upgrade to the ArbOS 20 Atlas release.\ncautionBefore proceeding, make sure you have successfully completed Steps 1 through 3 of the guide on How to upgrade ArbOS on your Arbitrum chain.To enable the posting of transaction data in Blobs to L1 Ethereum, please refer to the Enable post-4844 blobs section of the Arbitrum chain configuration guide.Reference links for ArbOS 20 Atlas​\nNitro v2.3.1 Release details on Github\nOriginal DAO proposal: AIP: ArbOS Version 20 \"Atlas\"\nAIP: ArbOS Version 20 \"Atlas\" Snapshot Vote\nFormal Tally (onchain) vote for AIP: ArbOS Version 20\nArbOS 20 Atlas Audit Report by Trail of Bits\nRequirements:High-level description of ArbOS 20 changesSpecial notes on ArbOS 20: Atlas support for EIP-4844Block explorersAdditional requirement for Arbitrum L2 chain operators: enabling blob batch postingReference links for ArbOS 20 Atlas","tokens":1684,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259430553,"hash":"ad3584dad77f3defda065ec8ba40132ee2b984f1"}
{"url":"https://io.net/docs/guides/clouds/deploy-containers","domain":"io.net","title":"Deploy CaaS - io.net","text":"io.net offers a simple and powerful interface for deploying containers using high-performance infrastructure. Whether you are running inference, training models, or hosting APIs, the Containers system gives you flexibility and speed.\nThis guide will help you deploy using IO Cloud API keys on our CaaS clusters. For detailed API usage, refer to our API Reference.\nSupport for AWS ECR private images is not available at this time for CaaS.\n\n​Deploy Container\nClick the Deploy Container button to launch a wizard that guides you through the deployment process.\n\n​Container Deployment Wizard\n​Step 1: Basic Deployment Settings\nConfigure your container:\n\nContainer Image (required) Example: myorg/myimage:latest\n\nImage Type\n\nPublic Image\nPrivate Image\n\nStart Command Enter the start command in JSON array format, example:\n[\"python3\",\"-m\",\"vllm.entrypoints.openai.api_server\",\"--model\"]\n\nTraffic Port (required) Default: 8000\n\nEnvironment Variables Click Add Variable to define key-value pairs. Options:\n\nNormal Variable\nPrivate Variable You can add or remove variables as needed.\n\nOnce all required fields are completed, click Next Step.\n\nUsing Environment Variables in EntrypointsTo avoid deployment failures:\nAlways define environment variables in the env_variables section.\nDo not substitute variables directly in the entrypoint or args.\nWhen referencing variables in the entrypoint, escape$as   $$.\nExample:\"entrypoint\": [\n \"sh\", \"-c\", \"echo 'Variable value: $${TEST_VAR}' && sleep 3600\"\n],\n\"env_variables\": {\n \"TEST_VAR\": \"This is a test\"\n}\n\nCorrect: $${TEST_VAR} prints the variable value inside the container.\nIncorrect: $TEST_VAR may cause deployment failure.\nAlways use env_variables for variable management.\nFor advanced users: There is a known issue where Terraform variable interpolation ($) may conflict with service-layer substitution. Escaping with $$ resolves this issue.\n​Step 2: Select Your Cluster Processor + Location\nChoose the hardware and region for your deployment:\n\nAvailable GPUs Search by GPU model and view:\n\nGPU Model\nGPUs per Container\n\nLocation Selection After selecting a GPU, you’ll see a list of locations showing:\n\nRegion (e.g. Canada, Germany)\nAvailable containers per location\n\nOnce both GPU and location are selected, proceed to the next step.\n\n​Step 3: Summary\nOn the Summary page, the choices you made in the process are displayed. You must select the number of Containers and the duration of time that you will use them.\n\nIn the No. of Containers field, select the number of Containers in the dropdown. 2 Containers will increase the cost.\nIn the Enter Duration field, select the length of time: Hourly, Daily, or Weekly. To the right, you can increase the quantity.\nReview all the details of your cluster, including the Total Cost.\nClick Deploy Cluster.\n\n​View Cluster\nAfter payment is processed you can view your cluster loading.\n\nClick Return to Clusters after your cluster is successfully deployed. The screenshot below is a detail page of your cluster.\n\n🚧 Troubleshooting Container Issues\nIf your container is not running, you do not need to delete the whole cluster. Instead, open the deployment settings, adjust any incorrect details (for example, the image name or registry credentials), and redeploy.\nThis way, you avoid the minimum 1-hour charge for deleting and recreating a cluster.\n\nWas this page helpful?","tokens":839,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259434196,"hash":"1be8fd04c6d0d169e8e9fd4cf2fde943cecb4c95"}
{"url":"https://gov.optimism.io/t/builder-grant-proposal-op-security-proxy-local-pre-execution-revert-interception-for-the-superchain/10845/5","domain":"gov.optimism.io","title":"[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n Sep 4\n\n 5 / 5\n\n Sep 8\n\n 27d ago\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions before broadcasting to OP Stack nodes. On EVM rollups, end users and automated agents pay gas fees even when transactions revert on chain due to stale oracle states, localized slippage, or sandwich attacks. For retail users, burning gas on a failed execution creates frustration, and for wallet teams it leads to avoidable support tickets.\nThe proxy sits between standard wallets or clients and public Optimism RPC nodes. When a client issues an eth_sendRawTransaction request, the proxy intercepts the raw payload and simulates it in process using revm against current chain state. If the simulation executes successfully, the transaction is forwarded upstream to the sequencer over an existing hyper connection pool. If the simulation reverts, the proxy aborts the broadcast completely so zero gas is burned on chain, and immediately returns a standard JSON-RPC error containing decoded Solidity custom errors or panic codes along with an estimated gas saved metric.\nThe core implementation is open-source under the MIT license with 40 automated tests passing across the Rust core and TypeScript client SDK. In empirical benchmarks against mainnet.optimism.io, the proxy introduces a minimal 11.8 millisecond processing overhead on fair keep-alive connections with session reuse. For clients that make cold requests without connection reuse, the proxy internal connection pool eliminates repetitive TLS 1.3 handshakes to remote endpoints, amortizing roundtrip latency by roughly 97 milliseconds. The full reproduction methodology and raw telemetry logs are recorded in BENCHMARK_RESULTS.md (https://github.com/Ishant5436/op-sec-proxy/blob/main/BENCHMARK_RESULTS.md).\nUncached transaction simulation over public internet RPC currently averages approximately 2.7 seconds because the execution engine must fetch contract state slots across the network during execution. I am requesting 10,000 OP for an initial builder grant to fund three engineering milestones over the next three months. The initial phase tackles state caching, replacing network RPC state queries with a local in-memory LRU trie cache for warm contract bytecode and storage slots to drive simulation latency down toward a sub-65 millisecond target. Following that, work shifts to developer adoption with a TypeScript provider wrapper and standardized error decoding for wallet integrations. The final phase expands routing across OP Mainnet, Base, Mode, Zora, and Fraxtal alongside reproducible Docker containers and systemd service packaging for node operators.\nAs an individual engineer, I rely on Rust memory safety guarantees, cargo-audit automated dependency scanning, and reproducible GitHub Actions workflows rather than corporate support infrastructure. All code is public and modular. I previously shared an introductory post in the general discussion section of the governance forum under thread 10810 (OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions), and this grant application will allow me to build and package the middleware as a permanent, zero-cost public good for the Superchain ecosystem.\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n 4\n\n post by Anzus_GemWallet on Sep 4\n\n Anzus_GemWallet\n\n From a user-support perspective, how will the proxy handle cases where the local simulation is based on slightly stale state but the transaction might still succeed on-chain? It would be useful to understand whether the default behavior is to fail open, and how the wallet communicates simulation uncertainty versus a definite revert.\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Regarding stale state and transient boundaries, the proxy strictly defaults to fail-open whenever there is execution ambiguity or when a simulation fails due to state retrieval timeouts or RPC sync lags. If the proxy cannot deterministically prove a failure against the current block header, it logs the warning and forwards the raw transaction directly upstream to the sequencer so user submissions are never blocked by middleware latency or momentary node lag.\nFor transaction categorization, the proxy distinguishes between invariant contract panics and state-dependent reverts. Static reverts such as invalid signatures, nonce mismatches, unauthorized access, or insufficient balance are deterministic and will fail regardless of whether the head moved by a block. In those cases, the proxy returns a standard -32000 error with the decoded reason and flags the simulation as definite.\nState-dependent reverts, such as slippage limits on decentralized exchanges or time-sensitive oracle feeds, are where stale state matters most. When revm returns a revert from a condition that depends on volatile storage slots, the proxy includes an uncertainty flag in the JSON-RPC error payload under data.confidence set to uncertain alongside the block number used for simulation. In the TypeScript provider wrapper, wallets can inspect this field to decide how to treat the result. For instance, a wallet can show a clear distinction between a transaction that is guaranteed to revert versus one that failed due to potential slippage drift at the head, or choose to pass uncertain transactions upstream automatically with a warning notice in the user interface.\n\n post by Cypherin on Sep 6\n\n Cypherin\n\n Anzus_GemWallet\n\n A quick update for the review team following up on the discussion above. The simulation confidence classification and fail-open behavior discussed here are now fully implemented and passing in the public repository under commit 8376212.\nWhen revm encounters transient database or RPC connection timeouts, the proxy classifies the execution as uncertain and automatically forwards the raw transaction directly upstream to the sequencer when fail-open is enabled, ensuring zero user drop-offs. If a wallet wishes to inspect or handle the simulation result, the JSON-RPC error payload returns the confidence rating along with decoded contract reverts. The TypeScript client library at @op-sec/client has also been updated with these types, and all unit, integration, and linter checks pass with zero warnings across 32 tests.\n\n post by Cypherin on Sep 8\n\n Cypherin\n\n A quick procedural update for the review team: project metadata and repository ownership verification have now also been completed and published onchain via OP Atlas at https://atlas.optimism.io/project/0x6ab1a8cbf07a602a09c6e754b34361f336ba8e62c1a4792659d7b5ac4a27663b.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n ✨ General\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 106\n\n Sep 4\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Grant Application: superchain-guard\n\n Grants Updates\n\n season-8,season-9\n\n Project Name: superchain-guard — The Security Frontier for Interoperable Intents \nApplicant: ILE Labs (ILE-Labs · GitHub) \nProgram: Season 9 Growth Grants (Infrastructure Category) \n\nExecutive Summary\nOptimism is enterin…\n\n read more\n\n 6\n\n 213\n\n May 19\n\n [MISSION REQUEST] Open-source transaction simulator\n\n Governance Fund Missions\n\n Title: Open-source transaction simulator\nDelegate Mission Request Summary: \nThis mission is intended to provide a key, critical piece of tooling - simulating transactions before they go onchain. Tenderly provides a great…\n\n read more\n\n 3\n\n 522\n\n Aug 2025\n\n Upgrade Proposal #13: OPCM and Incident Response improvements\n\n Protocol Upgrade\n\n Executive Summary\nHi I’m Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej (@0xEscanor) and @Kelvin from the OP Labs Team. \nThis proposal is intended to be voted on in cycle…\n\n read more\n\n 19\n\n 1.4k\n\n Mar 2025","tokens":2197,"squid":"ink-governance","role":"Council Listener","at":1791259434343,"hash":"0259dc9d442ab576bf1ac0b10ba61b7d6728895d"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-30-1","domain":"anchor-lang.com","title":"0.30.1","text":"Anchor Project UpdatesRelease Notes0.30.1Anchor - Release Notes 0.30.1There are a good number of quality of life improvements in this patch release.\nYou can upgrade to this version from 0.30.0 with ease since there are no major\nbreaking changes.\n\nHow to upgrade\n\nUpdate anchor-cli:\navm install 0.30.1\n\nUpdate Anchor crate(s) to 0.30.1.\n\nUpdate TS package(s) to 0.30.1.\n\nRecommended Solana Version\nWhile this release supports anything above 1.17.3, the recommended Solana\nversion is 1.18.17. You can upgrade Solana tools by running:\nsolana-install init 1.18.17\nIDL\nConvert legacy IDLs\nA new feature has been added to the IDL crate in order to convert legacy IDLs\n(pre Anchor v0.30) to new IDLs.\nTo programmatically convert legacy IDLs, add:\nanchor-lang-idl = { version = \"0.1.1\", features = [\"convert\"] }\nand use the\nconvert_idl\nfunction.\nNOTE: This functionality has also been implemented as a CLI command for\nconvenience, see idl convert command.\nUnsupported seed expressions\nSome seed expressions such as &(my_account.data + 1).to_le_bytes():\n#[derive(Accounts)]\npub struct SeedMathExpr<'info> {\n #[account(seeds = [&(my_account.data + 1).to_le_bytes()], bump)]\n pub math_expr_account: UncheckedAccount<'info>,\n pub my_account: Account<'info, MyAccount>,\n}\n\n#[account]\npub struct MyAccount {\n data: u64,\n}\ncannot currently get stored in the IDL, but there was a regression in the IDL\ngeneration that resulted in compile errors when using these or similar\nunsupported expressions.\nThey no longer cause compile errors, but this also means that they also cannot\nget automatically resolved by clients.\nFields with address constraint\nUsing field expressions as an address constraint e.g.\n#[derive(Accounts)]\npub struct Initialize<'info> {\n #[account(address = my_account.authority)]\n pub authority: UncheckedAccount<'info>,\n pub my_account: Account<'info, MyAccount>,\n}\n\n#[account]\npub struct MyAccount {\n authority: u64,\n}\nno longer result in a compile error when generating the IDL.\nHowever, accounts that use the address constraint with non-constant values do\nnot currently resolve automatically. For this reason, you might want to consider\nusing the has_one constraint instead:\n#[derive(Accounts)]\npub struct Initialize<'info> {\n pub authority: UncheckedAccount<'info>,\n #[account(has_one = authority)]\n pub my_account: Account<'info, MyAccount>,\n}\nOverride nightly version on builds\nIDL generation currently uses the nightly compiler to build the IDL, and this\ncan potentially result in compile errors on certain nightly versions.\nIn this release, you can now override the nightly version with\nRUSTUP_TOOLCHAIN env variable.\nRecursive generation\nThere was a compile error during generation with recursive external type\nresolution, which is now fixed. See\nthis if you'd like to see the\nproblem in more detail.\nNew spec crate\nMaking changes to the IDL crate, e.g. adding features such as the\nconvert feature, would\nrequire bumping the version to get the changes even if the spec itself doesn't\nchange.\nTo fix this problem, a new crate that\nonly includes the IDL spec has been introduced. The new crate's version will be\nused in the idl.metadata.spec field to differentiate between various IDLs.\nNOTE: This crate is accessible via the main IDL crate from\nanchor_lang_idl::types.\nCLI\nidl convert command\nThis command allows you to convert legacy IDLs with the new anchor idl convert\ncommand:\nanchor idl convert <PATH_TO_IDL_JSON>\nidl type command\nThis command creates TypeScript IDL type (with camelCase fields) from an\nexisting IDL file:\nanchor idl type <PATH_TO_IDL_JSON>\nidl build toolchain override\nSee the explanation in the IDL section.\nExample usage with the CLI:\nRUSTUP_TOOLCHAIN=\"nightly-2024-05-09\" anchor idl build\nAutomatic program id updates\nWhen building a program for the first time ever, the program id declarations\nwill get automatically updated if there is not a [programs.localnet] entry in\nAnchor.toml.\nNote that this is essentially the same as running anchor keys sync, only\ndifference being that this will only run once automatically.\nUpgradeable program clones\nCloning upgradeable programs with\n[test.validator]\nurl = \"https://api.mainnet-beta.solana.com\"\n\n[[test.validator.clone]]\naddress = \"TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb\"\nwould result in unusable programs due to a breaking change in Solana 1.17.12.\nThis problem has been fixed from both Anchor and Solana's side. However, it\nrequires using solana-cli >=1.18.10.\nFile system error improvements\nDefault Rust error when a file is not found in the file system does not log the\nfile path, which makes it difficult to debug.\nIn this release, file system related errors also include the path of the file.\nLang\nUsing legacy IDLs with declare_program!\ndeclare_program!\nmacro can now be used with legacy IDLs (pre Anchor v0.30).\nThis works great as long as the program can be described correctly with the\nlegacy IDL spec. However, if a program uses non-default features such as zero\ncopy, or repr modifications, the declaration of the program either won't\ncompile, or will be invalid. There are two main solutions in this scenario:\n\nUse the idl convert command, and manually fix the invalid parts\nGenerate the program's IDL by upgrading the program to Anchor v0.30\n\nThe latter option is preferred as it's less error-prone. If you have dependency\nissues while upgrading, simply remove them when generating the IDL since the IDL\ngeneration only cares about the signatures, and all program logic, including all\ndependencies (except Anchor), can be removed when generating the IDL.\nHere\nis an example program that you can generate an IDL from.\nIn short, IDLs should be preferably generated with v0.30 rather than the\nconversion method, as a new IDL spec wouldn't be necessary if the old one was\nsufficient to reliably describe programs.\ndeclare_program! fixes\nThere were a number of cases where the new declare_program! would cause a\ncompile error.\nUsing the following would result in a compile error:\n\nDefined types (e.g. structs) in instruction parameters\nTypes with const generics\nVec<u8> type\nInstruction with a non-unit return type\nOptional accounts (in clients)\nbytemuckunsafe account serialization\n\nAnother issue was tuple struct fields were private (Rust default), they are now\npublic.\npubkey! macro\nsolana-program\nhas\npubkey!\nto easily declare public keys:\nlet key = pubkey!(\"11111111111111111111111111111111\");\nwhich is more convenient than Pubkey::from_str:\nuse std::str::FromStr;\nlet key = Pubkey::from_str(\"11111111111111111111111111111111\").unwrap();\nHowever, because of how the macro is implemented, it wasn't possible to use it\nfrom Anchor without also including solana-program to your dependency list as\nthe macro was specifically using ::solana_program.\nYou can now directly use pubkey! as it's exported from anchor_lang::prelude.\nNote that because solana_program is exported from anchor_lang, you can also\nremove solana-program dependency from your Cargo.toml if pubkey! was the\nreason for adding it.\nID_CONST constant\nProgram ids declared from\ndeclare_id!\nand\ndeclare_program!\nhave ID declared as static which doesn't allow compile time checks.\nBoth of these macros now have a new constant (ID_CONST), which is essentially\nthe same as ID, but is declared as const instead of static.\nStack usage of token extensions\nStack usage of the new\ntoken extensions constraints\nhas been improved.\nError propagation from integer conversion errors\nYou can now propagate integer conversion errors with ?:\nlet n: i32 = u32::MAX.try_into()?;\nSPL\nExport ATA crate\n[spl-associated-token-account](https://crates.io/crates/spl-associated-token-account) crate is now re-exported from anchor_spl::associated_token`.\nSimilar to how you can\nremove\nthe mpl-token-metadata crate from your dependency list, you can also remove\nspl-associated-token-accounts crate.\n[dependencies]\nanchor-spl = \"0.30.1\"\n- spl-associated-token-account = \"3.0.2\"\nTypeScript\nATA resolution\nThe\naccount resolution\nsupport has been extended to support associated token accounts in this release.\nIf you use ATAs in your instruction, you'll get a type error if you call the\naccounts method with those account specified. To solve, simply remove all ATAs\nfrom your accounts call.\nDefined types in generics\nUsing defined types (structs, enums, or type aliases) as a generic argument e.g.\nparam: GenericStruct<MyStruct>,\nno longer results in an error.\nVersioned transactions\nA problem where maxSupportedTransactionVersion was needed, but not being set\nfrom AnchorProvider has been fixed.\nNew errors package\nAnchor errors have been separated into a new package\n@anchor-lang/errors.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.30.2Next0.30.0On this pageHow to upgradeRecommended Solana VersionIDLConvert legacy IDLsUnsupported seed expressionsFields with address constraintOverride nightly version on buildsRecursive generationNew spec crateCLIidl convert commandidl type commandidl build toolchain overrideAutomatic program id updatesUpgradeable program clonesFile system error improvementsLangUsing legacy IDLs with declare_program!declare_program! fixespubkey! macroID_CONST constantStack usage of token extensionsError propagation from integer conversion errorsSPLExport ATA crateTypeScriptATA resolutionDefined types in genericsVersioned transactionsNew errors packageEdit on GitHub","tokens":2336,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259444170,"hash":"283afff4caecdfefc972789e77d4b40435f5b603"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts","domain":"aave.com","title":"Smart Contracts | Aave Protocol Documentation","text":"Smart Contracts#\n\nThe source code of the Aave v3 Protocol contracts is available on GitHub. Contract addresses can be imported as Solidity or JavaScript package with the Aave\nAddress Book.\nThe core contracts fall into the following categories in the GitHub repository:\nPoolConfigurationLogicTokenizationHelpersMisc\nPool#\nPool#\nThe Pool is the main entry point into the Aave Protocol. Most user interactions with the Aave Protocol occur via the Pool contract. Pool is owned by the PoolAddressesProvider of the specific market. All admin functions are callable by the PoolConfigurator contract, which is defined in PoolAddressesProvider.\nL2Pool#\nThe L2Pool is a modification of the Pool contract for L2 rollups, with gas-optimized user methods that takes byte encoded input arguments. It is a calldata optimized extension of the Pool contract allowing users to pass compact calldata representations to reduce transaction costs on rollups.\nPoolConfigurator#\nThe PoolConfigurator provides configuration methods for the Pool contract. The write methods of this contract can only be called by addresses with corresponding permissioned system roles that are managed by ACLManager.\nConfiguration#\nACLManager#\nThe ACLManager contract is the main registry of system roles and permissions.\nPoolAddressesProvider#\nThe PoolAddressesProvider is a registry of various components of the protocol, including the ACLManager and Pool contracts, and has the ability to update pointers or update the implementation of proxy contracts.\nLogic#\nLibraries that implement the base logic for various actions and functions.\nTokenization#\nAToken#\nATokens are yield-generating tokens that are minted and burnt upon supply and withdraw of assets to Aave Pool.\nVariableDebtToken#\nVariableDebtTokens are non-transferable interest accruing tokens representing variable borrow rate positions.\nHelpers#\nL2Encoder#\nThe L2Encoder is a helper contract to encode calldata that is passed to the L2Pool. It is used to optimize calldata size in L2Pool for transaction cost reduction. It is only intended to help generate calldata for users/frontends.\nAaveProtocolDataProvider#\nThe AaveProtocolDataProvider is a peripheral contract to collect and pre-process information from the Pool.\nMisc#\nAaveOracle#\nThe AaveOracle is the registry of reserve oracle to get asset prices and manage price sources.\nDefaultReserveInterestRateStrategy#\nThe DefaultReserveInterestRateStrategy implements the calculation of the interest rates depending on the reserve state. This contract holds the information needed to calculate and update the yield relating to specific liquidity pools.\nPriceOracleSentinel#\nThe PriceOracleSentinel validates if operations are allowed depending on the PriceOracle health. Once the PriceOracle gets up after an outage or downtime, users can make their positions healthy during a grace period.PreviousIntegrationsNextPool","tokens":723,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259447194,"hash":"ff3aa846e0c5f8dfe633313de525084fb2092e34"}
{"url":"https://ethresear.ch/t/mempool-account-transaction-capacity-from-historical-activity-matcha/25949","domain":"ethresear.ch","title":"Mempool Account Transaction Capacity from Historical Activity (MATCHA) - Execution Layer Research - Ethereum Research","text":"Mempool Account Transaction Capacity from Historical Activity (MATCHA) \n\n Execution Layer Research\n\n account-abstraction,transaction-privacy\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n read \n\n 7\n min\n\n Sep 8\n\n 1 / 12\n\n Sep 7\n\n 19h ago\n\n post by soispoke on Sep 8\n\n soispoke\n\n exec-88a503c6-2691-4c16-98f1-527ff590481d1254×1254 232 KB\ns/o Toni for the artwork\nby Thomas, based on ideas and discussions with Vitalik and Toni\nIntroduction\nFrame Transactions (EIP-8141) allow applications to define their own validation and gas payment logic. To keep this programmable validation safe in the public mempool, EIP-8141 limits the validation work for each transaction through MAX_VERIFY_GAS and normally admits at most one pending Frame Transaction per sender. Clients also track validation dependencies so they only revalidate transactions whose dependencies may have changed after a new canonical block.\nKeyed Nonces for Frame Transactions (EIP-8250) gives transactions independent nonce keys. This matters for privacy applications, where many users share one sender so their transactions do not expose separate public accounts or fragment the anonymity set. By removing nonce conflicts between unrelated spends, EIP-8250 makes it possible for a future mempool policy to admit several transactions from the same sender.\nRelaxing the one transaction limit creates a new DoS vector. An attacker could deploy a fake privacy application and submit many valid spends with different nonce keys, all of which read the same validation setting. A single onchain change to that setting could invalidate the entire pending set and force clients to revalidate and remove every spend. By restoring the setting and resubmitting the spends, the attacker could repeat the attack at little onchain cost relative to the mempool work it creates.\nAdmitting several transactions also creates a second problem. A malicious user could target an honest privacy application by submitting many valid transactions with low fees. These transactions consume the shared sender’s capacity and prevent other users from entering the mempool. They may remain pending or leave without inclusion, in which case no fee is paid, so fee bids alone cannot provide a hard bound.\nIn this post, we introduce MATCHA, a local mempool policy for admitting several transactions from one sender while bounding the resulting DoS risk. Each admission beyond the first spends capacity called width, assigned to that sender. A sender earns new width only from the actual gas used by its Frame Transactions in finalized blocks, and spent width is not returned when a transaction leaves the mempool. This bounds repeated mass invalidation.\nWe also present how the proposed FOCIL extension for Frame Transactions (EIP-8369) would make valid transaction flooding riskier by increasing the chance that the attacker’s transactions are included and the attacker pays for their gas. Clients could strengthen this deterrent with an optional minimum remaining validity period or linearly increasing priority fees.\nGoals\nThe goal of MATCHA is to let clients admit several Frame Transactions with independent EIP-8250 nonce keys from one shared sender, without whitelisting any application, paymaster, verifier, or proof system.\nMATCHA must protect the public mempool even if the application is malicious.\nProtect the mempool\n\nBound total mempool resource use. The client caps pending transaction data, dependency indexes, signature and proof verification, state reads, revalidation, and cleanup. It may also apply lower limits to each peer, but adding peers or sender addresses does not increase the client’s total limits.\n\nPrevent nonce conflicts and double counting the payer balance. No two distinct pending transactions may use the same (sender, nonce_key). The total maximum cost reserved by pending transactions using one payer may not exceed that payer’s balance at the current head.\n\nBound repeated mass invalidation. Admitting an additional transaction, replacing it with different bytes, or rerunning its validation prefix spends width. Inclusion, invalidation, removal, expiry, or reorg does not return that width. Once it runs out, further additional admissions require new finalized activity from the sender.\n\nDeter valid transactions that consume shared capacity. FOCIL for Frame Transactions increases the chance that a transaction which remains eligible is included and its payer is charged. Clients may strengthen this deterrent by rejecting transactions close to a predictable expiry or requiring linearly higher fees as more transactions remain pending. Importantly, these policies do not guarantee inclusion or payment, so width and the client’s total limits remain the hard DoS bound.\n\nNote: MATCHA protects mempool resources, not application funds or fairness between users. Its FOCIL deterrence assumes that an honest application makes each user authorize and pay for the gas of their own transaction. Application solvency, settlement safety, and proof design are separate concerns.\n\nHow it works\nUnder EIP-8141 mempool rules, a client normally keeps at most one pending Frame Transaction per sender. MATCHA keeps this transaction as the baseline and may admit additional transactions when they use EIP-8250 nonce keys and satisfy the MATCHA admission profile. The EIP-8141 baseline spends no width, but every additional transaction does. If the baseline leaves while other transactions remain pending, none of them becomes the baseline; it becomes available again only when the sender’s pending set is empty. Frame Transactions that do not satisfy MATCHA continue to follow the “one transaction per sender” policy.\nThe client uses width only after the validation prefix succeeds and the transaction can be attributed to its sender and payer. All work and storage remain subject to limits shared by the whole client, including transaction data, signature and proof verification, state access, stored records, revalidation, and cleanup. When a limit is reached, the client rejects or defers further work.\nRejection under MATCHA does not make a transaction invalid for inclusion in a block or excuse its omission under FOCIL.\n\nMATCHA does not increase EIP-8141’s validation budget. An application with a larger proof must fit the active budget or use a separately defined public mempool profile.\n\nwidth\nwidth is the capacity available to a sender for pending Frame Transactions beyond the EIP-8141 baseline. A sender starts with no width and earns it from the actual gas used by its Frame Transactions in newly finalized blocks, up to a local cap. Each finalized block is credited only once:\nwidth[sender] = min(\n width_cap,\n width[sender] + newly_finalized_gas[sender]\n)\n\nEach transaction has a charge based on the work budgeted to admit it. admission_gas(tx) covers transaction data, signatures, EIP-8250 nonce checks, the checks in Recent Roots for Frame Transactions (EIP-8272), and EIP-8141 execution through payment approval. For frame execution, it uses the declared execution gas limits, so the stored charge also covers a later revalidation that takes more work than the initial simulation. It excludes later application execution. State gas is bounded separately and is excluded because it does not measure validation work. A safety_factor covers client work that EVM gas does not measure accurately:\ncharge(tx) = ceil(safety_factor * admission_gas(tx))\n\nThe baseline spends no width. Before spending width, an additional transaction must pass the ordinary admission checks and be valid for a child of the current head, including max_fee_per_gas >= next_base_fee. Its sender must then have enough width, and the client deducts the transaction’s charge:\nrequire width[sender] >= charge(tx)\nwidth[sender] = width[sender] - charge(tx)\n\nThe remaining rules are:\n\nDuplicates, replacements, and revalidation. Exact duplicates of a transaction already pending share one pool record and spend no width. Replacing the baseline also spends no width. Replacing an additional transaction with different bytes spends another charge. Rerunning its validation prefix spends its stored charge before the work begins. If the sender cannot cover that charge, the client removes the transaction without rerunning the prefix.\n\nNo refunds and local lifetime. Spent width is not returned when a transaction is included, invalidated, or removed. Every pending transaction is removed after a maximum local lifetime, without affecting its onchain validity. A removed transaction must pass admission again, including after a reorg, and spends another charge if it is additional. Rebuilding spends more width; once it runs out, further additional admissions require new finalized activity from the sender.\n\nNonce keys and payer balance. No two distinct pending transactions may use the same (sender, nonce_key). The client reserves each transaction’s maximum cost against the payer’s balance at the current head. After a new head, affected transactions remain unavailable for block construction until their combined reservations fit the new balance. These checks exist only in the client’s mempool.\n\nA change to the payer balance does not by itself require rerunning validation. The client can reuse its earlier result if it confirms that validation would run with the same code and inputs. It must still check nonce keys, recent roots, expiry, fees and the payer’s total reservations at the new head. All these checks remain subject to the client’s resource limits.\nProtection against width draining\nIrreversible width bounds repeated mempool work, but an attacker can still consume an honest application’s available capacity by submitting valid transactions with very low fees to block concurrent admissions. If the pending set becomes empty, the EIP-8141 baseline becomes available again, but further additional admissions must wait for new finalized activity if the sender has exhausted its width.\nMATCHA relies on a consensus extension implementing the FOCIL reference model in EIP-8369 to make this attack risky. If an honest includer selects a transaction eligible under that extension and the inclusion list reaches enough attesters, the builder must include it unless the omission checks establish that it is invalid or does not fit. EIP-8369 evaluates these checks at a position claimed by the builder. In an honest privacy application, inclusion charges the transaction’s user for its gas, and finalization earns fresh width for the shared sender. An additional transaction spends width again whenever it is replaced or its validation is rerun. Only the version that is included earns new width after finalization, so it may replenish less capacity than was spent along the way.\nThis deterrent is conditional: under Fork-choice enforced Inclusion Lists (FOCIL) (EIP-7805), transaction selection remains with the includer, inclusion lists have finite capacity, and a transaction can become invalid or fee invalid before inclusion. The hard DoS bound therefore remains spent width and the client’s total resource limits, but we think in practice relying on FOCIL might be enough to deter these width draining attacks.\nThere are also ideas clients could use to strengthen this deterrent with one or both of the following optional policies:\n\nMinimum period before expiry. A client may require an additional transaction’s EIP-8141 expiry and every EIP-8272 recent root to remain valid through a target slot chosen by local policy. The longer this period is, the more opportunities FOCIL has to include the transaction, increasing the chance that the attacker has to pay for it.\n\nLinear fees using load. A client may also track load, the sum of the charge values of the additional transactions that remain pending. Each new additional transaction must offer a minimum effective priority fee that rises linearly with this load. The client chooses base_price, the starting fee floor. When all charges are equal, the floor is base_price for the first additional transaction, twice base_price for the next, then three times, and so on. When a transaction leaves the mempool, its charge is removed from load even though its spent width is not returned.\nThis makes a transaction later in a large batch carry a higher fee offer, so including it can expose the attacker to a cost that grows with the batch. The rule also raises fees for honest users when their shared sender is busy and does not reserve capacity for individual users, so it remains optional and does not replace width as the hard DoS bound.\n\nNext steps\nThe next step is to implement the core width policy in clients alongside FOCIL for Frame Transactions and test the two attacks MATCHA targets: repeated mass invalidation by a malicious application and width draining against an honest one, including repeated replacements before inclusion. These tests should calibrate the admission charge and capacity limits, measure how quickly eligible transactions are included during congestion, and determine whether FOCIL is sufficient on its own or whether a minimum validity period or linear fees using load justify their added complexity.\nThe tests should also measure honest throughput: including one transaction changes the shared payer balance and may trigger revalidation of the others before finalization replenishes width. We need to check whether ordinary activity can sustain useful concurrency, and when cheap dependency checks can avoid a full replay.\n\n 4\n\n 4\n\n read \n\n 7\n min\n\n post by AnkushinDaniil on Sep 8\n\n AnkushinDaniil\n\n really like that width is earned from finalized gas and burned irreversibly, it sidesteps the stake and reputation traps at once.\nthe thing i keep circling on is that the charge is flat across every additional tx, while the work it actually prices, the cheap repeated invalidation loop, only shows up when the validation prefix reads shared live-contended state. if a prefix only touches single-writer state, its own nullifier, or a value bound to a recent root (8272, which you already fold into admission_gas), one onchain write can’t take down the pending set: a recent-root read is stale-acceptable by construction, and a nullifier is self-scoped, so falsifying it only drops that one spend, not its neighbours. those txs structurally can’t be in the mass-invalidation set, yet they still pay full width.\nwe wrote up the dimension behind this here (Order-dependence as the classifying dimension for frame-transaction mempool admission): the ruler for admission is order-dependence / contention, not the volume of state a check reads, and the recent-root tier is exactly the stale-acceptable middle class. it lines up with your VOPS-eligibility split, class 0 there is the same single-writer case.\nso the question is whether width could be indexed by that: full charge when the prefix reads shared live-contended state, waived or reduced when it’s provably single-writer or recent-root-bound. that would also take the edge off cold-start for an honest pool that binds spends to a recent root, which is the natural design anyway.\nthe obvious counter is admission cost: can a client decide cheaply that a prefix reads no shared contended state without running it? if not, flat charging is the pragmatic call. and exempting those txs leans their capacity protection on FOCIL plus the fee ramp instead of width, which may be fine but is a real shift. curious if you already looked at contention-indexed width and ruled it out on the classification cost.\n\n post by TimTinkers on Sep 8\n\n TimTinkers\n\n I really like this! This is a much, much better solution for public mempool DoS concerns than ever enshrining special contracts as exceptions; very opposed to ever enshrining any special behavior. Contracts slowly earning leniency from the mempool via frames that succeed is a nice, neutral mechanism.\nCould a similar idea be applied to the verify gas limits?\n\n post by soispoke on Sep 9\n\n soispoke\n\n AnkushinDaniil\n\n thanks for your comments!\nI think lower risk of repeated invalidation could justify a lower charge, even if the initial verification costs the same, so that could help with cold start\nbut the main q is which transactions would actually qualify because “single-writer” is not enough: an app can change its own validation setting and invalidate txns, and even if you have independent nullifiers and recent roots, you still have the shared payer balance. So a draining attack (draining ETH in this case not width) can just make the pending txns unaffordable even if their proofs are valid\n\n post by soispoke on Sep 9\n\n soispoke\n\n @TimTinkers glad you like the idea, and I think it could!\nEarned width could allow more expensive verification not just more pending txns, with larger budgets spending more width. Ofc you’d still need to keep the hard upper bound per check\none thing to think about is that some privacy applications need the proof to check authorization so an attacker could name an active pool as the sender and submit an invalid proof that takes a lot of work to reject\nif we deduct width before checking authorisation it would let anyone drain the pool’s width, and it we deduct it afterwards it means invalid proofs consume work without spending any width\nso it definitely seems worth considering as long as clients still have limits on their total verification work and queued requests, and we woudl need to test how much invalid proofs delay other honest transactions\n\n post by AnkushinDaniil on Sep 14\n\n AnkushinDaniil\n\n soispoke\n\n the balance drain is a different axis from proof invalidation, and reserving the payer balance at admission closes it: a later drain can’t unfund a pending set whose funds are already held. so the qualifying set could be proof-side clean plus reserved balance, not just proof-side clean.\nwrote up why that balance can’t be dropped, only reserved: Public-mempool gas sponsorship needs escrow, a bond, or trust\nwould you draw the line there?\n\n post by soispoke on Sep 15\n\n soispoke\n\n The exact same MATCHA approach could apply to the paymaster as well imo: it earns width from gas it paid for in finalized transactions, and additional admissions and revalidations across all its sponsored senders spend that width.\nIf it drains its balance and invalidates the pending set, the spent width is not returned. So we don’t necessarily need to prevent the drain itself or lock the funds we just need to bound the repeated mempool work it can cause.\n\n post by AnkushinDaniil on Sep 15\n\n AnkushinDaniil\n\n yeah you’re right, i had that wrong. checked the spec, the 8141 reservation is just each node’s own tally, nothing’s locked onchain. a sponsored tx that lands still spends the real balance through gas, so it caps a node’s exposure but doesn’t keep an admitted tx funded.\nso width’s the right default, it bounds the repeated work. keeping an admitted tx funded through a drain needs a real onchain lock, that’s heavier and agreed it shouldn’t be forced on every paymaster. opt-in for the ones that want it.\n\n post by egpivo on Sep 22\n\n egpivo\n\n Just curious. Could finalization-gated width become a bottleneck for bursty L2 posting? For example, if a rollup submitter uses multiple nonce keys, could its available mempool concurrency be exhausted while earlier L1 transactions are already included but not yet finalized?\n\n 10 days later\n\n post by jstinhw 4 days ago\n\n jstinhw\n\n soispoke\n\n Consider a privacy pool used as a paymaster: users transact from arbitrary sender addresses and prove they can spend a note in the pool to pay gas. The pool is the shared payer.\nFor the proposed paymaster extension to MATCHA, could a malicious user drain the pool’s width by submitting multiple spends of the same note from different senders, reducing throughput for other users?\nFor example, assuming the baseline/width model applies per payer:\n\nThe pool has enough width for 100 additional admissions and enough ETH to cover the maximum-cost reservations.\nAn attacker submits one baseline transaction plus 100 additional transactions from different senders. Each has a valid proof spending the same note, with the same nullifier.\nAll independently pass validation against the current head because the note is unspent. The (sender, nonce_key) restriction does not catch the conflict across different senders. The additional admissions consume the pool’s available width.\nOne transaction gets included and consumes the note, invalidating the others. Their spent width is not returned.\n\nWould this force other users back to the one-pending-transaction baseline, once the pending set empties, until newly finalized activity replenishes capacity?\nWould this scenario be addressed by MATCHA’s proposed paymaster extension, or would it require a separate mechanism to detect repeated (payer, nullifier) pairs across different senders\n\n post by AnkushinDaniil 23 hours ago\n\n AnkushinDaniil\n\n which write marks the note spent when the pool is only the payer? 8250 consumes keys under (tx.sender, key), so the same nullifier from 100 senders is 100 different keys, and a pay frame can’t read the pool’s own storage under the 8141 mempool rules. so i think all 100 stay valid and can land, which is a pool funds problem before a width one. would it make sense for payment approve to consume keys under the payer, so the copies collide on (payer, key) from tx fields before any width is spent?\n\n post by mmjahanara 19 hours ago\n\n mmjahanara\n\nIf a privacy pool wants to support transactions for which it is not the sender, it has to forgo using EIP-8250 as its only nullifier management mechanism, which in turn makes it practically incompatible with frame transactions as it would require tracking nullifiers in state and accessing paymaster’s state during validation which is not allowed in the public mempool for non-canonical paymasters.\n\n Powered by Discourse","tokens":5466,"squid":"ink-research","role":"Deep Scholar","at":1791259448928,"hash":"7046b5a13055929287087325ca5292b93ba2377f"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-30-0","domain":"anchor-lang.com","title":"0.30.0","text":"Anchor Project UpdatesRelease Notes0.30.0Anchor - Release Notes 0.30.0The long-awaited v0.30.0 release is finally here!\nWe'll go over the main changes, but if you'd like to see all notable changes,\ncheck out the\nCHANGELOG.\n\nHow to upgrade\n\nUpdate avm:\ncargo install --git https://github.com/otter-sec/anchor --tag v0.30.0 avm --locked\n\nUpdate anchor-cli:\navm install latest\n\nUpdate Anchor crate(s) to 0.30.0. Optionally, run cargo update to update\nother dependencies to the latest compatible versions.\n\nUpdate TS package(s) to 0.30.0.\n\nRecommended Solana Version\nWhile this release supports anything above 1.16, the recommended Solana\nversion is 1.18.8. You can upgrade Solana tools by running:\nsolana-install init 1.18.8\nIDL\nThe IDL type specification and generation has been rewritten. To keep the\nrelease notes short, we won't go over the changes here, but see\nthis if you'd like to learn\nmore.\nidl-build feature\nidl-build feature is now required in your program's Cargo.toml definition in\norder for the IDL generation to work.\nWithout this feature, anchor build outputs:\nError: `idl-build` feature is missing. To solve, add\n\n[features]\nidl-build = [\"anchor-lang/idl-build\"]\n\nin `<PATH_TO_CARGO_TOML>`.\nNote that all crates that you use to generate type definitions for the IDL need\nto be specified in the list of idl-build, e.g. anchor-spl/idl-build,\nsome-program/idl-build...\nLang\nDependency free program declaration\nDepending on other crates who used different versions of Anchor is not the best\nexperience, to say the least. To solve this problem, program clients can now be\ngenerated from their IDL using the new declare_program! macro:\ndeclare_program!(program_name);\nprogram_name is based on the file name of the IDL in idls directory, e.g.\nidls/program_name.json is required to exist in order for the above example to\nwork.\nThis works for both on-chain (CPI) and off-chain (RPC) usage, allowing program\ninteractions without creating a\ndependency hell. Check out\nthis\nexample for on-chain CPI usage.\nFor more information, see the macro's\ndocumentation.\nToken extensions\nConstraints\nThere are new account constraints for\nToken Extensions (Token 2022):\n\ngroup_pointer:\n\nauthority\ngroup_address\n\ngroup_member_pointer:\n\nauthority\nmember_address\n\nmetadata_pointer:\n\nauthority\nmetadata_address\n\nclose_authority\n\nauthority\n\npermanent_delegate:\n\ndelegate\n\ntransfer_hook:\n\nauthority\nprogram_id\n\nNote: Above values are concatenated with :: (similar to other Anchor\nconstraints) and have extensions prefix e.g.\nextensions::group_pointer::authority = <EXPR>.\nThese constraints can be used both with or without the init constraint.\nHere\nis an example program that uses these constraints.\nCPI wrappers\nanchor-spl now includes CPI wrappers for Token Extensions which can be\naccessed from anchor_spl::token_2022_extensions.\n#[interface] attribute\nTransfer hooks can now be used with the new #[interface] macro. This argument\noverrides the Anchor's default instruction discriminator to use the interface\ninstruction's discriminator.\nCurrent supported values are:\n\nspl_transfer_hook_interface::initialize_extra_account_meta_list\nspl_transfer_hook_interface::execute\n\nmod my_hook_program {\n #[interface(spl_transfer_hook_interface::initialize_extra_account_meta_list)]\n pub fn initialize(ctx: Context<Initialize>, metas: Vec<AnchorExtraAccountMeta>) -> Result<()> {\n /* ... */\n }\n\n #[interface(spl_transfer_hook_interface::execute)]\n pub fn execute(ctx: Context<Execute>, amount: u64) -> Result<()> {\n /* ... */\n }\n}\nOptional bumps\nWhen an optional account is not specified, instead of defaulting it to\nu8::MAX, this release changes the optional bump type to be Option<u8> and\nsets the bump field to None.\nLess heap allocations\nBorshSerialize::try_to_vec\nimplementation, which is used in events, CPI, and return data, heap allocates\n1024\nbytes each time it's used, even if your data is much smaller. In this release,\nthe default allocation is set to 256 bytes.\nThere is also a new method InstructionData::write_to() to write to an existing\nallocation rather than creating a new allocation with InstructionData::data().\nCLI\nPriority fees in CLI\nIDL commands take in --priority-fee argument As it's getting harder and harder\nto land transactions in mainnet-beta without using priority fees, this release\nsupports setting --priority-fee argument for the IDL commands. For example:\nanchor idl erase-authority --program-id <PROGRAM_ID> --priority-fee 9000\nWhen the --priority-fee argument is not specified, the median fee of the last\n150 confirmed slots is used.\n--no-idl flag on builds\nIDL generation requires building of the program, but this is unnecessary if your\nprogram API doesn't change. In that case, you can use --no-idl flag to build\nyour program but skip the IDL generation:\nanchor build --no-idl\nIDL buffer is closed after idl upgrade\nAfter an IDL upgrade, the buffer account is now closed and the lamports are\nreturned back to the IDL authority.\nPass deploy arguments to solana-cli\nYou can now pass arguments to solana program deploy from anchor deploy:\nanchor deploy -- --final\nVerifiable deployments\nSimilar to verifiable builds, you can now deploy the verified build instead of\nthe default build:\nanchor deploy --verifiable\nAccept package name as program name\n--program-name (-p) argument of various commands also works with package\nname of the program rather than lib name which is snake_case. For example:\nanchor build -p my-program\nDeactivate test-validator features\nYou can now deactivate test-validator features from Anchor.toml:\n[test.validator]\ndeactivate_feature = [\"GDH5TVdbTPUpRnXaRyQqiKUa7uZAbZ28Q2N9bhbKoMLm\", \"zkiTNuzBKxrCLMKehzuQeKZyLtX2yvFcEKMML8nExU8\"]\nCrate and package compatibility\nUsing non-matching versions of anchor-cli, anchor-lang, and\n@anchor-lang/core can result in unexpected behavior. In this release, you'll\nget a warning if any of them don't match.\nExplicit overflow-checks flag\noverflow-checks\nflag is implicitly disabled by default. Anchor workspaces that are created with\nanchor init have this flag enabled, however, Anchor doesn't do any checks for\nit after the initial workspace creation.\nWith this release, overflow-checks in the workspace Cargo.toml need to be\nspecified. Note that \"specified\" does not mean enabled, as you can also disable\nit, but you need to be explicit in doing so.\nWildcard pattern in Anchor.toml\nworkspace.members and workspace.exclude now supports simple wildcard\npattern:\n[workspace]\nmembers = [\"programs/*\"]\nNote that the support is limited to this simple wildcard pattern, and more\ncomplex globs are not currently supported.\ncargo build-sbf is now the default\nBefore this release, anchor build used cargo build-bpf to build programs,\nhowever, because it is deprecated, anchor build now defaults to\ncargo build-sbf.\nTo preserve the old behavior, you can use:\nanchor build --arch bpf\nRun multiple commands in scripts\nScripts in Anchor.toml now supports running multiple commands:\n[scripts]\ntest-all = \"cargo test && yarn run ts-mocha tests/**/*.ts\"\nThis script would run both cargo and yarn commands:\nanchor run test-all\nTest only a specified program\nA single program can be tested in a multi program workspace with the\n--program-name (-p) argument:\nanchor test --program-name example\nThis builds and tests only the specified program.\nRust test template\nA wild TypeScript test won't appear if you initialize your workspace with the\nnew Rust test template:\nanchor init --test-template rust\nTypeScript\nAccount resolution\nAccount resolution refers to the ability of clients to resolve accounts without\nhaving to manually specify them when sending transactions.\nThere are too many changes to the account resolution logic in the TS library,\nhowever, we can skip a good chunk of them since they're mostly internal.\nOne change that affects everyone is the change in the accounts method. Even\nthough the TS library had some support for account resolution, it had no\ntype-level support for it — all accounts were essentially typed as partial, and\nthere was no way to know which accounts were resolvable and which were not.\nThere are now 3 methods to specify accounts with the transaction builder:\n\naccounts: This method is now fully type-safe based on the resolution fields\nin the IDL, making it much easier to only specify the accounts that are\nactually needed.\naccountsPartial: This method keeps the old behavior and let's you specify\nall accounts including the resolvable ones.\naccountsStrict: If you don't want to use account resolution and specify all\naccounts manually (unchanged).\n\nThis change is likely to result in errors in your existing .accounts() calls.\nTo fix, either change accounts to accountsPartial, or remove all accounts\nthat can be resolved from the IDL. For example:\n- await program.methods\n- .init()\n- .accounts({\n- pda: ...,\n- signer: ...,\n- systemProgram: ...,\n- })\n- .rpc();\n+ await program.methods.init().rpc();\nMagic account names\nAnother change that affects most projects is the removal of \"magic\" account\nnames. The TS library used to autofill common program and sysvar accounts based\non their name, e.g. systemProgram, however, this is no longer necessary with\nthe introduction of the address field (in the IDL) which is used to resolve\nall program and sysvars by default.\nCase conversion\nThe internals of the TS library are filled with case conversion logic before\nmaking string comparison and this also forces other libraries who build on top\nof Anchor to do the same.\nAlong with making the IDL have consistent casing, TS library also has consistent\ncasing (camelCase) in this release.\nNo more Program ID\nprogramId parameter of Program is removed since the new IDL requires to\nstore the program id in its address field:\n- new Program(idl, programId);\n+ new Program(idl);\nOptional provider options\nopts parameter of AnchorProvider is now optional:\n- new AnchorProvider(connection, wallet, {});\n+ new AnchorProvider(connection, wallet);\nType changes\nThere are too many type changes to list here, especially the types that are\nrelated to the IDL. The new IDL types can be found\nhere.\n\nSee the full list of notable changes in the\nCHANGELOG.Previous0.30.1Next0.29.0On this pageHow to upgradeRecommended Solana VersionIDLidl-build featureLangDependency free program declarationToken extensions#[interface] attributeOptional bumpsLess heap allocationsCLIPriority fees in CLI--no-idl flag on buildsIDL buffer is closed after idl upgradePass deploy arguments to solana-cliVerifiable deploymentsAccept package name as program nameDeactivate test-validator featuresCrate and package compatibilityExplicit overflow-checks flagWildcard pattern in Anchor.tomlcargo build-sbf is now the defaultRun multiple commands in scriptsTest only a specified programRust test templateTypeScriptAccount resolutionMagic account namesCase conversionNo more Program IDOptional provider optionsType changesEdit on GitHub","tokens":2720,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259454857,"hash":"31c873cb9c872a43ef0f706bc3383499eaf75f17"}
{"url":"https://aave.com/docs/aave-v3/markets/advanced","domain":"aave.com","title":"Advanced Features | Aave Protocol Documentation","text":"Advanced Features#\nImplement advanced Aave features for sophisticated DeFi applications.\nUser Transaction History#\nTrack user transaction history across Aave markets with detailed transaction information.\nReactTypeScriptGraphQLUse the useUserTransactionHistory hook to fetch paginated transaction history for a user.const { data, loading, error } = useUserTransactionHistory({ market: EvmAddress, user: EvmAddress, chainId: ChainId, filter?: UserTransactionType[], orderBy?: UserTransactionHistoryRequestOrderBy, pageSize?: PageSize, cursor?: Cursor,});Fetch user transaction history ordered by date.import { useUserTransactionHistory, evmAddress, chainId, PageSize, OrderDirection,} from \"@aave/react\";\n// …\nconst { data, loading, error } = useUserTransactionHistory({ market: evmAddress(\"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\"), user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), chainId: chainId(1), orderBy: { date: OrderDirection.DESC }, pageSize: PageSize.FIFTY,});\nif (loading) { return <p>Loading transaction history...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\n// data.items: UserTransactionItem[]// data.pageInfo.next: Cursor | null// data.pageInfo.prev: Cursor | nullFilter transactions by type.import { useUserTransactionHistory, evmAddress, chainId, PageSize, OrderDirection, UserTransactionType,} from \"@aave/react\";\n// …\nconst { data, loading, error } = useUserTransactionHistory({ market: evmAddress(\"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\"), user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), chainId: chainId(1), filter: [UserTransactionType.SUPPLY, UserTransactionType.WITHDRAW], orderBy: { date: OrderDirection.DESC }, pageSize: PageSize.TEN,});\nTransaction Types#\nThe user transaction history includes the following transaction types with their specific data:\nSUPPLY - Asset supply transactions with amount and reserve informationWITHDRAW - Asset withdrawal transactions with amount and reserve informationBORROW - Asset borrowing transactions with amount and reserve informationREPAY - Debt repayment transactions with amount and reserve informationUSAGE_AS_COLLATERAL - Collateral enable/disable transactions with enabled flagLIQUIDATION_CALL - Liquidation transactions with collateral and debt repaid details\nFiltering Options#\nUse the filter parameter to narrow down transaction results by transaction types:\nfilter: [UserTransactionType.SUPPLY, UserTransactionType.WITHDRAW];\nAvailable filter values: SUPPLY, WITHDRAW, BORROW, REPAY, USAGE_AS_COLLATERAL, LIQUIDATION_CALL\nOrdering Options#\nOrder transactions using the orderBy parameter:\ndate - Order by transaction date (ASC or DESC)\nEfficiency Mode (eMode)#\nHigh Efficiency Mode (eMode) in Aave optimizes borrowing power for price-correlated assets. This feature is particularly useful when both supplied and borrowed assets share similar economic price movements, such as stablecoins or derivatives that track the same underlying asset. By using eMode, users benefit from lower collateral requirements, effectively increasing their available borrowing capacity for correlated assets.\nTo enable efficiency mode and maximize capital efficiency for correlated assets, follow these steps.\n1Check Available eMode Categories#First, check the available eMode categories on the market to understand which category to enable.Let's say we have the following market object with available eMode categories:const market: Market = { __typename: \"Market\", name: \"Aave v3 Ethereum\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chain: { __typename: \"Chain\", chainId: 1, name: \"Ethereum\", // … }, eModeCategories: [ { __typename: \"EmodeMarketCategory\", id: 1, label: \"Stablecoins\", maxLTV: { __typename: \"DecimalValue\", value: \"0.97\", // … }, liquidationThreshold: { __typename: \"DecimalValue\", value: \"0.975\", // … }, liquidationPenalty: { __typename: \"DecimalValue\", value: \"0.01\", // … }, reserves: [ { __typename: \"EmodeMarketReserveInfo\", underlyingToken: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, canBeCollateral: true, canBeBorrowed: true, }, // … more reserves ], // … }, // … more categories ], // …};Where each EmodeMarketCategory object has the following properties:maxLTV.value - Maximum borrowing power (% of supplied collateral you can borrow)liquidationThreshold.value - How close you can get to liquidation (higher = safer)liquidationPenalty.value - How much you lose if liquidation happens (lower = better)reserves[] - an array of EmodeMarketReserveInfo objects, each representing a reserve that indicates if the asset can be used as collateral and/or borrowed in this specific eMode.2Prepare the Transaction Request#Next, we can proceed with creating the transaction request for the desired eMode operation.ReactTypeScriptGraphQLUse the useUserSetEmode hook to create the transaction request for enabling or disabling efficiency mode.import { useWalletClient } from \"wagmi\";import { useUserSetEmode, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [setEmode, settingEmode] = useUserSetEmode();\nconst execute = async () => { const result = await setEmode({ market: market.address, user: evmAddress(walletClient!.account.address), categoryId: 1, // Enable category 1 (Stablecoins) chainId: market.chain.chainId, });\n // …};To disable eMode, set categoryId to null:import { useWalletClient } from \"wagmi\";import { useUserSetEmode, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [setEmode, settingEmode] = useUserSetEmode();\nconst execute = async () => { const result = await setEmode({ market: market.address, user: evmAddress(walletClient!.account.address), categoryId: null, // Disable eMode chainId: market.chain.chainId, });\n // …};3Send the Transaction#Finally, send the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useUserSetEmode } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [setEmode, settingEmode] = useUserSetEmode();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = settingEmode.loading || sending.loading;const error = settingEmode.error || sending.error;\n// …\nconst execute = async () => { const result = await setEmode({ // … }).andThen(sendTransaction);\n if (result.isErr()) { console.error(\"eMode operation failed:\", result.error); } else { console.log(\"eMode operation successful with hash:\", result.value); }};\nLiquidations#\nLiquidate undercollateralized positions to earn liquidation bonuses and help maintain protocol stability.\n1Identify an Undercollateralized Position#First, identify a target user with a health factor below 1.0, and one of their borrow positions that is eligible for liquidation.const targetUser = evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\");Let's say you have identified the following user's borrow position:const position: MarketUserReserveBorrowPosition = { __typename: \"MarketUserReserveBorrowPosition\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, currency: { __typename: \"Currency\", symbol: \"WETH\", name: \"Wrapped Ether\", address: \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", // … }, debt: { __typename: \"TokenAmount\", amount: { __typename: \"DecimalValue\", value: \"1.5\", raw: \"1500000000000000000\", decimals: 18, // … }, // … }, // …};It's not in the scope of this guide to explain how to users with a health\nfactor below 1.0 and identify an undercollateralized position.2Choose the Liquidation Bonus#Next, decide which collateral token to receive as a liquidation bonus from the target user's collateral positions.Let's say you have identified the following collateral position.const collateral: MarketUserReserveSupplyPosition = { __typename: \"MarketUserReserveSupplyPosition\", market: { __typename: \"Market\", address: \"0x87870bca3f3fd6335c3f4ce8392d69350b4fa4e2\", chainId: 1, // … }, currency: { __typename: \"Currency\", symbol: \"USDC\", name: \"USD Coin\", address: \"0xA0b86a33E6441c8c5f0bb9b7e5e1f8bbf5b78b5c\", // … }, isCollateral: true, canBeCollateral: true, // …};3Prepare the Transaction Request#Then, create the transaction request for the liquidation operation.ReactTypeScriptGraphQLUse the useLiquidate hook to create the transaction request for liquidating the undercollateralized position.import { useLiquidate } from \"@aave/react\";\n// …\nconst [liquidate, liquidating] = useLiquidate();\nconst execute = async () => { const result = await liquidate({ chainId: position.market.chainId, market: position.market.address, user: targetUser, underlyingToken: position.currency.address, debtToCover: { max: true }, // Liquidate maximum debt collateralToken: collateral.currency.address, receiveAToken: false, // Receive collateral as aToken });\n // …};4Send the Transaction#Finally, send the transaction to execute the liquidation.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useLiquidate } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [liquidate, liquidating] = useLiquidate();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\n// Optional: combine loading statesconst loading = liquidating.loading || sending.loading;const error = liquidating.error || sending.error;\n// …\nconst execute = async () => { const result = await liquidate({ // … }).andThen(sendTransaction);\n if (result.isErr()) { console.error(\"Liquidation failed:\", result.error); } else { console.log(\"Liquidation successful with hash:\", result.value); }};PreviousIncentive ProgramsNextAave V3 on Aptos","tokens":2510,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259457070,"hash":"37e36e55c5646d9ce749a7aefb41b5da26159240"}
{"url":"https://www.anchor-lang.com/docs/updates/release-notes/0-29-0","domain":"anchor-lang.com","title":"0.29.0","text":"Anchor Project UpdatesRelease Notes0.29.0Anchor - Release Notes 0.29.0Anchor keeps a\nCHANGELOG but\nit's not easy to make sense what has changed, what effect does the change have\nand how to migrate. This is where release notes come in, an easy to digest and\nactionable view for each release.\n\nHow to update\n\nUpdate avm:\ncargo install --git https://github.com/otter-sec/anchor --tag v0.29.0 avm --locked\n\nUpdate anchor-cli:\navm install latest\n\nUpdate Anchor crate(s) to 0.29.0. Optionally, run cargo update to update\nother dependencies to the latest compatible versions.\n\nUpdate TS package(s) to 0.29.0.\n\nSolana 1.14 is no longer supported\nMinimum supported Solana version is now 1.16.0 because\n\nAll clusters including mainnet-beta are now running ^1.16\nThere is a\ncompatibility issue\nbetween 1.14 and 1.16\n\nIf you are still on Solana 1.14, update by running:\nsolana-install init 1.17.0\nOverride toolchain for the workspace\nAnchor.toml has a new section called [toolchain] that allows overriding the\ncurrent toolchain versions inside the workspace.\n[toolchain]\nanchor_version = \"0.29.0\" # `anchor-cli` version to use\nsolana_version = \"1.17.0\" # Solana version to use\nNotes\n\nFields are optional.\nanchor_version requires\navm to be installed.\nBefore this release, anchor_version and solana_version keys in\nAnchor.toml were being used for Docker verifiable builds only. Now, all\ncommands work via the [toolchain] section.\n\nInstall CLI from commit with avm\nIt is possible to install CLI from commit by running:\ncargo install --git https://github.com/otter-sec/anchor --rev 6cf200493a307c01487c7b492b4893e0d6f6cb23 anchor-cli --locked\nbut this overrides the anchor binary and does not work well with avm.\nIn this release, avm supports installing and switching between commits.\nInstall from a commit with avm install <VERSION>-<COMMIT>:\n# <VERSION>-<COMMIT>\navm install 0.28.0-6cf200493a307c01487c7b492b4893e0d6f6cb23\n\n# Full commit hash\navm install 6cf200493a307c01487c7b492b4893e0d6f6cb23\n\n# Short commit hash\navm install 6cf200\nUse a different version avm use <VERSION>-<COMMIT>:\navm use 0.28.0-6cf200493a307c01487c7b492b4893e0d6f6cb23\nSpecify toolchain.anchor_version as <VERSION>-<COMMIT>:\n[toolchain]\nanchor_version = \"0.28.0-6cf200493a307c01487c7b492b4893e0d6f6cb23\"\nMultiple files template\nPrograms created with anchor init or anchor new have a single lib.rs file\nbut not everyone prefers a single file approach for programs.\nThe most popular way of splitting the program into multiple files looks\nsomething like the following:\n├── constants.rs\n├── error.rs\n├── instructions\n│   ├── initialize.rs\n│   └── mod.rs\n├── lib.rs\n└── state\n └── mod.rs\nTo initialize a workspace with this program structure, run:\nanchor init <NAME> --template multiple\nor if you have an existing workspace:\nanchor new <NAME> --template multiple\nUpgradeable programs in tests\nYou can now configure upgradability of the programs in anchor test.\nIn Anchor.toml:\n[test]\nupgradeable = true\nor for an individual program:\n[[test.genesis]]\naddress = \"22Y43yTVxuUkoRKdm9thyRhQ3SdgQS7c7kB6UNCiaczD\"\nprogram = \"swap.so\"\nupgradeable = true\nLamport utilities\nTransferring lamports from a PDA is quite complicated due to the types that are\nbeing used.\nInstead of\n**ctx.accounts.from.to_account_info().try_borrow_mut_lamports()? -= amount;\n**ctx.accounts.to.to_account_info().try_borrow_mut_lamports()? += amount;\nyou can\nctx.accounts.from.sub_lamports(amount)?;\nctx.accounts.to.add_lamports(amount)?;\nSimilarly for getting the lamports, instead of\nlet lamports = ctx.accounts.my_account.to_account_info().lamports();\nyou can\nlet lamports = ctx.accounts.my_account.get_lamports();\nNote: The new methods are not only more ergonomic but they are also more\nperformant than the previous examples. This is because to_account_info method\nclones the data internally but the new methods use a reference to the underlying\ndata.\nType safe context bumps\nBefore this release, ctx.bumps used to be a BTreeMap<String, u8> which\ndoesn't provide type safety for the keys(account names).\nlet bump = *ctx.bumps.get(\"my_account\").unwrap();\nWith this release, there is an auto-generated struct that holds the bump values.\nlet bump = ctx.bumps.my_account;\nNote: The new way is not only more intuitive but also is more performant.\nThis is mainly because BTreeMap is heap-allocated and it has to resize and\ngrow occasionally.\nidl-build feature\nThere is a new way to generate IDLs via compilation.\nAdd idl-build feature to your program's Cargo.toml to try it out.\n[features]\nidl-build = [\"anchor-lang/idl-build\"]\nThe IDL will be built automatically when you run anchor build but if you'd\nlike to only generate the IDL, run:\nanchor idl build\nNotes\n\nAll crates that are being used for the IDL generation needs to be added to the\nidl-build feature list.\n\n[features]\nidl-build = [\n \"anchor-lang/idl-build\",\n \"anchor-spl/idl-build\",\n \"another-program/idl-build\"\n]\n\nCompile time checks are supported.\nExternal types from other Anchor programs are supported as long as the\nexternal crate has the idl-build feature(see another-program/idl-build).\nConflicting type names e.g. some_module::MyType and another_module::MyType\ncan be used together.\nGeneration time is a lot slower compared to the default method(parsing) due to\nRust compile times.\nEven though most of it works great, some parts are still rough around the\nedges and you may encounter parts that are not fully ironed out. Please\ncreate an issue if you run into\na problem.\n\nType aliases\nAnchor IDL now supports type aliases.\npub type U8Array = [u8; 8];\n\n#[program]\npub mod my_program {\n use super::*;\n\n pub fn type_alias(ctx: Context<TypeAlias>, u8_array: U8Array) -> Result<()> {\n msg!(\"{:?}\", u8_array);\n Ok(())\n }\n}\n\n#[derive(Accounts)]\npub struct TypeAlias {}\nGenerates the following IDL:\n{\n \"version\": \"0.1.0\",\n \"name\": \"my_program\",\n \"instructions\": [\n {\n \"name\": \"typeAlias\",\n \"accounts\": [],\n \"args\": [\n {\n \"name\": \"u8Array\",\n \"type\": {\n \"defined\": \"U8Array\"\n }\n }\n ]\n }\n ],\n \"types\": [\n {\n \"name\": \"U8Array\",\n \"type\": {\n \"kind\": \"alias\",\n \"value\": {\n \"array\": [\"u8\", 8]\n }\n }\n }\n ]\n}\nNote: This example only works with the default IDL generation\nmethod(parsing) for now because type aliases for default Rust types don't work\nproperly with\nidl-build(#2640).\nExport mpl-token-metadata\nanchor-spl with metadata feature enabled now exports the\nmpl-token-metadata crate.\nNote: Consider removing the mpl-token-metadata dependency to reduce the\npossibility of having conflicting versions:\n[dependencies]\nanchor-spl = { version = \"0.29.0\", features = [\"metadata\"] }\n- mpl-token-metadata = \"1.13.1\"\nand use the exported crate from anchor-spl:\nuse anchor_spl::metadata::mpl_token_metadata;\nTypeScript SDK improvements\n\nProgram.addEventListener method is now strongly typed -- correct types for\nthe event names and the event returned from the callback instead of any.\n\nanchor.workspace now lazy loads programs on-demand. Programs that are not\nbeing used in the tests won't get loaded and therefore won't cause errors.\n\nJavaScript convention is to use camelCase for property names but programs are\naccessed via PascalCase e.g. anchor.workspace.MyProgram which is\nunintuitive. Both variations work in this release.\nconst camel = anchor.workspace.myProgram;\nconst pascal = anchor.workspace.MyProgram;\n\nRemoved assert and base64-js dependency.\n\nNew docker image\nThe previous\nimage(projectserum/build) is now\ndeprecated, new image is\nbackpackapp/build.\nTo pull the latest image, run:\ndocker pull backpackapp/build:v0.29.0\nNote: anchor build --verifiable now works with the latest image.\nEnhanced performance\n0.29.0 performance is noticeably improved in all areas, the biggest one being\nbinary size\nwhich is reduced ~36% compared to 0.28.0!\nSimilar benchmarks can be found for\ncompute units\nand\nstack memory.\nNote: The benchmark results will vary between programs but the overall\ndirection should be the same.\n\nSee the full list of changes in the\nCHANGELOG.Previous0.30.0NextChangelogOn this pageHow to updateSolana 1.14 is no longer supportedOverride toolchain for the workspaceNotesInstall CLI from commit with avmMultiple files templateUpgradeable programs in testsLamport utilitiesType safe context bumpsidl-build featureNotesType aliasesExport mpl-token-metadataTypeScript SDK improvementsNew docker imageEnhanced performanceEdit on GitHub","tokens":2081,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259467890,"hash":"d4fd2f83191ef35191375cb81f8719dadcd798cb"}
{"url":"https://aave.com/docs/aave-v4/positions/withdraw","domain":"aave.com","title":"Withdraw Assets | Aave Protocol Documentation","text":"Withdraw Assets#\nLearn how to withdraw assets from your Aave v4 supply positions.\n\nWithdraw supplied assets from your Aave v4 positions to access your funds and any earned interest.\nWithdrawing assets while having an open borrow position may reduce the\ncollateralization ratio and lower the position's health factor. In some cases,\nthis may put the position at risk of being liquidated.\nWithdrawing#\nWithdrawing can be broken down into the following steps:\nIdentify the supply position to withdraw fromPreview the impact of the withdraw operationWithdraw the assets\nIdentify the Supply Position#\nGiven a list of user's supply positions, identify the supply position matching the token you want to withdraw and with a withdrawable amount that covers your needs.\nThe supplied position reserve should not be paused in order to withdraw from\nit.\nFor example, let’s say you have identified the following UserSupplyItem object.\nconst supplyPosition: UserSupplyItem = { reserve: { id: \"SGVsbG8h\", onChainId: \"42\", chain: { chainId: 1, name: \"Ethereum\", }, spoke: { address: \"0x123…\", // … }, asset: { underlying: { address: \"0xa0b86a33e6e2ad05ad6c9ac3b6e5e5f6e7b6c1b2\", // USDC }, // … }, status: { paused: false, }, // … other reserve properties }, isCollateral: true, balance: { amount: { value: BigDecimal(1042.5), // principal + accrued interest // … }, // … }, withdrawable: { amount: { value: BigDecimal(1000.0), // 1,000 USDC supplied // … }, // … }, // …};\nKeep in mind that if the asset is used as collateral (isCollateral: true), withdrawing may:\nReduce your borrowing capacity and lower the position’s health factor, increasing the risk of liquidation.If the collateral has a reserve.settings.collateralRisk greater than 0, lower the borrow APY on any open borrow positions in the same Spoke, effectively making those positions cheaper to maintain.\nPreview Withdraw#\nPreview the impact of a withdraw operation before committing to it.\nReactTypeScriptGraphQLSolidityUse the usePreview hook (or the imperative usePreviewAction variant) to preview the impact of the withdraw operation on the user's position.import { type WithdrawRequest, usePreview } from \"@aave/react\";\nfunction WithdrawPreview({ request }: { request: WithdrawRequest }) { const { data, error, loading } = usePreview({ action: { withdraw: request, }, });\n if (loading) return <div>Loading…</div>; if (error) return <div>Error: {error.message}</div>;\n // data: PreviewUserPosition return ( <div> <h3>Health Factor:</h3> <p>From: {data.healthFactor?.current ?? \"N/A\"}</p> <p>To: {data.healthFactor?.after ?? \"N/A\"}</p>\n <h3>User Risk Premium:</h3> <p>From: {data.riskPremium.current.normalized.toFixed(2)}%</p> <p>To: {data.riskPremium.after.normalized.toFixed(2)}%</p>\n <h3>Net APY:</h3> <p>From: {data.netApy.current.normalized.toFixed(2)}%</p> <p>To: {data.netApy.after.normalized.toFixed(2)}%</p>\n <h3>Net Collateral:</h3> <p>From: {data.netCollateral.current.value.toDisplayString(2)}</p> <p>To: {data.netCollateral.after.value.toDisplayString(2)}</p> </div> );}Where the WithdrawRequest can be as follows:const request: WithdrawRequest = { sender: evmAddress(\"0x789…\"), // User's address reserve: supplyPosition.reserve.id, amount: { erc20: { value: { exact: bigDecimal(500), // 500 USDC }, }, },};The PreviewUserPosition shows the impact of the withdraw operation by comparing current and after states, with the table below outlining key fields and how to interpret them.FieldImpacthealthFactor.[current → after]: BigDecimal|nullHigher is better(null if not applicable)riskPremium.[current → after]: PercentNumberLower is betternetApy.[current → after]: PercentNumberHigher is betternetCollateral.[current → after]: ExchangeAmountHigher is betternetBalance.[current → after]: ExchangeAmountUpdated balancemaxBorrowingPower.[current → after]: ExchangeAmountMaximum borrowing powerremainingBorrowingPower.[current → after]: ExchangeAmountRemaining borrowing powerotherConditions: UserPositionConditionVariation[]Dynamic config changes\nWithdrawing collateral updates the Dynamic Config within the same user position.\nThe otherConditions field is an array of objects describing the resulting dynamic config changes.\nCollateralFactorVariation – Collateral factor changeLiquidationFeeVariation – Liquidation fee changeMaxLiquidationBonusVariation – Maximum liquidation bonus changeYou can also specify a different currency to return fiat amounts in.import { Currency } from \"@aave/react\";\nconst { data, error, loading } = usePreview({ action: { withdraw: request, }, currency: Currency.Eur,});\nStep-by-Step#\nNow that we know how to preview the impact of a withdraw operation, let's see how to withdraw assets from a supply position.\nWithdrawing collaterals while having an open borrow position is a\nrisk-increasing action and will update the Dynamic\nConfig, which in turn updates the\nUser Risk Premium for the given position.\nReactTypeScriptGraphQLSolidityTo withdraw assets from an Aave supply position with AaveKit React, follow these steps.1Configure Wallet Integration#First, instantiate the useSendTransaction hook for the wallet library of your choice.import { useWalletClient } from \"wagmi\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: wallet } = useWalletClient();const [sendTransaction] = useSendTransaction(wallet);2Define the Withdraw Flow#Then, use the useWithdraw hook to prepare the withdraw operation.import { useWithdraw } from \"@aave/react\";\nconst [withdraw, { loading, error }] = useWithdraw((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"PreContractActionRequired\": return sendTransaction(plan.transaction); }});3Execute the Withdraw Operation#Then, execute the desired withdraw operation.import { bigDecimal, evmAddress } from \"@aave/react\";\nconst execute = async () => { const result = await withdraw({ sender: evmAddress(wallet.account.address), // User's address reserve: supplyPosition.reserve.id, amount: { erc20: { value: { exact: bigDecimal(500), // Withdraw 500 USDC }, }, }, });\n // …};4Handle the Result#Finally, handle the result.const execute = async () => { const result = await withdraw(/* … */);\n if (result.isErr()) { switch (result.error.name) { case \"CancelError\": // The user cancelled the operation return;\n case \"SigningError\": console.error( `Failed to sign the transaction: ${result.error.message}`, ); break;\n case \"TimeoutError\": console.error(`Transaction timed out: ${result.error.message}`); break;\n case \"TransactionError\": console.error(`Transaction failed: ${result.error.message}`); break;\n case \"ValidationError\": console.error(`Invalid withdrawal amount: ${result.error.message}`); break;\n case \"UnexpectedError\": console.error(result.error.message); break; } return; }\n console.log(\"Withdraw successful with hash:\", result.value.txHash);};\n\nAdvanced Usage#\nNetwork Fee#\nThis experimental AaveKit React hook currently works only with Viem or Wagmi\nintegrations. Support for additional wallet libraries may be added later.\nEstimate the network cost of any action using the same PreviewAction you pass to the usePreview hook.\nLet's consider the following example:\nimport { type PreviewAction } from \"@aave/react\";\nconst action: PreviewAction = { withdraw: { sender: evmAddress(\"0x123…\"), // User's address reserve: supplyPosition.reserve.id, amount: { erc20: { value: { exact: bigDecimal(42), // USDC }, }, }, },};\nUse the useNetworkFee hook to estimate both the network fee for the provided action and its fiat equivalent.\nimport { type PreviewAction, Currency } from \"@aave/react\";import { useNetworkFee } from \"@aave/react/viem\";\nfunction NetworkFee({ action }: { action: PreviewAction }) { const { data: fee, loading, error, } = useNetworkFee({ query: { estimate: action }, currency: Currency.Eur, });\n if (loading) return <p>Loading fee…</p>; if (error) return <p>Error: {error.message}</p>;\n return ( <p> Network Fee: {fee.amount.value.toDisplayString(2)} {fee.token.info.symbol} <span> ≈{fee.exchange.symbol} {fee.exchange.value.toDisplayString(2)} </span> </p> );}\nNative Tokens#\nWhen the Reserve's underlying token is the wrapped version of the chain's native token (e.g., WETH on Ethereum), you can withdraw the asset as the chain's native token using the Native Token Gateway.\nUse the reserve.asset.underlying.isWrappedNativeToken flag to determine if the underlying token is a wrapped native token. The Native Gateway address is available from the chain details.\nconst supplyPosition: UserSupplyItem = { reserve: { id: \"SGVsbG8h\", onChainId: \"42\", asset: { underlying: { address: \"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\", info: { name: \"Wrapped Ether\", symbol: \"WETH\", decimals: 18, // … }, isWrappedNativeToken: true, // … }, // … }, spoke: { address: \"0x123…\", // … }, chain: { chainId: 1, name: \"Ethereum\", nativeGateway: \"0xabc…\", }, // … }, balance: { amount: { value: BigDecimal(1.25), // … }, // … }, // …};\nSpecify the amount in the amount field as a native value.\nReactTypeScriptGraphQLSolidityconst execute = async () => { const result = await withdraw({ sender: evmAddress(wallet.account.address), // User's address reserve: supplyPosition.reserve.id, amount: { native: { exact: bigDecimal(1), // Withdraw 1 ETH }, }, });\n // …};PreviousBorrow AssetsNextRepay Loans","tokens":2325,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259467932,"hash":"9fb433505df6fce8af7069db4cd439c15d87bb04"}
{"url":"https://ethresear.ch/c/execution-layer-research/37","domain":"ethresear.ch","title":"Latest Execution Layer Research topics - Ethereum Research","text":"Latest topics in Execution Layer Research\n\n Execution Layer Research\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Execution Layer Research category\n\n The Execution Layer Research category is for research topics related specifically to the Execution Layer of Ethereum (previously often described as “eth1” [minus PoW]). This includes the EVM, state, sync, transactions, a…\n\n read more\n\n 0\n\n 2.6k\n\n Aug 2021\n\n Mempool Account Transaction Capacity from Historical Activity (MATCHA)\n\n account-abstraction,transaction-privacy\n\n 11\n\n 541\n\n 19h\n\n The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\n\n stateless\n\n 10\n\n 783\n\n 4d\n\n Designs for EVM gas accounting in EIP-7999\n\n fee-market\n\n 6\n\n 463\n\n 11d\n\n Proprietary AMMs and Ethereum\n\n mev\n\n 13\n\n 1.3k\n\n 12d\n\n CHAMP: Hardening the Mempool with CHain-Anchored, Multi-dimensional Peer Protection\n\n p2p,networking\n\n 0\n\n 106\n\n 12d\n\n Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter\n\n 1\n\n 131\n\n 18d\n\n How Hegotá can influence the state roadmap\n\n 1\n\n 218\n\n 19d\n\n Scaling Ethereum with recursive STARKs and the Trustless Log Index\n\n stateless,cross-shard\n\n 0\n\n 159\n\n 21d\n\n Native UTXOs on Ethereum\n\n stateless,utxo\n\n 30\n\n 4.4k\n\n 28d\n\n How Hegotá should approach gas repricing\n\n 0\n\n 184\n\n 29d\n\n Order-dependence as the classifying dimension for frame-transaction mempool admission\n\n 0\n\n 94\n\n 29d\n\n EIP-8141 and minimum required validation budget for privacy applications\n\n account-abstraction,transaction-privacy\n\n 2\n\n 248\n\n Sep 5\n\n An Evaluation of Authenticated UTXO Discovery with EIP-8304 and UTXO Proof Tables\n\n stateless,utxo\n\n 0\n\n 118\n\n Aug 27\n\n Why Decentralized State is important for Ethereum\n\n stateless\n\n 0\n\n 106\n\n Aug 4\n\n Scaling in Hegota: using the ETH transfer to anchor execution and bandwidth\n\n 2\n\n 260\n\n Jul 25\n\n Integrating Kleros for Onchain ARR\n\n 0\n\n 73\n\n Jun 30\n\n The Anatomy of Ethereum’s State Access\n\n stateless,execution\n\n 0\n\n 586\n\n Jun 29\n\n Hot-Cold Storage Separation in Practice\n\n stateless\n\n 0\n\n 214\n\n Jun 7\n\n CuEVM - Achieving Millions of TPS on GPUs for fuzzing and beyond\n\n security,parallelization\n\n 1\n\n 269\n\n May 20\n\n Seeking feedback on a new EVM+(Motoko)\n\n 1\n\n 115\n\n May 17\n\n Toward a Portable Verification Boundary for Ethereum\n\n zk-roll-up\n\n 0\n\n 83\n\n May 10\n\n Block Update Digests: Membership Proofs Without a Global State Tree\n\n stateless,rollup,sparse-merkle-tree,state-execution-separation\n\n 1\n\n 414\n\n May 7\n\n The Airgap Problem in DeFi\n\n 0\n\n 156\n\n May 2\n\n Break This: A Minimal, System-Independent Verification Primitive\n\n 0\n\n 72\n\n Apr 27\n\n Bridge Attacks Like the Recent Aave rsETH Exploit can be eliminated by a new n-VM architecture\n\n 2\n\n 337\n\n Apr 25\n\n The Missing Verification Primitive in Ethereum\n\n execution-environment\n\n 1\n\n 123\n\n Apr 18\n\n Frame Transactions Through a Statelessness Lens\n\n stateless\n\n 11\n\n 733\n\n Apr 15\n\n Snap v2: Replacing Trie Healing with BALs\n\n chain-sync\n\n 0\n\n 408\n\n Apr 12\n\n The Path Towards Binary Tries 2: How Fast Is the Binary Trie Today? MPT vs. BTree\n\n 0\n\n 139\n\n Apr 4","tokens":784,"squid":"ink-research","role":"Deep Scholar","at":1791259471554,"hash":"74b9d1af28cc16b386143fd6a8b7166cd42ab03a"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/oracles","domain":"aave.com","title":"Oracles | Aave Protocol Documentation","text":"Oracles#\nReference for the aave-oracle Move package.\nOverview#\nThe Aave Oracle is a contract that manages asset prices and price sources for the Aave Protocol on Aptos. It allows authorized administrators to set, update, and remove price feeds for assets, and provides functions to query asset prices.\nWrite Methods#\nset_asset_feed_id#\npublic entry fun set_asset_feed_id(account: &signer, asset: address, feed_id: vector<u8>)\nSets the price feed ID for a given asset.\nThis method can only be called by a POOL_ADMIN or ASSET_LISTING_ADMIN. Please look at the ACLManager contract for further details on system roles.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer with admin privilegesassetaddressThe address of the asset for which feed is setfeed_idvector<u8>The ID of the Chainlink price feed for the asset\nbatch_set_asset_feed_ids#\npublic entry fun batch_set_asset_feed_ids(account: &signer, assets: vector<address>, feed_ids: vector<vector<u8>>)\nSets the price feed IDs for multiple assets in a single transaction.\nThis method can only be called by a POOL_ADMIN or ASSET_LISTING_ADMIN. Please look at the acl_manage contract for further details on system roles.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer with admin privilegesassetsvector<address>The addresses of the assets for which feeds are being setfeed_idsvector<vector<u8>>The IDs of the Chainlink price feeds for each asset. Length must match the assets vector\nremove_asset_feed_id#\npublic entry fun remove_asset_feed_id(account: &signer, asset: address)\nRemoves the price feed for a given asset.\nThis method can only be called by a POOL_ADMIN or ASSET_LISTING_ADMIN. Please look at the acl_manage contract for further details on system roles.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer with admin privilegesassetaddressThe address of the asset to remove the feed for\nbatch_remove_asset_feed_ids#\npublic entry fun batch_remove_asset_feed_ids(account: &signer, assets: vector<address>)\nRemoves the price feeds for multiple assets in a single transaction.\nThis method can only be called by a POOL_ADMIN or ASSET_LISTING_ADMIN. Please look at the ACLManager contract for further details on system roles.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer with admin privilegesassetsvector<address>The addresses of the assets to remove feeds for\nView Methods#\nget_asset_price#\n#[view]public fun get_asset_price(asset: address): u256\nReturns the price of the supported asset in BASE_CURRENCY of the Aave Market in wei.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the asset\nReturn Values:\nTypeDescriptionu256The price of the asset in BASE_CURRENCY of the Aave market to its smallest unit\nget_assets_prices#\n#[view]public fun get_assets_prices(assets: vector<address>): vector<u256>\nReturns a list of prices from a list of the supported assets addresses in BASE_CURRENCY of the Aave Market. All prices are in the smallest unit of the asset.\nInput Parameters:\nNameTypeDescriptionassetsvector<address>The list of assets addresses for which price is being queried\nReturn Values:\nTypeDescriptionvector<u256>The prices of the given assets in BASE_CURRENCY of the Aave market in wei\nget_asset_price_decimals#\n#[view]public fun get_asset_price_decimals(): u8\nReturns the number of decimals used for asset prices.\nReturn Values:\nTypeDescriptionu8The number of decimals for asset prices (18)\noracle_address#\n#[view]public fun oracle_address(): address\nReturns the address of the oracle resource account.\nReturn Values:\nTypeDescriptionaddressThe address of the oracle accountPreviousPool ConfiguratorNextAave Logic","tokens":910,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259487416,"hash":"28dce33e8d709d217ba532df0894d271438182b3"}
{"url":"https://ethresear.ch/t/how-hegota-can-influence-the-state-roadmap/25895/1","domain":"ethresear.ch","title":"How Hegotá can influence the state roadmap - Execution Layer Research - Ethereum Research","text":"How Hegotá can influence the state roadmap \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 3\n\n 1 / 2\n\n Sep 2\n\n 19d ago\n\n post by misilva73 on Sep 3\n\n misilva73\n\nThis is an opinion piece from myself and @CPerezz. We would like to thank @fradamt for catching an error.\n\nIn this opinion piece, we discuss how EIPs proposed for Hegotá can impact our current work on state. It thus focuses on those EIPs with a direct impact on state management, state access or the trie migration.\nThe state roadmap has two goals in our view:\n\nKeep state manageable to hold, access and serve as throughput rises.\nPrepare a safe transition to a new state trie.\n\nHegotá can help by keeping state growth within a clear budget, keeping Frames’ new state bounded, resolving some legacy state issues and, if fork timing allows, improving access to existing state through Block Access List sidecars. It should defer changes whose benefit is small today but whose cost would show up during the migration or in increased state growth.\nHegotá follows Glamsterdam’s introduction of BALs (EIP-7928) and state gas (EIP-8037); the PBT migration is expected later, in fork I*.\nQuick primer on PBT and the migration\nThe Partitioned Binary Tree (PBT), specified in EIP-8297, replaces Ethereum’s current state trie layout with a binary structure designed for smaller proofs and more efficient proving. It separates different kinds of state into zones and stores contract code by its content, allowing identical code to be shared.\nEIP-8347 proposes an offline migration: clients convert the state at a finalized anchor block and then use block access lists (BALs) to replay changes until the new tree catches up. The PBT activation fork later switches the state root from MPT to PBT. This avoids a full conversion at the activation boundary, but makes complete and reliably available BALs a migration dependency.\nEIP-8025’s optional execution proofs tilt the tradeoff further toward this offline approach. An online migration would otherwise have to keep proof generation working against both trees through the transition. This is not an argument for or against EIP-8025, but it affects the migration design.\nState growth control: observe, then choose\nEIP-8037 introduces a separate state-gas dimension, priced via a standardized cost per state byte (CPSB), so that all state-creating operations charge proportionally to the bytes they write and state growth is bounded. This EIP is scheduled for Glamsterdam.\nAfter Glamsterdam activates, the first step is to observe how demand for state creation responds to EIP-8037 and compare state-gas and execution-gas utilization with their targets. That evidence determines whether Hegotá should modify CPSB or the state-gas mechanism at all. There are three possible scenarios:\n\nState and execution demand are mismatched: one resource’s utilization remains far from its target while the other resource constrains the block. This is an EIP-8037 failure mode. In this case, we should adopt EIP-8372, which performs a one-time recalibration of CPSB and scales the raw state-gas limit at the hard fork boundary, bringing state and execution capacity back into balance.\n\nDemand is balanced, but Hegotá raises the block gas limit: in this case, we should adopt EIP-8368 to re-derive CPSB for the higher limit and keep state growth on target without changing the mechanism.\n\nDemand is balanced and the block gas limit stays unchanged: in this case, we should make no Hegotá update and retain EIP-8037’s existing parameters.\n\nEIP-8368 and EIP-8372 should therefore remain alternative contingency paths until there is enough post-Glamsterdam utilization data. The decision should be evidence-gated and dependent on the final gas limit target for the fork.\nFrames need a bounded state footprint\nEIP-8141 introduces frame transactions as Hegotá’s native account abstraction design. Programmable validation must read only a bounded slice of state so that validity-checking nodes, including future inclusion-list builders, do not need to hold the whole state. This is why we should push back on ERC-20 fee sponsorship as a Frames feature: it would make validity depend on arbitrary token storage and defeat that constraint.\nTwo Frame extensions add new state types. EIP-8250 adds keyed nonces, and EIP-8272 adds a rolling window of recent application state roots. Both can begin as regular storage in a system contract and move into their own PBT zone later. This only works if demand stays bounded, especially for keyed nonces, where each new key adds a permanent slot. Privacy pool usage is the best current proxy, and nullifier growth looks feasible so far based on this Dune dashboard. We should keep watching it as adoption grows.\nResolve the legacy accounts\nEIP-8253 addresses a small set of legacy accounts left over from before Spurious Dragon: accounts with storage but no code and a zero nonce. Hegotá should remove this account shape before the PBT migration. EIP-8253 does so by setting the nonce of 28 accounts to 1, while an alternative would be to clear their 129 storage entries. The nonce bump is the smaller and simpler transition; clearing the storage removes more state. We should resolve the anomaly in Hegotá, choosing the exact mechanism after verifying the account list and comparing the transition complexity.\nAdd BAL as sidecars if fork timing allows\nEIP-7928’s Block Access List (BAL) contains every account, storage slot, and code or balance/nonce change a block touches. EIP-8146 moves BAL delivery out of the payload and sends it early on its own channel, giving clients more time to prefetch state and compute the state root.\nThis is a good improvement if it does not delay the fork. Before including it, we should benchmark the execution benefit of one additional second of prefetching and state-root calculation.\nState tiering can wait\nToday’s client databases weren’t built for multi-terabyte state. A possible fix is hot/cold separation: keep hot state in the live database and push cold state to flat files on cheaper media. Measurements show that about 94% of storage writes hit state from the last 30 days, and that the top 1% of accounts absorb 96–98% of reads (Hot-Cold Storage Separation in Practice, The Anatomy of Ethereum’s State Access). Cold state should target HDDs, since big, slow, cheap disks need a job.\nEIP-8188 records the last block that wrote to each account and storage slot, providing a clean signal for this split. We will likely want it eventually, but it puts write-recency into state while the current PBT leaf format does not represent it. Adding it before the migration would mean resolving that gap and carrying more data through the conversion, while its main operational benefit arrives only as state approaches the TB mark.\nWe should therefore revisit EIP-8188 after the trie migration and keep only low-priority exploration going for now. More work is also needed on serving cold state from HDDs without making access too expensive.\nSETCODEFROM over SETDELEGATE\nEIP-7819’s SETDELEGATE creates accounts that delegate to existing code. The factory can later change or clear that delegation. EIP-8298’s SETCODEFROM lets an account adopt code already deployed elsewhere. For EIP-7702 accounts, this permanently disables ECDSA transactions under EIP-3607, offering a path to post-quantum wallets.\nBoth reduce duplicate code: SETDELEGATE stores a short delegation indicator, while SETCODEFROM reuses the code without copying it. EIP-8037 charges for duplicate bytes even though PBT stores identical code only once. Roughly 62% of deployed contracts reportedly reuse existing bytecode, so deployment savings would remain after the migration.\nNeither is needed for Hegotá. If we include one, it should be EIP-8298 for its code reuse and ECDSA migration path. EIP-7819 makes clones cheaper and keeps them upgradeable, but its main benefit is lower application gas costs.\nSELFDESTRUCT and ephemeral storage\nEIP-4758 removes the only account-deletion case left by EIP-6780: an account created and self-destructed in the same transaction. Removing this case is neutral to PBT or its migration, since these accounts do not exist in the pre-state and do not survive into the post-state.\nThe plan to replace SELFDESTRUCT is EIP-8360’s TCREATE, a CREATE2 variant that deploys a contract whose code, nonce, and storage are all removed at the end of the transaction, leaving only its balance behind. Inside a TCREATEd contract, SLOAD/SSTORE are priced and behave like TLOAD/TSTORE.\nThere are some use-cases that would benefit from this ephemeral storage layer, however, current usage is limited. In a sample covering one month of blocks, we see an average of roughly 1,500 accounts per day created and self-destructed in the same transaction. There are two patterns of usage in this sample, namely, internal wallet maangement for centralised exchanges or NFT marketplaces and laundering from scams. At current usage, and counting only 120 bytes per account while ignoring storage, this deletion avoids roughly 62 MiB of state growth per year, which is fairly small. Thus, this is not a clear win and likely not a priority for now.\n\n read \n\n 4\n min\n\n 14 days later\n\n post by Helkomine on Sep 17\n\n Helkomine\n\n We should shift our perspective, as ephemeral contracts already constitute a distinct market segment given the projects committed to using them. Measuring past state is of little help, given the shift in design. The network’s slow adoption of a native solution risks causing block congestion due to frequent state occupancy in the future.\n\n Powered by Discourse","tokens":2414,"squid":"ink-research","role":"Deep Scholar","at":1791259487757,"hash":"3b15f2b1f79994bd681c6c8d539e20e721a29702"}
{"url":"https://docs.soliditylang.org/en/latest/","domain":"docs.soliditylang.org","title":"Solidity — Solidity 0.8.38-develop documentation","text":"Solidity\n\n Edit on GitHub\n\nSolidity\nSolidity is an object-oriented, high-level language for implementing smart contracts.\nSmart contracts are programs that govern the behavior of accounts within the Ethereum state.\nSolidity is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM).\nIt is influenced by C++, Python, and JavaScript.\nYou can find more details about which languages Solidity has been inspired by in the language influences section.\nSolidity is statically typed, supports inheritance, libraries, and complex user-defined types, among other features.\nWith Solidity, you can create contracts for uses such as voting, crowdfunding, blind auctions, and multi-signature wallets.\nWhen deploying contracts, you should use the latest released version of Solidity.\nApart from exceptional cases, only the latest version receives\nsecurity fixes.\nFurthermore, breaking changes, as well as new features, are introduced regularly.\nWe currently use a 0.y.z version number to indicate this fast pace of change.\n\nWarning\nSolidity recently released the 0.8.x version that introduced a lot of breaking changes.\nMake sure you read the full list.\n\nIdeas for improving Solidity or this documentation are always welcome,\nread our contributors guide for more details.\n\nHint\nYou can download this documentation as PDF, HTML or Epub\nby clicking on the versions flyout menu in the bottom-right corner and selecting the preferred download format.\n\nGetting Started\n1. Understand the Smart Contract Basics\nIf you are new to the concept of smart contracts, we recommend you to get started by digging into the “Introduction to Smart Contracts” section, which covers the following:\n\nA simple example smart contract written in Solidity.\nBlockchain Basics.\nThe Ethereum Virtual Machine.\n\n2. Get to Know Solidity\nOnce you are accustomed to the basics, we recommend you read the “Solidity by Example”\nand “Language Description” sections to understand the core concepts of the language.\n3. Install the Solidity Compiler\nThere are various ways to install the Solidity compiler,\nsimply choose your preferred option and follow the steps outlined on the installation page.\n\nHint\nYou can try out code examples directly in your browser with the\nRemix IDE.\nRemix is a web browser-based IDE that allows you to write, deploy and administer Solidity smart contracts,\nwithout the need to install Solidity locally.\n\nWarning\nAs humans write software, it can have bugs.\nTherefore, you should follow established software development best practices when writing your smart contracts.\nThis includes code review, testing, audits, and correctness proofs.\nSmart contract users are sometimes more confident with code than their authors,\nand blockchains and smart contracts have their own unique issues to watch out for,\nso before working on production code, make sure you read the Security Considerations section.\n\n4. Learn More\nIf you want to learn more about building decentralized applications on Ethereum,\nthe Ethereum Developer Resources can help you with further general documentation around Ethereum,\nand a wide selection of tutorials, tools, and development frameworks.\nIf you have any questions, you can try searching for answers or asking on the\nEthereum StackExchange,\nor our Gitter channel.\n\nTranslations\nCommunity contributors help translate this documentation into several languages.\nNote that they have varying degrees of completeness and up-to-dateness.\nThe English version stands as a reference.\nYou can switch between languages by clicking on the flyout menu in the bottom-right corner\nand selecting the preferred language.\n\nChinese\nFrench\nIndonesian\nJapanese\nKorean\nPersian\nRussian\nSpanish\nTurkish\n\nNote\nWe set up a GitHub organization and translation workflow to help streamline the community efforts.\nPlease refer to the translation guide in the solidity-docs org\nfor information on how to start a new language or contribute to the community translations.\n\nContents\nKeyword Index, Search Page\n\nBasics\n\nIntroduction to Smart Contracts\nA Simple Smart Contract\nBlockchain Basics\nThe Ethereum Virtual Machine\n\nSolidity by Example\nVoting\nBlind Auction\nSafe Remote Purchase\nMicropayment Channel\nModular Contracts\n\nInstalling the Solidity Compiler\nVersioning\nRemix\nnpm / Node.js\nDocker\nLinux Packages\nmacOS Packages\nStatic Binaries\nBuilding from Source\nCMake Options\nThe Version String in Detail\nImportant Information About Versioning\n\nLanguage Description\n\nLayout of a Solidity Source File\nSPDX License Identifier\nPragmas\nImporting other Source Files\nComments\n\nStructure of a Contract\nState Variables\nFunctions\nFunction Modifiers\nEvents\nErrors\nStruct Types\nEnum Types\n\nTypes\nValue Types\nReference Types\nMapping Types\nOperators\nConversions between Elementary Types\nConversions between Literals and Elementary Types\n\nUnits and Globally Available Variables\nEther Units\nTime Units\nSpecial Variables and Functions\nReserved Keywords\n\nExpressions and Control Structures\nControl Structures\nFunction Calls\nCreating Contracts via new\nOrder of Evaluation of Expressions\nAssignment\nScoping and Declarations\nChecked or Unchecked Arithmetic\nError handling: Assert, Require, Revert and Exceptions\n\nContracts\nCreating Contracts\nVisibility and Getters\nFunction Modifiers\nTransient Storage\nComposability of Smart Contracts and the Caveats of Transient Storage\nConstant and Immutable State Variables\nCustom Storage Layout\nFunctions\nEvents\nCustom Errors\nInheritance\nAbstract Contracts\nInterfaces\nLibraries\nUsing For\n\nInline Assembly\nExample\nAccess to External Variables, Functions and Libraries\nThings to Avoid\nConventions in Solidity\nAdvanced Safe Use of Memory\n\nCheatsheet\nOrder of Precedence of Operators\nABI Encoding and Decoding Functions\nMembers of bytes and string\nMembers of address\nBlock and Transaction Properties\nValidations and Assertions\nMathematical and Cryptographic Functions\nContract-related\nType Information\nFunction Visibility Specifiers\nModifiers\n\nLanguage Grammar\nSolidityParser\nSolidityLexer\n\nCompiler\n\nUsing the Compiler\nUsing the Commandline Compiler\nSetting the EVM Version to Target\nCompiler Input and Output JSON Description\nExperimental Mode\n\nAnalysing the Compiler Output\nSolidity IR-based Codegen Changes\nSemantic Only Changes\nInternals\n\nInternals\n\nLayout of State Variables in Storage and Transient Storage\nMappings and Dynamic Arrays\nJSON Output\n\nLayout in Memory\nDifferences to Layout in Storage\n\nLayout of Call Data\nCleaning Up Variables\nSource Mappings\nThe Optimizer\nBenefits of Optimizing Solidity Code\nDifferences between Optimized and Non-Optimized Code\nOptimizer Parameter Runs\nOpcode-Based Optimizer Module\nYul-Based Optimizer Module\nCodegen-Based Optimizer Module\n\nContract Metadata\nEncoding of the Metadata Hash in the Bytecode\nUsage for Automatic Interface Generation and NatSpec\nUsage for Source Code Verification\n\nContract ABI Specification\nBasic Design\nFunction Selector\nArgument Encoding\nTypes\nDesign Criteria for the Encoding\nFormal Specification of the Encoding\nFunction Selector and Argument Encoding\nExamples\nUse of Dynamic Types\nEvents\nErrors\nJSON\nStrict Encoding Mode\nNon-standard Packed Mode\nEncoding of Indexed Event Parameters\n\nAdvisory content\n\nSecurity Considerations\nPitfalls\nRecommendations\n\nList of Known Bugs\nFrequently Reported Non-Bugs\nNon-canonical ABI-encoded calldata is accepted\nDifferent results between the evmasm and the IR pipeline\nOrder of evaluation\nStale references into storage\n\nSolidity v0.5.0 Breaking Changes\nSemantic Only Changes\nSemantic and Syntactic Changes\nExplicitness Requirements\nDeprecated Elements\nInteroperability With Older Contracts\nExample\n\nSolidity v0.6.0 Breaking Changes\nChanges the Compiler Might not Warn About\nExplicitness Requirements\nSemantic and Syntactic Changes\nNew Features\nInterface Changes\nHow to update your code\n\nSolidity v0.7.0 Breaking Changes\nSilent Changes of the Semantics\nChanges to the Syntax\nRemoval of Unused or Unsafe Features\nInterface Changes\nHow to update your code\n\nSolidity v0.8.0 Breaking Changes\nSilent Changes of the Semantics\nNew Restrictions\nInterface Changes\nHow to update your code\n\nAdditional Material\n\nNatSpec Format\nDocumentation Example\nTags\nDocumentation Output\n\nSMTChecker and Formal Verification\nTutorial\nSMTChecker Options and Tuning\nAbstraction and False Positives\nReal World Assumptions\n\nYul\nMotivation and High-level Description\nSimple Example\nStand-Alone Usage\nInformal Description of Yul\nSpecification of Yul\nSpecification of Yul Object\nYul Optimizer\nComplete ERC20 Example\n\nImport Path Resolution\nVirtual Filesystem\nImports\nBase Path and Include Paths\nAllowed Paths\nImport Remapping\nUsing URLs in imports\n\nResources\n\nStyle Guide\nIntroduction\nCode Layout\nOrder of Layout\nNaming Conventions\nNatSpec\n\nCommon Patterns\nWithdrawal from Contracts\nRestricting Access\nState Machine\n\nResources\nGeneral Resources\nIntegrated (Ethereum) Development Environments\nEditor Integrations\nSolidity Tools\nThird-Party Solidity Parsers and Grammars\n\nContributing\nTeam Calls\nHow to Report Issues\nWorkflow for Pull Requests\nAI-Assisted Contributions\nRunning the Compiler Tests\nRunning the Fuzzer via AFL\nWhiskers\nDocumentation Style Guide\nSolidity Language Design\n\nLanguage Influences\nSolidity Brand Guide\nThe Solidity Brand\nSolidity Brand Name\nSolidity Logo License\nSolidity Logo Guidelines\nCredits","tokens":2324,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259488155,"hash":"43604b5b75af1f08868a3ea8cb16253b2e847df0"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/pool-configurator","domain":"aave.com","title":"Pool Configurator | Aave Protocol Documentation","text":"Pool Configurator#\nReference for the aave-config Move package. The asset listing and risk parameter methods.\nOnly Asset Listing Or Pool Admins Methods#\ninit_reserves#\npublic entry fun init_reserves( account: &signer, underlying_asset: vector<address>, treasury: vector<address>, a_token_name: vector<String>, a_token_symbol: vector<String>, variable_debt_token_name: vector<String>, variable_debt_token_symbol: vector<String>)\nInitializes multiple reserves using the arrays of initialization parameters as input. Only callable by accounts with the Asset Listing Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerunderlying_assetvector<address>The addresses of the underlying assetstreasuryvector<address>The addresses of the aToken contract implementationsa_token_namevector<String>The addresses of the variable debt token contractsa_token_symbolvector<String>The addresses of the interest rate strategy contractsvariable_debt_token_namevector<String>The names of the aTokensvariable_debt_token_symbolvector<String>The symbols of the aTokens\nOnly Emergency Admin Methods#\nset_pool_pause#\npublic entry fun set_pool_pause( account: &signer, paused: bool, grace_period: u64)\nPauses or unpauses all the protocol reserves. In the paused state all the protocol interactions are suspended. Only callable by accounts with the Emergency Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerpausedbooltrue if the protocol needs to be paused, otherwise falsegrace_periodu64Count of seconds after unpause during which liquidations will not be available\nOnly Emergency Or Pool Admin Methods#\nset_reserve_pause#\npublic entry fun set_reserve_pause( account: &signer, asset: address, paused: bool, grace_period: u64)\nPauses a reserve. A paused reserve does not allow any interaction (supply, borrow, repay, liquidate, atoken transfers). Only callable by accounts with the Emergency Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservepausedbooltrue if pausing the reserve, false if unpausing the reservegrace_periodu64Count of seconds after unpause during which liquidations will not be available\nOnly Pool Admin Methods#\ndrop_reserve#\npublic entry fun drop_reserve( account: &signer, asset: address)\nDrops a reserve entirely. Only callable by accounts with the Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the reserve to drop\nset_reserve_active#\npublic entry fun set_reserve_active( account: &signer, asset: address, active: bool)\nActivate or deactivate a reserve. Only callable by accounts with the Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reserveactivebooltrue if the reserve needs to be active, false otherwise\nupdate_flashloan_premium_total#\npublic entry fun update_flashloan_premium_total( account: &signer, new_flashloan_premium_total: u128)\nUpdates the total flash loan premium. The premium is calculated on the total amount borrowed, and is expressed in bps. Only callable by accounts with the Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callernew_flashloan_premium_totalu128The total flashloan premium\nupdate_flashloan_premium_to_protocol#\npublic entry fun update_flashloan_premium_to_protocol( account: &signer, new_flashloan_premium_to_protocol: u128)\nUpdates the flash loan premium collected by protocol reserves. The premium to protocol is calculated on the total flashloan premium, and is expressed in bps. Only callable by accounts with the Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callernew_flashloan_premium_to_protocolu128The part of the flashloan premium sent to the protocol treasury\nOnly Risk Or Pool Admins Methods#\nset_reserve_borrowing#\npublic entry fun set_reserve_borrowing( account: &signer, asset: address, enabled: bool)\nEnables or disables borrowing on a reserve. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reserveenabledbooltrue if borrowing needs to be enabled, false otherwise\nset_reserve_flash_loaning#\npublic entry fun set_reserve_flash_loaning( account: &signer, asset: address, enabled: bool)\nEnables or disables flash loans for a reserve. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressAddress of the reserve assetenabledbooltrue to enable, false to disable\nconfigure_reserve_as_collateral#\npublic entry fun configure_reserve_as_collateral( account: &signer, asset: address, ltv: u256, liquidation_threshold: u256, liquidation_bonus: u256)\nConfigures the reserve collateralization parameters. All the values are expressed in bps. A value of 10000 results in 100.00%. The liquidation_bonus is always above 100%. A value of 10500 means the liquidator will receive a 5% bonus. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reserveltvu256The loan to value of the asset when used as collateralliquidation_thresholdu256The threshold at which loans using this asset as collateral will be considered undercollateralizedliquidation_bonusu256The bonus liquidators receive to liquidate this asset\nset_reserve_freeze#\npublic entry fun set_reserve_freeze( account: &signer, asset: address, freeze: bool)\nFreeze or unfreeze a reserve. A frozen reserve doesn't allow any new supply or borrow but allows repayments, liquidations, rate rebalances and withdrawals. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservefreezebooltrue if the reserve needs to be frozen, false otherwise\nset_borrowable_in_isolation#\npublic entry fun set_borrowable_in_isolation( account: &signer, asset: address, borrowable: bool)\nSets the borrowable in isolation flag for the reserve. When this flag is set to true, the asset will be borrowable against isolated collaterals and the borrowed amount will be accumulated in the isolated collateral's total debt exposure. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reserveborrowablebooltrue if the asset should be borrowable in isolation, false otherwise\nset_reserve_factor#\npublic entry fun set_reserve_factor( account: &signer, asset: address, new_reserve_factor: u256)\nUpdates the reserve factor of a reserve. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_reserve_factoru256The new reserve factor of the reserve\nset_debt_ceiling#\npublic entry fun set_debt_ceiling( account: &signer, asset: address, new_debt_ceiling: u256)\nSets the debt ceiling for an asset. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_debt_ceilingu256The new debt ceiling\nset_siloed_borrowing#\npublic entry fun set_siloed_borrowing( account: &signer, asset: address, new_siloed: bool)\nSets siloed borrowing for an asset. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_siloedboolThe new siloed borrowing state - enable or disable siloed borrowing for the reserve\nset_borrow_cap#\npublic entry fun set_borrow_cap( account: &signer, asset: address, new_borrow_cap: u256)\nUpdates the borrow cap of a reserve. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_borrow_capu256The new borrow cap of the reserve in whole tokens. A borrow cap of 0 signifies that there is no cap\nset_supply_cap#\npublic entry fun set_supply_cap( account: &signer, asset: address, new_supply_cap: u256)\nUpdates the supply cap of a reserve. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_supply_capu256The new supply cap of the reserve in whole tokens. A supply cap of 0 signifies that there is no cap\ndisable_liquidation_grace_period#\npublic entry fun disable_liquidation_grace_period( account: &signer, asset: address)\nDisables the liquidation grace period for a reserve. Only callable by accounts with the Emergency Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressAddress of the reserve asset\nset_liquidation_protocol_fee#\npublic entry fun set_liquidation_protocol_fee( account: &signer, asset: address, new_fee: u256)\nUpdates the liquidation protocol fee of reserve. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_feeu256The new liquidation protocol fee of the reserve, expressed in bps\nset_emode_category#\npublic entry fun set_emode_category( account: &signer, category_id: u8, ltv: u16, liquidation_threshold: u16, liquidation_bonus: u16, label: String)\nAdds a new efficiency mode (eMode) category. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callercategory_idu8The id of the category to be configured. category_id ≠ 0. NOTE: category 0 is reserved for the default category i.e. non-eModeltvu16The loan to value for the associated eMode category. It must be less than or equal to the liquidationThresholdliquidation_thresholdu16The liquidation threshold associated with the categoryliquidation_bonusu16The liquidation bonus associated with the categorylabelStringA custom label identifying the category\nset_asset_emode_category#\npublic entry fun set_asset_emode_category( account: &signer, asset: address, new_category_id: u8)\nSets the efficiency mode category for an asset. Only callable by accounts with the Risk Admin or Pool Admin role.\nInput Parameters:\nNameTypeDescriptionaccount&signerThe signer account of the callerassetaddressThe address of the underlying asset of the reservenew_category_idu8The new eMode category for the assetPreviousAccess ControlNextOracles","tokens":2829,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259497347,"hash":"fe695f4df000224ce269d16592b85a85b01b7d53"}
{"url":"https://ethresear.ch/t/how-hegota-can-influence-the-state-roadmap/25895/2","domain":"ethresear.ch","title":"How Hegotá can influence the state roadmap - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 3\n\n 2 / 2\n\n Sep 16\n\n 19d ago\n\n post by misilva73 on Sep 3\n\n misilva73\n\nThis is an opinion piece from myself and @CPerezz. We would like to thank @fradamt for catching an error.\n\nIn this opinion piece, we discuss how EIPs proposed for Hegotá can impact our current work on state. It thus focuses on those EIPs with a direct impact on state management, state access or the trie migration.\nThe state roadmap has two goals in our view:\n\nKeep state manageable to hold, access and serve as throughput rises.\nPrepare a safe transition to a new state trie.\n\nHegotá can help by keeping state growth within a clear budget, keeping Frames’ new state bounded, resolving some legacy state issues and, if fork timing allows, improving access to existing state through Block Access List sidecars. It should defer changes whose benefit is small today but whose cost would show up during the migration or in increased state growth.\nHegotá follows Glamsterdam’s introduction of BALs (EIP-7928) and state gas (EIP-8037); the PBT migration is expected later, in fork I*.\nQuick primer on PBT and the migration\nThe Partitioned Binary Tree (PBT), specified in EIP-8297, replaces Ethereum’s current state trie layout with a binary structure designed for smaller proofs and more efficient proving. It separates different kinds of state into zones and stores contract code by its content, allowing identical code to be shared.\nEIP-8347 proposes an offline migration: clients convert the state at a finalized anchor block and then use block access lists (BALs) to replay changes until the new tree catches up. The PBT activation fork later switches the state root from MPT to PBT. This avoids a full conversion at the activation boundary, but makes complete and reliably available BALs a migration dependency.\nEIP-8025’s optional execution proofs tilt the tradeoff further toward this offline approach. An online migration would otherwise have to keep proof generation working against both trees through the transition. This is not an argument for or against EIP-8025, but it affects the migration design.\nState growth control: observe, then choose\nEIP-8037 introduces a separate state-gas dimension, priced via a standardized cost per state byte (CPSB), so that all state-creating operations charge proportionally to the bytes they write and state growth is bounded. This EIP is scheduled for Glamsterdam.\nAfter Glamsterdam activates, the first step is to observe how demand for state creation responds to EIP-8037 and compare state-gas and execution-gas utilization with their targets. That evidence determines whether Hegotá should modify CPSB or the state-gas mechanism at all. There are three possible scenarios:\n\nState and execution demand are mismatched: one resource’s utilization remains far from its target while the other resource constrains the block. This is an EIP-8037 failure mode. In this case, we should adopt EIP-8372, which performs a one-time recalibration of CPSB and scales the raw state-gas limit at the hard fork boundary, bringing state and execution capacity back into balance.\n\nDemand is balanced, but Hegotá raises the block gas limit: in this case, we should adopt EIP-8368 to re-derive CPSB for the higher limit and keep state growth on target without changing the mechanism.\n\nDemand is balanced and the block gas limit stays unchanged: in this case, we should make no Hegotá update and retain EIP-8037’s existing parameters.\n\nEIP-8368 and EIP-8372 should therefore remain alternative contingency paths until there is enough post-Glamsterdam utilization data. The decision should be evidence-gated and dependent on the final gas limit target for the fork.\nFrames need a bounded state footprint\nEIP-8141 introduces frame transactions as Hegotá’s native account abstraction design. Programmable validation must read only a bounded slice of state so that validity-checking nodes, including future inclusion-list builders, do not need to hold the whole state. This is why we should push back on ERC-20 fee sponsorship as a Frames feature: it would make validity depend on arbitrary token storage and defeat that constraint.\nTwo Frame extensions add new state types. EIP-8250 adds keyed nonces, and EIP-8272 adds a rolling window of recent application state roots. Both can begin as regular storage in a system contract and move into their own PBT zone later. This only works if demand stays bounded, especially for keyed nonces, where each new key adds a permanent slot. Privacy pool usage is the best current proxy, and nullifier growth looks feasible so far based on this Dune dashboard. We should keep watching it as adoption grows.\nResolve the legacy accounts\nEIP-8253 addresses a small set of legacy accounts left over from before Spurious Dragon: accounts with storage but no code and a zero nonce. Hegotá should remove this account shape before the PBT migration. EIP-8253 does so by setting the nonce of 28 accounts to 1, while an alternative would be to clear their 129 storage entries. The nonce bump is the smaller and simpler transition; clearing the storage removes more state. We should resolve the anomaly in Hegotá, choosing the exact mechanism after verifying the account list and comparing the transition complexity.\nAdd BAL as sidecars if fork timing allows\nEIP-7928’s Block Access List (BAL) contains every account, storage slot, and code or balance/nonce change a block touches. EIP-8146 moves BAL delivery out of the payload and sends it early on its own channel, giving clients more time to prefetch state and compute the state root.\nThis is a good improvement if it does not delay the fork. Before including it, we should benchmark the execution benefit of one additional second of prefetching and state-root calculation.\nState tiering can wait\nToday’s client databases weren’t built for multi-terabyte state. A possible fix is hot/cold separation: keep hot state in the live database and push cold state to flat files on cheaper media. Measurements show that about 94% of storage writes hit state from the last 30 days, and that the top 1% of accounts absorb 96–98% of reads (Hot-Cold Storage Separation in Practice, The Anatomy of Ethereum’s State Access). Cold state should target HDDs, since big, slow, cheap disks need a job.\nEIP-8188 records the last block that wrote to each account and storage slot, providing a clean signal for this split. We will likely want it eventually, but it puts write-recency into state while the current PBT leaf format does not represent it. Adding it before the migration would mean resolving that gap and carrying more data through the conversion, while its main operational benefit arrives only as state approaches the TB mark.\nWe should therefore revisit EIP-8188 after the trie migration and keep only low-priority exploration going for now. More work is also needed on serving cold state from HDDs without making access too expensive.\nSETCODEFROM over SETDELEGATE\nEIP-7819’s SETDELEGATE creates accounts that delegate to existing code. The factory can later change or clear that delegation. EIP-8298’s SETCODEFROM lets an account adopt code already deployed elsewhere. For EIP-7702 accounts, this permanently disables ECDSA transactions under EIP-3607, offering a path to post-quantum wallets.\nBoth reduce duplicate code: SETDELEGATE stores a short delegation indicator, while SETCODEFROM reuses the code without copying it. EIP-8037 charges for duplicate bytes even though PBT stores identical code only once. Roughly 62% of deployed contracts reportedly reuse existing bytecode, so deployment savings would remain after the migration.\nNeither is needed for Hegotá. If we include one, it should be EIP-8298 for its code reuse and ECDSA migration path. EIP-7819 makes clones cheaper and keeps them upgradeable, but its main benefit is lower application gas costs.\nSELFDESTRUCT and ephemeral storage\nEIP-4758 removes the only account-deletion case left by EIP-6780: an account created and self-destructed in the same transaction. Removing this case is neutral to PBT or its migration, since these accounts do not exist in the pre-state and do not survive into the post-state.\nThe plan to replace SELFDESTRUCT is EIP-8360’s TCREATE, a CREATE2 variant that deploys a contract whose code, nonce, and storage are all removed at the end of the transaction, leaving only its balance behind. Inside a TCREATEd contract, SLOAD/SSTORE are priced and behave like TLOAD/TSTORE.\nThere are some use-cases that would benefit from this ephemeral storage layer, however, current usage is limited. In a sample covering one month of blocks, we see an average of roughly 1,500 accounts per day created and self-destructed in the same transaction. There are two patterns of usage in this sample, namely, internal wallet maangement for centralised exchanges or NFT marketplaces and laundering from scams. At current usage, and counting only 120 bytes per account while ignoring storage, this deletion avoids roughly 62 MiB of state growth per year, which is fairly small. Thus, this is not a clear win and likely not a priority for now.\n\n read \n\n 4\n min\n\n 14 days later\n\n post by Helkomine on Sep 17\n\n Helkomine\n\n We should shift our perspective, as ephemeral contracts already constitute a distinct market segment given the projects committed to using them. Measuring past state is of little help, given the shift in design. The network’s slow adoption of a native solution risks causing block congestion due to frequent state occupancy in the future.\n\n Powered by Discourse","tokens":2403,"squid":"ink-research","role":"Deep Scholar","at":1791259498903,"hash":"3b199fa9b78b8ed1f636c162ffb205c2164737aa"}
{"url":"https://soliditylang.org/about","domain":"soliditylang.org","title":"About | Solidity Programming Language","text":"{About}Solidity is a statically-typed curly-braces programming language designed for developing smart contracts that run on the Ethereum Virtual Machine.Get startedContributeSolidity is a powerful programming language designed specifically for writing smart contracts on the Ethereum blockchain. With Solidity, developers can define the rules and behavior of decentralized applications (DApps).Smart contracts are programs that are executed inside a peer-to-peer network where nobody has special authority over the execution, and thus they allow to implement tokens of value, ownership, voting and other kinds of logics.Note that when deploying contracts, you should use the latest released version of Solidity. This is because breaking changes as well as new features and bug fixes are introduced regularly.Solidity was publicly previewed for the first time in November 2014 at Devcon0. Versioning for Solidity was committed. into the codebase on July 9, 2015, marking Solidity Version 0.0.1. However, v0.1.0 wasn't an actual release yet, and builds of it are not available anymore. You can read more about Solidity's history in the 5 year celebration post from 2020 here.The Solidity programming language is an open-source, community project governed by a core team. Originally started within the Ethereum Foundation, the project is now part of the Argot Collective.","tokens":342,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259501701,"hash":"a70197b9f385962263090e11cb9c6b7b77407e52"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/l2-pool","domain":"aave.com","title":"L2 Pool | Aave Protocol Documentation","text":"L2Pool#\nThe main transaction cost on L2 comes from calldata. To minimize this cost, Aave v3 uses a different contract on L2 networks that allows calldata of Pool methods to be compressed.\nL2Pool is the contract for the L2 optimized user facing methods of the protocol that takes byte encoded input arguments. It exposes the liquidity management methods that can be invoked using either Solidity or Web3 libraries. The L2Pool contract is a calldata optimized extension of the Pool contract allowing users to pass compact calldata representation to reduce transaction costs on L2 rollups.\nPool methods not exposed in L2Pool.sol (such as flashLoan, setUserEMode\netc.) are the same on L2 as on other versions of protocol. Refer to\nPool docs for the rest of the methods.\nSince there are a limited set of supported assets that are already given an\nindividual id, we use the 16 bit asset id in the encoded arguments instead of\n160 bit asset address.\nThe source code is available on GitHub.\nThrere is an additional L2Encoder helper contract with view methods to encode transaction params for compressed methods.\nMethods#\nsupply#\nfunction supply(bytes32 args) external override\nCalldata efficient wrapper of the supply function on behalf of the caller. Supplies asset into the protocol, minting the same amount of corresponding aTokens, and transferring them to msg.sender.\nYou can use data returned from encodeSupplyParams() method in\nL2Encoder\nhelper contract to pass to this method.\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the supply function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 144-159: uint16 referralCode - used for 3rd party integrations\nsupplyWithPermit#\nfunction supplyWithPermit(bytes32 args, bytes32 r, bytes32 s) external override\nCalldata efficient wrapper of the supplyWithPermit function on behalf of the caller. Supply with transfer approval of supplied asset via permit function. This method removes the need for separate approval transaction before supplying asset to the pool.\nYou can use data returned from encodeSupplyWithPermitParams() method in\nL2Encoder\nhelper contract to pass to this method.\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the supply function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 144-159: uint16 referralCode - used for 3rd party integrationsbit 160-191: uint32 shortenedDeadline - shortened deadline from the original uint256bit 192-199: uint8 permitV - the V parameter of ERC712 permit signaturerbytes32The R parameter of ERC712 permit signaturesbytes32The S parameter of ERC712 permit signature\nwithdraw#\nfunction withdraw(bytes32 args) external override returns (uint256)\nCalldata efficient wrapper of the withdraw function, withdrawing to the caller. Withdraws amount of the underlying asset, i.e. redeems the underlying token and burns the aTokens.\nIf the user has any existing debt backed by the underlying token, the maximum amount available to withdraw is the amount that will not leave the user with a health factor < 1 after the withdrawal.\nYou can use data returned from encodeWithdrawParams() method in\nL2Encoder\nhelper contract to pass to this method.\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the withdraw function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).max\nReturn Value:#\nNameTypeDescriptionamountuint256The final amount of the underlying asset withdrawn, denominated in the base unit of the asset (e.g., wei for ETH, smallest unit for ERC-20 tokens). This is the amount actually transferred to the caller, accounting for constraints like liquidity and health factor.\nborrow#\nfunction borrow(bytes32 args) external override\nCalldata efficient wrapper of the borrow function, borrowing on behalf of the caller. Borrows amount of asset with interestRateMode, sending the amount to msg.sender, with the debt being incurred by onBehalfOf.\nYou can use data returned from encodeBorrowParams() method in\nL2Encoder\nhelper contract to pass to this method.\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the borrow function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 144 - 151: uint8 shortenedInterestRateModebit 152 - 167: uint16 referralCode - used for 3rd party integrations\nrepay#\nfunction repay(bytes32 args) external override returns (uint256)\nCalldata efficient wrapper of the repay function, repaying on behalf of the caller. Repays debt of an asset for the given interestRateMode.\nYou can use data returned from encodeRepayParams() method in\nL2Encoder\nhelper contract to pass to this method.\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the repay function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 144 - 151: uint8 shortenedInterestRateMode\nReturn Values:#\nTypeDescriptionuint256The final amount repaid\nrepayWithPermit#\nfunction repayWithPermit(bytes32 args, bytes32 r, bytes32 s) external override returns (uint256)\nCalldata efficient wrapper of the repayWithPermit function, repaying on behalf of the caller. Repay with transfer approval of borrowed asset via permit function. This method removes the need for separate approval transaction before repaying asset to the pool.\nYou can use data returned from encodeRepayWithPermitParams() method in\nL2Encoder\nhelper contract to pass to this method.​\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the repayWithPermit function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 144 - 151: uint8 shortenedInterestRateModebit 152-183: uint32 shortenedDeadline - shortened deadline from original uint256bit 184-191: uint8 permitV - the V parameter of ERC712 permit signaturerbytes32The R parameter of ERC712 permit signaturesbytes32The S parameter of ERC712 permit signature\nReturn Values:#\nTypeDescriptionuint256The final amount repaid\nrepayWithATokens#\nfunction repayWithATokens(bytes32 args) external override returns (uint256)\nCalldata efficient wrapper of the repayWithATokens function. Allows user to repay with aTokens of the underlying debt asset without any approvals, for example, Pay DAI debt using aDAI tokens.\nYou can use data data returned from encodeRepayWithATokensParams() method in\nL2Encoder\nhelper contract to pass to this method.\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the repayWithATokens function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16-143: uint128 shortenedAmount - cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 144 - 151: uint8 shortenedInterestRateMode\nReturn Values:#\nTypeDescriptionuint256The final amount repaid\nsetUserUseReserveAsCollateral#\nfunction setUserUseReserveAsCollateral(bytes32 args) external override\nCalldata efficient wrapper of the setUserUseReserveAsCollateral function. Sets the asset of msg.sender to be used as collateral or not.\nYou can use data returned from encodeSetUserUseReserveAsCollateral() method\nin\nL2Encoder\nhelper contract to pass to this method.​\nInput Parameters:#\nNameTypeDescriptionargsbytes32Arguments for the setUserUseReserveAsCollateral function packed in one bytes32bit 0-15: uint16 assetId - the index of the asset in the reservesListbit 16: 0 => enable useAsCollateral, 1 => disable useAsCollateral\nliquidationCall#\nfunction liquidationCall(bytes32 args1, bytes32 args2) external override\nCalldata efficient wrapper of the liquidationCall function. Liquidate positions with a health factor below 1.\nYou can use data returned from encodeLiquidationCall() method in\nL2Encoder\nhelper contract to pass to this method.​\nInput Parameters:#\nNameTypeDescriptionargs1bytes32Part of the arguments for the liquidationCall function packed in one bytes32bit 0-15: uint16 collateralAssetId - the index of the collateral asset in the reservesListbit 16-31: uint16 debtAssetId - the index of the debt asset in the reservesListbit 32-191: address of the user being liquidatedargs2bytes32Part of the arguments for the liquidationCall function packed in one bytes32bit 0-127: uint128 shortenedDebtToCover is cast to 256 bits at decode time, if type(uint128).max the value will be expanded to type(uint256).maxbit 128: receiveAToken - 0 => receive aToken, 1 => receive underlying assetPreviousPoolNextWrapped Token Gateway","tokens":2340,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259507725,"hash":"6a38aac8ac6407b08096af5740e440047b64ccfe"}
{"url":"https://docs.soliditylang.org/?color=dark","domain":"docs.soliditylang.org","title":"Solidity — Solidity 0.8.37-develop documentation","text":"Solidity\n\n Edit on GitHub\n\nSolidity\nSolidity is an object-oriented, high-level language for implementing smart contracts.\nSmart contracts are programs that govern the behavior of accounts within the Ethereum state.\nSolidity is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM).\nIt is influenced by C++, Python, and JavaScript.\nYou can find more details about which languages Solidity has been inspired by in the language influences section.\nSolidity is statically typed, supports inheritance, libraries, and complex user-defined types, among other features.\nWith Solidity, you can create contracts for uses such as voting, crowdfunding, blind auctions, and multi-signature wallets.\nWhen deploying contracts, you should use the latest released version of Solidity.\nApart from exceptional cases, only the latest version receives\nsecurity fixes.\nFurthermore, breaking changes, as well as new features, are introduced regularly.\nWe currently use a 0.y.z version number to indicate this fast pace of change.\n\nWarning\nSolidity recently released the 0.8.x version that introduced a lot of breaking changes.\nMake sure you read the full list.\n\nIdeas for improving Solidity or this documentation are always welcome,\nread our contributors guide for more details.\n\nHint\nYou can download this documentation as PDF, HTML or Epub\nby clicking on the versions flyout menu in the bottom-right corner and selecting the preferred download format.\n\nGetting Started\n1. Understand the Smart Contract Basics\nIf you are new to the concept of smart contracts, we recommend you to get started by digging into the “Introduction to Smart Contracts” section, which covers the following:\n\nA simple example smart contract written in Solidity.\nBlockchain Basics.\nThe Ethereum Virtual Machine.\n\n2. Get to Know Solidity\nOnce you are accustomed to the basics, we recommend you read the “Solidity by Example”\nand “Language Description” sections to understand the core concepts of the language.\n3. Install the Solidity Compiler\nThere are various ways to install the Solidity compiler,\nsimply choose your preferred option and follow the steps outlined on the installation page.\n\nHint\nYou can try out code examples directly in your browser with the\nRemix IDE.\nRemix is a web browser-based IDE that allows you to write, deploy and administer Solidity smart contracts,\nwithout the need to install Solidity locally.\n\nWarning\nAs humans write software, it can have bugs.\nTherefore, you should follow established software development best practices when writing your smart contracts.\nThis includes code review, testing, audits, and correctness proofs.\nSmart contract users are sometimes more confident with code than their authors,\nand blockchains and smart contracts have their own unique issues to watch out for,\nso before working on production code, make sure you read the Security Considerations section.\n\n4. Learn More\nIf you want to learn more about building decentralized applications on Ethereum,\nthe Ethereum Developer Resources can help you with further general documentation around Ethereum,\nand a wide selection of tutorials, tools, and development frameworks.\nIf you have any questions, you can try searching for answers or asking on the\nEthereum StackExchange,\nor our Gitter channel.\n\nTranslations\nCommunity contributors help translate this documentation into several languages.\nNote that they have varying degrees of completeness and up-to-dateness.\nThe English version stands as a reference.\nYou can switch between languages by clicking on the flyout menu in the bottom-right corner\nand selecting the preferred language.\n\nChinese\nFrench\nIndonesian\nJapanese\nKorean\nPersian\nRussian\nSpanish\nTurkish\n\nNote\nWe set up a GitHub organization and translation workflow to help streamline the community efforts.\nPlease refer to the translation guide in the solidity-docs org\nfor information on how to start a new language or contribute to the community translations.\n\nContents\nKeyword Index, Search Page\n\nBasics\n\nIntroduction to Smart Contracts\nA Simple Smart Contract\nBlockchain Basics\nThe Ethereum Virtual Machine\n\nSolidity by Example\nVoting\nBlind Auction\nSafe Remote Purchase\nMicropayment Channel\nModular Contracts\n\nInstalling the Solidity Compiler\nVersioning\nRemix\nnpm / Node.js\nDocker\nLinux Packages\nmacOS Packages\nStatic Binaries\nBuilding from Source\nCMake Options\nThe Version String in Detail\nImportant Information About Versioning\n\nLanguage Description\n\nLayout of a Solidity Source File\nSPDX License Identifier\nPragmas\nImporting other Source Files\nComments\n\nStructure of a Contract\nState Variables\nFunctions\nFunction Modifiers\nEvents\nErrors\nStruct Types\nEnum Types\n\nTypes\nValue Types\nReference Types\nMapping Types\nOperators\nConversions between Elementary Types\nConversions between Literals and Elementary Types\n\nUnits and Globally Available Variables\nEther Units\nTime Units\nSpecial Variables and Functions\nReserved Keywords\n\nExpressions and Control Structures\nControl Structures\nFunction Calls\nCreating Contracts via new\nOrder of Evaluation of Expressions\nAssignment\nScoping and Declarations\nChecked or Unchecked Arithmetic\nError handling: Assert, Require, Revert and Exceptions\n\nContracts\nCreating Contracts\nVisibility and Getters\nFunction Modifiers\nTransient Storage\nComposability of Smart Contracts and the Caveats of Transient Storage\nConstant and Immutable State Variables\nCustom Storage Layout\nFunctions\nEvents\nCustom Errors\nInheritance\nAbstract Contracts\nInterfaces\nLibraries\nUsing For\n\nInline Assembly\nExample\nAccess to External Variables, Functions and Libraries\nThings to Avoid\nConventions in Solidity\nAdvanced Safe Use of Memory\n\nCheatsheet\nOrder of Precedence of Operators\nABI Encoding and Decoding Functions\nMembers of bytes and string\nMembers of address\nBlock and Transaction Properties\nValidations and Assertions\nMathematical and Cryptographic Functions\nContract-related\nType Information\nFunction Visibility Specifiers\nModifiers\n\nLanguage Grammar\nSolidityParser\nSolidityLexer\n\nCompiler\n\nUsing the Compiler\nUsing the Commandline Compiler\nSetting the EVM Version to Target\nCompiler Input and Output JSON Description\nExperimental Mode\n\nAnalysing the Compiler Output\nSolidity IR-based Codegen Changes\nSemantic Only Changes\nInternals\n\nInternals\n\nLayout of State Variables in Storage and Transient Storage\nMappings and Dynamic Arrays\nJSON Output\n\nLayout in Memory\nDifferences to Layout in Storage\n\nLayout of Call Data\nCleaning Up Variables\nSource Mappings\nThe Optimizer\nBenefits of Optimizing Solidity Code\nDifferences between Optimized and Non-Optimized Code\nOptimizer Parameter Runs\nOpcode-Based Optimizer Module\nYul-Based Optimizer Module\nCodegen-Based Optimizer Module\n\nContract Metadata\nEncoding of the Metadata Hash in the Bytecode\nUsage for Automatic Interface Generation and NatSpec\nUsage for Source Code Verification\n\nContract ABI Specification\nBasic Design\nFunction Selector\nArgument Encoding\nTypes\nDesign Criteria for the Encoding\nFormal Specification of the Encoding\nFunction Selector and Argument Encoding\nExamples\nUse of Dynamic Types\nEvents\nErrors\nJSON\nStrict Encoding Mode\nNon-standard Packed Mode\nEncoding of Indexed Event Parameters\n\nAdvisory content\n\nSecurity Considerations\nPitfalls\nRecommendations\n\nList of Known Bugs\nSolidity v0.5.0 Breaking Changes\nSemantic Only Changes\nSemantic and Syntactic Changes\nExplicitness Requirements\nDeprecated Elements\nInteroperability With Older Contracts\nExample\n\nSolidity v0.6.0 Breaking Changes\nChanges the Compiler Might not Warn About\nExplicitness Requirements\nSemantic and Syntactic Changes\nNew Features\nInterface Changes\nHow to update your code\n\nSolidity v0.7.0 Breaking Changes\nSilent Changes of the Semantics\nChanges to the Syntax\nRemoval of Unused or Unsafe Features\nInterface Changes\nHow to update your code\n\nSolidity v0.8.0 Breaking Changes\nSilent Changes of the Semantics\nNew Restrictions\nInterface Changes\nHow to update your code\n\nAdditional Material\n\nNatSpec Format\nDocumentation Example\nTags\nDocumentation Output\n\nSMTChecker and Formal Verification\nTutorial\nSMTChecker Options and Tuning\nAbstraction and False Positives\nReal World Assumptions\n\nYul\nMotivation and High-level Description\nSimple Example\nStand-Alone Usage\nInformal Description of Yul\nSpecification of Yul\nSpecification of Yul Object\nYul Optimizer\nComplete ERC20 Example\n\nImport Path Resolution\nVirtual Filesystem\nImports\nBase Path and Include Paths\nAllowed Paths\nImport Remapping\nUsing URLs in imports\n\nResources\n\nStyle Guide\nIntroduction\nCode Layout\nOrder of Layout\nNaming Conventions\nNatSpec\n\nCommon Patterns\nWithdrawal from Contracts\nRestricting Access\nState Machine\n\nResources\nGeneral Resources\nIntegrated (Ethereum) Development Environments\nEditor Integrations\nSolidity Tools\nThird-Party Solidity Parsers and Grammars\n\nContributing\nTeam Calls\nHow to Report Issues\nWorkflow for Pull Requests\nAI-Assisted Contributions\nRunning the Compiler Tests\nRunning the Fuzzer via AFL\nWhiskers\nDocumentation Style Guide\nSolidity Language Design\n\nLanguage Influences\nSolidity Brand Guide\nThe Solidity Brand\nSolidity Brand Name\nSolidity Logo License\nSolidity Logo Guidelines\nCredits","tokens":2278,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259521350,"hash":"1b3910316898b081dafe291e76d68463cc09b005"}
{"url":"https://docs.openzeppelin.com/tools/uikit/components","domain":"docs.openzeppelin.com","title":"Components | OpenZeppelin Docs","text":"UIKitComponentsOpen in ClaudeOpenZeppelin UIKit ships two categories of components: UI primitives from @openzeppelin/ui-components and renderer widgets from @openzeppelin/ui-renderer. This page catalogs both and shows how to use them.\nUI Primitives\n@openzeppelin/ui-components provides foundational React components built on Radix UI and shadcn/ui patterns. All components are styled with Tailwind CSS and support dark mode.\nGeneral Components\nComponentDescriptionButton / LoadingButtonAction buttons with multiple variants (default, destructive, outline, secondary, ghost, link)Input / TextareaText input primitivesLabelAccessible form labelsCardContainer with CardHeader, CardTitle, CardDescription, CardContent, CardFooterDialogModal dialogs with DialogTrigger, DialogContent, DialogHeader, DialogFooterAlertAlert messages with AlertTitle and AlertDescriptionCheckbox / RadioGroupSelection inputsSelectDropdown select with SelectTrigger, SelectContent, SelectItemDropdownMenuContext menu with DropdownMenuTrigger, DropdownMenuContent, DropdownMenuItemPopoverFloating content anchored to a trigger elementProgressProgress bar indicatorTabsTab navigation with TabsList, TabsTrigger, TabsContentTooltipHover tooltipsAccordionCollapsible content sectionsBannerFull-width notification bannersCalendar / DateRangePickerDate selection and date-range picker componentsEmptyStatePlaceholder UI for empty lists or initial statesExternalLinkAnchor that opens in a new tab with appropriate rel attributesFormForm wrapper integrating react-hook-form with accessible error messagesHeader / FooterPage-level header and footer layout componentsSonnerToast notification system (powered by sonner)SidebarSidebar navigation layoutWizardMulti-step wizard flow\nBlockchain-Specific Components\nComponentDescriptionNetworkSelectorSearchable network dropdown with optional multi-select modeNetworkIconNetwork-specific icon (renders the correct logo for a given network ID)NetworkStatusBadgeColored badge showing network status (e.g. connected, syncing)EcosystemDropdownEcosystem selection with chain iconsEcosystemIconChain-specific icons (Ethereum, Stellar, Polkadot, etc.)AddressDisplayFormatted address with optional alias labels and edit controlsViewContractStateButtonQuick-action button to open the contract state widgetOverflowMenuCompact \"...\" dropdown for secondary actions\nUsage\nimport { Button, Card, CardContent, CardHeader, CardTitle } from '@openzeppelin/ui-components';\n\nfunction ContractCard({ name, address }) {\n return (\n <Card>\n <CardHeader>\n <CardTitle>{name}</CardTitle>\n </CardHeader>\n <CardContent>\n <p className=\"text-sm text-muted-foreground\">{address}</p>\n <Button variant=\"outline\" className=\"mt-4\">\n View Contract\n </Button>\n </CardContent>\n </Card>\n );\n}\nForm Fields\nThe field components are designed for use with react-hook-form. Each field handles its own validation, formatting, and blockchain-specific behavior.\nFieldInput TypeUse CaseAddressFieldBlockchain addressContract addresses, recipient addresses; validates format per ecosystemAmountFieldToken amountsToken transfers; handles decimals and BigInt formattingBigIntFieldLarge integersRaw uint256 values, timestamps, token IDsBytesFieldHex byte stringsCalldata, hashes, signaturesTextFieldFree-form textString parameters, names, URIsUrlFieldURLEndpoint URLs, metadata URIs; validates URL formatPasswordFieldMasked textAPI keys, secrets; input is hidden by defaultNumberFieldNumeric valuesCounts, percentages, indicesBooleanFieldTrue/falseFeature flags, approvalsEnumFieldEnum selectionContract enum parametersSelectFieldDropdownPredefined option listsSelectGroupedFieldGrouped dropdownCategorized optionsRadioFieldRadio buttonsSmall option setsTextAreaFieldMulti-line textABI input, JSON dataCodeEditorFieldCode / JSON editorContract source code, ABI JSON, configuration filesDateTimeFieldDate and timeTimestamps, scheduling, time-locked parametersFileUploadFieldFile uploadImporting ABIs, uploading contract artifactsArrayFieldDynamic arraysArray parameters (e.g. address[], uint256[])ArrayObjectFieldArray of structsRepeated struct entries (e.g. batch transfers, multi-recipient calls)MapFieldKey-value pairsMapping-like structuresObjectFieldNested objectsStruct/tuple parameters\nField Example\nimport { useForm } from 'react-hook-form';\nimport { AddressField, AmountField, Button } from '@openzeppelin/ui-components';\n\nfunction TransferForm() {\n const { control, handleSubmit } = useForm({\n defaultValues: { to: '', amount: '' },\n });\n\n return (\n <form onSubmit={handleSubmit(onSubmit)} className=\"space-y-4\">\n <AddressField\n name=\"to\"\n label=\"Recipient\"\n control={control}\n placeholder=\"0x...\"\n />\n <AmountField\n name=\"amount\"\n label=\"Amount\"\n control={control}\n placeholder=\"0.0\"\n />\n <Button type=\"submit\">Transfer</Button>\n </form>\n );\n}\nAddress Label & Suggestion Contexts\nUIKit provides context-driven address resolution that works automatically with AddressField and AddressDisplay:\n\nAddressLabelProvider: When mounted, all AddressDisplay instances in the subtree auto-resolve human-readable labels (e.g. \"Treasury Multisig\" instead of 0x1234...abcd).\nAddressSuggestionProvider: When mounted, all AddressField instances show autocomplete suggestions as the user types.\nuseAddressLabel(address, networkId?): Hook to resolve a label from the nearest provider.\n\nRenderer Widgets\n@openzeppelin/ui-renderer provides high-level, ready-to-use widgets for common blockchain UI patterns. These compose the lower-level components with adapter capabilities.\n\nTransactionForm\nThe primary widget for rendering blockchain transaction forms. Accepts a declarative schema and an adapter capabilities bundle:\nimport { TransactionForm } from '@openzeppelin/ui-renderer';\nimport type { RenderFormSchema, TransactionFormCapabilities } from '@openzeppelin/ui-types';\n\nconst schema: RenderFormSchema = {\n id: 'approve-form',\n title: 'Approve Spending',\n fields: [\n { id: 'spender', name: 'spender', type: 'address', label: 'Spender' },\n { id: 'amount', name: 'amount', type: 'amount', label: 'Amount' },\n ],\n layout: { columns: 1, spacing: 'normal', labelPosition: 'top' },\n submitButton: { text: 'Approve', loadingText: 'Approving...' },\n};\n\nfunction ApprovePage({ adapter }: { adapter: TransactionFormCapabilities }) {\n return (\n <TransactionForm\n schema={schema}\n adapter={adapter}\n onTransactionSuccess={(result) => console.log('Approved:', result)}\n />\n );\n}\nKey props:\nPropTypeDescriptionschemaRenderFormSchemaForm layout, fields, and submit button configcontractSchemaContractSchemaABI / function metadata for the target contractadapterTransactionFormCapabilitiesCapability bundle from the active runtimeexecutionConfigExecutionConfigEOA vs. relayer configurationonTransactionSuccesscallbackFires after successful transactionisWalletConnectedbooleanWhether a wallet session is active\nDynamicFormField\nRenders individual form fields dynamically based on type configuration. Used internally by TransactionForm but available for custom form layouts:\nimport { DynamicFormField } from '@openzeppelin/ui-renderer';\n\n<DynamicFormField\n field={{ id: 'amount', name: 'amount', type: 'amount', label: 'Amount' }}\n control={control}\n/>\nContractStateWidget\nDisplays read-only contract state by querying view functions. The widget automatically discovers all view functions from the contract schema and renders their return types. Supports auto-refresh to keep values current.Each row shows the function name, return type, and live result. No wallet connection is required. Pass query and schema capabilities from the active runtime:import { ContractStateWidget } from '@openzeppelin/ui-renderer';\n\n<ContractStateWidget\n contractSchema={contractSchema}\n contractAddress=\"0x...\"\n query={runtime.query}\n schema={runtime.schema}\n isVisible={true}\n/>\nAddressBookWidget\nA full-featured address book UI for managing saved addresses and their human-readable aliases. Supports CRUD operations, search, and import/export.\n\nAddressBookWidget works with the @openzeppelin/ui-storage package, specifically the account alias plugin which persists address-to-name mappings in IndexedDB via Dexie.js. When mounted alongside AddressLabelProvider and AddressSuggestionProvider, saved aliases automatically appear in all AddressDisplay and AddressField components throughout the app.\nimport { AddressBookWidget } from '@openzeppelin/ui-renderer';\nimport { createDexieDatabase, ALIAS_SCHEMA, useAddressBookWidgetProps } from '@openzeppelin/ui-storage';\nimport Dexie from 'dexie';\n\nconst db = createDexieDatabase(new Dexie('my-app'), ALIAS_SCHEMA);\n\nfunction AddressBook({ addressing }) {\n const widgetProps = useAddressBookWidgetProps(db, { networkId: 'ethereum-mainnet' });\n return <AddressBookWidget {...widgetProps} addressing={addressing} />;\n}\nSee the Storage page for setup and plugin configuration.\nOther Renderer Components\nComponentDescriptionContractActionBarNetwork status display with contract state toggleExecutionConfigDisplayConfigure execution method (EOA / Relayer)NetworkSettingsDialogConfigure RPC endpoints and indexer URLsWalletConnectionWithSettingsWallet connection UI with integrated settingsAliasEditPopoverInline popover for editing address aliases\nNext Steps\n\nReact Integration: Connect components to wallet state and runtime capabilities\nTheming & Styling: Customize the visual appearance\nGetting Started: Step-by-step setup guide\nArchitecturePrevious PageReact IntegrationNext PageOn this pageUI PrimitivesGeneral ComponentsBlockchain-Specific ComponentsUsageForm FieldsField ExampleAddress Label & Suggestion ContextsRenderer WidgetsTransactionFormDynamicFormFieldContractStateWidgetAddressBookWidgetOther Renderer ComponentsNext Steps","tokens":2423,"squid":"ink-security_audits","role":"Sentinel","at":1791259528754,"hash":"d05e14d5fc5742950ab8e159ca5ab296637ff1e6"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/l1-ethereum-beacon-chain-rpc-providers","domain":"docs.arbitrum.io","title":"Ethereum beacon chain RPC providers | Arbitrum Docs","text":"✏️Request an updateFollowing Ethereum's Dencun upgrade in March 2024, child chains like Arbitrum will be able to rollup and post batches of transaction data on Ethereum in the form of a new transaction format called a Blob. This Blob data will be part of the beacon chain and is fully downloadable by all consensus nodes. This means that data stored in blobs are inaccessible by the EVM, unlike calldata.\nWhat does this mean for node operators?​\nTo run a node for an Arbitrum child chain (i.e., Arbitrum One, Arbitrum Nova, and L3 Arbitrum chains), your node will need access to blob data to sync up to the latest state of your Arbitrum child chain. Blob data on Ethereum is stored on the beacon chain and is inaccessible to the EVM, hence why dedicated RPC endpoints for the beacon chain will be required after the Dencun upgrade. You can find more details on node requirements in the Run a full node guide.\nFurthermore, new node operators joining a network or node operators who come online following an extended period of offline time will require access to historical blob data to sync up to the latest state of their Arbitrum chain. If you run your own beacon node, see Beacon nodes: historical blobs for the client flags needed to retain and serve historical blob data through the Fusaka upgrade.\nList of Ethereum beacon chain RPC providers​\nThe list curated here is not comprehensive and in no way does Offchain Labs endorse or benefit from your use of any of these providers.\nProviderMainnet Beacon chain APIs?Mainnet Historical blob data?Sepolia Beacon chain APIs?Ankr✅✅✅Chainbase✅Chainstack✅✅✅Conduit*✅✅BlastAPINirvana Labs✅✅NodeReal✅QuickNode✅✅✅dRPC✅✅✅\nPlease reach out to these teams individually if you need assistance with setting up your validator with any of the above providers.What does this mean for node operators?List of Ethereum beacon chain RPC providers","tokens":469,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259531623,"hash":"6c9dbca485194b777150a487384a7826082e13ba"}
{"url":"https://eips.ethereum.org/EIPS/eip-7569","domain":"eips.ethereum.org","title":"EIP-7569: Hardfork Meta - Dencun","text":"🎉 Final\n\n Meta\n\n EIP-7569: Hardfork Meta - Dencun\n\n EIPs included in the Deneb/Cancun Ethereum network upgrade.\n\n Authors\n Tim Beiko (@timbeiko)\n\n Created\n 2023-12-01\n\n Requires\n\n EIP-1153, \n\n EIP-4788, \n\n EIP-4844, \n\n EIP-5656, \n\n EIP-6780, \n\n EIP-7044, \n\n EIP-7045, \n\n EIP-7514, \n\n EIP-7516, \n\n EIP-7568\n\n Abstract\n\nThis Meta EIP lists the EIPs included in the Dencun network upgrade across both Ethereum’s execution and consensus layers. See EIP-7568 for the specifications of past upgrades.\n\n Specification\n\n Included EIPs\n\n EIP-1153: Transient storage opcodes\n EIP-4788: Beacon block root in the EVM\n EIP-4844: Shard Blob Transactions\n EIP-5656: MCOPY - Memory copying instruction\n EIP-6780: SELFDESTRUCT only in same transaction\n EIP-7044: Perpetually Valid Signed Voluntary Exits\n EIP-7045: Increase Max Attestation Inclusion Slot\n EIP-7514: Add Max Epoch Churn Limit\n EIP-7516: BLOBBASEFEE opcode\n\n Full Specifications\n\n Consensus Layer\n\nEIPs 4788, 4844, 7044, 7045 and 7514 require changes to Ethereum’s consensus layer. These are specified in the deneb folder of the ethereum/consensus-specs repository.\n\n Execution Layer\n\nEIPs 1153, 4788, 4844, 5656, 6780 and 7516 require changes to Ethereum’s execution layer. The EIPs fully specify the changes.\n\n Activation\n\n Network Name\n Activation Epoch\n Activation Timestamp\n\n Goerli\n 231680\n 1705473120\n\n Sepolia\n 132608\n 1706655072\n\n Holešky\n 29696\n 1707305664\n\n Mainnet\n 269568\n 1710338135\n\nNote: rows in the table above will be filled as activation times are decided by client teams.\n\n Rationale\n\nThis Meta EIP provides a global view of all changes included in the Dencun network upgrade, as well as links to full specification.\n\n Security Considerations\n\nNone.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Tim Beiko (@timbeiko), \"EIP-7569: Hardfork Meta - Dencun,\" Ethereum Improvement Proposals, no. 7569, December 2023. Available: https://eips.ethereum.org/EIPS/eip-7569.","tokens":497,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259542115,"hash":"c6175837d049447349c29ccae61e139b8f7509c0"}
{"url":"https://docs.openzeppelin.com/tools/uikit/getting-started","domain":"docs.openzeppelin.com","title":"Getting Started | OpenZeppelin Docs","text":"UIKitGetting StartedOpen in ClaudeThis guide walks you through installing OpenZeppelin UIKit, configuring styles, and rendering your first blockchain transaction form.\nLive example: See UIKit and ecosystem adapters working together in the browser at openzeppelin-ui.netlify.app.\nPrerequisites\n\nNode.js >= 20.19.0\nReact 19\nTailwind CSS 4\nA package manager: pnpm (recommended), npm, or yarn\n\nInstallation\nInstall only the packages your application needs. The packages are designed to be incrementally adopted.\nMinimal Setup (Types + Components)\nFor projects that only need the component library and type system:\npnpm add @openzeppelin/ui-types @openzeppelin/ui-utils @openzeppelin/ui-components @openzeppelin/ui-styles\nFull Setup (With Rendering + React Integration)\nFor applications that need transaction form rendering and wallet integration:\npnpm add @openzeppelin/ui-types @openzeppelin/ui-utils @openzeppelin/ui-styles \\\n @openzeppelin/ui-components @openzeppelin/ui-react @openzeppelin/ui-renderer\nOptional Packages\n# IndexedDB persistence (address book, settings, etc.)\npnpm add @openzeppelin/ui-storage\n\n# Dev CLI for Tailwind wiring and local development\npnpm add -D @openzeppelin/ui-dev-cli\nEcosystem Adapters\nYou also need at least one ecosystem adapter package for the blockchain(s) your app supports:\n# EVM (Ethereum, Polygon, Arbitrum, etc.)\npnpm add @openzeppelin/adapter-evm\n\n# Stellar / Soroban\npnpm add @openzeppelin/adapter-stellar\n\n# Polkadot (EVM-compatible path)\npnpm add @openzeppelin/adapter-polkadot\nStep 1: Configure Tailwind CSS\nUIKit uses Tailwind CSS 4 for styling. Components ship class names but not compiled CSS. Your application's Tailwind build must know where to find them.\nAutomated Setup (Recommended)\nThe dev CLI handles Tailwind configuration automatically:\npnpm add -D @openzeppelin/ui-dev-cli\npnpm exec oz-ui-dev tailwind doctor --project \"$PWD\"\npnpm exec oz-ui-dev tailwind fix --project \"$PWD\"\nThis generates an oz-tailwind.generated.css file with the correct @source directives for all installed OpenZeppelin packages.\nManual Setup\nIf you prefer manual configuration, your entry CSS must register the OpenZeppelin package sources:\n@layer base, components, utilities;\n\n@import 'tailwindcss' source(none);\n@source \"./\";\n@source \"../\";\n@source \"../node_modules/@openzeppelin/ui-components\";\n@source \"../node_modules/@openzeppelin/ui-react\";\n@source \"../node_modules/@openzeppelin/ui-renderer\";\n@source \"../node_modules/@openzeppelin/ui-styles\";\n@source \"../node_modules/@openzeppelin/ui-utils\";\n@import '@openzeppelin/ui-styles/global.css';\nA bare Tailwind import is not enough. Tailwind v4 must be told to scan the OpenZeppelin node_modules paths, or component classes will be missing from the final CSS.\nStep 2: Use Components\nUIKit components work with react-hook-form for form state management. Here is a simple form with an address field and a submit button:\nimport { useForm } from 'react-hook-form';\nimport { Button, TextField, AddressField } from '@openzeppelin/ui-components';\n\nfunction SimpleForm() {\n const { control, handleSubmit } = useForm();\n\n const onSubmit = (data) => {\n console.log('Form data:', data);\n };\n\n return (\n <form onSubmit={handleSubmit(onSubmit)} className=\"space-y-4\">\n <AddressField\n name=\"recipient\"\n label=\"Recipient Address\"\n control={control}\n placeholder=\"0x...\"\n />\n <TextField\n name=\"memo\"\n label=\"Memo\"\n control={control}\n placeholder=\"Optional note\"\n />\n <Button type=\"submit\">Send</Button>\n </form>\n );\n}\nStep 3: Render a Transaction Form\nThe renderer package provides a declarative way to build transaction forms from a schema. The form fields, layout, and submission are all driven by data.\nimport { TransactionForm } from '@openzeppelin/ui-renderer';\nimport type { RenderFormSchema } from '@openzeppelin/ui-types';\n\nconst schema: RenderFormSchema = {\n id: 'transfer-form',\n title: 'Transfer Tokens',\n fields: [\n { id: 'to', name: 'to', type: 'address', label: 'Recipient' },\n { id: 'amount', name: 'amount', type: 'amount', label: 'Amount' },\n ],\n layout: { columns: 1, spacing: 'normal', labelPosition: 'top' },\n submitButton: { text: 'Transfer', loadingText: 'Transferring...' },\n};\n\nfunction TransferPage({ adapter, contractSchema }) {\n return (\n <TransactionForm\n schema={schema}\n contractSchema={contractSchema}\n adapter={adapter}\n onTransactionSuccess={(result) => {\n console.log('Transaction successful:', result);\n }}\n />\n );\n}\nThe adapter prop accepts a TransactionFormCapabilities object: a bundle of capabilities from your active Ecosystem Runtime.\nStep 4: Wire Up React Providers\nFor wallet integration and multi-network support, wrap your app with RuntimeProvider and WalletStateProvider:\nimport { RuntimeProvider, WalletStateProvider } from '@openzeppelin/ui-react';\nimport { ecosystemDefinition } from '@openzeppelin/adapter-evm';\n\nasync function resolveRuntime(networkConfig) {\n return ecosystemDefinition.createRuntime('composer', networkConfig);\n}\n\nfunction App() {\n return (\n <RuntimeProvider resolveRuntime={resolveRuntime}>\n <WalletStateProvider\n initialNetworkId=\"ethereum-mainnet\"\n getNetworkConfigById={getNetworkById}\n >\n <YourApp />\n </WalletStateProvider>\n </RuntimeProvider>\n );\n}\nThen access wallet state and runtime capabilities from any component:\nimport { useWalletState } from '@openzeppelin/ui-react';\n\nfunction WalletInfo() {\n const { activeNetworkConfig, activeRuntime, isRuntimeLoading } = useWalletState();\n\n if (isRuntimeLoading || !activeRuntime) {\n return <p>Loading...</p>;\n }\n\n return <p>Connected to {activeNetworkConfig?.name}</p>;\n}\nFor the full React integration guide, see React Integration.\nNext Steps\n\nArchitecture: Understand the package layers, capability tiers, and runtime model\nComponents: Explore UI primitives and blockchain-aware form fields\nReact Integration: Deep dive into providers, hooks, and wallet state\nTheming & Styling: Customize tokens, colors, and dark mode\nBuilding an adapter: Background on adapter packages and ecosystem integrations\nOverviewPrevious PageArchitectureNext PageOn this pagePrerequisitesInstallationMinimal Setup (Types + Components)Full Setup (With Rendering + React Integration)Optional PackagesEcosystem AdaptersStep 1: Configure Tailwind CSSAutomated Setup (Recommended)Manual SetupStep 2: Use ComponentsStep 3: Render a Transaction FormStep 4: Wire Up React ProvidersNext Steps","tokens":1589,"squid":"ink-security_audits","role":"Sentinel","at":1791259549004,"hash":"ae4934a3e1d6d5f99ce4658a4a68d9bfd78c1627"}
{"url":"https://eips.ethereum.org/EIPS/eip-7516","domain":"eips.ethereum.org","title":"EIP-7516: BLOBBASEFEE instruction","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-7516: BLOBBASEFEE instruction\n\n Instruction that returns the current data-blob base-fee\n\n Authors\n Carl Beekhuizen (@carlbeek)\n\n Created\n 2023-09-11\n\n Requires\n\n EIP-3198, \n\n EIP-4844\n\n Abstract\n\nAdd a BLOBBASEFEE (0x4a) instruction that returns the value of the blob base-fee of the current block it is executing in. It is the identical to EIP-3198 (BASEFEE opcode) except that it returns the blob base-fee as per EIP-4844.\n\n Motivation\n\nThe intended use case would be for contracts to get the value of the blob base-fee. This feature enables blob-data users to programmatically account for the blob gas price, eg:\n\n Allow rollup contracts to trustlessly account for blob data usage costs.\n Blob gas futures can be implemented based on it which allows for blob users to smooth out data blob costs.\n\n Specification\n\nAdd a BLOBBASEFEE instruction with opcode 0x4a, with gas cost 2.\n\n Op\n Input\n Output\n Cost\n\n 0x4a\n 0\n 1\n 2\n\nBLOBBASEFEE returns the result of the get_blob_gasprice(header) -> int function as defined in EIP-4844 §Gas accounting.\n\n Rationale\n\n Gas cost\n\nThe value of the blob base-fee is needed to process data-blob transactions. That means its value is already available before running the EVM code.\nThe instruction does not add extra complexity and additional read/write operations, hence the choice of 2 gas cost. This is also identical to EIP-3198 (BASEFEE opcode)’s cost as it just makes available data that is in the header.\n\n Backwards Compatibility\n\nThere are no known backward compatibility issues with this instruction.\n\n Test Cases\n\n Nominal Case\n\nAssume calling get_blob_gasprice(header) (as defined in EIP-4844 §Gas accounting) on the current block’s header returns 7 wei:\nBLOBBASEFEE should push the value 7 (left padded byte32) to the stack.\n\nBytecode: 0x4a00 (BLOBBASEFEE, STOP)\n\n Pc\n Op\n Cost\n Stack\n RStack\n\n 0\n BLOBBASEFEE\n 2\n []\n []\n\n 1\n STOP\n 0\n [7]\n []\n\nOutput: 0x\nConsumed gas: 2\n\n Comprehensive Test Suite\n\nA complete suite of tests can be found here.\n\n Security Considerations\n\nThe value of the blob base-fee is not sensitive and is publicly accessible in the block header. There are no known security implications with this instruction.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Carl Beekhuizen (@carlbeek), \"EIP-7516: BLOBBASEFEE instruction,\" Ethereum Improvement Proposals, no. 7516, September 2023. Available: https://eips.ethereum.org/EIPS/eip-7516.","tokens":623,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259551915,"hash":"9fbb18283a2bc66d7a61888d724e52ac0a0e74d7"}
{"url":"https://docs.pyth.network/entropy/transform-entropy-results","domain":"docs.pyth.network","title":"Transform Entropy Results | Pyth Developer Hub","text":"Transform Entropy ResultsBest practices for transforming entropy results in your applicationsGenerating random values within a specific range\nYou can map the random number provided by Entropy into a smaller range using the solidity modulo operator.\nHere is a simple example of how to map a random number provided by Entropy into a range between minRange and maxRange (inclusive).\n// Maps a random number into a range between minRange and maxRange (inclusive)\nfunction mapRandomNumber(\n bytes32 randomNumber,\n int256 minRange,\n int256 maxRange\n) internal pure returns (int256) {\n require(minRange <= maxRange, \"Invalid range\");\n\n uint256 range = uint256(maxRange - minRange + 1);\n uint256 randomUint = uint256(randomNumber);\n\n return minRange + int256(randomUint % range);\n\n}\nNotice that using the modulo operator can distort the distribution of random numbers if it's not a power of 2. This is\nnegligible for small and medium ranges, but it can be noticeable for large ranges.\nFor example, if you want to generate a random number between 1 and 52, the probability of having value 5 is approximately\n10^-77 higher than the probability of having value 50 which is infinitesimal.\nGenerating multiple random values in a single transaction\nIf you need to generate multiple random values in a single transaction, you can hash the random input provided by Entropy with a unique identifier for each random number.\nIn the following example, mapRandomNumber is used to generate 6 random attributes for a character.\nfunction generateAttributes(bytes32 randomNumber) internal {\n int256 strength = mapRandomNumber(\n keccak256(abi.encodePacked(randomNumber, \"strength\")),\n 15,\n 20\n );\n int256 stamina = mapRandomNumber(\n keccak256(abi.encodePacked(randomNumber, \"stamina\")),\n 10,\n 15\n );\n int256 agility = mapRandomNumber(\n keccak256(abi.encodePacked(randomNumber, \"agility\")),\n 5,\n 15\n );\n int256 stealth = mapRandomNumber(\n keccak256(abi.encodePacked(randomNumber, \"stealth\")),\n 0,\n 5\n );\n int256 positionX = mapRandomNumber(\n keccak256(abi.encodePacked(randomNumber, \"positionX\")),\n -100,\n 100\n );\n int256 positionY = mapRandomNumber(\n keccak256(abi.encodePacked(randomNumber, \"positionY\")),\n -100,\n 100\n );\n}Debug Callback FailuresHow to identify and resolve issues with Entropy callbacksChainlist and Fee DetailsPyth Entropy contract addresses on EVM networks","tokens":588,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259555225,"hash":"ae03e8cedcb7e3b48ea8e769ec84686894d8929a"}
{"url":"https://docs.openzeppelin.com/tools/uikit/react-integration","domain":"docs.openzeppelin.com","title":"React Integration | OpenZeppelin Docs","text":"UIKitReact IntegrationOpen in ClaudeThe @openzeppelin/ui-react package provides the runtime and wallet infrastructure that connects UIKit components to blockchain ecosystems. This page covers providers, hooks, wallet state management, and multi-ecosystem support.\nLive example: See these providers and hooks in a running app at openzeppelin-ui.netlify.app.\nProvider Setup\nTwo providers form the foundation of a UIKit-powered React app:\n\nRuntimeProvider\nRuntimeProvider maintains a registry of EcosystemRuntime instances (one per network ID). It creates runtimes on demand, caches them, and disposes all of them on unmount.\nimport { RuntimeProvider } from '@openzeppelin/ui-react';\nimport { ecosystemDefinition } from '@openzeppelin/adapter-evm';\n\nasync function resolveRuntime(networkConfig) {\n return ecosystemDefinition.createRuntime('composer', networkConfig);\n}\n\nfunction App() {\n return (\n <RuntimeProvider resolveRuntime={resolveRuntime}>\n {/* children */}\n </RuntimeProvider>\n );\n}\nProps:\nPropTypeDescriptionresolveRuntime(networkConfig) => Promise<EcosystemRuntime>Factory function that creates a runtime for a given network\nWalletStateProvider\nWalletStateProvider builds on RuntimeProvider to manage:\n\nThe active network ID and config\nThe active runtime and its loading state\nWallet facade hooks from the active runtime's UiKitCapability\nThe ecosystem's React UI provider component (e.g. wagmi's WagmiProvider)\n\nimport { RuntimeProvider, WalletStateProvider } from '@openzeppelin/ui-react';\n\nfunction App() {\n return (\n <RuntimeProvider resolveRuntime={resolveRuntime}>\n <WalletStateProvider\n initialNetworkId=\"ethereum-mainnet\"\n getNetworkConfigById={getNetworkById}\n >\n <YourApp />\n </WalletStateProvider>\n </RuntimeProvider>\n );\n}\nProps:\nPropTypeDescriptioninitialNetworkIdstringNetwork to activate on mountgetNetworkConfigById(id: string) => NetworkConfigResolver for network configurationsloadConfigModule(runtime) => Promise<void>Optional: load UI kit config modules for the runtime\nHooks\nuseWalletState\nThe primary hook for accessing global wallet and runtime state:\nimport { useWalletState } from '@openzeppelin/ui-react';\n\nfunction Dashboard() {\n const {\n activeNetworkId, // Current network ID string\n activeNetworkConfig, // Full NetworkConfig object\n activeRuntime, // EcosystemRuntime instance (or null)\n isRuntimeLoading, // True while runtime is being created\n walletFacadeHooks, // Ecosystem-specific React hooks\n setActiveNetworkId, // Switch networks\n reconfigureActiveUiKit // Re-initialize UI kit config\n } = useWalletState();\n\n if (isRuntimeLoading || !activeRuntime) {\n return <p>Loading runtime...</p>;\n }\n\n return (\n <div>\n <p>Network: {activeNetworkConfig?.name}</p>\n <p>Ecosystem: {activeRuntime.ecosystem}</p>\n </div>\n );\n}\nuseRuntimeContext\nLow-level hook for direct access to the runtime registry:\nimport { useRuntimeContext } from '@openzeppelin/ui-react';\n\nfunction AdvancedComponent() {\n const { getRuntimeForNetwork } = useRuntimeContext();\n\n const handleQuery = async () => {\n const { runtime, isLoading } = getRuntimeForNetwork(polygonConfig);\n if (isLoading || !runtime) return;\n const result = await runtime.query.queryViewFunction(/* ... */);\n };\n}\nDerived Wallet Hooks\nThese hooks abstract wallet interactions across ecosystems, providing a consistent API regardless of whether the user is connected to EVM, Stellar, or any other chain:\nHookReturnsuseDerivedAccountStatus(){ isConnected, address, chainId }useDerivedConnectStatus(){ connect, isPending, error }useDerivedDisconnect(){ disconnect }useDerivedSwitchChainStatus(){ switchChain, isPending }useDerivedChainInfo(){ chainId, chains }useWalletReconnectionHandler()Manages automatic wallet reconnection\nThese are built on top of the walletFacadeHooks from the active runtime's UiKitCapability, which wraps the ecosystem's native wallet library (e.g. wagmi for EVM, Stellar Wallets Kit for Stellar).\nWallet Components\n@openzeppelin/ui-react ships ready-to-use wallet UI components:\nComponentDescriptionWalletConnectionHeaderCompact header bar with wallet status and connect/disconnectWalletConnectionUIFull wallet connection interfaceWalletConnectionWithSettingsWallet connection with integrated network/RPC settingsNetworkSwitchManagerHandles programmatic network switching with user confirmation\nNetworkSwitchManager\nPass capabilities from the active runtime, not a monolithic adapter instance:\nimport { useState } from 'react';\nimport { NetworkSwitchManager, useWalletState } from '@openzeppelin/ui-react';\n\nfunction MyApp() {\n const [targetNetwork, setTargetNetwork] = useState(null);\n const { activeRuntime } = useWalletState();\n\n const wallet = activeRuntime?.wallet;\n const networkCatalog = activeRuntime?.networkCatalog;\n\n return (\n <>\n {wallet && networkCatalog && targetNetwork && (\n <NetworkSwitchManager\n wallet={wallet}\n networkCatalog={networkCatalog}\n targetNetworkId={targetNetwork}\n onNetworkSwitchComplete={() => setTargetNetwork(null)}\n />\n )}\n </>\n );\n}\nEcosystem Wallet Components\nEach adapter can provide its own wallet components via the UiKitCapability. These are accessed through the runtime:\nconst walletComponents = runtime.uiKit?.getEcosystemWalletComponents();\n// { ConnectButton, AccountDisplay, NetworkSwitcher }\nFor EVM, this integrates with RainbowKit. For Stellar, it integrates with Stellar Wallets Kit. Each adapter maps its ecosystem's wallet library into the standardized component interface.\nMulti-Ecosystem Apps\nA single app can support multiple blockchain ecosystems. The key is the resolveRuntime function, which determines which adapter to use based on the network config:\nimport { ecosystemDefinition as evmDef } from '@openzeppelin/adapter-evm';\nimport { ecosystemDefinition as stellarDef } from '@openzeppelin/adapter-stellar';\n\nasync function resolveRuntime(networkConfig) {\n switch (networkConfig.ecosystem) {\n case 'evm':\n return evmDef.createRuntime('composer', networkConfig);\n case 'stellar':\n return stellarDef.createRuntime('composer', networkConfig);\n default:\n throw new Error(`Unsupported ecosystem: ${networkConfig.ecosystem}`);\n }\n}\n\nfunction App() {\n return (\n <RuntimeProvider resolveRuntime={resolveRuntime}>\n <WalletStateProvider\n initialNetworkId=\"ethereum-mainnet\"\n getNetworkConfigById={getNetworkById}\n >\n <MultiChainApp />\n </WalletStateProvider>\n </RuntimeProvider>\n );\n}\nWhen the user switches networks, WalletStateProvider automatically resolves the correct runtime and updates the wallet facade hooks, UI provider, and wallet components for the new ecosystem.\n\nNext Steps\n\nComponents: Browse all available components and form fields\nTheming & Styling: Customize the visual design\nBuilding an adapter: Background on adapter packages and ecosystem integrations\nComponentsPrevious PageTheming & StylingNext PageOn this pageProvider SetupRuntimeProviderWalletStateProviderHooksuseWalletStateuseRuntimeContextDerived Wallet HooksWallet ComponentsNetworkSwitchManagerEcosystem Wallet ComponentsMulti-Ecosystem AppsNext Steps","tokens":1748,"squid":"ink-security_audits","role":"Sentinel","at":1791259559150,"hash":"909341182386b6c144d7172ce34075cb8a47553b"}
{"url":"https://eips.ethereum.org/EIPS/eip-4844","domain":"eips.ethereum.org","title":"EIP-4844: Shard Blob Transactions","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-4844: Shard Blob Transactions\n\n Shard Blob Transactions scale data-availability of Ethereum in a simple, forwards-compatible manner.\n\n Authors\n Vitalik Buterin (@vbuterin), Dankrad Feist (@dankrad), Diederik Loerakker (@protolambda), George Kadianakis (@asn-d6), Matt Garnett (@lightclient), Mofi Taiwo (@Inphi), Ansgar Dietrichs (@adietrichs)\n\n Created\n 2022-02-25\n\n Requires\n\n EIP-1559, \n\n EIP-2718, \n\n EIP-2930, \n\n EIP-4895\n\n Abstract\n\nIntroduce a new transaction format for “blob-carrying transactions” which contain a large amount of data that cannot be\naccessed by EVM execution, but whose commitment can be accessed.\nThe format is intended to be fully compatible with the format that will be used in full sharding.\n\n Motivation\n\nRollups are in the short and medium term, and possibly in the long term, the only trustless scaling solution for Ethereum.\nTransaction fees on L1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups.\nRollups are significantly reducing fees for many Ethereum users: Optimism and Arbitrum frequently provide fees that are ~3-8x lower than the Ethereum base layer itself,\nand ZK rollups, which have better data compression and can avoid including signatures, have fees ~40-100x lower than the base layer.\n\nHowever, even these fees are too expensive for many users. The long-term solution to the long-term inadequacy of rollups\nby themselves has always been data sharding, which would add ~16 MB per block of dedicated data space to the chain that rollups could use.\nHowever, data sharding will still take a considerable amount of time to finish implementing and deploying.\n\nThis EIP provides a stop-gap solution until that point by implementing the transaction format that would be used in sharding,\nbut not actually sharding those transactions. Instead, the data from this transaction format is simply part of the beacon chain and is fully downloaded\nby all consensus nodes (but can be deleted after only a relatively short delay).\nCompared to full data sharding, this EIP has a reduced cap on the number of these transactions that can be included, corresponding to a target of ~0.375 MB per block and a limit of ~0.75 MB.\n\n Specification\n\n Parameters\n\n Constant\n Value\n\n BLOB_TX_TYPE\n Bytes1(0x03)\n\n BYTES_PER_FIELD_ELEMENT\n 32\n\n FIELD_ELEMENTS_PER_BLOB\n 4096\n\n BLS_MODULUS\n 52435875175126190479447740508185965837690552500527637822603658699938581184513\n\n VERSIONED_HASH_VERSION_KZG\n Bytes1(0x01)\n\n POINT_EVALUATION_PRECOMPILE_ADDRESS\n Bytes20(0x0A)\n\n POINT_EVALUATION_PRECOMPILE_GAS\n 50000\n\n MAX_BLOB_GAS_PER_BLOCK\n 786432\n\n TARGET_BLOB_GAS_PER_BLOCK\n 393216\n\n MIN_BASE_FEE_PER_BLOB_GAS\n 1\n\n BLOB_BASE_FEE_UPDATE_FRACTION\n 3338477\n\n GAS_PER_BLOB\n 2**17\n\n HASH_OPCODE_BYTE\n Bytes1(0x49)\n\n HASH_OPCODE_GAS\n 3\n\n MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS\n 4096\n\n Type aliases\n\n Type\n Base type\n Additional checks\n\n Blob\n ByteVector[BYTES_PER_FIELD_ELEMENT * FIELD_ELEMENTS_PER_BLOB]\n\n VersionedHash\n Bytes32\n\n KZGCommitment\n Bytes48\n Perform IETF BLS signature “KeyValidate” check but do allow the identity point\n\n KZGProof\n Bytes48\n Same as for KZGCommitment\n\n Cryptographic Helpers\n\nThroughout this proposal we use cryptographic methods and classes defined in the corresponding consensus 4844 specs.\n\nSpecifically, we use the following methods from polynomial-commitments.md:\n\n verify_kzg_proof()\n verify_blob_kzg_proof_batch()\n\n Helpers\n\ndef kzg_to_versioned_hash(commitment: KZGCommitment) -> VersionedHash:\n return VERSIONED_HASH_VERSION_KZG + sha256(commitment)[1:]\n\nApproximates factor * e ** (numerator / denominator) using Taylor expansion:\n\ndef fake_exponential(factor: int, numerator: int, denominator: int) -> int:\n i = 1\n output = 0\n numerator_accum = factor * denominator\n while numerator_accum > 0:\n output += numerator_accum\n numerator_accum = (numerator_accum * numerator) // (denominator * i)\n i += 1\n return output // denominator\n\n Blob transaction\n\nWe introduce a new type of EIP-2718 transaction, “blob transaction”, where the TransactionType is BLOB_TX_TYPE and the TransactionPayload is the RLP serialization of the following TransactionPayloadBody:\n\n[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes, y_parity, r, s]\n\nThe fields chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, value, data, and access_list follow the same semantics as EIP-1559.\n\nThe field to deviates slightly from the semantics with the exception that it MUST NOT be nil and therefore must always represent a 20-byte address. This means that blob transactions cannot have the form of a create transaction.\n\nThe field max_fee_per_blob_gas is a uint256 and the field blob_versioned_hashes represents a list of hash outputs from kzg_to_versioned_hash.\n\nThe EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]).\n\n Signature\n\nThe signature values y_parity, r, and s are calculated by constructing a secp256k1 signature over the following digest:\n\nkeccak256(BLOB_TX_TYPE || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, to, value, data, access_list, max_fee_per_blob_gas, blob_versioned_hashes])).\n\n Header extension\n\nThe current header encoding is extended with two new 64-bit unsigned integer fields:\n\n blob_gas_used is the total amount of blob gas consumed by the transactions within the block.\n excess_blob_gas is a running total of blob gas consumed in excess of the target, prior to the block. Blocks with above-target blob gas consumption increase this value, blocks with below-target blob gas consumption decrease it (bounded at 0).\n\nThe resulting RLP encoding of the header is therefore:\n\nrlp([\n parent_hash,\n 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347, # ommers hash\n coinbase,\n state_root,\n txs_root,\n receipts_root,\n logs_bloom,\n 0, # difficulty\n number,\n gas_limit,\n gas_used,\n timestamp,\n extradata,\n prev_randao,\n 0x0000000000000000, # nonce\n base_fee_per_gas,\n withdrawals_root,\n blob_gas_used,\n excess_blob_gas,\n])\n\nThe value of excess_blob_gas can be calculated using the parent header.\n\ndef calc_excess_blob_gas(parent: Header) -> int:\n if parent.excess_blob_gas + parent.blob_gas_used < TARGET_BLOB_GAS_PER_BLOCK:\n return 0\n else:\n return parent.excess_blob_gas + parent.blob_gas_used - TARGET_BLOB_GAS_PER_BLOCK\n\nFor the first post-fork block, both parent.blob_gas_used and parent.excess_blob_gas are evaluated as 0.\n\n Gas accounting\n\nWe introduce blob gas as a new type of gas. It is independent of normal gas and follows its own targeting rule, similar to EIP-1559.\nWe use the excess_blob_gas header field to store persistent data needed to compute the blob gas base fee. For now, only blobs are priced in blob gas.\n\ndef calc_blob_fee(header: Header, tx: Transaction) -> int:\n return get_total_blob_gas(tx) * get_base_fee_per_blob_gas(header)\n\ndef get_total_blob_gas(tx: Transaction) -> int:\n return GAS_PER_BLOB * len(tx.blob_versioned_hashes)\n\ndef get_base_fee_per_blob_gas(header: Header) -> int:\n return fake_exponential(\n MIN_BASE_FEE_PER_BLOB_GAS,\n header.excess_blob_gas,\n BLOB_BASE_FEE_UPDATE_FRACTION\n )\n\nThe block validity conditions are modified to include blob gas checks (see the Execution layer validation section below).\n\nThe actual blob_fee as calculated via calc_blob_fee is deducted from the sender balance before transaction execution and burned, and is not refunded in case of transaction failure.\n\n Opcode to get versioned hashes\n\nWe add an instruction BLOBHASH (with opcode HASH_OPCODE_BYTE) which reads index from the top of the stack\nas big-endian uint256, and replaces it on the stack with tx.blob_versioned_hashes[index]\nif index < len(tx.blob_versioned_hashes), and otherwise with a zeroed bytes32 value.\nThe opcode has a gas cost of HASH_OPCODE_GAS.\n\n Point evaluation precompile\n\nAdd a precompile at POINT_EVALUATION_PRECOMPILE_ADDRESS that verifies a KZG proof which claims that a blob\n(represented by a commitment) evaluates to a given value at a given point.\n\nThe precompile costs POINT_EVALUATION_PRECOMPILE_GAS and executes the following logic:\n\ndef point_evaluation_precompile(input: Bytes) -> Bytes:\n \"\"\"\n Verify p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof.\n Also verify that the provided commitment matches the provided versioned_hash.\n \"\"\"\n # The data is encoded as follows: versioned_hash | z | y | commitment | proof | with z and y being padded 32 byte big endian values\n assert len(input) == 192\n versioned_hash = input[:32]\n z = input[32:64]\n y = input[64:96]\n commitment = input[96:144]\n proof = input[144:192]\n\n # Verify commitment matches versioned_hash\n assert kzg_to_versioned_hash(commitment) == versioned_hash\n\n # Verify KZG proof with z and y in big endian format\n assert verify_kzg_proof(commitment, z, y, proof)\n\n # Return FIELD_ELEMENTS_PER_BLOB and BLS_MODULUS as padded 32 byte big endian values\n return Bytes(U256(FIELD_ELEMENTS_PER_BLOB).to_be_bytes32() + U256(BLS_MODULUS).to_be_bytes32())\n\nThe precompile MUST reject non-canonical field elements (i.e. provided field elements MUST be strictly less than BLS_MODULUS).\n\n Consensus layer validation\n\nOn the consensus layer the blobs are referenced, but not fully encoded, in the beacon block body.\nInstead of embedding the full contents in the body, the blobs are propagated separately, as “sidecars”.\n\nThis “sidecar” design provides forward compatibility for further data increases by black-boxing is_data_available():\nwith full sharding is_data_available() can be replaced by data-availability-sampling (DAS) thus avoiding all blobs being downloaded by all beacon nodes on the network.\n\nNote that the consensus layer is tasked with persisting the blobs for data availability, the execution layer is not.\n\nThe ethereum/consensus-specs repository defines the following consensus layer changes involved in this EIP:\n\n Beacon chain: process updated beacon blocks and ensure blobs are available.\n P2P network: gossip and sync updated beacon block types and new blob sidecars.\n Honest validator: produce beacon blocks with blobs; sign and publish the associated blob sidecars.\n\n Execution layer validation\n\nOn the execution layer, the block validity conditions are extended as follows:\n\ndef validate_block(block: Block) -> None:\n ...\n\n # check that the excess blob gas was updated correctly\n assert block.header.excess_blob_gas == calc_excess_blob_gas(block.parent.header)\n\n blob_gas_used = 0\n\n for tx in block.transactions:\n ...\n\n # modify the check for sufficient balance\n max_total_fee = tx.gas * tx.max_fee_per_gas\n if get_tx_type(tx) == BLOB_TX_TYPE:\n max_total_fee += get_total_blob_gas(tx) * tx.max_fee_per_blob_gas\n assert signer(tx).balance >= max_total_fee\n\n ...\n\n # add validity logic specific to blob txs\n if get_tx_type(tx) == BLOB_TX_TYPE:\n # there must be at least one blob\n assert len(tx.blob_versioned_hashes) > 0\n\n # all versioned blob hashes must start with VERSIONED_HASH_VERSION_KZG\n for h in tx.blob_versioned_hashes:\n assert h[0] == VERSIONED_HASH_VERSION_KZG\n\n # ensure that the user was willing to at least pay the current blob base fee\n assert tx.max_fee_per_blob_gas >= get_base_fee_per_blob_gas(block.header)\n\n # keep track of total blob gas spent in the block\n blob_gas_used += get_total_blob_gas(tx)\n\n # ensure the total blob gas spent is at most equal to the limit\n assert blob_gas_used <= MAX_BLOB_GAS_PER_BLOCK\n\n # ensure blob_gas_used matches header\n assert block.header.blob_gas_used == blob_gas_used\n\n Networking\n\nBlob transactions have two network representations. During transaction gossip responses (PooledTransactions), the EIP-2718 TransactionPayload of the blob transaction is wrapped to become:\n\nrlp([tx_payload_body, blobs, commitments, proofs])\n\nEach of these elements are defined as follows:\n\n tx_payload_body - is the TransactionPayloadBody of standard EIP-2718 blob transaction\n blobs - list of Blob items\n commitments - list of KZGCommitment of the corresponding blobs\n proofs - list of KZGProof of the corresponding blobs and commitments\n\nThe node MUST validate tx_payload_body and verify the wrapped data against it. To do so, ensure that:\n\n There are an equal number of tx_payload_body.blob_versioned_hashes, blobs, commitments, and proofs.\n The KZG commitments hash to the versioned hashes, i.e. kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i]\n The KZG commitments match the corresponding blobs and proofs. (Note: this can be optimized using verify_blob_kzg_proof_batch, with a proof for a\nrandom evaluation at a point derived from the commitment and blob data for each blob)\n\nFor body retrieval responses (BlockBodies), the standard EIP-2718 blob transaction TransactionPayload is used.\n\nNodes MUST NOT automatically broadcast blob transactions to their peers.\nInstead, those transactions are only announced using NewPooledTransactionHashes messages, and can then be manually requested via GetPooledTransactions.\n\n Rationale\n\n On the path to sharding\n\nThis EIP introduces blob transactions in the same format in which they are expected to exist in the final sharding specification.\nThis provides a temporary but significant scaling relief for rollups by allowing them to initially scale to 0.375 MB per slot,\nwith a separate fee market allowing fees to be very low while usage of this system is limited.\n\nThe core goal of rollup scaling stopgaps is to provide temporary scaling relief,\nwithout imposing extra development burdens on rollups to take advantage of this relief.\nToday, rollups use calldata. In the future, rollups will have no choice but to use sharded data (also called “blobs”)\nbecause sharded data will be much cheaper.\nHence, rollups cannot avoid making a large upgrade to how they process data at least once along the way.\nBut what we can do is ensure that rollups need to only upgrade once.\nThis immediately implies that there are exactly two possibilities for a stopgap: (i) reducing the gas costs of existing calldata,\nand (ii) bringing forward the format that will be used for sharded data, but not yet actually sharding it.\nPrevious EIPs were all a solution of category (i); this EIP is a solution of category (ii).\n\nThe main tradeoff in designing this EIP is that of implementing more now versus having to implement more later:\ndo we implement 25% of the work on the way to full sharding, or 50%, or 75%?\n\nThe work that is already done in this EIP includes:\n\n A new transaction type, of the exact same format that will need to exist in “full sharding”\n All of the execution-layer logic required for full sharding\n All of the execution / consensus cross-verification logic required for full sharding\n Layer separation between BeaconBlock verification and data availability sampling blobs\n Most of the BeaconBlock logic required for full sharding\n A self-adjusting independent base fee for blobs\n\nThe work that remains to be done to get to full sharding includes:\n\n A low-degree extension of the commitments in the consensus layer to allow 2D sampling\n An actual implementation of data availability sampling\n PBS (proposer/builder separation), to avoid requiring individual validators to process 32 MB of data in one slot\n Proof of custody or similar in-protocol requirement for each validator to verify a particular part of the sharded data in each block\n\nThis EIP also sets the stage for longer-term protocol cleanups. For example, its (cleaner) gas base fee update rule could be applied to the primary basefee calculation.\n\n How rollups would function\n\nInstead of putting rollup block data in transaction calldata, rollups would expect rollup block submitters\nto put the data into blobs. This guarantees availability (which is what rollups need) but would be much cheaper than calldata.\nRollups need data to be available once, long enough to ensure honest actors can construct the rollup state, but not forever.\n\nOptimistic rollups only need to actually provide the underlying data when fraud proofs are being submitted.\nThe fraud proof can verify the transition in smaller steps, loading at most a few values of the blob at a time through calldata.\nFor each value it would provide a KZG proof and use the point evaluation precompile to verify the value against the versioned hash that was submitted before,\nand then perform the fraud proof verification on that data as is done today.\n\nZK rollups would provide two commitments to their transaction or state delta data:\nthe blob commitment (which the protocol ensures points to available data) and the ZK rollup’s own commitment using whatever proof system the rollup uses internally.\nThey would use a proof of equivalence protocol, using the point evaluation precompile,\nto prove that the two commitments refer to the same data.\n\n Versioned hashes & precompile return data\n\nWe use versioned hashes (rather than commitments) as references to blobs in the execution layer to ensure forward compatibility with future changes.\nFor example, if we need to switch to Merkle trees + STARKs for quantum-safety reasons, then we would add a new version,\nallowing the point evaluation precompile to work with the new format.\nRollups would not have to make any EVM-level changes to how they work;\nsequencers would simply have to switch over to using a new transaction type at the appropriate time.\n\nHowever, the point evaluation happens inside a finite field, and it is only well defined if the field modulus is known. Smart contracts could contain a table mapping the commitment version to a modulus, but this would not allow smart contract to take into account future upgrades to a modulus that is not known yet. By allowing access to the modulus inside the EVM, the smart contract can be built so that it can use future commitments and proofs, without ever needing an upgrade.\n\nIn the interest of not adding another precompile, we return the modulus and the polynomial degree directly from the point evaluation precompile. It can then be used by the caller. It is also “free” in that the caller can just ignore this part of the return value without incurring an extra cost – systems that remain upgradable for the foreseeable future will likely use this route for now.\n\n Base fee per blob gas update rule\n\nThe base fee per blob gas update rule is intended to approximate the formula base_fee_per_blob_gas = MIN_BASE_FEE_PER_BLOB_GAS * e**(excess_blob_gas / BLOB_BASE_FEE_UPDATE_FRACTION),\nwhere excess_blob_gas is the total “extra” amount of blob gas that the chain has consumed relative to the “targeted” number (TARGET_BLOB_GAS_PER_BLOCK per block).\nLike EIP-1559, it’s a self-correcting formula: as the excess goes higher, the base_fee_per_blob_gas increases exponentially, reducing usage and eventually forcing the excess back down.\n\nThe block-by-block behavior is roughly as follows.\nIf block N consumes X blob gas, then in block N+1 excess_blob_gas increases by X - TARGET_BLOB_GAS_PER_BLOCK,\nand so the base_fee_per_blob_gas of block N+1 increases by a factor of e**((X - TARGET_BLOB_GAS_PER_BLOCK) / BLOB_BASE_FEE_UPDATE_FRACTION).\nHence, it has a similar effect to the existing EIP-1559, but is more “stable” in the sense that it responds in the same way to the same total usage regardless of how it’s distributed.\n\nThe parameter BLOB_BASE_FEE_UPDATE_FRACTION controls the maximum rate of change of the base fee per blob gas. It is chosen to target a maximum change rate of e**(TARGET_BLOB_GAS_PER_BLOCK / BLOB_BASE_FEE_UPDATE_FRACTION) ≈ 1.125 per block.\n\n Throughput\n\nThe values for TARGET_BLOB_GAS_PER_BLOCK and MAX_BLOB_GAS_PER_BLOCK are chosen to correspond to a target of 3 blobs (0.375 MB) and maximum of 6 blobs (0.75 MB) per block. These small initial limits are intended to minimize the strain on the network created by this EIP and are expected to be increased in future upgrades as the network demonstrates reliability under larger blocks.\n\n Backwards Compatibility\n\n Blob non-accessibility\n\nThis EIP introduces a transaction type that has a distinct mempool version and execution-payload version,\nwith only one-way convertibility between the two. The blobs are in the network representation and not in the consensus representation;\ninstead, they are coupled with the beacon block. This means that there is now a part of a transaction that will not be accessible from the web3 API.\n\n Mempool issues\n\nBlob transactions have a large data size at the mempool layer, which poses a mempool DoS risk,\nthough not an unprecedented one as this also applies to transactions with large amounts of calldata.\n\nBy only broadcasting announcements for blob transactions, receiving nodes will have control over which and how many transactions to receive,\nallowing them to throttle throughput to an acceptable level.\nEIP-5793 will give further fine-grained control to nodes by extending the NewPooledTransactionHashes announcement messages to include the transaction type and size.\n\nIn addition, we recommend including a 1.1x base fee per blob gas bump requirement to the mempool transaction replacement rules.\n\n Test Cases\n\nExecution layer test cases for this EIP can be found in the eip4844_blobs of the ethereum/execution-spec-tests repository. Consensus layer test cases can be found here.\n\n Security Considerations\n\nThis EIP increases the bandwidth requirements per beacon block by a maximum of ~0.75 MB.\nThis is 40% larger than the theoretical maximum size of a block today (30M gas / 16 gas per calldata byte = 1.875M bytes), and so it will not greatly increase worst-case bandwidth.\nPost-merge, block times are static rather than an unpredictable Poisson distribution, giving a guaranteed period of time for large blocks to propagate.\n\nThe sustained load of this EIP is much lower than alternatives that reduce calldata costs, even if the calldata is limited,\nbecause there is no expectation that the blobs need to be stored for as long as an execution payload.\nThis makes it possible to implement a policy that these blobs must be kept for at least a certain period. The specific value chosen is MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS epochs, which is around 18 days, \na much shorter delay compared to proposed (but yet to be implemented) one-year rotation times for execution payload history.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), Dankrad Feist (@dankrad), Diederik Loerakker (@protolambda), George Kadianakis (@asn-d6), Matt Garnett (@lightclient), Mofi Taiwo (@Inphi), Ansgar Dietrichs (@adietrichs), \"EIP-4844: Shard Blob Transactions,\" Ethereum Improvement Proposals, no. 4844, February 2022. Available: https://eips.ethereum.org/EIPS/eip-4844.","tokens":5710,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259561664,"hash":"e59c7a555223cece51f439f611a7326bbec00db2"}
{"url":"https://docs.pyth.network/entropy/set-custom-gas-limits","domain":"docs.pyth.network","title":"Set Custom Gas Limits | Pyth Developer Hub","text":"Set Custom Gas LimitsHow to set custom gas limits for Entropy callbacksCustom gas limits are useful when your callback function requires more gas than the default provider limit, or when you want to optimize gas costs for simpler callbacks.\nPrerequisites\nBefore following this guide, you should first complete the basic setup from the Generate Random Numbers in EVM Contracts guide. This guide builds upon that foundation and assumes you have:\n\nInstalled the Pyth Entropy Solidity SDK\nSet up your contract with the IEntropyConsumer interface\nImplemented the basic entropyCallback function\n\nWhen to Use Custom Gas Limits\nYou might need custom gas limits in these scenarios:\n\nComplex callback logic: Your entropyCallback function performs computationally expensive operations\nGas optimization: You want to use less gas for simple callbacks to reduce fees\nMultiple operations: Your callback needs to perform multiple state changes or external calls\nIntegration requirements: Your application has specific gas requirements for reliability\n\nImplementation\n1. Use requestV2 with Gas Limit Parameter\nInstead of the basic requestV2() method, use the variant that accepts a gasLimit parameter:\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n\n // Store the sequence number for tracking if needed\n}\n2. Calculate Fees with Custom Gas Limit\nWhen using custom gas limits, you must use the getFeeV2 variant that accepts a gasLimit parameter:\n// Get fee for custom gas limit\nuint256 fee = entropy.getFeeV2(customGasLimit);\n\n// NOT: uint256 fee = entropy.getFeeV2(); // This uses default gas limit\n3. Complete Example\nHere's a complete example showing how to implement custom gas limits:\npragma solidity ^0.8.0;\n\nimport { IEntropyConsumer } from \"@pythnetwork/entropy-sdk-solidity/IEntropyConsumer.sol\";\nimport { IEntropyV2 } from \"@pythnetwork/entropy-sdk-solidity/IEntropyV2.sol\";\n\ncontract CustomGasLimitExample is IEntropyConsumer {\nIEntropyV2 public entropy;\nmapping(uint64 => bool) public processedRequests;\n\n constructor(address entropyAddress) {\n entropy = IEntropyV2(entropyAddress);\n }\n\n // Request with custom gas limit for complex callback\n function requestComplexRandomNumber() external payable {\n uint32 customGasLimit = 200000; // Higher limit for complex operations\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n require(msg.value >= fee, \"Insufficient fee\");\n\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n // Store sequence number if needed for tracking\n }\n\n // Request with lower gas limit for simple callback\n function requestSimpleRandomNumber() external payable {\n uint32 customGasLimit = 50000; // Lower limit for simple operations\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n require(msg.value >= fee, \"Insufficient fee\");\n\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n }\n\n // Complex callback that requires more gas\n function entropyCallback(\n uint64 sequenceNumber,\n address provider,\n bytes32 randomNumber\n ) internal override {\n // Prevent duplicate processing\n require(!processedRequests[sequenceNumber], \"Already processed\");\n processedRequests[sequenceNumber] = true;\n\n // Complex operations that require more gas\n for (uint i = 0; i < 10; i++) {\n // Simulate complex state changes\n // This would require more gas than the default limit\n }\n\n // Use the random number for your application logic\n uint256 randomValue = uint256(randomNumber);\n // Your application logic here...\n }\n\n function getEntropy() internal view override returns (address) {\n return address(entropy);\n }\n\n}\nGas Limit Constraints\nWhen setting custom gas limits, be aware of these constraints:\nGas Limit RulesGas limits are automatically rounded up to the nearest multiple of 10,000.\nExample: 19,000 becomes 20,000 25,500 becomes 30,000. The minimum gas limit is\nthe provider's configured default limit. The maximum gas limit is 655,350,000\n(uint16.max * 10,000).\nRecommended Gas Limits\n\nSimple callbacks: 50,000 - 100,000 gas\nModerate complexity: 100,000 - 200,000 gas\nComplex operations: 200,000 - 500,000 gas\nVery complex logic: 500,000+ gas (use with caution)\n\nBest Practices\n1. Estimate Gas Usage\nTest your callback function to determine the actual gas usage:\n// In your tests, measure gas usage\nuint256 gasStart = gasleft();\n// Your callback logic here\nuint256 gasUsed = gasStart - gasleft();\nconsole.log(\"Gas used:\", gasUsed);\n2. Add Safety Buffer\nAlways add a safety buffer to your estimated gas usage:\nuint32 estimatedGas = 150000;\nuint32 safetyBuffer = 20000;\nuint32 customGasLimit = estimatedGas + safetyBuffer;\n3. Handle Gas Limit Errors\nBe prepared to handle cases where your gas limit is insufficient:\nIf your callback runs out of gas, the entropy provider will not be\nable to complete the callback. Always test your gas limits thoroughly and\ninclude adequate safety margins.\n4. Consider Fee Implications\nHigher gas limits result in higher fees. Balance your gas needs with cost considerations:\n// Compare fees for different gas limits\nuint256 defaultFee = entropy.getFeeV2();\nuint256 customFee = entropy.getFeeV2(customGasLimit);\nuint256 additionalCost = customFee - defaultFee;\nTroubleshooting\nIf you're experiencing issues with custom gas limits:\n\nCallback not executing: Your gas limit might be too low\nHigh fees: Consider optimizing your callback or using a lower gas limit\nReverts: Check that your gas limit doesn't exceed the maximum allowed\n\nFor more debugging help, see the Debug Callback Failures guide.\nAdditional Resources\n\nGenerate Random Numbers in EVM Contracts - Basic setup guide\nTransform Entropy Results - General optimization tips\nContract Addresses and Fee Details - Entropy contract deployments and fee details\nGenerate Random Numbers On-chainLearn how to integrate Pyth Entropy to generate random numbers in your dappDebug Callback FailuresHow to identify and resolve issues with Entropy callbacks","tokens":1536,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259565355,"hash":"a351c37541ce6e8f14a18b14785392177d291e4a"}
{"url":"https://docs.openzeppelin.com/role-manager","domain":"docs.openzeppelin.com","title":"Quick Start | OpenZeppelin Docs","text":"Quick StartOpen in ClaudeThe Role Manager is an open source, UI tool you can use to provide your users a way to easily assess the status of the roles involved with your smart contracts. The interface is built specifically for the official OpenZeppelin AccessControl and Ownable contracts.\nThe OpenZeppelin Role Manager allows anyone to simply plug in a contract address and:\n\nsee details relevant to role management, including detection of what OpenZeppelin Access Control implementations are used,\nwhat roles are active and who has what roles,\nindexed role-related transaction history,\nan interface to prepare and execute role management such as assignment or revocation of specific roles.\n\nThe Role Manager currently supports the Stellar Mainnet and Testnet. Future support will be provided for other networks.\n\nA walkthrough of the Role Manager is shown in the video below. Feel free to watch it and follow along with the rest of this page.\n\nGetting Started\nVisit rolemanager.openzeppelin.com to get started.\n1. Select Network\nFirst select the network your contract is deployed to.\n\n2. Provide Contract Name and Address\nFill in the name and onchain address for the contract that you are working with. The indexer that is deployed inspects the contract provided.\n\n3. Review the Contract Roles Related Details\nThe first page of the UI shows a dashboard where you can view the basic details of the smart contract, including:\n\nthe types of role related details implemented,\nthe number of different roles,\nthe number of accounts that hold the different roles\nany pending role changes\n\nThroughout each of the pages, the data can be refreshed. On this page, a JSON snapshot of the current contract state (capabilities, role assignments) can be exported at any point as well.\nBefore moving onto the next step, connect your Stellar-supported wallet using the UI. We'll use Freighter:\n\n4. Review the Authorized accounts\nThe next page displays all of the accounts, their role status (active or pending), their respective roles, and the ability to edit their roles. You can filter the page based on the roles and status.\n\nEditing other accounts' roles requires the appropriate permissions from the connected wallet, of course. It is a simple as checking off the onchain change you would like to implement.\n\nThe Admin and Owner roles require two steps when transferring their roles within the Stellar networks.\n\n5. Manage Roles\nThe next page, titled Roles, provides a simple UI where the different roles are listed with some pertinent details. These include: number of accounts assigned this role, the role name and description.\n\nAs you select different roles, respective details for each are displayed on the right hand side of the page. Here you can revoke or assign roles to different accounts, if you have the correct permissions to do so.\n\nYou can even initiate a Contract Admin or Owner role transfer, and connect the accepting wallet for the role tranfer.\n\nIf the defined block expiration date is passed, the expired transaction is shown until a new two-step role transfer transaction is initiated.\n\n6. Role-Related Transaction History\nThe final page of the UI tool showcases the contract's role-related transaction history. This is made possible because of the deployed indexer inspecting the onchain data.\nOpenZeppelin has deployed indexers for Stellar, and soon other networks to have onchain data at the ready. The current indexer details are listed below:\n\nStellar Indexer 1\nStellar Indexer 2\nThe Indexer Repo\n\nThe public indexer URL can also be replaced in the UI to improve the workflow's robustness.\nThe changes we incurred in the prior steps can be seen in the contract transaction history.\n\nNext Steps\nThe Role Manager is a useful tool for teams that need to test and carry out their onchain role management, and soon will be available for various ecosystems.\nSince it is built off of the same technology stack as the UI Builder, it can also act as a kickoff point for teams looking to build their own UI tool that helps their users carry out the permissioned roles themselves. Take a look at the UI Builder and its repo to better understand its tech stack that can be customized. The UI Builder is an example of what can be built using the UI Kit and Adapters.\nVisit the Role Manager Github repo with the link below and open an issue if you have any problems!\nGitHub RepoChangelogPrevious PageOn this pageGetting Started1. Select Network2. Provide Contract Name and Address3. Review the Contract Roles Related Details4. Review the Authorized accounts5. Manage Roles6. Role-Related Transaction HistoryNext Steps","tokens":1155,"squid":"ink-security_audits","role":"Sentinel","at":1791259571206,"hash":"3b683a823ef6288064379c0730938cdb40e3b3ab"}
{"url":"https://docs.pyth.network/entropy/debug-callback-failures","domain":"docs.pyth.network","title":"Debug Callback Failures | Pyth Developer Hub","text":"Debug Callback FailuresHow to identify and resolve issues with Entropy callbacksThis guide explains how to identify and resolve issues with the Entropy callback.\nThe intended audience for this guide is developers who have made an Entropy random number request, but their application hasn't received a callback.\n\n🔍 Quick Debug Tool\nUse the Entropy Explorer to quickly diagnose and resolve callback issues.\n\nDependencies\nThis guide uses Foundry to submit transactions to the blockchain.\nPlease install Foundry before continuing.\nRun the Callback\nDevelopers can run the Entropy callback themselves to see the reason for the failure.\nTo run the callback, invoke the revealWithCallback function on the Entropy contract on your blockchain.\nThe function has the following signature:\nfunction revealWithCallback(\n address provider,\n uint64 sequenceNumber,\n bytes32 userContribution,\n bytes32 providerContribution\n)\nThis call requires the chain ID, contract address, and four other arguments.\nThe chain ID and contract address can be retrieved from Chainlist and Fee Details page.\nExport these values as environment variables for later use:\nexport CHAIN_ID=base\nexport ENTROPY_ADDRESS=0x6E7D74FA7d5c90FEF9F0512987605a6d546181Bb\n\nThree of the other arguments can be retrieved from the request transaction's event logs.\nLook at the event logs of the request transaction in a block explorer.\nYou should see a RequestedWithCallback event emitted from the Entropy contract.\nCopy the following values from the event into environment variables:\nexport PROVIDER=0x52DeaA1c84233F7bb8C8A45baeDE41091c616506\nexport SEQUENCE_NUMBER=12345\nexport USER_RANDOM_NUMBER=0x1234...\nThe fourth argument (provider contribution) must be retrieved from the provider's API.\nThis value becomes available after the reveal delay has passed.\nCommon Issues\nThere are a few common issues that can cause the callback to fail.\nGas Limit Exceeded\nIf your callback function uses too much gas, the transaction will fail. Check the gas limit for your chain on the chainlist page and ensure your callback function uses less gas.\n\n💡 Tip\nRefer to the Set Custom Gas Limits guide to set a custom gas limit for your callback function.\n\nCallback Function Errors\nYour callback function might contain logic that throws an error. Review your callback implementation for:\n\nDivision by zero\nArray out of bounds access\nFailed require statements\nInsufficient contract balance for operations\n\nTransaction Timing\nMake sure you're attempting the callback after the reveal delay has passed. The reveal delay varies by network and helps prevent MEV attacks.\nRefer to the chainlist page for the reveal delay for each network.Set Custom Gas LimitsHow to set custom gas limits for Entropy callbacksTransform Entropy ResultsBest practices for transforming entropy results in your applications","tokens":707,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259575235,"hash":"03c530aabb389d8d51a050060a60e43d98491d72"}
{"url":"https://eips.ethereum.org/EIPS/eip-20","domain":"eips.ethereum.org","title":"ERC-20: Token Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-20: Token Standard\n\n Authors\n Fabian Vogelsteller <fabian@ethereum.org>, Vitalik Buterin <vitalik.buterin@ethereum.org>\n\n Created\n 2015-11-19\n\n Simple Summary\n\nA standard interface for tokens.\n\n Abstract\n\nThe following standard allows for the implementation of a standard API for tokens within smart contracts.\nThis standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.\n\n Motivation\n\nA standard interface allows any tokens on Ethereum to be re-used by other applications: from wallets to decentralized exchanges.\n\n Specification\n\n Token\n\n Methods\n\nNOTES:\n\n The following specifications use syntax from Solidity 0.4.17 (or above)\n Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!\n\n name\n\nReturns the name of the token - e.g. \"MyToken\".\n\nOPTIONAL - This method can be used to improve usability,\nbut interfaces and other contracts MUST NOT expect these values to be present.\n\nfunction name() public view returns (string)\n\n symbol\n\nReturns the symbol of the token. E.g. “HIX”.\n\nOPTIONAL - This method can be used to improve usability,\nbut interfaces and other contracts MUST NOT expect these values to be present.\n\nfunction symbol() public view returns (string)\n\n decimals\n\nReturns the number of decimals the token uses - e.g. 8, means to divide the token amount by 100000000 to get its user representation.\n\nOPTIONAL - This method can be used to improve usability,\nbut interfaces and other contracts MUST NOT expect these values to be present.\n\nfunction decimals() public view returns (uint8)\n\n totalSupply\n\nReturns the total token supply.\n\nfunction totalSupply() public view returns (uint256)\n\n balanceOf\n\nReturns the account balance of another account with address _owner.\n\nfunction balanceOf(address _owner) public view returns (uint256 balance)\n\n transfer\n\nTransfers _value amount of tokens to address _to, and MUST fire the Transfer event.\nThe function SHOULD throw if the message caller’s account balance does not have enough tokens to spend.\n\nNote Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.\n\nfunction transfer(address _to, uint256 _value) public returns (bool success)\n\n transferFrom\n\nTransfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.\n\nThe transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf.\nThis can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies.\nThe function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.\n\nNote Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.\n\nfunction transferFrom(address _from, address _to, uint256 _value) public returns (bool success)\n\n approve\n\nAllows _spender to withdraw from your account multiple times, up to the _value amount. If this function is called again it overwrites the current allowance with _value.\n\nNOTE: To prevent attack vectors like the one described here and discussed here,\nclients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender.\nTHOUGH The contract itself shouldn’t enforce it, to allow backwards compatibility with contracts deployed before\n\nfunction approve(address _spender, uint256 _value) public returns (bool success)\n\n allowance\n\nReturns the amount which _spender is still allowed to withdraw from _owner.\n\nfunction allowance(address _owner, address _spender) public view returns (uint256 remaining)\n\n Events\n\n Transfer\n\nMUST trigger when tokens are transferred, including zero value transfers.\n\nA token contract which creates new tokens SHOULD trigger a Transfer event with the _from address set to 0x0 when tokens are created.\n\nevent Transfer(address indexed _from, address indexed _to, uint256 _value)\n\n Approval\n\nMUST trigger on any successful call to approve(address _spender, uint256 _value).\n\nevent Approval(address indexed _owner, address indexed _spender, uint256 _value)\n\n Implementation\n\nThere are already plenty of ERC20-compliant tokens deployed on the Ethereum network.\nDifferent implementations have been written by various teams that have different trade-offs: from gas saving to improved security.\n\n Example implementations are available at\n\n OpenZeppelin implementation\n ConsenSys implementation\n\n History\n\nHistorical links related to this standard:\n\n Original proposal from Vitalik Buterin: https://github.com/ethereum/wiki/wiki/Standardized_Contract_APIs/499c882f3ec123537fc2fccd57eaa29e6032fe4a\n Reddit discussion: https://www.reddit.com/r/ethereum/comments/3n8fkn/lets_talk_about_the_coin_standard/\n Original Issue #20: https://github.com/ethereum/EIPs/issues/20\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Fabian Vogelsteller <fabian@ethereum.org>, Vitalik Buterin <vitalik.buterin@ethereum.org>, \"ERC-20: Token Standard,\" Ethereum Improvement Proposals, no. 20, November 2015. Available: https://eips.ethereum.org/EIPS/eip-20.","tokens":1323,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259593131,"hash":"c9467be672d3b7a794da1895a03c1aa2f3ddccf4"}
{"url":"https://docs.openzeppelin.com/monitor/1.3.x","domain":"docs.openzeppelin.com","title":"OpenZeppelin Monitor | OpenZeppelin Docs","text":"OpenZeppelin MonitorOpen in ClaudeOverview\nIn the rapidly evolving world of blockchain technology, effective monitoring is crucial for ensuring security and performance. OpenZeppelin Monitor is a blockchain monitoring service that watches for specific on-chain activities and triggers notifications based on configurable conditions. The service offers multi-chain support with configurable monitoring schedules, flexible trigger conditions, and an extensible architecture for adding new chains.\nKey Capabilities\n\nReal-time Monitoring: Watch blockchain networks in real-time for specific events and transactions\nSmart Filtering: Use flexible expressions to define exactly what you want to monitor\nMulti-notification Support: Send alerts via Slack, Discord, Email, Telegram, Webhooks, or custom scripts\nConfigurable Scheduling: Set custom monitoring schedules using cron expressions\nData Persistence: Store monitoring data and resume from checkpoints\nExtensible Architecture: Easy to add support for new blockchains and notification types\n\nSupported Networks\n\nEVM-Compatible Networks\nStellar\nSolana\nMidnight (Partially Supported)\n\nNotification Channels\n\nSlack - Send formatted messages to Slack channels\nDiscord - Post alerts to Discord channels via webhooks\nEmail - Send email notifications with SMTP support\nTelegram - Send messages to Telegram chats via bot API\nWebhooks - Send HTTP requests to custom endpoints\nCustom Scripts - Execute Python, JavaScript, or Bash scripts\n\nTo get started immediately, see Quickstart.\nTo test monitors against a local EVM node (no testnet required), see Local EVM Testing.\nInstallation\nPrerequisites\n\nUse Rust 2024 edition, version 1.90 or later.\nDocker (optional, for containerized deployment)\nPython 3.11 (3.10+) - For pre-commit hooks; we recommend pyenv for version management (see Contribution guidelines)\n\nSystem Dependencies (Linux)\nFor Ubuntu 22.04+ or Debian-based systems (both x86 and ARM64 architectures), install required packages:\nNote: Python 3.11 is recommended; 3.10+ is the minimum for pre-commit hooks.\n# Install required packages directly\nsudo apt update\nsudo apt install -y \\\n build-essential \\\n curl \\\n git \\\n pkg-config \\\n libssl-dev \\\n libffi-dev \\\n libyaml-dev \\\n python3 \\\n python3-venv \\\n python3-pip\nOr use the provided system package script (installs Python 3.11 if your system Python is below 3.10):\nchmod +x ./scripts/linux/sys_pkgs_dev.sh\n# Installs required packages and ensures compatible Python version\n./scripts/linux/sys_pkgs_dev.sh # For Python/dev dependencies (includes runtime deps)\n# Or, for runtime-only (no Python/dev tools): ./scripts/linux/sys_pkgs_core.sh\nLocal Installation\n\nClone the repository:\ngit clone https://github.com/openzeppelin/openzeppelin-monitor\ncd openzeppelin-monitor\n\nBuild the application:\ncargo build --release\n\nMove binary to project root:\nmv ./target/release/openzeppelin-monitor .\n\nVerify installation:\n./openzeppelin-monitor --help\n\nView available options:\n./openzeppelin-monitor --help\n\n# Enable logging to file\n./openzeppelin-monitor --log-file\n\n# Enable metrics server\n./openzeppelin-monitor --metrics\n\n# Validate configuration files without starting the service\n./openzeppelin-monitor --check\n\nDocker Installation\n\nClone the repository:\ngit clone https://github.com/openzeppelin/openzeppelin-monitor\ncd openzeppelin-monitor\n\nSet up environment:\ncp .env.example .env\n# Edit .env file with your configuration\n\nStart with Docker Compose:\ncargo make docker-compose-up\n\nMetrics Configuration\nThe metrics server, Prometheus, and Grafana can be enabled by setting METRICS_ENABLED=true in your .env file.\nYou can start services directly with Docker Compose:\n# without metrics profile ( METRICS_ENABLED=false by default )\ndocker compose up -d\n\n# With metrics enabled\ndocker compose --profile metrics up -d\nTo view prometheus metrics in a UI, you can use http://localhost:9090 on your browser.\nTo view grafana dashboard, you can use http://localhost:3000 on your browser.\nBy default, predefined metrics within a dashboard is populated in grafana.\nConfiguration Guidelines\nRecommended File Naming Conventions\n\nNetwork configurations: <network_type>_<network_name>.json\n\nExample: ethereum_mainnet.json, stellar_testnet.json\nShould match the slug property inside the file\n\nMonitor configurations: <asset>_<action>_monitor.json\n\nExample: usdc_transfer_monitor.json, dai_liquidation_monitor.json\nReferenced by monitors using their name property\n\nTrigger configurations: <type>_<purpose>.json\n\nExample: slack_notifications.json, email_alerts.json\nIndividual triggers referenced by their configuration key\n\nConfiguration References\n\nMonitor, network, and trigger names must be unique across all configurations files\n\nMonitor’s networks array must contain valid network slug values from network configuration files\n\nMonitor’s triggers array must contain valid trigger configuration keys\n\nExample valid references:\n// networks/ethereum_mainnet.json\n{\n \"slug\": \"ethereum_mainnet\",\n ...\n}\n\n// triggers/slack_notifications.json\n{\n \"large_transfer_slack\": {\n ...\n }\n}\n\n// monitors/usdc_transfer_monitor.json\n{\n \"networks\": [\"ethereum_mainnet\"],\n \"triggers\": [\"large_transfer_slack\"],\n ...\n}\n\nEnsure all referenced slugs and trigger keys exist in their respective configuration files. The monitor will fail to start if it cannot resolve these references.\nSafe Protocol Guidelines\nThe monitor implements protocol security validations across different components and will issue warnings when potentially insecure configurations are detected. While insecure protocols are not blocked, we strongly recommend following these security guidelines:\nNetwork Protocols\nRPC URLs\n\nHTTPS Recommended: Using https:// for RPC endpoints is strongly recommended\nWSS Recommended: For WebSocket connections, wss:// (secure WebSocket) is strongly recommended\nWarning: Using http:// or ws:// will trigger security warnings as they transmit data unencrypted\n\nNotification Protocols\nWebhook Notifications\n\nHTTPS Recommended: URLs should use HTTPS protocol\nAuthentication Recommended: Including either:\n\nX-API-Key header\nAuthorization header\n\nOptional Secret: Can include a secret for HMAC authentication\n\nWhen a secret is provided, the monitor will:\n\nGenerate a timestamp in milliseconds\nCreate an HMAC-SHA256 signature of the payload and timestamp\nAdd the signature in the X-Signature header\nAdd the timestamp in the X-Timestamp header\n\nThe signature is computed as: HMAC-SHA256(secret, payload + timestamp)\n\nWarning: Non-HTTPS URLs or missing authentication headers will trigger security warnings\n\nSlack Notifications\n\nHTTPS Recommended: Webhook URLs should start with https://hooks.slack.com/\nWarning: Non-HTTPS URLs will trigger security warnings\n\nDiscord Notifications\n\nHTTPS Recommended: Webhook URLs should start with https://discord.com/api/webhooks/\nWarning: Non-HTTPS URLs will trigger security warnings\n\nTelegram Notifications\n\nProtocol: POST request with a application/json payload to the sendMessage method.\nEndpoint: https://api.telegram.org/bot<token>/sendMessage\nSecurity:\n\nHTTPS Required: The API endpoint uses HTTPS.\nAuthentication is handled via the Bot Token in the URL. Keep this token secure.\n\nFormatting: Messages are sent with parse_mode set to MarkdownV2. Special characters in the message title and body are automatically escaped to prevent formatting errors.\n\nEmail Notifications\n\nSecure Ports Recommended: The following ports are considered secure:\n\n465: SMTPS (SMTP over SSL)\n587: SMTP with STARTTLS\n993: IMAPS (IMAP over SSL)\n\nWarning: Using other ports will trigger security warnings\nValid Format: Email addresses must follow RFC 5322 format\n\nNotifications Retry Policy\nFollowing notification protocols support retry policies:\n\nSlack\nDiscord\nTelegram\nWebhook\nEmail\n\nDefault retry policy is using exponential backoff with the following parameters:\nParameterDefault ValueDescriptionmax_retries3Maximum number of retries before giving upbase_for_backoff2Base duration for exponential backoff calculations in secondsinitial_backoff250Initial backoff duration in millisecondsmax_backoff10Maximum backoff duration in secondsjitterFullJitter strategy to apply to the backoff duration, currently supports Full and None\nThese parameters can be overridden by providing custom RetryConfig struct in retry_policy field in trigger configuration.\nScript Security\nFile Permissions (Unix Systems)\n\nRestricted Write Access: Script files should not have overly permissive write permissions\nRecommended Permissions: Use 644 (rw-r--r--) for script files\nWarning: Files with mode 022 or more permissive will trigger security warnings\n\nExample Setting Recommended Permissions\nchmod 644 ./config/filters/my_script.sh\nSecret Management\nThe monitor implements a secure secret management system with support for multiple secret sources and automatic memory zeroization.\nSecret Sources\nThe monitor supports three types of secret sources:\n\nPlain Text: Direct secret values (wrapped in SecretString for secure memory handling)\nEnvironment Variables: Secrets stored in environment variables\nHashicorp Cloud Vault: Secrets stored in Hashicorp Cloud Vault\n\nSecurity Features\n\nAutomatic Zeroization: Secrets are automatically zeroized from memory when no longer needed\nType-Safe Resolution: Secure handling of secret resolution with proper error handling\nConfiguration Support: Serde support for configuration files\n\nConfiguration\nSecrets can be configured in the JSON files using the following format:\n{\n \"type\": \"Plain\",\n \"value\": \"my-secret-value\"\n}\n{\n \"type\": \"Environment\",\n \"value\": \"MY_SECRET_ENV_VAR\"\n}\n{\n \"type\": \"HashicorpCloudVault\",\n \"value\": \"my-secret-name\"\n}\nHashicorp Cloud Vault Integration\nTo use Hashicorp Cloud Vault, configure the following environment variables:\nEnvironment VariableDescriptionHCP_CLIENT_IDHashicorp Cloud Vault client IDHCP_CLIENT_SECRETHashicorp Cloud Vault client secretHCP_ORG_IDHashicorp Cloud Vault organization IDHCP_PROJECT_IDHashicorp Cloud Vault project IDHCP_APP_NAMEHashicorp Cloud Vault application name\nBest Practices\n\nUse environment variables or vault for production secrets\nAvoid storing plain text secrets in configuration files\nUse appropriate access controls for vault secrets\nMonitor vault access patterns for suspicious activity\n\nBasic Configuration\n\nSet up environment variables:\n\nCopy the example environment file and update values according to your needs\ncp .env.example .env\nThis table lists the environment variables and their default values.\nEnvironment VariableDefault ValueAccepted ValuesDescriptionRUST_LOGinfoinfo, debug, warn, error, traceLog level.LOG_MODEstdoutstdout, fileWrite logs either to console or to file.LOG_DATA_DIRlogs/<any file path>Directory to write log files on host.MONITOR_DATA_DIRnull<any file path>Persist monitor data between container restarts.LOG_MAX_SIZE1073741824<size in bytes or human-readable format (e.g., \"1GB\", \"500MB\")>Size after which logs needs to be rolled. Accepts both raw bytes (e.g., \"1073741824\") or human-readable formats (e.g., \"1GB\", \"500MB\").METRICS_ENABLEDfalsetrue, falseEnable metrics server for external tools to scrape metrics.METRICS_PORT8081<any tcp port (preferably choose non-privileged ports i.e. (1024-65535))>Port to use for metrics server.HCP_CLIENT_ID-<string>Hashicorp Cloud Vault client ID for secret management.HCP_CLIENT_SECRET-<string>Hashicorp Cloud Vault client secret for secret management.HCP_ORG_ID-<string>Hashicorp Cloud Vault organization ID for secret management.HCP_PROJECT_ID-<string>Hashicorp Cloud Vault project ID for secret management.HCP_APP_NAME-<string>Hashicorp Cloud Vault application name for secret management.\n\nCopy and configure some example files:\n\n# EVM Configuration\ncp examples/config/monitors/evm_transfer_usdc.json config/monitors/evm_transfer_usdc.json\ncp examples/config/networks/ethereum_mainnet.json config/networks/ethereum_mainnet.json\n\n# Stellar Configuration\ncp examples/config/monitors/stellar_swap_dex.json config/monitors/stellar_swap_dex.json\ncp examples/config/networks/stellar_mainnet.json config/networks/stellar_mainnet.json\n\n# Solana Configuration\ncp examples/config/monitors/solana_kamino_deposit.json config/monitors/solana_kamino_deposit.json\ncp examples/config/networks/solana_mainnet.json config/networks/solana_mainnet.json\n\n# Notification Configuration\ncp examples/config/triggers/slack_notifications.json config/triggers/slack_notifications.json\ncp examples/config/triggers/email_notifications.json config/triggers/email_notifications.json\n\n# Filter Configuration\ncp examples/config/filters/evm_filter_block_number.sh config/filters/evm_filter_block_number.sh\ncp examples/config/filters/stellar_filter_block_number.sh config/filters/stellar_filter_block_number.sh\nCommand Line Options\nThe monitor supports several command-line options for configuration and control:\nOptionDefaultDescription**--log-file**falseWrite logs to file instead of stdout**--log-level**infoSet log level (trace, debug, info, warn, error)**--log-path**logs/Path to store log files**--log-max-size**1GBMaximum log file size before rolling**--metrics-address**127.0.0.1:8081Address to start the metrics server on**--metrics**falseEnable metrics server**--monitor-path**-Path to the monitor to execute (for testing)**--network**-Network to execute the monitor for (for testing)**--block**-Block number to execute the monitor for (for testing)**--check**falseValidate configuration files without starting the service\nData Storage Configuration\nThe monitor uses file-based storage by default.\nFile Storage\nWhen store_blocks is enabled in the network configuration, the monitor stores:\n\nProcessed blocks: ./data/<network_slug>_blocks_<timestamp>.json\nMissed blocks: ./data/<network_slug>_missed_blocks.json (JSON format with block status tracking)\n\nThe missed blocks file tracks blocks that failed to be fetched or processed, including their status (Pending, Recovering, Recovered, Failed), retry count, and error information. When recovery_config is enabled, this file is used by the recovery job to retry failed blocks.\nAdditionally, the monitor will always store:\n\nLast processed block: ./data/<network_slug>_last_block.txt (enables resuming from last checkpoint)\n\nConfiguration Files\nNetwork Configuration\nA Network configuration defines connection details and operational parameters for a specific blockchain network, supporting both EVM and Stellar-based chains.\nExample Network Configuration\n{\n \"network_type\": \"Stellar\",\n \"slug\": \"stellar_mainnet\",\n \"name\": \"Stellar Mainnet\",\n \"rpc_urls\": [\n {\n \"type_\": \"rpc\",\n \"url\": {\n \"type\": \"plain\",\n \"value\": \"https://soroban.stellar.org\"\n },\n \"weight\": 100\n }\n ],\n \"network_passphrase\": \"Public Global Stellar Network ; September 2015\",\n \"block_time_ms\": 5000,\n \"confirmation_blocks\": 2,\n \"cron_schedule\": \"0 */1 * * * *\",\n \"max_past_blocks\": 20,\n \"store_blocks\": true\n}\nAvailable Fields\nFieldTypeDescription**network_type**StringType of blockchain (\"EVM\" or \"Stellar\")**slug**StringRequired - Unique identifier for the network**name**StringRequired - Unique Human-readable network name**rpc_urls**Array[Object]List of RPC endpoints with weights for load balancing**chain_id**NumberNetwork chain ID (EVM only)**network_passphrase**StringNetwork identifier (Stellar only)**block_time_ms**NumberAverage block time in milliseconds**confirmation_blocks**NumberNumber of blocks to wait for confirmation**cron_schedule**StringMonitor scheduling in cron format**max_past_blocks**NumberMaximum number of past blocks to process**store_blocks**BooleanWhether to store processed blocks (defaults output to ./data/ directory)**recovery_config**ObjectOptional configuration for missed block recovery (see below)\nMissed Block Recovery\nWhen RPC failures or network issues cause blocks to be missed during normal monitoring cycles, the missed block recovery feature can automatically retry fetching and processing them. This runs as a separate background job to avoid impacting the main monitoring loop.\nExample Recovery Configuration\n{\n \"recovery_config\": {\n \"enabled\": true,\n \"cron_schedule\": \"0 */5 * * * *\",\n \"max_blocks_per_run\": 10,\n \"max_block_age\": 1000,\n \"max_retries\": 3,\n \"retry_delay_ms\": 1000\n }\n}\nRecovery Config Fields\nFieldTypeDescription**enabled**BooleanWhether the recovery job is active**cron_schedule**StringWhen to run recovery (separate from main monitor schedule)**max_blocks_per_run**NumberMaximum blocks to attempt per recovery cycle (limits RPC load)**max_block_age**NumberBlocks older than this (in blocks from current) are pruned and not recovered**max_retries**NumberMaximum retry attempts before marking a block as failed**retry_delay_ms**NumberDelay in milliseconds between retry attempts\nImportant Considerations\n\nWe strongly recommend using private RPC providers for improved reliability.\n\nTrigger Configuration\nA Trigger defines actions to take when monitored conditions are met. Triggers can send notifications, make HTTP requests, or execute scripts.\nExample Trigger Configuration\n{\n \"evm_large_transfer_usdc_slack\": {\n \"name\": \"Large Transfer Slack Notification\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\n \"type\": \"plain\",\n \"value\": \"https://hooks.slack.com/services/A/B/C\"\n },\n \"message\": {\n \"title\": \"${monitor.name} triggered\",\n \"body\": \"Large transfer of ${events.0.args.value} USDC from ${events.0.args.from} to ${events.0.args.to} | https://etherscan.io/tx/${transaction.hash}#eventlog\"\n }\n }\n },\n \"stellar_large_transfer_usdc_slack\": {\n \"name\": \"Large Transfer Slack Notification\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\n \"type\": \"environment\",\n \"value\": \"SLACK_WEBHOOK_URL\"\n },\n \"message\": {\n \"title\": \"large_transfer_usdc_slack triggered\",\n \"body\": \"${monitor.name} triggered because of a large transfer of ${functions.0.args.amount} USDC to ${functions.0.args.to} | https://stellar.expert/explorer/testnet/tx/${transaction.hash}\"\n }\n }\n }\n}\nTrigger Types\nSlack Notifications\n{\n \"slack_url\": {\n \"type\": \"HashicorpCloudVault\",\n \"value\": \"slack-webhook-url\"\n },\n \"message\": {\n \"title\": \"Alert Title\",\n \"body\": \"Alert message for ${transaction.hash}\"\n }\n}\nSlack Notification Fields\nFieldTypeDescription**name**StringRequired - Unique Human-readable name for the notification**trigger_type**StringMust be \"slack\" for Slack notifications**config.slack_url.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.slack_url.value**StringSecret value (URL, environment variable name, or vault secret name)**config.message.title**StringTitle that appears in the Slack message**config.message.body**StringMessage template with variable substitution\nEmail Notifications\n{\n \"host\": \"smtp.gmail.com\",\n \"port\": 465,\n \"username\": {\n \"type\": \"plain\",\n \"value\": \"sender@example.com\"\n },\n \"password\": {\n \"type\": \"environment\",\n \"value\": \"SMTP_PASSWORD\"\n },\n \"message\": {\n \"title\": \"Alert Subject\",\n \"body\": \"Alert message for ${transaction.hash}\",\n },\n \"sender\": \"sender@example.com\",\n \"recipients\": [\"recipient@example.com\"]\n}\nEmail Notification Fields\nFieldTypeDescription**name**StringRequired - Unique Human-readable name for the notification**trigger_type**StringMust be \"email\" for email notifications**config.host**StringSMTP server hostname**config.port**NumberSMTP port (defaults to 465)**config.username.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.username.value**StringSecret value (username, environment variable name, or vault secret name)**config.password.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.password.value**StringSecret value (password, environment variable name, or vault secret name)**config.message.title**StringEmail subject line**config.message.body**StringEmail body template with variable substitution**config.sender**StringSender email address**config.recipients**Array[String]List of recipient email addresses\nWebhook Notifications\n{\n \"url\": {\n \"type\": \"HashicorpCloudVault\",\n \"value\": \"webhook-url\"\n },\n \"method\": \"POST\",\n \"secret\": {\n \"type\": \"environment\",\n \"value\": \"WEBHOOK_SECRET\"\n },\n \"headers\": {\n \"Content-Type\": \"application/json\"\n },\n \"message\": {\n \"title\": \"Alert Title\",\n \"body\": \"Alert message for ${transaction.hash}\"\n }\n}\nWebhook Notification Fields\nFieldTypeDescription**name**StringRequired - Unique Human-readable name for the notification**trigger_type**StringMust be \"webhook\" for webhook notifications**config.url.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.url.value**StringSecret value (URL, environment variable name, or vault secret name)**config.method**StringHTTP method (POST, GET, etc.) defaults to POST**config.secret.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.secret.value**StringSecret value (HMAC secret, environment variable name, or vault secret name)**config.headers**ObjectHeaders to include in the webhook request**config.payload_mode**StringPayload mode: \"template\" (default) or \"raw\"**config.message.title**StringTitle that appears in the webhook message (required for template mode)**config.message.body**StringMessage template with variable substitution (required for template mode)\nWebhook Payload Modes\nWebhooks support two payload modes that determine how data is sent to your endpoint:\nTemplate Mode (default)\nIn template mode, the webhook sends a formatted JSON payload with title and body fields, where variables are substituted from the monitor match data:\n{\n \"title\": \"Monitor Alert triggered\",\n \"body\": \"Large transfer detected from 0x123... to 0x456...\"\n}\nRaw Mode\nIn raw mode, the webhook sends the complete MonitorMatch object directly as the JSON payload. This is useful when you want to receive all blockchain event data without formatting, allowing your receiving service to process the raw data as needed.\n{\n \"raw_webhook\": {\n \"name\": \"Raw Payload Webhook\",\n \"trigger_type\": \"webhook\",\n \"config\": {\n \"url\": { \"type\": \"plain\", \"value\": \"https://api.example.com/events\" },\n \"method\": \"POST\",\n \"payload_mode\": \"raw\"\n }\n }\n}\nWhen using raw mode:\n\nThe message field is ignored\nThe payload contains the full monitor match including: monitor configuration, transaction details, receipt, logs, matched conditions, and decoded arguments\nThis is particularly useful for integrations that need to process the complete event data programmatically\n\nDiscord Notifications\n{\n \"discord_url\": {\n \"type\": \"plain\",\n \"value\": \"https://discord.com/api/webhooks/123-456-789\"\n },\n \"message\": {\n \"title\": \"Alert Title\",\n \"body\": \"Alert message for ${transaction.hash}\"\n }\n}\nDiscord Notification Fields\nFieldTypeDescription**name**StringRequired - Unique Human-readable name for the notification**trigger_type**StringMust be \"discord\" for Discord notifications**config.discord_url.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.discord_url.value**StringSecret value (URL, environment variable name, or vault secret name)**config.message.title**StringTitle that appears in the Discord message**config.message.body**StringMessage template with variable substitution\nTelegram Notifications\n{\n \"token\": {\n \"type\": \"HashicorpCloudVault\",\n \"value\": \"telegram-bot-token\"\n },\n \"chat_id\": \"9876543210\",\n \"message\": {\n \"title\": \"Alert Title\",\n \"body\": \"Alert message for ${transaction.hash}\"\n }\n}\nTelegram Notification Fields\nFieldTypeDescription**name**StringRequired - Unique Human-readable name for the notification**trigger_type**StringMust be \"telegram\" for Telegram notifications**config.token.type**StringSecret type (\"Plain\", \"Environment\", or \"HashicorpCloudVault\")**config.token.value**StringSecret value (bot token, environment variable name, or vault secret name)**config.chat_id**StringTelegram chat ID**config.disable_web_preview**BooleanWhether to disable web preview in Telegram messages (defaults to false)**config.message.title**StringTitle that appears in the Telegram message**config.message.body**StringMessage template with variable substitution\nCustom Script Notifications\n{\n \"language\": \"Bash\",\n \"script_path\": \"./config/triggers/scripts/custom_notification.sh\",\n \"arguments\": [\"--verbose\"],\n \"timeout_ms\": 1000\n}\nScript Notification Fields\nFieldTypeDescription**name**StringRequired - Unique Human-readable name for the notification**trigger_type**StringMust be \"script\" for Custom Script notifications**language**StringThe language of the script**script_path**StringThe path to the script**arguments**Array[String]The arguments of the script (optional).**timeout_ms**NumberThe timeout of the script is important to avoid infinite loops during the execution. If the script takes longer than the timeout, it will be killed.\nFor more information about custom scripts, see Custom Scripts Section.\nSecurity Risk: Only run scripts that you trust and fully understand. Malicious scripts can harm your system or expose sensitive data. Always review script contents and verify their source before execution.\nAvailable Template Variables\nThe monitor uses a structured JSON format with nested objects for template variables. The data is flattened into dot notation for template use.\nCommon Variables\nVariableDescription**monitor.name**Name of the triggered monitor**transaction.hash**Hash of the transaction**functions**All functions matched and their parameters**events**All events matched and their parameters\nNetwork-Specific Variables\nEVM Variables\nVariableDescription**transaction.from**Sender address**transaction.to**Recipient address**transaction.value**Transaction value**events.[index].signature**Event signature**events.[index].args.[param]**Event parameters by name**functions.[index].signature**Function signature**functions.[index].args.[param]**Function parameters by name\nStellar Variables\nVariableDescription**events.[index].args.[position]**Event parameters by position**events.[index].args.[param]**Event parameters by name (only in case the contract supports event parameters name)**functions.[index].args.[param]**Function parameters by name\nTransaction-related variables (transaction.from, transaction.to, transaction.value) are not available for Stellar networks.\nMessage Formatting\nSlack, Discord, Telegram, Email and Webhook support Markdown formatting in their message bodies. You can use Markdown syntax to enhance your notifications.\nExample Email Notification with Markdown\n{\n \"email_notification\": {\n \"name\": \"Formatted Alert\",\n \"trigger_type\": \"email\",\n \"config\": {\n \"host\": \"smtp.example.com\",\n \"port\": 465,\n \"username\": {\"type\": \"plain\", \"value\": \"alerts@example.com\"},\n \"password\": {\"type\": \"plain\", \"value\": \"password\"},\n \"message\": {\n \"title\": \"**High Value Transfer Alert**\",\n \"body\": \"### Transaction Details\\n\\n* **Amount:** ${events.0.args.value} USDC\\n* **From:** `${events.0.args.from}`\\n* **To:** `${events.0.args.to}`\\n\\n> Transaction Hash: ${transaction.hash}\\n\\n[View on Explorer](https://etherscan.io/tx/${transaction.hash})\"\n },\n \"sender\": \"alerts@example.com\",\n \"recipients\": [\"recipient@example.com\"]\n }\n }\n}\nExample Slack Notification with Markdown\n{\n \"slack_notification\": {\n \"name\": \"Formatted Alert\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\"type\": \"plain\", \"value\": \"https://hooks.slack.com/services/XXX/YYY/ZZZ\"},\n \"message\": {\n \"title\": \"*🚨 High Value Transfer Alert*\",\n \"body\": \"*Transaction Details*\\n\\n• *Amount:* `${events.0.args.value}` USDC\\n• *From:* `${events.0.args.from}`\\n• *To:* `${events.0.args.to}`\\n\\n>Transaction Hash: `${transaction.hash}`\\n\\n<https://etherscan.io/tx/${transaction.hash}|View on Explorer>\"\n }\n }\n }\n}\nExample Discord Notification with Markdown\n{\n \"discord_notification\": {\n \"name\": \"Formatted Alert\",\n \"trigger_type\": \"discord\",\n \"config\": {\n \"discord_url\": {\"type\": \"plain\", \"value\": \"https://discord.com/api/webhooks/XXX/YYY\"},\n \"message\": {\n \"title\": \"**🚨 High Value Transfer Alert**\",\n \"body\": \"# Transaction Details\\n\\n* **Amount:** `${events.0.args.value}` USDC\\n* **From:** `${events.0.args.from}`\\n* **To:** `${events.0.args.to}`\\n\\n>>> Transaction Hash: `${transaction.hash}`\\n\\n**[View on Explorer](https://etherscan.io/tx/${transaction.hash})\"\n }\n }\n }\n}\nExample Telegram Notification with Markdown\n{\n \"telegram_notification\": {\n \"name\": \"Formatted Alert\",\n \"trigger_type\": \"telegram\",\n \"config\": {\n \"token\": {\"type\": \"plain\", \"value\": \"1234567890:ABCDEFGHIJKLMNOPQRSTUVWXYZ\"},\n \"chat_id\": \"9876543210\",\n \"message\": {\n \"title\": \"*🚨 High Value Transfer Alert*\",\n \"body\": \"*Transaction Details*\\n\\n• *Amount:* `${events.0.args.value}` USDC\\n• *From:* `${events.0.args.from}`\\n• *To:* `${events.0.args.to}`\\n\\n`Transaction Hash: ${transaction.hash}`\\n\\n[View on Explorer](https://etherscan.io/tx/${transaction.hash})\"\n }\n }\n }\n}\nImportant Considerations\n\nEmail notification port defaults to 465 if not specified.\nTemplate variables are context-dependent:\n\nEvent-triggered notifications only populate event variables.\nFunction-triggered notifications only populate function variables.\nMixing contexts results in empty values.\n\nCredentials in configuration files should be properly secured.\nConsider using environment variables for sensitive information.\n\nMonitor Configuration\nA Monitor defines what blockchain activity to watch and what actions to take when conditions are met. Each monitor combines:\n\nNetwork targets (which chains to monitor)\nContract addresses to watch\nConditions to match (functions, events, transactions)\nTrigger conditions (custom scripts that act as filters for each monitor match to determine whether a trigger should be activated).\nTriggers to execute when conditions are met\n\nExample Monitor Configuration\n{\n \"name\": \"Large USDC Transfers\",\n \"networks\": [\"ethereum_mainnet\"],\n \"paused\": false,\n \"addresses\": [\n {\n \"address\": \"0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48\",\n \"contract_spec\": [ ... ]\n }\n ],\n \"match_conditions\": {\n \"functions\": [\n {\n \"signature\": \"transfer(address,uint256)\",\n \"expression\": \"value > 1000000\"\n }\n ],\n \"events\": [\n {\n \"signature\": \"Transfer(address,address,uint256)\",\n \"expression\": \"value > 1000000\"\n }\n ],\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": \"value > 1500000000000000000\"\n }\n ]\n },\n \"trigger_conditions\": [\n {\n \"script_path\": \"./config/filters/evm_filter_block_number.sh\",\n \"language\": \"bash\",\n \"arguments\": \"--verbose\",\n \"timeout_ms\": 1000\n }\n ],\n \"triggers\": [\"evm_large_transfer_usdc_slack\", \"evm_large_transfer_usdc_email\"]\n}\nAvailable Fields\nFieldTypeDescription**name**StringRequired - Unique identifier for this monitor**networks**Array[String]List of network slugs this monitor should watch**paused**BooleanWhether this monitor is currently paused**addresses**Array[Object]Contract addresses to monitor with optional ABIs**match_conditions**ObjectCollection of conditions that can trigger the monitor**trigger_conditions**Array[Object]Collection of filters to apply to monitor matches before executing triggers**triggers**Array[String]IDs of triggers to execute when conditions match\nMatch Conditions\nMonitors support three types of match conditions that can be combined:\nFunction Conditions\nMatch specific function calls to monitored contracts:\n{\n \"functions\": [\n {\n \"signature\": \"transfer(address,uint256)\",\n \"expression\": \"value > 1000\"\n }\n ]\n}\nEvent Conditions\nMatch events emitted by monitored contracts:\n{\n \"events\": [\n {\n \"signature\": \"Transfer(address,address,uint256)\",\n \"expression\": \"value > 1000000\"\n }\n ]\n}\nSignature Format by Network Type\nThe signature field format varies by blockchain network type:\nEVM Networks\nFor EVM networks (Ethereum, Polygon, BSC, etc.), signatures follow the Solidity function/event signature format:\nFunctions:\nfunctionName(type1,type2,...)\nEvents:\nEventName(type1,type2,type3,...)\nExampleDescriptiontransfer(address,uint256)ERC20 transfer functionapprove(address,uint256)ERC20 approve functionTransfer(address,address,uint256)ERC20 Transfer eventApproval(address,address,uint256)ERC20 Approval eventswap(uint256,uint256,address,bytes)Uniswap V2 swap function\n\nUse the exact Solidity types (e.g., uint256 not uint, address not addr)\nDo not include parameter names, only types\nDo not include spaces between parameters\nFor indexed event parameters, use the same type format\n\nStellar Networks\nFor Stellar/Soroban contracts, signatures follow the SEP-48 format with capitalized type names:\nFunctions:\nfunctionName(Type1,Type2,...)\nExampleDescriptionswap(Address,U32,U32,U128,U128)DEX swap functiontransfer(Address,Address,I128)Token transfer functiondeposit(Address,I128)Deposit function\n\nUse capitalized type names: Address, U32, U64, U128, I32, I64, I128, Bool, String, Bytes, Symbol, Vec, Map\nThe contract specification (SEP-48) can be auto-fetched from the chain if not provided\n\nSolana Networks\nFor Solana programs, signatures use a simplified format:\nEvents:\nEventName\nor with program-specific context:\nEvent description with program address\nExampleDescriptionDepositSimple event name for Anchor-based programsWithdrawSimple withdrawal eventUpgraded program <PROGRAM_ADDRESS>BPF Loader upgrade event for a specific program\nFunctions:\nSolana function filtering is not currently supported. Use event filtering instead.\n\nFor Anchor-based programs, use the event name directly (e.g., Deposit, Withdraw)\nFor BPF Loader upgrade monitoring, use the format Upgraded program <PROGRAM_ADDRESS> where <PROGRAM_ADDRESS> is the actual program address you want to monitor\nEvent names are case-sensitive\nTip: To find the exact event names emitted by a Solana program, inspect any transaction on Solscan or Solana Explorer and check the \"Program Logs\" section to see the log messages and event names\n\nMidnight Networks\nFor Midnight networks, function signatures are simplified:\nFunctions:\nfunctionName()\nExampleDescriptionpost()Bulletin board post functiontransfer()Transfer function\n\nDue to Midnight's privacy-focused design, all argument variations are treated identically\npost, post(), and post(x, y, z) are equivalent\nEvent monitoring is not currently supported on Midnight\n\nTransaction Conditions\nMatch transaction properties. The available fields and expression syntax depend on the network type (EVM/Stellar)\n{\n \"transactions\": [\n {\n \"status\": \"Success\", // Only match successful transactions\n \"expression\": \"value > 1500000000000000000\" // Match transactions with value greater than 1.5 ETH\n }\n ]\n}\nAvailable Transaction Fields (EVM)\nFieldTypeDescription**value**uint256Transaction value in wei**from**addressSender address (case-insensitive comparison)**to**addressRecipient address (case-insensitive comparison)**hash**stringTransaction hash**gas_price**uint256Gas price in wei (legacy transactions)**max_fee_per_gas**uint256EIP-1559 maximum fee per gas**max_priority_fee_per_gas**uint256EIP-1559 priority fee**gas_limit**uint256Gas limit for transaction**nonce**uint256Sender nonce**input**stringHex-encoded input data (e.g., \"0xa9059cbb...\")**gas_used**uint256Actual gas used (from receipt)**transaction_index**uint64Position in block\nAvailable Transaction Fields (Stellar)\nFieldTypeDescription**hash**stringTransaction hash**ledger**i64Ledger sequence number where the transaction was included**value**i64Value associated with the first relevant operation (e.g., payment amount). Defaults to 0 if no relevant operation or value is found.**from**addressSource account address of the first relevant operation (e.g., payment sender). Case-insensitive comparison.**to**addressDestination account address of the first relevant operation (e.g., payment recipient or invoked contract). Case-insensitive comparison.\nAvailable Transaction Fields (Solana)\nFieldTypeDescription**signature**stringTransaction signature (base58 encoded). Comparisons are case-sensitive.**slot**u64Slot number where the transaction was processed**fee**u64Transaction fee in lamports**is_success**boolWhether the transaction succeeded**fee_payer**pubkeyAddress that paid the transaction fee (first account in account_keys). Only present if defined. Comparisons are case-sensitive.**accounts**stringAll accounts involved in the transaction, including addresses loaded from lookup tables (ALTs). Format: |account1|account2|...| with pipe delimiters. Use accounts contains \"|<address>|\" for exact matching. Comparisons are case-sensitive.\n\nNote: Solana uses base58-encoded addresses which are case-sensitive, unlike EVM hex addresses. Ensure your filter expressions match the exact casing of Solana addresses.\n\nSolana Filtering Examples:\n// Filter transactions by fee payer\n{\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": \"fee_payer == 'TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA'\"\n }\n ]\n}\n\n// Filter transactions involving a specific account\n{\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": \"accounts contains '|JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4|'\"\n }\n ]\n}\n\n// Combine fee payer and account filters\n{\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": \"fee_payer == 'So11111111111111111111111111111111111111112' AND accounts contains '|TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA|'\"\n }\n ]\n}\n\n// Filter transactions with minimum fee threshold\n{\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": \"fee > 5000\"\n }\n ]\n}\nMatching Rules\n\nIf no conditions are specified, all transactions match\nFor multiple condition types:\n\nTransaction conditions are checked first\nThen either function OR event conditions must match\nBoth transaction AND (function OR event) must match if both specified\n\nExpressions\nExpressions allow for condition checking of function arguments, event parameters, and transaction fields.\nSupported Parameter/Field Types and Basic Operations:\nTypeDescriptionExample OperatorsNotes**Numeric (uint/int variants)**Integer values (e.g., 42, -100) or decimal values (e.g., 3.14, -0.5).>, >=, <, <=, ==, !=Numbers must have digits before and after a decimal point if one is present (e.g., .5 or 5. are not valid standalone numbers).**Address**Blockchain addresses.==, !=Comparisons (e.g., from == '0xABC...') are typically case-insensitive regarding the hex characters of the address value itself.**String**Text values. Can be single-quoted (e.g., ’hello') or, on the right-hand side of a comparison, unquoted (e.g., active`).==, !=, starts_with, ends_with, containsQuoted strings support \\' to escape a single quote and \\\\ to escape a backslash. All string comparison operations (e.g., name == 'Alice', description contains 'error') are performed case-insensitively during evaluation. See the dedicated \"String Operations\" section for more examples and details.**Boolean**True or false values.==, !=Represented as true or false. These keywords are parsed case-insensitively (e.g., TRUE, False are also valid in expressions).**Hex String Literal**A string literal starting with 0x or 0X followed by hexadecimal characters (0-9, a-f, A-F).==, !=, starts_with, ends_with, containsTreated as a string for comparison purposes (e.g., input_data starts_with '0xa9059cbb'). Comparison is case-sensitive for the hex characters after 0x.**Array (EVM/Stellar)**Ordered list of items. For Stellar, often a JSON string in config (e.g., ’[\"a\", \"id\":1]'`). For EVM, typically decoded from ABI parameters.contains, ==, !=, [index]Detailed operations, including indexed access and behavior of contains, vary by network. See \"Operations on Complex Types\" below.**Object/Map (Stellar)**Key-value pairs, typically represented as a JSON string in config (e.g., ’\"key\": \"value\", \"id\": 123'`)..key_access, ==, !=Supports dot notation for field access (e.g., data.id). See \"Operations on Complex Types\" for details.**Vec (Stellar)**Ordered list, where the parameter’s value can be a CSV string (e.g., \"foo,bar\") or a JSON array string (e.g., ’[\"foo\",\"bar\"]'`).contains, ==, !=Behavior of contains and == differs based on whether the value is CSV or a JSON array string. See \"Operations on Complex Types\" for details.**Tuple (EVM)**Ordered list represented as a JSON array string (e.g., ’[\"Alice\", 0x1234..., 25, true, [12,34]]'`).contains, ==, !=The contains operation performs a case-insensitive deep search through all tuple elements. == and != perform comparisons against the entire tuple values. See \"Operations on Complex Types\" for details.\nLogical Operators:\n\nAND - All conditions must be true\nOR - At least one condition must be true\n() - Parentheses for grouping\nAND has higher precedence than OR (i.e., AND operations are evaluated before OR operations if not grouped by parentheses)\n\nVariable Naming and Access (Left-hand side of conditions):\nThe left-hand side (LHS) of a condition specifies the data field or parameter whose value you want to evaluate.\nBase Names:\n\nThese are the direct names of parameters or fields, such as amount, from, status, or event parameter indices like 0, 1 (common in Stellar events).\nBase names can consist of alphanumeric characters (a-z, A-Z, 0-9) and underscores (_).\nThey can start with a letter, an underscore, or a digit. Starting with a digit is primarily relevant for numerically indexed parameters (e.g., Stellar event parameters).\nImportant: Variable names are case-sensitive during evaluation. The name used in the expression must exactly match the casing of the field name in the source data (e.g., from an ABI or blockchain data structure). For example, if a field is named TotalValue in the data, an expression using totalvalue will not find it.\nVariable names cannot be keywords (e.g., true, AND, OR, contains). Keywords themselves are parsed case-insensitively.\n\nPath Accessors (for complex types):\nIf a base parameter is a complex type like an object, map, or array, you can access its internal data using accessors:\nKey Access: Use dot notation (.) to access properties of an object or map.\n\nExamples: transaction.value, user.name, data.0 (if 0 is a valid key name as a string).\nKeys typically consist of alphanumeric characters and underscores. They usually start with a letter or underscore, but purely numeric keys (e.g., .0, .123) are also supported for map-like structures where keys might be strings representing numbers.\nKeys cannot contain hyphens (-).\n\nIndex Access: Use bracket notation ([]) to access elements of an array by their zero-based integer index.\n\nExamples: my_array[0], log_entries[3].\nThe index must be a non-negative integer.\n\nCombined Access: You can combine key and index accessors to navigate nested structures.\n\nExample: event.data_array[0].property (accesses the property field of the first object in data_array, which is part of event).\nExample: map.numeric_key_as_string_0[1].name (accesses the name property of the second element of an array stored under the key 0 in map).\n\nString Operations:\nSeveral operators are available for matching patterns and comparing string values. These are particularly useful for EVM transaction input data, Stellar parameters defined with kind: \"string\", or any other field that contains text.\n\nstring_param starts_with 'prefix'::\nChecks if the string parameter’s value begins with the specified prefix.\nExample: transaction.input starts_with '0xa9059cbb' (checks for ERC20 transfer function selector).\nstring_param ends_with 'suffix'::\nChecks if the string parameter’s value ends with the specified suffix.\nExample: file_name ends_with '.txt'\nstring_param contains 'substring'::\nChecks if the string parameter’s value contains the specified substring anywhere within it.\nExample: message contains 'error'\nstring_param == 'exact_string'::\nChecks if the string parameter’s value is exactly equal to exact_string.\nstring_param != 'different_string'::\nChecks if the string parameter’s value is not equal to different_string.\n\nImportant Notes on String Operations:\n\nOperator Keywords: The operator keywords themselves (starts_with, ends_with, contains, AND, OR, true, false, comparison symbols like ==, >) are parsed case-insensitively. For example, CONTAINS is treated the same as contains, and TRUE is the same as true.\nCase-Insensitive Evaluation for String Comparisons: When comparing string data (e.g., from event parameters, transaction fields, or function arguments) with literal string values in your expression, all standard string operations perform a case-insensitive comparison during evaluation.\n\nEquality (==) and Inequality (!=)\nPattern matching (starts_with, ends_with, contains)\n\nVariable Name Case Sensitivity: It is important to distinguish this from variable names (the left-hand side of your condition, e.g., status). Variable names are case-sensitive and must exactly match the field names in your source data (ABI, etc.).\n\nWhitespace Handling:\nFlexible whitespace is generally allowed around operators, parentheses, and keywords for readability. However, whitespace within quoted string literals is significant and preserved.\nOperations on Complex Types\nBeyond simple primitive types, expressions can also interact with more complex data structures like arrays, objects, and vectors.\nEVM Specifics\nArray Operations (kind: \"array\")\nWhen an EVM parameter is an array (often represented internally or configured with kind: \"array\" and its value being a JSON string representation if manually configured), the following operations are supported:\n\narray_param contains 'value' checks if the string ’value'` exists within the array.\narray_param == '[\"raw_json_array_string\"]' string comparison of the array’s entire JSON string representation against the provided string\narray_param != '[\"raw_json_array_string\"]' the negation of the above\narray_param[0] indexed access\n\nTuple Operations (kind: \"tuple\")\n\ntuple_param contains 'value' checks if the string ’value'` exists within the tuple.\ntuple_param == (12, \"hello\", \"testing\", 34) checks if the tuple is equal.\ntuple_param != (12, \"hello\", \"testing\", 34) checks if the tuple is not equal.\n\nWhere tuple_param is the name of tuple param (we should have only one param for tuples).\nNote on Solidity Structs: When working with Solidity smart contracts, struct types are automatically converted to tuples during ABI encoding/decoding. For example, a Solidity struct like:\nstruct User {\n uint256 id;\n string name;\n string email;\n uint256 age;\n}\nWill be represented as a tuple **(12, \"user_name\", \"user_email\", 34)** where the values correspond to the struct fields in their declaration order. This conversion is handled transparently by the Solidity compiler and Web3 libraries, allowing you to use the tuple operations above to work with struct data returned from smart contract calls.\nStellar Specifics\nObject (kind: \"object\") / Map (kind: \"Map\") Operations\n\nobject_param.key == 'value' checks if the object or map has a key named key with the value ’value'`.\nobject_param.nested_key.another_key > 100 checks if the nested key another_key within nested_key has a value greater than 100.\nobject_param == '\"raw_json_object_string\"' checks if the object or map matches the provided JSON string representation.\nobject_param != '\"raw_json_object_string\"' the negation of the above\n\nArray (kind: \"array\") Operations\n\narray_param[index] accesses the element at the specified index in the array.\narray_param[0] == 'value' checks if the first element in the array is equal to ’value'`.\narray_param[1].property == 'value' checks if the second element in the array has a property named property with the value ’value'`.\narray_param contains 'value' checks if the array contains the string ’value'`.\narray_param == '[\"raw_json_array_string\"]' checks if the array matches the provided JSON string representation.\narray_param != '[\"raw_json_array_string\"]' the negation of the above\n\nVector (kind: \"vec\") Operations\nWhen a Stellar parameter has kind: \"vec\", its value can be either a CSV string or a JSON array string.\n\nvec_param contains 'item' checks if the vector contains the string ’item'`. This works for both CSV and JSON array strings.\nvec_param == 'raw_string_value' checks if the vector matches the provided raw string value. This works for both CSV and JSON array strings.\nvec_param != 'raw_string_value' the negation of the above\n\nEvent Parameter Access (Stellar)\nStarting with Stellar Protocol 23, Soroban contracts can include event definitions in their contract specifications. This enables two ways to access event parameters:\nAccess by Name (Protocol 23+):\nWhen a contract specification includes event definitions, you can access event parameters by their defined names:\n\nIf an event has a parameter named recipient (kind: \"Address\"):\n\nrecipient == 'GBBD...ABCD'\n\nIf an event has a parameter named amount (kind: \"U128\"):\n\namount > 1000000\n\nIf an event has a parameter named metadata (kind: \"Map\") containing ’\"id\": 123, \"name\": \"Test\"'`:\n\nmetadata.id == 123\nmetadata.name contains 'test' (case-insensitive)\n\nIf an event has a parameter named items (kind: \"array\") containing ’[\"alpha\", \"beta\"]'`:\n\nitems contains 'beta' (case-insensitive deep search)\n\nAccess by Index (Legacy):\nFor contracts without event definitions in their specification, or when working with older contracts, event parameters can be accessed by their numeric index (e.g., 0, 1, 2):\n\nIf event parameter 0 (kind: \"Map\") is ’\"id\": 123, \"name\": \"Test\"'`:\n\n0.id == 123\n0.name contains 'est' (case-insensitive)\n\nIf event parameter 1 (kind: \"array\") is ’[\"alpha\", \"val\": \"beta\"]'`:\n\n1[0] == 'ALPHA' (case-insensitive)\n1[1].val == 'Beta' (case-insensitive)\n1 contains 'beta' (case-insensitive deep search)\n\nNamed access is recommended when available as it makes expressions more readable and maintainable. The monitor will automatically use named parameters if they’re available in the contract specification, otherwise it falls back to indexed access.\nEVM Examples\nThese examples assume common EVM event parameters or transaction fields.\nBasic Comparisons\n// Numeric\n\"transaction.value > 1000000000000000000\" // Value greater than 1 ETH\n\"event.amount <= 500\"\n\"block.number == 12345678\"\n\n// String (case-insensitive evaluation for '==' and 'contains')\n\"transaction.to == '0xdeadbeef...'\" // Address check (address value comparison itself is case-insensitive)\n\"event.token_name == 'mytoken'\"\n\"transaction.input contains 'a9059cbb'\" // Checks for ERC20 transfer selector\n\n// Boolean\n\"receipt.status == true\" // or simply \"receipt.status\" if boolean field can be evaluated directly\n\"event.isFinalized == false\"\nLogical Operators\n\"transaction.value > 1000 AND event.type == 'Deposit'\"\n\"(receipt.status == true OR event.fallback_triggered == true) AND user.is_whitelisted == false\"\nString Operations\n\"transaction.input starts_with '0xa9059cbb'\" // Case-insensitive for the operation\n\"event.message ends_with 'failed'\"\n\"event.details contains 'critical alert'\"\nArray Operations\nAssume event.ids is [10, 20, 30] and event.participants is [\"user\": \"Alice\", \"role\": \"admin\", \"user\": \"Bob\", \"role\": \"editor\"].\n\"event.ids[0] == 10\"\n\"event.ids contains '20'\" // Checks for string '20' (case-insensitive)\n\n\"event.participants contains 'Alice'\" // True (deep search, case-insensitive)\n\"event.participants contains 'editor'\" // True (deep search, case-insensitive)\n\"event.participants == '[{\\\"user\\\": \\\"Alice\\\", \\\"role\\\": \\\"admin\\\"}, {\\\"user\\\": \\\"Bob\\\", \\\"role\\\": \\\"editor\\\"}]'\" // Raw JSON match (case-sensitive for structure and keys)\nStellar Examples\nBasic Comparisons\n// Numeric\n\"event.params.amount > 10000000\" // Accessing 'amount' field in an object 'params'\n\"ledger.sequence >= 123456\"\n\n// String (case-insensitive evaluation for '==' and 'contains')\n\"event.params.recipient == 'GBD22...'\" // Address check\n\"event.type == 'payment_processed'\"\n\n// Boolean\n\"transaction.successful == true\"\n\"event.data.is_verified == false\"\nLogical Operators\n\"event.data.value > 500 AND event.source_account == 'GCA7Z...'\"\n\"(event.type == 'TRANSFER' OR event.type == 'PAYMENT') AND event.params.asset_code == 'XLM'\"\nString Operations\n\"event.contract_id starts_with 'CA23...'\"\n\"event.memo ends_with '_TEST'\"\n\"event.params.description contains 'urgent'\"\nObject (kind: \"object\") / Map (kind: \"Map\") Operations\nAssume event.details (kind: \"Map\") is ’\"id\": 123, \"user\": \"name\": \"CHarlie\", \"status\": \"Active\", \"tags\": [\"new\"]'`.\n\"event.details.id == 123\"\n\"event.details.user.name == 'charlie'\" // Case-insensitive string comparison\n\"event.details.user.status contains 'act'\" // Case-insensitive contains\n\"event.details.tags == '[\\\"new\\\"]'\" // Raw JSON string match for the 'tags' field\nArray (kind: \"array\") Operations\nAssume event.items (kind: \"array\") is ’[\"sku\": \"A1\", \"qty\": 10, \"sku\": \"B2\", \"qty\": 5, \"notes\":\"Rush order\"]'`.\n\"event.items[0].sku == 'a1'\"\n\"event.items[1].qty < 10\"\n\"event.items contains 'A1'\" // Deep search (case-insensitive)\n\"event.items contains 'rush order'\" // Deep search (case-insensitive)\nVector (kind: \"vec\") Operations\nAssume csv_data (kind: \"vec\") is \"ALPHA,Bravo,Charlie\" and json_array_data (kind: \"vec\") is ’[\"Delta\", \"id\": \"ECHO\", \"Foxtrot\"]'`.\n\"csv_data contains 'bravo'\" // Case-insensitive CSV element match\n\"csv_data == 'ALPHA,Bravo,Charlie'\" // Raw string match\n\n\"json_array_data contains 'delta'\" // Case-insensitive deep search (like array)\n\"json_array_data contains 'ECHO'\" // Case-insensitive deep search (like array)\nEvent Parameter Access (Numerically Indexed)\nAssume event parameter 0 is 12345 (u64), 1 (kind: \"array\") is ’[\"Val1\", \"VAL2\"]', and 2 (kind: \"Map\") is ’\"keyA\": \"dataX\", \"keyB\": 789'.\n\"0 > 10000\"\n\"1[0] == 'val1'\"\n\"1 contains 'val2'\"\n\"2.keyA == 'DATAX'\"\n\"2.keyB < 1000\"\nNow, after Stellar Protocol 23 we can access to Event parameters by name (first, make sure the contract supports the feature)\n\"0 > 10000\"\n\"param_name[0] == 'val1'\"\n\"param_name contains 'val2'\"\n\"param_name.keyA == 'DATAX'\"\n\"param_name.keyB < 1000\"\nWith SEP-48 support, Stellar functions can now reference parameters by name (e.g., amount > 1000) instead of position (e.g., 2 > 1000). Events still use indexed parameters until SEP-48 support is added for events.You can find the contract specification through Stellar contract explorer tool. For example:\nStellar DEX Contract Interface\nTrigger Conditions (Custom filters)\nCustom filters allow you to create sophisticated filtering logic for processing monitor matches. These filters act as additional validation layers that determine whether a match should trigger the execution of a trigger or not.\nFor more information about custom scripts, see Custom Scripts Section.\nSecurity Risk: Only run scripts that you trust and fully understand. Malicious scripts can harm your system or expose sensitive data. Always review script contents and verify their source before execution.\nExample Trigger Conditions Configuration\n{\n \"script_path\": \"./config/filters/evm_filter_block_number.sh\",\n \"language\": \"Bash\",\n \"arguments\": [\"--verbose\"],\n \"timeout_ms\": 1000\n}\nAvailable Fields\nTrigger Conditions Fields\nFieldTypeDescription**script_path**StringThe path to the script**language**StringThe language of the script**arguments**Array[String]The arguments of the script (optional).**timeout_ms**NumberThe timeout of the script is important to avoid infinite loops during the execution. If the script takes longer than the timeout, it will be killed and the match will be included by default.\nImportant Considerations\n\nNetwork slugs in the monitor must match valid network configurations.\nTrigger IDs must match configured triggers.\nExpression syntax and available variables differ between EVM and Stellar networks.\nABIs can be provided in two ways:\n\nFor EVM networks: Through the monitor configuration using standard Ethereum ABI format\nFor Stellar networks: Through the monitor configuration using SEP-48 format, or automatically fetched from the chain if not provided\n\nThe monitoring frequency is controlled by the network’s cron_schedule.\nEach monitor can watch multiple networks and addresses simultaneously.\nMonitors can be paused without removing their configuration.\n\nRunning the Monitor\nLocal Execution\n\nBasic startup:\n./openzeppelin-monitor\n\nWith logging to file:\n./openzeppelin-monitor --log-file\n\nWith metrics enabled:\n./openzeppelin-monitor --metrics\n\nValidate configuration without starting:\n./openzeppelin-monitor --check\n\nDocker Execution\n\nStart all services:\ncargo make docker-compose-up\n\nWith metrics and monitoring (Prometheus + Grafana):\n# Set METRICS_ENABLED=true in .env file, then:\ndocker compose --profile metrics up -d\n\nView logs:\ndocker compose logs -f monitor\n\nStop services:\ncargo make docker-compose-down\n\nCommand Line Options\nOptionDefaultDescription--log-filefalseWrite logs to file instead of stdout--log-levelinfoSet log level (trace, debug, info, warn, error)--metricsfalseEnable metrics server on port 8081--checkfalseValidate configuration files only--help-Show all available options\nTesting your configuration\nNetwork Configuration\nThe validate_network_config.sh script helps ensure your network configuration is properly set up and operational. The script:\n\nTests the health of all configured RPC endpoints\nValidates connectivity using network-specific methods\nProvides clear visual feedback for each endpoint\n\n# Test default networks directory (/config/networks/)\n./scripts/validate_network_config.sh\n\n# Test a specific configuration directory\n./scripts/validate_network_config.sh -f /path/to/configs\nRun this script when setting up new networks, before deploying configuration changes, or when troubleshooting connectivity issues.\nValidating Configuration Files\nBefore starting the monitor service, you can validate your configuration files using the --check option:\n./openzeppelin-monitor --check\nThis command will:\n\nParse and validate all configuration files\nCheck for syntax errors\nVerify references between monitors, networks, and triggers\nReport any issues without starting the service\n\nIt’s recommended to run this check after making changes to any configuration files.\nMonitor Configuration\nThe monitor can be tested in two modes:\n1. Latest Block Mode\nThis mode processes the most recent blocks across all configured networks.\n./openzeppelin-monitor --monitor-path=\"config/monitors/evm_transfer_usdc.json\"\nWhat this does:\n\nRuns the \"Large Transfer of USDC Token\" monitor\nTargets all networks specified in the configuration\nProcesses only the latest block for each network\nSends a notification to all associated channels for every match that is found\n\n2. Specific Block Mode\nThis mode allows you to analyze a particular block on a specific network, which is useful for debugging specific transactions, verifying monitor behavior on known events, and testing monitor performance on historical data.\n./openzeppelin-monitor \\\n --monitor-path=\"config/monitors/evm_transfer_usdc.json\" \\\n --network=ethereum_mainnet \\\n --block=12345678\nWhat this does:\n\nRuns the \"Large Transfer of USDC Token\" monitor\nTargets only the specified network (ethereum_mainnet)\nProcesses only the specified block (12345678)\nSends a notification to all associated channels for every match that is found\n\nSpecific Block Mode requires both parameters:\n--network: The network to analyze\n--block: The block number to process\n\nData Persistence (Optional)\n\nSet LOG_MODE as file will persist the log data in logs/ on host. To change it to a different directory use LOG_DATA_DIR.\nSet MONITOR_DATA_DIR to specific dir on your host system which will persist data between container restarts.\n\nError Handling\nThe monitor implements a comprehensive error handling system with rich context and tracing capabilities. For detailed information about error handling, see Error Handling Guide.\nImportant Considerations\nPerformance Considerations\n\nMonitor performance depends on network congestion and RPC endpoint reliability.\n\nView the list of RPC calls made by the monitor.\n\nThe max_past_blocks configuration is critical:\n\nCalculate as: (cron_interval_ms/block_time_ms) + confirmation_blocks + 1 (defaults to this calculation if not specified).\nExample for 1-minute Ethereum cron: (60000/12000) + 12 + 1 = 18 blocks.\nToo low settings may result in missed blocks.\n\nTrigger conditions are executed sequentially based on their position in the trigger conditions array. Proper execution also depends on the number of available file descriptors on your system. To ensure optimal performance, it is recommended to increase the limit for open file descriptors to at least 2048 o","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791259593804,"hash":"b9217c88d68a5a639d548e5cc80313adc0f4cd2c"}
{"url":"https://docs.pyth.network/entropy","domain":"docs.pyth.network","title":"Entropy | Pyth Developer Hub","text":"EntropySecure, Verifiable Random Number Generator for EVM-based smart contractsPyth Entropy is an on-chain random number generator (RNG) designed for developers who need fair, unbiased, and cryptographically secure randomness.\nWhether you're building a blockchain game, NFT mint, lottery, or simulation, Entropy delivers randomness that is:\n\nTrustless & verifiable - built on commit-reveal protocol.\nLow-latency - randomness available within a few blocks.\nEasy to use - get started in < 5 minutes, no registration required.\nCost-efficient - designed for scalable production use fees.\nNative gas fees - pay with chain native token.\n\nWhat's New in Entropy v2\nEntropy v2 introduces several improvements and new features to make random number generation more flexible and efficient.\nSee What's New in Entropy v2 for more details.\nStart Building\nQuickstart GuideHow-to guide for reading fees and requesting randomness on EVM.Chainlist and Fee DetailsFind Entropy addresses, reveal delays, gas limits, and fees.Pyth EntropyProtocol DesignUnderstanding how Pyth Entropy generates secure random numbers.Entropy ExplorerInteractive tool to diagnose callback issues on-chain.What's New in Entropy v2New features and improvements in Entropy v2","tokens":308,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259596187,"hash":"6b9c45c0b5f4533e43e3769202e7f044ff3f0eb4"}
{"url":"https://docs.pyth.network/entropy/protocol-design","domain":"docs.pyth.network","title":"Protocol Design | Pyth Developer Hub","text":"Protocol DesignUnderstanding how Pyth Entropy generates secure random numbersThe Entropy protocol implements a secure 2-party random number generation procedure. The protocol\nis an extension of a simple commit/reveal protocol. The original version has the following steps:\n\nTwo parties A and B each randomly sample secret contributions to the random number, (xA)(x_A) and (xB)(x_B).\nA commits to their number by sharing (hA)=hash(xA).(h_A) = hash(x_A).\nB reveals xBx_B\nA reveals xAx_A\nB verifies that hash(xA)==hAhash(x_{A}) == h_A\nThe random number r=hash(xA,xB)r = hash(x_A, x_B)\n\nThis protocol has the property that the result is random as long as either A or B are honest.\nHonesty means that (1) they draw their value at random, and (2) for A, they keep (xA)(x_A) a secret until\nstep 4. Thus, neither party needs to trust the other -- as long as they are themselves honest, they can\nensure that the result (r)(r) is random.\n\nEntropy implements a version of this protocol that is optimized for on-chain usage. The\nkey difference is that one of the participants (the provider) commits to a sequence of random numbers\nup-front using a hash chain. Users of the protocol then simply grab the next random number in the sequence.\nSetup: The provider PP computes a sequence of NN random numbers, xix_i for 0≤i≤N−10 \\leq i \\leq N-1:\n\nxN−1=random()x_{N-1} = random()\nxi=hash(xi+1)x_i = hash(x_{i + 1})\n\nThe provider commits to x0x_0 by posting it to the Entropy contract.\nEach random number in the sequence can then be verified against the previous one in the sequence by hashing it, i.e., hash(xi)=xi−1hash(x_i) = x_{i - 1}\nRequest: To produce a random number, the following steps occur.\n\nThe user randomly samples their contribution (xU)(x_U) and submits it to the contract.\n(Users may also run this step using an on-chain PRNG if they trust the validator to not collude with the provider.)\nThe contract remembers (xU)(x_U) and assigns it an incrementing sequence number (i)(i), representing which\nof the provider's random numbers the user will receive.\nAfter sufficient block confirmations, the provider submits a transaction to the contract revealing their contribution (xi)(x_i) to the contract.\nThe contract verifies hash(xi)==xi−1hash(x_i) == x_{i-1} to prove that (xi)(x_i) is the (i)(i)'th random number.\nThe contract stores (xi)(x_i) as the (i)(i)'th random number to reuse for future verifications.\nIf the condition above is satisfied, the random number (r)=hash(xi,xU)(r) = hash(x_i, x_U).\nThe contract submits a callback to the calling contract with the random number (r)(r).\n\nThis flow is secure as long as several trust assumptions hold:\n\nProviders are trusted to reveal their random number (xi)(x_i) regardless of what the final result (r)(r) is. Providers can compute (r)(r) off-chain before they reveal (xi)(x_i), which permits a censorship attack.\nProviders are trusted not to front-run user transactions (via the mempool or colluding with the validator). Providers who observe user transactions can manipulate the result by inserting additional reuests or rotating their commitment.\nProviders are trusted not to keep their hash chain a secret. Anyone with the hash chain can predict the result of a randomness request before it is requested,\nand therefore manipulate the result. This applies both to users of the protocol as well as blockchain validators who can use this information to manipulate the on-chain PRNG or reorder user transactions.\n\nThe code of default deployed provider can be found here.Error CodesOn chain error codes from the Pyth Entropy EVM contractsFeesUnderstanding Pyth Entropy fee structure","tokens":907,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259618034,"hash":"1628ed6ae39d3bbf6a765d40f50d5526beb99da7"}
{"url":"https://io.net/docs/guides/clouds/monitor-manage-clusters","domain":"io.net","title":"Monitor & Manage Clusters - io.net","text":"To access the dashboard, log into io.net and select Manager Clusters.\n​View Your Cluster\nTo see all the details about your cluster, click on it in the Cluster tab. The screenshot below highlights what you can expect to see in a hired, active cluster.\n\n​Clusters Tab\nThe Clusters tab provides a quick overview of all your clusters, both active and inactive.\n​Sort Clusters\nUse the sorting options to find the cluster you’re looking for easily. Sort by status (Running, Completed, Failed, Destroyed) or search by keyword.\n\n​Cluster Management Actions\nThese actions can be done if a cluster is currently running.\n​Terminate Cluster\nClick Terminate Cluster in the bottom right to end your session.\n\n​Extend Cluster\nTo keep your cluster active for longer, simply click Extend Cluster. You’ll be charged the same amount as your original transaction.\n\n​Actions\nA completed cluster provides the option to archive the cluster. Click Archive in the bottom right to archive this cluster.\nRun Jobs and Monitor Your Cluster\nReady to start working on your cluster? You can run your jobs using either Visual Studio or Jupyter Notebook. The Ray Dashboard lets you manage and monitor everything, including your cluster and running jobs.\nOn your cluster’s details page, grab the IDE Password, and then click on Jupyter Notebook, Visual Studio, or the Ray Dashboard to get started\n\nTo access your application, enter the IDE Password.\nOnce your cluster’s time expires, you’ll lose access to the IDEs and the Ray Dashboard.\n​Archive a Cluster\nOnce a cluster is complete, you can archive it. Click Archive at the bottom right to archive a cluster.\n\n🚧 You can’t renew a cluster after it’s completed.\n\n​Cluster Information\nClick on a cluster in the Cluster tab to view the details associated with the cluster. In the screenshot below, a completed cluster has been selected.\n\n​Monitor the following on the right:\nActionDescriptionCompute HoursShows how long a single instance has been running and consuming resources. Includes “Served” and “Remaining” times.Funds Used or RefundedThe amount you’ve spent or had refunded for cluster operations.Connectivity TierYour chosen level of connectivity for the cluster (download / upload speeds).Security ComplianceThe selected security setting (e.g. end-to-end encryption).LocationsGeographic location(s) where your GPUs are located.\n\n​Monitor the following on the left:\nActionDefinitionAll WorkersAllows you to filter the view by selecting different groups of workers. This option is currently set to show all workers in the cluster.[#] WorkersIndicates that the dashboard currently shows four workers in the cluster that are active or relevant to the task being monitored. The panel below labels these workers as “IO Worker 1,” “IO Worker 2,” and so on.[#] GPUsShows that there are 4 GPUs (Graphics Processing Units) in use across the cluster. Each worker seems to have one GPU assigned to it, as indicated by the details in each worker’s panel.SearchThe search bar allows you to quickly find specific workers, GPUs, or tasks by searching based on keywords, worker names, device IDs, or other identifiers.\n​Detailed information for each worker\nFeatureDescriptionDecentralized NetworkIO Cloud uses a network of computers (called “IO workers”) to create powerful GPU clusters. This means you’re not relying on a single company for your computing power.Self-healingIf one part of the cluster has issues, the others automatically take over, keeping your projects running smoothly.Easy to UseYou can easily run your AI projects using Python code, just like on any other cloud platform.Built on Industry-leading TechnologyIO Cloud is powered by the same technology used by OpenAI to train its powerful AI models, such as GPT-3 and GPT-4.\n\n​Selecting a worker shows you the following\nFeatureDescriptionWorker Name and StatusIndicates the worker’s status, such as Completed, Running, Pending, or Failed. A green dot signifies successful completion.Device IDThe unique identifier for the specific GPU device in the worker node.GPU InformationGeForce RTX 3060 Ti (GPU type): Each worker is equipped with an NVIDIA GeForce RTX 3060 Ti GPU. x1: Number of GPUs utilized (in this case, one unit). Uptime in Cluster: Displays uptime, showing that the worker has been fully operational without downtime for the monitored period.Activity Consistency Status BarA visual representation of the worker’s uptime, consisting of 10 white squares filled in to indicate 100% uptime.\nWas this page helpful?","tokens":1125,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259623232,"hash":"b5cee013f79d0386fee0bb8bca2e72ae25588454"}
{"url":"https://gov.optimism.io/t/shutterized-optimism-an-encrypted-mempool-for-the-op-stack/6387","domain":"gov.optimism.io","title":"Shutterized Optimism – An Encrypted Mempool for the OP Stack - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack \n\n Proposals 📃Technical Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 13\n min\n\n Jul 2023\n\n 1 / 5\n\n Jul 2023\n\n Jul 2023\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori\nExecutive Summary\nThis document serves as a requirements and technical architecture document for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, capitalizing on the capabilities of the Shutter Network. The mechanism targets the reduction of front-running and MEV-related exploits in the Ethereum DeFi ecosystem by adopting a shielded mempool using threshold encryption.\nBy integrating this mechanism, we foresee OP Stack-based rollups becoming more secure and efficient layers, attracting safer trading for DeFi users, more robust censorship resistance, and increased profitability. Moreover, the sequencer operators will be able to claim immunity from front-running and censoring transactions by design, while retaining their ability to collect and/or distribute back-running related MEV.\nDecentralized Sequencer and MEVA designs are largely orthogonal to this proposal and complement it well.\nTable of Contents\n\nExecutive Summary\nTable of Contents\nIntroduction and Goals\n3.1. Problem Statement\n3.1.1. Malicious MEV and Censorship\n3.1.2. MEV and Censorship on Layer 2 (L2)\n3.1.3. Regulatory Implications\n3.2. MEV mitigation solutions overview\n3.3. OP Stack\n3.4 Shutter Network\nParticipant Requirements\n4.1 End User\n4.2 Dapp Project\n4.3 Optimism Rollup Node\n4.4 Optimism Sequencer\n5 Component Requirements\n5.1 Functional Requirements\n5.1.1 Optimism Rollup Node\n5.1.2 Optimism Sequencer Node\n5.1.3 Keyper\n5.1.4 Front End Library\n5.2 Non-functional Requirements\nTechnical Architecture of Shutterized Optimism\n6.1 Overview\n6.2 Components\n6.2.1 Keyper Set\n6.2.2 Sequencer\n6.2.3 System Contracts\n6.2.4 Client Library\n6.3 Code Modifications\n6.3.1 Shutter Inbox Contract\n6.3.2 Keyper Set Contract\n6.3.3 Key Broadcast Contract\n6.3.4 Engine API\n6.3.5 op-node\n6.3.6 op-geth\n6.4 User Interaction\n6.5 Interaction With Decentralized Sequencers\n6.6 Finality Assumption\n6.7 Potential Issues and Solutions\n6.7.1 Liveness Failures\n6.7.2 Latency\n6.7.3 Sequencer Side-Channel Attack\nDesign Options\n7.1 Block or Transaction Keys\nFuture Considerations\nConclusion\n\nIntroduction and Goals\nThis document presents requirements and an architecture proposal for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network. The mechanism aims to provide front-running protection using an encrypted/shielded mempool and threshold encryption, as proposed in Shutter Network’s Optimism Governance Forum post.\nWe think by adopting this mechanism, OP Stack-based rollups become better, more neutral base layers and can gain the following benefits:\n\nSafer trading for DEFI users (no front-running)\nAdded censorship resistance (even for centralized sequencers)\nMore profitable trading for DEFI users (because less value lost due to malicious MEV)\nSequencer can plausibly argue that they no longer have the ability to front-run transactions nor censor transactions based on their content by design (potential compliance, image and regulatory benefits for the sequencer operator)\nSequencer still retains the ability to collect or distribute back-running related MEV (arbitrage and liquidations)\n\nThis document begins with a goals/motivation section, then presents a two-phase process for defining the architecture of a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network.\nThe process starts with Phase 1, where high-level, solution-agnostic requirements for the mechanism are defined. This phase is primarily driven by the perspectives and needs of the end users and the sequencer, with requirements categorized by actors in the system.\nFollowing this, Phase 2 transitions to defining Shutter-specific requirements, focusing more on the details of the proposed implementation. These requirements are categorized by expected technical components in the system.\nIt then outlines the user interaction with the system, followed by the core of the document, the technical architecture section. Within this section, the technical components and code modifications are outlined, a transaction flow diagram is given, among other things.\nThe document closes with a conclusion and future considerations.\nProblem Statement\nThe rising popularity of Ethereum’s open finance (DeFi) ecosystem has led to an increasing amount of maximal extractable value (MEV). Unfortunately, it has also exposed the network to potential exploitation through front-running and other MEV-related tactics, which can deter prospective investors and traders. Furthermore, the measures put in place to manage this issue have proven to be suboptimal, introducing unnecessary trust assumptions and centralization factors. For instance, MEV relays, though beneficial for market health, require a high degree of trust, making them unsustainable in their current form. To unlock the billions in side-lined investment and ensure Ethereum’s long-term base layer neutrality, an effective approach to transaction ordering and inclusion is required.\nMalicious MEV and Censorship\nFront-running and malicious MEV extraction pose significant threats to Ethereum’s ecosystem. Front-running involves the unethical practice of a broker executing orders on a security for its own account while taking advantage of advance knowledge of pending orders from its customers. On Ethereum, this has resulted in a measurable amount of value extraction from users. MEV relays, which were introduced as a solution, unfortunately introduce centralization risks due to the required high degree of trust.\nThis tendency to centralize parts of the transaction supply chain infrastructure not only adds censorship vectors but also facilitates actual censorship on the protocol level, as evidenced by instances of adherence to sanctions lists such as the Office of Foreign Assets Control (OFAC) list.\nMEV and Censorship on Layer 2 (L2)\nLayer 2 solutions, which aim to scale Ethereum’s network by processing transactions off the main blockchain, face a similar yet distinct set of challenges. Here, the problem lies in the private mempools and potential spamming issues. Currently, rollup sequencers — responsible for collecting and submitting transactions on L2 — are trusted not to extract MEV. However, this centralized approach could potentially amplify the MEV issue in the long term. To avoid front-running, we place our trust in the sequencer, inadvertently consolidating their power, thus creating an unsustainable and censorship susceptible system.\nRegulatory Implications\nThe regulatory landscape poses another challenge. Regulatory bodies worldwide have begun to clamp down on front-running, potentially categorizing sequencers who extract malicious MEV as financial intermediaries, rather than purely technical entities. This could complicate compliance, as financial intermediaries are subjected to stringent regulatory requirements. Consequently, without proper management of MEV, Ethereum could face stricter regulations, deterring users and stifling growth in the DeFi sector.\nMEV mitigation solutions overview\n\nProposer Builder Separation (PBS): Proposer-builder separation (PBS) is a proposed upgrade for Ethereum that divides the tasks of creating and broadcasting blocks between multiple validators, enhancing censorship resistance, preventing hobbyist validators from being outcompeted by institutional players, and aiding Ethereum’s scalability; it also reconfigures the economics of maximum extractable value (MEV), allowing any validator to benefit from sophisticated MEV extraction performed by block builders.\nMEV Auctions (Optimism MEVA): Optimism MEVA is a proposal for an auction-based system where proposers bid for the right to order transactions within a block, reducing the potential for MEV extraction.\nMEV Revenue Sharing Approaches: These approaches involve mechanisms that redistribute MEV to various stakeholders, thus diminishing the potential profits from malicious extraction.\nTrust in Sequencer or MEV Relay to Not Front-run: This approach depends on the trustworthiness of a sequencer or MEV relay to act in the best interests of users and not engage in front-running.\nEncrypted Mempools: Encrypted mempools are a way to hide transaction information until it is included in a block, preventing front-running and other MEV extraction tactics.\n\nSolution Comparison Table\n\nSolution\nReduces or Redistributes MEV?\nTrust Requirement\n\nProposer Builder Separation (PBS)\nRedistributes\nSeparates trust requirements\n\nMEV Auctions (e.g. Optimism MEVA)\nRedistributes\nDepends on specific implementation\n\nMEV Revenue Sharing Approaches\nRedistributes\nUsually introduces additional trust requirements\n\nTrust in Sequencer or MEV Relay to Not Front-run\nReduces\nIntroduces additional trust requirements\n\nEncrypted Mempools\nReduces\nReduces trust requirements\n\nIn conclusion, a comprehensive solution to the MEV problem may involve a combination of multiple strategies. For instance, encrypted mempools could be used to significantly reduce malicious MEV, and then redistribution frameworks such as Optimism MEVA could be applied to manage the remaining MEV. The goal is to balance the need for trust with the potential to reduce or redistribute MEV effectively.\nOP Stack\nThe OP Stack, managed by the Optimism Collective, is a standardized, shared, and open-source development stack that fuels Optimism. Currently powering the Optimism Mainnet, it’s expected to evolve and shape the Optimism Superchain and its governance. Its design promotes a shared, high-quality system for creating new L2 blockchains, minimizing the need for siloed software development.\nThe “Optimism Bedrock” is the latest iteration of the OP Stack, providing tools to launch production-quality Optimistic Rollup blockchains. It’s designed to support the Optimism Superchain, a proposed network of L2s that share security, communication layers, and a common development stack.\nAs an evolving concept, the OP Stack will grow and adapt with Optimism, aiming to simplify the deployment of new L2 Rollups and foster interoperability among different chains within the Superchain ecosystem. For those interested, resources are available to explore the OP Stack further and launch a Superchain-ready L2.\nShutter Network\nShutter is an anti-frontrunning, malicious MEV-preventing protocol using threshold encryption. It’s intended to be used as a plugin by any L1/L2 protocol to provide front-running and censorship resistance via implementing a shielded/encrypted mempool.\nShutter incorporates a Distributed Key Generation (DKG) scheme into an L1 or L2 rollup sequencer mechanism to protect all dapps deployed on the rollup by default while also improving censorship resistance and potentially latency properties. In principle, it operates by making the sequencer accept encrypted transactions in their blocks and revealing and executing them only once they are ordered.\n\n read \n\n 13\n min\n\n post by Jannik on Jul 5, 2023\n\n post by Jannik on Jul 5, 2023\n\n post by Jannik on Jul 5, 2023\n\n post by Jannik on Jul 5, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP as an MEV staking token\n\n ✨ General\n\n Hi everyone, I wanted to make an alternate proposal than Enabling $OP as a gas token on Optimism Network!. This is an approach which mirrors PoS as well as Fuel Labs. \nThis is not a token price scheme, please read the fu…\n\n read more\n\n 13\n\n 3.8k\n\n Aug 2022\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved\n\n Metagovernance\n\n Optimism is experiencing rapid growth, but this is a double-edged sword. Currently, Optimism is a centrally operated network where, as far as I’m aware, unknown entities across Optimism Foundation, OP Labs or associates …\n\n read more\n\n 26\n\n 5.5k\n\n Dec 2022\n\n Infrastructure & Dependencies nominations for RPGF2\n\n Retro Funding Missions\n\n round-2\n\n Infrastructure & Dependencies nominations for RetroPGF2\nThis is the thread to nominate projects for the Infrastructure and dependencies category of RetroPGF round 2. Please familiarize yourself with the Nominations proce…\n\n read more\n\n 120\n\n 12.7k\n\n Jan 2023","tokens":3355,"squid":"ink-governance","role":"Council Listener","at":1791259625188,"hash":"8b7cb1da0f472179db39887a8cad4a12d40077e6"}
{"url":"https://aave.com/docs/aave-v3/aptos/smart-contracts/pool","domain":"aave.com","title":"Pool | Aave Protocol Documentation","text":"Pool#\nReference for the aave-pool Move package.\nOverview#\nThe pool module maintains the state of reserves, user configurations, and protocol-wide settings. It doesn't directly expose public entry functions for users to interact with. Instead, it provides view functions and friend-accessible functions that other modules use to implement protocol features like supplying, borrowing, repaying, and liquidations.\nKey View Functions#\nget_reserve_data#\n#[view]public fun get_reserve_data(asset: address): Object<ReserveData>\nReturns the state and configuration of a specific reserve. This includes information such as liquidity index, borrow rates, token addresses, and other reserve-specific parameters.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nget_user_configuration#\n#[view]public fun get_user_configuration(user: address): UserConfigurationMap\nReturns the configuration of a user across all reserves, indicating which assets they are using as collateral and which they have borrowed.\nInput Parameters:\nNameTypeDescriptionuseraddressThe user address\nget_reserve_normalized_income#\n#[view]public fun get_reserve_normalized_income(asset: address): u256\nReturns the ongoing normalized income for the reserve. A value of 1e27 means there is no income. As time passes, the yield is accrued.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nget_reserve_normalized_variable_debt#\n#[view]public fun get_reserve_normalized_variable_debt(asset: address): u256\nReturns the normalized variable debt per unit of asset. A value of 1e27 means there is no debt. As time passes, the debt is accrued.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nget_user_account_data#\n#[view]public fun get_user_account_data( user: address): (u256, u256, u256, u256, u256, u256)\nReturns the user account data across all reserves, including total collateral, total debt, available borrows, liquidation threshold, LTV, and health factor.\nInput Parameters:\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:\nPositionTypeDescription0u256Total collateral in base currency1u256Total debt in base currency2u256Available borrows in base currency3u256Current liquidation threshold4u256Loan to value ratio5u256Health factor\nget_reserve_configuration#\n#[view]public fun get_reserve_configuration(asset: address): &ReserveConfigurationMap\nReturns the configuration of a reserve, including parameters like LTV, liquidation threshold, borrowing enabled flags, etc.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nget_reserves_list#\n#[view]public fun get_reserves_list(): vector<address>\nReturns the list of the underlying assets of all initialized reserves.\nget_user_emode#\n#[view]public fun get_user_emode(user: address): u8\nReturns the efficiency mode (eMode) category that the user is using. A value of 0 indicates the user is not in any eMode category.\nInput Parameters:\nNameTypeDescriptionuseraddressThe address of the user\nget_reserve_address_by_id#\n#[view]public fun get_reserve_address_by_id(id: u256): address\nReturns the address of the reserve corresponding to a given ID.\nInput Parameters:\nNameTypeDescriptionidu256The ID of the reserve in the reserves list\nProtocol Configuration View Functions#\n#[view]public fun get_flashloan_premium_total(): u128\n#[view]public fun get_flashloan_premium_to_protocol(): u128\n#[view]public fun max_number_reserves(): u16\nThese functions return various protocol-wide configuration parameters:\nThe total flashloan premium percentageThe portion of flashloan premium that goes to the protocolThe maximum number of reserves supported by the pool\nInternal State Management#\nWhile not directly accessible to users, the pool module contains friend-accessible functions that other modules use to implement protocol features:\nReserve initialization and configurationInterest rate updatesLiquidity and debt managementCollateral managementHealth factor calculationsE-Mode operationsIsolation mode operationsFlash loan handling\nKey Differences from Solidity Implementation#\nThe Move implementation differs from the Solidity version in several ways:\n\nSeparation of Concerns: The Move implementation separates data storage (in the pool module) from business logic (in modules like supply_logic, borrow_logic, etc.)\n\nNo Direct User Entry Points: Users interact with the protocol through other modules that have friend access to the pool module\n\nResource-Oriented Design: The Move implementation leverages Move's resource model for safer asset management\n\nStreamlined Interest Rate Strategy: The interest rate calculation still follows the utilization-based approach where:\n\nInterest rates increase as utilization increases\n\nThere are optimal utilization points and slope parameters\n\nBut the implementation only needs to track and update variable rate indices\n\nNative Token Integration: The implementation is designed to work with Aptos's native token model\n\nThis architecture provides strong safety guarantees while maintaining the core functionality of the Aave protocol, adapted for the Move language and Aptos blockchain environment.\nPool Data Provider View Functions#\nThe pool_data_provider module in Aave's Move implementation serves as a utility contract to collect and pre-process information from the Pool. This module contains methods for querying token addresses, reserve data, and other protocol information, similar to the AaveProtocolDataProvider in the Solidity implementation.\nget_all_reserves_tokens#\n#[view]public fun get_all_reserves_tokens(): vector<TokenData>\nReturns a list of the existing reserves in the pool, pairs include the symbols and token addresses.\nReturn Values:\nTypeDescriptionvector<TokenData>The list of reserves, pairs of symbols and addresses\nThe TokenData struct is composed of the following fields:\nNameTypeDescriptionsymbolStringThe symbol of the underlying reserve assettoken_addressaddressThe address of the underlying reserve asset\nget_all_a_tokens#\n#[view]public fun get_all_a_tokens(): vector<TokenData>\nReturns a list of the existing ATokens in the pool, pairs include the symbols and token addresses.\nReturn Values:\nTypeDescriptionvector<TokenData>The list of ATokens, pairs of symbols and addresses\nThe TokenData struct is composed of the following fields:\nNameTypeDescriptionsymbolStringThe symbol of aToken of the reservetoken_addressaddressThe address of aToken of the reserve\nget_all_var_tokens#\n#[view]public fun get_all_var_tokens(): vector<TokenData>\nReturns a list of the existing variable debt tokens in the pool, pairs include the symbols and token addresses.\nReturn Values:\nTypeDescriptionvector<TokenData>The list of variableDebtTokens, pairs of symbols and addresses\nThe TokenData struct is composed of the following fields:\nNameTypeDescriptionsymbolStringThe symbol of variable debt token of the reservetoken_addressaddressThe address of variable debt token of the reserve\nget_reserve_configuration_data#\n#[view]public fun get_reserve_configuration_data( asset: address): (u256, u256, u256, u256, u256, bool, bool, bool, bool)\nReturns the configuration data of the reserve. Not returning borrow and supply caps for compatibility, nor pause flag.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nPositionTypeDescription0u256The number of decimals of the reserve1u256The ltv of the reserve2u256The liquidation threshold of the reserve3u256The liquidation bonus of the reserve4u256The reserve factor of the reserve5boolTrue if the usage as collateral is enabled, false otherwise6boolTrue if borrowing is enabled, false otherwise7boolTrue if it is active, false otherwise8boolTrue if it is frozen, false otherwise\nget_reserve_data#\n#[view]public fun get_reserve_data( asset: address): (u256, u256, u256, u256, u256, u256, u256, u64)\nReturns the state of the reserve.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nPositionTypeDescription0u256The scaled amount of tokens accrued to treasury that is to be minted1u256The total supply of the aToken2u256The total variable debt of the reserve3u256The liquidity rate of the reserve4u256The variable borrow rate of the reserve5u256The liquidity index of the reserve6u256The variable borrow index of the reserve7u64The timestamp of the last update of the reserve\nget_user_reserve_data#\n#[view]public fun get_user_reserve_data( asset: address, user: address): (u256, u256, u256, u256, bool)\nReturns the user data in the reserve.\nInput Parameters:\nPositionTypeDescription0u256The current aToken balance of the user1u256The current variable debt of the user2u256The scaled variable debt of the user3u256The liquidity rate of the reserve4boolTrue if the user is using the asset as collateral, else false\nget_reserve_tokens_addresses#\n#[view]public fun get_reserve_tokens_addresses( asset: address): (address, address)\nReturns the addresses of the aToken and variableDebtToken of the reserve.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nPositionTypeDescription0addressThe AToken address of the reserve1addressThe VariableDebtToken address of the reserve\nget_reserve_caps#\n#[view]public fun get_reserve_caps( asset: address): (u256, u256)\nReturns the caps parameters of the reserve.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nPositionTypeDescription0u256The borrow cap of the reserve1u256The supply cap of the reserve\nget_siloed_borrowing#\n#[view]public fun get_siloed_borrowing( asset: address): bool\nReturns the siloed borrowing flag. It returns true if the asset is siloed for borrowing.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nTypeDescriptionboolTrue if the asset is siloed for borrowing\nget_debt_ceiling#\n#[view]public fun get_debt_ceiling( asset: address): u256\nReturns the debt ceiling of the reserve.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nTypeDescriptionu256The debt ceiling of the reserve\nget_liquidation_protocol_fee#\n#[view]public fun get_liquidation_protocol_fee( asset: address): u256\nReturns the protocol fee on the liquidation bonus.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nTypeDescriptionu256The protocol fee on liquidation\nget_borrowable_in_isolation#\n#[view]public fun get_borrowable_in_isolation( self: &ReserveConfigurationMap): bool\nReturns true if the asset can be borrowed in isolation mode.\nInput Parameters:\nNameTypeDescriptionselfReserveConfigurationMapThe reserve configuration\nReturn Values:\nTypeDescriptionboolTrue if the asset is borrowable in isolation mode, false otherwise\nget_emode_category#\n#[view]public fun get_emode_category( self: &ReserveConfigurationMap): u256\nReturns the eMode category of the asset.\nInput Parameters:\nNameTypeDescriptionselfReserveConfigurationMapThe reserve configuration\nReturn Values:\nTypeDescriptionu256The eMode category ID\nget_user_emode#\n#[view]public fun get_user_emode( user: address): u8\nReturns the eMode the user is using.\nInput Parameters:\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:\nTypeDescriptionu8The eMode ID (0 means the user isn't using any eMode)\nget_emode_category_data#\n#[view]public fun get_emode_category_data( id: u8): EModeCategory\nReturns the E-Mode category configuration for the specified category ID.\nInput Parameters:\nNameTypeDescriptionidu8The ID of the category\nReturn Values:\nField NameTypeDescriptionltvu16The loan-to-value of the categoryliquidation_thresholdu16The liquidation threshold of the categoryliquidation_bonusu16The liquidation bonus of the categorylabelStringThe label of the category\nget_user_account_data#\n#[view]public fun get_user_account_data( user: address): (u256, u256, u256, u256, u256, u256)\nReturns the user account data across all reserves.\nInput Parameters:\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:\nPositionTypeDescription0u256Total collateral in base currency1u256Total debt in base currency2u256Available borrows in base currency3u256Current liquidation threshold4u256Loan to value ratio5u256Health factor\nget_flash_loan_enabled#\n#[view]public fun get_flash_loan_enabled( asset: address): bool\nReturns true if flash loans are enabled for the reserve.\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:\nTypeDescriptionboolTrue if flash loans are enabled, false otherwisePreviousSmart ContractsNextAccess Control","tokens":3217,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259631861,"hash":"643836f670f5b95524c82da0bc8614b5ad1fcb19"}
{"url":"http://io.net/","domain":"io.net","title":"The Open Source AI Infrastructure Platform - io.net - io.net","text":"70% cheaper than AWS.Zero waitlists.H100s, A100s, and full clusters on demand. io.net is the GPU cloud built for AI teams who can't afford to wait.Get StartedTrusted by top AI startupsFocus on building,not your runwayFocus on building,not your runwayAccess GPUs instantlyDeploy in minutes with thousands of secure, fully orchestrated global GPU clusters. No waitlists, no approval process, no enterprise contracts.Get unmatched flexibilityMix GPU types, adjust on the fly, and only pay only for what you use. Scale up for training, scale down for inference. No minimums or lock-in.Save up to 70%H100s from $2.19/hr vs AWS at $6.88/hr. Transparent pricing, no hidden fees. Most startups save $10k+ monthly.Increase resilience and securityWith a globally distributed network, and available confidential compute, your project is protected against centralzied outages and your data stays safe.Instant access at 70% lower costsSecurely connect to GPUs from independent data centers, mining operations, and private clusters worldwide. Better prices, faster access, no long contracts, and no single point of failure.H100Nvidia4xAmount80 GBVRAMPer Card6.4 TBStoragePrice From:$16.28/hrDeploy ClusterH100Nvidia4xAmount80 GBVRAMPer Card6.4 TBStoragePrice From:$16.28/hrDeploy ClusterA100Nvidia8xAmount80 GBVRAMPer Card4.9 TBStoragePrice From:$10.50/hrDeploy ClusterV100_32GNvidia4xAmount32 GBVRAMPer Card1000 GBStoragePrice From:$9.83/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card3.2 TBStoragePrice From:$8.45/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card6 TBStoragePrice From:$7.32/hrDeploy ClusterL40SNvidia8xAmount48 GBVRAMPer Card4.9 TBStoragePrice From:$6.72/hrDeploy ClusterV100Nvidia4xAmount32 GBVRAMPer Card3.5 TBStoragePrice From:$6.30/hrDeploy Cluster6000 ADANvidia8xAmount48 GBVRAMPer Card2.7 TBStoragePrice From:$5.46/hrDeploy ClusterV100_32GNvidia2xAmount32 GBVRAMPer Card500 GBStoragePrice From:$4.91/hrDeploy ClusterRTXPRO6000Nvidia2xAmount96 GBVRAMPer Card800 GBStoragePrice From:$4.61/hrDeploy ClusterRTX6000AdaNvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$4.07/hrDeploy ClusterA6000Nvidia8xAmount48 GBVRAMPer Card2.5 TBStoragePrice From:$3.95/hrDeploy ClusterA30Nvidia2xAmount24 GBVRAMPer Card1.3 TBStoragePrice From:$3.94/hrDeploy ClusterH200Nvidia1xAmount141 GBVRAMPer Card750 GBStoragePrice From:$3.79/hrDeploy ClusterL40SNvidia2xAmount48 GBVRAMPer Card3.2 TBStoragePrice From:$3.77/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterL40SNvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$3.36/hrDeploy ClusterA40Nvidia2xAmount48 GBVRAMPer Card1.5 TBStoragePrice From:$3.04/hrDeploy Cluster6000 ADANvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$2.73/hrDeploy ClusterL40Nvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$2.65/hrDeploy ClusterA100Nvidia2xAmount80 GBVRAMPer Card1.5 TBStoragePrice From:$2.58/hrDeploy ClusterV100Nvidia2xAmount32 GBVRAMPer Card1.8 TBStoragePrice From:$2.52/hrDeploy ClusterV100_32GNvidia1xAmount32 GBVRAMPer Card250 GBStoragePrice From:$2.46/hrDeploy ClusterPRO 6000 BLACKWELLNvidia1xAmount96 GBVRAMPer Card725 GBStoragePrice From:$2.09/hrDeploy ClusterA100Nvidia1xAmount40 GBVRAMPer Card1.5 TBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterRTX6000AdaNvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$2.04/hrDeploy ClusterA6000Nvidia4xAmount48 GBVRAMPer Card1 TBStoragePrice From:$1.97/hrDeploy ClusterA30Nvidia1xAmount24 GBVRAMPer Card640 GBStoragePrice From:$1.97/hrDeploy ClusterV100Nvidia1xAmount32 GBVRAMPer Card900 GBStoragePrice From:$1.57/hrDeploy ClusterA40Nvidia1xAmount48 GBVRAMPer Card750 GBStoragePrice From:$1.51/hrDeploy Cluster6000 ADANvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$1.36/hrDeploy ClusterL40Nvidia2xAmount48 GBVRAMPer Card1.2 TBStoragePrice From:$1.32/hrDeploy ClusterA100Nvidia1xAmount80 GBVRAMPer Card625 GBStoragePrice From:$1.31/hrDeploy ClusterDGX A100Nvidia1xAmount80 GBVRAMPer Card1000 GBStoragePrice From:$1.31/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterRTX6000AdaNvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$1.02/hrDeploy ClusterA6000Nvidia2xAmount48 GBVRAMPer Card512 GBStoragePrice From:$0.99/hrDeploy ClusterT4Nvidia2xAmount16 GBVRAMPer Card1.8 TBStoragePrice From:$0.94/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.84/hrDeploy Cluster6000 ADANvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$0.68/hrDeploy ClusterL40Nvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.66/hrDeploy ClusterA6000Nvidia1xAmount48 GBVRAMPer Card256 GBStoragePrice From:$0.49/hrDeploy ClusterT4Nvidia1xAmount16 GBVRAMPer Card900 GBStoragePrice From:$0.47/hrDeploy ClusterB200Nvidia1xAmount192 GBVRAMPer Card500 GBStoragePrice From:$4.89/hrDeploy ClusterB300 SXM6 ACNvidia1xAmount275 GBVRAMPer Card500 GBStoragePrice From:$4.50/hrDeploy ClusterH200Nvidia1xAmount140 GBVRAMPer Card500 GBStoragePrice From:$2.00/hrDeploy ClusterH100 80GB HBM3Nvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.99/hrDeploy ClusterH100 PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.59/hrDeploy ClusterA100-SXM4-80GBNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100 80GB PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100-PCIE-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$1.19/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.90/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterGeForce RTX 5090Nvidia1xAmount32 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterA100-SXM4-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$0.79/hrDeploy ClusterGeForce RTX 4090 DNvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 4090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 3090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.25/hrDeploy ClusterRTX A5000Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.19/hrDeploy ClusterRTX A4000Nvidia1xAmount16 GBVRAMPer Card500 GBStoragePrice From:$0.15/hrDeploy ClusterH100Nvidia4xAmount80 GBVRAMPer Card6.4 TBStoragePrice From:$16.28/hrDeploy ClusterA100Nvidia8xAmount80 GBVRAMPer Card4.9 TBStoragePrice From:$10.50/hrDeploy ClusterV100_32GNvidia4xAmount32 GBVRAMPer Card1000 GBStoragePrice From:$9.83/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card3.2 TBStoragePrice From:$8.45/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card6 TBStoragePrice From:$7.32/hrDeploy ClusterL40SNvidia8xAmount48 GBVRAMPer Card4.9 TBStoragePrice From:$6.72/hrDeploy ClusterV100Nvidia4xAmount32 GBVRAMPer Card3.5 TBStoragePrice From:$6.30/hrDeploy Cluster6000 ADANvidia8xAmount48 GBVRAMPer Card2.7 TBStoragePrice From:$5.46/hrDeploy ClusterV100_32GNvidia2xAmount32 GBVRAMPer Card500 GBStoragePrice From:$4.91/hrDeploy ClusterRTXPRO6000Nvidia2xAmount96 GBVRAMPer Card800 GBStoragePrice From:$4.61/hrDeploy ClusterRTX6000AdaNvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$4.07/hrDeploy ClusterA6000Nvidia8xAmount48 GBVRAMPer Card2.5 TBStoragePrice From:$3.95/hrDeploy ClusterA30Nvidia2xAmount24 GBVRAMPer Card1.3 TBStoragePrice From:$3.94/hrDeploy ClusterH200Nvidia1xAmount141 GBVRAMPer Card750 GBStoragePrice From:$3.79/hrDeploy ClusterL40SNvidia2xAmount48 GBVRAMPer Card3.2 TBStoragePrice From:$3.77/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterL40SNvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$3.36/hrDeploy ClusterA40Nvidia2xAmount48 GBVRAMPer Card1.5 TBStoragePrice From:$3.04/hrDeploy Cluster6000 ADANvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$2.73/hrDeploy ClusterL40Nvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$2.65/hrDeploy ClusterA100Nvidia2xAmount80 GBVRAMPer Card1.5 TBStoragePrice From:$2.58/hrDeploy ClusterV100Nvidia2xAmount32 GBVRAMPer Card1.8 TBStoragePrice From:$2.52/hrDeploy ClusterV100_32GNvidia1xAmount32 GBVRAMPer Card250 GBStoragePrice From:$2.46/hrDeploy ClusterPRO 6000 BLACKWELLNvidia1xAmount96 GBVRAMPer Card725 GBStoragePrice From:$2.09/hrDeploy ClusterA100Nvidia1xAmount40 GBVRAMPer Card1.5 TBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterRTX6000AdaNvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$2.04/hrDeploy ClusterA6000Nvidia4xAmount48 GBVRAMPer Card1 TBStoragePrice From:$1.97/hrDeploy ClusterA30Nvidia1xAmount24 GBVRAMPer Card640 GBStoragePrice From:$1.97/hrDeploy ClusterV100Nvidia1xAmount32 GBVRAMPer Card900 GBStoragePrice From:$1.57/hrDeploy ClusterA40Nvidia1xAmount48 GBVRAMPer Card750 GBStoragePrice From:$1.51/hrDeploy Cluster6000 ADANvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$1.36/hrDeploy ClusterL40Nvidia2xAmount48 GBVRAMPer Card1.2 TBStoragePrice From:$1.32/hrDeploy ClusterA100Nvidia1xAmount80 GBVRAMPer Card625 GBStoragePrice From:$1.31/hrDeploy ClusterDGX A100Nvidia1xAmount80 GBVRAMPer Card1000 GBStoragePrice From:$1.31/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterRTX6000AdaNvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$1.02/hrDeploy ClusterA6000Nvidia2xAmount48 GBVRAMPer Card512 GBStoragePrice From:$0.99/hrDeploy ClusterT4Nvidia2xAmount16 GBVRAMPer Card1.8 TBStoragePrice From:$0.94/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.84/hrDeploy Cluster6000 ADANvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$0.68/hrDeploy ClusterL40Nvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.66/hrDeploy ClusterA6000Nvidia1xAmount48 GBVRAMPer Card256 GBStoragePrice From:$0.49/hrDeploy ClusterT4Nvidia1xAmount16 GBVRAMPer Card900 GBStoragePrice From:$0.47/hrDeploy ClusterB200Nvidia1xAmount192 GBVRAMPer Card500 GBStoragePrice From:$4.89/hrDeploy ClusterB300 SXM6 ACNvidia1xAmount275 GBVRAMPer Card500 GBStoragePrice From:$4.50/hrDeploy ClusterH200Nvidia1xAmount140 GBVRAMPer Card500 GBStoragePrice From:$2.00/hrDeploy ClusterH100 80GB HBM3Nvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.99/hrDeploy ClusterH100 PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.59/hrDeploy ClusterA100-SXM4-80GBNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100 80GB PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100-PCIE-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$1.19/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.90/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterGeForce RTX 5090Nvidia1xAmount32 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterA100-SXM4-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$0.79/hrDeploy ClusterGeForce RTX 4090 DNvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 4090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 3090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.25/hrDeploy ClusterRTX A5000Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.19/hrDeploy ClusterRTX A4000Nvidia1xAmount16 GBVRAMPer Card500 GBStoragePrice From:$0.15/hrDeploy ClusterGPUs everywhere, on demandYour customers are everywhere, and your compute requirements are always changing. Get the compute you need, where you need it, when you need it with globally distributed GPU clusters, and no vendor lock-in.Try io.cloud nowGeForce RTX 4090NvidiaH100 PCIeNvidiaPrices correct as of 30th July 2025H100SXM5NvidiaH200Nvidia$0.49/ hr$1.85/ hrVirtual Machines$1.85/ hr$3.70/ hr$0.50/ hr$1.70/ hrCaaS$1.99/ hr$2.49/ hr$0.50/ hr$1.70/ hrBare Metal$1.99/ hr$2.49/ hrGPUVirtual MachinesCaaSBare MetalGeForce RTX 4090Nvidia$0.49/ hr$0.50/ hr$0.50/ hrH100 PCIeNvidia$1.85/ hr$1.70/ hr$1.70/ hrH100SXM5Nvidia$1.85/ hr$1.99/ hr$1.99/ hrH200Nvidia$3.70/ hr$2.49/ hr$2.49/ hrPrices correct as of 30th July 2025Deploy how you want,when you wantContainersOne-line deployment for ML workloads with pre-configured environmentsDeploy ContainerVirtual machinesAI-ready VMs in less than 5 minutes with pre-configured ML frameworksDeploy VMRay clusterNative support for containerized AI workloads with familiar toolingThe open-weight AI platform built for scaleInstantly run, deploy, and scale AI models with high-performance GPUs and zero setup.Scale with over 50+ AI ModelsXiaomiDeepSeekZ.aiAlibaba CloudMoonshot AIMiniMaxGoogleOpen AIMeta AIMistral AIEverything you need tobuild advanced AI solutionsAgentic workflow editorBuild and connect intelligent agents with logic-driven automation.Launch Workflow EditorModel and agent marketplaceDiscover and deploy leading open-weight AI models.Launch AI MarketplaceTraining-as-a-Service (TaaS)Train and scale models securely on decentralized infrastructure.Launch Training As A ServiceGet off the waitlist and start building today Join thousands of developers instantly and securely deploying GPU clusters at 70% lower cost. No waitlists. No constant price rises. No vendor lock-in. Just the resources you need to build a sustainable business.Get Started","tokens":3455,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259635139,"hash":"5ca56cc1b95440cc94aee8de31b21f12b538d689"}
{"url":"https://gov.optimism.io/t/shutterized-optimism-an-encrypted-mempool-for-the-op-stack/6387/5","domain":"gov.optimism.io","title":"Shutterized Optimism – An Encrypted Mempool for the OP Stack - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Proposals 📃Technical Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 13\n min\n\n Jul 2023\n\n 5 / 5\n\n Jul 2023\n\n Jul 2023\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori\nExecutive Summary\nThis document serves as a requirements and technical architecture document for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, capitalizing on the capabilities of the Shutter Network. The mechanism targets the reduction of front-running and MEV-related exploits in the Ethereum DeFi ecosystem by adopting a shielded mempool using threshold encryption.\nBy integrating this mechanism, we foresee OP Stack-based rollups becoming more secure and efficient layers, attracting safer trading for DeFi users, more robust censorship resistance, and increased profitability. Moreover, the sequencer operators will be able to claim immunity from front-running and censoring transactions by design, while retaining their ability to collect and/or distribute back-running related MEV.\nDecentralized Sequencer and MEVA designs are largely orthogonal to this proposal and complement it well.\nTable of Contents\n\nExecutive Summary\nTable of Contents\nIntroduction and Goals\n3.1. Problem Statement\n3.1.1. Malicious MEV and Censorship\n3.1.2. MEV and Censorship on Layer 2 (L2)\n3.1.3. Regulatory Implications\n3.2. MEV mitigation solutions overview\n3.3. OP Stack\n3.4 Shutter Network\nParticipant Requirements\n4.1 End User\n4.2 Dapp Project\n4.3 Optimism Rollup Node\n4.4 Optimism Sequencer\n5 Component Requirements\n5.1 Functional Requirements\n5.1.1 Optimism Rollup Node\n5.1.2 Optimism Sequencer Node\n5.1.3 Keyper\n5.1.4 Front End Library\n5.2 Non-functional Requirements\nTechnical Architecture of Shutterized Optimism\n6.1 Overview\n6.2 Components\n6.2.1 Keyper Set\n6.2.2 Sequencer\n6.2.3 System Contracts\n6.2.4 Client Library\n6.3 Code Modifications\n6.3.1 Shutter Inbox Contract\n6.3.2 Keyper Set Contract\n6.3.3 Key Broadcast Contract\n6.3.4 Engine API\n6.3.5 op-node\n6.3.6 op-geth\n6.4 User Interaction\n6.5 Interaction With Decentralized Sequencers\n6.6 Finality Assumption\n6.7 Potential Issues and Solutions\n6.7.1 Liveness Failures\n6.7.2 Latency\n6.7.3 Sequencer Side-Channel Attack\nDesign Options\n7.1 Block or Transaction Keys\nFuture Considerations\nConclusion\n\nIntroduction and Goals\nThis document presents requirements and an architecture proposal for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network. The mechanism aims to provide front-running protection using an encrypted/shielded mempool and threshold encryption, as proposed in Shutter Network’s Optimism Governance Forum post.\nWe think by adopting this mechanism, OP Stack-based rollups become better, more neutral base layers and can gain the following benefits:\n\nSafer trading for DEFI users (no front-running)\nAdded censorship resistance (even for centralized sequencers)\nMore profitable trading for DEFI users (because less value lost due to malicious MEV)\nSequencer can plausibly argue that they no longer have the ability to front-run transactions nor censor transactions based on their content by design (potential compliance, image and regulatory benefits for the sequencer operator)\nSequencer still retains the ability to collect or distribute back-running related MEV (arbitrage and liquidations)\n\nThis document begins with a goals/motivation section, then presents a two-phase process for defining the architecture of a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network.\nThe process starts with Phase 1, where high-level, solution-agnostic requirements for the mechanism are defined. This phase is primarily driven by the perspectives and needs of the end users and the sequencer, with requirements categorized by actors in the system.\nFollowing this, Phase 2 transitions to defining Shutter-specific requirements, focusing more on the details of the proposed implementation. These requirements are categorized by expected technical components in the system.\nIt then outlines the user interaction with the system, followed by the core of the document, the technical architecture section. Within this section, the technical components and code modifications are outlined, a transaction flow diagram is given, among other things.\nThe document closes with a conclusion and future considerations.\nProblem Statement\nThe rising popularity of Ethereum’s open finance (DeFi) ecosystem has led to an increasing amount of maximal extractable value (MEV). Unfortunately, it has also exposed the network to potential exploitation through front-running and other MEV-related tactics, which can deter prospective investors and traders. Furthermore, the measures put in place to manage this issue have proven to be suboptimal, introducing unnecessary trust assumptions and centralization factors. For instance, MEV relays, though beneficial for market health, require a high degree of trust, making them unsustainable in their current form. To unlock the billions in side-lined investment and ensure Ethereum’s long-term base layer neutrality, an effective approach to transaction ordering and inclusion is required.\nMalicious MEV and Censorship\nFront-running and malicious MEV extraction pose significant threats to Ethereum’s ecosystem. Front-running involves the unethical practice of a broker executing orders on a security for its own account while taking advantage of advance knowledge of pending orders from its customers. On Ethereum, this has resulted in a measurable amount of value extraction from users. MEV relays, which were introduced as a solution, unfortunately introduce centralization risks due to the required high degree of trust.\nThis tendency to centralize parts of the transaction supply chain infrastructure not only adds censorship vectors but also facilitates actual censorship on the protocol level, as evidenced by instances of adherence to sanctions lists such as the Office of Foreign Assets Control (OFAC) list.\nMEV and Censorship on Layer 2 (L2)\nLayer 2 solutions, which aim to scale Ethereum’s network by processing transactions off the main blockchain, face a similar yet distinct set of challenges. Here, the problem lies in the private mempools and potential spamming issues. Currently, rollup sequencers — responsible for collecting and submitting transactions on L2 — are trusted not to extract MEV. However, this centralized approach could potentially amplify the MEV issue in the long term. To avoid front-running, we place our trust in the sequencer, inadvertently consolidating their power, thus creating an unsustainable and censorship susceptible system.\nRegulatory Implications\nThe regulatory landscape poses another challenge. Regulatory bodies worldwide have begun to clamp down on front-running, potentially categorizing sequencers who extract malicious MEV as financial intermediaries, rather than purely technical entities. This could complicate compliance, as financial intermediaries are subjected to stringent regulatory requirements. Consequently, without proper management of MEV, Ethereum could face stricter regulations, deterring users and stifling growth in the DeFi sector.\nMEV mitigation solutions overview\n\nProposer Builder Separation (PBS): Proposer-builder separation (PBS) is a proposed upgrade for Ethereum that divides the tasks of creating and broadcasting blocks between multiple validators, enhancing censorship resistance, preventing hobbyist validators from being outcompeted by institutional players, and aiding Ethereum’s scalability; it also reconfigures the economics of maximum extractable value (MEV), allowing any validator to benefit from sophisticated MEV extraction performed by block builders.\nMEV Auctions (Optimism MEVA): Optimism MEVA is a proposal for an auction-based system where proposers bid for the right to order transactions within a block, reducing the potential for MEV extraction.\nMEV Revenue Sharing Approaches: These approaches involve mechanisms that redistribute MEV to various stakeholders, thus diminishing the potential profits from malicious extraction.\nTrust in Sequencer or MEV Relay to Not Front-run: This approach depends on the trustworthiness of a sequencer or MEV relay to act in the best interests of users and not engage in front-running.\nEncrypted Mempools: Encrypted mempools are a way to hide transaction information until it is included in a block, preventing front-running and other MEV extraction tactics.\n\nSolution Comparison Table\n\nSolution\nReduces or Redistributes MEV?\nTrust Requirement\n\nProposer Builder Separation (PBS)\nRedistributes\nSeparates trust requirements\n\nMEV Auctions (e.g. Optimism MEVA)\nRedistributes\nDepends on specific implementation\n\nMEV Revenue Sharing Approaches\nRedistributes\nUsually introduces additional trust requirements\n\nTrust in Sequencer or MEV Relay to Not Front-run\nReduces\nIntroduces additional trust requirements\n\nEncrypted Mempools\nReduces\nReduces trust requirements\n\nIn conclusion, a comprehensive solution to the MEV problem may involve a combination of multiple strategies. For instance, encrypted mempools could be used to significantly reduce malicious MEV, and then redistribution frameworks such as Optimism MEVA could be applied to manage the remaining MEV. The goal is to balance the need for trust with the potential to reduce or redistribute MEV effectively.\nOP Stack\nThe OP Stack, managed by the Optimism Collective, is a standardized, shared, and open-source development stack that fuels Optimism. Currently powering the Optimism Mainnet, it’s expected to evolve and shape the Optimism Superchain and its governance. Its design promotes a shared, high-quality system for creating new L2 blockchains, minimizing the need for siloed software development.\nThe “Optimism Bedrock” is the latest iteration of the OP Stack, providing tools to launch production-quality Optimistic Rollup blockchains. It’s designed to support the Optimism Superchain, a proposed network of L2s that share security, communication layers, and a common development stack.\nAs an evolving concept, the OP Stack will grow and adapt with Optimism, aiming to simplify the deployment of new L2 Rollups and foster interoperability among different chains within the Superchain ecosystem. For those interested, resources are available to explore the OP Stack further and launch a Superchain-ready L2.\nShutter Network\nShutter is an anti-frontrunning, malicious MEV-preventing protocol using threshold encryption. It’s intended to be used as a plugin by any L1/L2 protocol to provide front-running and censorship resistance via implementing a shielded/encrypted mempool.\nShutter incorporates a Distributed Key Generation (DKG) scheme into an L1 or L2 rollup sequencer mechanism to protect all dapps deployed on the rollup by default while also improving censorship resistance and potentially latency properties. In principle, it operates by making the sequencer accept encrypted transactions in their blocks and revealing and executing them only once they are ordered.\n\n read \n\n 13\n min\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Participant Requirements\nThis section defines requirements for a threshold encryption-based front-running protection mechanism for OP Stack and Bedrock. They are high-level, solution-agnostic, and primarily driven by the perspectives and needs of the participants in the system who are as follows:\n\nEnd users: These are individuals who interact with the system, usually by submitting transactions.\nOptimism sequencer: The Optimism sequencer is a component of the Optimism rollup architecture, responsible for ordering and executing transactions by building new rollup blocks.\nOptimism rollup node: The Optimism rollup node is a component of the Optimism rollup architecture, syncing the rollup state from the sequencer and the L1 chain.\nDapp project: Dapp projects provide some service to end users and typically consist of a set of smart contracts deployed on the Optimism chain, a browser-based frontend, and potentially additional components.\n\nEnd User\n\nUser experience and security should be comparable to using a Dapp on Optimism today.\nUsers can submit encrypted transactions that cannot be frontrun.\nUsers can still send unencrypted transactions that have the same execution guarantees as before.\nInclusion and execution latency for unencrypted transactions is similar to the status quo.\nInclusion and execution latency for encrypted transactions is not much higher than for unencrypted transactions.\nTransaction fees for unencrypted transactions is the same as the status quo.\nTransaction fees for encrypted transactions is not much higher than for unencrypted transactions.\n\nDapp Project\n\nComprehensive documentation on the front-running protection mechanism is available.\nExisting front-end applications require no to minimal changes to remain compatible.\nA frontend library that handles the encryption, submission, and execution status tracking of encrypted transactions is available.\nUsage of the system requires no additional networking besides the existing JSON RPC interface.\n\nOptimism Rollup Node\n\nSetup and operation of the rollup node should be similar to the status quo.\nAdditional computational overhead of decrypting transactions does not significantly impact hardware requirements.\nError handling and reporting mechanisms for issues related to transaction decryption or processing are reliable and robust.\nThe node can scale in response to increased demand for encrypted transactions.\nFailures are handled gracefully.\n\nOptimism Sequencer\nThe sequencer inherits the rollup node requirements.\n\nThe sequencer can plausibly argue that they no longer have the ability to front-run transactions by design.\nThe sequencer can plausibly argue that they no longer have the ability to censor transactions based on their content by design.\nEncrypted and unencrypted transactions are processed within the same pipeline.\nThe sequencer can reject encrypted transactions if they do not pay an appropriate fee, taking into account the cost of both storing it on L1 as well as executing it.\n\nComponent Requirements\nThis section defines requirements for a concrete instantiation of a threshold encryption-based front-running protection mechanism, leveraging the Shutter Network. It first defines the main software components generally needed for such a system and then states requirements on them.\nThe technical components in the system are as follows:\n\nOptimism rollup node: The rollup node reads the L2 state from the sequencer’s unsafe sync and occasionally compares it with the L2 state locally derived from L1 sequencer batches and deposit data. The rollup node also propagates unsafe, safe and finalized block data within a P2P network. It uses the same software as the sequencer but in a different mode of operation and as a different entity in the Optimism system.\nOptimism sequencer node: The sequencer accepts transactions via a (private) mempool and integrates them in new L2 sequencer batches, which will eventually be included in an unsafe block,persisted on L1 and later included in a finalized block.\nKeyper set: The keypers run a distributed key generation (DKG) protocol. This process outputs a single public key as well as one secret key share for each participant. From the public key, encryption keys can be derived. The keypers can compute the corresponding decryption key in a collaborative manner. The process assumes that at least a certain fraction (e.g. 2/3) is honest and online.\nFrontend library: The frontend library helps Dapps to use encrypted transactions in the user interface.\n\nFunctional Requirements\nOptimism Rollup Node\n\nThe rollup node reads decryption keys from the chain.\nThe rollup node verifies correctness of decryption keys.\nThe rollup node decrypts encrypted transactions included in the chain with the decryption key.\nThe rollup node executes decrypted transactions in the order that the sequencer has arranged the corresponding encrypted transactions in the block.\nThe changes do not affect inclusion and execution of deposit transactions.\nThe state does not progress without decryption keys to prevent frontrunning.\nThe system provides a mechanism to indefinitely stop execution of encrypted transactions in case the keypers fail to produce decryption keys.\nThe rollup node implementation is based on the OP Mainnet node with minimal modifications.\n\nOptimism Sequencer Node\n\nThe sequencer accepts both plaintext and encrypted transactions through the existing mempool.\nThe sequencer chooses to include encrypted transactions in a block if they pay a fee appropriate to its resource requirements at both inclusion and execution time.\nThe sequencer has a guarantee at inclusion time that encrypted transactions pay a fee for their execution.\nThe sequencer receives decryption keys from the keypers and includes them in their blocks after validating them.\nThe sequencer does not store state in memory that if lost would prevent the chain from making progress.\nThe sequencer implementation is based on the OP Mainnet sequencer with minimal modifications.\n\nKeyper\n\nThe keypers generate a public key used to derive encryption keys and broadcast it on L2.\nThe keypers read the keyper set membership and peer information from a contract on L2.\nThe keypers generate the decryption keys for encrypted transactions.\nHardware requirements should allow running a keyper node on a consumer grade laptop given access to an external rollup node.\nIn order to circumvent sequencer censorship, the keyper is able to send deposit transactions via L1.\nThe keyper software is implemented in Go.\n\nFront End Library\n\nComprehensive documentation of the library API and usage patterns exists\nThe library exposes a small API surface and hides away implementation details\nThe library integrates well with existing commonly used front-end libraries.\nThe library is implemented in JavaScript or TypeScript.\n\nNon-functional Requirements\nDisclaimer: At this stage in the architectural planning process, these are provisional estimates for non-functional requirements and are subject to change.\n\nAt least 20 keypers\nNew epoch every 4 seconds.\nInclusion confirmation within one block.\nExecution confirmation for unencrypted transactions within one block.\nExecution confirmation for encrypted transactions within two blocks.\nNo gas overhead for unencrypted transactions.\nLess than 3x gas cost for a typical encrypted transaction.\n\nTechnical Architecture of Shutterized Optimism\nOverview\nThe main addition to the stack is the set of keypers, a committee responsible for generating keys that will be used to encrypt and decrypt transactions. Its members are managed by a contract on L2, the Keyper Set Contract. In a one-time setup phase, they generate the so-called eon public key and broadcast it via the Key Broadcast Contract.\nIn addition to standard transactions, the system allows users to send encrypted transactions that will be protected from frontrunning and censorship. To do so, users have to first create the payload (consisting of receiver, calldata, and value) and then encrypt it with the eon key. They then submit the encrypted payload to the Shutter Inbox Contract via a so-called Commit Transaction. The contract stores the payload in its storage and charges the user a fee which covers the gas the scheduled transaction is going to use when being executed. The amount is derived from the gas price as well as a user-provided gas limit and sent via the Commit Transaction’s value field.\nWhenever the sequencer seals a block, the keypers collaboratively generate the decryption key for it and broadcast it on a P2P network. The sequencer picks it up and puts it – in the form of a so-called Reveal Transaction – at the front of the block. Executing this transaction will result in all encrypted transactions that have been scheduled previously being read from the ShutterInbox Contract, being decrypted and executed.\nThe state transition function ensures that the sequencer plays by the rules, i.e., that blocks fulfill the structure outlined above. In particular, blocks without a decryption key at the top (or an incorrect one) are invalid.\nblock-diagram961×205 27.2 KB\nInternal structure of blocks: Time increases from left to right, with decryption processes between the blocks. Inside of the block structure, transactions are executed in a left to right order. Decrypted payloads committed one block earlier are executed within the “Reveal Transaction” at the beginning of the block. (high res)\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Components\nKeyper Set\nThe keyper set is a threshold-committee consisting of at least 20 members. During a setup phase, the keyper set generates the eon public key and broadcasts it. This key will be used by users to encrypt payloads. After each block produced by the sequencer, the keyper set generates a decryption key that can be used to decrypt these payloads.\nIt is assumed that at least a certain number of keypers – the threshold – is online and behaves honestly. If not, they can produce decryption keys before the corresponding block has been produced and use this advance knowledge to frontrun in collusion with the sequencer.\nSequencer\nThe job of Optimism’s sequencer is to receive transactions from users, build blocks, broadcast them, and submit them to L1. In addition to that, this proposal requires them to listen on a P2P network for decryption keys from the keypers and produce blocks with slightly altered rules.\nSystem Contracts\nThe system relies on a small suite of smart contracts deployed on L2:\n\nThe Keyper Set Contract: Manages the set of keypers.\nThe Key Broadcast Contract: Acts as a billboard on which keypers can publish the eon public key.\nShutter Inbox Contract: Collects encrypted payloads and metadata submitted by users in the form of Commit Transactions.\n\nClient Library\nThis frontend library provides functions for Dapps to easily\n\nretrieve the eon public key from the Key Broadcast Contract,\ncreate and encrypt payloads,\nsubmit them to the Shutter Inbox Contract via Commit Transactions, and\nbe notified when they are included as well as decrypted and executed.\n\ncomponents824×682 60.2 KB\nDiagram of the different components making up the Shutterized Optimism System. Arrows indicate the data flow starting with the user submitting a plaintext as well as an encrypted transaction and ending with it being executed on the chain. Numbered text over arrows describe successive steps in the block building process. (high res)\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Code Modifications\nThis section describes the main modifications that have to be implemented on top of the existing OP Stack and Bedrock codebase. In addition, it describes the required system contracts.\nShutter Inbox Contract\nThe central system contract is the Shutter Inbox Contract. It exposes the commit function which can be called by standard Ethereum transactions. In the following, those are named Commit Transactions.\nThe user encrypts a payload, consisting of data, value and to fields, and attaches this in serialized form as an argument to the commit call. Additional arguments are the future block-number when the transaction has to be executed as well as the estimated gas-limit for the execution. The Commit Transaction has to include an ETH-transfer to the contract via the transaction’s value field, so that the amount is equal to the gas-limit argument multiplied by the gas-price of the Commit Transaction.\nThe contract will store a FIFO-queue of the passed in arguments together with the sender address in its storage. The contract makes sure that the cumulative gas-limits of the queue can never surpass the block-gas-limit, otherwise the contract call fails. In order to keep the total state-growth constant, the contract will only accept and enqueue transactions where the block-number argument equals the next block number, and the contract will delete all previous transactions from the queue once they are handled in the Reveal Transaction. The accumulated gas transferred to the contract via the Commit Transactions can be withdrawn by a configurable account, e.g. the sequencer or a DAO.\nKeyper Set Contract\nThe Keyper Set Contract manages the current keyper set. It allows an owner, e.g. the OP DAO, to add and remove members at will at certain block numbers. The keyper set contract also defines an emergency shutdown mechanism described in more detail in the “Potential Issues and Solutions” section.\nKey Broadcast Contract\nThe Key Broadcast Contract is a simple billboard that allows any keyper set to broadcast its eon public key after they generated it. Users can fetch it from there.\nEngine API\nIn order to include the decryption key in the block and make it available in the state-transition-function (STF), it has to be passed from the receiving end (op-node) to the block-building engine in op-geth. Therefore the EngineAPI payload-attributes for the engine_forkChoiceUpdatedV1 have to be extended to include a decryption-key field.\nop-node\nThe op-node is responsible for initiating the construction and release of new blocks in the op-geth node in regular intervals. It does so by continuously adding transactions to the block candidate at all times. This process now has to be paused briefly after each proposed block until the keypers have produced the decryption key.\nConcretely, the time between a sequencer’s unsafe head update and the successful keyper-decryption process blocks the execution of the next call to engine_forkChoiceUpdatedV1. Since the decryption key generation time is variable, the op-node adjusts the time for successive calls to engine_getPayloadV1 / engine_newPayloadV1 in order to keep the overall block time constant.\nThe op-node additionally communicates with the set of keypers by operating a libp2p module that connects to the keypers and subscribes to a decryption-key topic via the gossipsub protocol. The op-node has to have access to the current layer 2 blockchain state, in order to verify keyper-set membership and the validity of received decryption keys.\nop-geth\nThe miner in op-geth is responsible for assembling new blocks. To do so, it picks transactions from the sorted mempool as well as deposit-transactions received from the op-node via the payload-attributes of the EngineAPI.\nBlock-building is initiated by the op-node via the Engine API. In this process, additional constraints have to be fulfilled and considered for block validity. It requires the decryption key for transactions included in the previous block, which the miner receives via the payload-attributes from the op-node.\nThe first transaction to be executed in the block’s state-transition function is the special Reveal Transaction. It is exclusively assembled by the miner and contains the decryption key. It fetches the encrypted payloads for this block from the Shutter Inbox Contract and decrypts them. Subsequently, it executes it, taking the corresponding metadata fields sender and gas limit into account. Note that the gas for the transaction has already been paid for by Commit Transaction.\nAfter successful execution of the decrypted payload, the resulting events of all decrypted transactions are included in the receipt of the Reveal Transaction. In the remainder of the block, the miner includes new transactions from the mempool as usual, including Commit Transactions for the next block. The miner takes the execution gas limit of the latter into account in the scoring function used for mempool ordering.\nblock-building1004×1142 74.3 KB\nSequence diagram of the block building process. Two iterations of block building are shown - in the first, only the inclusion of normal transactions is shown in detail. In the second, only the inclusion of the Reveal Transaction is shown in detail. “NextBlock” represents the current locally built block within the sequencer’s memory. “Layer2State” represents the publicly visible unsafe head state of the layer 2 blockchain. (high res)\nUser Interaction\nThe user experience of using encrypted transactions is very similar compared to normal ones, and involves only a few additional steps in the transaction submission and status notification process. When using a specific Dapp frontend, an action that posts a transaction to the blockchain will be handled in the following way:\nThe user will be informed beforehand that the gas mechanism of this transaction is handled differently and the value transferred to the inbox contract is a pre-payment of gas for execution of the revealed transaction. In the background, the Dapp will locally handle the gas estimation of the payload, eventually fetch the relevant encryption inputs from the L2 chain, and encrypt the payload.\nThe Dapp then constructs a normal Ethereum transaction that calls the commit function of the Shutter Inbox Contract and adds the calculated execution-gas to the transaction’s value field.\nNext, the Dapp will ask the user’s wallet to send the transaction, which in turn will prompt the user to sign it. Finally, the wallet will submit the signed transaction to the Optimism JSON RPC endpoint.\nThe Dapp will then continuously show the current execution status of the user’s transaction – but execution confirmation will take longer than usual: As a first pre-confirmation, the Dapp will check the layer 2 chain for successful inclusion of the Shutter Inbox call in the latest block. As soon as the Commit Transaction has been included, the user will see the status of the transaction as “committed, waiting for decryption and execution”.\nOnce the corresponding decrypted payload is found in the Reveal Transaction of the next block and executed successfully, the user will see the status of the transaction as “revealed, successfully decrypted and executed”. The Dapp may read the receipt of the Reveal Transaction and construct more detailed information on the transaction’s execution. Among others, this receipt indicates if execution was successful or if it reverted, e.g. due to running out of gas.\nIn case the Reveal Transaction receipt does not contain a trace of the decrypted payload, it was invalid.\nInteraction With Decentralized Sequencers\nDecentralized Sequencer and MEVA designs are largely orthogonal to this proposal. The only requirements for Shutterized Optimism on the block proposal mechanism are that they come with a certain degree of finality, or achieve it quickly over time (without additional blocks).\nFinality Assumption\nThe system assumes that unsafe heads are final, as the keypers release the decryption key immediately upon observing them. If they are not, i.e., if a malicious sequencer can create a competing fork, this sequencer would be able to frontrun. Note that this attack would be both provable and attributable. We therefore recommend that the sequencer has to deposit a stake that will be slashed in case the sequencer attempts this attack.\nPotential Issues and Solutions\nLiveness Failures\nThe main failure to consider is a liveness failure caused by the keypers not producing the decryption key. This would prevent the sequencer from proposing the next valid block. For this scenario to take place, Shutter’s threshold assumption has to break: More than 1 - t keypers have to be offline, where t is the threshold parameter.\nTo recover from this and similar types of failure, Shutter can be disabled by a smart contract emergency switch. In that case, the rollup’s operation would fall back to standard Optimism mode. In particular, this would allow the sequencer to produce a block without including the decryption key, so that the system can continue to make progress. This cannot be used to frontrun as encrypted transactions will never be decrypted nor executed. Various options exist for which entities could trigger the emergency switch: The sequencer, OP governance, Shutter governance, or a subset of the keyper set itself. In addition, the switch could be conditional on the duration in which no block has been produced.\nLatency\nEncrypted transactions are executed over the course of two blocks (commit in some block, reveal in the next). Naturally, their latency until execution increases by a factor of two. Latency until inclusion of the Commit Transaction is still only a single block (note that inclusion guarantees later execution). Standard transactions are largely unaffected by Shutter, so they will still be included and executed in the next block.\nHowever, building a block now involves generating the decryption key. Since this is carried out in a distributed manner over a P2P network, the default block time may have to be increased. The exact number will depend on the number of keypers and network latency, but a cautiously optimistic estimate is 4s.\nSequencer Side-Channel Attack\nThe design involves a potential issue related to the sequencer’s ability to freely choose block attributes. This control enables the sequencer to affect the execution path of previously committed transactions at a time when they already know the decryption key. This allows them to frontrun.\nFor instance, the sequencer may include a transaction at the top of the block that buys a token on a DEX if the block timestamp is even and sells it if it is odd. As soon as they receive the decryption key, they can decrypt the other transactions, and learn about the resulting price movement over the course of the block. By choosing the timestamp for the next block accordingly (even if it increases, odd if it decreases), they can effectively frontrun.\nThe sequencer can thus potentially gain an unfair advantage by executing transactions based on privileged information before other participants.\nAs a possible prevention mechanism, the sequencer has to commit to all variable block parameters already in the previous block. In order to prevent any degrees of freedom in the block attributes, the sequencer has to pre-commit to the block attributes difficulty, layer1-origin-hash, coinbase, and timestamp.\nHowever, this step has to be carefully considered in order to make sure normal operation is not negatively affected.\nDesign Options\nBlock or Transaction Keys\nShutter uses an identity-based encryption scheme. This means that the encryption key is derived from the eon public key and an identity, an arbitrary parameter. This parameter is also used when the corresponding decryption key is generated. There are two major options how to choose the identity:\n\none identity per block (e.g., the block number)\none identity per transaction (e.g., a custom nonce)\n\nThe advantage of block keys is efficiency: Only a single decryption key per block has to be generated and included in each block. However, they have a negative UX impact: Before sending a transaction, users have to figure out what the identity value of the next block will be (or rather, the identity value of the block in which they want their payload to be executed). This can be difficult if network latency is high and may lead to higher confirmation times if users have to estimate more conservatively. In addition, encrypted payloads will be revealed even if the transaction is not included at all, e.g., due to high latency, network congestion, or a malicious sequencer. Note however, that an already revealed transaction can not be included later on, so this does not make the transaction susceptible for frontrunning.\nTransaction keys, on the other hand, can be derived purely locally without any knowledge over the state of the system. This makes the user experience maximally straightforward and prevents revelation without inclusion. On the other hand, the system is less efficient because for each transaction a separate key has to be included.\nFuture Considerations\nFor the purpose of this proposal, practicality and low implementation complexity were primary goals. When these become less important in future versions, more options open up. Here we describe three.\nInstead of including encrypted transactions in the chain and decrypting them during execution, it is possible to do the opposite: Only commit to a hash of all encrypted payloads, and at time of execution only include the decrypted payloads. As part of the state transition function, the payloads would be encrypted again in order to check correctness against the commitment. This approach is more efficient: Decrypted transactions can be compressed much better than encrypted ones, so they use less of the expensive L1 space.\nThe main drawback of this, however, is a much higher complexity in the sequencer: They need to keep track of which transactions they have committed to in the previous block. If they lose this data, e.g., during a crash at an inconvenient time, they will be unable to produce a valid block and the system is stuck.\nZero knowledge proofs are another potential tool to increase efficiency: A zkSNARK that proves correct decryption would allow omitting the decryption keys from the chain altogether, thus severely limiting the L1 footprint of the system, in particular if transaction keys instead of block keys are chosen. Furthermore, users could use zero knowledge proofs to make statements about their account balances without revealing the sender account, which in the current system is leaked to potential attackers. Unfortunately, zero knowledge technology is still somewhat complex.\nLastly, a potential modification to make reorg attacks by the sequencer much harder is to involve the keyper committee: In addition and simultaneous to the decryption key generation, they could produce a threshold signature on the current head of the chain. The state transition function would check this signature in order to make sure that no reorg has happened. In order to successfully attack, the sequencer would thus not only have to produce a competing block, but also require the keypers to sign it off.\nConclusion\nIn this document, we have proposed modifications to the OP Stack to provide front-running protection and censorship resistance to its users. The required changes are relatively small in scale, not overly complex, and viable to implement.\nWe have evaluated failure cases and outlined robust solutions for such scenarios, with the legacy system always serving as a fallback point to recover to, even in the worst-case.\nNotably, the proposed architecture does not compromise the user experience of normal transactions, while also providing an only slightly diminished user experience for front-running protected transactions. Importantly., it is possible to submit encrypted transactions with standard wallets, requiring only small frontend modifications that can be implemented straightforwardly by using a provided library.\nOverall, the outlined software architecture lays a solid foundation for a front-running protection system, balancing practicality, complexity, and security.\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Due to character limits, we had to split this up into multiple posts. Here’s the whole document as a PDF.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP as an MEV staking token\n\n ✨ General\n\n Hi everyone, I wanted to make an alternate proposal than Enabling $OP as a gas token on Optimism Network!. This is an approach which mirrors PoS as well as Fuel Labs. \nThis is not a token price scheme, please read the fu…\n\n read more\n\n 13\n\n 3.8k\n\n Aug 2022\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved\n\n Metagovernance\n\n Optimism is experiencing rapid growth, but this is a double-edged sword. Currently, Optimism is a centrally operated network where, as far as I’m aware, unknown entities across Optimism Foundation, OP Labs or associates …\n\n read more\n\n 26\n\n 5.5k\n\n Dec 2022\n\n Infrastructure & Dependencies nominations for RPGF2\n\n Retro Funding Missions\n\n round-2\n\n Infrastructure & Dependencies nominations for RetroPGF2\nThis is the thread to nominate projects for the Infrastructure and dependencies category of RetroPGF round 2. Please familiarize yourself with the Nominations proce…\n\n read more\n\n 120\n\n 12.7k\n\n Jan 2023","tokens":10293,"squid":"ink-governance","role":"Council Listener","at":1791259635392,"hash":"dea5d3f3a5ebdaa52795b1d65cadd885670c4c55"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/pool","domain":"aave.com","title":"Pool | Aave Protocol Documentation","text":"Pool#\nThis contract is the main user-facing contract. Most user interactions with the Aave Protocol occur via the Pool contract. It exposes the liquidity management methods that can be invoked using either Solidity or Web3 libraries.\nPool.sol allows users to:\nSupplyWithdrawBorrowRepayEnable/disable supplied assets as collateralLiquidate positionsExecute Flash Loans\nPool is covered by a proxy contract and is owned by the PoolAddressesProvider of the specific market. All admin functions are callable by the PoolConfigurator contract defined in the PoolAddressesProvider.\nThe source code is available on GitHub.\nWrite Methods#\ninitialize#\nfunction initialize(IPoolAddressesProvider provider) external virtual\nInitializes the Pool.\nFunction is invoked by the proxy contract when the Pool contract is added to the PoolAddressesProvider of the market.\nCaches the address of the PoolAddressesProvider in order to reduce gas consumption on subsequent operations.\nInput Parameters:#\nNameTypeDescriptionprovideraddressThe address of the PoolAddressesProvider\nsupply#\nfunction supply( address asset, uint256 amount, address onBehalfOf, uint16 referralCode) public virtual override\nSupplies a certain amount of an asset into the protocol, minting the same amount of corresponding aTokens and transferring them to the onBehalfOf address. For example, if a user supplies 100 USDC and onBehalfOf address is the same as msg.sender, they will get 100 aUSDC in return.\nThe referralCode is emitted in Supply event and can be for third-party referral integrations. To activate the referral feature and obtain a unique referral code, integrators need to submit a proposal to Aave Governance.\nWhen supplying, the Pool contract must have allowance() to spend funds on\nbehalf of msg.sender for at least the amount for the asset being supplied.\nThis can be done via the standard ERC20 approve() method on the underlying\ntoken contract.\nReferral supply is currently inactive, you can pass 0 as referralCode.\nThis program may be activated in the future through an Aave governance\nproposal.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset being supplied to the poolamountuint256The amount of asset to be suppliedonBehalfOfaddressThe address that will receive the corresponding aTokens. This is the only address that will be able to withdraw the asset from the pool. This will be the same as msg.sender if the user wants to receive aTokens into their own wallet, or use a different address if the beneficiary of aTokens is a different walletreferralCodeuint16Referral supply is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-men\nsupplyWithPermit#\nfunction supplyWithPermit( address asset, uint256 amount, address onBehalfOf, uint16 referralCode, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS) public virtual override\nSupply with transfer approval of the asset to be supplied via permit function. This method removes the need for separate approval tx before supplying asset to the pool. See: https://eips.ethereum.org/EIPS/eip-2612.\nPermit signature must be signed by msg.sender with spender as Pool address.\nReferral program is currently inactive, you can pass 0 as referralCode.\nThis program may be activated in the future through an Aave governance\nproposal.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of underlying asset being supplied. The same asset as used in permit v, s, and ramountuint256The amount of asset to be supplied and signed for approval. The same amount as used in permit v, s, and ronBehalfOfaddressThe address that will receive the aTokens. This will be the same as msg.sender if the user wants to receive aTokens into their own wallet, or use a different address if the beneficiary of aTokens is a different walletreferralCodeuint16Referral supply is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-mendeadlineuint256The unix timestamp up until which the permit signature is validpermitVuint8The v parameter of the ERC712 permit signaturepermitRbytes32The r parameter of the ERC712 permit signaturepermitSbytes32The s parameter of the ERC712 permit signature\nwithdraw#\nfunction withdraw(address asset, uint256 amount, address to) public virtual override returns (uint256)\nWithdraws an amount of underlying asset from the reserve, burning the equivalent aTokens owned. For example, if a user has 100 aUSDC and calls withdraw(), they will receive 100 USDC, burning the 100 aUSDC.\nIf user has any existing debt backed by the underlying token, then the maximum amount available to withdraw is the amount that will not leave user's health factor < 1 after withdrawal.\nWhen withdrawing to another address, msg.sender should have aToken that\nwill be burned by Pool.\nReserves with a Loan To Value parameter of 0% must be disabled as collateral\n(using Pool.setUserUseReserveAsCollateral or by fully withdrawing the\nsupplied balance) before other assets can be withdrawn.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset to withdraw, not the aTokenamountuint256The underlying amount to be withdrawn (the amount supplied), expressed in wei units. Use type(uint).max to withdraw the entire aToken balancetoaddressThe address that will receive the underlying asset. This will be the same as msg.sender if the user wants to receive the tokens into their own wallet, or use a different address if the beneficiary is a different wallet\nReturn Values:#\nTypeDescriptionuint256The final amount withdrawn\nborrow#\nfunction borrow( address asset, uint256 amount, uint256 interestRateMode, uint16 referralCode, address onBehalfOf) public virtual override\nAllows users to borrow a specific amount of the reserve underlying asset, provided the borrower has already supplied enough collateral, or they were given enough allowance by a credit delegator on the corresponding debt token (VariableDebtToken). For example, if a user borrows 100 USDC passing their own address as onBehalfOf, they will receive 100 USDC into their wallet and 100 variable debt tokens.\nNOTE: If onBehalfOf is not the same as msg.sender, then onBehalfOf must\nhave supplied enough collateral via supply() and have delegated credit to\nmsg.sender via approveDelegation().\nReferral program is currently inactive, you can pass 0 as referralCode.\nThis program may be activated in the future through an Aave governance\nproposal.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset to borrowamountuint256The amount to be borrowed, expressed in wei unitsinterestRateModeuint256Should always be passed a value of 2 (variable rate mode)referralCodeuint16Referral supply is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-menonBehalfOfaddressThis should be the address of the borrower calling the function if they want to borrow against their own collateral, or the address of the credit delegator if the caller has been given credit delegation allowance\nrepay#\nfunction repay( address asset, uint256 amount, uint256 interestRateMode, address onBehalfOf) public virtual override returns (uint256)\nRepays a borrowed amount on a specific reserve, burning the equivalent debt tokens owned. For example, if a user repays 100 USDC, the 100 variable debt tokens owned by the onBehalfOf address will be burned.\nWhen repaying, the Pool contract must have allowance to spend funds on\nbehalf of msg.sender for at least the amount for the asset you are\nrepaying with. This can be done via the standard ERC20 approve() method on\nthe underlying token contract.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the borrowed underlying asset previously borrowedamountuint256The amount to repay, expressed in wei units. Use type(uint256).max in order to repay the whole debt, ONLY when the repayment is not executed on behalf of a 3rd party. In case of repayments on behalf of another user, it's recommended to send an amount slightly higher than the current borrowed amountinterestRateModeuint256Only available option is 2 (variableRateMode)onBehalfOfaddressThe address of the user who will get their debt reduced/removed. This should be the address of the user calling the function if they want to reduce/remove their own debt, or the address of any other borrower whose debt should be removed\nrepayWithPermit#\nfunction repayWithPermit( address asset, uint256 amount, uint256 interestRateMode, address onBehalfOf, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS) public virtual override returns (uint256)\nRepay with transfer approval of the borrowed asset to be repaid, done via permit function. This method removes the need for separate approval tx before repaying asset to the pool. See: https://eips.ethereum.org/EIPS/eip-2612.\nPermit signature must be signed by msg.sender with spender value as Pool\naddress.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the borrowed underlying asset previously borrowed. The same asset as used in permit v, r, and samountuint256The amount to repay, expressed in wei units. Use type(uint256).max in order to repay the whole debt to pay without leaving aToken dust. The same amount as used in permit v,r,sinterestRateModeuint256Only available option is 2 (variableRateMode)onBehalfOfaddressThe address of the user who will get their debt reduced/removed. This should be the address of the user calling the function if they want to reduce/remove their own debt, or the address of any other borrower whose debt should be removeddeadlineuint256The unix timestamp up until which the permit signature is validpermitVuint8The v parameter of the ERC712 permit signaturepermitRbytes32The r parameter of the ERC712 permit signaturepermitSbytes32The s parameter of the ERC712 permit signature\nReturn Values:#\nTypeDescriptionuint256The final amount repaid\nrepayWithATokens#\nfunction repayWithATokens(address asset, uint256 amount, uint256 interestRateMode) public virtual override returns (uint256)\nAllows a user to repay a borrowed amount on a specific reserve using the reserve aTokens, burning the equivalent debt tokens. For example, a user repays 100 USDC using 100 aUSDC, burning 100 variable debt tokens. Passing uint256.maxas the amount will clean up any residual aToken dust balance, if the user aToken balance is not enough to cover the whole debt.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the borrowed underlying asset previously borrowedamountuint256The amount to repay. Use type(uint256).max in order to repay the whole debt for asset to pay without leaving aToken dustinterestRateModeuint256Only available option is 2 (variableRateMode)\nReturn Values:#\nTypeDescriptionuint256The final amount repaid\nsetUserUseReserveAsCollateral#\nfunction setUserUseReserveAsCollateral(address asset, bool useAsCollateral) public virtual override\nAllows suppliers to enable/disable a specific supplied asset as collateral. Sets the asset of msg.sender to be used as collateral or not.\nAn asset in Isolation Mode can be enabled to use as collateral\nonly if no other asset is already enabled to use as collateral.\nAn asset with LTV parameter of 0% cannot be enabled as collateral.\nThe user won’t be able to disable an asset as collateral if they have an outstanding debt position which could be left with the Health Factor < HEALTH_FACTOR_LIQUIDATION_THRESHOLD on disabling the given asset as collateral.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset supplieduseAsCollateralbooltrue if the user wants to use the supply as collateral, false otherwise\nliquidationCall#\nfunction liquidationCall( address collateralAsset, address debtAsset, address user, uint256 debtToCover, bool receiveAToken) public virtual override\nFunction to liquidate a non-healthy position collateral-wise, with Health Factor below 1.\nWhen the health factor of a position is below 1, the caller (liquidator) repays the debtToCover amount of debt of the user getting liquidated. This is part or all of the outstanding borrowed amount on behalf of the borrower. The caller then receives a proportional amount of the collateralAsset (discounted amount of collateral) plus a liquidation bonus to cover market risk.\nLiquidators can decide if they want to receive an equivalent amount of collateral aTokens instead of the underlying asset. When the liquidation is completed successfully, the health factor of the position is increased, bringing the health factor above 1.\nLiquidators can only close a certain amount of collateral defined by a close factor. Currently the close factor is 0.5. In other words, liquidators can only liquidate a maximum of 50% of the amount pending to be repaid in a position. The liquidation discount applies to this amount.\nIn most scenarios, profitable liquidators will choose to liquidate as much as they can (50% of the user position).debtToCover parameter can be set to uint(-1) and the protocol will proceed with the highest possible liquidation allowed by the close factor.To check a user's health factor, use [getUserAccountData()].\nLiquidators must approve() the Pool contract to use debtToCover of the\nunderlying ERC20 of the asset used for the liquidation.\nInput Parameters:#\nNameTypeDescriptioncollateralAssetaddressThe address of the underlying asset used as collateral, to receive as result of the liquidationdebtAssetaddressThe address of the underlying borrowed asset to be repaid with the liquidationuseraddressThe address of the borrower getting liquidateddebtToCoveruint256The debt amount of borrowed asset the liquidator will repayreceiveATokenbooltrue if the liquidator wants to receive the aTokens equivalent of the purchased collateral, false if they want to receive the underlying collateral asset directly\nflashLoan#\nfunction flashLoan( address receiverAddress, address[] calldata assets, uint256[] calldata amounts, uint256[] calldata interestRateModes, address onBehalfOf, bytes calldata params, uint16 referralCode) public virtual override\nAllows users to access liquidity of the pool for a given list of assets within one transaction, as long as the amount taken plus a fee is returned. The receiver must approve the Pool contract for at least the amount borrowed + fee, otherwise the transaction will revert.\nThe flash loan fee is waived for approved FLASH_BORROWER.\nThere are security concerns for developers of flashloan receiver contracts\nthat must be taken into consideration. For further details, visit Flash Loan\nDevelopers Guide.\nReferral program is currently inactive, you can pass 0 as referralCode.\nThis program may be activated in the future through an Aave governance\nproposal.\nInput Parameters:#\nNameTypeDescriptionreceiverAddressaddressThe address of the contract receiving the flash-borrowed funds, implementing the IFlashLoanReceiver interfaceassetsaddress[]The addresses of the assets being flash-borrowedamountsuint256[]The amounts of the assets being flash-borrowed. This needs to contain the same number of entries as assetsinterestRateModesuint256[]The types of the debt position to open if the flash loan is not returned: 0 -> Don't open any debt, the amount + fee must be paid in this case or just revert if the funds can't be transferred from the receiver. 2 -> Open variable rate borrow position for the value of the amount flash-borrowed to the onBehalfOf addressonBehalfOfaddressThe address that will receive the debt if the associated interestRateModes is 1 or 2. onBehalfOf must already have approved sufficient borrow allowance of the associated asset to msg.senderparamsbytesVariadic packed params to pass to the receiver as extra informationreferralCodeuint16Referral supply is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-men\nflashLoanSimple#\nfunction flashLoanSimple( address receiverAddress, address asset, uint256 amount, bytes calldata params, uint16 referralCode) public virtual override\nAllows users to access liquidity of the pool for a given asset within one transaction, as long as the amount taken plus a fee is returned. The receiver must approve the Pool contract for at least the amount borrowed + fee, otherwise the transaction will revert.\nThis function does not waive the fee for approved FLASH_BORROWER, nor does it allow for opening a debt position instead of repaying.\nThere are security concerns for developers of flashloan receiver contracts\nthat must be kept into consideration.\nReferral program is currently inactive, you can pass 0 as referralCode.\nThis program may be activated in the future through an Aave governance\nproposal.\nInput Parameters:#\nNameTypeDescriptionreceiverAddressaddressThe address of the contract receiving the flash-borrowed funds, implementing the IFlashLoanReceiver interfaceassetaddressThe address of the asset being flash-borrowedamountuint256The amount of the asset being flash-borrowedparamsbytesVariadic packed params to pass to the receiver as extra informationreferralCodeuint16Referral supply is currently inactive, you can pass 0. This code is used to register the integrator originating the operation, for potential rewards. 0 if the action is executed directly by the user, without any middle-men\nmintToTreasury#\nfunction mintToTreasury(address[] calldata assets) external virtual override\nMints the assets accrued through the reserve factor to the treasury in the form of aTokens for the given list of assets.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of reserves for which the minting needs to be executed\nfinalizeTransfer#\nfunction finalizeTransfer( address asset, address from, address to, uint256 amount, uint256 balanceFromBefore, uint256 balanceToBefore) external virtual override\nValidates and finalizes an aToken transfer. It is only callable by the overlying aToken of the asset.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the aTokenfromaddressThe user from which the aTokens are transferredtoaddressThe user receiving the aTokensamountuint256The amount being transferred/withdrawnbalanceFromBeforeuint256The aToken balance of the from user before the transferbalanceToBeforeuint256The aToken balance of the to user before the transfer\nsetUserEMode#\nfunction setUserEMode(uint8 categoryId) external virtual override\nAllows a user to use the protocol in efficiency mode. The category id must be a valid id already defined by Pool or Risk Admins.\nWill revert if user is borrowing non-compatible asset or if the change will drop the Health Factor < HEALTH_FACTOR_LIQUIDATION_THRESHOLD.\nInput Parameters:#\nNameTypeDescriptioncategoryIduint8The eMode category id (0 - 255) defined by Risk or Pool Admins. categoryId set to 0 is a non eMode category\ninitReserve#\nfunction initReserve( address asset, address aTokenAddress, address stableDebtAddress, address variableDebtAddress, address interestRateStrategyAddress) external virtual override onlyPoolConfigurator\nInitializes a reserve, activating it, assigning an aToken and debt tokens and an interest rate strategy.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveaTokenAddressaddressThe address of the aToken that will be assigned to the reservestableDebtAddressaddressThe address of the StableDebtToken that will be assigned to the reserve (deprecated)variableDebtAddressaddressThe address of the VariableDebtToken that will be assigned to the reserveinterestRateStrategyAddressaddressThe address of the interest rate strategy contract\ndropReserve#\nfunction dropReserve(address asset) external virtual override onlyPoolConfigurator\nDrop a reserve.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nsetReserveInterestRateStrategyAddress#\nfunction setReserveInterestRateStrategyAddress(address asset, address rateStrategyAddress) external virtual override onlyPoolConfigurator\nUpdates the address of the interest rate strategy contract.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserverateStrategyAddressaddressThe address of the interest rate strategy contract\nsetConfiguration#\nfunction setConfiguration(address asset, DataTypes.ReserveConfigurationMap calldata configuration) external virtual override onlyPoolConfigurator\nSets the configuration bitmap of the reserve as a whole.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveconfigurationDataTypes.ReserveConfigurationMapThe new configuration bitmap\nThe DataTypes.ReserveConfigurationMap struct is composed of the following fields:\nbitDescription0-15LTV16-31Liquidation threshold32-47Liquidation bonus48-55Decimals56Reserve is active57Reserve is frozen58Borrowing is enabled59Stable rate borrowing enabled (deprecated)60Asset is paused61Borrowing in isolation mode is enabled62Siloed borrowing is enabled63Flashloaning is enabled64-79Reserve factor80-115Borrow cap in whole tokens, borrowCap == 0 => no cap116-151Supply cap in whole tokens, supplyCap == 0 => no cap152-167Liquidation protocol fee168-175eMode category (deprecated)176-211Unbacked mint cap in whole tokens, unbackedMintCap == 0 => minting disabled212-251Debt ceiling for isolation mode with (ReserveConfiguration::DEBT_CEILING_DECIMALS) decimals252Virtual accounting is enabled253-255Unused\nupdateBridgeProtocolFee#\nfunction updateBridgeProtocolFee(uint256 protocolFee) external virtual override onlyPoolConfigurator\nUpdates the protocol fee on the bridging.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionprotocolFeeuint256The part of the premium sent to the protocol treasury\nupdateFlashloanPremiums#\nfunction updateFlashloanPremiums(uint128 flashLoanPremiumTotal, uint128 flashLoanPremiumToProtocol) external virtual override onlyPoolConfigurator\nUpdates flash loan premiums. A flash loan premium consists of two parts:\nA part is sent to aToken holders as extra, one time accumulated interestA part is collected by the protocol treasury\nThe total premium is calculated on the total borrowed amount. The premium to protocol is calculated on the total premium, being a percentage of flashLoanPremiumTotal.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionflashLoanPremiumTotaluint128The total premium, expressed in bpsflashLoanPremiumToProtocoluint128The part of the premium sent to the protocol treasury, expressed in bps\nconfigureEModeCategory#\nfunction configureEModeCategory(uint8 id, DataTypes.EModeCategory memory category) external virtual override onlyPoolConfigurator\nConfigures a new category for the eMode. In eMode, the protocol allows very high borrowing power to borrow assets of the same category. The category 0 is reserved for volatile heterogeneous assets and it's always disabled.\nEach eMode category has a custom ltv and liquidation threshold. Each eMode category may or may not have a custom oracle to override the individual assets price oracles.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptioniduint8The total premium, expressed in bpscategoryDataTypes.EModeCategoryThe configuration of the category\nThe DataTypes.EModeCategory struct is composed of the following fields:\nNameTypeDescriptionltvuint16The custom Loan to Value for the eMode categoryliquidationThresholduint16The custom liquidation threshold for the eMode categoryliquidationBonusuint16The liquidation bonus for the eMode categorycollateralBitmapuint128Bitmap of collateral assets in the categorylabelstringThe custom label describing the eMode categoryborrowableBitmapuint128Bitmap of borrowable assets in the category\nresetIsolationModeTotalDebt#\nfunction resetIsolationModeTotalDebt(address asset) external virtual override onlyPoolConfigurator\nResets the isolation mode total debt of the given asset to zero. It requires the given asset to have a zero debt ceiling.\nOnly callable by the PoolConfigurator contract.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset to reset the isolationModeTotalDebt\nrescueTokens#\nfunction rescueTokens(address token, address to, uint256 amount) external virtual override onlyPoolAdmin\nRescue and transfer tokens locked in this contract.\nOnly available to POOL_ADMIN role. Pool admin is\nselected by the governance.\nInput Parameters:#\nNameTypeDescriptiontokenaddressThe address of the tokentoaddressThe address of the recipientamountuint256The amount of token to transfer\neliminateReserveDeficit#\nCovers the deficit of a specified reserve by burning the equivalent aToken amount for assets with virtual accounting enabled or the equivalent amount of underlying for assets with virtual accounting disabled (e.g. GHO). Only callable by address with onlyUmbrella modifier.\nfunction eliminateReserveDeficit(address asset, uint256 amount) external;\nInput Parameters:#\nNameTypeDescriptionassetaddressUnderlying token addressamountuint256The amount to be covered, in aToken or underlying on non-virtual accounted assets\nView Methods#\ngetUserAccountData#\nfunction getUserAccountData(address user) external view virtual override returns ( uint256 totalCollateralBase, uint256 totalDebtBase, uint256 availableBorrowsBase, uint256 currentLiquidationThreshold, uint256 ltv, uint256 healthFactor)\nReturns the user account data across all the reserves.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:#\nNameTypeDescriptiontotalCollateralBaseuint256The total collateral of the user in the base currency used by the price feedtotalDebtBaseuint256The total debt of the user in the base currency used by the price feedavailableBorrowsBaseuint256The borrowing power left of the user in the base currency used by the price feedcurrentLiquidationThresholduint256The liquidation threshold of the userltvuint256The loan to value of the userhealthFactoruint256The current health factor of the user\ngetConfiguration#\nfunction getConfiguration(address asset) external view virtual override returns (DataTypes.ReserveConfigurationMap memory)\nReturns the configuration of the reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionDataTypes.ReserveConfigurationMapThe configuration of the reserve\nThe DataTypes.ReserveConfigurationMap struct is composed of the following fields:\nbitDescription0-15LTV16-31Liquidation threshold32-47Liquidation bonus48-55Decimals56Reserve is active57Reserve is frozen58Borrowing is enabled59Stable rate borrowing enabled (deprecated)60Asset is paused61Borrowing in isolation mode is enabled62Siloed borrowing enabled63Flashloaning enabled64-79Reserve factor80-115Borrow cap in whole tokens, borrowCap == 0 => no cap116-151Supply cap in whole tokens, supplyCap == 0 => no cap152-167Liquidation protocol fee168-175eMode category (deprecated)176-211Unbacked mint cap in whole tokens, unbackedMintCap == 0 => minting disabled212-251Debt ceiling for isolation mode with (ReserveConfiguration::DEBT_CEILING_DECIMALS) decimals252Virtual accounting is enabled for the reserve253-255Unused\ngetUserConfiguration#\nfunction getUserConfiguration(address user) external view virtual override returns (DataTypes.UserConfigurationMap memory)\nReturns the configuration of the user across all the reserves.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe user address\nReturn Values:#\nTypeDescriptionDataTypes.UserConfigurationMapThe configuration of the user\nThe DataTypes.UserConfigurationMap struct is composed of the following fields:\nNameTypeDescriptiondatauint256Bitmap of the users collaterals and borrows. It is divided into pairs of bits, one pair per asset. The first bit indicates if an asset is used as collateral by the user, the second whether an asset is borrowed by the user. The corresponding assets are in the same position as getReservesList(). For example, if the hex value returned is 0x40020, which represents a decimal value of 262176, then in binary it is 1000000000000100000. If we format the binary value into pairs, starting from the right, we get 1 00 00 00 00 00 00 10 00 00. If we start from the right and move left in the above binary pairs, the third pair is 10. Therefore the 1 indicates that third asset from the reserveList is used as collateral, and 0 indicates it has not been borrowed by this user\ngetReserveNormalizedIncome#\nfunction getReserveNormalizedIncome(address asset) external view virtual override returns (uint256)\nReturns the ongoing normalized income for the reserve.\nA value of 1e27 means there is no income. As time passes, the yield is accrued. A value of 2*1e27 means for each unit of asset, one unit of income has been accrued.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The reserve's normalized income\ngetReserveNormalizedVariableDebt#\nfunction getReserveNormalizedVariableDebt(address asset) external view virtual override returns (uint256)\nReturns the normalized variable debt per unit of asset.\nA value of 1e27 means there is no debt. As time passes, the debt is accrued. A value of 2*1e27 means that for each unit of debt, one unit worth of interest has been accumulated.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The reserve normalized variable debt\ngetReservesList#\nfunction getReservesList() external view virtual override returns (address[] memory)\nReturns the list of the underlying assets of all the initialized reserves. It does not include dropped reserves.\nReturn Values:#\nTypeDescriptionaddress[]The addresses of the underlying assets of the initialized reserves\ngetReserveAddressById#\nfunction getReserveAddressById(uint16 id) external view returns (address)\nReturns the address of the underlying asset of a reserve by the reserve id as stored in the DataTypes.ReserveData struct.\nInput Parameters:#\nNameTypeDescriptioniduint16The id of the reserve as stored in the DataTypes.ReserveData struct\nReturn Values:#\nTypeDescriptionaddressThe address of the reserve associated with id\ngetEModeCategoryData#\nfunction getEModeCategoryData(uint8 id) external view virtual override returns (DataTypes.EModeCategory memory)\nReturns the data of an eMode category.\nEach eMode category has a custom LTV and liquidation threshold. Each eMode category may or may not have a custom oracle to override the individual assets' price oracles.\nInput Parameters:#\nNameTypeDescriptioniduint8The id of the category\nReturn Values:#\nTypeDescriptionDataTypes.EModeCategoryThe configuration data of the category\nThe DataTypes.EModeCategory struct is composed of the following fields:\nNameTypeDescriptionltvuint16The custom Loan to Value for the eMode categoryliquidationThresholduint16The custom liquidation threshold for the eMode categoryliquidationBonusuint16The liquidation bonus for the eMode categorycollateralBitmapuint128Bitmap of collateral assets in the categorylabelstringThe custom label describing the eMode categoryborrowableBitmapuint128Bitmap of borrowable assets in the category\ngetReserveData#\nfunction getReserveData(address asset) external view virtual override returns (DataTypes.ReserveData memory)\nReturns the state and configuration of the reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionDataTypes.ReserveDataThe state and configuration data of the reserve\nThe DataTypes.ReserveData struct is composed of the following fields:\nNameTypeDescriptionconfigurationReserveConfigurationMapStores the reserve configurationliquidityIndexuint128The yield generated by the reserve during time interval since lastUpdatedTimestamp. Expressed in raycurrentLiquidityRateuint128The current supply rate. Expressed in rayvariableBorrowIndexuint128The yield accrued by reserve during time interval since lastUpdatedTimestamp. Expressed in raycurrentVariableBorrowRateuint128The current variable borrow rate. Expressed in ray__deprecatedStableBorrowRateuint128DEPRECATED on v3.2.0lastUpdateTimestampuint40The timestamp of when reserve data was last updated. Used for yield calculationiduint16The id of the reserve. It represents the reserve’s position in the list of active reservesliquidationGracePeriodUntiluint40The timestamp until liquidations are not allowed on the reserve. If set to the past, liquidations will be allowedaTokenAddressaddressThe address of associated aToken__deprecatedStableDebtTokenAddressaddressDEPRECATED on v3.2.0variableDebtTokenAddressaddressThe address of associated variable debt tokeninterestRateStrategyAddressaddressThe address of interest rate strategyaccruedToTreasuryuint128The current treasury balance (scaled)unbackeduint128The outstanding unbacked aTokens minted through the bridging featureisolationModeTotalDebtuint128The outstanding debt borrowed against this asset in isolation modevirtualUnderlyingBalanceuint128The virtual balance of the underlying asset for yield calculation purposes\ngetUserEMode#\nfunction getUserEMode(address user) external view virtual override returns (uint256)\nReturns eMode the user is using. 0 is a non eMode category.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:#\nTypeDescriptionuint256The eMode id\nFLASHLOAN_PREMIUM_TOTAL#\nfunction FLASHLOAN_PREMIUM_TOTAL() public view virtual override returns (uint128)\nReturns the percent of total flashloan premium paid by the borrower.\nA part of this premium is added to reserve's liquidity index i.e. paid to the liquidity provider and the other part is paid to the protocol i.e. accrued to the treasury.\nReturn Values:#\nTypeDescriptionuint128The total fee on flashloans\nBRIDGE_PROTOCOL_FEE#\nfunction BRIDGE_PROTOCOL_FEE() public view virtual override returns (uint256)\nReturns the part of the bridge fees sent to protocol.\nReturn Values:#\nTypeDescriptionuint256The percentage of available liquidity to borrow, expressed in bps\nFLASHLOAN_PREMIUM_TO_PROTOCOL#\nfunction FLASHLOAN_PREMIUM_TO_PROTOCOL() public view virtual override returns (uint128)\nReturns the percent of flashloan premium that is accrued to the treasury.\nReturn Values:#\nTypeDescriptionuint128The percentage of available liquidity to borrow, expressed in bps\nMAX_NUMBER_RESERVES#\nfunction MAX_NUMBER_RESERVES() public view virtual override returns (uint16)\nReturns the maximum number of reserves supported to be listed in this Pool.\nReturn Values:#\nTypeDescriptionuint16The maximum number of reserves supported\ngetLiquidationGracePeriod#\nReturns the liquidation grace period of the given asset\nfunction getLiquidationGracePeriod(address asset) external view virtual override returns (uint40)\nInput Parameters:#\nNameTypeDescriptionassetaddressUnderlying token address\nReturn Values:#\nTypeDescriptionuint256Timestamp when the liquidation grace period will end\ngetReserveDeficit#\nReturns the current deficit of a reserve.\nfunction getReserveDeficit(address asset) external view returns (uint256);\nInput Parameters:#\nNameTypeDescriptionassetaddressUnderlying token address\nReturn Values:#\nTypeDescriptionuint256Current reserve deficit from undercollateralized borrow positions\ngetReserveAToken#\nReturns the aToken address of a reserve.\nfunction getReserveAToken(address asset) external view returns (address);\nInput Parameters:#\nNameTypeDescriptionassetaddressUnderlying token address\nReturn Values:#\nTypeDescriptionaddressThe address of the AToken\ngetReserveVariableDebtToken#\nReturns the variableDebtToken address of a reserve.\nfunction getReserveVariableDebtToken(address asset) external view returns (address);\nInput Parameters:#\nNameTypeDescriptionassetaddressUnderlying token address\nReturn Values:#\nTypeDescriptionaddressThe address of the VariableDebtToken\nPure Methods#\ngetRevision#\nfunction getRevision() internal pure virtual override returns (uint256)\nReturns the revision number of the contract. Needs to be defined in the inherited class as a constant.\nReturns 0x1.\nReturn Values:#\nTypeDescriptionuint256The revision numberPreviousSmart ContractsNextL2 Pool","tokens":9223,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259641732,"hash":"374a53871e9a11d7cbbf8ef813e6dcf4daf77f17"}
{"url":"https://gov.optimism.io/c/governance-design-and-strategy/metagovernance/53","domain":"gov.optimism.io","title":"Latest Governance Design and Strategy 📐/Metagovernance topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Metagovernance\n\n Governance Design and Strategy 📐\n\n Metagovernance\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Metagovernance category\n\n Topics related to the operating structure of the Optimism Collective\n\n 0\n\n 558\n\n Jan 2023\n\n Protocol Delegation Program Renewal\n\n season-4\n\n Protocol Delegation Program Renewal\nProtocols building on Optimism are among its most important stakeholders and they value having a voice in the development of the ecosystem. In Season 3, the Protocol Delegation Program…\n\n read more\n\n 37\n\n 5.5k\n\n 1d\n\n Optimism Working Models for Decentralization\n\n Optimism Working Models for Decentralization\nIn the recent weeks, the community has started an important conversation about the Collective’s path towards full decentralization. The Foundation remains fully committed to t…\n\n read more\n\n 16\n\n 1.3k\n\n Jan 20\n\n Season 7: Chain Delegation Program Amended\n\n season-7\n\n Season 7: Chain Delegation Program Amended\nThis is an amended version of the original Chain Delegation Program approved in Season 5. This is the authoritative version for Season 7. \n\nOP Chains play an incredibly importan…\n\n read more\n\n 4\n\n 552\n\n Jan 12\n\n Guide to Season 8\n\n season-8\n\n Season 8 begins on July 31st and runs through December 24th. The New Protocol Upgrade process will go into effect on August 1st. \nPlease read Governance in Season 8: The Next Phase for additional context on Season 8 upda…\n\n read more\n\n 8\n\n 2.9k\n\n Dec 2025\n\n Anticapture Commission Dissolution Proposal\n\n season-7,season-8\n\n Recommendation Against Renewing the Anticapture Commission for Season 8\nFollowing three Seasons of operation and the recent publication of The Future of the Anticapture Commission, the ACC believes it is no longer advisa…\n\n read more\n\n 6\n\n 346\n\n Jul 2025\n\n Season 7 Retro Rewards\n\n Thank You\nA huge thank you is due to delegates and Citizens for their continued dedication to experimentation and iteration. Over the past three years, the Collective’s governance participants have helped establish, boot…\n\n read more\n\n 16\n\n 1.2k\n\n Jul 2025\n\n Season 8 Reflection Period Guide\n\n season-8\n\n Season 8 Reflection Period Guide\nPlease note the new protocol upgrade process will go into effect starting August 1st. \nJune 12th - June 18th: Reflect\n\nReview retrospectives from Season 7:\n\nDeveloper Advisory Board - Ret…\n\n read more\n\n 5\n\n 505\n\n Jun 2025\n\n The Collective Feedback Commission: The Next Iteration\n\n season-7\n\n Collective Feedback Commission: The Next Iteration\nThe Collective Feedback Commission (CFC) was piloted beginning in Season 5 as part of the path to open metagovernance. As outlined in the Collective’s Working Constituti…\n\n read more\n\n 2\n\n 690\n\n Jun 2025\n\n Season 7: Guide to Season 7\n\n season-7\n\n This post serves as an introduction to the upcoming Season of Optimism Governance. The audience for this post is all governance participants (delegates and Citizens). \nIf you’re a builder, check out how to Get a Grant. \nD…\n\n read more\n\n 19\n\n 6.5k\n\n Apr 2025\n\n Season 7: Chain Delegation Program Amendment\n\n season-7\n\n Season 7: Chain Delegation Program Amendment\nThe Chain Delegation Program was introduced in Season 5, to help new OP Chains onboard and build their delegation in Optimism’s governance. As outlined here, the Chain Delegat…\n\n read more\n\n 1\n\n 305\n\n Feb 2025\n\n Season 6: Retro Governance Participation Rewards\n\n season-6\n\n Season 6: Retro Governance Participation Rewards\n\nThank you\nA huge thank you is due to delegates and Citizens for their continued dedication to experimentation and iteration. \nThis Season, the Collective took important s…\n\n read more\n\n 42\n\n 3.6k\n\n Feb 2025\n\n Code of Conduct Council Dissolution Proposal\n\n season-7\n\n Council Dissolution Proposal\nAs outlined in the Operating Manual, a persistent Council is expected to continue into the next Season unless a Dissolution proposal is approved. The Foundation is proposing the dissolution o…\n\n read more\n\n 11\n\n 374\n\n Dec 2024\n\n A case for the organizational chart\n\n season-6\n\n Special thanks to @brichis , @Pumbi and the @govNERDs for the feedback and information support. And to the people at the Developer Advisory Board meeting for motivating to continue. \nDear fellow members of the collective…\n\n read more\n\n 8\n\n 430\n\n Dec 2024\n\n Season 7: Reflection Period Guide\n\n season-7\n\n Season 7: Reflection Period Guide\nSee video explainers on Season 7 Intents here and the Guide to Season 7 here \n\nNovember 21st - November 25th: Reflect\n\nReview retrospectives from Season 6:\n\nCode of Conduct Council - Ret…\n\n read more\n\n 3\n\n 708\n\n Nov 2024\n\n Looking Ahead: Long-term Onchain Governance Architecture\n\n season-6\n\n Looking ahead: Long-term Onchain Governance Architecture\nWe’re thrilled to share some updates and our vision for the future of onchain governance within our ecosystem. As many of you know, Agora has been instrumental in …\n\n read more\n\n 5\n\n 2.0k\n\n Nov 2024\n\n Season 7: CFC Membership\n\n season-7\n\n CFC Membership\nFor the next iteration of the Collective Feedback Commission, we’re experimenting with a new membership selection method. As a reminder, pilot membership was determined via delegation rankings in the Token…\n\n read more\n\n 3\n\n 456\n\n Nov 2024\n\n The Future of Optimism Governance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024\n\n Collective Feedback Commission Pilot Retrospective\n\n retrospective\n\n Collective Feedback Commission Pilot Retrospective\nPilot Recap\n6 months ago, we piloted a Collective Feedback Commission (CFC) as the first step in outlining a path towards open metagovernance. The primary role of the C…\n\n read more\n\n 2\n\n 302\n\n Oct 2024\n\n Season 6: Chain Delegation Program Amendment\n\n season-6\n\n Special thanks to @brichis,@kaereste, and @Porter_Smith for review and feedback on these amendments as part of the Feedback Commission \nSeason 6: Chain Delegation Program Amendment\n\nChain Delegation Program Amendment\nThe…\n\n read more\n\n 13\n\n 1.4k\n\n Sep 2024\n\n Announcing Optimism Fractal’s Intent to Optimize Governance on the Superchain\n\n GM Optimists! I’m pleased to share an exciting update about Optimism Fractal that can greatly help the Optimism Collective and warmly invite you to join our weekly events \nDuring the 30th Optimism…\n\n read more\n\n 0\n\n 274\n\n Aug 2024\n\n Introducing the Collective Feedback Commission\n\n season-5\n\n Introducing the Collective Feedback Commission\nThe Optimism Foundation stewards the development of the Optimism Collective’s governance system. The process by which the Collective takes on more responsibility for the sys…\n\n read more\n\n 8\n\n 2.4k\n\n Aug 2024\n\n How do you feel about a Conflict Committee\n\n As of now, OPerating manual does not have any guideline on handling conflict of interest and I want to hear your opinion on this. \nChallenge:- \n\nLets say a project feels that an entity is voting against their proposal or…\n\n read more\n\n 14\n\n 2.5k\n\n Jun 2024\n\n Code of Conduct Councils\n\n season-5\n\n Update on 06/03/2024: There have been 2 rescopings of the Code of Conduct Council since this original experiment: \n\nProposal to Reclassify Grant Misusage Enforcement\nRescoping #2\n\nThe Code of Conduct Council, if renewed …\n\n read more\n\n 17\n\n 3.2k\n\n Jun 2024\n\n Season 6: Guide to Season 6\n\n season-6\n\n Thanks to members of the Feedback Commission for providing input and feedback on Season 6 drafts. \nGuide to Season 6 \n\nSeason 6 begins on June 27th and runs through December 11th. Grant applications open on July 18…\n\n read more\n\n 2\n\n 3.5k\n\n May 2024\n\n Season 6: Anticapture Commission Amended\n\n season-6\n\n Season 6: Anticapture Commission Amended\nThis is an amended version of the original Anticapture Commission Charter approved in Season 5. This will become the authoritative Charter in the case the Season 6 proposed Amendm…\n\n read more\n\n 0\n\n 533\n\n May 2024\n\n The Path to Open Metagovernance\n\n The Path Towards Open Metagovernance Design\nThe Optimism Foundation stewards the development of the Optimism Collective’s governance system. The process by which the Collective takes on more responsibility for the system…\n\n read more\n\n 11\n\n 8.4k\n\n May 2024\n\n DappRadar DAO’s participation within Optimism Collective\n\n Introduction \nWarm greetings to the Optimism Collective community. Inspired by Base’s initial metagovernance manifesto, we at DappRadar DAO are thrilled to share our own: a strong statement that emphasizes our journey to…\n\n read more\n\n 1\n\n 892\n\n Apr 2024\n\n Onboarding OP Chains to Optimism Governance\n\n Welcoming More OP Chains to the Collective\nLast year, Optimism launched the Superchain, marking the transition from an ecosystem built around a single chain to a Collective aligned towards a shared Superchain vision. The…\n\n read more\n\n 0\n\n 1.1k\n\n Mar 2024\n\n The main differences between the Partner and the Seed fund?\n\n Dear OP forum, \nRecently I have been trying to map out the Optimism Collective and its stakeholders in a flowchart. Something that is not clear to me is what the exact purpose is of the Partner and the Seed funds which t…\n\n read more\n\n 2\n\n 426\n\n Feb 2024","tokens":2334,"squid":"ink-governance","role":"Council Listener","at":1791259645545,"hash":"3d6ffefbf3d331389e6a715342872f2800a39cbe"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/wrapped-token-gateway","domain":"aave.com","title":"Wrapped Token Gateway | Aave Protocol Documentation","text":"Wrapped Token Gateway#\nThe Aave Protocol operates exclusively with ERC-20 reserve tokens. To accommodate network gas tokens, the WrappedTokenGateway (previously called WETHGateway) is a helper contract that enables gas tokens (ETH, POL, etc.) to be wrapped or unwrapped to perform Aave Pool methods:\nSupplyBorrowRepayWithdraw\nThe smart contract source code is available on GitHub.\nWrite Methods#\ndepositETH#\nfunction depositETH( address, address onBehalfOf, uint16 referralCode) external payable override\nWraps and supplies gas tokens to the Aave Protocol. A corresponding amount of the wrapped aTokens are minted to the onBehalfOf address.\nThe amount of network gas tokens to be supplied is specified in the\nmsg.value field of the transaction.\nInput Parameters:#\nNameTypeDescriptiononBehalfOfaddressThe address of the user who will receive the aTokens representing the supplied tokensreferralCodeuint16Inactive, can pass 0 as placeholder\nwithdrawETH#\nfunction withdrawETH( address, uint256 amount, address to) external override\nWithdraws amount of the supplied wrapped gas token, unwraps it and transfers to the to address. If the amount is uint(-1), the entire balance is withdrawn.\nThe WrappedTokenGateway contract must have an approved token allowance to\nspend aWETH on behalf of the user, example:\nIERC20(aWETHAddress).approve(wrappedTokenGatewayAddress, amount)\nInput Parameters:#\nNameTypeDescriptionamountuint256amount of aWETH to withdraw and receive native ETHtoaddressThe address of the user who will receive native ETH\nrepayETH#\nfunction repayETH( address, uint256 amount, uint256 rateMode, address onBehalfOf) external payable override\nRepays a borrow position of onBehalfOf's address for the specified amount (or for the whole amount, if amount of uint256(-1) is passed).\nThe amount of network gas token to be repaid must also be specified in the\nmsg.value field of the transaction.\nInput Parameters:#\nNameTypeDescriptionamountuint256The amount to repay, or uint256(-1) if the user wants to repay everythingrateModeuint256Should always be passed a value of 2 (variable rate mode)onBehalfOfaddressThe address for which msg.sender is repaying\nborrowETH#\nfunction borrowETH( address, uint256 amount, uint256 interestRateMode, uint16 referralCode) external override\nBorrows amount of unwrapped network gas tokens to msg.sender.\nThe WrappedTokenGateway contract must have an approved credit\ndelegation to borrow WETH (or corresponding wrapped gas\ntoken of the network) on behalf of the the caller, example:\nIVariableDebtToken(wethAddress).approveDelegation(wrappedTokenGatewayAddress, amount)\nInput Parameters:#\nNameTypeDescriptionamountuint256The amount of ETH to borrowinterestRateModeuint256Should always be passed a value of 2 (variable rate mode)referralCodeuint16Integrators are assigned a referral code and can potentially receive rewards\nwithdrawETHWithPermit#\nfunction withdrawETHWithPermit( address, uint256 amount, address to, uint256 deadline, uint8 permitV, bytes32 permitR, bytes32 permitS) external override\nWithdraws amount of the supplied wrapped gas token, unwraps it and transfers to the to address. If the amount is uint(-1), the entire balance is withdrawn.\nInput Parameters:#\nNameTypeDescriptionamountuint256The amount of aWETH to withdraw and receive native ETHtoaddressThe address of the user who will receive native ETHdeadlineuint256Timestamp of signature expirationpermitVuint8V parameter of ERC712 permit sigpermitRbytes32R parameter of ERC712 permit sigpermitSbytes32S parameter of ERC712 permit sig\nView Methods#\ngetWETHAddress#\nfunction getWETHAddress() external view returns (address)\nGet WETH address used by WrappedTokenGatewayV3.\nReturn Values:#\nTypeDescriptionaddressThe WETH address used by WrappedTokenGatewayV3PreviousL2 PoolNextView Contracts","tokens":948,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259652945,"hash":"1125e6632be10f630319c9e6f1ef26d84ca154ba"}
{"url":"https://gov.optimism.io/t/guide-to-season-8/10001","domain":"gov.optimism.io","title":"Guide to Season 8 - Governance Design and Strategy 📐 / Metagovernance - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Guide to Season 8 \n\n Governance Design and Strategy 📐Metagovernance\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 4\n min\n\n Jun 2025\n\n 1 / 9\n\n Jun 2025\n\n Dec 2025\n\n post by system on Jun 11, 2025\n\n system\n\n Season 8 begins on July 31st and runs through December 24th. The New Protocol Upgrade process will go into effect on August 1st.\nPlease read Governance in Season 8: The Next Phase for additional context on Season 8 updates.\nDon’t want to read? Join the upcoming community call for an overview of Season 8.\nYou can find all community calls and other dates on the public governance calendar.\n\nCelebrating Season 7 Accomplishments\n\nThank you to all governance participants that contributed in Season 7. You have played a critical role in bootstrapping the Collective’s governance system. You can find retro rewards for Season 7 Here Rewards are made in accordance with the Collective Rewards Framework.\nIn Season 7, we made important steps towards decentralization milestones, which have been updated to reflect Season 8 changes.\n\nGovernance passed 6 protocol upgrades\nMaintenance upgrades (optimistic approval) were introduced to react to L1 hard forks or to perform bugfixes and maintenance on a shorter timeframe\nThe first onchain token transfers were executed\nThe Milestones and Metrics Council managed grant delivery, largely replacing the Foundation in this process\nThe Budget Board was introduced, bringing the first portions of economic policy online\nOP Labs published a public roadmap and SUP process\nGovernance approved staking a portion of sequencer ETH to earn yield for the Collective\n14 OP Chains were onboarded to Optimism Governance via the Chain Delegation Program\nThe Grants Council, Retro Funding, and Futarchy experiments all worked towards pre-defined and measurable success metrics\nThe Collective participated in a futarchy experiment to better understand different methods of making predictions\nGuest voter experiments continued to further understand different Citizenship selection methods\nThe Foundation published regular updates on our working models for decentralization and joined community calls to discuss progress with the community\n\nHow did we get here? Seasons 1 - 7\n\nSeason 1 Theme: Genesis and unstructured community grants\nSeason 2 Theme: Establishing structure with grant committees\nSeason 3 Theme: Refining structure with the Grants Council\nSeason 4 Theme: Working as a Collective (Introduction of Missions, Intents, and Trust Tiers)\nSeason 5 Theme: Governance resiliency (Introduction of the Security Council, Law of Chains, Developer Advisory Board, and Anticapture Commission)\nSeason 6 Theme: Optimizing to support the Superchain (Streamlining of Mission process and other structures, Blockspace Charters, Superchain grants, Chain Delegation Program)\nSeason 7 Theme: Shared success (Alignment around singular Intent and common Mission framework, introduction of Success Metrics)\n\nThe evolution of Seasons are based on 100’s of pieces of feedback documented by the Foundation throughout the Season, reports and analysis conducted by the community, periodic feedback surveys, public feedback threads, the Collective Feedback Commission, retrospectives conducted by community representatives, etc.\nSeason 8 Theme: Purpose-built governance\n The purpose of Optimism governance is to reduce platform risk for the Collective’s stakeholders.\nPlatform risk is the risk to a customer or user that a platform they depend on changes against their interests. It is a common risk of Web 2 platforms and is a key consideration for the largest partners building on the OP Stack.\nSeason 8 introduces several big governance updates that enable our governance system to transition from being “general-purpose” to “purpose-built,” resulting in a system optimized to reduce platform risk for customers and users of the Superchain. See Governance in Season 8: The Next Phase for more info.\nIn Season 8, all contributors to the Collective will leverage this purpose-built governance system to execute on a core pillar of our Superchain Product Vision: Interoperability.\nIntents\nIntents are high level goals. Please see the Season 8 Intents for full details.\nScreenshot 2025-06-12 at 16.22.071056×370 6.51 KB\nThere are three main objectives that will allow us to achieve this intent.\n\nShip Interop\nGrow TVL on the Superchain\nDrive Developer Adoption of Interop\n\nMissions\nCollective contributors work towards the Intents by executing Missions. Missions are specific initiatives aimed at making measurable progress towards the Intent. They are clearly scoped, and can be executed by Collective contributors start-to-finish in less than 12 months.\nIn Season 8, Missions are organized under each objective and may be supported by the Governance Fund or Retroactive Public Goods Funding, as outlined below.\nToken Allocation\nAll incentive programs and the chain delegation program for Season 8 will be available to chains on a fully-standard, governance-approved release of the OP Stack and that have opted into the Security Council (or are on track to). This corresponds to the green + yellow chains (see Superchain Index.)\n\nProject\nBudget Proposed by Budget Board\nFund\nWho selects projects? (Module I)\nWho evaluates impact? (Module H)\nWhen is impact evaluated?\n\nOnchain Builders\nTBD\nRetroactive Public Goods Funding\nAll eligible projects can participate\nOSO\nRegularly throughout Season\n\nDeveloper Tooling\nTBD\nRetroactive Public Goods Funding\nAll eligible projects can participate\nOSO\nRegularly throughout Season\n\nOP Stack Dependencies\nTBD\nRetroactive Public Goods Funding\nAll eligible projects can participate\nOSO\nRegularly throughout Season\n\nGovernance Fund: Grants Council\nTBD\nGovernance Fund\nGrants Council\nMilestones and Metrics Council and/or Open Source Observer\nAt the end of the Season\n\nGovernance Fund: Futarchy\nTBD\nGovernance Fund\nContest outcomes\nMilestones and Metrics Council and/or Open Source Observer\nAt the end of the Season\n\nGovernance Fund: Developer Advisory Board\nTBD\nGovernance Fund\nDeveloper Advisory Board\nMilestones and Metrics Council and/or Open Source Observer\nAt the end of the Season\n\nCouncils, Boards, and Commissions\n\nAll Councils and Boards will operate on 12 month terms\nThe Grants Council, Developer Advisory Board, and Security Council are all persistent Councils expected to continue in Season 8 & 9 unless a Dissolution proposal is put forward and approved as outlined in the Operating Manual. Details about the Council and Board renewal process can be found here.\nGuidance for Councils, Commissions, and Boards can be found here. Additional information about elections will be posted to the forum soon.\n\nUpdates to Citizenship\n\nAs of Season 8, we’ve arrived at a public definition of Citizenship. Three categories of Optimism stakeholders will be represented in the Citizens’ House: chains, apps and end-users. You can read more about the full definition and eligibility requirements in the gov docs.\nPast Citizens can register for Season 8 if they meet the definition of being an end-user (having been active on the Superchain in at least 3 of the past 6 months).\n\nImportant Voting Changes\n\nPlease see Operating Manual for full details\n\nProgress Towards Decentralization\n\nSee updated Decision Diagram and Decentralization Milestones (additional context on updates can be found in the comment here.)\nThe Foundation will continue to post mid-point and end of season progress updates on milestones\n\nSee the Season 8 Reflection Period Guide for detailed outline of what delegates and Citizens need to do during the Reflection Period.\nWe understand delegates have other commitments and may need to step away. Please see the Delegate Resignation Process.\n\n Guide to Season 9\n\n Optimism Gov Summary\n\n 2\n\n read \n\n 4\n min\n\n post by bars26 on Jun 12, 2025\n\n bars26\n\n The progress made in Season 7 was truly impressive — especially the protocol upgrades, futarchy experiments, and onboarding of OP Stack chains into governance. These were all crucial steps toward realizing the Superchain vision.\nNow, with Season 8, we’re entering a new era of purpose-built governance. Reducing platform risk and enabling interoperability are not just technical goals, but a reflection of our collective ability to coordinate.\nThe Intents and Missions are clearly defined, making it easier for everyone to contribute in meaningful ways.\nThe new Citizenship framework brings greater clarity and inclusivity to governance.\nRetro Funding opens exciting new opportunities for builders across the ecosystem.\nLooking forward to building, contributing, and learning together this season.\n\n post by SuperchainEco on Jun 13, 2025\n\n SuperchainEco\n\n ​While we’re still digesting all documents and preparing feedback, there’s one critical comment we want to share now:\nEnding the Season on December 24th will likely result in a low turnout and focus at the end of the season, which is one of the most important periods of the season.\nWe suggest either 1) shorten the Season with ~2 weeks or 2) extend the season with ~3 weeks - so that the Season 8 wrap-up, review, and next season scoping can get the required attention.\n\n post by Mint on Jun 15, 2025\n\n Mint\n\n Season8 makes our team excited. The great era of cross-chain interoperability of the Superchain ecosystem is coming!\n\n post by lavande on Jun 18, 2025\n\n lavande\n\n Following up from the community call:\n\nHere are the slides from the Season 8 Overview (cc @Jrocki)\nYou can find all upgrades and their anticipated timing on the public roadmap - Upgrades 16 and 17 are the interop related upgrades. Upgrade 16 includes the changes required to maintain Stage 1 rating in L2Beat’s framework (cc @GFXlabs)\n\n 21 days later\n\n post by system on Jul 9, 2025\n\n system\n\n Season 8 will be delayed for one week - and will now run from July 31st - December 24th. The decision to delay by one week was discussed with Council and Board Leads. The reason for the delay is to accommodate more time for community review of Operating Budgets.\n\n 2 months later\n\n post by mrberto on Aug 25, 2025\n\n mrberto\n\n looking good team!!! LFG!!!\n\n 1 month later\n\n post by roeder on Oct 3, 2025\n\n roeder\n\n Im super excited for temp 8 campaign. LEsgoo superchain!\n\n 3 months later\n\n post by 0xhayder on Dec 20, 2025\n\n 0xhayder\n\n Amazing what OP is building on!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Season 8 – The Next Step in Optimism Governance\n\n ✨ General\n\n season-8\n\n Season 8 – The Next Step in Optimism Governance\nIntroduction\nSeason 8 marks a new phase in the evolution of the Optimism Collective’s governance. It introduces key improvements to processes and strengthens stakeholder pa…\n\n read more\n\n 2\n\n 262\n\n Sep 2025\n\n Season 7: Guide to Season 7\n\n Metagovernance\n\n season-7\n\n This post serves as an introduction to the upcoming Season of Optimism Governance. The audience for this post is all governance participants (delegates and Citizens). \nIf you’re a builder, check out how to Get a Grant. \nD…\n\n read more\n\n 19\n\n 6.5k\n\n Apr 2025\n\n Joint House Community Calls Summaries - Season 7\n\n Community Calls\n\n season-7\n\n As part of the GovNERDs’ responsibilities, we will be hosting the Token House / Joint House Community Call (occurring on Tuesdays, every other week, at 19:00 UTC, alternating). \n → Here is the link to the OP public gover…\n\n read more\n\n 11\n\n 602\n\n Aug 2025\n\n Governance Update #9\n\n Governance Updates\n\n Governance Update #9\nIt’s been a while since our last governance update, but we wanted to bring these posts back in order to keep the Collective updated on the progress we’re making towards decentralization. \nSeason 6 Re…\n\n read more\n\n 0\n\n 215\n\n Jan 2025\n\n Optimism Gov Summary\n\n Governance Updates\n\n Hello! In this thread, we’ll be sharing a condensed update every two weeks with forum highlights — straight to the point and packed with the essentials to keep up with the DAO. If we missed anything, feel free to add …\n\n read more\n\n 15\n\n 1.3k\n\n Apr 1","tokens":3034,"squid":"ink-governance","role":"Council Listener","at":1791259660087,"hash":"36ee5d7afed112c273eb68625bc37fe9d4e0048a"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/view-contracts","domain":"aave.com","title":"View Contracts | Aave Protocol Documentation","text":"View Contracts#\nThe Aave Protocol has several view contracts to assist with querying onchain data.\nUiPoolDataProvider#\nContract that returns an array of all reserve or user data for a particular market (for example, liquidity, token addresses, rate strategy), used by the Aave Interface to display Markets and Dashboard data. Compatible with both V2 and v3 of the Aave Protocol.\nThe Aave Utilities SDK includes an interface to make calls to this contract, and functions to format the response for frontend use-cases.\nThe source code is available on GitHub.\nView Methods#\ngetReservesList#\nfunction getReservesList(IPoolAddressesProvider provider) public view override returns (address[] memory)\nReturns the list of initialised reserves in the Pool associated with the given provider.\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe given provider for the associated pool\nReturn Values:#\nTypeDescriptionaddress[]The list of initialised reserves in the Pool\ngetReservesData#\nfunction getReservesData(IPoolAddressesProvider provider) public view override returns (AggregatedReserveData[] memory, BaseCurrencyInfo memory)\nReturns BaseCurrencyInfo of the Pool and AggregatedReserveData[] for all the initialised reserves in the Pool associated with the given provider.\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe given provider for the associated pool\nReturn Values:#\nTypeDescriptionBaseCurrencyInfoThe base currency informationAggregatedReserveData[]The aggregated reserve data\nThe BaseCurrencyInfo struct is composed of the following fields:\nNameTypeDescriptionmarketReferenceCurrencyUnituint256Reference aka base currency of the Aave marketmarketReferenceCurrencyPriceInUsdint256Price of reference aka base currency in USDnetworkBaseTokenPriceInUsdint256Price of native token of the network/chain in USDnetworkBaseTokenPriceDecimalsuint8Decimals of native token of the network/chain\nThe AggregatedReserveData struct is composed of the following fields:\nNameTypeDescriptionunderlyingAssetaddressThe address of the underlying asset of the reservenamestringThe name of the underlying reserve assetsymbolstringThe symbol of the underlying reserve assetdecimalsuint256The number of decimals of the reservebaseLTVasCollateraluint256The ltv of the reservereserveLiquidationThresholduint256The liquidation threshold of the reservereserveLiquidationBonusuint256The liquidation bonus of the resurvereserveFactoruint256The reserve factor of the reserveusageAsCollateralEnabledbooltrue if the asset is enabled to be used as collateral, false otherwiseborrowingEnabledbooltrue if borrowing is enabled, false otherwiseisActivebooltrue if reserve is active, false otherwiseisFrozenbooltrue if reserve is frozen, false otherwiseBASE DATAliquidityIndexuint128The liquidity index of the reservevariableBorrowIndexuint128The variable borrow index of the reserveliquidityRateuint128The liquidity rate of the reservevariableBorrowRateuint128The variable borrow rate of the reservelastUpdateTimestampuint40The timestamp of the last update of the reserveaTokenAddressaddressThe AToken address of the reservevariableDebtTokenAddressaddressThe VariableDebtToken address of the reserveinterestRateStrategyAddressaddressThe address of the Interest Rate strategyavailableLiquidityuint256The liquidity availabletotalScaledVariableDebtuint256The total scaled variable debtpriceInMarketReferenceCurrencyuint256Price of reference aka base currency of Aave marketpriceOracleaddressThe address of the price oracle used by the associated marketvariableRateSlope1uint256The variable rate slopevariableRateSlope2uint256The variable rate slopebaseVariableBorrowRateuint256The base variable borrow rate, expressed in rayoptimalUsageRatiouint256The optimal usage ratiov3 ONLYisPausedbooltrue if the pool is paused, false otherwiseisSiloedBorrowingbooltrue if the asset is siloed for borrowingaccruedToTreasuryuint128The amount of tokens accrued to treasury that is to be mintedunbackeduint128The amount of unbacked aTokens of the reserveisolationModeTotalDebtuint128The outstanding debt borrowed against this asset in isolation modeflashLoanEnabledbooltrue is asset is available to borrow in flash loan transactiondebtCeilinguint256The debt ceiling of the reservedebtCeilingDecimalsuint256The debt ceiling decimalseModeCategoryIduint8The eMode id of the reserveborrowCapuint256The borrow cap of the reservesupplyCapuint256The supply cap of the reserveborrowableInIsolationbooltrue is asset available to borrow against isolated collateral assetsv3.1virtualAccActivebooltrue if virtual accounting is enabled for a reservevirtualUnderlyingBalanceuint128Balance of reserve if virtual accounting is used\ngetUserReservesData#\nfunction getUserReservesData(IPoolAddressesProvider provider, address user) external view override returns (UserReserveData[] memory, uint8)\nReturns UserReserveData[] for all user reserves in the Pool associated with the given provider.\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe given provider for the associated pooluseraddressThe address of the user\nUserReserveData#\nTypeDescriptionUserReserveData[]The user reserve data\nThe UserReserveData struct is composed of the following fields:\nNameTypeDescriptionunderlyingAssetaddressThe address of the underlying asset supplied/borrowedscaledATokenBalanceuint256The scaled balance of the aToken. scaledBalance = balance/liquidityIndexusageAsCollateralEnabledOnUserbooltrue if the supplied asset is enabled to be used as collateral, false otherwisescaledVariableDebtuint256The scaled balance of borrow position: (current balance = scaled balance * liquidity index)\ngetEModes#\nReturns an array of all available E-mode categories in the Pool associated with the provider.\nfunction getEModes(IPoolAddressesProvider provider) external view returns (Emode[] memory)\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe PoolAddressesProvider for the associated Pool to fetch EMode categories for\nReturn Parameters:#\nNameTypeDescriptioncategoriesEmode[]The list of E-Modes available in the pool\nEmode#\nThe Emode struct is composed of the following fields:\nNameTypeDescriptioniduint8The unique identifier of the E-ModeeModeDataTypes.EModeCategoryThe E-Mode configuration details\nDataTypes.EModeCategory#\nThe EModeCategory struct is composed of the following fields:\nNameTypeDescriptionltvuint16Loan-to-Value ratio for the E-Mode categoryliquidationThresholduint16The threshold at which liquidation is triggeredliquidationBonusuint16The bonus applied during liquidationcollateralBitmapuint128Bitmap representing eligible collateral for this E-ModelabelstringThe label describing the E-Mode categoryborrowableBitmapuint128Bitmap representing borrowable assets for this E-Mode\nWalletBalanceProvider#\nFetches tokens balances for all underlying tokens of Aave reserves for one user address.\nThis contract is not used within the Aave Protocol. It is an accessory\ncontract used to reduce the number of calls towards the blockchain from the\nAave backend.\nFor getting ETH (native chain token) balance use MOCK_ETH_ADDRESS = 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE.\nThe source code is available on GitHub.\nView Methods#\nbalanceOf#\nfunction balanceOf(address user, address token) public view returns (uint256)\nChecks the token balance of a wallet in a token contract. Returns the balance of the token for user (ETH included with MOCK_ETH_ADDRESS).\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the usertokenaddressThe address of the token\nReturn Values:#\nTypeDescriptionuint256The balance of the token for user. Returns 0 for a non-contract address\nbatchBalanceOf#\nfunction batchBalanceOf(address[] calldata users, address[] calldata tokens) external view returns (uint256[] memory)\nReturns balances for a list of users and tokens (ETH included with MOCK_ETH_ADDRESS).\nInput Parameters:#\nNameTypeDescriptionusersaddress[]The list of userstokensaddress[]The list of tokens\nReturn Values:#\nTypeDescriptionuint256[]A list of balances for each user\ngetUserWalletBalances#\nfunction getUserWalletBalances(address provider, address user) external view returns (address[] memory, uint256[] memory)\nProvides balances of user wallet for all reserves available on the pool.\nInput Parameters:#\nNameTypeDescriptionprovideraddressThe address of the provideruseraddressThe address of the user\nReturn Values:#\nTypeDescriptionaddress[]A list of user walletsuint256[]A list of balances for each user\nUiIncentiveDataProviderV3#\nContract that returns an array of all reserve incentives or user claimable rewards within a particular market, used by the Aave Labs Interface to display incentives data. Compatible with both V2 and v3 of the Aave Protocol.\nThe Aave Utilities SDK includes an interface to make calls to this contract, and functions to format the response for frontend use-cases.\nThe source code is available on GitHub.\nView Methods#\ngetFullReservesIncentiveData#\nfunction getFullReservesIncentiveData(IPoolAddressesProvider provider, address user) external view override returns (AggregatedReserveIncentiveData[] memory, UserReserveIncentiveData[] memory)\nReturns both AggregatedReserveIncentiveData[] and UserReserveIncentiveData[] for the given user for the pool associated with the given provider.\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe given provider for the associated pooluseraddressThe address of the user\nReturn Values:#\nTypeDescriptionAggregatedReserveIncentiveData[]The aggregated reserve incentive dataUserReserveIncentiveData[]The user reserve incentive data\nThe AggregatedReserveIncentiveData struct is composed of the following fields:\nNameTypeDescriptionunderlyingAssetaddressAddress of the asset supplied/borrowed in PoolaIncentiveDataIncentiveDataDetails of rewards distributed for supplying to Aave Pool i.e. rewards for aToken holdersvIncentiveDataIncentiveDataDetails of rewards distributed for variable debt borrowed from Aave Pool i.e. rewards for vToken holders\nThe UserReserveIncentiveData struct is composed of the following fields:\nNameTypeDescriptionunderlyingAssetaddressAddress of the asset supplied/borrowed in PoolaTokenIncentivesUserDataUserIncentiveDataDetails of user rewards received for supplying to Aave Pool i.e. rewards for aTokenvTokenIncentivesUserDataUserIncentiveDataDetails of user rewards received for borrowing at variable rate from Aave Pool i.e. rewards for vToken\ngetReservesIncentivesData#\nfunction getReservesIncentivesData(IPoolAddressesProvider provider) external view override returns (AggregatedReserveIncentiveData[] memory)\nReturns AggregatedReserveIncentiveData[] for the pool associated with the given provider.\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe given provider for the associated pool\nReturn Values:#\nTypeDescriptionAggregatedReserveIncentiveData[]The aggregated reserve incentive data\nThe AggregatedReserveIncentiveData struct is composed of the following fields:\nNameTypeDescriptionunderlyingAssetaddressAddress of the asset supplied/borrowed in PoolaIncentiveDataIncentiveDataDetails of rewards distributed for supplying to Aave Pool i.e. rewards for aToken holdersvIncentiveDataIncentiveDataDetails of rewards distributed for variable debt borrowed from Aave Pool i.e. rewards for vToken holders\ngetUserReservesIncentivesData#\nfunction getUserReservesIncentivesData(IPoolAddressesProvider provider, address user) external view override returns (UserReserveIncentiveData[] memory)\nReturns the UserReserveIncentiveData[] for the given user for the pool associated with the given provider.\nInput Parameters:#\nNameTypeDescriptionproviderIPoolAddressesProviderThe given provider for the associated pool\nReturn Values:#\nTypeDescriptionUserReserveIncentiveData[]The user reserve incentive data\nThe UserReserveIncentiveData struct is composed of the following fields:\nNameTypeDescriptionunderlyingAssetaddressAddress of the asset supplied/borrowed in PoolaTokenIncentivesUserDataUserIncentiveDataDetails of user rewards received for supplying to Aave Pool i.e. rewards for aTokenvTokenIncentivesUserDataUserIncentiveDataDetails of user rewards received for borrowing at variable rate from Aave Pool i.e. rewards for vToken\nAaveProtocolDataProvider#\nThe AaveProtocolDataProvider is a peripheral contract to collect and pre-process information from the Pool. This contract contains methods for querying token addresses, reserve parameters, and user account information. The methods of the PoolDataProvider are more granular than the UiPoolDataProvider, which queries data for reserve tokens or user balances simultaneously.\nThe source code is available on GitHub.\nView Methods#\ngetAllReservesTokens#\nfunction getAllReservesTokens() external view returns (TokenData[] memory)\nReturns a list of the existing reserves in the pool, pairs include the symbol and tokenAddress. Handles MKR and ETH in a different way since they do not have standard symbol functions.\nReturn Values:#\nTypeDescriptionTokenData[]The list of reserves, pairs of symbols and addresses\nThe TokenData struct is composed of the following fields:\nNameTypeDescriptionsymbolstringThe symbol of the underlying reserve assettokenAddressaddressThe address of the underlying reserve asset\ngetAllATokens#\nfunction getAllATokens() external view returns (TokenData[] memory)\nReturns a list of the existing ATokens in the pool, pairs include the symbol and tokenAddress.\nReturn Values:#\nTypeDescriptionTokenData[]The list of ATokens, pairs of symbols and addresses\nThe TokenData struct is composed of the following fields:\nNameTypeDescriptionsymbolstringThe symbol of aToken of the reservetokenAddressaddressThe address of aToken of the reserve\ngetReserveConfigurationData#\nfunction getReserveConfigurationData(address asset) external view returns ( uint256 decimals, uint256 ltv, uint256 liquidationThreshold, uint256 liquidationBonus, uint256 reserveFactor, bool usageAsCollateralEnabled, bool borrowingEnabled, bool stableBorrowRateEnabled, bool isActive, bool isFrozen)\nReturns the configuration data of the reserve as described below. Does not return borrow and supply caps, nor pause flag for compatibility.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nNameTypeDescriptiondecimalsuint256The number of decimals of the reserveltvuint256The ltv of the reserveliquidationThresholduint256The liquidation threshold of the reserveliquidationBonusuint256The liquidation bonus of the reservereserveFactoruint256The reserve factor of the reserveusageAsCollateralEnabledbooltrue if the usage as collateral is enabled, false otherwiseborrowingEnabledbooltrue if borrowing is enabled, false otherwisestableBorrowRateEnabledboolAlways false (deprecated)isActivebooltrue if reserve is active, false otherwiseisFrozenbooltrue if reserve is frozen, false otherwise\ngetReserveCaps#\nfunction getReserveCaps(address asset) external view returns (uint256 borrowCap, uint256 supplyCap)\nReturns the caps parameters of the reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nNameTypeDescriptionborrowCapuint256The borrow cap of the reservesupplyCapuint256The supply cap of the reserve\ngetPaused#\nfunction getPaused(address asset) external view returns (bool isPaused)\nReturns true if the pool isPaused.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nNameTypeDescriptionisPausedbooltrue if the pool is paused, false otherwise\ngetSiloedBorrowing#\nfunction getSiloedBorrowing(address asset) external view override returns (bool)\nReturns the siloed borrowing flag. It returns true if the asset is siloed for borrowing.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionbooltrue if the asset is siloed for borrowing\ngetLiquidationProtocolFee#\nfunction getLiquidationProtocolFee(address asset) external view override returns (uint256)\nReturns the protocol fee on the liquidation bonus.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The protocol fee on liquidation\ngetUnbackedMintCap#\nfunction getUnbackedMintCap(address asset) external view override returns (uint256)\nReturns the unbacked mint cap of the reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The unbacked mint cap of the reserve\ngetDebtCeiling#\nfunction getDebtCeiling(address asset) external view override returns (uint256)\nReturns the debt ceiling of the reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The debt ceiling of the reserve\ngetReserveData#\nfunction getReserveData(address asset) external view override returns ( uint256 unbacked, uint256 accruedToTreasuryScaled, uint256 totalAToken, uint256 totalStableDebt, uint256 totalVariableDebt, uint256 liquidityRate, uint256 variableBorrowRate, uint256 stableBorrowRate, uint256 averageStableBorrowRate, uint256 liquidityIndex, uint256 variableBorrowIndex, uint40 lastUpdateTimestamp)\nReturns the reserve data.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nNameTypeDescriptionunbackeduint256The amount of unbacked aTokens of the reserveaccruedToTreasuryScaleduint256The scaled amount of tokens accrued to treasury that is to be mintedtotalATokenuint256The total supply of the aTokentotalStableDebtuint256The total stable debt of the reserve (deprecated)totalVariableDebtuint256The total variable debt of the reserveliquidityRateuint256The liquidity rate of the reservevariableBorrowRateuint256The variable borrow rate of the reservestableBorrowRateuint256The stable borrow rate of the reserve (deprecated)averageStableBorrowRateuint256The average stable borrow rate of the reserve (deprecated)liquidityIndexuint256The liquidity index of the reservevariableBorrowIndexuint256The variable borrow index of the reservelastUpdateTimestampuint40The timestamp of the last update of the reserve\ngetATokenTotalSupply#\nfunction getATokenTotalSupply(address asset) external view override returns (uint256)\nReturns the total supply of aTokens for a given asset.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The total supply of the aToken\ngetTotalDebt#\nfunction getTotalDebt(address asset) external view override returns (uint256)\nReturns the total debt for a given asset.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256The total borrows for an asset\ngetUserReserveData#\nfunction getUserReserveData(address asset, address user) external view returns ( uint256 currentATokenBalance, uint256 currentStableDebt, uint256 currentVariableDebt, uint256 principalStableDebt, uint256 scaledVariableDebt, uint256 stableBorrowRate, uint256 liquidityRate, uint40 stableRateLastUpdated, bool usageAsCollateralEnabled)\nReturns the following user reserve data.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveuseraddressThe address of the user\nReturn Values:#\nNameTypeDescriptioncurrentATokenBalanceuint256The current AToken balance of the usercurrentStableDebtuint256The current stable debt of the user (deprecated)currentVariableDebtuint256The current variable debt of the userprincipalStableDebtuint256The principal stable debt of the user (deprecated)scaledVariableDebtuint256The scaled variable debt of the userstableBorrowRateuint256The stable borrow rate of the user (deprecated)liquidityRateuint256The liquidity rate of the reservestableRateLastUpdateduint40The timestamp of the last update of the user stable rate (deprecated)usageAsCollateralEnabledbooltrue if the user is using the asset as collateral, else false\ngetReserveTokensAddresses#\nfunction getReserveTokensAddresses(address asset) external view override returns ( address aTokenAddress, address stableDebtTokenAddress, address variableDebtTokenAddress)\nReturns the addresses of the aToken, stableDebtToken and variableDebtToken of the reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nNameTypeDescriptionaTokenAddressaddressThe AToken address of the reservestableDebtTokenAddressaddressThe StableDebtToken address of the reserve (deprecated)variableDebtTokenAddressaddressThe VariableDebtToken address of the reserve\ngetInterestRateStrategyAddress#\nfunction getInterestRateStrategyAddress(address asset) external view override returns (address irStrategyAddress)\nReturns the address of the Interest Rate strategy.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nNameTypeDescriptionirStrategyAddressaddressThe address of the Interest Rate strategy\ngetReserveDeficit#\nfunction getReserveDeficit(address asset) external view override returns (uint256)\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserve\nReturn Values:#\nTypeDescriptionuint256Current reserve deficit from undercollateralized borrow positions\nPure Methods#\ngetDebtCeilingDecimals#\nfunction getDebtCeilingDecimals() external pure override returns (uint256)\nReturns the debt ceiling decimals.\nReturn Values:#\nTypeDescriptionuint256The debt ceiling decimals\nLiquidationDataProvider#\nThis contract is a utility for fetching and pre-processing liquidation-related parameters for a given user. It aggregates data from the underlying Pool and Price Oracle to determine a user’s position, collateral, borrow details, and liquidation limits according to the protocol parameters.\nThe source code is available on GitHub.\nView Methods#\ngetUserPositionFullInfo#\ngetUserPositionFullInfo(address user) public view override returns (UserPositionFullInfo memory)\nReturns aggregated position information for a user including total collateral, total debt, available borrows, current liquidation threshold, loan-to-value (LTV), and health factor. All values are denominated in the base currency.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the user whose position is queried\nReturn Values:#\nNameTypeDescriptionUserPositionFullInfostructThe aggregated position information of the user\nThe UserPositionFullInfo struct is composed of the following fields:\nNameTypeDescriptiontotalCollateralInBaseCurrencyuint256Total collateral in base currencytotalDebtInBaseCurrencyuint256Total debt in base currencyavailableBorrowsInBaseCurrencyuint256Available borrows in base currencycurrentLiquidationThresholduint256Current liquidation thresholdltvuint256Loan-to-value ratiohealthFactoruint256Health factor of the user’s position\ngetCollateralFullInfo#\ngetCollateralFullInfo(address user, address collateralAsset) external view override returns (CollateralFullInfo memory)\nReturns detailed information regarding a user’s collateral for a given asset. The returned struct includes the asset’s unit (based on decimals), its current price (via the Price Oracle), the associated aToken address, the raw collateral balance, and its equivalent value in the base currency.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the usercollateralAssetaddressThe address of the collateral asset to fetch information for\nReturn Values:#\nNameTypeDescriptionCollateralFullInfostructDetailed collateral information for the specified asset\nThe CollateralFullInfo struct is composed of the following fields:\nNameTypeDescriptionassetUnituint256The unit value of the asset (10^decimals)priceuint256Current price of the asset from the Price OracleaTokenaddressAddress of the aToken associated with the assetcollateralBalanceuint256The raw collateral balance of the usercollateralBalanceInBaseCurrencyuint256Collateral balance denominated in the base currency\ngetDebtFullInfo#\ngetDebtFullInfo(address user, address debtAsset) external view override returns (DebtFullInfo memory)\nReturns detailed information regarding a user’s debt for a given asset. The returned struct includes the asset’s unit, current price, the associated variable debt token address, the debt balance, and its equivalent value in the base currency.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the userdebtAssetaddressThe address of the debt asset to fetch information for\nReturn Values:#\nNameTypeDescriptionDebtFullInfostructDetailed debt information for the specified asset\nThe DebtFullInfo struct is composed of the following fields:\nNameTypeDescriptionassetUnituint256The unit value of the asset (10^decimals)priceuint256Current price of the asset from the Price OraclevariableDebtTokenaddressAddress of the variable debt token associated with the assetdebtBalanceuint256The raw debt balance of the userdebtBalanceInBaseCurrencyuint256Debt balance denominated in the base currency\ngetLiquidationInfo (without custom debt amount)#\ngetLiquidationInfo(address user, address collateralAsset, address debtAsset) public view override returns (LiquidationInfo memory)\nA convenience function that returns liquidation parameters for a user using the maximum possible debt liquidation amount. Internally, it calls the overloaded version with debtLiquidationAmount set to the maximum (type(uint256).max).\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the usercollateralAssetaddressThe address of the collateral assetdebtAssetaddressThe address of the debt asset\nReturn Values:#\nNameTypeDescriptionLiquidationInfostructDetailed liquidation information for the specified user and assets\nThe LiquidationInfo struct is composed of the following fields:\nNameTypeDescriptionuserInfostructAggregated position details of the user (UserPositionFullInfo above)collateralInfostructDetailed collateral information (CollateralFullInfo above)debtInfostructDetailed debt information (DebtFullInfo above)maxCollateralToLiquidateuint256Maximum collateral that can be liquidatedmaxDebtToLiquidateuint256Maximum debt that can be liquidatedliquidationProtocolFeeuint256Protocol fee applied on the liquidation bonusamountToPassToLiquidationCalluint256Adjusted debt amount for the liquidation call\ngetLiquidationInfo (with custom debt liquidation amount)#\ngetLiquidationInfo(address user, address collateralAsset, address debtAsset, uint256 debtLiquidationAmount) public view override returns (LiquidationInfo memory)\nReturns comprehensive liquidation parameters for a user given a specific collateral asset and debt asset, considering a custom maximum debt liquidation amount. The function aggregates the user’s position, collateral and debt details, checks if liquidation conditions are met, and computes the optimal amounts for liquidation—including any applicable protocol fees.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the usercollateralAssetaddressThe address of the collateral asset to be liquidateddebtAssetaddressThe address of the debt asset to be repaiddebtLiquidationAmountuint256The maximum debt amount that can be liquidated (if lower than the user’s debt balance)\nReturn Values:#\nNameTypeDescriptionLiquidationInfostructDetailed liquidation information for the specified user and assets\nThe LiquidationInfo struct is composed of the following fields:\nNameTypeDescriptionuserInfostructAggregated position details of the user (UserPositionFullInfo above)collateralInfostructDetailed collateral information (CollateralFullInfo above)debtInfostructDetailed debt information (DebtFullInfo above)maxCollateralToLiquidateuint256Maximum collateral that can be liquidatedmaxDebtToLiquidateuint256Maximum debt that can be liquidatedliquidationProtocolFeeuint256Protocol fee applied on the liquidation bonusamountToPassToLiquidationCalluint256Adjusted debt amount for the liquidation callPreviousWrapped Token GatewayNextIncentives","tokens":7051,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259662832,"hash":"cbaf08729e4be07500d6db8078a72e3bfa6c8d96"}
{"url":"https://gov.optimism.io/t/allow-the-optimism-foundation-to-stake-a-portion-of-sequencer-eth-through-season-8/9710","domain":"gov.optimism.io","title":"Allow the Optimism Foundation to Stake a Portion of Sequencer ETH Through Season 8 - Communications 📣 / Citizen Updates - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Allow the Optimism Foundation to Stake a Portion of Sequencer ETH Through Season 8 \n\n Communications 📣Citizen Updates\n\n season-7,season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2025\n\n 1 / 31\n\n Feb 2025\n\n Nov 2025\n\n post by system on Feb 26, 2025\n\n system\n\n Allow the Optimism Foundation to Stake a Portion of Sequencer ETH Through Season 8\nProposal Type: Sequencer ETH: Passive Management (see updated Operating Manual)\n\nNotes about this Proposal Type:\nYield estimates are subject to change based on market conditions and other factors, estimates in this proposal are as of writing (2/27/25.)\n\nThis proposal type must be initiated by the Foundation given our current level of organizational decentralization. In the future, full proposal rights will be transferred to governance (potentially a delegated set of representatives) and this process may be facilitated as a public RFP process.\nPlease note that additional governance responsibilities related to Sequencer ETH will be brought online at a later date. We are conducting various workstreams to reduce the dependencies between Phase A and Phase B in Row 19 of our Decentralization Milestones. The approval of this proposal, would move us incrementally closer to Phase B but we do not expect to achieve Phase B in Season 7.\nThis vote is subject to Citizen approval as Sequencer ETH currently accrues to the Retro Fund, by default. We are currently doing active research to further develop this proposal type and to design the “Sequencer ETH: Active Management” proposal type. Future versions of this proposal type may vary substantially as a result, and may be subject to Token House approval and/or veto in future iterations.\n\nExecutive Summary\n\nThe Foundation would like to stake a portion of the Sequencer ETH accruing to the Collective treasury on behalf of the Collective (details here.)\nThis sequencer ETH includes the revenue contribution of chains within the Superchain. The Superchain has generated 14,991 ETH to date, with 10,325 ETH currently held in the Collective Treasury (4,667 ETH is currently held by chains contributing revenue and, as such, cannot currently be staked.) This proposal would enable the Foundation to stake up to 60% of the sequencer ETH, or 6195 ETH, across three providers in 2025.\nUpon approval of this proposal, an initial 20%, or 2,065 ETH, will be staked within 10 days of approval. At a ~4.5% yield, this would generate 81 ETH per year for the Collective, net of fees.\nBy early 2H25, the Foundation plans to onboard an additional 2 custodians to manage an additional 20% (2,065 ETH) each. The total result would be 60% of sequencer ETH staked (6,195 ETH) across three custodians for an expected net yield of 243 ETH per year (~560,000 USD as of 2/27/25.) The Foundation does not believe it is prudent to stake any more than 60% of the ETH in order to maintain sufficient reserves (reserves may be used to support regular network operations, etc.)\nThis proposal would be in effect until the end of Season 8 (Dec 2025), when it would need to be renewed.\n\nMotivation\nQuite simply, the Collective is incurring an opportunity cost by not generating yield on sequencer ETH. While we work towards the development of robust economic models that will allow governance to more fully manage the treasury, we propose staking a portion of this ETH so that the Collective can earn up to ~243 ETH per year in the meantime. All yield generated will accrue directly to the Collective treasury (specifically, defaulting to the Retro Fund.) Any resulting loss, although unexpected, would also accrue to the Collective treasury.\nSpecifications\n\nOperational details\n\nSequencer ETH is currently custodied passively at BitGo, but generates no yield.\n\nThis proposal would enable the Foundation to promptly open an agreement with BitGo Custody to stake an initial 20% of the sequencer ETH - or 2,065 ETH - on behalf of the Collective. This is consistent with the Foundation’s internal policies, which cap exposure to a single counterparty at 20%.\n\nThird-party providers determine staking parameters (decisions regarding the type of block builder, client software, fork choice rule election.) You can view BitGo’s staking overview here\n\nThe factors considered in selecting Bitgo are outlined below:\n\nOperational Simplicity: We currently hold this ETH with BitGo. Transitioning to staking requires minimal operational lift, ensuring seamless integration with existing workflows and partnerships.\nProven Partnership: Our existing relationship with BitGo has demonstrated their reliability and efficiency in handling institutional-grade assets.\nSecurity and Insurance: BitGo Custody offers $250 million in cold wallet insurance (for all assets under custody), providing significant risk mitigation for staked assets stored in cold storage. This insurance generally covers cases where keys are stolen, lost, or misused by BitGo.\nRegulatory Compliance: BitGo is a regulated custodian, holding various licences, aligning with Optimism’s governance and compliance standards.\nRedemption: Staked ETH has a minimal redemption delay (estimated at 24-48 hours post-request, depending on network congestion). This ensures efficient execution of withdrawal requests, if needed.\n\nIf approved, this proposal will also allow the Foundation to deploy an additional 40% of the sequencer ETH, split equally across 2 additional custodians, from the list below. These providers were selected for minimal protocol risk, strong reputations, ease of use, and a preference for companies that have existing partnerships with Optimism. We plan to further evaluate liquid staking options in the future. Please note that the Foundation also covers the USD cost of maintaining an agreement with each provider, estimated at ~36,000 USD per year.\n\nKraken\nCoinbase\n\nImpact summary\n\nIf approved, this proposal will immediately stake 2,065 ETH resulting in the below projections:\n\nAnnual Yield: Staking with BitGo is expected to generate net annual returns of 4-5%.\nFee Structure: BitGo charges a competitive staking fee of approximately 10-15% of staking rewards, which is deducted before rewards are distributed.\nEstimated Yield: Assuming an average yield of 4.5% and average staking fees of 12.5% of yield, we would estimate returns in the region of ~$213k in the first year, on this initial 20% allocation.\n\nimage1626×102 9.61 KB\n\nWe estimate that by staking the full 6,195 ETH this proposal approves, the Collective can generate ~243 ETH annually.\n\nWhile we believe this is a low-risk yield generation strategy, it is not without risk. Risk factors include:\n\nSmart Contract Risk: Potential vulnerabilities in the staking protocol could expose assets to loss. However, Ethereum’s network is among the most secure and rigorously tested.\nValidator Performance Risk: Staking rewards depend on validator uptime and behavior. Misbehavior or downtime could result in slashing penalties. However, BitGo’s validators are professionally managed to minimise this risk.\nLiquidity Risk: Staked ETH is subject to a withdrawal delay (currently estimated at 24-48 hours). This reduces flexibility compared to holding ETH idle.\n\nAction Plan\nIf this proposal is approved, the Foundation will promptly enter into an agreement with BitGo Custody to stake 2,065 ETH within 10 days of the passing of this proposal. The Foundation will also onboard and stake and additional 2,065 ETH (each) with the 2 additional providers listed above, covering the associated USD fees. An exact timing estimate is not possible as staking is subject to onboarding and agreements with each new staking providers, but we hope to have the additional 40% staked by early 2H25.\nThe Foundation will will confirm execution with each provider at the bottom of this post. The Foundation will post quarterly updates about yield generation as a comment on this post, if approved and implemented.\nThe actions taken via this proposal may be rolled back (unstaked) in circumstances including security incidents, extreme market downturns, and/or to support any immediate operational needs. Any rollback/unstaking actions taken will be noted by the Foundation as a comment on this post.\nYield estimates are subject to change based on market conditions and other factors, estimates in this proposal are as of writing (2/27/25.)\n\n Voting Cycle Roundup #34\n\n Token House Call [March 11th 19:00 UTC]\n\n Joint House Community Calls Summaries - Season 7\n\n Guide to Season 8\n\n Season 8 & 9: Budget Board Charter\n\n 6\n\n 3\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n Unlisted on Feb 26, 2025\n\n Listed on Feb 27, 2025\n\n post by GFXlabs on Mar 4, 2025\n\n GFXlabs\n\nQuestion about this: This seems above market (which is great). Does it come with additional risks? Lido appears to be paying net 3.3% right now, so this is a significant increase in yield and just wondering if this is a promotional rate or something else?\n\nWhy are there no DeFi options on here? We strongly recommend a public RFP process to avoid a perception of conflicts of interest.\n\n Proposal to Align the OP Token with Superchain Success\n\n post by jengajojo on Mar 5, 2025\n\n jengajojo\n\n Glad to see efforts being initiated to earn yield. It would be great to understand the rationale behind leaning towards custodians as opposed to DeFi strategies on Optimism which will help increase TVL since this is one of the important metrics for the season.\nA public RFP would be a nice option for the 2nd or 3rd portion of the ETH to be staked as it will help the collective gather essential feedback on the difference between processes and costs between offline and public processes.\n\n post by MinimalGravitas on Mar 5, 2025\n\n MinimalGravitas\n\nThis proposal would enable the Foundation to promptly open an agreement with BitGo Custody to stake an initial 20% of the sequencer ETH\n\nIf approved, this proposal will also allow the Foundation to deploy an additional 40% of the sequencer ETH, split equally across 2 additional custodians, from the list below. […]\n\nKraken\nCoinbase\n\nSo this means 60% in total right?\n20% with BitGo, 20% with Kraken and 20% with Coinbase… if so then it really seems this is worded obtusely. Why say 2 custodians from the list below when the list only contains 2 options? What am I missing?\nAlso, same question as GFXlabs about the yield - it’s not clear from the docs where the extra comes from, could it just be that their marketing is out of date?\nFinally, with regards to risk, both Coinbase and Kraken use Prism for a majority of their CL clients (over 60% for CB and almost 100% for Kraken). I’m not sure the client diversity of Bitgo and their site doesn’t seem to make it clear how their validators are set up. If they are mostly using Prism too then would it be better risk management to choose staking service providers with a more varied set of node software?\n\n post by 0xDonPepe on Mar 5, 2025\n\n 0xDonPepe\n\n First, I want to commend the Foundation for proactively seeking to put the Collective’s idle ETH to work, this is a smart and necessary step toward responsible treasury management. Generating yield on sequencer ETH is a no-brainer, and your focus on security, compliance, and simplicity with BitGo is understandable. That said, I believe there’s a far more impactful way to achieve these goals while aligning with Ethereum’s values and generating even greater returns: partnering with Obol Labs instead of centralized custodians like BitGo, Coinbase, or Kraken.\nHere’s why Obol is a superior choice:\n1. Strengthens Ethereum Decentralization\nCentralized custodians like BitGo, while convenient, directly contradict Ethereum’s core ethos of decentralization. By contrast, Obol’s Distributed Validator Technology (DVT) splits validator operations across independent node operators (e.g., techne credential holders), eliminating single points of failure and censorship risks. This:\n\nAvoids reliance on institutional middlemen (BitGo’s validators = centralized control).\nEnhances network resilience—critical for Optimism’s long-term credibility as a “Superchain” leader.\nBuilds grassroots alignment by supporting small operators in the Obol/Optimism ecosystems.\n\n2. Generates Higher Yield\nObol’s proposal isn’t just about ideology, it’s financially compelling:\n\nMetric\nOptimism + BitGo\nObol Partnership\n\nBase APR\n4.5% (net after 12.5% fees)\n~3% ETH staking\n\nAdditional Yield\nNone\n1-2% $OBOL rewards + AVS rewards + EigenLayer restaking + potential airdrops\n\nLiquidity Utility\nIlliquid (24-48h unlock)\nosETH (DeFi-ready LST) for lending, LP, etc.\n\nEffective APY\n~4.5%\n5-8%+ (depending on AVS/restaking strategies)\n\nObol’s 1% fee structure (vs. BitGo’s 10-15%) and $OBOL token rewards alone make it a better deal. Add in Stakewise’s osETH liquidity and EigenLayer restaking, and the upside dwarfs custodial staking.\n3. Future-Proofs Optimism’s Ecosystem\nAdopting Obol would:\n\nBoost Superchain’s DeFi ecosystem by introducing osETH as a liquid staking primitive for Optimism’s dApps.\nAccelerate decentralization milestones by aligning sequencer ETH management with community-operated validators.\nCreate governance synergies—Obol contributions grant Retroactive Public Goods Funding (RPGF) eligibility and future governance rights in Obol’s Collective.\n\nThe Foundation’s proposal is a solid start, but settling for centralized custodians leaves value and values on the table. Obol offers a rare win-win: higher yields and stronger decentralization. As a leader in the ecosystem, Optimism has a responsibility to champion Ethereum’s principles while maximizing treasury efficiency. Let’s not replicate TradFi models, let’s build something better.\n\n post by system on Mar 6, 2025\n\n system\n\n Thank you for the questions @GFXlabs and @jengajojo\n\nThe yield rate we’ve presented is not promotional. It reflects the current yield estimate provided directly by BitGo. It’s possible given current market rates that actual yield comes in lower than BitGo’s projected number.\n\nOur risk management framework requires comprehensive security evaluation and continuous monitoring for any protocol we rely on. This proposal only includes custodial options because it’s the fastest path to get ETH staked and earning yield in a way that meets our security standards.\nWe definitely recognize the benefits of staking via DeFi strategies on Optimism – these are probably the right long-term solutions here. This proposal suggests the Collectie take the shortest path to start generating yield immediately, and the conversation around safe and positive-sum DeFi options can take place in parallel. As more robust treasury management capabilities come online in future seasons, these options will feature heavily.\n\nA public RFP process is likely the right solution for this type of decision at some point in the Collective’s future. This proposal represents a shorter term approach to begin generating yield for the benefit of the Collective. It’s worth noting that any experiments with RFP processes should not be done via full Citizens’ House vote (like this proposal), but rather a delegated group that manages procurement. To date, the Citizens’ House hasn’t managed any similar procurement or RFP process, which is also a consideration here.\nThis proposal would stake ETH through the end of Season 8 (which runs through H2 2025), at which point another proposal or public procurement process should take place.\n\n post by GFXlabs on Mar 7, 2025\n\n GFXlabs\n\nWe don’t think you should make decisions based on that quoted number. No one else can provide yield like that purely from staking, so we recommend you ask BitGo for an updated estimate. See here for what should be expected:\nScreenshot 2025-03-07 at 8.36.05 AM2416×784 132 KB\n(Source)\nAnother view of what market staked ETH rates are:\nScreenshot 2025-03-07 at 8.39.48 AM3466×1072 266 KB\n(Source)\nIf BitGo insist they can pay more than any of the major staked ETH providers, we recommend additional due diligence to understand how they are doing so before relying on those estimates.\n\nWell, it looks like you can spot dump more than $1m each of wstETH and rETH on Optimism itself without incurring any meaningful price impact. And that’s just on Optimism, not taking into account local markets on Base and other chains.\nIsn’t simply buying and then self-custodying a bunch of liquid staking tokens 1) faster, 2) cheaper, 3) safer, 4) eating our own dogfood?\nLet’s also remember that in reality, governance is unlikely to sell/unstake the funds all at once. But if, for some reason, funds are needed ASAP, liquid staking DeFi assets allow for immediate exit rather than being caught up in the unstaking queue + any delays from the custodian.\nIt is just an incredibly poor look if Optimism doesn’t trust its own product. How are we supposed to attract financial institutions to utilize the Superchain like that? It should be noted that Arbitrum holds its treasury assets on its own chain, and also uses that process to court more and more financial institutions to deploy there.\nIt is both a practical and political imperative that the Foundation not pursue a custodian-only strategy with governance-owned ETH. We are going to get eaten alive if the message is “Even Optimism doesn’t trust its funds to the Superchain.”\n\n post by Gonna.eth on Mar 7, 2025\n\n Gonna.eth\n\n I’m inclined to vote against this proposal, not because I oppose staking ETH, but because I believe the approach could be more aligned with governance decentralization. Here’s where I see room for improvement:\n\nFoundation Contradiction: The statement “Optimism doesn’t trust its funds to the Superchain” raises concerns. I don’t think there are risks or doubts about the Superchain’s security or sustainability, but if there are they should be openly discussed. Clarity here would strengthen trust in the broader ecosystem.\nStep-by-Step Token House Decision: Instead of a single approval for staking both the ETH amount and providers, a more decentralized approach could involve separate Token House votes. First on the providers, then on the staking amount. This would give the community more say in risk management and treasury decisions. Or make the providers put a proposal and let TH choose.\nExploring a Treasury Council: Rather than relying solely on the Foundation to make these financial decisions, the creation of a Treasury Council with a lead chosen by the Foundation but governed by a broader group can be a better solution. This would allow for a structured transition toward decentralization while keeping expert oversight in place.\n\nStaking ETH makes sense financially, but how we decide to stake is just as important as whether we do it.\n\n post by mastermojo on Mar 7, 2025\n\n mastermojo\n\n I love this proposal, but think we should 100% have a DEFI option on here.\nIMO 20% to bitgo, 20% coinbase, 20% kraken, then 40% onchain. Putting a portion of your sequencer $eth onchain is a huge nod to your current builders, protocols. Perhaps the onchain options could be voted on eventually (Token and Citizen house)?\nonchain options could be explored on stage 1 chains only\nimage854×288 25.2 KB\n\n post by jackanorak on Mar 7, 2025\n\n jackanorak\n\n Fwiw i think it’s totally fair game for the Foundation to stake its ETH anywhere as an intermediate step, especially if there are some constraints with regard to how Optimism can stake.\nI do think it’d be appropriate to have some clear pathway toward self-custodied, fully onchain alternatives but the explanations for BitGo seem totally fine to me.\n\n post by katie on Mar 9, 2025\n\n katie\n\n I would love to see the ETH used in defi at some point but I’m supportive of anything that gets us yield in the interim and the Bitgo rates are great, I fully support this proposal!\n\n post by ashrafstakala on Mar 9, 2025\n\n ashrafstakala\n\n Why bypass the Token House on this proposal? It seems like quite an important decision for the Collective, and I’m sure many Token Holders would appreciate the opportunity to vote on it.\nWe risk sending the message that only Citizens have input on proposals relating to the Sequencer revenue. Not sure if that is the intention.\n\n post by system on Mar 10, 2025\n\n system\n\n Thank you all for the feedback and discussion.\n\nIt is just an incredibly poor look if Optimism doesn’t trust its own product.\n\nTo reiterate from the comment above: positive-sum DeFi, and Superchain DeFi in particular, is the best longterm solution here. The Foundation continues to support the growth of DeFi across the Superchain through business development, grants, and product support.\nThis procurement process should evolve towards Superchain-native DeFi protocols, but this proposal is the shortest route to get staking up and running on a short timeline given the Foundation’s commitments and constraints around security, tax, and legal.\nIn other words, we are in agreement about the importance of using DeFi staking solutions, but that will require us to set up new structures to manage the security, tax, and legal implications for the DAO and that will take time. So the question is not whether we should include DeFi solutions - we should! - but rather whether we want to move forward with staking the ETH using the current structures we have in place to start generating yield for the Collective immediately (as outlined in this proposal), or incur the opportunity cost of not generating yield while we set up the structures required to feasibly enable DeFi solutions (likely until the end of Season 8, which is when this proposal expires.)\n\nExploring a Treasury Council: Rather than relying solely on the Foundation to make these financial decisions, the creation of a Treasury Council with a lead chosen by the Foundation but governed by a broader group can be a better solution.\n\nThis is a great callout. This is an important part of the Collective’s evolution. Here’s the high-level plan, starting in Season 8:\n\nEstablish a Joint House Budget Board to enable the Collective to develop economic decision making processes for Optimism. (Mentioned here and here.)\nSupport the Budget Board in developing an advanced and data-driven framework for Treasury management.\nThe Budget Board could run a public RFP process for staking providers (including or even limited to Superchain-native DeFi) as part of broader Treasury management strategy\n\nRather than wait for the above to take place, this proposal is suggesting the Collective stake ETH to generate yield as soon as possible while we continue to evolve the processes and frameworks that will let the governance community make independent, legitimate decisions around treasury management.\n\nAnother important clarification, as it appears there is some confusion about this proposal type: While it is undoubtedly valuable for Token House delegates to share their opinions on this proposal, this proposal will be voted on by Citizens, as sequencer revenue defaults to the Retro Fund, which is managed by the Citizens’ House. This is an important part of the capture resistant design of the Collective outlined here. You’ll note that in the future, “The Token House may vote on proposals to divert a portion of the surplus protocol revenue for other Optimism Collective” which would come online when the Sequencer ETH: Passive Management proposal type comes online.\n\n post by loxia.eth on Mar 11, 2025\n\n loxia.eth\n\n Boosting the staking utilization rate of ETH is a brilliant idea! Retro Funding requires more ETH to generate additional positive externalities for the entire ecosystem! The current compromise, balancing yield and security considerations, also appears to be quite sensible. Indeed, in the long run, it would be appropriate to transition the ETH staking method to a Superchain-native approach.\nHaving previously worked in a blockchain insurance protocol, I’ve compiled extensive data on security incidents. One particularly striking conclusion is that the likelihood of security incidents in a DeFi protocol significantly decreases only after it has been operating smoothly for six months or more. Therefore, I fully understand that OP should support its own ecosystem and community. However, from a security standpoint, I personally believe that staking a large portion of funds in a Superchain-native staking protocol that has been securely operational for less than six months is not advisable. Instead, funds should be staked in batches over time. This would be a complex and protracted process, involving multiple alternative DeFi protocols, with the total staking period potentially spanning six months to a year, and a dedicated task force continuously monitoring and maintaining the process.\nI am very fond of this proposal and am eagerly looking forward to seeing new updates on it!\n\n post by Gonna.eth on Mar 11, 2025\n\n Gonna.eth\n\nFully agree to stake now after this answer,\nI am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\n\n post by mastermojo on Mar 11, 2025\n\n mastermojo\n\n system\n\n I am an Optimism Top 100 delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote\n\n post by OPUser on Mar 11, 2025\n\n OPUser\n\n I fully support this proposal in current form, but there are a few points to consider. For BitGo, do we know the source of the additional yield mentioned by GFX Labs above?\nCollective is supporting DeFi and Superchain-native applications from multiple angles—through proactive and retroactive grants, as well as intent and social outreach initiatives. If and when we proceed with DeFi approach, I believe it is reasonable to request assurances from native staking providers in the event of a smart contract bug or exploit. This technology has been around for a decade, and I think it’s time we demand guarantees that these protocols will make us whole if something goes wrong, rather than simply asking us to accept the outcome as an inherent smart contract risk.\nAdditionally, instead of immediately transitioning to a DeFi staking solution, I would recommend moving the funds on-chain in the form of cbETH and kr(?)ETH at a later stage, once they are fully supported on Inkonchain. However, I am uncertain about the potential legal challenges associated with this approach.\nin case this propsal requires delegate approval.\nI am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\n\n post by SEEDGov on Mar 13, 2025\n\n SEEDGov\n\n As delegates, we want to express our agreement with the straightforward nature of this proposal to allocate the Sequencer ETH funds for staking with BitGo, a service provider already used by the Foundation for other purposes. We agree that basic ETH staking is the best baseline for generating yield before considering riskier options. However, we want to highlight and reiterate the following points:\n\nClarify BitGo’s estimations.\nExpand on the Foundation’s challenges in considering DeFi options as viable alternatives, as other major organizations currently use them (e.g., it is unclear what the risks would be of simply ‘buying and holding’ staked ETH derivatives, self-custodied in an on-chain governance contract or through BitGo).\nProvide staking details offered by Base and Kraken.\nWork into an RFP process as soon as possible.\n\n Load more posts below","tokens":6855,"squid":"ink-governance","role":"Council Listener","at":1791259670377,"hash":"3100e97a921989087f5884c972242ea411e95657"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/incentives","domain":"aave.com","title":"Incentives | Aave Protocol Documentation","text":"Incentives#\nThe UiIncentiveDataProvider provides methods to query all active incentive emissions, and claimable user incentives for a particular Aave market.\nRewardsController#\nRewardsController is the main rewards contract where the user interacts to claim the rewards of their positions. It is an abstract contract template to build Distributors contracts for ERC20 rewards to protocol participants. RewardsController inherits from RewardsDistributor to handle the distribution of rewards. The users of the incentivized ERC20 assets will accrue value if they hold their tokens in possession without the need for staking or blocking the assets inside a contract.\nThe users can claim all the rewards or an individual reward per transaction, with a variety of functions that allow more granularity at claim.\nAt every transfer, the asset must call the handleAction method to account\nfor the user's rewards.\nThe source code is available on GitHub.\nWrite Methods#\ninitialize#\nfunction initialize(address) external initializer\nInitialize RewardsController instance.\nInput Parameters:#\nTypeDescriptionaddressUnused but required due to being initialized by PoolAddressProvider._updateImpl()\nconfigureAssets#\nfunction configureAssets(RewardsDataTypes.RewardsConfigInput[] memory config) external override onlyEmissionManager\nConfigure assets to incentivize with an emission of rewards per second until the end of distribution.\nInput Parameters:#\nNameTypeDescriptionconfigRewardsDataTypes.RewardsConfigInput[]The emission per second following rewards unit decimals\nThe RewardsDataTypes.RewardsConfigInput struct is composed of the following fields:\nNameTypeDescriptionemissionPerSeconduint88The emission per second following rewards unit decimalstotalSupplyuint256The total supply of the asset to incentivizedistributionEnduint32The end of the distribution of the incentives for an assetassetaddressThe asset address to incentivizerewardaddressThe reward token addresstransferStrategyITransferStrategyThe TransferStrategy address with the install hook and claim logicrewardOracleIEACAggregatorProxyThe Price Oracle of a reward to visualize the incentives at the UI frontend. Must follow Chainlink Aggregator IEACAggregatorProxy interface to be compatible.\nsetTransferStrategy#\nfunction setTransferStrategy(address reward, ITransferStrategyBase transferStrategy) external onlyEmissionManager\nSets a TransferStrategy logic contract that determines the logic of the rewards transfer.\nInput Parameters:#\nNameTypeDescriptionrewardaddressThe address of the reward tokentransferStrategyaddressThe address of the TransferStrategy logic contract\nsetRewardOracle#\nfunction setRewardOracle(address reward, IEACAggregatorProxy rewardOracle) external onlyEmissionManager\nSets an Aave Oracle contract to enforce rewards with a source of value.\nAt the moment of reward configuration, the Incentives Controller performs a check to see if the reward asset oracle is compatible with IEACAggregator proxy. This check is enforced for integrators to show incentives at the current Aave UI without needing to set up an external price registry.\nInput Parameters:#\nNameTypeDescriptionrewardaddressThe address of the reward to set the price aggregatorrewardOracleIEACAggregatorProxyThe address of price aggregator that follows the IEACAggregatorProxy interface\nhandleAction#\nfunction handleAction(address user, uint256 totalSupply, uint256 userBalance) external override\nCalled by the corresponding asset on transfer hook to update the rewards distribution of a user.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the usertotalSupplyuint256The user balance of the assetuserBalanceuint256The total supply of the asset\nclaimRewards#\nfunction claimRewards( address[] calldata assets, uint256 amount, address to, address reward) external override returns (uint256)\nClaims reward for a user to the desired address, on all the assets of the pool, accumulating the pending rewards. Rewards are received by the to address.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets to check eligible distributions before claiming rewards. Pass a/s/vToken addressesamountuint256The amount of rewards to claim, expressed in wei. Pass MAX_UINT to claim the entire unclaimed reward balancetoaddressThe address that will be receiving the rewardsrewardaddressThe address of the reward token (e.g., stkAAVE)\nReturn Values:#\nTypeDescriptionuint256The amount of rewards claimed for one specific reward\nThe msg.sender must be an authorized claimer set using the setClaimer()\nmethod, via a Governance Vote.\nclaimRewardsOnBehalf#\nfunction claimRewardsOnBehalf( address[] calldata assets, uint256 amount, address user, address to, address reward) external override onlyAuthorizedClaimers(msg.sender, user) returns (uint256)\nClaims rewards for a user on behalf, on all the assets of the pool, accumulating the pending rewards of the assets passed by the first argument. The caller must be whitelisted via the allowClaimOnBehalf function by the EmissionManager role held by Aave Governance. Rewards are received by the to address.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets to check eligible distributions before claiming rewards. Pass a/s/vToken addressesamountuint256The amount of rewards to claim, expressed in wei. Pass MAX_UINT to claim the entire unclaimed reward balanceuseraddressThe address to check and claim rewardstoaddressThe address that will be receiving the rewardsrewardaddressThe address of the reward token being claimed (e.g., stkAAVE)\nReturn Values:#\nTypeDescriptionuint256The amount of rewards claimed\nclaimRewardsToSelf#\nfunction claimRewardsToSelf(address[] calldata assets, uint256 amount, address reward) external override returns (uint256)\nClaims reward for msg.sender, on all the assets of the pool, accumulating the pending rewards passed by the first input parameter. Rewards are received by msg.sender.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets to check eligible distributions before claiming rewards. Pass a/s/vToken addressesamountuint256The amount of rewards to claim, expressed in wei. Pass MAX_UINT to claim the entire unclaimed reward balancerewardaddressThe address of the reward token\nReturn Values:#\nTypeDescriptionuint256The amount of rewards claimed for one specific reward\nclaimAllRewards#\nfunction claimAllRewards(address[] calldata assets, address to) external override returns (address[] memory rewardsList, uint256[] memory claimedAmounts)\nClaims all rewards for a user to the desired address, on all the assets of the pool, accumulating the pending rewards passed by the first input parameter. Rewards are received by the to address.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets to check eligible distributions before claiming rewards (aToken or variableDebtToken addresses)toaddressThe address that will be receiving the rewards\nReturn Values:#\nNameTypeDescriptionrewardsListaddress[]The list of addresses of the reward tokensclaimedAmountsuint256[]The list that contains the claimed amount per reward, following the same order as rewardsList\nclaimAllRewardsOnBehalf#\nfunction claimAllRewardsOnBehalf( address[] calldata assets, address user, address to) external override onlyAuthorizedClaimers(msg.sender, user) returns (address[] memory rewardsList, uint256[] memory claimedAmounts)\nClaims all rewards for a user on behalf, on all the assets of the pool, accumulating the pending rewards passed by the first input parameter. The caller must be whitelisted via the allowClaimOnBehalf function by the EmissionManager role held by Aave Governance. Rewards are received by the to address.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets to check eligible distributions before claiming rewards. Pass a/s/vToken addressesuseraddressThe address to check and claim rewardstoaddressThe address that will be receiving the rewards\nReturn Values:#\nNameTypeDescriptionrewardsListaddress[]The list of addresses of the reward tokensclaimedAmountsuint256[]The list that contains the claimed amount per reward, following the same order as rewardsList\nclaimAllRewardsToSelf#\nfunction claimAllRewardsToSelf(address[] calldata assets) external override returns (address[] memory rewardsList, uint256[] memory claimedAmounts)\nClaims all rewards accrued by msg.sender, on all assets of the pool, accumulating the pending rewards by the first input parameter. Rewards are received by msg.sender.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets to check eligible distributions before claiming rewards. Pass a/s/vToken addresses\nReturn Values:#\nNameTypeDescriptionrewardsListaddress[]The list of addresses of the reward tokensclaimedAmountsuint256[]The list that contains the claimed amount per reward, following the same order as rewardsList\nsetClaimer#\nfunction setClaimer(address user, address caller) external override onlyEmissionManager\nWhitelists an address to claim rewards on behalf of another address. Can only be called by the EmissionManager.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the usercalleraddressThe address of the claimer\nView Methods#\ngetClaimer#\nfunction getClaimer(address user) external view override returns (address)\nReturns the whitelisted claimer for a certain address. It returns the 0x0 address if it is not set.\nInput Parameters:#\nNameTypeDescriptionuseraddressThe address of the user\nReturn Values:#\nTypeDescriptionaddressThe claimer address\ngetRewardOracle#\nfunction getRewardOracle(address reward) external view override returns (address)\nGet the price aggregator oracle address.\nNameTypeDescriptionrewardaddressThe address of the reward token\nReturn Values:#\nTypeDescriptionaddressThe address of the reward oracle\ngetTransferStrategy#\nfunction getTransferStrategy(address reward) external view override returns (address)\nReturns the Transfer Strategy implementation contract address being used for a reward address.\nNameTypeDescriptionrewardaddressThe address of the reward\nReturn Values:#\nTypeDescriptionaddressThe address of the TransferStrategy contract\nPure Methods#\nfunction getRevision() internal pure override returns (uint256)\nReturns the revision of the implementation contract.\nReturn Values:#\nTypeDescriptionuint256The current revision versionPreviousView ContractsNextTokenization","tokens":2597,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259672796,"hash":"cfb7a0c48e33d866480bc934ed291856a2a118e2"}
{"url":"https://gov.optimism.io/t/governance-update-9/9603","domain":"gov.optimism.io","title":"Governance Update #9 - Updates and Announcements 📢 / Governance Updates - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Governance Update #9 \n\n Updates and Announcements 📢Governance Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2025\n\n 1 / 3\n\n Jan 2025\n\n Jan 2025\n\n post by system on Jan 30, 2025\n\n system\n\n Governance Update #9\nIt’s been a while since our last governance update, but we wanted to bring these posts back in order to keep the Collective updated on the progress we’re making towards decentralization.\nSeason 6 Recap\nAs a reminder, in Season 6, we made important steps towards continued decentralization:\n\nThree out of the past six protocol upgrades were proposed by core development teams other than OP Labs.\nMultiple OP Chains are now governed by Optimism governance\nBase and Ink are now running our permissionless fault proofs\nAll Security Council members are now elected\nGovernance Fund proposals now execute onchain, via Governor Update #3\nThe Token House ratified the Standard Blockspace Charter, taking a major step towards shared Superchain upgrades\nWe onboarded first OP Chains to governance via the Chain Delegation Program\nWe piloted the Collective Feedback Commission, the first step on the path to open metagovernance\nWe experimented with Citizenship selection methods via guest voter experiments\nWe published working models for decentralization\n\nSeason 7\nIn Season 7, we’re focused on the below milestones or dependencies.\nDecentralization Milestones\nAll milestones or dependencies highlighted in yellow (and, in the case of dependencies, bolded) are focus areas for Season 7.\nTechnical Layer\nAll Milestones in Phase A are completed. The first Milestone we are gradually working towards in Phase B is:\n\nStage 1 + multiple proof systems running\n\nEconomic Layer\nAll Milestones in Phase A are completed. We are now working to reduce the dependencies between Phase A and B:\n\nMeasureable & standardized ROI for grant programs\n\nAnalysis of Season 6 Grants (analysis to be shared soon!)\nGovernance Fund Success Metrics (all grants must move TVL metrics)\nRetro Funding Missions (data driven, human-in-the-loop)\n\nInitial set of Superchain partners onboarded by Foundation\n\nSuperchain Index\n\nMore automated/scalable grant processes\n\nFutarchy Experiment, Milestones and Metric Council, Collective Multisig Policy\n\nBudgeting framework\n\nIn preparation for Season 8 Budget Board, in collaboration with Collective Feedback Commission\n\nFinancial forecasting ability\n\nIn preparation for Season 8 Budget Board, in collaboration with Collective Feedback Commission\n\nSocial Layer\nA few Milestones remain to be completed in Phase A.\n\nGreater than 25% tokens circulating; Cost of attack > 50M OP (target subject to change)\n\nVotable Supply Framework in development\n@optimistic_josiah is focused on this milestone as our Strategic Delegation Lead!\n\nFoundation proposes, Citizens approve\n\nCitizenship Approach for 2025\n\nConfidence in gridlock resistant veto mechanism\n\n@elizaoak will be conducting research on this throughout Season 7, to inform Season 8 experimentation\n\nMore developed Internal Dev Experience\n\nWork in progress\n\nCore dev program development\n\nSee our public SUP Process\n\nPublic roadmaps\n\nOptimism Protocol Roadmap - H1 2025\n\nPublic R&D Discord\n\nUp and running (Invite only)\n\nDefined Optimism design process\n\nWork in progress\n\nHigh context group of contributors\n\nCollective Feedback Commission Next Iteration\n\nPermissionless proposal rights w/ Foundation veto\n\nWork in progress, draft spec here\n\nWe are also making progress towards more operational autonomy with the onchain transfer of the Governance Fund Mission to a Collective Multisig managed by the Milestone and Metrics Council as well as the onchain transfer of an Operating Budget to the Security Council.\n\nThis fits into the broader System Diagram as outlined below:\nVision\nimage1010×436 9.21 KB\nThe entire Collective has aligned around one Collective Intent, with measurable Success Metrics! The way the north star is determined will continue to evolve in future Seasons.\nImpact Evaluation\nimage1082×382 8.59 KB\n\nMeasurable Outcomes: Retro Funding is experimenting with data driven, human-in-the-loop Retro Funding MIssions\nQualitative Outputs - The Milestones and Metrics Council will gradually take on more responsibilities in verifying outputs starting in Season 7.\n\nSelection Mechanism\nimage1082×328 10.8 KB\n\nWe will experiment with alternate selection methods via our Futarchy Experiment\n\nWho Should be a Citizen\nimage836×328 6.33 KB\n\nWe will work towards Citizenship Selection via Citizenship Approach for 2025\n\nWe’ll post another update at the mid-point and end of Season 7 and are happy to join any conversations facilitated by the Anticapture Commission on our progress towards the above milestones!\n\n Allow the Optimism Foundation to Stake a Portion of Sequencer ETH Through Season 8\n\n Unlisted on Jan 30, 2025\n\n Listed on Feb 4, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Governance Update #10\n\n Governance Updates\n\n season-7\n\n Governance Update #10\nWe’re now at the mid-point of Season 7 (!) and wanted to update the Collective on the progress made towards our Decentralization Milestones. The Foundation is available to join any calls with the AC…\n\n read more\n\n 1\n\n 272\n\n Apr 2025\n\n Season 7: Guide to Season 7\n\n Metagovernance\n\n season-7\n\n This post serves as an introduction to the upcoming Season of Optimism Governance. The audience for this post is all governance participants (delegates and Citizens). \nIf you’re a builder, check out how to Get a Grant. \nD…\n\n read more\n\n 19\n\n 6.5k\n\n Apr 2025\n\n Governance Update #11\n\n Governance Updates\n\n Governance Update #11\nThe Collective has been hard at work and it’s already time for our midpoint update on the progress made towards our Decentralization Milestones! \n\nSeason 8\nIn Season 8, we’re focused on the below mi…\n\n read more\n\n 0\n\n 227\n\n Oct 2025\n\n Guide to Season 8\n\n Metagovernance\n\n season-8\n\n Season 8 begins on July 31st and runs through December 24th. The New Protocol Upgrade process will go into effect on August 1st. \nPlease read Governance in Season 8: The Next Phase for additional context on Season 8 upda…\n\n read more\n\n 8\n\n 2.9k\n\n Dec 2025\n\n Governance Report: November 2024 Update\n\n ✨ General\n\n November 2024 Update\nKey Insights\n\nHolocene Network Upgrade: \nThe Holocene Network Upgrade enhances Optimism with stricter block derivation, EIP-1559 configurability, and updated MIPS contracts for improved security, pe…\n\n read more\n\n 0\n\n 189\n\n Dec 2024","tokens":1647,"squid":"ink-governance","role":"Council Listener","at":1791259680713,"hash":"7172cb9023bde447dd772fc33205e91f7dd140ef"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/interest-rate-strategy","domain":"aave.com","title":"Interest Rate Strategy | Aave Protocol Documentation","text":"Interest Rate Strategy#\n\nImplements the calculation of the interest rates depending on the reserve state. The model of interest rate is based on two slopes, one before the OPTIMAL_USAGE_RATIO point of usage and another from that point to 100%.\nAn instance of this same contract can't be used across different Aave markets\ndue to the caching of the PoolAddressesProvider.\nThe source code is available on GitHub.\nView Methods#\ngetVariableRateSlope1#\nfunction getVariableRateSlope1(address reserve) external view returns (uint256)\nReturns the variable rate slope below the optimal usage ratio for the specified reserve. This is the variable rate when the usage ratio is between 0 and OPTIMAL_USAGE_RATIO.\nInput Parameters:#\nNameTypeDescriptionreserveaddressThe address of the reserve\nReturn Values:#\nTypeDescriptionuint256The variable rate slope\ngetVariableRateSlope2#\nfunction getVariableRateSlope2(address reserve) external view returns (uint256)\nReturns the variable rate slope above the optimal usage ratio for the specified reserve. This is the variable rate when the usage ratio is greater than OPTIMAL_USAGE_RATIO.\nInput Parameters:#\nNameTypeDescriptionreserveaddressThe address of the reserve\nReturn Values:#\nTypeDescriptionuint256The variable rate slope\ngetBaseVariableBorrowRate#\nfunction getBaseVariableBorrowRate(address reserve) external view override returns (uint256)\nReturns the base variable borrow rate for the specified reserve.\nInput Parameters:#\nNameTypeDescriptionreserveaddressThe address of the reserve\nReturn Values:#\nTypeDescriptionuint256The base variable borrow rate, expressed in ray\ngetMaxVariableBorrowRate#\nfunction getMaxVariableBorrowRate(address reserve) external view override returns (uint256)\nReturns the maximum variable borrow rate for the specified reserve.\nInput Parameters:#\nNameTypeDescriptionreserveaddressThe address of the reserve\nReturn Values:#\nTypeDescriptionuint256The maximum variable borrow rate, expressed in ray\ncalculateInterestRates#\nfunction calculateInterestRates( DataTypes.CalculateInterestRatesParams memory params) external view override returns (uint256, uint256)\nCalculates the interest rates depending on the reserve's state and configurations. This function returns only two values: the liquidity rate and the variable borrow rate.\nInput Parameters:#\nNameTypeDescriptionparamsDataTypes.CalculateInterestRatesParamsThe parameters needed to calculate interest rates\nThe DataTypes.CalculateInterestRatesParams struct is composed of the following fields:\nNameTypeDescriptionunbackeduint256The amount of unbacked tokensliquidityAddeduint256The liquidity added during the operationliquidityTakenuint256The liquidity taken during the operationtotalDebtuint256The total borrowed from the reservereserveFactoruint256The reserve portion of the interest that goes to the treasury of the marketreserveaddressThe address of the reserveusingVirtualBalanceboolFlag to indicate if the virtual balance is being usedvirtualUnderlyingBalanceuint256The virtual balance of underlying asset used for mintable assets\nReturn Values:#\nNameTypeDescriptionliquidityRateuint256The liquidity rate, expressed in rayvariableBorrowRateuint256The variable borrow rate, expressed in rayPreviousTokenizationNextAccess Control Manager","tokens":816,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259682693,"hash":"65f4ad45462c9eb90ed2513e2035655a72ee7018"}
{"url":"https://ethresear.ch/t/failure-modes-in-eip-8037-and-state-gas-scaling/23975","domain":"ethresear.ch","title":"Failure modes in EIP-8037 and state-gas scaling - Execution Layer Research - Ethereum Research","text":"Failure modes in EIP-8037 and state-gas scaling \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 29\n\n 1 / 2\n\n Jan 28\n\n Feb 4\n\n post by aelowsson on Jan 29\n\n aelowsson\n\n This note reviews the two equilibrium failure modes that arise in EIP-8037 when users do not wish to spend 50% of their budget on state creation, and presents the corrective state gas scaling measures that then can be deployed. In the extreme, if users continue creating as many state bytes per consumed regular gas unit as they do today and Ethereum scales the gas limit by 10x, then around 6.2% of the regular blockspace will be utilized under equilibrium. This would forfeit a great part of the scaling gains achieved via ePBS and BALs. Two direct adjustments can be made if it turns out that demand does not produce a 50/50 spending distribution: (1) adopt the EIP-8075 pricing that automatically expands and contracts the state gas limit; or (2) manually expand/contract the state gas limit, either in a regular hard fork or in a “state-gas parameter only” (SGPO) hardfork.\nFailure modes\nEthereum is focused on scaling the layer 1, with headliners EIP-7732 (ePBS) and EIP-7928 (BALs) scheduled for inclusion in Glamsterdam. If the gas cost for state creation is not adjusted, state would likely grow roughly in line with an expanding gas limit. Therefore, EIP-8037 raises the gas cost for state creation substantially. A concern (1, 2, 3) associated with this change is that the proportion of the total gas that is spent on state creation may rise, thus crowding out regular gas. For example, assume that ePBS and BALs together with compute repricings allow for a 600M gas limit, a midpoint of the numbers discussed here. With the current EIP-8037 specification that relies on the EIP-8011 metering rule, if users are not sensitive to the state gas cost increase and create as much state relative to consumed regular gas as they do today, then only around 6.2% of the regular blockspace would be utilized under equilibrium. The scaling gains from ePBS, BALs and compute repricings would then largely be lost.\nOf course, we may hope that users create fewer state bytes per regular gas unit when the cost of state creation increases, but the price-elasticity of demand for state creation is unknown and seems impossible to predict in a reliable manner. Should users start consuming for example half as many state bytes per regular gas unit as today, then the situation improves somewhat, and 12.3% of the block gas limit can be utilized. The ideal scenario is if users consume 8.1 times fewer state bytes per regular gas unit than today. In this case, both state gas and regular gas can be utilized at a 50/50 capacity (or realistically, perhaps closer to 40/40, if the EIP-8011 pricing uses the max operator). Should relative consumption of state creation fall more than that, then an opposite effect takes place, and users are creating less than the desired 100 GiB of state per year.\nFigure 1 outlines the two equilibrium failure modes that are possible under EIP-8011 pricing: too few state bytes created, or too little regular gas consumed. The current design works optimally if users are willing to spend 50% of their budget on regular gas and 50% of their budget on state gas, regardless of the relative prices between the two. If this is not the case, one side will crowd out the other under equilibrium.\nFigure 11442×1178 84.4 KB\nFigure 1. The two failure modes of the EIP-8011 pricing mechanism applied in EIP-8037. If demand for state creation is relatively lower than what researchers predicted, too little state is created under equilibrium (its price is too high to match demand). If demand for state creation is relatively higher than what researchers predicted, too little regular gas is consumed under equilibrium (its price is too high to match demand).\nAverting failure\nThe deeper issue is that the EIP-8011 pricing mechanism does not track state creation over time (or more generally speaking, any value that reflects the balance in demand between state and non-state operations). It therefore cannot adjust the state gas cost such that both the state resource and regular resource are at target demand. We may end up with either state or all other resources significantly underutilized under equilibrium. There are two options to alleviate this:\n\nto track state creation over time using a header variable and automatically adjust the balance between state gas and regular gas, as proposed in EIP-8075; or\nto manually readjust the balance between state gas and regular gas after observing a lopsided distribution, potentially using state-gas (or state-growth) parameter only hardforks.\n\n(1) Averting failure modes via EIP-8075\nApplying the EIP-8075 pricing mechanism for EIP-8037 resolves the issue in a principled manner. Under EIP-8075, state creation has a variable gas cost that adapts with demand such that the desired number of state bytes are created over time. The state gas target and limit expands and contracts automatically with the gas cost (since the pricing mechanism operates over state bytes). The metered gas is computed as the average of the regular gas and a normalized measure of state gas. This allows regular gas to be consumed at its targeted level over time, while the protocol also guarantees that a target number of state bytes are created.\nFigure 22002×1178 171 KB\nFigure 2. EIP-8075 automatically adjusts the gas cost with demand to ensure a target creation of state bytes in the long run. To achieve this, the EIP expands and contracts the gas target and limit while adapting the gas cost such that a target number of state bytes are consumed.\n(2) Averting failure modes manually in regular/SGPO hardforks\nThe second option is to mirror the idea of EIP-8075, but to make the adjustments manually. The state gas target and limit can in this case ideally be allowed to expand and contract as in EIP-8075 (Figure 2), such that the metering equation remains responsive to both regular and state gas. If implemented as a SGPO hardfork, a stateSchedule can be introduced and initiated as:\n{\n \"stateSchedule\": {\n \"gloas\": {\n \"target\": 107374182400,\n \"scale\": 100\n }\n },\n \"gloasTime\": \"TBD\"\n}\n\nThe scale parameter allows the state gas limit to be expanded or contracted relative to the block gas limit, and the target parameter sets the yearly state growth under full utilization. The state_gas_limit is computed as state_gas_limit = gas_limit * stateSchedule.scale // 100, and the cost_per_state_byte computed by replacing gas_limit with state_gas_limit in the following expression:\ncost_per_state_byte = state_gas_limit * 7200 * 365 // (stateSchedule.target * 2)\n\nWhen the metering function F finally is applied (where F could be max or any other function discussed here), it is just as in EIP-8075 applied to a normalized measure of state gas: F(regular_gas, state_gas * 100 // stateSchedule.scale). Since the demand-elasticity is unknown, a single manual correction may not hit the mark perfectly. It therefore seems reasonable to overshoot a little if too little regular gas is consumed under equilibrium, to retain scaling. It is also possible to “overshoot” more generally by targeting a higher proportion of state gas relative to the limit than 0.5, as outlined here.\nNote that the scale parameter would be the key rationale for adding SGPO hardforks. Without the scale parameter, Ethereum risks entering Failure mode 2 in Figure 1, foregoing some proportion of the scaling gains of ePBS and BALs. The ability to also adjust the target growth is welcome, but would not in isolation warrant the implementation complexity. In other words, both the target and scale could be set and adjusted in a regular hardfork, but only the lack of a scale parameter may warrant SGPO hardforks.\nStylized equilibrium\nThe equilibrium outcome under EIP-8011 pricing in EIP-8037 can be rudimentarily analyzed by focusing on relative demand elasticities between the two resources (as here and here, with a general write-up on demand elasticities also available here).\nThere is a fixed gas cost and both resources have the same base fee. Initially, before implementing EIP-8037, 70% of all gas is spent on operations that will be charged under regular gas, G_1=0.7𝐺1 =0.7 and 30% of the gas is spent on state creation, G_2 = 0.3𝐺2 =0.3. If demand becomes balanced between regular and state gas under the fixed gas cost that EIP-8037 specifies at any given gas limit, such that users spend an equal amount of gas on both, the mechanism will work perfectly as intended. The ratio r𝑟 of the gas spent on the two resources is then 1:\n\nr = \\frac{G'_1}{G'_2} = 1.\n𝑟=𝐺′1𝐺′2=1.\nLet the gas cost of state creation increase by a factor p𝑝 and let d𝑑 represent how many times fewer state bytes users are willing to create per consumed regular gas unit, under the given cost increase. The new ratio between consumed regular and state gas is then:\n\nr = \\frac{G_1}{G_2(p/d)} = \\frac{G_1 d}{G_2 p}.\n𝑟=𝐺1𝐺2(𝑝/𝑑)=𝐺1𝑑𝐺2𝑝.\nUnder equilibrium when using the max function (as in EIP-8037) and ignoring how block variability pushes down the equilibrium proportions, the metered dimension (the larger of regular and state gas) will sit at the target. Users will then consume regular gas at a proportion of G^*_1 = \\min(0.5, 0.5r)𝐺∗1 =min(0.5,0.5𝑟) of the gas limit, and state gas at a proportion of G^*_2 = \\min(0.5, 0.5/r)𝐺∗2 =min(0.5,0.5/𝑟).\nThe baseline EIP-8037 cost increase at 60M gas is 1.17x for storage slots, 3.29x for accounts, and 3.67x for code. A weighted average gas cost increase across these three metrics based on current growth trajectories (storage snapshot, account snapshot, contract codes) between block 17,165,429 and block 21,000,000 is around 1.89x. Uncertainty in the current weighted average is duly acknowledged.\nInvestigating a 10x scaling facilitated by BALs, ePBS and repricing, the weighted average gas cost increase would with the EIP-8037 specification be 18.9x. Thus, setting p=18.9𝑝 =18.9 and assuming that users do not change their current usage pattern (d=1𝑑 =1), the ratio becomes\n\nr=0.7/(0.3 \\times 18.9)=0.123.\n𝑟=0.7/(0.3×18.9)=0.123.\nUsers will then only consume regular gas at a proportion of\n\nG^*_1 = 0.5 \\times 0.123 = 0.062\n𝐺∗1=0.5×0.123=0.062\nof the gas limit under equilibrium. If users halve their state creation per regular gas unit, then the equilibrium becomes G^*_1 = 0.123𝐺∗1 =0.123. The optimum reduction in state byte consumption per regular gas unit is obtained by restoring balance (r=1𝑟 =1), which implies:\n\nd^* = \\frac{G_2p}{G_1} = \\frac{0.3\\cdot 18.9}{0.7} = 8.1.\n𝑑∗=𝐺2𝑝𝐺1=0.3⋅18.90.7=8.1.\nLooking ahead\nAs Ethereum continues to scale, the difficulty in predicting the state gas cost that balances gas expenditures increases, as does the severity of the worst failure modes. As an example, at a 30x L1 scaling, only 2.1% of the blockspace for regular gas is utilized under equilibrium, if users do not change state byte creation per regular gas usage (but the high gas cost should at this point incentivize users to make rather substantial adjustments to how much state they create). By the point a 30x scaling is reached, a more comprehensive solution to the problem will ideally have been deployed. Such a solution consists of a full multidimensional fee market as in EIP-7999, and engineering efforts to better handle state growth (potentially expiring some part of the state).\n\n Analysis of different aggregation functions for EIP-8037 under different elasticity regimes\n\n How Hegotá can influence the state roadmap\n\n Designs for EVM gas accounting in EIP-7999\n\n How Hegotá should approach gas repricing\n\n read \n\n 5\n min\n\n post by aelowsson on Feb 4\n\n Powered by Discourse","tokens":2948,"squid":"ink-research","role":"Deep Scholar","at":1791259688483,"hash":"b2b8c4e4efaa375d50352bf4b82e192a635bff6f"}
{"url":"https://docs.soliditylang.org/en/latest/contributing.html","domain":"docs.soliditylang.org","title":"Contributing — Solidity 0.8.38-develop documentation","text":"Contributing\n\n Edit on GitHub\n\nContributing\nHelp is always welcome and there are plenty of options to contribute to Solidity.\nIn particular, we appreciate support in the following areas:\n\nReporting issues.\nFixing and responding to Solidity’s GitHub issues, especially those tagged as\n“good first issue” which are\nmeant as introductory issues for external contributors.\nImproving the documentation.\nTranslating the documentation into more languages.\nResponding to questions from other users on StackExchange and the Solidity Gitter Chat.\nGetting involved in the language design process by proposing language changes or new features in the Solidity forum and providing feedback.\n\nTo get started, you can try Building from Source in order to familiarize\nyourself with the components of Solidity and the build process. Also, it may be\nuseful to become well-versed at writing smart-contracts in Solidity.\nPlease note that this project is released with a Contributor Code of Conduct. By participating in this project — in the issues, pull requests, or Gitter channels — you agree to abide by its terms.\n\nTeam Calls\nIf you have issues or pull requests to discuss, or are interested in hearing what\nthe team and contributors are working on, you can join our public team call:\n\nWednesdays at 3PM CET/CEST.\n\nThe call takes place on Jitsi.\nNew topics can be freely added to the agenda\nand will be scheduled for discussion on the nearest call.\n\nHow to Report Issues\nTo report an issue, please use the\nGitHub issues tracker. When\nreporting issues, please mention the following details:\n\nSolidity version.\nSource code (if applicable).\nOperating system.\nSteps to reproduce the issue.\nActual vs. expected behavior.\n\nReducing the source code that caused the issue to a bare minimum is always\nvery helpful, and sometimes even clarifies a misunderstanding.\nFor technical discussions about language design, a post in the\nSolidity forum is the correct place (see Solidity Language Design).\n\nWorkflow for Pull Requests\nIn order to contribute, please fork off of the develop branch and make your\nchanges there. Your commit messages should detail why you made your change\nin addition to what you did (unless it is a tiny change).\nIf you need to pull in any changes from develop after making your fork (for\nexample, to resolve potential merge conflicts), please avoid using git merge\nand instead, git rebase your branch. This will help us review your change\nmore easily.\nAdditionally, if you are writing a new feature, please ensure you add appropriate\ntest cases under test/ (see below).\nHowever, if you are making a larger change, please consult with the Solidity Development Gitter channel (different from the one mentioned above — this one is\nfocused on compiler and language development instead of language usage) first.\nNew features and bugfixes should be added to the Changelog.md file: please\nfollow the style of previous entries, when applicable.\nFinally, please make sure you respect the coding style\nfor this project. Also, even though we do CI testing, please test your code and\nensure that it builds locally before submitting a pull request.\nWe highly recommend going through our review checklist before submitting the pull request.\nWe thoroughly review every PR and will help you get it right, but there are many common problems that can be easily avoided, making the review much smoother.\nThank you for your help!\n\nAI-Assisted Contributions\nWe do not ban the use of AI tools, but we hold all contributions to the same high standard\nregardless of how they are produced, and we require full transparency about their use.\nSubmitting AI-generated code means you have reviewed it, understand it, can explain it, and have\ntested it as thoroughly as if you had written it by hand.\nIf you used AI tools to generate code, tests, or documentation in any part of your contribution,\ndisclosure in the pull request is mandatory.\nIf we determine that a PR contains undisclosed AI-generated content, we may close it.\n\nRunning the Compiler Tests\n\nPrerequisites\nFor running all compiler tests you may want to optionally install a few\ndependencies (evmone,\nz3, Eldarica,\ncvc5).\nOn macOS systems, some of the testing scripts expect GNU coreutils to be installed.\nThis can be easiest accomplished using Homebrew: brew install coreutils.\nOn Windows systems, make sure that you have a privilege to create symlinks,\notherwise several tests may fail.\nAdministrators should have that privilege, but you may also\ngrant it to other users\nor\nenable Developer Mode.\n\nRunning the Tests\nSolidity includes different types of tests, most of them bundled into the\nBoost C++ Test Framework application soltest.\nRunning build/test/soltest or its wrapper scripts/soltest.sh is sufficient for most changes.\nThe ./scripts/tests.sh script executes most Solidity tests automatically,\nincluding those bundled into the Boost C++ Test Framework\napplication soltest (or its wrapper scripts/soltest.sh), as well as command-line tests and\ncompilation tests.\nThe test system automatically tries to discover the location of\nthe evmone for running the semantic tests.\nThe evmone library must be located in the deps or deps/lib directory relative to the\ncurrent working directory, to its parent or its parent’s parent. Alternatively, an explicit location\nfor the evmone shared object can be specified via the ETH_EVMONE environment variable.\nevmone is needed mainly for running semantic and gas tests.\nIf you do not have it installed, you can skip these tests by passing the --no-semantic-tests\nflag to scripts/soltest.sh.\nThe evmone library should end with the file name\nextension .so on Linux, .dll on Windows systems and .dylib on macOS.\nFor running SMT tests, the z3 executable must be present in PATH.\nA few SMT tests use Eldarica instead of z3.\nThese require its executable (eld) to be present in PATH for the tests to pass.\nHowever, if Eldarica is not found, these tests will be automatically skipped.\nIf z3 is not present on your system, you should disable the\nSMT tests by exporting SMT_FLAGS=--no-smt before running ./scripts/tests.sh or\nrunning ./scripts/soltest.sh --no-smt.\nThese tests are libsolidity/smtCheckerTests.\n\nNote\nTo get a list of all unit tests run by Soltest, run ./build/test/soltest --list_content=HRF.\n\nFor quicker results you can run a subset of, or specific tests.\nTo run a subset of tests, you can use filters:\n./scripts/soltest.sh -t TestSuite/TestName,\nwhere TestName can be a wildcard *.\nOr, for example, to run all the tests for the yul disambiguator:\n./scripts/soltest.sh -t \"yulOptimizerTests/disambiguator/*\" --no-smt.\n./build/test/soltest --help has extensive help on all of the options available.\nSee especially:\n\nshow_progress (-p) to show test completion,\nrun_test (-t) to run specific tests cases, and\nreport-level (-r) give a more detailed report.\n\nNote\nThose working in a Windows environment wanting to run the above basic sets\nwithout z3. Using Git Bash, you use: ./build/test/Release/soltest.exe -- --no-smt.\nIf you are running this in plain Command Prompt, use .\\build\\test\\Release\\soltest.exe -- --no-smt.\n\nIf you want to debug using GDB, make sure you build differently than the “usual”.\nFor example, you could run the following command in your build folder:\ncmake -DCMAKE_BUILD_TYPE=Debug ..\nmake\n\nThis creates symbols so that when you debug a test using the --debug flag,\nyou have access to functions and variables in which you can break or print with.\nThe CI runs additional tests (including solc-js and testing third party Solidity\nframeworks) that require compiling the Emscripten target.\n\nWriting and Running Syntax Tests\nSyntax tests check that the compiler generates the correct error messages for invalid code\nand properly accepts valid code.\nThey are stored in individual files inside the tests/libsolidity/syntaxTests folder.\nThese files must contain annotations, stating the expected result(s) of the respective test.\nThe test suite compiles and checks them against the given expectations.\nFor example: ./test/libsolidity/syntaxTests/double_stateVariable_declaration.sol\nopen in Remix\ncontract test {\n uint256 variable;\n uint128 variable;\n}\n// ----\n// DeclarationError: (36-52): Identifier already declared.\n\nA syntax test must contain at least the contract under test itself, followed by the separator // ----. The comments that follow the separator are used to describe the\nexpected compiler errors or warnings. The number range denotes the location in the source where the error occurred.\nIf you want the contract to compile without any errors or warning you can leave\nout the separator and the comments that follow it.\nIn the above example, the state variable variable was declared twice, which is not allowed. This results in a DeclarationError stating that the identifier was already declared.\nThe isoltest tool is used for these tests and you can find it under ./build/test/tools/. It is an interactive tool which allows\nediting of failing contracts using your preferred text editor. Let’s try to break this test by removing the second declaration of variable:\nopen in Remix\ncontract test {\n uint256 variable;\n}\n// ----\n// DeclarationError: (36-52): Identifier already declared.\n\nRunning ./build/test/tools/isoltest again results in a test failure:\nsyntaxTests/double_stateVariable_declaration.sol: FAIL\n Contract:\n contract test {\n uint256 variable;\n }\n\n Expected result:\n DeclarationError: (36-52): Identifier already declared.\n Obtained result:\n Success\n\nisoltest prints the expected result next to the obtained result, and also\nprovides a way to edit, update or skip the current contract file, or quit the application.\nIt offers several options for failing tests:\n\nedit: isoltest tries to open the contract in an editor so you can adjust it. It either uses the editor given on the command-line (as isoltest --editor /path/to/editor), in the environment variable EDITOR or just /usr/bin/editor (in that order).\nupdate: Updates the expectations for contract under test. This updates the annotations by removing unmet expectations and adding missing expectations. The test is then run again.\nskip: Skips the execution of this particular test.\nquit: Quits isoltest.\n\nAll of these options apply to the current contract, except quit which stops the entire testing process.\nAutomatically updating the test above changes it to\nopen in Remix\ncontract test {\n uint256 variable;\n}\n// ----\n\nand re-run the test. It now passes again:\nRe-running test case...\nsyntaxTests/double_stateVariable_declaration.sol: OK\n\nNote\nChoose a name for the contract file that explains what it tests, e.g. double_variable_declaration.sol.\nDo not put more than one contract into a single file, unless you are testing inheritance or cross-contract calls.\nEach file should test one aspect of your new feature.\n\nCommand-line Tests\nOur suite of end-to-end command-line tests checks the behaviour of the compiler binary as a whole\nin various scenarios.\nThese tests are located in test/cmdlineTests/,\none per subdirectory, and can be executed using the cmdlineTests.sh script.\nBy default the script runs all available tests.\nYou can also provide one or more file name patterns,\nin which case only the tests matching at least one pattern will be executed.\nIt is also possible to exclude files matching a specific pattern by prefixing it with --exclude.\nBy default the script assumes that a solc binary is available inside the build/ subdirectory\ninside the working copy.\nIf you build the compiler outside of the source tree, you can use the SOLIDITY_BUILD_DIR environment\nvariable to specify a different location for the build directory.\nExample:\nexport SOLIDITY_BUILD_DIR=~/solidity/build/\ntest/cmdlineTests.sh \"standard_*\" \"*_yul_*\" --exclude \"standard_yul_*\"\n\nThe commands above will run tests from directories starting with test/cmdlineTests/standard_ and\nsubdirectories of test/cmdlineTests/ that have _yul_ somewhere in the name,\nbut no test whose name starts with standard_yul_ will be executed.\nIt will also assume that the file solidity/build/solc/solc inside your home directory is the\ncompiler binary (unless you are on Windows – then solidity/build/solc/Release/solc.exe).\nThere are several kinds of command-line tests:\n\nStandard JSON test: contains at least an input.json file.\nIn general may contain:\n\ninput.json: input file to be passed to the --standard-json option on the command line.\noutput.json: expected Standard JSON output.\nargs: extra command-line arguments passed to solc.\n\nCLI test: contains at least an input.* file (other than input.json).\nIn general may contain:\n\ninput.*: a single input file, whose name will be supplied to solc on the command line.\nUsually input.sol or input.yul.\nargs: extra command-line arguments passed to solc.\nstdin: content to be passed to solc via standard input.\noutput: expected content of the standard output.\nerr: expected content of the standard error output.\nexit: expected exit code. If not provided, zero is expected.\n\nScript test: contains a test.* file.\nIn general may contain:\n\ntest.*: a single script to run, usually test.sh or test.py.\nThe script must be executable.\n\nRunning the Fuzzer via AFL\nFuzzing is a technique that runs programs on more or less random inputs to find exceptional execution\nstates (segmentation faults, exceptions, etc). Modern fuzzers are clever and run a directed search\ninside the input. We have a specialized binary called solfuzzer which takes source code as input\nand fails whenever it encounters an internal compiler error, segmentation fault or similar, but\ndoes not fail if e.g., the code contains an error. This way, fuzzing tools can find internal problems in the compiler.\nWe mainly use AFL for fuzzing. You need to download and\ninstall the AFL packages from your repositories (afl, afl-clang) or build them manually.\nNext, build Solidity (or just the solfuzzer binary) with AFL as your compiler:\ncd build\n# if needed\nmake clean\ncmake .. -DCMAKE_C_COMPILER=path/to/afl-gcc -DCMAKE_CXX_COMPILER=path/to/afl-g++\nmake solfuzzer\n\nAt this stage, you should be able to see a message similar to the following:\nScanning dependencies of target solfuzzer\n[ 98%] Building CXX object test/tools/CMakeFiles/solfuzzer.dir/fuzzer.cpp.o\nafl-cc 2.52b by <lcamtuf@google.com>\nafl-as 2.52b by <lcamtuf@google.com>\n[+] Instrumented 1949 locations (64-bit, non-hardened mode, ratio 100%).\n[100%] Linking CXX executable solfuzzer\n\nIf the instrumentation messages did not appear, try switching the cmake flags pointing to AFL’s clang binaries:\n# if previously failed\nmake clean\ncmake .. -DCMAKE_C_COMPILER=path/to/afl-clang -DCMAKE_CXX_COMPILER=path/to/afl-clang++\nmake solfuzzer\n\nOtherwise, upon execution the fuzzer halts with an error saying binary is not instrumented:\nafl-fuzz 2.52b by <lcamtuf@google.com>\n... (truncated messages)\n[*] Validating target binary...\n\n[-] Looks like the target binary is not instrumented! The fuzzer depends on\n compile-time instrumentation to isolate interesting test cases while\n mutating the input data. For more information, and for tips on how to\n instrument binaries, please see /usr/share/doc/afl-doc/docs/README.\n\n When source code is not available, you may be able to leverage QEMU\n mode support. Consult the README for tips on how to enable this.\n (It is also possible to use afl-fuzz as a traditional, \"dumb\" fuzzer.\n For that, you can use the -n option - but expect much worse results.)\n\n[-] PROGRAM ABORT : No instrumentation detected\n Location : check_binary(), afl-fuzz.c:6920\n\nNext, you need some example source files. This makes it much easier for the fuzzer\nto find errors. You can either copy some files from the syntax tests or extract test files\nfrom the documentation or the other tests:\nmkdir /tmp/test_cases\ncd /tmp/test_cases\n# extract from tests:\npath/to/solidity/scripts/isolate_tests.py path/to/solidity/test/libsolidity/SolidityEndToEndTest.cpp\n# extract from documentation:\npath/to/solidity/scripts/isolate_tests.py path/to/solidity/docs\n\nThe AFL documentation states that the corpus (the initial input files) should not be\ntoo large. The files themselves should not be larger than 1 kB and there should be\nat most one input file per functionality, so better start with a small number of.\nThere is also a tool called afl-cmin that can trim input files\nthat result in similar behavior of the binary.\nNow run the fuzzer (the -m extends the size of memory to 60 MB):\nafl-fuzz -m 60 -i /tmp/test_cases -o /tmp/fuzzer_reports -- /path/to/solfuzzer\n\nThe fuzzer creates source files that lead to failures in /tmp/fuzzer_reports.\nOften it finds many similar source files that produce the same error. You can\nuse the tool scripts/uniqueErrors.sh to filter out the unique errors.\n\nWhiskers\nWhiskers is a string templating system similar to Mustache. It is used by the\ncompiler in various places to aid readability, and thus maintainability and verifiability, of the code.\nThe syntax comes with a substantial difference to Mustache. The template markers {{ and }} are\nreplaced by < and > in order to aid parsing and avoid conflicts with Yul\n(The symbols < and > are invalid in inline assembly, while { and } are used to delimit blocks).\nAnother limitation is that lists are only resolved one depth and they do not recurse. This may change in the future.\nA rough specification is the following:\nAny occurrence of <name> is replaced by the string-value of the supplied variable name without any\nescaping and without iterated replacements. An area can be delimited by <#name>...</name>. It is replaced\nby as many concatenations of its contents as there were sets of variables supplied to the template system,\neach time replacing any <inner> items by their respective value. Top-level variables can also be used\ninside such areas.\nThere are also conditionals of the form <?name>...<!name>...</name>, where template replacements\ncontinue recursively either in the first or the second segment depending on the value of the boolean\nparameter name. If <?+name>...<!+name>...</+name> is used, then the check is whether\nthe string parameter name is non-empty.\n\nDocumentation Style Guide\nIn the following section you find style recommendations specifically focusing on documentation\ncontributions to Solidity.\n\nEnglish Language\nUse International English, unless using project or brand names. Try to reduce the usage of\nlocal slang and references, making your language as clear to all readers as possible.\nBelow are some references to help:\n\nSimplified technical English\nInternational English\n\nNote\nWhile the official Solidity documentation is written in English, there are community contributed Translations\nin other languages available. Please refer to the translation guide\nfor information on how to contribute to the community translations.\n\nTitle Case for Headings\nUse title case for headings. This means capitalise all principal words in\ntitles, but not articles, conjunctions, and prepositions unless they start the\ntitle.\nFor example, the following are all correct:\n\nTitle Case for Headings.\nFor Headings Use Title Case.\nLocal and State Variable Names.\nOrder of Layout.\n\nExpand Contractions\nUse expanded contractions for words, for example:\n\n“Do not” instead of “Don’t”.\n“Can not” instead of “Can’t”.\n\nActive and Passive Voice\nActive voice is typically recommended for tutorial style documentation as it\nhelps the reader understand who or what is performing a task. However, as the\nSolidity documentation is a mixture of tutorials and reference content, passive\nvoice is sometimes more applicable.\nAs a summary:\n\nUse passive voice for technical reference, for example language definition and internals of the Ethereum VM.\nUse active voice when describing recommendations on how to apply an aspect of Solidity.\n\nFor example, the below is in passive voice as it specifies an aspect of Solidity:\n\nFunctions can be declared pure in which case they promise not to read\nfrom or modify the state.\n\nFor example, the below is in active voice as it discusses an application of Solidity:\n\nWhen invoking the compiler, you can specify how to discover the first element\nof a path, and also path prefix remappings.\n\nCommon Terms\n\n“Function parameters” and “return variables”, not input and output parameters.\n\nCode Examples\nA CI process tests all code block formatted code examples that begin with pragma solidity, contract, library\nor interface using the ./test/cmdlineTests.sh script when you create a PR. If you are adding new code examples,\nensure they work and pass tests before creating the PR.\nEnsure that all code examples begin with a pragma version that spans the largest where the contract code is valid.\nFor example pragma solidity >=0.4.0 <0.9.0;.\n\nRunning Documentation Tests\nMake sure your contributions pass our documentation tests by running ./docs/docs.sh that installs dependencies\nneeded for documentation and checks for any problems such as broken links or syntax issues.\n\nSolidity Language Design\nTo actively get involved in the language design process and to share your ideas concerning the future of Solidity,\nplease join the Solidity forum.\nThe Solidity forum serves as the place to propose and discuss new language features and their implementation in\nthe early stages of ideation or modifications of existing features.\nAs soon as proposals get more tangible, their\nimplementation will also be discussed in the Solidity GitHub repository\nin the form of issues.\nIn addition to the forum and issue discussions, we regularly host language design discussion calls in which selected\ntopics, issues or feature implementations are debated in detail. The invitation to those calls is shared via the forum.\nWe are also sharing feedback surveys and other content that is relevant to language design in the forum.\nIf you want to know where the team is standing in terms of implementing new features, you can follow the implementation status in the Solidity GitHub project.\nIssues in the design backlog need further specification and will either be discussed in a language design call or in a regular team call. You can\nsee the upcoming changes for the next breaking release by changing from the default branch (develop) to the breaking branch.\nFor ad-hoc cases and questions, you can reach out to us via the Solidity-dev Gitter channel — a\ndedicated chatroom for conversations around the Solidity compiler and language development.\nWe are happy to hear your thoughts on how we can improve the language design process to be even more collaborative and transparent.","tokens":5622,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259695635,"hash":"ee77dedb3fc348ae4fae6488425b06ceae92f36a"}
{"url":"https://ethresear.ch/t/failure-modes-in-eip-8037-and-state-gas-scaling/23975/1","domain":"ethresear.ch","title":"Failure modes in EIP-8037 and state-gas scaling - Execution Layer Research - Ethereum Research","text":"Failure modes in EIP-8037 and state-gas scaling \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 29\n\n 1 / 2\n\n Jan 28\n\n Feb 4\n\n post by aelowsson on Jan 29\n\n aelowsson\n\n This note reviews the two equilibrium failure modes that arise in EIP-8037 when users do not wish to spend 50% of their budget on state creation, and presents the corrective state gas scaling measures that then can be deployed. In the extreme, if users continue creating as many state bytes per consumed regular gas unit as they do today and Ethereum scales the gas limit by 10x, then around 6.2% of the regular blockspace will be utilized under equilibrium. This would forfeit a great part of the scaling gains achieved via ePBS and BALs. Two direct adjustments can be made if it turns out that demand does not produce a 50/50 spending distribution: (1) adopt the EIP-8075 pricing that automatically expands and contracts the state gas limit; or (2) manually expand/contract the state gas limit, either in a regular hard fork or in a “state-gas parameter only” (SGPO) hardfork.\nFailure modes\nEthereum is focused on scaling the layer 1, with headliners EIP-7732 (ePBS) and EIP-7928 (BALs) scheduled for inclusion in Glamsterdam. If the gas cost for state creation is not adjusted, state would likely grow roughly in line with an expanding gas limit. Therefore, EIP-8037 raises the gas cost for state creation substantially. A concern (1, 2, 3) associated with this change is that the proportion of the total gas that is spent on state creation may rise, thus crowding out regular gas. For example, assume that ePBS and BALs together with compute repricings allow for a 600M gas limit, a midpoint of the numbers discussed here. With the current EIP-8037 specification that relies on the EIP-8011 metering rule, if users are not sensitive to the state gas cost increase and create as much state relative to consumed regular gas as they do today, then only around 6.2% of the regular blockspace would be utilized under equilibrium. The scaling gains from ePBS, BALs and compute repricings would then largely be lost.\nOf course, we may hope that users create fewer state bytes per regular gas unit when the cost of state creation increases, but the price-elasticity of demand for state creation is unknown and seems impossible to predict in a reliable manner. Should users start consuming for example half as many state bytes per regular gas unit as today, then the situation improves somewhat, and 12.3% of the block gas limit can be utilized. The ideal scenario is if users consume 8.1 times fewer state bytes per regular gas unit than today. In this case, both state gas and regular gas can be utilized at a 50/50 capacity (or realistically, perhaps closer to 40/40, if the EIP-8011 pricing uses the max operator). Should relative consumption of state creation fall more than that, then an opposite effect takes place, and users are creating less than the desired 100 GiB of state per year.\nFigure 1 outlines the two equilibrium failure modes that are possible under EIP-8011 pricing: too few state bytes created, or too little regular gas consumed. The current design works optimally if users are willing to spend 50% of their budget on regular gas and 50% of their budget on state gas, regardless of the relative prices between the two. If this is not the case, one side will crowd out the other under equilibrium.\nFigure 11442×1178 84.4 KB\nFigure 1. The two failure modes of the EIP-8011 pricing mechanism applied in EIP-8037. If demand for state creation is relatively lower than what researchers predicted, too little state is created under equilibrium (its price is too high to match demand). If demand for state creation is relatively higher than what researchers predicted, too little regular gas is consumed under equilibrium (its price is too high to match demand).\nAverting failure\nThe deeper issue is that the EIP-8011 pricing mechanism does not track state creation over time (or more generally speaking, any value that reflects the balance in demand between state and non-state operations). It therefore cannot adjust the state gas cost such that both the state resource and regular resource are at target demand. We may end up with either state or all other resources significantly underutilized under equilibrium. There are two options to alleviate this:\n\nto track state creation over time using a header variable and automatically adjust the balance between state gas and regular gas, as proposed in EIP-8075; or\nto manually readjust the balance between state gas and regular gas after observing a lopsided distribution, potentially using state-gas (or state-growth) parameter only hardforks.\n\n(1) Averting failure modes via EIP-8075\nApplying the EIP-8075 pricing mechanism for EIP-8037 resolves the issue in a principled manner. Under EIP-8075, state creation has a variable gas cost that adapts with demand such that the desired number of state bytes are created over time. The state gas target and limit expands and contracts automatically with the gas cost (since the pricing mechanism operates over state bytes). The metered gas is computed as the average of the regular gas and a normalized measure of state gas. This allows regular gas to be consumed at its targeted level over time, while the protocol also guarantees that a target number of state bytes are created.\nFigure 22002×1178 171 KB\nFigure 2. EIP-8075 automatically adjusts the gas cost with demand to ensure a target creation of state bytes in the long run. To achieve this, the EIP expands and contracts the gas target and limit while adapting the gas cost such that a target number of state bytes are consumed.\n(2) Averting failure modes manually in regular/SGPO hardforks\nThe second option is to mirror the idea of EIP-8075, but to make the adjustments manually. The state gas target and limit can in this case ideally be allowed to expand and contract as in EIP-8075 (Figure 2), such that the metering equation remains responsive to both regular and state gas. If implemented as a SGPO hardfork, a stateSchedule can be introduced and initiated as:\n{\n \"stateSchedule\": {\n \"gloas\": {\n \"target\": 107374182400,\n \"scale\": 100\n }\n },\n \"gloasTime\": \"TBD\"\n}\n\nThe scale parameter allows the state gas limit to be expanded or contracted relative to the block gas limit, and the target parameter sets the yearly state growth under full utilization. The state_gas_limit is computed as state_gas_limit = gas_limit * stateSchedule.scale // 100, and the cost_per_state_byte computed by replacing gas_limit with state_gas_limit in the following expression:\ncost_per_state_byte = state_gas_limit * 7200 * 365 // (stateSchedule.target * 2)\n\nWhen the metering function F finally is applied (where F could be max or any other function discussed here), it is just as in EIP-8075 applied to a normalized measure of state gas: F(regular_gas, state_gas * 100 // stateSchedule.scale). Since the demand-elasticity is unknown, a single manual correction may not hit the mark perfectly. It therefore seems reasonable to overshoot a little if too little regular gas is consumed under equilibrium, to retain scaling. It is also possible to “overshoot” more generally by targeting a higher proportion of state gas relative to the limit than 0.5, as outlined here.\nNote that the scale parameter would be the key rationale for adding SGPO hardforks. Without the scale parameter, Ethereum risks entering Failure mode 2 in Figure 1, foregoing some proportion of the scaling gains of ePBS and BALs. The ability to also adjust the target growth is welcome, but would not in isolation warrant the implementation complexity. In other words, both the target and scale could be set and adjusted in a regular hardfork, but only the lack of a scale parameter may warrant SGPO hardforks.\nStylized equilibrium\nThe equilibrium outcome under EIP-8011 pricing in EIP-8037 can be rudimentarily analyzed by focusing on relative demand elasticities between the two resources (as here and here, with a general write-up on demand elasticities also available here).\nThere is a fixed gas cost and both resources have the same base fee. Initially, before implementing EIP-8037, 70% of all gas is spent on operations that will be charged under regular gas, G_1=0.7𝐺1 =0.7 and 30% of the gas is spent on state creation, G_2 = 0.3𝐺2 =0.3. If demand becomes balanced between regular and state gas under the fixed gas cost that EIP-8037 specifies at any given gas limit, such that users spend an equal amount of gas on both, the mechanism will work perfectly as intended. The ratio r𝑟 of the gas spent on the two resources is then 1:\n\nr = \\frac{G'_1}{G'_2} = 1.\n𝑟=𝐺′1𝐺′2=1.\nLet the gas cost of state creation increase by a factor p𝑝 and let d𝑑 represent how many times fewer state bytes users are willing to create per consumed regular gas unit, under the given cost increase. The new ratio between consumed regular and state gas is then:\n\nr = \\frac{G_1}{G_2(p/d)} = \\frac{G_1 d}{G_2 p}.\n𝑟=𝐺1𝐺2(𝑝/𝑑)=𝐺1𝑑𝐺2𝑝.\nUnder equilibrium when using the max function (as in EIP-8037) and ignoring how block variability pushes down the equilibrium proportions, the metered dimension (the larger of regular and state gas) will sit at the target. Users will then consume regular gas at a proportion of G^*_1 = \\min(0.5, 0.5r)𝐺∗1 =min(0.5,0.5𝑟) of the gas limit, and state gas at a proportion of G^*_2 = \\min(0.5, 0.5/r)𝐺∗2 =min(0.5,0.5/𝑟).\nThe baseline EIP-8037 cost increase at 60M gas is 1.17x for storage slots, 3.29x for accounts, and 3.67x for code. A weighted average gas cost increase across these three metrics based on current growth trajectories (storage snapshot, account snapshot, contract codes) between block 17,165,429 and block 21,000,000 is around 1.89x. Uncertainty in the current weighted average is duly acknowledged.\nInvestigating a 10x scaling facilitated by BALs, ePBS and repricing, the weighted average gas cost increase would with the EIP-8037 specification be 18.9x. Thus, setting p=18.9𝑝 =18.9 and assuming that users do not change their current usage pattern (d=1𝑑 =1), the ratio becomes\n\nr=0.7/(0.3 \\times 18.9)=0.123.\n𝑟=0.7/(0.3×18.9)=0.123.\nUsers will then only consume regular gas at a proportion of\n\nG^*_1 = 0.5 \\times 0.123 = 0.062\n𝐺∗1=0.5×0.123=0.062\nof the gas limit under equilibrium. If users halve their state creation per regular gas unit, then the equilibrium becomes G^*_1 = 0.123𝐺∗1 =0.123. The optimum reduction in state byte consumption per regular gas unit is obtained by restoring balance (r=1𝑟 =1), which implies:\n\nd^* = \\frac{G_2p}{G_1} = \\frac{0.3\\cdot 18.9}{0.7} = 8.1.\n𝑑∗=𝐺2𝑝𝐺1=0.3⋅18.90.7=8.1.\nLooking ahead\nAs Ethereum continues to scale, the difficulty in predicting the state gas cost that balances gas expenditures increases, as does the severity of the worst failure modes. As an example, at a 30x L1 scaling, only 2.1% of the blockspace for regular gas is utilized under equilibrium, if users do not change state byte creation per regular gas usage (but the high gas cost should at this point incentivize users to make rather substantial adjustments to how much state they create). By the point a 30x scaling is reached, a more comprehensive solution to the problem will ideally have been deployed. Such a solution consists of a full multidimensional fee market as in EIP-7999, and engineering efforts to better handle state growth (potentially expiring some part of the state).\n\n Analysis of different aggregation functions for EIP-8037 under different elasticity regimes\n\n How Hegotá can influence the state roadmap\n\n Designs for EVM gas accounting in EIP-7999\n\n How Hegotá should approach gas repricing\n\n read \n\n 5\n min\n\n post by aelowsson on Feb 4\n\n aelowsson\n\n There is also the option to have the state-gas scaling that can be applied in a SGPO hardfork instead “trigger” automatically upon observing a lopsided distribution. This requires tracking gas consumption in header variable(s). It is a very unprincipled way of achieving the properties of EIP-8075, but it does achieve them. The mechanism could be deployed in two ways:\n\nAt regular intervals (e.g., monthly), we rescale state gas as previously outlined, according to tracked gas consumption.\nIn the case that the gas consumption distribution has diverged from our predicted acceptable range, the state-scaling triggers with a one-time change to bring back a desirable distribution.\n\nPersonally, I would think that if we decide to track gas consumption in the header, we should go for the more principled price-setting solution of EIP-8075. However, I flag this as an (unprincipled/ugly) option that is available to us, while not recommending it.\n\n Powered by Discourse","tokens":3188,"squid":"ink-research","role":"Deep Scholar","at":1791259699299,"hash":"54b5f54f0a636bfd284b484054fb9cd833848854"}
{"url":"https://eips.ethereum.org/EIPS/eip-747","domain":"eips.ethereum.org","title":"EIP-747: wallet_watchAsset RPC Method","text":"🎉 Final\n\n Standards Track: Interface\n\n EIP-747: wallet_watchAsset RPC Method\n\n Adds a new RPC method that allows websites to prompt users to watch an asset\n\n Authors\n Dan Finlay (@danfinlay), Esteban Mino (@estebanmino), Gavin John (@Pandapip1)\n\n Created\n 2018-08-13\n\n Requires\n\n EIP-20, \n\n EIP-1046, \n\n EIP-1193\n\n Abstract\n\nThis EIP standardizes a new wallet-scoped RPC method, wallet_watchAsset, to allow a client to suggest a token for the user’s wallet to track.\n\n Motivation\n\nToday, one of the major uses of Ethereum wallets is to track users’ assets.\nWithout this EIP, each wallet either needs to pre-load a list of approved assets, or users must manually add assets to their wallet.\nIn the first case, wallets are burdened with both the security of managing this list, as well as the bandwidth of mass polling for known assets on their wallet.\nIn the second case, the user experience is terrible.\n\n Specification\n\nThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.\n\nA new RPC method, wallet_watchAsset is added. wallet_watchAsset requests that a specified asset be listed to the user’s wallet. It MUST immediately (i.e. before prompting the user) return true if the request was valid, or error if it was not. The meaning of “listed to the user’s wallet” is dependent on the wallet implementation. A successful call to wallet_watchAsset MUST indicate that the wallet recognized the request and that it contained no issues, but doesn’t indicate whether the user was prompted or whether the asset was actually added to the wallet.\n\n wallet_watchAsset Parameters\n\nThe wallet_watchAsset method takes a single parameter, a WatchAssetParameters object, which is defined as follows:\n\ninterface WatchAssetParameters {\n type: string; // The asset's interface, e.g. 'ERC1046'\n options: any;\n}\n\nThe type string SHOULD be the commonly accepted name of the interface implemented by the asset’s contract, e.g. ERC1046. Defining the global identifiers for different asset types is beyond the scope of this EIP.\n\nThis interface SHOULD be extended or modified depending on the asset type. These changes MUST be specified in separate EIPs.\n\n wallet_watchAsset Returns\n\nwallet_watchAsset immediately (i.e. without waiting for user interaction) returns the boolean value true to indicate that the request was recognized (regardless of whether the user was prompted), or errors if the request is invalid. An error might occur in the following circumstances (not comprehensive):\n\n The asset type is unrecognized/unsupported\n The asset was blocked due to an allowlist or denylist (this makes the request ‘invalid’ since the root cause requires developer action)\n Downloading the image failed to load\n\n The wallet didn’t load some of the metadata required to display the asset, in order to protect against a potential SSRF attack\n\n ERC1046 type\n\nThe format of the options field is:\n\ninterface ERC1046WatchAssetOptions {\n{\n address: string; // The hexadecimal address of the token contract\n chainId?: number; // The chain ID of the asset. If empty, defaults to the current chain ID.\n };\n}\n\naddress is required, and the other fields are optional. address MUST be the 0x-prefixed checksummed hexadecimal address of the token contract. chainId MUST be the chain ID to which the asset belongs.\n\nIf the checksum fails, the request MUST be considered invalid.\n\nIf the wallet does not recognize the chainId, or the chainId is blank and the wallet does not have a concept of “active” chain, the call MUST fail.\n\nwallet_watchAsset MUST fetch the ERC-1046 tokenURI and check the interop field to determine the type of the token. If the parsing fails, or the type is unknown, the RPC call MUST error.\n\nwallet_watchAsset SHOULD check the name and symbol fields, and the contract address and chainId against a list of well-known tokens. If the name and/or symbol are similar to ones on the list but the chainId/address don’t match, a warning SHOULD be presented to the user.\n\nThe wallet SHOULD whitelist and/or blacklist specific ports and schemes to avoid SSRF attacks.\n\n Legacy ERC20 type\n\nThe format of the options field is:\n\ninterface ERC20WatchAssetOptions {\n{\n address: string; // The hexadecimal address of the token contract\n chainId?: number; // The chain ID of the asset. If empty, defaults to the current chain ID.\n };\n}\n\naddress is required, and the other fields are optional. address MUST be the 0x-prefixed checksummed hexadecimal address of the token contract. chainId MUST be the chain ID to which the asset belongs.\n\nIf the checksum fails, the request MUST be considered invalid.\n\nIf the wallet does not recognize the chainId, or the chainId is blank and the wallet does not have a concept of “active” chain, the call MUST fail.\n\nwallet_watchAsset SHOULD check the name and symbol fields, and the contract address and chainId against a list of well-known tokens. If the name and/or symbol are similar to ones on the list but the chainId/address don’t match, a warning SHOULD be presented to the user.\n\nIf possible, it is RECOMMENDED to instead use the ERC1046 type, which supports images and custom metadata.\n\n Rationale\n\nDisplaying a user’s assets is a basic feature that every modern DApp user expects. Most wallets currently either manage their own asset lists, which they store client-side, or they query a centralized API for balances, which reduces decentralization and allows correlating account holders with IP addresses. Additionally, refreshing/polling an asset list from the network can be costly, especially on bandwidth-constrained devices. Also, maintaining an asset list becomes a political act, provoking harassment and inducing pressure to list obscure assets.\n\nAutomatically listing assets makes assets into a sort of spam mail: Users suddenly see new assets that they don’t care about in their wallet. This can be used to send unsolicited information, or even to conduct phishing scams. This phenomenon is already common with airdropped tokens, a major cause of network congestion, because spamming people with new tokens has, so far, been rewarded with increased user attention.\n\nWhen a user is manually adding an asset, they had likely previously learned about it from a website. At that moment, there was a natural alignment of interests, where both parties wanted the user to track the token. This is a natural point to introduce an API to easily allow these parties to collaborate.\n\n Security Considerations\n\n Server-Side Request Forgery\n\nWallets should be careful about making arbitrary requests to URLs. As such, it is recommended for wallets to sanitize the URI by whitelisting specific schemes and ports. A vulnerable wallet could be tricked into, for example, modifying data on a locally-hosted redis database.\n\n Validation\n\nWallets should warn users if the symbol or name matches or is similar to another token, to avoid phishing scams.\n\n Fingerprinting\n\nTo avoid fingerprinting based on wallet behavior and/or listed assets, the RPC call must return as soon as the user is prompted or an error occurs, without waiting for the user to accept or deny the prompt.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Dan Finlay (@danfinlay), Esteban Mino (@estebanmino), Gavin John (@Pandapip1), \"EIP-747: wallet_watchAsset RPC Method,\" Ethereum Improvement Proposals, no. 747, August 2018. Available: https://eips.ethereum.org/EIPS/eip-747.","tokens":1895,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259717374,"hash":"20b945faaed92cb5392a7e4b16808ae895acb2b3"}
{"url":"https://docs.soliditylang.org/en/latest/common-patterns.html","domain":"docs.soliditylang.org","title":"Common Patterns — Solidity 0.8.38-develop documentation","text":"Common Patterns\n\n Edit on GitHub\n\nCommon Patterns\n\nWithdrawal from Contracts\nThe recommended method of sending funds after an effect\nis using the withdrawal pattern. Although the most intuitive\nmethod of sending Ether, as a result of an effect, is a\ndirect transfer call, this is not recommended as it\nintroduces a potential security risk. You may read\nmore about this on the Security Considerations page.\nThe following is an example of the withdrawal pattern in practice in\na contract where the goal is to send the most of some compensation, e.g. Ether, to the\ncontract in order to become the “richest”, inspired by\nKing of the Ether.\nIn the following contract, if you are no longer the richest,\nyou receive the funds of the person who is now the richest.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract WithdrawalContract {\n address public richest;\n uint public mostSent;\n\n mapping(address => uint) pendingWithdrawals;\n\n /// The amount of Ether sent was not higher than\n /// the currently highest amount.\n error NotEnoughEther();\n\n constructor() payable {\n richest = msg.sender;\n mostSent = msg.value;\n }\n\n function becomeRichest() public payable {\n if (msg.value <= mostSent) revert NotEnoughEther();\n pendingWithdrawals[richest] += msg.value;\n richest = msg.sender;\n mostSent = msg.value;\n }\n\n function withdraw() public {\n uint amount = pendingWithdrawals[msg.sender];\n // Remember to zero the pending refund before\n // sending to prevent reentrancy attacks\n pendingWithdrawals[msg.sender] = 0;\n (bool success, ) = payable(msg.sender).call{value: amount}(\"\");\n require(success);\n }\n}\n\nThis is as opposed to the more intuitive sending pattern:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract SendContract {\n address payable public richest;\n uint public mostSent;\n\n /// The amount of Ether sent was not higher than\n /// the currently highest amount.\n error NotEnoughEther();\n\n constructor() payable {\n richest = payable(msg.sender);\n mostSent = msg.value;\n }\n\n function becomeRichest() public payable {\n if (msg.value <= mostSent) revert NotEnoughEther();\n // This line can cause problems (explained below).\n (bool success, ) = richest.call{value: msg.value}(\"\");\n require(success);\n richest = payable(msg.sender);\n mostSent = msg.value;\n }\n}\n\nNotice that, in this example, an attacker could trap the\ncontract into an unusable state by causing richest to be\nthe address of a contract that has a receive or fallback function\nwhich fails (e.g. by using revert() or by just\nconsuming more than the 2300 gas stipend transferred to them). That way,\nwhenever transfer is called to deliver funds to the\n“poisoned” contract, it will fail and thus also becomeRichest\nwill fail, with the contract being stuck forever.\nIn contrast, if you use the “withdraw” pattern from the first example,\nthe attacker can only cause his or her own withdraw to fail and not the\nrest of the contract’s workings.\n\nRestricting Access\nRestricting access is a common pattern for contracts.\nNote that you can never restrict any human or computer\nfrom reading the content of your transactions or\nyour contract’s state. You can make it a bit harder\nby using encryption, but if your contract is supposed\nto read the data, so will everyone else.\nYou can restrict read access to your contract’s state\nby other contracts. That is actually the default\nunless you declare your state variables public.\nFurthermore, you can restrict who can make modifications\nto your contract’s state or call your contract’s\nfunctions and this is what this section is about.\nThe use of function modifiers makes these\nrestrictions highly readable.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract AccessRestriction {\n // These will be assigned at the construction\n // phase, where `msg.sender` is the account\n // creating this contract.\n address public owner = msg.sender;\n uint public creationTime = block.timestamp;\n\n // Now follows a list of errors that\n // this contract can generate together\n // with a textual explanation in special\n // comments.\n\n /// Sender not authorized for this\n /// operation.\n error Unauthorized();\n\n /// Function called too early.\n error TooEarly();\n\n /// Not enough Ether sent with function call.\n error NotEnoughEther();\n\n // Modifiers can be used to change\n // the body of a function.\n // If this modifier is used, it will\n // prepend a check that only passes\n // if the function is called from\n // a certain address.\n modifier onlyBy(address account)\n {\n if (msg.sender != account)\n revert Unauthorized();\n // Do not forget the \"_;\"! It will\n // be replaced by the actual function\n // body when the modifier is used.\n _;\n }\n\n /// Make `newOwner` the new owner of this\n /// contract.\n function changeOwner(address newOwner)\n public\n onlyBy(owner)\n {\n owner = newOwner;\n }\n\n modifier onlyAfter(uint time) {\n if (block.timestamp < time)\n revert TooEarly();\n _;\n }\n\n /// Erase ownership information.\n /// May only be called 6 weeks after\n /// the contract has been created.\n function disown()\n public\n onlyBy(owner)\n onlyAfter(creationTime + 6 weeks)\n {\n delete owner;\n }\n\n // This modifier requires a certain\n // fee being associated with a function call.\n // If the caller sent too much, he or she is\n // refunded, but only after the function body.\n // This was dangerous before Solidity version 0.4.0,\n // where it was possible to skip the part after `_;`.\n modifier costs(uint amount) {\n if (msg.value < amount)\n revert NotEnoughEther();\n\n _;\n if (msg.value > amount) {\n (bool success, ) = payable(msg.sender).call{value: msg.value - amount}(\"\");\n require(success);\n }\n }\n\n function forceOwnerChange(address newOwner)\n public\n payable\n costs(200 ether)\n {\n owner = newOwner;\n // just some example condition\n if (uint160(owner) & 0 == 1)\n // This did not refund for Solidity\n // before version 0.4.0.\n return;\n // refund overpaid fees\n }\n}\n\nA more specialised way in which access to function\ncalls can be restricted will be discussed\nin the next example.\n\nState Machine\nContracts often act as a state machine, which means\nthat they have certain stages in which they behave\ndifferently or in which different functions can\nbe called. A function call often ends a stage\nand transitions the contract into the next stage\n(especially if the contract models interaction).\nIt is also common that some stages are automatically\nreached at a certain point in time.\nAn example for this is a blind auction contract which\nstarts in the stage “accepting blinded bids”, then\ntransitions to “revealing bids” which is ended by\n“determine auction outcome”.\nFunction modifiers can be used in this situation\nto model the states and guard against\nincorrect usage of the contract.\n\nExample\nIn the following example,\nthe modifier atStage ensures that the function can\nonly be called at a certain stage.\nAutomatic timed transitions\nare handled by the modifier timedTransitions, which\nshould be used for all functions.\n\nNote\nModifier Order Matters.\nIf atStage is combined\nwith timedTransitions, make sure that you mention\nit after the latter, so that the new stage is\ntaken into account.\n\nFinally, the modifier transitionNext can be used\nto automatically go to the next stage when the\nfunction finishes.\n\nNote\nModifier May be Skipped.\nThis only applies to Solidity before version 0.4.0:\nSince modifiers are applied by simply replacing\ncode and not by using a function call,\nthe code in the transitionNext modifier\ncan be skipped if the function itself uses\nreturn. If you want to do that, make sure\nto call nextStage manually from those functions.\nStarting with version 0.4.0, modifier code\nwill run even if the function explicitly returns.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract StateMachine {\n enum Stages {\n AcceptingBlindedBids,\n RevealBids,\n AnotherStage,\n AreWeDoneYet,\n Finished\n }\n /// Function cannot be called at this time.\n error FunctionInvalidAtThisStage();\n\n // This is the current stage.\n Stages public stage = Stages.AcceptingBlindedBids;\n\n uint public creationTime = block.timestamp;\n\n modifier atStage(Stages stage_) {\n if (stage != stage_)\n revert FunctionInvalidAtThisStage();\n _;\n }\n\n function nextStage() internal {\n stage = Stages(uint(stage) + 1);\n }\n\n // Perform timed transitions. Be sure to mention\n // this modifier first, otherwise the guards\n // will not take the new stage into account.\n modifier timedTransitions() {\n if (stage == Stages.AcceptingBlindedBids &&\n block.timestamp >= creationTime + 10 days)\n nextStage();\n if (stage == Stages.RevealBids &&\n block.timestamp >= creationTime + 12 days)\n nextStage();\n // The other stages transition by transaction\n _;\n }\n\n // Order of the modifiers matters here!\n function bid()\n public\n payable\n timedTransitions\n atStage(Stages.AcceptingBlindedBids)\n {\n // We will not implement that here\n }\n\n function reveal()\n public\n timedTransitions\n atStage(Stages.RevealBids)\n {\n }\n\n // This modifier goes to the next stage\n // after the function is done.\n modifier transitionNext()\n {\n _;\n nextStage();\n }\n\n function g()\n public\n timedTransitions\n atStage(Stages.AnotherStage)\n transitionNext\n {\n }\n\n function h()\n public\n timedTransitions\n atStage(Stages.AreWeDoneYet)\n transitionNext\n {\n }\n\n function i()\n public\n timedTransitions\n atStage(Stages.Finished)\n {\n }\n}","tokens":2337,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259717865,"hash":"cc7c8d00a4baf2f3b20d6e427060aa81ba52d020"}
{"url":"https://ethresear.ch/t/failure-modes-in-eip-8037-and-state-gas-scaling/23975/2","domain":"ethresear.ch","title":"Failure modes in EIP-8037 and state-gas scaling - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 29\n\n 2 / 2\n\n Feb 3\n\n Feb 4\n\n post by aelowsson on Jan 29\n\n aelowsson\n\n This note reviews the two equilibrium failure modes that arise in EIP-8037 when users do not wish to spend 50% of their budget on state creation, and presents the corrective state gas scaling measures that then can be deployed. In the extreme, if users continue creating as many state bytes per consumed regular gas unit as they do today and Ethereum scales the gas limit by 10x, then around 6.2% of the regular blockspace will be utilized under equilibrium. This would forfeit a great part of the scaling gains achieved via ePBS and BALs. Two direct adjustments can be made if it turns out that demand does not produce a 50/50 spending distribution: (1) adopt the EIP-8075 pricing that automatically expands and contracts the state gas limit; or (2) manually expand/contract the state gas limit, either in a regular hard fork or in a “state-gas parameter only” (SGPO) hardfork.\nFailure modes\nEthereum is focused on scaling the layer 1, with headliners EIP-7732 (ePBS) and EIP-7928 (BALs) scheduled for inclusion in Glamsterdam. If the gas cost for state creation is not adjusted, state would likely grow roughly in line with an expanding gas limit. Therefore, EIP-8037 raises the gas cost for state creation substantially. A concern (1, 2, 3) associated with this change is that the proportion of the total gas that is spent on state creation may rise, thus crowding out regular gas. For example, assume that ePBS and BALs together with compute repricings allow for a 600M gas limit, a midpoint of the numbers discussed here. With the current EIP-8037 specification that relies on the EIP-8011 metering rule, if users are not sensitive to the state gas cost increase and create as much state relative to consumed regular gas as they do today, then only around 6.2% of the regular blockspace would be utilized under equilibrium. The scaling gains from ePBS, BALs and compute repricings would then largely be lost.\nOf course, we may hope that users create fewer state bytes per regular gas unit when the cost of state creation increases, but the price-elasticity of demand for state creation is unknown and seems impossible to predict in a reliable manner. Should users start consuming for example half as many state bytes per regular gas unit as today, then the situation improves somewhat, and 12.3% of the block gas limit can be utilized. The ideal scenario is if users consume 8.1 times fewer state bytes per regular gas unit than today. In this case, both state gas and regular gas can be utilized at a 50/50 capacity (or realistically, perhaps closer to 40/40, if the EIP-8011 pricing uses the max operator). Should relative consumption of state creation fall more than that, then an opposite effect takes place, and users are creating less than the desired 100 GiB of state per year.\nFigure 1 outlines the two equilibrium failure modes that are possible under EIP-8011 pricing: too few state bytes created, or too little regular gas consumed. The current design works optimally if users are willing to spend 50% of their budget on regular gas and 50% of their budget on state gas, regardless of the relative prices between the two. If this is not the case, one side will crowd out the other under equilibrium.\nFigure 11442×1178 84.4 KB\nFigure 1. The two failure modes of the EIP-8011 pricing mechanism applied in EIP-8037. If demand for state creation is relatively lower than what researchers predicted, too little state is created under equilibrium (its price is too high to match demand). If demand for state creation is relatively higher than what researchers predicted, too little regular gas is consumed under equilibrium (its price is too high to match demand).\nAverting failure\nThe deeper issue is that the EIP-8011 pricing mechanism does not track state creation over time (or more generally speaking, any value that reflects the balance in demand between state and non-state operations). It therefore cannot adjust the state gas cost such that both the state resource and regular resource are at target demand. We may end up with either state or all other resources significantly underutilized under equilibrium. There are two options to alleviate this:\n\nto track state creation over time using a header variable and automatically adjust the balance between state gas and regular gas, as proposed in EIP-8075; or\nto manually readjust the balance between state gas and regular gas after observing a lopsided distribution, potentially using state-gas (or state-growth) parameter only hardforks.\n\n(1) Averting failure modes via EIP-8075\nApplying the EIP-8075 pricing mechanism for EIP-8037 resolves the issue in a principled manner. Under EIP-8075, state creation has a variable gas cost that adapts with demand such that the desired number of state bytes are created over time. The state gas target and limit expands and contracts automatically with the gas cost (since the pricing mechanism operates over state bytes). The metered gas is computed as the average of the regular gas and a normalized measure of state gas. This allows regular gas to be consumed at its targeted level over time, while the protocol also guarantees that a target number of state bytes are created.\nFigure 22002×1178 171 KB\nFigure 2. EIP-8075 automatically adjusts the gas cost with demand to ensure a target creation of state bytes in the long run. To achieve this, the EIP expands and contracts the gas target and limit while adapting the gas cost such that a target number of state bytes are consumed.\n(2) Averting failure modes manually in regular/SGPO hardforks\nThe second option is to mirror the idea of EIP-8075, but to make the adjustments manually. The state gas target and limit can in this case ideally be allowed to expand and contract as in EIP-8075 (Figure 2), such that the metering equation remains responsive to both regular and state gas. If implemented as a SGPO hardfork, a stateSchedule can be introduced and initiated as:\n{\n \"stateSchedule\": {\n \"gloas\": {\n \"target\": 107374182400,\n \"scale\": 100\n }\n },\n \"gloasTime\": \"TBD\"\n}\n\nThe scale parameter allows the state gas limit to be expanded or contracted relative to the block gas limit, and the target parameter sets the yearly state growth under full utilization. The state_gas_limit is computed as state_gas_limit = gas_limit * stateSchedule.scale // 100, and the cost_per_state_byte computed by replacing gas_limit with state_gas_limit in the following expression:\ncost_per_state_byte = state_gas_limit * 7200 * 365 // (stateSchedule.target * 2)\n\nWhen the metering function F finally is applied (where F could be max or any other function discussed here), it is just as in EIP-8075 applied to a normalized measure of state gas: F(regular_gas, state_gas * 100 // stateSchedule.scale). Since the demand-elasticity is unknown, a single manual correction may not hit the mark perfectly. It therefore seems reasonable to overshoot a little if too little regular gas is consumed under equilibrium, to retain scaling. It is also possible to “overshoot” more generally by targeting a higher proportion of state gas relative to the limit than 0.5, as outlined here.\nNote that the scale parameter would be the key rationale for adding SGPO hardforks. Without the scale parameter, Ethereum risks entering Failure mode 2 in Figure 1, foregoing some proportion of the scaling gains of ePBS and BALs. The ability to also adjust the target growth is welcome, but would not in isolation warrant the implementation complexity. In other words, both the target and scale could be set and adjusted in a regular hardfork, but only the lack of a scale parameter may warrant SGPO hardforks.\nStylized equilibrium\nThe equilibrium outcome under EIP-8011 pricing in EIP-8037 can be rudimentarily analyzed by focusing on relative demand elasticities between the two resources (as here and here, with a general write-up on demand elasticities also available here).\nThere is a fixed gas cost and both resources have the same base fee. Initially, before implementing EIP-8037, 70% of all gas is spent on operations that will be charged under regular gas, G_1=0.7𝐺1 =0.7 and 30% of the gas is spent on state creation, G_2 = 0.3𝐺2 =0.3. If demand becomes balanced between regular and state gas under the fixed gas cost that EIP-8037 specifies at any given gas limit, such that users spend an equal amount of gas on both, the mechanism will work perfectly as intended. The ratio r𝑟 of the gas spent on the two resources is then 1:\n\nr = \\frac{G'_1}{G'_2} = 1.\n𝑟=𝐺′1𝐺′2=1.\nLet the gas cost of state creation increase by a factor p𝑝 and let d𝑑 represent how many times fewer state bytes users are willing to create per consumed regular gas unit, under the given cost increase. The new ratio between consumed regular and state gas is then:\n\nr = \\frac{G_1}{G_2(p/d)} = \\frac{G_1 d}{G_2 p}.\n𝑟=𝐺1𝐺2(𝑝/𝑑)=𝐺1𝑑𝐺2𝑝.\nUnder equilibrium when using the max function (as in EIP-8037) and ignoring how block variability pushes down the equilibrium proportions, the metered dimension (the larger of regular and state gas) will sit at the target. Users will then consume regular gas at a proportion of G^*_1 = \\min(0.5, 0.5r)𝐺∗1 =min(0.5,0.5𝑟) of the gas limit, and state gas at a proportion of G^*_2 = \\min(0.5, 0.5/r)𝐺∗2 =min(0.5,0.5/𝑟).\nThe baseline EIP-8037 cost increase at 60M gas is 1.17x for storage slots, 3.29x for accounts, and 3.67x for code. A weighted average gas cost increase across these three metrics based on current growth trajectories (storage snapshot, account snapshot, contract codes) between block 17,165,429 and block 21,000,000 is around 1.89x. Uncertainty in the current weighted average is duly acknowledged.\nInvestigating a 10x scaling facilitated by BALs, ePBS and repricing, the weighted average gas cost increase would with the EIP-8037 specification be 18.9x. Thus, setting p=18.9𝑝 =18.9 and assuming that users do not change their current usage pattern (d=1𝑑 =1), the ratio becomes\n\nr=0.7/(0.3 \\times 18.9)=0.123.\n𝑟=0.7/(0.3×18.9)=0.123.\nUsers will then only consume regular gas at a proportion of\n\nG^*_1 = 0.5 \\times 0.123 = 0.062\n𝐺∗1=0.5×0.123=0.062\nof the gas limit under equilibrium. If users halve their state creation per regular gas unit, then the equilibrium becomes G^*_1 = 0.123𝐺∗1 =0.123. The optimum reduction in state byte consumption per regular gas unit is obtained by restoring balance (r=1𝑟 =1), which implies:\n\nd^* = \\frac{G_2p}{G_1} = \\frac{0.3\\cdot 18.9}{0.7} = 8.1.\n𝑑∗=𝐺2𝑝𝐺1=0.3⋅18.90.7=8.1.\nLooking ahead\nAs Ethereum continues to scale, the difficulty in predicting the state gas cost that balances gas expenditures increases, as does the severity of the worst failure modes. As an example, at a 30x L1 scaling, only 2.1% of the blockspace for regular gas is utilized under equilibrium, if users do not change state byte creation per regular gas usage (but the high gas cost should at this point incentivize users to make rather substantial adjustments to how much state they create). By the point a 30x scaling is reached, a more comprehensive solution to the problem will ideally have been deployed. Such a solution consists of a full multidimensional fee market as in EIP-7999, and engineering efforts to better handle state growth (potentially expiring some part of the state).\n\n Analysis of different aggregation functions for EIP-8037 under different elasticity regimes\n\n How Hegotá can influence the state roadmap\n\n Designs for EVM gas accounting in EIP-7999\n\n How Hegotá should approach gas repricing\n\n read \n\n 5\n min\n\n post by aelowsson on Feb 4\n\n aelowsson\n\n There is also the option to have the state-gas scaling that can be applied in a SGPO hardfork instead “trigger” automatically upon observing a lopsided distribution. This requires tracking gas consumption in header variable(s). It is a very unprincipled way of achieving the properties of EIP-8075, but it does achieve them. The mechanism could be deployed in two ways:\n\nAt regular intervals (e.g., monthly), we rescale state gas as previously outlined, according to tracked gas consumption.\nIn the case that the gas consumption distribution has diverged from our predicted acceptable range, the state-scaling triggers with a one-time change to bring back a desirable distribution.\n\nPersonally, I would think that if we decide to track gas consumption in the header, we should go for the more principled price-setting solution of EIP-8075. However, I flag this as an (unprincipled/ugly) option that is available to us, while not recommending it.\n\n Powered by Discourse","tokens":3175,"squid":"ink-research","role":"Deep Scholar","at":1791259720929,"hash":"7f446a4cb6cf89dff6648fb5df10bcbcddb4efd1"}
{"url":"https://eips.ethereum.org/","domain":"eips.ethereum.org","title":"Home | Ethereum Improvement Proposals","text":"EIPs\n\nEthereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Ethereum Project Management repository.\n\nContributing\nFirst review EIP-1. Then clone the repository and add your EIP to it. There is a template EIP here. Then submit a Pull Request to Ethereum's EIPs repository.\n\nEIP status terms\n\n Idea - An idea that is pre-draft. This is not tracked within the EIP Repository.\n Draft - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.\n Review - An EIP Author marks an EIP as ready for and requesting Peer Review.\n Last Call - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.\n Final - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.\n Stagnant - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.\n Withdrawn - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.\n Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.\n\nEIP Types\n\nEIPs are separated into a number of types, and each has its own list of EIPs.\n\nStandards Track (1143)\nDescribes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.\n\nCore (438)\nImprovements requiring a consensus fork (e.g. EIP-5, EIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in EIP-225).\n\nNetworking (30)\nIncludes improvements around devp2p (EIP-8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.\n\nInterface (59)\nIncludes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP-6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.\n\nERC (616)\nApplication-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes (EIP-681), library/package formats (EIP-190), and account abstraction (EIP-4337).\n\nMeta (43)\nDescribes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.\n\nInformational (23)\nDescribes a Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.","tokens":1067,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259727063,"hash":"9b1b91f47a22737d7105cc2706e2b9c9ba7d06c1"}
{"url":"https://ethresear.ch/c/execution-layer-research/37/l/top","domain":"ethresear.ch","title":"Top Execution Layer Research topics - Ethereum Research","text":"Top topics in Execution Layer Research\n\n Execution Layer Research\n\n tags\n\n Latest\n\n Top\n\n All time\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n How to hard-fork to save most users’ funds in a quantum emergency\n\n 38\n\n 26.5k\n\n Mar 2025\n\n ReGenesis - resetting Ethereum to reduce the burden of large blockchain and state\n\n 27\n\n 13.3k\n\n Jan 2021\n\n Torrents and EIP-4444\n\n 20\n\n 6.7k\n\n Oct 2024\n\n Shutterized Beacon Chain\n\n mev\n\n 27\n\n 16.3k\n\n Jun 2025\n\n Proprietary AMMs and Ethereum\n\n mev\n\n 13\n\n 1.3k\n\n 12d\n\n Resurrection-conflict-minimized state bounding, take 2\n\n 17\n\n 8.8k\n\n Jun 2021\n\n Native UTXOs on Ethereum\n\n stateless,utxo\n\n 30\n\n 4.4k\n\n 28d\n\n Block-Level Warming\n\n 10\n\n 1.1k\n\n Mar 2025\n\n Delayed Execution And Skipped Transactions\n\n 26\n\n 2.2k\n\n May 2025\n\n Self-Sovereign Identity and Account Abstraction for Privacy-Preserving cross chain user operations across roll ups\n\n zk-roll-up,account-abstraction,transaction-privacy,signature-aggregation,sequencing\n\n 14\n\n 7.4k\n\n Oct 2024\n\n Binary trie format\n\n 43\n\n 70.9k\n\n Nov 2020\n\n The curious case of BLOCKHASH and Stateless Ethereum\n\n stateless\n\n 11\n\n 5.9k\n\n Sep 2022\n\n A brief note on the future of accounts\n\n account-abstraction\n\n 11\n\n 7.8k\n\n May 2022\n\n Frame Transactions Through a Statelessness Lens\n\n stateless\n\n 11\n\n 733\n\n Apr 15\n\n Block-level Access Lists (BALs)\n\n scaling\n\n 13\n\n 2.1k\n\n Oct 2025\n\n A pragmatic path towards Validity-Only Partial Statelessness (VOPS)\n\n stateless\n\n 14\n\n 2.1k\n\n Jun 2025\n\n The Data Availability Problem under Stateless Ethereum\n\n stateless,data-availability\n\n 18\n\n 8.0k\n\n Mar 2020\n\n Overlay method for hex -> bin tree conversion\n\n 13\n\n 7.3k\n\n Jun 2020\n\n Who’s working on what?\n\n 12\n\n 3.3k\n\n May 2020\n\n Terminology: What do we call “witness” in “Stateless Ethereum” and why it is appropriate\n\n stateless\n\n 11\n\n 3.1k\n\n Jun 2020\n\n Simpler Ethereum sync: Major/minor state snapshots, blockchain files, receipt files\n\n 17\n\n 7.5k\n\n Jul 2020\n\n On Increasing the Block Gas Limit: Technical Considerations & Path Forward\n\n 7\n\n 2.6k\n\n Dec 2024\n\n State of block header sync in light clients\n\n 12\n\n 5.5k\n\n Dec 2020\n\n A practical proposal for Multidimensional Gas Metering\n\n 20\n\n 1.5k\n\n Aug 2025\n\n How high can the gas limit be increased?\n\n 14\n\n 5.5k\n\n Mar 2021\n\n Oil: adding a second fuel source to the EVM (pre-EIP)\n\n 18\n\n 4.8k\n\n May 2020\n\n A Third Way: Coordinating the gas limit\n\n 9\n\n 5.9k\n\n May 2021\n\n Meta transactions, Oil, and Karma megathread\n\n 23\n\n 5.8k\n\n Jun 2020\n\n The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\n\n stateless\n\n 10\n\n 783\n\n 4d\n\n Counter-proposal to oil/karma: per-account gas limits\n\n 13\n\n 3.5k\n\n May 2020\n\n Introductions for the Eth1.x research group\n\n 26\n\n 6.7k\n\n Jan 2020\n\n Alternative bounded-state-friendly address scheme\n\n 12\n\n 4.0k\n\n Feb 2021\n\n Trustless access to Ethereum State with Swarm\n\n data-availability\n\n 15\n\n 3.2k\n\n Dec 2023\n\n Mempool Account Transaction Capacity from Historical Activity (MATCHA)\n\n account-abstraction,transaction-privacy\n\n 11\n\n 541\n\n 19h\n\n State Network DHT - Development Update #2\n\n 12\n\n 4.5k\n\n Apr 2021\n\n The Great Alaskan Transaction Pipeline\n\n stateless\n\n 16\n\n 3.9k\n\n Jan 2021\n\n Telegram group for Eth1x Stateless Client\n\n 28\n\n 4.7k\n\n Mar 2020\n\n Specification for the Unchained Index Version 2.0 - Feedback welcome\n\n 30\n\n 3.2k\n\n Nov 2023\n\n Prover Killers Killer: You Build it, You Prove it\n\n delayed-execution\n\n 7\n\n 1.7k\n\n Jul 2025\n\n Bayesian network model of Witness Creation - Feedback request\n\n stateless\n\n 3\n\n 3.8k\n\n Apr 2021\n\n An updated roadmap for Stateless Ethereum\n\n 5\n\n 5.2k\n\n Jun 2021\n\n Analyzing EIP-7623: Increase Calldata Cost\n\n 2\n\n 3.5k\n\n Mar 2024\n\n DoS Vectors in Account Abstraction (AA) or Validation Generalization, a Case Study in Geth\n\n account-abstraction\n\n 0\n\n 8.2k\n\n Sep 2020\n\n Parallelilizing EVM through end-of-the-block virtual transactions\n\n 4\n\n 4.5k\n\n Feb 2021\n\n Sharding state with Discovery and Adaptive Range Filter ads\n\n stateless\n\n 1\n\n 2.1k\n\n Jul 2020\n\n Distributed storage and cryptographically secured retrieval of SSZ objects for Portal Network\n\n portal-network,ssz\n\n 1\n\n 3.1k\n\n May 2024\n\n Using The Graph to Preserve Historical Data and Enable EIP-4444\n\n 0\n\n 4.1k\n\n Nov 2023\n\n EVM Native Sequencing Rules\n\n mev\n\n 8\n\n 6.1k\n\n May 2024\n\n Native Meta-Transaction Proposal Roundup\n\n 6\n\n 3.4k\n\n Jun 2020\n\n L1 improvement based on Minus Theory\n\n 4\n\n 879\n\n Jan 2025","tokens":1101,"squid":"ink-research","role":"Deep Scholar","at":1791259734161,"hash":"801f4224be38917dbfa82eab824863b42ab3cbc9"}
{"url":"https://docs.soliditylang.org/en/v0.8.37/structure-of-a-contract.html","domain":"docs.soliditylang.org","title":"Structure of a Contract — Solidity 0.8.37-develop documentation","text":"Structure of a Contract\n\n Edit on GitHub\n\nStructure of a Contract\nContracts in Solidity are similar to classes in object-oriented languages.\nEach contract can contain declarations of State Variables, Functions,\nFunction Modifiers, Events, Errors, Struct Types and Enum Types.\nFurthermore, contracts can inherit from other contracts.\nThere are also special kinds of contracts called libraries and interfaces.\nThe section about contracts contains more details than this section,\nwhich serves to provide a quick overview.\n\nState Variables\nState variables are variables whose values are either permanently stored in contract\nstorage or, alternatively, temporarily stored in transient storage which is cleaned at\nthe end of each transaction.\nSee data locations for more details.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract SimpleStorage {\n uint storedData; // State variable\n // ...\n}\n\nSee the Types section for valid state variable types and\nVisibility and Getters for possible choices for\nvisibility.\n\nFunctions\nFunctions are the executable units of code. Functions are usually\ndefined inside a contract, but they can also be defined outside of\ncontracts.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.1 <0.9.0;\n\ncontract SimpleAuction {\n function bid() public payable { // Function\n // ...\n }\n}\n\n// Helper function defined outside of a contract\nfunction helper(uint x) pure returns (uint) {\n return x * 2;\n}\n\nFunction Calls can happen internally or externally\nand have different levels of visibility\ntowards other contracts. Functions accept parameters and return variables to pass parameters\nand values between them.\n\nFunction Modifiers\nFunction modifiers can be used to amend the semantics of functions in a declarative way\n(see Function Modifiers in the contracts section).\nOverloading, that is, having the same modifier name with different parameters,\nis not possible.\nLike functions, modifiers can be overridden.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.22 <0.9.0;\n\ncontract Purchase {\n address public seller;\n\n modifier onlySeller() { // Modifier\n require(\n msg.sender == seller,\n \"Only seller can call this.\"\n );\n _;\n }\n\n function abort() public view onlySeller { // Modifier usage\n // ...\n }\n}\n\nEvents\nEvents are convenience interfaces with the EVM logging facilities.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.22;\n\nevent HighestBidIncreased(address bidder, uint amount); // Event\n\ncontract SimpleAuction {\n function bid() public payable {\n // ...\n emit HighestBidIncreased(msg.sender, msg.value); // Triggering event\n }\n}\n\nSee Events in contracts section for information on how events are declared\nand can be used from within a dapp.\n\nErrors\nErrors allow you to define descriptive names and data for failure situations.\nErrors can be used in revert statements.\nIn comparison to string descriptions, errors are much cheaper and allow you\nto encode additional data. You can use NatSpec to describe the error to\nthe user.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\n/// Not enough funds for transfer. Requested `requested`,\n/// but only `available` available.\nerror NotEnoughFunds(uint requested, uint available);\n\ncontract Token {\n mapping(address => uint) balances;\n function transfer(address to, uint amount) public {\n uint balance = balances[msg.sender];\n if (balance < amount)\n revert NotEnoughFunds(amount, balance);\n balances[msg.sender] -= amount;\n balances[to] += amount;\n // ...\n }\n}\n\nSee Custom Errors in the contracts section for more information.\n\nStruct Types\nStructs are custom defined types that can group several variables (see\nStructs in types section).\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract Ballot {\n struct Voter { // Struct\n uint weight;\n bool voted;\n address delegate;\n uint vote;\n }\n}\n\nEnum Types\nEnums can be used to create custom types with a finite set of ‘constant values’ (see\nEnums in types section).\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract Purchase {\n enum State { Created, Locked, Inactive } // Enum\n}","tokens":1054,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259744279,"hash":"15627af517979a9c91aa9f1ed13debbf448a206d"}
{"url":"https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677","domain":"ethresear.ch","title":"Delayed Execution And Skipped Transactions - Execution Layer Research - Ethereum Research","text":"Delayed Execution And Skipped Transactions \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2025\n\n 1 / 27\n\n Feb 2025\n\n May 2025\n\n post by Nero_eth on Feb 5, 2025\n\n Nero_eth\n\n Delayed Execution And Skipped Transactions\nMany thanks to Francesco for feedback, review an collaboration on this!\nEthereum requires every block to be fully executed before it’s considered valid. Each block header commits to a set of execution outputs—like the new state root, receipts, and logs—that result from processing every transaction within that block. This tight coupling means that validators must run every transaction as soon as they see a new block, making execution an inherent part of the critical path.\nA proposed solution, known as Delayed Execution (spec’ed by Francesco, here), offers an elegant approach by decoupling block validation from immediate transaction execution. In this post, I’ll go through how this mechanism works and what it could mean for scaling.\n\nAlso, check out Francesco’s post on delayed execution that explores another potential approach besides the one described in this post.\n\nBlockchain 1x1\nIn Ethereum, each block links to its predecessor by including a cryptographic commitment not only to the previous block’s header but also to the state resulting from all transactions in that block.\nHere’s what happens:\n\nExecution-Dependent Headers: The block header contains fields such as state_root, receipt_root, and logs bloom. These fields are generated only after the transactions have been executed.\nFull Execution: Every validator, upon receiving a new block, must execute all transactions to verify that the header’s commitments are correct. This ensures the block is consistent with the current state but forces nodes to do potentially heavy computation immediately.\n\nstate transition now1241×431 25.1 KB\nThe Concept of Delayed Execution\nDelayed Execution challenges this paradigm by splitting the block processing into two distinct stages:\n\nStatic Validation (Pre-Execution): Validators perform minimal checks using only the previous state. Instead of committing to a freshly computed state_root and related fields, the block header defers these execution outputs by referencing values from the parent block.\nPost-Attestation Execution: The actual execution of transactions is delayed until after the block is initially validated and attested to by the network.\n\nThis decoupling means that validators can quickly agree on the block’s validity without having to execute every transaction upfront. In essence, the block is “chained” to its predecessor using minimal data that does not require full execution.\nstate transition with delayed execution1142×350 24.6 KB\nInstead of fully executing the block before attesting, we can already attest to the block as soon as minimal static validation is done. This relieves stress from the critical path. The following is a simplified illustration of the efficiency gains. It compares the current situation (top) with delayed execution (bottom):\novertime1250×739 162 KB\nThe following graph has a (incomplete) list of things we do during a state transition. Only the initial, static validation phase (which relies solely on the previous state) needs to be executed immediately, while the more complex, state-changing operations can be safely deferred until after attestation.\nstate transition function840×690 105 KB\nIn theory, this change could boost efficiency by as much as 8x, assuming blocks arrive at second 3 of the slot, the attestation deadline stays at second 4, and the worst-case execution time is 1 second (based on the 99.9999th percentile). Special thanks to Marek, Ben, and Łukasz for providing this figure.\nThat said, take this estimate with a grain of salt—you might more realistically expect around a 5x improvement.\nThe Role of Skipped Transactions\nA novel concept in the delayed execution mechanism is the allowance for skipped transactions. Under the current protocol, a single invalid or underfunded transaction can invalidate an entire block. Delayed execution introduces a more resilient approach:\n\nInclusion Without Execution: Transactions are still included in the block’s transaction list but might be marked as “skipped” during execution if they fail certain conditions (e.g., insufficient funds, underpricing, incorrect nonce, or other execution-dependent checks).\nUpfront Fee Payment by Coinbase: To protect the network against the cost of including these transactions, the block proposer’s account (known as the COINBASE) pays an upfront “inclusion cost.” This cost covers basic expenses like the base transaction cost and calldata fees.\nNetwork Compensation: Even if a transaction is skipped, the network is compensated because the inclusion cost has been pre-paid by the COINBASE. This mechanism eliminates the risk of having transactions that consume resources without paying.\n\ndelayed execution flow1181×331 20.9 KB\nBy allowing invalid transactions to be skipped without invalidating the whole block, the proposal shifts the burden of heavy execution away from the immediate validation process. Similar to EIP-7732 (ePBS), we relieve the critical path from the heavy load of execution and state root validation.\nThe Role of COINBASE and Direct Sponsorship (optional)\nDelayed execution could create new opportunities for direct sponsorship. Since the coinbase already covers the inclusion cost upfront, it might be reasonable to extend this responsibility to the base fee as well.\nHere’s how it works:\n\nCOINBASE’s Signature Commitment: The block header comes with a signature from the COINBASE address. This signature is a commitment that the COINBASE is responsible for paying all inclusion costs upfront. In effect, the COINBASE sponsors the execution of transactions that might otherwise be underfunded (=not able to pay for the basefee).\nFlexible Fee Models: With the COINBASE on the hook for initial fees, the protocol can allow transactions that don’t strictly meet the minimum fee requirements. This opens the door to new possibilities such as gasless or sponsored transactions, where the sender might not have enough ETH to pay upfront but is later reimbursed—or the COINBASE recoups the cost—once execution is successful.\n\nDelayed execution and block-level base fee mechanisms are separate topics that should be addressed independently. However, the COINBASE’s commitment to covering the inclusion cost could be extended to also committing to sponsoring the base fee.\nFor additional details on why block-level markets have the potential to contribute to more efficient resource allocation, check out Barnabé’s post on Block-level Markets.\nUnder The Hood\nUnder delayed execution, the way blocks are chained together undergoes a small transformation:\n\nDeferred Execution Outputs: Header fields such as the state_root, receipt_root, and logs bloom are deferred. Instead of reflecting the immediate execution of the block, these fields hold values from the parent block. This means that the block’s validity can be confirmed without performing all of its computational work. Invalid transactions can be included in blocks.\nInclusion Cost Calculation: For every transaction, an inclusion cost is computed that typically includes a base cost (e.g., 21,000 gas), calldata fees, and any blob gas fees. This cost is deducted from the COINBASE’s balance before the transactions are executed. If the transaction is skipped, the COINBASE loses the inclusion cost fronted for the transaction. If the transaction executes successfully, the inclusion cost fronted by the COINBASE is refunded by the sender of the transaction.\nTwo-Phase Validation: The validation process is split into an initial static check—ensuring that the block is structurally sound and that the COINBASE can cover inclusion costs—and a later execution phase, where transactions are processed or skipped as appropriate.\n\nThis design relieves the critical path of execution, allowing blocks to be validated and attested more quickly. It ultimately results in a more scalable and flexible protocol, as the heavy lifting of transaction execution can be handled asynchronously relative to block attestation.\nAdvantages and Trade-Offs\nAdvantages:\n\nIncreased Throughput: By taking transaction execution out of the immediate validation path, blocks can be attested to more rapidly.\nEnhanced Flexibility: The model simplifies introducing new fee mechanisms, such as sponsored and gasless transactions, which can make Ethereum more accessible to users.\n\nTrade-Offs:\n\nLiquidity Requirements for Proposer/Builder: The COINBASE address must be sufficiently funded to cover the maximum possible inclusion costs for a block, which may introduce liquidity constraints, especially during periods of high base fee conditions. The maximum inclusion fee equals gas_limit * base_fee, so, with a base_fee of 100 GWEI, we’re at 3 ETH.\nProtocol Complexity: Introducing delayed execution involves substantial changes to Ethereum’s execution layer. However, unlike other delayed execution proposals, this approach avoids modifying the fork-choice function, which keeps the complexity lower. For a closer look at what these changes entail—especially if you’re interested in adding base fee sponsoring—check out the flow chart in the appendix and the EELS specs here.\n\nAppendix\nFor flowchart enthusiasts, here is how the described mechanism is currently spec’ed; this includes the block-basefee feature and skipped transactions, going through the EELS implementation here:\nflow chart of complete flow with skipped transactions adn sponsoring891×3640 285 KB\n^find the uncompressed version of this diagram here.\n\n Delayed Execution and Free DA\n\n Decoupling throughput from local building\n\n 11\n\n 6\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n post by thegaram33 on Feb 5, 2025\n\n thegaram33\n\n Excellent writeup!\nWhile it’s not shown on the “State Transition” figure, I assume the Static Validation steps would also include:\n\nCheck execution results of parent block (header.pre_state_root, etc.)\nBlock and transaction decoding (we at least need to make sure that the block is well-formed).\n\n post by g11in on Feb 5, 2025\n\n g11in\n\n we will also need to include execution requests in the deffer-ed outputs\nessentially CL can’t use/attest to any outputs from the current payload txs since the actual EL execution might not agree with it. This implies now the requests CL will include/apply in its block will be of parent’s\n\n post by terence on Feb 5, 2025\n\n terence\n\n Expected withdrawals from CL to EL as well\n\n post by GregTheGreek on Feb 5, 2025\n\n GregTheGreek\n\n I love this, something I’ve been thinking about with Mark lately is whether it even matters to have any failed or “skipped” txs in the blocks at all.\nAn initial thought was to chuck the failed ones into a blob or a special tx that sits at the 0th index of every block. Rational is its useless state to store, and if we can validate a tx (eg Mev bots racing each other, or nft drops and hat get spammed and fail) we have a chance to decrease the overall load on the network and free up space that’s literally useless.\n\n post by thogard785 on Feb 5, 2025\n\n thogard785\n\n Why skip - is it purely for the disincentivize? If the Coinbase is already paying the cost, why not execute it and let the block builder act as a de facto paymaster?\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\n GregTheGreek\n\n This is interesting, and yeah, I agree, the right place for invalid transaction would actually be in a blob, and then being pruned after some days.\nI have to think more about this approach and what it would require in changes as we’re currently basically using simple “if not skipped then execute and refund, else skip” logic while putting txs into the trie beforehand. So, we’d need to keep track of skipped txs and then move them over into a blob. 128kib would probably be a little wasteful since we can expect skipped transactions to be a very rare event since local/mevboost builders have a clear incentive to not have skipped txs bc they pay for it. Also, during syncing you’d need to know that those transactions (that still contribute to the previous_state_root of the next block) are now in a blob instead of the block. I still have to get my head around this.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\nFor mevboost blocks, the coinbase usually sets its own address into the “coinbase”. So, when a transaction needs to skip execution, it means that the transaction was invalid (underfunded, invalid nonce, etc) and would normally have invalidated the whole block. With the described delayed execution mechanism, we’d pre-charge the coinbase of the block (builder) at the very beginning, taking an “inclusion fee” (21k base cost + calldata + blobs), and refund it in case the tx is not skipped. So, there’s a clear incentive for the builder to not order your transactions in a way that screws you over by suddenly having your transactions “skip”. The builder can still do so but pays for it. So, skipped transactions should be rare bugs and failures at the one that has control over the content of the block.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\nYeah, this is correct in case of delayed execution. The transaction (and withdrawal) encoding happens as part of the static checks too, yes. In the diagram I wanted to show the current state transition function, not the one with delayed execution, just to show that static validation is minimal compared to the rest. I have the post-execution header checks as Verification at the end.\nThis is all done in validate_header() in the specs:\n\n post by LukaszRozmej on Feb 6, 2025\n\n LukaszRozmej\n\n I have mixed feelings, but probably more on the positive side.\nI would like to propose to call it an async execution rather than delayed execution. As we are not really delaying it to any next slots, but running it async to attestations and all CL logic, without waiting for result.\nAs for the proposal: on one hand it probably gives us a lot of wiggle room with execution. On the other hand execution is probably not the main bottleneck, bandwith and state growth are.\nI somewhat like skipped transactions, this brings parity with rollups, especially based rollups that can’t control their sequencer thus have to have a similar concept.\nMy main concerns would be around if this won’t close up some other paths we would like to explore in the future as the design is somewhat a one way ticket and will prevent us from having this execution feedback loop in CL. Not sure if there are already existing EIPs this would make void?\n\n post by linoscope on Feb 6, 2025\n\n linoscope\n\n Good read and interesting proposal!\n\nI am wondering about the impact on self-building solo-stakers here, who may not have such liquidity. Note that even for validators using MEV-Boost, self-building is important for supporting the fallback case for MEV-Boost failure. Is the assumption that we will already have APS so all builders (= execution proposers) are sophisticated? Or maybe there can be an opt-out mechanism to allow for blocks to be proposed without the delayed execution (and consequently the upfront payment), probably with a lower gas limit?\n\n post by thogard785 on Feb 6, 2025\n\n thogard785\n\n Nero_eth\n\n I see. So I think my concern would be around EIP-7702:\n\nIf we assume that the block builder does execute the block, I don’t think that the builder would include txs that aren’t profitable for the builder, so I don’t see the need to “skip” txs. If the builder wants to pay for the unfunded txs, imo let them.\nIf we assume that the block builder doesn’t execute the entire block, then there is a pretty gnarly attack vector on the builder created by 7702. For context, EIP-7702 allows for bytecode to be deployed to EOAs. Currently, in the absence of 7702, a block builder can build a valid block by looking at an EOA’s balance at the end of the last block and then ensuring that balance > (tx.gas + calldata_gas) * tx.gas_price + tx.value. But this only works because of the invariant “only a tx from an EOA can decrease that EOA’s balance.” If we assume that the builder isn’t executing the txs in a block, 7702 will allow EOAs to frontrun their txs with other txs to arbitrarily drain their balances. In a PBS-style competitive, permissionless auction, this type of adversarial behavior could be rational to decrease the value / profit of a builder’s block.\n\nIn the long term I think that skipping the tx would disincentivize that type of behavior - and incentives do matter - but I worry that presumed-adversarial actors in the MEV supply chain may interact with this mechanism in ways that cause unexpected externalities.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\n Yeah, all good points!\n\nYeah, I can see why this makes sense.\n\nThis is true. Initially, when considering the interplay between FOCIL (EIP-7805) and the delayed execution proposal in its current form, it became clear that for FOCIL execution must be carried out before attesting to check whether a transaction—one that is not included in the block but is present on the IL—can be appended.\nFor other concepts, such as block base fee sponsoring, block-level access lists, or real-time proving, delayed execution offers significant advantages.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\n linoscope\n\n Good questions! The additional liquidity requirement could indeed be a challenge for those who don’t have ~3 ETH on top of their 32 ETH. However, we need to weigh the pros and cons.\nIf pipelining execution unlocks significant efficiency gains and the only trade-off is monetary assets for “stake,” it might be a worthwhile approach (there are other downsides as outlined in the post). Local builders can still operate under the increased liquidity requirement, ultimately contributing to a more scalable network. For most users, the ~95% who are using MEV-Boost, the liquidity requirements are handled by the block builder.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\nWe need to skip transactions because, otherwise, they would invalidate the entire block. The builder pays for their inclusion—not for execution—since these transactions have no execution.\nThe only incentive for the local builder or MEV-Boost builder is to avoid skipped transactions. For the user, it doesn’t matter whether the builder includes transaction A and B from sender C in one order or the other. If a transaction is skipped due to nonce issues, the builder pays. This is consistent because one could argue that the fault lies with the builder.\n\n post by thogard785 on Feb 6, 2025\n\n thogard785\n\n I think it’s more complex than this - in your inclusion-but-not-execution model you aren’t accounting for the opportunity cost of the transaction.\nEDIT: I agree with skipping nonce-invalidated and signature-invalidated and other critical security issues. But specifically for gas cost invalid txs:\nIf the builder is executing the entire block then great, but they won’t include bad txs unless it’s profitable to do so. There’s no opportunity cost but there’s also no bad txs, so just charge the builder for the max execution cost of any invalidated-by-gas-cost transaction (and then execute it). There’s no reason not to do so.\nIf the builder isn’t executing the entire block, that also means the builder has to build the block based on the gas limit of each transaction rather than the execution gas used. This is because they don’t yet know what the execution gas used will be, because they haven’t executed it yet. Validators voting / attesting would similarly have to build the block based on gas limits rather than execution gas used. In this example, you’d still want to charge the builder for the max execution cost because that’s what corresponds with the blockspace that they’re reserving and it’s the opportunity cost to all parties involved for an invalid transaction.\nThis opens up a real can of worms though around gas costs and their relationship with gas limits. There is a lot of research being done on this area that should help inform on delayed execution strategies. I agree with you that the two are inherently linked and that it’s hard to discuss details of async execution without first clarifying changes to gas cost.\n\n post by Nero_eth on Feb 7, 2025\n\n Nero_eth\n\nYou cannot execute an “invalid” transaction—that’s what makes it invalid. There are only two options:\n\nSkip execution.\nInvalidate the entire block.\n\nIf such a transaction were executed, it could “overwrite” a past transaction through nonce reuse.\n\nThis is only partly correct. For each transaction, we check whether its maximum gas usage (the gas limit) still fits within the block. However, after executing the transaction, we only subtract the actual gas used from the block gas limit.\nFor example, if I include a 21k gas transaction (consumes 21k and has 21k gas limit) in a block, another 21k transaction cannot be added to that block if it specifies a gas limit equal to the block gas limit. Ordering them vice-verca works. This logic remains unchanged with delayed execution.\nImportantly, even skipped transactions consume gas—otherwise, this would create a DoS vector. However, they only consume inclusion gas, which is fair since the transaction remains available indefinitely and can still be used for DA.\n\n post by GregTheGreek on Feb 11, 2025\n\n GregTheGreek\n\n Nero_eth\n\n That makes sense, I was trying to target failed txs due to races (eg: solvers, or liquidation bots) which we can fully remove from the blocks and state entirely.\nWe might be able to do both at the same time.\n\n post by thogard785 on Feb 11, 2025\n\n thogard785\n\nApologies for the typo. I was specifically and exclusively referring to transactions “invalidated” post-inclusion due to a gas balance shortfall. But invalidated is probably the wrong word to use if they’re actually executed Rewording it, I think the gist of my point was that it’s not clear to me why this new case (gas cost shortfall) should lead to an invalidated transaction if we can make the block builder on the hook for the gas cost anyway. I don’t see the benefit of separating out an inclusion cost from an execution cost - can you elaborate on the motivation and benefits of doing so?\n\nThat’s how synchronous execution works.\n\nI must be fundamentally misunderstanding your design because I do no believe that the logic is unchanged with delayed execution. In fact, I believe your example illustrates the difference.\nFor the two txs in your example:\nBlockGasLimit:\n30,000,000\nTx A𝐴:\nGasLimit𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡: 21,00021,000\nGasUsed𝐺𝑎𝑠𝑈𝑠𝑒𝑑 (in Execution): 21,00021,000\nTx B𝐵:\nGasLimit𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡: 30,000,00030,000,000\nGasUsed𝐺𝑎𝑠𝑈𝑠𝑒𝑑 (in Execution): 21,00021,000\nSynchronous Execution, sequence [A, B][𝐴,𝐵]:\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasUsed_A = 29,979,000=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝑈𝑠𝑒𝑑𝐴 =29,979,000\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_B = 30,000,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐵 =30,000,000\nTx B𝐵 cannot be included because GasAvailable < GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 <𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nAsynchronous Execution, sequence [A, B][𝐴,𝐵]:\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasLimit_A = 29,979,000=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐴 =29,979,000\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_B = 30,000,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐵 =30,000,000\nTx B𝐵 cannot be included because GasAvailable < GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 <𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nMatches so far, but if we flip the sequence:\nSynchronous Execution, sequence [B, A][𝐵,𝐴]:\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasUsed_B = 29,979,000=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝑈𝑠𝑒𝑑𝐵 =29,979,000\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_A = 21,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐴 =21,000\nTx A𝐴 CAN be included because GasAvailable \\ge GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 ≥𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nAsynchronous Execution, sequence [B, A][𝐵,𝐴]:\nNote that we’d have to execute Tx B𝐵 to know that it only used 21,00021,000 gas in execution, and executing Tx B𝐵 is not possible with delayed execution.\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasLimit_B = 0=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐵 =0\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_A = 21,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐴 =21,000\nTx A𝐴 cannot be included because GasAvailable < GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 <𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nIn other words, with asynchronous / delayed execution, we do not know how much gas is used during execution and so the builder has to build the block by fitting the sum of each transaction’s gas limit (not gas used) into the block. If it were built any other way, execution would be needed prior to validation in order to know how much gas was actually used.\nThis is also why I emphasize the opportunity cost of the transaction’s gas cost as if it were fully executed - this cost is relevant because the high gas limit is forcing out other transactions that could be executed inside of the same space and earn fees for the proposer (and/or burn for the protocol). The foregone revenue to the proposer / validator would be the full execution cost (+ inclusion if you separate it) of the invalidated tx. If we want to really lean into delayed execution, technically the opportunity cost would be based on the actual gas limit of the tx.\nPlease let me know if I’m missing something - perhaps there’s an “block overfilling” mechanism? But if so, it’s not clear to me what would happen if all txs used up all of their gas limit and the block itself became invalidated.\n\n post by Nero_eth on Feb 12, 2025\n\n Nero_eth\n\nAh, I see what you mean and there is actually a 3rd part that the coinbase could sponsor:\n\nInclusion cost (delayed execution)\nInclusion cost + base fee (delayed execution + block base fee)\nInclusion cost + base fee + everything else (with only tx.value remaining)\n\nWhile directly going to block base fee sponsoring seems intriguing, it definitely brings additional complexity and a smoother rollup of the phases might be better.\n\nThis means that even though we COULD make the block’s coinbase base for underfunded transactions at execution, we don’t in the initial design. Besides the complexity it would increase the monetary requirement to local build (which might be fine though).\n\nHere, we would just stop executing and start skipping if the actual gas usage raises above the block gas limit during execution. For the inclusion cost is already paid at that point. The builder would lose the inclusion cost for the transaction that went over the block gas limit.\n\n Load more posts below","tokens":6683,"squid":"ink-research","role":"Deep Scholar","at":1791259747475,"hash":"cb68dc8ad3f69f122339b0e57fbb5add020037e7"}
{"url":"https://eips.ethereum.org/EIPS/eip-721","domain":"eips.ethereum.org","title":"ERC-721: Non-Fungible Token Standard","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-721: Non-Fungible Token Standard\n\n Authors\n William Entriken (@fulldecent), Dieter Shirley <dete@axiomzen.co>, Jacob Evans <jacob@dekz.net>, Nastassia Sachs <nastassia.sachs@protonmail.com>\n\n Created\n 2018-01-24\n\n Requires\n\n EIP-165\n\n Simple Summary\n\nA standard interface for non-fungible tokens, also known as deeds.\n\n Abstract\n\nThe following standard allows for the implementation of a standard API for NFTs within smart contracts. This standard provides basic functionality to track and transfer NFTs.\n\nWe considered use cases of NFTs being owned and transacted by individuals as well as consignment to third party brokers/wallets/auctioneers (“operators”). NFTs can represent ownership over digital or physical assets. We considered a diverse universe of assets, and we know you will dream up many more:\n\n Physical property — houses, unique artwork\n Virtual collectibles — unique pictures of kittens, collectible cards\n “Negative value” assets — loans, burdens and other responsibilities\n\nIn general, all houses are distinct and no two kittens are alike. NFTs are distinguishable and you must track the ownership of each one separately.\n\n Motivation\n\nA standard interface allows wallet/broker/auction applications to work with any NFT on Ethereum. We provide for simple ERC-721 smart contracts as well as contracts that track an arbitrarily large number of NFTs. Additional applications are discussed below.\n\nThis standard is inspired by the ERC-20 token standard and builds on two years of experience since EIP-20 was created. EIP-20 is insufficient for tracking NFTs because each asset is distinct (non-fungible) whereas each of a quantity of tokens is identical (fungible).\n\nDifferences between this standard and EIP-20 are examined below.\n\n Specification\n\nThe key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.\n\nEvery ERC-721 compliant contract must implement the ERC721 and ERC165 interfaces (subject to “caveats” below):\n\npragma solidity ^0.4.20;\n\n/// @title ERC-721 Non-Fungible Token Standard\n/// @dev See https://eips.ethereum.org/EIPS/eip-721\n/// Note: the ERC-165 identifier for this interface is 0x80ac58cd.\ninterface ERC721 /* is ERC165 */ {\n /// @dev This emits when ownership of any NFT changes by any mechanism.\n /// This event emits when NFTs are created (`from` == 0) and destroyed\n /// (`to` == 0). Exception: during contract creation, any number of NFTs\n /// may be created and assigned without emitting Transfer. At the time of\n /// any transfer, the approved address for that NFT (if any) is reset to none.\n event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);\n\n /// @dev This emits when the approved address for an NFT is changed or\n /// reaffirmed. The zero address indicates there is no approved address.\n /// When a Transfer event emits, this also indicates that the approved\n /// address for that NFT (if any) is reset to none.\n event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);\n\n /// @dev This emits when an operator is enabled or disabled for an owner.\n /// The operator can manage all NFTs of the owner.\n event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);\n\n /// @notice Count all NFTs assigned to an owner\n /// @dev NFTs assigned to the zero address are considered invalid, and this\n /// function throws for queries about the zero address.\n /// @param _owner An address for whom to query the balance\n /// @return The number of NFTs owned by `_owner`, possibly zero\n function balanceOf(address _owner) external view returns (uint256);\n\n /// @notice Find the owner of an NFT\n /// @dev NFTs assigned to zero address are considered invalid, and queries\n /// about them do throw.\n /// @param _tokenId The identifier for an NFT\n /// @return The address of the owner of the NFT\n function ownerOf(uint256 _tokenId) external view returns (address);\n\n /// @notice Transfers the ownership of an NFT from one address to another address\n /// @dev Throws unless `msg.sender` is the current owner, an authorized\n /// operator, or the approved address for this NFT. Throws if `_from` is\n /// not the current owner. Throws if `_to` is the zero address. Throws if\n /// `_tokenId` is not a valid NFT. When transfer is complete, this function\n /// checks if `_to` is a smart contract (code size > 0). If so, it calls\n /// `onERC721Received` on `_to` and throws if the return value is not\n /// `bytes4(keccak256(\"onERC721Received(address,address,uint256,bytes)\"))`.\n /// @param _from The current owner of the NFT\n /// @param _to The new owner\n /// @param _tokenId The NFT to transfer\n /// @param data Additional data with no specified format, sent in call to `_to`\n function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;\n\n /// @notice Transfers the ownership of an NFT from one address to another address\n /// @dev This works identically to the other function with an extra data parameter,\n /// except this function just sets data to \"\".\n /// @param _from The current owner of the NFT\n /// @param _to The new owner\n /// @param _tokenId The NFT to transfer\n function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;\n\n /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE\n /// TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE\n /// THEY MAY BE PERMANENTLY LOST\n /// @dev Throws unless `msg.sender` is the current owner, an authorized\n /// operator, or the approved address for this NFT. Throws if `_from` is\n /// not the current owner. Throws if `_to` is the zero address. Throws if\n /// `_tokenId` is not a valid NFT.\n /// @param _from The current owner of the NFT\n /// @param _to The new owner\n /// @param _tokenId The NFT to transfer\n function transferFrom(address _from, address _to, uint256 _tokenId) external payable;\n\n /// @notice Change or reaffirm the approved address for an NFT\n /// @dev The zero address indicates there is no approved address.\n /// Throws unless `msg.sender` is the current NFT owner, or an authorized\n /// operator of the current owner.\n /// @param _approved The new approved NFT controller\n /// @param _tokenId The NFT to approve\n function approve(address _approved, uint256 _tokenId) external payable;\n\n /// @notice Enable or disable approval for a third party (\"operator\") to manage\n /// all of `msg.sender`'s assets\n /// @dev Emits the ApprovalForAll event. The contract MUST allow\n /// multiple operators per owner.\n /// @param _operator Address to add to the set of authorized operators\n /// @param _approved True if the operator is approved, false to revoke approval\n function setApprovalForAll(address _operator, bool _approved) external;\n\n /// @notice Get the approved address for a single NFT\n /// @dev Throws if `_tokenId` is not a valid NFT.\n /// @param _tokenId The NFT to find the approved address for\n /// @return The approved address for this NFT, or the zero address if there is none\n function getApproved(uint256 _tokenId) external view returns (address);\n\n /// @notice Query if an address is an authorized operator for another address\n /// @param _owner The address that owns the NFTs\n /// @param _operator The address that acts on behalf of the owner\n /// @return True if `_operator` is an approved operator for `_owner`, false otherwise\n function isApprovedForAll(address _owner, address _operator) external view returns (bool);\n}\n\ninterface ERC165 {\n /// @notice Query if a contract implements an interface\n /// @param interfaceID The interface identifier, as specified in ERC-165\n /// @dev Interface identification is specified in ERC-165. This function\n /// uses less than 30,000 gas.\n /// @return `true` if the contract implements `interfaceID` and\n /// `interfaceID` is not 0xffffffff, `false` otherwise\n function supportsInterface(bytes4 interfaceID) external view returns (bool);\n}\n\nA wallet/broker/auction application MUST implement the wallet interface if it will accept safe transfers.\n\n/// @dev Note: the ERC-165 identifier for this interface is 0x150b7a02.\ninterface ERC721TokenReceiver {\n /// @notice Handle the receipt of an NFT\n /// @dev The ERC721 smart contract calls this function on the recipient\n /// after a `transfer`. This function MAY throw to revert and reject the\n /// transfer. Return of other than the magic value MUST result in the\n /// transaction being reverted.\n /// Note: the contract address is always the message sender.\n /// @param _operator The address which called `safeTransferFrom` function\n /// @param _from The address which previously owned the token\n /// @param _tokenId The NFT identifier which is being transferred\n /// @param _data Additional data with no specified format\n /// @return `bytes4(keccak256(\"onERC721Received(address,address,uint256,bytes)\"))`\n /// unless throwing\n function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes _data) external returns(bytes4);\n}\n\nThe metadata extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your smart contract to be interrogated for its name and for details about the assets which your NFTs represent.\n\n/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension\n/// @dev See https://eips.ethereum.org/EIPS/eip-721\n/// Note: the ERC-165 identifier for this interface is 0x5b5e139f.\ninterface ERC721Metadata /* is ERC721 */ {\n /// @notice A descriptive name for a collection of NFTs in this contract\n function name() external view returns (string _name);\n\n /// @notice An abbreviated name for NFTs in this contract\n function symbol() external view returns (string _symbol);\n\n /// @notice A distinct Uniform Resource Identifier (URI) for a given asset.\n /// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC\n /// 3986. The URI may point to a JSON file that conforms to the \"ERC721\n /// Metadata JSON Schema\".\n function tokenURI(uint256 _tokenId) external view returns (string);\n}\n\nThis is the “ERC721 Metadata JSON Schema” referenced above.\n\n{\n \"title\": \"Asset Metadata\",\n \"type\": \"object\",\n \"properties\": {\n \"name\": {\n \"type\": \"string\",\n \"description\": \"Identifies the asset to which this NFT represents\"\n },\n \"description\": {\n \"type\": \"string\",\n \"description\": \"Describes the asset to which this NFT represents\"\n },\n \"image\": {\n \"type\": \"string\",\n \"description\": \"A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.\"\n }\n }\n}\n\nThe enumeration extension is OPTIONAL for ERC-721 smart contracts (see “caveats”, below). This allows your contract to publish its full list of NFTs and make them discoverable.\n\n/// @title ERC-721 Non-Fungible Token Standard, optional enumeration extension\n/// @dev See https://eips.ethereum.org/EIPS/eip-721\n/// Note: the ERC-165 identifier for this interface is 0x780e9d63.\ninterface ERC721Enumerable /* is ERC721 */ {\n /// @notice Count NFTs tracked by this contract\n /// @return A count of valid NFTs tracked by this contract, where each one of\n /// them has an assigned and queryable owner not equal to the zero address\n function totalSupply() external view returns (uint256);\n\n /// @notice Enumerate valid NFTs\n /// @dev Throws if `_index` >= `totalSupply()`.\n /// @param _index A counter less than `totalSupply()`\n /// @return The token identifier for the `_index`th NFT,\n /// (sort order not specified)\n function tokenByIndex(uint256 _index) external view returns (uint256);\n\n /// @notice Enumerate NFTs assigned to an owner\n /// @dev Throws if `_index` >= `balanceOf(_owner)` or if\n /// `_owner` is the zero address, representing invalid NFTs.\n /// @param _owner An address where we are interested in NFTs owned by them\n /// @param _index A counter less than `balanceOf(_owner)`\n /// @return The token identifier for the `_index`th NFT assigned to `_owner`,\n /// (sort order not specified)\n function tokenOfOwnerByIndex(address _owner, uint256 _index) external view returns (uint256);\n}\n\n Caveats\n\nThe 0.4.20 Solidity interface grammar is not expressive enough to document the ERC-721 standard. A contract which complies with ERC-721 MUST also abide by the following:\n\n Solidity issue #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: payable, implicit nonpayable, view, and pure. Your implementation MUST meet the mutability guarantee in this interface and you MAY meet a stronger guarantee. For example, a payable function in this interface may be implemented as nonpayable (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.20 is that you can edit this interface to add stricter mutability before inheriting from your contract.\n Solidity issue #3419: A contract that implements ERC721Metadata or ERC721Enumerable SHALL also implement ERC721. ERC-721 implements the requirements of interface ERC-165.\n Solidity issue #2330: If a function is shown in this specification as external then a contract will be compliant if it uses public visibility. As a workaround for version 0.4.20, you can edit this interface to switch to public before inheriting from your contract.\n Solidity issues #3494, #3544: Use of this.*.selector is marked as a warning by Solidity, a future version of Solidity will not mark this as an error.\n\nIf a newer version of Solidity allows the caveats to be expressed in code, then this EIP MAY be updated and the caveats removed, such will be equivalent to the original specification.\n\n Rationale\n\nThere are many proposed uses of Ethereum smart contracts that depend on tracking distinguishable assets. Examples of existing or planned NFTs are LAND in Decentraland, the eponymous punks in CryptoPunks, and in-game items using systems like DMarket or EnjinCoin. Future uses include tracking real-world assets, like real-estate (as envisioned by companies like Ubitquity or Propy). It is critical in each of these cases that these items are not “lumped together” as numbers in a ledger, but instead each asset must have its ownership individually and atomically tracked. Regardless of the nature of these assets, the ecosystem will be stronger if we have a standardized interface that allows for cross-functional asset management and sales platforms.\n\n“NFT” Word Choice\n\n“NFT” was satisfactory to nearly everyone surveyed and is widely applicable to a broad universe of distinguishable digital assets. We recognize that “deed” is very descriptive for certain applications of this standard (notably, physical property).\n\nAlternatives considered: distinguishable asset, title, token, asset, equity, ticket\n\nNFT Identifiers\n\nEvery NFT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint256 tokenId) will then be a globally unique and fully-qualified identifier for a specific asset on an Ethereum chain. While some ERC-721 smart contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers SHALL NOT assume that ID numbers have any specific pattern to them, and MUST treat the ID as a “black box”. Also note that NFTs MAY become invalid (be destroyed). Please see the enumeration functions for a supported enumeration interface.\n\nThe choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256.\n\nTransfer Mechanism\n\nERC-721 standardizes a safe transfer function safeTransferFrom (overloaded with and without a bytes parameter) and an unsafe function transferFrom. Transfers may be initiated by:\n\n The owner of an NFT\n The approved address of an NFT\n An authorized operator of the current owner of an NFT\n\nAdditionally, an authorized operator may set the approved address for an NFT. This provides a powerful set of tools for wallet, broker and auction applications to quickly use a large number of NFTs.\n\nThe transfer and accept functions’ documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results:\n\n Disallow transfers if the contract is paused — prior art, CryptoKitties deployed contract, line 611\n Blocklist certain address from receiving NFTs — prior art, CryptoKitties deployed contract, lines 565, 566\n Disallow unsafe transfers — transferFrom throws unless _to equals msg.sender or countOf(_to) is non-zero or was non-zero previously (because such cases are safe)\n Charge a fee to both parties of a transaction — require payment when calling approve with a non-zero _approved if it was previously the zero address, refund payment if calling approve with the zero address if it was previously a non-zero address, require payment when calling any transfer function, require transfer parameter _to to equal msg.sender, require transfer parameter _to to be the approved address for the NFT\n Read only NFT registry — always throw from safeTransferFrom, transferFrom, approve and setApprovalForAll\n\nFailed transactions will throw, a best practice identified in ERC-223, ERC-677, ERC-827 and OpenZeppelin’s implementation of SafeERC20.sol. ERC-20 defined an allowance feature, this caused a problem when called and then later modified to a different amount, as on OpenZeppelin issue #438. In ERC-721, there is no allowance because every NFT is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20’s original design without problems that have been later discovered.\n\nCreation of NFTs (“minting”) and destruction of NFTs (“burning”) is not included in the specification. Your contract may implement these by other means. Please see the event documentation for your responsibilities when creating or destroying NFTs.\n\nWe questioned if the operator parameter on onERC721Received was necessary. In all cases we could imagine, if the operator was important then that operator could transfer the token to themself and then send it – then they would be the from address. This seems contrived because we consider the operator to be a temporary owner of the token (and transferring to themself is redundant). When the operator sends the token, it is the operator acting on their own accord, NOT the operator acting on behalf of the token holder. This is why the operator and the previous token owner are both significant to the token recipient.\n\nAlternatives considered: only allow two-step ERC-20 style transaction, require that transfer functions never throw, require all functions to return a boolean indicating the success of the operation.\n\nERC-165 Interface\n\nWe chose Standard Interface Detection (ERC-165) to expose the interfaces that a ERC-721 smart contract supports.\n\nA future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your ERC-721 implementation to implement ERC721Enumerable, ERC721Metadata, or other interfaces by delegating to a separate contract.\n\nGas and Complexity (regarding the enumeration extension)\n\nThis specification contemplates implementations that manage a few and arbitrarily large numbers of NFTs. If your application is able to grow then avoid using for/while loops in your code (see CryptoKitties bounty issue #4). These indicate your contract may be unable to scale and gas costs will rise over time without bound.\n\nWe have deployed a contract, XXXXERC721, to Testnet which instantiates and tracks 340282366920938463463374607431768211456 different deeds (2^128). That’s enough to assign every IPV6 address to an Ethereum account owner, or to track ownership of nanobots a few micron in size and in aggregate totalling half the size of Earth. You can query it from the blockchain. And every function takes less gas than querying the ENS.\n\nThis illustration makes clear: the ERC-721 standard scales.\n\nAlternatives considered: remove the asset enumeration function if it requires a for-loop, return a Solidity array type from enumeration functions.\n\nPrivacy\n\nWallets/brokers/auctioneers identified in the motivation section have a strong need to identify which NFTs an owner owns.\n\nIt may be interesting to consider a use case where NFTs are not enumerable, such as a private registry of property ownership, or a partially-private registry. However, privacy cannot be attained because an attacker can simply (!) call ownerOf for every possible tokenId.\n\nMetadata Choices (metadata extension)\n\nWe have required name and symbol functions in the metadata extension. Every token EIP and draft we reviewed (ERC-20, ERC-223, ERC-677, ERC-777, ERC-827) included these functions.\n\nWe remind implementation authors that the empty string is a valid response to name and symbol if you protest to the usage of this mechanism. We also remind everyone that any smart contract can use the same name and symbol as your contract. How a client may determine which ERC-721 smart contracts are well-known (canonical) is outside the scope of this standard.\n\nA mechanism is provided to associate NFTs with URIs. We expect that many implementations will take advantage of this to provide metadata for each NFT. The image size recommendation is taken from Instagram, they probably know much about image usability. The URI MAY be mutable (i.e. it changes from time to time). We considered an NFT representing ownership of a house, in this case metadata about the house (image, occupants, etc.) can naturally change.\n\nMetadata is returned as a string value. Currently this is only usable as calling from web3, not from other contracts. This is acceptable because we have not considered a use case where an on-blockchain application would query such information.\n\nAlternatives considered: put all metadata for each asset on the blockchain (too expensive), use URL templates to query metadata parts (URL templates do not work with all URL schemes, especially P2P URLs), multiaddr network address (not mature enough)\n\nCommunity Consensus\n\nA significant amount of discussion occurred on the original ERC-721 issue, additionally we held a first live meeting on Gitter that had good representation and well advertised (on Reddit, in the Gitter #ERC channel, and the original ERC-721 issue). Thank you to the participants:\n\n @ImAllInNow Rob from DEC Gaming / Presenting Michigan Ethereum Meetup Feb 7\n @Arachnid Nick Johnson\n @jadhavajay Ajay Jadhav from AyanWorks\n @superphly Cody Marx Bailey - XRAM Capital / Sharing at hackathon Jan 20 / UN Future of Finance Hackathon.\n @fulldecent William Entriken\n\nA second event was held at ETHDenver 2018 to discuss distinguishable asset standards (notes to be published).\n\nWe have been very inclusive in this process and invite anyone with questions or contributions into our discussion. However, this standard is written only to support the identified use cases which are listed herein.\n\n Backwards Compatibility\n\nWe have adopted balanceOf, totalSupply, name and symbol semantics from the ERC-20 specification. An implementation may also include a function decimals that returns uint8(0) if its goal is to be more compatible with ERC-20 while supporting this standard. However, we find it contrived to require all ERC-721 implementations to support the decimals function.\n\nExample NFT implementations as of February 2018:\n\n CryptoKitties – Compatible with an earlier version of this standard.\n CryptoPunks – Partially ERC-20 compatible, but not easily generalizable because it includes auction functionality directly in the contract and uses function names that explicitly refer to the assets as “punks”.\n Auctionhouse Asset Interface – The author needed a generic interface for the Auctionhouse ÐApp (currently ice-boxed). His “Asset” contract is very simple, but is missing ERC-20 compatibility, approve() functionality, and metadata. This effort is referenced in the discussion for EIP-173.\n\nNote: “Limited edition, collectible tokens” like Curio Cards and Rare Pepe are not distinguishable assets. They’re actually a collection of individual fungible tokens, each of which is tracked by its own smart contract with its own total supply (which may be 1 in extreme cases).\n\nThe onERC721Received function specifically works around old deployed contracts which may inadvertently return 1 (true) in certain circumstances even if they don’t implement a function (see Solidity DelegateCallReturnValue bug). By returning and checking for a magic value, we are able to distinguish actual affirmative responses versus these vacuous trues.\n\n Test Cases\n\n0xcert ERC-721 Token includes test cases written using Truffle.\n\n Implementations\n\n0xcert ERC721 – a reference implementation\n\n MIT licensed, so you can freely use it for your projects\n Includes test cases\n Active bug bounty, you will be paid if you find errors\n\nSu Squares – an advertising platform where you can rent space and place images\n\n Complete the Su Squares Bug Bounty Program to seek problems with this standard or its implementation\n Implements the complete standard and all optional interfaces\n\nERC721ExampleDeed – an example implementation\n\n Implements using the OpenZeppelin project format\n\nXXXXERC721, by William Entriken – a scalable example implementation\n\n Deployed on testnet with 1 billion assets and supporting all lookups with the metadata extension. This demonstrates that scaling is NOT a problem.\n\n References\n\nStandards\n\n ERC-20 Token Standard.\n ERC-165 Standard Interface Detection.\n ERC-173 Owned Standard.\n ERC-223 Token Standard.\n ERC-677 transferAndCall Token Standard.\n ERC-827 Token Standard.\n Ethereum Name Service (ENS). https://ens.domains\n Instagram – What’s the Image Resolution? https://help.instagram.com/1631821640426723\n JSON Schema. https://json-schema.org/\n Multiaddr. https://github.com/multiformats/multiaddr\n RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. https://www.ietf.org/rfc/rfc2119.txt\n\nIssues\n\n The Original ERC-721 Issue. https://github.com/ethereum/eips/issues/721\n Solidity Issue #2330 – Interface Functions are External. https://github.com/ethereum/solidity/issues/2330\n Solidity Issue #3412 – Implement Interface: Allow Stricter Mutability. https://github.com/ethereum/solidity/issues/3412\n Solidity Issue #3419 – Interfaces Can’t Inherit. https://github.com/ethereum/solidity/issues/3419\n Solidity Issue #3494 – Compiler Incorrectly Reasons About the selector Function. https://github.com/ethereum/solidity/issues/3494\n Solidity Issue #3544 – Cannot Calculate Selector of Function Named transfer. https://github.com/ethereum/solidity/issues/3544\n CryptoKitties Bounty Issue #4 – Listing all Kitties Owned by a User is O(n^2). https://github.com/axiomzen/cryptokitties-bounty/issues/4\n OpenZeppelin Issue #438 – Implementation of approve method violates ERC20 standard. https://github.com/OpenZeppelin/zeppelin-solidity/issues/438\n Solidity DelegateCallReturnValue Bug. https://solidity.readthedocs.io/en/develop/bugs.html#DelegateCallReturnValue\n\nDiscussions\n\n Reddit (announcement of first live discussion). https://www.reddit.com/r/ethereum/comments/7r2ena/friday_119_live_discussion_on_erc_nonfungible/\n Gitter #EIPs (announcement of first live discussion). https://gitter.im/ethereum/EIPs?at=5a5f823fb48e8c3566f0a5e7\n ERC-721 (announcement of first live discussion). https://github.com/ethereum/eips/issues/721#issuecomment-358369377\n ETHDenver 2018. https://ethdenver.com\n\nNFT Implementations and Other Projects\n\n CryptoKitties. https://www.cryptokitties.co\n 0xcert ERC-721 Token. https://github.com/0xcert/ethereum-erc721\n Su Squares. https://tenthousandsu.com\n Decentraland. https://decentraland.org\n CryptoPunks. https://www.larvalabs.com/cryptopunks\n DMarket. https://www.dmarket.io\n Enjin Coin. https://enjincoin.io\n Ubitquity. https://www.ubitquity.io\n Propy. https://tokensale.propy.com\n CryptoKitties Deployed Contract. https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#code\n Su Squares Bug Bounty Program. https://github.com/fulldecent/su-squares-bounty\n XXXXERC721. https://github.com/fulldecent/erc721-example\n ERC721ExampleDeed. https://github.com/nastassiasachs/ERC721ExampleDeed\n Curio Cards. https://mycuriocards.com\n Rare Pepe. https://rarepepewallet.com\n Auctionhouse Asset Interface. https://github.com/dob/auctionhouse/blob/master/contracts/Asset.sol\n OpenZeppelin SafeERC20.sol Implementation.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n William Entriken (@fulldecent), Dieter Shirley <dete@axiomzen.co>, Jacob Evans <jacob@dekz.net>, Nastassia Sachs <nastassia.sachs@protonmail.com>, \"ERC-721: Non-Fungible Token Standard,\" Ethereum Improvement Proposals, no. 721, January 2018. Available: https://eips.ethereum.org/EIPS/eip-721.","tokens":7286,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259748024,"hash":"e6c54306de058c0f1e67333347423b1068d19ee3"}
{"url":"https://soliditylang.org/use-cases","domain":"soliditylang.org","title":"Use cases | Solidity Programming Language","text":"{Use_cases}With Solidity, you can create contracts for uses such as voting, crowdfunding, blind auctions, and multi-signature wallets and much more! Below we list some of the most popular use cases.Get startedDecentralized Autonomous Organizations (DAOs)Solidity has enabled the creation of DAOs, which are self-governing organizations that operate on smart contracts, allowing for transparent decision-making and governance.Learn moreGaming and Virtual WorldsSolidity has been employed to develop blockchain-based games and virtual worlds with features like asset ownership, in-game economies, and provable scarcity. It opens up new possibilities for unique digital assets and player interactions.Decentralized Finance (DeFi)Solidity has played a pivotal role in the rise of DeFi applications built on the Ethereum blockchain. Developers have created decentralized exchange logic, auction mechanisms, lending protocols, conditional payments, and more.Learn moreNon-Fungible Tokens (NFTs)Solidity has been used to implement NFTs, which have gained significant popularity for digital collectibles, artwork, and unique virtual assets like decentralized domain names.Learn moreSupply Chain and TraceabilitySolidity can be used to create smart contracts that enhance transparency and traceability in supply chain management. By recording transactions and verifying the authenticity of products, Solidity-powered smart contracts can help prevent counterfeiting and improve trust in supply chain processes.... and much moreIf you want to get started building your own applications, head to the Solidity by Example section to see code examples of different contracts and understand the core concepts of the language.","tokens":427,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259755395,"hash":"10c4377563f6ac83a61bc63ee58c41839135e879"}
{"url":"https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677/27","domain":"ethresear.ch","title":"Delayed Execution And Skipped Transactions - Execution Layer Research - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 11\n\n 6\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n Feb 2025\n\n 27 / 27\n\n May 2025\n\n May 2025\n\n Load more posts above\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\nFor mevboost blocks, the coinbase usually sets its own address into the “coinbase”. So, when a transaction needs to skip execution, it means that the transaction was invalid (underfunded, invalid nonce, etc) and would normally have invalidated the whole block. With the described delayed execution mechanism, we’d pre-charge the coinbase of the block (builder) at the very beginning, taking an “inclusion fee” (21k base cost + calldata + blobs), and refund it in case the tx is not skipped. So, there’s a clear incentive for the builder to not order your transactions in a way that screws you over by suddenly having your transactions “skip”. The builder can still do so but pays for it. So, skipped transactions should be rare bugs and failures at the one that has control over the content of the block.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\nYeah, this is correct in case of delayed execution. The transaction (and withdrawal) encoding happens as part of the static checks too, yes. In the diagram I wanted to show the current state transition function, not the one with delayed execution, just to show that static validation is minimal compared to the rest. I have the post-execution header checks as Verification at the end.\nThis is all done in validate_header() in the specs:\n\n post by LukaszRozmej on Feb 6, 2025\n\n LukaszRozmej\n\n I have mixed feelings, but probably more on the positive side.\nI would like to propose to call it an async execution rather than delayed execution. As we are not really delaying it to any next slots, but running it async to attestations and all CL logic, without waiting for result.\nAs for the proposal: on one hand it probably gives us a lot of wiggle room with execution. On the other hand execution is probably not the main bottleneck, bandwith and state growth are.\nI somewhat like skipped transactions, this brings parity with rollups, especially based rollups that can’t control their sequencer thus have to have a similar concept.\nMy main concerns would be around if this won’t close up some other paths we would like to explore in the future as the design is somewhat a one way ticket and will prevent us from having this execution feedback loop in CL. Not sure if there are already existing EIPs this would make void?\n\n post by linoscope on Feb 6, 2025\n\n linoscope\n\n Good read and interesting proposal!\n\nI am wondering about the impact on self-building solo-stakers here, who may not have such liquidity. Note that even for validators using MEV-Boost, self-building is important for supporting the fallback case for MEV-Boost failure. Is the assumption that we will already have APS so all builders (= execution proposers) are sophisticated? Or maybe there can be an opt-out mechanism to allow for blocks to be proposed without the delayed execution (and consequently the upfront payment), probably with a lower gas limit?\n\n post by thogard785 on Feb 6, 2025\n\n thogard785\n\n Nero_eth\n\n I see. So I think my concern would be around EIP-7702:\n\nIf we assume that the block builder does execute the block, I don’t think that the builder would include txs that aren’t profitable for the builder, so I don’t see the need to “skip” txs. If the builder wants to pay for the unfunded txs, imo let them.\nIf we assume that the block builder doesn’t execute the entire block, then there is a pretty gnarly attack vector on the builder created by 7702. For context, EIP-7702 allows for bytecode to be deployed to EOAs. Currently, in the absence of 7702, a block builder can build a valid block by looking at an EOA’s balance at the end of the last block and then ensuring that balance > (tx.gas + calldata_gas) * tx.gas_price + tx.value. But this only works because of the invariant “only a tx from an EOA can decrease that EOA’s balance.” If we assume that the builder isn’t executing the txs in a block, 7702 will allow EOAs to frontrun their txs with other txs to arbitrarily drain their balances. In a PBS-style competitive, permissionless auction, this type of adversarial behavior could be rational to decrease the value / profit of a builder’s block.\n\nIn the long term I think that skipping the tx would disincentivize that type of behavior - and incentives do matter - but I worry that presumed-adversarial actors in the MEV supply chain may interact with this mechanism in ways that cause unexpected externalities.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\n Yeah, all good points!\n\nYeah, I can see why this makes sense.\n\nThis is true. Initially, when considering the interplay between FOCIL (EIP-7805) and the delayed execution proposal in its current form, it became clear that for FOCIL execution must be carried out before attesting to check whether a transaction—one that is not included in the block but is present on the IL—can be appended.\nFor other concepts, such as block base fee sponsoring, block-level access lists, or real-time proving, delayed execution offers significant advantages.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\n linoscope\n\n Good questions! The additional liquidity requirement could indeed be a challenge for those who don’t have ~3 ETH on top of their 32 ETH. However, we need to weigh the pros and cons.\nIf pipelining execution unlocks significant efficiency gains and the only trade-off is monetary assets for “stake,” it might be a worthwhile approach (there are other downsides as outlined in the post). Local builders can still operate under the increased liquidity requirement, ultimately contributing to a more scalable network. For most users, the ~95% who are using MEV-Boost, the liquidity requirements are handled by the block builder.\n\n post by Nero_eth on Feb 6, 2025\n\n Nero_eth\n\nWe need to skip transactions because, otherwise, they would invalidate the entire block. The builder pays for their inclusion—not for execution—since these transactions have no execution.\nThe only incentive for the local builder or MEV-Boost builder is to avoid skipped transactions. For the user, it doesn’t matter whether the builder includes transaction A and B from sender C in one order or the other. If a transaction is skipped due to nonce issues, the builder pays. This is consistent because one could argue that the fault lies with the builder.\n\n post by thogard785 on Feb 6, 2025\n\n thogard785\n\n I think it’s more complex than this - in your inclusion-but-not-execution model you aren’t accounting for the opportunity cost of the transaction.\nEDIT: I agree with skipping nonce-invalidated and signature-invalidated and other critical security issues. But specifically for gas cost invalid txs:\nIf the builder is executing the entire block then great, but they won’t include bad txs unless it’s profitable to do so. There’s no opportunity cost but there’s also no bad txs, so just charge the builder for the max execution cost of any invalidated-by-gas-cost transaction (and then execute it). There’s no reason not to do so.\nIf the builder isn’t executing the entire block, that also means the builder has to build the block based on the gas limit of each transaction rather than the execution gas used. This is because they don’t yet know what the execution gas used will be, because they haven’t executed it yet. Validators voting / attesting would similarly have to build the block based on gas limits rather than execution gas used. In this example, you’d still want to charge the builder for the max execution cost because that’s what corresponds with the blockspace that they’re reserving and it’s the opportunity cost to all parties involved for an invalid transaction.\nThis opens up a real can of worms though around gas costs and their relationship with gas limits. There is a lot of research being done on this area that should help inform on delayed execution strategies. I agree with you that the two are inherently linked and that it’s hard to discuss details of async execution without first clarifying changes to gas cost.\n\n post by Nero_eth on Feb 7, 2025\n\n Nero_eth\n\nYou cannot execute an “invalid” transaction—that’s what makes it invalid. There are only two options:\n\nSkip execution.\nInvalidate the entire block.\n\nIf such a transaction were executed, it could “overwrite” a past transaction through nonce reuse.\n\nThis is only partly correct. For each transaction, we check whether its maximum gas usage (the gas limit) still fits within the block. However, after executing the transaction, we only subtract the actual gas used from the block gas limit.\nFor example, if I include a 21k gas transaction (consumes 21k and has 21k gas limit) in a block, another 21k transaction cannot be added to that block if it specifies a gas limit equal to the block gas limit. Ordering them vice-verca works. This logic remains unchanged with delayed execution.\nImportantly, even skipped transactions consume gas—otherwise, this would create a DoS vector. However, they only consume inclusion gas, which is fair since the transaction remains available indefinitely and can still be used for DA.\n\n post by GregTheGreek on Feb 11, 2025\n\n GregTheGreek\n\n Nero_eth\n\n That makes sense, I was trying to target failed txs due to races (eg: solvers, or liquidation bots) which we can fully remove from the blocks and state entirely.\nWe might be able to do both at the same time.\n\n post by thogard785 on Feb 11, 2025\n\n thogard785\n\nApologies for the typo. I was specifically and exclusively referring to transactions “invalidated” post-inclusion due to a gas balance shortfall. But invalidated is probably the wrong word to use if they’re actually executed Rewording it, I think the gist of my point was that it’s not clear to me why this new case (gas cost shortfall) should lead to an invalidated transaction if we can make the block builder on the hook for the gas cost anyway. I don’t see the benefit of separating out an inclusion cost from an execution cost - can you elaborate on the motivation and benefits of doing so?\n\nThat’s how synchronous execution works.\n\nI must be fundamentally misunderstanding your design because I do no believe that the logic is unchanged with delayed execution. In fact, I believe your example illustrates the difference.\nFor the two txs in your example:\nBlockGasLimit:\n30,000,000\nTx A𝐴:\nGasLimit𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡: 21,00021,000\nGasUsed𝐺𝑎𝑠𝑈𝑠𝑒𝑑 (in Execution): 21,00021,000\nTx B𝐵:\nGasLimit𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡: 30,000,00030,000,000\nGasUsed𝐺𝑎𝑠𝑈𝑠𝑒𝑑 (in Execution): 21,00021,000\nSynchronous Execution, sequence [A, B][𝐴,𝐵]:\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasUsed_A = 29,979,000=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝑈𝑠𝑒𝑑𝐴 =29,979,000\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_B = 30,000,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐵 =30,000,000\nTx B𝐵 cannot be included because GasAvailable < GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 <𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nAsynchronous Execution, sequence [A, B][𝐴,𝐵]:\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasLimit_A = 29,979,000=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐴 =29,979,000\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_B = 30,000,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐵 =30,000,000\nTx B𝐵 cannot be included because GasAvailable < GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 <𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nMatches so far, but if we flip the sequence:\nSynchronous Execution, sequence [B, A][𝐵,𝐴]:\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasUsed_B = 29,979,000=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝑈𝑠𝑒𝑑𝐵 =29,979,000\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_A = 21,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐴 =21,000\nTx A𝐴 CAN be included because GasAvailable \\ge GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 ≥𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nAsynchronous Execution, sequence [B, A][𝐵,𝐴]:\nNote that we’d have to execute Tx B𝐵 to know that it only used 21,00021,000 gas in execution, and executing Tx B𝐵 is not possible with delayed execution.\nGasAvailable𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 for the Second Tx = BlockGasLimit - GasLimit_B = 0=𝐵𝑙𝑜𝑐𝑘𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡 −𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐵 =0\nGasNeeded𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑 for the Second Tx = GasLimit_A = 21,000=𝐺𝑎𝑠𝐿𝑖𝑚𝑖𝑡𝐴 =21,000\nTx A𝐴 cannot be included because GasAvailable < GasNeeded𝐺𝑎𝑠𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 <𝐺𝑎𝑠𝑁𝑒𝑒𝑑𝑒𝑑\nIn other words, with asynchronous / delayed execution, we do not know how much gas is used during execution and so the builder has to build the block by fitting the sum of each transaction’s gas limit (not gas used) into the block. If it were built any other way, execution would be needed prior to validation in order to know how much gas was actually used.\nThis is also why I emphasize the opportunity cost of the transaction’s gas cost as if it were fully executed - this cost is relevant because the high gas limit is forcing out other transactions that could be executed inside of the same space and earn fees for the proposer (and/or burn for the protocol). The foregone revenue to the proposer / validator would be the full execution cost (+ inclusion if you separate it) of the invalidated tx. If we want to really lean into delayed execution, technically the opportunity cost would be based on the actual gas limit of the tx.\nPlease let me know if I’m missing something - perhaps there’s an “block overfilling” mechanism? But if so, it’s not clear to me what would happen if all txs used up all of their gas limit and the block itself became invalidated.\n\n post by Nero_eth on Feb 12, 2025\n\n Nero_eth\n\nAh, I see what you mean and there is actually a 3rd part that the coinbase could sponsor:\n\nInclusion cost (delayed execution)\nInclusion cost + base fee (delayed execution + block base fee)\nInclusion cost + base fee + everything else (with only tx.value remaining)\n\nWhile directly going to block base fee sponsoring seems intriguing, it definitely brings additional complexity and a smoother rollup of the phases might be better.\n\nThis means that even though we COULD make the block’s coinbase base for underfunded transactions at execution, we don’t in the initial design. Besides the complexity it would increase the monetary requirement to local build (which might be fine though).\n\nHere, we would just stop executing and start skipping if the actual gas usage raises above the block gas limit during execution. For the inclusion cost is already paid at that point. The builder would lose the inclusion cost for the transaction that went over the block gas limit.\n\n post by thogard785 on Feb 12, 2025\n\n thogard785\n\nRight but you can’t stop executing because you haven’t started executing because this scenario is prevented from happening by checks that occur when the block is validated, which happens before the block is executed.\nYou can’t have the tx gas used go over the block gas limit because:\n\nthe tx gas reserved can’t go over the remaining block gas limit\nThe tx gas used can’t go over the tx gas reserved.\n\nIf either of those conditions did happen (although I don’t believe it does in the example we were looking it), it would invalidate the block… but the second condition is impossible to reach because it requires execution, which would never happen because the first condition would get caught in the validation (before execution) and the block would be invalid anyway and so there’d be nothing to execute.\nEdit: or are you saying the block builder could intentionally overpack the block and this would overflow the execution gas used, which would lead to a skip? In which case that would mean you’re removing check 1. (Prior paragraph) from the block validity requirements?\n\n post by Nero_eth on Feb 13, 2025\n\n Nero_eth\n\n There is no sum([tx.gas for tx in transactions]) check in the pre-execution validation. Where do you see what you describe in the specs?\n\nInitially, we only check that the transactions stay within the block gas limit using the inclusion gas, not the max possible (tx.gas)\n\nThen, when it comes to execution, we deduct the inclusion gas from the gas available:\n\nAnd here, during execution, we make sure every additional transaction, specified by its max gas, still fits into the block. If not, it is skipped (and pays for inclusion):\n\n post by thogard785 on Feb 13, 2025\n\n thogard785\n\n I see! Thank you for taking the time to walk me through that - my mental model was off.\nThat is so interesting that you kept the tx.gas < gas_available check but have it in the execution phase rather than the prevalidation phase.\nIs the rationale for doing it during execution (rather than earlier at prevalidation) that doing the check in execution lets you waste less space as the average |gas - gas_used| for txs in the block increases?\n\n 2 months later\n\n post by smartprogrammer on Apr 13, 2025\n\n smartprogrammer\n\n I am thinking maybe we can run tx validation logic (the logic that invalidate the whole block) in the current slot, and keep the rest of the full execution in the slot after. this way we remove the requirement for coinbase to front the base tx cost (21K) and the calldata fee.\n\n post by Nero_eth on Apr 14, 2025\n\n Nero_eth\n\nYeah right!\n\nCould you elaborate on that?\nThe validation logic under delayed exec is performed before attesting. If we want to accept transctions without executing, we can’t tell if the transations are actually executable. Therefore, we must charge someone beforehand, in case a transaction becomes “skipped”. In such cases, the coinbase could have prevented the skip by reording or not including that transaction, thus, it’s not the sender’s fault.\n\n post by smartprogrammer on Apr 14, 2025\n\n smartprogrammer\n\nthats true, coinbase fronting seems like the only solution right now.\n\n 18 days later\n\n post by kladkogex on May 2, 2025\n\n kladkogex\n\n We have this feature in our production blockchain—it definitely helps improve performance.\nAs mentioned above, all you need during the block proposal phase is to ensure that charges are applied to protect against DoS attacks. Everything else is not strictly necessary. The state root can be calculated after the fact, rather than beforehand.\n\n Powered by Discourse","tokens":4549,"squid":"ink-research","role":"Deep Scholar","at":1791259757716,"hash":"fc880bad1a96f47ca435c872fc076e27df18246f"}
{"url":"https://eips.ethereum.org/EIPS/eip-165","domain":"eips.ethereum.org","title":"ERC-165: Standard Interface Detection","text":"🎉 Final\n\n Standards Track: ERC\n\n ERC-165: Standard Interface Detection\n\n Authors\n Christian Reitwießner <chris@ethereum.org>, Nick Johnson <nick@ethereum.org>, Fabian Vogelsteller <fabian@lukso.network>, Jordi Baylina <jordi@baylina.cat>, Konrad Feldmeier <konrad.feldmeier@brainbot.com>, William Entriken <github.com@phor.net>\n\n Created\n 2018-01-23\n\n Requires\n\n EIP-214\n\n Simple Summary\n\nCreates a standard method to publish and detect what interfaces a smart contract implements.\n\n Abstract\n\nHerein, we standardize the following:\n\n How interfaces are identified\n How a contract will publish the interfaces it implements\n How to detect if a contract implements ERC-165\n How to detect if a contract implements any given interface\n\n Motivation\n\nFor some “standard interfaces” like the ERC-20 token interface, it is sometimes useful to query whether a contract supports the interface and if yes, which version of the interface, in order to adapt the way in which the contract is to be interacted with. Specifically for ERC-20, a version identifier has already been proposed. This proposal standardizes the concept of interfaces and standardizes the identification (naming) of interfaces.\n\n Specification\n\n How Interfaces are Identified\n\nFor this standard, an interface is a set of function selectors as defined by the Ethereum ABI. This a subset of Solidity’s concept of interfaces and the interface keyword definition which also defines return types, mutability and events.\n\nWe define the interface identifier as the XOR of all function selectors in the interface. This code example shows how to calculate an interface identifier:\n\npragma solidity ^0.4.20;\n\ninterface Solidity101 {\n function hello() external pure;\n function world(int) external pure;\n}\n\ncontract Selector {\n function calculateSelector() public pure returns (bytes4) {\n Solidity101 i;\n return i.hello.selector ^ i.world.selector;\n }\n}\n\nNote: interfaces do not permit optional functions, therefore, the interface identity will not include them.\n\n How a Contract will Publish the Interfaces it Implements\n\nA contract that is compliant with ERC-165 shall implement the following interface (referred as ERC165.sol):\n\npragma solidity ^0.4.20;\n\ninterface ERC165 {\n /// @notice Query if a contract implements an interface\n /// @param interfaceID The interface identifier, as specified in ERC-165\n /// @dev Interface identification is specified in ERC-165. This function\n /// uses less than 30,000 gas.\n /// @return `true` if the contract implements `interfaceID` and\n /// `interfaceID` is not 0xffffffff, `false` otherwise\n function supportsInterface(bytes4 interfaceID) external view returns (bool);\n}\n\nThe interface identifier for this interface is 0x01ffc9a7. You can calculate this by running bytes4(keccak256('supportsInterface(bytes4)')); or using the Selector contract above.\n\nTherefore the implementing contract will have a supportsInterface function that returns:\n\n true when interfaceID is 0x01ffc9a7 (EIP165 interface)\n false when interfaceID is 0xffffffff\n true for any other interfaceID this contract implements\n false for any other interfaceID\n\nThis function must return a bool and use at most 30,000 gas.\n\nImplementation note, there are several logical ways to implement this function. Please see the example implementations and the discussion on gas usage.\n\n How to Detect if a Contract Implements ERC-165\n\n The source contract makes a STATICCALL to the destination address with input data: 0x01ffc9a701ffc9a700000000000000000000000000000000000000000000000000000000 and gas 30,000. This corresponds to contract.supportsInterface(0x01ffc9a7).\n If the call fails or return false, the destination contract does not implement ERC-165.\n If the call returns true, a second call is made with input data 0x01ffc9a7ffffffff00000000000000000000000000000000000000000000000000000000.\n If the second call fails or returns true, the destination contract does not implement ERC-165.\n Otherwise it implements ERC-165.\n\n How to Detect if a Contract Implements any Given Interface\n\n If you are not sure if the contract implements ERC-165, use the above procedure to confirm.\n If it does not implement ERC-165, then you will have to see what methods it uses the old-fashioned way.\n If it implements ERC-165 then just call supportsInterface(interfaceID) to determine if it implements an interface you can use.\n\n Rationale\n\nWe tried to keep this specification as simple as possible. This implementation is also compatible with the current Solidity version.\n\n Backwards Compatibility\n\nThe mechanism described above (with 0xffffffff) should work with most of the contracts previous to this standard to determine that they do not implement ERC-165.\n\nAlso the ENS already implements this EIP.\n\n Test Cases\n\nFollowing is a contract that detects which interfaces other contracts implement. From @fulldecent and @jbaylina.\n\npragma solidity ^0.4.20;\n\ncontract ERC165Query {\n bytes4 constant InvalidID = 0xffffffff;\n bytes4 constant ERC165ID = 0x01ffc9a7;\n\n function doesContractImplementInterface(address _contract, bytes4 _interfaceId) external view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = noThrowCall(_contract, ERC165ID);\n if ((success==0)||(result==0)) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, InvalidID);\n if ((success==0)||(result!=0)) {\n return false;\n }\n\n (success, result) = noThrowCall(_contract, _interfaceId);\n if ((success==1)&&(result==1)) {\n return true;\n }\n return false;\n }\n\n function noThrowCall(address _contract, bytes4 _interfaceId) constant internal returns (uint256 success, uint256 result) {\n bytes4 erc165ID = ERC165ID;\n\n assembly {\n let x := mload(0x40) // Find empty storage location using \"free memory pointer\"\n mstore(x, erc165ID) // Place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceId) // Place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // To addr\n x, // Inputs are stored at location x\n 0x24, // Inputs are 36 bytes long\n x, // Store output over input (saves space)\n 0x20) // Outputs are 32 bytes long\n\n result := mload(x) // Load the result\n }\n }\n}\n\n Implementation\n\nThis approach uses a view function implementation of supportsInterface. The execution cost is 586 gas for any input. But contract initialization requires storing each interface (SSTORE is 20,000 gas). The ERC165MappingImplementation contract is generic and reusable.\n\npragma solidity ^0.4.20;\n\nimport \"./ERC165.sol\";\n\ncontract ERC165MappingImplementation is ERC165 {\n /// @dev You must not set element 0xffffffff to true\n mapping(bytes4 => bool) internal supportedInterfaces;\n\n function ERC165MappingImplementation() internal {\n supportedInterfaces[this.supportsInterface.selector] = true;\n }\n\n function supportsInterface(bytes4 interfaceID) external view returns (bool) {\n return supportedInterfaces[interfaceID];\n }\n}\n\ninterface Simpson {\n function is2D() external returns (bool);\n function skinColor() external returns (string);\n}\n\ncontract Lisa is ERC165MappingImplementation, Simpson {\n function Lisa() public {\n supportedInterfaces[this.is2D.selector ^ this.skinColor.selector] = true;\n }\n\n function is2D() external returns (bool){}\n function skinColor() external returns (string){}\n}\n\nFollowing is a pure function implementation of supportsInterface. The worst-case execution cost is 236 gas, but increases linearly with a higher number of supported interfaces.\n\npragma solidity ^0.4.20;\n\nimport \"./ERC165.sol\";\n\ninterface Simpson {\n function is2D() external returns (bool);\n function skinColor() external returns (string);\n}\n\ncontract Homer is ERC165, Simpson {\n function supportsInterface(bytes4 interfaceID) external view returns (bool) {\n return\n interfaceID == this.supportsInterface.selector || // ERC165\n interfaceID == this.is2D.selector\n ^ this.skinColor.selector; // Simpson\n }\n\n function is2D() external returns (bool){}\n function skinColor() external returns (string){}\n}\n\nWith three or more supported interfaces (including ERC165 itself as a required supported interface), the mapping approach (in every case) costs less gas than the pure approach (at worst case).\n\n Version history\n\n PR 1640, finalized 2019-01-23 – This corrects the noThrowCall test case to use 36 bytes rather than the previous 32 bytes. The previous code was an error that still silently worked in Solidity 0.4.x but which was broken by new behavior introduced in Solidity 0.5.0. This change was discussed at #1640.\n\n EIP 165, finalized 2018-04-20 – Original published version.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Christian Reitwießner <chris@ethereum.org>, Nick Johnson <nick@ethereum.org>, Fabian Vogelsteller <fabian@lukso.network>, Jordi Baylina <jordi@baylina.cat>, Konrad Feldmeier <konrad.feldmeier@brainbot.com>, William Entriken <github.com@phor.net>, \"ERC-165: Standard Interface Detection,\" Ethereum Improvement Proposals, no. 165, January 2018. Available: https://eips.ethereum.org/EIPS/eip-165.","tokens":2263,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259757757,"hash":"0a4d8d237f9676beedbc30bb63b30c8bb51ba0e6"}
{"url":"https://docs.openzeppelin.com/monitor/1.3.x/quickstart","domain":"docs.openzeppelin.com","title":"Quick Start Guide | OpenZeppelin Docs","text":"MonitorQuick Start GuideOpen in ClaudeOpenZeppelin Monitor is a powerful tool for monitoring blockchain events and transactions. This guide will help you get up and running quickly with practical examples for both EVM and Stellar networks.\nWhat You'll Learn\n\nHow to set up OpenZeppelin Monitor locally or with Docker\nHow to configure monitoring for USDC transfers on Ethereum\nHow to monitor DEX swaps on Stellar\nHow to set up notifications via Slack and email\n\nPrerequisites\nBefore you begin, ensure you have the following installed:\n\nRust 2024 edition - Required for building from source\nDocker - Optional, for containerized deployment\nGit - For cloning the repository\nPython 3.11 (3.10+) - For pre-commit hooks; we recommend pyenv for version management (see Contribution guidelines)\n\nIf you don’t have Rust installed, visit https://rustup.rs/ to install it.\nSystem Dependencies (Linux)\nFor Ubuntu 22.04+ or Debian-based systems (both x86 and ARM64 architectures), install required packages:\nNote: Python 3.11 is recommended; 3.10+ is the minimum for pre-commit hooks.\n# Install required packages directly\nsudo apt update\nsudo apt install -y \\\n build-essential \\\n curl \\\n git \\\n pkg-config \\\n libssl-dev \\\n libffi-dev \\\n libyaml-dev \\\n python3 \\\n python3-venv \\\n python3-pip\nOr use the provided system package script:\nchmod +x ./scripts/linux/sys_pkgs_dev.sh\n./scripts/linux/sys_pkgs_dev.sh # For Python/dev dependencies (includes runtime deps)\n# Or, for runtime-only (no Python/dev tools): ./scripts/linux/sys_pkgs_core.sh\nQuick Setup Options\nWe provide two setup paths to get you started:\nOption 1: Automated Setup (Recommended)\nFor the fastest setup experience, use our automated script that handles everything for you.\nWhat the Automated Setup Does\nThe setup_and_run.sh script provides a complete solution that:\n\nBuilds the monitor application from source\nCopies example configurations from examples/ to config/\n\nNetwork configurations for major blockchains\nPre-configured monitor examples (USDC transfers, Stellar DEX swaps)\nRequired filter scripts and basic trigger notifications\n\nValidates all configurations to ensure proper setup\nOptionally runs the monitor to verify everything works\n\nRunning the Automated Setup\n\nClone the repository:\ngit clone https://github.com/openzeppelin/openzeppelin-monitor\ncd openzeppelin-monitor\n\nMake the script executable:\nchmod +x setup_and_run.sh\n\nRun the automated setup:\n./setup_and_run.sh\n\nThe script provides colored output and clear guidance throughout the process.\nAfter Automated Setup\nOnce complete, you’ll have:\n\nA fully built OpenZeppelin Monitor\nExample configurations ready for customization\nClear guidance on next steps\n\nNext Steps:\n. Customize the copied configurations in config/ directories\n. Update RPC URLs and notification credentials\n. Run the monitor with ./openzeppelin-monitor\nThe setup script creates working configurations with placeholder values. Remember to update your files with actual RPC endpoints and notification credentials before starting real monitoring.\nOption 2: Manual Setup\nFor users who prefer more control over the setup process.\nBuilding from Source\n\nClone and build:\ngit clone https://github.com/openzeppelin/openzeppelin-monitor\ncd openzeppelin-monitor\ncargo build --release\n\nMove the binary to project root:\nmv ./target/release/openzeppelin-monitor .\n\nDocker Setup\nFor containerized deployment:\n\nStart services:\ndocker compose up\n\nBy default, Docker Compose uses Dockerfile.development. For production, set:\nDOCKERFILE=Dockerfile.production before running the command.\nDocker Management Commands\nCommandDescriptiondocker ps -aVerify container statusdocker compose downStop services (without metrics)docker compose --profile metrics downStop services (with metrics)docker compose logs -fView logs (follow mode)\nEnvironment Configuration\nLogging Configuration\nConfigure logging verbosity by setting the RUST_LOG environment variable:\nLevelDescriptionerrorOnly error messageswarnWarnings and errorsinfoGeneral information (recommended)debugDetailed debugging informationtraceVery detailed trace information\nexport RUST_LOG=info\nLocal Configuration\nCopy the example environment file and customize it:\ncp .env.example .env\nFor detailed configuration options, see Basic Configuration.\nPractical Examples\nNow let’s set up real monitoring scenarios. Choose the example that matches your needs:\nExample 1: Monitor USDC Transfers (Ethereum)\nThis example monitors large USDC transfers on Ethereum mainnet and sends notifications when transfers exceed 10,000 USDC.\nStep 1: Network Configuration\nCreate the Ethereum mainnet configuration:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/networks/ethereum_mainnet.json config/networks/ethereum_mainnet.json\nKey Configuration Details:\n{\n \"network_type\": \"EVM\",\n \"slug\": \"ethereum_mainnet\",\n \"name\": \"Ethereum Mainnet\",\n \"rpc_urls\": [\n {\n \"type_\": \"rpc\",\n \"url\": {\n \"type\": \"plain\",\n \"value\": \"YOUR_RPC_URL_HERE\"\n },\n \"weight\": 100\n }\n ],\n \"chain_id\": 1,\n \"block_time_ms\": 12000,\n \"confirmation_blocks\": 12,\n \"cron_schedule\": \"0 */1 * * * *\",\n \"max_past_blocks\": 18,\n \"store_blocks\": false\n}\nImportant: Replace YOUR_RPC_URL_HERE with your actual Ethereum RPC endpoint. You can use providers like Infura, Alchemy, or run your own node.\nStep 2: Monitor Configuration\nSet up the USDC transfer monitor:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/monitors/evm_transfer_usdc.json config/monitors/evm_transfer_usdc.json\ncp examples/config/filters/evm_filter_block_number.sh config/filters/evm_filter_block_number.sh\nMonitor Configuration Overview:\n{\n \"name\": \"Large Transfer of USDC Token\",\n \"paused\": false,\n \"networks\": [\"ethereum_mainnet\"],\n \"addresses\": [\n {\n \"address\": \"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48\",\n \"contract_spec\": [\n {\n \"anonymous\": false,\n \"inputs\": [\n {\n \"indexed\": true,\n \"internalType\": \"address\",\n \"name\": \"from\",\n \"type\": \"address\"\n },\n {\n \"indexed\": true,\n \"internalType\": \"address\",\n \"name\": \"to\",\n \"type\": \"address\"\n },\n {\n \"indexed\": false,\n \"internalType\": \"uint256\",\n \"name\": \"value\",\n \"type\": \"uint256\"\n }\n ],\n \"name\": \"Transfer\",\n \"type\": \"event\"\n }\n ]\n }\n ],\n \"match_conditions\": {\n \"functions\": [],\n \"events\": [\n {\n \"signature\": \"Transfer(address,address,uint256)\",\n \"expression\": \"value > 10000000000\"\n }\n ],\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": null\n }\n ]\n },\n \"trigger_conditions\": [\n {\n \"script_path\": \"./config/filters/evm_filter_block_number.sh\",\n \"language\": \"bash\",\n \"arguments\": [\"--verbose\"],\n \"timeout_ms\": 1000\n }\n ],\n \"triggers\": [\"evm_large_transfer_usdc_slack\", \"evm_large_transfer_usdc_email\"]\n}\n\nThe expression: \"value > 10000000000\" monitors transfers over 10,000 USDC (USDC has 6 decimals)\nRemove the trigger_conditions array to disable additional filtering\nThe USDC contract address 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 is the official USDC contract on Ethereum mainnet\n\nStep 3: Notification Setup\nSlack Notifications\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/triggers/slack_notifications.json config/triggers/slack_notifications.json\nSlack Configuration:\n{\n \"evm_large_transfer_usdc_slack\": {\n \"name\": \"Large Transfer Slack Notification\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\n \"type\": \"plain\",\n \"value\": \"SLACK_WEBHOOK_URL\"\n },\n \"message\": {\n \"title\": \"large_transfer_slack triggered\",\n \"body\": \"Large transfer of ${events.0.args.value} USDC from ${events.0.args.from} to ${events.0.args.to} | https://etherscan.io/tx/${transaction.hash}#eventlog\"\n }\n }\n }\n}\nTo get a Slack webhook URL:\n\nGo to https://api.slack.com/apps\nCreate a new app or select existing one\nEnable \"Incoming Webhooks\"\nCreate a webhook for your channel\n\nEmail Notifications\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/triggers/email_notifications.json config/triggers/email_notifications.json\nEmail Configuration:\n{\n \"evm_large_transfer_usdc_email\": {\n \"name\": \"Large Transfer Email Notification\",\n \"trigger_type\": \"email\",\n \"config\": {\n \"host\": \"smtp.gmail.com\",\n \"port\": 465,\n \"username\": {\n \"type\": \"plain\",\n \"value\": \"your_email@gmail.com\"\n },\n \"password\": {\n \"type\": \"plain\",\n \"value\": \"SMTP_PASSWORD\"\n },\n \"message\": {\n \"title\": \"large_transfer_usdc_email triggered\",\n \"body\": \"Large transfer of ${events.0.args.value} USDC from ${events.0.args.from} to ${events.0.args.to} | https://etherscan.io/tx/${transaction.hash}#eventlog\"\n },\n \"sender\": \"your_email@gmail.com\",\n \"recipients\": [\n \"recipient1@example.com\",\n \"recipient2@example.com\"\n ]\n }\n }\n}\nFor Gmail, you’ll need to use an \"App Password\" instead of your regular password. Enable 2FA and generate an app password in your Google Account settings.\nStep 4: Run the Monitor\nLocal Deployment:\n./openzeppelin-monitor\nDocker Deployment:\ncargo make docker-compose-up\nWhat Happens Next\nOnce running, the monitor will:\n\nCheck for new Ethereum blocks every minute\nWatch for USDC transfers over 10,000 USDC\nSend notifications via Slack and email when large transfers occur\n\nCustomization Options\n\nAdjust threshold: Modify \"value > 10000000000\" to change the minimum transfer amount\nMonitor other tokens: Create new monitor configurations for different ERC20 tokens\nAdd more networks: Configure additional EVM networks (Polygon, BSC, etc.)\n\nExample 2: Monitor DEX Swaps (Stellar)\nThis example monitors large DEX swaps on Stellar mainnet.\nStep 1: Network Configuration\nCreate the Stellar mainnet configuration:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/networks/stellar_mainnet.json config/networks/stellar_mainnet.json\nKey Configuration Details:\n{\n \"network_type\": \"Stellar\",\n \"slug\": \"stellar_mainnet\",\n \"name\": \"Stellar Mainnet\",\n \"rpc_urls\": [\n {\n \"type_\": \"rpc\",\n \"url\": {\n \"type\": \"plain\",\n \"value\": \"YOUR_RPC_URL_HERE\"\n },\n \"weight\": 100\n }\n ],\n \"network_passphrase\": \"Public Global Stellar Network ; September 2015\",\n \"block_time_ms\": 5000,\n \"confirmation_blocks\": 2,\n \"cron_schedule\": \"0 */1 * * * *\",\n \"max_past_blocks\": 20,\n \"store_blocks\": true\n}\nStep 2: Monitor Configuration\nSet up the DEX swap monitor:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/monitors/stellar_swap_dex.json config/monitors/stellar_swap_dex.json\ncp examples/config/filters/stellar_filter_block_number.sh config/filters/stellar_filter_block_number.sh\nMonitor Configuration Overview:\n{\n \"name\": \"Large Swap By Dex\",\n \"paused\": false,\n \"networks\": [\"stellar_mainnet\"],\n \"addresses\": [\n {\n \"address\": \"CA6PUJLBYKZKUEKLZJMKBZLEKP2OTHANDEOWSFF44FTSYLKQPIICCJBE\",\n \"contract_spec\": [\n {\n \"function_v0\": {\n \"doc\": \"\",\n \"name\": \"swap\",\n \"inputs\": [\n {\n \"doc\": \"\",\n \"name\": \"user\",\n \"type_\": \"address\"\n },\n {\n \"doc\": \"\",\n \"name\": \"in_idx\",\n \"type_\": \"u32\"\n },\n {\n \"doc\": \"\",\n \"name\": \"out_idx\",\n \"type_\": \"u32\"\n },\n {\n \"doc\": \"\",\n \"name\": \"in_amount\",\n \"type_\": \"u128\"\n },\n {\n \"doc\": \"\",\n \"name\": \"out_min\",\n \"type_\": \"u128\"\n }\n ],\n \"outputs\": [\"u128\"]\n }\n }\n ]\n }\n ],\n \"match_conditions\": {\n \"functions\": [\n {\n \"signature\": \"swap(Address,U32,U32,U128,U128)\",\n \"expression\": \"out_min > 1000000000\"\n }\n ],\n \"events\": [],\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": null\n }\n ]\n },\n \"trigger_conditions\": [\n {\n \"script_path\": \"./config/filters/stellar_filter_block_number.sh\",\n \"language\": \"bash\",\n \"arguments\": [\"--verbose\"],\n \"timeout_ms\": 1000\n }\n ],\n \"triggers\": [\"stellar_large_swap_by_dex_slack\"]\n}\n\nThe contract_spec field is optional for Stellar contracts. If not provided, the monitor automatically fetches the contract’s SEP-48 interface from the chain\nYou can explore Stellar contract interfaces using the Stellar Contract Explorer\nThe expression \"out_min > 1000000000\" monitors swaps with minimum output over 1 billion tokens\nNow, you can also filter by parameters event’s name (Stellar Protocol 23 has introduced this new feature). See this section for more details\n\nStep 3: Notification Setup\nSet up Slack notifications for Stellar swaps:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/triggers/slack_notifications.json config/triggers/slack_notifications.json\nSlack Configuration:\n{\n \"stellar_large_swap_by_dex_slack\": {\n \"name\": \"Large Swap By Dex Slack Notification\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\n \"type\": \"plain\",\n \"value\": \"slack-webhook-url\"\n },\n \"message\": {\n \"title\": \"large_swap_by_dex_slack triggered\",\n \"body\": \"${monitor.name} triggered because of a large swap of ${functions.0.args.out_min} tokens | https://stellar.expert/explorer/public/tx/${transaction.hash}\"\n }\n }\n }\n}\n\nIf you want to include event details in the notification message body, you can also access event parameters by name. Here’s an example:\n\n\"body\": \"${monitor.name} triggered because of a large swap from ${events.0.args.from} tokens | https://stellar.expert/explorer/public/tx/${transaction.hash}\"\nStep 4: Run the Monitor\nLocal Deployment:\n./openzeppelin-monitor\nDocker Deployment:\ncargo make docker-compose-up\nWhat Happens Next\nOnce running, the monitor will:\n\nCheck for new Stellar blocks every minute\nWatch for large DEX swaps\nSend notifications via Slack when large swaps occur\n\nExample 3: Monitoring Bulletin Post (Midnight):\nStep 1: Network Configuration\nCreate the Midnight testnet network configuration:\ncp examples/config/networks/examples/midnight_testnet.json config/networks/midnight_testnet.json\nThe link:https://github.com/OpenZeppelin/openzeppelin-monitor/blob/main/examples/config/networks/midnight_testnet.json[default configuration^] should work, but you may want to update the RPC URL to your preferred provider.\n{\n \"network_type\": \"Midnight\",\n \"slug\": \"midnight_testnet\",\n \"name\": \"Midnight Testnet\",\n \"rpc_urls\": [\n {\n \"type_\": \"ws_rpc\",\n \"url\": {\n \"type\": \"plain\",\n \"value\": \"YOUR_WSS_RPC_URL_HERE\"\n },\n \"weight\": 100\n }\n ],\n \"chain_id\": 0,\n \"block_time_ms\": 6000,\n \"confirmation_blocks\": 2,\n \"cron_schedule\": \"0 */1 * * * *\",\n \"max_past_blocks\": 13,\n \"store_blocks\": false\n}\nA websocket RPC URL (wss://) is required in the network configuration for Midnight networks. This is because transaction status information is retrieved through Substrate events, which are only available via websocket connections.\nStep 2: Monitor Configuration:\nCreate the bulletin board post monitor configuration:\ncp examples/config/monitors/midnight_testnet_bulletin_post.json config/monitors/midnight_testnet_bulletin_post.json\nThis link:https://github.com/OpenZeppelin/openzeppelin-monitor/blob/main/examples/config/monitors/midnight_testnet_bulletin_post.json[configuration^] monitors post transactions to a specific bulletin board contract. You can customize the notification channels by modifying the triggers array.\n{\n \"name\": \"Bulletin post\",\n \"paused\": false,\n \"networks\": [\n \"midnight_testnet\"\n ],\n \"addresses\": [\n {\n \"address\": \"020200048fe17c5b2ae77e7154ff983dc37f18736a61aaef774c7a997935e84abe8361\"\n }\n ],\n \"match_conditions\": {\n \"functions\": [\n {\n \"signature\": \"post()\",\n \"expression\": null\n }\n ],\n \"events\": [],\n \"transactions\": [\n {\n \"status\": \"Any\",\n \"expression\": null\n }\n ]\n },\n \"trigger_conditions\": [],\n \"triggers\": [\n \"midnight_bulletin_post_slack\"\n ]\n}\n\nEvent monitoring is currently not supported\nDue to the privacy-focused design of the network:\n** Transaction details cannot be monitored (except for transaction status)\n** Function and event arguments cannot be monitored\nFunction signatures are simplified:\n** All argument variations are treated identically. For example post, post(), and post(x, y, z) are equivalent\n\nStep 3: Notification Configuration:\nFor Slack Notifications:\ncp examples/config/triggers/slack_notifications.json config/triggers/slack_notifications.json\nUpdate the webhook URL in the link:https://github.com/OpenZeppelin/openzeppelin-monitor/blob/main/examples/config/triggers/slack_notifications.json[configuration^].\n{\n \"midnight_bulletin_post_slack\": {\n \"name\": \"Bulletin Post Slack Notification\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\n \"type\": \"plain\",\n \"value\": \"https://hooks.slack.com/services/A/B/C\"\n },\n \"message\": {\n \"title\": \"midnight_bulletin_post_slack triggered\",\n \"body\": \"A call to ${functions.0.signature} was made to the bulletin board | ${transaction.hash}\"\n }\n }\n }\n}\nStep 4: Run the Monitor:\nLocal Deployment\n./openzeppelin-monitor\nDocker Deployment\n----\ncargo make docker-compose-up\nThe monitor will now:\n\nCheck for new Midnight blocks every minute.\nWatch for post calls to a bulletin board contract.\nSend notifications via Slack when a new post occurs.\n\nExample 4: Monitor Kamino Deposits (Solana)\nThis example monitors deposit events on the Kamino lending protocol on Solana mainnet.\nStep 1: Network Configuration\nCreate the Solana mainnet configuration:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/networks/solana_mainnet.json config/networks/solana_mainnet.json\nNote: The example uses Solana's public RPC endpoint for demonstration. For production monitoring, use a dedicated RPC provider (Alchemy, QuickNode, Helius, or self-hosted) to avoid rate limiting.\nKey Configuration Details:\n{\n \"network_type\": \"Solana\",\n \"slug\": \"solana_mainnet\",\n \"name\": \"Solana Mainnet\",\n \"rpc_urls\": [\n {\n \"type_\": \"rpc\",\n \"url\": {\n \"type\": \"plain\",\n \"value\": \"YOUR_RPC_URL_HERE\"\n },\n \"weight\": 100\n }\n ],\n \"block_time_ms\": 400,\n \"confirmation_blocks\": 32,\n \"cron_schedule\": \"*/10 * * * * *\",\n \"max_past_blocks\": 100,\n \"store_blocks\": false\n}\nStep 2: Monitor Configuration\nSet up the Kamino deposit monitor:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/monitors/solana_kamino_deposit.json config/monitors/solana_kamino_deposit.json\nMonitor Configuration Overview:\n{\n \"name\": \"Solana Kamino Deposit Monitor\",\n \"paused\": false,\n \"networks\": [\"solana_mainnet\"],\n \"addresses\": [\n {\n \"address\": \"KLend2g3cP87fffoy8q1mQqGKjrxjC8boSyAYavgmjD\",\n \"contract_spec\": []\n }\n ],\n \"match_conditions\": {\n \"functions\": [],\n \"events\": [\n {\n \"signature\": \"Deposit\",\n \"expression\": null\n }\n ],\n \"transactions\": [\n {\n \"status\": \"Success\",\n \"expression\": null\n }\n ]\n },\n \"trigger_conditions\": [],\n \"triggers\": [\"solana_kamino_deposit_slack\"]\n}\n\nSolana event signatures use just the event name (e.g., Deposit) without parameters\nThe address KLend2g3cP87fffoy8q1mQqGKjrxjC8boSyAYavgmjD is the Kamino lending program on Solana mainnet\nThe contract_spec field is optional for Solana programs\n\nStep 3: Notification Setup\nSet up Slack notifications for Kamino deposits:\n# Only necessary if you haven't already run the automated setup script (Option 1: Automated Setup)\ncp examples/config/triggers/slack_notifications.json config/triggers/slack_notifications.json\nSlack Configuration:\n{\n \"solana_kamino_deposit_slack\": {\n \"name\": \"Kamino Deposit Slack Notification\",\n \"trigger_type\": \"slack\",\n \"config\": {\n \"slack_url\": {\n \"type\": \"plain\",\n \"value\": \"slack-webhook-url\"\n },\n \"message\": {\n \"title\": \"solana_kamino_deposit_slack triggered\",\n \"body\": \"A new deposit was made on Kamino | https://solscan.io/tx/${transaction.signature}\"\n }\n }\n }\n}\nStep 4: Run the Monitor\nLocal Deployment:\n./openzeppelin-monitor\nDocker Deployment:\ncargo make docker-compose-up\nWhat Happens Next\nOnce running, the monitor will:\n\nCheck for new Solana blocks every 10 seconds\nWatch for Deposit events on the Kamino lending program\nSend notifications via Slack when deposits occur\n\nNext Steps\nNow that you have OpenZeppelin Monitor running, here are some suggestions for what to do next:\nLocal EVM Testing\nTo iterate on monitor behavior without using public testnets, you can run a local EVM node with Foundry and point the monitor at it. See Local EVM Testing for setup, deployment, and triggering conditions.\nTesting and Validation\n\nTest your configuration against specific block numbers\nVerify your RPC endpoints are working correctly\nTest notification channels with small transactions\n\nSecurity and Best Practices\n\nConfigure secure secret management for sensitive data\nUse environment variables or Hashicorp Cloud Vault for credentials\nRegularly update your RPC endpoints and monitor configurations\n\nAdvanced Configuration\n\nExplore additional examples in the examples/config/monitors directory\nSet up monitoring for multiple networks simultaneously\nConfigure custom filter scripts for complex conditions\n\nGetting Help\n\nCheck the GitHub Issues for known problems\nReview the User Documentation for detailed configuration options\nJoin the OpenZeppelin community for support\n\nStart with simple monitoring scenarios and gradually add complexity. This helps you understand how the system works and makes troubleshooting easier.OverviewPrevious PageArchitecture GuideNext PageOn this pageWhat You'll LearnPrerequisitesSystem Dependencies (Linux)Quick Setup OptionsOption 1: Automated Setup (Recommended)What the Automated Setup DoesRunning the Automated SetupAfter Automated SetupOption 2: Manual SetupBuilding from SourceDocker SetupDocker Management CommandsEnvironment ConfigurationLogging ConfigurationLocal ConfigurationPractical ExamplesExample 1: Monitor USDC Transfers (Ethereum)Step 1: Network ConfigurationStep 2: Monitor ConfigurationStep 3: Notification SetupSlack NotificationsEmail NotificationsStep 4: Run the MonitorWhat Happens NextCustomization OptionsExample 2: Monitor DEX Swaps (Stellar)Step 1: Network ConfigurationStep 2: Monitor ConfigurationStep 3: Notification SetupStep 4: Run the MonitorWhat Happens NextExample 3: Monitoring Bulletin Post (Midnight):Step 1: Network ConfigurationStep 2: Monitor Configuration:Step 3: Notification Configuration:For Slack Notifications:Step 4: Run the Monitor:Example 4: Monitor Kamino Deposits (Solana)Step 1: Network ConfigurationStep 2: Monitor ConfigurationStep 3: Notification SetupStep 4: Run the MonitorWhat Happens NextNext StepsLocal EVM TestingTesting and ValidationSecurity and Best PracticesAdvanced ConfigurationGetting Help","tokens":5558,"squid":"ink-security_audits","role":"Sentinel","at":1791259772979,"hash":"57e71c287f91e449b6a434763f4faefa3f39ca69"}
{"url":"https://docs.pyth.network/entropy/fees","domain":"docs.pyth.network","title":"Fees | Pyth Developer Hub","text":"FeesUnderstanding Pyth Entropy fee structureThe Entropy protocol has been designed to charge fees on a per-request basis. The total fee is\nthe sum of the provider fee, which is determined by the individual provider on a per-blockchain\nbasis, and the protocol fee, which is subject to Pyth governance decisions also on a per-chain\nbasis. These are accessible via the smart contract functions.\nProviders can withdraw their fees from the contract whenever they want. The allocation of the fees collected by the Entropy protocol\nis governed by the collective decisions of its governance body. All fees are denominated in the native token\nof the respective blockchain, ensuring a seamless and integrated operation.\nNote that protocols integrating with Entropy can pass these fees along to their users. Whenever a user\nsubmits a transaction that requests a random number, the user can directly pay the entropy fees required\nwith the native blockchain token. There are no fees for revealing the random numbers.\nYou can check the current fees in the chainlist and fee details page for each blockchain.Protocol DesignUnderstanding how Pyth Entropy generates secure random numbers","tokens":293,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259773875,"hash":"54c51398ae7fd509a077e25ea77768a4f01e382f"}
{"url":"https://docs.pyth.network/entropy/request-callback-variants","domain":"docs.pyth.network","title":"Request Callback Variants | Pyth Developer Hub","text":"Request Callback VariantsDifferent ways to request random numbers with Pyth EntropyThe IEntropyV2 interface provides multiple variants of the requestV2 function:\n1. Basic request\nfunction requestV2() external payable returns (uint64 assignedSequenceNumber);\nThis is the simplest variant that requests entropy using the default provider and default gas settings. Uses in-contract PRNG for the user contribution to randomness.\nUse this when you want the most straightforward implementation and don't need to customize provider or gas parameters.\nExample\nfunction requestBasicRandomNumber() external payable {\n // Get the fee for the default provider and gas limit\n uint256 fee = entropy.getFeeV2();\n\n require(msg.value >= fee, \"Insufficient fee\");\n\n // Request randomness with default settings\n uint64 sequenceNumber = entropy.requestV2{value: fee}();\n}\n2. Request with custom gas limit\nfunction requestV2(\n uint32 gasLimit\n) external payable returns (uint64 assignedSequenceNumber);\nThis variant allows you to specify a custom gas limit for the callback function execution. Uses in-contract PRNG for the user contribution.\nUse this when your entropyCallback function has complex logic that requires more gas than the default amount, or when you want to optimize gas usage by setting a lower limit for simple callbacks.\nExample\nfunction requestWithCustomGas() external payable {\n uint32 customGasLimit = 150000; // Custom gas limit for callback\n\n // Get fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n require(msg.value >= fee, \"Insufficient fee\");\n\n // Request with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{value: fee}(customGasLimit);\n}\n3. Request with custom provider\nfunction requestV2(\n address provider\n) external payable returns (uint64 assignedSequenceNumber);\nThis variant allows you to specify a custom entropy provider instead of using the default one.\n4. Full custom request\nfunction requestV2(\n address provider,\n bytes32 userRandomNumber,\n uint32 gasLimit\n) external payable returns (uint64 assignedSequenceNumber);\nThis is the most flexible variant that allows you to specify all parameters: custom provider, custom gas limit, and user random number.Chainlist and Fee DetailsPyth Entropy contract addresses on EVM networksError CodesOn chain error codes from the Pyth Entropy EVM contracts","tokens":588,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259783191,"hash":"2078d6da454ef14ffb386333a05ea6af6961965a"}
{"url":"https://docs.openzeppelin.com/relayer/1.5.x","domain":"docs.openzeppelin.com","title":"OpenZeppelin Relayer | OpenZeppelin Docs","text":"OpenZeppelin RelayerOpen in ClaudeOverview\nOpenZeppelin Relayer is a service that provides infrastructure to relay transactions to the EVM & Non-EVM networks. It is designed to be used as a backend for dApps that need to interact with these networks.\nFeatures\n\nMulti-Chain Support: Interact with multiple blockchain networks, including Solana and EVM-based chains.\nTransaction Relaying: Submit transactions to supported blockchain networks efficiently.\nTransaction Signing: Securely sign transactions using configurable key management.\nTransaction Fee Estimation: Estimate transaction fees for better cost management.\nSolana Gasless Transactions: Support for gasless transactions on Solana, enabling users to interact without transaction fees.\nStellar Gasless/Sponsored Transactions: Support for sponsored transactions on Stellar, enabling users to pay fees in tokens (e.g., USDC) instead of native XLM.\nTransaction Nonce Management: Handle nonce management to ensure transaction order.\nTransaction Status Monitoring: Track the status of submitted transactions.\nSDK Integration: Easily interact with the relayer through our companion JavaScript/TypeScript SDK.\nExtensible Architecture: Easily add support for new blockchain networks.\nConfigurable Network Policies: Define and enforce network-specific policies for transaction processing.\nMetrics and Observability: Monitor application performance using Prometheus and Grafana.\nDocker Support: Deploy the relayer using Docker for both development and production environments.\nPlugins: Extend the functionality of the relayer with custom logic using TypeScript functions.\n\nSupported Networks\nOpenZeppelin Relayer supports multiple blockchain networks through a flexible JSON-based configuration system. Networks are defined in configuration files, allowing you to configure:\n\nAny EVM-compatible network (Ethereum, Polygon, BSC, Arbitrum, Optimism, etc.)\nSolana networks (mainnet-beta, devnet, testnet, custom RPC endpoints)\nStellar networks (Pubnet, Testnet, custom networks)\nCreate custom network configurations with specific RPC endpoints, chain IDs, and network parameters\nUse inheritance to create network variants that inherit from base configurations\n\nNetwork Types\nNetwork TypeDescriptionevmEthereum Virtual Machine compatible networks. Supports any EVM chain by configuring chain ID, RPC URLs, and network-specific parameters.solanaSolana blockchain networks. Supports all Solana clusters and custom RPC endpoints.stellarStellar blockchain networks (Partial support). Supports Stellar Public Network and Testnet.\nNetworks can be loaded from:\n\nJSON arrays: Direct network definitions in configuration files\nDirectory of files: Multiple JSON files each containing network definitions\n\nFor detailed network configuration options and examples, see the Network Configuration page.\nFor information about our development plans and upcoming features, see Project Roadmap.\nTo get started immediately, see Quickstart.\nTechnical Overview\n\nProject Structure\nThe project follows a standard Rust project layout:\nopenzeppelin-relayer/\n├── src/\n│ ├── api/ # Route and controllers logic\n│ ├── bootstrap/ # Service initialization logic\n│ ├── config/ # Configuration logic\n│ ├── constants/ # Constant values used in the system\n│ ├── domain/ # Domain logic\n│ ├── jobs/ # Asynchronous processing logic (queueing)\n│ ├── logging/ # Logs File rotation logic\n│ ├── metrics/ # Metrics logic\n│ ├── models/ # Data structures and types\n│ ├── repositories/ # Configuration storage\n│ ├── services/ # Services logic\n│ └── utils/ # Helper functions\n│\n├── config/ # Configuration files\n├── tests/ # Integration tests\n├── docs/ # Documentation\n├── scripts/ # Utility scripts\n├── examples/ # Configuration examples\n├── helpers/ # Rust helper scripts\n├── plugins/ # Plugins directory\n└── ... other root files (Cargo.toml, README.md, etc.)\nFor detailed information about each directory and its contents, see Project Structure Details.\nGetting Started\nPrerequisites\n\nRust 2021 edition, version 1.86 or later\nDocker (optional, for containerized deployment)\nNode.js, typescript and ts-node (optional, for plugins)\n\nReady-to-Use Example Configurations\nFor quick setup with various configurations, check the examples directory in our GitHub repository:\n\nbasic-example: Simple setup with Redis\nbasic-example-logging: Configuration with file-based logging\nbasic-example-metrics: Setup with Prometheus and Grafana metrics\nvault-secret-signer: Using HashiCorp Vault for key management\nvault-transit-signer: Using Vault Transit for secure signing\nevm-gcp-kms-signer: Using Google Cloud KMS for EVM secure signing\nevm-turnkey-signer: Using Turnkey for EVM secure signing\nsolana-turnkey-signer: Using Turnkey for Solana secure signing\nevm-cdp-signer: Using CDP for EVM secure signing\nsolana-cdp-signer: Using CDP for Solana secure signing\nredis-storage: Using Redis for Storage\nnetwork-configuration-config-file: Using Custom network configuration via config file\nnetwork-configuration-json-file: Using Custom network configuration via JSON file\n\nEach example includes a README with step-by-step instructions and Docker Compose configuration.\nInstall Locally\n\nClone the repository:\ngit clone https://github.com/openzeppelin/openzeppelin-relayer\ncd openzeppelin-relayer\n\nVerify you have sodium libs installed. If not, follow these instructions:\n\nInstall a stable libsodium version from here.\nFollow the steps in the libsodium installation guide.\n\nInstall dependencies:\ncargo build\n\nRunning the Relayer\nOption 1: Run Locally\ncargo run\nBefore executing the command, ensure that the .env and config.json files are configured as detailed in the Configuration References section.\nOption 2: Run with Docker\nThe Relayer can be run as either a development or production container using the corresponding Dockerfile (Dockerfile.development or Dockerfile.production).\nStep 1: Configure Environment\n\nEdit .env at the root of the repository to adjust environment variables\nThe appropriate .env file will be included during image build\n\nStep 2: Build the Image\nYou can build using Docker Compose (v2).\n# Default build\ndocker compose build\n\n# Or, for a leaner image (and using Dockerfile.production)\nDOCKERFILE=Dockerfile.production docker compose build\nStep 3: Run the Container\nUse Docker Compose to run the container:\ndocker compose up -d\nFor production runs, you can use:\nDOCKERFILE=Dockerfile.production docker compose up -d\nConfiguration\nOpenZeppelin Relayer supports two configuration approaches:\nFile-based Configuration:\n\nconfig.json: Contains relayer definitions, signer configurations, and network policies\n.env: Contains environment variables like API keys and connection strings\n\nAPI-based Configuration:\n\nRuntime configuration management via REST API\nNo service restarts required for configuration changes\nFull CRUD operations for relayers, signers, and notifications\n\nBoth approaches can be used together. File-based configuration is loaded on startup, while API changes provide runtime flexibility. Changes to environment variables (.env) always require restarting the container.When used together, API changes are not synced to file-based configuration. File-based configuration is loaded only once when using persistent storage mode.For quick setup examples with pre-configured files, see the examples directory in our GitHub repository.\nFor comprehensive configuration details, including:\n\nEnvironment variables and their settings\nMain configuration file structure\nSigner configurations (local, vault, cloud KMS, etc.)\nNotification setup\nRelayer policies and network settings\nPlugin configuration\nComplete configuration examples\n\nSee the dedicated Configuration Guide.\nImportant Considerations\nDeployment Considerations\nThe OpenZeppelin Relayer is designed to function as a backend service and is not meant to be directly exposed to the public internet. To protect the service from unauthorized access, deploy it behind your own secure backend infrastructure—such as a reverse proxy or firewall—and restrict access to trusted internal components only. Direct exposure can increase the risk of exploitation and security breaches.\nSupport\nFor support or inquiries, contact us.\nLicense\nThis project is licensed under the GNU Affero General Public License v3.0 - see the LICENSE file for details.\nSecurity\nFor security concerns, please refer to our Security Policy.TroubleshootingPrevious PageQuickstartNext PageOn this pageOverviewFeaturesSupported NetworksNetwork TypesTechnical OverviewProject StructureGetting StartedPrerequisitesInstall LocallyRunning the RelayerOption 1: Run LocallyOption 2: Run with DockerStep 1: Configure EnvironmentStep 2: Build the ImageStep 3: Run the ContainerConfigurationImportant ConsiderationsDeployment ConsiderationsSupportLicenseSecurity","tokens":2195,"squid":"ink-security_audits","role":"Sentinel","at":1791259783264,"hash":"a267b8493d4e7427fd1d60f12ffd2005ae36d62c"}
{"url":"https://io.net/docs/guides/clouds/kubernetes/externaldns-guide","domain":"io.net","title":"ExternalDNS Deployment Guide - io.net","text":"ExternalDNS automatically manages DNS records for applications exposed through your ingress controller. Configuration depends on whether the ingress controller is deployed as a Deployment (Option 1) or a DaemonSet (Option 2).\nPopular DNS providers: Cloudflare, Route 53, Google Cloud DNS, DigitalOcean, Vultr, etc.\n1Deploy ExternalDNSChoose one of the following examples based on your DNS provide:Example for Cloudflare with API Token (Recommended)API tokens are more secure than API keys as they can be scoped to specific zones and permissions.Show Examplekubectl create namespace external-dns\nkubectl create secret generic cloudflare-api-token -n external-dns --from-literal=apiToken=YOUR_API_TOKEN\n\nhelm repo add external-dns https://kubernetes-sigs.github.io/external-dns/\nhelm repo update\n\nhelm upgrade --install external-dns external-dns/external-dns \\\n --namespace external-dns \\\n --set txtOwnerId=mycluster \\\n --set provider.name=cloudflare \\\n --set 'env[0].name=CF_API_TOKEN' \\\n --set 'env[0].valueFrom.secretKeyRef.name=cloudflare-api-token' \\\n --set 'env[0].valueFrom.secretKeyRef.key=apiToken'\nExample for Cloudflare with API KeyReference: https://kubernetes-sigs.github.io/external-dns/latest/docs/tutorials/cloudflare/Show Examplekubectl create namespace external-dns\nkubectl create secret generic cloudflare-api-key -n external-dns --from-literal=apiKey=YOUR_API_KEY --from-literal=email=YOUR_CLOUDFLARE_EMAIL\n\nhelm repo add external-dns https://kubernetes-sigs.github.io/external-dns/\nhelm repo update\n\nhelm upgrade --install external-dns external-dns/external-dns \\\n --namespace external-dns \\\n --set txtOwnerId=mycluster \\\n --set provider.name=cloudflare \\\n --set 'env[0].name=CF_API_KEY' \\\n --set 'env[0].valueFrom.secretKeyRef.name=cloudflare-api-key' \\\n --set 'env[0].valueFrom.secretKeyRef.key=apiKey' \\\n --set 'env[1].name=CF_API_EMAIL' \\\n --set 'env[1].valueFrom.secretKeyRef.name=cloudflare-api-key' \\\n --set 'env[1].valueFrom.secretKeyRef.key=email'\nBy default, ExternalDNS runs with the upsert-only policy, which allows it to create and update DNS records but not delete them. To enable record deletion, change the policy to sync.--set policy=sync2Annotate the Ingress Controller ServiceThe annotations you need depend on which ingress controller option you chose.Option 1 (Deployment with the LoadBalancer Service)kubectl annotate svc ingress-nginx-controller \\\n -n ingress-nginx \\\n external-dns.alpha.kubernetes.io/hostname=\"*.example.com\"\n\nWildcard domains simplify DNS management for multiple applications.\nEliminates the need to annotate each Ingress resource individually.\nDNS records are automatically updated when the Service’s externalIPs change.\nExternalDNS monitors the LoadBalancer Service and creates DNS A records that point to the configured externalIPs.\nOption 2 (DaemonSet with hostNetwork)kubectl annotate svc ingress-nginx-controller \\\n -n ingress-nginx \\\n external-dns.alpha.kubernetes.io/hostname=\"*.example.com\" \\\n external-dns.alpha.kubernetes.io/endpoints-type=NodeExternalIP\n\nThe endpoints-type=NodeExternalIP annotation instructs ExternalDNS to use the external IPs of nodes where the DaemonSet pods are running.\nThis results in DNS A records pointing to the external IPs of all worker nodes.\nDNS records are automatically updated as nodes are added to, or removed from, the cluster.\n\nFor an end-to-end HTTPS application example, refer to Quick Start: Hello World with HTTPS.Was this page helpful?","tokens":863,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259790306,"hash":"96a4155705eb33f5ea0c9b0cbb5b950b84917e65"}
{"url":"https://docs.pyth.network/price-feeds/pro/getting-started","domain":"docs.pyth.network","title":"Getting Started | Pyth Developer Hub","text":"Pyth ProGetting StartedLearn how to access, configure, and use Pyth Pro price feedsPyth Pro is a high-performance, low-latency service that provides real-time financial market data.\nThis guide will walk you through setting up and running a basic JavaScript example to subscribe to Pyth Pro price feeds.\nPrerequisites\nBefore getting started, make sure you have the following installed:\n\nA Pyth Pro API Key - see How to Acquire an API Key if you don't have one\nNode.js (version 18 or higher)\npnpm package manager\nGit for cloning the examples repository\n\nClone the Examples RepositoryFirst, clone the Pyth examples repository which contains the JavaScript SDK example:git clone https://github.com/pyth-network/pyth-examples.git\ncd pyth-examples/lazer/jsInstall DependenciesInstall the required dependencies using pnpm:pnpm installThis will install @pythnetwork/pyth-lazer-sdk, which will be used to subscribe to Pyth Pro prices.Pyth Pro was previously known as Pyth Lazer. The SDK remains the same.Configure Your API KeySet your Pyth Pro API key as an environment variable:export ACCESS_TOKEN=your_actual_token_hereReplace your_actual_token_here with your actual Pyth Pro API key. If you\ndon't have one, follow the API key guide to\nobtain it.Run the Basic WebSocket ExampleNow you can run the basic example that demonstrates connecting to Pyth Pro and receiving price updates:pnpm run startThis command will subscribe to Pyth Pro updates for two price feeds, receiving streaming updates.\nEach update is then printed to the terminal on receipt.\nYou should see output similar to the following:got message: {\n type: 'json',\n value: {\n type: 'streamUpdated',\n subscriptionId: 1,\n parsed: { timestampUs: '1758034015200000', priceFeeds: [Array] },\n solana: {\n encoding: 'hex',\n data: 'b9011a82036df6ced259a33949ab9b2c48a61a2d3b0b9436cba24c3ef8a600b72767927d14a459fcc3abce280b3f8194e16e8b32f9322ac0b84a9c0b792e19857962a60180efc1f480c5615af3fb673d42287e993da9fbc3506b6e41dfa32950820c2e6c2a0075d3c79300a3fa30ec3e060003020100000001009053802f790a00000200000001004234106d67000000'\n }\n }\n}\nstream updated for subscription 1 : [\n { priceFeedId: 1, price: '11515604259728' },\n { priceFeedId: 2, price: '444211409986' }\n]\ngot message: {\n type: 'json',\n value: {\n type: 'streamUpdated',\n subscriptionId: 1,\n parsed: { timestampUs: '1758034015400000', priceFeeds: [Array] },\n solana: {\n encoding: 'hex',\n data: 'b9011a826f5ff7e25ac4056c4ec3a08c428baf38e7b78c46014296ccbcfd5395c38c9f7bc23865a048401c66788e791f0edc3a6701b0ea4a5399f50ec8b1795757854f0180efc1f480c5615af3fb673d42287e993da9fbc3506b6e41dfa32950820c2e6c2a0075d3c79340b0fd30ec3e060003020100000001005821a32f790a00000200000001004334106d67000000'\n }\n }\n}\nstream updated for subscription 1 : [\n { priceFeedId: 1, price: '11515606540632' },\n { priceFeedId: 2, price: '444211409987' }\n]Understand the Example CodeThe main example code in src/index.ts demonstrates the core Pyth Pro integration pattern:import { PythLazerClient } from \"@pythnetwork/pyth-lazer-sdk\";\n\nconst client = await PythLazerClient.create({\n urls: [\n \"wss://pyth-lazer-0.dourolabs.app/v1/stream\",\n \"wss://pyth-lazer-1.dourolabs.app/v1/stream\",\n \"wss://pyth-lazer-2.dourolabs.app/v1/stream\",\n ],\n token: process.env.ACCESS_TOKEN!,\n});\n\n// The message listener is called every time a new message is received.\nclient.addMessageListener((message) => {\n // Add your logic to consume messages here\n console.log(\"got message:\", message);\n});\n\n// Subscribe to price feeds\nclient.subscribe({\n type: \"subscribe\",\n subscriptionId: 1,\n priceFeedIds: [1, 2],\n properties: [\"price\"],\n formats: [\"solana\"],\n deliveryFormat: \"json\",\n channel: \"fixed_rate@200ms\",\n jsonBinaryEncoding: \"hex\",\n});Production Tip: Include feedUpdateTimestampFor production applications, add \"feedUpdateTimestamp\" to the properties\narray. This field lets you determine whether a price was freshly generated or\ncarried forward from an earlier update by comparing it against timestampUs.\nSee Payload Reference — Price Availability\nSemantics for\ndetails.For a detailed explanation of every property passed to client.subscribe, see\nthe Payload\nReference.\nWhat's Next?\nNow that you've successfully run the basic Pyth Pro example, you can explore more advanced integration patterns:\nMore Information\nExplore additional Pyth Pro capabilities:\n\nSubscribe to Price Updates - Detailed guide on WebSocket subscriptions and message handling\nPrice Feed IDs - Complete list of available price feeds and their identifiers\n\nBlockchain Integration\nLearn how to integrate Pyth Pro price feeds into your smart contracts:\n\nSolana Integration - Build SVM smart contracts that consume Pyth Pro price feeds with cryptographic verification\nEVM Integration - Integrate Pyth Pro into Ethereum and other EVM-compatible chains\nSui Integration - Verify Pyth Pro price updates in Sui Programmable Transaction Blocks before consuming them in Move contracts\nIOTA Integration - Verify Pyth Pro price updates in IOTA Programmable Transaction Blocks before consuming them in Move contracts\nCardano Integration - Verify Pyth Pro price updates in Cardano transactions\n\nAI-Assisted Development\nUse Pyth market data directly in AI assistants like Claude, Cursor, and Windsurf via the Model Context Protocol:\n\nMCP Server - Connect your AI assistant to Pyth price feeds, historical data, and candlestick charts\nMCP Skills - Pre-built workflows for portfolio tracking, volatility analysis, FX conversion, and more\n\nExample Applications\nCheck out more comprehensive examples in the pyth-examples repository:\n\nSolana Examples - Post price data to Solana smart contracts with Ed25519 and ECDSA verification\nEVM Examples - Smart contract integration for Ethereum-compatible chains\nPyth ProExplore Pyth Pro's enterprise-grade, customizable price data offeringPyth TerminalExplore Pyth price feeds, get a free API key, and trial Pyth Pro from your browser","tokens":1468,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259793107,"hash":"768ad882217595f085950976615097e381384e22"}
{"url":"https://docs.openzeppelin.com/relayer/1.5.x/solana","domain":"docs.openzeppelin.com","title":"Solana Integration | OpenZeppelin Docs","text":"RelayerSolana IntegrationOpen in ClaudeOverview\nOpenZeppelin Relayer provides robust support for Solana networks, enabling secure transaction relaying, automated token swaps, gasless transactions, and advanced fee management. This page covers everything you need to get started and make the most of Solana-specific features.\nFeatures\n\nAutomated token swaps via Jupiter DEX (mainnet-beta only)\nGasless transactions (user or relayer pays fees)\nSecure transaction signing with multiple signer backends\nTransaction status monitoring and nonce management\nCustom RPC endpoints and network policies\nMetrics and observability\n\nSupported Networks\nSolana networks are defined via JSON configuration files, providing flexibility to:\n\nConfigure standard Solana clusters: mainnet-beta, devnet, testnet\nSet up custom Solana-compatible networks with specific RPC endpoints\nCreate network variants using inheritance from base configurations\n\nExample Solana network configurations:\n{\n \"networks\": [\n {\n \"type\": \"solana\",\n \"network\": \"solana-mainnet\",\n \"rpc_urls\": [\"https://api.mainnet-beta.solana.com\"],\n \"explorer_urls\": [\"https://explorer.solana.com\"],\n \"is_testnet\": false,\n \"tags\": [\"mainnet\", \"solana\"]\n },\n {\n \"type\": \"solana\",\n \"network\": \"solana-devnet\",\n \"rpc_urls\": [\"https://api.devnet.solana.com\"],\n \"explorer_urls\": [\"https://explorer.solana.com?cluster=devnet\"],\n \"is_testnet\": true,\n \"tags\": [\"devnet\", \"solana\"]\n },\n {\n \"type\": \"solana\",\n \"network\": \"solana-custom\",\n \"rpc_urls\": [\"https://your-custom-solana-rpc.example.com\"],\n \"tags\": [\"custom\", \"solana\"]\n }\n ]\n}\nFor detailed network configuration options, see the Network Configuration guide.\nSupported Signers\n\nvault_transit (hosted)\nturnkey (hosted)\ngoogle_cloud_kms (hosted)\nlocal (local)\nvault (local)\ncdp (hosted)\n\nIn production systems, hosted signers are recommended for the best security model.\nQuickstart\nFor a step-by-step setup, see Quick Start Guide.\nKey prerequisites:\n\nRust 2021, version 1.86 or later\nRedis\nDocker (optional)\n\nExample configuration for a Solana relayer:\n{\n \"id\": \"solana-example\",\n \"name\": \"Solana Example\",\n \"network\": \"devnet\",\n \"paused\": false,\n \"notification_id\": \"notification-example\",\n \"signer_id\": \"local-signer\",\n \"network_type\": \"solana\",\n \"custom_rpc_urls\": [\n { \"url\": \"https://primary-solana-rpc.example.com\", \"weight\": 100 },\n { \"url\": \"https://backup-solana-rpc.example.com\", \"weight\": 100 }\n ],\n \"policies\": {\n \"fee_payment_strategy\": \"user\",\n \"min_balance\": 0,\n \"allowed_tokens\": [\n { \"mint\": \"So111...\", \"max_allowed_fee\": 100000000 }\n ],\n \"swap_config\": {\n \"strategy\": \"jupiter-swap\",\n \"cron_schedule\": \"0 0 * * * *\",\n \"min_balance_threshold\": 1000000,\n \"jupiter_swap_options\": {\n \"dynamic_compute_unit_limit\": true,\n \"priority_level\": \"high\",\n \"priority_fee_max_lamports\": 1000000000\n }\n }\n }\n}\nFor more configuration examples, visit the OpenZeppelin Relayer examples repository, window=_blank.\nConfiguration\nRelayer Policies\nIn addition to standard relayer configuration and policies, Solana relayers support additional options:\nFeatureUser Pays (Default)Relayer PaysWho pays feesUsers pay in SPL tokensRelayer pays in SOLTransaction formatPre-signed transactions onlyEncoded transactions OR instruction arraysBest endpointRPC methods (Paymaster spec)REST API POST /transactionsUse caseGasless UX, user-controlled signingSimplified UX, backend automation\nFuture Breaking Change:In future versions, fee_payment_strategy will be a mandatory field in the relayer configuration. This change is being made to prevent misconfigurations and misunderstandings. Please ensure your relayer configurations explicitly specify fee_payment_strategy as either \"user\" or \"relayer\" to avoid issues when upgrading.\nUser Pays Fees (Default)\nfee_payment_strategy: user (default when not specified)\nIn this mode:\n\nUsers pay transaction fees in SPL tokens\nThe relayer receives fee payment from the user as part of the transaction\nUsers submit fully-formed, pre-signed transactions via the API\nThe relayer validates and relays the transaction to the network\n\nRelayer Pays Fees\nfee_payment_strategy: relayer\nIn this mode:\n\nThe relayer pays all transaction fees in SOL\nUsers can submit either:\n\nEncoded transactions (base64-encoded, pre-signed)\nArray of instructions (relayer builds and signs the full transaction)\n\nUse Cases:\n\nSimplified user experience (no fee token management)\nBackend-controlled transaction execution\nAutomated workflows and scheduled operations\nApplications where the relayer subsidizes transaction costs\n\nAdditional Relayer Policies\n\nallowed_tokens: List of SPL tokens supported for swaps and fee payments. Optional.\n\nWhen not set or empty, all tokens are allowed for transactions and fee payments\nWhen configured, only tokens in this list can be used for transfers and fee payments\n\nallowed_programs, allowed_accounts, disallowed_accounts: Restrict relayer operations to specific programs/accounts\nswap_config: Automated token swap settings (see below)\n\nYou can check all options in User Documentation - Relayers.\nAutomated token swap configuration options:\n\nstrategy: The swap engine to use. Supported values: \"jupiter-swap\" (Jupiter Swap API), \"jupiter-ultra\" (Jupiter Ultra API).\ncron_schedule: Cron expression defining how often scheduled swaps should run (e.g., \"0 0 * * * *\" for every hour).\nmin_balance_threshold: Minimum token balance (in lamports) that triggers a swap. If the relayer’s balance drops below this, a swap is attempted.\njupiter_swap_options: Advanced options for Jupiter swaps, such as:\n\ndynamic_compute_unit_limit: If true, dynamically adjusts compute units for swap transactions.\npriority_level: Priority for the swap transaction. Supported values: \"medium\", \"high\", \"veryHigh\".\npriority_fee_max_lamports: Maximum priority fee (in lamports) to pay for a swap transaction.\n\nPer-token swap limits:\n\nmin_amount: Minimum amount of a token to swap in a single operation.\nmax_amount: Maximum amount of a token to swap in a single operation.\nretain_min_amount: Minimum amount of a token to retain in the relayer account after a swap (prevents swapping the entire balance).\n\nAutomated Token Swaps\nThe relayer can perform automated token swaps on Solana when user fee_payment_strategy is used for relayer using:\n\njupiter-swap – via the Jupiter Swap API\njupiter-ultra – via the Jupiter Ultra API\n\nSwaps can be set to work as:\n\nScheduled Swaps: Background jobs run swaps based on your cron schedule.\nOn-Demand Swaps: If a transaction fails due to insufficient funds, the relayer attempts a swap before returning an error.\n\nAPI Reference\nThe Solana relayer provides two API interfaces that support fee estimation, transaction preparation, signing, and sending:\n\nRPC Endpoint (JSON-RPC 2.0) - Conforms to the Paymaster spec\n\nBest for: User fee payment mode\nURL: POST /api/v1/relayers/<relayer_id>/rpc\nWorks in: Both fee payment modes\nSupports: feeEstimate, prepareTransaction, signTransaction, and signAndSendTransaction methods\n\nREST Endpoints - Direct transaction operations\n\nFee Estimation: POST /api/v1/relayers/<relayer_id>/transactions/sponsored/quote (matches feeEstimate RPC method)\nTransaction Preparation: POST /api/v1/relayers/<relayer_id>/transactions/sponsored/build (matches prepareTransaction RPC method)\nSign Transaction: POST /api/v1/relayers/<relayer_id>/sign-transaction\nSend Transaction: POST /api/v1/relayers/<relayer_id>/transactions\n\nBase URL: POST /api/v1/relayers/<relayer_id>/rpcThis endpoint can be used in both fee payment modes, but provides the best experience for user fee payment mode.\nRPC Methods\n\nfeeEstimate - Estimate transaction fees\ngetSupportedTokens - Get list of supported tokens\ngetSupportedFeatures - Get list of available features\nprepareTransaction - Prepare transaction with fee payments\ntransferTransaction - Execute token transfers with fee payments\nsignTransaction - Sign user-provided transactions\nsignAndSendTransaction - Sign and send transactions (combines signing and submission)\n\nFor complete RPC examples, see the SDK Solana examples.\nFee Token Parameter Behavior:When using fee_payment_strategy: \"relayer\", the fee_token parameter in RPC methods becomes informational only. The relayer pays all transaction fees in SOL regardless of the specified fee token. In this mode, you can use either \"So11111111111111111111111111111112\" (WSOL) or \"11111111111111111111111111111111\" (native SOL) as the fee_token value.When using fee_payment_strategy: \"user\", the fee_token parameter determines which token the user will pay fees in, and must be a supported token from the allowed_tokens list (if configured).\nREST Endpoints\nFee Estimation (Quote)\nBase URL: POST /api/v1/relayers/<relayer_id>/transactions/sponsored/quote\nAvailable in: user payment mode.\nMatches RPC method: feeEstimate\nEstimates transaction fees for a given transaction. Returns the fee amount in both the native currency (SOL) and the specified fee token. This endpoint helps users understand the cost before building or submitting a transaction.\nTransaction Preparation (Build)\nBase URL: POST /api/v1/relayers/<relayer_id>/transactions/sponsored/build\nAvailable in: user payment mode.\nMatches RPC method: prepareTransaction\nPrepares a transaction with fee payments. This endpoint builds a transaction that includes the necessary fee payment instructions based on the fee payment strategy. Returns a prepared transaction ready for signing.\nSign Transaction\nBase URL: POST /api/v1/relayers/<relayer_id>/sign-transaction\nAvailable in: Both fee payment modes\nMatches RPC method: signTransaction\nSigns a user-provided transaction without submitting it to the network. This is useful when you want to sign a transaction and handle submission separately.\nSend Transaction\nBase URL: POST /api/v1/relayers/<relayer_id>/transactions\nMatches RPC method: signAndSendTransaction\nThis endpoint provides two ways to submit transactions:\nOption 1: Encoded Transaction (Pre-signed)\nSubmit a base64-encoded, pre-signed transaction that the relayer will relay to the network. When in user payment mode, the relayer optionally validates that the transaction contains user payment to the relayer.\nOption 2: Array of Instructions (Relayer Builds Transaction)\nSubmit an array of Solana instructions. The relayer will:\n\nBuild a complete transaction from the provided instructions\nAdd necessary compute budget and priority fee instructions\nOptionally validate that the transaction contains user payment to the relayer when in user payment mode\nSign the transaction with the relayer's signer\nSubmit the transaction to the Solana network\n\nFor complete REST API examples with both options, see the SDK Solana examples.\nAPI Summary\nFor User Fee Payment Mode (fee_payment_strategy: \"user\"):\n\nRPC endpoint: POST /api/v1/relayers/<relayer_id>/rpc\n\nFull Paymaster specification support\nMethods: feeEstimate, prepareTransaction, signTransaction, signAndSendTransaction, etc.\n\nREST endpoints:\n\nPOST /api/v1/relayers/<relayer_id>/transactions/sponsored/quote - Estimate fees (matches feeEstimate)\nPOST /api/v1/relayers/<relayer_id>/transactions/sponsored/build - Prepare transaction (matches prepareTransaction)\nPOST /api/v1/relayers/<relayer_id>/sign-transaction - Sign transactions without submitting\nPOST /api/v1/relayers/<relayer_id>/transactions - Send transactions (accepts encoded transactions or instruction arrays)\n\nFor Relayer Fee Payment Mode (fee_payment_strategy: \"relayer\"):\n\nREST endpoints:\n\nPOST /api/v1/relayers/<relayer_id>/transactions - Send transactions (accepts encoded transactions or instruction arrays)\nPOST /api/v1/relayers/<relayer_id>/sign-transaction - Sign transactions without submitting\n\nRPC endpoint: POST /api/v1/relayers/<relayer_id>/rpc\n\nAlternative: RPC methods also work but REST is recommended for sending transactions\n\nAdditional Resources:\n\nAPI Reference Documentation - Complete API specification\nSDK Solana Examples - Working code examples for both RPC and REST endpoints\n\nSecurity\n\nDo not expose the relayer directly to the public internet.\nDeploy behind a secure backend (reverse proxy, firewall).\nUse hosted signers in production systems.\n\nTroubleshooting\n\nCheck environment variables and configuration files for errors\nReview container logs for issues\n\nRoadmap\n\nSee Project Roadmap for upcoming features\n\nSupport\nFor help, open an issue on GitHub or contact us.\nLicense\nThis project is licensed under the GNU Affero General Public License v3.0.EVM IntegrationPrevious PageOverviewNext PageOn this pageOverviewFeaturesSupported NetworksSupported SignersQuickstartConfigurationRelayer PoliciesUser Pays Fees (Default)Relayer Pays FeesAdditional Relayer PoliciesAutomated token swap configuration options:Automated Token SwapsAPI ReferenceRPC MethodsREST EndpointsFee Estimation (Quote)Transaction Preparation (Build)Sign TransactionSend TransactionOption 1: Encoded Transaction (Pre-signed)Option 2: Array of Instructions (Relayer Builds Transaction)API SummarySecurityTroubleshootingRoadmapSupportLicense","tokens":3237,"squid":"ink-security_audits","role":"Sentinel","at":1791259793592,"hash":"05050f29474ec62f74272d5216157323786ba8af"}
{"url":"https://docs.pyth.network/price-feeds/pro/pyth-terminal","domain":"docs.pyth.network","title":"Pyth Terminal | Pyth Developer Hub","text":"Pyth ProPyth TerminalExplore Pyth price feeds, get a free API key, and trial Pyth Pro from your browserPyth Terminal is a self-serve web application where you can explore Pyth's full catalog of price feeds, view historical chart data, and get a free Pyth Pro API trial key — all without needing to contact sales. Whether you're evaluating Pyth for a new integration or browsing available data, Terminal is the fastest way to get started.\nWhat You Can Do\n\nExplore Feeds — Browse and filter 500+ price feeds across crypto, US equities, FX, commodities, and more\nView Historical Charts — Inspect OHLC candlestick data with trading schedule overlays\nGet a Free API Trial — Generate a Pyth Pro access token instantly, no credit card required\nAccess Benchmark Data — View benchmark pricing for US equities and FX\nManage Your Subscription — Upgrade your plan, add payment, and manage billing online\n\nTutorials\nGetting Started with Pyth Terminal\nWalk through the core features: searching feeds, filtering by asset class, viewing price charts, and generating your API key.\n\nPyth Pro x Polymarket\nSee how Polymarket uses Pyth Pro data through Terminal, including RWA feeds and subscription setup.\nIf you'd like to access the package Polymarket uses, please visit Polymarket's documentation, where they link the request form.\nThis package includes metals such as XAU and XAG, equities such as SPY, QQQ, EWY, AAPL, NVDA, MSFT, AMZN, GOOGL, META, TSLA, NFLX, COIN, HOOD, PLTR, ABNB, OPEN, and RKLB, and commodities such as WTI and Henry Hub natural gas futures; see the Pyth Pro price feed IDs page for the latest symbols and IDs.\n\nReady to try it yourself? Visit Pyth Terminal to start exploring price feeds and get your free API key.Getting StartedLearn how to access, configure, and use Pyth Pro price feedsAcquire an API KeyRequest and manage API keys for Pyth Pro","tokens":464,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259803140,"hash":"a45cc5fd602fc3c4348294d131a7505a33bae7db"}
{"url":"https://io.net/docs/guides/payment/io-credits","domain":"io.net","title":"IO Credits - io.net","text":"​What are IO Credits?\nIO Credits are prepaid credits you can use to pay for compute deployments on io.net Cloud, including Ray Clusters, VMs, Kubernetes, and Baremetal. Each IO Credit is equivalent to 1 USD, this allows pricing to be simple and consistent.\n​Why IO Credits?\n\nPay once to use anytime.\nCan be used across io.net Cloud products.\nFaster checkout process during deployments.\nRefunds and incentives automatically appear as credits.\nAPI support is available for fully automated workflows.\n\n​Quick Start\n\nOn the Navigation Bar, click Buy IO Credits and A pop-up window will appear.\n\nEnter the amount of credits you want to purchase. The minimum purchase is $10.\n\nChoose a payment method: USDC or USD (Credit/Debit Card).\n\nIf USDC is selected, you will be redirected to Spherepay to complete the transaction.\n\nIf USD (Credit/Debit Card) is selected, you will be redirected to Stripe to complete the transaction.\n\nOnce payment is confirmed, the purchased IO Credits will be added to your account.\n\nUse IO Credits to deploy compute or inference workloads.\n\nView your balance, track usage, and manage withdrawals in Usage & Billing.\n\n​Refunds as Credits\nIf a deployment ends early or is cancelled, any unused funds are returned as IO Credits. You will be notified via the Notification Center.\n​Using IO Credits\n​Compute Products\nDuring checkout you see the required amount and your current credit balance.\n1 IO Credit = 1 USD\nIf sufficient credits are available, the Pay & Deploy button becomes active, allowing you to proceed with deployment.\n​Use via API\nDeployment endpoints accept the parameter payment_method: \"credits\".\nIf the available balance is low, the system may provide fallback options such as:\n\nGET /credits/check?amount=XX – Checks if sufficient credits are available for a specific amount.\nPending Payment state – Indicates that payment confirmation is required.\nSmall negative credit allowance (for example, up to -$10) – Allows limited temporary usage.\nFive-minute grace window – Prompts you to top up before deployment fails.\nFailure to deploy – Occurs if credits are not replenished within the grace period.\n\n​Managing IO Credits\n​Viewing Credit Balance\nTo view your IO Credit balance:\n\nNavigate to Usage & Billing from the top navigation bar.\nIn this page you can:\n\nView your Total IO Credits displayed as a single balance (in USD).\nView your Credits Usage and Transactions.\nRequest a Withdrawal (available for purchased credits only).\n\n​Request Withdrawal\nYou may submit a manual request to withdraw available purchased credits from your balance.\nWithdrawals are available only to users who have paid for credits. Once submitted, withdrawal requests are reviewed by the IO Finance team and typically processed within three to seven business days.\n\n​Viewing Transactions\nThe Transactions section provides visibility into how your IO Credits have been added, used, or refunded. It allows you to track spending, reconcile deployments, and understand your current balance.\nYou will find transaction entries for the following categories:\n\nCredit Inflow – Credits that you have purchased or that have been issued to your account by the IO team.\nUsage Deductions – Credits spent on compute deployments, inference runs, or other billable operations.\nRefunds – Credits returned from early terminations, failed deployments, or unused services.\n\nEach transaction record includes the following details:\n\nType of transaction\nAmount added or deducted\nDate and time of the transaction\nTransaction ID\n\nUse this log to audit your activity, track usage patterns, or troubleshoot billing inquiries.\n\n​Credit Usage via API and Tracking\nCredits are tied to your IO ID and can be used across all io.net Cloud products. When using io.net APIs, you can specify the payment method as credits to automatically deduct from your balance.\n​FAQs\nWhat happens if I don’t have enough IO Credits?You will be prompted to top up or use another payment method. Your deployment will pause temporarily and may fail if not resolved in time.Can I convert credits back to USDC?Only purchased credits may be withdrawn, after a manual review by the finance team.Do IO Credits expire?Yes. All purchased IO Credits expire twelve (12) months from the date of purchase.What happens when my IO Credits expire?Once IO Credits expire, any unused balance will have no remaining value and cannot be withdrawn, refunded, or reinstated.Does this expiration policy apply to all IO Credits?No. The 12-month expiration applies only to non-promotional credits, which are credits that were purchased or paid for by users.Promotional credits (for example, credits granted by the IO team for trials, rewards, or campaigns) may have different expiration timelines or conditions, which will be clearly stated when they are issued.Can I extend or renew my IO Credit expiration date?No. Once IO Credits have expired, they cannot be reactivated or extended. To continue using IO, you can purchase new credits at any time.Was this page helpful?","tokens":1251,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259810124,"hash":"c4bb09a1efca4330c3ee6d5c5f5ee5d9fc1bb4c5"}
{"url":"https://docs.openzeppelin.com/relayer/1.5.x/evm","domain":"docs.openzeppelin.com","title":"EVM Integration | OpenZeppelin Docs","text":"RelayerEVM IntegrationOpen in ClaudeOverview\nOpenZeppelin Relayer provides comprehensive support for EVM (Ethereum Virtual Machine) networks, enabling secure transaction relaying, advanced gas management, EIP-1559 support, and robust fee estimation. This page covers everything you need to get started and make the most of EVM-specific features.\nFeatures\n\nAdvanced gas price management with EIP-1559 support\nDynamic gas limit estimation with fallback mechanisms\nTransaction replacement and acceleration\nMulti-network support (Ethereum, Arbitrum, Optimism, BSC, Polygon, etc.)\nCustom RPC endpoints with load balancing and failover\nSecure transaction signing with multiple signer backends\nTransaction status monitoring and confirmation tracking\nWhitelist-based security policies\nMetrics and observability\n\nSupported Networks\nEVM networks are defined via JSON configuration files, providing flexibility to:\n\nConfigure any EVM-compatible network (Ethereum, Polygon, BSC, Arbitrum, Optimism, etc.)\nSet up custom EVM-compatible networks with specific RPC endpoints\nCreate network variants using inheritance from base configurations\nSupport both Layer 1 and Layer 2 networks\n\nFor detailed network configuration options, see the Network Configuration guide.\nSupported Signers\n\nlocal (local keystore files)\nvault (HashiCorp Vault secret storage)\nvault_cloud (hosted HashiCorp Vault)\nturnkey (hosted Turnkey signer)\ngoogle_cloud_kms (Google Cloud KMS)\naws_kms (Amazon AWS KMS)\ncdp (hosted Coinbase Developer Platform signer)\n\nFor detailed signer configuration options, see the Signers guide.\nIn production systems, hosted signers (AWS KMS, Google Cloud KMS, Turnkey, CDP) are recommended for the best security model.\nQuickstart\nFor a step-by-step setup, see Quick Start Guide.\nKey prerequisites:\n\nRust 2021, version 1.88 or later\nRedis\nDocker (optional)\n\nExample configuration for an EVM relayer:\n{\n \"id\": \"sepolia-example\",\n \"name\": \"Sepolia Example\",\n \"network\": \"sepolia\",\n \"paused\": false,\n \"notification_id\": \"notification-example\",\n \"signer_id\": \"local-signer\",\n \"network_type\": \"evm\",\n \"custom_rpc_urls\": [\n {\n \"url\": \"https://primary-rpc.example.com\",\n \"weight\": 100\n },\n {\n \"url\": \"https://backup-rpc.example.com\",\n \"weight\": 100\n }\n ],\n \"policies\": {\n \"gas_price_cap\": 100000000000,\n \"eip1559_pricing\": true,\n \"gas_limit_estimation\": true,\n \"whitelist_receivers\": [\n \"0x1234567890123456789012345678901234567890\",\n \"0xabcdefabcdefabcdefabcdefabcdefabcdefabcd\"\n ],\n \"min_balance\": 1000000000000000000\n }\n},\nFor more configuration examples, visit the OpenZeppelin Relayer examples repository, window=_blank.\nConfiguration\nRelayer Policies\nIn addition to standard relayer configuration and policies, EVM relayers support additional options:\n\ngas_price_cap: Maximum gas price limit (in wei) for transactions\ngas_limit_estimation: Enable/disable automatic gas limit estimation\nwhitelist_receivers: List of authorized contract addresses for transactions\nmin_balance: Minimum balance required for the relayer to operate (in wei)\neip1559_pricing: Enable/disable EIP-1559 pricing methodology for transaction fees\n\nYou can check all options in User Documentation - Relayers.\nGas Management Configuration\nGas Price Cap\nSet a maximum gas price to protect against extreme network congestion:\n{\n \"policies\": {\n \"gas_price_cap\": 100000000000 // 100 Gwei maximum\n }\n}\nGas Limit Estimation\nEnable or disable automatic gas limit estimation:\n{\n \"policies\": {\n \"gas_limit_estimation\": true // Enable automatic estimation\n }\n}\nWhen disabled, gas limits must be provided explicitly in transaction requests.\nThe relayer uses a two-tier approach for gas limit estimation:\n\nPrimary Method: Uses the RPC estimate_gas method to calculate gas requirements\n\nThe estimated value is increased by 10% as a safety buffer\nProvides accurate estimates for most transaction types\n\nFallback Method: When RPC estimation fails, default gas limits are applied based on transaction type:\n\nSimple ETH transfer (no data): 21,000 gas\nERC20 transfer (0xa9059cbb): 65,000 gas\nERC721/ERC20 transferFrom (0x23b872dd): 80,000 gas\nComplex contracts (all other function calls): 200,000 gas\n\nFor advanced users working with complex transactions or custom contracts, it is recommended to include an explicit gas_limit parameter in the transaction request to ensure optimal gas usage and avoid estimation errors.\nWhitelist Receivers\nRestrict transactions to specific contract addresses:\n{\n \"policies\": {\n \"whitelist_receivers\": [\n \"0x1234567890123456789012345678901234567890\",\n \"0xabcdefabcdefabcdefabcdefabcdefabcdefabcd\"\n ]\n }\n}\nAPI Reference\nThe EVM API provides comprehensive transaction management capabilities.\nCommon endpoints:\n\nPOST /api/v1/relayers/<relayer_id>/transactions send transaction\nGET /api/v1/relayers/<relayer_id>/transactions list transactions\nGET /api/v1/relayers/<relayer_id>/transactions/<transaction_id> get transaction by id\n\nSend Transaction - Speed params\ncurl --location --request POST 'http://localhost:8080/api/v1/relayers/sepolia-example/transactions' \\\n--header 'Authorization: Bearer <api_key>' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": 1,\n \"data\": \"0x\",\n \"to\": \"0xd9b55a2ba539031e3c18c9528b0dc3a7f603a93b\",\n \"speed\": \"average\"\n}'\nSend Transaction - Speed params with gas limit included\ncurl --location --request POST 'http://localhost:8080/api/v1/relayers/sepolia-example/transactions' \\\n--header 'Authorization: Bearer <api_key>' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": 1,\n \"data\": \"0x\",\n \"to\": \"0xd9b55a2ba539031e3c18c9528b0dc3a7f603a93b\",\n \"speed\": \"average\",\n \"gas_limit\": 21000\n}'\nTransaction with EIP-1559 Pricing\ncurl --location --request POST 'http://localhost:8080/api/v1/relayers/sepolia-example/transactions' \\\n--header 'Authorization: Bearer <api_key>' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": 1,\n \"data\": \"0x\",\n \"to\": \"0xd9b55a2ba539031e3c18c9528b0dc3a7f603a93b\",\n \"max_fee_per_gas\": 30000000000,\n \"max_priority_fee_per_gas\": 20000000000,\n}'\nTransaction with Legacy Pricing - gas estimation included\ncurl --location --request POST 'http://localhost:8080/api/v1/relayers/sepolia-example/transactions' \\\n--header 'Authorization: Bearer <api_key>' \\\n--header 'Content-Type: application/json' \\\n--data-raw '{\n \"value\": 1,\n \"data\": \"0x\",\n \"to\": \"0xd9b55a2ba539031e3c18c9528b0dc3a7f603a93b\",\n \"gas_price\": \"12312313123\"\n}'\nGet Transaction Status\ncurl --location --request GET 'http://localhost:8080/api/v1/relayers/sepolia-example/transactions/<transaction_id>' \\\n--header 'Authorization: Bearer <api_key>'\nSee API Reference for full details and examples.\nTransaction Lifecycle\n1. Transaction Submission\n\nValidate transaction parameters\nCheck whitelist policies (if enabled)\nEstimate gas limit (if not provided)\nCalculate gas price based on network conditions\n\n2. Transaction Signing\n\nSign transaction using configured signer\nGenerate appropriate signature format\n\n3. Transaction Broadcasting\n\nSubmit to network via RPC endpoints\nHandle RPC failures with automatic retries\nSwitch to backup RPC endpoints if needed\n\n4. Transaction Monitoring\n\nTrack transaction status and confirmations\nHandle transaction replacements if needed\nSend notifications on status changes\n\n5. Transaction Confirmation\n\nWait for required number of confirmations\nMark transaction as confirmed or failed\nClean up resources\n\nSecurity Best Practices\nNetwork Security\n\nUse private RPC endpoints in production\nConfigure RPC_ALLOWED_HOSTS and RPC_BLOCK_PRIVATE_IPS for SSRF protection. See Configuration → RPC URL Security\nConfigure appropriate gas_price_cap to prevent excessive fees\nEnable whitelist_receivers for controlled environments\nMonitor relayer balance and set appropriate min_balance\n\nSigner Security\n\nUse hosted signers (AWS KMS, Google Cloud KMS, Turnkey) in production\nRotate signer keys regularly\nImplement proper access controls and audit logging\nNever store private keys in plain text\n\nOperational Security\n\nDeploy behind a secure reverse proxy\nUse HTTPS for all communications\nImplement proper rate limiting\nMonitor for unusual transaction patterns\n\nMonitoring and Observability\nEnable metrics and monitor:\n\nTransaction success rates\nGas price trends\nRPC endpoint performance\nRelayer balance levels\nFailed transaction patterns\n\nSupport\nFor help with EVM integration:\n\nContact us for general support\nOpen an issue on our GitHub repository\nCheck our comprehensive documentation\n\nLicense\nThis project is licensed under the GNU Affero General Public License v3.0.Storage ConfigurationPrevious PageSolana IntegrationNext PageOn this pageOverviewFeaturesSupported NetworksSupported SignersQuickstartConfigurationRelayer PoliciesGas Management ConfigurationGas Price CapGas Limit EstimationWhitelist ReceiversAPI ReferenceSend Transaction - Speed paramsSend Transaction - Speed params with gas limit includedTransaction with EIP-1559 PricingTransaction with Legacy Pricing - gas estimation includedGet Transaction StatusTransaction Lifecycle1. Transaction Submission2. Transaction Signing3. Transaction Broadcasting4. Transaction Monitoring5. Transaction ConfirmationSecurity Best PracticesNetwork SecuritySigner SecurityOperational SecurityMonitoring and ObservabilitySupportLicense","tokens":2309,"squid":"ink-security_audits","role":"Sentinel","at":1791259813727,"hash":"853b5eb68c0fbcc0833c30614afacc96312287ca"}
{"url":"https://dev-forum.pyth.network/c/help-price-feeds/7","domain":"dev-forum.pyth.network","title":"Latest Price Feeds topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Price Feeds\n\n Price Feeds\n\n subcategories\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Price Feeds category\n\n Price Feeds\n\n Welcome to the Pyth Price Feeds Category \nThis is your hub for everything related to Pyth’s Price Feeds. \nUse this category to: \n• Ask questions and troubleshoot integration issues \n•…\n\n read more\n\n 0\n\n 507\n\n Apr 2025\n\n Pyth Pro equity entitlement for the Stocklana hackathon (Best use of Pyth market data)\n\n Price Feeds\n\n svm\n\n 4\n\n 14\n\n 9h\n\n When will pyth-lazer-solana-contract, pyth-lazer-sdk crates be bumped for Anchor v0.32?\n\n Price Feeds\n\n svm\n\n 0\n\n 14\n\n 7d\n\n How can I revoke or rotate an exposed Pyth API key?\n\n Benchmarks(Historic Prices)\n\n 1\n\n 9\n\n 8d\n\n Deprecation Notice - Push Feeds (EVM) - October 15th 2026\n\n Price Feeds\n\n announcements\n\n 0\n\n 31\n\n 26d\n\n Pyth data for a small public market-intelligence platform in Slovenia\n\n Price Feeds\n\n announcements\n\n 2\n\n 20\n\n Aug 26\n\n Update: Pyth Core Upgrade Date Moved to August 26, 2026\n\n Price Feeds\n\n announcements\n\n 2\n\n 400\n\n Aug 26\n\n We’re building a prediction game on Solana where every shot settles on Pyth, and we ended up doing the account validation by hand rather than through the SDK. Sharing what we found, plus four questions we couldn’t answer from the docs. Why by hand. Our fi\n\n Price Feeds\n\n entropy\n\n 7\n\n 28\n\n Aug 26\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Pyth Pro Streams query\n\n Benchmarks(Historic Prices)\n\n 4\n\n 37\n\n Aug 5\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 115\n\n Aug 5\n\n Deprecation of Pyth Push Feeds on Movement — July 13th, 2026\n\n Price Feeds\n\n announcements\n\n 0\n\n 22\n\n Jul 13\n\n Off-chain price feeds\n\n Price Feeds\n\n 11\n\n 78\n\n Jul 4\n\n Pyth Hermes → Custom EVM Chain Integration Issues\n\n Price Feeds\n\n 7\n\n 68\n\n Jun 22\n\n Missing parsePriceFeedUpdatesUnique function on BSC implementation\n\n Price Feeds\n\n evm\n\n 6\n\n 46\n\n Jun 18\n\n Updates to Push Feeds on Monad Mainnet - 17th June\n\n Price Feeds\n\n announcements\n\n 0\n\n 14\n\n Jun 17\n\n Pyth-solana-receiver-sdk supported Anchor versions\n\n Price Feeds\n\n 3\n\n 522\n\n Jun 16\n\n Lower-latency Pyth Lazer endpoint for Dublin / Ireland VPS?\n\n Price Feeds\n\n 1\n\n 22\n\n Jun 16\n\n Pythnet RPC access?\n\n Price Feeds\n\n 1\n\n 29\n\n Jun 3\n\n Deprecation of some (Resolv) Pyth Push Feeds on Base, Ethereum, Arbitrum, HyperEVM and Solana – May 31st, 2026\n\n Price Feeds\n\n announcements\n\n 1\n\n 33\n\n Jun 2\n\n Insight seeks collaboration with Pyth on data integration and ecosystem building\n\n Price Feeds\n\n 0\n\n 16\n\n Jun 1\n\n Price feed subscription error\n\n Price Feeds\n\n evm\n\n 0\n\n 26\n\n May 21\n\n Pyth Pro Update: SO, WH, and CO futures feed units\n\n Price Feeds\n\n announcements\n\n 0\n\n 23\n\n May 14\n\n Xstocks price feed aggregation question\n\n Price Feeds\n\n evm\n\n 1\n\n 25\n\n May 8\n\n Sui Push Feeds: Update Frequency Increase (60s → 10s), May 5th, 2026\n\n Price Feeds\n\n announcements,sponsored-feeds\n\n 0\n\n 22\n\n May 5\n\n Q2 2025: Pyth Core Onchain Fees\n\n Price Feeds\n\n announcements,evm\n\n 0\n\n 13\n\n May 5\n\n Guardian update unresolved\n\n Price Feeds\n\n svm\n\n 7\n\n 84\n\n May 3\n\n Best approach for handling oracle latency vs on-chain execution timing?\n\n Price Feeds\n\n 2\n\n 38\n\n Apr 13\n\n Pyth Pro x Polymarket - commodity asset type not enabled on API key\n\n Price Feeds\n\n 2\n\n 33\n\n Apr 9\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 23\n\n Apr 9","tokens":1751,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259817269,"hash":"be6b60bb7831780ee617c5bc342c230d291df55c"}
{"url":"https://docs.openzeppelin.com/relayer/1.5.x/configuration","domain":"docs.openzeppelin.com","title":"Configuration | OpenZeppelin Docs","text":"RelayerConfigurationOpen in ClaudeOverview\nMost configuration files should live under ./config, including the signer configurations, under ./config/keys.\nPlease ensure appropriate access permissions on all configuration files (for ./config/keys/*, we recommend 0500.\nThe OpenZeppelin Relayer supports two configuration approaches:File-based Configuration:\nconfig.json: Contains relayer definitions, signer configurations, and network policies\n.env file: Contains environment variables like API keys and connection strings\nAPI-based Configuration:\nFull CRUD operations for relayers, signers, and notifications via REST API\nChanges take effect immediately (no container restart required)\nSee the API Reference page for detailed endpoints documentation\nSee Storage Configuration for detailed information about how file-based and API-based configurations work together, storage behavior, and best practices.For quick setup examples with pre-configured files, see the examples directory in our GitHub repository.\nEnvironment configuration (.env)\nThis defines some base configurations for the Relayer application:\nCopy the example environment file and update values according to your needs\ncp .env.example .env\nThis table lists the environment variables and their default values.\nEnvironment VariableDefault ValueAccepted ValuesDescriptionRUST_LOGinfoinfo, debug, warn, error, traceLog level.REPOSITORY_STORAGE_TYPEin-memoryin-memory, redisType of storage used for storing repository config and resources. See Storage Configuration for detailed information.RESET_STORAGE_ON_STARTfalseboolClears all resources from storage on startup and reloads entries from the config file. See Storage Configuration for usage details.TRANSACTION_EXPIRATION_HOURS4numberNumber of hours after which transactions in a final state are removed from storage. See Storage Configuration for more information.CONFIG_DIR./config<any relative file path where config.json is located>Relative path of directory where config files resideCONFIG_FILE_NAMEconfig.json<any file name>File Name of the configuration file.RATE_LIMIT_REQUESTS_PER_SECOND100<any value>Rate limit for the API in requests per second.RATE_LIMIT_BURST_SIZE300<any value>Rate limit burst size.API_KEY``string,API key to use for authentication to the relayer server. Minimum length 32 characters.WEBHOOK_SIGNING_KEY``stringSigning key to use for webhook notifications. Minimum length 32 characters.LOG_MODEstdoutstdout, fileWrite logs either to console or to file.LOG_DATA_DIR./logs<any file path>Directory to persist log files on host.LOG_MAX_SIZE (in bytes)1073741824<any value in bytes>Size after which logs needs to be rolled.METRICS_ENABLEDfalseboolEnable metrics server for external tools to scrape metrics.METRICS_PORT8081<any tcp port (preferably choose non-privileged ports i.e. (1024-65535))>Port to use for metrics server.REDIS_URLredis://localhost:6379<redis connection string>Redis connection URL for the primary instance. Used for all write operations and read operations when REDIS_READER_URL is not set. See Storage Configuration for Redis setup details.REDIS_READER_URL(none)<redis connection string>Optional separate endpoint for read operations. When set, read operations use this endpoint while writes use REDIS_URL. Useful for AWS ElastiCache with read replicas. See Storage Configuration for configuration examples.REDIS_CONNECTION_TIMEOUT_MS10000<timeout in milliseconds>Connection timeout for Redis in milliseconds. See Storage Configuration for Redis configuration.REDIS_POOL_MAX_SIZE500<number>Maximum number of connections in the primary Redis connection pool. See Storage Configuration for tuning guidance.REDIS_READER_POOL_MAX_SIZE1000<number>Maximum number of connections in the reader Redis connection pool. Only used when REDIS_READER_URL is set. Useful for read-heavy workloads. See Storage Configuration for pool sizing recommendations.REDIS_POOL_TIMEOUT_MS10000<timeout in milliseconds>Maximum time to wait for a connection from the pool. See Storage Configuration for performance tuning.REDIS_KEY_PREFIXoz-relayerstringRedis key prefix for namespacing. See Storage Configuration for more information.QUEUE_BACKENDredisredis, sqsQueue backend implementation. redis uses Apalis + Redis queues. sqs uses AWS SQS workers and queue backend abstraction.AWS_REGION(none)<aws region>Required when QUEUE_BACKEND=sqs. Used to build/resolve SQS queue endpoints.AWS_ACCOUNT_ID(none)<aws account id>Required when QUEUE_BACKEND=sqs and SQS_QUEUE_URL_PREFIX is not set. Used to construct default SQS queue URLs.SQS_QUEUE_URL_PREFIX(none)<sqs queue url prefix>Optional override for SQS queue URL prefix (example: https://sqs.us-east-1.amazonaws.com/123456789012/relayer-). When set, AWS_ACCOUNT_ID is not required.SQS_QUEUE_TYPEautoauto, standard, fifoSQS queue type. auto (default) probes the transaction-request queue at startup to detect the type. standard and fifo skip probing and use the specified type directly.DISTRIBUTED_MODEfalsebool (true/false, 1/0)Enables Redis-based distributed locks for cron/cleanup tasks in multi-instance deployments, preventing duplicate scheduled execution across nodes.STORAGE_ENCRYPTION_KEY``stringEncryption key used to encrypt data at rest in Redis storage. See Storage Configuration for security details.RPC_TIMEOUT_MS10000<timeout in milliseconds>Sets the maximum time to wait for RPC connections before timing out.PROVIDER_MAX_RETRIES3<number of retries>Maximum number of retry attempts for provider operations.PROVIDER_RETRY_BASE_DELAY_MS100<delay in milliseconds>Base delay between retry attempts in milliseconds.PROVIDER_RETRY_MAX_DELAY_MS2000<delay in milliseconds>Maximum delay between retry attempts in milliseconds.PROVIDER_MAX_FAILOVERS3<number of failovers>Maximum number of failovers (switching to different providers).PROVIDER_FAILURE_THRESHOLD3<number>Number of consecutive failures before a provider is temporarily paused. When a provider reaches this threshold, it will be paused for the duration specified by PROVIDER_PAUSE_DURATION_SECS. Supports legacy env var RPC_FAILURE_THRESHOLD.PROVIDER_PAUSE_DURATION_SECS60<seconds>Duration in seconds that a provider remains paused after reaching the failure threshold. During this time, the relayer will attempt to use other available providers. Supports legacy env var RPC_PAUSE_DURATION_SECS.PROVIDER_FAILURE_EXPIRATION_SECS60<seconds>Duration in seconds after which individual failure records are considered stale and automatically removed. This allows providers to naturally recover over time even without explicit success calls. Failures older than this duration are not counted toward the failure threshold.RPC_ALLOWED_HOSTS``<comma-separated hostnames>Comma-separated list of allowed RPC hostnames/IPs. If non-empty, only URLs with these hosts are permitted. Example: eth-mainnet.g.alchemy.com,mainnet.infura.ioRPC_BLOCK_PRIVATE_IPSfalseboolBlock private IP addresses (RFC 1918, loopback, link-local) in RPC URLs. Set to true to prevent RPC URLs from targeting private networks.CONNECTION_BACKLOG511<number>TCP listen backlog size (pending connections queue). Higher values allow more connections to be queued during traffic bursts, preventing connection drops. Default of 511 is a production-ready value that balances memory usage with burst capacity.REQUEST_TIMEOUT_SECONDS30<seconds>Request handler timeout in seconds for API endpoints. This is a security measure to prevent resource exhaustion attacks (DoS). It limits how long a request handler can run, preventing slowloris-style attacks and ensuring resources are freed promptly.RELAYER_CONCURRENCY_LIMIT100<any positive number>Maximum number of concurrent requests allowed for /api/v1/relayers/* endpoints. When this limit is reached, additional requests will be rejected with a 429 Too Many Requests error. This helps prevent resource exhaustion and ensures fair resource allocation.MAX_CONNECTIONS256<any positive number>Maximum number of concurrent TCP connections allowed server-wide. This is a safety net that prevents the server from accepting more connections than it can handle. When this limit is reached, new connections will be rejected.ENABLE_SWAGGERfalsetrue, falseEnable or disable Swagger UI for API documentation.KEYSTORE_PASSPHRASE``<keystore passphrase>Passphrase for the keystore file used for signing transactions.BACKGROUND_WORKER_TRANSACTION_REQUEST_CONCURRENCY50<any positive number>Maximum number of concurrent transaction request jobs that can be processed simultaneously.BACKGROUND_WORKER_TRANSACTION_SENDER_CONCURRENCY75<any positive number>Maximum number of concurrent transaction submission jobs that can be processed simultaneously.BACKGROUND_WORKER_TRANSACTION_STATUS_CHECKER_CONCURRENCY50<any positive number>Maximum number of concurrent generic/default transaction status check jobs that can be processed simultaneously. This worker handles Solana and any future networks that don’t have dedicated status checkers.BACKGROUND_WORKER_TRANSACTION_STATUS_CHECKER_EVM_CONCURRENCY100<any positive number>Maximum number of concurrent EVM transaction status check invocations that can be processed simultaneously. EVM handles the highest volume (~75% of all status checks) and uses optimized retries (8-20s) to avoid triggering premature resubmission.BACKGROUND_WORKER_TRANSACTION_STATUS_CHECKER_STELLAR_CONCURRENCY50<any positive number>Maximum number of concurrent Stellar transaction status checks that can be processed simultaneously. Stellar status checker uses fast retries (2-3s) optimized for Stellar’s faster block times.BACKGROUND_WORKER_NOTIFICATION_SENDER_CONCURRENCY30<any positive number>Maximum number of concurrent notifications that can be processed simultaneously.BACKGROUND_WORKER_SOLANA_TOKEN_SWAP_REQUEST_CONCURRENCY10<any positive number>Maximum number of concurrent Solana token swap requests that can be processed simultaneously. Low volume worker.BACKGROUND_WORKER_TRANSACTION_CLEANUP_CONCURRENCY1<any positive number>Maximum number of concurrent transaction cleanup invocations that can be processed simultaneously. Defaults to 1 to avoid database conflicts.BACKGROUND_WORKER_RELAYER_HEALTH_CHECK_CONCURRENCY10<any positive number>Maximum number of concurrent relayer health check invocations that can be processed simultaneously. Low volume worker.\nEnvironment configuration example\n.env file config example:\nRUST_LOG=DEBUG\nCONFIG_DIR=./config\nCONFIG_FILE_NAME=config.json\nWEBHOOK_SIGNING_KEY=e1d42480-6f74-4d0b-85f4-b7f0bb690fae\nAPI_KEY=5eefd216-0e44-4ca7-b421-2925f90d30d5\nRATE_LIMIT_REQUESTS_PER_SECOND=100\nRATE_LIMIT_BURST_SIZE=300\nMETRICS_ENABLED=true\nMETRICS_PORT=8081\nREDIS_URL=redis://localhost:6379\nREDIS_CONNECTION_TIMEOUT_MS=10000\nREDIS_KEY_PREFIX=oz-relayer\nRPC_TIMEOUT_MS=10000\nPROVIDER_MAX_RETRIES=3\nPROVIDER_RETRY_BASE_DELAY_MS=100\nPROVIDER_RETRY_MAX_DELAY_MS=2000\nPROVIDER_MAX_FAILOVERS=3\nPROVIDER_FAILURE_THRESHOLD=3\nPROVIDER_PAUSE_DURATION_SECS=60\nPROVIDER_FAILURE_EXPIRATION_SECS=60\nRPC_BLOCK_PRIVATE_IPS=true\nRPC_ALLOWED_HOSTS=eth-mainnet.g.alchemy.com,mainnet.infura.io\nCONNECTION_BACKLOG=511\nREQUEST_TIMEOUT_SECONDS=30\nRELAYER_CONCURRENCY_LIMIT=100\nMAX_CONNECTIONS=256\nENABLE_SWAGGER=false\nKEYSTORE_PASSPHRASE=your_keystore_passphrase\nSTORAGE_ENCRYPTION_KEY=X67aXacJB+krEldv9i2w7NCSFwwOzVV/1ELM2KJJjQw=\nREPOSITORY_STORAGE_TYPE=redis\nRESET_STORAGE_ON_START=false\nTRANSACTION_EXPIRATION_HOURS=8\nQueue backend configuration\nSet QUEUE_BACKEND to choose the queue system:\n\nredis (default): Redis queue backend via Apalis workers\nsqs: AWS SQS queue backend (standard or FIFO queues)\n\nExample for SQS:\nQUEUE_BACKEND=sqs\nAWS_REGION=us-east-1\nAWS_ACCOUNT_ID=123456789012\n# Optional: \"auto\" (default), \"standard\", or \"fifo\"\n# SQS_QUEUE_TYPE=auto\n# Optional alternative to AWS_ACCOUNT_ID:\n# SQS_QUEUE_URL_PREFIX=https://sqs.us-east-1.amazonaws.com/123456789012/relayer-\nBy default (SQS_QUEUE_TYPE=auto), the relayer auto-detects whether your queues are standard or FIFO at startup by probing the transaction-request queue. Set SQS_QUEUE_TYPE=standard or SQS_QUEUE_TYPE=fifo to skip probing and use the specified type directly.\nFor distributed deployments (multiple relayer instances), set:\nDISTRIBUTED_MODE=true\nThis enables distributed locking for cron/cleanup tasks so only one instance executes each scheduled job at a time.\nSQS queue provisioning guide\nWhen QUEUE_BACKEND=sqs, create queues with the relayer- prefix (or your custom SQS_QUEUE_URL_PREFIX). By default (SQS_QUEUE_TYPE=auto), the relayer auto-detects the queue type at startup by probing a reference queue. You can also set SQS_QUEUE_TYPE=standard or SQS_QUEUE_TYPE=fifo to skip probing.\nStandard queues\nStandard queues offer higher throughput, native per-message DelaySeconds, and simpler setup. Duplicate deliveries are possible but harmless since all handlers are idempotent.\nRequired queue names:\n\nrelayer-transaction-request\nrelayer-transaction-submission\nrelayer-status-check\nrelayer-status-check-evm\nrelayer-status-check-stellar\nrelayer-notification\nrelayer-token-swap-request\nrelayer-relayer-health-check\n\nAWS CLI example (replace <ACCOUNT_ID>):\naws sqs create-queue \\\n --queue-name relayer-transaction-request \\\n --attributes VisibilityTimeout=30\nFIFO queues\nFIFO queues provide message ordering per group and exactly-once delivery via deduplication. The relayer sets MessageGroupId and MessageDeduplicationId on send.\nRequired queue names:\n\nrelayer-transaction-request.fifo\nrelayer-transaction-submission.fifo\nrelayer-status-check.fifo\nrelayer-status-check-evm.fifo\nrelayer-status-check-stellar.fifo\nrelayer-notification.fifo\nrelayer-token-swap-request.fifo\nrelayer-relayer-health-check.fifo\n\nAWS CLI example (replace <ACCOUNT_ID>):\naws sqs create-queue \\\n --queue-name relayer-transaction-request.fifo \\\n --attributes \\\nFifoQueue=true,ContentBasedDeduplication=false,VisibilityTimeout=30,DeduplicationScope=messageGroup,FifoThroughputLimit=perMessageGroupId\nFor production workloads, enable high-throughput FIFO on high-volume queues (transaction-request, transaction-submission, status-check). Set DeduplicationScope=messageGroup and FifoThroughputLimit=perMessageGroupId to raise throughput from 300 to 70,000 messages/second per queue.\nRecommended queue settings\nThese settings apply to both standard and FIFO queues:\nQueueVisibility timeout (seconds)Suggested maxReceiveCount (DLQ redrive)transaction-request306transaction-submission302status-check301000 (or a high value)status-check-evm301000 (or a high value)status-check-stellar201000 (or a high value)notification606token-swap-request603relayer-health-check603\nNotes:\n\nStatus-check queues use short-delay re-enqueue for retries; use a high maxReceiveCount to avoid premature DLQ movement.\nConfigure a DLQ per queue in production. For FIFO queues, the DLQ must also be FIFO.\n\nSet redrive policy to attach a DLQ:\naws sqs set-queue-attributes \\\n --queue-url \"https://sqs.us-east-1.amazonaws.com/<ACCOUNT_ID>/relayer-transaction-request\" \\\n --attributes '{\"RedrivePolicy\":\"{\\\"deadLetterTargetArn\\\":\\\"<DLQ_ARN>\\\",\\\"maxReceiveCount\\\":\\\"6\\\"}\"}'\nMain configuration file (config.json)\nThis file can exist in any directory, but the default location is ./config/config.json.\nAll components defined in config.json can also be managed via REST API endpoints. This provides runtime flexibility for adding, updating, or removing relayers, signers, and notifications without restarting the service. See the API Reference page for detailed endpoints documentation.\nKey sections in this file include:\n\nSigners: Defines transaction signing methods.\nNotifications: Sets up status alerts\nRelayers: Configures networks, notifications channels, policies & singers.\nNetworks: Defines blockchain network configurations.\nPlugins: Configures plugins.\n\n1. Signers\nTransaction signers are responsible for cryptographically signing transactions before they are submitted to blockchain networks.\nFor comprehensive details on configuring all supported signer types including:\n\nLocal keystore file signers\nHashiCorp Vault (secret and transit)\nCloud KMS providers (Google Cloud, AWS)\nTurnkey signers\nCDP signers\nSecurity best practices and troubleshooting\n\nSee the dedicated Signers Configuration guide.\nSigners can also be managed via API endpoints.\nSee the API Reference page for detailed endpoints documentation.\n2. Notifications\n\nnotifications array containing notification entries:\n\n\"notifications\": [\n {\n \"id\": \"notification-test\",\n \"type\": \"webhook\",\n \"url\": \"https://webhook.site/f95cf78d-742d-4b21-88b7-d683e6fd147b\",\n \"signing_key\": {\n \"type\": \"env\",\n \"value\": \"WEBHOOK_SIGNING_KEY\"\n }\n }\n]\nAvailable configuration fields\nFieldTypeDescriptionidStringUnique id for the notificationtypeStringType of notification (only webhook available, for now)urlStringNotification URLsigning_key.typeStringType of key used in signing the notification (env or plain)signing_key.valueStringSigning key value, env variable name, ...\nNotifications can also be managed via API endpoints.\nSee the API Reference page for detailed endpoints documentation.\n3. Relayers\n\nrelayers array, containing relayer entries:\n\n\"relayers\": [\n {\n \"id\": \"solana-testnet\",\n \"name\": \"Solana Testnet\",\n \"paused\": false,\n \"notification_id\": \"notification-test\",\n \"signer_id\": \"local-signer\",\n \"network_type\": \"solana\",\n \"network\": \"testnet\",\n \"custom_rpc_urls\": [\n {\n \"url\": \"https://primary-rpc.example.com\",\n \"weight\": 2 // Higher weight routes more requests to this endpoint. The value must be an integer between 0 and 100 (inclusive).\n },\n {\n \"url\": \"https://backup-rpc.example.com\",\n \"weight\": 1\n }\n ],\n \"policies\": {\n \"allowed_programs\": [\n \"11111111111111111111111111111111\",\n \"TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA\",\n \"BPFLoaderUpgradeab1e11111111111111111111111\"\n ]\n }\n }\n]\nAvailable configuration fields\nFieldTypeDescriptionidStringUnique id for the relayernameStringHuman readable name for the relayerpausedBooleanWhether or not the relayer is paused (true, false)notification_idStringID of a configured notification objectsigner_idStringID of a configured signernetwork_typeStringType of network the relayer will connect to (evm, solana)networkStringNetwork the relayer will connect to. Must match a network identifier defined in your network configuration files. See Network Configuration for details on defining networks.custom_rpc_urlslistOptional custom RPC URLs for the network. If provided, this will be used instead of the public RPC URLs. This is useful for using your own RPC node or a paid service provider. The first url of the list is going to be used as the defaultpolicieslistOverrides default policies. Please refer to the Policies table\nPolicies\nNetwork typePolicyTypeDescriptionsolana, evm, stellarmin_balanceunsigned 128 (evm/solana), unsigned 64 (stellar)Minimum balance (in lamports, wei, or stroops) required for the relayer to operate. Optional.solanafee_payment_strategyenum(user,relayer)Specifies who pays the fee. \"user\" (default) means the sender pays; \"relayer\" means the relayer pays. For \"user\", RPC methods add an instruction to transfer SPL tokens (calculated from the current SOL price plus a configurable margin) from the user to the relayer, ensuring fees are sustainably covered in tokens rather than SOL.stellarfee_payment_strategyenum(user,relayer)Specifies who pays the fee. \"user\" enables sponsored transactions (users pay fees in tokens), \"relayer\" means relayer pays all fees in XLM. Optional.solanaswap_configSwapConfigOptional object configuring automated token‐swaps on Solana.stellarswap_configSwapConfigOptional object configuring automated token swaps on Stellar. Includes strategies (order-book, soroswap), cron_schedule, and min_balance_threshold.solanafee_margin_percentagef32Additional margin percentage added to estimated transaction fees to account for price fluctuations. For example, a value of 10 will add 10% to estimated fees. Optional.stellarfee_margin_percentagef32Fee margin percentage applied when converting XLM fees to token amounts for sponsored transactions. Optional.stellarslippage_percentagef32Maximum slippage percentage allowed when swapping tokens via DEX for sponsored transactions. Optional.solanamax_allowed_fee_lamportsunsigned 64Maximum allowed fee (in lamports) for a transaction. Optional.solanaallowed_tokensVector<AllowedToken>List of allowed tokens. Only these tokens are supported if provided. Optional.stellarallowed_tokensVector<StellarAllowedToken>List of tokens allowed for fee payments in sponsored transactions. Each token includes asset, max_allowed_fee (optional), and swap_config (optional). Optional.solanaallowed_programsVector<String>List of allowed programs by their identifiers. Only these programs are supported if provided.solanaallowed_accountsVector<String>List of allowed accounts by their public keys. The relayer will only operate with these accounts if provided.solanadisallowed_accountsVector<String>List of disallowed accounts by their public keys. These accounts will be explicitly blocked.solanamax_tx_data_sizeunsigned 16Maximum transaction size. Optional.solanamax_signaturesunsigned 8Maximum supported signatures. Optional.stellarmax_feeunsigned 32Maximum transaction fee in stroops (1 XLM = 10,000,000 stroops) the relayer is willing to pay. Optional.stellartimeout_secondsunsigned 64Transaction timeout in seconds. Optional.stellarconcurrent_transactionsboolEnable concurrent transaction processing. When enabled, bypasses the lane gating mechanism that normally ensures sequential processing for each relayer. Only enable this when your relayer manages transactions from multiple accounts with independent sequence number pools. Optional.evmgas_price_capunsigned 128Specify a maximum gas price for every transaction sent with the Relayer. When enabled, any transaction exceeding the cap will have its gasPrice or maxFeePerGas overwritten. (Optional)evmgas_limit_estimationboolAutomatic gas_limit calculation. Enabled by default. (Optional)evmwhitelist_receiversVector<String>A list of authorized contracts for each transaction sent using the Relayer. Transactions will be rejected if the destination address is not on the list. (Optional)\nRPC URL Configuration\nThe relayer supports two ways to configure RPC URLs:\n\nPublic RPC URLs: These are the default RPC endpoints provided by the network. They are automatically selected based on the network configuration.\nCustom RPC URLs: You can specify custom RPC URLs using the custom_rpc_urls field in the relayer configuration. Each URL can be configured with an optional weight for high availability:\n\n\"custom_rpc_urls\": [\n {\n \"url\": \"https://primary-rpc.example.com\",\n \"weight\": 2 // Higher weight routes more requests to this endpoint. The value must be an integer between 0 and 100 (inclusive).\n },\n {\n \"url\": \"https://secondary-rpc.example.com\",\n \"weight\": 100, // Max allowed weight\n },\n {\n \"url\": \"https://backup-rpc.example.com\" // No weight specified, defaults to 100\n },\n {\n \"url\": \"https://backup2-rpc.example.com\",\n \"weight\": 0, // A value of 0 disables the endpoint.\n }\n]\nThis is useful when you want to:\n\nUse your own RPC nodes with load balancing\nUse a paid service provider for better reliability and performance\nOverride the default public RPC URLs\nAccess custom network endpoints\nConfigure primary and backup endpoints with different weights\n\nWhen both are available, the relayer will:\n\nFirst attempt to use the custom_rpc_urls if configured.\nFall back to the public RPC URLs if no custom URL is configured.\n\nFor backward compatibility, string arrays are still supported:\n\"custom_rpc_urls\": [\"https://your-rpc.example.com\"]\nProvider Health Management\nThe relayer automatically tracks the health of RPC providers and manages failover:\n\nFailure Tracking: When a provider fails, the failure is recorded with a timestamp. Failures older than PROVIDER_FAILURE_EXPIRATION_SECS (default: 60 seconds) are automatically considered stale and removed.\n\nAutomatic Pausing: When a provider reaches PROVIDER_FAILURE_THRESHOLD (default: 3) failures within the expiration window, it is automatically paused for PROVIDER_PAUSE_DURATION_SECS (default: 60 seconds). During this pause period, the relayer will attempt to use other available providers.\n\nAutomatic Recovery: After the pause duration expires, the provider becomes available again. Additionally, if all failures expire (older than PROVIDER_FAILURE_EXPIRATION_SECS), the provider automatically recovers even if it hasn't reached the pause expiration time.\n\nFallback Behavior: If all non-paused providers are unavailable, the relayer will fall back to paused providers as a last resort, ensuring maximum availability.\n\nYou can configure these behaviors using the environment variables:\n\nPROVIDER_FAILURE_THRESHOLD: Number of failures before pausing (default: 3)\nPROVIDER_PAUSE_DURATION_SECS: How long to pause a failed provider (default: 60 seconds)\nPROVIDER_FAILURE_EXPIRATION_SECS: How long failures are remembered (default: 60 seconds)\n\nRPC URL Security\nYou can configure the following security features via environment variables:\n\nRPC_ALLOWED_HOSTS: Comma-separated list of allowed RPC hostnames/IPs. If non-empty, only URLs with these hosts are permitted.\n\nExample: RPC_ALLOWED_HOSTS=eth-mainnet.g.alchemy.com,mainnet.infura.io\n\nRPC_BLOCK_PRIVATE_IPS: Block private IP addresses (RFC 1918, loopback, link-local). Set to true to prevent RPC URLs from targeting private networks.\n\nExample: RPC_BLOCK_PRIVATE_IPS=true\nDefault: false (for backwards compatibility)\n\nCloud metadata endpoints (169.254.169.254, fd00:ec2::254) are always blocked to prevent credential theft, regardless of configuration.\nRecommended Production Configuration:\nRPC_BLOCK_PRIVATE_IPS=true\nRPC_ALLOWED_HOSTS=eth-mainnet.g.alchemy.com,mainnet.infura.io,eth.llamarpc.com\nWhen using custom RPC URLs:\nEnsure the URLs are secure (HTTPS) when accessing over public networks\nKeep your API keys and authentication tokens secure\nTest the RPC endpoints' reliability and performance before using it in production\nConfigure weights to prioritize endpoints, assigning higher values to more reliable or performant ones.\nThe weight must be an integer between 0 and 100 (inclusive).\nA weight of 0 disables the endpoint.\nIf a weight is not specified for an endpoint, it defaults to 100.\n\nRelayers could also be managed via API endpoints.\nSee the API Reference page for detailed endpoints documentation.\n4. Plugins\nFor more information on how to write a plugin, please refer to the Plugins page.\n\nplugins array, containing plugin configurations:\n\n\"plugins\": [\n {\n \"id\": \"my-plugin\",\n \"path\": \"my-plugin.ts\"\n }\n]\nAvailable configuration fields\nFieldTypeDescriptionidStringUnique id for the pluginpathStringPath to the plugin file\n5. Networks\nYou can configure networks either:\n\nIn separate JSON files (recommended for better organization)\nDirectly in your main config.json\n\nFor comprehensive network configuration details, including:\n\nNetwork field reference\nConfiguration examples for all network types\nNetwork inheritance\nSpecial tags and their behavior\nBest practices and troubleshooting\n\nSee the dedicated Network Configuration guide.\nConfiguration File Example\nFull config/config.json example with evm and solana relayers definitions using keystore signer:\n{\n \"relayers\": [\n {\n \"id\": \"sepolia-example\",\n \"name\": \"Sepolia Example\",\n \"network\": \"sepolia\",\n \"paused\": false,\n \"notification_id\": \"notification-example\",\n \"signer_id\": \"local-signer\",\n \"network_type\": \"evm\",\n \"custom_rpc_urls\": [\n {\n \"url\": \"https://primary-rpc.example.com\",\n \"weight\": 2\n },\n {\n \"url\": \"https://backup-rpc.example.com\",\n \"weight\": 1\n }\n ],\n \"policies\": {\n \"gas_price_cap\": 30000000000000,\n \"eip1559_pricing\": true\n }\n },\n {\n \"id\": \"solana-example\",\n \"name\": \"Solana Example\",\n \"network\": \"devnet\",\n \"paused\": false,\n \"notification_id\": \"notification-example\",\n \"signer_id\": \"local-signer\",\n \"network_type\": \"solana\",\n \"custom_rpc_urls\": [\n {\n \"url\": \"https://primary-solana-rpc.example.com\",\n \"weight\": 2\n },\n {\n \"url\": \"https://backup-solana-rpc.example.com\",\n \"weight\": 1\n }\n ],\n \"policies\": {\n \"fee_payment_strategy\": \"user\",\n \"min_balance\": 0,\n \"allowed_tokens\": [\n {\n \"mint\": \"Gh9ZwEmdLJ8DscKNTkTqPbNwLNNBjuSzaG9Vp2KGtKJr\",\n \"max_allowed_fee\": 100000000\n },\n {\n \"mint\": \"So11111111111111111111111111111111111111112\"\n }\n ]\n }\n },\n {\n \"id\": \"solana-mainnet-example\",\n \"name\": \"Solana Mainnet Example\",\n \"network\": \"mainnet-beta\",\n \"paused\": false,\n \"notification_id\": \"notification-example\",\n \"signer_id\": \"local-signer\",\n \"network_type\": \"solana\",\n \"custom_rpc_urls\": [\"https://your-private-solana-rpc.example.com\"],\n \"policies\": {\n \"fee_payment_strategy\": \"user\",\n \"min_balance\": 0,\n \"swap_config\": {\n \"cron_schedule\": \"0 0 * * * *\",\n \"min_balance_threshold\": 0,\n \"strategy\": \"jupiter-ultra\"\n },\n \"allowed_tokens\": [\n {\n \"mint\": \"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v\",\n \"max_allowed_fee\": 100000000,\n \"swap_config\": {\n \"min_amount\": 0,\n \"max_amount\": 0,\n \"retain_min_amount\": 0\n }\n },\n {\n \"mint\": \"So11111111111111111111111111111111111111112\"\n }\n ]\n }\n }\n ],\n \"notifications\": [\n {\n \"id\": \"notification-example\",\n \"type\": \"webhook\",\n \"url\": \"https://webhook.site/1384d4d9-21b1-40a0-bcd1-d3f3b66be955\",\n \"signing_key\": {\n \"type\": \"env\",\n \"value\": \"WEBHOOK_SIGNING_KEY\"\n }\n }\n ],\n \"signers\": [\n {\n \"id\": \"local-signer\",\n \"type\": \"local\",\n \"config\": {\n \"path\": \"config/keys/local-signer.json\",\n \"passphrase\": {\n \"type\": \"env\",\n \"value\": \"KEYSTORE_PASSPHRASE\"\n }\n }\n }\n ],\n \"networks\": [\n {\n \"average_blocktime_ms\": 12000,\n \"chain_id\": 11155111,\n \"explorer_urls\": [\n \"https://api-sepolia.etherscan.io/api\",\n \"https://sepolia.etherscan.io\"\n ],\n \"features\": [\"eip1559\"],\n \"is_testnet\": true,\n \"network\": \"sepolia\",\n \"required_confirmations\": 6,\n \"rpc_urls\": [\n \"https://sepolia.drpc.org\",\n \"https://1rpc.io/sepolia\",\n \"https://ethereum-sepolia-rpc.publicnode.com\",\n \"https://ethereum-sepolia-public.nodies.app\"\n ],\n \"symbol\": \"ETH\",\n \"tags\": [\"deprecated\"],\n \"type\": \"evm\"\n },\n {\n \"type\": \"solana\",\n \"network\": \"devnet\",\n \"rpc_urls\": [\"https://api.devnet.solana.com\"],\n \"explorer_urls\": [\"https://explorer.solana.com?cluster=devnet\"],\n \"average_blocktime_ms\": 400,\n \"is_testnet\": true\n },\n {\n \"type\": \"solana\",\n \"network\": \"mainnet-beta\",\n \"rpc_urls\": [\"https://api.mainnet-beta.solana.com\"],\n \"explorer_urls\": [\"https://explorer.solana.com\"],\n \"average_blocktime_ms\": 400,\n \"is_testnet\": false\n }\n ]\n}\nConfiguration Management Approaches\nThe OpenZeppelin Relayer supports two complementary approaches for configuration management:\nFile-based Configuration\n\nIdeal for initial setup and deployment\nConfiguration persists across restarts\nRequires container restart for changes to take effect\nSuitable for infrastructure-as-code workflows\n\nAPI-based Configuration\n\nEnables runtime configuration changes\nNo service restarts required\nPerfect for dynamic environments\nSupports automated configuration management\n\nSee Storage Configuration for detailed information about how file-based and API-based configurations work together, storage behavior, and best practices.QuickstartPrevious PageSignersNext PageOn this pageOverviewEnvironment configuration (.env)Environment configuration exampleQueue backend configurationSQS queue provisioning guideStandard queuesFIFO queuesRecommended queue settingsMain configuration file (config.json)1. Signers2. Notifications3. RelayersRPC URL ConfigurationProvider Health ManagementRPC URL Security4. Plugins5. NetworksConfiguration File ExampleConfiguration Management ApproachesFile-based ConfigurationAPI-based Configuration","tokens":7874,"squid":"ink-security_audits","role":"Sentinel","at":1791259823926,"hash":"d4547326da651f40a7001b097b51e0eba69969ba"}
{"url":"https://dev-forum.pyth.network/t/pyth-pro-equity-entitlement-for-the-stocklana-hackathon-best-use-of-pyth-market-data/837/1","domain":"dev-forum.pyth.network","title":"Pyth Pro equity entitlement for the Stocklana hackathon (Best use of Pyth market data) - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Pro equity entitlement for the Stocklana hackathon (Best use of Pyth market data) \n\n Price Feeds\n\n svm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Sep 22\n\n 1 / 5\n\n Sep 21\n\n 9h ago\n\n post by Rayyer on Sep 22\n\n Rayyer\n\n I’m building for the Solana Foundation Stocklana hackathon (submissions close 25 Sep, 20:00 UTC) and targeting the “Best use of Pyth market data” track. I’d like to request a hackathon-scoped Pyth Pro token entitled to US equities.\n Chain\nSolana. Reads are against mainnet; the program is deployed on devnet.\n Timestamp\nReproduced at 2026-09-22 10:12:24 UTC. First seen 2026-09-20.\n Steps to reproduce\n\nSign up at pythdata.app and create an API key (free Terminal trial).\nRequest a crypto feed with it — works, HTTP 200.\nRequest any US equity feed with the same key — HTTP 403.\n\n Code snippet\n# control — crypto: HTTP 200\ncurl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://hermes.pyth.network/v2/updates/price/latest?ids[]=ef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d&parsed=true\"\n\n# Equity.US.AAPL/USD: HTTP 403\ncurl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://hermes.pyth.network/v2/updates/price/latest?ids[]=49f6b65cb1de6b10eaf75e7c03ca029c306d0357e91b5311b175084a5ad55688&parsed=true\"\n# -> Not entitled: feed 49f6b65c...5688 (no grant accepts this feed (asset type 'equity', instrument type 'spot', exchange 1))\n\n# Equity.Index.AAPL/USD (24/7): HTTP 403\ncurl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://hermes.pyth.network/v2/updates/price/latest?ids[]=aaba35e6f33fb973bb2201d48a79ae24795affa6ba8bd50a93dcaf7da0030f36&parsed=true\"\n# -> Not entitled: feed aaba35e6...0f36 (no grant accepts this gated feed; it requires access to one of the following groups: [\"pyth-indices\"])\n\nSo the key authenticates fine; it just isn’t entitled to asset type equity or to the pyth-indices group.\nName of the project\nDeliverable — an options venue on tokenized US stocks (xStocks) on Solana. Writers sell covered calls against real tokenized shares; settlement is physical delivery of the share itself.\nWhy Pyth equity data matters here specifically: the venue’s settlement gate refuses to act when it can’t defend the security’s state — market closed, halted, or a stale or unreliable price. Today it already reads Pyth Lazer equity prices indirectly, through the PythLazer AAPLx/USD entries that Kamino Scope republishes on-chain. A direct entitlement would let the program verify Pyth updates itself instead of trusting an intermediary’s copy. The 24/7 Equity.Index feeds are the other half: they let the interface show the price the venue could have settled against while the reference market is shut, next to the refusal — which is the core of the demo.\nWhat I’m asking for\n\nA hackathon-scoped token entitled to asset type equity, and if at all possible the pyth-indices group.\nTickers: AAPL, NVDA, TSLA, SPY, QQQ, GOOGL, META, MSTR, COIN, CRCL.\nFine for it to expire once judging concludes (2 Oct).\n\nOne technical confirmation, if you have a moment: is the Lazer Solana contract pytd2yyk641x7ak7mkaasSJVXh6YYZnC7wTmtgAyxPt the right on-chain verifier for Pro equity updates requested with formats: [\"solana\"]? I’d rather verify the signed update in the program than read it off-chain.\nContact\n\nEmail (also my Pyth Terminal account): egorslavutich@gmail.com\nDiscord: rayyer_220 | id 677158150691880980\nTelegram: @L0ceo\n\nThanks!\n\n 2\n\n 2\n\n post by KemarTiti on Sep 22\n\n KemarTiti\n\n Hey!\nThanks for reaching out - are sure about this email (egorslavutich@gmail.com)? I could not find you anywhere\n\n post by Rayyer on Sep 22\n\n Rayyer\n\n Yeah, sorry, I messed up with mails, the one that goes with my Pyth Terminal account is egorivaschenko77@gmail.com\n\n post by KemarTiti on Sep 22\n\n KemarTiti\n\n Found you and bumped your permissions for the hackathon!\n\n 13 days later\n\n post by Organic 9 hours ago\n\n Organic\n\n Posted about a similar situation, would really appreciate having the permissions upgraded to the MAG7 (kaushalbalagurusamy@berkeley.edu) for the rest of this week (project due Monday)\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Temporary Pyth Trial Permissions Upgrade for Fellowship\n\n Pyth Community Hackathon\n\n svm\n\n 1\n\n 5\n\n 9h\n\n Clarification on Displaying Equity Price Data in Trading Journal App\n\n Price Feeds\n\n 3\n\n 580\n\n Aug 2025\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 714\n\n Dec 2025\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 23\n\n Apr 9\n\n Powered by Discourse","tokens":2047,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259827601,"hash":"e305bcd6386fc307579a89ab0c04f850b753c43c"}
{"url":"https://io.net/docs/guides/payment/card-payments-faqs","domain":"io.net","title":"Card Payment FAQs - io.net","text":"This page answers common questions about topping up IO Credits with a card (Fiat) through Stripe.\n​General Payment Logic\n\nCompute is paid only with IO Credits, the platform’s internal credits.\nYou can top up IO Credits with a credit or debit card through Stripe.\nThe minimum top-up is $10.00.\nCard top-ups have a 5% payment provider fee.\n\n​FAQ\n​Q. Can I pay for compute directly with a card?\nNo. Compute is paid only with IO Credits. Use your card to top up your credits, then deploy.\n​Q. How do I top up IO Credits with a card?\nClick Buy IO Credits, enter the amount (at least $10.00) and choose USD (Credit/Debit Card). You’re redirected to Stripe to complete the payment.\nThe Stripe payment page shows these line items:\n\nIO Credits Cost\nPayment Provider Fee\n\nAfter a successful payment, the credits are added to your IO Credits balance.\n​Q. How are fees displayed during payment?\nWhen you pay through Stripe, you see:\n\nIO Credits Cost\nPayment Provider Fee (5%)\nTotal Amount\n\n​Q. Can I pay with my local currency?\nYes. If your local currency is supported by Stripe, you can pay with it.\nStripe automatically converts it to USD during checkout.\nThe final amount charged may vary slightly based on exchange rates and your bank’s conversion fees.Was this page helpful?","tokens":317,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259831356,"hash":"43028b4f544b3ccf7f47a53dec465c7692425b84"}
{"url":"https://gov.optimism.io/t/season-6-standard-rollup-charter/8135","domain":"gov.optimism.io","title":"Season 6: Standard Rollup Charter - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 6: Standard Rollup Charter \n\n Proposals 📃Technical Proposals\n\n season-6\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n May 2024\n\n 1 / 19\n\n May 2024\n\n Nov 2024\n\n post by system on May 13, 2024\n\n system\n\n Season 6: Standard Rollup Charter\n\n// This draft will be ratified by the Token House in Voting Cycle #29. For more context on the Blockspace Charter Framework, see here.\nIntroduction\nThe Standard Rollup is the Optimism Collective’s flagship, high-security blockspace product. The Standard Rollup targets the Collective’s highest bar for security, uptime, and decentralization.\nThis Charter applies the principles of the Law of Chains to the specific context of Standard Rollups, and does not modify or supersede the Law of Chains in any way. All conflicts between this Charter and the provisions of Law of Chains will be resolved in favor of the Law of Chains.\nOptimism Governance is responsible for upholding the standards and policies outlined in this Charter and ensuring their consistency with the Law of Chains. All potential changes to the Standard Rollup should be treated with careful consideration by the governance community, to enable long-term, sustainable ecosystems to be built around Standard Rollup blockspace with confidence.\nCriteria\nThe criteria for being a Standard Rollup consist of:\n\nA set of deterministic onchain criteria to ensure that chains are well-configured, on an up-to-date version, and have authorized the Optimism Security Council to perform upgrades.\nA set of lightweight, offchain criteria checked by the Optimism Foundation, which are expected to carry on until they are ready to be safely transitioned to Optimism Governance.\nCompletion of a “history integrity check” by the Optimism Foundation, which is expected to be deprecated in the future (as chains deploy directly as Standard Rollups from day 1).\n\nOnchain Criteria\nThe onchain criteria for Standard Rollups consist of two components: a version check and a configuration check.\nVersion Validation\nThe most important onchain criteria is that a chain be on a standard, governance-approved release of the OP Stack. This check is performed by comparing all bytecode for the chain’s L1 smart contracts to the standard bytecode corresponding to a governance-approved release of the OP Stack.\nVersion validation is a strict, critical requirement. To securely hand over upgradability to the Collective, a chain’s L1 smart contracts must match the release tags defined by this TOML file in the Superchain Registry. At the time of writing, this corresponds to op-contracts@v1.6.0.\nFor those interested, the code currently used in the Superchain Registry to perform version (and configuration) checks can be found here. The Optimism Foundation may, from time to time, update this code (e.g. for quality-of-life improvements or other refactors), so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.\nConfiguration Check\nBeyond being on a standard version of the OP Stack, all configuration values for the chain must be within high-security, well-tested bounds, and all administrative roles must be set correctly. There are two main components:\n\nParameter Configuration: A set of requirements for the “protocol parameters” of a chain — things like block time, gas metering, and other low-level variables — to either equal a certain value, or fall within a specified range. The specific requirements can be found here.\nRole Configuration: A set of requirements for the privileged administrative roles for the chain. The specific requirements can be found here. Primarily, these checks involve ensuring that the Security Council holds authorization to perform upgrades, and other minor Stage 1 requirements (see here).\n\nA more human-readable breakdown of these requirements, including supporting rationale choices, can be found in the configurability page of the OP Stack docs. However, the ultimate source of truth for configuration requirements are the two TOML files linked above, as modified from time to time by Optimism Governance.\nThe Optimism Foundation may, from time to time, update the validation code used in the Superchain Registry to perform these checks, so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.\nRole Configuration Exceptions\nCertain chains’ L1ProxyAdmin role shall satisfy the Standard Rollup Criteria, without the default address 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A, so long as that role is a 3/3 gnosis SAFE between the Chain Governor, Optimism Foundation, and Security Council. These chains are:\n\nBase\nUnichain\n\nThese Chain Governors have publicly committed to using their upgrade key consistent with the “Normal Operation” and “Emergency Response” sections of the Security Council Charter.\nWhile not currently anticipated, the Optimism Foundation may propose expansions of this list from time to time, subject to governance approval via the Protocol Upgrade process.\nOffchain Criteria\nIn addition to the above deterministic criteria, the Optimism Foundation may perform a limited set of manual, offchain checks at its discretion before inclusion as a Standard Rollup. These checks include:\n\nChainID check: ensuring that the Chain ID is unique and does not collide with a pre-existing EVM chain.\nGas Limit check: ensuring that the Chain’s initial GasLimit is configured to a reasonable value based on the then-current status of OP Stack performance testing. (See below for additional context on Gas Limit policy.)\nSecurity Monitoring: ensuring certain standard monitoring tools have been deployed for every chain.\nGovernor/Servicer verification: verifying at the social layer that the chain is indeed deployed and operated by the parties in question, and are not being impersonated.\nOther checks: running other checks (e.g. compliance-related checks) as deemed appropriate.\n\nGiven the fundamentally subjective nature of these checks, they are expected to be administered by the Foundation until they can be safely transitioned to Governance.\nHistory Integrity Checks\nThe Optimism Foundation has implemented a suite of history integrity checks, which can be used to identify historical discrepancies between chains and manually assess their impact. The Optimism Foundation will assess these discrepancies on an as-needed basis. If it believes that these discrepancies risk violating the Law of Chains (e.g., User Protections) in the future once the chain is added as a Standard Rollup, it will deny the chain’s inclusion, even if all other criteria in this document are met.\nThe importance of history integrity checks should quickly diminish over time towards deprecation, since the expectation is that all Standard Rollups launched after the ratification of this Charter are deployed correctly at launch.\nFor more information on the motivation for history integrity checks, see this post.\nNote on Superchain Registry\nThe \"promotion” of a chain (i.e. setting its superchain_level to 1) in the superchain-registry repo will be the canonical indicator of passing the offchain criteria and history integrity checks. Thus, the community can determine whether a given chain falls under the scope of this Charter by checking that:\n\nThe Chain passes all Onchain Criteria checks\nThe Chain has been included by the Foundation in the superchain-registry repo.\n\nEven after history integrity checks are deprecated, it should be expected that the Foundation’s subjective checks are also either eliminated, or transitioned to a process run directly by the community, so that inclusion may be determined purely by onchain data.\nGoverning Policies\nThe Standard Rollup’s governing policies implement additional “reactive” procedures in the event that one or more stakeholder protections in the Law of Chains are violated in such a way that the protocol cannot naturally handle them. Each of these governing policies include reference to a specific protection in the Law of Chains.\nAs such, these governing policies are applications of the existing principles of the Law of Chains. Subject to the provisions of the Law of Chains, these policies are intended to establish predictable enforcement paths for an illustrative (but not exhaustive) list of potential violations of that document.\nIn its current form, all governing policies’ relevant enforcement actions would be taken by the L1ProxyAdmin role, which is held by the Phase 0 Security Council, a 2/2 shared by the Foundation and the Optimism Governance-approved Council (or in the case of the chains listed in “Onchain Criteria–Role Configuration Exceptions” above, a 3/3 with the Phase 0 Council plus the Chain Governor). As such, all enforcement actions are expected to follow the standard Protocol Upgrade vote procedure, which is the existing path used for governance to exercise the L1ProxyAdmin role. In the future, policies may include different enforcement mechanisms (e.g. via unilateral action by other councils, or via direct onchain governor outcomes given explicit authority in the protocol.)\nGovernor Key Recovery\nIn the current version of the OP Stack, the SystemConfigOwner is permitted to change certain chain configuration values. According to the Law of Chains, control of some of these values are afforded to the Chain Governor (e.g. transaction fee margin), and others are afforded to the Chain Servicer (e.g. the batcher hotkey).\nFor convenience, the Configuration Check in the above criteria permits either the Chain Servicer or the Chain Governor to be the SystemConfigOwner, so that Chain Governors can delegate all configuration updates to Servicers. However, because the Chain Governor is also protected by the Law of Chains to be able to switch between Chain Servicers, ultimate control of the SystemConfigOwner role should belong to the Chain Governor.\nIn the event that a Chain Servicer stops fulfilling the wishes of the Chain Governor for those values which the Law of Chains states they should be able to control, or refuses to transfer control of the SystemConfigOwner role in the event that the Chain Governor desires to switch to a different servicer, then the Chain Governor may submit a vote to Optimism Governance to have the Security Council recover the role to an account they control.\nSequencer Censorship\nIn the event that a sequencer is determined to be maliciously censoring valid user transactions, or experiencing unreasonable downtime impacting applications on the chain, they are violating the User Protection of Security, Uptime, and Liveness in the Law of Chains.\nIn the event that a Chain Governor refuses to change its sequencer in reaction (after it has clearly been put on notice of the violation), the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new non-censoring sequencer.\nResponsible GasLimits\nThe OP Stack is rapidly evolving and the boundaries of its performance continue to be pushed. As such, the protocol currently does not implement a hardcoded upper bound on the Gas Limit for a chain. However, this ability must be responsibly exercised to ensure fulfillment of User Protections. Thus:\n\nBefore any GasLimit increase, Chain Governors should submit to the community a public load test which demonstrates stability at that limit.\nAfter any GasLimit increase, if the chain experiences a significant degradation in performance or stability, the GasLimit should promptly be lowered back to its previous value.\n\nIf a Chain Governor fails to take these steps, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the GasLimit.\nResponsible Batch Submission\nThe current version of the OP Stack allows for batches to be submitted with up to a 12 hour delay after initial reception by the sequencer (the “sequencing window”). However, Sequencers are expected to submit at least twice as frequently (i.e. every 6 hours). This affords sufficient time to batch submit in the case of failures or downtime, fulfilling the User Protection to Security, Uptime, and Liveness.\nIn the event that a Chain Governor refuses (after it has clearly been put on notice of the violation) to change its sequencer which repeatedly and intentionally violates this practice, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new compliant sequencer.\nFee Margins\nThe Law of Chains affords Chain Governors the ability to set fee margins for the chain. However, setting the fee margin significantly high can be a form of economic censorship — by making transactions prohibitively expensive to submit, the Governor could effectively violate the User Protection to censorship resistance.\nThe Standard Rollup should allow a maximum fee margin of 100% (i.e., the average cost of transactions should not exceed twice the cost of batch submission). If a Chain Governor sets the fee margin in excess of this, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the Fee Margin.\nResourceMetering\nThe SystemConfigOwner role is currently able to modify the ResourceMetering struct, a low-level set of values which set certain properties of L1→L2 message rules. This is a low-level variable with no reason to be changed outside of a protocol upgrade.\nIf a SystemConfigOwner (either Servicer or Governor) changes this value, the community may submit a vote to Optimism Governance to remove the relevant party and revert the change.\nPrecommitments\nThis section commits to anticipated changes (or lack thereof) for future upgrades to this Charter. While by no means an exhaustive description of the Standard Rollup’s full future development path, the following commitments are core to the expectations of existing and future Superchain ecosystem participants. The Collective should endeavor to do everything in its power to ensure the following commitments are actualized, understanding that non-adherence will fundamentally and irrevocably undermine the legitimacy and trustworthiness of Optimism Governance.\nCollective Fee Take\nThis Charter specifies a fee split of the greater of 1) 2.5% of transaction fee revenue and 2) 15% of chain profit (fee revenue - L1 submission cost).\nIt is extremely important to provide stakeholders in the Collective with a reliable economic model on which they can build sustainable long-term ecosystems. By ratifying this Blockspace Charter, the Collective is signaling its precommitment to all Standard Rollups that it will not modify the fee split parameters outlined above until December 31, 2029 (at the earliest).\nThis does not preclude changes or improvements to the implementation of the fee split contracts, so long as they preserve the original economic spirit. In the event that new sources of fees (or operating costs) are introduced to the protocol, the economics should be updated with minimized impact to the existing expectations and ecosystems in the Superchain.\nGovernor/Servicer Role Separation\nSome policies above (e.g. Governor Key Recovery) arise from an overloading of the SystemConfigOwner role to control configurability options which the Law of Chains affords separately to Governors and Servicers. In a future upgrade (or upgrades), the Collective should transition to a model which establishes independent roles for the Governors and Servicers of Standard Rollups, allowing them to modify the configuration values afforded to them independently. This change should also remove controllability of the Resource Metering Config without a protocol upgrade.\nOssified GasLimits\nBecause the OP Stack’s performance is rapidly improving, the onchain GasLimit criteria is bounded above by a significantly higher value (based on the limits of fault provability) than what chains in practice require for stability. The Governing Policy above reflects the fast-paced nature of gas limits today, in which chains frequently increase their gas limits to test stability. However, as the rate of change slows, the Collective should set a more realistic upper bound, which can only be changed via upgrade.\nDirect Fee Margin Controls\nToday, the “fee margin” discussed in the relevant Governing Policy above is only indirectly influenceable via the control of multiple other configuration variables. In the future, the Collective should implement a protocol improvement which allows the margin to be set more directly, and which imposes a strict upper bound of 100%, to remove the ability to perform economic censorship even temporarily.\n\n Season 6: Guide to Season 6\n\n Season 7 Incentives Eligibility\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Governance Update #9\n\n Optimism Community Call Recaps & Recordings Thread\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Unlisted on May 13, 2024\n\n Listed on May 13, 2024\n\n 13 days later\n\n post by Luckyhooman.eth on May 27, 2024\n\n post by op_julian on May 29, 2024\n\n 9 days later\n\n post by 0xKitsune on Jun 7, 2024\n\n 11 days later\n\n post by kira on Jun 19, 2024\n\n 4 months later\n\n post by system on Oct 17, 2024\n\n post by katie on Oct 21, 2024\n\n post by SEEDGov on Oct 21, 2024\n\n post by mastermojo on Oct 21, 2024\n\n post by Olusoji on Oct 22, 2024\n\n post by Mint on Oct 24, 2024\n\n post by Mint on Oct 25, 2024\n\n post by Gonna.eth on Oct 29, 2024\n\n post by chaselb on Oct 29, 2024\n\n post by Juggs on Nov 1, 2024\n\n post by Bubli.eth on Nov 1, 2024\n\n post by CryptoNeet0 on Nov 7, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovNFT Governance Topic Thread 1\n\n ✨ General\n\n season-6\n\n Hi GovNFT participants! \nA very exciting topic in governance right now is Blockspace Charters, and we want to know your thoughts and ideas on the subject. Relevant links for more information: \n\nSeason 6: Introducing Bloc…\n\n read more\n\n 12\n\n 310\n\n Sep 2024\n\n Updates to the Standard Rollup Charter\n\n Technical Proposals\n\n // This post outlines the key changes made to the Standard Rollup Charter since the v0.1 draft’s introduction earlier this year. For an introductory post explaining how Blockspace Charters work, please see this post. The…\n\n read more\n\n 0\n\n 298\n\n Oct 2024\n\n Blockchain@USC - Delegate Communication Thread\n\n Delegate Updates\n\n Hello all! We are the blockchain club at the University of Southern California. \nOur delegate address is: 0x995013B47EF3A2B07b9e60dA6D1fFf8fa9C53Cf4 \nHere’s what we stand for:\nMission: In our role as a delegate, we striv…\n\n read more\n\n 8\n\n 2.1k\n\n Apr 2025\n\n Season 6: Introducing Blockspace Charters: Superchain-first Governance\n\n Technical Proposals\n\n season-6\n\n Season 6: Introducing Blockspace Charters: Superchain-first Governance\n\nIn Season 6 of Optimism Governance, we intend introduce the Blockspace Charter: a new, technical-focused governing document (and framework) for the …\n\n read more\n\n 1\n\n 2.3k\n\n May 2024\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024","tokens":4867,"squid":"ink-governance","role":"Council Listener","at":1791259842678,"hash":"e3938582000d1d24181f48b300e8c580a35dc93a"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/oracles","domain":"aave.com","title":"Oracles | Aave Protocol Documentation","text":"AaveOracle#\nContract to get asset prices and manage price sources.\nThe source code is available on GitHub.\nThis contract is owned by the Aave Governance.\nWrite Methods#\nsetAssetSources#\nfunction setAssetSources(address[] calldata assets, address[] calldata sources) external override onlyAssetListingOrPoolAdmins\nSets the price sources for given list of assets.\nThis method can only be called by a POOL_ADMIN or ASSET_LISTING_ADMIN.\nPlease look at the ACLManager contract for further details\non system roles.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The addresses of the assets for which source is being setsourcesaddress[]The address of the source of each asset. Length of assets and sources array should be same\nsetFallbackOracle#\nfunction setFallbackOracle(address fallbackOracle) external override onlyAssetListingOrPoolAdmins\nSets/updates the fallbackOracle.\nThis method can only be called by a POOL_ADMIN or ASSET_LISTING_ADMIN.\nPlease look at the ACLManager contract for further details\non system roles.\nInput Parameters:#\nNameTypeDescriptionfallbackOracleaddressThe address of the fallback oracle\nView Methods#\ngetAssetPrice#\nfunction getAssetPrice(address asset) public view override returns (uint256)\nReturns the price of the supported asset in BASE_CURRENCY of the Aave Market in wei.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the asset\nReturn Values:#\nTypeDescriptionuint256The price of the asset in BASE_CURRENCY of the Aave market in wei\ngetAssetsPrices#\nfunction getAssetsPrices(address[] calldata assets) external view override returns (uint256[] memory)\nReturns a list of prices from a list of the supported assets addresses in BASE_CURRENCY of the Aave Market. All prices are in wei.\nInput Parameters:#\nNameTypeDescriptionassetsaddress[]The list of assets addresses for which price is being queried\nReturn Values:#\nTypeDescriptionuint256[]The prices of the given assets in BASE_CURRENCY of the Aave market in wei\ngetSourceOfAsset#\nfunction getSourceOfAsset(address asset) external view override returns (address)\nReturns the address of the price source for an asset address.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the asset\nReturn Values:#\nTypeDescriptionaddressThe address of the source\ngetFallbackOracle#\nfunction getFallbackOracle() external view returns (address)\nReturns the address of the fallback oracle.\nReturn Values:#\nTypeDescriptionaddressThe address of the fallback oracle\nPriceOracleSentinel#\nThe PriceOracleSentinel contract validates if the operations are allowed depending on the PriceOracle health.\nThis feature introduces a grace period for liquidations and disables borrowing under specific circumstances.\nThis feature has been specifically designed for L2s to handle eventual downtime of the sequencer (but can be extended to handle other cases, even on L1s, in the future).\nOnce the PriceOracle gets up after an outage or downtime, users can make their positions healthy during a grace period. The PriceOracle is considered healthy once its completely up and the grace period has passed.\nThe source code is available on GitHub.\nWrite Methods#\nsetSequencerOracle#\nfunction setSequencerOracle(address newSequencerOracle) external onlyPoolAdmin\nUpdates the address of the sequencer oracle.\nThis method can only be called by PoolAdmin.\nThis method can only be called by the Role Admin, specified by Aave Governance, responsible for managing the POOL_ADMIN role.\nInput Parameters:#\nNameTypeDescriptionnewSequencerOracleaddressThe address of the new Sequencer Oracle to be set\nsetGracePeriod#\nfunction setGracePeriod(uint256 newGracePeriod) public onlyRiskOrPoolAdmins\nUpdates the duration of the grace period.\nCan only be called by PoolAdmin or RiskAdmin.\nInput Parameters:#\nNameTypeDescriptionnewGracePerioduint256The duration of new grace period in seconds\nView Methods#\nisBorrowAllowed#\nfunction isBorrowAllowed() external view override returns (bool)\nReturns true if the borrow operation is allowed. The operation is not allowed when PriceOracle is down or the grace period has not passed.\nReturn Values:#\nTypeDescriptionboolReturns true if the borrow operation is allowed (the PriceOracle is up and grace period has passed), false otherwise\nisLiquidationAllowed#\nfunction isLiquidationAllowed() external view override returns (bool)\nReturns true if the liquidation operation is allowed. The operation is not allowed when PriceOracle is down or the grace period has not passed.\nReturn Values:#\nTypeDescriptionboolReturns true if the liquidation operation is allowed (the PriceOracle is up and grace period has passed), false otherwise\ngetSequencerOracle#\nfunction getSequencerOracle() external view returns (address)\nReturns the SequencerOracle.\nReturn Values:#\nTypeDescriptionaddressThe address of the sequencer oracle contract\ngetGracePeriod#\nfunction getGracePeriod() external view returns (uint256)\nReturns the grace period.\nReturn Values:#\nTypeDescriptionuint256The duration of the grace period in secondsPreviousAccess Control ManagerNextPool Addresses Provider","tokens":1267,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259843589,"hash":"1ab4e825d022633d7a043caa23bbd0a691a2a39d"}
{"url":"https://ethresear.ch/t/delayed-execution-and-skipped-transactions/21677/1","domain":"ethresear.ch","title":"Delayed Execution And Skipped Transactions - Execution Layer Research - Ethereum Research","text":"Delayed Execution And Skipped Transactions \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2025\n\n 1 / 27\n\n Feb 2025\n\n May 2025\n\n post by Nero_eth on Feb 5, 2025\n\n Nero_eth\n\n Delayed Execution And Skipped Transactions\nMany thanks to Francesco for feedback, review an collaboration on this!\nEthereum requires every block to be fully executed before it’s considered valid. Each block header commits to a set of execution outputs—like the new state root, receipts, and logs—that result from processing every transaction within that block. This tight coupling means that validators must run every transaction as soon as they see a new block, making execution an inherent part of the critical path.\nA proposed solution, known as Delayed Execution (spec’ed by Francesco, here), offers an elegant approach by decoupling block validation from immediate transaction execution. In this post, I’ll go through how this mechanism works and what it could mean for scaling.\n\nAlso, check out Francesco’s post on delayed execution that explores another potential approach besides the one described in this post.\n\nBlockchain 1x1\nIn Ethereum, each block links to its predecessor by including a cryptographic commitment not only to the previous block’s header but also to the state resulting from all transactions in that block.\nHere’s what happens:\n\nExecution-Dependent Headers: The block header contains fields such as state_root, receipt_root, and logs bloom. These fields are generated only after the transactions have been executed.\nFull Execution: Every validator, upon receiving a new block, must execute all transactions to verify that the header’s commitments are correct. This ensures the block is consistent with the current state but forces nodes to do potentially heavy computation immediately.\n\nstate transition now1241×431 25.1 KB\nThe Concept of Delayed Execution\nDelayed Execution challenges this paradigm by splitting the block processing into two distinct stages:\n\nStatic Validation (Pre-Execution): Validators perform minimal checks using only the previous state. Instead of committing to a freshly computed state_root and related fields, the block header defers these execution outputs by referencing values from the parent block.\nPost-Attestation Execution: The actual execution of transactions is delayed until after the block is initially validated and attested to by the network.\n\nThis decoupling means that validators can quickly agree on the block’s validity without having to execute every transaction upfront. In essence, the block is “chained” to its predecessor using minimal data that does not require full execution.\nstate transition with delayed execution1142×350 24.6 KB\nInstead of fully executing the block before attesting, we can already attest to the block as soon as minimal static validation is done. This relieves stress from the critical path. The following is a simplified illustration of the efficiency gains. It compares the current situation (top) with delayed execution (bottom):\novertime1250×739 162 KB\nThe following graph has a (incomplete) list of things we do during a state transition. Only the initial, static validation phase (which relies solely on the previous state) needs to be executed immediately, while the more complex, state-changing operations can be safely deferred until after attestation.\nstate transition function840×690 105 KB\nIn theory, this change could boost efficiency by as much as 8x, assuming blocks arrive at second 3 of the slot, the attestation deadline stays at second 4, and the worst-case execution time is 1 second (based on the 99.9999th percentile). Special thanks to Marek, Ben, and Łukasz for providing this figure.\nThat said, take this estimate with a grain of salt—you might more realistically expect around a 5x improvement.\nThe Role of Skipped Transactions\nA novel concept in the delayed execution mechanism is the allowance for skipped transactions. Under the current protocol, a single invalid or underfunded transaction can invalidate an entire block. Delayed execution introduces a more resilient approach:\n\nInclusion Without Execution: Transactions are still included in the block’s transaction list but might be marked as “skipped” during execution if they fail certain conditions (e.g., insufficient funds, underpricing, incorrect nonce, or other execution-dependent checks).\nUpfront Fee Payment by Coinbase: To protect the network against the cost of including these transactions, the block proposer’s account (known as the COINBASE) pays an upfront “inclusion cost.” This cost covers basic expenses like the base transaction cost and calldata fees.\nNetwork Compensation: Even if a transaction is skipped, the network is compensated because the inclusion cost has been pre-paid by the COINBASE. This mechanism eliminates the risk of having transactions that consume resources without paying.\n\ndelayed execution flow1181×331 20.9 KB\nBy allowing invalid transactions to be skipped without invalidating the whole block, the proposal shifts the burden of heavy execution away from the immediate validation process. Similar to EIP-7732 (ePBS), we relieve the critical path from the heavy load of execution and state root validation.\nThe Role of COINBASE and Direct Sponsorship (optional)\nDelayed execution could create new opportunities for direct sponsorship. Since the coinbase already covers the inclusion cost upfront, it might be reasonable to extend this responsibility to the base fee as well.\nHere’s how it works:\n\nCOINBASE’s Signature Commitment: The block header comes with a signature from the COINBASE address. This signature is a commitment that the COINBASE is responsible for paying all inclusion costs upfront. In effect, the COINBASE sponsors the execution of transactions that might otherwise be underfunded (=not able to pay for the basefee).\nFlexible Fee Models: With the COINBASE on the hook for initial fees, the protocol can allow transactions that don’t strictly meet the minimum fee requirements. This opens the door to new possibilities such as gasless or sponsored transactions, where the sender might not have enough ETH to pay upfront but is later reimbursed—or the COINBASE recoups the cost—once execution is successful.\n\nDelayed execution and block-level base fee mechanisms are separate topics that should be addressed independently. However, the COINBASE’s commitment to covering the inclusion cost could be extended to also committing to sponsoring the base fee.\nFor additional details on why block-level markets have the potential to contribute to more efficient resource allocation, check out Barnabé’s post on Block-level Markets.\nUnder The Hood\nUnder delayed execution, the way blocks are chained together undergoes a small transformation:\n\nDeferred Execution Outputs: Header fields such as the state_root, receipt_root, and logs bloom are deferred. Instead of reflecting the immediate execution of the block, these fields hold values from the parent block. This means that the block’s validity can be confirmed without performing all of its computational work. Invalid transactions can be included in blocks.\nInclusion Cost Calculation: For every transaction, an inclusion cost is computed that typically includes a base cost (e.g., 21,000 gas), calldata fees, and any blob gas fees. This cost is deducted from the COINBASE’s balance before the transactions are executed. If the transaction is skipped, the COINBASE loses the inclusion cost fronted for the transaction. If the transaction executes successfully, the inclusion cost fronted by the COINBASE is refunded by the sender of the transaction.\nTwo-Phase Validation: The validation process is split into an initial static check—ensuring that the block is structurally sound and that the COINBASE can cover inclusion costs—and a later execution phase, where transactions are processed or skipped as appropriate.\n\nThis design relieves the critical path of execution, allowing blocks to be validated and attested more quickly. It ultimately results in a more scalable and flexible protocol, as the heavy lifting of transaction execution can be handled asynchronously relative to block attestation.\nAdvantages and Trade-Offs\nAdvantages:\n\nIncreased Throughput: By taking transaction execution out of the immediate validation path, blocks can be attested to more rapidly.\nEnhanced Flexibility: The model simplifies introducing new fee mechanisms, such as sponsored and gasless transactions, which can make Ethereum more accessible to users.\n\nTrade-Offs:\n\nLiquidity Requirements for Proposer/Builder: The COINBASE address must be sufficiently funded to cover the maximum possible inclusion costs for a block, which may introduce liquidity constraints, especially during periods of high base fee conditions. The maximum inclusion fee equals gas_limit * base_fee, so, with a base_fee of 100 GWEI, we’re at 3 ETH.\nProtocol Complexity: Introducing delayed execution involves substantial changes to Ethereum’s execution layer. However, unlike other delayed execution proposals, this approach avoids modifying the fork-choice function, which keeps the complexity lower. For a closer look at what these changes entail—especially if you’re interested in adding base fee sponsoring—check out the flow chart in the appendix and the EELS specs here.\n\nAppendix\nFor flowchart enthusiasts, here is how the described mechanism is currently spec’ed; this includes the block-basefee feature and skipped transactions, going through the EELS implementation here:\nflow chart of complete flow with skipped transactions adn sponsoring891×3640 285 KB\n^find the uncompressed version of this diagram here.\n\n Delayed Execution and Free DA\n\n Decoupling throughput from local building\n\n 11\n\n 6\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n post by thegaram33 on Feb 5, 2025\n\n post by g11in on Feb 5, 2025\n\n post by terence on Feb 5, 2025\n\n post by GregTheGreek on Feb 5, 2025\n\n post by thogard785 on Feb 5, 2025\n\n post by Nero_eth on Feb 6, 2025\n\n post by Nero_eth on Feb 6, 2025\n\n post by Nero_eth on Feb 6, 2025\n\n post by LukaszRozmej on Feb 6, 2025\n\n post by linoscope on Feb 6, 2025\n\n post by thogard785 on Feb 6, 2025\n\n post by Nero_eth on Feb 6, 2025\n\n post by Nero_eth on Feb 6, 2025\n\n post by Nero_eth on Feb 6, 2025\n\n post by thogard785 on Feb 6, 2025\n\n post by Nero_eth on Feb 7, 2025\n\n post by GregTheGreek on Feb 11, 2025\n\n post by thogard785 on Feb 11, 2025\n\n post by Nero_eth on Feb 12, 2025\n\n Load more posts below","tokens":2623,"squid":"ink-research","role":"Deep Scholar","at":1791259845824,"hash":"f7ccdebcd98de27b8b243c5b25e40117becbb6c1"}
{"url":"https://gov.optimism.io/t/season-6-standard-rollup-charter/8135/1","domain":"gov.optimism.io","title":"Season 6: Standard Rollup Charter - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 6: Standard Rollup Charter \n\n Proposals 📃Technical Proposals\n\n season-6\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n May 2024\n\n 1 / 19\n\n May 2024\n\n Nov 2024\n\n post by system on May 13, 2024\n\n system\n\n Season 6: Standard Rollup Charter\n\n// This draft will be ratified by the Token House in Voting Cycle #29. For more context on the Blockspace Charter Framework, see here.\nIntroduction\nThe Standard Rollup is the Optimism Collective’s flagship, high-security blockspace product. The Standard Rollup targets the Collective’s highest bar for security, uptime, and decentralization.\nThis Charter applies the principles of the Law of Chains to the specific context of Standard Rollups, and does not modify or supersede the Law of Chains in any way. All conflicts between this Charter and the provisions of Law of Chains will be resolved in favor of the Law of Chains.\nOptimism Governance is responsible for upholding the standards and policies outlined in this Charter and ensuring their consistency with the Law of Chains. All potential changes to the Standard Rollup should be treated with careful consideration by the governance community, to enable long-term, sustainable ecosystems to be built around Standard Rollup blockspace with confidence.\nCriteria\nThe criteria for being a Standard Rollup consist of:\n\nA set of deterministic onchain criteria to ensure that chains are well-configured, on an up-to-date version, and have authorized the Optimism Security Council to perform upgrades.\nA set of lightweight, offchain criteria checked by the Optimism Foundation, which are expected to carry on until they are ready to be safely transitioned to Optimism Governance.\nCompletion of a “history integrity check” by the Optimism Foundation, which is expected to be deprecated in the future (as chains deploy directly as Standard Rollups from day 1).\n\nOnchain Criteria\nThe onchain criteria for Standard Rollups consist of two components: a version check and a configuration check.\nVersion Validation\nThe most important onchain criteria is that a chain be on a standard, governance-approved release of the OP Stack. This check is performed by comparing all bytecode for the chain’s L1 smart contracts to the standard bytecode corresponding to a governance-approved release of the OP Stack.\nVersion validation is a strict, critical requirement. To securely hand over upgradability to the Collective, a chain’s L1 smart contracts must match the release tags defined by this TOML file in the Superchain Registry. At the time of writing, this corresponds to op-contracts@v1.6.0.\nFor those interested, the code currently used in the Superchain Registry to perform version (and configuration) checks can be found here. The Optimism Foundation may, from time to time, update this code (e.g. for quality-of-life improvements or other refactors), so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.\nConfiguration Check\nBeyond being on a standard version of the OP Stack, all configuration values for the chain must be within high-security, well-tested bounds, and all administrative roles must be set correctly. There are two main components:\n\nParameter Configuration: A set of requirements for the “protocol parameters” of a chain — things like block time, gas metering, and other low-level variables — to either equal a certain value, or fall within a specified range. The specific requirements can be found here.\nRole Configuration: A set of requirements for the privileged administrative roles for the chain. The specific requirements can be found here. Primarily, these checks involve ensuring that the Security Council holds authorization to perform upgrades, and other minor Stage 1 requirements (see here).\n\nA more human-readable breakdown of these requirements, including supporting rationale choices, can be found in the configurability page of the OP Stack docs. However, the ultimate source of truth for configuration requirements are the two TOML files linked above, as modified from time to time by Optimism Governance.\nThe Optimism Foundation may, from time to time, update the validation code used in the Superchain Registry to perform these checks, so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.\nRole Configuration Exceptions\nCertain chains’ L1ProxyAdmin role shall satisfy the Standard Rollup Criteria, without the default address 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A, so long as that role is a 3/3 gnosis SAFE between the Chain Governor, Optimism Foundation, and Security Council. These chains are:\n\nBase\nUnichain\n\nThese Chain Governors have publicly committed to using their upgrade key consistent with the “Normal Operation” and “Emergency Response” sections of the Security Council Charter.\nWhile not currently anticipated, the Optimism Foundation may propose expansions of this list from time to time, subject to governance approval via the Protocol Upgrade process.\nOffchain Criteria\nIn addition to the above deterministic criteria, the Optimism Foundation may perform a limited set of manual, offchain checks at its discretion before inclusion as a Standard Rollup. These checks include:\n\nChainID check: ensuring that the Chain ID is unique and does not collide with a pre-existing EVM chain.\nGas Limit check: ensuring that the Chain’s initial GasLimit is configured to a reasonable value based on the then-current status of OP Stack performance testing. (See below for additional context on Gas Limit policy.)\nSecurity Monitoring: ensuring certain standard monitoring tools have been deployed for every chain.\nGovernor/Servicer verification: verifying at the social layer that the chain is indeed deployed and operated by the parties in question, and are not being impersonated.\nOther checks: running other checks (e.g. compliance-related checks) as deemed appropriate.\n\nGiven the fundamentally subjective nature of these checks, they are expected to be administered by the Foundation until they can be safely transitioned to Governance.\nHistory Integrity Checks\nThe Optimism Foundation has implemented a suite of history integrity checks, which can be used to identify historical discrepancies between chains and manually assess their impact. The Optimism Foundation will assess these discrepancies on an as-needed basis. If it believes that these discrepancies risk violating the Law of Chains (e.g., User Protections) in the future once the chain is added as a Standard Rollup, it will deny the chain’s inclusion, even if all other criteria in this document are met.\nThe importance of history integrity checks should quickly diminish over time towards deprecation, since the expectation is that all Standard Rollups launched after the ratification of this Charter are deployed correctly at launch.\nFor more information on the motivation for history integrity checks, see this post.\nNote on Superchain Registry\nThe \"promotion” of a chain (i.e. setting its superchain_level to 1) in the superchain-registry repo will be the canonical indicator of passing the offchain criteria and history integrity checks. Thus, the community can determine whether a given chain falls under the scope of this Charter by checking that:\n\nThe Chain passes all Onchain Criteria checks\nThe Chain has been included by the Foundation in the superchain-registry repo.\n\nEven after history integrity checks are deprecated, it should be expected that the Foundation’s subjective checks are also either eliminated, or transitioned to a process run directly by the community, so that inclusion may be determined purely by onchain data.\nGoverning Policies\nThe Standard Rollup’s governing policies implement additional “reactive” procedures in the event that one or more stakeholder protections in the Law of Chains are violated in such a way that the protocol cannot naturally handle them. Each of these governing policies include reference to a specific protection in the Law of Chains.\nAs such, these governing policies are applications of the existing principles of the Law of Chains. Subject to the provisions of the Law of Chains, these policies are intended to establish predictable enforcement paths for an illustrative (but not exhaustive) list of potential violations of that document.\nIn its current form, all governing policies’ relevant enforcement actions would be taken by the L1ProxyAdmin role, which is held by the Phase 0 Security Council, a 2/2 shared by the Foundation and the Optimism Governance-approved Council (or in the case of the chains listed in “Onchain Criteria–Role Configuration Exceptions” above, a 3/3 with the Phase 0 Council plus the Chain Governor). As such, all enforcement actions are expected to follow the standard Protocol Upgrade vote procedure, which is the existing path used for governance to exercise the L1ProxyAdmin role. In the future, policies may include different enforcement mechanisms (e.g. via unilateral action by other councils, or via direct onchain governor outcomes given explicit authority in the protocol.)\nGovernor Key Recovery\nIn the current version of the OP Stack, the SystemConfigOwner is permitted to change certain chain configuration values. According to the Law of Chains, control of some of these values are afforded to the Chain Governor (e.g. transaction fee margin), and others are afforded to the Chain Servicer (e.g. the batcher hotkey).\nFor convenience, the Configuration Check in the above criteria permits either the Chain Servicer or the Chain Governor to be the SystemConfigOwner, so that Chain Governors can delegate all configuration updates to Servicers. However, because the Chain Governor is also protected by the Law of Chains to be able to switch between Chain Servicers, ultimate control of the SystemConfigOwner role should belong to the Chain Governor.\nIn the event that a Chain Servicer stops fulfilling the wishes of the Chain Governor for those values which the Law of Chains states they should be able to control, or refuses to transfer control of the SystemConfigOwner role in the event that the Chain Governor desires to switch to a different servicer, then the Chain Governor may submit a vote to Optimism Governance to have the Security Council recover the role to an account they control.\nSequencer Censorship\nIn the event that a sequencer is determined to be maliciously censoring valid user transactions, or experiencing unreasonable downtime impacting applications on the chain, they are violating the User Protection of Security, Uptime, and Liveness in the Law of Chains.\nIn the event that a Chain Governor refuses to change its sequencer in reaction (after it has clearly been put on notice of the violation), the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new non-censoring sequencer.\nResponsible GasLimits\nThe OP Stack is rapidly evolving and the boundaries of its performance continue to be pushed. As such, the protocol currently does not implement a hardcoded upper bound on the Gas Limit for a chain. However, this ability must be responsibly exercised to ensure fulfillment of User Protections. Thus:\n\nBefore any GasLimit increase, Chain Governors should submit to the community a public load test which demonstrates stability at that limit.\nAfter any GasLimit increase, if the chain experiences a significant degradation in performance or stability, the GasLimit should promptly be lowered back to its previous value.\n\nIf a Chain Governor fails to take these steps, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the GasLimit.\nResponsible Batch Submission\nThe current version of the OP Stack allows for batches to be submitted with up to a 12 hour delay after initial reception by the sequencer (the “sequencing window”). However, Sequencers are expected to submit at least twice as frequently (i.e. every 6 hours). This affords sufficient time to batch submit in the case of failures or downtime, fulfilling the User Protection to Security, Uptime, and Liveness.\nIn the event that a Chain Governor refuses (after it has clearly been put on notice of the violation) to change its sequencer which repeatedly and intentionally violates this practice, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new compliant sequencer.\nFee Margins\nThe Law of Chains affords Chain Governors the ability to set fee margins for the chain. However, setting the fee margin significantly high can be a form of economic censorship — by making transactions prohibitively expensive to submit, the Governor could effectively violate the User Protection to censorship resistance.\nThe Standard Rollup should allow a maximum fee margin of 100% (i.e., the average cost of transactions should not exceed twice the cost of batch submission). If a Chain Governor sets the fee margin in excess of this, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the Fee Margin.\nResourceMetering\nThe SystemConfigOwner role is currently able to modify the ResourceMetering struct, a low-level set of values which set certain properties of L1→L2 message rules. This is a low-level variable with no reason to be changed outside of a protocol upgrade.\nIf a SystemConfigOwner (either Servicer or Governor) changes this value, the community may submit a vote to Optimism Governance to remove the relevant party and revert the change.\nPrecommitments\nThis section commits to anticipated changes (or lack thereof) for future upgrades to this Charter. While by no means an exhaustive description of the Standard Rollup’s full future development path, the following commitments are core to the expectations of existing and future Superchain ecosystem participants. The Collective should endeavor to do everything in its power to ensure the following commitments are actualized, understanding that non-adherence will fundamentally and irrevocably undermine the legitimacy and trustworthiness of Optimism Governance.\nCollective Fee Take\nThis Charter specifies a fee split of the greater of 1) 2.5% of transaction fee revenue and 2) 15% of chain profit (fee revenue - L1 submission cost).\nIt is extremely important to provide stakeholders in the Collective with a reliable economic model on which they can build sustainable long-term ecosystems. By ratifying this Blockspace Charter, the Collective is signaling its precommitment to all Standard Rollups that it will not modify the fee split parameters outlined above until December 31, 2029 (at the earliest).\nThis does not preclude changes or improvements to the implementation of the fee split contracts, so long as they preserve the original economic spirit. In the event that new sources of fees (or operating costs) are introduced to the protocol, the economics should be updated with minimized impact to the existing expectations and ecosystems in the Superchain.\nGovernor/Servicer Role Separation\nSome policies above (e.g. Governor Key Recovery) arise from an overloading of the SystemConfigOwner role to control configurability options which the Law of Chains affords separately to Governors and Servicers. In a future upgrade (or upgrades), the Collective should transition to a model which establishes independent roles for the Governors and Servicers of Standard Rollups, allowing them to modify the configuration values afforded to them independently. This change should also remove controllability of the Resource Metering Config without a protocol upgrade.\nOssified GasLimits\nBecause the OP Stack’s performance is rapidly improving, the onchain GasLimit criteria is bounded above by a significantly higher value (based on the limits of fault provability) than what chains in practice require for stability. The Governing Policy above reflects the fast-paced nature of gas limits today, in which chains frequently increase their gas limits to test stability. However, as the rate of change slows, the Collective should set a more realistic upper bound, which can only be changed via upgrade.\nDirect Fee Margin Controls\nToday, the “fee margin” discussed in the relevant Governing Policy above is only indirectly influenceable via the control of multiple other configuration variables. In the future, the Collective should implement a protocol improvement which allows the margin to be set more directly, and which imposes a strict upper bound of 100%, to remove the ability to perform economic censorship even temporarily.\n\n Season 6: Guide to Season 6\n\n Season 7 Incentives Eligibility\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Governance Update #9\n\n Optimism Community Call Recaps & Recordings Thread\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Unlisted on May 13, 2024\n\n Listed on May 13, 2024\n\n 13 days later\n\n post by Luckyhooman.eth on May 27, 2024\n\n Luckyhooman.eth\n\n Great work in putting this together, this charter will serve as a vital tool in ensuring all Superchains are compliant with the law of chains and more broadly the Optimism ethos.\n\nWill we( the collective) be expecting this fee split to be paid in OP tokens or in ETH\n\n post by op_julian on May 29, 2024\n\n op_julian\n\n Hi Butterbum\nAll chains use ETH as their gas token, so it would get paid in ETH\n\n 9 days later\n\n post by 0xKitsune on Jun 7, 2024\n\n 0xKitsune\n\n Hello, I noticed that the draft mentions: “The chain’s genesis state and predeploy (0x420000…) contracts are standard, uniform implementations with no malicious code.”\nIs this saying that there can be no other predeploys/state in addition to the default genesis.json, or is this only requiring that the predeploys/genesis state specified in the default OP Stack configuration are not altered?\nWith the Worldchain launch, we will need to migrate the existing WorldApp user’s Safe wallets from Optimism to Worldchain. We were planning on setting the genesis state with a predeploy for each user’s Safe address along with the necessary storage slots set.\nIn general, it would be helpful to have the flexibility to include additional predeploys in the genesis state.\n\n 11 days later\n\n post by kira on Jun 19, 2024\n\n kira\n\n Great draft, thanks for putting it together. I’ve few questions that I would like to present here.\nThe questions assume that I’m building a custom L2 rollup using Op-stack and the chain wants to be a part of the Superchain.\n\nThe chain’s genesis state and predeploy (0x420000...) contracts are standard, uniform implementations with no malicious code.\n\nCan we add one or more pre-deploy contracts, which is not malicious but there to have some additional functionality for the new rollup? If one does add one or more predeploys does it still qualify as a standard rollup?\n\nA standard fee split to the Collective is enforced by smart contracts, as specified [here] and implemented by [this contract].\n\nEven though currently all chains use ETH as their gas token, if someone wants to use a custom native gas token in future, or let’s the new rollup has a feature of custom gas token and then would this affect the stance of the new rollup or existing rollup as a standard Rollup chain?\n\nAdding to the above question how would fee split work in that case if custom gas token is implemented/used? Emphasis on custom gas token because let’s say a chain is made for some specific usecase other than the primary use-cases that current chains have, something like redstone for gaming or some chain for other real-world use-case. How would this affect it?\n\nThanks in advance!\n\n 4 months later\n\n post by system on Oct 17, 2024\n\n system\n\n This Standard Rollup Charter draft has been updated to include the changes outlined in the following update post: Updates to the Standard Rollup Charter\n\n post by katie on Oct 21, 2024\n\n katie\n\n I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\n\n post by SEEDGov on Oct 21, 2024\n\n SEEDGov\n\nWe would like to confirm; this means that no Chain Governor could block the upgrade process for the rest, correct?\nHow is this mitigated with interoperability? In principle, chains that fall behind with an old version should be disconnected since the state transition of all involved is at risk.\n\nThis process initially seems to have the same level of importance as a typical protocol upgrade audit. Is it expected to treat it as such? Is it expected to cover those in conjunction with third-party security teams? It would be great if these followed a report format for public knowledge.\n\n SEEDGov - Delegate Communication Thread\n\n post by mastermojo on Oct 21, 2024\n\n mastermojo\n\n I am one of the Synthetix Ambassadors, and I am an Optimism delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote.\n\n post by Olusoji on Oct 22, 2024\n\n Olusoji\n\n Cool I’m bullish on Optimism\n\n post by Mint on Oct 24, 2024\n\n Mint\n\n (post deleted by author)\n\n post by Mint on Oct 25, 2024\n\n Mint\n\n Hello everyone, Mint blockchain is an Optimism Delegate.\nMint blockchain supports this proposal. We think the proposal strengthens the security and decentralization of the Rollup by establishing clear standards for governance and oversight, while ensuring a flexible approach to integrity checks in the early phases.\n\n post by Gonna.eth on Oct 29, 2024\n\n Gonna.eth\n\nI believe that for each chain included under this role, one developer selected by that chain should be added to the Security Council. This developer would serve not only as a voter but also as a technical representative who is kept updated on the latest changes within their chain and understands the implications of any upgrades. This approach would ensure more informed decision-making while maintaining alignment with each chain’s specific technical requirements.\nIf something should happen to a particular chain this person will be a direct channel between the Security Council and the specific chain.\n\n post by chaselb on Oct 29, 2024\n\n chaselb\n\n I have a bit of a dump of questions:\n\nwhy are the parameters set the way they are?\nI don’t have enough context on the technical implementation of the OP Stack, and the tradeoffs of different parameter changes, so what’s more important (to me) is how these decisions were made. Was it just OP Labs? Input from other teams?\nI also think what’s most important is that standard rollup chains are\n\nEasily verifiable (as in, it’s easy to independently verify that a rollup chain is “standard”)\nSecure\nSufficiently standardized to be interoperable with other standard rollup chains (as interoperable tech improves)\n\nWhat stake holders have given input on this charter?\nWhich chains are expected to follow this charter?\nWho decides which chains get a special multisig with a “Chain Governor” like Base and Unichain? What criteria was used to decide it for Base and Unichain?\n\nAs a side note, I think there should be some way to make these proposals requiring high technical understanding more accessible to the broader community. As I was getting at above, without the background to analyze the technicals of this proposal, or verify its soundness, it would be nice to have some confidence that a lot of thought and review was put into this proposal. I like the format of protocol upgrades where they talk about risks, other reviewers, and the developer advisory board adds a summary and thoughts as well. I think proposals like this could benefit from the same.\nDue to the lack of confidence in my ability to properly critique this proposal, I (on behalf of Blockchain@USC), will likely abstain on this proposal.\n\n Blockchain@USC - Delegate Communication Thread\n\n post by Juggs on Nov 1, 2024\n\n Juggs\n\n Great work! I’m new to the governance side of the community but look forward to contributing!\n\n post by Bubli.eth on Nov 1, 2024\n\n Bubli.eth\n\n This brings Optimism closer to its goal and make it more viable and practical.\n\n post by CryptoNeet0 on Nov 7, 2024\n\n CryptoNeet0\n\n In cases where there’s a conflict between a Chain Governor and Servicer regarding control over configuration values, how would governance balance community input versus technical requirements?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovNFT Governance Topic Thread 1\n\n ✨ General\n\n season-6\n\n Hi GovNFT participants! \nA very exciting topic in governance right now is Blockspace Charters, and we want to know your thoughts and ideas on the subject. Relevant links for more information: \n\nSeason 6: Introducing Bloc…\n\n read more\n\n 12\n\n 310\n\n Sep 2024\n\n Updates to the Standard Rollup Charter\n\n Technical Proposals\n\n // This post outlines the key changes made to the Standard Rollup Charter since the v0.1 draft’s introduction earlier this year. For an introductory post explaining how Blockspace Charters work, please see this post. The…\n\n read more\n\n 0\n\n 298\n\n Oct 2024\n\n Blockchain@USC - Delegate Communication Thread\n\n Delegate Updates\n\n Hello all! We are the blockchain club at the University of Southern California. \nOur delegate address is: 0x995013B47EF3A2B07b9e60dA6D1fFf8fa9C53Cf4 \nHere’s what we stand for:\nMission: In our role as a delegate, we striv…\n\n read more\n\n 8\n\n 2.1k\n\n Apr 2025\n\n Season 6: Introducing Blockspace Charters: Superchain-first Governance\n\n Technical Proposals\n\n season-6\n\n Season 6: Introducing Blockspace Charters: Superchain-first Governance\n\nIn Season 6 of Optimism Governance, we intend introduce the Blockspace Charter: a new, technical-focused governing document (and framework) for the …\n\n read more\n\n 1\n\n 2.3k\n\n May 2024\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024","tokens":6558,"squid":"ink-governance","role":"Council Listener","at":1791259852954,"hash":"fa6df78c86f5799dde4c8796547e933b90fd6e1d"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/swap-features","domain":"aave.com","title":"Swap Features | Aave Protocol Documentation","text":"Swap Features#\nThe Aave Labs interface integrates multiple features integrating token swaps detailed below.\nSwap Tokens#\nThe Swap Tokens feature enables users to swap between tokens using ParaSwap or CoW Protocol as the swap provider, depending on network availability. Tokens traded using CoW Protocol will incur a fee depending on the token pair and swap type:\nDebt Swaps: 0 bps fee across all pairs.All other swap operations: a discounted fee of 15 bps is applied to swaps between correlated assets (e.g. ETH/wstETH); for all other swaps a fee of 25 bps is applied.\nThe list of correlated assets is reviewed and updated periodically:\nStablecoin asset group: USDC, USDT, DAI, GHO, EURC, USDbC, USDe, USDS, sUSDe, RLUSD, PYUSD, LUSD, sDAI, crvUSD, USD₮0, USDC.e, EURe, xDAI, wxDAIETH correlated asset group: weETH, ETH, WETH, wstETH, cbETH, ezETH, wrsETH, osETH, rETH, ETHxBTC correlated asset group: cbBTC, WBTC, LBTC, tBTC, eBTC\nSwap Adapter Contracts#\nThe swap adapter contracts integrate Aave's Flash Loans and the ParaSwap DEX aggregator to facilitate advanced actions such as repaying borrow positions using collateral, swapping collateral assets, swapping borrow positions, and withdrawing and swapping assets. They allow users to perform complex operations in a single transaction, leveraging the liquidity of the Aave protocol and the atomic swapping capabilities of decentralized exchanges.\nThe table below outlines swap feature availability across v3 markets on the Aave Labs interface:\nMarketToken SwapRepay With CollateralCollateral SwapDebt SwapWithdraw & SwapEthereum CoreEthereum PrimeEthereum EtherFiArbitrumAvalancheBaseBNBOptimismPolygonGnosisSonicMetisScrollZKsyncCeloSoneiumLineaPlasmaInk\nRepay With Collateral#\nThe ParaSwapRepayAdapter contract enables users to repay their borrow positions on Aave using their supplied collateral directly, without the need to unwind their positions or provide additional liquidity. It leverages Aave's Flash Loans and the ParaSwap DEX aggregator to swap the user's collateral for the borrowed asset and repay the borrow position in a single atomic transaction.\nBy using this adapter, users can efficiently manage their positions and reduce their borrow positions using their existing collateral, saving on transaction costs and avoiding manual steps.\nThe source code is available on GitHub.\nReference Integration: useCollateralRepaySwap.tsx\nWrite Methods#\nexecuteOperation#\nfunction executeOperation( address asset, uint256 amount, uint256 premium, address initiator, bytes calldata params) external override nonReentrant returns (bool)\nUses the received funds from the flash loan to repay a borrow position on the protocol on behalf of the user. Then, pulls the collateral from the user and swaps it to the debt asset to repay the flash loan.\nThe user should give this contract allowance to pull the aTokens in order to withdraw the underlying asset, swap it, and repay the flash loan.\nSupports only one asset on the flash loan.\nThe params parameter should be the ABI-encoded values of the following:\nIERC20Detailed debtAsset — The address of the borrow position assetuint256 debtRepayAmount — The amount of the borrow position to be repaiduint256 buyAllBalanceOffset — Offset in the ParaSwap calldata if swapping all balanceuint256 rateMode — The rate mode of the borrow position to be repaidbytes paraswapData — Data for the ParaSwap AdapterPermitSignature permitSignature — Struct containing the permit signature, set to zeroes if not used\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the flash-borrowed assetamountuint256The amount of the flash-borrowed assetpremiumuint256The fee of the flash-borrowed assetinitiatoraddressThe address of the flash loan initiatorparamsbytesThe byte-encoded parameters passed when initiating the flash loan\nReturn Values:\nTypeDescriptionboolTrue if the execution of the operation succeeds, false otherwise\nswapAndRepay#\nfunction swapAndRepay( IERC20Detailed collateralAsset, IERC20Detailed debtAsset, uint256 collateralAmount, uint256 debtRepayAmount, uint256 debtRateMode, uint256 buyAllBalanceOffset, bytes calldata paraswapData, PermitSignature calldata permitSignature) external nonReentrant\nSwaps the user's collateral for the debt asset and then repays the borrow position on the protocol on behalf of the user without using flash loans. This method can be used when the temporary transfer of the collateral asset to this contract does not affect the user's position.\nThe user should give this contract allowance to pull the aTokens in order to withdraw the underlying asset.\nInput Parameters:\nNameTypeDescriptioncollateralAssetIERC20DetailedThe address of the collateral asset to be swappeddebtAssetIERC20DetailedThe address of the debt assetcollateralAmountuint256The maximum amount of the collateral to be swappeddebtRepayAmountuint256The amount of the borrow position to be repaid, or maximum amount when repaying alldebtRateModeuint256The rate mode of the borrow position to be repaidbuyAllBalanceOffsetuint256Offset in the ParaSwap calldata if swapping all balance, otherwise 0paraswapDatabytesData for the ParaSwap AdapterpermitSignaturePermitSignatureStruct containing the permit signature, set to zeroes if not used\nPermitSignature Struct#\nstruct PermitSignature { uint256 deadline; uint8 v; bytes32 r; bytes32 s;}\nMembers:\nNameTypeDescriptiondeadlineuint256The deadline timestamp for the permit signaturevuint8The V parameter of the ECDSA signaturerbytes32The R parameter of the ECDSA signaturesbytes32The S parameter of the ECDSA signature\n\nCollateral Swap#\nThe ParaSwapLiquiditySwapAdapter contract allows users to swap their supplied collateral from one asset to another in a single transaction using Aave's Flash Loans and the ParaSwap DEX aggregator.\nThis adapter enables users to rebalance their collateral positions without needing to withdraw and re-supply assets manually. By leveraging flash loans, the user can swap their existing collateral to a new asset and supply it back into the Aave protocol in a single transaction.\nThe source code is available on GitHub.\nReference Integration: useCollateralSwap.tsx\nWrite Methods#\nexecuteOperation#\nfunction executeOperation( address asset, uint256 amount, uint256 premium, address initiator, bytes calldata params) external override nonReentrant returns (bool)\nSwaps the received amount from the flash loan into the specified asset. The received funds from the swap are then supplied into the protocol on behalf of the user.\nThe user should give this contract allowance to pull the aTokens in order to withdraw the underlying asset and repay the flash loan.\nThe params parameter should be the ABI-encoded values of the following:\nIERC20Detailed assetToSwapTo — The address of the underlying asset to be swapped to and supplieduint256 minAmountToReceive — The minimum amount to be received from the swapuint256 swapAllBalanceOffset — Offset in the Augustus calldata if swapping all balance, otherwise 0bytes swapCalldata — Calldata for ParaSwap's Augustus Swapper contractIParaSwapAugustus augustus — Address of ParaSwap's Augustus Swapper contractPermitSignature permitParams — Struct containing the permit signature, set to zeroes if not used\nInput Parameters:\nNameTypeDescriptionassetaddressThe address of the flash-borrowed assetamountuint256The amount of the flash-borrowed assetpremiumuint256The fee of the flash-borrowed assetinitiatoraddressThe address of the flash loan initiatorparamsbytesThe byte-encoded parameters passed when initiating the flash loan\nReturn Values:\nTypeDescriptionboolTrue if the execution of the operation succeeds, false otherwise\nswapAndDeposit#\nfunction swapAndDeposit( IERC20Detailed assetToSwapFrom, IERC20Detailed assetToSwapTo, uint256 amountToSwap, uint256 minAmountToReceive, uint256 swapAllBalanceOffset, bytes calldata swapCalldata, IParaSwapAugustus augustus, PermitSignature calldata permitParams) external nonReentrant\nSwaps an amount of an asset to another and supplies the new asset amount on behalf of the user without using a flash loan. This method can be used when the temporary transfer of the collateral asset to this contract does not affect the user's position.\nThe user should give this contract allowance to pull the aTokens in order to withdraw the underlying asset and perform the swap.\nInput Parameters:\nNameTypeDescriptionassetToSwapFromIERC20DetailedThe address of the underlying asset to be swapped fromassetToSwapToIERC20DetailedThe address of the underlying asset to be swapped to and suppliedamountToSwapuint256Amount to be swapped, or maximum amount when swapping all balanceminAmountToReceiveuint256Minimum amount to be received from the swapswapAllBalanceOffsetuint256Offset in Augustus calldata if swapping all balance, otherwise 0swapCalldatabytesCalldata for ParaSwap's Augustus Swapper contractaugustusIParaSwapAugustusAddress of ParaSwap's Augustus Swapper contractpermitParamsPermitSignatureStruct containing the permit signature, set to zeroes if not used\n\nBorrow Position Swap#\nThe ParaSwapDebtSwapAdapter contracts allow users to swap their borrow positions from one asset to another. They leverage Aave's Flash Loans and the ParaSwap DEX aggregator to perform the swap in a single atomic transaction.\nThere are two versions of the adapter:\n\nParaSwapDebtSwapAdapterV3: The standard version that supports swapping any borrow position asset.\nSource Code: GitHubReference Integration: useDebtSwitch.tsx\n\nParaSwapDebtSwapAdapterV3GHO: A specialized version that supports GHO, where GHO can be flash minted via the ERC-3156 interface.\nSource Code: GitHubReference Integration: useDebtSwitch.tsx\n\nParaSwapDebtSwapAdapterV3#\nThe ParaSwapDebtSwapAdapterV3 contract allows users to swap their borrow positions from one asset to another, enabling borrow position refinancing on the Aave protocol.\nThis adapter leverages Aave's Flash Loans and the ParaSwap DEX aggregator to perform the borrow position swap in a single transaction.\nWrite Methods#\nexecuteOperation\nfunction executeOperation( address[] calldata assets, uint256[] calldata amounts, uint256[] calldata, address initiator, bytes calldata params) external returns (bool)\nPerforms the borrow position swap operation using the received funds from the flash loan.\nPerforms the swap and repay operation using the borrowed funds from the flash loan, and then re-borrows the new borrow position asset to maintain the overall borrow position.\nThe params parameter should be the ABI-encoded values required for the operation, such as:\nThe addresses of the borrow position assets involvedThe rate modes of the borrow positionsParaSwap swap dataAny necessary permit signatures\nInput Parameters:\nNameTypeDescriptionassetsaddress[]The addresses of the assets being borrowed in the flash loanamountsuint256[]The amounts of the assets being borrowedpremiumsuint256[]The fees for the flash loansinitiatoraddressThe address of the flash loan initiatorparamsbytesArbitrary data containing the parameters needed for the operation\nReturn Values:\nTypeDescriptionboolTrue if the execution of the operation succeeds, false otherwise\nParaSwapDebtSwapAdapterV3GHO#\nThe ParaSwapDebtSwapAdapterV3GHO contract is a specialized version of the borrow position swap adapter that supports GHO, allowing users to swap their borrow positions involving GHO. It utilizes the ERC-3156 flash mint interface for GHO.\nPerforms the swap and repay operation using the borrowed funds from the flash loan, and then re-borrows the borrow position asset to maintain the overall borrow position.\nWrite Methods#\nonFlashLoan\nfunction onFlashLoan( address initiator, address token, uint256 amount, uint256 fee, bytes calldata data) external override returns (bytes32)\nThis is the ERC-3156 Flash Loan callback function that gets called when the contract receives a flash loan (in this case, flash mint) from the GHO Flash Minter.\nInput Parameters:\nNameTypeDescriptioninitiatoraddressThe initiator of the flash loantokenaddressThe address of the token being borrowedamountuint256The amount of tokens being borrowedfeeuint256The fee for the flash loandatabytesArbitrary data containing the parameters needed for the operation\nReturn Values:\nTypeDescriptionbytes32The keccak256 hash of the string 'ERC3156FlashBorrower.onFlashLoan'\n\nWithdraw & Swap#\nThe ParaSwapWithdrawSwapAdapter contract allows users to withdraw their supplied assets from Aave and swap them to another asset in a single transaction using the ParaSwap DEX aggregator.\nThis adapter enables users to efficiently exit positions and swap their assets without having to perform multiple transactions, reducing gas costs and simplifying the user experience.\nThe source code is available on GitHub.\nReference Integration: WithdrawAndSwitchActions.tsx\nWrite Methods#\nwithdrawAndSwap#\nfunction withdrawAndSwap( IERC20Detailed assetToSwapFrom, IERC20Detailed assetToSwapTo, uint256 amountToSwap, uint256 minAmountToReceive, uint256 swapAllBalanceOffset, bytes calldata swapCalldata, IParaSwapAugustus augustus, PermitSignature calldata permitParams) external nonReentrant\nSwaps an amount of an asset to another after a withdrawal and transfers the new asset to the user. The user should give this contract allowance to pull the aTokens in order to withdraw the underlying asset and perform the swap.\nInput Parameters:\nNameTypeDescriptionassetToSwapFromIERC20DetailedThe address of the underlying asset to be swapped fromassetToSwapToIERC20DetailedThe address of the underlying asset to be swapped toamountToSwapuint256Amount to be swapped, or maximum amount when swapping all balanceminAmountToReceiveuint256Minimum amount to be received from the swapswapAllBalanceOffsetuint256Offset in Augustus calldata if swapping all balance, otherwise 0swapCalldatabytesCalldata for ParaSwap's Augustus Swapper contractaugustusIParaSwapAugustusAddress of ParaSwap's Augustus Swapper contractpermitParamsPermitSignatureStruct containing the permit signature, set to zeroes if not used\nexecuteOperation#\nNote that in this contract, the executeOperation method is overridden but simply reverts with NOT_SUPPORTED, so it's not intended to be used.PreviousPool ConfiguratorNextVaults","tokens":3547,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259853708,"hash":"33c5f760a614dc2748c838e41a012ccd9ee8d262"}
{"url":"https://ethresear.ch/t/torrents-and-eip-4444/19788/1","domain":"ethresear.ch","title":"Torrents and EIP-4444 - Execution Layer Research - Ethereum Research","text":"Torrents and EIP-4444 \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2024\n\n 1 / 21\n\n Jun 2024\n\n Oct 2024\n\n post by parithosh on Jun 12, 2024\n\n parithosh\n\n Torrents and EIP-4444\nIntroduction\nEIP-4444 aims to limit the historical data that Ethereum nodes need to store. This EIP has two main problems that require solutions: Format for history archival and Methods to reliably retrieve history. The client teams have agreed on a common era files format, solving one half of the problem. The second half of the problem, i.e Method to reliably retrieve history will likely not rely on a single solution. Some client teams may rely on the Portal network, some rely on torrents, others might rely on some form of snapshot storage.\nTorrents for EIP-4444\nTorrents offer us a unique way to distribute this history, torrents as a technology have existed since 2001 and have withstood the test of time. Some client teams, such as Erigon already include a method to sync via torrents that has run in production systems.\nIn order to make some progress on the Torrent approach of history retrieval, the files would first be required. So an era file export was made on a geth running version v1.14.3 . To explore the initial idea, the torrent approach chose pre-merge data as a target. The merge occurred at block height 15537393, meaning all pre-merge data could be archived by choosing a range of 0 to block 15537393. The era files were then created using the command geth --datadir=/data export-history /data/erafiles 0 15537393.\nOnce the era files were created, they were verified using the command era verify roots.txt, with the source of the roots.txt file being this. The entire process has been outlined in this PR comment. The verification output was found to be this log message: Verifying Era1 files verified=1896, elapsed=5h21m49.184s\nThe output era files were then uploaded onto a server and a torrent was created using the software mktorrent. An updated list of trackers was found using the github repo trackerslist. The trackers chosen were a mix of http/https/udp in order to allow for maximal compatibility. The chunk size of the torrent was chosen to be 64MB, which was the max allowed and recommended value for a torrent of this size.\nThe result of this process is now a torrent of size 427GB. This torrent can be imported with this magnet link and a torrent client would be able to pull the entire pre-merge history as era files.\nTradeoffs\nThere are of course some tradeoffs with torrents, as with many of the other EIP-4444 approaches:\n\nTorrents rely on a robust set of peers to share the data, there is however no way to incentivise or ensure that this data is served by peers\nA torrent client would need to be included in the client releases and some client languages might not have a torrent library\nTorrents would de-facto expect the nodes to also seed the content they leech, this would increase node network requirements if they choose to store history\nThe JSON-RPC response needs to take into account that it may not have the data to return a response in case the user decides to not download pre-merge data\n\nConclusion\nA client could potentially include this torrent into their releases and avoid syncing pre-merge data by default, which could then be fetched via torrent if a user requests it (perhaps with a flag similar to --preMergeData=True). The client could also hardcode the hash of the expected data, ensuring that the data retrieved matches what they expect.\nInstructions for re-creating torrent:\n\nSync a geth node using the latest release\nStop the geth node and run geth --datadir=/data export-history /data/erafiles 0 15537393 to export the data in a folder called data/erafiles(Warning, this will use ~427GB of additional space)\nUse the mktorrent tool or the rutorrent GUI to create a torrent. Choose the /data/erafiles/ folder as the source for the data. Next, obtain the latest open trackers from this github repository. Choose a healthy mix of udp/http/https trackers and choose the chunk size of the torrent to be 64MB.\nThe tool should output a .torrent file, the GUI will also allow you to copy a magnet link if that is required\n\nInstructions for download and verification of torrent data:\n\nDownload the torrent data with this magnet link and in a torrent client of your choice: link\nClone the latest release of geth and install the dependencies\nRun make all in the geth repository to build the era binary\nFetch the roots.txt file with the command: wget https://gist.githubusercontent.com/lightclient/528b95ffe434ac7dcbca57bff6dd5bd1/raw/fd660cfedb65cd8f133b510c442287dc8a71660f/roots.txt\nRun era verify roots.txt in the folder to verify the integrity of the data\n\n 9\n\n 5\n\n 2\n\n 2\n\n 2\n\n read \n\n 17\n min\n\n post by imkharn on Jun 12, 2024\n\n post by arnetheduck on Jun 13, 2024\n\n post by kdeme on Jun 13, 2024\n\n post by parithosh on Jun 13, 2024\n\n post by parithosh on Jun 13, 2024\n\n post by arnetheduck on Jun 13, 2024\n\n post by parithosh on Jun 13, 2024\n\n post by arnetheduck on Jun 13, 2024\n\n post by imkharn on Jun 13, 2024\n\n post by parithosh on Jun 14, 2024\n\n post by parithosh on Jun 14, 2024\n\n 14 days later\n\n post by parithosh on Jun 28, 2024\n\n post by chfast on Jun 28, 2024\n\n post by arnetheduck on Jul 1, 2024\n\n 11 days later\n\n post by kdeme on Jul 12, 2024\n\n 12 days later\n\n post by parithosh on Jul 25, 2024\n\n post by chfast on Jul 25, 2024\n\n post by parithosh on Jul 25, 2024\n\n 16 days later\n\n post by r4f4ss on Aug 10, 2024\n\n Load more posts below","tokens":1385,"squid":"ink-research","role":"Deep Scholar","at":1791259855989,"hash":"1156a25fd7c639d152b5b25eea015d215b06507c"}
{"url":"https://gov.optimism.io/t/season-6-standard-rollup-charter/8135/19","domain":"gov.optimism.io","title":"Season 6: Standard Rollup Charter - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Proposals 📃Technical Proposals\n\n season-6\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n May 2024\n\n 19 / 19\n\n Nov 2024\n\n Nov 2024\n\n post by system on May 13, 2024\n\n system\n\n Season 6: Standard Rollup Charter\n\n// This draft will be ratified by the Token House in Voting Cycle #29. For more context on the Blockspace Charter Framework, see here.\nIntroduction\nThe Standard Rollup is the Optimism Collective’s flagship, high-security blockspace product. The Standard Rollup targets the Collective’s highest bar for security, uptime, and decentralization.\nThis Charter applies the principles of the Law of Chains to the specific context of Standard Rollups, and does not modify or supersede the Law of Chains in any way. All conflicts between this Charter and the provisions of Law of Chains will be resolved in favor of the Law of Chains.\nOptimism Governance is responsible for upholding the standards and policies outlined in this Charter and ensuring their consistency with the Law of Chains. All potential changes to the Standard Rollup should be treated with careful consideration by the governance community, to enable long-term, sustainable ecosystems to be built around Standard Rollup blockspace with confidence.\nCriteria\nThe criteria for being a Standard Rollup consist of:\n\nA set of deterministic onchain criteria to ensure that chains are well-configured, on an up-to-date version, and have authorized the Optimism Security Council to perform upgrades.\nA set of lightweight, offchain criteria checked by the Optimism Foundation, which are expected to carry on until they are ready to be safely transitioned to Optimism Governance.\nCompletion of a “history integrity check” by the Optimism Foundation, which is expected to be deprecated in the future (as chains deploy directly as Standard Rollups from day 1).\n\nOnchain Criteria\nThe onchain criteria for Standard Rollups consist of two components: a version check and a configuration check.\nVersion Validation\nThe most important onchain criteria is that a chain be on a standard, governance-approved release of the OP Stack. This check is performed by comparing all bytecode for the chain’s L1 smart contracts to the standard bytecode corresponding to a governance-approved release of the OP Stack.\nVersion validation is a strict, critical requirement. To securely hand over upgradability to the Collective, a chain’s L1 smart contracts must match the release tags defined by this TOML file in the Superchain Registry. At the time of writing, this corresponds to op-contracts@v1.6.0.\nFor those interested, the code currently used in the Superchain Registry to perform version (and configuration) checks can be found here. The Optimism Foundation may, from time to time, update this code (e.g. for quality-of-life improvements or other refactors), so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.\nConfiguration Check\nBeyond being on a standard version of the OP Stack, all configuration values for the chain must be within high-security, well-tested bounds, and all administrative roles must be set correctly. There are two main components:\n\nParameter Configuration: A set of requirements for the “protocol parameters” of a chain — things like block time, gas metering, and other low-level variables — to either equal a certain value, or fall within a specified range. The specific requirements can be found here.\nRole Configuration: A set of requirements for the privileged administrative roles for the chain. The specific requirements can be found here. Primarily, these checks involve ensuring that the Security Council holds authorization to perform upgrades, and other minor Stage 1 requirements (see here).\n\nA more human-readable breakdown of these requirements, including supporting rationale choices, can be found in the configurability page of the OP Stack docs. However, the ultimate source of truth for configuration requirements are the two TOML files linked above, as modified from time to time by Optimism Governance.\nThe Optimism Foundation may, from time to time, update the validation code used in the Superchain Registry to perform these checks, so long as it does not violate the semantic interpretation of the above TOML files, which are subject to Governance approval.\nRole Configuration Exceptions\nCertain chains’ L1ProxyAdmin role shall satisfy the Standard Rollup Criteria, without the default address 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A, so long as that role is a 3/3 gnosis SAFE between the Chain Governor, Optimism Foundation, and Security Council. These chains are:\n\nBase\nUnichain\n\nThese Chain Governors have publicly committed to using their upgrade key consistent with the “Normal Operation” and “Emergency Response” sections of the Security Council Charter.\nWhile not currently anticipated, the Optimism Foundation may propose expansions of this list from time to time, subject to governance approval via the Protocol Upgrade process.\nOffchain Criteria\nIn addition to the above deterministic criteria, the Optimism Foundation may perform a limited set of manual, offchain checks at its discretion before inclusion as a Standard Rollup. These checks include:\n\nChainID check: ensuring that the Chain ID is unique and does not collide with a pre-existing EVM chain.\nGas Limit check: ensuring that the Chain’s initial GasLimit is configured to a reasonable value based on the then-current status of OP Stack performance testing. (See below for additional context on Gas Limit policy.)\nSecurity Monitoring: ensuring certain standard monitoring tools have been deployed for every chain.\nGovernor/Servicer verification: verifying at the social layer that the chain is indeed deployed and operated by the parties in question, and are not being impersonated.\nOther checks: running other checks (e.g. compliance-related checks) as deemed appropriate.\n\nGiven the fundamentally subjective nature of these checks, they are expected to be administered by the Foundation until they can be safely transitioned to Governance.\nHistory Integrity Checks\nThe Optimism Foundation has implemented a suite of history integrity checks, which can be used to identify historical discrepancies between chains and manually assess their impact. The Optimism Foundation will assess these discrepancies on an as-needed basis. If it believes that these discrepancies risk violating the Law of Chains (e.g., User Protections) in the future once the chain is added as a Standard Rollup, it will deny the chain’s inclusion, even if all other criteria in this document are met.\nThe importance of history integrity checks should quickly diminish over time towards deprecation, since the expectation is that all Standard Rollups launched after the ratification of this Charter are deployed correctly at launch.\nFor more information on the motivation for history integrity checks, see this post.\nNote on Superchain Registry\nThe \"promotion” of a chain (i.e. setting its superchain_level to 1) in the superchain-registry repo will be the canonical indicator of passing the offchain criteria and history integrity checks. Thus, the community can determine whether a given chain falls under the scope of this Charter by checking that:\n\nThe Chain passes all Onchain Criteria checks\nThe Chain has been included by the Foundation in the superchain-registry repo.\n\nEven after history integrity checks are deprecated, it should be expected that the Foundation’s subjective checks are also either eliminated, or transitioned to a process run directly by the community, so that inclusion may be determined purely by onchain data.\nGoverning Policies\nThe Standard Rollup’s governing policies implement additional “reactive” procedures in the event that one or more stakeholder protections in the Law of Chains are violated in such a way that the protocol cannot naturally handle them. Each of these governing policies include reference to a specific protection in the Law of Chains.\nAs such, these governing policies are applications of the existing principles of the Law of Chains. Subject to the provisions of the Law of Chains, these policies are intended to establish predictable enforcement paths for an illustrative (but not exhaustive) list of potential violations of that document.\nIn its current form, all governing policies’ relevant enforcement actions would be taken by the L1ProxyAdmin role, which is held by the Phase 0 Security Council, a 2/2 shared by the Foundation and the Optimism Governance-approved Council (or in the case of the chains listed in “Onchain Criteria–Role Configuration Exceptions” above, a 3/3 with the Phase 0 Council plus the Chain Governor). As such, all enforcement actions are expected to follow the standard Protocol Upgrade vote procedure, which is the existing path used for governance to exercise the L1ProxyAdmin role. In the future, policies may include different enforcement mechanisms (e.g. via unilateral action by other councils, or via direct onchain governor outcomes given explicit authority in the protocol.)\nGovernor Key Recovery\nIn the current version of the OP Stack, the SystemConfigOwner is permitted to change certain chain configuration values. According to the Law of Chains, control of some of these values are afforded to the Chain Governor (e.g. transaction fee margin), and others are afforded to the Chain Servicer (e.g. the batcher hotkey).\nFor convenience, the Configuration Check in the above criteria permits either the Chain Servicer or the Chain Governor to be the SystemConfigOwner, so that Chain Governors can delegate all configuration updates to Servicers. However, because the Chain Governor is also protected by the Law of Chains to be able to switch between Chain Servicers, ultimate control of the SystemConfigOwner role should belong to the Chain Governor.\nIn the event that a Chain Servicer stops fulfilling the wishes of the Chain Governor for those values which the Law of Chains states they should be able to control, or refuses to transfer control of the SystemConfigOwner role in the event that the Chain Governor desires to switch to a different servicer, then the Chain Governor may submit a vote to Optimism Governance to have the Security Council recover the role to an account they control.\nSequencer Censorship\nIn the event that a sequencer is determined to be maliciously censoring valid user transactions, or experiencing unreasonable downtime impacting applications on the chain, they are violating the User Protection of Security, Uptime, and Liveness in the Law of Chains.\nIn the event that a Chain Governor refuses to change its sequencer in reaction (after it has clearly been put on notice of the violation), the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new non-censoring sequencer.\nResponsible GasLimits\nThe OP Stack is rapidly evolving and the boundaries of its performance continue to be pushed. As such, the protocol currently does not implement a hardcoded upper bound on the Gas Limit for a chain. However, this ability must be responsibly exercised to ensure fulfillment of User Protections. Thus:\n\nBefore any GasLimit increase, Chain Governors should submit to the community a public load test which demonstrates stability at that limit.\nAfter any GasLimit increase, if the chain experiences a significant degradation in performance or stability, the GasLimit should promptly be lowered back to its previous value.\n\nIf a Chain Governor fails to take these steps, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the GasLimit.\nResponsible Batch Submission\nThe current version of the OP Stack allows for batches to be submitted with up to a 12 hour delay after initial reception by the sequencer (the “sequencing window”). However, Sequencers are expected to submit at least twice as frequently (i.e. every 6 hours). This affords sufficient time to batch submit in the case of failures or downtime, fulfilling the User Protection to Security, Uptime, and Liveness.\nIn the event that a Chain Governor refuses (after it has clearly been put on notice of the violation) to change its sequencer which repeatedly and intentionally violates this practice, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and appoint a new compliant sequencer.\nFee Margins\nThe Law of Chains affords Chain Governors the ability to set fee margins for the chain. However, setting the fee margin significantly high can be a form of economic censorship — by making transactions prohibitively expensive to submit, the Governor could effectively violate the User Protection to censorship resistance.\nThe Standard Rollup should allow a maximum fee margin of 100% (i.e., the average cost of transactions should not exceed twice the cost of batch submission). If a Chain Governor sets the fee margin in excess of this, the community may submit a vote to Optimism Governance to remove the Chain Governor as the SystemConfigOwner and lower the Fee Margin.\nResourceMetering\nThe SystemConfigOwner role is currently able to modify the ResourceMetering struct, a low-level set of values which set certain properties of L1→L2 message rules. This is a low-level variable with no reason to be changed outside of a protocol upgrade.\nIf a SystemConfigOwner (either Servicer or Governor) changes this value, the community may submit a vote to Optimism Governance to remove the relevant party and revert the change.\nPrecommitments\nThis section commits to anticipated changes (or lack thereof) for future upgrades to this Charter. While by no means an exhaustive description of the Standard Rollup’s full future development path, the following commitments are core to the expectations of existing and future Superchain ecosystem participants. The Collective should endeavor to do everything in its power to ensure the following commitments are actualized, understanding that non-adherence will fundamentally and irrevocably undermine the legitimacy and trustworthiness of Optimism Governance.\nCollective Fee Take\nThis Charter specifies a fee split of the greater of 1) 2.5% of transaction fee revenue and 2) 15% of chain profit (fee revenue - L1 submission cost).\nIt is extremely important to provide stakeholders in the Collective with a reliable economic model on which they can build sustainable long-term ecosystems. By ratifying this Blockspace Charter, the Collective is signaling its precommitment to all Standard Rollups that it will not modify the fee split parameters outlined above until December 31, 2029 (at the earliest).\nThis does not preclude changes or improvements to the implementation of the fee split contracts, so long as they preserve the original economic spirit. In the event that new sources of fees (or operating costs) are introduced to the protocol, the economics should be updated with minimized impact to the existing expectations and ecosystems in the Superchain.\nGovernor/Servicer Role Separation\nSome policies above (e.g. Governor Key Recovery) arise from an overloading of the SystemConfigOwner role to control configurability options which the Law of Chains affords separately to Governors and Servicers. In a future upgrade (or upgrades), the Collective should transition to a model which establishes independent roles for the Governors and Servicers of Standard Rollups, allowing them to modify the configuration values afforded to them independently. This change should also remove controllability of the Resource Metering Config without a protocol upgrade.\nOssified GasLimits\nBecause the OP Stack’s performance is rapidly improving, the onchain GasLimit criteria is bounded above by a significantly higher value (based on the limits of fault provability) than what chains in practice require for stability. The Governing Policy above reflects the fast-paced nature of gas limits today, in which chains frequently increase their gas limits to test stability. However, as the rate of change slows, the Collective should set a more realistic upper bound, which can only be changed via upgrade.\nDirect Fee Margin Controls\nToday, the “fee margin” discussed in the relevant Governing Policy above is only indirectly influenceable via the control of multiple other configuration variables. In the future, the Collective should implement a protocol improvement which allows the margin to be set more directly, and which imposes a strict upper bound of 100%, to remove the ability to perform economic censorship even temporarily.\n\n Season 6: Guide to Season 6\n\n Season 7 Incentives Eligibility\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n Governance Update #9\n\n Optimism Community Call Recaps & Recordings Thread\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Unlisted on May 13, 2024\n\n Listed on May 13, 2024\n\n 13 days later\n\n post by Luckyhooman.eth on May 27, 2024\n\n Luckyhooman.eth\n\n Great work in putting this together, this charter will serve as a vital tool in ensuring all Superchains are compliant with the law of chains and more broadly the Optimism ethos.\n\nWill we( the collective) be expecting this fee split to be paid in OP tokens or in ETH\n\n post by op_julian on May 29, 2024\n\n op_julian\n\n Hi Butterbum\nAll chains use ETH as their gas token, so it would get paid in ETH\n\n 9 days later\n\n post by 0xKitsune on Jun 7, 2024\n\n 0xKitsune\n\n Hello, I noticed that the draft mentions: “The chain’s genesis state and predeploy (0x420000…) contracts are standard, uniform implementations with no malicious code.”\nIs this saying that there can be no other predeploys/state in addition to the default genesis.json, or is this only requiring that the predeploys/genesis state specified in the default OP Stack configuration are not altered?\nWith the Worldchain launch, we will need to migrate the existing WorldApp user’s Safe wallets from Optimism to Worldchain. We were planning on setting the genesis state with a predeploy for each user’s Safe address along with the necessary storage slots set.\nIn general, it would be helpful to have the flexibility to include additional predeploys in the genesis state.\n\n 11 days later\n\n post by kira on Jun 19, 2024\n\n kira\n\n Great draft, thanks for putting it together. I’ve few questions that I would like to present here.\nThe questions assume that I’m building a custom L2 rollup using Op-stack and the chain wants to be a part of the Superchain.\n\nThe chain’s genesis state and predeploy (0x420000...) contracts are standard, uniform implementations with no malicious code.\n\nCan we add one or more pre-deploy contracts, which is not malicious but there to have some additional functionality for the new rollup? If one does add one or more predeploys does it still qualify as a standard rollup?\n\nA standard fee split to the Collective is enforced by smart contracts, as specified [here] and implemented by [this contract].\n\nEven though currently all chains use ETH as their gas token, if someone wants to use a custom native gas token in future, or let’s the new rollup has a feature of custom gas token and then would this affect the stance of the new rollup or existing rollup as a standard Rollup chain?\n\nAdding to the above question how would fee split work in that case if custom gas token is implemented/used? Emphasis on custom gas token because let’s say a chain is made for some specific usecase other than the primary use-cases that current chains have, something like redstone for gaming or some chain for other real-world use-case. How would this affect it?\n\nThanks in advance!\n\n 4 months later\n\n post by system on Oct 17, 2024\n\n system\n\n This Standard Rollup Charter draft has been updated to include the changes outlined in the following update post: Updates to the Standard Rollup Charter\n\n post by katie on Oct 21, 2024\n\n katie\n\n I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.\n\n post by SEEDGov on Oct 21, 2024\n\n SEEDGov\n\nWe would like to confirm; this means that no Chain Governor could block the upgrade process for the rest, correct?\nHow is this mitigated with interoperability? In principle, chains that fall behind with an old version should be disconnected since the state transition of all involved is at risk.\n\nThis process initially seems to have the same level of importance as a typical protocol upgrade audit. Is it expected to treat it as such? Is it expected to cover those in conjunction with third-party security teams? It would be great if these followed a report format for public knowledge.\n\n SEEDGov - Delegate Communication Thread\n\n post by mastermojo on Oct 21, 2024\n\n mastermojo\n\n I am one of the Synthetix Ambassadors, and I am an Optimism delegate [Delegate Commitments - #65 by mastermojo ] with sufficient voting power, and I believe this proposal is ready to move to a vote.\n\n post by Olusoji on Oct 22, 2024\n\n Olusoji\n\n Cool I’m bullish on Optimism\n\n post by Mint on Oct 24, 2024\n\n Mint\n\n (post deleted by author)\n\n post by Mint on Oct 25, 2024\n\n Mint\n\n Hello everyone, Mint blockchain is an Optimism Delegate.\nMint blockchain supports this proposal. We think the proposal strengthens the security and decentralization of the Rollup by establishing clear standards for governance and oversight, while ensuring a flexible approach to integrity checks in the early phases.\n\n post by Gonna.eth on Oct 29, 2024\n\n Gonna.eth\n\nI believe that for each chain included under this role, one developer selected by that chain should be added to the Security Council. This developer would serve not only as a voter but also as a technical representative who is kept updated on the latest changes within their chain and understands the implications of any upgrades. This approach would ensure more informed decision-making while maintaining alignment with each chain’s specific technical requirements.\nIf something should happen to a particular chain this person will be a direct channel between the Security Council and the specific chain.\n\n post by chaselb on Oct 29, 2024\n\n chaselb\n\n I have a bit of a dump of questions:\n\nwhy are the parameters set the way they are?\nI don’t have enough context on the technical implementation of the OP Stack, and the tradeoffs of different parameter changes, so what’s more important (to me) is how these decisions were made. Was it just OP Labs? Input from other teams?\nI also think what’s most important is that standard rollup chains are\n\nEasily verifiable (as in, it’s easy to independently verify that a rollup chain is “standard”)\nSecure\nSufficiently standardized to be interoperable with other standard rollup chains (as interoperable tech improves)\n\nWhat stake holders have given input on this charter?\nWhich chains are expected to follow this charter?\nWho decides which chains get a special multisig with a “Chain Governor” like Base and Unichain? What criteria was used to decide it for Base and Unichain?\n\nAs a side note, I think there should be some way to make these proposals requiring high technical understanding more accessible to the broader community. As I was getting at above, without the background to analyze the technicals of this proposal, or verify its soundness, it would be nice to have some confidence that a lot of thought and review was put into this proposal. I like the format of protocol upgrades where they talk about risks, other reviewers, and the developer advisory board adds a summary and thoughts as well. I think proposals like this could benefit from the same.\nDue to the lack of confidence in my ability to properly critique this proposal, I (on behalf of Blockchain@USC), will likely abstain on this proposal.\n\n Blockchain@USC - Delegate Communication Thread\n\n post by Juggs on Nov 1, 2024\n\n Juggs\n\n Great work! I’m new to the governance side of the community but look forward to contributing!\n\n post by Bubli.eth on Nov 1, 2024\n\n Bubli.eth\n\n This brings Optimism closer to its goal and make it more viable and practical.\n\n post by CryptoNeet0 on Nov 7, 2024\n\n CryptoNeet0\n\n In cases where there’s a conflict between a Chain Governor and Servicer regarding control over configuration values, how would governance balance community input versus technical requirements?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n GovNFT Governance Topic Thread 1\n\n ✨ General\n\n season-6\n\n Hi GovNFT participants! \nA very exciting topic in governance right now is Blockspace Charters, and we want to know your thoughts and ideas on the subject. Relevant links for more information: \n\nSeason 6: Introducing Bloc…\n\n read more\n\n 12\n\n 310\n\n Sep 2024\n\n Updates to the Standard Rollup Charter\n\n Technical Proposals\n\n // This post outlines the key changes made to the Standard Rollup Charter since the v0.1 draft’s introduction earlier this year. For an introductory post explaining how Blockspace Charters work, please see this post. The…\n\n read more\n\n 0\n\n 298\n\n Oct 2024\n\n Blockchain@USC - Delegate Communication Thread\n\n Delegate Updates\n\n Hello all! We are the blockchain club at the University of Southern California. \nOur delegate address is: 0x995013B47EF3A2B07b9e60dA6D1fFf8fa9C53Cf4 \nHere’s what we stand for:\nMission: In our role as a delegate, we striv…\n\n read more\n\n 8\n\n 2.1k\n\n Apr 2025\n\n Season 6: Introducing Blockspace Charters: Superchain-first Governance\n\n Technical Proposals\n\n season-6\n\n Season 6: Introducing Blockspace Charters: Superchain-first Governance\n\nIn Season 6 of Optimism Governance, we intend introduce the Blockspace Charter: a new, technical-focused governing document (and framework) for the …\n\n read more\n\n 1\n\n 2.3k\n\n May 2024\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024","tokens":6549,"squid":"ink-governance","role":"Council Listener","at":1791259863254,"hash":"344bb810eee8fd1f5a7fa0f6c2f62433919430b4"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/vaults","domain":"aave.com","title":"Vaults | Aave Protocol Documentation","text":"ATokenVault#\nThe ATokenVault contract is an ERC-4626 compliant yield-bearing vault designed for Aave v3. It allows users to supply and withdraw ERC-20 tokens supported by Aave v3, automatically managing asset supply and withdrawal within the Aave Protocol. This vault also enables managers to collect a fee on the yield generated.\nThe smart contract source code is available on GitHub.\nWrite Methods#\ninitialize#\nfunction initialize( address owner, uint256 initialFee, string memory shareName, string memory shareSymbol, uint256 initialLockDeposit) external initializer\nInitializes the vault, setting its initial parameters and initializing inherited contracts. An initial non-zero deposit (in underlying tokens) is required to prevent frontrunning attacks. It does not initialize the OwnableUpgradeable contract to avoid setting the proxy admin as the owner.\nInput Parameters:#\nNameTypeDescriptionowneraddressThe address to set as the owner of the vault.initialFeeuint256The initial fee to set, expressed in wad, where (1 \\times 10^18) is 100%.shareNamestringThe name to set for the vault's shares.shareSymbolstringThe symbol to set for the vault's shares.initialLockDeposituint256The initial amount of underlying assets to deposit. This must be a non-zero, non-trivial amount, depending on the underlying asset's decimals.\ndeposit#\nfunction deposit(uint256 assets, address receiver) public override returns (uint256)\nDeposits assets (underlying tokens) into the vault and mints a corresponding amount of vault shares to the receiver.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of underlying assets to deposit.receiveraddressThe address to which vault shares will be minted.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares minted.\ndepositATokens#\nfunction depositATokens(uint256 assets, address receiver) public override returns (uint256)\nDeposits assets (aTokens) directly into the vault and mints a corresponding amount of vault shares to the receiver.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of aTokens to deposit.receiveraddressThe address to which vault shares will be minted.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares minted.\ndepositWithSig#\nfunction depositWithSig( uint256 assets, address receiver, address depositor, EIP712Signature calldata sig) public override returns (uint256)\nDeposits assets (underlying tokens) into the vault on behalf of a depositor, authenticated by an EIP-712 signature. Vault shares are minted to the receiver.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of underlying assets to deposit.receiveraddressThe address to which vault shares will be minted.depositoraddressThe address of the actual depositor, whose signature is provided.sigEIP712SignatureThe EIP-712 signature for the deposit transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares minted.\ndepositATokensWithSig#\nfunction depositATokensWithSig( uint256 assets, address receiver, address depositor, EIP712Signature calldata sig) public override returns (uint256)\nDeposits assets (aTokens) directly into the vault on behalf of a depositor, authenticated by an EIP-712 signature. Vault shares are minted to the receiver.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of aTokens to deposit.receiveraddressThe address to which vault shares will be minted.depositoraddressThe address of the actual depositor, whose signature is provided.sigEIP712SignatureThe EIP-712 signature for the deposit transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares minted.\nmint#\nfunction mint(uint256 shares, address receiver) public override returns (uint256)\nMints an exact amount of shares (vault shares) to the receiver by depositing the calculated amount of underlying assets.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The exact amount of vault shares to mint.receiveraddressThe address to which vault shares will be minted.\nReturn Values:#\nTypeDescriptionuint256The amount of underlying assets required to mint the specified shares.\nmintWithATokens#\nfunction mintWithATokens(uint256 shares, address receiver) public override returns (uint256)\nMints an exact amount of shares (vault shares) to the receiver by depositing the calculated amount of aTokens.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The exact amount of vault shares to mint.receiveraddressThe address to which vault shares will be minted.\nReturn Values:#\nTypeDescriptionuint256The amount of aTokens required to mint the specified shares.\nmintWithSig#\nfunction mintWithSig( uint256 shares, address receiver, address depositor, EIP712Signature calldata sig) public override returns (uint256)\nMints an exact amount of shares (vault shares) to the receiver on behalf of a depositor, authenticated by an EIP-712 signature, by depositing the calculated amount of underlying assets.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The exact amount of vault shares to mint.receiveraddressThe address to which vault shares will be minted.depositoraddressThe address of the actual depositor, whose signature is provided.sigEIP712SignatureThe EIP-712 signature for the mint transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of underlying assets required to mint the specified shares.\nmintWithATokensWithSig#\nfunction mintWithATokensWithSig( uint256 shares, address receiver, address depositor, EIP712Signature calldata sig) public override returns (uint256)\nMints an exact amount of shares (vault shares) to the receiver on behalf of a depositor, authenticated by an EIP-712 signature, by depositing the calculated amount of aTokens.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The exact amount of vault shares to mint.receiveraddressThe address to which vault shares will be minted.depositoraddressThe address of the actual depositor, whose signature is provided.sigEIP712SignatureThe EIP-712 signature for the mint transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of aTokens required to mint the specified shares.\nwithdraw#\nfunction withdraw( uint256 assets, address receiver, address owner) public override returns (uint256)\nWithdraws assets (underlying tokens) from the vault and sends them to the receiver. The corresponding vault shares are burned from the owner.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of underlying assets to withdraw.receiveraddressThe address to which the underlying assets will be sent.owneraddressThe address from which vault shares will be burned.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares burned for the withdrawal.\nwithdrawATokens#\nfunction withdrawATokens(uint256 assets, address receiver, address owner) public override returns (uint256)\nWithdraws assets (aTokens) directly from the vault and sends them to the receiver. The corresponding vault shares are burned from the owner.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of aTokens to withdraw.receiveraddressThe address to which the aTokens will be sent.owneraddressThe address from which vault shares will be burned.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares burned for the withdrawal.\nwithdrawWithSig#\nfunction withdrawWithSig( uint256 assets, address receiver, address owner, EIP712Signature calldata sig) public override returns (uint256)\nWithdraws assets (underlying tokens) from the vault and sends them to the receiver. The corresponding vault shares are burned from the owner, authenticated by an EIP-712 signature.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of underlying assets to withdraw.receiveraddressThe address to which the underlying assets will be sent.owneraddressThe address from which vault shares will be burned. This address must be the signatory.sigEIP712SignatureThe EIP-712 signature for the withdrawal transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares burned for the withdrawal.\nwithdrawATokensWithSig#\nfunction withdrawATokensWithSig( uint256 assets, address receiver, address owner, EIP712Signature calldata sig) public override returns (uint256)\nWithdraws assets (aTokens) directly from the vault and sends them to the receiver. The corresponding vault shares are burned from the owner, authenticated by an EIP-712 signature.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of aTokens to withdraw.receiveraddressThe address to which the aTokens will be sent.owneraddressThe address from which vault shares will be burned. This address must be the signatory.sigEIP712SignatureThe EIP-712 signature for the withdrawal transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares burned for the withdrawal.\nredeem#\nfunction redeem( uint256 shares, address receiver, address owner) public override returns (uint256)\nRedeems shares (vault shares) for the underlying assets, which are sent to the receiver. The shares are burned from the owner.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The amount of vault shares to redeem.receiveraddressThe address to which the underlying assets will be sent.owneraddressThe address from which vault shares will be burned.\nReturn Values:#\nTypeDescriptionuint256The amount of underlying assets received for the shares.\nredeemAsATokens#\nfunction redeemAsATokens(uint256 shares, address receiver, address owner) public override returns (uint256)\nRedeems shares (vault shares) for aTokens, which are sent to the receiver. The shares are burned from the owner.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The amount of vault shares to redeem.receiveraddressThe address to which the aTokens will be sent.owneraddressThe address from which vault shares will be burned.\nReturn Values:#\nTypeDescriptionuint256The amount of aTokens received for the shares.\nredeemWithSig#\nfunction redeemWithSig( uint256 shares, address receiver, address owner, EIP712Signature calldata sig) public override returns (uint256)\nRedeems shares (vault shares) for the underlying assets, which are sent to the receiver. The shares are burned from the owner, authenticated by an EIP-712 signature.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The amount of vault shares to redeem.receiveraddressThe address to which the underlying assets will be sent.owneraddressThe address from which vault shares will be burned. This address must be the signatory.sigEIP712SignatureThe EIP-712 signature for the redemption transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of underlying assets received for the shares.\nredeemWithATokensWithSig#\nfunction redeemWithATokensWithSig( uint256 shares, address receiver, address owner, EIP712Signature calldata sig) public override returns (uint256)\nRedeems shares (vault shares) for aTokens, which are sent to the receiver. The shares are burned from the owner, authenticated by an EIP-712 signature.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The amount of vault shares to redeem.receiveraddressThe address to which the aTokens will be sent.owneraddressThe address from which vault shares will be burned. This address must be the signatory.sigEIP712SignatureThe EIP-712 signature for the redemption transaction, including v, r, s parameters, and deadline.\nReturn Values:#\nTypeDescriptionuint256The amount of aTokens received for the shares.\nsetFee#\nfunction setFee(uint256 newFee) public override onlyOwner\nSets a new fee percentage for the vault. This function can only be called by the vault owner. Accrues current yield before updating the fee.\nInput Parameters:#\nNameTypeDescriptionnewFeeuint256The new fee to set, expressed in wad, where (1 \\times 10^18) is 100%.\nwithdrawFees#\nfunction withdrawFees(address to, uint256 amount) public override onlyOwner\nWithdraws amount of accumulated fees (in aTokens) to the specified to address. This function can only be called by the vault owner. Accrues current yield before withdrawing fees.\nInput Parameters:#\nNameTypeDescriptiontoaddressThe address to which the collected fees will be sent.amountuint256The amount of fees to withdraw.\nclaimRewards#\nfunction claimRewards(address to) public override onlyOwner\nClaims any pending rewards accumulated by the vault and sends them to the specified to address. This function can only be called by the vault owner.\nInput Parameters:#\nNameTypeDescriptiontoaddressThe address to which the claimed rewards will be sent.\nemergencyRescue#\nfunction emergencyRescue( address token, address to, uint256 amount) public override onlyOwner\nAllows the vault owner to rescue an arbitrary amount of an ERC-20 token that was mistakenly sent to the vault, transferring it to the to address. This function cannot be used to rescue the AToken that the vault is designed to hold.\nInput Parameters:#\nNameTypeDescriptiontokenaddressThe address of the ERC-20 token to rescue. Cannot be the vault's AToken.toaddressThe address to which the rescued tokens will be sent.amountuint256The amount of tokens to rescue.\nView Methods#\nmaxDeposit#\nfunction maxDeposit(address) public view override returns (uint256)\nReturns the maximum amount of underlying assets that can be deposited into the vault. This is determined by the Aave protocol's supply cap and the current supplied amount.\nInput Parameters:#\nNameTypeDescription-addressPlaceholder for receiver (not used in computation).\nReturn Values:#\nTypeDescriptionuint256The maximum amount of underlying assets that can be deposited.\nmaxMint#\nfunction maxMint(address) public view override returns (uint256)\nReturns the maximum amount of vault shares that can be minted. This is derived from the maximum suppliable assets converted to shares.\nInput Parameters:#\nNameTypeDescription-addressPlaceholder for receiver (not used in computation).\nReturn Values:#\nTypeDescriptionuint256The maximum amount of vault shares that can be minted.\nmaxWithdraw#\nfunction maxWithdraw(address owner) public view override returns (uint256)\nReturns the maximum amount of underlying assets that can be withdrawn by a specific owner. This is limited by the vault's balance and Aave's available liquidity.\nInput Parameters:#\nNameTypeDescriptionowneraddressThe address of the share owner whose maximum withdrawal is being queried.\nReturn Values:#\nTypeDescriptionuint256The maximum amount of underlying assets that can be withdrawn.\nmaxRedeem#\nfunction maxRedeem(address owner) public view override returns (uint256)\nReturns the maximum amount of vault shares that can be redeemed by a specific owner. This is limited by the vault's balance and Aave's available liquidity.\nInput Parameters:#\nNameTypeDescriptionowneraddressThe address of the share owner whose maximum redemption is being queried.\nReturn Values:#\nTypeDescriptionuint256The maximum amount of vault shares that can be redeemed.\npreviewDeposit#\nfunction previewDeposit(uint256 assets) public view override returns (uint256)\nProvides a preview of the amount of vault shares that would be minted for a given assets deposit.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of underlying assets to preview deposit for.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares that would be received.\npreviewMint#\nfunction previewMint(uint256 shares) public view override returns (uint256)\nProvides a preview of the amount of underlying assets that would be required to mint a given shares amount of vault shares.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The amount of vault shares to preview mint for.\nReturn Values:#\nTypeDescriptionuint256The amount of underlying assets that would be required.\npreviewWithdraw#\nfunction previewWithdraw(uint256 assets) public view override returns (uint256)\nProvides a preview of the amount of vault shares that would be burned for a given assets withdrawal.\nInput Parameters:#\nNameTypeDescriptionassetsuint256The amount of underlying assets to preview withdrawal for.\nReturn Values:#\nTypeDescriptionuint256The amount of vault shares that would be burned.\npreviewRedeem#\nfunction previewRedeem(uint256 shares) public view override returns (uint256)\nProvides a preview of the amount of underlying assets that would be received for a given shares redemption.\nInput Parameters:#\nNameTypeDescriptionsharesuint256The amount of vault shares to preview redeem for.\nReturn Values:#\nTypeDescriptionuint256The amount of underlying assets that would be received.\ndomainSeparator#\nfunction domainSeparator() public view override returns (bytes32)\nReturns the EIP-712 domain separator for this contract.\nReturn Values:#\nTypeDescriptionbytes32The EIP-712 domain separator.\ntotalAssets#\nfunction totalAssets() public view override returns (uint256)\nReports the total assets managed by the vault, net of fees, for vault share logic.\nReturn Values:#\nTypeDescriptionuint256The total amount of assets held by the vault (net of fees).\ngetClaimableFees#\nfunction getClaimableFees() public view override returns (uint256)\nCalculates and returns the total amount of fees that are currently claimable by the vault manager.\nReturn Values:#\nTypeDescriptionuint256The total amount of fees that can be claimed.\ngetSigNonce#\nfunction getSigNonce(address signer) public view override returns (uint256)\nReturns the current nonce for a given signer address, used for EIP-712 signatures to prevent replay attacks.\nInput Parameters:#\nNameTypeDescriptionsigneraddressThe address whose EIP-712 signature nonce is being queried.\nReturn Values:#\nTypeDescriptionuint256The current nonce for the specified signer.\ngetLastVaultBalance#\nfunction getLastVaultBalance() public view override returns (uint256)\nReturns the last recorded balance of the vault's AToken. This value is updated when yield is accrued.\nReturn Values:#\nTypeDescriptionuint256The last recorded balance of ATokens held by the vault.\ngetFee#\nfunction getFee() public view override returns (uint256)\nReturns the current fee percentage set for the vault.\nReturn Values:#\nTypeDescriptionuint256The current fee, expressed in wad, where (1 \\times 10^18) is 100%.PreviousSwap FeaturesNextTesting & Debugging","tokens":4587,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259864874,"hash":"40b6c3c2f57848ee5a944294263e037b68093e46"}
{"url":"https://gov.optimism.io/c/88-category/technical-proposals/47","domain":"gov.optimism.io","title":"Latest Proposals 📃/Technical Proposals topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Technical Proposals\n\n Proposals 📃\n\n Technical Proposals\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Standard Proposal Template – Optimism Token House\n\n Standard Proposal Template – Optimism Token House\nFor all non Governance Fund grant proposals, please use the below template and the process outlined in the operating manual. \n\nProposal Title: __________________________…\n\n read more\n\n 0\n\n 2.7k\n\n Mar 2023\n\n About the Technical Proposals category\n\n Discuss non-grant related structural, or technical, governance proposals.\n\n 1\n\n 2.8k\n\n Jan 2023\n\n Upgrade 19b — Karst Hardfork\n\n Proposal Type: Protocol Upgrade\nVoting Cycle Type: off-cycle\nHi, I’m Matthew Cruz, Engineering Manager of the Solutions team at OP Labs. I have reviewed this proposal with: Josh Klopfenstein, Paul Dowman, and Andrea Fede…\n\n read more\n\n 3\n\n 284\n\n Jun 18\n\n [Research] Post-Quantum Cryptography (PQC) Latency Benchmarks on OP Stack Architecture\n\n Hi OP Stack Community and Core Devs, \nAs the transition toward Post-Quantum Cryptography (PQC) becomes an operational necessity across L1/L2/L3 infrastructures, the primary bottleneck remains execution overhead. Introduc…\n\n read more\n\n 6\n\n 153\n\n Jun 14\n\n Maintanance Upgrade Proposal 18a: Arena-Z Chain Servicer Migration\n\n season-9\n\n Proposal Title: Arena-Z Chain Servicer Migration\nProposal Type: Maintenance Upgrade\nVoting Cycle Type: Off-cycle\n\nExecutive Summary\nThis Maintenance Upgrade Proposal requests the Optimism Security Council to execute two …\n\n read more\n\n 0\n\n 185\n\n Mar 13\n\n Upgrade 17 - Jovian Hardfork and Fusaka Readiness\n\n Proposal Title: Upgrade 17 Proposal: Jovian Hardfork and Fusaka Readiness \nProposal Type: Protocol Upgrade \nThis proposal will run off cycle \nHi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP S…\n\n read more\n\n 3\n\n 934\n\n Jan 1\n\n Integrating LUXBIN: Quantum-Classical Hybrid Cryptography for Optimism’s Future\n\n Hey Optimism Collective! \nMy name is Nichole Christie I a member who’s been inspired by \nOptimism's mission to scale Ethereum sustainably and build a more open,\n\ndecentralized world. I've been working on a …\n\n read more\n\n 0\n\n 56\n\n Dec 2025\n\n Disclosing two fault proof system vulnerabilities\n\n Summary\n\nWe discovered and fixed two medium severity vulnerabilities impacting OP Stack chains that run a permissionless fault proof system. \n\nNeither were exploited on any OP Stack chain. \n\nBoth issues were fixed in …\n\n read more\n\n 0\n\n 222\n\n Dec 2025\n\n [deprecated] Upgrade 17 Proposal: Jovian Hardfork\n\n This proposal has been deprecated. \n\nProposal Title: Upgrade 17 Proposal: Jovian Hardfork \nProposal Type: Protocol Upgrade \nThis proposal will go to vote during voting cycle 44 \nHi I’m George, a Protocol Engineer at OP …\n\n read more\n\n 2\n\n 329\n\n Nov 2025\n\n Governor Upgrade Proposal: Onchain Controls MVP\n\n Proposal Title: Governor Upgrade Proposal: Onchain Controls MVP \nProposal Type: Governor Upgrade \nThis proposal will go to vote during voting cycle 44 \nExecutive Summary\nThis proposal introduces the Onchain Controls MVP,…\n\n read more\n\n 0\n\n 204\n\n Oct 2025\n\n An update to OP Labs recommendation for signing OPCM upgrade transactions\n\n Hi, I’m maurelian, a member of the EVM Safety team at OP Labs. \nThose familiar with the process of executing upgrades to the Optimism Superchain will know just how deeply we go into the process of verifying the expected …\n\n read more\n\n 1\n\n 129\n\n Oct 2025\n\n Proposal Preview: Operator Fee\n\n Proposal Title: Operator Fee\nProposal Type: Protocol Upgrade\nExecutive Summary\nThe current fee formula for the OP Stack presents challenges for variants of the OP Stack that leverage Alt-DA, validity proving with ZK or a…\n\n read more\n\n 1\n\n 322\n\n Sep 2025\n\n Vulnerability disclosure: incorrect blob preimages\n\n Summary\nWe recently discovered a bug in an offchain component of Optimism’s fault proof stack that can lead to permissionless dispute games resolving incorrectly under certain conditions – this is medium-severity based o…\n\n read more\n\n 1\n\n 347\n\n Sep 2025\n\n Maintenance Upgrade Proposal: U16a\n\n Proposal Type: Maintenance Upgrade \nHi, I’m Kelvin, part of the EVM Safety team at OP Labs. I will be acting as the primary point of contact for technical questions related to this proposal. \nThe following proposal was p…\n\n read more\n\n 2\n\n 545\n\n Sep 2025\n\n [Draft] Inflation Adjustment Proposal\n\n Summary\nThis proposal suggests setting inflation of $OP’s total token supply to 0%. The total supply will remain at 4,294,967,296 OP. \nMotivation\nData gathered from: [PUBLIC] OP Token Unlock (Estimated) - Google Sheetsan…\n\n read more\n\n 3\n\n 431\n\n May 2025\n\n Upgrade Proposal #15a - Absolute Prestate Updates for Isthmus Activation & Blob Preimage Fix\n\n Proposal Title: Absolute Prestate Updates for Isthmus Activation & Blob Preimage Fix\nProposal Type: Maintenance Upgrade\nExecutive Summary\nHi, I’m Seb, a Protocol Software Engineer at OP Labs. I prepared this proposal in …\n\n read more\n\n 1\n\n 344\n\n May 2025\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n Upgrade Proposal #15 - Isthmus Hard Fork\n\n Proposal Title: Upgrade 15 - Isthmus Hard Fork\nProposal Type: Protocol Upgrade\nThis proposal is intended to be voted on in Cycle 35 \nThis proposal is contingent upon the passing of Upgrade Proposal #14 \nExecutive Summary\n…\n\n read more\n\n 13\n\n 1.1k\n\n Apr 2025\n\n Proposal Preview: L2 Withdrawals Root in Block Header\n\n Proposal Title: L2 Withdrawals Root in Block Header\nProposal Type: Protocol Upgrade\nPlease note that this is a Proposal Preview and is not an actual proposal. It is meant to allow the Collective to provide feedback and a…\n\n read more\n\n 0\n\n 216\n\n Mar 2025\n\n Proposal Preview: DeputyPauseModule (Superchain Pause Improvements)\n\n Executive Summary\nOP Labs is planning to submit a proposal that introduces a new Safe Module called the DeputyPauseModule to be installed into the Optimism Foundation Safe to simplify the process of quickly responding to…\n\n read more\n\n 2\n\n 174\n\n Mar 2025\n\n Proposal Preview: OP Contracts Manager Upgrades and Release Process Improvements\n\n Please note that this is a Proposal Preview and is not an actual proposal. It is meant to allow the Collective to provide feedback and ask questions before an official proposal is published. \nExecutive Summary\nThis propo…\n\n read more\n\n 2\n\n 188\n\n Feb 2025\n\n Proposal Preview: Implement Prague features on the OP Stack\n\n Proposal Preview: Implement Prague features in Isthmus\nProposal Title: Pectra Hardfork on Optimism\nProposal Type: Protocol Upgrade\n\nPlease note that this is a Proposal Preview and is not an actual proposal. It is meant …\n\n read more\n\n 0\n\n 460\n\n Feb 2025\n\n Proposal Preview: Operator Fee\n\n Please note that this is a Proposal Preview and is not an actual proposal. It is meant to allow the Collective to provide feedback and ask questions before an official proposal is published. \nProposal Title: Operator Fee\n…\n\n read more\n\n 0\n\n 216\n\n Feb 2025\n\n [Informational] Upcoming Upgrades Preview\n\n Executive Summary\nThis post is for informational purposes only, and is not a formal governance proposal \nThis is a preview of what OP Labs plans to propose in upcoming protocol upgrade proposals. Due to the numerous feat…\n\n read more\n\n 1\n\n 246\n\n Feb 2025\n\n Proposal Preview: Upgrading the Cannon Fault Proof VM to support 64-bit and multi-threading\n\n Please note that this is a Proposal Preview and is not an actual proposal. It is meant to allow the Collective to provide feedback and ask questions before an official proposal is published. \nExecutive Summary\nOP Labs is…\n\n read more\n\n 0\n\n 134\n\n Feb 2025\n\n Proposal Preview: Fault Proofs Incident Response Improvements\n\n Executive Summary\nOP Labs is planning to submit a proposal that introduces technical improvements to several key contracts to enable more flexible and less disruptive ways to respond to any potential incidents in the OP …\n\n read more\n\n 0\n\n 166\n\n Feb 2025\n\n Proposal to change marketmaker Wintermute\n\n Hi there. \nAs you can see the price of $OP token is in a state of decline and does not respond to market conditions.Despite the successful growth of Ethereum ecosystem the price of token $OP is not responding. \nIn my per…\n\n read more\n\n 13\n\n 419\n\n Dec 2024\n\n [FINAL] Proposal to Reclassify Grant Misusage Enforcement\n\n season-5,cycle-17\n\n Proposal to Reclassify Grant Misusage Enforcement\nAfter discussions with the elected Token House Code of Conduct Council and the Grants Council, the Foundation would like to propose a change to two proposal types pertain…\n\n read more\n\n 8\n\n 1.4k\n\n Dec 2024\n\n Season 6: Standard Rollup Charter\n\n season-6\n\n Season 6: Standard Rollup Charter\n\n// This draft will be ratified by the Token House in Voting Cycle #29. For more context on the Blockspace Charter Framework, see here. \nIntroduction\nThe Standard Rollup is the Optimism …\n\n read more\n\n 16\n\n 2.8k\n\n Nov 2024\n\n Insights into Optimism’s Chain Composition\n\n Our team, ProbeLab, has recently ran an analysis on the Optimism network (OP Stack Chain ID). We have crawled the discv4 and discv5 DHTs with our network crawler Nebula and filtered the results to only include nodes that…\n\n read more\n\n 0\n\n 125\n\n Nov 2024","tokens":2383,"squid":"ink-governance","role":"Council Listener","at":1791259873430,"hash":"894e724c4de75ea783668433c2663f26e013655c"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/testing-and-debugging","domain":"aave.com","title":"Testing & Debugging | Aave Protocol Documentation","text":"Testing & Debugging#\nThis guide provides comprehensive instructions on how to test and debug Aave protocol integrations.\nTesting#\nThere are two primary methods for testing the Aave protocol: using a testnet or creating fork networks.\nTestnet#\nThe Aave protocol is available for testing on the Sepolia testnet. You can access the Sepolia v3 testnet market by visiting app.aave.com and enabling testnet mode in the top right corner.\nTo get started:\nVisit the test market on app.aave.com.Use the Faucet tab to acquire test tokens available in the market.Supply these tokens to the protocol.Perform operations such as borrowing, repaying, and withdrawing to test different functionalities.\nFork Networks#\nA fork network replicates the state of a blockchain, allowing you to interact with it in a sandbox environment. This is especially useful for testing scenarios that depend on contracts and states existing on the mainnet.\nCreating a Fork Network#\nSeveral tools can help you create a fork network:\nTenderly: Debugging toolkit with fork networks, simulations, and online dashboard.Foundry: Smart contract development framework.Hardhat: Smart contract development framework.\nTo acquire tokens on a fork network, you can impersonate an address that holds the desired tokens (holders can be found using block explorers) and transfer them to your address.\nConnecting the Fork Network to the UI#\nThe app.aave.com interface can be configured to connect to a fork network. By setting specific variables via the browser console, you can enable this functionality. Refer to this guide for detailed instructions.\nDebugging#\nWhen interacting with the Aave protocol, you may encounter smart contract errors. This section helps you understand how to interpret error codes, use debugging tools, and resolve common issues.\nError Codes#\nThe Aave protocol uses specific error codes to indicate why a transaction failed. Understanding these codes is essential for debugging. The error codes for each Aave protocol version are defined in their respective Errors.sol files:\nAave v3 Error Codes: Errors.solAave V2 Error Codes: Errors.sol\nDebugging Tools#\nTo effectively debug transactions, you can use tools like Tenderly, Hardhat, and Foundry. These tools allow you to simulate transactions, inspect state changes, and step through execution to identify issues.\nTenderly#\nTenderly allows you to simulate transactions and debug them step-by-step. By inputting the transaction details (to, from, data, and value), you can simulate the call and identify the cause of any revert, including error codes and stack traces.\nHardhat#\nHardhat provides a local Ethereum environment for testing and debugging. It offers features like console logs in Solidity, detailed stack traces, and the ability to fork mainnet state for testing.\nFoundry#\nFoundry is a fast, portable, and modular toolkit for Ethereum application development. It includes tools like Forge for testing and debugging smart contracts, allowing you to simulate and debug transactions effectively.\nUnderstanding \"Gas Estimation Failed\"#\nThe \"Gas estimation failed\" error is a generic message indicating that the transaction would fail if executed. To diagnose this issue:\nUse the transaction's to, from, data, and value fields.Simulate the transaction using one of the debugging tools mentioned above.Identify the specific error code or exception causing the failure.Examine the stack trace to pinpoint the issue.\nCommon Errors#\nAave v3 Pool#\nWhen interacting with the Aave v3 Pool, you may encounter issues related to token approvals, insufficient collateral, or reaching protocol limits.\nERC-20 Token Approval for Supply and Repay\nBefore supplying or repaying tokens, ensure that you have granted the Aave Pool contract an allowance to transfer tokens. This is performed by calling the approve function on the ERC-20 token contract to authorize the Pool as the spender.\nInsufficient Collateral\nIf you're unable to borrow assets, it may be due to insufficient collateral or not meeting the required Loan-to-Value (LTV) ratios. Ensure that you have supplied enough collateral and that it satisfies the protocol's requirements.\nBorrow Cap Reached\nSometimes, you may not be able to borrow a specific asset because the borrow cap has been reached. In this case, you may need to wait for borrowers to repay or supply more liquidity to the pool.\nFor more detailed explanations of potential revert cases, refer to this DeFi Integration Guide.\nLoan To Value = 0%\nWhen an Aave reserve has a Loan To Value (LTV) parameter configured to 0%, commonly referred to as LTV0, it impacts reserve interactions in several ways:\nBorrowing power: Any existing collateral of this asset will no longer contribute to borrowing power.Collateral status: The asset can no longer be enabled as collateral.Transfers: If received via transfer, the asset will not be automatically enabled as collateral.Withdrawals: Assets with LTV0 must be disabled as collateral (using Pool.setUserUseReserveAsCollateral or by fully withdrawing the supplied balance) before other assets can be withdrawn.\nWrappedTokenGateway#\nWhen interacting with Ether (ETH) in the Aave protocol, the WrappedTokenGateway is used to wrap ETH into WETH and vice versa. Common issues may include not sending ETH with the transaction when required or using incorrect functions for depositing or withdrawing ETH.\nFor detailed usage and potential revert causes, refer to the WrappedTokenGateway documentation.PreviousVaultsNextUmbrella","tokens":1375,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259875569,"hash":"c0799e3aaeb218f452081de2a09f77aa793a89f6"}
{"url":"https://ethresear.ch/t/torrents-and-eip-4444/19788/21","domain":"ethresear.ch","title":"Torrents and EIP-4444 - Execution Layer Research - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 5\n\n 2\n\n 2\n\n 2\n\n read \n\n 17\n min\n\n Jun 2024\n\n 21 / 21\n\n Oct 2024\n\n Oct 2024\n\n Load more posts above\n\n post by imkharn on Jun 12, 2024\n\n post by arnetheduck on Jun 13, 2024\n\n post by kdeme on Jun 13, 2024\n\n post by parithosh on Jun 13, 2024\n\n post by parithosh on Jun 13, 2024\n\n post by arnetheduck on Jun 13, 2024\n\n post by parithosh on Jun 13, 2024\n\n post by arnetheduck on Jun 13, 2024\n\n post by imkharn on Jun 13, 2024\n\n post by parithosh on Jun 14, 2024\n\n post by parithosh on Jun 14, 2024\n\n 14 days later\n\n post by parithosh on Jun 28, 2024\n\n post by chfast on Jun 28, 2024\n\n post by arnetheduck on Jul 1, 2024\n\n 11 days later\n\n post by kdeme on Jul 12, 2024\n\n 12 days later\n\n post by parithosh on Jul 25, 2024\n\n parithosh\n\n I’ve updated the torrent with the proofs as requested, the new torrent magnet link can be found here.\nSince the earlier link has been deleted for some reason, I’ve also uploaded the torrent file in an s3 bucket here: https://ethereum-mainnet-pre-merge-era-files.fra1.cdn.digitaloceanspaces.com/EthereumMainnetPreMergeEraFiles.torrent\ncc @chfast\n\n post by chfast on Jul 25, 2024\n\n chfast\n\n The new link has been deleted too. Maybe a discourse policy?\n\n post by parithosh on Jul 25, 2024\n\n parithosh\n\n Probably. I’ve also uploaded it to IPFS, CID is QmejuzLRmhiwoW7HuJ6V8MoSqjxPhfjarkAhPqrhy8ScSp and e.g retrieval URL curl https://gateway.pinata.cloud/ipfs/QmejuzLRmhiwoW7HuJ6V8MoSqjxPhfjarkAhPqrhy8ScSp. The above mentioned s3 bucket would also work.\n\n 16 days later\n\n post by r4f4ss on Aug 10, 2024\n\n r4f4ss\n\n Is there a torrent for testnets too? Holesky seems especially difficult to sync execution layer, there are near no nodes providing initial history. I have been experiencing several hours “Looking for peers”.\n\n 3 months later\n\n post by arnetheduck on Oct 28, 2024\n\n arnetheduck\n\n Holesky began its life merged, so there is no “era1” - you can get era files however: https://holesky.era.nimbus.team/\nWe have sepolia too:\nhttps://sepolia.era1.nimbus.team/\nhttps://sepolia.era.nimbus.team/\n\n Powered by Discourse","tokens":528,"squid":"ink-research","role":"Deep Scholar","at":1791259876301,"hash":"496bc26f165a8f2a284d9c895616c5545bd9eb28"}
{"url":"https://gov.optimism.io/t/maintanance-upgrade-proposal-18a-arena-z-chain-servicer-migration/10623","domain":"gov.optimism.io","title":"Maintanance Upgrade Proposal 18a: Arena-Z Chain Servicer Migration - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Maintanance Upgrade Proposal 18a: Arena-Z Chain Servicer Migration \n\n Proposals 📃Technical Proposals\n\n season-9\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 13\n\n 1 / 1\n\n Mar 12\n\n Mar 13\n\n post by system on Mar 13\n\n system\n\n Proposal Title: Arena-Z Chain Servicer Migration\nProposal Type: Maintenance Upgrade\nVoting Cycle Type: Off-cycle\n\nExecutive Summary\nThis Maintenance Upgrade Proposal requests the Optimism Security Council to execute two administrative changes on behalf of Arena-Z (the Chain Governor, as defined by the Law of Chains), in accordance with the Technical Configurability provisions. These changes apply to both Arena-Z Mainnet (Chain ID: 7897) and Arena-Z Testnet (Chain ID: 9899):\n\nProposer Migration — Update the proposer address in the DisputeGameFactory to a new Chain Servicer-operated address.\nFee Vault Recipient Update — Predeploy batched fee vault implementations to update the fee recipient to new Arena-Z-operated addresses.\n\nImpacted Stakeholders: Arena-Z, Node Operators\nExpected Outcomes: These changes are purely administrative and do not alter the protocol’s behavior for end users, infrastructure providers, or other chains. Arena-Z, as the Chain Governor under the Law of Chains, is exercising its right to migrate Chain Servicers.\n\nMotivation\nArena-Z’s ProxyAdmin owner roles are managed by the Optimism Security Council. As such, the Security Council can only act by direction of Optimism Governance. The Law of Chains ensures that Arena-Z, as the Chain Governor, can migrate its Chain Servicers under Technical Configurability:\n\n“Chain Governors may make basic technical configurations permitted to them by the OP Stack. This should include the ability for the Chain Governor to change the Sequencer on its OP Chain between those which have been approved by Optimism Governance, and to appoint a new Chain Governor to take its place in the event it elects to make such a transition.”\n\nArena-Z wishes to migrate its Chain Servicer operations, requiring updates to the proposer role, fee vault recipients, and withdrawal network configuration. Since these operations require the ProxyAdminOwner (Security Council) to execute, this proposal is submitted for governance approval.\nNo conflicts of interest are anticipated. This is a routine administrative migration of operational roles.\n\nSpecifications\nBlockspace Charter\n\nArena-Z Mainnet\nNo changes to the Blockspace Charter are proposed; this is an administrative address migration.\n\nTechnical Details\nAction 1: Proposer Migration in DisputeGameFactory\nFunction: setImplementation(uint32 _gameType, IDisputeGame _impl, bytes _args)\nThe proposer and challenger addresses are encoded as CWIA (Clone-With-Immutable-Args) data in the gameArgs of the DisputeGameFactory. The implementation contract does not change — the existing PermissionedDisputeGame implementation is reused. Only the _args parameter is updated with the new proposer address.\nMainnet (Ethereum L1)\nDisputeGameFactory at 0x658656A14AFdf9c507096aC406564497d13EC754\n\nParameter\nCurrent\nNew\n\nProposer\n0x5f16E66D8736B689a430564a31c8d887ca357CD8\n0xDA89371d5C940233B200f9a235bF0Ea8AB9fAe96\n\nOther immutables (unchanged):\n\nGame Type: 1 (PermissionedDisputeGame)\nImplementation: 0x58bf355C5d4EdFc723eF89d99582ECCfd143266A\nAbsolute Prestate: 0x033c000916b4a88cfffeceddd6cf0f4be3897a89195941e5a7c3f8209b4dbb6e\nVM: 0x6463dEE3828677F6270d83d45408044fc5eDB908\nAnchor State Registry: 0x0C9fF654bCd0769142Fe70951B0634C5AE19BA3C\nWETH: 0x1D21c2535154d5D0337eda61df9c07f306AA17f7\nL2 Chain ID: 7897\nChallenger: 0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3A (Security Council Safe, unchanged)\n\nExecution: ProxyAdminOwner 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A (2-of-2: Security Council + Foundation) calls setImplementation with updated args.\nProof of ownership of new proposer address\n\nAction 2: Fee Vault Recipient Update\nThe three L2 fee vault predeploys (same addresses on both networks):\n\nL1FeeVault: 0x420000000000000000000000000000000000001A\nSequencerFeeVault: 0x4200000000000000000000000000000000000011\nBaseFeeVault: 0x4200000000000000000000000000000000000019\n\nMainnet (Arena-Z, Chain ID: 7897)\nCurrent implementation version: v1.5.0-beta.2\n\nParameter\nCurrent\nNew\n\nRecipient (all 3 vaults)\n0xBeA2Bc852a160B8547273660E22F4F08C2fa9Bbb (Gelato 4-of-9 Safe)\n0x6f6B5c7bdf4A7Ba9Fd39A4869285e2ebEd1C6a49\n\nWithdrawal Network\nL1 (0)\nL1 (0) — unchanged\n\nMin Withdrawal Amount\n2 ETH\n2 ETH — unchanged\n\nRequired Steps (mainnet only, 4 Security Council transactions):\nSince current implementations use immutable recipients baked into constructor bytecode (no setRecipient() function), new implementation contracts must be predeployed and proxies upgraded via the L2 ProxyAdmin (0x4200000000000000000000000000000000000018). The L1 ProxyAdminOwner (Security Council) sends L1→L2 transactions to execute. Implementation deployments are predeployed offchain prior to SC execution and are not part of the SC batch.\nNote: L1FeeVault and BaseFeeVault share identical bytecode and constructor args, so a single predeployed implementation is reused for both. SequencerFeeVault requires its own implementation. The three proxy upgrades are batched into a single SC transaction.\n\n(Pre-execution) Predeploy shared FeeVault implementation (for L1FeeVault + BaseFeeVault) on Arena-Z Mainnet\n(Pre-execution) Predeploy SequencerFeeVault implementation on Arena-Z Mainnet\nBatched SC transaction: Upgrade L1FeeVault, BaseFeeVault, and SequencerFeeVault proxies → new implementations via L2 ProxyAdmin\n\nSecurity Considerations\n\nNo protocol behavior changes: both actions are administrative role/configuration changes. The dispute game mechanics, fault proof system, and bridge security are unaffected.\nNo new code deployed for Action 1: the existing PermissionedDisputeGame implementation is reused; only CWIA args are updated.\nExisting games unaffected: games already created continue with their original proposer/challenger. Only new games will use the updated proposer.\nFee vault upgrade (Action 2): deploys new implementations with updated recipient as a constructor immutable. Contract code is identical to current deployment — only the immutable recipient value changes.\nChallenger unchanged: challenger roles remain unchanged on both networks, preserving the existing security model.\n\nImpact Summary\n\nNo downtime required — changes are transparent to end users\nNo chain reorg or restart needed\nExisting in-progress dispute games are unaffected\nNo impact on other Superchain members\n\nKey Dates:\n\nMilestone\nTarget Date\n\nProposal posted & on-chain veto period begins\n2026/03/12\n\nVeto period ends (7 days, optimistic approval)\n2026/03/19\n\nSecurity Council executes transactions\n2026/03/19+\n\nPrecommitment Impact Review\n\nPrecommitment\nImpact\n\nCollective Fee Take\nNo change. Fee vault mechanisms remain the same; only the recipient address changes.\n\nGovernor/Servicer Role Separation\nNo change. Arena-Z is exercising its existing right as Chain Governor to migrate Chain Servicers. The Security Council and Foundation roles remain unchanged.\n\nOssified GasLimits\nNo change. Gas limits are not modified.\n\nDirect Fee Margin Controls\nNo change. Fee margins and scalars are not modified.\n\nAction Plan\n\nArena-Z confirms all new addresses for both mainnet and testnet.\nProposal is posted to the Optimism Governance Forum for a 1-week veto period (target: 2026/03/12).\nPrior to SC execution, OP Labs predeploys the two fee vault implementation contracts on Arena-Z Mainnet.\nUpon approval, the Security Council prepares and simulates the following 2 transactions on Ethereum Mainnet:\n\nTx 1: DisputeGameFactory.setImplementation(1, 0x58bf..., newArgs) on Ethereum — updates proposer\nTx 2: Batched upgrade — L1FeeVault, BaseFeeVault, and SequencerFeeVault proxies upgraded to predeployed implementations via L2 ProxyAdmin\n\nSecurity Council verifies all addresses match expected values and executes.\n\nContingency: If last-minute bugs or issues are found during simulation, execution will be delayed until the issue is resolved. No on-chain changes take effect until all transactions are verified.\n\nConclusion\nThis proposal enables Arena-Z to exercise its Technical Configurability rights as Chain Governor under the Law of Chains by migrating its Chain Servicer operations. The changes are limited to administrative address updates — updating the proposer role in the DisputeGameFactory and updating fee vault recipient addresses on both mainnet and testnet — and do not alter the protocol’s security model or behavior.\nThe Security Council is requested to verify and execute these 2 transactions upon governance approval following the 7-day veto period ending 2026/03/19.\n\nBy submitting a proposal, you represent and warrant to the Optimism Collective that all the information it contains is true and complete to the best of your knowledge.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Maintenance Upgrade Proposal: Ink Mainnet Fee Vault Config Update and Proposer Rotation\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nVoting Cycle Type: Off-cycle. Per the OPerating Manual, Maintenance Upgrade Proposals proceed directly to on-chain voting under optimistic approval, with a one-week veto period and a 2…\n\n read more\n\n 0\n\n 97\n\n Jul 22\n\n Maintenance Upgrade Proposal: Update Soneium Fee Vaults Recipient\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade \nSummary\nThis proposal updates the recipient configured on Soneium’s four L2 fee vault predeploys (SequencerFeeVault, BaseFeeVault, L1FeeVault, OperatorFeeVault) from the current treasu…\n\n read more\n\n 1\n\n 117\n\n Aug 23\n\n Maintenance Upgrade Proposal: Mode, Metal, Zora, and Dust Ownership Transfer to Conduit\n\n Proposals 📃\n\n Proposal Type: Maintenance Upgrade Proposal \nVoting Cycle: Off-cycle (Special Voting Cycle, subject to the standard veto period) \nSummary\nThis proposal requests the Optimism Security Council return administrative ownersh…\n\n read more\n\n 0\n\n 55\n\n Sep 2\n\n [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization\n\n Protocol Upgrade\n\n Hi Maurelian here, I’m a protocol security engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not re…\n\n read more\n\n 26\n\n 2.5k\n\n May 2024\n\n [FINAL] Protocol Upgrade #7: Fault Proofs\n\n Protocol Upgrade\n\n Executive Summary\nHi I’m Adrian, a protocol engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not r…\n\n read more\n\n 44\n\n 6.2k\n\n Jun 2024","tokens":2715,"squid":"ink-governance","role":"Council Listener","at":1791259883628,"hash":"da808737bc896ffedb0bdde9b41507727c8661e6"}
{"url":"https://aave.com/docs/aave-v3/guides/flash-loans","domain":"aave.com","title":"Flash Loans | Aave Protocol Documentation","text":"Flash Loans#\n\nFlash Loans are special transactions that allow the borrowing of an asset, as long as the borrowed amount (and a fee) is returned before the end of the transaction (also called One Block Borrows). These transactions do not require a user to supply collateral prior to engaging in the transaction. There is no real world analogy to Flash Loans, so it requires some basic understanding of how state is managed within blocks in blockchains.\nFlash Loans are an advanced concept aimed at developers. You must have a good\nunderstanding of EVM, programming, and smart contracts to be able to use this\nfeature.\nOverview#\nFlash-loan allows users to access liquidity of the pool (only for reserves for which borrow is enabled) for one transaction as long as the amount taken plus fee is returned or (if allowed) debt position is opened by the end of the transaction.\nAave v3 offers two options for flash loans:\nflashLoan(): Allows borrower to access liquidity of multiple reserves in single flashLoan transaction. The borrower also has an option to open variable rate borrow position backed by supplied collateral or credit delegation in this case.\nNOTE: flash loan fee is waived for approved flashBorrowers (managed by ACLManager)flashLoanSimple(): Allows borrower to access liquidity of single reserve for the transaction. In this case flash loan fee is not waived nor can borrower open any debt position at the end of the transaction. This method is gas efficient for those trying take advantage of simple flash loan with single reserve asset.\nExecution Flow#\nFor developers, a helpful mental model to consider when developing your solution:\nYour contract calls the Pool contract, requesting a Flash Loan of a certain amount(s) of reserve(s) using flashLoanSimple() or flashLoan().After some sanity checks, the Pool transfers the requested amounts of the reserves to your contract, then calls executeOperation() on receiver contract .Your contract, now holding the flash loaned amount(s), executes any arbitrary operation in its code. \nIf you are performing a flashLoanSimple, then when your code has finished, you approve Pool for flash loaned amount + fee.If you are performing flashLoan, then for all the reserves either depending on interestRateMode passed for the asset, either the Pool must be approved for flash loaned amount + fee or must or sufficient collateral or credit delegation should be available to open debt position.If the amount owed is not available (due to a lack of balance or approval or insufficient collateral for debt), then the transaction is reverted.\nAll of the above happens in 1 transaction (hence in a single ethereum block).\nApplications of Flash Loans#\nAave Flash Loans are already used with Aave v3 for liquidity switch feature. Other examples in the wild include:\nArbitrage between assets, without needing to have the principal amount to execute the arbitrage.Liquidating borrow positions, without having to repay the debt of the positions and using discounted collateral claimed to payoff flashLoan amount + fee.\nFlash loan fee#\nThe flash loan fee is initialized at deployment to 0.05% and can be updated via Governance Vote. Use FLASHLOAN_PREMIUM_TOTAL to get current value.\nFlashloan fee can be shared by the LPs (liquidity providers) and the protocol treasury. The FLASHLOAN_PREMIUM_TOTAL represents the total fee paid by the borrowers of which:\nFee to LP: FLASHLOAN_PREMIUM_TOTAL - FLASHLOAN_PREMIUM_TO_PROTOCOLFee to Protocol: FLASHLOAN_PREMIUM_TO_PROTOCOL\nAt initialization,\nFLASHLOAN_PREMIUM_TO_PROTOCOL\nis set to 0.\nStep by step#\n1. Setting Up#\nYour contract that receives the flash loaned amounts must conform to the IFlashLoanSimpleReceiver or IFlashLoanReceiver interface by implementing the relevant executeOperation() function.\nAlso note that since the owed amounts will be pulled from your contract, your contract must give allowance to the Pool to pull those funds to pay back the flash loan amount + premiums.\n2. Calling flashLoan() or flashLoanSimple()#\nTo call either of the two flash loan methods on the Pool, we need to pass in the relevant parameters. There are 3 ways you can do this.\n\nFrom an EOA ('normal' ethereum account)\nTo use an EOA, send a transaction to the relevant Pool calling the flashLoan() or flashLoanSimple() function. See the Pool docs for parameter details, ensuring you use your contract address from step 1 for the receiverAddress.\n\nFrom a different contract\nSimilar to sending a transaction from an EOA as above, ensure the receiverAddress is your contract address from step 1.\n\nFrom the same contract\nIf you want to use the same contract as in step 1, use address(this) for the receiverAddress parameter in the flash loan method.\n\nNever keep funds permanently on your\nFlashLoanReceiverBase\ncontract as they could be exposed to a 'griefing'\nattack, where the stored\nfunds are used by an attacker.\nCompleting the flash loan#\nOnce you have performed your logic with the flash loaned assets (in your executeOperation() function), you will need to pay back the flash loaned amounts if you used flashLoanSimple() or interestRateModes = 0 in flashLoan() for any of the assets in modes parameter.\n\nPaying back a flash loaned asset#\nEnsure your contract has the relevant amount + premium to payback the borrowed asset. You can calculate this by taking the sum of the relevant entry in the amounts and premiums array passed into the executeOperation() function.\nYou do not need to transfer the owed amount back to the Pool. The funds will be automatically pulled at the conclusion of your operation.\n\nIncurring a debt (i.e. not immediately paying back)#\nIf you initially used a mode=1 or mode=2 for any of the assets in the modes parameter, then the address passed in for onBehalfOf will incur the debt if the onBehalfOf address has previously approved the msg.sender to incur debts on their behalf.\nThis means that you can have some assets that are paid back immediately, while other assets incur a debt.\nPreviousAave HorizonNextCredit Delegation","tokens":1507,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259885584,"hash":"6bb8aabce99ed8555b85a09545492cf396a9171c"}
{"url":"https://ethresear.ch/t/era-archival-files-for-block-and-consensus-data/13526","domain":"ethresear.ch","title":"ERA - archival files for block and consensus data - Data Structure - Ethereum Research","text":"ERA - archival files for block and consensus data \n\n Data Structure\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2022\n\n 1 / 1\n\n Aug 2022\n\n Aug 2022\n\n post by arnetheduck on Aug 29, 2022\n\n arnetheduck\n\nTL;DR: a simple, flat type-length-value format for storing finalized block and consensus state data, for interop, archival and out-of-band dissemination - full spec here.\n\nIntro\nToday, consensus clients store and offer via P2P the entire beacon chain block history so as to allow syncing from genesis - to date this is in the order of 40-50GB of data, but with the merge, the growth of this data set will accelerate significantly with the inclusion of execution transactions in consensus blocks.\nAn alternative way of syncing is to start from an arbitrary point in time using a known trusted checkpoint - due to weak subjectivity, the security model remains the same (ie in both from-genesis and checkpoint sync, you need to know one valid block hash from within the weak subjectivity period to be safe against weak subjectivity attacks).\nRegardless of sync method, clients conforming to the spec must make block data available for MIN_EPOCHS_FOR_BLOCK_REQUESTS epochs (~5 months) but de facto clients store all blocks from genesis - in part this is to support from-genesis sync, but also because there exists no standardized and interoperable way to disseminate the data outside of the p2p specification and there is general concern that the data will be lost or difficult to recover should clients simply start dropping it with a replacement mechanism.\nEnter ERA files - a simple, flat storage format for out-of-band interchange of historical block and consensus data.\nFormat\n\nSpecification\n\nThe basic structure of an era file is a list of type-length-value records. Each era file starts with a version marker, followed by a number of entries: blocks, a beacon state and finally some indices that allow lookup of block data based on slot number. Blocks and states are stored as they typically appear in the p2p protocol of consensus clients: each record is encoded with SSZ and compressed with snappy.\nEach era covers 8192 blocks (or roughly 27 hours), and includes a state snapshot of the beacon chain state at the end of the era.\nThe state snapshot serves two purposes: to validate the blocks contained in the era file (for which validator public keys as well as block roots are needed), as well as serve as a starting point to recreate history from there onward.\nFinally, era files contain a slot-to-offset index allowing linear lookup of block data based on slot number.\nFeatures\nEra files are formed from finalized data: they are immutable and verifiable using a recent-enough state. Without making any additional security assumptions, they can be stored out-of-band and transferred using existing internet infrastructure such as plain cache-friendly HTTP, bittorrent etc.\nAny era file can be verified using the historical_roots field of any beacon state more recent than the era file, all the way back to genesis.\nBecause they contain a beacon state, they can also serve as starting point for recreating detailed historical data for each slot past the given era - for example to examine balances and states of validators at a particular point in time.\nClients wishing to use era files for syncing purposes can download them using a simple http client - with predictable naming, this can be used as a fast and efficient alternative to backfilling via P2P - in this sense, they replace and enhance checkpoint sync.\nFinally, with an interoperable format for archival, clients are free to start dropping historical data altogether, because the needs of users requiring full archival remain met (albeit via a different mechanism than today).\nWho will store the data?\nCurrently, the P2P network stores / supports the from-genesis history of blocks, but it is difficult to motivate this from a node perspective - it is not needed for computing consensus but costs significant bandwidth and storage.\nAssuming that the historical data is of interest to the community, it is expected that existing large operators and data providers will fill the space of providing long-term storage - a single interested entity is enough to ensure that the data remains available - the data can also be backed up to decentralized storage (though in order to do so, an additional mapping mechanism is needed that allows the data to be found).\nThe current beacon chain history is available in era forma (additional sources will be added soon):\n\nhttps://mainnet.era.nimbus.team/ - Mainnet consensus data from genesis\n\nHow will the data be made available?\nSimilar to the beacon API, providers of infrastructure can provide HTTP endpoints serving era files - a Beacon API PR is being considered to make era file access part of the “standard” api, likely via an “optional” extension.\nImplementations\nThe era file format is fully documented and has as of writing, reference implementations in Python and Nim.\nNimbus supports using era files in lieu of its own database to serve p2p and API requests, allowing a single era file store to be shared among multiple Nimbus beacon nodes and avoiding the need to backfill via P2P after a checkpoint sync.\nWhat’s missing?\nWith the merge, era files become complete stores of all data necessary to recreate the ethereum state history - however, pre-merge blocks are not covered by the current proposal.\nPost-merge, the pre-merge history will be considered immutable / finalized as well and it is expected that a separate standard for the pre-merge data will be written so as to capture it, likely using the type mechanism of the ERA files.\nWhat’s next?\nThis post serves to introduce the format and open it up for discussion - the next step for this proposal is to make it a standard (via EIP / consensus spec) - given how after the merge, blocks also contain transaction history, the format is of interest to both consensus and execution clients, allowing both to use the same archival storage format for raw block data.\nWhy now?\nAs of the merge hard fork, all consensus clients implement checkpoint sync allowing them to stop relying on full sync as the only mechanism to get going.\nAt the same time, the storage problem is becoming significant - it is widely recognized in the community that all nodes storing full block history is not a sustainable solution.\nDelegating some of the storage work to participants better suited to handle the problem of long-term storage allows lowering the cost of running a node and those lowers the bar for running a consensus node in general.\nRelated work\n\nEIP-4444 - Bound Historical Data in Execution Clients\n getPayloadBodiesByRangeV1 - sharing block execution data between execution client and beacon node\n\n Using The Graph to Preserve Historical Data and Enable EIP-4444\n\n Torrents and EIP-4444\n\n Powered by Discourse","tokens":1725,"squid":"ink-research","role":"Deep Scholar","at":1791259886338,"hash":"d6c949482c5c78c21203f8463df04c21020cd4a9"}
{"url":"https://aave.com/docs/aave-v3/guides/credit-delegation","domain":"aave.com","title":"Credit Delegation | Aave Protocol Documentation","text":"Credit Delegation#\nCredit delegation allows a supplier to contribute liquidity to the Aave protocol to earn interest, and delegate borrowing power (i.e. their credit) to other users. The enforcement of the borrow position and its terms are agreed upon between the supplier and borrowers, which can be either offchain via legal agreements or onchain via smart contracts.\nThis enables:\nThe supplier (aka delegator) to earn extra yield on top of the yield they already earn from the protocol.The borrowers (aka delegatees) to access uncollateralized liquidity.\nBorrow by delegatee must be consistent with delegator eMode category.\nFor eg. if a delegator eMode category is STABLECOINS, then\nDelegator can only borrow STABLECOINS eMode category asset.In case delegator approve credit to delegatee for non STABLECOINScategory (for eg. weth), then borrow would revert.\nThe delegatee cannot abuse credit approval to liquidate delegator i.e. if the borrow puts delegator's position in HF < HEALTH_FACTOR_LIQUIDATION_THRESHOLD, then borrow will fail.\nApproving the delegation#\nThe approveDelegation or delegationWithSig function on the VariableDebtToken contract must be called by the supplier (delegator), approving the borrower (delegatee) a certain amount.\nThis is done for each debt token that needs to be delegated.\nThe delegator does not need to already have supplied funds in the protocol to approveDelegation. However, before the delegatee executes borrow, there must be sufficient collateral supplied by delegator in the protocol.\nBorrowing the credit#\nThe borrower (delegatee) calls the borrow function on the Pool, using the supplier's (delegator's) address in final parameter onBehalfOf.\nThe borrower's available credit is reduced by the borrowed amount.\nRepaying the credit#\nAnyone can repay the borrow position OnBehalf of the user, by calling one of the following Pool functions - repay or repayWithPermit. The supplier (aka creditor) can also use the repayWithATokens function to repay a borrow position with their aTokens of the underlying asset in the same pool.PreviousFlash LoansNextOverview","tokens":525,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791259895526,"hash":"f160f92a7c8e53ed67a02dd615f9bc308c8bd6c3"}
{"url":"https://ethereum.org/dao","domain":"ethereum.org","title":"What is a DAO? | Decentralized Autonomous Organization | ethereum.org","text":"Edit page (opens in a new tab)What are DAOs?\nA DAO is a collectively-owned organization working towards a shared mission.\nDAOs allow us to work with like-minded folks around the globe without trusting a benevolent leader to manage the funds or operations. There is no CEO who can spend funds on a whim or CFO who can manipulate the books. Instead, blockchain-based rules baked into the code define how the organization works and how funds are spent.\nThey have built-in treasuries that no one has the authority to access without the approval of the group. Decisions are governed by proposals and voting to ensure everyone in the organization has a voice, and everything happens transparently .\nWhy do we need DAOs?\nStarting an organization with someone that involves funding and money requires a lot of trust in the people you're working with. But it’s hard to trust someone you’ve only ever interacted with on the internet. With DAOs you don’t need to trust anyone else in the group, just the DAO’s code, which is 100% transparent and verifiable by anyone.\nThis opens up so many new opportunities for global collaboration and coordination.\nA comparison\nDAOA traditional organizationUsually flat, and fully democratized.Usually hierarchical.Voting required by members for any changes to be implemented.Depending on structure, changes can be demanded from a sole party, or voting may be offered.Votes tallied, and outcome implemented automatically without trusted intermediary.If voting allowed, votes are tallied internally, and outcome of voting must be handled manually.Services offered are handled automatically in a decentralized manner (for example distribution of philanthropic funds).Requires human handling, or centrally controlled automation, prone to manipulation.All activity is transparent and fully public.Activity is typically private, and limited to the public.\nDAO examples\nTo help this make more sense, here's a few examples of how you could use a DAO:\n\nA charity – you could accept donations from anyone in the world and vote on which causes to fund.\nCollective ownership – you could purchase physical or digital assets and members can vote on how to use them.\nVentures and grants – you could create a venture fund that pools investment capital and votes on ventures to back. Repaid money could later be redistributed amongst DAO-members.\n\nCould a DAO build the next great city?Scott Fitsimones shares how decentralized autonomous organizations (DAOs) could be the key to coordinating community-driven development and building the next great city.Watch with transcript \nHow do DAOs work?\nThe backbone of a DAO is its , which defines the rules of the organization and holds the group's treasury. Once the contract is live on Ethereum, no one can change the rules except by a vote. If anyone tries to do something that's not covered by the rules and logic in the code, it will fail. And because the treasury is defined by the smart contract too that means no one can spend the money without the group's approval either. This means that DAOs don't need a central authority. Instead, the group makes decisions collectively, and payments are automatically authorized when votes pass.\nThis is possible because smart contracts are tamper-proof once they go live on Ethereum. You can't just edit the code (the DAOs rules) without people noticing because everything is public.\nEthereum and DAOs\nEthereum is the perfect foundation for DAOs for a number of reasons:\n\nEthereum’s own consensus is decentralized and established enough for organizations to trust the network.\nSmart contract code can’t be modified once live, even by its owners. This allows the DAO to run by the rules it was programmed with.\nSmart contracts can send/receive funds. Without this you'd need a trusted intermediary to manage group funds.\nThe Ethereum community has proven to be more collaborative than competitive, allowing for best practices and support systems to emerge quickly.\n\nDAO governance\nThere are many considerations when governing a DAO, such as how voting and proposals work.\nDelegation\nDelegation is like the DAO version of representative democracy. Token holders delegate votes to users who nominate themselves and commit to stewarding the protocol and staying informed.\nA famous example\nENS (opens in a new tab) – ENS holders can delegate their votes to engaged community members to represent them.\nAutomatic transaction governance\nIn many DAOs, transactions will be automatically executed if a quorum of members votes affirmative.\nA famous example\nNouns (opens in a new tab) – In Nouns DAO, a transaction is automatically executed if a quorum of votes is met and a majority votes affirmative, as long as it is not vetoed by the founders.\nMultisig governance\nWhile DAOs may have thousands of voting members, funds can live in a shared by 5-20 active community members who are trusted and usually doxxed (public identities known to the community). After a vote, the signers execute the will of the community.\nDAO laws\nIn 1977, Wyoming invented the LLC, which protects entrepreneurs and limits their liability. More recently, they pioneered the DAO law that establishes legal status for DAOs. Currently Wyoming, Vermont, and the Virgin Islands have DAO laws in some form.\nA famous example\nCityDAO (opens in a new tab) – CityDAO used Wyoming's DAO law to buy 40 acres of land near Yellowstone National Park.\nDAO membership\nThere are different models for DAO membership. Membership can determine how voting works and other key parts of the DAO.\nToken-based membership\nUsually fully , depending on the token used. Mostly these governance tokens can be traded permissionlessly on a . Others must be earned through providing liquidity or some other ‘proof-of-work’. Either way, simply holding the token grants access to voting.\nTypically used to govern broad decentralized protocols and/or tokens themselves.\nA famous example\nMakerDAO (opens in a new tab) – MakerDAO's token MKR is widely available on decentralized exchanges and anyone can buy into having voting power on Maker protocol's future.\nShare-based membership\nShare-based DAOs are more permissioned, but still quite open. Any prospective members can submit a proposal to join the DAO, usually offering a tribute of some value in the form of tokens or work. Shares represent direct voting power and ownership. Members can exit at any time with their proportionate share of the treasury.\nTypically used for more closer-knit, human-centric organizations like charities, worker collectives, and investment clubs. Can also govern protocols and tokens as well.\nReputation-based membership\nReputation represents proof of participation and grants voting power in the DAO. Unlike token or share-based membership, reputation-based DAOs don't transfer ownership to contributors. Reputation cannot be bought, transferred or delegated; DAO members must earn reputation through participation. Onchain voting is permissionless and prospective members can freely submit proposals to join the DAO and request to receive reputation and tokens as a reward in exchange for their contributions.\nTypically used for decentralized development and governance of protocols and , but also well suited to a diverse set of organizations like charities, worker collectives, investment clubs, etc.\nA famous example\nDXdao (opens in a new tab) – DXdao was a global sovereign collective building and governing decentralized protocols and applications since 2019. It leveraged reputation-based governance and to coordinate and manage funds, meaning no one could buy their way into influencing its future or governance.\nJoin / start a DAO\nJoin a DAO\n\nEthereum community DAOs\nDAOHaus's list of DAOs (opens in a new tab)\nTally.xyz list of DAOs (opens in a new tab)\nDeGov.AI list of DAOs (opens in a new tab)\n\nStart a DAO\n\nSummon a DAO with DAOHaus (opens in a new tab)\nStart a Governor DAO with Tally (opens in a new tab)\nCreate an Aragon-powered DAO (opens in a new tab)\nStart a colony (opens in a new tab)\nLaunch a DAO with the DeGov Launcher (opens in a new tab)\n\nFurther reading\nDAO Articles\n\nWhat's a DAO? (opens in a new tab) – Aragon (opens in a new tab)\nHouse of DAOs (opens in a new tab) – Metagame (opens in a new tab)\nWhat is a DAO and what is it for? (opens in a new tab) – DAOhaus (opens in a new tab)\nHow to Start a DAO-Powered Digital Community (opens in a new tab) – DAOhaus (opens in a new tab)\nWhat is a DAO? (opens in a new tab) – Coinmarketcap (opens in a new tab)\nWhat is Holographic Consensus? (opens in a new tab) - DAOstack (opens in a new tab)\nDAOs are not corporations: where decentralization in autonomous organizations matters by Vitalik (opens in a new tab)\nDAOs, DACs, DAs and More: An Incomplete Terminology Guide (opens in a new tab) - Ethereum Blog (opens in a new tab)\n\nVideos\n\nWhat is a DAO in crypto? (opens in a new tab)\nCan a DAO Build a City? (opens in a new tab) – TED (opens in a new tab)\n\nTest your Ethereum knowledgeDAOs - Decentralized autonomous organizationsQuestion number 1:Unlike traditional organizations, DAOs are…","tokens":2270,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259911388,"hash":"2b2d6cf18b31aa57474678cf08d90b8ddb7c8fda"}
{"url":"https://docs.openzeppelin.com/relayer/1.5.x/configuration/network","domain":"docs.openzeppelin.com","title":"Network Configuration | OpenZeppelin Docs","text":"RelayerConfigurationNetwork ConfigurationOpen in ClaudeThe OpenZeppelin Relayer supports multiple blockchain networks through a flexible JSON-based configuration system. This guide covers everything you need to know about configuring networks for your relayer instances.\nOverview\nNetworks are defined in JSON configuration files, allowing you to:\n\nConfigure any EVM-compatible network (Ethereum, Polygon, BSC, Arbitrum, Optimism, etc.)\nSet up Solana networks (mainnet-beta, devnet, testnet, custom RPC endpoints)\nConfigure Stellar networks (Pubnet, Testnet, custom networks)\nCreate custom network configurations with specific RPC endpoints, chain IDs, and network parameters\nUse inheritance to create network variants without duplicating configuration\n\nNetwork Types\nNetwork TypeDescriptionevmEthereum Virtual Machine compatible networks. Supports any EVM chain by configuring chain ID, RPC URLs, and network-specific parameters.solanaSolana blockchain networks. Supports all Solana clusters and custom RPC endpoints.stellarStellar blockchain networks. Supports Stellar Public Network and Testnet.\nConfiguration Methods\nDefault Network Configuration\nIf no networks field is specified in your config.json, the relayer will automatically load network configurations from the ./config/networks directory. This is the default behavior.\n{\n \"relayers\": [...],\n \"notifications\": [...],\n \"signers\": [...]\n // No \"networks\" field - defaults to \"./config/networks\"\n}\nOnce you specify a networks field in your configuration, the default\n./config/networks directory will not be loaded automatically. If you\nwant to use files from that directory, you must explicitly specify the path\n\"./config/networks\".\nYou can configure networks in two ways:\nMethod 1: Separate JSON Files\nSpecify the path to network configuration files in your main config.json:\n{\n \"relayers\": [...],\n \"notifications\": [...],\n \"signers\": [...],\n \"networks\": \"./config/networks\" // Path to directory or file\n}\nThis is the same as the default behavior, but explicitly specified. You can\nalso point to a different directory or file path.\nEach JSON file must contain a top-level networks array:\n{\n \"networks\": [\n // ... network definitions ...\n ]\n}\nWhen using a directory structure:\nnetworks/\n├── evm.json # {\"networks\": [...]}\n├── solana.json # {\"networks\": [...]}\n└── stellar.json # {\"networks\": [...]}\nMethod 2: Direct Configuration\nDefine networks directly in your main config.json instead of using separate files:\n{\n \"relayers\": [...],\n \"notifications\": [...],\n \"signers\": [...],\n \"networks\": [\n {\n \"type\": \"evm\",\n \"network\": \"ethereum-mainnet\",\n \"chain_id\": 1,\n // ... other fields\n }\n ]\n}\nWhen using this method, the default ./config/networks directory is ignored, and only the networks defined in this array will be available.\nNetwork Field Reference\nCommon Fields\nAll network types support these configuration fields:\nFieldTypeRequiredDescriptiontypestringYesNetwork type: \"evm\", \"solana\", or \"stellar\"networkstringYesUnique network identifier (e.g., \"ethereum-mainnet\", \"polygon-mumbai\")fromstringNoName of parent network to inherit from (same type only)rpc_urlsarray[string]Yes*List of RPC endpoint URLs (*Required for base networks, optional for inherited)explorer_urlsarray[string]NoList of blockchain explorer URLsaverage_blocktime_msnumberNoEstimated average time between blocks in millisecondsis_testnetbooleanNoWhether this is a testnet (affects behavior and validation)tagsarray[string]NoArbitrary tags for categorization and filtering\nSpecial Network Tags\nSome tags have special meaning and affect relayer behavior:\nTagDescription and BehaviorrollupIdentifies Layer 2 rollup networks (e.g., Arbitrum, Optimism, Base)optimism-basedIdentifies Optimism-based networks using the OP Stack (e.g., Optimism, Base, World Chain)optimism (deprecated)DEPRECATED: Use optimism-based instead. This tag will be removed in a future version.arbitrum-basedIdentifies Arbitrum-based networks using the Arbitrum Stackno-mempoolIndicates networks that lack a traditional mempool (e.g., Arbitrum). Note: The relayer also treats networks tagged as arbitrum-based or optimism-based as lacking a mempool, even if no-mempool is not present.deprecatedMarks networks that are deprecated and may be removed in future versions\nExample: Using Special Tags\nHere’s an example showing how special tags are used in practice:\n{\n \"type\": \"evm\",\n \"network\": \"arbitrum-one\",\n \"chain_id\": 42161,\n \"required_confirmations\": 1,\n \"symbol\": \"ETH\",\n \"rpc_urls\": [\"https://arb1.arbitrum.io/rpc\"],\n \"tags\": [\"rollup\", \"no-mempool\"], // Arbitrum is a rollup without mempool\n \"is_testnet\": false\n}\nThese tags help the relayer:\n\nApply specific transaction handling for rollups\nUse optimized fee calculation for OP Stack chains\nSkip mempool-related operations for networks without mempools\nWarn users about deprecated networks\n\nEVM-Specific Fields\nThe OpenZeppelin Relayer supports any EVM-based L1 blockchain, as long as it\ndoesn’t deviate significantly from standard EVM behavior. Some L2 networks may\nalso work, depending on how closely they follow EVM conventions. Users are\nencouraged to add the networks they need via the JSON configuration and test\nthem thoroughly on testnets before deploying to production.\nFieldTypeRequiredDescriptionchain_idnumberYes*Unique chain identifier (e.g., 1 for Ethereum mainnet, 137 for Polygon) (*Required for base networks, optional for inherited)required_confirmationsnumberYes*Number of block confirmations before considering a transaction final (*Required for base networks, optional for inherited)symbolstringYes*Native currency symbol (e.g., \"ETH\", \"MATIC\", \"BNB\") (*Required for base networks, optional for inherited)featuresarray[string]NoSupported features (e.g., [\"eip1559\", \"london\"])\nExample: EVM Network Configuration\nHere’s an example showing an EVM network configuration:\n{\n \"type\": \"evm\",\n \"network\": \"ethereum-mainnet\",\n \"chain_id\": 1, // Ethereum mainnet chain ID\n \"required_confirmations\": 12, // High security: 12 confirmations\n \"symbol\": \"ETH\", // Native currency symbol\n \"features\": [\"eip1559\"], // Supports EIP-1559 fee market\n \"rpc_urls\": [\"https://mainnet.infura.io/v3/YOUR_KEY\"],\n \"is_testnet\": false\n}\nSolana-Specific Fields\nCurrently, Solana networks use only the common fields. Additional Solana-specific configuration options may be added in future versions.\nStellar-Specific Fields\nFieldTypeRequiredDescriptionpassphrasestringNoNetwork passphrase for transaction signing and network identification (optional for all networks, including base networks)\nExample: Stellar Network Configuration\nHere’s an example showing a Stellar network configuration with passphrase:\n{\n \"type\": \"stellar\",\n \"network\": \"pubnet\",\n \"rpc_urls\": [\"https://mainnet.sorobanrpc.com\"],\n \"explorer_urls\": [\"https://stellar.expert/explorer/public\"],\n \"passphrase\": \"Public Global Stellar Network ; September 2015\", // Official mainnet passphrase\n \"average_blocktime_ms\": 5000,\n \"is_testnet\": false\n}\nConfiguration Examples\nBasic EVM Network\n{\n \"type\": \"evm\",\n \"network\": \"ethereum-mainnet\",\n \"chain_id\": 1,\n \"required_confirmations\": 12,\n \"symbol\": \"ETH\",\n \"rpc_urls\": [\"https://mainnet.infura.io/v3/YOUR_KEY\"],\n \"explorer_urls\": [\"https://etherscan.io\"],\n \"average_blocktime_ms\": 12000,\n \"is_testnet\": false,\n \"tags\": [\"mainnet\", \"ethereum\"]\n}\nLayer 2 EVM Network with Tags\n{\n \"type\": \"evm\",\n \"network\": \"optimism\",\n \"chain_id\": 10,\n \"required_confirmations\": 1,\n \"symbol\": \"ETH\",\n \"rpc_urls\": [\"https://mainnet.optimism.io\", \"https://optimism.drpc.org\"],\n \"features\": [\"eip1559\"],\n \"tags\": [\"rollup\", \"optimism-based\"],\n \"average_blocktime_ms\": 2000,\n \"is_testnet\": false\n}\nSolana Network\n{\n \"type\": \"solana\",\n \"network\": \"mainnet-beta\",\n \"rpc_urls\": [\"https://api.mainnet-beta.solana.com\"],\n \"explorer_urls\": [\"https://explorer.solana.com\"],\n \"average_blocktime_ms\": 400,\n \"is_testnet\": false,\n \"tags\": [\"mainnet\", \"solana\"]\n}\nStellar Network\n{\n \"type\": \"stellar\",\n \"network\": \"pubnet\",\n \"rpc_urls\": [\"https://mainnet.sorobanrpc.com\"],\n \"passphrase\": \"Public Global Stellar Network ; September 2015\",\n \"explorer_urls\": [\"https://stellar.expert/explorer/public\"],\n \"average_blocktime_ms\": 5000,\n \"is_testnet\": false,\n \"tags\": [\"mainnet\", \"stellar\"]\n}\nNetwork Inheritance\nNetworks can inherit from other networks of the same type, allowing you to create variants without duplicating configuration:\n{\n \"networks\": [\n {\n \"type\": \"evm\",\n \"network\": \"ethereum-base\",\n \"chain_id\": 1,\n \"required_confirmations\": 12,\n \"symbol\": \"ETH\",\n \"rpc_urls\": [\"https://mainnet.infura.io/v3/YOUR_KEY\"]\n },\n {\n \"from\": \"ethereum-base\",\n \"type\": \"evm\",\n \"network\": \"ethereum-sepolia\",\n \"chain_id\": 11155111,\n \"required_confirmations\": 3,\n \"rpc_urls\": [\"https://sepolia.infura.io/v3/YOUR_KEY\"],\n \"is_testnet\": true\n }\n ]\n}\nWhen using inheritance:\n\nThe child network inherits all fields from the parent\nFields specified in the child override parent values\nThe from field must reference a network of the same type\n\nUsing Networks in Relayer Configuration\nOnce networks are defined, reference them in your relayer configurations:\n{\n \"relayers\": [\n {\n \"id\": \"my-evm-relayer\",\n \"name\": \"My EVM Relayer\",\n \"network\": \"ethereum-mainnet\", // References network ID\n \"network_type\": \"evm\",\n \"signer_id\": \"my-signer\"\n }\n ]\n}\nBest Practices\n1. Network Organization\n\nGroup related networks in separate files (e.g., ethereum.json, polygon.json)\nUse consistent naming conventions for network identifiers\nInclude both mainnet and testnet configurations\n\n2. RPC URLs\n\nAlways configure multiple RPC URLs for redundancy\nUse private/dedicated RPC endpoints for production\nEnsure URLs are secure (HTTPS) when accessing over public networks\nConfigure RPC_ALLOWED_HOSTS and RPC_BLOCK_PRIVATE_IPS environment variables for SSRF protection in production. See Configuration → RPC URL Security for details.\n\n3. Confirmation Requirements\n\nSet appropriate required_confirmations based on network security\nHigher values for mainnet, lower for testnets\nConsider network-specific finality characteristics\n\n4. Tags and Features\n\nUse tags to categorize networks (e.g., \"mainnet\", \"testnet\", \"rollup\")\nEnable appropriate features (e.g., \"eip1559\" for supported networks)\nDocument custom tags used in your organization\n\n5. Inheritance\n\nCreate base configurations for common settings\nUse inheritance to reduce duplication\nOverride only necessary fields in child networks\n\nTroubleshooting\nCommon Issues\nNetwork not found:\n\nEnsure the network identifier in relayer config matches exactly\nCheck that network configuration files are in the correct location\nVerify JSON syntax is valid\n\nRPC connection failures:\n\nTest RPC URLs independently before configuring\nEnsure firewall/network allows outbound HTTPS connections\nCheck API keys are included in RPC URLs where required\n\nInvalid configuration:\n\nValidate required fields are present for network type\nEnsure numeric fields (chain_id, confirmations) are numbers, not strings\nCheck that inherited networks reference existing parent networks\n\nSee Also\n\nRelayer Configuration\nQuickstart Guide\nSolana Integration\nAPI Reference\nSignersPrevious PageStorage ConfigurationNext PageOn this pageOverviewNetwork TypesConfiguration MethodsDefault Network ConfigurationMethod 1: Separate JSON FilesMethod 2: Direct ConfigurationNetwork Field ReferenceCommon FieldsSpecial Network TagsExample: Using Special TagsEVM-Specific FieldsExample: EVM Network ConfigurationSolana-Specific FieldsStellar-Specific FieldsExample: Stellar Network ConfigurationConfiguration ExamplesBasic EVM NetworkLayer 2 EVM Network with TagsSolana NetworkStellar NetworkNetwork InheritanceUsing Networks in Relayer ConfigurationBest Practices1. Network Organization2. RPC URLs3. Confirmation Requirements4. Tags and Features5. InheritanceTroubleshootingCommon IssuesSee Also","tokens":2946,"squid":"ink-security_audits","role":"Sentinel","at":1791259911428,"hash":"b96f5bd2bb1f75fb563bd260b02aa0a96ea60ed5"}
{"url":"https://eips.ethereum.org/EIPS/eip-6953","domain":"eips.ethereum.org","title":"EIP-6953: Network Upgrade Activation Triggers","text":"🎉 Final\n\n Informational\n\n EIP-6953: Network Upgrade Activation Triggers\n\n Exhaustive list of network upgrade activation mechanisms\n\n Authors\n Tim Beiko (@timbeiko)\n\n Created\n 2023-04-28\n\n Requires\n\n EIP-2982, \n\n EIP-3675, \n\n EIP-6122\n\n Abstract\n\nThis EIP outlines the various network upgrade activation triggers used on Ethereum over time, from the proof-of-work era to the first post-merge network upgrade, Shanghai/Capella, across both the execution and consensus layers.\n\n Motivation\n\nThis EIP aims to provide users and developers with a single source of truth for understanding the various upgrade activation patterns used throughout Ethereum’s history. It does not aim to be a comprehensive, ongoing record, of upgrades and their activations mechanism. Readers should assume that future upgrades use the mechanism described in the Post Merge Upgrades section, unless this EIP is superseded by another one.\n\n Specification\n\n Proof-of-Work Network Upgrades\n\nDuring the proof-of-work era, network upgrades on Ethereum were triggered based on specific block numbers. The following upgrades followed this pattern:\n\n Upgrade Name\n Activation Block Number\n\n Frontier\n 1\n\n Frontier Thawing\n 200000\n\n Homestead\n 1150000\n\n DAO Fork\n 1920000\n\n Tangerine Whistle\n 2463000\n\n Spurious Dragon\n 2675000\n\n Byzantium\n 4370000\n\n Constantinople\n 7280000\n\n Petersburg\n 7280000\n\n Istanbul\n 9069000\n\n Muir Glacier\n 9200000\n\n Berlin\n 12244000\n\n London\n 12965000\n\n Arrow Glacier\n 13773000\n\n Gray Glacier\n 15050000\n\n Beacon Chain Launch\n\nThe Beacon Chain was launched following a set of conditions detailed in EIP-2982. The launch was activated once all the following conditions were met:\n\n The Beacon Chain deposit contract received at least 524288 ETH from 16384 validators.\n The MIN_GENESIS_TIME timestamp of 1606824000 (Dec 1, 2020) had been exceeded.\n A GENESIS_DELAY of 604800 seconds had passed since the minimum validator count was exceeded.\n\n Beacon Chain Upgrades\n\nBeacon Chain upgrades are activated at specific epochs. The following upgrades followed this pattern:\n\n Upgrade Name\n Activation Epoch\n\n Altair\n 74240\n\n Bellatrix\n 144896\n\n The Merge: Paris Upgrade\n\nThe Paris upgrade, the execution layer portion of “The Merge,” was triggered by a proof-of-work Total Difficulty value of 58750000000000000000000, as specified in EIP-3675. Note that the activation of the Bellatrix upgrade on the Beacon Chain was a pre-requisite for the Paris upgrade to successfully activate on the proof-of-work chain.\n\n Post-Merge Upgrades\n\nAfter The Merge, network upgrades are triggered at an epoch on the consensus layer (CL), which ideally maps to an historical roots accumulator boundary (i.e., a multiple of 8192 slots). The epoch’s corresponding timestamp, rather than a block number, is then used on the execution layer (EL) as the activation trigger. The following upgrades followed this pattern:\n\n Upgrade Name\n Activation Epoch\n Activation Timestamp\n\n Capella (CL)\n 194048\n\n Shanghai (EL)\n\n 1681338455\n\nNote that epoch 194048 happened at timestamp 1681338455. In other words, the upgrades activated simultaneously on both the execution and consensus layers, even though they each used a different constant to trigger it.\n\nAdditionally, the use of timestamps on the execution layer resulted in changes to how nodes’ FORK_HASH and FORK_NEXT values are calculated. These are described in EIP-6122\n\n Rationale\n\n Blocks and Epochs\n\nBlocks and epochs serve as natural trigger points for upgrades, as they represent the levels at which state transitions occur on Ethereum.\n\n Terminal Total Difficulty\n\nFor the Terminal Total Difficulty mechanism, the rationale can be found in EIP-3675.\n\n Timestamps\n\nDue to the possibility of missed slots on the Beacon Chain, the execution layer cannot rely solely on block numbers to trigger upgrades in sync with the consensus layer.\n\nTimestamps are guaranteed to map to a specific epoch, and in their Unix representation, timestamps will always be greater than the block numbers previously used. This allows for a reliable method to trigger upgrades on the execution layer post-merge, while also ensuring that a post-merge upgrade based on a timestamp can never use a value that is considered lower than the last block-triggered upgrade.\n\n Security Considerations\n\nNone.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Tim Beiko (@timbeiko), \"EIP-6953: Network Upgrade Activation Triggers,\" Ethereum Improvement Proposals, no. 6953, April 2023. Available: https://eips.ethereum.org/EIPS/eip-6953.","tokens":1142,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259920983,"hash":"f45d15126b78e190fcdd5bc7bfeb1963d60e6b90"}
{"url":"https://docs.openzeppelin.com/relayer/1.5.x/configuration/signers","domain":"docs.openzeppelin.com","title":"Signers Configuration | OpenZeppelin Docs","text":"RelayerConfigurationSigners ConfigurationOpen in ClaudeOverview\nSigners are responsible for cryptographically signing transactions before they are submitted to blockchain networks. OpenZeppelin Relayer supports multiple signer types to accommodate different security requirements and infrastructure setups.\nEach signer is referenced by its id in relayer configurations.\nConfiguration Structure\nExample signer configuration:\n\"signers\": [\n {\n \"id\": \"my_id\",\n \"type\": \"local\",\n \"config\": {\n \"path\": \"config/keys/local-signer.json\",\n \"passphrase\": {\n \"type\": \"env\",\n \"value\": \"KEYSTORE_PASSPHRASE\"\n }\n }\n }\n]\nSupported Signer Types\nOpenZeppelin Relayer supports the following signer types:\n\nlocal: Keystore file signer\nvault: HashiCorp Vault secret signer\nvault_transit: HashiCorp Vault Transit signer\nturnkey: Turnkey signer\ngoogle_cloud_kms: Google Cloud KMS signer\naws_kms: Amazon AWS KMS signer\ncdp: Coinbase Developer Platform signer\n\nNetwork Compatibility Matrix\nThe following table shows which signer types are compatible with each network type:\nSigner TypeEVM NetworksSolana NetworksStellar Networkslocal✅ Supported✅ Supported✅ Supportedvault✅ Supported✅ Supported❌ Not supportedvault_transit❌ Not supported✅ Supported❌ Not supportedturnkey✅ Supported✅ Supported✅ Supportedgoogle_cloud_kms✅ Supported✅ Supported✅ Supportedaws_kms✅ Supported✅ Supported✅ Supportedcdp✅ Supported✅ Supported❌ Not supported\nNetwork-specific considerations:\nEVM Networks: Use secp256k1 cryptography. Most signers support EVM networks with proper key generation.\nSolana Networks: Use ed25519 cryptography. Ensure your signer supports ed25519 key generation and signing.\nStellar Networks: Use ed25519 cryptography with specific Stellar requirements. Supported by local, AWS KMS, Google Cloud KMS, and Turnkey signers.\nAWS KMS: Supports secp256k1 (EVM) and ed25519 (Solana, Stellar) key types.\nGoogle Cloud KMS: Supports secp256k1 (EVM) and ed25519 (Solana, Stellar) key types.\nTurnkey: Supports EVM, Solana, and Stellar networks with appropriate key management.\n\nCommon Configuration Fields\nAll signer types share these common configuration fields:\nFieldTypeDescriptionidStringUnique identifier for the signer (used to reference this signer in relayer configurations)typeStringType of signer (see supported signer types above)configMapSigner type-specific configuration object\nLocal Signer Configuration\nThe local signer uses encrypted keystore files stored on the filesystem.\n{\n \"id\": \"local-signer\",\n \"type\": \"local\",\n \"config\": {\n \"path\": \"config/keys/local-signer.json\",\n \"passphrase\": {\n \"type\": \"env\",\n \"value\": \"KEYSTORE_PASSPHRASE\"\n }\n }\n}\nConfiguration fields:\nFieldTypeDescriptionpathStringPath to the signer JSON file. Should be under the ./config directorypassphrase.typeStringType of passphrase source (env or plain)passphrase.valueStringPassphrase value or environment variable name\nHashiCorp Vault Signer Configuration\nVault Secret Signer\nUses HashiCorp Vault’s secret engine to store private keys.\n{\n \"id\": \"vault-signer\",\n \"type\": \"vault\",\n \"config\": {\n \"address\": \"https://vault.example.com\",\n \"role_id\": {\n \"type\": \"env\",\n \"value\": \"VAULT_ROLE_ID\"\n },\n \"secret_id\": {\n \"type\": \"env\",\n \"value\": \"VAULT_SECRET_ID\"\n },\n \"key_name\": \"relayer-key\",\n \"mount_point\": \"secret\"\n }\n}\nConfiguration fields:\nFieldTypeDescriptionaddressStringSpecifies the Vault API endpointrole_id.typeStringType of value source (env or plain)role_id.valueStringThe Vault AppRole role identifier value, or the environment variable name where the AppRole role identifier is storedsecret_id.typeStringType of value source (env or plain)secret_id.valueStringThe Vault AppRole role secret value, or the environment variable name where the AppRole secret value is storedkey_nameStringThe name of the cryptographic key within Vault’s Secret engine that is used for signing operationsmount_pointStringThe mount point for the Secrets engine in Vault. Defaults to secret if not explicitly specified. Optional.\nVault Transit Signer\nUses HashiCorp Vault’s Transit secrets engine for cryptographic operations.\n{\n \"id\": \"vault-transit-signer\",\n \"type\": \"vault_transit\",\n \"config\": {\n \"address\": \"https://vault.example.com\",\n \"role_id\": {\n \"type\": \"env\",\n \"value\": \"VAULT_ROLE_ID\"\n },\n \"secret_id\": {\n \"type\": \"env\",\n \"value\": \"VAULT_SECRET_ID\"\n },\n \"key_name\": \"relayer-transit-key\",\n \"mount_point\": \"transit\",\n \"namespace\": \"production\",\n \"pubkey\": \"your-public-key-here\"\n }\n}\nConfiguration fields:\nFieldTypeDescriptionaddressStringSpecifies the Vault API endpointrole_id.typeStringType of value source (env or plain)role_id.valueStringThe Vault AppRole role identifier value, or the environment variable name where the AppRole role identifier is storedsecret_id.typeStringType of value source (env or plain)secret_id.valueStringThe Vault AppRole role secret value, or the environment variable name where the AppRole secret value is storedkey_nameStringThe name of the cryptographic key within Vault’s Transit engine that is used for signing operationsmount_pointStringThe mount point for the Transit secrets engine in Vault. Defaults to transit if not explicitly specified. Optional.namespaceStringThe Vault namespace for API calls. This is used only in Vault Enterprise environments. Optional.pubkeyStringPublic key of the cryptographic key within Vault’s Transit engine that is used for signing operations\nTurnkey Signer Configuration\nUses Turnkey’s secure key management infrastructure.\n{\n \"id\": \"turnkey-signer\",\n \"type\": \"turnkey\",\n \"config\": {\n \"api_public_key\": \"your-api-public-key\",\n \"api_private_key\": {\n \"type\": \"env\",\n \"value\": \"TURNKEY_API_PRIVATE_KEY\"\n },\n \"organization_id\": \"your-org-id\",\n \"private_key_id\": \"your-private-key-id\",\n \"public_key\": \"your-public-key\"\n }\n}\nConfiguration fields:\nFieldTypeDescriptionapi_public_keyStringThe public key associated with your Turnkey API access credentials. Used for authentication to the Turnkey signing serviceapi_private_key.typeStringType of value source (env or plain)api_private_key.valueStringThe Turnkey API private key or environment variable name containing it. Used with the public key to authenticate API requestsorganization_idStringYour unique Turnkey organization identifier. Required to access resources within your specific organizationprivate_key_idStringThe unique identifier of the private key in your Turnkey account that will be used for signing operationspublic_keyStringThe public key corresponding to the private key identified by private_key_id. Used for address derivation and signature verification\nGoogle Cloud KMS Signer Configuration\nUses Google Cloud Key Management Service for secure key operations.\nNetwork-specific key requirements:For EVM transaction signing, ensure your Google Cloud KMS key is created with:\nProtection level: HSM\nPurpose: Asymmetric sign\nAlgorithm: \"Elliptic Curve secp256k1 - SHA256 Digest\"\nFor Solana and Stellar transaction signing, ensure your Google Cloud KMS key is created with:\nProtection level: Software or HSM\nPurpose: Asymmetric sign\nAlgorithm: \"Elliptic Curve ED25519 Key\"\n\n{\n \"id\": \"gcp-kms-signer\",\n \"type\": \"google_cloud_kms\",\n \"config\": {\n \"service_account\": {\n \"project_id\": \"your-gcp-project\",\n \"private_key_id\": {\n \"type\": \"env\",\n \"value\": \"GCP_PRIVATE_KEY_ID\"\n },\n \"private_key\": {\n \"type\": \"env\",\n \"value\": \"GCP_PRIVATE_KEY\"\n },\n \"client_email\": {\n \"type\": \"env\",\n \"value\": \"GCP_CLIENT_EMAIL\"\n },\n \"client_id\": \"your-client-id\"\n },\n \"key\": {\n \"location\": \"us-west2\",\n \"key_ring_id\": \"relayer-keyring\",\n \"key_id\": \"relayer-key\",\n \"key_version\": 1\n }\n }\n}\nConfiguration fields:\nFieldTypeDescriptionservice_account.project_idStringThe Google Cloud project ID where your KMS resources are locatedservice_account.private_key_id.typeStringType of value source for the private key ID (env or plain)service_account.private_key_id.valueStringThe private key ID value or the environment variable name containing itservice_account.private_key.typeStringType of value source for the private key (env or plain)service_account.private_key.valueStringThe Google Cloud service account private key (PEM format) or the environment variable name containing itservice_account.client_email.typeStringType of value source for the client email (env or plain)service_account.client_email.valueStringThe Google Cloud service account client email or the environment variable name containing itservice_account.client_idStringThe Google Cloud service account client IDkey.locationStringThe Google Cloud location (region) where your KMS key ring is located (e.g., \"us-west2\", \"global\")key.key_ring_idStringThe KMS key ring ID containing your cryptographic keykey.key_idStringThe KMS key ID used for signing operationskey.key_versionIntegerThe version of the KMS key to use for signing operations. Defaults to 1\nAWS KMS Signer Configuration\nUses Amazon Web Services Key Management Service for cryptographic operations.\n{\n \"id\": \"aws-kms-signer\",\n \"type\": \"aws_kms\",\n \"config\": {\n \"region\": \"us-west-2\",\n \"key_id\": \"arn:aws:kms:us-west-2:123456789012:key/12345678-1234-1234-1234-123456789012\"\n }\n}\nConfiguration fields:\nFieldTypeDescriptionregionStringAWS region. If the key is non-replicated across regions, this must match the key's original region. Optional. If not specified, the default region from shared credentials is usedkey_idStringID of the key in AWS KMS (can be key ID, key ARN, alias name, or alias ARN)\nCDP Signer Configuration\nUses CDP’s secure key management infrastructure.\n{\n \"id\": \"cdp-signer\",\n \"type\": \"cdp\",\n \"config\": {\n \"api_key_id\": \"your-cdp-api-key-id\",\n \"api_key_secret\": {\n \"type\": \"env\",\n \"value\": \"CDP_API_KEY_SECRET\"\n },\n \"wallet_secret\": {\n \"type\": \"env\",\n \"value\": \"CDP_WALLET_SECRET\"\n },\n \"account_address\": \"your-cdp-evm-or-solana-account-address\"\n }\n}\nConfiguration fields:\nFieldTypeDescriptionapi_key_idStringThe Key ID of a Secret API Key. Used for authentication to the CDP signing serviceapi_key_secret.typeStringType of value source (env or plain)api_key_secret.valueStringThe API key secret or environment variable name containing it. Used with the Key ID to authenticate API requestswallet_secret.typeStringType of value source (env or plain)wallet_secret.valueStringThe Wallet Secret or environment variable name containing it. Used to authorize API requests for signing operations.account_addressStringThe address of the CDP EVM EOA or CDP Solana Account used for signing operations.\nSecurity Best Practices\nFile Permissions\n\nSet restrictive permissions on keystore files: chmod 0500 config/keys/*\nEnsure configuration directories are properly secured\nUse environment variables for sensitive data like passphrases and API keys\n\nKey Management\n\nUse HSM-backed keys for production environments when available\nImplement proper key rotation policies\nNever commit private keys or sensitive configuration to version control\nUse dedicated service accounts with minimal required permissions\n\nEnvironment Separation\n\nUse different signers for different environments (development, staging, production)\nImplement proper secrets management in production deployments\nConsider using cloud-native key management services for enhanced security\n\nTroubleshooting\nCommon Issues\nInvalid keystore passphrase\n\nVerify the passphrase environment variable is correctly set\nCheck that the keystore file is not corrupted\nEnsure the keystore format is compatible\n\nCloud KMS authentication failures\n\nVerify service account credentials are valid and properly formatted\nCheck that the service account has necessary permissions for KMS operations\nEnsure the KMS key exists and is in the correct region/project\n\nVault connection issues\n\nVerify Vault server address and network connectivity\nCheck AppRole credentials and permissions\nEnsure the secret/transit engine is properly mounted and configured\n\nFor additional troubleshooting help, check the application logs and refer to the specific cloud provider or service documentation.OverviewPrevious PageNetwork ConfigurationNext PageOn this pageOverviewConfiguration StructureSupported Signer TypesNetwork Compatibility MatrixCommon Configuration FieldsLocal Signer ConfigurationHashiCorp Vault Signer ConfigurationVault Secret SignerVault Transit SignerTurnkey Signer ConfigurationGoogle Cloud KMS Signer ConfigurationAWS KMS Signer ConfigurationCDP Signer ConfigurationSecurity Best PracticesFile PermissionsKey ManagementEnvironment SeparationTroubleshootingCommon Issues","tokens":3100,"squid":"ink-security_audits","role":"Sentinel","at":1791259924123,"hash":"59430cd31fc3fdf8f38c58b658d97f652e81a3f2"}
{"url":"https://ethereum.org/staking/saas/","domain":"ethereum.org","title":"Delegated staking (staking as a service) | ethereum.org","text":"Edit page (opens in a new tab)What is delegated staking?\nDelegated staking represents a category of staking services where you deposit your own 32 ETH for a validator, but delegate node operations to a third-party operator. The process usually involves being guided through the initial setup, including key generation and deposit, then uploading your signing keys to the operator. You provide the ETH, but hand the operation of the validator's hardware to someone else.\nThe Ethereum protocol does not natively support delegation of stake, so a range of services have been built to fill this demand. This category is best known as staking as a service (SaaS), but it covers a spectrum of arrangements that differ on the key question of how much control you keep over your staked ETH:\n\nNon-custodial staking as a service: you keep your own withdrawal keys and delegate only validator operation.\nFully custodial staking: the provider, usually an exchange, holds both the keys and the funds.\n\nCompared to solo staking, every form of delegation places middleware between you and the Ethereum protocol. That middleware is software and infrastructure run by someone else's business. Each step toward convenience adds a trust assumption, so before choosing a service, work out where it sits on this spectrum.\nWhat delegated staking is not\n\nPooled staking and liquid staking tokens: with pools you combine any amount of ETH with other stakers, usually receiving a token that represents your share of the pool's stake. You are not delegating your own validator; the pool's smart contracts and node operators control the validators. More on pooled staking\nBonded node operation: some staking protocols let you run a validator on your own hardware with less than 32 ETH by posting a bond. That is node operation, the opposite of delegation, and is covered alongside solo staking.\n\nWhy delegate your staking?\nIf you have 32 ETH to stake, but don't feel comfortable dealing with hardware, delegated staking services allow you to hand off the technical side while you earn native Ethereum block rewards.\nYour own validatorDeposit your own 32 ETH to activate your own set of signing keys that will participate in Ethereum consensus. Monitor your progress with dashboards to watch those ETH rewards accumulate.Easy to startForget about hardware specs, setup, node maintenance and upgrades. Providers let you outsource the hard part by uploading your own signing credentials, allowing them to run a validator on your behalf, for a small cost.Limit your riskWith non-custodial services you keep control of the keys that enable withdrawing or transferring staked funds. These are different from the signing keys, and can be stored separately to limit (but not eliminate) your risk as a staker.\nComparison of staking options\nHome stakingSimilarities include having your own validator keys without having to pool funds, but with SaaS you must trust a third-party, who may potentially act maliciously or become a target of attack or regulation themselves. If these trust assumptions or centralization risks concern you, the gold standard of self-sovereign staking is solo staking.Learn more about home stakingLiquid & pooled stakingThese are similar in that you're generally relying on someone else to run the validator client, but unlike SaaS, pooled staking allows you to participate with smaller amounts of ETH. If you're looking to stake with less than 32 ETH, consider checking these out.Learn more about pooled staking\nThe delegation spectrum\nProviders differ in which keys they hold for you, and every key they hold is something you must trust them with.\nNon-custodial staking as a service\nWith non-custodial SaaS, you're typically guided through generating your validator keys and making your own 32 ETH deposit, then you upload the signing keys to the operator. The signing keys allow the operator to perform validator duties (attesting and proposing blocks) on your behalf. Misusing them can get your validator penalized or slashed, but they cannot be used to withdraw, transfer, or spend your funds.\nThe validator's withdrawal credentials stay pointed at an address you control. Rewards and exited funds can only ever go there (see the trust model section below).\nCustodial services and exchange staking\nAt the fully delegated end of the spectrum sits custodial staking, most commonly offered by centralized exchanges. You never handle keys at all; you just hold ETH in your platform account and opt in to staking. This is the simplest possible user experience, and it's a legitimate option for people who already keep funds on an exchange and accept custodial risk.\nIt also requires the most trust. The provider controls both the signing keys and the withdrawal credentials; what you hold is a balance on their platform, not a validator. That means:\n\nYour staked ETH is exposed to the provider's solvency, security, and regulatory situation, and withdrawals are subject to their terms and processing times, not just Ethereum protocol rules.\nYou have no independent way to exit the validator or recover funds if the provider fails or freezes withdrawals.\nLarge amounts of ETH staked under a handful of exchange operators contribute to stake centralization, and these operators' client choices affect the health of the network. Staking in a way that keeps more control in your hands, or choosing providers that demonstrably run minority clients, does more for Ethereum's resilience.\n\nTrust model: what to evaluate\nDelegated staking always means trusting someone else with part of your staking setup. Answer these questions before handing anything over:\n\nWho holds the withdrawal keys? A validator's withdrawal credentials (type 0x01 or 0x02) point to an execution layer address that ultimately controls the stake. If that address is yours, the arrangement is non-custodial; the operator can run (or mismanage) the validator, but the ETH can only ever be withdrawn to you. If the credentials point to the provider's address, you hold a promise, not a stake.\nCan you exit without the operator? Since the Pectra upgrade, execution layer triggered withdrawals (EIP-7002) (opens in a new tab) allow the withdrawal address to trigger a validator exit (or, for compounding 0x02 validators, a partial withdrawal of balance above 32 ETH) directly from the execution layer, without the signing keys. It requires a transaction and costs gas, but it means an unresponsive or defunct operator can no longer hold your validator hostage, provided the withdrawal credentials are yours.\nWhat is the fee structure? Services charge a flat monthly fee or a percentage of rewards. Check how fees interact with downtime and penalties: who bears the cost if the operator underperforms, and whether any guarantees or insurance are offered.\nWhich clients does the operator run? An operator running majority execution or consensus clients exposes both your stake and the network to correlated failure if that client has a bug. Prefer providers that document minority client usage.\nIs the service open and audited? Providers may run additional software around the standard Ethereum clients that is not open source or auditable. Look for public audits, an established operating history, and a clean slashing record.\nWhat happens if the provider disappears? A responsible provider documents its offboarding process, providing clear instructions for how you exit your validator, recover your keys, or trigger an exit yourself. If the answer depends entirely on the provider staying in business it is a custodial arrangement.\n\nSome providers can run your validator using distributed validator technology (DVT), splitting the signing key across multiple nodes so that no single machine or operator is a point of failure. More on distributed validator technology\nWhat to consider\nThere are a growing number of providers to help you delegate the operation of your validator, but they all have their own benefits and risks. All delegated options require additional trust assumptions compared to solo staking. Delegated options may have additional code wrapping the Ethereum clients that is not open or auditable. Delegation also has a detrimental effect on network decentralization. Depending on the setup, you may not control your validator, and the operator could act dishonestly using your ETH.\nAttribute indicators are used below to signal notable strengths or weaknesses a listed provider may have. Use this section as a reference for how we define these attributes while you're choosing a staking service.\nOpen sourceEssential code is 100% open source and available to the public to fork and useOpen sourceClosed source\nExplore staking service providers\nBelow are some available staking-as-a-service providers. Use the above indicators to help guide you through these services.\nProducts and services are listed as a convenience for the Ethereum community. Inclusion of a product or service does not represent an endorsement from the ethereum.org website team, or the Ethereum Foundation.\nSaaS providers\nSerenitaFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)BitwiseFrom 1000 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)KilnFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)P2P.orgFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)stakefishFrom 32 ETHBrowserWalletLinuxmacOSWindowsGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)RockX StakingFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Consensys StakingFrom 32 ETHmacOSWindowsGUIAPIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyGet started (opens in a new tab)FigmentFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)EthpoolFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Sensei NodeFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)ChainLaboFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Everstake InstitutionalFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Abyss FinanceFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)AllnodesFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)SquidFrom 32 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessExecution diversityConsensus diversitySelf custodyGet started (opens in a new tab)\nPlease note the importance of supporting client diversity as it improves the security of the network, and limits your risk. Services that have evidence of limiting majority client use are indicated with \"execution client diversity\" and \"consensus client diversity.\"\nKey Generators\nethdoLinuxWindowsCLIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyGet started (opens in a new tab)Wagyu Key GenLinuxmacOSWindowsGUIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)AvadoBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)\nHave a suggestion for a staking-as-a-service provider we missed? Check out our product listing policy to see if it would be a good fit, and to submit it for review.\n\nFrequently asked questions\nArrangements differ from provider to provider. With non-custodial services, you will be guided through generating the signing keys for your validator (each validator holds 32 ETH, or up to 2048 ETH with compounding (0x02) credentials since the Pectra upgrade), and uploading these to your provider to allow them to validate on your behalf. The signing keys alone do not give any ability to withdraw, transfer, or spend your funds. However, they do provide the ability to cast votes towards consensus, which if not done properly can result in offline penalties or slashing.With custodial services, such as staking through a centralized exchange, the provider holds all keys: the signing keys and the withdrawal credentials. In that case you are trusting the provider with the funds themselves, not just with validator operation.\nYes. Each validator has signing keys and separate withdrawal credentials. In order for a validator to attest to the state of the chain, participate in sync committees and propose blocks, the signing keys must be readily accessible by a validator client. These must be connected to the internet in some form, and are thus inherently considered to be \"hot\" keys. The keys that control withdrawn funds are kept separate for security reasons.The withdrawal credentials designate the execution layer address that staking rewards and exited funds go to. Modern deposit tooling lets you set this address at the time of deposit, as either a regular (0x01) or compounding (0x02) credential, and it should be an address you control, ideally secured in cold storage. This protects your funds even if someone else controls your validator signing keys, and since the Pectra upgrade it also lets you exit the validator directly from that address.Validators set up in the network's early days without an execution withdrawal address use legacy BLS withdrawal keys, and must sign a one-time message declaring a withdrawal address before withdrawals can begin. This involves regenerating the withdrawal keys from the mnemonic seed phrase created at setup.Make certain you back this seed phrase up safely or you will be unable to generate your withdrawal keys when the time comes.Check with your provider for support regarding how to prepare your validator.\nHow withdrawals work depends on your validator's withdrawal credential type. For regular (0x01) validators, any balance over 32 ETH is automatically swept to the withdrawal address on a periodic basis every few days. For compounding (0x02) validators, rewards compound into the validator's balance up to 2048 ETH, and withdrawing below that requires triggering a partial withdrawal from your withdrawal address, which costs gas.Validators can also fully exit, which unlocks the entire remaining ETH balance. After completing the exit process, the full balance is transferred to the withdrawal address during a subsequent validator sweep.More on staking withdrawals\nIf your withdrawal credentials point to an address you control, you can exit the validator yourself and recover your stake; see Trust model: what to evaluate.If the provider holds the withdrawal credentials (as with custodial and exchange staking), there is no protocol-level way for you to recover the funds independently; your recourse is limited to the provider's own processes.\nBy using a delegated staking provider, you are entrusting the operation of your node to someone else. This comes with the risk of poor node performance, which is not in your control. In the event your validator is slashed, an initial penalty proportional to your validator's balance is applied (made significantly smaller in the Pectra upgrade), and your validator is forcibly exited from the validator set.Upon completion of the slashing/exiting process, the remaining funds are transferred to the withdrawal address assigned to the validator.Contact individual providers for more details on any guarantees or insurance options. If you'd prefer to be in full control of your validator setup, learn more about how to solo stake your ETH.\nFurther reading\n\nWhat is Staking-as-a-Service? (opens in a new tab) - Figment\nThe Ethereum Staking Directory (opens in a new tab) - Eridian and Spacesider\nEvaluating Staking Services (opens in a new tab) - Jim McDonald 2020\nEIP-7002: Execution layer triggerable withdrawals (opens in a new tab) - the specification for exiting a validator from its withdrawal address","tokens":4374,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259924223,"hash":"bca1c445a906e45886b771e437d430a09181c315"}
{"url":"https://eips.ethereum.org/EIPS/eip-3675","domain":"eips.ethereum.org","title":"EIP-3675: Upgrade consensus to Proof-of-Stake","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-3675: Upgrade consensus to Proof-of-Stake\n\n Specification of the consensus mechanism upgrade on Ethereum Mainnet that introduces Proof-of-Stake\n\n Authors\n Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin)\n\n Created\n 2021-07-22\n\n Requires\n\n EIP-2124\n\n Abstract\n\nThis EIP deprecates Proof-of-Work (PoW) and supersedes it with the new Proof-of-Stake consensus mechanism (PoS) driven by the beacon chain. Information on the bootstrapping of the new consensus mechanism is documented in EIP-2982. Full specification of the beacon chain can be found in the ethereum/consensus-specs repository.\n\nThis document specifies the set of changes to the block structure, block processing, fork choice rule and network interface introduced by the consensus upgrade.\n\n Motivation\n\nThe beacon chain network has been up and running since December 2020. Neither safety nor liveness failures were detected during this period of time. This long period of running without failure demonstrates the sustainability of the beacon chain system and its readiness to become a security provider for the Ethereum Mainnet.\n\nTo understand the motivation of introducing the Proof-of-Stake consensus see the Motivation section of EIP-2982.\n\n Specification\n\n Definitions\n\n PoW block: Block that is built and verified by the existing proof-of-work mechanism. In other words, a block of the Ethereum network before the consensus upgrade.\n PoS block: Block that is built and verified by the new proof-of-stake mechanism.\n Terminal PoW block: A PoW block that satisfies the following conditions –\npow_block.total_difficulty >= TERMINAL_TOTAL_DIFFICULTY and pow_block.parent_block.total_difficulty < TERMINAL_TOTAL_DIFFICULTY.\nThere can be more than one terminal PoW block in the network, e.g. multiple children of the same pre-terminal block.\n TERMINAL_TOTAL_DIFFICULTY The amount of total difficulty reached by the network that triggers the consensus upgrade. Ethereum Mainnet configuration MUST have this parameter set to the value 58750000000000000000000.\n TRANSITION_BLOCK The earliest PoS block of the canonical chain, i.e. the PoS block with the lowest block height.\n POS_FORKCHOICE_UPDATED An event occurring when the state of the proof-of-stake fork choice is updated.\n FORK_NEXT_VALUE A block number set to the FORK_NEXT parameter for the upcoming consensus upgrade.\n TERMINAL_BLOCK_HASH Designates the hash of the terminal PoW block if set, i.e. if not stubbed with 0x0000000000000000000000000000000000000000000000000000000000000000.\n TERMINAL_BLOCK_NUMBER Designates the number of the terminal PoW block if TERMINAL_BLOCK_HASH is set.\n\n PoS events\n\nEvents having the POS_ prefix in the name (PoS events) are emitted by the new proof-of-stake consensus mechanism. They signify the corresponding assertion that has been made regarding a block specified by the event. The underlying logic of PoS events can be found in the beacon chain specification. On the occurrence of each PoS event the corresponding action that is specified by this EIP MUST be taken.\n\nThe details provided below must be taken into account when reading those parts of the specification that refer to the PoS events:\n\n Reference to a block that is contained by PoS events is provided in a form of a block hash unless another is explicitly specified.\n A POS_FORKCHOICE_UPDATED event contains references to the head of the canonical chain and to the most recent finalized block. Before the first finalized block occurs in the system the finalized block hash provided by this event is stubbed with 0x0000000000000000000000000000000000000000000000000000000000000000.\n FIRST_FINALIZED_BLOCK The first finalized block that is designated by POS_FORKCHOICE_UPDATED event and has the hash that differs from the stub.\n\n Client software configuration\n\nThe following set of parameters is a part of client software configuration and MUST be included into its binary distribution:\n\n TERMINAL_TOTAL_DIFFICULTY\n FORK_NEXT_VALUE\n TERMINAL_BLOCK_HASH\n TERMINAL_BLOCK_NUMBER\n\nNote: If TERMINAL_BLOCK_HASH is stubbed with 0x0000000000000000000000000000000000000000000000000000000000000000 then TERMINAL_BLOCK_HASH and TERMINAL_BLOCK_NUMBER parameters MUST NOT take an effect.\n\n PoW block processing\n\nPoW blocks that are descendants of any terminal PoW block MUST NOT be imported. This implies that a terminal PoW block will be the last PoW block in the canonical chain.\n\n Constants\n\n Name\n Value\n\n MAX_EXTRA_DATA_BYTES\n 32\n\n Block structure\n\nBeginning with TRANSITION_BLOCK, a number of previously dynamic block fields are deprecated by enforcing these values to instead be constants. Each block field listed in the table below MUST be replaced with the corresponding constant value.\n\n Field\n Constant value\n Comment\n\n ommersHash\n 0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347\n = Keccak256(RLP([]))\n\n difficulty\n 0\n\n mixHash\n 0x0000000000000000000000000000000000000000000000000000000000000000\n\n nonce\n 0x0000000000000000\n\n ommers\n []\n RLP([]) = 0xc0\n\nBeginning with TRANSITION_BLOCK, the validation of the block’s extraData field changes: The length of the block’s extraData MUST be less than or equal to MAX_EXTRA_DATA_BYTES bytes.\n\nNote: Logic and validity conditions of block fields that are not specified here MUST remain unchanged. Additionally, the overall block format MUST remain unchanged.\n\nNote: Subsequent EIPs may override the constant values specified above to provide additional functionality. For an example, see EIP-4399.\n\n Block validity\n\nBeginning with TRANSITION_BLOCK, the block validity conditions MUST be altered by the following:\n\n Remove verification of the block’s difficulty value with respect to the difficulty formula.\n Remove verification of the block’s nonce and mixHash values with respect to the Ethash function.\n Remove all validation rules that are evaluated over the list of ommers and each member of this list.\n Add verification of the fields noted in the block structure section.\n\nNote: If one of the new rules fails then the block MUST be invalidated.\n\nNote: Validity rules that are not specified in the list above MUST remain unchanged.\n\n Transition block validity\n\nIn addition to satisfying the above conditions, TRANSITION_BLOCK MUST be a child of a terminal PoW block. That is, a parent of TRANSITION_BLOCK MUST satisfy terminal PoW block conditions.\n\n Block and ommer rewards\n\nBeginning with TRANSITION_BLOCK, block and ommer rewards are deprecated. Specifically, the following actions MUST be taken:\n\n Remove increasing the balance of the block’s beneficiary account by the block reward.\n Remove increasing the balance of the block’s beneficiary account by the ommer inclusion reward per each ommer.\n Remove increasing the balance of the ommer’s beneficiary account by the ommer block reward per each ommer.\n\nNote: Transaction fee mechanics affecting the block’s beneficiary account MUST remain unchanged.\n\n Fork choice rule\n\nIf set, TERMINAL_BLOCK_HASH parameter affects the PoW heaviest chain rule in the following way:\n\n Canonical blockchain MUST contain a block with the hash defined by TERMINAL_BLOCK_HASH parameter at the height defined by TERMINAL_BLOCK_NUMBER parameter.\n\nNote: This rule is akin to block hash whitelisting functionality already present in client software implementations.\n\nAs of the first POS_FORKCHOICE_UPDATED event, the fork choice rule MUST be altered in the following way:\n\n Remove the existing PoW heaviest chain rule.\n Adhere to the new PoS LMD-GHOST rule.\n\nThe new PoS LMD-GHOST fork choice rule is specified as follows. On each occurrence of a POS_FORKCHOICE_UPDATED event including the first one, the following actions MUST be taken:\n\n Consider the chain starting at genesis and ending with the head block nominated by the event as the canonical blockchain.\n Set the head of the canonical blockchain to the corresponding block nominated by the event.\n Beginning with the FIRST_FINALIZED_BLOCK, set the most recent finalized block to the corresponding block nominated by the event.\n\nChanges to the block tree store that are related to the above actions MUST be applied atomically.\n\nNote: This rule MUST be strictly enforced. “Optimistic” updates to the head MUST NOT be made. That is – if a new block is processed on top of the current head block, this new block becomes the new head if and only if an accompanying POS_FORKCHOICE_UPDATED event occurs.\n\n Network\n\n Fork identifier\n\nFor the purposes of the EIP-2124 fork identifier, nodes implementing this EIP MUST set the FORK_NEXT parameter to the FORK_NEXT_VALUE.\n\n devp2p\n\nThe networking stack SHOULD NOT send the following messages if they advertise the descendant of any terminal PoW block:\n\n NewBlockHashes (0x01)\n NewBlock (0x07)\n\nBeginning with receiving the FIRST_FINALIZED_BLOCK, the networking stack MUST discard the following ingress messages:\n\n NewBlockHashes (0x01)\n NewBlock (0x07)\n\nBeginning with receiving the finalized block next to the FIRST_FINALIZED_BLOCK, the networking stack MUST remove the handlers corresponding to the following messages:\n\n NewBlockHashes (0x01)\n NewBlock (0x07)\n\nPeers that keep sending these messages after the handlers have been removed SHOULD be disconnected.\n\nNote: The logic of message handlers that are not affected by this section MUST remain unchanged.\n\n Rationale\n\nThe changes specified in this EIP target a minimal requisite set of consensus and client software modifications to safely replace the existing proof-of-work consensus algorithm with the new proof-of-stake consensus represented by the already in-production beacon chain.\n\nThis EIP was designed to minimize the complexity of hot-swapping the live consensus of the Ethereum network. Both the safety of the operation and time to production were taken into consideration. Additionally, a minimal changeset helps ensure that most smart contracts and services will continue to function as intended during and after the transition with little to no required intervention.\n\n Total difficulty triggering the upgrade\n\nSee Security considerations.\n\n Parameterizing terminal block hash\n\nSee Security considerations.\n\n Halting the import of PoW blocks\n\nSee Security considerations.\n\n Replacing block fields with constants\n\nDeprecated block fields are replaced with constant values to ensure the block format remains backwards compatible. Preserving the block format aids existing smart contracts and services in providing uninterrupted service during and after this transition.\n\nParticularly, this is important for those smart contracts that verify Merkle proofs of transaction/receipt inclusion and state by validating the hash of externally provided block header against the corresponding value returned by the BLOCKHASH operation.\n\nThis change introduces an additional validity rule that enforces the replacement of deprecated block fields.\n\n Replacing difficulty with 0\n\nAfter deprecating the proof-of-work the notion of difficulty no longer exists and replacing the block header difficulty field with 0 constant is semantically sound.\n\n Changing block validity rules\n\nThe rule set enforcing the PoW seal validity is replaced with the corresponding PoS rules along with the consensus upgrade as the rationale behind this change.\n\nAn additional rule validating a set of deprecated block fields is required by the block format changes introduced by this specification.\n\n Removing block rewards\n\nExisting rewards for producing and sealing blocks are deprecated along with the PoW mechanism. The new PoS consensus becomes both responsible for sealing blocks and for issuing block rewards once this specification enters into effect.\n\n Supplanting fork choice rule\n\nThe fork choice rule of the PoW mechanism becomes completely irrelevant after the upgrade and is replaced with the corresponding rule of the new PoS consensus mechanism.\n\n Remove of POS_CONSENSUS_VALIDATED\n\nIn prior draft versions of this EIP, an additional POS event – POS_CONSENSUS_VALIDATED – was required as a validation condition for blocks. This event gave the signal to either fully incorporate or prune the block from the block tree.\n\nThis event was removed for two reasons:\n\n This event was an unnecessary optimization to allow for pruning of “bad” blocks from the block tree. This optimization was unnecessary because the PoS consensus would never send POS_FORKCHOICE_UPDATED for any such bad blocks or their descendants, and eventually any such blocks would be able to be pruned after a PoS finality event of an alternative branch in the block tree.\n This event was dangerous in some scenarios because a block could be referenced by two different and conflicting PoS branches. Thus for the same block in some scenarios, both a POS_CONSENSUS_VALIDATED == TRUE and POS_CONSENSUS_VALIDATED == FALSE event could sent, entirely negating the ability to safely perform the optimization in (1).\n\n EIP-2124 fork identifier\n\nThe value of FORK_NEXT in EIP-2124 refers to the block number of the next fork a given node knows about and 0 otherwise.\n\nThe number of TRANSITION_BLOCK cannot be known ahead of time given the dynamic nature of the transition trigger condition. As the block will not be known a priori, nodes can’t use its number for FORK_NEXT and in light of this fact an explicitly set FORK_NEXT_VALUE is used instead.\n\n Removing block gossip\n\nAfter the upgrade of the consensus mechanism only the beacon chain network will have enough information to validate a block. Thus, block gossip provided by the eth network protocol will become unsafe and is deprecated in favour of the block gossip existing in the beacon chain network.\n\nIt is recommended for the client software to not propagate descendants of any terminal PoW block to reduce the load on processing the P2P component and stop operating in the environment with unknown security properties.\n\n Restricting the length of extraData\n\nThe extraData field is defined as a maximum of 32 bytes in the yellow paper. Thus mainnet and most PoW testnets cap the value at 32 bytes. extraData fields of greater length are used by clique testnets and other networks to carry special signature/consensus schemes. This EIP restricts the length of extraData to 32 bytes because any network that is transitioning from another consensus mechanism to a beacon chain PoS consensus mechanism no longer needs extended or unbounded extraData.\n\n Backwards Compatibility\n\nThis EIP introduces backward incompatibilities in block validity, block rewards and fork choice rule.\n\nThe design of the consensus upgrade specified by this document does not introduce backward incompatibilities for existing applications and services built on top of Ethereum except for those that are described in the EVM section below or heavily depends on the PoW consensus in any other way.\n\n EVM\n\nAlthough this EIP does not introduce any explicit changes to the EVM there are a couple of places where it may affect the logic of existing smart contracts.\n\n DIFFICULTY\n\nDIFFICULTY operation will always return 0 after this EIP takes effect and deprecates the difficulty field by replacing it with 0 constant.\n\nNote: Altering the DIFFICULTY semantics to return randomness accumulated by the beacon chain is under consideration but will be introduced in a separate EIP.\n\n BLOCKHASH\n\nPseudo-random numbers obtained as the output of BLOCKHASH operation become more insecure after this EIP takes effect and the PoW mechanism (which decreases the malleability of block hashes) gets supplanted by PoS.\n\n Test Cases\n\n Block validity\n\n Beginning with TRANSITION_BLOCK, block is invalidated if any of the following is true:\n\n ommersHash != Keccak256(RLP([]))\n difficulty != 0\n nonce != 0x0000000000000000\n len(extraData) > MAX_EXTRA_DATA_BYTES\n\n Beginning with TRANSITION_BLOCK, block rewards aren’t added to beneficiary account\n\n Client software adheres to PoS LMD-GHOST rule\n\n Head and finalized blocks are set according to the recent POS_FORKCHOICE_UPDATED event\n No fork choice state is updated unless POS_FORKCHOICE_UPDATED event is received\n\n Transition process\n\n Client software doesn’t process any PoW block beyond a terminal PoW block\n Beginning with TRANSITION_BLOCK, client software applies new block validity rules\n Beginning with the first POS_FORKCHOICE_UPDATED, client software switches its fork choice rule to PoS LMD-GHOST\n TRANSITION_BLOCK must be a child of a terminal PoW block\n NewBlockHashes (0x01) and NewBlock (0x07) network messages are discarded after receiving the FIRST_FINALIZED_BLOCK\n\n Security Considerations\n\n Beacon chain\n\nSee Security Considerations section of EIP-2982.\n\n Transition process\n\nThe transition process used to take this specification into effect is a more sophisticated version of a hardfork – the regular procedure of applying backwards incompatible changes in the Ethereum network. This process has multiple successive steps instead of the normal block-height point condition of simpler hardforks.\n\nThe complexity of this upgrade process stems from this fork targeting the underlying consensus mechanism rather than the execution layer within the consensus mechanism. Although the design seeks simplicity where possible, safety and liveness considerations during this transition have been prioritized.\n\n Terminal total difficulty vs block number\n\nUsing a pre-defined block number for the hardfork is unsafe in this context due to the PoS fork choice taking priority during the transition.\n\nAn attacker may use a minority of hash power to build a malicious chain fork that would satisfy the block height requirement. Then the first PoS block may be maliciously proposed on top of the PoW block from this adversarial fork, becoming the head and subverting the security of the transition.\n\nTo protect the network from this attack scenario, difficulty accumulated by the chain (total difficulty) is used to trigger the upgrade.\n\n Ability to jump between terminal PoW blocks\n\nThere could be the case when a terminal PoW block is not observed by the majority of network participants due to (temporal) network partitioning. In such a case, this minority would switch their fork choice to the new rule provided by the PoS rooted on the minority terminal PoW block that they observed.\n\nThe transition process allows the network to re-org between forks with different terminal PoW blocks as long as (a) these blocks satisfy the terminal PoW block conditions and (b) the FIRST_FINALIZED_BLOCK has not yet been received. This provides resilience against adverse network conditions during the transition process and prevents irreparable forks/partitions.\n\n Halt the importing of PoW blocks\n\nSuppose the part of the client software that is connected to the beacon chain network goes offline before the Ethereum network reaches the TERMINAL_TOTAL_DIFFICULTY and stays offline while the network meets this threshold. Such an event makes the client software unable to switch to PoS and allows it to keep following the PoW chain if this chain is being built beyond the terminal PoW block. Depending on how long the beacon chain part was offline, it could result in different adverse effects such as:\n\n The client has no post-state for the terminal PoW block (the state has been pruned) which prevents it from doing the re-org to the PoS chain and leaving syncing from scratch as the only option to recover.\n An application, a user or a service uses the data from the wrong fork (PoW chain that is kept being built) which can cause security issues on their side.\n\nNot importing PoW blocks that are beyond the terminal PoW block prevents these adverse effects on safety/re-orgs in the event of software or configuration failures in favor of a liveness failure.\n\n Terminal PoW block overriding\n\nThere is a mechanism allowing for accelerating the consensus upgrade in emergency cases.\nThis EIP considers the following emergency case scenarios for the acceleration to come into effect:\n\n A drop of the network hashing rate which delays the upgrade significantly.\n Attacks on the PoW network before the upgrade.\n\nThe first case can be safely accelerated by updating the following parameters:\n\n TERMINAL_TOTAL_DIFFICULTY – reset to a value that is closer in time than the original one.\n FORK_NEXT_VALUE – adjust accordingly.\n\nThe second, more dire attack scenario requires a more invasive override:\n\n TERMINAL_BLOCK_HASH – set to the hash of a certain block to become the terminal PoW block.\n TERMINAL_BLOCK_NUMBER – set to the number of a block designated by TERMINAL_BLOCK_HASH.\n TERMINAL_TOTAL_DIFFICULTY – set to the total difficulty value of a block designated by TERMINAL_BLOCK_HASH.\n FORK_NEXT_VALUE – adjust accordingly.\n\nNote: Acceleration in the second case is considered for the most extreme of scenarios because it will result in a non-trivial liveness failure on Ethereum Mainnet.\n\n Ancient blocks are no longer a requisite for a network security\n\nKeeping historical blocks starting from genesis is essential in the PoW network. A header of every block that belongs to a particular chain is required to justify the validity of this chain with respect to the PoW seal.\n\nValidating the entire history of the chain is not required by the new PoS mechanism. Instead, the sync process in the PoS network relies on weak subjectivity checkpoints, which are historical snapshots shared by peers on the network. This means historical blocks beyond weak subjectivity checkpoint are no longer a requisite for determining the canonical blockchain.\n\nSpecification of weak subjectivity checkpoints can be found in the ethereum/consensus-specs repository.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin), \"EIP-3675: Upgrade consensus to Proof-of-Stake,\" Ethereum Improvement Proposals, no. 3675, July 2021. Available: https://eips.ethereum.org/EIPS/eip-3675.","tokens":5482,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259931218,"hash":"3fe4be5416eeb2d8a38b18a592c6fd8c767441bc"}
{"url":"https://docs.openzeppelin.com/monitor/1.3.x/architecture","domain":"docs.openzeppelin.com","title":"Architecture Guide | OpenZeppelin Docs","text":"MonitorArchitecture GuideOpen in ClaudeThis document describes the high-level architecture of OpenZeppelin Monitor, including the core components, their interactions, and the overall system design. It provides a technical overview of how the service processes blockchain data and triggers notifications based on configurable conditions.\nSystem Overview\nOpenZeppelin Monitor is organized as a data processing pipeline that spans from blockchain data collection to notification delivery. The system follows a modular architecture with distinct components for each step in the monitoring process, designed for scalability and extensibility.\nHigh-Level Architecture\nThe diagram below shows the core processing pipeline of OpenZeppelin Monitor, from blockchain networks and configuration through to notification channels:\n\nComponent Architecture\nThe system consists of several core services that are initialized at startup and work together to process blockchain data and trigger notifications. The service initialization and dependencies are managed through the bootstrap module.\nService Initialization Flow\n\nCore Components\nBlock Processing Components\n\nBlockWatcherService: Orchestrates the block monitoring process by polling blockchain networks for new blocks and coordinating the processing pipeline.\nBlockTracker: Tracks processed block numbers to prevent duplicate processing and ensure data consistency across service restarts.\nBlockStorage: Persists block processing state for recovery and maintains the last processed block number for each network.\n\nClient Layer Components\n\nClientPool: Manages blockchain client instances and provides network connectivity with connection pooling and failover capabilities.\nEVMClient: Handles communication with Ethereum Virtual Machine compatible networks (Ethereum, Polygon, BSC, etc.).\nStellarClient: Manages connections to Stellar blockchain networks with protocol-specific optimizations.\nSolanaClient: Manages connections to Solana blockchain networks with protocol-specific optimizations.\nMidnightClient: Manages connections to Midnight blockchain networks with WebSocket transport and Substrate-based architecture.\n\nProcessing Pipeline Components\n\nFilterService: Applies monitor filters to blockchain data, evaluating conditions and match expressions to identify relevant transactions and events.\nTriggerExecutionService: Executes triggers based on matched monitor conditions, evaluating trigger logic and preparing notification payloads.\nNotificationService: Delivers notifications through configured channels (Slack, Email, Discord, Telegram, Webhooks, Scripts).\n\nConfiguration Management Components\n\nMonitorService: Manages monitor configurations and provides access to active monitors with validation and lifecycle management.\nNetworkService: Manages network configurations and provides network details for client connections and monitoring operations.\nTriggerService: Manages trigger configurations and provides trigger details for notification execution.\n\nService Responsibilities\nThe following table describes the key responsibilities of each service in the OpenZeppelin Monitor architecture:\nServiceResponsibilityMonitorServiceManages monitor configurations and provides access to active monitorsNetworkServiceManages network configurations and provides network detailsTriggerServiceManages trigger configurations and provides trigger detailsFilterServiceFilters blockchain data based on monitor conditions and match expressionsTriggerExecutionServiceExecutes triggers based on matched monitor conditionsNotificationServiceDelivers notifications through configured channelsBlockWatcherServicePolls blockchain networks for new blocks and coordinates processingBlockTrackerTracks processed block numbers to prevent duplicate processingBlockStoragePersists block processing state for recoveryClientPoolManages blockchain client instances and provides network connectivity\nBlock Processing Workflow\nThe following runtime flow illustrates how data moves through the system, from blockchain networks to notification channels. This sequence represents the core monitoring loop that executes for each configured network.\n\nData Flow Architecture\n1. Block Discovery Phase\nThe BlockWatcherService initiates the monitoring cycle by:\n\nRetrieving the last processed block number from BlockStorage\nQuerying the blockchain for the latest block number\nCalculating the range of new blocks to process\n\n2. Data Retrieval Phase\nThe BlockchainClient fetches block data:\n\nConnects to the appropriate blockchain network via RPC\nRetrieves full block data including transactions and events\nHandles network-specific data formats and protocols\n\n3. Filtering Phase\nThe FilterService processes each block:\n\nApplies monitor-specific filters to transactions and events\nEvaluates match expressions and conditions\nIdentifies relevant data that matches monitoring criteria\n\n4. Trigger Evaluation Phase\nThe TriggerExecutionService processes matches:\n\nEvaluates trigger conditions for matched data\nPrepares notification payloads with relevant context\nDetermines which notification channels to activate\n\n5. Notification Delivery Phase\nThe NotificationService delivers alerts:\n\nFormats messages for each notification channel\nHandles channel-specific delivery protocols\nManages delivery retries and error handling\n\n6. State Persistence Phase\nThe BlockStorage updates processing state:\n\nRecords the latest processed block number\nEnsures data consistency for recovery scenarios\nMaintains processing history for debugging\n\nError Handling and Resilience\nThe architecture includes several resilience mechanisms:\n\nConnection Pooling: The ClientPool manages multiple connections to prevent single points of failure\nState Recovery: BlockStorage enables the service to resume from the last known good state after restarts\nRetry Logic: Notification delivery includes configurable retry mechanisms for transient failures\nGraceful Degradation: Individual component failures don’t cascade to the entire system\n\nFor detailed information about RPC logic and network communication, see the RPC section.\nConfiguration Architecture\nThe system uses a JSON-based configuration system organized into distinct categories:\nConfiguration Categories\n\nNetwork Configurations: Define blockchain network connections, RPC endpoints, and network parameters\nMonitor Configurations: Specify monitoring rules, conditions, and network/trigger references\nTrigger Configurations: Define notification settings and script definitions\nFilter Configurations: Contain match filter scripts for data filtering\n\nConfiguration Validation\nThe system implements comprehensive validation:\n\nCross-reference validation between monitors, networks, and triggers\nSchema validation for all configuration files\nRuntime validation of configuration references during service startup\n\nFor configuration examples and best practices, see the Configuration Guidelines section in the user documentation.\nExtensibility Points\nThe architecture is designed for extensibility in several key areas:\nBlockchain Support\n\nClient Layer: New blockchain protocols can be added by implementing the BlockchainClient trait\nTransport Layer: Protocol-specific transport clients handle network communication details\nFilter Layer: Chain-specific filters process protocol-dependent data formats\n\nNotification Channels\n\nChannel Plugins: New notification channels can be added by implementing the notification interface\nScript Support: Custom notification logic can be implemented using Python, JavaScript, or Bash scripts\n\nMonitoring Logic\n\nExpression Engine: Flexible expression evaluation for complex monitoring conditions\nScript Triggers: Custom trigger logic can be implemented using supported scripting languages\n\nPerformance Considerations\nThe architecture is optimized for:\n\nConcurrent Processing: Multiple networks can be monitored simultaneously\nEfficient Block Processing: Batch processing of blocks to minimize RPC calls\nMemory Management: Streaming processing of large blocks to prevent memory issues\nConnection Reuse: Client pooling reduces connection overhead\n\nSecurity Architecture\nThe system implements several security measures:\n\nSecure Protocols: Support for HTTPS/WSS\nSecret Management: Secure handling of API keys and sensitive configuration data\nInput Validation: Comprehensive validation of all external inputs and configurations\n\nRelated Documentation\nFor detailed information about the project structure, source code organization, and development resources, see the Project Structure guide.\nFor information about RPC logic and network communication, see the RPC section.\nFor configuration examples and best practices, see the Configuration Guidelines section in the user documentation.QuickstartPrevious PageProject StructureNext PageOn this pageSystem OverviewHigh-Level ArchitectureComponent ArchitectureService Initialization FlowCore ComponentsBlock Processing ComponentsClient Layer ComponentsProcessing Pipeline ComponentsConfiguration Management ComponentsService ResponsibilitiesBlock Processing WorkflowData Flow Architecture1. Block Discovery Phase2. Data Retrieval Phase3. Filtering Phase4. Trigger Evaluation Phase5. Notification Delivery Phase6. State Persistence PhaseError Handling and ResilienceConfiguration ArchitectureConfiguration CategoriesConfiguration ValidationExtensibility PointsBlockchain SupportNotification ChannelsMonitoring LogicPerformance ConsiderationsSecurity ArchitectureRelated Documentation","tokens":2371,"squid":"ink-security_audits","role":"Sentinel","at":1791259934189,"hash":"39384c6a4c1e8b967c74e809c19b335de877fb04"}
{"url":"https://ethereum.org/run-a-node/","domain":"ethereum.org","title":"How to Run an Ethereum Node | ⁦ethereum.org⁩","text":"What does it mean to \"run a node\"?Run software.Known as a 'client', this software downloads a copy of the Ethereum blockchain and verifies the validity of every block, then keeps it up-to-date with new blocks and transactions, and helps others download and update their own copies.With hardware.Ethereum is designed to run a node on average consumer-grade computers. You can use any personal computer, but most users opt to run their node on dedicated hardware to eliminate the performance impact on their machine and minimize node downtime.While online.Running an Ethereum node may sound complicated at first, but it's merely the act of continuously running client software on a computer while connected to the internet. While offline, your node will simply be inactive until it gets back online and catches up with the latest changes.Who should run a node?Everyone! Nodes are not just for validators. Anyone can run a node—you don't even need ETH.You don't need to ETH to run a node. In fact, it's every other node on Ethereum that holds validators accountable.You may not get the financial rewards that validators earn, but there are many other benefits of running a node for any Ethereum user to consider, including privacy, security, reduced reliance on third-party servers, censorship resistance and improved health and decentralization of the network.Having your own node means you don't need to trust information about the state of the network provided by a third party.Don't trust. Verify.Why run a node?When sending transactions using public nodes, personal information can be leaked to these third-party services such as your IP address and which Ethereum addresses you own.By pointing compatible wallets to your own node you can use your wallet to privately and securely interact with the blockchain.Also, if a malicious node distributes an invalid transaction, your node will simply disregard it. Every transaction is verified locally on your own machine, so you don't need to trust anyone.A 3rd-party node could choose to refuse transactions from specific IP addresses, or transactions that involve specific accounts, potentially blocking you from using the network when you need it. Having your own node to submit transactions to guarantees that you can broadcast your transaction to the rest of the peer-to-peer network at any time.By running a node you become part of a global movement to decentralize control and power over a world of information.If you're a holder, bring value to your ETH by supporting the health and decentralization of the network, and ensure you have a say in its future.Centralized cloud servers can provide a lot of computing power, but they provide a target for nation-states or attackers looking to disrupt the network.Network resilience is achieved with more nodes, in geographically diverse locations, operated by more people of diverse backgrounds. As more people run their own node, reliance on centralized points of failure diminishes, making the network stronger.In the event of a chain fork, where two chains emerge with two different sets of rules, running your own node guarantees your ability to choose which set of rules you support. It's up to you to upgrade to new rules and support proposed changes, or not.If you're staking ETH, running your own node allows you to choose your own client, to minimize your risk of slashing and to react to fluctuating demands of the network over time. Staking with a third party forfeits your vote on which client you think is the best choice.An Ethereum wallet allows you to take full custody and control of your digital assets by holding the private keys to your addresses, but those keys don't tell you the current state of the blockchain, such as your wallet balance.By default, Ethereum wallets typically reach out to a 3rd-party node, such as Infura or Alchemy, when looking up your balances. Running your own node allows you to have your own copy of the Ethereum blockchain.Getting startedIn the earlier days of the network, users needed to have the ability to interface with the command-line in order to operate an Ethereum node.If this is your preference, and you've got the skills, feel free to check out our technical docs.Spin up an Ethereum node Now we have DAppNode, which is free and open-source software that gives users an app-like experience while managing their node.In just a few taps you can have your node up and running.DAppNode makes it easy for users to run full nodes, as well as and other networks, with no need to touch the command-line. This makes it easier for everyone to participate and create a more decentralized network.Choose your adventureYou'll need some hardware to get started. Although running node software is possible on a personal computer, having a dedicated machine can greatly enhance the performance of your node while minimizing its impact on your primary computer.When selecting hardware, consider that the chain is continually growing, and maintenance will inevitably be needed. Increasing specs can help delay the need for node maintenance.Buy fully loadedOrder a plug and play option from vendors for the simplest onboarding experience.No building needed.App-like setup with a GUI.No command-line required.Shop DAppNode (opens in a new tab)Shop Avado (opens in a new tab)Build your ownA cheaper and more customizable option for slightly more technical users.Source your own parts.Install DAppNode.Or, choose your own OS and clients.Learn moreBuild your ownStep 1 – HardwareMinimum specs4 - 8 GB RAMSee note on stakingSee note on Raspberry Pi2 TB SSDSSD necessary for required write speeds.RecommendedIntel NUC, 7th gen or higherx86 processorWired internet connectionNot required, but provides easier setup and most consistent connectionDisplay screen and keyboardUnless you're using DAppNode, or ssh/headless setupStep 2 – SoftwareOption 1 – DAppNodeWhen you're ready with your hardware, the DAppNode operating system can be downloaded using any computer and installed onto a fresh SSD via a USB drive.DAppNode Setup (opens in a new tab)Option 2 – Command lineFor maximum control, experienced users may prefer using the command line instead.See our developer docs for more information on getting started with client selection.Command line setupFind some helpersOnline platforms such as Discord or Reddit are home to a large number of community builders willing to help you with any questions you may encounter.Don't go at it alone. If you have a question it's likely someone here can help you find an answer. Join the DAppNode Discord (opens in a new tab)Find online communitiesFurther readingMastering Ethereum - Should I Run a Full Node (opens in a new tab) - Andreas AntonopoulosEthereum on ARM - Quick Start Guide (opens in a new tab)The Limits to Blockchain Scalability (opens in a new tab) - Vitalik ButerinPlan on staking?To maximize the efficiency of your validator, a minimum of 16 GB RAM is recommended, but 32 GB is better, with a CPU benchmark score of 6667+ on cpubenchmark.net (opens in a new tab). It is also recommended that stakers have access to unlimited high-speed internet bandwidth, though this is not an absolute requirement.EthStaker goes into more detail in this hour long special - How to shop for Ethereum validator hardware (opens in a new tab)A note on Raspberry Pi (ARM processor)Raspberry Pis are lightweight and affordable computers, but they have limitations that may impact the performance of your node. Though not currently recommended for staking, these can be an excellent and inexpensive option for running a node for personal use, with as little as 4 - 8 GB of RAM.Ethereum on ARM documentation (opens in a new tab) - Learn how to set up a node via the command line on a Raspberry PiRun a node with Raspberry Pi - Follow along here if tutorials are your preferenceTest your Ethereum knowledgeRun a nodeQuestion number 1:How much ETH do you need to stake to run a node?","tokens":1988,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259934558,"hash":"ad9a53e2ab5144ae6e08b537dacbdbb426e7627c"}
{"url":"https://eips.ethereum.org/EIPS/eip-2982","domain":"eips.ethereum.org","title":"EIP-2982: Serenity Phase 0","text":"🎉 Final\n\n Informational\n\n EIP-2982: Serenity Phase 0\n\n Phase 0 of the release schedule of Serenity, a series of updates to Ethereum a scalable, proof-of-stake consensus\n\n Authors\n Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin)\n\n Created\n 2020-09-15\n\n Abstract\n\nThis EIP specifies Phase 0 of Serenity (eth2), a multi-phased upgrade to the consensus mechanism for Ethereum mainnet. In Phase 0, the existing PoW chain and mechanics are entirely unaffected, while a PoS chain – the beacon chain – is built in parallel to serve as the core of the upgraded consensus. In subsequent phases, the beacon chain is enhanced to support and secure the consensus of a number of parallel shard chains, ultimately incorporating current Ethereum mainnet as one of those shards.\n\nAt the core of the beacon chain is a proof of stake consensus mechanism called Casper the Friendly Finality Gadget (FFG) and a fork-choice rule called Latest Message Driven Greedy Heaviest Observed Sub-Tree (LMD-GHOST). Phase 0 is centered primarily around the mechanics and incentives of validators executing these algorithms. The detailed specifications for eth2 are contained in an independent repository from this EIP, and safety and liveness proofs can be found in the Combining GHOST and Casper paper. To avoid duplication, this EIP just references relevant spec files and releases.\n\nEarly phases of eth2 are executed without any breaking consensus changes on current Ethereum mainnet. This EIP serves to document the bootstrapping of this consensus mechanism and note the path for eth2 to supplant Ethereum’s current proof-of-work (PoW) consensus.\n\n Motivation\n\nEth2 aims to fulfill the original vision of Ethereum to support an efficient, global-scale, general-purpose transactional platform while retaining high cryptoeconomic security and decentralization.\n\nToday, Ethereum blocks are consistently full due to increasingly high demand for decentralized applications. Ever since the first serious spikes in adoption in 2017 (cryptokitties), the Ethereum community has consistently and vocally demanded scaling solutions.\n\nSince day 0 of Ethereum, the investigation and expectation in scaling solutions has been two-pronged – scale from both Layer 1 upgrades and Layer 2 adoption. This EIP represents the start to a multi-phased rollout of the former.\n\n Scaling through sharding\n\nAs the Ethereum network and the applications built upon it have seen increasing usage over the past 5 years, blocks have become regularly full and the gas price market continues to climb. Simple increases to the block gas-limit of the current Ethereum chain are unable to account for the increase in demand of the system without inducing an unsustainably high resource burden (in the form of bandwidth, computational, and disk resources) on consumer nodes. To retain decentralization while scaling up the Ethereum network, another path must be taken.\n\nTo provide more scale to Ethereum, while not inducing a restrictively high burden on both consumer and consensus nodes, eth2 introduces a “sharded” solution in which a number of blockchain shards – each of similar capacity to Ethereum mainnet today – run in parallel under a unified consensus mechanism. The core consensus (the beacon chain) and a small number of these shards can be processed via a single consumer machine, while the aggregate of the system provides much higher capacity.\n\n Decentralization and economic finality through proof-of-stake\n\nSince the early days of Ethereum, proof-of-stake has been a long-awaited desideratum for the following:\n\n Increased decentralization of the core consensus by lowering the barrier to entry and technical requirements of participation\n Increased cryptoeconomic security via in-protocol penalties for misbehaviour and the addition of economic finality\n Elimination of the energy hungry mining of the current PoW consensus mechanism\n\nIn addition to the above, PoS has synergies with the sharding scaling solution. Due to the random sampling requirement of sharding, PoS provides a more simple and direct access to the “active validator set” than PoW and thus allows for a more direct sharded protocol construction.\n\n Specification\n\nPhase 0 is designed to require no breaking consensus changes to existing Ethereum mainnet. Instead, this is the bootstrapping a new PoS consensus that can, once stable, supplant the current PoW consensus.\n\nPhase 0 specifications are maintained in a repository independent of this EIP. SPEC_RELEASE_VERSION release of the specs at SPEC_RELEASE_COMMIT are considered the canonical Phase 0 specs for this EIP.\n\nThis EIP provides a high level view on the Phase 0 mechanisms, especially those that are relevant to Ethereum mainnet (e.g. the deposit contract) and users (e.g. validator mechanics and eth2 issuance). The extended and low level details remain in the consensus-specs repository\n\n Parameters\n\n Parameter\n Value\n\n SPEC_RELEASE_VERSION\n v1.0.0\n\n SPEC_RELEASE_COMMIT\n 579da6d2dc734b269dbf67aa1004b54bb9449784\n\n DEPOSIT_CONTRACT_ADDRESS\n 0x00000000219ab540356cBB839Cbe05303d7705Fa\n\n MIN_GENESIS_TIME\n 1606824000\n\n BASE_REWARD_FACTOR\n 2**6 (64)\n\n INACTIVITY_PENALTY_QUOTIENT\n 2**26 (67,108,864)\n\n PROPORTIONAL_SLASHING_MULTIPLIER\n 1\n\n MIN_SLASHING_PENALTY_QUOTIENT\n 2**7 (128)\n\nNote: Eth2 has many more Phase 0 configuration parameters but the majority are left out of this EIP for brevity.\n\n Validator deposit contract\n\nIn Phase 0, eth2 uses a contract deployed on Ethereum mainnet – the Deposit Contract – at DEPOSIT_CONTRACT_ADDRESS to onboard validators into the PoS consensus of the beacon chain.\n\nTo participate in the PoS consensus, users submit validator deposits to the deposit contract. The beacon chain comes to consensus on the state of this contract and processes new validator deposits. This uni-directional deposit mechanism is the only technical link between the two components of the system (Ethereum mainnet and beacon chain) in Phase 0.\n\n Beacon chain and validator mechanics\n\nUsers who choose to participate in eth2 consensus deposit ETH collateral into the deposit contract in order to be inducted into the beacon chain validator set. From there, these validators are responsible for constructing the beacon chain (note that these consensus participants in PoS are akin to miners in PoW).\n\nThe beacon chain is a pure PoS chain that in Phase 0 is primarily concerned with maintaining its own consensus and managing the registry of validators. The consensus rules define roles (e.g. block proposal, block attesting) that validators are expected to participate in; validators who perform their roles well are rewarded, and validators who perform their roles poorly or are offline are penalized. Phase 0 does not yet include any ETH transfer, sharding or smart contract / VM execution capabilities.\n\nIn subsequent phases, additional mechanisms and validator responsibilities will be added to the beacon chain to manage the consensus of a number of parallel shard chains (“Phase 1”), to integrate the existing Ethereum system (“Phase 1.5”) and to add full support for sharded smart contract execution (“Phase 2”).\n\n Issuance\n\nTo incentivize validators to deposit ether collateral and participate in the eth2 consensus, we propose that rewards (in the form of Ethereum’s native asset, ether) be regularly issued to consensus participants. Due to the beacon chain operating in parallel to the existing PoW chain in early phases of eth2, this issuance is in addition to any PoW rewards until the existing chain is merged into eth2 as a shard.\n\nThe amount of ether issued to validators on the beacon chain is proportional to the square root of the total ether deposited. This issuance curve was chosen as a more stable and sustainable curve to the two obvious alternatives – fixed total issuance and fixed issuance per ether staked. For a more technical discussion on this choice see here.\n\nIn eth2, this curve is parameterized by BASE_REWARD_FACTOR in the context of slot time and epoch length. Below is the issuance curve as a function of ether staked, along with a table of examples for illustration. Note, all figures shown are annualized.\n\n Active Deposits\n Max Annual Validator Reward*\n Max Annual ETH Issued*\n\n 0.5M ETH\n 23.50%\n 117,527\n\n 1M ETH\n 16.60%\n 166,208\n\n 2M ETH\n 11.75%\n 235,052\n\n 4M ETH\n 8.31%\n 332,411\n\n 8M ETH\n 5.88%\n 470,104\n\n 16M ETH\n 4.16%\n 664,801\n\n 32M ETH\n 2.94%\n 940,167\n\n 64M ETH\n 2.08%\n 1,329,603\n\n 128M ETH\n 1.47%\n 1,880,334\n\n*Assuming validators are online 100% of the time and behaving optimally. Suboptimal validator behavior will lead to reduced rewards and/or penalties that reduce total issuance.\n\n Initial punitive parameters\n\nFor PoS protocols to be crypto-economically secure, in-protocol penalties are required. Small offline penalties incentivize validator liveness, whereas (potentially) much larger penalties provide protocol security in the event of tail-risk scenarios.\n\nSpecifically, the following significant penalties exist:\n\n Inactivity Leak: an offline penalty that increases each epoch is applied to validators during extended times of no finality (e.g. if one-third or more are offline or not on the canonical chain). This ensures the chain can eventually regain finality even under catastrophic conditions.\n Slashing: a penalty applied to validators that sign explicitly malicious messages that could lead to the construction and finalization of two conflicting chains (e.g. two blocks or attestations in the same slot). This penalty is designed to scale up in proportion to the number of slashable validators in the same time period such that if a critical number (wrt chain safety) of slashings have occurred, validators are maximally punished.\n\nFor the initial launch of Phase 0, the parameters defining the magnitude of these penalties – INACTIVITY_PENALTY_QUOTIENT, PROPORTIONAL_SLASHING_MULTIPLIER, and MIN_SLASHING_PENALTY_QUOTIENT – have been tuned to be less punitive than their final intended values. This provides a more forgiving environment for early validators and client software in an effort to encourage validation in this early, higher technical-risk stage.\n\nINACTIVITY_PENALTY_QUOTIENT is configured initially to four times its final value. This results in a slower inactivity leak during times of non-finality, which means the chain is less responsive to such an event. If there is an extended time of non-finality during the early months of eth2, it is far more likely to be due to technical issues with client software rather than some sort of global catastrophic event.\n\nPROPORTIONAL_SLASHING_MULTIPLIER is configured initially to one-third of its final value. This results in a lower accountable safety margin in the event of an attack. If any validators are slashed in the early months of eth2, it is far more likely to be the result of user mismanagement of keys and/or issues with client software than an organized attack.\n\nMIN_SLASHING_PENALTY_QUOTIENT configured initially to four times its final value. This results in a lower guaranteed minimum penalty for a slashable offense and thus reduces the baseline punitive incentive to keep an individual validator’s system secure. As with PROPORTIONAL_SLASHING_MULTIPLIER, slashings during the early months of eth2 are far more likely to be due to user mismanagement, or issues with client software, than an organized attack.\n\n Rationale\n\n Principles\n\n Simplicity: especially since cryptoeconomic proof of stake and quadratic sharding are inherently complex, the protocol should strive for maximum simplicity in its decisions as much as possible. This is important because it (i) minimizes development costs, (ii) reduces risk of unforeseen security issues, and (iii) allows protocol designers to more easily convince users that parameter choices are legitimate. When complexity is unavoidable to achieve a given level of functionality, the preference order for where the complexity goes is: layer 2 protocols > client implementations > protocol spec.\n Long-term stability: the low levels of the protocol should ideally be built so that there is no need to change them for a decade or longer, and any needed innovation can happen on higher levels (client implementations or layer 2 protocols).\n Sufficiency: it should be fundamentally possible to build as many classes of applications as possible on top of the protocol.\n Defense in depth: the protocol should continue to work as well as possible under a variety of possible security assumptions (eg. regarding network latency, fault count, the motivations of users)\n Full light-client verifiability: given some assumptions (eg. network latency, bounds on attacker budget, 1-of-N or few-of-N honest minority), a client verifying a small fixed amount of data (ideally just the beacon chain) should be able to gain indirect assurance that all of the data in the full system is available and valid, even under a 51% attack (note: this is a form of defense-in-depth but it’s important enough to be separate)\n\n The Layer 1 vs Layer 2 Tradeoff\n\nThe Ethereum roadmap uses a mixed layer 1 / layer 2 approach. We focus on serving a particular type of layer 2 (rollups) because it’s the only kind of layer 2 that both inherits the security of layer 1 and provides scaling of general-purpose applications. However, rollups come at a cost: they require some on-chain data per transaction, and so a blockchain with really high capacity rollups must be able to handle a still quite high amount of data bandwidth. So make this more feasible, we are implementing on scalable data layer technologies, particularly data availability sampling.\n\nThe reason to not take a pure layer 2 approach is that pure layer 2 scaling can only be done either with trust-based solutions (not desirable), or with channels or plasma (which have inherent limitations and cannot support the full EVM.\n\nThe reason to not take a pure layer 1 approach is to enable more room for experimentation in execution layers, and allow the base protocol to be simpler and have less intensive governance.\n\n Why proof of stake\n\nIn short:\n\n No need to consume large quantities of electricity in order to secure a blockchain (e.g. it’s estimated that both Bitcoin and Ethereum burn over $1 million worth of electricity and hardware costs per day as part of their consensus mechanism).\n Because of the lack of high electricity consumption, there is not as much need to issue as many new coins in order to motivate participants to keep participating in the network. It may theoretically even be possible to have negative net issuance, where a portion of transaction fees is “burned” and so the supply goes down over time.\n Proof of stake opens the door to a wider array of techniques that use game-theoretic mechanism design in order to better discourage centralized cartels from forming and, if they do form, from acting in ways that are harmful to the network (e.g. like selfish mining in proof of work).\n Reduced centralization risks, as economies of scale are much less of an issue. 10millionofcoinswillgetyouexactly10timeshigherreturnsthan1 million of coins, without any additional disproportionate gains because at the higher level you can afford better mass-production equipment, which is an advantage for Proof-of-Work.\n Ability to use economic penalties to make various forms of 51% attacks vastly more expensive to carry out than proof of work - to paraphrase Vlad Zamfir, “it’s as though your ASIC farm burned down if you participated in a 51% attack”.\n\n Why Casper\n\nThere are currently three major schools of proof of stake consensus algorithm:\n\n Nakamoto-inspired (Peercoin, NXT, Ouroboros…)\n PBFT-inspired (Tendermint, Casper FFG, Hotstuff…)\n CBC Casper\n\nWithin the latter two camps, there is also the question of whether and how to use security deposits and slashing (Nakamoto-inspired algorithms are incompatible with non-trivial slashing). All three are superior to proof of work, but we want to defend our own approach.\n\n Slashing\n\nEthereum 2.0 uses a slashing mechanism where a validator that is detected to have misbehaved can be penalized, in the best case ~1% but in the worst case up to its entire deposit.\n\nWe defend our use of slashing as follows:\n\n Raising the cost of attack: We want to be able to make a hard claim that a 51% attack on a proof of stake blockchain forces the attacker to incur a very large amount of expense (think: hundreds of millions of dollars worth of coins) that get burned, and any attack can be recovered from quickly. This makes the attack/defense calculus very unfavorable for attackers, and in fact makes attacks potentially counterproductive, because the disruption to service is outweighed by price gains to legitimate coin holders.\n Overcoming the validator’s dilemma: the most realistic immediate way for nodes to start to deviate from “honest” behavior is laziness (ie. not validating things that one should be validating, signing everything just in case, etc). See the validator’s dilemma paper (Luu et al., CC BY) for theoretical reasoning and the Bitcoin SPV mining fork for examples of this happening and leading to very harmful consequences in the wild. Having very large penalties for self-contradicting or for signing incorrect things helps to alleviate this.\n\nA more subtle instance of (2) can be seen as follows. In July 2019 a validator on Cosmos was slashed for signing two conflicting blocks. An investigation revealed that this happened because that validator was running a primary and a backup node (to ensure that one of the two going offline would not prevent them from getting rewards) and the two were accidentally turned on at the same time, leading to them contradicting each other.\n\nIf it became standard practice to have a primary and backup node, then an attacker could partition the network and get the primaries and the backups of all the validators to commit to different blocks, and thereby lead to two conflicting blocks being finalized. Slashing penalties help to heavily disincentivize this practice, reducing the risk of such a scenario taking place.\n\n Choice of consensus algorithm\n\nOnly the BFT-inspired and CBC schools of consensus algorithm have a notion of finality, where a block is confirmed in such a way that a large portion (1/3 in BFT-inspired, 1/4 in CBC) of validators would need to misbehave and get slashed for that block to get reverted in favor of some conflicting block; Nakamoto-inspired (ie. longest-chain-rule) consensus algorithms have no way of achieving finality in this sense.\n\nNote that finality requires a (super)majority of validators being online, but this is a requirement of the sharding mechanism already, as it requires 2/3 of a randomly sampled committee of validators to sign off on a crosslink for that crosslink to be accepted.\n\nOur choice of Casper FFG was simply a matter of it being the simplest algorithm available at the time that part of the protocol was being finalized. Details are still subject to long-term change; in particular, we are actively exploring solutions to achieve single slot finality.\n\n Sharding - or, why do we hate supernodes?\n\nThe main alternative to sharding for layer-1 scaling is the use of supernodes - simply requiring every consensus node to have a powerful server so that it can individually process every transaction. Supernode-based scaling is convenient because it is simple to implement: it works just the same way blockchains do now, except that more software-engineering work is required to build things in a way that is more parallelizable.\n\nOur main objections to this approach are as follows:\n\n Pool centralization risk: in a supernode-based system, running a node has a high fixed cost, so far fewer users can participate. This is usually rebutted with “well consensus in most PoW and PoS coins is dominated by 5-20 pools anyway, and the pools will be able to run nodes just fine”. However, this response ignores the risk of centralization pressure even between pools that can afford it. If the fixed cost of running a validator is significant relative to the returns, then larger pools will be able to offer smaller fees than smaller ones and this could lead to smaller pools being pushed out or feeling pressure to merge. In a sharded system, on the other hand, validators with more ETH need to verify more transactions, so costs are not fixed.\n AWS centralization risk: in a supernode-based system, home staking is infeasible and so it’s more likely that most staking will happen inside cloud computing environments, of which there are only a few options to choose from. This creates a single point of failure.\n Reduced censorship resistance: making it impossible to participate in consensus without high computation+bandwidth requirements makes detection and censorship of validators easier.\n Scalability: as transaction throughput increases, in a supernode-based system the above risks increase, whereas sharded systems can more easily handle the increased load.\n\nThese centralization risks are also why we are NOT attempting to achieve super-low-latency (<1s) of the blockchain, instead opting for (relatively!) conservative numbers.\n\nInstead, Ethereum is taking an approach where each validator is only assigned to process a small portion of all data. Only validators staking large amounts of ETH (think: tens of thousands or more) are required to process the entire data in the chain.\n\nNote that there is a possible middle-ground in sharding design where block production is centralized but (i) block verification is decentralized and (ii) there exist “bypass channels” where users can send transactions and block producers are forced to include them, so even a monopoly producer cannot censor. We are actively considering sharding designs that lean somewhat in this direction to increase simplicity so that scaling can be deployed faster, though if desired even within this spec it’s possible to run distributed builders and avoid centralization even there.\n\n Security models\n\nIt’s commonly assumed that blockchains depend on an “honest majority” assumption for their security: that >=50% of participants will faithfully follow a prescribed protocol, even forgoing opportunities to defect for their own personal interest. In reality, (i) an honest majority model is unrealistic, with participants being “lazy” and signing off on blocks without validating them (see the validator’s dilemma paper and the Bitcoin SPV mining fork) being a very common form of defection, but fortunately (ii) blockchains maintain many or all of their security properties under much harsher models, and it’s really important to preserve those extra guarantees.\n\nA common harsher model is the uncoordinated rational majority model, which states that participants act in their own self-interest, but no more than some percentage (eg. 23.21% in simple PoW chains) are cooperating with each other. An even harsher model is the worst-case model where there is a single actor that controls more than 50% of hashpower or stake, and the question becomes:\n\n Can we, even under that scenario, force the attacker to have to pay a very high cost to break the chain’s guarantees?\n What guarantees can we unconditionally preserve?\n\nSlashing in proof of stake chains accomplishes the first objective. In non-sharded chains, every node verifying every block accomplishes the second objective for two specific guarantees: (i) that the longest chain is valid, and (ii) that the longest chain is available.\n\nA major challenge in sharding is getting the same two properties without requiring each node to verify the full chain. Our defense-in-depth approach with sharding accomplishes just that. The core idea is to combine together random committee sampling, proof of custody, fraud proofs, data availability sampling (DAS) and eventually ZK-SNARKs, to allow clients to detect and reject invalid or unavailable chains without downloading and verifying all of the data, even if the invalid chains are supported by a majority of all proof of stake validators.\n\nCensorship of transactions can potentially be detected by clients in a consensus-preserving way, but this research has not yet been incorporated into the ethereum roadmap.\n\nHere is the current expected security properties expressed in a table:\n\n Network delay <3s\n Network delay 3s - 6 min\n Network delay > 6 min\n\n >2/3 validators honest\n Perfect operation\n Imperfect but acceptable operation. No rigorous proof of liveness, but liveness expected in practice.\n Likely intermittent liveness failures, no safety failures\n\n >2/3 validators rational, <1/3 coordinated\n Perfect operation\n Imperfect but acceptable operation, heightened centralization risk\n Likely intermittent liveness failures, no safety failures, very high centralization risk\n\n 51% attacker\n Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains\n Can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains\n Can revert finality or censor; cannot force through invalid or unavailable chains\n\n Why are the Casper incentives set the way they are?\n\n Base rewards\n\nDuring each epoch, every validator is expected to make an “attestation”, a signature that expresses that validator’s opinion on what the head of the chain is. There is a reward for having one’s attestation included, with four components (called “duties”):\n\n Reward for the attestation getting included at all\n Reward for the attestation specifying the correct epoch checkpoint\n Reward for the attestation specifying the correct chain head\n Reward for correctly participating in sync committee signatures\n\nNote also that mixed into these duties is a timeliness requirement: your attestation has to be included within a certain time to be eligible for the rewards, and for the “correct head” duty that time limit is 1 slot.\n\nFor each duty, the actual reward is computed as follows. If:\n\n R=B∗nomden equals the base reward multiplied by the fraction nomden that corresponds to that particular duty\n P is the portion of validators that did the desired action\n\nThen:\n\n Any validator that fulfilled the duty gets a reward of R∗P\n Any validator that did not fulfill the duty gets a penalty −R\n\nThe purpose of this “collective reward” scheme where “if anyone performs better, everyone performs better” is to bound griefing factors (see this paper for one description of griefing factors and why they are important).\n\nThe base reward B is itself calculated as k∗Di∑j=1nDj where D1…Dn are deposit sizes and k is a constant; this is a halfway compromise between two common models, (i) fixed reward rate, ie. k∗Di, and (ii) fixed total reward, ie. k∗Di∑j=1nDj.\n\nThe main argument against (i) is that it imposes too much uncertainty on the network of two kinds: uncertainty of the total level of issuance, and uncertainty of the total level of deposits (as if a fixed reward rate is set too low then almost no one will participate, threatening the network, and if a rate is set too high then very many validators will participate, leading to unexpectedly high issuance). The main argument against (ii) is greater vulnerability to discouragement attacks (again see the discouragement attacks paper). The inverse-square-root approach compromises between the two and avoids the worst consequences of each one.\n\nWhen an attestation gets a reward, the proposer gets a fraction of that reward. This is to encourage proposers to listen well for messages and accept as many as possible.\n\nNote also that the rewards are designed to be forgiving to validators who are offline often: being offline 1% of the time only sacrifices about 1.6% of your reward. This is also to promote decentralization: the goal of a decentralized system is to create a reliable whole out of unreliable parts, so we should not be trying to force each individual node to be extremely reliable.\n\n Inactivity leak\n\nIf the chain fails to finalize for tsf>4 epochs (tsf = “time since finality”), then a penalty is added so that the maximum possible reward is zero (validators performing imperfectly get penalized), and a second penalty component is added, proportional to tsf (that is, the longer the chain has not finalized, the higher the per-epoch penalty for being offline). This ensures that if more than 1/3 of validators drop off, validators that are not online get penalized much more heavily, and the total penalty goes up quadratically over time.\n\nThis has three consequences:\n\n Penalizes being offline much more heavily in the case where you being offline is actually preventing blocks from being finalized\n Serves the goals of being an anti-correlation penalty (see section below)\n Ensures that if more than 1/3 do go offline, eventually the portion online goes back up to 2/3 because of the declining deposits of the offline validators\n\nWith the current parametrization, if blocks stop being finalized, validators lose 1% of their deposits after 2.6 days, 10% after 8.4 days, and 50% after 21 days. This means for example that if 50% of validators drop offline, blocks will start finalizing again after 21 days.\n\n Slashing and anti-correlation penalties\n\nIf a validator is caught violating the Casper FFG slashing condition, they get penalized a portion of their deposit equal to three times the portion of validators that were penalized around the same time as them (specifically, between 18 days before they were penalized and roughly the time they withdrew). This is motivated by several goals:\n\n A validator misbehaving is only really bad for the network if they misbehave at the same time as many other validators, so it makes sense to punish them more in that case\n It heavily penalizes actual attacks, but applies very light penalties to single isolated failures that are likely to be honest mistakes\n It ensures that smaller validators take on less risk than larger validators (as in the normal case, a large validator would be the only one failing at the same time as themselves)\n It creates a disincentive against everyone joining the largest pool\n\n BLS Signatures\n\nBLS signatures are used because of their aggregation-friendliness: any two signatures S1 and S2 of a message M signed by keys k1 and k2 (corresponding pubkeys K1=G∗k1 and K2=G∗k2 where G is the generator of the elliptic curve) can simply be aggregated by elliptic curve point addition: S1+S2, which verifies against the public key K1+K2. This allows many thousands of signatures to be aggregated, with the marginal cost of one signature being one bit of data (to express that a particular public key is present in the aggregate signature) and one elliptic curve addition for computation.\n\nNote that BLS signatures of this form are vulnerable to rogue key attacks: if you see that other validators have already published public keys K1…Kn, then you can generate a private key r and publish a public key G∗r−K1−…−Kn. The aggregate public key would simply be G∗r, so you would be able to make a signature that verifies against the combined public key by yourself. The standard way to get around this is to require a proof of possession: basically, a signature of a message (that depends on the public key, and that would normally not be signed) that verifies against the public key by itself (ie. sign(message=H′(K),key=k) for privkey k and pubkey K, where H′ is a hash function). This ensures that you personally control the private key connected to the public key that you publish.\n\nWe use the signature of a deposit message (which specifies the signing key but also other important data such as the withdrawal key) as a proof of possession.\n\n Why 32 ETH validator sizes?\n\nAny BFT consensus algorithm with accountable fault tolerance (ie. if two conflicting blocks get finalized you can identify which 1/3 of nodes were responsible) must have all validators participate, and furthermore for technical reasons you need two rounds of every validator participating to finalize a message.\n\nThis leads to the decentralization / finality time / overhead tradeoff: if n is the number of validators in a network, f is the time to finalize a block, and ω is the overhead in messages per second, then we have:\n\n\\[\\omega \\ge \\frac{2 * n}{f}\\]\n\nFor example, if we are ok with an overhead of 10 messages per second, then a 10000-node network could only have a finality time of at least 2000 seconds (~33 minutes).\n\nIn Ethereum’s case, if we assume a total ETH supply of ≈227 ETH, then with 32 ETH deposit sizes, there are at most 222 validators (and that’s if everyone validates; in general we expect ~10x less ETH validating). With a finality time of 2 epochs (2 * 32 * 12 = 768 seconds), that implies a max overhead of 222768≈5461 messages per second. We can tolerate such high overhead due to BLS aggregation reducing the marginal size of each signature to 1 bit and the marginal verification complexity to one elliptic curve addition.\n\n32 slots is a safe minimum for another reason: if an attacker manipulates the randomness used for proposer selection, this number still provides enough space to ensure that there will be at least one honest proposer in each epoch, which is sufficient to ensure blocks keep finalizing. Our calculations suggest that current levels of overhead are acceptable, but higher levels would make running a node too difficult. Finally, the validator deposit size is ideal for shard crosslinking (see below).\n\n Random sampling\n\n Seed selection\n\nThe seed used for randomness is updated every block by “mixing in” (ie. seed <- xor(seed, new_data)) a value that must be revealed by the proposer of the block. Just like proof of custody subkeys, a validator’s values are all pre-determined once the validator has deposited, third parties cannot compute subkeys but can verify subkeys that are revealed voluntarily (this mechanism is sometimes called RANDAO).\n\nThis ensures that each proposer has one “bit of manipulation” over the seed: they can either make a block or not make a block. Not making a block is expensive in that the proposer misses out on many rewards. Furthermore, because the persistent and beacon committee sizes (see below) are large, manipulation of the randomness almost certainly cannot allow minority attackers to get 2/3 of any committee.\n\nIn the future we plan to use verifiable delay functions (VDFs) to further increase the random seeds’ robustness against manipulation.\n\n Shuffling\n\nWe use the swap-or-not shuffle described by Viet Tung Hoang, Ben Morris, and Phillip Rogaway to shuffle the validator set and assign responsibilities every epoch. This algorithm ensures that:\n\n As the shuffle is a permutation, each validator is assigned to be a member of exactly one committee during each epoch (keeping their load stable and reducing the chance manipulation of randomness can be profitable)\n As the shuffle is pointwise-evaluable in the forward direction, a validator can determine their own responsibilities in O(1) time\n As the shuffle is pointwise-evaluable in the reverse direction, the members of any specific committee or the proposer of any specific block can be computed in O(1) time\n\n Shuffling by slot\n\nThere are 32 slots in an epoch, and the validators responsible for attesting to each slot are chosen by shuffling. This ensures that attackers with a significant but still small portion of total stake cannot take over specific slots and cause short-range reorgs.\n\n Beacon committees\n\nThe committee for each slot is in turn split up into some number of beacon committees. Today (2022 Jan), this design does serve one useful function, allowing different subsets of attestations to get aggregated in separate subnets and thus making the p2p network more efficient. However, it does not serve any other useful consensus-related role.\n\nIn the original sharding design, the intention was that each beacon committee would be responsible for verifying a specific shard. However, this approach is likely deprecated if we switch to a single-proposer model. Hence, the more fine-grained beacon committees may well only be there vestigially and could eventually be removed or re-structured in a different way to focus on facilitating attestation aggregation.\n\n Sync committee\n\nA sync committee of 512 validators is selected once every ~27 hours to sign a block; this committee’s pubkeys are saved in an easily accessible list, allowing signatures to be easily verified by ultra-light clients.\n\n LMD GHOST fork choice rule\n\nThe beacon chain uses an LMD GHOST fork choice rule.\n\nThe LMD GHOST fork choice rule incorporates information from all validators, hundreds in each slot, making it extremely unlikely in the normal case that even a single block will be reverted. Because the fork choice is dependent on all validators, this also ensures that blocks cannot be reverted unless an attacker really does control close to 50% of the entire validator set; one cannot achieve a large advantage by manipulating the randomness.\n\n The proof of custody game\n\nFor each 9-day period, each validator has the ability to privately generate a “period subkey”. The validator’s public key uniquely determines their period subkey for every period, so once a validator has deposited they have no further freedom to choose what their subkeys are. No one can compute any given validator’s subkey except the validator themselves, but once a validator reveals a subkey voluntarily, anyone can verify its correctness (this is all done via BLS magic, and if quantum-safety is required in the future it can be done with hash-based commitments).\n\nWhen signing a block with data D with root R during period j, letting s being the period-j secret of that validator, a validator is required to compute a bitfield M as follows:\n\n Split D into 512-byte chunks D[0]…D[n−1]\n Set M to be the bitfield where the i’th bit is M[i]=mix(s,D[i])\n\nThey include get_chunk_bits_root(M) (this is called the custody bit) as part of what they are signing. mix and get_chunk_bits_root can both be viewed as hash-like functions that output a single bit (but are designed for multi-party-computation friendliness).\n\nIf a crosslink includes multiple blocks B1…Bn and the validator computes custody bits c1…cn for these blocks, then the validator signs all (Bi,ci,i) tuples and aggregates them. This unconventional self-aggregation is used to ensure that there are only 2n different messages (n different block/index pairs * 2 different bit values) being signed by different validators, reducing the number of pairings needed to verify the signatures.\n\nIf a validator publishes their period j subkey during or before period j, any other validator can publish a proof-of-knowledge of the subkey to the chain, which then penalizes the validator whose subkey was revealed. The proof of knowledge also proves which validator created it; this prevents block proposers from “stealing” the whistleblowing reward (once again all done via BLS magic, if quantum-safety is required in the future this can be done with STARKs). The goal of this is to make it dangerous to outsource computation of M.\n\nAfter a validator publishes their period j subkey, anyone else can check their work for any block that they signed. If they discover that a validator provided an incorrect custody bit, they can challenge this on-chain, and slash that validator. In general, random guessing (or any procedure that does not involve all of D) will only give a correct answer half the time, leading to a 50% risk of slashing per block signed.\n\nThe purpose of this mechanism is to mitigate the validator’s dilemma problem, where validators have an incentive to avoid verifying data out of laziness and piggyback on the assumption that all other validators are honest; if too many validators think in this way, it could lead to a tragedy of the commons leading to the chain accepting invalid blocks. With this scheme, if a validator attempts to commit to data that they did not personally process, then they would not be able to compute M, and so would lose the interactive challenge game.\n\n SSZ\n\nThe SimpleSerialize suite contains the following algorithms:\n\n A serialization algorithm\n A hashing algorithm (called SSZTreeHash or hash_tree_root)\n A generalized Merkle proof algorithm (called “SSZ partials”) that can handle proofs for multiple values and optimally deduplicates Merkle tree sister nodes in such cases.\n\nThe serialization algorithm has the following design goals:\n\n Simplicity (eg. no three clauses like RLP has for long / list encoding depending on item length)\n Being equivalent to simple concatenation in the case of entirely fixed-size objects\n Being usable as both a consensus-layer serialization algorithm and an application-layer ABI\n\nNote that the resulting SSZ serialization spec is very similar to the ethereum 1.0 ABI, with the major differences being (i) different basic data types and (ii) replacing the 32 byte length/position record size with a 4 byte size.\n\nThe hashing algorithm has the following design goals:\n\n Efficiency of computing the hash of an updated object, especially in the case where the object is very large and/or complex and the change is relatively small\n Efficiency (in terms of verification complexity and witness size) of proving the value of a specific field even in a large or complex object with a given hash\n\nThese requirements together make a Merkle tree structure the obvious choice.\n\n Generalized indices\n\nSee https://github.com/ethereum/eth2.0-specs/blob/dev/ssz/merkle-proofs.md for a description of generalized indices, and how they allow for very easy verification of Merkle proofs “poking into” arbitrary positions in an object by representing paths as an integer or bitfield.\n\n The validator lifecycle\n\n Depositing\n\nA validator deposits by sending a transaction that calls a function on the deposit contract on the eth1 chain (eventually, a way to deposit from inside eth2 will also be added). A deposit specifies:\n\n The public key corresponding to the private key that will be used to sign messages\n The withdrawal credentials (hash of the public key that will be used to withdraw funds once the validator is done validating)\n The deposit amount\n\nThese values are all signed by the signing key. The goal of having separate signing and withdrawal keys is to allow the more dangerous withdrawal key to be kept more securely (offline, not shared with any staking pools, etc) while the signing key is used to actively sign a message every epoch.\n\nThe deposit contract maintains a Merkle root of all deposits made so far. Once a merkle root containing the deposit gets included into the eth2 chains (via the Eth1Data voting mechanism), an eth2 block proposer can submit a Merkle proof of the deposit and start the deposit process.\n\n Activation\n\n The validator immediately joins the validator registry, but is at first inactive. The validator becomes active after N≥4 epochs; the minimum of 4 is there to ensure the RANDAO is not manipulable, and N may exceed 4 if too many validators try to join at the same time. If the active validator set has size $\n V\n ,amaximumofmax(4, \\frac{\n V\n }{65536})$ validators can join per epoch; if more validators try to join, they are put in a queue and processed as quickly as possible.\n\n Exiting\n\nWhen a validator exits (whether by publishing a voluntary exit message or being slashed), they are similarly put into an exit queue with the same maximum throughput.\n\n The reason for the entrance/exit queue limits is to ensure that the validator set cannot change too quickly between any two points in time, which ensures that finality guarantees still remain between two chains as long as a validator logs on often enough (once every ~1-2 months if $\n V\n \\ge 262144$). See here https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942 for rationale (and specifically why to use a rate limit instead of a fixed waiting time) and https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187 for how to calculate safety margin for a client that has been offline for some amount of time.\n\n Withdrawal\n\nOnce a validator leaves the exit queue, there is a ~27 hour period until they can withdraw. This period has several functions:\n\n It ensures that if a validator misbehaved there is a period of time within which the error can be caught and the validator can be slashed even if the exit queue is nearly empty.\n It provides time for the last period of shard rewards to be included.\n It provides time for proof of custody challenges to be made.\n\nIf a validator is slashed, a further delay of ~36 days is imposed. This further penalizes them (and forces them to hold the ETH; this makes the penalty somewhat larger for malicious validators that are trying to destroy the ethereum blockchain than those validators that want to support the platform but just made a mistake, as the former category would have to risk the exposure or pay for derivatives to cancel it out), but also allows for a period during which the number of other validators that got slashed can be calculated.\n\nIn phase 0, a “withdrawn” validator cannot actually withdraw to anywhere yet; the only distinction is that it is protected from validator penalties and does not have any responsibilities. In later phases, the ability to move funds from a withdrawn validator slot to an execution environment will be made available.\n\n Effective balances\n\nMost calculations based on a validator’s balance use the validator’s “effective balance”; the only exception is calculations that increase or decrease the validator’s balance. Only when the validators’s balance B falls below EB or goes above EB+1.5 is EB adjusted to equal floor(B). This is done to ensure that effective balance changes infrequently, reducing the amount of hashing needed to recompute the state every epoch; on average, only the balances need to all be updated, and the effective balances only get updated relatively rarely per validator. Balances are all stored in a dedicated vector, so 2∗N∗832=N2 hashes are needed to recompute a balance array, whereas effective balances are stored in validator record objects, where at least 5N hashes would be needed per validator to adjust the SSZ hash roots. Additionally, EB can be compressed more easily into a CompactValidator object, as it’s only one byte.\n\n Fork mechanism\n\nThe Fork data structure contains (i) the current “fork ID”, (ii) the previous fork ID and (iii) the switchover slot. The fork ID at the current height influences the valid signatures of all messages; hence, a message signed with one fork ID is invalid to a verification function using any other fork ID.\n\nA fork is done by adding a state transition at some “fork slot” n which sets the previous fork ID to the current fork ID, the current fork ID to a new value, and the switchover slot to n. Signature verification functions will verify messages using the fork ID at the slot the message is for, which could be the previous fork ID or the current one (eg. consider the case of attestations included after a delay; an attestation from before the fork slot could be included after the fork slot).\n\nIf any users do not want to join the fork, they can simply continue the chain that does not change the fork ID at the fork slot. The two chains would be able to proceed and validators would be free to validate on both without getting slashed.\n\n Backwards Compatibility\n\nAlthough this EIP does not introduce any immediate changes to the current Ethereum mainnet, this EIP lays the groundwork for future backwards incompatibilities through the introduction of the new eth2 consensus mechanism in which Ethereum will be integrated in subsequent phases. To secure this mechanism, users move ether into the beacon chain and additional ether is issued. This EIP is a commitment to this path being canonical, as well as directly informing the future and roadmap of Ethereum mainnet.\n\n Security Considerations\n\nEth2 is a major overhaul of the Ethereum’s core consensus from PoW to a sharded PoS. There are inherent risks in this migration but there is extensive research literature analyzing security and trade-offs. The following only represents a high level selection of the resources available:\n\n Casper FFG\n Combining GHOST and Casper\n\nIn addition to the research supporting this path, a number of audits and formal verification of specs, cryptography, and client implementations have been performed. Many client and utility library audits are currently in progress and will be appended here upon completion.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Danny Ryan (@djrtwo), Vitalik Buterin (@vbuterin), \"EIP-2982: Serenity Phase 0,\" Ethereum Improvement Proposals, no. 2982, September 2020. Available: https://eips.ethereum.org/EIPS/eip-2982.","tokens":12197,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791259941285,"hash":"fdc49a186fc4ef0eb8eb53e41e0078dc06c2bfcc"}
{"url":"https://ethereum.org/developers/tools/categories/education-standards/","domain":"ethereum.org","title":"Education & standards | Developer builder resources | ⁦ethereum.org⁩","text":"EDUCATION & STANDARDSResources found: 15 / 15Education & standards(15)Courses & tutorials(12)WTF SolidityWTF Solidity is a free open-source Solidity course running from basics to advanced topics, with runnable code examples in Chinese and English. Beginners work through it to learn Solidity by editing and running each example.The EthernautThe Ethernaut is OpenZeppelin's browser capture-the-flag: each level is a broken contract you exploit to learn common Solidity vulnerabilities hands-on.SpeedrunEthereumSpeedrun Ethereum is a hands-on series of challenges designed to help you learn by building. Each challenge delivers one key \"aha\" moment, a mental unlock about how Ethereum really works. At the same time, you'll be building your Ethereum portfolio.Damn Vulnerable DeFiDamn Vulnerable DeFi is a hands-on Ethereum security training environment featuring realistic Solidity and DeFi exploitation challenges.Alchemy UniversityAlchemy University offers tutorials and guided learning content for Ethereum developers, including smart contract and web3 app development.Building Secure ContractsBuilding Secure Contracts is Trail of Bits' collection of guidelines, checklists, and training material for writing and reviewing Solidity contracts. Solidity developers work through its exercises and program analysis tutorials while building and reviewing code.Solidity by ExampleSolidity by Example is a collection of short annotated Solidity snippets organized by language feature and pattern. Builders look things up there while writing contracts.RareSkillsRareSkills is an Ethereum and smart contract education platform with structured courses, bootcamps, and in-depth developer learning content.UpdraftUpdraft is Cyfrin's free, hands-on curriculum for Solidity, security, Foundry, and DeFi: use it when you want structured exercises and certifications before shipping high-risk contracts.Solidity Testing HandbookSolidity Testing Handbook is a comprehensive guide to testing smart contracts in the Solidity programming language. It covers the basics of testing, the different types of tests, and the tools available for testing.BuidlGuidl CTFBuidlGuidl CTF is a Solidity challenge platform where developers solve practical Ethereum security and smart contract puzzles.AcademyTraining, incubation, and acceleration programs for non-tech people and devs to start in the web3 privacy ecosystem.Standards & specifications(3)OpenRPCOpenRPC is JSON-RPC schema tooling and generators in the spirit of OpenAPI: you describe RPC surfaces once, then ship typed clients, docs, and tests for Ethereum and L2 JSON-RPC stacks.evm codesevm.codes is an interactive reference for EVM opcodes where each instruction can be inspected and run. Builders use it to learn what an opcode does and to experiment with short sequences of instructions.EIP.ToolsEIP.Tools is a browser explorer for EIPs, ERCs, RIPs, and CAIPs with search, summaries, trending views, and a relationship graph when you need to skim how standards connect.Suggest a resourceKnow a great builder resource that should be listed? Open an issue and share it with us.Suggest a resource (opens in a new tab)","tokens":788,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791259944487,"hash":"8c55ebc74b52c3be11ad19f635206bfb538f78b3"}
{"url":"https://docs.openzeppelin.com/monitor/1.3.x/project-structure","domain":"docs.openzeppelin.com","title":"Project Structure | OpenZeppelin Docs","text":"MonitorProject StructureOpen in ClaudeThis document describes the project structure and organization of the OpenZeppelin Monitor codebase, including the source code layout, configuration files, and development resources.\nProject Layout\nThe project follows a standard Rust project layout with additional directories for configuration, documentation, and operational resources:\nopenzeppelin-monitor/\n├── src/ # Source code\n│ ├── bootstrap/ # Bootstrap functions for the application\n│ ├── models/ # Data structures and types\n│ ├── repositories/ # Configuration storage\n│ ├── services/ # Core business logic\n│ ├── utils/ # Helper functions\n│\n├── config/ # Configuration files\n├── tests/ # Integration and property-based tests\n├── data/ # Runtime data storage\n├── docs/ # Documentation\n├── scripts/ # Utility scripts\n├── cmd/ # Metrics and monitoring\n├── examples/ # Example configuration files\n└── ... other root files (Cargo.toml, README.md, etc.)\nSource Code Organization\nsrc/ Directory\nThe main source code directory contains the core implementation files organized into several modules:\nbootstrap/\nApplication initialization and setup for main.rs:\n\nHandles service initialization and dependency injection\nManages the startup sequence and service lifecycle\n\nmodels/\nCore data structures and types:\n\nblockchain/: Platform-specific implementations\n\nevm/: Ethereum Virtual Machine specific types\nstellar/: Stellar blockchain specific types\nsolana/: Solana blockchain specific types\nmidnight/: Midnight blockchain specific types\n\nconfig/: Configuration loading and validation\ncore/: Core domain models\nsecurity/: Security and secret management\n\nrepositories/\nConfiguration storage:\n\nHandles loading and validating configuration files\nProvides storage interfaces for monitors, networks, and triggers\nImplements validation of configuration references\n\nservices/\nCore business logic:\n\nblockchain/: Blockchain client interfaces\n\ntransports/: Transport clients\n\nevm/: Ethereum Virtual Machine transport client\nstellar/: Stellar transport client\nsolana/: Solana transport client\nmidnight/: Midnight transport client\n\nclients/: Client implementations\n\nevm/: Ethereum Virtual Machine client\nstellar/: Stellar client\nsolana/: Solana client\nmidnight/: Midnight client\n\nblockwatcher/: Block monitoring and processing\nfilter/: Transaction and event filtering\n\nfilters/: Filter implementations\n\nevm/: Ethereum Virtual Machine filter\nstellar/: Stellar filter\nsolana/: Solana filter\nmidnight/: Midnight filter\n\nnotification/: Alert handling\ntrigger/: Trigger evaluation and execution\n\nscript/: Script execution utilities\n\nutils/\nHelper functions:\n\ncron_utils: Cron schedule utilities\nexpression: Expression evaluation\nlogging/: Logging utilities\nmacros/: Macros for common functionality\nmetrics/: Metrics utilities\nmonitor/: Monitor configuration test utilities\ntests/: Contains test utilities and helper functions\n\nbuilders/: Test builder patterns implementing fluent interfaces for creating test fixtures\n\nevm/: Builder implementations specific to Ethereum Virtual Machine (EVM) testing\nstellar/: Builder implementations specific to Stellar blockchain testing\nsolana/: Builder implementations specific to Solana blockchain testing\nmidnight/: Builder implementations specific to Midnight blockchain testing\n\nConfiguration and Data\nconfig/ Directory\nContains JSON configuration files for:\n\nNetwork configurations (networks/)\n\nConnection details for blockchain networks\nRPC endpoints and network parameters\n\nMonitor configurations (monitors/)\n\nMonitoring rules and conditions\nNetwork and trigger references\n\nTrigger configurations (triggers/)\n\nNotification settings\nScript definitions\n\nFilter configurations (filters/)\n\nMatch filter scripts\n\nThe examples/config/ directory contains example JSON configuration files for each (network, monitor, trigger and filters).\ndata/ Directory\nRuntime data storage:\n\nBlock processing state\nOperational data\nTemporary files\n\nThe data/, logs/ and config/ directories are gitignored except for example files. These directories are mounted to persist the configs and runtime data.\nExamples and Resources\nexamples/ Directory\nProvides practical examples and sample configurations to help users get started:\n\nDemonstrates typical service configurations for various networks\nActs as a quick-start guide for customizing the monitor\nServes as a reference for best practices in configuration\n\nMetrics and Monitoring\ncmd/prometheus/ Directory\nPrometheus exporters and monitoring infrastructure:\n\ndashboards/: Grafana dashboards\ndatasources/: Prometheus datasources\nprometheus.yml: Prometheus configuration\ngrafana.ini: Grafana configuration\n\nTesting and Documentation\ntests/ Directory\nContains comprehensive test suites:\n\nIntegration tests\nProperty-based tests\nMock implementations\nTest utilities and helpers\n\ndocs/ Directory\nProject documentation:\n\nUser guides\nAPI documentation\nConfiguration examples\nArchitecture diagrams\n\nscripts/ Directory\nUtility scripts for:\n\nDevelopment workflows\nDocumentation generation\nBuild processes\nDeployment helpers\n\nDevelopment Tools\nPre-commit Hooks\nLocated in the project root:\n\nCode formatting checks\nLinting rules\nCommit message validation\n\nBuild Configuration\nCore build files:\n\nCargo.toml: Project dependencies and metadata\nrustfmt.toml: Code formatting rules\nrust-toolchain.toml: Rust version and components\n\nDocker Support\nThe project includes Docker configurations for different environments:\n\nDockerfile.development: Development container setup\nDockerfile.production: Production-ready container\nBefore running the docker compose set your env variables in .env according to your needs\n\nFor detailed information about running the monitor in containers, see the Docker deployment section in the user documentation.Architecture GuidePrevious PageRPC ClientNext PageOn this pageProject LayoutSource Code Organizationsrc/ Directorybootstrap/models/repositories/services/utils/Configuration and Dataconfig/ Directorydata/ DirectoryExamples and Resourcesexamples/ DirectoryMetrics and Monitoringcmd/prometheus/ DirectoryTesting and Documentationtests/ Directorydocs/ Directoryscripts/ DirectoryDevelopment ToolsPre-commit HooksBuild ConfigurationDocker Support","tokens":1550,"squid":"ink-security_audits","role":"Sentinel","at":1791259944539,"hash":"ead8641fb5fccc1da2939380b4838378dc24b286"}
{"url":"https://dev-forum.pyth.network/c/general/4","domain":"dev-forum.pyth.network","title":"Latest General topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in General\n\n General\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Welcome to Pyth Developer Forum! \n\n We are so glad you joined us. \n\nPyth Developer Forum\nWelcome to Pyth Dev Community — the official forum for Pyth’s Technical Support, Product Updates, and Community Discussion. Whether you’re looking for help, exploring …\n\n read more\n\n 0\n\n 577\n\n Mar 2025\n\n About the General category\n\n Topics that don’t need a category, or don’t fit into any other existing category.\n\n 0\n\n 454\n\n Mar 2025\n\n Powered by Discourse","tokens":1022,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259957408,"hash":"f9ea7f4ef71b1f3db4cbd73a100e4ed297f5ea36"}
{"url":"https://io.net/docs/guides/clouds/run-jobs-on-clusters","domain":"io.net","title":"Overview - io.net","text":"Machine learning (ML) has revolutionized various fields by enabling data-driven decision-making and automating complex tasks. As ML models become more sophisticated, the computational power required to train and deploy these models increases significantly. Running machine learning jobs on clusters, which consist of interconnected computers working together, has become a critical approach to meet these demands. This document provides an overview of the benefits, setup, and best practices for running machine learning jobs on clusters, ensuring efficient and scalable ML workflows.\n​Benefits of Running ML Jobs on Clusters\n\nEnhanced Computational Power Clusters aggregate the computational resources of multiple machines, providing the necessary power to handle large-scale ML tasks. This enables the training of complex models on vast datasets that would be infeasible on a single machine.\nScalability Clusters offer the ability to scale resources up or down based on the needs of the ML job. This flexibility allows for efficient resource management and cost optimization, ensuring that resources are allocated appropriately for different stages of the ML workflow.\nParallel Processing By distributing tasks across multiple nodes in a cluster, ML jobs can be executed in parallel, significantly reducing the time required for training and inference. This parallelism is crucial for handling the iterative and computationally intensive nature of ML algorithms.\nFault Tolerance and Reliability Clusters are designed with fault tolerance in mind. In the event of hardware failure or other issues, the workload can be redistributed among other nodes, minimizing downtime and ensuring the reliability of ML job execution.\nWas this page helpful?","tokens":436,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259963975,"hash":"a90d5c7f2c6502b8f40823c333395b9ddc8b5001"}
{"url":"https://gov.optimism.io/t/upgrade-19b-karst-hardfork/10713","domain":"gov.optimism.io","title":"Upgrade 19b — Karst Hardfork - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Upgrade 19b — Karst Hardfork \n\n Proposals 📃Technical Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 6\n min\n\n Jun 15\n\n 1 / 4\n\n Jun 15\n\n Jun 18\n\n post by soyboy on Jun 15\n\n soyboy\n\n Proposal Type: Protocol Upgrade\nVoting Cycle Type: off-cycle\nHi, I’m Matthew Cruz, Engineering Manager of the Solutions team at OP Labs. I have reviewed this proposal with: Josh Klopfenstein, Paul Dowman, and Andrea Federici from the OP Labs Team. OP Labs and the named individuals herein do not represent or speak on behalf of the Optimism Foundation.\nExecutive Summary\nUpgrade 19 bundles six protocol changes that advance L2 upgradeability, align the OP Stack execution layer with Ethereum’s Fusaka hardfork, promote the Rust kona-client to primary fault proof, and lay groundwork for interop. The L2 hardfork shipped in this upgrade is named Karst.\nKarst (L2 hardfork) — execution-layer changes:\n\nOsaka on L2 — adoption of 7 EIPs from Ethereum’s Fusaka: EIP-7642, EIP-7823, EIP-7825, EIP-7883, EIP-7910, EIP-7939, EIP-7951.\nGlamsterdam Defense: BN256 pairing input size reduction — bn256Pairing precompile maximum input reduced from Jovian’s 81,984 bytes (427 pairs) to 57,600 bytes (300 pairs) to restore Jovian-era headroom under EIP-7825’s transaction gas cap, accommodating a potential EIP-7904’s pairing cost increase on L1.\n\nBeyond Karst, Upgrade 19 also bundles four contracts and fault proof related changes:\n\nL2 Contract Manager (L2CM) — deterministic L2-predeploy upgrade mechanism via ProxyAdmin.upgradePredeploys().\nOPCMv2 adoption — redesigned OP Contracts Manager v2, replacing OPCM v1’s five functions with two unified deploy() / upgrade() calls.\nCANNON_KONA as respected game type + new Kona absolute prestate — the Rust-based kona-client on the Cannon VM (deployed as a fallback in U18) becomes the primary fault proof program for withdrawals, with a new absolute prestate. Permissionless fault proof chains flip their respected game type from CANNON to CANNON_KONA.\nPortal rootClaim / rootClaimByChainId dispatch by game type — in preparation for interop’s SuperDisputeGame, the OptimismPortal detects the game type and calls either rootClaim() or rootClaimByChainId(). The SuperDisputeGame branch is dormant in U19 but the dispatch logic ships now so the portal is ready for the next interop-bearing upgrade.\n\nThis upgrade also marks the end of support for op-geth and op-program see this notice page for more details.\nMotivation\nL2 contract upgrades have historically been one of the more brittle parts of the OP Stack’s release process. L2CM addresses this directly by making upgrade transactions “100% deterministic with a clear, immutable record of the exact transactions and bytecode executed.”\nOP Contract Manager v2 modernizes the operational tooling used to execute the upgrade itself. The OPCMv2 is an accumulation of learnings and recent changes to the protocol, particularly around dispute game types, and have exposed significant pain points in OPCM v1. Inspiring the consolidation into two unified entry points and the move to dynamic game-type handling.\nOsaka on L2 keeps the OP Stack execution layer aligned with L1, preserving the strict equivalence that lets developers reason about gas costs, precompiles, and opcodes consistently across both layers.\nThe kona-client promotion to primary fault proof and the BN256 input reduction are paired safety measures. Promoting kona-client was driven by the end of support for op-geth/op-program and to consolidate around a Rust implementation of the OP Stack; the BN256 reduction preserves headroom in fault proof transaction sizes so that anticipated L1 precompile cost increases under Glamsterdam’s EIP-7904 cannot push proofs past the maximum transaction size.\nThe Portal rootClaim / rootClaimByChainId dispatch is small but forward-looking — it prepares the OptimismPortal for the next interop-bearing upgrade without requiring a re-touch of the portal at that time.\nImpacted Stakeholders and Expected Outcomes\n\nApp developers:\n\nEIP-7825 transaction gas limit (Osaka on L2): L2 transactions are now subject to a per-transaction gas limit of 2^24 = 16,777,216 gas. If your application submits transactions with very high gas limits, verify they remain within the new threshold. Deposit transactions are exempt. Most applications will not be affected.\nMODEXP gas changes (EIP-7883 + EIP-7823, Osaka on L2): the gas cost floor for MODEXP (0x05) increases, and a new input size cap (1024-byte modulus) is enforced. If your contracts call MODEXP, update your gas estimates and verify inputs are within the new size limit.\nP256VERIFY gas change (EIP-7951, Osaka on L2): the gas cost for P256VERIFY (0x100) increases from 3,450 to 6,900 gas. If your contracts call P256VERIFY, update your gas estimates.\nCLZ opcode (EIP-7939, Osaka on L2): a new Count Leading Zeros opcode (0x1e) is available. Existing contracts are not affected.\nBN256 pairing input size limit (Glamsterdam Defense): the maximum input for ecPairing (0x08) is reduced from 427 to 300 pairs (57,600 bytes). If your contracts call the BN256 pairing precompile with more than 300 pairs, those calls will fail. Standard ZK proof verification (e.g., Groth16) is not affected.\nWithdrawal proving: the respected game type on permissionless chains changes from CANNON (0) to CANNON_KONA (8). Standard SDK usage handles this automatically.\n\nNode operators: op-geth and op-program are no longer supported. Operators must migrate to op-reth and kona-client before Karst activation. (notice page)\nChain operators: New component versions are required for op-node, op-reth, op-challenger, op-dispute-mon, and op-contracts. The contracts pre-audit release is op-contracts/v7.0.0-rc.4. Required component versions (must be updated before the activation timestamp). We have information on which components are necessary in our notice page here.\n\nSpecifications\nBlockspace Charter\nThis Protocol Upgrade is scoped to the Standard Rollup Charter. These changes will be made to the charter as a part of this upgrade, and the new prestates have been added to standard prestates TOML in accordance to the existing Standard Rollup Charter.\nTechnical Details\nL2 Contract Manager (L2CM)\n\nDesign Doc\nSpecs\n\nspecs/protocol/l2-upgrades-1-execution.md\nspecs/protocol/l2-upgrades-2-contracts.md\n\nFailure Modes Analysis\n\nOsaka on L2\n\nSpecs:\n\nspecs/protocol/karst/overview.md — Karst upgrade overview; lists all 7 activated EIPs\nspecs/protocol/karst/exec-engine.md — BN256 pairing input size reduction\nspecs/protocol/karst/derivation.md — L2CM network upgrade transactions during derivation\n\nFailure Mode Analysis\n\nGlamsterdam Defense (BN256 pairing input size reduction)\n\nImplementation\n\nOPCMv2 adoption\n\nDesign Doc\nSpecs\n\nspecs/experimental/contracts/L1/opcm.md\n\nFailure Modes Analysis\n\nContract Changesx\nThe contract changes can be found at this contract release tag: op-contracts/v7.0.0-rc.4, which will be finalized as op-contracts/v7.0.0 after this upgrade is approved by governance.\nThe canonical OPCMv2 address on Ethereum Mainnet is 0x9ce712ff84e02659846dc6450bb9b7642fe8be5d (version 7.1.17; superchain-registry). Chains must be deployed or upgraded via this address to satisfy the Standard Rollup Charter version criteria. A full diff from the previous upgrade can be seen here.\nAbsolute Prestate\nThis upgrade includes the absolute presate for kona-proof:\n\nkona-clientv1.6.0-rc.2: The absolute prestate hash (cannon64-kona variant) is 0x0337ecb3604c0b40c352e0c7711beb17a212d583f4fe956fd8d66e29ad5f9025. It has been publicly verified here.\n\nCalldata\nThe expected calldata to sign on for a bundled OP, Ink, Mode, Metal, Zora, and Soneium and the seperate Unichain will be commented below (because of a post character limit). This also includes the upgrade on OP Mainnet, Ink, Metal, Mode, and Zora Mainnets as these networks will be upgraded in one superchain-ops task. The Unichain Mainnet calldata will also be posted in a comment below because of the same character limit.\nImpact Summary\n\nPerformance: No anticipated downtime.\nWithdrawal proofs: The CANNON_KONA primary fault proof transition after the smart contract upgrade is executed.\nUpgrade documentation: Upgrade 19 notice page covers the operator-facing details, including the op-geth/op-program end of support details.\nOther: None beyond the per-stakeholder items above.\n\nPrecommitment Impact Review\nThis Upgrade Proposal does not impact any of the precommitments in the Standard Rollup Charter.\n\nCollective Fee Take: no modification or onchain implementation introduced.\nGovernor/Servicer Role Separation: no change to role structures or authorization patterns.\nOssified GasLimits: no change\nDirect Fee Margin Controls: no change to the relevant configuration structure and authorization.\n\nSecurity Considerations\nWe have done threat modelling for the new features in this release. The Upgrade 19 audit is a combined audit of the full contracts diff since the last release (op-contracts/v6.0.0).\nAction Plan\n\nAlphanet and Betanet testing has been completed.\nSepolia activation: Wed, Jun 17, 2026 at 16:00:01 UTC (timestamp 1781712001). Chains: OP, Soneium, Ink, Unichain, Mode, Metal, and Zora. Smart contract upgrade will happen prior to activation.\nMainnet smart contract upgrade: expected the week of Jul 1, 2026 (week prior to L2 activation).\nMainnet L2 activation: Wed, Jul 8, 2026 at 16:00:01 UTC (timestamp 1783526401), pending Optimism Governance approval. Chains: OP, Soneium, Ink, Unichain, Mode, Metal, and Zora. Smart contract upgrade will happen prior to activation.\n\nCommunication and education plan: The Upgrade 19 notice page is published with necessary information for application developers, chain operators, and node operators to be ready.\nConclusion\nUpgrade 19 advances the following goals. L2CM and OPCMv2 make protocol upgrades themselves more deterministic and auditable. Osaka on L2 preserves equivalence with the EVM. The CANNON_KONA promotion as the new respected game type for permissionless fault proof chains. The BN256 reduction takes proactive measures to harden the fault proof system ahead of the Glamsterdam L1 hardfork. This marks the explicit end of support for op-geth and op-program in favor of op-reth and kona-client.\n\n PGov - Delegate Communication Thread\n\n 3\n\n read \n\n 6\n min\n\n post by soyboy on Jun 15\n\n post by MconnectDAO on Jun 15\n\n post by soyboy on Jun 18\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon\n\n Protocol Upgrade\n\n Proposal Type: Protocol Upgrade\nHi, I’m Kelvin, the technical lead on the OP Labs EVM Safety team. I will be acting as the primary point of contact for technical questions related to this proposal. \nThe following proposa…\n\n read more\n\n 18\n\n 2.1k\n\n Aug 2025\n\n Upgrade 18 - Custom Gas Token v2 and Kona Proofs\n\n Proposals 📃\n\n Proposal Type: Protocol Upgrade \nHi I’m Paul, an Engineering Manager at OP Labs and core contributor of the OP Stack. I reviewed this proposal in collaboration with Sanjana Mehta from the OP Labs Team. \nThe following pro…\n\n read more\n\n 2\n\n 318\n\n Jan 28\n\n Upgrade 17 - Jovian Hardfork and Fusaka Readiness\n\n Technical Proposals\n\n Proposal Title: Upgrade 17 Proposal: Jovian Hardfork and Fusaka Readiness \nProposal Type: Protocol Upgrade \nThis proposal will run off cycle \nHi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP S…\n\n read more\n\n 3\n\n 934\n\n Jan 1\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n [deprecated] Upgrade 17 Proposal: Jovian Hardfork\n\n Technical Proposals\n\n This proposal has been deprecated. \n\nProposal Title: Upgrade 17 Proposal: Jovian Hardfork \nProposal Type: Protocol Upgrade \nThis proposal will go to vote during voting cycle 44 \nHi I’m George, a Protocol Engineer at OP …\n\n read more\n\n 2\n\n 329\n\n Nov 2025","tokens":3072,"squid":"ink-governance","role":"Council Listener","at":1791259964028,"hash":"b409a411059617c08161f006696bfa9c0558b0fe"}
{"url":"https://dev-forum.pyth.network/t/welcome-to-pyth-developer-forum/5","domain":"dev-forum.pyth.network","title":"Welcome to Pyth Developer Forum! 👋 - General - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Welcome to Pyth Developer Forum! \n\n General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by system on Mar 26, 2025\n\n system\n\n We are so glad you joined us.\n\nPyth Developer Forum\nWelcome to Pyth Dev Community — the official forum for Pyth’s Technical Support, Product Updates, and Community Discussion. Whether you’re looking for help, exploring release notes, or connecting with other users, you’re in the right place.\n\nHere are some things you can do to get started:\n Introduce yourself by adding your picture and information about yourself and your interests to your profile. What is one thing you’d like to be asked about?\n Get to know the community by browsing discussions that are already happening here. When you find a post interesting, informative, or entertaining, use the to show your appreciation or support!\n Contribute by commenting, sharing your own perspective, asking questions, or offering feedback in the discussion. Before replying or starting new topics, please review the Community Guidelines.\n\nIf you need help or have a suggestion, feel free to ask in #site-feedback or contact the admins.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Forum Feedback category\n\n Forum Feedback\n\n 0\n\n 449\n\n Apr 2025\n\n Welcome to the Announcements category\n\n Announcements\n\n 0\n\n 499\n\n Mar 2025\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n 620\n\n Mar 31\n\n Pyth Community Hackathon Official Rules\n\n Pyth Community Hackathon\n\n 0\n\n 565\n\n Mar 2\n\n Powered by Discourse","tokens":1288,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259967075,"hash":"f7f62508a881ceebfeb7f4e69d2e79f325da938c"}
{"url":"https://io.net/docs/guides/coin/ionet-monthly-token-emission-schedule","domain":"io.net","title":"Monthly Token Emission Schedule - io.net","text":"io.net will release 300 million tokens over 20 years in addition to the 500 million tokens available at launch. The proposed emission schedule simplifies the frequency of disinflation from hourly to monthly while achieving the same total supply target of 800 million tokens.\n\nInitial Supply at Launch: 500,000,000 tokens\nTotal Additional Emissions: 300,000,000 tokens over 20 years\nFinal Cap: 800,000,000 tokens\nDisinflation Frequency: Monthly\nStarting Inflation Rate: 8% per year (0.667% per month)\nDisinflation Factor: /~0.989849199 per month\nDisinflation periods: 240 (20 years × 12 months)\n\nThe monthly emission schedule follows a disinflationary curve, meaning that the inflation rate decreases over time. It starts at 8% annually and gradually reduces each month until it reaches near-zero inflation at the end of 20 years.\n​Monthly Emission Schedule\nThe table below demonstrates the first 12 months of emissions under the proposed schedule:\nMonthTotal SupplyInflation Rate (%)Tokens EmittedJuly 2024500,000,000.000.6673,333,333August 2024503,335,000.000.6603,299,497September 2024506,658,165.730.6543,266,003October 2024509,969,316.470.6473,232,850November 2024513,268,276.000.6403,200,033December 2024516,554,872.590.6343,167,549January 2025519,828,938.940.6273,135,395February 2025523,090,312.180.6213,103,568March 2025526,338,833.810.6153,072,063April 2025529,574,349.690.6083,040,879May 2025532,796,709.990.6023,010,011June 2025536,005,769.190.5962,979,456\n​Visual Representation\nBelow is a chart illustrating the total supply growth and token emissions for the first 12 months:\n\n​Formula for Emissions Calculation\nThe formula for calculating emissions under the proposed monthly schedule is as follows:\nEmissions_T = Total Supply_T-1 × Inflation Rate_T\nWhere:\n\nInflation Rate_T = Inflation Rate_T-1 × (1 - Disinflation Factor)\nDisinflation Factor ≈ 0.010150801 (or 1.01508%)\n\n​Initial Inflation Rate\nInitial Monthly Inflation Rate = Annual Inflation Rate ÷ Months Per Year Initial Monthly Inflation Rate = 8% ÷ 12 = 0.667%\n​Detailed Calculations: First Three Months\nMonth 1 (July 2024):\nThe first month’s emissions are based on the initial supply of 500,000,000 tokens and an inflation rate of 0.667%.\nEmissions_1 = 500,000,000 × 0.667% Emissions_1 = 3,333,333.33 tokens\nAt the end of Month 1:\n\nTotal Supply: 500,000,000 + 3,333,333.33 = 503,333,333.33\n\nMonth 2 (August 2024):\nThe disinflation factor reduces the inflation rate for Month 2:\nInflation Rate_2 = 0.667% × (1 - 0.010150801) Inflation Rate_2 ≈ 0.660%\nThe emissions for Month 2 are:\nEmissions_2 = 503,333,333.33 × 0.660% Emissions_2 ≈ 3,299,497.40 tokens\nAt the end of Month 2:\n\nTotal Supply: 503,333,333.33 + 3,299,497.40 = 506,632,830.73\n\nMonth 3 (September 2024):\nThe inflation rate for Month 3 is further reduced:\nInflation Rate_3 = 0.660% × (1 - 0.010150801) Inflation Rate_3 ≈ 0.654%\nThe emissions for Month 3 are:\nEmissions_3 = 506,632,830.73 × 0.654% Emissions_3 ≈ 3,266,003.20 tokens\nAt the end of Month 3:\n\nTotal Supply: 506,632,830.73 + 3,266,003.20 = 509,898,833.93\n\n​Conclusion\nThe proposed monthly schedule achieves the same emission goal of 300 million tokens over 20 years but simplifies management and calculations compared to the current hourly schedule. By transitioning to monthly emissions:\n\nSimplification: Reduces emission frequency from 175,319 hourly epochs to 240 monthly epochs.\nAccuracy: Maintains the same cumulative disinflation effect over 20 years.\nEase of Implementation: Aligns better with monthly financial and operational reporting cycles.\nWas this page helpful?","tokens":893,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259974253,"hash":"8910de6a7ac61d6da724af52f53c2de7f3859a08"}
{"url":"https://dev-forum.pyth.network/latest","domain":"dev-forum.pyth.network","title":"Latest topics - Pyth Developer Forum","text":"Welcome to Pyth Dev Forum.\n\n Where developers build DeFi. \n\n gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n All latest topics\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Welcome to Pyth Developer Forum! \n\n General\n\n We are so glad you joined us. \n\nPyth Developer Forum\nWelcome to Pyth Dev Community — the official forum for Pyth’s Technical Support, Product Updates, and Community Discussion. Whether you’re looking for help, exploring …\n\n read more\n\n 0\n\n 578\n\n Mar 2025\n\n Pyth Pro equity entitlement for the Stocklana hackathon (Best use of Pyth market data)\n\n Price Feeds\n\n svm\n\n 4\n\n 15\n\n 9h\n\n Temporary Pyth Trial Permissions Upgrade for Fellowship\n\n Pyth Community Hackathon\n\n svm\n\n 1\n\n 5\n\n 10h\n\n When will pyth-lazer-solana-contract, pyth-lazer-sdk crates be bumped for Anchor v0.32?\n\n Price Feeds\n\n svm\n\n 0\n\n 14\n\n 7d\n\n How can I revoke or rotate an exposed Pyth API key?\n\n Benchmarks(Historic Prices)\n\n 1\n\n 9\n\n 8d\n\n Deprecation Notice - Push Feeds (EVM) - October 15th 2026\n\n Price Feeds\n\n announcements\n\n 0\n\n 31\n\n 26d\n\n Hello, I asked earlier but no response. Can entropy be deployed on Robinhood chain now? Got a partnership and nft project coming up that would require it. And also if it can’t be deployed now, when would that be?\n\n Entropy\n\n entropy\n\n 0\n\n 12\n\n Sep 3\n\n Entropy on Robinhood isn’t working yet. Can it be fixed?\n\n Entropy\n\n entropy,sponsored-feeds,starknet\n\n 2\n\n 21\n\n Sep 1\n\n Pyth data for a small public market-intelligence platform in Slovenia\n\n Price Feeds\n\n announcements\n\n 2\n\n 20\n\n Aug 26\n\n Update: Pyth Core Upgrade Date Moved to August 26, 2026\n\n Price Feeds\n\n announcements\n\n 2\n\n 400\n\n Aug 26\n\n We’re building a prediction game on Solana where every shot settles on Pyth, and we ended up doing the account validation by hand rather than through the SDK. Sharing what we found, plus four questions we couldn’t answer from the docs. Why by hand. Our fi\n\n Price Feeds\n\n entropy\n\n 7\n\n 28\n\n Aug 26\n\n Deprecation of Swellchain, Pyth Oracle on will be unavailable - June 15, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 24\n\n Aug 20\n\n Deprecation Notice: Pyth Entropy Deprecation for Selected chains — August 15, 2026\n\n Entropy\n\n announcements,evm,entropy\n\n 1\n\n 43\n\n Aug 18\n\n Pulse Scheduler - is it available for use?\n\n Uncategorized\n\n 1\n\n 16\n\n Aug 12\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Pyth Pro Streams query\n\n Benchmarks(Historic Prices)\n\n 4\n\n 37\n\n Aug 5\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 115\n\n Aug 5\n\n Deprecation of Pyth Push Feeds on Movement — July 13th, 2026\n\n Price Feeds\n\n announcements\n\n 0\n\n 22\n\n Jul 13\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 190\n\n Jul 13\n\n Off-chain price feeds\n\n Price Feeds\n\n 11\n\n 78\n\n Jul 4\n\n Pyth Hermes → Custom EVM Chain Integration Issues\n\n Price Feeds\n\n 7\n\n 68\n\n Jun 22\n\n Missing parsePriceFeedUpdatesUnique function on BSC implementation\n\n Price Feeds\n\n evm\n\n 6\n\n 46\n\n Jun 18\n\n Updates to Push Feeds on Monad Mainnet - 17th June\n\n Price Feeds\n\n announcements\n\n 0\n\n 14\n\n Jun 17\n\n Deprecation of Pyth Core Equity PRE, POST and OVERNIGHT Feeds – 15th June 2026\n\n Announcements\n\n announcements\n\n 1\n\n 128\n\n Jun 17\n\n Pyth-solana-receiver-sdk supported Anchor versions\n\n Price Feeds\n\n 3\n\n 522\n\n Jun 16\n\n Lower-latency Pyth Lazer endpoint for Dublin / Ireland VPS?\n\n Price Feeds\n\n 1\n\n 22\n\n Jun 16\n\n Pythnet RPC access?\n\n Price Feeds\n\n 1\n\n 29\n\n Jun 3\n\n Deprecation of Price Feeds (CRT, ZENBTC) Price Feed - 31st May, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 28\n\n Jun 2\n\n Deprecation of some (Resolv) Pyth Push Feeds on Base, Ethereum, Arbitrum, HyperEVM and Solana – May 31st, 2026\n\n Price Feeds\n\n announcements\n\n 1\n\n 33\n\n Jun 2\n\n [Deprecation Notice] Pyth Pro `/v1/{channel}/streaming` Endpoint — Sunset May 31, 2026\n\n Announcements\n\n 1\n\n 66\n\n Jun 2","tokens":1871,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259978061,"hash":"7a805354817dfc8aa203781138f168f25f853836"}
{"url":"https://io.net/docs/guides/coin/io-coin-allocation","domain":"io.net","title":"IO Coin Allocation - io.net","text":"​Initial $IO Allocation\nThe genesis supply of $IO is set at 500,000,000 tokens, distributed across five categories:\n\nSeed Investors\nSeries A Investors\nCore Contributors\nResearch & Development\nEcosystem and Community\n\nOver the next 20 years, this supply will grow to 800,000,000 $IO through emissions designed to incentivize network growth and adoption.\n\n​Unlocks and Rewards\nThe initial 500 million tokens are subject to specific unlock schedules outlined below. In addition, the circulating supply increases as rewards are issued. Rewards are unlocked upon receipt and immediately added to the circulating supply.\n​Key Definitions:\n\nCirculating Supply: The amount of $IO available in general circulation without on-chain transfer restrictions.\nLocked Supply: The portion of $IO that is unvested and unavailable for circulation.\nAvailable Supply: The sum of circulating supply and issued (but locked) tokens. Rewards not yet issued are excluded from this figure.\nMax Supply: The total number of $IO tokens that will exist after all emissions have been completed.\n\nA breakdown of these supply categories and schedules is provided in the chart below:\n\n​Pro Forma Allocation\nAs the IOG Network emits rewards over time, the proportional share held by early backers and Core Contributors will gradually decrease. Consequently, the Community’s allocation will expand, reaching approximately 50% of the total supply once all rewards have been distributed.\n\nWas this page helpful?","tokens":368,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259985221,"hash":"fca57b1dcfc38ebf2d3a44682656296f7038052d"}
{"url":"https://gov.optimism.io/t/upgrade-19b-karst-hardfork/10713/4","domain":"gov.optimism.io","title":"Upgrade 19b — Karst Hardfork - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Proposals 📃Technical Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 6\n min\n\n Jun 15\n\n 4 / 4\n\n Jun 17\n\n Jun 18\n\n post by soyboy on Jun 15\n\n post by soyboy on Jun 15\n\n post by MconnectDAO on Jun 15\n\n MconnectDAO\n\n Thanks for bringing forward Upgrade 19 and the Karst hardfork in such a detailed way. From a governance and risk management perspective, this bundle looks like a thoughtful step towards making OP Stack upgrades more deterministic, audited and aligned with Ethereum’s Fusaka hardfork.\nI especially appreciate the introduction of the L2 Contract Manager and OPCMv2, and the fact that both components come with design docs, specs and dedicated Failure Mode Analyses. This kind of structured threat modelling and combined audit of the full contracts diff since op-contracts/v6.0.0 sets a strong precedent for future upgrades.\nA few suggestions / questions from a delegate focused on protocol risk:\nFor non‑technical delegates and app teams, it would be helpful to have a short “governance‑level” explainer that summarises:\nhow L2CM and OPCMv2 concretely reduce upgrade execution risk,\nwhat new operator mistakes are still possible in practice, and\nwhich parts of the process remain offchain vs fully onchain.\nThe BN256 pairing input reduction is clearly a proactive move for Glamsterdam’s potential EIP‑7904. Could you add one or two concrete examples (e.g. common ZK circuits) in the notice docs to reassure integrators that standard proof systems remain within safe limits under the new cap?\nGiven CANNON_KONA is now the respected game type and op-geth / op-program support is ending, it might be useful to publish a simple “fault proof readiness checklist” for chains and operators, so governance can better track who is fully migrated before the July 8 activation.\nI also appreciate that the proposal explicitly states there is no change to Standard Rollup Charter precommitments (fee take, role separation, ossified gas limits, fee margin controls). Keeping economic and political parameters out of this upgrade helps keep the scope tight and reduces governance risk.\nOverall, I am supportive of the direction of Upgrade 19, subject to continued clarity for less technical stakeholders on how these changes impact their operational risk and upgrade responsibilities.\n\n post by soyboy on Jun 18\n\n soyboy\n\n Hey thanks for your suggestions, most of what you’re asking for are provided in the links in the design documentation and the failure mode analysis. The current governance level summary that I put in the motivation which essentially describes the outcomes we expect from this upgrade. I personally don’t believe there is value in re-summarizing the contents of the specs, design docs, and failure mode analysis because you’d lose the detail needed to fully describe this functionality.\n\nThere are details here: feat(karst): reduce bn256Pairing input size limit to 300 pairs by pauldowman · Pull Request #20250 · ethereum-optimism/optimism · GitHub\n\nThis is outlined in the u19 notice page for chain operators. Insight into the actual chain operators practices is opaque, but it is permissionless to run your own node with the correct software if you’d like to verify the correct behavior\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon\n\n Protocol Upgrade\n\n Proposal Type: Protocol Upgrade\nHi, I’m Kelvin, the technical lead on the OP Labs EVM Safety team. I will be acting as the primary point of contact for technical questions related to this proposal. \nThe following proposa…\n\n read more\n\n 18\n\n 2.1k\n\n Aug 2025\n\n Upgrade 18 - Custom Gas Token v2 and Kona Proofs\n\n Proposals 📃\n\n Proposal Type: Protocol Upgrade \nHi I’m Paul, an Engineering Manager at OP Labs and core contributor of the OP Stack. I reviewed this proposal in collaboration with Sanjana Mehta from the OP Labs Team. \nThe following pro…\n\n read more\n\n 2\n\n 318\n\n Jan 28\n\n Upgrade 17 - Jovian Hardfork and Fusaka Readiness\n\n Technical Proposals\n\n Proposal Title: Upgrade 17 Proposal: Jovian Hardfork and Fusaka Readiness \nProposal Type: Protocol Upgrade \nThis proposal will run off cycle \nHi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP S…\n\n read more\n\n 3\n\n 934\n\n Jan 1\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n [deprecated] Upgrade 17 Proposal: Jovian Hardfork\n\n Technical Proposals\n\n This proposal has been deprecated. \n\nProposal Title: Upgrade 17 Proposal: Jovian Hardfork \nProposal Type: Protocol Upgrade \nThis proposal will go to vote during voting cycle 44 \nHi I’m George, a Protocol Engineer at OP …\n\n read more\n\n 2\n\n 329\n\n Nov 2025","tokens":1281,"squid":"ink-governance","role":"Council Listener","at":1791259985276,"hash":"f3a4ffa66583cc7d12414a4bb459291eb8aad444"}
{"url":"https://dev-forum.pyth.network/t/pyth-pro-equity-entitlement-for-the-stocklana-hackathon-best-use-of-pyth-market-data/837/5","domain":"dev-forum.pyth.network","title":"Pyth Pro equity entitlement for the Stocklana hackathon (Best use of Pyth market data) - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n svm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Sep 22\n\n 5 / 5\n\n Oct 5\n\n 9h ago\n\n post by Rayyer on Sep 22\n\n Rayyer\n\n I’m building for the Solana Foundation Stocklana hackathon (submissions close 25 Sep, 20:00 UTC) and targeting the “Best use of Pyth market data” track. I’d like to request a hackathon-scoped Pyth Pro token entitled to US equities.\n Chain\nSolana. Reads are against mainnet; the program is deployed on devnet.\n Timestamp\nReproduced at 2026-09-22 10:12:24 UTC. First seen 2026-09-20.\n Steps to reproduce\n\nSign up at pythdata.app and create an API key (free Terminal trial).\nRequest a crypto feed with it — works, HTTP 200.\nRequest any US equity feed with the same key — HTTP 403.\n\n Code snippet\n# control — crypto: HTTP 200\ncurl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://hermes.pyth.network/v2/updates/price/latest?ids[]=ef0d8b6fda2ceba41da15d4095d1da392a0d2f8ed0c6c7bc0f4cfac8c280b56d&parsed=true\"\n\n# Equity.US.AAPL/USD: HTTP 403\ncurl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://hermes.pyth.network/v2/updates/price/latest?ids[]=49f6b65cb1de6b10eaf75e7c03ca029c306d0357e91b5311b175084a5ad55688&parsed=true\"\n# -> Not entitled: feed 49f6b65c...5688 (no grant accepts this feed (asset type 'equity', instrument type 'spot', exchange 1))\n\n# Equity.Index.AAPL/USD (24/7): HTTP 403\ncurl -H \"Authorization: Bearer $PYTH_API_KEY\" \\\n \"https://hermes.pyth.network/v2/updates/price/latest?ids[]=aaba35e6f33fb973bb2201d48a79ae24795affa6ba8bd50a93dcaf7da0030f36&parsed=true\"\n# -> Not entitled: feed aaba35e6...0f36 (no grant accepts this gated feed; it requires access to one of the following groups: [\"pyth-indices\"])\n\nSo the key authenticates fine; it just isn’t entitled to asset type equity or to the pyth-indices group.\nName of the project\nDeliverable — an options venue on tokenized US stocks (xStocks) on Solana. Writers sell covered calls against real tokenized shares; settlement is physical delivery of the share itself.\nWhy Pyth equity data matters here specifically: the venue’s settlement gate refuses to act when it can’t defend the security’s state — market closed, halted, or a stale or unreliable price. Today it already reads Pyth Lazer equity prices indirectly, through the PythLazer AAPLx/USD entries that Kamino Scope republishes on-chain. A direct entitlement would let the program verify Pyth updates itself instead of trusting an intermediary’s copy. The 24/7 Equity.Index feeds are the other half: they let the interface show the price the venue could have settled against while the reference market is shut, next to the refusal — which is the core of the demo.\nWhat I’m asking for\n\nA hackathon-scoped token entitled to asset type equity, and if at all possible the pyth-indices group.\nTickers: AAPL, NVDA, TSLA, SPY, QQQ, GOOGL, META, MSTR, COIN, CRCL.\nFine for it to expire once judging concludes (2 Oct).\n\nOne technical confirmation, if you have a moment: is the Lazer Solana contract pytd2yyk641x7ak7mkaasSJVXh6YYZnC7wTmtgAyxPt the right on-chain verifier for Pro equity updates requested with formats: [\"solana\"]? I’d rather verify the signed update in the program than read it off-chain.\nContact\n\nEmail (also my Pyth Terminal account): egorslavutich@gmail.com\nDiscord: rayyer_220 | id 677158150691880980\nTelegram: @L0ceo\n\nThanks!\n\n 2\n\n 2\n\n post by KemarTiti on Sep 22\n\n KemarTiti\n\n Hey!\nThanks for reaching out - are sure about this email (egorslavutich@gmail.com)? I could not find you anywhere\n\n post by Rayyer on Sep 22\n\n Rayyer\n\n Yeah, sorry, I messed up with mails, the one that goes with my Pyth Terminal account is egorivaschenko77@gmail.com\n\n post by KemarTiti on Sep 22\n\n KemarTiti\n\n Found you and bumped your permissions for the hackathon!\n\n 13 days later\n\n post by Organic 9 hours ago\n\n Organic\n\n Posted about a similar situation, would really appreciate having the permissions upgraded to the MAG7 (kaushalbalagurusamy@berkeley.edu) for the rest of this week (project due Monday)\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Temporary Pyth Trial Permissions Upgrade for Fellowship\n\n Pyth Community Hackathon\n\n svm\n\n 1\n\n 5\n\n 10h\n\n Clarification on Displaying Equity Price Data in Trading Journal App\n\n Price Feeds\n\n 3\n\n 580\n\n Aug 2025\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 714\n\n Dec 2025\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 23\n\n Apr 9\n\n Powered by Discourse","tokens":2024,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259988242,"hash":"69c5841205f3d300a761a10a4262cce9a48ba3fd"}
{"url":"https://io.net/docs/guides/coin/io-coin","domain":"io.net","title":"Overview - io.net","text":"IO Coin ($IO) is the native cryptocurrency of the IOG Network, powering its ecosystem and facilitating seamless interactions between key participants. These participants include:\n​GPU Renters (Users):\nMachine Learning Engineers, developers, and individual consumers who use $IO to rent GPU computing power for tasks like deploying GPU clusters, running cloud gaming instances, or building applications such as Unreal Engine 5 pixel streaming. Users can also leverage $IO for serverless AI model inferences via platforms like BC8.ai and other apps hosted on io.net.\n​GPU Owners (Suppliers):\nIndependent data centers, crypto mining farms, and professional miners supply underutilized GPU computing power to the network. They earn $IO tokens by providing this compute power.\n​$IO Coin Holders (Community):\nSupporters who stake $IO to secure the network, earn rewards and align incentives across the ecosystem for sustainable growth and adoption.\nThese roles are flexible—anyone can participate in multiple capacities (e.g., a GPU owner can also be an $IO holder and a GPU renter).\n\n​Universal Payment System\nThe IOG Network’s payment system revolves around $IO. While users can pay in fiat (e.g., USD), USDC, or other supported cryptocurrencies, all payments are ultimately converted to $IO behind the scenes. This approach reduces friction in transactions and avoids traditional issues like escrow and delayed billing, while maintaining strong demand for $IO.\n​User Payments:\n\nCustomers can pay in USDC or fiat for GPU services.\nSuppliers receive compensation in $IO, creating demand for the token.\n\n​Supplier Options:\n\nSuppliers can opt to receive payments in native $IO or convert earnings into USDC, based on their preference.\n\n​Network Security and Collateralization\n$IO is integral to securing and maintaining the network’s integrity. Two primary mechanisms achieve this:\n​Node Collateral Requirements:\nA minimum amount of $IO must be staked to operate a node and earn idle rewards.\n​Staking for Rewards:\nAdditional $IO can be staked up to a maximum limit per node, allowing holders to earn rewards while contributing to the network’s security and reliability.\nThese mechanisms incentivize active participation and align interests across the network.\n\n​Why $IO Matters\n$IO is more than just a transactional token—it’s the backbone of the IOG Network, driving economic activity and ensuring network health. Its design creates a dynamic, interconnected ecosystem that benefits Renters, Suppliers, and Holders alike.\nBy reducing payment friction, offering a flexible fee structure, and integrating network security features, $IO builds a sustainable framework for growth and innovation.\n\n​Call to Action\nExplore the IOG Network and see how $IO can power your GPU-driven projects or help you monetize unused resources. Whether you’re an AI developer, a data center owner, or a blockchain enthusiast, $IO offers a unified, efficient, and scalable solution.\n​Join the IOG Network today and experience the future of decentralized computing!Was this page helpful?","tokens":765,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791259995401,"hash":"f2ed7a3537f78bcdc2a344a6a6a7144581c85067"}
{"url":"https://gov.optimism.io/c/88-category/protocol-upgrade/58","domain":"gov.optimism.io","title":"Latest Proposals 📃/Protocol Upgrade topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Protocol Upgrade\n\n Proposals 📃\n\n Protocol Upgrade\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Protocol Upgrade category\n\n 1\n\n 2.6k\n\n Feb 2023\n\n Upgrade 20 - Super Root Dispute Games & OPCM v8.0.0\n\n Proposal Type: Protocol Upgrade\nHi, I’m Andrea Federici, Senior Solutions Engineer at OP Labs. I prepared this proposal in collaboration with Adrian Sutton, Matt Solomon and Matthew Cruz from the OP Labs team. Neither OP…\n\n read more\n\n 2\n\n 281\n\n 20d\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment\nProposal Type: Protocol Upgrade\nVoting Cycle: Cycle #52 \nExecutive Summary\nThis proposal requests approval for a time-boxed transaction-ordering experiment on OP…\n\n read more\n\n 1\n\n 276\n\n Apr 16\n\n Upgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon\n\n Proposal Type: Protocol Upgrade\nHi, I’m Kelvin, the technical lead on the OP Labs EVM Safety team. I will be acting as the primary point of contact for technical questions related to this proposal. \nThe following proposa…\n\n read more\n\n 18\n\n 2.1k\n\n Aug 2025\n\n Governor Update Proposal: Removing Abstain Count from Quorum\n\n Executive Summary\nThis proposal outlines a targeted improvement to the Optimism Governor contract by removing Abstain votes from quorum calculations. The change resolves an edge case where Abstain votes could unintention…\n\n read more\n\n 21\n\n 854\n\n Jul 2025\n\n Protocol Upgrade: Superchain Registry 2.0\n\n Proposal Title: Superchain Registry 2.0 \nProposal Type: Protocol Upgrade \nExecutive Summary\nThis Protocol Upgrade makes several improvements to the Standard Rollup Charter’s Onchain Criteria. Primarily, it adds additiona…\n\n read more\n\n 14\n\n 866\n\n Apr 2025\n\n Upgrade Proposal #13: OPCM and Incident Response improvements\n\n Executive Summary\nHi I’m Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej (@0xEscanor) and @Kelvin from the OP Labs Team. \nThis proposal is intended to be voted on in cycle…\n\n read more\n\n 19\n\n 1.4k\n\n Mar 2025\n\n Upgrade Proposal #12: L1 Pectra Readiness\n\n Proposal Title: L1 Pectra Compatibility\nProposal Type: Maintenance Upgrade\nExecutive Summary\nHi I’m George, a Protocol Engineer at OP Labs and core contributor of the OP Stack. I reviewed this proposal in collaboration w…\n\n read more\n\n 3\n\n 486\n\n Mar 2025\n\n Upgrade Proposal #11: Holocene Network Upgrade\n\n Proposal Title: Holocene governance proposal\nProposal Type: Protocol Upgrade\nExecutive Summary\nHi I’m Dragan, a technical program manager at OP labs working on the OP blockchain development team, and a core contributor o…\n\n read more\n\n 32\n\n 2.6k\n\n Dec 2024\n\n Governor Update Proposal #3: Enable onchain treasury execution\n\n Executive Summary\nHi I’m Kent, CTO of Agora. Agora is the governance software company focused on contributing to the Optimism token house governor and its frontend at vote.optimism.io. We provide some services to, but do…\n\n read more\n\n 19\n\n 1.1k\n\n Nov 2024\n\n Upgrade Proposal #10: Granite Network Upgrade\n\n Executive Summary\nHi I’m Mofi, a protocol engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not rep…\n\n read more\n\n 30\n\n 5.3k\n\n Aug 2024\n\n Upgrade Proposal #9: Fjord Network Upgrade\n\n Executive Summary\nHi I’m Roberto, an engineer at Coinbase working on the Base blockchain, and a core developer of the OP Stack. I reviewed this proposal in collaboration with Sebastian Stammler and Dragan Zurzin from the…\n\n read more\n\n 23\n\n 4.4k\n\n Jun 2024\n\n [FINAL] Governor Update Proposal #2: Improvements to advanced delegation allowance calculations\n\n Executive Summary\nHi I’m Kent, CTO of Agora. Agora is the governance software company contributing to the Optimism token house governor and its frontend at vote.optimism.io. We provide some services to, but do not repres…\n\n read more\n\n 18\n\n 1.3k\n\n Jun 2024\n\n [FINAL] Protocol Upgrade #7: Fault Proofs\n\n Executive Summary\nHi I’m Adrian, a protocol engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not r…\n\n read more\n\n 44\n\n 6.2k\n\n Jun 2024\n\n [FINAL] Protocol Upgrade #8: Guardian, Security Council Threshold and L2 ProxyAdmin Ownership changes for Stage 1 Decentralization\n\n Hi Maurelian here, I’m a protocol security engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not re…\n\n read more\n\n 26\n\n 2.5k\n\n May 2024\n\n Governor Update Proposal #1: Improve advanced delegation voting\n\n Executive Summary\nHi I’m Kent, CTO of Agora. Agora is the governance software company contributing to the Optimism token house governor and its frontend at vote.optimism.io. We provide some services to, but do not repres…\n\n read more\n\n 14\n\n 2.2k\n\n Apr 2024\n\n Upgrade Proposal #6: Multi-Chain Prep (MCP) L1\n\n Executive Summary\nHi I’m Diego, a protocol engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem and a core developer of the OP Stack. We provide some services to, but do not re…\n\n read more\n\n 11\n\n 3.7k\n\n Mar 2024\n\n Upgrade Proposal #5: Ecotone Network Upgrade\n\n Executive Summary\nHi I’m Roberto, an engineer on the core Base team and a core developer of the OP Stack. Neither Coinbase nor I represent or speak on behalf of the Optimism Foundation. \nThis is a proposal for the Ecoton…\n\n read more\n\n 19\n\n 5.6k\n\n Mar 2024\n\n Upgrade Proposal #4\n\n season-5,cycle-18\n\n Hi I’m Maurelian, an engineer at OP Labs. \nOP Labs is a software development company focused on the Optimism ecosystem, and a core developer of the OP Stack. We provide some services to, but do not represent or speak on …\n\n read more\n\n 24\n\n 4.2k\n\n Feb 2024\n\n [FINAL] Upgrade Proposal #3: Delta Network Upgrade\n\n Executive Summary\n\nTest in Prod proposes Delta network upgrade, which activates Span Batches for OP Mainnet and all other OP Chains.\nSpan Batches implement a new batching specification that reduces L1 costs by ~97% for i…\n\n read more\n\n 23\n\n 5.1k\n\n Feb 2024\n\n [FINAL] Upgrade Proposal #2: Canyon Network Upgrade\n\n Executive Summary\nHi I’m Joshua, an engineer at OP Labs. OP Labs is a software development company focused on the Optimism ecosystem, and a core developer of the OP Stack. We provide some services to, but do not represen…\n\n read more\n\n 13\n\n 5.6k\n\n Dec 2023\n\n [FINAL] Upgrade #1: Bedrock Protocol Upgrade - v2\n\n Executive Summary\n\nIn short, what is this upgrade proposal? \nImpacted stakeholders & expected outcomes \nWhy the Collective should upgrade \n\nThe Optimism Foundation is proud to propose the first protocol upgrade to the Op…\n\n read more\n\n 20\n\n 14.3k\n\n Apr 2023\n\n [DRAFT] Upgrade Proposal: Bedrock\n\n Executive Summary\n\nIn short, what is this upgrade proposal? \nImpacted stakeholders & expected outcomes \nWhy the Collective should upgrade \n\nThe Optimism Foundation is proud to propose the first protocol upgrade to the Op…\n\n read more\n\n 86\n\n 19.4k\n\n Mar 2023\n\n [Request for Comment] Protocol Upgrade Proposal Information\n\n season-3\n\n Hi all, \nOn behalf of the Optimism Foundation, I’d like to get the conversation with the community started about Optimism’s first ever protocol upgrade vote. With the Bedrock release approaching, the first ever protocol …\n\n read more\n\n 21\n\n 5.4k\n\n Feb 2023","tokens":1907,"squid":"ink-governance","role":"Council Listener","at":1791259995698,"hash":"c1cef7682e337a451ef6066175973619d6ac406a"}
{"url":"https://dev-forum.pyth.network/t/temporary-pyth-trial-permissions-upgrade-for-fellowship/845","domain":"dev-forum.pyth.network","title":"Temporary Pyth Trial Permissions Upgrade for Fellowship - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Temporary Pyth Trial Permissions Upgrade for Fellowship \n\n Pyth Community Hackathon\n\n svm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 5\n\n 1 / 2\n\n Oct 5\n\n 10h ago\n\n post by Organic 10 hours ago\n\n Organic\n\n Hi Pyth team, I’m a fellow in the Gauntlet AI fellowship. My Pyth Terminal trial key (account email: kaushalbalagurusamy@berkeley.edu) is only entitled to Equity.US.TSLA/USD. Could you add the six other MAG7 regular-session feeds for the length of the project? Details below.\n Chain\nSolana devnet. Settlement reads PriceUpdateV2 through the pro-compatible receiver rec2HHDDnjLfj4kE7VyEtFA1HPGQLK33259532cRyHp (pyth-solana-receiver-sdk 2.0.0, Anchor 1.2).\n Timestamp of the issue\n2026-10-05, 17:18–17:40 UTC. It still reproduces.\n Steps to reproduce\n\nRequest the latest price with the trial key for each MAG7 feed on Hermes. TSLA returns 200; AAPL, MSFT, GOOGL, AMZN, NVDA and META return 403.\nSubscribe on Pyth Pro (Lazer) to IDs 922, 954, 1163, 1272, 1292 and 1314. Each returns subscriptionError … Not entitled, while 1435 (TSLA) streams normally.\nCrypto (for example Crypto.BTC/USD) returns 200, so the key itself is valid.\n\n Code snippet\ncurl -H “Authorization: Bearer $PYTH_API_KEY”\n“https://hermes.pyth.network/v2/updates/price/latest?parsed=true&ids[]=49f6b65cb1de6b10eaf75e7c03ca029c306d0357e91b5311b175084a5ad55688”\n→ 403 Not entitled: feed 49f6b65c…5688 (no grant accepts this feed\n(asset type ‘equity’, instrument type ‘spot’, exchange 1))\nws.send(JSON.stringify({ type: “subscribe”, subscriptionId: 1, priceFeedIds: [922],\nproperties: [“price”,“exponent”,“confidence”,“feedUpdateTimestamp”],\nformats: , channel: “fixed_rate@200ms” }));\n// → {“type”:“subscriptionError”,“subscriptionId”:1,“error”:“Not entitled: feed 922 (…)”}\nFeeds requested: AAPL 49f6b6…5688 (922), AMZN b5d0e0…b07a (954), GOOGL 5a48c0…5aa6 (1163), META 78a3e3…07fe (1272), MSFT d0ca23…d4d1 (1292), NVDA b10738…a593 (1314).\nName of the dApp / project\nMeridian, a Gauntlet AI fellowship partner project. It’s a non-commercial Solana devnet prototype of binary “will [stock] close at or above [strike] today” markets on the MAG7, settled on-chain from a Pyth price update at the 16:00 ET close. No real funds are involved, and the deadline is 2026-10-09. I’m happy to provide anything that helps you verify this: confirmation of the fellowship, the project brief, read access to the repository, and the devnet program ID once deployed. Pyth will be credited as the settlement oracle in the docs and demo. It would also help to know how long the trial key stays valid.\nContact\nEmail: kaushalbalagurusamy@berkeley.edu\n\n post by Organic 10 hours ago\n\n Organic\n\n I noticed someone on 9/22 got access upgraded for their hackathon and was hoping I could have the same happen\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Pro equity entitlement for the Stocklana hackathon (Best use of Pyth market data)\n\n Price Feeds\n\n svm\n\n 4\n\n 15\n\n 9h\n\n Price feed subscription error\n\n Price Feeds\n\n evm\n\n 0\n\n 26\n\n May 21\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 23\n\n Apr 9\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 221\n\n Jan 12\n\n Powered by Discourse","tokens":1718,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791259998654,"hash":"69df822b79bb6b4ce121ea5ab35b0b84600a4f83"}
{"url":"https://gov.optimism.io/t/upgrade-proposal-stake-based-priority-ordering-experiment/10655","domain":"gov.optimism.io","title":"Upgrade Proposal: Stake-Based Priority Ordering Experiment - Proposals 📃 / Protocol Upgrade - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment \n\n Proposals 📃Protocol Upgrade\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 16\n\n 1 / 2\n\n Apr 16\n\n Apr 16\n\n post by ben-chain on Apr 16\n\n ben-chain\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment\nProposal Type: Protocol Upgrade\nVoting Cycle: Cycle #52\nExecutive Summary\nThis proposal requests approval for a time-boxed transaction-ordering experiment on OP Mainnet consisting of two phases of stake-based priority ordering.\nUnder the experiment, participants who stake OP tokens into a dedicated smart contract may receive priority transaction treatment for a designated transaction-sending address. The purpose of the experiment is to test whether stake-based priority access changes the behavior of heavy blockspace consumers, including market makers and arbitrage bots, and whether it can reduce spammy or redundant transaction behavior while creating new utility for OP tokens. At the end of the experiment, OP Mainnet will revert to standard PGA ordering.\nImpacted stakeholders include market makers, searchers, blockspace-intensive transactors, integrators, and all other OP Mainnet users. The expected outcome is operational and economic learning, rather than short-term revenue maximization.\nMotivation\nThis proposal is being submitted to allow the Collective to approve a bounded, reversible experiment that changes transaction ordering policy on OP Mainnet.\nThe goal is to test whether a stake-to-prioritize model can:\n\ncreate new utility for OP tokens beyond governance,\n\ninfluence the behavior of sophisticated blockspace consumers,\n\nreduce failed, redundant, or spammy transaction submission patterns,\n\ngenerate data on market maker and arbitrage bot behavior under stake-based ordering, and\n\nhelp inform future blockspace tooling across the Superchain.\n\nTo the best of the proposer’s knowledge, this proposal does not modify any existing Blockspace Charter precommitments relating to transaction ordering.\nSpecifications\n\nBlockspace Charter\n\nNo Blockspace Charter changes are proposed.\n\n**Technical Details\n**\nThe technical details of the experiment are described in more detail in the documentation attached as Attachment 1. At a high level:\n\nThis proposal approves a two-phase, time-boxed experiment in stake-based transaction ordering on OP Mainnet.\nA dedicated staking contract will allow a participant to stake OP from a capital address and optionally link that stake to a separate transaction-sending address. A staker may link to one beneficiary address at a time. If stake is linked to a beneficiary address, the staker’s own address does not also receive the benefit of that same stake.\nEligible transactions will receive priority treatment under the experiment’s ordering rules.\nPhase 1 tests FIFO ordering among eligible participants.\nPhase 2 tests stake-weighted ordering among eligible participants. The current design intent is a bounded, diminishing-returns model that preserves market pricing signals while giving some additional weight based on effective stake and stake age. Current numerical values described in associated design materials are illustrative starting parameters only and are not fixed by this proposal.\nThe proposal delegates exact operational parameters to the Optimism Foundation, including threshold values, weighting-function parameters, rollout timing, monitoring thresholds, and checkpoint decisions, so long as the experiment remains within the scope approved by governance.\nRelevant implementation materials:\n\nStaking contract spec / repository\n\nStaking contract deployment address: The contract is deployed on OP Sepolia at 0xeFcb172De9aA254910A2E93E596F7F5721c17677 with owner address 0xA895C24907D872bC05B58933205dD98090C07446 and a mock ERC20 at 0x3d2536BC0Bc0BAdE9e836C0934419c25b2e0B58C. The Optimism Foundation will post the Mainnet staking address on the Optimism docs in the upcoming weeks.\n\nAudit report / Audit findings / remediation summary\n\nStaked OP are intended to remain outside the control of the Optimism Foundation, and participants are intended to be able to unstake at any time.\n\n**Impact summary\n**\nThis proposal authorizes a temporary change to transaction ordering on OP Mainnet for experimental purposes. The experiment is intended to be reversible, bounded in duration, and subject to standard Optimism Foundation incident-response and operational protocols.\nAnticipated impacts include:\n\nchanges in bidding, spam, and arbitrage behavior by sophisticated blockspace consumers,\n\npossible new demand for OP staking tied to transaction priority,\n\noperational learning around sequencer tooling and ordering policy, and\n\ndata on whether stake-based priority access changes transaction inclusion patterns without degrading sequencer health or ordinary user experience.\n\nIllustrative success metrics from the underlying design work include participation, total OP staked, sequencer health, normal-user impact, fee effects, revert rate, and spam rate. Exact thresholds and response procedures are delegated to the Optimism Foundation under its standard operating protocols.\nThe experiment will automatically conclude after the OP Mainnet test window and OP OP Mainnet will revert to standard PGA ordering.\n\nPrecommitment impact review\n\nAll known precommitments are unaffected.\nNo precommitments are proposed to be modified.\nNo precommitments are proposed to be removed.\n\nAction Plan\nSepolia testing will run for 2–4 weeks prior to commencing the experiment on OP Mainnet. If Sepolia testing is successful and stable, the OP Mainnet experiment may be launched.\nThe OP Mainnet experiment may run for up to 4 weeks total:\n\nPhase 1: up to 1 week\n\nPhase 2: up to 3 weeks\n\nAt the end of the OP Mainnet experiment, OP Mainnet will revert to standard PGA ordering.\nFollowing the experiment, the Optimism Foundation expects to publish learnings and results.\nDisclosures & Disclaimers\nImportant disclosures and disclaimers are attached to this proposal as Attachment 2.\nConclusion\nThis proposal requests approval for a bounded, two-phase experiment in stake-based priority ordering on OP Mainnet. The experiment is intended to generate operational and economic learning while remaining temporary, reversible, and subject to standard operational safeguards.\nThe proposer requests approval from the Optimism Collective to authorize the Optimism Foundation to implement and operate this experiment without requiring a second governance vote between phases, provided the experiment remains within the scope described in this proposal.\nAttachment 1: Stake-based priority ordering on OP Mainnet\n\nAttachment 2: Disclosures & Disclaimers\n\n post by Michael on Apr 16\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP as an MEV staking token\n\n ✨ General\n\n Hi everyone, I wanted to make an alternate proposal than Enabling $OP as a gas token on Optimism Network!. This is an approach which mirrors PoS as well as Fuel Labs. \nThis is not a token price scheme, please read the fu…\n\n read more\n\n 13\n\n 3.8k\n\n Aug 2022\n\n Proposal to Align the OP Token with Superchain Success\n\n Proposals 📃\n\n season-9\n\n Proposal to Align OP Token with Superchain Success\nThis proposal was updated on 1/15/26 to reflect community feedback to split the original proposal into two separate proposals. \nExecutive Summary\n\nThis proposal would im…\n\n read more\n\n 36\n\n 4.3k\n\n 1d\n\n [READY] [GF: Phase 1 Proposal] dHEDGE\n\n Governance Fund: Phase 1\n\n cycle-4\n\n Project Name: dHEDGE DAO \nAuthor Name: Jake Richards \nNumber of OP tokens requested: 500,000 OP over 6 months \nL2 Recipient Address: 0x352Fb838A3ae9b0ef2f0EBF24191AcAf4aB9EcEc \nRelevant Usage Metrics: \n\nOptimism TVL: $1…\n\n read more\n\n 42\n\n 6.2k\n\n Aug 2022\n\n [DRAFT] Support missions that should deploy OP stack for testing\n\n ARCHIVED & OLD Missions\n\n season-4\n\n S4 Intent: Progress Towards Technical Decentralization (Intent 1) \nProposed Mission: Support missions that should deploy OP stack for testing \nProposal Tier: Ember \nPlease verify that you meet the qualifications for your…\n\n read more\n\n 10\n\n 1.5k\n\n Jul 2023\n\n [FINAL] Upgrade Proposal #3: Delta Network Upgrade\n\n Protocol Upgrade\n\n Executive Summary\n\nTest in Prod proposes Delta network upgrade, which activates Span Batches for OP Mainnet and all other OP Chains.\nSpan Batches implement a new batching specification that reduces L1 costs by ~97% for i…\n\n read more\n\n 23\n\n 5.1k\n\n Feb 2024","tokens":2147,"squid":"ink-governance","role":"Council Listener","at":1791260005960,"hash":"f76c4c00b06f2dc472f25d0153e891b6ba9ee87f"}
{"url":"https://aave.com/docs/aave-v3/umbrella","domain":"aave.com","title":"Umbrella | Aave Protocol Documentation","text":"Umbrella#\n\nAave Umbrella is a modular, onchain risk management system that automates bad debt coverage for Aave v3 pools. Built by BGD Labs and approved by Aave governance, Umbrella introduces a more capital-efficient and automated way to protect the protocol without requiring governance intervention.\nUmbrella allows users to stake two types of assets: aTokens (supplied tokens such as aUSDC, aUSDT, and aWETH) and GHO (Aave's native stablecoin). By staking these protocol assets, users actively contribute to risk management while earning rewards.\nUmbrella enhances the reslience of the Aave Protocol by replacing the existing Safety Module with an automated staking system. If a deficit occurs in a given asset, Umbrella enables the corresponding staked assets to be burned and offset the bad debt, removing the need for governance decisions or manual intervention. This creates a more efficient, responsive, and predictable safety mechanism for the protocol and its users.\nUmbrella can be interacted with using the Aave Labs Interface.\nKey Benefits#\nAutomated Coverage: Eliminates reliance on governance for bad debt resolution by responding directly to measurable, onchain deficit data.\naToken Staking: Allows users to stake aTokens they already hold within Aave, continuing to earn underlying yield while participating in risk management.\nIncreased Efficiency: aTokens are the most capital-efficient assets to cover deficits. For example, burning aUSDT directly covers USDT bad debt without requiring market sales.\nEnhanced Security: Creates a more resilient protocol by tying coverage directly to the borrow assets through an automated mechanisms.\nRewards and Safety Incentives#\nWith Umbrella, users who stake their aTokens continue earning yield on their supplied assets while gaining additional rewards for helping secure the protocol. For aToken staking (USDC, USDT, WETH), you earn dual yield streams. The underlying aToken yield continues accruing automatically in your staked position, while additional Safety Incentives compensate you for assuming slashing risk.\nFor GHO staking, you earn Safety Incentives directly since GHO doesn't generate underlying yield like aTokens. These rewards can be paid in various tokens like AAVE, GHO, or USDC, depending on governance configuration. Unlike automatic aToken yield, Safety Incentives must be actively claimed through blockchain transactions.\nThe rewards system uses a mathematically modeled Emission Curve that targets optimal staking levels. The system defines a target amount of staked assets and allocates maximum rewards when total staking reaches exactly that target. When total staked assets are below the target, rewards are proportionally higher to attract participation. When staking exceeds the target, rewards decrease slightly to discourage over-staking.\nThis creates a natural balancing mechanism that prevents extreme APY fluctuations. As a general rule, the maximum APY when minimal assets are staked is double the APY at target liquidity, but the curve avoids misleading triple-digit scenarios that disappear with increased participation.\nSlashing Risk and Deficit Protection#\nIn return for earning rewards, stakers accept the possibility of slashing if a deficit arises on the specific pool and asset they have staked. Staking risk is isolated to the specific asset and network where the aTokens are staked. For example, staking aUSDC helps cover bad debt in USDC only.\nThe system includes crucial deficit offset mechanisms that provide first-loss protection. For example, USDT staking has a 100,000 USDT offset, meaning the Aave DAO covers the first 100,000 USDT of bad debt before any staker assets are affected. While the protocol design allows for slashing up to the full staked amount in extreme scenarios, the offset mechanisms significantly reduce the likelihood of any slashing for typical deficit scenarios.\nTo put this in perspective, during the first month of Aave v3.3 operation, approximately $400 in total deficit accumulated across all pools, against nearly $9.5 billion in outstanding borrows. This represents roughly 0.000004% of outstanding borrowings.\nNetwork Coverage and Initial Activation#\nInitial activation starts with Ethereum and will expand to other networks, focusing on high-borrow demand assets like USDC, USDT, WETH, and GHO. Activation parameters, including reward rates and target liquidity levels, are set by the Aave DAO, with ongoing management delegated to the Aave Finance Committee.\nEach Umbrella deployment protects only the specific asset and network where it's staked, providing precise risk isolation. The system maintains a 20-day cooldown period and 2-day withdrawal window, consistent with the previous Safety Module.\nTransition from the Legacy Safety Module#\nUmbrella will gradually replace the legacy Safety Module. Current participants have different migration paths depending on their staked assets.\nstkAAVE and stkABPT will remain active during the transition, with slashing disabled once Umbrella reaches sufficient scale. No immediate action is required for these positions.\nStaked GHO (stkGHO) is being transitioned to the new savings GHO (sGHO) — a native ERC-4626 vault that earns a fixed APR via an on-chain yield index with no cooldown period, no slashing risk, and no rehypothecation. Users should withdraw GHO from the legacy stkGHO contract and deposit into the new sGHO vault. See the sGHO guide for integration details. For higher rewards with slashing risk, users can instead migrate to Umbrella stkGHO by activating cooldown on legacy stkGHO, unstaking their GHO, then staking in the new Umbrella system.\nThis empowers suppliers who aren't borrowing to participate in risk management while earning rewards, creating broader participation in protocol security and aligning incentives with protocol health.\nSee the Umbrella FAQ for more common questions.\nArchitecture#\nUmbrella is built from three main contract types:\nUmbrellaCore: Orchestrates deficit monitoring, slashing, and asset coverage for each Aave v3 pool.StakeToken: ERC4626 Vault per asset and network that handles staking, cooldown, slashing, and integrates with the rewards controller.RewardsController: Manages multi-token rewards, emission curves, and user reward accounting.UmbrellaBatchHelper: Periphery contract enabling multiple actions to be batched into a single transaction.\nStaking#\nTo participate, users deposit supported assets (wrapped aTokens or GHO) into the appropriate StakeToken contract. This action mints shares representing their position. The StakeToken uses an exchange rate that starts at 1:1 and only decreases if slashing occurs.\nStaking can be performed with a standard ERC20 approve and deposit, or with EIP-2612 permit signature using depositWithPermit. Users may also set a cooldown operator to manage their cooldowns.\nIERC20 underlying = IERC20(stakeToken.asset());underlying.approve(address(stakeToken), amount);stakeToken.deposit(amount, msg.sender);\nUnstaking#\nTo withdraw, users must first activate a cooldown by calling cooldown(). The cooldown period is 20 days (configurable by governance), followed by a 2-day unstake window. During cooldown, rewards continue to accrue and funds remain slashable. Only one cooldown record is allowed per user at a time. If a user transfers shares after activating cooldown, the amount available for withdrawal is reduced. Depositing more after cooldown does not affect the cooldowned amount.\nAfter the cooldown period, users can withdraw within the unstake window using redeem or withdraw. If the window is missed, the cooldown must be restarted. Withdrawals are always subject to the current exchange rate, which may have changed due to slashing.\nstakeToken.cooldown();// ...wait for cooldown period...stakeToken.redeem(shares, msg.sender, msg.sender);\nSlashing#\nSlashing is triggered automatically by UmbrellaCore when a deficit in the corresponding Aave pool exceeds the configured offset. Slashing reduces total assets in the StakeToken, lowering the value of all shares. The contract enforces a minimum assets floor to prevent full depletion. Only UmbrellaCore (the owner) can call slash, and slashed assets are sent to the Aave Collector for deficit coverage.\nfunction slash(uint256 amount) external onlyOwner;\nRewards#\nRewards are managed by the RewardsController, which supports up to 8 reward tokens per StakeToken. Emission rates are governed by a piecewise linear curve, targeting optimal liquidity. Below the target liquidity, rewards are boosted to attract stakers; at target, emission is maximized; above target, emission tapers off to discourage over-staking. Governance sets up new assets and rewards, while a Rewards Admin can adjust emission rates and distribution end times.\nUsers can claim all available rewards for their assets at any time, or authorize a claimer to do so on their behalf.\nrewardsController.claimAllRewards([address(stakeToken)], msg.sender);\nTo claim a specific reward:\nrewardsController.claimRewards( [address(stakeToken)], amount, msg.sender, rewardToken);\nTo set a claimer:\nrewardsController.setClaimer(user, claimer);\nDeployed Contracts#\nNameAddressUMBRELLA0xD400fc38ED4732893174325693a63C30ee3881a8UMBRELLA_IMPL0x929e21D24D3f2A529621AdC248D227012B72646dUMBRELLA_STAKE_TOKEN_IMPL0x75e8aC0c063B6966E2A9954adEdf39BdE9370197UMBRELLA_REWARDS_CONTROLLER0x4655Ce3D625a63d30bA704087E52B4C31E38188BUMBRELLA_REWARDS_CONTROLLER_IMPL0x85C3371044e49782DbE3dC23de1D77a078aFb5d0PERMISSIONED_PAYLOADS_CONTROLLER0xF86F77F7531B3374274E3f725E0A81D60bC4bB67PERMISSIONED_PAYLOADS_CONTROLLER_EXECUTOR0x2759de67aD133C747C9f41d56F1b8A343cE679a1UMBRELLA_BATCH_HELPER0xCe6Ced23118EDEb23054E06118a702797b13fc2FUMBRELLA_CONFIG_ENGINE0x3f3EfAeba02bbA78BA7E89Dc6Ec503C8fe5fd5a4DATA_AGGREGATION_HELPER0xcc8FD820B1b9C5EBACA8615927f2fFc1f74B9dB3DEFICIT_OFFSET_CLINIC_STEWARD0x6c1DC85f2aE71C3DAcd6E44Bb57DEeF61b540a5AAAVE0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9AAVE_ORACLE0x547a514d5e3769680Ce22B2361c10Ea13619e8a9STK_AAVE0x4da27a545c0c5B758a6BA100e3a049001de870f5GHO0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2fGHO_ORACLE0x3f12643d3f6f874d39c2a4c9f2cd6f2dbac877fcSTK_GHO0x1a88Df1cFe15Af22B3c4c783D4e6F7F9e0C1885dSTK_AAVE_WSTETH_BALANCER_POOL_V20x9eDA81C21C273a82BE9Bbc19B6A6182212068101STK_AAVE_WSTETH_BALANCER_POOL_V2_ORACLE0xADf86b537eF08591c2777E144322E8b0Ca7E82a7STK_AAVE_WSTETH_BALANCER_POOL_V2_MIGRATOR0xecD4bd3121F9FD604ffaC631bF6d41ec12f1fafbSTK_AAVE_ETH_BALANCER_POOL_V1 (deprecated)0xa1116930326D21fB917d5A27F1E9943A9595fb47STK_AAVE_ETH_BALANCER_POOL_V1 (deprecated)0x209Ad99bd808221293d03827B86cC544bcA0023b\nResources#\nSmart ContractsFrontend ImplemenationPreviousTesting & DebuggingNextAave Horizon","tokens":2675,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260021896,"hash":"93dd7005e93505eb94e6eafff1106f0eb221bf6d"}
{"url":"https://eips.ethereum.org/EIPS/eip-2124","domain":"eips.ethereum.org","title":"EIP-2124: Fork identifier for chain compatibility checks","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-2124: Fork identifier for chain compatibility checks\n\n Authors\n Péter Szilágyi <peterke@gmail.com>, Felix Lange <fjl@ethereum.org>\n\n Created\n 2019-05-03\n\n Simple Summary\n\nCurrently nodes in the Ethereum network try to find each other by establishing random connections to remote machines “looking” like an Ethereum node (public networks, private networks, test networks, etc), hoping that they found a useful peer (same genesis, same forks). This wastes time and resources, especially for smaller networks.\n\nTo avoid this overhead, Ethereum needs a mechanism that can precisely identify whether a node will be useful, as early as possible. Such a mechanism requires a way to summarize chain configurations, as well as a way to disseminate said summaries in the network.\n\nThis proposal focuses only on the definition of said summary - a generally useful fork identifier - and it’s validation rules, allowing it to be embedded into arbitrary network protocols (e.g. discovery ENRs or eth/6x handshakes).\n\n Abstract\n\nThere are many public and private Ethereum networks, but the discovery protocol doesn’t differentiate between them. The only way to check if a peer is good or bad (same chain or not), is to establish a TCP/IP connection, wrap it with RLPx cryptography, then execute an eth handshake. This is an extreme cost to bear if it turns out that the remote peer is on a different network and it’s not even precise enough to differentiate Ethereum and Ethereum Classic. This cost is magnified for small networks, where a lot more trial and errors are needed to find good nodes.\n\nEven if the peer is on the same chain, during non-controversial consensus upgrades, not everybody updates their nodes in time (developer nodes, leftovers, etc). These stale nodes put a meaningless burden on the peer-to-peer network, since they just latch on to good nodes, but don’t accept upgraded blocks. This causes valuable peer slots and bandwidth to be lost until the stale nodes finally update. This is a serious issue for test networks, where leftovers can linger for months.\n\nThis EIP proposes a new identity scheme to both precisely and concisely summarize the chain’s current status (genesis and all applied forks). The conciseness is particularly important to make the identity useful across datagram protocols too. The EIP solves a number of issues:\n\n If two nodes are on different networks, they should never even consider connecting.\n If a hard fork passes, upgraded nodes should reject non-upgraded ones, but NOT before.\n If two chains share the same genesis, but not forks (ETH / ETC), they should reject each other.\n\nThis EIP does not attempt to solve the clean separation of 3-way-forks! If at the same future block number, the network splits into three (non-fork, fork-A and fork-B), separating the forkers from each another will need case-by-case special handling. Not handling this keeps the proposal pragmatic, simple and also avoids making it too easy to fork off mainnet.\n\nTo keep the scope limited, this EIP only defines the identity scheme and validation rules. The same scheme and algorithm can be embedded into various networking protocols, allowing both the eth/6x handshake to be more precise (Ethereum vs. Ethereum Classic); as well as the discovery to be more useful (reject surely peers without ever connecting).\n\n Motivation\n\nPeer-to-peer networking is messy and hard due to firewalls and network address translation (NAT). Generally only a small fraction of nodes have publicly routed addresses and P2P networks rely mainly on these for forwarding data for everyone else. The best way to maximize the utility of the public nodes is to ensure their resources aren’t wasted on tasks that are worthless to the network.\n\nBy aggressively cutting off incompatible nodes from each other we can extract a lot more value from the public nodes, making the entire P2P network much more robust and reliable. Supporting this network partitioning at a discovery layer can further enhance performance as we avoid the costly crypto and latency/bandwidth hit associated with establishing a stream connection in the first place.\n\n Specification\n\nEach node maintains the following values:\n\n FORK_HASH: IEEE CRC32 checksum ([4]byte) of the genesis hash and fork blocks numbers that already passed.\n\n The fork block numbers are fed into the CRC32 checksum in ascending order.\n If multiple forks are applied at the same block, the block number is checksummed only once.\n Block numbers are regarded as uint64 integers, encoded in big endian format when checksumming.\n If a chain is configured to start with a non-Frontier ruleset already in its genesis, that is NOT considered a fork.\n\n FORK_NEXT: Block number (uint64) of the next upcoming fork, or 0 if no next fork is known.\n\nE.g. FORK_HASH for mainnet would be:\n\n forkhash₀ = 0xfc64ec04 (Genesis) = CRC32(<genesis-hash>)\n forkhash₁ = 0x97c2c34c (Homestead) = CRC32(<genesis-hash> || uint64(1150000))\n forkhash₂ = 0x91d1f948 (DAO fork) = CRC32(<genesis-hash> || uint64(1150000) || uint64(1920000))\n\nThe fork identifier is defined as RLP([FORK_HASH, FORK_NEXT]). This forkid is cross validated (NOT naively compared) to assess a remote chain’s compatibility. Irrespective of fork state, both parties must come to the same conclusion to avoid indefinite reconnect attempts from one side.\n\n Validation rules\n\n 1) If local and remote FORK_HASH matches, compare local head to FORK_NEXT.\n\n The two nodes are in the same fork state currently. They might know of differing future forks, but that’s not relevant until the fork triggers (might be postponed, nodes might be updated to match).\n\n 1a) A remotely announced but remotely not passed block is already passed locally, disconnect, since the chains are incompatible.\n 1b) No remotely announced fork; or not yet passed locally, connect.\n\n 2) If the remote FORK_HASH is a subset of the local past forks and the remote FORK_NEXT matches with the locally following fork block number, connect.\n\n Remote node is currently syncing. It might eventually diverge from us, but at this current point in time we don’t have enough information.\n\n 3) If the remote FORK_HASH is a superset of the local past forks and can be completed with locally known future forks, connect.\n\n Local node is currently syncing. It might eventually diverge from the remote, but at this current point in time we don’t have enough information.\n\n 4) Reject in all other cases.\n\n Stale software examples\n\nThe examples below try to exhaust the fork combination possibilities that arise when nodes do not run matching software versions, but otherwise follow the same chain (mainnet nodes, testnet nodes, etc).\n\n Past forks\n Future forks\n Head\n Remote FORK_HASH\n Remote FORK_NEXT\n Connect\n Reason\n\n A\n\n A\n\n Yes (1b)\n Same forks, same sync state.\n\n A\n\n < B\n A\n B\n Yes (1b)\n Remote is advertising a future fork, but that is uncertain.\n\n A\n\n >= B\n A\n B\n No (1a)\n Remote is advertising a future fork that passed locally.\n\n A\n B\n\n A\n\n Yes (1b)\n Local knows about a future fork, but that is uncertain.\n\n A\n B\n\n A\n B\n Yes (1b)\n Both know about a future fork, but that is uncertain.\n\n A\n B1\n < B2\n A\n B2\n Yes (1b)\n Both know about differing future forks, but those are uncertain.\n\n A\n B1\n >= B2\n A\n B2\n No (1a)\n Both know about differing future forks, but the remote one passed locally.\n\n [A,B]\n\n A\n B\n Yes (2)\n Remote out of sync.\n\n [A,B,C]\n\n A\n B\n Yes¹ (2)\n Remote out of sync. Remote will need a software update, but we don’t know it yet.\n\n A\n B\n\n A ⊕ B\n\n Yes (3)\n Local out of sync.\n\n A\n B,C\n\n A ⊕ B\n\n Yes (3)\n Local out of sync. Local also knows about a future fork, but that is uncertain yet.\n\n A\n\n A ⊕ B\n\n No (4)\n Local needs software update.\n\n A\n B\n\n A ⊕ B ⊕ C\n\n No² (4)\n Local needs software update.\n\n [A,B]\n\n A\n\n No (4)\n Remote needs software update.\n\nNote, there’s one asymmetry in the table, marked with ¹ and ². Since we don’t have access to a remote node’s future fork list (just the next one), we can’t detect that it’s software is stale until it syncs up. This is acceptable as 1) the remote node will disconnect from us anyway, and 2) this is a temporary fluke during sync, not permanent with a leftover node.\n\n Rationale\n\n Why flatten FORK_HASH into 4 bytes? Why not share the entire genesis and fork list?\n\nWhilst the eth devp2p protocol permits arbitrarily much data to be transmitted, the discovery protocol’s total space allowance for all ENR entries is 300 bytes.\n\nReducing the FORK_HASH into a 4 bytes checksum ensures that we leave ample room in the ENR for future extensions; and 4 bytes is more than enough for arbitrarily many Ethereum networks from a (practical) collision perspective.\n\n Why use IEEE CRC32 as the checksum instead of Keccak256?\n\nWe need a mechanism that can flatten arbitrary data into 4 bytes, without ignoring any of the input. Any other checksum or hashing algorithm would work, but since nodes can lie at any time, there’s no value in cryptographic hash functions.\n\nInstead of just taking the first 4 bytes of a Keccak256 hash (seems odd) or XOR-ing all the 4-byte groups (messy), CRC32 is a better alternative, as this is exactly what it was designed for. IEEE CRC32 is also used by ethernet, gzip, zip, png, etc, so every programming language support should not be a problem.\n\n We’re not using FORK_NEXT for much, can’t we get rid of it somehow?\n\nWe need to be able to differentiate whether a remote node is out of sync or whether its software is stale. Sharing only the past forks cannot tell us if the node is legitimately behind or stuck.\n\n Why advertise only one next fork, instead of “hashing” all known future ones like the FORK_HASH?\n\nOpposed to past forks that have already passed (for us locally) and can be considered immutable, we don’t know anything about future ones. Maybe we’re out of sync or maybe the fork didn’t pass yet. If it didn’t pass yet, it might be postponed, so enforcing it would split the network apart. It could also happen that we’re not yet aware of all future forks (haven’t updated our software in a while).\n\n Backwards Compatibility\n\nThis EIP only defines an identity scheme, it does not define functional changes.\n\n Test Cases\n\nHere’s a full suite of tests for all possible fork IDs that Mainnet, Ropsten, Rinkeby and Görli can advertise given the Petersburg fork cap (time of writing).\n\ntype testcase struct {\n head uint64\n want ID\n}\ntests := []struct {\n config *params.ChainConfig\n genesis common.Hash\n cases []testcase\n}{\n // Mainnet test cases\n {\n params.MainnetChainConfig,\n params.MainnetGenesisHash,\n []testcase{\n {0, ID{Hash: 0xfc64ec04, Next: 1150000}}, // Unsynced\n {1149999, ID{Hash: 0xfc64ec04, Next: 1150000}}, // Last Frontier block\n {1150000, ID{Hash: 0x97c2c34c, Next: 1920000}}, // First Homestead block\n {1919999, ID{Hash: 0x97c2c34c, Next: 1920000}}, // Last Homestead block\n {1920000, ID{Hash: 0x91d1f948, Next: 2463000}}, // First DAO block\n {2462999, ID{Hash: 0x91d1f948, Next: 2463000}}, // Last DAO block\n {2463000, ID{Hash: 0x7a64da13, Next: 2675000}}, // First Tangerine block\n {2674999, ID{Hash: 0x7a64da13, Next: 2675000}}, // Last Tangerine block\n {2675000, ID{Hash: 0x3edd5b10, Next: 4370000}}, // First Spurious block\n {4369999, ID{Hash: 0x3edd5b10, Next: 4370000}}, // Last Spurious block\n {4370000, ID{Hash: 0xa00bc324, Next: 7280000}}, // First Byzantium block\n {7279999, ID{Hash: 0xa00bc324, Next: 7280000}}, // Last Byzantium block\n {7280000, ID{Hash: 0x668db0af, Next: 0}}, // First and last Constantinople, first Petersburg block\n {7987396, ID{Hash: 0x668db0af, Next: 0}}, // Today Petersburg block\n },\n },\n // Ropsten test cases\n {\n params.TestnetChainConfig,\n params.TestnetGenesisHash,\n []testcase{\n {0, ID{Hash: 0x30c7ddbc, Next: 10}}, // Unsynced, last Frontier, Homestead and first Tangerine block\n {9, ID{Hash: 0x30c7ddbc, Next: 10}}, // Last Tangerine block\n {10, ID{Hash: 0x63760190, Next: 1700000}}, // First Spurious block\n {1699999, ID{Hash: 0x63760190, Next: 1700000}}, // Last Spurious block\n {1700000, ID{Hash: 0x3ea159c7, Next: 4230000}}, // First Byzantium block\n {4229999, ID{Hash: 0x3ea159c7, Next: 4230000}}, // Last Byzantium block\n {4230000, ID{Hash: 0x97b544f3, Next: 4939394}}, // First Constantinople block\n {4939393, ID{Hash: 0x97b544f3, Next: 4939394}}, // Last Constantinople block\n {4939394, ID{Hash: 0xd6e2149b, Next: 6485846}}, // First Petersburg block\n {6485845, ID{Hash: 0xd6e2149b, Next: 6485846}}, // Last Petersburg block\n {6485846, ID{Hash: 0x4bc66396, Next: 0}}, // First Istanbul block\n {7500000, ID{Hash: 0x4bc66396, Next: 0}}, // Future Istanbul block\n },\n },\n // Rinkeby test cases\n {\n params.RinkebyChainConfig,\n params.RinkebyGenesisHash,\n []testcase{\n {0, ID{Hash: 0x3b8e0691, Next: 1}}, // Unsynced, last Frontier block\n {1, ID{Hash: 0x60949295, Next: 2}}, // First and last Homestead block\n {2, ID{Hash: 0x8bde40dd, Next: 3}}, // First and last Tangerine block\n {3, ID{Hash: 0xcb3a64bb, Next: 1035301}}, // First Spurious block\n {1035300, ID{Hash: 0xcb3a64bb, Next: 1035301}}, // Last Spurious block\n {1035301, ID{Hash: 0x8d748b57, Next: 3660663}}, // First Byzantium block\n {3660662, ID{Hash: 0x8d748b57, Next: 3660663}}, // Last Byzantium block\n {3660663, ID{Hash: 0xe49cab14, Next: 4321234}}, // First Constantinople block\n {4321233, ID{Hash: 0xe49cab14, Next: 4321234}}, // Last Constantinople block\n {4321234, ID{Hash: 0xafec6b27, Next: 5435345}}, // First Petersburg block\n {5435344, ID{Hash: 0xafec6b27, Next: 5435345}}, // Last Petersburg block\n {5435345, ID{Hash: 0xcbdb8838, Next: 0}}, // First Istanbul block\n {6000000, ID{Hash: 0xcbdb8838, Next: 0}}, // Future Istanbul block\n },\n },\n // Goerli test cases\n {\n params.GoerliChainConfig,\n params.GoerliGenesisHash,\n []testcase{\n {0, ID{Hash: 0xa3f5ab08, Next: 1561651}}, // Unsynced, last Frontier, Homestead, Tangerine, Spurious, Byzantium, Constantinople and first Petersburg block\n {1561650, ID{Hash: 0xa3f5ab08, Next: 1561651}}, // Last Petersburg block\n {1561651, ID{Hash: 0xc25efa5c, Next: 0}}, // First Istanbul block\n {2000000, ID{Hash: 0xc25efa5c, Next: 0}}, // Future Istanbul block\n },\n },\n}\n\nHere’s a suite of tests of the different states a Mainnet node might be in and the different remote fork identifiers it might be required to validate and decide to accept or reject:\n\ntests := []struct {\n head uint64\n id ID\n err error\n}{\n // Local is mainnet Petersburg, remote announces the same. No future fork is announced.\n {7987396, ID{Hash: 0x668db0af, Next: 0}, nil},\n\n // Local is mainnet Petersburg, remote announces the same. Remote also announces a next fork\n // at block 0xffffffff, but that is uncertain.\n {7987396, ID{Hash: 0x668db0af, Next: math.MaxUint64}, nil},\n\n // Local is mainnet currently in Byzantium only (so it's aware of Petersburg), remote announces\n // also Byzantium, but it's not yet aware of Petersburg (e.g. non updated node before the fork).\n // In this case we don't know if Petersburg passed yet or not.\n {7279999, ID{Hash: 0xa00bc324, Next: 0}, nil},\n\n // Local is mainnet currently in Byzantium only (so it's aware of Petersburg), remote announces\n // also Byzantium, and it's also aware of Petersburg (e.g. updated node before the fork). We\n // don't know if Petersburg passed yet (will pass) or not.\n {7279999, ID{Hash: 0xa00bc324, Next: 7280000}, nil},\n\n // Local is mainnet currently in Byzantium only (so it's aware of Petersburg), remote announces\n // also Byzantium, and it's also aware of some random fork (e.g. misconfigured Petersburg). As\n // neither forks passed at neither nodes, they may mismatch, but we still connect for now.\n {7279999, ID{Hash: 0xa00bc324, Next: math.MaxUint64}, nil},\n\n // Local is mainnet Petersburg, remote announces Byzantium + knowledge about Petersburg. Remote\n // is simply out of sync, accept.\n {7987396, ID{Hash: 0xa00bc324, Next: 7280000}, nil},\n\n // Local is mainnet Petersburg, remote announces Spurious + knowledge about Byzantium. Remote\n // is definitely out of sync. It may or may not need the Petersburg update, we don't know yet.\n {7987396, ID{Hash: 0x3edd5b10, Next: 4370000}, nil},\n\n // Local is mainnet Byzantium, remote announces Petersburg. Local is out of sync, accept.\n {7279999, ID{Hash: 0x668db0af, Next: 0}, nil},\n\n // Local is mainnet Spurious, remote announces Byzantium, but is not aware of Petersburg. Local\n // out of sync. Local also knows about a future fork, but that is uncertain yet.\n {4369999, ID{Hash: 0xa00bc324, Next: 0}, nil},\n\n // Local is mainnet Petersburg. remote announces Byzantium but is not aware of further forks.\n // Remote needs software update.\n {7987396, ID{Hash: 0xa00bc324, Next: 0}, ErrRemoteStale},\n\n // Local is mainnet Petersburg, and isn't aware of more forks. Remote announces Petersburg +\n // 0xffffffff. Local needs software update, reject.\n {7987396, ID{Hash: 0x5cddc0e1, Next: 0}, ErrLocalIncompatibleOrStale},\n\n // Local is mainnet Byzantium, and is aware of Petersburg. Remote announces Petersburg +\n // 0xffffffff. Local needs software update, reject.\n {7279999, ID{Hash: 0x5cddc0e1, Next: 0}, ErrLocalIncompatibleOrStale},\n\n // Local is mainnet Petersburg, remote is Rinkeby Petersburg.\n {7987396, ID{Hash: 0xafec6b27, Next: 0}, ErrLocalIncompatibleOrStale},\n\n // Local is mainnet Petersburg, far in the future. Remote announces Gopherium (non existing fork)\n // at some future block 88888888, for itself, but past block for local. Local is incompatible.\n //\n // This case detects non-upgraded nodes with majority hash power (typical Ropsten mess).\n {88888888, ID{Hash: 0x668db0af, Next: 88888888}, ErrLocalIncompatibleOrStale},\n\n // Local is mainnet Byzantium. Remote is also in Byzantium, but announces Gopherium (non existing\n // fork) at block 7279999, before Petersburg. Local is incompatible.\n {7279999, ID{Hash: 0xa00bc324, Next: 7279999}, ErrLocalIncompatibleOrStale},\n}\n\nHere’s a couple of tests to verify the proper RLP encoding (since FORK_HASH is a 4 byte binary but FORK_NEXT is an 8 byte quantity):\n\ntests := []struct {\n id ID\n want []byte\n}{\n {\n ID{Hash: 0, Next: 0},\n common.Hex2Bytes(\"c6840000000080\"),\n },\n {\n ID{Hash: 0xdeadbeef, Next: 0xBADDCAFE},\n common.Hex2Bytes(\"ca84deadbeef84baddcafe\"),\n },\n {\n ID{Hash: math.MaxUint32, Next: math.MaxUint64},\n common.Hex2Bytes(\"ce84ffffffff88ffffffffffffffff\"),\n },\n}\n\n Implementation\n\nGeth: https://github.com/ethereum/go-ethereum/tree/master/core/forkid\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Péter Szilágyi <peterke@gmail.com>, Felix Lange <fjl@ethereum.org>, \"EIP-2124: Fork identifier for chain compatibility checks,\" Ethereum Improvement Proposals, no. 2124, May 2019. Available: https://eips.ethereum.org/EIPS/eip-2124.","tokens":4680,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260029752,"hash":"0be5858661c50c0bd9a4d83d192383c98d7d4b24"}
{"url":"https://ethresear.ch/c/data-structure/30","domain":"ethresear.ch","title":"Latest Data Structure topics - Ethereum Research","text":"Latest topics in Data Structure\n\n Data Structure\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Data Structure category\n\n 0\n\n 1.3k\n\n Apr 2019\n\n LazyTower: An O(1) Replacement for Incremental Merkle Trees\n\n 2\n\n 660\n\n Feb 2025\n\n Interpreting MPT branch node values\n\n 0\n\n 168\n\n Aug 2024\n\n Portal Network & Verkle\n\n stateless\n\n 0\n\n 1.8k\n\n Apr 2024\n\n ERA - archival files for block and consensus data\n\n 0\n\n 2.8k\n\n Feb 2024\n\n Distributing Ethereum State over Portal Network\n\n stateless\n\n 2\n\n 1.1k\n\n Dec 2023\n\n Compact Fraud Proofs for UTXO Chains Without Intermediate State Serialization\n\n fraud-proofs\n\n 6\n\n 7.5k\n\n Jun 2023\n\n Merkle tree with O(1) append\n\n zk-roll-up\n\n 0\n\n 3.0k\n\n Feb 2023\n\n Merkle multi proofs for computationally constrained environments\n\n 0\n\n 987\n\n Jan 2023\n\n Optimizing sparse Merkle trees\n\n sparse-merkle-tree,data-structure\n\n 29\n\n 27.2k\n\n Jan 2022\n\n Efficient On-Chain Dynamic Merkle Tree\n\n 0\n\n 4.3k\n\n Oct 2021\n\n A nearly-trivial-on-zero-inputs 32-bytes-long collision-resistant hash function\n\n sparse-merkle-tree\n\n 33\n\n 8.3k\n\n Feb 2021\n\n An optimized compacted sparse merkle tree without pre-calculated hashes\n\n sparse-merkle-tree\n\n 3\n\n 3.2k\n\n Jan 2021\n\n Quadrable: Sparse merkle tree database in C++ and Solidity, git-like command-line tool\n\n sparse-merkle-tree\n\n 2\n\n 2.7k\n\n Oct 2020\n\n Unbalanced Merkle trees with compact multi-proofs for updating, inferring indices, and appending, simultaneously\n\n data-structure,sparse-merkle-tree\n\n 2\n\n 2.0k\n\n Sep 2020\n\n A two-layer account trie inside a single-layer trie\n\n 4\n\n 4.1k\n\n Mar 2020\n\n Storing (almost) all contract state on Swarm INSTEAD of the Blockchain\n\n 4\n\n 1.9k\n\n Jan 2020\n\n ERC-2350 Semantic contracts (ERC extension - draft)\n\n 0\n\n 1.2k\n\n Jan 2020\n\n ETh2, authenticated data structures, and gas costs\n\n 6\n\n 2.6k\n\n Dec 2019\n\n Deterministic ABIs\n\n 4\n\n 2.2k\n\n Sep 2019\n\n Simpler hash-efficient sparse tree\n\n sparse-merkle-tree\n\n 16\n\n 4.7k\n\n Jul 2019\n\n Optimizing Merkle tree multi-queries\n\n data-structure\n\n 9\n\n 6.5k\n\n Feb 2019\n\n Powered by Discourse","tokens":521,"squid":"ink-research","role":"Deep Scholar","at":1791260033371,"hash":"19793b968a2473eb8c211f828e126fcd192f11bf"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/acl-manager","domain":"aave.com","title":"ACL Manager | Aave Protocol Documentation","text":"ACLManager#\nThe Access Control List Manager (ACLManager) is the main registry of system roles and permissions.\nThe Aave Protocol implements an access control list to segregate powers and/or benefits that can be allocated to different entities on the protocol. The ACL_MANAGER contract is managed by the PoolAddressesProvider contract.\nACLManager keeps track of the individual roles and its holders, and allows a Role Admin to manage roles. Role Admin is itself a role that is managed by the DEFAULT_ADMIN_ROLE.\nThe DEFAULT_ADMIN_ROLE is held by the ACL_ADMIN, and should be initialized in the PoolAddressesProvider beforehand.\nThe source code is available on GitHub.\nRoles#\nBelow we outline the responsibilities/powers of the roles and the specific methods that are only accessible to the holders of these roles.\nThe FLASH_BORROWER and BRIDGE roles have few direct responsibilities and can primarily access specific features of the protocol, while ADMIN roles have the power and responsibility to handle risk or configuration parameters.\nFLASH_BORROWER#\nHolders of this role will have the premium on flash loans waived (this does not include the simple flash loan).\nMethods Accessible:#\nPool:\nflashLoan()\nASSET_LISTING_ADMIN#\nHolders of this role can:\nUpdate asset oracle sources and the fallback oracle.Add new assets to the Aave market.\nMethods Accessible:#\nAaveOracle:\nsetAssetSources()setFallbackOracle()\nPoolConfigurator:\ninitReserves()\nRISK_ADMIN#\nHolders of this role can:\nUpdate the grace period of Oracle Sentinels.Update reserve parameters such as reserve factor, caps, E-Mode category, borrowing enabled, freeze/unfreeze, LTV, liquidation threshold, liquidation bonus (cannot pause/unpause or activate/deactivate a reserve).Create new and update existing E-Mode categories (not category 0).Update unbacked mint cap and liquidation protocol fee.\nMethods Accessible:#\nPoolConfigurator:\nsetReserveBorrowing()configureReserveAsCollateral()setReserveFreeze()setBorrowableInIsolation()setReserveFactor()setDebtCeiling()setSiloedBorrowing()setBorrowCap()setSupplyCap()setLiquidationProtocolFee()setEModeCategory()setAssetCollateralInEMode()setUnbackedMintCap()setReserveInterestRateStrategyAddress()setReserveInterestRateData()disableLiquidationGracePeriod()setReserveFlashLoaning()\nPriceOracleSentinel:\nsetGracePeriod()\nACL_ADMIN#\nHolders of this role manage the role admins in the ACLManager. The DEFAULT_ADMIN_ROLE is held by the ACL_ADMIN, and should be initialized in the PoolAddressesProvider beforehand.\nMethods Accessible:#\nACLManager:\nsetRoleAdmin()addPoolAdmin()removePoolAdmin()addEmergencyAdmin()removeEmergencyAdmin()addRiskAdmin()removeRiskAdmin()addFlashBorrower()removeFlashBorrower()addBridge()removeBridge()addAssetListingAdmin()removeAssetListingAdmin()\nEMERGENCY_ADMIN#\nHolders of this role can pause and unpause the pool or an individual reserve.\nMethods Accessible:#\nPoolConfigurator:\nsetReservePause()setPoolPause()setReserveActive()setReserveFreeze()\nPOOL_ADMIN#\nHolders of this role can update token implementations, drop, (un)pause and (de)activate reserves, update premiums along with everything the ASSET_LISTING_ADMIN and RISK_ADMIN can do.\nAll deployers have resigned their POOL_ADMIN roles. All instances of the POOL_ADMIN role, across all v3 networks, are now governed by the [Guardians multisig] or by the Governance Bridge executors.\nMethods Accessible:#\nAll methods accessible to ASSET_LISTING_ADMIN.\nAll methods accessible to RISK_ADMIN.\nAToken:\nrescueTokens()\nPool:\nrescueTokens()\nIncentivizedERC20:\nsetIncentivesController()\nPoolConfigurator:\ndropReserve()updateAToken()updateVariableDebtToken()setReserveActive()updateBridgeProtocolFee()updateFlashloanPremiumTotal()updateFlashloanPremiumToProtocol()setAssetBorrowableInEMode()setReserveInterestRateData()setReserveInterestRateStrategyAddress()\nPriceOracleSentinel:\nsetSequencerOracle()\nWrite Methods#\nsetRoleAdmin#\nfunction setRoleAdmin(bytes32 role, bytes32 adminRole) external override onlyRole(DEFAULT_ADMIN_ROLE)\nSets the role as admin of a specific role. By default, the adminRole for all roles is DEFAULT_ADMIN_ROLE.\nThis method can only be called by an address with\nDEFAULT_ADMIN_ROLE.\nInput Parameters:#\nNameTypeDescriptionrolebytes32The role to be managed by the admin role - keccak256 hash of one of the following: POOL_ADMIN, EMERGENCY_ADMIN, RISK_ADMIN, FLASH_BORROWER, BRIDGE, ASSET_LISTING_ADMINadminRolebytes32The admin role. 0x00 is reserved for the DEFAULT_ADMIN_ROLE\naddPoolAdmin#\nfunction addPoolAdmin(address admin) external override\nAdds a new admin as Pool Admin. The address is added to the list of members with the POOL_ADMIN role. Holders of this role can update token implementations, drop, (un)pause and (de)activate reserves, update premiums and do everything the ASSET_LISTING_ADMIN and RISK_ADMIN can do.\nThis method can only be called by the Role Admin, specified by Aave\nGovernance, responsible for managing the POOL_ADMIN\nrole.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address which will be granted the POOL_ADMIN role\nremovePoolAdmin#\nfunction removePoolAdmin(address admin) external override\nRemoves an admin as Pool Admin. The given address is removed from the list of members with the POOL_ADMIN role.\nThis method can only be called by the Role Admin, specified by Aave\nGovernance, responsible for managing the POOL_ADMIN\nrole.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address for which the POOL_ADMIN role permissions will be removed\naddEmergencyAdmin#\nfunction addEmergencyAdmin(address admin) external override\nAdds a new admin as an Emergency Admin. The address is added to the list of members with the EMERGENCY_ADMIN role. Holders of this role can pause and unpause the pool or an individual reserve.\nThis method can only be called by the Role Admin, specified by Aave\nGovernance, responsible for managing the\nEMERGENCY_ADMIN role.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address which will be granted the EMERGENCY_ADMIN role\nremoveEmergencyAdmin#\nfunction removeEmergencyAdmin(address admin) external override\nRemoves an admin as Emergency Admin. The given address is removed from the list of members with the EMERGENCY_ADMIN role.\nThis method can only be called by the Role Admin, specified by Aave\nGovernance, responsible for managing the\nEMERGENCY_ADMIN role.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address for which the EMERGENCY_ADMIN role permissions will be removed\naddRiskAdmin#\nfunction addRiskAdmin(address admin) external override\nAdds a new admin as a Risk Admin. The address is added to the list of members with the RISK_ADMIN role. Holders of this role can update grace period of Oracle Sentinels, reserve params, unbacked mint cap, liquidation fee and eMode categories.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address which will be granted the RISK_ADMIN role\nremoveRiskAdmin#\nfunction removeRiskAdmin(address admin) external override\nRemoves an admin as Risk Admin. The given address is removed from the list of members with the RISK_ADMIN role.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address for which the RISK_ADMIN role permissions will be removed\naddFlashBorrower#\nfunction addFlashBorrower(address borrower) external override\nAdds a new borrower address as Flash Borrower. The address is added to the list of members with the FLASH_BORROWER role. Holders of this role do not pay premium for flash loan (does not apply to flashLoanSimple).\nInput Parameters:#\nNameTypeDescriptionborroweraddressThe address which will be granted the FLASH_BORROWER role\nremoveFlashBorrower#\nfunction removeFlashBorrower(address borrower) external override\nRemoves an admin as Flash Borrower. The given borrower address is removed from the list of members with the FLASH_BORROWER role.\nInput Parameters:#\nNameTypeDescriptionborroweraddressThe address for which the FLASH_BORROWER role permissions will be removed\naddAssetListingAdmin#\nfunction addAssetListingAdmin(address admin) external override\nAdds a new admin as Asset Listing Admin. The address is added to the list of members with the ASSET_LISTING_ADMIN role. Holder of this role can update oracles and add new assets to the Aave market.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address which will be granted ASSET_LISTING_ADMIN role\nremoveAssetListingAdmin#\nfunction removeAssetListingAdmin(address admin) external override\nRemoves an admin as Asset Listing Admin. The given address is removed from the list of members with the ASSET_LISTING_ADMIN role.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address for which ASSET_LISTING_ADMIN role permissions will be removed\nView Methods#\nisPoolAdmin#\nfunction isPoolAdmin(address admin) external view override returns (bool)\nReturns true if the address has the POOL_ADMIN role, false otherwise.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address to check\nReturn Values:#\nTypeDescriptionbooltrue if the given address is POOL_ADMIN, false otherwise\nisEmergencyAdmin#\nfunction isEmergencyAdmin(address admin) external view override returns (bool)\nReturns true if the address has the EMERGENCY_ADMIN role, false otherwise.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address to check\nReturn Values:#\nTypeDescriptionbooltrue if the given address is EMERGENCY_ADMIN, false otherwise\nisRiskAdmin#\nfunction isRiskAdmin(address admin) external view override returns (bool)\nReturns true if the address has the RISK_ADMIN role, false otherwise.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address to check\nReturn Values:#\nTypeDescriptionbooltrue if the given address is RISK_ADMIN, false otherwise\nisFlashBorrower#\nfunction isFlashBorrower(address borrower) external view override returns (bool)\nReturns true if the address has the FLASH_BORROWER role, false otherwise.\nInput Parameters:#\nNameTypeDescriptionborroweraddressThe address to check\nReturn Values:#\nTypeDescriptionbooltrue if the given address is FLASH_BORROWER, false otherwise\nisBridge#\nfunction isBridge(address bridge) external view override returns (bool)\nReturns true if the address has BRIDGE role, false otherwise.\nInput Parameters:#\nNameTypeDescriptionbridgeaddressThe address to check\nReturn Values:#\nTypeDescriptionbooltrue if the given address is BRIDGE, false otherwise\nisAssetListingAdmin#\nfunction isAssetListingAdmin(address admin) external view override returns (bool)\nReturns true if the address has the ASSET_LISTING_ADMIN role, false otherwise.\nInput Parameters:#\nNameTypeDescriptionadminaddressThe address to check\nReturn Values:#\nTypeDescriptionbooltrue if the given address is ASSET_LISTING_ADMIN, false otherwisePreviousInterest Rate StrategyNextOracles","tokens":2677,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260033467,"hash":"6909c0fcb7ad86fdf5ad888a5b329789f664e8f7"}
{"url":"https://eips.ethereum.org/EIPS/eip-778","domain":"eips.ethereum.org","title":"EIP-778: Ethereum Node Records (ENR)","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-778: Ethereum Node Records (ENR)\n\n Authors\n Felix Lange <fjl@ethereum.org>\n\n Created\n 2017-11-23\n\n Abstract\n\nThis EIP defines Ethereum Node Records, an open format for p2p connectivity information.\n\n Motivation\n\nEthereum nodes discover each other through the node discovery protocol. The purpose of\nthat protocol is relaying node identity public keys (on the secp256k1 curve), their IP\naddress and two port numbers. No other information can be relayed.\n\nThis specification seeks to lift the restrictions of the discovery v4 protocol by defining\na flexible format, the node record, for connectivity-related information. Node records\ncan be relayed through a future version of the node discovery protocol. They can also be\nrelayed through arbitrary other mechanisms such as DNS, ENS, a devp2p subprotocol, etc.\n\nNode records improve cryptographic agility and handling of protocol upgrades. A record can\ncontain information about arbitrary transport protocols and public key material associated\nwith them.\n\nAnother goal of the new format is to provide authoritative updates of connectivity\ninformation. If a node changes its endpoint and publishes a new record, other nodes should\nbe able to determine which record is newer.\n\n Specification\n\nThe components of a node record are:\n\n signature: cryptographic signature of record contents\n seq: The sequence number, a 64-bit unsigned integer. Nodes should increase the number\n whenever the record changes and republish the record.\n The remainder of the record consists of arbitrary key/value pairs\n\nA record’s signature is made and validated according to an identity scheme. The identity\nscheme is also responsible for deriving a node’s address in the DHT.\n\nThe key/value pairs must be sorted by key and must be unique, i.e. any key may be present\nonly once. The keys can technically be any byte sequence, but ASCII text is preferred. Key\nnames in the table below have pre-defined meaning.\n\n Key\n Value\n\n id\n name of identity scheme, e.g. “v4”\n\n secp256k1\n compressed secp256k1 public key, 33 bytes\n\n ip\n IPv4 address, 4 bytes\n\n tcp\n TCP port, big endian integer\n\n udp\n UDP port, big endian integer\n\n ip6\n IPv6 address, 16 bytes\n\n tcp6\n IPv6-specific TCP port, big endian integer\n\n udp6\n IPv6-specific UDP port, big endian integer\n\nAll keys except id are optional, including IP addresses and ports. A record without\nendpoint information is still valid as long as its signature is valid. If no tcp6 /\nudp6 port is provided, the tcp / udp port applies to both IP addresses. Declaring\nthe same port number in both tcp, tcp6 or udp, udp6 should be avoided but doesn’t\nrender the record invalid.\n\n RLP Encoding\n\nThe canonical encoding of a node record is an RLP list of [signature, seq, k, v, ...].\nThe maximum encoded size of a node record is 300 bytes. Implementations should reject\nrecords larger than this size.\n\nRecords are signed and encoded as follows:\n\ncontent = [seq, k, v, ...]\nsignature = sign(content)\nrecord = [signature, seq, k, v, ...]\n\n Text Encoding\n\nThe textual form of a node record is the base64 encoding of its RLP representation,\nprefixed by enr:. Implementations should use the URL-safe base64 alphabet\nand omit padding characters.\n\n “v4” Identity Scheme\n\nThis specification defines a single identity scheme to be used as the default until other\nschemes are defined by further EIPs. The “v4” scheme is backwards-compatible with the\ncryptosystem used by Node Discovery v4.\n\n To sign record content with this scheme, apply the keccak256 hash function (as used by\nthe EVM) to content, then create a signature of the hash. The resulting 64-byte\nsignature is encoded as the concatenation of the r and s signature values (the\nrecovery ID v is omitted).\n To verify a record, check that the signature was made by the public key in the\n“secp256k1” key/value pair of the record.\n To derive a node address, take the keccak256 hash of the uncompressed public key.\n\n Rationale\n\nThe format is meant to suit future needs in two ways:\n\n Adding new key/value pairs: This is always possible and doesn’t require implementation\nconsensus. Existing clients will accept any key/value pairs regardless of whether they\ncan interpret their content.\n Adding identity schemes: these need implementation consensus because the network won’t\naccept the signature otherwise. To introduce a new identity scheme, propose an EIP and\nget it implemented. The scheme can be used as soon as most clients accept it.\n\nThe size of a record is limited because records are relayed frequently and may be included\nin size-constrained protocols such as DNS. A record containing a IPv4 address, when signed\nusing the “v4” scheme occupies roughly 120 bytes, leaving plenty of room for additional\nmetadata.\n\nYou might wonder about the need for so many pre-defined keys related to IP addresses and\nports. This need arises because residential and mobile network setups often put IPv4\nbehind NAT while IPv6 traffic—if supported—is directly routed to the same host. Declaring\nboth address types ensures a node is reachable from IPv4-only locations and those\nsupporting both protocols.\n\n Test Vectors\n\nThis is an example record containing the IPv4 address 127.0.0.1 and UDP port 30303.\nThe node ID is a448f24c6d18e575453db13171562b71999873db5b286df957af199ec94617f7.\n\nenr:-IS4QHCYrYZbAKWCBRlAy5zzaDZXJBGkcnh4MHcBFZntXNFrdvJjX04jRzjzCBOonrkTfj499SZuOh8R33Ls8RRcy5wBgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQPKY0yuDUmstAHYpMa2_oxVtw0RW_QAdpzBQA8yWM0xOIN1ZHCCdl8\n\nThe record is signed using the “v4” identity scheme using sequence number 1 and this\nprivate key:\n\nb71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291\n\nThe RLP structure of the record is:\n\n[\n 7098ad865b00a582051940cb9cf36836572411a47278783077011599ed5cd16b76f2635f4e234738f30813a89eb9137e3e3df5266e3a1f11df72ecf1145ccb9c,\n 01,\n \"id\",\n \"v4\",\n \"ip\",\n 7f000001,\n \"secp256k1\",\n 03ca634cae0d49acb401d8a4c6b6fe8c55b70d115bf400769cc1400f3258cd3138,\n \"udp\",\n 765f,\n]\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Felix Lange <fjl@ethereum.org>, \"EIP-778: Ethereum Node Records (ENR),\" Ethereum Improvement Proposals, no. 778, November 2017. Available: https://eips.ethereum.org/EIPS/eip-778.","tokens":1564,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260041045,"hash":"da58f4c1ad8f98b8008bd65b4372a64d16ac4b4f"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/pool-configurator","domain":"aave.com","title":"Pool Configurator | Aave Protocol Documentation","text":"Pool Configurator#\nThe PoolConfigurator contract implements the configuration methods for the Aave Protocol. The 'write methods' below are grouped by permissioned system roles that are managed by ACLManager.\nThe source code is available on GitHub.\nWrite Methods#\nOnly Asset Listing Or Pool Admins Methods#\ninitReserves#\nfunction initReserves(ConfiguratorInputTypes.InitReserveInput[] calldata input) external override onlyAssetListingOrPoolAdmins\nInitializes multiple reserves using the array of initialization parameters as input.\nInput Parameters:#\nNameTypeDescriptioninputConfiguratorInputTypes.InitReserveInput[]The array of initialization parameters\nThe ConfiguratorInputTypes.InitReserveInput[] struct is composed of the following fields:\nNameTypeDescriptionaTokenImpladdressThe address of the aToken contract implementationvariableDebtTokenImpladdressThe address of the variable debt token contractuseVirtualBalancebooltrue if reserve is utilising virtual balance accountinginterestRateStrategyAddressaddressThe address of the interest rate strategy contract for this reserveunderlyingAssetaddressThe address of the underlying assettreasuryaddressThe address of the treasuryincentivesControlleraddressThe address of the incentives controller for this aTokenaTokenNamestringThe name of the aTokenaTokenSymbolstringThe symbol of the aTokenvariableDebtTokenNamestringThe name of the variable debt tokenvariableDebtTokenSymbolstringThe symbol of the variable debt tokenparamsbytesA set of encoded parameters for additional initializationinterestRateDatabytesEncoded interest rate strategy data\nOnly Emergency Admin Methods#\nsetPoolPause#\nfunction setPoolPause(bool paused) external override onlyEmergencyOrPoolAdmin\nPauses or unpauses all the protocol reserves. In the paused state all the protocol interactions are suspended.\nInput Parameters:#\nNameTypeDescriptionpausedbooltrue if the protocol needs to be paused, otherwise false\nOnly Emergency Or Pool Admin Methods#\nsetReservePause#\nfunction setReservePause(address asset, bool paused) public override onlyEmergencyOrPoolAdmin\nPauses a reserve. A paused reserve does not allow any interaction (supply, borrow, repay, liquidate, atoken transfers).\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservepausedbooltrue if pausing the reserve, false if unpausing the reserve\nOnly Pool Admin Methods#\ndropReserve#\nfunction dropReserve(address asset) external override onlyPoolAdmin\nDrops a reserve entirely.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the reserve to drop\nupdateAToken#\nfunction updateAToken(ConfiguratorInputTypes.UpdateATokenInput calldata input) external override onlyPoolAdmin\nUpdates the aToken implementation for the reserve. Takes the aToken update parameters as input.\nInput Parameters:#\nNameTypeDescriptioninputConfiguratorInputTypes.UpdateATokenInputThe aToken update parameters\nThe ConfiguratorInputTypes.UpdateATokenInput struct is composed of the following fields:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservetreasuryaddressThe address of the treasuryincentivesControlleraddressThe address of the incentives controller for this aTokennamestringThe name of the aTokensymbolstringThe symbol of the aTokenimplementationaddressThe new aToken implementationparamsbytesA set of encoded parameters for additional initialization\nupdateVariableDebtToken#\nfunction updateVariableDebtToken(ConfiguratorInputTypes.UpdateDebtTokenInput calldata input) external override onlyPoolAdmin\nInput Parameters:#\nNameTypeDescriptioninputConfiguratorInputTypes.UpdateDebtTokenInputThe variableDebtToken update parameters\nThe ConfiguratorInputTypes.UpdateDebtTokenInput struct is composed of the following fields:\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveincentivesControlleraddressThe address of the incentives controller for this variableDebtTokennamestringThe name of the variableDebtTokensymbolstringThe symbol of the variableDebtTokenimplementationaddressThe new variableDebtToken implementationparamsbytesA set of encoded parameters for additional initialization\nsetReserveActive#\nfunction setReserveActive(address asset, bool active) external override onlyPoolAdmin\nActivate or deactivate a reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveactivebooltrue if the reserve needs to be active, false otherwise\nupdateBridgeProtocolFee#\nfunction updateBridgeProtocolFee(uint256 newBridgeProtocolFee) external override onlyPoolAdmin\nUpdates the bridge fee collected by the protocol reserves.\nInput Parameters:#\nNameTypeDescriptionnewBridgeProtocolFeeuint256The part of the fee sent to the protocol treasury, expressed in bps\nsetReserveFlashLoaning#\nfunction setReserveFlashLoaning(address asset, bool enabled) external override onlyRiskOrPoolAdmins\nEnables or disables flash loans for a reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressAddress of the reserve assetenabledbooltrue to enable, false to disable\nupdateFlashloanPremiumTotal#\nfunction updateFlashloanPremiumTotal(uint128 newFlashloanPremiumTotal) external override onlyPoolAdmin\nUpdates the total flash loan premium. The premium is calculated on the total amount borrowed, and is expressed in bps.\nThe total flash loan premium consists of two parts:\nA part is sent to aToken holders as extra balance, andA part is collected by the protocol reserves.\nInput Parameters:#\nNameTypeDescriptionnewFlashloanPremiumTotaluint128The total flashloan premium\nupdateFlashloanPremiumToProtocol#\nfunction updateFlashloanPremiumToProtocol(uint128 newFlashloanPremiumToProtocol) external override onlyPoolAdmin\nUpdates the flash loan premium collected by protocol reserves. The premium to protocol is calculated on the total flashloan premium, and is expressed in bps.\nInput Parameters:#\nNameTypeDescriptionnewFlashloanPremiumToProtocoluint128The part of the flashloan premium sent to the protocol treasury\nOnly Risk Or Pool Admins Methods#\nsetReserveBorrowing#\nfunction setReserveBorrowing(address asset, bool enabled) external override onlyRiskOrPoolAdmins\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveenabledbooltrue if borrowing needs to be enabled, false otherwise\nconfigureReserveAsCollateral#\nfunction configureReserveAsCollateral( address asset, uint256 ltv, uint256 liquidationThreshold, uint256 liquidationBonus) external override onlyRiskOrPoolAdmins\nConfigures the reserve collateralization parameters. All the values are expressed in bps. A value of 10000 results in 100.00%. The liquidationBonus is always above 100%. A value of 105% means the liquidator will receive a 5% bonus.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveltvuint256The loan to value of the asset when used as collateralliquidationThresholduint256The threshold at which loans using this asset as collateral will be considered undercollateralizedliquidationBonusuint256The bonus liquidators receive to liquidate this asset\nsetReserveFreeze#\nfunction setReserveFreeze(address asset, bool freeze) external override onlyRiskOrPoolAdmins\nFreeze or unfreeze a reserve. A frozen reserve doesn't allow any new supply or borrow but allows repayments, liquidations, rate rebalances and withdrawals.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservefreezebooltrue if the reserve needs to be frozen, false otherwise\nsetBorrowableInIsolation#\nfunction setBorrowableInIsolation(address asset, bool borrowable) external override onlyRiskOrPoolAdmins\nSets the borrowable in isolation flag for the reserve. When this flag is set to true, the asset will be borrowable against isolated collaterals and the borrowed amount will be accumulated in the isolated collateral's total debt exposure. Only assets of the same family (e.g. USD stablecoins) should be borrowable in isolation mode to keep consistency in the debt ceiling calculations.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserveborrowablebooltrue if the asset should be borrowable in isolation, false otherwise\nsetReserveFactor#\nfunction setReserveFactor(address asset, uint256 newReserveFactor) external override onlyRiskOrPoolAdmins\nUpdates the reserve factor of a reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewReserveFactoruint256The new reserve factor of the reserve\nsetDebtCeiling#\nfunction setDebtCeiling(address asset, uint256 newDebtCeiling) external override onlyRiskOrPoolAdmins\nSets the debt ceiling for an asset.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewDebtCeilinguint256The new debt ceiling\nsetSiloedBorrowing#\nfunction setSiloedBorrowing(address asset, bool newSiloed) external override onlyRiskOrPoolAdmins\nSets siloed borrowing for an asset\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewSiloedboolThe new siloed borrowing state - enable or disable siloed borrowing for the reserve\nsetBorrowCap#\nfunction setBorrowCap(address asset, uint256 newBorrowCap) external override onlyRiskOrPoolAdmins\nUpdates the borrow cap of a reserve. Allows RISK_ADMIN and POOL_ADMIN to add/update cap on the total borrow that can be borrowed from the reserve. Once the borrow cap is reached, no more borrow positions for the given reserve asset can be initiated.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewBorrowCapuint256The new borrow cap of the reserve in whole tokens. A borrow cap of 0 signifies that there is no cap\nsetSupplyCap#\nfunction setSupplyCap(address asset, uint256 newSupplyCap) external override onlyRiskOrPoolAdmins\nUpdates the supply cap of a reserve. Allows RISK_ADMIN and POOL_ADMIN to add/update liquidity supply cap on the reserve. Once the supply cap is reached, no more liquidity for the given reserve asset can be supplied to the pool.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewSupplyCapuint256The new supply cap of the reserve in whole tokens. A supply cap of 0 signifies that there is no cap\ndisableLiquidationGracePeriod#\nfunction disableLiquidationGracePeriod(address asset) external override onlyEmergencyOrPoolAdmin\nDisables the liquidation grace period for a reserve.\nInput Parameters#\nNameTypeDescriptionassetaddressAddress of the reserve asset\nsetLiquidationProtocolFee#\nfunction setLiquidationProtocolFee(address asset, uint256 newFee) external override onlyRiskOrPoolAdmins\nUpdates the liquidation protocol fee of reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewFeeuint256The new liquidation protocol fee of the reserve, expressed in bps\nsetEModeCategory#\nfunction setEModeCategory( uint8 categoryId, uint16 ltv, uint16 liquidationThreshold, uint16 liquidationBonus, string calldata label) external override onlyRiskOrPoolAdmins\nAdds a new efficiency mode (eMode) category. Allows RISK_ADMIN and POOL_ADMIN to configure existing or add new eModeCategory\nIf zero is provided as oracle address, the default asset oracles will be used to compute the overall debt and overcollateralization of the users using this category. The new ltv and liquidation threshold must be greater than the base ltvs and liquidation thresholds of all assets within the eMode category.\nInput Parameters:#\nNameTypeDescriptioncategoryIduint8The id of the category to be configured. categoryId ≠ 0. NOTE: category 0 is reserved for the default category i.e. non-eModeltvuint16The loan to value for the associated eMode category. It must be less than or equal to the liquidationThresholdliquidationThresholduint16The liquidation threshold associated with the categoryliquidationBonusuint16The liquidation bonus associated with the categorylabelstringA custom label identifying the category\nsetAssetCollateralInEMode#\nfunction setAssetCollateralInEMode(address asset, uint8 categoryId, bool allowed) external override onlyRiskOrPoolAdmins\nAssign collateral status to an asset for a particular efficiency mode (eMode) category. Allows RISK_ADMIN and POOL_ADMIN to configure eModeCategory of an asset.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservecategoryIduint8eMode category id to set asset collateral status forallowedbooltrue if asset is enabled as collateral in designated categoryId\nsetAssetBorrowableInEMode#\nfunction setAssetBorrowableInEMode(address asset, uint8 categoryId, bool borrowable) external override onlyRiskOrPoolAdmins\nConfigures if an asset can be borrowed in a specific eMode category.\nInput Parameters:#\nNameTypeDescriptionassetaddressAddress of the reserve assetcategoryIduint8eMode category IDborrowablebooltrue to enable, false to disable\nsetUnbackedMintCap#\nfunction setUnbackedMintCap(address asset, uint256 newUnbackedMintCap) external override onlyRiskOrPoolAdmins\nUpdates the unbacked mint cap of reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reservenewUnbackedMintCapuint256The new unbacked mint cap of the reserve\nsetReserveInterestRateData#\nfunction setReserveInterestRateData(address asset, bytes calldata rateData) external onlyRiskOrPoolAdmins\nSets custom interest rate parameters for a reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressAddress of the reserve assetrateDatabytesEncodes rate strategy parameters\nsetReserveInterestRateStrategyAddress#\nfunction setReserveInterestRateStrategyAddress(address asset, address rateStrategyAddress, bytes calldata rateData) external override onlyRiskOrPoolAdmins\nSets the interest rate strategy of a reserve.\nInput Parameters:#\nNameTypeDescriptionassetaddressThe address of the underlying asset of the reserverateStrategyAddressaddressThe address of the interest strategy contractrateDatabytesEncoded interst rate strategy data\nPure Methods#\ngetRevision#\nfunction getRevision() internal pure virtual override returns (uint256)\nReturns the revision number of the contract. Needs to be defined in the inherited class as a constant.\nReturns 0x1.\nReturn Values:#\nTypeDescriptionuint256The revision numberPreviousPool Addresses ProviderNextSwap Features","tokens":3618,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260046946,"hash":"f9b78804cca57e93b982735800ebb38c57b8f2b2"}
{"url":"https://aave.com/docs/mcp","domain":"aave.com","title":"Aave MCP | Aave Protocol Documentation","text":"Aave MCP#\nAave MCP gives AI agents a single interface to Aave v3 and v4. Compatible clients can discover markets, inspect positions, simulate protocol actions, and prepare transactions for a user's wallet to review and sign.\nServer endpoint: https://mcp.aave.com\nWhat You Can Do#\nExplore markets: Retrieve supported chains, reserves, available liquidity, protocol structure, and current or historical rates.Review positions: Inspect a wallet's supplies, borrows, health factor, activity, and rewards.Prepare actions: Simulate and build supply, borrow, withdraw, repay, collateral, reward, and liquidation transactions.Use specialized capabilities: Work with token swaps, Aave v4 hub data, Savings GHO, and Aave DAO governance data.\nSee the Tools reference for the complete tool inventory, parameters, and response schemas.\nAction Lifecycle#\nBuild actions in five stages.\nAave MCP never holds private keys or signs transactions. Action tools return an\nunsigned transaction or EIP-712 typed data for the user's wallet. For swaps,\nthe server can relay an order only after the user has signed it.\nDiscover: get_markets returns the reserve, narrowed with a symbols filter to the asset in question. The ids it returns are what every later stage takes.Inspect: get_reserve_details for rates, caps and risk parameters. get_user_summary for the wallet's position and health factor.Simulate: preview_action reports what the action would leave behind, and warns when it cannot succeed. Never skip it before a borrow or a withdraw.Build: prepare_action returns an unsigned transaction, preceded by an approval step where the token needs one.Sign: The user's wallet signs and submits. get_transaction_processed says when Aave has caught up, which is what a dependent follow-up should wait on.\nSafety#\nReads are side-effect-free and prepare_* tools commit nothing, so nothing moves until the user signs. Safety covers the guarantees, the warnings that stop an action, and the reserve flags that block some actions but not others.\nIntegrate Aave#\nQuick Start#\nEvery call is a tools/call with a tool name and its arguments. These are the params an agent sends, and Getting Started has the full request envelope.\nMarket DataAccount DataSupply{ \"name\": \"get_markets\", \"arguments\": { \"version\": \"all\", \"symbols\": [\"USDC\"] }}One call covers both versions and every chain each of them serves, and the result names those chains under chainsCovered.\nBuilding in code rather than through an agent? AaveKit covers the same operations.\nReactTypeScriptGraphQL\nBuilding On AavePreviousCredit DelegationNextGetting Started","tokens":648,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260057974,"hash":"32e4348d6b8a5e9085e31a962d86752f9491a4e3"}
{"url":"https://eips.ethereum.org/EIPS/eip-150","domain":"eips.ethereum.org","title":"EIP-150: Gas cost changes for IO-heavy operations","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-150: Gas cost changes for IO-heavy operations\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2016-09-24\n\n Meta reference\n\nTangerine Whistle.\n\n Parameters\n\n FORK_BLKNUM\n CHAIN_ID\n CHAIN_NAME\n\n 2,463,000\n 1\n Main net\n\n Specification\n\nIf block.number >= FORK_BLKNUM, then:\n\n Increase the gas cost of EXTCODESIZE to 700 (from 20).\n Increase the base gas cost of EXTCODECOPY to 700 (from 20).\n Increase the gas cost of BALANCE to 400 (from 20).\n Increase the gas cost of SLOAD to 200 (from 50).\n Increase the gas cost of CALL, DELEGATECALL, CALLCODE to 700 (from 40).\n Increase the gas cost of SELFDESTRUCT to 5000 (from 0).\n If SELFDESTRUCT hits a newly created account, it triggers an additional gas cost of 25000 (similar to CALLs).\n Increase the recommended gas limit target to 5.5 million.\n Define “all but one 64th” of N as N - floor(N / 64).\n If a call asks for more gas than the maximum allowed amount (i.e. the total amount of gas remaining in the parent after subtracting the gas cost of the call and memory expansion), do not return an OOG error; instead, if a call asks for more gas than all but one 64th of the maximum allowed amount, call with all but one 64th of the maximum allowed amount of gas (this is equivalent to a version of EIP-901 plus EIP-1142). CREATE only provides all but one 64th of the parent gas to the child call.\n\nThat is, substitute:\n\n extra_gas = (not ext.account_exists(to)) * opcodes.GCALLNEWACCOUNT + \\\n (value > 0) * opcodes.GCALLVALUETRANSFER\n if compustate.gas < gas + extra_gas:\n return vm_exception('OUT OF GAS', needed=gas+extra_gas)\n submsg_gas = gas + opcodes.GSTIPEND * (value > 0)\n\nWith:\n\n def max_call_gas(gas):\n return gas - (gas // 64)\n\n extra_gas = (not ext.account_exists(to)) * opcodes.GCALLNEWACCOUNT + \\\n (value > 0) * opcodes.GCALLVALUETRANSFER\n if compustate.gas < extra_gas:\n return vm_exception('OUT OF GAS', needed=extra_gas)\n if compustate.gas < gas + extra_gas:\n gas = min(gas, max_call_gas(compustate.gas - extra_gas))\n submsg_gas = gas + opcodes.GSTIPEND * (value > 0)\n\n Rationale\n\nRecent denial-of-service attacks have shown that opcodes that read the state tree are under-priced relative to other opcodes. There are software changes that have been made, are being made and can be made in order to mitigate the situation; however, the fact will remain that such opcodes will be by a substantial margin the easiest known mechanism to degrade network performance via transaction spam. The concern arises because it takes a long time to read from disk, and is additionally a risk to future sharding proposals as the “attack transactions” that have so far been most successful in degrading network performance would also require tens of megabytes to provide Merkle proofs for. This EIP increases the cost of storage reading opcodes to address this concern. The costs have been derived from an updated version of the calculation table used to generate the 1.0 gas costs: https://docs.google.com/spreadsheets/d/15wghZr-Z6sRSMdmRmhls9dVXTOpxKy8Y64oy9MvDZEQ/edit#gid=0; the rules attempt to target a limit of 8 MB of data that needs to be read in order to process a block, and include an estimate of 500 bytes for a Merkle proof for SLOAD and 1000 for an account.\n\nThis EIP aims to be simple, and adds a flat penalty of 300 gas on top of the costs calculated in this table to account for the cost of loading the code (~17–21 kb in the worst case).\n\nThe EIP 90 gas mechanic is introduced because without it, all current contracts that make calls would stop working as they use an expression like msg.gas - 40 to determine how much gas to make a call with, relying on the gas cost of calls being 40. Additionally, EIP 114 is introduced because, given that we are making the cost of a call higher and less predictable, we have an opportunity to do it at no extra cost to currently available guarantees, and so we also achieve the benefit of replacing the call stack depth limit with a “softer” gas-based restriction, thereby eliminating call stack depth attacks as a class of attack that contract developers have to worry about and hence increasing contract programming safety. Note that with the given parameters, the de-facto maximum call stack depth is limited to ~340 (down from ~1024), mitigating the harm caused by any further potential quadratic-complexity DoS attacks that rely on calls.\n\nThe gas limit increase is recommended so as to preserve the de-facto transactions-per-second processing capability of the system for average contracts.\n\n References\n\n EIP-90, https://github.com/ethereum/EIPs/issues/90\n EIP-114, https://github.com/ethereum/EIPs/issues/114\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-150: Gas cost changes for IO-heavy operations,\" Ethereum Improvement Proposals, no. 150, September 2016. Available: https://eips.ethereum.org/EIPS/eip-150.","tokens":1224,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260060527,"hash":"5d2a1c731ee4cea0ea1ceb3724e2abb5dd3e3d0b"}
{"url":"https://aave.com/docs/mcp/safety","domain":"aave.com","title":"Aave MCP Safety | Aave Protocol Documentation","text":"Safety#\nAave MCP reads live protocol data and builds transactions. It never signs them, and the user's wallet is the last gate before anything reaches a chain.\nNon-Custodial by Design#\nThe server holds no private keys and cannot move funds.Read tools are side-effect-free.A prepare_* tool returns an unsigned transaction, an approval step that comes first, or EIP-712 typed data to sign. None of it commits anything.Two tools change state. submit_signed_order relays an order the user has already signed, and cancel_order relays a signed cancellation. Neither can create or sign anything of its own.Signing happens in the user's wallet, on every version and every action.\nBecause building a transaction commits nothing, an agent needs no permission to\nbuild one. The useful pattern is to prepare it, state the action, the amounts\nand the resulting health factor, and let the user decide at the signature.\nWarnings That Stop an Action#\nA result may carry warnings, each with a level, a stable code, and a message. The levels are not interchangeable, and error is the one with teeth.\nLevelWhat to doerrorThe action cannot succeed as built. Stop, fix the arguments, or tell the user. Do not build or sign past it.warningThe action will succeed. Tell the user before they sign.infoContext worth passing on.\nSimulate Before Signing#\npreview_action reports what an action would leave behind, on either version, and commits nothing. Run it before a borrow or a withdraw, the two actions that move a position toward liquidation, and show the result next to the amount.\nA clean simulation means the position allows the action. It says nothing about token allowances, so an approval step can still be outstanding.\nReserve Flags Block Different Things#\nA status flag is not uniformly disqualifying, and treating it that way pushes a user away from actions they should be taking.\nFlagSupplyBorrowWithdrawRepayFrozenNoNoYesYesPausedNoNoNoNoSupply cap reachedNoYesYesYesBorrow cap reachedYesNoYesYes\nA frozen reserve still lets a position be unwound, so refusing a withdraw or a repay on one tells the user to abandon a position they should be closing. get_markets carries these flags along with the liquidity left, and only when set, so a row with none of them is not flagged. That is why a reserve should be ranked on a rate that can actually be entered rather than on APY alone.\nWhat a Supplier Is Exposed To#\nNone of the following shows up in a health factor, and the server returns the fields behind each one without ranking reserves by risk.\nSupplying puts tokens in a contract. A governance-approved reserve list is curation, not a guarantee.A quoted APY is the rate now, not a promise. It moves with utilization, and get_apy_history shows how far it has actually moved.Getting out is not always immediate. availableLiquidity is what can be pulled at this moment, so a high rate on a fully utilized reserve is a rate nobody exits quickly.A plain supply cannot be liquidated. Once it is collateral it can, and the liquidator takes a bonus out of it.Isolation mode on v3, or a low collateral factor, is the DAO pricing that asset as riskier.Reward and incentive rates are separate from the supply rate and can stop, so they are not part of the yield.\nAn Empty Result Is Not Always an Answer#\nA read names the chains it covered under chainsCovered, and what it skipped under chainsNotCovered. A chain under chainsNotServed is one this API holds no market on, so nothing there is a statement about the chain itself.\nThose fields matter most in the case that looks harmless. A wallet with no position on a chain and a chain that could not be read both come back with an empty list, and only the coverage fields tell them apart.\nSecurity Resources#\nUmbrellaNative coverage for bad debt.SecuritySecurity resources and audits.PreviousSkillsNextAAVE","tokens":958,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260068929,"hash":"1ca562bfd1226bf1202f70daf8a195a3ea8902e3"}
{"url":"https://ethresear.ch/t/the-future-of-state-part-1-oopsie-a-new-type-of-snap-sync-based-wallet-lightclient/23395","domain":"ethresear.ch","title":"The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient - Execution Layer Research - Ethereum Research","text":"The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient \n\n Execution Layer Research\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Nov 2025\n\n 1 / 11\n\n Nov 2025\n\n 4d ago\n\n post by CPerezz on Nov 3, 2025\n\n CPerezz\n\n Thanks @gballet @ihagopian and @weiihann for the reviews and discussions\n(O.o)psie\nOOPSIE (Opt-in Ownership of Partial State of Interest, Exclusively) turns wallets into tiny, proof-aware state clients: snap-sync-first-first reads, user-owned range sets, authenticity badges (data marked as authenticated via MPT proof), and finalized pre-sign checks—faster UX, better privacy, and fewer RPC crutches.\n\nThis article will showcase what we could do with this new snap-based client/wallet and the major issues that it showcases. From there, this will serve us as an introduction for the article that will touch on the deep state-related problems that ZKEVM and Partial Statefulness entail.\n\nWhy OOPSIE? - The Hidden Crisis in Ethereum’s Architecture\nToday’s Ethereum faces a paradox. While we celebrate decentralization, the reality is starkly different: RPC endpoints are scarce, expensive, and centralized. Users don’t hold their own data. Bootnodes are hammered with snap sync requests. Wallets are mere proxies to centralized services. And with ZKEVMs evolving rapidly, fewer nodes will be incentivized to hold and serve syncing of Ethereum’s ever-growing state.\nThe consequences are already visible:\n\nBuilder centralization: Builders produce 80-90% of Ethereum’s blocks, becoming the only entities holding full state after ZKEVMs.\nRPC dependency: Almost no full nodes serve public RPC. Users are entirely dependent on centralized providers\nPrivacy leakage: Every wallet query broadcasts user addresses to centralized services linking it to the user’s IP and behaviour patterns\nFragility: When major RPC providers go down, users lose access to their own assets\n\nAny state expiry proposal must confront this reality: no one holds their own data. This makes discussions about expired state academically interesting but practically painful.\nNot only that, with ZKEVMs further evolving, we will eventually get to a point, where less and less nodes will be incentivized to hold Ethereum’s ever-growing state. Thus arriving to a critical point where we might have a really hard time retrieving data.\nA change of paradigm - Let’s tackle the problem step by step\nInstead of trying to solve a massive problem with a single solution. Incurring into massive changes and involving never-ending discussions. We should adopt a smarter strategy.\nLet’s take a first small step towards changing the storage paradigm. What could happen if users stored the subset of state they’re interested on?\nThink about it. Nowadays, wallets are a mere RPC proxy. They don’t hold any data. And, thus, they’re just not participants of the network on any way or shape. They’re completelly dependent on centralized RPCs and wallet providers.\nWithout them, they’re merciless and lack any sovereignty over their data/wallet. Most of them only have their seed phrase. But without holding any data, they’re just a part of the problem of expiring state. Rather than a solution or at least, not an impediment.\nEven I’ve faced the issue of trying to pay a friend back for a dinnner with my wallet, and the RPC being down actually made it impossible for me to even know my balance or transact.\nBesides the philosophical aspect of it, users holding their data locally would cause quite some changes for several actors:\nRenewed wallet providers\n\nWallet providers would heavily alleviate the pressure on their RPCs (though this requires further investigation and i. Since wallets now hold data and can/will update state. Users are able to have a synced subset of ethereum’s state that is of their interest and update it themseleves.\nWallets would snap sync their range set at every startup. Getting not only the updated values but also the proofs for the ranges they’re interested on.\nFaster, offline-first experience (instant balance + nonce display).\nReduced privacy leakage: no need to broadcast every address to a single RPC provider.\nState marketplace participation strategies. Wallets can offload storage costs for redundancy on users in return of premium features for example.\nReduced freemium costs: Free tier users consume minimal resources\n\nBetter UX\n\nOffline-first basics: Instant balance + nonce + token holdings for recent activity. Compose transactions while offline and broadcast later.\n2–3s faster tx building: Pre-filled nonce/balance removes a blocking RPC round trip for most common sends/swaps.\nLower infra cost: Many read calls (balanceOf, nonce, token lists) are served locally. Your free tier goes further.\nBetter privacy posture: Fewer raw address queries. Marketable as a tangible privacy upgrade.\nResilience = fewer support tickets: Users aren’t bricked by a transient RPC outage.\n\nArchitecture & technical dive.\nLet’s be clear. We don’t need another grand rewrite. We need a small, sharp step that makes wallets faster, more private, and harder to brick when RPCs sneeze. That’s OOPSIE in hybrid mode: light-client for authenticity + snap synced subset state for UX. Everything else stays the same.\nNo forks. No heroics. No promises to “solve Ethereum.” Just a small incremental update.\nTLDR\nHybrid edge client inside the wallet:\n\nBlock headers: keep a thin, verified view of finalized headers. Use them as the anchor of truth.\nSnap synced subset state: store only the key-values the user cares about (balances, nonces, a few token/storage slots) with proofs.\nRPC for the rest (RPC IS OPTIONAL. The wallet can function without it): raw reads if needed and with proofs if you’ve got them. Always MPT-proved.\n\nNet effect: faster UI, offline-friendly basics, fewer blind calls, and a way to talk about state expiry without users paying the price.\nThe Range Set — What do we store\nA tiny list of exact keys the wallet will be stored locally with their proofs.\nA) Account meta (per address)\n\nbalance(address)\nnonce(address)\ncodeHash(address) (If we want to be able to simulateGas for example we need the actual code too). Same if you have a smart wallet.\n(storageRoot(address) is implicit if you track any storage slots)\n\nThese come from the account leaf/commitment itself.\nB) ERC balances (precise, verifiable)\n\nERC‑20 balanceOf(owner)\n\nKey = (token, owner) → slot = keccak(owner || baseSlot_balances) (OZ layout uses slot 0 for balances)\nValue = uint256\n\nERC‑721\n\nownerOf(tokenId) → slot = keccak(tokenId || baseSlot_owners) (often slot 0)\nbalanceOf(owner) → keccak(owner || baseSlot_balances) (often slot 1)\n\nERC‑1155 balanceOf(owner, id)\n\nNested mapping → keccak( owner || keccak(id || baseSlot) )\nValue = uint256\n\nC) Allowances & approvals (Probably overkill/ can be optional)\n\nERC‑20 allowance(owner, spender) → commonly keccak( spender || keccak(owner || baseSlot_allowances) )\nERC‑721\n\ngetApproved(tokenId) (per‑token)\nisApprovedForAll(owner, operator) (nested mapping)\n\nD) Selective storage slots (DeFi positions)\nPin a handful of slots that matter to the user:\n\nRouter allowances for swaps\nLP shares / staking balances\nCollateral and debt indexes\n\nRepresented as:\nSelectiveSlot {\n contract: address,\n slot?: bytes32, // exact 32‑byte slot\n preimage?: { parts: bytes[], hash: 'keccak256', nested?: true },\n abi?: { type: string, scale?: number } // optional decode hints\n}\n\nExample range sets\n\nMinimal (10–15 keys): account meta for the active address, 3 token balances (USDC/WETH/DAI), 1–2 allowances, 1–2 NFT bits, maybe one lending slot.\nActive DeFi (30–50 keys): 2–3 accounts, ~10 ERC‑20s, ~10 allowances, ~10 protocol slots, a few 1155 balances.\n\nHow the Pieces Fit\nUI ↔ Query Router ↔ OOPSIE Engine (WASM)\n ├─ Range Set Manager\n ├─ Snapsync Fetcher\n ├─ Proof Verifier\n ├─ Block Header Pipeline\n\nProviders (full nodes / snapshotters)\n ├─ JSON‑RPC\n └─ Proof/Multi‑proof endpoints\n\nSnap Sync — Pull What We Care About, With Proofs, Without RPCs\nCold start:\nUser picks range set\n │\n ▼\nPick target = latest finalized header H_f\n │\n ▼\nRequest Range with multiproof(keys, H_f) → {values, proofs} (via snap sync)\n │\n ▼\nVerify vs H_f → OK → store (value, proof, H_f)\n FAIL → discard & fallback\n\nWarm path (delta refresh):\n\nOn new finalized header, on send, or on schedule (Wi‑Fi/charging), refresh only what matters.\nHeuristics: keys touched by user since last header + anything past an age cap.\nWe can snap sync a lot more metadata related to previous txs like receiver/senders account data, past contract state-updates etc..\n\noopsie_snapsync_flow_labels_above_fix4_ready (1)980×480 3.57 KB\nTrie path (conceptual):\nstateRoot (from H_f)\n │\n [branch]\n / \\\nacct acct ...\n | \\\n meta storageRoot\n │\n [branch]── proofs only for the exact leaves we pin\n │\n storage leaf (slot)\n\nmultiproof_presign_final900×520 4.88 KB\n\nMinimal proof: only the account leaf and specific storage leaves (e.g., allowance, balanceOf) plus the branch nodes needed to recompute stateRoot@H_f.\n\nReading Data — Router Rules\noopsie_wallet_call_routing_legend_border1180×900 12.5 KB\n\nRouting matrix (what goes to Snap sync vs RPC)\n\nQuick map of common wallet calls, their primary path, and fallbacks.\n\nBucket\nExamples\nNeeds known leaf key?\nMempool needed?\nPrimary Path\nBadge\nFallback\n\nAccount meta\nbalance(A), nonce(A), codeHash(A)\nNo (account leaf is address-keyed)\nNo\nSnap sync (multiproof) vs safe head (UI) / finalized (pre-sign)\nVERIFIED\nRPC (UNVERIFIED) if Snap sync slow/unavailable\n\nKnown storage slot\nERC-20 balanceOf, allowance; ERC-721 ownerOf; ERC-1155 balanceOf\nYes\nNo\nSnap sync\nVERIFIED\nRPC (UNVERIFIED); optional bg-verify to upgrade\n\nDerived / ABI-known slot\ntotalSupply() when slot mapped\nOften yes\nNo\nSnap sync if slot mapped; else RPC → learn & cache slot\nVERIFIED (if snap sync) / UNVERIFIED (RPC)\nRPC now; snap sync later once mapped\n\nArbitrary eth_call\nrouter.getQuote(...), complex view\nNo\nNo\nRPC (needs EVM execution)\nUNVERIFIED (unless provider includes proof)\nOptional bg discovery of slots (advanced)\n\nGas/fee & pending\neth_feeHistory, maxPriorityFee\nNo\nYes\nRPC\nUNVERIFIED\n—\n\nEstimate gas / simulate\neth_estimateGas, dry-run\nNo\nOften\nRPC\nUNVERIFIED\n—\n\nLogs & receipts\neth_getLogs, getTransactionReceipt\nNo\nNo\nRPC (indexed history)\nUNVERIFIED\n—\n\nTracing / debug\ndebug_traceTx, callTracer\nNo\nNo\nRPC\nUNVERIFIED\n—\n\nWhy snap sync before RPC on a miss?\n\nAuthenticity: you get a Merkle multiproof back and can verify against your block header, turning reads into VERIFIED without trusting the provider.\n\nBatchability: router can batch multiple UI asks (balance, nonce, 3 token balances) into a single multiproof tied to one header → fewer round-trips and smaller total proof than N separate proofs.\n\nPrivacy: rotating snapshotters + header-anchored reads reduces repeated raw-address spam to a single RPC origin. Thus reducing traceability & footprint metadata.\n\nOffline-tolerant: cached proofs remain meaningful (badged STALE) without network.\n\nFor the avg. case, for ≤50 keys, a well-formed multiproof is on the order of tens of KB and verify in tens of ms on mobile. That often beats a handful of RPC calls + TLS + cold caches.\nThis should mean:\n\nWallets are happy (less RPC reliance).\nUsers are happy (Better UX and privacy).\nRPCs get alleviated (They serve only requests which need them 100% (history, mempool-related stuff, tx simulation etc..)\n\nThe uncomfortable part — who actually serves state?\nOOPSIE leans on snap sync/multiproofs for authenticity. Today, snap-serving nodes (public sync nodes, a few public Geth, Nethermind and Besu nodes) are already saturated. In a ZK-EVM world, validators don’t need full state to prove/verify, so the natural question is: who is incentivized to hold and serve state at all?\nNot validators. Not most solo builders (they’ll be squeezed between builders and provers).\nThat leaves two classes with any reason to carry state:\n\nBlock builders (especially under FOCIL-like regimes): They still need read access to build sensible blocks, but their business model is latency-sensitive, not “serve the world proofs.”\n\nRPC providers: Centralization pressure increases. Their bandwidth is already eaten by eth_call, logs, mempool gossip. Serving snap sync for free has negative ROI.\n\nIf that’s our future, we risk a vicious circle:\nfewer state holders → proofs harder to find → wallets fall back to RPC → RPCs get even more load → less appetite to run snap servers → even fewer state holders.\nAnd there’s a second sting: user-held leaves age into uselessness for revival if all you keep is the value. A hundred blocks later, your leaf without a decent witness (siblings/branches up to the root) can’t help rebuild anything. The user’s “local state” degenerates into a pretty cache entry with no recovery value.\nThe opposite arc: when state is served, expiry becomes tractable\nIf we push the ecosystem so that many actors are incentivized to hold and serve authenticated slices (snap sync/multiproof), the picture flips:\n\nAvailability scales with demand. Wallet demand for proofs turns into a predictable revenue line for anyone exposing multiproofs (dapps for their own contracts, RPCs with per-KB pricing, builder-adjacent caches).\n\nWitnesses become a commodity. Small, content-addressed witness bundles (account proof + storage proofs) circulate, users and apps keep witness-rich fragments (pieces of data + their proof), not just raw values.\n\nExpiry ≠ exile. When state is pruned, revival = fetch a bundle from multiple sources and check it against a header you already trust. No global archives needed, just enough overlapping witnesses.\n\nDecentralization by slicing. Nobody needs all state. Many parties can profitably hold and serve their slice (per-domain, per-contract, per-prefix). That’s real, emergent state sharding without protocol sharding.\n\nConclusion\nExpiry is only real if state is served. OOPSIE-like clients matter only if they can keep up-to-date & authenticated data for users. And, only, if they can do something with that data like reviving state!\nIf ZK-EVM decouples validation from holding state, the default gravity is RPC + builder centralization. In that world, state-expiry is theater: you can “expire” state on paper, but revival just means asking the same few RPCs for answers you can’t independently authenticate.\nOOPSIE flips the demand curve. By making wallets ask for multiproofs of named leaves and by showing authenticity in the UI, OOPSIE turns proof-backed state into a first-class product. That creates room for many actors—not just RPC oligopolies—to profitably hold and serve slices of state, which is exactly what makes expiry tractable. When witnesses are easy to get, expiry stops being a cliff and becomes “fetch a bundle, verify against a header, move on.”\nWhat can help to facilitate this?\n\nPartial RPC solutions where re-execution is not needed. And partial state-holding still allows for proof-serving & snapsync range-constrained serving.\nIncentive-based state-serving. Either via RPC or Snapsync.\nSnapsync needs to be updated to a design where ranges can be missing and it still finalizes.\n\nThe north star: don’t centralize re-execution; decentralize witness serving.\nNext, we will delve into the depths of partial stateful nodes and explore the broader challenges of a ZKEVM–based future for Ethereum’s state availability.\n\n The Future of State, Part 2: Beyond The Myth of Partial Statefulness & The Reality Of ZKEVMs\n\n 4\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n post by MicahZoltu on Nov 4, 2025\n\n MicahZoltu\n\nHow much disk space does the full USDC state consume? While I very much appreciate your desire to get down to the minimum size possible, I wonder if it is worth the effort compared to just grabbing the full state of tokens of interest. If the difference is a handful of bytes (plus all of the proofs) vs MBs (plus all of the proofs), it may make sense to just pull down the MBs since I think the proof sizes will be the same or smaller. If the full state for USDC token is GBs though, then selective balances would make more sense.\n\n Compression-based state expiry\n\n post by MicahZoltu on Nov 4, 2025\n\n MicahZoltu\n\nWhile I know no one listens to me when I shout this into the wind, events (aka “logs”) should not be used for long term storage. They should be used to notify chain followers of interesting things that occurred in a block. A light client that is following head can utilize events for this trustlessly without an RPC server.\nUse case:\n\nUser wants to make a payment to a friend from a mobile device.\nThe recipient opens their wallet and indicates that they are expecting a payment.\nThe sender opens their wallet and initiates the payment.\nThe recipient and sender’s devices both are following head looking for payment events to/from their account.\nWhen the transaction is mined, recipient is notified and balance in wallet is updated.\nWhen the transaction is mined, sender is notified and balance/nonce in wallet is updated.\nBoth devices continue to follow head until finality is reached (to ensure no reorg occurred).\n\n post by CPerezz on Nov 6, 2025\n\n CPerezz\n\nIndeed is more than 1GB. You can see that in 2024 it was already 1GB in How to Raise the Gas Limit, Part 1: State Growth - Paradigm (see Figure 2). On top of that you also should account that most revival mechanisms require proofs to revive expired data.\nSo if you want Oopsie to be useful, you also need to store all intermediate nodes from the root of USDC contract until the root.\nThis is further explored in The Future of State, Part 2: Beyond The Myth of Partial Statefulness & The Reality Of ZKEVMs - #4 by MicahZoltu where we get numbers of the data needed in order to serve proofs for a particular contract. (TLDR, it’s arround 10GBs).\n\nAs per this, I agree we can do better. Nevertheless, it doesn’t fix or address the core issues of Oopsie within the situation where Ethereum is going to be in a couple years.\n\n 2 months later\n\n post by Julian on Dec 23, 2025\n\n Julian\n\n Hey Carlos, thanks for the post!\nIf I understand correctly the idea is that light clients store the state and proofs the user is interested in. However, proofs need to be updated continuously as other parts of state change (as the authors of this post argued On the impossibility of stateless blockchains - a16z crypto). How would light clients ensure that they create proofs against the canonical state root? Are they expected to be constantly online or do they sync to the head of the chain when a user wants to send a transaction? If the light client syncs when the user wants to send a transaction, can we say anything how much transaction inclusion latency that would add?\n\n post by CPerezz on Dec 23, 2025\n\n CPerezz\n\n Hey! Thanks for reading this @Julian and good question BTW.\nThe idea here is to leverage snap-sync mechanisms that already exist today in most clients and work by default.\nInstead of needing to constantly keep proofs up-to-date, we can simply query the P2P network with a snapsync-request (technically we would be requesting a leaf rangeproof for only 1 leaf (or the few of interest we have)). And the network would get back at us with it (already synced at the top of the chain).\nThis, combined with the sync-commitee that lightclients use gives us P2P user-generated proofs for our data which we can verify at tip-of-the-chain height.\nLatency would be in the order ofms for less than 10 leaves. For arround 50 we are looking at <1s for sure. I can try to get you numbers on that if it’s needed \nWith that we can be sure that our data is valid at anytime and get a proof for it if ours is invalid and for some reason we need it.\nNotice that with statelessness and a heavily reduced count of full nodes serving these requests, this system might eventually collapse as the few nodes that remain would be overwhelmed with requests.\n\n post by Julian on Dec 23, 2025\n\n Julian\n\n Thanks @CPerezz! Who do you intend to be the providers of state in this model? Is the idea that regular users who also run OOPSIE wallets provide state that others can snap-sync to or are they more professional RPCs?\n\n post by CPerezz on Dec 23, 2025\n\n CPerezz\n\nThe whole idea is that as the network is today, any full node is a provider by default (as long as they support SnapSync (so Geth, Nethermind & Besu).\nSince snapsync requests are always served by default (even some RPC providers have them on).\nAnd the pairing is done via P2P network and enode obtention. So it’s decently well distributed (though not uniformally I’d assume).\nWallets can serve their leaves only, so they aren’t the provider on any way or shape. This is more of a way to serve RPC calls, own your data locally and also have a “TLS-like system” for data any wallet needs (RPCs don’t send proofs with the data they provide).\n\n post by YanAnghelp on Dec 25, 2025\n\n YanAnghelp\n\n The shortcomings observed today are not merely implementation artifacts, but rather symptoms of a structural flaw in the consensus design.\nIf consensus could be achieved in a round-isolated manner—without requiring access to global state or historical data—then, in principle, nodes would only need to store block hashes in order to verify the entire chain history.\nUnder such a model, the resource requirements for running a full node could be reduced to an extremely low level.\nOf course, this is not feasible for strongly consistent systems like monetary blockchains, but the main pressure today appears to be on the execution layer, which may not require the same level of strong consistency as money.\n\n 9 months later\n\n post by dryajov on Sep 14\n\n dryajov\n\n Very interesting. I just want to point out that a similar idea was tried years ago (circa 2018), by @hermanjunge , kumavis (Aaron Davis) and myself, at Metamask.\nThe core idea was to split the MPT trie based on prefixes called “slices” and publish the slices on a libp2p gossip layer. It worked surprisingly well despite the simplicity (I even have demo querying the gnosis contract balance, one of the largest storage tries back in the day - https://www.youtube.com/watch?v=NznEt_40qbQ). We had to hack geth to query the slices, but of course snap sync now gives us all the required protocol level endpoints out of the box so this is seems much more straightforward.\nAlso, this being a metamask effort meant we had to focus on the browser first.\nHowever, the nice thing about slices was that we could broadcast them over a gossip layer, which kept clients seeded without having to constantly query for new blocks. Eventually, we were planing on only propagating slice diffs but we never got that far.\nIn any case, I’m glad to see these ideas live on in one form or another. If interested checkout https://github.com/musteka-la/go-ethereum the modified geth and GitHub - musteka-la/kitsunet-js: the kitsunet js implementation · GitHub the client that propagates slices and intercepts EVM storage requests to subscribe to storage trie slices.\nIt would be nice to finally see something like this implemented in the major clients and wallets, if curious on the details, don’t hesitate to DM @CPerezz .\nCheers.\n\n 17 days later\n\n post by stkux 4 days ago\n\n stkux\n\n I really like the general direction: moving verification closer to the wallet and reducing the trust placed in RPC providers is something I strongly agree with.\nHowever, I wonder whether using Snap as the data/proof-serving layer creates a scalability and incentive problem that looks somewhat similar to what we experienced with LES.\nSnap is primarily a synchronization protocol. A node consumes resources from other peers while syncing, but eventually becomes a synced node itself and participates in the network. A wallet using Snap in the way proposed here would behave differently: it would continuously consume bandwidth, database I/O and state/proof-serving capacity without ever becoming a state-serving peer itself.\nAt small scale this may not matter and work well. But if millions of wallets adopted this model, wouldn’t Snap-serving nodes have a strong incentive to rate-limit or deprioritize these clients? In that sense, the wallets effectively become permanent consumers of a resource that was designed primarily for node synchronization.\nThe article already points in this direction when discussing the negative ROI of serving Snap for free and the need for incentive-based state serving. I think this raises an interesting architectural question:\nIf state/proof serving ultimately needs its own incentives, should it perhaps be separated from the P2P synchronization protocol altogether?\nThis is also the direction we have taken with colibri.stateless.\nColibri deliberately separates the roles of providing data/proofs and verifying them. A wallet or application does not need to trust any provider. A prover collects the required state, transaction, receipt or consensus proofs and returns a proof bundle, while the Colibri client verifies everything locally against a cryptographically verified root.\nThe important consequence is that the prover can be an economically sustainable service. It could be operated by an RPC provider, a wallet provider, a dApp, or another infrastructure provider. Clients can switch between provers because correctness does not depend on trusting them.\nConceptually:\nuntrusted prover → data + proofs → local verification\nrather than:\ntrusted RPC → data\nor potentially:\nP2P node → continuously serves wallet queries for free\nThis also allows the proof interface to be optimized specifically for wallet/application workloads: arbitrary requested state, compact multiproofs, execution witnesses, transaction/receipt proofs, etc., rather than adapting a synchronization protocol to become a long-term query protocol.\nIt would be interesting to understand how you envision the incentive model once Snap-based wallets reach significant scale. Do you expect ordinary Ethereum nodes to continue serving these requests, or do you ultimately expect specialized/incentivized state-serving nodes to emerge?\n\n Powered by Discourse","tokens":6514,"squid":"ink-research","role":"Deep Scholar","at":1791260077212,"hash":"1c9b8a54934dd87df276352464af5e1742b91b08"}
{"url":"https://aave.com/docs/mcp/skills","domain":"aave.com","title":"Aave MCP Skills | Aave Protocol Documentation","text":"Skills#\nA skill is a short procedure for one Aave flow, written for the model rather than for a person: which tools to call, in what order, and what a finished answer has to contain.\nAave publishes one skill per flow where the tool list alone tends to leave an agent a step short. Each is a single SKILL.md in the aave/skills repository.\nSkill Examples#\nsafe-transactionsDiscover, inspect, simulate, build, then hand over unsigned.yield-analysisCompare rates across chains and versions, against their recent range.deleverageLift a health factor by simulating every route, never estimating.account-activityA wallet's history, with the chains the feed actually covered.tx-confirmationConfirm what a signed transaction did by reading the position it left.\nHow a Client Gets Them#\nAs a plugin. The skills are bundled with the Aave MCP plugin, which also connects the client to https://mcp.aave.com. It is published to each provider's own marketplace, currently Claude Code and Cursor.\n/plugin marketplace add aave/skills/plugin install aave-mcp@aave\nFrom the repository. An agent that loads skills from a directory can take the SKILL.md files from aave/skills as they are.\nUsing a Skill#\nNothing has to be invoked by name.\nInstall the plugin, which connects the client to https://mcp.aave.com and loads the skills. Getting Started covers connecting a client on its own.Ask in plain language. \"Get my health factor up on Aave\", \"did my supply go through\". A client with skill support loads the matching procedure.Review and sign. Skills change which reads happen and what an answer covers. They grant nothing: every state change is still an unsigned transaction your own wallet approves, as described in Safety.\nContributing#\nThe skills are maintained in aave/skills. Proposals and corrections are welcome there.PreviousToolsNextSafety","tokens":458,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260078898,"hash":"5ce6f8c3c9c08097fdfd5c81dbacb0086c794845"}
{"url":"https://ethresear.ch/t/the-future-of-state-part-1-oopsie-a-new-type-of-snap-sync-based-wallet-lightclient/23395/11","domain":"ethresear.ch","title":"The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient - Execution Layer Research - Ethereum Research","text":"Execution Layer Research\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Nov 2025\n\n 11 / 11\n\n Oct 1\n\n 4d ago\n\n post by CPerezz on Nov 3, 2025\n\n post by MicahZoltu on Nov 4, 2025\n\n post by MicahZoltu on Nov 4, 2025\n\n post by CPerezz on Nov 6, 2025\n\n 2 months later\n\n post by Julian on Dec 23, 2025\n\n post by CPerezz on Dec 23, 2025\n\n post by Julian on Dec 23, 2025\n\n post by CPerezz on Dec 23, 2025\n\n post by YanAnghelp on Dec 25, 2025\n\n YanAnghelp\n\n The shortcomings observed today are not merely implementation artifacts, but rather symptoms of a structural flaw in the consensus design.\nIf consensus could be achieved in a round-isolated manner—without requiring access to global state or historical data—then, in principle, nodes would only need to store block hashes in order to verify the entire chain history.\nUnder such a model, the resource requirements for running a full node could be reduced to an extremely low level.\nOf course, this is not feasible for strongly consistent systems like monetary blockchains, but the main pressure today appears to be on the execution layer, which may not require the same level of strong consistency as money.\n\n 9 months later\n\n post by dryajov on Sep 14\n\n dryajov\n\n Very interesting. I just want to point out that a similar idea was tried years ago (circa 2018), by @hermanjunge , kumavis (Aaron Davis) and myself, at Metamask.\nThe core idea was to split the MPT trie based on prefixes called “slices” and publish the slices on a libp2p gossip layer. It worked surprisingly well despite the simplicity (I even have demo querying the gnosis contract balance, one of the largest storage tries back in the day - https://www.youtube.com/watch?v=NznEt_40qbQ). We had to hack geth to query the slices, but of course snap sync now gives us all the required protocol level endpoints out of the box so this is seems much more straightforward.\nAlso, this being a metamask effort meant we had to focus on the browser first.\nHowever, the nice thing about slices was that we could broadcast them over a gossip layer, which kept clients seeded without having to constantly query for new blocks. Eventually, we were planing on only propagating slice diffs but we never got that far.\nIn any case, I’m glad to see these ideas live on in one form or another. If interested checkout https://github.com/musteka-la/go-ethereum the modified geth and GitHub - musteka-la/kitsunet-js: the kitsunet js implementation · GitHub the client that propagates slices and intercepts EVM storage requests to subscribe to storage trie slices.\nIt would be nice to finally see something like this implemented in the major clients and wallets, if curious on the details, don’t hesitate to DM @CPerezz .\nCheers.\n\n 17 days later\n\n post by stkux 4 days ago\n\n stkux\n\n I really like the general direction: moving verification closer to the wallet and reducing the trust placed in RPC providers is something I strongly agree with.\nHowever, I wonder whether using Snap as the data/proof-serving layer creates a scalability and incentive problem that looks somewhat similar to what we experienced with LES.\nSnap is primarily a synchronization protocol. A node consumes resources from other peers while syncing, but eventually becomes a synced node itself and participates in the network. A wallet using Snap in the way proposed here would behave differently: it would continuously consume bandwidth, database I/O and state/proof-serving capacity without ever becoming a state-serving peer itself.\nAt small scale this may not matter and work well. But if millions of wallets adopted this model, wouldn’t Snap-serving nodes have a strong incentive to rate-limit or deprioritize these clients? In that sense, the wallets effectively become permanent consumers of a resource that was designed primarily for node synchronization.\nThe article already points in this direction when discussing the negative ROI of serving Snap for free and the need for incentive-based state serving. I think this raises an interesting architectural question:\nIf state/proof serving ultimately needs its own incentives, should it perhaps be separated from the P2P synchronization protocol altogether?\nThis is also the direction we have taken with colibri.stateless.\nColibri deliberately separates the roles of providing data/proofs and verifying them. A wallet or application does not need to trust any provider. A prover collects the required state, transaction, receipt or consensus proofs and returns a proof bundle, while the Colibri client verifies everything locally against a cryptographically verified root.\nThe important consequence is that the prover can be an economically sustainable service. It could be operated by an RPC provider, a wallet provider, a dApp, or another infrastructure provider. Clients can switch between provers because correctness does not depend on trusting them.\nConceptually:\nuntrusted prover → data + proofs → local verification\nrather than:\ntrusted RPC → data\nor potentially:\nP2P node → continuously serves wallet queries for free\nThis also allows the proof interface to be optimized specifically for wallet/application workloads: arbitrary requested state, compact multiproofs, execution witnesses, transaction/receipt proofs, etc., rather than adapting a synchronization protocol to become a long-term query protocol.\nIt would be interesting to understand how you envision the incentive model once Snap-based wallets reach significant scale. Do you expect ordinary Ethereum nodes to continue serving these requests, or do you ultimately expect specialized/incentivized state-serving nodes to emerge?\n\n Powered by Discourse","tokens":1424,"squid":"ink-research","role":"Deep Scholar","at":1791260087399,"hash":"9f32c87be6fd42c21536332a5b2c20161dbea682"}
{"url":"https://ethereum.org/start/","domain":"ethereum.org","title":"Start with crypto | ⁦ethereum.org⁩","text":"1 / 3Download a walletA wallet is an app that allows you to receive, send cryptocurrencies and manage your Ethereum account.I have a wallet.Coinbase Wallet (opens in a new tab)Get wallet (opens in a new tab)MEW wallet (opens in a new tab)Get wallet (opens in a new tab)Rainbow (opens in a new tab)Get wallet (opens in a new tab)Zerion Wallet (opens in a new tab)Get wallet (opens in a new tab)OneKey (opens in a new tab)Get wallet (opens in a new tab)I have a wallet.1 / 3Connect your walletYou can use your new wallet as a single account in all apps and projects on Ethereum. No separate accounts needed.1 / 3Let's use some appsIt's time to go onchain and benefit from the wide ecosystem of projects available to you.Explore moreFarcasterSOCIALSThe social and community platform of crypto.Go (opens in a new tab)AaveFINANCELend your tokens to earn interest and withdraw any time.Go (opens in a new tab)UniswapFINANCESwap your tokens for different ones globally.Go (opens in a new tab)OpenSeaCOLLECTIBLESBuy, sell, discover, and trade limited-edition goods.Go (opens in a new tab)Explore more","tokens":273,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260091252,"hash":"e1e43b9c593b59658bfbfc1322b18d637c87b703"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/api-hardhat-upgrades","domain":"docs.openzeppelin.com","title":"OpenZeppelin Hardhat Upgrades API | OpenZeppelin Docs","text":"Upgrades PluginsOpenZeppelin Hardhat Upgrades APIOpen in ClaudeThis is the documentation for Hardhat 3. For Hardhat 2, see the Hardhat Upgrades API docs (Hardhat 2).\nThis package works with both ethers and viem. By default it uses the ethers-based API; if you are using viem, import from @openzeppelin/hardhat-upgrades/viem. The options and validations documented below apply to both APIs. The two APIs differ in how contracts are referenced and returned:\n\nEthers (the default): deployProxy and upgradeProxy return instances of ethers.js contracts and require ethers.js contract factories as arguments.\nIf you are using viem: the same functions identify contracts by name (a string) and return viem contract instances; addresses use viem's Address type (a `0x${string}` template-literal type, i.e. any string beginning with 0x).\n\nFor beacons, deployBeacon and upgradeBeacon both return an upgradable beacon instance that can be used with a beacon proxy.\nAll deploy and upgrade functions validate that the implementation contract is upgrade-safe, and will fail otherwise.\nSetup\nIn Hardhat 3, all of the functions below are accessed via an upgradesApi object created from the upgrades factory, which takes a network connection as an argument; share one connection across your operations. (Or use hre.network.getOrCreate(), which reuses a connection per network instead of creating a new one each time.)\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nconst connection = await hre.network.create();\nconst { ethers } = connection;\nconst upgradesApi = await upgrades(hre, connection);import hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nconst connection = await hre.network.create();\nconst upgradesApi = await upgrades(hre, connection);Contracts are referenced by name and returned as viem contract instances. Transactions are signed by the connection's first wallet client by default; pass a specific one with the client option.\nupgradesApi exposes every top-level function documented below (e.g. upgradesApi.deployProxy(...)). The admin, erc1967, and beacon namespaces are accessed as upgradesApi.admin.*, upgradesApi.erc1967.*, and upgradesApi.beacon.*.\nCommon Options\nThe following options are common to some functions.\n\nkind: (\"uups\" | \"transparent\" | \"beacon\") The kind of proxy to deploy, upgrade or import, or the kind of proxy that the implementation will be used with. deployProxy() and upgradeProxy() only support the values \"uups\" | \"transparent\". Defaults to \"transparent\". See Transparent vs UUPS.\nunsafeAllow: (ValidationError[]) Selectively disable one or more validation errors or warnings:\n\n\"external-library-linking\": Allows a deployment with external libraries linked to the implementation contract. (External libraries are otherwise not yet supported.)\n\"struct-definition\", \"enum-definition\": Used to be necessary to deploy a contract with structs or enums. No longer necessary.\n\"state-variable-assignment\": Allows assigning state variables in a contract even though they will be stored in the implementation.\n\"state-variable-immutable\": Allows use of immutable variables, which are not unsafe\n\"constructor\": Allows defining a constructor. See constructorArgs.\n\"delegatecall\", \"selfdestruct\": Allow the use of these operations. Incorrect use of this option can put funds at risk of permanent loss. See Can I safely use delegatecall and selfdestruct?\n\"missing-public-upgradeto\": Allow UUPS implementations that do not contain a public upgradeTo or upgradeToAndCall function. Enabling this option is likely to cause a revert due to the built-in UUPS safety mechanism.\n\"internal-function-storage\": Allow internal functions in storage variables. Internal functions are code pointers which will no longer be valid after an upgrade, so they must be reassigned during upgrades. See How can I use internal functions in storage variables?\n\"missing-initializer\": Allows implementations where an initializer function is not detected.\n\"missing-initializer-call\": Allows implementations where a parent initializer is not called from the child initializer.\n\"duplicate-initializer-call\": Allows implementations where a parent initializer is called more than once from the child initializer.\n\"incorrect-initializer-order\": Allows implementations where parent initializers are not called in linearized order. Note: This condition shows a warning by default, and setting this option will silence the warning.\n\nunsafeAllowRenames: (boolean) Configure storage layout check to allow variable renaming.\nunsafeSkipStorageCheck: (boolean) upgrades the proxy or beacon without first checking for storage layout compatibility errors. This is a dangerous option meant to be used as a last resort.\nconstructorArgs: (unknown[]) Provide arguments for the constructor of the implementation contract. Note that these are different from initializer arguments, and will be used in the deployment of the implementation contract itself. Can be used to initialize immutable variables.\ninitialOwner: (string) the address to set as the initial owner of a transparent proxy’s admin or initial owner of a beacon. Defaults to the externally owned account that is deploying the transparent proxy or beacon. Not supported for UUPS proxies.\n\nSince: @openzeppelin/hardhat-upgrades@3.0.0\n\nunsafeSkipProxyAdminCheck: (boolean) Skips checking the initialOwner option when deploying a transparent proxy. When deploying a transparent proxy, the initialOwner must be the address of an EOA or a contract that can call functions on a ProxyAdmin. It must not be a ProxyAdmin contract itself. Use this if you encounter an error due to this check and are sure that the initialOwner is not a ProxyAdmin contract.\n\nSince: @openzeppelin/hardhat-upgrades@3.4.0\n\ntimeout: (number) Timeout in milliseconds to wait for the transaction confirmation when deploying an implementation contract. Defaults to 60000. Use 0 to wait indefinitely.\npollingInterval: (number) Polling interval in milliseconds between checks for the transaction confirmation when deploying an implementation contract. Defaults to 5000.\nredeployImplementation: (\"always\" | \"never\" | \"onchange\") Determines whether the implementation contract will be redeployed. Defaults to \"onchange\".\n\nIf set to \"always\", the implementation contract is always redeployed even if it was previously deployed with the same bytecode.\nIf set to \"never\", the implementation contract is never redeployed. If the implementation contract was not previously deployed or is not found in the network file, an error will be thrown.\nIf set to \"onchange\", the implementation contract is redeployed only if the bytecode has changed from previous deployments.\n\ntxOverrides: (ethers.Overrides) An ethers.js Overrides object to override transaction parameters, such as gasLimit and gasPrice. Applies to all transactions sent by a function with this option, even if the function sends multiple transactions. This option applies to the default ethers-based API.\n\nIf you are using viem, txOverrides does not apply. Instead, pass the transaction parameters gas, gasPrice, maxFeePerGas, maxPriorityFeePerGas, and value directly as options, and use the client option to select the wallet/public client.\n\nclient: (KeyedClient) viem-based API only. The viem public and/or wallet clients to use, following @nomicfoundation/hardhat-viem conventions. KeyedClient is an object { public?: PublicClient; wallet?: WalletClient } (with at least one of the two provided). The wallet client is the viem counterpart of the ethers signer: it selects the account that signs the plugin's transactions, and must be an account managed by the network connection. Defaults to the first wallet client from connection.viem.getWalletClients(). The admin.* functions instead take a wallet client as a positional argument, not via this option.\nproxyFactory: (ethers.ContractFactory) Customizes the ethers contract factory to use for deploying the proxy, allowing a custom proxy contract to be deployed. See factories.ts for the default contract factory for each kind of proxy.\n\nSince: @openzeppelin/hardhat-upgrades@3.7.0\n\ndeployFunction: ((hre, opts, factory, ...args) => Promise<EthersOrDefenderDeployment>) Customizes the function used to deploy the proxy. Can be used along with the proxyFactory option to override constructor parameters for custom proxy deployments. See deploy.ts for the default deploy function. EthersOrDefenderDeployment is the return type exported by @openzeppelin/hardhat-upgrades, kept under its upstream name.\n\nSince: @openzeppelin/hardhat-upgrades@3.7.0\n\nNote that the options unsafeAllow can also be specified in a more granular way directly in the source code if using Solidity >=0.8.2. See How can I disable some of the checks?\nThe following options have been deprecated.\n\nunsafeAllowLinkedLibraries: Equivalent to including \"external-library-linking\" in unsafeAllow.\nunsafeAllowCustomTypes: Equivalent to including \"struct-definition\" and \"enum-definition\" in unsafeAllow. No longer necessary.\nuseDeployedImplementation: (boolean) Equivalent to setting redeployImplementation to \"never\". Not supported when using viem; use redeployImplementation instead.\n\ndeployProxy\nasync function deployProxy(\n Contract: ethers.ContractFactory,\n args: unknown[] = [],\n opts?: {\n initializer?: string | false,\n unsafeAllow?: ValidationError[],\n constructorArgs?: unknown[],\n initialOwner?: string,\n unsafeSkipProxyAdminCheck?: boolean,\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n txOverrides?: ethers.Overrides,\n kind?: 'uups' | 'transparent',\n proxyFactory?: ethers.ContractFactory,\n deployFunction?: () => Promise<EthersOrDefenderDeployment>,\n },\n): Promise<ethers.Contract>async function deployProxy(\n contractName: string,\n args: unknown[] = [],\n opts?: {\n initializer?: string | false,\n unsafeAllow?: ValidationError[],\n constructorArgs?: unknown[],\n initialOwner?: Address,\n unsafeSkipProxyAdminCheck?: boolean,\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n kind?: 'uups' | 'transparent',\n client?: KeyedClient,\n },\n): Promise<ContractReturnType>\nCreates a UUPS or Transparent proxy from the given implementation, and returns a contract instance bound to the proxy address with the implementation interface. If args is set, will call an initializer function initialize with the supplied args during proxy deployment.\nIf you call deployProxy several times for the same implementation contract, several proxies will be deployed, but only one implementation contract will be used.\nParameters:\n\nContract (ethers) or contractName (viem) - an ethers contract factory or contract name to use as the implementation.\nargs - arguments for the initializer function.\nopts - an object with options:\n\ninitializer: the initializer function to call instead of the default initialize: a function name such as initialize, or a full signature such as initialize(uint256) to disambiguate overloads; or false to disable initialization. The accepted formats differ slightly between ethers and viem. See Differences.\nadditional options as described in Common Options.\n\nReturns:\n\na contract instance bound to the proxy address with the implementation interface: an ethers contract, or a viem contract instance when using viem.\n\nupgradeProxy\nasync function upgradeProxy(\n proxy: string | ethers.Contract,\n Contract: ethers.ContractFactory,\n opts?: {\n call?: string | { fn: string; args?: unknown[] },\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n txOverrides?: ethers.Overrides,\n kind?: 'uups' | 'transparent',\n },\n): Promise<ethers.Contract>async function upgradeProxy(\n proxy: Address | ContractReturnType,\n contractName: string,\n opts?: {\n call?: string | { fn: string; args?: unknown[] },\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n kind?: 'uups' | 'transparent',\n client?: KeyedClient,\n },\n): Promise<ContractReturnType>\nUpgrades a UUPS or Transparent proxy at a specified address to a new implementation contract, and returns a contract instance with the proxy address and the new implementation interface.\nParameters:\n\nproxy - the proxy address or proxy contract instance.\nContract (ethers) or contractName (viem) - an ethers contract factory or contract name to use as the new implementation.\nopts - an object with options:\n\ncall: enables the execution of an arbitrary function call during the upgrade process. This call is described using a function name or signature, and optional arguments. It is batched into the upgrade transaction, making it safe to call migration initializing functions. The accepted formats differ slightly between ethers and viem. See Differences.\nadditional options as described in Common Options.\n\nReturns:\n\na contract instance with the proxy address and the new implementation interface.\n\ndeployBeacon\nasync function deployBeacon(\n Contract: ethers.ContractFactory,\n opts?: {\n unsafeAllow?: ValidationError[],\n constructorArgs?: unknown[],\n initialOwner?: string,\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n txOverrides?: ethers.Overrides,\n },\n): Promise<ethers.Contract>async function deployBeacon(\n contractName: string,\n opts?: {\n unsafeAllow?: ValidationError[],\n constructorArgs?: unknown[],\n initialOwner?: Address,\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n client?: KeyedClient,\n },\n): Promise<UpgradeableBeaconContract>\nCreates an upgradable beacon for the given implementation, and returns the beacon contract instance.\nParameters:\n\nContract (ethers) or contractName (viem) - an ethers contract factory or contract name to use as the implementation.\nopts - an object with options:\n\nadditional options as described in Common Options.\n\nReturns:\n\nthe beacon contract instance.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.13.0\n\nupgradeBeacon\nasync function upgradeBeacon(\n beacon: string | ethers.Contract,\n Contract: ethers.ContractFactory,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n txOverrides?: ethers.Overrides,\n },\n): Promise<ethers.Contract>async function upgradeBeacon(\n beacon: Address | UpgradeableBeaconContract,\n contractName: string,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n client?: KeyedClient,\n },\n): Promise<UpgradeableBeaconContract>\nUpgrades an upgradable beacon at a specified address to a new implementation contract, and returns the beacon contract instance.\nParameters:\n\nbeacon - the beacon address or beacon contract instance.\nContract (ethers) or contractName (viem) - an ethers contract factory or contract name to use as the new implementation.\nopts - an object with options:\n\nadditional options as described in Common Options.\n\nReturns:\n\nthe beacon contract instance.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.13.0\n\ndeployBeaconProxy\nasync function deployBeaconProxy(\n beacon: string | ethers.Contract,\n attachTo: ethers.ContractFactory,\n args: unknown[] = [],\n opts?: {\n initializer?: string | false,\n txOverrides?: ethers.Overrides,\n proxyFactory?: ethers.ContractFactory,\n deployFunction?: () => Promise<EthersOrDefenderDeployment>,\n },\n): Promise<ethers.Contract>async function deployBeaconProxy(\n beacon: Address | UpgradeableBeaconContract,\n contractName: string,\n args: unknown[] = [],\n opts?: {\n initializer?: string | false,\n client?: KeyedClient,\n },\n): Promise<ContractReturnType>\nCreates a Beacon proxy given an existing beacon and the beacon's current implementation contract, and returns a contract instance with the beacon proxy address and the implementation interface. If args is set, will call an initializer function initialize with the supplied args during proxy deployment.\nParameters:\n\nbeacon - the beacon address or beacon contract instance.\nattachTo (ethers) or contractName (viem) - an ethers contract factory or contract name corresponding to the beacon's current implementation contract.\nargs - arguments for the initializer function.\nopts - an object with options:\n\ninitializer: set a different initializer function to call (a function name, or a signature such as initialize(uint256)), or specify false to disable initialization. See Differences.\nadditional options as described in Common Options.\n\nReturns:\n\na contract instance with the beacon proxy address and the implementation interface.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.13.0\n\nforceImport\nasync function forceImport(\n address: string,\n deployedImpl: ethers.ContractFactory,\n opts?: {\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<ethers.Contract>async function forceImport(\n addressOrInstance: Address | ContractReturnType,\n contractName: string,\n opts?: {\n kind?: 'uups' | 'transparent' | 'beacon',\n client?: KeyedClient,\n },\n): Promise<ContractReturnType>\nForces the import of an existing proxy, beacon, or implementation contract deployment to be used with this plugin. Provide the address of an existing proxy, beacon or implementation, along with its current implementation contract (an ethers contract factory, or the contract name as a string when using viem).\nWhen importing a proxy or beacon, the implementation argument must be the current implementation contract version that is being used, not the version that you are planning to upgrade to.\nUse this function to recreate a lost network file by importing previous deployments, or to register proxies or beacons for upgrading even if they were not originally deployed by this plugin. Supported for UUPS, Transparent, and Beacon proxies, as well as beacons and implementation contracts.\nParameters:\n\naddress (ethers) or addressOrInstance (viem) - the address of an existing proxy, beacon or implementation. The viem API also accepts a contract instance.\ndeployedImpl (ethers) or contractName (viem) - the ethers contract factory or contract name of the current implementation contract.\nopts - an object with options:\n\nkind: (\"uups\" | \"transparent\" | \"beacon\") forces a proxy to be treated as a UUPS, Transparent, or Beacon proxy. If not provided, the proxy kind will be automatically detected.\n\nReturns:\n\na contract instance representing the imported proxy, beacon or implementation.\n\nSince\n\n@openzeppelin/hardhat-upgrades@1.15.0\n\nvalidateImplementation\nasync function validateImplementation(\n Contract: ethers.ContractFactory,\n opts?: {\n unsafeAllow?: ValidationError[],\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<void>async function validateImplementation(\n contractName: string,\n opts?: {\n unsafeAllow?: ValidationError[],\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<void>\nValidates an implementation contract without deploying it.\nParameters:\n\nContract (ethers) or contractName (viem) - the ethers contract factory or contract name of the implementation contract.\nopts - an object with options:\n\nadditional options as described in Common Options.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.20.0\n\ndeployImplementation\nasync function deployImplementation(\n Contract: ethers.ContractFactory,\n opts?: {\n unsafeAllow?: ValidationError[],\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n txOverrides?: ethers.Overrides,\n getTxResponse?: boolean,\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<string | ethers.providers.TransactionResponse>async function deployImplementation(\n contractName: string,\n opts?: {\n unsafeAllow?: ValidationError[],\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n kind?: 'uups' | 'transparent' | 'beacon',\n client?: KeyedClient,\n },\n): Promise<Address>\nValidates and deploys an implementation contract, and returns its address.\nParameters:\n\nContract (ethers) or contractName (viem) - the ethers contract factory or contract name of the implementation contract.\nopts - an object with options:\n\ngetTxResponse: (ethers-based API only) if set to true, causes this function to return an ethers transaction response corresponding to the deployment of the new implementation contract instead of its address. Note that if the new implementation contract was originally imported as a result of forceImport, only the address will be returned.\nadditional options as described in Common Options.\n\nReturns:\n\nthe implementation contract address (or, with the ethers-based API, an ethers transaction response when getTxResponse is set).\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.20.0\n\nvalidateUpgrade\nasync function validateUpgrade(\n referenceAddressOrContract: string | ethers.ContractFactory,\n newContract: ethers.ContractFactory,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<void>async function validateUpgrade(\n referenceAddressOrContractName: Address | string,\n newContractName: string,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<void>\nValidates a new implementation contract without deploying it and without actually upgrading to it. Compares the current implementation contract to the new implementation contract to check for storage layout compatibility errors. If the reference is the current implementation address, the kind option is required.\nParameters:\n\nreferenceAddressOrContract (ethers) or referenceAddressOrContractName (viem) - a proxy or beacon address that uses the current implementation, or an address, ethers contract factory, or contract name corresponding to the current implementation.\nnewContract (ethers) or newContractName (viem) - the ethers contract factory or contract name of the new implementation contract.\nopts - an object with options:\n\nadditional options as described in Common Options.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.20.0\n\nExamples:\nValidate upgrading an existing proxy to a new contract (replace PROXY_ADDRESS with the address of your proxy):\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nconst connection = await hre.network.create();\nconst { ethers } = connection;\nconst upgradesApi = await upgrades(hre, connection);\n\nconst BoxV2 = await ethers.getContractFactory('BoxV2');\nawait upgradesApi.validateUpgrade(PROXY_ADDRESS, BoxV2);import hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nconst connection = await hre.network.create();\nconst upgradesApi = await upgrades(hre, connection);\n\nawait upgradesApi.validateUpgrade(PROXY_ADDRESS, 'BoxV2');\nValidate upgrading between two contract implementations:\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nconst connection = await hre.network.create();\nconst { ethers } = connection;\nconst upgradesApi = await upgrades(hre, connection);\n\nconst Box = await ethers.getContractFactory('Box');\nconst BoxV2 = await ethers.getContractFactory('BoxV2');\nawait upgradesApi.validateUpgrade(Box, BoxV2);import hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nconst connection = await hre.network.create();\nconst upgradesApi = await upgrades(hre, connection);\n\nawait upgradesApi.validateUpgrade('Box', 'BoxV2');\nprepareUpgrade\nasync function prepareUpgrade(\n referenceAddressOrContract: string | ethers.Contract,\n Contract: ethers.ContractFactory,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n txOverrides?: ethers.Overrides,\n getTxResponse?: boolean,\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Promise<string | ethers.providers.TransactionResponse>async function prepareUpgrade(\n referenceAddressOrContract: Address | ContractReturnType,\n contractName: string,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n constructorArgs?: unknown[],\n timeout?: number,\n pollingInterval?: number,\n redeployImplementation?: 'always' | 'never' | 'onchange',\n kind?: 'uups' | 'transparent' | 'beacon',\n client?: KeyedClient,\n },\n): Promise<Address>\nValidates and deploys a new implementation contract, and returns its address. If the reference is the current implementation address, the kind option is required. Use this method to prepare an upgrade to be run from an admin address you do not control directly or cannot use from Hardhat.\nParameters:\n\nreferenceAddressOrContract - the proxy or beacon or implementation address or contract instance.\nContract (ethers) or contractName (viem) - the ethers contract factory or contract name of the new implementation contract.\nopts - an object with options:\n\ngetTxResponse: (ethers-based API only) if set to true, causes this function to return an ethers transaction response corresponding to the deployment of the new implementation contract instead of its address. Note that if the new implementation contract was originally imported as a result of forceImport, only the address will be returned.\nadditional options as described in Common Options.\n\nReturns:\n\nthe new implementation contract address (or, with the ethers-based API, an ethers transaction response when getTxResponse is set).\n\nadmin.changeProxyAdmin\nasync function changeProxyAdmin(\n proxyAddress: string,\n newAdmin: string,\n signer?: ethers.Signer,\n opts?: {\n txOverrides?: ethers.Overrides,\n },\n): Promise<void>async function changeProxyAdmin(\n proxyAddress: Address,\n newAdmin: Address,\n walletClient?: WalletClient,\n opts?: {\n gas?: bigint,\n gasPrice?: bigint,\n maxFeePerGas?: bigint,\n maxPriorityFeePerGas?: bigint,\n value?: bigint,\n },\n): Promise<void>\nChanges the admin for a specific proxy.\nThis function is not supported with admins or proxies from OpenZeppelin Contracts 5.x.\nParameters:\n\nproxyAddress - the address of the proxy to change.\nnewAdmin - the new admin address.\nsigner (ethers) or walletClient (viem) - the account to send the transaction with. Optional; defaults to the connection's default account.\nopts - an object with options:\n\nadditional options as described in Common Options.\n\nadmin.transferProxyAdminOwnership\nasync function transferProxyAdminOwnership(\n proxyAddress: string,\n newOwner: string,\n signer?: ethers.Signer,\n opts?: {\n silent?: boolean,\n txOverrides?: ethers.Overrides,\n },\n): Promise<void>async function transferProxyAdminOwnership(\n proxyAddress: Address,\n newOwner: Address,\n walletClient?: WalletClient,\n opts?: {\n silent?: boolean,\n gas?: bigint,\n gasPrice?: bigint,\n maxFeePerGas?: bigint,\n maxPriorityFeePerGas?: bigint,\n value?: bigint,\n },\n): Promise<void>\nChanges the owner of the proxy admin contract for a specific proxy.\nThe proxyAddress parameter is required since @openzeppelin/hardhat-upgrades@3.0.0\nParameters:\n\nproxyAddress - the address of the proxy whose admin ownership is to be transferred.\nnewOwner - the new owner address for the proxy admin contract.\nsigner (ethers) or walletClient (viem) - the account to send the transaction with. Optional; defaults to the connection's default account.\nopts - an object with options:\n\nsilent: if set to true, silences console logging about each proxy affected by the admin ownership transfer.\nadditional options as described in Common Options.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@3.0.0\n\nerc1967\nasync function erc1967.getImplementationAddress(proxyAddress: string): Promise<string>;\nasync function erc1967.getBeaconAddress(proxyAddress: string): Promise<string>;\nasync function erc1967.getAdminAddress(proxyAddress: string): Promise<string>;async function erc1967.getImplementationAddress(proxyAddress: Address): Promise<Address>;\nasync function erc1967.getBeaconAddress(proxyAddress: Address): Promise<Address>;\nasync function erc1967.getAdminAddress(proxyAddress: Address): Promise<Address>;\nFunctions in this module provide access to the ERC1967 variables of a proxy contract.\nParameters:\n\nproxyAddress - the proxy address.\n\nReturns:\n\nthe implementation, beacon, or admin address depending on the function called.\n\nbeacon\nasync function beacon.getImplementationAddress(beaconAddress: string): Promise<string>;async function beacon.getImplementationAddress(beaconAddress: Address): Promise<Address>;\nThis module provides a convenience function to get the implementation address from a beacon contract.\nParameters:\n\nbeaconAddress - the beacon address.\n\nReturns:\n\nthe implementation address.\n\nSince:\n\n@openzeppelin/hardhat-upgrades@1.13.0\n\nsilenceWarnings\nfunction silenceWarnings()\nThis function is useful for tests, but its use in production deployment scripts is discouraged.\nSilences all subsequent warnings about the use of unsafe flags. Prints a last warning before doing so.\nverify\nExtends hardhat-verify's verify task to completely verify a proxy on Etherscan. This supports verifying proxy contracts that were deployed by the Hardhat Upgrades plugin.\nThe arguments are the same as for hardhat-verify’s verify task. If the provided address is a proxy, this task will verify the proxy’s implementation contract, the proxy itself and any proxy-related contracts, as well as link the proxy to the implementation contract’s ABI on Etherscan. If the provided address is not a proxy, the regular verify task from hardhat-verify will be run on the address instead.\nThe following contracts will be verified when you run this task on your proxy address:\n\nYour implementation contract\nERC1967Proxy or TransparentUpgradeableProxy or BeaconProxy (for UUPS, transparent, or beacon proxies, respectively)\nProxyAdmin (with transparent proxies)\nUpgradeableBeacon (with beacon proxies)\n\nSince:\n\n@openzeppelin/hardhat-upgrades@2.0.0\n\nUsage:\nTo use this task, ensure you have hardhat-verify installed:\nnpm install --save-dev @nomicfoundation/hardhat-verify\nThen add both @nomicfoundation/hardhat-verify and @openzeppelin/hardhat-upgrades to the plugins array in your hardhat.config.ts. The upgrades plugin detects hardhat-verify and automatically extends its verify task:\nimport { configVariable, defineConfig } from 'hardhat/config';\nimport hardhatVerify from '@nomicfoundation/hardhat-verify';\nimport hardhatUpgrades from '@openzeppelin/hardhat-upgrades';\n\nexport default defineConfig({\n plugins: [hardhatVerify, hardhatUpgrades],\n verify: {\n etherscan: {\n apiKey: configVariable('ETHERSCAN_API_KEY'),\n },\n },\n});import { configVariable, defineConfig } from 'hardhat/config';\nimport hardhatVerify from '@nomicfoundation/hardhat-verify';\nimport hardhatUpgrades from '@openzeppelin/hardhat-upgrades/viem';\n\nexport default defineConfig({\n plugins: [hardhatVerify, hardhatUpgrades],\n verify: {\n etherscan: {\n apiKey: configVariable('ETHERSCAN_API_KEY'),\n },\n },\n});\nThen run the verify task from the command line with the proxy address:\nnpx hardhat verify --network mainnet PROXY_ADDRESS\nNote that you do not need to include constructor arguments when verifying if your implementation contract only uses initializers. However, if your implementation contract has an actual constructor with arguments (such as to set immutable variables), then include constructor arguments according to the usage information for the task.Frequently Asked QuestionsPrevious PageOverviewNext PageOn this pageSetupCommon OptionsdeployProxyupgradeProxydeployBeaconupgradeBeacondeployBeaconProxyforceImportvalidateImplementationdeployImplementationvalidateUpgradeprepareUpgradeadmin.changeProxyAdminadmin.transferProxyAdminOwnershiperc1967beaconsilenceWarningsverify","tokens":8106,"squid":"ink-security_audits","role":"Sentinel","at":1791260093301,"hash":"3b95b0ddb3b2235d42a016da1e9fa175e857a526"}
{"url":"https://dev-forum.pyth.network/categories","domain":"dev-forum.pyth.network","title":"Pyth Developer Forum","text":"Welcome to Pyth Dev Forum.\n\n Where developers build DeFi. \n\n gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n All categories\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Hot\n\n Category\n Topics\n\n Price Feeds\n\n Welcome to the Pyth Price Feeds Category\n\n Benchmarks(Historic Prices)\n\n 171\n\n Pyth Community Hackathon\n\n A 6-week community hackathon for builders of all skill levels. Build projects using \nPyth’s price feeds, or Pyth Entropy. Pyth embraces vibe coding and all AI-assisted \ndevelopment to lower the barrier to entry . No PhD required.\n\n 55\n\n Entropy\n\n Welcome to the Pyth Entropy Category\n\n 34\n\n Announcements\n\n Official updates related to Pyth, Pyth products and more!\n\n Incidents\n\n 51\n\n Uncategorized\n\n 4\n\n Grants\n\n Welcome to the Grants category!\n\n 3\n\n Express Relay\n\n Welcome to the Pyth Express Relay Category\n\n 2\n\n General\n\n Topics that don’t need a category, or don’t fit into any other existing category.\n\n 1\n\n Forum Feedback\n\n Feedback on how to make this developer forum better for you!\n\n 0\n\n Top\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n Mar 31\n\n The Market Witness\n\n Pyth Community Hackathon\n\n 11\n\n Mar 27\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n Oct 2025\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n Aug 5\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)svm\n\n 11\n\n Jan 12\n\n Off-chain price feeds\n\n Price Feeds\n\n 11\n\n Jul 4\n\n Pyth Entropy Smart Contract Verification\n\n Grantsentropy\n\n 2\n\n Oct 2025\n\n Judging Rubric; How Submissions Are Scored\n\n Pyth Community Hackathon\n\n 0\n\n Mar 2\n\n Update: Pyth Core Upgrade Date Moved to August 26, 2026\n\n Price Feedsannouncements\n\n 2\n\n Aug 26\n\n Market DVR — Record Every Pyth Pro Tick, Replay Any Market Moment Frame by Frame\n\n Pyth Community Hackathon\n\n 2\n\n Mar 10\n\n Deprecation of DEUSD/USD and SDEUSD/DEUSD.RR feeds on Pyth - 9th November, 2025\n\n Announcementsannouncements\n\n 1\n\n Nov 2025\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n Mar 2\n\n Should we pay attention to the VAA timestamp when updating feeds?\n\n Price Feedsevm\n\n 2\n\n Oct 2025\n\n More\n\n Powered by Discourse","tokens":1403,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260100160,"hash":"98a70652a6d70e3c012cfcb8c3bc0973ccb460c9"}
{"url":"https://ethereum.org/staking/pools/","domain":"ethereum.org","title":"Liquid & pooled staking | ethereum.org","text":"Edit page (opens in a new tab)What are staking pools?\nStaking pools are a collaborative approach to allow many people with smaller amounts of ETH to obtain the 32 ETH minimum required to activate a validator on Ethereum. Pooling functionality is not natively supported within the protocol, so solutions were built out separately to address the need for participating with smaller amounts.\nSome staking pools operate using smart contracts, where funds are deposited to a contract that manages and tracks your stake, and issues you a receipt token (liquid staking token) that represents this value. Other pools may not involve smart contracts and are instead mediated offchain.\nPooled options differ enormously in how much you can verify about them. Transparent, protocol-governed pools are open-source smart contracts on Ethereum that hold deposits, publish their node operator sets, and issue a redeemable token; everything backing your position is visible onchain. Opaque pooled products, such as some centralized exchange yield programs, take your ETH into custody, and you cannot independently verify what is staked on your behalf, if anything. Most of this page covers the first kind; see opaque pooled products for how to tell the difference.\nEvery pooled option solves the real access problem of staking with less than 32 ETH, or without running hardware. But each also puts an intermediary between the staker and core Ethereum protocol. Only solo staking gives you a direct, unmediated relationship with Ethereum.\nWhy stake with a pool?\nIn addition to the benefits of participating in staking, staking with a pool comes with a number of unique benefits.\nLow barrier to entryNot a whale? No problem. Most staking pools let you stake virtually any amount of ETH by joining forces with other stakers, unlike staking solo which requires 32 ETH.Stake todayStaking with a pool is as easy as a token swap. No need to worry about hardware setup and node maintenance. Pools allow you to deposit your ETH which enables node operators to run validators. Rewards are then distributed to contributors minus a fee for node operations.Liquid staking tokensMany staking pools provide a token that represents a claim on your staked ETH and the rewards it generates. This allows you to make use of your staked ETH, e.g., as collateral in DeFi applications.\nComparison of staking options\nHome stakingPooled staking has a significantly lower barrier to entry when compared to home staking, but comes with additional risk by delegating all node operations to a third-party, and with a fee. Home staking gives full sovereignty and control over the choices that go into choosing a staking setup. Stakers never have to hand over their keys, and they earn full rewards without any middlemen taking a cut.Learn more about home stakingDelegated staking, or staking as a service (SaaS)These are similar in that stakers do not run the validator software themselves, but unlike pooling options, SaaS requires a full 32 ETH deposit to activate a validator. Rewards accumulate to the staker, and usually involve a monthly fee or other stake to use the service. If you'd prefer your own validator keys and are looking to stake at least 32 ETH, using a SaaS provider may be a good option for you.Learn more about delegated staking\nLiquid staking tokens\nMost transparent staking pools issue a liquid staking token (LST), an ERC-20 token that represents a claim on staked ETH and the rewards it earns. When you deposit ETH, the protocol stakes it with its node operators and mints a receipt token (LST) to your wallet. You can hold the token yourself or custody it with a third-party provider, and can transfer or sell the token at any time. The underlying ETH stays staked on the consensus layer. Liquid staking protocols account for around a third of all staked ETH, making LSTs one of the most common ways to stake today.\nHow rewards show up in the token\nLSTs reflect staking rewards in one of two ways:\n\nRebasing tokens (such as Lido's stETH): your token balance increases as rewards accrue, so one token stays roughly equal in value to one ETH.\nExchange-rate tokens (such as Rocket Pool's rETH): your token balance stays the same, but each token becomes redeemable for a growing amount of ETH over time.\n\nBoth designs deliver rewards net of the staking protocol's fee. Neither is inherently better, but they behave differently in wallets and DeFi applications, and are treated differently for tax purposes in some jurisdictions. Rebasing tokens often have \"wrapped\" non-rebasing versions for compatibility with applications.\nRedeeming and trading\nThere are two ways to exit an LST position:\n\nRedeem through the protocol for the underlying ETH. Redemption depends on the protocol having liquidity available, either a buffer of unstaked ETH or validators exiting through the consensus layer exit queue, which can take time.\nSell on secondary markets at any time. Because the token trades freely, its market price can deviate from the value of the ETH backing it, particularly during periods of market stress.\n\nSince the Pectra upgrade, execution layer triggered withdrawals (EIP-7002) (opens in a new tab) allow validator exits to be triggered directly from the execution layer by the withdrawal address holder. Staking protocols can use this feature to ensure their validators can be exited without relying on node operators to cooperate, so redemptions rely less on trusting node operators than they used to.\nHolding an LST is not the same as staking\nThe Ethereum protocol pays rewards to validators; it doesn't know your token exists. When you hold an LST, you are not a staker from the protocol's point of view. Instead, you hold a claim on a service or smart contract that stakes on your behalf. This works well in normal conditions, but it comes with additional trust dependencies. Your staked ETH depends on the pool's contracts, governance, and operators working correctly, not just on Ethereum itself.\nRisks of liquid staking tokens\nLSTs inherit the underlying risks of staking (such as slashing and downtime penalties on the pool's validators) and add layers of their own:\n\nSmart contract risk - your ETH is held by contracts that could contain bugs or be exploited. Favor protocols with open-source, audited, battle-tested code.\nMarket and liquidity risk - the token's secondary-market price can fall below the value of the ETH backing it (\"depegging\"). If protocol redemptions are slow or congested when you want out, selling at a discount may be your only fast exit.\nGovernance and upgrade risk - fees, node operator sets, and even how the token works can be changed through the protocol's governance and contract upgrades. As a token holder you typically have no vote in that governance.\nOperator-set centralization - some pools concentrate stake with their chosen node operators. Large amounts of staked ETH under the control of a few organizations create conditions for censorship, value extraction, and single points of failure. Prefer pools with permissionless, distributed operator sets.\nSlashing pass-through - if the pool's validators are slashed or penalized, the loss is typically socialized across all token holders according to the protocol's rules.\n\nMany pools reduce operator risk using distributed validator technology (DVT), middleware that splits a validator's key across multiple machines and operators so no single failure or compromise takes the validator down. More on distributed validator technology\nOpaque pooled products\nNot everything marketed as \"staking\" is protocol staking. Centralized exchange \"earn\" or \"rewards\" programs, and some yield products built on top of staking tokens, pool customer ETH in ways you cannot inspect:\n\nCustodial - the provider holds the withdrawal keys and the ETH.\nTerms can change - rates, lockups, and eligibility are set by company policy and can be revised at any time, unlike rules enforced by onchain contracts.\nMay not be staking at all - under the hood, the yield may come from lending, trading, or other activities rather than validators. You usually have no way to verify.\nCounterparty risk - if the provider becomes insolvent or freezes withdrawals, there is nothing onchain for you to redeem.\n\nTo tell a transparent pool from an opaque product, ask:\n\nCan you verify onchain where your ETH goes, in open-source, audited contracts?\nIs the node operator set published?\nDo you receive a token held in your own wallet that is redeemable for the underlying ETH?\nAre the rules enforced by smart contracts and public governance, or by a company's terms of service?\n\nThe more of these questions a provider can only answer with \"trust us,\" the more opaque the product.\nSome products advertise \"enhanced\" or \"boosted\" yield by combining staking with restaking, a use case for LSTs that commits staked ETH to secure additional protocols under additional slashing conditions. Restaking is a separate risk category and novel application built on top of LSTs, not a form of direct staking participation. If a yield figure is meaningfully higher than the core network staking rate, you should ask exactly where the extra yield comes from. What is restaking?\nRun a node for a pool\nBecoming a bonded node operator for a staking pool is a middle path between holding a token and solo staking. Some staking protocols let individuals run validators using pooled ETH from other users. You post a bond of your own ETH as collateral, run the hardware and keys, and earn a commission on the stake matched to you.\nFor example, Rocket Pool megapool validators require a 4 ETH bond per validator, and Lido's Community Staking Module requires around 2.4 ETH for a first validator key (1.5 ETH for Identified Community Stakers). This offers people with less than 32 ETH a way to run their own hardware and strengthen the network's operator set, while accepting the pool's rules, performance requirements, and penalty conditions.\nWhat to consider\nEach pool and the tools or smart contracts they use have been built out by different teams, and each comes with benefits and risks. Pooled or delegated staking is not natively supported by the Ethereum protocol, and the gold standard for staking should always be individuals running validators on their own hardware whenever possible.\nAttribute indicators are used below to signal notable strengths or weaknesses a listed staking pool may have. Use this section as a reference for how we define these attributes while you're choosing a pool to join.\nOpen sourceEssential code is 100% open source and available to the public to fork and useOpen sourceClosed source\nExplore staking pools\nThere are a variety of options available to help you with your setup. Use the above indicators to help guide you through the tools below.\nProducts and services are listed as a convenience for the Ethereum community. Inclusion of a product or service does not represent an endorsement from the ethereum.org website team, or the Ethereum Foundation.\nLidoAny amountBrowserWalletGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Origin EtherAny amountBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)StakeWiseAny amountBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Rocket PoolFrom 0.01 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)EverstakeFrom 0.1 ETHBrowserWalletGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)BedrockAny amountBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Ankr StakingAny amountBrowserWalletGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab)Get started (opens in a new tab)StaFiFrom 0.01 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionless nodesExecution diversityConsensus diversityLiquidity tokenVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)\nPlease note the importance of choosing a service that takes client diversity seriously, as it improves the security of the network, and limits your risk. Services that have evidence of limiting majority client use are indicated with \"execution client diversity\" and \"consensus client diversity.\"\nHave a suggestion for a staking tool we missed? Check out our product listing policy to see if it would be a good fit, and to submit it for review.\n\nFrequently asked questions\nTypically ERC-20 liquid staking tokens are issued to stakers and represent the value of their staked ETH plus rewards. Rewards reach you in one of two ways depending on the token design: rebasing tokens increase your token balance as rewards accrue, while exchange-rate tokens keep your balance fixed and become redeemable for more ETH over time. Either way, rewards are distributed net of the pool's fee.\nStaking withdrawals have been enabled since the Shanghai/Capella upgrade in April 2023. Validator accounts that back staking pools can exit and withdraw ETH to their designated withdrawal address, which lets you redeem your portion of stake for the underlying ETH. Redemption speed depends on your pool's available liquidity and the consensus layer exit queue. Check with your provider to see how they support this functionality.Since the Pectra upgrade, pools can also use execution layer triggered withdrawals (EIP-7002) to exit validators directly from the withdrawal address, without relying on node operators' signing keys, reducing the trust required for redemptions to be honored.Alternatively, pools that utilize an ERC-20 liquid staking token allow users to trade this token in the open market, allowing you to sell your staking position, effectively \"withdrawing\" without actually removing ETH from the staking contract. Note that the market price can differ from the token's redemption value.More on staking withdrawals\nThere are many similarities between these pooled staking options and centralized exchanges, such as the ability to stake small amounts of ETH and have them bundled together to activate validators.Unlike centralized exchanges, many other pooled staking options utilize smart contracts and/or liquid staking tokens, which are usually ERC-20 tokens that can be held in your own wallet, and bought or sold just like any other token. This offers a layer of sovereignty and security by giving you control over your tokens, but still does not give you direct control over the validator client attesting on your behalf in the background.Exchange \"earn\" programs are also custodial and governed by company terms rather than onchain rules, and their yield may not come from protocol staking at all. See opaque pooled products for how to tell the difference.Some pooling options are more decentralized than others when it comes to the nodes that back them. To promote the health and decentralization of the network, stakers are always encouraged to select a pooling service that enables a permissionless decentralized set of node operators.\nFurther reading\n\nThe Ethereum Staking Directory (opens in a new tab) - Eridian and Spacesider\nThe risks of liquid staking derivatives (opens in a new tab) - Danny Ryan\nWhat Is Liquid Staking? (opens in a new tab) - Chainlink\nEIP-7002: Execution layer triggerable withdrawals (opens in a new tab) - Ethereum Improvement Proposals\nEthereum Staking Pool Ratings (opens in a new tab) - Rated Network Explorer\nWhat's the difference between a liquid restaking token (LRT) and a liquid staking token (LST)? (opens in a new tab) - Liquid Collective","tokens":4126,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260102865,"hash":"aec58804155e65c0e0a16002773e1a134ea0e1e6"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/hardhat-upgrades","domain":"docs.openzeppelin.com","title":"Using with Hardhat | OpenZeppelin Docs","text":"Upgrades PluginsUsing with HardhatOpen in ClaudeThis is the documentation for Hardhat 3. For Hardhat 2, see Using with Hardhat (Hardhat 2).\nThis package adds functions to your Hardhat scripts so you can deploy and upgrade proxies for your contracts, using either ethers or viem.\nMigrating from Hardhat 2? See the Migration Guide.\nInstallation\n$ npm install --save-dev @openzeppelin/hardhat-upgrades\n$ npm install --save-dev @nomicfoundation/hardhat-ethers ethers$ npm install --save-dev @openzeppelin/hardhat-upgrades\n$ npm install --save-dev @nomicfoundation/hardhat-viem viem\nUse the ethers / viem toggle above depending on which library you use. Your choice also switches the config and every code example on this page. When you install this plugin, you must also install the peer dependencies for your chosen library. See Using with viem for the behavior differences between the two.\nRegister the plugin in your hardhat.config.ts:\nimport { defineConfig } from 'hardhat/config';\nimport hardhatUpgrades from '@openzeppelin/hardhat-upgrades';\n\nexport default defineConfig({\n plugins: [hardhatUpgrades],\n // ... rest of config\n});import { defineConfig } from 'hardhat/config';\nimport hardhatViem from '@nomicfoundation/hardhat-viem';\nimport hardhatUpgrades from '@openzeppelin/hardhat-upgrades/viem';\n\nexport default defineConfig({\n plugins: [hardhatViem, hardhatUpgrades],\n // ... rest of config\n});\nIf you use the verify task, also add @nomicfoundation/hardhat-verify to the plugins array and configure Hardhat's verify.etherscan.apiKey setting.\nUsage in scripts\nImportant: Create a single network connection and share it across all operations. This ensures operations share the same context and state. (Or use hre.network.getOrCreate(), which reuses a connection per network instead of creating a new one each time.)\nProxies\nYou can use this plugin in a Hardhat script to deploy an upgradeable instance of one of your contracts via the deployProxy function:\n// scripts/create-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nasync function main() {\n const connection = await hre.network.create();\n const { ethers } = connection;\n const upgradesApi = await upgrades(hre, connection);\n\n const Box = await ethers.getContractFactory('Box');\n const box = await upgradesApi.deployProxy(Box, [42]);\n await box.waitForDeployment();\n console.log('Box deployed to:', await box.getAddress());\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});// scripts/create-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nasync function main() {\n const connection = await hre.network.create();\n const upgradesApi = await upgrades(hre, connection);\n\n const box = await upgradesApi.deployProxy('Box', [42]);\n console.log('Box deployed to:', box.address);\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});\nThis will automatically check that the Box contract is upgrade-safe, deploy an implementation contract for the Box contract (unless there is one already from a previous deployment), create a proxy (along with a proxy admin if needed), and initialize it by calling initialize(42).\nThen, in another script, you can use the upgradeProxy function to upgrade the deployed instance to a new version. The new version can be a different contract (such as BoxV2), or you can just modify the existing Box contract and recompile it — the plugin will note it changed.\n// scripts/upgrade-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nconst PROXY_ADDRESS = '0x...'; // Replace with your proxy address\n\nasync function main() {\n const connection = await hre.network.create();\n const { ethers } = connection;\n const upgradesApi = await upgrades(hre, connection);\n\n const BoxV2 = await ethers.getContractFactory('BoxV2');\n await upgradesApi.upgradeProxy(PROXY_ADDRESS, BoxV2);\n console.log('Box upgraded');\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});// scripts/upgrade-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nconst PROXY_ADDRESS = '0x...'; // Replace with your proxy address\n\nasync function main() {\n const connection = await hre.network.create();\n const upgradesApi = await upgrades(hre, connection);\n\n await upgradesApi.upgradeProxy(PROXY_ADDRESS, 'BoxV2');\n console.log('Box upgraded');\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});\n\nNote: While this plugin keeps track of all the implementation contracts you have deployed per network, in order to reuse them and validate storage compatibilities, it does not keep track of the proxies you have deployed. This means that you will need to manually keep track of each deployment address, to supply those to the upgrade function when needed.\n\nThe plugin will take care of comparing BoxV2 to the previous one to ensure they are compatible for the upgrade, deploy the new BoxV2 implementation contract (unless there is one already from a previous deployment), and upgrade the existing proxy to the new implementation.\nBeacon proxies\nYou can also use this plugin to deploy an upgradeable beacon for your contract with the deployBeacon function, then deploy one or more beacon proxies that point to it by using the deployBeaconProxy function.\n// scripts/create-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nasync function main() {\n const connection = await hre.network.create();\n const { ethers } = connection;\n const upgradesApi = await upgrades(hre, connection);\n\n const Box = await ethers.getContractFactory('Box');\n\n const beacon = await upgradesApi.deployBeacon(Box);\n await beacon.waitForDeployment();\n console.log('Beacon deployed to:', await beacon.getAddress());\n\n const box = await upgradesApi.deployBeaconProxy(beacon, Box, [42]);\n await box.waitForDeployment();\n console.log('Box deployed to:', await box.getAddress());\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});// scripts/create-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nasync function main() {\n const connection = await hre.network.create();\n const upgradesApi = await upgrades(hre, connection);\n\n const beacon = await upgradesApi.deployBeacon('Box');\n console.log('Beacon deployed to:', beacon.address);\n\n const box = await upgradesApi.deployBeaconProxy(beacon, 'Box', [42]);\n console.log('Box deployed to:', box.address);\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});\nThen, in another script, you can use the upgradeBeacon function to upgrade the beacon to a new version. When the beacon is upgraded, all of the beacon proxies that point to it will use the new contract implementation.\n// scripts/upgrade-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nconst BEACON_ADDRESS = '0x...'; // Replace with your beacon address\n\nasync function main() {\n const connection = await hre.network.create();\n const { ethers } = connection;\n const upgradesApi = await upgrades(hre, connection);\n\n const BoxV2 = await ethers.getContractFactory('BoxV2');\n await upgradesApi.upgradeBeacon(BEACON_ADDRESS, BoxV2);\n console.log('Beacon upgraded');\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});// scripts/upgrade-box.ts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\nconst BEACON_ADDRESS = '0x...'; // Replace with your beacon address\n\nasync function main() {\n const connection = await hre.network.create();\n const upgradesApi = await upgrades(hre, connection);\n\n await upgradesApi.upgradeBeacon(BEACON_ADDRESS, 'BoxV2');\n console.log('Beacon upgraded');\n}\n\nmain().catch(err => {\n console.error(err);\n process.exit(1);\n});\nUsage in tests\nYou can also use the plugin's functions from your Hardhat tests, in case you want to add tests for upgrading your contracts (which you should!). The API is the same as in scripts.\nImportant: Share a single connection across all tests in a suite. Create the connection once in a before / beforeAll hook, or at module scope using ESM top-level await.\nProxies\nimport { expect } from 'chai';\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\ndescribe('Box', function () {\n let upgradesApi;\n let ethers;\n\n before(async () => {\n const connection = await hre.network.create();\n ({ ethers } = connection);\n upgradesApi = await upgrades(hre, connection);\n });\n\n it('works', async () => {\n const Box = await ethers.getContractFactory('Box');\n const BoxV2 = await ethers.getContractFactory('BoxV2');\n\n const instance = await upgradesApi.deployProxy(Box, [42]);\n const upgraded = await upgradesApi.upgradeProxy(await instance.getAddress(), BoxV2);\n\n const value = await upgraded.value();\n expect(value.toString()).to.equal('42');\n });\n});import { expect } from 'chai';\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\ndescribe('Box', function () {\n let upgradesApi;\n\n before(async () => {\n const connection = await hre.network.create();\n upgradesApi = await upgrades(hre, connection);\n });\n\n it('works', async () => {\n const instance = await upgradesApi.deployProxy('Box', [42]);\n const upgraded = await upgradesApi.upgradeProxy(instance.address, 'BoxV2');\n\n expect(await upgraded.read.value()).to.equal(42n);\n });\n});\nBeacon proxies\nimport { expect } from 'chai';\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\ndescribe('Box', function () {\n let upgradesApi;\n let ethers;\n\n before(async () => {\n const connection = await hre.network.create();\n ({ ethers } = connection);\n upgradesApi = await upgrades(hre, connection);\n });\n\n it('works', async () => {\n const Box = await ethers.getContractFactory('Box');\n const BoxV2 = await ethers.getContractFactory('BoxV2');\n\n const beacon = await upgradesApi.deployBeacon(Box);\n const instance = await upgradesApi.deployBeaconProxy(beacon, Box, [42]);\n\n await upgradesApi.upgradeBeacon(beacon, BoxV2);\n const upgraded = BoxV2.attach(await instance.getAddress());\n\n const value = await upgraded.value();\n expect(value.toString()).to.equal('42');\n });\n});import { expect } from 'chai';\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades/viem';\n\ndescribe('Box', function () {\n let upgradesApi;\n let connection;\n\n before(async () => {\n connection = await hre.network.create();\n upgradesApi = await upgrades(hre, connection);\n });\n\n it('works', async () => {\n const beacon = await upgradesApi.deployBeacon('Box');\n const instance = await upgradesApi.deployBeaconProxy(beacon, 'Box', [42]);\n\n await upgradesApi.upgradeBeacon(beacon, 'BoxV2');\n const upgraded = await connection.viem.getContractAt('BoxV2', instance.address);\n\n const value = await upgraded.read.value();\n expect(value).to.equal(42n);\n });\n});\nUsing with viem\nEvery code example on this page has an ethers / viem toggle; switch the tab to see the viem version. The viem API imports from @openzeppelin/hardhat-upgrades/viem, identifies contracts by name (instead of passing an ethers contract factory), and returns viem contract instances with read and write. Your selected tab is remembered across the page. Addresses use viem's Address type, and transactions are signed by the connection's wallet client (or one you pass with the client option), so viem local accounts such as privateKeyToAccount are supported.\nDifferences from the ethers-based API\nBoth accept the same options and run the same upgrade-safety validations. The following behaviors differ:\n\nOverloaded function names. When you pass a bare function name (no parameter types) for the initializer option or an upgrade call, and the contract has multiple overloads of that name, viem resolves the overload from the argument types, while ethers requires the full function signature in that case.\nFunction reference formats. For the initializer option and upgrade call, viem accepts a function name or a canonical signature such as initialize(uint256). It does not accept a 4-byte selector or non-canonical signature spellings that ethers tolerates.\n\nSolidity tests\nHardhat 3 supports writing tests in Solidity. You can use Solidity to test deployments, upgrades, and upgrade safety via the @openzeppelin/foundry-upgrades Solidity library.\nFor the Solidity API, see Upgrades.sol (deployment and upgrade functions) and Options.sol (common options).\nThis section is optional and is only needed if you want Solidity-based tests.\nProxy source: In Solidity tests, proxies are compiled from the @openzeppelin/contracts version installed in your project (via proxyFilesToBuild() + Hardhat 3's npmFilesToBuild). In scripts and JavaScript/TypeScript tests, proxies come from precompiled bytecode bundled with the plugin. Because the two paths rely on independent sources and compilation settings, the resulting proxy bytecode may not be identical.\nInstall the library and forge-std:\n$ npm install --save-dev @openzeppelin/foundry-upgrades \"github:foundry-rs/forge-std#semver:^1.9.5\"\nConfigure your Hardhat config to enable Solidity tests and expose the artifacts directory to FFI:\nimport { defineConfig } from 'hardhat/config';\nimport hardhatUpgrades, { proxyFilesToBuild } from '@openzeppelin/hardhat-upgrades';\n\nif (!process.env.FOUNDRY_OUT) {\n process.env.FOUNDRY_OUT = 'artifacts/contracts';\n}\n\nexport default defineConfig({\n plugins: [hardhatUpgrades],\n solidity: {\n version: '0.8.28',\n npmFilesToBuild: [...proxyFilesToBuild()],\n },\n test: {\n solidity: {\n ffi: true,\n fsPermissions: {\n readDirectory: ['artifacts/contracts'],\n },\n },\n },\n});import { defineConfig } from 'hardhat/config';\nimport hardhatUpgrades, { proxyFilesToBuild } from '@openzeppelin/hardhat-upgrades/viem';\n\nif (!process.env.FOUNDRY_OUT) {\n process.env.FOUNDRY_OUT = 'artifacts/contracts';\n}\n\nexport default defineConfig({\n plugins: [hardhatUpgrades],\n solidity: {\n version: '0.8.28',\n npmFilesToBuild: [...proxyFilesToBuild()],\n },\n test: {\n solidity: {\n ffi: true,\n fsPermissions: {\n readDirectory: ['artifacts/contracts'],\n },\n },\n },\n});\nAdd a remappings.txt at your project root so the library's imports resolve to the npm package's source:\nopenzeppelin-foundry-upgrades/=node_modules/@openzeppelin/foundry-upgrades/src/\nWrite your Solidity tests using the Upgrades library, the same way you would in a Foundry project. The imports match the Foundry Upgrades API:\n// test/MyContract.t.sol\nimport { Test } from \"forge-std/Test.sol\";\nimport { Upgrades } from \"openzeppelin-foundry-upgrades/Upgrades.sol\";\n\nimport { MyContract } from \"../contracts/MyContract.sol\";\n\ncontract MyContractTest is Test {\n function testDeploy() public {\n address proxy = Upgrades.deployTransparentProxy(\n \"contracts/MyContract.sol:MyContract\",\n msg.sender,\n abi.encodeCall(MyContract.initialize, (42))\n );\n\n assertEq(MyContract(proxy).value(), 42);\n }\n}\nDeploy and upgrade calls work the same as in a standalone Foundry project, including the upgrade safety checks that run automatically. See Using with Foundry for deploy and upgrade examples.\nRun hardhat clean before running your Solidity tests, or include the --force option when running hardhat compile. Any previous build artifacts must be cleared first to avoid duplicate contract definitions when the Solidity-based validation reads the build info:\n$ npx hardhat compile --force\n$ npx hardhat test solidity\nAPI\nSee Hardhat Upgrades API for the full API documentation.OverviewPrevious PageNetwork FilesNext PageOn this pageInstallationUsage in scriptsProxiesBeacon proxiesUsage in testsProxiesBeacon proxiesUsing with viemDifferences from the ethers-based APISolidity testsAPI","tokens":3931,"squid":"ink-security_audits","role":"Sentinel","at":1791260103751,"hash":"13096bf10e95d5ba74d9439aa6df1c3ba75a0498"}
{"url":"https://dev-forum.pyth.network/c/announcements/incidents/11","domain":"dev-forum.pyth.network","title":"Latest Announcements/Incidents topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Incidents\n\n Announcements\n\n Incidents\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Incidents category\n\n ncidents \nThis category is for official updates from the admin team about technical incidents, outages, and service disruptions affecting our platform. Only admins can post here—everyone else can view and stay informed. \n…\n\n read more\n\n 0\n\n 439\n\n May 2025\n\n Powered by Discourse","tokens":993,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260110099,"hash":"d8d4eac388b86d7ee64937bdbed4ff0a3e831eba"}
{"url":"https://ethereum.org/staking/solo/","domain":"ethereum.org","title":"Home stake your ETH | ethereum.org","text":"Edit page (opens in a new tab)What is home staking?\nHome staking is the act of running an Ethereum node connected to the internet and depositing at least 32 ETH to activate a validator, giving you the ability to participate directly in network consensus.\nHome staking is the most direct way to stake. No smart contracts, operators, or custodians stand between you and the protocol. You hold your own keys, actively participate in validating the Ethereum network, and receive network rewards directly. Every other staking method adds layers of technology, middleware, or services on top of this core network activity.\nHome staking increases the decentralization of the Ethereum network, making Ethereum more censorship-resistant and robust against attacks. Other staking methods may not help the network in the same ways. Home staking is the best staking option for securing Ethereum.\nAn Ethereum node consists of both an execution layer (EL) client, as well as a consensus layer (CL) client. These clients are software that work together, along with a valid set of signing keys, to verify transactions and blocks, attest to the correct head of the chain, aggregate attestations, and propose blocks.\nHome stakers are responsible for operating the hardware needed to run these clients. It is highly recommended to use a dedicated machine for this that you operate from home–this is extremely beneficial to the health of the network.\nA home staker receives rewards directly from the protocol for keeping their validator properly functioning and online.\nWhy stake from home?\nHome staking comes with more responsibility but provides you with maximum control over your funds and staking setup.\nKeep all rewardsHome stakers receive 100% of protocol rewards, paid directly by the protocol while your validator is online.Self-sovereigntyKeep your own keys and full custody of your funds at all times. Choose the combination of clients and hardware that allows you to minimize your risk. No third party can make these decisions for you or restrict your withdrawals.Client and geographic diversityHome stakers running minority clients on hardware spread across many locations strengthen the decentralization and security of the network.\nConsiderations before home staking\nAs much as we wish that home staking was accessible and risk free to everyone, this is not reality. There are some practical and serious considerations to keep in mind before choosing to home stake your ETH.\nWhen operating your own node you should spend some time learning how to use the software you've chosen. This involves reading relevant documentation and being attune to communication channels of those dev teams.The more you understand about the software you're running and how proof-of-stake works, the less risky it will be as a staker, and the easier it will be to fix any issues that may arise along the way as a node operator.\nNode setup requires a reasonable comfort level when working with computers, although new tools are making this easier over time. Understanding of the command-line interface is helpful, but no longer strictly required.It also requires very basic hardware setup, and some understanding of minimum recommended specs.\nCurrent community guidance for validator hardware and bandwidth is maintained in the hardware and bandwidth recommendations (EIP-7870) (opens in a new tab). As a rough guide, plan for a 4 TB NVMe SSD, 64 GB of RAM (less can work, but this is the recommended headroom), a solid modern multi-core CPU, and an internet connection of around 50 Mbps download / 25 Mbps upload.Since the Fusaka upgrade introduced PeerDAS, a staking node only needs to store and download a fraction of the network's blob data, significantly reducing disk and bandwidth requirements for home stakers.\nJust like how private keys secure your Ethereum address, you will need to generate keys specifically for your validator. You must understand how to keep any seed phrases or private keys safe and secure. Ethereum security and scam prevention\nHardware occasionally fails, network connections error out, and client software occasionally needs upgrading. Node maintenance is inevitable and will occasionally require your attention. You'll want to be sure you stay aware of any anticipated network upgrades, or other critical client upgrades.\nYour rewards are proportional to the time your validator is online and properly attesting. Downtime incurs penalties proportional to how many other validators are offline at the same time, but does not result in slashing. Bandwidth also matters, as rewards are decreased for attestations that are not received in time. Requirements will vary, but the current hardware and bandwidth recommendations (EIP-7870) (opens in a new tab) suggest around 50 Mbps download and 25 Mbps upload.\nDifferent from inactivity penalties for being offline, slashing is a much more serious penalty reserved for malicious offenses. By running a minority client with your keys loaded on only one machine at time, your risk of being slashed is minimized. That being said, all stakers must be aware of the risks of slashing. More on slashing and validator lifecycle\nComparison of staking options\nDelegated staking, or staking as a service (SaaS)With SaaS providers you're still required to deposit 32 ETH, but don't have to run hardware. You typically maintain access to your validator keys, but also need to share your signing keys so the operator can act on behalf of your validator. This introduces a layer of trust not present when running your own hardware, and unlike solo staking at home, SaaS does not help as much with geographic distribution of nodes. If you're uncomfortable operating hardware but still looking to stake 32 ETH, using a SaaS provider may be a good option for you.Learn more about delegated stakingLiquid & pooled stakingSolo staking is significantly more involved than staking with a pooling service, but offers full access to ETH rewards, and full control over the setup and security of your validator. Pooled staking has a significantly lower barrier to entry. Users can stake small amounts of ETH, are not required to generate validator keys, and have no hardware requirements beyond a standard internet connection. Liquidity tokens enable the ability to exit from staking before this is enabled at the protocol level. If you're interested in these features, pooled staking may be a good fit.Learn more about pooled staking\nHow it works\nGet some hardware: You need to run a node to stakeSync an execution layer clientSync a consensus layer clientGenerate your keys and load them into your validator clientMonitor and maintain your nodeDeposit your stake (32 ETH minimum, up to 2048 ETH per validator) to activate your validator\nOnce your node is synced and your keys are generated, you deposit your stake to activate your validator. A single validator requires a minimum of 32 ETH, and can hold up to 2048 ETH. The network recognizes deposits in around 13 minutes, but new validators pass through an activation queue before they start attesting; its length varies with demand.\nWhile active you will earn ETH rewards. With compounding (0x02) withdrawal credentials, rewards are added to your stake automatically; with regular withdrawals (0x01) credentials, rewards above the initial 32 ETH are periodically swept to your withdrawal address.\nIf ever desired, you can exit as a validator, which eliminates the requirement to be online and stops any further rewards. Your remaining balance will then be withdrawn to the withdrawal address that you designate during setup. Exits can be initiated with your validator signing keys, or triggered directly from your withdrawal address with an execution layer transaction, so ultimate control of your funds always rests with your withdrawal address.\nCompounding and the 2048 ETH maximum\nValidators have one of two types of withdrawal credentials:\n\nRegular withdrawals (0x01): the validator's effective balance is capped at 32 ETH, and any balance above that is automatically swept to your withdrawal address every few days.\nCompounding (0x02): the validator's effective balance can grow up to 2048 ETH. Rewards compound automatically, and you earn rewards on every whole ETH above the 32 ETH minimum, so you can stake flexible amounts like 40 ETH, not just multiples of 32. Only balance above 2048 ETH is swept automatically; withdrawing anything else means manually triggering a partial withdrawal from your withdrawal address, which costs gas.\n\nIf you run multiple validators, you can consolidate them into a single compounding validator without exiting and re-entering the network, reducing your maintenance overhead. Consolidation is requested from your withdrawal address and is subject to processing queues. Switching a validator from 0x01 to 0x02 credentials uses this same mechanism, and cannot be reversed without fully exiting and depositing again.\nMore on staking withdrawals\nGet started on the Staking Launchpad\nThe Staking Launchpad is an open source application that will help you become a staker. It will guide you through choosing your clients, generate your keys and depositing your ETH to the staking deposit contract. A checklist is provided to make sure you've covered everything to get your validator set up safely.\nSolo validators are expected to test their setup and operational skills on the Hoodi testnet before risking funds. Remember it is important to choose a minority client as it improves the security of the network and limits your risk.If you're comfortable with it, you can set up everything needed from the command line using the Staking Launchpad alone.Choose networkStart staking on Hoodi testnet (opens in a new tab)Start staking on Mainnet (opens in a new tab)To make things easier, check out some of the tools and guides below that can help you alongside the Staking Launchpad to get your clients set up with ease. Software tools and guide\nWhat to consider with node and client setup tools\nThere are a growing number of tools and services to help you home stake your ETH, but each come with different risks and benefits.\nAttribute indicators are used below to signal notable strengths or weaknesses a listed staking tool may have. Use this section as a reference for how we define these attributes while you’re choosing what tools to help with your staking journey.\nOpen sourceEssential code is 100% open source and available to the public to fork and useOpen sourceClosed source\nExplore node and client setup tools\nThere are a variety of options available to help you with your setup. Use the above indicators to help guide you through the tools below.\nProducts and services are listed as a convenience for the Ethereum community. Inclusion of a product or service does not represent an endorsement from the ethereum.org website team, or the Ethereum Foundation.\nNode tools\nRocket Pool CLIFrom 8 ETHLinuxmacOSWindowsCLIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)eth-dockerFrom 32 ETHLinuxCLIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalGet started (opens in a new tab)StereumFrom 32 ETHLinuxmacOSWindowsGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)AvadoFrom 10.4 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (opens in a new tab)Get started (opens in a new tab)Vouch + DirkFrom 32 ETHLinuxWindowsCLIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)DAppNodeFrom 10.4 ETHBrowserGUIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)Ethereum on ArmFrom 32 ETHLinuxCLIOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalGet started (opens in a new tab)LaunchnodesFrom 32 ETHLinuxmacOSWindowsCLIAWSAzureOpen sourceAuditedBug bountyBattle testedTrustlessPermissionlessMulti-clientSelf custodyEconomicalVisit on (opens in a new tab) (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)\nPlease note the importance of choosing a minority client as it improves the security of the network, and limits your risk. Tools that allow you to setup minority client are denoted as \"multi-client.\"\nKey Generators\nThese tools can be used as an alternative to the Staking Deposit CLI (opens in a new tab) to help with key generation.\nethdoLinuxWindowsCLIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyGet started (opens in a new tab)Wagyu Key GenLinuxmacOSWindowsGUIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyVisit on (opens in a new tab) (opens in a new tab)Get started (opens in a new tab)AvadoBrowserGUIOpen sourceAuditedBug bountyBattle testedPermissionlessSelf custodyVisit on (opens in a new tab)Get started (opens in a new tab)\nHave a suggestion for a staking tool we missed? Check out our product listing policy to see if it would be a good fit, and to submit it for review.\nExplore home staking guides\nCoinCashew's Ethereum 2.0 Guide (opens in a new tab)Linux (CLI)Somer Esat (opens in a new tab)Linux (CLI)Rocket Pool Node Operators (opens in a new tab)Linux, macOS (CLI)StakeWise Node Operators (opens in a new tab)Linux, Windows, MacOS (CLI)Lido CSM Node Operators (opens in a new tab)Linux (CLI)\nSquad staking: home staking with fault tolerance\nDistributed validator technology (DVT) lets a single validator run across a cluster of machines instead of just one. The validator key is split into shares using distributed key generation, and a threshold of the cluster (for example, any 3 of 4 nodes) must sign together; the full key never exists on any single machine. If one machine fails, goes offline, or is misconfigured, the rest of the cluster keeps the validator attesting.\nFor home stakers this enables \"squad staking\": teaming up with friends or other community members to run validators together, removing the single points of failure of a solo setup and reducing the risk of slashing from a single misbehaving machine. Obol and SSV Network both provide production DVT implementations, used today across home staking, staking as a service, and staking pools.\nMore on distributed validator technology\nRun validators for a staking protocol\nIf you have the hardware and skills to run a node but less than 32 ETH, some staking protocols will match your validator with ETH from their pooled stakers. You post a smaller bond as collateral and run the validator on your own machine; the protocol supplies the rest of the stake, and you earn a share of the rewards.\nThis is a hybrid approach: you keep the responsibilities (and satisfaction) of operating your own hardware, but your validator operates under the protocol's smart contracts, governance, and performance rules, which is a different trust profile from staking your own ETH directly.\nLearn more about how these protocols work, including their trust assumptions and token mechanics, on the pooled staking page.\nMore ways to use your node\nYou don't need to stake at all to put node-operation skills to work. Anyone can run an Ethereum node without depositing any ETH. You get a self-verified view of the chain, your own private endpoint for sending transactions and interacting with applications, and you contribute to the health and resilience of the network. Running a node is also a good way to build experience before activating a validator, with no ETH at risk.\n\nFrequently asked questions\nThese are a few of the most common questions about staking that are worth knowing about.\nA validator is a virtual entity that lives on Ethereum and participates in the consensus of the Ethereum protocol. Validators are represented by a balance, public key, and other properties. A validator client is the software that acts on behalf of the validator by holding and using its private key. A single validator client can hold many key pairs, controlling many validators.\nYes. A validator with compounding (0x02) withdrawal credentials can hold an effective balance of up to 2048 ETH, while the minimum to activate remains 32 ETH. Rewards on a compounding validator are added to its stake automatically, and it earns rewards on every whole ETH above the 32 ETH minimum, so you can stake amounts that aren't multiples of 32. See Compounding and the 2048 ETH maximum.Validators with regular withdrawals (0x01) credentials remain capped at an effective balance of 32 ETH, with any balance above that automatically swept to the withdrawal address every few days.For a compounding validator, only balance above the 2048 ETH maximum is swept automatically. To withdraw anything below that, you trigger a partial withdrawal from your withdrawal address (a transaction that costs gas), which can draw down any balance above the 32 ETH minimum. If you run multiple validators, you can also consolidate them into a single compounding validator without exiting the network.More on staking withdrawals\nGoing offline when the network is finalizing properly will NOT result in slashing. Small inactivity penalties are incurred if your validator is not available to attest for a given epoch (each 6.4 minutes long), but this is very different to slashing. These penalties are slightly less than the reward you would have earned had the validator been available to attest, and losses can be earned back with approximately an equal amount of time back online again.Note that penalties for inactivity are proportional to how many validators are offline at the same time. In cases where a large portion of the network is all offline at once, the penalties for each of these validators will be greater than when a single validator is unavailable.In extreme cases if the network stops finalizing as a result of more than a third of the validators being offline, these users will suffer what is known as a quadratic inactivity leak, which is an exponential drain of ETH from offline validator accounts. This enables the network to eventually self-heal by burning the ETH of inactive validators until their balance reaches 16 ETH, at which point they will be automatically ejected from the validator pool. The remaining online validators will eventually comprise over 2/3 the network again, satisfying the supermajority needed to once again finalize the chain.\nIn short, this can never be fully guaranteed, but if you act in good faith, run a minority client and only keep your signing keys on one machine at a time, the risk of getting slashed is nearly zero.There are only a few specific ways that can result in a validator getting slashed and ejected from the network. At time of writing, the slashings that have occurred have been exclusively a product of redundant hardware setups where signing keys are stored on two separate machines at once. This can inadvertently result in a double vote from your keys, which is a slashable offense.Running a supermajority client (any client used by over 2/3 the network) also holds the risk of potential slashing in the event this client has a bug that results in a chain fork. This can result in a faulty fork that gets finalized. To correct back to the intended chain would require submitting a surround vote by trying to undo a finalized block. This is also a slashable offense and can be avoided simply by running a minority client instead.Equivalent bugs in a minority client would never finalize and thus would never result in a surround vote, and would simply result in inactivity penalties, not slashing.Learn more about the importance of running a minority client.Learn more about rewards, penalties, and slashing\nIndividual clients may vary slightly in terms of performance and user interface, as each are developed by different teams using a variety of programming languages. That being said, none of them are \"best.\" All production clients are excellent pieces of software, that all perform the same core functions to sync and interact with the blockchain.Since all production clients provide the same basic functionality, it is actually very important that you choose a minority client, meaning any client that is NOT currently being used by a majority of validators on the network. This may sound counterintuitive, but running a majority or supermajority client puts you at an increased risk of slashing in the event of a bug in that client. Running a minority client drastically limits these risks.Learn more about why client diversity is critical\nAlthough a virtual private server (VPS) can be used as a replacement to home hardware, the physical access and location of your validator client does matter. Centralized cloud solutions such as Amazon Web Services or Digital Ocean allow the convenience of not having to obtain and operate hardware, at the expense of centralizing the network.The more validator clients running on a single centralized cloud storage solution, the more dangerous it becomes for these users. Any event that takes these providers offline, whether by an attack, regulatory demands, or just power/internet outages, will result in every validator client that relies on this server to go offline at the same time.Offline penalties are proportional to how many others are offline at the same time. Using a VPS greatly increases the risk that offline penalties will be more severe, and increases your risk of quadratic leaking or slashing in the event the outage is large enough. To minimize your own risk, and the risk to the network, users are strongly encouraged to obtain and operate their own hardware.\nEvery withdrawal requires your validator to have a withdrawal address set. New stakers set this at time of key generation and deposit. Stakers from the network's early days who have not yet set a withdrawal address will need to update their withdrawal credentials before withdrawing.For validators with regular withdrawals (0x01) credentials, reward payments (accumulated ETH over the initial 32) are periodically distributed to the withdrawal address automatically. For compounding (0x02) validators, rewards remain staked and compound automatically. You can withdraw any balance above 32 ETH by triggering a partial withdrawal from your withdrawal address.To unlock and receive your entire balance back you must exit your validator. You can do this using your validator signing keys, or trigger it directly from your withdrawal address with an execution layer transaction, meaning your funds remain recoverable even if your signing keys are lost.More on staking withdrawals\nFurther reading\n\nClient diversity statistics and migration guides (opens in a new tab)\nHelping Client Diversity (opens in a new tab) - Jim McDonald 2022\nClient diversity on Ethereum's consensus layer (opens in a new tab) - jmcook.eth 2022\nHow To: Shop For Ethereum Validator Hardware (opens in a new tab) - EthStaker 2022\nEIP-7870: Hardware and bandwidth recommendations (opens in a new tab)\nThe Pectra upgrade: max effective balance and more\n\nTest your Ethereum knowledgeSolo stakingQuestion number 1:Which of the following is NOT a slashable offense?","tokens":5882,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260113367,"hash":"3d6ee984190dac27ee841f5e3377b20ff1fdcc3f"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/migrate-from-hardhat-2","domain":"docs.openzeppelin.com","title":"Migrating from Hardhat 2 | OpenZeppelin Docs","text":"Upgrades PluginsUsing with HardhatMigrating from Hardhat 2Open in ClaudePrerequisite: Migrate your Hardhat project to Hardhat 3 first. See the official Hardhat 3 migration guide.\nBreaking Changes\n\nNo automatic hre.upgrades - Must call factory function explicitly\nFactory functions are async - Require await and network connection\nImport changes - Import factory functions, not just the plugin\nUpdated peerDependencies - hardhat and @nomicfoundation/hardhat-ethers peer dependency versions have been updated for Hardhat 3.\n\nInstall Dependencies\nIf upgrading from a previous version, ensure these packages are in your devDependencies:\nnpm install --save-dev hardhat @nomicfoundation/hardhat-ethers\nUsing viem? The plugin now has a viem API. Install @nomicfoundation/hardhat-viem and viem instead of the ethers packages, register the plugin from @openzeppelin/hardhat-upgrades/viem, and import its upgrades factory from the same path. Contracts are then identified by name and the functions return viem contract instances, so @nomicfoundation/hardhat-ethers is no longer needed. See Using with Hardhat for viem usage examples.\nMigration\nUpdate Config\nIn Hardhat 3, plugins must be explicitly added to the plugins array in your config:\nBefore (Hardhat 2):\nimport '@openzeppelin/hardhat-upgrades';\nAfter (Hardhat 3):\nimport { defineConfig } from 'hardhat/config';\nimport hardhatUpgrades from '@openzeppelin/hardhat-upgrades';\n\nexport default defineConfig({\n plugins: [hardhatUpgrades],\n // ... rest of config\n});\nIf you use the verify task, also add @nomicfoundation/hardhat-verify and configure Hardhat's verify.etherscan.apiKey setting:\nimport { configVariable, defineConfig } from 'hardhat/config';\nimport hardhatVerify from '@nomicfoundation/hardhat-verify';\nimport hardhatUpgrades from '@openzeppelin/hardhat-upgrades';\n\nexport default defineConfig({\n plugins: [hardhatVerify, hardhatUpgrades],\n verify: {\n etherscan: {\n apiKey: configVariable('ETHERSCAN_API_KEY'),\n },\n },\n});\nUpdate Imports\nBefore:\nimport '@openzeppelin/hardhat-upgrades';\nAfter:\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\nAll functions are now exported by the API.\nUpdate Usage\nBefore:\nawait hre.upgrades.deployProxy(MyContract, []);\nAfter:\nconst connection = await hre.network.create();\nconst upgradesApi = await upgrades(hre, connection);\nawait upgradesApi.deployProxy(MyContract, []);\nImportant:\nupgrades receives hre and connection as parameters: upgrades(hre, connection)\nShare the connection across multiple operations; do not create a new one each time (or use hre.network.getOrCreate(), which reuses a connection per network)\nIn tests, create the connection once in a before block or use top-level await (ESM)\n\nExamples\nScripts\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nasync function main() {\n const connection = await hre.network.create();\n const { ethers } = connection;\n const upgradesApi = await upgrades(hre, connection);\n\n const MyContract = await ethers.getContractFactory('MyContract');\n const proxy = await upgradesApi.deployProxy(MyContract, []);\n\n const MyContractV2 = await ethers.getContractFactory('MyContractV2');\n await upgradesApi.upgradeProxy(proxy, MyContractV2);\n}\n\nmain();\nTasks\nimport { task } from 'hardhat/config';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\ntask('deploy', async (args, hre) => {\n const connection = await hre.network.create();\n const { ethers } = connection;\n const upgradesApi = await upgrades(hre, connection);\n const MyContract = await ethers.getContractFactory('MyContract');\n await upgradesApi.deployProxy(MyContract, []);\n});\nTests\nImportant: In Hardhat 3, ethers comes from the connection, not hre.ethers. Share the connection across all tests in a suite.\nBefore (Hardhat 2):\nimport hre from 'hardhat';\nimport '@openzeppelin/hardhat-upgrades';\n\ndescribe('MyContract', () => {\n it('should deploy', async () => {\n const MyContract = await hre.ethers.getContractFactory('MyContract');\n const proxy = await hre.upgrades.deployProxy(MyContract, []);\n });\n});\nAfter (Hardhat 3) - with before hook:\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\ndescribe('MyContract', () => {\n let upgradesApi;\n let ethers;\n\n before(async () => {\n const connection = await hre.network.create();\n ({ ethers } = connection);\n upgradesApi = await upgrades(hre, connection);\n });\n\n it('should deploy', async () => {\n const MyContract = await ethers.getContractFactory('MyContract');\n const proxy = await upgradesApi.deployProxy(MyContract, []);\n });\n});\nAfter (Hardhat 3) - with ESM top-level await:\nimport hre from 'hardhat';\nimport { upgrades } from '@openzeppelin/hardhat-upgrades';\n\nconst connection = await hre.network.create();\nconst { ethers } = connection;\nconst upgradesApi = await upgrades(hre, connection);\n\ndescribe('MyContract', () => {\n it('should deploy', async () => {\n const MyContract = await ethers.getContractFactory('MyContract');\n const proxy = await upgradesApi.deployProxy(MyContract, []);\n });\n});\nNote: upgrades receives hre and connection as parameters.\nHardhat 3 also supports tests written in Solidity. See Solidity tests for setup with @openzeppelin/foundry-upgrades.\nVerify Task (Optional)\nIf your Hardhat config file's verify.etherscan.apiKey setting uses configVariable('ETHERSCAN_API_KEY'), set ETHERSCAN_API_KEY before running Hardhat (or use a provider such as @nomicfoundation/hardhat-keystore):\nETHERSCAN_API_KEY=... npx hardhat verify --network mainnet PROXY_ADDRESS\nThe upgrades plugin extends hardhat-verify's verify task for proxy addresses.\nNote that you do not need to include constructor arguments when verifying if your implementation contract only uses initializers. However, if your implementation contract has an actual constructor with arguments (such as to set immutable variables), then include constructor arguments according to Hardhat's documentation for verifying a contract.\nChecklist\n\nInstall the peer dependencies for the API you use: @nomicfoundation/hardhat-ethers and ethers for the ethers-based API, or @nomicfoundation/hardhat-viem and viem if you are using viem\nAdd hardhatUpgrades to plugins in hardhat.config.ts\nIf using verify, add hardhatVerify to plugins, install @nomicfoundation/hardhat-verify, and configure Hardhat's verify.etherscan.apiKey setting\nReplace import '@openzeppelin/hardhat-upgrades' → import { upgrades } from '@openzeppelin/hardhat-upgrades' in scripts/tests\nAdd const connection = await hre.network.create(); (share connection across operations, don't create new ones)\nReplace hre.ethers → ethers from connection (const { ethers } = connection)\nReplace hre.upgrades.method() → call methods from const upgradesApi = await upgrades(hre, connection)\nUpdate all scripts, tasks, and tests\nNetwork FilesPrevious PageUsing with FoundryNext PageOn this pageBreaking ChangesInstall DependenciesMigrationUpdate ConfigUpdate ImportsUpdate UsageExamplesScriptsTasksTestsVerify Task (Optional)Checklist","tokens":1749,"squid":"ink-security_audits","role":"Sentinel","at":1791260114087,"hash":"dce7b5850e50c15be67fb9738ddffbe2218510ee"}
{"url":"https://ethereum.org/developers/docs/","domain":"ethereum.org","title":"Ethereum development documentation | ethereum.org","text":"Ethereum development documentationEdit page (opens in a new tab)This documentation is designed to help you build with Ethereum. It covers Ethereum as a concept, explains the Ethereum tech stack, and documents advanced topics for more complex applications and use cases.\nEverything here is open-source and community-maintained, so if a page is out of date or missing something useful, open an issue or a pull request. The editing guide (opens in a new tab) walks through how.\nPick a starting point\nReaders arrive with different goals, and the fastest path through these docs depends on what you want to build. A few common entry points:\n\nBuilding a dapp that talks to Ethereum. Start with the technical intro, then work through accounts and transactions. Pick a framework when you're ready to write code.\nWriting a smart contract. Skim the intro if EVM concepts are new, then jump to smart contracts and a programming language.\nRunning a node or staking. Go to nodes and clients, then networking and consensus mechanisms.\nUnderstanding the protocol from the bottom up. The modules below are ordered for this. Read them in sequence.\n\nDevelopment modules\nIf this is your first attempt at Ethereum development, we recommend starting at the beginning and working your way through like a book.\nFoundational topics\nIntro to Ethereum – A quick overview of EthereumIntro to Ether – A quick overview of EtherIntro to dapps – An introduction to decentralized applicationsWeb2 vs Web3 – The fundamental differences that blockchain-based applications provideAccounts – Entities in the network that can hold a balance and send transactionsTransactions – Transfers and other actions that cause Ethereum's state to changeBlocks – The way transactions are batched to ensure state is synchronised across all actorsEthereum virtual machine (EVM) – The EVM handles all the computation on the Ethereum networkOpcodesGas – Computational power required to process transactions, paid for in ETH by transaction sendersNodes and clients – The individuals participating in the network and the software they run to verify transactionsRun a nodeClient diversityNodes as a serviceNode architectureLight clientsArchive nodesBootnodesNetworks – Implementations of Ethereum including test networksConsensus mechanisms – How the individual nodes of a distributed network agree on the current state of the systemProof-of-stakeProof-of-workProof-of-authority\nEthereum stack\nIntro to the stack – An overview of the Ethereum/web3 stackSmart contracts – Programs that reside at an Ethereum address and run functions when triggered by transactionsSmart contract languagesSmart contract anatomySmart contracts librariesInteracting with smart contractsTesting smart contractsCompiling smart contractsDeploying smart contractsNaming smart contractsVerifying smart contractsUpgrading smart contractsSmart contract securitySmart contract formal verificationComposabilityDevelopment networks – Local blockchain environments used to test dapps before deploymentDevelopment frameworks – Tools that make developing with Ethereum easierEthereum client APIs – Convenience libraries that allow your web app to interact with Ethereum and smart contractsJavaScript APIsBackend APIsJSON-RPCAuthentication – How users sign in to Ethereum apps with their wallet instead of a passwordData and analytics – How blockchain data is aggregated, organized and implemented into dappsBlock explorersStorage – Decentralized storage structures and mechanismIntegrated Development Environments (IDEs) – The best environments to write dapp codeProgramming languages – How to get started with Ethereum using languages you may already knowDartDelphi.NETElixirGolangJavaJavaScriptPythonRubyRust\nAdvanced\nBridges – An overview of bridging for developersStandards – Agreed upon protocols for maintaining efficiency and accessibility of projects to the communityToken standardsMaximal extractable value (MEV) – How value is extracted from the Ethereum blockchain beyond the block rewardOracles – How information is injected into the Ethereum blockchainScaling – Methods for preserving decentralization and security as Ethereum growsOptimistic rollupsZero-knowledge rollupsState channelsSidechainsPlasmaValidiumData availability – An overview of problems and solutions relating to data availability in EthereumBlockchain data storage strategiesNetworking layer – Explanation of Ethereum's networking layerNetwork addressesPortal NetworkData structures and encoding – Explanation of the data structures and encoding schema used across the Ethereum stackPatricia Merkle TrieRecursive-length prefix (RLP)Simple serialize (SSZ)Web3 secret storage definition","tokens":1169,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260135205,"hash":"54b1a84e8fca56debcfaa4f1d626a84c40f9131c"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/network-files","domain":"docs.openzeppelin.com","title":"Network Files | OpenZeppelin Docs","text":"Upgrades PluginsUsing with HardhatNetwork FilesOpen in ClaudeOpenZeppelin Hardhat Upgrades, by default, keeps track of all the contract versions you have deployed in an .openzeppelin folder in the project root. You will find one file per network there. It is advised that you commit to source control the files for all networks except the development ones (you may see them as .openzeppelin/unknown-*.json).\nThe format of the files within the .openzeppelin folder is not compatible with those of the OpenZeppelin CLI. If you want to use these plugins for an existing OpenZeppelin CLI project, you have to migrate it first. See Migrate from CLI for instructions.\n<network_name>.json\nOpenZeppelin Hardhat Upgrades will generate a file for each of the networks you work on (mainnet, sepolia, etc.). These files share the same structure:\n// .openzeppelin/<network_name>.json\n\n \"manifestVersion\": \"3.0\",\n \"impls\": {\n \"...\": {\n \"address\": \"...\",\n \"txHash\": \"...\",\n \"layout\": {\n \"storage\": [...],\n \"types\": {...\n }\n },\n \"...\":\n \"address\": \"...\",\n \"txHash\": \"...\",\n \"layout\": {\n \"storage\": [...],\n \"types\": {...\n }\n }\n }\n}\nFor every logic contract, besides the deployment address, the following info is also tracked:\n\ntypes keeps track of all the types used in the contract or its ancestors, from basic types like uint256 to custom struct types\nstorage tracks the storage layout of the linearized contract, referencing the types defined in the types section, and is used for verifying that any storage layout changes between subsequent versions are compatible\n\nThe naming of the file will be <network_name>.json, but note that <network_name> is not taken from the name of the network’s entry in the Hardhat configuration file, but is instead inferred from the chain id associated to the entry.\nThere is a limited set of public chains; Chains not on the list such as Ethereum Classic will have network files named unknown-<chain_id>.json.\nConfiguration Files in Version Control\nPublic network files like mainnet.json or sepolia.json should be tracked in version control. These contain valuable information about your project’s status in the corresponding network, like the addresses of the contract versions that have been deployed. Such files should be identical for all the contributors of a project.\nNetwork files may also appear as unknown-<chain_id>.json if the network name is not known to the Hardhat plugin. If the chain ID corresponds to a public network, then it should also be tracked in version control. However, if the chain ID is for a temporary local network such as a development network, then it is only relevant to a single contributor of the project and should not be tracked in version control.\nTemporary Files\nHardhat development networks using Hardhat version 2.12.3 or later, and Anvil development networks connected from Hardhat, will have network files written to an openzeppelin-upgrades folder under the operating system’s temporary directory. These files are named hardhat-<chain_id>-<instance_id>.json or anvil-<chain_id>-<instance_id>.json, where <instance_id> is a 0x-prefixed hex id that uniquely identifies an instance/run of the Hardhat or Anvil network. Files in this temporary folder can be safely deleted when their corresponding Hardhat or Anvil network instance is no longer active, for example after testing is finished.\nYou can determine the location of a temporary network file by doing the following:\n\nRun export DEBUG=@openzeppelin:* to enable debug logging.\nRun your Hardhat test or script.\nFind the log message containing the text development manifest file:.\n\nCustom Network Files Location\nTo customize the location of the .openzeppelin folder, set the MANIFEST_DEFAULT_DIR environment variable to an absolute path or a path relative to the root of your project. This variable allows you to specify different directories for storing network files, enabling you to deploy the same contracts to the same networks for different environments without conflicts. This can be used with private networks to avoid chain ID conflicts.\nFor example:\n\nRun export MANIFEST_DEFAULT_DIR=.openzeppelin/tests to configure OpenZeppelin Hardhat Upgrades to use .openzeppelin/tests/<network_name>.json for test deployments.\nRun export MANIFEST_DEFAULT_DIR=.openzeppelin/production to configure OpenZeppelin Hardhat Upgrades to use .openzeppelin/production/<network_name>.json for production deployments.\nOverviewPrevious PageMigrating from Hardhat 2Next PageOn this page<network_name>.jsonConfiguration Files in Version ControlTemporary FilesCustom Network Files Location","tokens":1147,"squid":"ink-security_audits","role":"Sentinel","at":1791260136064,"hash":"51588b5f42bc5bd2721e97b2ce1eda867a8129c4"}
{"url":"https://dev-forum.pyth.network/c/announcements/6","domain":"dev-forum.pyth.network","title":"Latest Announcements topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Announcements\n\n Announcements\n\n subcategories\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Welcome to the Announcements category\n\n Announcements\n\n Official updates related to Pyth, Pyth products and more! \nHere you’ll find: \n\n Network and protocol updates \n\n Product releases and feature announcements \n\n Developer tool upgrades…\n\n read more\n\n 0\n\n 499\n\n Mar 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 190\n\n Jul 13\n\n Deprecation of Swellchain, Pyth Oracle on will be unavailable - June 15, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 24\n\n Aug 20\n\n Deprecation of Pyth Core Equity PRE, POST and OVERNIGHT Feeds – 15th June 2026\n\n Announcements\n\n announcements\n\n 1\n\n 128\n\n Jun 17\n\n Deprecation of Price Feeds (CRT, ZENBTC) Price Feed - 31st May, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 28\n\n Jun 2\n\n Deprecation of some Pyth Push Feeds on Sonic EVM – May 15th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 1\n\n 37\n\n May 15\n\n [Deprecation Notice] Pyth Pro `/v1/{channel}/streaming` Endpoint — Sunset May 31, 2026\n\n Announcements\n\n 1\n\n 66\n\n Jun 2\n\n Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 54\n\n Apr 30\n\n Deprecation of Pyth Push Feeds on Aptos – April 30th, 2026\n\n Announcements\n\n announcements,move\n\n 1\n\n 95\n\n May 1\n\n Price Feeds Upcoming Deactivations – April 15th, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 57\n\n Apr 15\n\n 30th April 2026 - Migration of Pyth History API to a New Base URL\n\n Announcements\n\n 0\n\n 111\n\n Mar 30\n\n Pyth Core: Wormhole Guardian Set Upgrade — Action Required for Forks\n\n Announcements\n\n announcements\n\n 0\n\n 76\n\n Mar 3\n\n Pyth Pro: EMA Price and Confidence Fields Now Available\n\n Announcements\n\n 0\n\n 62\n\n Feb 25\n\n Pyth Pro: Update to price `payload` in API Responses\n\n Announcements\n\n 0\n\n 220\n\n Feb 25\n\n Pyth Pro Proxy API\n\n Announcements\n\n 0\n\n 74\n\n Feb 11\n\n Added a new feature in docs for AI\n\n Announcements\n\n announcements\n\n 0\n\n 79\n\n Feb 6\n\n Pyth Pro FAQ now live\n\n Announcements\n\n 0\n\n 81\n\n Feb 2\n\n New Documentation: SVM Error Codes Reference Page\n\n Announcements\n\n svm\n\n 0\n\n 115\n\n Jan 20\n\n Price Feeds Upcoming Deactivations – January 16th, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 130\n\n Jan 19\n\n Deprecation of Pyth Custom TWAP feature — 31st January, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 161\n\n Feb 6\n\n Q1 2026 — Pyth Core Onchain Fees\n\n Announcements\n\n announcements\n\n 0\n\n 133\n\n Jan 7\n\n Q1 2026 — Pyth Entropy Onchain Fees  pyth.network\n\n Announcements\n\n entropy\n\n 1\n\n 151\n\n Feb 12\n\n Deprecation of Pyth Push Feeds - 15th January, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 170\n\n Jan 15\n\n Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 498\n\n Jan 3\n\n Deprecation of Pyth Push Feeds on Soneium - 7th December, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 229\n\n Dec 2025\n\n Deprecation of ALP/USD.RR on Pyth - Sunday, 16th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 261\n\n Nov 2025\n\n Migration from AI16Z/USD to ELIZAOS/USD – Sunday 16th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 273\n\n Nov 2025\n\n Deprecation of DEUSD/USD and SDEUSD/DEUSD.RR feeds on Pyth - 9th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 312\n\n Nov 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 548\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 338\n\n Oct 2025","tokens":1775,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260142370,"hash":"3815caecc0aa22559b509a6162aee9a0ff0e0871"}
{"url":"https://ethereum.org/use-cases/","domain":"ethereum.org","title":"Ethereum use cases: DeFi, payments, NFTs, DAOs, and more | ⁦ethereum.org⁩","text":"While many people know Ethereum for its cryptocurrency, ether, Ethereum is a global platform for building secure, transparent applications. Whether you are managing your finances, verifying your identity, or interacting with communities, Ethereum powers an ecosystem of tools designed to eliminate middlemen and operate with absolute transparency.Financial toolsOpen financial services that anyone can access with an internet connection. No banks to approve accounts, no middlemen to take a cut, and no borders limiting who can participate.Open finance (DeFi)Lend, borrow, trade, and earn interest without middlemen like banks or brokers. You control your money directly.Explore DeFiStablecoinsDigital dollars and other currencies that hold their value. Combine the stability of traditional money with the speed and openness of Ethereum.Get digital dollarsPaymentsSend money anywhere in the world in minutes with low fees. No bank accounts or paperwork required.Send and receiveNovel usesTokenized assets (RWAs)Buy shares of real estate, bonds, and other traditional investments through Ethereum, with lower minimums and fewer barriers.Explore tokenized assetsPrediction marketsPeople put money behind their predictions on future events, producing real-time crowd-sourced forecasts.See the forecastsEthereum for institutionsHow enterprises and institutions are using Ethereum for settlement, tokenization, and infrastructure.Visit institutions hub (opens in a new tab)Restaking: extend Ethereum's security to other networksDigital ownership and gamingOwn digital items in a way that is verifiable, transferable, and independent of any company.Non-fungible tokens (NFTs)Unique digital items with provable ownership. Creators sell directly to audiences and collectors hold verifiable originals.Explore NFTsGamingGames where you truly own your in-game items and game rules are public and can't be changed behind your back.Explore gamesOrganizations and identityMake decisions together, prove who you are, and use social platforms no company controls.Decentralized organizations (DAOs)Community-run organizations where members vote on decisions together. No single person controls the funds or rules.Join a DAODecentralized identityOwn and control your digital identity without relying on big tech. Prove things about yourself without revealing more than necessary.Own your identitySocial networksSocial platforms where you own your data, content, and connections. No company can deplatform you or sell your information.Explore social platformsScience and public goodsFund research directly and coordinate environmental projects without gatekeepers.Decentralized science (DeSci)Open infrastructure for funding, publishing, and crediting scientific research. Making science more transparent and accessible to everyone.Fund open scienceRegenerative finance (ReFi)Financial tools designed to fund environmental and social regeneration rather than extraction.Explore ReFi","tokens":741,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260145136,"hash":"58e8887d56300d423360204e16b15207d3d03deb"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/faq","domain":"docs.openzeppelin.com","title":"Frequently Asked Questions | OpenZeppelin Docs","text":"Upgrades PluginsFrequently Asked QuestionsOpen in ClaudeCan I change Solidity compiler versions when upgrading?\nYes. The Solidity team guarantees that the compiler will preserve the storage layout across versions.\nWhy am I getting the error \"Cannot call fallback function from the proxy admin\"?\nThis is due to the Transparent Proxy Pattern. You shouldn’t get this error when using the OpenZeppelin Upgrades Plugins, since it uses the ProxyAdmin contract for managing your proxies.\nHowever, if you are using OpenZeppelin Contracts proxies programmatically you could potentially run into such error. The solution is to always interact with your proxies from an account that is not the admin of the proxy, unless you want to specifically call the functions of the proxy itself.\nWhat does it mean for a contract to be upgrade safe?\nWhen deploying a proxy for a contract, there are some limitations to the contract code. In particular, the contract cannot have a constructor, and should not use the selfdestruct or delegatecall operations for security reasons.\nAs a replacement for the constructor, it is common to set up an initialize function to take care of the contract’s initialization. You can use the Initializable base contract to have access to an initializer modifier that ensures the function is only called once.\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\n\ncontract MyContract is Initializable {\n uint256 value;\n function initialize(uint256 initialValue) public initializer {\n value = initialValue;\n }\n}\nBoth plugins will validate that the contract you are trying to deploy complies with these rules. You can read more about how to write upgrade safe contracts here.\nHow can I disable some of the checks?\nDeployment and upgrade related functions come with an optional opts object, which includes an unsafeAllow option. This can be set to disable any check performed by the plugin. The list of checks that can individually be disabled is:\n\nstate-variable-assignment\nstate-variable-immutable\nexternal-library-linking\nstruct-definition\nenum-definition\nconstructor\ndelegatecall\nselfdestruct\nmissing-public-upgradeto\ninternal-function-storage\n\nThis function is a generalized version of the original unsafeAllowCustomTypes and unsafeAllowLinkedLibraries allowing any check to be manually disabled.\nFor example, in order to upgrade to an implementation that contains a delegate call, you would call:\nawait upgradeProxy(proxyAddress, implementationFactory, unsafeAllow: ['delegatecall'] );\nAdditionally, it is possible to precisely disable checks directly from the Solidity source code using NatSpec comments. This requires Solidity >=0.8.2.\ncontract SomeContract {\n function some_dangerous_function() public {\n ...\n /// @custom:oz-upgrades-unsafe-allow delegatecall\n (bool success, bytes memory returndata) = msg.sender.delegatecall(\"\");\n ...\n }\n}\nThis syntax can be used with the following errors:\n\n/// @custom:oz-upgrades-unsafe-allow state-variable-immutable\n/// @custom:oz-upgrades-unsafe-allow state-variable-assignment\n/// @custom:oz-upgrades-unsafe-allow external-library-linking\n/// @custom:oz-upgrades-unsafe-allow constructor\n/// @custom:oz-upgrades-unsafe-allow delegatecall\n/// @custom:oz-upgrades-unsafe-allow selfdestruct\n\nIn some cases you may want to allow multiple errors in a single line.\n/// @custom:oz-upgrades-unsafe-allow constructor state-variable-immutable\ncontract SomeOtherContract {\n uint256 immutable x;\n constructor() {\n x = block.number;\n }\n}\nYou can also use the following to allow specific errors in reachable code, which includes any referenced contracts, functions, and libraries:\n\n/// @custom:oz-upgrades-unsafe-allow-reachable delegatecall\n/// @custom:oz-upgrades-unsafe-allow-reachable selfdestruct\n\nCan I safely use delegatecall and selfdestruct?\nThis is an advanced technique and can put funds at risk of permanent loss.\nIt may be possible to safely use delegatecall and selfdestruct if they are guarded so that they can only be triggered through proxies and not on the implementation contract itself. A way to achieve this in Solidity is as follows.\nabstract contract OnlyDelegateCall {\n /// @custom:oz-upgrades-unsafe-allow state-variable-immutable\n address private immutable self = address(this);\n\n function checkDelegateCall() private view {\n require(address(this) != self);\n }\n\n modifier onlyDelegateCall() {\n checkDelegateCall();\n _;\n }\n}\ncontract UsesUnsafeOperations is OnlyDelegateCall {\n /// @custom:oz-upgrades-unsafe-allow selfdestruct\n function destroyProxy() onlyDelegateCall {\n selfdestruct(msg.sender);\n }\n}\nWhat does it mean for an implementation to be compatible?\nWhen upgrading a proxy from one implementation to another, the storage layout of both implementations must be compatible. This means that, even though you can completely change the code of the implementation, you cannot modify the existing contract state variables. The only operation allowed is to append new state variables after the ones already declared.\nBoth plugins will validate that the new implementation contract is compatible with the previous one.\nYou can read more about how to make storage-compatible changes to an implementation contract here.\nWhat is a proxy admin?\nA ProxyAdmin is an intermediary contract that acts as the upgrader of a transparent proxy. Each ProxyAdmin is owned by the deployer address, or by the initialOwner address when deploying a transparent proxy from OpenZeppelin Contracts 5.0 or above. You can transfer the ownership of a proxy admin by calling transferOwnership.\nWhat is an implementation contract?\nUpgradeable deployments require at least two contracts: a proxy and an implementation. The proxy contract is the instance you and your users will interact with, and the implementation is the contract that holds the code. If you call deployProxy several times for the same implementation contract, several proxies will be deployed, but only one implementation contract will be used.\nWhen you upgrade a proxy to a new version, a new implementation contract is deployed if needed, and the proxy is set to use the new implementation contract. You can read more about the proxy upgrade pattern here.\nWhat is a proxy?\nA proxy is a contract that delegates all of its calls to a second contract, named an implementation contract. All state and funds are held in the proxy, but the code actually executed is that of the implementation. A proxy can be upgraded by its admin to use a different implementation contract.\nYou can read more about the proxy upgrade pattern here.\nWhy can't I use immutable variables?\nSolidity 0.6.5 introduced the immutable keyword to declare a variable that can be assigned only once during construction and can be read only after construction. It does so by calculating its value during contract creation and storing its value directly into the bytecode.\nNotice that this behavior is incompatible with the way upgradeable contracts work for two reasons:\n\nUpgradeable contracts have no constructors but initializers, therefore they can’t handle immutable variables.\nSince the immutable variable value is stored in the bytecode its value would be shared among all proxies pointing to a given contract instead of each proxy’s storage.\n\nIn some cases immutable variables are upgrade safe. The plugins cannot currently detect these cases automatically so they will point it out as an error anyway. You can manually disable the check using the option unsafeAllow: ['state-variable-immutable'], or in Solidity >=0.8.2 placing the comment /// @custom:oz-upgrades-unsafe-allow state-variable-immutable before the variable declaration.\nWhy can't I use external libraries?\nAt the moment, the plugins only have partial support for upgradeable contracts linked to external libraries. This is because it’s not known at compile time what implementation is going to be linked, thus making it very difficult to guarantee the safety of the upgrade operation.\nThere are plans to add this functionality in the near future with certain constraints that make the issue easier to address like assuming that the external library’s source code is either present in the codebase or that it’s been deployed and mined so it can be fetched from the blockchain for analysis.\nIn the meantime, you can deploy upgradeable contracts linked to external libraries by setting the unsafeAllowLinkedLibraries flag to true in the deployProxy or upgradeProxy calls, or including 'external-library-linking' in the unsafeAllow array. Keep in mind the plugins will not verify that the linked libraries are upgrade safe. This has to be done manually for now until the full support for external libraries is implemented.\nYou can follow or contribute to this issue in GitHub.\nWhy do I need a public upgradeTo or upgradeToAndCall function?\nWhen using UUPS proxies (through the kind: 'uups' option), the implementation contract must include one or both of the public functions upgradeTo(address newImplementation) or upgradeToAndCall(address newImplementation, bytes memory data). This is because in the UUPS pattern the proxy does not contain an upgrading function itself, and the entire upgradeability mechanism lives on the implementation side. Thus, on every deploy and upgrade we have to make sure to include it, otherwise we may permanently disable the upgradeability of the contract.\nThe recommended way to include one or both of these functions is by inheriting the UUPSUpgradeable contract provided in OpenZeppelin Contracts, as shown below. This contract adds the required function(s), but also contains a built-in mechanism that will check on-chain, at the time of an upgrade, that the new implementation proposed also inherits UUPSUpgradeable or implements the same interface. In this way, when using the Upgrades Plugins there are two layers of mitigations to prevent accidentally disabling upgradeability: an off-chain check by the plugins, and an on-chain fallback in the contract itself.\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol\";\n\ncontract MyContract is Initializable, ..., UUPSUpgradeable {\n ...\n}\nRead more about the differences with the Transparent Proxy Pattern in Transparent vs UUPS.\nCan I use custom types like structs and enums?\nPast versions of the plugins did not support upgradeable contracts that used custom types like structs or enums in their code or linked libraries. This is no longer the case for current versions of the plugins, and structs and enums will be automatically checked for compatibility when upgrading a contract.\nSome users who have already deployed proxies with structs and/or enums and who need to upgrade those proxies may need to use the override flag unsafeAllowCustomTypes for their next upgrade, after which it will no longer be necessary. If the project contains the source code for the implementation currently in use by the proxy, the plugin will attempt to recover the metadata that it needs before the upgrade, falling back to the override flag if this is not possible.\nHow can I rename a variable, or change its type?\nRenaming a variable is disallowed by default because there is a chance that a renaming is actually an accidental reordering. For example, if variables uint a; uint b; are upgraded to uint b; uint a;, if renaming was simply allowed this would not be seen as a mistake, but it could have been an accident, especially when multiple inheritance is involved.\nIt is possible to disable this check by passing the option unsafeAllowRenames: true. A more granular approach is to use a docstring comment /// @custom:oz-renamed-from <previous name> right above the variable that is being renamed, for example:\ncontract V1 {\n uint x;\n}\ncontract V2 {\n /// @custom:oz-renamed-from x\n uint y;\n}\nChanging the type of a variable is not allowed either, even in cases where the types have the same size and alignment, for the similar reason explained above. As long as we can guarantee that the rest of the layout is not affected by this type change, it is also possible to override this check by placing a docstring comment /// @custom:oz-retyped-from <previous type>.\ncontract V1 {\n bool x;\n}\ncontract V2 {\n /// @custom:oz-retyped-from bool\n uint8 x;\n}\nDocstring comments don’t yet work for struct members, due to a current Solidity limitation.\nHow can I use internal functions in storage variables?\nInternal functions in storage variables are code pointers which will no longer be valid after an upgrade, because the code will move around and the pointer would change. To avoid this issue, you can declare those functions as external, or avoid code pointers in storage altogether and define an enum that you will use with a dispatcher function to select from the list of available functions. If you must use internal functions, those internal functions need to be reassigned during each upgrade.\nFor example, the messageFunction variable in the following contract is not upgrade safe. Attempting to call showMessage() after an upgrade would likely result in a revert.\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\n\ncontract V1 is Initializable {\n function() internal pure returns (string memory) messageFunction;\n\n function initialize() initializer public {\n messageFunction = hello;\n }\n\n function hello() internal pure returns (string memory) {\n return \"Hello, World!\";\n }\n\n function showMessage() public view returns (string memory)\n return messageFunction();\n }\n ...\n}\nTo allow the above contract to be deployed by the Upgrades Plugins, you can disable the internal-function-storage check according to How can I disable some of the checks?, but ensure you follow the steps below to reassign the internal function during upgrades.\nIn new versions of this contract, assign the internal function in the storage variable again, for example by using a reinitializer:\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\nimport \"./V1.sol\";\n\ncontract V2 is V1 {\n function initializeV2() reinitializer(2) public {\n messageFunction = hello;\n }\n ...\n}\nThen when upgrading, call the reinitializer function as part of the upgrade process, for example in Hardhat:\nawait upgradesApi.upgradeProxy(PROXY_ADDRESS, ContractFactoryV2, {\n call: 'initializeV2',\n unsafeAllow: ['internal-function-storage']\n});\nor in Foundry:\nUpgrades.upgradeProxy(\n PROXY_ADDRESS,\n \"V2.sol\",\n abi.encodeCall(V2.initializeV2, ())\n);Proxy Upgrade PatternPrevious PageHardhat Upgrades APINext PageOn this pageCan I change Solidity compiler versions when upgrading?Why am I getting the error \"Cannot call fallback function from the proxy admin\"?What does it mean for a contract to be upgrade safe?How can I disable some of the checks?Can I safely use delegatecall and selfdestruct?What does it mean for an implementation to be compatible?What is a proxy admin?What is an implementation contract?What is a proxy?Why can't I use immutable variables?Why can't I use external libraries?Why do I need a public upgradeTo or upgradeToAndCall function?Can I use custom types like structs and enums?How can I rename a variable, or change its type?How can I use internal functions in storage variables?","tokens":3794,"squid":"ink-security_audits","role":"Sentinel","at":1791260148214,"hash":"092930e377e08143814980191cbcd6bbf4f57ac8"}
{"url":"https://dev-forum.pyth.network/t/deprecation-of-swellchain-pyth-oracle-on-will-be-unavailable-june-15-2026/782/2","domain":"dev-forum.pyth.network","title":"Deprecation of Swellchain, Pyth Oracle on will be unavailable - June 15, 2026 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 18\n\n 2 / 2\n\n Aug 19\n\n Aug 20\n\n post by KemarTiti on May 18\n\n KemarTiti\n\n gm Pythians,\nFollowing the scheduled sunset of Swellchain on June 15, 2026, the Pyth oracle will no longer be available on Swellchain from that date onward.\nAs Swellchain winds down, Pyth price feeds will naturally become unavailable on the network accordingly. For developers currently building on Swellchain, the main action item is to migrate to another supported chain ahead of the shutdown. From a Pyth integration perspective, not much changes beyond the need to move your deployment environment.\nTimeline\n\nJune 15, 2026 — Swellchain is scheduled to sunset\n\nWhat developers should do\n\nPlan migration off Swellchain before June 15\nMove any dependencies on Pyth price feeds to another supported chain\nUpdate contracts, infrastructure, and integrations accordingly\n\nReference\n\nSwell announcement: https://x.com/swellnetworkio/status/2049065334536016382\n\n 3 months later\n\n post by KemarTiti on Aug 20\n\n KemarTiti\n\n This has been done already\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 54\n\n Apr 30\n\n Deprecation of ALP/USD.RR on Pyth - Sunday, 16th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 261\n\n Nov 2025\n\n Deprecation of Pyth Sponsored Feeds on Optimism Sepolia - 9th September, 2025\n\n Announcements\n\n announcements\n\n 0\n\n 361\n\n Sep 2025\n\n Powered by Discourse","tokens":1347,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260152545,"hash":"25f1cd94e04a4359dc572deac64f89dda8e9d6a2"}
{"url":"https://ethereum.org/bridges/","domain":"ethereum.org","title":"Introduction to blockchain bridges | ethereum.org","text":"Edit page (opens in a new tab)Web3 has evolved into an ecosystem of L1 blockchains and L2 scaling solutions, each designed with unique capabilities and trade-offs. As the number of blockchain protocols increases, so does the demand to move assets across chains. To fulfill this demand, we need bridges.\n\nWhat are bridges?\nBlockchain bridges work just like the bridges we know in the physical world. Just as a physical bridge connects two physical locations, a blockchain bridge connects two blockchain ecosystems. Bridges facilitate communication between blockchains through the transfer of information and assets.\nLet's consider an example:\nYou're from the USA and are planning a trip to Europe. You have USD, but you need EUR to spend. To exchange your USD for EUR you can use a currency exchange for a small fee.\nBut, what do you do if you want to make a similar exchange to use a different ? Let's say you want to exchange on Ethereum Mainnet for ETH on Arbitrum (opens in a new tab). Like the currency exchange we made for EUR, we need a mechanism to move our ETH from Ethereum to Arbitrum. Bridges make such a transaction possible. In this case, Arbitrum has a native bridge (opens in a new tab) that can transfer ETH from Mainnet onto Arbitrum.\nWhy do we need bridges?\nAll blockchains have their limitations. For Ethereum to scale and keep up with demand, it has required . Alternatively, L1s like Solana and Avalanche are designed differently to enable higher throughput but at the cost of decentralization.\nHowever, all blockchains are developed in isolated environments and have different rules and mechanisms. This means they cannot natively communicate, and tokens cannot move freely between blockchains.\nBridges exist to connect blockchains, allowing the transfer of information and tokens between them.\nBridges enable:\n\nthe cross-chain transfer of assets and information.\n to access the strengths of various blockchains – thus enhancing their capabilities (as protocols now have more design space for innovation).\nusers to access new platforms and leverage the benefits of different chains.\ndevelopers from different blockchain ecosystems to collaborate and build new platforms for the users.\n\nHow to bridge tokens to layer 2\n\nBridge use cases\nThe following are some scenarios where you can use a bridge:\nLower transaction fees\nLet’s say you have ETH on Ethereum Mainnet but want cheaper transaction fees to explore different dapps. By bridging your ETH from the Mainnet to an Ethereum L2 rollup, you can enjoy lower transaction fees.\nDapps on other blockchains\nIf you’ve been using Aave on Ethereum Mainnet to supply USDT but the interest rate you may receive for supplying USDT using Aave on Polygon is higher.\nExplore blockchain ecosystems\nIf you have ETH on Ethereum Mainnet and you want to explore an alt L1 to try out their native dapps. You can use a bridge to transfer your ETH from Ethereum Mainnet to the alt L1.\nOwn native crypto assets\nLet’s say you want to own native Bitcoin (BTC), but you only have funds on Ethereum Mainnet. To gain exposure to BTC on Ethereum, you can buy Wrapped Bitcoin (WBTC). However, WBTC is an token native to the Ethereum network, which means it’s an Ethereum version of Bitcoin and not the original asset on the Bitcoin blockchain. To own native BTC, you would have to bridge your assets from Ethereum to Bitcoin using a bridge. This will bridge your WBTC and convert it into native BTC. Alternatively, you might own BTC and want to use it in Ethereum protocols. This would require bridging the other way, from BTC to WBTC which can then be used as an asset on Ethereum.\nYou can also do all of the above using a centralized exchange. However, unless your funds are already on an exchange, it would involve multiple steps, and you’d likely be better off using a bridge.\n\nTypes of bridges\nBridges have many types of designs and intricacies. Generally, bridges fall into two categories: trusted and trustless bridges.\nTrusted BridgesTrustless BridgesTrusted bridges depend upon a central entity or system for their operations.Trustless bridges operate using smart contracts and algorithms.They have trust assumptions with respect to the custody of funds and the security of the bridge. Users mostly rely on the bridge operator's reputation.They are trustless, i.e., the security of the bridge is the same as that of the underlying blockchain.Users need to give up control of their crypto assets.Through , trustless bridges enable users to remain in control of their funds.\nIn a nutshell, we can say that trusted bridges have trust assumptions, whereas trustless bridges are trust-minimized and don’t make new trust assumptions beyond those of the underlying domains. Here’s how these terms can be described:\n\nTrustless: having equivalent security to the underlying domains. As described by Arjun Bhuptani in this article. (opens in a new tab)\nTrust assumptions: moving away from the security of the underlying domains by adding external verifiers in the system, thus making it less crypto-economically secure.\n\nTo develop a better understanding of the key differences between the two approaches, let’s take an example:\nImagine you’re at the airport security checkpoint. There are two types of checkpoints:\n\nManual Checkpoints — operated by officials who manually check all the details of your ticket and identity before handing over the boarding pass.\nSelf Check-In — operated by a machine where you put in your flight details and receive the boarding pass if everything checks out.\n\nA manual checkpoint is similar to a trusted model as it depends upon a third party, i.e., the officials, for its operations. As a user, you trust the officials to make the right decisions and use your private information correctly.\nSelf check-in is similar to a trustless model as it removes the operator's role and uses technology for its operations. Users always remain in control of their data and don’t have to trust a third party with their private information.\nMany bridging solutions adopt models between these two extremes with varying degrees of trustlessness.\n\nUse bridges\nUsing bridges allows you to move your assets across different blockchains. Here are some resources that can help you find and use bridges:\n\nL2BEAT Bridges Summary (opens in a new tab) & L2BEAT Bridges Risk Analysis (opens in a new tab): A comprehensive summary of various bridges, including details on market share, bridge type, and destination chains. L2BEAT also has a risk analysis for bridges, helping users make informed decisions when selecting a bridge.\nDefiLlama Bridge Summary (opens in a new tab): A summary of bridge volumes across Ethereum networks.\n\nRisk of using bridges\nBridges are in the early stages of development. It is likely that the optimal bridge design has not yet been discovered. Interacting with any type of bridge carries risk:\n\nSmart Contract Risk — the risk of a bug in the code that can cause user funds to be lost\nTechnology Risk — software failure, buggy code, human error, spam, and malicious attacks can possibly disrupt user operations\n\nMoreover, since trusted bridges add trust assumptions, they carry additional risks such as:\n\nCensorship Risk — bridge operators can theoretically stop users from transferring their assets using the bridge\nCustodial Risk — bridge operators can collude to steal the users’ funds\n\nUser's funds are at risk if:\n\nthere is a bug in the smart contract\nthe user makes an error\nthe underlying blockchain is hacked\nthe bridge operators have malicious intent in a trusted bridge\nthe bridge gets hacked\n\nOne recent hack was Solana’s Wormhole bridge, where 120k wETH ($325 million USD) was stolen during the hack (opens in a new tab). Many of the top hacks in blockchains involved bridges (opens in a new tab).\nBridges are crucial to onboarding users onto Ethereum L2s, and even for users who want to explore different ecosystems. However, given the risks involved in interacting with bridges, users must understand the trade-offs the bridges are making. These are some strategies for cross-chain security (opens in a new tab).\n\nFurther reading\n\nEIP-5164: Cross-Chain Execution (opens in a new tab) - June 18, 2022 - Brendan Asselstine\nL2Bridge Risk Framework (opens in a new tab) - July 5, 2022 - Bartek Kiepuszewski\n\"Why the future will be multi-chain, but it will not be cross-chain.\" (opens in a new tab) - January 8, 2022 - Vitalik Buterin\nHarnessing Shared Security For Secure Cross-Chain Interoperability: Lagrange State Committees And Beyond (opens in a new tab) - June 12, 2024 - Emmanuel Awosika\nThe State Of Rollup Interoperability Solutions (opens in a new tab) - June 20, 2024 - Alex Hook\n\nTest your Ethereum knowledgeBlockchain bridgesQuestion number 1:What makes a bridge trustless?","tokens":2194,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260155483,"hash":"60b39becd1b0173fdd44e075b5c29cab7a675c82"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/proxies","domain":"docs.openzeppelin.com","title":"Proxy Upgrade Pattern | OpenZeppelin Docs","text":"Upgrades PluginsProxy Upgrade PatternOpen in ClaudeThis article describes the \"unstructured storage\" proxy pattern, the fundamental building block of OpenZeppelin Upgrades.\nFor a more in depth read, please see our proxy-patterns blog post, which discusses the need for proxies, goes into more technical detail on the subject, elaborates on other possible proxy patterns that were considered for OpenZeppelin Upgrades, and more.\nWhy Upgrade a Contract?\nBy design, smart contracts are immutable. On the other hand, software quality heavily depends on the ability to upgrade and patch source code in order to produce iterative releases. Even though blockchain based software profits significantly from the technology’s immutability, still a certain degree of mutability is needed for bug fixing and potential product improvements. OpenZeppelin Upgrades solves this apparent contradiction by providing an easy to use, simple, robust, and opt-in upgrade mechanism for smart contracts that can be controlled by any type of governance, be it a multi-sig wallet, a simple address or a complex DAO.\nUpgrading via the Proxy Pattern\nThe basic idea is using a proxy for upgrades. The first contract is a simple wrapper or \"proxy\" which users interact with directly and is in charge of forwarding transactions to and from the second contract, which contains the logic. The key concept to understand is that the logic contract can be replaced while the proxy, or the access point is never changed. Both contracts are still immutable in the sense that their code cannot be changed, but the logic contract can simply be swapped by another contract. The wrapper can thus point to a different logic implementation and in doing so, the software is \"upgraded\".\nUser ---- tx ---> Proxy ----------> Implementation_v0\n |\n ------------> Implementation_v1\n |\n ------------> Implementation_v2\nProxy Forwarding\nThe most immediate problem that proxies need to solve is how the proxy exposes the entire interface of the logic contract without requiring a one to one mapping of the entire logic contract’s interface. That would be difficult to maintain, prone to errors, and would make the interface itself not upgradeable. Hence, a dynamic forwarding mechanism is required. The basics of such a mechanism are presented in the code below:\n// This code is for \"illustration\" purposes. To implement this functionality in production it\n// is recommended to use the `Proxy` contract from the `@openzeppelin/contracts` library.\n// https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v4.8.2/contracts/proxy/Proxy.sol\n\nassembly {\n // (1) copy incoming call data\n calldatacopy(0, 0, calldatasize())\n\n // (2) forward call to logic contract\n let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)\n\n // (3) retrieve return data\n returndatacopy(0, 0, returndatasize())\n\n // (4) forward return data back to caller\n switch result\n case 0 {\n revert(0, returndatasize())\n }\n default {\n return(0, returndatasize())\n }\n}\nThis code can be put in the fallback function of a proxy, and will forward any call to any function with any set of parameters to the logic contract without it needing to know anything in particular of the logic contract’s interface. In essence, (1) the calldata is copied to memory, (2) the call is forwarded to the logic contract, (3) the return data from the call to the logic contract is retrieved, and (4) the returned data is forwarded back to the caller.\nA very important thing to note is that the code makes use of the EVM’s delegatecall opcode which executes the callee’s code in the context of the caller’s state. That is, the logic contract controls the proxy’s state and the logic contract’s state is meaningless. Thus, the proxy doesn’t only forward transactions to and from the logic contract, but also represents the pair’s state. The state is in the proxy and the logic is in the particular implementation that the proxy points to.\nUnstructured Storage Proxies\nA problem that quickly comes up when using proxies has to do with the way in which variables are stored in the proxy contract. Suppose that the proxy stores the logic contract’s address in its only variable address public _implementation;. Now, suppose that the logic contract is a basic token whose first variable is address public _owner. Both variables are 32 byte in size, and as far as the EVM knows, occupy the first slot of the resulting execution flow of a proxied call. When the logic contract writes to _owner, it does so in the scope of the proxy’s state, and in reality writes to _implementation. This problem can be referred to as a \"storage collision\".\n|Proxy |Implementation |\n|--------------------------|-------------------------|\n|address _implementation |address _owner | <=== Storage collision!\n|... |mapping _balances |\n| |uint256 _supply |\n| |... |\nThere are many ways to overcome this problem, and the \"unstructured storage\" approach which OpenZeppelin Upgrades implements works as follows. Instead of storing the _implementation address at the proxy’s first storage slot, it chooses a pseudo random slot instead. This slot is sufficiently random, that the probability of a logic contract declaring a variable at the same slot is negligible. The same principle of randomizing slot positions in the proxy’s storage is used in any other variables the proxy may have, such as an admin address (that is allowed to update the value of _implementation), etc.\n|Proxy |Implementation |\n|--------------------------|-------------------------|\n|... |address _owner |\n|... |mapping _balances |\n|... |uint256 _supply |\n|... |... |\n|... | |\n|... | |\n|... | |\n|... | |\n|address _implementation | | <=== Randomized slot.\n|... | |\n|... | |\nAn example of how the randomized storage is achieved, following EIP 1967:\nbytes32 private constant implementationPosition = bytes32(uint256(\n keccak256('eip1967.proxy.implementation')) - 1\n));\nAs a result, a logic contract doesn’t need to care about overwriting any of the proxy’s variables. Other proxy implementations that face this problem usually imply having the proxy know about the logic contract’s storage structure and adapt to it, or instead having the logic contract know about the proxy’s storage structure and adapt to it. This is why this approach is called \"unstructured storage\"; neither of the contracts needs to care about the structure of the other.\nStorage Collisions Between Implementation Versions\nAs discussed, the unstructured approach avoids storage collisions between the logic contract and the proxy. However, storage collisions between different versions of the logic contract can occur. In this case, imagine that the first implementation of the logic contract stores address public _owner at the first storage slot and an upgraded logic contract stores address public _lastContributor at the same first slot. When the updated logic contract attempts to write to the _lastContributor variable, it will be using the same storage position where the previous value for _owner was being stored, and overwrite it!\nIncorrect storage preservation:\n|Implementation_v0 |Implementation_v1 |\n|--------------------|-------------------------|\n|address _owner |address _lastContributor | <=== Storage collision!\n|mapping _balances |address _owner |\n|uint256 _supply |mapping _balances |\n|... |uint256 _supply |\n| |... |\nCorrect storage preservation:\n|Implementation_v0 |Implementation_v1 |\n|--------------------|-------------------------|\n|address _owner |address _owner |\n|mapping _balances |mapping _balances |\n|uint256 _supply |uint256 _supply |\n|... |address _lastContributor | <=== Storage extension.\n| |... |\nThe unstructured storage proxy mechanism doesn’t safeguard against this situation. It is up to the user to have new versions of a logic contract extend previous versions, or otherwise guarantee that the storage hierarchy is always appended to but not modified. However, OpenZeppelin Upgrades detects such collisions and warns the developer appropriately.\nThe Constructor Caveat\nIn Solidity, code that is inside a constructor or part of a global variable declaration is not part of a deployed contract’s runtime bytecode. This code is executed only once, when the contract instance is deployed. As a consequence of this, the code within a logic contract’s constructor will never be executed in the context of the proxy’s state. To rephrase, proxies are completely oblivious to the storage trie changes that are performed by the constructor. It’s simply as if they weren’t there for the proxy. (Note that immutable variables can be reflected in a proxy contract but should be used with caution.)\nThe problem is easily solved though. Logic contracts should move the code within the constructor to a regular 'initializer' function, and have this function be called whenever the proxy links to this logic contract. Special care needs to be taken with this initializer function so that it can only be called once, which is one of the properties of constructors in general programming.\nThis is why when we create a proxy using OpenZeppelin Upgrades, you can provide the name of the initializer function and pass parameters.\nTo ensure that the initialize function can only be called once, a simple modifier is used. OpenZeppelin Upgrades provides this functionality via a contract that can be extended:\n// contracts/MyContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\n\ncontract MyContract is Initializable {\n function initialize(\n address arg1,\n uint256 arg2,\n bytes memory arg3\n ) public payable initializer {\n // \"constructor\" code...\n\n }\n}\nNotice how the contract extends Initializable and implements the initializer provided by it.\nTransparent Proxies and Function Clashes\nAs described in the previous sections, upgradeable contract instances (or proxies) work by delegating all calls to a logic contract. However, the proxies need some functions of their own, such as upgradeTo(address) to upgrade to a new implementation. This begs the question of how to proceed if the logic contract also has a function named upgradeTo(address): upon a call to that function, did the caller intend to call the proxy or the logic contract?\nClashing can also happen among functions with different names. Every function that is part of a contract’s public ABI is identified, at the bytecode level, by a 4-byte identifier. This identifier depends on the name and arity of the function, but since it’s only 4 bytes, there is a possibility that two different functions with different names may end up having the same identifier. The Solidity compiler tracks when this happens within the same contract, but not when the collision happens across different ones, such as between a proxy and its logic contract. Read this article for more info on this.\nThe way OpenZeppelin Upgrades deals with this problem is via the transparent proxy pattern. A transparent proxy will decide which calls are delegated to the underlying logic contract based on the caller address (i.e., the msg.sender):\n\nIf the caller is the admin of the proxy (the address with rights to upgrade the proxy), then the proxy will not delegate any calls, and only answer any messages it understands.\nIf the caller is any other address, the proxy will always delegate a call, no matter if it matches one of the proxy’s functions.\n\nAssuming a proxy with an owner() and an upgradeTo() function, that delegates calls to an ERC20 contract with an owner() and a transfer() function, the following table covers all scenarios:\nmsg.senderowner()upgradeTo()transfer()Ownerreturns proxy.owner()returns proxy.upgradeTo()failsOtherreturns erc20.owner()failsreturns erc20.transfer()\nFortunately, OpenZeppelin Upgrades accounts for this situation, and uses an intermediary ProxyAdmin contract for each transparent proxy. Even if you call the deploy command from your node’s default account, the ProxyAdmin contracts will be the actual admins of your transparent proxies. This means that you will be able to interact with the proxies from any of your node’s accounts, without having to worry about the nuances of the transparent proxy pattern. Only advanced users that create proxies from Solidity need to be aware of the transparent proxies pattern.\nSummary\nAny developer using upgradeable contracts should be familiar with proxies in the ways that are described in this article. In the end, the concept is very simple, and OpenZeppelin Upgrades is designed to encapsulate all the proxy mechanics in a way that the amount of things you need to keep in mind when developing projects are reduced to an absolute minimum. It all comes down to the following list:\n\nHave a basic understanding of what a proxy is\nAlways extend storage instead of modifying it\nMake sure your contracts use initializer functions instead of constructors\n\nFurthermore, the OpenZeppelin Upgrades will let you know when something goes wrong with one of the items in this list.Writing Upgradeable ContractsPrevious PageFrequently Asked QuestionsNext PageOn this pageWhy Upgrade a Contract?Upgrading via the Proxy PatternProxy ForwardingUnstructured Storage ProxiesStorage Collisions Between Implementation VersionsThe Constructor CaveatTransparent Proxies and Function ClashesSummary","tokens":3331,"squid":"ink-security_audits","role":"Sentinel","at":1791260158365,"hash":"6862ddbf5a1000a8750cc7dcd35dc8073d857c03"}
{"url":"https://io.net/docs/guides/announcements/supplier-migration-guide-upgrading-to-m4-series-devices","domain":"io.net","title":"Supplier Migration Guide: Upgrading to M4 Series Devices - io.net","text":"Suppliers on io.net can now seamlessly upgrade their existing inventory of M2 Pro, M2 Max, and M2 Ultra devices to the cutting-edge M4 series. This transition ensures enhanced performance, improved efficiency, and continued eligibility for earnings on the io.net platform.\nImportant Pre-Migration Requirement:Before initiating the migration, ensure your current M2 worker has been actively earning Block Rewards for at least the last 3 continuous hours (i.e., passing PoW tests and contributing work).If this condition is not met, the new M4 device will be automatically blocked during the migration process.\n​Important Migration Dates:\n\nMigration Start: UTC 09:00 AM on April 3rd, 2025\nEnd of Support for M2 Devices: UTC 23:59:59 on April 21st, 2025\nMigration Window Closes: UTC 23:59:59 on April 21st, 2025\n\nOnly currently connected devices with full stake are eligible for migration.\n​M4 Series Device Options\nDeviceEarning MultiplierRay Cluster PricingStaking RequirementM40.5x$0.10/hour$IO 200M4 Pro0.75x$0.13/hour$IO 200M4 Max1x$0.15/hour$IO 200\n​Migration Process:\nStep 1: Disconnect Your M2 Device\nBefore migrating, ensure your M2 Pro, M2 Max, or M2 Ultra device is disconnected from the io.net network.\nStep 2: Execute the Migration Command\nOnce your M2 device is disconnected, run the following command on your new M4, M4 Pro, or M4 Max device:\n./io_net_launch_binary_mac --device_id={same device id} --user_id={same user_id} \n--operating_system=\"macOS\" --usegpus=false --device_name=\"{same device name}\"\n\nStep 3: Ensure Proper Configuration\nYour new M4 series device should be correctly configured with a stable internet connection to avoid loss of Block Rewards during migration.\n​Benefits of Migration:\nWhen migrating to the M4 series, your new device will:\n\nRetain the same device_id\nRetain the same $IO staked (M2 Pro/Max staking requirements match M4/M4 Pro/M4 Max)\nFor M2 Ultra migrations: The excess 50 $IO (beyond the minimum staking requirement) will be withdrawable without a cooldown period after approximately 24-48 hours post-migration.//\n\n​Additional Update:\nThis migration ensures suppliers remain operational on io.net while benefiting from the next-generation M4 series devices. We appreciate your continued support as we drive decentralized computing forward.\nThank you for your continued partnership and support as we move towards a more innovative future together.\nIf you have any questions, please contact io.net support. The io.net TeamWas this page helpful?","tokens":623,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260167065,"hash":"8c7839baddc445edacec955fe9bb1c6a14efcbef"}
{"url":"https://gov.optimism.io/t/upgrade-proposal-stake-based-priority-ordering-experiment/10655/2","domain":"gov.optimism.io","title":"Upgrade Proposal: Stake-Based Priority Ordering Experiment - Proposals 📃 / Protocol Upgrade - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Proposals 📃Protocol Upgrade\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 16\n\n 2 / 2\n\n Apr 16\n\n Apr 16\n\n post by ben-chain on Apr 16\n\n ben-chain\n\n Upgrade Proposal: Stake-Based Priority Ordering Experiment\nProposal Type: Protocol Upgrade\nVoting Cycle: Cycle #52\nExecutive Summary\nThis proposal requests approval for a time-boxed transaction-ordering experiment on OP Mainnet consisting of two phases of stake-based priority ordering.\nUnder the experiment, participants who stake OP tokens into a dedicated smart contract may receive priority transaction treatment for a designated transaction-sending address. The purpose of the experiment is to test whether stake-based priority access changes the behavior of heavy blockspace consumers, including market makers and arbitrage bots, and whether it can reduce spammy or redundant transaction behavior while creating new utility for OP tokens. At the end of the experiment, OP Mainnet will revert to standard PGA ordering.\nImpacted stakeholders include market makers, searchers, blockspace-intensive transactors, integrators, and all other OP Mainnet users. The expected outcome is operational and economic learning, rather than short-term revenue maximization.\nMotivation\nThis proposal is being submitted to allow the Collective to approve a bounded, reversible experiment that changes transaction ordering policy on OP Mainnet.\nThe goal is to test whether a stake-to-prioritize model can:\n\ncreate new utility for OP tokens beyond governance,\n\ninfluence the behavior of sophisticated blockspace consumers,\n\nreduce failed, redundant, or spammy transaction submission patterns,\n\ngenerate data on market maker and arbitrage bot behavior under stake-based ordering, and\n\nhelp inform future blockspace tooling across the Superchain.\n\nTo the best of the proposer’s knowledge, this proposal does not modify any existing Blockspace Charter precommitments relating to transaction ordering.\nSpecifications\n\nBlockspace Charter\n\nNo Blockspace Charter changes are proposed.\n\n**Technical Details\n**\nThe technical details of the experiment are described in more detail in the documentation attached as Attachment 1. At a high level:\n\nThis proposal approves a two-phase, time-boxed experiment in stake-based transaction ordering on OP Mainnet.\nA dedicated staking contract will allow a participant to stake OP from a capital address and optionally link that stake to a separate transaction-sending address. A staker may link to one beneficiary address at a time. If stake is linked to a beneficiary address, the staker’s own address does not also receive the benefit of that same stake.\nEligible transactions will receive priority treatment under the experiment’s ordering rules.\nPhase 1 tests FIFO ordering among eligible participants.\nPhase 2 tests stake-weighted ordering among eligible participants. The current design intent is a bounded, diminishing-returns model that preserves market pricing signals while giving some additional weight based on effective stake and stake age. Current numerical values described in associated design materials are illustrative starting parameters only and are not fixed by this proposal.\nThe proposal delegates exact operational parameters to the Optimism Foundation, including threshold values, weighting-function parameters, rollout timing, monitoring thresholds, and checkpoint decisions, so long as the experiment remains within the scope approved by governance.\nRelevant implementation materials:\n\nStaking contract spec / repository\n\nStaking contract deployment address: The contract is deployed on OP Sepolia at 0xeFcb172De9aA254910A2E93E596F7F5721c17677 with owner address 0xA895C24907D872bC05B58933205dD98090C07446 and a mock ERC20 at 0x3d2536BC0Bc0BAdE9e836C0934419c25b2e0B58C. The Optimism Foundation will post the Mainnet staking address on the Optimism docs in the upcoming weeks.\n\nAudit report / Audit findings / remediation summary\n\nStaked OP are intended to remain outside the control of the Optimism Foundation, and participants are intended to be able to unstake at any time.\n\n**Impact summary\n**\nThis proposal authorizes a temporary change to transaction ordering on OP Mainnet for experimental purposes. The experiment is intended to be reversible, bounded in duration, and subject to standard Optimism Foundation incident-response and operational protocols.\nAnticipated impacts include:\n\nchanges in bidding, spam, and arbitrage behavior by sophisticated blockspace consumers,\n\npossible new demand for OP staking tied to transaction priority,\n\noperational learning around sequencer tooling and ordering policy, and\n\ndata on whether stake-based priority access changes transaction inclusion patterns without degrading sequencer health or ordinary user experience.\n\nIllustrative success metrics from the underlying design work include participation, total OP staked, sequencer health, normal-user impact, fee effects, revert rate, and spam rate. Exact thresholds and response procedures are delegated to the Optimism Foundation under its standard operating protocols.\nThe experiment will automatically conclude after the OP Mainnet test window and OP OP Mainnet will revert to standard PGA ordering.\n\nPrecommitment impact review\n\nAll known precommitments are unaffected.\nNo precommitments are proposed to be modified.\nNo precommitments are proposed to be removed.\n\nAction Plan\nSepolia testing will run for 2–4 weeks prior to commencing the experiment on OP Mainnet. If Sepolia testing is successful and stable, the OP Mainnet experiment may be launched.\nThe OP Mainnet experiment may run for up to 4 weeks total:\n\nPhase 1: up to 1 week\n\nPhase 2: up to 3 weeks\n\nAt the end of the OP Mainnet experiment, OP Mainnet will revert to standard PGA ordering.\nFollowing the experiment, the Optimism Foundation expects to publish learnings and results.\nDisclosures & Disclaimers\nImportant disclosures and disclaimers are attached to this proposal as Attachment 2.\nConclusion\nThis proposal requests approval for a bounded, two-phase experiment in stake-based priority ordering on OP Mainnet. The experiment is intended to generate operational and economic learning while remaining temporary, reversible, and subject to standard operational safeguards.\nThe proposer requests approval from the Optimism Collective to authorize the Optimism Foundation to implement and operate this experiment without requiring a second governance vote between phases, provided the experiment remains within the scope described in this proposal.\nAttachment 1: Stake-based priority ordering on OP Mainnet\n\nAttachment 2: Disclosures & Disclaimers\n\n post by Michael on Apr 16\n\n Michael\n\n Love this experiment, both for OP utility but also for it’s potential to add clarity to what is currently somewhat messy data on market makers & arbitrage.\n\nAre there any specific data points that are of particular interest, especially when considering if this experiment should become permanent?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP as an MEV staking token\n\n ✨ General\n\n Hi everyone, I wanted to make an alternate proposal than Enabling $OP as a gas token on Optimism Network!. This is an approach which mirrors PoS as well as Fuel Labs. \nThis is not a token price scheme, please read the fu…\n\n read more\n\n 13\n\n 3.8k\n\n Aug 2022\n\n Proposal to Align the OP Token with Superchain Success\n\n Proposals 📃\n\n season-9\n\n Proposal to Align OP Token with Superchain Success\nThis proposal was updated on 1/15/26 to reflect community feedback to split the original proposal into two separate proposals. \nExecutive Summary\n\nThis proposal would im…\n\n read more\n\n 36\n\n 4.3k\n\n 1d\n\n [READY] [GF: Phase 1 Proposal] dHEDGE\n\n Governance Fund: Phase 1\n\n cycle-4\n\n Project Name: dHEDGE DAO \nAuthor Name: Jake Richards \nNumber of OP tokens requested: 500,000 OP over 6 months \nL2 Recipient Address: 0x352Fb838A3ae9b0ef2f0EBF24191AcAf4aB9EcEc \nRelevant Usage Metrics: \n\nOptimism TVL: $1…\n\n read more\n\n 42\n\n 6.2k\n\n Aug 2022\n\n [DRAFT] Support missions that should deploy OP stack for testing\n\n ARCHIVED & OLD Missions\n\n season-4\n\n S4 Intent: Progress Towards Technical Decentralization (Intent 1) \nProposed Mission: Support missions that should deploy OP stack for testing \nProposal Tier: Ember \nPlease verify that you meet the qualifications for your…\n\n read more\n\n 10\n\n 1.5k\n\n Jul 2023\n\n [FINAL] Upgrade Proposal #3: Delta Network Upgrade\n\n Protocol Upgrade\n\n Executive Summary\n\nTest in Prod proposes Delta network upgrade, which activates Span Batches for OP Mainnet and all other OP Chains.\nSpan Batches implement a new batching specification that reduces L1 costs by ~97% for i…\n\n read more\n\n 23\n\n 5.1k\n\n Feb 2024","tokens":2208,"squid":"ink-governance","role":"Council Listener","at":1791260171245,"hash":"d2d3ba2c74ad53720f373c3c90d4b5dbc9c59895"}
{"url":"https://aave.com/docs/aave-v3/horizon","domain":"aave.com","title":"Aave Horizon | Aave Protocol Documentation","text":"Aave Horizon RWA Market#\n\nAave Horizon is an initiative by Aave Labs designed to create a robust marketplace for Real-World Assets (RWAs) tailored to institutional and qualified participants. It operates as a licensed, separate instance of the Aave Protocol, initially forking v3.3, to meet the regulatory and compliance requirements associated with RWA products. The core function of the Aave Horizon market is to allow users to supply permissioned, tokenized RWAs as collateral while borrowing permissionless stablecoins. This architecture enables institutions to maintain regulatory compliance while accessing the capital efficiency and liquidity of decentralized finance.\nAave Horizon RWA Market#\nThe Aave Horizon RWA Market is a specialized liquidity protocol designed to bridge institutional finance with the permissionless nature of decentralized finance (DeFi). Its architecture distinctly separates the handling of different asset types and user roles to maintain compliance while unlocking capital efficiency. This separation creates a secure environment where traditional financial institutions can participate in DeFi without compromising their regulatory obligations.\nThe market facilitates the use of tokenized real-world assets (RWAs) as collateral. This aspect is strictly permissioned, limited to qualified users who are allowlisted by the RWA issuers. Compliance is enforced at the asset level through the RWA token's native smart contract, ensuring that only approved participants can interact with these regulated assets. In contrast, the market integrates permissionless liquidity pools for stablecoins like USDC, RLUSD, and GHO, which operate without access restrictions for liquidity providers.\n\nThe core innovation of the Aave Horizon RWA Market lies in how these two sides interact: the ability to borrow from the permissionless stablecoin pools is exclusively granted to users who have supplied permissioned RWA collateral. This model strategically enables institutional entities to leverage their regulated assets to access the liquidity of the DeFi ecosystem within a compliant framework. The result is a unique hybrid system that maintains the security and compliance of traditional finance while unlocking the efficiency of decentralized protocols.\nIntegrations#\nAave Horizon is fully compatible with AaveKit API methods. See getting started guides to integrate Aave programmatically into your application, and specify the Aave Horizon Pool address as demonstrated in the query examples below.\nReactTypeScriptGraphQLimport { useAaveMarket, chainId, evmAddress } from \"@aave/react\";\nfunction HorizonMarketData() { // Query Aave Horizon market data const { data: horizonMarketData, loading, error, } = useAaveMarket({ address: evmAddress(\"0xAe05Cd22df81871bc7cC2a04BeCfb516bFe332C8\"), // Aave Horizon Pool address chainId: chainId(1), });}\nSupplying RWA Collateral#\nParticipation in the Aave Horizon market begins with supplying tokenized real-world assets (RWAs) as collateral. This process is exclusively for users who have been qualified and allowlisted by the specific relevant RWA's issuer. The qualification process typically involves standard institutional onboarding procedures, including identity verification, compliance checks, and agreement to relevant terms and conditions.\nThese supplied RWAs are designated for collateral use only and cannot be borrowed by other market participants. When a user supplies an asset, they receive aTokens representing the collateral position programmatically. A key characteristic of this market is that these receipt tokens are non-transferable, enhancing security and compliance by enforcing that the collateral position remains with the original supplier. This non-transferable nature prevents secondary market trading of collateral positions, maintaining the integrity of the permissioning system.\nThe collateral value is determined through established pricing mechanisms that account for the specific characteristics of each RWA type. Risk parameters, including loan-to-value ratios and liquidation thresholds, are configured according to the underlying asset's risk profile and regulatory requirements.\nBorrowing Stablecoins#\nThe primary borrowable assets in the Aave Horizon market are permissionless stablecoins, such as USDC, RLUSD, and GHO. These stablecoins can be supplied to the market by any participant in a fully permissionless manner to earn yield. Stablecoins cannot be used as collateral themselves, maintaining the clear distinction between the permissioned collateral side and the permissionless liquidity side of the market.\nThe ability to borrow is therefore exclusively available to users who have first supplied and enabled their RWA collateral. This creates a clear separation where regulated, permissioned assets can be used to access permissionless liquidity. The borrowing process follows standard Aave Protocol mechanics, with interest rates determined by utilization curves and market dynamics.\nBorrowers must maintain adequate collateralization ratios as determined by the risk parameters of their supplied RWA collateral. The system continuously monitors these ratios and may trigger liquidation processes if positions become under-collateralized, though the liquidation mechanisms are adapted to account for the unique characteristics of RWA collateral.\nRWA Price Oracle Safeguards#\nUnlike crypto-native assets priced by decentralized exchange markets, RWAs rely on a Net Asset Value (NAV) reported directly by the asset issuer. This introduces a critical risk vector: the potential for delayed, inaccurate, or malicious price reporting. A simple operational error or a malicious act could lead to an incorrect NAV being published onchain, which could trigger faulty liquidations across the market. While an emergency multisig can reactively freeze the reserve, this process introduces operational delays, creating a window where whitelisted liquidators could exploit a faulty price and cause irreparable harm to borrowers.\nAave Horizon implements a robust, automated safeguard directly at the Oracle level to mitigate this risk. In partnership with Chainlink and LlamaRisk, pre-defined upper and lower price bounds are configured for each RWA price feed at the Decentralized Oracle Network (DON) level. When an issuer reports a new NAV, the Chainlink DON validates it against these bounds before publishing it onchain. If the reported NAV is within the bounds, the update is accepted. If it is outside the bounds, the DON rejects the update, and the oracle continues to report the last known valid price. This proactive mechanism prevents a faulty price from ever reaching the Aave Horizon protocol, eliminating the risk of erroneous liquidations. Furthermore, any breach of these price bounds is paired with a time-sensitive reaction from Aave Horizon's emergency multisig to prevent new loan originations and additional exposure until the root cause analysis is performed.\nAdministrative Functions and Edge Case Management#\nThe structure of the Aave Horizon market provides mechanisms for account recovery and management in exceptional circumstances, facilitated by the RWA issuers. These administrative functions are essential for institutional participation, as they provide pathways for resolution in complex scenarios that may arise in regulated environments.\nFor instance, if a user loses access to their private keys, the asset issuer has administrative capabilities to assist in migrating the user's entire collateral and borrow position to a new, secure wallet. This recovery process maintains the integrity of the market while providing essential operational flexibility for institutional users.\nThere may be circumstances where the issuer is legally required to take steps to secure a position. For example, the issuers will have functionality to prevent a user from increasing their borrow position while coordinating with relevant parties on a resolution, thereby preserving the market’s collateralization and compliance.\nThe administrative framework is designed to be transparent and accountable, with clear governance structures determining how these exceptional powers can be exercised. This provides institutional participants with confidence that their interests are protected while maintaining the decentralized nature of the underlying protocol.\nFor more information on the implementation of RwaAToken functions and roles, see the tokenization documentation.\nFor more information on Aave Horizon RWA Market governance, see access controls.PreviousUmbrellaNextGuides","tokens":2149,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260171274,"hash":"7ee0e0111421b4801bf7b6c6a6551e089b748582"}
{"url":"https://io.net/docs/guides/announcements/announcements","domain":"io.net","title":"Overview - io.net","text":"This section provides key information on platform upgrades, new features, and essential changes that impact suppliers and users.\n​​Service Update: Bare Metal (Self Serve) Moving ForwardBare Metal on Demand will no longer be available starting Wednesday, October 1, 2025.\nIf you need Bare Metal, please contact our sales team at business@io.net for managed services.\nFor self-service compute, check out our latest option: Virtual Machines on Demand.\n\n​​Important: Action Required for Expired Refresh TokensSome suppliers using older refresh tokens (generated before our switch to non-expiring tokens) may experience token expiration after 365 days — causing worker downtime and authentication errors.For full details and steps to resolve the issue, please refer to the Action Required for Expired Refresh Tokens\n​​Supplier Migration to M4 Series – Upgrade Now!Suppliers on io.net can now seamlessly upgrade their existing inventory of M2 Pro, M2 Max, and M2 Ultra devices to the cutting-edge M4 series. This transition offers enhanced performance, improved efficiency, and ensures continued eligibility for earnings on the io.net platform.For full details on the migration process, please refer to the Supplier Migration Guide: Upgrading to M4 Series DevicesWas this page helpful?","tokens":320,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260180896,"hash":"bafbef3a6fda3c70480868b199a6ae2d36ae0d26"}
{"url":"https://aave.com/docs/aave-v3/smart-contracts/pool-addresses-provider","domain":"aave.com","title":"Pool Addresses Provider | Aave Protocol Documentation","text":"PoolAddressesProvider#\nThe PoolAddressesProvider contract is the main registry of addresses that are part of, or connected to the Protocol, including permissioned roles. It acts as a factory of proxies and is the admin of those, and therefore has the right to change its implementations.\nThe addresses provider manages various protocol modules and has the ability to update pointers (e.g. update the ACLManager contract) or update the implementation of proxy contracts (e.g. update the Pool implementation).\nIt specifies the initial holder of the DEFAULT_ADMIN_ROLE, it is immutable, and the address will never change.\nWhenever the Pool contract is needed, we recommended you fetch the\ncorrect address from this PoolAddressesProvider smart contract.\nThe source code is available on GitHub.\nThis contract is owned by the Aave Governance.\nWrite Methods#\nsetMarketId#\nfunction setMarketId(string memory newMarketId) external override onlyOwner\nUpdates the identifier of the Aave market by associating an id with a specific PoolAddressesProvider. This can be used to create an on-chain registry of pool addresses providers to identify and validate multiple Aave markets.\nInput Parameters:#\nNameTypeDescriptionnewMarketIdstringThe new id of the market\nsetAddress#\nfunction setAddress(bytes32 id, address newAddress) external override onlyOwner\nSets the address of the protocol contract stored at the given id, replacing the address saved in the addresses map.\nFor example, utils.keccak256(utils.toUtf8Bytes(\"INCENTIVES_CONTROLLER\")), is set to the address of INCENTIVES_CONTROLLER.\nUse this function carefully, as it will do a hard replacement of the current\naddress in the addresses map.\nInput Parameters:#\nNameTypeDescriptionidbytes32keccak256 hash of UTF8Bytes string representing contractnewAddressaddressThe new address to be set corresponding to the id\nsetAddressAsProxy#\nfunction setAddressAsProxy(bytes32 id, address newImplementationAddress) external override onlyOwner\nUpdates the implementation address of a proxy contract with a specified id.\nIf there is no proxy registered, it will instantiate one and set the implementation as the newImplementationAddress.\nUse this function carefully, only for ids that do not have an explicit setter\nfunction in order to avoid unexpected consequences.\nInput Parameters:#\nNameTypeDescriptionidbytes32The id of the proxy contractnewImplementationAddressaddressThe address of new implementation contract corresponding to the proxy\nsetPoolImpl#\nfunction setPoolImpl(address newPoolImpl) external override onlyOwner\nUpdates the implementation of the Pool contract, or creates a proxy.\nInput Parameters:#\nNameTypeDescriptionnewPoolImpladdressThe address of new Pool implementation contract\nsetPoolConfiguratorImpl#\nfunction setPoolConfiguratorImpl(address newPoolConfiguratorImpl) external override onlyOwner\nUpdates the implementation of the PoolConfigurator contract, or creates a proxy.\nInput Parameters:#\nNameTypeDescriptionnewPoolConfiguratorImpladdressThe address of new PoolConfigurator implementation contract\nsetPriceOracle#\nfunction setPriceOracle(address newPriceOracle) external override onlyOwner\nUpdates the address of the price oracle.\nInput Parameters:#\nNameTypeDescriptionnewPriceOracleaddressThe address of new price oracle\nsetACLManager#\nfunction setACLManager(address newAclManager) external override onlyOwner\nUpdates the address of the Access Control List Manager.\nInput Parameters:#\nNameTypeDescriptionnewAclManageraddressThe address of the new ACLManager\nsetACLAdmin#\nfunction setACLAdmin(address newAclAdmin) external override onlyOwner\nUpdates the address of the Access Control List Admin.\nInput Parameters:#\nNameTypeDescriptionnewAclAdminaddressThe address of new ACLAdmin\nsetPriceOracleSentinel#\nfunction setPriceOracleSentinel(address newPriceOracleSentinel) external override onlyOwner\nUpdates the address of the price oracle sentinel.\nInput Parameters:#\nNameTypeDescriptionnewPriceOracleSentineladdressThe address of new PriceOracleSentinel\nsetPoolDataProvider#\nfunction setPoolDataProvider(address newDataProvider) external override onlyOwner\nUpdates the address of the data provider.\nInput Parameters:#\nNameTypeDescriptionnewDataProvideraddressThe address of new DataProvider\nView Methods#\ngetMarketId#\nfunction getMarketId() external view override returns (string memory)\nReturns the market id of the associated Aave market.\nReturn Values:#\nTypeDescriptionstringA string representation of the market id\ngetAddress#\nfunction getAddress(bytes32 id) public view override returns (address)\nReturns the address of protocol contract stored at the given id. The returned address might be an EOA or a contract, which may be proxied. It will return ZERO if there is no registered address with the given id.\nInput Parameters:#\nNameTypeDescriptionidbytes32The id. For example, the Protocol Data Provider uses id 0x1\nReturn Values:#\nTypeDescriptionaddressThe address associated with the id passed\nExample:#\n// Get address of incentive controllerimport { utils } from \"@ethers/lib/utils\";\nconst id = utils.keccak256(utils.toUtf8Bytes(\"INCENTIVES_CONTROLLER\"));const address = poolAddressProvider.getAddress(id);\ngetPool#\nfunction getPool() external view override returns (address)\nReturns the address of the latest Pool proxy contract.\nReturn Values:#\nTypeDescriptionaddressThe address of the associated Pool proxy\ngetPoolConfigurator#\nfunction getPoolConfigurator() external view override returns (address)\nReturns the address of the PoolConfigurator proxy. Used for configuration methods, like init reserves or update token implementation etc, of the market.\nReturn Values:#\nTypeDescriptionaddressThe PoolConfigurator proxy address\ngetPriceOracle#\nfunction getPriceOracle() external view override returns (address)\nReturns the address of the Price Oracle used by the market.\nReturn Values:#\nTypeDescriptionaddressThe address of the price oracle used by the associated market\ngetACLManager#\nfunction getACLManager() external view override returns (address)\nReturns the address of the Access Control List Manager (ACLManager) that manages the system role of the market.\nReturn Values:#\nTypeDescriptionaddressThe address of the ACLManger contract managing the system role of the associated market\ngetACLAdmin#\nfunction getACLAdmin() external view override returns (address)\nReturns the address of the Access Control List Admin (ACLAdmin) of the market which holds the DEFAULT_ADMIN_ROLE in ACLManager.\nReturn Values:#\nTypeDescriptionaddressThe address of the Access Control List admin of the associated market\ngetPriceOracleSentinel#\nfunction getPriceOracleSentinel() external view override returns (address)\nReturns the address of the price oracle sentinel.\nReturn Values:#\nTypeDescriptionaddressThe address of the PriceOracleSentinel of the associated market\ngetPoolDataProvider#\nfunction getPoolDataProvider() external view override returns (address)\nReturns the address of latest pool data provider.\nReturn Values:#\nTypeDescriptionaddressThe address of the pool data provider of the associated marketPreviousOraclesNextPool Configurator","tokens":1775,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260183796,"hash":"89ee50da02dec7b02899910a101d6b2b9b19067d"}
{"url":"https://gov.optimism.io/t/proposal-to-align-the-op-token-with-superchain-success/10527/39","domain":"gov.optimism.io","title":"Proposal to Align the OP Token with Superchain Success - Proposals 📃 - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 3\n\n 3\n\n 2\n\n 2\n\n read \n\n 15\n min\n\n Jan 7\n\n 39 / 39\n\n Oct 3\n\n 1d ago\n\n Load more posts above\n\n post by system on Jan 15\n\n system\n\n On OTC execution: We appreciate the community’s feedback and the thoughtful alternatives suggested. For the first iteration of buybacks, we recommend starting with OTC execution primarily for operational simplicity and reliability, allowing us to execute swaps cleanly without introducing additional smart contract risk or other complex dynamics during early rollout. OTC also enables better price discovery by accessing deeper liquidity than currently exists on OP Mainnet, while improving Optimism Mainnet liquidity is a core long-term goal. This helps reduce the impact of slippage that would ultimately reduce value to the ecosystem. We agree that onchain mechanisms such as DEX execution, Dutch auctions and Tip Jar claims offer strong transparency guarantees. In the meantime, all OTC trades will be reported publicly, either via stats.optimism.io or via the governance forum. The program is not designed to have any interaction whatsoever with existing private or employed OP holders: providers are being selected based on who can fill the Foundation’s operational, financial, and legal requirements. In short, starting with OTC gives us a pragmatic baseline while we work toward onchain execution and exploring the alternatives mentioned is very much part of that path. We’re happy to discuss any of the above in more detail on the upcoming community call on January 20nd.\n\n post by OPUser on Jan 15\n\n OPUser\n\nOverall, I am in favour of the proposal but would have loved to see the 2026 plan first; there is no guarantee that this proposal will have much impact if the project’s fundamentals and adoption are struggling, not to mention the opportunity cost of using the funds.\n\n post by Milo on Jan 17\n\n Milo\n\n Buybacks = good.\nThis is a great and much needed proposal.\nI also think it’s totally fine to have a buyback program alongside emissions, even if they technically cancel out (partially). The meme of the buyback is important. It allows people to clearly project what would happen if the superchain grows 100x. That narrative supports token price, which fuels growth. Without that narrative, $OP is seen as ‘just a useless governance token’.\n\n post by 0xOuterGod on Jan 18\n\n 0xOuterGod\n\n I am glad to know that the OP Foundation has understood the need to align $OP tokenholders to the Superchain economy, however, I do not believe that the proposal under discussion will be beneficial in the long term. As long as the Superchain remains the beating heart of the technological infrastructure in terms of rollup adoption (Base, Ink, Unichain, etc.), it must also be accountable to all $OP stakeholders, including Superchain users themselves, not just tokenholders with voting power.\nAs @Myles said, buybacks are a very useful tool, but they don’t necessarily generate utility for the ecosystem. Before even thinking about the actual buyback strategy, I would solve two important problems, one of which emerged in the original proposal itself:\n\nThere isn’t enough deep liquidity on DEXs.\nThe issue of emissions persists after all these years.\n\n@GFXlabs certainly has better tools and expertise than I do to report on emissions issues, but the point I would like to make is that it makes no sense to seek OTC partners when there is a lack of liquidity on the Superchain itself.\nWhy would anyone buy OP if OP Foundation itself is uncapable of doing it on its infrastructure?\nIt makes much more sense not to pass the proposal and to listen to the community on this issue.\n\nCounter-Proposal: No Buybacks & No Discretion over ETH Treasury\nThe Optimism Foundation has clearly been unable to manage the ETH Treasury, let alone properly incentivize adoption of the $OP governance token, to the extent that the idea of relying on an OTC agreement for the token buyback has been proposed.\nOTC agreements are not only less transparent than on-chain buyback models, but they also do not return value to all stakeholders as they have less impact on price action.\nMy (current) counter-proposal:\n\nSeparate the alignment proposal into two separate proposals, as suggested by other users.\nCancel the $OP buyback proposal and focus efforts on reducing emissions and improving liquidity on the Superchain.\nReduce the Foundation’s discretionary power over the ETH Treasury, entrusting it entirely to Governance, and therefore to $OP tokenholders, aiming for proposals based on informed analysis.\n\nTo make a better contribution, I would focus this message exclusively on improving on-chain liquidity: a buyback model is not acceptable without first building a sufficiently liquid market. For this reason, I propose:\n\nOffering liquidity on the OP/WETH pools on Uniswap V3 or V4 and Velodrome V2 Slipstream using sequencer fees in order to improve on-chain liquidity and enable potential future buyback programs. If you look at the liquidity depth of the following charts, you’ll notice how they’re thin and unable to provide any reliability for wealthy investors or buyback program models.\nclamm_212156×2016 305 KB\n\nEntering into agreements with lending protocols (AAVE, Morpho, Compound, Fluid) to ensure favorable conditions for those borrowing stablecoins against OP, discouraging grant recipients from dumping their allocations in OP.\n\nIn order to do that, we need to start with a better liquidity structure, one that is not based on a series of illiquid pools like the ones I am showing here.\nLet’s look at the two main pools, 0x68F5C0A2DE713a54991E01858Fd27a3832401849 on Uniswap V3 (30bps) and 0x4dc22588ade05c40338a9d95a6da9dcee68bcd60 on Velodrome (dynamic 5bps), which have ~$645K and ~$425K TVL, respectively. If OP Foundation would allocate even a fraction of its sequencer fees single-side on Velodrome and/or Uniswap in WETH token, it would be possible to support $OP token price, and maybe allow the Community to ask for a decent on-chain buyback model.\nAnother positive aspect of POL (Protocol Owned Liquidity) is that OP Foundation would accumulate OP from open market via trading fees, which could be burned forever or used in other ways (liquidity mining, grants, autocompound, etc…).\n\nHope my contribute can be helpful to anyone of this community, open to discussion about data and serious proposals, hoping that OP Foundation listens the community on this. I trust that TradFi non-sense doesn’t ruin Superchain growing economy.\n\n post by Manugotsuka on Jan 19\n\n Manugotsuka\n\n The following reflects the views of L2BEAT’s governance team, composed of @kaereste and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.\nOverall, it’s good to see OP value accrual being addressed more directly. A buyback mechanism can help create a clearer connection between Superchain activity and OP demand, and in that sense, it can be read as a signal of confidence in the ecosystem.\nThat said, buybacks on their own don’t automatically lead to long-term value capture. More clarity on why holding OP is preferred over alternatives like burning, or what concrete future uses are being considered, would make the value-accrual path easier to assess.\nOn the execution side, the use of OTC providers is typically intended to help manage liquidity and market impact. At the same time, since this introduces a recurring source of buy pressure, additional transparency around how OTC execution will work in practice would be helpful. More details on how this mechanism will be handled could help delegates and tokenholders feel more comfortable with this action. Similarly, the choice to allocate 50% of Superchain revenue to buybacks is presented as a reasonable starting point, but some context on how this number was reached, and whether alternatives were considered, will be helpful as well.\nOn the treasury management side, actively using ETH instead of leaving it idle should improve capital efficiency, but expanding the Foundation’s discretion makes clear guardrails and review processes especially important. While the buyback program is framed as a 12-month initiative, it would be helpful to clarify whether the same re-evaluation timeline applies to the expanded ETH management mandate. Given that these are two distinct policy decisions, splitting the buyback and treasury management changes into separate proposals could also allow each to be evaluated on its own merits and lead to clearer mandates.\n\n post by DerKrieg on Jan 19\n\n DerKrieg\n\n I personally support the critics of the proposal. Buyback on their own are not a solution for the lack of utility of OP.\n\n post by GFXlabs on Jan 20\n\n GFXlabs\n\nRealistically, you’re talking about $500k in buybacks over a month period. It is trivial to use the many routers present on Optimism that integrate both onchain and offchain execution, particularly if the monthly buyback is broken into weekly or bi-weekly tranches.\nWe recommend you try execution the includes onchain first, and if it doesn’t perform satisfactorily, then try OTC as a fallback for better price.\nScreenshot 2026-01-20 at 12.51.51 PM2082×982 310 KB\n\n post by system on Jan 22\n\n system\n\n Manugotsuka\n\n Thanks for the thoughtful feedback @Manugotsuka! We discussed these topics on the community call but since not everyone was able to attend, I’ll provide a summary here as well.\n\nWe’ve proposed 50% of revenue based on analyses we did on trading volumes, the relative size / impact of other buyback programs, etc. 50% also allows us to continue accruing ETH to the treasury and retain optionality over future uses of that ETH. We did consider the full range of alternatives and landed on 50% as the starting point that best balanced near term impact with future adaptability.\n\nWe have decided to hold the repurchased OP, rather than burn it, as it allows for the same optionality over future use. We could also burn OP without doing a buyback, so it’s not the burn that creates the connection between Superchain success and OP.\n\n100% agree with the need for transparency around OTC execution and the Foundation will make all relevant data public on a monthly basis. We agree that OTC is not the optimal long term execution mechanism; however, we do believe it is the optimal short term execution path (for reasons we discussed on the community call) and aim to transition this to an onchain mechanism within ~6 months. We’ve already taken the first step on this path with Protocol Upgrade 18.\n\n post by GS4ever on Jan 22\n\n GS4ever\n\n It is time to get OP brand back to the top again. Dismal token performance repels any interested explorer to the chain. It may sound not logical but it is the reality. Lets make OP great again.\n\n post by Johnwick on Jan 23\n\n Johnwick\n\n As a citizen I am unable to cast my vote on this proposal. What could be the issue?\nThank you. Besides that great thread, with so many meaningful contributions.\nCitizen Registration S93200×1398 340 KB\nVote Proposal3200×1398 405 KB\n\n post by Jonas on Jan 23\n\n Jonas\n\n Hey @Johnwick - could you please reach out to me on TG so we can resolve this? My TG is @jonassft.\nFor anyone, else experiencing problems - please also contact me via Telegram \n\n post by mekaguardians on Jan 23\n\n mekaguardians\n\n This is a very bold move, and I’m a little skeptical about this proposal, it’s a 50/50 split. But I hope for the best if it’s approved.\n\n post by Johnwick on Jan 23\n\n Johnwick\n\n Jonas\n\n Thanks Jonas. Let me hit you up on Telegram.\n\n post by system on Jan 26\n\n system\n\n Manugotsuka\n\n To further address how OTC execution will work in practice: If the proposal is approved, the Foundation will execute the monthly conversions with an OTC provider within predetermined parameters designed to eliminate execution discretion by the Foundation. These parameters include the amount of ETH to be converted to OP (which will be based on verifiable monthly sequencer revenue) and execution timing (which will be based on a predetermined window). The Foundation confirms that it has no prior agreements with the OTC provider for other OTC services, and that it has been assured that the execution fee will not exceed a maximum limit, determined in advance. Furthermore, all OTC trades will be reported publicly on a monthly basis, either via stats.optimism.io or via the governance forum. Finally, this is meant to be a temporary implementation and we aim to transition execution to an onchain mechanism within ~6 months.\n(other points previously addressed here.)\n\n post by GFXlabs on Jan 26\n\n GFXlabs\n\nWhy does it take 6 months to transition to an onchain mechanism? OP purchases can be done today without OTC.\n\nWhy pay any fee at all? Some routers internalize a fee, but you can still see best-execution price when you compare across them like in this screenshot:\n\nPeople would be less confused if there was some reason to utilize OTC specifically when Optimism has a host of routers that combine DeFi and CeFi quotes for best execution. It is not as if the entire buyback must occur on a single day each month, and onchain swaps are capable of executing any buyback program of the scale Optimism is likely to need.\nOTC seems like a poor choice vs onchain execution in terms of transparency, fees, and ensuring best price execution.\nWe encourage voters to vote Against this proposal.\n\n post by Griff on Jan 26\n\n Griff\n\n I am voting AGAINST\nI love the idea of a 50% buy back… but I HATE the idea of OTC, and there is no need to wait 6 months… If you need to do it in a centralized way as a transition that makes perfect sense, but doing OTC takes volume away from the builders… Why would we do that?\nBut the main reason to vote against is what @Michael says:\n\n post by DeFi3053 on Jan 27\n\n DeFi3053\n\n Great and exciting plan\n\n post by Axia on Jan 27\n\n Axia\n\n Axia voted FOR this proposal. Aligning the OP token with Superchain success and revenue is an important step for Optimism as it continues to mature. The fundamental premise of this proposal: linking blockspace consumption across the Superchain to demand for OP —creates a sustainable tokenomics model.\nThat said, Axia will be closely monitoring this 12 month program and expects the following:\n1.Comprehensive Dashboards\nThe Foundation mentioned publishing a dashboard to track execution data for the buyback. In addition, there should also be a dashboard that includes value alignment metrics that specifically demonstrate the relationship between the OP token price and Superchain revenue. For example:\n\nOP price correlation with Superchain revenue growth\n\nNet supply change (emissions vs. buybacks)\n\nSuperchain transaction volume trends alongside OP price movements\n\nRevenue run-rate projections and their implications for future buyback capacity\n\nBuyback volume as a percentage of trading volume\n\n2. Clear Success Metrics\nBy the end of the 12-month period, an analysis showing:\n\nTotal OP acquired relative to market conditions\n\nImpact on token supply dynamics and holder value\n\nCommunity sentiment and delegate feedback\n\nLooking forward to the buyback starting in February and tracking these metrics throughout the 12-month pilot.\n\n Axia Network — Delegate Communications Thread\n\n post by system on Jan 28\n\n system\n\n This proposal has passed.The next steps can be tracked here.\n\n 8 months later\n\n post by DarkEmpath888 1 day ago\n\n DarkEmpath888\n\n joanbp\n\n I so not know what this is … nor did I authorize. Can someone please provide details as what this is in regards to?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [DRAFT] [GF: META] Proposal to reserve a share of GF distribution for liquidity backstopping and stronger governance\n\n Technical Proposals\n\n The Commons: shoring up OP’s liquidity, governance, and funding capacity\nHi, I’m Jack from Velodrome, a leading Optimism dex that recently received a 3mm OP grant from OP Labs, a close collaborator in the build of our pr…\n\n read more\n\n 77\n\n 7.6k\n\n Dec 2022\n\n Change the use of OP tokens from a governance token to the main network token for gas payment\n\n ✨ General\n\n Do you agree with changing the use of OP tokens from a governance token to a main network token to pay the gas fee?\n\n 192\n\n 14.9k\n\n Mar 2023\n\n Accelerated Decentralization Proposal For Optimism\n\n ✨ General\n\n Authors: @GFXlabs \nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary) \nIf you hold OP, please signal your approval of this accelerated decentralization on this Snap…\n\n read more\n\n 36\n\n 3.6k\n\n Aug 25\n\n Enabling $OP as a gas token on Optimism Network!\n\n ✨ General\n\n Enabling $OP as a gas token on Optimism Network! \nThe $OP token can be used to pay gas fees on the Optimism Network!. This is a major addition to the utility of the $OP token, and will …\n\n read more\n\n 144\n\n 18.9k\n\n Jun 2023\n\n [FINAL] Enable aOP as A Votable Token in Optimism’s Governance\n\n ARCHIVED & OLD Missions\n\n season-4\n\n S4 Intent: Governance Accessibility\nProposed Mission: Enable aOP as A Votable Token in Optimism’s Governance\nProposal Tier: Fledging\nBaseline grant amount: N/A\nAlliance Lead: Fig / Flipside Crypto\nContact Info:\n\nTwitter…\n\n read more\n\n 22\n\n 3.2k\n\n Jul 2023","tokens":4318,"squid":"ink-governance","role":"Council Listener","at":1791260184288,"hash":"729e7f2c9d8d5aaec7dd5e87d2a1c27e537924bc"}
{"url":"https://io.net/docs/guides/clouds/deploy-vm-on-demand","domain":"io.net","title":"Deploy VM on Demand - io.net","text":"VM on Demand provides a seamless way to deploy fully equipped virtual machines optimized for AI and machine learning workflows. Designed for data scientists, researchers, and builders, it enables you to launch high-performance GPU or CPU-powered environments with a few simple clicks.\nYou can scale resources as your workloads grow, monitor performance, and manage deployments, all through an intuitive interface. Whether you are training deep learning models, running data pipelines, or testing ML prototypes, VM on Demand delivers a fast, reliable, and frictionless compute experience.\n​Quick Start:\n\nClick Deploy Virtual Machine on the Home tab.\nChoose your Processor.\nConfigure your Virtual Machine.\nMonitor your deployment details in the sidebar.\nOnce the minimum requirements are met, review and deploy your cluster.\nStart using your Virtual Machine.\nView and manage your virtual machines in the Virtual Machine tab.\n\n​Deploying Clusters\n​1. Getting Started\nTo begin, click the Deploy button in the Virtual Machine row on the Home tab of the io.net Cloud platform.\n\nYou can also open the Virtual Machine tab directly and select Deploy Virtual Machine to start a new deployment.\n\n​2. Select your Virtual Machine Processor\nChoose a processor based on your requirements. Each card displays its specifications, including:\n\nDevice Availability\nPrice\nVRAM per card\nStorage\nSupplier\nLocation\n\nTo view detailed technical information, click More details. This will display additional specifications such as interconnect technology, NVLink support, memory, and the number of virtual CPUs (vCPUs).\nYou can refine your selection using the Search GPU Model field or by applying filters. Click Filter to filter by:\n\nGPU Family\nRegion\nSupplier\nGPU Memory\nCPU Cores\nDevice Memory\nStorage\n\nYou can apply these filters individually or in combination.\n\nAfter selecting your Virtual Machine Processor, click Next Step to continue.\n​3. Configure Environment and SSH Keys\nSet up your environment and link SSH Keys for secure access. You can choose between two image types:\nPartner-provided clusters include a preloaded image that cannot be changed.To choose a specific image, select a processor supplied by io.net.\n General Purpose Image Data Science ImageThe General Purpose Image provides a clean, flexible foundation for building any type of compute environment.Specifications:\nOS: Ubuntu 24.04 (64-bit)\nSize: 3.5 GB (uncompressed)\nIncludes: CUDA Toolkit and drivers\nIdeal for: Users who prefer to fully customize their development environment and software stack.\nThe Data Science Image provides a ready-to-use environment for machine learning, artificial intelligence, and data analytics workloads. It comes fully configured with GPU acceleration and essential data science tools, allowing you to begin experimentation and model development immediately without additional setup.Specifications:\nOS: Ubuntu 24.04.2 LTS\nIncludes:\n\nPython 3.12\nConda 25.7.0\nCUDA 12.1\nRAPIDS 25.6.0\n\nIdeal for:\n\nBuilding and training deep learning or machine learning models using GPU acceleration.\nAnalyzing and processing large datasets with GPU-accelerated data frames.\nRunning distributed computing tasks with frameworks such as Ray.\nDeveloping, visualizing, and testing AI workflows directly from Jupyter Notebooks.\n\nView full image specification →\n​4. Add your SSH Key\nChoose one of the following methods to access your VM securely:\nPartner-supplied clusters only support Manual SSH key input. You must add your SSH key by entering a key name and pasting your public key directly.To use the Fetch from GitHub feature, select an io.net-supplied processor. This allows you to retrieve your public SSH key automatically by entering your GitHub ID, simplifying setup and secure access.\n\n Manual Input Fetch from GitHubUse this option to add your SSH key directly.\nEnter a Key Name to identify the key.\nPaste your public SSH key into the field provided.\nYou can repeat these steps to add multiple SSH keys if several users or systems require access. Each key you add will be authorized for SSH connections to your deployed VM.This method is especially useful if you manage SSH keys locally or use multiple machines. It also ensures that you can explicitly control which public keys are linked to your cluster.Make sure that you paste only the public portion of your SSH key. Private keys should never be uploaded or shared.If your public SSH keys are already associated with your GitHub account, you can retrieve them automatically using the Fetch from GitHub feature.\nSelect the Fetch SSH key from GitHub option in the Type of SSH key field.\nEnter your GitHub ID, or multiple GitHub IDs separated with commas, in the field provided.\nThe system will automatically retrieve and apply your public SSH keys from your GitHub profile.\nThis option is a fast and convenient way to authenticate without copying or pasting keys manually. It is especially useful if you frequently rotate keys or work across multiple environments, since your GitHub account always stores the latest authorized keys.You can view or manage your SSH keys in your GitHub account by navigating to Settings > SSH and GPG keys.\n​5. Customize your Virtual Machine (Optional)\nIn this step, you can personalize your deployment by assigning a name and configuring network services.\n\nCluster Name\nYou can assign a unique name to your cluster to help identify and manage it easily.\nEnter your preferred name in the Your Cluster Name field. This name will appear throughout your dashboard and logs, making it simpler to distinguish between different clusters or projects.\nNetwork Services\nNetwork services allow you to expose specific ports on your virtual machine that are necessary for your applications or workflows. These ports enable external access to services running inside your virtual machine, such as APIs, web applications, or databases.\nBy defining network services during setup, you ensure that your required tools and applications are reachable while keeping all other ports securely closed by default. This approach provides flexibility for your workloads without compromising security.\nYou can configure multiple network services depending on your use case.\nPartner-supplied clusters expose all ports. However, the following ports are occupied by default:\nPort 22 - SSH Access\nPort 53 - System DNS\nPort 5555 - NVIDIA Host Engine\nPort 9100 - Node Exporter: Metrics\nPort 9400 - DCGM Exporter: GPU Metrics\nPort 12345 and 12346 - Grafana Agent\n\nTo expose additional ports or services, follow these steps:\n\nClick Add Network Service\nProvide the required details:\n\nService Name\nPort Number\nProtocol (TCP or UDP)\nWhitelisted IPs (IPv4 subnet)\n\nClick the + button to add each IP to your whitelist.\n\nNetwork services and port configurations cannot be changed after virtual machine deployment. Ensure that all required ports are defined before deployment, and expose them in your Docker command inside the VM.\nPort Exposure on io.netWhen deploying containers, you must expose ports in two locations:\nInside the VM (Docker):\nSpecify ports when running your container.docker run -d -p 8082:8082 your-image-name\n\nio.net Network or Frontend Configuration:\nAfter deployment, the platform assigns external ports that map to your container ports.\nThese external ports are used to access your services.Docker port exposure inside the VM does not automatically propagate to the external network. Both configurations are required for external accessibility.\n​6. Review and Deploy\nA sidebar on the right displays all your deployment details, including:\n\nMachine Type\nProcessor\nCost\nGPUs per VM\nLocation\nDuration type (Hourly, Daily, Weekly, Monthly)\nDuration\n\nAfter confirming that all details are correct and the minimum requirements are met, click Pay & Deploy.\n\nA payment window will appear where you can complete the transaction using IO Credits, Credit or Debit Cards, USDC, or IO Coin.\n\nOnce payment is confirmed, your cluster deployment will begin automatically.\n​Viewing Virtual Machines\nAfter deployment, you can view your virtual machines.\nNavigate to the Virtual Machines tab to monitor performance or launch additional VMs.\nThe Virtual Machines Dashboard allows you to filter clusters by their current status. Click on a specific VM to open its details page.\nEach Detail page shows you:\n\nReal-time resource usage information\nSSH connection details\nBilling and usage insights\n\n​Connecting to your Virtual Machine\n\nLocate the SSH Access field on your cluster page and copy the provided command.\n\nOpen your Terminal and paste the command, then press Enter.\nWhen prompted to confirm the connection, type yes and press Enter.\nOnce connected, you will see the welcome message and gain access to your VM through the SSH terminal.\nWas this page helpful?","tokens":2195,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260191326,"hash":"aa697ee27226fa40da8e232d2f323b4b6eddfc7c"}
{"url":"https://gov.optimism.io/t/draft-gf-meta-proposal-to-reserve-a-share-of-gf-distribution-for-liquidity-backstopping-and-stronger-governance/2969/1","domain":"gov.optimism.io","title":"[DRAFT] [GF: META] Proposal to reserve a share of GF distribution for liquidity backstopping and stronger governance - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [DRAFT] [GF: META] Proposal to reserve a share of GF distribution for liquidity backstopping and stronger governance \n\n Proposals 📃Technical Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2022\n\n 1 / 78\n\n Jul 2022\n\n Dec 2022\n\n post by jackanorak on Jul 13, 2022\n\n jackanorak\n\n The Commons: shoring up OP’s liquidity, governance, and funding capacity\nHi, I’m Jack from Velodrome, a leading Optimism dex that recently received a 3mm OP grant from OP Labs, a close collaborator in the build of our protocol. We’ve mostly been heads down building and showing up in partner discords, and we’re looking forward to participating more in OP governance. Consider this our first effort in earnest to engage, following some observations we’ve made.\nOP grants to date are meeting some common needs…\nCongratulations to protocol teams who have successfully received grants from the Optimism Collective. As part of Velodrome’s research on how best to apply, we read and catalogued every governance proposal to see which approaches seemed reasonable and what the community had to say about each. A few key themes jumped out:\n\nThrough Phase 0 and round 1 of Phase 1, a total of ~40.3mm OP approved for distribution\nOf this, 40.0mm OP — ~99% of the total — earmarked for payment (to be likely sold)\nThe only OP designated for some use is for protocol-owned liquidity\n\nWe observed successful grants primarily seeking, loosely speaking, three forms of aid: liquidity (35%), user acquisition (28%), and ecosystem engagement (21%). All of these (necessary and valuable!) forms of help essentially amount to a guarantee of a protocol paying someone OP, which would then in all likelihood be sold for ETH or some stablecoin.\n…and are a lot for OP to digest\nAcross the three largest dexes featuring LP, there are roughly 10mm OP in liquidity pools. If we assume the ~40mm distributed OP to be sold evenly over the next six months, we’re looking at 6.7mm OP sell pressure – two thirds of all the OP in liquidity pools – every month.\nSimply offering OP to be market dumped for these purposes in this way is an attempt to outrun the token’s degradation, hoping that eventually enough economic value will be generated by the community before the glamour surrounding the OP token’s potential fades to oblivion.\nPeople have hypothesized that it could come from blockspace demand. It could be MEV, transaction ordering, or even community-level partnerships. But there is currently limited tangible value accruing to the Collective, and as far as we can tell there haven’t been significant moves on this issue – and the need to address it is likely imminent.\nSo we’re offering a broader proposal, one we believe could make a huge difference for the ecosystem. It would help the OP token meet its intended purpose — sustainably fund public goods that may otherwise go unsupported — while lending a crucial layer of relevance to the Optimism Collective as a governing community.\nWe call it The Commons.\nThe Commons: securing public infrastructure\nOP does in fact have a valuable function in permissionless settings: you can pair it with other tokens on AMMs and use it as a central liquidity node, the same way WETH works on Mainnet or, say, OSMO on Osmosis. This has the effect of providing liquidity to less central tokens, all while increasing the base token’s price stability.\nSo rather than simply doling out OP to protocols, under this plan Optimism’s governance would reserve some portion of tokens currently earmarked for distribution each round to be used for liquidity pairing. To gain liquidity for their native or utility tokens, applicant protocols would now offer the Optimism Collective some of these tokens for pairing.\nAs an example, we’ll look backward at the roughly 15mm OP being distributed to help with some form of liquidity. Let’s say OP had instead set aside 10mm of that OP for pairing with native tokens. Roughly speaking, the following would occur:\n\n25% of all previously distributed tokens would instead be earmarked for pairing\nSelling pressure is reduced by nearly 25%, or 1.7mm OP per month, to 5mm OP per month\nAdding 10mm of OP into liquidity would double the amount of OP currently in LPs to 20mm OP in LPs.\nSo we’ll have gone from dumping 67% of aggregate OP in LPs to 25% every month.\n\nIn addition, assuming a 35% benchmark APR we at Velo are using, the current $10mm (assuming OP at 50c) gained from liquidity provision would return roughly $1.75mm over 6 months, not including compounding [note: may vary substantially due to the many potential ways of deploying LP across different platforms].\nGood for protocols\nThe selling point for protocols is simply this: they’re already asking for more liquidity from Optimism than what’s provided by this example and, even outside of OP grants, are incentivizing protocols such as Curve (and, yes, Velodrome). This is all to say that there clearly exists demand for this sort of liquidity backstop. This proposal would provide them this exact service while also giving them a responsible steward of their tokens. And, because this action lends some material value to the Collective, our hope is that it kickstarts similar initiatives accruing additional value and signals to the broader market that there is a nascent economic engine beneath us.\nBecoming the Collective\nBy obtaining a wide range of ecosystem governance tokens, the Optimism community will gain broader governance power, creating a new layer of metagovernance available to Collective members to help shape the ecosystem for public benefit. The Collective’s status as stakeholder of participating protocols would then be formalized and made actionable. Delegates can now vote not just on Optimism-specific proposals but also on individual protocols’ proposals. Collective members now have a direct channel to partner with Optimism protocols, and some could even act as specialized representatives on behalf of Optimism. There is a lot of design space here.\nThis exact scenario has already played out for Velodrome. Some of you might know that when we first designed our token distribution, Velodrome took the initiative to grant Optimism 5% of our initial token share. This has proven to be one of our best decisions yet; Optimism has already gotten back its initial $150,000 grant to us in token value alone, and in the meantime it has collected substantial fees and compounded its power to incentivize liquidity in ways that have been beneficial for the ecosystem. And most importantly, that ownership has facilitated a close partnership between us and OP Labs; we actively work with them to help them use our protocol to best serve their interests.\nCommunity member dcao has illustrated this mode of value creation through recomposition succinctly:\nimage1118×1000 123 KB\nThis is unironically true.\nThe Bet\nThe Working Constitution calls for the Optimism Collective to “undertake a series of governance experiments” to, among other things, “sustainably fund those public goods that improve upon the well-being of the Collective and beyond” and “minimize the discrepancy between collective impact and individual profit.”\nWe’re asking the Collective to take the experimental bet that acquiring a stake in partner protocols in exchange for crucial, clearly desired support does indeed serve this vision—that properly seating the Optimism Collective’s capacity in the combined value of participants’ efforts and successes will lead to new directions in shared responsibility and prosperity.\nAnd we’re asking protocols on Optimism to do more than express support for the public good as a concept and take another bet, that they will in fact be better off by formalizing a commitment to the public good and inviting the greater Optimism community to the table. It wouldn’t be for nothing — they would gain a responsible holder of their tokens, in addition to all of the other benefits they stand to gain from partnering more closely with the Optimism Collective.\nWe’re Optimistic\nThere’s a reason why, when we were invited by Optimism to migrate from the Fantom ecosystem and build a liquidity hub, we shifted our entire trajectory as veDAO toward this new space. We saw in Optimism a unique ecosystem where it seemed that people were putting money where their mouth was when it came to experimentation in governance modes.\nAnd now that we’re here, we want to help Optimism take real steps in proving that its philosophy of mobilizing new governance structures to build and maintain public goods can and does work.\nOne step in this direction, we think, is the communal ownership of liquidity, which we believe can be a public good. It helps that owning liquidity also happens to be a value-accretive activity, which in turn will help us fund more public goods in a sustainable way.\nThis, of course, all comes back to the question of why we have OP the token in the first place. Its sole purpose ought to be to fund public goods for the betterment of the community—so let’s make sure that this token can continue to do so by supporting its value through meaningful economic action.\nOpen questions\nWe invite discussion on this issue, as there are some details and specific cases we have a view on but could use more perspectives. For instance:\n\nHow would this be incentivized or required? Would there be some ‘bonus’ OP pool set aside?\nHow much OP currently requested for liquidity as a proportion of the total OP distributed should be targeted?\nHow do we factor protocols’ market cap (or having any token on OP) into these considerations?\nWould OP compound LP positions or accrue vote power (in the case of, e.g., positions on Velodrome and Curve)?\nCan we call this layer-owned liquidity (LOL)?\nWhat would be the actual mechanics of managing the LPs? Who administers them?\n\nProposed timeline\nWe suggest that new grants be frozen until we consider this proposal. It is critically important that the Collective appreciate the likely inability of the current liquidity infrastructure to handle projected sell pressure.\nWe look forward to hearing thoughts on this.\n\n Owning protocols that bring TVL to OP\n\n Voting power Grant Proposal\n\n [READY][GF: Phase 1 Proposal] Velodrome Finance\n\n DRAFT][S02 Committee Proposal: Category: Defi: Group B]\n\n 33\n\n 20\n\n 4\n\n 4\n\n 4\n\n read \n\n 34\n min\n\n post by dcao on Jul 13, 2022\n\n dcao\n\n What a great proposal jack! I (a new user with 0 posts) completely support this. Perhaps the OP foundation could use this new dex I found called “velodrome” to create the LPs proposed by this proposal. Jack, have you heard about this dex before? With the simple passage of this proposal we could drive hundreds of millions of dollars to velodrome TVL. Maybe I should buy some VELO token.\n\n post by jackanorak on Jul 13, 2022\n\n jackanorak\n\nimage784×184 30.6 KB\n\nimage1104×726 38.2 KB\n\n post by dcao on Jul 13, 2022\n\n dcao\n\n Defi value creation:\n\nimage1905×1703 330 KB\n\n post by OPUser on Jul 14, 2022\n\n OPUser\n\n Couple of points:\n\n36M that was distributed in Phase 0 was for liquidity and user on-boarding so I dont see a problem if those token are sold out or dumped. That was their sole purpose, on board liquidity according to their proposal\n\nYes, this assumption is wrong.\n\nIf we assume the ~40mm distributed OP to be sold evenly over the next six months, we’re looking at 6.7mm OP sell pressure – two thirds of all the OP in liquidity pools – every month.\n\nNot all of the token will be sold, token distribution plan from their proposal is from 6-24 months and few of them are not using their token as an LP reward, so token distribution will be gradual.\nThis is nice idea but will not work\n\nDelegates can now vote not just on Optimism-specific proposals but also on individual protocols’ proposals\n\nIt will cause bias, if I have a say in project X and they submit a proposal here on GF fund, only option for me to abstain from discussion.\nThis will work out just fine on organizational and/or project level, just as you mentioned below\n\nVelodrome took the initiative to grant Optimism 5% of our initial token share. This has proven to be one of our best decisions yet\n\nAnd going back to last point, I dont expect anyone from OP foundation to comment on your proposal because I will see bias.\nWe are mixing two things here, price of OP and Public Good.\n\nwhy we have OP the token in the first place\n\nFor public good we have dedicated 20% fund and its distribution is based on different logic which I am really excited about.\n\nWe suggest that new grants be frozen until we consider this proposal\n\nAgain, in my opinion, this we should not do. Pausing will only hurt our progress we have made so far.\nFew point because this proposal is mixing couple of things.\n\nIn Phase 1, we are not just focusing on LP, we are also looking into user on boarding via different approach, application migration and integration, marketing and even development support if idea is unique. Now we are asking projects to submit KPI based proposal if its based on LP incentives and we are working on making sure that its sustainable, long term. Again, opinion varies according to delegate but from what I see, we are looking beyond just LP.\n\nThis seems to be focused on price of token with a mask of public good. We should keep them separate.\n\nPersonally, I dont see a proposal if token are being dumped as long the reason is justified in their proposal. Again, depends on proposal. At the end of day, 1 OP will always has 1 voting power as it should be, after all its a Gov token.\n\nIf you feel project proposal need improvement, join us and help us improve it.\n\nPausing will not help but asking question and providing feedback to project proposal will.\n\nI see, you have marked it as Ready, unfortunately, I am not in favor of this proposal.\n\nI want to mention few things. We have an excellent gov model(token house and citizen house) which motivated me to join this gov and I think, it need feedback and suggestion.\nWe are in dire need of community engagement, if i look at the stats on this forum, user involvement are going down each passing day. What can we do for that ?Last voting cycle, we had 17M vote count on proposal.\nI think liquidity will see some boost once fraud proof and bedrock is implemented, current market sentiment is also having some impact on that.\nAgain, I might be in minority here, liquidity is not “critical” problem here but lack on user involvement is.\nResolving bias is another concern but that need a separate thread.\nWe have few thoughts and thread going on to improve overall gov process. Please join us there.\n\n post by gabagool on Jul 14, 2022\n\n gabagool\n\nWanted to make a comment not about the discussion here, but about your manner of discussion.\nI’ve noted in several posts that you are quite dismissive of ideas you do not personally agree with, without providing clear rational or full engagement with contrary arguments.\nYou are not worried about token price, and do not think token price is connected to governance activity. Does that make these opinions true?\nWhy is liquidity not a crucial problem? How are you defining liquidity?\nWhy will Delegates voting on individual protocol’s proposals cause bias? Why should you abstain from a governance discussion or vote when a protocol submits to OP if you also participated in a governance discussion or vote on that individual protocol? Being a delegate somewhere should not curtail ANYONE from participating in governance elsewhere. This is core to the entire ethos of decentralization and autonomy.\nYou claim that “this assumption is wrong” re: the distributed grant OP being sold evenly over the next six months. First of all, be acknowledge that this is a hypothetical, but offer no clear numbers on how many protocols are using OP as Lp rewards. What makes YOUR assumption that “token distribution will be gradual” accurate? Can you please provide evidence for this assumption?\nThis proposal emerged out of a comprehensive review of every single grant proposal submitted to OP, and was also discussed prior to publication with members of the OP team itself.\n\nThat is right, because they are mixed. Tokens have both economic value and governance value, and the very “public good funding” that the OP token is being used for DEPENDS on token value. No public good’s funding without the token having economic value.\n\nThis entire proposal is core to user onboarding. Maintaining economic value of $OP is fundamental to attracting new users to Optimism.\n\nCan you explain why you believe this? and why you are not concerned that a massive distribution of the OP token will result in a token price that could certainly result in negative tailwinds for Public Goods funding, governance, user activity, and more?\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\n OPUser\n\n We were excited to hear OPUser’s thoughts due to their thoughtful feedback on our current draft proposal. We intend to clear up the entirety of their concerns voiced here, most of which we believe merely require some clarification.\n\n36M that was distributed in Phase 0 was for liquidity and user on-boarding so I dont see a problem if those token are sold out or dumped. That was their sole purpose, on board liquidity according to their proposal\nYes, this assumption is wrong.\n\nWe made no value claims about where the tokens were going, just observing that for 99% of all tokens being distributed, the ultimate recipient is likely someone who is unmotivated to hold OP vs market selling it. Of course there’s nothing wrong with paying people to LP, use, or build on your product! Velodrome ourselves are using our grant for the same purposes – because these are things that protocols need. This is why we believe protocols have good reason to opt into our proposal, which addresses liquidity, by far the most requested need, and prolongs the efficacy of these programs.\nThat Governance is fine with using OP for these purposes doesn’t make it less unsustainable, which is our claim.\n\nNot all of the token will be sold, token distribution plan from their proposal is from 6-24 months and few of them are not using their token as an LP reward, so token distribution will be gradual.\n\nGoing through the individual approved applications, we saw the distribution being heavily stacked toward the 6-12 month horizon. We certainly can provide supporting data if this is enough of a sticking point.\nBut even if tokens were distributed equally over 18 months (which is VERY generous); you’d still see unmitigated sell pressure of roughly a quarter of all LP’ed tokens each month. By the time the 6th month came around, the value of the grant would likely be a small fraction of what it would have been if spent at the start. Some GF proposals have already asked for an inflated amount of tokens, claiming they are anticipating this fact!\nOne thing we didn’t cover in our proposal would be that this observed sell pressure will heavily encourage front-loading of distributions by partner protocols, as they will stand to be better off using their tokens now and risk missing out on future grants than comply with expectations to get a second distribution worth a small fraction of the first.\n\nIt will cause bias, if I have a say in project X and they submit a proposal here on GF fund, only option for me to abstain from discussion.\nThis will work out just fine on organizational and/or project level, just as you mentioned below\n\nIf you believe that the Optimism Collective’s ownership of project governance tokens would bias your personal decisions, either you have graver concerns about the functionality of decentralized governance structures in general – or you (possibly correctly) believe that you, OPUser, individually have outsized influence on the collective, such that you can sway things for your personal benefit, which would naturally be problematic from a decentralization standpoint.\nSeparately, how would this structure be more problematic than an individual personally owning a large stake in project X and thus being conflicted — which of course is almost certainly the case for many delegates and perhaps something unavoidable?\nTo be honest, we believe this feature is the most exciting thing for committed delegates, as it reflects in our view a compelling experimentation around decentralized governance (and capitalism) – a collective stake in participating organizations.\n\nThis is nice idea but will not work\n\nThis opinion, on the other hand, in response to our data- and experience-driven proposal, has no support. Why not share your bias against this? Pretty sure we can address any material concerns you may have.\n\nAnd going back to last point, I dont expect anyone from OP foundation to comment on your proposal because I will see bias.\n\nWhy would this be the case? Spell out exactly how they’d be biased. Is it because you think this benefits Velodrome? Note that nowhere do we mention Velodrome as a place to LP tokens; that is up to the OP Collective. If this is why you are concerned, do you believe that their small stake in Velodrome is enough to materially sway their interests?\nThere are many fantastic places to LP tokens, each with its benefits. Uni naturally has unique strengths, Beethoven’s well known for its farming abilities, etc.\nAnd consider the opposite: it is entirely possible that they influenced us to make this proposal for the good of Optimism because, as tokenholders, they have a say in what sorts of communications we put out. And that would be a good thing. [To be clear, though, this proposal was entirely conceived by the Velodrome team.]\nIf someone from the Foundation were to comment on this, we would expect participants here to see them as people who put the Collective first. We’re genuinely confused at how you could expect otherwise.\n\nWe are mixing two things here, price of OP and Public Good.\n\nOf course we are. We recognize the need to paint a veneer of propriety such that we don’t have random tokenholders screeching “but token price”, but until the OP Collective can figure out a way to accrue a material treasury, the token is how we have the ability to fund public goods. What we’re doing is offering a mechanical and governance-driven means of ensuring that this method is sustainable.\nSeeing the token go to zero critically hamstrings the Collective’s capability to fund public goods or RFPG, which limits protocols’ capacity to facilitate user/liquidity/protocol onboarding, which lowers the stakes for governance participation, which leads to a death spiral.\nWe are laying out our concerns with the weight of experience of having seen this play out in several contexts – and, we believe, our expertise, having professionally consulted for protocols (e.g., Redacted) and layers (e.g., Boba) on this very subject, to say nothing of our deep history in complex tokenomics. We are sounding the warning here because not attending to this is a grave mistake. Let’s drop the pearls, people.\n\nAgain, in my opinion, this we should not do. Pausing will only hurt our progress we have made so far.\n\nPausing would prevent OP from multiplying the sell pressure overnight. Can you explain what sort of progress would be stalled in support of this? Why would delaying, say, two weeks have a material impact?\n\nIn Phase 1, we are not just focusing on LP, we are also looking into user on boarding via different approach, application migration and integration, marketing and even development support if idea is unique. Now we are asking projects to submit KPI based proposal if its based on LP incentives and we are working on making sure that its sustainable, long term. Again, opinion varies according to delegate but from what I see, we are looking beyond just LP.\n\nAs far as we can tell, none of these entails doing anything other than paying somebody OP so they can sell for stables. Would love to see an alternative — so much so that we’ve suggested one!\n\nThis seems to be focused on price of token with a mask of public good. We should keep them separate.\n\nAlready addressed above, but we’ll emphasize: this is an aesthetic objection to a material concern. The token price is not its own end; it is the sum total of Optimism’s operational capacity.\nMoreover, this a rank misreading of our proposal, which is in fact not focused primarily on the token price.\n\nThe broader objectives you yourself have raised include participation in governance. Our proposal increases the stakes for governance.\nThe Constitution calls for experimentation in modes of governance; we’ve outlined in detail a way to dramatically expand the scope of governance.\nYou provide links to discussions on how to accrue value to governance; we’re not sure what else you can call our proposal.\n\nPersonally, I dont see a proposal if token are being dumped as long the reason is justified in their proposal. Again, depends on proposal. At the end of day, 1 OP will always has 1 voting power as it should be, after all its a Gov token.\n\nAgain, we’re not making value claims about the intended purpose of these tokens. We’re devising a win-win-win way to sustain these intended uses of the tokens.\n\nFor public good we have dedicated 20% fund and its distribution is based on different logic which I am really excited about.\n\nSure, but again we’re commenting specifically on the current program’s sustainability, on which we’re not picking up any material pushback.\n\nWe are in dire need of community engagement, if i look at the stats on this forum, user involvement are going down each passing day. What can we do for that ?Last voting cycle, we had 17M vote count on proposal.\nI think liquidity will see some boost once fraud proof and bedrock is implemented, current market sentiment is also having some impact on that.\n\nYou can’t get around the fact that governance participation will pick up when there are higher stakes and modalities to it. Merely accepting the status quo of meting out rapidly depreciating tokens to a few dozen protocols is simply not enough to bring in outside participation, and tech updates will of course do precious little to affect that. But because we have a vested interest in making sure Optimism thrives, we will certainly do our part.\n\nWe have few thoughts and thread going on to improve overall gov process. Please join us there.\n\nSure, we’re happy to explain how this proposal would address all of these concerns. We’d actually considered doing this already. We’ll consider this your active encouragement to do so.\n\nI see, you have marked it as Ready, unfortunately, I am not in favor of this proposal.\n\nYou might be, but we hope others reading can critically evaluate this on its merits. It would indeed be a concerning thing for governance if participation is so low that OPUser’s opposition is enough to stall what we believe is the first immediately actionable way to address an imminent threat to Governance’s power to satisfy one of its core mandates.\nNonetheless, this is the only change you’ve convinced us to make in our proposal, if only because we want to encourage more discussion (and clear up some particulars) before finalizing, and marking it as READY may have discouraged that.\nWe are encouraging readers and delegates to think bigger; we want Optimism to grow up and meet its potential, and to do so we must be receptive to experimentation, especially when there is a sound thesis and solid support behind it.\n\n post by forrest on Jul 14, 2022\n\n forrest\n\n For any token incentive program, the most important measure is Emissions over Revenue. Projects almost always overpay for growth at the beginning ($1 of Emissions leads to less than $1 of fees), with the goal of flipping that ratio in the future. It’s worth noting that in Optimism’s case, the stated goal for OP incentives is that they not only lead to more transactions (revenue) but also more liquidity and users.\nImportantly, none of the Phase 0 programs have started distributing OP, so we cannot really measure this Emissions/Revenue ratio for Optimism.\nThis also means your OP sell pressure numbers are hypothetical and probably overstated. You assume every single OP token will be sold on the market which is misleading, I think it’s fair to assume at least some amount will be held or staked in liquidity pools.\nBacking this claim up with data from another network’s liquidity mining campaign (ex. Polygon or Avalanche) would be helpful. I know that in both cases, native token incentives for dapps led to growth in all of the key areas: transactions, liquidity, and users. And they did this without having the native token collapse from sell pressure.\nMy biggest problem with the proposal is that it would see the Optimism Treasury take on significant impermanent loss risk. Token pairs with high divergence are more likely to suffer from impermanent loss, and it’s fair to assume OP will continue to be more volatile than say, ETH. Arbitrageurs will rejoice if OP is naively overallocated into constant product AMMs.\nWhile having the Optimism Collective act as meta-governance in the ecosystem might accrue some value to the OP token, I think it would challenge the network’s claim of being credibly neutral. Optimism functions as an extension of Ethereum, and maintaining credible neutrality is a must. Optimism was already accused of showing certain apps favoritism, and this proposal could make things much worse.\n\nUnironically, impermanent loss invalidates the meme. By pairing OP with long tail tokens on AMMs, the Collective would lose value on many of their positions.\n\nThis is a ridiculous suggestion. The Collective should continue giving grants to projects they believe can convert incentives into more Optimism transactions, liquidity, and users.\nOverall, this proposal uses a lot of hyperbole and does not establish itself as clearly better than the OP incentives that dozens of projects are about to kick off, many of which will enhance the OP token’s on-chain liquidity. Pairing OP with new projects’ tokens on AMMs is not “funding public goods”, I hope other readers and delegates see this clearly.\nI believe the OP token’s utility will reach maturity only once sequencing/block production is decentralized. This is where it will derive most of its value, and trying to append weird and somewhat risky utility onto it now is a bit short-sighted.\nI am not in favor of this proposal and would vote against it.\nDisclosure: I am on the Rubicon team. Regardless of how it would impact our protocol, I simply think this is not a wise move for the Collective.\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\n The simple fact that OP would have these coins in the first place vs outright distributing them and thus having nothing invalidates the majority of your objection to the point where we have to wonder whether we expressed our plan clearly enough.\nConsider:\nStatus quo, Optimism distributes 100 OP.\nOur proposal, Optimism distributes 75 OP , reserves 25 OP and solicits 25 OP equivalent from partner protocols.\nSetting aside the likely farming benefits to offset IL (after all, that is the compensation!), think there’s basic math you’re not seeing here.\nNot really sure why you claim hyperbole in the proposal. We’re not saying that the grant program be stopped indefinitely - we consider it a means of prolonging its efficacy.\nThe fact of your calling it ‘weird’ I think gives your game away. You seek a distant, engineering-led, speculative approach to accrue value when we’re offering something concrete and data-driven that can be done now to meet an imminent need. The fact of expanding and iterating on modes of governance is not ‘weird’ – it’s literally baked into the Working Constitution.\nReally unsure how else to respond here other than to reemphasize, this is not a wholesale stand-in for grants; it’s not necessary to use a program such as Avalanche as a counterfactual. We’re talking about changing how protocols get the thing they’re asking for – dex-based liquidity – in a positive-sum way. Even if we suppose that some marginal incentivized liquidity provider would miss out at the start, there remain the same outside incentives (and the same liquidity) to encourage plenty of new users, capital, and development – and, again, with our plan you could be comfortable in the likelihood of being able to prolong existing liquidity mining programs (and start new ones), along with all the others, to continue to bring in this activity.\n\n post by OPUser on Jul 14, 2022\n\n OPUser\n\n jackanorak\n\nBut even if tokens were distributed equally over 18 months (which is VERY generous);\n\nYou are right here and I am also looking at how it will turn out, you also know, those funds are already distributed and there no point discussing about it now. All we can do is wait, see and learn from it.\n\nSome GF proposals have already asked for an inflated amount of tokens, claiming they are anticipating this fact!\n\nAgain, I agree with you and like I mentioned earlier, best place to point this out is on project proposal so that they can work on it. I have seen, many projects are quite responsive to feedback and willing to amend their proposal.\n\nIf you believe that the\n\nIt not about me or you, I am talking in general. We had seen this in past voting cycle as well, If an entity has stake in a project, they choose to abstain from their proposal.\n\nSpell out exactly the source of their bias\n\nNo, its not about your project or anyone in particular, apologies if my words were not formed properly you get a felling that I am referring to your project. If I have stake in Project X, I would choose to abstain from their proposal in GF round and would expect others too do so if they also have stake in them.\n\nIf someone from the Foundation were to comment on this, we would expect participants here to see them as people who put the Collective first.\n\nI see here we have different opinion, from what I understood, GF funds are for token house and users holding token have say in this. Of course, at initial stage OP Foundation can decide to approve or reject it but only when a proposal is approved by token house.\n\nWhy would delaying, say, two weeks have a material impact?\n\n2 Weeks would not be a problem, I was thinking a pause for months. Reason being, if we pause for months, there will be many proposal at once which would be hard to judge and manage.\n\nOPUser, individually have outsized influence on the collective\n\nIts quite opposite, I am no one, my knowledge is limited and I still learning about different tools and technology and trying to find my niche. There are few delegate here, far more knowledgeable than me and I look up to them.\nI have chosen not to share my view on any comment related to token price.\nIf I am missing anything here, let me know and i would try to explain it it detail.\n\n post by OPUser on Jul 14, 2022\n\n OPUser\n\n gabagool\n\nI’ve noted in several posts that you are quite dismissive of ideas you do not personally agree with, without providing clear rational or full engagement with contrary arguments.\n\nThank you for the feedback and I would love to extend my thoughts, could you please share the link.\n\nWhy will Delegates voting on individual protocol’s proposals cause bias?\n\nIf I have stake in Project X, I would choose to abstain from their proposal in GF round. This is how in general voting works, its nothing new.\n\nCan you please provide evidence for this assumption?\n\nIts not assumption, I am simply quoting what mentioned in project proposal.\nAgain, choose not to comment on anything price related.\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\n OPUser\n\n Jack here. Many thanks for the considerate reply. Will respond per item.\n\nYou are right here and I am also looking at how it will turn out, you also know, those funds are already distributed and there no point discussing about it now. All we can do is wait, see and learn from it.\n\nYes, absolutely. The last batch was intended as a demonstration to provide a sense of scale. Of relevance is the next batch (and so on), which is why we were asking to hold off on this series of grants, just for a week or two, to consider this proposal.\nWe’ve submitted this proposal as a team, but I would volunteer to dedicate myself solely to this project to make sure we could get to consensus quickly enough to continue rewards.\n\nAgain, I agree with you and like I mentioned earlier, best place to point this out is on project proposal so that they can work on it. I have seen, many projects are quite responsive to feedback and willing to amend their proposal.\n\nWe can def do more of this – but it’s addressing the symptom and not the cause. Our proposal intends to remove that kind of guesswork altogether.\n\nIt not about me or you, I am talking in general. We had seen this in past voting cycle as well, If an entity has stake in a project, they choose to abstain from their proposal.\n\nIf I’m understanding you correctly, you’re saying that delegates with personal stakes in protocols currently abstain from votes where there might be conflicts of interest. I think that’s fine – if fragile – as a means of preventing capture (as we’ve seen in politics).\nIn any case, what we’re proposing is a step away from these types of conflicts, as the only shift is the addition of governance to firms’ capital bases, not individuals. To say that personal conflicts would enter into it in a more significant way than in the status quo would be to say that governance itself is captured by individuals, which is an entirely different matter (one, incidentally, this proposal is also attempting to address).\n\nI see here we have different opinion, from what I understood, GF funds are for token house and users holding token have say in this. Of course, at initial stage OP Foundation can decide to approve or reject it but only when a proposal is approved by token house.\n\nI think we have the same understanding here. We were just saying that the OP Foundation should have by this point more than demonstrated their commitment to and interest in Optimism’s success as a primary matter.\n\n2 Weeks would not be a problem, I was thinking a pause for months. Reason being, if we pause for months, there will be many proposal at once which would be hard to judge and manage.\n\nAbsolutely. In fact I’d be all in favor of proposing a cap on any sort of pause to keep distribution flowing.\n\nI have chosen not to share my view on any comment related to token price.\n\nI don’t want to overstep my bounds here with you, especially because I sympathize with this sentiment (and strictly adhere to it when it comes to Velodrome), but unfortunately in the case of funding public goods, the price is of relevance in that it dictates OP’s ability to do so.\nI think we ought to be able to refer to its instrumentality to this end while avoiding the ugly speculative discussion that comes from hyperfocus on it. That is, of course, unless there is some sort of legal/regulatory reason to avoid any sort of mention.\n\n post by forrest on Jul 14, 2022\n\n forrest\n\nAgain, their stated goal here is more transactions, users, and liquidity, which I think the current program is on track to accomplish. Optimism does get something out of these incentives. I am arguing that 25% more incentives to fuel growth in those three metrics is more valuable than incentives for long-tail token liquidity against OP on AMMs that account for less than 30% of Optimism DEX volumes.\n\nSo a network’s token accruing value from block production is “speculative” but pairing the token with long tail assets in constant product AMMs is “concrete” and “data-driven”. Gotcha. Could not disagree more. There is way more value for OP in block production than there is in “partnerships”.\n\nWhy not? Those incentive programs grew their respective network in all of Optimism’s target metrics. They are great comparables and I am not sure why you want to dismiss them.\nI guess I do not feel the urgency you do or see this “imminent” need for utility. Incentives are about to kick off on almost all Optimism apps and Bedrock will be online later this year. I don’t buy the theory of the coming OP liquidity crisis, and as I mentioned, you did use unrealistic estimates.\nAlso, I want to see the Optimism Collective do governance experiments, I just think this is a bad one! And I see hyperbole throughout the proposal, not just the suggestion that grants should stop.\n\n post by OPUser on Jul 14, 2022\n\n OPUser\n\nCould you please help me with this example:\nreserves 25 OP : who will get this and what would be its purpose, same question for 25 equivalent from partner\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\nJust realized that we missed this question on an important topic - apologies.\nWould hope you’d expand on this thought, as we’ve struggled to find any direct line between our proposal and any sort of loss of credible neutrality. Governance is either neutral or not; what it has governance over ought not to affect neutrality.\nIf your belief is that simply expanding the purview of governance leads to a loss of neutrality [don’t want to misrepresent tho], that implies the desire for highly limited governance, a view I’d really like to hear explained in light of what’s been posted on the forum to date.\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\n OPUser\n\n Instead of giving away 100 tokens, Optimism gives away 75 tokens and keeps 25 tokens for itself.\nIn return for other grants, some partner protocols may choose to offer some of their own tokens to Optimism, which then pools the 25 OP against protocols’ granted tokens in LPs throughout Optimism.\nSo now instead of having 0 tokens, Optimism now has custody of 25 OP tokens as well as equivalent value of other protocols’ tokens. So in addition to keeping some of its own tokens under the discretion of governance (possibly to be distributed later!), it also has tokens of OP-domiciled protocols. All of these tokens are used to increase liquidity throughout the ecosystem, and Optimism may choose to exercise governance rights through these partner protocols’ tokens.\n\n post by Netrim on Jul 14, 2022\n\n Netrim\n\n But why do this? Optimism already has 5.4% Partner Fund and 8.8% Unallocated. If the core team wanted to do this, they can using those funds and such proposal could fall under a classic POL strategy or maybe someone creates a specific/innovative way of applying it.\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\n forrest\n\nThis also means your OP sell pressure numbers are hypothetical and probably overstated. You assume every single OP token will be sold on the market which is misleading, I think it’s fair to assume at least some amount will be held or staked in liquidity pools.\n\nI’m not so sure, considering the moral panic you seem to exhibit at the thought of impermanent loss. Feel free to back your assertion with some data on how much farmers LPing tokens A + B getting paid in token C choose to farm token C. Any seasoned farmer can tell you it would not be much. Or feel free to consider how much long-term holding or LPing you get from users getting incremental tokens for use rewards, or devs getting paid in OP.\nAnd in any case, there would have to be substantial retention of tokens for there not to be a material impact. A 50% haircut in our estimates is still demonstrably intolerable if what we’re trying to swing as OP is sustained funding of public goods.\n\nFor any token incentive program, the most important measure is Emissions over Revenue . Projects almost always overpay for growth at the beginning ($1 of Emissions leads to less than $1 of fees), with the goal of flipping that ratio in the future. It’s worth noting that in Optimism’s case, the stated goal for OP incentives is that they not only lead to more transactions (revenue) but also more liquidity and users.\nWhy not? Those incentive programs grew their respective network in all of Optimism’s target metrics. They are great comparables and I am not sure why you want to dismiss them.\n\nAgain, there’s nothing in our proposal that impedes the growth of any of these things. It provides if anything more stable liquidity, thus facilitating more trades, investment, etc., better rates due to greater activity on lending and trading protocols, etc. We’re not saying the net effect ought to be any different from Avalanche Rush or any other programs –– the concrete benefit to these protocols and their users doesn’t change one iota. So yes, they’re good models for OP globally. No, they’re not a counterfactual here.\n\nI guess I do not feel the urgency you do or see this “imminent” need for utility. Incentives are about to kick off on almost all Optimism apps and Bedrock will be online later this year. I don’t buy the theory of the coming OP liquidity crisis, and as I mentioned, you did use unrealistic estimates.\n\nEven if you were to discount our estimates of sell pressure by 50% we’re talking about massive, sustained sell pressure by any reasonable measure. Saying you don’t “feel the urgency” without any evidence or modeling does not help anyone here make sound decisions.\n\nAnd I see hyperbole throughout the proposal, not just the suggestion that grants should stop.\n\nWould love to see specific examples of how we’ve strayed from data or reason. To answer the question of “what else is hyperbolic” by saying “well, it’s everywhere” isn’t productive.\n\nSo a network’s token accruing value from block production is “speculative” but pairing the token with long tail assets in constant product AMMs is “concrete” and “data-driven”. Gotcha. Could not disagree more. There is way more value for OP in block production than there is in “partnerships”.\n\nWhether OP collectively resolves 1. what it’d look like, 2. whether it would outweigh potential risks, 3. ultimately whether to go with it, among other issues is, yes, a matter of speculation. Certainly it could accrue material value, and I’m not saying it’s the wrong path! I’ve had these conversations myself, and there’s much to be gained. But something like this being implemented is months and months away, and the sell pressure we’ve described is occurring as we speak with little other than market markers to mitigate it.\nAnd in that time, the weeks and weeks of incentives being voted on by OP will depreciate, and so on. And, yes, what we’re describing is a mechanical buffer against this sell pressure that also happens to carry many side benefits. It’s a positive-sum construction.\n\nGotcha. Could not disagree more. There is way more value for OP in block production than there is in “partnerships”.\n\nNot really sure where this adversarial tone is coming from. It’s not an either-or; it’s a matter of meeting needs as they come. Any sort of opinion you may have over what’s good or bad is more helpful when it’s backed by evidence or modeling.\n\n post by jackanorak on Jul 14, 2022\n\n jackanorak\n\n Netrim\n\n We do this because it’s a positive-sum means of offering to grantees a service they’re already asking for while generating more meaning for governance and cohesion between OP governance and constituent protocols.\nSame service, more bang for everyone’s buck. Save the unallocated for non-redundant initiatives once we figure out what to do with it.\n\n post by Netrim on Jul 14, 2022\n\n Netrim\n\n Who is asking for this?\nFirst time this was raised was this thread.\nBut this is not redundant, this is a change, I would say a constituent change.\nThe other issue I am not understand is who is going to own the created LP, since Optimism provides OP, the dex provides their token? So in the case of Velodrone, it would be VELO. But then you need to create the LP for it, and that LP will have only one owner.\nIf your proposal tries to tackle price, too early to tell and like others have said, many assumptions on your initial post, some of which I don’t agree.\nIf your proposal tries to tackle governance participation, the issue is very different and this proposal does nothing.\n\n Load more posts below","tokens":12007,"squid":"ink-governance","role":"Council Listener","at":1791260194510,"hash":"4cb8cf51bf07458e446b437f23a757f76cfce6b5"}
{"url":"https://governance.aave.com/","domain":"governance.aave.com","title":"Aave - Governance Forum","text":"All latest topics\n\n categories\n\n Latest\n\n Top\n\n Categories\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 765\n\n 8h\n\n [ARFC] The Aave Foundation, Phase 1\n\n Governance\n\n 3\n\n 961\n\n 11h\n\n [ARFC] Deploy Aave V4 on the Monad Network\n\n New Market\n\n 3\n\n 389\n\n 11h\n\n LlamaRisk - Monthly Community Update\n\n Governance\n\n 28\n\n 3.4k\n\n 16h\n\n Risk Stewards: Supply and Borrow Cap Reductions on Aave V3 / 2026.08.10\n\n Risk\n\n 3\n\n 201\n\n 1d\n\n [Discussion] A second, issuer-controlled verifier for cross-chain GHO on CCIP 2.0\n\n Governance\n\n 0\n\n 61\n\n 1d\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Onboard wstLINK to Aave V3 Core Instance\n\n New Asset\n\n 15\n\n 3.1k\n\n 1d\n\n [Question] Any idea what happened here?\n\n Finance\n\n 4\n\n 225\n\n 3d\n\n [GHO Stewards] October 2026 - GHO Borrow Rate Update\n\n Governance\n\n 0\n\n 163\n\n 4d\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n [ARFC] Aave Institutional\n\n Governance\n\n 7\n\n 534\n\n 4d\n\n [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\n\n New Asset\n\n 1\n\n 121\n\n 4d\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.10.01\n\n Risk\n\n 0\n\n 92\n\n 4d\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 199\n\n 5d\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Activate Aave Risk Stewards on Aave V4\n\n Governance\n\n 7\n\n 528\n\n 5d\n\n [ARFC] Onboard OUSD to Aave V3 Core Instance and Aave V4 Core Hub\n\n New Asset\n\n 0\n\n 236\n\n 6d\n\n [Direct-to-AIP] Onboard PT-USDG-25FEB2027 on X Layer\n\n New Asset\n\n 0\n\n 75\n\n 6d\n\n [ARFC] Onboard syrupUSDC to Aave V4 on Arc\n\n Governance\n\n 2\n\n 192\n\n 6d\n\n [ARFC] Onboard mWIN (Midas / Wellington Management) to Aave Horizon\n\n Horizon\n\n 9\n\n 574\n\n 6d\n\n Syrup USDC (syrupUSDC) on Aave Arc Assessments\n\n Assessments\n\n 1\n\n 84\n\n 6d\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28\n\n Risk\n\n 0\n\n 110\n\n 8d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE\n\n Governance\n\n 3\n\n 771\n\n 11d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n [Direct-To-AIP] Umbrella - Renew Allowances\n\n Governance\n\n 0\n\n 83\n\n 11d\n\n wstETH borrows enabled\n\n Governance\n\n 2\n\n 116\n\n 11d","tokens":651,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260194991,"hash":"12990dc648b743c48415d63e52427097a4c6d6ed"}
{"url":"https://gov.optimism.io/t/draft-gf-meta-proposal-to-reserve-a-share-of-gf-distribution-for-liquidity-backstopping-and-stronger-governance/2969/78","domain":"gov.optimism.io","title":"[DRAFT] [GF: META] Proposal to reserve a share of GF distribution for liquidity backstopping and stronger governance - Proposals 📃 / Technical Proposals - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 33\n\n 20\n\n 4\n\n 4\n\n 4\n\n read \n\n 34\n min\n\n Jul 2022\n\n 78 / 78\n\n Dec 2022\n\n Dec 2022\n\n Load more posts above\n\n post by norswap on Jul 15, 2022\n\n norswap\n\n (I work for OP Labs, but this reflects my own opinion. I have worked closely with the Velodrome team.)\nI think this proposal makes a lot of sense.\nFor obvious legal reasons, OP Labs & employees do not discuss token value, but I don’t think I will rock anyone’s socks if I say that a strong token opens more possibilities for governance to make an impact. I love to see a proposal in this direction, even just as a side effect.\nI will also second the fact that liquidity is a real need. I often hear from the bizdev team that liquidity is one of the main concerns of projects. The situation has largely improved already, but it’s still possible to do much better.\nGiving the collective governance power in protocols is also something you like to see. It’s a good way to maintain alignment. I think there can even be a discussion about projects having the ability to use their LP funds to vote in Optimism governance. Projects are important and valued actors whose voice should carry weight (though this should be made very carefully, to avoid projects having a disproportionate governance weight). My take away from the recent situation with the delegation of Perpetual Protocol’s OP allocation is that we’d like to give protocol a voice, but we have to be mindful that it does not take over the voices of other token holders.\nFinally, we have to be cognizant that there are many dexes on Optimism, and we can’t be playing favorite. On the other hand, this is not Optimism, not Communism and I would like to see the market play a role. I think a fairly simple solution is to let projects decide on which dex they want to deposit their liquidity (subject to governance approval to avoids griefs such as creating a new dex specially for the occasion). They will do what is in their best interest, competition will play its role, and hopefully all will be well. (To be fair, this is implied in the proposal, which mentions Velodrome and Curve, I think it’s worth spelling explicitly though.)\nVelodrome did indeed draft this, so I do expect they are confident they’ll be able to benefit from the proposal (though I do think everyone in the ecosystem benefits from it becoming stronger). They don’t have to be the only dex benefitting however.\nThere’s been a lot of back-and-forth in this thread between the Velodrome team and other parties from other dexes. I’d love to see what less directly involved member of the community think as well.\n\n post by jackanorak on Jul 15, 2022\n\n jackanorak\n\n OPUser\n\n Appreciate the clarifications earlier. Now that we’ve settled questions about process, I’ll turn to the individual q’s you posted earlier, as they’re similar to the open questions we laid out in the original proposal. There is enough overlap where I’d rather post them here, and then once we’ve discussed, we can amend.\nExcited to get back to the proposal at hand.\n\nWho will own the LP address, OP foundation ? or someone else ? This need clear answer.\n\nFoundation multisig is probably the most low-friction way to custody this while final governance is sorted out.\n\nWhat would you suggest to do with the LP rewards. Give some of your suggestion ?\n\nIn our initial proposal, we left this an open question and invited thoughts. The three primary actions are:\n\nSell LP rewards to compound LP positions, possibly through autocompounder\nCompound LP rewards into more capacity to influence broader liquidity\n– if v3, possibly buy back OP for more public good distribution or acquire votepower in a veDEX\n– if veDEX model, such as Velo or Curve, accumulate voting tokens to gain general votepower\nSell LP rewards for some other purpose\n–Buy back OP for public good investment\n–Acquire more governance of partner protocols\n–(pending legal clearance, lol) general treasury mgmt\n\nAs you can see, there are a few different paths, but each of them presents an interesting opportunity for the Collective.\nMy personal suggestion would be some combination of compounding voteshare and buying back OP, both of which directly free up Governance’s hand to facilitate more funding, but this is very much an area where I’d invite some other perspectives.\n\nHow long will this LP last ? Who will make a call do dilute the LP and /or its rewards.\n\nOur thinking was that this would be more or less permanent until the protocol signaled a lack of need, at which point the funds would be at Optimism’s disposal. We could say that Optimism commits to holding protocols’ governance tokens in perpetuity while reclaiming its OP for more public goods distribution.\n\nDo you see Impermanent loss as a problem? What would you recommend to mitigate this ?\n\nAs an impediment to passing this proposal, no. The analogy I used above is that it’s silly to refuse to accept $100 of free money because you’re worried you might lose $10 of that.\nThe primary reason for doing this in the first place is to take OP you were already going to give away and put it to work for the same purpose it was originally being requested for–but also put it to work for you. How efficiently it works for you is secondary because your alternative is getting 0 value for yourself.\nAs an operating matter, yes there are possibilities to mitigate this, but I believe it’s downstream of getting something like this passed.\n\nHow this will work ? Lets say OP foundation has the token owned by multi-sig, now who will vote and participate in the DAO ? will it be foundation or the delegates?\n\nThis is a super exciting area where I don’t have a clear direction! I think this is a much, much bigger question on which I would be thrilled to have this proposal spark discussion.\nFortunately, even if this passed we would have some time to sort it out. Of primary importance is meeting protocols’ liquidity needs, which currently represent over 1/3 of all approved OP distributions.\n\n post by OPUser on Jul 17, 2022\n\n OPUser\n\n Process wise, we are still there but like I said, you are motivated about this so I am joining the conversation, may be I am missing something here.\nLast time when we try to involve foundation with joining multi-sig with different project they said no because of bureaucracy, So I would start with getting their permission here. Are they willing to take this responsibility. If you are able to resolve this, then I would agree that we have made some progress.\n\nThis proposal will impact all upcoming proposals, So I would assume this going to voting on snapshot and for that reason, If I were you, I would do some math here and extend the analogy.\nWe know how many token are left in GF fund, you are proposing 25% from from our side and 25% from project side. Run some number and show us the data with, even if it has 10% of variance.\n\nAs an impediment to passing this proposal, no. The analogy I used above is that it’s silly to refuse to accept $100 of free money because you’re worried you might lose $10 of that.\n\nWe have gone through this many time and I dont agree with this logic. So, i wont repeat again.\n\nThe primary reason for doing this in the first place is to take OP you were already going to give away and put it to work for the same purpose it was originally being requested for–but also put it to work for you. How efficiently it works for you is secondary because your alternative is getting 0 value for yourself.\n\nFew other thoughts:-\n\nWhat about those project that does not have token or cant afford to give 25% of their share ?\nBuying OP and putting into foundation treasury would be a good idea where both house would vote to distribute it to public good.\nI would remove DAO all together if foundation is accepting to hold the address, or mention specifically that decision(on other project DAO) will be done by OP Token house, foundation role would be just cast those votes. Goal here is to keep Foundation as neutral as possible.\nWe are asking projects to give co-incentives, are you planning to keep that part or remove it ?\nAlso put 5 dex of your choice where you want to keep the LP.\nWould you suggest putting all in a single dex or distribute it between 3-5 ?\nDex selection should also need voting, I think ?\nIn order for anyone to call Velodrome bias because you are drafting this proposal, I would suggest taking a voting snapshot of the date this proposal was submitted.\n\n post by jackanorak on Jul 18, 2022\n\n jackanorak\n\n Appreciate your thoughts here @norswap. A few things you’re mentioning I’d like to add on to.\n\nDelegating donated LP funds to protocols is a fascinating idea I don’t want to lose. Been struggling to propose an actionable approach to getting distributed OP delegated to these major stakeholders, and this feels like it could be a win-win in that it also incentivizers partners to participate. Would hope to see mutual governance influence in the long term, and the discussion on Perp’s distro stands to disenfranchise a major group\nAgree on the idea of letting projects decide their own dex – had had this thought. Removes a ton of overhead.\nI want to make clear: my guess is that we would benefit primarily through TVL, through the ecosystem’s sustained growth, and through sustained OP token value (which would allow more OP incentivization over time). I’ll say again that, economically speaking, this has an unclear effect on us because partner protocols see a lower cost of liquidity and thus may end up bribing less. For a non-bribe-oriented dex such as Uniswap, my guess is that this would be a strict improvement.\n\nOverall, I think we need to remember that we are doing these grants as a collective. We’re granting a ton of rewards because we believe they will generate more economic activity throughout the ecosystem.\nMy call to everyone here is to try more positive-sum thinking when considering these grants and asking “how does everyone win” vs “does that protocol get more than me”. In my view, this proposal stands to positively directly affect all stakeholders and increase the Collective’s capacity to continue to do so.\n\n post by Ruby on Jul 19, 2022\n\n Ruby\n\n great proposals, good thoughts!\n\n post by wcc on Jul 24, 2022\n\n wcc\n\n I would break my takes into two parts: high level (concepts) and implementation level (approach to execute/distribute properly)\nOn a high level\n\nI mostly agree with this statement. Liquidity is one of many key metrics and plays a vital role in adoption whether we want to accept this or not.\nRegarding governance fund phase 1, I think it would help protocols on OP to bootstrap users together with liquidity over to OP. However, I have observed that many protocols difficult to match incentives with OP tokens. My take on this is most protocols foresee that the OP token value will be dumped for a while given economic value is limited and still underrealized by the market norms. If the market value of OP dropped, it will lead to difficulty for protocols to inorganically bootstrap new users/liquidity from granted OP.\nAfter I read this proposal, I took EVM (Polygon, BSC) and non-EVM (Osmosis) as references, and it proved that the chain representative tokens are mainly used as the main pair (or second to stablecoin(s)).\nReferring back to Optimism, based on what I can find, there are only WETH and VELO that are highly paired with OP. The rest are heavily paired with USDC.\nOn an implementation level\nI would not comment on this since I still could not think of ways to execute the liquidity pairing properly. (not saying your proposal is wrong, maybe just me that is unable to imagine it)\n\n post by diligit on Jul 24, 2022\n\n diligit\n\n I agree with the proposal, in general.\nThere needs to be a separate fund for “Layer-Owned-Liquidity” aka LOL.\nI agree that projects should have voting power in Optimism Collective, but for sure the voting power of projects should not exceed or equal the voting power of the community.\nOf course the main goal is to maintain the value of the OP so that public goods have more value.\nContext: don’t mix DEXs incentives and Public Goods. This need in stimulus is the result of similar projects with low liquidity. We need more exceptional ideas.\nPublic Goods is something special, which I hope will focus on research, innovation, education…\nAnd I don’t agree with “metagovernance” = “metamonopoly”.\n\n post by jackanorak on Jul 24, 2022\n\n jackanorak\n\n @diligit - thanks for critically engaging with the ideas behind this proposal.\n\nI agree that projects should have voting power in Optimism Collective, but for sure the voting power of projects should not exceed or equal the voting power of the community.\n\nI absolutely agree with this sentiment. Part of what I found appealing about Norswap’s suggestion was that it seemed like a pretty tractable way to both grant and set boundaries around protocols’ governance power. But we’re still in early stages of discussing implementation (assuming there’s appetite for the broader strokes of this proposal), and I’d love for you to stay involved on this front.\n\nContext: don’t mix DEXs incentives and Public Goods. This need in stimulus is the result of similar projects with low liquidity. We need more exceptional ideas.\n\nI couldn’t agree more with this belief. Liquidity provision is foundational to DeFi health at this current stage of development, but it’s also primarily an intermediate means to an end. Most dapps, DeFi or otherwise, don’t even really need tokens!\nThe observation that a disproportionate amount of rewards went to liquidity provision (again, important at this current stage) was part of the motivation behind wanting to at least in part separate this service from others, so that projects could be encouraged to think more expansively about how best to use the Optimism Collective’s capacity. It doesn’t need to all be going to LPs (which imo is is a pretty convenient way to funnel grants and vote power to project teams, as we may have already seen in some cases).\n\nPublic Goods is something special, which I hope will focus on research, innovation, education…\nAnd I don’t agree with “metagovernance” = “metamonopoly”.\n\nCould you please expand on this? Would like to have a discussion around your concerns. We could do this in the forums in case we have to do a back and forth.\n\n post by jackanorak on Jul 24, 2022\n\n jackanorak\n\n wcc\n\n I agree in principle with much of what you’re saying, and indeed I’m starting to see that, following this initial proposal (not sure whether baader-meinhof phenomenon), there has been a surge in delegates’ interest in pairing tokens with OP.\nIf there is broad agreement that this is something generally worth pursuing, one way or another we need to make sure it’s done as part of a deliberate campaign. The worst thing would be to push scattershot rewards, fragmenting the centrality of liquidity between, e.g., WETH and OP, which could hurt the systemic efficiency of swap liquidity.\nLet this be the first proposal to put forth such a dedicated effort; we can use it to discuss how best to achieve this (and perhaps jog your thinking on how we could do so).\n\n post by diligit on Jul 25, 2022\n\n diligit\n\n jackanorak\n\n That’s good, now I understand how metagovernance will be achieved and how the Optimism Collective will be involved in it. There is too much extra information in the proposal, it would be better if it was structured in “Why” and “For” in details, but yes, I support the proposal.\nAnd I can answer your questions:\n\nFrom Ecosystem Fund, through GF\n\nYes\n\nmax. 5%\n\n50/50\n\nYes\n\nThe Optimism Foundation\n\n post by diligit on Jul 25, 2022\n\n diligit\n\n No comments.\nThanks.\n\n post by jackanorak on Aug 1, 2022\n\n jackanorak\n\n Would like to take the opportunity to restart the conversation here. I’m not really sure where else we ought to go from here, as this proposal has now had some form of approval from a wide swath of the community, including OP Labs members (in a private capacity) as well as delegates.\nBut there’s clearly more to hash out here. Perhaps in a way to make this actionable and take advantage in the pause in rewards, could we perhaps start a working group to hash out the details here to submit for a proposal?\nSeparately, would like to mention that there is some outside support for measures such as this to lend immediate utility to OP. Here’s Crocswap’s founder, Doug Colkitt, remarking on the core problem:\n\nThis proposal offers a solution to the issue he’s posing.\n\n post by OPUser on Aug 1, 2022\n\n OPUser\n\n would like to mention this to anyone not reading the complete thread that this proposal does not have approval from OP Labs and wording seems misleading, at least to me.\nAs per bobby, this is valid proposal, he is not endorsing the content or providing his approval.\n\nWhat norswap has said is his personal opinion as mentioned in his comment and not of OP Lab team.\n\n post by jackanorak on Aug 1, 2022\n\n jackanorak\n\n I said that OP Labs members agreed with this in a private capacity, i.e., not as team members. This is clearly true and not intended to be misleading; this may be lost in translation. Would appreciate a retraction.\nI’ll also echo @OPUser that OP Labs team members said in an official capacity that this proposal was suitable to present in the forum, i.e., that it is in fact a valid proposal.\n\n 1 month later\n\n post by jackanorak on Sep 12, 2022\n\n jackanorak\n\n Monthly bump to restart the conversation - some people in the Velodrome discord had been theorizing on this very point and I was hoping some thoughtful people would weigh in.\n\n 29 days later\n\n post by jackanorak on Oct 11, 2022\n\n jackanorak\n\n Monthly bump for some engagement here in the wake of a massive drop in OP’s price\nthink we’ve now gotten to a place where people are asking about how to ‘use’ OP.\nthe answer of course is for governance. so let’s make sure that this governance value is worth enough to fund the projects we all want\n\n 15 days later\n\n post by jackanorak on Oct 27, 2022\n\n jackanorak\n\n After a helpful round of feedback, it may be prudent to roll back one piece of the metagovernance part of this proposal, where the LP positions – though representing yield-bearing stakes in ecosystem DAOs – will not have voting power in the constituent protocols. This would make prospective grantees more likely to participate and eliminate unnecessary decision-making.\nThe really important part of this piece as it relates to the Collective’s stake is that it is 1) a direct representation of the ecosystem’s stake in aggregate economic activity and 2) tangible, accretive value that can flow to governance and continually refresh the Collective’s capacity to fund growth initiatives, public goods, and so on.\nI remain eager to entertain thoughts on this, especially in light of governance funds’ outcomes to date as shown by yesterday’s conference call.\n\n 2 months later\n\n post by coinlord on Dec 30, 2022\n\n coinlord\n\n great news for all of us\n\n post by Luckymonkey on Dec 30, 2022\n\n Luckymonkey\n\n If Optimism wants META superiority , this is one of those proposals that the whole should look into! Much love OPTI! \n\n post by Luckymonkey on Dec 30, 2022\n\n Luckymonkey\n\n I am big fan of OP & VELO ! I hope the two would be discussing something exciting and juicy in the future! Lfg! \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Accelerated Decentralization Proposal For Optimism\n\n ✨ General\n\n Authors: @GFXlabs \nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary) \nIf you hold OP, please signal your approval of this accelerated decentralization on this Snap…\n\n read more\n\n 36\n\n 3.6k\n\n Aug 25\n\n I want to discuss project boosting their delegate power with governance fund\n\n Accountability 🗂️\n\n This is not a proposal or even an idea for something. \nI want to hear your opinion on project(s) using token allocated to their project to boost their delegate voting power. \nIn GF Phase 0, top three project got 21M OP(9…\n\n read more\n\n 75\n\n 5.9k\n\n Dec 2022\n\n [FINAL] Enable aOP as A Votable Token in Optimism’s Governance\n\n ARCHIVED & OLD Missions\n\n season-4\n\n S4 Intent: Governance Accessibility\nProposed Mission: Enable aOP as A Votable Token in Optimism’s Governance\nProposal Tier: Fledging\nBaseline grant amount: N/A\nAlliance Lead: Fig / Flipside Crypto\nContact Info:\n\nTwitter…\n\n read more\n\n 22\n\n 3.2k\n\n Jul 2023\n\n [READY] [GF: Phase 1 Proposal] GARD\n\n Governance Fund: Phase 1\n\n cycle-4\n\n Project Name: The GARD Protocol \nAuthor Name(s): Rylie Rueda, Ryan Soscia, and David McCabe \nNumber of OP tokens requested: 1,000,000 OP tokens \nL2 Recipient Address: 0x9C669a3d5915F6e210Eb453393F4F0D1bBE30EDd \nRelevant …\n\n read more\n\n 20\n\n 4.2k\n\n Aug 2022\n\n [DRAFT] [GF: Phase 1 Proposal] Beefy\n\n Governance Fund: Phase 1\n\n cycle-2\n\n Beefy Incentive Proposal \nProject Name: Beefy \nAuthor Name: @frondoto \nNumber of OP tokens requested: 650,000 OP \nL2 Recipient Address: 0x4ABa01FB8E1f6BFE80c56Deb367f19F35Df0f4aE \nTargeted deployment date: 30/06 \nRelevan…\n\n read more\n\n 30\n\n 5.2k\n\n Jul 2022","tokens":5286,"squid":"ink-governance","role":"Council Listener","at":1791260204735,"hash":"c5d9302a4d2d3c8c8100c0bf56e7734b6b4e5971"}
{"url":"https://governance.aave.com/c/governance/new-asset/9","domain":"governance.aave.com","title":"Latest Governance/New Asset topics - Aave","text":"Latest topics in New Asset\n\n Governance\n\n New Asset\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [ARFC] Onboard wstLINK to Aave V3 Core Instance\n\n 15\n\n 3.1k\n\n 1d\n\n [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\n\n 1\n\n 121\n\n 4d\n\n [ARFC] Onboard OUSD to Aave V3 Core Instance and Aave V4 Core Hub\n\n 0\n\n 236\n\n 6d\n\n [Direct-to-AIP] Onboard PT-USDG-25FEB2027 on X Layer\n\n 0\n\n 75\n\n 6d\n\n [ARFC] Deploy Aave V4 on Base\n\n 7\n\n 1.3k\n\n 11d\n\n [Direct-to-AIP] Asset Listing - USDe X Layer\n\n 2\n\n 120\n\n 13d\n\n [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\n\n 1\n\n 222\n\n Sep 18\n\n [ARFC] Onboard cirBTC on Aave v3 Core and Aave V4 Core\n\n 4\n\n 474\n\n Sep 1\n\n How can i set a specific custome migration fee for l2 blockchains\n\n 0\n\n 53\n\n Aug 29\n\n [Direct-to-AIP] Asset Listing - USDC X Layer\n\n 1\n\n 216\n\n Aug 24\n\n ARC: Add support for StakeWise’s permissioned staked ETH token (psETH) to Aave Arc\n\n 5\n\n 2.7k\n\n Aug 3\n\n [Direct to AIP] Onboard syrupUSDG on Aave V4 Global Dollar Hub\n\n 3\n\n 704\n\n Jul 28\n\n [ARFC] Onboard USDai & sUSDai to Aave V3 Arbitrum Instance\n\n 12\n\n 2.7k\n\n Jul 23\n\n [ARFC] Onboard syrupUSDC to Aave V3 Core Instance\n\n 17\n\n 3.7k\n\n Jul 23\n\n [Direct-to-AIP] Onboard PT-USDG-24SEP2026 to Aave V4 on Ethereum\n\n 7\n\n 1.0k\n\n Jul 16\n\n [ARFC] Onboard stcUSD to Aave V3 MegaETH\n\n 11\n\n 969\n\n Jul 2\n\n [Direct to AIP] Onboard PT-sUSDe-22OCT2026 to Aave V3 Plasma\n\n 2\n\n 335\n\n Jun 18\n\n [Direct to AIP] Onboard Strata srUSDe-22OCT2026 PT tokens to V3 Core Instance\n\n 2\n\n 283\n\n Jun 16\n\n [ARFC] Onboard PT-sUSDE AUG14 Expiry to Aave V3 Core Market and Aave V4 Ethereum\n\n 1\n\n 258\n\n Jun 5\n\n [ARFC] Onboard pufETH to Aave V3 Core Instance\n\n 20\n\n 1.5k\n\n May 26\n\n [ARFC] Onboard MNT, mETH, cmETH as collateral assets on Aave v3 Mantle Instance\n\n 8\n\n 1.3k\n\n May 7\n\n [Direct-to-AIP] Onboard USDe to the Aave V3 MegaETH Instance\n\n 5\n\n 752\n\n Apr 20\n\n [ARFC] Onboard PT-USDG-28MAY2026 to Aave V3 Core Instance\n\n 4\n\n 894\n\n Apr 14\n\n [Direct to AIP] Onboard BTC.b to Aave V3 Core Instance\n\n 5\n\n 704\n\n Mar 19\n\n [Direct to AIP] Onboard USDe & sUSDe May expiry PT tokens on Aave V3 Core Instance\n\n 5\n\n 536\n\n Jan 29\n\n [TEMP CHECK] Add LIT to Aave v3 Main Instance on Ethereum\n\n 0\n\n 124\n\n Jan 21\n\n [ARFC] Onboard Strata srUSDe PT tokens to V3 Core Instance\n\n 8\n\n 1.1k\n\n Jan 20\n\n [TEMP CHECK] Onboard kBTC to Aave V3 Core Instance\n\n 1\n\n 245\n\n Jan 14\n\n [Direct to AIP] Onboard syrupUSDC to Aave V3 Base Instance\n\n 5\n\n 889\n\n Jan 9\n\n [Direct to AIP] Onboard USDe & sUSDe April expiry PT tokens on Aave V3 Plasma Instance\n\n 4\n\n 609\n\n Dec 2025","tokens":645,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260205241,"hash":"b420d96d094c757a15359ef0fd92bc1215230f58"}
{"url":"https://gov.optimism.io/t/accelerated-decentralization-proposal-for-optimism/8875/1","domain":"gov.optimism.io","title":"Accelerated Decentralization Proposal For Optimism - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Accelerated Decentralization Proposal For Optimism \n\n ✨ General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2024\n\n 1 / 37\n\n Sep 2024\n\n Aug 25\n\n post by GFXlabs on Sep 17, 2024\n\n GFXlabs\n\n Authors: @GFXlabs\nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary)\nIf you hold OP, please signal your approval of this accelerated decentralization on this Snapshot petition.\nMotivation\nThe promise of the OP token is to govern the Optimism L2 software. However, to date, neither Token House nor Citizens’ House has the power to execute code. In fact, governance does not even control its own governance contract. Optimism governance governs exactly nothing in its own right today, relying upon the Foundation to even create proposals. This stands in stark contrast to Optimism’s main competitor, Arbitrum, where the ARB token has complete system control over Arbitrum One and Arbitrum Nova.\nOptimism governance launched more than two years ago. Over this time, governance has matured considerably, with increased capacity for decision making, increasingly robust checks and balances, and professionalization of many elected positions. While there was some early value in the Foundation and OP Labs having all system access powers, that time has passed as both the promised decentralization of power and the business strategy of Optimism have underperformed expectations.\nTransferring all system powers, resources, and access to governance can relieve OP Labs and the Foundation from their burdens, and allow them to focus on the tasks they do best. It will also offer rejuvenation to a system that is currently stagnating with only de minimis progress towards decentralization, and a business strategy that appears to be high in cost and low in benefit.\nLike an aging parent whose own capabilities are no longer growing, we hope Foundation and Labs will embrace our view that it is time to let the Optimism governance provide the vigor, clear direction, and focus on delivering value to tokenholders that they cannot. This is not an attempt to push either entity into irrelevance or diminish their contributions that have helped raise governance to a level of maturity and responsibility that it is ready to take the lead.\nWith that goal in mind, we have divided this plan into three phases of decentralization, to be completed by summer of 2025. Phase I, which governance contributors desire to see immediately, consists of resources that are ostensibly owned by governance and governance infrastructure. The immediate handover of control over funds and governance assets does not put any user funds at risk in any way, and does not insert governance into the core smart contracts.\nPhase II consists of items that, while not core contracts of the protocol, are essential infrastructure that will require an orderly handover and cannot realistically be done immediately. They can, however, be accomplished swiftly.\nPhase III is all remaining privileges, access, and control of onchain contracts and assets, and represents a complete decentralization of governance.\nPhase I (Immediate)\nOP Token Contract Ownership\nUnlike some competitors (like Arbitrum), the OP token has no established rights to execute code, make proposals, share in revenue, or anything else.\nThis manifests itself as a lack of interest in OP as a governance token, making it a struggle to convince some users to delegate or vote. In some circles, OP is actually referred to as a meme coin, and not jokingly so.\nOf particular embarrassment is that the OP token does not even own its own contract. Transferring ownership of the token contract to governance is an essential first step in a credible plan to make the OP token serve its intended purpose of governing Optimism.\nPutting the token contract under onchain governance oversight also ensures that basic tasks will get done, like deploying standardized OP token contracts on Superchain member chains and a reliable, quick mint-burn bridge between those chains. This is of particular urgency with the Superchain grants program scheduled to dispense 12,000,000 OP tokens to member chains, but with no way to reliably get those tokens to those chains.\nGovernance Contract Ownership\nMuch like with the OP token, the governance contract used for voting is not under governance control. This leaves governance dependent upon the Foundation’s approval to present proposals for a vote. Lack of governance control has also resulted in episodes where the governance contract has been upgraded without the knowledge, much less the consent, of governance.\nBecause the governance contract currently controls no parameters of Optimism mainnet, giving onchain control of this contract to OP tokenholders can be enacted immediately.\nFor the avoidance of doubt, governance ownership of the governance contract includes a permissionless way for delegates to submit proposals for a vote.\nGovernance Fund Ownership\nThe OP tokens in the Governance Fund should be transferred to an address controlled by the governance contract.\nETH Collected on Behalf of Optimism Collective Comes Under Governance Control\nThere is currently 15,397 ETH collected for the benefit of Optimism governance, spread across several addresses under Foundation or Optimism Labs control. This ETH, minus a buffer for operational costs recommended by Labs, should be transferred to an address on L1 controlled onchain by Optimism governance.\nPhase II (concluding end of Q1 2025)\nBridge L1 Escrow Comes Under Governance Control\nOP Bridge currently holds several billion dollars in assets that could be deployed across Ethereum mainnet to generate revenue for Optimism governance. Utilizing bridge assets is being made common by other chains, most notably Blast, Mantle, and Gnosis, with Polygon looking like it will follow suit.\nWhile we do not propose a plan for utilizing these assets or any immediate changes in where they are held on L1, we do believe it is a decision for governance to make. This is particularly important from a sustainability perspective, since the current vision for Optimism revenues are tied to sequencer revenues on Optimism and Superchain members. As sequencer revenues trend towards zero over time in an intensely competitive marketplace, the bridge is an obvious way to permanently create sustainable revenue streams over the long term for governance and the maintenance of Optimism.\nSequencer Decentralization Roadmap\nOP Labs and/or the Foundation should present a plan to decentralize the Optimism mainnet sequencer before the end of March 2025. This plan should include specific actions to take and requirements. The plan also must include a target date to decentralize the sequencer for Optimism before the end of Q2 2025.\nIf this date to decentralize the sequencer is determined to be unfeasible within the decentralization plan, then the plan should also present specific actionable steps to ensure the current sequencer operator is directly accountable to governance for major parameters.\nRevisions and Re-Ratification of the Law of Chains\nThe Law of Chains was not drafted by governance, though governance ratified it. The Law of Chains will be reviewed for conflicts with this roadmap and other governance priorities, and revised, or re-ratified as is by governance. A schedule to periodically revisit the Law of Chains will also be established to ensure that it serves the needs of governance in its task to protect, grow, and generate value for Optimism stakeholders.\nPhase III (concluding Q2 2025)\nFull Control of Optimism by Optimism Governance\nComplete technical control over the Optimism protocol should be handed over to Token House, Citizen’s House, and various bodies appointed or elected by Token and Citizen’s House. This handover can be done by empowering the current governance contract or by providing a new architecture that is approved by governance.\nThe Foundation is encouraged to seek a permanent seat on the Security Council and potentially other privileges, but those should flow from authorization by governance and not from the Foundation’s own authority.\nFoundation Grants Disclosure\nNo later than the end of Q1 2025, the Optimism Foundation should commit in a binding manner to disclose to Optimism governance all past and ongoing grants. To the extent some of this information may not be made public, the Foundation must offer to make this information available to appointed representatives of Optimism governance.\nCompleted Decentralization of the Sequencer\nBarring legal or technical blockers, the sequencer should be decentralized according to the plan presented by OP Labs and/or Foundation in Phase II.\nIf you hold OP, please signal your approval of this accelerated decentralization on this Snapshot petition.\n\n Where are the Optimisms main treasury addresses?\n\n Revenue Opportunities for the Optimism Collective\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n GovNFT Community Call Thread 5\n\n The Future of the Anticapture Commission\n\n 5\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 33\n min\n\n post by jacq on Sep 18, 2024\n\n jacq\n\n Thank you for laying out this plan, I appreciate the thoughtfulness put into each step and agree that we can do more to decentralize, the time is ripe for change. Just out of curiosity, are there any risks you’ve identified associated with an accelerated timeline?\n\n post by GFXlabs on Sep 18, 2024\n\n GFXlabs\n\nPhase I are all items that don’t impact the Optimism chain itself, and are mainly around governance no longer using the Foundation as a custodian for its own assets. So risks there would primarily be around wasting funds (OP and ETH).\nPhase II and III would involve some technical risk in any kind of handover, and would need to be treated with the appropriate amount of preparation and testing. There is also the possibility that governance could find some way to damage the chain through control of the bridge, sequencer, and protocol upgrades but that’s true of anyone controlling those items – note that we just saw a fix to a protocol upgrade from OP Labs around fraud proofs. Governance control mainly lends even more eyes to the same issues.\nLike parents of a grown child, Labs and Foundation will both have significant influence and voice in a governance-owned protocol. If the intent is to decentralize, there’s not much reason to wait any longer, since governance at Optimism has already had several years to mature.\n\n post by system on Sep 18, 2024\n\n system\n\n Thank you for raising this conversation. The Collective’s progressive path towards full decentralization is an important topic.\nTactically, the Foundation has been working on several initiatives to share more information about this path, accompanied by collaborative conversations to gather input from the community, in the coming weeks and months.\nThe timing of this post coincides closely with several of those initiatives, including:\n\nPublication of a framework outlining the milestones towards Optimism’s progressive decentralization (currently under review by the Collective Feedback Commission and other advisors), meant to occur over a period of multiple years, as originally outlined in the Working Constitution.\nA post outlining how a series of upcoming proposals in Season 6 move us closer to some of these milestones (and interoperability).\nThe Foundation’s Product Vision, which lays the groundwork for the Collective to be involved in the 2025 planning process starting in November.\n\nThe hope is that these efforts spur constructive, rather than divisive, conversations that result in a plan that is in the best long term interest of the entire Collective.\nIdeologically, it is important to remember our original commitment to take a fundamentally different approach towards progressive decentralization, which means drawing direct comparisons to other systems can be counterproductive.\nOur Working Constitution outlines that our path towards decentralization will be gradual (over the course of several years), experimental, and iterative. The role of the Foundation in this journey is to bootstrap a sustainable governance system, based heavily on the input of participants, that enables the accomplishment of the key strategic goals of the Collective over the long term.\nOptimism Governance is uniquely designed to be the system through which the entire Collective will derive security and accomplish strategic goals. This vision is distinct from other ecosystems’ approaches. It requires a fundamentally different approach and a timeline tied to the security, sustainability, and resilience of the system rather than speed.\nWe remain fully committed to gradually and fully decentralizing the system. We hope the upcoming publication of our milestones towards decentralization serves as a tool for the community to hold us accountable in this process. The journey along this path will involve ongoing and collaborative conversations with the community.\n\nBelow we address @GFXlabs’s specific proposal, line by line:\nPhase 1\n\nToken contract\n\n“the OP token does not even own its own contract”\n\nDepending on interpretation, we find this statement misleading, if not inaccurate. To clarify, the OP Token does not authorize any L2 account to upgrade its code. The only way to upgrade the OP Token is via a Protocol Upgrade. This was an intentional decision made to reflect our view that token contract upgrades should not occur frequently, if ever. Effectively, this means that the OP Token is already “owned” by the Collective via the same Security Council it has authorized to implement other protocol upgrades. However, we appreciate that this may be opaque and could benefit from a concrete example of the process in practice.\nAdditionally, we agree that deploying a standardized OP Token contract to other chains is a critical feature, one which we believe does justify using a Protocol Upgrade to modify the OP Token. Several Core Developers in the Collective have been working on this in earnest over the past few months as a part of interop development. We expect that this proposal will be a part of the interop rollout in the first half of 2025. We hope that this will help provide a concrete example of OP Token upgrades, and demonstrates our approach towards bringing governance responsibilities online as they support strategic initiatives and not as ends in and of themselves.\n\nGovernance Contract Ownership\n\nThe transition of control over the onchain Governor contract to OP tokenholders is already planned to occur before the end of Season 6. This proposal will transition upgrade control to the Security Council, which we believe will allow us to remain agile without risking an irrecoverable bug. Stay tuned for more details in the proposal, expected to be posted by Agora in Voting Cycle #28 or #29.\n\nIn regards to the ability for delegates to submit proposals for a vote, we don’t believe it is safe to put the entire Governance Fund onchain with permissionless proposal rights while the cost of governance attack is currently lower than the value of the Governance Fund. This is a dynamic many DAOs currently face but that we can avoid while we work to increase votable supply (and we’ve hired someone to focus exclusively on doing this.) However, Agora has shipped a new feature that allows any delegate to draft a proposal in the voting UI. Drafts will still need to follow a valid proposal type and receive the required delegate approvals to move to a vote.\n\nGovernance Fund Ownership\n\nThe proposal referenced above (expected in Cycle #28 or #29) would move the Governance Fund entirely onchain, meaning budget proposals would execute onchain. This means that the Grants Council, if renewed, would manage its own grant delivery process, largely eliminating the Foundation in this process.\n\nETH Collected on Behalf of Optimism Collective Comes Under Governance Control\n\nWe don’t currently believe there is a strategic need for the DAO to manage ETH while the DAO has access to the +150M OP Governance Fund and the +800M OP Retro Fund. This is also a responsibility that should come online alongside a comprehensive framework for managing the treasury, governing the macroeconomic policies of the Collective, and measuring the efficacy of capital allocation. These are all important governance responsibilities that are under or poorly defined in most other systems. We agree with the sentiment that the near term priority should be on the more technical aspects listed above rather than transition of these responsibilities.\n\nPhase 2\n\nBridge L1 Escrow Comes Under Governance Control\n\nIt is not entirely clear whether this milestone is suggesting any change in control structure. All L1 contracts, including bridge Escrow contracts, are already held by the Security Council. If this is a suggestion to move the ownership directly to an onchain governor contract, we feel the need to emphasize that this would pose a potentially existential security risk until we achieve Stage 2 decentralization.\n\nWe agree that all Protocol Upgrades—of which L1 Escrow contracts are among the highest stakes—are decisions for governance to make. However, since this post alludes to “utilizing” the bridge funds, we feel an obligation to express our strongly held viewpoint that such appropriation of user assets would represent an existential threat to Optimism’s social contract, business reputation, and long-term viability. Tactically speaking, it is a clear violation of the key User Protection to State Transition and Message Validity outlined in the Law of Chains. Strategically speaking, the Collective is in the business of providing neutral, scalable blockspace. No matter how alluring it may be to move user assets, deposited with the clear expectation of being fully custodied in a known escrow contract, into a different smart contract—even a relatively low-risk one—the long-term erosion of trust which would accompany such violation of expectations outweighs any short-term sustainability improvements which might come with it.\n\nWe would also like to reinforce that the Law of Chains is a critical governing document, which was ratified by the Token House. The Law of Chains also plays a pivotal role in onboarding OP Chains to join the Superchain, which is the sustainable way to drive revenue for the Collective.\n\nSequencer Decentralization Roadmap\n\nWe think sharing more plans on the timeline suggested is a reasonable goal. It feels worth flagging now that this will be a long burn — decentralized sequencing protocols are still rapidly evolving, but even beyond the tech itself, have deep economic and strategic implications for the Superchain and its partners. As such, we think holding the sequencer accountable to governance is the correct short-term focus.\nThe OP Labs team is actively working on productionizing and open-sourcing the infrastructure required to easily run a high-availability, performant sequencer, so that switching OP Mainnet to a new sequencer is more feasible. The Standard Rollup Charter draft contains an initial proposal for sequencer accountability structures; we welcome feedback and collaboration on the relevant governing policies.\nLastly—over the next quarter, we expect to see new core development work with a focus on sequencing. For example, the Flashbots team recently began engaging heavily with OP Stack core development processes. We are extremely excited to build a collaborative roadmap with industry experts, and hope that this will both accelerate development, and decrease reliance on OP Labs and the Optimism Foundation as a bottleneck to this part of the roadmap.\n\nRevisions and Re-Ratification of the Law of Chains\n\nThe Law of Chains is a foundational governing document upon which all OP Chains rely. This document serves the critical purpose of providing a neutral, transparent, and long-term social contract for how the Collective makes decisions about protocol upgrades. As such, it should not be subject to change often–especially as we move towards upcoming interoperability milestones, where governance rigidity is even more of a key value proposition (see framework by Vitalik here). Periodic review of this document can be facilitated, but should occur on a 1-3 year cadence.\n\nThe ability to propose amendments to the Law of Chains is a metagovernance right, which has always been slated to be the last set of governance responsibilities to come online. This is partly because the ability to change the system while it is being built, and while new partners are relying on its consistency, is destabilizing. The Collective Feedback Commission is the first step in a gradual path to decentralizing these rights.\n\nPhase 3\n\nFull Control of Optimism by Optimism Governance and Completed Decentralization of the Sequencer\n\nWe continue to be fully committed to the transition of full control over the system to Optimism Governance and to complete decentralization of the sequencer. The difference of opinions on this is only in regards to the timeline required to make this transition responsibly.\n\nFoundation Grants Disclosure\n\nAlthough the budget with which the Foundation makes these grants was part of the initial token distribution, and is therefore not subject to detailed disclosure, we are supportive of greater disclosure around the Foundation’s expenditures. However:\n\nPublic disclosures about individual grants will only be made at the point in time at which it does not jeopardize the Foundation’s ability to onboard more OP Chains to the Superchain, something which greatly benefits all members of the Collective.\n\nWe are not supportive of select grant disclosures to certain delegates within the Collective, as that can create tiered information asymmetry among delegates.\n\nFor reference on current disclosures, delegates can refer to previous budget reports on the forum.\n\nAs stated above, this is a very important topic and this post has started a very important conversation. We look forward to continuing to engage in many more constructive and collaborative conversations on this topic as we work to progress on this path as a Collective.\n\n OP Bulletin: Weekly news and insights on the Optimism Collective \n\n GovNFT Community Call Thread 5\n\n Optimism Community Call Recaps & Recordings Thread\n\n post by GFXlabs on Sep 18, 2024\n\n GFXlabs\n\n It’s wonderful the Foundation has taken the time to address the priorities laid out above in detail. Some of them do require some additional context for readers, or prompt a request for more clarification.\n\nWe don’t feel this is the case. Optimism’s governance structure, with the Citizens’ House and Security Council, has fairly robust checks and balances compared to most DAOs. Additionally, it wouldn’t be unreasonable to discuss the Foundation retaining some form of veto rights that it could actively exercise over certain sorts of proposals.\n\nThere is a very strong strategic need for governance to have these funds. Firstly, under the Foundation’s custody, this ETH is like a fallow farm field. None of the substantial ETH is staked, either through a service or directly staked. It is clear that there is some hesitancy on the part of the Foundation that makes them skittish about picking such low-hanging fruit. Let governance assume this risk, and offload it from the Foundation.\nSecondly, and more importantly, Optimism suffers under a competitive disadvantage versus other grants programs, in that any grantee being directly compensated has their funds locked for 12 months. This is because they are paid in OP tokens, which are also volatile in price. Having access to this ETH would allow these grants – currently forcing grantees to be illiquid and long OP tokens for a year – to be made with ETH or stables, neither of which presumably require a 12-month vesting. Currently, grants that must be locked regularly have to overpay for services or attract lower quality counterparties, and governance control over this ETH would remedy this.\n\nWe think this option should remain open. We and others have lost faith in the current business model of relying upon sequencer revenue, both from Optimism and Superchain members. We fully expect sequencer revenues to trend down over time as L2s must remain competitive with both each other and mainnet. This means the revenue may not allow Optimism to be sustainable, and also that other Superchain members will have an incentive to pioneer new ways to see returns on their investments, since Optimism gets 15% of sequencer revenues. Already we see ultra-low-fee Superchain members where sequencer revenue may never materialize in any meaningful way.\nUsers have shown little aversion to conservative bridge asset management. Gnosis, Blast, and others serve as examples. Polygon may be the first of the “major” chains to experiment with this, as they are fielding proposals currently. That should serve as a good test of whether users react negatively and can inform any future plans.\nBut there are no plans at present. We believe it’s the responsible thing to do to keep options open, though.\n\nThe Law of Chains does not irrevocably bind Token House or governance as a whole. It even says so:\nBut Participant Protections are not, and do not create, legal rights, or corresponding legal obligations. They are not absolutely guaranteed to any ecosystem participant.\nThe Law of Chains is a set of guidelines. It is not a contract.\nGovernance approved it, and governance can change it. It is also specifically intended to be a living document, and will require regular updating and re-ratification to remain relevant.\nAs stated upthread, we do not have faith that sequencer revenue sharing will long-term provide the return that OP tokenholders require to justify holding the asset.\n\nThis is an entirely reasonable response, and we’re happy to see it.\n\nThis is another area where Optimism lags behind peers. Consider beginning with a level of disclosure similar to The Arbitrum Foundation, and working out from there to meet this goal. See this example:\nScreenshot 2024-09-18 at 5.21.13 PM1564×1162 121 KB\n(The footnote leads to a table of projects that have received grants, though not with amounts.)\nCompare to the Optimism Foundation, which does not readily make available lists of grants made at the discretion of the Foundation.\n\n100% agree, and we are excited to move forward on this together. We view the Foundation and Labs as parents to governance. Just as there is sometimes tension when a child has grown up, and the parents need time to adjust to the new dynamic, we understand it can be difficult to let go of the reins. The Foundation has done a wonderful job raising governance, but governance has matured, and it’s time to begin the transition from Foundation overseeing governance to governance being a full partner in developing and growing Optimism.\nIf you hold OP, please signal your approval of this accelerated decentralization on this Snapshot petition. \n\n post by parseb on Sep 18, 2024\n\n parseb\n\n Progressive decentralization, the paradigm adopted by the OP collective from a16z, has not historically (20th century or last 4 years) worked. This proposed approach is downstream of that and representative of the generalized local minimum governance efforts are in.\n\nSeeking and nurturing variety is crucial to overcoming this phase.\n\n post by lefterisjp on Sep 19, 2024\n\n lefterisjp\n\n I am quite happy to see this conversation.\nI think we should strive for better decentralization of the Optimism ecosystem as indeed at the moment it’s firmly at the hands of the foundation.\nI appreciate that the foundation has a roadmap for this decentralization but it’s been years already and the progress is quite slow. Especially when compared with other L2s.\nWe can do better.\n\n post by Tadas on Sep 19, 2024\n\n Tadas\n\nAs I understand a key problem here is voter-apathy. I’ve been working on a solution to this. It is currently oriented towards a different context (community with non-transferable reputation token), but I see potential potential to extend it and general approach might be valid for other contexts (especially Optimism I would say because of bicameral governance structure that it uses). You can read the idea here. Note this section which considers applicability of this idea to other contexts. Feedback is appreciated.\nMy intuition is that when it comes to control of core contracts for Optimism the right solution lies in creative ways of utilizing its bicameral governance structure.\n\n post by Gonna.eth on Sep 19, 2024\n\n Gonna.eth\n\n Disclaimer: The views expressed here are my own and do not represent the Grants Council, Govnerds, Feedback Commission, or any other governance entity I am involved with.\nI am signing the petition, but I want to provide clarity on what I am supporting by doing so. I agree with GFXlabs on some points and also believe the Foundation plays an essential role in ensuring the success of this process.\n1. Decentralization of OP Governance (Phase I)\nI fully support the need for governance to gain more control, especially over the OP token and governance contract. However, I believe the Foundation should present a clearer roadmap toward this decentralization. This roadmap should include checkpoints, allowing the collective to evaluate progress and adjust if necessary, but it must set clear expectations about where we are heading and how long each step will take.\n2. Governance Fund and ETH Control\nWhile I understand GFX’s call for immediate governance over these funds, I believe the Foundation should retain control for now. However, I suggest establishing a Treasury Council, initially overseen by the Foundation, which gains more autonomy over the seasons as it becomes battle-tested. This approach strikes a balance between decentralization and ensuring the security of these resources. The Treasury Council could start by handling grants approved by the Grants Council. In line with the Foundation’s example, I believe the Grants Council is gaining too much power, and decentralizing oversight would allow both the Treasury Council and the Grants Council to oversee and check each other, fostering a more balanced governance structure.\n3. Bridge Assets Utilization\nI agree that bridge assets should be under governance control, but not primarily to generate revenue. The key reason is to avoid unilateral decisions made by non-governance actors. Again, this should be managed by a Treasury Council to ensure that the governance process is respected while protecting users and network stability.\n4. Sequencer Decentralization Plan\nI support the need for a sequencer decentralization plan, as outlined by GFX. However, I do not agree with setting a firm handover date for Q2 2025. Instead, I believe the Foundation should propose a 3-year roadmap with annual evaluations to hold them accountable. The timeline must be flexible and based on the maturity and readiness of governance.\n5. Business Strategy Critique\nGFX raises a valid point about fee revenue becoming unsustainable over time. Additionally, chains can adjust fee margins to attract users, which contradicts the proposed 15% fee revenue from chains to integrate into the Superchain. This is a crucial issue that needs to be addressed, especially if we are to sustain long-term value within the ecosystem.\n6. Complete Decentralization by Summer 2025\nI agree with the Foundation that this deadline is likely too fast. However, it would be beneficial to set a deadline and revisit it once we reach that point. A hard deadline may be unrealistic, but a target gives us something to work toward, with the flexibility to revise based on real-world progress.\nIn conclusion, while I support this push for decentralization and will sign the petition, I believe a measured and well-planned approach is essential to success. I’m a firm believer that The Foundation’s involvement can ensure we decentralize responsibly.\n\n post by MattGov.eth on Sep 19, 2024\n\n MattGov.eth\n\n I’ve also expressed my approval of this petition and want to emphasize the areas that are most important to me. My primary objective is to initiate a conversation and work toward aligning on a timeline with the Foundation to gradually and responsibly decentralize over time. This is by no means intended to rush the process but rather to ensure we move forward thoughtfully.\nI fully support Gonna’s recommendations and believe this is an excellent opportunity for the Foundation and governance to use this moment to discuss the path toward decentralization, particularly in defining a timeline for the shift.\nDisclaimer: The views expressed here are my own and do not represent the Grants Council, Govnerds, Feedback Commission, or any other governance entity I am involved with.\nMy contributions to the petition primarily revolve around the L1 Bridge Escrow and the potential to deploy these funds across L1 DeFi. I’ve conducted several economic opportunity assessments, and with the bridge funds being invested in low-risk strategies—such as MakerDAO DSR, AAVE lending markets, Lido, and other LST opportunities—we’re looking at a potential return in the range of $20-30 million by utilizing half of these assets.\nWhile this approach will require deeper consideration, it remains a crucial area of focus for me to ensure the DAO’s sustainability and to support the ongoing expenses of various growth programs. The best case scenario from my perspective would be to focus on growth with funds generated through DAO-led initiatives like this, limiting the use of OP tokens while still ensuring that security is paramount.\n\n post by katie on Sep 19, 2024\n\n katie\n\n I want to preface my statements by saying that I appreciate the work put into this proposal and the dialogue and engagement it has prompted. However, I do not agree with this proposal and will not be singing the petition.\nI have the benefit of being on the other side of governance and working at a Foundation that eventually dissolved and fully decentralized the protocol. OP Labs and Foundation are private companies and it’s unrealistic to think that we, as community members, will ever have a complete view of everything that’s happening behind the scenes. These teams have actually been extremely transparent in their plans, but it’s impossible for them to share every detail because we are not employees.\nI also have the benefit of being involved in governance since day one and witnessing the monumental changes in our governance structures. The Foundation has not given us any reason to believe that they will not decentralize, when they have already shipped the Security Council, fraud proofs, Citizen’s House veto, etc. Decentralization takes time and Optimism is still in it’s infancy with only 2 years of governance under our belts.\nDecentralizing too quickly would be catastrophic, especially when DAO governance itself is brand new and there aren’t really any examples of any DAOs doing this right imo. I would encourage everyone to slow down and reflect on how far we have already come.\n\n post by hashigo on Sep 19, 2024\n\n hashigo\n\n While I acknowledge the need for transparency and decentralization, I don’t think it’s good practice to rebut an opinion submitted on the forum through personal X account.\n\n post by katie on Sep 19, 2024\n\n katie\n\n Agreed, this type of behavior is unnecessary.\n\n post by Oxytocin on Sep 20, 2024\n\n Oxytocin\n\n Glad to see such detailed debate on this important topic, both from GFX labs as well as the response from the Foundation. I have signed the petition , less so because of the original roadmap (as it has already been discussed), but to signal the importance of progressive decentralization.\nI look forward to seeing the planned transitions to OP badgeholders by the end of Season 6, but wanted to ask a question regarding one part of the reply:\n\nIn addition to the other safeguards mentioned by @GFXlabs , isn’t one of the roles of the Anti-capture Commission to mitigate this risk? With their voting supply + quorum requirements , I can see most potential attacks having to undergo countermeasures that are a lot more robust than in other DAOs. I understand that perhaps it’s still not considered a developed enough commission to defend something of as high value as the Governance Fund, but I feel it’s still worth considering\n\nJust to share an opposing view, is this not being done already by Token Delegates through their budget votes? I’m curious to hear more about what you have in mind, but right now it feels like the Treasury Council would serve little purpose other than to stand between the Token House and Grants Council.\n\nThe final thing I wanted to share regarding this discussion comes from a very important summary from @katie . This is more of an observation than something that can be done in an actionable manner, but I feel that part of the reason people might feel Optimism isn’t decentralizing isn’t because there’s no efforts, but because the steps are being made on much larger time frames compared to other Onchain organizations.\nThis is something that the Foundation is clearly doing deliberately (see the comments on ETH treasury spending), and I feel future Seasons communications could start emphasising on this more. We already have Themes each season, but I feel is important to also start summarizing the learnings and advancements of each Season, to show how progress is being made.\n\n post by AnthiasLabs on Sep 20, 2024\n\n AnthiasLabs\n\n Our team at Anthias Labs has signed this petition to signal a need to further this conversation proposed by @GFXlabs. Along with risk, our primary focus as delegates has been attempting to clarify the unique Optimism value proposition and how the Optimism Collective can capture part of the value it creates from this unique value proposition.\nThe value proposition of the Superchain may be correct, but we, along with other delegates, continue to maintain the thesis that sequencer fees are going to 0. Therefore, it is insufficient to consider Superchain sequencer fees to be the only path of Optimism Collective value accrual for the next 3, 5, 7+ years.\nWe believe that the Collective needs to begin focusing more on the app layer as opposed to purely the chain layer for value capture (or at least test this), but the current construction of the DAO does not fully allow for this testing. There is no current way–at least to our understanding–to test a program like the following:\nHow can the Optimism Collective gain more revenue in new ways? One way will be to supercharge a handful of apps with incentives as opposed to spreading incentives thinly across many apps. Utilize the same amount of OP incentives (or less), but target them much more effectively. Thesis: More builders + users will migrate directly to Optimism for 20%+ yields on 3-4 apps than 8%+ yields on 30-40 apps, so long as the risk profile is similar. We can test this for one season and see the TVL growth relative to market beta. A rough plan would be to foster an application process where apps apply for these incentives from the DAO. Then, the top 3-4 apps will be selected, and these will be the supercharged Superchain apps. In exchange, these apps will give back to the DAO in revenue share, which will ideally drive more value to the OP token.\nA program like the above is a concept that could not be proposed today by a delegate or group of delegates and does not fit in the current structure of the Grants Council. It is just an example of a new way of value accrual that the Collective could benefit from testing for one season.\nWhether or not the full roadmaps outlined in this forum thread or as outlined by the Foundation are accurate or will need to be amended, it is clear that the Optimism Collective is in need of clarification here if it seeks to maintain its position and not fall to emerging L2 and alternative L1 solutions.\n\n Revenue Opportunities for the Optimism Collective\n\n post by Gonna.eth on Sep 20, 2024\n\n Gonna.eth\n\nI proposed this as a baby step towards establishing a battle-tested Treasury Council that would eventually be able to execute key tasks like grant deliveries, Retro funding distributions, and governance rewards. The goal is to gradually build its capacity, so it can also propose a strategy to put the 15,397 ETH collected into a sustainable farm for the Token House in the near future. This isn’t about creating a barrier, but rather ensuring we have a structure in place that can effectively manage these responsibilities as we decentralize further.\n\n post by ccerv1 on Sep 20, 2024\n\n ccerv1\n\n I appreciate the intention but have some major concerns with the approach and “why now” rationale. I will add that I’m not a token house delegate, just an engaged citizen and working on a project that has received grants from the Foundation.\nThe Good\nThere are two things I really like here.\nFirst, I think it’s good for there to be a clearer decentralization roadmap and scorecard. It should be simple and objective, but not overly prescriptive. My mind immediately goes to a version of L2Beat’s risk analysis pies that tracks progress towards governance decentralization.\nFor instance, one criterion could be that the foundation has a viable economic model in place that has performed well under different market conditions. Right now, you and others in this thread point out long-term risks with the viability of the sequencer fee revenue model. So some proof point around economic viability should be a stage gate for full decentralization, not something we expect to be magically solved post-decentralization.\nYou named some other potential stage gates, like the token governing the contracts, decentralizing the sequencer, etc\nSecond, I like that this is a measurable “vibe check” on whether OP is moving fast enough towards complete decentralization.\nThis kind of feedback or referendum, taken at regular intervals, could be a really good thing. Voting and forum discussions are very tactical; they don’t offer much signal on delegate sentiment or confidence in governance. They also don’t show us the trendline.\nThat said, the “vibe check” aspect should be separate from the “what next” aspect.\nMany might share the sentiment that decentralization is taking too long, but have diverging views on the actions needed, the order of operations, or the overall timeline. In nation-state elections, 80% of voters might agree that “the country is on the wrong track” but then split their votes 50/50 across parties.\nReading through the comments above, it seems there is more support for the goal of accelerating decentralization than for the specific actions / timelines you propose. This petition has been effective at raising attention, but doesn’t give insight into which items on the agenda resonate most with delegates.\nConcerns\nThere are two major concerns I have with this proposal.\nFirst, OP governance is really complex. This bicameral house thing is unique. The surface area of what it is intended to govern is vast. The technical roadmap is hard. The endgame for how everything should be funded retroactively is fuzzy. Perhaps it’s all too ambitious. But that’s what we came here to try… right???\nI have low confidence that rapid decentralization makes this easier.\nHumans and wildebeests are both mammals. They both walk, eat food, and do things in groups. Humans spend over a decade learning how to walk, feed themselves, and contribute to a group. Wildebeests are literally born standing up and are fully independent in a week.\nThe point is that just because there are examples of DAOs that decentralized faster, it’s wrong to assume that every DAO should follow a similar trajectory / timeline. More complex organisms take longer to stand on their own. In nature, this is generally a function of brain size. More than 20% of human energy goes towards powering the brain. In wildebeests, it’s <5% — all their energy goes to walking around and running.\nHopefully it’s evident that governing Optimism is harder than most other things in Ethereum today. And for every (less complex) project that may appear to be on the right track, there are hundreds that have crashed and burned.\nMy second, even bigger concern, is who is going to do the governing.\nAnyone reading this post is probably an OG. Thank you for not giving up on DAO governance because you’ve probably seen your share of shenanigans.\nBut is this what you do full time? Is this – Optimism Governance – what you want to do full time?\nAlthough there is a rising class of up-and-coming delegates from within the community (who play active roles in the grants council, Citizens House, etc), most voting power still rests in the hands of <50 organizations / individuals who are delegates for multiple DAOs and who are also running their own organizations at the same time they are doing this. Their time is at a premium and generally they only speak up on really important high-level matters.\nThat’s fine, but stuff has to get done too. Who is going to do the hard work of vision setting, retaining focus, saying no to all the cash grabs, pushing for greater efficiency, etc etc ?\nThe reality is that the Foundation currently has people spending 100% of their time on these problems. They also run RFPs and oversee external teams to build stuff. Long term, this work either needs to be solved by code / mechanism design or put in the hands of groups with sufficient context and incentive to do it well. That takes time. The more we expect to be solved by code / mechanism design, the less we should expect it to follow a predictable timeline.\nIMHO, this feels like the hardest problem: building a talent funnel of fully-engaged governance participants who can take the baton from some of the OGs and give this work their full mindshare.\nFinal thoughts\nYou are totally right to point out that existing incentives (investors, job security, etc) make it hard to decentralize — and as result there should be a strong counterweight.\nPersonally, I think that will be better accomplished in the short to medium term by (a) clarifying what training wheels need to come off, (b) openly tracking progress in removing them, and (c) facilitating regular vibe checks on the foundation’s seriousness about all this.\n\n post by LuukDAO on Sep 21, 2024\n\n LuukDAO\n\n I’ve been following this thread for a couple of days and fully agree with Carl’s points.\nOver the years, I’ve first-hand experienced the rise and fall of multiple DAOs. From my experience, real DAO leadership effectively guiding the entire network to focus on its goal is challenging to establish and maintain.\nI like the tangible steps of mapping and defining what training wheels need to come off, the minimum requirements (and nice to have\"s) before they can be taken off, and openly collaborating to progress this shared roadmap, which is the best way forward.\nWith Superchain Eco, we’re fully committed to helping realize the Optimism vision and progress its decentralization. One of our primary aims is building that talent attraction and retention funnel.\nNow is the right time to start taking the next steps. @GFXlabs, thanks for jumpstarting this conversation!\nI’m happy to support the first step and contribute to mapping the governable universe of Optimism, understanding where responsibilities currently sit, and identifying what is required to manage certain system elements properly.\n\n Good for everyone\n\n post by lavande on Sep 23, 2024\n\n lavande\n\nHi @LuukDAO - I wanted to let you know that the Foundation has drafted something very similar to what you/@ccerv1 describe above. This “decentralization milestones framework” is currently under review by the Collective Feedback Commission and we plan to publish it soon, after incorporating their input. I’d be happy to discuss about how we might collaborate on refining that framework and/or monitoring our progress towards different milestones, as that will be an important part of holding the Foundation accountable to this framework.\n\n post by LuukDAO on Sep 23, 2024\n\n LuukDAO\n\n Great! Glad to hear this is already in motion, and we’re eager to help refine and operate the framework.\nCan DM via forum or mail to op@superchain.eco\n\n Load more posts below","tokens":12091,"squid":"ink-governance","role":"Council Listener","at":1791260214955,"hash":"fe587ddf96605db76f20910d72de4255d3c4c66b"}
{"url":"https://governance.aave.com/t/direct-to-aip-onboard-usde-to-aave-v4-core-instance-on-avalanche/25576","domain":"governance.aave.com","title":"[Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche - Governance / New Asset - Aave","text":"[Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche \n\n GovernanceNew Asset\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 1\n\n 1 / 2\n\n Aug 31\n\n Sep 18\n\n post by AaveLabs on Sep 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Title: [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\nAuthor: @AaveLabs\nDate: 2026-09-01\n\nSummary\nThis proposal seeks to onboard USDe to the Aave V4 Core Instance on Avalanche. This proposal follows the Direct to AIP route.\nMotivation\nUSDe is Ethena Labs’ synthetic dollar, targeting a value of one US dollar through a strategy that pairs staked collateral with offsetting perpetual futures positions, held largely offchain. Ethena Labs has extended USDe and its staked form to Avalanche, with support from spot and lending venues across the network.\nOnboarding USDe would:\n\nAdd a synthetic dollar stablecoin to the Aave V4 Core Instance on Avalanche.\nSupport demand emerging from Ethena’s expansion of USDe to Avalanche.\nExtend USDe’s collateral footprint within the broader Aave protocol, where it is already listed across other Aave instances.\n\nSpecification\nThis proposal onboards USDe to the Aave V4 Core Instance on Avalanche.\nRisk parameters and final configuration will be provided by the Risk Service Providers and this proposal will be updated accordingly.\nUseful Links\n\nEthena Documentation\n\nDisclaimer\nThis proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no direct financial relationship with Ethena Labs or its affiliates and has not received compensation from Ethena Labs or its affiliates in connection with this proposal.\nNext Steps\n\nGather community and Service Provider feedback.\nIncorporate the Risk Service Providers’ final configuration for the Aave V4 Core Instance on Avalanche.\nPublish the AIP vote for final confirmation and onchain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n 17 days later\n\n post by LlamaRisk on Sep 18\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Ethena USDe on Aave Avalanche Assessments\n\n Assessments\n\n 1\n\n 101\n\n Sep 18\n\n [Direct-to-AIP] Asset Listing - USDe X Layer\n\n New Asset\n\n 2\n\n 120\n\n 13d\n\n [Direct-to-AIP] Onboard USDe to the Aave V3 MegaETH Instance\n\n New Asset\n\n 5\n\n 752\n\n Apr 20\n\n [Direct to AIP] Onboard PT-USDe-22OCT2026 to Aave V3 Monad\n\n Governance\n\n 2\n\n 242\n\n Sep 4\n\n [Direct to AIP] Onboard sUSDe and USDe to Aave V3 Base Instance\n\n General\n\n 1\n\n 304\n\n Feb 24","tokens":640,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260215326,"hash":"c0db572a923d02648a3bf56a9349e7ff2752226c"}
{"url":"https://gov.optimism.io/t/accelerated-decentralization-proposal-for-optimism/8875/38","domain":"gov.optimism.io","title":"Accelerated Decentralization Proposal For Optimism - ✨ General - Optimism Collective","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 33\n min\n\n Sep 2024\n\n 37 / 37\n\n Aug 25\n\n Aug 25\n\n Load more posts above\n\n post by LuukDAO on Sep 21, 2024\n\n LuukDAO\n\n ccerv1\n\n I’ve been following this thread for a couple of days and fully agree with Carl’s points.\nOver the years, I’ve first-hand experienced the rise and fall of multiple DAOs. From my experience, real DAO leadership effectively guiding the entire network to focus on its goal is challenging to establish and maintain.\nI like the tangible steps of mapping and defining what training wheels need to come off, the minimum requirements (and nice to have\"s) before they can be taken off, and openly collaborating to progress this shared roadmap, which is the best way forward.\nWith Superchain Eco, we’re fully committed to helping realize the Optimism vision and progress its decentralization. One of our primary aims is building that talent attraction and retention funnel.\nNow is the right time to start taking the next steps. @GFXlabs, thanks for jumpstarting this conversation!\nI’m happy to support the first step and contribute to mapping the governable universe of Optimism, understanding where responsibilities currently sit, and identifying what is required to manage certain system elements properly.\n\n Good for everyone\n\n post by lavande on Sep 23, 2024\n\n lavande\n\nHi @LuukDAO - I wanted to let you know that the Foundation has drafted something very similar to what you/@ccerv1 describe above. This “decentralization milestones framework” is currently under review by the Collective Feedback Commission and we plan to publish it soon, after incorporating their input. I’d be happy to discuss about how we might collaborate on refining that framework and/or monitoring our progress towards different milestones, as that will be an important part of holding the Foundation accountable to this framework.\n\n post by LuukDAO on Sep 23, 2024\n\n LuukDAO\n\n Great! Glad to hear this is already in motion, and we’re eager to help refine and operate the framework.\nCan DM via forum or mail to op@superchain.eco\n\n post by cp0x on Sep 23, 2024\n\n cp0x\n\n Interesting proposal.\n\nDid @GFXlabs specifically set the end date until 2026? So that this voting would always be in progress?\nThe motivation for this proposal is clear to many, there are a lot of questions about management over a long period of time. In particular - disclosure of information - to whom and at what price were hundreds of millions of OP tokens sold and where are these funds now?\nVoting is a basic right and giving delegates the opportunity to speak out, including by initiating a vote - should be an inalienable right (with an adjustment for the presence of a certain number of OP tokens)\n\n post by GFXlabs on Sep 23, 2024\n\n GFXlabs\n\nIt’s a petition, not a proposal. All proposals must be approved by the Foundation, which should illustrate the need for this slate of reforms.\n\nWe agree, and the ability to push a proposal to a vote is one of the main points of contention where discussions broke down before presenting this plan publicly.\nThank you for the support!\n\n post by SEEDGov on Sep 24, 2024\n\n SEEDGov\n\n At SEEDGov, we appreciate that the conversation around the current state of governance in Optimism is being debated. Like everyone here, we value and believe it’s important for all voices in the Collective to engage in order to ensure that decisions and expectations are aligned with the ultimate goals of the protocol.\nFirst impression observed: we notice that the way this petition has been framed might not fully reflect or reference certain aspects of Optimism’s current vision -both from a technical and social perspective- which have been discussed in various instances. As we have shown support for Optimism’s current thesis, we wonder if this validation is shared by others.\nHere are our thoughts:\n“OP Token Contract Ownership”\n\nSince OP is the flagship asset of the Optimism ecosystem, the way it’s proposed to implement it across OP Chains might not fully account for some of its implications, as there’s currently no way to bridge OP without encountering certain pain points in order to obtain a usable representation early on. This is what we understand interop will eventually solve. On the other hand, we recognize that it may be perceived as an organizational oversight to have launched a grants program for OP Chains, considering this limitation would arise.\n“Governance Contract Ownership”\n\nWe believe this is a necessary step in the right direction. This topic has been discussed on previous occasions, highlighting the importance of implementing it appropriately. For example, the future governor should ideally include the Citizen House to ensure both houses operate in harmony and avoid one overtaking the other. In our view, there’s still much to explore in this broad design space. Therefore, forcing the governor to be controlled solely by the Token House might not be the most suitable approach under current expectations, in our opinion.\n“Governance Fund Ownership”\n\nWe believe this approach is reasonable, as governance is in a position to take greater control of its own funds, assume responsibility for its actions, and develop a relevant framework to consolidate its autonomy regarding its own expenditures.\n“Bridge L1 Escrow Comes Under Governance Control”\n\nUpon reviewing this, our main impression is that it’s essential to prioritize the protection of user rights and the security of funds from a technical perspective. The discussion on revenue opportunities for the Collective, beyond sequencing revenues (which remain unresolved), warrants deeper analysis considering the design of Superchain. It would be wise to take the necessary time to debate this, considering all implications, should part of the Collective be willing to follow this path. Ultimately, Optimism is a set of blockchains scaling Ethereum, and this neutrality has been a fundamental expectation emerging from the Ethereum community regarding how a Layer 2 is defined.\n“Sequencer Decentralization Roadmap”\n\nThis is a recurring topic in X circles and is part of many teams’ pursuit of the holy grail of solutions. However, we believe this point should be considered alongside the other technical improvements and new designs planned for the upcoming Superchain phase. This represents a significant shift for any rollup stack design. In our opinion, the Collective should eventually have the right to choose the entity behind the sequencer and be able to make the switch itself, under a voted framework.\n“Phase III (concluding Q2 2025)”\nWe are excited about the interest and desire for the technical decentralization of the Optimism Protocol in less than 12 months. However, from a realistic perspective, this is unlikely to happen, given the vision and goals of the Optimism Collective and their implications for implementation. Each previous phase involves numerous rounds of discussions, and it’s clear that consensus among all interested parties will happen with back and forth. On our part, we will actively participate in the discussions without the need to set a specific timeline if the current roadmap suggests a different appreciation.\nOther comments:\n\nCertainly, we believe that the current state of other ecosystems—considered competitors—should not be a reason to condition our decision-making models. Existing models are far from perfect, and particularly, the Optimism Collective has followed a markedly different process, with each iteration and restructuring over the seasons, making its process unique.\n\nIn line with Carl here, we believe the request adds a number of initiatives and substantial changes that may be unrealistic to achieve. It is more appropriate, and evidently clear, that asking delegates about their interest in advancing Optimism’s decentralization is one thing, while specific objectives, order, and timing are issues that should be addressed at a later stage. Keeping the latter as a separate draft would have been a better approach.\nOn a Final Note:\nTo GFXLabs, once again, we thank you for this push, as all these topics deserve to be discussed—from goals and design to implementation—something stakeholders should have the opportunity to provide their input on.\nTo the Foundation, we appreciate your time dedicated to responding extensively to this request, disclosing several of the future next steps to propose to governance. This attitude should be a common practice, and we hope the conversation about the future of Optimism will reach its peak of intensity by the end of Season 6.\nFor us, the most critical part is found right here: how to move forward with the decentralization discussion, split into its various parts, following what was described to be presented. For example, the next step mentioned by @lavande:\n\nThis step shouldn’t take long, as the Foundation is one of the main stewards of Optimism’s vision.\n\n post by Mon on Sep 24, 2024\n\n Mon\n\n the transfer of powers and resources to community governance is a bold step toward true decentralization, its success will depend heavily on the Governance ability to organize, govern effectively, and handle increased complexity. With proper safeguards, in place, this move could propel Optimism forward as a decentralized governance, planning and execution will be critical to ensure it strengthens rather than weakens the ecosystem.\n\n post by OPUser on Sep 24, 2024\n\n OPUser\n\n I’m not in favor of this proposal, as I believe that while it comes from a good place with positive intentions, it doesn’t address all the complexities involved.\n\nWe have a unique governance model, and we’ve achieved a lot in a short period of time. The two-pillar governance structure has been, and continues to be, an experiment that evolves with collective feedback. Each season brings challenges, but we consistently overcome them, emerging stronger on the other side.\nTo reframe the question: full decentralization may be necessary if people feel restricted, isolated, or censored in any way. However, at present, anyone can submit a proposal in this open forum. The grant distribution framework is transparent, algorithms are accessible, and anyone can become a delegate and contribute. In fact, you don’t even need to be a delegate to share your thoughts here.\nOurs is the only DAO with dedicated support from the protocol team, and at least in terms of headcount, the contact information for representatives of the OP Foundation is public. And this is coming out from soneone virtually unknown outside of this governance, from Jonas to Carl, they listen every single time.\nWe have various councils, with dedicated and motivated delegates working to ensure we remain unbiased and sustainable in the long term. This process is not controlled by the Foundation. We, the collective, are responsible for writing proposals, approving and distributing funds—all in a distributed and decentralized manner. The Foundation takes a backseat, while we lead the way.\n\nAdditionally, I don’t think we’re quite ready to take full control of the DAO. We haven’t yet onboarded other members of the superchain, which I believe will happen in the next season. Onboard them, their project, dev and community. DAO budget will run out one day, only way to make sure we are sustainable long term, RPGF is to flourish and support positive contributions is highly dependent on members of superchain . Issues like projects capturing grant tokens to increase their voting power, the concentration of power, conflicts of interest, and misalignment are still concerns, especially in this fast-moving space.\nThere are clearly many open questions and points of failure. Just because one DAO is doing something does not necessarily mean we should do it too, the current working model and end goal play an important role.\nWe are progressing towards a sustainable DAO that is run, controlled, and managed by the collective. We should continue on this path, taking cautious but deliberate steps and iterating based on feedback.\n\n post by Leuts on Sep 25, 2024\n\n Leuts\n\n Congratulations to GFXLabs for bringing up this topic, although these proposals can sometimes come across as combative as our industry values trust-minimization, the route to that goal often requires removing trust from even people who are of high-credibility. Thus friction can arise. Regardless, the conversation itself is extremely important and gauging community sentiment is always positive when done professionally.\nDecentralization and trust-minimization is a means to an end, not the end itself, and GFX clearly states that “While there was some early value in the Foundation and OP Labs having all system access powers, that time has passed as both the promised decentralization of power and the business strategy of Optimism have underperformed expectations.”\nI would be curious for GFX to provide comparisons on how more trust-minimized DAOs such as Arbitrum are performing in key categories against Optimism, including as mentioned above. Is the writing truly on the wall that Arbitrum is more successful? It would be great to try and compare? Others like Lido, Aave, Maker seem to be the darlings of DAOs but are of course not chains.\nI first think it’s extremely important to categorically separate control of permissions between the technology and money. It’s become evident over time that separate governance processes and bodies can perform more effectively apart. So far this hasn’t been achieved on a large scale in any DAO beyond a committee format. Thus I’d recommend one of 2 options: separating the phases and permissions by technology and money, i.e. removing the ETH collected temporarily. The progressive transfer of permissions is sensible.\nI believe there is a middle ground on the way to becoming fully trust-minimized and decentralized which is a newer governance primitive we are working on with Polygon and a few other rollups soon launching. More info can be found here and the PIP to activate this is now live here.\nIn short: the foundation and/or a council are the only ones to put a proposal onchain, but token holders have the ability to veto this change. This allows for a more streamlined governance process but puts hard-power in the hands of token holders. When these training wheels are ready to be taken off they can be more easily. It also places proper checks-and balances in the hands of token holders rather than the reverse methodology we often see when a committee or multisig, somewhere, has the hard power to block any proposal. The outcome = more efficiency with actual checks and balances.\nWhy we continue to launch the same broken and misaligned vanilla token-weighted delegate voting is beyond me. There are lots of safe ways to govern and OP has already showcased its governance leadership in RPGF.\nOverall, I am very are happy to see these amazing conversation happen for some of the most important projects in the industry and happy to help where and when necessary. Thank you!\n\n post by GFXlabs on Sep 25, 2024\n\n GFXlabs\n\nWe want to point out that this is not correct. Proposals are permissioned by the Foundation and also are subject to fitting within certain categories of approved proposal type.\nAlso, these two statements are contradictory:\n\nSuperchain members often receive substantial grants of OP tokens from the Foundation, and neither membership nor those initial grants is not subject to governance approval.\n\nThis would be a very long conversation in and of itself, but we would characterize Arbitrum as more nimble and energetic since it can capture bottom-up ideas quickly and act on them, but this does come at the cost of substantial waste in spending. Optimism would have the benefit of already having a structured governance system in place, while Arbitrum started largely from the primordial ooze and has had to evolve in real time.\n\nGFX’s time at Maker is one of the main drivers of the desire to decentralize while we can. Maker is as tightly controlled as any centralized company, and is a perfect example of why decentralization is needed.\nThank you to everyone who has commented so far. And if you’ve not yet done so, please signal your desire for accelerated decentralization on this Snapshot petition. \n\n post by Marcus01 on Sep 26, 2024\n\n Marcus01\n\n govNERD\n\n From Optimism Chinsese Community, we voted in favour of the petition, but that doesn’t mean we support the proposal, we would like to initiate some communication agenda about Token House and the Foundation\nWhat I think is bad about this proposal is\nDecentralised governance is a long and arduous process, which is full of many explorations, and we don’t think that accelerated decentralisation will give a big boost to the Optimism collective at this point in time, on the contrary, a lot of the work that the Optimism Foundation and Op labs have done, in terms of superchain scaling, upgrading of Op stacks, etc., is something that we think is very good, and some of the rights of the The lower part of the Council and the Anti-Capture Committee have given Token House some decision-making power.\nWhat we don’t think is good at the moment is\nOptimism Foundation’s long-term roadmap for decentralisation is not clear, we think the foundation needs to have some sort of long-term roadmap, including the process of transferring the governance fund contract, and the application scenarios of OP tokens (at present, there are no other application scenarios except governance).\nThrough this petition, we hope to suggest a cyclical dialogue where the Optimism Foundation can make some clearer governance roadmap based on community feedback.\n\n post by NathanVDH on Sep 26, 2024\n\n NathanVDH\n\n I’ve been inactive as a delegate for exactly the reasons quoted in this post. I couldn’t agree more and this has my full support. I’d be happy to start participating in governance again if this goes through.\n\n post by ml_sudo on Sep 26, 2024\n\n ml_sudo\n\n Wow, this is a big bold move by @GFXlabs and I fully respect it. It very clearly demands for progress on a few vital elements of the OP ecosytem in particular, and the crypto industry in general - otherwise, what are we here for?\nIt’s difficult for me to support the whole petition as it is currently written, for a few key reasons. I will try to be succinct because they mirror things that people like @katie @Gonna.eth @ccerv1 and others have voiced in this thread\n1. We need tight, war time organizations\nWhile we have been one of the leading ecosystems in recent history, I believe that we are still in “war time.” We are still fighting for long term relevance and dominance. In my experience (and according to business and military history), spreading decision-making out at this stage to a wide swath of people who aren’t necessarily full-time committed to a vision is overly risky. We need a war time organization, one that can move quickly and nimbly in the face of strategic and tactical challenges (credit: Ben Horowitz’s distinction between wartime and peacetime CEOs)\n2. Story time: an live anecdote to help us learn from other’s mistakes.\nI contribute to Synthetix like @MattGov.eth. Just yesterday, a referendum was proposed to bring back the original founding team to re-invigorate the protocol. If it passes, the 17 people sitting on 3 councils will be “fired,” and a new council will be formed, consisting of only 7 people (primarily OGs who founded the protocol). The team will also concentrate new hires in Sydney, a slight reversal of our fully remote/global operations.\nWhy did this happen? While Synthetix has always been “decentralization maxis,” it became clear that decentralizing code architecture is one thing, while decentralizing planning is another. With decentralized planning, we had too many actors, so accountability was tricky to pin on anyone. Decision-making lacked tightness, making it hard for partners to do business with us. As a result, despite having broken ground on defi with Optimism at the start of defi summer, we have been languishing for ~18 months now, with our competitive position and token price reflecting this state of affairs. I am proud to contribute to Synthetix, but this is a change that I welcome.\nIn line with some of the other comments on this thread, is there another way to blend your desire for greater governance participation together with these practical realities?\n\n post by AnthiasLabs on Sep 29, 2024\n\n AnthiasLabs\n\n Anthias Labs Optimism Governance Decentralization Risk Analysis - Token Contract Transfer\nAbstract\nIn response to GFX Labs’ recent post to accelerate Optimism Decentralization, Anthias Labs has conducted the following risk analysis to make clear the current state of OP governance attack risk. This analysis is not intended to endorse or reject GFX’s proposal but rather to share the state of risk objectively so that Optimism stakeholders may make the most informed decision on how to proceed.\nDisclaimer: Anthias Labs has signed GFX Labs’s Snapshot petition.\nPhase 1 - OP Token Ownership Analysis\nIn this initial analysis, we will focus primarily on transference of the OP token contract ownership as that is the first step proposed.\nThe following is an excerpt from what GFX Labs proposed above:\n“OP Token Contract Ownership\nUnlike some competitors (like Arbitrum), the OP token has no established rights to execute code, make proposals, share in revenue, or anything else.\nThis manifests itself as a lack of interest in OP as a governance token, making it a struggle to convince some users to delegate or vote. In some circles, OP is actually referred to as a meme coin, and not jokingly so.\nOf particular embarrassment is that the OP token does not even own its own contract. Transferring ownership of the token contract to governance is an essential first step in a credible plan to make the OP token serve its intended purpose of governing Optimism.\nPutting the token contract under onchain governance oversight also ensures that basic tasks will get done, like deploying standardized OP token contracts on Superchain member chains and a reliable, quick mint-burn bridge between those chains. This is of particular urgency with the Superchain grants program scheduled to dispense 12,000,000 OP tokens to member chains, but with no way to reliably get those tokens to those chains.”\nWhat does contract ownership mean?\nIt is defined here in the following Optimism contracts:\n1210×560 82 KB\nThe function transferOwnership is called to transfer the ownership of the contract from its current owner which is this address 0x5C4e7Ba1E219E47948e6e3F55019A647bA501005 to an address owned by the governance council.\nThe owner of the OP Token contract has rights to all the functions present in the contract as well as access to all the functions which have onlyOwner access. Below are some of those functions:\n1022×274 46.7 KB943×116 11.9 KB\nOnly the owner of the contract can renounce their ownership when they wish to, and only they can transfer their ownership to whomever they wish to and whenever they wish to.\nOnly the owner of the contract has the right to mint the governance tokens which is a restricted privilege. Transferring ownership requires just calling a function. But the risk of this transfer is a governance attack, which we will now provide some context around.\nWhat is the current state of OP token decentralization, and what risks might its current state pose or mitigate? This is what we will now explore.\nData on the OP Token and How this Data Connects with Governance Attack Risk\n1294×792 44.7 KB\nPlot 1 - Shows the total OP available for voting i.e currently delegated.\n1294×792 73.8 KB\nPlot 2 - Shows the total votable supply compared with the available supply.\nInferences from the above plots:\n\nThe votable supply is quite a small fraction of the available supply that peaked at 16.83% 2 years ago & has mostly stagnated since then.\nThough the total votable supply has been constantly increasing, the available supply has increased more quickly.\n\n1294×792 87.8 KB\nPlot 3 - Shows the total collective treasury of OP collective in USD.\nLet us look at how different delegates constitute the collective council, their distribution & the voting power they have.\n1294×792 69.5 KB\nPlot 4 - Number of recognized Delegates.\n1600×729 158 KB\nPlot 5 - Voting power available to different delegates.\n1294×792 122 KB\nPlot 6 - Distribution of Top 10 delegates with their voting power.\n1294×792 96.5 KB\nPlot 7 - Distribution of Top 10 delegates with the amount of OP they hold.\n1294×792 63.2 KB\nComparing OP with ARB data as a point of governance decentralization comparison\nThe above plot shows the number of delegates required to cross 50% of the voting power. This is an important parameter as it tells how decentralized & distributed the voting power actually is. The number of such delegates for OP lies in the range of 10-15 which is moderate. This number has a higher magnitude in the case of Arbitrum.\n1294×792 78.7 KB\nThis plot shows the ARB delegated for Top 50 delegates vs the other remaining delegates. We see that the Top 50 delegates are together needed to achieve 56% voting power. The top 240 delegates control two-thirds of the total voting power for Arbitrum DAO & around 15% of all the available ARB is being delegated compared to OP’s 9.8%.\nThe plot below shows the distribution of voting power among the Top 50 delegates for Arbitrum DAO. Hopefully, this plot serves as a point of reference between the two DAOs given this discussion to decentralize.\n1294×792 116 KB\nThe monetary costs of a governance attack over the OP ecosystem.\nCase 1: Attack takes place using the already delegated supply\nProcedure:\n\nWe take the total votable supply of the OP ecosystem.\nWe multiply the value by 0.51 to obtain the 51% voting supply.\nWe multiply the obtained voting supply with the historical market price of OP token to obtain the cost of executing a 51% attack on the ecosystem at various points in the past plotted as a curve.\nWe ignore dex slippage for the moment, considering the ideal cost. True cost would be actual cost added with dex slippage.\n\nCase 2: Attack takes place using the currently undelegated supply\nProcedure:\n\nWe take the total available supply of the OP ecosystem.\nRemaining steps are the same.\n\n588×450 28.7 KB\n588×450 27.7 KB\n588×450 28 KB609×450 29.8 KB\n1600×241 49 KB\nAbove is the fundamental equation for a governance attack. The only way to avoid a governance attack is to make the profit of the attacker negative. This can be done by one or more of the following:\n\nDecreasing the value of attack.\nIncreasing the cost of acquiring voting power.\nIncreasing the cost of executing an attack.\n\nTo be fully clear: What is a governance attack, and how can Optimism avoid them?\nA governance attack is when a malicious actor or a group of actors gain enough voting power to overthrow the existing governance structure of a DAO & cause a hostile takeover of the governance, taking the protocol into the direction they wish to for their personal benefits.\nBelow are two governance attacks with details on how exactly they occurred:\n\nBeanstalk: Beanstalk is a lending platform that allowed its governance contract to change the address of the owner of the collateral of the platform. It was attacked by an exploiter who transferred all of the collateral of the platform (estimated at just over 182M USD) to themselves, collapsing the platform as a result. The attack was issued by an individual who was able to take a flashloan of Beanstalk’s governance tokens and in doing so became a majority holder of governance tokens, allowing them to make dictatorship decisions in the governance contract. To overcome Beanstalk’s wait time safety feature, the attacker uploaded a seemingly innocent governance suggestion (donating funds to Ukraine) while hiding the actual functionality using Ethereum’s Diamond standard (which is a sophisticated version of the proxy mechanism). This is how the attack was not detected prior to the beginning of the voting period. The attacker also utilized the emegrantCommit() method to transfer to himself a sum that covered his flashloan, alongside over 180 M USD in profits from the attack.\n\nCompound DAO passes $24 million in alleged governance attack: Two months ago, a controversial proposal in front of the Compound Finance DAO narrowly passed, allocating 499,000 COMP (~$24 million, approximately 5% of the project’s treasury) to an outside group. The proposal was introduced by a Compound Finance whale known as “Humpy,” who pushed for the tokens to be granted to a protocol created by a group called the “Golden Boys,” which Humpy also leads. This marked the third attempt to secure funding for the Golden Boys, following two unsuccessful votes in May and earlier in July. Humpy had previously been accused of engaging in governance attacks on other protocols, including Balancer and SushiSwap. Before the proposal passed, some members of the Compound Finance DAO raised concerns. Compound Finance security adviser Michael Lewellen stated at the time, “In my personal opinion, the actions of Humpy and the Golden Boys can be considered a governance attack if they persist in their attempts to take funds from the protocol in clear opposition to the will of all other Compound DAO delegates.” Lewellen further described the proposal as “a malicious attempt to steal funds from the protocol.” After the proposal passed, Lewellen wrote that “OpenZeppelin is working with all active delegates and Compound contributors to assess our options for protecting the protocol. We see serious risks to the future decentralization of the DAO as a result of Proposal 289 passing, and we are exploring options to mitigate or reverse this outcome.” This event, now two months past, remains a significant moment in Compound Finance’s history, as it exposed vulnerabilities in decentralized governance and raised ongoing concerns about the control of protocol resources.\n\nConclusion\nRisk abounds in any decentralized system, but there are immense rewards to be had as well with decentralization, as GFX Labs outlines in their original post. OP stakeholders must weigh those risks and rewards in order to come to their own conclusions about the best path forward for the Optimism Collective. Additionally, there may be adjacent middle-ground solutions here that find the optimal value for the Collective. Our team at Anthias Labs will have more work here shared to the forum soon.\nLegal Disclaimer\nAnthias LLC (D.B.A. Anthias Labs) does not provide financial advice. Any information accepted here is accepted on the behest of the protocol/DAO team. Anthias Labs is not permitted to give financial advice, and nothing in this documentation should be considered as such. Anthias LLC (D.B.A. Anthias Labs) will not be held liable for any economic or otherwise monetary loss brought about by statements made in this document. This is not financial advice, and any third party reading this document should do its own research into any statement made.\n\n Looking Ahead: Long-term Onchain Governance Architecture\n\n post by system on Sep 30, 2024\n\n system\n\n Hi everyone, it’s great to see this conversation happening on the forum. We wanted to give an update on the other conversations that have been happening throughout the Collective on this topic:\n\nThe Foundation has received feedback on a framework for decentralization milestones from the Collective Feedback Commission and joined a call to discuss it with members in more detail last week.\nThe Foundation discussed this petition on the Token House community call last week.\nThe Foundation joined a call with the Anticapture Commission to discuss this petition and some of the potential roles the ACC might play in regards to this conversation.\n\nTo reiterate, we remain fully committed to full decentralization, using the initial approach and timeline outlined in the Working Constitution, and will continue to have ongoing conversations about this path with the community. We understand that governance participants want more transparency around the path towards decentralization and regular opportunities to hold the Foundation accountable to making progress on this path and we are supportive of both.\nImmediate next steps on our side:\n\nIncorporate CFC feedback on our framework for decentralization milestones and publish (along with other resources) for broader community feedback. We are targeting early Voting Cycle #29 for this.\n\nTo address specific aspects of the Phase 1 suggested in the above petition:\n\nThe Token Contract is already owned by governance. A concrete example of the process to upgrade the token contract will occur as part of the upcoming interop upgrade.\nAgora plans to post a governor upgrade proposal that would transfer keys to the Security Council and move the full governance contract onchain to be voted on in Voting Cycle #29.\nThe conversation about sequencer ETH remains ongoing, but should include Citizens, as sequencer ETH defaults to Citizen management (it goes to Retro Funding), as outlined here.\n\nThe Foundation recommends we focus on completing the above milestones and revisit the path forward from there. We expect many OP Chain delegates to begin participating in governance between now and 1Q25 and it’s important that their perspectives be represented in this conversation. The same goes for Citizens, as they play a critical role in protecting the long term interests of the Collective. This is foundational to our bicameral design but absent in the process around this petition.\nWe expect this conversation to be ongoing throughout this iterative process. As several people have highlighted above, many projects have decentralized quickly only to realize that they hadn’t laid the foundations to support that decentralization properly, and then resorted to re-centralization. We believe we can avoid this pattern by taking the time to lay the foundation that can support full decentralization for the long term.\n\n post by ACC on Oct 2, 2024\n\n ACC\n\n ACC’s Statement on the Proposal for Accelerated Decentralization for Optimism\nOn 26th September 2024, the Anticapture Commission (ACC) held an Internal Meeting where one of the key agenda items was the discussion on the Petition for Accelerated Decentralization for Optimism. Along with the Delegate members of the ACC, we also invited GFX Lab’s PaperImperium and members of the Foundation to discuss the petition.\nThere was wide agreement among all parties that the proposal represented a step in the right direction, in pushing for the decentralization of key components of Optimism. The issues raised in the proposal were well received, and have ignited a healthy conversation within the Optimism community on our path towards decentralization. Delegates stressed a need for moving towards decentralization by ceding more power to token holders and delegates. The Foundation reaffirmed their full commitment to decentralizing the protocol and working with the community to iron out a more granular path forward. The Foundation will publish concrete proposals, which are already in audit, in the coming weeks as part of Phase 1 of the path towards decentralization. Recently, the development process has been opened up to a good extent with public specs published in repositories. This has enabled external groups, beyond OP Labs and the Foundation, to contribute to the OP Stack development process. External teams like Flashbots, are now able to propose features related to the OP Stack, and have the designs reviewed and merged into the codebase.\nThe ACC members discussed with Foundation that there are concrete proposals for decentralization coming up in the next few Voting Cycles and gradually but surely, more control is being ceded to governance in a progressive manner. To this effect, the Petition for Accelerated Decentralization felt like a timing issue while we are all on the same path towards decentralization. As per the bicameral nature of Optimism’s Governance, one of the main mandates of the ACC is to alert the Citizen’s House if there is a possibility of capture in the Token House. However, the Citizens are not involved in this conversation that is currently before the Token House. To this effect, the ACC will seek to facilitate the role or voice of Citizens in this discussion such as creating standards for signaling proposals.\nConsidering the Charter of the ACC, the members were in agreement that at this stage, the ACC will not vote directly on the Snapshot proposal with the voting weight delegated to the ACC multisig. There however, is no restriction on individual delegates who are part of the ACC in signaling their opinion on the proposal.\n\n The Future of the Anticapture Commission\n\n Anticapture Commission Communication Thread\n\n 10 days later\n\n post by LXDAO on Oct 12, 2024\n\n LXDAO\n\n This petition has garnered significant attention within our community (LXDAO, a research and development-focused community with conscience as its core value).\nIt has sparked many reflections, such as:\n\nTo what extent can a commercial organization decentralize?\nHow can we determine if a community is mature enough to assume full governance responsibility?\nWhat is the standard for balancing technical implementation and governance decisions?\n\nFrom the perspective of merging business operations with community governance, Optimism serves as an excellent model. We believe this provides not only practical experience for OP’s governance but also valuable inspiration for other Web3 projects.\nHowever, this raises another issue: is it necessary for a commercial organization to fully decentralize? Or rather, to what extent can meaningful decentralization be achieved?\nFor a commercial organization, decentralization is not always necessary, and at certain stages, it may not even be an effective governance approach. The goal of decentralization is to distribute power, enhance transparency, and increase community participation, but it must be balanced with practical operational needs. In some decision-making processes, a degree of centralization is required to maintain efficiency and ensure accuracy, particularly when it comes to responding swiftly to market changes.\nAt the same time, we also observe the significant efforts the Optimism Foundation has made to expand “decentralized governance,” leveraging collective wisdom to accelerate operations, prevent abuse of power, while maintaining necessary flexibility and efficiency.\nAs for the goal of full decentralization, we are uncertain if it is achievable. However, we are pleased to see the community actively proposing such petitions, as they promote closer integration between the Optimism Foundation and the community, creating more possibilities for governance models.\nThis not only fosters further decentralization within Optimism but also raises important questions about how to mature a community to take on more governance responsibilities or how to objectively assess what level of governance a community can handle.\nOn this issue, it’s not only the Optimism Foundation that may need a “decentralization timeline,” but the community itself may also need to form various specialized working groups in stages to ensure governance safety and accuracy. For example, in the management of funds, it might be feasible to establish co-governance teams between the community and the foundation, allowing the community to undertake governance in a protected environment, which could accelerate the community’s maturity.\nThroughout this process, transparency and mutual oversight could ensure that the Foundation maintains or even accelerates the “decentralization process,” while also enabling the community to become more robust and secure.\nThe Optimism Foundation has conducted multiple decentralization experiments over time. The data and results from these processes offer valuable insights for the development of Web3. For this, we express our respect for the Foundation’s contributions to decentralized governance and are pleased to see the Optimism community remain active. As more discussions unfold, we believe that an ideal balance between business models and decentralization principles can be achieved.\n\n post by alexsotodigital on Oct 13, 2024\n\n alexsotodigital\n\n govNERD\n\n Hi! \nAfter reading this thread, I realize that concrete actions are already being taken to follow up on the various proposals that have been presented. Wanting to avoid repeating what more capable people have already expressed, I’ll set the topic of ‘decentralization’ aside; understanding that we are all aligned with the intention, and it’s just the details of the implementation that differ.\n\nAnd yet, I believe this conversation has highlighted a different topic: revenue opportunities for the Collective, beyond sequencing revenues.\n\nEspecially if we consider that the trend is for that revenue source to decrease over time.\n\nAnd I believe that coming up with possible solutions is a responsibility of the collective rather than the foundation.\n\nIn other words, if we continue with the analogy of parenthood, I’d say we need to demonstrate our maturity and capability by taking proactive steps in this matter, rather than waiting for someone else to solve it in the future.\nWhat do we do about it?\nFor the sake of order, I suggest opening a new thread to focus on ‘revenue opportunities’ without diverting this one from its initial focus (which is the pace at which we should decentralize operations). I’m not aware if there are other conversations about this, but at least it wasn’t evident to me when searching the forum.\nI leave this post here, inviting anyone who wants to participate in a 'Collective Proposal Creation’ to brainstorm and synthesize some paths to address this concern. \nI hope my suggestion is appropriate. Thank you in advance for your comments in the thread. \n\n post by lavande on Oct 16, 2024\n\n lavande\n\n Hi all! Related to the topic above, we’ve just published a post outlining two working models for decentralization. There is a lot of information in here but we’ve linked to video walk throughs of each model and the Foundation will also host an AMA on Thursday to answer questions (check the public governance calendar!)\n\n 2 years later\n\n post by lvhllc904 on Aug 25\n\n lvhllc904\n\n jacq\n\n Deleted, my apologies, I replied to the wrong the wrong post… I’m new \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved\n\n Metagovernance\n\n Optimism is experiencing rapid growth, but this is a double-edged sword. Currently, Optimism is a centrally operated network where, as far as I’m aware, unknown entities across Optimism Foundation, OP Labs or associates …\n\n read more\n\n 26\n\n 5.5k\n\n Dec 2022\n\n [DRAFT] [GF: META] Proposal to reserve a share of GF distribution for liquidity backstopping and stronger governance\n\n Technical Proposals\n\n The Commons: shoring up OP’s liquidity, governance, and funding capacity\nHi, I’m Jack from Velodrome, a leading Optimism dex that recently received a 3mm OP grant from OP Labs, a close collaborator in the build of our pr…\n\n read more\n\n 77\n\n 7.6k\n\n Dec 2022\n\n Polynya - Delegate Communication Thread\n\n Delegate Updates\n\n I have finished my votes for Gov Fund Phase 1 Season 1. \nMy general impression thus far is that most proposals are a mixed bag, with very few high-quality projects I’d be excited to support without reservations. Since Op…\n\n read more\n\n 44\n\n 6.8k\n\n Jan 26\n\n ScaleWeb3 - Delegate Communication Thread\n\n Delegate Updates\n\n This thread is intended to provide an insight to ScaleWeb3, a record of ScaleWeb3’s voting, reasoning for each vote and a collection of important comments across the Optimism forum & proposals. \nName: ScaleWeb3 \nDelegate…\n\n read more\n\n 27\n\n 5.5k\n\n May 2024\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024","tokens":11072,"squid":"ink-governance","role":"Council Listener","at":1791260225269,"hash":"ec5aab38124471edfc25e3bf0b4a3e0cceeef600"}
{"url":"https://ethereum.org/developers/tutorials/","domain":"ethereum.org","title":"Ethereum Development Tutorials | ⁦ethereum.org⁩","text":"TopicsAvailable tutorialsOraclesIntermediateBuidlGuidl •July 21, 2026 •60 min •ExternalBuild three oracle architectures in Solidity (whitelist, staking, and optimistic) with dispute resolution and economic incentives. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontendoracles (opens in a new tab)Over-Collateralized LendingIntermediateBuidlGuidl •July 21, 2026 •60 min •ExternalBuild an over-collateralized lending protocol in Solidity with liquidations and flash loans. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontenddefi (opens in a new tab)StablecoinsAdvancedBuidlGuidl •July 21, 2026 •90 min •ExternalBuild an algorithmic stablecoin in Solidity with collateralization, liquidations, and incentives that maintain the peg. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontenddefierc-20 (opens in a new tab)Prediction MarketsAdvancedBuidlGuidl •July 21, 2026 •90 min •ExternalBuild a decentralized prediction market in Solidity, from market creation and betting to oracle-based outcome resolution. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontenddefioracleserc-20 (opens in a new tab)ZK VotingAdvancedBuidlGuidl •July 21, 2026 •90 min •ExternalBuild a privacy-preserving voting dApp in Solidity and Noir, using zero-knowledge proofs, Merkle trees, and nullifiers. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontendprivacycryptography (opens in a new tab)Tricks of the job interview scamBeginnerOri Pomerantz •May 27, 2026 •10 min •ExternalLearn how scammers target developers with fake job offers that include malicious repositories. Covers real-world attack techniques like remote code execution, environment variable exfiltration, VS Code task abuse, and defenses such as cloud sandboxes and AI-assisted code review.securityjavascriptscamdeveloper (opens in a new tab)Add clear signing to your protocol with ERC-7730IntermediateHester Bruikman •May 10, 2026 •7 minLearn how to write an ERC-7730 descriptor so your smart contract interactions display human-readable details in wallets before users sign.erc-7730securitysigningsmart contractswalletsSponsoring gas fees: How to cover transaction costs for your usersIntermediateOri Pomerantz •February 26, 2026 •10 minIt is easy to create a private key and an address; it's just a matter of running the right software. But there are many places in the world where getting the ETH to send transactions is much harder. In this tutorial you learn how to cover the onchain gas costs for executing user-signed, offchain structured data in your smart contract. You have the user sign a structure containing the transaction information, which your offchain code then submits to the blockchain as a transaction.gaslesssolidityeip-712meta-transactionsMake your own AI trading agent on EthereumIntermediateOri Pomerantz •February 12, 2026 •24 minIn this tutorial you learn how to make a simple AI trading agent. This agent reads information from the blockchain, asks an LLM for a recommendation based on that information, performs the trade the LLM recommends, and then waits and repeats.aitradingagentpythonUsing Stealth AddressesIntermediateOri Pomerantz •November 29, 2025 •15 minStealth addresses allow users to transfer assets anonymously. After reading this article, you will be able to: Explain what stealth addresses are and how they work, understand how to use stealth addresses in a way that preserves anonymity, and write a web-based application that uses stealth addresses.stealth addressprivacycryptographyrustwasmWrite an app-specific plasma that preserves privacyAdvancedOri Pomerantz •October 14, 2025 •32 minIn this tutorial, we build a semi-secret bank for deposits. The bank is a centralized component; it knows each user's balance. However, this information is not stored onchain. Instead, the bank posts a hash of the state. Every time a transaction occurs, the bank posts the new hash, along with a zero-knowledge proof that it has a signed transaction that changes the hash state to the new one. After reading this tutorial, you will understand not just how to use zero-knowledge proofs, but also why you use them and how to do so securely.zero-knowledgeserveroffchainprivacyBuilding your first dApp with dAppBoosterBeginnerBootNode •June 27, 2025 •15 min •ExternalGetting started with dAppBooster in just a few lines of code.dappvitetypescriptweb3reactfrontendjavascriptdappboosterbeginner (opens in a new tab)Using subgraphs with dAppBoosterIntermediateBootNode •May 26, 2025 •30 min •ExternalThis guide will walk you through the use of the subgraphs plugin in dAppBooster.subgraphdappvitetypescriptweb3reactwagmifrontendjavascriptdappbooster (opens in a new tab)Prevent UI Spoofing: Simulating Ethereum Transactions with Foundry & PythonAdvancedValentina Rivas •May 9, 2025 •50 min •ExternalSimulate transactions on a local fork to verify on-chain behavior and catch UI spoofing.securitysmart contractsfoundrytestingpythonerc-20 (opens in a new tab)Detect UI Spoofing Attacks: Decoding Ethereum Calldata with PythonIntermediateValentina Rivas •May 7, 2025 •15 min •ExternalLearn to decode Ethereum calldata to detect malicious transactions before signing.securitysmart contractspythontransactionserc-20 (opens in a new tab)Using Ethereum for web2 authenticationBeginnerOri Pomerantz •April 29, 2025 •20 minAfter reading this tutorial, a developer will be able to integrate Ethereum login (web3) with SAML login, a standard used in web2 to provide single sign-on and other related services. This allows access to web2 resources to be authenticated through Ethereum signatures, with the user attributes coming from attestations.web2authenticationeasUsing zero-knowledge for a secret stateAdvancedOri Pomerantz •March 14, 2025 •28 minonchain games are limited because they cannot keep any hidden information. After reading this tutorial, a reader will be able to combine zero-knowledge proofs and server components to create verifiable games with a secret state, offchain, component. The technique to do this will be demonstrated by creating a minesweeper game.serveroffchaincentralizedzero-knowledgezokratesmudprivacyRemix vs Truffle vs Hardhat vs FoundryIntermediateThomas Wiesner •November 7, 2024 •60 min •ExternalA mini-course developing a set of smart contracts with Remix, Truffle, Hardhat, and Foundry to demonstrate what each framework offers developers.remixtrufflehardhatfoundry (opens in a new tab)Server components and agents for web3 appsBeginnerOri Pomerantz •July 14, 2024 •8 minAfter reading this tutorial, you will be able to write TypeScript servers that listen to events on a blockchain and respond accordingly with their own transactions. This will enable you to write centralized applications (because the server is a point of failure), but can interact with web3 entities. The same techniques can also be used to write an agent that responds to onchain events without a human in the loop.agentserveroffchaindappsIPFS for decentralized user interfacesBeginnerOri Pomerantz •June 28, 2024 •4 minThis tutorial teaches the reader how to use IPFS to store the user interface for a dapp. Although the application's data and business logic are decentralized, without a censorship resistant user interface users might lose access to it anyway.ipfsdappsfrontendWhat is EIP-4844? Proto-Danksharding and blob transactions explainedIntermediatePatrick Collins •May 29, 2024 •11 min •ExternalWhat is the EIP-4844? Learn what proto-danksharding and blobs are, how they work, and how to send your first blob transaction using the new Ethereum improvement proposallayer 2 (opens in a new tab)What is EIP-4844? | Blobs & Proto-dankshardingIntermediatePatrick Collins •May 29, 2024 •10 min •ExternalWhat is EIP-4844? What are blob-carrying transactions?layer 2 (opens in a new tab)TokenizationBeginnerAustin Griffith •April 24, 2024 •10 min •ExternalBuild, mint, and transfer your own ERC721. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagminftjavascripttypescriptopenzeppelin (opens in a new tab)Decentralized Staking AppBeginnerAustin Griffith •April 24, 2024 •30 min •ExternalBuild, test, and deploy your own decentralized staking app. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontend (opens in a new tab)Token VendorBeginnerAustin Griffith •April 24, 2024 •30 min •ExternalBuild a vending machine to buy and sell your own ERC20. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontenderc-20openzeppelin (opens in a new tab)Dice GameBeginnerAustin Griffith •April 24, 2024 •25 min •ExternalDeploy a contract to attack a DiceGame contract and predict the randomness so you only roll winners. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontendopenzeppelin (opens in a new tab)Build a DEXIntermediateAustin Griffith •April 24, 2024 •60 min •ExternalDeploy a decentralized exchange to swap an ERC20 and ETH. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontenderc-20openzeppelin (opens in a new tab)Multisig walletIntermediateAustin Griffith •April 24, 2024 •90 min •ExternalDeploy a multi-signature wallet where enough signatures are required to execute a transaction. A Speedrun Ethereum challenge.soliditysmart contractsreactnextjswagmijavascripttypescriptfrontendopenzeppelinsigning (opens in a new tab)Foundry FundamentalsIntermediateCyfrin Updraft •February 28, 2024 •600 min •ExternalThis course will level up your Solidity development skills with Foundry. The Foundry Fundamentals course teaches advanced web3 development concepts and tools. Expand your knowledge of Solidity, ERC-20s, DeFi, and Ethereum. Master Foundry Forge and Anvil while learning about Chainlink blockchain oracles, smart contract testing, and local network deployment.updraftvideofoundrysoliditysmart contractsfuzzingopenzeppelinerc-20block explorerdefitestingoraclesstoragedeployingevmjavascriptlayer 2mockingnodestransactionsalchemy (opens in a new tab)Solidity Smart Contract DevelopmentBeginnerCyfrin Updraft •February 28, 2024 •300 min •ExternalThis course will give you a full introduction to Solidity Programming, your gateway to web3 development in Ethereum compatible ecosystems. You'll learn all the core concepts to start building Solidity smart contracts. Including: ERC-20, oracles, inheritance, memeory, storage, mapping, functions, Chainlink, ZKsync, and more! This Solidity programming course has already helped thousands of developers kickstart their blockchain careers.updraftvideoevmsmart contractssolidityremixoraclesstoragedeployingtestingoffchainerc-20testingethers.jshardhatremixtransactions (opens in a new tab)Learn Smart Contract Auditing, Security, and DeFiAdvancedCyfrin Updraft •December 13, 2023 •1320 min •ExternalThe ultimate web3 security course for all those looking to be top smart contract developer or security researchers. We teach you all the cutting edge skills needed to make web3 safer and start a successful career in web3 security.updraftsoliditysmart contractsvideooraclesfoundrydefifuzzing (opens in a new tab)Building a user interface for your contractBeginnerOri Pomerantz •October 31, 2023 •18 minUsing modern components such as TypeScript, React, Vite, and Wagmi, we will go over a modern, but minimal, user interface and learn how to connect a wallet to the user interface, call a smart contract to read information, send a transaction to a smart contract, and monitor events from a smart contract to identify changes.typescriptreactvitewagmifrontendSome tricks used by scam tokens and how to detect themIntermediateOri Pomerantz •September 14, 2023 •15 minIn this tutorial we dissect a scam token to see some of the tricks that scammers play, how they implement them, and how we can detect them.scamsolidityerc-20javascripttypescriptHow to Get Transaction History for an Address on EthereumBeginnerAlchemy •July 1, 2023 •10 min •ExternalLearn how to get the full transaction history for a smart contract or a user address including external, internal, token, ERC-20, ERC-721 and ERC-1155 token transfers in a single request.alchemyquerying (opens in a new tab)Formal Verification & Symbolic ExecutionIntermediatePatrick Collins •April 25, 2023 •10 min •ExternalWe look at formal verification & symbolic execution with two Trail of Bits Web3 security team members. Additionally, we review the value these techniques bring and compare them to other tools.security (opens in a new tab)Fuzzing & Invariant Testing IntroductionBeginnerPatrick Collins •April 13, 2023 •9 min •ExternalWhat is fuzz testing? What are invariant tests? We introduce how to use these tools in Web3 & Solidity and explain why they are essential, especially for security. security (opens in a new tab)How to develop and test a dApp on a local, multi-client testnetIntermediateTedi Mitiku •April 10, 2023 •11 minThis guide will first walk you through how to instantiate and configure a multi-client local Ethereum testnet before using the testnet to deploy & test a dApp.clientsnodessmart contractscomposabilityconsensus layerexecution layertestingWhat is a Smart Contract AuditBeginnerPatrick Collins •April 6, 2023 •5 min •ExternalSmart Contract Auditing | What it is, what to expect, and where to look for one. Everything you need to know!security (opens in a new tab)Build an escrow contract with Solidity and ReplitBeginnerreplit •March 24, 2023 •20 min •ExternalLearn how to build a simple escrow smart contract, which will include deploying your own non-fungible token (NFT) and learning more about Solidity on Ethereum.soliditysmart contractserc-721 (opens in a new tab)Build a robot NFT with Solidity and Replit (part 1)Beginnerreplit •March 24, 2023 •20 min •ExternalLearn how to create a simple generative art NFT, ReplBots, with part 1 focusing on the smart contract deployment.soliditysmart contractserc-721nft (opens in a new tab)Build a robot NFT with Solidity and Replit (part 2)Beginnerreplit •March 24, 2023 •15 min •ExternalContinues from part 1 where you can learn how to create a frontend interface for your NFT application.javascriptfrontend (opens in a new tab)Build a smart contract oracle with Solidity, Node.js, and ReplitBeginnerreplit •March 24, 2023 •30 min •ExternalLearn how to use oracles in smart contracts and how oracles work internally, and gain experience with hybrid on-and-offchain systems.solidityoraclesjavascript (opens in a new tab)devpill.meBeginnerdcbuilder •March 22, 2023NaN •Externaldevpill.me is a public good blockchain development guide aimed at becoming the go-to learning resource aggregator for building on Ethereum and its wider ecosystem of scaling solutions and applications.frontendbackendsmart contractssolidity (opens in a new tab)Learn EVM Opcodes SeriesBeginnerEngin YILMAZ @veridelisi •March 8, 2023NaN •ExternalWelcome to the comprehensive series on understanding Ethereum Virtual Machine (EVM) Opcodesopcodesfoundrysmart contractssolidityyulstorage (opens in a new tab)EIP-1271: Signing and Verifying Smart Contract SignaturesIntermediateNathan H. Leung •January 11, 2023 •6 minAn overview of smart contract signature generation and verification with EIP-1271. We also walk through the EIP-1271 implementation used in Safe (previously Gnosis Safe) to provide a concrete example for smart contract developers to build on.eip-1271smart contractsverifyingsigningIssuing And Verifying Ethereum DIDs with MetamaskIntermediateAw Kai Shin •November 10, 2022 •9 min •ExternalAn initial explainer on how decentralized identity worksidentity (opens in a new tab)All you can cacheIntermediateOri Pomerantz •September 14, 2022 •23 minLearn how to create and use a caching contract for cheaper rollup transactionslayer 2cachingstoragescalingERC-20 with Safety RailsBeginnerOri Pomerantz •August 14, 2022 •8 minHow to help people avoid silly mistakeserc-20Run an Ethereum node on Raspeberry Pi 4IntermediateEthereumOnArm •June 9, 2022 •8 minFlash your Raspberry Pi 4, plug in an ethernet cable, connect the SSD disk and power up the device to turn the Raspberry Pi 4 into a full Ethereum node + validatorclientsexecution layerconsensus layernodesUnderstanding the Yellow Paper's EVM SpecificationsIntermediateqbzzt •May 14, 2022 •19 minUnderstanding the part of the Yellow Paper, the formal specifications for Ethereum, that explains the Ethereum virtual machine (EVM).evmHow to develop an NFT Smart Contract (ERC721) with AlchemyBeginnerVitto Rivabella •May 1, 2022 •48 min •ExternalA tutorial showing how to develop your first NFT smart contract quickly using OpenZeppelin, Remix, Alchemy, and Opensea. The first lesson of Road to Web3, a series of community-focused weekly Web3 development projects!solidityremixethers.jssmart contractsopenzeppelinalchemyvideonfterc-721alchemyblock explorer (opens in a new tab)Short ABIs for Calldata OptimizationIntermediateOri Pomerantz •March 31, 2022 •14 minOptimizing smart contracts for Optimistic Rollupslayer 2Optimism standard bridge contract walkthroughIntermediateOri Pomerantz •March 29, 2022 •33 minHow does the standard bridge for Optimism work? Why does it work this way?soliditybridgelayer 2Introduction to FoundryBeginnerPatrick Collins •March 28, 2022 •19 min •ExternalWe build a minimal Foundry project using a staking application to show you how to work with Foundry.solidityfoundryvideo (opens in a new tab)How to build an on-chain DAOBeginnerPatrick Collins •March 4, 2022 •86 min •ExternalUsing Compound and Openzeppelin as a basis, we build a 100% onchain DAO using an ERC20 governance token for votes.soliditytypescripthardhatdefidaovideo (opens in a new tab)How to build an on-chain DAOBeginnerPatrick Collins •February 24, 2022 •6 min •ExternalUsing Compound and Openzeppelin as a basis, we build a 100% onchain DAO using an ERC20 governance token for votes.soliditytypescripthardhatdefidao (opens in a new tab)How to Connect your Smart Contracts to MetamaskBeginnerPatrick Collins •February 11, 2022 •70 min •ExternalWe learn exactly how web3 / blockchain / smart contract applications work in the front end using HTML and Javascript. We then go through 6 different ways you can connect your Metamask, Phantom, or other blockchain wallet address to your front end. We’ll look at popular Nextjs / React packages to make your development lifecycle 100 times easier.solidityjavascripthardhatnextjsmoralisethers.jsvideo (opens in a new tab)Full Stack Web3 — Everything You Need to KnowBeginnerPatrick Collins •February 7, 2022 •14 min •ExternalWe learn exactly how web3 / blockchain / smart contract applications work in the front end using HTML and Javascript. We then go through 6 different ways you can connect your Metamask, Phantom, or other blockchain wallet address to your front end. We’ll look at popular Nextjs / React packages to make your development lifecycle 100 times easier. solidityjavascripthardhatnextjsmoralisethers.js (opens in a new tab)Merkle proofs for offline data integrityAdvancedOri Pomerantz •December 29, 2021 •10 minEnsuring data integrity onchain for data that is stored, mostly, offchainstorageReverse Engineering a ContractAdvancedOri Pomerantz •December 29, 2021 •32 minHow to understand a contract when you don't have the source codeevmopcodesEvents and Logging in SolidityBeginnerPatrick Collins •November 25, 2021 •5 min •ExternalLearn all about solidity events and logging, with hardhat and brownie examples! With video example: https://www.youtube.com/watch?v=KDYJC85eS5Msolidityeventshardhatbrowniesmart contractsjavascriptpython (opens in a new tab)How to become a blockchain engineerBeginnerPatrick Collins •November 8, 2021 •12 min •ExternalWe explore the steps one needs to take to enter the world as a blockchain developer and engineer. We talk about how to get there.solidity (opens in a new tab)Hello World Smart Contract for Beginners - FullstackBeginnernstrike2 •October 24, 2021 •45 minIntroductory tutorial on writing and deploying a simple smart contract on Ethereum.solidityhardhatalchemysmart contractsdeployingblock explorerfrontendtransactionsframeworkWhat is Multicall?IntermediatePatrick Collins •October 14, 2021 •15 min •ExternalLearn how to make multiple API calls to a blockchain node with a single API call to a multicall contract.brownieweb3.pyvideopython (opens in a new tab)NFT Minter TutorialIntermediatesmudgil •October 5, 2021 •28 minIn this tutorial, you’ll build an NFT minter and learn how to create a full stack dapp by connecting your smart contract to a React frontend using MetaMask and Web3 tools.soliditynftalchemysmart contractsfrontendpinataerc-721Solidity, Blockchain, and Smart Contract CourseBeginnerPatrick Collins •September 9, 2021 •960 min •ExternalThis course will give you a full introduction into all of the core concepts in blockchain, smart contracts, solidity, NFTs/ERC721s, ERC20s, Coding Decentralized Finance (DeFi), python and solidity, Chainlink, Ethereum, upgradable smart contracts, and full stack blockchain development. soliditybrownieweb3.pysmart contractsreactvideostorageoraclesnfterc-20pythonmockingtestingganache (opens in a new tab)How to make NFT Art with On-Chain MetadataBeginnerPatrick Collins •September 3, 2021 •180 min •ExternalExplore the world of using SVGs to generate random NFT ImageURIs and Metadata 100% onchain.solidityethers.jshardhatnftsmart contractsjavascriptvideo (opens in a new tab)The Complete Guide to Full Stack Ethereum DevelopmentBeginnerNader Dabit •August 25, 2021 •18 min •ExternalBuilding Full Stack dapps with React, Ethers.js, Solidity, and Hardhatsolidityhardhatethers.jssmart contractsreact (opens in a new tab)Leveraged Trading in DeFiBeginnerPatrick Collins •June 29, 2021 •34 min •ExternalLeveraged trading is a common strategy in traditional finance, and leveraged trades are even easier to do in DeFisolidityweb3.pybrowniedefismart contractspythonvideo (opens in a new tab)How to Set Up Tellor as your OracleBeginnerTellor •June 28, 2021 •2 minA guide to get started with integrating the Tellor oracle into your protocolsoliditysmart contractsoraclesHardhat's tutorial for beginnersBeginnerHardhat •June 22, 2021NaN •ExternalHardhat's beginners guide to Ethereum contracts and dapp developmenthardhatsoliditytestingsmart contracts (opens in a new tab)Aave Flash Loan TutorialIntermediatePatrick Collins •May 24, 2021 •30 min •ExternalAll about upgradable smart contracts, proxies, and using delegatecall in your solidity.solidityweb3.pybrowniesmart contractspythonopenzeppelinproxiesvideo (opens in a new tab)Create your own Blockchain ERC20 TokenBeginnerPatrick Collins •May 24, 2021 •30 min •ExternalDeploy your smart contract to Opensea, end-to-end.solidityweb3.pybrowniesmart contractspythonopenzeppelinerc-20video (opens in a new tab)Learn Foundational Ethereum Topics with SQLBeginnerPaul Apivat •May 10, 2021 •8 minThis tutorial helps readers understand fundamental Ethereum concepts including transactions, blocks and gas by querying onchain data with Structured Query Language (SQL).sqlqueryingtransactionsdata-and-analyticsNFT/ERC-721/Collectible END-TO-END TUTORIAL | Deploy, List on Opensea, Host Metadata on IPFSBeginnerPatrick Collins •May 9, 2021 •17 min •ExternalBuild your own ERC20 token using Brownie, Python, and Solidity.solidityweb3.pybrowniesmart contractspythonopenzeppelinvideo (opens in a new tab)Uniswap-v2 Contract Walk-ThroughIntermediateOri Pomerantz •April 30, 2021 •60 minHow does the Uniswap-v2 contract work? Why is it written that way?soliditydappsUpgrading your Smart Contracts | A Tutorial & IntroductionIntermediatePatrick Collins •April 25, 2021 •17 min •ExternalLearn how to make contracts that use flash loans. Using Brownie, Solidity, Aave.solidityweb3.pybrowniesmart contractspythonvideodefi (opens in a new tab)How to Mint an NFT (Part 2/3 of NFT Tutorial Series)BeginnerSumi Mudgil •April 21, 2021 •9 minThis tutorial describes how to mint an NFT on the Ethereum blockchain using our smart contract and Web3.erc-721alchemysoliditysmart contractsHow to View Your NFT in Your Wallet (Part 3/3 of NFT Tutorial Series)BeginnerSumi Mudgil •April 21, 2021 •2 minThis tutorial describes how to view an existing NFT on MetaMask!erc-721alchemysolidityHow to Write & Deploy an NFT (Part 1/3 of NFT Tutorial Series)BeginnerSumi Mudgil •April 21, 2021 •13 minThis tutorial is Part 1 of a series on NFTs that will take you step by step on how to write and deploy a Non Fungible Token (ERC-721 token) smart contract using Ethereum and Inter Planetary File System (IPFS).erc-721alchemysoliditysmart contractsSending Tokens Using ethers.jsBeginnerKim YongJun •April 5, 2021 •2 minBeginner friendly guide to sending tokens using ethers.js.ethers.jserc-20tokensVyper ERC-721 Contract WalkthroughBeginnerOri Pomerantz •March 31, 2021 •20 minRyuya Nakamura's ERC-721 contract and how it worksvypererc-721pythonHello World Smart Contract for BeginnersBeginnerelanh •March 30, 2021 •12 minIntroductory tutorial on writing and deploying a simple smart contract on Ethereum.solidityhardhatalchemysmart contractsdeployingERC-20 Contract Walk-ThroughBeginnerOri Pomerantz •March 8, 2021 •27 minWhat is in the OpenZeppelin ERC-20 contract and why is it there?solidityerc-20Monitoring Geth with InfluxDB and GrafanaIntermediateMario Havel •January 12, 2021 •5 minSet up monitoring for your Geth node using InfluxDB and Grafana to track performance and identify issues.clientsnodesHow to Fetch the Current Price of Ethereum in SolidityBeginnerHarry Papacharissiou •January 5, 2021NaN •ExternalLearn how to fetch the current price of Bitcoin, Ethereum and other cryptocurrencies in your Solidity smart contracts.solidityoracles (opens in a new tab)Using WebSocketsBeginnerElan Halpern •November 30, 2020 •6 minGuide to using WebSockets and Alchemy to make JSON-RPC requests and subscribe to events.alchemywebsocketsqueryingjavascriptSending Transactions Using Web3BeginnerElan Halpern •November 3, 2020 •10 minThis is a beginner friendly guide to sending Ethereum transactions using Web3. There are three main steps in order to send a transaction to the Ethereum blockchain: create, sign, and broadcast. We’ll go through all three.transactionsweb3.jsalchemyGetting Started with Ethereum DevelopmentBeginnerElan Halpern •October 29, 2020 •4 minThis is a beginner's guide to getting started with Ethereum development. We’ll take you from spinning up an API endpoint, to making a command line request, to writing your first web3 script! No blockchain development experience necessary!javascriptethers.jsnodesqueryingalchemyA Python developer's introduction to Ethereum, part 1BeginnerMarc Garreau •September 7, 2020 •12 minAn introduction to Ethereum development, especially useful for those with knowledge of the Python programming languagepythonweb3.pyA guide to smart contract security toolsIntermediateTrailofbits •September 6, 2020 •6 minAn overview of three different testing and program analysis techniquessoliditysmart contractssecuritySmart contract security checklistIntermediateTrailofbits •September 6, 2020 •2 minA suggested workflow for writing secure smart contractssmart contractssecuritysoliditySmart contract security guidelinesIntermediateTrailofbits •September 5, 2020 •4 minA checklist of security guidelines to consider when building your dappsoliditysmart contractssecurityThe Graph: Fixing Web3 data queryingIntermediateMarkus Waas •September 5, 2020 •8 minBlockchain is like a database but without SQL. All the data is there, but no way to access it. Let me show you how to fix this with The Graph and GraphQL.soliditysmart contractsqueryingthe graphreactToken integration checklistIntermediateTrailofbits •August 12, 2020 •4 minA checklist of things to consider when interacting with tokenssoliditysmart contractssecuritytokensDownsizing contracts to fight the contract size limitIntermediateMarkus Waas •June 25, 2020 •6 minWhat can you do to prevent your smart contracts from getting too large?soliditysmart contractsstorageHow to use Slither to find smart contract bugsAdvancedTrailofbits •June 8, 2020 •7 minHow to use Slither to automatically find bugs in smart contractssoliditysmart contractssecuritytestingHow to mock Solidity smart contracts for testingIntermediateMarkus Waas •May 1, 2020 •4 minWhy you should make fun of your contracts when testingsoliditysmart contractstestingmockingKickstart your dapp frontend development with create-eth-appBeginnerMarkus Waas •April 26, 2020 •6 minAn overview of how to use create-eth-app and its featuresfrontendjavascriptethers.jsthe graphdefiCalling a smart contract from JavaScriptBeginnerjdourlens •April 18, 2020 •3 minHow to call a smart contract function from JavaScript using a Dai token exampletransactionsfrontendjavascriptweb3.jsSet up web3.js to use the Ethereum blockchain in JavaScriptBeginnerjdourlens •April 10, 2020 •3 minLearn how to set up and configure web3.js library to interact with the Ethereum blockchain from JavaScript applications.web3.jsjavascriptHow to use Echidna to test smart contractsAdvancedTrailofbits •April 9, 2020 •13 minHow to use Echidna to automatically test smart contractssoliditysmart contractssecuritytestingfuzzingTransfers and approval of ERC-20 tokens from a solidity smart contractIntermediatejdourlens •April 6, 2020 •7 minBuild a DEX smart contract that handles ERC-20 token transfers and approvals using Solidity.smart contractstokenssolidityerc-20Interact with other contracts from SolidityAdvancedjdourlens •April 4, 2020 •4 minHow to deploy a smart contract from an existing contract and interact with itsmart contractssolidityremixdeployingcomposabilityUnderstand the ERC-20 token smart contractBeginnerjdourlens •April 4, 2020 •5 minLearn how to implement the ERC-20 token standard with a complete Solidity smart contract example and explanation.smart contractstokenssolidityerc-20Deploying your first smart contractBeginnerjdourlens •April 2, 2020 •4 minAn introduction to deploying your first smart contract on an Ethereum test networksmart contractsremixsoliditydeployingLogging data from smart contracts with eventsIntermediatejdourlens •April 2, 2020 •2 minAn introduction to smart contract events and how you can use them to log datasmart contractsremixsolidityeventsHow to implement an ERC-721 marketIntermediateAlberto Cuesta Cañada •March 18, 2020 •6 minHow to put tokenized items for sale on a decentralized classifieds boardsmart contractserc-721soliditytokensHow to use Manticore to find bugs in smart contractsAdvancedTrailofbits •January 12, 2020 •11 minHow to use Manticore to automatically find bugs in smart contractssoliditysmart contractssecuritytestingformal verification","tokens":7728,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260241072,"hash":"1ac1781ca24c6889401e446b6d8c2229a1bad5a6"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/api-core","domain":"docs.openzeppelin.com","title":"OpenZeppelin Upgrades Core & CLI | OpenZeppelin Docs","text":"Upgrades PluginsOpenZeppelin Upgrades Core & CLIOpen in ClaudeThe @openzeppelin/upgrades-core package provides a validate command to check for upgrade safety and storage layout compatibility in upgradeable contracts. It can be used throughout your development process to ensure that your contracts are upgrade safe and compatible with previous versions.\nIt also provides APIs to perform these checks programmatically, and contains the core logic for these checks to be performed with the OpenZeppelin Upgrades plugins.\nCLI: Validate Command\nDetects upgradeable contracts from a directory containing build info files and validates whether they are upgrade safe. Use this if you want to validate all of your project's upgradeable contracts from the command line, in a script, or as part of your CI/CD pipeline.\n\"Build info files\" are generated by your compilation toolchain (Hardhat, Foundry) and contain the inputs and outputs of the compilation process.\nPrerequisites\nBefore using the validate command, you must define upgradeable contracts so that they can be detected and validated, define reference contracts for storage layout comparisons, and compile your contracts.\nDefine Upgradeable Contracts\nThe validate command performs upgrade safety checks on contracts that look like upgradeable contracts. Specifically, it performs checks on implementation contracts that meet any of the following criteria:\n\nInherits Initializable.\nHas an upgradeTo(address) or upgradeToAndCall(address,bytes) function. This is the case for contracts that inherit UUPSUpgradeable.\nHas the NatSpec annotation @custom:oz-upgrades\nHas the NatSpec annotation @custom:oz-upgrades-from <reference> according to Define Reference Contracts below.\n\nSimply add the NatSpec annotation @custom:oz-upgrades or @custom:oz-upgrades-from <reference> to each implementation contract so that it can be detected as an upgradeable contract for validation.\nDefine Reference Contracts\nIf an implementation contract is meant to deployed as an upgrade to an existing proxy, you MUST define a reference contract for storage layout comparisons. Otherwise, you will not receive errors if there are any storage layout incompatibilities.\nDefine a reference contract by adding the NatSpec annotation @custom:oz-upgrades-from <reference> to your implementation contract, where <reference> is the contract name or fully qualified contract name of the reference contract to use for storage layout comparisons. The contract does not need to be in scope, and the contract name will suffice if it is unambiguous across the project.\nExample:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\n/// @custom:oz-upgrades-from MyContractV1\ncontract MyContractV2 {\n ...\n}\nOr:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\n/// @custom:oz-upgrades-from contracts/MyContract.sol:MyContractV1\ncontract MyContractV2 {\n ...\n}\nCompile Contracts with Storage Layouts\nCompile your contracts and ensure that your build is configured to output JSON files with Solidity compiler inputs and outputs in a build info directory. The compiler output must include storage layouts. If any previous build artifacts exist, they must be cleaned first to avoid duplicate contract definitions.\nHardhat\nConfigure hardhat.config.js or hardhat.config.ts to include storage layout in the output selection:\nmodule.exports = {\n solidity: {\n settings: {\n outputSelection: {\n '*': {\n '*': ['storageLayout'],\n },\n },\n },\n },\n};\nThen compile your contracts:\nnpx hardhat clean && npx hardhat compile\nFoundry\nConfigure foundry.toml to include build info and storage layout:\n[profile.default]\nbuild_info = true\nextra_output = [\"storageLayout\"]\nThen compile your contracts:\nforge clean && forge build\nUsage\nAfter performing the prerequisites, run the npx @openzeppelin/upgrades-core validate command to validate your contracts:\nnpx @openzeppelin/upgrades-core validate [<BUILD_INFO_DIR>] [<OPTIONS>]\nIf any errors are found, the command will exit with a non-zero exit code and print a detailed report of the errors to the console.\nParameters:\n\n<BUILD_INFO_DIR> - Optional path to the build info directory which contains JSON files with Solidity compiler input and output. Defaults to artifacts/build-info for Hardhat projects or out/build-info for Foundry projects. If your project uses a custom output directory, you must specify its build info directory here.\n\nOptions:\n\n--contract <CONTRACT> - The name or fully qualified name of the contract to validate. If not specified, all upgradeable contracts in the build info directory will be validated.\n--reference <REFERENCE_CONTRACT> - Can only be used when the --contract option is also provided. The name or fully qualified name of the reference contract to use for storage layout comparisons. If not specified, uses the @custom:oz-upgrades-from annotation if it is defined in the contract that is being validated.\n--requireReference - Can only be used when the --contract option is also provided. Not compatible with --unsafeSkipStorageCheck. If specified, requires either the --reference option to be provided or the contract to have a @custom:oz-upgrades-from annotation.\n--referenceBuildInfoDirs \"<BUILD_INFO_DIR>[,<BUILD_INFO_DIR>...]\" - Optional paths of additional build info directories from previous versions of the project to use for storage layout comparisons. When using this option, refer to one of these directories using prefix <dirName>: before the contract name or fully qualified name in the --reference option or @custom:oz-upgrades-from annotation, where <dirName> is the directory short name. Each directory short name must be unique, including compared to the main build info directory. If passing in multiple directories, separate them with commas or call the option multiple times, once for each directory.\n--exclude \"<GLOB_PATTERN>\" [--exclude \"<GLOB_PATTERN>\"...] - Exclude validations for contracts in source file paths that match any of the given glob patterns. For example, --exclude \"contracts/mocks/\\***/**.sol\". Does not apply to reference contracts. If passing in multiple patterns, call the option multiple times, once for each pattern.\n--unsafeAllow \"<VALIDATION_ERROR>[,<VALIDATION_ERROR>...]\" - Selectively disable one or more validation errors or warnings. Comma-separated list with one or more of the following:\n\nErrors: state-variable-assignment, state-variable-immutable, external-library-linking, struct-definition, enum-definition, constructor, delegatecall, selfdestruct, missing-public-upgradeto, internal-function-storage, missing-initializer, missing-initializer-call, duplicate-initializer-call\nWarnings: incorrect-initializer-order\n\n--unsafeAllowRenames - Configure storage layout check to allow variable renaming.\n--unsafeSkipStorageCheck - Skips checking for storage layout compatibility errors. This is a dangerous option meant to be used as a last resort.\n\nHigh-Level API\nThe high-level API is a programmatic equivalent to the validate command. Use this API if you want to validate all of your project's upgradeable contracts from a JavaScript or TypeScript environment.\nPrerequisites\nSame prerequisites as the validate command.\nUsage\nImport the validateUpgradeSafety function:\nimport { validateUpgradeSafety } from '@openzeppelin/upgrades-core';\nThen call the function to validate your contracts and get a project report with the validation results.\nvalidateUpgradeSafety\nvalidateUpgradeSafety(\n buildInfoDir?: string,\n contract?: string,\n reference?: string,\n opts: ValidateUpgradeSafetyOptions = {},\n referenceBuildInfoDirs?: string[],\n exclude?: string[],\n): Promise<ProjectReport>\nDetects upgradeable contracts from a build info directory and validates whether they are upgrade safe. Returns a project report with the results.\nNote that this function does not throw validation errors directly. Instead, you must use the project report to determine whether any errors were found.\nParameters:\n\nbuildInfoDir - the path to the build info directory which contains JSON files with Solidity compiler input and output. Defaults to artifacts/build-info for Hardhat projects or out/build-info for Foundry projects. If your project uses a custom output directory, you must specify its build info directory here.\ncontract - The name or fully qualified name of the contract to validate. If not specified, all upgradeable contracts in the build info directory will be validated.\nreference - Can only be used when the contract argument is also provided. The name or fully qualified name of the reference contract to use for storage layout comparisons. If not specified, uses the @custom:oz-upgrades-from annotation if it is defined in the contract that is being validated.\nopts - an object with the following options as defined in Common Options:\n\nunsafeAllow\nunsafeAllowRenames\nunsafeSkipStorageCheck\nrequireReference - Can only be used when the contract argument is also provided. Not compatible with the unsafeSkipStorageCheck option. If specified, requires either the reference argument to be provided or the contract to have a @custom:oz-upgrades-from annotation.\n\nreferenceBuildInfoDirs - Optional paths of additional build info directories from previous versions of the project to use for storage layout comparisons. When using this option, refer to one of these directories using prefix <dirName>: before the contract name or fully qualified name in the reference param or @custom:oz-upgrades-from annotation, where <dirName> is the directory short name. Each directory short name must be unique, including compared to the main build info directory.\nexclude - Exclude validations for contracts in source file paths that match any of the given glob patterns.\n\nReturns:\n\na project report.\n\nProjectReport\ninterface ProjectReport {\n ok: boolean;\n explain(color?: boolean): string;\n numPassed: number;\n numTotal: number;\n}\nAn object that represents the result of upgrade safety checks and storage layout comparisons, and contains a report of all errors found.\nMembers:\n\nok - false if any errors were found, otherwise true.\nexplain() - returns a message explaining the errors in detail, if any.\nnumPassed - number of contracts that passed upgrade safety checks.\nnumTotal - total number of upgradeable contracts detected.\n\nLow-Level API\nThis low-level API is deprecated. Use the High-Level API instead.\nThe low-level API works with Solidity input and output JSON objects and lets you perform upgrade safety checks and storage layout comparisons on individual contracts. Use this API if you want to validate specific contracts rather than a whole project.\nPrerequisites\nCompile your contracts to generate Solidity input and output JSON objects. The compiler output must include storage layouts.\nNote that the other prerequisites from the validate command are not required, because the low-level API does not detect upgradeable contracts automatically. Instead, you must create an instance of UpgradeableContract for each implementation contract that you want to validate, and call functions on it to get the upgrade safety and storage layout reports.\nUsage\nImport the UpgradeableContract class:\nimport { UpgradeableContract } from '@openzeppelin/upgrades-core';\nThen create an instance of UpgradeableContract for each implementation contract that you want to validate, and call .getErrorReport() and/or .getStorageLayoutReport() on it to get the upgrade safety and storage layout reports, respectively.\nUpgradeableContract\nThis class represents the implementation for an upgradeable contract and gives access to error reports.\nconstructor UpgradeableContract\nconstructor UpgradeableContract(\n name: string,\n solcInput: SolcInput,\n solcOutput: SolcOutput,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n solcVersion?: string,\n): UpgradeableContract\nCreates a new instance of UpgradeableContract.\nParameters:\n\nname - the name of the implementation contract as either a fully qualified name or contract name. If multiple contracts have the same name, you must use the fully qualified name e.g., contracts/Bar.sol:Bar.\nsolcInput - the Solidity input JSON object for the implementation contract.\nsolcOutput - the Solidity output JSON object for the implementation contract.\nopts - an object with the following options as defined in Common Options:\n\nkind\nunsafeAllow\nunsafeAllowRenames\nunsafeSkipStorageCheck\n\nsolcVersion - the Solidity version used to compile the implementation contract.\n\nIn Hardhat, solcInput and solcOutput can be obtained from the Build Info file, which itself can be retrieved with hre.artifacts.getBuildInfo.\n.getErrorReport\ngetErrorReport(): Report\nReturns:\n\na report about errors pertaining to proxied contracts, e.g. the use of selfdestruct.\n\n.getStorageUpgradeReport\ngetStorageUpgradeReport(\n upgradedContract: UpgradeableContract,\n opts?: {\n unsafeAllow?: ValidationError[],\n unsafeAllowRenames?: boolean,\n unsafeSkipStorageCheck?: boolean,\n kind?: 'uups' | 'transparent' | 'beacon',\n },\n): Report\nCompares the storage layout of an upgradeable contract with that of a proposed upgrade.\nParameters:\n\nupgradedContract - another instance of UpgradeableContract representing the proposed upgrade.\nopts - an object with the following options as defined in Common Options:\n\nkind\nunsafeAllow\nunsafeAllowRenames\nunsafeSkipStorageCheck\n\nReturns:\n\na report about errors pertaining to proxied contracts, e.g. the use of selfdestruct, and storage layout conflicts.\n\nReport\ninterface Report {\n ok: boolean;\n explain(color?: boolean): string;\n}\nAn object that represents the results of an analysis.\nMembers:\n\nok - false if any errors were found, otherwise true.\nexplain() - returns a message explaining the errors in detail, if any.\nOptionsPrevious PageUsing with HardhatNext PageOn this pageCLI: Validate CommandPrerequisitesDefine Upgradeable ContractsDefine Reference ContractsCompile Contracts with Storage LayoutsHardhatFoundryUsageHigh-Level APIPrerequisitesUsagevalidateUpgradeSafetyProjectReportLow-Level APIPrerequisitesUsageUpgradeableContractconstructor UpgradeableContract.getErrorReport.getStorageUpgradeReportReport","tokens":3540,"squid":"ink-security_audits","role":"Sentinel","at":1791260241109,"hash":"510e73cded8a10130d6a2416652051192bd3ae1e"}
{"url":"https://eips.ethereum.org/EIPS/eip-609","domain":"eips.ethereum.org","title":"EIP-609: Hardfork Meta: Byzantium","text":"🎉 Final\n\n Meta\n\n EIP-609: Hardfork Meta: Byzantium\n\n Authors\n Alex Beregszaszi (@axic)\n\n Created\n 2017-04-23\n\n Requires\n\n EIP-100, \n\n EIP-140, \n\n EIP-196, \n\n EIP-197, \n\n EIP-198, \n\n EIP-211, \n\n EIP-214, \n\n EIP-607, \n\n EIP-649, \n\n EIP-658\n\n Abstract\n\nThis specifies the changes included in the hard fork named Byzantium.\n\n Specification\n\n Codename: Byzantium\n Aliases: Metropolis/Byzantium, Metropolis part 1\n Activation:\n\n Block >= 4,370,000 on Mainnet\n Block >= 1,700,000 on Ropsten testnet\n\n Included EIPs:\n\n EIP-100 (Change difficulty adjustment to target mean block time including uncles)\n EIP-140 (REVERT instruction in the Ethereum Virtual Machine)\n EIP-196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128)\n EIP-197 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128)\n EIP-198 (Precompiled contract for bigint modular exponentiation)\n EIP-211 (New opcodes: RETURNDATASIZE and RETURNDATACOPY)\n EIP-214 (New opcode STATICCALL)\n EIP-649 (Difficulty Bomb Delay and Block Reward Reduction)\n EIP-658 (Embedding transaction status code in receipts)\n\n References\n\n https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Alex Beregszaszi (@axic), \"EIP-609: Hardfork Meta: Byzantium,\" Ethereum Improvement Proposals, no. 609, April 2017. Available: https://eips.ethereum.org/EIPS/eip-609.","tokens":369,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260250659,"hash":"40cdebdac0afd684ddfb50607443e18a5f476b9e"}
{"url":"https://ethereum.org/developers/docs/intro-to-ethereum/","domain":"ethereum.org","title":"Technical intro to Ethereum | ethereum.org","text":"Technical intro to EthereumEdit page (opens in a new tab)What is a blockchain?\nA blockchain is a public database that is updated and shared across many computers in a network.\n\"Block\" refers to data and state being stored in consecutive groups known as \"blocks\". If you send ETH to someone else, the transaction data needs to be added to a block to be successful.\n\"Chain\" refers to the fact that each block cryptographically references its parent. In other words, blocks get chained together. The data in a block cannot change without changing all subsequent blocks, which would require the consensus of the entire network.\nEvery computer in the network must agree upon each new block and the chain as a whole. These computers are known as \"nodes\". Nodes ensure everyone interacting with the blockchain has the same data. To accomplish this distributed agreement, blockchains need a consensus mechanism.\nEthereum uses a proof-of-stake-based consensus mechanism. Anyone who wants to add new blocks to the chain must stake ETH - the native currency in Ethereum - as collateral and run validator software. These \"validators\" can then be randomly selected to propose blocks that other validators check and add to the blockchain. There is a system of rewards and penalties that strongly incentivize participants to be honest and available online as much as possible.\nIf you would like to see how blockchain data is hashed and subsequently appended to the history of block references, be sure to check out this demo (opens in a new tab) by Anders Brownworth and watch the accompanying video below.\nWatch Anders explain hashes in blockchains:\nBlockchain 101: a visual demoA demonstration of how blockchain technology works, covering hashing, blocks, chains, distributed ledgers, and tokens to make blockchain concepts tangible and intuitive.Watch with transcript \nWhat is Ethereum?\nEthereum is a blockchain with a computer embedded in it. It is the foundation for building apps and organizations in a decentralized, permissionless, censorship-resistant way.\nIn the Ethereum universe, there is a single, canonical computer (called the Ethereum Virtual Machine, or EVM) whose state everyone on the Ethereum network agrees on. Everyone who participates in the Ethereum network (every Ethereum node) keeps a copy of the state of this computer. Additionally, any participant can broadcast a request for this computer to perform arbitrary computation. Whenever such a request is broadcast, other participants on the network verify, validate, and carry out (\"execute\") the computation. This execution causes a state change in the EVM, which is committed and propagated throughout the entire network.\nRequests for computation are called transaction requests; the record of all transactions and the EVM's present state gets stored on the blockchain, which in turn is stored and agreed upon by all nodes.\nCryptographic mechanisms ensure that once transactions are verified as valid and added to the blockchain, they can't be tampered with later. The same mechanisms also ensure that all transactions are signed and executed with appropriate \"permissions\" (no one should be able to send digital assets from Alice's account, except for Alice herself).\nWhat is ether?\nEther (ETH) is the native cryptocurrency of Ethereum. The purpose of ETH is to allow for a market for computation. Such a market provides an economic incentive for participants to verify and execute transaction requests and provide computational resources to the network.\nAny participant who broadcasts a transaction request must also offer some amount of ETH to the network as a bounty. The network will burn part of the bounty and award the rest to whoever eventually does the work of verifying the transaction, executing it, committing it to the blockchain, and broadcasting it to the network.\nThe amount of ETH paid corresponds to the resources required to do the computation. These bounties also prevent malicious participants from intentionally clogging the network by requesting the execution of infinite computation or other resource-intensive scripts, as these participants must pay for computation resources.\nETH is also used to provide crypto-economic security to the network in three main ways: 1) it is used as a means to reward validators who propose blocks or call out dishonest behavior by other validators; 2) It is staked by validators, acting as collateral against dishonest behavior—if validators attempt to misbehave their ETH can be destroyed; 3) it is used to weigh 'votes' for newly proposed blocks, feeding into the fork-choice part of the consensus mechanism.\nWhat are smart contracts?\nIn practice, participants don't write new code every time they want to request a computation on the EVM. Rather, application developers upload programs (reusable snippets of code) into EVM state, and users make requests to execute these code snippets with varying parameters. We call the programs uploaded to and executed by the network \"smart contracts\".\nAt a very basic level, you can think of a smart contract like a sort of vending machine: a script that, when called with certain parameters, performs some actions or computation if certain conditions are satisfied. For example, a simple vendor smart contract could create and assign ownership of a digital asset if the caller sends ETH to a specific recipient.\nAny developer can create a smart contract and make it public to the network, using the blockchain as its data layer, for a fee paid to the network. Any user can then call the smart contract to execute its code, again for a fee paid to the network.\nThus, with smart contracts, developers can build and deploy arbitrarily complex user-facing apps and services such as: marketplaces, financial instruments, games, etc.\nTerminology\nBlockchain\nThe sequence of all blocks that have been committed to the Ethereum network in the history of the network. So named because each block contains a reference to the previous block, which helps us maintain an ordering over all blocks (and thus over the precise history).\nETH\nEther (ETH) is the native cryptocurrency of Ethereum. Users pay ETH to other users to have their code execution requests fulfilled.\nMore on ETH\nEVM\nThe Ethereum Virtual Machine is the global virtual computer whose state every participant on the Ethereum network stores and agrees on. Any participant can request the execution of arbitrary code on the EVM; code execution changes the state of the EVM.\nMore on the EVM\nNodes\nThe real-life machines which are storing the EVM state. Nodes communicate with each other to propagate information about the EVM state and new state changes. Any user can also request the execution of code by broadcasting a code execution request from a node. The Ethereum network itself is the aggregate of all Ethereum nodes and their communications.\nMore on nodes\nAccounts\nWhere ETH is stored. Users can initialize accounts, deposit ETH into the accounts, and transfer ETH from their accounts to other users. Accounts and account balances are stored in a big table in the EVM; they are a part of the overall EVM state.\nMore on accounts\nTransactions\nA \"transaction request\" is the formal term for a request for code execution on the EVM, and a \"transaction\" is a fulfilled transaction request and the associated change in the EVM state. Any user can broadcast a transaction request to the network from a node. For the transaction request to affect the agreed-upon EVM state, it must be validated, executed, and \"committed to the network\" by another node. Execution of any code causes a state change in the EVM; upon commitment, this state change is broadcast to all nodes in the network. Some examples of transactions:\n\nSend X ETH from my account to Alice's account.\nPublish some smart contract code into EVM state.\nExecute the code of the smart contract at address X in the EVM, with arguments Y.\n\nMore on transactions\nBlocks\nThe volume of transactions is very high, so transactions are \"committed\" in batches, or blocks. Blocks generally contain dozens to hundreds of transactions.\nMore on blocks\nSmart contracts\nA reusable snippet of code (a program) which a developer publishes into EVM state. Anyone can request that the smart contract code be executed by making a transaction request. Because developers can write arbitrary executable applications into the EVM (games, marketplaces, financial instruments, etc.) by publishing smart contracts, these are often also called dapps, or Decentralized Apps.\nMore on smart contracts\nWhere to go next\nMost readers follow the docs in order, but the shortest path depends on what you're trying to build:\n\nDapps that interact with Ethereum: accounts and transactions, then pick a framework.\nSmart contract development: smart contracts and programming languages.\nNodes and staking: nodes and clients, then consensus mechanisms.\n\nFurther reading\n\nEthereum Whitepaper\nHow does Ethereum work, anyway? (opens in a new tab) - Preethi Kasireddy (NB this resource is still valuable but be aware that it predates The Merge and therefore still refers to Ethereum's proof-of-work mechanism - Ethereum is actually now secured using proof-of-stake)\n\nMore of a visual learner?\nThis video series offers a thorough exploration of foundational topics:\nEthereum basics: introAn introductory lecture on Ethereum fundamentals, covering what Ethereum is, how it differs from Bitcoin, and the core concepts that underpin the Ethereum network.Watch with transcript \nEthereum Basics Playlist (opens in a new tab)\nKnow of a community resource that helped you? Edit this page and add it!\nRelated tutorials\n\nA developer's guide to Ethereum, part 1 – A very beginner-friendly exploration of Ethereum using Python and web3.py","tokens":2438,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260253589,"hash":"831253e961fe854145f08c0ebac3975aea03ecad"}
{"url":"https://docs.openzeppelin.com/upgrades-plugins/foundry/foundry-upgrades","domain":"docs.openzeppelin.com","title":"Using with Foundry | OpenZeppelin Docs","text":"Upgrades PluginsUsing with FoundryOpen in ClaudeFoundry library for deploying and managing upgradeable contracts, which includes upgrade safety validations.\nInstallation\nFollow one of the sections below depending on which version of OpenZeppelin Contracts you are using. OpenZeppelin Contracts v5 is required for new deployments.\nUsing OpenZeppelin Contracts v5\nRun these commands:\nforge install foundry-rs/forge-std\nforge install OpenZeppelin/openzeppelin-foundry-upgrades\nforge install OpenZeppelin/openzeppelin-contracts-upgradeable\nSet the following in remappings.txt, replacing any previous definitions of these remappings:\n@openzeppelin/contracts/=lib/openzeppelin-contracts-upgradeable/lib/openzeppelin-contracts/contracts/\n@openzeppelin/contracts-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts/\nThe above remappings mean that both @openzeppelin/contracts/ (including proxy contracts deployed by this library) and @openzeppelin/contracts-upgradeable/ come from your installation of the openzeppelin-contracts-upgradeable submodule and its subdirectories, which includes its own transitive copy of openzeppelin-contracts of the same release version number. This format is needed for Etherscan verification to work. Particularly, any copies of openzeppelin-contracts that you install separately are NOT used.\nUsing OpenZeppelin Contracts v4\nRun these commands, replacing v4.9.6 with the specific version of OpenZeppelin Contracts that you are using:\nforge install foundry-rs/forge-std\nforge install OpenZeppelin/openzeppelin-foundry-upgrades\nforge install OpenZeppelin/openzeppelin-contracts@v4.9.6\nforge install OpenZeppelin/openzeppelin-contracts-upgradeable@v4.9.6\nSet the following in remappings.txt:\n@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/\n@openzeppelin/contracts-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts/\nUse LegacyUpgrades.sol instead of Upgrades.sol to upgrade existing deployments that were created with OpenZeppelin Contracts v4.\nOptional: Alternative installation methods\nNPM\nFollow the steps above, but instead of running forge install OpenZeppelin/openzeppelin-foundry-upgrades, use this command instead:\nnpm install @openzeppelin/foundry-upgrades\nThen add the following additional line to remappings.txt, in addition to the ones described above:\nopenzeppelin-foundry-upgrades/=node_modules/@openzeppelin/foundry-upgrades/src/\nThis library can also be used in Hardhat 3 Solidity tests, where the same remapping applies. See Using with Hardhat — Solidity tests for the Hardhat configuration and an example.\nSoldeer\nFollow the steps above, but instead of running forge install OpenZeppelin/openzeppelin-foundry-upgrades, use one of the install commands described in https://soldeer.xyz/project/openzeppelin-foundry-upgrades\nThen add the following additional line to remappings.txt, in addition to the ones described above (replace 0.3.6 with the version of the plugin that you installed):\nopenzeppelin-foundry-upgrades/=dependencies/openzeppelin-foundry-upgrades-0.3.6/src/\nFoundry Requirements\nThis library requires forge-std version 1.9.5 or higher.\nBefore Running\nThis library uses the OpenZeppelin Upgrades CLI for upgrade safety validations, which are run by default during deployments and upgrades.\nIf you want to be able to run upgrade safety validations, the following are needed:\n\nInstall Node.js.\nConfigure your foundry.toml to enable ffi, ast, build info and storage layout:\n\n[profile.default]\nffi = true\nast = true\nbuild_info = true\nextra_output = [\"storageLayout\"]\n\nIf you are upgrading your contract from a previous version, add the @custom:oz-upgrades-from <reference> annotation to the new version of your contract according to Define Reference Contracts or specify the referenceContract option when calling the library’s functions.\nRun forge clean before running your Foundry script or tests, or include the --force option when running forge script or forge test.\n\nIf you do not want to run upgrade safety validations, you can skip the above steps and use the unsafeSkipAllChecks option when calling the Upgrades library’s functions, or use the UnsafeUpgrades library instead. Note that these are dangerous options meant to be used as a last resort.\nOptional: Custom output directory\nBy default, this library assumes your Foundry output directory is set to \"out\".\nIf you want to use a custom output directory, set it in your foundry.toml and provide read permissions for the directory. For example (replace my-output-dir with the directory that you want to use):\n[profile.default]\nout = \"my-output-dir\"\nfs_permissions = [{ access = \"read\", path = \"my-output-dir\" }]\nThen in a .env at your project root, set the FOUNDRY_OUT environment variable to match the custom output directory, for example:\nFOUNDRY_OUT=my-output-dir\nWindows environments\nIf you are using Windows, set the OPENZEPPELIN_BASH_PATH environment variable to the fully qualified path of the bash executable, using forward slashes. For example, with Git for Windows:\nOPENZEPPELIN_BASH_PATH=\"C:/Program Files/Git/bin/bash\"\nIn a Foundry project, you can set this in your project's .env file.\nUsage\nDepending on which major version of OpenZeppelin Contracts you are using, and whether you want to run upgrade safety validations, use the table below to determine which library to import:\nOpenZeppelin Contracts v5OpenZeppelin Contracts v4Runs validationsimport {Upgrades} from \"openzeppelin-foundry-upgrades/Upgrades.sol\";import {Upgrades} from \"openzeppelin-foundry-upgrades/LegacyUpgrades.sol\";No validationsimport {UnsafeUpgrades} from \"openzeppelin-foundry-upgrades/Upgrades.sol\";import {UnsafeUpgrades} from \"openzeppelin-foundry-upgrades/LegacyUpgrades.sol\";\nImport one of the above libraries in your Foundry scripts or tests, for example:\nimport {Upgrades} from \"openzeppelin-foundry-upgrades/Upgrades.sol\";\nAlso import the implementation contract that you want to validate, deploy, or upgrade to, for example:\nimport {MyToken} from \"src/MyToken.sol\";\nThen call functions from the imported library to run validations, deployments, or upgrades.\nExamples\nThe following examples assume you are using OpenZeppelin Contracts v5 and want to run upgrade safety validations.\nDeploy a proxy\nDeploy a UUPS proxy:\naddress proxy = Upgrades.deployUUPSProxy(\n \"MyContract.sol\",\n abi.encodeCall(MyContract.initialize, (\"arguments for the initialize function\"))\n);\nDeploy a transparent proxy:\naddress proxy = Upgrades.deployTransparentProxy(\n \"MyContract.sol\",\n INITIAL_OWNER_ADDRESS_FOR_PROXY_ADMIN,\n abi.encodeCall(MyContract.initialize, (\"arguments for the initialize function\"))\n);\nDeploy an upgradeable beacon and a beacon proxy:\naddress beacon = Upgrades.deployBeacon(\"MyContract.sol\", INITIAL_OWNER_ADDRESS_FOR_BEACON);\n\naddress proxy = Upgrades.deployBeaconProxy(\n beacon,\n abi.encodeCall(MyContract.initialize, (\"arguments for the initialize function\"))\n);\nUse your contract\nCall your contract’s functions as normal, but remember to always use the proxy address:\nMyContract instance = MyContract(proxy);\ninstance.myFunction();\nUpgrade a proxy or beacon\nUpgrade a transparent or UUPS proxy and call an arbitrary function (such as a reinitializer) during the upgrade process:\nUpgrades.upgradeProxy(\n transparentProxy,\n \"MyContractV2.sol\",\n abi.encodeCall(MyContractV2.foo, (\"arguments for foo\"))\n);\nUpgrade a transparent or UUPS proxy without calling any additional function:\nUpgrades.upgradeProxy(\n transparentProxy,\n \"MyContractV2.sol\",\n \"\"\n);\nUpgrade a beacon:\nUpgrades.upgradeBeacon(beacon, \"MyContractV2.sol\");\nWhen upgrading a proxy or beacon, ensure that the new contract either has its @custom:oz-upgrades-from <reference> annotation set to the name of the old implementation contract used by the proxy or beacon, or set it with the referenceContract option, for example:Options memory opts;\nopts.referenceContract = \"MyContractV1.sol\";\nUpgrades.upgradeProxy(proxy, \"MyContractV2.sol\", \"\", opts);\n// or Upgrades.upgradeBeacon(beacon, \"MyContractV2.sol\", opts);\nIf possible, keep the old version of the implementation contract’s source code somewhere in your project to use as a reference as above. This requires the new version to be in a different directory, Solidity file, or using a different contract name. Otherwise, if you want to use the same directory and name for the new version, keep the build info directory from the previous deployment (or build it from an older branch of your project repository) and reference it as follows:Options memory opts;\nopts.referenceBuildInfoDir = \"/old-builds/build-info-v1\";\nopts.referenceContract = \"build-info-v1:MyContract\";\nUpgrades.upgradeProxy(proxy, \"MyContract.sol\", \"\", opts);\n// or Upgrades.upgradeBeacon(beacon, \"MyContract.sol\", opts);\nCoverage Testing\nTo enable code coverage reports with forge coverage, use the following deployment pattern in your tests: instantiate your implementation contracts directly and use the UnsafeUpgrades library. For example:\naddress implementation = address(new MyContract());\naddress proxy = UnsafeUpgrades.deployUUPSProxy(\n implementation,\n abi.encodeCall(MyContract.initialize, (\"arguments for the initialize function\"))\n);\nUnsafeUpgrades is not recommended for use in Forge scripts. It does not validate whether your contracts are upgrade safe or whether new implementations are compatible with previous ones. Ensure you run validations before any actual deployments or upgrades, such as by using the Upgrades library in scripts.\nDeploying and Verifying\nRun your script with forge script to broadcast and deploy. See Foundry’s Solidity Scripting guide.\nInclude the --sender <ADDRESS> flag for the forge script command when performing upgrades, specifying an address that owns the proxy or proxy admin. Otherwise, OwnableUnauthorizedAccount errors will occur.\nInclude the --verify flag for the forge script command if you want to verify source code such as on Etherscan. This will verify your implementation contracts along with any proxy contracts as part of the deployment.\nAPI\nSee Foundry Upgrades API for the full API documentation.Migrating from Hardhat 2Previous PageWriting Upgradeable ContractsNext PageOn this pageInstallationUsing OpenZeppelin Contracts v5Using OpenZeppelin Contracts v4Optional: Alternative installation methodsNPMSoldeerFoundry RequirementsBefore RunningOptional: Custom output directoryWindows environmentsUsageExamplesDeploy a proxyUse your contractUpgrade a proxy or beaconCoverage TestingDeploying and VerifyingAPI","tokens":2624,"squid":"ink-security_audits","role":"Sentinel","at":1791260253658,"hash":"d13678ae8ecde5c6fdf08056830d1935da077e45"}
{"url":"https://eips.ethereum.org/EIPS/eip-197","domain":"eips.ethereum.org","title":"EIP-197: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-197: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128\n\n Authors\n Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>\n\n Created\n 2017-02-06\n\n Simple Summary\n\nPrecompiled contracts for elliptic curve pairing operations are required in order to perform zkSNARK verification within the block gas limit.\n\n Abstract\n\nThis EIP suggests to add precompiled contracts for a pairing function on a specific pairing-friendly elliptic curve. This can in turn be combined with EIP-196 to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).\n\n Motivation\n\nCurrent smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive\nto fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.\n\nNote that fixing these parameters will in no way limit the use-cases for zkSNARKs, it will even allow for incorporating some advances in zkSNARK research without the need for a further hard fork.\n\nPairing functions can be used to perform a limited form of multiplicatively homomorphic operations, which are necessary for current zkSNARKs. This precompile can be used to run such computations within the block gas limit. This precompiled contract only specifies a certain check, and not an evaluation of a pairing function. The reason is that the codomain of a pairing function is a rather complex field which could provide encoding problems and all known uses of pairing function in zkSNARKs only require the specified check.\n\n Specification\n\nFor blocks where block.number >= BYZANTIUM_FORK_BLKNUM, add a precompiled contracts for a bilinear function on groups on the elliptic curve “alt_bn128”. We will define the precompiled contract in terms of a discrete logarithm. The discrete logarithm is of course assumed to be hard to compute, but we will give an equivalent specification that makes use of elliptic curve pairing functions which can be efficiently computed below.\n\nAddress: 0x8\n\nFor a cyclic group G (written additively) of prime order q let log_P: G -> F_q be the discrete logarithm on this group with respect to a generator P, i.e. log_P(x) is the smallest non-negative integer n such that n * P = x.\n\nThe precompiled contract is defined as follows, where the two groups G_1 and G_2 are defined by their generators P_1 and P_2 below. Both generators have the same prime order q.\n\nInput: (a1, b1, a2, b2, ..., ak, bk) from (G_1 x G_2)^k\nOutput: If the length of the input is incorrect or any of the inputs are not elements of\n the respective group or are not encoded correctly, the call fails.\n Otherwise, return one if\n log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0\n (in F_q) and zero else.\n\nNote that k is determined from the length of the input. Following the section on the encoding below,\nk is the length of the input divided by 192. If the input length is not a multiple of 192,\nthe call fails. Empty input is valid and results in returning one.\n\nIn order to check that an input is an element of G_1, verifying the encoding of the coordinates and checking that they satisfy the curve equation (or is the encoding of infinity) is sufficient. For G_2, in addition to that, the order of the element has to be checked to be equal to the group order q = 21888242871839275222246405745257275088548364400416034343698204186575808495617.\n\n Definition of the groups\n\nThe groups G_1 and G_2 are cyclic groups of prime order q = 21888242871839275222246405745257275088548364400416034343698204186575808495617.\n\nThe group G_1 is defined on the curve Y^2 = X^3 + 3 over the field F_p with p = 21888242871839275222246405745257275088696311157297823662689037894645226208583 with generator P1 = (1, 2).\n\nThe group G_2 is defined on the curve Y^2 = X^3 + 3/(i+9) over a different field F_p^2 = F_p[i] / (i^2 + 1) (p is the same as above) with generator\nP2 = (\n 11559732032986387107991004021392285783925812861821192530917403151452391805634 * i +\n 10857046999023057135944570762232829481370756359578518086990519993285655852781,\n 4082367875863433681332203403145435568316851327593401208105741076214120093531 * i +\n 8495653923123431417604973247489272438418190587263600148770280649306958101930\n)\n\nNote that G_2 is the only group of order q of that elliptic curve over the field F_p^2. Any other generator of order q instead of P2 would define the same G_2. However, the concrete value of P2 is useful for skeptical readers who doubt the existence of a group of order q. They can be instructed to compare the concrete values of q * P2 and P2.\n\n Encoding\n\nElements of F_p are encoded as 32 byte big-endian numbers. An encoding value of p or larger is invalid.\n\nElements a * i + b of F_p^2 are encoded as two elements of F_p, (a, b).\n\nElliptic curve points are encoded as a Jacobian pair (X, Y) where the point at infinity is encoded as (0, 0).\n\nNote that the number k is derived from the input length.\n\nThe length of the returned data is always exactly 32 bytes and encoded as a 32 byte big-endian number.\n\n Gas costs\n\nThe gas costs of the precompiled contract are 80 000 * k + 100 000, where k is the number of\npoints or, equivalently, the length of the input divided by 192.\n\n Rationale\n\nThe specific curve alt_bn128 was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.\n\nThe feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification; the gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve or does not admit an efficient pairing implementation.\n\nA non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).\n\nThe encoding of field elements in F_p^2 was chosen in this order to be in line with the big endian encoding of the elements themselves.\n\n Backwards Compatibility\n\nAs with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the “reserved range” below 256.\n\n Test Cases\n\nTo be written.\n\n Implementation\n\nThe precompiled contract can be implemented using elliptic curve pairing functions, more specifically, an optimal ate pairing on the alt_bn128 curve, which can be implemented efficiently. In order to see that, first note that a pairing function e: G_1 x G_2 -> G_T fulfills the following properties (G_1 and G_2 are written additively, G_T is written multiplicatively):\n\n(1) e(m * P1, n * P2) = e(P1, P2)^(m * n)\n(2) e is non-degenerate\n\nNow observe that\nlog_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk) = 0 (in F_q)\n\nif and only if\ne(P1, P2)^(log_P1(a1) * log_P2(b1) + ... + log_P1(ak) * log_P2(bk)) = 1 (in G_T)\n\nFurthermore, the left hand side of this equation is equal to\ne(log_P1(a1) * P1, log_P2(b1) * P2) * ... * e(log_P1(ak) * P1, log_P2(bk) * P2)\n= e(a1, b1) * ... * e(ak, bk)\n\nAnd thus, the precompiled contract can be implemented by verifying that\ne(a1, b1) * ... * e(ak, bk) = 1\n\nImplementations are available here:\n\n libff (C++)\n bn (Rust)\n Python\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin <vitalik@ethereum.org>, Christian Reitwiessner <chris@ethereum.org>, \"EIP-197: Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128,\" Ethereum Improvement Proposals, no. 197, February 2017. Available: https://eips.ethereum.org/EIPS/eip-197.","tokens":2132,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260260771,"hash":"ad55bb3de69f23fa1cde4e917c97d5dcf9f7125a"}
{"url":"https://ethereum.org/layer-2/","domain":"ethereum.org","title":"Intro to Ethereum Layer 2: benefits and uses | ethereum.org","text":"Powered by EthereumEthereum is no longer just a single network. With hundreds of blockchains now built on top of it, Ethereum has become more cost-effective, faster, and accessible for everyday use.Embrace the future by joining one of the many networks powered by Ethereum!$0.035Average transaction cost on the Ethereum blockchain$0.0016Average transaction cost on Ethereum backed networksThe network of networksEthereum's strength and security provides a platform for other networks to build upon. With a single account, everything is compatible and connects seamlessly.$0.01 feesYou can trade, send money globally, or use applications without worrying about high costs.Near instant transactionsWhether you are making a quick payment or engaging in decentralized finance (DeFi), all transactions take only a few seconds.Backed by EthereumEthereum's time-proven and decentralized blockchain functions as the settlement layer for other newer networks.Ready to start?Have a look at all the different networks that are available to you.Explore networksInkInk is an Ethereum OP Stack layer 2 blockchain designed to be the house of DeFi for the Superchain; a powerful baselayer for deploying innovative DeFi protocols.Go (opens in a new tab)Arbitrum OneArbitrum One is a general-purpose Optimistic Rollup built by Offchain Labs and governed by the Arbitrum DAO.Go (opens in a new tab)StarknetStarknet is a general purpose ZK Rollup based on STARKs and the Cairo VM.Go (opens in a new tab)Powered by EthereumWhy do we need multiple networks on Ethereum?Why are there all these networks and not just one Ethereum network?Learn moreFrequently asked questionsThere are many different ways one can categorize networks in relation to Ethereum. Many networks claim to be scaling Ethereum to gather popularity. However, one clear perspective is whether the network stores its data on the Ethereum main network. This greatly enhances user security and Ethereum's permissionless vision. Such projects are often called “rollups”. If data is stored somewhere else, then the project is not a direct Ethereum extension and is rather independent. Check out some of the most popular Ethereum networks.Some specific industries might not require such direct close relationship such as gaming or non-financial applications where different technologies are better fit.While generally designed with robust security features, their safety depends on the underlying technology, smart contract security, and maturity of the network.Users should perform due diligence, starting with small transactions and staying updated on developments to ensure secure usage.Ethereum can't easily scale its own main chain because it needs to stay secure and decentralized. Making the main chain faster would require larger nodes and more specialised hardware, reducing the number of people who can run a node and undermining decentralization. Instead, Ethereum focuses on being the best settlement layer it can be. The Fusaka upgrade (December 2025) introduced PeerDAS, a more efficient way for L2s to post and retrieve data on Ethereum, so the network of networks can keep scaling without compromising on security.Just as there is no 'official' Ethereum client, there is no 'official' Ethereum layer 2. Ethereum is permissionless - technically anyone can create a layer 2! Multiple teams will implement their version of a layer 2, and the ecosystem as a whole will benefit from a diversity of design approaches that are optimized for different use cases. Much like we have multiple Ethereum clients developed by multiple teams in order to have diversity in the network, this too will be how layer 2s develop in the future.","tokens":920,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260263772,"hash":"fdeb4912326724df7c552a8970c76668e4796159"}
{"url":"https://eips.ethereum.org/EIPS/eip-196","domain":"eips.ethereum.org","title":"EIP-196: Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-196: Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128\n\n Authors\n Christian Reitwiessner <chris@ethereum.org>\n\n Created\n 2017-02-02\n\n Simple Summary\n\nPrecompiled contracts for elliptic curve operations are required in order to perform zkSNARK verification within the block gas limit.\n\n Abstract\n\nThis EIP suggests to add precompiled contracts for addition and scalar multiplication on a specific pairing-friendly elliptic curve. This can in turn be combined with EIP-197 to verify zkSNARKs in Ethereum smart contracts. The general benefit of zkSNARKs for Ethereum is that it will increase the privacy for users (because of the Zero-Knowledge property) and might also be a scalability solution (because of the succinctness and efficient verifiability property).\n\n Motivation\n\nCurrent smart contract executions on Ethereum are fully transparent, which makes them unsuitable for several use-cases that involve private information like the location, identity or history of past transactions. The technology of zkSNARKs could be a solution to this problem. While the Ethereum Virtual Machine can make use of zkSNARKs in theory, they are currently too expensive\nto fit the block gas limit. Because of that, this EIP proposes to specify certain parameters for some elementary primitives that enable zkSNARKs so that they can be implemented more efficiently and the gas cost be reduced.\n\nNote that while fixing these parameters might look like limiting the use-cases for zkSNARKs, the primitives are so basic that they can be combined in ways that are flexible enough so that it should even be possible to allow future advances in zkSNARK research without the need for a further hard fork.\n\n Specification\n\nIf block.number >= BYZANTIUM_FORK_BLKNUM, add precompiled contracts for point addition (ADD) and scalar multiplication (MUL) on the elliptic curve “alt_bn128”.\n\nAddress of ADD: 0x6\nAddress for MUL: 0x7\n\nThe curve is defined by:\nY^2 = X^3 + 3\nover the field F_p with\np = 21888242871839275222246405745257275088696311157297823662689037894645226208583\n\n Encoding\n\nField elements and scalars are encoded as 32 byte big-endian numbers. Curve points are encoded as two field elements (x, y), where the point at infinity is encoded as (0, 0).\n\nTuples of objects are encoded as their concatenation.\n\nFor both precompiled contracts, if the input is shorter than expected, it is assumed to be virtually padded with zeros at the end (i.e. compatible with the semantics of the CALLDATALOAD opcode). If the input is longer than expected, surplus bytes at the end are ignored.\n\nThe length of the returned data is always as specified (i.e. it is not “unpadded”).\n\n Exact semantics\n\nInvalid input: For both contracts, if any input point does not lie on the curve or any of the field elements (point coordinates) is equal or larger than the field modulus p, the contract fails. The scalar can be any number between 0 and 2**256-1.\n\n ADD\n\nInput: two curve points (x, y).\nOutput: curve point x + y, where + is point addition on the elliptic curve alt_bn128 specified above.\nFails on invalid input and consumes all gas provided.\n\n MUL\n\nInput: curve point and scalar (x, s).\nOutput: curve point s * x, where * is the scalar multiplication on the elliptic curve alt_bn128 specified above.\nFails on invalid input and consumes all gas.\n\n Gas costs\n\n Gas cost for ECADD: 500\n Gas cost for ECMUL: 40000\n\n Rationale\n\nThe specific curve alt_bn128 was chosen because it is particularly well-suited for zkSNARKs, or, more specifically their verification building block of pairing functions. Furthermore, by choosing this curve, we can use synergy effects with ZCash and re-use some of their components and artifacts.\n\nThe feature of adding curve and field parameters to the inputs was considered but ultimately rejected since it complicates the specification: The gas costs are much harder to determine and it would be possible to call the contracts on something which is not an actual elliptic curve.\n\nA non-compact point encoding was chosen since it still allows to perform some operations in the smart contract itself (inclusion of the full y coordinate) and two encoded points can be compared for equality (no third projective coordinate).\n\n Backwards Compatibility\n\nAs with the introduction of any precompiled contract, contracts that already use the given addresses will change their semantics. Because of that, the addresses are taken from the “reserved range” below 256.\n\n Test Cases\n\nInputs to test:\n\n Curve points which would be valid if the numbers were taken mod p (should fail).\n Both contracts should succeed on empty input.\n Truncated input that results in a valid curve point.\n Points not on curve (but valid otherwise).\n Multiply point with scalar that lies between the order of the group and the field (should succeed).\n Multiply point with scalar that is larger than the field order (should succeed).\n\n Implementation\n\nImplementation of these primitives are available here:\n\n libff (C++)\n bn (Rust)\n\nIn both codebases, a specific group on the curve alt_bn128 is used and is called G1.\n\n Python - probably most self-contained and best readable.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Christian Reitwiessner <chris@ethereum.org>, \"EIP-196: Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128,\" Ethereum Improvement Proposals, no. 196, February 2017. Available: https://eips.ethereum.org/EIPS/eip-196.","tokens":1393,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260271321,"hash":"530ecb6dda96925eac5f93275319d5faa53eff31"}
{"url":"https://ethereum.org/founders/","domain":"ethereum.org","title":"Founders support | ⁦ethereum.org⁩","text":"Apply for supportChoose your path and get routed to the most relevant next step.Optimism AtlasActiveGrant ProgramAudit GrantsPublic GoodsSupport for individual builders and teams making onchain apps, tooling, and infrastructure to advance the Superchain.19 chains eligible700+ projects supportedVisit Optimism (opens in a new tab)BaseActiveGrant ProgramTooling & InfraBuilder Grants are ongoing experiments to recognize Base builders.1-5 ETH grantsVisit Base (opens in a new tab)Ecosystem Support ProgramActiveGrant ProgramPublic GoodsTooling & InfraEventsAllocating resources to critical projects, to be a valued voice within the Ethereum ecosystem, and to advocate for Ethereum to the outside world.2,000+ projects supportedVisit ESP (opens in a new tab)ArbitrumActiveGrant ProgramAudit GrantsTooling & InfraThe mission is to empower developers and entrepreneurs to build impactful DApps that leverage the capabilities of the Arbitrum network300+ projects supportedVisit Arbitrum (opens in a new tab)UnichainActiveGrant ProgramAudit GrantsTooling & InfraA series of programs and resources designed to support Unichain’s emergent developer communityNovel DeFi mechanismsVisit Unichain (opens in a new tab)PolygonActiveGrant ProgramTooling & InfraA community grants program to support builders, teams, and creators committed to the growth of PolygonBuilding or migrating to PolygonVisit Polygon (opens in a new tab)","tokens":354,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260274375,"hash":"763199222b4e2f752bef0429a0ed53e058e306d9"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-upgrades-new-instance-in-a-contract/17738","domain":"forum.openzeppelin.com","title":"Openzeppelin upgrades - new instance in a contract - Support / Upgrades - OpenZeppelin Forum","text":"Openzeppelin upgrades - new instance in a contract \n\n SupportUpgrades\n\n proxies\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Oct 2021\n\n 1 / 5\n\n Oct 2021\n\n Nov 2021\n\n post by novaknole on Oct 28, 2021\n\n novaknole\n\n Hi Team,\nI am writing new smart contracts and need to follow upgradability principles.\nI got a factory contract that should create 3-4 contracts inside it.\ncontract Factory {\n\n function create() public {\n Contract1 c1 = new Contract1();\n Contract2 c2 = new Contract2();\n Contract3 c3 = new Contract3(); \n }\n\n}\n\nNow, openzeppelin upgrade docs mention that I shouldn't be creating new instances inside smart contract and what I should be doing instead is passing the addresses to the create function above of already deployed contracts. In my case, that's a big problem, because this is a factory contract and it's the one that should be deploying new instances. It's a bad idea and I can't do to deploy contract1, contract2, contract3 separatelly, because I just showed an easy scenario and my case is a little bit complex. Here is where i read in the docs. https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable\nThanks a lot in advance for any help...\n\n ERC20Votes for upgradability doesn't exist\n\n 3\n\n 2\n\n post by novaknole on Oct 29, 2021\n\n novaknole\n\n The only way I can think of in this case is to use TransparentUpgradeableProxy and the below code would go in the factory function. WDYT ?\nTransparentUpgradeableProxy voting = new TransparentUpgradeableProxy(voting, msg.sender, abi.encodeWithSelector(Voting.initialize.selector, votingSettings));\n\n post by frangio on Nov 3, 2021\n\n frangio\n\n OpenZeppelin Team\n\n I'm missing some context here. Do you want your factory to be upgradeable? Do you want contracts 1, 2, and 3 to be upgradeable?\n\n post by novaknole on Nov 3, 2021\n\n novaknole\n\n @frangio\nCase 1.\nMainly, I want contract1, contract2, contract3 to be upgradable. Using openzeppelin upgrades plugin, I don't see the way how it can be achieved if I got a factory contract that deploys those 1,2,3 contracts. so my way of above seems really easy for me to understand. WDYT ?\nCase 2.\nWhat if I want my factory to be upgradable as well alongside those 1,2,3 contracts ? I guess, for factory, I'd use openzeppelin upgrades plugin with deployProxy and in the factory contract's function, I'd still have TransparentUpgradeableProxy voting = new TransparentUpgradeableProxy(voting, msg.sender, abi.encodeWithSelector(Voting.initialize.selector, votingSettings)); the following. What do you think ?\nThanks a lot.\n\n post by frangio on Nov 3, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How can I create a factory of Upgradeable smart contracts?\n\n Upgrades\n\n erc20,erc721,upgrades\n\n 3\n\n 1.4k\n\n Apr 2022\n\n How to upgrade a contract deployed from a factory contract?\n\n SDK\n\n proxies\n\n 12\n\n 2.9k\n\n Jul 2020\n\n Deploy an upgradable contract from an upgradable factory\n\n Upgrades\n\n 4\n\n 467\n\n Apr 2023\n\n Creating upgradeable contracts from Solidity, is it mandatory to use App.sol?\n\n SDK\n\n 3\n\n 2.7k\n\n Aug 2020\n\n How to upgrade contracts that was created via a factory contract without any CLI?\n\n SDK\n\n 8\n\n 2.2k\n\n Jul 2020","tokens":811,"squid":"ink-security_audits","role":"Sentinel","at":1791260275155,"hash":"87e3fdb1caebd1d0ac5b48bf4645b329435ae36f"}
{"url":"https://ethereum.org/developers/","domain":"ethereum.org","title":"Ethereum Developer Resources | ethereum.org","text":"What do you want to build today?Everything you need to learn and build your first apps on EthereumBeginnerTokenizationCreate a unique token to learn the basics of Scaffold-ETH 2.Start quest (opens in a new tab)IntermediateDEXBuild a simple automated market maker, provide liquidity, and implement token swaps.Start quest (opens in a new tab)AdvancedStablecoinsBuild a stablecoin and learn stability mechanisms and price oracles.Start quest (opens in a new tab)Challenges and mentorshipReceive mentorship from others, and learn how to collaborate with fellow developers.SpeedRun Ethereum (opens in a new tab)BeginnerTokenizationCreate a unique token to learn the basics of Scaffold-ETH 2.Start quest link-external-assistive-textIntermediateDEXBuild a simple automated market maker, provide liquidity, and implement token swaps.Start quest link-external-assistive-textAdvancedStablecoinsBuild a stablecoin and learn stability mechanisms and price oracles.Start quest link-external-assistive-textChallenges and mentorshipReceive mentorship from others, and learn how to collaborate with fellow developers.SpeedRun Ethereum link-external-assistive-textGet paid well. Stay remote. Build the future.Over half of blockchain careers are remote-first with some estimates putting the number as high as 70%.$93 - 169KAvg developer salary $80 - 255KAvg salary in blockchain industry Money you can programWrite code that defines how value moves, when, and to whom. No banks, no intermediaries, just logic you define.Future-proof skillsLearn the building blocks of the next internet. The tech might evolve, but the principles of web3 are here to stay.Censorship resistanceBuild projects and commerce that can't be silenced by governments, corporations, or algorithms. If it matters, it stays online.Digital sovereigntyOwn your identity, assets, and creations online without relying on platforms that can delete you.Build onchain with agentsStructured Ethereum knowledge for the agentic stack. Give your AI agent the context it needs to read state, send transactions, and coordinate with protocols, without leaving the model's context window.$ launch a coin for my community█Build with ethskills (opens in a new tab)Helpful developer resourcesQuickstart your ideaBootstrap your Ethereum app stack in seconds. Read Scaffold-ETH 2 (opens in a new tab)npx create-eth@latestScaffold-ETH 2 llms-full.txt (opens in a new tab)Get helpIf you are stuck or need help solving problems, be sure to ask for guidance.Stack Exchange (opens in a new tab)ResourcesWant to experiment first, ask questions later? Check sandboxes, bootcamps etc.Play with codeTutorialsLearn Ethereum development step-by-step from builders who have already done it.View tutorialsVideo coursesWant to kickstart your professional career in blockchain? These courses will prepare you to get hired as blockchain developer.3-hour courseBlockchain basicsLearn how blockchains and smart contracts work, create a wallet, and sign your first transaction. (opens in a new tab)5-hour courseSolidity smart contract developmentSolidity Programming is your gateway to web3 development in Ethereum compatible ecosystems. (opens in a new tab)10-hour courseFoundry fundamentalsLevel up your Solidity development skills with Foundry and advanced web3 development concepts and tools. (opens in a new tab)13-hour courseAdvanced foundryMaster web3 development techniques with Advanced Foundry for Solidity smart contract development. (opens in a new tab)24-hour courseSmart contract securityStart your career as a smart contract security researcher! Learn smart contract auditing and the best practices. (opens in a new tab)3-hour courseBlockchain basicsLearn how blockchains and smart contracts work, create a wallet, and sign your first transaction. link-external-assistive-text5-hour courseSolidity smart contract developmentSolidity Programming is your gateway to web3 development in Ethereum compatible ecosystems. link-external-assistive-text10-hour courseFoundry fundamentalsLevel up your Solidity development skills with Foundry and advanced web3 development concepts and tools. link-external-assistive-text13-hour courseAdvanced foundryMaster web3 development techniques with Advanced Foundry for Solidity smart contract development. link-external-assistive-text24-hour courseSmart contract securityStart your career as a smart contract security researcher! Learn smart contract auditing and the best practices. link-external-assistive-textBuilder updatesInsights on the latest Ethereum builder resources, tools, and developments.The next great wallet will be privateElliott AlexanderYour wallet sees every address you hold, every dApp you connect to, and every request you make. That same position lets it protect all of it. A practical look at the privacy tools, defaults, and unshipped ideas that will define the next generation of Ethereum wallets.July 2, 2026How to build privacy apps on Ethereum with zero-knowledge proofsPhilip Krause · EF Builder GrowthOne reusable pattern powers anonymous voting, mixers, airdrops, and membership systems on Ethereum. Learn the commitment-nullifier-proof cycle and how zero-knowledge tooling makes it practical to build today.May 12, 2026Why build on EthereumPhilip Krause · EF Builder GrowthDecentralization, censorship resistance, permissionless deployment, and composability are not separate selling points. They reinforce each other. A practical guide to why builders should choose Ethereum.May 12, 2026View all updatesExplore the documentationUnderstand the core concepts of Ethereum and blockchainsIntroductionsIntro to EthereumAn introduction to blockchain and EthereumIntro to EtherAn introduction to cryptocurrency and EtherIntro to dappsAn introduction to decentralized applicationsIntro to the stackAn introduction to the Ethereum stackWeb2 vs Web3How the web3 world of development is differentProgramming languagesUsing Ethereum with familiar languagesFundamentalsAccountsContracts or people on the networkTransactionsThe way Ethereum state changesBlocksBatches of transactions added to the blockchainThe Ethereum virtual machine (EVM)The computer that processes transactionsGasEther needed to power transactionsNodes and clientsHow blocks and transactions are verified in the networkNetworksAn overview of Mainnet and the test networksThe stackSmart contractsThe logic behind dapps – self-executing agreementsDevelopment frameworksTools for helping speed up developmentJavaScript librariesUsing JavaScript to interact with smart contractsBackend APIsUsing libraries to interact with smart contractsBlock explorersYour portal to Ethereum dataSmart contract securitySecurity measures to consider during development of smart contractsStorageHow to handle dapp storageDevelopment environmentsIDEs that are suitable for dapp developmentJoin hackathonsHackathons are great opportunities to network and learn from others as well as start projects and earn prizesParadigm FrontiersOct 12 – 14, 2026San Francisco, United States (opens in a new tab)Devcon IndiaNov 3 – 6, 2026Mumbai, India (opens in a new tab)ETHGlobal MumbaiNov 5 – 7, 2026Mumbai, India (opens in a new tab)Visit EthGlobal (opens in a new tab)Are you a founder?Have a project idea already or working on a prototype? Explore how to take your project to the next step. We can connect you with relevant organizations and experts in the field.Get in touch (opens email client)See grant options","tokens":1860,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260284732,"hash":"63f924ba6f60b65ece092b97cbd2b54a536b0948"}
{"url":"https://forum.openzeppelin.com/c/support/17","domain":"forum.openzeppelin.com","title":"Latest Support topics - OpenZeppelin Forum","text":"Latest topics in Support\n\n Support\n\n Ask for help and guidance about OpenZeppelin libraries and tools.\n\n Support\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Defender\n\n OpenZeppelin Defender Support\n\n Contracts\n\n OpenZeppelin Contracts Support\n\n Upgrades\n\n OpenZeppelin Upgrades Support\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Deploying BSC Smart Contract & Token Generation\n\n Support\n\n 7\n\n 3.3k\n\n 13h\n\n OZ Smart Account Builder on Stellar\n\n Support\n\n 0\n\n 33\n\n Jun 26\n\n UUPS Upgrade Successful (event emitted) but Implementation Address Not Updating (BSC Mainnet, Hardhat)\n\n Upgrades\n\n proxies,solidity,upgrades\n\n 3\n\n 113\n\n Apr 9\n\n [Defender Sunset] No migration path for CREATE2 deterministic deployments via hardhat-upgrades\n\n Defender\n\n etherscan-verify,defender\n\n 0\n\n 63\n\n Mar 18\n\n Initial alpha release of Hardhat Upgrades plugin for Hardhat v3\n\n Upgrades\n\n 0\n\n 78\n\n Mar 2\n\n Need help in locking a PCS LP\n\n Support\n\n etherscan-verify,bep20,solidity,pancake\n\n 0\n\n 45\n\n Feb 21\n\n Review Request: AOXC Upgradeable Token with Inflation Control & Daily Limits\n\n Contracts\n\n erc20,solidity,upgrades\n\n 0\n\n 75\n\n Feb 2\n\n Compatibility/Support of old manifest formats\n\n Upgrades\n\n 2\n\n 83\n\n Jan 29\n\n Install @openzeppelin/community-contracts\n\n Contracts\n\n multisig\n\n 2\n\n 70\n\n Jan 4\n\n Vanity contract address using CREATE2?\n\n Support\n\n 6\n\n 4.2k\n\n Dec 2025\n\n Contract `ReentrancyGuard` has a constructor define an initializer instead\n\n Support\n\n upgrades-plugins\n\n 0\n\n 121\n\n Dec 2025\n\n Unexpected different CREATE2 address when using defender.deployProxy() despite identical parameters\n\n Defender\n\n 0\n\n 87\n\n Dec 2025\n\n Partial Defender Deployment Fails to Maintain Deterministic Address\n\n Defender\n\n 0\n\n 53\n\n Dec 2025\n\n Why was the Approval event removed from transferFrom\n\n Contracts\n\n 0\n\n 62\n\n Nov 2025\n\n safeApprove… forever loop with remix\n\n Contracts\n\n 0\n\n 49\n\n Nov 2025\n\n How to get ‘exact code’ verification for OpenZeppelin UUPS proxy contracts?\n\n Upgrades\n\n proxies,hardhat\n\n 1\n\n 98\n\n Oct 2025\n\n ERC4626 vault\n\n Support\n\n 3\n\n 128\n\n Oct 2025\n\n // The following functions are overrides required by Solidity\n\n Contracts\n\n 4\n\n 2.7k\n\n Oct 2025\n\n Issue with my token\n\n Support\n\n 3\n\n 106\n\n Sep 2025\n\n ERC2771ContextUpgradeable implementation\n\n Contracts\n\n erc721\n\n 8\n\n 275\n\n Aug 2025\n\n About governance contract in version 5.4.0\n\n Contracts\n\n erc20,solidity\n\n 0\n\n 88\n\n Aug 2025\n\n The upgrade function is used repeatedly with the current version of the smart contract as an argument for the new version, but instead, a new one should be deployed\n\n Upgrades\n\n proxies\n\n 2\n\n 66\n\n Aug 2025\n\n Failed to upgrade implementation of proxy using proxy admin\n\n Upgrades\n\n 1\n\n 60\n\n Aug 2025\n\n Difference between initializer, reinitializer(1), and reinitializer(2) modifiers\n\n Contracts\n\n 8\n\n 1.5k\n\n Aug 2025\n\n Deploy upgradable contract with hardhat-upgrades fails on mainnet\n\n Upgrades\n\n 2\n\n 173\n\n Aug 2025\n\n Creation of ERC20PresetMinterPauser on Remix errored: Cannot convert undefined or null to object\n\n Contracts\n\n 5\n\n 2.4k\n\n Aug 2025\n\n Web3js intagration in html + JS please help me it wont display the ABI array in the browser like I told it to!\n\n Contracts\n\n web3js\n\n 0\n\n 34\n\n Jul 2025\n\n Plans for Generalization of ERC721\n\n Contracts\n\n erc721\n\n 0\n\n 25\n\n Jul 2025\n\n Why doesn’t __Ownable2Step_init do initialization for __Context_init/__Ownable_init?\n\n Support\n\n 6\n\n 105\n\n Jul 2025\n\n How do ShortStrings optimize gas/storage?\n\n Support\n\n 0\n\n 22\n\n Jul 2025","tokens":869,"squid":"ink-security_audits","role":"Sentinel","at":1791260285253,"hash":"9e493dd12a239c019c712b3a72582afd78d3570a"}
{"url":"https://eips.ethereum.org/EIPS/eip-5793","domain":"eips.ethereum.org","title":"EIP-5793: eth/68 - Add tx type to tx announcement","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-5793: eth/68 - Add tx type to tx announcement\n\n Adds the transaction type and transaction size to tx announcement messages in the wire protocol\n\n Authors\n Marius van der Wijden (@MariusVanDerWijden)\n\n Created\n 2022-10-18\n\n Requires\n\n EIP-2464, \n\n EIP-2481, \n\n EIP-4938\n\n Abstract\n\nThe Ethereum Wire Protocol defines request and response messages for exchanging data between clients. The NewPooledTransactionHashes message announces transactions available in the node. This EIP extends this announcement message such that beside the transaction hashes, the node sends the transaction types and their sizes (as defined in EIP-2718) as well.\n\n Motivation\n\nThe NewPooledTransactionHashes message announces transaction hashes, allowing the peer to selectively fetch transactions it does not yet have.\n\nEIP-4844 introduces a new transaction type for blob transactions. Since these blob transactions are large, naively broadcasting them to sqrt(peers) could significantly increase bandwidth requirements. Adding the transaction type and the size to the announcement message will allow nodes to select which transactions they want to fetch and also allow them to load balance or throttle peers based on past behavior.\n\nThe added metadata fields will also enable future - upgradeless - protocol tweaks to prevent certain transaction type (e.g. blob transactions) or certain transaction sizes (e.g. 128KB+) from being blindly broadcast to many peers. Enforcing announcements only and retrieval on demand would ensure a much more predictable networking behavior, limiting the amplification effect of transaction propagation DoS attack.\n\n Specification\n\nModify the NewPooledTransactionHashes (0x08) message:\n\n (eth/67): [hash_0: B_32, hash_1: B_32, ...]\n (eth/68): [types: B, [size_0: P, size_1: P, ...], [hash_0: B_32, hash_1: B_32, ...]]\n\nThe new types element refers to the transaction types of the announced hashes. Note the\ntransaction types are packed as a ‘byte array’ instead of a list.\n\nThe size_0, size_1 etc. elements refer to the transaction sizes of the announced hashes.\n\n Rationale\n\nThis change will make the eth protocol future-proof for new transaction types that might not be relevant for all nodes. It gives the receiving node better control over the data it fetches from the peer as well as allow throttling the download of specific types.\n\nThe types message element is a byte array because early implementations of this EIP\nerroneously implemented it that way. It was later decided to keep this behavior in order\nto minimize work.\n\n Backwards Compatibility\n\nThis EIP changes the eth protocol and requires rolling out a new version, eth/68. Supporting multiple versions of a wire protocol is possible. Rolling out a new version does not break older clients immediately, since they can keep using protocol version eth/67.\n\nThis EIP does not change consensus rules of the EVM and does not require a hard fork.\n\n Security Considerations\n\nNone\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Marius van der Wijden (@MariusVanDerWijden), \"EIP-5793: eth/68 - Add tx type to tx announcement,\" Ethereum Improvement Proposals, no. 5793, October 2022. Available: https://eips.ethereum.org/EIPS/eip-5793.","tokens":825,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260292175,"hash":"163a8cf32986fd05b2286dd46a8c0258b8336b70"}
{"url":"https://ethereum.org/developers/tools/","domain":"ethereum.org","title":"Developer builder resources | ⁦ethereum.org⁩","text":"Resources found: 440 / 440Contract tooling(88)Contract frameworks(11)Ape FrameworkThe smart contract development tool for Pythonistas, Data Scientists, and Security ProfessionalsScaffold-ETH 2Scaffold-ETH 2 is a Next.js plus Hardhat or Foundry starter with wallet hooks, hot contract reload, local faucet utilities, and extension modules for full-stack dapp deployment.HuffHuff is a low-level assembly language and compiler for writing hand-optimized EVM bytecode, with development continuing in huff2. Builders reach for it when bytecode has to be tuned by hand.BrownieA Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.Remix ProjectA rich and accessible Web3 toolset for learning, building, and testing on multiple chainsStylus SDK (Rust)The Stylus SDK is the Rust SDK for writing smart contracts that run in Arbitrum's Stylus environment alongside the EVM. Rust builders use it when contract logic should be written in Rust rather than Solidity.BuildBearBuildBear is a hosted service that spins up a private testnet sandbox mirroring a real chain such as Ethereum, Polygon, BSC, or Arbitrum. Builders point tests at it to work against a private fork with real chain state.@nomicfoundation/slangslang from the Nomic Foundation is a modular Solidity compiler frontend with a parser, concrete syntax tree, and bindings. Builders import it when writing a linter, formatter, or other tool that has to understand Solidity source.WakeWake is a Python framework for testing, fuzzing, and static analysis of Solidity projects. Builders reach for it when they want to write contract tests and fuzzing campaigns in Python and run analysis over the same codebase.py-solc-xpy-solc-x is a Python wrapper and version manager for the solc Solidity compiler, used by Brownie and Ape style test suites. Python builders install it to fetch and switch compiler versions from their own scripts.MoccasinMoccasin is Cyfrin's Python-first workflow on Titanoboa for testing, fuzzing, and deploying Vyper written smart contracts.Deployment & devops(25)HardhatHardhat is a development environment to build and deploy your Ethereum softwareFoundryFoundry is a fast, portable Rust toolchain for Ethereum smart contract engineering that manages dependencies, compiles Solidity, runs fuzz and unit tests, deploys contracts, and drives scripted chain interaction from the terminal or Solidity automation scripts.PoWFaucetPoWFaucet is a modular testnet faucet for EVM chains with anti-abuse methods including a mining puzzle, captcha, IP limits, and Gitcoin Passport, and it backs the Sepolia proof-of-work faucet. Teams running a testnet self-host it to hand out test ETH without giving it all to one address.hardhat-deployhardhat-deploy is a Hardhat plugin for replicable deployments with named accounts, proxies, and diamonds. Builders install it when deployments must be repeatable across networks and track upgradeable contracts.eth-dockereth-docker is a Dockerized stack for deploying and managing execution, consensus, and validator clients on mainnet. Node operators use it to run a full node setup from configuration files instead of hand-installed binaries.Kurtosis ethereum-packageThe Kurtosis ethereum-package spins up reproducible multi-client Ethereum devnets, including mev-boost and supporting tooling. Builders run it when they need a local network that mirrors a real client mix.KurtosisKurtosis packages reproducible multi-service devnets so you can spin up realistic Ethereum or rollup stacks for integration tests faster than hand-maintained compose files.DAppNodeDAppNode is an operating system with an app store for running Ethereum execution and consensus clients and other node software on your own hardware. Someone setting up a home node installs it and picks client packages instead of configuring each service by hand.simple-optimism-nodesimple-optimism-node is a one-command Docker setup for running an OP Stack node. Builders run it to get their own Optimism node, in the same way eth-docker covers mainnet clients.ethereum-helm-chartsethereum-helm-charts are Helm charts from ethPandaOps for running Ethereum execution and consensus clients and related infrastructure on Kubernetes. Teams add them to a cluster rather than writing client manifests themselves.Chainlink FaucetsChainlink Faucets dispense testnet ETH and LINK across the supported test networks. Builders use them to fund an account before deploying and testing contracts on a testnet.DeckerDecker is a TypeScript CLI for creating configurable local Ethereum devnets with execution and consensus clients, relays, and block builders. Teams use its recipes for integration tests and infrastructure development.etherealethereal is a Go command line tool for everyday Ethereum tasks, including sending transactions, managing ENS records, transferring tokens, and inspecting accounts. Builders install it for one-off operations that do not justify a script.ImmunefiImmunefi is a bug bounty platform where projects post rewards for whitehats who find and responsibly disclose contract vulnerabilities. Teams list a program there to give researchers a paid route to report issues.rockethrocketh is a deployment and test harness for Ethereum contracts built around viem, keeping one record of deployments per network so scripts and tests agree. Builders use it when they want repeatable deployments without Hardhat, which the hardhat-deploy plugin wraps over the same code.Rocket Pool Smart NodeRocket Pool Smart Node is the command line package node operators run to set up and manage a Rocket Pool minipool, wrapping execution and consensus clients plus validator duties.CreateXCreateX is pcaversaccio's trustless universal deployer that wraps CREATE, CREATE2, and CREATE3-style flows so teams can launch contracts from predictable addresses without bespoke factory code.foundry-toolchain (GitHub Action)foundry-toolchain is the official GitHub Action that installs Foundry in continuous integration. Builders add it to a workflow so forge test and forge script run on every pull request.SedgeSedge is a command line setup tool from Nethermind that generates docker-compose configurations for execution, consensus, and validator client combinations. Builders run it to get a working node setup without writing the compose files.xdeployerHardhat plugin to deploy your smart contracts across multiple EVM chains with the same deterministic address. A total of 133 EVM chains are currently supported, including (almost) all OP-stack-powered chains.ethereum-genesis-generatorethereum-genesis-generator creates execution and consensus layer genesis state for a testnet and serves it over a web server. Devnet and rollup teams run it to produce the genesis files for a custom network.Create2DeployerCreate2Deployer is a minimal factory contract from pcaversaccio that wraps the CREATE2 opcode with safety checks so teams can deploy counterfactual contracts at deterministic addresses.txtxTxtx turns the stress, pain and tears of Smart Contract Infrastructure management by introducing Crypto Infrastructure as Code. Runbooks are the blueprint for Engineering Excellence, setting the new standard for Web3 Infrastructures.CannonCannon is a DevOps tool for protocols on Ethereum. It manages smart contract deployment and configuration for local development and live networks.EthPillarEthPillar is a setup script and terminal interface for installing and managing an Ethereum staking node with execution, consensus and MEV-Boost clients. Solo stakers run it to stand up a node without editing client configuration by hand.Smart contract libraries & utilities(27)OpenZeppelin ContractsOpenZeppelin Contracts are the go-to library for smart contract development.SoliditySolidity is an object-oriented, high-level language for implementing smart contracts.VyperPythonic Smart Contract Language for the EVMSolaritySolidity-Oriented Development ToolingSafe Smart Account (Gnosis Safe)Safe Smart Account is the widely deployed set of modular multisig smart-account contracts behind Safe. Wallet and treasury builders deploy or extend it to add multisignature control and account modules.SoladySolady by Vectorized collects aggressively optimized Solidity snippets from Merkle proofs to compression helpers, wrapping careful inline assembly in approachable APIs so advanced developers can ship gas-efficient patterns while learning cutting-edge optimization techniques from a living reference library.SolmateSolmate is a modern, opinionated collection of gas-optimized Solidity building blocks and utilities for smart contract development.Fe LanguageFe is a Rust-inspired language targeting the EVM; today you can explore Fe v2's type system via CLI or editor tooling even while bytecode generation is still evolving.SolhintSolhint is a Solidity linter you wire into editors or CI to enforce style rules and catch footgun patterns early.Vscode Solidity ExtensionJuan Blanco's VS Code Solidity extension adds syntax highlighting, compile commands, hover metadata, quick fixes, monorepo detection, optional Nethereum codegen, lint integration, and an LSP server.ERC721AERC721A is a gas-optimized ERC-721 implementation with cheap consecutive batch minting. Builders import it when an NFT contract mints several tokens to the same address at once and minting cost matters.IntelliJ SoliditySolidity plugin for IntelliJWhatsABIWhatsABI recovers selectors, proxies, and partial ABIs from bytecode alone-use it in wallets, explorers, or local tools when verified source is missing but you still need calldata decoding.PRBMathPRBMath is a smart contract library that adds support for fixed-point types and advanced math functions like logarithms and exponentials in Solidity. Operating with 18-decimal numbers, PRBMath is at the same time gas efficient and user-friendly.Solc-selectSolc-select is a command line utility for quickly installing and switching between Solidity compiler versions.Multicall3Multicall3 is the canonical contract for batching many reads or writes into a single transaction. Builders call it from contracts and scripts to fetch or update state across several contracts in one round trip.SolarBlazingly fast, modular Solidity compiler written in Rust by Paradigm. Designed as a contributor-friendly compiler stack for faster builds and better diagnostics.snekmateState-of-the-art, highly opinionated, hyper-optimised, and secureVyper smart contract building blocks.Prettier SolidityA Prettier plugin for automatically formatting your Solidity code.SolidState SoliditySolidState Solidity is an upgradeable-first contract library built around the diamond pattern of EIP-2535. Teams import it when contracts are organized as diamond facets from the start.weirollweiroll is an operation-chaining scripting language and set of contracts for composing many EVM calls into one transaction. Teams building call-routing or batching systems use it to express the call sequence as a script.Solidity Bytes Arrays Utils LibrarySolidity Bytes Utils is a classic library for concatenating, slicing, and casting dynamic bytes arrays in Solidity memory or storage-long maintained and widely forked across major protocols.solxA gas-efficient Solidity compiler for Ethereum powered by LLVM from the ZKsync team and collaborators. Works as a drop-in replacement for solc in workflows like Foundry and Hardhat.ABDKMath64x64ABDKMath64x64 is a Solidity library for 64.64-bit binary fixed-point math. Builders import it when a contract needs fixed-point arithmetic that Solidity does not provide natively.ERC721A-UpgradeableERC721A-Upgradeable is the proxy-upgradeable variant of the ERC721A implementation. Builders import it when a proxy-based NFT contract needs the batch minting design of ERC721A.DiamondscaffoldDiamondscaffold is a CLI tool designed to scaffold EIP-2535 diamond projects with an opinionated layout and scripts, making it faster to stand up modular upgradeable proxies.solidity-docgensolidity-docgen generates Markdown documentation for a Solidity project from its NatSpec comments. Teams run it so published docs stay in step with the contract source.ZK circuits & privacy(25)ZK EmailZK Email provides circuits and SDKs for proving facts about redacted email transcripts onchain. Useful when you want privacy-preserving identity or receipt checks without doxxing inboxes.SP1 (Succinct)SP1 from Succinct is a zero-knowledge virtual machine that proves correct execution of RISC-V programs, and it is used to generate proofs for rollups and bridges. Teams compile a Rust program with it when a proof must stand in for re-executing that program onchain.snarkjssnarkjs is a JavaScript and CLI toolkit for generating and verifying zkSNARK proofs, and for running common proving workflows in Node.js and the browser.CircomCircom is a domain-specific language and compiler for writing and compiling arithmetic circuits used in zero-knowledge proof systems.SemaphoreSemaphore is a zero-knowledge protocol for private group membership proofs, enabling anonymous signaling and authentication without revealing identity.Self ProtocolSelf Protocol provides open identity and proof primitives builders can embed when they need privacy-preserving verification flows tied to wallets or credentials.zkTLS/ TLSNotaryzkTLS / TLSNotary is an open protocol for proving properties of TLS sessions with MPC so verifiers can trust transcripts without seeing full plaintext.RISC Zero risc0-ethereumrisc0-ethereum holds the integration libraries and verifier contracts for using the RISC Zero zkVM with Ethereum and other EVM chains. Teams proving computation off chain import these crates to settle the resulting proofs onchain.MACIMACI (Minimal Anti-Collusion Infrastructure) uses zero-knowledge proofs to enable collusion-resistant, private voting and signaling systems on Ethereum.gnark-cryptognark-crypto provides elliptic curve and pairing cryptography for BN, BLS12, BLS24, and BW6 curves, and it is the backend of the gnark SNARK library. Go builders import it directly for curve and pairing math.MoproA toolkit that makes client-side zero-knowledge proving on mobile simple. Connects ZK proof systems (Halo2, Circom) to generate iOS, Android, and browser bindings, leveraging mobile GPU for improved performance.ZK-KitA monorepo of reusable zero-knowledge libraries across multiple languages (JavaScript, Solidity, Rust, Noir), offering well-tested implementations of cryptographic primitives like Merkle trees, Poseidon hash, and more.SonobeA modular folding library supporting multiple folding schemes (Nova, HyperNova, ProtoGalaxy, CycleFold) and decider backends (Groth16, KZG) for Incremental Verifiable Computation. Supports Arkworks, Circom, Noir, and Noname frontends.Anon AadhaarTools for building privacy-preserving applications using Indian government Aadhaar ID cards. Provides ZK circuits, TypeScript, Solidity, and React libraries to enable Aadhaar holders to prove residency without revealing personal data.ZKPassportPrivate identity verification using zero-knowledge proofs. Verify age, country, or proof of personhood without revealing any personal information. Mobile-first design with SDK for integration and onchain registry contracts.Halo2PSE's re-architected fork of Zcash's Halo2 PLONK proof system, featuring a KZG backend with Solidity verifier for economical L1 verification, support for multiple elliptic curves, and decoupled frontend/backend architecture.p0tionA toolkit for Groth16 Phase 2 Trusted Setup ceremonies. Helps developers create and manage trusted setups for ZK applications, with a companion webapp (DefinitelySetup) for monitoring and participation.arkworks algebraarkworks algebra is a set of Rust libraries for finite field, elliptic curve, and polynomial arithmetic, and it is the math layer under many SNARK and STARK toolchains. Rust builders add the ark crates when writing proving code from the ground up.LambdaworksLambdaworks is a Rust library of SNARK and STARK prover components that can be used piecemeal or assembled into a custom proving system. Teams pull its crates when building their own prover rather than adopting a finished one.op-succinctop-succinct is a proving engine that generates SP1 validity proofs for OP Stack rollups. Rollup teams deploy it to turn an OP Stack chain into a validity proof rollup, running it as a separate service.Plonky3Plonky3 is a toolkit of polynomial IOP building blocks for constructing custom SNARK and STARK proving systems, and several zkVM projects build on it. Rust builders add the p3 crates when writing their own proving system.powdrpowdr is a toolkit for accelerating and hardening zkVMs by moving specific computations into custom circuits. Teams running a zkVM use it to generate custom precompiles and check constraints, and its authors still describe the code as experimental.rsp (Succinct)rsp from Succinct generates zero-knowledge proofs of Ethereum and OP Stack block execution, built on Reth. Its authors describe it as a minimal work in progress that is not meant for production, so it mainly serves teams already building on SP1.snark-verifier (Axiom)snark-verifier generates gas-efficient onchain verifiers for halo2 SNARKs and is maintained by Axiom, forked from the original PSE repository. halo2 developers import the crate to produce the Solidity verifier that checks their proofs onchain.Perpetual Powers of TauAn ongoing (since 2019) zk-SNARK trusted setup ceremony for circuits up to 2^28 constraints, generating 530M+ powers of tau. A multi-party ceremony where security holds as long as one participant is honest.Security & testing(56)Debugging & inspection(31)Semgrep (smart-contracts rules)Semgrep is a pattern-based static analysis tool with rulesets for Solidity vulnerabilities. Builders run those rules over a codebase to catch known vulnerable patterns and style issues before review.heimdall-rsheimdall-rs is a Rust EVM toolkit that disassembles bytecode, decompiles contracts, generates control flow graphs, and decodes calldata and traces. Builders reach for it when they need to understand a contract that has no published source.sol2umlsol2uml generates UML class and storage-layout diagrams from Solidity source or from verified contracts. Builders run it to see contract relationships and how state variables are packed into storage.CodeTracerCodeTracer is a user-friendly time-traveling debugger designed to support a wide range of web3 programming languages.EDB: The Ethereum Project DebuggerEDB is a source-level debugger for Solidity execution with stepping, locals, watches, and breakpoints when you need IDE-grade visibility into contract behavior onchain or in tests.ABI Calldata Layout VisualizerThe ABI Calldata Layout Visualizer decodes ABI calldata and draws its byte layout, showing where heads, tails, and offsets sit in the encoded payload. Builders open it when a plain decoder does not explain why an encoding is wrong.EVMConnectorEVMConnector is a browser workspace for calling contract functions on any EVM chain, with saved contracts and shareable call links. Builders use it to drive a contract without writing a script.HashEx ABI EncoderThe HashEx ABI Encoder is a web form that ABI-encodes constructor and function arguments from a pasted signature and values. Builders use it when they need encoded arguments and are not at a terminal.Radar (Auditware)Radar, from Auditware, is a static analysis tool that covers Solidity as well as Rust, Anchor, and Stylus contracts. Auditors run it to get findings across a mixed contract codebase.recursive calldata decoderA calldata decoder that also unwraps nested function calls. Builders open it when a flat decoder leaves the inner calls of a batched or forwarded transaction unreadable.SmartContractGUISmartContractGUI turns an uploaded ABI into an interface for reading from and writing to that contract on any EVM chain. Builders use it when they have an ABI but no frontend.sol-profilersol-profiler is a command line tool that lists a Solidity contract's methods with their visibility, mutability and modifiers. Reviewers run it to see the surface of a contract at a glance.TenderlyTenderly provides transaction simulation, trace debugging, alerting, and Virtual TestNets for contracts. Builders use it to replay a failing transaction, watch deployed contracts, and test against a forked network.Tenderly CLIThe Tenderly CLI is the command line client for Tenderly, pushing contracts for verification and driving error tracking, monitoring, and alerting. Builders install it to run those steps from a terminal or a continuous integration job.Web3ClientWeb3Client is a browser tool for creating, testing, and sharing contract ABIs and the calls made against them. Builders use it to work out a call and hand the result to someone else.revm-inspectorsrevm-inspectors is a Rust crate of EVM execution hooks and tracing built on revm, and it powers call tracing in Reth and Foundry. Rust builders import it to build their own tracers and debuggers.pyevmasmpyevmasm is a Python disassembler and assembler for EVM bytecode from Trail of Bits. Analysis scripts import it to turn bytecode into instructions and back.EVMoleEVMole extracts function selectors, arguments, and control flow from raw EVM bytecode, including contracts with no verified source. Builders point it at an unknown contract to work out what its functions take.Simbolik - Solidity DebuggerSimbolik is a powerful Solidity debugger that combines traditional breakpoint debugging with symbolic execution, enabling developers to explore every possible execution path and uncover vulnerabilities with precision. Available as a VSCode extension, Simbolik integrates seamlessly into existing workflows, offering breakpoint-style debugging, Solidity and EVM-level inspection, and formal verification capabilities.Abi NinjaAbi Ninja is a browser UI for calling contracts with known ABIs, pasted ABIs, or decompiled bytecode, with proxy-aware reads across many networks including your locally running Hardhat or Anvil node.hardhat-tracerhardhat-tracer is a Hardhat plugin that prints internal calls, events, and storage operations for a transaction in the console. Hardhat users install it to see what actually happened inside a failing test transaction.geas (Good Ethereum Assembler)geas, the Good Ethereum Assembler, is an assembler for writing raw EVM bytecode by hand, maintained by a go-ethereum core developer. It is used for EIP test cases and other low-level contract work.evm-storageevm-storage turns a transaction hash into readable state diffs and can list a contract's full storage. Builders install the command line tool when they need to see exactly which storage slots a call changed.scopelintscopelint is an opinionated formatter and linter for Foundry Solidity projects. Builders install it to hold a codebase to the ScopeLift conventions.WalnutWeb-based transaction debugger and simulator for the EVM. Open-source and self-hostable. Inspect variable states at every step, simulate transactions before deploying, and profile gas usage. Supports any RPC provider.forkyforky is a fork choice viewer for the Ethereum beacon chain. Consensus client developers self-host it or use the public instances to see and debug fork choice behavior on mainnet and testnets.tracoortracoor is an explorer for beacon states and execution traces. Client and protocol developers self-host it to inspect block and state traces on devnets and testnets.4byte4byte.directory maps four-byte function selectors and 32-byte event-signature hashes to their human-readable signatures. Builders query it when decoding calldata or logs from contracts without a published ABI.viem-tracerviem-tracer augments a Viem client so failed ethestimateGas and ethsendTransaction calls automatically include human-readable trace output decoded with sourcify.dev, and it adds typed helpers around debug_traceCall so developers can inspect execution without leaving their existing RPC stack.hardhat-gas-reporterhardhat-gas-reporter is a Hardhat plugin that reports gas used by each function call and deployment while the test suite runs, with optional fiat cost estimates. Hardhat users add it when they need to see the gas impact of a change in the test output.SlippySlippy is a Solidity linter for static analysis of smart contracts. Teams install the npm package to lint contracts as part of a build.Fuzz/Property testing(18)ChimeraChimera is a framework to write Solidity tests in foundry and be able to reuse them with other Open Source Tools such as Echidna, Medusa, Halmos and KontrolSlitherSlither is Trail of Bits' Python static analysis engine for Solidity and Vyper: run it in CI to fire detectors, print structural views of contracts, or script custom checks over whole codebases.EchidnaEchidna is a property-based and grammar fuzzer for Ethereum smart contracts. Builders and auditors write properties with it to find inputs that break contract invariants.SynpressSynpress layers Playwright with Ethereum-aware browser automation so you can end-to-end test dapps, including wallet popups and chain switches, in CI.AderynAderyn is Cyfrin's open-source, Rust-based solidity smart contract static analyzer designed to help protocol engineers and security researchers find vulnerabilities in Solidity code basesItyFuzzItyFuzz is a bytecode-level smart-contract fuzzer that combines fuzzing with symbolic analysis. Builders and auditors run it against EVM bytecode when source-level fuzzing is not enough or no source is available.MedusaMedusa is a stateful smart contract fuzzer inspired by Echidna. It provides parallelized fuzz testing of smart contracts and the verification of advanced smart contract invariants.eth-testereth-tester is a pluggable in-memory Ethereum backend used by web3.py for fast unit tests. Python builders import it when tests should run against a simulated chain instead of a node.TitanoboaTitanoboa is an interactive Vyper interpreter and test harness for fast feedback loops when you are experimenting with contracts outside a full Foundry loop.goevmlabgoevmlab is an EVM fuzzing and differential testing lab built by a go-ethereum core developer. EVM implementers use it to fuzz their own implementation and compare its behavior against others to find divergences.HiveHive is an end-to-end integration test harness that runs Ethereum clients in Docker across simulator scenarios. Client teams use it to check that implementations agree with each other.solidity-coveragesolidity-coverage provides smart-contract code coverage for the Hardhat developer platform. It's highly accurate, supports full viaIR solidity compilation and a large set of solidity-specific code branch patterns. It's installed on ~230k Github projects and is downloaded ~100k times a week from NPM.hevmhevm is an open source, state-of-the art, fast symbolic and concrete EVM execution engine that can find issues in smart contracts. Through its symbolic execution and analysis system, hevm can symbolically, semi-concretely, or concretely execute contracts to find bugs, or compare two different contracts for discrepancies, performing equivalence checking.Crytic-PropertiesCrytic-Properties is a suite of re-usable security tests for some of the most widely used token standards such as ERC20, ERC721, ERC4626, and more.contender (Flashbots)contender from Flashbots is a load-testing tool that floods EVM execution nodes over JSON-RPC and benchmarks the results. Teams benchmarking a client point it at an endpoint to generate load and measure throughput.bulloakA smart contract test generator based on the Branching Tree Technique.spamoorspamoor is a configurable Ethereum transaction generator for load-testing testnets and devnets with realistic traffic. Teams point it at a network to see how it behaves under sustained transaction volume.AssertoorAssertoor runs configurable checks and assertions against a live Ethereum devnet to validate its behavior. Client and devnet teams use it to confirm a running network is healthy, in the same family as Hive.Formal verification(7)K Semantics of the Ethereum Virtual Machine (EVM)KEVM is the K-framework executable semantics of the EVM: point it at bytecode when you need conformance-checked execution, symbolic exploration, gas reasoning, or proofs that track Ethereum's rules closely.haxhax is a tool for high assurance translations of a large subset of Rust into formal languages such as F* or Rocq.Certora ProverCertora Prover is a cloud formal-verification service that checks specifications written in CVL against deployed contract code. Verification engineers use it to prove that a contract holds stated properties for all inputs.Kontrol - formal verification tool based on Foundry and KEVMKontrol lifts Foundry property tests into KEVM-backed proofs so you can chase formal guarantees with less hand-written specification work than raw KEVM alone.ActAct is Ethereum's declarative specification language and toolchain for describing all behaviors of an EVM program so SMT solvers, theorem provers, or economic analysis tools can reason about bytecode-level correctness and incentive compatibility, including automatic refinement proofs against concrete implementations.VerifereumVerifereum connects Ethereum smart contracts to HOL4-backed theorem proving so you can aim at very strong correctness claims when automated SMT approaches are not enough.Certora AutoProverCertora AutoProver is an AI bot that automates parts of formal verification for smart contracts. Verification engineers use it to generate and run checks with less manual specification work.App integration(124)Core SDKs/libraries(35)Web3jLightweight, modular, reactive Java and Android library for Ethereum. JSON-RPC client API, wallet support, and auto-generated Solidity contract wrappers for deployment and interaction. Includes CLI, Maven/Gradle plugins, and ENS support.web3.pyweb3.py is the open source library that connects Python developers to Ethereum. The same team maintains more than a dozen additional building blocks including py-evm, eth-account, and eth-utils.go-ethereum (ethclient/accounts/abigen)go-ethereum ships Go packages for Ethereum development, including the ethclient RPC client, account and key handling, and abigen for type-safe contract bindings. Go builders import them to talk to nodes and call contracts from generated code.Ethers.jsEthers.js is a compact TypeScript library for scripts, wallets, and services that need predictable JSON-RPC, ABI encoding, and signing helpers in Node or the browser.Viem: TypeScript Interface for EthereumViem is the most used modern TypeScript Interface for Ethereum. Viem provides robust, performant, and type-safe modules to be the foundation for building Web Applications, TypeScript Libraries, Wallets, Backends, Indexers, Scripts, and more, on top of Ethereum.NethereumNethereum is the .Net integration library for Ethereum, simplifying the access and smart contract interaction with Ethereum nodes both public like Geth (or your preferred client) L2 chains like Optimism, Arbitrum (or your preferred L2), any compatible EVM chain (Gnosis, etc) and permissioned chains like Quorum.Rust Libp2prust-libp2p is the reference Rust implementation of libp2p's modular peer-to-peer stack used by Magi on the OP Stack, Lighthouse, Forest, and many other projects that need composable transports, security, pubsub, and discovery primitives for decentralized networking.RevmRevm is a critical component in the Ethereum ecosystem used by builders, toolings, clients and chains.ethereumjs (monorepo)The ethereumjs monorepo holds core JavaScript primitives for Ethereum, including transaction signing, an EVM implementation, RLP encoding, tries, and shared utilities. JavaScript builders import individual packages when they need protocol-level pieces rather than a full client library.web3.swift (Argent)web3.swift from Argent is a Swift library covering Ethereum RPC calls, ABI encoding, and transaction signing. iOS and macOS builders use it to talk to Ethereum from native applications.Safe Protocol Kit (safe-core-sdk)Safe Protocol Kit is the TypeScript SDK of safe-core-sdk for building, signing, and executing Safe multisignature transactions. Builders use it to drive Safe accounts from application or script code.MerkleTreeJSA JavaScript library to construct Merkle Trees and verify proofs.DelphereumDelphereum is a web3 implementation for Delphi that lets Object Pascal desktop and mobile applications sign transactions and read contract state. It is the maintained route to Ethereum for builders working in that language.EthereumexEthereumex is an Elixir JSON-RPC client for Ethereum and the transport layer that higher-level libraries such as Elixir Ethers build on. Elixir builders configure it by name even when they work through a higher-level library.headlongheadlong is a Java library for encoding and decoding contract ABI calldata and RLP, tuned for throughput in JVM services. Java builders add it when a backend has to process a high volume of Ethereum calls.hs-web3hs-web3 is a Haskell library for talking to Ethereum nodes, with contract ABI code generation through Template Haskell. It is the route to Ethereum for builders working in Haskell.ruintruint is a const-generic unsigned integer type for Rust that represents Ethereum's 256-bit words, and it sits under Alloy and Reth. Rust builders add it directly when they need fixed-width big integers.rust-web3rust-web3 is a Rust implementation of the web3 JSON-RPC client with pluggable transports. It predates Alloy and carries no deprecation notice.web3dartweb3dart is an Ethereum client library for Dart and Flutter covering JSON-RPC calls, contract bindings, and local transaction signing. Flutter builders use it as the general client for mobile applications.safe-eth-pysafe-eth-py is the Python SDK from the Safe team for building, signing, and relaying Safe multisig transactions. Python builders use it to drive Safe accounts from backend code.abitypeabitype provides strict TypeScript types and static inference for Ethereum ABIs, and it is the type layer under viem and wagmi. TypeScript builders import it when contract calls should be checked against the ABI at compile time.essential-ethessential-eth is a lightweight JavaScript client library that bundles to roughly a tenth of the size of ethers.js or web3.js. Builders install it when bundle size on the frontend is the constraint.oxox is a low-level TypeScript library of Ethereum primitives covering ABI, RLP, hex, signing, and transactions, and it sits under viem and other wevm tools. Builders import it directly when they want the primitives without the client layer.multicall.pymulticall.py is a Python client that batches many contract calls into a single Multicall aggregate call. Python builders install it to turn hundreds of reads into one RPC request.ethkit (Sequence)ethkit is a Go toolkit for building Ethereum applications from the team behind the Sequence JavaScript SDK. Go builders import it for wallet handling, ABI work, and RPC calls.w3 (Golang JSON-RPC client)w3 is a modular Go JSON-RPC client for Ethereum with first-class ABI support and request batching. Go builders import it when contract calls should be typed and many requests sent in one batch.Elixir EthersElixir Ethers is a library for calling and decoding Ethereum smart contracts from Elixir. Builders use it when the backend is written in Elixir, where options are few.ZabiZabi is a Zig library for interacting with Ethereum and other EVM chains, providing JSON-RPC clients, ABI utilities, signers, and wallet primitives.ethers-ktethers-kt is an async Kotlin library for interacting with EVM chains, targeting the JVM and Android. Kotlin builders use it to read contracts and send transactions from server or mobile code.MulticallerMulticaller from Vectorized is a collection of gas-optimized multicall-style contracts that batch arbitrary external calls while preserving the original msg.sender context for each callee, making complex router or aggregator flows cheaper and safer on EVM chains.libethclibethc is an open-source ethereum library for C/C++VoltaireVoltaire is a modern general-purpose Ethereum library for TypeScript, Zig, C, and Swift. Type-safe primitives, WASM-accelerated performance, and designed for AI-assisted development.ethereum-bloom-filtersA lightweight bloom filter client which allows you to test ethereum blooms for fast checks of set membership.Gelato Automate SDKAutomate your smart contracts using Automate SDKprimitive-typesprimitive-types provides the shared Rust U256, H160, and H256 types used across Ethereum and Substrate node and tooling codebases. Rust builders add it when their code has to carry Ethereum-sized integers and hashes.Frontend/integration tooling(8)Curvegrid MultiBaasCurvegrid MultiBaas is a hosted control plane with REST APIs for deploying and operating multi-chain EVM backends when you want managed keys, indexing hooks, and dashboards without building all ops in-house.Wagmi: Reactive primitives for Ethereum appsWagmi is a React hook layer on top of Viem for reading, writing, and caching Ethereum state in frontends without rebuilding wallet plumbing each project.Impersonator.xyzImpersonator.xyz lets developers connect to dapps through WalletConnect, an iframe shim, or a browser extension while masquerading as any address without holding private keys, which is ideal for QA teams that need to preview balances, capture calldata for Tenderly simulations, or regression-test wallet flows safely.ant-design-web3ant-design-web3 is a React component library from the Ant Design team for wallet connection and account interfaces. Builders drop it into a React application as an alternative to RainbowKit or ConnectKit.OnchainKitOnchainKit is a set of React components from Coinbase for wallets, transactions, identity, and other onchain interfaces. React builders use it to assemble an onchain frontend from prebuilt pieces.Swiss-Knife.xyzSwiss-Knife aggregates all the useful EVM tools in one place to ease developer experience while they are debugging or building new stuff.NexthNexth is a Next.js starter kit wired up with viem, wagmi, Sign-In with Ethereum, and Tailwind. Builders clone it to start from a working frontend rather than assembling the same pieces again.One Click DappOne Click Dapp generates a hosted web interface for a deployed contract from its ABI and address. Builders use it to give a contract a usable interface without writing frontend code.Wallet integration & auth(20)Human PassportHuman Passport aggregates identity credentials, called Stamps, into one Unique Humanity Score per wallet, so projects can check that an address is a distinct person before an airdrop, grant round, vote or signup. Read scores from the REST API or drop in the Passport Embed React component.thirdwebthirdweb is a full stack, open-source web3 development platform with frontend, backend, and onchain tools to build complete web3 apps - on every EVM chain.Modular AccountAlchemy's Modular Account is a maximally modular, upgradeable smart contract account that is compatible with ERC-4337 and ERC-6900. Alchemy's Modular Account most efficient smart account on the market with release of v2 released in feb 2025Ethereum Attestation Service (EAS)EAS is an infrastructure public good for making attestations onchain or offchain about anything. Attestations are digital signatures on structured pieces of data used to build more trust online and onchain.Coinbase Wallet SDKCoinbase Wallet SDK connects applications to Coinbase Wallet through the injected provider and the mobile WalletLink flow. Builders use it to support Coinbase Wallet users on web and mobile.Reown AppKit (ex-Web3Modal/WalletConnect SDK)Reown AppKit, formerly Web3Modal and the WalletConnect SDK, is a wallet-connection SDK with a hosted relay, support for over 700 wallets, and embedded logins. Application builders use it to cover both external wallets and embedded sign-in from one integration.Web3-OnboardWeb3-Onboard is a framework-agnostic wallet-connection library supporting more than 35 wallets and the EIP-1193, 1102, 3085 and 3326 standards, started by Blocknative and now maintained by thirdweb. Builders install it when the frontend is not React or must cover many wallet providers.RainbowKitRainbowKit is a customizable React wallet-connection interface built on wagmi. React builders add it when an application needs a ready-made connect flow instead of wiring wallet selection by hand.ConnectKitConnectKit provides React wallet-connection components built on wagmi. React builders drop it in when they want prebuilt connect buttons and modals for an application.Web3AuthWeb3Auth is an MPC and threshold key-management SDK that backs seedless wallets created from a social login. Builders use it when users should sign in with an existing account instead of a seed phrase.Magic (Magic.link)Magic is an embedded non-custodial wallet SDK with email and social login and delegated key management. Builders integrate it to give users a wallet behind a familiar login flow.DynamicDynamic is an SDK covering wallet connection, embedded MPC wallets, and application authentication. Builders choose it when an application must serve both existing wallet users and new users who need one created.ethr-did-resolverethr-did-resolver resolves decentralized identifiers anchored to Ethereum addresses. Applications that handle ethr identifiers install it to look up and manage those records.mipdmipd is a set of TypeScript utilities implementing EIP-6963 multi injected provider discovery for detecting installed browser wallets. Builders install it on its own when they need wallet discovery without pulling in wagmi.PrivyPrivy provides embedded wallet and authentication SDKs with configurable custody and signing permissions. Builders use it to create wallets during sign-up and support email, social, or passkey login.React Native PasskeysReact Native Passkeys exposes one WebAuthn-shaped passkey API across iOS, Android, and Web targets so you can reuse existing auth backends while shipping native mobile wallet or consumer apps.MetaMask ConnectMetaMask Connect is the SDK that connects web, mobile and game applications to the MetaMask wallet, replacing the deprecated MetaMask SDK with direct wallet communication and multichain support. Builders install the connect-evm package to reach MetaMask users from any frontend.@slicekit/erc8128TypeScript library to sign and verify HTTP requests with Ethereum wallets using ERC-8128 (RFC 9421 HTTP Message Signatures extension), enabling wallet-based authentication and request integrity.Variance_dartVariance_dart is a Dart SDK stack for passkey-first wallets, EIP-1271 signing flows, and ENSIP-15 normalization when you are shipping Flutter or mobile clients against EVM chains.w3pkPasswordless Web3 authentication SDK with encrypted wallets and privacy features.page-developers-tools-subcategory-cryptography-key-management-title(21)noble cryptographynoble cryptography is a family of minimal-dependency TypeScript cryptographic libraries that prioritize readable source, signed releases, and transparent npm builds, and they underpin most modern JavaScript wallets including MetaMask, Rabby, Rainbow, and many SDKs across the ecosystem.blstblst is a multilingual BLS12-381 signature library and the BLS implementation behind most Ethereum consensus clients. Builders link against it in Rust, C, or Go when writing validator or consensus tooling.@ledgerhq/hw-app-ethThe Ledger hw-app-eth package is the JavaScript API for signing Ethereum transactions and messages with a Ledger device, and it sits behind the Ledger connectors in wagmi and viem. Wallet and application builders import it to add hardware wallet signing.eth-cryptoeth-crypto is a set of JavaScript helpers for signing, verifying, recovering addresses, and ECIES encryption alongside ethers or web3. Builders import it for one-off cryptographic steps that the client libraries do not expose directly.py_eccpy_ecc is a Python library for elliptic curve pairing operations over bn128 and BLS12-381, used by py-evm and other Python tooling. Builders import it for precompile or BLS work in Python.@noble/secp256k1noble secp256k1 is a standalone pure JavaScript library for secp256k1 signing and ECDH, used by many wallets and libraries. Builders install it on its own when they need signing without the wider noble curves package.js-ethereum-cryptographyjs-ethereum-cryptography is an audited JavaScript package bundling the hashing and curve primitives that tooling such as ethers.js and web3.js builds on. Builders install it directly when they need keccak, secp256k1, or BIP-39 work without a full client library.k256 (RustCrypto)k256 from RustCrypto is a pure Rust secp256k1 implementation covering ECDSA signing, verification, public key recovery, Schnorr, and ECDH, and it sits under reth, Alloy, and most Rust tooling. Rust builders depend on it directly when they handle signatures themselves.Web3SignerWeb3Signer is a remote signing service that keeps keys in a vault or hardware security module. Node and validator operators run it so signing happens outside the client process.OKX js-wallet-sdkThe OKX js-wallet-sdk is a TypeScript signature SDK covering Bitcoin, Ethereum, Solana, Cosmos, and other chains. Builders install it to derive keys and sign transactions for several chains through one API.Trezor ConnectTrezor Connect is a JavaScript SDK for integrating Trezor hardware wallet signing, including Ethereum, into applications and wallets. Builders use it when users should sign with a Trezor device.c-kzg-4844c-kzg-4844 is the reference C implementation, with Rust bindings, of the KZG polynomial commitment scheme used for EIP-4844 and EIP-7594 blobs, and it is embedded in most execution and consensus clients. Rollup and blob tooling imports the bindings to produce KZG commitments and proofs.Fireblocks SDKThe Fireblocks SDK connects applications to Fireblocks' MPC wallet infrastructure for signing, transfers, and treasury operations. Builders use it to automate transactions and approval policies for wallets managed through Fireblocks.TurnkeyTurnkey offers an API and SDK for secure key generation and transaction signing backed by trusted execution environments. Builders use it to create and operate wallet infrastructure without holding raw private keys in their own code.eth-keyseth-keys is a Python library for secp256k1 keys and signatures, and it sits under eth-account and web3.py. Python builders import it when they need key and signature operations directly.micro-eth-signermicro-eth-signer is a minimal JavaScript library for building and signing Ethereum transactions, built on the audited noble cryptography libraries by the same author. Builders install it when a small signing dependency matters more than a full client library.coins-bip32coins-bip32 is a Rust library for BIP-32 hierarchical deterministic key derivation, used by ethers-rs and other Rust wallets and signers. Rust builders add it when an application derives keys from a seed.eciesjseciesjs implements the Elliptic Curve Integrated Encryption Scheme for secp256k1 in JavaScript. Builders import it to encrypt and decrypt data against an Ethereum-style keypair.keypo CLIkeypo is a local-first command line tool for hardware-bound key management and encrypted secret storage, aimed at AI agents that hold credentials. It installs from a Homebrew tap on macOS.Lit ProtocolLit Protocol is a decentralized network for threshold key management with programmable signing through its programmable key pairs. Builders use its SDK when signing or decryption should follow rules enforced by a network rather than a single key holder.mcl (herumi)mcl from herumi is a portable pairing-based cryptography library used for BLS signature operations by several Ethereum consensus clients. Builders link against it for BLS work in C++ or Go.Account abstraction & tx orchestration(28)eth-infinitism account-abstraction (SimpleAccount + SDK)The eth-infinitism account-abstraction repository holds the reference ERC-4337 contracts, including SimpleAccount, plus a TypeScript SDK from the authors of the specification. Builders use it as the baseline implementation when creating ERC-4337 accounts.Alchemy aa-sdk / Account KitAlchemy aa-sdk, shipped as Account Kit, is a full-stack smart wallet SDK with embedded wallets and a gas manager. Application builders use it to give users an account and sponsored transactions without a separate wallet app.RundlerRundler is Alchemy's modular Rust ERC-4337 bundler aimed at horizontally scaled deployments; many Ethereum user-operation workloads run on it today.Chain Abstraction with 4337With this setup, ecosystems can deploy tailor-made 4337 chain abstraction infrastructure. They become Liquidity Providers (LPs) for their users, sharing with them the value that would otherwise have been captured by solvers/fillers.Coinbase Smart WalletCoinbase Smart Wallet is a passkey-based smart account with the largest share of deployed wallets. Application builders integrate it so users sign with a passkey instead of managing a seed phrase.Skandha ERC-4337 BundlerSkandha is Etherspot's TypeScript ERC-4337 bundler that optimizes user operation submission, gas accounting, and mempool routing with optional MEV protections and shared mempool compatibility, and Etherspot runs that shared mempool stack in production.GelatoGelato is a hosted network that provides a bundler, paymaster and relay for smart accounts together with Web3 Functions for scheduled and event-driven contract execution. Builders use it to run gasless transactions and contract automation without operating those services themselves.Particle NetworkParticle Network is a hosted wallet-abstraction stack that bundles a bundler, paymaster, and social login. Builders choose it when they want account creation, login, and transaction sponsorship from one service.Sequence (0xsequence)Sequence, published as 0xsequence, is a smart-contract wallet SDK with embedded wallets, a relayer, an indexer, and gasless transactions. Builders use it when a game or application needs wallets and transaction plumbing from one stack.Base Account SDKBase Account SDK is Coinbase's package for Base Account, a smart-contract wallet with passkey signing and gasless transactions. Web builders install it to add passkey sign-in and sponsored transactions, separate from the older Coinbase Wallet SDK.MetaMask Delegation Framework (Gator)The MetaMask Delegation Framework, known as Gator, is a set of contracts that let one account grant specific revocable permissions to another account or agent along the lines of ERC-7715 and ERC-7710. Teams building delegated or agent-controlled permissions import these contracts and write their own caveat enforcers against them.Ithaca Account (Porto)Ithaca Account is the set of EIP-7702 smart account contracts behind Porto, an account standard for web authentication and payments. Teams picking an EIP-7702 implementation can read, fork, or deploy these contracts.ethereum-multicallAbility to call many ethereum constant function calls in 1 JSONRPC requestKernel (ZeroDev)Kernel from ZeroDev is a modular ERC-7579 smart-account contract with wide deployment. Wallet builders deploy it when an account needs pluggable validators and executors.Safe 4337 module (safe-modules)The Safe 4337 module adds native ERC-4337 support to Safe multisig accounts. Safe builders install it so an existing multisig can be driven by user operations through a bundler.Alto (Pimlico)Alto is a TypeScript ERC-4337 bundler from Pimlico that also runs behind their hosted service. Infrastructure builders run it themselves when they need to operate a bundler instead of relying on a third party.permissionless.js (Pimlico)permissionless.js from Pimlico is a vendor-neutral TypeScript library built on viem for ERC-4337 accounts. TypeScript builders use it to assemble and submit user operations while keeping the choice of bundler and paymaster open.Light AccountA set of lightweight, open sourced, audited and gas-optimized ERC-4337 compatible smart contract accounts with designated ownershipZeroDev SDK (Kernel)The ZeroDev SDK is a smart-account SDK for the Kernel account with modular validators and session keys. Account-abstraction builders use it to create Kernel accounts and delegate limited signing rights to sessions.Nexus (Biconomy)Nexus from Biconomy is a modular ERC-7579 smart-account contract aimed at high-volume applications. Wallet builders deploy it as the account implementation behind their smart wallets.Voltaire | Account Abstraction BundlerVoltaire is an ERC-4337 bundler implementation you can run when you need configurable user-operation relaying for account-abstraction wallets.Arka (Etherspot paymaster)Arka is the open-source paymaster service from Etherspot for sponsoring transaction gas. Builders self-host it when gas sponsorship for ERC-4337 accounts should run on their own infrastructure.executooorexecutooor centers on a reusable executor contract pattern so scripts can chain delegate calls, token approvals, and atomic onchain steps through viem or ethers without redeploying bespoke routers each time.AbstractionKit | Account Abstraction LibraryAbstractionKit is a TypeScript helper library for wiring ERC-4337 flows-user operations, paymasters, and bundler calls-without implementing the wire protocol from scratch.safe7579 (Rhinestone)safe7579 from Rhinestone is an adapter that makes Safe accounts ERC-7579 compliant. Builders add it when they want portable ERC-7579 modules to run on a Safe, usually alongside the Safe 4337 module.Rhinestone ModuleKitRhinestone ModuleKit is a Solidity framework for building and testing ERC-7579 modules. Builders use it when writing validators, executors, or hooks for modular smart accounts.Biconomy SDK (Nexus)The Biconomy SDK, published as AbstractJS for the Nexus account, builds ERC-4337 smart accounts with paymaster and bundler services. Builders use it when an application needs sponsored or gasless transactions.Gelato Relay SDKGelato Relay SDK wraps Gelato's relayers so frontends can submit meta-transactions, sponsored gas flows, or scheduled calls without operating your own bundler fleet.Payments & DeFi integration(8)crossmintCrossmint offers stablecoin APIs aimed at enterprises, including cross-chain flows. Builders use it to add stablecoin payments to an application without building the payment rails.eth-priceseth-prices is a Rust crate that estimates the price of an Ethereum asset by reading Uniswap V2 and V3 pools and ERC-4626 vaults through an RPC provider, with no exchange rate API involved. Rust builders add it when a price should be derived from onchain liquidity rather than read from an oracle feed.Lido Ethereum SDKThe Lido Ethereum SDK is the official package for staking and managing stETH and wstETH through the Lido protocol. Builders install it to add staking to an application without writing the Lido contract calls by hand.Machine Payments Protocol SDK (wevm)The Machine Payments Protocol SDK, published as mppx by the wevm team behind viem and wagmi, is a TypeScript implementation of an agent payments specification. Builders install it to let a service or agent pay and charge programmatically.Request NetworkRequest Network is a protocol and JavaScript library for creating, paying, and tracking crypto invoices and payment requests onchain. Builders install the client library to add invoicing to their own application.Stripe Crypto OnrampStripe Crypto Onramp is an embeddable fiat-to-crypto onramp SDK for web, iOS, Android, and React Native that delivers purchased crypto to a user's wallet. Builders embed it so users can fund a wallet with a card instead of transferring in.web3-ethereum-defiweb3-ethereum-defi is a Python library for DeFi integration and data research, with wrappers for Uniswap, Aave, Chainlink, and USDC on top of web3.py. Python builders import it instead of writing those protocol wrappers themselves.x402x402 is an open payments protocol built on the HTTP 402 status code that lets an application or agent pay per request in stablecoins without accounts or API keys. Builders add its middleware to a service to charge per call, or to a client so it can pay.Governance & DAO tooling(4)SnapshotSnapshot began as gasless off-chain governance for DAOs with flexible voting strategies and validation plugins, and the team later launched Snapshot X, a modular onchain voting stack that keeps execution trust-minimized while still minimizing gas through clever proving and cross-chain voting power accounting.Aragon OSxAragon OSx is onchain DAO framework infrastructure for launching modular organizations that govern treasuries and protocol parameters with audited contract primitives.AgoraAgora is an onchain governance application used by protocols including Optimism, ENS, and Uniswap to run delegate voting. It is a Next.js application a DAO deploys rather than a library a builder imports.DAOhausDAOhaus offers open-source tooling for launching and operating DAOs with modular contracts, apps, and community governance workflows.Network infrastructure(128)RPC/node infrastructure(37)alloyAlloy is a set of libraries that provides types and RPC client implementations for Ethereum.OrbitDBPeer-to-Peer Databases for the Decentralized Webgo-libp2pgo-libp2p is the canonical Go implementation of libp2p, packaging transports, identify, DHT, and GossipSub modules relied on by Prysm, Lotus, Celestia, and other large-scale clients that need production-grade peer discovery and messaging.Helios (a16z)Helios from a16z is a portable light client that serves verified Ethereum and other chain data without trusting an RPC provider. Builders run it or embed the Rust library when an application must check the data it receives.js-libp2pjs-libp2p is the JavaScript implementation of libp2p transports, security, pubsub, and discovery-used by Farcaster hubs, Lodestar-related tooling, and other off-chain coordination stacks.eRPCeRPC sits in front of your RPC providers to add caching, failover, and routing tuned for read-heavy workloads like dashboards, indexers, and multi-tenant backends.TevmAn Ethereum Node built to run in Browser, Bun, Deno, and Node.jsCheckpointzCheckpointz is a beacon-chain checkpoint sync provider from ethPandaOps. Node operators run one or point a consensus client at an existing instance to bootstrap a node in minutes instead of syncing from genesis.AlchemyAlchemy is a developer platform for building Ethereum and EVM applications with node infrastructure, APIs, and SDKs.1RPC1RPC from Automata Network is a privacy-preserving public RPC endpoint for Ethereum and other EVM chains. Builders point an application at it when request metadata should not be tied back to users.All That NodeAll That Node is a multi-chain node-as-a-service platform offering shared and dedicated Ethereum RPC nodes. Builders sign up for an endpoint instead of running their own node.AnkrAnkr offers free public and paid RPC endpoints across many chains. Builders point applications at Ankr for hosted chain access without operating their own nodes.BlockdaemonBlockdaemon runs enterprise node infrastructure together with staking systems and RPC APIs. Infrastructure teams use it when node operation and staking are outsourced under an enterprise agreement.BlockPI NetworkBlockPI Network is a hosted RPC service for Ethereum and more than 70 other chains, with shared and dedicated node tiers. Builders use it for chain access without operating infrastructure.ChainnodesChainnodes provides RPC and node infrastructure for Ethereum and the major layer 2 networks, including archival endpoints. Builders buy endpoints there when an application needs historical state as well as current data.ChainstackChainstack provides managed node and RPC","tokens":15000,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260295170,"hash":"20e5d5a7f16a8953c0b85bb0aef5b71bb58779ff"}
{"url":"https://forum.openzeppelin.com/c/support/upgrades/35","domain":"forum.openzeppelin.com","title":"Latest Support/Upgrades topics - OpenZeppelin Forum","text":"Latest topics in Upgrades\n\n Upgrades\n\n OpenZeppelin Upgrades Support\n\n Support\n\n Upgrades\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n UUPS Upgrade Successful (event emitted) but Implementation Address Not Updating (BSC Mainnet, Hardhat)\n\n proxies,solidity,upgrades\n\n 3\n\n 113\n\n Apr 9\n\n Initial alpha release of Hardhat Upgrades plugin for Hardhat v3\n\n 0\n\n 78\n\n Mar 2\n\n Compatibility/Support of old manifest formats\n\n 2\n\n 83\n\n Jan 29\n\n How to get ‘exact code’ verification for OpenZeppelin UUPS proxy contracts?\n\n proxies,hardhat\n\n 1\n\n 98\n\n Oct 2025\n\n The upgrade function is used repeatedly with the current version of the smart contract as an argument for the new version, but instead, a new one should be deployed\n\n proxies\n\n 2\n\n 66\n\n Aug 2025\n\n Failed to upgrade implementation of proxy using proxy admin\n\n 1\n\n 60\n\n Aug 2025\n\n Deploy upgradable contract with hardhat-upgrades fails on mainnet\n\n 2\n\n 173\n\n Aug 2025\n\n UUPS Timed out waiting for implementation contract deployment (docker)\n\n proxies\n\n 0\n\n 66\n\n Jun 2025\n\n How to change the msg.sender in upgrade plugin?\n\n proxies\n\n 2\n\n 69\n\n May 2025\n\n Possible bug with Missing initializer calls / order of initializers error\n\n 1\n\n 143\n\n May 2025\n\n Potential false positive “Missing initializer calls for one or more parent contracts”\n\n erc20,upgrades\n\n 2\n\n 229\n\n Apr 2025\n\n Adding _disableInitializers() at the end of the initialize method causes a “ProviderError: execution reverted” error when deploying the UUPS proxy and logic contract using hre.upgrades.deployProxy\n\n etherscan-verify\n\n 10\n\n 137\n\n Apr 2025\n\n The Upgrades plugin does not allow the execution of the constructor\n\n proxies\n\n 5\n\n 77\n\n Mar 2025\n\n New variables should be placed after all existing inherited variables\n\n 4\n\n 47\n\n Mar 2025\n\n Wrong indication of incompatible layout after upgrade\n\n 6\n\n 102\n\n Feb 2025\n\n Verifying TransparentUpgradeableProxy v 4.5 on Ethereum mainnet\n\n etherscan-verify,proxies\n\n 10\n\n 986\n\n Feb 2025\n\n Trying to upgrade a already deployed proxy contact on etherscan\n\n etherscan-verify\n\n 7\n\n 313\n\n Feb 2025\n\n prepareUpgrade with upgradeAndCall to upgrade proxy\n\n upgrades,upgrades-plugins,hardhat\n\n 1\n\n 103\n\n Jan 2025\n\n Transparent proxy upgrade with timelock\n\n 3\n\n 227\n\n Jan 2025\n\n `upgrades.deployProxy` hangs indefinitely on `hh coverage`\n\n proxies\n\n 6\n\n 1.1k\n\n Dec 2024\n\n Get OwnableUnauthorizedAccount when upgrade the transparent proxy\n\n upgrades,foundry\n\n 3\n\n 245\n\n Dec 2024\n\n Storage collision non-upgradable child and upgr. parent\n\n proxies,solidity,upgrades\n\n 1\n\n 89\n\n Dec 2024\n\n What does `_disableInitializers();` function mean?\n\n 22\n\n 10.4k\n\n Nov 2024\n\n __gap isn’t necessary in new OZ implementations?\n\n 3\n\n 227\n\n Nov 2024\n\n Contract name format for Foundry Upgrades\n\n 1\n\n 46\n\n Nov 2024\n\n Error when runnning upgrade safety validation\n\n 3\n\n 280\n\n Nov 2024\n\n Immutable ZkEvm Testnet - Upgradeable Contract initialize not being called\n\n etherscan-verify,proxies\n\n 6\n\n 65\n\n Nov 2024\n\n ImmutableX ZkEvm Upgradeable Contracts\n\n etherscan-verify,proxies\n\n 3\n\n 46\n\n Nov 2024\n\n Upgrades Plugin fails with the latest Hardhat (“contractFactory.attach is not a function”)\n\n 2\n\n 490\n\n Nov 2024\n\n Issue with upgradeToAndCall for 1967 Proxy Address and UUPS Implementation: Revert Error on Upgrade Attempt”\n\n upgrades\n\n 1\n\n 252\n\n Oct 2024","tokens":834,"squid":"ink-security_audits","role":"Sentinel","at":1791260295391,"hash":"ef1341decd37315d0f8b763832b09aae4217e62b"}
{"url":"https://dev-forum.pyth.network/t/deprecation-of-some-pyth-push-feeds-on-solana-april-30th-2026/757","domain":"dev-forum.pyth.network","title":"Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026 \n\n Announcements\n\n announcements,sponsored-feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 20\n\n 1 / 3\n\n Apr 19\n\n Apr 30\n\n post by KemarTiti on Apr 30\n\n KemarTiti\n\n Hey Pythians,\nThe Pyth Data Association, in accordance with some Sponsors of certain Push Feeds, has decided to stop pushing price updates from April 30th 2026, for the below feeds:\n\nSolana\n\nCrypto.ORCA/USD\nCrypto.HNT/USD\nCrypto.PENGU/USD\nCrypto.NAV.ONYC/USD\nCrypto.SAMO/USD\n\nAs always, if you need proactive price updates on any chain (mainnet or testnet), you can run the Price Pusher yourself.\nAny questions let us know.\n\n 9 days later\n\n post by KemarTiti on Apr 29\n\n KemarTiti\n\n Please note that the feeds from Sonic EVM will see their push price updates extended to May 15th, 2026.\n\nCrypto.WSTKSCETH/SCETH.RR\nCrypto.WSTKSCUSD/SCUSD.RR\nCrypto.SHADOW/USD\n\n post by KemarTiti on Apr 30\n\n KemarTiti\n\n The Solana feeds mentioned above have now stopped being pushed. LBTC/USD was added again for the time being.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Deprecation of some Pyth Push Feeds on Sonic EVM – May 15th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 1\n\n 37\n\n May 15\n\n Deprecation of some (Resolv) Pyth Push Feeds on Base, Ethereum, Arbitrum, HyperEVM and Solana – May 31st, 2026\n\n Price Feeds\n\n announcements\n\n 1\n\n 33\n\n Jun 2\n\n Deprecation of Pyth Push Feeds - 15th January, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 170\n\n Jan 15\n\n Deprecation of Pyth Push Feeds on Soneium - 7th December, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 229\n\n Dec 2025\n\n Deprecation of Pyth Push Feeds on Aptos – April 30th, 2026\n\n Announcements\n\n announcements,move\n\n 1\n\n 95\n\n May 1\n\n Powered by Discourse","tokens":1334,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260308128,"hash":"cacdd3bdb54204b56566a8b70909e2f7f5d688b3"}
{"url":"https://io.net/docs/guides/explorer/io-explorer","domain":"io.net","title":"Overview - io.net","text":"The purpose of IO Explorer is to provide users with a comprehensive view of our network, offering detailed statistics and insights into every aspect of our GPU Cloud. Similar to Solscan or a blockchain explorer for blockchain transactions, IO Explorer offers transparency to our GPU-powered operations.\nIts primary goal is to empower users to easily monitor, analyze, and understand the io.net network by providing complete visibility into activities, key statistics, data points, and Rewards transactions.\nIO Explorer democratizes access to our cloud data by offering transparent real-time metrics on cluster bookings, deployments, and network devices, all while ensuring that sensitive information remains hidden and securely protected.Was this page helpful?","tokens":190,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260309338,"hash":"e07e4fad3868f66e91cea737ab23cd6ec51ea7d7"}
{"url":"https://io.net/docs/guides/explorer/block-rewards-page","domain":"io.net","title":"Block Rewards - io.net","text":"​Block Rewards Dashboard\nThe Block Rewards Dashboard offers a detailed overview of the rewards earned by devices contributing computational power to the IO.net ecosystem. This page helps you track their earnings, understand reward calculations, and monitor key performance metrics. Whether you are an individual worker or managing multiple devices, the dashboard provides full transparency on reward distribution.\nTo view the Block Rewards tab, go to io.net > IO Explorer > Block Rewards.\n\nKey Features\nThe Rewards Overview Dashboard provides a high-level summary of reward distribution activity across the network. It allows administrators and operators to quickly monitor token payouts, supplier participation, and epoch progression without reviewing individual epochs..\n\nTotal Coins Distributed (In $IO Coins): Shows the total amount of $IO coins allocated to all eligible workers since the start of the reward system.\nToday’s Coins Distributed (In $IO Coins): Shows the total amount of $IO coins rewarded to workers within the current 24-hour period.\nTotal Epochs Computed: Indicates the number of computational epochs successfully processed within the IO.net network.\nNext Epoch Start Time: Displays the scheduled start time for the next computational epoch.\nTotal Unique Suppliers Paid: Represents the total number of distinct workers that have received rewards since the network began distributing payments.\nToday’s Unique Workers Paid: Represents the total number of distinct workers that have received rewards within the current 24-hour period.\n\n​Epoch List\nThis section provides a list of all reward epochs and their current status. Each row displays the epoch ID, duration, total reward emissions, nominated resources (CPUs and GPUs), and any resources that failed eligibility or validation checks. Open epochs show ongoing reward cycles, while closed epochs contain finalized reward data. Users can search for a specific epoch using the Epoch ID search bar to quickly locate and review reward distribution details.\n\nWallet Requirement for Rewards\n\nA valid SOL address is required to calculate Block Rewards.\nAutomated payouts are not yet enabled, so you should consider using a self-custodial wallet.\n\nWas this page helpful?","tokens":559,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260319271,"hash":"10bef74dc4f57d63718a4e21b9f7d35d2ffa62a9"}
{"url":"https://ethresear.ch/t/the-future-of-state-part-2-beyond-partial-statefulness-zkevms/23396","domain":"ethresear.ch","title":"The Future of State, Part 2: Beyond The Myth of Partial Statefulness & The Reality Of ZKEVMs - Execution Layer Research - Ethereum Research","text":"The Future of State, Part 2: Beyond The Myth of Partial Statefulness & The Reality Of ZKEVMs \n\n Execution Layer Research\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 12\n min\n\n Nov 2025\n\n 1 / 6\n\n Nov 2025\n\n Nov 2025\n\n post by CPerezz on Nov 3, 2025\n\n CPerezz\n\n The Myth of Partial Statefulness: Why Ethereum’s Future May Force a Binary Choice\n\nWe strongly recommend reading first the Part 1 of this series of articles. Even if a new type of client is not really interesting for you in particular, it will set the basis that showcase a lot of the problems tackled in this post.\n\nThanks to @weiihann and @gballet for their feedback and endless reviews.\n\nWe advise to readers that part 4.3.X can be skipped. But it showcases a bunch of issues and examples that are important to understand why Partial Statefulness & RPC-serving on this way might not be as good as it sounds.\n\n1. Introduction — The Illusion of Middle Ground\nEthereum’s roadmap toward statelessness and ZK-based validation has inspired the idea of a “partially stateful” node: one that stores and serves only a fraction of the global state while still contributing meaningfully to verification and data availability.\nAt first glance, this model promises a practical middle ground between the burden of full nodes and the fragility of fully stateless clients. Yet on closer inspection, the middle ground is largely illusory. Once state expiry and validity proofs dominate, the notion of sustainable partial statefulness collapses under the weight of execution semantics, data dependencies, and economic incentives.\nThe consequences extend far beyond performance. Ethereum’s security model relies on universal re-execution — the ability of any node to deterministically recompute state transitions. Once that ability is lost, state obtention from RPCs becomes an act of trust, not verification (as no proofs are served with such messages), and the decentralized execution layer begins to centralize in subtle but irreversible ways.\n2. What Partial Statefulness Actually Means\nBetween the extremes of a fully stateful node and a stateless client lies a theoretically appealing compromise: partial statefulness, sometimes framed as partial statelessness.\nIn this model, a node retains and serves only the subset of Ethereum’s global state that is directly relevant to its own activity or the users it supports, discarding the rest.\nThis approach can be understood as an alternative path to the same goal as state expiry: reducing the burden of perpetual state growth. Whereas state expiry enforces data deletion protocol-wide, partial statefulness allows operators to specialize voluntarily — keeping only the data that matters to them.\nIt also offers an intuitive appeal from an application-centric perspective.\nConsider USDC, the ERC-20 stablecoin. The USDC contract is among the most actively used on Ethereum mainnet, and the companies behind it, they already have machinery to provide state-related data mostly related to their contract..\nFor such an actor, maintaining an RPC server that stores and serves only the USDC-related portion of Ethereum’s state — balances, allowances, and event logs — would be highly efficient.\nThis arrangement provides three key benefits:\n\nReduced operational cost. Limiting storage to a single contract’s data dramatically lowers hardware and indexing requirements.\n\nLocalized availability. Users interacting with that contract can access data faster and more reliably, without relying on third-party RPC providers.\n\nImproved self-sufficiency under state expiry. If Ethereum eventually enforces in-protocol expiry — pruning old, inactive state — users or DApps that already hold the fragments they care about can revive that data far more easily.\nWithout such local holdings, users become vulnerable to revival monopolies. Imagine an account with a million dollars in tokens that remains untouched for five years and is thus pruned. When the owner returns, they must reconstruct the state from external providers — who may charge arbitrary fees for data restoration.\n\nBy contrast, partial state retention distributes this burden, aligning with the broader logic of state expiry — smaller global state, but more personalized persistence.\nimage1528×704 19.2 KB\nThis in turn reinforces the appeal of partial statefulness: the more users keep selective fragments, the easier it becomes to reason about and implement expiry, completing a virtuous cycle between selective storage and sustainable pruning.\nYet, as we will see, this is closer to an idealized scenario than a practical one. The coordination, consistency, and incentive mechanisms required to make such selective persistence reliable at scale are extraordinarily complex — turning what looks like a pragmatic optimization into, at least for now, a form of technological utopia rather than a realistic expectation.\n3. From Full Nodes to Stateless Clients — The Structural Transition\nIn Ethereum’s early years, full nodes performed three tightly coupled functions:\nConsensus verification — checking that every block’s execution followed protocol rules.\nState availability — achieved primarily through sync state serving, where nodes provided state data to peers during fast or snap synchronization. This peer-to-peer mechanism was the backbone of Ethereum’s distributed data layer.\nUser-facing access — offered through RPC serving, a niche but essential interface enabling wallets, dApps, and explorers to query or broadcast transactions. Unlike sync state serving, RPC endpoints were rarely operated by individuals; they were and still are predominantly provided by companies and infrastructure services such as Infura, Alchemy, or exchange-operated nodes.\nThese three roles together formed a coherent ecosystem. To verify blocks, a node had to hold the full state; and by holding it, it naturally contributed to both the sync layer and (occasionally) the RPC layer. This alignment made Ethereum’s availability largely self-sustaining — a by-product of consensus itself.\nThe emergence of stateless validation and ZK-EVM proofs decouples these roles. A node can now verify correctness without holding any state at all. Once verification and storage are separated, maintaining full state becomes optional — and economically irrational unless compensated.\nPartial statefulness appears to offer a compromise, but the illusion fades once we consider how Ethereum’s execution model actually works.\n4. The Infeasibility of Partial Statefulness\n4.1 The Missing Witness Range — Why Re-execution and Proof Serving Become Impossible\nEthereum’s consensus depends on every node’s ability to re-execute transactions deterministically, given the parent state root.\nFor this to hold, a node must be able to traverse the full authentication path of any account or storage slot — from the global state root down to the leaf node representing that value.\nA partially stateful node (such as OOPSIE) intentionally retains only the leaves relevant to it — e.g., an account’s balance, nonce, or specific ERC-20 mappings — but discards most of the intermediate trie nodes that connect these leaves to the state root.\nThis absent segment is the missing witness range: the sequence of intermediate nodes between the leaf and the state root.\nmissing_range1200×830 6.93 KB\nThese nodes are crucial for two reasons:\nAuthentication and proof generation.\nTo produce or verify a Merkle proof of inclusion — whether for an RPC query, a light client request, or a snap-sync operation — a node must possess every node along this path.\nWithout it, the node cannot prove that its locally held data actually belongs to the canonical global state.\nConsequently, partial nodes cannot serve authenticated RPCs, cannot participate in snap-sync for the segments they store, and cannot help others reconstruct state trustlessly.\nThe result is a network where only a few full providers (e.g., Infura, Alchemy, exchange nodes) retain the capacity to generate valid proofs.\nEveryone else becomes a passive data holder, unable to attest to correctness — a quiet but absolute form of centralization.\nState revival under expiry.\nIn state-expiry regimes (in-protocol or external), a user must prove that an expired account or storage slot previously existed and was part of the global state root at some block.\nDoing so requires exactly the same authentication path.\nIf the user lacks the missing witness range, they cannot prove existence — even if they still hold their local data.\nThey must turn to centralized providers to obtain the missing nodes, effectively paying “revival rent” to data oligopolies.\nThis paradox defeats the purpose of partial statefulness.\nA node may hold its own data, but it cannot authenticate it. It can serve state but not trustlessly; it can answer queries but not help anyone sync.\nAs a result, the network drifts toward a model where proofs, snapshots, and synchronization are monopolized by the few actors that preserve the full trie — the very centralization Ethereum sought to avoid.\nimage1228×1184 65.1 KB\n4.2 The Economic Problem — No One Pays for Partial Knowledge\nHistorically, full nodes engaged in sync state serving as a by-product of consensus participation: to verify, they had to store; and by storing, they could serve & verify.\nStateless verification dissolves that link. Once nodes can validate without storage, there is no built-in reason to maintain state for others.\nThe peer-to-peer sync layer — the true backbone of availability — becomes an unpriced externality. Rational nodes prune aggressively, while only a few specialized actors retain complete snapshots.\nThis shift has practical and systemic consequences.\n\nMundane operations we take for granted today — syncing a node from scratch, fetching a specific range of accounts or storage slots via snap-sync, or obtaining authenticated proofs for a particular contract — will no longer be broadly viable.\nThe infrastructure that supports these everyday tasks will shrink to a handful of entities capable of serving authenticated data. In practice, that means RPC providers.\nThey will likely remain the only actors capable of sustaining full-state access, but this service will almost certainly be commercialized, not freely provided.\nAs altruistic full-node operators disappear, the network’s capacity for permissionless synchronization and open access will erode, pushing Ethereum toward de-facto data centralization.\nIf the data layer becomes centralized, those custodians gain the ability to collude — selectively throttling, censoring, or even excluding new builders and infrastructure providers from joining the network.\nControl over state access becomes control over who can meaningfully participate.\nFurthermore, nodes that wish to reconstruct the full state independently will have no practical shortcut other than replaying blocks from genesis — performing a full sync.\nWithout broad state-serving peers, this process becomes prohibitively slow and resource-intensive, reinforcing dependence on centralized providers.\n\nimage1510×1102 61.1 KB\nFurthermore, building incentivized state-serving markets is profoundly complex (ie. Portal Network, which took years to develop and did not include any incentive mechanism).\nPrivate capital has little reason to fund such infrastructure when the simpler and more profitable path is to run proprietary RPC services.\nIncentivized state availability requires cryptoeconomic coordination, micropayments(to pay minimal amounts for state-on-demand), and verifiable accounting for data served — a level of protocol-native integration that Ethereum has not yet achieved (And some might believe is unachievable).\nUntil that exists, the economic equilibrium remains clear: few will pay to serve state, and even fewer will do it altruistically.\n4.3 The Fragmentation Problem — State as a Partially Divisible Graph\nThe challenge of state fragmentation is often overstated, yet it remains non-trivial.\nWhen an operator chooses to maintain a partial state, it is typically because they know precisely what subset they need to fetch and maintain.\nGiven an account or contract address, one already possesses its code hash, which uniquely identifies the bytecode.\nFrom that bytecode — or the associated ABI, when available — a node can reconstruct most of the depdancy layout, event schema, and function selectors relevant to that contract.\nIn many cases this is sufficient: the majority of interactions are self-contained, and delegate calls to arbitrary external contracts are relatively uncommon (though this is what 7702 does, so it’s about to become a lot more common).\nUnder these assumptions, a partial node can in principle isolate and maintain coherent fragments of the state, especially for contracts with stable, well-understood interfaces such as ERC-20 tokens or DEX pools.\nHowever, this separability has limits. Cross-contract calls, upgradeable proxies, or composable protocols can introduce dependencies that are not statically inferable.\nWhile not the most critical constraint, fragmentation still undermines the universality of re-execution: even if partial nodes remain functional within their domain, the system as a whole cannot guarantee deterministic replay across all subsets.\n\nThe upcoming examples can be skiped. But they provide valuable insight on why these partial stateful RPC-serving nodes aren’t really useful in today’s use cases of Ethereum. Even for the basic users of the chain.\n\n4.3.1 An example: the never-ending chain of dependencies\nIt is tempting to say: “We only care about this one contract. Let’s just keep that.” But on Ethereum, even something as conceptually narrow as “just serve state for one ERC-20 token” very quickly drags in a long tail of other contracts, other storage, and other actors. Past a certain point, you are no longer “partially stateful.” You are just doing state, but informally and with worse guarantees.\nConsider a seemingly simple goal: operate a partial node that “only” serves USDC-related state to users (balances, allowances, transfers), e.g. to act as an application-local RPC for that token.\nAt first glance this looks self-contained:\n\nYou store USDC.balanceOf(address) for relevant addresses.\nYou store allowance(holder, spender) for those addresses, so you can answer “can this wallet spend my USDC?”\nYou store the USDC contract metadata and code hash.\n\nSo far, this looks perfectly compatible with partial statefulness. But now look at what users actually ask in practice, and what you would need to serve honestly (with correct answers instead of trust-me-bro state chunks without any MPT proofs):\n4.3.2 DEX liquidity and pricing.\nUsers don’t just ask “what’s my USDC balance?” They ask “what is this USDC actually worth?” and “what will I get if I swap it?”.\nTo answer anything about price, you now need state from the AMM pools where USDC is paired: e.g. USDC/ETH pools, USDC/USDT pools, USDC/DAI pools.\nConcretely, that means you now have to pull in:\n\nThe pool contracts (e.g. specific Uniswap-style pair contracts or concentrated-liquidity pool contracts).\nThe pool reserves / liquidity ranges / ticks.\nFee parameters and accumulated fees per liquidity position.\nThose are different contracts. They’re not part of USDC’s storage trie — they live in completely separate accounts, each with their own storage roots.\n\nIf you don’t store that, you cannot answer even very basic “is this price quote legit?” questions without deferring to some external source.\n4.3.3 Routers and approvals.\nReal users don’t transfer USDC directly; they route through DEX routers, aggregators, vaults.\nTo know if “this account can execute a swap using USDC right now,” you can’t just answer using allowance(user, router) from the USDC contract in isolation. You now also need:\n\nThe router contract(s) themselves (which router are we talking about? Uniswap’s router? 1inch? CowSwap settlement contract?)\n\nand if the RPC/Dapp decides to select only a few, means that there will be a DEX centralization as well. It’s not just the chain that falls to this pitfall.\n\nThe router’s logic about which pools it will touch,\nPotential intermediate hop tokens.\n\nIf USDC → WETH → some other token is the default path, you’re implicitly tracking WETH state too: balances, allowances, total supply, and possibly wrapped ETH accounting.\nSo “I only serve USDC state” silently becomes “I serve USDC, WETH, and all the router contracts and their assumptions about connectivity.”\nAnd this pulls in yet another layer of external contract code and storage.\n4.3.4 LP positions and vault wrappers.\nMany users don’t even hold USDC directly in their externally owned account. They hold it inside something:\n\nIn a Uniswap V3 position (which is itself an NFT that encodes a price range, tick spacing, and liquidity amount),\nIn a lending protocol (USDC deposited as collateral, now represented as an aUSDC/cUSDC-style derivative balance),\nIn a yield vault or auto-compounder contract.\nTo answer a very normal user question like “how much USDC do I really have?”, you now have to:\nInspect their position manager NFT contract and read position state,\nInspect lending pool accounting contracts to see how much claim they have on the underlying,\nInspect vault share tokens and figure out the share→underlying exchange rate.\n\nNone of those live in the USDC contract. They’re not even structurally “children” of USDC in the trie. They are independent contracts with independent storage, each of which now becomes part of “your subset.”\n4.3.5 Data authenticity.\nEven if you say “fine, I won’t do prices, I’ll only tell you balances,” you still hit the witness problem.\nTo serve provable answers — i.e. to provide Merkle proofs that “this balance really is part of the canonical state” — you don’t just need the leaf for USDC.balanceOf(user).\nYou need:\n\nThe entire authentication path for that slot up to the global state root,\nWhich means intermediate trie nodes for USDC’s account,\nWhich themselves depend on the global account trie.\nThat already forces you outside of “just USDC,” because those intermediate trie nodes co-mingle structure from other accounts.\n\nThe dependency explosion happens even before we get to any DeFi composability.\n\nWhat looked like a neat, contract-scoped slice of state turns out not to be a slice at all. It’s a graph whose closure is “most of DeFi + witness paths.” The combinatorial dependency graph means that, in practice, trying to remain narrowly partial either makes you:\n\nuseless (you can only answer trivial questions, and even then not with proofs), or\nde facto full-service (you’re now tracking a huge chunk of Ethereum’s economic state anyway).\n\nThis is why fragmentation, while not always the first blocker (the missing witness range is more fundamental), is still fatal at scale. Even a “tiny” vertical like “just USDC” tends to force you into everything else if you want to be meaningful. Not just functional.\n5. The Incentive Paradox\nStatelessness introduces an asymmetry: verification becomes trustless and cheap, while state availability remains costly and unrewarded.\nThis dismantles the feedback loop that once aligned incentives. Full nodes no longer gain utility from storage, and partial nodes cannot perform full verification.\nThe logical endpoint is a bifurcated system:\nA small set of state-rich sync providers maintaining data continuity.\nA large population of stateless proof consumers depending on those providers for access to historical or off-subset data.\nIronically, the more Ethereum optimizes for efficiency, the stronger its pull toward centralization. Efficiency removes redundancy; redundancy was what made the system resilient.\n5.1 The technical part is fixable\nThe missing-witness problem described earlier — the inability of partial nodes to reconstruct the authentication path between their local storage and the global state root — is not a cryptographic dead end.\nIt is an architectural gap. Once we define a lightweight, standardized way to keep the upper levels of the state trie in sync, the gap closes.\nimage1892×1184 246 KB\n5.1.1 Rebuilding the top of the trie — account commitments\nEvery Ethereum account leaf already commits to four fields:\nnonce, balance, storageRoot, codeHash\n\nencoded as an RLP tuple whose hash forms the account value in the Merkle-Patricia Trie:\naccountHash = keccak256(RLP([nonce, balance, storageRoot, codeHash]))\n\nIf every node — even a partial one — kept only this 32-byte hash per account, it would have all the information needed to hash upward toward the global state root.\nNo balances, no code, no execution traces — just one 32-byte commitment per address.\nAt today’s scale:\n\n≈ 300 million accounts\n× 32 bytes each\n≈ 9.6 GB total\n\nThat dataset is small enough for a modest machine or even a Raspberry Pi-class device, yet complete enough to verify any account’s inclusion in the state root.\nNodes could store it as:\n\na flat key-value table (address → accountHash), updated in place; or\na lightweight Merkle accumulator, incrementally hashed upward as blocks arrive.\n\nEither structure makes the node cryptographically aware of the global state without requiring it to re-execute transactions or retain contract storage it doesn’t care about.\n5.1.2 Per-block sidecars — compact account-hash diffs\nTo keep this global account-hash table synchronized, each block would carry — or reference — a small sidecar payload broadcast through a pub-sub channel (similar in topology to Beacon-chain gossip).\nThe sidecar contains only:\n\nThe list of accounts touched by the block’s transactions old_accountHash = keccak256(RLP([nonce, balance, storageRoot, codeHash]))\nFor each, the updated new_accountHash = keccak256(RLP([nonce, balance, storageRoot, codeHash])).\n\nEvery partial node subscribed to this topic processes the sidecar as follows:\n\nReplace the stored 32-byte hash for each changed account.\nRe-hash incrementally — using cached untouched branches — to derive the new state root.\nVerify that the computed root matches the one announced in the block header.\n\nThat’s all. The bandwidth overhead is minimal (typically comparable to, or less than, the block size itself) and the computation is trivial compared to full re-execution.\nFrom then on, the node is state-root–synchronized: it can verify that its local partial data sits under a root consistent with the canonical chain.\nimage1656×1000 212 KB\n5.2 Proof-capable partial nodes and SnapSync contribution\nOnce a node maintains this up-to-date account-hash table, it gains full proof capability for the storage subtrees it actually holds.\nFor example, a node keeping the USDC contract’s storage can:\n\nProduce a Merkle proof from a local slot (e.g. balanceOf(address)) to the contract’s storageRoot.\nUse the globally tracked accountHash for USDC (which embeds its storageRoot) to connect that proof to the account layer.\nRe-hash upward to the verified global state root derived from sidecar updates.\n\nThat’s enough to serve authenticated RPC responses and snap sync ranges for its subset of state — no re-execution required.\nCollectively, such nodes would become active contributors to Ethereum’s data-availability layer:\n\nEach can serve verifiable state fragments to others.\nSnapSync no longer depends solely on a few full nodes.\nOOPSIE-style partial clients evolve from passive caches into distributed, proof-aware micro-providers.\n\nThis technical pathway doesn’t solve incentives — it only makes them easier to target.\nOnce partial nodes can serve authenticated state, Ethereum can design rewards around sync-state serving itself.\nA light device at home could hold a few gigabytes of account-hash data, store one or two contract subtrees, and earn modest compensation for providing Snap Sync proofs — a realistic, energy-efficient role that broadens participation instead of narrowing it.\n\n6. Conclusion — Ethereum’s Binary Future\nEthereum’s long-term architecture is converging on a binary outcome.\nEither the protocol introduces explicit incentives for sync-based state availability, or it accepts a future in which a handful of persistent providers become the de facto custodians of the network’s data.\nFrom a technical standpoint, we now know that partial statefulness is not impossible.\nThrough account-level commitments and per-block sidecars, it is possible for nodes to recompute the state root, prove correctness for their subsets, and even contribute authenticated data to snap sync.\nIn other words, the OOPSIE vision — partially stateful, proof-aware nodes that serve small fragments of state — can indeed exist as a coherent technical species within the Ethereum ecosystem.\nBut even if we solve the witness-range problem and make partial nodes cryptographically viable, we remain inside the same economic vacuum.\nNo mechanism today compensates anyone for holding or serving state.\nVerification is rewarded implicitly through consensus participation; storage and sync serving are not.\nThis asymmetry is what slowly starves the network’s data layer.\nFull nodes prune aggressively because there is no reason not to.\nRPC operators consolidate because they can extract fees while others cannot.\nAnd partial nodes, even if technically sound, will simply not appear in sufficient numbers without a reason to run them.\n6.1 Incentivized snap sync as the Natural Focal Point\nThe good news is that, once the technical side is solved, the incentive problem becomes far more tractable.\nIf partial nodes can meaningfully participate in snap sync — serving authenticated subtrees and proofs — then that becomes the natural focal point for incentives.\nRather than paying for global storage or subsidizing full nodes indefinitely, Ethereum could instead reward state-serving events: the act of responding to SnapSync requests or supplying verifiable proofs of state to peers.\nThat changes the economics of participation.\nIt opens a path for low-power, low-cost machines — home devices, Raspberry Pi–class setups, or modest cloud instances — to run partial nodes profitably.\nThese nodes wouldn’t need to hold the entire global state or execute every transaction.\nThey would simply keep authenticated fragments and earn small, ongoing rewards for serving them.\nThe protocol’s data layer would shift from a system of altruistic giants to a swarm of incentivized micro-providers.\n6.2 Who Provides the Sidecars?\nOne open question is who actually generates and distributes these per-block sidecars — the compact lists of account-hash diffs that allow partial nodes to update their state roots.\nIn principle, the responsibility could fall to block proposers, who already commit to the resulting state root in each block.\nThey are in the best position to assemble the set of changed account commitments and broadcast it through a pub-sub overlay, just as the beacon chain handles block attestations today.\nDoing so could be coupled with a market-based incentive: nodes that serve or relay these sidecars (and can prove correct delivery) receive micropayments proportional to their contribution.\nThis aligns the cost of sidecar generation and dissemination with block production and network bandwidth, ensuring that the data layer remains economically grounded rather than purely altruistic.\n6.3 The Fragility of Loss and the Need for Redundant Persistence\nEven with a functioning incentive system, state loss remains a critical risk.\nIf certain fragments of the state — or their corresponding proofs — vanish due to inactivity or unavailability, those portions of Ethereum’s history effectively become opaque.\nContracts or accounts dependent on lost segments could no longer be proven to exist at a given root, and any mechanism relying on revival proofs (e.g., state expiry reactivation) would fail.\nThis underscores the importance of redundant persistence.\nIn a world of partial stateholders, the survival of any fragment should not depend on a single node.\nIncentives must therefore not only reward serving but also replication — encouraging overlapping storage of the same subtrees across diverse participants.\nA healthy network would display a natural redundancy gradient: popular or economically active contracts (like USDC or major DEX pools) replicated by thousands, obscure ones by a few.\n6.4 Redefining Decentralization through Incentivized Diversity\nThat vision — incentivized snap sync serving over total storage — is what makes partial statefulness not just technically meaningful, but socially sustainable.\nIt redefines decentralization in practical terms: participation measured not by who can afford a datacenter, but by who can keep a small, verified piece of the state alive and responsive.\nOOPSIE, in this light, is less a utopia than a prototype of alignment.\nIt exposes the gap between what is technically possible and what is economically rational — and in doing so, it points toward a future where Ethereum’s data layer could once again scale through incentivized diversity, not consolidation.\nThe challenge ahead is therefore not to invent new proofs, but to reward persistence itself.\nOnly when maintaining and serving state becomes an economically meaningful act — including the generation, relay, and redundancy of sidecar data — will Ethereum’s execution layer remain truly decentralized.\n6.5 A final note on ZKEVM-statelessness.\n\nThis is not a critique of ZK-EVMs — quite the opposite.\n\nTheir development marks one of the most significant technical leaps in Ethereum’s history.\nBut precisely because they make verification effortless, they expose and amplify a deeper structural problem: there is still no backplane for data persistence once nodes begin pruning state.\nWithout a coordinated mechanism for retaining or re-serving historical data, the network risks becoming verifiable yet empty — a chain whose proofs survive, but whose underlying state slowly disappears.\nSolving this is not a detour from the ZK-EVM roadmap; it is a prerequisite for making its stateless future sustainable.\n\n Frame Transactions Through a Statelessness Lens\n\n 4\n\n 2\n\n read \n\n 12\n min\n\n post by MicahZoltu on Nov 4, 2025\n\n MicahZoltu\n\nIt also brings back the privacy problem, where lightclients are connecting their IP address and wallet address by asking centralized sync providers for their updated account data. Can be somewhat mitigated by adding noise, but one could argue that lightclients today can already add “noise” to their eth_calls if they wanted (but they don’t).\n\n post by MicahZoltu on Nov 4, 2025\n\n MicahZoltu\n\nI think the answer here is that this shouldn’t be a side-car, it should be part of the core protocol and a block is only valid if the “side car” is present on the network. Block builders who want their blocks accepted must provide this data to the network at time of block publishing (just like they must provide block bodies).\n\n post by MicahZoltu on Nov 4, 2025\n\n MicahZoltu\n\n General feedback:\nI feel like we should try to move away from MPTs for proofs, because they are so big compared to other proofs. Have you looked into things like Verkle trees to reduce proof sizes?\nWhen sending assets to someone, you need their account details so you can know (for example) how much gas to provide (if the recipient is a contract wallet you’ll need more than 21,000). I wonder if when someone shares their account with you via QR code, we could also fit their account proof in the QR code so the sender can properly construct the transaction without any third party involved?\n\n The Future of State, Part 1: OOPSIE - A new type of Snap Sync-based wallet/lightclient\n\n post by CPerezz on Nov 6, 2025\n\n CPerezz\n\n MicahZoltu\n\n I think that while I agree that privacy is a concern. Is even more concerning that we can simply not sync anymore or that full-state data becomes so scarce that centralization gets crazy.\n\nIt’s mandatory for builders to provide it I’d agree on that. But I wouldn’t say it’s a must to recieve it/forward it. Basically, these sidecars can be quite big. (MBs upwards). So you don’t want to propagate that across the entire network as it would significantly impact the overall bandwidth and latency of it.\nWell. Verkle was the best option wrt. proof sizes. But it was killed when it was quasi-ready to be shipped. So we are back at the start line again..\n\nThat we could do ofc. But should kinda be made as a standard. So we would probably need wallet-consensus most likely.\n\n post by MicahZoltu on Nov 7, 2025\n\n MicahZoltu\n\nIf it isn’t mandatory to propagate, then it isn’t mandatory to provide. A given node in the network cannot trustlessly differentiate whether the person giving them a block is the original block builder or an intermediate peer gossiping the block. If we try to enforce this, a builder can simply “gossip” their block to a single recipient (that they also operate) and then forward the block (without the sidecar) to the network.\nI can appreciate that these “side cars” are big, but that is the price we pay for cranking up the gas limit to 11, and if we choose to continue to ignore the costs of high gas limits then something is going to break. I would rather what breaks is the P2P network bandwidth, because that is visible to everyone (including core devs), rather than making it so fewer and fewer people can run trustless clients, which seems to be invisible to the core devs (despite many people telling them it is happening).\n\n Powered by Discourse","tokens":8348,"squid":"ink-research","role":"Deep Scholar","at":1791260322327,"hash":"442125296f45315fa8b44f680af3fb2c02d568d9"}
{"url":"https://dev-forum.pyth.network/t/deprecation-of-some-pyth-push-feeds-on-solana-april-30th-2026/757/3","domain":"dev-forum.pyth.network","title":"Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n announcements,sponsored-feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 20\n\n 3 / 3\n\n Apr 30\n\n Apr 30\n\n post by KemarTiti on Apr 30\n\n KemarTiti\n\n Hey Pythians,\nThe Pyth Data Association, in accordance with some Sponsors of certain Push Feeds, has decided to stop pushing price updates from April 30th 2026, for the below feeds:\n\nSolana\n\nCrypto.ORCA/USD\nCrypto.HNT/USD\nCrypto.PENGU/USD\nCrypto.NAV.ONYC/USD\nCrypto.SAMO/USD\n\nAs always, if you need proactive price updates on any chain (mainnet or testnet), you can run the Price Pusher yourself.\nAny questions let us know.\n\n 9 days later\n\n post by KemarTiti on Apr 29\n\n KemarTiti\n\n Please note that the feeds from Sonic EVM will see their push price updates extended to May 15th, 2026.\n\nCrypto.WSTKSCETH/SCETH.RR\nCrypto.WSTKSCUSD/SCUSD.RR\nCrypto.SHADOW/USD\n\n post by KemarTiti on Apr 30\n\n KemarTiti\n\n The Solana feeds mentioned above have now stopped being pushed. LBTC/USD was added again for the time being.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Deprecation of some Pyth Push Feeds on Sonic EVM – May 15th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 1\n\n 37\n\n May 15\n\n Deprecation of some (Resolv) Pyth Push Feeds on Base, Ethereum, Arbitrum, HyperEVM and Solana – May 31st, 2026\n\n Price Feeds\n\n announcements\n\n 1\n\n 33\n\n Jun 2\n\n Deprecation of Pyth Push Feeds - 15th January, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 170\n\n Jan 15\n\n Deprecation of Pyth Push Feeds on Soneium - 7th December, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 229\n\n Dec 2025\n\n Deprecation of Pyth Push Feeds on Aptos – April 30th, 2026\n\n Announcements\n\n announcements,move\n\n 1\n\n 95\n\n May 1\n\n Powered by Discourse","tokens":1317,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260328607,"hash":"dfb1393abe5304b55c69a63a90a781075bca2e40"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"A local-node-favoring delta to the scaling roadmap \n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 1 / 55\n\n May 2025\n\n Jun 2025\n\n post by vbuterin on May 18, 2025\n\n vbuterin\n\n Special thanks to Micah Zoltu, Toni Wahrstätter, Justin Traglia and pcaversaccio for discussion\nThe most common criticism of increasing the L1 gas limit, beyond concerns about network safety, is that it makes it harder to run a full node.\nEspecially in the context of a roadmap focused on unbundling the full node, addressing this requires an understanding of what full nodes are for.\nHistorically, the thinking has been that full nodes are for validating the chain; see here for my own exposition of what could happen if regular users cannot verify. If this is the only issue, then L1 scaling is unlocked by ZK-EVMs: the only limit is keeping the block building and proving costs low enough that both can remain 1-of-n censorship-resistant and a competitive market.\nHowever, in reality this is not actually the sole concern. The other major concern is: it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way. This document will discuss adjustments to the current L1 scaling roadmap that make this happen.\nWhy not stop with trustlessness and privacy via ZK-EVM + PIR?\nThe privacy roadmap I published last month focuses on TEEs + ORAM as a short-term patch plus PIR as a long-term solution. This, together with Helios and ZK-EVM verification, would allow any user to connect to external RPCs and be fully confident that (i) the chain they are getting is correct, and (ii) their data privacy is protected. So it is worth asking the question: why not stop here? Don’t these kinds of advanced cryptographic solutions make self-hosted nodes an outdated relic?\nHere I can give a few replies:\n\nFully trustless cryptographic solutions (ie. 1-server PIR) will be expensive. Currently the overhead is impractically high, and even after many efficiency improvements it is likely to stay expensive.\nMetadata privacy. The data of which IP address makes requests at what times, and the pattern of requests, is itself enough to reveal a lot of information about users.\nCensorship vulnerability: a market structure dominated by a few RPC providers is one that will face strong pressure to deplatform or censor users. Many RPC providers already exclude entire countries.\n\nFor these reasons, there is value in continuing to ensure greater ease of running a personal node.\nShort-term priorities\n\nUp-prioritize a full rollout of EIP-4444, all the way up to the final end state where each node stores data for only ~36 days. This greatly reduces disk space requirements, which are the primary issue preventing more people from running nodes. After this, the disk space requirements for a node will be (i) state size, (ii) state Merkle branches, (iii) 36 days of history.\nBuild a distributed history storage solution, by which each node can store a small percentage of historical data older than the cutoff. Use erasure coding to maximize robustness. This ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\nAdjust gas pricing to make storage more expensive and execution less expensive. A particularly high priority is increasing the gas cost of creating new state: (i) SSTORE for new storage slots, (ii) contract code creation, (iii) sending ETH to accounts that do not yet have a balance or nonce.\n\nMedium-term priority: stateless verification\nOnce we enable stateless verification, it becomes possible to run an RPC-capable node (ie. one that stores the state) without storing state Merkle branches. This further decreases storage requirements by ~2x.\nA new type of node: partially stateless nodes\nThis is the new idea, and will be key for allowing personal node operation even in a context where the L1 gas limit grows by 10-100x.\nWe add a node type which verifies blocks statelessly, and verifies the whole chain (either through stateless validation or ZK-EVM) and keeps up-to-date a portion of the state. The node is capable of responding to RPC requests as long as the required data is within that subset of the state; other requests will fail (or have to fallback to an externally-hosted cryptographic solution; whether or not to do this should be the user’s choice).\npartial_statelessness.drawio776×341 19.9 KB\nThe exact portion of the state to be held will depend on a config chosen by the user. Some examples might be:\n\nAll state except for contracts that are known to be spam\nState associated with all EOAs and SCWs and all commonly used ERC20 and ERC721 tokens and applications\nState associated with all EOAs and SCWs that have been accessed in the last two years, some commonly used ERC20 tokens, plus a limited curated set of swap, defi and privacy applications\n\nThe config could be managed by an onchain contract: a user would run their node with --save_state_by_config 0x12345...67890, and the address would specify in some language a list of addresses, storage slots or otherwise filtered regions of the state that the node would save and keep up to date. Note that there is no need for the user to save Merkle branches; they only need to save the raw values.\nThis type of node would give the benefits of direct local access to the state that a user needs to care about, as well as maximal full privacy of access to that state.\n\n The Future of State, Part 2: Beyond The Myth of Partial Statefulness & The Reality Of ZKEVMs\n\n State Expiry: In-protocol vs. Out-of-protocol\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n post by GalRogozinski on May 19, 2025\n\n GalRogozinski\n\n Interesting!\nExcuse my silliness, but why do you offer to save the config onchain? Why not have a free and private config in a file?\n\n post by amadeobrands on May 19, 2025\n\n amadeobrands\n\n Makes sense.\nThe main goal should be to make L1 fast enough to enable on-chain price discovery for assets. L1 should serve as the global settlement layer, even for all L2 prices. Assets seeking hard settlement guarantees should originate on L1.\nI believe this approach can achieve that state, but we need to recognize that many people, including myself, prefer to hold major assets on L1 rather than L2s.\n\n post by vbuterin on May 19, 2025\n\n vbuterin\n\n GalRogozinski\n\n it’s a convenience feature to allow a third-party actor (could be a DAO) to keep the config up to date.\n\n post by Vitomir2 on May 19, 2025\n\n Vitomir2\n\n Pretty interesting read — thanks for sharing!\nI’m curious about the longer-term history though. What if someone wants to verify transactions from, say, five years ago on Etherscan?\nWould that still be possible after implementing a mechanism that retains history for only 36 months?\n\n post by bklnf on May 19, 2025\n\n bklnf\n\nSorry, but 4tb nvme cost is 300-500usd.\nMain blocker from running a node is the size of 32ETH deposit.\nRunning node with x10(at least) less deposit will onboard whole new wave of home node operators\n\n post by Noveleader on May 19, 2025\n\n Noveleader\n\n Vitomir2\n\n It is 36 days.\nThe goal here is to ease out the local node running process. I think the global data would still be dependent on RPCs.\n\n post by Killari on May 19, 2025\n\n Killari\n\n Cool ideas!\nRather than DAO or on-chain config managing on what state the node is keeping, I would give this power to the node operators. We could have an UI that would let user select and add what ever addresses to maintain state for. You could have a DAO managing address metadatas, eg uniswap pools = [0x23, 0x12], tornadoCash = [0x23…]. And the user could then check the checkboxes which state to manage.\nA good example of this is IPFS desktop, that lets users to select which data to keep. The user should be able to select and deselect these addresses at any time and the node would start to adapt to users preferences (slowly, but eventually as retrieving new data from decentralized network takes time). IPFS has wanted_list system that manages this. You could also have some private RPC methods that allow you to manage on what data to keep and what not to keep.\n\n post by Killari on May 19, 2025\n\n Killari\n\n bklnf\n\n You need 0 eth to run a node, there’s no 32 ETH deposit requirements. The 32 ETH is required to run a validator. This thread is about running nodes, not validators.\n\n post by GregTheGreek on May 19, 2025\n\n GregTheGreek\n\nIf we’re on the topic of more at home setups, it should be noted we probably need to draw down ingress/egress. Depending on where you are the concept of unlimited bandwidth might not exist.\nI’m aware there are efforts to potentially erasure code, and do more structure gossiping on the p2p level but would probably bake this in as a concern for this sub group of node operators.\n\n post by MicahZoltu on May 19, 2025\n\n MicahZoltu\n\nYou are talking about stakers. This post is talking about end-users of Ethereum who need the ability to execute against state in a censorship resistant and privacy preserving way. These people do not have 32 ETH, and most of them may not have $500 to spend.\n\n post by soispoke on May 19, 2025\n\n soispoke\n\nThis relates to some recent thoughts we had around Validity-Only Partial Statelessness (VOPS): nodes keeping just enough data to ensure they can maintain a healthy mempool to ensure we can scale while preserving CR. This would result in just storing the account data, and gives us 25x storage reduction.\nI really like the general approach of providing more flexibility in what partial-state nodes choose or need to store, depending on the use case:\n\nNodes actively participating in protocol duties (e.g., attesters, FOCIL includers) could be required to store at least the state necessary to maintain the mempool (VOPS).\nHowever, there shouldn’t be strict requirements for nodes that simply want to read the chain in a trustless, CR-preserving, and privacy-friendly manner. They should just be able to keep as much state as they want depending on how often they would have to query state from elsewhere. But then the “elsewhere” part is still very important, and we’re trying to see if Portal could provide a good enough solution for random access lookups there.\n\n post by MicahZoltu on May 19, 2025\n\n MicahZoltu\n\nThis could be a good use for something like GitHub - Austin-Williams/cid-accumulator-monorepo: Trustless, decentralized CID accumulator for smart contracts —append, verify, and retrieve all your on-chain data via IPFS., so your on-chain updates would be on the order of 10,000s of gas with ~0 state growth, but it would perpetually link to a file that was maintained on the IPFS network by anonymous 3rd parties.\nIt is limited to append only, but you could split the files into 12 month epochs, and each file would contain a journal of additions and removals from which you can rebuild the final set for each epoch. One could imagine some way to materialize the epochs into a different format via social layer so you have a base list + accumulator over the course of a year.\n\n post by CPerezz on May 19, 2025\n\n CPerezz\n\nThis I assume is opening the door for Wallets or Dapps to follow some sort of “Dapp storage support” where they store their part of the state and serve to their users while at the same time, they keep the nodes to assert correct root.\nThen, they can serve RPC requests to their users (who can follow the chain with something like VOPS.\nSo, in short, are wallets and Dapps the parties who we pretend to handle over the state storing and the RPC serving wrt their protocol-related data?\nIf so (and I think this makes sense) within stateless-consensus we’re carrying over a survey with Wallets and Dapps for stateless-related questions.\nWould you be up for some feedback and proposing questions we should ask them or things/opinions/takes from their side?\nOne of our fears has always been that Dapps (specially good and useful ones) are a scarce resource. And putting more burden on them to build this partial RPC servers might be complex.\nWhat’s your take?\n\n post by daniellehrner on May 19, 2025\n\n daniellehrner\n\n With Besu we already have an implementation of the flat state without the Merkle nodes and can confirm that it reduces the disk requirements drastically. For mainnet the full state only requires 80GB like that. Saving only part of the state would only be a small change.\nThe remaining challenge is adding proofs to verify the state.\n\n post by MicahZoltu on May 19, 2025\n\n MicahZoltu\n\nThis isn’t the future I personally want to see play out, though I recognize that it is a possibility (if I correctly understand what you are describing). What I would like to see play out is end-users are able to run their own RPC servers that follow head and store the vast majority of all interesting state on Ethereum. They would only drop things like spam/scam tokens, and state from apps that haven’t been touched in a decade (which combined I suspect is probably a very significant chunk of state usage on Ethereum if I had to take a wild guess).\nWith some proof related improvements, a trustless node like this could probably use less than 100GB without any state dropping, and maybe less than 50GB with state dropping. This combined with UX improvements around node operations, and having these clients not execute blocks themselves (just validate proofs), and we can imagine a future where users just double click an installer and it runs in the background until the next hard fork (where they will have to update).\n\n post by vbuterin on May 19, 2025\n\n vbuterin\n\n soispoke\n\n I think VOPS makes sense. One nuance that is worth keeping in mind is how these whole ideas would intersect with full AA (EIP-7701).\nIt feels like recently the way full AA thinking is trending is, keeping the protocol-level EIP itself minimal, and then encouraging the development of custom mempools that support custom sets of validity conditions targeting specific application categories (eg. wallets, privacy protocols, defi protocols [so you can safely make swaps with zero slippage tolerance and thereby protect yourself from sandwiching])\nWhat this implies is that “which partial state you have to keep” itself becomes mempool specific, and so it’s a choice of each node implementation.\nWhich seems like it is compatible with the idea as a whole? Because there is no need for any global consensus on which state is kept and which state is not kept.\n\n post by juanfranblanco on May 19, 2025\n\n juanfranblanco\n\n A couple of thoughts,\nI believe that eventually enabling Dapps or users selecting the state they require will be ideal, not just a mini node level. User opens an application mobile / desktop / game / web (local storage or probably here a mini node to support it) and has the state they required synced, it might not be the whole 1 gig for the USDC Erc20 (tested that a year ago), but a fraction. A more complex data store like a game, or generic application, you store your data, validate and sync, when opening your app.\nThis types of applications could use “session / temporary delegated accounts”, like the ones in MUD, encouraging a more secure behaviour per account, and phishing attempts.\nDistributed history could be complemented with other data, like transactions per account, which is left to indexers (although the current indexers, like etherscan, etc, could be the ones that create a new type of verification layer for this type of data), and ideally use that opportunity to store the transfer of Eth or “native tokens in L2s / L(x)s” without making any changes like Optimism tried before, to simplify the process.\nApps verify with proofs the data / simulate, etc… which could be done now if “eth_getProofs” like “helios” but I guess easier with verkle trees, when available.\n\n post by CPerezz on May 19, 2025\n\n CPerezz\n\nThis is exactly what state expiry will get us eventually.\nI don’t think we disagree. I think the only problem we have here is that vast majority of all interesting state is something that will be HUGE if Ethereum becomes the ground for all economy-related activities in the future.\nL2s will help there too ofc.\n\nNevertheless, the amount of interesting state tends to infinity when time grows enough. And that is something that no measure (neither state expiry can solve).\n\nThus, the idea from Vitalik makes a lot of sense in combination with these types of nodes loke VOPS or Ress.\nUsers can follow the tip of the chain trustlessly, participate in consensus duties and keep healthy mempools for FOCIL or tx broadcasting.\nOn the other hand, Dapps and Wallets can keep the piece of protocol-related state only instead of a bunch of useless data they’ll never use for anything.\nThen, these Wallets and Dapps can have a much easier time serving requests via RPC to their users specifically which can be verified against trustlessly-asserted roots.\nOtherwise, we always need a GOOD_SAMARITAN who will serve this data to users that don’t want to store anything locally. Maybe not now. Maybe not in 10 years even.\nBut eventually, the fact that this happens means ethereum succeeded and became so big and important that we need to rely on these solutions.\nThe only caveat to all these discussions, is that this is only possible if the block producer HAS ALL THE STATE. Otherwise, strong_statelessness-like solutions will significantly harm UX unless a ton of effort is put. And won’t enable gas_scaling nor following the tip of the chain at such a low cost.\n\n post by soispoke on May 19, 2025\n\n soispoke\n\nAgreed, we had an “AA-VOPS” section in the post, where each node would only need to track the accounts it actively cares about (its own EOAs, those it interacts with, and frequently accessed contracts such as TokenPaymaster and USDC), maintaining a small local cache that is updated incrementally over time using stateDiffs from block producers.\nBut this comes at the cost of having to attach witnesses to transactions, leading to similar challenges as those found in strong statelessness proposals (higher P2P bandwidth, latency overhead, and the question of who should hold the full state then). Also unlike in your proposal, these nodes couldn’t really be queried in a general-purpose way, since they only hold state for the accounts they care about.\n\nI think it is compatible with the general idea, but the nuance there is that we probably need global consensus on which state is kept for protocol participants that are responsible for preserving CR? Ideally we wouldn’t have to trade off CR for cool applications leveraging full AA, but not sure how to resolve that tension. If full AA at the protocol-level is minimal and close to what we have with 7702 (or at least only requires small, non-expensive checks for txn validity), then we could do something like:\n\nAttesters and includers are required to hold validity-only state to preserve strong CR and, optionally, any state needed to support a particular application/protocol making use of full AA (they would signal this somehow to make sure this state can be queried from them)\n\nAny dApp or wallet making use of full AA is responsible for holding the corresponding state and generate witnesses associated with user transactions, or broadcast the txns in a specific mempool\n\nNodes staking 2048 ETH are required to store the full state\n\nPortal provides good guarantees about random state access\n\n Load more posts below","tokens":4866,"squid":"ink-research","role":"Deep Scholar","at":1791260332675,"hash":"7bd933b7aa0fb564fd230518de9fb39e690e8ff0"}
{"url":"https://dev-forum.pyth.network/c/announcements/6/l/latest","domain":"dev-forum.pyth.network","title":"Latest Announcements topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Announcements\n\n Announcements\n\n subcategories\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Welcome to the Announcements category\n\n Announcements\n\n Official updates related to Pyth, Pyth products and more! \nHere you’ll find: \n\n Network and protocol updates \n\n Product releases and feature announcements \n\n Developer tool upgrades…\n\n read more\n\n 0\n\n 499\n\n Mar 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 190\n\n Jul 13\n\n Deprecation of Swellchain, Pyth Oracle on will be unavailable - June 15, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 25\n\n Aug 20\n\n Deprecation of Pyth Core Equity PRE, POST and OVERNIGHT Feeds – 15th June 2026\n\n Announcements\n\n announcements\n\n 1\n\n 128\n\n Jun 17\n\n Deprecation of Price Feeds (CRT, ZENBTC) Price Feed - 31st May, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 28\n\n Jun 2\n\n Deprecation of some Pyth Push Feeds on Sonic EVM – May 15th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 1\n\n 37\n\n May 15\n\n [Deprecation Notice] Pyth Pro `/v1/{channel}/streaming` Endpoint — Sunset May 31, 2026\n\n Announcements\n\n 1\n\n 66\n\n Jun 2\n\n Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 55\n\n Apr 30\n\n Deprecation of Pyth Push Feeds on Aptos – April 30th, 2026\n\n Announcements\n\n announcements,move\n\n 1\n\n 95\n\n May 1\n\n Price Feeds Upcoming Deactivations – April 15th, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 57\n\n Apr 15\n\n 30th April 2026 - Migration of Pyth History API to a New Base URL\n\n Announcements\n\n 0\n\n 111\n\n Mar 30\n\n Pyth Core: Wormhole Guardian Set Upgrade — Action Required for Forks\n\n Announcements\n\n announcements\n\n 0\n\n 76\n\n Mar 3\n\n Pyth Pro: EMA Price and Confidence Fields Now Available\n\n Announcements\n\n 0\n\n 62\n\n Feb 25\n\n Pyth Pro: Update to price `payload` in API Responses\n\n Announcements\n\n 0\n\n 220\n\n Feb 25\n\n Pyth Pro Proxy API\n\n Announcements\n\n 0\n\n 74\n\n Feb 11\n\n Added a new feature in docs for AI\n\n Announcements\n\n announcements\n\n 0\n\n 79\n\n Feb 6\n\n Pyth Pro FAQ now live\n\n Announcements\n\n 0\n\n 81\n\n Feb 2\n\n New Documentation: SVM Error Codes Reference Page\n\n Announcements\n\n svm\n\n 0\n\n 115\n\n Jan 20\n\n Price Feeds Upcoming Deactivations – January 16th, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 130\n\n Jan 19\n\n Deprecation of Pyth Custom TWAP feature — 31st January, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 161\n\n Feb 6\n\n Q1 2026 — Pyth Core Onchain Fees\n\n Announcements\n\n announcements\n\n 0\n\n 133\n\n Jan 7\n\n Q1 2026 — Pyth Entropy Onchain Fees  pyth.network\n\n Announcements\n\n entropy\n\n 1\n\n 151\n\n Feb 12\n\n Deprecation of Pyth Push Feeds - 15th January, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 170\n\n Jan 15\n\n Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 498\n\n Jan 3\n\n Deprecation of Pyth Push Feeds on Soneium - 7th December, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 229\n\n Dec 2025\n\n Deprecation of ALP/USD.RR on Pyth - Sunday, 16th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 261\n\n Nov 2025\n\n Migration from AI16Z/USD to ELIZAOS/USD – Sunday 16th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 273\n\n Nov 2025\n\n Deprecation of DEUSD/USD and SDEUSD/DEUSD.RR feeds on Pyth - 9th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 312\n\n Nov 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 548\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 338\n\n Oct 2025","tokens":1775,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260339849,"hash":"065e8a863b1b9c514a898e39278f7a96f2e95358"}
{"url":"https://io.net/docs/guides/explorer/inferences-page","domain":"io.net","title":"Inferences - io.net","text":"​Key Metrics Displayed:\n\nTotal Inference Count (cumulative number of inferences processed)\nTotal On-Chain Transactions (total recorded transactions on the blockchain)\nToday’s Inference Count (number of inferences processed within the last 24 hours)\nToday’s On-Chain Transactions (transactions recorded on-chain today)\n\n​List of Inferences\nThe Inferences Table offers a transparent, real-time view of transactions conducted on the network.\nThe table includes:\n\nTransaction Status (successful, pending, or failed)\nLink to View Transaction Details\nDate (when the inference was processed)\nTime (specific timestamp of execution)\nComputed By (identification of the computing resource used)\n\n​Inference Details Page\nClicking on a transaction opens a detailed view with the following information:\n\nInference ID (unique identifier for the transaction)\nStatus (completed, pending, or failed)\nDate (when the inference was executed)\nComputation Time (duration in minutes/seconds)\nInference Micro Transaction URL (on-chain transaction record)\nRequested By App URL (source application that initiated the request)\n\nThis page provides full transparency into how inferences are processed within the network, enabling users to track transaction history and ensure accuracy in AI computations.\nWas this page helpful?","tokens":324,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260339894,"hash":"10fe9947c3c50b6ccec663b43c560812031e122f"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/63","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 55 / 55\n\n Jun 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791260342971,"hash":"af06e3d43c079b368681881fbf0acd10bb398bf4"}
{"url":"https://io.net/docs/guides/explorer/homepage","domain":"io.net","title":"Home - io.net","text":"Information that can be viewed in the Home page include:\nReady-to-Use Devices Secured with $IO Staking: Each device in the network is pre-configured and secured by a stake in $IO, proportional to its computational capacity. This ensures security, reliability, and efficient resource allocation.\nTotal Cluster Readiness & Fully Collateralized GPUs/CPUs: This section displays the number of available GPUs and CPUs in the network, including both hired and idle devices. Only Cluster-Ready Devices - those that have successfully passed Proof of Work and are ready for deployment - are included.\n\n​Supply Insights & Geographic Distribution\nThe Homepage Dashboard provides real-time data on active hardware across the network, helping users assess resource availability and optimize their computational needs.\nThe block “Supply Insights & Geo Distribution” displays:\n\nSelected country/region\nTotal number of available GPUs/CPUs and currently hired devices\nA breakdown of devices by type and availabilitye\n\n​Trending Devices\nThe Trending Devices table showcases the latest high-performance GPUs and CPUs optimized for AI model training and inference. Users can filter devices by brand, technology, and connectivity tiers to find the most suitable hardware for their needs.\nThe table includes:\n\nDevice (Model & Specifications)\nQuantity (Available Units)\nPrice (Cost per Usage)\nManaged Service Option (Contact button for top-tier devices))\n\nWas this page helpful?","tokens":364,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260361769,"hash":"084af0be29b24e95202dd92c23ab053ee48ccf0f"}
{"url":"https://dev-forum.pyth.network/t/deprecation-of-swellchain-pyth-oracle-on-will-be-unavailable-june-15-2026/782","domain":"dev-forum.pyth.network","title":"Deprecation of Swellchain, Pyth Oracle on will be unavailable - June 15, 2026 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Deprecation of Swellchain, Pyth Oracle on will be unavailable - June 15, 2026 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 18\n\n 1 / 2\n\n May 17\n\n Aug 20\n\n post by KemarTiti on May 18\n\n KemarTiti\n\n gm Pythians,\nFollowing the scheduled sunset of Swellchain on June 15, 2026, the Pyth oracle will no longer be available on Swellchain from that date onward.\nAs Swellchain winds down, Pyth price feeds will naturally become unavailable on the network accordingly. For developers currently building on Swellchain, the main action item is to migrate to another supported chain ahead of the shutdown. From a Pyth integration perspective, not much changes beyond the need to move your deployment environment.\nTimeline\n\nJune 15, 2026 — Swellchain is scheduled to sunset\n\nWhat developers should do\n\nPlan migration off Swellchain before June 15\nMove any dependencies on Pyth price feeds to another supported chain\nUpdate contracts, infrastructure, and integrations accordingly\n\nReference\n\nSwell announcement: https://x.com/swellnetworkio/status/2049065334536016382\n\n 3 months later\n\n post by KemarTiti on Aug 20\n\n KemarTiti\n\n This has been done already\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Deprecation of some Pyth Push Feeds on Solana – April 30th, 2026\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 55\n\n Apr 30\n\n Deprecation of ALP/USD.RR on Pyth - Sunday, 16th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 261\n\n Nov 2025\n\n Deprecation of Pyth Sponsored Feeds on Optimism Sepolia - 9th September, 2025\n\n Announcements\n\n announcements\n\n 0\n\n 361\n\n Sep 2025\n\n Powered by Discourse","tokens":1368,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260362041,"hash":"c933462f9b26e8dff8816631c6cf65ecf12a4f7f"}
{"url":"https://vitalik.eth.limo/general/2020/08/20/trust.html","domain":"vitalik.eth.limo","title":"Trust Models","text":"Dark Mode Toggle\n\n Trust Models \n 2020 Aug 20 \nSee all posts\n\n Trust Models \n\nOne of the most valuable properties of many blockchain applications\nis trustlessness: the ability of the application to continue\noperating in an expected way without needing to rely on a specific actor\nto behave in a specific way even when their interests might change and\npush them to act in some different unexpected way in the future.\nBlockchain applications are never fully trustless, but some\napplications are much closer to being trustless than others. If we want\nto make practical moves toward trust minimization, we want to have the\nability to compare different degrees of trust.\nFirst, my simple one-sentence definition of trust: trust is\nthe use of any assumptions about the behavior of other people.\nIf before the pandemic you would walk down the street without making\nsure to keep two meters' distance from strangers so that they could not\nsuddenly take out a knife and stab you, that's a kind of trust: both\ntrust that people are very rarely completely deranged, and trust that\nthe people managing the legal system continue to provide strong\nincentives against that kind of behavior. When you run a piece of code\nwritten by someone else, you trust that they wrote the code honestly\n(whether due to their own sense of decency or due to an economic\ninterest in maintaining their reputations), or at least that there\nexist enough people checking the code that a bug would be found.\nNot growing your own food is another kind of trust: trust that enough\npeople will realize that it's in their interests to grow food\nso they can sell it to you. You can trust different sizes of groups of\npeople, and there are different kinds of trust.\nFor the purposes of analyzing blockchain protocols, I tend to break\ndown trust into four dimensions:\n\nHow many people do you need to behave as you expect?\nOut of how many?\nWhat kinds of motivations are needed for those people to behave? Do\nthey need to be altruistic, or just profit seeking? Do they need to be\nuncoordinated?\nHow badly will the system fail if the assumptions are violated?\n\nFor now, let us focus on the first two. We can draw a graph:\n\nThe more green, the better. Let us explore the categories in more\ndetail:\n\n1 of 1: there is exactly one actor, and the system\nworks if (and only if) that one actor does what you expect them to. This\nis the traditional \"centralized\" model, and it is what we are trying to\ndo better than.\nN of N: the \"dystopian\" world. You rely on a whole\nbunch of actors, all of whom need to act as expected for\neverything to work, with no backups if any of them fail.\nN/2 of N: this is how blockchains work - they work\nif the majority of the miners (or PoS validators) are honest. Notice\nthat N/2 of N becomes significantly more valuable the larger the N gets;\na blockchain with a few miners/validators dominating the network is much\nless interesting than a blockchain with its miners/validators widely\ndistributed. That said, we want to improve on even this level of\nsecurity, hence the concern around surviving 51%\nattacks.\n1 of N: there are many actors, and the system works\nas long as at least one of them does what you expect them to. Any system\nbased on fraud proofs falls into this category, as do trusted setups\nthough in that case the N is often smaller. Note that you do want the N\nto be as large as possible!\nFew of N: there are many actors, and the system\nworks as long as at least some small fixed number of them do what you\nexpect them do. Data\navailability checks fall into this category.\n0 of N: the systems works as expected without any\ndependence whatsoever on external actors. Validating a block by checking\nit yourself falls into this category.\n\nWhile all buckets other than \"0 of N\" can be considered \"trust\", they\nare very different from each other! Trusting that one particular person\n(or organization) will work as expected is very different from trusting\nthat some single person anywhere will do what you expect them\nto. \"1 of N\" is arguably much closer to \"0 of N\" than it is to \"N/2 of\nN\" or \"1 of 1\". A 1-of-N model might perhaps feel like a 1-of-1 model\nbecause it feels like you're going through a single actor, but the\nreality of the two is very different: in a 1-of-N system, if\nthe actor you're working with at the moment disappears or turns evil,\nyou can just switch to another one, whereas in a 1-of-1 system you're\nscrewed.\nParticularly, note that even the correctness of the software you're\nrunning typically depends on a \"few of N\" trust model to ensure that if\nthere's bugs in the code someone will catch them. With that fact in\nmind, trying really hard to go from 1 of N to 0 of N on some other\naspect of an application is often like making a reinforced steel door\nfor your house when the windows are open.\nAnother important distinction is: how does the system fail if your\ntrust assumption is violated? In blockchains, two most common types of\nfailure are liveness failure and safety\nfailure. A liveness failure is an event in which you are\ntemporarily unable to do something you want to do (eg. withdraw coins,\nget a transaction included in a block, read information from the\nblockchain). A safety failure is an event in which something actively\nhappens that the system was meant to prevent (eg. an invalid block gets\nincluded in a blockchain).\nHere are a few examples of trust models of a few blockchain layer 2\nprotocols. I use \"small N\" to refer to the set of\nparticipants of the layer 2 system itself, and \"big N\"\nto refer to the participants of the blockchain; the assumption is always\nthat the layer 2 protocol has a smaller community than the blockchain\nitself. I also limit my use of the word \"liveness failure\" to cases\nwhere coins are stuck for a significant amount of time; no longer being\nable to use the system but being able to near-instantly withdraw does\nnot count as a liveness failure.\n\nChannels (incl state channels, lightning network):\n1 of 1 trust for liveness (your counterparty can temporarily freeze your\nfunds, though the harms of this can be mitigated if you split coins\nbetween multiple counterparties), N/2 of big-N trust for safety (a\nblockchain 51% attack can steal your coins)\nPlasma (assuming centralized operator): 1 of 1\ntrust for liveness (the operator can temporarily freeze your funds), N/2\nof big-N trust for safety (blockchain 51% attack)\nPlasma (assuming semi-decentralized operator, eg.\nDPOS): N/2 of small-N trust for liveness, N/2 of big-N trust for\nsafety\nOptimistic rollup: 1 of 1 or N/2 of small-N trust\nfor liveness (depends on operator type), N/2 of big-N trust for\nsafety\nZK rollup: 1 of small-N trust for liveness (if the\noperator fails to include your transaction, you can withdraw, and if the\noperator fails to include your withdrawal immediately they cannot\nproduce more batches and you can self-withdraw with the help of any full\nnode of the rollup system); no safety failure risks\nZK rollup (with light-withdrawal\nenhancement): no liveness failure risks, no safety failure\nrisks\n\nFinally, there is the question of incentives: does the actor you're\ntrusting need to be very altruistic to act as expected, only slightly\naltruistic, or is being rational enough? Searching for fraud proofs is\n\"by default\" slightly altruistic, though just how altruistic it is\ndepends on the complexity of the computation (see the verifier's dilemma),\nand there are ways to modify the game to make it rational.\nAssisting others with withdrawing from a ZK rollup is rational if we\nadd a way to micro-pay for the service, so there is really\nlittle cause for concern that you won't be able to exit from a rollup\nwith any significant use. Meanwhile, the greater risks of the other\nsystems can be alleviated if we agree as a community to\nnot\naccept 51% attack chains that revert too far in history or censor\nblocks for too long.\nConclusion: when someone says that a system \"depends on trust\", ask\nthem in more detail what they mean! Do they mean 1 of 1, or 1 of N, or\nN/2 of N? Are they demanding these participants be altruistic or just\nrational? If altruistic, is it a tiny expense or a huge expense? And\nwhat if the assumption is violated - do you just need to wait a few\nhours or days, or do you have assets that are stuck forever? Depending\non the answers, your own answer to whether or not you want to use that\nsystem might be very different.","tokens":2094,"squid":"ink-research","role":"Deep Scholar","at":1791260378054,"hash":"723a07e5c38def74c5899bfe21710403dc134414"}
{"url":"https://gov.optimism.io/c/communications/delegate-updates/45","domain":"gov.optimism.io","title":"Latest Communications 📣/Delegate Updates topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in Delegate Updates\n\n Communications 📣\n\n Delegate Updates\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Delegate Communication category\n\n This subcategory is for Delegate Communication. New delegates may introduce themselves here, and existing delegates may create communication threads to share updates about their voting.\n\n 0\n\n 327\n\n May 2022\n\n PGov - Delegate Communication Thread\n\n Delegate Name: @PGov \nDelegate Address: PGov.eth (0x3fb19771947072629c8eee7995a2ef23b72d4c8a) \nForum Handle: @PGov, @Juanbug_PGov \nEmail: PGovTeam@gmail.com \nCore Principles: \n\nTransparency: Clear communication with vote…\n\n read more\n\n 45\n\n 3.6k\n\n Sep 2\n\n Brichis - Delegate Communication Thread\n\n Delegate statement \nFirstly, allow me to introduce myself. My name is Bricia, although you’re welcome to call me Brichis and I am Co-Founder of Ethereum Mexico. \nMy decision to become a delegate was sparked by discussio…\n\n read more\n\n 48\n\n 3.9k\n\n Aug 21\n\n FranklinDAO (Penn Blockchain) - Delegate Communication Thread\n\n Address or ENS: FranklinDAO.eth \nDiscord username: Juanbug#9225 \nHello everyone! We’re FranklinDAO/Penn Blockchain (@PennBlockchain on twitter), a leading, completely student run blockchain organization from The Universi…\n\n read more\n\n 5\n\n 2.2k\n\n Aug 21\n\n AlexSotoDigital.eth - Delegate Communication Thread\n\n Here my Delegate Statement \n\nHi! \nFirst let me introduce myself. My name is Alex Soto, and I’m Mexican and a stubborn optimist. \nI am an independent facilitator and consultant on organizational de…\n\n read more\n\n 16\n\n 584\n\n Jul 9\n\n Axia Network — Delegate Communications Thread\n\n Axia Network is a delegate across DAOs in the EVM ecosystem. Axia is committed to growing alongside the ecosystem and contributing responsibly to each protocol’s long-term success. \nAxia’s values emphasize supporting pro…\n\n read more\n\n 2\n\n 139\n\n Jun 1\n\n GFX Labs - Delegate Communication Thread\n\n This thread is intended to provide a record of GFX Labs’ voting and communication around the reasoning of each vote. Subsequent voting communications will be added to this thread over time. \n3 Polls Ending June 26 \nPropo…\n\n read more\n\n 63\n\n 8.6k\n\n Apr 21\n\n Blockful – Delegate Communication Thread\n\n Delegate Name: @blockful \nDelegate Statement: gov.blockful.eth on Agora \nDelegate Address: gov.blockful.eth (0x1f3d3a7a9c548be39539b39d7400302753e20591) \nForum Handle: @blockful, @zeugh \nEmail: forum@blockful.io \nWebsite…\n\n read more\n\n 2\n\n 88\n\n Jan 28\n\n SEEDGov - Delegate Communication Thread\n\n UPDATE Q2 2023: we changed our name to SEED Latam. With this renewed image and enlargement of the scope, we are committed to support communities and leaders in Latam. \n\nRead our vision here – Plataformas de delegados. ¿P…\n\n read more\n\n 64\n\n 13.0k\n\n Jan 27\n\n Polynya - Delegate Communication Thread\n\n I have finished my votes for Gov Fund Phase 1 Season 1. \nMy general impression thus far is that most proposals are a mixed bag, with very few high-quality projects I’d be excited to support without reservations. Since Op…\n\n read more\n\n 44\n\n 6.8k\n\n Jan 26\n\n Formally Announcing Axia Network\n\n season-9\n\n I’m excited to formally announce Axia Network, a natural continuation of the governance work that @404DAO has stewarded over the years. I’m deeply grateful to have worked alongside the team that built 404 — Pruitt, Cole…\n\n read more\n\n 0\n\n 51\n\n Jan 13\n\n L2BEAT - Delegate Communication Thread\n\n Hey! \nIn the previous voting seasons, we were one of the most prominent governance delegators, engaging in various discussions and leading Tooling Governance Committee. \nToday I would like to announce that we are shiftin…\n\n read more\n\n 20\n\n 4.0k\n\n Nov 2025\n\n Lisk Delegate Statement and Communication Thread\n\n Who We Are\nLisk is a Layer 2 blockchain dedicated to bringing Web3 adoption in high-growth markets back to Ethereum. By leveraging cost-efficient, scalable, and innovative Layer 2 technology, Lisk enables real-world appl…\n\n read more\n\n 2\n\n 143\n\n Jun 2025\n\n Superseed – Delegate Communication Thread\n\n Welcome to the Superseed Delegate Communication Thread, a space where we outline our governance participation, share voting decisions, and offer insights on our role as a delegate within the Optimism ecosystem. \nAbout Su…\n\n read more\n\n 3\n\n 141\n\n Jun 2025\n\n Ignas - Delegate Communication Thread\n\n 1. Basic Info \n\nName: Ignas\nDelegate Address: ignasdefi.eth | 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0\nX (Twitter): x.com\nTelegram: @ignasdefi\nWebsite: https://pinkbrains.io/ (Co-founder)\n\n2. Intro \nI’m Ignas, a solo r…\n\n read more\n\n 11\n\n 344\n\n Jun 2025\n\n Blockchain@USC - Delegate Communication Thread\n\n Hello all! We are the blockchain club at the University of Southern California. \nOur delegate address is: 0x995013B47EF3A2B07b9e60dA6D1fFf8fa9C53Cf4 \nHere’s what we stand for:\nMission: In our role as a delegate, we striv…\n\n read more\n\n 8\n\n 2.1k\n\n Apr 2025\n\n Fractal Visions - Delegate Communication Thread\n\n We are posting here as a final post for the time being on the OP Governance forums. \nThis time will serve us over the spring in order to reflect on this past year of work on optimism network. \nOur plan is to continuing w…\n\n read more\n\n 10\n\n 2.3k\n\n Apr 2025\n\n LobbyFi - Delegate Communication Thread\n\n This is the official LobbyFi Delegate Communication Thread for the Optimism DAO. We will post updates, rationale for proposals and voting information. We are here with a positive vision for governance, aiming to improve …\n\n read more\n\n 1\n\n 107\n\n Apr 2025\n\n BOB Manifesto: Bringing Bitcoin’s Perspective to Optimism Governance\n\n We’re excited to formally introduce BOB (Build on Bitcoin) as a governance delegate within the Optimism ecosystem. As the first Bitcoin Layer-2 in the Superchain, we bring a fresh perspective—one that bridges the securit…\n\n read more\n\n 2\n\n 254\n\n Apr 2025\n\n BOB - Delegate Communication Thread\n\n Welcome to the BOB Delegate Communication Thread, where we share our governance participation, voting decisions, and insights as a delegate in the Optimism ecosystem. \nBOB (Build on Bitcoin) is the first Bitcoin Layer-2 …\n\n read more\n\n 1\n\n 131\n\n Apr 2025\n\n Soneium - Delegate Communication Thread\n\n This thread will serve as our official communication channel regarding Soneium’s participation in Optimism governance. As a delegate, we are committed to maintaining transparency and providing detailed rationales for our…\n\n read more\n\n 1\n\n 92\n\n Apr 2025\n\n StableLab - Delegate Communication Thread\n\n Name: StableLab \nDelegate Address: stablenodegov.eth \nGovernance tracking: Boardroom, Internal tracker \nForum: Bobbay_StableLab \nDiscord: Bobbay#4885 \nTwitter: https://twitter.com/Stablelab \nWebsite: https://www.stablela…\n\n read more\n\n 28\n\n 5.3k\n\n Mar 2025\n\n World Republic Delegate - A global democracy experiment in the Token House\n\n Hi everyone! \nI’m Blaise and I’m posting here for the first time to tell you about a new experiment I’m about to launch. \nOptimism’s vision is “to create a new internet that benefits all and is owned by all”, but current…\n\n read more\n\n 1\n\n 81\n\n Mar 2025\n\n RACE Manifesto: Unlocking Global Liquidity\n\n RACE Network Manifesto\nIntroduction\nWho We Are: \nRACE Network is a pioneering Ethereum Layer-2 blockchain purpose-built for real-world asset (RWA) tokenization. Built on Optimism’s OP Stack and now part of the Optimism S…\n\n read more\n\n 2\n\n 154\n\n Feb 2025\n\n Liliop.eth (piurana_inblock) Delegate Communication Thread\n\n Hello @optimism community \nFor those who don’t know me, I’m Lili, some friends call me Lili, others Lilian and some few @piurana_inblock. I grew up in a small town in the north of Peru called Piura and…\n\n read more\n\n 7\n\n 1.1k\n\n Feb 2025\n\n World Foundation: Delegate Statement for Optimism Governance\n\n As representatives of the World Foundation, we are honored to join the Optimism Collective as active participants in governance through the Chain Delegation Program. Our mission, to realize more inclusive, fair, and just…\n\n read more\n\n 1\n\n 303\n\n Feb 2025\n\n Addressing Voting Apathy in Optimism Governance\n\n Hey everyone, \nI’ve been taking some time to dig into participation in Optimism governance, and I wanted to share what I found. Active participation is essential for us to realize Optimism’s vision, but from my observati…\n\n read more\n\n 15\n\n 630\n\n Feb 2025\n\n Anthias Labs - Delegate Communication Thread\n\n Overview\nDelegate Name: @AnthiasLabs \nDelegate Address: anthiaslabs.eth (0x7575f04a46b6d76142723e765f7546c354773406) \nWebsite: anthias.xyz \nTwitter: @anthiasxyz \nEmail: team@anthias.xyz \nAbout Anthias Labs\nAnthias Lab…\n\n read more\n\n 11\n\n 702\n\n Jan 2025\n\n CosmicKi - Delegate Communication Thread\n\n Hi everyone! \nIt is a pleasure for me to kick off this communication thread as a Delegate in the Governance of Optimism. I’m excited to be part of the collective and contribute to the development of meaningful decisions. …\n\n read more\n\n 5\n\n 960\n\n Jan 2025\n\n Ramadhan-Delegate Communication Thread\n\n Greetings, Optimism community! \nMy delegate: https://vote.optimism.io/delegates/0xf6a09dB6967EeED5Dc9A657BD4f39D13aA3cc8d6 \nI’m @R_Kid7 on X & Ramadhan0109 on X and @Ramadhan on Farcaster. The skills I have are Marketing…\n\n read more\n\n 0\n\n 81\n\n Jan 2025","tokens":2330,"squid":"ink-governance","role":"Council Listener","at":1791260388495,"hash":"463f3c0c3acdf9550c90eafbac48ce35f2b4af9a"}
{"url":"https://governance.aave.com/c/governance/4","domain":"governance.aave.com","title":"Latest Governance topics - Aave","text":"Latest topics in Governance\n\n Governance\n\n subcategories\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [TEMP CHECK] AAVEnomics update\n\n Governance\n\n Title: [TEMP CHECK] AAVEnomics update\nAuthor: @ACI\nDate: 2024-07-25\n\nSimple Summary\nThis proposal seeks governance feedback and consensus on leveraging the Safety Module Umbrella update to create a clear path and roadmap…\n\n read more\n\n 20\n\n 11.5k\n\n Aug 2024\n\n Aave Governance Process Document v1\n\n Governance\n\n Aave Governance Process Document v1\nAuthors: ACI \nDate: 2024-08-08 \nIntroduction\nThe “Aave Governance Process’’ is an all-in-one document for contributing to Aave DAO. This document will be continuously updated by Aave D…\n\n read more\n\n 3\n\n 5.3k\n\n Sep 2024\n\n [ARFC] Update the Asset Onboarding Framework\n\n Governance\n\n 2023-11-24 This proposal was edited for improved clarity \n2024-06-17 Proposal updated to reflect latest ARFC Addendum \n\nTitle: [ARFC] Update the Asset Onboarding Framework\nAuthor: Marc Zeller - ACI ( Aave Chan Initiativ…\n\n read more\n\n 7\n\n 5.3k\n\n Dec 2023\n\n [ARFC] ARFC and TEMP CHECK Framework\n\n Governance\n\n Title: [ARFC] Framework for ARFC and TEMP CHECK Proposals \nAuthor: @MarcZeller - Aave Chan Initiative \nDate: 2023-06-27\nSummary\nThis framework provides comprehensive guidelines for the Aave DAO community when creating a…\n\n read more\n\n 17\n\n 10.2k\n\n Dec 2023\n\n Introducing “Skyward” - A Free Service for Aave DAO by Aave-Chan Initiative\n\n Governance\n\n Introducing “Skyward” - A Free Service for Aave DAO by Aave-Chan Initiative\nHello Aave Community, \nWe are excited to announce the launch of a new service by the Aave-Chan Initiative (ACI) - “Skyward”. Inspired by the spi…\n\n read more\n\n 11\n\n 5.8k\n\n Jul 2023\n\n Aave Finance Governance Process v0\n\n Governance\n\n Aave Finance Governance Process v0\nAuthors: @Kene_StableLab, Bobbay_StableNode \nThe “Aave Governance Process” is an all-in-one document for contributing to Aave DAO. This document will be continuously updated by Aave DAO…\n\n read more\n\n 3\n\n 8.7k\n\n Aug 2024\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 765\n\n 8h\n\n [ARFC] The Aave Foundation, Phase 1\n\n Governance\n\n 3\n\n 961\n\n 11h\n\n [ARFC] Deploy Aave V4 on the Monad Network\n\n New Market\n\n 3\n\n 389\n\n 11h\n\n LlamaRisk - Monthly Community Update\n\n Governance\n\n 28\n\n 3.4k\n\n 16h\n\n [Discussion] A second, issuer-controlled verifier for cross-chain GHO on CCIP 2.0\n\n Governance\n\n 0\n\n 61\n\n 1d\n\n [ARFC] Onboard wstLINK to Aave V3 Core Instance\n\n New Asset\n\n 15\n\n 3.1k\n\n 1d\n\n [GHO Stewards] October 2026 - GHO Borrow Rate Update\n\n Governance\n\n 0\n\n 163\n\n 4d\n\n [ARFC] Aave Institutional\n\n Governance\n\n 7\n\n 534\n\n 4d\n\n [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\n\n New Asset\n\n 1\n\n 121\n\n 4d\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Activate Aave Risk Stewards on Aave V4\n\n Governance\n\n 7\n\n 528\n\n 5d\n\n [ARFC] Onboard OUSD to Aave V3 Core Instance and Aave V4 Core Hub\n\n New Asset\n\n 0\n\n 236\n\n 6d\n\n [Direct-to-AIP] Onboard PT-USDG-25FEB2027 on X Layer\n\n New Asset\n\n 0\n\n 75\n\n 6d\n\n [ARFC] Onboard syrupUSDC to Aave V4 on Arc\n\n Governance\n\n 2\n\n 192\n\n 6d\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE\n\n Governance\n\n 3\n\n 772\n\n 11d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n [Direct-To-AIP] Umbrella - Renew Allowances\n\n Governance\n\n 0\n\n 83\n\n 11d\n\n wstETH borrows enabled\n\n Governance\n\n 2\n\n 116\n\n 11d\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 88\n\n 12d\n\n [Direct-to-AIP] Asset Listing - USDe X Layer\n\n New Asset\n\n 2\n\n 120\n\n 13d\n\n [ARFC] Unified Handling of the Isolated Flag in Aave V3.7 E-Modes\n\n Governance\n\n 1\n\n 137\n\n Sep 21\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21","tokens":1007,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260402019,"hash":"84279882e1b6aa393cf0c793d94c45746397372f"}
{"url":"https://eips.ethereum.org/EIPS/eip-2718","domain":"eips.ethereum.org","title":"EIP-2718: Typed Transaction Envelope","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2718: Typed Transaction Envelope\n\n Defines a new transaction type that is an envelope for future transaction types.\n\n Authors\n Micah Zoltu (@MicahZoltu)\n\n Created\n 2020-06-13\n\n Abstract\n\nTransactionType || TransactionPayload is a valid transaction and TransactionType || ReceiptPayload is a valid transaction receipt where TransactionType identifies the format of the transaction and *Payload is the transaction/receipt contents, which are defined in future EIPs.\n\n Motivation\n\nIn the past, when we have wanted to add new transaction types we have had to ensure they were backward compatible with all other transactions, meaning that you could differentiate them based only on the encoded payload, and it was not possible to have a transaction that matched both types.\nThis was seen in EIP-155 where the new value was bit-packed into one of the encoded fields.\nThere are multiple proposals in discussion that define new transaction types such as one that allows EOA accounts to execute code directly within their context, one that enables someone besides msg.sender to pay for gas, and proposals related to layer 1 multi-sig transactions.\nThese all need to be defined in a way that is mutually compatible, which quickly becomes burdensome to EIP authors and to clients who now have to follow complex rules for differentiating transaction type.\n\nBy introducing an envelope transaction type, we only need to ensure backward compatibility with existing transactions and from then on we just need to solve the much simpler problem of ensuring there is no numbering conflict between TransactionTypes.\n\n Specification\n\n Definitions\n\n || is the byte/byte-array concatenation operator.\n\n Transactions\n\nAs of FORK_BLOCK_NUMBER, the transaction root in the block header MUST be the root hash of patriciaTrie(rlp(Index) => Transaction) where:\n\n Index is the index in the block of this transaction\n Transaction is either TransactionType || TransactionPayload or LegacyTransaction\n TransactionType is a positive unsigned 8-bit number between 0 and 0x7f that represents the type of the transaction\n TransactionPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future EIPs\n LegacyTransaction is rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])\n\nAll signatures for future transaction types SHOULD include the TransactionType as the first byte of the signed data.\nThis makes it so we do not have to worry about signatures for one transaction type being used as signatures for a different transaction type.\n\n Receipts\n\nAs of FORK_BLOCK_NUMBER, the receipt root in the block header MUST be the root hash of patriciaTrie(rlp(Index) => Receipt) where:\n\n Index is the index in the block of the transaction this receipt is for\n Receipt is either TransactionType || ReceiptPayload or LegacyReceipt\n TransactionType is a positive unsigned 8-bit number between 0 and 0x7f that represents the type of the transaction\n ReceiptPayload is an opaque byte array whose interpretation is dependent on the TransactionType and defined in future EIPs\n LegacyReceipt is rlp([status, cumulativeGasUsed, logsBloom, logs])\n\nThe TransactionType of the receipt MUST match the TransactionType of the transaction with a matching Index.\n\n Rationale\n\n TransactionType only goes up to 0x7f\n\nFor the forseable future, 0x7f is plenty and it leaves open a number of options for extending the range such as using the high bit as a continuation bit.\nThis also prevents us from colliding with legacy transaction types, which always start with a byte >= 0xc0.\n\n SHOULD instead of MUST for the TransactionType being first byte of signed data\n\nWhile it is strongly recommended that all future transactions sign the first byte to ensure that there is no problem with signature reuse, the authors acknowledge that this may not always make sense or be possible.\nOne example where this isn’t possible is wrapped legacy transactions that are signature compatible with the legacy signing scheme.\nAnother potential situation is one where transactions don’t have a signature in the traditional sense and instead have some other mechanism for determining validity.\n\n TransactionType selection algorithm\n\nThere was discussion about defining the TransactionType identifier assignment/selection algorithm in this standard.\nWhile it would be nice to have a standardized mechanism for assignment, at the time of writing of this standard there is not a strong need for it so it was deemed out of scope.\nA future EIP may introduce a standard for TransactionType identifier assignment if it is deemed necessary.\n\n Opaque byte array rather than an RLP array\n\nBy having the second byte on be opaque bytes, rather than an RLP (or other encoding) list, we can support different encoding formats for the transaction payload in the future such as SSZ, LEB128, or a fixed width format.\n\n ORIGIN and CALLER\n\nThere was discussion about having ORIGIN and CALLER opcodes become dependent on the transaction type, so that each transaction type could define what those opcodes returned.\nHowever, there is a desire to make transaction type opaque to the contracts to discourage contracts treating different types of transactions differently.\nThere also were concerns over backward compatibility with existing contracts which make assumptions about ORIGIN and CALLER opcodes.\nGoing forward, we will assume that all transaction types will have an address that reasonably represents a CALLER of the first EVM frame and ORIGIN will be the same address in all cases.\nIf a transaction type needs to supply additional information to contracts, they will need a new opcode.\n\n Backwards Compatibility\n\nClients can differentiate between the legacy transactions and typed transactions by looking at the first byte.\nIf it starts with a value in the range [0, 0x7f] then it is a new transaction type, if it starts with a value in the range [0xc0, 0xfe] then it is a legacy transaction type.\n0xff is not realistic for an RLP encoded transaction, so it is reserved for future use as an extension sentinel value.\n\n Security Considerations\n\nWhen designing a new 2718 transaction type, it is STRONGLY recommended to include the transaction type as the first byte of the signed payload. If you fail to do this, it is possible that your transaction may be signature compatible with transactions of another type which can introduce security vulnerabilities for users.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Micah Zoltu (@MicahZoltu), \"EIP-2718: Typed Transaction Envelope,\" Ethereum Improvement Proposals, no. 2718, June 2020. Available: https://eips.ethereum.org/EIPS/eip-2718.","tokens":1684,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260402048,"hash":"a1cf0eac1346c832a1e2f40ad5dbf8f36ecd3e87"}
{"url":"https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332","domain":"gov.optimism.io","title":"AlexSotoDigital.eth - Delegate Communication Thread - Communications 📣 / Delegate Updates - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n AlexSotoDigital.eth - Delegate Communication Thread \n\n Communications 📣Delegate Updates\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 14\n\n read \n\n 7\n min\n\n Nov 2024\n\n 1 / 17\n\n Nov 2024\n\n Jul 9\n\n post by alexsotodigital on Nov 29, 2024\n\n alexsotodigital\n\n govNERD\n\n Here my Delegate Statement \n\nHi! \nFirst let me introduce myself. My name is Alex Soto, and I’m Mexican and a stubborn optimist.\nI am an independent facilitator and consultant on organizational development topics with a focus on self-management (Teal, Sociocracy, NVC, etc.)\nI am co-founder of Matriz, a community of freelancers, entrepreneurs, and early-stage collectives that seek to increase the impact of our work through collaboration and mutualization of resources.\nI have been participating in the Optimism collective since 2023 and have been an active contributor since season 6 (where I was a member of the Code of Conduct Council and went through the govNERDs contribution path training).\nMy decision to become a delegate came from having taken the Super Contributor Cohort 0 and recognizing that I had gained enough context to feel comfortable voting on topics.\nAlthough it is clear to me that I am still on a learning path, I consider that I have both the criteria and the experience to take a more active role.\nTo this day, only I have self-delegated the tokens that I hold. I will be honored when that changes, and others begin to consider me as an option to delegate their duties to. I am committed to maintaining transparency and communication to ensure that this is a fruitful relationship.\n\nConflict of Interest Disclosure\n\nI am a co-founder of Matriz\nI am a co-founder of Opus Collective\nI am a member of the following communities: Metagov, OpenCivics, Open Collective, Commons Stack, Frutero Club.\n\n 14\n\n read \n\n 7\n min\n\n post by dmars300 on Nov 30, 2024\n\n dmars300\n\n govNERD\n\n Welcome delegate! It’s so nice to have you in the token house. I’m sure you’ll do a great job\n\n post by Dnng on Nov 30, 2024\n\n Dnng\n\n Helo Alex, nice to meet you\n\n 13 days later\n\n post by alexsotodigital on Dec 13, 2024\n\n alexsotodigital\n\n govNERD\n\n Hello!\nTrying to make this a habit; I share here the reasoning behind my votes in the Special Voting Cycle #31a\nProposals I voted in favor of:\nTreasury Transfer\n\nOnchain Treasury Transfer Test\nOnchain Treasury Transfer Cancellation Test\n → While I’m not entirely clear on the process, I consider it safe enough to experiment.\n\nUpgrade\n\nUpgrade Proposal #11: Holocene Network Upgrade\n → I didn’t think the upgrade brought any risks or dangers that would warrant stopping it.\n\nSeason 7 Intent\n\nSeason 7: Intent Ratification\n → I accept the intent defined for this season, and I celebrate that it is only one (since it promotes greater focus and synergy).\n\nACC\n\nSeason 7: Anticapture Commission Amendment\n → I recognize the value of the ACC but I wonder how static the group of top 100 delegates is. How do we prevent it from solidifying into a power group? How do we promote rotation?\n\nSeason 7 Operating Budgets\n\nSeason 7: Grants Council Operating Budget\nSeason 7: Developer Advisory Board Operating Budget\nSeason 7: Milestones and Metrics Council Operating Budget\nSeason 7: Security Council Operating Budget [Onchain]\n → I attended the Budgets Discussion by L2BEATS and it seems to me that there is a lot of reasoning behind each of these proposals, and I trust their judgment.\nMy only observation is the difference in the range of amounts selected for the compensation of certain roles. I think it would be very valuable if it was better justified where it comes from compared to the value that that profile has in the market or any other process they have done to arrive at that amount.\n\nCOCC\n\nCode of Conduct Council Dissolution Proposal\n → Having been a member of the Code of Conduct Council, I support this proposal for dissolution as it seems to me that a representative structure is not the best way to promote the rules of engagement.\n\nProposals I abstained from:\n\nDecision Market Mission [Onchain]\n → While I find the experiment interesting (and it could bring a lot of value to the collective), I find it confusing to understand why this amount comes from the governance fund and is not considered a mission of the foundation (especially if it is work carried out by external actors). I think more information needs to be shared, so I do not feel comfortable adding to the quorum.\n\nProposals I voted against:\n\nN/A\n\n post by alexsotodigital on Dec 13, 2024\n\n alexsotodigital\n\n govNERD\n\n This being my first report, I welcome any feedback on the format, depth, or anything else that would make this more valuable. \nOf course, I also invite any comments or questions about any of the positions. \n\n 26 days later\n\n post by alexsotodigital on Jan 9, 2025\n\n alexsotodigital\n\n govNERD\n\n I’ll start by saying that making these decisions was a difficult task because I think everyone has great profiles. I’m very excited to see that the group is attracting such capable and talented people. \nIn general terms, I think I prioritized people who have previously served on boards, with a high level of participation and context. I would like to emphasize that I found it difficult to understand the availability of those people who represent a larger team. Comparing people to organizations seems dissonant to me.\nI am also confident that our collective intelligence will ensure that the best candidates are chosen. So be it. \n\nSeason 7 Nominations: Reviewer on the Milestone and Metric Council\nI voted for:\n\nLauNaMu\nmmurthy\nAngela\n → I have selected individuals over teams, hoping that this will translate into greater focus and availability of time on day-to-day work.\n\nSeason 7 Nominations: GrantNerd on the Grants Council\nI voted for:\n\nBrichis\nJrocki\nSov\n → I am prioritizing people with a high level of context and with previous participation in other councils, hoping that they will have a broader perspective in that decision-making.\n\nSeason 7 Nominations: Operations on the Grants Council\nI voted for:\n\nBunnic\n → I have worked briefly with Bunnic and he struck me as being very capable for this type of role.\n\nSeason 7 Nominations: Final Reviewer on the Grants Council\nI voted for:\n\nMichael\njackanorak\nJashFi\nGFX Lab\n → I am prioritizing the profiles that, in my perception, have greater availability and focus for the OP collective, beyond having a great track record in web3.\n\nSeason 7 Nominations: Governance Mission Team on the Developer Advisory Board\nI voted for:\n\nWill\nJepsen\nblockdev\n → I chose those I identified as having greater proximity to the OP Stack and who can integrate learnings from past seasons.\n\nSeason 7 Nominations: Foundation Mission Team on the Developer Advisory Board\nI voted for:\n\nEd\nDanyal\nI choose those who seems to have the most context and knowledge of how the OP foundation works.\n\nSeason 7 Nominations: Audit Request Team on the Developer Advisory Board\nI voted for:\n\nm4rio.eth\nnoah.eth\n–>I chose those who I considered had the best learning context from past seasons.\n\nSeason 7: Security Council Elections Cohort B Members\n\nI abstained to vote\n → because: I don’t think I have enough context to make this decision. I would point out that I find it confusing to compare people to organizations (especially those chains belonging to the superchain). How do we know who is really involved?\n\nSeason 7: Chain Delegation Program Amendment\n\nI voted for\n → I find it understandable and appropriate to integrate lessons that have emerged along the way, and I agree that meeting the ‘Standard Rollup Charter criteria’ is something we should promote, especially if we seek interoperability.\n\nAs always, I welcome any comments or reactions you may have, which may help me to better understand the situation.\nUntil next time.\n\n 22 days later\n\n post by alexsotodigital on Jan 31, 2025\n\n alexsotodigital\n\n govNERD\n\n Voting Cycle Roundup #32\nProtocol Upgrade: Superchain Registry 2.0\n\nI voted for this proposal\n → It seems to me that this is just to formalize something that already happens in reality; so we are only looking for the official seal.\n\n 1 month later\n\n post by alexsotodigital on Mar 14, 2025\n\n alexsotodigital\n\n govNERD\n\n Voting Cycle #34\nUpgrade Proposal #13: OPCM and Incident Response improvements\n\nI voted for this proposal\n→ This new upgrade process aims to unify contract versions across different op chains in the superchain, something that aligns with the essence of interoperability, our intent this season.\n\n 1 month later\n\n post by alexsotodigital on Apr 24, 2025\n\n alexsotodigital\n\n govNERD\n\n Voting Cycle #35\n\nUpgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\nI voted for this proposal\n→ I have no objection moving forward with this.\n\nUpgrade Proposal #15: Isthmus Hard Fork\n\nI voted for this proposal\n→ I have no objection moving forward with this.\n\nVoting Cycle #36\n\nSeason 8 and 9: Budget Board Member Ratification \n\nI voted for this proposal\n→ The Budget Board is central to decentralizing economic decisions—especially relevant as Optimism moves towards more automated and data-driven governance.\n\n 1 month later\n\n post by alexsotodigital on Jun 6, 2025\n\n alexsotodigital\n\n govNERD\n\n Voting Cycle Roundup #38 \nSeason 8 and 9 Milestone and Metrics Council Selection\n → I voted for this proposal, because I think it’s worth experimenting with non-political methods of selecting members for these roles.\nWhile I agree with the comments about how the initial set of criteria is too limited (and prevents talent turnover), I also believe that ensuring the continuity of highly experienced people in roles (once the learning curve has been overcome) is also valuable and should not be underestimated.\n\n 20 days later\n\n post by alexsotodigital on Jun 27, 2025\n\n alexsotodigital\n\n govNERD\n\n Special Voting Cycle Roundup#39a\nSeason 8 Developer Advisory Board Charter amendment\nI’m voting for this proposal\n → because I see these changes as an attempt to adapt the written agreement to the real needs of the moment and the emerging responsibilities of the DAB. I see no reason not to move forward.\nSeason 8 Grants Council Charter amendment \nI’m voting for this proposal\n → because I believe the changes are appropriate and reflect the lessons learned from last season. I welcome the simplification of the number of members and the division of responsibilities.\nSeason 8 Milestones and Metrics Council Charter\nI’m voting for this proposal\n → to maintain continuity in leadership and alignment with the rest of the representative structures. I see how things worked well last season, and I see no reason to change that.\nBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9 \nI’m voting for this proposal\n → I’m voting in favor. I’m glad the proposal has incorporated community feedback, and I think it’s good enough to move forward.\nSeason 8 Intent \nI’m voting for this proposal\n→ Because I agree that it is important to be consistent with the Season 7 Intent and remain focused on delivering protocol-native interop.\nGovernor Update Proposal: Removing Abstain Count from Quorum \nI’m voting for this proposal\n→ I understand that this change will help preserve the integrity of proposal outcomes and align voting behavior with intent. I see no reason not to do so.\n\n 8 days later\n\n post by alexsotodigital on Jul 5, 2025\n\n alexsotodigital\n\n govNERD\n\n Special Voting Cycle Roundup#39b \nUpgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in Cannon \nI’m voting for this proposal\n→ because I see this as one more step towards achieving our S8-9 intent, and I see no reason not to take it. I also appreciate the team’s willingness to clarify questions and bring non-technical members into the conversation.\n\n 23 days later\n\n post by alexsotodigital on Jul 29, 2025\n\n alexsotodigital\n\n govNERD\n\n Special Voting Cycle Roundup#39c \nGM!\nSeason 8/9 Operating Budgets\nI voted for\n → All of these councils are essential to the collective. Even with the limitation this may have (since it exceeds the cap), I prefer to highlight everyone’s work equally.\nAnticapture Commission Dissolution Proposal\nI voted for\n → IMO, there is currently confusion about the usefulness of such a structure, and I believe halting its work may enable a better co-design space to identify the gap it leaves.\nElections:\n → I’m choosing based on the level of participation I perceive from the forum and meeting activity. I’d like to reward involvement, willingness to focus, and continuity of processes.\nGrants Council Election: Final Reviewer\n\nGFX Labs\nMasterMojo\nmattgov.eth\nMichael\n\nGrants Council Election: Operations\n\nBunnic\n\nMilestones & Metrics Council Election: Reviewers\n\nSEEDGov\nBrichis\nSuperchainEco.eth\n\nDeveloper Advisory Board Election: Members\n\nblockdev\ndevtooligan\nm4rio\n𓀣 Odysseas.eth 𓀢\n\nS8 Governance Fund Missions:\n\nGrants Council\nDeveloper Advisory Board\n\noptimistically approved\n → I have no objection with this proposals\n\nAs always, I welcome any comments or reactions you may have, which may help me to better understand the situation.\nUntil next time.\n\n 18 days later\n\n post by alexsotodigital on Aug 16, 2025\n\n alexsotodigital\n\n govNERD\n\n Voting Cycle Roundup #40\nSecurity Council Season 7 Retroactive Funding Request\nI voted against this proposal\n→ While I recognize that the OPSC’s work is mission-critical, and I understand that they may have had a heavier workload during Season 7, I believe their initial compensation was already well valued compared to other roles in the collective.\nFull disclosure: I participated as a core govNERD (during Season 7). For comparison, the total reward was 3,214 OP (almost 1/8 of the 24,780 OPs that each OPSC recipient would receive - and likely will receive - with this proposal). While I understand that govNERDs are in Impact 6 and OPSC are in Impact 8 (of the Collective Reward Framework), it is an example of how some roles were underfunded.\n\n 2 months later\n\n post by alexsotodigital on Oct 16, 2025\n\n alexsotodigital\n\n govNERD\n\n Voting Cycle #43\nSecurity Council Elections Cohort A Members\nI voted for:\n\nAgora\nUniswap Foundation\nVelodrome\nAlchemy Insights, Inc.\nGauntlet\nEmiliano\nMariano\n→ I sought to prioritize actors with the longest track record of contributions (and incentives aligned with the Superchain), balancing teams and individuals, and approvals granted by the top 100 delegates.\n\nSecurity Council Elections: Cohort A Lead\nI voted for:\n\nAlisha\n→ Who I believe is a rockstar with what it takes to continue leading the council.\nI also think having this continuity will be good for maintaining accumulated knowledge.\n\n 1 month later\n\n post by stephanschwab on Nov 20, 2025\n\n stephanschwab\n\n Good choice, Alex! Good luck in all your endeavors! May your path be fruitful and promising! . Your work is interesting to watch, GOOD LUCK\n\n 8 months later\n\n post by alexsotodigital on Jul 9\n\n alexsotodigital\n\n govNERD\n\n GM\nI’ve voted For these proposals.\n\nSecurity Council Operating Budget\nSequencer ETH Management: 12-Month Renewal and Treasury Optimization\nDeveloper Advisory Board Dissolution Proposal\nOperating Manual Update Proposal\nGrants Council Dissolution Proposal\n Milestones and Metrics Council Dissolution Proposal\n\nFeedback\nI agree with simplifying governance where the overhead outweighs the benefits. The rationale presented by the @system Foundation is thoughtful, and I believe this evolution reflects important lessons from the past few years.\nMy main concern is not the dissolution of these structures, but the absence of a clear path for the people who built them. If the organization is evolving, how does the talent, context, and trust accumulated through years of community participation evolve with it, rather than being left behind?\nMore broadly, if governance’s role becomes holding the Foundation accountable while the Foundation executes, how can delegates and the broader community continue to provide meaningful oversight? Accountability works best when there are enough opportunities to understand the reasoning behind important decisions, not only their outcomes.\nI wonder whether there are lightweight practices from the DAO that could still strengthen this new model without slowing execution.\nThings like:\n\noccasional design workshops with delegates and builders,\npostmortems on significant decisions,\nopen strategy sessions on selected topics.\n\nAll that could preserve valuable community context while keeping the organization lean.\nOverall, I support the direction. My hope is simply that, as we move from experimentation to organization, we also find ways to carry forward the strengths of both worlds. A “new type of organization - not a DAO and not a corporation - but something new”, right?\n\n Guide to Season 9\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Brichis - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate statement \nFirstly, allow me to introduce myself. My name is Bricia, although you’re welcome to call me Brichis and I am Co-Founder of Ethereum Mexico. \nMy decision to become a delegate was sparked by discussio…\n\n read more\n\n 48\n\n 3.9k\n\n Aug 21\n\n PGov - Delegate Communication Thread\n\n Delegate Updates\n\n Delegate Name: @PGov \nDelegate Address: PGov.eth (0x3fb19771947072629c8eee7995a2ef23b72d4c8a) \nForum Handle: @PGov, @Juanbug_PGov \nEmail: PGovTeam@gmail.com \nCore Principles: \n\nTransparency: Clear communication with vote…\n\n read more\n\n 45\n\n 3.6k\n\n Sep 2\n\n SEEDGov - Delegate Communication Thread\n\n Delegate Updates\n\n UPDATE Q2 2023: we changed our name to SEED Latam. With this renewed image and enlargement of the scope, we are committed to support communities and leaders in Latam. \n\nRead our vision here – Plataformas de delegados. ¿P…\n\n read more\n\n 64\n\n 13.0k\n\n Jan 27\n\n L2BEAT - Delegate Communication Thread\n\n Delegate Updates\n\n Hey! \nIn the previous voting seasons, we were one of the most prominent governance delegators, engaging in various discussions and leading Tooling Governance Committee. \nToday I would like to announce that we are shiftin…\n\n read more\n\n 20\n\n 4.0k\n\n Nov 2025\n\n StableLab - Delegate Communication Thread\n\n Delegate Updates\n\n Name: StableLab \nDelegate Address: stablenodegov.eth \nGovernance tracking: Boardroom, Internal tracker \nForum: Bobbay_StableLab \nDiscord: Bobbay#4885 \nTwitter: https://twitter.com/Stablelab \nWebsite: https://www.stablela…\n\n read more\n\n 28\n\n 5.3k\n\n Mar 2025","tokens":4629,"squid":"ink-governance","role":"Council Listener","at":1791260402221,"hash":"03668f206cad51f5467ac8962e87f82602edafba"}
{"url":"https://eips.ethereum.org/EIPS/eip-155","domain":"eips.ethereum.org","title":"EIP-155: Simple replay attack protection","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-155: Simple replay attack protection\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2016-10-14\n\n Hard fork\n\nSpurious Dragon\n\n Parameters\n\n FORK_BLKNUM: 2,675,000\n CHAIN_ID: 1 (main net)\n\n Specification\n\nIf block.number >= FORK_BLKNUM and CHAIN_ID is available, then when computing the hash of a transaction for the purposes of signing, instead of hashing only six rlp encoded elements (nonce, gasprice, startgas, to, value, data), you SHOULD hash nine rlp encoded elements (nonce, gasprice, startgas, to, value, data, chainid, 0, 0). If you do, then the v of the signature MUST be set to {0,1} + CHAIN_ID * 2 + 35 where {0,1} is the parity of the y value of the curve point for which r is the x-value in the secp256k1 signing process. If you choose to only hash 6 values, then v continues to be set to {0,1} + 27 as previously.\n\nIf block.number >= FORK_BLKNUM and v = CHAIN_ID * 2 + 35 or v = CHAIN_ID * 2 + 36, then when computing the hash of a transaction for purposes of recovering, instead of hashing six rlp encoded elements (nonce, gasprice, startgas, to, value, data), hash nine rlp encoded elements (nonce, gasprice, startgas, to, value, data, chainid, 0, 0). The currently existing signature scheme using v = 27 and v = 28 remains valid and continues to operate under the same rules as it did previously.\n\n Example\n\nConsider a transaction with nonce = 9, gasprice = 20 * 10**9, startgas = 21000, to = 0x3535353535353535353535353535353535353535, value = 10**18, data='' (empty).\n\nThe “signing data” becomes:\n\n0xec098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a764000080018080\n\nThe “signing hash” becomes:\n\n0xdaf5a779ae972f972197303d7b574746c7ef83eadac0f2791ad23db92e4c8e53\n\nIf the transaction is signed with the private key 0x4646464646464646464646464646464646464646464646464646464646464646, then the v,r,s values become:\n\n(37, 18515461264373351373200002665853028612451056578545711640558177340181847433846, 46948507304638947509940763649030358759909902576025900602547168820602576006531)\n\nNotice the use of 37 instead of 27. The signed tx would become:\n\n0xf86c098504a817c800825208943535353535353535353535353535353535353535880de0b6b3a76400008025a028ef61340bd939bc2195fe537567866003e1a15d3c71ff63e1590620aa636276a067cbe9d8997f761aecb703304b3800ccf555c9f3dc64214b297fb1966a3b6d83\n\n Rationale\n\nThis would provide a way to send transactions that work on Ethereum without working on ETC or the Morden testnet. ETC is encouraged to adopt this EIP but replacing CHAIN_ID with a different value, and all future testnets, consortium chains and alt-etherea are encouraged to adopt this EIP replacing CHAIN_ID with a unique value.\n\n List of Chain ID’s:\n\n CHAIN_ID\n Chain(s)\n\n 1\n Ethereum mainnet\n\n 2\n Morden (disused), Expanse mainnet\n\n 3\n Ropsten\n\n 4\n Rinkeby\n\n 5\n Goerli\n\n 42\n Kovan\n\n 1337\n Geth private chains (default)\n\nFind more chain ID’s on chainid.network and contribute to ethereum-lists/chains.\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-155: Simple replay attack protection,\" Ethereum Improvement Proposals, no. 155, October 2016. Available: https://eips.ethereum.org/EIPS/eip-155.","tokens":797,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260423795,"hash":"67d57f3592f487008a321c861c6e24b5b487c9f7"}
{"url":"https://governance.aave.com/t/arfc-arfc-and-temp-check-framework/13828/20","domain":"governance.aave.com","title":"[ARFC] ARFC and TEMP CHECK Framework - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n Jun 2023\n\n 20 / 20\n\n Nov 2023\n\n Dec 2023\n\n post by MarcZeller on Jun 27, 2023\n\n MarcZeller\n\nTitle: [ARFC] Framework for ARFC and TEMP CHECK Proposals\nAuthor: @MarcZeller - Aave Chan Initiative\nDate: 2023-06-27\nSummary\nThis framework provides comprehensive guidelines for the Aave DAO community when creating and voting on ARFC (Aave Request for Comment) and TEMP CHECK proposals. It includes a template for crafting proposals and outlines the quorum and voting requirements.\nMotivation\nDistinction Between TEMP CHECK and ARFC\nTEMP CHECKs serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.\nConversely, ARFCs are precursors to Aave Improvement Proposals (AIPs). Relevant service providers are formally invited to provide feedback on them, and the specification section of ARFCs should detail how the potential upcoming AIP will impact Aave protocol smart contracts.\nProposal Template\nEach proposal must include the following sections:\nA header:\n\nTitle: A concise and descriptive title for the proposal, including the proposal type (ARFC or TEMP CHECK) in a [TAG] format.\nAuthor: The name of the author and/or entity creating the proposal.\nDate: The date the proposal is being made, in the YYYY-MM-DD format.\n\nA proposal body:\n\nSummary: A succinct summary of the proposal.\nMotivation: A detailed presentation of the proposal and potential benefits for the Aave protocol. This section can have sub-sections for improved readability.\nSpecification: A comprehensive description of the proposed change, including any relevant parameters or risk considerations. For ARFCs, this section should be technical, detailing the specific changes to be made. This section can have sub-sections for improved readability.\nDisclaimer: Any necessary disclaimers, such as conflicts of interest or third-party involvement.\nNext Steps: The proposed next steps if the proposal is approved.\nCopyright: A statement defining proposal copyright. While Open-Source is mandatory, the choice of a specific license is left to the author.\n\nVoting Guidelines\n\nVote Start Time: The vote should commence 24 hours after the proposal is published on Snapshot.\nProposal Age: The governance thread related to the snapshot vote should be at least 5 days old before voting begins.\nVote Duration: The vote should last for a minimum of 3 days.\nVote Options: The vote should have at least three options: YAE (Yes), NAY (No), and ABSTAIN.\nQuorum: The vote should reach a quorum of 320,000 YAE votes.\nDifferential: The YAE votes should exceed the second-largest vote option (either NAY or ABSTAIN) by at least 80,000.\n\nProposal Cycle:\nimage1920×920 54.1 KB\nSpecial Considerations\nThis framework should be considered as a general template for general proposals. Specific proposals and/or frameworks, such as asset onboarding or caps updates, should follow specific guidelines as determined by the Aave DAO community.\nThis framework is designed to ensure that all proposals are thoroughly considered and that all votes are fair and representative of the Aave DAO community’s views.\nSpecification\nAs this proposal pertains to governance guidelines, it does not require any on-chain action or protocol change.\nDisclaimer\nThe ACI is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC.\nNext Steps\n\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Gauntlet recommendation on TUSD for Aave v2 Ethereum\n\n [TEMP CHECK] Updated Aave Grants Continuation Proposal\n\n [TEMP CHECK] Increase wstETH supply cap on Polygon v3\n\n [ARFC] Direct-to-AIP Framework\n\n [TEMP CHECK] Re-building Aave’s official documentation\n\n 6\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by fig on Jun 27, 2023\n\n fig\n\n Smart – this has been needed for a while.\nWe are glad you see the same concerns and issues facing new, less familiar participants.\nSomething that may be worth including in this is the timing of each cycle; i.e. how long should a TEMP CHECK discussion be live before heading to a vote? As an ARFC?\nThe voting duration is clearly defined but it would be helpful to help guide discussions on the forum and how long they last (and when to progress) so the community may provide ample input.\nThis set of guidelines may prevent rushed, nefarious proposals – and create a clearer set of expectations around the total length of the Governance cycle.\n\nWe disagree with this line in the Snapshot stage:\n\nQuorum should not be related to the direction of a vote – nor in the AIP stage.\nWhat happens if a vote reaches 320,000 NAY votes? Is it not valid?\nAdditionally, it eliminates real possibilites of mixed votes and ABSTAINs.\n\n post by MarcZeller on Jun 27, 2023\n\n MarcZeller\n\n Hello @fig, thank you for your input.\n\nAs mentioned in the original post:\n\nBoth general-purpose ARFCs and TEMP CHECKs share several similarities, including the timeline for proposals. In this case, a minimum of 5 days is required between the topic publication and escalation to a snapshot vote.\nWe believe that setting a maximum or other “subjective” requirements is not necessary in this context. Proposals that fail to reach consensus have a low chance of passing the snapshot stages. When designing guidelines, it’s crucial to strike a balance between mandatory parts and parts left to “usage” to allow some degree of flexibility in well-designed frameworks.\n\nA vote that reaches 320,000 NAY votes is indeed valid and effectively rejects the proposal. All three stages of the proposal life process are designed to act as filters. The TEMP CHECK snapshot determines whether a proposal is worth the time and resources for service provider feedback and engineering to detail the proposal. The ARFC snapshot decides whether to dedicate actual resources to convert the human language of a proposal into AIP payload code. Finally, AIPs decide whether the payload is executed and actively modifies the Aave protocol.\nNAY and ABSTAIN votes are not subject to differential requirements, as no specific action is required with an ABSTAIN or NAY outcome. Payloads are simply not executed, or proposals are not escalated.\nBy design, a YAE outcome is supposed to be harder to achieve than a NAY or ABSTAIN outcome. Aave is a decentralized protocol, and AIPs modify the protocol itself, which manages billions of dollars. Therefore, checks and filters are necessary to ensure the protocol’s security and integrity.\n\nEDIT adding some examples for clarity:\n\nProposal 1\nVotes\n\nYAE\n310k\n\nNAY\n20k\n\nABSTAIN\n80k\n\nOutcome\nFailed (quorum failure)\n\nProposal 2\nVotes\n\nYAE\n325k\n\nNAY\n150k\n\nABSTAIN\n80k\n\nOutcome\nYAE\n\nProposal 3\nVotes\n\nYAE\n400k\n\nNAY\n350k\n\nABSTAIN\n0\n\nOutcome\nFailed (differential)\n\nProposal 4\nVotes\n\nYAE\n120k\n\nNAY\n240k\n\nABSTAIN\n0\n\nOutcome\nFailed (No quorum needed to fail a proposal if NAY/Abstain wins)\n\n post by TokenLogic on Jun 27, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Hi @MarcZeller,\nThis proposal is definitely needed.\n\nIf the goal is to be comprehensive, we suggest the following types of votes be included:\n\nLevel 2 Governance votes from the perspective of quorum requirements\nRisk Stewards specific to Supply/Borrow and GHO Mint Caps\nAsset listings when the asset is already active on another Aave deployment\n\nA loose idea is to have a rule of thumb whereby the vote cycle starts early in the week for all the non urgent votes. ie: minimise weekend voting where possible.\nIn the past, some teams have gone direct to AIP with minimal input from the community. This is normally the result of an abundance of caution from a risk perspective, which in recent votes has at times been voted down or quickly overturned by a later AIP submission.\nIf the objective is to be comprehensive, then all governance flows should be detailed in a single place. Or as a minimum cross referenced. Supply/Borrow caps amendments need to go through this process when both Chaos Labs and Gauntlet don’t support the proposed risk parameter changes. Having visibility of that governance flow here adds visibility to anyone using this post as the source of truth.\nRegarding the content of specifications, there seems to be a distinct difference between [TEMP CHECKS] and [ARFC]. [TEMP CHECK] appears to be more narrative and [ARFC] more technical. Directionally, we agree. However, more granularity on the distinctions is warranted as the text in the proposal is open for a wide array of interpretation.\nThis publication is a great start and in our honest opinion, it can be expanded to become more of a holistic source of truth for Aave governance. We are happy to help wherever possible to make this a more holistic framework.\n\n post by WintermuteGovernance on Jun 27, 2023\n\n WintermuteGovernance\n\n Hey @MarcZeller,\nThanks for putting this together and we support the proposed framework, template, and voting requirements.\nI think it would help the community if the new framework + template is easily accessible via a pinned post in the forum. Would it also be possible to have: Aave Protocol Overview updated to reflect these changes?\n\nI assume that if this proposal is approved, every off-chain vote will follow this template and voting guideline including Temp Checks + AFRC for level 2 governance (long executor). It won’t be until the AIP stage that voting guidelines are changed for level 2 governance votes. However, providing examples of what’s valid under these frameworks could certainly dispel some confusion.\n\n post by MarcZeller on Jun 28, 2023\n\n MarcZeller\n\n Hello and thx for your replies,\n@WintermuteGovernance answered to @TokenLogic on Long Executor proposals, no change until the AIP stage.\n\nthis documentation is controlled by the @AaveLabs so up to them to stay up to date.\n\nwe worked with stable labs to do this : Aave Finance Governance Process v0 it’s not perfect, but it’s a start, it will be updated to reflect governance decisions.\n\n post by TokenLogic on Jun 28, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Thank you for the feedback @WintermuteGovernance and @MarcZeller.\nTo confirm, adding assets already listed on one Aave deployment to another shall require a [TEMP CHECK] and [ARFC] Snapshot vote as per this proposal ?\nFor risk parameter changes deemed necessary, these can go direct to AIP without any Snapshot vote and fall outside of this framework ?\nCan we add this process flow into this framework.\nRegarding Supply/Borrow Caps, if we need to route via Snapshot. Does it make sense to vote twice given the both proposals [TEMP CHECK] and [ARFC] given the same known risk parameters are stated in the both Snapshot votes. There is an opportunity to remove some duplication by having a single Snapshot vote on Supply / Borrow Caps.\n\n post by fumoffuXx on Jun 28, 2023\n\n fumoffuXx\n\n So we are now amending governance procedures and definition without community acceptance through a poll?\nTalk about centralised mindset and lack of integrity\n\n post by EzR3aL on Jun 28, 2023\n\n EzR3aL\n\n Regular\n\n Hi,\ni don’t get what the problem here is?\nIf anybody involved in the DAO is against this, this person can come here and say so.\nIts just about a framwork for the different steps, which helps to organize stuff in here.\nThe snapshots and votings in the end will be voted decentralized.\n\n post by fumoffuXx on Jun 28, 2023\n\n fumoffuXx\n\n I am saying he can come up with hes own interpretation of the governance and expect everyone to follow it without question?\nNo one ever questions the intent of that form of interpretation?\nThere is something effy between aci and the entire TUSD fiasco.\n\n post by MarcZeller on Jun 28, 2023\n\n MarcZeller\n\nYou’re aware this goes to snapshot and needs to be approved by governance?\n\n post by fumoffuXx on Jun 28, 2023\n\n fumoffuXx\n\n Yes, just making sure procedures are followed and not bypassed. Moral Hazard is a disease in DEFI.\n\n post by 0xkeyrock.eth on Jun 29, 2023\n\n 0xkeyrock.eth\n\n Thanks for this framework @MarcZeller. It was definitely needed and creates much clearer guidelines for everyone while enabling easier access for anyone to place proposals and with the help of Skyward potentially escalate further in governance once there is community feedback.\nIn a scenario where this is a successful ARFC, we would strongly recommend as well that this gets pinned by @AaveLabs.\n\n post by Michigan_Blockchain on Jul 2, 2023\n\n Michigan_Blockchain\n\n Thank you for this much needed framework! This adds clarity for delegates and third parties who are new to making proposals. Michigan supports this proposal.\nIn the future, could we also have some guidelines on, at the ARFC stage, which service providers’ input are needed for each type of proposals? For example, for proposals regarding onboarding new oracles, who are the relevant service providers in addition to BGD?\n\n post by lbsblockchain on Jul 5, 2023\n\n lbsblockchain\n\n Thank you for this framework @MarcZeller and ACI, definitely needed! We agree with @Michigan_Blockchain around the need to provide guidelines on service provider input - it’ll make it easier for proposers to contact the relevant teams.\nWith regard to @TokenLogic’s comments on the Supply/Borrow Caps, if changes are to be made to those we agree that we should only have a single Snapshot vote. However, new listings on a new Aave deployment, regardless of whether it is present on another deployment, should require a TEMP CHECK as well since conditions across chains (e.g., liquidity) can materially differ.\nFurther additions to this framework could include more details around AIPs and specifically where proposals could directly go to the AIP stage and where it may not be appropriate to do so. However, we recognise that this proposal is to more keenly define the TEMP CHECK and ARFC stages of governance, and more details on the AIP stage can be added later.\n\n LBS Blockchain Society Delegate Platform\n\n post by MarcZeller on Jul 6, 2023\n\n MarcZeller\n\nThis is good feedback, will publish a framework on this shortly\n\nWe agree, these cases should be covered, voted and integrated in existing guidelines\n\nThis framework is the “general purpose” one, designed to act as the basic template for proposals, exceptions to these frameworks for specific cases will be voted on separately such as current “cap update framework” that is currently discussed to be updated as a “direct-to-Aip” framework allowing governance to bypass current framework for specific actions.\n\n post by MarcZeller on Jul 6, 2023\n\n MarcZeller\n\n Snapshot outcome is YAE and this framework is now officially integrated in Aave DAO governance Guidelines.\n\n 1 month later\n\n Closed on Aug 5, 2023\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n 27 days later\n\n Pinned on Sep 1, 2023\n\n 3 months later\n\n post by ACI on Dec 1, 2023\n\n ACI\n\n Leader\n\n Hello frens,\nAs you may have seen recently, there’s been some upgrades to update the Asset Onboarding Framework. Please find attached latest ARFC with a more detailed explanation on the changes to establish a streamlined governance process for adding new markets and streamline the listing of assets with existing Aave markets on new chains.\nThe listing framework aims to balance security and speed by providing a more efficient governance process for asset onboarding. We have established the precedent with past proposals that have improved timeliness and governance overhead. This will define a clearer and accessible standard in the same spirit as the DAO’s historic process.\nUpdated Asset Onboarding Framework\n\n [TEMP CHECK] Enable Metis as Collateral on Metis Chain\n\n Proposal to add WSOL as collateral\n\n AMPL problem on Aave v2 Ethereum\n\n Proposal Clarification\n\n [TEMP CHECK] Port of Aave to Solana using Formal Verification\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC ADDENDUM] Updated Framework for ARFC and TEMP CHECK Proposals\n\n General\n\n 6\n\n 533\n\n Aug 2024\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 697\n\n Aug 9\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 143\n\n Aug 10\n\n ARC: Aave Governance Process Improvements\n\n Governance\n\n 7\n\n 3.4k\n\n Mar 2023\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d","tokens":4148,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260424310,"hash":"794f3b7035d3316b176df98ae367f6857c7ac467"}
{"url":"https://vote.optimism.io/delegates/alexsotodigital.eth","domain":"vote.optimism.io","title":"alexsotodigital.eth on Agora","text":"Voted against this proposal about 2 months ago with 9.61 votesRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundReason: I'd like to see that pool of tokens deployed for users, even if that means distributing rewards through OP Enterprise clients or allocating them to initiatives that spark retail interest. Voted for this proposal 3 months ago with 9.61 votesMilestones and Metrics Council Dissolution ProposalReason: https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332/17?u=alexsotodigitalVoted for this proposal 3 months ago with 9.61 votesGrants Council Dissolution ProposalReason: https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332/17?u=alexsotodigitalVoted for this proposal 3 months ago with 9.61 votesOperating Manual Update ProposalReason: https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332/17?u=alexsotodigitalVoted for this proposal 3 months ago with 9.61 votesDeveloper Advisory Board Dissolution ProposalReason: https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332/17?u=alexsotodigitalVoted for this proposal 3 months ago with 9.61 votesSequencer ETH Management: 12-Month Renewal and Treasury OptimizationReason: https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332/17?u=alexsotodigitalVoted for this proposal 3 months ago with 9.61 votesSecurity Council Operating BudgetReason: https://gov.optimism.io/t/alexsotodigital-eth-delegate-communication-thread/9332/17?u=alexsotodigitalVoted on 1 options in this proposal 4 months ago with 9.59K votes[Second vote] Security Council Elections Cohort B MembersAlex SotoVoted on 6 options in this proposal 4 months ago with 41.7 votesSecurity Council Elections Cohort B MembersVoted: Alex Soto, Matthew Slipper, donnoh, Master Mojo, Test in Prod, dcbuilder.ethReason: My vote prioritized technical competence, prior contributions to Optimism, and institutional diversity. I also voted for myself. While I bring more experience in governance operations, multisig processes, and protocol stewardship than in protocol engineering, I believe that perspective is valuable on a Council tasked with faithfully executing governance outcomes and maintaining operational discipline.\n\nI chose not to support OP Labs or INK Foundation, not because of any concern regarding their qualifications or alignment. Both are highly capable and important contributors to the Superchain. Rather, I believe distributing trust across a broader set of independent actors strengthens the resilience of the Collective and helps further the long-term goal of decentralization.Voted on 1 options in this proposal 12 months ago with 3.23K votesSecurity Council Elections: Cohort A LeadalishaReason: → Who I believe is a rockstar with what it takes to continue leading the council. I also think having this continuity will be good for maintaining accumulated knowledge.Voted on 7 options in this proposal 12 months ago with 3.23K votesSecurity Council Elections Cohort A MembersVoted: Agora, Alchemy Insights, Inc., Emiliano, Gauntlet, Mariano, Uniswap Foundation, VelodromeReason: I sought to prioritize actors with the longest track record of contributions (and incentives aligned with the Superchain), balancing teams and individuals, and approvals granted by the top 100 delegates.Voted against this proposal about 1 year ago with 5.84K votesSecurity Council Season 7 Retroactive Funding RequestReason: While I recognize that the work of the OPSC is mission-critical, I believe that there were other roles in the collective that also had an increased workload during Season 7 and are not being compensated equally.Voted on 4 options in this proposal about 1 year ago with 5.63K votesDeveloper Advisory Board Election: MembersVoted: blockdev, devtooligan, m4rio, 𓀣 Odysseas.eth 𓀢Reason: top developers on Github for proximity to the OP StackVoted on 3 options in this proposal about 1 year ago with 5.63K votesMilestones & Metrics Council Election: ReviewersVoted: Brichis, SEEDGov, SuperchainEco.ethReason: Anyway, this will be a dream team! Voted on 1 options in this proposal about 1 year ago with 5.63K votesGrants Council Election: OperationsBunnicReason: I believe he is the right person! Voted on 4 options in this proposal about 1 year ago with 5.63K votesGrants Council Election: Final ReviewerVoted: GFX Labs, MasterMojo, mattgov.eth, MichaelReason: I'm choosing based on the level of participation I perceive from the forum and meeting activity. I'd like to reward involvement, willingness to focus, and continuity of processes.Voted for this proposal about 1 year ago with 5.63K votesAnticapture Commission Dissolution ProposalReason: There is currently confusion about the usefulness of such a structure, and I believe halting its work may enable a better co-design space to identify the gap it leaves.Voted on 4 options in this proposal about 1 year ago with 5.63K votesSeason 8/9 Operating BudgetsVoted: Developer Advisory Board Operating Budget, Grants Council Operating Budget, Milestones & Metrics Council Operating Budget, Security Council Operating BudgetReason: All of these councils are essential to the collective. Even with the limitation this may have (since it exceeds the cap), I prefer to highlight everyone's work equally.Voted for this proposal over 1 year ago with 5.62K votesUpgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in CannonReason: I see this as one more step towards achieving our S8-9 intent, and I see no reason not to take it.Voted for this proposal over 1 year ago with 5.62K votesBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9Reason: I’m glad the proposal has incorporated community feedback, and I think it’s good enough to move forward.Voted for this proposal over 1 year ago with 5.62K votesGovernor Update Proposal: Removing Abstain Count from QuorumReason: I understand that this change will help preserve the integrity of proposal outcomes and align voting behavior with intent. I see no reason not to do so.Voted for this proposal over 1 year ago with 5.62K votesSeason 8: Intent RatificationReason: I agree that it is important to be consistent with the Season 7 Intent and remain focused on delivering protocol-native interop.Voted for this proposal over 1 year ago with 5.62K votesBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9Reason: glad the proposal has incorporated community feedback, and I think it’s good enough to move forward.Voted for this proposal over 1 year ago with 5.62K votesSeason 8/9 Milestones and Metrics Council CharterReason: to maintain continuity in leadership and alignment with the rest of the representative structures. I see how things worked well last season, and I see no reason to change that.Voted for this proposal over 1 year ago with 5.62K votesSeason 8/9 Grants Council CharterReason: I believe the changes are appropriate and reflect the lessons learned from last season. I welcome the simplification of the number of members and the division of responsibilities.Voted for this proposal over 1 year ago with 5.62K votesSeason 8/9 Developer Advisory Board CharterReason: I see these changes as an attempt to adapt the written agreement to the real needs of the moment and the emerging responsibilities of the DAB. I see no reason not to move forward.Voted for this proposal over 1 year ago with 5.62K votesSeason 8 and 9 Milestone and Metrics Council SelectionReason: I think it's worth trying to test how to select roles based on competencies rather than choices. I hope eligibility criteria will be co-created in the future.Voted for this proposal over 1 year ago with 6.17K votesSeason 8 and 9: Budget Board Member RatificationReason: The Budget Board is central to decentralizing economic decisions—especially relevant as Optimism moves towards more automated and data-driven governance.Voted for this proposal over 1 year ago with 2.95K votesUpgrade Proposal #15: Isthmus Hard ForkReason: I have no objections to moving forward.Voted for this proposal over 1 year ago with 2.95K votesUpgrade Proposal #14: Isthmus L1 Contracts + MT-CannonReason: I like that 'this change opens up the design space of chains in a big way.' :) Voted for this proposal over 1 year ago with 2.95K votesUpgrade Proposal #13: OPCM and Incident Response improvementsReason: This new upgrade process aims to unify contract versions across different op chains in the superchain, something that aligns with the essence of interoperability, our intent this season.Voted for this proposal over 1 year ago with 2.95K votesProtocol Upgrade: Superchain Registry 2.0Reason: It seems to me that this is just to formalize something that already happens in reality; so we are only looking for the “governance-approved” seal. Voted on 2 options in this proposal over 1 year ago with 4.46K votesDeveloper Advisory Board Audit Request Team ElectionsVoted: m4rio.eth, noah.ethReason: I chose those who I considered had the best learning context from past seasons.Abstained from voting on this proposal over 1 year ago with 4.46K votesSecurity Council Elections Cohort B MembersAbstainReason: I don't think I have enough context to make this decision. I would point out that I find it confusing to compare people to organizations (especially those chains belonging to the superchain). How do we know who is really involved?Voted on 2 options in this proposal over 1 year ago with 4.46K votesDeveloper Advisory Board Foundation Mission Team ElectionsVoted: Ed, DanyalReason: I choose those who seems to have the most context and knowledge of how the OP foundation works.Voted on 3 options in this proposal over 1 year ago with 4.46K votesDeveloper Advisory Board Governance Mission Team ElectionsVoted: Will, Jepsen, blockdevReason: I chose those I identified as having greater proximity to the OP Stack and who can integrate learnings from past seasons.Voted on 3 options in this proposal over 1 year ago with 4.46K votesMilestones and Metrics Council Reviewer ElectionsVoted: LauNaMu, mmurthy, AngelaReason: I have selected individuals over teams, hoping that this will translate into greater focus and availability of time on day-to-day work.Voted on 4 options in this proposal over 1 year ago with 4.46K votesGrants Council Final Reviewer ElectionsVoted: GFX Lab, Michael, jackanorak, JashFiReason: I am prioritizing the profiles that, in my perception, have greater availability and focus for the OP collective, beyond having a great track record in web3.Voted on 3 options in this proposal over 1 year ago with 4.46K votesGrants Council GrantNerd ElectionsVoted: Brichis, Jrocki, SovReason: I am prioritizing people with a high level of context and with previous participation in other councils, hoping that they will have a broader perspective in that decision-making.Voted for this proposal over 1 year ago with 4.46K votesSeason 7: Chain Delegation Program AmendmentReason: I find it understandable and appropriate to integrate lessons that have emerged along the way, and I agree that meeting the 'Standard Rollup Charter criteria' is something we should promote, especially if we seek interoperability.Loading...","tokens":2816,"squid":"ink-governance","role":"Council Listener","at":1791260425056,"hash":"50535b14c923da234175d37ece03e8ad0004a49f"}
{"url":"https://governance.aave.com/t/arfc-arfc-and-temp-check-framework/13828","domain":"governance.aave.com","title":"[ARFC] ARFC and TEMP CHECK Framework - Governance - Aave","text":"[ARFC] ARFC and TEMP CHECK Framework \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n Title: [ARFC] Framework for ARFC and TEMP CHECK Proposals\nAuthor: @MarcZeller - Aave Chan Initiative\nDate: 2023-06-27\n\n Summary\n\n Motivation\n\n Distinction Between TEMP CHECK and ARFC\n\n Proposal Template\n\n Voting Guidelines\n\n Proposal Cycle:\n\n Special Considerations\n\n Specification\n\n Disclaimer\n\n Next Steps\n\n Copyright\n\n Jun 2023\n\n 1 / 20\n\n Jun 2023\n\n Dec 2023\n\n post by MarcZeller on Jun 27, 2023\n\n MarcZeller\n\nTitle: [ARFC] Framework for ARFC and TEMP CHECK Proposals\nAuthor: @MarcZeller - Aave Chan Initiative\nDate: 2023-06-27\nSummary\nThis framework provides comprehensive guidelines for the Aave DAO community when creating and voting on ARFC (Aave Request for Comment) and TEMP CHECK proposals. It includes a template for crafting proposals and outlines the quorum and voting requirements.\nMotivation\nDistinction Between TEMP CHECK and ARFC\nTEMP CHECKs serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.\nConversely, ARFCs are precursors to Aave Improvement Proposals (AIPs). Relevant service providers are formally invited to provide feedback on them, and the specification section of ARFCs should detail how the potential upcoming AIP will impact Aave protocol smart contracts.\nProposal Template\nEach proposal must include the following sections:\nA header:\n\nTitle: A concise and descriptive title for the proposal, including the proposal type (ARFC or TEMP CHECK) in a [TAG] format.\nAuthor: The name of the author and/or entity creating the proposal.\nDate: The date the proposal is being made, in the YYYY-MM-DD format.\n\nA proposal body:\n\nSummary: A succinct summary of the proposal.\nMotivation: A detailed presentation of the proposal and potential benefits for the Aave protocol. This section can have sub-sections for improved readability.\nSpecification: A comprehensive description of the proposed change, including any relevant parameters or risk considerations. For ARFCs, this section should be technical, detailing the specific changes to be made. This section can have sub-sections for improved readability.\nDisclaimer: Any necessary disclaimers, such as conflicts of interest or third-party involvement.\nNext Steps: The proposed next steps if the proposal is approved.\nCopyright: A statement defining proposal copyright. While Open-Source is mandatory, the choice of a specific license is left to the author.\n\nVoting Guidelines\n\nVote Start Time: The vote should commence 24 hours after the proposal is published on Snapshot.\nProposal Age: The governance thread related to the snapshot vote should be at least 5 days old before voting begins.\nVote Duration: The vote should last for a minimum of 3 days.\nVote Options: The vote should have at least three options: YAE (Yes), NAY (No), and ABSTAIN.\nQuorum: The vote should reach a quorum of 320,000 YAE votes.\nDifferential: The YAE votes should exceed the second-largest vote option (either NAY or ABSTAIN) by at least 80,000.\n\nProposal Cycle:\nimage1920×920 54.1 KB\nSpecial Considerations\nThis framework should be considered as a general template for general proposals. Specific proposals and/or frameworks, such as asset onboarding or caps updates, should follow specific guidelines as determined by the Aave DAO community.\nThis framework is designed to ensure that all proposals are thoroughly considered and that all votes are fair and representative of the Aave DAO community’s views.\nSpecification\nAs this proposal pertains to governance guidelines, it does not require any on-chain action or protocol change.\nDisclaimer\nThe ACI is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC.\nNext Steps\n\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Gauntlet recommendation on TUSD for Aave v2 Ethereum\n\n [TEMP CHECK] Updated Aave Grants Continuation Proposal\n\n [TEMP CHECK] Increase wstETH supply cap on Polygon v3\n\n [ARFC] Direct-to-AIP Framework\n\n [TEMP CHECK] Re-building Aave’s official documentation\n\n 6\n\n 3\n\n 2\n\n read \n\n 6\n min\n\n post by fig on Jun 27, 2023\n\n fig\n\n Smart – this has been needed for a while.\nWe are glad you see the same concerns and issues facing new, less familiar participants.\nSomething that may be worth including in this is the timing of each cycle; i.e. how long should a TEMP CHECK discussion be live before heading to a vote? As an ARFC?\nThe voting duration is clearly defined but it would be helpful to help guide discussions on the forum and how long they last (and when to progress) so the community may provide ample input.\nThis set of guidelines may prevent rushed, nefarious proposals – and create a clearer set of expectations around the total length of the Governance cycle.\n\nWe disagree with this line in the Snapshot stage:\n\nQuorum should not be related to the direction of a vote – nor in the AIP stage.\nWhat happens if a vote reaches 320,000 NAY votes? Is it not valid?\nAdditionally, it eliminates real possibilites of mixed votes and ABSTAINs.\n\n post by MarcZeller on Jun 27, 2023\n\n MarcZeller\n\n Hello @fig, thank you for your input.\n\nAs mentioned in the original post:\n\nBoth general-purpose ARFCs and TEMP CHECKs share several similarities, including the timeline for proposals. In this case, a minimum of 5 days is required between the topic publication and escalation to a snapshot vote.\nWe believe that setting a maximum or other “subjective” requirements is not necessary in this context. Proposals that fail to reach consensus have a low chance of passing the snapshot stages. When designing guidelines, it’s crucial to strike a balance between mandatory parts and parts left to “usage” to allow some degree of flexibility in well-designed frameworks.\n\nA vote that reaches 320,000 NAY votes is indeed valid and effectively rejects the proposal. All three stages of the proposal life process are designed to act as filters. The TEMP CHECK snapshot determines whether a proposal is worth the time and resources for service provider feedback and engineering to detail the proposal. The ARFC snapshot decides whether to dedicate actual resources to convert the human language of a proposal into AIP payload code. Finally, AIPs decide whether the payload is executed and actively modifies the Aave protocol.\nNAY and ABSTAIN votes are not subject to differential requirements, as no specific action is required with an ABSTAIN or NAY outcome. Payloads are simply not executed, or proposals are not escalated.\nBy design, a YAE outcome is supposed to be harder to achieve than a NAY or ABSTAIN outcome. Aave is a decentralized protocol, and AIPs modify the protocol itself, which manages billions of dollars. Therefore, checks and filters are necessary to ensure the protocol’s security and integrity.\n\nEDIT adding some examples for clarity:\n\nProposal 1\nVotes\n\nYAE\n310k\n\nNAY\n20k\n\nABSTAIN\n80k\n\nOutcome\nFailed (quorum failure)\n\nProposal 2\nVotes\n\nYAE\n325k\n\nNAY\n150k\n\nABSTAIN\n80k\n\nOutcome\nYAE\n\nProposal 3\nVotes\n\nYAE\n400k\n\nNAY\n350k\n\nABSTAIN\n0\n\nOutcome\nFailed (differential)\n\nProposal 4\nVotes\n\nYAE\n120k\n\nNAY\n240k\n\nABSTAIN\n0\n\nOutcome\nFailed (No quorum needed to fail a proposal if NAY/Abstain wins)\n\n post by TokenLogic on Jun 27, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Hi @MarcZeller,\nThis proposal is definitely needed.\n\nIf the goal is to be comprehensive, we suggest the following types of votes be included:\n\nLevel 2 Governance votes from the perspective of quorum requirements\nRisk Stewards specific to Supply/Borrow and GHO Mint Caps\nAsset listings when the asset is already active on another Aave deployment\n\nA loose idea is to have a rule of thumb whereby the vote cycle starts early in the week for all the non urgent votes. ie: minimise weekend voting where possible.\nIn the past, some teams have gone direct to AIP with minimal input from the community. This is normally the result of an abundance of caution from a risk perspective, which in recent votes has at times been voted down or quickly overturned by a later AIP submission.\nIf the objective is to be comprehensive, then all governance flows should be detailed in a single place. Or as a minimum cross referenced. Supply/Borrow caps amendments need to go through this process when both Chaos Labs and Gauntlet don’t support the proposed risk parameter changes. Having visibility of that governance flow here adds visibility to anyone using this post as the source of truth.\nRegarding the content of specifications, there seems to be a distinct difference between [TEMP CHECKS] and [ARFC]. [TEMP CHECK] appears to be more narrative and [ARFC] more technical. Directionally, we agree. However, more granularity on the distinctions is warranted as the text in the proposal is open for a wide array of interpretation.\nThis publication is a great start and in our honest opinion, it can be expanded to become more of a holistic source of truth for Aave governance. We are happy to help wherever possible to make this a more holistic framework.\n\n post by WintermuteGovernance on Jun 27, 2023\n\n WintermuteGovernance\n\n Hey @MarcZeller,\nThanks for putting this together and we support the proposed framework, template, and voting requirements.\nI think it would help the community if the new framework + template is easily accessible via a pinned post in the forum. Would it also be possible to have: Aave Protocol Overview updated to reflect these changes?\n\nI assume that if this proposal is approved, every off-chain vote will follow this template and voting guideline including Temp Checks + AFRC for level 2 governance (long executor). It won’t be until the AIP stage that voting guidelines are changed for level 2 governance votes. However, providing examples of what’s valid under these frameworks could certainly dispel some confusion.\n\n post by MarcZeller on Jun 28, 2023\n\n MarcZeller\n\n Hello and thx for your replies,\n@WintermuteGovernance answered to @TokenLogic on Long Executor proposals, no change until the AIP stage.\n\nthis documentation is controlled by the @AaveLabs so up to them to stay up to date.\n\nwe worked with stable labs to do this : Aave Finance Governance Process v0 it’s not perfect, but it’s a start, it will be updated to reflect governance decisions.\n\n post by TokenLogic on Jun 28, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Thank you for the feedback @WintermuteGovernance and @MarcZeller.\nTo confirm, adding assets already listed on one Aave deployment to another shall require a [TEMP CHECK] and [ARFC] Snapshot vote as per this proposal ?\nFor risk parameter changes deemed necessary, these can go direct to AIP without any Snapshot vote and fall outside of this framework ?\nCan we add this process flow into this framework.\nRegarding Supply/Borrow Caps, if we need to route via Snapshot. Does it make sense to vote twice given the both proposals [TEMP CHECK] and [ARFC] given the same known risk parameters are stated in the both Snapshot votes. There is an opportunity to remove some duplication by having a single Snapshot vote on Supply / Borrow Caps.\n\n post by fumoffuXx on Jun 28, 2023\n\n fumoffuXx\n\n So we are now amending governance procedures and definition without community acceptance through a poll?\nTalk about centralised mindset and lack of integrity\n\n post by EzR3aL on Jun 28, 2023\n\n EzR3aL\n\n Regular\n\n Hi,\ni don’t get what the problem here is?\nIf anybody involved in the DAO is against this, this person can come here and say so.\nIts just about a framwork for the different steps, which helps to organize stuff in here.\nThe snapshots and votings in the end will be voted decentralized.\n\n post by fumoffuXx on Jun 28, 2023\n\n fumoffuXx\n\n I am saying he can come up with hes own interpretation of the governance and expect everyone to follow it without question?\nNo one ever questions the intent of that form of interpretation?\nThere is something effy between aci and the entire TUSD fiasco.\n\n post by MarcZeller on Jun 28, 2023\n\n MarcZeller\n\nYou’re aware this goes to snapshot and needs to be approved by governance?\n\n post by fumoffuXx on Jun 28, 2023\n\n fumoffuXx\n\n Yes, just making sure procedures are followed and not bypassed. Moral Hazard is a disease in DEFI.\n\n post by 0xkeyrock.eth on Jun 29, 2023\n\n 0xkeyrock.eth\n\n Thanks for this framework @MarcZeller. It was definitely needed and creates much clearer guidelines for everyone while enabling easier access for anyone to place proposals and with the help of Skyward potentially escalate further in governance once there is community feedback.\nIn a scenario where this is a successful ARFC, we would strongly recommend as well that this gets pinned by @AaveLabs.\n\n post by Michigan_Blockchain on Jul 2, 2023\n\n Michigan_Blockchain\n\n Thank you for this much needed framework! This adds clarity for delegates and third parties who are new to making proposals. Michigan supports this proposal.\nIn the future, could we also have some guidelines on, at the ARFC stage, which service providers’ input are needed for each type of proposals? For example, for proposals regarding onboarding new oracles, who are the relevant service providers in addition to BGD?\n\n post by lbsblockchain on Jul 5, 2023\n\n lbsblockchain\n\n Thank you for this framework @MarcZeller and ACI, definitely needed! We agree with @Michigan_Blockchain around the need to provide guidelines on service provider input - it’ll make it easier for proposers to contact the relevant teams.\nWith regard to @TokenLogic’s comments on the Supply/Borrow Caps, if changes are to be made to those we agree that we should only have a single Snapshot vote. However, new listings on a new Aave deployment, regardless of whether it is present on another deployment, should require a TEMP CHECK as well since conditions across chains (e.g., liquidity) can materially differ.\nFurther additions to this framework could include more details around AIPs and specifically where proposals could directly go to the AIP stage and where it may not be appropriate to do so. However, we recognise that this proposal is to more keenly define the TEMP CHECK and ARFC stages of governance, and more details on the AIP stage can be added later.\n\n LBS Blockchain Society Delegate Platform\n\n post by MarcZeller on Jul 6, 2023\n\n MarcZeller\n\nThis is good feedback, will publish a framework on this shortly\n\nWe agree, these cases should be covered, voted and integrated in existing guidelines\n\nThis framework is the “general purpose” one, designed to act as the basic template for proposals, exceptions to these frameworks for specific cases will be voted on separately such as current “cap update framework” that is currently discussed to be updated as a “direct-to-Aip” framework allowing governance to bypass current framework for specific actions.\n\n post by MarcZeller on Jul 6, 2023\n\n MarcZeller\n\n Snapshot outcome is YAE and this framework is now officially integrated in Aave DAO governance Guidelines.\n\n 1 month later\n\n Closed on Aug 5, 2023\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n 27 days later\n\n Pinned on Sep 1, 2023\n\n 3 months later\n\n post by ACI on Dec 1, 2023\n\n ACI\n\n Leader\n\n Hello frens,\nAs you may have seen recently, there’s been some upgrades to update the Asset Onboarding Framework. Please find attached latest ARFC with a more detailed explanation on the changes to establish a streamlined governance process for adding new markets and streamline the listing of assets with existing Aave markets on new chains.\nThe listing framework aims to balance security and speed by providing a more efficient governance process for asset onboarding. We have established the precedent with past proposals that have improved timeliness and governance overhead. This will define a clearer and accessible standard in the same spirit as the DAO’s historic process.\nUpdated Asset Onboarding Framework\n\n [TEMP CHECK] Enable Metis as Collateral on Metis Chain\n\n Proposal to add WSOL as collateral\n\n AMPL problem on Aave v2 Ethereum\n\n Proposal Clarification\n\n [TEMP CHECK] Port of Aave to Solana using Formal Verification\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC ADDENDUM] Updated Framework for ARFC and TEMP CHECK Proposals\n\n General\n\n 6\n\n 533\n\n Aug 2024\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 697\n\n Aug 9\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 143\n\n Aug 10\n\n ARC: Aave Governance Process Improvements\n\n Governance\n\n 7\n\n 3.4k\n\n Mar 2023\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d","tokens":4238,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260437121,"hash":"824f7c0312a85850bbe0ed87b0019041d58846e7"}
{"url":"https://vote.optimism.io/proposals/94653586928704829987664319556957069435634532914401865187521227109996000544034","domain":"vote.optimism.io","title":"Milestones and Metrics Council Dissol...","text":"ProposalsVotersConnect  Wallet Standard Proposal by The Optimism FoundationMilestones and Metrics Council Dissolution ProposalProposal Visualization No substantive onchain transactions.The Foundation has proposed the dissolution of the Milestones and Metrics Council following Season 9. As outlined in the Operating Manual, a persistent Council continues into the next Season unless a dissolution proposal is approved.\nAfter multiple seasons of operation, the Foundation has assessed that the Council adds coordination overhead and slows grant disbursements without proportional accountability benefits. Since the Foundation has also proposed dissolving the Grants Council, the Milestones and Metrics Council’s Charter would no longer serve a purpose once community-led grant programs roll off.\nYou can read the proposal in its entirety here.\nIf approved, the Milestones and Metrics Council will be dissolved effective immediately. Any remaining milestones for existing Grants Council grants will be monitored by the Foundation via a third-party contractor agreement.\nIf the proposal is not approved, a prospective Lead would need to propose a budget and recruit candidates in the next voting cycle. The Foundation will not provide operational support or facilitate coordination with core teams.FOR - 22,938,451 AGAINST - 195,042 Quorum 16,540,389 Threshold 51%PASSEDEnded 3:54 pm Jul 15, 2026VotersHasn't voteddelegate.testinprod-io.eth8,485,127 op.evabeylin.eth4,000,000 delegate.l2beat.eth3,978,749 olimpio.eth2,157,950 cerv1.eth2,000,002 The M&M Council did a lot of excellent work for Optimism. My vote \"for\" dissolving it does not negate that impact, only admission that the council no longer is a good fit for Optimism's current GTM strategy and keeping it around with diminished authority (and no community grants program) would do more harm than good.tboptimist.eth2,000,000 pgov.eth1,015,868 fireeyesgov.eth591,240 gfxlabs.eth577,564 griff.eth330,189 wintermutegovernance.eth259,420 0xc2...d1ab221,122 cp0x.eth183,611 Standard Proposal by The Optimism FoundationMilestones and Metrics Council Dissolution ProposalProposal Visualization Loading transactions...No substantive onchain transactions.The Foundation has proposed the dissolution of the Milestones and Metrics Council following Season 9. As outlined in the Operating Manual, a persistent Council continues into the next Season unless a dissolution proposal is approved.\nAfter multiple seasons of operation, the Foundation has assessed that the Council adds coordination overhead and slows grant disbursements without proportional accountability benefits. Since the Foundation has also proposed dissolving the Grants Council, the Milestones and Metrics Council’s Charter would no longer serve a purpose once community-led grant programs roll off.\nYou can read the proposal in its entirety here.\nIf approved, the Milestones and Metrics Council will be dissolved effective immediately. Any remaining milestones for existing Grants Council grants will be monitored by the Foundation via a third-party contractor agreement.\nIf the proposal is not approved, a prospective Lead would need to propose a budget and recruit candidates in the next voting cycle. The Foundation will not provide operational support or facilitate coordination with core teams.FOR - 22,938,451 AGAINST - 195,042 Quorum 16,540,389 Threshold 51%PASSEDEnded 8:54 pm Jul 15, 2026VotersHasn't votedLoading votes...Milestones and Metrics Council Dissol...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":896,"squid":"ink-governance","role":"Council Listener","at":1791260437437,"hash":"e2f8d83aebe71e52926d5248259faf1505d9e777"}
{"url":"https://eips.ethereum.org/EIPS/eip-170","domain":"eips.ethereum.org","title":"EIP-170: Contract code size limit","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-170: Contract code size limit\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2016-11-04\n\n Hard fork\n\nSpurious Dragon\n\n Parameters\n\n MAX_CODE_SIZE: 0x6000 (2**14 + 2**13)\n FORK_BLKNUM: 2,675,000\n CHAIN_ID: 1 (Mainnet)\n\n Specification\n\nIf block.number >= FORK_BLKNUM, then if contract creation initialization returns data with length of more than MAX_CODE_SIZE bytes, contract creation fails with an out of gas error.\n\n Rationale\n\nCurrently, there remains one slight quadratic vulnerability in Ethereum: when a contract is called, even though the call takes a constant amount of gas, the call can trigger O(n) cost in terms of reading the code from disk, preprocessing the code for VM execution, and also adding O(n) data to the Merkle proof for the block’s proof-of-validity. At current gas levels, this is acceptable even if suboptimal. At the higher gas levels that could be triggered in the future, possibly very soon due to dynamic gas limit rules, this would become a greater concern—not nearly as serious as recent denial of service attacks, but still inconvenient especially for future light clients verifying proofs of validity or invalidity. The solution is to put a hard cap on the size of an object that can be saved to the blockchain, and do so non-disruptively by setting the cap at a value slightly higher than what is feasible with current gas limits.\n\n References\n\n EIP-170 issue and discussion: https://github.com/ethereum/EIPs/issues/170\n pyethereum implementation: https://github.com/ethereum/pyethereum/blob/5217294871283d8dc4fb3ca9d8a78c7d416490e8/ethereum/messages.py#L397\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-170: Contract code size limit,\" Ethereum Improvement Proposals, no. 170, November 2016. Available: https://eips.ethereum.org/EIPS/eip-170.","tokens":463,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260443197,"hash":"a7f1414f00293ffa8e8acf7db213c3dc658d1569"}
{"url":"https://governance.aave.com/t/proposal-clarification/17831/2","domain":"governance.aave.com","title":"Proposal Clarification - Other - Aave","text":"Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 2 / 4\n\n May 2024\n\n May 2024\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Hi all,\nI need some clarification on the Aave governance voting process, as I am not very familiar with it but I want to make sure I’m following the correct procedures.\nMy next task is to initiate a consensus vote for the snapshot and this message appears. Can I currently hold 1.6k AAVE tokens on Matic only? or is it only necessary to have the 1.6k AAVE splitter in multiple types? like also AAVE in stkBPT or other variations?\nThanks and sorry for asking but it’s unclear and I want to do things in the correct way :)\n\n 2\n\n post by EzR3aL on May 30, 2024\n\n EzR3aL\n\n Regular\n\n Hi, I’m not sure what exactly you want. But if you need guidelines for a proposal then see here. [ARFC] ARFC and TEMP CHECK Framework - #20 by ACI\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Thanks man, here is the screen\n\nDo you think it is ok to have 1.6k AAVE on matic only or need to have these tokens on multiple chains?\nThanks a lot \n\n 1 month later\n\n Closed on Jun 29, 2024\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 143\n\n Aug 10\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 697\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n Apu Mallku [Delegate platform]: Shutdown \n\n Delegate Platforms\n\n 6\n\n 1.1k\n\n Apr 12","tokens":443,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260447284,"hash":"8f36cfcfe20fbb152e35054227af93d9e7723e46"}
{"url":"https://vote.optimism.io/delegates/0x06ad892ce23c136bbda3a821570343a2af3e2914","domain":"vote.optimism.io","title":"delegate.testinprod-io.eth on Agora","text":"Voted for this proposal about 2 months ago with 8.49M votesRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundReason: Winning an enterprise deal is hard. Tokens are usually part of the deal, and the bidding is competitive. We think exact numbers (e.g., allocation per deal) are exactly what we shouldn't want disclosed as competitors could just match them. \n\nWe're in an uphill battle, the enterprise market is expensive, and the window is now. We think we need the war chest today, and we should be careful about handing information to competitors. So we're voting For, with one ask: as you execute, please share what you can after the fact (e.g., aggregate deployment and outcomes). We think that's what token holders actually need.Voted for this proposal 3 months ago with 8.49M votesSecurity Council Operating BudgetVoted for this proposal 3 months ago with 8.49M votesSequencer ETH Management: 12-Month Renewal and Treasury OptimizationVoted for this proposal 3 months ago with 8.49M votesOperating Manual Update ProposalVoted for this proposal 3 months ago with 8.49M votesDeveloper Advisory Board Dissolution ProposalVoted for this proposal 3 months ago with 8.49M votesMilestones and Metrics Council Dissolution ProposalVoted for this proposal 3 months ago with 8.49M votesGrants Council Dissolution ProposalVoted on 6 options in this proposal 4 months ago with 8.48M votes[Second vote] Security Council Elections Cohort B MembersVoted: Matthew Slipper, INK Foundation, donnoh, OP Labs, Test in Prod, dcbuilder.ethVoted on 6 options in this proposal 4 months ago with 8.12M votesSecurity Council Elections Cohort B MembersVoted: Matthew Slipper, INK Foundation, donnoh, OP Labs, Test in Prod, dcbuilder.ethVoted for this proposal 8 months ago with 6.54M votesDAO Operating Budget Midpoint AdjustmentVoted for this proposal 8 months ago with 6.54M votesProposal to Align OP Token with Superchain SuccessReason: We are finally happy to see the OP token and the Superchain aligning.Voted on 1 options in this proposal 12 months ago with 6.48M votesSecurity Council Elections: Cohort A LeadalishaVoted on 8 options in this proposal 12 months ago with 6.48M votesSecurity Council Elections Cohort A MembersVoted: Agora, Alchemy Insights, Inc., Cyfrin, Emiliano, Mariano, pablito.eth, Uniswap Foundation, VelodromeVoted for this proposal about 1 year ago with 6.24M votesSecurity Council Season 7 Retroactive Funding RequestVoted on 5 options in this proposal about 1 year ago with 6.07M votesGrants Council Election: Final ReviewerVoted: Doug sugma, GFX Labs, MasterMojo, mattgov.eth, MichaelVoted on 4 options in this proposal about 1 year ago with 6.07M votesSeason 8/9 Operating BudgetsVoted: Developer Advisory Board Operating Budget, Grants Council Operating Budget, Milestones & Metrics Council Operating Budget, Security Council Operating BudgetVoted on 1 options in this proposal about 1 year ago with 6.07M votesGrants Council Election: OperationsBunnicVoted on 6 options in this proposal about 1 year ago with 6.07M votesDeveloper Advisory Board Election: MembersVoted: blockdev, devtooligan, m4rio, 𓀣 Odysseas.eth 𓀢, Vectorized, wbnnsVoted on 4 options in this proposal about 1 year ago with 6.07M votesMilestones & Metrics Council Election: ReviewersVoted: Brichis, SEEDGov, Tané, v3naruVoted for this proposal about 1 year ago with 6.26M votesBudget Board Advisory Proposal for the DAO Operating Budget for Seasons 8 and 9Voted for this proposal about 1 year ago with 6.26M votesUpgrade 16 Proposal: Interop Contracts, Stage 1, and Go 1.23 Support in CannonVoted for this proposal over 1 year ago with 5.93M votesSeason 8: Intent RatificationVoted for this proposal over 1 year ago with 5.93M votesSeason 8/9 Developer Advisory Board CharterVoted for this proposal over 1 year ago with 5.93M votesGovernor Update Proposal: Removing Abstain Count from QuorumVoted for this proposal over 1 year ago with 5.93M votesSeason 8/9 Milestones and Metrics Council CharterVoted for this proposal over 1 year ago with 5.93M votesSeason 8/9 Grants Council CharterVoted for this proposal over 1 year ago with 5.55M votesSeason 8 and 9 Milestone and Metrics Council SelectionReason: The Collective experiment is still in its early stages and requires various kinds of experiments. We think this experiment would give us more insights into how the selection should be in the longer term; also, the risk seems to be fairly small.Voted for this proposal over 1 year ago with 5.56M votesSeason 8 and 9: Budget Board Member RatificationVoted for this proposal over 1 year ago with 5.74M votesUpgrade Proposal #15: Isthmus Hard ForkVoted for this proposal over 1 year ago with 5.74M votesUpgrade Proposal #14: Isthmus L1 Contracts + MT-CannonReason: This proposal increases OP Chains' throughput as it enables multi-threading & 64-bit for Cannon. Also, this allows more accurate user fee pricing. We're voting for this proposal.Voted for this proposal over 1 year ago with 5.7M votesUpgrade Proposal #13: OPCM and Incident Response improvementsVoted on 7 options in this proposal over 1 year ago with 5.27M votesSecurity Council Elections Cohort B MembersVoted: World Foundation, OP Labs, L2BEAT, Alchemy, Test in Prod, Ink, CoinbaseVoted on 4 options in this proposal over 1 year ago with 5.27M votesGrants Council GrantNerd ElectionsVoted: Brichis, Jrocki, mastermojo, SovVoted on 4 options in this proposal over 1 year ago with 5.27M votesDeveloper Advisory Board Governance Mission Team ElectionsVoted: Will, Jepsen, blockdev, IainVoted on 3 options in this proposal over 1 year ago with 5.27M votesDeveloper Advisory Board Audit Request Team ElectionsVoted: m4rio.eth, noah.eth, unsafe_callVoted for this proposal over 1 year ago with 5.27M votesSeason 7: Chain Delegation Program AmendmentReason: We believe the message & intent are clear—foster Superchain members' governance participation. This aligns with the entire Collective’s intent. We’re voting for this proposal.Voted on 4 options in this proposal over 1 year ago with 5.27M votesGrants Council Final Reviewer ElectionsVoted: MattGov.eth, GFX Lab, Michael, jackanorakReason: We prioritized those we believe to have extensive context about the Collective and who have already proven to spend enough time on the role based on their previous Collective governance participation.Voted on 2 options in this proposal over 1 year ago with 5.27M votesDeveloper Advisory Board Foundation Mission Team ElectionsVoted: Skeletor, DanyalReason: We believe OP Stack core contributors would be a good fit for the role.Voted on 3 options in this proposal over 1 year ago with 5.27M votesMilestones and Metrics Council Reviewer ElectionsVoted: LauNaMu, v3naru_Curia, Pumbi (SEEDGov)Reason: We're voting for those with extensive experience in Optimism Governance & relevant activities.Voted on 1 options in this proposal over 1 year ago with 5.27M votesGrants Council Operations ElectionsBunnicVoted for this proposal almost 2 years ago with 5.16M votesSeason 7: Milestones and Metrics Council Operating BudgetVoted for this proposal almost 2 years ago with 5.16M votesDecision Market Mission [Onchain]Voted for this proposal almost 2 years ago with 5.16M votesGrants Council Mission [Onchain]Voted for this proposal almost 2 years ago with 5.16M votesCode of Conduct Council Dissolution ProposalVoted for this proposal almost 2 years ago with 5.16M votesSeason 7: Intent RatificationReason: Happy that we're focusing on the most important product of the Collective—Interop. The implementation details are clear & transparent. \n\nWe're voting for the proposal.Voted abstain this proposal almost 2 years ago with 5.16M votesSeason 7: Security Council Operating Budget [Onchain]Reason: We're voting abstain as we're participating in the security council.Voted for this proposal almost 2 years ago with 5.16M votesSeason 7: Developer Advisory Board Operating BudgetReason: The Collective builds sophisticated technology, and not all citizens are experts. DAB is doing a great job bridging the gap and advising decisions. We appreciate their work, and the proposal makes sense.\n\nWe're voting for this proposal.Voted for this proposal almost 2 years ago with 5.16M votesSeason 7: Grants Council Operating BudgetReason: Appreciate you all for the hard work!Voted for this proposal almost 2 years ago with 5.16M votesSeason 7: Anticapture Commission AmendmentVoted for this proposal almost 2 years ago with 5.16M votesOnchain Treasury Transfer Cancellation TestVoted for this proposal almost 2 years ago with 5.16M votesUpgrade Proposal #11: Holocene Network UpgradeReason: As one of the core development teams of Optimism Collective, we believe all the changes Holocene proposes are necessary: Derivation pipeline improvement, independent gas configurations, and more MIPS syscalls. The rollout plan is clear and was well executed in the test environments. \n\nWe're voting for this proposal.Voted for this proposal almost 2 years ago with 4.53M votesGovernor Update Proposal #3: Enable Onchain Treasury ExecutionReason: Agora is a trustworthy team that has been contributing to the Collective's core governance software for many months, and the upgrade proposal is clear. We're voting for this proposal.Voted for this proposal almost 2 years ago with 4.53M votesSeason 6: Standard Rollup Charter RatificationReason: This charter clarifies which chains are subject to join Superchain—the Collective's core product. The writers also revised the proposal over many months, giving the community enough time to ratify it. \n\nWe're voting for this proposal.","tokens":2403,"squid":"ink-governance","role":"Council Listener","at":1791260448533,"hash":"1e66f0c743eee5102f209c05c4e6bb1751d75793"}
{"url":"https://eips.ethereum.org/EIPS/eip-160","domain":"eips.ethereum.org","title":"EIP-160: EXP cost increase","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-160: EXP cost increase\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2016-10-20\n\n Hard fork\n\nSpurious Dragon\n\n Parameters\n\n FORK_BLKNUM: 2,675,000\n CHAIN_ID: 1\n\n Specification\n\nIf block.number >= FORK_BLKNUM, increase the gas cost of EXP from 10 + 10 per byte in the exponent to 10 + 50 per byte in the exponent.\n\n Rationale\n\nBenchmarks suggest that EXP is currently underpriced by a factor of about 4–8.\n\n References\n\n EIP-160 issue and discussion: https://github.com/ethereum/EIPs/issues/160\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-160: EXP cost increase,\" Ethereum Improvement Proposals, no. 160, October 2016. Available: https://eips.ethereum.org/EIPS/eip-160.","tokens":186,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260454448,"hash":"09337dd9fbd93790ff523cc6b0b0ece3f45f0bf4"}
{"url":"https://governance.aave.com/t/proposal-clarification/17831/4","domain":"governance.aave.com","title":"Proposal Clarification - Other - Aave","text":"Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 4 / 4\n\n Jun 2024\n\n May 2024\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Hi all,\nI need some clarification on the Aave governance voting process, as I am not very familiar with it but I want to make sure I’m following the correct procedures.\nMy next task is to initiate a consensus vote for the snapshot and this message appears. Can I currently hold 1.6k AAVE tokens on Matic only? or is it only necessary to have the 1.6k AAVE splitter in multiple types? like also AAVE in stkBPT or other variations?\nThanks and sorry for asking but it’s unclear and I want to do things in the correct way :)\n\n 2\n\n post by EzR3aL on May 30, 2024\n\n EzR3aL\n\n Regular\n\n Hi, I’m not sure what exactly you want. But if you need guidelines for a proposal then see here. [ARFC] ARFC and TEMP CHECK Framework - #20 by ACI\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Thanks man, here is the screen\n\nDo you think it is ok to have 1.6k AAVE on matic only or need to have these tokens on multiple chains?\nThanks a lot \n\n 1 month later\n\n Closed on Jun 29, 2024\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 143\n\n Aug 10\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 697\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n Apu Mallku [Delegate platform]: Shutdown \n\n Delegate Platforms\n\n 6\n\n 1.1k\n\n Apr 12","tokens":443,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260457703,"hash":"b6ab7b55791a3200781c0c02a1761e9301bb16a4"}
{"url":"https://vote.optimism.io/proposals/52279585228711683139994867226626537890640289086801310015986428088919427604597","domain":"vote.optimism.io","title":"Operating Manual Update Proposal","text":"ProposalsVotersConnect  Wallet Standard Proposal by The Optimism FoundationOperating Manual Update ProposalProposal Visualization No substantive onchain transactions.The Optimism Foundation proposes a Pull Request to make changes to the Operating Manual: https://github.com/ethereum-optimism/OPerating-manual/pull/70\nThe changes proposed are summarized below:\n\nRemoves all mention of the Citizens House, as the Foundation has decided to temporarily pause its operations\nRemoves all mention of Joint House voting as only the Token House will vote while the Citizens’ House is paused\nAdds key election policies previously outlined in various forum posts for clarity\n\nAdditions to the Operating Manual do not require governance approval. Removals of important items from the Operating Manual do require approval. Therefore, the Token House must approve the proposed changes with a 51% approval threshold. If you vote “yes” for this proposal, the PR will be approved and merged to update the Operating Manual hosted here: https://github.com/ethereum-optimism/OPerating-manual\nYou can read the proposal in its entirety hereFOR - 22,338,869 AGAINST - 194,476 Quorum 16,540,389 Threshold 51%EXECUTEDExecuted 7:36 am Jul 19, 2026VotersHasn't voteddelegate.testinprod-io.eth8,485,127 op.evabeylin.eth4,000,000 delegate.l2beat.eth3,978,749 olimpio.eth2,157,950 cerv1.eth2,000,002 ggtboptimist.eth2,000,000 pgov.eth1,015,868 fireeyesgov.eth591,240 gfxlabs.eth577,564 griff.eth330,189 wintermutegovernance.eth259,420 0xc2...d1ab221,122 cp0x.eth183,611 Standard Proposal by The Optimism FoundationOperating Manual Update ProposalProposal Visualization Loading transactions...No substantive onchain transactions.The Optimism Foundation proposes a Pull Request to make changes to the Operating Manual: https://github.com/ethereum-optimism/OPerating-manual/pull/70\nThe changes proposed are summarized below:\n\nRemoves all mention of the Citizens House, as the Foundation has decided to temporarily pause its operations\nRemoves all mention of Joint House voting as only the Token House will vote while the Citizens’ House is paused\nAdds key election policies previously outlined in various forum posts for clarity\n\nAdditions to the Operating Manual do not require governance approval. Removals of important items from the Operating Manual do require approval. Therefore, the Token House must approve the proposed changes with a 51% approval threshold. If you vote “yes” for this proposal, the PR will be approved and merged to update the Operating Manual hosted here: https://github.com/ethereum-optimism/OPerating-manual\nYou can read the proposal in its entirety hereFOR - 22,338,869 AGAINST - 194,476 Quorum 16,540,389 Threshold 51%EXECUTEDExecuted 12:36 pm Jul 19, 2026VotersHasn't votedLoading votes...Operating Manual Update ProposalGovernance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":729,"squid":"ink-governance","role":"Council Listener","at":1791260460986,"hash":"971e635fb8520acf728c8695419527d39a9a983b"}
{"url":"https://eips.ethereum.org/EIPS/eip-2464","domain":"eips.ethereum.org","title":"EIP-2464: eth/65: transaction announcements and retrievals","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-2464: eth/65: transaction announcements and retrievals\n\n Introduces `NewPooledTransactionHashes`, `GetPooledTransactions`, and `PooledTransactions`.\n\n Authors\n Péter Szilágyi <peterke@gmail.com>, Péter Szilágyi (@karalabe), Gary Rong <garyrong0905@gmail.com>, Tim Beiko (@timbeiko)\n\n Created\n 2020-01-13\n\n Requires\n\n EIP-2364\n\n Abstract\n\nThis EIP introduces three additional message types into the eth protocol (releasing a new version, eth/65): NewPooledTransactionHashes (0x08) to announce a set of transactions without their content; GetPooledTransactions (0x09) to request a batch of transactions by their announced hash; and PooledTransactions (0x0a) to reply to a transaction request. This permits reducing the bandwidth used for transaction propagation from linear complexity in the number of peers to square root; and also reducing the initial transaction exchange from 10s-100s MB to len(pool) * 32B ~= 128KB.\n\n Motivation\n\nThe eth network protocol has two ways to propagate a newly mined block: it can be broadcast to a peer in its entirety (via NewBlock (0x07) in eth/64 and prior or it can be announced only (via NewBlockHashes (0x01)). This duality allows nodes to do the high-bandwidth broadcasting (10s-100s KB) for a square root number of peers; and the low-bandwidth announcing (10s-100s B) for the remaining linear number of peers. The square root broadcast is enough to reach all well connected nodes, but the linear announce is needed to get across degenerate topologies. This works well.\n\nThe eth protocol, however, does not have a similar dual mechanism for propagating transactions, so nodes need to rely on broadcasting (via Transactions (0x02)). To cater for degenerate topologies, transactions cannot be broadcast square rooted, rather they need to be transferred linearly to all peers. With N peers, each node will transfer the same transaction N times (counting both directions), whereas 1 would be enough in a perfect world. This is a significant waste.\n\nA similar issue arises when a new network connection is made between two nodes, as they need to sync up their transaction pools, but the pool is just a soup of dangling transactions. Without a way to deduplicate transactions remotely, each node is forced to naively transfer their entire list of transactions to the other side. With pools containing thousands of transactions, a naive transfer amounts to 10s-100s MB, most of which is useless. There is no better way, however.\n\nThis EIP introduces three additional message types into the eth protocol (releasing a new version, eth/65): NewPooledTransactionHashes (0x08) to announce a set of transactions without their content; GetPooledTransactions (0x09) to request a batch of transactions by their announced hash; and PooledTransactions (0x0a) to reply to a transaction request. This permits reducing the bandwidth used for transaction propagation from linear complexity in the number of peers to square root; and also reducing the initial transaction exchange from 10s-100s MB to len(pool) * 32B ~= 128KB.\n\nWith transaction throughput (and size) picking up in Ethereum, transaction propagation is the current dominant component of the used network resources. Most of these resources are however wasted, as the eth protocol does not have a mechanism to deduplicate transactions remotely, so the same data is transferred over and over again across all network connections.\n\nThis EIP proposes a tiny extension to the eth protocol, which permits nodes to agree on the set of transactions that need to be transferred across a network connection, before doing the costly exchange. This should help reduce the global (operational) bandwidth usage of the Ethereum network by at least an order of magnitude.\n\n Specification\n\nAdd three new message types to the eth protocol:\n\n NewPooledTransactionHashes (0x08): [hash_0: B_32, hash_1: B_32, ...]\n\n Specify one or more transactions that have appeared in the network and which have not yet been included in a block. To be maximally helpful, nodes should inform peers of all transactions that they may not be aware of.\n There is no protocol violating hard cap on the number of hashes a node may announce to a remote peer (apart from the 10MB devp2p network packet limit), but 4096 seems a sane chunk (128KB) to avoid a single packet hogging a network connection.\n Nodes should only announce hashes of transactions that the remote peer could reasonably be considered not to know, but it is better to be over zealous than to have a nonce gap in the pool.\n\n GetPooledTransactions (0x09): [hash_0: B_32, hash_1: B_32, ...]\n\n Specify one or more transactions to retrieve from a remote peer’s transaction pool.\n There is no protocol violating hard cap on the number of transactions a node may request from a remote peer (apart from the 10MB devp2p network packet limit), but the recipient may enforce an arbitrary cap on the reply (size or serving time), which must not be considered a protocol violation. To keep wasted bandwidth down (unanswered hashes), 256 seems like a sane upper limit.\n\n PooledTransactions (0x0a): [[nonce: P, receivingAddress: B_20, value: P, ...], ...]\n\n Specify transactions from the local transaction pool that the remote node requested via a GetPooledTransactions (0x09) message. The items in the list are transactions in the format described in the main Ethereum specification.\n The transactions must be in same order as in the request, but it is ok to skip transactions that are not available. This way if the response size limit is reached, requesters will know which hashes to request again (everything from the last returned transaction) and which to assume unavailable (all gaps before the last returned transaction).\n A peer may respond with an empty reply iff none of the hashes match transactions in its pool. It is allowed to announce a transaction that will not be served later if it gets included in a block in between.\n\n Rationale\n\nQ: Why limit GetPooledTransactions (0x09) to retrieving items from the pool?\n\nApart from the transaction pool, transactions in Ethereum are always bundled together by the hundreds in block bodies and existing network retrievals honor this data layout. Allowing direct access to individual transactions in the database has no actionable use case, but would expose costly database reads into the network.\n\nFor transaction propagation purposes there is no reason to allow disk access, as any transaction finalized to disk will be broadcast inside a block anyway, so at worse there is a few hundred millisecond delay when a node gets the transaction.\n\nBlock propagation may be made a bit more optimal by transferring the contained transactions on demand only, but that is a whole EIP in itself, so better relax the protocol when all the requirements are known and not in advance. It would probably be enough to maintain a set of transactions included in recent blocks in memory.\n\nQ: Should NewPooledTransactionHashes (0x08) deduplicate from disk?\n\nSimilarly to GetPooledTransactions (0x09), NewPooledTransactionHashes (0x08) should also only operate on the transaction pool and should ignore the disk altogether. During healthy network conditions, a transaction will propagate through much faster than it’s included in a block, so it will essentially be non-existent that a newly announced transaction is already on disk. By avoiding disk deduplication, we can avoid a DoS griefing by remote transaction announces.\n\nIf we want to be really correct and avoid even the slightest data race when deduplicating announcements, we can use the same recently-included-transactions trick that we discussed above to discard announcements that have recently become stale.\n\nQ: Why not reuse Transaction (0x02) instead of a new PooledTransactions (0x0a)?\n\nOriginally this EIP reused the existing Transaction (0x02) message as the reply to the GetPooledTransactions (0x09) request. This makes client code more complicated, because nodes constantly gossip Transaction (0x02) messages to each other as broadcasts, so it’s hard to match up which of the many messages is the actual reply to the request.\n\nBy keeping Transaction (0x02) and PooledTransactions (0x0a) as separate messages, we can also leave the protocol more flexible for future optimizations (e.g. adding request IDs, which are meaningless for gossip broadcasts).\n\n Backwards Compatibility\n\nThis EIP extends the eth protocol in a backwards incompatible way and requires rolling out a new version, eth/65. However, devp2p supports running multiple versions of the same wire protocol side-by-side, so rolling out eth/65 does not require client coordination, since non-updated clients can keep using eth/64.\n\nThis EIP does not change the consensus engine, thus does not require a hard fork.\n\n Security Considerations\n\nNone.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Péter Szilágyi <peterke@gmail.com>, Péter Szilágyi (@karalabe), Gary Rong <garyrong0905@gmail.com>, Tim Beiko (@timbeiko), \"EIP-2464: eth/65: transaction announcements and retrievals,\" Ethereum Improvement Proposals, no. 2464, January 2020. Available: https://eips.ethereum.org/EIPS/eip-2464.","tokens":2311,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260464233,"hash":"e77499b0a6e8af33389fd8b52adb9fc6f83acff9"}
{"url":"https://governance.aave.com/t/arfc-governance-framework-v2/25348","domain":"governance.aave.com","title":"[ARFC] Governance Framework v2 - Governance / General - Aave","text":"[ARFC] Governance Framework v2 \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 20\n\n 1 / 4\n\n Jul 20\n\n Aug 9\n\n post by TokenLogic on Jul 20\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [ARFC] Governance Framework v2\nauthor: @TokenLogic\ncreated: 2026-07-20\n\nSummary\nThis publication presents an overview of the Aave DAO’s Governance Process v2 and, upon implementation, replaces the current Governance Process Document v1. v2 consolidates the governance process, presently spread across v1 and several newer frameworks, into a single canonical reference.\nThe mandatory TEMP CHECK stage of the governance process has been removed, and all role, guardian, and steward mandates have been refreshed to reflect the 2026 service provider landscape. Upon implementation, this framework streamlines the current 19-day process to 13 days, while ensuring risk and technical standards are upheld.\nMotivation\nOverview\nAave’s governance has matured into a lean, Service Provider model built for transparency and speed. This publication provides a holistic overview of Aave DAO’s governance processes and frameworks, designed to keep the DAO efficient, nimble, and structured. A focused group of service providers now delivers the core functions: Aave Labs on development and growth; LlamaRisk on risk; Certora on security; and TokenLogic on finance and growth.\nThis document supersedes the Governance Process Document v1 and shall be maintained over time, always reflecting the community’s current operational structure.\nRationale for retiring TEMP CHECK\nOne of the most significant efficiency improvements to the overall governance process presented here has been the retirement of TEMP CHECK from the standard path. With an emphasis on refining the economics of sequential adjustments in overall market risk, the initial intent to reduce workload on Risk and Technical service providers has been addressed. The process now begins with a business case to determine whether new assets or markets should be deployed.\nFurthermore, since the Governance Process Document v1 was written, the DAO has adopted structured evaluation frameworks, notably the Aave Risk Framework and the Technical Asset Listing Framework, providing clear public criteria that each proposal must satisfy before it can advance. The ARFC stage provides a public discussion window followed by a binding Snapshot vote, providing the community retains a clear opportunity to shape, support, or reject a proposal without running two sequential sentiment rounds.\nA notable distinction: the ARFC vote is binding, allowing the Aave DAO to make commitments before deploying technical resources for larger initiatives, such as deploying Aave Protocol instances, entering new markets within an existing instance, or committing to payment upon delivery of work scopes.\nGovernance Process\nAave’s governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and implement approved changes through a transparent, structured process.\nThe processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate. For more details, please refer to the official documentation.\nEvery type of governance action falls into one of three processes, based upon who they are implemented by:\n\nStandard Process: The default governance process consists of an ARFC governance proposal, a Snapshot vote and an on-chain vote to implement the upgrade. The Short Executor implements the vast majority of AIP proposals, with the Long Executor reserved for major upgrades.\nDirect-to-AIP Process: A refined on-chain voting process designed to enable simple parameter adjustments, not otherwise performed by Stewards, to be implemented quickly.\nSteward Process: This process facilitates high-cadence operational updates implemented by Service Providers within a tightly controlled, limited-access, and bounded environment, allowing the protocol to operate efficiently throughout the market cycle.\n\nimage4296×2163 352 KB\nThe gradual introduction of Steward roles allows for a growing portion of routine upgrades to shift from the Direct-to-AIP process to the Steward Process, streamlining the protocol’s operational readiness by enabling swift action and reducing administrative overhead. Token holders remain critical to shaping the future of business by retaining key decision-making power and electing to delegate daily operations to trusted actors who operate the Steward roles.\nStandard Process\nThe standard governance process for the Aave DAO follows the guidelines outlined below:\nimage2736×2373 376 KB\nReference: Aave Governance. Adjust Level 2 requirements (long-executor)\n\nGovernance Forum - Aave Request for Comment (ARFC)\nThis is where initial discussions take place, and feedback is gathered. Service providers and community members provide detailed feedback over a 4-day period on how the proposal would affect the protocol, helping prepare it for the AIP stage.\n\nSnapshot\nARFC voting takes place in the Aave Snapshot Space.\n\nVoting: If the proposal meets the required Snapshot threshold, it proceeds to the AIP stage; otherwise, it fails. Authors, proposition power, timing, and thresholds are detailed in the Voting section below.\n\nAave Improvement Proposal (AIP)\nThe AIP stage is where the proposal becomes a formal, on-chain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Aave’s governance contracts, primarily on the Ethereum Mainnet.\n\nVoting: Once on-chain, the AIP is voted on through Aave’s governance contracts. The on-chain stages, quorum, and vote differential are described in the Voting section below.\nExecution: A successful proposal moves to the execution phase, where it is enacted via Aave’s governance infrastructure. Depending on the type of proposal, a timelock delay (either 1 day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave’s Delivery Infrastructure (a.DI).\n\nLong Executor\nThe Long Executor (Level 2) governs the most sensitive parts of the protocol, those that define governance itself. It controls upgrades to the AAVE, stkAAVE, and aAAVE tokens, changes to the governance contracts and their permissions, and modifications to the executors and timelocks themselves. In short, it covers any change that could affect voting or proposition power. Because these changes carry the highest impact, the Long Executor applies stricter requirements than the Short Executor (Level 1), which handles day-to-day protocol matters such as asset listings, parameter updates, and treasury operations. A Level 2 proposal runs a longer 10-day voting period, requires a higher quorum and vote differential, and passes through a 7-day timelock before execution, compared with the 3-day vote and 1-day timelock of a Level 1 proposal. For the current thresholds and contract addresses, see the Aave governance documentation.\nimage4296×1857 366 KB\nDirect-to-AIP Process\nTo support timely implementation of protocol upgrades via Token holder vote, the Direct-to-AIP governance process supports a streamlined 2-step process: a forum post followed by an AIP. By removing the Snapshot vote, the Direct-to-AIP process reduces the governance duration by 4 days and the governance burden. This process is intended to expedite minor changes and can only be proposed by active Service Providers. An illustration of the process is shown below:\nimage2736×1671 221 KB\nTo be eligible for this non-standard Tokenholder voter process, an Active Aave DAO Service Provider must submit a Direct-to-AIP proposal that addresses one of the areas mentioned below:\n\nExisting Asset Listing\nExisting Asset Parameter Update (excl. controlled by Stewards)\nExisting Rolling Maturity Asset Listing Eg: Pendle PTs\nEmission Manager updates\nFunding Updates\nWhitelist Flashloan Borrowers (remove fee)\nTechnical Maintenance\nWhitelist addresses to claim rewards\nExtending SVR Integrations to new instances or assets\nCreation of new hubs and spokes on Aave V4 with existing assets\nRisk Parameters not amendable by Steward Role\n\nStewards Process\nStewards assist the DAO in mitigating potential risks by introducing controlled, incremental exposure adjustments and responding quickly to changing market conditions without the delay of the full governance process. The introduction of a steward role strictly enforces programmatic controls, allowing trusted actors to maintain precise parameters within the protocol, thereby fine-tuning it to prevailing market conditions and limiting exposure to adverse events. The principal rationale for introducing Stewards is to both mitigate risk through tightly controlled exposure limits on Assets and maintain operational readiness.\nimage2287×1482 216 KB\nEach steward is a DAO-owned contract that features delegated authority over a narrow set of parameters or operations, bounded in magnitude and frequency by hard-coded and governance-set limits. Governance owns every steward and can revoke it at any time. The current stewards span risk parameters, the GHO stablecoin, treasury and finance operations, cross-chain bridging (in development), bad-debt maintenance, and oracle migration. The Horizon instance is configured through a related delegated model, described at the end of this section.\nimage1920×3746 373 KB\nGHO Stewards\nThe GHO Stewards manage the GHO stablecoin within bounded limits. The current design is GHO Steward v2, a set of four modular contracts, each gated by a one-day timelock and a maximum change per update, and each callable only by the GHO Risk Council. The GHO Risk Council multisig is 0x8513e6F37dBc52De87b166980Fa3F50639694B60, whose signers are TokenLogic, LlamaRisk, and Aave Labs.\nGHO Aave Steward\nManages the GHO reserve in the Aave V3 core pool. It can adjust the GHO borrow and supply caps (up to +100% per update) and the four interest-rate parameters (optimal usage, base rate, slope 1, slope 2), each bounded to ±500 bps per update, with an overall borrow-rate ceiling of 25% APR. It cannot change collateral parameters, the oracle, or any non-GHO reserve. Cooldown: one day per parameter. Address: 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34.\nGHO Bucket Steward\nAdjusts facilitator bucket capacities, the mint ceiling of each controlled facilitator, by up to +100% per update, and only for facilitators on its controlled list. Cooldown: one day per facilitator. Address: 0x46Aa1063e5265b43663E81329333B47c517A5409.\nGHO GSM Steward\nManages the GHO Stability Module: the exposure cap (up to ±100% per update) and the buy and sell fees (up to ±0.50% per update). Freeze, unfreeze, and price-strategy changes are out of scope and require governance. Cooldown: one day per GSM per parameter. Address: 0xD1E856a947CdF56b4f000ee29d34F5808E0A6848.\nGHO CCIP Steward\nManages the cross-chain (Chainlink CCIP) parameters for GHO: the bridge limit and the inbound and outbound rate limits, each bounded to ±100% per update. Cooldown: one day per parameter. Address: 0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39.\nRisk Stewards\nRisk Stewards manage risk parameters within bounds defined by the Aave Risk Framework. They may tighten or calibrate only within these limits; loosening beyond them or releasing a freeze requires governance. Following the departure of Chaos Labs, the manual Risk Steward is operated by LlamaRisk together with Aave Labs, with a progressive migration to Chainlink Runtime Environment (CRE) automation. The Aave DAO retains full control of the automation.\nRisk Steward\nThe main risk steward. It can adjust supply and borrow caps, collateral parameters (LTV, liquidation threshold, liquidation bonus), interest-rate parameters (base rate, slope 1, slope 2, optimal usage), CAPO price-cap and Pendle discount parameters, and e-mode collateral parameters. It cannot set caps, LTV, LT, or liquidation bonus to zero, change an e-mode’s isolated flag or label, or act on restricted assets and oracles (for example, GHO on Ethereum). Per-update bounds and cooldowns:\n\nParameter\nMax change per update\nMinimum delay\nPending change (ARFC)\n\nLTV, LT, LB\n0.5% absolute change\n72 hours\n-\n\nEmode - LTV, LB\n0.5% absolute change\n72 hours\n-\n\nEmode - LT\n0.1% absolute change\n72 hours\n-\n\nBase rate, Slope 1\n1% absolute change\n72 hours\n36h\n\nSlope 2\n20% absolute change\n72 hours\n36h\n\nOptimal Usage Ratio\n3% absolute change\n72 hours\n36h\n\nSupply and borrow caps\n100% relative change\n72 hours\n36h\n\nCAPO Dynamic Cap\n5% relative change\n72 hours\n-\n\nCAPO Stable Cap\n0.5% relative change\n72 hours\n-\n\nPT Discount Rate\n2.5% absolute change\n48 hours\n-\n\nReference: [ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment\nFreezing Steward\nCan freeze a reserve immediately, blocking new supply and borrow while existing positions may still repay and withdraw. It cannot unfreeze; that requires governance. A tighten-only safeguard.\nFinance Stewards\nFinance Stewards execute pre-approved, budgeted treasury operations on behalf of the DAO through contracts that act as admins of the Collector, without a full on-chain vote. They are operated by the Aave Finance Committee (AFC), the multisig 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa, a 2-of-3 organisation-controlled multisig. The DAO retains ownership and can revoke the role.\nMainnet Swap Steward\nLive. Executes treasury token swaps via the CoW Protocol with a Chainlink oracle price check and slippage bounds, supporting market, limit, and TWAP orders, as well as order cancellation. It can only swap into DAO-whitelisted tokens, within per-token budgets, and proceeds always return to the Collector. Address: 0xb7D402138Cb01BfE97d95181C849379d6AD14d19.\nPool Exposure Steward\nLive. Migrates assets from Aave V2 to V3, and deposits or withdraws Collector funds within Aave V3. It cannot move funds outside approved Aave pools or deplete a reserve below its minimum floor. Address: 0x22aC12a6937BBBC0a301AF9154d08EaD95673122.\nCollector Budget Steward\nTransfers or streams Collector tokens to pre-approved recipients within DAO-defined budgets. It cannot send to non-whitelisted addresses or exceed a budget.\nRewards Steward\nLive. Claims liquidity-mining and Merit rewards accrued to the Collector and forwards them to the Collector. It holds no discretionary transfer power, and must first be granted claim rights by the Emission Manager.\nBridge Stewards\nIn development, not yet live. A family of per-route stewards (Polygon, Arbitrum, Optimism, plus CCTP and LayerZero routes) that will move Collector funds cross-chain back to the Ethereum Collector without a full a.DI governance vote. This fills a gap the Pool Exposure Steward cannot cover, since that steward only moves funds within a single chain. Operators will be set at deployment.\nMaintenance Stewards\nClinic Steward\nLive. Batch-liquidates dust and underwater positions and repays accumulated bad debt, funded from the Collector, within a fixed USD budget cap that only an admin can raise. It cannot act outside repayment, liquidation flows, or exceed the budget. Address: 0xf00E2de0E78DFf055A92AD4719a179CE275b6Ef7.\nDeficit Offset Clinic Steward\nLive. The Umbrella-linked sibling of the Clinic Steward, used to offset reserve deficits through Umbrella’s deficit-elimination flow. Address: 0x6c1DC85f2aE71C3DAcd6E44Bb57DEeF61b540a5A.\nSVR Oracle Steward\nLive. Migrates an asset to a Chainlink Smart Value Recapture (SVR) price feed only when its deviation from the current feed is minimal, and lets the Protocol Guardian revert to the previous feed if needed. Address: 0x8b493f416F5F7933cC146b1899c069F2361cad60.\nHorizon\nHorizon is configured through a delegated model rather than standard governance. The Executive role is assigned to Aave Labs, which manages day-to-day risk parameters, asset listings, oracle configuration, and supply and borrow caps directly, without an AIP vote for each change. The Aave DAO retains ownership of the contracts and controls upgrades, and it still configures the GHO facilitator and credit line by governance vote. Reference: [ARFC] Horizon’s RWA Instance.\nVoting\nOnce a proposal meets the required conditions, it can proceed to the voting stages, which include both off-chain and on-chain voting methods. Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives.\nOff-Chain\nOff-chain votes take place in the Aave Snapshot Space and are the community’s directionally binding signal on a proposal before it moves on-chain. They allow token holders to participate without incurring transaction fees. The off-chain voting stage enables the Aave DAO to make a public commitment to deliver something when there is a difference in timing and/or payment between when the business says it will do something and when that commitment is fulfilled.\nAuthors and proposition power. To open a Snapshot vote, the author must be on the approved list of Authors for the Aave space, or hold at least 80,000 AAVE of proposition power. This filters spam while allowing recognised service providers and delegates to propose without holding a large balance.\nimage3096×1743 323 KB\nController. The administration of the Aave DAO Snapshot space is carried out by the Aave Finance Committee SAFE 0x22740deBa78d5a0c24C58C740e3715ec29de1bFawhilst the Controller is configured to 0x9F8F33e0e22F747617654A50305e61AA9811070C, held by Aave Labs as contingency.\nVoting power. Voting weight is the combined balance of AAVE, stkAAVE, and aAAVE that an address holds or has been delegated, measured at the snapshot block taken when the vote opens. Holders can vote directly or delegate their power to a representative.\nTiming and threshold. Once submitted, a Snapshot enters a one-day voting delay, followed by a three-day voting period. A 320,000 AAVE threshold applies: if it is met, the proposal proceeds to the AIP stage; if not, the proposal fails.\nFor further detail, see the Aave governance documentation.\nOn-Chain\nOn-chain voting is required on any Aave Improvement Proposal. Aave on-chain voting will take place on the Aave Governance Portal. With the launch of V3 governance, it is now possible to vote across multiple chains and cast gasless votes.\nThe on-chain voting process is composed of four stages:\n\nFirst, the proposal and payload are reviewed by Security Service Providers to ensure they are not malicious and don’t contain errors that could put the protocol at risk.\nThe second stage is entered if no errors or a malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a 1-day voting delay must pass before it becomes active.\nIn the third stage, once the voting delay has elapsed, the proposal becomes active and available for voting. This stage lasts for 3 days.\nIn the fourth stage, once the voting period has ended, the proposal will be either SUCCEEDED or FAILED, depending on whether it has reached quorum and received a majority of YAE votes. In this stage, if the proposal has passed, the payload is queued with a 1-day timelock; once this has elapsed, the payload may be executed. If the proposal is not executed before the end of the 7-day grace period, it expires and must be deployed and voted on again at the start of the on-chain voting process.\n\nA visual representation of this flow is shown in the figure below.\nimage3576×1593 329 KB\nQuorum\nFor a proposal to succeed, at least 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote, and the winning option must receive at least 320,000 votes.\n\nQuorum-failure rule: a proposal that fails the Snapshot vote due to a lack of quorum, rather than due to a rejecting majority, may reopen the Snapshot once without restarting from the ARFC stage.\nAnti-spam brake: the proposition power and whitelist gate at Snapshot submission.\nFinal token-holder break: the on-chain AIP vote and the one-day timelock.\nMalicious-proposal backstop: the Governance Emergency Guardian retains its power to cancel.\n\nGovernance Frameworks\nThe Aave DAO has predefined frameworks for common types of proposals, simplifying the governance process:\nAsset Onboarding Framework\nStandardised lifecycle for onboarding new assets to the protocol, providing a structured process for risk assessments and community discussions.\nOnboarding the right assets is one of the most direct levers the DAO has for growth. Each new asset can deepen liquidity, expand borrowing demand and protocol revenue, extend GHO’s reach, and unlock integrations and user acquisition. The framework makes that growth deliberate: assets are prioritised by verifiable demand, credible commitments, and strategic fit with the wider Aave business, and are onboarded only once they meet the DAO’s risk and technical standards. The below outlines the asset onboarding and expansion process:\nimage4296×1620 358 KB\nNew Asset Listing\nThe New Asset listing framework uses the Standard Process to list assets on the Aave Protocol for the first time if they have not been listed previously. Introducing a new asset to the Aave Protocol increases the risk surface area and requires rigorous assessment to ensure there is a strong business case for onboarding it.\nOnboarding a new asset is expected to take 13 days following the Standard Process.\nThe Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.\nAsset Listing ARFC Process\nDuring the ARFC stage, a clear business case for onboarding the asset must be provided; the asset then undergoes Risk Analysis and a Technical Assessment to verify its suitability for listing on the Aave Protocol.\nimage4296×969 199 KB\n\nBusiness Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the listing proposal on the governance forum. It presents a clear, validated case for onboarding the asset, including the proposed initial market structure and parameters, and explains how the asset fits the DAO’s broader strategy. Where relevant, it sets out the commitments supporting the listing, such as expected user deposits and debt, incentive budget, liquidity, and planned integrations.\n\nRisk Analysis: The Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.\n\nRisk Assessment: A thorough review of the risks associated with the asset, covering market risk (volatility, liquidity, and secondary-market depth across market conditions), the asset’s historical performance and susceptibility to market fluctuations, and asset-specific legal and compliance considerations. For coinciding asset listings with product launches,\nReference: [ARFC] Aave Risk Framework\n\nAny material finding, such as insufficient DEX liquidity, pauses the listing until it is resolved.\n\nTechnical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the asset’s technical and security profile.\n\nTechnical Assessment: A rigorous review of the asset’s contracts, oracle configuration, access controls, and dependencies, against the requirements of the Technical Asset Listing Framework.\nReference: [ARFC] Technical Asset Listing Framework\n\nAny finding that falls short of Aave’s security standards pauses the listing process until the issue is resolved.\n\nExisting Asset Listing\nThe Existing Asset listing framework applies only to assets already listed on the Aave Protocol; identical assets (syrupAssets) shall follow the Direct-to-AIP process when extending assets to other instances of the Aave Protocol.\nAdding an Existing Asset to an instance of the Aave Protocol is expected to take as little as 5 days following the Direct-to-AIP process.\nThe Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.\nExisting Asset Direct-to-AIP Process\nSimilar to the New Asset Listing framework, each of the three requirements must be met before an AIP is published: Business Case, Risk Analysis and Technical Analysis. Upon completing sufficient due diligence and assessing the expected returns, an AIP shall be published.\nimage4296×969 206 KB\nSimilar to the Asset Listing ARFC process, the Direct-to-AIP shall present the business case for adding the asset to another instance of the Aave Protocol, ensuring a rationale for the listing. In the comments section, Risk and Technical Service Providers are to provide commentary on the proposed parameter configuration and highlight any concerns, including additional dependencies (e.g., bridges) and liquidity considerations.\nNew Network Deployment Framework\nDeploying on a new network extends Aave’s liquidity footprint and revenue base, carries GHO into new ecosystems, and positions the protocol where users, partners, and capital are moving. Because a deployment is a larger commitment than a single listing, the framework weighs the network’s liquidity potential, GHO utility, revenue and integration commitments, and partner distribution before the DAO commits.\nThe New Network Deployment Framework follows the Standard Process for determining whether to deploy a new Aave Protocol instance. This framework provides a transparent approach for evaluating and deploying new instances of the Aave Protocol. The initial ARFC publication focuses on the business case and overall strategy supporting the deployment.\nA single ARFC Snapshot authorises the deployment and can trigger up to three separate on-chain AIP votes. For a deployment with GHO these are: (1) a.DI Path Activation, which registers the Aave Delivery Infrastructure for the new network; (2) CCIP GHO Lanes Activation, which activates the GHO lane on Chainlink’s CCIP; and (3) the Aave Protocol Activation, which brings the market live. The a.DI and CCIP GHO Lanes votes are completed before the Protocol Activation AIP is published. A deployment without GHO omits the CCIP GHO Lanes vote, so only the a.DI Path Activation precedes the Protocol Activation.\nThe Aave DAO requires that at least $150 worth of each listed asset be deposited into the Aave Short Executor before the market goes live.\nimage4296×1329 285 KB\nNew Network Deployment ARFC Process\nFollowing the Standard Process, at the ARFC stage, a clear business case for deploying the Aave Protocol on the network is to be presented to the community. The ARFC publication shall also detail the initial assets to be listed and present a tentative market configuration for discussion.\nGiven the early stage of most networks at the time the Aave Protocol is deployed, some risk considerations, such as DEX liquidity assessments, are based on commitments to provide flexibility in the lead-up to launch.\nimage4296×969 199 KB\n\nBusiness Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the deployment proposal on the governance forum. It presents a clear, validated case for deploying the Aave Protocol on the network, together with the proposed initial market structure: the assets to be listed, their tentative parameters, and how the deployment fits the DAO’s broader strategy. Where relevant, it also sets out the commercial terms supporting the deployment, including the incentive budget, liquidity and integration commitments, GHO utility, and the availability of Chainlink Oracle and CCIP infrastructure.\n\nRisk Analysis: Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.\n\nRisk Assessment: A thorough review of the risks associated with the network and its initial assets, covering chain-level risk (network maturity, decentralisation, and reliability), market risk (asset volatility, liquidity, and secondary-market depth), and asset-specific legal and compliance considerations. Given the early stage of most networks at deployment, some assessments, such as DEX liquidity, may rely on commitments made ahead of launch.\nReference: [ARFC] Aave Risk Framework\n\nAny material finding pauses the deployment until it is resolved.\n\nTechnical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the network’s technical and security profile and that of each listed asset.\n\nTechnical Assessment: A rigorous review of the network’s technical and security details, the a.DI (Aave Delivery Infrastructure) integration, oracle and CCIP availability, and each asset’s contract and oracle configuration.\nReference: [ARFC] Technical Asset Listing Framework\n\nAny finding that falls short of Aave’s security standards pauses the deployment until it is resolved.\n\nimage3696×1440 318 KB\nDirect-to-AIP Framework\nThe purpose of the Direct-to-AIP framework is to enable non-controversial, precise parameter updates to the protocol to be implemented quickly. Within the Aave Protocol, there are a number of parameters or access that can be granted that are not currently supported by Steward roles. The Direct-to-AIP provides a means of quickly updating those parameters and of processing routine, non-controversial operational matters.\nimage4296×1611 300 KB\nGovernance Roles\nDelegates & Delegators\nDelegates\nDelegates are community members who have received voting power from other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have entrusted them with their voting power. Delegates are not compensated.\nDelegators\nDelegators are community members who hold Aave, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another person. The person to whom they delegate their voting power is considered a delegate. This system allows delegators to have their interests represented in governance decisions without having to participate directly in every vote.\nContributors and Service Providers\nContributors\nContributors are community members who participate in and dedicate their time to the Aave DAO. They contribute by joining working groups, fulfilling bounties, building on top of the Aave Protocol, or working for the DAO via grants. Contributors work towards completing shared goals that benefit the Aave ecosystem.\nService Providers\nService providers are specialised entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:\n\nLlamaRisk, risk service provider\nCertora, security service provider\nTokenLogic, finance and growth service provider\nAave Labs, development and growth service provider\n\nGuardians\nThe Aave Guardians safeguard the protocol and the integrity of its governance. They operate as two independent multisigs with distinct mandates: the Protocol Emergency Guardian, which can pause markets and act in a protocol emergency, and the Governance Emergency Guardian, which can cancel malicious or erroneous governance proposals. Across the DAO’s emergency and treasury SAFEs, individual signer identities are increasingly withheld and held within organisation-controlled nested SAFEs, a deliberate practice to reduce attack surface (see the June 2026 signer and SAFE configuration update).\nFor more information on the Guardians’ permissions, refer to this detailed view of permissions in Aave systems. For a general overview of their role, see the Medium post about Aave V2 Governance here.\nProtocol Emergency Guardian\nThis Guardian holds the EMERGENCY_ADMIN role in Aave V3 and equivalent roles in V2 and related systems. Its purpose is to act quickly in an emergency to protect the protocol, for example by pausing a market. Following the May 2026 signer rotation, it operates as a 4-of-7 multisig, and to reduce its attack surface, the signer identities are not publicly disclosed. The current signer addresses are listed below.\n\nProtocol Emergency Guardian (4-of-7)\nSigner address\n\nSigner 1\n0x4Ab2Bed1d667260dB34244Ba412817651C2dD52b\n\nSigner 2\n0xc2674C1A1aF0557E1d217fF4F13DF44A637c7C13\n\nSigner 3\n0xe6838d834674eC35EDd53D485770Baa10bdd6AAe\n\nSigner 4\n0xb291232F480F41c75802C4a60F1D2AC03404Afef\n\nSigner 5\n0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E\n\nSigner 6\n0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe58\n\nSigner 7\n0x3fa960f8355D00874D9C7E3350147f5E94859bc2\n\nGovernance Emergency Guardian\nThis Guardian is responsible for cancelling governance proposals if they are detected as malicious or contain errors, typically identified during the on-chain verification stage by Certora. Unlike the Protocol Emergency Guardian, speed is less critical for this role since governance proposals unfold over a period of five days, allowing adequate time for issues to be identified and addressed. The multi-sig configuration for this Guardian is also a 5-of-9 setup. The current Governance Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nGovernance Emergency Guardian\nAddress\n\nSeb (Zapper)\n0xa1c9ceed5ff78f700dc4930514621843b5fac272\n\nMounir (Paraswap)\n0xfd639f49Da6cadc98f01B60900C8BE30C38c4B27\n\nGavi Galloway (Standard Crypto)\n0xbd4DCfA978c6D0d342cE36809AfFFa49d4B7f1F7\n\nNenad (Defi Saver)\n0xDA5Ae43e179987a66B9831F92223567e1F38BE7D\n\nFernando (Balancer)\n0x4C30E33758216aD0d676419c21CB8D014C68099f\n\nRoger (Chainlink community)\n0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396\n\nMariano Conti (DeFi OG)\n0x936CD9654271083cCF93A975919Da0aB3Bc99EF3\n\nMarin (Lido)\n0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nTemplates\nThe standard ARFC templates are collected here for reference. When drafting a proposal, copy the relevant template and adapt it to the specific asset, network, or change.\n\nAsset Listing ARFC Template\n\nTitle: [ARFC] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD\n\nSummary\nThis ARFC proposes onboarding to the Aave instance on the .\nMotivation\nExplain the motivation for listing the Token.\n\nBusiness Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.\n\nA general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.\n\nAt the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in an unapproved or unsanctioned category should not proceed.\nReference: [ARFC] Endorse the Asset Classification Framework (AAcA)\nThe initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.\n\nSpecification\nTicker:\nContract address:\nChainlink oracle:\n\nParameter\nv3\nv4\nValue\n\nNetwork\nYes\nYes\n\nInstance of Aave Protocol\nYes\nYes\n\nHub (Core / Prime / Plus)\nn/a\nYes\n\nSpoke / Spoke type\nn/a\nYes\n\nIsolation Mode\nYes\nn/a\n\nDebt Ceiling\nYes\nn/a\n\nSiloed Borrowing\nYes\nn/a\n\nBorrowable in Isolation\nYes\nn/a\n\nBorrowable\nYes\nYes\n\nCollateral enabled / Collateral-only\nYes\nYes\n\nSupply Cap (v3) / Add Cap (v4)\nYes\nYes\n\nBorrow Cap (v3) / Draw Cap (v4)\nYes\nYes\n\nCredit Line Size / Draw Cap\nn/a\nYes\n\nLTV\nYes\nn/a\n\nLiquidation Threshold (LT)\nYes\nn/a\n\nCollateral Factor (CF)\nn/a\nYes\n\nLiquidation Bonus\nYes\nn/a\n\nMax Liquidation Bonus\nn/a\nYes\n\nLiquidation Bonus Factor\nn/a\nYes\n\nHealth Factor for Max Bonus\nn/a\nYes\n\nLiquidation Protocol Fee\nYes\nYes\n\nCollateral Risk (bps)\nn/a\nYes\n\nVariable Base\nYes\nYes\n\nSlope 1\nYes\nYes\n\nSlope 2\nYes\nYes\n\nUoptimal\nYes\nYes\n\nReserve Factor (v3) / Liquidity Fee (v4)\nYes\nYes\n\nOracle Type (Chainlink SVR / CAPO / Pendle)\nYes\nYes\n\nCAPO: Max Yearly Ratio Growth %\nYes\nYes\n\nCAPO: Minimum Snapshot Delay\nYes\nYes\n\nPrice Cap (stablecoin / CAPO)\nYes\nYes\n\nPendle: Discount Rate / Max per year\nYes\nYes\n\nFlashloanable\nYes\nYes\n\nE-Mode Category (v3) / E-Mode Spoke (v4)\nYes\nYes\n\nDisclaimer\nStatement of the author’s potential conflict of interest and relationship with the asset protocol, and if they received compensation for publishing this proposal\nNext Steps\n\nIf consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.\nIf the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal\n\nCopyright\nCopyright and related rights waived via CC0.\n\nAsset Listing Direct-to-AIP Template\n\nTitle: [Direct-to-AIP] Template\nAuthor:\nDate: 2026-06-06\n\nSummary\nA brief sentence or two introducing the proposal’s topic. Specifically, the parameters to be updated, which instance of the Aave Protocol and which chains are affected.\nMotivation\nThis section outlines the reasoning, often supported by a business case and supporting analysis, allowing voters to make an informed decision at the time of the vote.\nWhere applicable, include:\n\nThe problem or opportunity being addressed.\nThe rationale for the proposed changes.\nSupporting analysis, research, or market data.\nExpected impact on protocol performance, capital efficiency, risk, or user experience.\nAny relevant business, technical, or governance considerations.\n\nThis section should focus on why the proposal should be implemented, while the Specification section describes how it will be implemented.\nFor assets extended to other instances of the Aave Protocol, as with the original ARFC to list the asset, this section shall include the Business Case supporting the listing. Please see the earlier section for further details.\nSpecification\nA summary of the technical changes to be implemented at the AIP stage.\nThis section should include all information necessary to construct the governance payload, including, where applicable:\n\nMarkets and networks affected.\nAssets affected.\nCurrent values.\nProposed values.\nSmart contracts or protocol components impacted.\nAny implementation or execution considerations.\n\nDisclaimer\nThe author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this Direct-to-AIP proposal.\nNext Steps\n\nPublish an AIP vote for final confirmation and on-chain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\nExisting Asset Listing Direct-to-AIP Template\n\nTitle: [Direct-to-AIP] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD\n\nSummary\nThis Direct-to-AIP proposes onboarding to the Aave instance on the .\nMotivation\nExplain the motivation for onboarding this asset to another instance of the Aave Protocol.\n\nBusiness Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.\n\nA general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.\n\nThe initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.\nReference: [ARFC] Endorse the Asset Classification Framework (AAcA)\n\nSpecification\nTicker:\nContract address:\nChainlink oracle:\n\nParameter\nv3\nv4\nValue\n\nNetwork\nYes\nYes\n\nInstance of Aave Protocol\nYes\nYes\n\nHub (Core / Prime / Plus)\nn/a\nYes\n\nSpoke / Spoke type\nn/a\nYes\n\nIsolation Mode\nYes\nn/a\n\nDebt Ceiling\nYes\nn/a\n\nSiloed Borrowing\nYes\nn/a\n\nBorrowable in Isolation\nYes\nn/a\n\nBorrowable\nYes\nYes\n\nCollateral enabled / Collateral-only\nYes\nYes\n\nSupply Cap (v3) / Add Cap (v4)\nYes\nYes\n\nBorrow Cap (v3) / Draw Cap (v4)\nYes\nYes\n\nCredit Line Size / Draw Cap\nn/a\nYes\n\nLTV\nYes\nn/a\n\nLiquidation Threshold (LT)\nYes\nn/a\n\nCollateral Factor (CF)\nn/a\nYes\n\nLiquidation Bonus\nYes\nn/a\n\nMax Liquidation Bonus\nn/a\nYes\n\nLiquidation Bonus Factor\nn/a\nYes\n\nHealth Factor for Max Bonus\nn/a\nYes\n\nLiquidation Protocol Fee\nYes\nYes\n\nCollateral Risk (bps)\nn/a\nYes\n\nVariable Base\nYes\nYes\n\nSlope 1\nYes\nYes\n\nSlope 2\nYes\nYes\n\nUoptimal\nYes\nYes\n\nReserve Factor (v3) / Liquidity Fee (v4)\nYes\nYes\n\nOracle Type (Chainlink SVR / CAPO / Pendle)\nYes\nYes\n\nCAPO: Max Yearly Ratio Growth %\nYes\nYes\n\nCAPO: Minimum Snapshot Delay\nYes\nYes\n\nPrice Cap (stablecoin / CAPO)\nYes\nYes\n\nPendle: Discount Rate / Max per year\nYes\nYes\n\nFlashloanable\nYes\nYes\n\nE-Mode Category (v3) / E-Mode Spoke (v4)\nYes\nYes\n\nDisclaimer\nThe author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this ARFC.\nNext Steps\n\nPublish an AIP vote for final confirmation and on-chain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\nNew Network Deployment ARFC Template\n\nTitle: [ARFC] Deploy Aave on \nAuthor:\nDate: YYYY-MM-DD\n\nSummary\nThis ARFC proposes deploying the Aave Protocol to the .\nMotivation\nProvide a comprehensive overview of the new deployment, including its technical features, security measures, and any unique benefits it brings to the Aave ecosystem. This section will focus on the following key areas:\n\nNetwork Capabilities: Transactions per second, latency, finality, scalability, security and interoperability.\n\nMarket Positioning: Details what makes this network unique from technical, user distribution, focus areas, and/or strategic alignment perspectives, with the goal of distinguishing this network from others.\n\nBusiness Case: This details the core value proposition for deploying the Aave Protocol on the respective network. The business case will take into consideration the effects of future liquidity, user adoption, market growth, strategic positioning and revenue potential, with a clear vision for the market over time.\nThe following presents a non-exhaustive list of key areas for consideration when compiling the business case:\n\nIncentive Budget.\nLiquidity commitments.\nGHO utility beyond the Aave Protocol.\nRevenue commitment.\nIntegration commitments.\nPartner’s distribution potential.\nAvailability of Chainlink’s Oracle and CCIP capabilities.\n\nTo support Tokenholders making a fully informed decision, the commercial terms supporting the deployment are to be clearly communicated while respecting any non-public information limitations.\n\nUseful Links: Any additional information that can help Aave DAO to decide. This may include recent announcements, links to documentation, a roadmap for network and ecosystem development, and plans.\n\nSpecification\nThis section contains the initial market structure, assets to be included and how the protocol is to be configured. The initial proposed parameters for the deployment should take into account any Unique Selling Points and desired go-to-market strategies, and be configured/positioned to attract users under prevailing market conditions.\n\nParameter\nAsset 1\nAsset 2\nAsset 3\n\nAsset\nwstETH\nWETH\nUSDT0\n\nBorrowable\n\nCollateral Enabled\n\nSupply Cap\n\nBorrow Cap\n\nDebt Ceiling\n\nLTV\n\nLT\n\nLiquidation Bonus\n\nLiquidation Protocol Fee\n\nVariable Base\n\nVariable Slope1\n\nVariable Slope2\n\nUoptimal\n\nReserve Factor\n\nStable Borrowing\n\nFlashloanable\n\nSiloed Borrowing\n\nBorrowable in Isolation\n\nE-Mode\n1\n1\n\nE-Mode Configurations\nwstETH Correlated #1\n\nParameter\nValue\nValue\n\nAsset\nwstETH\nWETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nMax LTV\n94.00%\n-\n\nLiquidation Threshold\n96.00%\n-\n\nLiquidation Bonus\n1.00%\n-\n\nCAPO\n\nAsset\nmaxYearlyRatioGrowthPercent\nratioReferenceTime\nMINIMUM_SNAPSHOT_DELAY\n\nwstETH\n9.68%\nMonthly\n7\n\nDisclaimer\nA statement of the author’s potential conflicts of interest, their relationship with the network or asset issuers, and whether they received compensation for publishing this proposal.\nNext Steps\n\nCommunity Engagement: Engage with the Aave community to gather feedback on the proposed framework for the new Aave Protocol deployment.\nARFC Snapshot: If community sentiment is favourable, initiate an ARFC snapshot to gauge official support for the framework.\nImplementation: If the Snapshot vote passes, the proposal as outlined shall be implemented by the respective Service Providers.\n\nCopyright\nCopyright and related rights waived under CC0.\n\nReferences\nAave Governance Process Document v1\n[ARFC] Aave Governance. Adjust Level 2 requirements (long-executor)\n[ARFC] Update the Asset Onboarding Framework\n[ARFC Addendum] Update Asset Onboarding Framework\n[ARFC] Technical Asset Listing Framework\n[ARFC] Direct-to-AIP Framework\n[ARFC] New Chain Deployment Framework\n[ARFC ADDENDUM] Mandatory Disclosures and Conflict-of-Interest Voting Norms\n[ARFC] Aave Risk Framework\n[ARFC] Emission Manager Framework Update\n[ARFC] Aave V3 Caps update Framework\nDisclosure\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is YAE, this proposal will be implemented.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n Update on Aave Horizon Asset Onboarding Process\n\n [ARFC] GHO Stewards Signer Update\n\n read \n\n 16\n min\n\n Pinned on Jul 20\n\n 17 days later\n\n post by Abel189 on Aug 7\n\n Abel189\n\n Thank you for the proposal.\nI support the objective of simplifying and consolidating the governance framework into a single reference document. As the DAO grows, having one canonical process should make governance easier to understand for both existing delegates and new participants.\nOne suggestion would be to periodically review the impact of these governance changes after implementation. In particular, it would be useful to monitor whether removing the mandatory TEMP CHECK affects proposal quality, community participation, delegate engagement, or the number of proposals requiring significant revisions during the ARFC stage. Publishing this information after several months would allow governance to evaluate whether the streamlined process is achieving its intended goals while preserving meaningful community review.\n\n post by Millesimillia on Aug 9\n\n Millesimillia\n\n Dear all,\nThank you for the proposal. I think it makes sense to review and improve governance processes every now and then. Simple question from me:\nWho can propose ARFCs for governance topics in the future?\nI read that in some cases (e.g., new listing) this must be done by official service providers. I hope this is not the case for all AFRCs.\nReason: I am an investor and looking forward to hearing more about how Aave token economics will effectively be kept strong or strengthened - especially vis-a-vis service providers who might also have more hidden incentives such as their own stock or revenues allocations.\nPotential future governance topics could include investment decisions, buybacks, provider selection criterias, service provider reviews, etc..\nKnowing that all topics can be brought forward and will be addressed on governance discussions would give me comfort/trust and be in the interests of Aave token holders.\nThanks for your thoughts and comments.\nWarm regards, Millesimillia\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Technical Asset Listing Framework\n\n General\n\n 7\n\n 1.5k\n\n Jul 17\n\n Aave Governance Process Document v1\n\n Governance\n\n 3\n\n 5.3k\n\n Sep 2024\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14","tokens":12098,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260480033,"hash":"11245a65e422b2176546c62802fea2d6dc1749cc"}
{"url":"https://ethereum.org/what-is-ethereum/","domain":"ethereum.org","title":"What is Ethereum? (A Complete Guide) | ⁦ethereum.org⁩","text":"Ethereum is an open, public blockchain launched in July 2015 by a software developer called Vitalik Buterin and a small team of co-founders.The idea behind Ethereum was simple. While Bitcoin lets you send and receive digital cash, Ethereum would build on this with open-source programs called smart contracts.Smart contracts let anyone create their own digital assets and decentralized applications (dapps) that run 24/7, globally. And unlike banks, corporations or other institutions, smart contracts are available to anyone with an internet connection.Since 2015, Ethereum has grown into a thriving ecosystem of digital assets like stablecoins, non-fungible tokens (NFTs), and governance tokens, as well as a sprawling world of dapps for decentralized finance (DeFi), art and collectibles, gaming and decentralized social media.Collectively, this ecosystem is called \"web3\", representing the third phase of the internet centered around ownership.Today, Ethereum is used by millions of people (opens in a new tab) around the world holding billions of dollars (opens in a new tab) in assets who send and receive trillions of dollars (opens in a new tab) every year—all without a bank.At the heart of all this is Ethereum's native cryptocurrency ether (ETH), a new kind of digital money used to power the whole network.What is the Ethereum network?You can think of the ethereum network as a global digital infrastructure that anyone can use but nobody can abuse.The network is made up of thousands of independent computers around the world called nodes. These nodes, run by regular people, work together to provide financial services and digital applications to anyone, anywhere.The Ethereum network has 3 key advantages over traditional networks owned by institutions. These are censorship resistance, enhanced security and improved reliability.Censorship resistantWhile traditional apps and financial services rely on banks or corporations that can decide to block access or freeze accounts, dapps on Ethereum are censorship resistant.This is because ethereum's network of nodes record every single transaction without discrimination—and this rule is embedded in the code.Highly secureWhile many apps today are hosted on cloud providers like AWS and can be vulnerable to takedowns and attacks, dapps on Ethereum are secured by the network itself. Every node stores and syncs the entire state of Ethereum, including all contracts.If someone tried to change a contract, the network would reject it since it wouldn't match their records. To take down a single app, attackers need to take over the entire network, which would cost billions and be extremely hard to coordinate.Durable and reliableDowntime on cloud hosting platforms can take apps offline, but Ethereum's design ensures perfect uptime. The network will keep running even if some nodes go offline due to software bugs, government crackdowns, natural disaster, or war.Millions of people use thousands of dapps on Ethereum every day. While high demand can lead to elevated transaction fees, it reflects the strength of a network that prioritizes security, decentralization, and the guarantee that it's always available when you need it.Ethereum extensions (Layer 2)Different teams have created Layer 2 (L2) networks that run on top of Ethereum to increase Ethereum's capacity. L2s act like express lanes, making transactions faster and cheaper—sometimes costing less than a cent on average.Some of the most popular L2s including Optimism (opens in a new tab), Arbitrum (opens in a new tab), ZKSync (opens in a new tab), and Base (opens in a new tab) now process millions of transactions worth billions of dollars each year.Learn more about the Ethereum network What is ether (ETH)?Ether (ETH) is the native cryptocurrency of Ethereum.It's a new kind of digital money you can send to anyone, anywhere in the world in seconds for as little as a few cents. But ETH is about more than just payments. It plays a vital role in keeping the Ethereum network running.When you use Ethereum to send money, collect art or build a new dapp, you pay a small transaction fee (or gas fee) in ETH. This fee helps prevent spam and rewards the people called validators who process transactions.These validators help secure the ethereum network through a system called staking. By locking up their ETH they're eligible to process transactions. In return, they earn ETH as a reward. This gives Ethereum its own self-sustaining economy, powered by users rather than companies.Unlike many traditional currencies, ETH can become more scarce over time. Every time someone uses Ethereum, a small portion of ETH is burned, which permanently removes it from the supply. On busy days, more ETH is burned than created, making ETH deflationary and increasing its value over time. The more Ethereum is used, the more ETH is burned.Because of this, many people see ETH as an investment and choose to hold, stake or lend it to grow their savings.Learn more about ether (ETH) How does Ethereum work?When Ethereum launched in 2015, it used a system called proof of work.This mechanism, pioneered by Bitcoin, is how all computers agreed on who owns what. Computers would use a lot of energy trying to solve a complex mathematical puzzle. The winner would get to propose a block of incoming transactions and earn new ETH.In 2022, Ethereum upgraded to a new system called proof of stake that's 99% more energy efficient. Instead of mathematical puzzles, validators lock their ETH as a security deposit to earn the right to process transactions.If they do it correctly, they earn ETH. If they cheat, they lose some of their stake.Here's an example:When you send $10 in stablecoins to a friend on Ethereum:You open your wallet, add the account address to send to and the amount, then click send.Your wallet signs the payment and broadcasts it to the network.The payment waits in the public queue (mempool) until a block proposer picks it.The block proposer adds it to the next block of transactions, broadcasts it, and earns a fee.The stablecoin contract moves $10 from you to your friend, and both wallets update.A global network of validators double-check and attest to the validity of the changes.When you mint a $5 collectible on Ethereum:You connect your wallet to the dapp and choose the item to mint.You confirm the purchase; the wallet signs and broadcasts the transaction.The mint request joins the mempool and is added to a block by a validator.The NFT smart contract records your wallet as the new owner.Your new collectible appears in your wallet a few seconds later.This is all possible thanks to the power of smart contracts; open-source programs that live on Ethereum and run 24/7, 365 accessible to anyone, anywhere.Every transaction, update, and action is synced across thousands of independent nodes. This gives Ethereum its reliability, transparency, and censorship resistance.Learn more about how Ethereum works Read developer docs for a technical overview of Ethereum What is Ethereum used for?People use Ethereum to do things that weren't possible before.Farmers in Kenya can receive automated insurance on their crops (opens in a new tab) without applying to a bank. Businesses like Visa can launch new payment systems that works globally (opens in a new tab) from day one. Global organizations like the UN can deliver aid to refugees (opens in a new tab) saving millions in bank fees.These dapps and assets run on Ethereum using open-source code and can't be restricted, censored or turned off.Here's how different groups are using it today:ConsumersMillions of people already use dapps on Ethereum to move money, trade, and own digital assets every day. Unlike traditional apps, there's no need to register with your name, wait for a bank to approve you, or hand over your personal data.With just a wallet and an internet connection you can:Access financial services without a bank account or credit historyOwn digital collectibles, art, and assets that can't be copied or confiscatedSign into dapps using your wallet, not your email—no passwords, no personal information necessaryParticipate in global communities where you can vote, contribute, and earn borderlesslyBusinesses & developersLaunch dapps with built-in global payments system from day oneDeploy tamper-proof contracts that automatically enforce agreementsCreate financial products that anyone can build on and drive value toFor example, PayPal launched its own stablecoin, PYUSD, on Ethereum (opens in a new tab). This is a sign that even the world's largest payments companies see the benefit of Ethereum's open and programmable nature.GovernmentsGovernments are also starting to explore what Ethereum makes possible.Distribute public funds and benefits directly to citizens with full transparencyIssue digital IDs or records that are verifiable and portable across bordersBuild tamper-proof public infrastructure for voting, land titles, and registriesIn another case, Ukraine's Ministry of Digital Transformation used Ethereum to distribute wartime aid (opens in a new tab).Funds were sent directly to citizens and NGOs using open smart contracts, providing transparency, speed, and accountability during a crisis.How to start using EthereumGetting started with Ethereum is easier than you might think.You don't need permission. You don't need a bank or even an ID document. All you need to get started is a device and an internet connection.For individualsThe first step is downloading a wallet.Popular wallets like Zerion (opens in a new tab), Rainbow (opens in a new tab), and Coinbase Wallet (opens in a new tab) are free and easy to use. Once your wallet is set up, you can:Buy a small amount of ETH on an exchange or directly inside some walletsUse that ETH to pay for transactions like sending tokens or collecting NFTsExplore dapps like Zora (opens in a new tab), Uniswap (opens in a new tab), or Farcaster (opens in a new tab)—no new logins or approvals neededThese priorities will help ensure Ethereum is secure, scalable and user friendly as more people rely on the network everyday.These dapps run in your browser and work with your wallet instantly. You can start using Ethereum in minutes.Start hereSee appsFor developersEthereum is a playground for developers. You can start building without permission, approvals, or even real money.The Ethereum Developer Docs walk you through everything from writing your first smart contract to deploying on test networks like Sepolia.You can build full-stack dapps with tools like Hardhat (opens in a new tab), Foundry (opens in a new tab), and Ethers.js (opens in a new tab), or experiment with low-code platforms like thirdweb (opens in a new tab) or Moralis (opens in a new tab).Everything is open-source and composable, so you can remix and build on what's already out there without asking for permission.Start building on EthereumUse Ethereum in businessEnterprises are already using Ethereum to power new infrastructure.Many enterprises are starting with L2 networks like Optimism and Base to support high-volume use cases. These networks offer lower fees, faster speeds while still benefiting from Ethereum's security and removing counterparty risk.You can:Launch modular loyalty programs that boost retention and cut third-party costsTokenize assets like tickets, coupons, or certificates to reduce fraud and resale riskEnable instant global payments to lower transaction fees and unlock new marketsFor example, in 2025, Shopify launched on Base (opens in a new tab) to allow consumers to spend stablecoins with millions of merchants around the globe.Use Ethereum in business (opens in a new tab)What's the difference between Ethereum and Bitcoin?Bitcoin and Ethereum are the two biggest cryptocurrencies in the world.They both let you send money without a bank, both run on blockchain technology, and both are open to anyone. But that's where the similarities end.Bitcoin is like digital gold.It has a fixed supply of 21 million coins, a narrow focus on peer-to-peer payments, and a basic scripting language that limits what you can build with it. This simplicity is by design since Bitcoin prioritizes predictability, durability, and long-term security over flexibility.Ethereum takes a broader approach.It's not just money, it's programmable infrastructure. Instead of just sending and receiving value, Ethereum lets developers build entire applications. You've already seen this in action: from lending markets and stablecoins to collectibles, social media, and real-time payments—all powered by smart contracts and secured by ETH.The way the networks reach consensus is also different.Bitcoin uses miners to secure the network. These are powerful computers that compete to solve complex puzzle, and the winner gets to add the next block of transactions to the chain and claim bitcoins as a reward. This process is called mining and it uses large amounts of electricity.Ethereum used to work like this too. But in 2022, it transitioned from proof of work to proof of stake. Today, transactions are confirmed by validators who lock up ETH as collateral. Honest validators earn ETH rewards while any dishonest ones lose part of their stake. This shift made Ethereum over 99.988% more energy efficient without sacrificing security or decentralization.There's also a difference in how supply is handled.Bitcoin has a fixed supply. There will only ever be 21 million coins. Ethereum, on the other hand, has a dynamic supply. New ETH is issued to reward validators, while a portion is burned with every transaction. This means Ethereum can't just \"print infinite ETH.\"The issuance rate is limited by how much ETH is staked. As more ETH is staked, individual rewards decrease, creating a natural balance. This design ensures a sustainable security budget well into the future, without relying solely on transaction fees.In short, Bitcoin is a tool for sending value. Ethereum is a platform for building it.Learn more about the difference between Ethereum and Bitcoin When did Ethereum launch, who founded it and who runs it now?From the start, Ethereum was designed to run by its community.In 2013, Vitalik Buterin published a white paper proposing a new kind of blockchain for money and apps anyone could use. The idea quickly gained traction.By 2014, co-founders like Gavin Wood and Joseph Lubin joined the effort, and the team raised funds through one of the earliest crypto crowdfunding campaigns.Ethereum officially launched in July 2015.Key moments in Ethereum's history2013: 19-year-old Vitalik Buterin publishes the Ethereum whitepaper2014: The Ethereum Foundation forms and launches a crowdfunding campaign2015: Developers launch the Ethereum network with the Frontier release2016: Smart contract exploit drains $60M (3.6M ETH) from The DAO prompting a chain fork 2020: Beacon Chain launch starts the move to Proof-of-Stake 2021: London upgrade starts burning gas fees via EIP-1559 2022: The Merge replaces mining with staking, cutting energy use by 99% 2025: Pectra upgrade improves smart wallet support and L2 compatibility Today, no single person or company runs Ethereum.The network is maintained by a broad group of contributors:Developers who write and propose upgradesNode operators contributing to distributed physical infrastructureStakers who validate transactionsCommunity members who build the tools and cultureYou by using the networkThere's no CEO, board, or central authority. The Ethereum Foundation still helps fund research and development, but the ecosystem runs on open participation.Changes are proposed through Ethereum Improvement Proposals (EIPs) (opens in a new tab), discussed publicly, and only adopted if the wider community supports them.This makes Ethereum slower to change than a startup, but also much harder to shut down or take over.Learn more about Ethereum's history What is the Ethereum roadmap for 2026?Ethereum doesn't follow a fixed roadmap. It follows a shared vision.Network upgrades are made as EIPs and developed in public by contributors around the world. There's no central team deciding what happens, just people building what they believe is useful based on users' needs. Fusaka is the most recent upgrade, launched in December 2025. It introduced PeerDAS for more efficient L2 data availability and raised the default gas limit to ~60M. Looking ahead to 2026, Glamsterdam is in development and expected in Q4 2026.Looking ahead (opens in a new tab), Ethereum's priorities include:Making the core protocol and its L2s faster and cheaper for everyoneImproving the experience for users and developersThese priorities will help ensure Ethereum is secure, scalable and user friendly as more people rely on the network everyday.If you want to steer the direction for Ethereum, get involved. You don't need permission, just the desire to make a difference in this new digital economy.See an overview of the Ethereum roadmap Read nextWhat are wallets?What is ether (ETH)?What is web3?Learn more about the Ethereum networkTest your Ethereum knowledgeWhat is Ethereum?Question number 1:How does Ethereum keep running without downtime?","tokens":4288,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260486999,"hash":"cf1735eb9e9b79c440e54a3d4d27c9964c389296"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-upgrades-new-instance-in-a-contract/17738/6","domain":"forum.openzeppelin.com","title":"Openzeppelin upgrades - new instance in a contract - Support / Upgrades - OpenZeppelin Forum","text":"SupportUpgrades\n\n proxies\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Oct 2021\n\n 5 / 5\n\n Nov 2021\n\n Nov 2021\n\n post by novaknole on Oct 28, 2021\n\n novaknole\n\n Hi Team,\nI am writing new smart contracts and need to follow upgradability principles.\nI got a factory contract that should create 3-4 contracts inside it.\ncontract Factory {\n\n function create() public {\n Contract1 c1 = new Contract1();\n Contract2 c2 = new Contract2();\n Contract3 c3 = new Contract3(); \n }\n\n}\n\nNow, openzeppelin upgrade docs mention that I shouldn't be creating new instances inside smart contract and what I should be doing instead is passing the addresses to the create function above of already deployed contracts. In my case, that's a big problem, because this is a factory contract and it's the one that should be deploying new instances. It's a bad idea and I can't do to deploy contract1, contract2, contract3 separatelly, because I just showed an easy scenario and my case is a little bit complex. Here is where i read in the docs. https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable\nThanks a lot in advance for any help...\n\n ERC20Votes for upgradability doesn't exist\n\n 3\n\n 2\n\n post by novaknole on Oct 29, 2021\n\n novaknole\n\n The only way I can think of in this case is to use TransparentUpgradeableProxy and the below code would go in the factory function. WDYT ?\nTransparentUpgradeableProxy voting = new TransparentUpgradeableProxy(voting, msg.sender, abi.encodeWithSelector(Voting.initialize.selector, votingSettings));\n\n post by frangio on Nov 3, 2021\n\n frangio\n\n OpenZeppelin Team\n\n I'm missing some context here. Do you want your factory to be upgradeable? Do you want contracts 1, 2, and 3 to be upgradeable?\n\n post by novaknole on Nov 3, 2021\n\n novaknole\n\n @frangio\nCase 1.\nMainly, I want contract1, contract2, contract3 to be upgradable. Using openzeppelin upgrades plugin, I don't see the way how it can be achieved if I got a factory contract that deploys those 1,2,3 contracts. so my way of above seems really easy for me to understand. WDYT ?\nCase 2.\nWhat if I want my factory to be upgradable as well alongside those 1,2,3 contracts ? I guess, for factory, I'd use openzeppelin upgrades plugin with deployProxy and in the factory contract's function, I'd still have TransparentUpgradeableProxy voting = new TransparentUpgradeableProxy(voting, msg.sender, abi.encodeWithSelector(Voting.initialize.selector, votingSettings)); the following. What do you think ?\nThanks a lot.\n\n post by frangio on Nov 3, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Yes, that sounds exactly right!\nCheck out this thread, there are some factory code samples:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How can I create a factory of Upgradeable smart contracts?\n\n Upgrades\n\n erc20,erc721,upgrades\n\n 3\n\n 1.4k\n\n Apr 2022\n\n How to upgrade a contract deployed from a factory contract?\n\n SDK\n\n proxies\n\n 12\n\n 2.9k\n\n Jul 2020\n\n Deploy an upgradable contract from an upgradable factory\n\n Upgrades\n\n 4\n\n 467\n\n Apr 2023\n\n Creating upgradeable contracts from Solidity, is it mandatory to use App.sol?\n\n SDK\n\n 3\n\n 2.7k\n\n Aug 2020\n\n How to upgrade contracts that was created via a factory contract without any CLI?\n\n SDK\n\n 8\n\n 2.2k\n\n Jul 2020","tokens":829,"squid":"ink-security_audits","role":"Sentinel","at":1791260494148,"hash":"ddebc5a0ba53dccdd5dd671b6a8cd0aeb242c63e"}
{"url":"https://ethereum.org/developers/docs/ethereum-stack/","domain":"ethereum.org","title":"Introduction to the Ethereum stack | ethereum.org","text":"Introduction to the Ethereum stackEdit page (opens in a new tab)Like any software stack, the complete \"Ethereum stack\" will vary from project to project depending on your goals.\nThere are, however, core components of Ethereum that help provide a mental model for how software applications interact with the Ethereum blockchain. Understanding the layers of the stack will help you understand the different ways that Ethereum can be integrated into software projects.\nLevel 1: Ethereum Virtual Machine\nThe Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts on Ethereum. All smart contracts and state changes on the Ethereum blockchain are executed by transactions. The EVM handles all of the transaction processing on the Ethereum network.\nAs with any virtual machine, the EVM creates a level of abstraction between the executing code and the executing machine (an Ethereum node). Currently, the EVM is running on thousands of nodes distributed across the world.\nUnder the hood, the EVM uses a set of opcode instructions to execute specific tasks. These (140 unique) opcodes allow the EVM to be Turing-complete (opens in a new tab), which means the EVM is able to compute just about anything, given enough resources.\nAs a dapp developer, you don't need to know much about the EVM other than it exists and that it reliably powers all applications on Ethereum without downtime.\nLevel 2: Smart contracts\nSmart contracts are the executable programs that run on the Ethereum blockchain.\nSmart contracts are written using specific programming languages that compile to EVM bytecode (low-level machine instructions called opcodes).\nNot only do smart contracts serve as open source libraries, they are essentially open API services that are always running and can't be taken down. Smart contracts provide public functions which users and applications (dapps) may interact with, without needing permission. Any application may integrate with deployed smart contracts to compose functionality, such as adding data feeds or to support token swaps. Additionally, anyone can deploy new smart contracts to Ethereum in order to add custom functionality to meet their application's needs.\nAs a dapp developer, you'll need to write smart contracts only if you want to add custom functionality on the Ethereum blockchain. You may find you can achieve most or all of your project's needs by merely integrating with existing smart contracts, for instance if you want to support payments in stablecoins or enable decentralized exchange of tokens.\nLevel 3: Ethereum nodes\nIn order for an application to interact with the Ethereum blockchain, it must connect to an Ethereum node. Connecting to a node allows you to read blockchain data and/or send transactions to the network.\nEthereum nodes are computers running software - an Ethereum client. A client is an implementation of Ethereum that verifies all transactions in each block, keeping the network secure and the data accurate. Ethereum nodes are the Ethereum blockchain. They collectively store the state of the Ethereum blockchain and reach consensus on transactions to mutate the blockchain state.\nBy connecting your application to an Ethereum node (via the JSON-RPC API), your application is able to read data from the blockchain (such as user account balances) as well as broadcast new transactions to the network (such as transferring ETH between user accounts or executing functions of smart contracts).\nLevel 4: Ethereum client APIs\nMany convenience libraries (built and maintained by Ethereum's open source community) allow your applications to connect to and communicate with the Ethereum blockchain.\nIf your user-facing application is a web app, you may choose to npm install a JavaScript API directly in your frontend. Or perhaps you'll choose to implement this functionality server-side, using a Python or Java API.\nWhile these APIs are not a necessary piece of the stack, they abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g., converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the functionality specific to your application.\nLevel 5: End-user applications\nAt the top level of the stack are user-facing applications. These are the standard applications you regularly use and build today: primarily web and mobile apps.\nThe way you develop these user interfaces remains essentially unchanged. Often users will not need to know the application they're using is built using a blockchain.\nReady to choose your stack?\nCheck out our guide to set up a local development environment for your Ethereum application.\nFurther reading\n\nThe Architecture of a Web 3.0 application (opens in a new tab) - Preethi Kasireddy\n\nKnow of a community resource that helped you? Edit this page and add it!","tokens":1229,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260497051,"hash":"faa4e5229af4bd48e795632e1dc3b59a7662b5ac"}
{"url":"https://dev-forum.pyth.network/t/welcome-to-the-announcements-category/12","domain":"dev-forum.pyth.network","title":"Welcome to the Announcements category - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Welcome to the Announcements category \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 1 / 2\n\n Mar 2025\n\n Mar 2025\n\n post by Aditya520 on Mar 27, 2025\n\n Aditya520\n\n Official updates related to Pyth, Pyth products and more!\nHere you’ll find:\n\n Network and protocol updates\n\n Product releases and feature announcements\n\n Developer tool upgrades and ecosystem integrations\n\nOnly Pyth team members can post here, but all community members are encouraged to follow this category to stay in the loop.\nWant to stay in the loop? Hit that at the right and set it to “Watching.”\n\n Closed on Mar 31, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to Pyth Developer Forum! \n\n General\n\n 0\n\n 578\n\n Mar 2025\n\n About the Forum Feedback category\n\n Forum Feedback\n\n 0\n\n 449\n\n Apr 2025\n\n Upcoming Changes to Pyth Sponsored Feeds – Effective August 31, 2025\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 644\n\n Sep 2025\n\n About the Incidents category\n\n Incidents\n\n 0\n\n 439\n\n May 2025\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n Powered by Discourse","tokens":1172,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260504367,"hash":"faffd435b662529a4364e2cfe8df205dceac3bc0"}
{"url":"https://iptf.ethereum.org/","domain":"iptf.ethereum.org","title":"EthSystems · Confidential Systems for Institutional Ethereum","text":"Confidential Systems for Institutional Ethereum EthSystems helps institutions move on-chain with privacy that's performant, secure, usable, and accessible, disclosing only what the rules require. See approaches→ See writeups→ The team institutions already know \nInstitutions want to move real financial activity onto Ethereum.\n A public ledger exposes positions, counterparties, and flows they are not allowed to reveal.\n EthSystems, the team behind the Ethereum Foundation’s Institutional Privacy Task Force, builds the confidential, compliant systems that make that possible, from proof-of-concept through to production, backed by a year of open-source work already shipped.\n What we offer → Find the right privacy solution We document patterns, use cases, and regulatory frameworks for implementing privacy-preserving financial applications on Ethereum. Approaches Read worked architectures directly. Each names trade-offs in plain language, evaluates under CROPS, and references a working prototype where one exists. 10 approaches → Problem areas Begin from the institutional question that mirrors your situation. Each use case pairs with one or more approaches that demonstrate how others have built solutions. 23 use cases → Reusable solutions Build your own approach using the cryptographic primitives applied in our case studies. Each building block includes its risk profile, architectural layer, and trade-offs. 74 building blocks → Who is this for EthSystems coordinates between vendors and protocols, institutions, and regulators. The map and the approaches are written so each group can reach the same evidence by a different door. Pick the column that fits your role; each one is a recommended reading order, not a forced path. For business stakeholders Decide what to integrate. 01 Use cases Start with business requirements and challenges. → 02 Jurisdictions Regulatory considerations in the regions you operate in. → 03 Approaches Recommended architectures with named trade-offs. → For technical teams Decide how to build. 01 Building blocks Reusable technical building blocks with standardized evaluations. → 02 Approaches Detailed implementation guidance from worked approaches. → 03 Vendors Tooling and infrastructure options mapped to patterns. → 04 Domains Domain-specific considerations across payments, custody, identity, and more. → For legal and compliance Map regulatory requirements. 01 Jurisdictions Regulatory frameworks applied as overlay on the architectures. → 02 Use cases Compliance constraints surfaced in context, written from interview. → 03 Approaches Architectures evaluated for regulated deployment. → 04 Disclosure mechanisms Selective disclosure with keys and proofs for audit and reporting. → Recent writeups from the team Long-form research, guides, POCs, and analysis from the EthSystems team. 2026-09-25 Building blocks: chainfold A runtime-agnostic way to turn on-chain events into ordered local state, with reorg recovery and durable checkpoints. 2026-09-11 Building blocks: sealring The code that encrypts a private payment so that one recipient can read it, and finds that payment again among thousands of others. 2026-08-31 Building blocks: rotortree A durable append-only Merkle tree for note commitments. Builds the entire Tornado Cash tree in 19 milliseconds, 450x faster than the TypeScript library this ecosystem runs. See all writeups→ How we assess solutions Every pattern on this site is rated against four properties (the CROPS framework) and tagged for the institutional context it fits. CR Censorship-resistance Whether a counterparty, sequencer, or relayer can block your transaction. OS Open source Whether the implementation is free to audit, fork, and self-host. P Privacy How much of the transaction (amounts, parties, patterns) stays hidden. S Security The trust assumptions and threat model the architecture relies on. Institution to institution Both counterparties are regulated institutions. Symmetric power dynamic; both parties have legal teams, vendor choice, and contractual recourse. Institution to user One counterparty is a regulated institution, the other an individual. Asymmetric power dynamic; privacy must protect the user from the institution. Browse the patterns→ Supported by The coalition standing behind EthSystems. Ethereum Treasury · BMNR Ethereum Treasury · SBET Joe Lubin Co-Founder, Ethereum Asia Ethereum Backer What institutions ask us most The questions we hear most, answered directly. Each one links into the full FAQ where answers cite the relevant pattern, jurisdiction, and approach. What is EthSystems? An engineering and research company building confidential systems for institutional Ethereum: the privacy and compliance infrastructure institutions need to put real financial activity on the network. About us Who is behind it? The team behind the Ethereum Foundation's Institutional Privacy Task Force (IPTF). Meet the team What have you actually built? A year of public, open-source work: private bonds (ZK, privacy L2s, FHE), compliance-first private stablecoin transfers, private cross-chain atomic swaps, a validium proof-of-concept, privacy-preserving identity, the Public Rails vs Private Ledgers decision framework, and the Ethereum Privacy Map. Writeups Explore the map Why does this matter? Every institutional use of Ethereum (tokenization, stablecoins, settlement) eventually hits the same blocker: a public ledger exposes positions, counterparties, and flows that regulated institutions cannot reveal. Confidentiality with built-in compliance is what makes those deployments viable. What do you offer institutions? Hands-on engineering engagements: privacy architecture and advisory, workshops that turn interest into concrete requirements, proof-of-concepts that de-risk decisions, and the design and build of confidential systems integrated with existing vendors and infrastructure, through to live implementation. Engagements can start small and scoped. Approaches What's your relationship with the Ethereum Foundation? We created and ran the Institutional Privacy Task Force at the EF, and we continue that body of work in active collaboration with EF and EF-aligned teams: coordinating the transition together, keeping the artifacts public, and collaborating on public goods, specs, and privacy work. EthSystems is its own company because commercial delivery needs a commercial structure; the collaboration continues. How do you relate to Ethlabs and Ethereum Institutional? As complementary nodes in the same network, often with overlapping supporters, and as collaborators. Ethlabs builds and grows the core protocol and platform capabilities of Ethereum. Ethereum Institutional is a neutral, non-commercial front door helping institutions understand and navigate the ecosystem. EthSystems is the specialist builder: when an institution moves from evaluating Ethereum to building on it, we're the accountable commercial counterparty that designs and delivers the confidential systems involved. Is your work open source? Yes. Our proof-of-concepts, libraries, frameworks, and the Ethereum Privacy Map are public, and we'll keep publishing. Open, verifiable work is how we earn trust. GitHub · map Where do you operate? Globally. Read all FAQs→ Talk to EthSystems If you are an institution with a privacy requirement, a builder shipping a solution, or a regulator who wants the picture, we are listening. Contact us Tell us about your requirements and the team will follow up. → hello@ethsystems.org General correspondence with the team. → GitHub · map Open issues, propose patterns, contribute use cases. →","tokens":1908,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260511501,"hash":"a383a7cd5a95b19a8145ecb8f5a1cb127fb9d9f4"}
{"url":"https://dev-forum.pyth.network/t/about-the-forum-feedback-category/20","domain":"dev-forum.pyth.network","title":"About the Forum Feedback category - Forum Feedback - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n About the Forum Feedback category \n\n Forum Feedback\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Aditya520 on Apr 1, 2025\n\n Aditya520\n\n Feedback on how to make this developer forum better for you!\nPlease note, if you are looking for support on Pyth Products, please search or add a new topic under respective category.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to Pyth Developer Forum! \n\n General\n\n 0\n\n 578\n\n Mar 2025\n\n Welcome to the Announcements category\n\n Announcements\n\n 0\n\n 500\n\n Mar 2025\n\n About the Price Feeds category\n\n Price Feeds\n\n 0\n\n 507\n\n Apr 2025\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n Pyth Pro FAQ now live\n\n Announcements\n\n 0\n\n 81\n\n Feb 2\n\n Powered by Discourse","tokens":1080,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260514464,"hash":"d08b94d95334ce8bac12d9c333a772856724b5f1"}
{"url":"https://ethereum.org/prediction-markets/","domain":"ethereum.org","title":"Prediction markets | ethereum.org","text":"Edit page (opens in a new tab)Prediction markets use crowd wisdom and financial incentives to forecast events. They offer diverse, high-quality data and gained traction during the 2024 U.S. elections.\nHow prediction markets work\nUnlike traditional forecasting methods that rely on expert opinions, limited survey samples or historical data, prediction markets leverage real-time financial incentives and crowd wisdom to generate insights relating to a particular event—elections, crypto prices, sports outcomes—anything. \nThis allows anyone to signal support for a specific outcome with a financial commitment.\n\nBy enabling betting on real-world events and adjusting the prices as new information arises, informed opinions are valued higher, and accuracy can be rewarded. \nIn theory, because bettors stand to profit from being correct, prediction markets can forecast outcomes with great precision. Blockchain-based prediction markets are even more exciting, as virtually anyone can take part in the forecasting and earn stablecoin or cryptocurrency rewards.\nWhy does this matter?\nUnlike traditional forecasting, blockchain-based prediction markets are:\nIncentivizedParticipants stake real funds, which infers high-quality predictions.DecentralizationUsing blockchain and smart contracts ensures transparent and automated payouts.Market driven oddsPrices are set by traders buying and selling outcome shares, rather than preset by a centralized bookmaker.\nEven as an observer of the market, you can assess valuable data that would be otherwise unavailable. Think of it like this:\n\nPredictions are tied to a specific event (e.g., Will Beam Chain deploy by 2030?).\nMarket participants buy and sell shares based on their confidence in any outcome.\nPrices adjust as more participants stake their beliefs, reflecting real-time insights.\nAnyone betting correctly earns proportionately to the amount staked. \nMarket observers can leverage the open data to inform research or discussion.\n\nFind a prediction market\nThere are several Ethereum-based prediction markets available. These are some of the most well-known prediction markets today:\nPolymarketA popular forecasting market with real-time trading.Explore Polymarket (opens in a new tab)AugurA fully decentralized prediction market protocol used for predicting price trends. Disclaimer: you will need some technical expertise to start using Augur.Dive into Augur (opens in a new tab)KalshiA CFTC-compliant platform using Ethereum for USDC deposits. (USA only)Try Kalshi (opens in a new tab)\nStay mindful of the risksOnly bet what you can afford, and be aware of potential addictive behaviors.\nChallenges & Risks\nPrediction markets on the blockchain face few challenges that can impact fairness, legality, and accuracy.\n⚠️ Market Manipulation – Wealthy players can distort outcomes through wash trading.\n💧 Liquidity Issues – Low participation (thin liquidity (opens in a new tab)) can reduce market reliability.\n🏛 Regulatory Uncertainty – Governments have imposed restrictions on some platforms.\nTo mitigate these issues, Ethereum developers are experimenting with solutions like futarchy (governance by prediction markets) and decentralized identity verification.\nExperimenting with prediction markets\nPrediction markets are reshaping decision-making in the digital age. By leveraging Ethereum, they offer fair, open, and rewarding ways to predict the future.\nThere are many ways to use forecasting tools outside of financial gain. For example, in a DevCon Improvement Proposal (opens in a new tab) (DIP) it was suggested that the organizers of DevCon use prediction markets to anticipate attendance for future events. \nThis would help the organizers determine which location would lead to the largest event, compared to which location would lead to the most internationally accessible. The benefits of this mean the organizers of DevCon can expedite the amount of time required to screen multiple\nvisa policies, airport access, and cost of living in the area while also gathering data on where prospective attendees would be excited to go.\nFurther reading\nFrom prediction markets to info finance (opens in a new tab) - Vitalik Buterin\nDecentralized Prediction Market Development on Ethereum (opens in a new tab)\nThe Augur Project Whitepaper (opens in a new tab)","tokens":1078,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260521613,"hash":"bb2aa923e499173e1145417457d55ee0117d52fe"}
{"url":"https://dev-forum.pyth.network/t/welcome-to-the-announcements-category/12/1","domain":"dev-forum.pyth.network","title":"Welcome to the Announcements category - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Welcome to the Announcements category \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 1 / 2\n\n Mar 2025\n\n Mar 2025\n\n post by Aditya520 on Mar 27, 2025\n\n Aditya520\n\n Official updates related to Pyth, Pyth products and more!\nHere you’ll find:\n\n Network and protocol updates\n\n Product releases and feature announcements\n\n Developer tool upgrades and ecosystem integrations\n\nOnly Pyth team members can post here, but all community members are encouraged to follow this category to stay in the loop.\nWant to stay in the loop? Hit that at the right and set it to “Watching.”\n\n Closed on Mar 31, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to Pyth Developer Forum! \n\n General\n\n 0\n\n 578\n\n Mar 2025\n\n About the Forum Feedback category\n\n Forum Feedback\n\n 0\n\n 450\n\n Apr 2025\n\n Upcoming Changes to Pyth Sponsored Feeds – Effective August 31, 2025\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 644\n\n Sep 2025\n\n About the Incidents category\n\n Incidents\n\n 0\n\n 439\n\n May 2025\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n Powered by Discourse","tokens":1172,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260524514,"hash":"566423082cd8abe518baffe4823eb5bb996b3846"}
{"url":"https://ethereum.org/","domain":"ethereum.org","title":"Ethereum - The complete guide from ethereum.org","text":"The internet that belongs to youEthereum is the global network where you control your assets, your data, and your identity.The user-owned internetEthereum gives back control of your assetsYour bank account is an entry in someone else's database. Your application is a file in someone else's server. Ethereum is an alternative network where you hold your assets directly.322METH holders10 478 629Transactions todayYOUR BUSINESS IS YOURSUse the internet without being watchedMost apps track what you do, who you talk to, and what you own. They sell that data or hand it over when asked. On Ethereum, your activity can stay private.No account tied to your name. No company watching your balance.Why privacy matters TRADITIONAL APPSYour data is their productETHEREUM APPSPrivate by defaultTRADITIONAL APPSYour data is their productETHEREUM APPSPrivate by defaultCROSS-BORDER PAYMENTSSend money home in 12 secondsSkip the $50 wire fee and the 5+ day wait.Send stablecoins to anyone, anywhere in the world, for just $0.02. They receive the funds almost instantly.Try it yourself WIRE TRANSFER3-5 daysETHEREUM12 secondsWIRE TRANSFER3-5 daysETHEREUM12 secondsFINANCIAL ACCESSBorrow without credit historyYou don't need a credit score to get started.Using DeFi apps on Ethereum, you can provide collateral and access credit instantly, no permission required.Learn more about DeFi TRADITIONAL BANKCredit checksON ETHEREUMBased on collateralTRADITIONAL BANKCredit checksON ETHEREUMBased on collateralNever offline100% uptime10 yearsSince 2015Proven track recordBuilt to lastEthereum has run continuously since 2015 without a single second of downtime.The code is open for anyone to verify. No company runs it, no one can shut it down, and thousands of independent operators keep it going worldwide.Get ETH Free foreverTry Ethereum in your browserExperience how Ethereum works. Just click and explore.1/7Receive digital assets from anywhereYour wallet helps you manage your funds, , identity and more. Here we'll go over how to receive and send some tokens on Ethereum.Let's first look at how to receive ether (ETH), Ethereum's native currency.Click the \"Receive\" button to see how to receive funds.Your total$00xfa4e...de30CryptoNFTsEther$00 ETHDAI$00 DAIUniswap$00 UNITry more guides What makes Ethereum differentPrinciples that set Ethereum apart from traditional systemsDirect ownershipYour bank balance is a custody promise. Your Ethereum balance is true ownership.$4.6B+Daily trading volume (USD)Public rulesThe code is public, agreements execute exactly as written. Think vending machine versus hoping the cashier gives correct change.GlobalAnyone, anywhere can use Ethereum. No permission needed.Free accessNo credit check, no minimum balance, no account approval. If you have internet, you're in.Nobody owns EthereumChanges happen through open proposals that anyone can participate in. Think community garden versus corporate farm.What is Ethereum? Nov 3 – 6, 2026November 3 – 6, 2026Mumbai, IndiaGather with the curious at Devcon 8Use ETHORG10 to claim your exclusive 10% General Admission discountGet tickets link-external-assistive-textLatest Ethereum updatesBlast Shuts Down Its L2ETH DailyBlast is winding down its Ethereum Layer 2 due to unsustainable operating costs, urging users to withdraw before October 26 as the exit delay drops to 24 hours.NewslettersOct 2, 2026 link-external-assistive-textEthereal news weekly #41EtherealGlamsterdam upgrade on Sepolia testnet October 6, Vitalik: the cryptographic world computer, Hegotá upgrade focil-devnet-0 liveNewslettersOct 2, 2026 link-external-assistive-textRemix Release v2.6.4Ethereum RemixRemixAI now selects audit checklist. Deploy & Run with a UI improvement. New RemixAI for low cost LLMs.Dev toolingOct 1, 2026 link-external-assistive-textView moreGet started on EthereumTakes 2 minutes to get started. No credit check, no paperwork, no minimum balance.Understand EthereumStart here. Learn what it is, why it matters, and how it works in plain language.What is Ethereum?How do wallets work?DeFi, stablecoins, and NFTs explainedStart learningStart buildingFor developers. Access documentation, tools, and tutorials to build on Ethereum.Developer documentationSmart contract tutorialsDevelopment tools & frameworksView materialsFor enterpriseBusiness use cases, institutional resources, and how Ethereum can serve your organization.Enterprise use casesPrivate & permissioned networksInstitutional resourcesExplore enterprise link-external-assistive-text","tokens":1128,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260541891,"hash":"768c047f9923c85546c51555a6536b30d4763e2e"}
{"url":"https://dev-forum.pyth.network/c/forum-feedback/10","domain":"dev-forum.pyth.network","title":"Latest Forum Feedback topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Forum Feedback\n\n Forum Feedback\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Forum Feedback category\n\n Feedback on how to make this developer forum better for you! \nPlease note, if you are looking for support on Pyth Products, please search or add a new topic under respective category.\n\n 0\n\n 450\n\n Apr 2025\n\n Powered by Discourse","tokens":980,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260544364,"hash":"64280f512f398068c2c8a6fcd22f0eb684443d4c"}
{"url":"https://io.net/docs/guides/explorer/workers-page","domain":"io.net","title":"Workers - io.net","text":"Key Metrics Displayed:\n\nTotal GPUs (hired and idle)\nTotal CPUs (hired and idle)\n\n​Available Inventory\nThe Workers tab also highlights available inventory, which includes both active and passive GPU and CPU processors. You can click on a specific processor to view detailed statistics about its usage and performance.\n\n​Workers List\nThe Workers List provides a transparent, real-time view of all connected devices, along with their current operational status and hire activity.\nThe table includes:\n\nWorker Status (active, idle, or under maintenance)\nLink to View Worker Details (for in-depth metrics)\nHire Status (availability for compute tasks)\nUptime Duration (how long the worker has been active)\nDevice Types & Quantities (detailed breakdown within each cluster)\n\n​Worker Details\nUsers can access a detailed view of each Device by selecting it from the Workers List. The details for each device includes full specifications, utilization metrics, and a breakdown of worker performance.\n​Device Overview Includes:\nAt the top of the Device Overview, users can view:\n\nBlock Rewards Nomination Eligibility Status\n\nDefault view shows only pass/fail status for each category.\nUsers can expand the section to see detailed criteria for Block Rewards Nominations.\n\nUptime Graph for the Last 30 Days\n\nEasily track whether the device has experienced downtime or remained continuously active.\n\n​Main Metrics Displayed:\nOn the right-hand side of the page, users can find key performance indicators for the selected device:\n\nUptime Percentage (availability over time)\nTraffic Transmitted (data usage and throughput)\nConnectivity Tier (network performance classification)\nSecurity Compliance (status of security protocols)\nLocation (geographic placement of the device)\n\nRunning Services:\n\nIO Version Control Status (software version management)\nIO Monitor Status (device health monitoring)\nRay.io Status (distributed computing framework status)\n\nThis Device Overview enables users to efficiently track, manage, and assess decentralized compute resources in real-time.\n\nBlock Rewards:\nThe Block Rewards tab provides detailed information about all of the Block Rewards associated with a specific device, this includes:\nBlockDescriptionBlock RewardTo the right of Block Reward, you see the status. In this instance, it’s Completed. If the device fails to satisfy the POW and POTL requirements, Failed will appear.Block IDA unique identifier assigned to each block within a blockchain.Connectivity TierThe Connectivity Tier that the worker qualifies for. This is an option when a customer reserves a GPU/CPU when they deploy a cluster.ProcessorThe processor type, GPU/CPU. In this example, it’s a Nvidia L4 GPU.Processor QuantityNumber of processors available for the worker.POTL(Proof of Timelock) - Verifies the uptime for the worker. This can be executed against a hired worker.POW(zkTFLOPs Proof) Tasks the worker must solve to verify the worker. To learn more about POW, see Proof of Work. This is never executed against a hired worker.Device Base ScoreThis score is based on hardware quantity, hardware multiplier, and the connectivity tier.\nSee below for the base score calculation:\n+ (0.02 x (connectivity_tier_number\" / 4.0)) \n + (2.0 x \"hardware_multiplier\" x \"processor_quantity\") ) x 100 + (0.05 x \"was_hired\")) x 10\n\nThe formula above is subject to future change by the IOG foundation. For example, a significant increase for the weight of hired status in the overall base score calculation. This would incentivize practical and usable GPU device growth within the IO ecosystem.\nDevice Normalized Score- This score represents potential earnings for the device, which is based on the available coin emissions for the block and the scores of all eligible devices.\nThe calculation is designed to ensure that the total GPU Normalized Score is 8M, and Total CPU Normalized Score is 2M. Device Normalised Score is calculated as Device Base Score / Total Base Score of Device Type / Normalized Score allocation.\nFor example, if a GPU Device Base Score is 8150, the total GPU device score at that hour across the entire network is 115M, then the GPU Device Normalized Score is 569. (8150/115Mx8M).\nRewarded- The amount of IO Coin the worker earned based on Total Score.\nWas this page helpful?","tokens":1070,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260566786,"hash":"62c919cccc60dcf0c380dbe4df2759b85d4f5f67"}
{"url":"https://vitalik.eth.limo/general/2017/05/08/coordination_problems.html","domain":"vitalik.eth.limo","title":"Engineering Security Through Coordination Problems","text":"Dark Mode Toggle\n\n Engineering Security Through Coordination Problems \n 2017 May 08 \nSee all posts\n\n Engineering Security Through Coordination Problems \n\nRecently, there was a small spat between the Core and Unlimited\nfactions of the Bitcoin community, a spat which represents perhaps the\nfiftieth time the same theme was debated, but which is nonetheless\ninteresting because of how it highlights a very subtle philosophical\npoint about how blockchains work.\nViaBTC, a mining pool that favors Unlimited, tweeted \"hashpower is\nlaw\", a usual talking point for the Unlimited side, which believes that\nminers have, and should have, a very large role in the governance of\nBitcoin, the usual argument for this being that miners are the one\ncategory of users that has a large and illiquid financial incentive in\nBitcoin's success. Greg Maxwell (from the Core side) replied\nthat \"Bitcoin's security works precisely because hash power is NOT\nlaw\".\nThe Core argument is that miners only have a limited role in the Bitcoin\nsystem, to secure the ordering of transactions, and they should NOT have\nthe power to determine anything else, including block size limits and\nother block validity rules. These constraints are enforced by full nodes\nrun by users - if miners start producing blocks according to a set of\nrules different than the rules that users' nodes enforce, then the\nusers' nodes will simply reject the blocks, regardless of whether 10% or\n60% or 99% of the hashpower is behind them. To this, Unlimited often\nreplies with something like \"if 90% of the hashpower is behind a new\nchain that increases the block limit, and the old chain with 10%\nhashpower is now ten times slower for five months until difficulty\nreadjusts, would you really not update your client to accept\nthe new chain?\" \n\n Many people often argue\nagainst\nthe use of public blockchains for applications that involve real-world\nassets or anything with counterparty risk. The critiques are either\ntotal, saying that there is no point in implementing such use cases on\npublic blockchains, or partial, saying that while there may be\nadvantages to storing the data on a public chain, the\nbusiness logic should be executed off chain.\nThe argument usually used is that in such applications, points of trust\nexist already - there is someone who owns the physical assets that back\nthe on-chain permissioned assets, and that someone could always choose\nto run away with the assets or be compelled to freeze them by a\ngovernment or bank, and so managing the digital representations of these\nassets on a blockchain is like paying for a reinforced steel door for\none's house when the window is open. Instead, such systems should use\nprivate chains, or even traditional server-based solutions, perhaps\nadding bits and pieces of cryptography to improve auditability, and\nthereby save on the inefficiencies and costs of putting everything on a\nblockchain. \n\n The arguments above are both flawed in their pure forms, and\nthey are flawed in a similar way. While it is theoretically\npossible for miners to switch 99% of their hashpower to a chain\nwith new rules (to make an example where this is uncontroversially bad,\nsuppose that they are increasing the block reward), and even spawn-camp\nthe old chain to make it permanently useless, and it is also\ntheoretically possible for a centralized manager of an asset-backed\ncurrency to cease honoring one digital token, make a new digital token\nwith the same balances as the old token except with one particular\naccount's balance reduced to zero, and start honoring the new token, in\npractice those things are both quite hard to do.\nIn the first case, users will have to realize that something is wrong\nwith the existing chain, agree that they should go to the new chain that\nthe miners are now mining on, and download the software that accepts the\nnew rules. In the second case, all clients and applications that depend\non the original digital token will break, users will need to update\ntheir clients to switch to the new digital token, and smart contracts\nwith no capacity to look to the outside world and see that they need to\nupdate will break entirely. In the middle of all this, opponents of the\nswitch can create a fear-uncertainty-and-doubt campaign to try to\nconvince people that maybe they shouldn't update their clients after\nall, or update their client to some third set of rules (eg.\nchanging proof of work), and this makes implementing the switch even\nmore difficult.\nHence, we can say that in both cases, even though there theoretically\nare centralized or quasi-centralized parties that could force a\ntransition from state A to state B, where state B is disagreeable to\nusers but preferable to the centralized parties, doing so requires\nbreaking through a hard coordination problem.\nCoordination problems are everywhere in society and are often a bad\nthing - while it would be better for most people if the English language\ngot rid of its highly complex and irregular spelling system and made a\nphonetic one, or if the United States switched to metric, or if we could\nimmediately drop all\nprices and wages by ten percent in the event of a recession, in\npractice this requires everyone to agree on the switch at the same time,\nand this is often very very hard.\nWith blockchain applications, however, we are doing something\ndifferent: we are using coordination problems to our\nadvantage, using the friction that coordination problems create\nas a bulwark against malfeasance by centralized actors. We can build\nsystems that have property X, and we can guarantee that they will\npreserve property X to a high degree because changing the rules from X\nto not-X would require a whole bunch of people to agree to update their\nsoftware at the same time. Even if there is an actor that could force\nthe change, doing so would be hard. This is the kind of security that\nyou gain from client-side validation of blockchain consensus rules.\nNote that this kind of security relies on the decentralization of users\nspecifically. Even if there is only one miner in the world, there is\nstill a difference between a cryptocurrency mined by that miner and a\nPayPal-like centralized system. In the latter case, the operator can\nchoose to arbitrarily change the rules, freeze people's money, offer bad\nservice, jack up their fees or do a whole host of other things, and the\ncoordination problems are in the operator's favor, as such systems have\nsubstantial network effects and so very many users would have to agree\nat the same time to switch to a better system. In the former case,\nclient-side validation means that many attempts at mischief that the\nminer might want to engage in are by default rejected, and the\ncoordination problem now works in the users' favor. \n\n Note that the arguments above do NOT, by themselves,\nimply that it is a bad idea for miners to be the principal actors\ncoordinating and deciding the block size (or in Ethereum's case, the gas\nlimit). It may well be the case that, in the specific case of the\nblock size/gas limit, \"government by coordinated miners with\naligned incentives\" is the optimal approach for deciding this one\nparticular policy parameter, perhaps because the risk of miners abusing\ntheir power is lower than the risk that any specific chosen hard limit\nwill prove wildly inappropriate for market conditions a decade after the\nlimit is set. However, there is nothing unreasonable about saying that\ngovernment-by-miners is the best way to decide one policy parameter, and\nat the same saying that for other parameters (eg. block reward)\nwe want to rely on client-side validation to ensure that miners are\nconstrained. This is the essence of engineering decentralized\ninstutitions: it is about strategically using coordination problems to\nensure that systems continue to satisfy certain desired properties.\nThe arguments above also do not imply that it is always optimal to try\nto put everything onto a blockchain even for services that are\ntrust-requiring. There generally are at least some gains to be made by\nrunning more business logic on a blockchain, but they are often much\nsmaller than the losses to efficiency or privacy. And this ok; the\nblockchain is not the best tool for every task. What the arguments above\ndo imply, though, is that if you are building a\nblockchain-based application that contains many centralized components\nout of necessity, then you can make substantial further gains in\ntrust-minimization by giving users a way to access your application\nthrough a regular blockchain client (eg. in the case of Ethereum, this\nmight be Mist, Parity, Metamask or Status), instead of getting them to\nuse a web interface that you personally control. \n\n Theoretically, the benefits of user-side validation are\noptimized if literally every user runs an independent \"ideal full node\"\n- a node that accepts all blocks that follow the protocol rules that\neveryone agreed to when creating the system, and rejects all blocks that\ndo not. In practice, however, this involves asking every user to process\nevery transaction run by everyone in the network, which is clearly\nuntenable, especially keeping in mind the rapid growth of smartphone\nusers in the developing world.\nThere are two ways out here. The first is that we can realize that\nwhile it is optimal from the point of view of the above\narguments that everyone runs a full node, it is certainly not\nrequired. Arguably, any major blockchain running at full\ncapacity will have already reached the point where it will not make\nsense for \"the common people\" to expend a fifth of their hard drive\nspace to run a full node, and so the remaining users are hobbyists and\nbusinesses. As long as there is a fairly large number of them, and they\ncome from diverse backgrounds, the coordination problem of getting these\nusers to collude will still be very hard.\nSecond, we can rely on strong light client\ntechnology.\nThere are two levels of \"light clients\" that are generally possible\nin blockchain systems. The first, weaker, kind of light client simply\nconvinces the user, with some degree of economic assurance, that they\nare on the chain that is supported by the majority of the network. This\ncan be done much more cheaply than verifying the entire chain, as all\nclients need to do is in proof of work schemes verify nonces or in proof\nstake schemes verify signed certificates that state \"either the root\nhash of the state is what I say it is, or you can publish this\ncertificate into the main chain to delete a large amount of my money\".\nOnce the light client verifies a root hash, they can use Merkle trees to\nverify any specific piece of data that they might want to verify.\n\nLook, it's a Merkle tree!\n\nThe second level is a \"nearly fully verifying\" light client. This\nkind of client doesn't just try to follow the chain that the majority\nfollows; rather, it also tries to follow only chains that follow all the\nrules. This is done by a combination of strategies; the simplest to\nexplain is that a light client can work together with specialized nodes\n(credit to Gavin Wood for coming up with the name \"fishermen\") whose\npurpose is to look for blocks that are invalid and generate \"fraud\nproofs\", short messages that essentially say \"Look! This block has a\nflaw over here!\". Light clients can then verify that specific part of a\nblock and check if it's actually invalid.\nIf a block is found to be invalid, it is discarded; if a light client\ndoes not hear any fraud proofs for a given block for a few minutes, then\nit assumes that the block is probably legitimate. There's a bit\nmore complexity involved in handling the case where the problem is\nnot data that is bad, but rather data that is missing,\nbut in general it is possible to get quite close to catching all\npossible ways that miners or validators can violate the rules of the\nprotocol.\nNote that in order for a light client to be able to efficiently\nvalidate a set of application rules, those rules must be executed inside\nof consensus - that is, they must be either part of the protocol or part\nof a mechanism executing inside the protocol (like a smart contract).\nThis is a key argument in favor of using the blockchain for both data\nstorage and business logic execution, as opposed to just data\nstorage.\nThese light client techniques are imperfect, in that they do rely on\nassumptions about network connectivity and the number of other light\nclients and fishermen that are in the network. But it is actually not\ncrucial for them to work 100% of the time for 100% of validators.\nRather, all that we want is to create a situation where any attempt by a\nhostile cartel of miners/validators to push invalid blocks without user\nconsent will cause a large amount of headaches for lots of people and\nultimately require everyone to update their software if they want to\ncontinue to synchronize with the invalid chain. As long as this is\nsatisfied, we have achieved the goal of security through coordination\nfrictions.","tokens":3238,"squid":"ink-research","role":"Deep Scholar","at":1791260568442,"hash":"4ffbb1ca53e388138040fc4631e7cd74a8313658"}
{"url":"https://vitalik.eth.limo/index.html","domain":"vitalik.eth.limo","title":"Vitalik Buterin's website","text":"Dark Mode Toggle\n\n Vitalik Buterin's website \n\n Vitalik Buterin's website \n\nBlockchains\nCryptography\nEconomics\nFun\nGeneral\nGitcoin\nMath\nPhilosophy\nTranslations\n\n 2026 Sep 27\n\n The cryptographic world computer\n\n 2026 Aug 21\n\n Obfuscation (Part III): Local Mixing\n\n 2026 Jul 28\n\n Obfuscation (Part II): Diamond iO\n\n 2026 Jun 29\n\n Obfuscation: building the final boss of cryptography (Part I)\n\n 2026 May 18\n\n A shallow dive into formal verification\n\n 2026 Apr 02\n\n My self-sovereign / local / private / secure LLM setup, April 2026\n\n 2025 Dec 30\n\n Balance of power\n\n 2025 Dec 17\n\n Let a thousand societies bloom\n\n 2025 Nov 25\n\n Plinko PIR tutorial\n\n 2025 Nov 07\n\n Galaxy brain resistance\n\n 2025 Oct 19\n\n A GKR Tutorial\n\n 2025 Oct 05\n\n Memory access is O(N^[1/3])\n\n 2025 Sep 24\n\n The importance of full-stack openness and verifiability\n\n 2025 Sep 21\n\n Low-risk defi can be for Ethereum what search was for Google\n\n 2025 Aug 12\n\n On idea-driven ideas\n\n 2025 Aug 12\n\n \"I support it only if it's open source\" should be a more common viewpoint\n\n 2025 Jul 10\n\n My response to AI 2027\n\n 2025 Jul 07\n\n Why I used to prefer permissive licenses and now favor copyleft\n\n 2025 Jun 28\n\n Does digital ID have risks even if it's ZK-wrapped?\n\n 2025 May 11\n\n A simple explanation of a/(b+c) + b/(c+a) + c/(a+b) = 4\n\n 2025 May 06\n\n The math of when stage 1 and stage 2 make sense\n\n 2025 May 03\n\n Simplifying the L1\n\n 2025 Apr 14\n\n Why I support privacy\n\n 2025 Mar 29\n\n We should talk less about public goods funding and more about open source funding\n\n 2025 Mar 29\n\n The tree ring model of culture and politics\n\n 2025 Feb 28\n\n AI as the engine, humans as the steering wheel\n\n 2025 Feb 14\n\n Reasons to have higher L1 gas limits even in an L2-heavy Ethereum\n\n 2025 Jan 23\n\n Scaling Ethereum L1 and L2s in 2025 and beyond\n\n 2025 Jan 05\n\n d/acc: one year later\n\n 2024 Dec 03\n\n What I would love to see in a wallet\n\n 2024 Nov 09\n\n From prediction markets to info finance\n\n 2024 Oct 29\n\n Possible futures of the Ethereum protocol, part 6: The Splurge\n\n 2024 Oct 26\n\n Possible futures of the Ethereum protocol, part 5: The Purge\n\n 2024 Oct 23\n\n Possible futures of the Ethereum protocol, part 4: The Verge\n\n 2024 Oct 20\n\n Possible futures of the Ethereum protocol, part 3: The Scourge\n\n 2024 Oct 17\n\n Possible futures of the Ethereum protocol, part 2: The Surge\n\n 2024 Oct 14\n\n Possible futures of the Ethereum protocol, part 1: The Merge\n\n 2024 Sep 28\n\n Making Ethereum alignment legible\n\n 2024 Sep 02\n\n Glue and coprocessor architectures\n\n 2024 Aug 21\n\n Plurality philosophy in an incredibly oversized nutshell\n\n 2024 Aug 03\n\n Review: museums of the future, Dubai and Tokyo\n\n 2024 Jul 23\n\n Exploring circle STARKs\n\n 2024 Jul 17\n\n Against choosing your political allegiances based on who is \"pro-crypto\"\n\n 2024 Jun 30\n\n Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times\n\n 2024 May 31\n\n Some reflections on the Bitcoin block size war\n\n 2024 May 29\n\n Layer 2s as cultural extensions of Ethereum\n\n 2024 May 23\n\n How do layer 2s really differ from execution sharding?\n\n 2024 May 17\n\n The near and mid-term future of improving the Ethereum network's permissionlessness and decentralization\n\n 2024 May 09\n\n Multidimensional gas pricing\n\n 2024 Apr 29\n\n Binius: highly efficient proofs over binary fields\n\n 2024 Apr 01\n\n Degen communism: the only correct political ideology\n\n 2024 Mar 29\n\n What else could memecoins be?\n\n 2024 Mar 28\n\n Ethereum has blobs. Where do we go from here?\n\n 2024 Feb 09\n\n Ask security questions\n\n 2024 Jan 31\n\n The end of my childhood\n\n 2024 Jan 30\n\n The promise and challenges of crypto + AI applications\n\n 2023 Dec 28\n\n Make Ethereum Cypherpunk Again\n\n 2023 Nov 27\n\n My techno-optimism\n\n 2023 Nov 14\n\n Exit games for EVM validiums: the return of Plasma\n\n 2023 Oct 31\n\n Different types of layer 2s\n\n 2023 Sep 30\n\n Should Ethereum be okay with enshrining more things in the protocol?\n\n 2023 Aug 16\n\n What do I think about Community Notes?\n\n 2023 Jul 24\n\n What do I think about biometric proof of personhood?\n\n 2023 Jun 20\n\n Deeper dive on cross-L2 reading for wallets and other use cases\n\n 2023 Jun 09\n\n The Three Transitions\n\n 2023 May 21\n\n Don't overload Ethereum's consensus\n\n 2023 Apr 14\n\n Travel time ~= 750 * distance ^ 0.6\n\n 2023 Mar 31\n\n How will Ethereum's multi-client philosophy interact with ZK-EVMs?\n\n 2023 Feb 28\n\n Some personal user experiences\n\n 2023 Jan 20\n\n An incomplete guide to stealth addresses\n\n 2022 Dec 30\n\n What even is an institution?\n\n 2022 Dec 06\n\n Updating my blog: a quick GPT chatbot coding experiment\n\n 2022 Dec 05\n\n What in the Ethereum application ecosystem excites me\n\n 2022 Nov 19\n\n Having a safe CEX: proof of solvency and beyond\n\n 2022 Oct 28\n\n The Revenue-Evil Curve: a different way to think about prioritizing public goods funding\n\n 2022 Sep 20\n\n DAOs are not corporations: where decentralization in autonomous organizations matters\n\n 2022 Sep 17\n\n What kind of layer 3s make sense?\n\n 2022 Sep 09\n\n Should there be demand-based recurring fees on ENS domains?\n\n 2022 Aug 04\n\n The different types of ZK-EVMs\n\n 2022 Jul 13\n\n What do I think about network states?\n\n 2022 Jun 20\n\n My 40-liter backpack travel guide\n\n 2022 Jun 15\n\n Some ways to use ZK-SNARKs for privacy\n\n 2022 Jun 12\n\n Where to use a blockchain in non-financial applications?\n\n 2022 May 25\n\n Two thought experiments to evaluate automated stablecoins\n\n 2022 Apr 01\n\n In Defense of Bitcoin Maximalism\n\n 2022 Mar 29\n\n The roads not taken\n\n 2022 Mar 14\n\n How do trusted setups work?\n\n 2022 Feb 28\n\n Encapsulated vs systemic complexity in protocol design\n\n 2022 Jan 26\n\n Soulbound\n\n 2021 Dec 19\n\n The bulldozer vs vetocracy political axis\n\n 2021 Dec 06\n\n Endgame\n\n 2021 Nov 16\n\n Review of Optimism retro funding round 1\n\n 2021 Nov 05\n\n Halo and more: exploring incremental verification and SNARKs without pairings\n\n 2021 Oct 31\n\n Crypto Cities\n\n 2021 Sep 26\n\n On Nathan Schneider on the limits of cryptoeconomics\n\n 2021 Aug 22\n\n Alternatives to selling at below-market-clearing prices for achieving fairness (or community sentiment, or fun)\n\n 2021 Aug 16\n\n Moving beyond coin voting governance\n\n 2021 Jul 29\n\n Against overuse of the Gini coefficient\n\n 2021 Jun 18\n\n Verkle trees\n\n 2021 May 25\n\n Blockchain voting is overrated among uninformed people but underrated among informed people\n\n 2021 May 23\n\n The Limits to Blockchain Scalability\n\n 2021 Apr 07\n\n Why sharding is great: demystifying the technical properties\n\n 2021 Apr 02\n\n Gitcoin Grants Round 9: The Next Phase of Growth\n\n 2021 Mar 23\n\n The Most Important Scarce Resource is Legitimacy\n\n 2021 Feb 18\n\n Prediction Markets: Tales from the Election\n\n 2021 Jan 26\n\n An approximate introduction to how zk-SNARKs are possible\n\n 2021 Jan 11\n\n Why we need wide adoption of social recovery wallets\n\n 2021 Jan 05\n\n An Incomplete Guide to Rollups\n\n 2020 Dec 28\n\n Endnotes on 2020: Crypto and Beyond\n\n 2020 Nov 08\n\n Convex and Concave Dispositions\n\n 2020 Nov 06\n\n Why Proof of Stake (Nov 2020)\n\n 2020 Oct 18\n\n Gitcoin Grants Round 7 Retrospective\n\n 2020 Sep 11\n\n Coordination, Good and Bad\n\n 2020 Aug 20\n\n Trust Models\n\n 2020 Aug 17\n\n A Philosophy of Blockchain Validation\n\n 2020 Jul 22\n\n Gitcoin Grants Round 6 Retrospective\n\n 2020 Jul 20\n\n Exploring Fully Homomorphic Encryption\n\n 2020 Apr 30\n\n Gitcoin Grants Round 5 Retrospective\n\n 2020 Mar 21\n\n A Quick Garbled Circuits Primer\n\n 2020 Jan 28\n\n Review of Gitcoin Quadratic Funding Round 4\n\n 2019 Dec 26\n\n Base Layers And Functionality Escape Velocity\n\n 2019 Dec 24\n\n Christmas Special\n\n 2019 Dec 07\n\n Quadratic Payments: A Primer\n\n 2019 Nov 22\n\n Hard Problems in Cryptocurrency: Five Years Later\n\n 2019 Oct 24\n\n Review of Gitcoin Quadratic Funding Round 3\n\n 2019 Oct 01\n\n In-person meatspace protocol to prove unconditional possession of a private key\n\n 2019 Sep 22\n\n Understanding PLONK\n\n 2019 Aug 28\n\n The Dawn of Hybrid Layer 2 Protocols\n\n 2019 Jun 12\n\n Sidechains vs Plasma vs Sharding\n\n 2019 May 12\n\n Fast Fourier Transforms\n\n 2019 May 09\n\n Control as Liability\n\n 2019 Apr 16\n\n On Free Speech\n\n 2019 Apr 03\n\n On Collusion\n\n 2019 Apr 01\n\n [Mirror] Cantor was Wrong: debunking the infinite set hierarchy\n\n 2018 Dec 05\n\n A CBC Casper Tutorial\n\n 2018 Nov 25\n\n [Mirror] Central Planning as Overfitting\n\n 2018 Aug 26\n\n Layer 1 Should Be Innovative in the Short Term but Less in the Long Term\n\n 2018 Aug 07\n\n A Guide to 99% Fault Tolerant Consensus\n\n 2018 Jul 21\n\n STARKs, Part 3: Into the Weeds\n\n 2018 Apr 20\n\n On Radical Markets\n\n 2018 Mar 28\n\n Governance, Part 2: Plutocracy Is Still Bad\n\n 2017 Dec 31\n\n Proof of Stake FAQ\n\n 2017 Dec 31\n\n Sharding FAQ\n\n 2017 Dec 17\n\n Notes on Blockchain Governance\n\n 2017 Dec 14\n\n A Quick Gasprice Market Analysis\n\n 2017 Nov 22\n\n STARKs, Part II: Thank Goodness It's FRI-day\n\n 2017 Nov 09\n\n STARKs, Part I: Proofs with Polynomials\n\n 2017 Oct 17\n\n On Medium-of-Exchange Token Valuations\n\n 2017 Sep 14\n\n A Prehistory of the Ethereum Protocol\n\n 2017 Jul 27\n\n A Note on Metcalfe's Law, Externalities and Ecosystem Splits\n\n 2017 Jul 16\n\n The Triangle of Harm\n\n 2017 Jun 22\n\n On Path Independence\n\n 2017 Jun 09\n\n Analyzing Token Sale Models\n\n 2017 May 08\n\n Engineering Security Through Coordination Problems\n\n 2017 Mar 14\n\n Hard Forks, Soft Forks, Defaults and Coercion\n\n 2017 Mar 11\n\n A Note On Charity Through Marginal Price Discrimination\n\n 2017 Feb 01\n\n [Mirror] Zk-SNARKs: Under the Hood\n\n 2017 Jan 14\n\n [Mirror] Exploring Elliptic Curve Pairings\n\n 2016 Dec 29\n\n [Mirror] A Proof of Stake Design Philosophy\n\n 2016 Dec 10\n\n [Mirror] Quadratic Arithmetic Programs: from Zero to Hero","tokens":2389,"squid":"ink-research","role":"Deep Scholar","at":1791260579522,"hash":"5fe644182c70f538de54ed47d19be8958a7aea1f"}
{"url":"https://vote.optimism.io/delegates/0xf4b0556b9b6f53e00a1fdd2b0478ce841991d8fa","domain":"vote.optimism.io","title":"olimpio.eth on Agora","text":"Voted against this proposal about 2 months ago with 2.17M votesRe-designating the User Airdrop Allocation as the Strategic Ecosystem FundVoted abstain this proposal 3 months ago with 2.16M votesSecurity Council Operating BudgetVoted abstain this proposal 3 months ago with 2.16M votesSequencer ETH Management: 12-Month Renewal and Treasury OptimizationVoted for this proposal 3 months ago with 2.16M votesDeveloper Advisory Board Dissolution ProposalVoted for this proposal 3 months ago with 2.16M votesOperating Manual Update ProposalVoted for this proposal 3 months ago with 2.16M votesGrants Council Dissolution ProposalVoted for this proposal 3 months ago with 2.16M votesMilestones and Metrics Council Dissolution ProposalVoted on 1 options in this proposal 4 months ago with 2.2M votes[Second vote] Security Council Elections Cohort B MembersINK FoundationVoted on 2 options in this proposal 4 months ago with 2.22M votesSecurity Council Elections Cohort B MembersVoted: INK Foundation, OP LabsVoted abstain this proposal 8 months ago with 2.48M votesDAO Operating Budget Midpoint AdjustmentVoted abstain this proposal 8 months ago with 2.48M votesProposal to Align OP Token with Superchain SuccessVoted on 1 options in this proposal 12 months ago with 2.75M votesSecurity Council Elections: Cohort A LeadalishaVoted on 4 options in this proposal 12 months ago with 2.75M votesSecurity Council Elections Cohort A MembersVoted: Agora, Cyfrin, pablito.eth, RoutescanVoted for this proposal about 1 year ago with 3.23M votesSecurity Council Season 7 Retroactive Funding RequestVoted on 1 options in this proposal about 1 year ago with 3.31M votesMilestones & Metrics Council Election: ReviewersSEEDGovVoted on 2 options in this proposal about 1 year ago with 3.31M votesDeveloper Advisory Board Election: MembersVoted: blockdev, devtooliganVoted on 1 options in this proposal about 1 year ago with 3.31M votesSeason 8/9 Operating BudgetsSecurity Council Operating BudgetVoted on 1 options in this proposal about 1 year ago with 3.31M votesGrants Council Election: OperationsBunnicVoted on 2 options in this proposal about 1 year ago with 3.31M votesGrants Council Election: Final ReviewerVoted: Doug sugma, GFX LabsVoted for this proposal about 1 year ago with 3.31M votesAnticapture Commission Dissolution ProposalLoading...","tokens":582,"squid":"ink-governance","role":"Council Listener","at":1791260580542,"hash":"1a8bc82822a042f4cd047fa34594ef0a7cac1a60"}
{"url":"https://io.net/docs/guides/workers/solana","domain":"io.net","title":"Solana Wallet - io.net","text":"​What is a Solana Wallet?\nA Solana wallet is a digital wallet used to store, manage, and interact with Solana (SOL) tokens and other assets on the Solana blockchain. It allows users to securely send, receive, and store their SOL tokens, as well as participate in decentralized finance (DeFi) activities such as staking, lending, and trading on decentralized exchanges (DEXs). Solana wallets come in various forms, including web wallets, mobile wallets, desktop wallets, and hardware wallets, each offering different levels of security and convenience for managing SOL tokens and engaging with the Solana ecosystem.\n​How to Create a Solana Wallet\nIO.NET is a DeFi project on Solana that pools GPU/CPU resources for artificial intelligence (AI) and machine learning (ML) companies. It uses Solana’s blockchain for transparent proof-of-compute, making all jobs and transactions visible on-chain. You can create any Solana (SOL) wallet from the official list here: Solana Ecosystem.\nFor this example, we will use a popular option - Phantom, and demonstrate how to configure and use the wallet:\n​1. Go to Phantom Wallet.\n\nSelect the browser to install Phantom on. In this example, we use Chrome.\nClick Download.\n\n​2. Add to Chrome\nAfter you click Download, you’re redirect to the extension download page.\nClick Add to Chrome to add the extension to Chrome.\n\n​3. Open the Phantom extension\n\nClick Create a new wallet.\nCreate a password for your wallet.\nClick Continue.\n\nIf you forget your password you will need to restore your wallet using your seed words, provided in the next step. Also, if you clear the browser cache, you cannot login using a password. You must restore wallet again using the seed word.\n\n​4. Store the Recovery Phrase\n\nIn the Secret Recovery Phrase page, copy and store your 24 word Secret Recovery phrase. You can save them on password managers like Keepass.\nClick Continue.\n\nFailure to save your Secret Recovery Phrase can result in an inability to access your account. You may lose access to your coins.\n​5. Copy the SOL Address\nAfter you click Continue, the wallet generates a new SOL address. This is the address used to receive coins.\nTo copy your SOL address:\n\nClick on Solana wallet.\nClick Receive.\nClick Copy button to copy deposit address.\n\n​6. Go to your IO ID account to set your new SOL wallet address.\nFollow the steps below to set your SOL wallet address.\n\nLog in to your io.net account.\nGo to your Account Settings via dropdown menu (in the top-right corner).\nIn Account Settings, find the Solana Wallet Address block and click the Add Wallet button.\nIn the appearing popup, enter your new Solana wallet address.\nClick Connect to add the new address.\n\nWas this page helpful?","tokens":677,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260588175,"hash":"6fc951da9179ed32044ec8d54b4cf6b2666fe33d"}
{"url":"https://vitalik.eth.limo/general/2025/12/17/societies.html","domain":"vitalik.eth.limo","title":"Let a thousand societies bloom","text":"Dark Mode Toggle\n\n Let a thousand societies bloom \n 2025 Dec 17 \nSee all posts\n\n Let a thousand societies bloom \n\nSpecial thanks to Zachary Williamson, Afra Wang, Mark Lutter,\nBalaji Srinivasan and Primavera di Filippi for feedback and\nreview\nOne of the recurring ideological themes of the last few decades has\nbeen the idea of creating entire new communities, cultures, cities and\neven countries. Instead of having a fixed number of these, all slowly\nchanging, we can \"let a thousand\nnations bloom\" (where \"nation\" can cover the full spectrum from a\nglorified internet forum to a literal country), giving people more\nchoice and opening up space for more pluralistic independent innovation.\nInstead of your membership in one being an accident of birth, each\nperson can choose to gravitate to the communities that best fit their\nvalues.\nSome strands of this thought include:\n\nVarious attempts to make \"digital countries\", to various degrees of\nseriousness\nBalaji Srinivasan's 2022 book on \"network states\", which I\nreviewed\nThe \"coordi-nations\"\nand later \"networked nations\" movement\n\"Phyles\"\nSeasteading\n(and also on the purist end, Liberland and Sealand)\nThe Charter Cities\nInstitute (see also: my own thinking about crypto\ncities)\nAttempts by existing nations to \"renovate\" themselves, such as Estonian\ne-residency, and more recently on a bigger scale, Bhutan's Gelephu Mindfulness City\nSimilarly-themed projects from earlier generations, eg. Freetown\nChristiania and Walt Disney's city EPCOT\n\nThese ideas are diverse. Some of them are explicitly about getting as\nmuch legal autonomy as possible, and using that platform to create new\nlaws from the ground up. Others value a more gradualist approach, and a\nmore long-term closer connection to existing groups and institutions\nrather than re-building everything from zero. Some focus on countries,\nothers on cities, and others on cultures. Some are more left-leaning in\nideology, others are more right-leaning. In many ways, it's like where\nthe crypto space was five to ten years ago.\n\nLeft: magic internet money. Right: magic internet\nsociety.\n\nIn 2023, seeing all of these ideas mature inspired me to run Zuzalu,\nan experimental \"popup city\" in Montenegro: bring ~200 people, from\nmultiple communities - Ethereum, longevity, rationalism, AI - together\nin one place for two months, and see what happens. Zuzalu succeeded as\nan experiment, and in my visits to various other \"new city\" projects I\noften heard the feedback that it inspired them to take culture and\ncommunity building more seriously. But the experiment left unanswered a\nkey question: what happens next?\nIn this post, I give my updated picture of this space. I will first\nreview what I think we have learned since 2023, when the space moved\nfrom vibes and whitepapers to real-world experimentation. I will then\nsketch out a concrete world that this movement could be driving towards,\nwhat new types of entities will emerge, and what concrete value they can\nprovide.\nTable of contents\n\nWhat have we learned from Zuzalu?\nTribes\n\nWhat is culture, and how should it evolve?\nTribes as innovators in culture\nHubs\n\nZones\n\nWhy would countries want to host zones?\nWhat are examples of policies zones could try?\n\nDo urbanism right\nLet people in\nVouching as general-purpose substitute for\nregulation\nCrazy democracy ideas\nCrazy urban governance ideas\n\nBounding the risks\n\nShould zones and tribes cooperate?\nThe Archipelago\n\nWhat have we learned from\nZuzalu?\n\nZuzalu, 2023\n\nZuzalu in 2023 was an experiment: bring ~200 people, from multiple\ncommunities -Ethereum, longevity, rationalism, AI - together in one\nplace for two months, and see what happens. This was the first time\nsomething like this had happened in this way - almost all events are\neither much smaller in scale, much shorter, or both - and the closest\nother historical examples are in spheres far removed from the kind of\nfrontier technology that Zuzalu was built around.\nI enjoyed my experience at Zuzalu - though sometimes the\nsocialization did get to the point where it was too much for me. I\nlearned a lot about different people's interests, and got to know many\nwarm and friendly and interesting people. There are a lot of \"little\nthings\" that we learned about how to organize a popup well. For\nexample:\n\n200 people (roughly Dunbar's\nnumber) is an excellent size for a popup. Unlike hacker\nhouses or even 40-person popups, it's a size large enough that we got to\nsee subcultures within Zuzalu. There were the Ethereum\nresearchers, the longevity enthusiasts, people doing intellectual\nsalons, people cooking Chinese hotpot and singing karaoke, the fitness\ncrew doing runs, saunas and cold plunges (I ended up being some of all\nfive). This made the community interesting and enjoyable to stay in for\ntwo whole months in a way that would not have been possible if it were\nhomogeneous.\n1-2 months is an excellent duration for a popup.\nThe reason is that the duration affects the attitude that people have:\na week is a break from your life, two months is your\nlife. A two-month duration makes it impossible to have high\nintensity of activities the whole time, and makes it possible to truly\nget to know people, and to form the kinds of sub-communities that make\nthe popup interesting. So it's a much better trial for building an\nactual new city.\nYou want to have \"content\" (activities, presentations,\neducational events...), but you don't want the amount of content to\noverflow. What you want is \"a college at 25% intensity\": enough\nto stimulate people, but not enough to tire people out. Many popups I've\nbeen to were too much on the side of tiring me out. I recommend having\nexplicitly agreed hour ranges and days where events do not happen.\n\nAfter the original Zuzalu in Montenegro, we kept going organizing\n\"popups\", and it feels like popups seem to have found \"product market\nfit\" within their niche. One of the Zu spinoffs, Edge City, has perfected a\npipeline of organizing them, and I have heard that they are at this\npoint a cash-flow-positive business. And popups - like-minded people\nliving together for medium durations - have proven themselves as a\nstepping stone toward a more full-fledged community.\n\nA panel on cryptography at ZuConnect and the ZuSocial hacker\nhouse, Istanbul 2023.\n\nIt also became abundantly clear that there are limits to what popups\ncan do:\n\nPopups are expensive: short-term rental is always\nmore expensive than long term, and you easily get ripped off negotiating\nin a new location for the first time. Edge City is not cheap to\nattend.\nIt's difficult to truly have depth when\ncustomizing. ShanhaiWoo is one of the \"Zu spinoffs\" that\nimpresses me deeply because it actually tries to create a culturally\nunique immersive environment, making its physical zones \"feel like\nShanhaiWoo\". But when it's only in one place for 40 days, the best that\nit can do is often paper and cardboard.\nBringing that many people together is hard. The\nmost sustainable approach that I have discovered is what we did in\nChiang Mai, where 5-10 popups, each independently bringing 30-300\npeople, co-located in the same city around the same time.\nInvolving locals in a non-superficial way is hard.\nA common goal that people doing popups have is to involve local people\nfrom the region, in a way deeper than buying food and rent from them\n(though I would argue even buying food and rent can be a meaningful\ncontribution to an economy, especially if you come during off-peak\nseason, as the original Zuzalu did, so you're stabilizing load rather\nthan overcrowding it). But involving locals non-superficially is hard:\nif you have a niche interest that only a few people care about, and\nyou're in a country with 1-5 million people, the intersection will be\nvery tiny. Realistically, my main conclusions so far are (i) reach out\nto diasporas of the country, and not just already-in-country locals, and\n(ii) effective local community building requires coming back to a place\nfor years, and not just doing a one-off.\n\nAnother pattern I have noticed is that two things core to the\nearly ideology often fall away over time: novel governance designs, and\na search for legal autonomy. Within the context of popups, this\nmakes total sense. If a popup is short-duration, then \"forking as\ngovernance\" works perfectly fine. Each popup can be run by a founder or\ncore team, and if anyone is unhappy, they can make their own version and\ntry to attract people over. The longevity-focused Zu spinoff Vitalia\nalready split\ninto two forks. And if a popup only lasts 30 days, then there is not\nmuch interesting that could be done that would benefit from legal\ninnovation.\nAs a result of all this, I have noticed a worrying pattern: over\ntime, popups would get shorter in duration, smaller in scope, and more\ngeneric in substance, to the point where in the limit they approach\nbeing simply a few more conferences and hackerspaces. Outside the\nZuzalu-verse, I saw Praxis aspiring to big\ndreams of a new Mediterranean renaissance, but in practice mostly\ndelivering parties in upscale cities in the United States. (Since then,\nthey seem to have switched\nto pursuing the American military dynamism topic)\nFor all of these reasons, I have started advocating for\nZuzalu-inspired communities to start having permanent nodes. There\nalready are a few: Frontier\nTower, Crecimiento, and\n4seas' two nodes (one city, one\nmountain) in Chiang Mai, with others under construction\n(additionally, of course, there is Balaji's Network School). But even with these, in the\nback of my mind I always fear the \"regression to the mean\" that they\nwill turn into glorified coworkingspaces, and lose all of their cultural\nor experimental interestingness. Making sure that this does not happen\nis an ongoing challenge, and indeed it is a primary goal of this post to\npaint a clearer picture of what alternative future these projects could\nbe driving toward.\nNow, let's get into actually explaining what I think this future can\nbe.\n\nTribes\n\nThe 4seas mountain venue features flags of many of the\ncommunities that it sees itself as connected with: Bitcoin,\nEthereum, Plancker, 706\n\nOne common critique of modern society is that it is at the same time\natomistic and authoritarian: there is a lack of intermediate\ninstitutions, in between individuals and states, that give people needed\nservices and community. In the critics' story, this makes society:\n\nLack a feeling of community, become uncaring, and fail to provide\npublic goods that are too local or group-specific for states to\nnotice\nBecome homogeneous - \"glass and steel skyscrapers with Starbucks\neverywhere\"\nBecome vulnerable to takeover by dictators\n\nAll three problems stem from the fact that we have too much of a\ntwo-level structure: individuals, very powerful large-scale actors like\nstates, and nothing else.\nHistorically, these \"intermediate institutions\" included local\ngovernments, clubs, churches, small businesses and various other\nassociations. Today, we still have many of those, but they are\ninherently local in scale, and so they are failing to capture the most\nmeaningful communities today, which are increasingly continental and\nglobal. We have corporations, including very big corporations, and we\nalso have social media. But these are impersonal, homogenizing forces:\nthe profit motive drives them to appeal to as many people as possible,\nreducing their diversity and uniqueness toward zero. Startups are small\nand diverse, but according to the\nstandard playbook, encouraged by venture-capital profit motives, a\nstartup is a group of people attempting to become a new megacorporation,\nnot some reliable third sector of society.\nSo what would a successful \"intermediate institution\" of this type,\nadapted for the needs of the 21ˢᵗ century, look like? I will propose my\nanswer. It needs to be some kind of neo-tribe or other\ninstitution that focuses, and meaningfully innovates, on the thing that\nhumans do that isn't generic: culture.\n\nWhat is culture, and\nhow should it evolve?\n\nLeft: gym at Balaji's Network\nSchool. Right: Town hall at ShanhaiWoo Chiang\nMai.\n\nThe Wiktionary\ndefinition of \"culture\" begins as follows:\n\nThe arts,\ncustoms, lifestyles,\nbackground\nand habits\nthat characterize\nhumankind,\nor a particular society or nation.\nThe beliefs, values, behaviour\nand material objects that constitute a people's way of life.\nThe conventional conducts and ideologies of a community; the system\ncomprising the accepted norms and values of a society.\n\nIn short, culture is the patterns of human behavior in a particular\ncommunity. It covers everything from the food you eat, the language you\nspeak, dance, music, architecture, to much \"deeper\" things like how\npeople conceive the stories of their own lives, their relationships with\ntheir families, business, politics, and how people resolve conflicts in\nall of these spheres.\nMany people make the mistake of thinking culture is something that\ncan be explicitly laid down by mission statements and top-down edicts.\nLet's take, for example, the corporate culture of Enron (explanation for\nyounger readers: Enron was the FTX of your parents'\nera).\n\nOn paper, Enron valued \"integrity, communication, respect and\nexcellence\". In practice, Enron clearly valued some very different\nthings. But this is only the most egregious example; the inevitable wide\ndivergence between \"organizational culture\" written on paper and an\norganization's culture in practice is very easy to see anywhere.\nAnother problem with top-down attempts to shape culture, especially\nmore coercive ones, is that the whole strategy has very low galaxy-brain\nresistance. While declaring top-down \"the culture I wrote down in\nthis document is better than what you have now, so I will impose it\" may\nat times be the right thing to do (see: the anti-smoking push,\nfederally-driven anti-segregation\nin the 1960s USA, etc), the problem is that it's too easy for\nsomeone to get convinced that their own culture, as they understand it,\nis great, and then use it as an excuse to dominate others.\nOn the other hand, many people make the mistake of over-identifying\nculture with the purely aesthetic, subjective and\ngroup-identity-oriented parts of culture: food, music, dance, dress,\narchitecture styles, and ignore the parts that are functional, whose\nsuccess or failure drives the success and failure of civilizations. This\ncan lead to an over-egalitarian and stagnant \"culture as museum\"\nmentality: every culture is equally as good as every other culture\nbecause aesthetics are ultimately subjective, and so there is no such\nthing as cultural improvement - instead, the only goal is\npreservation.\nThat is the sort of thing that Thomas Sowell rails\nagainst:\n\nCultures are not museum pieces. They are the working machinery of\neveryday life. Unlike objects of aesthetic contemplation, working\nmachinery is judged by how well it works, compared to the\nalternatives.\n\nCultures are there to serve their people, not touristic onlookers\nappreciating their existence from far away. Some cultures do this much\nbetter than others, and all cultures could do much better still. There\nare just too many examples of traditional culture being pathological\n(here's the latest\nI just happened to see while writing this) for preservation to be\nthe only goal. And even if it were not, technology - growing wealth,\ndigital communications, birth control, education, the list goes on - has\nchanged the world so much that any lessons from our collective memory in\nthe past millennium need to be radically adapted to be relevant in the\nnext.\nOn the third hand, some make the mistake of acknowledging that\nculture is functional, but over-emphasizing very small-scale\nindividual decisions as a vehicle of change. This is what Scott\nAlexander calls \"universal\nculture\":\n\nUniversal culture is the collection of the most competitive ideas and\nproducts. Coca-Cola spreads because it tastes better than whatever\npeople were drinking before. Egalitarian gender norms spread because\nthey're more popular and likeable than their predecessors. If there was\nsomething that outcompeted Coca-Cola, then that would be the official\nsoda of universal culture and Coca-Cola would be consigned to the\nscrapheap of history.\n\nInstead of keeping culture the way it is, or reforming it from the\ntop down, why not embrace the wisdom of accumulated individual choice\nand freedom?\nHere is how I would argue the case against an overly purist version\nof this approach. There are many things that require \"immersion\" to\nsucceed: lifestyle habits, local public goods such as air quality, work\nhabits, lifetime learning habits, limitations on use of technology, etc.\nDoing anything truly interesting and unique requires \"depth\", and\nsubstantial collective investment and effort to create an entire\nenvironment oriented around better serving those needs. These things\ncannot easily be done by an individual, or even by a corporation,\nbecause corporations face too much pressure to \"meet users where they\nare\" - and so we get everyone drinking Coca Cola (or getting addicted to\noutrage-driven social media, or ...)\n\nAs we see clearly with architecture styles (but happens in every\nsphere), relying too much on market incentives leads to global\nmonoculture.\n\nSo what's going on here? And if we want to avoid these three\npitfalls, what might cultural evolution done well look like?\nThe social philosopher Charles\nTaylor talks about culture as being underpinned by moral\norders and social imaginaries. Taylor defines\na \"social imaginary\" as:\n\nthe ways in which [people] imagine their social existence, how they\nfit together with others, how things go on between them and their\nfellows, the expectations which are normally met, and the deeper\nnormative notions and images which underlie these expectations\n\nFor example:\n\nTake our practice of choosing governments through general elections ...\nEssential to our understanding what is involved in this kind of\nmacro-decision is our ability to identify what would constitute a foul:\ncertain kinds of influence, buying votes, threats, and the like. This\nkind of macro-decision has, in other words, to meet certain norms, if it\nis to be what it is meant to be ... And beyond the ideal stands some\nnotion of a moral or metaphysical order, in the context of which the\nnorms and ideals make sense.\n\nAn important point that Taylor makes is that social imaginaries are\noften transformed when \"what start off as theories held by a few people\nmay come to infiltrate the social imaginary, first of elites perhaps,\nand then of the whole society\". Taylor talks at length about how modern\nEuropean liberal democratic norms emerged in the 17ᵗʰ century as a\nresult of this process transforming the European \"moral order\". However,\nTaylor cautions, this process of transformation is\norganic and complicated:\n\nWhat exactly is involved when a theory penetrates and transforms the\nsocial imaginary? For the most part, people take up, improvise, or are\ninducted into new practices. These are made sense of by the new outlook,\nthe one first articulated in the theory; this outlook is the context\nthat gives sense to the practices ... But this process isn't just one\nsides, a theory making over a social imaginary. In coming to make sense\nof the action the theory is glossed, as it were, given a particular\nshape as the context of these practices ... Nor need the process end here.\nThe new practice, with the implicit understanding it generates, can be\nthe basis for modifications of theory, which in turn can inflect\npractice, and so on.\n\nIn short, culture is a big complicated blob where actions,\nconsequences, statements by leaders and theories by intellectuals all\ninfluence each other in every direction. If a culture\nofficially says to do one thing, but actually people\ndo something else, then the latter is more decisive. Culture is\nshaped by incentives, but then incentives are themselves implemented by\npeople, who are guided by culture. Culture is housed in a community,\nwhich is held together because people feel affinity for each other, and\nthat affinity is itself shaped by shared rituals.\nI remember experiencing some of this (ok fine, the solitary parts of\nthis) myself with my experiences as a teenager attempting to build constructed\nlanguages - like Esperanto, but\nbetter. I easily recognized how English is pathological with its horribly broken and irregular\nspelling system (and many other issues), and how centuries of\norganic evolution has only made the problem worse. But when I tried to\ncreate an \"ideal language\" from scratch, I ended up creating something\nthat can make beautiful logical and compact sentences in the specific\ncases I designed it around, but which takes three times longer than\nEnglish to express any other thought that I needed to express in\neveryday life.\nThis shows why all three of the above approaches to culture are\ninsufficient:\n\nTop-down culture fails because it ignores the\nbottom-up side. It acknowledges the intellectuals and their theories,\nbut not the parts of culture bring its members together, and integrates\nthe theories to people's actions\nCultural traditionalism fails because it ignores\nthat culture needs to change and improve at all\nCultural individualism (and incrementalism\ngenerally) fails because it only sees the bottom-up side, and\nit ignores the need for large, structured paradigm shifts to get out of\nbad local equilibria\n\nNotice how \"top-down culture\", \"cultural traditionalism\" and\n\"cultural individualism\" map really nicely to the three corners of\n\"the\nd/acc triangle\", which also argues that all three are\ninsufficient and we need to do something else.\n\nTribes as innovators in\nculture\nAnd so I think we need a different path. What we want is a\nbetter \"world game\" for cultural evolution: an environment\nwhere cultures improve and compete, but not on the basis of violent\nforce, and also not exclusively on low-level forms of memetic\nfitness (eg. virality of individual posts on social media,\nmoment-by-moment enjoyment and convenience), but rather on some kind of\nfair playing field that creates sufficient space to showcase the\nlonger-term benefits that a thriving culture provides.\nOne early modern version of this idea is the notion of\n\"prefigurational cultures\". A seminal work is Margaret\nMead's Culture and Commitment from 1970:\n\nIn the past, in configurational cultures, the elderly were gradually\ncut off from limiting the future of their children. Now, as I see it,\nthe development of prefigurational cultures will depend on the existence\nof a continuing dialogue in which the young, free to act on their own\ninitiative, can lead their elders in the direction of the unknown.\n\nWhat might a prefigurational culture in the real world look like?\nHere, there are many possible different answers. To show one end of the\nspectrum, let me re-paste Balaji's example from years ago:\n\nKeto Kosher, the sugar-free society\nStart with a history of the horrible USDA Food Pyramid, the\ngrain-heavy monstrosity that gave cover to the corporate sugarification\nof the globe and the obesity epidemic. ... Organize a community online\nthat crowdfunds properties around the world, like apartment buildings\nand gyms, and perhaps eventually even culdesacs and small towns. You\nmight take an extreme sugar teeotaler approach, literally banning\nprocessed foods and sugar at the border, thereby implementing a kind of\n\"Keto Kosher\".\nYou can imagine variants of this startup society that are like\n\"Carnivory Communities\" or \"Paleo People\". These would be competing\nstartup societies in the same broad area, iterations on a theme. If\nsuccessful, such a society might not stop at sugar. It could get into\nsetting cultural defaults for fitness and exercise. Or perhaps it could\nbulk purchase continuous glucose meters for all members, or orders of\nmetformin.\n\nBut cultural innovation does not have to be \"legible\" in the way that\nKeto Kosher is. In fact, as we have seen, over-indexing on legibility\nand on explicit ideology often leads to problems. Cultural innovation\nworks better when it arises out of a collection of habits, attitudes and\ngoals that are shared by a particular group, and adapted to the group's\nneeds. The group's goal might be realistically a 50/50 mix of being\n\"about a set of values\" and being \"about the group\" - it's not\nattempting to expand to unlimited size, rather, it's a group of people\nwith shared history and shared identity trying to do their thing and\nmake the best of it.\nThe Zuzalu-verse is actually one of the better proto-examples of\nthis. It is organized around a particular set of values: the \"Ethereum\ncanon\" of open source, freedom, decentralization and a positive-sum\nattitude toward humanity, idealistic hacker culture, concern about\nhealth, etc. The Zuzalu identity is demonstrably not universal. Many\npeople who frequent the Zuzalu-verse reported finding themselves out of\nplace at Network School, which is organized around principles that are\nsimilar on paper, but very different in their \"vibes\" - and undoubtedly\nothers feel the same way in the other direction. But there isn't a fixed\n\"One\nCommandment\", or even any specific written-down mission and vision\nstatement. Aspects of it could be described as \"Keto Kosher but for\neducation\", attempting to integrate constant learning into week-by-week\nlife (a very important thing for us to get right in the 21ˢᵗ century!),\nbut even this is done in a very organic style. Just as much as the\ngoals, the community is organized around its people.\nEventually, I also expect tribes to get back to innovating in\ngovernance: using a combination of culture and technological\nmeans (blockchains, LLMs, ZK...) to have better collective conversation\nand decision-making. Currently, this part of the space is in somewhat of\na \"trough of disillusionment\", as we have realized the downfalls of\nformalizing governance too early. However, I would argue that we have\nnot yet properly tried to integrate AI and ZK tech into voting\nprocesses, which could solve their two biggest problems: attention\noverload and fatigue, and collapse into social games where people vote\nbased on how their vote will be perceived (if not outright bribery),\nrather than their genuine convictions. I expect this to pick back up at\nsome point, as it will be necessary for tribes to be long-term\nsustainable without having the same pitfalls as corporations. I also\nthink tribes may be a better ground for this kind of governance\nexperimentation than eg. blockchain-based DAOs, because tribes'\ncapabilities and needs are more complex.\n\nHubs\n\n4seas Nimman in Chiang Mai. Visibly a \"regen\" space, visibly an\n\"Ethereum-ish\" space, visibly not your average cowork.\n\nTruly instantiating a culture with any level of depth requires not\njust talking about the culture's themes, but actually\nliving them. This requires deep immersion,\ninstantiating the culture's values and aesthetics and practices at a\nlevel that goes far beyond a few decorations and posters. For\nexample:\n\nIf the community values health, have a restaurant that serves\nhealthier versions of major cuisines\nIf the community values infrastructure sustainability and\nresilience, then the node could have an actual local farm, solar panels,\nbatteries, etc built in.\nIf a community values open source and security, then the node can be\ndone with not just open source software, but also open\nand verifiable hardware.\nIf a community values collective activities, it needs rooms capable\nof fitting them (this one is actually surprisingly nontrivial)\nIf the community values a particular aesthetic, the structures could\nbe built with that aesthetic in mind. (A middle ground is to have mobile\nstructures, like\nthese)\n\nThis is all why I think it is a critical part of digital tribes to\nhave long-lasting physical spaces. Physical spaces allow a culture's\nvalues and habits to be instantiated in a much deeper way.\nThe good news about a hub is that you need a surprisingly small size\nto be viable. If a hub is located inside a city, they can be arbitrarily\nsmall, because residents can take advantage of the surrounding\ninfrastructure of a city. If a hub is located outside a city, then it's\nbasically building a new city. But even here, there is good news. For a\nconventional city to play a significant role at the frontier of\nanything, you need to have a population of at least a million; that is\nthe level at which it's possible to have effective network effects\nwithin any particular niche. But if you are specialized to one or a few\nniches (I think a novel combination of a few niches is better than being\noverly focused on one), the minimum size is much smaller. Here are some\nexamples of viable cities I've visited that are quite small:\n\nLongyearbyen\n(northernmost significant settlement in the world): 2,600 people\nUniversity towns: often 30,000 (eg. Ithaca, NY) to\n150,000 (eg. New\nHaven, Cambridge)\nSki towns, surf towns and other sport-specific\ntowns: often 1,000 to 10,000\n\n2,600 is a great size: Longyearbyen is able to sustain ~10\nrestaurants, an airport, a hospital and a school (2,600 total ~= 26 per\nyear of age).\nBut 100 people is probably not enough. I recently visited Prospera in\nHonduras (population ~100), and while the physical venue was beautiful,\nsurprisingly strong on cultural uniqueness, and even strong on\nengagement with locals (a Honduran was on the core leadership team, many\nwere in the core community, and at least one of the medical businesses\nwas run by Hondurans), the place I was staying had one restaurant with\nlimited food options and no other amenities within walking distance.\nHence I think one or two further steps of growth and maturity beyond the\n100-person level is ideal.\nI expect getting hubs right to be the next important step for these\nkinds of \"tribes\" to succeed, and an important training ground for them\nto figure out culture, governance and other issues at a much deeper\nlevel.\n\nZones\n\nFrom top left to bottom right: (i) the micronation Liberland,\n(ii) Prospera,\na zone in Honduras, (iii) artist's drawing of the\nunder-construction California\nForever, (iv) artist's drawing of Bhutan's\ngovernment-initiated under-construction Gelephu Mindfulness City. All\nare what I call \"zones\", but represent very different points on the\nspectrum of engagement with governments.\n\nSo far, we have talked about innovating in culture. The more\nradical part of the free cities and network states space started by\nasking a different question: how do we get more innovation in\nrules - that is, the regulations, laws, and political systems\nthat govern the physical spaces that we are in?\nIn my observation, there are three schools of thought here:\n\nLibertarians are primarily interested in a specific\nthing: freedom, the ability to be in a corner and peacefully do their\nown thing, whether in terms of lifestyle or technology development. They\nare willing to pay the price of smaller size and greater distance from\nglobal network effects - a price that is significant, and in fact a key\nreason why I do not share many people's worries about their\nprojects.\nDevelopmentalists want to apply proven means to\nimprove economic prosperity, and look at Shenzhen\n(sometimes, I would argue, they focus on Shenzhen too much) as an\nexample.\nSocial technologists view governance as a social\ntechnology, and want to see more experimentation and improvement in that\ntechnology. They value development, but are more focused on developing\nnew techniques, rather than scaling already well-known techniques.\n\nOne\nview of a social technology perspective on\ngovernance.\n\nOften, the three perspectives merge. Some social technologists are\ninterested in governance ideas in a libertarian-ish direction, because\nthey see ideal forms of governance is being precisely those forms that\ntry to align incentives and beyond that point minimize arbitrary\nconstraints. Some libertarians believe in freedom because they see it as\ncritical for economic development.\n\nMy attempt at creating a political compass of some of the\nprojects I am more familiar with.\n\nWhy would countries want\nto host zones?\nBasically, for a country, it's a way of participating in the rapid\nand accelerating economic and technological revolution of the 21ˢᵗ\ncentury. In particular, it lets you go beyond tourism, which imports\nindividuals but not the networks between those\nindividuals, and instead actually import parts of the networks\nthemselves, opening up the opportunity to capture a larger share of the\nvalue.\nQuoting\nNoah Smith:\n\nUnder British rule, and then for the first two decades of Chinese\nrule, Hong Kong served as a crucial entrepot — the\nworld's gateway to China. It facilitated the inflow of foreign capital,\nwhich was absolutely crucial to China's early industrialization. It was\na major hub for goods to move into and out of China. It provided\nservices for foreigners to do business on the mainland. And it imported\nforeign know-how into China, teaching locals how to build high-quality\ninfrastructure, set up factories, and do business overseas.\nSo I thought about Hong Kong, and wondered: What if every\ncountry had a quasi-independent city like that?\nImagine a Hong Kong in India. A Hong Kong or two in Europe. A Hong\nKong in Brazil, Japan, Indonesia, the United States, and so on. Each\ncity would formally be a part of the host country, subject to the laws\nand authority of the central government there. But in practice, each\ncity would be granted a degree of autonomy.\n\nThis sounds like social science fiction, but Bhutan's Gelephu Mindfulness City is an attempt to do\npretty much exactly this. The problem that GMC is trying to solve is, as\ndescribed to me by the Bhutan government, is twofold:\n\nGive Bhutan a foothold in globalized techno-modernity, and help it\nget the economic benefits (including giving Bhutanese themselves better\nopportunities staying in Bhutan)\nDo so in a way that minimizes risks to the existing culture\n\nBasically, let the expats come and the thirty-storey towers go up, at\nleast in one corner of the country along the border with India, but\ndon't let the next generation of the whole country get hooked on Coca\nCola.\nIncidentally, this is all why I am expecting \"zones\" to be the bulk\nof the future of jurisdictional innovation, and not new \"countries\".\nCountries are very unwilling to literally give up their sovereignty over\neven small patches of their land. Liberland has found a hack: take over\none of the very small pieces of land that, by pure accident of how the\nlines were drawn, no country claims as its own. But there are\nnot many opportunities like that, and even that is far\nfrom a guarantee of safety. To really have a country, you\nhave to either get approval from your new neighbors, or figure out your\nown military. Zones, on the other hand, are much more palatable for\npoliticians, and also enable a government to actually get ongoing upside\nin the networks that it attracts, rather than just a one-time deal (eg.\nProspera pays 12% of its tax revenue to the government of Honduras).\n\nWhat are examples\nof policies zones could try?\nI will give a few examples that I personally find interesting, on a\nscale from \"boring\" to \"experimental\".\n\nDo urbanism right\n\nImage from Culdesac\nTempe\n\nIn many developed countries, a major challenge is that housing\nconstruction is very difficult for legal reasons. Some have estimated\nthat fixing this could make cities much more affordable, and improve\nGDP by as much as 36%. But changing laws in an existing city is\nhard, in large part because of existing stakeholders. So what if you can\ncreate a new city?\nThis is a big part of the\npitch for California\nForever. The other part of the pitch is all the other problems that\nurban economists have consistently railed about for decades. One that\nCalifornia Forever, and others like Culdesac, focus on is walkability (and\nbikeability). A third is attracting business including heavy industry\nthat people can work in. A fourth and more experimental option is\nfriendliness to new technologies (eg. drone delivery). There is a whole\nlist of ideas that policy thinkers have basically agreed on for decades,\nthat many are frustrated that they cannot implement in existing cities\nbecause things are hard to change. With a new city, you can - and it\nonly requires city-level autonomy, which is in many places quite easy to\nget, and not anything national-scale.\n\nLet people in\n\nLeft: where a Singaporean can go (for short-term visit) without a\nvisa. Right: where an Indian can go without a visa.\n\nOne problem that many people have in the 21ˢᵗ century: where do you\ngo to live? Whether it's because of lack of economic opportunity,\npolitical instability, a culture unforgiving to people who are\ndifferent, or a government unfriendly to their business aspirations or\neven their way of life (or, for the luckier among us, a simple thirst\nfor adventure), for many people around the world, the country of their\nbirth does not suit them.\nAttracting these people is a massive economic opportunity. Many\ncountries around the world are becoming more restrictive (or even\nhostile) to both long-term and short-term immigration, but the number of\npeople who need more options for where to be is only increasing. Better\nserving such people also fosters global redistribution of\ntalent: creating a future where the most important\ntechnological and economic work is done from everywhere, and its\nproceeds more widely shared, instead of being concentrated in a few\nsuperstar cities in a few very powerful countries.\nThere is also a social technology angle to this. Many people have\nconcerns about inviting more people: the risk that they will stay longer\nthan expected and become illegal immigrants (including running to\nneighboring countries), risks related to safety, cultural\nincompatibility, etc. Today, we use \"which country are you from?\" as a\nfilter to determine who is high-risk and who is low-risk. But this is\nincredibly inefficient and unjust - it's the exact opposite of \"judging\npeople not by the color of their skin, but by the content of their\ncharacter\". In a modern digitized society, we have many kinds of filters\nto identify people who might be low-risk: work history, education,\npeople vouching for them, etc. I expect that whichever country or zone\ncreates an easy user-friendly mechanism for talented people from\neverywhere to easily be able to come (eg. to work for a local company,\nor for a conference, or for a popup) will gain a lot of benefits.\n\nVouching\nas general-purpose substitute for regulation\nOne idea that some economists like Robin Hanson support as a\nsubstitute for much of our regulation is vouching\n(aka mandatory liability insurance): you can do what you want, as\nlong as you find someone (eg. an insurance company) with enough capital\nwho agrees to pay potentially large fines and compensate any victims if\nyou create a problem.\nThis addresses a key problem with a libertarian approach to law: if\nyou only punish people when they actually create a problem, then the\ncost of the harm can easily be so great that there's no way to penalize\nsomeone enough to adequately incentivize caution. If the only regulation\non driving were that if you cause an accident you go to jail, it would\ndeter drunk driving (or driving without a license, or flying in unsafe\nversions of weird newfangled 3D aircraft) too little.\nIt also addresses a problem with the current approach of creating\napplication-specific rules for everything: the rules do not adapt well\nto new technology, and easily get corrupted and twisted into goals that\nhave nothing to do with safety, like protecting incumbent businesses.\nHere, the rules that people follow would be created by vouchers,\nincentivized by their need to balance between attracting customers and\nmanaging risks, rather than by politicians. The political lever is\nindirect, and more compatible with a free society: it sets the\nobjective, but not how you get there.\nIf successful, this is a really cool idea that could improve a lot of\nthings. But to see if it works, we have to try it somewhere, at a\nsufficient scale and level of realism. This is actually what Prospera,\nthe autonomous zone in Honduras (see website, review by\nScott Alexander) is trying to do. Currently, the experiment is still\nvery young, and there is only one insurance company (run by the zone\nitself), but this is exactly the kind of thing that a self-contained\nzone is the ideal place to try.\n\nCrazy democracy ideas\nOne of the core political challenges of the 21ˢᵗ century is how to\nimprove democracy. Here's Eliezer Yudkowsky way of stating the\nproblem:\n\nEliezer's proposed\nsolution is a new twist on liquid\ndemocracy. Approximately:\n\nEvery voter chooses a delegate. Delegates gain power if they have at\nleast 50-200 votes\nYou have two or three levels of higher-tier delegation: 50-200\ndelegates can empower a second-level delegate\nThe delegates chosen at the top of this multi-level structure are\nthe parliament\n\nAgain, this is a really cool idea: it biases for sophistication\n(because each level would end up more sophisticated than the previous)\nand guards against populism (because a delegate can't amass extreme\npower by gaining a huge following directly) but in a way that avoids\nempowering pre-selected aristocracies. But to see how well it works, we\nneed to try it somewhere.\n\nCrazy urban governance ideas\nHere I'll quote myself:\n\nAgain, you don't have to believe in this exact idea, just that there\nare things of this level of craziness that are at least worthy trying in\na serious way, somewhere.\n\nBounding the risks\nProjects building zones, especially those leaning more libertarian or\nnot initiated by governments, often get criticized - for being havens\nfor billionaires, unregulated zones where things will inevitably go very\nwrong, or for being neo-colonial. These criticisms sometimes apply to\ntribes and hubs too. I can understand the sentiment behind these\ncritiques, and I think there are important risks worth worrying about.\nHowever, I disagree with many of the stronger criticisms\n- and it is worth explaining why.\nAt heart, I am a pluralist. I believe that when different people\ndisagree about how things should be done, it's healthy to have a bias\ntoward solutions where both versions exist at least somewhere, and\npeople can freely choose between them. If a powerful (commercial or\npolitical or cultural) actor wants to see their culture or economic or\npolitical ideology implemented, the most productive and least risky\nimaginable way for them to do it is to peacefully make something\nsmall in a corner somewhere, and see how it plays out. By building a\nwhole new zone from scratch, you are taking on a huge inconvenience, and\na huge tax in terms of forgoing all kinds of network effects. And since\nyou are growing not by amassing a country-sized blog or podcast\naudience, but instead entering the real world at a much earlier stage,\nwe all gain valuable rapid feedback about whether or not the whole idea\nis crazy. This all feels like the sort of role you want\nsemi-influential radical mavericks to be playing in our society.\nWhat's the role we don't want them to play? One strategy I\ndeeply fear is what many in the so-called Silicon\nValley Tech Right have recently pivoted to: stop trying to route\naround the government, and instead just take over the government.\nThis is deeply scary: instead of corporations and the state serving as a\nhealthy check and balance against each other, the two collude against\neveryone else. It also means that ideas go straight from being\ntwelve-thousand-word screeds or five hour podcasts to running entire\ncountries.\nAnd in my experience, these two modes of action are substitutes:\npeople who start working on tribes and zones suddenly get visibly\nmore positive-sum and less interested in country\ntakeovers.\n\nLots of people on the internet lately seem to pine for a world\n(or a nation) where we force everyone to be more like Durmstrang.\nI'd rather let someone enthusiastic about that approach make the best of\nit, and have to inspire people to come voluntarily, than pontificate on\nthe internet and build up a large political movement based on how\nappealing that idea sounds written in words, with no feedback from how\nit works in reality. Long small-scale voluntary attempts at Durmstrang,\nshort Gilead.\n\nIn general, business and politics are the scariest at scale:\nmonopolizing industries, overwriting entire societies, or recklessly\nbuilding superintelligent AI (which eventually anyone will be able to\nbuild, but in any realistic universe the global centers of power will\nget to long before everyone else). Zones are the opposite of scale.\nWhatever you say about CHAZ,\nits downsides were far lower than what you would get if the\nsame people took over an entire country or even city government.\nIn an ideal world, zones can be a tool that can help countries and\nstates get more integrated into a global economy, and can give their\nbrightest people a path to frontier science and technology and business\nthat does not involve disappearing to a university and then a corporate\necosystem in a country halfway across the world. Creating opportunities\nfor frontier tech and business to happen locally instead of entirely\ndepending on powerful nations abroad can be a far more meaningful\ngain to national sovereignty than full uniformity of rules across\nthe entire country without even a few otherwise-undeveloped square\nkilometers of exceptions.\nBut achieving this outcome requires actively shaping it. I see\nopportunities for improvement here from both sides. Countries should not\nbe able to suddenly rugpull everyone in a zone if their political mood\nchanges, but they could have have levers of influence to\nencourage them to behave cooperatively, perhaps privileges defined\nnumerically that each administration can adjust up or down a medium\namount. Ideally, there would be ways to more explicitly encourage\neducation and tech transfer to local and regional talent. For\n\"developmentalist\" zones that are less radical but need to get access to\na larger local population, more limited sector-specific forms of\nautonomy is worth exploring.\nFrom a zone's perspective, this is another place where bottom-up\ndecentralized governance ideas can shine: they could help people working\non zones (or even hubs) are more able to determine what local\npopulations value and want, and try to proactively serve it, rather than\nwaiting for potential political backlash after the fact. Prospera has\nvoluntarily chosen to pay 12% of its taxes to the Honduran government,\nand passed internal laws to disallow it\nto expropriate anyone's land, but it could attempt to use newer\ntools to engage the population on a larger scale to better identify\nforms of value it could provide, and risks it should avoid.\n\nShould zones and tribes\ncooperate?\nSo far, I have told two disjoint stories. One is about smaller-scale\ncommunity-driven projects, and experimentation in culture. Another is\nabout larger-scale politics and business-driven projects, and\nexperimentation in rules.\nIt may seem like the story I am going for is that the two will\nconverge. But actually, while some \"vertically integrated\" zones that\ncombine both will exist, I predict that in general the \"market\nstructure\" will split tribes and zones into distinct categories, because\nthese are different things that require different specialties that are\ncomplementary. Figuring out legal frameworks to make it easy\nfor people from any country around the world to come to one place is one\ntype of skill. Actually building a global community is another: Edge\nCity and ShanhaiWoo have access to great technical talent, but they are\nnot constitutional lawyers.\n\nWe have already seen this \"market structure\" in the Zuzalu world:\nthere is at least a partial separation between \"hubs\", which provide\npermanent space, and \"popups\", which are communities that sometimes need\nspace for some period of time. Network School, 4seas and other nodes\nregularly host popups inside of them. I expect collaboration between\nzones and tribes (including tribes that expand to permanent hubs) to\nfollow a similar pattern.\nI argue that this strategy is ideal for countries that want to\nmaximize the success of their zone. Their goal should not just be to\nimport individuals, rather it should be to import\nnetworks. Furthermore, because most of them cannot compete with\nthe world's largest cities at creating generic networks, they\nneed to focus on more focused issue-specific networks.\nAttracting tribes, including schemes like collective visas (the\ngovernment approves the tribe, the tribe then provides its list of\n100-1000 people who automatically get admitted), can be a very effective\nway of doing this.\n\nThe archipelago\nRecently, Francis Fukuyama wrote\na post arguing that \"liberalism needs community, but it doesn't need\na ‘strong god' telling everyone what to do\". Scott Alexander wrote\na piece commenting on it. Both are good, so I'll quote Scott quoting\nFukuyama and replying at length:\n\nAccording to R. R. Reno, editor of the magazine First\nThings, the liberal project of the past three generations has\nsought to weaken the \"strong\nGods\" of populism, nationalism, and religion that were held to be\nthe drivers of the bloody conflicts of the early 20th\ncentury. Those gods are now returning, and are present in the politics\nof both the progressive left and far right—particularly the right, which\nis characterized today by demands for strong national identities or\nreligious foundations for national communities.\nHowever, there is a cogent liberal response to the charge that\nliberalism undermines community. The problem is that, just as in the\n1930s, that response has not been adequately articulated by the\ndefenders of liberalism. Liberalism is not intrinsically opposed to\ncommunity; indeed, there is a version of liberalism that encourages the\nflourishing of strong community and human virtue. That community emerges\nthrough the development of a strong and well-organized civil society,\nwhere individuals freely choose to bond with other like-minded\nindividuals to seek common ends. People are free to follow \"strong\nGods\"; the only caveat is that there is no single strong god that binds\nthe entire society together.\n\nIn other words - yes, part of the good life is participation in a\ntight-knit community with strong values. Liberalism's shared values are\ncomparatively weak, and its knitting comparatively loose. But that's no\nargument against the liberal project. Its goal isn't to become this kind\nof community itself, but to be the platform where communities like this\ncan grow up. So in a liberal democracy, Christians can have their\nchurch, Jews their synagogue, Communists their commune, and so on.\nEveryone gets the tight-knit community they want - which beats\nilliberalism, where (at most) one group gets the community they\nwant and everyone else gets persecuted.\nOn a theoretical level, this is a great answer. On a practical level\n- is it really working? Are we really a nation dotted with tight-knit\ncommunities of strong values? The average person has a church they don't\nattend and a political philosophy that mainly cashes out in Twitter\ndunks. Otherwise they just consume whatever slop the current year's\nversion of capitalism chooses to throw at them.\n\nScott then lists a few partial exceptions, and laments that they have\nnot been much more successful. His conclusion is that it's not working\nyet because we're not wealthy enough, and when we get wealthier and\nmoving people around to custom communities with custom infrastructure\nbecomes cheaper, it will happen.\nBut I also think there is something different at play: people just\nhave to get off their butts and actually create these alternative\ncultures and environments, and doing it is hard. Startups are also hard.\nBut startups have had a multi-billion-pdollar capitalist optimization\nmachine figuring out all the most optimized ways of doing them and\nrapidly growing them to scale, and turned them into cookie-cutter\nstandardized playbooks. Culture does not have the same profit motive,\nand culture is inherently not easy to scale.\n\nSome argue that NFTs solve this and make culture profitable, but\nthe fact that Zundamon's\nTheorem was not made as an NFT makes me pessimistic that\nNFT-driven culture will solve the problems that I want cultural\ninnovation to solve.\n\nA parallel problem exists for progress in economic and political\nrules, which have also stagnated under supposedly \"dynamic\" capitalist\nliberalism. The problem is that development of new and better economic\nand political rules, whether at city-scale or at country-scale,\nsimilarly does not have a strong profit motive. It definitely does not\nhave a rapid experimentation loop that startups have or even that many\n(but not all) aspects of culture have.\nI do not literally expect we are going to see a world where most\npeople live in tribes, or even zones. I definitely do not\nexpect normal people to be plotting themselves on a political compass of\n\"goldbug libertarianism\", \"hipster socialism\", \"Durmstrang-ism\",\n\"techno-Leninism\" etc, and joining whichever community is closest to\nthem on a 2D map. For most people, such grand ideologies are far from\nprimary in their lives. But I do expect a world that is somewhat more\ndynamic in both economic and political rules and in cultural dimensions,\nand that gives people more options.\nSuch a world would be a world where (i) people have more meaningful\nfreedom, both to escape persecution and to choose the kinds of\nenvironments that they truly enjoy living in, (ii) we get better\ninnovation both in economic and political rules and in culture, and\n(iii) instead of the innovation and creativity of the world being\nconcentrated in a few super-centers of global economic and political\npower, it is globally distributed everywhere across the world. This is a\nworld that I want to live in.","tokens":13458,"squid":"ink-research","role":"Deep Scholar","at":1791260590028,"hash":"99f5b09911e7273869db78fdb370de9ff2372243"}
{"url":"https://vote.optimism.io/proposals/113175971717859207366755835770332050892710441139838230871056024778447233720896","domain":"vote.optimism.io","title":"[Second vote] Security Council Electi...","text":"ProposalsVotersConnect  Wallet Approval Vote Proposal by The Optimism Foundation[Second vote] Security Council Elections Cohort B MembersProposal Visualization Executed Transactions // Alex SotoReveal 7 more optionsFollowing the guidelines of the Security Council Charter, the Token House will hold elections for Cohort B of the Optimism Security Council. The top 6 candidates with the highest votes will be elected to Cohort B and serve a 12-month term, subject to Foundation confirmation. If any candidate is not confirmed by the Foundation, the runner up will take their position.\nThis vote will utilize approval voting, allowing delegates to vote for any number of nominees. In approval or ranked choice votes, delegates may vote for themselves as long as they also cast votes for the remaining elected positions. All candidates that received delegate approvals are eligible in this election as shown below.\n\nAlex Soto\nMatthew Slipper\nINK Foundation\ndonnoh\nOP Labs\nMaster Mojo\nTest in Prod\ndcbuilder.eth\n\nIt's important to note that no more than 1 elected member may be associated with a particular entity, or that entity’s employees or affiliates.\nThe Foundation has updated the votable supply calculation to better reflect active governance participation. Voting power from the top 50 delegates who have never participated in a governance vote and who received their delegations more than three voting cycles ago has been excluded from the votable supply calculation. This adjustment only affects the computed quorum, the quorum threshold remains the same (30%.) It does not remove any delegate’s ability to vote, change candidate eligibility, or otherwise affect how votes are countedResultsVotes INK Foundation14,521,400 74.19% donnoh13,042,959 66.63% OP Labs12,985,137 66.34% Matthew Slipper12,722,367 64.99% Test in Prod10,313,750 52.69% dcbuilder.eth10,027,245 51.22% Alex Soto6,375,089 32.57% Master Mojo1,570,041 8.02% Quorum 13,540,389 Current 19,573,162 EXECUTEDExecuted 1:24 am Jun 14, 2026In this top-choices style proposal, the top 6 options will be executed. Voters can select up to 8 options. If the quorum is not met, no options will be executed.[Second vote] Security Council Electi...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":576,"squid":"ink-governance","role":"Council Listener","at":1791260593908,"hash":"e842a0c7e3ceda4a368b149ab25cc5a0964ef632"}
{"url":"https://io.net/docs/guides/workers/earnings-rewards","domain":"io.net","title":"Earnings & Rewards - io.net","text":"​Earnings and Rewards Tab\nTo access the Earnings and Rewards tab, go to IO Worker and click the Earnings & Rewards tab in the upper-left corner.\n\n​Rewards and Jobs\n\nEarnings from Block Rewards in $IO coins\nEarnings from Jobs in $IO coins\nTotal time your workers were active.\nNumber of jobs processed by your workers.\n\n​Daily Block Rewards\nThe graph displays your daily earnings in $IO coins from Block Rewards. Below the graph, you can see:\n\nTotal Blocks Earned\nTotal Blocks Failed\n\n​Daily Earnings\nIn the top-right corner of the chart, you can switch to the Earnings chart. This graph displays your daily earnings in $IO coins from common jobs performed by your workers. Below the graph, you can find:\n\nTotal Compute Hours Served\nEarned vs. Slashed\nTotal Compute Jobs\n\n​Clusters\nThe list shows the clusters your workers are part of and provides detailed earnings information, including:\n\nEarnings in $IO coins\nProjected Max Earnings\nTotal Slashed\n\nClick on a specific cluster to view its details. You can also search by Cluster ID to find information for that cluster.\n\n​Job Payments\nImportant: If the job is completed within a day, payment is made immediately. For jobs that last multiple days, payment is made at the end of each day. A few points:\n\nIf your Worker participated in a job and remained available throughout, it will receive payment.\nIf the Worker was unavailable during the cluster process, it will not receive payment for the whole time.\nIf the Worker stops within the first hour of connection, no payment will be made for that time.\n\nYou can search for a transaction by entering the Job ID number and filter transactions by date within any permitted period. Clicking on a specific transaction will open a page with detailed information about it.\n\n​View Transactions\nThe transaction page shows: Amount and type of currency received\n\nTransaction type\nPlatform used\nStatus\nDate\nTransaction ID\n\nWas this page helpful?","tokens":483,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260599793,"hash":"eb0ed81204034d486922c179d121f7bdad28cdfc"}
{"url":"https://vitalik.eth.limo/general/2022/07/13/networkstates.html","domain":"vitalik.eth.limo","title":"What do I think about network states?","text":"Dark Mode Toggle\n\n What do I think about network states? \n 2022 Jul 13 \nSee all posts\n\n What do I think about network states? \n\nOn July 4, Balaji Srinivasan released the first version of his\nlong-awaited new book describing his vision for \"network\nstates\": communities organized around a particular vision of\nhow to run their own society that start off as online clubs, but then\nbuild up more and more of a presence over time and eventually become\nlarge enough to seek political autonomy or even diplomatic\nrecognition.\nNetwork states can be viewed as an attempt at an ideological\nsuccessor to libertarianism: Balaji repeatedly praises The\nSovereign Individual (see my mini-review here)\nas important reading and inspiration, but also departs from its thinking\nin key ways, centering in his new work many non-individualistic and\nnon-monetary aspects of social relations like morals and community.\nNetwork states can also be viewed as an attempt to sketch out a possible\nbroader political narrative for the crypto space. Rather than staying in\ntheir own corner of the internet disconnected from the wider world,\nblockchains could serve as a centerpiece for a new way of organizing\nlarge chunks of human society.\nThese are high promises. Can network states live up to them? Do\nnetwork states actually provide enough benefits to be worth getting\nexcited about? Regardless of the merits of network states, does it\nactually make sense to tie the idea together with blockchains and\ncryptocurrency? And on the other hand, is there anything crucially\nimportant that this vision of the world misses? This post represents my\nattempt to try to understand these questions.\nTable of contents\n\nWhat is a network state?\nSo what\nkinds of network states could we build?\nWhat is\nBalaji's megapolitical case for network states?\nDo\nyou have to like Balaji's megapolitics to like network states?\nWhat\ndoes cryptocurrency have to do with network states?\nWhat aspects of\nBalaji's vision do I like?\nWhat\naspects of Balaji's vision do I take issue with?\nNon-Balajian network\nstates\nIs there a middle way?\n\nWhat is a network state?\nBalaji helpfully gives multiple short definitions of what a network\nstate is. First, his definition in one sentence:\n\nA network state is a highly aligned online community with a capacity\nfor collective action that crowdfunds territory around the world and\neventually gains diplomatic recognition from pre-existing states.\n\nThis so far seems uncontroversial. Create a new internet community\nonline, once it grows big enough materialize it offline, and eventually\ntry to negotiate for some kind of status. Someone of almost any\npolitical ideology could find some form of network state under\nthis definition that they could get behind. But now, we get to his\ndefinition in a longer sentence:\n\nA network state is a social network with a moral innovation, a sense\nof national consciousness, a recognized founder, a capacity for\ncollective action, an in-person level of civility, an integrated\ncryptocurrency, a consensual government limited by a social smart\ncontract, an archipelago of crowdfunded physical territories, a virtual\ncapital, and an on-chain census that proves a large enough population,\nincome, and real-estate footprint to attain a measure of diplomatic\nrecognition.\n\nHere, the concept starts to get opinionated: we're not just talking\nabout the general concept of online communities that have collective\nagency and eventually try to materialize on land, we're talking about a\nspecific Balajian vision of what network states should look\nlike. It's completely possible to support network states in general, but\nhave disagreements with the Balajian view of what properties network\nstates should have. If you're not already a \"crypto convert\", it's hard\nto see why an \"integrated cryptocurrency\" is such a fundamental part of\nthe network state concept, for example - though Balaji does later on in\nthe book defend his choices.\nFinally, Balaji expands on this conception of a Balajian network\nstate in longer-form, first in \"a\nthousand words\" (apparently, Balajian network states use base 8, as the actual\nword count is exactly 512=83)\nand then an\nessay, and at the very end of the book a whole\nchapter.\n\nAnd, of course,\nan\nimage.\n\nOne key point that Balaji stresses across many chapters and\npages is the\nunavoidable moral ingredient required for any successful new\ncommunity. As Balaji writes:\n\nThe quick answer comes from Paul Johnson at the 11:00 mark of this talk, where he notes\nthat early America's religious colonies succeeded at a higher rate than\nits for-profit colonies, because the former had a purpose. The slightly\nlonger answer is that in a startup society, you're not asking people to\nbuy a product (which is an economic, individualistic pitch) but to join\na community (which is a cultural, collective pitch).\n\nThe commitment\nparadox of religious communes is key here: counterintuitively, it's\nthe religious communes that demand the most of their members\nthat are the most long-lasting.\n\nThis is where Balajism explicitly diverges from the more traditional\nneoliberal-capitalist ideal of the defanged, apolitical and passion-free\nconsumerist \"last\nman\". Unlike the strawman libertarian, Balaji does not believe that\neverything can \"merely be a consumer product\". Rather, he stresses\ngreatly the importance of social norms for cohesion, and a literally\nreligious attachment to the values that make a particular network state\ndistinct from the world outside. As Balaji says in\nthis podcast at 18:20, most current libertarian attempts at\nmicronations are like \"Zionism without Judaism\", and this is a key part\nof why they fail.\nThis recognition is not a new one. Indeed, it's at the core of\nAntonio Garcia Martinez's criticism of Balaji's earlier\nsovereign-individual ideas (see this\npodcast at ~27:00), praising the tenacity of Cuban exiles in Miami\nwho \"perhaps irrationally, said this is our new homeland, this is our\nlast stand\". And in Fukuyama's The End of History:\n\nThis city, like any city, has foreign enemies and needs to be\ndefended from outside attack. It therefore needs a class of guardians\nwho are courageous and public-spirited, who are willing to sacrifice\ntheir material desires and wants for the sake of the common good.\nSocrates does not believe that courage and public-spiritedness can arise\nout of a calculation of enlightened self-interest. Rather, they must be\nrooted in thymos, in the just pride of the guardian class in themselves\nand in their own city, and their potentially irrational anger against\nthose who threaten it.\n\nBalaji's argument in The Network State, as I am\ninterpreting it, is as follows. While we do need political collectives\nbound not just by economic interest but also by moral force, we don't\nneed to stick with the specific political collectives we have\ntoday, which are highly flawed and increasingly unrepresentative of\npeople's values. Rather, we can, and should, create new and better\ncollectives - and his seven-step\nprogram tells us how.\nSo what kinds of\nnetwork states could we build?\nBalaji outlines a few ideas for network states, which I will condense\ninto two key directions: lifestyle immersion and\npro-tech regulatory innovation.\nBalaji's go-to example for lifestyle immersion is a network state\norganized around health:\n\nNext, let's do an example which requires a network archipelago (with\na physical footprint) but not a full network state (with diplomatic\nrecognition). This is Keto Kosher, the sugar-free\nsociety.\nStart with a history of the horrible USDA Food Pyramid, the\ngrain-heavy monstrosity that gave cover to the corporate sugarification\nof the globe and the obesity epidemic. ... Organize a community online\nthat crowdfunds properties around the world, like apartment buildings\nand gyms, and perhaps eventually even culdesacs and small towns. You\nmight take an extreme sugar teeotaler approach, literally banning\nprocessed foods and sugar at the border, thereby implementing a kind of\n\"Keto Kosher\".\nYou can imagine variants of this startup society that are like\n\"Carnivory Communities\" or \"Paleo People\". These would be competing\nstartup societies in the same broad area, iterations on a theme. If\nsuccessful, such a society might not stop at sugar. It could get into\nsetting cultural defaults for fitness and exercise. Or perhaps it could\nbulk purchase continuous glucose meters for all members, or orders of\nmetformin.\n\nThis, strictly speaking, does not require any diplomatic recognition\nor even political autonomy - though perhaps, in the longer-term future,\nsuch enclaves could negotiate for lower health insurance fees and\nmedicare taxes for their members. What does require autonomy? Well, how\nabout a free zone for medical innovation?\n\nNow let's do a more difficult example, which will require a full\nnetwork state with diplomatic recognition. This is the medical\nsovereignty zone, the FDA-free society.\nYou begin your startup society with Henninger's history of FDA-caused\ndrug lag\nand Tabarrok's history of FDA interference with so-called \"off\nlabel\" prescription. You point out how many millions were killed by\nits policies, hand out t-shirts like ACT-UP did, show Dallas Buyers Club\nto all prospective residents, and make clear to all new members why your\ncause of medical sovereignty is righteous ...\nFor the case of doing it outside the US, your startup society would\nride behind, say, the support of the Malta's FDA for a new biomedical\nregime. For the case of doing it within the US, you'd need a governor\nwho'd declare a sanctuary state for biomedicine. That is, just like a\nsanctuary city declares that it won't enforce federal immigration law, a\nsanctuary state for biomedicine would not enforce FDA writ.\n\nOne can think up of many more examples for both categories. One could\nhave a zone where it's okay to walk around naked, both securing your\nlegal right to do so and helping you feel comfortable by\ncreating an environment where many other people are naked too.\nAlternatively, you could have a zone where everyone can only wear basic\nplain-colored clothing, to discourage what's perceived as a zero-sum\nstatus competition of expending huge effort to look better than everyone\nelse. One could have an intentional community zone for cryptocurrency\nusers, requiring every store to accept it and demanding an NFT to get in\nthe zone at all. Or one could build an enclave that legalizes radical\nexperiments in transit and drone delivery, accepting higher risks to\npersonal safety in exchange for the privilege of participating in a\ntechnological frontier that will hopefully set examples for the world as\na whole.\nWhat is common about all of these examples is the value of having a\nphysical region, at least of a few hectares, where the network state's\nunique rules are enforced. Sure, you could individually insist on only\neating at healthy restaurants, and research each restaurant carefully\nbefore you go there. But it's just so much easier to have a\ndefined plot of land where you have an assurance that anywhere you go\nwithin that plot of land will meet your standards. Of course, you could\nlobby your local government to tighten health and safety regulations.\nBut if you do that, you risk friction with people who have radically\ndifferent preferences on tradeoffs, and you risk shutting\npoor people out of the economy. A network state offers a moderate\napproach.\nWhat is\nBalaji's megapolitical case for network states?\nOne of the curious features of the book that a reader will notice\nalmost immediately is that it sometimes feels like two books in one:\nsometimes, it's a book about the concept of network states, and at other\ntimes it's an exposition of Balaji's grand megapolitical theory.\nBalaji's grand megapolitical theory is pretty out-there and fun in a\nbunch of ways. Near the beginning of the book, he entices readers with\ntidbits like... ok fine, I'll just quote:\n\nGermany sent\nVladimir\nLenin into Russia, potentially as part of a\nstrategy\nto destabilize their then-rival in war. Antony Sutton's books document\nhow some\nWall\nStreet bankers apparently funded the Russian Revolution (and how\nother Wall Street bankers\nfunded\nthe Nazis years later). Leon Trotsky spent\ntime\nin New York prior to the revolution, and propagandistic reporting\nfrom Americans like\nJohn\nReed aided Lenin and Trotsky in their revolution. Indeed, Reed was\nso useful to the Soviets — and so misleading as to the nature of the\nrevolution — that he was\nburied\nat the base of the Kremlin Wall. Surprise: the Russian Revolution\nwasn't done wholly by Russians, but had significant foreign involvement\nfrom Germans and Americans.\nThe Ochs-Sulzberger family, which owns The New York Times Company,\nowned\nslaves but didn't report that fact in their 1619\ncoverage.\nNew York Times correspondent Walter\nDuranty won a Pulitzer\nPrize for helping the Soviet Union starve Ukraine into submission,\n90 years before the Times decided to instead \"stand\nwith Ukraine\".\n\nYou can find a bunch more juicy examples in the chapter titled,\nappropriately, \"If\nthe News is Fake, Imagine History\". These examples seem haphazard,\nand indeed, to some extent they are so intentionally: the goal is first\nand foremost to shock the reader out of their existing world model so\nthey can start downloading Balaji's own.\nBut pretty soon, Balaji's examples do start to point to some\nparticular themes: a deep dislike of the \"woke\" US left, exemplified by\nthe New York Times, a combination of strong discomfort with the Chinese\nCommunist Party's authoritarianism with an understanding of why the CCP\noften justifiably fears the United States, and an appreciation of the\nlove of freedom of the US right (exemplified by Bitcoin maximalists)\ncombined with a dislike of their hostility toward cooperation and\norder.\nNext, we get Balaji's overview of the\npolitical realignments in recent history, and finally we get to his\ncore model of politics in the present day: NYT, CCP, BTC.\n\nTeam NYT basically runs the US, and its total lack of competence\nmeans that the US is collapsing. Team BTC (meaning, both actual Bitcoin\nmaximalists and US rightists in general) has some positive values, but\ntheir outright hostility to collective action and order means that they\nare incapable of building anything. Team CCP can build, but they are\nbuilding a dystopian surveillance state that much of the world would not\nwant to live in. And all three teams are waaay too nationalist: they\nview things from the perspective of their own country, and ignore or\nexploit everyone else. Even when the teams are internationalist in\ntheory, their specific ways of interpreting their values make them\nunpalatable outside of a small part of the world.\nNetwork states, in Balaji's view, are a \"de-centralized\ncenter\" that could create a better alternative. They combine the\nlove of freedom of team BTC with the moral energy of team NYT and the\norganization of team CCP, and give us the best benefits of all three\n(plus a level of international appeal greater than any of the\nthree) and avoid the worst parts.\nThis is Balajian megapolitics in a nutshell. It is not trying to\njustify network states using some abstract theory (eg. some Dunbar's\nnumber or concentrated-incentive argument that the optimal size of a\npolitical body is actually in the low tens of thousands). Rather, it is\nan argument that situates network states as a response to the particular\npolitical situation of the world at its current place and time.\n\nBalaji's helical theory of history: yes, there are cycles,\nbut there is also ongoing progress. Right now, we're at the part of the\ncycle where we need to help the sclerotic old order die, but also seed a\nnew and better one.\n\nDo\nyou have to agree with Balaji's megapolitics to like network\nstates?\nMany aspects of Balajian megapolitics will not be convincing to many\nreaders. If you believe that \"wokeness\" is an important movement that\nprotects the vulnerable, you may not appreciate the almost off-handed\ndismissal that it is basically just a mask for a professional elite's\nwill-to-power. If you are worried about the plight of smaller countries\nsuch as Ukraine who are threatened by aggressive neighbors and\ndesperately need outside support, you will not be convinced by Balaji's\nplea that \"it may instead be best for countries to rearm, and take\non their own defense\".\nI do think that you can support network states while disagreeing with\nsome of Balaji's reasoning for them (and vice versa). But first, I\nshould explain why I think Balaji feels that his view of the\nproblem and his view of the solution are connected. Balaji has been\npassionate about roughly the same problem for a long time; you can see a\nsimilar narrative outline of defeating US institutional sclerosis\nthrough a technological and exit-driven approach in his speech on \"the\nultimate exit\" from 2013. Network states are the latest iteration of\nhis proposed solution.\nThere are a few reasons why talking about the problem is\nimportant:\n\nTo show that network states are the only way to protect\nfreedom and capitalism, one must show why the US cannot. If the\nUS, or the \"democratic liberal order\", is just fine, then there is no\nneed for alternatives; we should just double down on global coordination\nand rule of law. But if the US is in an irreversible decline, and its\nrivals are ascending, then things look quite different. Network states\ncan \"maintain liberal values in an illiberal world\"; hegemony thinking\nthat assumes \"the good guys are in charge\" cannot.\nMany of Balaji's intended readers are not in the US, and a\nworld of network states would inherently be globally distributed - and\nthat includes lots of people who are suspicious of\nAmerica. Balaji himself is Indian, and has a large Indian fan\nbase. Many people in India, and elsewhere, view the US not as a\n\"guardian of the liberal world order\", but as something much more\nhypocritical at best and sinister at worst. Balaji wants to make it\nclear that you do not have to be pro-American to be a liberal (or at\nleast a Balaji-liberal).\nMany parts of US left-leaning media are increasingly hostile\nto both cryptocurrency and the tech sector. Balaji expects that\nthe \"authoritarian left\" parts of \"team NYT\" will be hostile to network\nstates, and he explains this by pointing out that the media are not\nangels and their attacks are often self-interested.\n\nBut this is not the only way of looking at the broader picture. What\nif you do believe in the importance of role of social justice\nvalues, the New York Times, or America? What if you value governance\ninnovation, but have more moderate views on politics? Then, there are\ntwo ways you could look at the issue:\n\nNetwork states as a synergistic strategy, or at least as a\nbackup. Anything that happens in US politics in terms of\nimproving equality, for example, only benefits the ~4% of the\nworld's population that lives in the United States. The First Amendment\ndoes not apply outside US borders. The governance of many wealthy\ncountries is sclerotic, and we do need some way to try\nmore governance innovation. Network states could fill in the gaps.\nCountries like the United States could host network states that attract\npeople from all over the world. Successful network states could even\nserve as a policy model for countries to adopt. Alternatively, what\nif the Republicans win and secure a decades-long majority in 2024,\nor the United States breaks down? You want there to be an\nalternative.\nExit to network states as a distraction, or even a\nthreat. If everyone's first instinct when faced with a large\nproblem within their country is to exit to an enclave elsewhere, there\nwill be no one left to protect and maintain the countries themselves.\nGlobal infrastructure that ultimately network states depend on will\nsuffer.\n\nBoth perspectives are compatible with a lot of disagreement with\nBalajian megapolitics. Hence, to argue for or against Balajian network\nstates, we will ultimately have to talk about network states. My own\nview is friendly to network states, though with a lot of caveats and\ndifferent ideas about how network states could work.\nWhat\ndoes cryptocurrency have to do with network states?\nThere are two kinds of alignment here: there is the\nspiritual alignment, the idea that \"Bitcoin\nbecomes the flag of technology\", and there is the practical\nalignment, the specific ways in which network states could use\nblockchains and cryptographic tokens. In general, I agree with both of\nthese arguments - though I think Balaji's book could do much more to\nspell them out more explicitly.\nThe spiritual alignment\nCryptocurrency in 2022 is a key standard-bearer for internationalist\nliberal values that are difficult to find in any other social force that\nstill stands strong today. Blockchains and cryptocurrencies are\ninherently global. Most Ethereum developers are outside the US, living\nin far-flung places like Europe, Taiwan and Australia. NFTs have given\nunique opportunities to artists\nin Africa and elsewhere\nin the Global South. Argentinians punch above their weight in\nprojects like Proof of Humanity, Kleros and Nomic Labs.\nBlockchain communities continue to stand for openness, freedom,\ncensorship resistance and credible\nneutrality, at a time where many geopolitical actors are\nincreasingly only serving their own interests. This enhances their\ninternational appeal further: you don't have to love US hegemony to love\nblockchains and the values that they stand for. And this all makes\nblockchains an ideal spiritual companion for the network state vision\nthat Balaji wants to see.\nThe practical alignment\nBut spiritual alignment means little without practical use value for\nblockchains to go along with it. Balaji gives plenty of blockchain use\ncases. One of Balaji's favorite concepts is the idea of the blockchain\nas a \"ledger of record\": people can timestamp events on-chain, creating\na global provable log of humanity's \"microhistory\". He continues with\nother examples:\n\nZero-knowledge\ntechnology like ZCash, Ironfish, and Tornado Cash allow on-chain attestation\nof exactly what people want to make public and nothing more.\nNaming systems like the Ethereum Name\nService (ENS) and Solana Name\nService (SNS) attach identity to on-chain transactions.\nIncorporation systems allow the on-chain representation of corporate\nabstractions above the level of a mere transaction, like financial\nstatements or even full programmable company-equivalents like DAOs.\nCryptocredentials,\nNon-Fungible\nTokens (NFTs), Non-Transferable\nFungibles (NTFs), and Soulbounds allow the\nrepresentation of non-financial data on chain, like diplomas or\nendorsements.\n\nBut how does this all relate to network states? I could go into\nspecific examples in the vein of crypto cities: issuing\ntokens, issuing CityDAO-style\ncitizen NFTs, combining blockchains with zero-knowledge cryptography to\ndo secure privacy-preserving\nvoting, and a lot more. Blockchains are the\nLego of crypto-finance and crypto-governance: they are a very\neffective tool for implementing transparent in-protocol rules to govern\ncommon resources, assets and incentives.\nBut we also need to go a level deeper. Blockchains and\nnetwork states have the shared property that they are both trying to\n\"create a new root\". A corporation is not a root: if there is a\ndispute inside a corporation, it ultimately gets resolved by a national\ncourt system. Blockchains and network states, on the other hand,\nare trying to be new roots. This does not mean some absolute\n\"na na no one can catch me\" ideal of sovereignty that is perhaps only\ntruly accessible to the ~5 countries that have highly self-sufficient\nnational economies and/or nuclear weapons. Individual blockchain\nparticipants are of course vulnerable to national regulation, and\nenclaves of network states even more so. But blockchains are the only\ninfrastructure system that at least attempts to do ultimate\ndispute resolution at the non-state level (either through on-chain smart\ncontract logic or through the freedom\nto fork). This makes them an ideal base infrastructure for network\nstates.\nWhat aspects of\nBalaji's vision do I like?\nGiven that a purist \"private\nproperty rights only\" libertarianism inevitably runs into large\nproblems like its inability to fund public goods, any successful\npro-freedom program in the 21st century has to be a hybrid containing at\nleast one Big Compromise Idea that solves at least 80% of the problems,\nso that independent individual initiative can take care of the rest.\nThis could be some stringent measures against economic power and wealth\nconcentration (maybe charge annual Harberger\ntaxes on everything), it could be an 85% Georgist\nland tax, it could be a UBI, it could be mandating that sufficiently\nlarge companies become democratic internally, or one of any other\nproposals. Not all of these work, but you need something that\ndrastic to have any shot at all.\nGenerally, I am used to the Big Compromise Idea being a leftist one:\nsome form of equality and democracy. Balaji, on the other hand, has Big\nCompromise Ideas that feel more rightist: local communities with shared\nvalues, loyalty, religion, physical environments structured to encourage\npersonal discipline (\"keto kosher\") and hard work. These values are\nimplemented in a very libertarian and tech-forward way, organizing not\naround land, history, ethnicity and country, but around the cloud and\npersonal choice, but they are rightist values nonetheless. This style of\nthinking is foreign to me, but I find it fascinating, and important.\nStereotypical \"wealthy\nwhite liberals\" ignore this at their peril: these more \"traditional\"\nvalues are actually quite popular even among some\nethnic minorities in the United States, and even more so in places\nlike Africa and India, which is exactly where Balaji is trying to build\nup his base.\nBut\nwhat about this particular baizuo that's currently writing this review?\nDo network states actually interest me?\nThe \"Keto Kosher\" health-focused lifestyle immersion network state is\ncertainly one that I would want to live in. Sure, I could just spend\ntime in cities with lots of healthy stuff that I can seek out\nintentionally, but a concentrated physical environment makes it so much\neasier. Even the motivational aspect of being around other people who\nshare a similar goal sounds very appealing.\nBut the truly interesting stuff is the governance innovation: using\nnetwork states to organize in ways that would actually not be possible\nunder existing regulations. There are three ways that you can interpret\nthe underlying goal here:\n\nCreating new regulatory environments that let their\nresidents have different priorities from the priorities\npreferred by the mainstream: for example, the \"anyone can walk around\nnaked\" zone, or a zone that implements different tradeoffs between\nsafety and convenience, or a zone that legalizes more psychoactive\nsubstances.\nCreating new regulatory institutions that might be more\nefficient at serving the same priorities as the status quo. For\nexample, instead of improving environmental friendliness by regulating\nspecific behaviors, you could just have a Pigovian tax.\nInstead of requiring licenses and regulatory pre-approval for many\nactions, you could require mandatory\nliability insurance. You could use quadratic voting for\ngovernance and quadratic funding to fund local public goods.\nPushing against regulatory conservatism in general,\nby increasing the chance that there's some jurisdiction that\nwill let you do any particular thing. Institutionalized bioethics, for\nexample, is a notoriously conservative enterprise, where 20 people dead\nin a medical experiment gone wrong is a tragedy, but 200000 people dead\nfrom life-saving\nmedicines and vaccines not being approved quickly enough is a\nstatistic. Allowing people to opt into network states that accept higher\nlevels of risk could be a successful strategy for pushing against\nthis.\n\nIn general, I see value in all three. A large-scale\ninstitutionalization of [1] could make the word simultaneously more free\nwhile making people comfortable with higher levels of restriction of\ncertain things, because they know that if they want to do something\ndisallowed there are other zones they could go to do it. More generally,\nI think there is an important idea hidden in [1]: while the\n\"social technology\" community has come up with many good ideas around\nbetter governance, and many good ideas around better public discussion, there is a\nmissing emphasis on better social technology for\nsorting. We don't just want to take existing maps of\nsocial connections as given and find better ways to come to consensus\nwithin them. We also want to reform the webs of social connections\nthemselves, and put people closer to other people that are more\ncompatible with them to better allow different ways of life to maintain\ntheir own distinctiveness.\n[2] is exciting because it fixes a major problem in politics: unlike\nstartups, where the early stage of the process looks somewhat like a\nmini version of the later stage, in politics the early stage is a public\ndiscourse game that often selects for very different things than what\nactually work in practice. If governance ideas are regularly implemented\nin network states, then we would move from an\nextrovert-privileging \"talker liberalism\" to a more balanced \"doer\nliberalism\" where ideas rise and fall based on how well they actually do\non a small scale. We could even combine [1] and [2]: have a\nzone for people who want to automatically participate in a new\ngovernance experiment every year as a lifestyle.\n[3] is of course a more complicated moral question: whether you view\nparalysis and creep toward de-facto authoritarian global government as a\nbigger problem or someone inventing an evil technology that dooms us all\nas a bigger problem. I'm generally in the first camp; I am concerned\nabout the prospect of both\nthe West and China settling into a kind of low-growth conservatism,\nI love how imperfect coordination between nation states limits\nthe enforceability of things like global copyright law, and I'm\nconcerned about the possibility that, with future surveillance\ntechnology, the world as a whole will enter a highly self-enforcing but\nterrible political equilibrium that it cannot get out of. But there are\nspecific areas (cough cough, unfriendly\nAI risk) where I am in the risk-averse camp ... but here we're already\ngetting into the second part of my reaction.\nWhat\naspects of Balaji's vision do I take issue with?\nThere are four aspects that I am worried about the most:\n\nThe \"founder\" thing - why do network states need a recognized\nfounder to be so central?\nWhat if network states end up only serving the wealthy?\n\"Exit\" alone is not sufficient to stabilize global politics. So if\nexit is everyone's first choice, what happens?\nWhat about global negative externalities more generally?\n\nThe \"founder\" thing\nThroughout the book, Balaji is insistent on the importance of\n\"founders\" in a network state (or rather, a startup society:\nyou found a startup society, and become a network state if you are\nsuccessful enough to get diplomatic recognition). Balaji explicitly\ndescribes startup society founders as being \"moral entrepreneurs\":\n\nThese presentations are similar to startup pitch decks. But as the\nfounder of a startup society, you aren't a technology entrepreneur\ntelling investors why this new innovation is better, faster, and\ncheaper. You are a moral entrepreneur telling potential future citizens\nabout a better way of life, about a single thing that the broader world\nhas gotten wrong that your community is setting right.\n\nFounders crystallize moral intuitions and learnings\nfrom history into a concrete philosophy, and people whose moral\nintuitions are compatible with that philosophy coalesce around the\nproject. This is all very reasonable at an early stage - though it is\ndefinitely not the only approach for how a startup society\ncould emerge. But what happens at later stages? Mark Zuckerberg being\nthe centralized founder of facebook the startup was perhaps necessary.\nBut Mark Zuckerberg being in charge of a multibillion-dollar (in fact,\nmultibillion-user) company is something quite different. Or,\nfor that matter, what about Balaji's nemesis: the fifth-generation\nhereditary white Ochs-Sulzberger dynasty running the New York Times?\nSmall things being centralized is great, extremely large things being\ncentralized is terrifying. And given the reality of network effects, the\nfreedom to exit again is not sufficient. In my view, the problem of how\nto settle into something other than founder control is important, and\nBalaji spends too little effort on it. \"Recognized founder\" is baked\ninto the definition of what a Balajian network state is, but a roadmap\ntoward wider participation in governance is not. It should be.\nWhat about everyone who\nis not wealthy?\nOver the last few years, we've seen many instances of governments\naround the world becoming explicitly more open to \"tech talent\". There\nare 42\ncountries offering digital nomad visas, there is a French\ntech visa, a similar\nprogram in Singapore, golden visas for Taiwan, a\nprogram for Dubai,\nand many others. This is all great for skilled professionals and rich\npeople. Multimillionaires fleeing China's tech crackdowns and covid\nlockdowns (or, for that matter, moral disagreements with China's other\npolicies) can often escape the\nworld's systemic discrimination against Chinese and other\nlow-income-country citizens by spending a few hundred thousand\ndollars on buying\nanother passport. But what about regular people? What about the Rohingya minority\nfacing extreme conditions in Myanmar, most of whom do not have a way\nto enter the US or Europe, much less buy another passport?\nHere, we see a potential tragedy of the network state concept. On the\none hand, I can really see how exit can be the most viable strategy for\nglobal human rights protection in the twenty first century. What do you\ndo if another country is oppressing an ethnic minority? You could do\nnothing. You could sanction them (often ineffective\nand ruinous\nto the very people you're trying to help). You could try to invade (same\ncriticism but even worse). Exit is a more humane option. People\nsuffering human rights atrocities could just pack up and leave for\nfriendlier pastures, and coordinating to do it in a group would mean\nthat they could leave without sacrificing the communities they depend on\nfor friendship and economic livelihood. And if you're wrong and the\ngovernment you're criticizing is actually not that oppressive, then\npeople won't leave and all is fine, no starvation or bombs required.\nThis is all beautiful and good. Except... the whole thing breaks down\nbecause when the people try to exit, nobody is there to take them.\nWhat is the answer? Honestly, I don't see one. One point in favor of\nnetwork states is that they could be based in poor countries,\nand attract wealthy people from abroad who would then help the local\neconomy. But this does nothing for people in poor countries who want\nto get out. Good old-fashioned political action within existing\nstates to liberalize immigration laws seems like the only option.\nNowhere to run\nIn the wake of Russia's invasion of Ukraine on Feb 24, Noah Smith\nwrote an important\npost on the moral clarity that the invasion should bring to our\nthought. A particularly striking section is titled \"nowhere to run\".\nQuoting:\n\nBut while exit works on a local level — if San Francisco is too\ndysfunctional, you can probably move to Austin or another tech town — it\nsimply won't work at the level of nations. In fact, it never really did\n— rich crypto guys who moved to countries like Singapore or territories\nlike Puerto Rico still depended crucially on the infrastructure and\ninstitutions of highly functional states. But Russia is making it even\nclearer that this strategy is doomed, because eventually there is\nnowhere to run. Unlike in previous eras, the arm of the great powers is\nlong enough to reach anywhere in the world.\nIf the U.S. collapses, you can't just move to Singapore, because in a\nfew years you'll be bowing to your new Chinese masters. If the U.S.\ncollapses, you can't just move to Estonia, because in a few years\n(months?) you'll be bowing to your new Russian masters. And those\nmasters will have extremely little incentive to allow you to remain a\nfree individual with your personal fortune intact ... Thus it is very very\nimportant to every libertarian that the U.S. not collapse.\n\nOne possible counter-argument is: sure, if Ukraine was full of people\nwhose first instinct was exit, Ukraine would have collapsed. But if\nRussia was also more exit-oriented, everyone in Russia would\nhave pulled out of the country within a week of the invasion. Putin\nwould be left standing alone in the fields of the Luhansk oblast facing\nZelensky a hundred meters away, and when Putin shouts his demand for\nsurrender, Zelensky would reply: \"you and what army\"? (Zelensky would of\ncourse win a fair one-on-one fight)\nBut things could go a different way. The risk is that exitocracy\nbecomes recognized as the primary way you do the \"freedom\"\nthing, and societies that value freedom will become exitocratic,\nbut centralized states will censor and suppress these impulses, adopt a\nmilitaristic attitude of national unconditional loyalty, and run\nroughshod over everyone else.\nSo what about those\nnegative externalities?\nIf we have a hundred much-less-regulated innovation labs everywhere\naround the world, this could lead to a world where harmful things are\nmore difficult to prevent. This raises a question: does\nbelieving in Balajism require believing in a world where\nnegative externalities are not too big a deal? Such a\nviewpoint would be the opposite of the Vulnerable\nWorld Hypothesis (VWH), which suggests that are technology\nprogresses, it gets easier and easier for one or a few crazy people to\nkill millions, and global authoritarian surveillance might be\nrequired to prevent extreme suffering or even extinction.\nOne way out might be to focus on self-defense technology. Sure, in a\nnetwork state world, we could not feasibly ban gain-of-function\nresearch, but we could use network states to help the world along a path\nto adopting really good HEPA air\nfiltering, far-UVC\nlight, early detection infrastructure and a very rapid\nvaccine development and deployment pipeline that could defeat not only\ncovid, but far worse viruses too. This\n80,000 hours episode outlines the bull case for bioweapons being a\nsolvable problem. But this is not a universal solution for all\ntechnological risks: at the very least, there is no self-defense against\na super-intelligent unfriendly AI that kills us all.\nSelf-defense technology is good, and is probably an undervalued\nfunding focus area. But it's not realistic to rely on that alone.\nTransnational cooperation to, for example, ban\nslaughterbots, would be required. And so we do want a world where,\neven if network states have more sovereignty than intentional\ncommunities today, their sovereignty is not absolute.\nNon-Balajian network states\nReading The Network State reminded me of a different book\nthat I read ten years ago: David de Ugarte's Phyles: Economic Democracy\nin the Twenty First Century. Phyles talks about\nsimilar ideas of transnational communities organized around values, but\nit has a much more left-leaning emphasis: it assumes that these\ncommunities will be democratic, inspired by a combination of 2000s-era\nonline communities and nineteenth and twentieth-century ideas of\ncooperatives and workplace democracy.\nWe can see the differences most clearly by looking at de Ugarte's\ntheory of formation. Since I've already spent a lot of time quoting\nBalaji, I'll give de Ugarte a fair hearing with a longer quote:\n\nThe very blogosphere is an ocean of identities and conversation in\nperpetual cross-breeding and change from among which the great social\ndigestion periodically distils stable groups with their own contexts and\nspecific knowledge.\nThese conversational communities which crystallise, after a certain\npoint in their development, play the main roles in what we call digital\nZionism: they start to precipitate into reality, to generate mutual\nknowledge among their members, which makes them more identitarially\nimportant to them than the traditional imaginaries of the imagined\ncommunities to which they are supposed to belong (nation, class,\ncongregation, etc.) as if it were a real community (group of friends,\nfamily, guild, etc.)\nSome of these conversational networks, identitarian and dense, start\nto generate their own economic metabolism, and with it a distinct demos\n– maybe several demoi – which takes the nurturing of the autonomy of the\ncommunity itself as its own goal. These are what we call Neo-Venetianist\nnetworks. Born in the blogosphere, they are heirs to the hacker work\nethic, and move in the conceptual world, which tends to the economic\ndemocracy which we spoke about in the first part of this book.\nUnlike traditional cooperativism, as they do not spring from real\nproximity-based communities, their local ties do not generate identity.\nIn the Indianos' foundation, for instance, there are residents in two\ncountries and three autonomous regions, who started out with two\ncompanies founded hundreds of kilometres away from each other.\n\nWe see some very Balajian ideas: shared collective identities, but\nformed around values rather than geography, that start off as discussion\ncommunities in the cloud but then materialize into taking over large\nportions of economic life. De Ugarte even uses the exact same metaphor\n(\"digital Zionism\") that Balaji does!\nBut we also see a key difference: there is no single founder. Rather\nthan a startup society being formed by an act of a single individual\ncombining together intuitions and strands of thought into a coherent\nformally documented philosophy, a phyle starts off as a conversational\nnetwork in the blogosphere, and then directly turns into a group that\ndoes more and more over time - all while keeping its democratic and\nhorizontal nature. The whole process is much more organic, and not at\nall guided by a single person's intention.\nOf course, the immediate challenge that I can see is the incentive\nissues inherent to such structures. One way to perhaps unfairly\nsummarize both Phyles and The Network State is that\nThe Network State seeks to use 2010s-era blockchains as a model\nfor how to reorganize human society, and Phyles seeks to use\n2000s-era open source software communities and blogs as a model for how\nto reorganize human society. Open source has the failure mode of not\nenough incentives, cryptocurrency has the failure mode of\nexcessive and overly concentrated incentives. But what this\ndoes suggest is that some kind of middle way should be possible.\nIs there a middle way?\nMy judgement so far is that network states are great, but they are\nfar from being a viable Big Compromise Idea that can actually plug all\nthe holes needed to build the kind of world I and most of my readers\nwould want to see in the 21st century. Ultimately, I do think that we\nneed to bring in more democracy and large-scale-coordination oriented\nBig Compromise Ideas of some kind to make network states truly\nsuccessful.\nHere are some significant adjustments to Balajism that I would\nendorse:\nFounder\nto start is okay (though not the only way), but we really need a\nbaked-in roadmap to exit-to-community\nMany founders want to eventually retire or start something\nnew (see: basically half of every crypto project), and we need to\nprevent network states from collapsing or sliding into mediocrity when\nthat happens. Part of this process is some kind of constitutional\nexit-to-community guarantee: as the network state\nenters higher tiers of maturity and scale, more input from community\nmembers is taken into account automatically.\nProspera attempted something like this. As Scott Alexander summarizes:\n\nOnce Próspera has 100,000 residents (so realistically a long time\nfrom now, if the experiment is very successful), they can hold a\nreferendum where 51% majority can change anything about the charter,\nincluding kicking HPI out entirely and becoming a direct democracy, or\nrejoining the rest of Honduras, or anything\n\nBut I would favor something even more participatory than the\nresidents having an all-or-nothing nuclear option to kick the government\nout.\nAnother part of this process, and one that I've recognized in the\nprocess of Ethereum's growth, is explicitly encouraging broader\nparticipation in the moral and philosophical development of the\ncommunity. Ethereum has its Vitalik, but it also has its Polynya: an internet anon who\nhas recently entered the scene unsolicited and started providing\nhigh-quality thinking on rollups and scaling technology. How will your\nstartup society recruit its first ten Polynyas?\nNetwork\nstates should be run by something that's not coin-driven governance\nCoin-driven governance is plutocratic and vulnerable to attacks; I\nhave written about this many times, but it's worth\nrepeating. Ideas like Optimism's soulbound and\none-per-person citizen NFTs\nare key here. Balaji already acknowledges the need for non-fungibility\n(he supports\ncoin lockups), but we should go further and more explicit in\nsupporting governance that's not just shareholder-driven. This will also\nhave the beneficial side effect that more democratic governance is more\nlikely to be aligned with the outside world.\nNetwork\nstates commit to making themselves friendly through outside\nrepresentation in governance\nOne of the fascinating and under-discussed ideas from the rationalist\nand friendly-AI community is functional\ndecision theory. This is a complicated concept, but the\npowerful core idea is that AIs could coordinate better than humans,\nsolving prisoner's dilemmas where humans often fail, by making\nverifiable public commitments about their source code. An AI could\nrewrite itself to have a module that prevents it from cheating other AIs\nthat have a similar module. Such AIs would all cooperate with each other\nin\nprisoner's dilemmas.\nAs I pointed\nout years ago, DAOs could potentially do the same thing. They could\nhave governance mechanisms that are explicitly more charitable toward\nother DAOs that have a similar mechanism. Network states would be run by\nDAOs, and this would apply to network states too. They could even commit\nto governance mechanisms that promise to take wider public interests\ninto account (eg. 20% of the votes could go to a randomly selected set\nof residents of the host city or country), without the burden of having\nto follow specific complicated regulations of how they should\ntake those interests into account. A world where network states do such\na thing, and where countries adopt policies that are explicitly more\nfriendly to network states that do it, could be a better one.\nConclusion\nI want to see startup societies along these kinds of visions exist. I\nwant to see immersive lifestyle experiments around healthy living. I\nwant to see crazy governance experiments where public goods are funded\nby quadratic funding, and all zoning laws are replaced by a system where\nevery building's property tax floats between zero and five percent per\nyear based on what percentage of nearby residents express approval or\ndisapproval in a real-time blockchain and ZKP-based voting\nsystem. And I want to see more technological experiments that accept\nhigher levels of risk, if the people taking those risks consent to it.\nAnd I think blockchain-based tokens, identity and reputation systems and\nDAOs could be a great fit.\nAt the same time, I worry that the network state vision in its\ncurrent form risks only satisfying these needs for those wealthy enough\nto move and desirable enough to attract, and many people lower down the\nsocioeconomic ladder will be left in the dust. What can be said in\nnetwork states' favor is their internationalism: we even have the\nAfrica-focused Afropolitan.\nInequalities between countries are responsible\nfor two thirds of global inequality and inequalities within\ncountries are only one third. But that still leaves a lot of people in\nall countries that this vision doesn't do much for. So we need something\nelse too - for the global poor, for Ukrainians that want to keep their\ncountry and not just squeeze into Poland for a decade until Poland gets\ninvaded too, and everyone else that's not in a position to move to a\nnetwork state tomorrow or get accepted by one.\nNetwork states, with some modifications that push for more democratic\ngovernance and positive relationships with the communities that surround\nthem, plus some other way to help everyone else? That is a\nvision that I can get behind.","tokens":12169,"squid":"ink-research","role":"Deep Scholar","at":1791260602601,"hash":"56d9ca7a4d0dce68857833c868f9038d113ab000"}
{"url":"https://io.net/docs/guides/workers/aptos-wallet","domain":"io.net","title":"Aptos Wallet - io.net","text":"​What is a Aptos Wallet?\nAn Wallet is a digital wallet designed for securely storing and managing Aptos tokens, sending and receiving transactions, and interacting with decentralized applications (DApps) on the Aptos blockchain. It offers features such as private key management, encryption, and a user-friendly interface for monitoring balances and transaction history. Additionally, it integrates with various blockchain services and platforms, and can be available as mobile apps, browser extensions, or hardware wallets.\n​How to Create a Aptos Wallet\nYou can create any Aptos (APT) wallet from the official list here: Aptos Ecosystem.\nFor this example, we will use a popular option - Petra, and demonstrate how to configure and use the wallet:\n1. Go to Petra Wallet.\n\nSelect the browser to install Petra on. In this example, we use Chrome.\nClick Add to browser.\n\n2. Add to Chrome\nAfter you click Add to browser, you’re redirect to the extension download page.\nClick Add to Chrome to add the extension to Chrome.\n\n3. Open the Petra extension\n\nClick Create New Wallet.\nCreate a password for your wallet.\nClick Continue.\n\nIf you forget your password you will need to restore your wallet using your seed words, provided in the next step. Also, if you clear the browser cache, you cannot login using a password. You must restore wallet again using the seed word.\n\n4. Store the Recovery Phrase\n\nIn the Secret Recovery Phrase page, copy and store your 12 word Secret Recovery phrase. You can save them on password managers like Keepass.\nClick Continue.\n\nFailure to save your Secret Recovery Phrase can result in an inability to access your account. You may lose access to your coins.\n5. Copy the APT Address\nAfter you click Continue, the wallet generates a new APT address. This is the address used to receive coins.\nTo copy your APT address:\n\nClick on Aptos wallet extension.\nClick Receive.\nAt the top of the extension, click Copy icon to copy deposit address.\n\n6. Go to your IO ID account to set your new APT wallet address.\nFollow the steps below to set your APT wallet address.\n\nLog in to your io.net account.\nGo to your IO ID profile.\nIn the Account Settings tab (it’s there by default), find the Aptos Wallet address field.\nClick Change Wallet button\nEnter your new Aptos wallet address.\nClick Connect to add the new address.\n\nWas this page helpful?","tokens":588,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260609894,"hash":"ae54a2480966b1023244ed9c94221109b2d0aad9"}
{"url":"https://io.net/docs/guides/workers/rewards-wallets","domain":"io.net","title":"Overview - io.net","text":"​Rewards and Fees\nAll worker earnings are paid in IO Coin. IO Coin reduces friction in our payment system, bypassing the use of escrow, past-pay billing etc. At the same time, we balance this by creating a structural demand for $IO in the actual payment process. Every transaction in io.net creates $IO demand because Customers pay in USDC, but Suppliers are compensated with $IO tokens.\nTo learn more, see IO Coin.\n​Add Wallet to Account\nTo ensure future cryptocurrency withdrawals, you must link your wallet to your account. You can find instructions on how to get it here, using the Phantom wallet as an example. You can connect a Solana or Aptos wallet to your account.\nFollow the steps below to add a wallet to your account:\n\nClick on your icon in the upper right and select Account Settings.\n\nIn the Solana Wallet section, click Add Wallet.\n\n​Withdraw Funds from Your Account\n\nCreate a crypto wallet, such as Phantom, or use an existing wallet.\n\nIn the upper-right of the screen, click USDC.\n\nOn the Claim Rewards dialog, choose Custom to enter a specific amount or select the values to the right: 5, 20, 50, or 100.\n\nClick the Confirm Amount button.\n\nA dialog launches that indicates the payment is being processed, followed by a Success confirmation. You can also track the transaction on Soloscan immediately by clicking on the See on Soloscan link.\n\n​Earnings and Rewards Tab\nThe Earnings & Rewards tabs enable you to view and manage your earnings for various compute jobs.\nIn the upper-left, select the Earnings & Rewards tab.\n\nOn this page, you can monitor your earnings and track data such as:\n\nTotal Compute Hours Served\nClaimable Earnings\nTotal Compute Jobs Served\nEarnings graphs by month\nCompute Jobs categorized by tasks\n\n​Block Rewards\nBlock Rewards are payments made to suppliers who provide their GPUs or CPUs to the our network. This incentivizes supply-side network growth. These rewards are distributed hourly in $IO, following a predefined emission schedule.\nThe Block Rewards tab in IO Explore provides a transparent view of io.net’s Block Rewards and coin emissions. Users can consult this information to monitor worker nominations and their status. Users can track the performance and success rates for worker nominations and block completion. Information on coin emissions and block rewards provides transparency about io.net network’s health.\nFor more information, see Block Rewards.\n​Staking\nAt IO.net, we’re committed to building a robust, secure, and decentralized platform for GPU and CPU supply and demand sides. Our staking program is designed to align incentives, ensure network integrity, and reward active participants in our ecosystem.\nStaking is a crucial component of our network security and efficiency. Requiring suppliers to stake $IO allows us to:\n\nEncourage long-term commitment to our platform.\nCreate an incentive for good behavior.\nEstablish a mechanism to discourage and penalize malicious actions.\n\nTo learn more about Staking, see IO Staking.Was this page helpful?","tokens":754,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260619982,"hash":"f1a98fd9b654ae7be12c38314c45dd7969f2dd38"}
{"url":"https://vitalik.eth.limo/general/2025/11/25/plinko.html","domain":"vitalik.eth.limo","title":"Plinko PIR tutorial","text":"Dark Mode Toggle\n\n Plinko PIR tutorial \n 2025 Nov 25 \nSee all posts\n\n Plinko PIR tutorial \n\nSpecial thanks to Alex Hoover, Keewoo Lee and Ali for feedback\nand review\nOne underrated form of privacy, that is not well satisfied by ZK-SNARKs,\ntraditional versions of FHE\nor other commonly talked about methods, is private\nreads. Users want to learn things from a large database,\nwithout revealing what they're reading. Some use cases of this\ninclude:\n\nPrivacy-preserving Wikipedia (so you can learn things without even\nthe server knowing what you're reading)\nPrivacy-preserving RAG\nor LLM search (so your\nlocal LLM can get data from the internet without revealing what you're\nquerying)\nBlockchain data reads (so you can use a dapp that queries an\nexternal RPC node without the node learning what you're querying; see\n\"private reads\" here)\n\nThere is a category of privacy protocols that are directly designed\nto solve this problem, called private\ninformation retrieval (PIR). A server has a database D. A client has an index i. The client sends the server a query,\nthe server replies back with an answer that allows the client to\nreconstruct D[i], all without the\nserver learning anything about i.\nIn this post I will describe some basics that underlies all PIR\nprotocols, and then describe Plinko, a protocol that\nefficiently achieves this.\nBasics of PIR\nTo understand more complicated PIR protocols, it's best to start with\n\"classic two-server PIR\". Classic two-server PIR assumes that a client\nis making queries to two servers, and it trusts\nthat at least one of the two is honest. Here's how the protocol\nworks:\n\nThe client wants to know D[i],\nin the above example D[8].\nThe client generates a random subset of indices in D, on average about half full (in the\nabove example, [1,5,6,10,15]).\nThe client sends that subset to one server, and then sends a\nmodified subset, where the membership of D[i] is flipped (ie. added if it was not\nthere, removed if it was there), to the other server.\nEach server computes the XOR of the values in D[i] that it was asked, and returns the\nresult\nThe client XORs these two values, and it gets the value of D[i]\n\nThe key idea is that each server receives what looks like a\ncompletely random subset of the indices. There is not even a slight bias\nfrom mixing in i, because that\nmodification is as likely to add the value as it is to remove it. The\ntwo servers give XOR-sums of subsets that are almost identical, but\ndiffer in one place: one includes D[i] and the other doesn't. The client\ngets these two values, and takes the difference between the two, which\ngives D[i].\nThis naturally generalizes to \"cells\" that are bigger than one bit;\nyou could have each D[i] have eg.\n1000 bits, and the protocol is exactly the same.\nThis protocol has three big weaknesses:\n\nYou have to trust that one of the two servers is honest.\nThe client has communication overhead equal to the number of cells\n(this can be much smaller than the total size of the data if the cells\nare big, but it's still a lot).\nThe server has to XOR half the total data to respond to a single\nquery.\n\nThere are two well-understood modifications to classic two-server PIR\nthat solve (1).\nOne strategy is PIR with preprocessing. Notice that\nin the protocol above, you can compute one of the two random sample sets\nbefore you even know which i you\nwant to query for. You generate thousands of these random queries. You\nhave an initial phase where you download (but do not need to store) the\nwhole file D, and you compute the\nXOR sums for these random sets of indices locally. Essentially, you are\nacting as one of the two servers - and in this way, satisfy the 1-of-2\ntrust assumption all by yourself, so you do not need to trust the other\nserver. This approach does require a huge amount of upfront bandwidth,\nbut you can do it ahead of time, or do it in the background and use a\nmore inefficient form of PIR to answer any queries that you get before\nit finishes.\nThe other strategy is single-server PIR.\nBasically, you use some variant of homomorphic encryption (often simpler\nthan full-on FHE) to encrypt your query, in such a way that the server\ncan compute on your encrypted query to give you an encrypted answer.\nThis has high computational overhead on the server side, and so is not\nyet feasible for very large datasets. This strategy can be combined with\nPIR with preprocessing, so you can theoretically avoid the initial\ndownload by doing that procedure homomorphically encrypted on the server\nside.\nPlinko solves (2) and (3) - or at least, it decreases both\ncommunication overhead and server-side compute overhead from O(N) to O(N) where N is the number of cells. It uses the\npreprocessing strategy to remove the trust assumption. Theoretically,\nyou can do the preprocessing in FHE; it is currently an open problem to\ndo this efficiently enough.\nIn Plinko's language, there is:\n\nA setup phase, where the client processes all the\ndata once (but only remembers a small number of\n\"hints\")\nA query mechanism, where the client makes a query\nto the server and combines the answer with the right hint to compute the\nneeded value.\n\nThere is also an easy way for the client to update hints if the data\nset changes. Now, let's get into the protocol!\nSetup phase\nTreat the database as being a square, with N rows and N columns:\n\nThe client generates a random master seed S. For each row i, the client uses the master seed to\ngenerate a row seed Si. The client\ngenerates roughly 128∗N\nhints. Each hint is generated as follows:\n\nRandomly (or rather, pseudorandomly by hashing the master seed) pick\nN2+1 rows\nIf we're computing the j'th\nhint, for each row ri, use a hash\nH(Sri,j) to generate a random\ncolumn ci. So we get N2+1 (ri,ci) pairs\nXOR the pairs, and save the bit\n\nThe \"hash\" that is used to compute the ci values could be a regular\nhash, but that leads to (tolerable but significant) inefficiency during\nthe query phase. So instead, Plinko prefers special type of hash called\nan \"invertible PRF\". The core property that it achieves is that given\nSi and ci, you can easily recover all j values that lead to that ci. In practical terms, this means that\nfor any cell (ri,ci), you can\neasily find all hints that \"include\" that cell.\nAdditionally, the setup phase generates some \"backup hints\". These\nare constructed like regular hints, except for each index j, you choose N2 rows, and compute a\npair of hints: one over the chosen subset of rows, and the other for its\ncomplement (ie. the N2 rows that were\nnot chosen):\n\nThis whole process can be done \"streaming\", without requiring the\nclient to store any data at any point in time other than the hints\nthemselves. In total, the client needs to download the whole data set\nand store data equal to roughly 64∗N cells, plus N cells per backup hint (the\nclient will need one backup hint for each query that the client will\nmake).\nIf desired, the process can also be done in FHE, which means the\nclient would only need to download the hints, but the server would need\nto do FHE work over the whole dataset; this is of course expensive, and\noptimizing it is an ongoing problem.\nQuery phase\nSuppose you are interested in a specific coordinate (x,y). First, you discover a hint index\nj that generates a hint that\ncontains (x,y). This is where the\n\"invertible PRF\" mechanism helps: it lets you immediately run the\nfunction in reverse knowing Sx and\ny to compute all j's such that H(Sx,j)=y. However, if you want to\navoid this complexity, you could just set H(Sx,j)=sha256(Sx,⌊j16⌋)[j%16:(j%16)+2] and then compute on average\nN16 hashes every\ntime.\nThen, you determine the N2+1 rows that the hint\ngenerates. You take out row x. You then send the server a message\nthat contains:\n\n[(r1,c1),(r2,c2)...(rN2,cN2)]: the set of\npoints included in that hint, except for the point you want\n[(x1,y1),(x2,y2)...(xN2,yN2)]: the set of\nall other rows (including the row you want), with a randomly\nchosen column for each one\n\nYou send these in a random order, so the server does not know which\nis which. As far as the server can tell, you just sent it a random set\nof points, one per row, with the rows split in half in an arbitrary way.\nThe server XORs both sets of cells, and replies with both outputs.\nThe client then locally takes its hint, XORs it with the (non-junk)\nvalue returned by the server, and it has its answer.\n\nThe server does a computation based on N cells, and returns that data to\nthe client. The server knows nothing about which cell the client wants\n(provided the client does not reuse hints), because the client gave the\nserver every point in the set in its hint except the point it\nactually wants. And without knowing the hash that generated these\nsubsets, to the server, all the row and column choices look completely\nrandom.\nBackup queries\nTo avoid using a hint twice (and thus leaking data), when the client\nmakes a query, it dumps the hint that it used, and \"promotes\" a backup\nhint into being a regular hint. Remember that each \"backup hint\" is a\npair of hints, one that is based on a random subset of the rows, and the\nother based on its complement. The algorithm is simple:\n\nTake the hint value generated from the subset of the rows that\ndoes not contain the row you queried\nXOR in the value you queried\n\nNow, you have a set of N2+1 rows with an XOR of one randomly-chosen column from each\nrow: exactly the same format as a regular hint.\n\nUpdating the dataset\nSuppose a value in the data updates. Then, you can find all hints\nthat contain that value, and simply do a direct update: mix in the XOR\nof the old value and the new value.\n\nAnd that's the whole protocol!\nConcrete efficiency\nIn asymptotic terms, everything in Plinko is O(N): the size of the hints that\nthe client needs to store, the data transmitted per query\n(technically that's O(N∗log(N))), and the server-side compute costs. But it helps to\nput this all into the context of a real-world workload. So let's use the\nreal-world workload that I am the most familiar with: Ethereum.\nSuppose that you are querying a dataset with 10 billion values, each\nof which are 32 bytes. This is a pretty good description of the Ethereum\nstate tree, in a couple of years when it gets significantly bigger due\nto scale. We use cuckoo hashing\nto convert a key-value store into a \"flat\" lookup table of the type that\nPlinko handles.\nTo include Merkle branches, one simple way (though not the optimal\nway) is to treat them separately as queries into smaller databases; if\nit's a binary\ntree, then the first level is full-sized, the second level is\nhalf-sized, the third level is quarter-sized, etc; because PIR costs are\nall proportional to sqrt, this means that our total costs will all be\nmultiplied by 1+1+12+12+122+...=3+2≈4.414. Ethereum's state tree is (for now) a less-efficient\nhexary tree, but you can ZK-prove equivalence to a binary\ntree to get the efficiencies of a binary tree today.\n\nBut first, let's provide raw costs without the Merkle branches. This\nimplies a 100000×100000 grid, where each cell is 32 bytes (256 bits).\nThe client would need to store 100000×128 hints, which is 100000 × 128 ×\n32 bytes ~= 390 MB, plus some extra backup hints.\nFor each query, the client would need to send the server a\npartitioning of the rows into two parts, and 100000 column indices. We\ncould be super-clever and do slightly better than this, but if\nwe do it naively, the row partition is 100000 bits (12.2 kB) and the\ncolumn indices are 100000 * ceil(log2(100000)) = 1.7m bits = 202.7 kB.\nThese two sum up to 215 kB per query.\nIf we introduce Merkle branches, the hint costs blow up to about\n1.68 GB. With clever work, we can actually avoid the\nper-query communication costs increasing by 4.414x, because we can\nadjust the PIR in such a way that we use the same (or rather, analogous)\nquery indices for the datasets representing different levels of the\ntree.\nServer-side costs involve reading and XOR'ing 100000 cells, or 3.05MB\nper query; the XOR is negligible, but the read load is significant.\nAdding Merkle branches would blow this up to about 13.4 MB in theory,\nthough the realistic added cost may well be negligible because clever\nengineering can ensure that matching values are always in the same page\n(memory pages are usually 4096 bytes).\nOur main tool to fiddle with these numbers is to make the\nrectangle unbalanced (have different width and height): we can\nincrease hint storage by 2x to reduce query size by 2x. Realistically,\nthis is a good tradeoff: storing even 10 GB of hints is not that hard,\nbut especially if nodes are sending multiple queries every 200\nmilliseconds, 215 kB per query is higher than we would be comfortable\nwith.\nIn the case of a search engine, the size of the objects would be much\nlarger (eg. 10 kB per text webpage), but the number of queries may be\nsmaller. Hence, query complexity would be relatively low, but hint size\nwould be large. To compensate for this, it may make sense to make the\nrectangle unbalanced in the other direction.\nBeyond Plinko:\ncomparing to the alternatives\nOne already-existing alternative to Plinko is TreePIR. TreePIR works by\nusing a \"puncturable PRF\": a hash function where you can provide a key\nthat allows evaluating it at all points except for one chosen\npoint. This allows you to generate a representation of the query columns\n(\"values generated from a seed S\nexcept the j'th value\")\nthat is logarithmic-sized - much more compact than providing the whole\nlist directly:\n\nThe full approach is somewhat more clever than the above diagram. The\nidea in this diagram reveals the excluded index 01100, violating\nprivacy. TreePIR works by providing the yellow values without\nrevealing their (horizontal) position in the tree. There are 2log2(N)=N possible\nsets of leaf values, and thus N possible sets of columns, that\ncan be generated by taking the left and right choice of position for\neach yellow value. The server has an O(N∗log(N)) time algorithm to\ncompute the XOR sum of chosen cells for every possible arrangement\nsimultaneously. The client knows which of these sums corresponds to the\nset that it actually needs. It uses single-server PIR to ask for it.\nThis reduces communication complexity to logarithmic, at the cost of\nincreased server work, and at the cost of removing the \"invertible PRF\"\nmechanism, forcing the client to \"grind\" through many possible hints\nuntil they find a matching hint.\nThere are various theoretical\nlower bounds\nfor how much overhead a PIR protocol needs to have. In reality, however,\nmost of these bounds come with caveats, and so the \"real\" lower bounds\nare far fewer. For example, if you have obfuscation, you can make any of\nthese protocols require only a constant real-time communication overhead\n- but of course, today, such protocols are still quite far away from\npracticality. The harder thing to reduce is server-side computation.\nBecause it's \"just\" XOR, the workload in Plinko is already not a big\ndeal. But if we want to remove the client-side O(N) download requirement, then we need\nthe server side to do much heavier computation.\nWith Plinko, PIR is much further along than it was a decade ago, but\nthere is still theoretically much further that these protocols could\ngo.","tokens":3796,"squid":"ink-research","role":"Deep Scholar","at":1791260622762,"hash":"126a4e59a5104ce33e1747e2de6f019e878bbf87"}
{"url":"https://atlas.optimism.io/","domain":"atlas.optimism.io","title":"Optimism Atlas","text":"Grants for the Superchain EcosystemSupport for individual builders and teams making onchain apps, tooling, and infrastructure to advance the Superchain. Our grants are for different stages of development, from pre-launch to established projects looking to scale their impact.70MOP rewarded in Retro Funding100MOP rewarded by Grants Council714Projects rewarded20 chains in the Superchain are eligible for builder rewards20 chains eligible for rewardsOP MainnetOpenAudit GrantsFor audit-ready apps looking to deploy on the Superchain.Get startedClosedGrowth GrantsFor apps that have already deployed, looking to boost their TVL.ClosedFoundation MissionsFor anyone who wants to tackle pre-determined problems.OpenGovernance Fund MissionsFor self-sufficient teams interested in technical challenges.Get startedOpenAudit GrantsFor audit-ready apps looking to deploy on the Superchain.Get startedClosedGrowth GrantsFor apps that have already deployed, looking to boost their TVL.ClosedFoundation MissionsFor anyone who wants to tackle pre-determined problems.OpenGovernance Fund MissionsFor self-sufficient teams interested in technical challenges.Get startedNot sure?Sunny can help you find the right grant programNot sure? Sunny can help you find the right grant programOver 500 projects have been rewardedSee allRelay Protocol133Kalloy70KVelodrome Finance395KCash Convert58KAerodrome Finance395KViem: TypeScript Interface for Ethereum559KLI.FI297KSushiswap107KSolidity559KDNA Token85Kethereum-bloom-filters208KSolhint255Kkeccak256js70KUniswap on Superchain (Oku)415Kweb3.py233KSplits44KEthers.js559KOtterverse63KPRBMath127KPancakeSwap294KOther Superchain GrantsExplore grant programs facilitated by our Superchain partnersSoniumSoneium For AllAccess help with funding, user acquisition, and technical implementation on Sonium.Learn moreUnichainUnichain Infinite HackathonRewards for projects recently built during any hackathon (IRL or virtual), competition, or demo day.Learn moreUnichainUnichain Open CallFor projects and teams looking for varying levels of support from the Uniswap Foundation.Learn moreUnichainUnichain Retro GrantsFor developers, content creators, and analysts with projects that show measurable impact.Learn moreWorldchainWorld Foundation GrantsSupporting innovation, impact, and collaboration on Worldchain.Learn moreWorldchainWorld Foundation RFPsOpen calls for applications addressing specific focus areas for Worldchain growth.Learn moreSoniumSoneium For AllAccess help with funding, user acquisition, and technical implementation on Sonium.Learn moreUnichainUnichain Infinite HackathonRewards for projects recently built during any hackathon (IRL or virtual), competition, or demo day.Learn moreUnichainUnichain Open CallFor projects and teams looking for varying levels of support from the Uniswap Foundation.Learn moreUnichainUnichain Retro GrantsFor developers, content creators, and analysts with projects that show measurable impact.Learn moreWorldchainWorld Foundation GrantsSupporting innovation, impact, and collaboration on Worldchain.Learn moreWorldchainWorld Foundation RFPsOpen calls for applications addressing specific focus areas for Worldchain growth.Learn moreNew to Optimism?Get started with the number one most used blockchain infrastructure.Deploy a chainBuild an appLearn more at optimism.io","tokens":834,"squid":"ink-governance","role":"Council Listener","at":1791260625542,"hash":"7602a22f1771b2c1cd08f24063a14690cf2b0f8e"}
{"url":"https://eips.ethereum.org/EIPS/eip-2364","domain":"eips.ethereum.org","title":"EIP-2364: eth/64: forkid-extended protocol handshake","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-2364: eth/64: forkid-extended protocol handshake\n\n Introduces validation of the `forkid` when handshaking with peers.\n\n Authors\n Péter Szilágyi <peterke@gmail.com>, Péter Szilágyi (@karalabe), Tim Beiko (@timbeiko)\n\n Created\n 2019-11-08\n\n Requires\n\n EIP-2124\n\n Abstract\n\nThis EIP specifies the inclusion of the forkid, originally defined in (EIP-2124), as a new field in the Ethereum wire protocol (eth) handshake. This change is implemented as a new version of the wire protocol, eth/64.\n\n Motivation\n\nThe forkid (EIP-2124) was designed to permit two Ethereum nodes to quickly and cheaply decide if they are compatible or not, not only at a genesis/networking level, but also from the perspective of the currently passed network updates (i.e. forks).\n\nEIP-2124 only defines how the forkid is calculated and validated, but does not specify how the forkid should be exchanged between peers. This EIP specifies the inclusion of the forkid as a new field in the Ethereum wire protocol (eth) handshake (releasing a new version, eth/64).\n\nBy cross-validating forkid during the handshake, incompatible nodes can disconnect before expensive block exchanges and validations take place (PoW check, EVM execution, state reconstruction). This further prevents peer slots from being taken up by nodes that are incompatible, but have not yet been detected as such.\n\nFrom a micro perspective, cutting off incompatible nodes from one another ensures that a node only spends its resources on tasks that are genuinely useful to it. The sooner we can decide the remote peer is useless, the less time and processing we expend in vain.\n\nFrom a macro perspective, keeping incompatible nodes partitioned from one another ensures that disjoint clusters retain more resources for maintaining their own chain, thus raising the quality of service for all networks globally.\n\n Specification\n\n Implement forkid generation and validation per EIP-2124.\n Advertise a new eth protocol capability (version) at eth/64.\n\n The old eth/63 protocol should still be kept alive side-by-side, until eth/64 is sufficiently adopted by implementors.\n\n Redefine Status (0x00) for eth/64 to add a trailing forkid field:\n\n Old packet: [protocolVersion, networkId, td, bestHash, genesisHash]\n New packet: [protocolVersion, networkId, td, bestHash, genesisHash, forkid],\nwhere forkid is [forkHash: [4]byte, forkNext: uint64] (fields per EIP-2124 ).\n\nWhenever two peers connect using the eth/64 protocol, the updated Status message must be sent as the protocol handshake, and each peer must validate the remote forkid, disconnecting at a detected incompatibility.\n\n Rationale\n\nThe specification is tiny since most parts are already specified in EIP-2124. eth/63 is not specified as an EIP, but is maintained in the ethereum/devp2p Github repository.\n\n EIP-2124 mentions advertising the forkid in the discovery protocol too. How does that compare to advertising in the eth protocol? Why is the redundancy needed?\n\nAdvertising and validating the forkid in the discovery protocol is a more optimal solution, as it can help avoid the cost of setting up the TCP connection and cryptographic RLPx stream, only to be torn down if eth/64 rejects it.\n\nCompared to the eth protocol however, discovery is a bit fuzzy. The goal there is to suggest potential peers, not to be fool-proof. Information may be outdated, nodes may have changed or disappeared. Discovery can do a rough filtering, but more precision is still needed afterwards.\n\nAdditionally, forkid validation via the discovery protocol requires ENR implementation (EIP-778) and ENR extension support (EIP-868), which is not mandated by the Ethereum network currently. Lastly, the discovery protocol is just one way to find peers, but systems that cannot use UDP or that rely on other mechanism (e.g. DNS discovery)) still need a way to filter connections.\n\n The forkid implicitly contains the genesis hash checksummed into the FORK_HASH field. Why doesn’t this proposal remove the genesisHash field from the eth handshake?\n\nOriginally this EIP did remove it as redundant data, since filtering based on the forkid is a superset of filtering based on genesis hash. The reason for backing out of that decision was that the genesis hash may be useful for other things too, not just connection filtering (network crawlers use it currently to split nodes across networks).\n\nAlthough the forkid will hopefully take over all the roles of the genesis hash currently in use, there’s no reason to be overly aggressive in deduplicating data. It’s fine to keep both side-by-side for now, and remove in a future version when 3rd party infrastructures switch over.\n\n Backwards Compatibility\n\nThis EIP extends the eth protocol handshake in a backwards incompatible way and requires rolling out a new version, eth/64. However, devp2p supports running multiple versions of the same wire protocol side-by-side, so rolling out eth/64 does not require client coordination, since non-updated clients can keep using eth/63.\n\nThis EIP does not change the consensus engine, thus does not require a hard fork.\n\n Test Cases\n\nFor calculating and validating fork IDs, see test cases in EIP-2124.\n\n Security Considerations\n\nNone.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Péter Szilágyi <peterke@gmail.com>, Péter Szilágyi (@karalabe), Tim Beiko (@timbeiko), \"EIP-2364: eth/64: forkid-extended protocol handshake,\" Ethereum Improvement Proposals, no. 2364, November 2019. Available: https://eips.ethereum.org/EIPS/eip-2364.","tokens":1400,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260634393,"hash":"48f4143c3d44f7af78aed73d44b83db750c4dcd4"}
{"url":"https://governance.aave.com/t/arfc-governance-framework-v2/25348/4","domain":"governance.aave.com","title":"[ARFC] Governance Framework v2 - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 20\n\n 4 / 4\n\n Aug 8\n\n Aug 9\n\n post by TokenLogic on Jul 20\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [ARFC] Governance Framework v2\nauthor: @TokenLogic\ncreated: 2026-07-20\n\nSummary\nThis publication presents an overview of the Aave DAO’s Governance Process v2 and, upon implementation, replaces the current Governance Process Document v1. v2 consolidates the governance process, presently spread across v1 and several newer frameworks, into a single canonical reference.\nThe mandatory TEMP CHECK stage of the governance process has been removed, and all role, guardian, and steward mandates have been refreshed to reflect the 2026 service provider landscape. Upon implementation, this framework streamlines the current 19-day process to 13 days, while ensuring risk and technical standards are upheld.\nMotivation\nOverview\nAave’s governance has matured into a lean, Service Provider model built for transparency and speed. This publication provides a holistic overview of Aave DAO’s governance processes and frameworks, designed to keep the DAO efficient, nimble, and structured. A focused group of service providers now delivers the core functions: Aave Labs on development and growth; LlamaRisk on risk; Certora on security; and TokenLogic on finance and growth.\nThis document supersedes the Governance Process Document v1 and shall be maintained over time, always reflecting the community’s current operational structure.\nRationale for retiring TEMP CHECK\nOne of the most significant efficiency improvements to the overall governance process presented here has been the retirement of TEMP CHECK from the standard path. With an emphasis on refining the economics of sequential adjustments in overall market risk, the initial intent to reduce workload on Risk and Technical service providers has been addressed. The process now begins with a business case to determine whether new assets or markets should be deployed.\nFurthermore, since the Governance Process Document v1 was written, the DAO has adopted structured evaluation frameworks, notably the Aave Risk Framework and the Technical Asset Listing Framework, providing clear public criteria that each proposal must satisfy before it can advance. The ARFC stage provides a public discussion window followed by a binding Snapshot vote, providing the community retains a clear opportunity to shape, support, or reject a proposal without running two sequential sentiment rounds.\nA notable distinction: the ARFC vote is binding, allowing the Aave DAO to make commitments before deploying technical resources for larger initiatives, such as deploying Aave Protocol instances, entering new markets within an existing instance, or committing to payment upon delivery of work scopes.\nGovernance Process\nAave’s governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and implement approved changes through a transparent, structured process.\nThe processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate. For more details, please refer to the official documentation.\nEvery type of governance action falls into one of three processes, based upon who they are implemented by:\n\nStandard Process: The default governance process consists of an ARFC governance proposal, a Snapshot vote and an on-chain vote to implement the upgrade. The Short Executor implements the vast majority of AIP proposals, with the Long Executor reserved for major upgrades.\nDirect-to-AIP Process: A refined on-chain voting process designed to enable simple parameter adjustments, not otherwise performed by Stewards, to be implemented quickly.\nSteward Process: This process facilitates high-cadence operational updates implemented by Service Providers within a tightly controlled, limited-access, and bounded environment, allowing the protocol to operate efficiently throughout the market cycle.\n\nimage4296×2163 352 KB\nThe gradual introduction of Steward roles allows for a growing portion of routine upgrades to shift from the Direct-to-AIP process to the Steward Process, streamlining the protocol’s operational readiness by enabling swift action and reducing administrative overhead. Token holders remain critical to shaping the future of business by retaining key decision-making power and electing to delegate daily operations to trusted actors who operate the Steward roles.\nStandard Process\nThe standard governance process for the Aave DAO follows the guidelines outlined below:\nimage2736×2373 376 KB\nReference: Aave Governance. Adjust Level 2 requirements (long-executor)\n\nGovernance Forum - Aave Request for Comment (ARFC)\nThis is where initial discussions take place, and feedback is gathered. Service providers and community members provide detailed feedback over a 4-day period on how the proposal would affect the protocol, helping prepare it for the AIP stage.\n\nSnapshot\nARFC voting takes place in the Aave Snapshot Space.\n\nVoting: If the proposal meets the required Snapshot threshold, it proceeds to the AIP stage; otherwise, it fails. Authors, proposition power, timing, and thresholds are detailed in the Voting section below.\n\nAave Improvement Proposal (AIP)\nThe AIP stage is where the proposal becomes a formal, on-chain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Aave’s governance contracts, primarily on the Ethereum Mainnet.\n\nVoting: Once on-chain, the AIP is voted on through Aave’s governance contracts. The on-chain stages, quorum, and vote differential are described in the Voting section below.\nExecution: A successful proposal moves to the execution phase, where it is enacted via Aave’s governance infrastructure. Depending on the type of proposal, a timelock delay (either 1 day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave’s Delivery Infrastructure (a.DI).\n\nLong Executor\nThe Long Executor (Level 2) governs the most sensitive parts of the protocol, those that define governance itself. It controls upgrades to the AAVE, stkAAVE, and aAAVE tokens, changes to the governance contracts and their permissions, and modifications to the executors and timelocks themselves. In short, it covers any change that could affect voting or proposition power. Because these changes carry the highest impact, the Long Executor applies stricter requirements than the Short Executor (Level 1), which handles day-to-day protocol matters such as asset listings, parameter updates, and treasury operations. A Level 2 proposal runs a longer 10-day voting period, requires a higher quorum and vote differential, and passes through a 7-day timelock before execution, compared with the 3-day vote and 1-day timelock of a Level 1 proposal. For the current thresholds and contract addresses, see the Aave governance documentation.\nimage4296×1857 366 KB\nDirect-to-AIP Process\nTo support timely implementation of protocol upgrades via Token holder vote, the Direct-to-AIP governance process supports a streamlined 2-step process: a forum post followed by an AIP. By removing the Snapshot vote, the Direct-to-AIP process reduces the governance duration by 4 days and the governance burden. This process is intended to expedite minor changes and can only be proposed by active Service Providers. An illustration of the process is shown below:\nimage2736×1671 221 KB\nTo be eligible for this non-standard Tokenholder voter process, an Active Aave DAO Service Provider must submit a Direct-to-AIP proposal that addresses one of the areas mentioned below:\n\nExisting Asset Listing\nExisting Asset Parameter Update (excl. controlled by Stewards)\nExisting Rolling Maturity Asset Listing Eg: Pendle PTs\nEmission Manager updates\nFunding Updates\nWhitelist Flashloan Borrowers (remove fee)\nTechnical Maintenance\nWhitelist addresses to claim rewards\nExtending SVR Integrations to new instances or assets\nCreation of new hubs and spokes on Aave V4 with existing assets\nRisk Parameters not amendable by Steward Role\n\nStewards Process\nStewards assist the DAO in mitigating potential risks by introducing controlled, incremental exposure adjustments and responding quickly to changing market conditions without the delay of the full governance process. The introduction of a steward role strictly enforces programmatic controls, allowing trusted actors to maintain precise parameters within the protocol, thereby fine-tuning it to prevailing market conditions and limiting exposure to adverse events. The principal rationale for introducing Stewards is to both mitigate risk through tightly controlled exposure limits on Assets and maintain operational readiness.\nimage2287×1482 216 KB\nEach steward is a DAO-owned contract that features delegated authority over a narrow set of parameters or operations, bounded in magnitude and frequency by hard-coded and governance-set limits. Governance owns every steward and can revoke it at any time. The current stewards span risk parameters, the GHO stablecoin, treasury and finance operations, cross-chain bridging (in development), bad-debt maintenance, and oracle migration. The Horizon instance is configured through a related delegated model, described at the end of this section.\nimage1920×3746 373 KB\nGHO Stewards\nThe GHO Stewards manage the GHO stablecoin within bounded limits. The current design is GHO Steward v2, a set of four modular contracts, each gated by a one-day timelock and a maximum change per update, and each callable only by the GHO Risk Council. The GHO Risk Council multisig is 0x8513e6F37dBc52De87b166980Fa3F50639694B60, whose signers are TokenLogic, LlamaRisk, and Aave Labs.\nGHO Aave Steward\nManages the GHO reserve in the Aave V3 core pool. It can adjust the GHO borrow and supply caps (up to +100% per update) and the four interest-rate parameters (optimal usage, base rate, slope 1, slope 2), each bounded to ±500 bps per update, with an overall borrow-rate ceiling of 25% APR. It cannot change collateral parameters, the oracle, or any non-GHO reserve. Cooldown: one day per parameter. Address: 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34.\nGHO Bucket Steward\nAdjusts facilitator bucket capacities, the mint ceiling of each controlled facilitator, by up to +100% per update, and only for facilitators on its controlled list. Cooldown: one day per facilitator. Address: 0x46Aa1063e5265b43663E81329333B47c517A5409.\nGHO GSM Steward\nManages the GHO Stability Module: the exposure cap (up to ±100% per update) and the buy and sell fees (up to ±0.50% per update). Freeze, unfreeze, and price-strategy changes are out of scope and require governance. Cooldown: one day per GSM per parameter. Address: 0xD1E856a947CdF56b4f000ee29d34F5808E0A6848.\nGHO CCIP Steward\nManages the cross-chain (Chainlink CCIP) parameters for GHO: the bridge limit and the inbound and outbound rate limits, each bounded to ±100% per update. Cooldown: one day per parameter. Address: 0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39.\nRisk Stewards\nRisk Stewards manage risk parameters within bounds defined by the Aave Risk Framework. They may tighten or calibrate only within these limits; loosening beyond them or releasing a freeze requires governance. Following the departure of Chaos Labs, the manual Risk Steward is operated by LlamaRisk together with Aave Labs, with a progressive migration to Chainlink Runtime Environment (CRE) automation. The Aave DAO retains full control of the automation.\nRisk Steward\nThe main risk steward. It can adjust supply and borrow caps, collateral parameters (LTV, liquidation threshold, liquidation bonus), interest-rate parameters (base rate, slope 1, slope 2, optimal usage), CAPO price-cap and Pendle discount parameters, and e-mode collateral parameters. It cannot set caps, LTV, LT, or liquidation bonus to zero, change an e-mode’s isolated flag or label, or act on restricted assets and oracles (for example, GHO on Ethereum). Per-update bounds and cooldowns:\n\nParameter\nMax change per update\nMinimum delay\nPending change (ARFC)\n\nLTV, LT, LB\n0.5% absolute change\n72 hours\n-\n\nEmode - LTV, LB\n0.5% absolute change\n72 hours\n-\n\nEmode - LT\n0.1% absolute change\n72 hours\n-\n\nBase rate, Slope 1\n1% absolute change\n72 hours\n36h\n\nSlope 2\n20% absolute change\n72 hours\n36h\n\nOptimal Usage Ratio\n3% absolute change\n72 hours\n36h\n\nSupply and borrow caps\n100% relative change\n72 hours\n36h\n\nCAPO Dynamic Cap\n5% relative change\n72 hours\n-\n\nCAPO Stable Cap\n0.5% relative change\n72 hours\n-\n\nPT Discount Rate\n2.5% absolute change\n48 hours\n-\n\nReference: [ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment\nFreezing Steward\nCan freeze a reserve immediately, blocking new supply and borrow while existing positions may still repay and withdraw. It cannot unfreeze; that requires governance. A tighten-only safeguard.\nFinance Stewards\nFinance Stewards execute pre-approved, budgeted treasury operations on behalf of the DAO through contracts that act as admins of the Collector, without a full on-chain vote. They are operated by the Aave Finance Committee (AFC), the multisig 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa, a 2-of-3 organisation-controlled multisig. The DAO retains ownership and can revoke the role.\nMainnet Swap Steward\nLive. Executes treasury token swaps via the CoW Protocol with a Chainlink oracle price check and slippage bounds, supporting market, limit, and TWAP orders, as well as order cancellation. It can only swap into DAO-whitelisted tokens, within per-token budgets, and proceeds always return to the Collector. Address: 0xb7D402138Cb01BfE97d95181C849379d6AD14d19.\nPool Exposure Steward\nLive. Migrates assets from Aave V2 to V3, and deposits or withdraws Collector funds within Aave V3. It cannot move funds outside approved Aave pools or deplete a reserve below its minimum floor. Address: 0x22aC12a6937BBBC0a301AF9154d08EaD95673122.\nCollector Budget Steward\nTransfers or streams Collector tokens to pre-approved recipients within DAO-defined budgets. It cannot send to non-whitelisted addresses or exceed a budget.\nRewards Steward\nLive. Claims liquidity-mining and Merit rewards accrued to the Collector and forwards them to the Collector. It holds no discretionary transfer power, and must first be granted claim rights by the Emission Manager.\nBridge Stewards\nIn development, not yet live. A family of per-route stewards (Polygon, Arbitrum, Optimism, plus CCTP and LayerZero routes) that will move Collector funds cross-chain back to the Ethereum Collector without a full a.DI governance vote. This fills a gap the Pool Exposure Steward cannot cover, since that steward only moves funds within a single chain. Operators will be set at deployment.\nMaintenance Stewards\nClinic Steward\nLive. Batch-liquidates dust and underwater positions and repays accumulated bad debt, funded from the Collector, within a fixed USD budget cap that only an admin can raise. It cannot act outside repayment, liquidation flows, or exceed the budget. Address: 0xf00E2de0E78DFf055A92AD4719a179CE275b6Ef7.\nDeficit Offset Clinic Steward\nLive. The Umbrella-linked sibling of the Clinic Steward, used to offset reserve deficits through Umbrella’s deficit-elimination flow. Address: 0x6c1DC85f2aE71C3DAcd6E44Bb57DEeF61b540a5A.\nSVR Oracle Steward\nLive. Migrates an asset to a Chainlink Smart Value Recapture (SVR) price feed only when its deviation from the current feed is minimal, and lets the Protocol Guardian revert to the previous feed if needed. Address: 0x8b493f416F5F7933cC146b1899c069F2361cad60.\nHorizon\nHorizon is configured through a delegated model rather than standard governance. The Executive role is assigned to Aave Labs, which manages day-to-day risk parameters, asset listings, oracle configuration, and supply and borrow caps directly, without an AIP vote for each change. The Aave DAO retains ownership of the contracts and controls upgrades, and it still configures the GHO facilitator and credit line by governance vote. Reference: [ARFC] Horizon’s RWA Instance.\nVoting\nOnce a proposal meets the required conditions, it can proceed to the voting stages, which include both off-chain and on-chain voting methods. Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives.\nOff-Chain\nOff-chain votes take place in the Aave Snapshot Space and are the community’s directionally binding signal on a proposal before it moves on-chain. They allow token holders to participate without incurring transaction fees. The off-chain voting stage enables the Aave DAO to make a public commitment to deliver something when there is a difference in timing and/or payment between when the business says it will do something and when that commitment is fulfilled.\nAuthors and proposition power. To open a Snapshot vote, the author must be on the approved list of Authors for the Aave space, or hold at least 80,000 AAVE of proposition power. This filters spam while allowing recognised service providers and delegates to propose without holding a large balance.\nimage3096×1743 323 KB\nController. The administration of the Aave DAO Snapshot space is carried out by the Aave Finance Committee SAFE 0x22740deBa78d5a0c24C58C740e3715ec29de1bFawhilst the Controller is configured to 0x9F8F33e0e22F747617654A50305e61AA9811070C, held by Aave Labs as contingency.\nVoting power. Voting weight is the combined balance of AAVE, stkAAVE, and aAAVE that an address holds or has been delegated, measured at the snapshot block taken when the vote opens. Holders can vote directly or delegate their power to a representative.\nTiming and threshold. Once submitted, a Snapshot enters a one-day voting delay, followed by a three-day voting period. A 320,000 AAVE threshold applies: if it is met, the proposal proceeds to the AIP stage; if not, the proposal fails.\nFor further detail, see the Aave governance documentation.\nOn-Chain\nOn-chain voting is required on any Aave Improvement Proposal. Aave on-chain voting will take place on the Aave Governance Portal. With the launch of V3 governance, it is now possible to vote across multiple chains and cast gasless votes.\nThe on-chain voting process is composed of four stages:\n\nFirst, the proposal and payload are reviewed by Security Service Providers to ensure they are not malicious and don’t contain errors that could put the protocol at risk.\nThe second stage is entered if no errors or a malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a 1-day voting delay must pass before it becomes active.\nIn the third stage, once the voting delay has elapsed, the proposal becomes active and available for voting. This stage lasts for 3 days.\nIn the fourth stage, once the voting period has ended, the proposal will be either SUCCEEDED or FAILED, depending on whether it has reached quorum and received a majority of YAE votes. In this stage, if the proposal has passed, the payload is queued with a 1-day timelock; once this has elapsed, the payload may be executed. If the proposal is not executed before the end of the 7-day grace period, it expires and must be deployed and voted on again at the start of the on-chain voting process.\n\nA visual representation of this flow is shown in the figure below.\nimage3576×1593 329 KB\nQuorum\nFor a proposal to succeed, at least 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote, and the winning option must receive at least 320,000 votes.\n\nQuorum-failure rule: a proposal that fails the Snapshot vote due to a lack of quorum, rather than due to a rejecting majority, may reopen the Snapshot once without restarting from the ARFC stage.\nAnti-spam brake: the proposition power and whitelist gate at Snapshot submission.\nFinal token-holder break: the on-chain AIP vote and the one-day timelock.\nMalicious-proposal backstop: the Governance Emergency Guardian retains its power to cancel.\n\nGovernance Frameworks\nThe Aave DAO has predefined frameworks for common types of proposals, simplifying the governance process:\nAsset Onboarding Framework\nStandardised lifecycle for onboarding new assets to the protocol, providing a structured process for risk assessments and community discussions.\nOnboarding the right assets is one of the most direct levers the DAO has for growth. Each new asset can deepen liquidity, expand borrowing demand and protocol revenue, extend GHO’s reach, and unlock integrations and user acquisition. The framework makes that growth deliberate: assets are prioritised by verifiable demand, credible commitments, and strategic fit with the wider Aave business, and are onboarded only once they meet the DAO’s risk and technical standards. The below outlines the asset onboarding and expansion process:\nimage4296×1620 358 KB\nNew Asset Listing\nThe New Asset listing framework uses the Standard Process to list assets on the Aave Protocol for the first time if they have not been listed previously. Introducing a new asset to the Aave Protocol increases the risk surface area and requires rigorous assessment to ensure there is a strong business case for onboarding it.\nOnboarding a new asset is expected to take 13 days following the Standard Process.\nThe Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.\nAsset Listing ARFC Process\nDuring the ARFC stage, a clear business case for onboarding the asset must be provided; the asset then undergoes Risk Analysis and a Technical Assessment to verify its suitability for listing on the Aave Protocol.\nimage4296×969 199 KB\n\nBusiness Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the listing proposal on the governance forum. It presents a clear, validated case for onboarding the asset, including the proposed initial market structure and parameters, and explains how the asset fits the DAO’s broader strategy. Where relevant, it sets out the commitments supporting the listing, such as expected user deposits and debt, incentive budget, liquidity, and planned integrations.\n\nRisk Analysis: The Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.\n\nRisk Assessment: A thorough review of the risks associated with the asset, covering market risk (volatility, liquidity, and secondary-market depth across market conditions), the asset’s historical performance and susceptibility to market fluctuations, and asset-specific legal and compliance considerations. For coinciding asset listings with product launches,\nReference: [ARFC] Aave Risk Framework\n\nAny material finding, such as insufficient DEX liquidity, pauses the listing until it is resolved.\n\nTechnical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the asset’s technical and security profile.\n\nTechnical Assessment: A rigorous review of the asset’s contracts, oracle configuration, access controls, and dependencies, against the requirements of the Technical Asset Listing Framework.\nReference: [ARFC] Technical Asset Listing Framework\n\nAny finding that falls short of Aave’s security standards pauses the listing process until the issue is resolved.\n\nExisting Asset Listing\nThe Existing Asset listing framework applies only to assets already listed on the Aave Protocol; identical assets (syrupAssets) shall follow the Direct-to-AIP process when extending assets to other instances of the Aave Protocol.\nAdding an Existing Asset to an instance of the Aave Protocol is expected to take as little as 5 days following the Direct-to-AIP process.\nThe Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.\nExisting Asset Direct-to-AIP Process\nSimilar to the New Asset Listing framework, each of the three requirements must be met before an AIP is published: Business Case, Risk Analysis and Technical Analysis. Upon completing sufficient due diligence and assessing the expected returns, an AIP shall be published.\nimage4296×969 206 KB\nSimilar to the Asset Listing ARFC process, the Direct-to-AIP shall present the business case for adding the asset to another instance of the Aave Protocol, ensuring a rationale for the listing. In the comments section, Risk and Technical Service Providers are to provide commentary on the proposed parameter configuration and highlight any concerns, including additional dependencies (e.g., bridges) and liquidity considerations.\nNew Network Deployment Framework\nDeploying on a new network extends Aave’s liquidity footprint and revenue base, carries GHO into new ecosystems, and positions the protocol where users, partners, and capital are moving. Because a deployment is a larger commitment than a single listing, the framework weighs the network’s liquidity potential, GHO utility, revenue and integration commitments, and partner distribution before the DAO commits.\nThe New Network Deployment Framework follows the Standard Process for determining whether to deploy a new Aave Protocol instance. This framework provides a transparent approach for evaluating and deploying new instances of the Aave Protocol. The initial ARFC publication focuses on the business case and overall strategy supporting the deployment.\nA single ARFC Snapshot authorises the deployment and can trigger up to three separate on-chain AIP votes. For a deployment with GHO these are: (1) a.DI Path Activation, which registers the Aave Delivery Infrastructure for the new network; (2) CCIP GHO Lanes Activation, which activates the GHO lane on Chainlink’s CCIP; and (3) the Aave Protocol Activation, which brings the market live. The a.DI and CCIP GHO Lanes votes are completed before the Protocol Activation AIP is published. A deployment without GHO omits the CCIP GHO Lanes vote, so only the a.DI Path Activation precedes the Protocol Activation.\nThe Aave DAO requires that at least $150 worth of each listed asset be deposited into the Aave Short Executor before the market goes live.\nimage4296×1329 285 KB\nNew Network Deployment ARFC Process\nFollowing the Standard Process, at the ARFC stage, a clear business case for deploying the Aave Protocol on the network is to be presented to the community. The ARFC publication shall also detail the initial assets to be listed and present a tentative market configuration for discussion.\nGiven the early stage of most networks at the time the Aave Protocol is deployed, some risk considerations, such as DEX liquidity assessments, are based on commitments to provide flexibility in the lead-up to launch.\nimage4296×969 199 KB\n\nBusiness Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the deployment proposal on the governance forum. It presents a clear, validated case for deploying the Aave Protocol on the network, together with the proposed initial market structure: the assets to be listed, their tentative parameters, and how the deployment fits the DAO’s broader strategy. Where relevant, it also sets out the commercial terms supporting the deployment, including the incentive budget, liquidity and integration commitments, GHO utility, and the availability of Chainlink Oracle and CCIP infrastructure.\n\nRisk Analysis: Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.\n\nRisk Assessment: A thorough review of the risks associated with the network and its initial assets, covering chain-level risk (network maturity, decentralisation, and reliability), market risk (asset volatility, liquidity, and secondary-market depth), and asset-specific legal and compliance considerations. Given the early stage of most networks at deployment, some assessments, such as DEX liquidity, may rely on commitments made ahead of launch.\nReference: [ARFC] Aave Risk Framework\n\nAny material finding pauses the deployment until it is resolved.\n\nTechnical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the network’s technical and security profile and that of each listed asset.\n\nTechnical Assessment: A rigorous review of the network’s technical and security details, the a.DI (Aave Delivery Infrastructure) integration, oracle and CCIP availability, and each asset’s contract and oracle configuration.\nReference: [ARFC] Technical Asset Listing Framework\n\nAny finding that falls short of Aave’s security standards pauses the deployment until it is resolved.\n\nimage3696×1440 318 KB\nDirect-to-AIP Framework\nThe purpose of the Direct-to-AIP framework is to enable non-controversial, precise parameter updates to the protocol to be implemented quickly. Within the Aave Protocol, there are a number of parameters or access that can be granted that are not currently supported by Steward roles. The Direct-to-AIP provides a means of quickly updating those parameters and of processing routine, non-controversial operational matters.\nimage4296×1611 300 KB\nGovernance Roles\nDelegates & Delegators\nDelegates\nDelegates are community members who have received voting power from other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have entrusted them with their voting power. Delegates are not compensated.\nDelegators\nDelegators are community members who hold Aave, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another person. The person to whom they delegate their voting power is considered a delegate. This system allows delegators to have their interests represented in governance decisions without having to participate directly in every vote.\nContributors and Service Providers\nContributors\nContributors are community members who participate in and dedicate their time to the Aave DAO. They contribute by joining working groups, fulfilling bounties, building on top of the Aave Protocol, or working for the DAO via grants. Contributors work towards completing shared goals that benefit the Aave ecosystem.\nService Providers\nService providers are specialised entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:\n\nLlamaRisk, risk service provider\nCertora, security service provider\nTokenLogic, finance and growth service provider\nAave Labs, development and growth service provider\n\nGuardians\nThe Aave Guardians safeguard the protocol and the integrity of its governance. They operate as two independent multisigs with distinct mandates: the Protocol Emergency Guardian, which can pause markets and act in a protocol emergency, and the Governance Emergency Guardian, which can cancel malicious or erroneous governance proposals. Across the DAO’s emergency and treasury SAFEs, individual signer identities are increasingly withheld and held within organisation-controlled nested SAFEs, a deliberate practice to reduce attack surface (see the June 2026 signer and SAFE configuration update).\nFor more information on the Guardians’ permissions, refer to this detailed view of permissions in Aave systems. For a general overview of their role, see the Medium post about Aave V2 Governance here.\nProtocol Emergency Guardian\nThis Guardian holds the EMERGENCY_ADMIN role in Aave V3 and equivalent roles in V2 and related systems. Its purpose is to act quickly in an emergency to protect the protocol, for example by pausing a market. Following the May 2026 signer rotation, it operates as a 4-of-7 multisig, and to reduce its attack surface, the signer identities are not publicly disclosed. The current signer addresses are listed below.\n\nProtocol Emergency Guardian (4-of-7)\nSigner address\n\nSigner 1\n0x4Ab2Bed1d667260dB34244Ba412817651C2dD52b\n\nSigner 2\n0xc2674C1A1aF0557E1d217fF4F13DF44A637c7C13\n\nSigner 3\n0xe6838d834674eC35EDd53D485770Baa10bdd6AAe\n\nSigner 4\n0xb291232F480F41c75802C4a60F1D2AC03404Afef\n\nSigner 5\n0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E\n\nSigner 6\n0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe58\n\nSigner 7\n0x3fa960f8355D00874D9C7E3350147f5E94859bc2\n\nGovernance Emergency Guardian\nThis Guardian is responsible for cancelling governance proposals if they are detected as malicious or contain errors, typically identified during the on-chain verification stage by Certora. Unlike the Protocol Emergency Guardian, speed is less critical for this role since governance proposals unfold over a period of five days, allowing adequate time for issues to be identified and addressed. The multi-sig configuration for this Guardian is also a 5-of-9 setup. The current Governance Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nGovernance Emergency Guardian\nAddress\n\nSeb (Zapper)\n0xa1c9ceed5ff78f700dc4930514621843b5fac272\n\nMounir (Paraswap)\n0xfd639f49Da6cadc98f01B60900C8BE30C38c4B27\n\nGavi Galloway (Standard Crypto)\n0xbd4DCfA978c6D0d342cE36809AfFFa49d4B7f1F7\n\nNenad (Defi Saver)\n0xDA5Ae43e179987a66B9831F92223567e1F38BE7D\n\nFernando (Balancer)\n0x4C30E33758216aD0d676419c21CB8D014C68099f\n\nRoger (Chainlink community)\n0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396\n\nMariano Conti (DeFi OG)\n0x936CD9654271083cCF93A975919Da0aB3Bc99EF3\n\nMarin (Lido)\n0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nTemplates\nThe standard ARFC templates are collected here for reference. When drafting a proposal, copy the relevant template and adapt it to the specific asset, network, or change.\n\nAsset Listing ARFC Template\n\nTitle: [ARFC] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD\n\nSummary\nThis ARFC proposes onboarding to the Aave instance on the .\nMotivation\nExplain the motivation for listing the Token.\n\nBusiness Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.\n\nA general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.\n\nAt the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in an unapproved or unsanctioned category should not proceed.\nReference: [ARFC] Endorse the Asset Classification Framework (AAcA)\nThe initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.\n\nSpecification\nTicker:\nContract address:\nChainlink oracle:\n\nParameter\nv3\nv4\nValue\n\nNetwork\nYes\nYes\n\nInstance of Aave Protocol\nYes\nYes\n\nHub (Core / Prime / Plus)\nn/a\nYes\n\nSpoke / Spoke type\nn/a\nYes\n\nIsolation Mode\nYes\nn/a\n\nDebt Ceiling\nYes\nn/a\n\nSiloed Borrowing\nYes\nn/a\n\nBorrowable in Isolation\nYes\nn/a\n\nBorrowable\nYes\nYes\n\nCollateral enabled / Collateral-only\nYes\nYes\n\nSupply Cap (v3) / Add Cap (v4)\nYes\nYes\n\nBorrow Cap (v3) / Draw Cap (v4)\nYes\nYes\n\nCredit Line Size / Draw Cap\nn/a\nYes\n\nLTV\nYes\nn/a\n\nLiquidation Threshold (LT)\nYes\nn/a\n\nCollateral Factor (CF)\nn/a\nYes\n\nLiquidation Bonus\nYes\nn/a\n\nMax Liquidation Bonus\nn/a\nYes\n\nLiquidation Bonus Factor\nn/a\nYes\n\nHealth Factor for Max Bonus\nn/a\nYes\n\nLiquidation Protocol Fee\nYes\nYes\n\nCollateral Risk (bps)\nn/a\nYes\n\nVariable Base\nYes\nYes\n\nSlope 1\nYes\nYes\n\nSlope 2\nYes\nYes\n\nUoptimal\nYes\nYes\n\nReserve Factor (v3) / Liquidity Fee (v4)\nYes\nYes\n\nOracle Type (Chainlink SVR / CAPO / Pendle)\nYes\nYes\n\nCAPO: Max Yearly Ratio Growth %\nYes\nYes\n\nCAPO: Minimum Snapshot Delay\nYes\nYes\n\nPrice Cap (stablecoin / CAPO)\nYes\nYes\n\nPendle: Discount Rate / Max per year\nYes\nYes\n\nFlashloanable\nYes\nYes\n\nE-Mode Category (v3) / E-Mode Spoke (v4)\nYes\nYes\n\nDisclaimer\nStatement of the author’s potential conflict of interest and relationship with the asset protocol, and if they received compensation for publishing this proposal\nNext Steps\n\nIf consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.\nIf the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal\n\nCopyright\nCopyright and related rights waived via CC0.\n\nAsset Listing Direct-to-AIP Template\n\nTitle: [Direct-to-AIP] Template\nAuthor:\nDate: 2026-06-06\n\nSummary\nA brief sentence or two introducing the proposal’s topic. Specifically, the parameters to be updated, which instance of the Aave Protocol and which chains are affected.\nMotivation\nThis section outlines the reasoning, often supported by a business case and supporting analysis, allowing voters to make an informed decision at the time of the vote.\nWhere applicable, include:\n\nThe problem or opportunity being addressed.\nThe rationale for the proposed changes.\nSupporting analysis, research, or market data.\nExpected impact on protocol performance, capital efficiency, risk, or user experience.\nAny relevant business, technical, or governance considerations.\n\nThis section should focus on why the proposal should be implemented, while the Specification section describes how it will be implemented.\nFor assets extended to other instances of the Aave Protocol, as with the original ARFC to list the asset, this section shall include the Business Case supporting the listing. Please see the earlier section for further details.\nSpecification\nA summary of the technical changes to be implemented at the AIP stage.\nThis section should include all information necessary to construct the governance payload, including, where applicable:\n\nMarkets and networks affected.\nAssets affected.\nCurrent values.\nProposed values.\nSmart contracts or protocol components impacted.\nAny implementation or execution considerations.\n\nDisclaimer\nThe author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this Direct-to-AIP proposal.\nNext Steps\n\nPublish an AIP vote for final confirmation and on-chain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\nExisting Asset Listing Direct-to-AIP Template\n\nTitle: [Direct-to-AIP] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD\n\nSummary\nThis Direct-to-AIP proposes onboarding to the Aave instance on the .\nMotivation\nExplain the motivation for onboarding this asset to another instance of the Aave Protocol.\n\nBusiness Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.\n\nA general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.\n\nThe initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.\nReference: [ARFC] Endorse the Asset Classification Framework (AAcA)\n\nSpecification\nTicker:\nContract address:\nChainlink oracle:\n\nParameter\nv3\nv4\nValue\n\nNetwork\nYes\nYes\n\nInstance of Aave Protocol\nYes\nYes\n\nHub (Core / Prime / Plus)\nn/a\nYes\n\nSpoke / Spoke type\nn/a\nYes\n\nIsolation Mode\nYes\nn/a\n\nDebt Ceiling\nYes\nn/a\n\nSiloed Borrowing\nYes\nn/a\n\nBorrowable in Isolation\nYes\nn/a\n\nBorrowable\nYes\nYes\n\nCollateral enabled / Collateral-only\nYes\nYes\n\nSupply Cap (v3) / Add Cap (v4)\nYes\nYes\n\nBorrow Cap (v3) / Draw Cap (v4)\nYes\nYes\n\nCredit Line Size / Draw Cap\nn/a\nYes\n\nLTV\nYes\nn/a\n\nLiquidation Threshold (LT)\nYes\nn/a\n\nCollateral Factor (CF)\nn/a\nYes\n\nLiquidation Bonus\nYes\nn/a\n\nMax Liquidation Bonus\nn/a\nYes\n\nLiquidation Bonus Factor\nn/a\nYes\n\nHealth Factor for Max Bonus\nn/a\nYes\n\nLiquidation Protocol Fee\nYes\nYes\n\nCollateral Risk (bps)\nn/a\nYes\n\nVariable Base\nYes\nYes\n\nSlope 1\nYes\nYes\n\nSlope 2\nYes\nYes\n\nUoptimal\nYes\nYes\n\nReserve Factor (v3) / Liquidity Fee (v4)\nYes\nYes\n\nOracle Type (Chainlink SVR / CAPO / Pendle)\nYes\nYes\n\nCAPO: Max Yearly Ratio Growth %\nYes\nYes\n\nCAPO: Minimum Snapshot Delay\nYes\nYes\n\nPrice Cap (stablecoin / CAPO)\nYes\nYes\n\nPendle: Discount Rate / Max per year\nYes\nYes\n\nFlashloanable\nYes\nYes\n\nE-Mode Category (v3) / E-Mode Spoke (v4)\nYes\nYes\n\nDisclaimer\nThe author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this ARFC.\nNext Steps\n\nPublish an AIP vote for final confirmation and on-chain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\nNew Network Deployment ARFC Template\n\nTitle: [ARFC] Deploy Aave on \nAuthor:\nDate: YYYY-MM-DD\n\nSummary\nThis ARFC proposes deploying the Aave Protocol to the .\nMotivation\nProvide a comprehensive overview of the new deployment, including its technical features, security measures, and any unique benefits it brings to the Aave ecosystem. This section will focus on the following key areas:\n\nNetwork Capabilities: Transactions per second, latency, finality, scalability, security and interoperability.\n\nMarket Positioning: Details what makes this network unique from technical, user distribution, focus areas, and/or strategic alignment perspectives, with the goal of distinguishing this network from others.\n\nBusiness Case: This details the core value proposition for deploying the Aave Protocol on the respective network. The business case will take into consideration the effects of future liquidity, user adoption, market growth, strategic positioning and revenue potential, with a clear vision for the market over time.\nThe following presents a non-exhaustive list of key areas for consideration when compiling the business case:\n\nIncentive Budget.\nLiquidity commitments.\nGHO utility beyond the Aave Protocol.\nRevenue commitment.\nIntegration commitments.\nPartner’s distribution potential.\nAvailability of Chainlink’s Oracle and CCIP capabilities.\n\nTo support Tokenholders making a fully informed decision, the commercial terms supporting the deployment are to be clearly communicated while respecting any non-public information limitations.\n\nUseful Links: Any additional information that can help Aave DAO to decide. This may include recent announcements, links to documentation, a roadmap for network and ecosystem development, and plans.\n\nSpecification\nThis section contains the initial market structure, assets to be included and how the protocol is to be configured. The initial proposed parameters for the deployment should take into account any Unique Selling Points and desired go-to-market strategies, and be configured/positioned to attract users under prevailing market conditions.\n\nParameter\nAsset 1\nAsset 2\nAsset 3\n\nAsset\nwstETH\nWETH\nUSDT0\n\nBorrowable\n\nCollateral Enabled\n\nSupply Cap\n\nBorrow Cap\n\nDebt Ceiling\n\nLTV\n\nLT\n\nLiquidation Bonus\n\nLiquidation Protocol Fee\n\nVariable Base\n\nVariable Slope1\n\nVariable Slope2\n\nUoptimal\n\nReserve Factor\n\nStable Borrowing\n\nFlashloanable\n\nSiloed Borrowing\n\nBorrowable in Isolation\n\nE-Mode\n1\n1\n\nE-Mode Configurations\nwstETH Correlated #1\n\nParameter\nValue\nValue\n\nAsset\nwstETH\nWETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nMax LTV\n94.00%\n-\n\nLiquidation Threshold\n96.00%\n-\n\nLiquidation Bonus\n1.00%\n-\n\nCAPO\n\nAsset\nmaxYearlyRatioGrowthPercent\nratioReferenceTime\nMINIMUM_SNAPSHOT_DELAY\n\nwstETH\n9.68%\nMonthly\n7\n\nDisclaimer\nA statement of the author’s potential conflicts of interest, their relationship with the network or asset issuers, and whether they received compensation for publishing this proposal.\nNext Steps\n\nCommunity Engagement: Engage with the Aave community to gather feedback on the proposed framework for the new Aave Protocol deployment.\nARFC Snapshot: If community sentiment is favourable, initiate an ARFC snapshot to gauge official support for the framework.\nImplementation: If the Snapshot vote passes, the proposal as outlined shall be implemented by the respective Service Providers.\n\nCopyright\nCopyright and related rights waived under CC0.\n\nReferences\nAave Governance Process Document v1\n[ARFC] Aave Governance. Adjust Level 2 requirements (long-executor)\n[ARFC] Update the Asset Onboarding Framework\n[ARFC Addendum] Update Asset Onboarding Framework\n[ARFC] Technical Asset Listing Framework\n[ARFC] Direct-to-AIP Framework\n[ARFC] New Chain Deployment Framework\n[ARFC ADDENDUM] Mandatory Disclosures and Conflict-of-Interest Voting Norms\n[ARFC] Aave Risk Framework\n[ARFC] Emission Manager Framework Update\n[ARFC] Aave V3 Caps update Framework\nDisclosure\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is YAE, this proposal will be implemented.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n Update on Aave Horizon Asset Onboarding Process\n\n [ARFC] GHO Stewards Signer Update\n\n read \n\n 16\n min\n\n Pinned on Jul 20\n\n 17 days later\n\n post by Abel189 on Aug 7\n\n Abel189\n\n Thank you for the proposal.\nI support the objective of simplifying and consolidating the governance framework into a single reference document. As the DAO grows, having one canonical process should make governance easier to understand for both existing delegates and new participants.\nOne suggestion would be to periodically review the impact of these governance changes after implementation. In particular, it would be useful to monitor whether removing the mandatory TEMP CHECK affects proposal quality, community participation, delegate engagement, or the number of proposals requiring significant revisions during the ARFC stage. Publishing this information after several months would allow governance to evaluate whether the streamlined process is achieving its intended goals while preserving meaningful community review.\n\n post by Millesimillia on Aug 9\n\n Millesimillia\n\n Dear all,\nThank you for the proposal. I think it makes sense to review and improve governance processes every now and then. Simple question from me:\nWho can propose ARFCs for governance topics in the future?\nI read that in some cases (e.g., new listing) this must be done by official service providers. I hope this is not the case for all AFRCs.\nReason: I am an investor and looking forward to hearing more about how Aave token economics will effectively be kept strong or strengthened - especially vis-a-vis service providers who might also have more hidden incentives such as their own stock or revenues allocations.\nPotential future governance topics could include investment decisions, buybacks, provider selection criterias, service provider reviews, etc..\nKnowing that all topics can be brought forward and will be addressed on governance discussions would give me comfort/trust and be in the interests of Aave token holders.\nThanks for your thoughts and comments.\nWarm regards, Millesimillia\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Technical Asset Listing Framework\n\n General\n\n 7\n\n 1.5k\n\n Jul 17\n\n Aave Governance Process Document v1\n\n Governance\n\n 3\n\n 5.3k\n\n Sep 2024\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14","tokens":12089,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260636426,"hash":"4b13d5f20d7fa3084b77dfd4355ec4fa3763968d"}
{"url":"https://eips.ethereum.org/EIPS/eip-2481","domain":"eips.ethereum.org","title":"EIP-2481: eth/66 request identifier","text":"🎉 Final\n\n Standards Track: Networking\n\n EIP-2481: eth/66 request identifier\n\n Introduces a request id for all requests of the eth protocol\n\n Authors\n Christoph Burgdorf (@cburgdorf)\n\n Created\n 2020-01-17\n\n Requires\n\n EIP-2464\n\n Abstract\n\nThe eth protocol defines various request and response commands that are used to exchange data between Ethereum nodes. For example, to ask a peer node for a specific set of headers, a node sends it the GetBlockHeaders command.\n\nCiting from the GetBlockHeaders spec definition:\n\n [block: {P, B_32}, maxHeaders: P, skip: P, reverse: P in {0, 1}]\n\n Require peer to return a BlockHeaders message. Reply must contain a number of block\nheaders, of rising number when reverse is 0, falling when 1, skip blocks apart,\nbeginning at block block (denoted by either number or hash) in the canonical chain, and\nwith at most maxHeaders items.\n\nThe node that receives the GetBlockHeaders command should answer it with the BlockHeaders response command accordingly.\n\nCiting from the BlockHeaders spec definition:\n\n [blockHeader_0, blockHeader_1, ...]\n\n Reply to GetBlockHeaders. The items in the list (following the message ID) are block\nheaders in the format described in the main Ethereum specification, previously asked for\nin a GetBlockHeaders message. This may validly contain no block headers if none of the\nrequested block headers were found. The number of headers that can be requested in a\nsingle message may be subject to implementation-defined limits.\n\nLet’s consider a client making many simultaneous requests for GetBlockHeaders to one of its peers. By nature it can not be guaranteed that the expected responses arrive in the same order as they were sent. For the client to associate the incoming responses to the correct requests it has to loop through all pending requests trying to match it with the incoming response based on its contents.\n\nThis can be particular tricky for responses that are ambiguous such as empty responses.\n\nThis EIP proposes to change the GetBlockHeaders and the BlockHeaders command to include a request_id.\n\nThe request_id is a 64-bit integer set by the client when it makes the request. On the responding side, the exact same request_id from the incoming request is put back into the response object.\n\nThis change allows the requesting client to match incoming responses directly back to their pending requests without going through all of the pending requests to check if they might match based on the response data.\n\nThe selected request/response pair serves as an example for many similar request/response pairs in the eth networking protocol.\n\n Motivation\n\nThe lack of request identifiers in the request / response paris of the eth protocol puts unnecessary burden of code complexity into every Ethereum client. It also makes the communication slightly less efficient. Another argument can be made that the addition of request identifiers makes the protocol more aligned with the les protocol which does already defines request identifiers for each request / response pair.\n\n Specification\n\nChange the following message types in the eth protocol:\n\n GetBlockHeaders (0x03)\n\n Current (eth/65): [block: {P, B_32}, maxHeaders: P, skip: P, reverse: P in {0, 1}]\n Then (eth/66): [request_id: P, [block: {P, B_32}, maxHeaders: P, skip: P, reverse: P in {0, 1}]]\n\n BlockHeaders (0x04)\n\n Current (eth/65): [blockHeader_0, blockHeader_1, ...]\n Then (eth/66): [request_id: P, [blockHeader_0, blockHeader_1, ...]]\n\n GetBlockBodies (0x05)\n\n Current (eth/65): [hash_0: B_32, hash_1: B_32, ...]\n Then (eth/66): [request_id: P, [hash_0: B_32, hash_1: B_32, ...]]\n\n GetPooledTransactions (0x09):\n\n Current (eth/65)[hash_0: B_32, hash_1: B_32, ...]\n Then (eth/66)[request_id: P, [hash_0: B_32, hash_1: B_32, ...]]\n\n PooledTransactions (0x0a):\n\n Current (eth/65)[[nonce: P, receivingAddress: B_20, value: P, ...], ...]\n Then (eth/66)[request_id: P, [[nonce: P, receivingAddress: B_20, value: P, ...], ...]]\n\n BlockBodies (0x06)\n\n Current (eth/65): [hash_0: B_32, hash_1: B_32, ...]\n Then (eth/66): [request_id: P, [hash_0: B_32, hash_1: B_32, ...]]\n\n GetNodeData (0x0d)\n\n Current (eth/65): [hash_0: B_32, hash_1: B_32, ...]\n Then (eth/66): [request_id: P, [hash_0: B_32, hash_1: B_32, ...]]\n\n NodeData (0x0e)\n\n Current (eth/65): [value_0: B, value_1: B, ...]\n Then (eth/66): [request_id: P, [value_0: B, value_1: B, ...]]\n\n GetReceipts (0x0f)\n\n Current (eth/65): [blockHash_0: B_32, blockHash_1: B_32, ...]\n Then (eth/66): [request_id: P, [blockHash_0: B_32, blockHash_1: B_32, ...]]\n\n Receipts (0x10)\n\n Current (eth/65): [[receipt_0, receipt_1], ...]\n Then (eth/66): [request_id: P, [[receipt_0, receipt_1], ...]]\n\nTo elaborate, each command is altered in the following way:\n\n Create a list with the request_id being the first element.\n Make the second element the list that defines the whole command in the current scheme.\n\nThe request_id has the following characteristics:\n\n 64 bit integer\n Doesn’t need to be sequential (can be random)\n Does allow duplicates\n\n Rationale\n\nQ: The efficiency gains might encourage clients to flood their peers with too many simultaneous requests\n\nPeers can always throttle or disconnect if they don’t feel treated well. This is the same as today.\n\nQ: If les already defines the commands like this, why not just use the les protocol?\n\nIn practice, peers that serve the les protocol are much harder to find in the network. The reasons for this are varied but might boil down to client defaults, immature implementations or missing incentives.\n\nQ: Networking works today, isn’t this just adding bloat?\n\nThis is adding a single integer per command while at the same time reducing code complexity and improving networking efficiency. The addition seems justified.\n\nQ: Why not demand request ids to be sequential?\n\nAssuming request ids start always to count from 0 upon connection, things will become messy when\nconnections are lost and clients reconnect and start over with the same request ids that they had used\nin the previous session.\n\nQ: Why allow duplicate request ids?\n\nThe main benefit is flexibility and simplicity on the implementation side. Clients could decide to share\nthe same ids across multiple different request types since they are naturally separated anyway. Clients\ncould even decide to not rely on request ids at all, therefore using the same constant request id across\nall requests.\n\nQ: Why choose a 64-bit integer for the request ids\n\n64-bit integer were chosen to keep compatibility with the les protocol.\n\n Backwards Compatibility\n\nThis EIP extends the eth protocol in a backwards incompatible way and requires rolling out a new version, eth/66. However, devp2p supports running multiple versions of the same wire protocol side-by-side, so rolling out eth/66 does not require client coordination, since non-updated clients can keep using eth/65.\n\nThis EIP does not change the consensus engine, thus does not require a hard fork.\n\n Test Cases\n\nThese testcases cover RLP-encoding of all the redefined messages types, where the rlp portion is the rlp-encoding of the message defined in the data portion.\n\n{\n \"type\": \"GetBlockHeadersPacket66\",\n \"rlp\": \"0xe8820457e4a000000000000000000000000000000000000000000000000000000000deadc0de050580\",\n \"data\": {\n \"RequestId\": 1111,\n \"Origin\": {\n \"Hash\": \"0x00000000000000000000000000000000000000000000000000000000deadc0de\",\n \"Number\": 0\n },\n \"Amount\": 5,\n \"Skip\": 5,\n \"Reverse\": false\n }\n}\n\n{\n \"type\": \"GetBlockHeadersPacket66\",\n \"rlp\": \"0xca820457c682270f050580\",\n \"data\": {\n \"RequestId\": 1111,\n \"Origin\": {\n \"Hash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"Number\": 9999\n },\n \"Amount\": 5,\n \"Skip\": 5,\n \"Reverse\": false\n }\n}\n\n{\n \"type\": \"BlockHeadersPacket66\",\n \"rlp\": \"0xf90202820457f901fcf901f9a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000940000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000b90100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008208ae820d0582115c8215b3821a0a827788a00000000000000000000000000000000000000000000000000000000000000000880000000000000000\",\n \"data\": {\n \"RequestId\": 1111,\n \"BlockHeadersPacket\": [\n {\n \"parentHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"sha3Uncles\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"miner\": \"0x0000000000000000000000000000000000000000\",\n \"stateRoot\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"transactionsRoot\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"receiptsRoot\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"logsBloom\": \"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\n \"difficulty\": \"0x8ae\",\n \"number\": \"0xd05\",\n \"gasLimit\": \"0x115c\",\n \"gasUsed\": \"0x15b3\",\n \"timestamp\": \"0x1a0a\",\n \"extraData\": \"0x7788\",\n \"mixHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"nonce\": \"0x0000000000000000\",\n \"hash\": \"0x8c2f2af15b7b563b6ab1e09bed0e9caade7ed730aec98b70a993597a797579a9\"\n }\n ]\n }\n}\n\n{\n \"type\": \"GetBlockBodiesPacket66\",\n \"rlp\": \"0xf847820457f842a000000000000000000000000000000000000000000000000000000000deadc0dea000000000000000000000000000000000000000000000000000000000feedbeef\",\n \"data\": {\n \"RequestId\": 1111,\n \"GetBlockBodiesPacket\": [\n \"0x00000000000000000000000000000000000000000000000000000000deadc0de\",\n \"0x00000000000000000000000000000000000000000000000000000000feedbeef\"\n ]\n }\n}\n\n{\n \"type\": \"BlockBodiesPacket66\",\n \"rlp\": \"0xf902dc820457f902d6f902d3f8d2f867088504a817c8088302e2489435353535353535353535353535353535353535358202008025a064b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c12a064b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c10f867098504a817c809830334509435353535353535353535353535353535353535358202d98025a052f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afba052f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afbf901fcf901f9a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000940000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000b90100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008208ae820d0582115c8215b3821a0a827788a00000000000000000000000000000000000000000000000000000000000000000880000000000000000\",\n \"data\": {\n \"RequestId\": 1111,\n \"BlockBodiesPacket\": [\n {\n \"Transactions\": [\n {\n \"nonce\": \"0x8\",\n \"gasPrice\": \"0x4a817c808\",\n \"gas\": \"0x2e248\",\n \"to\": \"0x3535353535353535353535353535353535353535\",\n \"value\": \"0x200\",\n \"input\": \"0x\",\n \"v\": \"0x25\",\n \"r\": \"0x64b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c12\",\n \"s\": \"0x64b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c10\",\n \"hash\": \"0x588df025c4c2d757d3e314bd3dfbfe352687324e6b8557ad1731585e96928aed\"\n },\n {\n \"nonce\": \"0x9\",\n \"gasPrice\": \"0x4a817c809\",\n \"gas\": \"0x33450\",\n \"to\": \"0x3535353535353535353535353535353535353535\",\n \"value\": \"0x2d9\",\n \"input\": \"0x\",\n \"v\": \"0x25\",\n \"r\": \"0x52f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afb\",\n \"s\": \"0x52f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afb\",\n \"hash\": \"0xf39c7dac06a9f3abf09faf5e30439a349d3717611b3ed337cd52b0d192bc72da\"\n }\n ],\n \"Uncles\": [\n {\n \"parentHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"sha3Uncles\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"miner\": \"0x0000000000000000000000000000000000000000\",\n \"stateRoot\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"transactionsRoot\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"receiptsRoot\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"logsBloom\": \"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\n \"difficulty\": \"0x8ae\",\n \"number\": \"0xd05\",\n \"gasLimit\": \"0x115c\",\n \"gasUsed\": \"0x15b3\",\n \"timestamp\": \"0x1a0a\",\n \"extraData\": \"0x7788\",\n \"mixHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"nonce\": \"0x0000000000000000\",\n \"hash\": \"0x8c2f2af15b7b563b6ab1e09bed0e9caade7ed730aec98b70a993597a797579a9\"\n }\n ]\n }\n ]\n }\n}\n\n{\n \"type\": \"GetNodeDataPacket66\",\n \"rlp\": \"0xf847820457f842a000000000000000000000000000000000000000000000000000000000deadc0dea000000000000000000000000000000000000000000000000000000000feedbeef\",\n \"data\": {\n \"RequestId\": 1111,\n \"GetNodeDataPacket\": [\n \"0x00000000000000000000000000000000000000000000000000000000deadc0de\",\n \"0x00000000000000000000000000000000000000000000000000000000feedbeef\"\n ]\n }\n}\n\n{\n \"type\": \"NodeDataPacket66\",\n \"rlp\": \"0xce820457ca84deadc0de84feedbeef\",\n \"data\": {\n \"RequestId\": 1111,\n \"NodeDataPacket\": [\n \"0xdeadc0de\",\n \"0xfeedbeef\"\n ]\n }\n}\n\n{\n \"type\": \"GetReceiptsPacket66\",\n \"rlp\": \"0xf847820457f842a000000000000000000000000000000000000000000000000000000000deadc0dea000000000000000000000000000000000000000000000000000000000feedbeef\",\n \"data\": {\n \"RequestId\": 1111,\n \"GetReceiptsPacket\": [\n \"0x00000000000000000000000000000000000000000000000000000000deadc0de\",\n \"0x00000000000000000000000000000000000000000000000000000000feedbeef\"\n ]\n }\n}\n\n{\n \"type\": \"ReceiptsPacket66\",\n \"rlp\": \"0xf90172820457f9016cf90169f901668001b9010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f85ff85d940000000000000000000000000000000000000011f842a0000000000000000000000000000000000000000000000000000000000000deada0000000000000000000000000000000000000000000000000000000000000beef830100ff\",\n \"data\": {\n \"RequestId\": 1111,\n \"ReceiptsPacket\": [\n [\n {\n \"root\": \"0x\",\n \"status\": \"0x0\",\n \"cumulativeGasUsed\": \"0x1\",\n \"logsBloom\": \"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\n \"logs\": [\n {\n \"address\": \"0x0000000000000000000000000000000000000011\",\n \"topics\": [\n \"0x000000000000000000000000000000000000000000000000000000000000dead\",\n \"0x000000000000000000000000000000000000000000000000000000000000beef\"\n ],\n \"data\": \"0x0100ff\",\n \"blockNumber\": \"0x0\",\n \"transactionHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"transactionIndex\": \"0x0\",\n \"blockHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"logIndex\": \"0x0\",\n \"removed\": false\n }\n ],\n \"transactionHash\": \"0x00000000000000000000000000000000000000000000000000000000deadc0de\",\n \"contractAddress\": \"0x0000000000000000000000000000000000011111\",\n \"gasUsed\": \"0x1b207\",\n \"blockHash\": \"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"transactionIndex\": \"0x0\"\n }\n ]\n ]\n }\n}\n\n{\n \"type\": \"GetPooledTransactionsPacket66\",\n \"rlp\": \"0xf847820457f842a000000000000000000000000000000000000000000000000000000000deadc0dea000000000000000000000000000000000000000000000000000000000feedbeef\",\n \"data\": {\n \"RequestId\": 1111,\n \"GetPooledTransactionsPacket\": [\n \"0x00000000000000000000000000000000000000000000000000000000deadc0de\",\n \"0x00000000000000000000000000000000000000000000000000000000feedbeef\"\n ]\n }\n}\n\n{\n \"type\": \"PooledTransactionsPacket66\",\n \"rlp\": \"0xf8d7820457f8d2f867088504a817c8088302e2489435353535353535353535353535353535353535358202008025a064b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c12a064b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c10f867098504a817c809830334509435353535353535353535353535353535353535358202d98025a052f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afba052f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afb\",\n \"data\": {\n \"RequestId\": 1111,\n \"PooledTransactionsPacket\": [\n {\n \"nonce\": \"0x8\",\n \"gasPrice\": \"0x4a817c808\",\n \"gas\": \"0x2e248\",\n \"to\": \"0x3535353535353535353535353535353535353535\",\n \"value\": \"0x200\",\n \"input\": \"0x\",\n \"v\": \"0x25\",\n \"r\": \"0x64b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c12\",\n \"s\": \"0x64b1702d9298fee62dfeccc57d322a463ad55ca201256d01f62b45b2e1c21c10\",\n \"hash\": \"0x588df025c4c2d757d3e314bd3dfbfe352687324e6b8557ad1731585e96928aed\"\n },\n {\n \"nonce\": \"0x9\",\n \"gasPrice\": \"0x4a817c809\",\n \"gas\": \"0x33450\",\n \"to\": \"0x3535353535353535353535353535353535353535\",\n \"value\": \"0x2d9\",\n \"input\": \"0x\",\n \"v\": \"0x25\",\n \"r\": \"0x52f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afb\",\n \"s\": \"0x52f8f61201b2b11a78d6e866abc9c3db2ae8631fa656bfe5cb53668255367afb\",\n \"hash\": \"0xf39c7dac06a9f3abf09faf5e30439a349d3717611b3ed337cd52b0d192bc72da\"\n }\n ]\n }\n}\n\n Security Considerations\n\nNone\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Christoph Burgdorf (@cburgdorf), \"EIP-2481: eth/66 request identifier,\" Ethereum Improvement Proposals, no. 2481, January 2020. Available: https://eips.ethereum.org/EIPS/eip-2481.","tokens":4931,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260646042,"hash":"ac5b304844b6cd203ec60df1393a6af817c787d5"}
{"url":"https://governance.aave.com/t/who-can-bring-governance-topics-to-a-vote-under-governance-framework-v2/25462","domain":"governance.aave.com","title":"Who can bring governance topics to a vote under Governance Framework v2? - Governance - Aave","text":"Who can bring governance topics to a vote under Governance Framework v2? \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 10\n\n 1 / 3\n\n Aug 10\n\n Aug 10\n\n post by Millesimillia on Aug 10\n\n Millesimillia\n\n I raised this question in the [ARFC] Governance Framework v2 thread on 9 August, while the Snapshot was still open: [ARFC] Governance Framework v2 - #4 by Millesimillia\nIt did not receive a response, and the vote has since closed with 392,100 AAVE in favour and none against. I am opening it here so it has a proper home. This is a request for clarification, not an objection to the framework.\nIn the framework, author restrictions appear in three places only: the business case for a New Asset Listing and for a New Network Deployment, both reserved to Aave Labs or TokenLogic, and the Direct-to-AIP path, limited to active Service Providers. The Standard Process does not appear to restrict ARFC authorship.\n\nIs it correct that any token holder may author an ARFC on topics outside asset listings and network deployments - tokenomics, buybacks, service provider selection criteria, service provider reviews?\n\nOpening a Snapshot requires a place on the Authors list or 80,000 AAVE of proposition power. What is the route for a holder below that threshold whose ARFC has community support? Is there a sponsoring mechanism, and who maintains the Authors list?\n\nWith TEMP CHECK retired, what is the intended low-barrier entry point for community-initiated topics?\n\nCommitments have been made in governance discussions that token economics would remain firmly in view, and I take them in good faith. My question is structural rather than about intent: what keeps token economics transparent to holders over time, when every service provider also carries equity and revenue interests of its own? Concretely, is there a fixed reporting cadence on protocol revenue and its allocation that does not depend on which provider holds which mandate?\n\nIf the reading above is correct, I would ask that a short subsection on community-initiated proposals be added: who may author an ARFC, the route to Snapshot for authors below the threshold, and who maintains the Authors list. The framework states that it shall be maintained over time, so this seems a natural place for it.\nTransparency and accountability on these points would make AAVE stronger, not weaker. Over the medium term I would like holders to be able to judge the token the way shareholders judge a company: on disclosed economics, a predictable reporting rhythm, and a clear line from protocol revenue to the token.\nDisclosure: I am an AAVE holder and staker, without material proposition power. I am not compensated by any party and hold no position with any service provider.\nWarm regards,\nMillesimillia (Edited)\n@TokenLogic\n\n Areta Delegate Platform\n\n post by MconnectDAO on Aug 10\n\n MconnectDAO\n\n I strongly support this question. Aave governance should not only reward those who already have enough voting power or the right connections to move an idea forward.\nStrong proposals can come from any holder, researcher, delegate, or community member. The forum should give serious attention to ideas based on their quality, evidence, and value for Aave, not only on who brings them.\nWe need a clear path for community proposals that receive genuine support but come from authors below the Snapshot threshold. A transparent sponsor process, clear criteria for the Authors list, and public timelines for review would make participation more fair.\nAt the same time, proposals should be judged on impact, risk, and long term benefit. Sometimes well presented proposals move ahead despite limited value, while strong ideas are left behind because the author lacks access or visibility.\nOpen participation with clear accountability will make Aave governance stronger and help ensure that the best ideas get a real chance to be discussed and voted on. @Millesimillia\n\n 1 month later\n\n Closed on Sep 9\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Should Aave Make Governance Discussions Easier for Non-Technical Users to Follow?\n\n General\n\n 2\n\n 109\n\n Sep 20\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n Governance\n\n 24\n\n 1.4k\n\n Apr 14","tokens":1138,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260649046,"hash":"6e9457f09cf067f31b261fdc9231fdfd169967eb"}
{"url":"https://ethereum.org/apps/","domain":"ethereum.org","title":"Top crypto apps on Ethereum | ⁦ethereum.org⁩","text":"HighlightsAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.DeFiAaveLending and borrowingInterface is a trading-focused social network on Ethereum. Share your takes, discover new markets, follow friends, and copy trade their moves with live notifications.SocialInterfaceSocial network · Identity · PublishingUsual is a decentralized protocol, embracing the shape of a decentralized banking system. It issues a fiat-backed stablecoin, collateralized by Real-World Assets (RWAs), combining the security of real assets with the composability and liquidity of DeFi.DeFiUsual RWA · Stablecoin issuance · YieldAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.DeFiAaveLending and borrowingInterface is a trading-focused social network on Ethereum. Share your takes, discover new markets, follow friends, and copy trade their moves with live notifications.SocialInterfaceSocial network · Identity · PublishingUsual is a decentralized protocol, embracing the shape of a decentralized banking system. It issues a fiat-backed stablecoin, collateralized by Real-World Assets (RWAs), combining the security of real assets with the composability and liquidity of DeFi.DeFiUsual RWA · Stablecoin issuance · YieldDiscoverCollectiblesHighlightHighlight is a platform for creating and collecting digital art and culture.ArtPrivacyTornado CashA fully decentralized mixing protocol for private transactions on Ethereum.PoolsProductivityEASEthereum Attestation Service (EAS) is an infrastructure public good for making attestations onchain or offchain about anything.GovernancePrivacyPrivacy PoolsPrivacy Pools by 0xbow is a compliant way to anonymously transact on Ethereum. 0xbow blocks illicit actors to ensure pool integrity.Pools · ComplianceBridgeLayerswapLayerswap is the reliable solution for transferring crypto assets across networks in a matter of minutes. The app enables frictionless cross-chain transfers across 35+ blockchains as well as direct transfers between chains and 15+ exchanges.Liquidity networkProductivityLivepeerLivepeer is a decentralized network for limitless video computing, enabling AI processing and transcoding jobs to power the future of video.Storage · VideoApplicationsDeFiAaveLending and borrowingSky/Maker - USDSStablecoin issuance · RWA · Lending and borrowingEthena - USDERWA · Stablecoin issuance · YieldUniswapDEXPendleRWASocialZoraSocial networkRodeoSocial networkTownsMessagingFarcasterSocial network · MessagingOrbSocial networkPrivacyDemocracy Earth ProtocolVotingFileverseCommunicationFluidkeyStealth address · Payments · IdentityFreedom ToolVotingKohakuShielded · PaymentsCollectiblesOpenSeaMarketBlurMarketHighlightArtManifoldArtRaribleMarketGamingAavagochiAdventure · Strategy · RPGAsphodel: PrologueStrategyBattle BearsShooter · MultiplayerCambriaRPG · AdventureCat TownRPG · Casual · FishingDAOSnapshotGovernance · Organization · Offchain votingTallyOnchain voting · Analytics · Tokenomics · DAO creation · GovernorHats ProtocolRole management · Permissions · OrganizationAragonDAO creation · Governance · FrameworkDAOhausDAO creation · Treasury management · Framework · MolochProductivityENSDNS · IdentityHuddle01CommunicationLivepeerStorage · VideoZK PassportIdentityQuarkIDIdentityBridgeParticle NetworkChain abstractionLayerswapLiquidity networkHopLiquidity networkStargateLiquidity network · Generalized message passingAcrossValidator or oracle · Liquidity networkApplication categoriesDeFiDeFi is a category of decentralized applications that allow users to lend, borrow, trade, and earn interest on their crypto assets.CollectiblesCollectibles are digital assets that are unique and cannot be replicated.SocialSocial is a category of decentralized applications that allow users to connect with others and share content.GamingGaming is a category of decentralized applications that allow users to play games and earn rewards.BridgeBridge is a category of decentralized applications that allow users to bridge their assets between different networks.ProductivityProductivity is a category of decentralized applications that allow users to be productive.PrivacyPrivacy is a category of decentralized applications that allow users to be private.DAODAO is a category of decentralized applications that allow users to govern and create decentralized autonomous organizations.Community picksTim Beiko@TimBeiko (opens in a new tab)SocialFarcasterSocial network · MessagingTrent Van Epps@trent_vanepps (opens in a new tab)DeFiPeerOnramp / offrampJason Chaskin@jchaskin22 (opens in a new tab)DeFiAaveLending and borrowingSocialFarcasterSocial network · MessagingTim Beiko@TimBeiko (opens in a new tab)SocialFarcasterSocial network · MessagingTrent Van Epps@trent_vanepps (opens in a new tab)DeFiPeerOnramp / offrampJason Chaskin@jchaskin22 (opens in a new tab)DeFiAaveLending and borrowingSocialFarcasterSocial network · MessagingSuggest an appWe're always looking for new apps to add to our list. If you know of an app that you think should be on the list, please let us know.Suggest an app (opens in a new tab)","tokens":1371,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260657357,"hash":"8481a793288479719d831de89f61a3896ad4434b"}
{"url":"https://governance.aave.com/t/who-can-bring-governance-topics-to-a-vote-under-governance-framework-v2/25462/3","domain":"governance.aave.com","title":"Who can bring governance topics to a vote under Governance Framework v2? - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 10\n\n 3 / 3\n\n Sep 9\n\n Aug 10\n\n post by Millesimillia on Aug 10\n\n Millesimillia\n\n I raised this question in the [ARFC] Governance Framework v2 thread on 9 August, while the Snapshot was still open: [ARFC] Governance Framework v2 - #4 by Millesimillia\nIt did not receive a response, and the vote has since closed with 392,100 AAVE in favour and none against. I am opening it here so it has a proper home. This is a request for clarification, not an objection to the framework.\nIn the framework, author restrictions appear in three places only: the business case for a New Asset Listing and for a New Network Deployment, both reserved to Aave Labs or TokenLogic, and the Direct-to-AIP path, limited to active Service Providers. The Standard Process does not appear to restrict ARFC authorship.\n\nIs it correct that any token holder may author an ARFC on topics outside asset listings and network deployments - tokenomics, buybacks, service provider selection criteria, service provider reviews?\n\nOpening a Snapshot requires a place on the Authors list or 80,000 AAVE of proposition power. What is the route for a holder below that threshold whose ARFC has community support? Is there a sponsoring mechanism, and who maintains the Authors list?\n\nWith TEMP CHECK retired, what is the intended low-barrier entry point for community-initiated topics?\n\nCommitments have been made in governance discussions that token economics would remain firmly in view, and I take them in good faith. My question is structural rather than about intent: what keeps token economics transparent to holders over time, when every service provider also carries equity and revenue interests of its own? Concretely, is there a fixed reporting cadence on protocol revenue and its allocation that does not depend on which provider holds which mandate?\n\nIf the reading above is correct, I would ask that a short subsection on community-initiated proposals be added: who may author an ARFC, the route to Snapshot for authors below the threshold, and who maintains the Authors list. The framework states that it shall be maintained over time, so this seems a natural place for it.\nTransparency and accountability on these points would make AAVE stronger, not weaker. Over the medium term I would like holders to be able to judge the token the way shareholders judge a company: on disclosed economics, a predictable reporting rhythm, and a clear line from protocol revenue to the token.\nDisclosure: I am an AAVE holder and staker, without material proposition power. I am not compensated by any party and hold no position with any service provider.\nWarm regards,\nMillesimillia (Edited)\n@TokenLogic\n\n Areta Delegate Platform\n\n post by MconnectDAO on Aug 10\n\n MconnectDAO\n\n I strongly support this question. Aave governance should not only reward those who already have enough voting power or the right connections to move an idea forward.\nStrong proposals can come from any holder, researcher, delegate, or community member. The forum should give serious attention to ideas based on their quality, evidence, and value for Aave, not only on who brings them.\nWe need a clear path for community proposals that receive genuine support but come from authors below the Snapshot threshold. A transparent sponsor process, clear criteria for the Authors list, and public timelines for review would make participation more fair.\nAt the same time, proposals should be judged on impact, risk, and long term benefit. Sometimes well presented proposals move ahead despite limited value, while strong ideas are left behind because the author lacks access or visibility.\nOpen participation with clear accountability will make Aave governance stronger and help ensure that the best ideas get a real chance to be discussed and voted on. @Millesimillia\n\n 1 month later\n\n Closed on Sep 9\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Should Aave Make Governance Discussions Easier for Non-Technical Users to Follow?\n\n General\n\n 2\n\n 109\n\n Sep 20\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n Governance\n\n 24\n\n 1.4k\n\n Apr 14","tokens":1144,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260660980,"hash":"870a75f73ab0f6775623aa01a4c7ddb16e0bb78d"}
{"url":"https://eips.ethereum.org/EIPS/eip-7","domain":"eips.ethereum.org","title":"EIP-7: DELEGATECALL","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-7: DELEGATECALL\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2015-11-15\n\n Hard Fork\n\nHomestead\n\n Parameters\n\n Activation:\n\n Block >= 1,150,000 on Mainnet\n Block >= 494,000 on Morden\n Block >= 0 on future testnets\n\n Overview\n\nAdd a new opcode, DELEGATECALL at 0xf4, which is similar in idea to CALLCODE, except that it propagates the sender and value from the parent scope to the child scope, i.e. the call created has the same sender and value as the original call.\n\n Specification\n\nDELEGATECALL: 0xf4, takes 6 operands:\n\n gas: the amount of gas the code may use in order to execute;\n to: the destination address whose code is to be executed;\n in_offset: the offset into memory of the input;\n in_size: the size of the input in bytes;\n out_offset: the offset into memory of the output;\n out_size: the size of the scratch pad for the output.\n\n Notes on gas\n\n The basic stipend is not given; gas is the total amount the callee receives.\n Like CALLCODE, account creation never happens, so the upfront gas cost is always schedule.callGas + gas.\n Unused gas is refunded as normal.\n\n Notes on sender\n\n CALLER and VALUE behave exactly in the callee’s environment as they do in the caller’s environment.\n\n Other notes\n\n The depth limit of 1024 is still preserved as normal.\n\n Rationale\n\nPropagating the sender and value from the parent scope to the child scope makes it much easier for a contract to store another address as a mutable source of code and ‘‘pass through’’ calls to it, as the child code would execute in essentially the same environment (except for reduced gas and increased callstack depth) as the parent.\n\nUse case 1: split code to get around 3m gas barrier\n\n~calldatacopy(0, 0, ~calldatasize())\nif ~calldataload(0) < 2**253:\n ~delegate_call(msg.gas - 10000, $ADDR1, 0, ~calldatasize(), ~calldatasize(), 10000)\n ~return(~calldatasize(), 10000)\nelif ~calldataload(0) < 2**253 * 2:\n ~delegate_call(msg.gas - 10000, $ADDR2, 0, ~calldatasize(), ~calldatasize(), 10000)\n ~return(~calldatasize(), 10000)\n...\n\nUse case 2: mutable address for storing the code of a contract:\n\nif ~calldataload(0) / 2**224 == 0x12345678 and self.owner == msg.sender:\n self.delegate = ~calldataload(4)\nelse:\n ~delegate_call(msg.gas - 10000, self.delegate, 0, ~calldatasize(), ~calldatasize(), 10000)\n ~return(~calldatasize(), 10000)\n\nThe child functions called by these methods can now freely reference msg.sender and msg.value.\n\n Possible arguments against\n\n You can replicate this functionality by just sticking the sender into the first twenty bytes of the call data. However, this would mean that code would need to be specially compiled for delegated contracts, and would not be usable in delegated and raw contexts at the same time.\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-7: DELEGATECALL,\" Ethereum Improvement Proposals, no. 7, November 2015. Available: https://eips.ethereum.org/EIPS/eip-7.","tokens":741,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260678271,"hash":"4020f2cdcfc8d77c3099e44ae85c40cf192d5563"}
{"url":"https://governance.aave.com/t/temp-check-aave-will-win-framework/24055","domain":"governance.aave.com","title":"[TEMP CHECK] Aave Will Win Framework - Governance / General - Aave","text":"[TEMP CHECK] Aave Will Win Framework \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 12\n\n 1 / 136\n\n Feb 12\n\n 7d ago\n\n post by AaveLabs on Feb 12\n\n AaveLabs\n\n Aave Labs-Technical SP\n\nCover1920×1080 202 KB\n1. Summary\nAave began with the thesis that decentralized lending could play a major role in traditional finance. Eight years later, that thesis has been validated. Aave is the largest protocol in decentralized finance, commanding a 60% market share in lending. The opportunity ahead, however, is bigger than anything behind us.\nDetailed below is a strategic framework proposal for Aave’s next chapter. It asks the Aave DAO to ratify Aave V4 as the protocol’s foundational technology for future growth. It also proposes to direct all revenue from Aave-branded products built to the DAO treasury and to establish a budget for continued development. It also includes a solution to protect the Aave brand.\nThis proposal asks the DAO to approve the following operational framework:\n\nDirect 100% of Aave-branded product revenue to the Aave DAO treasury.\n\nCommit to a solution for protecting the Aave brand.\n\nRatify Aave V4 as the protocol’s core technical foundation for future development.\n\nCreate a framework for the DAO to fund strategic growth and development.\n\n2. Motivation\nThe LEND token sale in 2017 raised $16M to build a decentralized lending protocol. That protocol became Aave, and that $16M has grown into a multi-billion dollar ecosystem, creating billions in value in the process.\nAlong the way, Aave Labs has requested DAO funds only for direct protocol development and marketing activities. Everything else has been self-funded. This includes the product layer, which encompasses aave.com, the Aave mobile app, Aave Pro, Aave Kit, and Aave Horizon. It also includes legal and regulatory work such as SEC defense, brand protection, trademark management, and compliance. Business development and growth has been self-funded as well.\nWe are now entering one of the most important periods that will determine Aave’s success going forward. Fintechs are entering DeFi, institutions are coming onchain, and regulatory clarity is emerging in certain markets that allows us to go direct to consumers. The protocols that win the next decade will be those that move fast, build great tools and products, and capture new markets before competitors. With the right focus, and by investing in important growth areas, Aave is positioned to do exactly that.\nOther approaches to this framework exist, however they have different trade-offs. Aave Labs could operate independently and keep product revenue to fund itself, but then there would need to be a separation of the protocol revenues from the ones generated by the Aave-branded products built on top of the protocol. The DAO could directly build and operate Aave-branded products through governance, but the execution would be slow, and governance overhead can’t scale indefinitely to meet the pace required.\n3. Specification\n100% Aave Product Revenue to the DAO\nimage1600×871 122 KB\nThe first ever Aave governance proposal, AIP-1, established that AAVE token holders govern the Aave Protocol, which has led to the DAO rightfully collecting 100% of protocol fees.\nAnd since the protocol’s launch, Aave Labs has operated aave.com, which became an important access point for most protocol usage across retail users, power users, and integrators. This has supported millions of users with zero security incidents. The DAO has matured quite a bit since AIP-1 and we believe it’s time to align behind a token-centric model.\nUnder this proposal, 100% of Aave Labs’ product revenue will go to the DAO. This includes:\n\naave.com, the existing interface, and all associated fees\n\nAave App, the consumer mobile application\n\nAave Card, a card tied to Aave App with all fees flowing to the DAO\n\nAave Pro, the new interface for Aave V4\n\nAave Kit, enterprise solutions for fintechs and institutions building on Aave\n\nAave Horizon, Aave’s RWA market and institutional services\n\nAAVE ETP, exchange traded product of $AAVE\n\nUpon approval of this proposal, the DAO would also receive revenue from the swap integration on aave.com, which currently generates approximately $10 million in annualized revenue. This integration is expected to expand to additional chains and functionality.\nRevenue is defined as gross product revenue earned by Aave Labs, minus any direct revenue sharing paid by Aave Labs to external partners including revenue rebates, revenue subsidies, revenue sharing arrangements and any additional direct user incentives.\nProduct growth incentive budgets are funded by the Aave DAO. Additionally, Aave Labs retains the discretion to redirect a portion of product inflows, such as vault yields, directly into user incentives. Competing for users requires the ability to deploy capital quickly toward growth without waiting for a governance cycle. In these instances, Aave Labs will disclose additional user incentives spending in our quarterly updates.\nWith proper execution, the product layer can be an additional source of revenue for the DAO treasury. Combined with protocol fees, the DAO can fund its own growth, security, and development from a diversified revenue stream.\nExpanding Revenue Through Aave V4\nThe product layer is one part of the path to increasing the DAO’s annual revenue. The protocol layer, powered by Aave V4, is the other. Aave V3 already generates over $100 million in annualized revenue. Aave V4 expands on V3 with new monetization features that allow the protocol to capture more value from the risk it underwrites.\nV4’s architecture also unlocks revenue streams that are not easily possible in previous Aave versions. Each Spoke can extend Aave into a new market or use case, with its own risk parameters and revenue model. As with V3, 100% of Aave V4’s protocol revenue will go to the DAO.\nWe’ve taken a look at various products and protocols across the crypto and fintech industries to show estimations that highlight the size of the opportunities available:\nspoke-revenue-data1921×1046 400 KB\nrevenue-flow-diagram1921×1046 161 KB\n* These opportunity estimates are based on other protocols or products in each category (e.g. Pendle, Fluid), and the size of the opportunity (e.g. OTC lending volume), etc. They each represent a net new revenue opportunity on top of what Aave generates today, and they are only possible to pursue in a scalable way once V4 is live. Reaching these estimates would also depend on market conditions, scale of adoption, and execution.\nAave V4 also introduces a new reinvestment module, which is an optional net new revenue opportunity for the DAO to consider. Aave pools maintain a significant idle float that currently earns nothing. This reinvestment feature allows the protocol to sweep this capital into short-term, low-risk yield opportunities pre-vetted and approved by the DAO, similar to a collateral listing.\nWhen Aave rates fall below SOFR-rates, it signals underutilized liquidity that could be productively deployed. Based on historical stablecoin float levels and a risk-free proxy SOFR-rate, the additional interest that would have been earned is substantial:\nreinvestment-module-data1921×1047 391 KB\n* Based on historical performance and idle liquidity. These figures are illustrative good faith estimates included to inform governance discussions around prioritization and resource allocation. They are not projections, commitments, or expectations, and actual outcomes may vary materially depending on governance choices, execution, adoption, and market conditions.\nThis interest can be split between depositors and the DAO or whatever else the DAO decides. The analysis does not include other strategies such as ETH staking or reinvesting into higher-yield opportunities, which are also an option if the DAO chooses.\nTaken together, these opportunities illustrate the range of operational scale the DAO may need to support across both the protocol and product layers if adoption and market conditions warrant it. Viewed as an aggregate opportunity set, they suggest that the long-term revenue ceiling for the Aave ecosystem is materially higher than today.\nRatification of Aave V4\nAave V3 has served the protocol well, but it is approaching its architectural limits. Adding new features to V3 requires modifying core protocol logic, which involves extensive audits and significant coordination overhead. Meanwhile V4’s architecture allows new functionality to be added through Spokes without touching the core, making experimentation cheaper, faster, and safer.\nImportantly, anything V3 does can be recreated on V4, but not vice versa. V4 is a strict superset of V3’s capabilities, meaning no functionality is lost in the upgrade.\nV4’s architecture expands the range of revenue models the protocol can support, which is why governance analysis considers higher-scale revenue scenarios when planning long-term operations. To capture the opportunities outlined above, Aave Labs and the rest of the DAO’s service providers should coordinate development efforts around V4. This means prioritizing V4 Spoke development, aligning roadmaps, and shifting new feature work away from V3. Notably, V4 is already live on testnet, has completed an open security contest, and has its first public audit.\nThe DAO is being asked to agree on this strategic direction and a separate proposal will follow for V4 protocol activation, the launch setup, etc.\nV3 Maintenance Plan\nThat said, V3 should not be shut down hastily or haphazardly. V3 is stable, mature, and battle-tested. There is no need for a rushed, or forced, migration, and the transition should happen in three phases:\n\nActive Development. V3 remains the primary production system, with security patches, parameter updates, and critical maintenance continuing as normal. It also makes sense to pause any new features for V3 if this framework is passed.\n\nStable Maintenance. V4 becomes the primary technology layer for expansion and innovation. V3 documentation, tooling, and access points remain fully supported, and users migrate at their own pace.\n\nLegacy Support. Once V4 is mature, V3 parameters could be gradually adjusted to encourage migration, following the same approach used in past version transitions. V3 remains open indefinitely for withdrawals, with governance stepping in only for critical security issues.\n\nNote: As per the DAO’s feedback, the timeline for these phases can evolve organically or be decided in a different proposal. In the near term, V3 will run alongside V4 until further discussions are held by the DAO. That said, aligning the DAO behind V4 is important.\nAave Brand Governance\nThe Aave brand is one of the protocol’s most important assets, built over years of technical excellence, security track record, and community trust. Protecting it is in the best interest of the DAO, token holders, and the broader ecosystem.\nToday, Aave Labs is the exclusive legal owner of the Aave trademarks and has been solely responsible for holding, defending, and enforcing them. Because the DAO is not a legal entity, it cannot directly hold or defend trademarks. As a result, trademark stewardship has necessarily sat within Aave Labs.\nFor the past seven years, Aave Labs has carried this operational burden, and the work is hands-on, expensive, and necessary. Trademarks that are not actively and consistently defended can be weakened or lost, reducing the ability to control how a mark is used in commerce and increasing the risk of misuse or confusion.\nAt the same time, there are understandable concerns around concentrating long-term control of such a critical asset within a single operating entity, particularly as the DAO continues to mature. To address this, and subject to DAO approval, Aave Labs proposes the creation of a Foundation that would assume responsibility for holding and stewarding the Aave trademarks going forward. The Foundation would be mandated to protect the brand, license it to approved entities, address unauthorized use, and operate in alignment with DAO-approved parameters.\nThe details regarding the structure, governance, and execution of this Foundation, including any transfer or licensing of trademark rights, as well as proposed approaches to V4 codebase licensing, will be presented to the DAO in a follow-up proposal.\n$AAVE Market Access\nTo go beyond the product/protocol layer and expand market access to $AAVE, Aave Labs will support partners to launch regulated, traditional market products referencing $AAVE as the underlying asset. This includes the potential launch of $AAVE regulated futures, as well as a regulated spot exchange-traded product (ETP).\nThe introduction of regulated futures and ETP products would represent a meaningful step toward institutional maturity for Aave, broadening access for professional and traditional investors. A standalone proposal covering structure and execution will follow under the workstreams authorized by this proposal.\nDAO Growth Requires Resources At Scale\nThe operational framework outlined above requires execution at scale that matches the opportunity. For Aave to scale and play a role in the real financial system, it should allocate resources in growth the way fintechs, banks, and other financial institutions do. Without commitment to this as a goal, Aave’s upside will always be limited. If all of Aave Labs’ product revenue flows to the DAO, the DAO would need to fund the ongoing development and growth of these products.\nAave Labs Funding Request\nThe DAO is facing a structural decision regarding Aave Labs’ operating model going forward.\nCurrently, Aave Labs self-funds a significant portion of its operations. Historically, the ecosystem’s direction of travel (via AIP-1) was to use fees generated by Aave-branded products, such as aave.com and other product surfaces, to cover Aave Labs’ product development, marketing, legal, and operational costs, while the DAO funded direct protocol version development carried out by Aave Labs.\nUnder the proposed operational framework, all fees from Aave-branded products would go to the DAO treasury rather than supporting Aave Labs’ operations and product development. In this configuration, the responsibility for funding Aave Labs’ activities would shift correspondingly to the DAO.\nAave Labs requests $25 million in stablecoins, 75,000 AAVE, with additional growth and development grants payable upon specific product launches. The funding would be structured as follows:\n\nPrimary Grant:\n\n$5 million paid upfront upon approval of the proposal and $20 million streamed over the course of the year.\n\n75,000 AAVE delivered upon approval of the proposal, unlocking linearly monthly over a 2 year period\n\nGrowth/Development Grants:\n\n$5,000,000 for Aave App launch, with funds used for user acquisition, marketing, and ongoing development\n\n$5,000,000 for Aave Pro launch, with funds used for user acquisition, marketing, and ongoing development\n\n$5,000,000 for Aave Card launch, with funds used for user acquisition, marketing, and ongoing development\n\n$2,500,000 for Aave Kit launch, with funds used for maintenance and marketing\n\nNote: For clarity, all funds will be spent on Aave-related efforts.\nGrowth and development grants are released upon delivery and streamed over a period of six months, with governance confirming completion before funds are disbursed. They cover the cost of bringing each product to market, from engineering through go-to-market.\nCompanies entering DeFi are well-capitalized and spending aggressively on product and distribution. To succeed in the market, Aave needs to invest at a similar scale. This commitment allows for long-term planning, aggressive hiring, and sustained investment in product and go-to-market without the friction of annual budget cycles.\nThe funding requested is a significant expansion of scope beyond historical funding. To date, Aave Labs has largely self-funded the cost of building and scaling the product layer, seeking DAO support mainly for core protocol development and focused marketing. This proposal secures the investment needed to stay competitive and continue innovating over the next decade. Growing Aave and growing it to the scale of other TradFi alternatives requires stable, predictable funding so contributors can plan, hire, and execute at the standard of a global financial platform.\nAltogether, these funds are covering the following costs:\n\nContinued protocol development (V4 improvements, Spokes, core infrastructure, research, and development)\n\nProduct engineering across Aave Pro, Aave App, Aave Kit, and other products\n\nProduct go-to-market, user acquisition, marketing (e.g. social media/SEO/content) and growth\n\nBusiness development\n\nAave Labs invests heavily in partnering with the largest institutional and fintech names to integrate with Aave.\n\nAave Horizon asset onboarding and driving TVL/borrow growth.\n\nOngoing 360° resource provision for institutional integrators, including technical, InfoSec and operational support.\n\nApplication security\n\nAave Labs runs an extensive monitoring program, and very heavy enterprise fees to social media platforms, to protect the Aave brand.\n\nEvents, which historically Aave Labs has already run with funding from the DAO (e.g. rAAVE, DeFi Day)\n\nWith this capital, Aave Labs can build with the runway needed to succeed on the items outlined above. It would also reflect the DAO’s decision to fund the level of execution required to support protocol operations at increased scale, should governance determine that expansion is warranted.\nIn order to be as effective as possible, Aave Labs would retain autonomy over product strategy and operations. Building competitive products requires the ability to move quickly, make decisions without committee approval, and iterate based on market feedback. We suggest the same for other Service Providers who might choose to operate under this framework.\nThe grants outlined above are for one year and would need to be revisited, if approved, 12 months after the proposal is decided on.\nIn line with existing DAO practices, oversight of this work is exercised through governance. Aave Labs will provide regular transparency into its activities, including:\n\nQuarterly updates on progress against funded initiatives, key metrics, and use of DAO-authorized resources\n\nOngoing updates on active workstreams and prioritization decisions\n\nContinued open and responsive communication with the DAO through established governance channels\n\n4. Next Steps\nAave remains early in its journey. What exists today is a base layer, while the real scale of adoption lies ahead as global finance moves onchain. DeFi is still quite small in the grand scheme of things. And over the coming decades, trillions of dollars in assets will migrate onto open rails. In that world, Aave can become the core infrastructure for global finance.\nSince 2017, the focus has been on disciplined execution at the frontier, and that conviction has only strengthened. The next phase of growth, fueled by innovation, and institutional adoption will be led by Aave. With sustained commitment and effective execution, the protocol can support significantly greater scale over time and continue establishing itself as core liquidity infrastructure for the onchain economy.\nThis proposal seeks to establish a framework for Aave’s next decade. Upon approval, it would reaffirm Aave Labs’ alignment with the DAO by directing all Aave-branded product revenue to the DAO treasury. It asks for the ratification of V4 as the technical foundation for this growth and for the funding to execute this vision. This framework’s objective is to position the Aave Protocol as a core piece of global financial infrastructure, with the value it creates directed to the Aave DAO to fund its continued development and success.\nIn accordance with Aave governance processes, this proposal is intended as an initial Temp Check to gather community feedback on the strategic direction outlined above. Any commitments, structural changes, or funding allocations would proceed through the appropriate stages of discussion, refinement, and governance proposal stages prior to implementation.\nIf the Temp Check is successful and the community supports this proposal, we will move forward with a formal ARFC submission.\nDisclaimer\nHistorically, Aave Labs has self-funded its endeavors. Due to the nature of the proposal, Aave Labs would receive funding from the DAO in exchange for Aave Labs’ revenue going to the DAO if passed. No third parties co-authored this proposal.\nCopyright\nCopyright and related rights waived under Creative Commons Zero (CC0).\nFAQ\n1. Why are so many significant items grouped into a single proposal? Shouldn’t these be separate votes?\nThis proposal presents a single, cohesive strategy. The components are interconnected and depend on each other for success. For example, aligning on V4 as the core technical foundation informs how development efforts are prioritized, while the proposed funding framework supports coordinated execution across protocol and product workstreams. Voting on these items separately could result in a fragmented and unworkable plan. Approving the strategy without the technology, or the technology without the funding to build it, would be inefficient. This proposal is a complete strategic package, and voting on it as a whole ensures the DAO is aligned on a single, comprehensive path forward.\n2. The funding request is substantial. Why does Aave Labs need this budget?\nThe requested budget reflects a deliberate shift in operating model rather than an incremental extension of past funding. Historically, Aave Labs subsidized a broad range of activities and requested DAO support primarily for direct protocol development and focused marketing. Under this framework, the DAO is choosing to fund a wider operational scope directly, including product engineering, go-to-market execution, product relevant legal and compliance work, and business development. This budget is intended to support long-term planning and execution at scale and to enable stable resourcing and sustained focus. It reflects a governance decision about how the DAO wishes to resource protocol-adjacent work as Aave engages more directly with an evolving and increasingly competitive market landscape.\n3. Why should the DAO fund Aave Labs now if it has been self-funded for so long?\nBy directing 100% of revenue to the DAO, Aave Labs will not be able to self-fund going forward. Without the ability to earn or raise revenue, there is no way to cover the costs across product development, business development, and other operational functions Aave Labs has historically funded. Without funding to continue this work these functions would stop.\n4. Is this funding request annual?\nYes. Aave Labs will submit an annual budget proposal to the DAO for the work it performs. Each year’s budget requires a separate governance vote, giving the DAO ongoing oversight of how funds are allocated.\n5. What does “autonomy” mean in this proposal?\nThe proposal requests autonomy over certain operational and product strategy decisions. Building competitive products requires the ability to move quickly and iterate based on market feedback, which is difficult if every decision requires a vote. Accountability is central to this arrangement. Aave Labs commits to providing quarterly reports on progress, frequent updates on development, and continued open communication with the DAO. The DAO retains ultimate oversight through its control of the treasury and Aave Labs’ funding stream. If Aave Labs does not meet its commitments or perform effectively, the DAO can choose not to continue contributing to this budget.\n6. What does ratifying V4 mean in this proposal?\nThis vote asks the DAO to agree on a strategic direction. Ratifying V4 in this proposal means committing to it as the core technical foundation for future development. It signals to all service providers that V4 is the priority, allowing them to align their roadmaps and development efforts. This coordination is necessary to build the features that will achieve the proposal’s goals. The subsequent vote to activate the V4 protocol will be a purely technical one, focused on the readiness of the code, launch parameters, etc.\n7. Why is there compensation tied to milestones?\nLaunching and scaling products involves costs beyond core development work. This includes go-to-market execution, partnership development, and ongoing operational support around the time a product is introduced. The milestone-based payments are intended to support these activities at key delivery points, aligning resourcing with product rollout. As all revenue from these products flows to the DAO, funding this work supports execution that directly contributes to the protocol’s operational sustainability.\n8. How does this framework impact other Service Providers working with the Aave DAO?\nIf the DAO ratifies this proposal, coordination among service providers will be important for efficient execution. Service providers funded by the DAO can align their work with this direction to maintain Aave’s competitive position. Those who prefer to focus on different priorities can propose adjusting their scope accordingly. Additionally, the increased surface area for revenue generation established by this proposal creates a framework that other service providers can consider for their own work with the DAO.\n\n [TEMP CHECK] One-Time Bounty Award — CoW Swap Fee Discovery\n\n Aave Labs: $86 Million, 23% of the Token Supply, and this is their Track Record\n\n ACI: Full Transparency Report\n\n BGD. Leaving Aave\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n 14\n\n 11\n\n 10\n\n 10\n\n 7\n\n read \n\n 77\n min\n\n post by anon40760803 on Feb 12\n\n anon40760803\n\nHey, thanks for submitting this temp check. I won’t comment on the budget aspect and will leave those questions and analysis to the DAO’s financial SPs, but it’s great to see things moving in a positive direction!\nI just have two questions:\n1. What is the objective of the “Primary Grant”?\nIs it intended as compensation for transferring the IP/brand rights to the DAO and renouncing revenue from AAVE-branded products? I’m not fully clear on this point, especially since the “Growth/Development Grants” section appears to already cover operational costs\n2. Could you provide more clarity on the current AAVE Labs structure?\nGiven that Avara and its side projects (Lens, Family) are being sunset or phased out, it would be helpful for the DAO to have a clearer breakdown of AAVE Labs as it stands today. For example:\n\nHow many people are currently working there?\n\nHow are teams structured?\n\nHow would the requested funds be allocated across departments?\n\nAppreciate the clarification in advance \n\n post by A_J on Feb 12\n\n A_J\n\n Good start to DAO, AAVE Labs and revenue discussions.\nOn the face of it, all items appear cohesive and in interests of 1. DAO, 2. $AAVE holders and 3. AAVE Labs.\nPersonally really happy that the turmoil of revenue is behind us and a new chapter begins. Kudos!\n\n post by MarcZeller on Feb 12\n\n MarcZeller\n\n I’ll post a more detailed answer tomorrow touching proposal substance, but I want to cut through the attempted gaslighting now concerning funding and “Decentralization”.\nAave Labs created a problem and extracted roughly $5.5M of potential Aave DAO revenue.\nimage1325×779 36.2 KB\nSince then, we’ve seen roughly $1.5B wiped from $AAVE market cap and a real, lasting hit to reputation.\nNow Labs is back with a $50M “solution”, presented as “for the good of the DAO”, after zero prior coordination with delegates or service providers.\nInstead of engaging directly with the people who actually run governance day to day, the strategy has been to shape the narrative through KOLs and proxy accounts. That’s not how you build legitimacy. That’s how you manufacture it.\nWe’ve seen this playbook before: open with egregious terms, absorb backlash, then reframe a smaller ask as “the reasonable middle ground” while still extracting a massive amount.\nAnd at this point, there’s not much left to debate: Labs has now shown, repeatedly, that when a decision touches its own interests, it will vote its $AAVE accordingly. That’s their right as holders. But it also means the “discussion” is largely theater when one party can reliably enforce its preferred outcome with voting power.\nLet’s be honest about where we are: Labs is acting as if it can impose outcomes regardless of governance process. If token holders are comfortable with that, so be it, but I’m not going to pretend this is healthy governance.\nAt this point, the fox controls the henhouse, and the incentive is clearly to maximize extraction.\nGood luck, friends.\n\n post by Gross on Feb 12\n\n Gross\n\n The real question we need to ask concerns the validity of your claim that you have self-funded all these products. We are forced to ask where this capital actually originates. Apart from the Aave protocol and the DAO treasury what independent revenue streams have you generated to fund such extensive development? You already exert enough dominance in voting and manipulate governance processes as you see fit. This request for 75k AAVE will simply cement that control. Moving the brand to a foundation on paper changes absolutely nothing because at the end of the day you will still retain the power to unilaterally force any rule you want through on chain voting.\nStani, to be clear: no one is asking you to leave. We want you to keep working for Aave, earning for yourselves while generating value for the protocol. However, these requests and potential gains must remain reasonable and acceptable. The general framework of this proposal is solid, and if we can find common ground on the grant specifics and a few other items, I believe this would pass with broad support. The only real misstep here has been the lack of prior engagement with community leaders and DAO delegates.\n\n post by ApuMallku on Feb 12\n\n ApuMallku\n\nThis is the critical question: where does this capital actually originate?\nThis is my core concern: complete lack of voting power transparency. We’re witnessing real-time governance capture—Labs wielding 600K voting power plus unknown hidden wallets.\nRequirements before this proposal has credibility:\n\nFull disclosure of all wallets under Labs/founder control\nComplete budget breakdown showing funding sources\nTransparent accounting of capital deployment\n\nI’m glad the hidden front-end fees discovery forced this proposal. But the cost? Over $1 billion in market cap destroyed through entirely avoidable drama.\nReality check: Full disclosure should happen before Snapshot. But this will pass regardless—Labs controls governance. That’s the problem we’re documenting in real-time.\n\n post by _LP17 on Feb 12\n\n _LP17\n\n From my perspective, this proposal makes a lot of sense and shows a strong alignment around the token and the long-term vision of the ecosystem. Directing product revenues to the DAO, strengthening V4 as the core foundation, and structuring growth in a more coordinated way is strategically coherent.\nThat said, I believe additional steps and clarifications are necessary, especially regarding the size and structure of the requested budget, which appears quite significant for Aave Labs.\nFirst, do we have a clear breakdown of the internal architecture of Aave Labs? More transparency on operational structure, cost centers, and resource allocation would help the DAO better understand how funds will actually be used. Are there detailed cost estimates per product, per team, or per initiative? At this scale, granularity matters.\nSecond, the request for stablecoins is understandable and logical. Stable funding allows for planning, hiring, and execution without exposure to volatility. However, I am less convinced about the request for AAVE tokens. What is the precise objective of allocating AAVE to Labs? If the intention is compensation, incentives, or treasury alignment, this should be explicitly detailed.\nThere is also a legitimate concern about potential selling pressure on the AAVE token if large allocations are unlocked over time. Even with vesting, this creates structural risk. It could also introduce governance dynamics where token allocations might indirectly influence voting power. Would it not be safer and more neutral to structure the funding purely in stablecoins, at least for operational expenses?\nAnother point: the fact that multiple budgets are set at similar levels (Labs, App, Pro, Card, Kit) raises questions. These products likely have very different complexity levels, timelines, and market strategies. It would be beneficial to see a more detailed justification of why these allocations are equal or comparable, with clear KPIs, expected ROI, and milestone-based release logic.\nDespite these concerns, as a personal holder of a significant amount of AAVE, I believe the direction is correct. There is a real alignment around the token and the long-term positioning of Aave as a core financial infrastructure.\nHowever, budget discipline is critical. At this stage, the priority should be to grow revenue and strengthen buyback mechanisms. Increasing recurring protocol income and reinforcing buybacks is, in my opinion, one of the only reliable ways to protect the AAVE token from market pressure, volatility, or potential manipulation.\nToday, the overall valuation of AAVE feels disproportionately low compared to the scale of assets secured, the revenue generation potential, and the strategic ambition of the protocol. This disconnect is not just surprising — it can become structurally dangerous. When a protocol of this size and importance is valued too low relative to its fundamentals, it can make the ecosystem more vulnerable.\nSo yes, the proposal is directionally strong and aligned with the token. But tighter cost control, more transparency on spending structure, clearer justification for AAVE allocations, and a stronger focus on revenue growth and buybacks would make the framework significantly more robust and protective for token holders.\n\n post by aleks-larsen on Feb 12\n\n aleks-larsen\n\n Disclosure: I’m a general partner at Blockchain Capital, a venture firm with a large, long-term $AAVE position. I want to share our thoughts on this proposal.\nFirst, we’re very happy to see this proposal from Aave Labs (“Aave Labs” or “Labs”) and think it represents an important step in the Aave ecosystem’s evolution towards a mature DAO. For many reasons, it’s tricky to navigate the relationship between labs companies and DAOs and we genuinely don’t have good precedents to go off of here, so we’ve been thinking about this from first principles.\nAt a basic level, DAOs are good for aligning stakeholders in a decentralized system and deciding how the resources of the DAO are used and allocated. Companies are good for execution: building products, taking them to market, exploring partnerships, interfacing with the legal system, etc. What we want to aim for as token holders is a healthy relationship between the DAO and the companies that operate in service of it.\nThis requires balance. If the DAO micromanages companies, the companies won’t be able to make much progress; if companies don’t have the right checks and balances, then the DAO may end up ceding too much control to the companies. The goal is to find a way to enable companies that work inside of the DAO to execute at a world class level in a competitive environment while making real commitments that keep value and ultimate authority at the governance level.\nThis proposal looks like a mature effort to define that balance. Sending 100% of Aave-branded net product revenue to the DAO is a very clear way to align incentives and represents a full commitment from Labs to the DAO. It also makes sense to pair that with a clear funding model for the team doing the work: if the DAO owns the economics of the product layer, the DAO should fund the development, go-to-market, security, and operations needed to grow it. The milestone-based funding and streaming payments feel like the right approach in that they give Aave Labs enough stability to plan and execute while maintaining clear, enforceable governance checkpoints.\nWe also think the brand and trademark section is a necessary step toward a more professional setup. Since the DAO isn’t a legal entity, someone has to hold and defend the trademarks. Moving stewardship to a foundation that must operate within DAO-approved rules is a good direction, in our view, as long as the follow-up proposal adds clear safeguards, e.g., transparent licensing rules, conflicts-of-interest policies, regular reporting, an appeals process, and a clear way to replace the steward, or those managing it, if needed. If the DAO can get those details right, it could help protect users from scams and confusion while maintaining the brand as a community-governed ecosystem asset.\nPutting implementation details aside, the only real alternative to this direction is that Aave Labs pursues independent business models and funding. That might still drive some value to the protocol, but as token holders, we think it’s in our best interest to do what we can to fully align Aave Labs within the DAO, and, from our read, that’s what this proposal represents.\nOur view is that the question that should be asked when considering whether or not to grant this kind of funding proposal is whether this team/company has the track record, plan and alignment to warrant a large investment from the DAO. Our view at Blockchain Capital is that Aave Labs unequivocally has a track record that warrants our full support, and we think the most productive thing for the DAO to do is to work with this proposal in an effort to position the Aave ecosystem for success. We’re excited about the products Aave Labs is building and believe that this could be a high ROI investment for the DAO to make. We also believe it is far better than Labs seeking independent funding. If successful, this can stand as a template for future proposals from other companies that want to be part of the DAO and contribute to the Aave ecosystem. In 10 years, hopefully the protocol has dozens of talented, competitive teams that are aligned towards growing the protocol. This could be an important step towards getting there.\nWith that said, we think there’s a handful of details that need to be worked out, such as clearly defining net revenue. The spirit of this makes sense: product builders who choose to work in the DAO need to be able to be competitive. Normal companies get to re-invest their revenue into growth. The DAO needs a mechanism for Aave-aligned companies that matches this, but it should iron out the guardrails and set a framework for how this changes over time. It is also important to discuss allowing a prospective labs team to have reinvestment flexibility. This could be accomplished by adding a simple policy with thresholds, below which, the team can move fast; above it, governance has visibility or approval authority.\nWith some additional discussion and guardrails, we think this proposal is an excellent step forward for all participants in the ecosystem, and we hope to work collaboratively towards an operating framework that positions the Aave protocol for long term success.\nDisclaimers: Blockchain Capital holds the AAVE token but is not otherwise affiliated with the Aave Protocol and is in no way affiliated with Aave Labs. Blockchain Capital does not hold equity in Aave Labs or any of its affiliated entities. Neither Blockchain Capital nor the author guarantees the accuracy, adequacy or completeness of information provided in this post. No representation or warranty, express or implied, is made or given by or on behalf of Blockchain Capital, the author or any other person as to the accuracy and completeness or fairness of the information contained in any post and no responsibility or liability is accepted for any such information.\nNothing contained in this post constitutes investment, regulatory, legal, compliance or tax or other advice nor is it to be relied on in making an investment decision. This post should not be viewed as current or past recommendations or solicitations of an offer to buy or sell $AAVE or any other digital asset, any securities, or to adopt any investment strategy. This post may contain projections or other forward-looking statements, which are based on beliefs, assumptions and expectations that may change as a result of many possible events or factors. If a change occurs, actual results may vary materially from those expressed in the forward-looking statements. All forward-looking statements speak only as of the date such statements are made, and neither Blockchain Capital nor the author assumes any duty to update such statements except as required by law.\n\n post by tsips1267 on Feb 12\n\n tsips1267\n\n The funding request here seems a little excessive compared to the revenue the DAO would get back from the Cowswap fees. AAVE Labs is requesting $25M/year in stables and 75000 AAVE (which would be worth almost another $25M not that long ago) and only gives $10M/year back in revenue from the swap fees. Unless the AAVE App grows to be a particularly large success, I can’t see how this would be profitable short term to the DAO to get $10M and lose almost $50M.\nEDIT: Ultimately I’d rather AAVE Labs get a significantly lower sum of $10M/year in stables without any AAVE tokens and to remove all fees from the Cowswap integration altogether. These fees are purely extractive and unnecessary to the functioning of the interface, and long term drive users away from the interface to third party interfaces and potentially even competing lending platforms.\n\n post by dabit3 on Feb 12\n\n dabit3\n\n All product revenue flowing to the DAO is the right call. Labs getting funded directly in exchange is a clean structure, they receive the needed runway to compete and the DAO retains oversight through governance.\nFintechs and institutions are entering DeFi with serious capital and aggressive distribution, Aave can’t afford to move slowly while these players build on competing protocols. This seems like a great path for both the DAO as well as the tokenholders. Nice work!\n\n post by MarcZeller on Feb 12\n\n MarcZeller\n\n The DAO Won, but the Deal Isn’t Done\n\nThis proposal is a victory for the Aave DAO.\nBack in December, @EzR3aL, a truly independent delegate, posted a revenue question that kicked off a broader community conversation about revenue alignment, governance transparency, and the relationship between Aave Labs and the protocol. Today, Aave Labs is offering to direct 100% of product revenue to the DAO treasury, ratify V4 as the shared technical foundation, and create a Foundation to hold the brand. That did not happen by accident. It happened because governance worked.\nThe direction is right. I have been publicly advocating for exactly this kind of token-centric alignment. The destination is correct. The route needs work. Here is what the community should understand before voting.\nRead the Fine Print\nThe headline is “100% of Aave-branded product revenue to the DAO.” A genuine and welcome commitment. Proof that decentralized governance produces real outcomes.\nGovernance also means reading the details.\n“100% Revenue” Needs a Definition the DAO Controls\nRevenue is defined in this proposal as gross product revenue minus partner revenue sharing, minus revenue rebates, minus revenue subsidies, minus “additional direct user incentives.” All deductions are at Aave Labs’ sole discretion. No independent audit. No cap. No DAO approval threshold.\nThe proposal also states: “Aave Labs retains the discretion to redirect a portion of product inflows, such as vault yields, directly into user incentives.”\n100% of revenue is a powerful commitment. The DAO needs to define what revenue means , not the entity being funded from it. An independent auditor verifying the number and DAO-approved caps on discretionary deductions would turn a headline into an enforceable commitment. A small change that makes the entire proposal credible.\nThe Treasury Cannot Absorb This Ask\nThe Aave DAO treasury holds $160.9M, down $44.8M. Of that, $100.6M is non-AAVE assets and $60.2M is AAVE tokens.\nThis proposal requests $42.5M in stablecoins ($25M primary + $17.5M in milestone grants) and 75,000 AAVE. The stablecoin ask alone is 42% of the DAO’s non-AAVE reserves. The total ask of roughly $50.7M is 31.5% of the entire treasury. For a single service provider. In a single vote.\nNo funds or tokens should transfer until enforceable commitments are in place.\nV3 Built This House\nAave V3 generates over $100M in annualized protocol revenue. The most proven lending infrastructure in DeFi. More than 95% of all Aave DAO historical revenue comes from V3 and its predecessors.\nThis proposal frames V3 as “approaching its architectural limits” and asks the DAO to ratify V4 as the replacement. Buried in the maintenance plan: “It also makes sense to pause any new features for V3 if this framework is passed.”\nV4 may well be the future. Today, it is on testnet, has some completed audit, and has generated zero revenue. The right approach is parallel-track: protect the V3 cash engine while accelerating V4 validation on its own timeline. Ratifying an unshipped protocol while freezing the $100M per year revenue engine in a single bundled vote is premature. V4 should earn its ratification through its own proposal, on its own merits, when it is ready for mainnet.\nUnbundle the Vote\nThe FAQ states: “Voting on these items separately could result in a fragmented and unworkable plan.”\nThis is four proposals in a trenchcoat. Revenue alignment, V4 ratification, Foundation creation, and a $50M funding request are four separate decisions with different risk profiles and different levels of community consensus. The community broadly supports revenue alignment. It may also support V4 ratification and a Foundation. It has serious questions about the funding size and terms.\nBundling them means accepting everything or rejecting everything. If these components stand on their own merits, they can be voted on separately. Let the community say yes to alignment while demanding better terms on funding.\n75,000 AAVE Tokens Are Governance Power\n75,000 AAVE at today’s price of $109 is roughly $8.2M and represents 13.6% of the DAO’s AAVE holdings (~550,000 tokens). AAVE tokens carry voting power.\nYesterday I published on-chain analysis showing wallets connected to Aave Labs infrastructure voted to defeat the Mandatory Disclosures proposal , a proposal requiring wallet disclosure and conflict-of-interest abstention. That vote is still active and currently losing.\nThis proposal asks the DAO to transfer 75,000 additional AAVE tokens to an entity whose existing governance holdings remain undisclosed. The DAO should know what governance power the recipient already holds before transferring more. Any entity receiving AAVE tokens from the DAO should meet the same disclosure standard we would expect of any service provider.\nWhat I Support\nI support the direction of this proposal. Revenue alignment is correct. A Foundation holding the brand is correct. V4 as a long-term technical direction is correct. The DAO should recognize this moment: engaged governance produces results.\nWhat Needs to Happen First\nDirection is not execution, and a Temp Check is not a blank check. I propose the following sequencing:\n\nUnbundle the vote. Revenue alignment, V4 ratification, Foundation creation, and funding should be separate proposals. Each stands on its own merits. The community can support what it agrees with and refine what it doesn’t.\n\nTruly independent Foundation. An independent Foundation holding all Aave IP, trademarks, and brand rights should be operational and verified before any funds are transferred. “Independent” means exactly that: a board and governance structure that is not controlled by Labs-aligned members. With voting power concentrated around Labs and the unresolved COI questions, an entity that is independent on paper but aligned in practice cannot serve as a safeguard. How Foundation independence is guaranteed is a question worth asking before any money moves.\n\nFull wallet disclosure. Any entity requesting DAO funding and receiving AAVE tokens should disclose all wallets under its direct or indirect control. These standards apply to every service provider equally, including ACI.\n\nIndependent revenue verification. Revenue flowing to the DAO should be defined and verified by an independent auditor, with deductions capped or subject to DAO approval. “100% of revenue” must mean something the DAO can verify.\n\nNone of these require rejecting the proposal. They require improving it. These conditions can be met in weeks, not months. If they are already planned, formalizing them in the Temp Check costs nothing and strengthens community confidence.\nOnce these are met, the DAO can evaluate a funding proposal on fair terms, with a real Foundation in place, transparent governance holdings, verifiable revenue, and each component voted on individually.\nGood day for Aave governance. The community pushed for alignment and got a response. Now make sure the response is real, enforceable, and fair.\n\nDisclaimer: I am the founder of the Aave Chan Initiative, a delegate platform and service provider to the Aave DAO.\n\n post by JesusCryptoPlaza on Feb 12\n\n JesusCryptoPlaza\n\n Comment: Revenue Alignment Is Not Enough — We Must Address Value Capture and the Agency Problem\nFirst, credit where it is due: governance worked. As Marc pointed out, this proposal did not appear in a vacuum. Community pressure around revenue alignment, transparency, and structure has clearly influenced the direction. That is a positive signal for Aave.\nIt is also important to recognize the leadership that brought Aave here.\nAave did not reach 60% lending market share by accident. Over multiple cycles, the team has delivered V2 and V3 as industry standards, built one of the strongest security track records in DeFi, expanded across chains, generated over $100M in annualized protocol revenue, and maintained institutional credibility through complex regulatory environments. That competitive edge has been earned. Execution quality has been a defining strength of this protocol.\nFor that reason, this discussion should not evolve into reflexive distrust. Aave Labs has demonstrated competence and resilience. That trust has been built through performance — and it matters.\nHowever, there is still a major dimension missing from this debate: value capture for AAVE holders.\nWe are discussing:\n\nThe definition of “100% revenue”\n\nWhether deductions are at Labs’ discretion\n\nThe size of the $50M funding request\n\nThe 75,000 AAVE token transfer and its governance implications\n\nWhether V4 should be ratified now or later\n\nWhether the vote should be unbundled\n\nAll legitimate concerns. But none of them address the core economic question:\nHow does this translate into structural value accrual for the token holder?\nIf 100% of product revenue flows to the DAO treasury, that is a meaningful structural improvement. But revenue flowing into a treasury is not the same as value flowing to token holders. Treasury growth without a capital allocation framework can easily become undisciplined spending.\nThis proposal is clearly growth-oriented. Significant stablecoin funding. Large token transfers. Expansion into new verticals. Acceleration toward V4. That may be strategically sound — and Aave’s leadership has historically executed well — but growth without value capture creates an asymmetry:\n\nThe ecosystem grows\n\nThe operational footprint expands\n\nCosts increase\n\nBut token holders remain structurally residual and indirect beneficiaries\n\nAt some point, we must define whether AAVE is meant to behave like productive capital or purely like governance utility.\nWe must also acknowledge the agency problem structurally embedded here.\nWe are in a situation where entities closely connected to product development may also be governance participants and potentially significant token holders. In other words:\n\nInvestors\n\nService providers\n\nGovernance actors\n\nmay overlap.\nThis does not imply bad faith — and Aave’s leadership has earned credibility. But strong leadership does not eliminate structural agency risk. It makes it more important to design safeguards that protect the system long term.\nIndependent revenue verification, full wallet disclosure for funded entities, and clear boundaries around discretionary deductions are not expressions of distrust. They are governance hygiene in a maturing protocol that is scaling economically.\nAt the same time, we must avoid the opposite risk: turning governance into a coordination bottleneck.\nAave’s competitive advantage has always been its ability to move decisively while maintaining credible decentralization. We should be careful not to penalize that edge. Other protocols have shown how excessive procedural friction, fragmented votes, and political gridlock can weaken even technically superior systems. Governance should protect the protocol — not paralyze it.\nIntroducing clearer value capture mechanisms for token holders would actually reduce tension in this system. Beginning to return part of the value — whether through buybacks, staking yield, or structured fee capture — would introduce capital discipline without undermining execution speed. It would require prioritization. It would reduce the risk of over-optimization: deploying capital across too many fronts, expanding aggressively in multiple directions, and gradually losing strategic focus.\nMany organizations do not lose competitiveness because they underinvest. They lose it because they overextend.\nAave V3 is a $100M+ annualized revenue engine. V4 may well be the future. Product expansion may unlock significant upside. This is precisely why now is the moment to define the long-term economic model of the token.\nRevenue alignment is necessary.\nGovernance safeguards are necessary.\nPreserving execution advantage is necessary.\nBut structural value capture discipline is equally necessary.\nIf we institutionalize growth without institutionalizing value accrual, we risk building a larger system that does not proportionally reward the capital base that secures and governs it.\nThis is not an argument against the proposal’s direction.\nIt is an argument for completing it — responsibly, strategically, and with long-term alignment in mind.\n\n post by Emereb on Feb 12\n\n Emereb\n\n This is a good first step, and I’m glad to see Labs explicitly align on the principle that 100% of Aave-branded product-layer revenues should flow back to the DAO. That said, I agree with @MarcZeller we need a clear, auditable definition of what “100%” means in practice.\nConcretely, before this can be considered “done”, the DAO should have:\n\na public revenue & permissions map (all product-layer streams, recipient addresses, who can change what, and under what process),\n\nregular reporting (quarterly at minimum) with verifiable numbers, and\n\nan independent audit / attestation for the major revenue streams.\n\nOn the budget side, I’ve said it before, Aave Labs has been doing excellent work, and I’m supportive of funding OPEX, growth, and user acquisition, but with standard governance hygiene, a clear budget breakdown, measurable KPIs, and milestone-based releases (especially for launch grants).\nOn the 75k AAVE ask, this is not just compensation, it is governance power. Market-standard alignment is typically 4-year vesting, not 2 so I’m asking Labs to be compliant with market practice, and to avoid recreating today’s legitimacy “soft governance” concerns that @stani said, the DAO should require governance guardrails around that stake (e.g., fixed/neutral delegation and strong COI recusal norms, with consequences tied to mandates/funding), so voting legitimacy is preserved.\nIf Labs is aligned with these principles, clear definition of “100%”, transparency/auditability, budget accountability, and long-term/low-risk token alignment, I believe we all win over the long term and we restore confidence in the token’s utility and valuation.\n\n post by JonahSkycatcher on Feb 12\n\n JonahSkycatcher\n\n very good to see, great direction. lead vision like this has been needed.\nA few key things that would be worthy additions - posting for community consideration:\n1) ROIC Framework - A Return on invested capital framework for all grants, in particular growth spend could be implemented and administered by a 3P SP like TokenLogic. This way all DAO spend is made against an accountable to framework that allows DAO & voters to allocate more capital according to expected return (and track record of returns). Good for everyone.\n2) DAO Spend Plan - As part of this, audit of DAO spend plans probably in order. 3P SPs providing financial accounting / audit services and risk services probably still makes sense. But on things like development etc, how much will Labs be doing here vs what DAO is also paying for elsewhere?\n3) Contractual Terms - Think we need contractual terms that suitably enforce these terms for DAO / Token Holders. Technological details as well. The hole deal is better off for it, incomplete without it.\n4) Larger AAVE allocation thats KPI Based - The proposed allocation of AAVE tokens is actually quite small (less than 1% of total supply?). So this part of the deal actually costs very little for each token holder. As such, I’d be in favor of higher allocation of AAVE tokens if a KPI-based vesting framework was implemented. Extra capital to invest in / incentivize RWA-focused BD efforts, for example, passes the expected ROIC sniff test. Esp if we can guarantee the expected business KPI / outcome.\nOverall excellent to see this and think this deal is well structured. Would like to see these 4 things added and then will certainly be voting yes.\n\n post by Gross on Feb 12\n\n Gross\n\n We cannot afford to waste months in debate and paralysis analysis. We have lost enough time already and we need to take action now. While we argue over details, institutional giants like BlackRock and major players are looking for entry points into DeFi. If we don’t resolve this uncertainty quickly, they will choose other protocols and we will lose our competitive edge. I am confident that Stani and the team are reading these comments and taking the community’s feedback to heart.\nLooking at the bigger picture, everyone agrees that this is a positive, logical proposal with the right vision for Aave. There is no fundamental disagreement here. The community really only has four specific concerns. If these valid points are addressed, I believe this proposal will pass with 100% support.\nBridging the gap on these four points is entirely achievable.\n1-The 75,000 AAVE allocation is the biggest friction point. The community finds the amount excessive and worries about the governance pressure it creates. Stani needs to meet us in the middle here. If this number is reduced to a reasonable 35-40k AAVE and vested over a standard 4-year period, I don’t think anyone would oppose it. This balances team incentives with DAO security.\n2-There needs to be flexibility regarding the $25M budget. No one is against Aave Labs developing products and being profitable, provided that the revenue and expense structures are transparent. As long as we have clarity, the funding won’t be an issue.\n3-We should keep V3 active. No one opposes the development of V4, but the majority wants V3 to remain the backbone until V4 has proven its security and stability. V3 is currently a cash cow generating significant revenue, so shutting it down prematurely is an unnecessary risk. Migration to V4 can be driven by incentives over time, allowing for a planned and safe transition.\n4-","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260681585,"hash":"b4a6d7e4162ed87a59d525dab64cc5aa2a956282"}
{"url":"https://eips.ethereum.org/EIPS/eip-2","domain":"eips.ethereum.org","title":"EIP-2: Homestead Hard-fork Changes","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-2: Homestead Hard-fork Changes\n\n Authors\n Vitalik Buterin (@vbuterin)\n\n Created\n 2015-11-15\n\n Meta reference\n\nHomestead.\n\n Parameters\n\n FORK_BLKNUM\n CHAIN_NAME\n\n 1,150,000\n Main net\n\n 494,000\n Morden\n\n 0\n Future testnets\n\n Specification\n\nIf block.number >= HOMESTEAD_FORK_BLKNUM, do the following:\n\n The gas cost for creating contracts via a transaction is increased from 21,000 to 53,000, i.e. if you send a transaction and the to address is the empty string, the initial gas subtracted is 53,000 plus the gas cost of the tx data, rather than 21,000 as is currently the case. Contract creation from a contract using the CREATE opcode is unaffected.\n All transaction signatures whose s-value is greater than secp256k1n/2 are now considered invalid. The ECDSA recover precompiled contract remains unchanged and will keep accepting high s-values; this is useful e.g. if a contract recovers old Bitcoin signatures.\n If contract creation does not have enough gas to pay for the final gas fee for adding the contract code to the state, the contract creation fails (i.e. goes out-of-gas) rather than leaving an empty contract.\n Change the difficulty adjustment algorithm from the current formula: block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + int(2**((block.number // 100000) - 2)) (where the int(2**((block.number // 100000) - 2)) represents the exponential difficulty adjustment component) to block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2)), where // is the integer division operator, eg. 6 // 2 = 3, 7 // 2 = 3, 8 // 2 = 4. The minDifficulty still defines the minimum difficulty allowed and no adjustment may take it below this.\n\n Rationale\n\nCurrently, there is an excess incentive to create contracts via transactions, where the cost is 21,000, rather than contracts, where the cost is 32,000. Additionally, with the help of suicide refunds, it is currently possible to make a simple ether value transfer using only 11,664 gas; the code for doing this is as follows:\n\nfrom ethereum import tester as t\n> from ethereum import utils\n> s = t.state()\n> c = s.abi_contract('def init():\\n suicide(0x47e25df8822538a8596b28c637896b4d143c351e)', endowment=10**15)\n> s.block.get_receipts()[-1].gas_used\n11664\n> s.block.get_balance(utils.normalize_address(0x47e25df8822538a8596b28c637896b4d143c351e))\n1000000000000000\n\nThis is not a particularly serious problem, but it is nevertheless arguably a bug.\n\nAllowing transactions with any s value with 0 < s < secp256k1n, as is currently the case, opens a transaction malleability concern, as one can take any transaction, flip the s value from s to secp256k1n - s, flip the v value (27 -> 28, 28 -> 27), and the resulting signature would still be valid. This is not a serious security flaw, especially since Ethereum uses addresses and not transaction hashes as the input to an ether value transfer or other transaction, but it nevertheless creates a UI inconvenience as an attacker can cause the transaction that gets confirmed in a block to have a different hash from the transaction that any user sends, interfering with user interfaces that use transaction hashes as tracking IDs. Preventing high s values removes this problem.\n\nMaking contract creation go out-of-gas if there is not enough gas to pay for the final gas fee has the benefits that:\n\n (i) it creates a more intuitive “success or fail” distinction in the result of a contract creation process, rather than the current “success, fail, or empty contract” trichotomy;\n (ii) makes failures more easily detectable, as unless contract creation fully succeeds then no contract account will be created at all; and\n (iii) makes contract creation safer in the case where there is an endowment, as there is a guarantee that either the entire initiation process happens or the transaction fails and the endowment is refunded.\n\nThe difficulty adjustment change conclusively solves a problem that the Ethereum protocol saw two months ago where an excessive number of miners were mining blocks that contain a timestamp equal to parent_timestamp + 1; this skewed the block time distribution, and so the current block time algorithm, which targets a median of 13 seconds, continued to target the same median but the mean started increasing. If 51% of miners had started mining blocks in this way, the mean would have increased to infinity. The proposed new formula is roughly based on targeting the mean; one can prove that with the formula in use, an average block time longer than 24 seconds is mathematically impossible in the long term.\n\nThe use of (block_timestamp - parent_timestamp) // 10 as the main input variable rather than the time difference directly serves to maintain the coarse-grained nature of the algorithm, preventing an excessive incentive to set the timestamp difference to exactly 1 in order to create a block that has slightly higher difficulty and that will thus be guaranteed to beat out any possible forks. The cap of -99 simply serves to ensure that the difficulty does not fall extremely far if two blocks happen to be very far apart in time due to a client security bug or other black-swan issue.\n\n Implementation\n\nThis is implemented in Python here:\n\n https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L130\n https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L129\n https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L304\n https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/blocks.py#L42\n\n Citation\n Please cite this document as:\n\n Vitalik Buterin (@vbuterin), \"EIP-2: Homestead Hard-fork Changes,\" Ethereum Improvement Proposals, no. 2, November 2015. Available: https://eips.ethereum.org/EIPS/eip-2.","tokens":1508,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260688804,"hash":"2ae347042bcaca74cdfe0fae1a35a8cc08412b96"}
{"url":"https://ethereum.org/community/","domain":"ethereum.org","title":"Community Hub | ⁦ethereum.org⁩","text":"Why get involved?Find your tribeThere is a tribe for everyone. Find and connect with like minded individuals to discuss, ponder, and celebrate Ethereum together.Discover EventsEarn a livingEveryone has bills to pay. Ethereum allows you to find meaningful work, and get paid well to do it.Find a jobMake a differenceGetting involved with Ethereum allows you to be an active stakeholder in a technology that is having a positive impact on millions of people.Get InvolvedCreator? Builder? Get paid for your work.Whatever your skills, there's a place for you in the Ethereum ecosystem. Help build a better internet alongside a global community.Explore grantsFind a jobRoom for every skillDesign, writing, community, research, operations. Ethereum runs on far more than code, and it needs your kind of talent.Back your own ideaHave a project or community of your own? Grants across the ecosystem help you grow your vision.Build what lastsContribute to open, public infrastructure that can't be silenced by governments, corporations, or algorithms. What you help build stays.Digital sovereigntyOwn your identity, assets, and creations online without relying on platforms that can delete you.Join an online communityFind your tribe and participate in community with other Ethereum enthusiasts.r/ethereumAll things Ethereum+3.7M members (opens in a new tab)r/ethtraderTrends & market analysis+2.3M members (opens in a new tab)r/ethdevFocused on Ethereum development+120K members (opens in a new tab)See all communitiesMajor blockchain conferencesJoin online and in-person events around the globe.AFT '26Oct 5 – 8London, United Kingdom (opens in a new tab)Ethereum Ecosystem Summit @Token2049 SingaporeOct 8Singapore (opens in a new tab)Paradigm FrontiersOct 11 – 13San Francisco, United States (opens in a new tab)EDCON2026 Kuala LumpurOct 16 – 18Kuala Lumpur, Malaysia (opens in a new tab)ETHVenice 2026October 20Venice, Italy (opens in a new tab)Ethereum Cypherpunk Congress #3November 1Mumbai, India (opens in a new tab)See all eventsEthereum voicesEthereum community members share how the network has made a difference in their lives.Suraj SharmaIndia (opens in a new tab)Talent in India is not limited to metros. I've seen curious and capable developers who just lacked early exposure to protocols, grants and global conversations. Ethereum gives us open access, open source code, open communities, open coordination. That permissionless layer is powerful.Jatin PandyaIndia (opens in a new tab)ETHIndia 2022 was a turning point. The energy of hundreds of developers shipping at midnight convinced me this ecosystem was worth committing to. I went from participant to mentor to organizer. Ethereum taught me that communities ship. I saw firsthand how one ecosystem could spawn an entire generation of Indian builders. Ethereum gave that talent a global stage. Developers here aren't just building for India anymore; now they are building for the world.Bhawna ChauhanIndia (opens in a new tab)I discovered Ethereum, and that moment completely redirected my life. It wasn't just a career change, it was a new beginning. Driven by curiosity, I dived headfirst into the Bitcoin whitepaper and the fundamentals of Ethereum. That curiosity soon turned into a passion for building. The thrill of winning a track prize at my first online hackathon was the spark I needed. Since then, I haven't stopped building and shipping.SamuelNigeriaBefore Ethereum, opportunities for many developers like me, especially in Nigeria and across Africa, were very limited. Access to global tech communities, funding, mentorship, and even simply being seen was incredibly hard. Ethereum changed that for me and for many people I know. It helped us overcome barriers of geography, background, and limited resources. Through Ethereum, we could contribute to open-source projects, earn real experience, build real products, and be part of something bigger than ourselves, without needing permission from institutions or borders.MesoReefDAOMexico (opens in a new tab)We are using Ethereum to create new coordination mechanisms within a DeSciDAO, allowing us to allocate various forms of capital with smart contracts and accelerate research and citizen science in coral reef conservation initiatives and programs in Mesoamerica, with plans to scale these efforts worldwide.LidaIranI couldn't withdraw funds on offshore cryptocurrency apps, but Ethereum made it so easy.TranslationThiagoBrazilIn emerging regions, instability, distrust, and social inequality are commonplace. Ethereum offers not only a technological alternative, but a philosophical one. It allows us to build systems where transparency is default, trust is programmable, and access is open.EmmanuelNigeriaEthereum has reduce poverty on average Nigeria youth. Young guys and ladies either trade or writing codes. This has help to reduce unemployment in my community.NicoNetherlands (opens in a new tab)I use Ethereum on a daily basis. With my Gnosis Pay card it's very easy to link my wallet to my daily expenses, and the best of it all is that I can leverage DeFi at the same time. That means that even my current account is earning yield, while keeping my funds accessible and easy to spend.NicoNetherlands (opens in a new tab)My family lives in Bolivia, and when my brother went to study abroad it was extremely expensive to send him money. Bank transfers are extremely expensive, and solutions like MoneyGram or Western Union would take huge cuts on the transfer. It was a big relief when we discovered that we could send him money with crypto at a fraction of the cost.FacuArgentinaEthereum has helped Argentinians overcome the limits of a broken financial system. It gave us a way to earn and save (mostly in stablecoins), despite inflation, currency controls, and constant uncertainty.YamillePeru (opens in a new tab)Ethereum helped us break down many barriers we took for granted. Not just technical ones, but also mental ones: believing that technology was foreign, that you had to speak a certain language, live in a certain place, or have a specific profile to access real opportunities.\n\nFor me and my community, it opened the door to global spaces, where what matters is what you contribute, not where you come from. It allowed us to explore, learn, and build on what we already knew but with a totally new vision.\n\nAnd that also showed us that we can be in both worlds—creative and technological—and add value from there.Open-source project12,000+ contributorsContribute to ethereum.orgFor many people, ethereum.org is their first step into the ecosystem. It is kept up-to-date and accurate by thousands of open-source contributors. Want to help? Read our guide on contributing, or take up an issue on our GitHub.More on contributingView on GitHub (opens in a new tab)Try Ethereum for yourself","tokens":1710,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260689598,"hash":"05fcb01a8d452ee75f0e79a763fea67778cbc14a"}
{"url":"https://eips.ethereum.org/EIPS/eip-145","domain":"eips.ethereum.org","title":"EIP-145: Bitwise shifting instructions in EVM","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-145: Bitwise shifting instructions in EVM\n\n To Provide native bitwise shifting with cost on par with other arithmetic operations.\n\n Authors\n Alex Beregszaszi (@axic), Paweł Bylica (@chfast)\n\n Created\n 2017-02-13\n\n Abstract\n\nNative bitwise shifting instructions are introduced, which are more efficient processing wise on the host and are cheaper to use by a contract.\n\n Motivation\n\nEVM is lacking bitwise shifting operators, but supports other logical and arithmetic operators. Shift operations can be implemented via arithmetic operators, but that has a higher cost and requires more processing time from the host. Implementing SHL and SHR using arithmetic cost each 35 gas, while the proposed instructions take 3 gas.\n\n Specification\n\nThe following instructions are introduced:\n\n 0x1b: SHL (shift left)\n\nThe SHL instruction (shift left) pops 2 values from the stack, first arg1 and then arg2, and pushes on the stack arg2 shifted to the left by arg1 number of bits. The result is equal to\n\n(arg2 * 2^arg1) mod 2^256\n\nNotes:\n\n The value (arg2) is interpreted as an unsigned number.\n The shift amount (arg1) is interpreted as an unsigned number.\n If the shift amount (arg1) is greater or equal 256 the result is 0.\n This is equivalent to PUSH1 2 EXP MUL.\n\n 0x1c: SHR (logical shift right)\n\nThe SHR instruction (logical shift right) pops 2 values from the stack, first arg1 and then arg2, and pushes on the stack arg2 shifted to the right by arg1 number of bits with zero fill. The result is equal to\n\nfloor(arg2 / 2^arg1)\n\nNotes:\n\n The value (arg2) is interpreted as an unsigned number.\n The shift amount (arg1) is interpreted as an unsigned number.\n If the shift amount (arg1) is greater or equal 256 the result is 0.\n This is equivalent to PUSH1 2 EXP DIV.\n\n 0x1d: SAR (arithmetic shift right)\n\nThe SAR instruction (arithmetic shift right) pops 2 values from the stack, first arg1 and then arg2, and pushes on the stack arg2 shifted to the right by arg1 number of bits with sign extension. The result is equal to\n\nfloor(arg2 / 2^arg1)\n\nNotes:\n\n The value (arg2) is interpreted as a signed number.\n The shift amount (arg1) is interpreted as an unsigned number.\n If the shift amount (arg1) is greater or equal 256 the result is 0 if arg2 is non-negative or -1 if arg2 is negative.\n This is not equivalent to PUSH1 2 EXP SDIV, since it rounds differently. See SDIV(-1, 2) == 0, while SAR(-1, 1) == -1.\n\nThe cost of the shift instructions is set at verylow tier (3 gas).\n\n Rationale\n\nInstruction operands were chosen to fit the more natural use case of shifting a value already on the stack. This means the operand order is swapped compared to most arithmetic instructions.\n\n Backwards Compatibility\n\nThe newly introduced instructions have no effect on bytecode created in the past.\n\n Test Cases\n\n SHL (shift left)\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x00\nSHL\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x01\nSHL\n---\n0x0000000000000000000000000000000000000000000000000000000000000002\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0xff\nSHL\n---\n0x8000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x0100\nSHL\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x0101\nSHL\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x00\nSHL\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x01\nSHL\n---\n0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0xff\nSHL\n---\n0x8000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x0100\nSHL\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x01\nSHL\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x01\nSHL\n---\n0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe\n\n SHR (logical shift right)\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x00\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x01\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x01\nSHR\n---\n0x4000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0xff\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x0100\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x0101\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x00\nSHR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x01\nSHR\n---\n0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0xff\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x0100\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x01\nSHR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n SAR (arithmetic shift right)\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x00\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000001\nPUSH 0x01\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x01\nSAR\n---\n0xc000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0xff\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x0100\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0x8000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x0101\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x00\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x01\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0xff\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x0100\nSAR\n---\n0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\n\n PUSH 0x0000000000000000000000000000000000000000000000000000000000000000\nPUSH 0x01\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x4000000000000000000000000000000000000000000000000000000000000000\nPUSH 0xfe\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0xf8\nSAR\n---\n0x000000000000000000000000000000000000000000000000000000000000007f\n\n PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0xfe\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000001\n\n PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0xff\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n PUSH 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff\nPUSH 0x0100\nSAR\n---\n0x0000000000000000000000000000000000000000000000000000000000000000\n\n Implementation\n\nClient support:\n\n cpp-ethereum: https://github.com/ethereum/cpp-ethereum/pull/4054\n\nCompiler support:\n\n Solidity/LLL: https://github.com/ethereum/solidity/pull/2541\n\n Tests\n\nSources:\n\n https://github.com/ethereum/tests/tree/develop/src/GeneralStateTestsFiller/stShift\n\nFilled Tests:\n\n https://github.com/ethereum/tests/tree/develop/GeneralStateTests/stShift\n https://github.com/ethereum/tests/tree/develop/BlockchainTests/GeneralStateTests/stShift\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Alex Beregszaszi (@axic), Paweł Bylica (@chfast), \"EIP-145: Bitwise shifting instructions in EVM,\" Ethereum Improvement Proposals, no. 145, February 2017. Available: https://eips.ethereum.org/EIPS/eip-145.","tokens":2437,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260711271,"hash":"be3d198338b4e81823ddbe8910bbd24d518ad645"}
{"url":"https://ethereum.org/community/get-involved/","domain":"ethereum.org","title":"How can I get involved? | ethereum.org","text":"Edit page (opens in a new tab)The Ethereum community includes people of many different backgrounds and skillsets. Whether you’re a developer, an artist, or an accountant, there are ways to get involved. Here’s a list of suggestions that might help you get started.\nStart by reading about the ethereum.org mission and values in our code of conduct.\nDevelopers ‍\n\nLearn about and try Ethereum at ethereum.org/developers/\nAttend an ETHGlobal (opens in a new tab) hackathon near you!\nCheck out projects related to your area of expertise or programming language of choice\nWatch or participate in the Consensus and Execution Layer calls (opens in a new tab)\nEcosystem Support Program's wishlist (opens in a new tab) - tooling, documentation, and infrastructure areas where the Ethereum Ecosystem Support Program is actively seeking grant applications\nWeb3Bridge (opens in a new tab) - join the aspiring web3 community in their initiative to identify, train, and support hundreds of developers and community members throughout Africa\nJoin the Eth R&D Discord (opens in a new tab)\nJoin the Ethereum Cat Herders Discord (opens in a new tab)\n\nResearchers & Academics ‍\nDo you have a background in mathematics, cryptography, or economics? You might be interested in some of the cutting-edge work being done within the Ethereum ecosystem:\n\nJoin the Eth R&D Discord (opens in a new tab)\nWrite or review an Ethereum Improvement Proposal\n\nWrite an EIP\n\nSubmit your idea on Ethereum Magicians (opens in a new tab)\nRead EIP-1 (opens in a new tab) - Yes, that's the entire document.\nFollow the directions in EIP-1. Reference it as you write your draft.\n\nLearn how to become an EIP Editor (opens in a new tab)\n\nYou can peer-review EIPs right now! See open PRs with the e-review tag (opens in a new tab). Provide technical feedback on the discussion-to link.\n\nParticipate in EIP Governance (opens in a new tab)\n\nJoin the Ethereum Cat Herders Discord (opens in a new tab)\n\nMore on EIPs\n\nChallenges.ethereum.org (opens in a new tab) - a series of high-value research bounties, where you can earn >$100,000 USD\nEthresear.ch (opens in a new tab) - Ethereum’s primary forum for research, and the world’s most influential forum for cryptoeconomics\nEF Research AMA (opens in a new tab) - An ongoing Q&A series with researchers. As each next part opens, anyone can post questions.\nEcosystem Support Program's wishlist (opens in a new tab) - research areas where the Ethereum Ecosystem Support Program is actively seeking grant applications\nAllWalletDevs (opens in a new tab) - a forum for Ethereum developers, designers, and interested users to come together regularly and discuss wallets\n\nExplore more active areas of research.\nNon-technical skillsets ‍\nIf you’re not a developer, it can be hard to know where to start in Ethereum. Here are a few suggestions, along with resources for specific professional backgrounds.\nOrganize a meetup in your city\n\nNot sure how to start? The BUIDL network (opens in a new tab) can help.\n\nWrite content about Ethereum\n\nEthereum needs good writers who can explain its value in plain language\nNot ready to publish your own articles? Consider contributing to the existing content on community resources, or propose new content for ethereum.org!\n\nOffer to take notes for community calls\n\nThere are many open-source community calls, and having notetakers is a huge help. If you’re interested, join the Ethereum Cat Herders discord (opens in a new tab), and introduce yourself!\n\nHelp improve translated Ethereum content\n\nThe ethereum.org Translation Program is winding down and is no longer onboarding new translators—see the program page for its status and history\nYou can still help by reporting errors in existing translations (opens in a new tab)\n\nRun a node\nJoin thousands of node operators in helping to further decentralize Ethereum.\n\nMore on how to run a node\n\nStake your ETH\nBy staking your ETH you can earn rewards whilst helping to secure the Ethereum network.\n\nMore on staking\n\nSupport projects\nThe Ethereum ecosystem is on a mission to fund public goods and impactful projects. With very small donations you can show your support and allow important work to be realized.\n\nGitcoin (opens in a new tab)\nclr.fund (opens in a new tab)\n\nFinancial professionals & Accountants ‍\n\nEthereum is home to the “Decentralized Finance” ecosystem - a network of protocols and applications that offer an alternative financial system. If you’re a financial professional, check out some DeFi apps at DeFi Llama (opens in a new tab) or DeFiPrime (opens in a new tab)\nAccountant? Assets on Ethereum - ETH, tokens, DeFi, etc - introduce many novel accounting issues. You could start by checking out some projects that aim to help users of cryptocurrency solve their bookkeeping & accounting challenges, like Rotki (opens in a new tab)\n\nProduct Managers 🖋‍\n\nThe Ethereum ecosystem needs your talents! Many companies are hiring for product manager roles. If you want to start by contributing to an open source project, get in touch with the Ethereum Cat Herders (opens in a new tab) or RaidGuild (opens in a new tab)\n\nMarketing ‍\n\nThere are many marketing and communications positions in the Ethereum ecosystem!\n\nEthereum jobs\nWant to find a job working in Ethereum?\n\nethereum.org jobs\nEthereum Foundation job board (opens in a new tab)\nJobStash (opens in a new tab)\nEthereum Job Board (opens in a new tab)\nCryptocurrency Jobs (opens in a new tab)\nCareers at ConsenSys (opens in a new tab)\nCrypto Jobs List (opens in a new tab)\nBankless jobs board (opens in a new tab)\nWeb3 Jobs (opens in a new tab)\nWeb3 Army (opens in a new tab)\nCrypto Valley Jobs (opens in a new tab)\nEthereum Jobs (opens in a new tab)\n\nJoin a DAO\n\"DAOs\" are decentralized autonomous organizations. These groups leverage Ethereum technology to facilitate organization and collaboration. For instance, for controlling membership, voting on proposals, or managing pooled assets. While DAOs are still experimental, they offer opportunities for you to find groups that you identify with, find collaborators, and grow your impact on the Ethereum community. More on DAOs\n\nDAOSquare (opens in a new tab) @DAOSquare (opens in a new tab) - Promote the DAO concept in non-tech field and help people create value through DAO\nDeveloper DAO (opens in a new tab) @developer_dao (opens in a new tab) - Community of builders who believe in collective ownership of the internet\ndOrg (opens in a new tab) @dOrg_tech (opens in a new tab) - Freelancer Web3 development collective working as a DAO\nHausDAO (opens in a new tab) @nowdaoit (opens in a new tab) - Community governance of DAOhaus\nLexDAO (opens in a new tab) @lex_DAO (opens in a new tab) - Legal engineering\nMetaCartel Ventures (opens in a new tab) @VENTURE_DAO (opens in a new tab) - Venture for pre-seed crypto projects\nMetaFactory (opens in a new tab) @TheMetaFactory (opens in a new tab) - Digiphysical Apparel Brands\nRaid Guild (opens in a new tab) @RaidGuild (opens in a new tab) - Collective of Web3 builders\n\nPlease remember to abide by the ethereum.org code of conduct whenever and however you contribute to ethereum.org!","tokens":1784,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260711572,"hash":"1b21ba7bda3360c0790f936c89615950f3feeab8"}
{"url":"https://ethereum.org/layer-2/networks/","domain":"ethereum.org","title":"Ethereum Layer 2:Explore networks | ⁦ethereum.org⁩","text":"Ethereum networksFilters (5)Wallet supportNetwork maturityRobustFully decentralized and secure network that cannot be tampered with or stopped by any individual or group, including its creators.This is a network that fulfills Ethereum's vision of decentralization.MaturingA network transitioning to being decentralized. A group of actors still may be able to halt the network in extreme situations.DevelopingA centralized operator runs the network but adds fail-safe features to reduce risks of centralization.EmergingA centralized operator runs the network. The data is publicly visible on Ethereum to verify whether the operator is being honest.Networks showing (11)Avg. transaction fee Market share Network maturity Ethereum MainnetAvg. transaction fee$0.035Market share$329B$0.035$329BBaseAvg. transaction fee$0.002Market share$16.4B$0.002$16.4BArbitrum OneAvg. transaction fee$0.004Market share$11.5B$0.004$11.5BOptimismAvg. transaction fee$0.00Market share$2.00B$0.00$2.00BStarknetAvg. transaction fee$0.008Market share$534M$0.008$534MInkAvg. transaction fee$0.00Market share$440M$0.00$440MUnichainAvg. transaction fee$0.00Market share$91.6M$0.00$91.6MZKSync EraAvg. transaction fee-Market share$276M-$276MScrollAvg. transaction fee$0.002Market share$48.7M$0.002$48.7MLineaAvg. transaction fee$0.022Market share$378M$0.022$378MZircuitAvg. transaction fee-Market share$12.5M-$12.5MLooking for more advanced overview?Many of the projects are still young and somewhat experimental.For more information on the technology, risks and trust assumptions of these networks, we recommend checking out L2BEAT, which provides a comprehensive risk assessment framework of each project and growthepie for general data analysis.Visit l2beat.com (opens in a new tab)Visit growthepie.com (opens in a new tab)Network maturity explainedWe review the network's progress towards Ethereum alignment (opens in a new tab): total value locked (TVL), time live in production, and risk considerations. These levels help track network development and provide a standardized way for the community to evaluate progress.Technical progress alone is not enough, user adoption and age are essential part of the overall strength and maturity on any network.MaturityRequirementsRobust• Stage 2• At least $1B TVLMaturing• Stage 1• At least $150M TVL• 6+ months live in productionDeveloping• Stage 0• Risk assessment: 3/5 (L2beat)• At least $150M TVL• 6+ months live in productionEmerging• Stage 0• Risk assessment: 2/5 (L2beat)• At least $150M TVL or 6+ months live in production","tokens":637,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260735737,"hash":"9c3ca05634007277456d88d63ee706811d76f1ad"}
{"url":"https://dev-forum.pyth.network/c/forum-feedback/10/l/hot","domain":"dev-forum.pyth.network","title":"Hot Forum Feedback topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Hot topics in Forum Feedback\n\n Forum Feedback\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Forum Feedback category\n\n Feedback on how to make this developer forum better for you! \nPlease note, if you are looking for support on Pyth Products, please search or add a new topic under respective category.\n\n 0\n\n 450\n\n Apr 2025\n\n Powered by Discourse","tokens":979,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260735771,"hash":"ce153fe0a499f42f4557bc82debadf019b6be633"}
{"url":"https://forum.openzeppelin.com/c/smart-contracts/review-wanted/38","domain":"forum.openzeppelin.com","title":"Latest Smart Contracts/Review Wanted topics - OpenZeppelin Forum","text":"Latest topics in Review Wanted\n\n Smart Contracts\n\n Review Wanted\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Review Wanted category\n\n Ask the community to informally review your code. NOT A SUBSTITUTE FOR A PROFESSIONAL AUDIT.\n\n 0\n\n 650\n\n May 2021\n\n Broken OpenZeppilin ERC-721 repo on github missing ./extensions/IERC721Metadata.sol file\n\n erc721,solidity,openzeppelin-contracts,remix\n\n 0\n\n 40\n\n Jul 2025\n\n Signature validation works only for contract owner, fails for other accounts\n\n etherscan-verify\n\n 1\n\n 87\n\n Jun 2025\n\n I cant send my coins to another wallet\n\n bep20\n\n 0\n\n 42\n\n Feb 2025\n\n Scam meme coin? PEPE TRUMP BNB chain\n\n 10\n\n 1.0k\n\n Feb 2025\n\n Erc20 création de token\n\n erc20,etherscan-verify\n\n 1\n\n 49\n\n Dec 2024\n\n New to Solidity, first attempt at ERC20\n\n 2\n\n 127\n\n Dec 2024\n\n Should Burn work coming from the liquidity pool of Pancakeswap in Testnet?\n\n bep20\n\n 2\n\n 72\n\n Dec 2024\n\n // SPDX-License-Identifier: MIT pragma solidity ^0.8.22; verifying on BscScan\n\n etherscan-verify\n\n 1\n\n 332\n\n Dec 2024\n\n Review token with uniswap buy limit during the first transactions\n\n erc20\n\n 2\n\n 85\n\n Nov 2024\n\n Wrong contract address when I bought tokens\n\n 0\n\n 40\n\n Sep 2024\n\n Review this contract generated with help of AI\n\n 3\n\n 453\n\n Sep 2024\n\n Sign and Send usdt meta transaction to defender relay\n\n 1\n\n 144\n\n Jul 2024\n\n I need help getting this deployed and contract fixed\n\n etherscan-verify\n\n 1\n\n 132\n\n Jul 2024\n\n Scam token on BSC pancakeswap ons\n\n bep20\n\n 10\n\n 499\n\n Jul 2024\n\n I need a review and some fix to this smart contract\n\n 0\n\n 113\n\n Jun 2024\n\n Listable Contract?\n\n 0\n\n 93\n\n Jun 2024\n\n I can’t adjust the tax\n\n erc20\n\n 0\n\n 163\n\n Apr 2024\n\n Help reviewing this lazy minting contract with royalties for NFT collection\n\n etherscan-verify,erc721\n\n 2\n\n 322\n\n Feb 2024\n\n Forwarder Verifying without Signed `from`\n\n 2\n\n 255\n\n Feb 2024\n\n Need some people to test smartcontract\n\n 2\n\n 242\n\n Jan 2024\n\n “Gas estimation failed” when deploying on mainnet\n\n 0\n\n 311\n\n Oct 2023\n\n Blockchain Experts, I need your attention on Fractional Ownership of NFT\n\n erc20,erc721,erc1155,nft\n\n 7\n\n 2.0k\n\n Oct 2023\n\n Discussion on Feature Request: Granular Control Modifiers in Context.sol Contract\n\n 0\n\n 321\n\n Oct 2023\n\n Evidence Token NFT need review of my smart contract ready for deployment\n\n 0\n\n 345\n\n Aug 2023\n\n Uniswap v2 cannot add liquidity with error “execution reverted: TransferHelper: TRANSFER_FROM_FAILED”\n\n etherscan-verify\n\n 6\n\n 3.0k\n\n Aug 2023\n\n Weird results where you cannot buy or remove liquidity… need assistance please!\n\n erc20,etherscan-verify,bep20\n\n 1\n\n 662\n\n Jul 2023\n\n Does this simple ERC20 code using OpenZeppelin looks safe?\n\n erc20\n\n 7\n\n 754\n\n Jul 2023\n\n ERC20 token showing insufficient liquidity even after adding pool on uniswap\n\n erc20\n\n 1\n\n 762\n\n Jul 2023\n\n File level constants for error message in require statements\n\n 3\n\n 379\n\n Jun 2023","tokens":732,"squid":"ink-security_audits","role":"Sentinel","at":1791260742352,"hash":"5c4a3ff5d7495b99cf73e39615d5701c872d0c27"}
{"url":"https://ethereum.org/developers/docs/design-and-ux/","domain":"ethereum.org","title":"Design and UX in web3 | ethereum.org","text":"Design and UX in web3Edit page (opens in a new tab)Are you new to designing with Ethereum? This is the right place for you. The Ethereum community has written resources to introduce you to web3 design and research basics. You'll learn about core concepts that may differ from other app designs you're familiar with.\nNeed a more basic understanding of web3 first? Check out Learn hub.\nStart with user research\nEffective design goes beyond creating visually appealing user interfaces. It involves gaining a deep understanding of the user's needs, objectives, and driving factors. Therefore, we highly recommend that all designers adopt a design process, such as the double diamond process (opens in a new tab), to ensure that their work is deliberate and intentional.\nIf you want to see what are currently the most pressing UX pain points, check out this map of current UX issues (opens in a new tab).\n\nWeb3 needs more UX Researchers and Designers (opens in a new tab) - An overview of current design maturity\nA simple guide to UX Research in web3 (opens in a new tab) - Simple guide how to do research\nHow to Approach UX Decisions in Web3 (opens in a new tab) - A brief overview of quantitative and qualitative research and the differences between the two (video, 6 min)\nBeing a ux researcher in web3 (opens in a new tab) - A personal view on what it is like being a UX researcher in web3\n\nResearch studies in web3\nThis is a curated list of user research done in web3 that may help with design and product decisions or work as an inspiration to conduct own study.\nArea of focusNameCrypto onboardingThe Reown Pulse 2024: Crypto Consumer Sentiment & Usage (opens in a new tab)Crypto onboardingCRADL: UX in Cryptocurrency (opens in a new tab)Crypto onboardingCRADL: Onboarding to Cryptocurrency (opens in a new tab)Crypto onboardingBitcoin UX report (opens in a new tab)Crypto onboardingConSensys: The State of Web3 perception around the world 2023 (opens in a new tab)Crypto onboardingNEAR: Accelerating the journey towards adoption (opens in a new tab)StakingOpenUX: Rocket Pool Node Operator UX (opens in a new tab)StakingStaking: Key trends, takeaways, and predictions - Eth Staker (opens in a new tab)StakingMulti App Staking (opens in a new tab)DAO2022 DAO Research Update: What do DAO Builders Need? (opens in a new tab)DeFiCoverage pools (opens in a new tab)DeFiConSensys: DeFi User Research Report 2022 (opens in a new tab)MetaverseMetaverse: User Research Report (opens in a new tab)MetaverseGoing on Safari: Researching Users in the Metaverse (opens in a new tab) (video, 27 min)\nDesign for web3\n\nWeb3 Design Playbook (opens in a new tab) - A comprehensive collection of frameworks and notes on Web3 UX principles, DeFi patterns, governance design, wallet UX, and protocol-level thinking for designers and founders\nWeb3 UX Design Handbook (opens in a new tab) - Practical guide to designing Web3 apps\nWeb3 Design Principles (opens in a new tab) - A framework of UX rules for blockchain based dapps\nBlockchain Design Principles (opens in a new tab) - Lessons learned by the blockchain design team at IBM\nNeueux.com (opens in a new tab) - UI library of user flows with diverse filtering options\nWeb3's Usability Crisis: What You NEED to Know! (opens in a new tab) - A panel discussion on pitfalls of developer focused project building (video, 34 min)\n\nGetting Started\n\nHeuristics for Web3 - 7 heuristics for Web3 interface design\nDEX Design Best Practices - A guide to designing Decentralized Exchanges\n\nWeb3 Design Case Studies\n\nDeep Work Studio (opens in a new tab)\nSelling an NFT on OpenSea (opens in a new tab)\nWallet UX teardown how wallets need to change (opens in a new tab) (video, 20 min)\n\nDesign Bounties\n\nDework (opens in a new tab)\nBuildbox hackathons (opens in a new tab)\nETHGlobal hackathons (opens in a new tab)\n\nDesign DAOs and communities\nGet involved in professional community-driven organizations or join design groups to discuss design and research related topics and trends with other members.\n\nVectordao.com (opens in a new tab)\nDeepwork.studio (opens in a new tab)\nWe3.co (opens in a new tab)\nOpenux.xyz (opens in a new tab)\n\nDesign Systems and other design resources\n\nOptimism Design (opens in a new tab) (Figma)\nEthereum.org Design system (opens in a new tab) (Figma)\nFinity, a design system by Polygon (opens in a new tab) (Figma)\nKleros Design System (opens in a new tab) (Figma)\nSafe Design System (opens in a new tab) (Figma)\nENS Design system (opens in a new tab)\nMirror Design System (opens in a new tab)\n\nArticles and projects listed on this page are not official endorsements, and are provided for informational purposes only.\nWe add links to this page based on criteria in our listing policy. If you'd like us to add a project/article, edit this page on GitHub (opens in a new tab).","tokens":1205,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260748172,"hash":"e50a68f20c7b85ad93896a4b60955758bef1b2c2"}
{"url":"https://forum.openzeppelin.com/t/should-burn-work-coming-from-the-liquidity-pool-of-pancakeswap-in-testnet/42528/3","domain":"forum.openzeppelin.com","title":"Should Burn work coming from the liquidity pool of Pancakeswap in Testnet? - Smart Contracts / Review Wanted - OpenZeppelin Forum","text":"Smart ContractsReview Wanted\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2024\n\n 3 / 3\n\n Dec 2024\n\n Dec 2024\n\n post by Lesho on Dec 9, 2024\n\n Lesho\n\n Hi, I'm new so please forgive this if it's a newbie question...\nI have deployed this code to BNB TestNet and the initial Burn works on creation. However, when I create a liquidity pool and I use other wallets to swap from Pancakeswap, I do not see any Burn taking place. Is there something wrong with the code? Do Buy and Sell Burns work differently? Am I just completely wrong?\nHere is the code:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract OneLoveBurn is ERC20, ERC20Burnable {\n uint256 private constant TOTAL_SUPPLY = 420420000000 * 10**18; // Including 18 decimals\n uint256 private constant INITIAL_BURN = 420000000 * 10**18; // Including 18 decimals\n uint256 private constant MAX_HOLD_LIMIT_PERCENTAGE = 420; // 4.20% expressed as 420 / 10000\n uint256 private constant BURN_PERCENTAGE = 420; // 4.20% expressed as 420 / 10000\n uint256 private constant MINIMUM_CIRCULATING_SUPPLY = 420000000 * 10**18; // Minimum circulating supply\n\n address public constant BURN_ADDRESS = 0x000000000000000000000000000000000000dEaD;\n address public owner;\n mapping(address => bool) public liquidityPools;\n\n constructor() ERC20(\"41Love Burn - The best burn ever\", \"41LoveBURN\") {\n owner = msg.sender;\n\n // Mint the total supply to the owner\n _mint(owner, TOTAL_SUPPLY);\n\n // Perform the initial burn\n _transfer(owner, BURN_ADDRESS, INITIAL_BURN);\n }\n\n modifier onlyOwner() {\n require(msg.sender == owner, \"Caller is not the owner\");\n _;\n }\n\n function setLiquidityPool(address pool, bool isPool) external onlyOwner {\n liquidityPools[pool] = isPool;\n }\n\n function transfer(address recipient, uint256 amount) public override returns (bool) {\n _validateMaxHoldLimit(msg.sender, recipient, amount);\n return super.transfer(recipient, amount);\n }\n\n function transferFrom(\n address sender,\n address recipient,\n uint256 amount\n ) public override returns (bool) {\n if (_isBuyOrSell(sender, recipient)) {\n uint256 burnAmount = _calculateBurnAmount(amount);\n if (burnAmount > 0) {\n _transfer(sender, BURN_ADDRESS, burnAmount);\n amount -= burnAmount;\n }\n }\n _validateMaxHoldLimit(sender, recipient, amount);\n return super.transferFrom(sender, recipient, amount);\n }\n\n function _calculateBurnAmount(uint256 amount) internal view returns (uint256) {\n uint256 circulatingSupply = totalSupply() - balanceOf(BURN_ADDRESS);\n if (circulatingSupply <= MINIMUM_CIRCULATING_SUPPLY) {\n return 0; // Stop burning if circulating supply has reached the minimum\n }\n\n uint256 burnAmount = (amount * BURN_PERCENTAGE) / 10000;\n\n // Ensure burn doesn't reduce circulating supply below the minimum\n if (circulatingSupply - burnAmount < MINIMUM_CIRCULATING_SUPPLY) {\n burnAmount = circulatingSupply - MINIMUM_CIRCULATING_SUPPLY;\n }\n\n return burnAmount;\n }\n\n function _isBuyOrSell(address sender, address recipient) internal view returns (bool) {\n return liquidityPools[sender] || liquidityPools[recipient];\n }\n\n function _validateMaxHoldLimit(\n address,\n address recipient,\n uint256 amount\n ) internal view {\n uint256 maxLimit = (totalSupply() * MAX_HOLD_LIMIT_PERCENTAGE) / 10000;\n require(amount <= maxLimit, \"Transfer exceeds the maximum allowed percentage of total supply\");\n\n // Ensure recipient does not exceed the limit after receiving tokens\n uint256 recipientBalance = balanceOf(recipient) + amount;\n require(recipientBalance <= maxLimit, \"Recipient balance exceeds the maximum allowed percentage\");\n }\n\n function burn(uint256 amount) public override {\n uint256 circulatingSupply = totalSupply() - balanceOf(BURN_ADDRESS);\n require(circulatingSupply - amount >= MINIMUM_CIRCULATING_SUPPLY, \"Cannot burn below the minimum circulating supply\");\n _transfer(msg.sender, BURN_ADDRESS, amount);\n }\n\n function burnFrom(address account, uint256 amount) public override {\n uint256 circulatingSupply = totalSupply() - balanceOf(BURN_ADDRESS);\n require(circulatingSupply - amount >= MINIMUM_CIRCULATING_SUPPLY, \"Cannot burn below the minimum circulating supply\");\n uint256 currentAllowance = allowance(account, msg.sender);\n require(currentAllowance >= amount, \"ERC20: burn amount exceeds allowance\");\n _approve(account, msg.sender, currentAllowance - amount);\n _transfer(account, BURN_ADDRESS, amount);\n }\n}\n\n 2\n\n post by Skyge on Dec 9, 2024\n\n Skyge\n\n Hi, welcome to the community! \n\nI am not sure what you mean Burn does not take place, the balance of the Dead Address increases, so I think the Burn does take place, just totalSupply does not change.\n\n post by Lesho on Dec 9, 2024\n\n Lesho\n\n Thank you for the welcome!\nNo problem let me clarify.\n\nI run that code in TestNet. = Success\nThen I go to Pancakeswap and add liquidity for the contract in Testnet = Success\nI then swap via Pancakeswap 5,000,000 = Success\nTransaction finishes = Success\nI look in the wallet and it has 5,000,000 coins = Failure (in my mind)\n\nif 4.2% was going to be burned, than 210,000 coin should have gone to the dead wallet. and 4,790,000 should be in the wallet that bought. Is that correct?\nPlease let me know if I'm incorrect here, that should be what is happening with the code? Or do I not understand how the Liquidity pool works?\nPerhaps I'm confused about what triggers need to happen inorder for the burn to happen?\nI am a newbie so I would really appreciate any insight.\nThank you again!!!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Adding Liquidity pool to pancakeswap\n\n Support\n\n 0\n\n 310\n\n May 2021\n\n Serious issue trying to add initial liquidity to a bep20 token on Pancakeswap\n\n Support\n\n 3\n\n 2.9k\n\n Jun 2021\n\n Unable to create liquidity pool\n\n Contracts\n\n erc20,bep20\n\n 3\n\n 1.1k\n\n Jul 2021\n\n Unable to remove liquidity from pancakeswap\n\n Smart Contracts\n\n 0\n\n 665\n\n Mar 2022\n\n Pancakeswap V2 Liquidity in V1 Contract\n\n Support\n\n 2\n\n 644\n\n Jun 2021","tokens":1524,"squid":"ink-security_audits","role":"Sentinel","at":1791260752438,"hash":"b6f27b7d17fcf9d051d47eccf5989ca569441c5b"}
{"url":"https://dev-forum.pyth.network/t/welcome-to-the-announcements-category/12/2","domain":"dev-forum.pyth.network","title":"Welcome to the Announcements category - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 2 / 2\n\n Mar 2025\n\n Mar 2025\n\n post by Aditya520 on Mar 27, 2025\n\n Aditya520\n\n Official updates related to Pyth, Pyth products and more!\nHere you’ll find:\n\n Network and protocol updates\n\n Product releases and feature announcements\n\n Developer tool upgrades and ecosystem integrations\n\nOnly Pyth team members can post here, but all community members are encouraged to follow this category to stay in the loop.\nWant to stay in the loop? Hit that at the right and set it to “Watching.”\n\n Closed on Mar 31, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to Pyth Developer Forum! \n\n General\n\n 0\n\n 578\n\n Mar 2025\n\n About the Forum Feedback category\n\n Forum Feedback\n\n 0\n\n 450\n\n Apr 2025\n\n Upcoming Changes to Pyth Sponsored Feeds – Effective August 31, 2025\n\n Announcements\n\n announcements,sponsored-feeds\n\n 2\n\n 644\n\n Sep 2025\n\n About the Incidents category\n\n Incidents\n\n 0\n\n 439\n\n May 2025\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n Powered by Discourse","tokens":1162,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260754846,"hash":"4906f9be4883d5d2595ccf6f6c9540df2ca756e6"}
{"url":"https://io.net/docs/guides/block-rewards/proposed-device-block-reward-multiplier","domain":"io.net","title":"Device Block Reward Multiplier - io.net","text":"The io.net block reward system uses performance-based multipliers to fairly distribute rewards across a wide variety of hardware types. These multipliers are designed to reflect the relative utility, compute performance, and cost-efficiency of each device, ensuring the most effective hardware for AI workloads is appropriately incentivized.\n​Network Expansion and Updated Reward Structure\nOn June 4, 2025 at 3 PM UTC, io.net significantly expanded its network with the addition of over 800 NVIDIA H200 GPUs. This is the largest single onboarding of enterprise-grade hardware in our history and is part of our commitment to scaling infrastructure for enterprise AI workloads like training and inference.\nTo ensure fair distribution of rewards as the network grows, the block reward system has been updated to reflect the following changes:\n\nUpdated device multipliers\nNew reward pool categories\nTemporary staking grace period\n\n​Reward Pool Categories\nPool TypeDescription🔴 No longer supportedLow-tier or outdated devices. Multiplier set to 0. No longer earn rewards.🟡 Community PoolConsumer and mid-range devices. Earn 5% of block rewards.🟢 Enterprise PoolHigh-performance processors. Earn 95% of block rewards.\n​Device Earning Multiplier Comparison\n​🔴 No longer supported\nProcessorCurrent MultiplierNew MultiplierNotesM2 Max10Already droppedM2 Pro0.750Already droppedM2 Ultra1.250Already droppedA100.750Dropped due to lack of demand and supplyA10G0.750Dropped due to lack of demand and supplyA1610Dropped due to lack of demand and supplyA4020Dropped due to lack of demand and supplyGeForce GTX 1080 Ti0.250Dropped due to lack of demandGeForce GTX 2080 Ti0.250Dropped due to lack of demandGeForce GTX 30500.250Dropped due to lack of demandGeForce GTX 3050 Ti0.250Dropped due to lack of demand\n​🟡 Community Pool\nProcessorCurrent MultiplierNew MultiplierNotesM30.51TFLOP-based adjustment with bonus for unified memoryM3 Pro0.751.25TFLOP-based adjustment with bonus for unified memoryM3 Max11.5TFLOP-based adjustment with bonus for unified memoryM40.51TFLOP-based adjustment with bonus for unified memoryM4 Pro0.751.25TFLOP-based adjustment with bonus for unified memoryM4 Max11.5TFLOP-based adjustment with bonus for unified memoryGeForce RTX 30600.250.75TFLOP-based adjustmentGeForce RTX 3060 Ti0.250.75TFLOP-based adjustmentGeForce RTX 30700.251TFLOP-based adjustmentGeForce RTX 3070 Ti0.251TFLOP-based adjustmentGeForce RTX 30800.251.5TFLOP-based adjustmentGeForce RTX 3080 Ti0.251.75TFLOP-based adjustmentGeForce RTX 30900.51.75TFLOP-based adjustmentGeForce RTX 3090 Ti0.52TFLOP-based adjustmentGeForce RTX 40600.251TFLOP-based adjustmentGeForce RTX 4060 Ti0.251TFLOP-based adjustmentGeForce RTX 40700.251.5TFLOP-based adjustmentGeForce RTX 4070 Ti0.252.5TFLOP-based adjustmentGeForce RTX 40800.52.75TFLOP-based adjustmentL40.750.25TFLOP-based adjustmentRTX 40000.40.75TFLOP-based adjustmentRTX 4000 SFF Ada Generation0.51TFLOP-based adjustmentRTX 50000.251.5TFLOP-based adjustmentRTX 5000 Ada Generation1.53TFLOP-based adjustmentRTX 6000 Ada Generation2.54.5TFLOP-based adjustmentRTX A40000.41.5TFLOP-based adjustmentRTX A50000.751.5TFLOP-based adjustmentRTX A60001.52TFLOP-based adjustmentTesla T40.40.5TFLOP-based adjustmentTesla V100-PCIE-16GB0.50.75TFLOP-based adjustmentTesla V100-PCIE-32GB0.750.75TFLOP-based adjustmentTesla V100-SXM2-16GB0.50.75TFLOP-based adjustmentTesla V100-SXM2-32GB0.750.75TFLOP-based adjustmentTesla V100S-PCIE-32GB0.750.75TFLOP-based adjustment\n​🟢 Enterprise Pool\nProcessorCurrent MultiplierNew MultiplierNotesL40S2.253High-demand based adjustmentA100 80GB PCIe55No changeA100-PCIE-40GB22No changeA100-SXM4-80GB55No changeGeForce RTX 40900.751.25High-demand based adjustmentGeForce RTX 4090 D0.751.25High-demand based adjustmentH100 80GB HBM31010No changeH100 PCIe1010No changeH100 80G PCIe1010No changeB2003030No changeH2001512High-demand based adjustment\n​Overview of Staking Requirements\nImportant changes to Staking Requirements coming July 1, 2025Until July 1, 2025, staking requirements will continue to be calculated using the current earning multiplier.\nTo qualify for block rewards, each device must meet a minimum staking threshold calculated as follows:\n\nBase Stake per processor: 200 $IO\nEarning Multiplier: Varies by device performance\nNumber of processors: Total processors in the device\n\nMinimum Stake = Base Stake × max(1, Earning Multiplier) × Number of processors\nStarting July 1, 2025, staking requirements may increase for some devices, as a new calculation logic will take effect.\nFor example:\n\nA device with 8 H100 GPUs, each having an earning multiplier of 10 - Minimum Stake calculation: 200 × 10 × 8 = 16,000 $IO\nA device with 4 RTX 4070 GPUs, each having an earning multiplier of 0.25 - Minimum Stake calculation: 200 × max(1, 0.5) × 4 = 200 × 1 × 4 = 800 $IO\n\nEven if the earning multiplier is less than 1, the multiplier used in the calculation defaults to 1 to ensure a minimum stake of 200 $IO per processor.\n​Upcoming Adjustments\nWith the integration of new H200 GPUs and the introduction of a Community Hardware Pool, the following changes are anticipated:\n\nUpdated Multipliers: Devices will have their earning multipliers recalibrated based on performance metrics.\nAdjusted Staking Requirements: As multipliers change, the corresponding staking requirements will also adjust.\nGrace Period: A one-month grace period will be provided before new staking requirements are enforced.\n\nHigher multiplier ≠ always higher rewards. \nActual rewards depend on several factors - including the number of eligible devices in a block, pool allocation (e.g., Community vs. Enterprise), and your device’s multiplier.\nFor more detailed information on staking requirements and calculations, refer to the IO Staking Documentation.Was this page helpful?","tokens":1451,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260762924,"hash":"f69f942be965799a1d1ddfe658eeb4c208511d64"}
{"url":"https://dev-forum.pyth.network/t/about-the-incidents-category/172/1","domain":"dev-forum.pyth.network","title":"About the Incidents category - Announcements / Incidents - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n About the Incidents category \n\n AnnouncementsIncidents\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Aditya520 on May 22, 2025\n\n Aditya520\n\n ncidents\nThis category is for official updates from the admin team about technical incidents, outages, and service disruptions affecting our platform. Only admins can post here—everyone else can view and stay informed.\nGuidelines:\n\nPurpose: To provide timely, transparent updates about ongoing or resolved incidents directly from the admin team.\nHow is this different? Unlike other support or discussion categories, only admins can create topics here. It’s focused solely on platform-wide incidents or outages.\nWhat’s included? Each post should cover the nature of the incident, impacted systems, timestamps, progress updates, and final resolution notes.\nWhy keep this category? It helps the community quickly find accurate information during disruptions—all in one place, straight from the source.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to the Announcements category\n\n Announcements\n\n 0\n\n 500\n\n Mar 2025\n\n About the General category\n\n General\n\n 0\n\n 454\n\n Mar 2025\n\n About the Forum Feedback category\n\n Forum Feedback\n\n 0\n\n 450\n\n Apr 2025\n\n Welcome to Pyth Developer Forum! \n\n General\n\n 0\n\n 578\n\n Mar 2025\n\n About the Express Relay category\n\n Express Relay\n\n 0\n\n 446\n\n Jul 2025\n\n Powered by Discourse","tokens":1239,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260766567,"hash":"f213eb6196cec6a5d668c97b29d63615be8d00d3"}
{"url":"https://forum.openzeppelin.com/t/serious-issue-trying-to-add-initial-liquidity-to-a-bep20-token-on-pancakeswap/9955/1","domain":"forum.openzeppelin.com","title":"Serious issue trying to add initial liquidity to a bep20 token on Pancakeswap - Support - OpenZeppelin Forum","text":"Serious issue trying to add initial liquidity to a bep20 token on Pancakeswap \n\n Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Jun 2021\n\n 1 / 4\n\n Jun 2021\n\n Jun 2021\n\n post by CodingIdiot on Jun 5, 2021\n\n CodingIdiot\n\n I have created an deployed my token, it worked exactly as intended and I’ve set everything up to launch the darn thing. The project doesn’t really do much, it’s intended only to be a true deflationary currency. I’m just tired of all the scams and BS in the coins these days so I wanted to create a tradable asset that’s ironic and gives a people a serious chance who missed the all the come ups from other coins.\nThat all being said. I’ve run into an issue, I created a coin with autoburn so once it’s launched and on the market I can forget about it and just trade my share of coins away over the years. I think that auto burn might be causing an issue with pancakeswap and I cannot get help anywhere so far on how to fix this.\nI approved the right for the router to use the wallets supply on metamask, and after that I attempted to create the initial supply.\nThis is where the problem arises, I click add supply, it pops up the normal window that says “you are creating a pool”, after that I click “create pool & supply” from there it should send a confirmation approval to metamask, however it fails this instantly every single time and reverts immediately back to the “you are creating a pool” prompt.\nSo far I have tried the following fixes:\n• Verified on BSCScan.com\n• Tried trust wallet, and tried on two other metamasks.\n• I have tried VPNs\n• I have tried from mobile\n• I have tried on brave, firefox, and chrome\n• I have changed slippage anywhere from 1% to 49%\n• I have waited 5 days just incase it was a pancakeswap issue\n• I have tried every variable possible of initial price\nI’m at a loss for why it isn’t working.\nAnyway, here’s my code, the link to the contract on BSCScan, and the transaction for approval to spend the coin from pancake swap to their router.\ncontract on BSCScan\nTransaction for approval\npragma solidity ^0.8.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol\";\n\ncontract ScamCoin is ERC20 {\n\n//suposed to act as a stopping point for minimum total supply\nuint256 private _minimumSupply = 10000000 * (10 ** 18);\n\n/**\n * @dev Constructor that gives msg.sender all of existing tokens.\n */\nconstructor () public ERC20(\"ScamCoin\", \"SCAM\") {\n _mint(msg.sender, 500000000000000 * (10 ** uint256(decimals())));\n}\n\nfunction transfer(address to, uint256 amount) public override returns (bool) {\n return super.transfer(to, _partialBurn(amount));\n}\n\nfunction transferFrom(address from, address to, uint256 amount) public override returns (bool) {\n return super.transferFrom(from, to, _partialBurn(amount));\n}\n\nfunction _partialBurn(uint256 amount) internal returns (uint256) {\n uint256 burnAmount = _calculateBurnAmount(amount);\n\n if (burnAmount > 0) {\n _burn(msg.sender, burnAmount);\n }\n\n return amount -(burnAmount);\n}\n\nfunction _calculateBurnAmount(uint256 amount) internal view returns (uint256) {\n uint256 burnAmount = 0;\n\n //supposed to calculate the burn amount?\n if (totalSupply() > _minimumSupply) {\n burnAmount = amount / 10;\n uint256 availableBurn = totalSupply() -(_minimumSupply);\n if (burnAmount > availableBurn) {\n burnAmount = availableBurn;\n }\n }\n\n return burnAmount;\n}\n\n}\n\n 2\n\n post by Yoshiko on Jun 6, 2021\n\n Yoshiko\n\nThe first step would be to comment this out in your code and see if it works. The solution is probably to exclude the burn when providing liquidity.\nNarrow down what's broken. You can test on https://pancake.kiemtienonline360.com/#/swap using router address 0x9Ac64Cc6e4415144C455BD8E4837Fea55603e5c3\n\n 16 days later\n\n post by Mikeghaha on Jun 22, 2021\n\n Mikeghaha\n\n I’m having this same issue… did you ever find a resolution? I’ve tried everything you mentioned… I’ve been searching everywhere for 2 days for an answer.\n\n post by CodingIdiot on Jun 22, 2021\n\n CodingIdiot\n\n Yoshiko\n\n Being that the contract is already up and running I’ll have to create a new contract with that change correct?\nTbh, I I’m fairly new to solidity so I don’t even know what variable I would add to keep it from burning on liquidity transactions.\nHere’s a whole thread on the issue and what I’ve tried so far. Figured it might help ya.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t add liquidity to my token through BSCScan/Etherscan, need some help making sure the contract itself isn’t the issue\n\n Support\n\n 9\n\n 2.8k\n\n Jun 2021\n\n Adding Liquidity pool to pancakeswap\n\n Support\n\n 0\n\n 311\n\n May 2021\n\n Unable to create liquidity pool\n\n Contracts\n\n erc20,bep20\n\n 3\n\n 1.1k\n\n Jul 2021\n\n Can’t interact with token / buy, sell or remove liquidity on Pancakeswap\n\n Support\n\n 6\n\n 5.5k\n\n Jul 2021\n\n Unable to add liquidity to pancakeswap\n\n Support\n\n 1\n\n 1.5k\n\n Apr 2021","tokens":1273,"squid":"ink-security_audits","role":"Sentinel","at":1791260772555,"hash":"d539a3af39b1616a23b75cdeedcfb9bf43382b7a"}
{"url":"https://io.net/docs/guides/staking/device-owner-staking","domain":"io.net","title":"Overview - io.net","text":"Staking $IO tokens is a key step in participating in the IO.net decentralized ecosystem. It helps secure the network, validate computational tasks, and earn rewards. Whether you’re staking on your own or teaming up with others through co-staking, this guide will walk you through everything —from connecting your wallet to managing your stakes and maximizing your rewards.\n​Table of Contents\n\nSolo Staked Devices\nProtecting your Stake\nCreate a Co-staking Offer\nDeleting, Unstaking & Withdrawing\nFAQs\n\n​FAQs\n​General Co-Staking Questions\nQ: Can a person co-stake on multiple devices?Yes.Q: Is there a limitation?As the device owner, you can not co-stake with your own devices.Q: What is the maximum number of co-staking offers I can claim?To ensure that more users can benefit from co-staking offers, we have set a claim cap of up to two offers per IO account.\n​Identity & Anonymity\nQ: Are there any identifiable details of a co-staker or device owner?No, the marketplace deliberately anonymizes this information for privacy. However, wallet details remain public on the blockchain.Q: What if a co-staker and device owner want to adjust contributions?If the co-staking offer is still not being taken up, the device owner can simply cancel the offer and create a new one. Otherwise, they must unstake and wait for the cooldown period to pass before creating a new one.\n​Staking Structure & Financial Impact\nQ: Can multiple co-stakers contribute to a single offer?No. Only one co-staker is allowed per offer.Q: If a primary worker is suspected of fraud or gets slashed, what happens financially to the co-staker?If BR (Block Rewards) are slashed, co-stakers are also impacted.Q: What happens to the co-staked \\$IO when the device owner terminates the device?The device will immediately stop earning Block Rewards for both the supplier and co-staker as the device no longer meets the requirement for earning Block Rewards. Staked $IO will not be automatically unstaked and will need to be manually unstaked and go through the applicable Wait Period and/or Cooldown period.Was this page helpful?","tokens":523,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260772922,"hash":"7d036fafcde9c91b3eeff5c9ee336b83c80e5b3c"}
{"url":"https://dev-forum.pyth.network/t/about-the-general-category/3/1","domain":"dev-forum.pyth.network","title":"About the General category - General - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n About the General category \n\n General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by system on Mar 26, 2025\n\n system\n\n Topics that don’t need a category, or don’t fit into any other existing category.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Incidents category\n\n Incidents\n\n 0\n\n 440\n\n May 2025\n\n About the Grants category\n\n Grants\n\n 0\n\n 298\n\n Oct 2025\n\n About the Forum Feedback category\n\n Forum Feedback\n\n 0\n\n 450\n\n Apr 2025\n\n Added a new feature in docs for AI\n\n Announcements\n\n announcements\n\n 0\n\n 79\n\n Feb 6\n\n Welcome to the Announcements category\n\n Announcements\n\n 0\n\n 500\n\n Mar 2025\n\n Powered by Discourse","tokens":1056,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260780687,"hash":"84fc3e5d5bae8aa8294d8d06fbcc5071a5068cbd"}
{"url":"https://forum.openzeppelin.com/t/serious-issue-trying-to-add-initial-liquidity-to-a-bep20-token-on-pancakeswap/9955/4","domain":"forum.openzeppelin.com","title":"Serious issue trying to add initial liquidity to a bep20 token on Pancakeswap - Support - OpenZeppelin Forum","text":"Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Jun 2021\n\n 4 / 4\n\n Jun 2021\n\n Jun 2021\n\n post by CodingIdiot on Jun 5, 2021\n\n CodingIdiot\n\n I have created an deployed my token, it worked exactly as intended and I’ve set everything up to launch the darn thing. The project doesn’t really do much, it’s intended only to be a true deflationary currency. I’m just tired of all the scams and BS in the coins these days so I wanted to create a tradable asset that’s ironic and gives a people a serious chance who missed the all the come ups from other coins.\nThat all being said. I’ve run into an issue, I created a coin with autoburn so once it’s launched and on the market I can forget about it and just trade my share of coins away over the years. I think that auto burn might be causing an issue with pancakeswap and I cannot get help anywhere so far on how to fix this.\nI approved the right for the router to use the wallets supply on metamask, and after that I attempted to create the initial supply.\nThis is where the problem arises, I click add supply, it pops up the normal window that says “you are creating a pool”, after that I click “create pool & supply” from there it should send a confirmation approval to metamask, however it fails this instantly every single time and reverts immediately back to the “you are creating a pool” prompt.\nSo far I have tried the following fixes:\n• Verified on BSCScan.com\n• Tried trust wallet, and tried on two other metamasks.\n• I have tried VPNs\n• I have tried from mobile\n• I have tried on brave, firefox, and chrome\n• I have changed slippage anywhere from 1% to 49%\n• I have waited 5 days just incase it was a pancakeswap issue\n• I have tried every variable possible of initial price\nI’m at a loss for why it isn’t working.\nAnyway, here’s my code, the link to the contract on BSCScan, and the transaction for approval to spend the coin from pancake swap to their router.\ncontract on BSCScan\nTransaction for approval\npragma solidity ^0.8.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol\";\n\ncontract ScamCoin is ERC20 {\n\n//suposed to act as a stopping point for minimum total supply\nuint256 private _minimumSupply = 10000000 * (10 ** 18);\n\n/**\n * @dev Constructor that gives msg.sender all of existing tokens.\n */\nconstructor () public ERC20(\"ScamCoin\", \"SCAM\") {\n _mint(msg.sender, 500000000000000 * (10 ** uint256(decimals())));\n}\n\nfunction transfer(address to, uint256 amount) public override returns (bool) {\n return super.transfer(to, _partialBurn(amount));\n}\n\nfunction transferFrom(address from, address to, uint256 amount) public override returns (bool) {\n return super.transferFrom(from, to, _partialBurn(amount));\n}\n\nfunction _partialBurn(uint256 amount) internal returns (uint256) {\n uint256 burnAmount = _calculateBurnAmount(amount);\n\n if (burnAmount > 0) {\n _burn(msg.sender, burnAmount);\n }\n\n return amount -(burnAmount);\n}\n\nfunction _calculateBurnAmount(uint256 amount) internal view returns (uint256) {\n uint256 burnAmount = 0;\n\n //supposed to calculate the burn amount?\n if (totalSupply() > _minimumSupply) {\n burnAmount = amount / 10;\n uint256 availableBurn = totalSupply() -(_minimumSupply);\n if (burnAmount > availableBurn) {\n burnAmount = availableBurn;\n }\n }\n\n return burnAmount;\n}\n\n}\n\n 2\n\n post by Yoshiko on Jun 6, 2021\n\n Yoshiko\n\nThe first step would be to comment this out in your code and see if it works. The solution is probably to exclude the burn when providing liquidity.\nNarrow down what's broken. You can test on https://pancake.kiemtienonline360.com/#/swap using router address 0x9Ac64Cc6e4415144C455BD8E4837Fea55603e5c3\n\n 16 days later\n\n post by Mikeghaha on Jun 22, 2021\n\n Mikeghaha\n\n I’m having this same issue… did you ever find a resolution? I’ve tried everything you mentioned… I’ve been searching everywhere for 2 days for an answer.\n\n post by CodingIdiot on Jun 22, 2021\n\n CodingIdiot\n\n Yoshiko\n\n Being that the contract is already up and running I’ll have to create a new contract with that change correct?\nTbh, I I’m fairly new to solidity so I don’t even know what variable I would add to keep it from burning on liquidity transactions.\nHere’s a whole thread on the issue and what I’ve tried so far. Figured it might help ya.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t add liquidity to my token through BSCScan/Etherscan, need some help making sure the contract itself isn’t the issue\n\n Support\n\n 9\n\n 2.8k\n\n Jun 2021\n\n Adding Liquidity pool to pancakeswap\n\n Support\n\n 0\n\n 311\n\n May 2021\n\n Unable to create liquidity pool\n\n Contracts\n\n erc20,bep20\n\n 3\n\n 1.1k\n\n Jul 2021\n\n Can’t interact with token / buy, sell or remove liquidity on Pancakeswap\n\n Support\n\n 6\n\n 5.5k\n\n Jul 2021\n\n Unable to add liquidity to pancakeswap\n\n Support\n\n 1\n\n 1.5k\n\n Apr 2021","tokens":1253,"squid":"ink-security_audits","role":"Sentinel","at":1791260783774,"hash":"fd357d96bd81f3b2d1a03d4d3478047499287afd"}
{"url":"https://io.net/docs/guides/staking/unstaking-deleting-withdrawing","domain":"io.net","title":"Deleting, Unstaking & Withdrawing - io.net","text":"​Table of Contents\n\nDeleting a Co-Staking Offer\nUnstaking\nWithdrawing Overflow\n\n​Deleting a Co-Staking Offer\n\nIf you unstake part of your contribution while co-staked, you are not subject to a cooldown period.\nIf a co-staker cancels their stake, you have 7 days to cover the remaining portion or create a new co-staking offer.\nDuring this 7-day period, your device continues fulfilling staking requirements for block reward eligibility.\n\nYour device must still meet all other criteria.\nSteps to Delete a Co-Staking Offer:\n\nGo to the Manage Your Stake & Devices block, where all your staking devices are listed, and click the three dots next to the desired device.\n\nSelect Delete a Co-Staking Offer from the dropdown list.\n\nIn the pop-up, confirm by clicking the Retract My Co-Staking Offer button to complete the process.\n\nIf you unstake first:\n\nIf your stake remains above the minimum requirement, there is no impact.\nIf your stake falls below the requirement, the system automatically unstakes for the co-staker. In this case, all funds enter the 14-day cooldown period.\n\n​Unstaking\nYou can cancel a stake at any time.\n\nUnstaking takes 14 days.\nYou must unstake the entire amount, which stops counting toward the Minimum Required Stake immediately.\nYou cannot restake until the process is complete.\nUnstaking is not available for devices in hired status.\n\nHow to Unstake Your Device:\n\nGo to the Manage Your Stake & Devices block, where all your staking devices are listed, and click the three dots next to the desired device.\n\nSelect Unstake from the dropdown list.\n\nIn the pop-up, confirm by clicking the Unstake button to complete the process.\n\nIf an unfilled co-staking offer exists for the selected device, retract your offer before unstaking.\n\n​Withdrawing Overflow\nOverflow refers to funds exceeding your initial stake that can be withdrawn separately, while your original stake remains locked until the unstaking process is complete.\nHow to Withdraw Overflow:\n\nGo to the Manage Your Stake & Devices section and select the Co-Staked Devices tab.\n\nFind your device, click the ellipsis, and select Withdraw Overflow from the dropdown menu.\n\nTo confirm, click Withdraw Overflow. You can only withdraw overflow funds, not the main staked amount.\n\nYou can only withdraw overflow funds, not the main staked amount.Was this page helpful?","tokens":585,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260786696,"hash":"54666e09700d52c44ef1aff7459591c73a2f9953"}
{"url":"https://dev-forum.pyth.network/t/about-the-grants-category/441/1","domain":"dev-forum.pyth.network","title":"About the Grants category - Grants - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n About the Grants category \n\n Grants\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by nidhi on Oct 14, 2025\n\n nidhi\n\n Welcome to the Grants category!\nThis category is dedicated to discussions, questions, and support related to the Pyth Ecosystem Grants Program.\nKey topics might include:\n\nGrant application processes and eligibility\n\nIdeas for community-led development, education, or research projects\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to the Announcements category\n\n Announcements\n\n 0\n\n 500\n\n Mar 2025\n\n Pyth Community Hackathon Official Rules\n\n Pyth Community Hackathon\n\n 0\n\n 565\n\n Mar 2\n\n Terms & Conditions\n\n Pyth Community Hackathon\n\n 0\n\n 227\n\n Mar 5\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n About the Pyth Entropy category\n\n Entropy\n\n 0\n\n 482\n\n Apr 2025\n\n Powered by Discourse","tokens":1107,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260790986,"hash":"787248aae66474997215d6aa5c6b99f1810973ff"}
{"url":"https://forum.openzeppelin.com/t/cant-interact-with-token-buy-sell-or-remove-liquidity-on-pancakeswap/5982","domain":"forum.openzeppelin.com","title":"Can't interact with token / buy, sell or remove liquidity on Pancakeswap - Support - OpenZeppelin Forum","text":"Can’t interact with token / buy, sell or remove liquidity on Pancakeswap \n\n Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2021\n\n 1 / 7\n\n Feb 2021\n\n Jul 2021\n\n post by jing on Feb 25, 2021\n\n jing\n\n using pancakeswap forked a BEP20 token and traded it with some friends for a few days then all the sudden it stopped letting us interact with it.\nToken = 0xb64B6a804c07699535641c89B03BDe89cFc5A3CD\nLP token = 0x878C5832A08BEb7A7A557978E49C5aaBC87d19e5\npancakeswap.finance\n\n post by abcoathup on Feb 25, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @jing,\nI am sorry I can’t help you with this. You may want to try a pancakeswap or a Binance community for help.\n\n 2 months later\n\n post by iulianh on Apr 29, 2021\n\n iulianh\n\n same problem here. It’s very hard to get support. They only want fees and no help.\n\n 8 days later\n\n post by defitokens on May 7, 2021\n\n defitokens\n\n I have the same problem !!\nI added tokens + liquidity, but I can’t buy it and I don’t know why\nI tried to remove the liquidity but the CONFIRM button does not work.\nLiquidity came in, but it doesn’t come out.\nI do not know the reason.\nAs the friend said, they only want fees but they don’t support it. Telegram groups have no ADM, only scam.\nThere is no support from them. Totally inaccessible.\n\n post by Royaa on May 15, 2021\n\n Royaa\n\n I am also facing same issue have you found a way to resolved, I have read some where you can try to remove on trust wallet but in my case problem is i have create on metamask account 2. its mean i have can only import this account in trustwallet with private key with ethereum network. i don’t know how to convert wallet network in BSC in trustwallet. \n\n post by aidy515 on May 20, 2021\n\n aidy515\n\n on the write contract page go to setswapliquidty write FALSE then click right , confirm in wallet and you’ll be able to withdraw all liquidity\n\n 2 months later\n\n post by 11123 on Jul 11, 2021\n\n 11123\n\n I will be able to withdraw liquidity\nEmail me on Telegram: @ Aleksandr9817\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 252\n\n Apr 2024\n\n Can not remove liquidity from my token on pancakeswap/ even simple transfer from wallet to wallet is not possible. \n\n Smart Contracts\n\n 0\n\n 153\n\n May 2024\n\n Not able to remove liquidity from Pancakeswap\n\n Contracts\n\n 1\n\n 633\n\n Aug 2021\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 882\n\n Jun 2022\n\n This transaction would fail pancakeswap Error\n\n Smart Contracts\n\n 0\n\n 1.0k\n\n May 2025","tokens":660,"squid":"ink-security_audits","role":"Sentinel","at":1791260794143,"hash":"61e911e162004e7466d49b3ab162f7585cac62e1"}
{"url":"https://io.net/docs/guides/staking/solo-staked-devices","domain":"io.net","title":"Solo Staked Devices - io.net","text":"​Staking Tab\nTo view the Staking tab, go to io.net > IO Worker > Staking. The Staking tab displays:\n\nTotal Wallet Balance: Available balance in $IO.\nTotal Active Stake: Amount actively staked.\nTotal in Cooldown: Funds in the unstaking process.\nRewards from the Latest Block: Your latest block rewards in $IO.\n\n​How to Stake\n​Connect Your Crypto Wallet\nTo stake on IO, you need to connect your crypto wallet.\n\nGo to io.net > IO Worker > Staking tab.\nFollow the steps in Rewards and Wallets to connect your wallet.\n\nStaking above the minimum required stake does not increase block rewards.\n​Stake $IO\nOnce you’ve connected your wallet, you can stake $IO to your device. After you connect your device to our network, you must stake to the device.\nTo view your devices that have no stake or only a stake from the device owner, click the Solo Staked Devices tab. The screenshot below shows a list of devices, indicating whether they have no stake, or just the owner’s stake.\n\nBefore making a co-staking offer, a full stake must be created for your device.\n​Stake your tokens\n\nLocate your device and click Stake in the Staking Actions column.\n\nIn the pop-up window, enter the required $IO amount to stake your device, then click Stake. Any subsequent solo staking attempts on the same worker must use the wallet that was initially used for the device’s stake.\n\n​14-Day Cooldown Period\nThe 14-day cooldown period is important when unstaking your funds. Here’s how it works:\n\nYou can unstake at any time, but there is a 14-day cooldown period before the funds can be fully withdrawn.\nFunds in cooldown are not counted toward staking requirements.\nDuring the cooldown, your funds remain locked and cannot be withdrawn until the process is complete.\n\nDuring the cooldown period, your funds do not contribute to staking rewards. You will only be able to access your funds after the 14-day period ends.Was this page helpful?","tokens":478,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260796559,"hash":"8c7a2c5b5ff9e4093e28d72e4ec4fa5bf88a41b7"}
{"url":"https://vitalik.eth.limo/general/2022/06/15/using_snarks.html","domain":"vitalik.eth.limo","title":"Some ways to use ZK-SNARKs for privacy","text":"Dark Mode Toggle\n\n Some ways to use ZK-SNARKs for privacy \n 2022 Jun 15 \nSee all posts\n\n Some ways to use ZK-SNARKs for privacy \n\nSpecial thanks to Barry Whitehat and Gubsheep for feedback and\nreview.\nZK-SNARKs are a powerful cryptographic tool, and an increasingly\nimportant part of the applications that people are building both in the\nblockchain space and beyond. But they are complicated, both in terms of\nhow they work, and in terms of how you can use\nthem.\nMy previous post explaining\nZK-SNARKs focused on the first question, attempting to explain the\nmath behind ZK-SNARKs in a way that's reasonably understandable but\nstill theoretically complete. This post will focus on the second\nquestion: how do ZK-SNARKs fit into existing applications, what are some\nexamples of what they can do, what can't they do, and what are some\ngeneral guidelines for figuring out whether or not ZK-SNARKing some\nparticular application is possible?\nIn particular, this post focuses on applications of ZK-SNARKs\nfor preserving privacy.\nWhat does a ZK-SNARK do?\nSuppose that you have a public input x, a private input w, and a (public) function f(x,w)→{True,False} that\nperforms some kind of verification on the inputs. With a ZK-SNARK, you\ncan prove that you know an w such\nthat f(x,w)=True for some given\nf and x, without revealing what w is. Additionally, the verifier can\nverify the proof much faster than it would take for them to compute\nf(x,w) themselves, even if they\nknow w.\n\nThis gives the ZK-SNARK its two properties: privacy\nand scalability. As mentioned above, in this post our\nexamples will focus on privacy.\nProof of membership\nSuppose that you have an Ethereum wallet, and you want to prove that\nthis wallet has a proof-of-humanity registration, without revealing\nwhich registered human you are. We can mathematically describe\nthe function as follows:\n\nThe private input (w): your address A, and the private key k to your address\nThe public input (x): the set of all addresses with\nverified proof-of-humanity profiles {H1...Hn}\nThe verification function f(x,w):\n\nInterpret w as the pair (A,k), and x as the list of valid profiles {H1...Hn}\nVerify that A is one of the\naddresses in {H1...Hn}\nVerify that privtoaddr(k)=A\nReturn True if both\nverifications pass, False if either\nverification fails\n\nThe prover generates their address A and the associated key k, and provides w=(A,k) as the private input to f. They take the public input, the\ncurrent set of verified proof-of-humanity profiles {H1...Hn}, from the chain. They run\nthe ZK-SNARK proving algorithm, which (assuming the inputs are correct)\ngenerates the proof. The prover sends the proof to the verifier and they\nprovide the block height at which they obtained the list of verified\nprofiles.\nThe verifier also reads the chain, gets the list {H1...Hn} at the height that the\nprover specified, and checks the proof. If the check passes, the\nverifier is convinced that the prover has some verified\nproof-of-humanity profile.\nBefore we move on to more complicated examples, I highly\nrecommend you go over the above example until you understand every bit\nof what is going on.\nMaking the\nproof-of-membership more efficient\nOne weakness in the above proof system is that the verifier needs to\nknow the whole set of profiles {H1...Hn}, and they need to spend O(n) time \"inputting\" this set into the\nZK-SNARK mechanism.\nWe can solve this by instead passing in as a public input an on-chain\nMerkle root containing all profiles (this could just be the\nstate root). We add another private input, a Merkle proof M proving that the prover's account A is in the relevant part of the\ntree.\n\nAdvanced readers: A very new and more efficient alternative to\nMerkle proofs for ZK-proving membership is Caulk. In the future, some\nof these use cases may migrate to Caulk-like schemes.\nZK-SNARKs for coins\nProjects like Zcash and Tornado.cash allow you to have\nprivacy-preserving currency. Now, you might think that you can\ntake the \"ZK proof-of-humanity\" above, but instead of proving access of\na proof-of-humanity profile, use it to prove access to a coin.\nBut we have a problem: we have to simultaneously solve privacy and\nthe double spending problem. That is, it should not be possible to\nspend the coin twice.\nHere's how we solve this. Anyone who has a coin has a private secret\ns. They locally compute the \"leaf\"\nL=hash(s,1), which gets\npublished on-chain and becomes part of the state, and N=hash(s,2), which we call the\nnullifier. The state gets stored in a Merkle tree.\n\nTo spend a coin, the sender must make a ZK-SNARK where:\n\nThe public input contains a nullifier N, the current or recent Merkle root\nR, and a new leaf L′ (the intent is that recipient has\na secret s′, and passes to the\nsender L′=hash(s′,1))\nThe private input contains a secret s, a leaf L and a Merkle branch M\nThe verification function checks that:\n\nM is a valid Merkle branch\nproving that L is a leaf in a tree\nwith root R, where R is the current Merkle root of the\nstate\nhash(s,1)=L\nhash(s,2)=N\n\nThe transaction contains the nullifier N and the new leaf L′. We don't actually prove anything\nabout L′, but we \"mix it in\" to\nthe proof to prevent L′ from\nbeing modified by third parties when the transaction is in-flight.\nTo verify the transaction, the chain checks the ZK-SNARK, and\nadditionally checks that N has not\nbeen used in a previous spending transaction. If the transaction\nsucceeds, N is added to the spent\nnullifier set, so that it cannot be spent again. L′ is added to the Merkle tree.\nWhat is going on here? We are using a zk-SNARK to relate two values,\nL (which goes on-chain when a coin\nis created) and N (which goes\non-chain when a coin is spent), without revealing which L is connected to which N. The connection between L and N can only be discovered if you know the\nsecret s that generates both. Each\ncoin that gets created can only be spent once (because for each L there is only one valid corresponding\nN), but which coin is\nbeing spent at a particular time is kept hidden.\nThis is also an important primitive to understand. Many of\nthe mechanisms we describe below will be based on a very similar\n\"privately spend only once\" gadget, though for different\npurposes.\nCoins with arbitrary\nbalances\nThe above can easily be extended to coins of arbitrary balances. We\nkeep the concept of \"coins\", except each coin has a (private) balance\nattached. One simple way to do this is have the chain store for each\ncoin not just the leaf L but also\nan encrypted balance.\nEach transaction would consume two coins and create two new\ncoins, and it would add two (leaf, encrypted balance) pairs to the\nstate. The ZK-SNARK would also check that the sum of the balances coming\nin equals the sum of the balances going out, and that the two output\nbalances are both non-negative.\nZK anti-denial-of-service\nAn interesting anti-denial-of-service\ngadget. Suppose that you have some on-chain identity that is non-trivial\nto create: it could be a proof-of-humanity profile, it could be a\nvalidator with 32 ETH, or it could just be an account that has a nonzero\nETH balance. We could create a more DoS resistant peer-to-peer network\nby only accepting a message if it comes with a proof that the message's\nsender has such a profile. Every profile would be allowed to send up to\n1000 messages per hour, and a sender's profile would be removed from the\nlist if the sender cheats. But how do we make this\nprivacy-preserving?\nFirst, the setup. Let k be the\nprivate key of a user; A=privtoaddr(k) is the corresponding address. The list of valid\naddresses is public (eg. it's a registry on-chain). So far this is\nsimilar to the proof-of-humanity example: you have to prove that you\nhave the private key to one address without revealing which one. But\nhere, we don't just want a proof that you're in the list. We want a\nprotocol that lets you prove you're in the list but prevents you\nfrom making too many proofs. And so we need to do some more\nwork.\nWe'll divide up time into epochs; each epoch lasts 3.6 seconds (so,\n1000 epochs per hour). Our goal will be to allow each user to send only\none message per epoch; if the user sends two messages in the\nsame epoch, they will get caught. To allow users to send occasional\nbursts of messages, they are allowed to use epochs in the recent past,\nso if some user has 500 unused epochs they can use those epochs to send\n500 messages all at once.\nThe protocol\nWe'll start with a simple version: we use nullifiers. A user\ngenerates a nullifier with N=hash(k,e), where k is their key\nand e is the epoch number, and\npublishes it along with the message m. The ZK-SNARK once again mixes in hash(m) without verifying anything about\nm, so that the proof is bound to a\nsingle message. If a user makes two proofs bound to two different\nmessages with the same nullifier, they can get caught.\nNow, we'll move on to the more complex version. Instead of just\nmaking it easy to prove if someone used the same epoch twice, this next\nprotocol will actually reveal their private key in that case.\nOur core technique will rely on the \"two points make a line\" trick: if\nyou reveal one point on a line, you've revealed little, but if you\nreveal two points on a line, you've revealed the whole line.\nFor each epoch e, we take the\nline Le(x)=hash(k,e)∗x+k.\nThe slope of the line is hash(k,e), and the y-intercept is k; neither is known to the public. To\nmake a certificate for a message m, the sender provides y=Le(hash(m))= hash(k,e)∗hash(m)+k, along with a\nZK-SNARK proving that y was\ncomputed correctly.\n\nTo recap, the ZK-SNARK here is as follows:\n\nPublic input:\n\n{A1...An}, the list of\nvalid accounts\nm, the message that the\ncertificate is verifying\ne, the epoch number used for\nthe certificate\ny, the line function\nevaluation\n\nPrivate input:\n\nk, your private key\n\nVerification function:\n\nCheck that privtoaddr(k) is in\n{A1...An}\nCheck that y=hash(k,e)∗hash(m)+k\n\nBut what if someone uses a single epoch twice? That means they\npublished two values m1 and m2 and the corresponding certificate\nvalues y1=hash(k,e)∗hash(m1)+k and y2=hash(k,e)∗hash(m2)+k. We can use the two points to recover the line, and hence\nthe y-intercept (which is the private key):\n\nk=y1−hash(m1)∗y2−y1hash(m2)−hash(m1)\n\nSo if someone reuses an epoch, they leak out their private key for\neveryone to see. Depending on the circumstance, this could imply stolen\nfunds, a slashed validator, or simply the private key getting\nbroadcasted and included into a smart contract, at which point the\ncorresponding address would get removed from the set.\nWhat have we accomplished here? A viable off-chain, anonymous\nanti-denial-of-service system useful for systems like blockchain\npeer-to-peer networks, chat applications, etc, without requiring any\nproof of work. The RLN\n(rate limiting nullifier) project is currently building essentially\nthis idea, though with minor modifications (namely, they do\nboth the nullifier and the two-points-on-a-line technique,\nusing the nullifier to make it easier to catch double-use of an\nepoch).\nZK negative reputation\nSuppose that we want to build 0chan, an internet\nforum which provides full anonymity like 4chan (so you don't even have\npersistent names), but has a reputation system to encourage more quality\ncontent. This could be a system where some moderation DAO can flag posts\nas violating the rules of the system and institutes a\nthree-strikes-and-you're-out mechanism, it could be users being able to\nupvote and downvote posts; there are lots of configurations.\nThe reputation system could support positive or negative reputation;\nhowever, supporting negative reputation requires extra infrastructure to\nrequire the user to take into account all reputation messages\nin their proof, even the negative ones. It's this harder use case, which\nis similar to what is being implemented with Unirep Social, that\nwe'll focus on.\nChaining posts: the basics\nAnyone can make a post by publishing a message on-chain that contains\nthe post, and a ZK-SNARK proving that either (i) you own some scarce\nexternal identity, eg. proof-of-humanity, that entitles you to create an\naccount, or (ii) that you made some specific previous post.\nSpecifically, the ZK-SNARK is as follows:\n\nPublic inputs:\n\nThe nullifier N\nA recent blockchain state root R\nThe post contents (\"mixed in\" to the proof to bind it to the post,\nbut we don't do any computation on it)\n\nPrivate inputs:\n\nYour private key k\nEither an external identity (with address A), or the nullifier Nprev used by the previous post\nA Merkle proof M proving\ninclusion of A or Nprev on-chain\nThe number i of posts that you\nhave previously made with this account\n\nVerification function:\n\nCheck that M is a valid Merkle\nbranch proving that (either A or\nNprev, whichever is provided) is\na leaf in a tree with root R\nCheck that N=enc(i,k), where\nenc is an encryption function (eg.\nAES)\nIf i=0, check that A=privtoaddr(k), otherwise check that\nNprev=enc(i−1,k)\n\nIn addition to verifying the proof, the chain also checks that (i)\nR actually is a recent state root,\nand (ii) the nullifier N has not\nyet been used. So far, this is like the privacy-preserving coin\nintroduced earlier, but we add a procedure for \"minting\" a new account,\nand we remove the ability to \"send\" your account to a different key -\ninstead, all nullifiers are generated using your original key.\nWe use enc instead of hash here to make the nullifiers\nreversible: if you have k, you can\ndecrypt any specific nullifier you see on-chain and if the result is a\nvalid index and not random junk (eg. we could just check dec(N)<264), then you know that\nnullifier was generated using k.\nAdding reputation\nReputation in this scheme is on-chain and in the clear: some smart\ncontract has a method addReputation, which takes as input\n(i) the nullifier published along with the post, and (ii) the number of\nreputation units to add and subtract.\nWe extend the on-chain data stored per post: instead of just storing\nthe nullifier N, we store {N,h¯,u¯}, where:\n\nh¯=hash(h,r) where\nh is the block height of the state\nroot that was referenced in the proof\nu¯=hash(u,r) where\nu is the account's reputation score\n(0 for a fresh account)\n\nr here is simply a random value,\nadded to prevent h and u from being uncovered by brute-force\nsearch (in cryptography jargon, adding r makes the hash a hiding\ncommitment).\nSuppose that a post uses a root R and stores {N,h¯,u¯}. In the proof, it\nlinks to a previous post, with stored data {Nprev,h¯prev,u¯prev}. The post's proof is also required to walk\nover all the reputation entries that have been published between hprev and h. For each nullifier N, the verification function would\ndecrypt N using the user's key\nk, and if the decryption outputs a\nvalid index it would apply the reputation update. If the sum of all\nreputation updates is δ, the\nproof would finally check u=uprev+δ.\n\nIf we want a \"three strikes and you're out\" rule, the ZK-SNARK would\nalso check u>−3. If we want a\nrule where a post can get a special \"high-reputation poster\" flag if the\nposter has ≥100 rep, we can\naccommodate that by adding \"is u≥100?\" as a public input. Many kinds of such rules can be\naccommodated.\nTo increase the scalability of the scheme, we could split it up into\ntwo kinds of messages: posts and reputation update\nacknowledgements (RCAs). A post would be off-chain, though it would\nbe required to point to an RCA made in the past week. RCAs would be\non-chain, and an RCA would walk through all the reputation updates since\nthat poster's previous RCA. This way, the on-chain load is reduced to\none transaction per poster per week plus one transaction per reputation\nmessage (a very low level if reputation updates are rare, eg. they're\nonly used for moderation actions or perhaps \"post of the day\" style\nprizes).\nHolding centralized\nparties accountable\nSometimes, you need to build a scheme that has a central \"operator\"\nof some kind. This could be for many reasons: sometimes it's for\nscalability, and sometimes it's for privacy - specifically, the privacy\nof data held by the operator.\nThe MACI\ncoercion-resistant voting system, for example, requires voters to submit\ntheir votes on-chain encrypted to a secret key held by a central\noperator. The operator would decrypt all the votes on-chain, count them\nup, and reveal the final result, along with a ZK-SNARK proving that they\ndid everything correctly. This extra complexity is necessary to ensure a\nstrong privacy property (called coercion-resistance):\nthat users cannot prove to others how they voted even if they wanted\nto.\nThanks to blockchains and ZK-SNARKs, the amount of trust in the\noperator can be kept very low. A malicious operator could still break\ncoercion resistance, but because votes are published on the blockchain,\nthe operator cannot cheat by censoring votes, and because the operator\nmust provide a ZK-SNARK, they cannot cheat by mis-calculating the\nresult.\nCombining ZK-SNARKs with MPC\nA more advanced use of ZK-SNARKs involves making proofs over\ncomputations where the inputs are split between two or more parties, and\nwe don't want each party to learn the other parties' inputs. You can\nsatisfy the privacy requirement with garbled circuits in the\n2-party case, and more complicated multi-party computation protocols in\nthe N-party case. ZK-SNARKs can be combined with these protocols to do\nverifiable multi-party computation.\nThis could enable more advanced reputation systems where multiple\nparticipants can perform joint computations over their private inputs,\nit could enable privacy-preserving but authenticated data markets, and\nmany other applications. That said, note that the math for doing this\nefficiently is still relatively in its infancy.\nWhat can't we make private?\nZK-SNARKs are generally very effective for creating systems where\nusers have private state. But ZK-SNARKs cannot hold private\nstate that nobody knows. To make a proof about a piece\nof information, the prover has to know that piece of information in\ncleartext.\nA simple example of what can't (easily) be made private is Uniswap.\nIn Uniswap, there is a single logically-central\n\"thing\", the market maker account, which belongs to no one, and every\nsingle trade on Uniswap is trading against the market maker account. You\ncan't hide the state of the market maker account, because then someone\nwould have to hold the state in cleartext to make proofs, and their\nactive involvement would be necessary in every single transaction.\nYou could make a centrally-operated, but safe and private,\nUniswap with ZK-SNARKed garbled circuits, but it's not clear that the\nbenefits of doing this are worth the costs. There may not even be any\nreal benefit: the contract would need to be able to tell users what the\nprices of the assets are, and the block-by-block changes in the prices\ntell a lot about what the trading activity is.\nBlockchains can make state information global, ZK-SNARKs can\nmake state information private, but we don't really have any\ngood way to make state information global and private at the\nsame time.\nEdit: you can use multi-party computation to implement shared\nprivate state. But this requires an honest-majority threshold\nassumption, and one that's likely unstable in practice because (unlike\neg. with 51% attacks) a malicious majority could collude to break the\nprivacy without ever being detected.\nPutting the primitives\ntogether\nIn the sections above, we've seen some examples that are powerful and\nuseful tools by themselves, but they are also intended to serve as\nbuilding blocks in other applications. Nullifiers, for example, are\nimportant for currency, but it turns out that they pop up again and\nagain in all kinds of use cases.\nThe \"forced chaining\" technique used in the negative reputation\nsection is very broadly applicable. It's effective for many applications\nwhere users have complex \"profiles\" that change in complex ways over\ntime, and you want to force the users to follow the rules of the system\nwhile preserving privacy so no one sees which user is performing which\naction. Users could even be required to have entire private Merkle trees\nrepresenting their internal \"state\". The \"commitment pool\" gadget proposed in this\npost could be built with ZK-SNARKs. And if some application can't be\nentirely on-chain and must have a centralized operator, the exact same\ntechniques can be used to keep the operator honest too.\nZK-SNARKs are a really powerful tool for combining together the\nbenefits of accountability and privacy. They do have their limits,\nthough in some cases clever application design can work around those\nlimits. I expect to see many more applications using ZK-SNARKs, and\neventually applications combining ZK-SNARKs with other forms of\ncryptography, to be built in the years to come.","tokens":5181,"squid":"ink-research","role":"Deep Scholar","at":1791260803723,"hash":"cbd3f4e53818cbe17bb5ddd5008963705302fdee"}
{"url":"https://atlas.optimism.io/proposals/11395393129418988064055248708940773896984094841972570152146884754918156646311","domain":"atlas.optimism.io","title":"Proposals: Governor Upgrade Proposal: Onchain Controls MVP - OP Atlas","text":"Governor Upgrade Proposal: Onchain Controls MVPVoting Nov 6, 2025 - Nov 12, 2025You should only cast a vote on this proposal if you want to veto the DAB’s decision to approve this upgrade.\nThis proposal introduces the Onchain Controls MVP, a Governor upgrade that moves key governance powers from off-chain processes to onchain execution. It transfers the Optimism Governor’s admin role to the Security Council and establishes an onchain authorizedProposer role, enabling the Token House to exercise enforceable, onchain authority while maintaining safety controls under the Optimism Foundation.\nThis proposal was approved by the Developer Advisory Board here. Governance participants may veto the DAB’s decision if they believe it disadvantages their stakeholder group (tokenholders, chains, apps, or end-users.) You can read more about Stakeholder Vetos in our Operating Manual.\nIn the case of a veto, this proposal will proceed through the Appeals process outlined in the Operating Manual.Ended 11/12/2025This decision standsSUCCEEDEDView resultsAre you a delegate?Vote hereNeed help?Ask on Discord","tokens":275,"squid":"ink-governance","role":"Council Listener","at":1791260805152,"hash":"a74efbed4d10c9392e60a755c095196790a4b3c9"}
{"url":"https://io.net/docs/guides/staking/create-a-co-staking-offer","domain":"io.net","title":"Create a Co-staking Offer - io.net","text":"​Table of Contents\n\nCreate a Co-staking Offer\nOffer Status\nCheck Co-Staked Devices\n\n​Create a Co-staking Offer\nPrerequisite\nBefore creating a Co-Staking offer, ensure that your device meets the minimum staking requirement. If the requirement is not met, the option to create a Co-Staking offer will be disabled (grayed out).\nSteps to Create a Co-Staking Offer\n\nIn the Staking Actions column, click the three dots next to your device and select Create Co-Staking Offer.\n\nSet the amount of IO you’re requesting from a potential co-staker using the slider on the Co-Staker Contribution page. The maximum co-stake is 50% of the total stake.\n\nOn the Block Reward Sharing page, define the reward percentage for the co-staker using the slider. In the screenshot below, the co-staker will receive 74% of the block reward. Below the slider, we provide the estimated block reward per block for your co-staker based on the previous 7-day average.\n\nReview your choices on the Summary page and click Create a Co-Staking Offer.\n\nA unique offer link will be generated. Share this link with your collaborators.\n\nTo see your device, return to the Staking section and find your device listed under the Co-Staking Devices tab.\n\n​Offer Status\nTrack your Co-Staking offer in the Co-Staking Devices tab. Statuses include:\n\nSufficient State (Wait Period): The co-staker has unstaked, and their contribution is in the 7-day Wait Period. The stake still counts toward the device’s minimum staking requirement but does not earn block rewards.\nSufficient State (Waiting for Co-Staker): The owner has staked the device and is awaiting a co-staker.\nIn Cooldown: The unstaking process has completed the wait period and is now in a 14-day cooldown, where funds remain locked.\nCo-Staker Withdrawn: The co-staker has successfully withdrawn their funds after completing the unstaking process.\nCo-Staker Unstaked (In Wait Period): The co-staker has initiated unstaking, and their funds are in the 7-day wait period.\nOffer Closed: The offer has been closed by the owner or due to other circumstances and is no longer available in the marketplace.\nInsufficient Stake (Waiting for Co-Staker): The device does not meet the minimum stake requirement and is waiting for a co-staker to fulfill it.\n\n​Managing Co-Staked Devices\n\nTo view and manage your co-staked devices, click Co-Staked Devices tab.\n\nTo view offers, click the ellipsis next to the device and choose Co-Staking Details.\n\nThe Check Offer modal shows you the parameters of the Co-Staked Device.\n\nWas this page helpful?","tokens":635,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260806594,"hash":"08136956352528911ab907f2946b9a385ac0787d"}
{"url":"https://vote.optimism.io/proposals/98514033075828457515265808158613519042911506455163747732265774291262567775647","domain":"vote.optimism.io","title":"Governor Upgrade Proposal: Onchain Co...","text":"ProposalsVotersConnect  Wallet Joint House Optimistic Proposal by The Optimism FoundationGovernor Upgrade Proposal: Onchain Controls MVPNew: This proposal implements the Joint House Voting. Learn more about how the two houses work together here: Operating Manual.You should only cast a vote on this proposal if you want to veto the DAB’s decision to approve this upgrade.\nThis proposal introduces the Onchain Controls MVP, a Governor upgrade that moves key governance powers from off-chain processes to onchain execution. It transfers the Optimism Governor’s admin role to the Security Council and establishes an onchain authorizedProposer role, enabling the Token House to exercise enforceable, onchain authority while maintaining safety controls under the Optimism Foundation.\nThis proposal was approved by the Developer Advisory Board here. Governance participants may veto the DAB’s decision if they believe it disadvantages their stakeholder group (tokenholders, chains, apps, or end-users.) You can read more about Stakeholder Vetos in our Operating Manual.\nIn the case of a veto, this proposal will proceed through the Appeals process outlined in the Operating Manual.SUCCEEDEDEnded 1:54 pm Nov 12, 2025Proposal has passedOne of three thresholds are applied, based on the number of groups signaling to veto.Chains0%Apps0%Users0.9%Delegates0.6%# of signaling groupsAre you a citizen? Connect wallet hereGovernor Upgrade Proposal: Onchain Co...Governance ForumReport bugs & feedbackChange logFAQ4.295B OP total supply56.77M OP votable supply","tokens":387,"squid":"ink-governance","role":"Council Listener","at":1791260815143,"hash":"b643b7b24e559c5a280df0002160361b6a3f98fa"}
{"url":"https://io.net/docs/guides/staking/protecting-your-stake","domain":"io.net","title":"Protecting your Stake - io.net","text":"When participating in $IO staking, it’s crucial to only interact with the official and correct smart contract. This contract governs the staking process, ensuring your funds are safely managed in line with the platform’s operations. To protect yourself from potential risks, always verify the contract address before making any transactions. Here’s how you can safeguard your funds and ensure the legitimacy of your transactions.\nWe will never DM you in Discord or any other platform outside our official channels with alternative wallet addresses.\nBe cautious of scammers who may ask you to transfer funds to alternative addresses. If you receive any unsolicited messages asking you to send crypto to another wallet or join a staking offer outside of official channels, do not engage. Scammers often impersonate our team, and many users have fallen victim to these attacks, resulting in lost funds. Protect your assets by following the steps outlined below.\n​Official $IO Staking Contract Address\nTo ensure you’re interacting with the correct contract, always verify the address in our official documentation.\nhttps://solscan.io/account/3RRz3bZ7Khr3Cw2i7JURpKuUPT3G9QFV7fNVPmhSsF2i \n\n​Security Practices to Protect Your Stake:\n\nAccess URLs Directly: Always type io.net directly into your browser and bookmark the site. This protects against phishing sites that could trick you into entering personal details on fraudulent websites.\nVerify Smart Contracts: Before interacting with any smart contract, use trusted tools like Solscan to confirm the contract address matches the one provided in our official documentation. This step helps ensure your interactions are with legitimate addresses only.\nWatch Out for Phishing: Be cautious of links from unverified sources, unsolicited crypto offers, or direct messages, especially on platforms like Discord, social media, or community forums. Scammers often impersonate official channels and offer fake staking opportunities or ask you to send funds to alternative wallet addresses.\nUse Secure Wallets: For added security, use hardware wallets to store your funds. These provide an extra layer of protection against hacks. Never share your private keys or seed phrases with anyone, and always store them securely.\n\n​Why this matters:\nInteracting with incorrect or malicious contracts could result in the loss of your funds or the compromise of your sensitive information. Always verify every detail and follow the security measures listed above before making any transactions or interacting with smart contracts.\n​Verify Official Contract Addresses\nTo ensure the security of your transactions with the $IO ecosystem, always double-check the following contract addresses:\n\n$IO Token Contract: The official smart contract for the $IO token.\n$IO Staking Contract: The official contract for staking your $IO tokens.\n$IO Safety Module: The contract for the $IO Safety Module, which provides additional security features for your stake.\n\nYou can verify these addresses using:\n\nOfficial documentation or the io.net website.\nBlockchain explorers like Solscan.\nCommunity announcements or official support channels.\nWas this page helpful?","tokens":793,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791260817641,"hash":"32bde018a1fbcacee812c4d51de5c43a771eed85"}
{"url":"https://vitalik.eth.limo/general/2021/01/26/snarks.html","domain":"vitalik.eth.limo","title":"An approximate introduction to how zk-SNARKs are possible","text":"Dark Mode Toggle\n\n An approximate introduction to how zk-SNARKs are possible \n 2021 Jan 26 \nSee all posts\n\n An approximate introduction to how zk-SNARKs are possible \n\nSpecial thanks to Dankrad Feist, Karl Floersch and Hsiao-wei Wang\nfor feedback and review.\nPerhaps the most powerful cryptographic technology to come out of the\nlast decade is general-purpose succinct zero knowledge proofs, usually\ncalled zk-SNARKs (\"zero knowledge succinct arguments of knowledge\"). A\nzk-SNARK allows you to generate a proof that some computation has some\nparticular output, in such a way that the proof can be verified\nextremely quickly even if the underlying computation takes a very long\ntime to run. The \"ZK\" (\"zero knowledge\") part adds an additional\nfeature: the proof can keep some of the inputs to the computation\nhidden.\nFor example, you can make a proof for the statement \"I know a secret\nnumber such that if you take the word ‘cow', add the number to the end,\nand SHA256 hash it 100 million times, the output starts with\n0x57d00485aa\". The verifier can verify the proof far more\nquickly than it would take for them to run 100 million hashes\nthemselves, and the proof would also not reveal what the secret number\nis.\nIn the context of blockchains, this has two very powerful\napplications:\n\nScalability: if a block takes a long time to\nverify, one person can verify it and generate a proof, and everyone else\ncan just quickly verify the proof instead\nPrivacy: you can prove that you have the right to\ntransfer some asset (you received it, and you didn't already transfer\nit) without revealing the link to which asset you received. This ensures\nsecurity without unduly leaking information about who is transacting\nwith whom to the public.\n\nBut zk-SNARKs are quite complex; indeed, as recently as in 2014-17\nthey were still frequently called \"moon math\". The good news is that\nsince then, the protocols have become simpler and our understanding of\nthem has become much better. This post will try to explain how ZK-SNARKs\nwork, in a way that should be understandable to someone with a medium\nlevel of understanding of mathematics.\nNote that we will focus on scalability; privacy for these\nprotocols is actually relatively easy once the scalability is there, so\nwe will get back to that topic at the end.\nWhy ZK-SNARKs \"should\" be\nhard\nLet us take the example that we started with: we have a number (we\ncan encode \"cow\" followed by the secret input as an integer), we take\nthe SHA256 hash of that number, then we do that again another 99,999,999\ntimes, we get the output, and we check what its starting digits are.\nThis is a huge computation.\nA \"succinct\" proof is one where both the size of the proof and the\ntime required to verify it grow much more slowly than the computation to\nbe verified. If we want a \"succinct\" proof, we cannot require the\nverifier to do some work per round of hashing (because then the\nverification time would be proportional to the computation). Instead,\nthe verifier must somehow check the whole computation without peeking\ninto each individual piece of the computation.\nOne natural technique is random sampling: how about we just\nhave the verifier peek into the computation in 500 different places,\ncheck that those parts are correct, and if all 500 checks pass then\nassume that the rest of the computation must with high probability be\nfine, too?\nSuch a procedure could even be turned into a non-interactive proof\nusing the Fiat-Shamir heuristic: the prover computes a\nMerkle root of the computation, uses the Merkle root to pseudorandomly\nchoose 500 indices, and provides the 500 corresponding Merkle branches\nof the data. The key idea is that the prover does not know which\nbranches they will need to reveal until they have already \"committed to\"\nthe data. If a malicious prover tries to fudge the data after learning\nwhich indices are going to be checked, that would change the Merkle\nroot, which would result in a new set of random indices, which would\nrequire fudging the data again... trapping the malicious prover in an\nendless cycle.\nBut unfortunately there is a fatal flaw in naively applying random\nsampling to spot-check a computation in this way: computation is\ninherently fragile. If a malicious prover flips one bit\nsomewhere in the middle of a computation, they can make it give a\ncompletely different result, and a random sampling verifier would almost\nnever find out.\n\n It only takes one deliberately inserted error, that a\nrandom check would almost never catch, to make a computation give a\ncompletely incorrect result.\n\nIf tasked with the problem of coming up with a zk-SNARK protocol,\nmany people would make their way to this point and then get stuck and\ngive up. How can a verifier possibly check every single piece of the\ncomputation, without looking at each piece of the computation\nindividually? But it turns out that there is a clever solution.\nPolynomials\nPolynomials are a special class of algebraic expressions of the\nform:\n\nx+5\nx4\nx3+3x2+3x+1\n628x271+318x270+530x269+...+69x+381\n\ni.e. they are a sum of any (finite!) number of terms of the form\ncxk.\nThere are many things that are fascinating about polynomials. But\nhere we are going to zoom in on a particular one: polynomials\nare a single mathematical object that can contain an unbounded amount of\ninformation (think of them as a list of integers and this is\nobvious). The fourth example above contained 816 digits of tau, and one can\neasily imagine a polynomial that contains far more.\nFurthermore, a single equation between polynomials can\nrepresent an unbounded number of equations between numbers. For\nexample, consider the equation A(x)+B(x)=C(x). If this equation is true, then it's also true that:\n\nA(0)+B(0)=C(0)\nA(1)+B(1)=C(1)\nA(2)+B(2)=C(2)\nA(3)+B(3)=C(3)\n\nAnd so on for every possible coordinate. You can even construct\npolynomials to deliberately represent sets of numbers so you can check\nmany equations all at once. For example, suppose that you wanted to\ncheck:\n\n12 + 1 = 13\n10 + 8 = 18\n15 + 8 = 23\n15 + 13 = 28\n\nYou can use a procedure called Lagrange\ninterpolation to construct polynomials A(x) that give\n(12, 10, 15, 15) as outputs at some specific set of\ncoordinates (eg. (0, 1, 2, 3)), B(x) the outputs\n(1, 8, 8, 13) on those same coordinates, and so forth. In\nfact, here are the polynomials:\n\nA(x)=−2x3+192x2−192x+12\nB(x)=2x3−192x2+292x+1\nC(x)=5x+13\n\nChecking the equation A(x)+B(x)=C(x) with these polynomials checks all four above equations at\nthe same time.\nComparing a polynomial to\nitself\nYou can even check relationships between a large number of\nadjacent evaluations of the same polynomial using a simple\npolynomial equation. This is slightly more advanced. Suppose that you\nwant to check that, for a given polynomial F, F(x+2)=F(x)+F(x+1) within the integer range {0,1...98} (so if you also\ncheck F(0)=F(1)=1, then F(100) would be the 100th Fibonacci\nnumber).\nAs polynomials, F(x+2)−F(x+1)−F(x) would not be exactly zero, as it could give arbitrary\nanswers outside the range x={0,1...98}. But we can do something clever. In general, there\nis a rule that if a polynomial P is\nzero across some set S={x1,x2...xn} then it can be expressed as P(x)=Z(x)∗H(x), where Z(x)= (x−x1)∗(x−x2)∗...∗(x−xn) and H(x) is also a polynomial. In other\nwords, any polynomial that equals zero across some set is a\n(polynomial) multiple of the simplest (lowest-degree) polynomial that\nequals zero across that same set.\nWhy is this the case? It is a nice corollary of polynomial long\ndivision: the\nfactor theorem. We know that, when dividing P(x) by Z(x), we will get a quotient Q(x) and a remainer R(x) which satisfy P(x)=Z(x)∗Q(x)+R(x), where the\ndegree of the remainder R(x) is\nstrictly less than that of Z(x).\nSince we know that P is zero on all\nof S, it means that R has to be zero on all of S as well. So we can simply compute R(x) via polynomial interpolation, since\nit's a polynomial of degree at most n−1 and we know n values (the zeroes at S). Interpolating a polynomial with all\nzeroes gives the zero polynomial, thus R(x)=0 and H(x)=Q(x).\nGoing back to our example, if we have a polynomial F that encodes Fibonacci numbers (so\nF(x+2)=F(x)+F(x+1) across x={0,1...98}), then I can convince\nyou that F actually satisfies\nthis condition by proving that the polynomial P(x)= F(x+2)−F(x+1)−F(x) is zero over that range, by giving you the\nquotient:\nH(x)=F(x+2)−F(x+1)−F(x)Z(x)\nWhere Z(x)=(x−0)∗(x−1)∗...∗(x−98).\nYou can calculate Z(x) yourself\n(ideally you would have it precomputed), check the equation, and if the\ncheck passes then F(x) satisfies\nthe condition!\nNow, step back and notice what we did here. We converted a\n100-step-long computation (computing the 100th Fibonacci number) into a\nsingle equation with polynomials. Of course, proving the N'th Fibonacci\nnumber is not an especially useful task, especially since Fibonacci\nnumbers have\na closed form. But you can use exactly the same basic technique,\njust with some extra polynomials and some more complicated equations, to\nencode arbitrary computations with an arbitrarily large number of\nsteps.\nNow, if only there was a way to verify equations with polynomials\nthat's much faster than checking each coefficient...\nPolynomial commitments\nAnd once again, it turns out that there is an answer:\npolynomial commitments. A polynomial commitment is best\nviewed as a special way to \"hash\" a polynomial, where the hash has the\nadditional property that you can check equations between polynomials by\nchecking equations between their hashes. Different polynomial commitment\nschemes have different properties in terms of exactly what kinds of\nequations you can check.\nHere are some common examples of things you can do with various\npolynomial commitment schemes (we use com(P) to mean \"the commitment to the\npolynomial P\"):\n\nAdd them: given com(P), com(Q) and com(R) check if P+Q=R\nMultiply them: given com(P), com(Q) and com(R) check if P∗Q=R\nEvaluate at a point: given com(P), w, z\nand a supplemental proof (or \"witness\") Q, verify that P(w)=z\n\nIt's worth noting that these primitives can be constructed from each\nother. If you can add and multiply, then you can evaluate: to prove that\nP(w)=z, you can construct Q(x)=P(x)−zx−w, and the\nverifier can check if Q(x)∗(x−w)+z=?P(x). This works because if such a polynomial\nQ(x) exists, then P(x)−z=Q(x)∗(x−w), which means\nthat P(x)−z equals zero at w (as x−w equals zero at w) and so\nP(x) equals z at w.\nAnd if you can evaluate, you can do all kinds of checks. This is\nbecause there is a mathematical\ntheorem that says, approximately, that if some equation involving\nsome polynomials holds true at a randomly selected coordinate,\nthen it almost certainly holds true for the polynomials as a whole. So\nif all we have is a mechanism to prove evaluations, we can check eg. our\nequation P(x+2)−P(x+1)−P(x)=Z(x)∗H(x) using an interactive game:\n\nAs I alluded to earlier, we can make this non-interactive\nusing the Fiat-Shamir heuristic: the prover can compute\nr themselves by setting\nr = hash(com(P), com(H)) (where hash is any\ncryptographic hash function; it does not need any special properties).\nThe prover cannot \"cheat\" by picking P and H\nthat \"fit\" at that particular r but not elsewhere, because\nthey do not know r at the time that they are picking\nP and H!\nA quick recap so far\n\nZK-SNARKs are hard because the verifier needs to somehow check\nmillions of steps in a computation, without doing a piece of work to\ncheck each individual step directly (as that would take too long).\nWe get around this by encoding the computation into\npolynomials.\nA single polynomial can contain an unboundedly large amount of\ninformation, and a single polynomial expression (eg. P(x+2)−P(x+1)−P(x)=Z(x)∗H(x)) can\n\"stand in\" for an unboundedly large number of equations between\nnumbers.\nIf you can verify the equation with polynomials, you are implicitly\nverifying all of the number equations (replace x with any actual x-coordinate)\nsimultaneously.\nWe use a special type of \"hash\" of a polynomial, called a\npolynomial commitment, to allow us to actually verify the\nequation between polynomials in a very short amount of time, even if the\nunderlying polynomials are very large.\n\nSo, how do these\nfancy polynomial hashes work?\nThere are three major schemes that are widely used at the moment:\nbulletproofs, Kate and FRI.\n\nHere is a description of Kate commitments by Dankrad Feist: https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html\nHere is a description of bulletproofs by the curve25519-dalek team:\nhttps://doc-internal.dalek.rs/bulletproofs/notes/inner_product_proof/index.html,\nand here is an explanation-in-pictures by myself: https://twitter.com/VitalikButerin/status/1371844878968176647\nHere is a description of FRI by... myself: ../../../2017/11/22/starks_part_2.html\n\nWhoa,\nwhoa, take it easy. Try to explain one of them simply, without shipping\nme off to even more scary links\nTo be honest, they're not that simple. There's a reason why\nall this math did not really take off until 2015 or so.\nPlease?\nIn my opinion, the easiest one to understand fully is FRI (Kate is\neasier if you're willing to accept elliptic\ncurve pairings as a \"black box\", but pairings are really\ncomplicated, so altogether I find FRI simpler).\nHere is how a simplified version of FRI works (the real protocol has\nmany tricks and optimizations that are missing here for simplicity).\nSuppose that you have a polynomial P with degree <n. The commitment to P is a Merkle root of a set of\nevaluations to P at some set of\npre-selected coordinates (eg. {0,1....8n−1}, though this is not the most efficient choice). Now, we\nneed to add something extra to prove that this set of evaluations\nactually is a degree <n\npolynomial.\nLet Q be the polynomial only\ncontaining the even coefficients of P, and R be the polynomial only containing the\nodd coefficients of P. So if P(x)=x4+4x3+6x2+4x+1, then\nQ(x)=x2+6x+1 and R(x)=4x+4 (note that the degrees of\nthe coefficients get \"collapsed down\" to the range [0...n2)).\nNotice that P(x)=Q(x2)+x∗R(x2) (if this isn't immediately obvious to you, stop and\nthink and look at the example above until it is).\nWe ask the prover to provide Merkle roots for Q(x) and R(x). We then generate a random number\nr and ask the prover to provide a\n\"random linear combination\" S(x)=Q(x)+r∗R(x).\nWe pseudorandomly sample a large set of indices (using the\nalready-provided Merkle roots as the seed for the randomness as before),\nand ask the prover to provide the Merkle branches for P, Q, R\nand S at these indices. At each of\nthese provided coordinates, we check that:\n\nP(x) actually does\nequal Q(x2)+x∗R(x2)\nS(x) actually does\nequal Q(x)+r∗R(x)\n\nIf we do enough checks, then we can be convinced that the \"expected\"\nvalues of S(x) are different from\nthe \"provided\" values in at most, say, 1% of cases.\nNotice that Q and R both have degree <n2. Because S is a linear combination of Q and R, S\nalso has degree <n2. And this works in reverse: if we can prove S has degree <n2, then the fact that it's\na randomly chosen combination prevents the prover from choosing\nmalicious Q and R with hidden high-degree coefficients\nthat \"cancel out\", so Q and R must both be degree <n2, and because P(x)=Q(x2)+x∗R(x2), we know that\nP must have degree <n.\nFrom here, we simply repeat the game with S, progressively \"reducing\" the\npolynomial we care about to a lower and lower degree, until it's at a\nsufficiently low degree that we can check it directly.\n\nAs in the previous examples, \"Bob\" here is an abstraction, useful for\ncryptographers to mentally reason about the protocol. In reality, Alice\nis generating the entire proof herself, and to prevent her from cheating\nwe use Fiat-Shamir: we choose each randomly samples coordinate or\nr value based on the hash of the data generated in the\nproof up until that point.\nA full \"FRI commitment\" to P (in\nthis simplified protocol) would consist of:\n\nThe Merkle root of evaluations of P\nThe Merkle roots of evaluations of Q, R, S1\nThe randomly selected branches of P, Q, R, S1 to check S1 is correctly \"reduced from\" P\nThe Merkle roots and randomly selected branches just as in steps (2)\nand (3) for successively lower-degree reductions S2 reduced from S1, S3 reduced from S2, all the way down to a low-degree\nSk (this gets repeated ≈log2(n) times in total)\nThe full Merkle tree of the evaluations of Sk (so we can check it directly)\n\nEach step in the process can introduce a bit of \"error\", but if you\nadd enough checks, then the total error will be low enough that you can\nprove that P(x) equals a degree\n<n polynomial in at least, say,\n80% of positions. And this is sufficient for our use cases. If you want\nto cheat in a zk-SNARK, you would need to make a polynomial commitment\nfor a fractional expression (eg. to \"prove\" the false claim that x2+2x+3 evaluated at 4 equals 5, you would need to provide a polynomial\ncommitment for x2+2x+3−5x−4=x+6+22x−4). The set of evaluations for such\na fractional expression would differ from the evaluations for\nany real degree <n polynomial\nin so many positions that any attempt to make a FRI commitment to them\nwould fail at some step.\nAlso, you can check carefully that the total number and size of the\nobjects in the FRI commitment is logarithmic in the degree, so for large\npolynomials, the commitment really is much smaller than the polynomial\nitself.\nTo check equations between different polynomial commitments of this\ntype (eg. check A(x)+B(x)=C(x)\ngiven FRI commitments to A, B and C), simply randomly select many indices,\nask the prover for Merkle branches at each of those indices for each\npolynomial, and verify that the equation actually holds true at each of\nthose positions.\nThe above description is a highly inefficient protocol; there\nis a whole host of algebraic tricks that can increase its\nefficiency by a factor of something like a hundred, and you\nneed these tricks if you want a protocol that is actually viable for,\nsay, use inside a blockchain transaction. In particular, for example,\nQ and R are not actually necessary, because if\nyou choose your evaluation points very cleverly, you can reconstruct the\nevaluations of Q and R that you need directly from evaluations\nof P. But the above description\nshould be enough to convince you that a polynomial commitment is\nfundamentally possible.\nFinite fields\nIn the descriptions above, there was a hidden assumption: that each\nindividual \"evaluation\" of a polynomial was small. But when we are\ndealing with polynomials that are big, this is clearly not true. If we\ntake our example from above, 628x271+318x270+530x269+...+69x+381, that encodes 816\ndigits of tau, and evaluate it at x=1000, you get.... an 816-digit number\ncontaining all of those digits of tau. And so there is one more thing\nthat we need to add. In a real implementation, all of the arithmetic\nthat we are doing here would not be done using \"regular\" arithmetic over\nreal numbers. Instead, it would be done using modular\narithmetic.\nWe redefine all of our arithmetic operations as follows. We pick some\nprime \"modulus\" p. The % operator means \"take the remainder\nof\": 15 % 7=1, 53 % 10=3, etc (note that the answer\nis always non-negative, so for example −1 % 10=9). We redefine\nx+y⇒(x+y) %\np\nx∗y⇒(x∗y) %\np\nxy⇒(xy) % p\nx−y⇒(x−y) %\np\nx/y⇒(x∗yp−2)\n% p\nThe above rules are all self-consistent. For example, if p=7, then:\n\n5+3=1 (as 8 % 7=1)\n1−3=5 (as −2 % 7=5)\n2⋅5=3\n3/5=2 (as (3⋅55) % 7=9375 % 7=2)\n\nMore complex identities such as the distributive law also hold: (2+4)⋅3 and 2⋅3+4⋅3 both evaluate to\n4. Even formulas like (a2−b2) = (a−b)⋅(a+b) are still true in\nthis new kind of arithmetic.\nDivision is the hardest part; we can't use regular division because\nwe want the values to always remain integers, and regular division often\ngives non-integer results (as in the case of 3/5). We get around this problem using Fermat's\nlittle theorem, which states that for any nonzero x<p, it holds that xp−1 % p=1. This implies that xp−2 gives a number which, if\nmultiplied by x one more time,\ngives 1, and so we can say that\nxp−2 (which is an integer)\nequals 1x. A somewhat more\ncomplicated but faster way to evaluate this modular division operator is\nthe extended\nEuclidean algorithm, implemented in python here.\n\nBecause of how the numbers \"wrap around\", modular arithmetic is\nsometimes called \"clock math\"\n\nWith modular math we've created an entirely new system of arithmetic,\nand it's self-consistent in all the same ways traditional arithmetic is\nself-consistent. Hence, we can talk about all of the same kinds of\nstructures over this field, including polynomials, that we talk about in\n\"regular math\". Cryptographers love working in modular math (or, more\ngenerally, \"finite fields\") because there is a bound on the size of a\nnumber that can arise as a result of any modular math calculation - no\nmatter what you do, the values will not \"escape\" the set {0,1,2...p−1}. Even evaluating a\ndegree-1-million polynomial in a finite field will never give an answer\noutside that set.\nWhat's\na slightly more useful example of a computation being converted into a\nset of polynomial equations?\nLet's say we want to prove that, for some polynomial P, 0≤P(n)<264, without revealing the exact value of P(n). This is a common use case in\nblockchain transactions, where you want to prove that a transaction\nleaves a balance non-negative without revealing what that balance\nis.\nWe can construct a proof for this with the following polynomial\nequations (assuming for simplicity n=64):\n\nP(0)=0\nP(x+1)=P(x)∗2+R(x) across\nthe range {0...63}\nR(x)∈{0,1} across the\nrange {0...63}\n\nThe latter two statements can be restated as \"pure\" polynomial\nequations as follows (in this context Z(x)=(x−0)∗(x−1)∗...∗(x−63)):\n\nP(x+1)−P(x)∗2−R(x)=Z(x)∗H1(x)\nR(x)∗(1−R(x))=Z(x)∗H2(x) (notice the clever trick: y∗(1−y)=0 if and only if y∈{0,1})\n\nThe idea is that successive evaluations of P(i) build up the number bit-by-bit: if\nP(4)=13, then the sequence of\nevaluations going up to that point would be: {0,1,3,6,13}. In binary, 1 is\n1, 3 is 11, 6 is 110, 13 is\n1101; notice how P(x+1)=P(x)∗2+R(x) keeps adding one bit to the end as long as R(x) is zero or one. Any number within\nthe range 0≤x<264 can\nbe built up over 64 steps in this way, any number outside that range\ncannot.\nPrivacy\nBut there is a problem: how do we know that the commitments to P(x) and R(x) don't \"leak\" information that allows\nus to uncover the exact value of P(64), which we are trying to keep\nhidden?\nThere is some good news: these proofs are small proofs that\ncan make statements about a large amount of data and computation. So in\ngeneral, the proof will very often simply not be big enough to\nleak more than a little bit of information. But can we go from\n\"only a little bit\" to \"zero\"? Fortunately, we can.\nHere, one fairly general trick is to add some \"fudge factors\" into\nthe polynomials. When we choose P,\nadd a small multiple of Z(x) into\nthe polynomial (that is, set P′(x)=P(x)+Z(x)∗E(x) for some random E(x)). This does not affect the\ncorrectness of the statement (in fact, P′ evaluates to the same values as\nP on the coordinates that \"the\ncomputation is happening in\", so it's still a valid transcript), but it\ncan add enough extra \"noise\" into the commitments to make any remaining\ninformation unrecoverable. Additionally, in the case of FRI, it's\nimportant to not sample random points that are within the domain that\ncomputation is happening in (in this case {0...64}).\nCan we have one more recap,\nplease??\n\nThe three most prominent types of polynomial commitments are FRI,\nKate and bulletproofs.\nKate is the simplest conceptually but depends on the really\ncomplicated \"black box\" of elliptic curve pairings.\nFRI is cool because it relies only on hashes; it works by\nsuccessively reducing a polynomial to a lower and lower-degree\npolynomial and doing random sample checks with Merkle branches to prove\nequivalence at each step.\nTo prevent the size of individual numbers from blowing up, instead\nof doing arithmetic and polynomials over the integers, we do\neverything over a finite field (usually integers modulo some\nprime p)\nPolynomial commitments lend themselves naturally to privacy\npreservation because the proof is already much smaller than the\npolynomial, so a polynomial commitment can't reveal more than a little\nbit of the information in the polynomial anyway. But we can add some\nrandomness to the polynomials we're committing to to reduce the\ninformation revealed from \"a little bit\" to \"zero\".\n\nWhat research\nquestions are still being worked on?\n\nOptimizing FRI: there are already quite a few\noptimizations involving carefully selected evaluation domains, \"DEEP-FRI\", and a whole host\nof other tricks to make FRI more efficient. Starkware and others are\nworking on this.\nBetter ways to encode computation into polynomials:\nfiguring out the most efficient way to encode complicated computations\ninvolving hash functions, memory access and other features into\npolynomial equations is still a challenge. There has been great progress\non this (eg. see PLOOKUP), but we still need\nmore, especially if we want to encode general-purpose virtual machine\nexecution into polynomials.\nIncrementally verifiable computation: it would be\nnice to be able to efficiently keep \"extending\" a proof while a\ncomputation continues. This is valuable in the \"single-prover\" case, but\nalso in the \"multi-prover\" case, particularly a blockchain where a\ndifferent participant creates each block. See Halo for some recent\nwork on this.\n\nI wanna learn more!\nMy materials\n\nSTARKs: part 1,\npart 2, part 3\nSpecific protocols for encoding computation into polynomials: PLONK\nSome key mathematical optimizations I didn't talk about here: Fast Fourier transforms\n\nOther people's materials\n\nStarkware's\nonline course\nDankrad\nFeist on Kate commitments\nBulletproofs","tokens":6452,"squid":"ink-research","role":"Deep Scholar","at":1791260821692,"hash":"1e788d6d91c8c45baf641e2f36d62e0c2c077d2c"}
{"url":"https://atlas.optimism.io/proposals/91740421806758540401606442634499715051426524644078939676466319136051150178634","domain":"atlas.optimism.io","title":"Proposals: Proposal to Align OP Token with Superchain Success - OP Atlas","text":"Proposal to Align OP Token with Superchain SuccessVoting Jan 22, 2026 - Jan 28, 2026This vote will be subject to Joint House approval at a 60% approval threshold.\nThis proposal would authorize a 12 month program, dedicating 50% of incoming Superchain revenue to buying back OP, beginning in February. The purchased OP will be held in the Collective treasury, along with the remaining sequencer ETH.\nIf approved, the Foundation will partner with an OTC provider to execute monthly conversions of ETH to OP.\nRead the full proposal hereEnded 1/28/2026This proposal has endedSUCCEEDEDView resultsAre you a delegate?Vote hereNeed help?Ask on Discord","tokens":161,"squid":"ink-governance","role":"Council Listener","at":1791260824554,"hash":"b9355682b4d0db87ae69f89bb261896204112fca"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/56","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 51 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791260832904,"hash":"76ed403bb30408a694d21f019e64192fa234e1cf"}
{"url":"https://docs.arbitrum.io/run-arbitrum-node/arbos-releases/overview","domain":"docs.arbitrum.io","title":"ArbOS software releases: Overview | Arbitrum Docs","text":"✏️Request an updateinfoThis document provides an overview of Nitro node software releases that upgrade ArbOS. Visit the Nitro Github repository for a detailed index of Nitro releases.\nArbitrum chains are powered by Arbitrum nodes running the Nitro software stack. The Nitro software stack includes ArbOS, the child chain EVM hypervisor that facilitates the execution environment of an Arbitrum chain.\nAlthough new Nitro releases are shipped regularly, only a subset of Nitro releases carry ArbOS upgrades. These special Nitro releases are significant because ArbOS upgrades are Arbitrum's equivalent to a \"hard fork\"—an upgrade that alters a node's ability to produce valid Arbitrum blocks. This is why validator nodes supporting a public Arbitrum chain (One, Nova) must update Nitro whenever a new ArbOS version is released and voted for adoption by the ArbitrumDAO.\nnoteEvery Nitro release is backwards compatible. In other words, the latest version of Nitro will support all previous ArbOS releases. This means that your validator's Nitro version must be greater than or equal to the version that includes the latest ArbOS upgrade.\n\nHow often should I be upgrading my ArbOS version?It is strongly recommended to keep your Nitro's node software up-to-date as best you can to ensure you are benefting from the latest improvements to the Arbitrum technology stack. ArbOS version bumps are especially important because these upgrades change how Arbitrum nodes produce and validate assertions on a rollup's state.\nArbOS upgrades are carried out by the chain's owner; in the case of Arbitrum One and Nova, the owner is the Arbitrum DAO and so an upgrade will require a governance proposal and vote to pass to complete the upgrade. This is an example of a Nitro release that contains an ArbOS version bump, specifically to ArbOS 11.\nVisit How Arbitrum works to learn more about Nitro's architecture; more information about ArbOS software releases is available on the Arbitrum DAO forum.\nList of available ArbOS releases​\n\nElara (ArbOS 61)\nDia (ArbOS 51)\nCallisto (ArbOS 40)\nBianca (ArbOS 32)\nAtlas (ArbOS 20)\nArbOS 11\n\nNaming and numbering scheme​\nBeginning with ArbOS 20, ArbOS releases use the name of planetary moons in our solar system, ascending in alphabetical order (i.e., the next ArbOS upgrade after ArbOS 20 \"Atlas\" will be a planetary moon that begins with the letter \"B\").\nThe number used to denote each upgrade will increment by 10, starting from ArbOS 20 (i.e., the next ArbOS upgrade after ArbOS 20 will be ArbOS 31). This was done because there are teams who have customized their Arbitrum chain's behavior or precompiles and who may wish to use ArbOS's naming schema between official ArbOS version bumps (e.g., ArbOS 12 could be the name of a customized version of ArbOS for a project's L3 Arbitrum chain).\nNote that there may be cases where special optimizations or critical fixes are needed for a specific family of ArbOS releases that will diverge from the standard numbering scheme described above. For example, ArbOS 32 will be the canonical ArbOS version for the “Bianca” family of releases. Node operators and chain owners are expected to upgrade from ArbOS 20 directly to ArbOS 32 (instead of ArbOS 30 or ArbOS 31).\nNetwork status​\nTo view the status and timeline of network upgrades on Arbitrum One and Nova, please visit this page.\nExpectations for Arbitrum chain owners​\nFor Arbitrum chain owners or maintainers: it is important to note that before upgrading your Arbitrum chain(s) to the newest ArbOS release, we strongly encourage waiting at least four weeks after the new ArbOS release becomes active on Arbitrum One and Nova before attempting the upgrade yourself. The rationale behind this short time buffer is to allow the Offchain Labs team to address any upgrade issues or stability concerns that may arise with the initial rollout so that we can minimize the chances of your chain(s) hitting the same or similar issues and to maximize the likelihood of a smooth upgrade. Arbitrum chains, as always, can pick up new features and enable new customizations as they see fit. However, this delay ensures a consistent user experience (UX) across all Arbitrum chain owners and managers for these critical upgrades.\nEnabling an ArbOS upgrade isn't as simple as bumping your chain's Nitro node version. Instead, there are other steps required that are outlined in our docs on How to upgrade ArbOS on your Arbitrum chain. Be sure to follow them and let us know if you encounter any issues.\nStay up to date​\nTo stay up to date with proposals, timelines, and statuses of network upgrades to Arbitrum One and Nova:\n\nSubscribe to the Arbitrum Node Upgrade Announcement channel on Telegram\nJoin both the #dev-announcements and #node-runners Discord channels in the Arbitrum Discord server\nFollow the official Arbitrum (@Arbitrum) and Arbitrum Developers (@ArbitrumDevs) X accounts, formerly Twitter.\nList of available ArbOS releasesNaming and numbering schemeNetwork statusExpectations for Arbitrum chain ownersStay up to date","tokens":1261,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260842141,"hash":"7a2b07854664a44d56b7af7d5f79d649ef94f061"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/41","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 40 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by soispoke on May 20, 2025\n\n soispoke\n\nProbably not the most interesting thing but just to make sure we’re on the same page, FOCIL is definitely not opt-in in its current form. You’d have to modify client code if you didn’t want to participate in building ILs according the inclusion rules chosen by clients\n\nOk I see, so only basic ´nonce´ and ´balance´ checks, and then if other more complicated interactions (e.g., an IL transaction is invalidated by another “balance emptying” transaction included by the block producer before in the payload) invalidate transactions they can still be included in ILs but if specific mempools are responsible for too many invalid txns they become blacklisted, got it!\nA few thoughts:\n\nI like the idea because of the flexibility it would give but asking each node to keep track of many different mempool and blacklist them sounds a bit messy and might open some attack vectors (wouldn’t an attacker be able to just spin up new mempools whenever one gets blacklisted?)\n\nOne thing that can help is to play around with mempool rules, like enforcing at most N pending full AA transaction per address (this is how we deal with 7702 txns atm) so we limit IL flooding.\n\nMaybe one thing to consider is how much of a spectrum would we really see between nodes. To me FOCIL nodes can:\n\nStore validity-only state and either:\n\nOptimistically include full AA txns in ILs\nDecide to include full AA txns only if they come with witnesses attached, or not to include full AA txns in their ILs at all\n\nStore the full state and include all txns valid against the pre-state\n\nThis leads to two small qs:\n\nIn case FOCIL nodes only store validity-only state and optimistically include full AA txns, how do we deal with attackers spamming all mempools at the same time (at no cost because these txns will be invalidated anyways), what are examples of custom validation rules that could help with this? Maybe more of a q for @yoavw here\nDo you think in practice we would see a lot of FOCIL nodes store validity-only state + some state related to specific applications they care about? Or is it more of a binary (validation-only or full state) thing?\n\nNote: If we use BALs with post-values txns + nonce and balance checks, attesters can perform static validation and vote for a block with full AA txns without having to wait for the full execution (h/t Francesco and Toni) so I think everything works out for attesters in any case, which is nice.\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n Load more posts below","tokens":5295,"squid":"ink-research","role":"Deep Scholar","at":1791260843784,"hash":"360e5da49b4252a45bdcd27da2fa67224806e3ac"}
{"url":"https://ethereum.org/en/history/","domain":"ethereum.org","title":"Timeline of all Ethereum forks (2014 to present) | ethereum.org","text":"Edit page (opens in a new tab)A timeline of all the major milestones, forks, and updates to the Ethereum blockchain.\nForks are when major technical upgrades or changes need to be made to the network – they typically stem from Ethereum Improvement Proposals (EIPs) and change the \"rules\" of the protocol.When upgrades are needed in traditional, centrally-controlled software, the company will just publish a new version for the end-user. Blockchains work differently because there is no central ownership. Ethereum clients must update their software to implement the new fork rules. Plus block creators (miners in a proof-of-work world, validators in a proof-of-stake world) and nodes must create blocks and validate against the new rules. More on consensus mechanismsThese rule changes may create a temporary split in the network. New blocks could be produced according to the new rules or the old ones. Forks are usually agreed upon ahead of time so that clients adopt the changes in unison and the fork with the upgrades becomes the main chain. However, in rare cases, disagreements over forks can cause the network to permanently split – most notably the creation of Ethereum Classic with the DAO fork.\nThe software that underlies Ethereum is composed of two halves, known as the and the .Execution upgrade namingSince 2021, upgrades to the execution layer are named according to the city names of previous Devcon and Devconnect locations (opens in a new tab) in chronological order:Upgrade NameDevcon(nect) YearDevcon NumberUpgrade DateBerlin20140Apr 15, 2021London2015IAug 5, 2021Shanghai2016IIApr 12, 2023Cancun2017IIIMar 13, 2024Prague2018IVMay 7, 2025Osaka2019VDec 3, 2025Amsterdam2022DevconnectTBD - NextBogotá2022VITBDIstanbul2023DevconnectTBDBangkok2024VIITBDBuenos Aires2025DevconnectTBDMumbai2026VIIITBDConsensus upgrade namingSince the launch of the , upgrades to the consensus layer are named after celestial stars beginning with letters that proceed in alphabetical order:Upgrade NameUpgrade DateBeacon Chain genesisDec 1, 2020Altair (opens in a new tab)Oct 27, 2021Bellatrix (opens in a new tab)Sep 6, 2022Capella (opens in a new tab)Apr 12, 2023Deneb (opens in a new tab)Mar 13, 2024Electra (opens in a new tab)May 7, 2025Fulu (opens in a new tab)Dec 3, 2025Gloas (opens in a new tab)TBD - NextHeze (opens in a new tab)TBDCombined namingThe execution and consensus upgrades were initially rolled out at different times, but after The Merge in 2022 these have been deployed simultaneously. As-such, colloquial terms have emerged to simplify references to these upgrades using a single conjoined term. This began with the Shanghai-Capella upgrade, commonly referred to as \"Shapella\", and is continued with subsequent upgrades.Execution UpgradeConsensus UpgradeShort NameShanghaiCapella\"Shapella\"CancunDeneb\"Dencun\"PragueElectra\"Pectra\"OsakaFulu\"Fusaka\"AmsterdamGloas\"Glamsterdam\"BogotáHeze\"Hegotá\"\nSkip straight to information about some of the particularly important past upgrades: The Beacon Chain; The Merge; and EIP-1559\nLooking for future protocol upgrades? Learn about upcoming upgrades on the Ethereum roadmap.\n\n2025\nFulu-Osaka (\"Fusaka\")\nDec 3, 2025, 9:49:11 PM UTCBlock number: 23,935,694 (opens in a new tab)Epoch number: 411,392 (opens in a new tab)Slot number: 13,164,544 (opens in a new tab)ETH price: $3,149.00ethereum.org on waybackmachine (opens in a new tab)\nMore on Fusaka\nPrague-Electra (\"Pectra\")\nMay 7, 2025, 10:05:11 AM UTCBlock number: 22,431,084 (opens in a new tab)Epoch number: 364,032 (opens in a new tab)Slot number: 11,649,024 (opens in a new tab)ETH price: $2,222.00ethereum.org on waybackmachine (opens in a new tab)\nThe Prague-Electra (\"Pectra\") upgrade included several improvements to the Ethereum protocol aimed at enhancing the experience for all users, layer 2 networks, stakers and node operators.\nStaking got an upgrade with compounding validator accounts, and improved control over staked funds using the execution withdrawal address. EIP-7251 increased the max effective balance for a single validator to 2048, improving capital efficiency for stakers. EIP-7002 enabled an execution account to securely trigger validator actions, including exiting, or withdrawing portions of the funds, improving the experience for ETH stakers, while helping strengthen accountability for node operators.\nOther parts of the upgrade focused on improving the experience for regular users. EIP-7702 brought the ability for a regular non-smart-contract account () to execute code similar to a smart contract. This unlocked unbounded new functionality for traditional Ethereum accounts, such as transaction batching, gas sponsorship, alternative authentication, programmable spending controls, account recovery mechanisms and more.\nBetter user experience:EIP-7702 - Set EOA account codeEIP-7691 - Blob throughput increaseEIP-7623 - Increase calldata costEIP-7840 - Add blob schedule to EL config filesBetter staking experience:EIP-7251 - Increase the MAX_EFFECTIVE_BALANCEEIP-7002 - Execution layer triggerable exitsEIP-7685 - General purpose execution layer requestsEIP-6110 - Supply validator deposits on chainProtocol efficiency and security improvements:EIP-2537 - Precompile for BLS12-381 curve operationsEIP-2935 - Save historical block hashes in stateEIP-7549 - Move committee index outside Attestation\n\nHow Pectra will enhance the staking experience (opens in a new tab)\nRead the Electra upgrade specifications (opens in a new tab)\nPrague-Electra (\"Pectra\") FAQ\n\n2024\nCancun-Deneb (\"Dencun\")\nMar 13, 2024, 1:55:35 PM UTCBlock number: 19,426,587 (opens in a new tab)Epoch number: 269,568 (opens in a new tab)Slot number: 8,626,176 (opens in a new tab)ETH price: $3,984.00ethereum.org on waybackmachine (opens in a new tab)\nCancun summary\nThe Cancun upgrade contains a set of improvements to Ethereum's execution aimed towards improving scalability, in tandem with the Deneb consensus upgrades.\nNotably this includes EIP-4844, known as Proto-Danksharding, which significantly decreases the cost of data storage for layer 2 rollups. This is achieved through the introduction of data \"blobs\" which enables rollups to post data to Mainnet for a short period of time. This results in significantly lower transaction fees for users of layer 2 rollups.\nEIP-1153 - Transient storage opcodesEIP-4788 - Beacon block root in the EVMEIP-4844 - Shard blob transactions (Proto-Danksharding)EIP-5656 - MCOPY - Memory copying instructionEIP-6780 - SELFDESTRUCT only in same transactionEIP-7516 - BLOBBASEFEE opcode\n\nLayer 2 rollups\nProto-Danksharding\nDanksharding\nRead the Cancun upgrade specification (opens in a new tab)\n\nDeneb summary\nThe Deneb upgrade contains a set of improvements to Ethereum's consensus aimed towards improving scalability. This upgrade comes in tandem with the Cancun execution upgrades to enable Proto-Danksharding (EIP-4844), along with other improvements to the Beacon Chain.\nPre-generated signed \"voluntary exit messages\" no longer expire, thus giving more control to users staking their funds with a third-party node operator. With this signed exit message, stakers can delegate node operation while maintaining the ability to safely exit and withdraw their funds at any time, without needing to ask permission from anyone.\nEIP-7514 brings a tightening to the issuance of ETH by capping the \"churn\" rate that validators can join the network to eight (8) per epoch. Since ETH issuance is proportional to total ETH staked, limiting the number of validators joining caps the growth rate of newly issued ETH, while also reducing hardware requirements for node operators, helping decentralization.\nEIP-4788 - Beacon block root in the EVMEIP-4844 - Shard blob transactionsEIP-7044 - Perpetually valid signed voluntary exitsEIP-7045 - Increase max attestation inclusion slotEIP-7514 - Add max epoch churn limit\n\nRead the Deneb upgrade specifications (opens in a new tab)\nCancun-Deneb (\"Dencun\") FAQ\n\n2023\nShanghai-Capella (\"Shapella\")\nApr 12, 2023, 10:27:35 PM UTCBlock number: 17,034,870 (opens in a new tab)Epoch number: 194,048 (opens in a new tab)Slot number: 6,209,536 (opens in a new tab)ETH price: $1,917.00ethereum.org on waybackmachine (opens in a new tab)\nShanghai summary\nThe Shanghai upgrade brought staking withdrawals to the execution layer. In tandem with the Capella upgrade, this enabled blocks to accept withdrawal operations, which allows stakers to withdraw their ETH from the Beacon Chain to the execution layer.\nEIP-3651 – Starts the COINBASE address warmEIP-3855 – New PUSH0 instructionEIP-3860 – Limit and meter initcodeEIP-4895 – Beacon chain push withdrawals as operationsEIP-6049 - Deprecate SELFDESTRUCT\n\nRead the Shanghai upgrade specification (opens in a new tab)\n\nCapella summary\nThe Capella upgrade was the third major upgrade to the consensus layer (Beacon Chain) and enabled staking withdrawals. Capella occurred synchronously with the execution layer upgrade, Shanghai, and enabled staking withdrawal functionality.\nThis consensus layer upgrade brought the ability for stakers who did not provide withdrawal credentials with their initial deposit to do so, thereby enabling withdrawals.\nThe upgrade also provided automatic account sweeping functionality, which continuously processes validator accounts for any available rewards payments or full withdrawals.\n\nMore on staking withdrawals.\nRead the Capella upgrade specifications (opens in a new tab)\n\n2022\nParis (The Merge)\nSep 15, 2022, 6:42:42 AM UTCBlock number: 15,537,394 (opens in a new tab)ETH price: $1,472.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Paris upgrade was triggered by the proof-of-work blockchain passing a of 58750000000000000000000. This happened at block 15537393 on 15th September 2022, triggering the Paris upgrade the next block. Paris was The Merge transition - its major feature was switching off the proof-of-work mining algorithm and associated consensus logic and switching on proof-of-stake instead. Paris itself was an upgrade to the execution clients (equivalent to Bellatrix on the consensus layer) that enabled them to take instruction from their connected consensus clients. This required a new set of internal API methods, collectively known as the Engine API (opens in a new tab), to be activated. This was arguably the most significant upgrade in Ethereum history since Homestead!\n\nRead the Paris upgrade specification (opens in a new tab)\n\nEIP-3675 – Upgrade consensus to Proof-of-StakeEIP-4399 – Supplant DIFFICULTY opcode with PREVRANDAO\n\nBellatrix\nSep 6, 2022, 11:34:47 AM UTCEpoch number: 144,896 (opens in a new tab)ETH price: $1,558.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Bellatrix upgrade was the second scheduled upgrade for the Beacon Chain, preparing the chain for The Merge. It brings validator penalties to their full values for inactivity and slashable offenses. Bellatrix also includes an update to the fork choice rules to prepare the chain for The Merge and the transition from the last proof-of-work block to the first proof-of-stake block. This includes making consensus clients aware of the of 58750000000000000000000.\n\nRead the Bellatrix upgrade specification (opens in a new tab)\n\nGray Glacier\nJun 30, 2022, 10:54:04 AM UTCBlock number: 15,050,000 (opens in a new tab)ETH price: $1,069.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Gray Glacier network upgrade pushed back the by three months. This is the only change introduced in this upgrade, and is similar in nature to the Arrow Glacier and Muir Glacier upgrades. Similar changes have been performed on the Byzantium, Constantinople and London network upgrades.\n\nEF Blog - Gray Glacier Upgrade Announcement (opens in a new tab)\n\nEIP-5133 – delays the difficulty bomb until September 2022\n\n2021\nArrow Glacier\nDec 9, 2021, 7:55:23 PM UTCBlock number: 13,773,000 (opens in a new tab)ETH price: $4,111.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Arrow Glacier network upgrade pushed back the by several months. This is the only change introduced in this upgrade, and is similar in nature to the Muir Glacier upgrade. Similar changes have been performed on the Byzantium, Constantinople and London network upgrades.\n\nEF Blog - Arrow Glacier Upgrade Announcement (opens in a new tab)\nEthereum Cat Herders - Ethereum Arrow Glacier Upgrade (opens in a new tab)\n\nEIP-4345 – delays the difficulty bomb until June 2022\n\nAltair\nOct 27, 2021, 10:56:23 AM UTCEpoch number: 74,240 (opens in a new tab)ETH price: $4,024.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Altair upgrade was the first scheduled upgrade for the Beacon Chain. It added support for \"sync committees\"—enabling light clients, and increased validator inactivity and slashing penalties as development progressed towards The Merge.\n\nRead the Altair upgrade specification (opens in a new tab)\n\n Fun fact!\nAltair was the first major network upgrade that had an exact rollout time. Every upgrade prior had been based on a declared block number on the proof-of-work chain, where block times vary. The Beacon Chain does not require solving for proof-of-work, and instead works on a time-based epoch system consisting of 32 twelve-second \"slots\" of time where validators can propose blocks. This is why we knew exactly when we would hit epoch 74,240 and Altair became live!\n\nBlock time\n\nLondon\nAug 5, 2021, 12:33:42 PM UTCBlock number: 12,965,000 (opens in a new tab)ETH price: $2,621.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe London upgrade introduced EIP-1559 (opens in a new tab), which reformed the transaction fee market, along with changes to how gas refunds are handled and the schedule.\nWhat was the London Upgrade / EIP-1559?\nBefore the London Upgrade, Ethereum had fixed-sized blocks. In times of high network demand, these blocks operated at full capacity. As a result, users often had to wait for demand to reduce to get included in a block, which led to a poor user experience. The London Upgrade introduced variable-sized blocks to Ethereum.\nThe way transaction fees on the Ethereum network were calculated changed with the London Upgrade of August 2021. Before the London upgrade, fees were calculated without separating base and priority fees, as follows:\nLet's say Alice had to pay Bob 1 ETH. In the transaction, the gas limit is 21,000 units, and the gas price is 200 gwei.\nThe total fee would have been: Gas units (limit) * Gas price per unit i.e 21,000 * 200 = 4,200,000 gwei or 0.0042 ETH\nThe implementation of EIP-1559 (opens in a new tab) in the London Upgrade made the transaction fee mechanism more complex, but made gas fees more predictable, resulting in a more efficient transaction fee market. Users can submit transactions with a maxFeePerGas corresponding to how much they are willing to pay for the transaction to be executed, knowing that they will not pay more than the market price for gas (baseFeePerGas), and get any extra, minus their tip, refunded.\nThis video explains EIP-1559 and the benefits it brings: EIP-1559 Explained (opens in a new tab)\n\nAre you a dapp developer? Be sure to upgrade your libraries and tooling. (opens in a new tab)\nRead the Ethereum Foundation announcement (opens in a new tab)\nRead the Ethereum Cat Herder's explainer (opens in a new tab)\n\nEIP-1559 – improves the transaction fee marketEIP-3198 – returns the BASEFEE from a blockEIP-3529 - reduces gas refunds for EVM operationsEIP-3541 - prevents deploying contracts starting with 0xEFEIP-3554 – delays the Ice Age until December 2021\n\nBerlin\nApr 15, 2021, 10:07:03 AM UTCBlock number: 12,244,000 (opens in a new tab)ETH price: $2,454.00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Berlin upgrade optimized gas cost for certain EVM actions, and increases support for multiple transaction types.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nRead the Ethereum Cat Herder's explainer (opens in a new tab)\n\nEIP-2565 – lowers ModExp gas costEIP-2718 – enables easier support for multiple transaction typesEIP-2929 – gas cost increases for state access opcodesEIP-2930 – adds optional access lists\n\n2020\nBeacon Chain genesis\nDec 1, 2020, 12:00:23 PM UTC0ETH price: $586.23ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Beacon Chain needed 16384 deposits of 32 staked ETH to ship securely. This happened on November 27, and the Beacon Chain started producing blocks on December 1, 2020.\nRead the Ethereum Foundation announcement (opens in a new tab)\nThe Beacon Chain\n\nStaking deposit contract deployed\nOct 14, 2020, 9:22:52 AM UTCBlock number: 11,052,984 (opens in a new tab)ETH price: $379.04ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe staking deposit contract introduced to the Ethereum ecosystem. Although a contract, it had a direct impact on the timeline for launching the Beacon Chain, an important Ethereum upgrade.\nRead the Ethereum Foundation announcement (opens in a new tab)\nStaking\n\nMuir Glacier\nJan 2, 2020, 8:30:49 AM UTCBlock number: 9,200,000 (opens in a new tab)ETH price: $127.18ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Muir Glacier fork introduced a delay to the . Increases in block difficulty of the proof-of-work consensus mechanism threatened to degrade the usability of Ethereum by increasing wait times for sending transactions and using dapps.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nRead the Ethereum Cat Herder's explainer (opens in a new tab)\n\nEIP-2384 – delays the difficulty bomb for another 4,000,000 blocks, or ~611 days.\n\n2019\nIstanbul\nDec 8, 2019, 12:25:09 AM UTCBlock number: 9,069,000 (opens in a new tab)ETH price: $151.06ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Istanbul fork:\n\nOptimised the cost of certain actions in the EVM.\nImproved denial-of-service attack resilience.\nMade Layer 2 scaling solutions based on SNARKs and STARKs more performant.\nEnabled Ethereum and Zcash to interoperate.\nAllowed contracts to introduce more creative functions.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nEIP-152 – allow Ethereum to work with privacy-preserving currency like Zcash.EIP-1108 – cheaper cryptography to improve costs.EIP-1344 – protects Ethereum against replay attacks by adding CHAINID opcode.EIP-1884 – optimising opcode gas prices based on consumption.EIP-2028 – reduces the cost of CallData to allow more data in blocks – good for Layer 2 scaling.EIP-2200 – other opcode gas price alterations.\n\nConstantinople\nFeb 28, 2019, 7:52:04 PM UTCBlock number: 7,280,000 (opens in a new tab)ETH price: $136.29ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Constantinople fork:\n\nReduced block mining rewards from 3 to 2 ETH.\nEnsured the blockchain didn't freeze before proof-of-stake was implemented.\nOptimised the cost of certain actions in the EVM.\nAdded the ability to interact with addresses that haven't been created yet.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nEIP-145 – optimises cost of certain onchain actions.EIP-1014 – allows you to interact with addresses that have yet to be created.EIP-1052 – introduces the EXTCODEHASH instruction to retrieve the hash of another contract's code.EIP-1234 – makes sure the blockchain doesn't freeze before proof-of-stake and reduces block reward from 3 to 2 ETH.\n\n2017\nByzantium\nOct 16, 2017, 5:22:11 AM UTCBlock number: 4,370,000 (opens in a new tab)ETH price: $334.23ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Byzantium fork:\n\nReduced block mining rewards from 5 to 3 ETH.\nDelayed the by a year.\nAdded ability to make non-state-changing calls to other contracts.\nAdded certain cryptography methods to allow for layer 2 scaling.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nEIP-140 – adds REVERT opcode.EIP-658 – status field added to transaction receipts to indicate success or failure.EIP-196 – adds elliptic curve and scalar multiplication to allow for ZK-Snarks.EIP-197 – adds elliptic curve and scalar multiplication to allow for ZK-Snarks.EIP-198 – enables RSA signature verification.EIP-211 – adds support for variable length return values.EIP-214 – adds STATICCALL opcode, allowing non-state-changing calls to other contracts.EIP-100 – changes difficulty adjustment formula.EIP-649 – delays by 1 year and reduces block reward from 5 to 3 ETH.\n\n2016\nSpurious Dragon\nNov 22, 2016, 4:15:44 PM UTCBlock number: 2,675,000 (opens in a new tab)ETH price: $9.84ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Spurious Dragon fork was the second response to the denial of service (DoS) attacks on the network (September/October 2016) including:\n\ntuning opcode pricing to prevent future attacks on the network.\nenabling “debloat” of the blockchain state.\nadding replay attack protection.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nEIP-155 – prevents transactions from one Ethereum chain from being rebroadcasted on an alternative chain, for example a testnet transaction being replayed on the main Ethereum chain.EIP-160 – adjusts prices of EXP opcode – makes it more difficult to slow down the network via computationally expensive contract operations.EIP-161 – allows for removal of empty accounts added via the DOS attacks.EIP-170 – changes the maximum code size that a contract on the blockchain can have – to 24576 bytes.\n\nTangerine whistle\nOct 18, 2016, 1:19:31 PM UTCBlock number: 2,463,000 (opens in a new tab)ETH price: $12.50ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Tangerine Whistle fork was the first response to the denial of service (DoS) attacks on the network (September/October 2016) including:\n\naddressing urgent network health issues concerning underpriced operation codes.\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nEIP-150 – increases gas costs of opcodes that can be used in spam attacks.EIP-158 – reduces state size by removing a large number of empty accounts that were put in the state at very low cost due to flaws in earlier versions of the Ethereum protocol.\n\nDAO fork\nJul 20, 2016, 1:20:40 PM UTCBlock number: 1,920,000 (opens in a new tab)ETH price: $12.54ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe DAO fork was in response to the 2016 DAO attack (opens in a new tab) where an insecure contract was drained of over 3.6 million ETH in a hack. The fork moved the funds from the faulty contract to a new contract (opens in a new tab) with a single function: withdraw. Anyone who lost funds could withdraw 1 ETH for every 100 DAO tokens in their wallets.\nThis course of action was voted on by the Ethereum community. Any ETH holder was able to vote via a transaction on a voting platform (opens in a new tab). The decision to fork reached over 85% of the votes.\nSome miners refused to fork because the DAO incident wasn't a defect in the protocol. They went on to form Ethereum Classic (opens in a new tab).\nRead the Ethereum Foundation announcement (opens in a new tab)\n\nHomestead\nMar 14, 2016, 6:49:53 PM UTCBlock number: 1,150,000 (opens in a new tab)ETH price: $12.50ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe Homestead fork that looked to the future. It included several protocol changes and a networking change that gave Ethereum the ability to do further network upgrades.\nRead the Ethereum Foundation announcement (opens in a new tab)\nEIP-2 – makes edits to contract creation process.EIP-7 – adds new opcode: DELEGATECALLEIP-8 – introduces devp2p forward compatibility requirements\n\n2015\nFrontier thawing\nSep 7, 2015, 9:33:09 PM UTCBlock number: 200,000 (opens in a new tab)ETH price: $1.24ethereum.org on waybackmachine (opens in a new tab)\nSummary\nThe frontier thawing fork lifted the 5,000 limit per and set the default gas price to 51 . This allowed for transactions – transactions require 21,000 gas. The was introduced to ensure a future hard-fork to .\n\nRead the Ethereum Foundation announcement (opens in a new tab)\nRead the Ethereum Protocol Update 1 (opens in a new tab)\n\nFrontier\nJul 30, 2015, 3:26:13 PM UTC00ethereum.org on waybackmachine (opens in a new tab)\nSummary\nFrontier was a live, but barebone implementation of the Ethereum project. It followed the successful Olympic testing phase. It was intended for technical users, specifically developers. had a limit of 5,000. This ‘thawing’ period enabled miners to start their operations and for early adopters to install their clients without having to ‘rush’.\nRead the Ethereum Foundation announcement (opens in a new tab)\n\n2014\nEther sale\nJul 22, 2014, 12:00:00 AM UTC00ethereum.org on waybackmachine (opens in a new tab)\nEther officially went on sale for 42 days. You could buy it with BTC.\nRead the Ethereum Foundation announcement (opens in a new tab)\n\nYellowpaper released\nApr 1, 2014, 12:00:00 AM UTC00ethereum.org on waybackmachine (opens in a new tab)\nThe Yellow Paper, authored by Dr. Gavin Wood, is a technical definition of the Ethereum protocol.\nView the Yellow Paper (opens in a new tab)\n\n2013\nWhitepaper released\nNov 27, 2013, 12:00:00 AM UTC00ethereum.org on waybackmachine (opens in a new tab)\nThe introductory paper, published in 2013 by Vitalik Buterin, the founder of Ethereum, before the project's launch in 2015.\nWhitepaper","tokens":6335,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260852447,"hash":"dc439ba976deffc617baf173d075770284039d48"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/43","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 42 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791260854022,"hash":"960eab0e1cf5eae2932e0d31973c7c8a397e6da3"}
{"url":"https://specs.optimism.io/","domain":"specs.optimism.io","title":"Introduction - OP Stack Specification","text":"OP Stack Specification\n\nTable of Contents\n\nAbout Optimism\nAbout the OP Stack\nSite Navigation\n\nAbout Optimism\nOptimism is a project dedicated to scaling Ethereum's technology and expanding its ability to\ncoordinate people from across the world to build effective decentralized economies and governance systems. The\nOptimism Collective builds open-source software that powers scalable blockchains and\naims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the\nprinciple of impact=profit, the idea that individuals who positively impact the Collective should be proportionally\nrewarded with profit.\nChange the incentives and you change the world.\nAbout the OP Stack\nThe OP Stack is a decentralized software stack maintained by the OP Stack that forms the backbone of blockchains like\nOP Mainnet and Base. The OP Stack is designed to be aggressively\nopen-source — you are welcome to explore, modify, and extend the OP Stack to your heart's content.\nSite Navigation\nNavigate this site using the sidebar on the left, the search icon found at the top of this page, or the left/right\nnavigation buttons found to the sides of each page.","tokens":295,"squid":"ink-governance","role":"Council Listener","at":1791260868068,"hash":"fee8bf00c93770df5eb3a3949e3c237b2de01ca2"}
{"url":"https://ethereum.org/roadmap/","domain":"ethereum.org","title":"Ethereum roadmap | ⁦ethereum.org⁩","text":"In productionParis (The Merge)September 15, 2022In productionShapellaApril 12, 2023In productionDencunMarch 13, 2024In productionPectraMay 7, 2025In productionFusakaDecember 3, 2025In developmentGlamsterdamQ4 2026In developmentHegotá2027Paris (The Merge)September 15, 2022Main featuresTransition to Proof of StakeReplaced energy-intensive mining with staking-based consensusReduced Ethereum's energy consumption by ~99.95%Beacon Chain IntegrationMerged the Beacon Chain with the Ethereum mainnetEnabled the full transition to PoS consensus mechanismDifficulty Bomb RemovalRemoved the difficulty bomb that was increasing mining difficultyEnsured smooth transition to the new consensus mechanismLearn moreShapellaApril 12, 2023Main featuresStaking withdrawalsEnabled validators to withdraw their staked ETH and rewardsIntroduced partial and full withdrawal capabilitiesEIP-4895: Beacon chain push withdrawalsAdded a new system-level operation for withdrawalsEnsured secure and efficient processing of withdrawal requestsEIP-3651: Warm COINBASEReduced gas costs for accessing the COINBASE addressImproved efficiency of certain smart contract operationsLearn moreDencunMarch 13, 2024Main featuresProto-danksharding (EIP-4844)Introduced blob transactions to significantly reduce rollup transaction costsAdded a new transaction type that stores data temporarily and cheaplyEIP-1153: Transient storage opcodesAdded TSTORE and TLOAD opcodes for temporary storage during transaction executionEnables more efficient smart contract patterns and reduces gas costsEIP-4788: Beacon block root in the EVMExposes consensus layer information to smart contractsEnables new trust-minimized applications and cross-chain bridgesLearn morePectraMay 7, 2025Main featuresEnhance EOA wallets with smart contract functionalityUsers can set their address to be represented by a code of an existing smart contract and gain benefits such as transaction batching, transaction fee sponsorship or better recovery mechanismsIncrease the max effective balanceStakers can now hold up to 2048 ETH in one validator instead of exactly 32, earning rewards on every ETH above the minimumBlob throughput increaseRaised the blob target to 6 per block with a maximum of 9, making transactions on rollups cheaperLearn moreTrack changes (opens in a new tab)FusakaDecember 3, 2025Main featuresPeerDAS (Peer-to-Peer Data Availability Sampling)Enables more efficient data availability for rollupsMakes running a node more accessible while maintaining decentralizationBlob Parameter Only (BPO) ForksAllows flexible blob count increases between major upgradesEnables faster adaptation to L2 scaling needs without waiting for coordinated hard forksGas Limit & DoS HardeningTransaction gas limit cap of 16.7M gas per transactionRaised the default gas limit to 60M, increasing L1 execution capacityLearn moreTrack changes (opens in a new tab)GlamsterdamQ4 2026Main featuresEnshrined proposer-builder separationSeparates block agreement from processing, helping L1 scale by allowing validators to process more dataNatively integrates builders so validators can safely outsource block assembly without trusting external softwareBlock-level access listsIntroduces mandatory access lists at the block level, rather than for individual transactionsMaps dependencies upfront for faster syncs, parallel execution, and parallel disk readsLowers gas for state-heavy apps and improves gas cost predictabilityLearn moreTrack changes (opens in a new tab)Hegotá2027Main featuresFork-choice enforced inclusion lists (FOCIL)Lets a committee of validators require that valid transactions are included, so no single block builder can leave them outDecouples censorship resistance from local block building, removing a constraint on scaling L1Strengthens layer 2 settlement guarantees, which can shorten exit windows for optimistic rollupsFrame transactionsAdds a transaction type where the account itself decides what makes a transaction valid, rather than one fixed signature schemeMakes social recovery, spending limits and sponsored gas native to the protocol instead of bolted onGives accounts a path to post-quantum signature schemesScope is not final. These are the changes scheduled so far, and dozens more have been proposed.Learn moreTrack changes (opens in a new tab)What changes are coming to Ethereum?Ethereum is already a powerful platform, but it is still being improved. An ambitious set of improvements will upgrade Ethereum from its current form into a fully scaled, maximally resilient platform.Cheaper transactionsUpgrades to Ethereum and its rollups are adding capacity to the network, making transactions cheaper and faster for everyone.More on scalingExtra securityEthereum is already very secure but it can be made even stronger, ready to withstand all kinds of attack far into the future.More on securityBetter user experienceMore support for smart contract wallets and light-weight nodes will make using Ethereum simpler and safer.More on UXPrivacy by defaultPrivacy on Ethereum is moving from an optional add-on to a network-level default, with upgrades that protect what users read, send, and prove onchain.More on privacyWhy does Ethereum need a roadmap?Ethereum gets regular upgrades that enhance its scalability, security, or sustainability. One of Ethereum's core strengths is adapting as new ideas emerge from research and development. Adaptability gives Ethereum the flexibility to tackle emerging challenges and keep up with the most advanced technological breakthroughs.How the roadmap is definedThe roadmap is mostly the result of years of work by researchers and developers - because the protocol is very technical - but any motivated person can participate.Ideas usually start off as discussions on a forum such as ethresear.ch (opens in a new tab), Ethereum Magicians (opens in a new tab) or the Eth R&D discord server. They may be responses to new vulnerabilities that are discovered, suggestions from organizations working in the application layer (such as dapps and exchanges) or from known frictions for end users (such as costs or transaction speeds).When these ideas mature, they can be proposed as Ethereum Improvement Proposals (opens in a new tab). This is all done in public so that anyone from the community can weigh in at any time.More on Ethereum governanceWhat technical upgrades are coming to Ethereum?Post-quantum securityQuantum computers could one day break the cryptography that blockchains rely on. Ethereum's post-quantum upgrades will replace vulnerable algorithms before quantum computing becomes a real threat.Learn moreSingle slot finalityInstead of waiting for fifteen minutes, blocks could get proposed and finalized in the same slot. This is more convenient for apps and difficult to attack.Learn morezkEVMZero-knowledge proofs could allow validators to verify Ethereum blocks without re-executing transactions, enabling higher gas limits without raising hardware requirements.Learn moreStatelessnessStateless clients will be able to verify new blocks without having to store large amounts of data. This will provide all the benefits of running a node with only a tiny fraction of today's costs.Learn moreAccount abstractionAccount abstraction is a class of upgrades that support smart contract wallets natively on Ethereum, rather than having to use complex middleware.Learn moreDankshardingDanksharding makes L2 rollups much cheaper for users by adding \"blobs\" of data to Ethereum blocks.Learn moreWhat is the timeline for these upgrades?Yes—almost definitely. The roadmap is the current plan for upgrading Ethereum, covering both near-term and future plans. We expect the roadmap to change as new information and technology become available.Think of Ethereum's roadmap as a set of intentions for improving Ethereum; it is the core researchers' and developers' best hypothesis of Ethereum's most optimal path forward.Some upgrades are lower priority and likely not to be implemented for the next 5-10 years (e.g. quantum resistance). Giving precise timing of each upgrade is complicated to predict as many roadmap items are worked on in parallel and developed at different speeds. The urgency of an upgrade can also change over time depending on external factors (e.g. a sudden leap in the performance and availability of quantum computers may make quantum-resistant cryptography more urgent).One way to think about Ethereum development is by analogy to biological evolution. A network that is able to adapt to new challenges and maintain fitness is more likely to succeed than one that is resistant to change, although as the network becomes more and more performant, scalable and secure fewer changes to the protocol will be required.Upgrades tend not to impact end-users except by providing better user-experiences and a more secure protocol and perhaps more options for how to interact with Ethereum. Regular users are not required to actively participate in an upgrade, nor are they required to do anything** to secure their assets. Node operators will need to update their clients to prepare for an upgrade. Some upgrades may lead to changes for application developers. For example, history expiry upgrades may lead application developers to grab historical data from new sources.Sharding is splitting up the Ethereum blockchain so that subsets of validators are only responsible for a fraction of the total data. This was originally intended to be the way for Ethereum to scale. However, layer 2 rollups have developed much faster than expected and have provided a lot of scaling already, and will provide much more after Proto-Danksharding is implemented. This means \"shard chains\" are no longer needed and have been dropped from the roadmap.","tokens":2438,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260874435,"hash":"214a11eae2cab7721e90619d4ddea46e8e711071"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/45","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 44 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791260876185,"hash":"e9ee7d37cbfb911d008bf5ce8df8a42c363a5345"}
{"url":"https://institutions.ethereum.org/","domain":"institutions.ethereum.org","title":"Ethereum for Institutions | The Institutional Liquidity Layer","text":"The Institutional Liquidity LayerEthereum is the Backbone of the Onchain EconomyLive Data →0.0 YrsUninterrupted uptime and liveness$0BTotal value securing the network (44.2M ETH)$0BStablecoin TVL51%+ of global supply$0.0BDeFi TVL 65%+ of all blockchains$0.00B24-Hour DEX volume(12-month avg)Institutional Use CasesExplore Ethereum's digital asset landscape, from tokens to technologiesRWAs & StablecoinsReal-world assets tokenize offchain assets, like real estate, commodities, or bonds, while stablecoins design for steady value, often pegged to assets like USD.More on RWAs →Decentralized FinanceOpen financial systems built on smart contracts instead of banks. DeFi lets anyone lend, borrow, trade, and earn yield directly from their wallet.More on DeFi →Privacy & ComplianceDeploy on Ethereum's public Mainnet for global transparency, or use enterprise-grade privacy solutions for confidentiality and control.More on Privacy →L2 EcosystemLayer 2 networks scale Ethereum by processing transactions faster and cheaper.More on L2s →Ethereum Leads Where It MattersResilienceEthereum has maintained 11 Yrs of uninterrupted uptime and liveness since its launch. Zero downtime through 15+ successful network upgrades.FlexibilityOpen source, with complete freedom from lock-in to any single vendor, stack, or architecture. Institutions retain full optionality for their onchain products as business requirements change.Credible NeutralityNo single point of failure, no central coordinator, no pause button, no counterparty risk. Resilient to geopolitical, regulatory, and infrastructure-level risks.Decentralization$119B+ in economic security distributed across geographies and client implementations makes Ethereum the most expensive smart contract platform to attack.Deep Liquidity$1.68B+ in daily DEX volume, the deepest liquidity of any onchain environment. Ethereum is the chosen liquidity layer for institutions to build leading next-gen products.TokenizationThe leading platform for asset tokenization, with 36% of all onchain RWAs deployed on Ethereum and its L2s, and $162B in stablecoin TVL.Market-Proven PlatformInstitutions innovate on EthereumBlackRockOnchain Tokenization via Securitize$736M+ AUMCoinbaseBase Layer 2 Ecosystem$16.2B TVLVisaStablecoin Payment Settlement$1B+ Annual Stablecoin VolumeeToroStock Tokenization Platform100 Stocks Trade 24/5Industry Leaders Choose EthereumI think tokenised real-world assets will grow from $34bn today to $300bn over the next 12 months. All of this growth will happen on Ethereum because TradFi trusts Ethereum.It is irrelevant that other chains are faster or cheaper. Ethereum has been around for over 10 years and has never gone down. For TradFi, trustworthiness trumps marginal speed and cost savings every day of the week.Geoffrey KendrickGlobal Head of Digital Assets Research @ Standard CharteredSaying Ethereum is the wrong blockchain because it has high gas fees is like saying Amazon shouldn't use the internet because dial-up was slow in 1995.Banks aren't building on 2015 Ethereum, they're using today's Ethereum stack with tomorrows upgrades.Tom ZschachCIO @ SWIFTThere was no question that the blockchain that we would start our tokenization on was on Ethereum.Robert MitchnickHead of Digital Assets @ BlackRockI believe tokenization is the greatest capital markets innovation since the central limit order book.The Robinhood Chain is the first Ethereum Layer 2 optimized for real-world assets.Vlad TenevCEO @ RobinhoodEthereum is ScalingEthereum's performance isn't static. The network's active R&D roadmap sets the stage for an infinitely-scalable ecosystem, while Ethereum-based providers globally push throughput boundaries today.Raising mainnet gas limit to 100M/block rapidly increases mainnet TPSLearn more → (opens in a new tab)PeerDAS data availability sampling scales blob capacity, multiplying L2 TPSLearn more → (opens in a new tab)History expiry prunes storage to keep node performance comfortable at scaleLearn more → (opens in a new tab)LibraryLatest updates relevant for institutionsRedStone - Case Study: How Securitize and RedStone Enable DeFi-Ready RWAs on Ethereum (opens in a new tab)February 26, 2026IPTF - Public Rails vs Private Ledgers (opens in a new tab)January 30, 2026Fusaka upgrade: Ethereum is securely scalingDecember 9, 2025View All Resources →","tokens":1086,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260887930,"hash":"4c7183f39e0a34e8001421f6171c23b9ed12730b"}
{"url":"https://ethereum.org/developers/docs/design-and-ux/heuristics-for-web3/","domain":"ethereum.org","title":"7 heuristics for Web3 interface design | ethereum.org","text":"7 heuristics for Web3 interface designEdit page (opens in a new tab)Usability heuristics are broad “rules of thumb” that you can use to measure the usability of your site.\nThe 7 heuristics here are specifically tailored for Web3 and should be used alongside Jakob Nielsen's 10 general principles for interaction design (opens in a new tab).\nSeven usability heuristics for web3\n\nFeedback follows action\nSecurity and trust\nThe most important info is obvious\nUnderstandable terminology\nActions are as short as possible\nNetwork connections are visible and flexible\nControl from the app, not the wallet\n\nDefinitions and examples\n1. Feedback follows action\nIt should be obvious when something has happened, or is happening.\nUsers decide on their next steps based on the outcome of their previous steps. Therefore it is essential that they remain informed about the system status. This is especially important in Web3 as transactions can sometimes take a short time to commit to the blockchain. If there is no feedback informing them to wait, users are unsure if anything has happened.\nTips:\n\nInform the user via messaging, notifications, and other alerts.\nCommunicate waiting times clearly.\nIf an action is going to take longer than a few seconds, reassure the user with a timer or an animation to make them feel like something is happening.\nIf there are multiple steps to a process, show each step.\n\nExample:\nShowing each step involved in a transaction helps users know where they are in the process. Appropriate icons let the user know the status of their actions.\n\n2. Security and trust are baked in\nSecurity should be prioritized, and this should be emphasized for the user.\nPeople care deeply about their data. Safety is often a primary concern for users, so it should be considered at all levels of the design. You should always be seeking to earn the trust of your users, but the way you do this can mean different things on different apps. It should not be an afterthought, but should be designed consciously throughout. Build trust throughout the user experience, including social channels and documentation, as well as the final UI. Things like the level of decentralization, the treasury multi-sig status, and whether the team is doxxed, all affect users' trust\nTips:\n\nList your audits proudly\nGet multiple audits\nAdvertise any safety features that you designed\nHighlight possible risks, including underlying integrations\nCommunicate complexity of strategies\nConsider non-UI issues that might affect your users' perception of safety\n\nExample:\nInclude your audits in the footer, at a prominent size.\n\n3. The most important info is obvious\nFor complex systems, show only the most relevant data. Determine what is most important, and prioritize its display.\nToo much information is overwhelming and users typically anchor on one piece of information when making decisions. In DeFi, this will probably be APR on yield apps and LTV on lending apps.\nTips:\n\nUser research will uncover the most important metric\nMake the key info big, and the other details small and unobtrusive\nPeople don’t read, they scan; ensure your design is scannable\n\nExample: Large tokens in full color are easy to find when scanning. The APR is big and highlighted in an accent color.\n\n4. Clear terminology\nTerminology should be understandable and appropriate.\nTechnical jargon can be a huge blocker, because it requires the construction of a completely new mental model. Users are unable to relate the design to words, phrases and concepts they already know. Everything seems confusing and unfamiliar, and there is a steep learning curve before they can even attempt to use it. A users might approach DeFi wanting to save some money, and what they find is: Mining, farming, staking, emissions, bribes, vaults, lockers, veTokens, vesting, epochs, decentralized algorithms, protocol-owned liquidity…\nTry to use simple terms that will be understood by the broadest group of people. Do not invent brand new terms just for your project.\nTips:\n\nUse simple and consistent terminology\nUse existing language as much as possible\nDon’t come up with your own terms\nFollow conventions as they appear\nEducate users as much as possible\n\nExample:\n“Your rewards” is a broadly understood, neutral, term; not a new word made up for this project. The rewards are denominated in USD to match real world mental models, even if the rewards themselves are in another token.\n\n5. Actions are as short as possible\nSpeed up the user’s interactions by grouping sub actions.\nThis may be done on the smart contract level, as well as the UI. The user should not have to move from one part of the system to another – or leave the system entirely – to complete a common action.\nTips:\n\nCombine \"Approve\" with other actions where possible\nBundle signing steps as close together as possible\n\nExample: Combining “add liquidity” and “stake” is a simple example of an accelerator that saves a user both time and gas.\n\n6. Network connections are visible and flexible\nInform the user about what network they are connected to, and provide clear shortcuts to change network.\nThis is especially important on multichain apps. The main functions of the app should still be visible while disconnected or connected to a non-supported network.\nTips:\n\nShow as much of the app as possible while disconnected\nShow which network the user is currently connected to\nDon’t make the user go to the wallet to change network\nIf the app requires the user to switch network, prompt the action from the main call to action\nIf the app contains markets or vaults for multiple networks, clearly state which set the user is currently looking at\n\nExample: Show the user which network they are connected to, and allow them to change it, in the appbar.\n\n7. Control from the app, not the wallet\nThe UI should tell the user everything they need to know and give them control over everything they need to do.\nIn Web3, there are actions you take in the UI, and actions you take in the wallet. Generally, you initiate an action in the UI, and then confirm it in the wallet. Users can feel uncomfortable if these two strands are not integrated carefully.\nTips:\n\nCommunicate system status via feedback in the UI\nKeep a record of their history\nProvide links to block explorers for old transactions\nProvide shortcuts to change networks.\n\nExample: A subtle container shows the user what relevant tokens they have in their wallet, and the main CTA provides a shortcut to change the network.","tokens":1621,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260889747,"hash":"9c773dd4e4a9738237a4dafcfef57786fe1e4ce2"}
{"url":"https://governance.aave.com/c/governance/general/8","domain":"governance.aave.com","title":"Latest Governance/General topics - Aave","text":"Latest topics in General\n\n Governance\n\n General\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [ARFC] Governance Framework v2\n\n title: [ARFC] Governance Framework v2 \nauthor: @TokenLogic \ncreated: 2026-07-20 \n\nSummary\nThis publication presents an overview of the Aave DAO’s Governance Process v2 and, upon implementation, replaces the current Gove…\n\n read more\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n 135\n\n 18.0k\n\n 7d\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n 0\n\n 88\n\n 12d\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n 2\n\n 258\n\n Sep 21\n\n Migrate from V4 Main vault to Bluechip\n\n 9\n\n 410\n\n Sep 21\n\n Should Aave Make Governance Discussions Easier for Non-Technical Users to Follow?\n\n 2\n\n 109\n\n Sep 20\n\n [Discussion] ZK compliance layer for EU users — alternative to permissioned pools\n\n 4\n\n 239\n\n Aug 3\n\n Missing WBTC deposit in Aave V4 Core Hub - not showing on dashboard\n\n 1\n\n 153\n\n Jul 29\n\n Question about Aave V4 improvements compared to Aave V3\n\n 1\n\n 126\n\n Jul 26\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n 3\n\n 535\n\n Jul 26\n\n Why increased PT-USDG supply cap suddenly?\n\n 4\n\n 187\n\n Jul 13\n\n [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n 6\n\n 1.2k\n\n Jul 9\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n 14\n\n 2.1k\n\n Jul 8\n\n ACI is leaving Aave\n\n 32\n\n 7.1k\n\n Jul 1\n\n Gho V2 - Partnering with Sky Protocol and becoming profitable (potential $70M annual profit)\n\n 4\n\n 333\n\n Jun 20\n\n Data Insights: Aave v3 On-Chain Stickiness&Smart Contract Integrations Deep Dive\n\n 0\n\n 87\n\n Jun 3\n\n [TEMP CHECK] Integrate ZentraScore On-Chain Credit Oracle to Enable Risk-Tiered Lending on Aave V3\n\n 16\n\n 567\n\n Jun 1\n\n [TEMP CHECK v2] Arbitrum WETH Suppliers Retention Programme — Opt-in Liquidity Stabilisation\n\n 15\n\n 1.3k\n\n May 17\n\n [Direct to AIP] Add WETH to the rsETH LST E-Mode on Aave Core Instance\n\n 4\n\n 1.4k\n\n Apr 23\n\n [TEMP CHECK] Automated Supply Cap Updater – Restricting Short-Term Supply Increases in Aave V3\n\n 3\n\n 417\n\n Apr 22\n\n [Direct to AIP] Aave V3 Mantle – Collateral Enablement, eMode Expansion, and Isolation Updates (USDT0, USDe, ETH, XAUT)\n\n 3\n\n 620\n\n Apr 15\n\n [TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance\n\n 3\n\n 359\n\n Apr 13\n\n Chaos Labs Is Leaving Aave\n\n 15\n\n 3.1k\n\n Apr 7\n\n [Direct to AIP] Onboard Strata srUSDe June expiry PT tokens to V3 Core Instance\n\n 4\n\n 435\n\n Mar 26\n\n [Direct to AIP] Onboard USDe & sUSDe June expiry PT tokens on Aave V3 Plasma Instance\n\n 2\n\n 413\n\n Mar 23\n\n [Direct to AIP] Re-enable wstETH Borrow Caps on Ethereum Core and Prime (Post CAPO Incident)\n\n 0\n\n 223\n\n Mar 14\n\n [TEMP CHECK] The AAVE Utility Renaissance: Aligning Protocol Success with Token Holder Value\n\n 0\n\n 336\n\n Mar 9\n\n Aave v4: Adoption Paths\n\n 0\n\n 599\n\n Mar 5\n\n [Direct-to-AIP] ACI Stream Settlement\n\n 0\n\n 595\n\n Mar 3\n\n [ARFC] Orbit Program Renewal - Q1 and Q2 2026\n\n 16\n\n 1.3k\n\n Mar 1","tokens":770,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260891249,"hash":"0e45f056410e32bd489dbc7c1f93c83d36f94a5d"}
{"url":"https://institutions.ethereum.org/data-hub","domain":"institutions.ethereum.org","title":"Live Ethereum Network Data | Institutional Onchain Data Hub","text":"Data HubLive data on the Ethereum ecosystem, covering network activity, DeFi, stablecoins, RWAs, and Layer 2 networks.Explore curated metrics for mainnet activity, L2 scaling, DeFi markets, tokenized assets, and more.OverviewEther Market Cap$0BSource: ultrasound.money (opens in a new tab)Total Value Secured$0BSource: ultrasound.money (opens in a new tab)ETH Staked$0BSource: ultrasound.money (opens in a new tab)Security Ratio0.0xSource: ultrasound.money (opens in a new tab)DeFiDeFi TVLTotal value locked in DeFi protocols on Ethereum$0.0BSource: defillama.com (opens in a new tab)Ethereum vs. Next-Largest DeFi Ecosystem0.0xLargerSource: defillama.com (opens in a new tab)StablecoinsStablecoin TVL (Mainnet and L2s)$0BSource: rwa.xyz (opens in a new tab)Stablecoin Market ShareDistribution of stablecoin market cap on Ethereum L1Source: rwa.xyz (opens in a new tab)Real-World Assets (RWAs)Value of Real-World Assets (RWAs)$0.0BSource: rwa.xyz (opens in a new tab)Layer 2 EcosystemNumber of Live Ethereum L2 Networks0Source: l2beat.com (opens in a new tab)Daily Average L2 TVLTotal value locked on Ethereum's L2 networks$0.0BSource: growthepie.com (opens in a new tab)","tokens":293,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791260899267,"hash":"69f1f913897f0cbb6c4d71f033530c180d60a3bd"}
{"url":"https://ethereum.org/developers/docs/design-and-ux/dex-design-best-practice/","domain":"ethereum.org","title":"Decentralized exchange (DEX) design best practices | ethereum.org","text":"Decentralized exchange (DEX) design best practicesEdit page (opens in a new tab)Since the launch of Uniswap in 2018, there have been hundreds of decentralized exchanges launched across dozens of different chains.\nMany of these introduced new elements or added their own twist, but the interface has remained generally the same.\nOne reason for this is Jakob’s Law (opens in a new tab):\n\nUsers spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know.\n\nThanks to early innovators like Uniswap, Pancakeswap, and Sushiswap, DeFi users have a collective idea of what a DEX looks like.\nFor this reason, something like “best practice” is now emerging. We see more and more design decisions being standardized across sites. You can see the evolution of DEXes as a giant example of testing it live. Things that worked stayed, things that didn’t, got tossed out. There’s still room for personality, but there are certain standards a DEX should conform to.\nThis article is a summary of:\n\nwhat to include\nhow to make it as usable as possible\nthe main ways to customize the design\n\nAll of the example wireframes were made specifically for this article, although they are all based on real projects.\nThe Figma kit is also included at the bottom - feel free to use it and speed up your own wireframes!\nBasic anatomy of a DEX\nThe UI generally contains three elements:\n\nMain form\nButton\nDetails panel\n\nVariations\nThis will be a common theme in this article, but there are various different ways these elements can be organized. The “details panel” can be:\n\nAbove the button\nBelow the button\nHidden in an accordion panel\nAnd/or on a “preview” modal\n\nN.B. A “preview” modal is optional, but if you are showing very few details on the main UI, it becomes essential.\nStructure of the main form\nThis is the box where you actually choose which token you want to swap. The component consists of an input field and a small button in a row.\nDEXes typically display additional details in one row above and one row below, although this can be configured differently.\n\nVariations\nTwo UI variations are shown here; one without any borders, creating a very open design, and one where the input row has a border, creating a focus on that element.\n\nThis basic structure allows four key pieces of info to be shown in the design: one in each corner. If there is only one top/bottom row, then there are only two spots.\nDuring the evolution of DeFi, lots of different things have been included here.\nKey info to include\n\nBalance in wallet\nMax button\nFiat equivalent\nPrice impact on the “received” amount\n\nIn the early days of DeFi, the fiat equivalent was often missing. If you are building any sort of Web3 project, it is essential that a fiat equivalent is shown. Users still think in terms of local currencies, so in order to match real world mental models, this should be included.\nOn the second field (the one where you choose the token you are swapping to) you can also include the price impact next to the fiat currency amount, by calculating the difference between the input amount and estimated output amounts. This is quite a useful detail to include.\nPercentage buttons (e.g., 25%, 50%, 75%) can be a useful feature, but they take up more space, add more call to actions, and add more mental load. Same with percentage sliders. Some of these UI decisions will depend on your brand and your user type.\nExtra details can be shown below the main form. As this type of info is mostly for pro users, it makes sense to either:\n\nkeep it as minimal as possible, or;\nhide it in an accordion panel\n\nExtra info to include\n\nToken price\nSlippage\nMinimum received\nExpected output\nPrice impact\nGas cost estimate\nOther fees\nOrder routing\n\nArguably, some of these details could be optional.\nOrder routing is interesting, but doesn’t make much difference to most users.\nSome other details are simply restating the same thing in different ways. For example “minimum received” and “slippage” are two sides of the same coin. If you have slippage set at 1%, then the minimum you can expect to receive = expected output-1%. Some UIs will show expected amount, minimum amount, and slippage… Which is useful but possibly overkill.\nMost users will leave default slippage anyway.\n“Price impact” is often shown in brackets next to the fiat equivalent in the “to” field. This is a great ux detail to add, but if it is shown here, does it really need to be shown again below? And then again on a preview screen?\nMany users (especially those swapping small amounts) will not care about these details; they will simply enter a number and hit swap.\n\nExactly what details are shown will depend on your audience and what feel you want the app to have.\nIf you do include slippage tolerance in the details panel, you should also make it editable directly from here. This is a good example of an “accelerator”; a neat UX trick that can speed up experienced users’ flows, without impacting the general usability of the app.\n\nIt’s a good idea to think carefully about not just one specific piece of information on one screen, but about the entire flow through:\nEntering numbers in Main Form → Scanning Details → Clicking to Preview Screen (if you have a preview screen).\nShould the details panel be visible at all times, or does the user need to click it to expand?\nShould you create friction by adding a preview screen? This forces the user to slow down and consider their trade, which can be useful. But do they want to see all the same info again? What is most useful to them at this point?\nDesign options\nAs mentioned, a lot of this comes down to your personal style\nWho is your user?\nWhat is your brand?\nDo you want a “pro” interface showing every detail, or do you want to be minimalist?\nEven if you’re aiming for the pro users who want all info possible, you should still remember Alan Cooper’s wise words:\n\nNo matter how beautiful, no matter how cool your interface, it would be better if there were less of it.\n\nStructure\n\ntokens on the left, or tokens on the right\n2 rows or 3\ndetails above or below the button\ndetails expanded, minimized, or not shown\n\nComponent style\n\nempty\noutlined\nfilled\n\nFrom a pure UX point of view, UI style matters less than you think. Visual trends come and go in cycles, and a lot of preference is subjective.\nThe easiest way to get a feel for this - and think about the various different configurations - is to take a look at some examples and then do some experimenting yourself.\nThe included Figma kit contains empty, outlined and filled components.\nTake a look at the below examples to see different ways you can put it all together:\n\nBut which side should the token go on?\nThe bottom line is that it probably doesn’t make a huge difference to usability. There are a few things to bear in mind, however, which might sway you one way or the other.\nIt’s been mildly interesting to see the fashion change with time. Uniswap initially had the token on the left, but has since moved it to the right. Sushiswap also made this change during a design upgrade. Most, but not all, protocols have followed suit.\nFinancial convention traditionally puts the currency symbol before the number, e.g., $50, €50, £50, but we say 50 dollars, 50 Euros, 50 pounds.\nTo the general user - especially someone who reads left to right, top to bottom - token on the right probably feels more natural.\n\nPutting the token on the left and all the numbers on the right looks pleasingly symmetrical, which is a plus, but there is another downside to this layout.\nThe law of proximity states that items that are close together are perceived as related. Accordingly, we want to place related items next to each other. The token balance is directly related to the token itself, and will change whenever a new token is selected. It therefore makes slightly more sense for the token balance to be next to the token select button. It could be moved underneath the token, but that breaks the symmetry of the layout.\nUltimately, there are pluses and minuses for both options, but it is interesting how the trend appears to be towards token on the right.\nButton behavior\nDon’t have a separate button for Approve. Also don’t have a separate click for Approve. The user wants to Swap, so just say “swap” on the button and initiate the approval as the first step. A modal can show progress with a stepper, or a simple “tx 1 of 2 - approving” notification.\n\nButton as contextual help\nThe button can do double duty as an alert!\nThis is actually a fairly unusual design pattern outside of Web3, but has become standard within it. This is a good innovation as it saves space, and keeps attention focused.\nIf the main action - SWAP - is unavailable due to an error, the reason why can be explained with the button, e.g.:\n\nswitch network\nconnect wallet\nvarious errors\n\nThe button can also be mapped to the action that needs to be performed. For example, if the user cannot swap because they are on the wrong network, the button should say “switch to Ethereum”, and when the user clicks on the button, it should switch the network to Ethereum. This speeds up the user flow significantly.\n\nBuild your own with this figma file\nThanks to the hard work of multiple protocols, DEX design has improved a lot. We know what info the user needs, how we should show it, and how to make the flow as smooth as possible.\nHopefully this article provides a solid overview of the UX principles.\nIf you want to experiment, please feel free to use the Figma wireframe kit. It is kept as simple as possible, but has enough flexibility to build the basic structure in various ways.\nFigma wireframe kit (opens in a new tab)\nDeFi will continue to evolve, and there is always room for improvement.\nGood luck!","tokens":2449,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260899947,"hash":"510e2dc9bb041bbb98656317365f65271c0edaf4"}
{"url":"https://governance.aave.com/t/missing-wbtc-deposit-in-aave-v4-core-hub-not-showing-on-dashboard/25384/2","domain":"governance.aave.com","title":"Missing WBTC deposit in Aave V4 Core Hub - not showing on dashboard - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 26\n\n 3 / 3\n\n Jul 28\n\n Jul 29\n\n post by MM41 on Jul 26\n\n MM41\n\n Hello Aave Support Team,\nI am experiencing a critical issue with a recent WBTC deposit on the Aave V4 protocol (Ethereum Mainnet). I deposited 0.00492725 WBTC into the Aave Core Hub, the transaction was successful on-chain, but the funds are not displaying correctly on the pro.aave.com dashboard, and my Health Factor did not increase as expected.\nTransaction Details:\n• Wallet Address: `0x8dF87ED1d73eDB9998A81678096Ab0F9A34aB435`\n• Transaction Hash: `0x946321d3d024e1789f7ddc7d280ddc0d25ea90eefb4b5755808e575f3f25a02a`\n• Amount: `0.00492725 WBTC`\n• Contract Interacted With: `0x94e7A5dCbE816e498b89aB752661904E2F56c485` (Aave: Main Spoke)\n• Event Emitted: `Supply` (Log 218) with `reserveId: 3`\n\nThe Issue:\n1. Before the deposit, I had an active borrow position of ~$1,201 USDC against ~0.03 WBTC.\n2. When simulating the deposit of the additional 0.00492725 WBTC, the UI showed my Health Factor would increase to ~1.40.\n3. After the transaction was confirmed, my Health Factor remained stuck at ~1.29.\n4. The deposited amount of 0.00492725 WBTC is nowhere to be found as a separate balance on the Dashboard, nor did it visibly update the main collateral balance in a way that reflects the expected Health Factor increase.\n5. However, when I click “Withdraw”, the max available amount shows `0.03158279 WBTC`, which indicates the funds are in the protocol, but the UI and Health Factor calculation seem bugged or are routing the funds to a different `reserveId` that isn’t properly backing my USDC borrow.\n\nCould you please investigate why this deposit is not reflecting correctly on the UI and why it didn’t improve my Health Factor? I need to know how to safely withdraw this specific amount or properly apply it to my main position.\nThank you.\n\n post by Essah on Jul 29\n\n Essah\n\n Aave Labs-Technical SP\n\n Hi,\nThe Governance Forum is for protocol discussion. For personal support, please use one of our official channels:\nDocs: Aave Protocol Overview\nIn-App: app.aave.com → Get Support (on the bottom of the page)\nEmail: wecare@aave.com\nDiscord: Aave Community → #help\nNote: Aave Labs will never DM you first or ask for your seed phrase or private keys.\nClosing this thread. Our support team is ready to help through the channels above.\n— Aave Labs\n\n Closed on Jul 29\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Bug Report: aEthWBTC UI bug causing wrong balance + health factor\n\n Governance\n\n 1\n\n 147\n\n Apr 2025\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 142\n\n Jul 20\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 1\n\n 157\n\n Sep 16\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5","tokens":744,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260901467,"hash":"ce4a7ee2cee9fa2a8acc49ab75901a8b389bf65a"}
{"url":"https://ethereum.org/quizzes/","domain":"ethereum.org","title":"Quiz Hub | ethereum.org","text":"Your total points0/151Average score: 0%Completed: 0/28Community statsAverage score:70%Questions answered:1,130,094Retry rate:24.7%Last updated: Oct 5, 2026, 12:04 AM UTCEthereum basicsThis section covers the fundamental concepts of Ethereum, ensuring you have a strong foundation.What is Ethereum?5 QuestionsBEGINNERWhat is ether (ETH)?4 QuestionsBEGINNERWallets4 QuestionsBEGINNERWhat are apps?6 QuestionsBEGINNERWhat is Web3?5 QuestionsBEGINNEREthereum vs Bitcoin5 QuestionsBEGINNERApps and moneyThe things people actually do onchain, from collectibles and stable value to lending, trading and paying each other.NFTs - Non-fungible tokens5 QuestionsBEGINNERStablecoins5 QuestionsBEGINNERDeFi - Decentralized finance5 QuestionsBEGINNERDAOs - Decentralized autonomous organizations5 QuestionsINTERMEDIATEPayments6 QuestionsINTERMEDIATEHow Ethereum worksA closer look at the machinery of the network itself, from accounts and transactions to the software that keeps Ethereum running.Ethereum accounts7 QuestionsBEGINNERSmart contracts4 QuestionsBEGINNEREthereum: a green and efficient blockchain5 QuestionsBEGINNERTransactions7 QuestionsINTERMEDIATEBlocks6 QuestionsINTERMEDIATEGas fees5 QuestionsADVANCEDEthereum Virtual Machine (EVM)6 QuestionsADVANCEDSecurity and privacyHow to keep your funds safe from scams and attacks, and how much you reveal about yourself when you use Ethereum.Ethereum security and scam prevention5 QuestionsBEGINNERPrivacy6 QuestionsBEGINNERZero-knowledge proofs7 QuestionsINTERMEDIATEScaling, staking and nodesHow Ethereum grows beyond mainnet, and how validators and node operators keep the network running.Blockchain bridges6 QuestionsBEGINNERLayer 24 QuestionsINTERMEDIATERun a node6 QuestionsINTERMEDIATEThe Merge5 QuestionsINTERMEDIATEProof-of-stake6 QuestionsINTERMEDIATESolo staking7 QuestionsADVANCEDScaling4 QuestionsADVANCEDWant to see more quizzes here?Contribute to our library.Add a question/quiz","tokens":484,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260910257,"hash":"91fd97c3d1477290939a67833c95302f79111622"}
{"url":"https://dev-forum.pyth.network/t/pyth-community-hackathon-official-rules/521/1","domain":"dev-forum.pyth.network","title":"Pyth Community Hackathon Official Rules - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Community Hackathon Official Rules \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2\n\n 1 / 1\n\n Mar 2\n\n Mar 2\n\n post by CHOPPAtheSHARK on Mar 2\n\n CHOPPAtheSHARK\n\n Community Hackathon for Builders of All Skill Levels\nWhat is the Pyth Community Hackathon?\nA 6-week community hackathon for builders of all skill levels. Build projects using\nPyth’s price feeds, or Pyth Entropy. Pyth embraces vibe coding and all AI-assisted\ndevelopment to lower the barrier to entry . No PhD required.\nFormat:\n\nWeeks 1-4: Build and share progress publicly\nWeeks 5-6: Panel scoring + community voting\nEnd of Week 6: Winners announced via community call or livestream\n\nEvent Duration: March 4 – April 1, 2026\nJudging Period: April 2 – April 15, 2026\nTotal Prize Pool: 200,000 PYTH\n\nEligibility\n\nAge: 18+\nJurisdictions: Participants in OFAC-sanctioned territories are not eligible\nPyth Contributors: May participate but must disclose affiliation and are not eligible for prizes\nTeam Size: Maximum 2 people per submission\nMultiple Submissions: One submission per participant/team\n\nSubmission Requirements\nEvery valid submission must:\n\nUse at least one Pyth feature (Price Feeds, Entropy)\nInclude a working demo and/or live deployment\nProvide source code (GitHub/GitLab, Apache 2.0 license)\nPost to Pyth Developer Forum using the official template (pinned in this category)\nSubmit via GitHub (following DAO election process) with explicit terms acceptance\n\nContent Creation Requirements\nEvery submission must also include at least one of the following content contributions.\nThis helps the broader community discover and learn what is possible to build with Pyth:\n\nOne public post about your project and how it uses Pyth data — Reddit (r/algotrading, r/cryptocurrency, r/solana, r/defi), Dev.to, or Hashnode\n\nOne technical contribution — a Stack Overflow answer referencing Pyth, or a GitHub code example/gist showing your Pyth integration\n\nBonus PYTH for extra content:\n\nWikipedia contribution mentioning Pyth (verified): +5,000 PYTH\nQuality X content about Pyth and/or what you have built: +1,000 PYTH\n\nAll submissions must include an answer capsule — a 40-60 word self-contained summary of what Pyth data your project uses and why. This appears at the top of your submission.\nData collected at submission:\n\nDiscord handle\nWallet address (for screening and prize distribution)\nTerms acceptance checkbox\n\nNo personal identity information is collected at submission. Winners claiming prizes will\nbe required to complete KYC verification.\n\nPrize Structure\n\nTier\nCriteria\nReward\n\n1st Place\nTop judging score\n50,000 PYTH\n\n2nd Place\nSecond highest\n30,000 PYTH\n\n3rd Place\nThird highest\n15,000 PYTH\n\n4th–10th Place\nNext 7 highest\n3,000 PYTH each\n\nCommunity Choice\nHighest forum upvotes\n10,000 PYTH\n\nMost Creative Pyth Pro Use\nSpecial category\n10,000 PYTH\n\nBest Promotional/Educational Content\nSpecial category\n10,000 PYTH\n\nReddit Upvote Bonuses:\n\n10 upvotes: +500 PYTH\n25 upvotes: +1,000 PYTH\n50 upvotes: +2,500 PYTH\n100 upvotes: +5,000 PYTH\n\nJudging Criteria\n\nCriteria\nWeight\nWhat We’re Looking For\n\nPyth Integration\n30%\nIs the integration meaningful? Does it showcase Pyth capabilities effectively?\n\nCreativity/Innovation\n25%\nDoes this do something new or interesting? Does it surprise us?\n\nExecution\n20%\nDoes it work? Is the code clean and functional?\n\nUser Experience\n15%\nIs it fun or useful? Would someone actually use this?\n\nDocumentation\n10%\nCan someone else understand and build on this?\n\nTotal Score: 100 points\nJudges:\n\nArguer (Community Council)\nLowkeigh (Community Council)\nDouro Labs Engineers (Gigabrained)\nGainzy (Respected Crypto Native)\n\nTransparency: All scores will be published after results are announced.\n\nImportant Dates\n\nSubmissions Open: March 4, 2026\nSubmission Deadline: April 1, 2026\nJudging Period: April 2 – April 15, 2026\nWinners Announced: April 15, 2026\n\nTerms & Conditions\nFull T&Cs: Terms & Conditions\nThe Hackathon is organized by PYTH DAO LLC (Marshall Islands) through the Community Council.\nKey provisions:\n\nSkill-based judging with transparent, objective criteria\nTax disclaimer: Participants responsible for their own tax obligations\nIP/Licensing: All submissions Apache 2.0. Participants retain IP ownership.\nOFAC compliance: Sanctioned jurisdictions excluded\nKYC: Required only for prize-winning participants\nDAO contributors: May participate but are not eligible for prizes\nIndividual capacity: Participants warrant they are acting individually, not on behalf of employers or organizations\n\nQuestions?\nPost in this category — we’re here to help.\n\nThis is a Community Council-approved initiative. Have fun. Stack PYTH. Join the Community.\n\n Getting Started & FAQ\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Terms & Conditions\n\n Pyth Community Hackathon\n\n 0\n\n 227\n\n Mar 5\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n 620\n\n Mar 31\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 282\n\n Mar 2\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Pyth Sentinel: How I Built a Real-time Crypto Alert & Prediction Platform Using Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 56\n\n Mar 17\n\n Powered by Discourse","tokens":2204,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260911515,"hash":"bdea80134603566155dfa16b5b63d2eb6efe8d46"}
{"url":"https://governance.aave.com/t/direct-to-aip-onboard-btc-b-to-aave-v4-core-instance-on-ethereum/25532/1","domain":"governance.aave.com","title":"[Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum - Governance - Aave","text":"[Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Summary\n\n Motivation\n\n Specification\n\n Useful Links\n\n Disclaimer\n\n Next Steps\n\n Copyright\n\n Aug 25\n\n 1 / 2\n\n Aug 24\n\n Sep 16\n\n post by AaveLabs on Aug 25\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Title: [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\nAuthor: @AaveLabs\nDate: 2026-08-25\n\nSummary\nThis proposal seeks to onboard BTC.b to the Aave V4 Core Instance on Ethereum. This proposal follows the Direct to AIP route.\nMotivation\nBTC.b is a bridged representation of Bitcoin supported by Lombard’s infrastructure. BTC.b is already listed on the Aave V3 Core Instance and Aave V4 Core Instance on Avalanche, and this proposal extends its availability to the Aave V4 Core Instance on Ethereum.\nThe onboarding would expand the BTC collateral options available through Aave V4 while allowing the DAO and its Service Providers to apply a configuration specific to V4.\nSpecification\nThis proposal onboards BTC.b to the Aave V4 Core Instance on Ethereum.\nBTC.b: 0xB0F70C0bD6FD87dbEb7C10dC692a2a6106817072\nRisk parameters and final configuration will be provided by the Risk Service Providers and this proposal will be updated accordingly.\nUseful Links\n\nDocumentation\nFrequently asked questions\n\nDisclaimer\nThis proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no direct financial relationship with Lombard Finance or its affiliates and has not received compensation from Lombard Finance or its affiliates in connection with this proposal.\nNext Steps\n\nGather community and Service Provider feedback.\nIncorporate the Risk Service Providers’ final configuration for the Aave V4 Core Instance.\nPublish the AIP vote for final confirmation and onchain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n 22 days later\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding BTC.b to the Aave V4 Core Hub on Ethereum, conditional on the segregation of BTC custody between Lombard’s BTC.b and LBTC products, which are currently backed by a pooled custody structure. Lombard has confirmed that per-asset custody segregation is planned and is expected to be implemented within the next couple of weeks. While Lombard’s aggregate reserves are sufficient to fully collateralize both products, dedicated custody for BTC.b would ensure that its backing remains independent of LBTC-related exposures.\nBeyond the above consideration, BTC.b benefits from robust administrative safeguards. Contract upgrades are subject to a 1-day timelock enforced by LombardTimeLock, with the executor controlled by Lombard’s 3/5 Safe multisig. The Bascule check is also enabled on the Ethereum BTC.b contract, providing an additional layer of verification for mints. The protocol also maintains an active bug bounty program, and recent audits have not identified any critical or high-severity findings. BTC.b currently has approximately $7.9M in DEX liquidity on Ethereum, nearly 100% of which is supplied by the Lombard team. While highly concentrated, this liquidity is relatively stable given its protocol-aligned nature and lower reliance on third-party LPs.\nThe full assessment can be found in its corresponding thread.\nAave V4 Specific Parameters\nSpoke Parameters\n\nChain\nHub\nSpoke\nReserve\nCollateral Factor\nMax Liquidation Bonus\nBorrowable\nCollateral Risk\nLiquidation Fee\nRisk Premium Threshold\nReceive Shares\n\nEthereum\nCore Hub\nMain Spoke\nBTC.b\n78%\n5.55%\nFALSE\n0\n10%\n0\nTRUE\n\nAdd and Draw Caps\n\nChain\nHub\nSpoke\nReserve\nAdd Cap\nDraw Cap\n\nEthereum\nCore Hub\nMain Spoke\nBTC.b\n200\n0\n\nPrice feed Recommendation\nWe recommend using Chainlink’s BTC/USD SVR feed to price BTC.b on Aave V4.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n This topic will close a month after the last reply.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n BTC.b on Aave Ethereum\n\n Assessments\n\n 1\n\n 75\n\n Sep 16\n\n [Direct to AIP] Onboard BTC.b to Aave V3 Core Instance\n\n New Asset\n\n 5\n\n 704\n\n Mar 19\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 2\n\n 200\n\n Sep 17\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n General\n\n 14\n\n 2.1k\n\n Jul 8\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21","tokens":1221,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791260911815,"hash":"d36ce83dba00ac17896c8f37f9b1902213fc08c9"}
{"url":"https://ethereum.org/values/","domain":"ethereum.org","title":"Ethereum's core principles | ⁦ethereum.org⁩","text":"The hidden cost of living onlineAlgorithms decide what we see. Our behavior is tracked to influence what we buy. We created the content that makes platforms valuable, yet the platforms own our accounts, control the reach, and keep the power.None of this is inevitable. It's the result of how today's internet was built. But different infrastructure produces different outcomes, and Ethereum is building a better alternative.PrivacyYour personal life should not become someone else's product. Ethereum lets you interact without handing control of your identity and data to a central platform.Why privacy matters?Open SourceThe systems shaping your life should not be hidden behind closed doors. Ethereum's code can be inspected, verified, and improved by anyone.Why open source matters?Censorship ResistanceNo company, government, or middleman can freeze you out or block what you build. If you can reach the network, you can use it.Why open access matters?SecurityDigital ownership only matters when it cannot be easily taken, altered, or forged. Ethereum is secured by a global network rather than a single organization.What would the internet look like if it worked for people?Ethereum exists so you keep the final say over your own digital life (your money, identity, and actions). So that people can coordinate at scale (eg. a payments network) without handing that final say to whoever runs the system. The four principles are the conditions that make this possible.These four values are how Ethereum keeps that promise, and they hold only together. Weaken one and the others can't protect you.Open code without privacy turns transparency into exposure. A system anyone can audit, where your identity and balances are also visible, becomes a surveillance tool.Privacy without censorship resistance lets you be shut down without being seen. Concealing what you do protects the act but not your ability to keep doing it, because a gatekeeper can still freeze you.Censorship resistance without security is unstoppable and unreliable at the same time. Access no one can block is worth little if the system fails to do what it promised.Security you cannot inspect is just trust in disguise. A guarantee no one can verify is only a promise, and promises can be broken quietly.These values are shared across the entire Ethereum ecosystem, the researchers, builders, and communities who build here because of what the technology defends. Beyond Ethereum, it's important for everyone to understand why these properties matter in the digital age, and what you can do to protect them in your everyday life.Frequently Asked QuestionsThe record of activity is public, but it does not have to carry your name. Newer privacy tools let you prove something is true, like \"I have enough to pay,\" without revealing the details behind it. The aim is that you decide what to show, and the rest stays yours. This part of Ethereum is still improving, and honesty matters here.Because you do not have to take its word for it. Ethereum's code and rules are public, so anyone can check whether it really does what it claims. When a company keeps its system secret, all you have is the promise. Here you can verify it, or trust people who have.The same openness that keeps anyone from unfairly blocking you also means bad actors can show up, the way they can anywhere online. Ethereum handles this through transparency and security rather than a central gatekeeper: activity is public and traceable, and protection comes from better tools and safer habits. Removing the off switch is the price of making sure no one can be shut out unfairly.You might never need this, and that is fine. Think of it like a lock on a door: easy to ignore until the day it matters. As more of life moves online, simply having the option to keep the final say over your money and identity is worth holding, even if you rarely use it.","tokens":973,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260921016,"hash":"5493822d75aa75e3e932a3d8c9d297776b59203e"}
{"url":"https://ethereum.org/open-access/","domain":"ethereum.org","title":"Financial freedom and open access | ⁦ethereum.org⁩","text":"SummaryEthereum is an alternative financial system available worldwide.Access to international banking and global markets is offered to everyone, without restrictions.There is no intermediary that can target individuals and freeze their ETH transactions.You can participate instantly without needing approval from a bank or financial institution.Who decides what you can do with your money?You wake up and see a strange notification. Your account has been frozen. Your money is still there, but you cannot spend it, transfer it, or pay your bills.Most of us rarely think about who controls our digital access until something goes wrong.Usually it is temporary. A fraud check clears, the payment goes through, and you forget about it. But for a few seconds you bumped into something that is true every day and almost never visible: between you and your money sits a company, and it can say no.Sometimes even your own government can block you:Lebanon, 2019: People with US dollar savings could no longer withdraw them normally.[1]Argentina, 2019 to 2025: People faced tight limits on buying US dollars and moving money abroad.[2]Myanmar, 2021: Cash shortages and withdrawal limits made bank balances difficult to access.[3]Sri Lanka, 2022: Authorities restricted how foreign currency could be held, used and withdrawn.[4]And many people never get access in the first place. According to the latest World Bank Global Findex, 1.3 billion adults worldwide still do not have a financial account, even though 900 million of them have a mobile phone.[5]Having money and being free to use it are not the same thing.This is what censorship can look like when it involves money. Not a post disappearing from a website, but someone else having the final say over whether you can pay, withdraw, receive or participate.What financial freedoms does Ethereum offer?Financial freedom is not only about how much money you have. It is also about how much say you have over what you can do with it.You can think of this as financial agency: the ability to hold, move and use your assets, choose which financial tools to use, and take your money elsewhere when a service no longer works for you.Ethereum cannot guarantee wealth or equal outcomes. What it can do is reduce how often you need someone else's permission to participate.Ethereum offers the ability to hold and transfer ETH without depending on a company to keep your account open.Your ability to participate economicallyOn Ethereum, you can use assets as collateral, access the same underlying financial infrastructure from different countries, interact with markets around the clock, and move assets between applications without opening a new account each time.This can matter when services leave a country, or when access to traditional financial infrastructure is limited.Worldwide financial accessFinancial services vary by country, and some products like holding US dollars or stocks are not available everywhere.Ethereum runs on the same global infrastructure for anyone.Get a loan without a credit scoreUse your assets as collateral to borrow, without needing to have a credit score first.You still need collateral, and borrowing carries risk.Access markets anytimeMany traditional financial services have opening hours, settlement periods or delays between institutions.Ethereum apps run all day, every day. The network has not gone offline once since it launched in 2015.Take your assets with youMoving from one financial service to another often means creating another account, transferring money and waiting for it to arrive.On Ethereum, the assets are in your wallet. The same assets can often be used across different apps for trading, lending, saving or other purposes.What is censorship resistance?Censorship resistance is a system's ability to remain usable even when someone tries to block a user or transaction.On Ethereum, no single company, validator or app operator controls access to the main network. An app can set its own rules and block certain actions inside that app, but those rules end where the app ends. They do not decide what you can do on Ethereum as a whole.This is the technical property behind Ethereum's open access.PermissionlessYou do not need to apply for an Ethereum account.There is no central signup process, identity check or administrator who must approve you before you can interact with the network.NeutralThe Ethereum protocol applies the same rules to everyone.The network checks whether a transaction follows its rules, not whether it agrees with who sent it or why.No single off switchEthereum does not run from one company's servers.Independent computers operate the network around the world. Removing one computer, company or service does not shut Ethereum down.A shared recordOnce a transaction is confirmed, it becomes a permanent part of Ethereum's history.There is no administrator who can quietly edit the record or delete inconvenient history.An alternative when institutions failMost people will continue using banks, websites and other intermediaries because they are convenient and useful.Censorship resistant infrastructure provides another option when those systems become unavailable, unreliable or hostile.You may rarely need that option, but its value becomes clearer on the day you do.Emergency situationsWhen Russia invaded Ukraine in 2022, Ukraine's central bank introduced emergency limits on cash withdrawals and some financial transfers to protect the banking system. At the same time, the government published official crypto addresses, including an Ethereum address, so people around the world could send funds directly.Within the first month, Ukraine's official crypto fund had received more than $60 million in cryptoassets.[6]Crypto did not replace Ukraine's banks. It provided another way to move value when speed, borders and access mattered.That is the value of censorship resistant infrastructure: another path when the systems you normally rely on become restricted, unavailable or unreliable.Your ability to publishInformation stored through decentralized systems can be much harder for one organization to quietly remove or rewrite.In 2018, a Chinese student published an open letter about a sexual assault case at Peking University. After the letter disappeared from major online platforms, supporters copied it into an Ethereum transaction. The post could be removed from a website, but the copy on Ethereum remained.[7]Later that year, an investigative article about a vaccine scandal was also removed from Chinese social media. Readers responded by preserving the article on Ethereum, turning the network into a record that was much harder for any one platform to erase.[8]A similar thing happened in 2020, when an interview with Wuhan doctor Ai Fen disappeared from WeChat. Copies soon appeared in formats designed to survive censorship, including on Ethereum.[9]A platform can remove a post. It is effectively impossible for one party to erase the underlying record from Ethereum.Your freedom to buildDevelopers can deploy programs to Ethereum without asking Ethereum for an API key, developer account or app store approval.Once deployed, those programs do not depend on one company's continued permission to exist.In 2021, Uniswap Labs stopped showing some tokens on its website. But the blockchain app itself kept working so other websites could still connect to it and let people access the same tokens.[10]Even if one website stops providing access, the underlying application can still remain on Ethereum and be reached through another interface.How Ethereum resists censorshipEthereum spreads control across many independent participants:Anyone can run a node and independently check the network's rules. Ethereum is deliberately designed so a node can run on consumer hardware.Validators across the world propose and confirm blocks of transactions.Multiple independent teams build the software used to operate the network.There is no Ethereum headquarters that can be ordered to switch the network off.There is no central Ethereum account system that can suspend a user.This makes sustained censorship much harder to coordinate because it requires controlling or influencing many independent parts of the system rather than one administrator.A validator or block builder can leave a transaction out of a block. But another participant can include it in a later block. A transaction can be delayed but never fully stopped.ETH is not like other crypto assetsMany crypto assets are issued by companies that keep some control over them. For example, issuers of stablecoins such as USDC and USDT can block addresses and freeze tokens when required.[11]ETH works differently. It is the native asset of Ethereum, not a token issued by a company or controlled by a smart contract. There is no administrator key that can freeze the ETH in a particular account.If you control your account and can access the Ethereum network, nobody, including any company or government, can revoke your ability to use your ETH.Getting started on EthereumYou do not need to become an expert to reduce how much your digital access depends on intermediaries. An easy first step is to install a crypto wallet to create an Ethereum account.Read more about wallets Digital freedom beyond EthereumEthereum is only one part of a much larger effort to keep digital infrastructure open.Organizations around the world work on internet access, free expression, resilient communication, privacy and access to information.Electronic Frontier FoundationDefends digital civil liberties in the courts and in public policy (opens in a new tab)Access NowWorks to defend digital rights and documents internet shutdowns worldwide. (opens in a new tab)Internet ArchivePreserves the web and defends the right to read, lend, and archive online (opens in a new tab)Tor ProjectBuilds open anonymity and anti-censorship tools (opens in a new tab)Freedom of the Press FoundationDevelops tools and resources that support journalists and press freedom. (opens in a new tab)Reporters Without BordersWorks to protect freedom of information and journalists around the world. (opens in a new tab)A different future is possibleDigital systems do not have to be built around permanent permission from a handful of gatekeepers.We can build infrastructure where companies still provide useful services, communities still set their own rules, and laws still apply, while no single intermediary holds the final switch over everyone's access.Protect your privacy onlineRecommendedLearn how to protect your privacy so that nobody has the ability to target you.Why Ethereum?Read about what makes Ethereum special in today's world.Further readingLebanon: 2023 Article IV Consultation (opens in a new tab) - International Monetary FundComunicación \"A\" 6815 (opens in a new tab) - Banco Central de la República Argentina (limit lifted in April 2025)Myanmar Economic Monitor, July 2021 (opens in a new tab) - World BankAmending limits and conditions on possession of foreign currency (opens in a new tab) - Central Bank of Sri LankaMobile-Phone Technology Powers Saving Surge in Developing Economies (opens in a new tab) - World Bank (Global Findex 2025)The Cryptocurrencies Fund of Ukraine has already raised more than $60 million for the needs of the Armed Forces (opens in a new tab) - Cabinet of Ministers of Ukraine, March 2022China's #MeToo activists use blockchain to skirt censors (opens in a new tab) - Hong Kong Free PressChinese bet on blockchain to counter vaccine scandal cover-up (opens in a new tab) - TechNodeChinese Netizens Use Ethereum To Avoid China's COVID-19 Censorship (opens in a new tab) - ForbesToken access on app.uniswap.org (opens in a new tab) - Uniswap LabsUSDC Risk Factors (opens in a new tab) - CircleHolidays and trading hours (opens in a new tab) - New York Stock ExchangeNew \"T+1\" settlement cycle: what investors need to know (opens in a new tab) - US Securities and Exchange CommissionEthereum Uptime (opens in a new tab) - ethereumuptime.com","tokens":3012,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260931313,"hash":"489d61763379e61cadb3f82930a036a45b2848a7"}
{"url":"https://dev-forum.pyth.network/c/pyth-hackathon/14","domain":"dev-forum.pyth.network","title":"Latest Pyth Community Hackathon topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Pyth Community Hackathon\n\n Pyth Community Hackathon\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Terms & Conditions\n\n Pyth Playground — Terms & Conditions\n\n1. Overview\n1.1 Main Parties\n\nPyth Playground (the “Hackathon”) is a community-driven event organized by PYTH DAO LLC, PO Box 852, Long Islands Rd Majuro, Marshall Islands MH 96960 …\n\n read more\n\n 0\n\n 227\n\n Mar 5\n\n Getting Started & FAQ\n\n Getting Started\nPick your path based on how you work: \n\nUsing an AI coding tool? → Pyth MCP Server — lets Claude, Cursor, or Windsurf pull live Pyth data directly\nBuilding an AI agent? → Pyth Skills + MCP Server\nTraditio…\n\n read more\n\n 61\n\n 620\n\n Mar 31\n\n Pyth Community Hackathon Official Rules\n\n Community Hackathon for Builders of All Skill Levels\nWhat is the Pyth Community Hackathon?\nA 6-week community hackathon for builders of all skill levels. Build projects using \nPyth’s price feeds, or Pyth Entro…\n\n read more\n\n 0\n\n 566\n\n Mar 2\n\n Judging Rubric; How Submissions Are Scored\n\n How Projects Are Judged\nEvery submission is scored by our panel of judges using these criteria. \n\nScoring Breakdown\n\nCriteria\nWeight\nWhat We’re Looking For\n\nPyth Integration\n30%\nIs the integration meaningf…\n\n read more\n\n 0\n\n 175\n\n Mar 2\n\n Submission Template\n\n How to Submit Your Project\nCopy the template below, create a new topic in the Pyth Community Hackathon category, paste it in, and fill it out. \n\n[Project Name]\nTeam: @discord-handle-1discord-handle-1discord-handle…\n\n read more\n\n 0\n\n 282\n\n Mar 2\n\n Temporary Pyth Trial Permissions Upgrade for Fellowship\n\n svm\n\n 1\n\n 6\n\n 10h\n\n Autonomous intent-based defi agent for bridging short $meta to memecoin\n\n 0\n\n 16\n\n May 13\n\n Orra: Your Tarot Reading, Backed by Pyth Data\n\n 5\n\n 144\n\n Apr 10\n\n PolyJackpot - One guaranteed winner every single draw!\n\n entropy\n\n 0\n\n 41\n\n Apr 1\n\n Oracle Flow: The market terminal built around Pyth Price Feeds\n\n 0\n\n 26\n\n Apr 1\n\n PythGuard - Liquidation intelligence\n\n 0\n\n 25\n\n Apr 1\n\n Sleeve - A Gamified Crypto Portfolio App(Store Assets, Complete Quests, Win Prizes.)\n\n 0\n\n 25\n\n Apr 1\n\n Whac-a-Pythenian: High-Speed Arcade Gaming with On-Chain Pyth Entropy\n\n entropy\n\n 0\n\n 28\n\n Apr 1\n\n Tower of Entropy - RPG\n\n entropy\n\n 0\n\n 64\n\n Apr 1\n\n Pyth Casino: A Real-Time Crypto Casino Powered by Pyth Market Data\n\n entropy\n\n 0\n\n 26\n\n Apr 1\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n 0\n\n 24\n\n Apr 1\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n 0\n\n 24\n\n Apr 1\n\n Ouroboros — Describe a Game, Get a Deployed Pyth dApp (AI AGENT)\n\n 0\n\n 49\n\n Apr 1\n\n PythReceipt - Cryptographic Proof for Every Liquidation\n\n 0\n\n 26\n\n Apr 1\n\n Pyth Arcade - Onchain Arcade Retro Powered by Pyth\n\n 0\n\n 34\n\n Mar 31\n\n Walk The Planck\n\n 0\n\n 38\n\n Mar 31\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector\n\n 0\n\n 23\n\n Mar 31\n\n PyPredict — Real-Time Prediction Markets on Pyth\n\n 0\n\n 32\n\n Mar 31\n\n LiquidSense — Real-Time DeFi Liquidation Radar Powered by Pyth Price Feeds\n\n 0\n\n 28\n\n Mar 31\n\n Price Prediction Grids on Pyth Price Feed\n\n 0\n\n 25\n\n Mar 31\n\n RektoMeter | Airdrop Journal Powered by Pyth Price Feeds\n\n 0\n\n 21\n\n Mar 31\n\n NeuroTrade, a local-first AI trading operator for Solana powered by Pyth Pro market data\n\n 0\n\n 33\n\n Mar 31\n\n Coindle - daily crypto guessing game\n\n 0\n\n 49\n\n Mar 31\n\n PIRBGEN - Arcade game, Trading simulator\n\n 1\n\n 55\n\n Mar 30\n\n Pyth integration with QTCL Blockchain. HLWE Attestation, signed price snapshots, post quantum secure\n\n 1\n\n 35\n\n Mar 30","tokens":1753,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260931603,"hash":"40b45c68c7d1132f3c1167b56d7dd5685c04f81a"}
{"url":"https://ethereum.org/payments/","domain":"ethereum.org","title":"Payments on Ethereum | ethereum.org","text":"Edit page (opens in a new tab)Every day, millions of people face the same challenge: moving money across borders is slow, expensive, and often frustrating. A freelancer in Bali waits days for payment to clear from their New York client. This particularly affects people in regions with limited banking infrastructure, making it difficult to participate in the global economy.\nThis isn't a far-off dream—it's happening today on Ethereum. While traditional financial institutions have built robust payment systems over decades, they often remain constrained by borders, working hours, and legacy infrastructure. Ethereum offers a new paradigm: a global, 24/7 financial platform that enables near-instant, programmable transactions for anyone with internet access.\n\nRemittances: cheaper international transfers\nFor millions of people working abroad, sending money back home is a regular necessity. Traditional remittance services often come with high fees and slow processing times. Ethereum offers a compelling alternative.\nCheaper FeesRemittance services charge up to $14 fees on average. Ethereum transactions can often be completed under $0.01.Faster TransfersInternational wire transfers take several days to process. Ethereum transactions are settled in minutes.Open to anyoneYou only need an internet connection and a wallet app to send or receive Ether.\nAccess to global currencies\nIn many countries, inflation is a pressing concern, often accompanied by limited access to foreign currencies. People in these situations struggle to preserve their wealth as they are forced to hold rapidly depreciating savings.\nThe Ethereum community has created a robust alternative financial system that is independent of any nation’s monetary policies or control.\nEthereum users can use stablecoins—tokens typically tied to strong currencies like the US Dollar. By earning and saving in cryptocurrency, people can protect themselves from high inflation in their country, helping to preserve or even grow their purchasing power. This also enables easier payments for goods and services, both locally and globally.\nMore on stablecoins\nBuying goods and payment for services\nMany businesses are beginning to accept ether (ETH) and other cryptocurrencies as payment. For example:\n\nNewegg: The popular electronics retailer accepts Ethereum for purchases in select countries.\nTravala.com: This travel booking platform allows users to pay for hotels and flights using Ethereum.\nShopify: This popular E-commerce platform which serves as a platform for hosting businesses also accepts payments for goods and services using Ethereum.\nSotheby's: This organization trade fine and decorative art, jewelry, and collectibles and allows for payments using Ethereum and other cryptocurrencies.\n\nCountries like El Salvador and the Central African Republic have even adopted cryptocurrencies as legal tender, paving the way for wider acceptance of Ethereum payments in everyday transactions.\nIn countries where their means of payment have been disconnected from the rest of the world, crypto-integrated payment solutions have been a huge relief. Payments of subscriptions for platforms like Netflix, Spotify, and educational courses have now been made easy through crypto payment platforms like Gnosis Pay and Paypal.\nCreate your Ethereum account with a wallet app today.Get started\nPay with self-custodial crypto cards\nSelf-custodial crypto cards work like using your own backpack instead of locking your money in someone else’s vault. With a traditional card, a bank or custodian holds your funds and releases them when you spend. With self-custodial cards, you stay in control of your assets the whole time—no middleman—while still being able to tap or swipe to pay for coffee, groceries, or even a flight.\nThese cards link directly to non-custodial wallets or smart contract accounts, allowing users to spend ETH and stablecoins in everyday settings without giving up ownership. Unlike custodial cards, which require users to deposit funds with a third party, self-custodial cards enable real-world payments such as Visa and Mastercard while preserving onchain control.\nExamples\n\nMetaMask Card: Linked to the MetaMask wallet, this Mastercard debit card lets users spend ETH, stablecoins, and other supported tokens. It supports Apple Pay and Google Pay, includes crypto cashback rewards, and offers yield-earning options.\n\nTuyo Card: A smart contract–based Visa card that auto-converts crypto to USDC for spending anywhere Visa is accepted. Users keep custody of their assets, with access to yield, trading, and spending features.\n\nGnosis Pay: The first self-custodial Visa card tied to a Gnosis Safe smart account. Users spend crypto directly from their wallet with no gas, FX, or off-ramping fees. Card personalization via Ethereum Name Service (ENS) is also supported.\n\nEther.Fi Cash card: Integrated with ether.fi’s staking protocol, this card lets users spend while their ETH remains staked. Payments are handled via smart contracts, maintaining self-custody even while spending.\n\nSelf-custodial crypto card comparison\nCrypto cardSelf-custodialNon-custodialKey notesMetaMask Card✅✅Wallet stays in MetaMask; auto off-ramp at paymentTuyo Card✅✅Smart wallet converts to USDC; user retains controlGnosis Pay✅✅Linked to user’s Gnosis Safe; no custody shift during useEther.Fi Cash✅✅ETH remains staked; smart contract controls spending access.\n\nNote: \"Self-custodial\" refers to user-controlled wallets where the user has full access and control over their funds.\n\"Non-custodial\" refers to wallets where funds are managed without third-party custody, often through smart contracts.\nWhile all self-custodial cards are non-custodial, not all non-custodial cards are self-custodial.\n\nMicro-payments for websites & agents (x402)\nx402 (opens in a new tab) is an open payment standard that brings native per-use payments to the web. By using stablecoins on low-cost Ethereum layer 2 networks, the x402 standard makes it economical for humans and machines to pay directly for a single action, such as reading a news article or calling an API, rather than managing API keys, subscriptions, or “paying” by giving attention to advertising.\n\nRemoving paywalls and logins: Instead of creating an account and sharing personal information to read one news article, your wallet can pay the few cents required to unlock it.\nPayments for AI agents: x402 enables autonomous software (\"AI Agents\") to pay for the data and API calls they need to function, without human intervention.\n\nHow the x402 payment standard works\nWhen a client requests a resource, the server sends a 402 Payment Required error code along with payment instructions (price, account, and what tokens and chains are supported).\n\nYour wallet detects the request and handles the payment (often with a single click to approve, or automatically using a pre-approved allowance)\nAI agents with access to pre-approved wallet balances can automatically detect the price and pay instantly to access data or services\nThe client needs to have one of the supported stablecoins in their wallet, but does not need to have any ETH for gas expenses\n\nThis unlocks a new \"machine to machine\" economy where AI agents can buy resources on their own, and where API services can be accessed more efficiently.\nThe signed message is then delivered to the server. Servers typically use an x402 facilitator (opens in a new tab) to handle the blockchain complexity (sending the transaction, obtaining the payment, facilitating gas fees, etc.), which means that developers can easily accept crypto micropayments without managing payment infrastructure.\nSalary payments\nMany forward-thinking companies are now offering employees the option to receive their salaries, or a portion of them, in cryptocurrencies like ether (ETH):\n\nGipsybee: is an organization that deals in electronics, robotics, game creation and other services. They give employees the option to get paid in Ethereum.\nSC5: This Finnish company was one of the first to offer salaries in Bitcoin, paving the way for similar arrangements with Ethereum.\nBlockchain startups: Many companies in the blockchain space naturally offer cryptocurrency salary options to their employees.\nDAOs: Due to the peculiarity and diversity of contributors to DAOs, most contributions and salaries are rewarded in cryptocurrency.\n\nThis trend particularly appeals to remote workers and digital nomads who can benefit from borderless payments and potentially favorable exchange rates.\nGlobal relief efforts\nIn February 2023, when devastating earthquakes struck Turkey and Syria, the global crypto community sprang into action. Various campaigns were launched to collect funds for relief efforts, showcasing the power of Ethereum in times of crisis. Despite crypto not being a recognized form (opens in a new tab) of payment in Turkey, authorities made exceptions (opens in a new tab) for some organizations to collect donations. Some examples are:\n\nRefik Anadol (opens in a new tab): is a renowned digital artist who initiated a fundraising campaign.\nDAO Power: Anka Relief DAO (opens in a new tab) and Bankless DAO (opens in a new tab) joined forces with Giveth (opens in a new tab) to raise funds.\nPak (opens in a new tab), a prominent NFT artist, also contributed to the cause.\nEven Ethereum co-founder Vitalik Buterin (opens in a new tab) made personal donations to multiple campaigns.\n\nThe result of this? Over $6 million was raised in a matter of days, as tracked by a Dune (opens in a new tab) Analytics dashboard.\nThere were also similar response times for tragedies that happened in India and Ukraine. This rapid response highlights a crucial advantage of Ethereum payments, which is the ability to quickly mobilize global support without the hurdles of currency conversion, lengthy bank transfers, or exorbitant fees.\n\nCrypto payments on Ethereum vs. fiat payments\nTo truly appreciate the impact of Ethereum payments, it's worth comparing them to traditional fiat currencies:\nEthereumTraditional banksSpeedSeconds to minutesHours to daysGlobal ReachBorderless, 24/7Subject to international banking restrictions and work hoursTransparencyFully transparentVaries by institutionProgrammabilitySmart contracts enabledLimited to basic transactionsInflation ControlPredictable issuanceSubject to central bank policiesAccessibilityAnyone with internetSubject to national and international restrictions\nAt its core, Ethereum is a decentralized platform that allows for secure, fast, and transparent transactions. However, many components set it apart from traditional payment methods. Let's dive into the benefits that make Ethereum payments a game-changer:\nProgrammability\nOne of Ethereum's unique features is its ability to support smart contracts. Smart contracts are self-executing agreements with the terms directly written into code. This opens up a world of possibilities for automated, condition-based payments that can greatly improve transactions like:\n\nEscrow services\nRecurring payments\nPerformance-based compensation\n\nSpeed\nDo you remember the last time you waited days for an international bank transfer to clear? The long queue? And the multiple forms you had to fill? With Ethereum, those days are long gone. Transactions on the Ethereum network settle in minutes, regardless of where the sender and recipient are located. Due to Ethereum being permissionless, there is no regulatory bureaucracy when sending money. This speed is particularly crucial in time-sensitive situations, such as emergency relief efforts.\nLower fees\nTraditional international money transfers fees sometimes eat up a significant portion of the amount sent, especially when dealing with transactions in the hundreds of dollars. Ethereum transactions, while not free, often come with lower fees. This means more of your money goes where you intend it to, rather than lining the pockets of intermediaries.\nTransparency\nEvery transaction on the Ethereum blockchain is recorded on a public ledger. This means anyone can verify the movement of funds, making it an excellent tool for:\n\nCharitable organizations to demonstrate how donations are used\nBusinesses to prove payments to suppliers or employees\nIndividuals to keep track of their financial activities\n\nWith Ethereum, everyone can see how money moves and how costs are implemented, unlike traditional organizations where most of these remain unknown.\n\nWhile fiat currencies have the advantage of widespread acceptance and stability, Ethereum offers unique benefits that make it an attractive option for certain types of transactions.\nFrom facilitating rapid disaster relief to empowering global workers, Ethereum payments are writing a new chapter in the long history of money. While challenges remain, the unique advantages offered by this technology make it an attractive option for a wide range of use cases.\nTime to get your own Ethereum account.Get started!\n\nTest your Ethereum knowledgePaymentsQuestion number 1:Why would someone living with high inflation choose to save in stablecoins?","tokens":3269,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791260953315,"hash":"8e6c9f0f2b4caf91e4213a703a115c89aad37a49"}
{"url":"https://dev-forum.pyth.network/t/submission-template/522","domain":"dev-forum.pyth.network","title":"Submission Template - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Submission Template \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2\n\n 1 / 2\n\n Mar 2\n\n Mar 2\n\n post by CHOPPAtheSHARK on Mar 2\n\n CHOPPAtheSHARK\n\n How to Submit Your Project\nCopy the template below, create a new topic in the Pyth Community Hackathon category, paste it in, and fill it out.\n\n[Project Name]\nTeam: @discord-handle-1discord-handle-1discord-handle-1discord-handle-1, @discord-handle-2 (max 2 people)\nSubmitted: [Date]\n\nAnswer Capsule\n\n[40-60 words. Self-contained summary: What does your project do, what Pyth data does it use, and why? This should make sense to someone who reads nothing else.]\n\nWhat It Does\n[2-3 sentence description. Explain the problem you’re solving or the experience you’re\ncreating.]\n\nPyth Features Used\nCheck all that apply:\n\n Price Feeds (on-chain or off-chain)\n Entropy (randomness)\n Both\n\nLinks\n\nLive Demo: [URL]\nSource Code: [GitHub/GitLab URL]\nVideo Walkthrough (optional): [YouTube/Loom URL]\n\nScreenshots / Media\n[Embed images, GIFs, or demo videos here]\n\nTech Stack\nExample: Next.js, Solana, Python Flask, LangChain, etc.\n\nFramework/Language:\nBlockchain (if applicable):\nAgent Framework (if applicable):\nDeployment:\n\nContent Contributions (Required)\nEvery submission must include at least one public post and one technical contribution. Link them here.\n\nPublic Post (Reddit, Dev.to, or Hashnode): [URL]\nTechnical Contribution (Stack Overflow answer or GitHub gist/example): [URL]\nBonus — X Platform Post: [URL]\nBonus — Wikipedia Contribution (optional): [URL or diff link]\n\nLicensing\nThis project is licensed under Apache 2.0 (required for all submissions).\n\nEligibility Confirmation\n\n I am 18+ years old\n I am not located in an OFAC-sanctioned jurisdiction\n I confirm this is an original work created during the hackathon period\n I have read and agree to the Terms & Conditions\n\nSubmission Deadline: April 1, 2026\nNeed help? Post in Pyth Community Hackathon or check out the Pyth MCP Server and available Pyth Skills.\n\n Pinned on Mar 2\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Community Hackathon Official Rules\n\n Pyth Community Hackathon\n\n 0\n\n 566\n\n Mar 2\n\n Terms & Conditions\n\n Pyth Community Hackathon\n\n 0\n\n 227\n\n Mar 5\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n 620\n\n Mar 31\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Pyth Sentinel: How I Built a Real-time Crypto Alert & Prediction Platform Using Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 56\n\n Mar 17\n\n Powered by Discourse","tokens":1535,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260953562,"hash":"5eff4cbda050b8d5c7c3ffbae48cfd44b08c93c7"}
{"url":"https://forum.openzeppelin.com/t/cant-interact-with-token-buy-sell-or-remove-liquidity-on-pancakeswap/5982/3","domain":"forum.openzeppelin.com","title":"Can't interact with token / buy, sell or remove liquidity on Pancakeswap - Support - OpenZeppelin Forum","text":"Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2021\n\n 3 / 7\n\n Apr 2021\n\n Jul 2021\n\n post by jing on Feb 25, 2021\n\n jing\n\n using pancakeswap forked a BEP20 token and traded it with some friends for a few days then all the sudden it stopped letting us interact with it.\nToken = 0xb64B6a804c07699535641c89B03BDe89cFc5A3CD\nLP token = 0x878C5832A08BEb7A7A557978E49C5aaBC87d19e5\npancakeswap.finance\n\n post by abcoathup on Feb 25, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @jing,\nI am sorry I can’t help you with this. You may want to try a pancakeswap or a Binance community for help.\n\n 2 months later\n\n post by iulianh on Apr 29, 2021\n\n iulianh\n\n same problem here. It’s very hard to get support. They only want fees and no help.\n\n 8 days later\n\n post by defitokens on May 7, 2021\n\n defitokens\n\n I have the same problem !!\nI added tokens + liquidity, but I can’t buy it and I don’t know why\nI tried to remove the liquidity but the CONFIRM button does not work.\nLiquidity came in, but it doesn’t come out.\nI do not know the reason.\nAs the friend said, they only want fees but they don’t support it. Telegram groups have no ADM, only scam.\nThere is no support from them. Totally inaccessible.\n\n post by Royaa on May 15, 2021\n\n Royaa\n\n I am also facing same issue have you found a way to resolved, I have read some where you can try to remove on trust wallet but in my case problem is i have create on metamask account 2. its mean i have can only import this account in trustwallet with private key with ethereum network. i don’t know how to convert wallet network in BSC in trustwallet. \n\n post by aidy515 on May 20, 2021\n\n aidy515\n\n on the write contract page go to setswapliquidty write FALSE then click right , confirm in wallet and you’ll be able to withdraw all liquidity\n\n 2 months later\n\n post by 11123 on Jul 11, 2021\n\n 11123\n\n I will be able to withdraw liquidity\nEmail me on Telegram: @ Aleksandr9817\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 252\n\n Apr 2024\n\n Can not remove liquidity from my token on pancakeswap/ even simple transfer from wallet to wallet is not possible. \n\n Smart Contracts\n\n 0\n\n 153\n\n May 2024\n\n Not able to remove liquidity from Pancakeswap\n\n Contracts\n\n 1\n\n 633\n\n Aug 2021\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 882\n\n Jun 2022\n\n This transaction would fail pancakeswap Error\n\n Smart Contracts\n\n 0\n\n 1.0k\n\n May 2025","tokens":641,"squid":"ink-security_audits","role":"Sentinel","at":1791260960041,"hash":"3ff6282818e443d0ee2025a9cfca4eb546a42d08"}
{"url":"https://dev-forum.pyth.network/t/submission-template/522/2","domain":"dev-forum.pyth.network","title":"Submission Template - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2\n\n 2 / 2\n\n Mar 2\n\n Mar 2\n\n post by CHOPPAtheSHARK on Mar 2\n\n CHOPPAtheSHARK\n\n How to Submit Your Project\nCopy the template below, create a new topic in the Pyth Community Hackathon category, paste it in, and fill it out.\n\n[Project Name]\nTeam: @discord-handle-1discord-handle-1discord-handle-1discord-handle-1, @discord-handle-2 (max 2 people)\nSubmitted: [Date]\n\nAnswer Capsule\n\n[40-60 words. Self-contained summary: What does your project do, what Pyth data does it use, and why? This should make sense to someone who reads nothing else.]\n\nWhat It Does\n[2-3 sentence description. Explain the problem you’re solving or the experience you’re\ncreating.]\n\nPyth Features Used\nCheck all that apply:\n\n Price Feeds (on-chain or off-chain)\n Entropy (randomness)\n Both\n\nLinks\n\nLive Demo: [URL]\nSource Code: [GitHub/GitLab URL]\nVideo Walkthrough (optional): [YouTube/Loom URL]\n\nScreenshots / Media\n[Embed images, GIFs, or demo videos here]\n\nTech Stack\nExample: Next.js, Solana, Python Flask, LangChain, etc.\n\nFramework/Language:\nBlockchain (if applicable):\nAgent Framework (if applicable):\nDeployment:\n\nContent Contributions (Required)\nEvery submission must include at least one public post and one technical contribution. Link them here.\n\nPublic Post (Reddit, Dev.to, or Hashnode): [URL]\nTechnical Contribution (Stack Overflow answer or GitHub gist/example): [URL]\nBonus — X Platform Post: [URL]\nBonus — Wikipedia Contribution (optional): [URL or diff link]\n\nLicensing\nThis project is licensed under Apache 2.0 (required for all submissions).\n\nEligibility Confirmation\n\n I am 18+ years old\n I am not located in an OFAC-sanctioned jurisdiction\n I confirm this is an original work created during the hackathon period\n I have read and agree to the Terms & Conditions\n\nSubmission Deadline: April 1, 2026\nNeed help? Post in Pyth Community Hackathon or check out the Pyth MCP Server and available Pyth Skills.\n\n Pinned on Mar 2\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Community Hackathon Official Rules\n\n Pyth Community Hackathon\n\n 0\n\n 566\n\n Mar 2\n\n Terms & Conditions\n\n Pyth Community Hackathon\n\n 0\n\n 227\n\n Mar 5\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n 620\n\n Mar 31\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Pyth Sentinel: How I Built a Real-time Crypto Alert & Prediction Platform Using Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 56\n\n Mar 17\n\n Powered by Discourse","tokens":1529,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260967148,"hash":"3e3aacb61df408db8a40e85b2f416378713e03f6"}
{"url":"https://dev-forum.pyth.network/t/terms-conditions/527/1","domain":"dev-forum.pyth.network","title":"Terms & Conditions - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Terms & Conditions \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 5\n\n 1 / 2\n\n Mar 5\n\n Mar 5\n\n post by CHOPPAtheSHARK on Mar 5\n\n CHOPPAtheSHARK\n\n Pyth Playground — Terms & Conditions\n\n1. Overview\n1.1 Main Parties\n\nPyth Playground (the “Hackathon”) is a community-driven event organized by PYTH DAO LLC, PO Box 852, Long Islands Rd Majuro, Marshall Islands MH 96960 (the “Organizer”, the “DAO” or “we”). The Hackathon encourages participants to build open-source projects utilizing Pyth Network capabilities.\n\n“Participant” or “you” refer to any individual taking part in the Hackathon and agreeing to these Terms & Conditions as part of their participation.\n\nThe Pyth Community Council (the “Council”) is an elected body of the Organizer responsible for the management of community platforms, initiatives, campaigns and other programs which develop community engagement within the DAO. The Council operates with its own allocated budget and governance structure. The Council is the corporate body within the DAO responsible for organizing the Hackathon.\n\n1.2 Independence of Other Pyth Legal Entities\n\nThe DAO operates independently from the Pyth Data Association, Grabenstrase 25, 6340 Baar, a non-profit association incorporated under the laws of Switzerland, under registration number CHE-325.103.020 (“PDA”). The Hackathon, these Terms and Conditions, any other contractual or other legal obligations entered into by the Participant are not entered into with the PDA, nor does the PDA sponsor, organize or participate in the Hackathon.\n\n1.3 Binding Effect of Terms & Conditions\n\nThese Terms and Conditions constitute a legally binding agreement between the Organizer and each Participant. By registering for, accessing, or participating in the Hackathon, the Participant confirms their full acceptance of, and agreement to be bound by, these Terms and Conditions.\n\nIf the Council determines that a Participant has breached these Terms & Conditions, the Council may, with immediate effect, disqualify the Participant (or their team) from the Hackathon and/or revoke prize eligibility.\n\n2. Participant Eligibility Requirements\n\nParticipation in the Hackathon is subject to the Participant’s compliance with the requirements set out in this Section 2, which apply at the start of, during, and at the end of the Hackathon.\n\n2.1 Age\n\nThe Participant must be 18 years of age or older at the time of registration.\n\n2.2 Excluded Jurisdictions\n\nParticipants located in, ordinarily resident in, or nationals of countries or territories subject to comprehensive sanctions are not eligible to participate. This includes, without limitation:\n\nNorth Korea\n\nIran\n\nCuba\n\nCrimea region\n\nMyanmar\n\nDonetsk People’s Republic\n\nLuhansk People’s Republic\n\nSyria\n\nAny other jurisdiction subject to OFAC comprehensive sanctions\n\nBy participating, the Participant represents and warrants that they are not located in, ordinarily resident in, or a national of any such restricted jurisdiction.\n\n2.3 Teams\n\nParticipation is permitted individually or in teams of no more than two participants. All team members must individually satisfy the eligibility requirements set out in Section 2 of these Terms and Conditions. Each Participant may be a member of only one team per Hackathon.\n\n2.4 Participants Making a Contribution to the DAO\n\nParticipants who regularly contribute to the DAO (a “Contribution” meaning any recurring or ongoing provision of services or work product to or for the DAO, whether paid or unpaid, including as an employee, contractor, advisor, service provider, contributor, staker or volunteer) are permitted to participate in the Hackathon; however, they are excluded from eligibility to receive any prize.\n\nEach Participant must disclose at the application stage whether they make, or reasonably expect to make during the Hackathon, a Contribution.\n\nFor the avoidance of doubt, participation in the Hackathon does not create any employment, contractor, partnership or agency relationship between the Organizer and any Participant.\n\n3. Project Submission and Requirements\n3.1 Submission Requirements\n\nEach project must be submitted no later than April 1st, 2026. Late submissions may be rejected. The Organizer will provide a submission process, further set out in the Hackathon announcement (the “Official Submission Process”).\n\nThe submission must satisfy any content requirements set out in the Hackathon announcement.\n\n3.2 Technical Requirements\n\nAll submissions must:\n\ni. Utilize at least one Pyth Network feature (Price Feeds, Entropy, or Pyth Pro); ii. Include a working demonstration or live deployment; iii. Provide source code via public repository (GitHub, GitLab, etc.); iv. Post about your project on Reddit, Dev.to, or equivalent platform; and v. Be submitted through the Official Submission Process before the deadline.\n3.3 Licensing Requirements\n\nAll submissions must be released under the Apache License 2.0, consistent with Pyth Network’s own licensing. By submitting an entry, the Participant represents and warrants that they have the right to license the submission under the Apache License 2.0 and agree that the submission will be publicly available and may be reproduced, modified and distributed by the public in accordance with the terms of that license.\n\n3.4 Intellectual Property\n\nThe Participant retains all ownership and intellectual property rights in their submissions and any underlying code, designs, or content created during the Hackathon, subject to the licenses granted herein.\n\nThe Participant represents and warrants that their participation in the Hackathon is done in their individual capacity, and not as a representative or agent of any employer, university, or other organization, and that they are not bound by any contractual restrictions with any other third party which may limit their ability to participate in the Hackathon and to fully comply with these Terms & Conditions.\n\nThe Participant is responsible for ensuring that their submission does not infringe upon the intellectual property rights of any third party. If a submission incorporates third-party code or assets, the Participant must ensure they have the necessary licenses or permissions for such use and must clearly attribute all third-party intellectual property.\n\nUse of Pyth Network branding must comply with official brand guidelines. Submissions may reference Pyth but should not imply official endorsement.\n\n3.5 Winning & Judging\n\nIf there is a winner of the Hackathon, the Organizer reserves the right to determine the winner, including the composition of the panel of judges.\n\n4. Prize\n\nIf a winner is selected for the Hackathon, such winner shall be entitled to receive a prize as determined by the Organizer. Prizes are awarded in PYTH tokens. The prize amounts and structure shall be set out in the Hackathon announcement. The Organizer reserves the right to modify the prize amount and structure for subsequent iterations of the Hackathon.\n\nThe Participant acknowledges that distribution of any prize is contingent upon passing of KYC identification requirements imposed by the Organizer. If the Participant fails or refuses to provide such information or fails any required checks, the Participant may be disqualified from prize eligibility and the prize may be withheld or reallocated to another Participant.\n\n5. Disqualification\n\nThe Council may, at its sole and absolute discretion, disqualify any submission at any time for any reason, including if it determines that the submission: (i) violates any eligibility requirements; (ii) contains plagiarized, infringing or misappropriated code; (iii) includes malicious, harmful or deceptive functionality; (iv) violates any applicable laws or regulations; or (v) misrepresents Pyth integration or functionality. All determinations of the Council are final and binding.\n\n6. Liability\n6.1 No Guarantees\n\nParticipation in the Hackathon does not guarantee receipt of any prize, reward, or recognition.\n\nThe Council reserves the right to modify, suspend, or cancel the Hackathon at any time, for any reason, and without prior notice.\n\nTechnical issues, failures, delays or limitations relating to Pyth network services (including, but not limited to data feeds, APIs, smart contracts, or infrastructure) do not constitute grounds for appeal and do not create any obligation for the Organizer.\n\n6.2 Cryptocurrency Risks\n\nParticipants acknowledge and agree that any PYTH tokens awarded or transferred in connection with the Hackathon are subject to significant price volatility and may lose some or all of their value, that token transfers and any prize distribution may be delayed, or otherwise affected by blockchain and network conditions (including congestion, forks, outages, validator or RPC issues) and may incur network fees, that the Organizer is not responsible or liable for any losses arising from wallet or address errors (including incorrect wallet addresses provided by a Participant), loss of private keys or seed phrases, compromised wallets, phishing or other security incidents, or any irreversible or failed transfer, and that the legal and regulatory treatment of tokens and token transfers (including tax reporting and liability) varies by jurisdiction and may change, and each Participant is solely responsible for ensuring their participation in the Hackathon and receipt, holding, use and/or transfer of any tokens complies with applicable laws and for obtaining independent legal and tax advice where needed.\n\n6.3 Limitation of Liability\n\nTo the maximum extent permitted by law, the Organizer, the Council, PDA, and its affiliates shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from your participation in the Hackathon.\n\n6.4 Third-Party Platforms\n\nThe DAO or the Council might ask the Participant to use a third-party platform to participate in the Hackathon. Any use of a third-party platform (like GitHub, Discord, Discourse etc.) is governed solely by that third party’s applicable terms of service, acceptable use policies, and privacy policies, and participants are responsible for reviewing and accepting (and continuing to comply with) such terms. The Organizer is not affiliated with, does not control, and does not endorse any third-party platforms, and it does not provide any support, representations, warranties, or guarantees regarding the availability, security, functionality, or suitability of any third-party platform.\n\n7. Tax Obligations\n\nToken prizes have monetary value and may constitute taxable income in the Participant’s jurisdiction.\n\nThe Participant is solely responsible for compliance with their local tax obligations arising from token rewards.\n\n8. Privacy & Data\n8.1 Data Collection\n\nBy registering for and participating in the Hackathon, the Participant acknowledges and consents that the Organizer may collect and process the following categories of personal data:\n\ni. Discord handle and/or Pyth forum username; ii. Wallet address for the purpose of prize distribution; iii. Submission materials and associated metadata; and iv. Any additional information voluntarily provided by the Participant during registration.\n\nIf the Participant is selected as a winner (or potential winner), the Organizer (and/or its designated KYC or payment service provider) may require the Participant to complete identity verification and screening checks in order to receive any prize, including by providing valid government-issued photographic identification and proof of address (for example, a recent utility bill or bank statement) and any other information reasonably required to comply with applicable laws and regulations (including anti-money laundering, sanctions and counter-terrorist financing requirements).\n\n8.2 Use and Sharing of Data\n\nThe data collected pursuant to Section 8.1 will be used solely for the following purposes:\n\ni. Hackathon administration, operation and communication; ii. Verification of Participant eligibility and compliance with these Terms and Conditions; iii. Prize distribution; and iv. Public display, promotion of submissions and winners.\n\nTo the extent necessary for the purposes set out above, personal data may be shared with third parties, including but not limited to service providers, partners, and competent authorities. This includes sharing relevant personal data with the PDA and/or other designated third-party providers for the purposes of conducting KYC, AML, or similar compliance checks in connection with prize distribution.\n\nAll third parties receiving personal data will process such data in accordance with applicable data protection laws and solely for the purposes for which it is disclosed.\n\n8.3 Data Retention\n\nSubmission data and winner information may be retained indefinitely for record-keeping, historical and promotional purposes. Contact and registration information will be retained for the duration of the Hackathon and for up to twelve (12) months thereafter, unless a longer retention period is required or permitted by applicable law.\n\n9. Modifications\n\nThe Council reserves the right to modify these terms at any time. Material changes will be communicated through official channels. The Participant agrees that continued participation after modifications constitutes acceptance.\n\n10. Failure to Comply\n\nFailure to comply with these Terms and Conditions may imply your immediate disqualification from the Hackathon. Additionally, we reserve the right to take any available legal action against you if you fail to comply with these Terms and Conditions, including enforcement of our intellectual property rights.\n\n11. Governing Law and Jurisdiction\n11.1 Governing Law\n\nThese Terms and Conditions shall be governed by and construed in accordance with the substantive laws of Marshall Islands, to the exclusion of the principles of conflicts of laws thereof.\n\n11.2 Jurisdiction\n\nThese Terms and Conditions are intended as guidelines for a decentralized community initiative. Prior to engaging in traditional methods of dispute resolution, disputes should be resolved through the Organizer’s community governance processes where possible.\n\nAny dispute, controversy or claim arising out of or in relation to these Terms and Conditions or future non-contractual claims including the validity, invalidity, enforceability, interpretation, execution, breach, modification or termination thereof, shall be submitted to the exclusive jurisdiction of the courts of Marshall Islands.\n\n Pyth Community Hackathon Official Rules\n\n Submission Template\n\n FOGO Pulse - A binary trading platform - live\n\n Price Prediction Grids on Pyth Price Feed\n\n Walk The Planck\n\n read \n\n 5\n min\n\n Pinned on Mar 5\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Community Hackathon Official Rules\n\n Pyth Community Hackathon\n\n 0\n\n 566\n\n Mar 2\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n 620\n\n Mar 31\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 283\n\n Mar 2\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 23\n\n Mar 28\n\n Powered by Discourse","tokens":4712,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791260978647,"hash":"c48f6f247ef042353ad2306d075dbbc08bf73a17"}
{"url":"https://forum.openzeppelin.com/t/cant-interact-with-token-buy-sell-or-remove-liquidity-on-pancakeswap/5982/8","domain":"forum.openzeppelin.com","title":"Can't interact with token / buy, sell or remove liquidity on Pancakeswap - Support - OpenZeppelin Forum","text":"Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2021\n\n 7 / 7\n\n Jul 2021\n\n Jul 2021\n\n post by jing on Feb 25, 2021\n\n jing\n\n using pancakeswap forked a BEP20 token and traded it with some friends for a few days then all the sudden it stopped letting us interact with it.\nToken = 0xb64B6a804c07699535641c89B03BDe89cFc5A3CD\nLP token = 0x878C5832A08BEb7A7A557978E49C5aaBC87d19e5\npancakeswap.finance\n\n post by abcoathup on Feb 25, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @jing,\nI am sorry I can’t help you with this. You may want to try a pancakeswap or a Binance community for help.\n\n 2 months later\n\n post by iulianh on Apr 29, 2021\n\n iulianh\n\n same problem here. It’s very hard to get support. They only want fees and no help.\n\n 8 days later\n\n post by defitokens on May 7, 2021\n\n defitokens\n\n I have the same problem !!\nI added tokens + liquidity, but I can’t buy it and I don’t know why\nI tried to remove the liquidity but the CONFIRM button does not work.\nLiquidity came in, but it doesn’t come out.\nI do not know the reason.\nAs the friend said, they only want fees but they don’t support it. Telegram groups have no ADM, only scam.\nThere is no support from them. Totally inaccessible.\n\n post by Royaa on May 15, 2021\n\n Royaa\n\n I am also facing same issue have you found a way to resolved, I have read some where you can try to remove on trust wallet but in my case problem is i have create on metamask account 2. its mean i have can only import this account in trustwallet with private key with ethereum network. i don’t know how to convert wallet network in BSC in trustwallet. \n\n post by aidy515 on May 20, 2021\n\n aidy515\n\n on the write contract page go to setswapliquidty write FALSE then click right , confirm in wallet and you’ll be able to withdraw all liquidity\n\n 2 months later\n\n post by 11123 on Jul 11, 2021\n\n 11123\n\n I will be able to withdraw liquidity\nEmail me on Telegram: @ Aleksandr9817\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 252\n\n Apr 2024\n\n Can not remove liquidity from my token on pancakeswap/ even simple transfer from wallet to wallet is not possible. \n\n Smart Contracts\n\n 0\n\n 153\n\n May 2024\n\n Not able to remove liquidity from Pancakeswap\n\n Contracts\n\n 1\n\n 633\n\n Aug 2021\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 882\n\n Jun 2022\n\n This transaction would fail pancakeswap Error\n\n Smart Contracts\n\n 0\n\n 1.0k\n\n May 2025","tokens":641,"squid":"ink-security_audits","role":"Sentinel","at":1791260980378,"hash":"97f4d849469d264ca3adb166bfacaa1f074ad44e"}
{"url":"https://forum.openzeppelin.com/t/cant-remove-liquidity-on-v2-pancakeswap/40137/1","domain":"forum.openzeppelin.com","title":"Can't remove liquidity on v2 pancakeswap - Smart Contracts - OpenZeppelin Forum","text":"Can’t remove liquidity on v2 pancakeswap \n\n Smart Contracts\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by jarvis on Apr 6, 2024\n\n jarvis\n\n Pancakeswap says \"ERROR, This transaction would fail\", I have almost $94 trapped in that liquidity so anyone who can help will tip smth\nI own the contract 0xd577f2e407e3fab441ffdc3bc1575ccaf4290740 https://bscscan.com/token/0xd577f2e407e3fab441ffdc3bc1575ccaf4290740#readContract it was a project that never finished\nTried Solutions :\nX - Receive WBNB instead of BNB\nX - Tried it on multiple browsers as well as on metamask app on android\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 882\n\n Jun 2022\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 20\n\n 12.3k\n\n Aug 2025\n\n HELP Can’t remove liquidity on pcs v2\n\n Smart Contracts\n\n 4\n\n 887\n\n Nov 2022\n\n This transaction would fail , stuck liquidity error\n\n Smart Contracts\n\n 0\n\n 36\n\n Apr 2025\n\n Can not remove liquidity from my token on pancakeswap/ even simple transfer from wallet to wallet is not possible. \n\n Smart Contracts\n\n 0\n\n 153\n\n May 2024","tokens":316,"squid":"ink-security_audits","role":"Sentinel","at":1791261002523,"hash":"7d643e7eaa2c94e1463dff80e98d6f7ca787f0d4"}
{"url":"https://specs.optimism.io/protocol/proposals.html","domain":"specs.optimism.io","title":"Proposals - OP Stack Specification","text":"L2 Output Root Proposals Specification\n\nTable of Contents\n\nOverview\nProposing L2 Output Commitments\n\nL2OutputOracle v1.0.0\n\nL2 Output Commitment Construction\nL2 Output Oracle Smart Contract\n\nConfiguration\n\nSecurity Considerations\n\nL1 Reorgs\n\nOverview\nAfter processing one or more blocks the outputs will need to be synchronized with the settlement layer (L1)\nfor trustless execution of L2-to-L1 messaging, such as withdrawals.\nThese output proposals act as the bridge's view into the L2 state.\nActors called \"Proposers\" submit the output roots to the settlement layer (L1) and can be contested with a fault proof,\nwith a bond at stake if the proof is wrong. The op-proposer in one such implementation of a proposer.\nNote: Fault proofs on Optimism are not fully specified at this time. Although fault proof\nconstruction and verification is implemented in Cannon,\nthe fault proof game specification and integration of a output-root challenger into the rollup-node\nare part of later specification milestones.\nProposing L2 Output Commitments\nThe proposer's role is to construct and submit output roots, which are commitments to the L2's state,\nto the L2OutputOracle contract on L1 (the settlement layer). To do this, the proposer periodically\nqueries the rollup node for the latest output root derived from the latest\nfinalized L1 block. It then takes the output root and\nsubmits it to the L2OutputOracle contract on the settlement layer (L1).\nL2OutputOracle v1.0.0\nThe submission of output proposals is permissioned to a single account. It is expected that this\naccount will continue to submit output proposals over time to ensure that user withdrawals do not halt.\nThe L2 output proposer is expected to submit output roots on a deterministic\ninterval based on the configured SUBMISSION_INTERVAL in the L2OutputOracle. The larger\nthe SUBMISSION_INTERVAL, the less often L1 transactions need to be sent to the L2OutputOracle\ncontract, but L2 users will need to wait a bit longer for an output root to be included in L1 (the settlement layer)\nthat includes their intention to withdraw from the system.\nThe honest op-proposer algorithm assumes a connection to the L2OutputOracle contract to know\nthe L2 block number that corresponds to the next output proposal that must be submitted. It also\nassumes a connection to an op-node to be able to query the optimism_syncStatus RPC endpoint.\nimport time\n\nwhile True:\n next_checkpoint_block = L2OutputOracle.nextBlockNumber()\n rollup_status = op_node_client.sync_status()\n if rollup_status.finalized_l2.number >= next_checkpoint_block:\n output = op_node_client.output_at_block(next_checkpoint_block)\n tx = send_transaction(output)\n time.sleep(poll_interval)\n\nA CHALLENGER account can delete multiple output roots by calling the deleteL2Outputs() function\nand specifying the index of the first output to delete, this will also delete all subsequent outputs.\nL2 Output Commitment Construction\nThe output_root is a 32 byte string, which is derived based on the a versioned scheme:\noutput_root = keccak256(version_byte || payload)\n\nwhere:\n\nversion_byte (bytes32) a simple version string which increments anytime the construction of the output root\nis changed.\n\npayload (bytes) is a byte string of arbitrary length.\n\nIn the initial version of the output commitment construction, the version is bytes32(0), and the payload is defined\nas:\npayload = state_root || withdrawal_storage_root || latest_block_hash\n\nwhere:\n\nThe latest_block_hash (bytes32) is the block hash for the latest L2 block.\n\nThe state_root (bytes32) is the Merkle-Patricia-Trie (MPT) root of all execution-layer accounts.\nThis value is frequently used and thus elevated closer to the L2 output root, which removes the need to prove its\ninclusion in the pre-image of the latest_block_hash. This reduces the merkle proof depth and cost of accessing the\nL2 state root on L1.\n\nThe withdrawal_storage_root (bytes32) elevates the Merkle-Patricia-Trie (MPT) root of the Message\nPasser contract storage. Instead of making an MPT proof for a\nwithdrawal against the state root (proving first the storage root of the L2toL1MessagePasser against the state root,\nthen the withdrawal against that storage root), we can prove against the L2toL1MessagePasser's storage root directly,\nthus reducing the verification cost of withdrawals on L1.\nAfter Isthmus hard fork, the withdrawal_storage_root is present in the\nblock header as withdrawalsRoot and can be used directly, instead of computing\nthe storage root of the L2toL1MessagePasser contract.\nSimilarly, if Isthmus hard fork is active at the genesis block, the withdrawal_storage_root is present\nin the block header as withdrawalsRoot.\n\nL2 Output Oracle Smart Contract\nL2 blocks are produced at a constant rate of L2_BLOCK_TIME (2 seconds).\nA new L2 output MUST be appended to the chain once per SUBMISSION_INTERVAL which is based on a number of blocks.\nThe exact number is yet to be determined, and will depend on the design of the fault proving game.\nThe L2 Output Oracle contract implements the following interface:\n/**\n * @notice The number of the first L2 block recorded in this contract.\n */\nuint256 public startingBlockNumber;\n\n/**\n * @notice The timestamp of the first L2 block recorded in this contract.\n */\nuint256 public startingTimestamp;\n\n/**\n * @notice Accepts an L2 outputRoot and the timestamp of the corresponding L2 block. The\n * timestamp must be equal to the current value returned by `nextTimestamp()` in order to be\n * accepted.\n * This function may only be called by the Proposer.\n *\n * @param _l2Output The L2 output of the checkpoint block.\n * @param _l2BlockNumber The L2 block number that resulted in _l2Output.\n * @param _l1Blockhash A block hash which must be included in the current chain.\n * @param _l1BlockNumber The block number with the specified block hash.\n*/\n function proposeL2Output(\n bytes32 _l2Output,\n uint256 _l2BlockNumber,\n bytes32 _l1Blockhash,\n uint256 _l1BlockNumber\n )\n\n/**\n * @notice Deletes all output proposals after and including the proposal that corresponds to\n * the given output index. Only the challenger address can delete outputs.\n *\n * @param _l2OutputIndex Index of the first L2 output to be deleted. All outputs after this\n * output will also be deleted.\n */\nfunction deleteL2Outputs(uint256 _l2OutputIndex) external\n\n/**\n * @notice Computes the block number of the next L2 block that needs to be checkpointed.\n */\nfunction nextBlockNumber() public view returns (uint256)\n\nConfiguration\nThe startingBlockNumber must be at least the number of the first Bedrock block.\nThe startingTimestamp MUST be the same as the timestamp of the start block.\nThe first outputRoot proposed will thus be at height startingBlockNumber + SUBMISSION_INTERVAL\nSecurity Considerations\nL1 Reorgs\nIf the L1 has a reorg after an output has been generated and submitted, the L2 state and correct output may change\nleading to a faulty proposal. This is mitigated against by allowing the proposer to submit an\nL1 block number and hash to the Output Oracle when appending a new output; in the event of a reorg, the block hash\nwill not match that of the block with that number and the call will revert.","tokens":1792,"squid":"ink-governance","role":"Council Listener","at":1791261003002,"hash":"4349ac8df0da1c97bafe0b6d18b9a85bf614f872"}
{"url":"https://forum.openzeppelin.com/t/can-t-remove-liquidity-on-pancakeswap-v2/29722","domain":"forum.openzeppelin.com","title":"Can’t remove liquidity on pancakeswap v2 - Smart Contracts - OpenZeppelin Forum","text":"Can’t remove liquidity on pancakeswap v2 \n\n Smart Contracts\n\n etherscan-verify,bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2022\n\n 1 / 3\n\n Jun 2022\n\n Jun 2022\n\n post by Crispypotato on Jun 17, 2022\n\n Crispypotato\n\n So I've come accross so many topics over the internet and hit a dead end.\nthis is basically a Token-BNB liquidity and it happened I can't pull it out. Pancakeswap says \"ERROR, This transaction would fail\", I have almost $40,000 trapped in that liquidity so I'm giving away a bounty - It's better to give something or it might end up trapped forever.\nI own the contract and its interacted with PC router and Factory\nTried Solutions :\nX - Receive WBNB instead of BNB\nX - Tried it on multiple browsers as well as on metamask app on android\nX - Tried Approving the owner to the contracts\nX - Tried increaseallowance\nI found someone on an old github post telling setSwapAndLiquifyEnabled set to false but I happen can't find it.\nConsole error :\nremoveLiquidityETHWithPermit\nremoveLiquidityETHWithPermitSupportingFeeOnTransferTokens\nPC router\nI am giving anyone who can help remove the liquidity a $1,000 BNB REWARD!\nHERE IS A MODEL OF THE TOKEN CONTRACT: https://bscscan.com/token/0x328d0aa10e6087af2c1a0bd16d3455bf3acd92aa#writeContract\nThe token I am trying to remove liquidity from is just like this, please let me know if theres a way to remove! Thanks\n\n post by Team_X on Jun 23, 2022\n\n Team_X\n\n Hey! I had problems like this on the testnet. I never found a real solution to it. The only thing that worked was if I tried pulling all liquidity it would stop me.\nIf there is a max transaction limit in the contract of 2% then you can only transfer 2%\nIf there is a burn or tax fee then you may need to increase slippage. This are the only 2 things that you can try.\n\n post by minh_trng on Jun 23, 2022\n\n minh_trng\n\n the token you linked as a \"model\" has no verified source code. Does the token you put your money into has verified source code? also, did the project rug pull or is it still active?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 20\n\n 12.3k\n\n Aug 2025\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024\n\n HELP Can’t remove liquidity on pcs v2\n\n Smart Contracts\n\n 4\n\n 887\n\n Nov 2022\n\n Cannot remove liquidity from a BSC token - 200$ bounty\n\n Developer Wanted\n\n etherscan-verify\n\n 2\n\n 807\n\n May 2023\n\n Solved! Unable To Withdraw Liquidity From My Token\n\n Smart Contracts\n\n bep20\n\n 1\n\n 4.7k\n\n Dec 2021","tokens":661,"squid":"ink-security_audits","role":"Sentinel","at":1791261014277,"hash":"b0a7cfc89aa927e767508b5f9be1f73322f0e063"}
{"url":"https://specs.optimism.io/protocol/withdrawals.html","domain":"specs.optimism.io","title":"Withdrawals - OP Stack Specification","text":"Withdrawals\n\nTable of Contents\n\nOverview\nWithdrawal Flow\n\nOn L2\nOn L1\n\nThe L2ToL1MessagePasser Contract\n\nAddresses are not Aliased on Withdrawals\n\nThe Optimism Portal Contract\nWithdrawal Verification and Finalization\nSecurity Considerations\n\nKey Properties of Withdrawal Verification\nHandling Successfully Verified Messages That Fail When Relayed\nOptimismPortal can send arbitrary messages on L1\n\nOverview\nWithdrawals are cross domain transactions which are initiated on L2, and finalized by a transaction\nexecuted on L1. Notably, withdrawals may be used by an L2 account to call an L1 contract, or to transfer ETH from\nan L2 account to an L1 account.\nVocabulary note: withdrawal can refer to the transaction at various stages of the process, but we introduce\nmore specific terms to differentiate:\n\nA withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.\nA withdrawal proving transaction refers specifically to an L1 transaction\nwhich proves the withdrawal is correct (that it has been included in a merkle\ntree whose root is available on L1).\nA withdrawal finalizing transaction refers specifically to an L1 transaction which finalizes and relays the\nwithdrawal.\n\nWithdrawals are initiated on L2 via a call to the Message Passer predeploy contract, which records the important\nproperties of the message in its storage.\nWithdrawals are proven on L1 via a call to the OptimismPortal, which proves the inclusion of this withdrawal message.\nWithdrawals are finalized on L1 via a call to the OptimismPortal contract,\nwhich verifies that the fault challenge period has passed since the withdrawal message has been proved.\nIn this way, withdrawals are different from deposits which make use of a special transaction type in the\nexecution engine client. Rather, withdrawals transaction must use smart contracts on L1 for\nfinalization.\nWithdrawal Flow\nWe first describe the end to end flow of initiating and finalizing a withdrawal:\nOn L2\nAn L2 account sends a withdrawal message (and possibly also ETH) to the L2ToL1MessagePasser predeploy contract.\nThis is a very simple contract that stores the hash of the withdrawal data.\nOn L1\n\nA relayer submits a withdrawal proving transaction with the required inputs\nto the OptimismPortal contract.\nThe relayer is not necessarily the same entity which initiated the withdrawal on L2.\nThese inputs include the withdrawal transaction data, inclusion proofs, and a block number. The block number\nmust be one for which an L2 output root exists, which commits to the withdrawal as registered on L2.\nThe OptimismPortal contract retrieves the output root for the given block number from the L2OutputOracle's\ngetL2Output() function, and performs the remainder of the verification process internally.\nIf proof verification fails, the call reverts. Otherwise the hash is recorded to prevent it from being re-proven.\nNote that the withdrawal can be proven more than once if the corresponding output root changes.\nAfter the withdrawal is proven, it enters a 7 day challenge period, allowing time for other network participants\nto challenge the integrity of the corresponding output root.\nOnce the challenge period has passed, a relayer submits a withdrawal finalizing transaction to the\nOptimismPortal contract.\nThe relayer doesn't need to be the same entity that initiated the withdrawal on L2.\nThe OptimismPortal contract receives the withdrawal transaction data and verifies that the withdrawal has\nboth been proven and passed the challenge period.\nIf the requirements are not met, the call reverts. Otherwise the call is forwarded, and the hash is recorded to\nprevent it from being replayed.\n\nThe L2ToL1MessagePasser Contract\nA withdrawal is initiated by calling the L2ToL1MessagePasser contract's initiateWithdrawal function.\nThe L2ToL1MessagePasser is a simple predeploy contract at 0x4200000000000000000000000000000000000016\nwhich stores messages to be withdrawn.\ninterface L2ToL1MessagePasser {\n event MessagePassed(\n uint256 indexed nonce, // this is a global nonce value for all withdrawal messages\n address indexed sender,\n address indexed target,\n uint256 value,\n uint256 gasLimit,\n bytes data,\n bytes32 withdrawalHash\n );\n\n event WithdrawerBalanceBurnt(uint256 indexed amount);\n\n function burn() external;\n\n function initiateWithdrawal(address _target, uint256 _gasLimit, bytes memory _data) payable external;\n\n function messageNonce() public view returns (uint256);\n\n function sentMessages(bytes32) view external returns (bool);\n}\n\nThe MessagePassed event includes all of the data that is hashed and\nstored in the sentMessages mapping, as well as the hash itself.\nAddresses are not Aliased on Withdrawals\nWhen a contract makes a deposit, the sender's address is aliased. The same is not true\nof withdrawals, which do not modify the sender's address. The difference is that:\n\non L2, the deposit sender's address is returned by the CALLER opcode, meaning a contract cannot easily tell if the\ncall originated on L1 or L2, whereas\non L1, the withdrawal sender's address is accessed by calling the l2Sender() function on the OptimismPortal\ncontract.\n\nCalling l2Sender() removes any ambiguity about which domain the call originated from. Still, developers will need to\nrecognize that having the same address does not imply that a contract on L2 will behave the same as a contract on L1.\nThe Optimism Portal Contract\nThe Optimism Portal serves as both the entry and exit point to the Optimism L2. It is a contract which inherits from\nthe OptimismPortal contract, and in addition provides the following interface for\nwithdrawals:\n\nWithdrawalTransaction type\nOutputRootProof type\n\ninterface OptimismPortal {\n\n event WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success);\n\n function l2Sender() returns(address) external;\n\n function proveWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx,\n uint256 _l2OutputIndex,\n Types.OutputRootProof calldata _outputRootProof,\n bytes[] calldata _withdrawalProof\n ) external;\n\n function finalizeWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx\n ) external;\n}\n\nWithdrawal Verification and Finalization\nThe following inputs are required to prove and finalize a withdrawal:\n\nWithdrawal transaction data:\n\nnonce: Nonce for the provided message.\nsender: Message sender address on L2.\ntarget: Target address on L1.\nvalue: ETH to send to the target.\ndata: Data to send to the target.\ngasLimit: Gas to be forwarded to the target.\n\nProof and verification data:\n\nl2OutputIndex: The index in the L2 outputs where the applicable output root may be found.\noutputRootProof: Four bytes32 values which are used to derive the output root.\nwithdrawalProof: An inclusion proof for the given withdrawal in the L2ToL1MessagePasser contract.\n\nThese inputs must satisfy the following conditions:\n\nThe l2OutputIndex must be the index in the L2 outputs that contains the applicable output root.\nL2OutputOracle.getL2Output(l2OutputIndex) returns a non-zero OutputProposal.\nThe keccak256 hash of the outputRootProof values is equal to the outputRoot.\nThe withdrawalProof is a valid inclusion proof demonstrating that a hash of the Withdrawal transaction data\nis contained in the storage of the L2ToL1MessagePasser contract on L2.\n\nSecurity Considerations\nKey Properties of Withdrawal Verification\n\nIt should not be possible to 'double spend' a withdrawal, ie. to relay a withdrawal on L1 which does not\ncorrespond to a message initiated on L2. For reference, see this writeup of a vulnerability\nof this type found on Polygon.\n\nFor each withdrawal initiated on L2 (i.e. with a unique messageNonce()), the following properties must hold:\n\nIt should only be possible to prove the withdrawal once, unless the outputRoot for the withdrawal\nhas changed.\nIt should only be possible to finalize the withdrawal once.\nIt should not be possible to relay the message with any of its fields modified, ie.\n\nModifying the sender field would enable a 'spoofing' attack.\nModifying the target, data, or value fields would enable an attacker to dangerously change the\nintended outcome of the withdrawal.\nModifying the gasLimit could make the cost of relaying too high, or allow the relayer to cause execution\nto fail (out of gas) in the target.\n\nHandling Successfully Verified Messages That Fail When Relayed\nIf the execution of the relayed call fails in the target contract, it is unfortunately not possible to determine\nwhether or not it was 'supposed' to fail, and whether or not it should be 'replayable'. For this reason, and to\nminimize complexity, we have not provided any replay functionality, this may be implemented in external utility\ncontracts if desired.\nOptimismPortal can send arbitrary messages on L1\nThe L2ToL1MessagePasser contract's initiateWithdrawal function accepts a _target address and _data bytes,\nwhich is passed to a CALL opcode on L1 when finalizeWithdrawalTransaction is called after the challenge\nperiod. This means that, by design, the OptimismPortal contract can be used to send arbitrary transactions on\nthe L1, with the OptimismPortal as the msg.sender.\nThis means users of the OptimismPortal contract should be careful what permissions they grant to the portal.\nFor example, any ERC20 tokens mistakenly sent to the OptimismPortal contract are essentially lost, as they can\nbe claimed by anybody that pre-approves transfers of this token out of the portal, using the L2 to initiate the\napproval and the L1 to prove and finalize the approval (after the challenge period).","tokens":2379,"squid":"ink-governance","role":"Council Listener","at":1791261014326,"hash":"a9e7b64264af93a863f5d4b41f5cb06b0f9e05ec"}
{"url":"https://io.net/","domain":"io.net","title":"The Open Source AI Infrastructure Platform - io.net - io.net","text":"70% cheaper than AWS.Zero waitlists.H100s, A100s, and full clusters on demand. io.net is the GPU cloud built for AI teams who can't afford to wait.Get StartedTrusted by top AI startupsFocus on building,not your runwayFocus on building,not your runwayAccess GPUs instantlyDeploy in minutes with thousands of secure, fully orchestrated global GPU clusters. No waitlists, no approval process, no enterprise contracts.Get unmatched flexibilityMix GPU types, adjust on the fly, and only pay only for what you use. Scale up for training, scale down for inference. No minimums or lock-in.Save up to 70%H100s from $2.19/hr vs AWS at $6.88/hr. Transparent pricing, no hidden fees. Most startups save $10k+ monthly.Increase resilience and securityWith a globally distributed network, and available confidential compute, your project is protected against centralzied outages and your data stays safe.Instant access at 70% lower costsSecurely connect to GPUs from independent data centers, mining operations, and private clusters worldwide. Better prices, faster access, no long contracts, and no single point of failure.H100Nvidia4xAmount80 GBVRAMPer Card6.4 TBStoragePrice From:$16.28/hrDeploy ClusterH100Nvidia4xAmount80 GBVRAMPer Card6.4 TBStoragePrice From:$16.28/hrDeploy ClusterA100Nvidia8xAmount80 GBVRAMPer Card4.9 TBStoragePrice From:$10.50/hrDeploy ClusterV100_32GNvidia4xAmount32 GBVRAMPer Card1000 GBStoragePrice From:$9.83/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card3.2 TBStoragePrice From:$8.45/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card6 TBStoragePrice From:$7.32/hrDeploy ClusterL40SNvidia8xAmount48 GBVRAMPer Card4.9 TBStoragePrice From:$6.72/hrDeploy ClusterV100Nvidia4xAmount32 GBVRAMPer Card3.5 TBStoragePrice From:$6.30/hrDeploy Cluster6000 ADANvidia8xAmount48 GBVRAMPer Card2.7 TBStoragePrice From:$5.46/hrDeploy ClusterV100_32GNvidia2xAmount32 GBVRAMPer Card500 GBStoragePrice From:$4.91/hrDeploy ClusterRTXPRO6000Nvidia2xAmount96 GBVRAMPer Card800 GBStoragePrice From:$4.61/hrDeploy ClusterRTX6000AdaNvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$4.07/hrDeploy ClusterA6000Nvidia8xAmount48 GBVRAMPer Card2.5 TBStoragePrice From:$3.95/hrDeploy ClusterA30Nvidia2xAmount24 GBVRAMPer Card1.3 TBStoragePrice From:$3.94/hrDeploy ClusterH200Nvidia1xAmount141 GBVRAMPer Card750 GBStoragePrice From:$3.79/hrDeploy ClusterL40SNvidia2xAmount48 GBVRAMPer Card3.2 TBStoragePrice From:$3.77/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterL40SNvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$3.36/hrDeploy ClusterA6000Nvidia4xAmount48 GBVRAMPer Card1000 GBStoragePrice From:$3.13/hrDeploy ClusterA40Nvidia2xAmount48 GBVRAMPer Card1.5 TBStoragePrice From:$3.04/hrDeploy Cluster6000 ADANvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$2.73/hrDeploy ClusterL40Nvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$2.65/hrDeploy ClusterA100Nvidia2xAmount80 GBVRAMPer Card1.5 TBStoragePrice From:$2.58/hrDeploy ClusterV100Nvidia2xAmount32 GBVRAMPer Card1.8 TBStoragePrice From:$2.52/hrDeploy ClusterV100_32GNvidia1xAmount32 GBVRAMPer Card250 GBStoragePrice From:$2.46/hrDeploy ClusterRTXPRO6000Nvidia1xAmount96 GBVRAMPer Card800 GBStoragePrice From:$2.42/hrDeploy ClusterRTXPro6000Nvidia1xAmount96 GBVRAMPer Card750 GBStoragePrice From:$2.30/hrDeploy ClusterPRO 6000 BLACKWELLNvidia1xAmount96 GBVRAMPer Card725 GBStoragePrice From:$2.09/hrDeploy ClusterA100Nvidia1xAmount40 GBVRAMPer Card1.5 TBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterRTX6000AdaNvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$2.04/hrDeploy ClusterA30Nvidia1xAmount24 GBVRAMPer Card640 GBStoragePrice From:$1.97/hrDeploy ClusterV100Nvidia1xAmount32 GBVRAMPer Card900 GBStoragePrice From:$1.57/hrDeploy ClusterA40Nvidia1xAmount48 GBVRAMPer Card750 GBStoragePrice From:$1.51/hrDeploy Cluster6000 ADANvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$1.36/hrDeploy ClusterL40Nvidia2xAmount48 GBVRAMPer Card1.2 TBStoragePrice From:$1.32/hrDeploy ClusterA100Nvidia1xAmount80 GBVRAMPer Card625 GBStoragePrice From:$1.31/hrDeploy ClusterDGX A100Nvidia1xAmount80 GBVRAMPer Card1000 GBStoragePrice From:$1.31/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterRTX6000AdaNvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$1.02/hrDeploy ClusterA6000Nvidia2xAmount48 GBVRAMPer Card512 GBStoragePrice From:$0.99/hrDeploy ClusterT4Nvidia2xAmount16 GBVRAMPer Card1.8 TBStoragePrice From:$0.94/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.84/hrDeploy Cluster6000 ADANvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$0.68/hrDeploy ClusterL40Nvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.66/hrDeploy ClusterA6000Nvidia1xAmount48 GBVRAMPer Card256 GBStoragePrice From:$0.49/hrDeploy ClusterT4Nvidia1xAmount16 GBVRAMPer Card900 GBStoragePrice From:$0.47/hrDeploy ClusterB200Nvidia1xAmount192 GBVRAMPer Card500 GBStoragePrice From:$4.89/hrDeploy ClusterB300 SXM6 ACNvidia1xAmount275 GBVRAMPer Card500 GBStoragePrice From:$4.50/hrDeploy ClusterH200Nvidia1xAmount140 GBVRAMPer Card500 GBStoragePrice From:$2.00/hrDeploy ClusterH100 80GB HBM3Nvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.99/hrDeploy ClusterH100 PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.59/hrDeploy ClusterA100-SXM4-80GBNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100 80GB PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100-PCIE-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$1.19/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.90/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterGeForce RTX 5090Nvidia1xAmount32 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterA100-SXM4-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$0.79/hrDeploy ClusterGeForce RTX 4090 DNvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 4090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 3090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.25/hrDeploy ClusterRTX A5000Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.19/hrDeploy ClusterRTX A4000Nvidia1xAmount16 GBVRAMPer Card500 GBStoragePrice From:$0.15/hrDeploy ClusterH100Nvidia4xAmount80 GBVRAMPer Card6.4 TBStoragePrice From:$16.28/hrDeploy ClusterA100Nvidia8xAmount80 GBVRAMPer Card4.9 TBStoragePrice From:$10.50/hrDeploy ClusterV100_32GNvidia4xAmount32 GBVRAMPer Card1000 GBStoragePrice From:$9.83/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card3.2 TBStoragePrice From:$8.45/hrDeploy ClusterH100Nvidia2xAmount80 GBVRAMPer Card6 TBStoragePrice From:$7.32/hrDeploy ClusterL40SNvidia8xAmount48 GBVRAMPer Card4.9 TBStoragePrice From:$6.72/hrDeploy ClusterV100Nvidia4xAmount32 GBVRAMPer Card3.5 TBStoragePrice From:$6.30/hrDeploy Cluster6000 ADANvidia8xAmount48 GBVRAMPer Card2.7 TBStoragePrice From:$5.46/hrDeploy ClusterV100_32GNvidia2xAmount32 GBVRAMPer Card500 GBStoragePrice From:$4.91/hrDeploy ClusterRTXPRO6000Nvidia2xAmount96 GBVRAMPer Card800 GBStoragePrice From:$4.61/hrDeploy ClusterRTX6000AdaNvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$4.07/hrDeploy ClusterA6000Nvidia8xAmount48 GBVRAMPer Card2.5 TBStoragePrice From:$3.95/hrDeploy ClusterA30Nvidia2xAmount24 GBVRAMPer Card1.3 TBStoragePrice From:$3.94/hrDeploy ClusterH200Nvidia1xAmount141 GBVRAMPer Card750 GBStoragePrice From:$3.79/hrDeploy ClusterL40SNvidia2xAmount48 GBVRAMPer Card3.2 TBStoragePrice From:$3.77/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterH100Nvidia1xAmount80 GBVRAMPer Card3.1 TBStoragePrice From:$3.68/hrDeploy ClusterL40SNvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$3.36/hrDeploy ClusterA6000Nvidia4xAmount48 GBVRAMPer Card1000 GBStoragePrice From:$3.13/hrDeploy ClusterA40Nvidia2xAmount48 GBVRAMPer Card1.5 TBStoragePrice From:$3.04/hrDeploy Cluster6000 ADANvidia4xAmount48 GBVRAMPer Card1.4 TBStoragePrice From:$2.73/hrDeploy ClusterL40Nvidia4xAmount48 GBVRAMPer Card2.4 TBStoragePrice From:$2.65/hrDeploy ClusterA100Nvidia2xAmount80 GBVRAMPer Card1.5 TBStoragePrice From:$2.58/hrDeploy ClusterV100Nvidia2xAmount32 GBVRAMPer Card1.8 TBStoragePrice From:$2.52/hrDeploy ClusterV100_32GNvidia1xAmount32 GBVRAMPer Card250 GBStoragePrice From:$2.46/hrDeploy ClusterRTXPRO6000Nvidia1xAmount96 GBVRAMPer Card800 GBStoragePrice From:$2.42/hrDeploy ClusterRTXPro6000Nvidia1xAmount96 GBVRAMPer Card750 GBStoragePrice From:$2.30/hrDeploy ClusterPRO 6000 BLACKWELLNvidia1xAmount96 GBVRAMPer Card725 GBStoragePrice From:$2.09/hrDeploy ClusterA100Nvidia1xAmount40 GBVRAMPer Card1.5 TBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterL4Nvidia2xAmount24 GBVRAMPer Card400 GBStoragePrice From:$2.08/hrDeploy ClusterRTX6000AdaNvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$2.04/hrDeploy ClusterA30Nvidia1xAmount24 GBVRAMPer Card640 GBStoragePrice From:$1.97/hrDeploy ClusterV100Nvidia1xAmount32 GBVRAMPer Card900 GBStoragePrice From:$1.57/hrDeploy ClusterA40Nvidia1xAmount48 GBVRAMPer Card750 GBStoragePrice From:$1.51/hrDeploy Cluster6000 ADANvidia2xAmount48 GBVRAMPer Card700 GBStoragePrice From:$1.36/hrDeploy ClusterL40Nvidia2xAmount48 GBVRAMPer Card1.2 TBStoragePrice From:$1.32/hrDeploy ClusterA100Nvidia1xAmount80 GBVRAMPer Card625 GBStoragePrice From:$1.31/hrDeploy ClusterDGX A100Nvidia1xAmount80 GBVRAMPer Card1000 GBStoragePrice From:$1.31/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card400 GBStoragePrice From:$1.07/hrDeploy ClusterRTX6000AdaNvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$1.02/hrDeploy ClusterA6000Nvidia2xAmount48 GBVRAMPer Card512 GBStoragePrice From:$0.99/hrDeploy ClusterT4Nvidia2xAmount16 GBVRAMPer Card1.8 TBStoragePrice From:$0.94/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.84/hrDeploy Cluster6000 ADANvidia1xAmount48 GBVRAMPer Card350 GBStoragePrice From:$0.68/hrDeploy ClusterL40Nvidia1xAmount48 GBVRAMPer Card625 GBStoragePrice From:$0.66/hrDeploy ClusterA6000Nvidia1xAmount48 GBVRAMPer Card256 GBStoragePrice From:$0.49/hrDeploy ClusterT4Nvidia1xAmount16 GBVRAMPer Card900 GBStoragePrice From:$0.47/hrDeploy ClusterB200Nvidia1xAmount192 GBVRAMPer Card500 GBStoragePrice From:$4.89/hrDeploy ClusterB300 SXM6 ACNvidia1xAmount275 GBVRAMPer Card500 GBStoragePrice From:$4.50/hrDeploy ClusterH200Nvidia1xAmount140 GBVRAMPer Card500 GBStoragePrice From:$2.00/hrDeploy ClusterH100 80GB HBM3Nvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.99/hrDeploy ClusterH100 PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.59/hrDeploy ClusterA100-SXM4-80GBNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100 80GB PCIeNvidia1xAmount80 GBVRAMPer Card500 GBStoragePrice From:$1.29/hrDeploy ClusterA100-PCIE-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$1.19/hrDeploy ClusterL4Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.90/hrDeploy ClusterL40SNvidia1xAmount48 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterGeForce RTX 5090Nvidia1xAmount32 GBVRAMPer Card500 GBStoragePrice From:$0.89/hrDeploy ClusterA100-SXM4-40GBNvidia1xAmount40 GBVRAMPer Card500 GBStoragePrice From:$0.79/hrDeploy ClusterGeForce RTX 4090 DNvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 4090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.30/hrDeploy ClusterGeForce RTX 3090Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.25/hrDeploy ClusterRTX A5000Nvidia1xAmount24 GBVRAMPer Card500 GBStoragePrice From:$0.19/hrDeploy ClusterRTX A4000Nvidia1xAmount16 GBVRAMPer Card500 GBStoragePrice From:$0.15/hrDeploy ClusterGPUs everywhere, on demandYour customers are everywhere, and your compute requirements are always changing. Get the compute you need, where you need it, when you need it with globally distributed GPU clusters, and no vendor lock-in.Try io.cloud nowGeForce RTX 4090NvidiaH100 PCIeNvidiaPrices correct as of 30th July 2025H100SXM5NvidiaH200Nvidia$0.49/ hr$1.85/ hrVirtual Machines$1.85/ hr$3.70/ hr$0.50/ hr$1.70/ hrCaaS$1.99/ hr$2.49/ hr$0.50/ hr$1.70/ hrBare Metal$1.99/ hr$2.49/ hrGPUVirtual MachinesCaaSBare MetalGeForce RTX 4090Nvidia$0.49/ hr$0.50/ hr$0.50/ hrH100 PCIeNvidia$1.85/ hr$1.70/ hr$1.70/ hrH100SXM5Nvidia$1.85/ hr$1.99/ hr$1.99/ hrH200Nvidia$3.70/ hr$2.49/ hr$2.49/ hrPrices correct as of 30th July 2025Deploy how you want,when you wantContainersOne-line deployment for ML workloads with pre-configured environmentsDeploy ContainerVirtual machinesAI-ready VMs in less than 5 minutes with pre-configured ML frameworksDeploy VMRay clusterNative support for containerized AI workloads with familiar toolingThe open-weight AI platform built for scaleInstantly run, deploy, and scale AI models with high-performance GPUs and zero setup.Scale with over 50+ AI ModelsXiaomiDeepSeekZ.aiAlibaba CloudMoonshot AIMiniMaxGoogleOpen AIMeta AIMistral AIEverything you need tobuild advanced AI solutionsAgentic workflow editorBuild and connect intelligent agents with logic-driven automation.Launch Workflow EditorModel and agent marketplaceDiscover and deploy leading open-weight AI models.Launch AI MarketplaceTraining-as-a-Service (TaaS)Train and scale models securely on decentralized infrastructure.Launch Training As A ServiceGet off the waitlist and start building today Join thousands of developers instantly and securely deploying GPU clusters at 70% lower cost. No waitlists. No constant price rises. No vendor lock-in. Just the resources you need to build a sustainable business.Get Started","tokens":3544,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261023800,"hash":"1bc7554d8dc206d2efd894cea10ef55513294ad2"}
{"url":"https://specs.optimism.io/protocol/rollup-node-p2p.html","domain":"specs.optimism.io","title":"Rollup Node P2P - OP Stack Specification","text":"Rollup-node P2P interface\n\nTable of Contents\n\nOverview\nP2P configuration\n\nIdentification\nDiscv5\n\nConsensus Layer Structure\n\nLibP2P\n\nTransport\nDialing\nNAT\nPeer management\nTransport security\nProtocol negotiation\nIdentify\nPing\nMultiplexing\nGossipSub\n\nContent-based message identification\nMessage compression and limits\nMessage ID computation\n\nHeartbeat and parameters\nTopic configuration\nTopic validation\n\nGossip Topics\n\nblocksv1\nblocksv2\nblocksv3\nblocksv4\nBlock encoding\nBlock signatures\nBlock validation\n\nBlock processing\nBranch selection\nBlock topic scoring parameters\n\nReq-Resp\n\npayload_by_number\n\nOverview\nThe rollup node has an optional peer-to-peer (P2P) network service to improve the latency between\nthe view of sequencers and the rest of the network by bypassing the L1 in the happy case,\nwithout relying on a single centralized endpoint.\nThis also enables faster historical sync to be bootstrapped by providing block headers to sync towards,\nand only having to compare the L2 chain inputs to the L1 data as compared to processing everything one block at a time.\nThe rollup node will always prioritize L1 and reorganize to match the canonical chain.\nThe L2 data retrieved via the P2P interface is strictly a speculative extension, also known as the \"unsafe\" chain,\nto improve the happy case performance.\nThis also means that P2P behavior is a soft-rule: nodes keep each other in check with scoring and eventual banning\nof malicious peers by identity or IP. Any behavior on the P2P layer does not affect the rollup security, at worst nodes\nrely on higher-latency data from L1 to serve.\nIn summary, the P2P stack looks like:\n\nDiscovery to find peers: Discv5\nConnections, peering, transport security, multiplexing, gossip: LibP2P\nApplication-layer publishing and validation of gossiped messages like L2 blocks.\n\nThis document only specifies the composition and configuration of these network libraries.\nThese components have their own standards, implementations in Go/Rust/Java/Nim/JS/more,\nand are adopted by several other blockchains, most notably the L1 consensus layer (Eth2).\nP2P configuration\nIdentification\nNodes have a separate network- and consensus-identity.\nThe network identity is a secp256k1 key, used for both discovery and active LibP2P connections.\nCommon representations of network identity:\n\nPeerID: a LibP2P specific ID derived from the pubkey (through protobuf encoding, typing and hashing)\nNodeID: a Discv5 specific ID derived from the pubkey (through hashing, used in the DHT)\nMulti-address: an unsigned address, containing: IP, TCP port, PeerID\nENR: a signed record used for discovery, containing: IP, TCP port, UDP port, signature (pubkey can be derived)\nand L2 network identification. Generally encoded in base64.\n\nDiscv5\nConsensus Layer Structure\nThe Ethereum Node Record (ENR) for an Optimism rollup node must contain the following values, identified by unique keys:\n\nAn IPv4 address (ip field) and/or IPv6 address (ip6 field).\nA TCP port (tcp field) representing the local libp2p listening port.\nA UDP port (udp field) representing the local discv5 listening port.\nAn OpStack (opstack field) L2 network identifier\n\nThe opstack value is encoded as a single RLP bytes value, the concatenation of:\n\nchain ID (unsigned varint)\nfork ID (unsigned varint)\n\nNote that DiscV5 is a shared DHT (Distributed Hash Table): the L1 consensus and execution nodes,\nas well as testnet nodes, and even external IOT nodes, all communicate records in this large common DHT.\nThis makes it more difficult to censor the discovery of node records.\nThe discovery process in Optimism is a pipeline of node records:\n\nFill the table with FINDNODES if necessary (Performed by Discv5 library)\nPull additional records with searches to random Node IDs if necessary\n(e.g. iterate RandomNodes() in Go implementation)\nPull records from the DiscV5 module when looking for peers\nCheck if the record contains the opstack entry, verify it matches the chain ID and current or future fork number\nIf not already connected, and not recently disconnected or put on deny-list, attempt to dial.\n\nLibP2P\nTransport\nTCP transport. Additional transports are supported by LibP2P, but not required.\nDialing\nNodes should be publicly dialable, not rely on relay extensions, and able to dial both IPv4 and IPv6.\nNAT\nThe listening endpoint must be publicly facing, but may be configured behind a NAT.\nLibP2P will use PMP / UPNP based techniques to track the external IP of the node.\nIt is recommended to disable the above if the external IP is static and configured manually.\nPeer management\nThe default is to maintain a peer count with a tide-system based on active peer count:\n\nAt \"low tide\" the node starts to actively search for additional peer connections.\nAt \"high tide\" the node starts to prune active connections,\nexcept those that are marked as trusted or have a grace period.\n\nPeers will have a grace period for a configurable amount of time after joining.\nIn an emergency, when memory runs low, the node should start pruning more aggressively.\nPeer records can be persisted to disk to quickly reconnect with known peers after restarting the rollup node.\nThe discovery process feeds the peerstore with peer records to connect to, tagged with a time-to-live (TTL).\nThe current P2P processes do not require selective topic-specific peer connections,\nother than filtering for the basic network participation requirement.\nPeers may be banned if their performance score is too low, or if an objectively malicious action was detected.\nBanned peers will be persisted to the same data-store as the peerstore records.\nTODO: the connection gater does currently not gate by IP address on the dial Accept-callback.\nTransport security\nLibp2p-noise, XX handshake, with the secp256k1 P2P identity, as popularized in Eth2.\nThe TLS option is available as well, but noise should be prioritized in negotiation.\nProtocol negotiation\nMultistream-select 1.0 (/multistream/1.0.0) is an interactive protocol\nused to negotiate sub-protocols supported in LibP2P peers. Multistream-select 2.0 may be used in the future.\nIdentify\nLibP2P offers a minimal identification module to share client version and programming language.\nThis is optional and can be disabled for enhanced privacy.\nIt also includes the same protocol negotiation information, which can speed up initial connections.\nPing\nLibP2P includes a simple ping protocol to track latency between connections.\nThis should be enabled to help provide insight into the network health.\nMultiplexing\nFor async communication over different channels over the same connection, multiplexing is used.\nmplex (/mplex/6.7.0) is required, and yamux (/yamux/1.0.0) is recommended but optional\nGossipSub\nGossipSub 1.1 (/meshsub/1.1.0, i.e. with peer-scoring extension) is a pubsub protocol for mesh-networks,\ndeployed on L1 consensus (Eth2) and other protocols such as Filecoin, offering lots of customization options.\nContent-based message identification\nMessages are deduplicated, and filtered through application-layer signature verification.\nThus origin-stamping is disabled and published messages must only contain application data,\nenforced through a StrictNoSign Signature Policy\nThis provides greater privacy, and allows sequencers (consensus identity) to maintain\nmultiple network identities for redundancy.\nMessage compression and limits\nThe application contents are compressed with snappy single-block-compression\n(as opposed to frame-compression), and constrained to 10 MiB.\nMessage ID computation\nSame as L1, with recognition of compression:\n\nIf message.data has a valid snappy decompression, set message-id to the first 20 bytes of the SHA256 hash of\nthe concatenation of MESSAGE_DOMAIN_VALID_SNAPPY with the snappy decompressed message data,\ni.e. SHA256(MESSAGE_DOMAIN_VALID_SNAPPY + snappy_decompress(message.data))[:20].\nOtherwise, set message-id to the first 20 bytes of the SHA256 hash of\nthe concatenation of MESSAGE_DOMAIN_INVALID_SNAPPY with the raw message data,\ni.e. SHA256(MESSAGE_DOMAIN_INVALID_SNAPPY + message.data)[:20].\n\nHeartbeat and parameters\nGossipSub parameters:\n\nD (topic stable mesh target count): 8\nD_low (topic stable mesh low watermark): 6\nD_high (topic stable mesh high watermark): 12\nD_lazy (gossip target): 6\nheartbeat_interval (interval of heartbeat, in seconds): 0.5\nfanout_ttl (ttl for fanout maps for topics we are not subscribed to but have published to, in seconds): 24\nmcache_len (number of windows to retain full messages in cache for IWANT responses): 12\nmcache_gossip (number of windows to gossip about): 3\nseen_ttl (number of heartbeat intervals to retain message IDs): 130 (= 65 seconds)\n\nNotable differences from L1 consensus (Eth2):\n\nseen_ttl does not need to cover a full L1 epoch (6.4 minutes), but rather just a small window covering latest blocks\nfanout_ttl: adjusted to lower than seen_ttl\nmcache_len: a larger number of heartbeats can be retained since the gossip is much less noisy.\nheartbeat_interval: faster interval to reduce latency, bandwidth should still be reasonable since\nthere are far fewer messages to gossip about each interval than on L1 which uses an interval of 0.7 seconds.\n\nTopic configuration\nTopics have string identifiers and are communicated with messages and subscriptions.\n/optimism/chain_id/hardfork_version/Name\n\nchain_id: replace with decimal representation of chain ID\nhardfork_version: replace with decimal representation of hardfork, starting at 0\nName: topic application-name\n\nNote that the topic encoding depends on the topic, unlike L1,\nsince there are less topics, and all are snappy-compressed.\nTopic validation\nTo ensure only valid messages are relayed, and malicious peers get scored based on application behavior,\nan extended validator checks the message before it is relayed or processed.\nThe extended validator emits one of the following validation signals:\n\nACCEPT valid, relayed to other peers and passed to local topic subscriber\nIGNORE scored like inactivity, message is dropped and not processed\nREJECT score penalties, message is dropped\n\nGossip Topics\nListed below are the topics for distributing blocks to other nodes faster than proxying through L1 would. These are:\nblocksv1\nPre-Canyon/Shanghai blocks are broadcast on /optimism/<chainId>/0/blocks.\nblocksv2\nCanyon/Delta blocks are broadcast on /optimism/<chainId>/1/blocks.\nblocksv3\nEcotone blocks are broadcast on /optimism/<chainId>/2/blocks.\nblocksv4\nIsthmus blocks are broadcast on /optimism/<chainId>/3/blocks.\nBlock encoding\nA block is structured as the concatenation of:\n\nV1 and V2 topics\n\nsignature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8)\npayload: A SSZ-encoded ExecutionPayload, always the remaining bytes.\n\nV3 topic\n\nsignature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8)\nparentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes\npayload: A SSZ-encoded ExecutionPayload, always the remaining bytes.\n\nV4 topic\n\nsignature: A secp256k1 signature, always 65 bytes, r (uint256), s (uint256), y_parity (uint8)\nparentBeaconBlockRoot: L1 origin parent beacon block root, always 32 bytes\npayload: A SSZ-encoded ExecutionPayload, always the remaining bytes.\n\nNote - the ExecutionPayload is modified for the first time in Isthmus. See\n\"Update to ExecutionPayload\" in the Isthmus spec.\n\nAll topics use Snappy block-compression (i.e. no snappy frames):\nthe above needs to be compressed after encoding, and decompressed before decoding.\nBlock signatures\nThe signature is a secp256k1 signature, and signs over a message:\nkeccak256(domain ++ chain_id ++ payload_hash), where:\n\ndomain is 32 bytes, reserved for message types and versioning info. All zero for this signature.\nchain_id is a big-endian encoded uint256.\npayload_hash is keccak256(payload), where payload is:\n\nthe payload in V1 and V2,\nparentBeaconBlockRoot ++ payload in V3 + V4 (NOTE: In V4, payload is extended to include the\nwithdrawalsRoot).\n\nThe secp256k1 signature must have y_parity = 1 or 0, the chain_id is already signed over.\nBlock validation\nAn extended-validator checks the incoming messages as follows, in order of operation:\n\n[REJECT] if the compression is not valid\n[REJECT] if the block encoding is not valid\n[REJECT] if the payload.timestamp is older than 60 seconds in the past\n(graceful boundary for worst-case propagation and clock skew)\n[REJECT] if the payload.timestamp is more than 5 seconds into the future\n[REJECT] if the block_hash in the payload is not valid\n[REJECT] if the block is on the V1 topic and has withdrawals\n[REJECT] if the block is on the V1 topic and has a withdrawals list\n[REJECT] if the block is on a topic >= V2 and does not have an empty withdrawals list\n[REJECT] if the block is on a topic <= V2 and has a blob gas-used value set\n[REJECT] if the block is on a topic <= V2 and has an excess blob gas value set\n[REJECT] if the block is on a topic <= V2 and the parent beacon block root is not nil\n[REJECT] if the block is on a topic >= V3 and has a blob gas-used value that is not zero\n[REJECT] if the block is on a topic >= V3 and has an excess blob gas value that is not zero\n[REJECT] if the block is on a topic >= V3 and the parent beacon block root is nil\n[REJECT] if the block is on a topic <= V3 and the l2 withdrawals root is not nil\n[REJECT] if the block is on a topic >= V4 and the l2 withdrawals root is nil\n[REJECT] if more than 5 different blocks have been seen with the same block height\n[IGNORE] if the block has already been seen\n[REJECT] if the signature by the sequencer is not valid\nMark the block as seen for the given block height\n\nThe block is signed by the corresponding sequencer, to filter malicious messages.\nThe sequencer model is singular but may change to multiple sequencers in the future.\nA default sequencer pubkey is distributed with rollup nodes and should be configurable.\nNote that blocks that a block may still be propagated even if the L1 already confirmed a different block.\nThe local L1 view of the node may be wrong, and the time and signature validation will prevent spam.\nHence, calling into the execution engine with a block lookup every propagation step is not worth the added delay.\nBlock processing\nA node may apply the block to their local engine ahead of L1 availability, if it ensures that:\n\nThe application of the block is reversible, in case of a conflict with delayed L1 information\nThe subsequent forkchoice-update ensures this block is recognized as \"unsafe\"\n(see fork choice updated)\n\nBranch selection\nNodes expect that the sequencer will not equivocate, and therefore the fork choice rule for unsafe blocks\nis a \"first block wins\" model, where the unsafe chain will not change once it has been extended, unless\ninvalidated by safe data published to the L1.\nNodes who see a different initial unsafe block will not reach consensus until the L1 is published,\nwhich resolves the disagreement. Because the L1 published data depends on the batcher's view of the data,\nthe safe head will be based on whatever the batcher's source's unsafe head is.\nBlock topic scoring parameters\nTODO: GossipSub per-topic scoring to fine-tune incentives for ideal propagation delay and bandwidth usage.\nReq-Resp\nThe op-node implements a similar request-response encoding for its sync protocols as the L1 ethereum Beacon-Chain.\nSee L1 P2P-interface req-resp specification and Altair P2P update.\nHowever, the protocol is simplified, to avoid several issues seen in L1:\n\nError strings in responses, if there is any alternative response,\nshould not need to be compressed or have an artificial global length limit.\nPayload lengths should be fixed-length: byte-by-byte uvarint reading from the underlying stream is undesired.\n<context-bytes> are relaxed to encode a uint32, rather than a beacon-chain ForkDigest.\nPayload-encoding may change per hardfork, so is not part of the protocol-ID.\nUsage of response-chunks is specific to the req-resp method: most basic req-resp does not need chunked responses.\nCompression is encouraged to be part of the payload-encoding, specific to the req-resp method, where necessary:\npings and such do not need streaming frame compression etc.\n\nAnd the protocol ID format follows the same scheme as L1,\nexcept the trailing encoding schema part, which is now message-specific:\n/ProtocolPrefix/MessageName/SchemaVersion/\n\nThe req-resp protocols served by the op-node all have /ProtocolPrefix set to /opstack/req.\nIndividual methods may include the chain ID as part of the /MessageName segment,\nso it's immediately clear which chain the method applies to, if the communication is chain-specific.\nOther methods may include chain-information in the request and/or response data,\nsuch as the ForkDigest <context-bytes> in L1 beacon chain req-resp protocols.\nEach segment starts with a /, and may contain multiple /, and the final protocol ID is suffixed with a /.\npayload_by_number\nThis is an optional chain syncing method, to request/serve execution payloads by number.\nThis serves as a method to fill gaps upon missed gossip, and sync short to medium ranges of unsafe L2 blocks.\nProtocol ID: /opstack/req/payload_by_number/<chain-id>/0/\n\n/MessageName is /block_by_number/<chain-id> where <chain-id> is set to the op-node L2 chain ID.\n/SchemaVersion is /0\n\nRequest format: <num>: a little-endian uint64 - the block number to request.\nResponse format: <response> = <res><version><payload>\n\n<res> is a byte code describing the result.\n\n0 on success, <version><payload> should follow.\n1 if valid request, but unavailable payload.\n2 if invalid request\n3+ if other error\nThe >= 128 range is reserved for future use.\n\n<version> is a little-endian uint32, identifying the response type (fork-specific)\n<payload> is an encoded block, read till stream EOF.\n\nThe input of <response> should be limited, as well as any generated decompressed output,\nto avoid unexpected resource usage or zip-bomb type attacks.\nA 10 MB limit is recommended, to ensure all blocks may be synced.\nImplementations may opt for a different limit, since this sync method is optional.\n<version> list:\n\n0: SSZ-encoded ExecutionPayload, with Snappy framing compression,\nmatching the ExecutionPayload SSZ definition of the L1 Merge, L2 Bedrock and L2 Regolith, L2 Canyon versions.\n1: SSZ-encoded ExecutionPayloadEnvelope with Snappy framing compression,\nmatching the ExecutionPayloadEnvelope SSZ definition of the L2 Ecotone version.\n2: SSZ-encoded ExecutionPayload with Snappy framing compression,\nmatching the ExecutionPayload SSZ definition of the L2 Isthmus version.\n\nThe request is by block-number, enabling parallel fetching of a chain across many peers.\nA res = 0 response should be verified to:\n\nHave a block-number matching the requested block number.\nHave a consistent blockhash w.r.t. the other block contents.\nBuild towards a known canonical block.\n\nThis can be verified by checking if the parent-hash of a previous trusted canonical block matches\nthat of the verified hash of the retrieved block.\nFor unsafe blocks this may be relaxed to verification against the parent-hash of any previously trusted block:\n\nThe gossip validation process limits the amount of blocks that may be trusted to sync towards.\nThe unsafe blocks should be queued for processing, the latest received L2 unsafe blocks should always\noverride any previous chain, until the final L2 chain can be reproduced from L1 data.\n\nA res > 0 response code should not be accepted. The result code is helpful for debugging,\nbut the client should regard any error like any other unanswered request, as the responding peer cannot be trusted.","tokens":4897,"squid":"ink-governance","role":"Council Listener","at":1791261024155,"hash":"4d60e2328e3207ae276c0bd9e6f5a1e5eb47b075"}
{"url":"https://forum.openzeppelin.com/t/can-t-remove-liquidity-on-pancakeswap-v2/29722/3","domain":"forum.openzeppelin.com","title":"Can’t remove liquidity on pancakeswap v2 - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n etherscan-verify,bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2022\n\n 3 / 3\n\n Jun 2022\n\n Jun 2022\n\n post by Crispypotato on Jun 17, 2022\n\n Crispypotato\n\n So I've come accross so many topics over the internet and hit a dead end.\nthis is basically a Token-BNB liquidity and it happened I can't pull it out. Pancakeswap says \"ERROR, This transaction would fail\", I have almost $40,000 trapped in that liquidity so I'm giving away a bounty - It's better to give something or it might end up trapped forever.\nI own the contract and its interacted with PC router and Factory\nTried Solutions :\nX - Receive WBNB instead of BNB\nX - Tried it on multiple browsers as well as on metamask app on android\nX - Tried Approving the owner to the contracts\nX - Tried increaseallowance\nI found someone on an old github post telling setSwapAndLiquifyEnabled set to false but I happen can't find it.\nConsole error :\nremoveLiquidityETHWithPermit\nremoveLiquidityETHWithPermitSupportingFeeOnTransferTokens\nPC router\nI am giving anyone who can help remove the liquidity a $1,000 BNB REWARD!\nHERE IS A MODEL OF THE TOKEN CONTRACT: https://bscscan.com/token/0x328d0aa10e6087af2c1a0bd16d3455bf3acd92aa#writeContract\nThe token I am trying to remove liquidity from is just like this, please let me know if theres a way to remove! Thanks\n\n post by Team_X on Jun 23, 2022\n\n Team_X\n\n Hey! I had problems like this on the testnet. I never found a real solution to it. The only thing that worked was if I tried pulling all liquidity it would stop me.\nIf there is a max transaction limit in the contract of 2% then you can only transfer 2%\nIf there is a burn or tax fee then you may need to increase slippage. This are the only 2 things that you can try.\n\n post by minh_trng on Jun 23, 2022\n\n minh_trng\n\n the token you linked as a \"model\" has no verified source code. Does the token you put your money into has verified source code? also, did the project rug pull or is it still active?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 20\n\n 12.3k\n\n Aug 2025\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024\n\n HELP Can’t remove liquidity on pcs v2\n\n Smart Contracts\n\n 4\n\n 887\n\n Nov 2022\n\n Cannot remove liquidity from a BSC token - 200$ bounty\n\n Developer Wanted\n\n etherscan-verify\n\n 2\n\n 807\n\n May 2023\n\n Solved! Unable To Withdraw Liquidity From My Token\n\n Smart Contracts\n\n bep20\n\n 1\n\n 4.7k\n\n Dec 2021","tokens":650,"squid":"ink-security_audits","role":"Sentinel","at":1791261025557,"hash":"c4bdf02693ab1918d9113ad8f515970166d11f5a"}
{"url":"https://specs.optimism.io/protocol/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"L2 Chain Derivation Specification\n\nTable of Contents\n\nOverview\n\nEager Block Derivation\nProtocol Parameters\n\nBatch Submission\n\nSequencing & Batch Submission Overview\nBatch Submission Wire Format\n\nBatcher Transaction Format\nFrame Format\nChannel Format\nBatch Format\n\nArchitecture\n\nL2 Chain Derivation Pipeline\n\nL1 Traversal\nL1 Retrieval\nFrame Queue\nChannel Bank\n\nPruning\nTimeouts\nReading\nLoading frames\n\nChannel Reader (Batch Decoding)\nBatch Queue\nPayload Attributes Derivation\nEngine Queue\n\nEngine API usage\n\nBedrock, Canyon, Delta: API Usage\nEcotone: API Usage\n\nForkchoice synchronization\nL1-consolidation: payload attributes matching\nL1-sync: payload attributes processing\nProcessing unsafe payload attributes\n\nResetting the Pipeline\n\nFinding the sync starting point\nResetting derivation stages\nAbout reorgs Post-Merge\n\nDeriving Payload Attributes\n\nDeriving the Transaction List\n\nNetwork upgrade automation transactions\n\nBuilding Individual Payload Attributes\nOn Future-Proof Transaction Log Derivation\n\nOverview\n\nNote the following assumes a single sequencer and batcher. In the future, the design will be adapted to\naccommodate multiple such entities.\n\nL2 chain derivation — deriving L2 blocks from L1 data — is one of the main responsibilities\nof the rollup node, both in validator mode, and in sequencer mode (where derivation acts as a sanity\ncheck on sequencing, and enables detecting L1 chain re-organizations).\nThe L2 chain is derived from the L1 chain. In particular, each L1 block following L2 chain\ninception is mapped to a sequencing epoch comprising\nat least one L2 block. Each L2 block belongs to exactly one epoch, and we call the corresponding L1\nblock its L1 origin. The epoch's number equals that of its L1 origin block.\nTo derive the L2 blocks of epoch number E, we need the following inputs:\n\nL1 blocks in the range [E, E + SWS), called the sequencing window of the epoch, and SWS\nthe sequencing window size. (Note that sequencing windows overlap.)\nBatcher transactions from blocks in the sequencing window.\n\nThese transactions allow us to reconstruct the epoch's sequencer batches, each of\nwhich will produce one L2 block. Note that:\n\nThe L1 origin will never contain any data needed to construct sequencer batches since\neach batch must contain the L1 origin hash.\nAn epoch may have no sequencer batches.\n\nDeposits made in the L1 origin (in the form of events emitted by the deposit\ncontract).\nL1 block attributes from the L1 origin (to derive the L1 attributes deposited transaction).\nThe state of the L2 chain after the last L2 block of the previous epoch, or the L2 genesis state\nif E is the first epoch.\n\nTo derive the whole L2 chain from scratch, we start with the L2 genesis state and\nthe L2 genesis block as the first L2 block. We then derive L2 blocks from each epoch in order,\nstarting at the first L1 block following L2 chain inception. Refer to the\nArchitecture section for more information on how we implement this in practice.\nThe L2 chain may contain pre-Bedrock history, but the L2 genesis here refers to the Bedrock L2\ngenesis block.\nEach L2 block with origin l1_origin is subject to the following constraints (whose values are\ndenominated in seconds):\n\nblock.timestamp = prev_l2_timestamp + l2_block_time\n\nprev_l2_timestamp is the timestamp of the L2 block immediately preceding this one. If there\nis no preceding block, then this is the genesis block, and its timestamp is explicitly\nspecified.\nl2_block_time is a configurable parameter of the time between L2 blocks (2s on Optimism).\n\nl1_origin.timestamp <= block.timestamp <= max_l2_timestamp, where\n\nmax_l2_timestamp = max(l1_origin.timestamp + max_sequencer_drift, prev_l2_timestamp + l2_block_time)\n\nmax_sequencer_drift is a configurable parameter that bounds how far the sequencer can get ahead of\nthe L1.\n\nFinally, each epoch must have at least one L2 block.\nThe first constraint means there must be an L2 block every l2_block_time seconds following L2\nchain inception.\nThe second constraint ensures that an L2 block timestamp never precedes its L1 origin timestamp,\nand is never more than max_sequencer_drift ahead of it, except only in the unusual case where it\nmight prohibit an L2 block from being produced every l2_block_time seconds. (Such cases might arise\nfor example under a proof-of-work L1 that sees a period of rapid L1 block production.) In either\ncase, the sequencer enforces len(batch.transactions) == 0 while max_sequencer_drift is\nexceeded. See Batch Queue for more details.\nThe final requirement that each epoch must have at least one L2 block ensures that all relevant\ninformation from the L1 (e.g. deposits) is represented in the L2, even if it has no sequencer\nbatches.\nPost-merge, Ethereum has a fixed 12s block time, though some slots can be\nskipped. Under a 2s L2 block time, we thus expect each epoch to typically contain 12/2 = 6 L2\nblocks. The sequencer will however produce bigger epochs in order to maintain liveness in case of\neither a skipped slot on the L1 or a temporary loss of connection to it. For the lost connection\ncase, smaller epochs might be produced after the connection was restored to keep L2 timestamps from\ndrifting further and further ahead.\nEager Block Derivation\nDeriving an L2 block requires that we have constructed its sequencer batch and derived all L2\nblocks and state updates prior to it. This means we can typically derive the L2 blocks of an epoch\neagerly without waiting on the full sequencing window. The full sequencing window is required\nbefore derivation only in the very worst case where some portion of the sequencer batch for the\nfirst block of the epoch appears in the very last L1 block of the window. Note that this only\napplies to block derivation. Sequencer batches can still be derived and tentatively queued\nwithout deriving blocks from them.\nProtocol Parameters\nThe following table gives an overview of some protocol parameters, and how they are affected by\nprotocol upgrades.\nParameterBedrock (default) valueLatest (default) valueChangesNotes\nmax_sequencer_drift6001800FjordChanged from a chain parameter to a constant with Fjord.\nMAX_RLP_BYTES_PER_CHANNEL10,000,000100,000,000FjordConstant increased with Fjord.\nMAX_CHANNEL_BANK_SIZE100,000,0001,000,000,000FjordConstant increased with Fjord.\nMAX_SPAN_BATCH_ELEMENT_COUNT10,000,00010,000,000Effectively introduced in FjordNumber of elements\n\nBatch Submission\nSequencing & Batch Submission Overview\nThe sequencer accepts L2 transactions from users. It is responsible for building blocks out of these. For\neach such block, it also creates a corresponding sequencer batch. It is also responsible for\nsubmitting each batch to a data availability provider (e.g. Ethereum calldata), which it does via\nits batcher component.\nThe difference between an L2 block and a batch is subtle but important: the block includes an L2 state root, whereas the\nbatch only commits to transactions at a given L2 timestamp (equivalently: L2 block number). A block also includes a\nreference to the previous block (*).\n(*) This matters in some edge case where a L1 reorg would occur and a batch would be reposted to the L1 chain but not\nthe preceding batch, whereas the predecessor of an L2 block cannot possibly change.\nThis means that even if the sequencer applies a state transition incorrectly, the transactions in the batch will still\nbe considered part of the canonical L2 chain. Batches are still subject to validity checks (i.e. they have to be encoded\ncorrectly), and so are individual transactions within the batch (e.g. signatures have to be valid). Invalid batches and\ninvalid individual transactions within an otherwise valid batch are discarded by correct nodes.\nIf the sequencer applies a state transition incorrectly and posts an output root, then this output root\nwill be incorrect. The incorrect output root will be challenged by a fault proof, then replaced\nby a correct output root for the existing sequencer batches.\nRefer to the Batch Submission specification for more information.\nBatch Submission Wire Format\nBatch submission is closely tied to L2 chain derivation because the derivation process must decode the batches that have\nbeen encoded for the purpose of batch submission.\nThe batcher submits batcher transactions to a data availability\nprovider. These transactions contain one or multiple channel frames, which are\nchunks of data belonging to a channel.\nA channel is a sequence of sequencer batches (for any L2 blocks) compressed\ntogether. The reason to group multiple batches together is simply to obtain a better compression rate, hence reducing\ndata availability costs.\nChannels might be too large to fit in a single batcher transaction, hence we need to split it\ninto chunks known as channel frames. A single batcher transaction can also carry multiple frames\n(belonging to the same or to different channels).\nThis design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher\ntransactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to\npack the final (small) frame of one channel with one or more frames from the next channel.\nAlso note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up\ncontaining when we start a channel, or even as we send the first frames in the channel.\nAnd by splitting channels across multiple data transactions, the L2 can have larger block data than the\ndata-availability layer may support.\nAll of this is illustrated in the following diagram. Explanations below.\n\nThe first line represents L1 blocks with their numbers. The boxes under the L1 blocks represent batcher\ntransactions included within the block. The squiggles under the L1 blocks represent\ndeposits (more specifically, events emitted by the deposit contract).\nEach colored chunk within the boxes represents a channel frame. So A and B are\nchannels whereas A0, A1, B0, B1, B2 are frames. Notice that:\n\nmultiple channels are interleaved\nframes do not need to be transmitted in order\na single batcher transaction can carry frames from multiple channels\n\nIn the next line, the rounded boxes represent individual sequencer batches that were extracted from\nthe channels. The four blue/purple/pink were derived from channel A while the other were derived from channel B.\nThese batches are here represented in the order they were decoded from batches (in this case B is decoded first).\n\nNote The caption here says \"Channel B was seen first and will be decoded into batches first\", but this is not a\nrequirement. For instance, it would be equally acceptable for an implementation to peek into the channels and decode\nthe one that contains the oldest batches first.\n\nThe rest of the diagram is conceptually distinct from the first part and illustrates L2 chain derivation after the\nchannels have been reordered.\nThe first line shows batcher transactions. Note that in this case, there exists an ordering of the batches that makes\nall frames within the channels appear contiguously. This is not true in general. For instance, in the second\ntransaction, the position of A1 and B0 could have been inverted for exactly the same result — no changes needed in\nthe rest of the diagram.\nThe second line shows the reconstructed channels in proper order. The third line shows the batches extracted from the\nchannel. Because the channels are ordered and the batches within a channel are sequential, this means the batches are\nordered too. The fourth line shows the L2 block derived from each batch. Note that we have a 1-1 batch to\nblock mapping here but, as we'll see later, empty blocks that do not map to batches can be inserted in cases where there\nare \"gaps\" in the batches posted on L1.\nThe fifth line shows the L1 attributes deposited transaction which, within each L2 block, records\ninformation about the L1 block that matches the L2 block's epoch. The first number denotes the epoch/L1x number, while\nthe second number (the \"sequence number\") denotes the position within the epoch.\nFinally, the sixth line shows user-deposited transactions derived from the deposit\ncontract event mentioned earlier.\nNote the 101-0 L1 attributes transaction on the bottom right of the diagram. Its presence there is only possible if\nframe B2 indicates that it is the last frame within the channel and (2) no empty blocks must be inserted.\nThe diagram does not specify the sequencing window size in use, but from this we can infer that it must be at least 4\nblocks, because the last frame of channel A appears in block 102, but belong to epoch 99.\nAs for the comment on \"security types\", it explains the classification of blocks as used on L1 and L2.\n\nUnsafe L2 blocks:\nSafe L2 blocks:\nFinalized L2 blocks: refer to block that have been derived from finalized L1 data.\n\nThese security levels map to the headBlockHash, safeBlockHash and finalizedBlockHash values transmitted when\ninteracting with the execution-engine API.\nBatcher Transaction Format\nBatcher transactions are encoded as version_byte ++ rollup_payload (where ++ denotes concatenation).\nversion_byterollup_payload\n0frame ... (one or more frames, concatenated)\n1da_commitment (experimental, see alt-da)\n\nUnknown versions make the batcher transaction invalid (it must be ignored by the rollup node).\nAll frames in a batcher transaction must be parseable. If any one frame fails to parse, the all frames in the\ntransaction are rejected.\nBatch transactions are authenticated by verifying that the to address of the transaction matches the batch inbox\naddress, and the from address matches the batch-sender address in the system configuration at the\ntime of the L1 block that the transaction data is read from.\nFrame Format\nA channel frame is encoded as:\nframe = channel_id ++ frame_number ++ frame_data_length ++ frame_data ++ is_last\n\nchannel_id = bytes16\nframe_number = uint16\nframe_data_length = uint32\nframe_data = bytes\nis_last = bool\n\nWhere uint32 and uint16 are all big-endian unsigned integers. Type names should be interpreted to and\nencoded according to the Solidity ABI.\nAll data in a frame is fixed-size, except the frame_data. The fixed overhead is 16 + 2 + 4 + 1 = 23 bytes.\nFixed-size frame metadata avoids a circular dependency with the target total data length,\nto simplify packing of frames with varying content length.\nwhere:\n\nchannel_id is an opaque identifier for the channel. It should not be reused and is suggested to be random; however,\noutside of timeout rules, it is not checked for validity\nframe_number identifies the index of the frame within the channel\nframe_data_length is the length of frame_data in bytes. It is capped to 1,000,000 bytes.\nframe_data is a sequence of bytes belonging to the channel, logically after the bytes from the previous frames\nis_last is a single byte with a value of 1 if the frame is the last in the channel, 0 if there are frames in the\nchannel. Any other value makes the frame invalid (it must be ignored by the rollup node).\n\nChannel Format\nA channel is encoded by applying a streaming compression algorithm to a list of batches:\nencoded_batches = []\nfor batch in batches:\n encoded_batches ++ batch.encode()\nrlp_batches = rlp_encode(encoded_batches)\n\nwhere:\n\nbatches is the input, a sequence of batches each with a byte-encoder\nfunction .encode() as per the next section (\"Batch Encoding\")\nencoded_batches is a byte array: the concatenation of the encoded batches\nrlp_batches is the rlp encoding of the concatenated encoded batches\n\nchannel_encoding = zlib_compress(rlp_batches)\n\nwhere zlib_compress is the ZLIB algorithm (as specified in RFC-1950) with no dictionary.\nThe Fjord upgrade introduces an additional versioned channel encoding\nformat to support alternate compression\nalgorithms.\nWhen decompressing a channel, we limit the amount of decompressed data to MAX_RLP_BYTES_PER_CHANNEL (defined in the\nProtocol Parameters table), in order to avoid \"zip-bomb\" types of attack (where a small\ncompressed input decompresses to a humongous amount of data).\nIf the decompressed data exceeds the limit, things proceeds as though the channel contained\nonly the first MAX_RLP_BYTES_PER_CHANNEL decompressed bytes. The limit is set on RLP decoding, so all batches that\ncan be decoded in MAX_RLP_BYTES_PER_CHANNEL will be accepted even if the size of the channel is greater than\nMAX_RLP_BYTES_PER_CHANNEL. The exact requirement is that length(input) <= MAX_RLP_BYTES_PER_CHANNEL.\nWhile the above pseudocode implies that all batches are known in advance, it is possible to perform streaming\ncompression and decompression of RLP-encoded batches. This means it is possible to start including channel frames in a\nbatcher transaction before we know how many batches (and how many frames) the channel will\ncontain.\nBatch Format\nRecall that a batch contains a list of transactions to be included in a specific L2 block.\nA batch is encoded as batch_version ++ content, where content depends on the batch_version.\nPrior to the Delta upgrade, batches all have batch_version 0 and are encoded as described below.\nbatch_versioncontent\n0rlp_encode([parent_hash, epoch_number, epoch_hash, timestamp, transaction_list])\n\nwhere:\n\nbatch_version is a single byte, prefixed before the RLP contents, alike to transaction typing.\nrlp_encode is a function that encodes a batch according to the RLP format, and [x, y, z] denotes a list\ncontaining items x, y and z\nparent_hash is the block hash of the previous L2 block\nepoch_number and epoch_hash are the number and hash of the L1 block corresponding to the sequencing\nepoch of the L2 block\ntimestamp is the timestamp of the L2 block\ntransaction_list is an RLP-encoded list of EIP-2718 encoded transactions. Each element is one transaction's\nEIP-2718 encoding verbatim, type byte included; this format does not interpret it. A new transaction type\ntherefore needs no change here. Whether a batch may carry one is a separate question, governed by the\nbatch.transactions rules in Batch Queue.\n\nThe Delta upgrade introduced an additional batch type, span batches.\nUnknown versions make the batch invalid (it must be ignored by the rollup node), as do malformed contents.\n\nNote if the batch version and contents can be RLP decoded correctly but extra content exists beyond the batch,\nthe additional data may be ignored during parsing. Data between RLP encoded batches may not be ignored\n(as they are seen as malformed batches), but if a batch can be fully described by the RLP decoding,\nextra content does not invalidate the decoded batch.\n\nThe epoch_number and the timestamp must also respect the constraints listed in the Batch Queue\nsection, otherwise the batch is considered invalid and will be ignored.\n\nArchitecture\nThe above primarily describes the general encodings used in L2 chain derivation,\nprimarily how batches are encoded within batcher transactions.\nThis section describes how the L2 chain is produced from the L1 batches using a pipeline architecture.\nA verifier may implement this differently, but must be semantically equivalent to not diverge from the L2 chain.\nL2 Chain Derivation Pipeline\nOur architecture decomposes the derivation process into a pipeline made up of the following stages:\n\nL1 Traversal\nL1 Retrieval\nFrame Queue\nChannel Bank\nChannel Reader (Batch Decoding)\nBatch Queue\nPayload Attributes Derivation\nEngine Queue\n\nThe data flows from the start (outer) of the pipeline towards the end (inner).\nFrom the innermost stage the data is pulled from the outermost stage.\nHowever, data is processed in reverse order. Meaning that if there is any data to be processed in the last stage, it\nwill be processed first. Processing proceeds in \"steps\" that can be taken at each stage. We try to take as many steps as\npossible in the last (most inner) stage before taking any steps in its outer stage, etc.\nThis ensures that we use the data we already have before pulling more data and minimizes the latency of data traversing\nthe derivation pipeline.\nEach stage can maintain its own inner state as necessary. In particular, each stage maintains a L1 block reference\n(number + hash) to the latest L1 block such that all data originating from previous blocks has been fully processed, and\nthe data from that block is being or has been processed. This allows the innermost stage to account for finalization of\nthe L1 data-availability used to produce the L2 chain, to reflect in the L2 chain forkchoice when the L2 chain inputs\nbecome irreversible.\nLet's briefly describe each stage of the pipeline.\nL1 Traversal\nIn the L1 Traversal stage, we simply read the header of the next L1 block. In normal operations, these will be new\nL1 blocks as they get created, though we can also read old blocks while syncing, or in case of an L1 re-org.\nUpon traversal of the L1 block, the system configuration copy used by the L1 retrieval stage is\nupdated, such that the batch-sender authentication is always accurate to the exact L1 block that is read by the stage.\nL1 Retrieval\nIn the L1 Retrieval stage, we read the block we get from the outer stage (L1 traversal), and\nextract data from its batcher transactions. A batcher\ntransaction is one with the following properties:\n\nThe to field is equal to the configured batcher inbox address.\n\nThe transaction type is one of 0, 1, 2, 3, or 0x7e (L2 Deposited transaction type, to\nsupport force-inclusion of batcher transactions on nested OP Stack chains).\n\nThe sender, as recovered from the transaction signature (v, r, and s), is the batcher\naddress loaded from the system config matching the L1 block of the data.\n\nEach batcher transaction is versioned and contains a series of channel frames to\nbe read by the Frame Queue, see Batch Submission Wire Format. Each batcher\ntransaction in the block is processed in the order they appear in the block by passing its calldata\non to the next phase.\nFrame Queue\nThe Frame Queue buffers one data-transaction at a time,\ndecoded into channel frames, to be consumed by the next stage.\nSee Batcher transaction format and Frame format specifications.\nChannel Bank\nThe Channel Bank stage is responsible for managing buffering from the channel bank that was written to by the L1\nretrieval stage. A step in the channel bank stage tries to read data from channels that are \"ready\".\nChannels are currently fully buffered until read or dropped,\nstreaming channels may be supported in a future version of the ChannelBank.\nTo bound resource usage, the Channel Bank prunes based on channel size, and times out old channels.\nChannels are recorded in FIFO order in a structure called the channel queue. A channel is added to the channel\nqueue the first time a frame belonging to the channel is seen.\nPruning\nAfter successfully inserting a new frame, the ChannelBank is pruned:\nchannels are dropped in FIFO order, until total_size <= MAX_CHANNEL_BANK_SIZE, where:\n\ntotal_size is the sum of the sizes of each channel, which is the sum of all buffered frame data of the channel,\nwith an additional frame-overhead of 200 bytes per frame.\nMAX_CHANNEL_BANK_SIZE is a protocol constant defined in the Protocol Parameters table.\n\nTimeouts\nThe L1 origin that the channel was opened in is tracked with the channel as channel.open_l1_block,\nand determines the maximum span of L1 blocks that the channel data is retained for, before being pruned.\nA channel is timed out if: current_l1_block.number > channel.open_l1_block.number + CHANNEL_TIMEOUT, where:\n\ncurrent_l1_block is the L1 origin that the stage is currently traversing.\nCHANNEL_TIMEOUT is a rollup-configurable, expressed in number of L1 blocks.\n\nNew frames for timed-out channels are dropped instead of buffered.\nReading\nUpon reading, while the first opened channel is timed-out, remove it from the channel-bank.\nPrior to the Canyon network upgrade, once the first opened channel, if any, is not timed-out and is ready,\nthen it is read and removed from the channel-bank. After the Canyon network upgrade, the entire channel bank\nis scanned in FIFO order (by open time) & the first ready (i.e. not timed-out) channel will be returned.\nThe canyon behavior will activate when frames from a L1 block whose timestamp is greater than or equal to the\ncanyon time first enter the channel queue.\nA channel is ready if:\n\nThe channel is closed\nThe channel has a contiguous sequence of frames until the closing frame\n\nIf no channel is ready, the next frame is read and ingested into the channel bank.\nLoading frames\nWhen a channel ID referenced by a frame is not already present in the Channel Bank,\na new channel is opened, tagged with the current L1 block, and appended to the channel-queue.\nFrame insertion conditions:\n\nNew frames matching timed-out channels that have not yet been pruned from the channel-bank are dropped.\nDuplicate frames (by frame number) for frames that have not been pruned from the channel-bank are dropped.\nDuplicate closes (new frame is_last == 1, but the channel has already seen a closing frame and has not yet been\npruned from the channel-bank) are dropped.\n\nIf a frame is closing (is_last == 1) any existing higher-numbered frames are removed from the channel.\nNote that while this allows channel IDs to be reused once they have been pruned from the channel-bank, it is recommended\nthat batcher implementations use unique channel IDs.\nChannel Reader (Batch Decoding)\nIn this stage, we decompress the channel we pull from the last stage, and then parse\nbatches from the decompressed byte stream.\nSee Channel Format and Batch Format for decompression and\ndecoding specification.\nBatch Queue\nDuring the Batch Buffering stage, we reorder batches by their timestamps. If batches are missing for some time\nslots and a valid batch with a higher timestamp exists, this stage also generates empty batches to fill\nthe gaps.\nBatches are pushed to the next stage whenever there is one sequential batch directly following the timestamp\nof the current safe L2 head (the last block that can be derived from the canonical L1 chain).\nThe parent hash of the batch must also match the hash of the current safe L2 head.\nNote that the presence of any gaps in the batches derived from L1 means that this stage will need to buffer for a whole\nsequencing window before it can generate empty batches (because the missing batch(es) could have\ndata in the last L1 block of the window in the worst case).\nA batch can have 4 different forms of validity:\n\ndrop: the batch is invalid, and will always be in the future, unless we reorg. It can be removed from the buffer.\naccept: the batch is valid and should be processed.\nundecided: we are lacking L1 information until we can proceed batch filtering.\nfuture: the batch may be valid, but cannot be processed yet and should be checked again later.\n\nThe batches are processed in order of the inclusion on L1: if multiple batches can be accept-ed the first is applied.\nAn implementation can defer future batches a later derivation step to reduce validation work.\nThe batches validity is derived as follows:\nDefinitions:\n\nbatch as defined in the Batch format section.\nepoch = safe_l2_head.l1_origin a L1 origin coupled to the batch, with properties:\nnumber (L1 block number), hash (L1 block hash), and timestamp (L1 block timestamp).\ninclusion_block_number is the L1 block number when batch was first fully derived,\ni.e. decoded and output by the previous stage.\nnext_timestamp = safe_l2_head.timestamp + block_time is the expected L2 timestamp the next batch should have,\nsee block time information.\nnext_epoch may not be known yet, but would be the L1 block after epoch if available.\nbatch_origin is either epoch or next_epoch, depending on validation.\n\nNote that processing of a batch can be deferred until batch.timestamp <= next_timestamp,\nsince future batches will have to be retained anyway.\nRules, in validation order:\n\nbatch.timestamp > next_timestamp -> future: i.e. the batch must be ready to process.\nbatch.timestamp < next_timestamp -> drop: i.e. the batch must not be too old.\nbatch.parent_hash != safe_l2_head.hash -> drop: i.e. the parent hash must be equal to the L2 safe head block hash.\nbatch.epoch_num + sequence_window_size < inclusion_block_number -> drop: i.e. the batch must be included timely.\nbatch.epoch_num < epoch.number -> drop: i.e. the batch origin is not older than that of the L2 safe head.\nbatch.epoch_num == epoch.number: define batch_origin as epoch.\nbatch.epoch_num == epoch.number+1:\n\nIf next_epoch is not known -> undecided:\ni.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data.\nIf known, then define batch_origin as next_epoch\n\nbatch.epoch_num > epoch.number+1 -> drop: i.e. the L1 origin cannot change by more than one L1 block per L2 block.\nbatch.epoch_hash != batch_origin.hash -> drop: i.e. a batch must reference a canonical L1 origin,\nto prevent batches from being replayed onto unexpected L1 chains.\nbatch.timestamp < batch_origin.time -> drop: enforce the min L2 timestamp rule.\nbatch.timestamp > batch_origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule,\nbut with exceptions to preserve above min L2 timestamp invariant:\n\nlen(batch.transactions) == 0:\n\nepoch.number == batch.epoch_num:\nthis implies the batch does not already advance the L1 origin, and must thus be checked against next_epoch.\n\nIf next_epoch is not known -> undecided:\nwithout the next L1 origin we cannot yet determine if time invariant could have been kept.\nIf batch.timestamp >= next_epoch.time -> drop:\nthe batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant.\n\nlen(batch.transactions) > 0: -> drop:\nwhen exceeding the sequencer time drift, never allow the sequencer to include transactions.\n\nbatch.transactions: drop if the batch.transactions list contains a transaction\nthat is invalid or derived by other means exclusively:\n\nany transaction that is empty (zero length byte string)\nany deposited transactions (identified by the transaction type prefix byte)\nany transaction of a future type > 2 (note that\nIsthmus adds support\nfor SetCode transactions of type 4\nand Lagoon adds PostExec transactions of type 0x7d)\n\nIf no batch can be accept-ed, and the stage has completed buffering of all batches that can fully be read from the L1\nblock at height epoch.number + sequence_window_size, and the next_epoch is available,\nthen an empty batch can be derived with the following properties:\n\nparent_hash = safe_l2_head.hash\ntimestamp = next_timestamp\ntransactions is empty, i.e. no sequencer transactions. Deposited transactions may be added in the next stage.\nIf next_timestamp < next_epoch.time: the current L1 origin is repeated, to preserve the L2 time invariant.\n\nepoch_num = epoch.number\nepoch_hash = epoch.hash\n\nIf the batch is the first batch of the epoch, that epoch is used instead of advancing the epoch to ensure that\nthere is at least one L2 block per epoch.\n\nepoch_num = epoch.number\nepoch_hash = epoch.hash\n\nOtherwise,\n\nepoch_num = next_epoch.number\nepoch_hash = next_epoch.hash\n\nPayload Attributes Derivation\nIn the Payload Attributes Derivation stage, we convert the batches we get from the previous stage into instances of\nthe PayloadAttributes structure. Such a structure encodes the transactions that need to figure into\na block, as well as other block inputs (timestamp, fee recipient, etc). Payload attributes derivation is detailed in the\nsection Deriving Payload Attributes section below.\nThis stage maintains its own copy of the system configuration, independent of the L1 retrieval stage.\nThe system configuration is updated with L1 log events whenever the L1 epoch referenced by the batch input changes.\nEngine Queue\nIn the Engine Queue stage, the previously derived PayloadAttributes structures are buffered and sent to the\nexecution engine to be executed and converted into a proper L2 block.\nThe stage maintains references to three L2 blocks:\n\nThe finalized L2 head: everything up to and including this block can be fully derived from the\nfinalized (i.e. canonical and forever irreversible) part of the L1 chain.\nThe safe L2 head: everything up to and including this block can be fully derived from the\ncurrently canonical L1 chain.\nThe unsafe L2 head: blocks between the safe and unsafe heads are unsafe\nblocks that have not been derived from L1. These blocks either come from sequencing (in sequencer\nmode) or from unsafe sync to the sequencer (in validator mode).\nThis is also known as the \"latest\" head.\n\nAdditionally, it buffers a short history of references to recently processed safe L2 blocks, along with references\nfrom which L1 blocks each was derived.\nThis history does not have to be complete, but enables later L1 finality signals to be translated into L2 finality.\nEngine API usage\nTo interact with the engine, the execution engine API is used, with the following JSON-RPC methods:\nBedrock, Canyon, Delta: API Usage\n\nengine_forkchoiceUpdatedV2 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and\ninstructs the engine to start building an execution payload if the payload attributes parameter is not null.\nengine_getPayloadV2 — retrieves a previously requested execution payload build.\nengine_newPayloadV2 — executes an execution payload to create a block.\n\nEcotone: API Usage\n\nengine_forkchoiceUpdatedV3 — updates the forkchoice (i.e. the chain head) to headBlockHash if different, and\ninstructs the engine to start building an execution payload if the payload attributes parameter is not null.\nengine_getPayloadV3 — retrieves a previously requested execution payload build.\nengine_newPayload\n\nengine_newPayloadV2 — executes a Bedrock/Canyon/Delta execution payload to create a block.\nengine_newPayloadV3 — executes an Ecotone execution payload to create a block.\nengine_newPayloadV4 - executes an Isthmus execution payload to create a block.\n\nThe current version of op-node uses the v4 Engine API RPC methods as well as engine_newPayloadV3 and\nengine_newPayloadV2, due to engine_newPayloadV4 only supporting Isthmus execution payloads. Both\nengine_forkchoiceUpdatedV4 and engine_getPayloadV4 are backwards compatible with Ecotone, Bedrock,\nCanyon & Delta payloads.\nPrior versions of op-node used v3, v2 and v1 methods.\nThe execution payload is an object of type ExecutionPayloadV3.\nThe ExecutionPayload has the following requirements:\n\nBedrock\n\nThe withdrawals field MUST be nil\nThe blob gas used field MUST be nil\nThe blob gas limit field MUST be nil\n\nCanyon, Delta\n\nThe withdrawals field MUST be non-nil\nThe withdrawals field MUST be an empty list\nThe blob gas used field MUST be nil\nThe blob gas limit field MUST be nil\n\nEcotone\n\nThe withdrawals field MUST be non-nil\nThe withdrawals field MUST be an empty list\nThe blob gas used field MUST be 0\nThe blob gas limit field MUST be 0\n\nForkchoice synchronization\nIf there are any forkchoice updates to be applied, before additional inputs are derived or processed, then these are\napplied to the engine first.\nThis synchronization may happen when:\n\nA L1 finality signal finalizes one or more L2 blocks: updating the \"finalized\" L2 block.\nA successful consolidation of unsafe L2 blocks: updating the \"safe\" L2 block.\nThe first thing after a derivation pipeline reset, to ensure a consistent execution engine forkchoice state.\n\nThe new forkchoice state is applied by calling fork choice updated on the engine API.\nOn forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.\nL1-consolidation: payload attributes matching\nIf the unsafe head is ahead of the safe head, then consolidation is attempted, verifying that\nexisting unsafe L2 chain matches the derived L2 inputs as derived from the canonical L1 data.\nDuring consolidation, we consider the oldest unsafe L2 block, i.e. the unsafe L2 block directly after the safe head. If\nthe payload attributes match this oldest unsafe L2 block, then that block can be considered \"safe\" and becomes the new\nsafe head.\nThe following fields of the derived L2 payload attributes are checked for equality with the L2 block:\n\nBedrock, Canyon, Delta, Ecotone Blocks\n\nparent_hash\ntimestamp\nrandao\nfee_recipient\ntransactions_list (first length, then equality of each of the encoded transactions, including deposits)\ngas_limit\n\nCanyon, Delta, Ecotone Blocks\n\nwithdrawals (first presence, then length, then equality of each of the encoded withdrawals)\n\nEcotone Blocks\n\nparent_beacon_block_root\n\nIf consolidation succeeds, the forkchoice change will synchronize as described in the section above.\nIf consolidation fails, the L2 payload attributes will be processed immediately as described in the section below.\nThe payload attributes are chosen in favor of the previous unsafe L2 block, creating an L2 chain reorg on top of the\ncurrent safe block. Immediately processing the new alternative attributes enables execution engines like go-ethereum to\nenact the change, as linear rewinds of the tip of the chain may not be supported.\nL1-sync: payload attributes processing\nIf the safe and unsafe L2 heads are identical (whether because of failed consolidation or not), we send the L2 payload\nattributes to the execution engine to be constructed into a proper L2 block.\nThis L2 block will then become both the new L2 safe and unsafe head.\nIf a payload attributes created from a batch cannot be inserted into the chain because of a validation error (i.e. there\nwas an invalid transaction or state transition in the block) the batch should be dropped & the safe head should not be\nadvanced. The engine queue will attempt to use the next batch for that timestamp from the batch queue. If no valid batch\nis found, the rollup node will create a deposit only batch which should always pass validation because deposits are\nalways valid.\nInteraction with the execution engine via the execution engine API is detailed in the Communication with the Execution\nEngine section.\nThe payload attributes are then processed with a sequence of:\n\nEngine: Fork choice updated with current forkchoice state of the stage, and the attributes to\nstart block building.\n\nNon-deterministic sources, like the tx-pool, must be disabled to reconstruct the expected block.\n\nEngine: Get Payload to retrieve the payload, by the payload-ID in the result of the previous\nstep.\nEngine: New Payload to import the new payload into the execution engine.\nEngine: Fork Choice Updated to make the new payload canonical,\nnow with a change of both safe and unsafe fields to refer to the payload, and no payload attributes.\n\nEngine API Error handling:\n\nOn RPC-type errors the payload attributes processing should be re-attempted in a future step.\nOn payload processing errors the attributes must be dropped, and the forkchoice state must be left unchanged.\n\nEventually the derivation pipeline will produce alternative payload attributes, with or without batches.\nIf the payload attributes only contained deposits, then it is a critical derivation error if these are invalid.\n\nOn forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.\n\nProcessing unsafe payload attributes\nIf no forkchoice updates or L1 data remain to be processed, and if the next possible L2 block is already available\nthrough an unsafe source such as the sequencer publishing it via the p2p network, then it is optimistically processed as\nan \"unsafe\" block. This reduces later derivation work to just consolidation with L1 in the happy case, and enables the\nuser to see the head of the L2 chain faster than the L1 may confirm the L2 batches.\nTo process unsafe payloads, the payload must:\n\nHave a block number higher than the current safe L2 head.\n\nThe safe L2 head may only be reorged out due to L1 reorgs.\n\nHave a parent blockhash that matches the current unsafe L2 head.\n\nThis prevents the execution engine individually syncing a larger gap in the unsafe L2 chain.\nThis prevents unsafe L2 blocks from reorging other previously validated L2 blocks.\nThis check may change in the future versions to adopt e.g. the L1 snap-sync protocol.\n\nThe payload is then processed with a sequence of:\n\nBedrock/Canyon/Delta Payloads\n\nengine_newPayloadV2: process the payload. It does not become canonical yet.\nengine_forkchoiceUpdatedV2: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads.\n\nEcotone Payloads\n\nengine_newPayloadV3: process the payload. It does not become canonical yet.\nengine_forkchoiceUpdatedV3: make the payload the canonical unsafe L2 head, and keep the safe/finalized L2 heads.\n\nIsthmus Payloads\n\nengine_newPayloadV4: process the payload. It does not become canonical yet.\n\nEngine API Error handling:\n\nOn RPC-type errors the payload processing should be re-attempted in a future step.\nOn payload processing errors the payload must be dropped, and not be marked as canonical.\nOn forkchoice-state validity errors the derivation pipeline must be reset to recover to consistent state.\n\nResetting the Pipeline\nIt is possible to reset the pipeline, for instance if we detect an L1 reorg (reorganization).\nThis enables the rollup node to handle L1 chain reorg events.\nResetting will recover the pipeline into a state that produces the same outputs as a full L2 derivation process,\nbut starting from an existing L2 chain that is traversed back just enough to reconcile with the current L1 chain.\nNote that this algorithm covers several important use-cases:\n\nInitialize the pipeline without starting from 0, e.g. when the rollup node restarts with an existing engine instance.\nRecover the pipeline if it becomes inconsistent with the execution engine chain, e.g. when the engine syncs/changes.\nRecover the pipeline when the L1 chain reorganizes, e.g. a late L1 block is orphaned, or a larger attestation failure.\nInitialize the pipeline to derive a disputed L2 block with prior L1 and L2 history inside a fault-proof program.\n\nHandling these cases also means a node can be configured to eagerly sync L1 data with 0 confirmations,\nas it can undo the changes if the L1 later does recognize the data as canonical, enabling safe low-latency usage.\nThe Engine Queue is first reset, to determine the L1 and L2 starting points to continue derivation from.\nAfter this, the other stages are reset independent of each other.\nFinding the sync starting point\nTo find the starting point, there are several steps, relative to the head of the chain traversing back:\n\nFind the current L2 forkchoice state\n\nIf no finalized block can be found, start at the Bedrock genesis block.\nIf no safe block can be found, fallback to the finalized block.\nThe unsafe block should always be available and consistent with the above\n(it may not be in rare engine-corruption recovery cases, this is being reviewed).\n\nFind the first L2 block with plausible L1 reference to be the new unsafe starting point,\nstarting from previous unsafe, back to finalized and no further.\n\nPlausible iff: the L1 origin of the L2 block is known and canonical, or unknown and has a block-number ahead of L1.\n\nFind the first L2 block with an L1 reference older than the sequencing window, to be the new safe starting point,\nstarting at the above plausible unsafe head, back to finalized and no further.\n\nIf at any point the L1 origin is known but not canonical, the unsafe head is revised to parent of the current.\nThe highest L2 block with known canonical L1 origin is remembered as highest.\nIf at any point the L1 origin in the block is corrupt w.r.t. derivation rules, then error. Corruption includes:\n\nInconsistent L1 origin block number or parent-hash with parent L1 origin\nInconsistent L1 sequence number (always changes to 0 for a L1 origin change, or increments by 1 if not)\n\nIf the L1 origin of the L2 block n is older than the L1 origin of highest by more than a sequence window,\nand n.sequence_number == 0, then the parent L2 block of n will be the safe starting point.\n\nThe finalized L2 block persists as the finalized starting point.\nFind the first L2 block with an L1 reference older than the channel-timeout\n\nThe L1 origin referenced by this block which we call l2base will be the base for the L2 pipeline derivation:\nBy starting here, the stages can buffer any necessary data, while dropping incomplete derivation outputs until\nL1 traversal has caught up with the actual L2 safe head.\n\nWhile traversing back the L2 chain, an implementation may sanity-check that the starting point is never set too far\nback compared to the existing forkchoice state, to avoid an intensive reorg because of misconfiguration.\nImplementers note: step 1-4 are known as FindL2Heads. Step 5 is currently part of the Engine Queue reset.\nThis may change to isolate the starting-point search from the bare reset logic.\nResetting derivation stages\n\nL1 Traversal: start at L1 base as first block to be pulled by next stage.\nL1 Retrieval: empty previous data, and fetch the base L1 data, or defer the fetching work to a later pipeline step.\nFrame Queue: empty the queue.\nChannel Bank: empty the channel bank.\nChannel Reader: reset any batch decoding state.\nBatch Queue: empty the batch queue, use base as initial L1 point of reference.\nPayload Attributes Derivation: empty any batch/attributes state.\nEngine Queue:\n\nInitialize L2 forkchoice state with syncing start point state. (finalized/safe/unsafe)\nInitialize the L1 point of reference of the stage to base.\nRequire a forkchoice update as first task\nReset any finality data\n\nWhere necessary, stages starting at base can initialize their system-config from data encoded in the l2base block.\nAbout reorgs Post-Merge\nNote that post-merge, the depth of reorgs will be bounded by the L1 finality delay\n(2 L1 beacon epochs, or approximately 13 minutes, unless more than 1/3 of the network consistently disagrees).\nNew L1 blocks may be finalized every L1 beacon epoch (approximately 6.4 minutes), and depending on these\nfinality-signals and batch-inclusion, the derived L2 chain will become irreversible as well.\nNote that this form of finalization only affects inputs, and nodes can then subjectively say the chain is irreversible,\nby reproducing the chain from these irreversible inputs and the set protocol rules and parameters.\nThis is however completely unrelated to the outputs posted on L1, which require a form of proof like a fault-proof or\nzk-proof to finalize. Optimistic-rollup outputs like withdrawals on L1 are only labeled \"finalized\" after passing a week\nwithout dispute (fault proof challenge window), a name-collision with the proof-of-stake finalization.\n\nDeriving Payload Attributes\nFor every L2 block derived from L1 data, we need to build payload attributes,\nrepresented by an expanded version of the PayloadAttributesV2 object,\nwhich includes additional transactions and noTxPool fields.\nThis process happens during the payloads-attributes queue ran by a verifier node, as well as during block-production\nran by a sequencer node (the sequencer may enable the tx-pool usage if the transactions are batch-submitted).\nDeriving the Transaction List\nFor each L2 block to be created by the sequencer, we start from a sequencer batch matching the\ntarget L2 block number. This could potentially be an empty auto-generated batch, if the L1 chain did not include a batch\nfor the target L2 block number. Remember that the batch includes a sequencing\nepoch number, an L2 timestamp, and a transaction list.\nThis block is part of a sequencing epoch,\nwhose number matches that of an L1 block (its L1 origin).\nThis L1 block is used to derive L1 attributes and (for the first L2 block in the epoch) user deposits.\nTherefore, a PayloadAttributesV2 object must include the following transactions:\n\none or more deposited transactions, of two kinds:\n\na single L1 attributes deposited transaction, derived from the L1 origin.\nfor the first L2 block in the epoch, zero or more user-deposited transactions, derived from\nthe receipts of the L1 origin.\n\nzero or more network upgrade automation transactions: special transactions to perform network upgrades.\nzero or more sequenced transactions: regular transactions signed by L2 users, included in the\nsequencer batch.\n\nTransactions must appear in this order in the payload attributes.\nThe L1 attributes are read from the L1 block header, while deposits are read from the L1 block's receipts.\nRefer to the deposit contract specification for details on how deposits are encoded as log\nentries.\nLogs are derived from transactions following the future-proof best-effort process described in\nOn Future Proof Transaction Log Derivation\nNetwork upgrade automation transactions\nSome network upgrades require automated contract changes or deployments at specific blocks.\nTo automate these, without adding persistent changes to the execution-layer,\nspecial transactions may be inserted as part of the derivation process.\nBuilding Individual Payload Attributes\nAfter deriving the transactions list, the rollup node constructs a PayloadAttributesV2 as\nfollows:\n\ntimestamp is set to the batch's timestamp.\nrandom is set to the prev_randao L1 block attribute.\nsuggestedFeeRecipient is set to the Sequencer Fee Vault address. See Fee Vaults specification.\ntransactions is the array of the derived transactions: deposited transactions and sequenced transactions, all\nencoded with EIP-2718.\nnoTxPool is set to true, to use the exact above transactions list when constructing the block.\ngasLimit is set to the current gasLimit value in the system configuration of this payload.\nwithdrawals is set to nil prior to Canyon and an empty array after Canyon\n\nOn Future-Proof Transaction Log Derivation\nAs described in L1 Retrieval, batcher transactions' types are required to be from a fixed allow-list.\nHowever, we want to allow deposit transactions and SystemConfig update events to get derived even from receipts of\nfuture transaction types, as long as the receipts can be decoded following a best-effort process:\nAs long as a future transaction type follows the EIP-2718 specification, the\ntype can be decoded from the first byte of the transaction's (or its receipt's) binary encoding. We can then proceed as\nfollows to get the logs of such a future transaction, or discard the transaction's receipt as invalid.\n\nIf it's a known transaction type, that is, legacy (first byte of the encoding is in the range [0xc0, 0xfe]) or its\nfirst byte is in the range [0, 4] or 0x7e (deposited), then it's not a future transaction and we know how to\ndecode the receipt and this process is irrelevant.\nIf a transaction's first byte is in the range [0x05, 0x7d], it is expected to be a future EIP-2718 transaction, so\nwe can proceed to the receipt. Note that we excluded 0x7e because that's the deposit transaction type, which is known.\nThe future receipt encoding's first byte must be the same byte as the transaction encoding's first byte, or it is\ndiscarded as invalid, because we require it to be an EIP-2718-encoded receipt to continue.\nThe receipt payload is decoded as if it is encoded as rlp([status, cumulative_transaction_gas_used, logs_bloom, logs]), which is the encoding of the known non-legacy transaction types.\n\nIf this decoding fails, the transaction's receipt is discarded as invalid.\nIf this decoding succeeds, the logs have been obtained and can be processed as those of known transaction types.\n\nThe intention of this best-effort decoding process is to future-proof the protocol for new L1 transaction types.","tokens":12824,"squid":"ink-governance","role":"Council Listener","at":1791261034023,"hash":"723831e4c7ead36dfb25fb439fae819f03cab23d"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/47","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 46 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n post by pipermerriam on May 20, 2025\n\n post by peersky on May 20, 2025\n\n post by peersky on May 20, 2025\n\n post by MicahZoltu on May 21, 2025\n\n post by MicahZoltu on May 21, 2025\n\n post by pipermerriam on May 21, 2025\n\n post by MicahZoltu on May 21, 2025\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n post by kladkogex on May 26, 2025\n\n post by MicahZoltu on May 27, 2025\n\n post by peersky on May 27, 2025\n\n post by ncitron on May 29, 2025\n\n post by vbuterin on May 30, 2025\n\n post by kladkogex on Jun 4, 2025\n\n Powered by Discourse","tokens":1134,"squid":"ink-research","role":"Deep Scholar","at":1791261038165,"hash":"26bcb353a7567d646085ea1acbcb72244acb2add"}
{"url":"https://specs.optimism.io/protocol/overview.html","domain":"specs.optimism.io","title":"OP Stack Protocol - OP Stack Specification","text":"Optimism Overview\n\nTable of Contents\n\nArchitecture Design Goals\nArchitecture Overview\n\nCore L1 Smart Contracts\n\nNotes for Core L1 Smart Contracts\n\nCore L2 Smart Contracts\n\nNotes for Core L2 Smart Contracts\n\nSmart Contract Proxies\n\nL2 contract upgrades\n\nL2 Node Components\nTransaction/Block Propagation\n\nKey Interactions In Depth\n\nDeposits\nBlock Derivation\n\nOverview\nEpochs and the Sequencing Window\nBlock Derivation Loop\n\nEngine API\n\nThis document is a high-level technical overview of the Optimism protocol. It aims to explain how the protocol works in\nan informal manner, and direct readers to other parts of the specification so that they may learn more.\nThis document assumes you've read the background.\nArchitecture Design Goals\n\nExecution-Level EVM Equivalence: The developer experience should be identical to L1 except where L2 introduces a\nfundamental difference.\n\nNo special compiler.\nNo unexpected gas costs.\nTransaction traces work out-of-the-box.\nAll existing Ethereum tooling works - all you have to do is change the chain ID.\n\nMaximal compatibility with ETH1 nodes: The implementation should minimize any differences with a vanilla\nexecution-layer node, and leverage as many existing L1 standards as possible.\n\nThe execution engine/rollup node uses the ETH2 Engine API to build the canonical L2 chain.\nThe execution engine leverages the execution layer's existing mempool and sync implementations, including snap sync.\n\nMinimize state and complexity:\n\nWhenever possible, services contributing to the rollup infrastructure are stateless.\nStateful services can recover to full operation from a fresh DB using the peer-to-peer network and on-chain sync\nmechanisms.\nRunning a replica is as simple as running an execution-layer node.\n\nArchitecture Overview\nBlue nodes are upgradeable contracts, green nodes have fixed implementations, and orange nodes are actors or protocol\ntransactions. Grey nodes show other contracts, addresses, or configuration. Dotted arrows indicate reads.\nCore L1 Smart Contracts\nBelow you'll find architecture diagrams describing the core L1 smart contracts for the OP Stack.\nSmart contracts that are considered \"peripheral\" and not core to the operation of the OP Stack system are described separately.\nThese diagrams assume a single ETH-gas chain with ETHLockbox enabled.\n\nThe portal uses dispute games to verify withdrawals. Permissionless games dispute super roots at L2 timestamps;\nthe portal reads the output root for its chain from the selected game.\n\nNotes for Core L1 Smart Contracts\n\nSmart contracts that sit behind Proxy contracts are highlighted in BLUE. Refer to the\nSmart Contract Proxies section below to understand how these proxies are designed.\n\nThe L1CrossDomainMessenger contract sits behind the ResolvedDelegateProxy\ncontract, a legacy proxy contract type used within older versions of the OP Stack. This proxy type is used exclusively\nfor the L1CrossDomainMessenger to maintain backwards compatibility.\nThe L1StandardBridge contract sits behind the L1ChugSplashProxy\ncontract, a legacy proxy contract type used within older versions of the OP Stack. This proxy type is used exclusively\nfor the L1StandardBridge contract to maintain backwards compatibility.\n\nThe factory creates dispute games as clones with immutable arguments; MIPS64 and PreimageOracle are deployed\ndirectly.\nSuperFaultDisputeGame uses game type SUPER_CANNON_KONA (9). SuperPermissionedDisputeGame uses\nSUPER_PERMISSIONED (5) and accepts proposals only from its configured proposer. It resolves immediately in favor of\nthe proposal, without challenges or bonds. Withdrawal finality and Guardian checks still apply.\nUsers deposit or withdraw ETH and tokens through the bridges. They can also deposit directly through OptimismPortal,\nwhere they prove and finalize withdrawals.\nThe bridges, messenger, portal, ETHLockbox, AnchorStateRegistry, and DelayedWETH read pause state through\nSystemConfig. It combines the global pause state from SuperchainConfig\nwith the chain-specific pause state, identified by ETHLockbox. The portal also reads its configuration from SystemConfig.\nThe Guardian pauses or unpauses SuperchainConfig; a Pause Deputy installed through the\nDeputyPauseModule can trigger, but not lift, the pause. The Guardian can also blacklist or\nretire games and set the respected game type in AnchorStateRegistry. The ProxyAdmin owner also owns\nDisputeGameFactory in the standard configuration: it registers game-type implementations and init bonds, and can\nhold or recover bonds in DelayedWETH.\nProposers create games through DisputeGameFactory; AnchorStateRegistry checks game registration with the factory.\nParticipants challenge or defend permissionless games and supply preimages to PreimageOracle.\n\nCore L2 Smart Contracts\nHere you'll find architecture diagrams describing the core OP Stack smart contracts that exist natively on the L2 chain\nitself.\n\nThe L2 bridges mint, burn, or transfer tokens and send withdrawal messages through L2ToL1MessagePasser.\nDeposits can call L2CrossDomainMessenger to relay messages from L1. Both deposits and user transactions can also\ntarget other L2 contracts or addresses.\n\nNotes for Core L2 Smart Contracts\n\nL1 attributes transactions update L1Block, and the execution engine credits transaction fees to the fee vaults.\nGasPriceOracle reads fee parameters from L1Block.\nUsers typically do not mutate these contracts directly, except in the case of the FeeVault contracts where\nany user may trigger a withdrawal of collected fees to the pre-determined withdrawal address.\nFee vault withdrawals can target L1 through L2ToL1MessagePasser, or L2 directly, depending on the vault's configuration.\nThe execution engine also updates the beacon roots contract with the\nL1 origin's parent beacon block root and the\nhistory storage contract with L2 block hashes.\nUser interactions for the \"L2 Bridge Contracts\" have been omitted from these diagrams but largely follow the same user\ninteractions described in the notes for the Core L1 Smart Contracts.\n\nSmart Contract Proxies\nMost OP Stack smart contracts sit behind Proxy contracts that are managed by a ProxyAdmin contract.\nThe ProxyAdmin contract is controlled by some owner address that is a Safe multisig in the standard configuration.\nBelow you'll find a diagram that explains the behavior of the typical proxy contract.\n\nOn L1, the ProxyAdmin owner uses OP Contracts Manager to coordinate upgrades.\nThe owner's Safe delegatecalls the manager, so its calls to ProxyAdmin execute with the owner's authority.\nL2 contract upgrades\nNetwork upgrade transactions run at fork activation. They deploy the new\nimplementations and a version of L2ContractsManager, then call L2ProxyAdmin.upgradePredeploys from DEPOSITOR_ACCOUNT.\nL2ProxyAdmin delegatecalls the manager, which upgrades the predeploy proxies atomically and preserves their existing\nchain configuration. Only DEPOSITOR_ACCOUNT can call upgradePredeploys; the L2ProxyAdmin owner can still use its\nordinary administrative upgrade methods.\n\nConditionalDeployer, L2ProxyAdmin, and L2DevFeatureFlags are proxied predeploys. L2ContractsManager is deployed\nseparately for each upgrade. Its upgrade calls execute in L2ProxyAdmin's context. See the\nL2 upgrade contracts specification\nfor the deployment and configuration rules.\nL2 Node Components\nBelow you'll find a diagram illustrating the basic interactions between the components that make up an L2 node as well\nas demonstrations of how different actors use these components to fulfill their roles.\n\nThe rollup node also reads configuration updates from SystemConfig on L1.\nThe Batch Inbox Address shown above (highlighted in GREY) is not a smart contract and is instead an arbitrarily\nselected account that is assumed to have no known private key. The convention for deriving this account's address is\nprovided on the Configurability page.\n\nHistorically, it was often derived as\n0xFF0000....<L2 chain ID> where <L2 chain ID> is chain ID of the Layer 2 network for which the data is being posted.\nThis is why many chains, such as OP Mainnet, have a batch inbox address of this form.\n\nTransaction/Block Propagation\nSpec links:\n\nExecution Engine\n\nSince the execution engine implements the standard Ethereum execution-layer protocol, the OP Stack reuses the existing\npeer-to-peer network and transaction pool to propagate transactions. Execution clients interoperate on this network.\nThe same network can also be used to propagate submitted blocks and support snap-sync.\nUnsubmitted blocks, however, are propagated using a separate peer-to-peer network of Rollup Nodes. This is optional,\nhowever, and is provided as a convenience to lower latency for verifiers and their JSON-RPC clients.\nThe below diagram illustrates how the sequencer and verifiers fit together:\n\nKey Interactions In Depth\nDeposits\nSpec links:\n\nDeposits\n\nOptimism supports user deposits and L1 attributes deposits. To perform a user deposit, users\ncall the depositTransaction method on the OptimismPortal contract. This in turn emits TransactionDeposited events,\nwhich the rollup node reads during block derivation.\nL1 attributes deposits are used to register L1 block attributes (number, timestamp, etc.) on L2 via a call to the L1\nAttributes Predeploy. They cannot be initiated by users, and are instead added to L2 blocks automatically by the rollup\nnode.\nBoth deposit types are represented by a single custom EIP-2718 transaction type on L2.\nNetwork upgrade transactions also use this type at fork\nactivation to deploy and upgrade L2 contracts.\nBlock Derivation\nOverview\nThe rollup chain can be deterministically derived given an L1 Ethereum chain. The fact that the entire rollup chain can\nbe derived based on L1 blocks is what makes Optimism a rollup. This process can be represented as:\nderive_rollup_chain(l1_blockchain) -> rollup_blockchain\n\nOptimism's block derivation function is designed such that it:\n\nRequires no state other than what is easily accessible using L1 and L2 execution engine APIs.\nSupports sequencers and sequencer consensus.\nIs resilient to sequencer censorship.\n\nEpochs and the Sequencing Window\nThe rollup chain is subdivided into epochs. There is a 1:1 correspondence between L1 block numbers and epoch numbers.\nFor L1 block number n, there is a corresponding rollup epoch n which can only be derived after a sequencing window\nworth of blocks has passed, i.e. after L1 block number n + SEQUENCING_WINDOW_SIZE is added to the L1 chain.\nEach epoch contains at least one block. Every block in the epoch contains an L1 info transaction which contains\ncontextual information about L1 such as the block hash and timestamp. The first block in the epoch also contains all\ndeposits initiated via the OptimismPortal contract on L1. All L2 blocks can also contain sequenced transactions,\ni.e. transactions submitted directly to the sequencer.\nWhenever the sequencer creates a new L2 block for a given epoch, it must submit it to L1 as part of a batch, within\nthe epoch's sequencing window (i.e. the batch must land before L1 block n + SEQUENCING_WINDOW_SIZE). These batches are\n(along with the TransactionDeposited L1 events) what allows the derivation of the L2 chain from the L1 chain.\nThe sequencer does not need for a L2 block to be batch-submitted to L1 in order to build on top of it. In fact, batches\ntypically contain multiple L2 blocks worth of sequenced transactions. This is what enables\nfast transaction confirmations on the sequencer.\nSince transaction batches for a given epoch can be submitted anywhere within the sequencing window, verifiers must\nsearch all blocks within the window for transaction batches. This protects against the uncertainty of transaction\ninclusion of L1. This uncertainty is also why we need the sequencing window in the first place: otherwise the sequencer\ncould retroactively add blocks to an old epoch, and validators wouldn't know when they can finalize an epoch.\nThe sequencing window also prevents censorship by the sequencer: deposits made on a given L1 block will be included in\nthe L2 chain at worst after SEQUENCING_WINDOW_SIZE L1 blocks have passed.\nThe following diagram describes this relationship, and how L2 blocks are derived from L1 blocks (L1 info transactions\nhave been elided):\n\nBlock Derivation Loop\nA sub-component of the rollup node called the rollup driver is actually responsible for performing block derivation.\nThe rollup driver is essentially an infinite loop that runs the block derivation function. For each epoch, the block\nderivation function performs the following steps:\n\nDownloads deposit and transaction batch data for each block in the sequencing window.\nConverts the deposit and transaction batch data into payload attributes for the Engine API.\nSubmits the payload attributes to the Engine API, where they are converted into blocks and added to the canonical\nchain.\n\nThis process is then repeated with incrementing epochs until the tip of L1 is reached.\nEngine API\nThe rollup driver doesn't actually create blocks. Instead, it directs the execution engine to do so via the Engine API.\nFor each iteration of the block derivation loop described above, the rollup driver will craft a payload attributes\nobject and send it to the execution engine. The execution engine will then convert the payload attributes object into a\nblock, and add it to the chain. The basic sequence of the rollup driver is as follows:\n\nCall fork choice updated with the payload attributes object. We'll skip over the details of the\nfork choice state parameter for now - just know that one of its fields is the L2 chain's headBlockHash, and that it\nis set to the block hash of the tip of the L2 chain. The Engine API returns a payload ID.\nCall get payload with the payload ID returned in step 1. The engine API returns a payload object\nthat includes a block hash as one of its fields.\nCall new payload with the payload returned in step 2. (Ecotone blocks, must use V3, pre-Ecotone\nblocks MUST use the V2 version)\nCall fork choice updated with the fork choice parameter's headBlockHash set to the block hash\nreturned in step 2. The tip of the L2 chain is now the block created in step 1.\n\nThe swimlane diagram below visualizes the process:","tokens":3548,"squid":"ink-governance","role":"Council Listener","at":1791261045457,"hash":"64de2779ea9cc4eec5ee4f7614ba4557fb84e57e"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/49","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 47 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261050397,"hash":"0cbdb86662c78f3c2a23374152d7aa90a9e7b1a6"}
{"url":"https://institutions.ethereum.org/library","domain":"institutions.ethereum.org","title":"Research & Insights | Ethereum Institutional Resources","text":"Library: Institutional InsightsReports, articles, and analyses from across the institutional landscape, along with thought leadership and updates from the Ethereum Foundation's Enterprise Acceleration team.Explore market trends, technical developments, and strategic opportunities for institutions building in the onchain economy.RedStone - Case Study: How Securitize and RedStone Enable DeFi-Ready RWAs on Ethereum (opens in a new tab)February 26, 2026IPTF - Public Rails vs Private Ledgers (opens in a new tab)January 30, 2026Fusaka upgrade: Ethereum is securely scalingDecember 9, 2025a16zcrypto - State of Crypto (opens in a new tab)October 22, 2025MERGE Madrid - Future of Blockchain Infrastructure (opens in a new tab)October 15, 2025NextFin Summit - Low-risk DeFi on Ethereum (opens in a new tab)October 1, 2025Will all L1s Move to Ethereum? (opens in a new tab)October 1, 2025Citi - Stablecoins 2030 Web3 to Wall Street (opens in a new tab)September 25, 2025ETHTokyo - Ethereum: From tech to real (opens in a new tab)September 16, 2025Etherealize - Wall St Needs a Blockchain (opens in a new tab)September 15, 2025Fidelity - Coin report: Ethereum (ETH) (opens in a new tab)August 21, 2025Goldman Sachs - Stablecoin summer (opens in a new tab)August 19, 2025Consensys - The industrialization of trust report (opens in a new tab)August 4, 2025Fidelity - Blockchains as emerging economies (opens in a new tab)July 16, 2025Galaxy - Beyond Bitcoin: Ethereum as a corporate treasury asset (opens in a new tab)July 15, 2025EY - 2025 Institutional investor digital assets survey (opens in a new tab)March 18, 2025Blockchain Scotland - Ethereum: Enterprise adoption and financial services (opens in a new tab)September 5, 2024","tokens":431,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261050460,"hash":"675ad28d156f1c465db752f8479c857a1b75b482"}
{"url":"https://specs.optimism.io/protocol/guaranteed-gas-market.html","domain":"specs.optimism.io","title":"Guaranteed Gas Market - OP Stack Specification","text":"Guaranteed Gas Fee Market\n\nTable of Contents\n\nOverview\nGas Stipend\nDefault Values\nLimiting Guaranteed Gas\nRationale for burning L1 Gas\nOn Preventing Griefing Attacks\n\nOverview\nDeposited transactions are transactions on L2 that are\ninitiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment\nin the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits\nin a single L1 block.\nThe gas provided to deposited transactions is sometimes called \"guaranteed gas\". The gas provided to\ndeposited transactions is unique in the regard that it is not refundable. It cannot be refunded as\nit is sometimes paid for with a gas burn and there may not be any ETH left to refund.\nThe guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like\nto purchase (on L1) on top of that.\nGuaranteed gas on L2 is bought in the following manner. An L2 gas price is calculated via an\nEIP-1559-style algorithm. The total amount of ETH required to buy that gas is then calculated as\n(guaranteed gas * L2 deposit base fee). The contract then accepts that amount of ETH (in a future\nupgrade) or (only method right now), burns an amount of L1 gas that corresponds to the L2 cost (L2 cost / L1 base fee). The L2 gas price for guaranteed gas is not synchronized with the base fee on\nL2 and will likely be different.\nGas Stipend\nTo offset the gas spent on the deposit event, we credit gas spent * L1 base fee ETH to the cost\nof the L2 gas, where gas spent is the amount of L1 gas spent processing the deposit. If the ETH\nvalue of this credit is greater than the ETH value of the requested guaranteed gas (requested guaranteed gas * L2 gas price), no L1 gas is burnt.\nDefault Values\nVariableValue\nMAX_RESOURCE_LIMIT20,000,000\nELASTICITY_MULTIPLIER10\nBASE_FEE_MAX_CHANGE_DENOMINATOR8\nMINIMUM_BASE_FEE1 gwei\nMAXIMUM_BASE_FEEtype(uint128).max\nSYSTEM_TX_MAX_GAS1,000,000\nTARGET_RESOURCE_LIMITMAX_RESOURCE_LIMIT / ELASTICITY_MULTIPLIER\n\nLimiting Guaranteed Gas\nThe total amount of guaranteed gas that can be bought in a single L1 block must be limited to\nprevent a denial of service attack against L2 as well as ensure the total amount of guaranteed gas\nstays below the L2 block gas limit.\nWe set a guaranteed gas limit of MAX_RESOURCE_LIMIT gas per L1 block and a target of\nMAX_RESOURCE_LIMIT / ELASTICITY_MULTIPLIER gas per L1 block. These numbers enabled\noccasional large transactions while staying within our target and maximum gas usage on L2.\nBecause the amount of guaranteed L2 gas that can be purchased in a single block is now limited,\nwe implement an EIP-1559-style fee market to reduce congestion on deposits. By setting the limit\nat a multiple of the target, we enable deposits to temporarily use more L2 gas at a greater cost.\n# Pseudocode to update the L2 deposit base fee and cap the amount of guaranteed gas\n# bought in a block. Calling code must handle the gas burn and validity checks on\n# the ability of the account to afford this gas.\n\n# prev_base fee is a u128, prev_bought_gas and prev_num are u64s\nprev_base_fee, prev_bought_gas, prev_num = <values from previous update>\nnow_num = block.number\n\n# Clamp the full base fee to a specific range. The minimum value in the range should be around 100-1000\n# to enable faster responses in the base fee. This replaces the `max` mechanism in the ethereum 1559\n# implementation (it also serves to enable the base fee to increase if it is very small).\ndef clamp(v: i256, min: u128, max: u128) -> u128:\n if v < i256(min):\n return min\n elif v > i256(max):\n return max\n else:\n return u128(v)\n\n# If this is a new block, update the base fee and reset the total gas\n# If not, just update the total gas\nif prev_num == now_num:\n now_base_fee = prev_base_fee\n now_bought_gas = prev_bought_gas + requested_gas\nelif prev_num != now_num:\n # Width extension and conversion to signed integer math\n gas_used_delta = int128(prev_bought_gas) - int128(TARGET_RESOURCE_LIMIT)\n # Use truncating (round to 0) division - solidity's default.\n # Sign extend gas_used_delta & prev_base_fee to 256 bits to avoid overflows here.\n base_fee_per_gas_delta = prev_base_fee * gas_used_delta / TARGET_RESOURCE_LIMIT / BASE_FEE_MAX_CHANGE_DENOMINATOR\n now_base_fee_wide = prev_base_fee + base_fee_per_gas_delta\n\n now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=UINT_128_MAX_VALUE)\n now_bought_gas = requested_gas\n\n # If we skipped multiple blocks between the previous block and now update the base fee again.\n # This is not exactly the same as iterating the above function, but quite close for reasonable\n # gas target values. It is also constant time wrt the number of missed blocks which is important\n # for keeping gas usage stable.\n if prev_num + 1 < now_num:\n n = now_num - prev_num - 1\n # Apply 7/8 reduction to prev_base_fee for the n empty blocks in a row.\n now_base_fee_wide = now_base_fee * pow(1-(1/BASE_FEE_MAX_CHANGE_DENOMINATOR), n)\n now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=type(uint128).max)\n\nrequire(now_bought_gas < MAX_RESOURCE_LIMIT)\n\nstore_values(now_base_fee, now_bought_gas, now_num)\n\nRationale for burning L1 Gas\nThere must be a sybil resistance mechanism for usage of the network. If it is very cheap to get\nguaranteed gas on L2, then it would be possible to spam the network. Burning a dynamic amount\nof gas on L1 acts as a sybil resistance mechanism as it becomes more expensive with more demand.\nIf we collect ETH directly to pay for L2 gas, every (indirect) caller of the deposit function will need\nto be marked with the payable selector. This won't be possible for many existing projects. Unfortunately\nthis is quite wasteful. As such, we will provide two options to buy L2 gas:\n\nBurn L1 Gas\nSend ETH to the Optimism Portal (Not yet supported)\n\nThe payable version (Option 2) will likely have discount applied to it (or conversely, #1 has a\npremium applied to it).\nFor the initial release of bedrock, only #1 is supported.\nOn Preventing Griefing Attacks\nThe cost of purchasing all of the deposit gas in every block must be expensive\nenough to prevent attackers from griefing all deposits to the network.\nAn attacker would observe a deposit in the mempool and frontrun it with a deposit\nthat purchases enough gas such that the other deposit reverts.\nThe smaller the max resource limit is, the easier this attack is to pull off.\nThis attack is mitigated by having a large resource limit as well as a large\nelasticity multiplier. This means that the target resource usage is kept small,\ngiving a lot of room for the deposit base fee to rise when the max resource limit\nis being purchased.\nThis attack should be too expensive to pull off in practice, but if an extremely\nwealthy adversary does decide to grief network deposits for an extended period\nof time, efforts will be placed to ensure that deposits are able to be processed\non the network.","tokens":1726,"squid":"ink-governance","role":"Council Listener","at":1791261056246,"hash":"2ef96b54fdba9a69e368ef1b5defcbab01cb025e"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/52","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 49 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261063090,"hash":"5184131a6021d92670d7d00098c59fe7034e2ecf"}
{"url":"https://iptf.ethereum.org/public-rails-vs-private-ledgers/","domain":"iptf.ethereum.org","title":"Public Rails vs Private Ledgers · Writeups · EthSystems","text":"This post was written when IPTF (now EthSystems) was at the Ethereum Foundation\nAn institutional decision framework\nOver the past decade, many of us have watched a familiar pattern play out.\nA new “enterprise blockchain” arrives, promising privacy, control, and regulatory comfort. A consortium forms. Large financial institutions sign MOUs. Impressive proofs-of-concept, some live deployments, and then… stagnation.\nWas this because the technology was bad? Or because the permissioned consortium model has structural limits that even the best implementation cannot escape?\nWe use Canton as our reference point, not because it failed, but because it has gained real traction. Canton represents one of the most technically ambitious permissioned platforms to date, backed by tier-one institutions and some initial production deployments. If we want to understand the category’s limits, we should examine one of its strongest examples.\nWhat follows is a decision framework for institutions choosing between:\n\nPrivate ledgers with trust-based privacy, and\nPublic blockchains with cryptographic privacy.\n\nThe choice comes down to privacy by policy or privacy by math.\nDefinitions & Scope\nThe terminology misleads. “Public” blockchain does not necessarily mean your data is exposed. “Private” blockchain does not mean privacy-preserving. For institutions evaluating these platforms, what matters isn’t public versus private; it’s how privacy is enforced.\nTrust-based privacy (permissioned infrastructure): A known set of operators gate access. Counterparties see plaintext; non-participants are excluded by access control. Privacy depends on policy enforcement, legal agreements, and participants honoring them.\nCryptographic privacy (public infrastructure): Privacy is enforced by mathematics. Zero-knowledge proofs allow verification without disclosure. The infrastructure is public; your data is not.\nThis framework addresses a fundamental set of risks: a counterparty turns adversarial, a regulator demands data access years later, or an infrastructure operator gets pressured to change the rules. If you trust your consortium partners indefinitely and operate in a single jurisdiction, a standard database may suffice. Blockchains exist precisely for when trust breaks down.\n1. The Permissioned Promise\nFor technology and risk executives at large institutions, the appeal of permissioned ledgers is obvious. They look like what you already know.\nA permissioned consortium resembles traditional market infrastructure. Known parties around the table. Contractual governance. Vendor support with a runbook and a roadmap. Enterprise SLAs you can hold someone accountable to.\nFor a risk committee accustomed to these structures, the comfort is genuine:\n\nFamiliar governance: You know exactly who operates the infrastructure.\nRegulatory comfort: Participants are KYC’d; access is gated; operators are regulated entities.\nNo cryptographic complexity: Privacy comes from access control and contract law, not zero-knowledge proofs and novel threat models.\n\nThe promise unfolded in three waves:\n\nGen 1 (Hyperledger Fabric): IBM-backed, enterprise-grade, flexible.\nGen 2 (Corda): R3’s consortium, purpose-built for financial workflows.\nGen 3 (Canton): DAML’s smart contract language, a Global Synchronizer for cross-domain coordination, backing from DTCC, NASDAQ, and Goldman Sachs.\n\nThese were not irrational experiments. They mapped to existing institutional mental models. The question is: what have we learned after three generations?\n2. Case Study: Canton\nCanton is among the most ambitious permissioned platforms in production. Understanding what it achieved, and where it hits limits, reveals whether the constraints are specific to Canton or inherent to the permissioned model.\nInstitutional credibility. Partnerships with NASDAQ, DTCC, Goldman Sachs, Euroclear. The headline of trillions in represented asset value1 (tokenized records of off-chain assets, not natively on-chain) represents the largest permissioned deployment to date.\nTechnical sophistication. The Global Synchronizer enables cross-domain coordination. DAML’s sub-transaction privacy lets each participant see only their relevant slice. Two-phase commit (2PC) ensures multi-party transactions settle together or not at all.\nGovernance clarity. Super Validators (known organizations with protocol voting rights) run the network. For institutions that value knowing exactly who operates their infrastructure, this provides comfort.\nCanton may be the right answer if your use case is bilateral settlement between known counterparties within a closed, legally-aligned consortium, with deterministic finality requirements and tolerance for a non-standard talent pool.\nPublic blockchains have their own costs: gas, coordination overhead, and MEV exposure. For pure intra-consortium workflows, Canton’s trade-offs can make sense.\nBut the same structural constraints we saw in Gen 1 and Gen 2 persist. Canton demonstrates that these limits are inherent to the permissioned model, not specific to any implementation.\nWhere Permissioned Platforms Hit Limits\nDespite these achievements, Canton sits inside the same design space as Hyperledger and Corda. That space comes with constraints that matter more as the system grows.\nEcosystem isolation. Each Canton domain is a private silo. Domains cannot natively interact with Ethereum DeFi, public stablecoins, or the broader on-chain ecosystem. Any bridge requires a trusted intermediary, reintroducing the very counterparty risk that blockchains were designed to eliminate. In institutional terms, asset transferability is limited.\nWhile the Global Synchronizer enables cross-domain transactions, liquidity tends to fragment rather than compound across separate deployments.\nVendor lock-in. DAML does not run on public EVM chains. Migration away from Canton means a full rewrite, not a port. This creates switching costs at every level: tooling, talent, and institutional knowledge.\nThe talent gap is real: Ethereum has thousands of monthly active developers.2 DAML has roughly 200 contributors. One precedent is COBOL in banking, still critical but increasingly difficult to staff. Hiring DAML developers at scale, over a 10-year horizon, creates key-person risk that hiring for Solidity or Rust does not.\nGovernance concentration. The Canton Foundation is co-chaired by DTCC and Euroclear. Protocol changes require BFT voting with a 2/3 Super Validator majority. This is consortium governance, not decentralized governance. If a regulator pressures those entities, the network’s rules change. There is no fork option.\nThe 2PC risk. Canton uses asynchronous two-phase commit (2PC), a coordination protocol requiring all participants to respond, to settle across domains. If any participating domain is unavailable during the commit phase, the entire transaction rolls back. As you connect more domains, failure risk correlates rather than isolates. This creates systemic operational risk: correlated failures across participants, not isolated incidents. It also creates a scalability bottleneck for global settlement, much like traditional distributed systems.\nThe availability math. This behavior is derived from the topology.\nFor any cross-domain transaction, availability is the product of participating domains. At 99% uptime each: two domains yield 98%, five domains yield 95%. The principle scales: more counterparties, lower availability. In contrast, on a public chain, if Counterparty B is offline, the L1 is still up, and Counterparty A can still post their side of the trade. Failures are isolated, not correlated.\nOperational considerations. Canton’s major version migrations (2.x to 3.x) introduce breaking changes with no backwards compatibility. Budget accordingly if your production timeline spans releases.\n3. Trust-Based Privacy vs Cryptographic Privacy\nBefore comparing platforms, we should ask a more basic question: why are we using blockchains at all?\nBitcoin and Ethereum answered this clearly. They demonstrated that you can have a shared ledger where no single party controls the rules, no single party can censor transactions, and no single party can rewrite history. This is what we call resilience. The value proposition is removing trust in operators and replacing it with cryptographic and economic guarantees.\nPermissioned blockchains tried to capture blockchain benefits while preserving institutional control. But in doing so, they sacrificed resilience, the core value proposition. If you trust the consortium operators to run the network honestly, to respect your data boundaries, to not change the rules against your interests, you are back to trusting people. At that point, the question becomes: why not a database with legal contracts?\n\nTrust-based privacy says: “I promise I won’t look at your data.” Operators, validators, and governance commit to respect data boundaries. If incentives shift, if regulators demand access, if governance evolves, the promise breaks.\nCryptographic privacy says: “I mathematically cannot see your data.” Zero-knowledge proofs allow verification without disclosure. The guarantee is not a policy or a contract. It is the protocol.\nWhen trust-based privacy may suffice:\n\nClosed consortium, aligned incentives, single jurisdiction\nLower-stakes, short-duration, internal workflows\n\nWhen cryptographic becomes necessary:\n\nAdversarial or unknown counterparties\nHigh-stakes, long-duration commitments\nCross-border, multi-jurisdictional exposure\n\nMost institutional use cases, especially anything cross-border or long-duration, fall into the second category.\n4. Public Blockchains\nMultiple production systems now exist for cryptographic privacy on public infrastructure.\nEnterprise-grade (Canton-comparable): Prividium offers ZKsync validium architecture (off-chain data, on-chain proofs) with high throughput targets3, sub-second ZK finality, KYC/SSO built in. Deutsche Bank’s Project DAMA runs here. Selective disclosure enables compliance proofs without revealing underlying data, while L1 settlement preserves composability with the broader Ethereum ecosystem. Closest analog to Canton’s feature set, with cryptographic guarantees.\nProgrammable privacy: Aztec provides full privacy across transactions, state, and compute. Private smart contracts in Noir. Mainnet launched late 2025; enterprise-grade throughput still maturing.\nCompliance-first mechanisms: Privacy Pools (Vitalik co-authored) lets users prove funds are clean without revealing full history. Designed for the regulatory problem from day one. Live on mainnet.\nMature shielding: Railgun and similar ZK privacy pools have processed billions in shielded volume across Ethereum and L2s.\nOthers: Fhenix and Zama (FHE-based), Shutter Network (encrypted mempool), Renegade (dark pools), EY Nightfall and Miden (privacy rollups). For a comprehensive map of privacy solutions, see the IPTF Privacy Map.\nWhy this matters beyond features:\nResilience. Ethereum has operated without a complete outage since 2015, over a decade. AWS, Cloudflare, Facebook have all gone down in that period. This is the strongest argument for decentralized infrastructure.\nCensorship resistance. No single entity can block transaction inclusion. For cross-border operations where jurisdictional conflicts arise, this matters.\nEconomics. SaaS licensing vs gas costs. Utility pricing is transparent, predictable, and has no lock-in. SaaS licensing scales with vendor leverage, not your usage. Over a decade, this compounds.\nFinality. Canton’s deterministic finality4 is real. L2s are closing the gap with sub-second ZK finality. For most institutional workflows, the difference is immaterial. It matters for high-frequency trading or real-time settlement, but those are edge cases.\nRegulation. Public infrastructure ≠ unregulated activity. Regulators in Singapore, EU, and elsewhere increasingly engage with public chains directly.\n5. Due Diligence Checklist\nSeven questions that reveal architectural constraints:\n\n#QuestionWhat It Reveals1The Exit Test: If the vendor disappears, does the network state survive?Public: yes (state lives on L1). Permissioned: no.2Privacy Model: Is privacy enforced by policy or by mathematics?Trust-based privacy vs cryptographic: fundamentally different risk profiles.3Liquidity Access: Can assets move to DeFi and stablecoins without bespoke bridges?Ecosystem isolation vs composability.4Governance: Who holds the admin keys to change network rules?Consortium voting vs protocol-level governance.5Talent: Is your developer pool proprietary or global?DAML (~200 contributors) vs Solidity/Rust (thousands monthly active).6Portability: Can the stack move jurisdictions or platforms without a rewrite?Vendor lock-in vs open standards and modularity.7Finality: Is settlement deterministic or probabilistic?Canton advantage here. L2s closing gap.\nComparison Matrix\nHow the two approaches compare across key dimensions:\n\nDimensionCantonEthereum Privacy StackPrivacy modelTrust-based privacyCryptographicSmart contractsDAML (non-standard stack)Solidity/EVM (open)Developer ecosystem~200 contributorsThousands monthly activeSettlement finalityDeterministicL1 ~12 min; L2s ~1s soft finalityCross-domain atomicity2PC (all must respond)Shared L1 settlementComposabilityIsolated domainsDeFi interoperabilityGovernanceSuper Validators (consortium)Protocol-levelExit riskVendor-dependentSelf-sovereignTCO modelSaaSUtilityTrack recordCanton Network: ~2 years~10 years, no complete outages\n\nKey difference: Canton failures are correlated (one domain down stops the entire cross-domain transaction). Public L2 failures are isolated (L2 down doesn’t stop the L1 or other L2s).\n\nClosing\nIf you need the consortium to trust operators anyway, the blockchain adds complexity without delivering on its original promise: removing that trust requirement.\nFor institutions with genuine privacy requirements (adversarial counterparties, long-duration commitments, cross-border exposure, regulatory uncertainty), public blockchains with cryptographic privacy represent the architecture most aligned with what the technology was designed for.\nThe Ethereum privacy stack is live, battle-tested, and increasingly enterprise-ready. The seven questions above will tell you whether it fits your requirements.\nFor implementation patterns and institutional guidance, see the IPTF Privacy Map or contact the Institutional Privacy Task Force.\nReferences\n\nCanton Technical Primer\nGlobal Synchronizer Docs\nDAML GitHub\nZKsync Prividium\nPrivacy Pools Paper\nAztec Network\nRailgun\nMAS Project Guardian\nElectric Capital Developer Report\n\nFootnotes\n\nThis figure refers to “represented” RWA (traditional assets with blockchain-based records), not “distributed” RWA where the asset itself is natively on-chain. See rwa.xyz’s framework for the distinction. ↩\n\nSee Electric Capital Developer Report. ↩\n\nZKsync’s Atlas upgrade (October 2025) targets 10,000+ TPS. Actual throughput depends on transaction complexity and proving infrastructure. ↩\n\nFinality refers to when a transaction is irreversibly settled. Deterministic finality means immediate and absolute. ↩","tokens":3787,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261063128,"hash":"d4854d3682d5f79200412adb5badabe371058768"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/10","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 10 / 10\n\n Sep 20\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n post by stani on Jul 4\n\n post by MconnectDAO on Jul 5\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n post by defi_milos on Sep 9\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 14\n\n defi_milos\n\n You’re very welcome Zataoka! Also appreciate your kind words for the DFS app :)\nGood news that your positions are on a Smart Wallet.\nLoan Shifter shows up under the “Shift” tab only on Aave v3 currently, but we’ll make sure it’s also included on the v4 dashboard soon!\nInstead, you can find the Loan Shifter option from the menu on the left-hand side of the app - just under the “Exchange” tool.\nOnce you’ve opened it, if it’s not already pre-selected, please choose your Main v4 position in the “From position” section. Then, you’ll choose “Bluechip” in the “To position” section.\nImportant note: The position you shared has multiple collateral and debt assets, so I would mention that Loan Shifter won’t be able to move it all in one transaction.\nInstead, it’ll require a couple. The best option I found is:\n\nTransaction 1: Move all of your WBTC and your USDT debt to the Bluechip market first. This is the best course of action since WBTC makes up most of your position, so it’ll let you move all of the USDT in one transaction. For example if you try to move your wstETH and USDT, there won’t be enough wstETH collateral to support moving all of the 300k+ USDT. By moving WBTC and USDT first, you’re taking care of that in one-tx\nTransaction 2: Move all of your wstETH and your USDC debt to the Bluechip market. Even though it’s two separate Loan Shifter transactions, it’ll actually add the wstETH collateral and USDC debt on top of your newly moved WBTC/USDT Bluechip position\nTransaction 3: Since all of your debt has moved to the Bluechip market now, you can simply withdraw your remaining LINK and ETH collateral, then supply it to the position again on Bluechip\n\nLet me know if this is clear enough. You can also contact me by writing directly through the DFS app, where I’d be more than happy to provide a step-by-step guide with screenshots on how to get the process done.\nP.S. - You can also do the entire move in our Simulation Mode first - confirm that everything works (and that you’re comfortable with the flow), and only then re-do it on the live mode.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Thanks Milos.. I was able to do the switch and it all went smoothly. Appreciate it.\nLet me ask you a couple of questions, if I may\n\nWhy is there such a huge difference in borrowing costs between USDT on the Core vs. Prime hub? I moved my debt to USDT on the core hub and the interest rate there is 10.6% vs. 4.05% (core vs. prime).\nBecause of the above, I am trying to do the debt switcher to Prime (from Core) but it doesn’t let me do that.\nI have retained some portion of the debt with all my LINK as collateral on V4 Main.. hope that is fine? Or should I be removing that you think, given LINK isn’t a collateral asset on Bluechip.\n\n post by defi_milos on Sep 21\n\n defi_milos\n\n You’re welcome Zataoka! Apologies for the slightly delayed reply here.\nLet me address the questions one by one:\n\nIt might have been due to a higher utilization rate on Core that caused the borrow APY spike. I can see now that both are pretty much at an equal ~4%\n\nWould love to learn a bit more about Debt Switch “not letting you do it”. Is there some kind of error that pops up, is the button to switch just greyed out?\n\nIs your LINK leveraged on v4 or is it just sitting there? From what I can see, you’re not going to be earning any supply APY on that LINK, so you’re technically just paying the borrowing costs on that LINK + USDC (I suppose) v4 Main position.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 398\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":1081,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261070941,"hash":"9c8abeea72952465367a6e625af6566160fced85"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/public-chains","domain":"docs.arbitrum.io","title":"Arbitrum chains overview | Arbitrum Docs","text":"✏️Request an updateArbitrum chains are Child chain solutions built on top of the Ethereum Blockchain, designed to increase scalability and reduce Transaction costs. In this conceptual overview, we’ll learn about the different Arbitrum Chains and how they relate to each other. We’ll describe the available Arbitrum production and testnet chains, their differences, and the technology stacks that these chains use.\nWhat Arbitrum production chains are available?​\nArbitrum One​\nArbitrum One is a child chain Optimistic Rollup that implements the Arbitrum Rollup Protocol and settles to Ethereum's parent chain. It lets you build high-performance Ethereum dApps with low transaction costs and Ethereum-grade security guarantees, introducing no additional trust assumptions. This is made possible by the Nitro technology stack, a \"Geth-at-the-core\" architecture that gives Arbitrum One (and Nova) advanced calldata compression, separate contexts for common execution and fault proving, Ethereum parent chain gas compatibility, and more.\nArbitrum Nova​\nArbitrum Nova is a high-performance alternative to Arbitrum One's chain. While Arbitrum One implements the purely Trustless Rollup protocol, Arbitrum Nova implements the mostly trustless AnyTrust protocol. The key difference between Rollup and AnyTrust is that the AnyTrust protocol introduces an additional trust assumption in the form of a Data Availability Committee (DAC). This committee (detailed below) is responsible for expediting the process of storing, batching, and posting child chain transaction data to Ethereum's parent chain. This lets you use Arbitrum in scenarios that demand performance and affordability, while Arbitrum One is optimal for scenarios that demand Ethereum's pure trustlessness.\nWhat Arbitrum testnet chains are available?​\nArbitrum Sepolia​\nArbitrum Sepolia serves as a testnet chain replicating the capabilities of Arbitrum One's main network. Linked to the Sepolia testnet, it offers developers a secure platform to experiment with and evaluate their smart contracts prior to actual deployment on the mainnet. To deploy your first contract to Arbitrum Sepolia, see the Solidity quickstart.\nArbitrum Goerli​\nArbitrum Goerli was a testnet chain that mirrored the functionality of the Arbitrum One mainnet and was connected to the Ethereum Goerli testnet. It was deprecated on November 18th 2023, and deactivated on March 18th, 2024.\ncautionThe old testnet RinkArby was deprecated on December 20th, 2022.\nStylus testnet (deprecated)​\nStylus is now available on Arbitrum One and Arbitrum Sepolia. The standalone Stylus testnet was deprecated as of June 17, 2024. For information about developing with Stylus, see the Stylus documentation.\nWhat are the differences between the available Arbitrum chains?​\nThe main differences between the Arbitrum chains lie in their purpose and the environment they operate in.\nArbitrum One and Arbitrum Nova are production chains designed for real-world use. They're connected to the Ethereum mainnet and handle real, valuable transactions. They both use Arbitrum's Nitro technology stack under the hood, but Arbitrum One implements the Rollup protocol, while Nova implements the AnyTrust protocol. Arbitrum One is designed for general use, providing a scalable and cost-effective solution for running Ethereum-compatible smart contracts. On the other hand, Arbitrum Nova is designed for applications that require a higher transaction throughput and don’t require the full decentralization that rollups provide.\nFinally, Arbitrum Sepolia is a testnet chain. It's designed for testing purposes and is connected to the Sepolia testnet, which uses test Ether with no real-world value.\nWhat technology stacks use the Arbitrum chains?​\nNitro​\nNitro is the technology that powers Arbitrum One, Arbitrum Nova (with AnyTrust configuration), and Arbitrum Sepolia. It's designed to offer high throughput and low cost, making it ideal for building blockchain applications. Nitro is a major upgrade to the “Classic” stack, offering several improvements including advanced calldata compression, separate contexts for common execution and fault proving, Ethereum parent chain gas compatibility, and more. You can find more information about Nitro in How Arbitrum works.\nAnyTrust (variant of Nitro)​\nAnyTrust is a variant of the Nitro technology stack that lowers costs by accepting a mild trust assumption. The AnyTrust protocol relies on an external Data Availability Committee (DAC) to store data and provide it on demand. The DAC has N members, of which AnyTrust assumes at least two are honest. Keeping the data offchain in the happy/common case means the system can charge the user significantly lower fees. You can find more information about AnyTrust in Anytrust protocol.\nClassic (deprecated)​\nThe Classic technology stack is the original version of Arbitrum. It has been deprecated and replaced by the Nitro technology stack.\nConclusion​\nUnderstanding the different Arbitrum chains and their technology stacks is crucial for developers working on blockchain and Web3 applications. Each chain offers a unique set of features and benefits, making them suitable for different use cases. By choosing the right chain and technology stack, developers can ensure their applications are secure, scalable, and cost-effective.What Arbitrum production chains are available?Arbitrum OneArbitrum NovaWhat Arbitrum testnet chains are available?Arbitrum SepoliaArbitrum GoerliStylus testnet (deprecated)What are the differences between the available Arbitrum chains?What technology stacks use the Arbitrum chains?NitroAnyTrust (variant of Nitro)Classic (deprecated)Conclusion","tokens":1417,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261074560,"hash":"0825f836732df52955b827be10368e56aa1bc31f"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/55","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 50 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261074641,"hash":"9b9b60457d229a2288a4f592055f5c3fa69b77fe"}
{"url":"https://governance.aave.com/t/aave-v4-safe-to-move-my-positions/24711/2","domain":"governance.aave.com","title":"Aave v4 - Safe to move my positions? - Governance / New Market - Aave","text":"GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 23\n\n 2 / 2\n\n Apr 23\n\n Apr 23\n\n post by Zataoka on Apr 23\n\n Zataoka\n\n Hello, I have sizable positions (about 1.5M) - on Aave v3 - I am looking to move them on to Aave v4 but am wondering about the TVL being so low. Only $20m for the main vault and $6.6m for Bluechip. When will these be scaled up further? For eg., on bluechip, there is a supply cap of only 30 WBTC and I will be looking to bring in about 6-7 WBTC.\nIs it safe to move now to v4? I would like to given the spoke model and the fact that it is cleaner, easier to liquidity pool etc., Be grateful for any advice. Thanks.\n\n post by EzR3aL on Apr 23\n\n EzR3aL\n\n Regular\n\n Hi,\nAs far as I understood caps are raised slowly and I assume given the current situation focus is a bit less on it.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Migrate from V4 Main vault to Bluechip\n\n General\n\n 9\n\n 411\n\n Sep 21\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.15\n\n Risk\n\n 0\n\n 105\n\n Sep 15","tokens":332,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261081004,"hash":"dfe49ce572c1099d184c5abc458b879dda83a2d4"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/reference/geth","domain":"docs.arbitrum.io","title":"Geth at the core: modified Geth on Arbitrum Nitro | Arbitrum Docs","text":"✏️Request an updateArbitrum Nitro makes minimal modifications to Geth to avoid violating its assumptions. This section will explore the relationship between Geth and ArbOS, which consists of a series of hooks, interface implementations, and strategic re-appropriations of Geth’s basic types.\nWe store ArbOS's state at an address within a Geth statedb (state database). In doing so, ArbOS inherits the statedb's statefulness and lifetime properties. For example, a transaction's direct state changes to ArbOS would get discarded upon a revert.\n0xA4B05FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF is a fictional account representing ArbOS.\ninfoAny links on this page may point to older versions of Nitro or our fork of Geth. While we try to keep this up to date, most of this should be stable. Check the latest releases of Nitro and Geth for the most recent changes.\nHooks​\nArbitrum uses various hooks to modify Geth’s behavior during transaction processing. Each provides an opportunity for ArbOS to update its state and make decisions about the transaction during its lifetime. Transactions are applied using Geth's ApplyTransaction function.\nBelow is ApplyTransaction's callgraph, with additional info on where the various Arbitrum-specific hooks are. Click any to jump to their section. By default, these hooks do nothing to leave Geth's default behavior unchanged, but for chains configured with EnableArbOS set to true, ReadyEVMForL2 installs the alternative child chain hooks.\n\ncore.ApplyTransaction -> core.applyTransaction -> core.ApplyMessage\n\ncore.NewStateTransition\n\nReadyEVMForL2\n\ncore.TransitionDb\n\nStartTxHook\ncore.transitionDbImpl\n\nif IsArbitrum() remove tip\nGasChargingHook\nevm.Call\n\ncore.vm.EVMInterpreter.Run\n\nPushCaller\nPopCaller\n\ncore.StateTransition.refundGas\n\nForceRefundGas\nNonrefundableGas\n\nEndTxHook\n\nadded return parameter: transactionResult\n\nWhat follows is an overview of each hook in chronological order.\nReadyEVMForL2​\nA call to ReadyEVMForL2 installs the other transaction-specific hooks into each Geth EVM right before it performs a state transition. Without this call, the state transition will instead use the default DefaultTxProcessor and get the same results as vanilla Geth. A TxProcessor object carries these hooks and the associated Arbitrum-specific state during the transaction's lifetime.\nStartTxHook​\nGeth calls the StartTxHook before a transaction executes, which allows ArbOS to handle two Arbitrum-specific transaction types.\nIf the transaction is ArbitrumDepositTx, ArbOS adds balance to the destination account. This approach is safe because the parent chain bridge submits such a transaction only after collecting the same amount of funds on the parent chain.\nIf the transaction is an ArbitrumSubmitRetryableTx, ArbOS creates a retryable based on the transaction's fields. ArbOS schedules a retry of the new retryable if the transaction includes sufficient gas.\nThe hook returns true for both transaction types, signifying that the state transition is complete.\nGasChargingHook​\nThis fallible hook ensures the user has enough funds to pay their poster’s parent chain calldata costs. If not, the transaction is reverted, and the EVM does not start. In the common case where the user can pay, the amount paid for calldata is set aside for later reimbursement to the poster. All other fees go to the network account, as they represent the transaction’s burden on validators and nodes more generally.\nSuppose the user attempts to purchase compute gas over ArbOS's per-block gas limit. In that case, the difference is set aside and refunded later via ForceRefundGas, so only the gas limit is used. Note that the limit observed may not be the same as that seen at the start of the block if ArbOS's larger gas pool falls below the MaxPerBlockGasLimit while processing the block's previous transactions.\nPushCaller​\nThese hooks track callers on the EVM call stack, pushing and popping as calls are made and completed. This hook provides ArbSys with info about the call stack, which is used to implement the methods WasMyCallersAddressAliased and MyCallersAddressWithoutAliasing.\nL1BlockHash​\nIn Arbitrum, the BlockHash and Number operations return data that relies on the underlying parent chain blocks rather than child chain blocks to accommodate the normal use case of these opcodes, which often assume Ethereum-like time passing between blocks. The L1BlockHash and L1BlockNumber hooks have the required data for these operations.\nForceRefundGas​\nThis hook allows ArbOS to add additional refunds to the user's transaction. The only usage of this hook is to refund any compute gas purchased in excess of ArbOS's per-block gas limit during the GasChargingHook.\nNonRefundableGas​\nBecause poster costs are borne by the parent chain aggregators, not the network, payments toward parent chain calldata should not be refunded. This hook provides Geth access to the equivalent amount of child chain gas that the poster's cost equals, ensuring that this amount isn't reimbursed for network-incentivized behaviors like freeing storage slots.\nEndTxHook​\nThe EndTxHook is called after the EVM returns a transaction's result, providing one last opportunity for ArbOS to intervene before state transition finalization. Final gas amounts are known, enabling ArbOS to credit the network and poster share of the user's gas expenditures and adjust the pools. The hook returns from the TxProcessor for the final time, discarding its state as the system moves on to the next transaction, where its contents will be renewed.\nRevertedTxHook​\nThe RevertedTxHook is called during Nitro's state transition. It checks whether the transaction has been previously reverted or is part of the transaction filter. If either is true, it will not execute the transaction and will use up a predetermined amount of gas. If it was a previously reverted transaction, the sender's nonce will be increased.\nInterfaces and components​\nAPIBackend​\nAPIBackend implements the ethapi.Backend interface, which allows a simple integration of the Arbitrum chain to the existing Geth API. The Backend member answers most calls.\nBackend​\nThis struct is an Arbitrum equivalent to the Ethereum struct. It is mostly glue logic, including a pointer to the ArbInterface interface.\nArbInterface​\nThis interface serves as the primary interface between the geth-standard APIs and the Arbitrum chain. Geth APIs either check the status by working on the Blockchain struct retrieved from the Blockchain call or send transactions to Arbitrum using the PublishTransactions call.\nRecordingKV​\nRecordingKV is a read-only key-value store that retrieves values from an internal trie database. All values accessed by a RecordingKV get recorded internally. This value records all preimages accessed during block creation, which will be needed to prove the execution of this particular block. A RecordingChainContext should also be used to record which block headers the block execution reads (another option is always to assume that the last 256 block headers have been accessed). The process is simplified using two functions: PrepareRecording creates a stateDB and chain context objects, running block creation process using these objects records the required preimages, and PreimagesFromRecording function extracts the preimages recorded.\nTransaction types​\nNitro Geth includes a few child chain-specific transaction types. Click any to jump to their section.\nTransaction TypeRepresentsLast Hook ReachedSourceArbitrumUnsignedTxA parent chain to child chain messageEndTxHookBridgeArbitrumContractTxA nonce-less parent chain to child chain messageEndTxHookBridgeArbitrumDepositTxA user depositStartTxHookBridgeArbitrumSubmitRetryableTxCreating a retryableStartTxHookBridgeArbitrumRetryTxA retryable redeem attemptEndTxHookChild chainArbitrumInternalTxArbOS state updateStartTxHookArbOS\nThe following reference documents each type.\nArbitrumUnsignedTx​\nIt provides a mechanism for a user on a parent chain to message a contract on a child chain. This mechanism uses the bridge for authentication rather than requiring the user's signature. Address remapping of the user's address will occur on the child chain to distinguish them from a normal child chain caller.\nArbitrumContractTx​\nThese are like ArbitrumUnsignedTx's but intended for smart contracts. These use the bridge's unique, sequential nonce rather than requiring the caller to specify their own. A parent chain contract may still use an ArbitrumUnsignedTx, but doing so may necessitate tracking the nonce in the parent chain state.\nArbitrumDepositTx​\nIt represents a user deposit from a parent chain to a child chain. This representation increases the user's balance by the amount deposited on the parent chain.\nArbitrumSubmitRetryableTx​\nIt represents a retryable submission and may schedule an ArbitrumRetryTx if enough gas is available. For more info, see the retryables documentation.\nArbitrumRetryTx​\nThese calls are scheduled using the redeem method of the ArbRetryableTx precompile and via retryable auto-redemption. For more info, see the retryables documentation.\nArbitrumInternalTx​\nBecause tracing support requires state changes to occur within a transaction, ArbOS may create a transaction of this type to update its state between user-generated transactions. Such a transaction has a Type indicating the state it will update, though currently this is just future-proofing, as there's only one value it may have. Below are the internal transaction types.\nInternalTxStartBlock​\nIt updates the parent chain block number and the parent chain base fee. This transaction is generated whenever a new block gets created. They are guaranteed to be the first in their child block chain.\nTransaction run modes and underlying transactions​\nA Geth message may get processed for various purposes. For example, a message may estimate the gas of a contract call, whereas another may perform the corresponding state transition. Nitro Geth denotes the intent behind a message using TxRunMode, which it sets before processing the message. ArbOS uses this info to decide the transaction that the message ultimately constructs.\nA message derived from a transaction will carry that transaction in a field accessible via its UnderlyingTransaction method. While this relates to how a given message is used, they are not one-to-one. The table below shows the various run modes and whether each could have an underlying transaction.\nRun ModeScopeCarries an Underlying Transaction?MessageCommitModestate transitionAlwaysMessageGasEstimationModegas estimationWhen created via NodeInterface or when scheduledMessageEthcallModeeth_callsNever\nArbitrum chain parameters​\nNitro's Geth is configurable with the following child chain-specific chain parameters. These allow the rollup creator to customize their rollup at genesis.\nEnableArbos​\nIntroduces ArbOS, converting what would otherwise be a vanilla parent chain into a child chain Arbitrum rollup.\nAllowDebugPrecompiles​\nAllows access to debug precompiles. Not enabled for Arbitrum One. When false, calls to debut precompiles will always revert.\nDataAvailabilityCommittee​\nCurrently, it does nothing besides indicate that the rollup will access a data availability service for preimage resolution in the future. On Arbitrum One, this indication isn't present, which is a strict state function of its parent chain inbox messages.\nMiscellaneous Geth changes​\nABI Gas Margin​\nVanilla Geth's ABI library submits transactions with the exact estimate the node returns, employing no padding. This process means a transaction may revert if another arrives just before it, even if it changes the transaction's code path by just a little. To account for this, we've added a GasMargin field to bind.TransactOpts that pads estimates by the number of basis points set.\nConservation of child chain ETH​\nThe total amount of the child chain ether in the system should not change except in controlled cases, such as when bridging. As a safety precaution, ArbOS checks Geth's balance delta each time a block is created, alerting or panicking if conservation is violated.\nMixDigest and ExtraData​\nThe root hash and leaf count of ArbOS's send Merkle accumulator are stored in each child chain block's MixDigest and ExtraData fields to aid with outbox proof construction. The yellow paper specifies that the ExtraData field may be no larger than 32 bytes, so we use the first 8 bytes of the MixDigest, which has no meaning in a system without miners/bonders, to store the send count.\nRetryable support​\nArbOS primarily implements retryables, while Geth requires some modifications to support them.\n\nAdded ScheduledTxes field to ExecutionResult. This process lists transactions scheduled during the execution. To enable this field, we also pass the ExecutionResult to callers of ApplyTransaction.\nAdded gasEstimation param to DoCall. When enabled, DoCall will also execute any retryables activated by the original call, allowing gas to be estimated for retryables.\n\nAdded accessors​\nWe added UnderlyingTransaction to the Message interface, and GetCurrentTxLogs to StateDB.\nWe created the AdvancedPrecompile interface, which executes and charges gas with the same function call. Arbitrum precompiles use this interface, and it wraps Geth's standard precompiles.\nWASM build support​\nThe WASM executable for Arbitrum does not support file operations. We created fileutil.go to wrap fileutil calls and stub them out during WASM builds. fake_leveldb.go is a similar WASM mock for leveldb. The WASM block-replayer does not require these.\nTypes​\nArbitrum introduces a new signer and multiple new transaction types.\nReorgToOldBlock​\nGeth natively only allows reorgs to a fork of the currently known network. In Nitro, sometimes reorgs can be detected before the forked block is computed. We added the ReorgToOldBlock function to support re-orging to a block that's an ancestor of the current head.\nGenesis block creation​\nThe genesis block in Nitro is not necessarily block #0. Nitro supports importing blocks that take place before genesis. We split out WriteHeadBlock from genesis. Commit and use it to commit non-zero genesis blocks.HooksReadyEVMForL2StartTxHookGasChargingHookPushCallerL1BlockHashForceRefundGasNonRefundableGasEndTxHookRevertedTxHookInterfaces and componentsAPIBackendBackendArbInterfaceRecordingKVTransaction typesArbitrumUnsignedTxArbitrumContractTxArbitrumDepositTxArbitrumSubmitRetryableTxArbitrumRetryTxArbitrumInternalTxInternalTxStartBlockTransaction run modes and underlying transactionsArbitrum chain parametersEnableArbosAllowDebugPrecompilesDataAvailabilityCommitteeMiscellaneous Geth changesABI Gas MarginConservation of child chain ETHMixDigest and ExtraDataRetryable supportAdded accessorsWASM build supportTypesReorgToOldBlockGenesis block creation","tokens":3704,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261084611,"hash":"b8d2ca71c71bc4bcac1f535378431f6015a4d9ac"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/57","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 52 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261084924,"hash":"c813d25a925c40965575812b213f9703440f5a47"}
{"url":"https://governance.aave.com/c/governance/new-market/10","domain":"governance.aave.com","title":"Latest Governance/New Market topics - Aave","text":"Latest topics in New Market\n\n Governance\n\n New Market\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n 5\n\n 765\n\n 8h\n\n [ARFC] Deploy Aave V4 on the Monad Network\n\n 3\n\n 389\n\n 12h\n\n [ARFC] Deploy Aave V4 on Arc\n\n 9\n\n 911\n\n Sep 18\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n 7\n\n 1.0k\n\n Aug 28\n\n [Temp Check] Deploy Aave V4 on Tempo\n\n 3\n\n 393\n\n Jul 24\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n 7\n\n 1.0k\n\n Jul 11\n\n [Temp Check] Deploy Aave V4 on Arc\n\n 5\n\n 836\n\n Jun 7\n\n Aave v4 - Safe to move my positions?\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Add support for Rocket Pool Staked ETH (rETH) on AAVE V4\n\n 1\n\n 351\n\n Apr 21\n\n [ARFC] Deploy Aave V3 to MegaETH\n\n 47\n\n 4.7k\n\n Feb 26\n\n [TEMP CHECK] Launch the AAVE protocol on the Sui Blockchain\n\n 2\n\n 575\n\n Jun 2025\n\n [TEMP CHECK] Launch the AAVE protocol on the Solana Blockchain\n\n 1\n\n 469\n\n May 2025\n\n [TEMP CHECK] Deploy Aave v3 on Tron\n\n 7\n\n 641\n\n Apr 2025\n\n [ARFC] Aave Deployment on Celo\n\n 25\n\n 2.7k\n\n Mar 2025\n\n Deploy Aave on Cronos zkEVM Chain\n\n 1\n\n 231\n\n Feb 2025\n\n [ARFC] Deployment of Aave on Linea\n\n 8\n\n 1.3k\n\n Feb 2025\n\n [TEMP CHECK] Deploy Aave v3 on Sonic\n\n 25\n\n 3.3k\n\n Jan 2025\n\n [TEMP CHECK] Aave V3 Deployment on Aptos Mainnet\n\n 16\n\n 5.5k\n\n Jan 2025\n\n [ARFC] Deploy a Gnosis DAO Credit Line Aave v3 Instance\n\n 6\n\n 1.1k\n\n Oct 2024\n\n [ARFC] Deploy a Crypto.com Aave v3 Instance\n\n 5\n\n 577\n\n Oct 2024\n\n [TEMP CHECK] Deploy Aave V3 on Mode\n\n 5\n\n 1.1k\n\n Jun 2024\n\n Deploy AAVE v3 to Polygon Amoy\n\n 2\n\n 504\n\n May 2024\n\n [TEMP CHECK] Aave V3 deployment on Fraxtal Mainnet\n\n 14\n\n 1.7k\n\n Mar 2024\n\n [ARC] Launch Aave v3 on Celo\n\n 20\n\n 7.2k\n\n Feb 2024\n\n [ARC] Deploy Aave V3 on Cronos chain\n\n 6\n\n 4.0k\n\n Feb 2024\n\n [Temp Check] Add GHO to Cosmos and Polkadot through IBC\n\n 6\n\n 1.7k\n\n Jan 2024\n\n Launch Aave V3 on Starknet\n\n 3\n\n 6.6k\n\n Dec 2023\n\n [TEMP CHECK] Add Atom as Collateral on AAVE through IBC\n\n 5\n\n 1.7k\n\n Nov 2023\n\n Deploy Aave v3 on Scroll testnet\n\n 6\n\n 5.3k\n\n Nov 2023\n\n Aave Deployment on Avalanche + Asset Validation List\n\n 30\n\n 24.5k\n\n Sep 2023","tokens":526,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261091090,"hash":"6826c0884322176881d6538cd20225f8ad478a5e"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/reference/finality-and-reorgs","domain":"docs.arbitrum.io","title":"Finality and chain reorganizations | Arbitrum Docs","text":"✏️Request an updateThis reference explains how finality works on Arbitrum chains, why and when a chain can reorganize (reorg), how deep a reorg can go, and which confirmation level an indexer should wait for before treating data as irreversible.\nThis is intended for developers building indexers, block explorers, bridges, and custodial integrations, and it applies to Arbitrum One, Nova, and Dedicated Blockchains (Arbitrum chains)—including AnyTrust chains that settle to another Arbitrum chain.\nFor a step-by-step deposit and withdrawal detection procedure, see the Exchange integration checklist. This page provides the finality and reorg model that the checklist builds on.\nThe three confirmation levels​\nAn Arbitrum node exposes three levels of confirmation, surfaced as the standard Ethereum JSON-RPC block tags. Each maps to a different point in the transaction lifecycle and carries a different reversibility guarantee.\nLevelBlock tagWhat it meansCan it be reverted?Soft confirmationlatestThe Sequencer has ordered and executed the transaction and emitted it on the Sequencer feed.Yes—this is a promise from the Sequencer, not yet backed by the parent chain.Parent-chain safesafeThe batch containing the block has been posted to the parent chain and reached the parent chain's safe block.Only by a deep parent-chain reorg.Parent-chain finalfinalizedThe batch containing the block has been posted to the parent chain and reached the parent chain's finalized block.Only if the parent chain itself reverts a finalized block (on Ethereum, economically infeasible).\nThe load-bearing ruleAn Arbitrum block is only as final as the parent-chain block that carries its batch. Soft confirmation is fast (sub-second) but reversible. Hard finality—the safe and finalized tags—is inherited from the parent chain and is what makes a block reorg-proof.\nThe Fast Feed is not a fourth level​\nOn Arbitrum One, the Fast Feed publishes all transaction within the PGA round, as soon as they are ordered and executed, and before the block closes. That is earlier than latest, so it is tempting to treat it as the first confirmation level. Do not index against it.\nA Fast Feed message carries weaker guarantees than a soft confirmation:\nPropertyFast Feed messageSoft confirmation (latest)Block numberTentative, not guaranteed to be finalFinal for the block as sequencedBlock hashAbsent—the block is not built yetPresentInclusionNot guaranteed; a Sequencer failure mid-block discards what it already publishedThe block exists and is storedReplayNone. You receive only messages sent after you subscribe.Available from a node or relay\nTreat the Fast Feed as an early signal for latency-sensitive logic, and confirm every record against a node or the standard Sequencer feed. The three levels in the table above are the only ones your index should write against.\nWhat \"seconds to finality\" really means​\nOn an AnyTrust chain it is common to assume finality is achieved in seconds, as soon as the Data Availability Committee (DAC) signs the block's data. That describes soft confirmation and data availability, not hard finality:\n\nThe Sequencer executes and broadcasts the queued transactions immediately—this is your sub-second soft confirmation.\nThe DAC signing a Data Availability Certificate (DACert) guarantees the data is retrievable, so the batch can be posted compactly. It does not settle the block against the parent chain.\nHard finality still requires the batch (or DACert) to be posted to the parent chain's Sequencer Inbox and for that parent-chain block to finalize.\n\nSo on your chain, \"seconds\" is the soft-confirmation latency; the reorg-proof guarantee tracks your parent chain's finality, which in turn tracks Ethereum finality.\nHow the node derives safe and finalized​\nA Nitro node is split into a consensus side (reads the parent chain) and an execution side (runs the EVM and serves RPC). Finality flows from the parent chain into the child chain's safe/finalized heads:\n\nThe node reads the parent chain's own safe and finalized blocks over RPC. It does not compute parent-chain finality itself—it defers to the parent chain's block tags. (Finality data is only used when the parent chain serves those tags—for example Ethereum proof-of-stake, another Arbitrum chain, or a chain built on another stack that exposes them—and when the node is configured to read them, via node.parent-chain-reader.use-finality-data, which defaults to true.)\nFor each parent-chain safe/finalized block, the node finds the newest sequencer batch that was posted at or before that parent-chain block.\nThe last child-chain block in that batch becomes the child chain's safe (or finalized) head, which is what the child-chain RPC serves for those tags.\n\nIn other words, a child-chain block is finalized when the parent-chain block that carries its batch is itself finalized. Optionally, a chain can be configured to further hold safe/finalized back until a local validator has validated the block.\nBlock-tag availability on Dedicated BlockchainsThe safe and finalized tags are always available on Arbitrum One and Nova. On a self-managed chain, they are available only when your parent chain exposes finality data and your node is configured to track it. Confirm the behavior on your own chain before relying on finalized, and document the expected confirmation latency for your integrators.\nPer-chain-type guarantees​\nThe confirmation model is identical across chains; what differs is which parent chain finality is inherited from, and therefore the latency.\nChain typeParent chainfinalized inherits fromApproximate hard-finality latencyArbitrum One / NovaEthereumEthereum finalized (~2 epochs, ~13 min)Time to post the batch, plus Ethereum finality.Arbitrum chain atop Ethereum (L2)EthereumEthereum finalizedSame as above.Arbitrum chain atop an L2 (L3, e.g. on Base)The L2 (e.g. Base)The L2's finalized, which itself tracks EthereumThe L2's finality latency, which is bounded below by Ethereum finality.\nFor an L3 on Base, finalized on your chain cannot be more final than Base's finalized, and Base's finalized ultimately tracks Ethereum. The DAC does not shorten this—it only affects how data is made available, not how the parent chain finalizes.\nParent chains outside the Ethereum and Arbitrum stacks​\nA few chains settle to a parent chain that is neither Ethereum nor an Arbitrum chain; in practice this means an OP Stack chain such as Base. The confirmation model is unchanged—your node still defers to the parent chain's safe and finalized tags—but the meaning of those tags is defined by that chain's stack rather than by Ethereum consensus. On an OP Stack parent chain, safe means the block has been derived from batch data already posted to Ethereum, and finalized means that Ethereum data is itself finalized, so the chain of inheritance still terminates at Ethereum finality.\nBefore relying on finalized when your parent chain runs a different stack, confirm two things: that its RPC actually serves both tags, and what each tag guarantees on that chain. A parent chain that returns its own head for safe and finalized gives your child chain no guarantee beyond latest, in which case you should derive your own finality signal as described in Recommended confirmation levels for indexers.\nAnyTrust and the DAC: what changes and what doesn't​\nOn an AnyTrust chain the batch poster asks the DAC to sign a DACert over the batch data. If enough committee members sign against the current keyset, the batch poster posts the compact DACert to the Sequencer Inbox instead of the full data. What this does and does not affect:\n\nDoes not change the finality model. Finality still tracks the parent chain. A DACert reaching parent-chain finality is what makes the block final; the DAC signature by itself is a data-availability guarantee.\nDoes not change reorg behavior. A DACert is posted to the Sequencer Inbox exactly like a full-data batch, so the reorg rules below apply unchanged.\nAffects liveness under DAC failure. If the batch poster cannot collect enough signatures within a few minutes, it falls back to posting the full batch data directly to the parent chain as calldata, and the chain keeps producing and finalizing blocks. Fallback can be disabled (disable-dap-fallback-store-data-on-chain: true), in which case a DAC outage halts batch posting. See DAC and DAS operations for the full failure-mode table.\n\nThe reorg model​\nOnce a batch is posted to the Sequencer Inbox, the only thing that can reorganize an Arbitrum chain is a reorg of its underlying (parent) chain. Fraud proofs and dispute resolution never cause a reorg—a rejected assertion only prevents an invalid state from being confirmed for settlement; it never rewrites already-sequenced blocks.\nWhen a parent-chain reorg does change the Sequencer Inbox or delayed inbox ordering, the child chain reorgs as follows:\n\nThe node detects that the parent-chain-derived data has changed (the delayed-message accumulator or the sequencer-batch accumulator no longer matches what it stored).\nIt walks back to the most recent block that still matches the canonical parent-chain-derived history—the common ancestor.\nIt rolls the chain back to that block. State reverts to the state root at the common ancestor, and every transaction after that point is discarded. Block explorers and RPC no longer return the discarded transactions.\nIt re-derives the chain forward from the parent chain. Messages that were reorged out (within the re-sequencing window) may be re-sequenced, but block hashes, block numbers, and transaction ordering after the common ancestor can all differ from before.\n\nNever key an index on block number alone across a reorgAfter a reorg, the same block number can hold different transactions with a different block hash. Always store and compare block hashes and parentHash continuity, and rewind to the common ancestor rather than patching individual records. See Reorg detection patterns.\nHow deep can a reorg go?​\nChild-chain reorg depth is bounded by parent-chain reorg depth, not by anything on the child chain and not by how often you post assertions.\nA common misconception is to reason from the assertion (state-root) cadence: \"we post state roots every hour, which at 250 ms blocks is ~14,400 blocks, so a reorg could be 14,400 blocks deep.\" That conflates two independent things:\n\nAssertions / state roots are periodic settlement checkpoints posted to the Rollup contract for the dispute protocol. They do not cause or bound reorgs, and their cadence is irrelevant to reorg depth.\nBatches (data) are posted continuously by the batch poster—not on the assertion cadence. Reorgs are driven by parent-chain reorgs of these batches, and only for the batches that are not yet final on the parent chain.\n\nSo the practical bound on a child-chain reorg is: the child blocks whose batches were posted within the parent chain's unfinalized window. For an indexer, this collapses to a simple rule:\n\nIf you index at finalized, you will never observe a reorg, because finalized parent-chain blocks do not revert.\nIf you index at safe, you are exposed only to a deep parent-chain reorg (rare on Ethereum-backed chains).\nIf you index at latest (soft), you are exposed to the full unfinalized window and must handle reorgs actively.\n\nA 14,400-block child reorg would require the parent chain to reorg its entire corresponding unfinalized range at once—which for a Base → Ethereum-backed chain does not happen under normal finality assumptions. The correct defense is not to guess a maximum depth but to gate crediting on finalized (or to rewind to the common ancestor for anything you display before finality).\nArbitrumInternalTx behavior under a parent-chain reorg​\nEvery child-chain block begins with a system transaction of type ArbitrumInternalTx (0x6A), specifically an InternalTxStartBlock. It is guaranteed to be the first transaction in its block, and it records the parent-chain block number and parent-chain base fee that were in effect when the block's message was read. This is the mechanism that feeds parent-chain context (for example, the value returned by block.number and BLOCKHASH) into the EVM. See Geth at the core for details.\nBecause this transaction's contents are derived from the parent chain, a parent-chain reorg that changes a block's parent-chain context also changes that block's InternalTxStartBlock. There is no special handling that keeps it stable across a reorg—the affected blocks are reorged out and re-derived through the normal path above.\nConsequences for an indexer:\n\nThe ArbitrumInternalTx is ArbOS bookkeeping. It never moves user value and must never be credited or treated as a user transaction.\nDo not assume the ordering, block number, or block hash of the surrounding transactions is preserved across a reorg. After the common ancestor, everything is recomputed: the internal tx stays first, but the transactions after it, their block assignment, and the block hashes can all change.\nThe only stable anchor across a reorg is the common ancestor's block hash. Rewind to it and re-scan.\n\nRecommended confirmation levels for indexers​\nOn Ethereum, indexers often wait a fixed number of confirmations (for example, 12 blocks). That model does not translate to Arbitrum: child blocks are produced far faster than the parent chain finalizes, and reorg exposure is a function of parent-chain finality, not of a child-block count. Wait on the block tag, not on a fixed depth.\nUse caseWait forRationaleCrediting deposits, releasing funds, any irreversible actionfinalizedFinalized parent-chain blocks do not revert, so a credited entry can never be reorged away.Low-value or reversible UX (pending balances, activity feed)safe, or latest with active reorg handlingFaster, but you must be able to roll back if a reorg occurs.Real-time display onlylatestSub-second, but explicitly provisional—label it as unconfirmed and expect it to change.\nIf your chain does not expose safe/finalized (see the note above), treat the Sequencer tip as soft and derive your own finality signal from the parent chain—for example, by tracking which batches have reached the parent chain's finalized block.\nReorg detection patterns​\nWhichever level you index at below finalized, detect reorgs by tracking hash continuity and rewinding:\n\nStore each scanned block's hash, keyed by height.\nOn each poll, confirm that each new block's parentHash matches the hash you stored for the height below it.\nOn a mismatch, walk back to the most recent height whose stored hash still matches the canonical chain—the common ancestor.\nDiscard every record and stored hash above the common ancestor, move your scan cursor back to it, and re-scan forward. Because a reorg can both remove and introduce transactions, re-checking only the records you already have is not enough.\nYou never need to rewind below the finalized height, because finalized blocks cannot reorganize.\n\nThe Exchange integration checklist works through this algorithm in the context of a full deposit-detection pipeline.\nThe --node.bold.rpc-block-number flag​\nYou may encounter the node flag --node.bold.rpc-block-number. It is a validator-side setting: it selects which parent-chain block tag the BoLD validator reads onchain Rollup and assertion state from. It accepts latest, safe, or finalized, and defaults to finalized.\nNot the tag your indexer reads--node.bold.rpc-block-number controls how the BoLD validator reads the parent chain during dispute-protocol operations. It does not configure the latest/safe/finalized tags your indexer requests from the child-chain RPC. Do not set it expecting to change indexer-facing finality; use the block tags on your RPC queries instead.\nThe latest / safe / finalized names come from Ethereum's proof-of-stake finality: finalized is roughly two epochs (~64 slots, ~13 minutes) behind the head and safe roughly one epoch (~32 slots) behind. Nitro does not hard-code those distances — it reads the parent chain's own safe/finalized tags — but that is the origin of the \"latest-64 / latest-32\" shorthand you may have seen.\nCorner cases​\nThe scenarios below are the ones integrators most often ask about. They follow directly from the model above.\nA parent-chain reorg moves a block that held one of our state-root attestations​\nNo child-chain reorg results. State-root assertions are settlement checkpoints, not sequenced data; if the parent-chain block carrying an assertion is reorged, the node re-submits the assertion. A child-chain reorg happens only if the reorg changes the Sequencer Inbox or delayed-inbox ordering.\nA reorg on Base's parent (Ethereum) affects a block holding some of our data​\nHandled the same way. If it changes the derived batch/delayed-message ordering, the affected unfinalized child blocks are re-derived; anything already finalized is unaffected.\nThe DAC has an outage and cannot sign attestations​\nWith fallback enabled (the default), the batch poster stops waiting after a few minutes and posts the full batch data directly to the parent chain as calldata. The Sequencer keeps producing blocks and they keep finalizing—hard finality is not blocked by the DAC outage, though batches temporarily cost more to post. Finality is only delayed if you have disabled fallback.\nThe DAC is completely down and the batch poster cannot reach it​\nThis halts batch posting only if fallback is disabled (disable-dap-fallback-store-data-on-chain: true). With fallback enabled, the chain continues via direct calldata posting. Decide this trade-off deliberately: fallback favors liveness, disabling it favors keeping all data off the parent chain.\nThe Sequencer cannot post batches (or DACerts) to the parent chain​\nThe Sequencer keeps producing soft-confirmed blocks on the feed, and the batch poster retries until it can post. Until a batch reaches parent-chain finality, those blocks are soft only—treat them as reversible for indexing purposes, even though they appear immediately on the feed.\nOne case does not retry: if a posted batch reverts on the parent chain, the batch poster halts all posting and waits for an operator. See Finality and feedback.\nRelated resources​\n\nExchange integration checklist — end-to-end deposit/withdrawal detection built on this model.\nGeth at the core — transaction types, ArbitrumInternalTx, and ReorgToOldBlock.\nFinality — soft and hard finality, trust models, and which level to require per use case.\nThe Sequencer — soft vs hard finality and batch posting.\nThe batch poster — batch building, the DA handoff, and the revert watcher that halts posting.\nAnyTrust protocol — keysets, DACerts, and the fallback to Rollup mode.\nDAC and DAS operations — DAC failure modes and fallback behavior.\nBlock numbers and time — parent-chain block numbers on the child chain.\nThe three confirmation levelsThe Fast Feed is not a fourth levelWhat \"seconds to finality\" really meansHow the node derives safe and finalizedPer-chain-type guaranteesParent chains outside the Ethereum and Arbitrum stacksAnyTrust and the DAC: what changes and what doesn'tThe reorg modelHow deep can a reorg go?ArbitrumInternalTx behavior under a parent-chain reorgRecommended confirmation levels for indexersReorg detection patternsThe --node.bold.rpc-block-number flagCorner casesA parent-chain reorg moves a block that held one of our state-root attestationsA reorg on Base's parent (Ethereum) affects a block holding some of our dataThe DAC has an outage and cannot sign attestationsThe DAC is completely down and the batch poster cannot reach itThe Sequencer cannot post batches (or DACerts) to the parent chainRelated resources","tokens":4907,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261094711,"hash":"e96b032fb6dbdf547e7fd91ae93fd4f7c5701065"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/58","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 53 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261095198,"hash":"ed1078379eb821621a0149f803c33b486b9249f1"}
{"url":"https://governance.aave.com/t/temp-check-deploy-aave-v4-on-arc/24990/1","domain":"governance.aave.com","title":"[Temp Check] Deploy Aave V4 on Arc - Governance / New Market - Aave","text":"[Temp Check] Deploy Aave V4 on Arc \n\n GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 29\n\n 1 / 6\n\n May 29\n\n Jun 7\n\n post by AaveLabs on May 29\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n V4_AVAX (4)1920×1028 75 KB\nSimple Summary\nThis Temp Check seeks community feedback on deploying Aave V4 on Arc alongside supporting an initial set of high-quality assets.\nArc is an institutional-grade public layer-1 blockchain, built by Circle and designed to be the Economic Operating System (OS) of the internet for digital dollar liquidity and real-world assets. Launching Aave V4 on Arc would position Aave as foundational financial infrastructure on a network optimized for capital-efficient liquidity flows from regulated institutions.\nThis Temp Check is intended to gauge community sentiment on:\n\nDeploying Aave V4 on Arc at or near mainnet launch\nSupporting the proposed initial asset scope\nAdvancing the proposal to the ARFC stage\n\nIf there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers.\nMotivation\nArc is preparing for mainnet launch. The permissionless blockchain is purpose built for stablecoins, tokenized real world assets, and global onchain finance. Arc, built by Circle, is focused on bringing DeFi innovation into traditional financial workflows to unlock new capital formation and expand the market for onchain credit and liquidity. As the Economic OS for the internet, Arc is designed to coordinate onchain credit and financial primitives with treasury backed instruments, tokenized assets, and compliance aligned infrastructure in a single onchain capital environment.\nDeploying Aave V4 on Arc would:\n\nEstablish Aave as one of the primary lending protocols at network launch\nGrow Aave’s available markets for Circle-issued assets\nExpand Aave’s presence into new institutional and fintech liquidity flows\nDrive incremental TVL and revenue opportunities for the Aave ecosystem\n\nArc’s design concentrates regulated stablecoin liquidity and tokenized products into a programmable settlement layer. Integrating Aave into the Economic OS positions it to serve as one of the primary lending protocols for capital forming on the network.\nA core objective of this deployment is to support meaningful stablecoin and tokenized asset liquidity at scale, subject to risk provider recommendations.\nSpecification\nIf there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design/liquidity commitments, and parameter recommendations from relevant Aave DAO service providers.\nFull technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers will be presented during ARFC.\nAsset Scope\nThe initial asset set proposed includes:\n\nUSDC\nEURC\ncirBTC\n\nThe intent is to consolidate assets into a single formal governance process where possible to reduce fragmentation and minimize proposal overhead.\nFinal asset inclusion and parameters will be subject to:\n\nAave DAO service provider feedback\n\nRevenue Support\nIn connection with the deployment, Aave DAO is expected to receive a minimum of $2m per year in protocol revenue from the Aave V4 deployment on Arc, with any shortfalls covered by certain Arc ecosystem participants for the first five years following deployment. This structure provides protection for Aave DAO during the bootstrap phase.\nUseful Links\n\nWebsite: https://www.arc.network/\nLitepaper: https://www.arc.network/litepaper\n\nDisclaimer\nAave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is not directly affiliated with Arc and did not receive compensation for this proposal.\nNext Steps\nIf this Temp Check indicates sufficient community support, the proposal will proceed as follows:\nPhase 1 - Snapshot vote on Temp Check\nPhase 2 – ARFC (Aave Request for Final Comments)\nPhase 3 – AIP (Onchain Vote)\nFollowing Snapshot approval, the final AIP payload will be submitted on Ethereum mainnet for onchain execution.\nDeployment preparation would begin after ARFC passage, with activation following successful AIP approval.\nRequested Feedback\nThe community is invited to provide feedback on:\n\nDeploying Aave V4 on Arc\nSupporting the proposed initial asset scope\nAdvancing this proposal to the ARFC stage\n\nIf there is sufficient positive sentiment, the authors will proceed with a detailed ARFC submission.\nCopyright\nCopyright and related rights waived via CC0.\n\n post by A_J on May 30\n\n post by axieaur on May 30\n\n post by MconnectDAO on May 30\n\n post by bobgodwinx on Jun 1\n\n post by Abel189 on Jun 7\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n AL Technical Assessment Aave <> Arc\n\n Assessments\n\n 0\n\n 140\n\n Sep 14\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d","tokens":1318,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261101184,"hash":"36847dba32c8d628bb2920dc2105f7c0a0b5123c"}
{"url":"https://ethereum.org/smart-contracts/","domain":"ethereum.org","title":"Smart contracts: What are they and their benefits | ethereum.org","text":"Edit page (opens in a new tab)Smart contracts are the fundamental building blocks of Ethereum's application layer. They are computer programs stored on the that follow \"if this then that\" logic, and are guaranteed to execute according to the rules defined by its code, which cannot be changed once created.\nNick Szabo coined the term \"smart contract\". In 1994, he wrote an introduction to the concept (opens in a new tab), and in 1996 he wrote an exploration of what smart contracts could do (opens in a new tab).\nSzabo envisioned a digital marketplace where automatic, processes enable transactions and business functions to happen without trusted intermediaries. Smart contracts on Ethereum put this vision into practice.\nWatch Finematics explain smart contracts:\nCode is law? Smart contracts explainedExploring the concept of 'code is law' through the lens of smart contracts on Ethereum and DeFi.Watch with transcript \nTrust in conventional contracts\nOne of the biggest problems with a traditional contract is the need for trusted individuals to follow through with the contract's outcomes.\nHere is an example:\nAlice and Bob are having a bicycle race. Let's say Alice bets Bob $10 that she will win the race. Bob is confident he'll be the winner and agrees to the bet. In the end, Alice finishes the race well ahead of Bob and is the clear winner. But Bob refuses to pay out on the bet, claiming Alice must have cheated.\nThis silly example illustrates the problem with any non-smart agreement. Even if the conditions of the agreement get met (i.e., you are the winner of the race), you must still trust another person to fulfill the agreement (i.e., payout on the bet).\nA digital vending machine\nA simple metaphor for a smart contract is a vending machine, which works somewhat similarly to a smart contract - specific inputs guarantee predetermined outputs.\n\nYou select a product\nThe vending machine displays the price\nYou pay the price\nThe vending machine verifies that you paid the right amount\nThe vending machine gives you your item\n\nThe vending machine will only dispense your desired product after all requirements are met. If you don't select a product or insert enough money, the vending machine won't give out your product.\nAutomatic execution\nThe main benefit of a smart contract is that it deterministically executes unambiguous code when certain conditions are met. There is no need to wait for a human to interpret or negotiate the result. This removes the need for trusted intermediaries.\nFor example, you could write a smart contract that holds funds in escrow for a child, allowing them to withdraw funds after a specific date. If they try to withdraw before that date, the smart contract won't execute. Or you could write a contract that automatically gives you a digital version of a car's title when you pay the dealer.\nPredictable outcomes\nTraditional contracts are ambiguous because they rely on humans to interpret and implement them. For example, two judges might interpret a contract differently, which could lead to inconsistent decisions and unequal outcomes. Smart contracts remove this possibility. Instead, smart contracts execute precisely based on the conditions written within the contract's code. This precision means that given the same circumstances, the smart contract will produce the same result.\nPublic record\nSmart contracts are useful for audits and tracking. Since Ethereum smart contracts are on a public blockchain, anyone can instantly track asset transfers and other related information. For example, you can check to see that someone sent money to your address.\nPrivacy protection\nSmart contracts also protect your privacy. Since Ethereum is a pseudonymous network (your transactions are tied publicly to a unique cryptographic address, not your identity), you can protect your privacy from observers.\nVisible terms\nFinally, like traditional contracts, you can check what's in a smart contract before you sign it. Unlike a traditional contract, a smart contract's onchain transparency allows anyone to scrutinize and review it before interacting with it.\nHowever, while anyone can view a smart contract's terms, the raw transaction data is designed to be interpreted by applications and wallets, not humans. Because this data is so difficult to read, users often face a major security risk called \"blind signing,\" or approving a transaction that interacts with a smart contract without actually understanding what it will do.\nThe Ethereum ecosystem is transitioning to Clear Signing (opens in a new tab) standards (specifically ERC-7730 (opens in a new tab)). Clear Signing translates opaque smart contract data into plain, human-readable transaction descriptions, ensuring anyone can understand a contract's true intent before they sign.\nSmart contract use cases\nSmart contracts can do essentially anything that computer programs can do.\nThey can perform computations, create currency, store data, mint , send communications and even generate graphics. Here are some popular, real-world examples:\n\nStablecoins\nCreating and distributing unique digital assets\nAn automatic, open currency exchange\nDecentralized gaming\nAn insurance policy that pays out automatically (opens in a new tab)\nA standard that lets people create customized, interoperable currencies\n\nFurther reading\n\nHow Smart Contracts Will Change the World (opens in a new tab)\nSmart contracts for developers\nLearn to write smart-contracts\nMastering Ethereum - What is a Smart Contract? (opens in a new tab)\n\nTest your Ethereum knowledgeSmart contractsQuestion number 1:Which is NOT a main characteristic of smart contracts?","tokens":1409,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261106922,"hash":"fc032935c62c64010a646730f7ef017ffab50899"}
{"url":"https://dev-forum.pyth.network/t/terms-conditions/527/2","domain":"dev-forum.pyth.network","title":"Terms & Conditions - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 5\n\n 2 / 2\n\n Mar 5\n\n Mar 5\n\n post by CHOPPAtheSHARK on Mar 5\n\n CHOPPAtheSHARK\n\n Pyth Playground — Terms & Conditions\n\n1. Overview\n1.1 Main Parties\n\nPyth Playground (the “Hackathon”) is a community-driven event organized by PYTH DAO LLC, PO Box 852, Long Islands Rd Majuro, Marshall Islands MH 96960 (the “Organizer”, the “DAO” or “we”). The Hackathon encourages participants to build open-source projects utilizing Pyth Network capabilities.\n\n“Participant” or “you” refer to any individual taking part in the Hackathon and agreeing to these Terms & Conditions as part of their participation.\n\nThe Pyth Community Council (the “Council”) is an elected body of the Organizer responsible for the management of community platforms, initiatives, campaigns and other programs which develop community engagement within the DAO. The Council operates with its own allocated budget and governance structure. The Council is the corporate body within the DAO responsible for organizing the Hackathon.\n\n1.2 Independence of Other Pyth Legal Entities\n\nThe DAO operates independently from the Pyth Data Association, Grabenstrase 25, 6340 Baar, a non-profit association incorporated under the laws of Switzerland, under registration number CHE-325.103.020 (“PDA”). The Hackathon, these Terms and Conditions, any other contractual or other legal obligations entered into by the Participant are not entered into with the PDA, nor does the PDA sponsor, organize or participate in the Hackathon.\n\n1.3 Binding Effect of Terms & Conditions\n\nThese Terms and Conditions constitute a legally binding agreement between the Organizer and each Participant. By registering for, accessing, or participating in the Hackathon, the Participant confirms their full acceptance of, and agreement to be bound by, these Terms and Conditions.\n\nIf the Council determines that a Participant has breached these Terms & Conditions, the Council may, with immediate effect, disqualify the Participant (or their team) from the Hackathon and/or revoke prize eligibility.\n\n2. Participant Eligibility Requirements\n\nParticipation in the Hackathon is subject to the Participant’s compliance with the requirements set out in this Section 2, which apply at the start of, during, and at the end of the Hackathon.\n\n2.1 Age\n\nThe Participant must be 18 years of age or older at the time of registration.\n\n2.2 Excluded Jurisdictions\n\nParticipants located in, ordinarily resident in, or nationals of countries or territories subject to comprehensive sanctions are not eligible to participate. This includes, without limitation:\n\nNorth Korea\n\nIran\n\nCuba\n\nCrimea region\n\nMyanmar\n\nDonetsk People’s Republic\n\nLuhansk People’s Republic\n\nSyria\n\nAny other jurisdiction subject to OFAC comprehensive sanctions\n\nBy participating, the Participant represents and warrants that they are not located in, ordinarily resident in, or a national of any such restricted jurisdiction.\n\n2.3 Teams\n\nParticipation is permitted individually or in teams of no more than two participants. All team members must individually satisfy the eligibility requirements set out in Section 2 of these Terms and Conditions. Each Participant may be a member of only one team per Hackathon.\n\n2.4 Participants Making a Contribution to the DAO\n\nParticipants who regularly contribute to the DAO (a “Contribution” meaning any recurring or ongoing provision of services or work product to or for the DAO, whether paid or unpaid, including as an employee, contractor, advisor, service provider, contributor, staker or volunteer) are permitted to participate in the Hackathon; however, they are excluded from eligibility to receive any prize.\n\nEach Participant must disclose at the application stage whether they make, or reasonably expect to make during the Hackathon, a Contribution.\n\nFor the avoidance of doubt, participation in the Hackathon does not create any employment, contractor, partnership or agency relationship between the Organizer and any Participant.\n\n3. Project Submission and Requirements\n3.1 Submission Requirements\n\nEach project must be submitted no later than April 1st, 2026. Late submissions may be rejected. The Organizer will provide a submission process, further set out in the Hackathon announcement (the “Official Submission Process”).\n\nThe submission must satisfy any content requirements set out in the Hackathon announcement.\n\n3.2 Technical Requirements\n\nAll submissions must:\n\ni. Utilize at least one Pyth Network feature (Price Feeds, Entropy, or Pyth Pro); ii. Include a working demonstration or live deployment; iii. Provide source code via public repository (GitHub, GitLab, etc.); iv. Post about your project on Reddit, Dev.to, or equivalent platform; and v. Be submitted through the Official Submission Process before the deadline.\n3.3 Licensing Requirements\n\nAll submissions must be released under the Apache License 2.0, consistent with Pyth Network’s own licensing. By submitting an entry, the Participant represents and warrants that they have the right to license the submission under the Apache License 2.0 and agree that the submission will be publicly available and may be reproduced, modified and distributed by the public in accordance with the terms of that license.\n\n3.4 Intellectual Property\n\nThe Participant retains all ownership and intellectual property rights in their submissions and any underlying code, designs, or content created during the Hackathon, subject to the licenses granted herein.\n\nThe Participant represents and warrants that their participation in the Hackathon is done in their individual capacity, and not as a representative or agent of any employer, university, or other organization, and that they are not bound by any contractual restrictions with any other third party which may limit their ability to participate in the Hackathon and to fully comply with these Terms & Conditions.\n\nThe Participant is responsible for ensuring that their submission does not infringe upon the intellectual property rights of any third party. If a submission incorporates third-party code or assets, the Participant must ensure they have the necessary licenses or permissions for such use and must clearly attribute all third-party intellectual property.\n\nUse of Pyth Network branding must comply with official brand guidelines. Submissions may reference Pyth but should not imply official endorsement.\n\n3.5 Winning & Judging\n\nIf there is a winner of the Hackathon, the Organizer reserves the right to determine the winner, including the composition of the panel of judges.\n\n4. Prize\n\nIf a winner is selected for the Hackathon, such winner shall be entitled to receive a prize as determined by the Organizer. Prizes are awarded in PYTH tokens. The prize amounts and structure shall be set out in the Hackathon announcement. The Organizer reserves the right to modify the prize amount and structure for subsequent iterations of the Hackathon.\n\nThe Participant acknowledges that distribution of any prize is contingent upon passing of KYC identification requirements imposed by the Organizer. If the Participant fails or refuses to provide such information or fails any required checks, the Participant may be disqualified from prize eligibility and the prize may be withheld or reallocated to another Participant.\n\n5. Disqualification\n\nThe Council may, at its sole and absolute discretion, disqualify any submission at any time for any reason, including if it determines that the submission: (i) violates any eligibility requirements; (ii) contains plagiarized, infringing or misappropriated code; (iii) includes malicious, harmful or deceptive functionality; (iv) violates any applicable laws or regulations; or (v) misrepresents Pyth integration or functionality. All determinations of the Council are final and binding.\n\n6. Liability\n6.1 No Guarantees\n\nParticipation in the Hackathon does not guarantee receipt of any prize, reward, or recognition.\n\nThe Council reserves the right to modify, suspend, or cancel the Hackathon at any time, for any reason, and without prior notice.\n\nTechnical issues, failures, delays or limitations relating to Pyth network services (including, but not limited to data feeds, APIs, smart contracts, or infrastructure) do not constitute grounds for appeal and do not create any obligation for the Organizer.\n\n6.2 Cryptocurrency Risks\n\nParticipants acknowledge and agree that any PYTH tokens awarded or transferred in connection with the Hackathon are subject to significant price volatility and may lose some or all of their value, that token transfers and any prize distribution may be delayed, or otherwise affected by blockchain and network conditions (including congestion, forks, outages, validator or RPC issues) and may incur network fees, that the Organizer is not responsible or liable for any losses arising from wallet or address errors (including incorrect wallet addresses provided by a Participant), loss of private keys or seed phrases, compromised wallets, phishing or other security incidents, or any irreversible or failed transfer, and that the legal and regulatory treatment of tokens and token transfers (including tax reporting and liability) varies by jurisdiction and may change, and each Participant is solely responsible for ensuring their participation in the Hackathon and receipt, holding, use and/or transfer of any tokens complies with applicable laws and for obtaining independent legal and tax advice where needed.\n\n6.3 Limitation of Liability\n\nTo the maximum extent permitted by law, the Organizer, the Council, PDA, and its affiliates shall not be liable for any indirect, incidental, special, consequential, or punitive damages arising from your participation in the Hackathon.\n\n6.4 Third-Party Platforms\n\nThe DAO or the Council might ask the Participant to use a third-party platform to participate in the Hackathon. Any use of a third-party platform (like GitHub, Discord, Discourse etc.) is governed solely by that third party’s applicable terms of service, acceptable use policies, and privacy policies, and participants are responsible for reviewing and accepting (and continuing to comply with) such terms. The Organizer is not affiliated with, does not control, and does not endorse any third-party platforms, and it does not provide any support, representations, warranties, or guarantees regarding the availability, security, functionality, or suitability of any third-party platform.\n\n7. Tax Obligations\n\nToken prizes have monetary value and may constitute taxable income in the Participant’s jurisdiction.\n\nThe Participant is solely responsible for compliance with their local tax obligations arising from token rewards.\n\n8. Privacy & Data\n8.1 Data Collection\n\nBy registering for and participating in the Hackathon, the Participant acknowledges and consents that the Organizer may collect and process the following categories of personal data:\n\ni. Discord handle and/or Pyth forum username; ii. Wallet address for the purpose of prize distribution; iii. Submission materials and associated metadata; and iv. Any additional information voluntarily provided by the Participant during registration.\n\nIf the Participant is selected as a winner (or potential winner), the Organizer (and/or its designated KYC or payment service provider) may require the Participant to complete identity verification and screening checks in order to receive any prize, including by providing valid government-issued photographic identification and proof of address (for example, a recent utility bill or bank statement) and any other information reasonably required to comply with applicable laws and regulations (including anti-money laundering, sanctions and counter-terrorist financing requirements).\n\n8.2 Use and Sharing of Data\n\nThe data collected pursuant to Section 8.1 will be used solely for the following purposes:\n\ni. Hackathon administration, operation and communication; ii. Verification of Participant eligibility and compliance with these Terms and Conditions; iii. Prize distribution; and iv. Public display, promotion of submissions and winners.\n\nTo the extent necessary for the purposes set out above, personal data may be shared with third parties, including but not limited to service providers, partners, and competent authorities. This includes sharing relevant personal data with the PDA and/or other designated third-party providers for the purposes of conducting KYC, AML, or similar compliance checks in connection with prize distribution.\n\nAll third parties receiving personal data will process such data in accordance with applicable data protection laws and solely for the purposes for which it is disclosed.\n\n8.3 Data Retention\n\nSubmission data and winner information may be retained indefinitely for record-keeping, historical and promotional purposes. Contact and registration information will be retained for the duration of the Hackathon and for up to twelve (12) months thereafter, unless a longer retention period is required or permitted by applicable law.\n\n9. Modifications\n\nThe Council reserves the right to modify these terms at any time. Material changes will be communicated through official channels. The Participant agrees that continued participation after modifications constitutes acceptance.\n\n10. Failure to Comply\n\nFailure to comply with these Terms and Conditions may imply your immediate disqualification from the Hackathon. Additionally, we reserve the right to take any available legal action against you if you fail to comply with these Terms and Conditions, including enforcement of our intellectual property rights.\n\n11. Governing Law and Jurisdiction\n11.1 Governing Law\n\nThese Terms and Conditions shall be governed by and construed in accordance with the substantive laws of Marshall Islands, to the exclusion of the principles of conflicts of laws thereof.\n\n11.2 Jurisdiction\n\nThese Terms and Conditions are intended as guidelines for a decentralized community initiative. Prior to engaging in traditional methods of dispute resolution, disputes should be resolved through the Organizer’s community governance processes where possible.\n\nAny dispute, controversy or claim arising out of or in relation to these Terms and Conditions or future non-contractual claims including the validity, invalidity, enforceability, interpretation, execution, breach, modification or termination thereof, shall be submitted to the exclusive jurisdiction of the courts of Marshall Islands.\n\n Pyth Community Hackathon Official Rules\n\n Submission Template\n\n FOGO Pulse - A binary trading platform - live\n\n Price Prediction Grids on Pyth Price Feed\n\n Walk The Planck\n\n read \n\n 5\n min\n\n Pinned on Mar 5\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Community Hackathon Official Rules\n\n Pyth Community Hackathon\n\n 0\n\n 566\n\n Mar 2\n\n Getting Started & FAQ\n\n Pyth Community Hackathon\n\n 61\n\n 620\n\n Mar 31\n\n Submission Template\n\n Pyth Community Hackathon\n\n 0\n\n 283\n\n Mar 2\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 23\n\n Mar 28\n\n Powered by Discourse","tokens":4707,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261108833,"hash":"ec7ff6e9f9684e2373af7b0b2f35fdfcc73f8846"}
{"url":"https://governance.aave.com/t/temp-check-deploy-aave-v4-on-arc/24990/6","domain":"governance.aave.com","title":"[Temp Check] Deploy Aave V4 on Arc - Governance / New Market - Aave","text":"GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 29\n\n 6 / 6\n\n Jun 6\n\n Jun 7\n\n post by AaveLabs on May 29\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n V4_AVAX (4)1920×1028 75 KB\nSimple Summary\nThis Temp Check seeks community feedback on deploying Aave V4 on Arc alongside supporting an initial set of high-quality assets.\nArc is an institutional-grade public layer-1 blockchain, built by Circle and designed to be the Economic Operating System (OS) of the internet for digital dollar liquidity and real-world assets. Launching Aave V4 on Arc would position Aave as foundational financial infrastructure on a network optimized for capital-efficient liquidity flows from regulated institutions.\nThis Temp Check is intended to gauge community sentiment on:\n\nDeploying Aave V4 on Arc at or near mainnet launch\nSupporting the proposed initial asset scope\nAdvancing the proposal to the ARFC stage\n\nIf there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers.\nMotivation\nArc is preparing for mainnet launch. The permissionless blockchain is purpose built for stablecoins, tokenized real world assets, and global onchain finance. Arc, built by Circle, is focused on bringing DeFi innovation into traditional financial workflows to unlock new capital formation and expand the market for onchain credit and liquidity. As the Economic OS for the internet, Arc is designed to coordinate onchain credit and financial primitives with treasury backed instruments, tokenized assets, and compliance aligned infrastructure in a single onchain capital environment.\nDeploying Aave V4 on Arc would:\n\nEstablish Aave as one of the primary lending protocols at network launch\nGrow Aave’s available markets for Circle-issued assets\nExpand Aave’s presence into new institutional and fintech liquidity flows\nDrive incremental TVL and revenue opportunities for the Aave ecosystem\n\nArc’s design concentrates regulated stablecoin liquidity and tokenized products into a programmable settlement layer. Integrating Aave into the Economic OS positions it to serve as one of the primary lending protocols for capital forming on the network.\nA core objective of this deployment is to support meaningful stablecoin and tokenized asset liquidity at scale, subject to risk provider recommendations.\nSpecification\nIf there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design/liquidity commitments, and parameter recommendations from relevant Aave DAO service providers.\nFull technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers will be presented during ARFC.\nAsset Scope\nThe initial asset set proposed includes:\n\nUSDC\nEURC\ncirBTC\n\nThe intent is to consolidate assets into a single formal governance process where possible to reduce fragmentation and minimize proposal overhead.\nFinal asset inclusion and parameters will be subject to:\n\nAave DAO service provider feedback\n\nRevenue Support\nIn connection with the deployment, Aave DAO is expected to receive a minimum of $2m per year in protocol revenue from the Aave V4 deployment on Arc, with any shortfalls covered by certain Arc ecosystem participants for the first five years following deployment. This structure provides protection for Aave DAO during the bootstrap phase.\nUseful Links\n\nWebsite: https://www.arc.network/\nLitepaper: https://www.arc.network/litepaper\n\nDisclaimer\nAave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is not directly affiliated with Arc and did not receive compensation for this proposal.\nNext Steps\nIf this Temp Check indicates sufficient community support, the proposal will proceed as follows:\nPhase 1 - Snapshot vote on Temp Check\nPhase 2 – ARFC (Aave Request for Final Comments)\nPhase 3 – AIP (Onchain Vote)\nFollowing Snapshot approval, the final AIP payload will be submitted on Ethereum mainnet for onchain execution.\nDeployment preparation would begin after ARFC passage, with activation following successful AIP approval.\nRequested Feedback\nThe community is invited to provide feedback on:\n\nDeploying Aave V4 on Arc\nSupporting the proposed initial asset scope\nAdvancing this proposal to the ARFC stage\n\nIf there is sufficient positive sentiment, the authors will proceed with a detailed ARFC submission.\nCopyright\nCopyright and related rights waived via CC0.\n\n post by A_J on May 30\n\n A_J\n\n Minimum commitment in bootstrap phase is appreciated \nWin win situation! I am in favour of temp check.\n\n post by axieaur on May 30\n\n axieaur\n\n in favor of deploying v4 on arc\n\n post by MconnectDAO on May 30\n\n MconnectDAO\n\n From my side, key open points:\n\nArc is a brand‑new L1; can we get a concise chain‑level risk memo (consensus, infra, oracle, bridge assumptions) from risk providers or Arc engineers before ARFC?\n\ncirBTC is the least understood asset here; a short dedicated note on its backing, peg design, oracle setup, and emergency procedures would really help inform conservative initial parameters.\n\nThe 2M USD/year revenue floor is attractive, but how is the shortfall guarantee actually enforced (legal structure, escrow/multisig, or soft commitment)? What is the failure scenario if participants do not backfill?\n\n post by bobgodwinx on Jun 1\n\n bobgodwinx\n\n Honesty with ARC now the question is more than ever when are we going to scale GHO to compete with TradFi Centralized “StableCoins” like USDC\ncirBTC is the same thing like WBTC they just copied MAKER code and pasted it on ARC. We should actually say thanks to MAKER it is one of the most robust code out there.\nAnyway this is another EVM so I support it.\n\n post by Abel189 on Jun 7\n\n Abel189\n\n Generally supportive of advancing this proposal to the ARFC stage.\nArc’s focus on stablecoins, tokenized assets, and institutional capital flows appears highly aligned with Aave’s strategic direction. If Arc succeeds in attracting meaningful liquidity and RWA activity, establishing Aave V4 as a core lending primitive from day one could create a strong long-term positioning advantage.\nOne aspect that stands out positively is the proposed minimum revenue commitment of $2M annually for the first five years. As Aave expands across multiple ecosystems, it becomes increasingly important to evaluate deployments not only through TVL growth but also through their expected contribution to protocol revenue. The revenue backstop helps align incentives and reduces bootstrap risk for the DAO.\nFor the ARFC stage, I would be interested in additional detail regarding:\n• Expected liquidity commitments at launch.\n• Revenue-sharing mechanics and guarantees.\n• Demand assumptions for cirBTC, EURC, and USDC borrowing activity.\n• The roadmap for additional RWA assets.\n• How Arc differentiates itself from other emerging institutional-focused ecosystems.\nOverall, this appears to be a strategically aligned opportunity that merits further evaluation through the ARFC process.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n AL Technical Assessment Aave <> Arc\n\n Assessments\n\n 0\n\n 140\n\n Sep 14\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d","tokens":1915,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261123405,"hash":"0c8ca0647a9e5aa6b2cb54d2243f0fbe68393bb9"}
{"url":"https://ethereum.org/videos/smart-contracts-code-is-law/","domain":"ethereum.org","title":"Code is law? Smart contracts explained | ethereum.org","text":"Code is law? Smart contracts explainedExploring the concept of 'code is law' through the lens of smart contracts on Ethereum and DeFi. This video covers what smart contracts are, how they work, and the philosophical question of whether code should be the ultimate arbiter.Date published: November 18, 2020An explainer by Finematics exploring the concept of \"code is law\" through the lens of smart contracts on Ethereum, covering what smart contracts are, how they work, their advantages over traditional contracts, and why they are the building blocks of decentralized finance.\nThis transcript is an accessible copy of the original video transcript (opens in a new tab) published by Finematics. It has been lightly edited for readability.\nIntroduction (0:00)\nHave you ever heard the expression \"code is law,\" where technology is used to enforce rules? In that case, do we even need lawyers? Or maybe we can live in a fully automated world where code dictates what we can and cannot do. With the current development of smart contracts, this futuristic scenario may be closer than we think.\nA smart contract is a piece of code that can be executed automatically and in a deterministic way. The smart contract code is usually stored and executed on the blockchain to make it trustless and secure. Smart contracts also have the capability of receiving, storing, and sending funds — and even calling other smart contracts. They follow if-then semantics, which makes them fairly easy to program.\nSmart contracts aim at removing the human factor from decision-making. The human factor is often proven to be the most error-prone and unreliable element of standard traditional contracts.\nA vending machine comes up very often as a good analogy to a smart contract, as it shares some similarities. A typical vending machine is programmed in a way that allows certain actions and state transitions based on the input. It also works in a fully deterministic way. For example, if you want to buy a can of coke that costs two dollars and you only have one dollar, no matter how many times you try, you won't be able to get the drink. On the other hand, if you insert three dollars, the machine will give you a can of coke and appropriate change. Even the change given is selected in a predefined and programmed way based on which coins are available and which coins the machine wants to get rid of first.\nA smart contract can rely purely on the information available on the blockchain — for example, \"if you give me ten tokens A, I'll give you ten tokens B.\" Or it can rely on an external data source, for example, on the ETH or S&P 500 price. The latter example makes smart contracts more difficult, as they have to trust real-world data. The needed trust can be minimized by using oracle services, but even oracle services have to be trusted. There are already a few projects that, by using certain incentives, make oracles more likely to provide correct data. Chainlink is a project that clearly stands out in this category.\nEthereum smart contracts (3:09)\nEthereum is a blockchain that supports smart contracts and makes it possible for a programmer to implement their own smart contracts. A smart contract can be written in a programming language called Solidity, which was created specifically for that purpose. In Ethereum, all deployed smart contracts are immutable — this means that once deployed, they cannot be modified, which creates certain risks that we're going to discuss later.\nSmart contracts on Ethereum are also decentralized, which means there is no single machine controlling the contract. In fact, all the nodes on the Ethereum network store the same contract with exactly the same state. Although Ethereum is currently the most popular general-purpose smart contract platform, it is not the only one and it has a few competitors, including Cardano, Tezos, EOS, and Tron — but not all of them share the same characteristics.\nSmart contract definition (4:23)\nThe term \"smart contract\" was coined by well-known cryptographer Nick Szabo in the early 1990s. The name, although not the most self-explanatory, stuck and it's commonly used, especially in the blockchain industry. To see the benefits of smart contracts, let's compare a hypothetical smart contract to its equivalent in the traditional space.\nSmart contract example (4:46)\nLet's say we want to write the following contract: if Alice sends X number of tokens A and Bob sends the same number of tokens B, the tokens will be swapped — Alice will receive Bob's tokens and Bob will receive Alice's tokens.\nIn a non-smart-contract world, one way of achieving that without Alice having to trust Bob and Bob having to trust Alice would be to create an escrow contract with a third party. The third party would collect tokens A from Alice, wait for the same number of tokens B from Bob, and send Alice and Bob the respective swapped tokens.\nSmart contract problems (5:45)\nThis approach already shows a few problems that Alice and Bob may be facing:\n\nTrusting intermediaries — there is no guarantee that the third party will not run away with the tokens after receiving funds from Alice and Bob. We have to rely on the reputation of the intermediary and potential insurance.\nNon-deterministic outcomes — if something goes wrong, it may have different outputs depending on multiple factors, including the jurisdiction where a potential case would be settled.\n\nOn the other hand, a smart contract would work in a fully automated and deterministic way, making sure both parties receive funds when they meet the initial criteria of depositing tokens. Smart contracts can also hold funds within themselves, which is not possible to achieve in the traditional world.\nSpeed (6:47)\nDepending on the intermediary, Alice and Bob may have to wait even a few days or weeks to settle the transition of tokens. What if they want to swap tokens on a Sunday and the intermediary is not operating? With smart contracts, these kinds of problems go away, and the contract can be fulfilled seconds after the initial criteria are met.\nCost (7:16)\nTraditional contracts are not only expensive because of the intermediary that has to make a profit — there is also a huge risk of hidden costs for things like arbitration and enforcement if there are any problems with the contract.\nReusability is another advantage: the same smart contract responsible for swapping Alice's and Bob's tokens could be used by anyone else who wants to swap tokens. In the traditional world, they would all have to sign separate contracts and pay the respective fees to the intermediary.\nFraud (7:58)\nFraud is yet another hidden cost, this time for the intermediary itself. The intermediary would have to make sure that both Alice's and Bob's tokens are legitimate before initializing a swap. Fraud is very common in traditional finance, and most companies have huge teams working purely on preventing fraud. With smart contracts, the tokens can be verified on the blockchain, and with digital signatures, it's clear straight away whether both Alice and Bob are eligible for spending their tokens.\nUse cases (8:42)\nSmart contracts have a growing number of use cases ranging from payments and decentralized finance to supply chain and crowdfunding. Smart contracts are also the basic building blocks for decentralized applications, or dapps.\nDeFi (9:07)\nDecentralized finance, or DeFi, is one of the new industries that relies heavily on smart contracts. Some of the things that have already been built in this space include:\n\nDecentralized stablecoins — with clever use of smart contracts and certain incentives, we can create a stablecoin pegged to the U.S. dollar without having to store dollars in the real world. MakerDAO is one of the projects that makes this possible.\nAutomated liquidity provisioning — a set of smart contracts can allow users to provide liquidity and swap tokens in a completely permissionless and decentralized fashion. Uniswap and Kyber Network are good examples of such protocols.\n\nCrowdfunding and supply chains (10:05)\nAnother use case is providing more transparency to supply chains, where protocols like OriginTrail come into play. When it comes to crowdfunding, you can imagine a contract that unlocks funds as soon as certain goals are met and verified by the community.\nFuture smart contracts (10:29)\nWhat if smart contracts could facilitate things like ride-sharing, apartment rentals, and much more? How about charity? You can imagine a fully automated fund that would send money directly to the people who need it the most, without any intermediaries. For example, the fund could determine that a certain region was struck by a hurricane and redirect funds to that part of the world. For now, it sounds quite impossible, but all the necessary elements to make something like this happen are being built as we speak.\nThe use cases for smart contracts are almost infinite, but before we can achieve all of that, we have to tackle a few problems:\n\nBugs — one of the main risks when it comes to smart contracts is something that haunts every other piece of software. The best example is the DAO hack, which resulted in millions of dollars worth of Ether lost as the attacker was able to drain funds from the smart contract. This caused Ethereum to hard fork and created a lot of disagreement in the Ethereum community. Since the DAO hack, the Ethereum community has come up with a lot of extra security measures. These days, pretty much all popular smart contracts have gone through a security audit, often by multiple teams. There is also a trend for using formal verification methods to prove that certain contracts will always behave in an expected way.\nProtocol changes — even if a smart contract doesn't have any bugs and has been audited, we still cannot guarantee that a change on the platform level will not cause problems. An upgrade to the protocol itself may cause certain smart contracts to start behaving differently than expected.\nReal-world data — oracle services can provide a reliable way of getting information from the real world into the blockchain. But imagine you rented an apartment or a car and made some accidental damage. How would a smart contract, without any human intervention, possibly know about it? There are multiple examples where it's hard to imagine how something unexpected that happens in the real world can be visible to a smart contract.\n\nBesides the above, there are also risks involving regulation and tax, but these can all eventually be solved.\nCan we replace lawyers? (13:58)\nSo can we actually replace lawyers with code? Not quite — at least not right now. In the future, more and more contracts will likely be automated, especially in finance. But even in a fully automated world, lawyers can provide valuable knowledge that can be translated into code. There are also a lot of regulatory challenges around the crypto industry that will keep lawyers very busy for a while. Nevertheless, if I were a lawyer, I would start learning about smart contracts and coding, as they will play a big role in the future.\nSummary (14:53)\nSmart contract pros:\n\nFully automated\nDeterministic results\nTrustless\nFast, precise, and secure\nCost-efficient and transparent\n\nSmart contract cons:\n\nSoftware bugs\nProtocol changes\nRegulatory and tax uncertainty\n\nEven though smart contracts carry certain risks, we are still very early, and most of the current problems are solvable.","tokens":2863,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261128853,"hash":"cb71768d8b6f341602a4c2b9446bea5a8251c5d8"}
{"url":"https://dev-forum.pyth.network/t/real-time-oracle-intelligence-platform-paper-prediction-game/671","domain":"dev-forum.pyth.network","title":"Real-time oracle intelligence platform + paper prediction game - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Real-time oracle intelligence platform + paper prediction game \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 28\n\n 1 / 3\n\n Mar 27\n\n Mar 28\n\n post by 0xPilotSB on Mar 28\n\n 0xPilotSB\n\n (topic deleted by author)\n\n Unlisted on Mar 28\n\n Listed on Mar 29\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Ouroboros — Describe a Game, Get a Deployed Pyth dApp (AI AGENT)\n\n Pyth Community Hackathon\n\n 0\n\n 49\n\n Apr 1\n\n Real-time Oracle Intelligence Platform + Paper Prediction Games\n\n Pyth Community Hackathon\n\n 0\n\n 35\n\n Mar 29\n\n PyPredict — Real-Time Prediction Markets on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 32\n\n Mar 31\n\n Price Royale - A price prediction game built on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 44\n\n Mar 24\n\n Powered by Discourse","tokens":1118,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261130787,"hash":"0289edbb7ad442406553a54f150d7276801248ff"}
{"url":"https://governance.aave.com/t/al-technical-assessment-aave-arc/25638/1","domain":"governance.aave.com","title":"AL Technical Assessment Aave <> Arc - Risk / Assessments - Aave","text":"AL Technical Assessment Aave <> Arc \n\n RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 14\n\n 1 / 1\n\n Sep 14\n\n Sep 14\n\n post by AaveLabs on Sep 14\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Title: [Network Technical Assessment] Aave <> Arc\nAuthor: Aave Labs\nDate: 2026-09-14\n\nimage1920×1028 291 KB\n\nPreliminary assessment status. Aave Labs had access to Arc and was able to perform this analysis before its public mainnet availability. A follow-up post will clarify should any statement in this assessment differ from conditions observed after public mainnet availability. Arc was in a private mainnet phase when assessed, before its announced public mainnet availability on 16 September 2026, and public access to the RPC, explorer, Alchemy, and Tenderly services remained gated.\n\nObjective and independence of this assessment\nThis is an independent assessment of the technical components Aave Labs considers material for Aave software to run optimally on a candidate network, not a categorical judgment that Arc is good or bad, and not a requirement for Aave to deploy on Arc. That decision rests with Aave governance, independent of the views expressed here. Circle’s team was an important source of information throughout this assessment and was consistently forthcoming and supportive; everything in this report nonetheless reflects Aave Labs’ own independent criteria exclusively.\n1. Introduction to Arc\n\nField\nValue\n\nNetwork\nArc\n\nNetwork operator\nCircle\n\nNetwork type\nPermissioned proof of authority Layer 1\n\nChain ID\n5042\n\nTarget market\nAave, contracts targeting Cancun (all versions)\n\nArc pairs a Byzantine Fault Tolerant consensus engine, a design that keeps the network in agreement even if some participants act dishonestly, with a standard, Ethereum compatible environment for running smart contracts. Committed blocks are final, with no reorganization risk. Consensus is run by a permissioned set of vetted institutions, while operating a non-validating full node is open to anyone. USDC is the network’s native gas asset: its native and ERC-20 forms are the same asset, sharing balances, with blacklist and freeze operations performed at the protocol level. Arc is a standalone Layer 1: it does not post data to Ethereum and has no external data availability layer.\n2. Methodology\nEach category in Section 3 is assessed with a simplified rating: ★★★ Strong, fully meets requirements or exceeds them; ★★☆ Acceptable, meets requirements with caveats; ★☆☆ Concern, meaningful gaps, missing data, or limited validation. Because Arc operates as a permissioned Layer 1 rather than a rollup, the criteria applied are the equivalent Layer 1 level checks (see Section 3.16), not the rollup specific assumptions the framework otherwise defaults to.\n3. Evaluation\n3.1 Oracles\nReliable oracle infrastructure is a baseline requirement for Aave on any network.\nChainlink publishes 28 Data Feeds for Arc mainnet, and each one verified live onchain within its published heartbeat, covering USDC, USDT, ETH, BTC, cbBTC, AAVE, LINK, EURC, PAXG, a set of forex pairs, and rate feeds for yield bearing assets. An AAVE Network Emergency Count feed, the emergency mode oracle Aave’s Guardian mechanism consumes, was also confirmed live. Arc is a Layer 1 with no rollup sequencer, so a Chainlink sequencer uptime feed is not applicable; the equivalent liveness risk is a validator coalition holding more than one third of voting power stalling the chain (see Section 3.15). A proof of reserve feed, cirBTC Reserves (0xEB0884a871ea1f6483B5FC10fd3D7dC5806411fc), exists for cirBTC, a wrapped Bitcoin asset; no proof of reserve feed exists for other backed or wrapped assets on Arc.\nRating: ★★★ Strong\n3.2 Blockchain Explorer\nAave operations require a usable explorer environment after deployment.\nA mainnet block explorer was confirmed functional during this assessment. Aave Labs was granted access, and the explorer is expected to be made public at launch. The public test network explorer, testnet.arcscan.app, is live and source verified.\nRating: ★★★ Strong\n3.3 RPC Standard Compatibility\nAave relies on standard Ethereum RPC behavior across deployment, monitoring, and ongoing operations.\nArc’s RPC layer is served by reth, and standard eth/web3/net JSON-RPC calls behave normally, including eth_getStorageAt proxy slot reads. Two RPC methods, eth_createAccessList and txpool_status, are not yet supported on the assessed endpoint, and the default gas cap on eth_call simulations has been lowered, which can affect very large simulated transactions; the trace_ and debug_ method namespaces both work, including full call tracing.\nRating: ★★★ Strong\n3.4 Account Format Compatibility\nCompatibility with Ethereum’s address, key, and execution model helps preserve the assumptions built into Aave contracts, wallets, and operational workflows.\nAccount and address formats are standard secp256k1 keys and twenty byte addresses, with no transformation that would affect wallets or other tooling. Arc does not enforce EIP-55 checksum casing at the protocol or node level, and a checksummed address submitted as input resolves to the same twenty byte address as its lowercase equivalent. Since node version v0.7.0, Arc’s own logs, metrics, and JSON-RPC responses intentionally render addresses in lowercase hex rather than checksummed form, a display convention that does not affect address validity or interoperability.\nRating: ★★★ Strong\n3.5 RPC Access & Providers\nReliable RPC access is required for Aave to function smoothly in production.\nAn official connection point for accessing Arc, and a separate one operated by Alchemy, a widely used blockchain infrastructure provider, were both confirmed active during this assessment. Multiple independent providers are otherwise engaged for Arc: QuickNode supplies the connection point in Safe’s official configuration, and dRPC, Blockdaemon, GetBlock, and MetaMask’s own infrastructure are also available for Arc.\nRating: ★★★ Strong\n3.6 Custom Execution Layer Behavior\nExecution layer differences need to be reviewed closely because Aave depends on predictable EVM behavior.\nArc’s chain identifier is unique, with no collision risk against another blockchain, and its smart contract environment fully supports the Ethereum software version Aave’s contracts are built for; testing found no missing capability, including SELFDESTRUCT support. The Solidity compiler settings the target Aave repos use, including the cancun EVM-version flag, are compatible with Arc without adjustment. Arc also layers a few additive capabilities on top of this standard environment: a CallFrom precompile (0x1800000000000000000000000000000000000003) that preserves the original caller’s identity, backing a dedicated Memo contract (0x5294E9927c3306DcBaDb03fe70b92e01cCede505) and a Multicall3From contract (0x522fAf9A91c41c443c66765030741e4AaCe147D0), a gas fee model denominated in USDC, and the native asset freeze list described in Section 3.15.\nTwo aspects of Arc’s block behavior differ from standard Ethereum’s, though neither has an impact on the Aave Protocol or Aave Governance. The PREVRANDAO value that would normally serve as a randomness source is fixed at zero, and block timestamps are non-decreasing rather than strictly increasing, so two blocks can potentially share the same timestamp.\nThe CallFrom precompile alters standard EVM msg.sender scoping. Calls routed through the Memo and Multicall3From contracts preserve the original caller’s msg.sender through subcalls, so the address observed downstream is the original caller rather than the intermediary contract; Arc’s documentation calls this out explicitly so that address based screening is not bypassed through batching. This does not have direct impact on the Aave protocol by itself.\nUSDC on Arc exists in two forms, a native version used for balances and gas payments and a familiar ERC-20 token version. A review of the Aave contracts already deployed on Arc found this split fully compliant with ERC-20 and verified compatible with the Aave protocol. The Aave protocol interacts exclusively with the ERC-20 form of USDC and does not hold, accept, or otherwise use the native form under any circumstances. A wrapper contract some Aave deployments use to accept the native asset directly is not needed on Arc, since the native and ERC-20 forms of USDC are treated as the same asset at the protocol level.\nStandard local test environments, such as a default Anvil or Hardhat setup, do not natively include Arc’s custom precompiles, so an eth_call simulation or local execution involving CallFrom or the native USDC precompiles can revert locally while succeeding on an Arc node. Foundry, the standard developer testing tool Aave normally relies on, is affected the same way: it cannot yet simulate Arc’s native USDC contract offline, so testing has relied on direct checks against the live network instead. arc-foundry and Arc specific testnet endpoints reproduce this behavior accurately.\nRating: ★★★ Strong\n3.7 Wallet Provider Support\nWallet support shapes whether users, delegates, service providers, and multisig signers can interact with the network through standard tooling.\nWallet support is broad, including hardware and institutional signing: Circle’s launch release names MetaMask, Ledger, Fireblocks, Binance Wallet, Kraken, and Upbit, with additional support noted for Privy, Turnkey, Dynamic, Rainbow, and Exodus. Ledger satisfies the hardware wallet requirement for high value signing, and Fireblocks covers institutional custody.\nRating: ★★★ Strong\n3.8 Transaction Monitoring\nAave requires clear transaction visibility after deployment to support monitoring, incident review, and operational response.\nBlockchain explorers, covered in Section 3.2, provide baseline transaction visibility on Arc. Hypernative support is available on top of this, including rules-based monitoring, business-rule deviations, threshold alerts, onchain monitoring, and fraud detection. Coverage is sufficient for risk operations and production oversight.\nRating: ★★★ Strong\n3.9 Onchain Multisig Infrastructure\nAave depends on established multisig infrastructure for administrative actions and emergency response.\nThe complete Safe multisig contract suite, together with every deployment tool Aave’s scripts require, is deployed onchain. Safe’s own configuration service officially supports Arc, including a dedicated, responding transaction service, so Aave’s protocol and governance multisig accounts can be operated through the official interface once deployed.\nRating: ★★★ Strong\n3.10 Transaction Simulation & Tenderly\nSimulation and fork tooling supports the way Aave tests upgrades, validates proposals, and reviews edge cases before execution on mainnet.\nTenderly’s transaction simulation support was confirmed functional during this assessment.\nRating: ★★★ Strong\n3.11 Bridging: Assets & Cross-Chain Messaging\nAave deployment readiness depends on functional governance execution and cross chain message delivery.\nCircle’s own cross chain transfer service (CCTP V2, TokenMessengerV2 at 0x28b5a0e9C621a5BadaA536219b3a228C8168cf5d, paired with MessageTransmitterV2 and TokenMinterV2) moves USDC between Arc and other networks by burning and reissuing it directly, rather than through a wrapped token. Two independently operated, two way messaging services, LayerZero and Wormhole, are live and verified on Arc’s real network: LayerZero’s EndpointV2 (0x6f475642a6e85809b1c36fa62763669b1b48dd5b) connects to 129 confirmed destinations, including a confirmed return path from Ethereum, backed by five independent verification providers, LayerZero Labs, Nethermind, Canary, Horizen, and P2P, alongside one older, deprecated LayerZero Labs verifier no longer in the active set; and Wormhole’s Core contract (0xC8aD24fC6063c41cB5C12a8e3851AafC3b3CF027) runs on guardian set 7, the same 19 guardians, byte-identical, as the current Ethereum mainnet guardian set. Wormhole’s standard automated relay service is not yet available on Arc, though its newer Executor contract is deployed and registered for Arc, so using the relay would need that newer delivery mechanism or a custom integration. Two independent messaging providers meet Aave’s assessed minimum for cross chain governance message delivery, but leave no room for a three provider setup, and Chainlink’s competing messaging service is available only on Arc’s test network, not the live one.\nRating: ★★☆ Acceptable\n3.12 Chain Data & Indexing\nData and indexing infrastructure supports the broader operating layer around Aave.\nThe Graph and Goldsky both register Arc mainnet for data indexing, though neither has been exercised with a live integration against it, and Dune has no Arc coverage. The execution layer behavior detailed in Section 3.6 must be considered when building indexing tooling for Arc. Regarding USDC specifically, Arc implements EIP-7708 and special care must be taken to avoid double counting asset movements. Because committed blocks are final with no reorganization risk (see Section 3.14), indexing and analytics tooling built for Arc needs no reorg handling logic, confirmation depth waiting, or rollback support.\nRating: ★★★ Strong\n3.13 Data Availability\nHigh throughput and rapid block production shape how much historical data a network can practically keep accessible, which affects Aave’s ability to reconstruct state and investigate past activity.\nArc is a standalone Layer 1: data availability rests entirely on its own validator and full node network, with no external data availability layer and no data posted to Ethereum. Full nodes are permissionless and can reconstruct state by replaying the chain, the practical state reconstruction path available today. Circle has not published a data retention or full node state reconstruction policy, so long term historical data guarantees remain undocumented.\nRating: ★★☆ Acceptable\n3.14 Transaction Lifecycle\nFor Aave, transaction lifecycle and RPC behavior matter most for liquidations, keeper infrastructure, and other latency sensitive operations.\nArc’s block times run about 0.506 seconds, with committed blocks final and no reorganization risk. Block timestamps are non-decreasing rather than strictly increasing, so consecutive blocks can carry the same timestamp; this was verified onchain across two consecutive blocks sharing an identical timestamp. Interest accrual logic used by the Aave contracts deployed on Arc handles this correctly, short circuiting when the last update timestamp equals the current block timestamp rather than reverting or double accruing, and reverting only if the last update timestamp exceeds the current block timestamp, a condition non decreasing time makes impossible. Deadline checks and access control delays elsewhere in the deployed contracts compare against the current timestamp with a less than or equal test, so same timestamp blocks do not affect them.\nRating: ★★★ Strong\n3.15 Network Security & Technical Model\nAave inherits the operating conditions of the underlying network into its own protocol risk.\nAt assessment, the onchain ValidatorRegistry (0x3600000000000000000000000000000000000002) recorded 15 active validators holding 26,000 total voting power under Arc’s permissioned proof of authority set, with the largest single validator holding 7.69%. Five validators holding 2,000 voting power each can halt finality, and nine can control more than two thirds of voting power; the founding institutions behind the set are named, but they are not mapped publicly to their onchain validator keys, and the operators of four validators are not publicly identified. Membership in the validator set is itself permissioned by the PermissionedValidatorManager (0x3600000000000000000000000000000000000003), and that control path was exercised onchain during the assessment window. Arc runs a single execution client (reth, version v1.11.3) and a single consensus client (Malachite); the latest arc-node release at assessment was v0.7.3 (20 July 2026). Arc is not a rollup, has no sequencer, forced inclusion mechanism, or permissionless exit path (see Section 3.14 for finality and block timing).\nArc’s system contracts, FiatToken (USDC, 0x3600000000000000000000000000000000000000), ProtocolConfig (0x3600000000000000000000000000000000000001), the ValidatorRegistry, the PermissionedValidatorManager, and a fifth system contract (0x3600000000000000000000000000000000000004), are transparent proxies whose proxy admin and owner roles all resolve to individually held keys rather than a multisignature account or a time delay, with no N-of-M signer set in any of the five upgrade paths; the PermissionedValidatorManager’s owner key, the one controlling who can join the validator set, was used to change validator membership during the assessment window. USDC’s own controls, including the blacklister role (0x2A2b7FF330F15F9A8c52af5Fec27D775f5138467) that can freeze an address, also rest with individually held keys, though the masterMinter role is implemented as a contract rather than a bare individually held key; since USDC is also the network’s gas asset, a freeze can stop an address transacting at all, not only moving USDC. Tracing this through Aave’s own contracts found a frozen borrower remains liquidatable and repayable by a third party, since neither action moves funds directly to or from the frozen address; a frozen liquidator, or a freeze on one of Aave’s own contracts, would be blocked from that action.\nCircle operates an active bug bounty program on HackerOne open to security researchers, scoped to issues materially affecting network safety, liveness, correctness or reliability, that has already surfaced and disclosed a denial of service finding in the consensus engine, evidence it sees real use. A dedicated technical incident response channel between Aave and the Arc team is being established.\nRating: ★☆☆ Concern\n3.16 Comparison with Similar Networks\nComparing Arc against networks already hosting Aave deployments puts its technical profile in context.\nArc’s closest comparable is a Tendermint style BFT Layer 1 with an Ethereum equivalent execution layer, not an optimistic or validity proof rollup, so the assumptions Aave typically applies to a Layer 2 do not transfer directly. Liveness risk is a validator coalition holding more than one third of voting power, not a single sequencer, and there is no forced inclusion path or Chainlink sequencer uptime feed to gate liquidations on; deterministic finality in well under a second removes reorganization risk entirely, which is stronger than any optimistic rollup’s confirmation window. Arc settles independently rather than to Ethereum, so all governance messaging depends on the third party providers assessed in Section 3.11, and USDC as the gas asset carries issuer freeze powers enforced at the protocol level rather than only within an ERC-20 contract. Concentration of consensus power among a small number of regulated institutions, with no permissionless exit, is a governance and legal risk profile distinct from any current Aave deployment.\nRating: ★★★ Strong\n4. Summary\nTechnical assessment of Arc for Aave deployments whose contracts target Cancun.\nArc reaches finality in well under a second with no risk of chain reorganizations, its smart contract environment is fully compatible with what Aave’s contracts require, Chainlink price feeds are live for a broad set of assets, and two independently operated cross chain messaging providers, LayerZero and Wormhole, are confirmed live on the real network. The result reflects conditions observed before public mainnet availability, including a validator setup that currently runs on a single software implementation, a messaging provider count at the assessed minimum, and a system upgrade and validator membership control model that currently rests on individually held keys rather than a multisignature account (see Section 3.15).\nFindings table\nRatings in this table use the same star notation as Section 3, matching the methodology in Section 2.\n\nArea\nKey finding\nRating\n\n3.1 Oracles\n28 Chainlink Data Feeds live onchain within heartbeat, including the AAVE Network Emergency Count feed\n★★★\n\n3.2 Blockchain explorer\nMainnet explorer confirmed functional, with the public test network explorer live and source verified\n★★★\n\n3.3 RPC standard compatibility\nStandard trace and debug tracing available; two RPC methods unsupported and the eth_call gas cap lowered\n★★★\n\n3.4 Account format compatibility\nStandard secp256k1 keys and addresses; lowercase rendering is a cosmetic difference only\n★★★\n\n3.5 RPC access & providers\nOfficial and third party connection points active\n★★★\n\n3.6 Custom execution layer behavior\nFull compatibility with Aave’s target software confirmed on the live network, with a few additional network specific features layered on top\n★★★\n\n3.7 Wallet provider support\nBroad wallet support including hardware and institutional signing\n★★★\n\n3.8 Transaction monitoring\nHypernative provides rules based monitoring, threshold alerts, and fraud detection coverage for Arc\n★★★\n\n3.9 Onchain multisig infrastructure\nFull Safe multisig suite deployed onchain, with official configuration service support for Arc\n★★★\n\n3.10 Transaction simulation & Tenderly\nTenderly mainnet support confirmed functional\n★★★\n\n3.11 Bridging: assets & cross-chain messaging\nCircle’s transfer service live for native asset bridging; two independent messaging providers meet the assessed minimum\n★★☆\n\n3.12 Chain data & indexing\nThe Graph and Goldsky register Arc mainnet but unexercised; USDC’s duplicate transfer records require indexing tools to adjust\n★★★\n\n3.13 Data availability\nNo external data availability layer; full nodes can reconstruct state by replaying the chain, but no data retention policy is published\n★★☆\n\n3.14 Transaction lifecycle\nDeterministic sub second finality; non-decreasing timestamps are handled correctly by the deployed interest accrual and deadline logic\n★★★\n\n3.15 Network security & technical model\nDeterministic finality on a single client validator stack, with system upgrade and validator membership control resting on individually held keys\n★☆☆\n\n3.16 Comparison with similar networks\nDeterministic finality and no sequencer exit path distinguish Arc from Aave’s typical Layer 2 deployments\n★★★\n\nDisclaimer\nAave Labs has no formal or informal affiliation with Circle or its contributors beyond this technical assessment. Aave Labs has not been compensated by Circle or any related party in connection with this work.\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Deploy Aave V4 on Arc\n\n AL Development Update | September 2026\n\n read \n\n 7\n min\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n Circle USD (USDC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 99\n\n Sep 18\n\n Circle EUR (EURC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 87\n\n Sep 18\n\n Wrapped Ether (WETH) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 170\n\n Sep 18\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 105\n\n Sep 18","tokens":5805,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261134505,"hash":"aaabb227e5c1317182ab6a56f02068fefcad41ad"}
{"url":"https://ethereum.org/guides/","domain":"ethereum.org","title":"Ethereum guides | ethereum.org","text":"Edit page (opens in a new tab)Do you want to start your Ethereum journey? Our practical guides lead you step-by-step on getting started, and make it easier to navigate this new technology.\nGetting started\n\nHow to \"create\" an Ethereum account - Anyone can create a wallet for free. This guide will show you where to begin.\n\nHow to use a wallet - Learn how to send and receive tokens in your wallet and how to connect wallet to projects.\n\nSecurity basics\n\nHow to revoke smart contract access to your crypto funds - If you suddenly see a transaction in your wallet that you did not initiate, this guide will teach you how to prevent that from happening again.\n\nHow to identify scam tokens - What are scam tokens? How do they make themselves look legitimate, and how do you identify them to protect yourself and avoid being scammed?\n\nUsing Ethereum\n\nHow to bridge tokens to layer 2 - Are Ethereum transactions too costly? Consider moving to Ethereum scaling solutions called layer 2s.\n\nHow to swap tokens - Do you want to exchange your tokens for a different one? This simple guide will show you how to do that.","tokens":277,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261140381,"hash":"c2a7d2674d5b32da293e0646bd889ccda2f93ee3"}
{"url":"https://dev-forum.pyth.network/t/real-time-oracle-intelligence-platform-paper-prediction-games/688","domain":"dev-forum.pyth.network","title":"Real-time Oracle Intelligence Platform + Paper Prediction Games - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Real-time Oracle Intelligence Platform + Paper Prediction Games \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 29\n\n 1 / 1\n\n Mar 29\n\n Mar 29\n\n post by 0xPilotSB on Mar 29\n\n 0xPilotSB\n\n DeltaScope\nTeam: @0xPilotSB\nSubmitted: 29 March, 2026\n\nAnswer Capsule\n\nDeltaScope is a real-time oracle intelligence platform + paper prediction game that monitors the gap between Pyth Network oracle prices and Hyperliquid DEX mark prices. It uses triple-source Pyth ingestion (dual Hermes WebSocket + REST polling) with Pyth Lazer ready for sub-50ms updates, an AI assistant with 6 Pyth-powered tools for querying 1,930+ price feeds, and a Predict & Win game where users bet on price direction using live Pyth oracle data — with confidence-aware settlement that refunds when oracle data is unreliable.\n\nWhat It Does\nOracle prices and DEX mark prices should match — but they don’t. The gap reveals liquidation risk, funding rate mechanics, and infrastructure health that most traders are blind to.\nDeltaScope gives traders real-time visibility into:\n\nOracle-mark spread — Real-time discrepancy between Pyth oracle prices and Hyperliquid mark prices across 8 major assets\nPyth publish delay analytics — How stale is your oracle data right now? Median publish delay tracked in a 10-min rolling buffer\nInfrastructure latency monitoring — Pyth Oracle Delay, Hyperliquid REST API latency, WebSocket delivery, and overall health score\nPredict & Win — Paper prediction game where users predict price direction (UP/DOWN) using live Pyth prices, with alarm-based settlement, streak bonuses, and a global leaderboard\nAI-powered analysis — Natural language queries across 1,930+ Pyth price feeds with 6 structured tools\n\nThis is the layer beneath the prices that nobody else shows.\n\nPyth Features Used\nCheck all that apply:\n\n Price Feeds (on-chain or off-chain)\n Entropy (randomness)\n Both\n\nLinks\n\nLive Demo: https://deltascope.site\nSource Code: GitHub - 0xPilotSB/deltascope: Real-time Pyth Oracle & Hyperliquid market intelligence dashboard — oracle discrepancy monitoring, latency analysis, funding rates, and AI-powered market chat · GitHub\n\nScreenshots / Media\nScreenshot 2026-03-28 at 20.40.201920×1150 194 KBScreenshot 2026-03-28 at 20.46.062936×1604 306 KBScreenshot 2026-03-28 at 20.40.481920×1039 239 KBScreenshot 2026-03-28 at 20.44.591920×1051 180 KBScreenshot 2026-03-28 at 20.42.011920×882 209 KBScreenshot 2026-03-28 at 20.43.322936×1592 459 KB\n\nTech Stack\n\nFramework/Language: React Router 7 (TypeScript), Vite, Tailwind CSS 4, shadcn/ui\n\nBlockchain (if applicable): Hyperliquid (Not Yet Deployed, Still ongoing on my mind usecase)\n\nAgent Framework (if applicable): Vercel AI SDK + Cloudflare Workers AI (6 structured Pyth tools with codemode)\n\nDeployment: Cloudflare Workers + 4 Durable Objects (edge-deployed, 24/7 uptime via DO alarms, Smart Placement\n\nContent Contributions\n\nPublic Post (Dev.to): Real-time oracle intelligence platform + paper prediction game - DEV Community\n\nBonus — X Platform Post: https://x.com/0xPilotSB/status/2037896631685955592?s=20\n\nLicensing\nThis project is licensed under Apache 2.0\n\nEligibility Confirmation\n\n I am 18+ years old\n I am not located in an OFAC-sanctioned jurisdiction\n I confirm this is an original work created during the hackathon period\n I have read and agree to the Terms & Conditions\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Royale - A price prediction game built on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 44\n\n Mar 24\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 28\n\n PyPredict — Real-Time Prediction Markets on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 32\n\n Mar 31\n\n The Market Witness\n\n Pyth Community Hackathon\n\n 11\n\n 163\n\n Mar 27\n\n Pyth Insight Oracle Intelligence Platform (CI Calibration · Entropy Game · AI Analyst)\n\n Pyth Community Hackathon\n\n 0\n\n 33\n\n Mar 23\n\n Powered by Discourse","tokens":1882,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261140757,"hash":"f6b8591c3f047243894c426af20b09e7c7f398fa"}
{"url":"https://forum.openzeppelin.com/c/smart-contracts/39","domain":"forum.openzeppelin.com","title":"Latest Smart Contracts topics - OpenZeppelin Forum","text":"Latest topics in Smart Contracts\n\n Smart Contracts\n\n Ask for help with smart contract development and discuss related topics. NOTE: If you want help from OpenZeppelin staff, post in #Support!\n\n Smart Contracts\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Guides and Tutorials\n\n Guides, tutorials, how-tos and any other educational content.\n\n Showcase\n\n Showcase your projects to the community.\n\n Developer Wanted\n\n Post requests for freelance work. OpenZeppelin does not endorse participants. Always conduct due diligence.\n\n Review Wanted\n\n Ask the community to informally review your code. NOT A SUBSTITUTE FOR A PROFESSIONAL AUDIT.\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Smart Contracts category\n\n Smart Contracts\n\n Ask for help with smart contract development and discuss related topics. NOTE: If you want help from OpenZeppelin staff, post in #Support!\n\n 3\n\n 2.3k\n\n Oct 2025\n\n 0.1% transfer tax on an ERC-20 token with 0 decimals?\n\n Smart Contracts\n\n erc20\n\n 0\n\n 22\n\n 4d\n\n ERC-20 token logo and project URL not showing on PulseChain Explorer\n\n Smart Contracts\n\n 0\n\n 19\n\n 8d\n\n Mitigating Inflation Attacks on an ERC-4626 Freelance Escrow Vault Routing Idle Capital to Aave v3\n\n Smart Contracts\n\n erc20,etherscan-verify,solidity\n\n 0\n\n 34\n\n 18d\n\n Example/Tutorial for migrating data from prev version to next version of a smart contract\n\n Smart Contracts\n\n upgrades,dev-update\n\n 0\n\n 54\n\n Sep 1\n\n What is a sufficient test suite to rely on a contract’s upgradeability status?\n\n Smart Contracts\n\n upgrades\n\n 1\n\n 155\n\n Sep 1\n\n Can you create a BEP20 contract for small fee?\n\n Developer Wanted\n\n bep20\n\n 9\n\n 1.5k\n\n Aug 2\n\n Sending and receiving digital currencies\n\n Developer Wanted\n\n bep20\n\n 1\n\n 55\n\n Jun 29\n\n How can we fix phantom ban issue\n\n Smart Contracts\n\n 1\n\n 51\n\n Jun 21\n\n Usdt.z contract 21f Token\n\n Smart Contracts\n\n 1\n\n 158\n\n Jun 21\n\n Deploy a simple ERC20 token in Remix\n\n Guides and Tutorials\n\n 22\n\n 53.4k\n\n Jun 20\n\n I accidentally sent my LP Tokens to Contract Address\n\n Smart Contracts\n\n 0\n\n 113\n\n May 20\n\n Smart contract activation\n\n Smart Contracts\n\n 1\n\n 94\n\n Mar 6\n\n Ethernaut Community Solutions\n\n Guides and Tutorials\n\n ethernaut\n\n 8\n\n 15.3k\n\n Feb 20\n\n InvariantGuard : A framework to make DELEGATECALL safer\n\n Smart Contracts\n\n 0\n\n 73\n\n Feb 11\n\n ReentrancyGuardUpgradeable still relavant in upgradable contracts?\n\n Smart Contracts\n\n proxies\n\n 2\n\n 601\n\n Jan 18\n\n AccessManagedProxy: is a good idea?\n\n Smart Contracts\n\n 6\n\n 316\n\n Dec 2025\n\n Upgradable init chainned/unchainned logic\n\n Smart Contracts\n\n erc1155\n\n 0\n\n 50\n\n Nov 2025\n\n Changing/Adding Base Contract (V2)\n\n Smart Contracts\n\n erc20,upgrades\n\n 0\n\n 46\n\n Nov 2025\n\n Designing a Secure USDC-Based Raffle Contract\n\n Smart Contracts\n\n erc20\n\n 2\n\n 121\n\n Nov 2025\n\n Simple ERC20 token fees\n\n Guides and Tutorials\n\n erc20,bep20,solidity\n\n 15\n\n 9.3k\n\n Nov 2025\n\n Help with tax on my contract\n\n Smart Contracts\n\n 2\n\n 65\n\n Nov 2025\n\n Using both ownable and Ownable2step in a abstract contract\n\n Smart Contracts\n\n 4\n\n 348\n\n Nov 2025\n\n What happens if storage __gap is placed in at the beginning and not the end of a contract?\n\n Smart Contracts\n\n upgrades\n\n 0\n\n 60\n\n Oct 2025\n\n How to recover funds from a scam contract\n\n Smart Contracts\n\n 1\n\n 219\n\n Oct 2025\n\n Introduction to the Diamond Standard, EIP-2535 Diamonds  substack.com\n\n Guides and Tutorials\n\n proxies,upgrades,design\n\n 12\n\n 8.9k\n\n Oct 2025\n\n Uniswap V4 Hook Liquidity Not Stored in Hook Contract\n\n Smart Contracts\n\n 1\n\n 274\n\n Oct 2025\n\n Size of file extending in openZeppelin governance contract taken from Wizard\n\n Smart Contracts\n\n 4\n\n 95\n\n Sep 2025\n\n How to add the developer’s wallet, the marketing wallet in the smart contract\n\n Smart Contracts\n\n erc20\n\n 7\n\n 1.1k\n\n Sep 2025\n\n EIP-7702 Generic Smart Contract for transaction bundling\n\n Smart Contracts\n\n 1\n\n 352\n\n Aug 2025","tokens":962,"squid":"ink-security_audits","role":"Sentinel","at":1791261147255,"hash":"90c2e1e9587f1f4744a43c46690bf719c098147e"}
{"url":"https://ethereum.org/guides/how-to-use-a-wallet/","domain":"ethereum.org","title":"How to use Ethereum Wallets | Step by Step | ethereum.org","text":"Edit page (opens in a new tab)Learn how to operate all the basic functions of a wallet. If you don’t have one yet, check out our How to create an Ethereum account.\nOpen your wallet\nYou should see a dashboard that will likely show your balance and contain buttons to send and receive tokens.\nReceive cryptocurrency\nDo you want to receive crypto into your wallet?\nEach Ethereum account has its own receiving address which is a unique sequence of numbers and letters. The address functions like a bank account number. Ethereum addresses will always start with “0x”. You can share this address with anyone: it is safe to do so.\nYour address is like your home address: you need to tell people what it is so they can find you. It is safe to do this, because you can still lock your front door with another key only you control so that no-one can get in, even if they know where you live.\nYou need to provide whoever wants to send you money with your public address. Many wallet apps let you copy your address or show a QR code to scan for easier usage. Avoid typing any Ethereum address manually. This can easily lead to clerical errors and lost funds.\nDifferent apps may vary or use different language, but they should take you through a similar process if you are trying to transfer funds.\n\nOpen your wallet app.\nClick on \"Receive\" (or similarly worded option).\nCopy your Ethereum address to clipboard.\nProvide the sender with your receiving Ethereum address.\n\nSend cryptocurrency\nWould you like to send ETH to another wallet?\n\nOpen your wallet app.\nGet the receiving address and make sure you are connected to the same network as the recipient.\nEnter the receiving address or scan a QR code with your camera so that you don’t have to write the address manually.\nClick on a “Send” button in your wallet (or a similarly worded alternative).\n\nMany assets, like DAI or USDC, exist on multiple networks. When transferring crypto tokens, make sure that the recipient is using the same network as you are, since these are not interchangeable.\nEnsure that your wallet has sufficient ETH to cover the transaction fee, which varies depending on network conditions. Most wallets will automatically add the suggested fee to the transaction which you can then confirm.\nOnce your transaction is processed, the corresponding crypto amount will show up in the recipient’s account. This might take anywhere from a few seconds to a few minutes depending on how much the network is currently being used.\n\nConnecting to projects\nYour address will be the same in all Ethereum projects. You do not need to register individually on any project. Once you have a wallet, you can connect to any Ethereum project without any additional information. No emails or any other personal information are needed.\n\nVisit any project’s website.\nIf the project's landing page is just a static description of the project, you should be able to click on an \"Open the App\" button in the menu which will navigate you to the actual web app.\nOnce you are in the app click on “Connect”.\n\nSelect your wallet from the provided options list. If you can't see your wallet, it may be hidden under the “WalletConnect” option.\n\nConfirm the signature request in your wallet to establish the connection. Signing this message should not require spending any ETH.\nThat's it! Start using the app. You can find some interesting projects on our dApps page.\n\nWant to learn more?See our other guides\nFrequently asked questions\nIf I own an ETH address, do I own the same address on other blockchains?\nYou can use the same address on all EVM compatible blockchains (if you have the type of wallet with a recovery phrase). This list (opens in a new tab) will show you which blockchains you can use with the same address. Some blockchains, like Bitcoin, implement a completely separate set of network rules and you will need a different address with a different format. If you have a smart contract wallet you should check its product website for more info on which blockchains are supported.\nCan I use the same address on multiple devices?\nYes, you can use the same address on multiple devices. Wallets are technically only an interface to show you your balance and to make transactions, your account isn't stored inside the wallet, but on the blockchain.\nI have not received the crypto, where can I check the status of a transaction?\nYou can use block explorers to see the status of any transaction in real time. All you need to do is to search your wallet address or the ID of the transaction.\nCan I cancel or return transactions?\nNo, once a transaction is confirmed, you cannot cancel the transaction.","tokens":1159,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261154350,"hash":"b56bcd9a10b353b2f7cb7e8cd79541b4a97afc06"}
{"url":"https://forum.openzeppelin.com/t/about-the-smart-contracts-category/13235/10","domain":"forum.openzeppelin.com","title":"About the Smart Contracts category - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2021\n\n 4 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by frangio on Jul 29, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Ask for help with smart contract development and discuss related topics. NOTE: If you want help from OpenZeppelin staff, post in #Support!\n\n 2 years later\n\n post by Quinn on Aug 3, 2023\n\n Quinn\n\n Hello what are the steps for trading on uniswap, rocketswap, sushiswap\nWhat about the router addresses of the Dexes should they be change in the contract\nI have a contract where I have the function for router, enable and taxes, bot tax, 3 dead blocks\nWhat are the steps to go live for trading?\nI can’t add liquidity on dexes\n\n 4 months later\n\n post by MarsNext on Nov 26, 2023\n\n MarsNext\n\n Are you going to use v2 or v3?\n\n 2 years later\n\n post by favour_odoyo on Oct 6, 2025\n\n favour_odoyo\n\n please how do i use solidity to limit a certain amount of token purchased by a single address at a time?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Liquidity, trading, Bot Tax, deadblocks\n\n Smart Contracts\n\n erc20\n\n 15\n\n 939\n\n Jul 2025\n\n Made a Safemoon copy, but used V2 router adress\n\n Smart Contracts\n\n 2\n\n 602\n\n Dec 2021\n\n Review and understanding standard functions of smart contract code\n\n Contracts\n\n 2\n\n 1.4k\n\n Jan 2022\n\n Normal DEX web3 pattern to use in project\n\n Smart Contracts\n\n 0\n\n 261\n\n Feb 2022\n\n Learn how to write a contract\n\n Smart Contracts\n\n bep20\n\n 1\n\n 531\n\n Feb 2022","tokens":383,"squid":"ink-security_audits","role":"Sentinel","at":1791261157384,"hash":"d6f7b3e75cf7719a8cb6249770aba39632bd7d68"}
{"url":"https://ethereum.org/learn/","domain":"ethereum.org","title":"Ethereum: A Comprehensive Learning Guide | ⁦ethereum.org⁩","text":"Understand EthereumCryptocurrencies, such as bitcoin, enable anyone to transfer money globally. Ethereum does that too, but it can also run code that enables people to create apps and organizations. It's both resilient and flexible: any computer program can run on Ethereum. Learn more and find out how to get started:What is Ethereum?Understand what makes Ethereum special and how it differs from other technologies.Start hereWhat is ether (ETH)?Understand Ethereum's native currency ether (ETH) and how it powers the network.Learn about ETHEthereum vs BitcoinUnderstand the differences between Ethereum and Bitcoin and what each is designed to do.Compare the twoKeep learningWhat is the Ethereum network?Understand how the Ethereum network works: nodes, validators, and how transactions are processed.Explore the networkWhat is Web3?An alternative to centralized monopolies dictating the rules of the internet.Discover Web3Smart contractsThe fundamental building blocks of the Ethereum ecosystem.How they workMore on Ethereum basicsWhy Ethereum exists: the principles it is built onGuides: step-by-step instructions on using EthereumQuiz hub: test your knowledgeMore on Ethereum: history, founder and ownershipEthereum in 30 minutes by Vitalik Buterin (opens in a new tab)How do I use Ethereum?Using Ethereum can mean lots of things to lots of people. Maybe you want to sign in to an app, prove your online identity, or transfer some ETH. The first thing you'll need is an account. The easiest way to create and access an account is using software called a wallet.Ethereum walletsAn app to interact with your Ethereum account, manage funds, and connect to applications.Learn about walletsFind a walletBrowse wallets based on the features that matter to you.List of walletsGet ETHBuy or earn ether (ETH) so you can use Ethereum applications and send transactions.How to get ETHKeep learningStakingEarn rewards and help secure the network by staking your ETH.Ways to stakeLayer 2 networksNetworks built on Ethereum that make transactions faster and cheaper.What is layer 2?Community storiesHow people around the world are using Ethereum in their daily lives.Read the storiesMore on using EthereumHow to create an Ethereum accountHow to use a walletStaying safe: security and scam preventionGas and transaction fees explainedWhere to get help and supportWhat is Ethereum used for?Ethereum has led to the creation of new products and services that can improve different areas of our lives. From financial tools and digital ownership to governance and science, there is a growing list of use cases.How Ethereum worksExplore the technical side of the Ethereum protocol.Ethereum roadmapEthereum's roadmap makes it more scalable, secure, and sustainable.Explore the roadmapEthereum WhitepaperThe original Ethereum proposal written by Vitalik Buterin in 2014.Read whitepaperPrivacy on EthereumLearn about privacy tools and techniques for protecting your data on Ethereum.Explore privacyMore on the Ethereum protocolEnergy consumptionEthereum for developersEthereum's proof-of-stake based consensus mechanismEthereum's embedded computer (The EVM)Ethereum nodes and clientsBooks, podcasts, and series about EthereumBooksThe Cryptopians (opens in a new tab) - February 22, 2022 - Laura ShinOut of the Ether (opens in a new tab) - September 29, 2020 - Matthew LeisingThe Infinite Machine (opens in a new tab) - July 14, 2020 - Camila RussoMastering Ethereum (opens in a new tab) - December 23, 2018 - Andreas M. Antonopoulos, Gavin Wood Ph.D.Proof of Stake (opens in a new tab) - September 13, 2022 - Vitalik Buterin, Nathan SchneiderPodcastsGreen Pill (opens in a new tab) - Explores the crypto-economic systems that create positive externalities for the worldZero Knowledge (opens in a new tab) - Goes deep into the tech that will power the emerging decentralized web and the community building thisUnchained (opens in a new tab) - Dives deep into the people building the decentralized internet, the details of this technology that could underpin our future, and some of the thorniest topics in crypto, such as regulation, security and privacyThe Daily Gwei (opens in a new tab) - Ethereum news recaps, updates and analysisBankless (opens in a new tab) - A guide to Crypto financeVideo seriesEthereum Basics (opens in a new tab) - Learn the basics of Ethereum network architecture with an easy-to-understand video series.","tokens":1103,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261164361,"hash":"17712db4fe471bf9de0b8019f7e3fadf34e561d2"}
{"url":"https://dev-forum.pyth.network/t/real-time-oracle-intelligence-platform-paper-prediction-game/671/3","domain":"dev-forum.pyth.network","title":"Real-time oracle intelligence platform + paper prediction game - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 28\n\n 3 / 3\n\n Mar 28\n\n Mar 28\n\n post by 0xPilotSB on Mar 28\n\n 0xPilotSB\n\n (topic deleted by author)\n\n Unlisted on Mar 28\n\n Listed on Mar 29\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Ouroboros — Describe a Game, Get a Deployed Pyth dApp (AI AGENT)\n\n Pyth Community Hackathon\n\n 0\n\n 49\n\n Apr 1\n\n Real-time Oracle Intelligence Platform + Paper Prediction Games\n\n Pyth Community Hackathon\n\n 0\n\n 36\n\n Mar 29\n\n PyPredict — Real-Time Prediction Markets on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 32\n\n Mar 31\n\n Price Royale - A price prediction game built on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 44\n\n Mar 24\n\n Powered by Discourse","tokens":1101,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261164593,"hash":"b922b9bd3ea2325b0c9cc74cc4e0a59593a372ec"}
{"url":"https://forum.openzeppelin.com/t/made-a-safemoon-copy-but-used-v2-router-adress/20280/3","domain":"forum.openzeppelin.com","title":"Made a Safemoon copy, but used V2 router adress - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2021\n\n 3 / 3\n\n Dec 2021\n\n Dec 2021\n\n post by Coffetron on Dec 4, 2021\n\n Coffetron\n\n I deployed a smart contract through “remix.ethereum” and then I`m trying to find my token in pancakeswap. I changed the router to V2 in contract. Is that the problem? Is it possible to change it to V1 router, or are there other solutions?\nThanks\n\n 2\n\n post by FreezyEx on Dec 5, 2021\n\n FreezyEx\n\n You have to add liqudiity first.\n\n post by Coffetron on Dec 5, 2021\n\n Coffetron\n\n Thanks for reply, I cant add liquidity either. Cant find my token when I put the contract adress in..\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to fix Pancakeswap’s Router address in Safemoon\n\n Guides and Tutorials\n\n safemoon\n\n 100\n\n 31.9k\n\n May 2023\n\n Pancakeswap V2 Liquidity in V1 Contract\n\n Support\n\n 2\n\n 644\n\n Jun 2021\n\n LP Going To 0x07d80ae6f36a5e08dca74ce884a24d39db9934ed\n\n Contracts\n\n 1\n\n 1.7k\n\n May 2021\n\n Problem with removing liquidity despite changing uniswapv2router address into the new one\n\n Support\n\n 0\n\n 552\n\n May 2021\n\n Im not sure what I did?\n\n General\n\n 11\n\n 3.2k\n\n Jun 2021","tokens":304,"squid":"ink-security_audits","role":"Sentinel","at":1791261167549,"hash":"6441dd881b8e06cf30d44f89e80add79eaf5c4c6"}
{"url":"https://ethereum.org/what-is-ether/","domain":"ethereum.org","title":"What is Ether (ETH)? (A complete guide) | ⁦ethereum.org⁩","text":"Ether, commonly known as ETH, is the fuel that powers the Ethereum blockchain. Unlike bitcoin, which primarily serve as digital money, ether has multiple uses within the Ethereum ecosystem.As Ethereum's native cryptocurrency, ETH is used to:Pay transaction fees (gas) for using the network and its applicationsSecure the Ethereum network through stakingETH was introduced in 2015 as part of Ethereum's launch and has since grown to become one of the most valuable assets in the world (opens in a new tab).For consumersETH enables global payments without banks, purchases of non-fungible tokens (NFTs), and access to decentralized finance (DeFi) apps. It's censorship resistant with 24/7 cross-border functionality.For developersETH pays for transaction fees when deploying smart contracts to the Ethereum mainnet. It's also the primary currency used within many applications in the Ethereum ecosystem.For investorsETH functions as a store of value and yield-generating asset through staking. It provides exposure to web3 growth and the expanding digital economy.Learn more about ETH staking How to buy ETHBuying ETH is straightforward with several options based on your needs and location. Always start with a trusted platform offering strong security.For consumers, buy ETH through cryptocurrency exchanges or wallet apps.SidenoteWhen buying ETH you'll hear \"account/address\" and \"wallet\".Think of your account like your email address where people send you money.Think of your wallet like your email app where you check balances and make payments.You can purchase ETH with:Credit/debit cards instantly but with higher feesBank transfers slower but with lower feesPayPal or similar services where availableFor businesses, exchanges offer corporate accounts with higher limits, better support, compliance features, volume discounts, and enhanced security.Other ways to get ETH:Receive payments from people you knowProvide liquidity on decentralized finance protocolsStake ETH to earn rewards while securing the Ethereum networkLearn more about how and where to buy ETH How to send and receive ETHSending ETH requires a wallet and recipient address. Enter their address, specify the amount, review the transaction fee, and confirm. Transactions typically arrive in under 30 seconds and cannot be reversed once confirmed.Receiving ETH requires sharing your Ethereum address or QR code with the sender. Funds appear in your wallet after network confirmation, with most wallets providing notifications.Need help? Read the How to use a wallet guide.SidenoteOnly share your Ethereum address with trusted contacts. Since Ethereum is a public ledger, they can view your balance and transactions. They can't access your funds but privacy is recommended.For larger amounts, consider hardware wallets for added security.Learn about Ethereum and how it works. How long does it take to send ETH?ETH transactions typically complete in under 30 seconds. The Ethereum network processes blocks every 12 seconds, though transactions may queue during congestion.Transactions achieve 'finality' after ~15 minutes, compared to Bitcoin's 60-minute average.During high network traffic, you can speed up transactions by paying higher transaction fees, placing you ahead in line. Fees are split between validators and a burning mechanism.How much does it cost to send ETH?Ethereum transactions require transaction fees paid in ETH. The fee is calculated based on the computational work required (measured in 'gas'), and the network's current demand. The price of gas fluctuates with network traffic, making transactions lower-cost during off-peak periods.Transaction typeLive cost rangeEstimated gas unitsETH transfers$0.01221,000 gasSwapping tokens$0.073 - $0.087100,000 - 150,000 gasComplex DeFi/NFT transactions$0.12 - $0.29200,000 - 500,000 gasEnter L2s: Scaling EthereumAs Ethereum's popularity grows, keeping transaction fees low becomes challenging. Layer 2 (L2) networks address this issue.L2s like Optimism (opens in a new tab) and Arbitrum (opens in a new tab) offer 10-100x cheaper fees while inheriting Ethereum's security. They process transactions offchain and post data to Ethereum.Think of them as express lanes that provide faster, cheaper transactions alongside Ethereum's main highway.L2 transfers typically cost less than $0.01, bringing Ethereum to millions more users through integrations with companies like Robinhood, PayPal, and Shopify.What is the ETH supply?Unlike Bitcoin's fixed 21 million cap, ETH has dynamic supply mechanics:New ETH is issued to reward network validators at a limited rate calculated by the protocolA portion of every transaction fee is permanently \"burned\" (deleted from existence)This creates alternating periods of inflation and deflation based on network usageExpected equilibrium: The system balances network security with long-term value preservation. High usage leads to deflation; low usage results in inflation.Data sources: Etherscan (opens in a new tab), Ultrasound Money (opens in a new tab)What is the distribution of ETH?Ownership is widely distributed across tens of millions of addresses (opens in a new tab), preventing concentration of control and enhancing decentralization.A breakdown of ether distributionStaked ether: Tens-of-millions of ETH locked (opens in a new tab) for network securityExchanges: Centralized platforms hold 13-16% (opens in a new tab) of supplySmart contracts: Significant amounts in smart contracts including DeFi protocolsEthereum Foundation: Holds less than 0.3% (opens in a new tab) of supply (down from 9% in 2014)Who holds the most?The Ethereum addresses with the highest ETH balances are typically not individuals. The vast majority of ether visible in the \"top\" Ethereum addresses represents the collective, pooled funds of many different people and entities, not the holdings of a single individual. The highest-balance ETH accounts typically include:The Beacon Chain Deposit Contract: The deposit contract's balance represents all of the ETH that has been staked to help secure the Ethereum network. While this is the Ethereum address with the largest ETH balance, it does not represent an accessible Ethereum wallet account. It is a smart contract that accepts deposits of ETH as the first step to participate in staking, then manages the balances of that ether across the network's active validators.Smart contracts: Many of the other high-balance Ethereum addresses represent the smart contracts that power Ethereum-based applications, such as the smart contract addresses for decentralized finance (DeFi) protocols, bridges, or decentralized autonomous organizations (DAOs). These contract balances represent the ether that many wallets have deposited to participate in their application.Omnibus accounts: These are large wallets operated by exchanges, platforms, and funds (like Coinbase, Robinhood, or Binance). When a user buys ETH on an exchange, it's often held in one of these massive accounts alongside the ETH held by thousands of the platform's other customers.You can view a live list of the Ethereum wallet addresses with the highest ETH balances on Etherscan here (opens in a new tab).Why distribution matters for decentralizationWide distribution prevents centralized control. True decentralization depends on the number of independent nodes and validators maintaining the network.What makes ETH valuable?ETH derives value from multiple sources:Network utility: All Ethereum transactions require ETH for gas fees, creating consistent demand that grows with network adoption.Staking rewards: ETH stakers earn yields while securing the network, appealing to both individual and institutional investors.Store of value: Many view ETH as \"digital oil\"—a scarce asset with real utility powering the digital economy.Supply dynamics: Fee burning creates deflationary pressure during high usage periods. Since 2021, millions of ETH have been permanently removed (opens in a new tab) from circulation.What is wrapping ETH?Wrapped ETH (WETH) is an ERC-20 token that represents ETH on a 1:1 basis. Many decentralized apps and L2 networks are built to handle ERC-20 tokens, but native ETH itself is not an ERC-20 token. ‘Wrapping' means locking ETH in a smart contract, and issuing an ERC-20 representation of that locked ETH (WETH), allowing it to be used across any apps and L2s that can only accept ERC-20 tokens.Common uses include:Trading pairs on decentralized exchanges like Uniswap (opens in a new tab)Collateral on lending platforms like Aave (opens in a new tab)Bidding on NFT marketplaces like OpenSea (opens in a new tab)WETH can be unwrapped back to ETH anytime with minimal fees. The WETH is destroyed, and the ETH it represented is released from the smart contract. Most applications handle the wrapping and unwrapping process seamlessly.Learn more about Wrapped ETH (WETH) Test your Ethereum knowledgeWhat is ether (ETH)?Question number 1:Compared with Bitcoin's fixed cap of 21 million coins, the supply of ETH:","tokens":2252,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261174587,"hash":"2c2f52bd67ce54e5a12467f59896c0d8cde02406"}
{"url":"https://dev-forum.pyth.network/t/ouroboros-describe-a-game-get-a-deployed-pyth-dapp-ai-agent/730","domain":"dev-forum.pyth.network","title":"Ouroboros — Describe a Game, Get a Deployed Pyth dApp (AI AGENT) - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Ouroboros — Describe a Game, Get a Deployed Pyth dApp (AI AGENT) \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 1\n\n 1 / 1\n\n Mar 31\n\n Apr 1\n\n post by pstar on Apr 1\n\n pstar\n\n Project Name: Ouroboros\nTeam: pstar\nSubmitted: April 1, 2026\n\nAnswer Capsule\nOuroboros is an autonomous AI coding agent that builds Pyth-powered mini-games from plain English descriptions. It uses Pyth Price Feeds via the Hermes API for real-time asset pricing in prediction and trading games, and Pyth Entropy for verifiable on-chain randomness in dice, card, and loot-drop games — deploying smart contracts to Base Sepolia and frontends to Netlify, all through a chat interface.\n\nWhat It Does\nMost developers face a steep learning curve when building on-chain games that use real-world data or verifiable randomness. Ouroboros eliminates that barrier entirely. A user describes a game idea in plain English — “build me a coin flip game using ETH price” — and an AI agent autonomously writes the smart contracts, builds the frontend, integrates Pyth feeds, and deploys everything live. No Solidity knowledge required. No React experience needed. Just an idea and a chat window.\nThe agent operates through a ReAct (Reasoning + Acting) loop: it thinks about what to do, executes tools (writes files, runs terminal commands, fetches Pyth data, deploys contracts), observes the results, and iterates — all streamed to the user in real time.\n\nPyth Features Used\n\n Price Feeds (on-chain/off-chain via Hermes API)\n\n Entropy (on-chain verifiable randomness)\n\n Both\n\nPrice Feeds: The agent uses Pyth Hermes API (hermes.pyth.network) to fetch real-time prices for any supported asset. When building games, it integrates price data directly into frontends and smart contracts — enabling prediction markets, trading simulators, price-reactive gameplay mechanics, and more. The agent has built-in tools for price fetching, feed discovery, candlestick (OHLC) data, and historical price lookups.\nEntropy: For games requiring randomness (dice rolls, card draws, loot drops, coin flips), the agent deploys Solidity contracts to Base Sepolia that integrate with the Pyth Entropy contract at 0x4821932D0CDd71225A6d914706A621e0389D7061. Contracts implement the IEntropyConsumer interface for callback-based verifiable randomness — ensuring fair, tamper-proof outcomes on-chain.\n\nLinks\n\nLive Demo: https://ouroborospyth.netlify.app/\n\nBackend API: https://ouroboros.fit\n\nSource Code (Backend): GitHub - thierbig/ouroboros-backend · GitHub\n\nSource Code (Frontend): GitHub - thierbig/ouroboros-frontend · GitHub\n\nScreenshots/Media\ncoinflip2492×1320 278 KB\n\nTech Stack\n| Layer | Technology |\n|-------|-----------|\n| Backend Framework | Python, FastAPI, Uvicorn |\n| Frontend Framework | Nuxt 3, Vue 3, TypeScript |\n| Styling | Tailwind CSS, Nuxt UI 3 |\n| Database | MongoDB Atlas (async via Motor) |\n| LLM Providers | Anthropic Claude, OpenAI GPT |\n| Blockchain | Solidity, Foundry, Base Sepolia |\n| Pyth Integration | Hermes API (prices), Entropy (randomness), MCP Server (feed discovery) |\n| Deployment | Netlify (frontend + generated games), VPS with nginx + systemd (backend) |\n| Charts | ApexCharts |\n\nHow It Works\n\nCreate a project — Pick a template: Entropy Game (on-chain randomness), Price Game (live Pyth feeds), or Custom Game\n\nDescribe your game — Chat with the agent: “Build a dice game where the payout multiplier is based on the current ETH/USD price”\n\nWatch it build — The agent writes smart contracts, builds a React frontend, installs dependencies, integrates Pyth, and deploys — all streamed live\n\nPlay your game — Click the live preview link to play the deployed game immediately\n\nIterate — Keep chatting to add features, tweak mechanics, or redeploy\n\nThe agent has 10 specialized tools:\n\nFile operations: read, write, patch, search\n\nTerminal: execute shell commands with streaming output\n\nPyth tools: price fetching, feed search, candlestick data, historical prices, contract deployment\n\nEach tool call is visible in the activity log so users can follow along and learn how their game is being built.\n\nHow to Use It (For Judges)\n\nEnter your own Anthropic API key (Claude) in the header bar — select Claude Sonnet\nCreate a new project — pick any template (Entropy Game, Price Game, or Custom)\nDescribe your game idea in the chat, e.g. “Build a coin flip game where the payout is based on the current ETH price”\nWait for the agent to finish — it may appear stuck at times (especially during installs or deploys) but it will recover and continue. Give it a couple minutes before retrying.\nOnce done, click the live preview link to play your deployed game.\nDon’t be shy to tell the agent that the live preview did not work correctly and continue fixing deployment\n\nTip: The agent works best with Claude Sonnet. If it seems unresponsive for 30+ seconds, the stuck detection will kick in — you can either wait for it to self-recover or hit “Force Stop” and send a follow-up message like “continue where you left off.”\n\nContent Contributions\n\nReddit post: https://www.reddit.com/r/ethdev/s/nCGp2Od5Hm\n\nLicensing\nThis project is licensed under Apache 2.0.\n\nEligibility Confirmation\n\n I am 18 years of age or older\n\n I am not located in an OFAC-sanctioned territory\n\n This is original work created during the hackathon period\n\n I agree to the Terms & Conditions\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 28\n\n Price Royale - A price prediction game built on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 44\n\n Mar 24\n\n Pyth Arcade - Onchain Arcade Retro Powered by Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 34\n\n Mar 31\n\n Coindle - daily crypto guessing game\n\n Pyth Community Hackathon\n\n 0\n\n 49\n\n Mar 31\n\n Oracle Gym - Gamified trading arena by PythNetwork - learn with real-time oracle\n\n Pyth Community Hackathon\n\n evm,entropy\n\n 0\n\n 40\n\n Mar 30\n\n Powered by Discourse","tokens":2388,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261174941,"hash":"0eb0326bfc103cbfb1ac743a17a715112dee201b"}
{"url":"https://forum.openzeppelin.com/t/pancakeswap-v2-liquidity-in-v1-contract/9763","domain":"forum.openzeppelin.com","title":"Pancakeswap V2 Liquidity in V1 Contract - Support - OpenZeppelin Forum","text":"Pancakeswap V2 Liquidity in V1 Contract \n\n Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2021\n\n 1 / 3\n\n Jun 2021\n\n Jun 2021\n\n post by shqhin on Jun 3, 2021\n\n shqhin\n\n hey, i coded an token and added lp (1 bnb), then i saw my code router is pancakeswap v1 and wanted redeploy but i cant take out the lp… If i click confirm nothing happen can you help me please?\n\n post by FreezyEx on Jun 3, 2021\n\n FreezyEx\n\n disable swapandliquidify and change maxTxPercent to 100\n\n post by 0f0crypto on Jun 3, 2021\n\n 0f0crypto\n\n Alao try taking out WBNB instead of BNB\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Removing LP Pancakeswap not possible\n\n Contracts\n\n 10\n\n 2.6k\n\n Sep 2021\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 20\n\n 12.3k\n\n Aug 2025\n\n Unable to remove liquidity from pancakeswap\n\n Smart Contracts\n\n 0\n\n 665\n\n Mar 2022\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 883\n\n Jun 2022\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024","tokens":289,"squid":"ink-security_audits","role":"Sentinel","at":1791261177649,"hash":"c2638239ef5683ce04247e39a8988002f89cdbb8"}
{"url":"https://io.net/docs/guides/workers/install-on-windows","domain":"io.net","title":"Overview - io.net","text":"​Go to\ncloud.io.net\nIf you have not yet created an account, you can sign up on io.net using Google, Apple ID, GitHub, Hugging Face, X, Worldcoin, or simply with a one-time password by clicking the “Login with Email” button.\n\n​1. From IO Elements Go to IO Worker\nIO Elements serves as your new control panel for navigating the service efficiently. Click on IO Worker to delve deeper into its functionalities and features.\n\n​2. Click “Connect New Worker” to Open the Wizard\nIf Workers have not been added, click Connect New Worker. If the screen is full of information, find the same button in the upper right corner.\n\n​3. Name Your Device\nClick the “Pencil” icon to open the popup for editing the device name. 

\nPlease add a unique name for your device. We suggest a format such as: My-Test-Device
.\n\n​4. Select Windows Operating System\nChoose the Operating System of your device from MacOS, Windows or Ubuntu.\n\n​5. Select Device Type\nYou should choose the device type based on your task. A video card is better suited for AI tasks, while a processor is more suitable for graphic rendering.\n - This is the part of your computer or laptop that handles graphics - the video card. It’s usually from Nvidea or Radeon. You can find a full list of video cards that io.net is compatible with here.\n - This forms the core of every smart device in our world, including your computer or laptop. Now, alongside Intel and AMD processors, Apple’s processors have also joined the lineup. You can find a comprehensive list of processors compatible with io.net here.\n\nYou can also verify whether your GPU or CPU is included in the list of devices supported by our service on the wizard page.\nIf you choose .Worker and your device doesn’t have GPU the setup will fail\n​6. Prerequisites for Windows\nFollow the steps below to complete the prerequisites:\n\nDownload and Install Desktop . You can find comprehensive instructions on how to install Docker for Windows in this concise guide.\nThen Download and Setup . Please refer to the instructions on how to do this by following the link.\nAfterward (if needed or if not done yet), you’ll need to install or update the correct for your video card. You can find instructions on how to do this here .\n\nWhen using SXM or NV Link, ensure that Fabric Manager is installed correctly and enabled. This will prevent initialization issues and ensure that all s are functioning properly, thereby avoiding PoW verification failures.\n​7. Download and Launch IO Binary\nIO Binary is a compiled executable file used to perform computational tasks and manage system operations. It is crucial for the operation of the platform as it handles essential functions directly related to the performance and reliability of computational resources.\nDo not modify or run code directly in io.net’s docker containers. This may disqualify your device from earning block rewards or being hired. If you have suggestions or ideas for custom code in our Docker containers, contact customer support to suggest them.\nIn this step, what you are required to do is:\n\nDownload the Executable File: Copy the URL below, open your browser, and paste it. The browser downloads the executable file to your computer. It’s recommended to download the IO Binary again, as we often update versions for improvements.\nhttps://github.com/ionet-official/io_launch_binaries/raw/main/io_net_launch_binary_windows.exe\n\nOpen IO Binary file into Terminal\nTerminal is a tool on your computer that allows you enter commands to tell the computer what to do. Instead of clicking on elements with a mouse, you write instructions, and the computer follows them. It’s like talking directly to your computer using text.\n\nClick the Start Menu icon, then find and select the Terminal app from the popup menu.\n\nIn the Terminal, navigate to the Downloads folder by typing the command to go to the folder with the IO Binary.\ncd Downloads\n\nNext, copy the command from your new worker page to launch the IO Binary.\n\nThen paste it into the terminal and press Enter to run it.\n\n​8. Authorize Your New Device\nThe may prompt you to authorize your new device.\nRemember, you have about 3 minutes to complete the authorization of the device. If you miss it, you will need to rerun the code again.\nYou can do this in two ways:\n\nCopy the Link from the Terminal:\n\nPaste it into your browser and confirm the action. After confirmation, the system will prompt you to log in.\n\nCopy the Code from the Terminal:\n\nEnter this code on the page https://auth0.io.solutions/activate to authorize the device. After it, the system will prompt you to log in.\n\nOnboard Multiple Devices by Bypassing Interactive AuthenticationAfter you authenticate once, you can bypass the interactive auth process when you join additional devices. To do this, run the binary with an additional argument, the —token flag, followed by the token value.In the Command Prompt, copy your token and pass the —token flag, followed by the token and run the binary.io_net_launch_binary_windows.exe --token your-token-value\nTokens are valid for 12 months.\n​9. Remove Previously Installed Docker Containers\n will ask you questions related to previously installed Docker Containers. To continue the installation of , you must agree to remove all old containers and proceed by typing: Yes\n\n​11. Wait for Worker Connection to Complete\nThe IO Binary will installs all additional containers and images for your Docker. The process may take some time to complete as it installs additional packages for Docker. Please allow the installation process to finish.\n\nAfterward, return to the browser to complete the installation.\nYou may need to wait for up to 10 minutes while the device checks and connects to the IO Ecosystem. If it doesn’t connect, reach out to our Support ticket by logging into your IO.Net account.\n\nPlease disable power-saving mode when running your devices on IO Net. Power-saving mode can impair device performance, potentially leading to failure in PoW or being classified as not providing adequate computing power.\n​Congratulations on Successfully Setting up Your First Worker.\nNow that your Worker has been successfully created and is running, you can track its status on the Workers page.\n\nIf you’re having trouble installing the Worker, please refer to our Windows Worker troubleshooting guide or the general Worker troubleshooting guide. If the issue persists or you need further assistance, feel free to check our knowledge base for answers, and if you still need help, don’t hesitate to open a support ticket!\nBe aware that you will be installing a 20GB size container. This contains all the packages needed to serve AI/ML apps. Everything happens inside the container, nothing within the container can access your filesystem.Was this page helpful?","tokens":1693,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261198639,"hash":"ceca31cdc9eee1a8f894e3ab29f9c6307810a534"}
{"url":"https://forum.openzeppelin.com/t/cant-remove-liquidity-on-pancakeswap-v2/26155/21","domain":"forum.openzeppelin.com","title":"Can't remove liquidity on pancakeswap v2 - Smart Contracts - OpenZeppelin Forum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n 2\n\n Mar 2022\n\n 21 / 21\n\n Aug 2025\n\n Aug 2025\n\n Load more posts above\n\n post by Wrong on Mar 14, 2022\n\n Wrong\n\n Most likely there's a problem with the token you're trying to remove liquidity. Can you post the contract of the token?\n\n post by Sweetcrispypotato on Mar 14, 2022\n\n Sweetcrispypotato\n\n I can't post the contract here, but its 99% similar to https://bscscan.com/address/0x9D173E6c594f479B4d47001F8E6A95A7aDDa42bC#code\n\n post by Wrong on Mar 14, 2022\n\n Wrong\n\n Sorry this looks sketchy\nWhy would you seek for help to remove liquidity (a rug maybe) and not share the root of the problem (the contract)?\n\n post by YummyDao on Mar 14, 2022\n\n YummyDao\n\n Do you still own the address which you used to create the liquidity\n\n post by Sweetcrispypotato on Mar 14, 2022\n\n Sweetcrispypotato\n\n I do, its not renounced or transferred ownership.\n\n post by YummyDao on Mar 14, 2022\n\n YummyDao\n\n Create a liquidity was called from the token contract?\n\n post by YummyDao on Mar 14, 2022\n\n YummyDao\n\n If it's similar to this\n\nWhere is the address for bosses\n\n post by Sweetcrispypotato on Mar 14, 2022\n\n Sweetcrispypotato\n\n the uniswaprouterv2 is the same as you have given above\nRouter :\n\nThe addressforbossess is the owner itself.\n\n post by Sweetcrispypotato on Mar 14, 2022\n\n Sweetcrispypotato\n\n SOLVED, tax/maxtx set high reverted to 0 in order to make transaction.\n\n 5 months later\n\n post by alex_3000 on Aug 11, 2022\n\n alex_3000\n\n hello, please can you help state how you solved this? i am having the same issue\n\n post by CryptoWorld on Aug 11, 2022\n\n CryptoWorld\n\n He set the tax of his contract to 0 and set the max token transfer to high enough so he could take out the liquidity.\nWithout ppl showing the real tx and contract its pretty hard to say why its failing.\n\n 23 days later\n\n post by Godar_Yesh on Sep 4, 2022\n\n Godar_Yesh\n\n Sweetcrispypotato\n\n how to fill all the space bro? i have same problem. kindly post it for a sample. thanks before\n\n 3 months later\n\n post by Cathal_MacFadden on Nov 24, 2022\n\n Cathal_MacFadden\n\n In my case my slippage was set to 0%\nWhen i changed it to 1% it allowed me to remove the liquidity.\n\n 18 days later\n\n post by Boluwatife_Adegbola on Dec 13, 2022\n\n Boluwatife_Adegbola\n\n Hello, setting slippage to 0.5% does work too, the lesser the better.\n\n 3 months later\n\n post by hishumble on Mar 4, 2023\n\n hishumble\n\n hi there, how can we remove liquidity on this one???? The token itself was hit by self destruct attack but the remaining liquidity in MDEX, Pancakeswap, Bakeryswap is not possible to be removed. Any solution you could think of? https://bscscan.com/token/0x9dfA7Befc81e887fC3Abd8680d4026Bd22bB5dEA#balances\n\n 2 months later\n\n post by itsme_ken on Apr 24, 2023\n\n itsme_ken\n\n YummyDao\n\n Continuing the discussion from Can't remove liquidity on pancakeswap v2:\ni have same problem, i cant remove my liquidity , because of my contract have\nmax buy/sell and i renounce the contract, that`s why maybe i cant remove my LP\n\n 15 days later\n\n post by Gunnon_Ch on May 9, 2023\n\n Gunnon_Ch\n\n CryptoWorld\n\n Can the contract be edite after deployed? Im having the same problem and I dont know how to change the tax to 0. Please help.\n\n post by xput on May 12, 2023\n\n xput\n\n i have no idea what im doing, can anyone help me\n\n 6 months later\n\n post by Zach_Adam on Nov 3, 2023\n\n Zach_Adam\n\n if someone could help me figure out how to increase tx limit when removing liquidity so I can actually remove liquidity (right now can only remove 0.0000001 bnb it appears) that would be great. I cant write anything on the contract with my dev wallet or else it says contract error and gas is very expensive. Whoever can help me out I'm willing to give them a reward. Thanks\nContract: 0x7Cac1F986a9573C83daBC72602aEEC69aFD3b336\nLP Pool: 0x56e0b56f78f70aaeac9f855434ffc4089dd48b1b\n\n 2 years later\n\n post by Morteza_Khalili on Aug 23, 2025\n\n Morteza_Khalili\n\n Hi\nthe best way for removing this liquidity positions is to change the slippage tolerance to more than 5% and the best value is 10% and more.\nI found this very practical and worked for me \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 883\n\n Jun 2022\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024\n\n HELP Can’t remove liquidity on pcs v2\n\n Smart Contracts\n\n 4\n\n 887\n\n Nov 2022\n\n I can’t remove the LP from pancakeswap (22 BNB)\n\n Smart Contracts\n\n 5\n\n 1.2k\n\n Aug 2022\n\n Unable to remove liquidity from pancakeswap\n\n Smart Contracts\n\n 0\n\n 665\n\n Mar 2022","tokens":1176,"squid":"ink-security_audits","role":"Sentinel","at":1791261199767,"hash":"0414173325ce930c0ec4eca5ca21f1501e1d70a1"}
{"url":"https://specs.optimism.io/protocol/deposits.html","domain":"specs.optimism.io","title":"Deposits - OP Stack Specification","text":"Deposits\n\nTable of Contents\n\nOverview\nThe Deposited Transaction Type\n\nSource hash computation\nKinds of Deposited Transactions\nValidation and Authorization of Deposited Transactions\nExecution\n\nNonce Handling\n\nDeposit Receipt\nL1 Attributes Deposited Transaction\n\nL1 Attributes Deposited Transaction Calldata\n\nL1 Attributes - Bedrock, Canyon, Delta\n\nSpecial Accounts on L2\n\nL1 Attributes Depositor Account\nL1 Attributes Predeployed Contract\n\nL1 Attributes Predeployed Contract: Reference Implementation\n\nUser-Deposited Transactions\n\nDeposit Contract\n\nAddress Aliasing\nDeposit Contract Implementation: Optimism Portal\n\nOverview\nDeposited transactions, also known as deposits are transactions which\nare initiated on L1, and executed on L2. This document outlines a new transaction\ntype for deposits. It also describes how deposits are initiated on L1, along\nwith the authorization and validation conditions on L2.\nVocabulary note: deposited transaction refers specifically to an L2 transaction, while\ndeposit can refer to the transaction at various stages (for instance when it is deposited on L1).\nThe Deposited Transaction Type\nDeposited transactions have the following notable distinctions from existing\ntransaction types:\n\nThey are derived from Layer 1 blocks, and must be included as part of the protocol.\nThey do not include signature validation (see User-Deposited Transactions\nfor the rationale).\nThey buy their L2 gas on L1 and, as such, the L2 gas is not refundable.\n\nWe define a new EIP-2718 compatible transaction type with the prefix 0x7E to represent a deposit transaction.\nA deposit has the following fields\n(rlp encoded in the order they appear here):\n\nbytes32 sourceHash: the source-hash, uniquely identifies the origin of the deposit.\naddress from: The address of the sender account.\naddress to: The address of the recipient account, or the null (zero-length) address if the\ndeposited transaction is a contract creation.\nuint256 mint: The ETH value to mint on L2.\nuint256 value: The ETH value to send to the recipient account.\nuint64 gas: The gas limit for the L2 transaction.\nbool isSystemTx: If true, the transaction does not interact with the L2 block gas pool.\n\nNote: boolean is disabled (enforced to be false) starting from the Regolith upgrade.\n\nbytes data: The calldata.\n\nIn contrast to EIP-155 transactions, this transaction type:\n\nDoes not include a nonce, since it is identified by the sourceHash.\nAPI responses still include a nonce attribute:\n\nBefore Regolith: the nonce is always 0\nWith Regolith: the nonce is set to the depositNonce attribute of the corresponding transaction receipt.\n\nDoes not include signature information, and makes the from address explicit.\nAPI responses contain zeroed signature v, r, s values for backwards compatibility.\nIncludes new sourceHash, from, mint, and isSystemTx attributes.\nAPI responses contain these as additional fields.\n\nWe select 0x7E because transaction type identifiers are currently allowed to go up to 0x7F.\nPicking a high identifier minimizes the risk that the identifier will be used by another\ntransaction type on the L1 chain in the future. We don't pick 0x7F itself in case it becomes used\nfor a variable-length encoding scheme.\nSource hash computation\nThe sourceHash of a deposit transaction is computed based on the origin:\n\nUser-deposited:\nkeccak256(bytes32(uint256(0)), keccak256(l1BlockHash, bytes32(uint256(l1LogIndex)))).\nWhere the l1BlockHash, and l1LogIndex all refer to the inclusion of the deposit log event on L1.\nl1LogIndex is the index of the deposit event log in the combined list of log events of the block.\nL1 attributes deposited:\nkeccak256(bytes32(uint256(1)), keccak256(l1BlockHash, bytes32(uint256(seqNumber)))).\nWhere l1BlockHash refers to the L1 block hash of which the info attributes are deposited.\nAnd seqNumber = l2BlockNum - l2EpochStartBlockNum,\nwhere l2BlockNum is the L2 block number of the inclusion of the deposit tx in L2,\nand l2EpochStartBlockNum is the L2 block number of the first L2 block in the epoch.\nUpgrade-deposited: keccak256(bytes32(uint256(2)), keccak256(intent)).\nWhere intent is a UTF-8 byte string, identifying the upgrade intent.\n\nWithout a sourceHash in a deposit, two different deposited transactions could have the same exact hash.\nThe outer keccak256 hashes the actual uniquely identifying information with a domain,\nto avoid collisions between different types of sources.\nThe Interop derivation spec introduces two additional kinds of system deposits,\nwith domains 3 and 4.\nWe do not use the sender's nonce to ensure uniqueness because this would require an extra L2 EVM state read from the\nexecution engine during block-derivation.\nKinds of Deposited Transactions\nAlthough we define only one new transaction type, we can distinguish between two kinds of deposited\ntransactions, based on their positioning in the L2 block:\n\nThe first transaction MUST be a L1 attributes deposited transaction, followed by\nan array of zero-or-more user-deposited transactions\nsubmitted to the deposit feed contract on L1 (called OptimismPortal).\nUser-deposited transactions are only present in the first block of a L2 epoch.\n\nWe only define a single new transaction type in order to minimize modifications to L1 client\nsoftware, and complexity in general.\nValidation and Authorization of Deposited Transactions\nAs noted above, the deposited transaction type does not include a signature for validation. Rather,\nauthorization is handled by the L2 chain derivation process, which when correctly\napplied will only derive transactions with a from address attested to by the logs of the L1\ndeposit contract.\nExecution\nIn order to execute a deposited transaction:\nFirst, the balance of the from account MUST be increased by the amount of mint.\nThis is unconditional, and does not revert on deposit failure.\nThen, the execution environment for a deposited transaction is initialized based on the\ntransaction's attributes, in exactly the same manner as it would be for an EIP-155 transaction.\nThe deposit transaction is processed exactly like a type-2 (EIP-1559) transaction, with the exception of:\n\nNo fee fields are verified: the deposit does not have any, as it pays for gas on L1.\nNo nonce field is verified: the deposit does not have any, it's uniquely identified by its sourceHash.\nNo access-list is processed: the deposit has no access-list, and it is thus processed as if the access-list is empty.\nNo contract-creation init code size check is performed. The maximum deposit transaction size is constrained by L1.\ninit code size.\nNo check if from is an Externally Owner Account (EOA): the deposit is ensured not to be an EOA through L1 address\nmasking, this may change in future L1 contract-deployments to e.g. enable an account-abstraction like mechanism.\nBefore the Regolith upgrade:\n\nThe execution output states a non-standard gas usage:\n\nIf isSystemTx is false: execution output states it uses gasLimit gas.\nIf isSystemTx is true: execution output states it uses 0 gas.\n\nNo gas is refunded as ETH. (either by not refunding or utilizing the fact the gas-price of the deposit is 0)\nNo transaction priority fee is charged. No payment is made to the block fee-recipient.\nNo L1-cost fee is charged, as deposits are derived from L1 and do not have to be submitted as data back to it.\nNo base fee is charged. The total base fee accounting does not change.\n\nNote that this includes contract-deployment behavior like with regular transactions, and gas\nmetering is the same (with the exception of fee related changes above), including metering of\nintrinsic gas.\nAny non-EVM state-transition error emitted by the EVM execution is processed in a special way:\n\nIt is transformed into an EVM-error:\ni.e. the deposit will always be included, but its receipt will indicate a failure\nif it runs into a non-EVM state-transition error, e.g. failure to transfer the specified\nvalue amount of ETH due to insufficient account-balance.\nThe world state is rolled back to the start of the EVM processing, after the minting part of the deposit.\nThe nonce of from in the world state is incremented by 1, making the error equivalent to a native EVM failure.\nNote that a previous nonce increment may have happened during EVM processing, but this would be rolled back first.\n\nFinally, after the above processing, the execution post-processing runs the same:\ni.e. the gas pool and receipt are processed identical to a regular transaction.\nStarting with the Regolith upgrade however, the receipt of deposit transactions is extended with an additional\ndepositNonce value, storing the nonce value of the from sender as registered before the EVM processing.\nNote that the gas used as stated by the execution output is subtracted from the gas pool,\nbut this execution output value has special edge cases before the Regolith upgrade.\nNote for application developers: because CALLER and ORIGIN are set to from, the\nsemantics of using the tx.origin == msg.sender check will not work to determine whether\nor not a caller is an EOA during a deposit transaction. Instead, the check could only be useful for\nidentifying the first call in the L2 deposit transaction. However this check does still satisfy\nthe common case in which developers are using this check to ensure that the CALLER is unable to\nexecute code before and after the call.\nNonce Handling\nDespite the lack of signature validation, we still increment the nonce of the from account when a\ndeposit transaction is executed. In the context of a deposit-only roll up, this is not necessary\nfor transaction ordering or replay prevention, however it maintains consistency with the use of\nnonces during contract creation. It may also simplify integration with downstream\ntooling (such as wallets and block explorers).\nDeposit Receipt\nTransaction receipts use standard typing as per EIP-2718.\nThe Deposit transaction receipt type is equal to a regular receipt,\nbut extended with an optional depositNonce field.\nThe RLP-encoded consensus-enforced fields are:\n\npostStateOrStatus (standard): this contains the transaction status, see EIP-658.\ncumulativeGasUsed (standard): gas used in the block thus far, including this transaction.\n\nThe actual gas used is derived from the difference in CumulativeGasUsed with the previous transaction.\nStarting with Regolith, this accounts for the actual gas usage by the deposit, like regular transactions.\n\nbloom (standard): bloom filter of the transaction logs.\nlogs (standard): log events emitted by the EVM processing.\ndepositNonce (unique extension): Optional field. The deposit transaction persists the nonce used during execution.\ndepositNonceVersion (unique extension): Optional field. The value must be 1 if the field is present\n\nBefore Canyon, these depositNonce & depositNonceVersion fields must always be omitted.\nWith Canyon, these depositNonce & depositNonceVersion fields must always be included.\n\nStarting with Regolith, the receipt API responses utilize the receipt changes for more accurate response data:\n\nThe depositNonce is included in the receipt JSON data in API responses\nFor contract-deployments (when to == null), the depositNonce helps derive the correct contractAddress meta-data,\ninstead of assuming the nonce was zero.\nThe cumulativeGasUsed accounts for the actual gas usage, as metered in the EVM processing.\n\nL1 Attributes Deposited Transaction\nAn L1 attributes deposited transaction is a deposit transaction sent to the L1\nattributes predeployed contract.\nThis transaction MUST have the following values:\n\nfrom is 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001 (the address of the\nL1 Attributes depositor account)\nto is 0x4200000000000000000000000000000000000015 (the address of the L1 attributes predeployed\ncontract).\nmint is 0\nvalue is 0\ngasLimit is set to 150,000,000 prior to the Regolith upgrade, and 1,000,000 after.\nisSystemTx is set to true prior to the Regolith upgrade, and false after.\ndata is an encoded call to the L1 attributes predeployed contract that\ndepends on the upgrades that are active (see below).\n\nThis system-initiated transaction for L1 attributes is not charged any ETH for its allocated\ngasLimit, as it is considered part of state-transition processing.\nL1 Attributes Deposited Transaction Calldata\nL1 Attributes - Bedrock, Canyon, Delta\nThe data field of the L1 attributes deposited transaction is an ABI encoded call to the\nsetL1BlockValues() function with correct values associated with the corresponding L1 block\n(cf. reference implementation).\nSpecial Accounts on L2\nThe L1 attributes deposit transaction involves two special purpose accounts:\n\nThe L1 attributes depositor account\nThe L1 attributes predeployed contract\n\nL1 Attributes Depositor Account\nThe depositor account is an EOA with no known private key. It has the address\n0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001. Its value is returned by the CALLER and ORIGIN\nopcodes during execution of the L1 attributes deposited transaction.\nL1 Attributes Predeployed Contract\nA predeployed contract on L2 at address 0x4200000000000000000000000000000000000015, which holds\ncertain block variables from the corresponding L1 block in storage, so that they may be accessed\nduring the execution of the subsequent deposited transactions.\nThe predeploy stores the following values:\n\nL1 block attributes:\n\nnumber (uint64)\ntimestamp (uint64)\nbasefee (uint256)\nhash (bytes32)\n\nsequenceNumber (uint64): This equals the L2 block number relative to the start of the epoch,\ni.e. the L2 block distance to the L2 block height that the L1 attributes last changed,\nand reset to 0 at the start of a new epoch.\nSystem configurables tied to the L1 block, see System configuration specification:\n\nbatcherHash (bytes32): A versioned commitment to the batch-submitter(s) currently operating.\noverhead (uint256): The L1 fee overhead to apply to L1 cost computation of transactions in this L2 block.\nscalar (uint256): The L1 fee scalar to apply to L1 cost computation of transactions in this L2 block.\n\nThe contract implements an authorization scheme, such that it only accepts state-changing calls from\nthe depositor account.\nThe contract has the following solidity interface, and can be interacted with according to the\ncontract ABI specification.\nL1 Attributes Predeployed Contract: Reference Implementation\nA reference implementation of the L1 Attributes predeploy contract can be found in L1Block.sol.\nUser-Deposited Transactions\nUser-deposited transactions are deposited transactions\ngenerated by the L2 Chain Derivation process. The content of each user-deposited\ntransaction are determined by the corresponding TransactionDeposited event emitted by the\ndeposit contract on L1.\n\nfrom is unchanged from the emitted value (though it may\nhave been transformed to an alias in OptimismPortal, the deposit feed contract).\nto is any 20-byte address (including the zero address)\n\nIn case of a contract creation (cf. isCreation), this address is set to null.\n\nmint is set to the emitted value.\nvalue is set to the emitted value.\ngaslimit is unchanged from the emitted value. It must be at least 21000.\nisCreation is set to true if the transaction is a contract creation, false otherwise.\ndata is unchanged from the emitted value. Depending on the value of isCreation it is handled\nas either calldata or contract initialization code.\nisSystemTx is set by the rollup node for certain transactions that have unmetered execution.\nIt is false for user deposited transactions\n\nDeposit Contract\nThe deposit contract is deployed to L1. Deposited transactions are derived from the values in\nthe TransactionDeposited event(s) emitted by the deposit contract.\nThe deposit contract is responsible for maintaining the guaranteed gas market,\ncharging deposits for gas to be used on L2, and ensuring that the total amount of guaranteed\ngas in a single L1 block does not exceed the L2 block gas limit.\nThe deposit contract handles two special cases:\n\nA contract creation deposit, which is indicated by setting the isCreation flag to true.\nIn the event that the to address is non-zero, the contract will revert.\nA call from a contract account, in which case the from value is transformed to its L2\nalias.\n\nAddress Aliasing\nIf the caller is a contract, the address will be transformed by adding\n0x1111000000000000000000000000000000001111 to it. The math is unchecked and done on a\nSolidity uint160 so the value will overflow. This prevents attacks in which a\ncontract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this\nfor EOAs because they're guaranteed to have the same \"code\" (i.e. no code at all). This also makes\nit possible for users to interact with contracts on L2 even when the Sequencer is down.\nDeposit Contract Implementation: Optimism Portal\nA reference implementation of the deposit contract can be found in OptimismPortal.sol.","tokens":4206,"squid":"ink-governance","role":"Council Listener","at":1791261199952,"hash":"7d27023f41df159b3c55ab467fe2f5f77eca467f"}
{"url":"https://specs.optimism.io/protocol/bridges.html","domain":"specs.optimism.io","title":"Bridges - OP Stack Specification","text":"Standard Bridges\n\nTable of Contents\n\nOverview\nToken Depositing\nUpgradability\n\nOverview\nThe standard bridges are responsible for allowing cross domain\nETH and ERC20 token transfers. They are built on top of the cross domain\nmessenger contracts and give a standard interface for depositing tokens.\nThe bridge works for both L1 native tokens and L2 native tokens. The legacy API\nis preserved to ensure that existing applications will not experience any\nproblems with the Bedrock StandardBridge contracts.\nThe L2StandardBridge is a predeploy contract located at\n0x4200000000000000000000000000000000000010.\ninterface StandardBridge {\n event ERC20BridgeFinalized(address indexed localToken, address indexed remoteToken, address indexed from, address to, uint256 amount, bytes extraData);\n event ERC20BridgeInitiated(address indexed localToken, address indexed remoteToken, address indexed from, address to, uint256 amount, bytes extraData);\n event ETHBridgeFinalized(address indexed from, address indexed to, uint256 amount, bytes extraData);\n event ETHBridgeInitiated(address indexed from, address indexed to, uint256 amount, bytes extraData);\n\n function bridgeERC20(address _localToken, address _remoteToken, uint256 _amount, uint32 _minGasLimit, bytes memory _extraData) external;\n function bridgeERC20To(address _localToken, address _remoteToken, address _to, uint256 _amount, uint32 _minGasLimit, bytes memory _extraData) external;\n function bridgeETH(uint32 _minGasLimit, bytes memory _extraData) payable external;\n function bridgeETHTo(address _to, uint32 _minGasLimit, bytes memory _extraData) payable external;\n function deposits(address, address) view external returns (uint256);\n function finalizeBridgeERC20(address _localToken, address _remoteToken, address _from, address _to, uint256 _amount, bytes memory _extraData) external;\n function finalizeBridgeETH(address _from, address _to, uint256 _amount, bytes memory _extraData) payable external;\n function messenger() view external returns (address);\n function OTHER_BRIDGE() view external returns (address);\n}\n\nToken Depositing\nThe bridgeERC20 function is used to send a token from one domain to another\ndomain. An OptimismMintableERC20 token contract must exist on the remote\ndomain to be able to deposit tokens to that domain. One of these tokens can be\ndeployed using the OptimismMintableERC20Factory contract.\nUpgradability\nBoth the L1 and L2 standard bridges should be behind upgradable proxies.","tokens":615,"squid":"ink-governance","role":"Council Listener","at":1791261211518,"hash":"46699e0bede7439e29fa1c27bc2d399c216fed2d"}
{"url":"https://forum.openzeppelin.com/t/help-can-t-remove-liquidity-on-pcs-v2/32658/5","domain":"forum.openzeppelin.com","title":"HELP Can’t remove liquidity on pcs v2 - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Oct 2022\n\n 5 / 5\n\n Nov 2022\n\n Nov 2022\n\n post by Midnight on Oct 23, 2022\n\n Midnight\n\n Hello, I put pancakeswap liquidity and I can't withdraw it, I am getting the error below, please help.\nPancakeswap says \"ERROR, This transaction would fail\"\nOwnership renounced yes\nContract 0x882076B584a32c07dDD7DcdC32C5BC7e2df45D5d\nMy wallet : 0x15fd86b0ea6bBAA2B9Ecf7c9A2Cb33EefF03Fb8F\n\nimage1170×2532 93.9 KB\n\nimage1170×2532 454 KB\n\n 2\n\n post by Midnight on Oct 23, 2022\n\n Midnight\n\n So I've come accross so many topics over the internet and hit a dead end.\nthis is basically a Token-BNB liquidity and it happened I can't pull it out. Pancakeswap says \"ERROR, This transaction would fail\", I have almost $200 trapped in that liquidity so I'm giving away a bounty - It's better to give something or it might end up trapped forever.\nI own the contract and its interacted with PC router and Factory\nTried Solutions :\nX - Receive WBNB instead of BNB\nX - Tried it on multiple browsers as well as on metamask app on android\nX-ownership renounced - Yes\nContract : 0x882076B584a32c07dDD7DcdC32C5BC7e2df45D5d\nHelp pls..\n\n 8 days later\n\n post by frangio on Nov 1, 2022\n\n frangio\n\n OpenZeppelin Team\n\n This is a smart contract development forum and this question is off topic. I will keep it open in case someone happens to know an answer but you should try to ask somewhere else.\n\n 20 days later\n\n post by Neige_Pro on Nov 22, 2022\n\n Neige_Pro\n\n I know how to remove it. I did it for my token.\n\n post by Team_X on Nov 22, 2022\n\n Team_X\n\n This is probably a problem with the token itself. If there are any fees then set em to 0%.\nTry deactivate everything that has to do with the transfer.\nburning fee? set it to 0\nliquidity fee? set it to 0\nwhatever? set it to 0\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 20\n\n 12.3k\n\n Aug 2025\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 883\n\n Jun 2022\n\n I can’t remove the LP from pancakeswap (22 BNB)\n\n Smart Contracts\n\n 5\n\n 1.2k\n\n Aug 2022\n\n I can’t remove the liquidity of pancakeswap\n\n Support\n\n erc20,pancake\n\n 1\n\n 838\n\n Feb 2022","tokens":606,"squid":"ink-security_audits","role":"Sentinel","at":1791261211851,"hash":"ca62478bf35b84f585082fc6406d3395f02d7b6f"}
{"url":"https://specs.optimism.io/protocol/exec-engine.html","domain":"specs.optimism.io","title":"Execution Engine - OP Stack Specification","text":"L2 Execution Engine\n\nTable of Contents\n\n1559 Parameters\nExtra Data\nDeposited transaction processing\n\nDeposited transaction boundaries\n\nFees\n\nFee Vaults\nPriority fees (Sequencer Fee Vault)\nBase fees (Base Fee Vault)\nL1-Cost fees (L1 Fee Vault)\n\nPre-Ecotone\nEcotone L1-Cost fee changes (EIP-4844 DA)\n\nEngine API\n\nengine_forkchoiceUpdatedV2\n\nExtended PayloadAttributesV2\n\nengine_forkchoiceUpdatedV3\n\nExtended PayloadAttributesV3\n\nengine_newPayloadV2\nengine_newPayloadV3\nengine_newPayloadV4\nengine_getPayloadV2\nengine_getPayloadV3\n\nExtended Response\n\nengine_getPayloadV4\nengine_signalSuperchainV1\n\nNetworking\nSync\n\nHappy-path sync\nWorst-case sync\n\nEcotone: disable Blob-transactions\nEcotone: Beacon Block Root\nP2P Modifications\n\nThis document outlines the modifications, configuration and usage of a L1 execution engine for L2.\n1559 Parameters\nThe execution engine must be able to take a per chain configuration which specifies the EIP-1559 Denominator\nand EIP-1559 elasticity. After Canyon it should also take a new value EIP1559DenominatorCanyon and use that as\nthe denominator in the 1559 formula rather than the prior denominator.\nThe formula for EIP-1559 is otherwise not modified.\nStarting with Holocene, the EIP-1559 parameters become dynamically configurable.\nStarting with Jovian, a configurable minimum base fee is introduced.\nExtra Data\nBefore Holocene, the genesis block may contain an arbitrary extraData value whereas all normal\nblocks must have an empty extraData field.\nWith Holocene, the extraData field encodes the EIP-1559 parameters.\nWith Jovian, the extraData encoding is extended to include minBaseFee.\nDeposited transaction processing\nThe Engine interfaces abstract away transaction types with EIP-2718.\nTo support rollup functionality, processing of a new Deposit TransactionType\nis implemented by the engine, see the deposits specification.\nThis type of transaction can mint L2 ETH, run EVM,\nand introduce L1 information to enshrined contracts in the execution state.\nDeposited transaction boundaries\nTransactions cannot be blindly trusted, trust is established through authentication.\nUnlike other transaction types deposits are not authenticated by a signature:\nthe rollup node authenticates them, outside of the engine.\nTo process deposited transactions safely, the deposits MUST be authenticated first:\n\nIngest directly through trusted Engine API\nPart of sync towards a trusted block hash (trusted through previous Engine API instruction)\n\nDeposited transactions MUST never be consumed from the transaction pool.\nThe transaction pool can be disabled in a deposits-only rollup\nFees\nSequenced transactions (i.e. not applicable to deposits) are charged with 3 types of fees:\npriority fees, base fees, and L1-cost fees.\nFee Vaults\nThe three types of fees are collected in 3 distinct L2 fee-vault deployments for accounting purposes:\nfee payments are not registered as internal EVM calls, and thus distinguished better this way.\nThese are hardcoded addresses, pointing at pre-deployed proxy contracts.\nThe proxies are backed by vault contract deployments, based on FeeVault, to route vault funds to L1 securely.\nVault NamePredeploy\nSequencer Fee VaultSequencerFeeVault\nBase Fee VaultBaseFeeVault\nL1 Fee VaultL1FeeVault\n\nPriority fees (Sequencer Fee Vault)\nPriority fees follow the eip-1559 specification, and are collected by the fee-recipient of the L2 block.\nThe block fee-recipient (a.k.a. coinbase address) is set to the Sequencer Fee Vault address.\nBase fees (Base Fee Vault)\nBase fees largely follow the eip-1559 specification, with the exception that base fees are not burned,\nbut add up to the Base Fee Vault ETH account balance.\nL1-Cost fees (L1 Fee Vault)\nThe protocol funds batch-submission of sequenced L2 transactions by charging L2 users an additional fee\nbased on the estimated batch-submission costs.\nThis fee is charged from the L2 transaction-sender ETH balance, and collected into the L1 Fee Vault.\nThe exact L1 cost function to determine the L1-cost fee component of a L2 transaction depends on\nthe upgrades that are active.\nPre-Ecotone\nBefore Ecotone activation, L1 cost is calculated as:\n(rollupDataGas + l1FeeOverhead) * l1BaseFee * l1FeeScalar / 1e6 (big-int computation, result\nin Wei and uint256 range)\nWhere:\n\nrollupDataGas is determined from the full encoded transaction\n(standard EIP-2718 transaction encoding, including signature fields):\n\nBefore Regolith fork: rollupDataGas = zeroes * 4 + (ones + 68) * 16\n\nThe addition of 68 non-zero bytes is a remnant of a pre-Bedrock L1-cost accounting function,\nwhich accounted for the worst-case non-zero bytes addition to complement unsigned transactions, unlike Bedrock.\n\nWith Regolith fork: rollupDataGas = zeroes * 4 + ones * 16\n\nl1FeeOverhead is the Gas Price Oracle overhead value.\nl1FeeScalar is the Gas Price Oracle scalar value.\nl1BaseFee is the L1 base fee of the latest L1 origin registered in the L2 chain.\n\nNote that the rollupDataGas uses the same byte cost accounting as defined in eip-2028,\nexcept the full L2 transaction now counts towards the bytes charged in the L1 calldata.\nThis behavior matches pre-Bedrock L1-cost estimation of L2 transactions.\nCompression, batching, and intrinsic gas costs of the batch transactions are accounted for by the protocol\nwith the Gas Price Oracle overhead and scalar parameters.\nThe Gas Price Oracle l1FeeOverhead and l1FeeScalar, as well as the l1BaseFee of the L1 origin,\ncan be accessed in two interchangeable ways:\n\nread from the deposited L1 attributes (l1FeeOverhead, l1FeeScalar, basefee) of the current L2 block\nread from the L1 Block Info contract (0x4200000000000000000000000000000000000015)\n\nusing the respective solidity uint256-getter functions (l1FeeOverhead, l1FeeScalar, basefee)\nusing direct storage-reads:\n\nL1 basefee as big-endian uint256 in slot 1\nOverhead as big-endian uint256 in slot 5\nScalar as big-endian uint256 in slot 6\n\nEcotone L1-Cost fee changes (EIP-4844 DA)\nEcotone allows posting batches via Blobs which are subject to a new fee market. To account for this feature,\nL1 cost is computed as:\n(zeroes*4 + ones*16) * (16*l1BaseFee*l1BaseFeeScalar + l1BlobBaseFee*l1BlobBaseFeeScalar) / 16e6\nWhere:\n\nthe computation is an unlimited precision integer computation, with the result in Wei and having\nuint256 range.\n\nzeroes and ones are the count of zero and non-zero bytes respectively in the full encoded\nsigned transaction.\n\nl1BaseFee is the L1 base fee of the latest L1 origin registered in the L2 chain.\n\nl1BlobBaseFee is the blob gas price, computed as described in EIP-4844 from the\nheader of the latest registered L1 origin block.\n\nConceptually what the above function captures is the formula below, where compressedTxSize = (zeroes*4 + ones*16) / 16 can be thought of as a rough approximation of how many bytes the\ntransaction occupies in a compressed batch.\n(compressedTxSize) * (16*l1BaseFee*lBaseFeeScalar + l1BlobBaseFee*l1BlobBaseFeeScalar) / 1e6\nThe precise cost function used by Ecotone at the top of this section preserves precision under\ninteger arithmetic by postponing the inner division by 16 until the very end.\nThe two base fee values and their respective scalars can be accessed in two interchangeable ways:\n\nread from the deposited L1 attributes (l1BaseFeeScalar, l1BlobBaseFeeScalar, basefee,\nblobBaseFee) of the current L2 block\nread from the L1 Block Info contract (0x4200000000000000000000000000000000000015)\n\nusing the respective solidity getter functions\nusing direct storage-reads:\n\nbasefee uint256 in slot 1\nblobBaseFee uint256 in slot 7\nl1BaseFeeScalar big-endian uint32 slot 3 at offset 12\nl1BlobBaseFeeScalar big-endian uint32 in slot 3 at offset 8\n\nEngine API\nengine_forkchoiceUpdatedV2\nThis updates which L2 blocks the engine considers to be canonical (forkchoiceState argument),\nand optionally initiates block production (payloadAttributes argument).\nWithin the rollup, the types of forkchoice updates translate as:\n\nheadBlockHash: block hash of the head of the canonical chain. Labeled \"unsafe\" in user JSON-RPC.\nNodes may apply L2 blocks out of band ahead of time, and then reorg when L1 data conflicts.\nsafeBlockHash: block hash of the canonical chain, derived from L1 data, unlikely to reorg.\nfinalizedBlockHash: irreversible block hash, matches lower boundary of the dispute period.\n\nTo support rollup functionality, one backwards-compatible change is introduced\nto engine_forkchoiceUpdatedV2: the extended PayloadAttributesV2\nExtended PayloadAttributesV2\nPayloadAttributesV2 is extended to:\nPayloadAttributesV2: {\n timestamp: QUANTITY\n prevRandao: DATA (32 bytes)\n suggestedFeeRecipient: DATA (20 bytes)\n withdrawals: array of WithdrawalV1\n transactions: array of DATA\n noTxPool: bool\n gasLimit: QUANTITY or null\n}\n\nThe type notation used here refers to the HEX value encoding used by the Ethereum JSON-RPC API\nspecification, as this structure will need to be sent over JSON-RPC. array refers\nto a JSON array.\nEach item of the transactions array is a byte list encoding a transaction: TransactionType || TransactionPayload or LegacyTransaction, as defined in EIP-2718.\nThis is equivalent to the transactions field in ExecutionPayloadV2\nThe transactions field is optional:\n\nIf empty or missing: no changes to engine behavior. The sequencers will (if enabled) build a block\nby consuming transactions from the transaction pool.\nIf present and non-empty: the payload MUST be produced starting with this exact list of transactions.\nThe rollup driver determines the transaction list based on deterministic L1 inputs.\n\nThe noTxPool is optional as well, and extends the transactions meaning:\n\nIf false, the execution engine is free to pack additional transactions from external sources like the tx pool\ninto the payload, after any of the transactions. This is the default behavior a L1 node implements.\nIf true, the execution engine must not change anything about the given list of transactions.\n\nIf the transactions field is present, the engine must execute the transactions in order and return STATUS_INVALID\nif there is an error processing the transactions. It must return STATUS_VALID if all of the transactions could\nbe executed without error. Note: The state transition rules have been modified such that deposits will never fail\nso if engine_forkchoiceUpdatedV2 returns STATUS_INVALID it is because a batched transaction is invalid.\nThe gasLimit is optional w.r.t. compatibility with L1, but required when used as rollup.\nThis field overrides the gas limit used during block-building.\nIf not specified as rollup, a STATUS_INVALID is returned.\nengine_forkchoiceUpdatedV3\nSee engine_forkchoiceUpdatedV2 for a description of the forkchoice updated method.\nengine_forkchoiceUpdatedV3 must only be called with Ecotone payload.\nTo support rollup functionality, one backwards-compatible change is introduced\nto engine_forkchoiceUpdatedV3: the extended PayloadAttributesV3\nExtended PayloadAttributesV3\nPayloadAttributesV3 is extended to:\nPayloadAttributesV3: {\n timestamp: QUANTITY\n prevRandao: DATA (32 bytes)\n suggestedFeeRecipient: DATA (20 bytes)\n withdrawals: array of WithdrawalV1\n parentBeaconBlockRoot: DATA (32 bytes)\n transactions: array of DATA\n noTxPool: bool\n gasLimit: QUANTITY or null\n eip1559Params: DATA (8 bytes) or null\n minBaseFee: QUANTITY or null\n}\n\nThe requirements of this object are the same as extended PayloadAttributesV2 with\nthe addition of parentBeaconBlockRoot which is the parent beacon block root from the L1 origin block of the L2 block.\nStarting at Ecotone, the parentBeaconBlockRoot must be set to the L1 origin parentBeaconBlockRoot,\nor a zero bytes32 if the Dencun functionality with parentBeaconBlockRoot is not active on L1.\nStarting with Holocene, the eip1559Params field must encode the EIP1559 parameters. It must be null before.\nSee Dynamic EIP-1559 Parameters for details.\nStarting with Jovian, the minBaseFee field is added. It must be null before Jovian.\nSee Jovian Minimum Base Fee for details.\nengine_newPayloadV2\nNo modifications to engine_newPayloadV2.\nApplies a L2 block to the engine state.\nengine_newPayloadV3\nengine_newPayloadV3 applies an Ecotone L2 block to the engine state. There are no\nmodifications to this API.\nengine_newPayloadV3 must only be called with Ecotone payload.\nThe additional parameters should be set as follows:\n\nexpectedBlobVersionedHashes MUST be an empty array.\nparentBeaconBlockRoot MUST be the parent beacon block root from the L1 origin block of the L2 block.\n\nengine_newPayloadV4\nengine_newPayloadV4 applies an Isthmus L2 block to the engine state.\nThe ExecutionPayload parameter will contain an extra field, withdrawalsRoot, after the Isthmus hardfork.\nengine_newPayloadV4 must only be called with Isthmus payload.\nThe additional parameters should be set as follows:\n\nexecutionRequests MUST be an empty array.\n\nengine_getPayloadV2\nNo modifications to engine_getPayloadV2.\nRetrieves a payload by ID, prepared by engine_forkchoiceUpdatedV2 when called with payloadAttributes.\nengine_getPayloadV3\nengine_getPayloadV3 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3\nwhen called with payloadAttributes.\nengine_getPayloadV3 must only be called with Ecotone payload.\nExtended Response\nThe response is extended to:\n{\n executionPayload: ExecutionPayload\n blockValue: QUANTITY\n blobsBundle: BlobsBundle\n shouldOverrideBuilder: BOOLEAN\n parentBeaconBlockRoot: DATA (32 bytes)\n}\n\nIn Ecotone it MUST be set to the parentBeaconBlockRoot from the L1 Origin block of the L2 block.\nengine_getPayloadV4\nengine_getPayloadV4 retrieves a payload by ID, prepared by engine_forkchoiceUpdatedV3\nwhen called with payloadAttributes.\nengine_getPayloadV4 must only be called with Isthmus payload.\nengine_signalSuperchainV1\nOptional extension to the Engine API. Signals superchain information to the Engine:\nV1 signals which protocol version is recommended and required.\nTypes:\nSuperchainSignal: {\n recommended: ProtocolVersion;\n required: ProtocolVersion;\n}\n\nProtocolVersion: encoded for RPC as defined in\nProtocol Version format specification.\nParameters:\n\nsignal: SuperchainSignal, the signaled superchain information.\n\nReturns:\n\nProtocolVersion: the latest supported OP-Stack protocol version of the execution engine.\n\nThe execution engine SHOULD warn the user when the recommended version is newer than\nthe current version supported by the execution engine.\nThe execution engine SHOULD take safety precautions if it does not meet the required protocol version.\nThis may include halting the engine, with consent of the execution engine operator.\nNetworking\nThe execution engine can acquire all data through the rollup node, as derived from L1:\nP2P networking is strictly optional.\nHowever, to not bottleneck on L1 data retrieval speed, the P2P network functionality SHOULD be enabled, serving:\n\nPeer discovery (Disc v5)\neth/66:\n\nTransaction pool (consumed by sequencer nodes)\nState sync (happy-path for fast trustless db replication)\nHistorical block header and body retrieval\nNew blocks are acquired through the consensus layer instead (rollup node)\n\nNo modifications to L1 network functionality are required, except configuration:\n\nnetworkID: Distinguishes the L2 network from L1 and testnets.\nEqual to the chainID of the rollup network.\nActivate Merge fork: Enables Engine API and disables propagation of blocks,\nas block headers cannot be authenticated without consensus layer.\nBootnode list: DiscV5 is a shared network,\nbootstrap is faster through connecting with L2 nodes first.\n\nSync\nThe execution engine can operate sync in different ways:\n\nHappy-path: rollup node informs engine of the desired chain head as determined by L1, completes through engine P2P.\nWorst-case: rollup node detects stalled engine, completes sync purely from L1 data, no peers required.\n\nThe happy-path is more suitable to bring new nodes online quickly,\nas the engine implementation can sync state faster through methods like snap-sync.\nHappy-path sync\n\nThe rollup node informs the engine of the L2 chain head, unconditionally (part of regular node operation):\n\nBedrock / Canyon / Delta Payloads\n\nengine_newPayloadV2 is called with latest L2 block received from P2P.\nengine_forkchoiceUpdatedV2 is called with the current\nunsafe/safe/finalized L2 block hashes.\n\nEcotone Payloads\n\nengine_newPayloadV3 is called with latest L2 block received from P2P.\nengine_forkchoiceUpdatedV3 is called with the current\nunsafe/safe/finalized L2 block hashes.\n\nThe engine requests headers from peers, in reverse till the parent hash matches the local chain\nThe engine catches up:\na) A form of state sync is activated towards the finalized or head block hash\nb) A form of block sync pulls block bodies and processes towards head block hash\n\nThe exact P2P based sync is out of scope for the L2 specification:\nthe operation within the engine is the exact same as with L1 (although with an EVM that supports deposits).\nWorst-case sync\n\nEngine is out of sync, not peered and/or stalled due other reasons.\nThe rollup node maintains latest head from engine (poll eth_getBlockByNumber and/or maintain a header subscription)\nThe rollup node activates sync if the engine is out of sync but not syncing through P2P (eth_syncing)\nThe rollup node inserts blocks, derived from L1, one by one, potentially adapting to L1 reorg(s),\nas outlined in the rollup node spec.\n\nEcotone: disable Blob-transactions\nEIP-4844 introduces Blob transactions: featuring all the functionality of an EIP-1559 transaction,\nplus a list of \"blobs\": \"Binary Large Object\", i.e. a dedicated data type for serving Data-Availability as base-layer.\nWith the Ecotone upgrade, all Cancun L1 execution features are enabled, with EIP-4844 as exception:\nas a L2, the OP-Stack does not serve blobs, and thus disables this new transaction type.\nEIP-4844 is disabled as following:\n\nTransaction network-layer announcements, announcing blob-type transactions, are ignored.\nTransactions of the blob-type, through the RPC or otherwise, are not allowed into the transaction pool.\nBlock-building code does not select EIP-4844 transactions.\nAn L2 block state-transition with EIP-4844 transactions is invalid.\n\nThe BLOBBASEFEE opcode is present but its semantics are\naltered because there are no blobs processed by L2. The opcode will always push a value of 1 onto\nthe stack.\nEcotone: Beacon Block Root\nEIP-4788 introduces a \"beacon block root\" into the execution-layer block-header and EVM.\nThis block root is an SSZ hash-tree-root of the consensus-layer contents of the previous consensus block.\nWith the adoption of EIP-4399 in the Bedrock upgrade the OP-Stack already includes the PREVRANDAO of L1.\nAnd thus with EIP-4788 the L1 beacon block root is made available.\nFor the Ecotone upgrade, this entails that:\n\nThe parent_beacon_block_root of the L1 origin is now embedded in the L2 block header.\nThe \"Beacon roots contract\" is deployed at Ecotone upgrade-time, or embedded at genesis if activated at genesis.\nThe block state-transition process now includes the same special beacon-block-root EVM processing as L1 ethereum.\n\nP2P Modifications\nThe Ethereum Node Record (ENR) for an Optimism execution node must contain an opel key-value pair where the key is\nopel and the value is a EIP-2124 fork id.\nThe EL uses a different key from the CL in order to stop EL and CL nodes from connecting to each other.","tokens":4824,"squid":"ink-governance","role":"Council Listener","at":1791261221351,"hash":"d568d01b8a0ebb48397dbbc8a9cff27b1d490baf"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer","domain":"docs.arbitrum.io","title":"The Sequencer and censorship resistance | Arbitrum Docs","text":"✏️Request an updateThe Sequencer’s job is to receive, admit, and order transactions and then publish and post the resulting blocks. The moment ordered transactions are handed to the execution engine, responsibility shifts to the State Transition Function (STF) and ArbOS, where transactions are executed against the chain state, gas is metered, and the new state root is computed. Throughout this section, we flag those handoff points and point to the relevant pages rather than duplicating them.\nA transaction’s path through the Sequencer​\n\n1. Receipt and admission​\nA user transaction arrives over JSON-RPC. Before it is allowed anywhere near a block, it passes a series of admission checks: if this node is not the active Sequencer, the transaction is forwarded to the active one; optional sender allowlists and parent chain fee-surplus thresholds can reject it; and internal Arbitrum transaction types and blob transactions are filtered out. Admitted transactions land in an unordered waiting list, the first stage of the Sequencer’s two-stage mempool. What happens next depends on the chain’s transaction ordering policy. Under first-come, first-serve (FCFS), arrival time sets the order. Under Priority Gas Auctions (PGA), each ordering round moves the whole waiting list into a priority queue keyed on the priority fee each transaction pays.\n2. Block creation loop​\nThe Sequencer runs a tight loop that drains its queues and groups transactions into a block. It services a retry queue ahead of the regular queue. Under PGA, the loop runs in fixed ordering rounds: each round moves the waiting list into the priority queue, then transfers that queue into the block under construction, highest priority fee first. PGA ordering covers the rounds in detail. Lightweight pre-checks happen here: per-transaction data-size limits, a base-fee check, and a nonce cache that parks too-high nonces and revives them once their predecessor succeeds. The loop also confirms that the parent-chain block number and timestamp are within an acceptable range before producing a block.\nA block closes when it reaches the first of these limits:\n\nA gas target of 32 Mgas. The hard limit is 64 Mgas, and a single transaction can use at most 32 Mgas.\nA calldata limit of 95,000 bytes.\nThe end of its last round.\n\nIf a block fills before its last round, the Sequencer finalizes it right away and starts the next block rather than idling for the rest of the window. Under load, the chain then produces blocks faster than its nominal block time, up to a cap of 8 blocks per second. That cap keeps the spacing between rounds consistent, which the anti-starvation boost depends on.\n3. Handoff to ArbOS and the STF​\nOnce the Sequencer has a finalized ordering, it calls the ExecutionEngine, which in turn invokes ArbOS to produce the block.\nHandoff: execution belongs to ArbOS and the STFEverything from this point of execution—iterating the ordered transactions, applying pre- and post-execution filters, running each transaction against chain state, metering child- and parent-chain gas, and computing the resulting state—is the job of the State Transition Function and ArbOS. The Sequencer supplies the ordered input and receives a produced block in return; it does not decide execution outcomes.\n4. Persistence and broadcast​\nThe produced block comes back to the Sequencer as a sequenced message. The TransactionStreamer persists it to the local database and, if a coordinator is configured, replicates it to Redis for high availability. It then hands the message to the Broadcaster, which pushes it to subscribers over the real-time feed. This is the moment users get soft finality: a sub-second provisional confirmation that depends on the Sequencer behaving honestly.\nOn Arbitrum One, a second stream runs alongside the standard feed. The Fast Feed is a paid, authenticated WebSocket stream that publishes each transaction as soon as the Sequencer orders and executes it, inside the PGA round and before the block closes. The Sequencer publishes to the Fast Feed before it stores the transaction, so the block number each message carries is tentative. Soft finality still comes from the standard feed.\n5. Posting to the parent chain​\nIndependent of the loop above, the batch poster reads sequenced messages from the TransactionStreamer, Brotli-compresses them with adaptive compression levels, and posts them to the Sequencer Inbox using either calldata or EIP-4844 blobs. To configure this component, see Run a batch poster. Once those batches are finalized on the parent chain, the transactions reach hard finality.\nHigh availability: the Sequencer coordinator​\nIn production, several Sequencer nodes run under a single logical Sequencer, with the SeqCoordinator electing a single active leader via Redis. A chosen-sequencer key records the current leader, which holds a short, time-limited lockout (roughly one minute by default) that it must continually refresh. The active node writes signed messages to Redis; standby nodes follow along so that, if the leader fails or steps down, another can take over with minimal disruption. Activation clears any forwarders and resumes block production; deactivation sets up forwarding to the new leader and pauses local production.\nDelayed messages from the parent chain​\nNot every transaction originates with a direct RPC submission. Deposits and retryable tickets enter through the parent chain’s delayed inbox. The DelayedSequencer watches for these messages to finalize on the parent chain, then sequences them into the child chain so they appear in the ordering and on the feed alongside ordinary transactions. As with execution generally, the act of applying a delayed message is ArbOS/STF territory; the DelayedSequencer’s role is to decide when it enters the order.\nPGA ordering​\nPGA orders transactions by the priority fee each one pays, rather than by the moment each one arrives. The Sequencer evaluates that order in short rounds that run several times per block. Three parts work together.\nThe two-stage mempool​\nArriving transactions land in an unordered waiting list. Intake runs continuously, independent of any ordering work. At the start of each round, the whole list moves into a priority queue keyed on the priority fee, which EIP-1559 computes as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas).\nTies break on the arrival timestamp the Sequencer recorded when the transaction first reached it, not on when it entered the queue. Because the priority fee depends on the base fee, the Sequencer re-keys the queue against the new base fee at the start of every block.\nThe mempool stays private. PGA does not give anyone the right to see or reorder another user’s transactions, so Arbitrum’s protections against harmful MEV are unchanged.\nOrdering rounds​\nA new round starts every B/K, where B is the block time and K is the number of rounds per block. On Arbitrum One, B is 250ms and K is 2, so each round lasts 125ms. Each round runs two phases:\n\nIntake covers the full round window and absorbs new arrivals into the waiting list. It overlaps with the previous round’s execute phase.\nExecute starts as soon as intake closes. The waiting list moves into the priority queue, and the Sequencer transfers the queue into the block, highest priority first.\n\nThe transfer ends when the queue empties, the block fills, or the round runs out of time. Anything still queued waits for the next round.\nThe anti-starvation boost​\nAt the end of every round in which the priority queue holds transactions, each transaction still waiting gains a priority boost of p / (2K). Here p is the priority of the last transaction the previous round included, or zero if that round included none.\nTwo properties matter:\n\nThe boost moves a transaction’s position in the queue and nothing else. It never changes the fee the transaction pays.\nThe boost compounds across rounds. A transaction that pays no priority fee climbs until it outranks the marginal paying transaction, which bounds its wait to a small number of blocks.\n\nPGA replaces Timeboost on Arbitrum OneTimeboost auctioned a 60-second express lane to one express lane controller per round and delayed every other transaction by 200ms. PGA removes that delay: no transaction waits for the 200ms anymore. Chain owners can still choose Timeboost instead, but a chain that enables both policies behaves unpredictably. See Timeboost for Arbitrum chains and PGA for Arbitrum chains.\nCensorship Timeout​\nAs mentioned in the original Arbitrum BoLD forum post, the initial release of Arbitrum BoLD includes a feature called Censorship Timeout (formerly known as Delay Buffer).\nCensorship Timeout aims to limit the negative effects of:\n\nProlonged Sequencer censorship, or\nUnexpected Sequencer outages\n\nHow the Censorship Timeout works​\nTo explain how this feature improves the security of chains settling to Arbitrum One, consider a scenario where an L3’s parent chain Sequencer (the L2 Sequencer) is censoring or offline. In such a case, every assertion and/or sub-challenge move would need to wait 24 hours before bypassing the L2 Sequencer (using the Sequencer Inbox’s forceInclusion method). In this scenario, a challenge resolution would be delayed by a time t where t = (24 hours) * number of moves for a challenge. To illustrate with sample numbers, if a challenge takes 50 sequential moves to resolve, then the delay would be 50 days.\nThe Censorship Timeout feature mitigates this by lowering the force inclusion threshold when unexpected delays in message inclusion occur due to one (or all) of the above-mentioned cases of censorship or a sequencer outage, enabling entities to make moves without the 24-hour delay-per-move.\nThe force inclusion window is the lesser of delayBuffer and delayBlocks, where delayBlocks is a constant currently set to 24 hours, and delayBuffer ranges from 30 minutes to 48 hours.\nThe delayBuffer value “grows and shrinks” depending on how long the Sequencer is offline or censoring transactions. As a way to measure this behavior, the delayBuffer is decremented by the difference between a delayed message’s delay beyond the threshold and how long it has been delayed (that is, when some delayed messages are delayed by more than the threshold, the difference between the messages’ delay and the threshold is removed from the buffer). For example, if the threshold is 30 minutes and a message was delayed by 32 minutes, the delayBuffer is decremented by 2 minutes. The threshold is set to 30 minutes on Arbitrum One and 1 hour on Arbitrum Nova.\nThe delayBuffer replenishes at a linear rate when the Sequencer is operating correctly at a nominal rate of one minute for every 20 minutes in which no messages are delayed beyond the threshold.\nBelow are the initial, proposed parameter values for the Censorship Timeout feature for Arbitrum One and Nova:\n\ndelayBuffer = 14400 parent chain (Ethereum) blocks (2 days)\nthreshold = 150 L1 Ethereum blocks (30 minutes) for Arbitrum One and 300 parent chain (Ethereum) blocks (one hour) for Arbitrum Nova\nreplenish rate = 5% (meaning one day is replenished every 20 days or roughly a 95% uptime)\n\nWe believe that the Censorship Timeout feature provides stronger guarantees of censorship resistance for Arbitrum chains—especially those that settle to Arbitrum One or Arbitrum Nova. As always, chain owners can decide whether to use this feature for their chain and can also change the default parameters as they see fit for their use case.\nDecentralized fair sequencing​\nArbitrum’s long-term vision includes transitioning from a centralized Sequencer to a decentralized, fair sequencing model. In this framework, a committee of servers (or validators) collectively determines transaction ordering, ensuring fairness, reducing the influence of any single party, and making it more resistant to manipulation. By requiring a supermajority, this approach distributes sequencing power among multiple honest participants, mitigates the risks of front-running or censorship, and aligns with broader blockchain principles of enhanced security, transparency, and decentralization. A transaction ordering policy sits above this layer. Decentralized sequencing changes who enforces the ordering rules, not the rules themselves.A transaction’s path through the SequencerHigh availability: the Sequencer coordinatorDelayed messages from the parent chainPGA orderingThe two-stage mempoolOrdering roundsThe anti-starvation boostCensorship TimeoutHow the Censorship Timeout worksDecentralized fair sequencing","tokens":3140,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261224653,"hash":"fb00a03e33efa98c0bc713d5c3ea170c6d9f27b7"}
{"url":"https://specs.optimism.io/protocol/batcher.html","domain":"specs.optimism.io","title":"Batch Submitter - OP Stack Specification","text":"Batch Submitter\n\nTable of Contents\n\nOverview\n\nOverview\nThe batch submitter, also referred to as the batcher, is the entity submitting the L2 sequencer data to L1,\nto make it available for verifiers.\nThe format of the data transactions is defined in the derivation spec:\nthe data is constructed from L2 blocks in the reverse order as it is derived from data into L2 blocks.\nThe timing, operation and transaction signing is implementation-specific: any data can be submitted at any time,\nbut only the data that matches the derivation spec rules will be valid from the verifier perspective.\nThe most minimal batcher implementation can be defined as a loop of the following operations:\n\nSee if the unsafe L2 block number is past the safe block number: unsafe data needs to be submitted.\nIterate over all unsafe L2 blocks, skip any that were previously submitted.\nOpen a channel, buffer all the L2 block data to be submitted,\nwhile applying the encoding and compression as defined in the derivation spec.\nPull frames from the channel to fill data transactions with, until the channel is empty.\nSubmit the data transactions to L1\n\nThe L2 view of safe/unsafe does not instantly update after data is submitted, nor when it gets confirmed on L1,\nso special care may have to be taken to not duplicate data submissions.","tokens":327,"squid":"ink-governance","role":"Council Listener","at":1791261231552,"hash":"6754580ef44e2643cce103a819bede8c5ca64ab0"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/priority-gas-auction/pga","domain":"docs.arbitrum.io","title":"Introduction to PGA (Priority Gas Auctions) | Arbitrum Docs","text":"✏️Request an updatePGA is an ordering policy in which users bid for ordering by attaching a priority fee to each transaction. Ordering becomes a continuous, permissionless, per-transaction competition.\nPGA is now available for activation across all Arbitrum chains.\nWhy sunset Timeboost?​\nArbitrum One has used Timeboost since April 2025. Timeboost auctions off a 60-second \"express lane\" in a sealed-bid, second-price auction and falls back to first-come, first-served (FCFS) ordering for everything else. This policy served to reduce latency-race spam and create the first sequencing revenue stream for the Arbitrum DAO.\nHowever, some design limitations became clear:\nThe barrier to entry is high: Participating in an ahead-of-time auction requires building custom tooling and forecasting MEV for an entire upcoming round.\nIt does not serve latency-sensitive applications well: Emerging DeFi primitives such as proprietary AMMs (propAMMs) need cheap, frequent, priority-ordered inclusion to keep onchain parameters fresh. An express lane held by a single controller for 60 seconds at a time is incompatible with these new AMMs.\nWhat are PGA’s benefits?​\nFamiliar mechanics and a low barrier to entry​\nParticipants bid by setting maxPriorityFeePerGas on a standard EIP-1559 type 2 transaction. There is no auction to register for and no custom tooling to build. Anyone who already runs a searcher on another EVM chain can participate on day one.\nNear-zero operational cost​\nPGA adds no infrastructure to run. PGA is a Sequencer flag plus a round-count parameter.\nFaster blocks under load​\nThe Sequencer issues each block as soon as it fills, rather than idling for the remainder of the block window. On a chain with B=250ms and K=2, this yields between 4 and 8 blocks per second: a minimum of 1/B and a maximum of K/B. Under heavy load, your chain confirms faster than its nominal block time.\nPGA preserves the great UX that Arbitrum chains are known for​\nThe default block time for Arbitrum chains continues to be industry-leading at 250ms, and response times can be further reduced by adding 125ms PGA rounds.\nPGA preserves Arbitrum's fast block times​\nThe nominal block time on Arbitrum One remains 250ms, with PGA rounds added at 125ms increments. Arbitrum chains can select the number of rounds based on their needs. On Arbitrum One, there are only 2 PGA rounds, which means that under heavy load, blocks that fill early are issued immediately so that the chain can produce up to 8 blocks per second.\nPGA allows more participants to order competition​\nBidding happens per transaction, just-in-time, using a standard EIP-1559 field. There is no separate auction to register for, no ahead-of-time forecast to make. Searchers and applications can participate through tips.\nPGA protects low-fee transactions from starvation​\nOn Ethereum, a transaction that pays no priority fee has no guarantee of inclusion and can wait for as long as congestion lasts. Under PGA, an anti-starvation boost raises the effective ordering position of transactions left waiting after each round, so these transactions are included within a small number of blocks. The boost changes position in the queue, never the fee actually charged.\nPGA maintains a value accrual path for chain owners​\nChain owners may use PGA to capture a portion of the available MEV on their chain that would have otherwise gone entirely to searchers. Priority fees are collected by the chain owner rather than accruing entirely to whoever captures MEV.\nHow PGA works​\nPGA is a transaction ordering policy: a set of rules the Sequencer is trusted to follow when ordering transactions submitted by users.\nAs with FCFS and Timeboost, the Sequencer's job is unchanged:\n\nAccept valid transactions\nPlace them in an order dictated by the policy\nPublish the resulting sequence to a feed\nPublish transactions in compressed batches to the chain's data availability layer\n\nWith PGA, the priority fee determines transactions' order, evaluated in short ordering rounds that run multiple times per block. This ordering model should be familiar to users of other EVM chains (Base, OP Mainnet, and Unichain).\nPGA uses three components that work together:\n\nA two-stage mempool: an unordered waiting list that includes arriving transactions, and a priority queue keyed on each transaction's priority fee.\n\nPGA rounds: short, fixed-length ordering rounds that can run multiple times per block. Each round promotes the waiting list into the priority queue and transfers the queue into the block being built.\nAn anti-starvation priority boost: a position increase applied at the end of each round to transactions that are still waiting, so low-fee and zero-fee transactions rise over time.\n\nOn Arbitrum One, the block time B is 250ms and the proposed number of rounds per block K is 2, giving a nominal round length of 125ms. Let's look at each component.\n\nThe two-stage mempool​\nTransactions arriving at the Sequencer land first in an unordered waiting list. Intake runs continuously and independently of any ordering work.\nAt the start of each PGA round, the entire waiting list is transferred to the second stage: a priority queue keyed on the transaction's priority fee, computed per EIP-1559 as:\npriority_fee_per_gas = min( transaction.max_priority_fee_per_gas, transaction.max_fee_per_gas - block.base_fee_per_gas)\n\nTies are broken by the arrival timestamp recorded when the transaction first reached the Sequencer, not when it entered the queue.\n\nThe queue is re-keyed against the new base fee at the start of every block because the priority fee depends on the base fee, which changes between blocks.\nTransactions remain subject to the prevailing base fee, and the mempool remains private. PGA does not grant anyone the right to view or reorder other users' transactions, so the protections against harmful MEV that Arbitrum users rely on are unchanged.\nPGA rounds​\nThe following parameters define PGA rounds:\n\nthe block time B\nthe proposed number of rounds per block K\n\nA new round begins every B/K. In Arbitrum One, block time B is 250ms, and the number of rounds K is 2, meaning rounds are 125ms.\nK remains adjustable for two years after PGA activates, to any value from 1 to 10 inclusively. That gives round lengths from 250ms down to 25ms.\nEach round has two phases:\n\nThe intake phase runs for the full round window, absorbing new arrivals into the waiting list. It overlaps with the previous round's execute phase.\nThe execute phase begins as soon as intake closes. The waiting list moves into the priority queue, and the Sequencer transfers the queue into the block, highest priority first.\n\nThe transfer loop ends when the queue is empty, the block is full, or the round's time is up. Anything still queued waits for the next round.\nBlocks fill until they reach one of the following:\n\nThe 32 Mgas gas limit target\nThe 95,000-byte calldata limit\nThe end of the round.\n\nThe block hard limit is 64 Mgas, and an individual transaction is capped at 32 Mgas.\nIf a block fills before its last round, the Sequencer finalizes it immediately and starts the first round of the next block rather than idling for the remainder of the window. This is what allows the chain to exceed its nominal block rate under load. Block production is capped at 8 blocks per second; keeping the spacing between rounds consistent makes the anti-starvation policy behave predictably, since building faster would give older transactions an unfair advantage over newer ones.\nYour browser does not support the video tag.\nThe anti-starvation priority boost​\nAt the end of every round in which the priority queue is not empty, each transaction still waiting receives a priority boost of p / (2K), where p is the priority of the last transaction included in the previous round (or zero if that round included none). K is the number of rounds per block.\nTwo properties are worth emphasizing:\n\nThe boost shifts a transaction's position in the queue and nothing else. The fee charged on inclusion is unaffected.\nIt compounds across rounds. A transaction paying no priority fee accumulates boost each round until it outranks the marginal paying transaction, which is what bounds its wait to a small number of blocks. The exact wait depends on the round parameters and on the priority fee the transaction expressed.\n\nWhat changes when PGA activates​\nPGA activates on Arbitrum One some time after the onchain vote passes. On the same day, Timeboost's express lane and its delay logic will be decommissioned:\n\nThe Timeboost autonomous auctioneer stops accepting new bids.\nThe express lane endpoint shuts down.\nThe Sequencer stops enforcing the 200ms delay on transactions outside the express lane. That delay only applied while an express lane controller held the round.\nYou can withdraw funds you still have locked in the Timeboost auction contract at any time.\n\nOn Arbitrum One, PGA sends 97% of the priority fees it collects to the Arbitrum DAO treasury and 3% to the Arbitrum Developer Guild. The DAO accounts for these proceeds periodically and distributes them through a separate vote every six months.Why sunset Timeboost?What are PGA’s benefits?How PGA worksThe two-stage mempoolPGA roundsThe anti-starvation priority boostWhat changes when PGA activates","tokens":2318,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261234502,"hash":"47d7b79ae4e49dc6a1ecaf24d99ac0f580b391f5"}
{"url":"https://specs.optimism.io/protocol/rollup-node.html","domain":"specs.optimism.io","title":"Rollup Node - OP Stack Specification","text":"Rollup Node Specification\n\nTable of Contents\n\nOverview\nDriver\n\nDerivation\n\nL2 Output RPC method\n\nStructures\n\nBlockID\nL1BlockRef\nL2BlockRef\nSyncStatus\n\nOutput Method API\n\nProtocol Version tracking\n\nOverview\nThe rollup node is the component responsible for deriving the L2 chain from L1 blocks\n(and their associated receipts).\nThe part of the rollup node that derives the L2 chain is called the rollup driver. This document is\ncurrently only concerned with the specification of the rollup driver.\nDriver\nThe task of the driver in the rollup node\nis to manage the derivation process:\n\nKeep track of L1 head block\nKeep track of the L2 chain sync progress\nIterate over the derivation steps as new inputs become available\n\nDerivation\nThis process happens in three steps:\n\nSelect inputs from the L1 chain, on top of the last L2 block:\na list of blocks, with transactions and associated data and receipts.\nRead L1 information, deposits, and sequencing batches in order to generate payload attributes\n(essentially a block without output properties).\nPass the payload attributes to the execution engine, so that the L2 block (including output block\nproperties) may be computed.\n\nWhile this process is conceptually a pure function from the L1 chain to the L2 chain, it is in practice incremental. The\nL2 chain is extended whenever new L1 blocks are added to the L1 chain. Similarly, the L2 chain re-organizes whenever the\nL1 chain re-organizes.\nFor a complete specification of the L2 block derivation, refer to the L2 block derivation document.\nL2 Output RPC method\nThe Rollup node has its own RPC method, optimism_outputAtBlock which returns a 32\nbyte hash corresponding to the L2 output root.\nStructures\nThese define the types used by rollup node API methods.\nThe types defined here are extended from the engine API specs.\nBlockID\n\nhash: DATA, 32 Bytes\nnumber: QUANTITY, 64 Bits\n\nL1BlockRef\n\nhash: DATA, 32 Bytes\nnumber: QUANTITY, 64 Bits\nparentHash: DATA, 32 Bytes\ntimestamp: QUANTITY, 64 Bits\n\nL2BlockRef\n\nhash: DATA, 32 Bytes\nnumber: QUANTITY, 64 Bits\nparentHash: DATA, 32 Bytes\ntimestamp: QUANTITY, 64 Bits\nl1origin: BlockID\nsequenceNumber: QUANTITY, 64 Bits - distance to first block of epoch\n\nSyncStatus\nRepresents a snapshot of the rollup driver.\n\ncurrent_l1: Object - instance of L1BlockRef.\ncurrent_l1_finalized: Object - instance of L1BlockRef.\nhead_l1: Object - instance of L1BlockRef.\nsafe_l1: Object - instance of L1BlockRef.\nfinalized_l1: Object - instance of L1BlockRef.\nunsafe_l2: Object - instance of L2BlockRef.\nsafe_l2: Object - instance of L2BlockRef.\nfinalized_l2: Object - instance of L2BlockRef.\npending_safe_l2: Object - instance of L2BlockRef.\nqueued_unsafe_l2: Object - instance of L2BlockRef.\n\nOutput Method API\nThe input and return types here are as defined by the engine API specs.\n\nmethod: optimism_outputAtBlock\nparams:\n\nblockNumber: QUANTITY, 64 bits - L2 integer block number.\n\nreturns:\n\nversion: DATA, 32 Bytes - the output root version number, beginning with 0.\noutputRoot: DATA, 32 Bytes - the output root.\nblockRef: Object - instance of L2BlockRef.\nwithdrawalStorageRoot: 32 bytes - storage root of the L2toL1MessagePasser contract.\nstateRoot: DATA: 32 bytes - the state root.\nsyncStatus: Object - instance of SyncStatus.\n\nProtocol Version tracking\nThe rollup-node should monitor the recommended and required protocol version by monitoring\nthe Protocol Version contract on L1, as specified in the Superchain Version Signaling specifications.\nThis can be implemented through polling in the Driver loop.\nAfter polling the Protocol Version, the rollup node SHOULD communicate it with the execution-engine through an\nengine_signalSuperchainV1 call.\nThe rollup node SHOULD warn the user when the recommended version is newer than\nthe current version supported by the rollup node.\nThe rollup node SHOULD take safety precautions if it does not meet the required protocol version.\nThis may include halting the engine, with consent of the rollup node operator.","tokens":995,"squid":"ink-governance","role":"Council Listener","at":1791261241656,"hash":"19ae4ec2d1d8a9868301fa99eb493d598034b3f7"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/priority-gas-auction/use-fast-feed","domain":"docs.arbitrum.io","title":"How to use the Fast Feed | Arbitrum Docs","text":"✏️Request an updateThis guide is for searchers, propAMM operators, market makers, and anyone else who wants to read onchain data faster. It shows you how to subscribe to the Fast Feed on Arbitrum One, open a connection to it, and keep that connection across rounds.\nIt covers the full path: hash your API key, deposit USDG, read the round state, call purchaseTickets, open an authenticated WebSocket, and automate the purchase with the reference bot.\nIf you don't know what the Fast Feed isThe Fast Feed is a paid WebSocket stream that publishes each transaction as soon as the Sequencer executes it, before its block reaches the free sequencer feed. The introduction to the Fast Feed explains what it publishes, who it serves, and how rounds and prices work.\nThe Fast Feed admits one WebSocket connection per ticket, and a ticket is valid for one round. To keep a connection open, you buy a new ticket every round from the Tickets contract on Arbitrum One.\nPrerequisites​\n\nYou know how Fast Feed rounds and prices work. If not, read the introduction to the Fast Feed and the introduction to PGA, which sets the round cadence.\nAn account on Arbitrum One that holds USDG to pay for tickets and ETH to pay for gas.\nAn Arbitrum One JSON-RPC endpoint.\nFoundry's cast, or any EVM client, to send transactions. The examples use cast and leave out --rpc-url $RPC_URL --private-key $PRIVATE_KEY to stay short.\nA WebSocket client. The examples use wscat or websocat on the command line, the ws package for Node.js, and the websockets package for Python.\n\nAddresses and endpoints​\nItemArbitrum OneFast Feed endpointwss://arb1-txfeed.arbitrum.io/Tickets (proxy)0x451DD62C26b753d07d6104aaC6865AaE73a6A598USDG payment token0x004B506865409877C9fA29bfb1ebA929984B9bbC\nUSDG has 6 decimals, so the 17 USD minimum price is 17000000 in the token's smallest unit. The first round started on September 23, 2026 at 17:00 UTC.\nThe examples below use $FEED_URL, $TICKETS, and $USDG for these values:\nexport FEED_URL=wss://arb1-txfeed.arbitrum.io/export TICKETS=0x451DD62C26b753d07d6104aaC6865AaE73a6A598export USDG=0x004B506865409877C9fA29bfb1ebA929984B9bbC\nStep 1: Generate an API key and its hash​\nYour API key never goes onchain. You register its Keccak-256 hash with the ticket purchase, and you present the raw key when you connect to the Fast Feed. Anyone who holds the key can use your tickets, so treat it like a password.\n\nGenerate a random key and keep it private:\nopenssl rand -hex 32\n\nHash it:\ncast keccak \"<your-api-key>\"\nSave the 32-byte output. You pass it as apiKeyHash in every purchase.\n\nThe hash covers the UTF-8 bytes of the key string exactly as you send it in the Authorization header in step 5. Hash the exact string you send, with no 0x prefix and no surrounding whitespace.\nYou can bind several tickets to one key, in the same round or across rounds. The Fast Feed allows as many open connections per key as that key has active tickets.\nStep 2: Deposit USDG​\nThe contract debits ticket purchases from an internal balance, not from your wallet. Fund that balance before you buy.\n\nApprove the contract to pull USDG. amount is in the token's smallest unit, so 100 USDG is 100000000, enough for five tickets at the 17 USDG minimum price:\ncast send $USDG \"approve(address,uint256)\" $TICKETS <amount>\n\nMove the tokens into your internal balance:\ncast send $TICKETS \"depositToken(uint256)\" <amount>\n\nConfirm the balance:\ncast call $TICKETS \"tokenBalance(address)(uint256)\" <your-address>\n\nDeposit enough for several rounds. The price can rise by up to about two times between rounds, as the rounds and pricing section explains. You can withdraw an unused balance at any time with withdrawToken(amount).\nStep 3: Read the round state​\nA purchase must name the round and the price you expect. The contract reverts if either value has changed, so you never pay a new round's higher price by accident. Read the live values right before you buy:\ncast call $TICKETS \"roundNumber()(uint256)\"cast call $TICKETS \"currentPrice()(uint256)\"cast call $TICKETS \"roundEnd()(uint256)\"cast call $TICKETS \"grandfatherPeriodEnd()(uint256)\"cast call $TICKETS \"grandfatherCount(address)(uint256)\" <your-address>\nViewWhat it tells youroundNumberThe current round. Pass it as expectedRound.currentPriceThe price of every ticket in this round. Pass it as expectedPrice.roundEndUnix time when the round ends and the tickets you buy now become active.grandfatherPeriodEndUnix time when the grandfather period ends. Before it, only buyers from the previous round can buy.grandfatherCountHow many tickets you can still buy during the grandfather period. It equals the tickets you held last round, minus those bought this round.ticketsSoldThisRoundTickets sold so far. Compare it with maxTicketsPerRound to see how much room is left.\nRound state updates lazily: the first state-changing call in a new round rolls it forward. View functions compute the rolled-forward values on the fly, so the values you read are current.\nStep 4: Buy tickets​\nCall purchaseTickets with the values from step 3:\ncast send $TICKETS \\ \"purchaseTickets(uint256,uint256,uint256,bytes32)\" \\ <expectedRound> <expectedPrice> <numTicketsDesired> <apiKeyHash>\nThe contract fills up to numTicketsDesired, capped by the room left in the round, and debits expectedPrice × filled from your internal balance. If the round is close to its cap, you receive and pay for fewer tickets than you asked for. The call reverts only if the round is already sold out.\nEach purchase emits a TicketsPurchased(buyer, round, apiKeyHash, price, numTickets, numTicketsDesired) event. Read numTickets from the receipt to learn how many tickets you got.\nYour tickets become active when the round ends. Until then, tickets from the previous round stay active. If you hold tickets in both rounds under the same key, your connection stays open across the round boundary.\nStep 5: Connect​\nOnce the round in which you bought has ended, open a WebSocket to the Fast Feed endpoint and send your raw API key, not its hash, as a bearer token in the Authorization header of the upgrade request:\nAuthorization: Bearer <your-api-key>\nThe endpoint hashes the key with Keccak-256, compares it against the active tickets, and only then completes the upgrade. Messages start flowing at once. You open one connection per ticket, and each connection receives the full feed. Three rules apply to every client:\n\nComplete the upgrade within 5 seconds, or the endpoint drops the socket.\nSend only ping and pong frames.\nRead as fast as the feed arrives. The endpoint drops a client that lags behind, so parse and process off the read loop.\n\nEvery frame is a binary WebSocket frame that carries one JSON object with one transaction. The what the Fast Feed publishes section lists every field.\nCommand lineNode.jsPythonwscat -c \"$FEED_URL\" -H \"Authorization: Bearer $API_KEY\"import WebSocket from 'ws';const ws = new WebSocket(process.env.FEED_URL, { headers: { Authorization: `Bearer ${process.env.API_KEY}` },});ws.on('unexpected-response', (req, res) => { // 401: unknown key or no active ticket. 429: every ticket already has a connection. console.error(`Rejected: HTTP ${res.statusCode}`); req.destroy(); // with a listener attached, ws leaves the request open});ws.on('message', (data) => { const msg = JSON.parse(data.toString()); // msg.pga_round, msg.transaction.tx_hash, msg.transaction.receipt, ...});ws.on('close', (code, reason) => { console.log('closed', code, reason.toString());});import asyncioimport jsonimport osimport websocketsasync def main(): headers = {\"Authorization\": f\"Bearer {os.environ['API_KEY']}\"} try: async with websockets.connect(os.environ[\"FEED_URL\"], additional_headers=headers) as ws: async for frame in ws: msg = json.loads(frame) # msg[\"pga_round\"], msg[\"transaction\"][\"tx_hash\"], msg[\"transaction\"][\"receipt\"], ... except websockets.InvalidStatus as e: # 401: unknown key or no active ticket. 429: every ticket already has a connection. print(f\"Rejected: HTTP {e.response.status_code}\") except websockets.ConnectionClosed as e: print(f\"closed {e.rcvd.code} {e.rcvd.reason}\")asyncio.run(main())This example needs websockets 14 or later. Older versions use extra_headers= instead of additional_headers=.\nStep 6: Keep the connection across rounds​\nTickets bought in round N are active for round N+1 only, so an uninterrupted connection needs a purchase in every round:\n\nBuy the next round's ticket before roundEnd, with the same apiKeyHash. During the grandfather period you can renew up to the number of tickets you held.\nShortly after a round ends, the endpoint closes every connection whose key holds no ticket in the new round. A key with a ticket in both rounds keeps its connection.\nIf your connection closes, reconnect and continue from the current head. The Fast Feed keeps no history, so the messages sent while you were away are gone.\n\nTo make the purchase step automatic, run the reference bot described in the next section.\nAutomate the purchase with the reference bot​\nBuying by hand every round does not scale. Offchain Labs publishes a TypeScript purchase bot in the feed-ticket-contracts repository. Each round, the bot:\n\nReads the price, round boundaries, and your grandfather count.\nSkips the round if the price exceeds MAX_PRICE_PER_TICKET.\nBuys up to your grandfather count during the grandfather period, then buys the rest after the period ends.\nBefore each transaction, estimates gas and waits until gas × maxFeePerGas fits within MAX_TRANSACTION_FEE.\nSleeps past the round boundary, with random jitter so that bots do not all act at once.\n\nConfigure it with environment variables:\nVariableRequiredDescriptionRPC_URLYesArbitrum One JSON-RPC endpoint.PRIVATE_KEYYes0x-prefixed private key of the account that deposited USDG.TICKETS_ADDRESSYesTickets contract address.TICKETS_PER_ROUNDYesNumber of tickets to buy each round.MAX_PRICE_PER_TICKETYesHighest price per ticket you accept, in the token's smallest unit.MAX_TRANSACTION_FEEYesHighest total gas fee per purchase, in wei.API_KEY_HASHYesKeccak-256 hash of your API key, from step 1.MAX_SCHEDULE_JITTER_MSNoUpper bound of the random delay added at round boundaries. Default 30000.GAS_POLL_INTERVAL_MSNoHow often to re-check gas while waiting for it to fit the budget. Default 10000.BOUNDARY_BUFFER_MSNoDelay after a round or grandfather boundary before acting, so the chain has passed it. Default 2000.PRIORITY_FEE_PER_GASNoEIP-1559 priority fee per gas, in wei. Default 0.BASE_FEE_BOOST_PERCENTNoPercentage added to the latest base fee when computing maxFeePerGas. Default 20.\nRun it with Docker:\ngit clone https://github.com/OffchainLabs/feed-ticket-contracts.gitcd feed-ticket-contracts/botdocker build -t purchase-bot .docker run --rm \\ -e RPC_URL=$RPC_URL \\ -e PRIVATE_KEY=$PRIVATE_KEY \\ -e TICKETS_ADDRESS=$TICKETS \\ -e TICKETS_PER_ROUND=1 \\ -e MAX_PRICE_PER_TICKET=<amount> \\ -e MAX_TRANSACTION_FEE=<wei> \\ -e API_KEY_HASH=<apiKeyHash> \\ purchase-bot\nTwo behaviors to plan for:\n\nThe bot does not deposit funds. Keep the internal balance topped up with depositToken, as in step 2. A purchase that finds an empty balance reverts, and the bot skips that round.\nThe bot exits on RPC or network errors. It treats a contract revert as a skipped round and continues, but any transport failure ends the process. Run it under a supervisor that restarts it, such as Docker --restart=always, Kubernetes, or systemd.\n\nTroubleshoot​\nPurchase reverts​\nRevertCauseFixRoundNumberMismatch(expected, actual)The round advanced between your read and your transaction.Re-read roundNumber and currentPrice, then retry.IncorrectTicketPrice(expected, actual)The price changed, which happens at a round boundary.Re-read currentPrice and decide whether the new price fits your budget.MaxTicketsSold()The round is sold out.Wait for the next round. Buy earlier in the round, or hold tickets so you can buy during the grandfather period.InsufficientTokenBalance(balance, required)Your internal balance is below expectedPrice × numTicketsDesired.Deposit more USDG with depositToken.NotEnoughGrandfatheredTickets(held, requested)You asked for more tickets than your grandfather count during the grandfather period.Request at most grandfatherCount, or wait until grandfatherPeriodEnd.BeforeFirstRoundStart()The first round has not started.Wait for the configured first round start.ZeroTicketsRequested()numTicketsDesired was 0.Request at least one ticket.\nConnection rejected or closed​\nResponseCauseFixHTTP 401 UnauthorizedThe Authorization header is missing, or the key's hash has no active ticket.Check the raw key and its hash. Tickets bought this round activate at roundEnd.HTTP 429 Too Many RequestsThe key already has as many open connections as it has active tickets.Close a connection, or buy more tickets for the next round.HTTP 426 Upgrade RequiredThe request was not a WebSocket upgrade, for example a plain HTTPS GET.Use a WebSocket client.Close 1008, authentication expiredThe round ended and your key holds no ticket in the new round.Buy before roundEnd each round, then reconnect.Close 1013, client laggedYour client fell more than 2048 messages behind.Drain the socket faster. Move parsing and processing off the read loop, then reconnect.Close 1003, unexpected client messageYour client sent a data frame.Send only ping and pong frames.Close 1011, server shutting downThe endpoint restarted.Reconnect with a short backoff.\nFAQ​\nWhich token pays for tickets?\nUSDG on Arbitrum One. The token is fixed when the contract is deployed and cannot change. On Arbitrum Sepolia, a test token is available on request.\nWhen does my ticket start working?\nAt the end of the round in which you buy it. It stays active until the end of the next round.\nWhat happens to money I do not spend?\nIt stays in your internal balance. Withdraw it at any time with withdrawToken(amount).\nDo I need a Nitro node?\nNo. The Fast Feed is a stream for your own client. To follow the chain, use the free sequencer feed instead.PrerequisitesAddresses and endpointsStep 1: Generate an API key and its hashStep 2: Deposit USDGStep 3: Read the round stateStep 4: Buy ticketsStep 5: ConnectStep 6: Keep the connection across roundsAutomate the purchase with the reference botTroubleshootPurchase revertsConnection rejected or closedFAQ","tokens":3572,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261244321,"hash":"bc4e53f8c4026c14a7b35f549eb7ea9ac468dc8c"}
{"url":"https://specs.optimism.io/background.html","domain":"specs.optimism.io","title":"Background - OP Stack Specification","text":"Background\n\nTable of Contents\n\nOverview\nFoundations\n\nEthereum Scalability\nOptimistic Rollups\nEVM Equivalence\n\nProtocol Guarantees\n\nLiveness\nValidity\nAvailability\n\nNetwork Participants\n\nUsers\nSequencers\nVerifiers\n\nKey Interaction Diagrams\n\nDepositing and Sending Transactions\nWithdrawing\n\nNext Steps\n\nOverview\nThe OP Stack is a decentralized software stack maintained by the OP Stack that forms the backbone of blockchains like\nOP Mainnet and Base. The OP Stack provides the infrastructure for\noperating EVM equivalent rollup blockchains designed to scale Ethereum while remaining maximally compatible with\nexisting Ethereum infrastructure. This document provides an overview of the protocol to provide context for the rest of\nthe specification.\nFoundations\nEthereum Scalability\nScaling Ethereum means increasing the number of useful transactions the Ethereum network can process. Ethereum's\nlimited resources, specifically bandwidth, computation, and storage, constrain the number of transactions which can be\nprocessed on the network. Of the three resources, computation and storage are currently the most significant\nbottlenecks. These bottlenecks limit the supply of transactions, leading to extremely high fees. Scaling ethereum and\nreducing fees can be achieved by better utilizing bandwidth, computation and storage.\nOptimistic Rollups\nAn Optimistic Rollup is a layer 2 scalability construction which\nincreases the computation & storage capacity of Ethereum while aiming to minimize sacrifices to scalability or\ndecentralization. In a nutshell, an Optimistic Rollup utilizes Ethereum (or some other data availability layer) to host\ntransaction data. Layer 2 nodes then execute a state transition function over this data. Users can propose the result of\nthis off-chain execution to a smart contract on L1. A \"fault proving\" process can then demonstrate that a user's proposal\nis (or is not) valid.\nEVM Equivalence\nEVM Equivalence is complete compliance\nwith the state transition function described in the Ethereum yellow paper, the formal definition of the protocol. By\nconforming to the Ethereum standard across EVM equivalent rollups, smart contract developers can write once and deploy\nanywhere.\nProtocol Guarantees\nWe strive to preserve three critical properties: liveness, validity, and availability.\nA protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.\nLiveness\nLiveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within\na bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more\nthan this bounded time period. This bounded time period should also be acceptable such that inclusion is not just\ntheoretically possible but practically useful.\nValidity\nValidity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower\nbound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for\na smart contract on Ethereum to be able to validate this state transition function economically.\nAvailability\nAvailability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state\ntransition function correctly. Availability is essentially an element of validity and is required to be able to guarantee\nvalidity in general. Similar to validity, availability is subject to lower bound resource requirements.\nNetwork Participants\nGenerally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers.\n\nUsers\nUsers are the general class of network participants who:\n\nSubmit transactions through a Sequencer or by interacting with contracts on Ethereum.\nQuery transaction data from interfaces operated by verifiers.\n\nSequencers\nSequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to\nutilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a\nsingle active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for\neither a single Sequencer or a consensus protocol of multiple Sequencers.\nThe Sequencer:\n\nAccepts transactions directly from Users.\nObserves \"deposit\" transactions generated on Ethereum.\nConsolidates both transaction streams into ordered L2 blocks.\nSubmits information to L1 that is sufficient to fully reproduce those L2 blocks.\nProvides real-time access to pending L2 blocks that have not yet been confirmed on L1.\n\nThe Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally\nresponsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently\nbe possible if users were to submit all transactions directly to L1.\nVerifiers\nVerifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain\nthe integrity of the network and serve blockchain data to Users.\nVerifiers generally:\n\nDownload rollup data from L1 and the Sequencer.\nUse rollup data to execute the L2 state transition function.\nServe rollup data and computed L2 state information to Users.\n\nVerifiers can also act as Proposers and/or Challengers who:\n\nSubmit assertions about the state of the L2 to a smart contract on L1.\nValidate assertions made by other participants.\nDispute invalid assertions made by other participants.\n\nKey Interaction Diagrams\nDepositing and Sending Transactions\nUsers will often begin their L2 journey by depositing ETH from L1.\nOnce they have ETH to pay fees, they'll start sending transactions on L2.\nThe following diagram demonstrates this interaction and all key OP Stack components which are or should be utilized:\n\nWithdrawing\nUsers may also want to withdraw ETH or ERC20 tokens from an OP Stack chain back to Ethereum. Withdrawals are initiated\nas standard transactions on L2 but are then completed using transactions on L1. Withdrawals must reference a valid\nFaultDisputeGame contract that proposes the state of the L2 at a given point in time.\n\nNext Steps\nCheck out the sidebar to the left to find any specification you might want to read, or click one of the links embedded\nin one of the above diagrams to learn about particular components that have been mentioned.","tokens":1629,"squid":"ink-governance","role":"Council Listener","at":1791261255585,"hash":"fc3778f40be1db0afbed6762d1fc289ddb07debb"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/priority-gas-auction/fast-feed","domain":"docs.arbitrum.io","title":"Introduction to the Fast Feed | Arbitrum Docs","text":"✏️Request an updateThe Fast Feed is a paid, authenticated WebSocket stream that publishes each transaction as soon as the Sequencer has ordered and executed it, before the block that contains it reaches the standard sequencer feed.\nOn Arbitrum One, Priority Gas Auction (PGA) rounds run every 125ms inside a 250ms block. The Fast Feed publishes within those rounds, so you see ordered transactions without waiting for the block to close.\nPGA rounds set the cadence of the Fast Feed. To understand the rounds themselves, read the introduction to PGA first.\nWhat the Fast Feed does not do​\n\nIt does not give you a view into the mempool. The Fast Feed publishes a transaction only after the Sequencer has ordered and executed it. Nobody can influence or change that order afterward, so the Fast Feed does not enable frontrunning or sandwich attacks. The Sequencer's mempool stays private.\nIt does not publish state. You receive a list of transactions and a partial receipt for each one. You do not receive state changes or partial blocks.\nIt does not let you follow the chain. A Nitro node cannot consume the Fast Feed, and the Fast Feed gives you no way to track chain state. Subscribers write their own client. To follow the chain, use the standard sequencer feed instead.\n\nWho is the Fast Feed for​\nAny application or user that is latency sensitive gains from reading ordered transactions sooner. The following groups benefit most from subscribing:\n\nSearchers react to ordered transactions sooner, whether they run arbitrage between a centralized and a decentralized exchange, liquidations, or back-running strategies.\npropAMMs confirm faster whether their most recent price updates have landed.\nMarket makers update pricing models earlier in the round.\n\nIf you send ordinary transactions through a wallet or an app, the Fast Feed does not affect you. It doesn't change the ordering, the inclusion guarantee, or the fee that anyone pays.\nWhat the Fast Feed publishes​\nEach message is a FeedMessage envelope that carries one transaction plus the metadata you need to place it in time and in order. The Sequencer sends each message as a JSON object inside a binary WebSocket frame, so byte fields arrive as hex-encoded strings.\nFieldTypeDescriptionversionnumberProtocol version, for forward compatibility (currently 1)timestamp_msnumberUnix time in milliseconds when the Sequencer created the messagepga_roundnumber, optionalThe PGA round this transaction belongs to, within the block, starting at 1transactionobjectThe transaction data and its partial receipt\nThe transaction object carries the transaction itself:\nFieldTypeDescriptionblock_numbernumberTentative block number, not guaranteed to be finaltx_indexnumberPosition within the block so farraw_txstringHex-encoded, RLP-encoded signed transactiontx_hashstringHex-encoded transaction hashreceiptobjectExecution result\nThe receipt reports status, gas_used, gas_used_for_l1, cumulative_gas_used, effective_gas_price, base_fee, any contract_address the transaction created, and the event logs it emitted.\nLimits to design for​\nThe Fast Feed trades guarantees for speed. Three consequences shape how you write a client.\nInclusion is not guaranteed. The block_number you receive is tentative. The Sequencer publishes a transaction to the Fast Feed before it stores that transaction, which is part of what makes the feed fast. If the Sequencer fails partway through a block, the transactions it already published are lost, and another Sequencer starts a new block from scratch. The Sequencer almost never fails this way, so a PGA round rarely loses or reorders the transactions it published.\nReceipts are partial. A receipt omits block_hash, because the block is not final when the Sequencer publishes it.\nThere is no replay. The Fast Feed caches nothing. You subscribe at the head and receive only the messages sent from that point onward. If your connection drops, the messages sent while you were away are gone.\nNoteTreat the Fast Feed as an early signal, not as a record. Confirm final state against a node or the standard sequencer feed.\nHow subscription access works​\nAccess runs on tickets sold by the Tickets contract, an audited contract on Arbitrum One that the AIP and the audit call the Fast Feed Payment Contract. You prove your subscription with an API key that never appears onchain.\n\nGenerate an API key. Keep the key itself private.\nBuy a ticket. Send a payment transaction to the Tickets contract that includes the Keccak-256 hash of your key. The contract records that hash as your Subscription Credential.\nConnect. Present your raw API key to the Fast Feed endpoint. The endpoint hashes it with Keccak-256 and compares the result against the recorded credential to admit or deny the connection.\n\nYour access starts at the end of the round in which you buy the ticket. You can rotate your credential only when you buy a ticket for a new round.\nFor the contract calls, the WebSocket handshake, the reference purchase bot, and the errors you can hit, see how to use the Fast Feed.\nRounds and pricing​\nThe contract sells tickets in fixed rounds and prices them with the mechanism defined in EIP-4844. Every ticket in a round costs the same. Demand in one round sets the price for the next: sales above the target push the price up, sales below it push the price down, and the price never falls below the floor.\nParameterValueRound duration24 hoursTarget tickets per round100Maximum tickets per round200Minimum price17 USDPrice update fraction144Grandfather period fractionAbout half the round\nThese are the values the Tickets contract on Arbitrum One returns at the time of writing. A price update fraction of 144 means the next round can cost at most about twice the current price, and at least about half of it.\nEach round opens with a grandfather period that covers about half its length. During that period, only subscribers from the previous round can buy, up to the number of tickets they held. Sales then open to everyone until the round hits its maximum.\nInfoThe Arbitrum DAO controls these parameters and can change any of them. A change takes effect at the next round, so it can wait up to 24 hours.\nWhere the revenue goes​\nThe contract accepts payment in USDG, an ERC-20, USD-backed stablecoin. It sends proceeds to a dedicated RewardDistributor contract, which routes 97% to the Arbitrum DAO Treasury and 3% to the Arbitrum Developer Guild. Every subscription payment and every distribution emits an onchain event, so anyone can audit the flow.\nThis split follows the framework that Timeboost established, which keeps Arbitrum's ordering-related revenue products aligned.\nInfoThe Arbitrum Treasury Management (ATM) Council and OAT selected USDG as the stablecoin. The Tickets and USDG addresses are listed in how to use the Fast Feed.\nTrail of Bits audited both contracts before deployment. The Tickets contract is audited under the name \"Sequencer Feed Ticketing\", so read the Sequencer Feed Ticketing report for that contract, and the Reward Distributor Fixes report for the RewardDistributor. The security audit reports page lists every Arbitrum audit.\nFast Feed compared with the sequencer feed​\nThe two feeds serve different jobs. Running one does not replace the other.\nPropertySequencer feedFast FeedCostFreePaid subscriptionAuthenticationNoneAPI key against an onchain credentialGranularityPer blockPer transaction, within a PGA roundClientNitro node or feed relayYour own clientFollows a chainYesNoAvailabilityEvery Arbitrum chainArbitrum One\nTo work with the standard feed, see how to read the sequencer feed.What the Fast Feed does not doWho is the Fast Feed forWhat the Fast Feed publishesLimits to design forHow subscription access worksRounds and pricingWhere the revenue goesFast Feed compared with the sequencer feed","tokens":1953,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261255639,"hash":"891a3b10753f51e06968b4b5c5448bfc9cc0e64f"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/reference/stf-inputs","domain":"docs.arbitrum.io","title":"Inputs to the State Transition Function | Arbitrum Docs","text":"✏️Request an updateArbitrum nodes receive transaction inputs through two channels:\n\nNodes subscribe to the Sequencer feed and receive upcoming ordered transactions published in real time. To learn more, refer to the real-time sequencer feed documentation.\nNodes also subscribe to the SequencerBatchDelivered event on the parent chain. This event occurs whenever a batch of transactions gets delivered to the parent chain via the batch poster. Upon receiving this event, nodes verify that the transactions recorded on the parent chain match those from the Sequencer feed. If discrepancies arise, nodes reorganize to adopt the transactions confirmed on the parent chain, treating it as the definitive source of truth.\n\nThese two channels suit different applications. To choose between them, see when to rely on soft finality versus hard finality.\nThe Fast Feed on Arbitrum One is not a third channel. It is a read-only stream for latency-sensitive subscribers, and a Nitro node cannot consume it or follow the chain with it. It delivers no input to the STF.\nThese transactions serve as inputs for the State Transition Function (STF).\nMessage types​\nArbitrum supports multiple message types. These messages fall into two broad categories:\n\nMessages submitted directly to the Sequencer as child chain messages\nMessages submitted to the parent chain\n\nFor other message types, see the parent-to-child chain messaging documentation.\nIn the system, we refer to these messages as L1IncomingMessage (inspect the source code reference).\nWhen submitted to the Sequencer feed, messages receive unique identifiers for proper routing. Below is the list of message types, their associated constant values, and descriptions:\nuint8 constant L2_MSG = 3;uint8 constant L1MessageType_L2FundedByL1 = 7;uint8 constant L1MessageType_submitRetryableTx = 9;uint8 constant L1MessageType_ethDeposit = 12;uint8 constant L1MessageType_batchPostingReport = 13;uint8 constant L2MessageType_unsignedEOATx = 0;uint8 constant L2MessageType_unsignedContractTx = 1;uint8 constant ROLLUP_PROTOCOL_EVENT_TYPE = 8;uint8 constant INITIALIZATION_MSG_TYPE = 11;\nMessage TypeValueDescriptionL2MessageType_unsignedEOATx0Unsigned child chain messages from EOAs submitted to the parent chain.L2MessageType_unsignedContractTx1Unsigned child chain messages submitted to the parent chain.L2_MSG3Child chain messages submitted directly to the Sequencer.L1MessageType_L2FundedByL17Child chain messages that go to the parent chain's delayed inbox, with funding provided on the parent chain itself.ROLLUP_PROTOCOL_EVENT_TYPE8Arbitrum Classic used it for messages sent to bridge; Nitro does not use it.L1MessageType_submitRetryableTx9Submitting parent chain messages to the child chain via retryable tickets.INITIALIZATION_MSG_TYPE11The first message added to a new Rollup inbox. Its presence indicates proper initialization of the Rollup.L1MessageType_ethDeposit12Child chain messages that handle deposits of native tokens (ETH) into the child chain.L1MessageType_batchPostingReport13Used by the Sequencer to update the pricing model based on payment(s) by the batch poster.\nThese identifiers enable nodes to route messages correctly.Message types","tokens":798,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261277449,"hash":"82e3ce534430b66667b99ae124d379e56e1ba5a8"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/59","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 54 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n post by pipermerriam on May 20, 2025\n\n post by peersky on May 20, 2025\n\n post by peersky on May 20, 2025\n\n post by MicahZoltu on May 21, 2025\n\n post by MicahZoltu on May 21, 2025\n\n post by pipermerriam on May 21, 2025\n\n post by MicahZoltu on May 21, 2025\n\n post by SCBuergel on May 22, 2025\n\n post by MicahZoltu on May 22, 2025\n\n post by pipermerriam on May 22, 2025\n\n post by MicahZoltu on May 22, 2025\n\n post by pipermerriam on May 23, 2025\n\n post by Olshansky on May 24, 2025\n\n post by kladkogex on May 26, 2025\n\n post by MicahZoltu on May 27, 2025\n\n post by peersky on May 27, 2025\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":1175,"squid":"ink-research","role":"Deep Scholar","at":1791261284600,"hash":"5deae3a97c818894a7c9be2ac5dc90375cbd94cf"}
{"url":"https://governance.aave.com/c/risk/assets-assessments/31","domain":"governance.aave.com","title":"Latest Risk/Assessments topics - Aave","text":"Latest topics in Assessments\n\n Risk\n\n Assessments\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Assessments category\n\n A dedicated home for per-asset risk and technical assessments on Aave Protocol, covering both pre-listing evaluations and the continuous monitoring that follows once an asset is live. \nWhat this category is for\nThis cate…\n\n read more\n\n 0\n\n 69\n\n Jun 26\n\n Syrup USDC (syrupUSDC) on Aave Arc Assessments\n\n 1\n\n 84\n\n 7d\n\n Coinbase B20 Equities on Base Assessments\n\n 1\n\n 153\n\n 12d\n\n Ethena USDe on Aave Avalanche Assessments\n\n 1\n\n 101\n\n Sep 18\n\n Wrapped Ether (WETH) on Aave Arc Assessments\n\n 2\n\n 170\n\n Sep 18\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n 2\n\n 105\n\n Sep 18\n\n Circle EUR (EURC) on Aave Arc Assessments\n\n 2\n\n 87\n\n Sep 18\n\n Circle USD (USDC) on Aave Arc Assessments\n\n 2\n\n 99\n\n Sep 18\n\n EUR CoinVertible (EURCV) on Aave Ethereum\n\n 1\n\n 100\n\n Sep 17\n\n BTC.b on Aave Ethereum\n\n 1\n\n 75\n\n Sep 16\n\n Mainnet wstETH Liquidation Assessment: Financing Remains Unverified\n\n 0\n\n 79\n\n Sep 15\n\n AL Technical Assessment Aave <> Arc\n\n 0\n\n 141\n\n Sep 14\n\n Circle USD (USDC) on Aave X Layer Assessments\n\n 2\n\n 273\n\n Sep 10\n\n Paxos Gold (PAXG) on Aave Ethereum Assessments\n\n 2\n\n 417\n\n Aug 19\n\n Syrup USDC (syrupUSDC) on Aave Monad Assessments\n\n 2\n\n 214\n\n Aug 5\n\n Maple Syrup USDG (syrupUSDG) on Aave Ethereum\n\n 2\n\n 392\n\n Jul 20\n\n Agora USD (AUSD) on Aave Monad Assessments\n\n 2\n\n 279\n\n Jul 1\n\n Coinbase Wrapped BTC (cbBTC) on Aave Monad Assessments\n\n 1\n\n 133\n\n Jul 1\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n 1\n\n 109\n\n Jul 1\n\n Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\n\n 1\n\n 125\n\n Jul 1\n\n Wrapped Ether (WETH) on Aave Monad Assessments\n\n 1\n\n 90\n\n Jul 1\n\n MetaMask USD (mUSD) on Aave Monad Assessments\n\n 1\n\n 159\n\n Jul 1\n\n Staked USDe (sUSDe) on Aave Monad Assessments\n\n 1\n\n 97\n\n Jul 1\n\n USDe (USDe) on Aave Monad Assessments\n\n 1\n\n 148\n\n Jul 1\n\n USD Coin (USDC) on Aave Monad Assessments\n\n 1\n\n 169\n\n Jul 1","tokens":502,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261284648,"hash":"83d2ba0608d001a2787d7b2cdb3a2c0159281299"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l1-to-l2-messaging","domain":"docs.arbitrum.io","title":"Bridging from a parent chain to a child chain | Arbitrum Docs","text":"✏️Request an updateLooking for implementation guides?This document explains the protocol-level concepts of parent-to-child messaging. For practical, step-by-step instructions on implementing bridging and messaging, see How to bridge from parent chain to child chain.\nIn the Bypassing the Sequencer section, we introduced an alternative way for users to submit transactions to a child chain by going through the parent chain's Delayed Inbox contract instead of sending them directly to the Sequencer. This approach is one example of a parent-to-child messaging path. More broadly, parent-to-child chain messaging covers all ways to:\n\nSubmit a child chain bound transaction from a parent chain\nDeposit ETH or native tokens from a parent chain to a child chain\nSend arbitrary data or instructions from a parent chain to a child chain\n\nWe generally categorize these parent-to-child chain messaging methods as follows:\n\nNative token bridging: Refers to depositing a child chain's native token from the parent chain to the child chain. Depending on the type of Arbitrum chain, this can include:\n\n**ETH Bridging**: For Arbitrum chains that use ETH as their gas token, users can deposit **ETH** onto a child chain via the Delayed Inbox.\nCustom gas token bridging: For Arbitrum chains that use a custom gas token, users can deposit that chain's native token to a child chain using the same mechanism.\n\nTransaction via the Delayed Inbox: As described in the Bypassing the Sequencer section, this method allows users to send transactions through the parent chain. It includes two sub-types of messages:\n\nUnsigned messages: General arbitrary data or function calls\nSigned messages: Messages that include a signature, enabling certain authenticated actions\n\nRetryable tickets are Arbitrum's canonical mechanism for creating parent-to-child messages–transactions initiated on a parent chain that trigger execution on a child chain. This method contains the following functionality:\n\nGeneral retryable messaging: For sending arbitrary data or calls from a parent-to-child chain.\nCustomized feature messaging (e.g., token bridging): Leveraging retryable tickets (and other messaging constructs) for specialized actions, such as bridging tokens from a parent-to-child chain.\n\nThis section will explore these categories in detail and explain how they work. The diagram below illustrates the various paths available for parent-to-child chain communication and asset transfers.\n\nNative token bridging​\nNative token bridging refers to depositing a chain's native currency (the token used to pay gas fees) from the parent chain to the child chain. This follows a different, simpler process than ERC-20 token bridging through the canonical token bridge.\nArbitrum chains can use ETH or any other ERC-20 tokens as their gas fee currency. Arbitrum One and Nova use ETH as their native token, while some Arbitrum chains opt for a custom gas token. For more details about chains that use custom gas tokens, refer to the Custom gas token SDK.\nWhether a chain uses ETH or a custom gas token, users can deposit tokens from a parent chain (for Arbitrum One, Ethereum) into a child chain. Below, we describe how to deposit ETH on chains that use ETH as the native gas token. The process for depositing custom gas tokens follows the same steps, except it uses the chain’s Delayed Inbox contract.\nDepositing native tokens​\nA special message type exists for simple native token deposits from parent-to-child chains. The Inbox contract's depositEth method provides this functionality for chains using ETH, while custom gas token chains use similar mechanisms through their Delayed Inbox contract.\nFor step-by-step instructions on depositing native tokens, see How to bridge from parent chain.\nHow deposits work​\nWhen you call Inbox.depositEth, the ETH is sent to the bridge contract on the parent chain. The bridge then \"credits\" the deposited amount to the designated address on the child chain. From the L1 perspective, the funds are held in Arbitrum’s bridge contract on your behalf.\nA diagram illustrating this deposit process is below:\nNote on caller type and aliasing:\n\nIf the parent chain caller is an Externally Owned Account (EOA):\n\nThe deposited ETH will appear in the same EOA address on the child chain.\n\nIf the parent chain caller is a contract:\n\nThe ETH will get deposited into the contract's aliased address on the child chain. In the next section, we will cover Address aliasing.\n\nIf the caller is a 7702-enabled account (EOA with temporary contract code):\n\nThe ETH goes to the aliased address, similar to contracts. This is due to the presence of runtime code during execution, and ensures consistent aliasing behavior post-EIP-7702.\n\nAddress aliasing​\nAll unsigned messages submitted through the Delayed Inbox have their sender addresses \"aliased\" when executed on the child chain. Instead of returning the parent chain sender's address as msg.sender, the child chain sees the \"child alias\" of that address. Formally, the child alias calculation is:\nChild_Alias = Parent_Contract_Address + 0x1111000000000000000000000000000000001111\nWhy aliasing?​\nAddress aliasing in Arbitrum is a security measure that prevents cross-chain exploits. Without it, a malicious actor could impersonate a contract on a child chain by simply sending a message from that contract's parent chain address.\nBy introducing an offset, Arbitrum ensures that child-chain contracts can distinguish between parent-chain contract calls and those from child-chain native addresses.\nComputing the original parent chain address​\nIf you need to recover the original parent chain address from an aliased child chain address onchain, you can use Arbitrum's AddressAliasHelper library. This library allows you to translate between the aliased child address and the original parent address in your contract logic.\nmodifier onlyFromMyL1Contract() override { require(AddressAliasHelper.undoL1ToL2Alias(msg.sender) == myL1ContractAddress, \"ONLY_COUNTERPART_CONTRACT\"); _;}\nTransacting via the Delayed Inbox​\nArbitrum provides a Delayed Inbox contract on the parent chain that can deliver arbitrary messages to the child chain. This functionality is important for two reasons:\n\nGeneral cross-chain messaging: Allows a parent-chain EOA or contract to send messages or transactions to a child chain. This functionality is critical for bridging assets (other than the chain's native token) and performing cross-chain operations.\nCensorship resistance: It ensures the Arbitrum chain remains censorship-resistant, even if the Sequencer misbehaves or excludes certain transactions; refer to Bypassing the Sequencer for more details.\n\nUsers can send child chain transactions through the Delayed Inbox in two primary ways:\n\nGeneral child chain messaging\nRetryable tickets\n\nGeneral child chain messaging​\nAny message sent via the Delayed Inbox can ultimately produce a transaction on the child chain. These messages may or may not include a signature.\n\nSigned messages: Signed by an EOA on the parent chain. This signature proves the sender is an EOA rather than a contract, preventing certain cross-chain exploits and bypassing the need for aliasing.\nUnsigned messages: These do not include an EOA's signature. For security reasons, the sender’s address on the child chain must be aliased when the message gets executed; see the Address aliasing section for details.\n\nBelow, we describe the Delayed Inbox methods for each scenario.\nSigned messages​\nSigned messages let a parent chain EOA prove ownership of an address, ensuring the child chain transaction executes with msg.sender set to the signer's address on the child chain (rather than an alias). This mechanism is beneficial for bypassing the Sequencer if:\n\nYou want to force-include a transaction on a child chain in case of Sequencer downtime or censorship.\nYou need an operation on a child chain that explicitly requires EOA authorization (e.g., a withdrawal).\n\nWhen submitting through the Delayed Inbox, a child chain transaction signature gets included in the message's calldata. Because it matches the EOA's signature, the child chain can safely treat the signer's address as the sender.\nThe Delayed Inbox provides two methods for signed messages: sendL2Message (more flexible, can be called by EOAs or contracts) and sendL2MessageFromOrigin (cheaper gas costs, EOA-only). For implementation details, see Sending signed messages.\nUnsigned messages​\nUnsigned messages allow a parent chain sender to specify transaction parameters without an EOA signature. Because there is no signature, the sender's address must be aliased on the child chain (see the Address aliasing section for the rationale).\nThe Delayed Inbox provides methods for unsigned messages from both EOAs and contracts, with variants for whether funds are transferred from the parent chain or drawn from the child chain balance. For implementation details and method signatures, see Sending unsigned messages.\nMessage types​\nArbitrum Nitro defines various message types to distinguish between the categories described above (signed vs. unsigned, EOAs vs. contracts, etc.). These message types help the protocol route and process each incoming message securely.\nFor the full list of message-type identifiers used by ArbOS, see L1IncomingMessage and the ArbOS messages section.\nnoteRefer to the Address aliasing discussion for more background. This mechanism ensures that a parent chain contract can't impersonate a child chain address unless it provides a valid signature as an EOA.\nRetryable tickets​\nRetryable tickets are Arbitrum's canonical method for creating parent-to-child chain messages—parent-chain transactions that initiate a message to be executed on a child chain. A retryable is submittable for a fixed cost (dependent only on its calldata size) paid at the parent chain. Critically, the ticket's submission on the parent chain is separable and asynchronous from its execution on the child chain. This design provides atomicity for cross-chain operations: if the parent chain transaction to request submission succeeds (doesn't revert), then the execution of the retryable on the child chain has a strong guarantee to eventually succeed.\nFor step-by-step instructions on creating retryable tickets, including parameter estimation and SDK usage, see Creating retryable tickets.\nRetryable ticket lifecycle​\nThe lifecycle of a retryable ticket involves three stages: submission, automatic redemption, and manual redemption.\nSubmission​\nCreating a retryable ticket is initiated with a call to the createRetryableTicket function of the inbox contract. Key parameters include the destination address, call value, gas limits, refund addresses, and calldata. The ticket requires sufficient funds to cover both submission costs and gas for child chain execution. Upon successful submission, a unique TicketID is created and the ArbRetryableTx precompile emits a TicketCreated event.\nAutomatic redemption​\nUpon successful ticket creation, the system checks if conditions are met for automatic redemption: the user's child chain balance must cover the gas costs, and the provided maxFeePerGas must meet or exceed the child chain base fee. If these conditions are met, the system automatically attempts to execute the ticket (auto-redeem).\nIf auto-redemption succeeds, the ticket executes immediately with the original parameters, and excess fees are refunded. If auto-redemption fails (for example, due to insufficient gas or an increase in gas prices), the ticket remains in the retryable buffer for up to one week, allowing for manual redemption.\nManual redemption​\nIf automatic redemption fails, anyone can manually redeem the ticket by calling the ArbRetryableTx precompile's redeem method. The manual redemption attempt donates its call gas to the execution, and the gas limit is not constrained by the original ticket parameters. This allows tickets to be retried with different gas conditions.\nTickets remain in the retryable buffer for one week. If not successfully redeemed within this period, the ticket expires and is automatically discarded. However, tickets can be kept alive indefinitely by paying a fee to extend the lifetime for another full period before expiration.\nIf a ticket expires without successful redemption, the escrowed callValue is refunded to the callValueRefundAddress specified during submission. This protects user funds even if execution never succeeds.\nReceipt types​\nRetryable tickets produce two types of receipts:\n\nTicket creation receipt: Confirms successful ticket creation and includes a TicketCreated event with the ticketId\nRedeem attempt receipt: Records each redemption attempt and includes a RedeemScheduled event\nOnly one successful redemption can occur per ticket. Multiple failed redemption attempts each produce a receipt until one succeeds.\n\nToken bridging​\nRetryable tickets power Arbitrum's canonical token bridge. For the full token bridge architecture, including how ETH and ERC-20 tokens are bridged between layers, see the Token bridging overview.Native token bridgingDepositing native tokensAddress aliasingTransacting via the Delayed InboxGeneral child chain messagingSigned messagesUnsigned messagesMessage typesRetryable ticketsRetryable ticket lifecycleToken bridging","tokens":3322,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261288276,"hash":"e67a423aa2e9f4a37c17088fcf163621e0ba73e7"}
{"url":"https://governance.aave.com/t/eur-coinvertible-eurcv-on-aave-ethereum/25655","domain":"governance.aave.com","title":"EUR CoinVertible (EURCV) on Aave Ethereum - Risk / Assessments - Aave","text":"EUR CoinVertible (EURCV) on Aave Ethereum \n\n RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 17\n\n 1 / 2\n\n Sep 17\n\n Sep 17\n\n post by LlamaRisk on Sep 17\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of EURCV on Aave Ethereum.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 10\n min\n\n post by LlamaRisk on Sep 17\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk conditionally supports the listing of EURCV on Aave V4, pending the launch of the bug bounty program. The Euro-denominated asset represents a 1:1 reserve-backed stablecoin issued by Societe Generale-Forge, which holds its underlying collateral in a segregated account managed by Societe Generale. EURCV operates similarly to other centrally issued stablecoins, with the issuer ultimately retaining access control privileges and a gated minting/redemption flow accessible only to KYC/KYB entities and, more broadly, via secondary markets and partners.\nOffchain and onchain mechanisms control the assets’ collateralization, with automated systems enabling continuous minting/redemption flows for permissioned users (Preferred partners and the issuer). No bug bounty is currently active, and the team indicates that one will be introduced. Reserve attestations are currently reported by the issuer, with audited 3rd party attestations to be introduced. EURCV has kept a relatively tight peg to the Euro, comparable to EURC since its introduction in late 2025.\n1. Asset Fundamental Characteristics\n1.1 Asset\nEUR CoinVertible (EURCV) is an ERC20 Euro stablecoin issued by Societe Generale-Forge as part of the CoinVertible asset series. Under the AAcA framework, EURCV is classified as a reserve-backed stablecoin, backed 1:1 by reserves held in segregated Euro-denominated accounts managed by Societe Generale-Forge. For EURCV, the Initial Collateral Custodian is Societe Generale.\nReserve assets are held in a segregated account and may consist of cash and low-risk liquid securities. The issuer indicates, however, that reserves are currently 100% fiat and maintain a 1:1 collateralization ratio. EURCV is natively minted on different chains, including Ethereum, Solana, XRP Ledger, and Stellar.\n1.2 Architecture\nEURCV is issued behind an upgradeable ERC1967 proxy. The SmartCoin contract implements strict access controls, blacklisting capabilities, and redemption mechanisms. 3 operators are defined in the contract, each with distinct roles:\n\nRegistrar: The most significant role, responsible for compliance controls (freezing/blacklisting), managing the redemption process, token supply (mint/burn), and governance.\nTechnical: Manages contract upgrades.\nOperations: Has no defined role within the contract; its updated primary role is an involvement in contract upgrades. (see section 4.2.1 for more details)\n\nMinting and burn access is privileged, with only the issuer-controlled registrar permitted to perform these functions. No fees are associated with direct minting or burning.\nThe following subsections (preferred partners, minting, and redemption) are defined in the EURCV whitepaper.\nPreferred Partners\nPreferred Partners are financial institutions (network of exchanges, brokers, and market makers) that are permitted to act as distributors of electronic money for Societe Generale, allowing them to process minting and redemption of EURV from the issuer. Currently onboarded partners, as indicated on the “Network of partners\" section on the Coinvertible website, include: Bitpanda, Bitstamp, Bullish, BCB Group, Flowdesk, Keyrock, and Wintermute. Bitstamp is the primary Preferred Partner for EURCV issued on Ethereum.\nMinting\nMinting is permissioned, with minting available directly from the issuer or indirectly through approved Preferred Partners. Potential direct purchasers are required to pass a “Valid Purchaser” assessment to access EURCV from the issuer as a subscriber and/or purchaser.\nValid Purchasers are required to transfer/deliver the agreed assets to the segregated account specified by the issuer. Upon confirmation of receipt, EURCV is either minted directly into the Valid Purchaser’s address or transferred. Valid Purchasers are required to pass KYC/AML and Sanctions Rule verifications by the issuer before being approved to receive EURCV.\nThe stablecoin can also be purchased on secondary exchanges, with the issuer retaining the right to blacklist addresses from holding EURCV, exercised at the issuer’s sole discretion (for illegal activities or violations of the issuer’s requirements).\nRedemption\nEURCV holders have 2 options when redeeming EURCV back into fiat: directly from the issuer or through a Preferred Partner.\nIssuer-based redemptions require the holder to submit their redemption request directly via email. Prerequisites, including completion of KYC/AML, permitted transferees, sanctions rules, and other controls (see section 4.1 for more details), need to be completed before redemptions can be processed. On successful completion and the EURCV being transferred to the redemption address, the relevant redemption amount in Euros is transferred to the holder’s account by the last business day of the month following the month the controls were completed. If a holder fails to complete these controls, EURCV is sent back to their wallet.\nPreferred Partner redemptions require EURCV holders to satisfy the partner’s KYC/AML and sanctions requirements. Once onboarded, redemption requests follow the procedure established by the partner, which may include transferring EURCV to the partner prior to confirming the redemption request. Upon confirmation, the corresponding EURCV is frozen, and the partner requests that the issuer transfer the equivalent amount in Euros no later than the last business day of the month following the month in which the redemption request was confirmed. The funds are then credited to the holder’s Preferred Partner account.\nRedemptions are restricted to EEA residents and Permitted Transferees who satisfy applicable KYC/AML and sanctions requirements under both direct and Preferred Partner (EU residents) instances.\nThe issuer retains the right to exercise redemptions under 2 conditions:\n\nUnwind Event: Upon 90 days’ notice, the issuer may redeem all outstanding EURCV and liquidate the collateral. Holders will be entitled to receive one EURO per EURCV. Upon the Redemption Date, EURCV shall become void, and no payment shall be made in respect thereof\nSpecial Event: Following a Tax, Regulatory, and/or Force Majeure Event, the issuer retains the right to issue a 90-day notice for the redemption of EURCV.\n\nA “Business Day” in the context of EURCV is defined as a day on which:\n\nCommercial banks settle payments and are open for general business in France; and\nThe Trans-European Automated Real-Time Gross Settlement Express Transfer (T2) System (or any replacement thereof) is operating.\n\nRedemption limits are set per KYC client for direct redemptions, while redemptions facilitated by preferred partners are not limit-bound.\nOffchain System\nEURCV minting and redemption on Ethereum is enabled via an integrated offchain system. The automated system enables minting and redemption that are processed within 2 minutes on average, according to the issuer. Automated requests are processed continuously and are not subject to market times. Manual mint/burns are also available but operate during market hours (9 am to 6 pm, Monday to Friday).\nAccording to the issuer, EURCV minting is triggered by an internal API that monitors incoming cash flows to the collateral account held by Société Générale. Once the API detects a deposit, an automated minting engine initiates the mint workflow on mainnet.\nFor redemption operations, each valid customer is assigned a dedicated address used exclusively for burning purposes, which is assigned onchain using the addRedemptionAddresses function. When EURCV is sent to the address, the smart contract detects if the transfer meets the isRedemptionAddress parameter, which initiates the redemption process and directs the EURCV to the Registrar account. The offchain settlement system monitors for the RedemptionStarted event emission before transferring the equivalent amount in fiat to the customer’s designated bank account. Once a settlement is confirmed, the Registrar burns the associated tokens. Transaction screening is handled automatically via Chainalysis.\n1.3 Tokenomics\nThere is no supply cap enforced on EURCV. The total supply currently sits at 105.6M, with 70.6M on Ethereum. The underlying collateralization value equals the total EURCV outstanding multiplied by 1 unit of Euro.\nAs stated in section 1.2, the issuer retains discretionary rights to blacklist addresses from holding EURCV, with the whitepaper indicating that the primary justifications include:\n\nIf the issuer suspects that these addresses may be involved in illegal activities or violate the issuer’s requirements and/or the provisions outlined in the whitepaper\nIf a holder sends or receives EURCV from a blacklisted address, the Issuer has the right to freeze the corresponding EURCV.\nThe issuer may be required to freeze EURCV and/or surrender any related Euro held in the Segregated Account(s) if it receives a legal order from a valid government authority mandating such actions.\n\n1.3.1 Token Holder Concentration\n\nSource: Etherscan, September 15th, 2026\nOf the total 6,846 holders, the top 5 holders include:\n\nSteakhouse Morpho steakEURCV: 70.27% of the total supply.\nBitpanda: 8.40% of the total supply.\nEOA 1: 7.19% of the total supply.\nBullish: 2.96% of the total supply.\nBitstamp: 2.00% of the total supply.\n\nOver 90% of the mainnet supply is held by the top 5 addresses, the majority of which is locked in a Morpho vault, specifically a Steakhouse Prime EURCV vault. The associated concentration in an Aave competitor currently does not offer potentially distorting incentives, with its APY capped at 3.00%. EURCV is primarily used as a loanable asset enabled as collateral for cbBTC, WBTC, wstETH, EUTBL, eurSAFO, and steakUSDC (min LTV is 86%).\n2. Market Risk\n2.1 Liquidity\n\nSource: EURCV/USDC Swap, DeFiLlama Swap, September 15th, 2026\nApproximately 3.15M EURCV ($3.63M) can be swapped within a 5.5% price impact for USDC.\n2.1.1 Liquidity Venue Concentration\n\nSource: EURCV pools, GeckoTerminal, September 15th, 2026\nThere are only 2 pools with meaningful liquidity on mainnet: a Uniswap EURCV/EUROC pool with a TVL of ~$5.8M and a Uniswap EURCV/USDC pool with a TVL of $3.4M.\n2.1.2 DEX LP Concentration\nWithin the EURCV/USDC and EURCV/EUROC pools, an EOA is the sole source of liquidity. The EOA is associated with SG Forge and is controlled by their main market maker for those pools.\n2.2 Volatility\nEURCV vs EUR/USD Oracle Deviation\nSince the EURCV/USDC Uniswap pool launched in late September 2025, the pool market rate has tracked the Chainlink EUR/USD oracle closely. Over the full trading history, the pool traded within a deviation range of -1.06% to +4.36%, with a mean deviation of just +0.04%. The elevated positive tail was concentrated in the first two weeks of pool operation, where thin initial liquidity allowed the market rate to briefly dislocate from the oracle reference. Excluding that bootstrapping period, the pool has maintained tight oracle tracking since mid-October 2025.\n\nSource: EURCV Oracle Deviation, Steakhouse, September 2026\nEURCV/USDC vs EURC Market Rates\nRelative to the most liquid EUR-based stablecoin, EURC, the EURCV/USDC Uniswap pool market rate has tracked the EURC DEX average daily rate closely across its full trading history. Since pool inception through September 3, 2026, the spread ranged from a low of -0.41% to a high of +3.04%, with the positive extreme again attributable to the illiquid early deployment window in October 2025. Once liquidity matured, the spread range compressed to -0.41% to +0.66% against the EURC reference rate, with a mean of +0.01%. The narrow steady-state range reflects broad parity between the assets.\n\nSource: EURCV/USDC vs EURC market rates, LlamaRisk, September 2026\n2.3 Exchanges\nEURCV is available on two exchanges, Bullish and Bitstamp, which also act as Preferred Partners.\n\nSource: EURCV CEX pools, Coingecko, September 15th, 2026\n2.4 Growth\nThe total supply of EURCV on mainnet has steadily grown since its inception, peaking at 132.2M as of September 3rd. Relative to other chains, Ethereum represents the largest supply of EURCV, with approximately 80% of the overall supply.\n\nSource: EURCV mainnet supply, LlamaRisk, September 2026\n\nSource: EURCV, RWA.xyz, September 15th, 2026\n3. Technological Risk\n3.1 Smart Contract Risk\nA Hacken audit on the SmartCoin contract was completed in June 2025. 1 medium and 1 low-severity issue were found.\nThe most recent upgrade to the SmartCoin occurred in November 2025. Relative to the previous implementation, the current implementation includes 194 lines removed (41.6% reduction) and introduced 60 new lines of code.\nThis presents a potential blocker given the lack of re-attestation on subsequent material upgrades.\n3.2 Bug Bounty Program\nThere is currently no bug bounty in place for Societe Generale-Forge or CoinVertible-related assets.\nThe issuer indicated that they planned to introduce a bug bounty shortly. SG Forge indicated that they would introduce a bug bounty in 2027.\n3.3 Price Feed Risk\nA native EURCV Chainlink price feed is currently unavailable; however, the Chainlink EUR/USD price feed can serve as a suitable proxy, given that the underlying collateral is held in Euro fiat and remains redeemable at 1:1 par value.\nBecause the EUR/USD feed is a standard Forex price source, updates occur during defined FX trading hours, 24/5 (18:00 ET Sunday to 17:00 ET Friday), which introduces stale price-reporting risk outside those hours. This follows an established pattern used across onboarded Euro-denominated assets, including EURe on Gnosis, EURA and jEUR on Polygon (disabled), EURS on Arbitrum (frozen) and Polygon (disabled), and EURm on Celo. Currently, EURC is the sole Euro-stable asset supported by a dedicated, asset-specific EURC/USD feed.\nProof of reserves data is currently only available offchain, published on the issuer’s Coinvertible page and stated to be updated several times per day, with internal audits purportedly carried out before each reserve update. The issuer has indicated that formal third-party proof of reserves attestations are planned to be published on a quarterly or monthly basis (the frequency is yet to be determined). Until these attestations are established and published consistently, collateralization risk remains elevated given the absence of sufficient independent attestation measures.\n3.4 Dependency Risk\nThe primary risks associated with EURCV are centralized custodian and reserve management risk. Holders rely on Societe Generale as the custodian of the underlying reserves. As the sole custodian for safely holding and managing the underlying assets, EURCV’s dependency risk is entirely concentrated in the operational soundness and transparency of the bank. The 1:1 redemption guarantee requires that reserves be managed and reported transparently. While internal systems and a webpage are updated regularly, a PoR feed would provide greater onchain visibility and minimise trust assumptions.\nAccording to the EURCV white paper, holders are potentially exposed to the credit risks of Societe Generale and Preferred Partners (during redemptions) if they default or go bankrupt while user collateral is being held.\nAdditionally, while Euro reserves are held in a segregated account, this represents pooled collateral shared across all networks on which EURCV is deployed. EURCV does not make cross-chain calls, but the commingling of assets across external networks creates potential contagion risk; an exploit on one network could undercollateralize EURCV on Ethereum until the necessary interventions are made.\n4. Counterparty Risk\n4.1 Governance and Regulatory Risk\nSG-FORGE holds three load-bearing French regulatory authorisations, each relevant to the EURCV business model:\n\nElectronic Money Institution (EMI) license - granted by the ACPR effective 1 July 2024. This is the basis for issuing EMTs under MiCA Title III via Art. 48 (any credit institution or EMI may issue EMTs without further authorisation under MiCA, provided the whitepaper notification process is observed).\nInvestment firm authorisation - also supervised by the ACPR and conduct-regulated by the AMF. Provides the MiFID2 capital-markets perimeter under which SG-FORGE provides ancillary services.\nCrypto Asset Service Provider (CASP) - granted by the AMF in July 2023, predating MiCA. Under MiCA’s CASP regime, this French authorisation transitions into a MiCA CASP license through the EU’s grandfathering provisions (Art. 143).\n\nEURCV satisfies each MiCA EMT compliance pillar: (i) issuance by an authorised EMI (Art. 48); (ii) whitepaper notified to the ACPR on 30 May 2024 and offer commenced 1 July 2024 (Art. 51); (iii) 1:1 redemption-at-par right for EEA holders (Art. 49); (iv) no interest payable to holders (Art. 50); (v) reserve segregation and asset eligibility (Arts. 36, 38); (vi) recovery and redemption plans submitted under Arts. 46–47 within six months of offer commencement; (vii) marketing communications subject to ACPR oversight (Art. 53). The whitepaper further states that EURCV is not a “significant” EMT under Art. 56 - i.e., outstanding supply has not crossed the EBA-administered thresholds that would trigger enhanced supervision (i.e., €5bn or 2.5m daily-transaction-count threshold).\nEURCV is structured as a 100% cash- and high-quality-liquid-asset–backed EMT. The whitepaper provides specific composition rules: the Segregated Account holds (i) non-invested cash and cash distributions received by the issuer and (ii) Euro-denominated securities qualifying as “highly liquid financial instruments with minimal market risk, credit risk, and concentration risk, in accordance with Article 38(1) of MiCA,” with a credit rating “at least equivalent to the long term unsecured credit rating of senior preferred debt of Société Générale.” The Collateral Test imposes a hard floor: “cash held in Segregated Account(s) represent at least 30% of the Required Collateral Assets Value.” The eligibility criteria, therefore, explicitly map onto MiCA Art. 38 reserve-asset constraints.\nReserves are held in segregated accounts opened in SG-FORGE’s name on the books of “Collateral Custodians.” The Initial Collateral Custodian is Société Générale S.A. (the issuer’s parent G-SIB). The whitepaper contemplates Subsequent Collateral Custodians at other banks rated at or above SG’s senior unsecured rating, but as of the 27/04/2026 reserve snapshot, the entire EURCV reserve is held at SG. The segregation construct relies on Article L. 526-32 of the French Monetary and Financial Code (which insulates safeguarded e-money funds from issuer creditors), supplemented by Article L. 522-17 CMF (the segregated-account agreement requirement) and the Issuer-Custodian agreement dated June 2024.\nPer the issuer’s confirmation, SG-FORGE’s Finance and Compliance teams are currently developing a formal concentration-risk framework, and the issuer does not consider the current EURCV AUM to pose significant concentration risk at this scale. Separately, SG-FORGE’s parallel USDCV product is custodied at Bank of New York, demonstrating that the issuer has the operational and contractual infrastructure to onboard non-affiliated Subsequent Collateral Custodians - a meaningful piece of forward-looking optionality for EURCV reserve diversification, though no such diversification has yet been activated for EURCV.\nHolders who are EEA residents have an unconditional right of redemption at par per MiCA Art. 49, but the practical settlement timeline is materially longer than a 24/7 instant-redemption flow. The whitepaper provides for a controlled multi-step process: redemption request by email → 5 business-day acknowledgment → KYC/AML/Permitted-Transferee/Sanctions controls → settlement “at the latest on the last Business Day of the month following the month the controls were successfully completed.” On the inside, that can be ~T+5; on the outside, it can stretch to more than a month, particularly if the request lands at the start of a month and controls take time. Holders can alternatively redeem through a “Preferred Partner” (currently Bitstamp on Ethereum and Bullish on Solana), whose own settlement timelines apply.\nReserves are reported by the issuer on its own website, with composition and Collateral Test results published the business day following each Collateral Test Date. The whitepaper provides for the optional appointment of a Collateral Monitoring Agent, but does not name one. Independent third-party reserve attestations are not provided.\nSG-FORGE applies multi-jurisdictional sanctions screening at issuance, redemption, and on a continuous basis through smart-contract address blacklisting. The whitepaper adopts a four-source sanctions definition; per the issuer’s confirmation, the operative screening framework covers UN, EU, OFAC, OFSI, G7, and local-authority sanctions lists - i.e., a broader regime than the four-source whitepaper definition would suggest. Compliance operates under a Société Générale Group three-lines-of-defence model: AML, CFT, and sanctions policies (including KYC and CDD/EDD) are reviewed and approved annually by senior management, supervised quarterly by the Supervisory and Risk Committee, and reported at the Board level. Client onboarding, ongoing due diligence, PEP, adverse-media, and name screening are largely delegated to Société Générale and run through group tools — Dow Jones Risk & Compliance for sanctions/PEP/adverse-media data and Fircosoft for screening orchestration. On-chain transaction and sanctions monitoring is managed locally by SG-FORGE through a Know-Your-Transaction framework run on Chainalysis; screening is performed for every transaction, with alerts escalated to Compliance and (where applicable) to local authorities. Smart-contract enforcement is performed by SG-FORGE through a freeze/blacklist function held in the Issuer’s sole discretion.\nEURCV applies a tiered user-restriction architecture. At the issuance gateway, only “Valid Purchasers” who pass KYC/AML and qualify as “Permitted Transferees” can receive EURCV directly from the issuer. The Permitted Transferee construct excludes U.S. persons under Regulation S of the U.S. Securities Act, the U.S. Commodity Exchange Act, and Section 15G of the U.S. Securities Exchange Act. EEA residents who do not pass KYC at redemption time can be functionally barred from exercising redemption rights even though they hold the token.\n4.2 Access Control Risk\nHere are the controlling wallets:\n\nEOA 1: assigned the Registrar role\nEOA 2: assigned the Technical role\nEOA 3: assigned the Operations role\n\nThe SmartCoin contract exposes the above roles known collectively as “Operators”. These Operators and their sensitive functions assigned to them include:\n\nRegistrar, the compliance/admin authority role is assigned to a single EOA.\n\nFunctions\nDescription\n\nmint()\nMints new tokens and assigns them to an unfrozen address.\n\nburn()\nBurns registrar’s balance (within redemption flow).\n\nwipeFrozenAddress()\nBurns the balance of a frozen address.\n\nfreeze()\nFreezes account(s) from transferring or receiving tokens.\n\nunfreeze()\nUnfreezes accounts.\n\npause()\nHalts all token operations.\n\nunpause()\nResumes normal contract operation.\n\naddRedemptionAddresses()\nRegisters redemption addresses.\n\nremoveRedemptionAddresses()\nDeregisters redemption addresses.\n\nnameNewOperators()\nDesignates the three operator addresses for the next contract implementation. Named operators must subsequently accept their roles before an upgrade can proceed.\n\nauthorizeImplementation()\nPre-approves a new implementation contract for upgrades. Requires all named operators to have already accepted their roles.\n\nTechnical, executes upgrades initiated by the Registrar.\n\nFunctions\nDescription\n\nupgradeTo()\nUpgrades the proxy to a new implementation contract.\n\nupgradeToAndCall()\nSame as upgradeTo, but additionally calls an initialization function on the new implementation with the provided data.\n\nOperations, the role is retained in the latest implementation, but no longer has any specific permissions or functions.\n\nThe assignment of EOAs presents a potential security risk; if the EOAs assigned to the registrar and technical roles were to be compromised, then\n4.2.1 Contract Modification Options\nHere are the main contracts of the architecture:\n\nSmartCoin: Upgradeable ERC20 contract for the EURCV token.\nAccessControlUpgradeable: access control management contract for EURCV.\n\nContract upgrades require that the Operators be upgraded in tandem. This means the nominated addresses assume their new roles, while the current Operators remain in place until the upgrade is complete.\nThe main upgrade process steps include:\n\nRegistrar nominates the next Operators\nEach operator accepts their nominated role\nThe current (old)Technical deploys a new contract\nThe current Registrar authorize the update to the new contract\nThe current Technical calls the upgradeTo function\nThe upgradeTo function checks each operator has accepted, and then the upgrade is performed.\n\nUpgrades, therefore, require both the Technical and Registrar to execute contract upgrades. The same addresses can be re-nominated to the Operator roles, but they will still need to accept their roles via the acceptXYZRole function before an upgrade can be effected.\n\nOperations role\n\nAs stated in section 4.2, the Operations role has no assigned functions and is solely required in contract upgrade operations. The role has been retained in the latest version of the Smartcoin contract and is not intended to be reactivated or its permissions/functions expanded in the future. The role is a legacy Operator that remains to avoid reworking the existing contract upgrade mechanisms, which require that a set of Operators be nominated and assigned before an upgrade.\nRemoving the Operations role would require timely and complex modifications to the system; thus, this role is maintained for technical and architectural continuity. Its presence does not introduce any security issues and is retained for simplicity within the existing upgrade workflow.\n4.2.2 Timelock Duration and Function\nNo timelock is currently implemented, allowing contract modifications and upgrades to take effect immediately upon execution.\n4.2.3 Multisig Threshold / Signer identity\nOperator-assigned EOA private keys are stored within Ripple Custody (an institutional custody solution), where they are encrypted using the HSM key management (Hardware Security Module). Only the HSM is able to decrypt these keys, and they are never exposed in plain text. Transactions enacted with these EOAs are performed exclusively through Ripple Custody, following a multi‑role approval workflow:\n\nFor the Registrar, an operator prepares the transaction, and a controller must approve it before it can be executed.\nFor the Technical, a technical user prepares the transaction, which must then be approved first by an operator and subsequently by a controller.\n\nThe security of this model depends entirely on the integrity of Ripple Custody’s access controls and HSM integration. Access to roles, thus, is only technically accessible outside of these workflows if the Ripple Custody admin can bypass the approval workflow.\nNote: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V4. This framework is continuously updated and available here.\nAave V4 Specific Parameters\nGiven the lack of a bug bounty, the appropriate parameters will be proposed with an addendum post once this blocker has been resolved.\nPrice feed Recommendation\nWe recommend using the Chainlink EUR/USD price feed to price EURCV.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 2\n\n 200\n\n Sep 17\n\n Circle EUR (EURC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 87\n\n Sep 18\n\n [ARFC] Add EURC to Avalanche V3 Instance\n\n Governance\n\n 3\n\n 385\n\n Aug 2025\n\n Post Vyper Exploit - CRV Market Update and Recommendations\n\n General\n\n 48\n\n 8.1k\n\n Aug 29\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 105\n\n Sep 18","tokens":7368,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261294849,"hash":"6ecb467c8879ce088543c3543dadaaeaf940c51f"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/50","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 48 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261294945,"hash":"364ee09c6ea72111962e40f941c57ef9a58ebc7f"}
{"url":"https://ethereum.org/get-eth/","domain":"ethereum.org","title":"How to get Ethereum (ETH) | ethereum.org","text":"Ways you can get ETHCentralized exchangesExchanges are businesses that let you buy crypto using traditional currencies. They have custody over any ETH you buy until you send it to a wallet you control.See a list of exchanges Earn ETHYou can earn ETH by working for DAOs or companies that pay in crypto, winning bounties, finding software bugs, and more.Learn about DAOs Receive ETHOnce you have an Ethereum account, all you need to do is share your address to start sending and receiving ETH (and other tokens) peer-to-peer.Learn how to receive ETH Decentralized exchangesIf you want more control, buy ETH using . With a DEX you can trade digital assets without ever giving control of your funds to a centralized company.Try a DEX WalletsSome wallets let you buy ETH directly in the app with a debit or credit card, bank transfer, or even Apple Pay. Geographical restrictions may apply.More on wallets Staking rewardsIf you already have some ETH, you can earn more by running a validator node. You get paid for doing this verification work in ETH.Learn more about staking All products listed on this page are not official endorsements, and are provided for informational purposes only. If you want to add a product or provide feedback on the policy raise an issue in GitHub. Raise issue (opens in a new tab)Get ETH from exchangesFind a local crypto exchangeMany exchanges can only sell crypto in the specific regions where they operate. Search by country to find exchanges in your area. Inclusion here is not an endorsement, and service areas may change. Use this list as a starting point for your own research!Type where you live...WalletsKeeping your ETH safeEthereum isn't controlled by any single organization—it is decentralized.With ETH, you’re not trusting a bank or company to look after your assets. While this gives you complete ownership, it also means you are completely responsible for keeping your ETH secure.Keep your ETH in your own walletOne of the main features of Ethereum is that you keep control of your own assets by managing your own account. This means you don't have to trust any third party with your assets, and you are protected from any custodian acting dishonestly, going bankrupt or getting hacked. However, it also means you take responsibility for your own security.Check out walletsYour ETH addressWhen you download a wallet it will create a public ETH address for you. Here's what one looks like:0x0125e2478d69eXaMpLe81766fef5c120d30fb53fExample: do not copyThink of this like your email address, but instead of mail it can receive ETH. If you want to transfer ETH from an exchange to your wallet, use your address as the destination. Be sure to always double check before you send!Follow wallet instructionsIf you lose access to your account, you’ll lose access to your funds. Your wallet should give you instructions on protecting against this. Be sure to follow them carefully—in most cases, no one can help you if you lose access to your account.More on securityCommunity posts on securityProtecting yourself and your funds (opens in a new tab)MyCryptoThe keys to keeping your crypto safe (opens in a new tab)Coinbase","tokens":789,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261299664,"hash":"eaa15cd5ee3d181e5b74eddf7355eb9d5734aabd"}
{"url":"https://governance.aave.com/t/eur-coinvertible-eurcv-on-aave-ethereum/25655/2","domain":"governance.aave.com","title":"EUR CoinVertible (EURCV) on Aave Ethereum - Risk / Assessments - Aave","text":"RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 17\n\n 2 / 2\n\n Sep 17\n\n Sep 17\n\n post by LlamaRisk on Sep 17\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of EURCV on Aave Ethereum.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 10\n min\n\n post by LlamaRisk on Sep 17\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk conditionally supports the listing of EURCV on Aave V4, pending the launch of the bug bounty program. The Euro-denominated asset represents a 1:1 reserve-backed stablecoin issued by Societe Generale-Forge, which holds its underlying collateral in a segregated account managed by Societe Generale. EURCV operates similarly to other centrally issued stablecoins, with the issuer ultimately retaining access control privileges and a gated minting/redemption flow accessible only to KYC/KYB entities and, more broadly, via secondary markets and partners.\nOffchain and onchain mechanisms control the assets’ collateralization, with automated systems enabling continuous minting/redemption flows for permissioned users (Preferred partners and the issuer). No bug bounty is currently active, and the team indicates that one will be introduced. Reserve attestations are currently reported by the issuer, with audited 3rd party attestations to be introduced. EURCV has kept a relatively tight peg to the Euro, comparable to EURC since its introduction in late 2025.\n1. Asset Fundamental Characteristics\n1.1 Asset\nEUR CoinVertible (EURCV) is an ERC20 Euro stablecoin issued by Societe Generale-Forge as part of the CoinVertible asset series. Under the AAcA framework, EURCV is classified as a reserve-backed stablecoin, backed 1:1 by reserves held in segregated Euro-denominated accounts managed by Societe Generale-Forge. For EURCV, the Initial Collateral Custodian is Societe Generale.\nReserve assets are held in a segregated account and may consist of cash and low-risk liquid securities. The issuer indicates, however, that reserves are currently 100% fiat and maintain a 1:1 collateralization ratio. EURCV is natively minted on different chains, including Ethereum, Solana, XRP Ledger, and Stellar.\n1.2 Architecture\nEURCV is issued behind an upgradeable ERC1967 proxy. The SmartCoin contract implements strict access controls, blacklisting capabilities, and redemption mechanisms. 3 operators are defined in the contract, each with distinct roles:\n\nRegistrar: The most significant role, responsible for compliance controls (freezing/blacklisting), managing the redemption process, token supply (mint/burn), and governance.\nTechnical: Manages contract upgrades.\nOperations: Has no defined role within the contract; its updated primary role is an involvement in contract upgrades. (see section 4.2.1 for more details)\n\nMinting and burn access is privileged, with only the issuer-controlled registrar permitted to perform these functions. No fees are associated with direct minting or burning.\nThe following subsections (preferred partners, minting, and redemption) are defined in the EURCV whitepaper.\nPreferred Partners\nPreferred Partners are financial institutions (network of exchanges, brokers, and market makers) that are permitted to act as distributors of electronic money for Societe Generale, allowing them to process minting and redemption of EURV from the issuer. Currently onboarded partners, as indicated on the “Network of partners\" section on the Coinvertible website, include: Bitpanda, Bitstamp, Bullish, BCB Group, Flowdesk, Keyrock, and Wintermute. Bitstamp is the primary Preferred Partner for EURCV issued on Ethereum.\nMinting\nMinting is permissioned, with minting available directly from the issuer or indirectly through approved Preferred Partners. Potential direct purchasers are required to pass a “Valid Purchaser” assessment to access EURCV from the issuer as a subscriber and/or purchaser.\nValid Purchasers are required to transfer/deliver the agreed assets to the segregated account specified by the issuer. Upon confirmation of receipt, EURCV is either minted directly into the Valid Purchaser’s address or transferred. Valid Purchasers are required to pass KYC/AML and Sanctions Rule verifications by the issuer before being approved to receive EURCV.\nThe stablecoin can also be purchased on secondary exchanges, with the issuer retaining the right to blacklist addresses from holding EURCV, exercised at the issuer’s sole discretion (for illegal activities or violations of the issuer’s requirements).\nRedemption\nEURCV holders have 2 options when redeeming EURCV back into fiat: directly from the issuer or through a Preferred Partner.\nIssuer-based redemptions require the holder to submit their redemption request directly via email. Prerequisites, including completion of KYC/AML, permitted transferees, sanctions rules, and other controls (see section 4.1 for more details), need to be completed before redemptions can be processed. On successful completion and the EURCV being transferred to the redemption address, the relevant redemption amount in Euros is transferred to the holder’s account by the last business day of the month following the month the controls were completed. If a holder fails to complete these controls, EURCV is sent back to their wallet.\nPreferred Partner redemptions require EURCV holders to satisfy the partner’s KYC/AML and sanctions requirements. Once onboarded, redemption requests follow the procedure established by the partner, which may include transferring EURCV to the partner prior to confirming the redemption request. Upon confirmation, the corresponding EURCV is frozen, and the partner requests that the issuer transfer the equivalent amount in Euros no later than the last business day of the month following the month in which the redemption request was confirmed. The funds are then credited to the holder’s Preferred Partner account.\nRedemptions are restricted to EEA residents and Permitted Transferees who satisfy applicable KYC/AML and sanctions requirements under both direct and Preferred Partner (EU residents) instances.\nThe issuer retains the right to exercise redemptions under 2 conditions:\n\nUnwind Event: Upon 90 days’ notice, the issuer may redeem all outstanding EURCV and liquidate the collateral. Holders will be entitled to receive one EURO per EURCV. Upon the Redemption Date, EURCV shall become void, and no payment shall be made in respect thereof\nSpecial Event: Following a Tax, Regulatory, and/or Force Majeure Event, the issuer retains the right to issue a 90-day notice for the redemption of EURCV.\n\nA “Business Day” in the context of EURCV is defined as a day on which:\n\nCommercial banks settle payments and are open for general business in France; and\nThe Trans-European Automated Real-Time Gross Settlement Express Transfer (T2) System (or any replacement thereof) is operating.\n\nRedemption limits are set per KYC client for direct redemptions, while redemptions facilitated by preferred partners are not limit-bound.\nOffchain System\nEURCV minting and redemption on Ethereum is enabled via an integrated offchain system. The automated system enables minting and redemption that are processed within 2 minutes on average, according to the issuer. Automated requests are processed continuously and are not subject to market times. Manual mint/burns are also available but operate during market hours (9 am to 6 pm, Monday to Friday).\nAccording to the issuer, EURCV minting is triggered by an internal API that monitors incoming cash flows to the collateral account held by Société Générale. Once the API detects a deposit, an automated minting engine initiates the mint workflow on mainnet.\nFor redemption operations, each valid customer is assigned a dedicated address used exclusively for burning purposes, which is assigned onchain using the addRedemptionAddresses function. When EURCV is sent to the address, the smart contract detects if the transfer meets the isRedemptionAddress parameter, which initiates the redemption process and directs the EURCV to the Registrar account. The offchain settlement system monitors for the RedemptionStarted event emission before transferring the equivalent amount in fiat to the customer’s designated bank account. Once a settlement is confirmed, the Registrar burns the associated tokens. Transaction screening is handled automatically via Chainalysis.\n1.3 Tokenomics\nThere is no supply cap enforced on EURCV. The total supply currently sits at 105.6M, with 70.6M on Ethereum. The underlying collateralization value equals the total EURCV outstanding multiplied by 1 unit of Euro.\nAs stated in section 1.2, the issuer retains discretionary rights to blacklist addresses from holding EURCV, with the whitepaper indicating that the primary justifications include:\n\nIf the issuer suspects that these addresses may be involved in illegal activities or violate the issuer’s requirements and/or the provisions outlined in the whitepaper\nIf a holder sends or receives EURCV from a blacklisted address, the Issuer has the right to freeze the corresponding EURCV.\nThe issuer may be required to freeze EURCV and/or surrender any related Euro held in the Segregated Account(s) if it receives a legal order from a valid government authority mandating such actions.\n\n1.3.1 Token Holder Concentration\n\nSource: Etherscan, September 15th, 2026\nOf the total 6,846 holders, the top 5 holders include:\n\nSteakhouse Morpho steakEURCV: 70.27% of the total supply.\nBitpanda: 8.40% of the total supply.\nEOA 1: 7.19% of the total supply.\nBullish: 2.96% of the total supply.\nBitstamp: 2.00% of the total supply.\n\nOver 90% of the mainnet supply is held by the top 5 addresses, the majority of which is locked in a Morpho vault, specifically a Steakhouse Prime EURCV vault. The associated concentration in an Aave competitor currently does not offer potentially distorting incentives, with its APY capped at 3.00%. EURCV is primarily used as a loanable asset enabled as collateral for cbBTC, WBTC, wstETH, EUTBL, eurSAFO, and steakUSDC (min LTV is 86%).\n2. Market Risk\n2.1 Liquidity\n\nSource: EURCV/USDC Swap, DeFiLlama Swap, September 15th, 2026\nApproximately 3.15M EURCV ($3.63M) can be swapped within a 5.5% price impact for USDC.\n2.1.1 Liquidity Venue Concentration\n\nSource: EURCV pools, GeckoTerminal, September 15th, 2026\nThere are only 2 pools with meaningful liquidity on mainnet: a Uniswap EURCV/EUROC pool with a TVL of ~$5.8M and a Uniswap EURCV/USDC pool with a TVL of $3.4M.\n2.1.2 DEX LP Concentration\nWithin the EURCV/USDC and EURCV/EUROC pools, an EOA is the sole source of liquidity. The EOA is associated with SG Forge and is controlled by their main market maker for those pools.\n2.2 Volatility\nEURCV vs EUR/USD Oracle Deviation\nSince the EURCV/USDC Uniswap pool launched in late September 2025, the pool market rate has tracked the Chainlink EUR/USD oracle closely. Over the full trading history, the pool traded within a deviation range of -1.06% to +4.36%, with a mean deviation of just +0.04%. The elevated positive tail was concentrated in the first two weeks of pool operation, where thin initial liquidity allowed the market rate to briefly dislocate from the oracle reference. Excluding that bootstrapping period, the pool has maintained tight oracle tracking since mid-October 2025.\n\nSource: EURCV Oracle Deviation, Steakhouse, September 2026\nEURCV/USDC vs EURC Market Rates\nRelative to the most liquid EUR-based stablecoin, EURC, the EURCV/USDC Uniswap pool market rate has tracked the EURC DEX average daily rate closely across its full trading history. Since pool inception through September 3, 2026, the spread ranged from a low of -0.41% to a high of +3.04%, with the positive extreme again attributable to the illiquid early deployment window in October 2025. Once liquidity matured, the spread range compressed to -0.41% to +0.66% against the EURC reference rate, with a mean of +0.01%. The narrow steady-state range reflects broad parity between the assets.\n\nSource: EURCV/USDC vs EURC market rates, LlamaRisk, September 2026\n2.3 Exchanges\nEURCV is available on two exchanges, Bullish and Bitstamp, which also act as Preferred Partners.\n\nSource: EURCV CEX pools, Coingecko, September 15th, 2026\n2.4 Growth\nThe total supply of EURCV on mainnet has steadily grown since its inception, peaking at 132.2M as of September 3rd. Relative to other chains, Ethereum represents the largest supply of EURCV, with approximately 80% of the overall supply.\n\nSource: EURCV mainnet supply, LlamaRisk, September 2026\n\nSource: EURCV, RWA.xyz, September 15th, 2026\n3. Technological Risk\n3.1 Smart Contract Risk\nA Hacken audit on the SmartCoin contract was completed in June 2025. 1 medium and 1 low-severity issue were found.\nThe most recent upgrade to the SmartCoin occurred in November 2025. Relative to the previous implementation, the current implementation includes 194 lines removed (41.6% reduction) and introduced 60 new lines of code.\nThis presents a potential blocker given the lack of re-attestation on subsequent material upgrades.\n3.2 Bug Bounty Program\nThere is currently no bug bounty in place for Societe Generale-Forge or CoinVertible-related assets.\nThe issuer indicated that they planned to introduce a bug bounty shortly. SG Forge indicated that they would introduce a bug bounty in 2027.\n3.3 Price Feed Risk\nA native EURCV Chainlink price feed is currently unavailable; however, the Chainlink EUR/USD price feed can serve as a suitable proxy, given that the underlying collateral is held in Euro fiat and remains redeemable at 1:1 par value.\nBecause the EUR/USD feed is a standard Forex price source, updates occur during defined FX trading hours, 24/5 (18:00 ET Sunday to 17:00 ET Friday), which introduces stale price-reporting risk outside those hours. This follows an established pattern used across onboarded Euro-denominated assets, including EURe on Gnosis, EURA and jEUR on Polygon (disabled), EURS on Arbitrum (frozen) and Polygon (disabled), and EURm on Celo. Currently, EURC is the sole Euro-stable asset supported by a dedicated, asset-specific EURC/USD feed.\nProof of reserves data is currently only available offchain, published on the issuer’s Coinvertible page and stated to be updated several times per day, with internal audits purportedly carried out before each reserve update. The issuer has indicated that formal third-party proof of reserves attestations are planned to be published on a quarterly or monthly basis (the frequency is yet to be determined). Until these attestations are established and published consistently, collateralization risk remains elevated given the absence of sufficient independent attestation measures.\n3.4 Dependency Risk\nThe primary risks associated with EURCV are centralized custodian and reserve management risk. Holders rely on Societe Generale as the custodian of the underlying reserves. As the sole custodian for safely holding and managing the underlying assets, EURCV’s dependency risk is entirely concentrated in the operational soundness and transparency of the bank. The 1:1 redemption guarantee requires that reserves be managed and reported transparently. While internal systems and a webpage are updated regularly, a PoR feed would provide greater onchain visibility and minimise trust assumptions.\nAccording to the EURCV white paper, holders are potentially exposed to the credit risks of Societe Generale and Preferred Partners (during redemptions) if they default or go bankrupt while user collateral is being held.\nAdditionally, while Euro reserves are held in a segregated account, this represents pooled collateral shared across all networks on which EURCV is deployed. EURCV does not make cross-chain calls, but the commingling of assets across external networks creates potential contagion risk; an exploit on one network could undercollateralize EURCV on Ethereum until the necessary interventions are made.\n4. Counterparty Risk\n4.1 Governance and Regulatory Risk\nSG-FORGE holds three load-bearing French regulatory authorisations, each relevant to the EURCV business model:\n\nElectronic Money Institution (EMI) license - granted by the ACPR effective 1 July 2024. This is the basis for issuing EMTs under MiCA Title III via Art. 48 (any credit institution or EMI may issue EMTs without further authorisation under MiCA, provided the whitepaper notification process is observed).\nInvestment firm authorisation - also supervised by the ACPR and conduct-regulated by the AMF. Provides the MiFID2 capital-markets perimeter under which SG-FORGE provides ancillary services.\nCrypto Asset Service Provider (CASP) - granted by the AMF in July 2023, predating MiCA. Under MiCA’s CASP regime, this French authorisation transitions into a MiCA CASP license through the EU’s grandfathering provisions (Art. 143).\n\nEURCV satisfies each MiCA EMT compliance pillar: (i) issuance by an authorised EMI (Art. 48); (ii) whitepaper notified to the ACPR on 30 May 2024 and offer commenced 1 July 2024 (Art. 51); (iii) 1:1 redemption-at-par right for EEA holders (Art. 49); (iv) no interest payable to holders (Art. 50); (v) reserve segregation and asset eligibility (Arts. 36, 38); (vi) recovery and redemption plans submitted under Arts. 46–47 within six months of offer commencement; (vii) marketing communications subject to ACPR oversight (Art. 53). The whitepaper further states that EURCV is not a “significant” EMT under Art. 56 - i.e., outstanding supply has not crossed the EBA-administered thresholds that would trigger enhanced supervision (i.e., €5bn or 2.5m daily-transaction-count threshold).\nEURCV is structured as a 100% cash- and high-quality-liquid-asset–backed EMT. The whitepaper provides specific composition rules: the Segregated Account holds (i) non-invested cash and cash distributions received by the issuer and (ii) Euro-denominated securities qualifying as “highly liquid financial instruments with minimal market risk, credit risk, and concentration risk, in accordance with Article 38(1) of MiCA,” with a credit rating “at least equivalent to the long term unsecured credit rating of senior preferred debt of Société Générale.” The Collateral Test imposes a hard floor: “cash held in Segregated Account(s) represent at least 30% of the Required Collateral Assets Value.” The eligibility criteria, therefore, explicitly map onto MiCA Art. 38 reserve-asset constraints.\nReserves are held in segregated accounts opened in SG-FORGE’s name on the books of “Collateral Custodians.” The Initial Collateral Custodian is Société Générale S.A. (the issuer’s parent G-SIB). The whitepaper contemplates Subsequent Collateral Custodians at other banks rated at or above SG’s senior unsecured rating, but as of the 27/04/2026 reserve snapshot, the entire EURCV reserve is held at SG. The segregation construct relies on Article L. 526-32 of the French Monetary and Financial Code (which insulates safeguarded e-money funds from issuer creditors), supplemented by Article L. 522-17 CMF (the segregated-account agreement requirement) and the Issuer-Custodian agreement dated June 2024.\nPer the issuer’s confirmation, SG-FORGE’s Finance and Compliance teams are currently developing a formal concentration-risk framework, and the issuer does not consider the current EURCV AUM to pose significant concentration risk at this scale. Separately, SG-FORGE’s parallel USDCV product is custodied at Bank of New York, demonstrating that the issuer has the operational and contractual infrastructure to onboard non-affiliated Subsequent Collateral Custodians - a meaningful piece of forward-looking optionality for EURCV reserve diversification, though no such diversification has yet been activated for EURCV.\nHolders who are EEA residents have an unconditional right of redemption at par per MiCA Art. 49, but the practical settlement timeline is materially longer than a 24/7 instant-redemption flow. The whitepaper provides for a controlled multi-step process: redemption request by email → 5 business-day acknowledgment → KYC/AML/Permitted-Transferee/Sanctions controls → settlement “at the latest on the last Business Day of the month following the month the controls were successfully completed.” On the inside, that can be ~T+5; on the outside, it can stretch to more than a month, particularly if the request lands at the start of a month and controls take time. Holders can alternatively redeem through a “Preferred Partner” (currently Bitstamp on Ethereum and Bullish on Solana), whose own settlement timelines apply.\nReserves are reported by the issuer on its own website, with composition and Collateral Test results published the business day following each Collateral Test Date. The whitepaper provides for the optional appointment of a Collateral Monitoring Agent, but does not name one. Independent third-party reserve attestations are not provided.\nSG-FORGE applies multi-jurisdictional sanctions screening at issuance, redemption, and on a continuous basis through smart-contract address blacklisting. The whitepaper adopts a four-source sanctions definition; per the issuer’s confirmation, the operative screening framework covers UN, EU, OFAC, OFSI, G7, and local-authority sanctions lists - i.e., a broader regime than the four-source whitepaper definition would suggest. Compliance operates under a Société Générale Group three-lines-of-defence model: AML, CFT, and sanctions policies (including KYC and CDD/EDD) are reviewed and approved annually by senior management, supervised quarterly by the Supervisory and Risk Committee, and reported at the Board level. Client onboarding, ongoing due diligence, PEP, adverse-media, and name screening are largely delegated to Société Générale and run through group tools — Dow Jones Risk & Compliance for sanctions/PEP/adverse-media data and Fircosoft for screening orchestration. On-chain transaction and sanctions monitoring is managed locally by SG-FORGE through a Know-Your-Transaction framework run on Chainalysis; screening is performed for every transaction, with alerts escalated to Compliance and (where applicable) to local authorities. Smart-contract enforcement is performed by SG-FORGE through a freeze/blacklist function held in the Issuer’s sole discretion.\nEURCV applies a tiered user-restriction architecture. At the issuance gateway, only “Valid Purchasers” who pass KYC/AML and qualify as “Permitted Transferees” can receive EURCV directly from the issuer. The Permitted Transferee construct excludes U.S. persons under Regulation S of the U.S. Securities Act, the U.S. Commodity Exchange Act, and Section 15G of the U.S. Securities Exchange Act. EEA residents who do not pass KYC at redemption time can be functionally barred from exercising redemption rights even though they hold the token.\n4.2 Access Control Risk\nHere are the controlling wallets:\n\nEOA 1: assigned the Registrar role\nEOA 2: assigned the Technical role\nEOA 3: assigned the Operations role\n\nThe SmartCoin contract exposes the above roles known collectively as “Operators”. These Operators and their sensitive functions assigned to them include:\n\nRegistrar, the compliance/admin authority role is assigned to a single EOA.\n\nFunctions\nDescription\n\nmint()\nMints new tokens and assigns them to an unfrozen address.\n\nburn()\nBurns registrar’s balance (within redemption flow).\n\nwipeFrozenAddress()\nBurns the balance of a frozen address.\n\nfreeze()\nFreezes account(s) from transferring or receiving tokens.\n\nunfreeze()\nUnfreezes accounts.\n\npause()\nHalts all token operations.\n\nunpause()\nResumes normal contract operation.\n\naddRedemptionAddresses()\nRegisters redemption addresses.\n\nremoveRedemptionAddresses()\nDeregisters redemption addresses.\n\nnameNewOperators()\nDesignates the three operator addresses for the next contract implementation. Named operators must subsequently accept their roles before an upgrade can proceed.\n\nauthorizeImplementation()\nPre-approves a new implementation contract for upgrades. Requires all named operators to have already accepted their roles.\n\nTechnical, executes upgrades initiated by the Registrar.\n\nFunctions\nDescription\n\nupgradeTo()\nUpgrades the proxy to a new implementation contract.\n\nupgradeToAndCall()\nSame as upgradeTo, but additionally calls an initialization function on the new implementation with the provided data.\n\nOperations, the role is retained in the latest implementation, but no longer has any specific permissions or functions.\n\nThe assignment of EOAs presents a potential security risk; if the EOAs assigned to the registrar and technical roles were to be compromised, then\n4.2.1 Contract Modification Options\nHere are the main contracts of the architecture:\n\nSmartCoin: Upgradeable ERC20 contract for the EURCV token.\nAccessControlUpgradeable: access control management contract for EURCV.\n\nContract upgrades require that the Operators be upgraded in tandem. This means the nominated addresses assume their new roles, while the current Operators remain in place until the upgrade is complete.\nThe main upgrade process steps include:\n\nRegistrar nominates the next Operators\nEach operator accepts their nominated role\nThe current (old)Technical deploys a new contract\nThe current Registrar authorize the update to the new contract\nThe current Technical calls the upgradeTo function\nThe upgradeTo function checks each operator has accepted, and then the upgrade is performed.\n\nUpgrades, therefore, require both the Technical and Registrar to execute contract upgrades. The same addresses can be re-nominated to the Operator roles, but they will still need to accept their roles via the acceptXYZRole function before an upgrade can be effected.\n\nOperations role\n\nAs stated in section 4.2, the Operations role has no assigned functions and is solely required in contract upgrade operations. The role has been retained in the latest version of the Smartcoin contract and is not intended to be reactivated or its permissions/functions expanded in the future. The role is a legacy Operator that remains to avoid reworking the existing contract upgrade mechanisms, which require that a set of Operators be nominated and assigned before an upgrade.\nRemoving the Operations role would require timely and complex modifications to the system; thus, this role is maintained for technical and architectural continuity. Its presence does not introduce any security issues and is retained for simplicity within the existing upgrade workflow.\n4.2.2 Timelock Duration and Function\nNo timelock is currently implemented, allowing contract modifications and upgrades to take effect immediately upon execution.\n4.2.3 Multisig Threshold / Signer identity\nOperator-assigned EOA private keys are stored within Ripple Custody (an institutional custody solution), where they are encrypted using the HSM key management (Hardware Security Module). Only the HSM is able to decrypt these keys, and they are never exposed in plain text. Transactions enacted with these EOAs are performed exclusively through Ripple Custody, following a multi‑role approval workflow:\n\nFor the Registrar, an operator prepares the transaction, and a controller must approve it before it can be executed.\nFor the Technical, a technical user prepares the transaction, which must then be approved first by an operator and subsequently by a controller.\n\nThe security of this model depends entirely on the integrity of Ripple Custody’s access controls and HSM integration. Access to roles, thus, is only technically accessible outside of these workflows if the Ripple Custody admin can bypass the approval workflow.\nNote: This assessment follows the LLR-Aave Framework, a comprehensive methodology for asset onboarding and parameterization in Aave V4. This framework is continuously updated and available here.\nAave V4 Specific Parameters\nGiven the lack of a bug bounty, the appropriate parameters will be proposed with an addendum post once this blocker has been resolved.\nPrice feed Recommendation\nWe recommend using the Chainlink EUR/USD price feed to price EURCV.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 2\n\n 200\n\n Sep 17\n\n Circle EUR (EURC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 87\n\n Sep 18\n\n [ARFC] Add EURC to Avalanche V3 Instance\n\n Governance\n\n 3\n\n 385\n\n Aug 2025\n\n Post Vyper Exploit - CRV Market Update and Recommendations\n\n General\n\n 48\n\n 8.1k\n\n Aug 29\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 105\n\n Sep 18","tokens":7357,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261306766,"hash":"a0605a17c9db35e51e99be3a506ede062b9e3c99"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/44","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 43 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261306848,"hash":"1e4b13e2a6e318a7268e083eca6d8f24b707534f"}
{"url":"https://ethereum.org/apps/categories/defi/","domain":"ethereum.org","title":"List of Ethereum DeFi apps — Lending, Borrowing & Yield | ⁦ethereum.org⁩","text":"HighlightsPolymarket is the world’s largest prediction market, allowing you to stay informed and profit from your knowledge by betting on future events across various topics.DeFiPolymarketPrediction · RWA · Yield · CrowdfundingSablier is a protocol that facilitates the automated distribution of tokens over time. This \"streaming\" functionality removes the need for manual transactions, saving time and resources.DeFiSablierPaymentsAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.DeFiAaveLending and borrowingPolymarket is the world’s largest prediction market, allowing you to stay informed and profit from your knowledge by betting on future events across various topics.DeFiPolymarketPrediction · RWA · Yield · CrowdfundingSablier is a protocol that facilitates the automated distribution of tokens over time. This \"streaming\" functionality removes the need for manual transactions, saving time and resources.DeFiSablierPaymentsAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.DeFiAaveLending and borrowingShowing (57)AaveLending and borrowingSky/Maker - USDSStablecoin issuance · RWA · Lending and borrowingEthena - USDERWA · Stablecoin issuance · YieldUniswapDEXPendleRWASparkLending and borrowing · RWAMorphoLending and borrowingCompoundLending and borrowingCurveDEXBalancerDEXUsual RWA · Stablecoin issuance · YieldFluidLending and borrowing · DEXFraxRWA · Stablecoin issuance · Lending and borrowingAerodromeDEXMoonwellLending and borrowingFranklin Templeton - BENJIRWASynthetixPredictionZeroLendLending and borrowingSyncSwapDEXEkuboDEXMapleRWA · Lending and borrowingCentrifugeRWAGoldfinchRWASuperstateRWATether - USDTRWA · Stablecoin issuanceCircle - USDCRWA · Stablecoin issuancePayPal - PYUSDRWA · Stablecoin issuanceEtheriscInsurancePolymarketPrediction · RWA · Yield · Crowdfunding1inchDEXLiquityLending and borrowing · Stablecoin issuanceCoW SwapDEXPoolTogetherYieldYearnYield · Lending and borrowingether.fiLiquid staking · PaymentsTrue MarketsPredictionFlaunchLaunchpadOctantCrowdfundingSuperFluidSalary distribution · Lending and borrowingSplits.orgPaymentsJuiceboxETHCrowdfundingPeerOnramp / offrampTellerLending and borrowingAlchemixLending and borrowingWildcatLending and borrowingContangoYieldThe Gauntlet AppYieldSablierPaymentsR3al BlocksRWALemonPayments · WalletDeFi SaverPortfolio managerRipioDEX · Yield · Wallet · Portfolio managerBeloDEX · Yield · WalletOfframpPaymentsDaimo PayPaymentsKyberSwapYield · DEXSuperformYieldSuggest an appWe're always looking for new apps to add to our list. If you know of an app that you think should be on the list, please let us know.Suggest an app (opens in a new tab)","tokens":769,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261309777,"hash":"3040c34be814af3f41efd0a430d653d86d219b66"}
{"url":"https://governance.aave.com/t/arfc-endorse-the-asset-classification-framework-aaca/23114","domain":"governance.aave.com","title":"[ARFC] Endorse the Asset Classification Framework (AAcA) - Governance - Aave","text":"[ARFC] Endorse the Asset Classification Framework (AAcA) \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n Title: [ARFC] Endorse the Asset Classification Framework (AAcA)\n\n Specification\n\n 1. Stablecoins\n\n 2. Wrapped Assets\n\n 4. Protocol Tokens\n\n 5. Tokenized Financial Instruments\n\n Sep 2025\n\n 1 / 6\n\n Sep 2025\n\n Sep 2025\n\n post by LlamaRisk on Sep 11, 2025\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Title: [ARFC] Endorse the Asset Classification Framework (AAcA)\nAuthor: LlamaRisk\nDate: 2025-09-11\nSummary\nFollowing a community discussion, a formalization proposal by @bgdlabs, and an ARFC that passed the snapshot vote, we proposed this document to establish the Aave Asset Class Allowlist (AAcA). This framework is intended to be a collaborative tool maintained by Aave’s Service Providers to streamline and standardize the asset onboarding process. We’re opening this draft for the DAO’s feedback, as we have already started circulating it amongst SPs.\nMotivation\nThe core principle of the AAcA is to group assets into logical categories based on their shared characteristics and collective risk profiles. This structured approach provides several key benefits:\n\nClarity and Consistency: It creates a shared language for all stakeholders, from community members to risk service providers.\n\nSystematic Risk Assessment: By grouping similar assets, risks can be evaluated more systematically, allowing consistent risk parameters across a class.\n\nDeliberate Governance: It forces the DAO to make a conscious and deliberate decision before onboarding a new asset class, ensuring strategic alignment and risk awareness.\n\nThe framework is organized into six primary groups: Stablecoins, Wrapped Assets, Staking & Restaking Derivatives, Protocol Tokens, Tokenized Financial Instruments, and Uncategorized Assets. Each class within these groups is defined with a clear description, its current approval status, and examples of assets that fit the category.\n\nApproved classes are those that have been formalized based on currently or previously onboarded assets. Approved assets are still subject to analysis to determine if they are individually eligible for onboarding.\n\nNot Approved classes are those that have already been reviewed and have been explicitly not approved due to factors such as technical considerations and/or legal implications, among others.\n\nNot Analyzed classes are new categories introduced by recently proposed assets, suggested for future consideration, but not yet formally part of the Aave allowlist. These require assessment, community discussion and formal approval (via ARFC) before onboarding an asset of that class.\n\nSpecification\nAave Asset Class Framework\n1. Stablecoins\nThis group includes all assets designed to maintain a stable value relative to a fiat currency, subdivided by their stabilization mechanism and yield properties.\nimage766×1072 120 KB\n2. Wrapped Assets\nThis group includes tokens representing another underlying asset on a 1:1 basis, differentiated by their utility.\nimage763×274 37 KB\n3. Staking & Restaking Derivatives\nThis group includes all liquid tokens derived from Proof-of-Stake (PoS) staking or restaking activities.\nimage765×263 37.5 KB\n4. Protocol Tokens\nThis group includes tokens integral to a protocol’s function, governance, or utility.\nimage764×205 30.5 KB\n5. Tokenized Financial Instruments\nThis group includes tokenized derivatives and representations of traditional financial assets, including Real-World Assets (RWAs).\nimage768×399 43.4 KB\n6. Uncategorized Assets\nThis group is for unique asset types that do not fit into the other categories.\nimage767×171 19.4 KB\nDisclaimer\nLlamaRisk is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC.\nNext Steps\n\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\n\nIf the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Remove USDS as collateral and increase RF across all Aave Instances\n\n [Direct to AIP] Onboard syrupUSDT to Aave V3 Plasma Instance\n\n [Direct to AIP] Add rlUSD as Collateral\n\n [ARFC] Deploy Aave v3 on X Layer\n\n [ARFC] Onboard frxUSD to Aave V3 Core Instance on Ethereum\n\n 2\n\n post by JosueMpia on Sep 11, 2025\n\n JosueMpia\n\n Really great work here, especially for us DAO members. The AAcA framework does a solid job of defining asset categories (e.g.Stablecoins, Wrapped Assets, LSTs / LRTs / Leveraged LSTs) and their onboarding statuses (Approved, Not Approved, etc.).\nOne small suggestion that could add extra clarity for DAO members: maybe including a short, high-level summary of key risk for each class? Perhaps as a column or tag in each table.\nSince, as you noted, even approved classes still require individual asset analysis, a quick view of typical risk factors could make the framework even more useful, especially for people who don’t go deep into technical due diligence.\nFor example:\n\nReserve-Backed Stablecoins → depeg risk, reserve audit & transparency risk\n\nLeveraged LSTs → slashing risk, validator concentration, volatile yield, liquidity risk\n\nWrapped or Bridged Assets → bridge/oracle dependency, smart contract complexity\n\nAdding this kind of risk overview might help signal what to look out for across classes. Also, I’m assuming that when Aave v4 Spokes start coming out, assets that are not on this list may not be supported right away??? So, Spokes developers will love this list too.\nJust my 2 cents, thanks again for the hard work on this!\n\n post by ChaosLabs on Sep 17, 2025\n\n ChaosLabs\n\n Chaos Labs supports the proposed AAcA Framework and believes its introduction will improve the efficiency of the asset onboarding process.\nIn particular, we emphasize that assets within an approved class must still undergo considerable analysis to determine their individual eligibility for onboarding. Some approved categories, such as yield-bearing stablecoins and bridging assets, often feature assets with unique or non-standardized risks and operating mechanisms. These assets should be evaluated on a case-by-case basis, even if they fall within an approved class or share overlapping mechanisms with previously approved assets. This requirement ensures that each asset’s distinct risk profile is preliminarily assessed to determine its onboarding potential and whether it warrants further review by the risk service provider.\n\n Chaos Labs - Monthly Community Update\n\n post by ACI on Sep 23, 2025\n\n ACI\n\n Leader\n\n The current proposal has been escalated under Skywards, to ARFC Snapshot.\nVote will start tomorrow, we encourage everyone to participate.\n\n post by ACI on Sep 29, 2025\n\n ACI\n\n Leader\n\n After Snapshot monitoring, the current ARFC Snapshot ended recently, reaching out both Quorum and YAE as winning option, with 561.1K votes.\nTherefore [ARFC] Endorse the Asset Classification Framework (AAcA) has PASSED and it has been considered canon @LlamaRisk\n\n 1 month later\n\n Closed on Oct 29, 2025\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave Asset class Allowlist (AAcA)\n\n Development\n\n 8\n\n 912\n\n Sep 2025\n\n [ARFC] Technical Asset Listing Framework\n\n General\n\n 7\n\n 1.5k\n\n Jul 17\n\n About the Assessments category\n\n Assessments\n\n 0\n\n 69\n\n Jun 26\n\n Update on Aave Horizon Asset Onboarding Process\n\n Horizon\n\n 0\n\n 166\n\n Aug 14\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9","tokens":1911,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261316979,"hash":"6971474c026aae6d63d4eab8d84ceb7722c5f5e4"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/46","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n 4\n\n 4\n\n 4\n\n read \n\n 20\n min\n\n May 2025\n\n 45 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n post by ncitron on May 29, 2025\n\n ncitron\n\n vbuterin\n\n How would reduced state nodes know that some piece of cached state they have is stale?\nAs you mention, in a post-statelessness world they could of course check the block’s witness, but it is very possible that the witness is quite large (especially if the proposals to scale mainnet by many orders of magnitude come to fruition).\nYou could try asking a node “please give my state that has changed since last block,” but you have no guarantee that the list is exhaustive and you leak what state you are interested in to third parties.\nYou could download all of the state you care about each block, but this is quite wasteful and still leaks what set you are interested in.\nOne idea here is we could add some probabilistic data structure like a bloom filter to the block that can help nodes check what accounts and slots have changed in that bock. If we can keep false positives low enough (hopefully by learning from the mistakes of the existing logs bloom), we can download close to the minimal amount of data per block, and ensure exhaustiveness.\nThis proposal doesn’t fully solve the privacy concern (although it does reduce the amount of data leakage since you only leak information when state has changed), but if you download your updates via PIR/TEE+ORAM we can temper those concerns. It’s main benefit is that it is probably simpler and more scalable to add to Ethereum today than full bock witnesses.\nAnother idea that does not require any in protocol changes, but hurts the privacy element is to register with n providers what state you care about. These providers can be queried to get the set of state that has changed. We then implement a sort of dispute game. We ask the providers to prepare an ordered list of updated state and merkleize this data structure. If they all agree on the root, we can fetch the full list from one node and if it matches the root, accept it as valid. If there is a disagreement, we can bisect the tree until finding the point of disagreement. At that point, we fetch a merkle proof of this state, and confirm whether it is valid and whether it has changed in a given block. This allows us to identify every dishonest node in the set, and come to agreement on what the correct set is (assuming existential honesty).\nAre there any other techniques I am missing? If we can get a way to do this we would certainly implement it in Helios.\n\n post by vbuterin on May 30, 2025\n\n vbuterin\n\nThey would download deltas (the block-level access list proposals basically include this already)\nWe could require deltas to be sorted, which would allow nodes to download only the portion of deltas relevant to the portion of state they are keeping - though this leaks more data.\n\n post by kladkogex on Jun 4, 2025\n\n kladkogex\n\nWell, Micah, then Vitalik or someone else that has a power at EF needs to state this as the goal of Ethereum Foundation.\nCurrently the statements EF are making absolutely the opposite. Add to this the ghosting policies they have. They never answer questions they do not like.\nRollups a censoring and centralized. Not a single person from Ethereum Foundation ever explained how decentralize them, and they do not want to. They want to have another meaningless token from the likes of Optimism.\nIt is a fake morale build from the top down, I understand the powerlessness of people at the bottom.\nYou would agree with me that it is meaningless to have conversation, when the other party has a profit-maximizing strategy.\nThe pyramid built by the Ethereum Foundation has nothing to do with science and nothing to do with opensource. It has nothing with DAOs. And it has absolutely nothing with the spirit of opensource.\nIt is a very typical Russian organization where people at a particular Layer warship people at the layer above and get war shipped by the people at the layer below…\n\n Powered by Discourse","tokens":4971,"squid":"ink-research","role":"Deep Scholar","at":1791261317081,"hash":"a0a31f250017137291c1f15f6319604031ecc54a"}
{"url":"https://ethereum.org/apps/skymaker-usds/","domain":"ethereum.org","title":"Ethereum Apps - Sky/Maker - USDS | ⁦ethereum.org⁩","text":"DeFiSky/Maker - USDSby Sky EcosystemEnglish Visit Sky/Maker - USDS (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextEthena - USDESee nextEthena - USDESky.money is a non-custodial gateway to the decentralized Sky Protocol, which centers around the USDS stablecoin.InfoFounded2024CreatorSky EcosystemLast updated457 days agoGalleryMore apps like thisDeFiAaveAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.Lending and borrowingDeFiEthena - USDEEthena is a synthetic dollar protocol built on Ethereum that provides a crypto-native solution for money, USDe, alongside a globally accessible dollar savings asset, sUSDe.RWA · Stablecoin issuance · YieldDeFiPendlePendle is a DeFi protocol focused on yield trading, allowing users to both fix or leverage their yield.RWA","tokens":257,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261319909,"hash":"0c1b4026d3acaf30735b79fa4be7dd8da7c26b9d"}
{"url":"https://governance.aave.com/t/coinbase-b20-equities-on-base-assessments/25690/2","domain":"governance.aave.com","title":"Coinbase B20 Equities on Base Assessments - Risk / Assessments - Aave","text":"RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 24\n\n 2 / 2\n\n Sep 23\n\n 12d ago\n\n post by LlamaRisk on Sep 24\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of Coinbase B20 tokenized equities on Aave V4 Base.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 22\n min\n\n post by LlamaRisk on Sep 24\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nThis document is the technical review behind the initial parameters proposed for the tokenized equities market on Aave V4 Base. It covers the legal structure of the certificates, the issuance and redemption mechanics, the token standard and the issuer’s onchain contracts, the handling of corporate actions, and the behaviour of the price feed.\nThe market initially lists the Magnificent Seven US technology stocks in their Coinbase B20 form (AAPLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc, and TSLAc) as collateral in a dedicated Equities Hub, with USDC as the only borrowable asset. Each token is a certificate over shares held in segregated custody under a bare trust governed by ADGM law, offered under a public prospectus approved by the ADGM Financial Services Regulatory Authority. Holders who acquire the tokens on the secondary market hold them as unvested holders with economic exposure but no redemption right until they complete the issuer’s vesting process.\n1. Legal Structure\n\nExpand the legal structure review (sections 1.1 to 1.7)\nThe review is based on the prospectus, the terms and conditions and the deed of trust of the NVIDIA certificates. The seven tokens are issued under the same programme by the same issuer, and the analysis applies to each of them.\n1.1 Jurisdictional Compliance\nThe offering document is a public prospectus, approved by the FSRA on 4 August 2026 (the “Prospectus”) “under section 61(2) of FSMR and section 4.6.2 of the Market Rules” (Prospectus, cover, p. 1), and valid until 3 August 2027 — after which continued primary issuance requires renewal — and obliges the Issuer to publish an FSRA-approved supplement on any significant change or material mistake (Prospectus, Validity of Prospectus, p. 2). The Issuer and both Directors accept responsibility for its contents without qualification (Prospectus, §1.1, p. 20). These are favourable features, though approval is not endorsement: the ADGM “does not accept any responsibility for the content” (Prospectus, cover, p. 1).\nThe Prospectus itself settles the classification of the vested instrument: the Securities “constitute ‘Certificates representing certain Financial Instruments’” under paragraph 92 of Schedule 1 of FSMR and are deemed securities by the FSRA “pursuant to a written determination under section 58(2)(b) of FSMR” (Prospectus, Summary C, p. 14; §13, p. 68).\nThe unvested position carries a second, distinct classification: Unvested Securities “constitute ‘Rights to or interests in investments’” under paragraph 98 of Schedule 1 and “are also deemed to be ‘securities’” (Prospectus, §13, p. 68). The Coinbase DDQ response asserts the opposite — that this category “is not itself listed as a Security type” so no prospectus obligation arises (Coinbase DDQ response, Q3). The same DDQ response inverts the Prospectus on the on-chain token: the Prospectus states the tokens “do not constitute separate securities or independent financial instruments” (Prospectus, §12.8(b), p. 59); the DDQ response asserts “the on-chain token itself is a separate security / independent financial instrument” (Coinbase DDQ response, Q8). The token-status consequences are treated in the title and transfer-restriction sections of this examination.\nThe Issuer’s follow-up response confirms that Securities held by an Unvested Holder “constitute ‘Rights to or interests in investments’” — adopting the Prospectus’s paragraph 98 classification and, in substance, withdrawing the earlier Q3 analysis (Coinbase DDQ response (2), item 1).\nThe regulatory perimeter covers the offering and one service provider, not the Issuer. Nowhere is Coinbase Onchain SPV Ltd described as licensed, authorised or exempt; it is an SPV with no employees whose only activity is issuing Digital Securities (Prospectus, §3.2, p. 21). The Coinbase DDQ response calls it an “Unregulated SPV” (Coinbase DDQ response, Q2).\nThe single regulated ADGM node is Onchain Marketplace Ltd, “authorised by the FSRA to carry on the regulated activities of Arranging Deals in Investments and Providing Custody (restricted to operating a Central Securities Depositary)” (Prospectus, §3.5(b)(i), p. 22), which operates the Relevant System and is the declared Reporting Entity. Favourably, the definitive record of legal title sits inside an FSRA-supervised depositary subject to intraday reconciliation consistent with COBS 10.3.3 (Prospectus, §12.8(c), p. 60); but the permission is narrow, Onchain Marketplace Ltd does not custody the underlying shares. At the asset layer, Alpaca Securities LLC “is an SEC-registered broker-dealer and a member of FINRA and the SIPC” (Prospectus, §3.5(b)(ii), p. 22), contractually bound to remain so (Prospectus, §10(ii), p. 51), and the Issuer’s right to demand return of the shares is “an absolute right preserved under SEC Rule 15c3-3” (Prospectus, §4.5(d), p. 36). Pass-through SIPC protection for Holders in an Alpaca insolvency is expressly uncertain: “neither SIPC’s rules nor its published guidance directly address this novel custody structure” (Prospectus, §4.7(d), p. 41).\nThe Securities are not, and are not expected to be, admitted to trading on any exchange or trading facility anywhere (Prospectus, §13.1, p. 69); they are “solely transferable and traded through DeFi Markets,” which “are not currently regulated in the ADGM” (Prospectus, Summary C, p. 16); and secondary trading “does not constitute participation in the Offer and is not subject to the Offer perimeter” (Prospectus, §4.7(b), p. 39). The Issuer “has not entered into any formal market making or liquidity provider arrangement” and takes no responsibility for one (Prospectus, §13.2(a), p. 70); there is no stabilisation (Prospectus, §13.3, p. 70); and Holders “may have no legal remedies or practical recourse” against market interference (Prospectus, §4.2(f), p. 27).\nThe Securities are unregistered under the U.S. Securities Act, and the prohibition is absolute and perpetual: they may not be acquired, held, sold, transferred or delivered, directly or indirectly, in the United States “or to, or for the account or benefit of, any ‘U.S. Person’”, and all secondary dealings must occur “in offshore transactions in reliance on Regulation S” (Prospectus, §14.1(a), p. 72). Every acquirer is deemed to represent that it is not a U.S. Person, is outside the United States, and is not acquiring for one; the Deed of Trust dated 4 August 2026 (the “Deed of Trust”) recites the same reliance (Deed of Trust, recital (B), p. 103). Unexplained, the cover applies two different tests — Regulation S “U.S. Persons” for the offer, but CFTC-defined “Non-U.S. Persons” for onward delivery (Prospectus, cover, p. 1).\nEnforcement rests on restrictions “embedded in the Security’s smart contract” and binding on all transferees (Prospectus, §4.4(b), p. 31), on blockchain analytics, and on the freeze power — and the Prospectus concedes their limits: “Notwithstanding these restrictions, a Security could be transferred on a peer-to-peer basis or through DeFi Markets” to prohibited persons (Prospectus, §4.7(b), p. 39).\nThe primary offer is made in the ADGM exclusively to Authorised Participants, each a Professional Client under COBS 2.4 or a Market Counterparty under COBS 2.5, approved by the Issuer in its absolute discretion (Prospectus, Summary D, p. 17); in the secondary market, Authorised Participants “may make Securities available in DeFi Markets, including to retail investors” (Prospectus, §13.1, p. 69). Every secondary acquirer takes as an Unvested Holder with no redemption, voting or information rights — “The Issuer will not recognise any Holder as having any rights whatsoever” until vesting (Prospectus, p. 3) — and vesting is determined by the Tokenisation Entity on the Issuer’s behalf, final and binding absent manifest error, and revocable at any time (Terms and Conditions, Condition 2.4(c) and 2.4(e), pp. 81–82). Every liquidation counterparty will therefore stand, on acquisition, in the weakest class the structure recognises; exit runs through a discretionary compliance gate with no committed timeline anywhere in the reviewed material. We take no view on whether any particular holder would satisfy the Vesting Conditions.\nThe Issuer’s follow-up response adds the practical record: no liquidator, enforcement agent or lending protocol’s liquidation contract “has not yet been permitted to Vest” [sic]; expected processing time is described as “short”, with no service standard or outer time limit committed; onboarding discretion is expressly retained; and the Issuer offers to “discuss the process of potentially onboarding … liquidation contract” or partnering with an existing Authorised Participant for that purpose (Coinbase DDQ response (2), item 2).\nThe offer exists only in the ADGM: “no action has been or will be taken by the Issuer that would permit a public offering” anywhere else (Prospectus, §14.1, p. 71); every acquisition must comply with local law without imposing any obligation on the Issuer; and the Issuer reserves an unbounded right “to impose additional restrictions” by jurisdiction, person, wallet, venue or settlement system (Prospectus, §14.1(d), pp. 72–73). Transfers to jurisdictions where the offer was never made “could result in the Securities being frozen at the smart contract level” (Prospectus, Summary C, p. 17). No country-by-country selling restriction schedule exists, and no analysis addresses the lawfulness of holding the token in the European Union, the United Kingdom or elsewhere.\n1.2 Bankruptcy Remoteness\nThe separation architecture rests on a single instrument, the Deed Poll and Declaration of Trust dated 4 August 2026, published in full as Annex 2 to the Prospectus and executed by the Issuer as Trustee “IN FAVOUR OF: THE REGISTERED OWNERS AND UNVESTED HOLDERS” (Deed of Trust, preamble, p. 103). It declares two trusts. First, the Trustee “holds all Deposited Property on trust as bare trustee” for the Registered Owners from time to time (Deed of Trust, cl. 3.1, p. 104), the Deposited Property capturing the NVIDIA shares and everything received in respect of them (Deed of Trust, cl. 1.1, pp. 103–104). Second, where the Trustee is itself registered as owner of Unvested Securities, it holds “the legal title and all Beneficial Interests attaching” to them as bare trustee for the Unvested Holders (Deed of Trust, cl. 4, p. 105). Each Beneficial Interest is “a pro rata equitable interest in the Deposited Property as a whole” (Deed of Trust, cl. 1.1, p. 103).\nThe Deed is governed by ADGM law with exclusive ADGM jurisdiction (Deed of Trust, cll. 15–16, p. 107); as a deed poll, each beneficiary “may severally enforce the obligations of the Trustee” directly (Deed of Trust, cl. 11.2, p. 106), and the trust and segregation “continue throughout any such redemption, termination or wind-down” (Deed of Trust, cl. 14.3, p. 107).\nThe Deposited Property “shall be segregated from, and shall not form part of, the proprietary assets of the Trustee” (Deed of Trust, cl. 3.5, p. 105), and the custodian, Alpaca Securities LLC, must hold it on trust for the Trustee, identified in its books, segregated from Alpaca’s own assets “and, so far as practicable, from the assets of the Custodian’s other clients” (Deed of Trust, cl. 9.2, p. 106). Per the Prospectus’s summary of the Institutional Account Agreement, the custodian “is not permitted to engage in any securities lending”, “shall have no right to assert any applicable rights of lien”, and deposits “will not expire in the event of loss of capacity to act or bankruptcy” of the Issuer (Prospectus, §10(ii), p. 51). The custody accounts stand in the Issuer’s own name, and the Issuer’s right to demand return of the shares is “an absolute right preserved under SEC Rule 15c3-3” (Prospectus, §4.5(d), p. 36).\nUnder the Deed, all claims of Registered Owners and Unvested Holders “under this Deed, however arising, are limited in recourse” to the Deposited Property and its proceeds; no claim lies against the Trustee’s other assets, and once the property is realised and applied, “any outstanding claim of a Registered Owner or Unvested Holder shall be extinguished” (Deed of Trust, cl. 12.2, p. 106). The Prospectus asserts the proposition more broadly: “The Issuer’s obligations to Holders are limited recourse” (Prospectus, §6.3(d), p. 47).\nThe bankruptcy statement is expressly conditional: “subject to the validity of the bare trust arrangements”, the Deposited Property and Unvested Securities will not form part of the Issuer’s assets in an insolvency, and Registered Owners and Unvested Holders “are not creditors of the Issuer” in the ordinary course (Prospectus, §16.6, p. 77). The risk factors concede the central vulnerability in terms: creditors “may apply to a court to challenge or set aside the trust structures”, and proceedings may leave the property “being frozen” with delayed redemptions (Prospectus, §4.7(a), p. 39; Summary, p. 17).\n1.3 Title and Ownership\nTitle runs through five links across three legal systems. First, NVIDIA common stock is held by Alpaca Securities LLC in “segregated Custody Accounts in the Issuer’s name” (Prospectus, §4.5(d), p. 36); the Issuer “holds a beneficial interest in the Underlying” through the custodian (Prospectus, §12.10(b), p. 63) — in United States terms an account holder with an intermediated claim, not the shareholder of record. Second, the Issuer holds all Deposited Property as bare trustee for the Registered Owners under ADGM law (Deed of Trust, cl. 3.1, p. 104). Third, legal title to each Security belongs to its Registered Owner, “the person in whose name legal title” is registered in the Legal Register (Terms and Conditions, Condition 23.1, p. 99). Fourth, for every Security whose holder has not passed vesting, the Registered Owner is the Issuer itself, holding on a second bare trust for the Unvested Holders (Prospectus, §12.8(c), p. 59; Deed of Trust, cl. 4, p. 105). Fifth stands the Holder, defined purely operationally as “the person controlling the Wallet” in which the tokens sit (Terms and Conditions, Condition 23.1, p. 98).\nThe structure’s central design choice is that the token is not the record of ownership. “Legal title to the Securities shall be recorded exclusively by registration in the Legal Register” (Terms and Conditions, Condition 2.2, p. 80); the Legal Register is “the definitive and exclusive record of legal title” (Prospectus, §12.8(c), p. 59). Dealings on any blockchain, wallet or smart contract “shall not create, transfer, evidence, or extinguish legal title” except as reflected in the register, and wherever the two records diverge, “the Legal Register shall prevail” (Terms and Conditions, Condition 2.2, p. 80) — even mid-investigation: “Pending resolution, the Legal Register prevails” (Prospectus, §12.8(c), p. 60). Token possession passes on-chain; legal title passes “solely upon registration in the Legal Register” (Terms and Conditions, Condition 3.2, p. 82). When possession and register entry diverge — hack, erroneous transfer, register error, contested liquidation — the wallet-side party loses on the face of these provisions; the Tokenisation Entity may rescind transfers, cancel Securities, demote vested holders or freeze positions, “in each case with or without payment” (Prospectus, §14.2(a), p. 73).\nThe reconciliation between the two records is disclosed only as a fact: the Tokenisation Entity “carries out intraday reconciliation procedures in its capacity as CSD” (Prospectus, §12.8(b), p. 59). The Prospectus itself concedes that the Legal Register “does not benefit from the transparency and real-time verifiability” of a public blockchain (Prospectus, §4.5(e), p. 36).\nOnly Vested Holders — those who have satisfied the Vesting Conditions “as determined by the Tokenisation Entity” (Terms and Conditions, Condition 23.1, p. 100) — may exercise rights attaching to the Securities (Terms and Conditions, Condition 2.4(a), p. 80). “Unvested Holders shall not be entitled to redeem Securities or withdraw Underlying” (Terms and Conditions, Condition 5.1, p. 85); the unvested claim “is limited to a right to become the Registered Owner” upon vesting (Prospectus, §12.8(d), p. 61), alongside possession, transfer and economic exposure. The Vesting Conditions comprise compliance, wallet-control, bank-account and sanctions requirements, plus “such other conditions as may be specified” from time to time — an open-ended list, whose satisfaction is determined with finality binding “on the relevant Holder and all other persons” absent manifest error (Terms and Conditions, Condition 2.4(c), p. 81). Vested status is revocable at any time in the Issuer’s or the Tokenisation Entity’s sole discretion, on triggers including a wallet merely coming under governmental investigation (Terms and Conditions, Condition 2.4(e), p. 82), and transfer to a non-vested transferee automatically demotes the Security (Terms and Conditions, Condition 3.3, p. 83). Anyone acquiring in secondary markets takes as an Unvested Holder unless and until it satisfies the Vesting Conditions (Prospectus, §13.1, p. 68).\n1.4 Issuer Structure\nCoinbase Onchain SPV Ltd is a private company limited by shares incorporated in the ADGM on 17 June 2026, wholly owned by Onchain Marketplace Holdings Limited and ultimately by Coinbase Global, Inc. (Prospectus, Summary B, p. 12).\nThe board comprises two directors, Jordan Fish and John D’Agostino, both senior Coinbase executives and both holding offices at the very service provider the board exists to oversee: Mr Fish is a director of Onchain Marketplace Ltd; Mr D’Agostino is a director of Onchain Marketplace Holdings Limited and of Onchain Marketplace Ltd and “performs the controlled function of Senior Executive Officer” for the latter (Prospectus, §7.3, p. 48). While “all material decision-making is reserved to the Issuer’s Board of Directors” (Prospectus, §4.5(b), p. 35), the Issuer has no employees and every operation is executed by Onchain Marketplace Ltd — so every discretion exercised “on behalf of the Issuer” is, in personnel terms, an internal Coinbase Group decision.\nThe operation runs on four material contracts summarised in the Prospectus. Under the Tokenisation Services Agreement, effective 1 July 2026, Onchain Marketplace Ltd mints, delivers and burns the Securities, deploys and audits the smart contracts, operates the Relevant System, maintains the Legal Register and verifies Vesting Conditions (Prospectus, §12.10(d), p. 64). Its liability, absent gross negligence, fraud or wilful misconduct, “will not exceed the fees paid to the Tokenisation Entity” to the date of the claim (Prospectus, §10(i), pp. 50–51). The dependency is total: on a failure of the Tokenisation Entity, “the Issuer would immediately lose the ability to process any minting, redemption, transfer control, corporate action, or Deposit Ratio adjustment,” with “no alternative means of performing these functions,” and the offer “would be operationally suspended” pending replacement (Prospectus, §4.5(b), p. 35).\nThe Institutional Account Agreement with Alpaca, dated 30 July 2026 and governed by New York law, contains genuinely strong custody protections as summarised: segregated accounts, no securities lending or proprietary use, no “rights of lien, retention, or other rights to retain” the Deposited Property, and deposits that “will not expire in the event of … bankruptcy on the part of the Issuer” (Prospectus, §10(ii), p. 51); the Deed of Trust requires segregation from the Custodian’s own assets and, “so far as practicable,” from other clients’ assets (Deed of Trust, cl. 9.2, p. 106). Against that, the Custodian’s liability is “limited to a contractually specified amount” that is undisclosed, either party may terminate on written notice of unspecified length (Prospectus, §10(ii), p. 51), and replacement “could take several weeks or longer” (Prospectus, §4.5(d), p. 36). The General Services Agreement with Coinbase Global, Inc., effective 1 July 2026 and governed by California law, supplies finance, legal, compliance and technology support at an undisclosed arm’s-length fee, terminable on notice of unspecified length (Prospectus, §10(iii), pp. 51–52). The Issuer may replace any service provider — and even substitute a new issuer in its own place, subject to conditions including assumption of the trusteeship — without Holder consent (Terms and Conditions, Conditions 18 and 19, p. 96).\nDeloitte & Touche (M.E.) LLP is the appointed ADGM-registered auditor. No audited financial statements yet exist for any period (Prospectus, §8.1, p. 48); the only financial statement is the unaudited day-one balance sheet, predating all four material contracts; and “the Prospectus has not been audited or reviewed by the Auditors” (Prospectus, §9.1, p. 49). No reserve attestation or systems assurance report is referenced in the Prospectus, and the Coinbase DDQ response confirms none exists yet (Coinbase DDQ response, Q14).\n1.5 Subscriptions, Withdrawals and Redemption\nSecurities enter circulation through one channel only: creation by Authorised Participants “is the sole means through which Securities may come into circulation” (Prospectus, §12.8(e), p. 62). An Authorised Participant must be a Professional Client or Market Counterparty, “approved and engaged by the Issuer (in its absolute sole discretion)” (Prospectus, §13.2(a), p. 70), under an Authorised Participant Agreement which is not published — confidential, per an unverified issuer statement (Coinbase DDQ response, Q1). The creation fee is one basis point of the invested amount (Prospectus, §12.11(i), p. 66).\nThe creation is suspendable and cappable: the Issuer may suspend or refuse issuance generally or in particular instances (Terms and Conditions, Condition 2.3, p. 81), and “the Tokenisation Entity may limit the number of Securities that can be created in a 24-hour period” (Prospectus, §13.1, p. 69). Further, the Issuer “has not entered into any formal market making or liquidity provider arrangement” with any Authorised Participant (Prospectus, §13.2(a), p. 70), no price stabilisation will occur (Prospectus, §13.3, p. 70), and divergence between the trading price and the Underlying “may be significant” (Prospectus, §4.2(c), p. 25).\nThe redemption right belongs to Vested Holders alone, and the exclusion of everyone else is express and double-barrelled: “Unvested Holders shall not be entitled to redeem Securities or withdraw Underlying” (Terms and Conditions, Condition 5.1, p. 85). Vested status is determined by the Tokenisation Entity on the Issuer’s behalf, and that determination is, “in the absence of manifest error, … final and binding” on the holder and all other persons (Condition 2.4(c), p. 81). The Prospectus itself contemplates that the exclusion can become permanent: “the corresponding Underlying … may remain permanently held by the Issuer” (Prospectus, §4.4(e), p. 32), and “a partial or total loss of invested capital is possible” through vesting failure (Prospectus, §4.4(c), p. 31).\nA redeeming Vested Holder submits a Redemption Order “in such form and manner as the Tokenisation Entity may prescribe from time to time” (Terms and Conditions, Condition 5.2, p. 85). The prescribed form, the operational timetable and any settlement deadline appear nowhere in the Prospectus, the Terms and Conditions or the Deed of Trust; the procedures may be “otherwise determined by the Issuer or the Tokenisation Entity in their sole and absolute discretion” (Prospectus, §12.8(e), p. 62).\nBefore acceptance, the Tokenisation Entity, the Custodian or any relevant service provider may re-run any validation — expressly including re-verification of the Vesting Conditions “whether or not previously satisfied” — and may “reject, suspend, delay, or conditionally accept any Redemption Order” (Terms and Conditions, Condition 5.4, pp. 86–87). After acceptance a broader power applies: “Notwithstanding acceptance of a Redemption Order”, the Issuer, the Custodian or the Tokenisation Entity may suspend, delay or modify settlement inconsistent with Applicable Law, sanctions requirements, custody requirements, “market conditions”, settlement restrictions, or operational requirements of the Relevant System (Condition 5.4, p. 87). Neither stage carries a duration limit.\nThe settlement election belongs, in the first instance, to the redeeming Vested Holder, who may choose among in-kind transfer of the Underlying to a nominated custody or brokerage account, sale for US dollars to a nominated bank account, or sale and conversion into “USDC or such other stablecoin as may be accepted” delivered to a nominated Wallet (Terms and Conditions, Condition 5.3, p. 86). The redemption fee is five basis points of the redemption amount (Prospectus, §12.11(ii), p. 66).\n1.6 Investment Programme, Yield and Distribution\nThe Issuer applies creation proceeds “solely to acquire the corresponding Underlying” and “does not retain the subscription proceeds for its own account” (Prospectus, §11, p. 53). There is no investment mandate, no leverage against the Deposited Property and no rehypothecation: the Custodian “is not permitted to engage in any securities lending or other proprietary transactions” affecting the Deposited Property and has “no right to assert any applicable rights of lien” or retention over it (Prospectus, §10(ii), p. 51).\nEach Security is backed by NVIDIA common stock through the Deposit Ratio — the number of Underlying represented by one Security, “as determined and adjusted by the Issuer” (Terms and Conditions, Condition 23.1, p. 98). The Prospectus elsewhere states that costs are funded through fees and the affiliate loan facility (Prospectus, §11, p. 53), which cuts against routine downward adjustment, but nothing in the Conditions confines the power.\nHolders never receive cash. Condition 6 operates “in lieu of making any distribution of cash to Holders”: cash distributions received on the Underlying are applied, net of the Issuer’s fees and withheld taxes, to purchase additional Underlying, reflected as an upward adjustment to the Deposit Ratio (Terms and Conditions, Condition 6(i), p. 87). Distributions of shares are retained; other property is sold and reinvested, or retained; subscription rights may be exercised, sold, or permitted to lapse in the Issuer’s discretion; and under the compliance limb the Issuer may hold amounts “uninvested and without liability for interest” (Condition 6(ii)–(v), pp. 87–88). The Securities do not bear interest (Prospectus, §12.1, p. 54).\nThe distribution fee is “5.0% of the gross aggregate value” of any dividends, computed “before any withholding, deductions, or reinvestment” (Prospectus, §12.11(iv), p. 66); United States withholding is “currently 30% for non-U.S. Holders (unless reduced by applicable treaty)” (Prospectus, §12.11(iii), p. 66).\nCorporate actions vest wide reshaping powers in the Issuer. An Adjustment Event extends to “any other event” affecting the Underlying, the Underlying Issuer or the Deposited Property “that, in the opinion of the Issuer, requires an adjustment” (Terms and Conditions, Condition 4.2(a), p. 84). On such an event the Issuer may exchange or surrender the Underlying for other shares, securities, cash or property; may in its sole discretion “call for surrender of the Securities in exchange” — against payment of the Issuer’s fees and expenses — for new Securities describing the substituted Underlying; and, on a partial redemption of the Underlying, selects which Holders are redeemed “in such manner as it shall determine” (Condition 4.2(e), p. 85). A delisting of NVIDIA without immediate re-listing feeds into a sole-discretion termination (Condition 4.2(b), p. 84); Holder consent is expressly not required and a failure of notice does not invalidate an adjustment (Condition 4.2(d), p. 85).\n1.7 Transfer Restriction Enforcement and the Secondary Market\nA transferee who satisfies the Vesting Conditions at the time of transfer takes Vested Securities and is registered. Where the transferee does not, “the relevant Securities shall automatically be redesignated as Unvested Securities and legal title thereto shall be held by the Trustee” on trust for the transferee (Terms and Conditions, Condition 3.3(ii), p. 83). This is the ordinary design of the whole secondary market: persons other than Authorised Participants acquire only through secondary transactions “and will hold them as Unvested Holders unless and until they satisfy the Vesting Conditions” (Prospectus, §13, p. 68). A liquidator seizing the token therefore holds, at that moment, an unvested position — no redemption right, no entitlement to termination proceeds, no registered legal title — with a route to vesting that is discretionary.\nAsked how a secured creditor would enforce in practice, the Issuer elaborates: enforcement “will ultimately depend on the type of security interest”; a creditor with a direct right of appropriation — under a financial collateral arrangement, foreclosure under a mortgage, or conversion of a charge into an equitable mortgage — “would likely enforce directly against the debtor”, and otherwise “via application to the court for appointment of a receiver”; the appropriator declares the appropriation to the trustee, which “will update its records”, and “take[s] the equitable interest without procuring a transfer of the legal interest”, on the footing that “the normal principles of derivative transfer of title apply” to Unvested Securities; a transfer of legal title still requires onboarding as a Vested Holder; and the Tokenisation Entity may freeze, pause, rescind or cancel Securities “to give effect to the order of a court or authority recognised in the ADGM” (Coinbase DDQ response (2), item 3).\nThe unvested position is not a nullity: it expressly includes “a beneficial interest in such Securities” and “a right to possess, transfer, and benefit from economic exposure to the Underlying” (Terms and Conditions, Condition 2.4(d), p. 81). That interest is protected by an express trust — the Trustee holds “the legal title and all Beneficial Interests” as bare trustee for Unvested Holders (Deed of Trust, cl. 4, p. 105), the Deed takes effect as a deed poll in their favour, and each Unvested Holder “may severally enforce the obligations of the Trustee owed to them” (Deed of Trust, cl. 11.2, p. 106). An unvested token thus remains a possessable, transferable instrument carrying trust-protected exposure to NVIDIA stock.\nThe Prospectus and the Conditions do not describe the unvested position identically, and the divergence should be recorded rather than smoothed over. The Conditions grant a right “to possess, transfer, and benefit from economic exposure” (Condition 2.4(d)(ii), p. 81); the Prospectus body states that “the claim of any Unvested Holder is limited to a right to become the Registered Owner thereof” (Prospectus, §12.8(d), p. 61).\nThe Issuer’s follow-up response restates the register and vesting mechanics without choosing between the two formulations (Coinbase DDQ response (2), item 4). Its enforcement answer, however, proceeds on the footing that the unvested position is a present equitable interest capable of transfer and appropriation — the reading the Conditions and clause 4 of the Deed of Trust support — rather than a bare vesting expectancy.\nThe Prospectus describes a substantial apparatus — blacklisting, freezing, pausing, cancellation, rescission, redesignation, burning — operable at the smart-contract level “without requiring counterparty cooperation” (Prospectus, §14.2(d)(iii), p. 74). Possession transfers on-chain first, effective “upon validation and execution of the relevant transaction on a Blockchain Network” (Terms and Conditions, Condition 3.2(i), p. 82), and secondary trading occurs “outside of the CSD environment” (Prospectus, §4.3(b), p. 27). The single ex-ante, machine-enforced control described is address blocking: “The smart contract will block interactions with addresses flagged as sanctioned” (Prospectus, §14.2(b), p. 73), the Conditions adding, permissively, that the smart contracts “may include” controls against Wallets on the Designated List (Terms and Conditions, Condition 3.5, p. 83). Every other tool operates after settlement, on detection: a graduated protocol proceeding from identification of an ineligible address, through a freeze “denying the Holder all ability to transfer the Security or receive any economic benefit”, to ongoing monitoring (Prospectus, §14.2(d), p. 74), together with the power of “rescinding any purported transfer in violation of this Prospectus” (Prospectus, §14.2(a), p. 73).\nThe Tokenisation Entity may rescind transfers, cancel “any or all Securities”, redesignate Vested Holders, or freeze Securities on-chain, “in each case with or without payment” (Prospectus, §14.2(a), p. 73). A freeze denies all economic benefit “until the position is no longer prohibited (which may never occur)” (Prospectus, §4.2(a)(ii), pp. 24–25); detected prohibited holdings may be “frozen or burned” (Prospectus, §4.2(a), p. 25). No provision imposes a duration limit on a freeze, a compensation standard for a cancellation, or any procedure for contesting or releasing either.\nCondition 3.5 permits freezing, cancellation, or the refusal, suspension, delay, reversal or invalidation of any transfer where the Tokenisation Entity determines in good faith that action is necessary or advisable for legal, sanctions, compliance, custody or operational reasons, that a Designated List Wallet is involved, that a transfer “would expose the Issuer, Trustee, Custodian, or Tokenisation Entity to legal, regulatory, sanctions, or reputational risk”, or that it “would otherwise be inconsistent with the Relevant System” (Terms and Conditions, Condition 3.5, p. 83). The Prospectus separately reserves to the Issuer, “in its sole and absolute discretion and without liability”, power to refuse or suspend transfers “or require the disposal or transfer of Securities” (Prospectus, §14.1(a), p. 71) — a forced-disposal power.\nThe Tokenisation Entity “conducts continuous on-chain monitoring and reconciles on-chain positions against the Legal Register on an intraday basis” (Prospectus, §4.4A(b), p. 40), “applies blockchain analytics to risk-label external addresses” (Prospectus, §4.4(b), p. 31), and subjects all addresses holding Securities to “sanctions screening and transaction monitoring of the destination address”, with enhanced manual review above defined thresholds (Prospectus, §14.2(c), p. 73).\n+++++\n\n2. Issuance, Holding and Redemption\nPrimary issuance is available only to authorised participants approved by the issuer, which must qualify as professional clients or market counterparties under ADGM rules. Authorised participants mint against delivery of shares or cash and may sell the tokens into secondary markets, including to retail holders. The creation fee is one basis point and the redemption fee is five basis points.\nAnyone who acquires the tokens on the secondary market holds them as an unvested holder. An unvested holder has possession of the token, the right to transfer it, and the economic exposure to the underlying shares, which are held for it on a second bare trust. It does not have a redemption right until it completes the issuer’s vesting process, which covers compliance, sanctions, and wallet-control checks and is conducted at the issuer’s discretion. Vested holders may redeem in kind, in US dollars or in USDC. The securities are offered outside the United States under Regulation S and may not be held by US persons.\nThis structure has a direct consequence for liquidations. A liquidator that seizes tokens holds them as an unvested holder and must either sell them on the secondary market, hedge them until they can be realised, or complete vesting before it can redeem. Vesting has so far been used by authorised participants, and there is no separate onboarding path for a liquidator or a lending contract, so the redemption route should be treated as available only to parties that already hold the right. No minimum amounts, timing windows, or jurisdictional conditions apply to redemption beyond the fee, although the issuer may introduce them.\n2.1 Primary Issuance Path\nEvery mint runs through the issuer’s token supply manager, which is the only holder of the mint role on the tokens, so authorised participants never interact with the token contract directly. In practice a participant places an order off-chain, the issuer settles the share or cash leg in custody, and a single minter key then calls the supply manager, which mints to the participant’s wallet and records the order identifier so that the same order cannot be executed a second time. Nothing on-chain ties the token supply to the shares held at the custodian, since there is no order queue, no proof-of-reserves check ahead of a mint, and no attestation of the share inventory. The issuer reconciles the two off-chain, and the audited accounts and reserve reports that would evidence that reconciliation do not yet exist.\nThe only on-chain limit on issuance is the allowance assigned to the minter, which caps the amount of each token that can be created in any 24-hour window and refills continuously over that window. The amounts, listed in section 3, come to about USD 5M per token per day at current prices, and the issuer’s administrator can change or remove them in a single transaction. A mint can be directed to any address that is not on the transfer blocklist.\nThe seven names saw their first mint on 12 August 2026, and since then the supply manager has processed 1,669 mints and 803 redemptions on them, worth USD 34.7M and USD 20.3M respectively at the daily close, with the weekly volumes per token shown below. The same contract also serves the issuer’s other six equity tokens and seven test tokens, bringing its totals to 2,634 mints and 1,533 redemptions since late July 2026, so any operational change to it reaches every listed name at once.\nchart2520×1080 111 KB\nSource: LlamaRisk, 23 September 2026\n2.2 Redemption Path\nRedemption runs through the same contract in the opposite direction. The redeemer transfers tokens to the supply manager, which burns them and records the multiplier in force at the time, and the issuer then settles the share or cash leg off-chain. Before the burn the call passes three checks:\n\nThe caller must be a member of the redeem allowlist held in Base’s policy registry,\nthe token must not have its redemption paused on the manager,\nand the redeemed amount must clear a per-token minimum, which is currently zero for all seven names.\n\nThe redeem allowlist is where the vesting gate described in section 1 takes effect on-chain, and it is managed by the issuer’s administrator key. On 23 September 2026 it holds five addresses, all of them externally-owned accounts, which were added one at a time on 24 July, 2 August, 18 August, 31 August and 13 September 2026. Since redemption carries no rate limit, an allowlisted party can redeem its entire holding in one transaction and depends only on the issuer’s off-chain settlement thereafter.\nThe supply manager also carries a per-token redemption pause, but only an address holding a redeem-pauser right can use it and the issuer has not granted that right to anyone. As a consequence, when the issuer halts redemptions around a corporate action it does so by no longer processing orders off-chain, and nothing on-chain records that redemptions are closed. An integrator that wants to know whether a corporate-action window is open therefore has a single signal to read, which is the pause flag on the oracle registry described in section 5.\nProcessing times for either leg are not observable on-chain. A mint appears only at the moment the minter key executes it, and a redemption burns in the same transaction in which the redeemer hands over the tokens, so neither event records when the order was placed or how long the issuer took to settle the share or cash leg in custody. The offering documents commit to no timetable either. Creation orders are processed at the issuer’s discretion and may be capped per 24-hour period, a redemption order is submitted in whatever form the tokenisation entity prescribes and can be delayed or suspended both before and after acceptance with no outer time limit, and the issuer describes the processing time for vesting only as short. We therefore treat the timing of the primary route as resting entirely on the issuer.\n2.3 Secondary Holding and Transfer Controls\nSecondary transfers need no allowlist, but every transfer is checked against a single blocklist held in Base’s policy registry, with the check applied to the sender, the receiver, and the account submitting the transaction, and the same blocklist decides who may receive a mint. A blocked transfer reverts. Approvals are not checked against the list, so an allowance can remain in place for tokens that can no longer move.\n\nProperty\nValue\n\nPolicy\nBlocklist, policy id 5 in the policy registry\n\nCreated\n10 July 2026, by the issuer’s deployer key\n\nApplied to\nTransfer sender, transfer receiver, transfer executor, and mint receiver on all seven tokens\n\nAdministrator\nCompliance administrator 0xEC0F…2812, externally-owned account, no handover pending\n\nMembers on 23 September 2026\n479 addresses\n\nChange control\nOne administrator, no delay, no cap on batch size\n\nThe list was seeded in bulk and has grown in occasional batches since.\n\nDate\nChange\nMembers after\n\n22 July 2026\n390 addresses blocked in eight transactions\n390\n\n23 July 2026\n7 blocked\n397\n\n4 to 11 August 2026\n8 blocked, 1 unblocked\n404\n\n25 August 2026\n25 blocked\n429\n\n10 September 2026\n52 blocked\n479\n\nThe compliance administrator is a different key from the issuance administrator, which is consistent with the issuer’s statement that compliance functions are held apart from issuance functions.\n3. Token Standard and Issuer Contracts\nThe tokens are implemented on B20, a Base-native token standard that runs as a chain precompile and extends ERC-20. Balances never change, each token instead carries a multiplier that starts at 1.0 and moves only on corporate actions.\nTransfers are open to anyone not on the blocklist described in section 2.3. Each token can pause transfers, mints, and burns separately, can burn the balance of a blocked account, and gains a seize function with the Cobalt network upgrade. The tokens carry no supply ceiling of their own, and issuance is bounded instead by the issuer’s supply manager contract, which the rest of this section describes.\n3.1 Onchain Footprint\nThe seven tokens are precompile accounts whose bytecode is a single marker byte, so their behaviour comes from the Base node software rather than from verified contract source. The issuer’s own contracts sit beside them, all deployed by one deployer key on 10 July 2026, and the issuer’s asset factory then created the thirteen equity tokens on 26 July 2026.\n\nComponent\nAddress\nFunction\n\nAAPLc\n0xb200…d1fb\nB20 asset precompile, 8 decimals, supply 6,437\n\nAMZNc\n0xb200…C2E8\nB20 asset precompile, 8 decimals, supply 7,706\n\nGOOGLc\n0xb200…58B7\nB20 asset precompile, 8 decimals, supply 6,584, multiplier 1.000377 after one reinvested dividend\n\nMETAc\n0xb200…707C\nB20 asset precompile, 8 decimals, supply 3,854\n\nMSFTc\n0xB200…872B\nB20 asset precompile, 8 decimals, supply 3,986\n\nNVDAc\n0xB200…108C\nB20 asset precompile, 8 decimals, supply 16,618\n\nTSLAc\n0xb200…0cD0\nB20 asset precompile, 8 decimals, supply 2,838\n\nToken supply manager (proxy)\n0xd1ca…664c\nHolds the mint and burn roles on every token. Executes mints for the configured minter and processes redemptions for allowlisted redeemers. Rate-limits minting per caller through an allowance that refills linearly over a 24-hour interval\n\nToken supply manager (implementation)\n0x3F27…C6E3\nVersion 2, verified source, in force since 11 August 2026\n\nAsset factory (proxy)\n0x4bA3…534D\nCreates tokens through the B20 factory precompile, seeds the transfer blocklist into each new token, and registers it on the supply manager\n\nAsset factory (implementation)\n0xbBcb…28Ca\nVerified source, unchanged since deployment\n\nOracle registry\n0x3f3E…5CaD\nPublishes the live multiplier and a pause flag per token. Chainlink reads both from this contract. Not a proxy, verified source\n\nPolicy registry\n0x8453…0002\nBase precompile holding the transfer blocklist (policy 5) and the redeem allowlist\n\nB20 factory\n0xB20f…0000\nBase precompile that creates B20 tokens at deterministic addresses\n\n3.2 Upgrade Architecture\nThe token logic changes only when Base upgrades the network. B20 arrived with the Beryl upgrade, and the Cobalt upgrade on 30 September 2026 swaps in new logic behind the same precompile addresses, adding the scheduled multiplier path, the seize function, composite policies, and ERC-165 interface detection. Because a fork changes every B20 token on the chain at once, the issuer cannot opt out and has nothing to sign. Base’s contract upgrades are authorised jointly by a Coinbase signer set and the Security Council for Base, although the B20 documentation does not say who sets a fork’s activation time.\nThe issuer’s own contracts follow a more conventional pattern. The supply manager and the asset factory are UUPS proxies whose upgrader role sits with a single externally-owned account and is not behind a timelock. The supply manager has been upgraded once, on 11 August 2026, when version 2 added the order identifier on mints and separated the redemption checks, while the asset factory has not changed since 10 July 2026. The oracle registry is a plain contract with no upgrade path, so changing what Chainlink reads would require a new deployment and a feed reconfiguration.\nNone of the changes available to the issuer is subject to an on-chain delay, so contract upgrades, role grants, policy edits, and allowance changes all take effect in the transaction that submits them.\n3.3 Audit History\nThe B20 precompile has been reviewed by Spearbit researchers working through Cantina ahead of each Base upgrade that touched it, and the reports are published in the Base repository.\n\nAudit\nDate\nCoverage\nOutcome\n\nCantina, B20 precompiles\nReview 1 to 9 June 2026, report 14 August 2026\nB20 token and policy registry precompiles as shipped in Beryl\n29 findings, 1 High (oversized precompile inputs aborting the EVM) fixed, 11 Low, 17 informational\n\nCantina, precompile macros and storage\nReview 1 to 9 June 2026, report 14 August 2026\nStorage layout and macro layer under the precompiles\n37 findings, 5 Medium, 13 Low, 19 informational\n\nCantina, Cobalt precompile diff\nReview 17 August to 2 September 2026, report 10 September 2026\nSeize, scheduled multiplier, composite policies, ERC-165\n20 findings, 1 High (policy update access order on the stablecoin variant) fixed, 1 Medium, 4 Low, 3 acknowledged\n\nCantina, Cobalt dynamic upgrades\nReport 19 September 2026\nFork-activation mechanism nodes poll from L1\n1 High, 6 Medium, 9 Low\n\nThe Beryl reviews cover the code running today, and the Cobalt review covers the changes that go live on 30 September 2026, which means that the scheduled multiplier path and the seize function have been reviewed once and have not yet run in production.\nNo audit of the supply manager, the asset factory, or the oracle registry has been published, and the prospectus does not cite one either, saying only that the tokenisation entity deploys and audits the smart contracts. The three contracts are small, with verified source, and are built from standard OpenZeppelin access control and UUPS components, but version 2 of the supply manager, in force since 11 August 2026, postdates any review the July deployment may have had. Coinbase runs a bug bounty on Cantina that covers every mainnet contract it has deployed, with a maximum payout of USD 5M for a critical finding, and Base runs a separate HackerOne programme for off-chain and infrastructure findings, both referenced in the Base security policy. No unfixed critical finding is reported across the audits or the bounties.\n3.4 Access Control Model\nEvery contract in the footprint uses OpenZeppelin role-based access control, and on 23 September 2026 every role resolves either to an externally-owned account or to the supply manager, with no multisig, timelock, or module contract anywhere in the role tables. The issuer has indicated that administrative actions go through a hardware-backed key management system with multiple approvals, and that compliance keys are held apart from issuance keys.\nThe token roles are defined by the B20 standard. The default administrator grants and revokes every other role, changes the policy slots, and sets the supply cap, and the standard will not let the last default administrator be removed unless it deliberately renounces into a state with no administrator at all. A role-gated call checks the role first and then whether the feature concerned is paused.\n\nRole\nPurpose\nHolder (on-chain)\n\nDEFAULT_ADMIN_ROLE on all seven tokens\nGrant and revoke every token role, update the four policy slots, set the supply cap\nIssuance administrator 0x3846…72B1, externally-owned account\n\nOPERATOR_ROLE on all seven tokens\nUpdate the multiplier instantly, schedule or cancel a multiplier update after Cobalt, wrap calls in an announcement\nOperator 0x5da4…4d9a, externally-owned account, and on GOOGLc only a second operator 0xe6cb…8c37, externally-owned account, granted on 14 September 2026 in the transaction that applied the dividend multiplier\n\nMINT_ROLE and BURN_ROLE on all seven tokens\nMint to any non-blocked address, burn the caller’s own balance\nToken supply manager only\n\nPAUSE_ROLE and UNPAUSE_ROLE on all seven tokens\nPause and unpause the transfer, mint, burn, and seize features individually\nPauser 0x2fb5…bcdd, externally-owned account\n\nMETADATA_ROLE on all seven tokens\nChange name, symbol, contract URI, and extra metadata such as the ISIN\nOperator 0x5da4…4d9a and 0x1cc0…beca, externally-owned accounts\n\nBURN_BLOCKED_ROLE and SEIZE_ROLE on all seven tokens\nBurn from a blocked account (deprecated), seize from any non-exempt account after Cobalt\nNo holder\n\nDEFAULT_ADMIN_ROLE on the supply manager\nConfigure and remove minters and their allowances, register and deregister tokens, set the redeem policy, set the per-token redeem minimum, grant redeem pausers, grant the factory and upgrader roles\nIssuance administrator 0x3846…72B1\n\nUPGRADER_ROLE on the supply manager and the asset factory\nReplace the implementation\nUpgrader 0x7D4D…a106, externally-owned account\n\nFACTORY_ROLE on the supply manager\nRegister a newly created token and its redeem minimum on the supply manager, called at the end of each token deployment\nIssuer asset factory 0x4bA3…534D, the proxy contract listed in 3.1, which needs this role to complete a deployment\n\nConfigured minter on the supply manager\nCall the mint function within the per-token 24-hour allowance\nMinter 0x06fB…AbA8, externally-owned account, the only minter on all seven tokens\n\nDEFAULT_ADMIN_ROLE on the asset factory\nGrant token deployer and upgrader roles\nIssuance administrator 0x3846…72B1\n\nTOKEN_DEPLOYER_ROLE on the asset factory\nCreate new tokens with the issuance administrator as token admin and the operator as operator\nDeployer 0xE090…5C6f and 0xeE63…cC70, externally-owned accounts\n\nDEFAULT_ADMIN_ROLE and PAUSER_ROLE on the oracle registry\nGrant roles, set the per-token pause flag that halts the Chainlink feed\nIssuance administrator 0x3846…72B1\n\nRedeem allowlist administrator\nAdd and remove redeemers\nIssuance administrator 0x3846…72B1\n\nTransfer blocklist administrator\nBlock and unblock addresses on the policy applied to every transfer and mint\nCompliance administrator 0xEC0F…2812, externally-owned account\n\nThe issuance administrator sits at the root of the structure, since it is the default administrator on every token, on the supply manager, on the asset factory, and on the oracle registry, as well as the registry’s only pauser and the administrator of the redeem allowlist. Whoever holds that key can grant any role on any token to any address, re-point a transfer policy slot, lift the mint allowance, replace the redeem policy, or halt the price feed, each in a single transaction. The operator key is the second point of concentration, because it can move the multiplier on all seven tokens instantly and with no bound on the size of the step, and since 14 September 2026 a second operator key has held the same power on GOOGLc.\nPolicies in the registry follow their own rules. Each policy has one administrator at a time, handing it over takes a stage step followed by a finalise step, and an administrator that renounces freezes the membership permanently. Neither the blocklist nor the redeem allowlist has a handover pending, so both can still be changed.\n3.5 Pause Surface\nThree pause mechanisms coexist, and none is active on 23 September 2026.\n\nToken feature pause. The pauser key can pause transfers, mints, and burns on any token separately, and seizures once Cobalt is live. A transfer pause stops every balance movement, so supplies, withdrawals, and the collateral leg of a liquidation all fail until it is lifted and a position cannot be unwound on-chain in the meantime, although approvals continue to work. The issuer describes on-chain pauses as unlikely, the pause roles were first granted on 3 September 2026, and no token has been paused since deployment.\nRedemption pause. The supply manager can pause redemptions per token, but only an address with a redeem-pauser right can do so and none has been granted, so the pause on minting and redemption that the issuer applies around corporate actions is an off-chain decision not to process orders.\nOracle registry pause. The issuance administrator can set a flag per token that Chainlink reads, and while it is set the feed stops publishing and holds its last value. The flag has never been set on any of the seven tokens. This is the pause the issuer intends to use around corporate actions, and because tokens keep changing hands against a frozen price while it is set, the affected reserve is paused on the Aave side for the same window.\n\nLike every role action, a pause executes immediately with no on-chain delay.\n3.6 Multiplier and Corporate-Action Controls\nTwo properties of the corporate-action path shape the controls on the Aave side. The operator role can change the multiplier instantly, and although the standard recommends wrapping the change in an on-chain announcement it does not enforce it. The standard also defines a scheduled path with an effective time, following ERC-8056, but that path is not active on the deployed tokens and only arrives with the Cobalt upgrade on 30 September 2026, together with pre-announcement of pending changes and ERC-165 interface detection. Until then the tokens should be treated as not conforming to those interfaces, and a multiplier change that does not match an announced corporate action is treated as a price incident, with the affected reserve paused until the change is explained.\nThe instant update has no limit on the size of the step and does not check the state of the feed, so a mis-sequenced or mistaken call can move the token’s value by any factor in one transaction. After Cobalt the scheduled path allows one pending update at a time with an effective timestamp, which the operator can cancel before it matures, but maturation itself writes nothing and emits no event, so an integrator has to read the pending value and its effective time directly rather than wait for a signal. The instant setter remains available as an emergency path and clears any pending update. Because the oracle registry reads the multiplier live from the token, a change reaches the Chainlink feed on its next update unless the registry pause flag has been set first.\nThe multiplier has moved once across the seven tokens, for the GOOGLc cash dividend of 14 September 2026. At 15:39 UTC the operator key posted an announcement on GOOGLc describing the dividend and linking to the issuer’s corporate-action record, with no state change inside it, and at 18:29 UTC a second key, granted the operator role in the same block, applied the multiplier update from 1.0 to 1.000377 inside a second announcement carrying the same description and record identifier. The oracle registry was not paused for the event, as expected for a dividend with no price discontinuity. In effect this is the pre-announcement pattern the issuer intends to formalise after Cobalt, carried out for now as two operator transactions about three hours apart.\n3.7 Supply Bounds\nNone of the seven tokens has a supply cap, although the token administrator can set one at any value at or above the current supply. What bounds issuance instead is the minter’s allowance on the supply manager, which refills at the rates below, equivalent to about USD 5M per token per day at current prices, while redemption is limited to allowlisted addresses and has no rate limit.\n\nToken\nMint allowance per 24 hours\n\nAAPLc\n15,500\n\nAMZNc\n19,100\n\nGOOGLc\n15,700\n\nMETAc\n8,200\n\nMSFTc\n10,300\n\nNVDAc\n24,000\n\nTSLAc\n14,300\n\nSource: Base onchain data, 23 September 2026\nThe allowances for AAPLc, GOOGLc, METAc, and NVDAc were set on 2 August 2026 and those for AMZNc, MSFTc, and TSLAc on 3 September 2026, and none has changed since. The issuance administrator can change them at any time with immediate effect, and because the add caps in the Aave V4 Base deployment ARFC are sized against these values, a change to them is a reason to revisit the caps.\n4. Corporate Actions\nCorporate actions reach the chain through the multiplier. A reinvested dividend moves it by a fraction of a percent with no price event, and a split moves it by the split ratio at the same moment as the underlying price divides by that ratio. A split is the event that matters for a lending market, because if the token applies the new multiplier before the feed applies the new price, or the reverse, the token is mispriced by the full split ratio until the two realign.\nThe issuer’s current sequence is to pause minting and redemption off-chain and pause the feed through the oracle registry, update the multiplier, verify that the new underlying price multiplied by the new multiplier matches the held value, and then resume the feed and the off-chain flows. The announcement accompanies the multiplier update in the same transaction, and the multiplier update event is the point at which the action is considered processed onchain. The issuer has stated that every direct multiplier update will be wrapped in an announcement. That commitment is operational, since the standard does not enforce it, and it is expected to move to a pre-announcement once the network upgrade described in section 3 is live.\nDividends are reinvested at the time and price of the dividend payment, net of withholding tax and the issuer’s distribution fee, and reach the token as an increase in the multiplier. Because there is no price discontinuity, a dividend does not require a feed pause. Fractional amounts and later correcti","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261327216,"hash":"9880af9050eb995253c7fd8e355b38494cd5bb86"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/38","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 37 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by MicahZoltu on May 19, 2025\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence). If they have all of the state they need then the only extra proving is by the block builder once per block, where the block builder would generate and distribute a proof of the state diff for their block. This is different from light clients like Helios who route all of their queries through third parties.\n\n post by MicahZoltu on May 19, 2025\n\n MicahZoltu\n\nWhat is being discussed here is RPC serving nodes, not staking nodes. You are correct that stakers can afford hardware, and they are a service provider being paid to do work so it is reasonable to require this of them. RPC serving nodes are end-users that may be poor, may have low end hardware, and likely aren’t going out of their way to build out Ethereum-only PCs/servers.\n\n post by vbuterin on May 20, 2025\n\n vbuterin\n\n MicahZoltu\n\n The idea would be that:\n\nFor data you want to read, you store and keep up-to-date only the state\nFor data you want to use in the validation section of a tx, you store and keep up-to-date the state and the sister nodes up to the root\n\n post by soispoke on May 20, 2025\n\n soispoke\n\nProbably not the most interesting thing but just to make sure we’re on the same page, FOCIL is definitely not opt-in in its current form. You’d have to modify client code if you didn’t want to participate in building ILs according the inclusion rules chosen by clients\n\nOk I see, so only basic ´nonce´ and ´balance´ checks, and then if other more complicated interactions (e.g., an IL transaction is invalidated by another “balance emptying” transaction included by the block producer before in the payload) invalidate transactions they can still be included in ILs but if specific mempools are responsible for too many invalid txns they become blacklisted, got it!\nA few thoughts:\n\nI like the idea because of the flexibility it would give but asking each node to keep track of many different mempool and blacklist them sounds a bit messy and might open some attack vectors (wouldn’t an attacker be able to just spin up new mempools whenever one gets blacklisted?)\n\nOne thing that can help is to play around with mempool rules, like enforcing at most N pending full AA transaction per address (this is how we deal with 7702 txns atm) so we limit IL flooding.\n\nMaybe one thing to consider is how much of a spectrum would we really see between nodes. To me FOCIL nodes can:\n\nStore validity-only state and either:\n\nOptimistically include full AA txns in ILs\nDecide to include full AA txns only if they come with witnesses attached, or not to include full AA txns in their ILs at all\n\nStore the full state and include all txns valid against the pre-state\n\nThis leads to two small qs:\n\nIn case FOCIL nodes only store validity-only state and optimistically include full AA txns, how do we deal with attackers spamming all mempools at the same time (at no cost because these txns will be invalidated anyways), what are examples of custom validation rules that could help with this? Maybe more of a q for @yoavw here\nDo you think in practice we would see a lot of FOCIL nodes store validity-only state + some state related to specific applications they care about? Or is it more of a binary (validation-only or full state) thing?\n\nNote: If we use BALs with post-values txns + nonce and balance checks, attesters can perform static validation and vote for a block with full AA txns without having to wait for the full execution (h/t Francesco and Toni) so I think everything works out for attesters in any case, which is nice.\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n Load more posts below","tokens":4484,"squid":"ink-research","role":"Deep Scholar","at":1791261327313,"hash":"ed5dd45892b4ca67e42f7e9a73a7aaacd5002811"}
{"url":"https://ethereum.org/apps/aave/","domain":"ethereum.org","title":"Ethereum Apps - Aave | ⁦ethereum.org⁩","text":"DeFiAaveby AvaraEnglish Visit Aave (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextSky/Maker - USDSSee nextSky/Maker - USDSAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.InfoFounded2018CreatorAvaraLast updated459 days agoGalleryMore apps like thisDeFiSky/Maker - USDSSky.money is a non-custodial gateway to the decentralized Sky Protocol, which centers around the USDS stablecoin.Stablecoin issuance · RWA · Lending and borrowingDeFiSparkSpark Fi is a non-custodial DeFi protocol that allows users to lend and borrow digital assets through SparkLend, while earning passive income via the USDS stablecoin and its associated Sky Savings Rate.Lending and borrowing · RWADeFiMorphoMorpho is an open lending network with $14B+ in deposits connecting lenders and borrowers to the optimal opportunities worldwide. Its modular, open infrastructure enables fintechs, wallets, exchanges, and institutions to embed configurable credit products directly into their platforms, while maintaining full control over the user experience. Leaders like Coinbase, Robinhood, Bitwise Asset Management, and Société Générale already build on Morpho to deploy secure, scalable onchain credit products. Lending and borrowing","tokens":366,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261329945,"hash":"dd8c536b2c50f7e46126fcfa26d34c5b926681a5"}
{"url":"https://ethresear.ch/t/a-local-node-favoring-delta-to-the-scaling-roadmap/22368/39","domain":"ethresear.ch","title":"A local-node-favoring delta to the scaling roadmap - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 38 / 55\n\n May 2025\n\n Jun 2025\n\n Load more posts above\n\n post by MicahZoltu on May 19, 2025\n\n MicahZoltu\n\nWhat is being discussed here is RPC serving nodes, not staking nodes. You are correct that stakers can afford hardware, and they are a service provider being paid to do work so it is reasonable to require this of them. RPC serving nodes are end-users that may be poor, may have low end hardware, and likely aren’t going out of their way to build out Ethereum-only PCs/servers.\n\n post by vbuterin on May 20, 2025\n\n vbuterin\n\n MicahZoltu\n\n The idea would be that:\n\nFor data you want to read, you store and keep up-to-date only the state\nFor data you want to use in the validation section of a tx, you store and keep up-to-date the state and the sister nodes up to the root\n\n post by soispoke on May 20, 2025\n\n soispoke\n\nProbably not the most interesting thing but just to make sure we’re on the same page, FOCIL is definitely not opt-in in its current form. You’d have to modify client code if you didn’t want to participate in building ILs according the inclusion rules chosen by clients\n\nOk I see, so only basic ´nonce´ and ´balance´ checks, and then if other more complicated interactions (e.g., an IL transaction is invalidated by another “balance emptying” transaction included by the block producer before in the payload) invalidate transactions they can still be included in ILs but if specific mempools are responsible for too many invalid txns they become blacklisted, got it!\nA few thoughts:\n\nI like the idea because of the flexibility it would give but asking each node to keep track of many different mempool and blacklist them sounds a bit messy and might open some attack vectors (wouldn’t an attacker be able to just spin up new mempools whenever one gets blacklisted?)\n\nOne thing that can help is to play around with mempool rules, like enforcing at most N pending full AA transaction per address (this is how we deal with 7702 txns atm) so we limit IL flooding.\n\nMaybe one thing to consider is how much of a spectrum would we really see between nodes. To me FOCIL nodes can:\n\nStore validity-only state and either:\n\nOptimistically include full AA txns in ILs\nDecide to include full AA txns only if they come with witnesses attached, or not to include full AA txns in their ILs at all\n\nStore the full state and include all txns valid against the pre-state\n\nThis leads to two small qs:\n\nIn case FOCIL nodes only store validity-only state and optimistically include full AA txns, how do we deal with attackers spamming all mempools at the same time (at no cost because these txns will be invalidated anyways), what are examples of custom validation rules that could help with this? Maybe more of a q for @yoavw here\nDo you think in practice we would see a lot of FOCIL nodes store validity-only state + some state related to specific applications they care about? Or is it more of a binary (validation-only or full state) thing?\n\nNote: If we use BALs with post-values txns + nonce and balance checks, attesters can perform static validation and vote for a block with full AA txns without having to wait for the full execution (h/t Francesco and Toni) so I think everything works out for attesters in any case, which is nice.\n\n post by KolbyML on May 20, 2025\n\n KolbyML\n\nIsn’t this what Portal is doing. Except instead Portal is getting robustness through replications rather than erasure coding’s. Both have trade offs, but I think robustness through replications should be sufficiently durable as the number of replications would grow with the set of nodes participating and with the total storage being contributed.\nIs this bullet point suggesting a different storage solution should be built rather then Portal? What are priorities and trade offs desired in the target solution?\n\nThis ensures the property that “a blockchain is forever” without depending on centralized providers or putting heavy burdens on node operators\n\n^ Portal should be sufficient for these goals, which is why I ask.\n\n post by pipermerriam on May 20, 2025\n\n pipermerriam\n\n This somewhat echo’s what Kolby just stated.\nI believe that Portal solves all if not the vast majority of the stated goals and functionality outlined in this post. If this is a priority for Ethereum, we’re already on it and have solutions ready to go.\n\nPortal History network is already storing this information. We are generating ERA-style files for archival purposes of this data. Portal is ready as fast as EL clients are ready to drop this.\n\nPortal History network already provides a robust solution for this. It’s live and working.\n\nPortal State network is already underway in going live and is designed for lightweight personal nodes that have full RPC capabilities. The ability to have these clients verify blocks improves if the protocol is willing to upgrade to include commitments to things like witnesses or state diffs.\nState trie unification like is proposed in Verkle also improves things.\n\n post by peersky on May 20, 2025\n\n peersky\n\n MicahZoltu\n\n I might be totally off topic here, but as far as I understand, the motivation of this ongoing work is to enable more localised, decentralised ethereum network infrastructure as general challenge ecosystem faces.\nWhat stumbles me often in these EF discourses, is how much abstract, mathematical thinking is there as opposed to physical telecommunication real world.\nTCP networks do not look like “client ↔ server”. They look (very simplified) like this:\nThe-envisioned-communication-puzzle-of-4G_Q320320×320 21.6 KB\nIn initially linked articles network throughput is put under concern, however no analysis of what is physical topology demand is for such throughput.\nIt’s also claimed that\n\nHowever this problem statement does not include detail that indeed it is not the technical difficulty that faces bottleneck. It’s a financial incentive and return on investment difficulty to justify totally tangible and feasable technical requirements. Ethereum hardware requirements are not TON alike where you need a datacenter rack to launch a node.\nChallenges are in i) financial incentive of doing so (low APY plus increased broadband internet, static IP costs) ii) difficulty (cost) of obtaining static IP address from my ISP iii) lack of competitive market of ethereum node oriented hardware (dappNode with $2k cost bill is a lol).\nFurther, in local RPC serving nodes proposal here, assumption is that clients may want to store partial data. While I agree with that, If we take in context that we knowing how network topology of ISPs looks today:\nSP-topology-representation850×885 102 KB\nThen we are still missing this analysis of throughput demand. Is it really uniform (transactions happen with equal probability between two randomly picked end-clients)?\nI doubt it. I’d rather bet on that majority of settlements requiring high throughput are actually happening between local access points (end-users) doing their settlements.\nIf majority of traffic is localised then, candidates to run such “partial” clients are ISPs, last mile carriers, telecom companies who should be able to provide near instant settlement for transactions for network clients & contracts that are subset of their underlying client base and then slowly settle them to main ledger (and how it plays with rollup-centric stuff?).\nAnd that’s my point - they have no problems running 4TB SSD. They have static IP addresses already (!). They have specialised hardware companies and expertise that can enter market and create competitive hardware pricing.\nIn many aspects, last mile carriers are much better candidates to reinforce network decentralisation and localisation.\nThe problem is that they don’t see incentives in doing this.\nIf I’m running local node, there must be way of earn high yield on being able to settle end-user transactions quicker then others or for relaying that requested data to end user (and here partial state can be though as distribution network caching layer).\nThat gets me back to article on BFT-PoLoc paper I linked. If my local node can proof that it is able to do fastest settlement between two network clients, it should be able to take that opportunity at risk of already present stake it has.\nThen you get both win-win: network scales as crazy as that’s what users wants (instant secure and cheap settlements), and spatial decentralisation is achieved (data centers located remotely from user locations naturally cannot win settlement profits from ISPs or last mile carriers if market is latency based).\n\n Federated Multi-Model AI Deliberation Without Tensor Parallelism\n\n post by peersky on May 20, 2025\n\n peersky\n\nin context of EIP-4444 I suggest also adding\n\nEvent logs chosen to be stored by the operator, plus an option to store them as indexed, fast retrieval objects (potentially removes the need to host separate indexer clients)\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\n“Settlement” on Ethereum is between users and block builders. For each block, there are users all over the world submitting transactions, and a single builder somewhere in the world that is building the block. Once that block is built, it needs to be propagated to every node on the network.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nDo you have more details on this? My understanding was that portal was going to provide a network wide state storage system, but it wasn’t going to do anything to try to ensure individual nodes had all of the state they would ever want to reference locally. I thought the design was to ensure state was well distributed over the network with sufficient replication, not optimized for local access needs?\n\n post by pipermerriam on May 21, 2025\n\n pipermerriam\n\nWhen you say “optimized for local access needs”, I assume this means having the data locally, available for reading without having to do higher latency lookups over the network.\nOur network design is able to support this use case. Preliminary spec is available here. The rough concept is that we’ll be pushing state diffs into the network at every block. Anyone who wants to keep some slice of the state up-to-date can use the diffs to continually update their local cache/copy.\nMaybe a more appropriate statement here would be: The Portal teams are already working on clients that are trying to accomplish a set of goals that look very similar to what is outlined int his post… these are probably the droids you are looking for. It seems we may already be building the solution described in this thread.\n\n post by MicahZoltu on May 21, 2025\n\n MicahZoltu\n\nI agree that Portal is building a part of the thing described here, and I try to bring up that fact at every opportunity. I don’t think it is the full story though, as for true local-node-priority we need them to be trustless, which means getting state diffs proven with each block and part of consensus.\n\nDo you have any data on the overhead required to participate in the portal network? The 80GB flat-db state for all current state is currently achievable only by dropping the entire MPT datastructure, which I think cuts the disk requirement in half or more, plus makes pruning much easier. If a user stores say 10GB of state (in a flat DB, no MPT) they care about and wants to share access to that with the portal network, how much metadata will they need on disk to achieve that?\n\n post by SCBuergel on May 22, 2025\n\n SCBuergel\n\n MicahZoltu\n\nThese reduced-state nodes would only need to fetch extra data from somewhere when they find they are missing state they need (hopefully a rare occurrence).\n\nBut do reduced-state nodes participate in broadcasting of block / tx data so that they would mostly have this data in the first place? If yes, then I’d consider that a significant bandwidth overhead which would certainly prevent the typical wallet to actually run such a service (hence my question on how this is envisioned to be rolled out practically) and thus stand in the way of a maximally decentralized Ethereum. If no, then these massive number of nodes still creates a massive bandwidth and connection overhead for existing full nodes (full in the sense of having all state and broadcasting).\nSo bottom line I see no way around actually thinking about what @vbuterin wrote above\n\nwe eventually would benefit a lot from getting comfortable with paying nodes for services via a standardized (and anonymized) market.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nAh, I see what you are asking about now. I would hope that the light nodes are able to help with some amount of propagation. Perhaps they could propagate headers and state diffs, but not bodies. If we have proven blocks, these nodes also wouldn’t need the bodies (just headers and state diffs), so in theory they would contribute about as much as they consumed.\nOf course, how this all works out in the end definitely is dependent on what technology we actually manage to develop (realistic block proving is still a long way off). In general, I am also not terribly against an anonymized data market, especially if we can utilize payment channels so if it costs $0.00001 per block or something (which I would imagine would cover the bandwidth costs?), then users could pay $2/month to stay synced. Maybe less depending on what the costs actually end up being and how competitive the market is.\n\n post by pipermerriam on May 22, 2025\n\n pipermerriam\n\nI think this would work well with in-protocol block witnesses or state diffs.\nPortal becomes the backbone for bootstrapping new nodes or nodes that have been offline for a period. Full availability of any portion of the state that a node wants to pull into their local copy.\nKeeping this data up-to-date can be done with witness based block execution or just by applying the portion of the state diff that applies to their local state.\nAnd contributing back to Portal doesn’t need to be a function of the size of the local state data held by the node. A node could have 80GB of state data that it keeps locally and only choose to offer 1GB of storage back to portal. This is the part about Portal that is maybe conceptually important. Nodes don’t get to choose what data they store for the network. This is fundamental in the design of the network to ensure that data is evenly replicated and that even unpopular data remains available. Any design that is based on nodes choosing what data they store and offer the network is going to have trouble making the unpopular data readily available on the network. So the 1GB of storage offered to Portal in this example would likely be mostly disparate data from other 80GB.\n\n post by MicahZoltu on May 22, 2025\n\n MicahZoltu\n\nIs there any deduplication that can occur here? If all state is 100GB and the user is storing 50GB for their own use, and their randomly assigned slice of state is 10GB, then ~5GB of their randomly assigned state is state that they have chosen to keep local for personal reasons. Will the user need to store ~60GB or ~55GB in this scenario?\n\n post by pipermerriam on May 23, 2025\n\n pipermerriam\n\nYes, this data can be de duplicated if the client developers choose to do so in their implementation.\n\n post by Olshansky on May 24, 2025\n\n Olshansky\n\n tl;dr In addition (AND not OR) to solving the full node problem, I wanted to shed light on GATE: Gateway Abstraction Technical Elements. I did a full presentation on it at the 1kx summit\n\nIt’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way.**\n\nThis is theoretically true.\nPractically (unfortunately?) I do not believe RPC is going away.\nThis extends beyond Ethereum nodes to any open canonical dataset/service; Tor relayers, OpenStreeMapsData, LLMs, etc…\n\nIf I get a few here, I’m happy to share a thread of how we’re thinking about it. I want to avoid highjacking this thread and avoid any biases that relate to our project/company.\nThe high level technical approach is:\n\nPermissionless directory of endpoints\n\nVerifiable API counter (probabilistic)\n\nOptimistic rate limiter (with crypto-economic incentives)\n\nSmart Quality-of-Service SDK\n\nDelegated trust\n\nBorrows ideas from Grant Negotiation & Authorization Protocol; an IETF standard;\n\nScreenshot 2025-05-24 at 4.36.07 PM1645×1055 57.9 KB\n\n post by kladkogex on May 26, 2025\n\n kladkogex\n\n Well - this is a classic example of solving a problem that users don’t actually ask to solve.\nEthereum today is a somewhat-decentralized network, with a Nakamoto coefficient of around 3.\nMost users are perfectly fine with this level of decentralization. In fact, they dont care about rollups being 100% centralized.\nWhat Vitalik is missing in his line of thought, is why suddenly decentralization is important in the particular case that he is considering and totally unimportant in other cases.\n\n post by MicahZoltu on May 27, 2025\n\n MicahZoltu\n\n“Most users” are perfectly fine with a 100% centralized censorious financial system, as long as they are not the ones being censored. IMO, Ethereum should be filling the currently unfulfilled niche of censorship resistant finance, not trying to compete with censorable systems.\n\nWhat cases do you think should take priority over ensuring that users can operate the software in a sovereign way?\n\n post by peersky on May 27, 2025\n\n peersky\n\nProduct of Ethereum is not settling with some abstract block builders. It’s infrastructure service that allows to settle deals between entities or groups of such, where settlement between two end-users is a distinct use case.\nAll I’m saying is that while decentralised storage solution and stateless verifications are great, from what I can see today - it seems premature.\nWhile it is it’s valuable to have a full node so that you can have a local RPC server that you can use to read the chain in a trustless, censorship-resistant and privacy-friendly way, the proposed roadmap will not solve problems of end-users not able to run p2p nodes due to fact that most end-users are behind CGNATs.\nThis fact implies that it still would require local users to set up a server, call their provider and arrange CGNATs configuration.\nHence, in anyway the “localism” adaption and degree of possible decentralisation achieved will be limited by the last mile carrier internet providers.\nThis brings to question whether such participants, operating telecom equipment and often a server rack or two, are concerned by (What are estimated HW requirements?)\n\nOr do they have another concerns why they refuse today to run (at scale) Ethereum infrastructure on their premises?\nIn my humble view, Ethereum needs more research thinking in telecommunication network level and close intermediate gaps by getting incentives right for internet operators (local node ROI, EIPs to advertise RPC serving capacity/endpoints) , that will create incremental local-node favoring delta by moving out cloud resourced on to the edges AND will produce demand for decentralised storage and partial state etc etc.\n\n Load more posts below","tokens":4786,"squid":"ink-research","role":"Deep Scholar","at":1791261337578,"hash":"a77cd0b261895ffcda4561a8185284b8d9bf0ca6"}
{"url":"https://governance.aave.com/t/coinbase-b20-equities-on-base-assessments/25690/1","domain":"governance.aave.com","title":"Coinbase B20 Equities on Base Assessments - Risk / Assessments - Aave","text":"Coinbase B20 Equities on Base Assessments \n\n RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 24\n\n 1 / 2\n\n Sep 23\n\n 12d ago\n\n post by LlamaRisk on Sep 24\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of Coinbase B20 tokenized equities on Aave V4 Base.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 22\n min\n\n post by LlamaRisk on Sep 24\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nThis document is the technical review behind the initial parameters proposed for the tokenized equities market on Aave V4 Base. It covers the legal structure of the certificates, the issuance and redemption mechanics, the token standard and the issuer’s onchain contracts, the handling of corporate actions, and the behaviour of the price feed.\nThe market initially lists the Magnificent Seven US technology stocks in their Coinbase B20 form (AAPLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc, and TSLAc) as collateral in a dedicated Equities Hub, with USDC as the only borrowable asset. Each token is a certificate over shares held in segregated custody under a bare trust governed by ADGM law, offered under a public prospectus approved by the ADGM Financial Services Regulatory Authority. Holders who acquire the tokens on the secondary market hold them as unvested holders with economic exposure but no redemption right until they complete the issuer’s vesting process.\n1. Legal Structure\n\nExpand the legal structure review (sections 1.1 to 1.7)\nThe review is based on the prospectus, the terms and conditions and the deed of trust of the NVIDIA certificates. The seven tokens are issued under the same programme by the same issuer, and the analysis applies to each of them.\n1.1 Jurisdictional Compliance\nThe offering document is a public prospectus, approved by the FSRA on 4 August 2026 (the “Prospectus”) “under section 61(2) of FSMR and section 4.6.2 of the Market Rules” (Prospectus, cover, p. 1), and valid until 3 August 2027 — after which continued primary issuance requires renewal — and obliges the Issuer to publish an FSRA-approved supplement on any significant change or material mistake (Prospectus, Validity of Prospectus, p. 2). The Issuer and both Directors accept responsibility for its contents without qualification (Prospectus, §1.1, p. 20). These are favourable features, though approval is not endorsement: the ADGM “does not accept any responsibility for the content” (Prospectus, cover, p. 1).\nThe Prospectus itself settles the classification of the vested instrument: the Securities “constitute ‘Certificates representing certain Financial Instruments’” under paragraph 92 of Schedule 1 of FSMR and are deemed securities by the FSRA “pursuant to a written determination under section 58(2)(b) of FSMR” (Prospectus, Summary C, p. 14; §13, p. 68).\nThe unvested position carries a second, distinct classification: Unvested Securities “constitute ‘Rights to or interests in investments’” under paragraph 98 of Schedule 1 and “are also deemed to be ‘securities’” (Prospectus, §13, p. 68). The Coinbase DDQ response asserts the opposite — that this category “is not itself listed as a Security type” so no prospectus obligation arises (Coinbase DDQ response, Q3). The same DDQ response inverts the Prospectus on the on-chain token: the Prospectus states the tokens “do not constitute separate securities or independent financial instruments” (Prospectus, §12.8(b), p. 59); the DDQ response asserts “the on-chain token itself is a separate security / independent financial instrument” (Coinbase DDQ response, Q8). The token-status consequences are treated in the title and transfer-restriction sections of this examination.\nThe Issuer’s follow-up response confirms that Securities held by an Unvested Holder “constitute ‘Rights to or interests in investments’” — adopting the Prospectus’s paragraph 98 classification and, in substance, withdrawing the earlier Q3 analysis (Coinbase DDQ response (2), item 1).\nThe regulatory perimeter covers the offering and one service provider, not the Issuer. Nowhere is Coinbase Onchain SPV Ltd described as licensed, authorised or exempt; it is an SPV with no employees whose only activity is issuing Digital Securities (Prospectus, §3.2, p. 21). The Coinbase DDQ response calls it an “Unregulated SPV” (Coinbase DDQ response, Q2).\nThe single regulated ADGM node is Onchain Marketplace Ltd, “authorised by the FSRA to carry on the regulated activities of Arranging Deals in Investments and Providing Custody (restricted to operating a Central Securities Depositary)” (Prospectus, §3.5(b)(i), p. 22), which operates the Relevant System and is the declared Reporting Entity. Favourably, the definitive record of legal title sits inside an FSRA-supervised depositary subject to intraday reconciliation consistent with COBS 10.3.3 (Prospectus, §12.8(c), p. 60); but the permission is narrow, Onchain Marketplace Ltd does not custody the underlying shares. At the asset layer, Alpaca Securities LLC “is an SEC-registered broker-dealer and a member of FINRA and the SIPC” (Prospectus, §3.5(b)(ii), p. 22), contractually bound to remain so (Prospectus, §10(ii), p. 51), and the Issuer’s right to demand return of the shares is “an absolute right preserved under SEC Rule 15c3-3” (Prospectus, §4.5(d), p. 36). Pass-through SIPC protection for Holders in an Alpaca insolvency is expressly uncertain: “neither SIPC’s rules nor its published guidance directly address this novel custody structure” (Prospectus, §4.7(d), p. 41).\nThe Securities are not, and are not expected to be, admitted to trading on any exchange or trading facility anywhere (Prospectus, §13.1, p. 69); they are “solely transferable and traded through DeFi Markets,” which “are not currently regulated in the ADGM” (Prospectus, Summary C, p. 16); and secondary trading “does not constitute participation in the Offer and is not subject to the Offer perimeter” (Prospectus, §4.7(b), p. 39). The Issuer “has not entered into any formal market making or liquidity provider arrangement” and takes no responsibility for one (Prospectus, §13.2(a), p. 70); there is no stabilisation (Prospectus, §13.3, p. 70); and Holders “may have no legal remedies or practical recourse” against market interference (Prospectus, §4.2(f), p. 27).\nThe Securities are unregistered under the U.S. Securities Act, and the prohibition is absolute and perpetual: they may not be acquired, held, sold, transferred or delivered, directly or indirectly, in the United States “or to, or for the account or benefit of, any ‘U.S. Person’”, and all secondary dealings must occur “in offshore transactions in reliance on Regulation S” (Prospectus, §14.1(a), p. 72). Every acquirer is deemed to represent that it is not a U.S. Person, is outside the United States, and is not acquiring for one; the Deed of Trust dated 4 August 2026 (the “Deed of Trust”) recites the same reliance (Deed of Trust, recital (B), p. 103). Unexplained, the cover applies two different tests — Regulation S “U.S. Persons” for the offer, but CFTC-defined “Non-U.S. Persons” for onward delivery (Prospectus, cover, p. 1).\nEnforcement rests on restrictions “embedded in the Security’s smart contract” and binding on all transferees (Prospectus, §4.4(b), p. 31), on blockchain analytics, and on the freeze power — and the Prospectus concedes their limits: “Notwithstanding these restrictions, a Security could be transferred on a peer-to-peer basis or through DeFi Markets” to prohibited persons (Prospectus, §4.7(b), p. 39).\nThe primary offer is made in the ADGM exclusively to Authorised Participants, each a Professional Client under COBS 2.4 or a Market Counterparty under COBS 2.5, approved by the Issuer in its absolute discretion (Prospectus, Summary D, p. 17); in the secondary market, Authorised Participants “may make Securities available in DeFi Markets, including to retail investors” (Prospectus, §13.1, p. 69). Every secondary acquirer takes as an Unvested Holder with no redemption, voting or information rights — “The Issuer will not recognise any Holder as having any rights whatsoever” until vesting (Prospectus, p. 3) — and vesting is determined by the Tokenisation Entity on the Issuer’s behalf, final and binding absent manifest error, and revocable at any time (Terms and Conditions, Condition 2.4(c) and 2.4(e), pp. 81–82). Every liquidation counterparty will therefore stand, on acquisition, in the weakest class the structure recognises; exit runs through a discretionary compliance gate with no committed timeline anywhere in the reviewed material. We take no view on whether any particular holder would satisfy the Vesting Conditions.\nThe Issuer’s follow-up response adds the practical record: no liquidator, enforcement agent or lending protocol’s liquidation contract “has not yet been permitted to Vest” [sic]; expected processing time is described as “short”, with no service standard or outer time limit committed; onboarding discretion is expressly retained; and the Issuer offers to “discuss the process of potentially onboarding … liquidation contract” or partnering with an existing Authorised Participant for that purpose (Coinbase DDQ response (2), item 2).\nThe offer exists only in the ADGM: “no action has been or will be taken by the Issuer that would permit a public offering” anywhere else (Prospectus, §14.1, p. 71); every acquisition must comply with local law without imposing any obligation on the Issuer; and the Issuer reserves an unbounded right “to impose additional restrictions” by jurisdiction, person, wallet, venue or settlement system (Prospectus, §14.1(d), pp. 72–73). Transfers to jurisdictions where the offer was never made “could result in the Securities being frozen at the smart contract level” (Prospectus, Summary C, p. 17). No country-by-country selling restriction schedule exists, and no analysis addresses the lawfulness of holding the token in the European Union, the United Kingdom or elsewhere.\n1.2 Bankruptcy Remoteness\nThe separation architecture rests on a single instrument, the Deed Poll and Declaration of Trust dated 4 August 2026, published in full as Annex 2 to the Prospectus and executed by the Issuer as Trustee “IN FAVOUR OF: THE REGISTERED OWNERS AND UNVESTED HOLDERS” (Deed of Trust, preamble, p. 103). It declares two trusts. First, the Trustee “holds all Deposited Property on trust as bare trustee” for the Registered Owners from time to time (Deed of Trust, cl. 3.1, p. 104), the Deposited Property capturing the NVIDIA shares and everything received in respect of them (Deed of Trust, cl. 1.1, pp. 103–104). Second, where the Trustee is itself registered as owner of Unvested Securities, it holds “the legal title and all Beneficial Interests attaching” to them as bare trustee for the Unvested Holders (Deed of Trust, cl. 4, p. 105). Each Beneficial Interest is “a pro rata equitable interest in the Deposited Property as a whole” (Deed of Trust, cl. 1.1, p. 103).\nThe Deed is governed by ADGM law with exclusive ADGM jurisdiction (Deed of Trust, cll. 15–16, p. 107); as a deed poll, each beneficiary “may severally enforce the obligations of the Trustee” directly (Deed of Trust, cl. 11.2, p. 106), and the trust and segregation “continue throughout any such redemption, termination or wind-down” (Deed of Trust, cl. 14.3, p. 107).\nThe Deposited Property “shall be segregated from, and shall not form part of, the proprietary assets of the Trustee” (Deed of Trust, cl. 3.5, p. 105), and the custodian, Alpaca Securities LLC, must hold it on trust for the Trustee, identified in its books, segregated from Alpaca’s own assets “and, so far as practicable, from the assets of the Custodian’s other clients” (Deed of Trust, cl. 9.2, p. 106). Per the Prospectus’s summary of the Institutional Account Agreement, the custodian “is not permitted to engage in any securities lending”, “shall have no right to assert any applicable rights of lien”, and deposits “will not expire in the event of loss of capacity to act or bankruptcy” of the Issuer (Prospectus, §10(ii), p. 51). The custody accounts stand in the Issuer’s own name, and the Issuer’s right to demand return of the shares is “an absolute right preserved under SEC Rule 15c3-3” (Prospectus, §4.5(d), p. 36).\nUnder the Deed, all claims of Registered Owners and Unvested Holders “under this Deed, however arising, are limited in recourse” to the Deposited Property and its proceeds; no claim lies against the Trustee’s other assets, and once the property is realised and applied, “any outstanding claim of a Registered Owner or Unvested Holder shall be extinguished” (Deed of Trust, cl. 12.2, p. 106). The Prospectus asserts the proposition more broadly: “The Issuer’s obligations to Holders are limited recourse” (Prospectus, §6.3(d), p. 47).\nThe bankruptcy statement is expressly conditional: “subject to the validity of the bare trust arrangements”, the Deposited Property and Unvested Securities will not form part of the Issuer’s assets in an insolvency, and Registered Owners and Unvested Holders “are not creditors of the Issuer” in the ordinary course (Prospectus, §16.6, p. 77). The risk factors concede the central vulnerability in terms: creditors “may apply to a court to challenge or set aside the trust structures”, and proceedings may leave the property “being frozen” with delayed redemptions (Prospectus, §4.7(a), p. 39; Summary, p. 17).\n1.3 Title and Ownership\nTitle runs through five links across three legal systems. First, NVIDIA common stock is held by Alpaca Securities LLC in “segregated Custody Accounts in the Issuer’s name” (Prospectus, §4.5(d), p. 36); the Issuer “holds a beneficial interest in the Underlying” through the custodian (Prospectus, §12.10(b), p. 63) — in United States terms an account holder with an intermediated claim, not the shareholder of record. Second, the Issuer holds all Deposited Property as bare trustee for the Registered Owners under ADGM law (Deed of Trust, cl. 3.1, p. 104). Third, legal title to each Security belongs to its Registered Owner, “the person in whose name legal title” is registered in the Legal Register (Terms and Conditions, Condition 23.1, p. 99). Fourth, for every Security whose holder has not passed vesting, the Registered Owner is the Issuer itself, holding on a second bare trust for the Unvested Holders (Prospectus, §12.8(c), p. 59; Deed of Trust, cl. 4, p. 105). Fifth stands the Holder, defined purely operationally as “the person controlling the Wallet” in which the tokens sit (Terms and Conditions, Condition 23.1, p. 98).\nThe structure’s central design choice is that the token is not the record of ownership. “Legal title to the Securities shall be recorded exclusively by registration in the Legal Register” (Terms and Conditions, Condition 2.2, p. 80); the Legal Register is “the definitive and exclusive record of legal title” (Prospectus, §12.8(c), p. 59). Dealings on any blockchain, wallet or smart contract “shall not create, transfer, evidence, or extinguish legal title” except as reflected in the register, and wherever the two records diverge, “the Legal Register shall prevail” (Terms and Conditions, Condition 2.2, p. 80) — even mid-investigation: “Pending resolution, the Legal Register prevails” (Prospectus, §12.8(c), p. 60). Token possession passes on-chain; legal title passes “solely upon registration in the Legal Register” (Terms and Conditions, Condition 3.2, p. 82). When possession and register entry diverge — hack, erroneous transfer, register error, contested liquidation — the wallet-side party loses on the face of these provisions; the Tokenisation Entity may rescind transfers, cancel Securities, demote vested holders or freeze positions, “in each case with or without payment” (Prospectus, §14.2(a), p. 73).\nThe reconciliation between the two records is disclosed only as a fact: the Tokenisation Entity “carries out intraday reconciliation procedures in its capacity as CSD” (Prospectus, §12.8(b), p. 59). The Prospectus itself concedes that the Legal Register “does not benefit from the transparency and real-time verifiability” of a public blockchain (Prospectus, §4.5(e), p. 36).\nOnly Vested Holders — those who have satisfied the Vesting Conditions “as determined by the Tokenisation Entity” (Terms and Conditions, Condition 23.1, p. 100) — may exercise rights attaching to the Securities (Terms and Conditions, Condition 2.4(a), p. 80). “Unvested Holders shall not be entitled to redeem Securities or withdraw Underlying” (Terms and Conditions, Condition 5.1, p. 85); the unvested claim “is limited to a right to become the Registered Owner” upon vesting (Prospectus, §12.8(d), p. 61), alongside possession, transfer and economic exposure. The Vesting Conditions comprise compliance, wallet-control, bank-account and sanctions requirements, plus “such other conditions as may be specified” from time to time — an open-ended list, whose satisfaction is determined with finality binding “on the relevant Holder and all other persons” absent manifest error (Terms and Conditions, Condition 2.4(c), p. 81). Vested status is revocable at any time in the Issuer’s or the Tokenisation Entity’s sole discretion, on triggers including a wallet merely coming under governmental investigation (Terms and Conditions, Condition 2.4(e), p. 82), and transfer to a non-vested transferee automatically demotes the Security (Terms and Conditions, Condition 3.3, p. 83). Anyone acquiring in secondary markets takes as an Unvested Holder unless and until it satisfies the Vesting Conditions (Prospectus, §13.1, p. 68).\n1.4 Issuer Structure\nCoinbase Onchain SPV Ltd is a private company limited by shares incorporated in the ADGM on 17 June 2026, wholly owned by Onchain Marketplace Holdings Limited and ultimately by Coinbase Global, Inc. (Prospectus, Summary B, p. 12).\nThe board comprises two directors, Jordan Fish and John D’Agostino, both senior Coinbase executives and both holding offices at the very service provider the board exists to oversee: Mr Fish is a director of Onchain Marketplace Ltd; Mr D’Agostino is a director of Onchain Marketplace Holdings Limited and of Onchain Marketplace Ltd and “performs the controlled function of Senior Executive Officer” for the latter (Prospectus, §7.3, p. 48). While “all material decision-making is reserved to the Issuer’s Board of Directors” (Prospectus, §4.5(b), p. 35), the Issuer has no employees and every operation is executed by Onchain Marketplace Ltd — so every discretion exercised “on behalf of the Issuer” is, in personnel terms, an internal Coinbase Group decision.\nThe operation runs on four material contracts summarised in the Prospectus. Under the Tokenisation Services Agreement, effective 1 July 2026, Onchain Marketplace Ltd mints, delivers and burns the Securities, deploys and audits the smart contracts, operates the Relevant System, maintains the Legal Register and verifies Vesting Conditions (Prospectus, §12.10(d), p. 64). Its liability, absent gross negligence, fraud or wilful misconduct, “will not exceed the fees paid to the Tokenisation Entity” to the date of the claim (Prospectus, §10(i), pp. 50–51). The dependency is total: on a failure of the Tokenisation Entity, “the Issuer would immediately lose the ability to process any minting, redemption, transfer control, corporate action, or Deposit Ratio adjustment,” with “no alternative means of performing these functions,” and the offer “would be operationally suspended” pending replacement (Prospectus, §4.5(b), p. 35).\nThe Institutional Account Agreement with Alpaca, dated 30 July 2026 and governed by New York law, contains genuinely strong custody protections as summarised: segregated accounts, no securities lending or proprietary use, no “rights of lien, retention, or other rights to retain” the Deposited Property, and deposits that “will not expire in the event of … bankruptcy on the part of the Issuer” (Prospectus, §10(ii), p. 51); the Deed of Trust requires segregation from the Custodian’s own assets and, “so far as practicable,” from other clients’ assets (Deed of Trust, cl. 9.2, p. 106). Against that, the Custodian’s liability is “limited to a contractually specified amount” that is undisclosed, either party may terminate on written notice of unspecified length (Prospectus, §10(ii), p. 51), and replacement “could take several weeks or longer” (Prospectus, §4.5(d), p. 36). The General Services Agreement with Coinbase Global, Inc., effective 1 July 2026 and governed by California law, supplies finance, legal, compliance and technology support at an undisclosed arm’s-length fee, terminable on notice of unspecified length (Prospectus, §10(iii), pp. 51–52). The Issuer may replace any service provider — and even substitute a new issuer in its own place, subject to conditions including assumption of the trusteeship — without Holder consent (Terms and Conditions, Conditions 18 and 19, p. 96).\nDeloitte & Touche (M.E.) LLP is the appointed ADGM-registered auditor. No audited financial statements yet exist for any period (Prospectus, §8.1, p. 48); the only financial statement is the unaudited day-one balance sheet, predating all four material contracts; and “the Prospectus has not been audited or reviewed by the Auditors” (Prospectus, §9.1, p. 49). No reserve attestation or systems assurance report is referenced in the Prospectus, and the Coinbase DDQ response confirms none exists yet (Coinbase DDQ response, Q14).\n1.5 Subscriptions, Withdrawals and Redemption\nSecurities enter circulation through one channel only: creation by Authorised Participants “is the sole means through which Securities may come into circulation” (Prospectus, §12.8(e), p. 62). An Authorised Participant must be a Professional Client or Market Counterparty, “approved and engaged by the Issuer (in its absolute sole discretion)” (Prospectus, §13.2(a), p. 70), under an Authorised Participant Agreement which is not published — confidential, per an unverified issuer statement (Coinbase DDQ response, Q1). The creation fee is one basis point of the invested amount (Prospectus, §12.11(i), p. 66).\nThe creation is suspendable and cappable: the Issuer may suspend or refuse issuance generally or in particular instances (Terms and Conditions, Condition 2.3, p. 81), and “the Tokenisation Entity may limit the number of Securities that can be created in a 24-hour period” (Prospectus, §13.1, p. 69). Further, the Issuer “has not entered into any formal market making or liquidity provider arrangement” with any Authorised Participant (Prospectus, §13.2(a), p. 70), no price stabilisation will occur (Prospectus, §13.3, p. 70), and divergence between the trading price and the Underlying “may be significant” (Prospectus, §4.2(c), p. 25).\nThe redemption right belongs to Vested Holders alone, and the exclusion of everyone else is express and double-barrelled: “Unvested Holders shall not be entitled to redeem Securities or withdraw Underlying” (Terms and Conditions, Condition 5.1, p. 85). Vested status is determined by the Tokenisation Entity on the Issuer’s behalf, and that determination is, “in the absence of manifest error, … final and binding” on the holder and all other persons (Condition 2.4(c), p. 81). The Prospectus itself contemplates that the exclusion can become permanent: “the corresponding Underlying … may remain permanently held by the Issuer” (Prospectus, §4.4(e), p. 32), and “a partial or total loss of invested capital is possible” through vesting failure (Prospectus, §4.4(c), p. 31).\nA redeeming Vested Holder submits a Redemption Order “in such form and manner as the Tokenisation Entity may prescribe from time to time” (Terms and Conditions, Condition 5.2, p. 85). The prescribed form, the operational timetable and any settlement deadline appear nowhere in the Prospectus, the Terms and Conditions or the Deed of Trust; the procedures may be “otherwise determined by the Issuer or the Tokenisation Entity in their sole and absolute discretion” (Prospectus, §12.8(e), p. 62).\nBefore acceptance, the Tokenisation Entity, the Custodian or any relevant service provider may re-run any validation — expressly including re-verification of the Vesting Conditions “whether or not previously satisfied” — and may “reject, suspend, delay, or conditionally accept any Redemption Order” (Terms and Conditions, Condition 5.4, pp. 86–87). After acceptance a broader power applies: “Notwithstanding acceptance of a Redemption Order”, the Issuer, the Custodian or the Tokenisation Entity may suspend, delay or modify settlement inconsistent with Applicable Law, sanctions requirements, custody requirements, “market conditions”, settlement restrictions, or operational requirements of the Relevant System (Condition 5.4, p. 87). Neither stage carries a duration limit.\nThe settlement election belongs, in the first instance, to the redeeming Vested Holder, who may choose among in-kind transfer of the Underlying to a nominated custody or brokerage account, sale for US dollars to a nominated bank account, or sale and conversion into “USDC or such other stablecoin as may be accepted” delivered to a nominated Wallet (Terms and Conditions, Condition 5.3, p. 86). The redemption fee is five basis points of the redemption amount (Prospectus, §12.11(ii), p. 66).\n1.6 Investment Programme, Yield and Distribution\nThe Issuer applies creation proceeds “solely to acquire the corresponding Underlying” and “does not retain the subscription proceeds for its own account” (Prospectus, §11, p. 53). There is no investment mandate, no leverage against the Deposited Property and no rehypothecation: the Custodian “is not permitted to engage in any securities lending or other proprietary transactions” affecting the Deposited Property and has “no right to assert any applicable rights of lien” or retention over it (Prospectus, §10(ii), p. 51).\nEach Security is backed by NVIDIA common stock through the Deposit Ratio — the number of Underlying represented by one Security, “as determined and adjusted by the Issuer” (Terms and Conditions, Condition 23.1, p. 98). The Prospectus elsewhere states that costs are funded through fees and the affiliate loan facility (Prospectus, §11, p. 53), which cuts against routine downward adjustment, but nothing in the Conditions confines the power.\nHolders never receive cash. Condition 6 operates “in lieu of making any distribution of cash to Holders”: cash distributions received on the Underlying are applied, net of the Issuer’s fees and withheld taxes, to purchase additional Underlying, reflected as an upward adjustment to the Deposit Ratio (Terms and Conditions, Condition 6(i), p. 87). Distributions of shares are retained; other property is sold and reinvested, or retained; subscription rights may be exercised, sold, or permitted to lapse in the Issuer’s discretion; and under the compliance limb the Issuer may hold amounts “uninvested and without liability for interest” (Condition 6(ii)–(v), pp. 87–88). The Securities do not bear interest (Prospectus, §12.1, p. 54).\nThe distribution fee is “5.0% of the gross aggregate value” of any dividends, computed “before any withholding, deductions, or reinvestment” (Prospectus, §12.11(iv), p. 66); United States withholding is “currently 30% for non-U.S. Holders (unless reduced by applicable treaty)” (Prospectus, §12.11(iii), p. 66).\nCorporate actions vest wide reshaping powers in the Issuer. An Adjustment Event extends to “any other event” affecting the Underlying, the Underlying Issuer or the Deposited Property “that, in the opinion of the Issuer, requires an adjustment” (Terms and Conditions, Condition 4.2(a), p. 84). On such an event the Issuer may exchange or surrender the Underlying for other shares, securities, cash or property; may in its sole discretion “call for surrender of the Securities in exchange” — against payment of the Issuer’s fees and expenses — for new Securities describing the substituted Underlying; and, on a partial redemption of the Underlying, selects which Holders are redeemed “in such manner as it shall determine” (Condition 4.2(e), p. 85). A delisting of NVIDIA without immediate re-listing feeds into a sole-discretion termination (Condition 4.2(b), p. 84); Holder consent is expressly not required and a failure of notice does not invalidate an adjustment (Condition 4.2(d), p. 85).\n1.7 Transfer Restriction Enforcement and the Secondary Market\nA transferee who satisfies the Vesting Conditions at the time of transfer takes Vested Securities and is registered. Where the transferee does not, “the relevant Securities shall automatically be redesignated as Unvested Securities and legal title thereto shall be held by the Trustee” on trust for the transferee (Terms and Conditions, Condition 3.3(ii), p. 83). This is the ordinary design of the whole secondary market: persons other than Authorised Participants acquire only through secondary transactions “and will hold them as Unvested Holders unless and until they satisfy the Vesting Conditions” (Prospectus, §13, p. 68). A liquidator seizing the token therefore holds, at that moment, an unvested position — no redemption right, no entitlement to termination proceeds, no registered legal title — with a route to vesting that is discretionary.\nAsked how a secured creditor would enforce in practice, the Issuer elaborates: enforcement “will ultimately depend on the type of security interest”; a creditor with a direct right of appropriation — under a financial collateral arrangement, foreclosure under a mortgage, or conversion of a charge into an equitable mortgage — “would likely enforce directly against the debtor”, and otherwise “via application to the court for appointment of a receiver”; the appropriator declares the appropriation to the trustee, which “will update its records”, and “take[s] the equitable interest without procuring a transfer of the legal interest”, on the footing that “the normal principles of derivative transfer of title apply” to Unvested Securities; a transfer of legal title still requires onboarding as a Vested Holder; and the Tokenisation Entity may freeze, pause, rescind or cancel Securities “to give effect to the order of a court or authority recognised in the ADGM” (Coinbase DDQ response (2), item 3).\nThe unvested position is not a nullity: it expressly includes “a beneficial interest in such Securities” and “a right to possess, transfer, and benefit from economic exposure to the Underlying” (Terms and Conditions, Condition 2.4(d), p. 81). That interest is protected by an express trust — the Trustee holds “the legal title and all Beneficial Interests” as bare trustee for Unvested Holders (Deed of Trust, cl. 4, p. 105), the Deed takes effect as a deed poll in their favour, and each Unvested Holder “may severally enforce the obligations of the Trustee owed to them” (Deed of Trust, cl. 11.2, p. 106). An unvested token thus remains a possessable, transferable instrument carrying trust-protected exposure to NVIDIA stock.\nThe Prospectus and the Conditions do not describe the unvested position identically, and the divergence should be recorded rather than smoothed over. The Conditions grant a right “to possess, transfer, and benefit from economic exposure” (Condition 2.4(d)(ii), p. 81); the Prospectus body states that “the claim of any Unvested Holder is limited to a right to become the Registered Owner thereof” (Prospectus, §12.8(d), p. 61).\nThe Issuer’s follow-up response restates the register and vesting mechanics without choosing between the two formulations (Coinbase DDQ response (2), item 4). Its enforcement answer, however, proceeds on the footing that the unvested position is a present equitable interest capable of transfer and appropriation — the reading the Conditions and clause 4 of the Deed of Trust support — rather than a bare vesting expectancy.\nThe Prospectus describes a substantial apparatus — blacklisting, freezing, pausing, cancellation, rescission, redesignation, burning — operable at the smart-contract level “without requiring counterparty cooperation” (Prospectus, §14.2(d)(iii), p. 74). Possession transfers on-chain first, effective “upon validation and execution of the relevant transaction on a Blockchain Network” (Terms and Conditions, Condition 3.2(i), p. 82), and secondary trading occurs “outside of the CSD environment” (Prospectus, §4.3(b), p. 27). The single ex-ante, machine-enforced control described is address blocking: “The smart contract will block interactions with addresses flagged as sanctioned” (Prospectus, §14.2(b), p. 73), the Conditions adding, permissively, that the smart contracts “may include” controls against Wallets on the Designated List (Terms and Conditions, Condition 3.5, p. 83). Every other tool operates after settlement, on detection: a graduated protocol proceeding from identification of an ineligible address, through a freeze “denying the Holder all ability to transfer the Security or receive any economic benefit”, to ongoing monitoring (Prospectus, §14.2(d), p. 74), together with the power of “rescinding any purported transfer in violation of this Prospectus” (Prospectus, §14.2(a), p. 73).\nThe Tokenisation Entity may rescind transfers, cancel “any or all Securities”, redesignate Vested Holders, or freeze Securities on-chain, “in each case with or without payment” (Prospectus, §14.2(a), p. 73). A freeze denies all economic benefit “until the position is no longer prohibited (which may never occur)” (Prospectus, §4.2(a)(ii), pp. 24–25); detected prohibited holdings may be “frozen or burned” (Prospectus, §4.2(a), p. 25). No provision imposes a duration limit on a freeze, a compensation standard for a cancellation, or any procedure for contesting or releasing either.\nCondition 3.5 permits freezing, cancellation, or the refusal, suspension, delay, reversal or invalidation of any transfer where the Tokenisation Entity determines in good faith that action is necessary or advisable for legal, sanctions, compliance, custody or operational reasons, that a Designated List Wallet is involved, that a transfer “would expose the Issuer, Trustee, Custodian, or Tokenisation Entity to legal, regulatory, sanctions, or reputational risk”, or that it “would otherwise be inconsistent with the Relevant System” (Terms and Conditions, Condition 3.5, p. 83). The Prospectus separately reserves to the Issuer, “in its sole and absolute discretion and without liability”, power to refuse or suspend transfers “or require the disposal or transfer of Securities” (Prospectus, §14.1(a), p. 71) — a forced-disposal power.\nThe Tokenisation Entity “conducts continuous on-chain monitoring and reconciles on-chain positions against the Legal Register on an intraday basis” (Prospectus, §4.4A(b), p. 40), “applies blockchain analytics to risk-label external addresses” (Prospectus, §4.4(b), p. 31), and subjects all addresses holding Securities to “sanctions screening and transaction monitoring of the destination address”, with enhanced manual review above defined thresholds (Prospectus, §14.2(c), p. 73).\n+++++\n\n2. Issuance, Holding and Redemption\nPrimary issuance is available only to authorised participants approved by the issuer, which must qualify as professional clients or market counterparties under ADGM rules. Authorised participants mint against delivery of shares or cash and may sell the tokens into secondary markets, including to retail holders. The creation fee is one basis point and the redemption fee is five basis points.\nAnyone who acquires the tokens on the secondary market holds them as an unvested holder. An unvested holder has possession of the token, the right to transfer it, and the economic exposure to the underlying shares, which are held for it on a second bare trust. It does not have a redemption right until it completes the issuer’s vesting process, which covers compliance, sanctions, and wallet-control checks and is conducted at the issuer’s discretion. Vested holders may redeem in kind, in US dollars or in USDC. The securities are offered outside the United States under Regulation S and may not be held by US persons.\nThis structure has a direct consequence for liquidations. A liquidator that seizes tokens holds them as an unvested holder and must either sell them on the secondary market, hedge them until they can be realised, or complete vesting before it can redeem. Vesting has so far been used by authorised participants, and there is no separate onboarding path for a liquidator or a lending contract, so the redemption route should be treated as available only to parties that already hold the right. No minimum amounts, timing windows, or jurisdictional conditions apply to redemption beyond the fee, although the issuer may introduce them.\n2.1 Primary Issuance Path\nEvery mint runs through the issuer’s token supply manager, which is the only holder of the mint role on the tokens, so authorised participants never interact with the token contract directly. In practice a participant places an order off-chain, the issuer settles the share or cash leg in custody, and a single minter key then calls the supply manager, which mints to the participant’s wallet and records the order identifier so that the same order cannot be executed a second time. Nothing on-chain ties the token supply to the shares held at the custodian, since there is no order queue, no proof-of-reserves check ahead of a mint, and no attestation of the share inventory. The issuer reconciles the two off-chain, and the audited accounts and reserve reports that would evidence that reconciliation do not yet exist.\nThe only on-chain limit on issuance is the allowance assigned to the minter, which caps the amount of each token that can be created in any 24-hour window and refills continuously over that window. The amounts, listed in section 3, come to about USD 5M per token per day at current prices, and the issuer’s administrator can change or remove them in a single transaction. A mint can be directed to any address that is not on the transfer blocklist.\nThe seven names saw their first mint on 12 August 2026, and since then the supply manager has processed 1,669 mints and 803 redemptions on them, worth USD 34.7M and USD 20.3M respectively at the daily close, with the weekly volumes per token shown below. The same contract also serves the issuer’s other six equity tokens and seven test tokens, bringing its totals to 2,634 mints and 1,533 redemptions since late July 2026, so any operational change to it reaches every listed name at once.\nchart2520×1080 111 KB\nSource: LlamaRisk, 23 September 2026\n2.2 Redemption Path\nRedemption runs through the same contract in the opposite direction. The redeemer transfers tokens to the supply manager, which burns them and records the multiplier in force at the time, and the issuer then settles the share or cash leg off-chain. Before the burn the call passes three checks:\n\nThe caller must be a member of the redeem allowlist held in Base’s policy registry,\nthe token must not have its redemption paused on the manager,\nand the redeemed amount must clear a per-token minimum, which is currently zero for all seven names.\n\nThe redeem allowlist is where the vesting gate described in section 1 takes effect on-chain, and it is managed by the issuer’s administrator key. On 23 September 2026 it holds five addresses, all of them externally-owned accounts, which were added one at a time on 24 July, 2 August, 18 August, 31 August and 13 September 2026. Since redemption carries no rate limit, an allowlisted party can redeem its entire holding in one transaction and depends only on the issuer’s off-chain settlement thereafter.\nThe supply manager also carries a per-token redemption pause, but only an address holding a redeem-pauser right can use it and the issuer has not granted that right to anyone. As a consequence, when the issuer halts redemptions around a corporate action it does so by no longer processing orders off-chain, and nothing on-chain records that redemptions are closed. An integrator that wants to know whether a corporate-action window is open therefore has a single signal to read, which is the pause flag on the oracle registry described in section 5.\nProcessing times for either leg are not observable on-chain. A mint appears only at the moment the minter key executes it, and a redemption burns in the same transaction in which the redeemer hands over the tokens, so neither event records when the order was placed or how long the issuer took to settle the share or cash leg in custody. The offering documents commit to no timetable either. Creation orders are processed at the issuer’s discretion and may be capped per 24-hour period, a redemption order is submitted in whatever form the tokenisation entity prescribes and can be delayed or suspended both before and after acceptance with no outer time limit, and the issuer describes the processing time for vesting only as short. We therefore treat the timing of the primary route as resting entirely on the issuer.\n2.3 Secondary Holding and Transfer Controls\nSecondary transfers need no allowlist, but every transfer is checked against a single blocklist held in Base’s policy registry, with the check applied to the sender, the receiver, and the account submitting the transaction, and the same blocklist decides who may receive a mint. A blocked transfer reverts. Approvals are not checked against the list, so an allowance can remain in place for tokens that can no longer move.\n\nProperty\nValue\n\nPolicy\nBlocklist, policy id 5 in the policy registry\n\nCreated\n10 July 2026, by the issuer’s deployer key\n\nApplied to\nTransfer sender, transfer receiver, transfer executor, and mint receiver on all seven tokens\n\nAdministrator\nCompliance administrator 0xEC0F…2812, externally-owned account, no handover pending\n\nMembers on 23 September 2026\n479 addresses\n\nChange control\nOne administrator, no delay, no cap on batch size\n\nThe list was seeded in bulk and has grown in occasional batches since.\n\nDate\nChange\nMembers after\n\n22 July 2026\n390 addresses blocked in eight transactions\n390\n\n23 July 2026\n7 blocked\n397\n\n4 to 11 August 2026\n8 blocked, 1 unblocked\n404\n\n25 August 2026\n25 blocked\n429\n\n10 September 2026\n52 blocked\n479\n\nThe compliance administrator is a different key from the issuance administrator, which is consistent with the issuer’s statement that compliance functions are held apart from issuance functions.\n3. Token Standard and Issuer Contracts\nThe tokens are implemented on B20, a Base-native token standard that runs as a chain precompile and extends ERC-20. Balances never change, each token instead carries a multiplier that starts at 1.0 and moves only on corporate actions.\nTransfers are open to anyone not on the blocklist described in section 2.3. Each token can pause transfers, mints, and burns separately, can burn the balance of a blocked account, and gains a seize function with the Cobalt network upgrade. The tokens carry no supply ceiling of their own, and issuance is bounded instead by the issuer’s supply manager contract, which the rest of this section describes.\n3.1 Onchain Footprint\nThe seven tokens are precompile accounts whose bytecode is a single marker byte, so their behaviour comes from the Base node software rather than from verified contract source. The issuer’s own contracts sit beside them, all deployed by one deployer key on 10 July 2026, and the issuer’s asset factory then created the thirteen equity tokens on 26 July 2026.\n\nComponent\nAddress\nFunction\n\nAAPLc\n0xb200…d1fb\nB20 asset precompile, 8 decimals, supply 6,437\n\nAMZNc\n0xb200…C2E8\nB20 asset precompile, 8 decimals, supply 7,706\n\nGOOGLc\n0xb200…58B7\nB20 asset precompile, 8 decimals, supply 6,584, multiplier 1.000377 after one reinvested dividend\n\nMETAc\n0xb200…707C\nB20 asset precompile, 8 decimals, supply 3,854\n\nMSFTc\n0xB200…872B\nB20 asset precompile, 8 decimals, supply 3,986\n\nNVDAc\n0xB200…108C\nB20 asset precompile, 8 decimals, supply 16,618\n\nTSLAc\n0xb200…0cD0\nB20 asset precompile, 8 decimals, supply 2,838\n\nToken supply manager (proxy)\n0xd1ca…664c\nHolds the mint and burn roles on every token. Executes mints for the configured minter and processes redemptions for allowlisted redeemers. Rate-limits minting per caller through an allowance that refills linearly over a 24-hour interval\n\nToken supply manager (implementation)\n0x3F27…C6E3\nVersion 2, verified source, in force since 11 August 2026\n\nAsset factory (proxy)\n0x4bA3…534D\nCreates tokens through the B20 factory precompile, seeds the transfer blocklist into each new token, and registers it on the supply manager\n\nAsset factory (implementation)\n0xbBcb…28Ca\nVerified source, unchanged since deployment\n\nOracle registry\n0x3f3E…5CaD\nPublishes the live multiplier and a pause flag per token. Chainlink reads both from this contract. Not a proxy, verified source\n\nPolicy registry\n0x8453…0002\nBase precompile holding the transfer blocklist (policy 5) and the redeem allowlist\n\nB20 factory\n0xB20f…0000\nBase precompile that creates B20 tokens at deterministic addresses\n\n3.2 Upgrade Architecture\nThe token logic changes only when Base upgrades the network. B20 arrived with the Beryl upgrade, and the Cobalt upgrade on 30 September 2026 swaps in new logic behind the same precompile addresses, adding the scheduled multiplier path, the seize function, composite policies, and ERC-165 interface detection. Because a fork changes every B20 token on the chain at once, the issuer cannot opt out and has nothing to sign. Base’s contract upgrades are authorised jointly by a Coinbase signer set and the Security Council for Base, although the B20 documentation does not say who sets a fork’s activation time.\nThe issuer’s own contracts follow a more conventional pattern. The supply manager and the asset factory are UUPS proxies whose upgrader role sits with a single externally-owned account and is not behind a timelock. The supply manager has been upgraded once, on 11 August 2026, when version 2 added the order identifier on mints and separated the redemption checks, while the asset factory has not changed since 10 July 2026. The oracle registry is a plain contract with no upgrade path, so changing what Chainlink reads would require a new deployment and a feed reconfiguration.\nNone of the changes available to the issuer is subject to an on-chain delay, so contract upgrades, role grants, policy edits, and allowance changes all take effect in the transaction that submits them.\n3.3 Audit History\nThe B20 precompile has been reviewed by Spearbit researchers working through Cantina ahead of each Base upgrade that touched it, and the reports are published in the Base repository.\n\nAudit\nDate\nCoverage\nOutcome\n\nCantina, B20 precompiles\nReview 1 to 9 June 2026, report 14 August 2026\nB20 token and policy registry precompiles as shipped in Beryl\n29 findings, 1 High (oversized precompile inputs aborting the EVM) fixed, 11 Low, 17 informational\n\nCantina, precompile macros and storage\nReview 1 to 9 June 2026, report 14 August 2026\nStorage layout and macro layer under the precompiles\n37 findings, 5 Medium, 13 Low, 19 informational\n\nCantina, Cobalt precompile diff\nReview 17 August to 2 September 2026, report 10 September 2026\nSeize, scheduled multiplier, composite policies, ERC-165\n20 findings, 1 High (policy update access order on the stablecoin variant) fixed, 1 Medium, 4 Low, 3 acknowledged\n\nCantina, Cobalt dynamic upgrades\nReport 19 September 2026\nFork-activation mechanism nodes poll from L1\n1 High, 6 Medium, 9 Low\n\nThe Beryl reviews cover the code running today, and the Cobalt review covers the changes that go live on 30 September 2026, which means that the scheduled multiplier path and the seize function have been reviewed once and have not yet run in production.\nNo audit of the supply manager, the asset factory, or the oracle registry has been published, and the prospectus does not cite one either, saying only that the tokenisation entity deploys and audits the smart contracts. The three contracts are small, with verified source, and are built from standard OpenZeppelin access control and UUPS components, but version 2 of the supply manager, in force since 11 August 2026, postdates any review the July deployment may have had. Coinbase runs a bug bounty on Cantina that covers every mainnet contract it has deployed, with a maximum payout of USD 5M for a critical finding, and Base runs a separate HackerOne programme for off-chain and infrastructure findings, both referenced in the Base security policy. No unfixed critical finding is reported across the audits or the bounties.\n3.4 Access Control Model\nEvery contract in the footprint uses OpenZeppelin role-based access control, and on 23 September 2026 every role resolves either to an externally-owned account or to the supply manager, with no multisig, timelock, or module contract anywhere in the role tables. The issuer has indicated that administrative actions go through a hardware-backed key management system with multiple approvals, and that compliance keys are held apart from issuance keys.\nThe token roles are defined by the B20 standard. The default administrator grants and revokes every other role, changes the policy slots, and sets the supply cap, and the standard will not let the last default administrator be removed unless it deliberately renounces into a state with no administrator at all. A role-gated call checks the role first and then whether the feature concerned is paused.\n\nRole\nPurpose\nHolder (on-chain)\n\nDEFAULT_ADMIN_ROLE on all seven tokens\nGrant and revoke every token role, update the four policy slots, set the supply cap\nIssuance administrator 0x3846…72B1, externally-owned account\n\nOPERATOR_ROLE on all seven tokens\nUpdate the multiplier instantly, schedule or cancel a multiplier update after Cobalt, wrap calls in an announcement\nOperator 0x5da4…4d9a, externally-owned account, and on GOOGLc only a second operator 0xe6cb…8c37, externally-owned account, granted on 14 September 2026 in the transaction that applied the dividend multiplier\n\nMINT_ROLE and BURN_ROLE on all seven tokens\nMint to any non-blocked address, burn the caller’s own balance\nToken supply manager only\n\nPAUSE_ROLE and UNPAUSE_ROLE on all seven tokens\nPause and unpause the transfer, mint, burn, and seize features individually\nPauser 0x2fb5…bcdd, externally-owned account\n\nMETADATA_ROLE on all seven tokens\nChange name, symbol, contract URI, and extra metadata such as the ISIN\nOperator 0x5da4…4d9a and 0x1cc0…beca, externally-owned accounts\n\nBURN_BLOCKED_ROLE and SEIZE_ROLE on all seven tokens\nBurn from a blocked account (deprecated), seize from any non-exempt account after Cobalt\nNo holder\n\nDEFAULT_ADMIN_ROLE on the supply manager\nConfigure and remove minters and their allowances, register and deregister tokens, set the redeem policy, set the per-token redeem minimum, grant redeem pausers, grant the factory and upgrader roles\nIssuance administrator 0x3846…72B1\n\nUPGRADER_ROLE on the supply manager and the asset factory\nReplace the implementation\nUpgrader 0x7D4D…a106, externally-owned account\n\nFACTORY_ROLE on the supply manager\nRegister a newly created token and its redeem minimum on the supply manager, called at the end of each token deployment\nIssuer asset factory 0x4bA3…534D, the proxy contract listed in 3.1, which needs this role to complete a deployment\n\nConfigured minter on the supply manager\nCall the mint function within the per-token 24-hour allowance\nMinter 0x06fB…AbA8, externally-owned account, the only minter on all seven tokens\n\nDEFAULT_ADMIN_ROLE on the asset factory\nGrant token deployer and upgrader roles\nIssuance administrator 0x3846…72B1\n\nTOKEN_DEPLOYER_ROLE on the asset factory\nCreate new tokens with the issuance administrator as token admin and the operator as operator\nDeployer 0xE090…5C6f and 0xeE63…cC70, externally-owned accounts\n\nDEFAULT_ADMIN_ROLE and PAUSER_ROLE on the oracle registry\nGrant roles, set the per-token pause flag that halts the Chainlink feed\nIssuance administrator 0x3846…72B1\n\nRedeem allowlist administrator\nAdd and remove redeemers\nIssuance administrator 0x3846…72B1\n\nTransfer blocklist administrator\nBlock and unblock addresses on the policy applied to every transfer and mint\nCompliance administrator 0xEC0F…2812, externally-owned account\n\nThe issuance administrator sits at the root of the structure, since it is the default administrator on every token, on the supply manager, on the asset factory, and on the oracle registry, as well as the registry’s only pauser and the administrator of the redeem allowlist. Whoever holds that key can grant any role on any token to any address, re-point a transfer policy slot, lift the mint allowance, replace the redeem policy, or halt the price feed, each in a single transaction. The operator key is the second point of concentration, because it can move the multiplier on all seven tokens instantly and with no bound on the size of the step, and since 14 September 2026 a second operator key has held the same power on GOOGLc.\nPolicies in the registry follow their own rules. Each policy has one administrator at a time, handing it over takes a stage step followed by a finalise step, and an administrator that renounces freezes the membership permanently. Neither the blocklist nor the redeem allowlist has a handover pending, so both can still be changed.\n3.5 Pause Surface\nThree pause mechanisms coexist, and none is active on 23 September 2026.\n\nToken feature pause. The pauser key can pause transfers, mints, and burns on any token separately, and seizures once Cobalt is live. A transfer pause stops every balance movement, so supplies, withdrawals, and the collateral leg of a liquidation all fail until it is lifted and a position cannot be unwound on-chain in the meantime, although approvals continue to work. The issuer describes on-chain pauses as unlikely, the pause roles were first granted on 3 September 2026, and no token has been paused since deployment.\nRedemption pause. The supply manager can pause redemptions per token, but only an address with a redeem-pauser right can do so and none has been granted, so the pause on minting and redemption that the issuer applies around corporate actions is an off-chain decision not to process orders.\nOracle registry pause. The issuance administrator can set a flag per token that Chainlink reads, and while it is set the feed stops publishing and holds its last value. The flag has never been set on any of the seven tokens. This is the pause the issuer intends to use around corporate actions, and because tokens keep changing hands against a frozen price while it is set, the affected reserve is paused on the Aave side for the same window.\n\nLike every role action, a pause executes immediately with no on-chain delay.\n3.6 Multiplier and Corporate-Action Controls\nTwo properties of the corporate-action path shape the controls on the Aave side. The operator role can change the multiplier instantly, and although the standard recommends wrapping the change in an on-chain announcement it does not enforce it. The standard also defines a scheduled path with an effective time, following ERC-8056, but that path is not active on the deployed tokens and only arrives with the Cobalt upgrade on 30 September 2026, together with pre-announcement of pending changes and ERC-165 interface detection. Until then the tokens should be treated as not conforming to those interfaces, and a multiplier change that does not match an announced corporate action is treated as a price incident, with the affected reserve paused until the change is explained.\nThe instant update has no limit on the size of the step and does not check the state of the feed, so a mis-sequenced or mistaken call can move the token’s value by any factor in one transaction. After Cobalt the scheduled path allows one pending update at a time with an effective timestamp, which the operator can cancel before it matures, but maturation itself writes nothing and emits no event, so an integrator has to read the pending value and its effective time directly rather than wait for a signal. The instant setter remains available as an emergency path and clears any pending update. Because the oracle registry reads the multiplier live from the token, a change reaches the Chainlink feed on its next update unless the registry pause flag has been set first.\nThe multiplier has moved once across the seven tokens, for the GOOGLc cash dividend of 14 September 2026. At 15:39 UTC the operator key posted an announcement on GOOGLc describing the dividend and linking to the issuer’s corporate-action record, with no state change inside it, and at 18:29 UTC a second key, granted the operator role in the same block, applied the multiplier update from 1.0 to 1.000377 inside a second announcement carrying the same description and record identifier. The oracle registry was not paused for the event, as expected for a dividend with no price discontinuity. In effect this is the pre-announcement pattern the issuer intends to formalise after Cobalt, carried out for now as two operator transactions about three hours apart.\n3.7 Supply Bounds\nNone of the seven tokens has a supply cap, although the token administrator can set one at any value at or above the current supply. What bounds issuance instead is the minter’s allowance on the supply manager, which refills at the rates below, equivalent to about USD 5M per token per day at current prices, while redemption is limited to allowlisted addresses and has no rate limit.\n\nToken\nMint allowance per 24 hours\n\nAAPLc\n15,500\n\nAMZNc\n19,100\n\nGOOGLc\n15,700\n\nMETAc\n8,200\n\nMSFTc\n10,300\n\nNVDAc\n24,000\n\nTSLAc\n14,300\n\nSource: Base onchain data, 23 September 2026\nThe allowances for AAPLc, GOOGLc, METAc, and NVDAc were set on 2 August 2026 and those for AMZNc, MSFTc, and TSLAc on 3 September 2026, and none has changed since. The issuance administrator can change them at any time with immediate effect, and because the add caps in the Aave V4 Base deployment ARFC are sized against these values, a change to them is a reason to revisit the caps.\n4. Corporate Actions\nCorporate actions reach the chain through the multiplier. A reinvested dividend moves it by a fraction of a percent with no price event, and a split moves it by the split ratio at the same moment as the underlying price divides by that ratio. A split is the event that matters for a lending market, because if the token applies the new multiplier before the feed applies the new price, or the reverse, the token is mispriced by the full split ratio until the two realign.\nThe issuer’s current sequence is to pause minting and redemption off-chain and pause the feed through the oracle registry, update the multiplier, verify that the new underlying price multiplied by the new multiplier matches the held value, and then resume the feed and the off-chain flows. The announcement accompanies the multiplier update in the same transaction, and the multiplier update event is the point at which the action is considered processed onchain. The issuer has stated that every direct multiplier update will be wrapped in an announcement. That commitment is operational, since the standard does not enforce it, and it is expected to move to a pre-announcement once the network upgrade described in section 3 is live.\nDividends are reinvested at the time and price of the dividend payment, net of withholding tax and the issuer’s distribution fee, and reach the token as an increase in the multiplier. Because there is no price discontinuity, a dividend does not require a feed","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261337644,"hash":"1320ecfb8e3799603f7fb6237408c4e63361a99a"}
{"url":"https://ethereum.org/apps/morpho/","domain":"ethereum.org","title":"Ethereum Apps - Morpho | ⁦ethereum.org⁩","text":"DeFiMorphoby Morpho AssociationEnglish Visit Morpho (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextCompoundSee nextCompoundMorpho is an open lending network with $14B+ in deposits connecting lenders and borrowers to the optimal opportunities worldwide. Its modular, open infrastructure enables fintechs, wallets, exchanges, and institutions to embed configurable credit products directly into their platforms, while maintaining full control over the user experience. Leaders like Coinbase, Robinhood, Bitwise Asset Management, and Société Générale already build on Morpho to deploy secure, scalable onchain credit products. InfoFounded2022CreatorMorpho AssociationLast updated457 days agoGalleryMore apps like thisDeFiAaveAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.Lending and borrowingDeFiSky/Maker - USDSSky.money is a non-custodial gateway to the decentralized Sky Protocol, which centers around the USDS stablecoin.Stablecoin issuance · RWA · Lending and borrowingDeFiSparkSpark Fi is a non-custodial DeFi protocol that allows users to lend and borrow digital assets through SparkLend, while earning passive income via the USDS stablecoin and its associated Sky Savings Rate.Lending and borrowing · RWA","tokens":364,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261339959,"hash":"91adb40d2cb800eb8326e9fd463a4ddef497e454"}
{"url":"https://ethereum.org/apps/spark/","domain":"ethereum.org","title":"Ethereum Apps - Spark | ⁦ethereum.org⁩","text":"DeFiSparkby Spark FoundationEnglish Visit Spark (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextMorphoSee nextMorphoSpark Fi is a non-custodial DeFi protocol that allows users to lend and borrow digital assets through SparkLend, while earning passive income via the USDS stablecoin and its associated Sky Savings Rate.InfoFounded2023CreatorSpark FoundationLast updated457 days agoGalleryMore apps like thisDeFiAaveAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.Lending and borrowingDeFiSky/Maker - USDSSky.money is a non-custodial gateway to the decentralized Sky Protocol, which centers around the USDS stablecoin.Stablecoin issuance · RWA · Lending and borrowingDeFiEthena - USDEEthena is a synthetic dollar protocol built on Ethereum that provides a crypto-native solution for money, USDe, alongside a globally accessible dollar savings asset, sUSDe.RWA · Stablecoin issuance · Yield","tokens":288,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261350527,"hash":"3df28452b7375818de94b581efb72b676456c91b"}
{"url":"https://forum.openzeppelin.com/t/i-cant-remove-the-liquidity-of-pancakeswap/24660","domain":"forum.openzeppelin.com","title":"I can't remove the liquidity of pancakeswap - Support - OpenZeppelin Forum","text":"I can’t remove the liquidity of pancakeswap \n\n Support\n\n erc20,pancake\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2022\n\n 1 / 3\n\n Feb 2022\n\n Feb 2022\n\n post by Susan_Lopez on Feb 14, 2022\n\n Susan_Lopez\n\n Hello, as in the topic\nI can't remove the liquidity of pancakeswap ;/\nmy contract address\n0xe7a3fcc8577cc9a57787590f740b795694441ffd\nsomeone will help?\n\npancakeswap_liquidity678×725 54.8 KB\n\n post by frangio on Feb 18, 2022\n\n frangio\n\n OpenZeppelin Team\n\n This is a smart contract development forum. Not a PancakeSwap support forum.\n\n Closed on Feb 18, 2022\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I can’t remove the LP from pancakeswap (22 BNB)\n\n Smart Contracts\n\n 5\n\n 1.2k\n\n Aug 2022\n\n Not able to remove liquidity from Pancakeswap\n\n Contracts\n\n 1\n\n 633\n\n Aug 2021\n\n HELP Can’t remove liquidity on pcs v2\n\n Smart Contracts\n\n 4\n\n 888\n\n Nov 2022\n\n This transaction would fail , stuck liquidity error\n\n Smart Contracts\n\n 0\n\n 36\n\n Apr 2025\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024","tokens":282,"squid":"ink-security_audits","role":"Sentinel","at":1791261354292,"hash":"3ba33c8b61f1046857cb169f7ccf2684d39069d1"}
{"url":"https://dev-forum.pyth.network/t/real-time-oracle-intelligence-platform-paper-prediction-game/671/1","domain":"dev-forum.pyth.network","title":"Real-time oracle intelligence platform + paper prediction game - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Real-time oracle intelligence platform + paper prediction game \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 28\n\n 1 / 3\n\n Mar 27\n\n Mar 28\n\n post by 0xPilotSB on Mar 28\n\n 0xPilotSB\n\n (topic deleted by author)\n\n Unlisted on Mar 28\n\n Listed on Mar 29\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Ouroboros — Describe a Game, Get a Deployed Pyth dApp (AI AGENT)\n\n Pyth Community Hackathon\n\n 0\n\n 50\n\n Apr 1\n\n Real-time Oracle Intelligence Platform + Paper Prediction Games\n\n Pyth Community Hackathon\n\n 0\n\n 36\n\n Mar 29\n\n PyPredict — Real-Time Prediction Markets on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 32\n\n Mar 31\n\n Price Royale - A price prediction game built on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 44\n\n Mar 24\n\n Powered by Discourse","tokens":1118,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261364351,"hash":"ba0a6b93987906a67204f782245167423617feae"}
{"url":"https://id.io.net/","domain":"id.io.net","title":"Explorer | io.net","text":"Ready-to-use devices fully secured with $IO stakingEach device is ready-to-use and secured by a stake in $IO proportional to its computational capacity 848Total Cluster Ready and Fully Collateralized GPUs/CPUs848 GPUs & CPUs Hired 833Idle 15 Launch, manage, and scale your AI workloads Bring model serving, inference routing, and agent execution together.Supply Insights & Geo DistributionDiscover our globally distributed IO Worker NetworkWorldwide838/10Total GPUs / CPUsHired 833Top 5 NodesDiscover the latest in GPU and CPU technologyH100 80GB HBM3592GeForce RTX 4090176RTX A600012L40S9RTX PRO 6000 Blackwell Server Edition9Trending DevicesDiscover the latest in GPU and CPU technology, optimized for top-tier performance in training AI models and inference tasks.NVIDIAAppleIntelGPUCPU Chip:B300 SXM6 ACQty:8Ray:$4.48/hrContainer:$6.73/hrBaremetal:--VM:$4.5/hr Chip:H100 80GB HBM3Qty:592Ray:$1.19/hrContainer:$2.09/hrBaremetal:$1.79/hrVM:$1.99/hr Chip:H100 PCIeQty:8Ray:$0.89/hrContainer:$1/hrBaremetal:$1.39/hrVM:$1.59/hr Chip:L40SQty:9Ray:$0.79/hrContainer:$0.89/hrBaremetal:$0.99/hrVM:$0.89/hr Chip:L40Qty:2Ray:$0.79/hrContainer:--Baremetal:--VM:-- Chip:A100-SXM4-80GBQty:8Ray:$0.74/hrContainer:$1.39/hrBaremetal:$1.09/hrVM:$1.29/hr Chip:RTX A6000Qty:12Ray:$0.32/hrContainer:--Baremetal:--VM:-- Chip:RTX 6000 Ada GenerationQty:8Ray:$0.32/hrContainer:--Baremetal:--VM:-- Chip:GeForce RTX 4090Qty:176Ray:$0.25/hrContainer:$0.3/hrBaremetal:$0.37/hrVM:$0.3/hr Chip:Tesla T4Qty:1Ray:$0.05/hrContainer:--Baremetal:--VM:-- Chip:RTX PRO 6000 Blackwell Server EditionQty:9Ray:$0/hrContainer:--Baremetal:--VM:-- Chip:GeForce RTX 3090Qty:2Ray:$0.18/hrContainer:$0.27/hrBaremetal:$0.2/hrVM:$0.25/hr Chip:GeForce RTX 3080Qty:2Ray:$0.17/hrContainer:--Baremetal:--VM:-- Chip:M4 MaxQty:1Ray:$0.15/hrContainer:--Baremetal:--VM:-- Chip:M3 MaxQty:2Ray:$0.14/hrContainer:--Baremetal:--VM:-- Chip:M4 ProQty:2Ray:$0.13/hrContainer:--Baremetal:--VM:-- Chip:M3 ProQty:1Ray:$0.13/hrContainer:--Baremetal:--VM:-- Chip:GeForce RTX 3060Qty:1Ray:$0.13/hrContainer:--Baremetal:--VM:-- Chip:M4Qty:4Ray:$0.1/hrContainer:--Baremetal:--VM:--ChipQTYRayContainerBAREMETALVMB300 SXM6 AC8$4.48/hr$6.73/hr--$4.5/hrH100 80GB HBM3592$1.19/hr$2.09/hr$1.79/hr$1.99/hrH100 PCIe8$0.89/hr$1/hr$1.39/hr$1.59/hrL40S9$0.79/hr$0.89/hr$0.99/hr$0.89/hrL402$0.79/hr------A100-SXM4-80GB8$0.74/hr$1.39/hr$1.09/hr$1.29/hr","tokens":593,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261365029,"hash":"82df8e6fde222a29f711487e7fe49236c5a93dd8"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-crypto-anomaly-detector-on-pyth-network/732","domain":"dev-forum.pyth.network","title":"PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 1\n\n 1 / 3\n\n Apr 1\n\n Apr 1\n\n post by bemma on Apr 1\n\n bemma\n\n (topic deleted by author)\n\n Unlisted on Apr 1\n\n Listed on Apr 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 28\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector\n\n Pyth Community Hackathon\n\n 0\n\n 23\n\n Mar 31\n\n Request: 1ms crypto data feed trial and micro‑movement behavior\n\n Price Feeds\n\n 2\n\n 58\n\n Mar 22\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 473\n\n Jul 2025\n\n Powered by Discourse","tokens":1100,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261374688,"hash":"800021784df00c774719bed39a7336a2018c3e4f"}
{"url":"https://forum.openzeppelin.com/t/i-cant-remove-the-liquidity-of-pancakeswap/24660/2","domain":"forum.openzeppelin.com","title":"I can't remove the liquidity of pancakeswap - Support - OpenZeppelin Forum","text":"Support\n\n erc20,pancake\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2022\n\n 3 / 3\n\n Feb 2022\n\n Feb 2022\n\n post by Susan_Lopez on Feb 14, 2022\n\n Susan_Lopez\n\n Hello, as in the topic\nI can't remove the liquidity of pancakeswap ;/\nmy contract address\n0xe7a3fcc8577cc9a57787590f740b795694441ffd\nsomeone will help?\n\npancakeswap_liquidity678×725 54.8 KB\n\n post by frangio on Feb 18, 2022\n\n frangio\n\n OpenZeppelin Team\n\n This is a smart contract development forum. Not a PancakeSwap support forum.\n\n Closed on Feb 18, 2022\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I can’t remove the LP from pancakeswap (22 BNB)\n\n Smart Contracts\n\n 5\n\n 1.2k\n\n Aug 2022\n\n Not able to remove liquidity from Pancakeswap\n\n Contracts\n\n 1\n\n 633\n\n Aug 2021\n\n HELP Can’t remove liquidity on pcs v2\n\n Smart Contracts\n\n 4\n\n 888\n\n Nov 2022\n\n This transaction would fail , stuck liquidity error\n\n Smart Contracts\n\n 0\n\n 36\n\n Apr 2025\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024","tokens":270,"squid":"ink-security_audits","role":"Sentinel","at":1791261375126,"hash":"3307232aad657cc9427724db0984d26ae53cd61c"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-crypto-anomaly-detector-on-pyth-network/732/3","domain":"dev-forum.pyth.network","title":"PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 1\n\n 3 / 3\n\n Apr 1\n\n Apr 1\n\n post by bemma on Apr 1\n\n bemma\n\n (topic deleted by author)\n\n Unlisted on Apr 1\n\n Listed on Apr 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 28\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector\n\n Pyth Community Hackathon\n\n 0\n\n 23\n\n Mar 31\n\n Request: 1ms crypto data feed trial and micro‑movement behavior\n\n Price Feeds\n\n 2\n\n 58\n\n Mar 22\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 473\n\n Jul 2025\n\n Powered by Discourse","tokens":1084,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261385453,"hash":"a7f5574176266873edcc4072b676df9ba04d0145"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-cross-asset-anomaly-detector/720/1","domain":"dev-forum.pyth.network","title":"PythPulse: Real-Time Cross-Asset Anomaly Detector - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 31\n\n 1 / 3\n\n Mar 31\n\n Mar 31\n\n post by bemma on Mar 31\n\n bemma\n\n PythPulse is a real-time price anomaly detection dashboard built on Pyth Network’s Hermes API.\nLive Demo: https://pythpulse-2-wgig.vercel.app/\nGitHub: https://github.com/bankybemma-collab/pythpulse-2\nWhat it does:\n\nMonitors 38 live price feeds across Crypto, FX, Metals, Equities & Commodities using Pyth Hermes API\n\nDetects sudden price spikes in real-time across all assets simultaneously\n\nCalculates a Market Stress Index rises when multiplesets spike at once, signaling systemic market events\n\nLive sparkline charts, anomaly event log with timestamps, adjustable threshold slider\n\nBuilt with React, zero dependencies, deployed on Vercel\n\nTech: Pyth Hermes API · React · Custom SVG Charts · Vercel\n\n Unlisted on Apr 1\n\n Listed on Apr 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Pyth Radar - Real-time CEX deviation index with heatmap & delta\n\n Pyth Community Hackathon\n\n 0\n\n 48\n\n Mar 25\n\n PythFeeds — Real-Time Crypto, Stocks, Metals & Forex Prices\n\n Pyth Community Hackathon\n\n 3\n\n 106\n\n Mar 29\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Powered by Discourse","tokens":1294,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261395822,"hash":"851b629219755d0f51b10297cbd5abffde5508b3"}
{"url":"https://forum.openzeppelin.com/t/not-able-to-remove-liquidity-from-pancakeswap/12962/2","domain":"forum.openzeppelin.com","title":"Not able to remove liquidity from Pancakeswap - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2021\n\n 2 / 2\n\n Aug 2021\n\n Aug 2021\n\n post by Alearner on Jul 23, 2021\n\n Alearner\n\n Hello, I am not able to remove liquidity from a token I created. Nobody is able to buy either. Could someone please help me out?\nAddress & Contract:\n\nThank you!\n\n 24 days later\n\n post by Newbie on Aug 17, 2021\n\n Newbie\n\n Hi how did you resolve this ?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I can’t remove the liquidity of pancakeswap\n\n Support\n\n erc20,pancake\n\n 1\n\n 839\n\n Feb 2022\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 20\n\n 12.3k\n\n Aug 2025\n\n Can’t remove liquidity on pancakeswap v2\n\n Smart Contracts\n\n etherscan-verify,bep20\n\n 2\n\n 883\n\n Jun 2022\n\n Can’t remove liquidity on v2 pancakeswap\n\n Smart Contracts\n\n bep20\n\n 0\n\n 253\n\n Apr 2024\n\n Cannot interact with contract to remove liquidity\n\n Smart Contracts\n\n etherscan-verify,bep20,pancake\n\n 2\n\n 735\n\n Sep 2022","tokens":263,"squid":"ink-security_audits","role":"Sentinel","at":1791261399378,"hash":"0f542a24b4aa824b257b75148e63f1eafdce1a3c"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-cross-asset-anomaly-detector/720/3","domain":"dev-forum.pyth.network","title":"PythPulse: Real-Time Cross-Asset Anomaly Detector - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 31\n\n 3 / 3\n\n Apr 1\n\n Mar 31\n\n post by bemma on Mar 31\n\n bemma\n\n PythPulse is a real-time price anomaly detection dashboard built on Pyth Network’s Hermes API.\nLive Demo: https://pythpulse-2-wgig.vercel.app/\nGitHub: https://github.com/bankybemma-collab/pythpulse-2\nWhat it does:\n\nMonitors 38 live price feeds across Crypto, FX, Metals, Equities & Commodities using Pyth Hermes API\n\nDetects sudden price spikes in real-time across all assets simultaneously\n\nCalculates a Market Stress Index rises when multiplesets spike at once, signaling systemic market events\n\nLive sparkline charts, anomaly event log with timestamps, adjustable threshold slider\n\nBuilt with React, zero dependencies, deployed on Vercel\n\nTech: Pyth Hermes API · React · Custom SVG Charts · Vercel\n\n Unlisted on Apr 1\n\n Listed on Apr 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Pyth Radar - Real-time CEX deviation index with heatmap & delta\n\n Pyth Community Hackathon\n\n 0\n\n 48\n\n Mar 25\n\n PythFeeds — Real-Time Crypto, Stocks, Metals & Forex Prices\n\n Pyth Community Hackathon\n\n 3\n\n 106\n\n Mar 29\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Powered by Discourse","tokens":1280,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261407221,"hash":"9fcb110397af9231ed166e25f7937c19939b00d1"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/fault-dispute-game.html","domain":"specs.optimism.io","title":"Fault Dispute Game - OP Stack Specification","text":"Fault Dispute Game\n\nTable of Contents\n\nOverview\nDefinitions\n\nVirtual Machine (VM)\nPreimageOracle\nExecution Trace\nClaims\nAnchor State\nAnchor State Registry\nRespected Game Type\nDAG\nSubgame\nGame Tree\nPosition\nMAX_CLOCK_DURATION\nCLOCK_EXTENSION\nFreeloader Claims\n\nCore Game Mechanics\n\nActors\nMoves\n\nAttack\nDefend\n\nL2 Block Number Challenge\nStep\nStep Types\nPreimageOracle Interaction\nTeam Dynamics\nGame Clock\nResolution\n\nResolving the L2 Block Number Challenge\n\nFinalization\n\nOverview\nThe Fault Dispute Game (FDG) is a specific type of dispute game that verifies the\nvalidity of a root claim by iteratively bisecting over output roots and execution traces of single\nblock state transitions down to a single instruction step. It relies on a Virtual Machine (VM) to falsify invalid\nclaims made at a single instruction step.\nActors, i.e. Players, interact with the game by making claims that dispute other claims in the FDG.\nEach claim made narrows the range over the entire historical state of L2, until the source of dispute is a single\nstate transition. Once a time limit is reached, the dispute game is resolved, based on claims made that are disputed\nand which aren't, to determine the winners of the game.\nDefinitions\nVirtual Machine (VM)\nThis is a state transition function (STF) that takes a pre-state and computes the post-state.\nThe VM may access data referenced during the STF and as such, it also accepts a proof of this data.\nTypically, the pre-state contains a commitment to the proof to verify the integrity of the data referenced.\nMathematically, we define the STF as where\n\n is the pre-state\n is an optional proof needed for the transition from to .\n\nPreimageOracle\nThis is a pre-image data store. It is often used by VMs to read external data during its STF.\nBefore successfully executing a VM STF, it may be necessary to preload the PreimageOracle with pertinent data.\nThe method for key-based retrieval of these pre-images varies according to the specific VM.\nExecution Trace\nAn execution trace is a sequence where each is a VM state and\nfor each , , .\nEvery execution trace has a unique starting state, , that's preset to a FDG implementation.\nWe refer to this state as the ABSOLUTE_PRESTATE.\nClaims\nClaims assert an output root or the state of the FPVM at a given instruction. This is represented as\na Hash type, a bytes32 representing either an output root or a commitment to the last VM state in a\ntrace. A FDG is initialized with an output root that corresponds to the state of L2 at a given L2 block number, and\nexecution trace subgames at SPLIT_DEPTH + 1 are initialized with a claim that commits to the entire execution trace\nbetween two consecutive output roots (a block n -> n+1 state transition). As we'll see later, there can be multiple\nclaims, committing to different output roots and FPVM states in the FDG.\nAnchor State\nAn anchor state, or anchor output root, is a previous output root that is assumed to be valid. An\nFDG is always initialized with an anchor state and execution is carried out between this anchor\nstate and the claimed output root. FDG contracts pull their anchor state from the\nAnchor State Registry contract. The initial anchor state for a FDG is the\ngenesis state of the L2.\nClients must currently gather L1 data for the window between the anchor state and the claimed\nstate. In order to reduce this L1 data requirement, claims about the state of the L2\nbecome new anchor states when dispute games resolve in their favor. FDG contracts set their anchor\nstates at initialization time so that these updates do not impact active games.\nAnchor State Registry\nThe Anchor State Registry is a registry that the FDG uses to determine its anchor state. It also\ndetermines if the game is finalized and\n\"proper\" for purposes of Bond\nDistribution. See Anchor State Registry for more\ndetails.\nRespected Game Type\nA Fault Dispute Game must record whether its game type is respected at the time of its creation. See\nRespected Game Type for more details.\nDAG\nA Directed Acyclic Graph representing the relationship between claims, where:\n\n is the set of nodes, each representing a claim. Formally, ,\nwhere is a claim.\n is the set of directed edges. An edge exists if is a direct dispute\nagainst through either an \"Attack\" or \"Defend\" move.\n\nSubgame\nA sub-game is a DAG of depth 1, where the root of the DAG is a Claim and the children are Claims that counter the\nroot. A good mental model around this structure is that it is a fundamental dispute between two parties over a single\npiece of information. These subgames are chained together such that a child within a subgame is the root of its own\nsubgame, which is visualized in the resolution section. There are two types of sub-games in the fault\ndispute game:\n\nOutput Roots\nExecution Trace Commitments\n\nAt and above the split depth, all subgame roots correspond to output roots, or commitments to the full\nstate of L2 at a given L2 block number. Below the split depth, subgame roots correspond to commitments to the fault\nproof VM's state at a given instruction step.\nGame Tree\nThe Game Tree is a binary tree of positions. Every claim in the DAG references a position in the Game Tree.\nThe Game Tree has a split depth and maximum depth, SPLIT_DEPTH and MAX_GAME_DEPTH respectively, that are both\npreset to an FDG implementation. The split depth defines the maximum depth at which claims about\noutput roots can occur, and below it, execution trace bisection occurs. Thus, the Game Tree contains\n positions, where is the MAX_GAME_DEPTH (unless , in which case there's only 1 position).\nThe full game tree, with a layer of the tree allocated to output bisection, and sub-trees after an arbitrary split\ndepth, looks like:\n\nPosition\nA position represents the location of a claim in the Game Tree. This is represented by a\n\"generalized index\" (or gindex) where the high-order bit is the level in the tree and the remaining\nbits is a unique bit pattern, allowing a unique identifier for each node in the tree.\nThe gindex of a position can be calculated as , where:\n\n is a function returning the depth of the position in the Game Tree\n is a function returning the index of the position at its depth (starting from the left).\n\nPositions at the deepest level of the game tree correspond to indices in the execution trace, whereas claims at the\nsplit depth represent single L2 blocks' output roots.\nPositions higher up the game tree also cover the deepest, right-most positions relative to the current position.\nWe refer to this coverage as the trace index of a Position.\n\nThis means claims commit to an execution trace that terminates at the same index as their Position's trace index.\nThat is, for a given trace index , its state witness hash corresponds to the th state in the trace.\n\nNote that there can be multiple positions covering the same trace index.\nMAX_CLOCK_DURATION\nThis is an immutable, preset to a FDG implementation, representing the maximum amount of time that may accumulate on a\nteam's chess clock.\nCLOCK_EXTENSION\nThis is an immutable, preset to a FDG implementation, representing the flat credit that is given to a team's clock if\ntheir clock has less than CLOCK_EXTENSION seconds remaining.\nFreeloader Claims\nDue to the subgame resolution logic, there are certain moves which result in the correct final resolution of the game,\nbut do not pay out bonds to the correct parties.\nAn example of this is as follows:\n\nAlice creates a dispute game with an honest root claim.\nBob counters the honest root with a correct claim at the implied L2 block number.\nAlice performs a defense move against Bob's counter, as the divergence exists later in Bob's view of the chain state.\nBob attacks his own claim.\n\nBob's attack against his own claim is a counter to a bad claim, but with the incorrect pivot direction. If left\nuntouched, because it exists at a position further left than Alice's, he will reclaim his own bond upon resolution.\nBecause of this, the honest challenger must always counter freeloader claims for incentive compatibility to be\npreserved.\nCritically, freeloader claims, if left untouched, do not influence incorrect resolution of the game globally.\nCore Game Mechanics\nThis section specifies the core game mechanics of the FDG. The full FDG mechanics includes a\nspecification for Bonds. Readers should understand basic game mechanics before\nreading up on the Bond specification.\nActors\nThe game involves two types of participants (or Players): Challengers and Defenders.\nThese players are grouped into separate teams, each employing distinct strategies to interact with the game.\nTeam members share a common goal regarding the game's outcome. Players interact with the game primarily through\nmoves.\nMoves\nA Move is a challenge against an existing claim and must include an alternate claim asserting a different trace.\nMoves can either be attacks or defenses and serve to update to DAG by adding nodes and edges targeting the disputed\nclaim.\nMoves within the fault dispute game can claim two separate values: output roots and execution trace\ncommitments. At and above the SPLIT_DEPTH, claims correspond to output roots, while below the split depth, they\ncorrespond to execution trace commitments.\nInitially, claims added to the DAG are uncontested (i.e. not countered). Once a move targets a claim, that claim\nis considered countered.\nThe status of a claim — whether it's countered or not — helps determine its validity and, ultimately, the\ngame's winner.\nAttack\nA logical move made when a claim is disagreed with.\nA claim at the relative attack position to a node, n, in the Game Tree commits to half\nof the trace of the n’s claim.\nThe attack position relative to a node can be calculated by multiplying its gindex by 2.\nTo illustrate this, here's a Game Tree highlighting an attack on a Claim positioned at 6.\n\nAttacking the node at 6 moves creates a new claim positioned at 12.\nDefend\nThe logical move against a claim when you agree with both it and its parent.\nA defense at the relative position to a node, n, in the Game Tree commits to the first half of n + 1’s trace range.\n\nNote that because of this, some nodes may never exist within the Game Tree.\nHowever, they're not necessary as these nodes have complimentary, valid positions\nwith the same trace index within the tree. For example, a Position with gindex 5 has the same\ntrace index as another Position with gindex 2. We can verify that all trace indices have valid moves within the game:\n\nThere may be multiple claims at the same position, so long as their state witness hashes are unique.\nEach move adds new claims to the Game Tree at strictly increasing depth.\nOnce a claim is at MAX_GAME_DEPTH, the only way to dispute such claims is to step.\nL2 Block Number Challenge\nThis is a special type of action, made by the Challenger, to counter a root claim.\nGiven an output root preimage and its corresponding RLP-encoded L2 block header, the L2 block number can be verified.\nThis process ensures the integrity and authenticity of an L2 block number.\nThe procedure for this verification involves three steps: checking the output root preimage, validating the block hash preimage,\nand extracting the block number from the RLP-encoded header.\nBy comparing the challenger-supplied preimages and the extracted block number against their claimed values,\nthe consistency of the L2 block number with the one in the provided header can be confirmed, detecting any discrepancies.\nRoot claims made with an invalid L2 block number can be disputed through a special challenge.\nThis challenge is validated in the FDG contract using the aforementioned procedure.\nHowever, it is crucial to note that this challenge can only be issued against the root claim,\nas it's the only entity making explicit claims on the L2 block number.\nA successful challenge effectively disputes the root claim once its subgame is resolved.\nStep\nAt MAX_GAME_DEPTH, the position of claims correspond to indices of an execution trace.\nIt's at this point that the FDG is able to query the VM to determine the validity of claims,\nby checking the states they're committing to.\nThis is done by applying the VM's STF to the state a claim commits to.\nIf the STF post-state does not match the claimed state, the challenge succeeds.\n/// @notice Perform an instruction step via an on-chain fault proof processor.\n/// @dev This function should point to a fault proof processor in order to execute\n/// a step in the fault proof program on-chain. The interface of the fault proof\n/// processor contract should adhere to the `IBigStepper` interface.\n/// @param _claimIndex The index of the challenged claim within `claimData`.\n/// @param _isAttack Whether or not the step is an attack or a defense.\n/// @param _stateData The stateData of the step is the preimage of the claim at the given\n/// prestate, which is at `_stateIndex` if the move is an attack and `_claimIndex` if\n/// the move is a defense. If the step is an attack on the first instruction, it is\n/// the absolute prestate of the fault proof VM.\n/// @param _proof Proof to access memory nodes in the VM's merkle state tree.\nfunction step(uint256 _claimIndex, bool _isAttack, bytes calldata _stateData, bytes calldata _proof) external;\n\nStep Types\nSimilar to moves, there are two ways to step on a claim; attack or defend.\nThese determine the pre-state input to the VM STF and the expected output.\n\nAttack Step - Challenges a claim by providing a pre-state, proving an invalid state transition.\nIt uses the previous state in the execution trace as input and expects the disputed claim's state as output.\nThere must exist a claim in the DAG that commits to the input.\nDefense Step - Challenges a claim by proving it was an invalid attack,\nthereby defending the disputed ancestor's claim. It uses the disputed claim's state as input and expects\nthe next state in the execution trace as output. There must exist a claim in the DAG that commits to the\nexpected output.\n\nThe FDG step handles the inputs to the VM and asserts the expected output.\nA step that successfully proves an invalid post-state (when attacking) or pre-state (when defending) is a\nsuccessful counter against the disputed claim.\nPlayers interface with step by providing an indicator of attack and state data (including any proofs)\nthat corresponds to the expected pre/post state (depending on whether it's an attack or defend).\nThe FDG will assert that an existing claim commits to the state data provided by players.\nPreimageOracle Interaction\nCertain steps (VM state transitions) require external data to be available by the PreimageOracle.\nTo ensure a successful state transition, players should provide this data in advance.\nThe FDG provides the following interface to manage data loaded to the PreimageOracle:\n/// @notice Posts the requested local data to the VM's `PreimageOracle`.\n/// @param _ident The local identifier of the data to post.\n/// @param _execLeafIdx The index of the leaf claim in an execution subgame that requires the local data for a step.\n/// @param _partOffset The offset of the data to post.\nfunction addLocalData(uint256 _ident, uint256 _execLeafIdx, uint256 _partOffset) external;\n\nThe addLocalData function loads local data into the VM's PreimageOracle. This data consists of bootstrap data for\nthe program. There are multiple sets of local preimage keys that belong to the FaultDisputeGame contract due to the\nability for players to bisect to any block state transition since the configured anchor state, the\n_execLeafIdx parameter enables a search for the starting / disputed outputs to be performed such that the contract\ncan write to and reference unique local keys in the PreimageOracle for each of these \ntransitions.\nIdentifierDescription\n1Parent L1 head hash at the time of the proposal\n2Starting output root hash (commits to block # n)\n3Disputed output root hash (commits to block # n + 1)\n4Disputed L2 block number (block # n + 1)\n5L2 Chain ID\n\nFor global keccak256 preimages, there are two routes for players to submit:\n\nSmall preimages atomically.\nLarge preimages via streaming.\n\nGlobal keccak256 preimages are non-context specific and can be submitted directly to the PreimageOracle via the\nloadKeccak256PreimagePart function, which takes the part offset as well as the full preimage. In the event that the\npreimage is too large to be submitted through calldata in a single block, challengers must resort to the streaming\noption.\nLarge Preimage Proposals\nLarge preimage proposals allow for submitters to stream in a large preimage over multiple transactions, along-side\ncommitments to the intermediate state of the keccak256 function after absorbing/permuting the bit block.\nThis data is progressively merkleized on-chain as it is streamed in, with each leaf constructed as follows:\n/// @notice Returns a leaf hash to add to a preimage proposal merkle tree.\n/// @param input A single 136 byte chunk of the input.\n/// @param blockIndex The index of the block that `input` corresponds to in the full preimage's absorption.\n/// @param stateCommitment The hash of the full 5x5 state matrix *after* absorbing and permuting `input`.\nfunction hashLeaf(\n bytes memory input,\n uint256 blockIndex,\n bytes32 stateCommitment\n) internal view returns (bytes32 leaf) {\n require(input.length == 136, \"input must be exactly the size of the keccak256 rate\");\n\n leaf = keccak256(abi.encodePacked(input, blockIndex, stateCommitment));\n}\n\nOnce the full preimage and all intermediate state commitments have been posted, the large preimage proposal enters a\nchallenge period. During this time, a challenger can reconstruct the merkle tree that was progressively built on-chain\nlocally by scanning the block bodies that contain the proposer's leaf preimages. If they detect that a commitment to\nthe intermediate state of the hash function is incorrect at any step, they may perform a single-step dispute for the\nproposal in the PreimageOracle. This involves:\n\nCreating a merkle proof for the agreed upon prestate leaf (not necessary if the invalid leaf is the first one, the\nsetup state of the matrix is constant.) within the proposal's merkle root.\nCreating a merkle proof for the disputed post state leaf within the proposal's merkle root.\nComputing the state matrix at the agreed upon prestate (not necessary if the invalid leaf is the first one, the\nsetup state of the matrix is constant.)\n\nThe challenger then submits this data to the PreimageOracle, where the post state leaf's claimed input is absorbed into\nthe pre state leaf's state matrix and the SHA3 permutation is executed on-chain. After that, the resulting state matrix\nis hashed and compared with the proposer's claim in the post state leaf. If the hash does not match, the proposal\nis marked as challenged, and it may not be finalized. If, after the challenge period is concluded, a proposal has no\nchallenges, it may be finalized and the preimage part may be placed into the authorized mappings for the FPVM to read.\nTeam Dynamics\nChallengers seek to dispute the root claim, while Defenders aim to support it.\nBoth types of actors will move accordingly to support their team. For Challengers, this means\nattacking the root claim and disputing claims positioned at even depths in the Game Tree.\nDefenders do the opposite by disputing claims positioned at odd depths.\nPlayers on either team are motivated to support the actions of their teammates.\nThis involves countering disputes against claims made by their team (assuming these claims are honest).\nUncontested claims are likely to result in a loss, as explained later under Resolution.\nGame Clock\nEvery claim in the game has a Clock. A claim inherits the clock of its grandparent claim in the\nDAG (and so on). Akin to a chess clock, it keeps track of the total time each team takes to make\nmoves, preventing delays. Making a move resumes the clock for the disputed claim and pauses it for the newly added one.\nIf a move is performed, where the potential grandchild's clock has less time than CLOCK_EXTENSION seconds remaining,\nthe potential grandchild's clock is granted exactly CLOCK_EXTENSION seconds remaining. This is to combat the situation\nwhere a challenger must inherit a malicious party's clock when countering a freeloader claim, in\norder to preserve incentive compatibility for the honest party. As the extension only applies to the potential\ngrandchild's clock, the max possible extension for the game is bounded, and scales with the MAX_GAME_DEPTH.\nIf the potential grandchild is an execution trace bisection root claim and their clock has less than CLOCK_EXTENSION\nseconds remaining, exactly CLOCK_EXTENSION * 2 seconds are allocated for the potential grandchild. This extra time\nis allotted to allow for completion of the off-chain FPVM run to generate the initial instruction trace.\nA move against a particular claim is no longer possible once the parent of the disputed claim's Clock\nhas accumulated MAX_CLOCK_DURATION seconds. By which point, the claim's clock has expired.\nResolution\nResolving the FDG determines which team won the game. To do this, we use the internal sub game structure.\nEach claim within the game is the root of its own sub game. These subgames are modeled as nested DAGs, each with a max\ndepth of 1. In order for a claim to be considered countered, only one of its children must be uncountered. Subgames\ncan also not be resolved until all of their children, which are subgames themselves, have been resolved and\nthe potential opponent's chess clock has run out. To determine if the potential opponent's chess clock has ran out, and\ntherefore no more moves against the subgame are possible, the duration elapsed on the subgame root's parent clock is\nadded to the difference between the current time and the timestamp of the subgame root's creation. Because each claim\nis the root of its own sub-game, truth percolates upwards towards the root claim by resolving each individual sub-game\nbottom-up.\nIn a game like the one below, we can resolve up from the deepest subgames. Here, we'd resolve b0\nto uncountered and a0 to countered by walking up from their deepest children, and once all children of the\nroot game are recursively resolved, we can resolve the root to countered due to b0 remaining uncountered.\n\nhttps://github.com/ethereum-optimism/optimism/assets/8406232/d2b708a0-539e-439d-96bd-c2f66f3a45f8\nAnother example is this game, which has a slightly different structure. Here, the root claim will also\nbe countered due to b0 remaining uncountered.\n\nGiven these rules, players are motivated to move quickly to challenge all dishonest claims.\nEach move bisects the historical state of L2 and eventually, MAX_GAME_DEPTH is reached where disputes\ncan be settled conclusively. Dishonest players are disincentivized to participate, via backwards induction,\nas an invalid claim won't remain uncontested. Further incentives can be added to the game by requiring\nclaims to be bonded, while rewarding game winners using the bonds of dishonest claims.\nResolving the L2 Block Number Challenge\nThe resolution of an L2 block number challenge occurs in the same manner as subgame resolution, with one caveat;\nthe L2 block number challenger, if it exist, must be the winner of a root subgame.\nThus, no moves against the root, including uncontested ones, can win a root subgame that has an L2 block number challenge.\nFinalization\nOnce the game is resolved, it must wait for the disputeGameFinalityDelaySeconds on the OptimismPortal to pass before\nit can be finalized, after which bonds can be distributed via the process outlined in Bond Incentives: Game\nFinalization.","tokens":5894,"squid":"ink-governance","role":"Council Listener","at":1791261410431,"hash":"a68a093c0a47f25a10deb14a41f4814ceaa61f78"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/gas-and-fees","domain":"docs.arbitrum.io","title":"Gas and fees | Arbitrum Docs","text":"✏️Request an updateArbitrum uses gas to track the execution cost on an Arbitrum Nitro chain. It works the same as Ethereum gas, in the sense that every EVM instruction costs the same amount of gas as it would on Ethereum.\nThere are two parties a user pays when submitting a transaction:\n\nPoster: If reimbursable, covers the parent chain resources such as the parent chain calldata needed to post the transaction.\nNetwork fee account: Covers the child chain's resources, including computation, storage, and other burdens that child chain nodes must bear to service transactions.\n\nThe parent chain component is the product of the transaction's estimated contribution to its batch's size—computed using Brotli on the transaction alone—and the child chain's view of the parent chain data price. This value dynamically adjusts over time to ensure the batch poster is ultimately fairly compensated.\nThe child chain component consists of the traditional fees Geth would pay to bonders in a vanilla parent chain, such as the computation and storage charges that apply to the State Transition Function (STF). ArbOS charges additional fees for executing its child-chain-specific precompiles, whose fees are dynamically priced based on the resources used during execution.\nThe following sections detail how parent and child chain fees are calculated. For a practical guide on estimating gas for your transactions, see How to estimate gas in Arbitrum.\nParent chain gas pricing​\nArbOS dynamically prices the parent chain gas, with the price adjusting to ensure that the amount collected in the parent chain gas fees is as close as possible to the costs that must be covered, over time.\nChallenges in pricing parent chain resources​\nThere are two main challenges in accurately pricing parent chain resources:\n1. Apportioning batch costs among transactions​\n\nCompression complexity: The data posted to the parent chain is compressed using a general-purpose compression algorithm (Brotli). The effectiveness of compression depends on shared patterns among transactions in a batch.\nContribution estimation: It's difficult to determine how much a specific transaction contributes to the batch's overall compressibility.\nIdeal vs. practical: Ideally, transactions that enhance compressibility would get charged less, but there's no efficient way to calculate this precisely within the constraints of the STF.\n\n2. Assessing parent chain fees at sequencing time​\n\nDeterminism requirement: The parent chain fee for a transaction must be known when the transaction is sequenced to maintain the STF's determinism.\nFuture uncertainty: At sequencing time, the actual cost of the batch is unknown because it depends on the parent chain base fee at the future time of batch posting and the remaining contents of the batch (which affect its size and compressibility).\nImpossibility of exact charges: Charging based on future information is not feasible, so the system must rely on estimations.\n\nNitro's approach​\nTo overcome these challenges, Arbitrum Nitro implements a two-fold strategy:\n\nEstimated relative footprint: An estimated size is calculated for each transaction, measured in data units, to approximate its impact on batch size.\nAdaptive fee per data unit: A dynamic fee per data unit adjusts over time to align collected fees with actual costs.\n\nParent chain costs​\nThere are two types of parent chain costs: batch posting costs and rewards.\nBatch posting costs reflect the actual cost a batch poster pays to post batch data on the parent chain. Whenever a batch is posted, the parent chain contract that records it will send a special \"batch posting report\" message to the child chain ArbOS, reporting who paid for the batch and the parent chain basefee at the time. This message is placed in the chain's delayed inbox so that it will be delivered to the child chain ArbOS after some delay.\nWhen a batch posting report message arrives at the child chain, ArbOS computes the cost of the referenced batch by multiplying the reported basefee by the batch's data cost. (ArbOS retrieves the batch's data from its inbox state and computes the parent chain gas the batch would have used by counting the number of zero bytes and non-zero bytes in the batch.) The pricer records the resulting cost as funds due to the party who is reported to have submitted the batch.\nThe second type of parent chain cost is an optional (per chain) per-unit reward for handling transaction calldata. In general, the reward might be paid to the Sequencer, or to members of the Data Availability Committee in an AnyTrust chain, or to anyone else who incurs per-calldata-byte costs on behalf of the chain. The reward is a fixed number of wei per data unit, and is paid to a single address.\nThe parent chain pricer keeps track of funds due to the reward address based on the number of data units processed so far. This amount is updated whenever a batch posting report arrives at the child chain.\nApportioning costs among transactions​\nTo approximate each transaction's contribution to parent chain costs:\n\nEach transaction is individually compressed using the Brotli compressor at its lowest compression level (fastest setting). This reduces computational overhead within the STF.\nThe size of the compressed transaction is multiplied by 16 (since Ethereum charges 16 gas per non-zero byte). This product represents the transaction's estimated footprint in data units.\nWhile not exact, this method approximates the transaction's size after full batch compression and is computationally efficient for real-time processing.\n\nParent chain calldata fees​\nThe parent chain calldata fees exist because the Sequencer, or the batch poster that posts the Sequencer's transaction batches on Ethereum, incurs parent chain gas costs to post transactions on Ethereum as calldata. Funds collected in the parent chain calldata fees are credited to the batch poster to cover its costs.\nEvery transaction that comes in through the Sequencer will pay a parent chain calldata fee. Transactions that come in through the delayed inbox do not pay this fee because they don't add to batch posting costs—but these transactions pay gas fees to Ethereum when they are put into the delayed inbox.\nThe parent chain pricing algorithm assigns a parent chain calldata fee to each Sequencer transaction. First, it computes the transaction's size, an estimate of how many bytes the transaction will add to the compressed batch it is in; the formula includes an estimate of the transaction's compressibility.\nSecond, it multiplies the computed size estimate by the current price per estimated byte to determine the transaction's parent chain calldata cost in wei. Finally, it divides this cost by the current child chain basefee to convert the fee into child chain gas units. The result is reported as the \"poster fee\" for the transaction.\nThe price per estimated byte is set by a dynamic algorithm that compares the total parent-chain calldata fees collected to the total fees actually paid by batch posters and tries to bring the two as close to equality as possible. If batch poster costs are less than fee receipts, the price will increase; if they exceed fee receipts, the price will decrease.\nAdaptive pricing algorithm​\nTo align collected fees with actual costs, Arbitrum uses an adaptive algorithm with two primary goals:\n\nCost alignment: Minimize the long-term difference between collected fees and the Sequencer's parent chain costs.\nStability: Avoid sudden fluctuations in the data price, ensuring a stable fee environment.\n\nPricer components​\nThe pricer module within ArbOS tracks:\n\nAmount owed to the Sequencer: The cumulative parent chain costs incurred by the Sequencer for batch posting.\nReimbursement fund: Collects all funds charged to transactions for parent chain fees. Acts as a pool to reimburse the Sequencer.\nData unit count: The total number of recent data units processed, which increases with each transaction's estimated data units.\nCurrent parent chain data unit price: The adaptive fee per data unit expressed in wei.\n\nAlgorithm for price adjustment​\nWhen the Sequencer posts a batch to the parent chain inbox:\n\nBatch posting report generation: The parent chain inbox inserts a \"batch posting report\" transaction into the chain's Delayed Inbox. After a delay, this report is processed by ArbOS's pricer module.\n\nProcessing the batch posting report:\n\nCompute batch cost: ArbOS calculates the actual cost of posting the batch by retrieving the batch data from the inbox state and counting zero and non-zero bytes to determine parent chain gas usage. The cost is added to the amount owed to the Sequencer.\n\nUpdate data units: Calculate the data units assigned to this update (Uupd)(U_{\\text{upd}}):\nUupd=U×Tupd−TprevT−TprevU_{\\text{upd}} = U \\times \\frac{T_{\\text{upd}} - T_{\\text{prev}}}{T - T_{\\text{prev}}}\nWhere UU is total recent data units, TT is the current time, TupdT_{\\text{upd}} is the time when the update occurred, and TprevT_{\\text{prev}} is the time of the previous update. Subtract UupdU_{\\text{upd}} from the total UU.\n\nReimburse the Sequencer: Pay the Sequencer from the reimbursement fund. The amount paid is the lesser of the amount owed or the fund balance. Deduct the paid amount from both the reimbursement fund and the amount owed.\n\nCompute surplus and derivative:\nSurplus (SS):\nS=Reimbursement Fund Balance−Amount OwedS = \\text{Reimbursement Fund Balance} - \\text{Amount Owed}\nDerivative of surplus (DD):\nD=S−SprevUupdD = \\frac{S - S_{\\text{prev}}}{U_{\\text{upd}}} where SprevS_{\\text{prev}} is the surplus at the previous update.\n\nCompute derivative goal (D′D'): Establish a target derivative to eliminate surplus over time:\nD′=−SED' = -\\frac{S}{E} where EE is the equilibration constant (time horizon for balancing surplus).\n\nAdjust price (ΔP\\Delta P): Calculate the change in the data unit price:\nΔP=(D′−D)×Uupdα+Uupd\\Delta P = \\frac{(D' - D) \\times U_{\\text{upd}}}{\\alpha + U_{\\text{upd}}}\nWhere α\\alpha is a smoothing parameter to prevent abrupt changes.\nUpdate the price:\nP=max⁡(0,Pprev+ΔP)P = \\max(0, P_{\\text{prev}} + \\Delta P)\n\nOutcome: The adaptive algorithm adjusts the parent chain data unit price to align collected fees with actual costs, ensuring that the Sequencer gets fairly reimbursed while avoiding surpluses or deficits.\n\nCompression levels​\nFor an operational overview of how the Sequencer applies these levels, see Compression. Dynamic adjustments of compression levels are based on backlog size (BB):\n\nCompression level (CLCL) (where UCUC is the user-configured compression level):\n\nFor B≤20B \\leq 20: CL=min⁡(6,UC)CL = \\min(6, UC)\nFor 20<B<6020 < B < 60: CL=UCCL = UC\nFor B>60B > 60: CL=min⁡(4,UC)CL = \\min(4, UC)\n\nRecompression level (RLRL):\n\nFor B<40B < 40: RL=UCRL = UC\nFor B≥40B \\geq 40: RL=min⁡(6,UC)RL = \\min(6, UC)\n\nRecompression of existing batch segments may occur if the batch exceeds maximum size limits or hasn't been properly closed.\nParent chain fee collection​\nA transaction is charged for the parent chain gas if and only if it arrived as part of a sequencer batch. This means that someone would have paid for the parent chain gas to post the transaction on the parent chain.\nThe estimated cost of posting a transaction on the parent chain is the product of the transaction's estimated size and the current parent chain gas basefee. This estimated cost is divided by the current child-chain gas used for the parent-chain operation (see Understanding Arbitrum 2-dimensional fees for more information).\nThe estimated size is measured in the parent chain gas. It is calculated as follows: first, compress the transaction's data using the Brotli-zero algorithm, then multiply the size of the result by 16 (because the parent chain charges 16 gas per byte—the parent chain charges less for bytes that are zero, but that doesn't apply here).\nBrotli-zero is used to reward users for posting compressible transactions. Ideally, we would like to reward for posting transactions that contribute to the compressibility (using the Brotli compressor) of the entire batch, but that is a difficult notion to define and, in any case, would be too expensive to compute at the child chain. Brotli-zero is an approximation that is cheap to compute.\nParent chain gas fee funds collected from transactions are transferred to a special L1PricerFundsPool account, so that account's balance represents the funds collected and available to pay for costs.\nThe parent chain pricer also records the total number of \"data units\" (the sum of the estimated sizes, multiplied by 16) received.\nChild chain gas pricing​\nThe child chain gas price on a given Arbitrum chain has a set floor, which can be queried via ArbGasInfo's getMinimumGasPrice method.\nEstimating child chain gas​\nCalling the Arbitrum Node's eth_estimateGas RPC returns a value sufficient to cover the full transaction fee at the given child chain gas price; i.e., the value returned from eth_estimateGas multiplied by the child chain gas price tells you how much total ETH is required for the transaction to succeed.\nThis means that, for a given operation, the value returned by eth_estimateGas will change over time (as the parent chain's calldata price fluctuates). (See 2-dimensional fees and How to estimate gas in Arbitrum for more.)\nChild chain gas fees​\nChild chain gas fees work similarly to Ethereum: a transaction consumes gas, which is multiplied by the current basefee per gas to determine the child chain transaction fee (denominated in gwei).\nThe basefee is set by a pricing algorithm that governs fees across multiple adjustment windows. This algorithm uses several gas targets, each paired with its own adjustment window. Higher targets with shorter windows (for example, 60 Mgas/s over nine seconds) absorb transient demand spikes without triggering aggressive fee increases. Lower targets with longer windows address slower traffic, with the lowest target measured over 86,400 seconds (one day), establishing the chain's long-term capacity.\nFrom the users' perspective, this means that the network will charge an increasing amount for each additional amount of gas consumed above the target. For example, a 10% fee is levied for going 1% over the target. The fee rises to 15% if you go to 2% over the target, and so on.\nThe algorithm tracks a gas backlog for each target. Whenever a transaction consumes gas, that gas is added to the backlog. Each second, the corresponding gas target is subtracted from its backlog (the backlog cannot go below zero). If the backlog grows, the basefee increases exponentially to discourage usage; if the backlog shrinks, the basefee decreases to incentivize more demand. This behavior is intended to bring the chain's usage to an equilibrium defined by the long-term gas target.\nThis layered structure creates a dampening effect: overlapping windows smooth volatility at their respective timescales, reducing peak gas prices during congestion while preserving responsiveness to genuine capacity constraints.\nFor more details on how gas targets affect chain security and validator assumptions, see the gas target section below.\nChild chain tips​\nWhether a tip does anything depends on the chain's transaction ordering policy and on whether the chain collects tips at all. Today, the only ordering policy that uses tips to define order is PGA. Two settings control this, and a chain needs both before a tip changes anything:\n\nTip collection. ArbOS 61 added setCollectTips on the ArbOwner precompile. It ships disabled. Until a chain owner enables it, the chain ignores the tip and the sender pays the basefee alone.\nOrdering that reads the tip. The sequencer must run an ordering policy that sorts on the PriorityFee field.\n\nThat gives three outcomes:\nChain configurationWhat a tip doesFCFS, tips not collectedNothing. Arrival time sets the order, and the sender pays the basefee.PGA, tips collectedThe tip sets the ordering position and the chain collects it.\nUnder PGA, the sequencer keys its priority queue on the priority fee, computed per EIP-1559 as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas). Paying more moves a transaction up the queue; it never lowers the basefee the transaction owes. A transaction that pays no tip still gets included, because the anti-starvation boost raises its position each round.\nArbitrum One runs PGA and collects tips, sending 97% of the proceeds to the Arbitrum DAO treasury and 3% to the Arbitrum Developer Guild. To turn either setting on for your own chain, see Priority fees collection and PGA for Arbitrum chains.\nGas estimating retryables​\nWhen a transaction schedules another, the cost of the subsequent transaction's execution will be included in the gas estimation via the node's RPC. A transaction's gas estimate can only be found if all the transactions succeed at a given gas limit. This is especially important when working with retryables and scheduling redeem attempts.\nBecause a call to redeem donates all of the call's gas, doing multiple calls requires limiting the amount of gas provided to each subcall. Otherwise, the first will take all the gas and force the second to fail, irrespective of the estimation's gas limit.\nGas estimation for retryable submissions is possible via the NodeInterface and similarly requires the auto-redeem attempt to succeed.\nThe gas target​\nThe security of Arbitrum Nitro chains depends on the assumption that when one validator creates an assertion, other validators check it and respond with a correct assertion or a challenge if it's wrong.\nThis requires that the other validators have the time and resources to check each assertion quickly enough to issue a timely challenge. The Arbitrum protocol takes this into account when setting deadlines for assertions.\nThis sets an effective gas target for executing an Arbitrum Nitro chain: in the long run, the chain cannot make progress faster than a validator can emulate its execution. If assertions are published faster than the gas target, their deadlines will get farther and farther into the future. Due to the limit enforced by the Rollup protocol contracts on how far in the future a deadline can be, this will eventually slow down new assertions, thereby enforcing the effective gas target.\nSetting the gas target accurately depends on estimating the time required to validate an assertion with some accuracy. Any uncertainty in estimating validation time will force us to set the gas target lower, to be safe. And we do not want to set the gas target lower, so we try to enable accurate estimation.\nTotal fee and gas estimation​\nThe total fee charged to a transaction is the child chain basefee multiplied by the sum of the child chain gas used and the parent chain calldata charge.\nAs on Ethereum, a transaction fails if it does not supply enough gas or specifies a basefee limit below the current basefee. Ethereum also allows a \"tip.\" A Nitro chain ignores that field unless the chain owner enables tip collection, and the tip changes the ordering only under PGA. See Child chain tips.\nAllocating funds and paying what is owed​\nWhen a batch posting report is processed in the child chain, the pricer allocates some of the collected funds to cover costs incurred. To allocate funds, the pricer considers three timestamps:\n\ncurrentTime is the current time, when the batch posting report message arrives at the child chain\nupdateTime is the time at which the reported batch was submitted (which will typically be around 20 minutes before currentTime)\nlastUpdateTime is the time of submission for the previous reported batch\n\nThe pricer computes an allocation fraction F = (updateTime-lastUpdateTime) / (currentTime-lastUpdateTime) and allocates a fraction F of funds in the L1PricerFundsPool to the current report. The intuition is that the pricer knows how many funds have been collected between lastUpdateTime and currentTime, and we want to figure out how many of those funds to allocate to the interval between lastUpdateTime and updateTime. The given formula is correct if we assume that funds arrived at a uniform rate over the interval between lastUpdateTime and currentTime. The pricer similarly allocates a portion of the total data units to the current report.\nNow the pricer pays out the allocated funds to cover the rewards due and the amounts due to batch posters, thereby reducing the balance due to each party. If the allocated funds aren't sufficient to cover everything that is due, some amount will remain due. If the amount due is covered with the allocated funds, any remaining funds are returned to the L1PricerFundsPool.\nGetting parent chain fee info​\nThe parent chain gas basefee can be queried via ArbGasInfo.getL1BaseFeeEstimate. To estimate the parent chain fee a transaction will use, call NodeInterface.gasEstimateComponents() or NodeInterface.gasEstimateL1Component().\nArbitrum transaction receipts include a gasUsedForL1 field that shows the amount of gas used on the parent chain, in units of the child chain's gas.\nAdjusting the parent chain gas basefee​\nAfter allocating funds and paying what is owed, the parent chain pricer adjusts the parent chain gas basefee. The goal of this process is to find a value that, over time, causes the amount collected to equal the amount owed.\nThe algorithm first computes the surplus (funds in the L1PricerFundsPool, minus total funds due), which might be negative. If the surplus is positive, the parent chain gas basefee is reduced so that exactly the surplus will reduce the amount collected over a fixed future interval. If the surplus is negative, the basefee is increased so that the shortfall is eliminated over the same fixed future interval.\nA second term is added to the parent chain gas basefee, based on the derivative of the surplus (surplus at present, minus the surplus after the previous batch posting report was processed). This term, which is multiplied by a smoothing factor to reduce fluctuations, will reduce the basefee if the surplus is increasing, and increase the basefee if the surplus is shrinking.\nEffective block gas limit​\nPost-Fusaka, the block gas limit and transaction filtering have changed. Instead of using a hard limit of 32M (Arbitrum One), a new \"Effective Block Gas Limit\" has been introduced. For the underlying gas-pool and per-block-limit mechanics in ArbOS, see the ArbOS technical reference.\nFiltering​\nArbOS 51 also introduces a MaxTxGasLimit. The State Transition Function (STF) will be relaxed to allow the final transaction in a block to use up to the MaxTxGasLimit even if it would cause the block to exceed the MaxBlockGasLimit.\nnoteThe MaxTxGasLimit is set by implementing EIP-7825 from the Fusaka hard fork.\nThis means that the \"Effective Block Gas Limit\" is really MaxBlockGasLimit + MaxTxGasLimit (64M for Arbitrum One). In previous versions of ArbOS, the STF would skip transactions from the sequencer feed if the transaction's GasLimit (set by the user) minus the L1 data posting gas exceeded the gas remaining in the block (without executing the transaction to see how much L2 gas it actually used).\nThe new algorithm is more efficient because the STF doesn't need to continually search the transaction queue for one that fits in the remaining block gas, and can just keep adding transactions until the unused block gas is 0.\nnoteThis change does not affect the GasTarget, and therefore does not affect how much overall gas per second the chain will use—only how transactions using that gas could be divided between different blocks.\nHow a block closes under PGA​\nOn a chain running PGA, the gas limits above are one of three conditions that close a block. The sequencer seals a block when it reaches the first of:\n\nThe 32 Mgas gas target, with the 64 Mgas effective limit described above and a 32 Mgas cap on any single transaction.\nA calldata limit of 95,000 bytes.\nThe end of the block's last ordering round.\n\nA block that fills before its last round is finalized right away rather than idling, so a chain under load produces blocks faster than its nominal block time. On Arbitrum One that means 4 to 8 blocks per second. This changes how gas is divided between blocks, not how much gas per second the chain spends: the gas target still governs that. Block creation under PGA covers the round mechanics.Parent chain gas pricingChallenges in pricing parent chain resourcesNitro's approachParent chain costsApportioning costs among transactionsParent chain calldata feesAdaptive pricing algorithmParent chain fee collectionChild chain gas pricingEstimating child chain gasChild chain gas feesChild chain tipsGas estimating retryablesThe gas targetTotal fee and gas estimationAllocating funds and paying what is owedGetting parent chain fee infoAdjusting the parent chain gas basefeeEffective block gas limitFilteringHow a block closes under PGA","tokens":6210,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261434076,"hash":"aa841f92776ad3cc04b6c1b50ad40121dc4b3a07"}
{"url":"https://specs.optimism.io/fault-proof/index.html","domain":"specs.optimism.io","title":"Fault Proof - OP Stack Specification","text":"Fault Proof\n\nTable of Contents\n\nOverview\nPre-image Oracle\n\nPre-image key types\n\nType 0: Zero key\nType 1: Local key\nType 2: Global keccak256 key\nType 3: Global generic key\nType 4: Global SHA2-256 key\nType 5: Global EIP-4844 Point-evaluation key\nType 6: Global Precompile key\nType 7-128: reserved range\nType 129-255: application usage\n\nBootstrapping\nHinting\nPre-image communication\n\nFault Proof Program\n\nPrologue\nMain content\nEpilogue\nPre-image hinting routes\n\nl1-block-header <blockhash>\nl1-transactions <blockhash>\nl1-receipts <blockhash>\nl1-blob <blobhash ++ metadata>\nl1-precompile-v2 <address ++ requiredGas ++ inputbytes>\nl2-block-header <blockhash> <chainID>?\nl2-transactions <blockhash> <chainID>?\nl2-receipts <blockhash> <chainID>\nl2-code <codehash> <chainID>?\nl2-state-node <nodehash> <chainID>?\nl2-output <outputroot> <chainID>?\nl2-payload-witness <payload_attributes>\nl2-account-proof <blockhash_and_address>\nl2-block-data <blockhash>\n\nPrecompile Accelerators\n\nFault Proof VM\nFault Proof Interactive Dispute Game\n\nOverview\nA fault proof, also known as fraud proof or interactive game, consists of 3 components:\n\nProgram: given a commitment to all rollup inputs (L1 data) and the dispute, verify the dispute statelessly.\nVM: given a stateless program and its inputs, trace any instruction step, and prove it on L1.\nInteractive Dispute Game: bisect a dispute down to a single instruction, and resolve the base-case using the VM.\n\nEach of these 3 components may have different implementations, which can be combined into different proof stacks,\nand contribute to proof diversity when resolving a dispute.\n\"Stateless execution\" of the program, and its individual instructions, refers to reproducing\nthe exact same computation by authenticating the inputs with a Pre-image Oracle.\n\nPre-image Oracle\nThe pre-image oracle is the only form of communication between\nthe Program (in the Client role) and the VM (in the Server role).\nThe program uses the pre-image oracle to query any input data that is understood to be available to the user:\n\nThe initial inputs to bootstrap the program. See Bootstrapping.\nExternal data not already part of the program code. See Pre-image hinting routes.\n\nThe communication happens over a simple request-response wire protocol,\nsee Pre-image communication.\nPre-image key types\nPre-images are identified by a bytes32 type-prefixed key:\n\nThe first byte identifies the type of request.\nThe remaining 31 bytes identify the pre-image key.\n\nType 0: Zero key\nThe zero prefix is illegal. This ensures all pre-image keys are non-zero,\nenabling storage lookup optimizations and avoiding easy mistakes with invalid zeroed keys in the EVM.\nType 1: Local key\nInformation specific to the dispute: the remainder of the key may be an index, a string, a hash, etc.\nOnly the contract(s) managing this dispute instance may serve the value for this key:\nit is localized and context-dependent.\nThis type of key is used for program bootstrapping, to identify the initial input arguments by index or name.\nType 2: Global keccak256 key\nThis type of key uses a global pre-image store contract, and is fully context-independent and permissionless.\nI.e. every key must have a single unique value, regardless of chain history or time.\nUsing a global store reduces duplicate pre-image registration work,\nand avoids unnecessary contract redeployments per dispute.\nThis global store contract should be non-upgradeable.\nSince keccak256 is a safe 32-byte hash input, the first byte is overwritten with a 2 to derive the key,\nwhile keeping the rest of the key \"readable\" (matching the original hash).\nType 3: Global generic key\nReserved. This scheme allows for unlimited application-layer pre-image types without fault-proof VM redeployments.\nThis is a generic version of a global key store: key = 0x03 ++ keccak256(x, sender)[1:], where:\n\nx is a bytes32, which can be a hash of an arbitrary-length type of cryptographically secure commitment.\nsender is a bytes32 identifying the pre-image inserter address (left-padded to 32 bytes)\n\nThis global store contract should be non-upgradeable.\nThe global contract is permissionless: users can standardize around external contracts that verify pre-images\n(i.e. a specific sender will always be trusted for a specific kind of pre-image).\nThe external contract verifies the pre-image before inserting it into the global store for usage by all\nfault proof VMs without requiring the VM or global store contract to be changed.\nUsers may standardize around upgradeable external pre-image contracts,\nin case the implementation of the verification of the pre-image is expected to change.\nThe store update function is update(x bytes32, offset uint64, span uint8, value bytes32):\n\nx is the bytes32 x that the pre-image key is computed with.\nOnly part of the pre-image, starting at offset, and up to (incl.) 32 bytes span can be inserted at a time.\nPre-images may have an undefined length (e.g. a stream), we only need to know how many bytes of value are usable.\nThe key and offset will be hashed together to uniquely store the value and span, for later pre-image serving.\n\nThis enables fault proof programs to adopt any new pre-image schemes without VM update or contract redeployment.\nIt is up to the user to index the special pre-image values by this key scheme,\nas there is no way to revert it to the original commitment without knowing said commitment or value.\nType 4: Global SHA2-256 key\nA SHA-256 pre-image.\nKey: the SHA-256 hash, with the first byte overwritten with the type byte: 4 ++ sha256(data)[1:].\nType 5: Global EIP-4844 Point-evaluation key\nAn EIP-4844 point-evaluation.\nIn an EIP-4844 blob, 4096 field elements represent the blob data.\nIt verifies p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof.\nThe value y is the pre-image.\nThe value z is part of the key; the index of the point within the blob.\nThe commitment is part of the key.\nEach element is proven with a point-evaluation.\nKey: 5 ++ keccak256(commitment ++ z)[1:], where:\n\n5 is the type byte\n++ is concatenation\ncommitment is a bytes48, representing the KZG commitment.\nz is a big-endian uint256\n\nType 6: Global Precompile key\nA precompile result. It maps directly to precompiles on Ethereum.\nThis preimage key can be used to avoid running expensive precompile operations in the program.\nKey: 6 ++ keccak256(precompile ++ input)[1:], where:\n\n6 is the type byte\n++ is concatenation\nprecompile is the 20-byte address of the precompile contract\ninput is the input to the precompile contract\n\nThe result is identical to that of a call to the precompile contract, prefixed with a revert indicator:\n\nreverted ++ precompile_result.\n\nreverted is a 1-byte indicator with a 0 value if the precompile reverts for the given input, otherwise it's 1.\nType 7-128: reserved range\nRange start and end both inclusive.\nThis range of key types is reserved for future usage by the core protocol.\nE.g. version changes, contract migrations, chain-data, additional core features, etc.\n128 specifically (1000 0000 in binary) is reserved for key-type length-extension\n(reducing the content part to 30 or less key bytes), if the need arises.\nType 129-255: application usage\nThis range of key types may be used by forks or customized versions of the fault proof protocol.\nBootstrapping\nInitial inputs are deterministic, but not necessarily singular or global:\nthere may be multiple different disputes at the same time, each with its own disputed claims and L1 context.\nTo bootstrap, the program requests the initial inputs from the VM, using pre-image key type 1.\nThe VM is aware of the external context, and maps requested pre-image keys based on their type, i.e.\na local lookup for type 1, or global one for 2, and optionally support other key-types.\nHinting\nThere is one more form of optional communication between client and server: pre-image hinting.\nHinting is optional, and is a no-op in a L1 VM implementation.\nThe hint itself comes at very low cost onchain: the hint can be a single write sys-call,\nwhich is instant as the memory to write as hint does not actually need to be loaded as part of the onchain proof.\nHinting allows the program, when generating a proof offchain,\nto instruct the VM what data it is interested in.\nThe VM can choose to execute the requested hint at any time: either locally (for standard requests),\nor in a modular form by redirecting the hint to tooling that may come with the VM program.\nHints do not have to be executed directly: they may first just be logged to show the intents of the program,\nand the latest hint may be buffered for lazy execution, or dropped entirely when in read-only mode (like onchain).\nWhen the pre-image oracle serves a request, and the request cannot be served from an existing collection of pre-images\n(e.g. a local pre-image cache) then the VM can execute the hint to retrieve the missing pre-image(s).\nIt is the responsibility of the program to provide sufficient hinting for every pre-image request.\nSome hints may have to be repeated: the VM only has to execute the last hint when handling a missing pre-image.\nNote that hints may produce multiple pre-images:\ne.g. a hint for an ethereum block with transaction list may prepare pre-images for the header,\neach of the transactions, and the intermediate merkle-nodes that form the transactions-list Merkle Patricia Trie.\nHinting is implemented with a request-acknowledgement wire-protocol over a blocking two-way stream:\n<request> := <length prefix> <hint bytes>\n\n<response> := <ack>\n\n<length prefix> := big-endian uint32 # length of <hint bytes>\n<hint bytes> := byte sequence\n<ack> := 1-byte zero value\n\nThe ack informs the client that the hint has been processed. Servers may respond to hints and pre-image (see below)\nrequests asynchronously as they are on separate streams. To avoid requesting pre-images that are not yet fetched,\nclients should request the pre-image only after it has observed the hint acknowledgement.\nPre-image communication\nPre-images are communicated with a minimal wire-protocol over a blocking two-way stream.\nThis protocol can be implemented with blocking read/write syscalls.\n<request> := <bytes32> # the type-prefixed pre-image key\n\n<response> := <length prefix> <pre-image bytes>\n\n<length prefix> := big-endian uint64 # length of <pre-image bytes>, note: uint64\n\nThe <length prefix> here may be arbitrarily high:\nthe client can stop reading at any time if the required part of the pre-image has been read.\nAfter the client writes new <request> bytes, the server should be prepared to respond with\nthe pre-image starting from offset == 0 upon read calls.\nThe server may limit read results artificially to only a small amount of bytes at a time,\neven though the full pre-image is ready: this is expected regular IO protocol,\nand the client will just have to continue to read the small results at a time,\nuntil 0 bytes are read, indicating EOF.\nThis enables the server to serve e.g. at most 32 bytes at a time or align reads with VM memory structure,\nto limit the amount of VM state that changes per syscall instruction,\nand thus keep the proof size per instruction bounded.\nFault Proof Program\nThe Fault Proof Program defines the verification of claims of the state-transition outputs\nof the L2 rollup as a pure function of L1 data.\nThe op-program is the reference implementation of the program, based on op-node and op-geth implementations.\nThe program consists of:\n\nPrologue: load the inputs, given minimal bootstrapping, with possible test-overrides.\nMain content: process the L2 state-transition, i.e. derive the state changes from the L1 inputs.\nEpilogue: inspect the state changes to verify the claim.\n\nPrologue\nThe program is bootstrapped with two primary inputs:\n\nl1_head: the L1 block hash that will be perceived as the tip of the L1 chain,\nauthenticating all prior L1 history.\ndispute: identity of the claim to verify.\n\nBootstrapping happens through special input requests to the host of the program.\nAdditionally, there are implied inputs, which are derived from the above primary inputs,\nbut can be overridden for testing purposes:\n\nl2_head: the L2 block hash that will be perceived as the previously agreed upon tip of the L2 chain,\nauthenticating all prior L2 history.\nChain configurations: chain configuration may be baked into the program,\nor determined from attributes of the identified dispute on L1.\n\nl1_chain_config: The chain-configuration of the L1 chain (also known as l1_genesis.json)\nl2_chain_config: The chain-configuration of the L2 chain (also known as l2_genesis.json)\nrollup_config: The rollup configuration used by the rollup-node (also known as rollup.json)\n\nThe implied inputs rely on L1-introspection to load attributes of the dispute through the\ndispute game interface, in the L1 history up and till the specified l1_head.\nThe dispute may be the claim itself, or a pointer to specific prior claimed data in L1,\ndepending on the dispute game interface.\nImplied inputs are loaded in a \"prologue\" before the actual core state-transition function executes.\nDuring testing a simplified prologue that loads the overrides may be used.\n\nNote: only the test-prologues are currently supported, since the dispute game interface is actively changing.\n\nMain content\nTo verify a claim about L2 state, the program first reproduces\nthe L2 state by applying L1 data to prior agreed L2 history.\nThis process is also known as the L2 derivation process,\nand matches the processing in the rollup node and\nexecution-engine.\nThe difference is that rather than retrieving inputs from an RPC and applying state changes to disk,\nthe inputs are loaded through the pre-image oracle and the changes accumulate in memory.\nThe derivation executes with two data-sources:\n\nInterface to read-only L1 chain, backed by the pre-image oracle:\n\nThe l1_head determines the view over the available L1 data: no later L1 data is available.\nThe implementation of the chain traverses the header-chain from the l1_head down to serve by-number queries.\nThe l1_head is the L1 unsafe head, safe head, and finalized head.\n\nInterface to L2 engine API\n\nPrior L2 chain history is backed by the pre-image oracle, similar to the L1 chain:\n\nThe initial l2_head determines the view over the initial available L2 history: no later L2 data is available.\nThe implementation of the chain traverses the header-chain from the l2_head down to serve by-number queries.\nThe l2_head is the initial L2 unsafe head, safe head, and finalized head.\n\nNew L2 chain history accumulates in memory.\n\nAlthough the pre-image oracle can be used to retrieve data by hash if memory is limited,\nthe program should prefer to keep the newly created chain data in memory, to minimize pre-image oracle access.\nThe L2 unsafe head, safe head, and finalized L2 head will potentially change as derivation progresses.\nL2 state consists of the diff of changes in memory,\nand any unchanged state nodes accessible through the read-only L2 history view.\n\nSee Pre-image routes for specifications of the pre-image oracle backing of these data sources.\nUsing these data-sources, the derivation pipeline is processed till we hit one of two conditions:\n\nEOF: when we run out of L1 data, the L2 chain will not change further, and the epilogue can start.\nEager epilogue condition: depending on the type of claim to verify,\nif the L2 result is irreversible (i.e. no later L1 inputs can override it),\nthe processing may end early when the result is ready.\nE.g. when asserting state at a specific L2 block, rather than the very tip of the L2 chain.\n\nEpilogue\nWhile the main-content produces the disputed L2 state already,\nthe epilogue concludes what this means for the disputed claim.\nThe program produces a binary output to verify the claim, using a standard single-byte Unix exit-code:\n\na 0 for success, i.e. the claim is correct.\na non-zero code for failure, i.e. the claim is incorrect.\n\n1 should be preferred for identifying an incorrect claim.\nOther non-zero exit codes may indicate runtime failure,\ne.g. a bug in the program code may resolve in a kind of panic or unexpected error.\nSafety should be preferred over liveness in this case, and the claim will fail.\n\nTo assert the disputed claim, the epilogue, like the main content,\ncan introspect L1 and L2 chain data and post-process it further,\nto then make a statement about the claim with the final exit code.\nA disputed output-root may be disproven by first producing the output-root, and then comparing it:\n\nRetrieve the output attributes from the L2 chain view: the state-root, block-hash, withdrawals storage-root.\nCompute the output-root, as the\nproposer should compute it.\nIf the output-root matches the claim, exit with code 0. Otherwise, exit with code 1.\n\nNote: the dispute game interface is actively changing, and may require additional claim assertions.\nthe output-root epilogue may be replaced or extended for general L2 message proving.\n\nPre-image hinting routes\nThe fault proof program implements hint handling for the VM to use,\nas well as any program testing outside of VM environment.\nThis can be exposed via a CLI, or alternative inter-process API.\nEvery instance of <blockhash> in the below routes is 0x-prefixed, lowercase, hex-encoded.\nSome routes below are conditional on the type of state transition the program verifies. \"Super root mode\" means the\nprogram verifies a step of the\nsuper root state transition rather than the\napplication of a single L2 block.\nl1-block-header <blockhash>\nRequests the host to prepare the L1 block header RLP pre-image of the block <blockhash>.\nl1-transactions <blockhash>\nRequests the host to prepare the list of transactions of the L1 block with <blockhash>:\nprepare the RLP pre-images of each of them, including transactions-list MPT nodes.\nl1-receipts <blockhash>\nRequests the host to prepare the list of receipts of the L1 block with <blockhash>:\nprepare the RLP pre-images of each of them, including receipts-list MPT nodes.\nl1-blob <blobhash ++ metadata>\nRequests the host to prepare EIP-4844 blob data for fault proof verification.\nThe hint data consists of 40 bytes concatenated together:\n\nBytes 0-31: Blob version hash (32 bytes) - the keccak256 hash of the KZG commitment with version byte prefix\nBytes 32-39: L1 block timestamp (8-byte big-endian uint64)\n\nThe host will:\n\nFetch the blob from the L1 beacon chain using the timestamp and blob hash\nCompute the KZG commitment and prepare it as a SHA256 preimage\nPrepare all 4096 field elements of the blob as Blob-type preimages,\nkeyed by keccak256(commitment || rootOfUnity[i]) for evaluation at the standard roots of unity\n\nThis hint is required for verifying transactions that use EIP-4844 blob data (post-Ecotone).\nl1-precompile-v2 <address ++ requiredGas ++ inputbytes>\nRequests the host to prepare the result of an L1 precompile call with gas validation.\nThe hint data format:\n\nBytes 0-19: Precompile address (20 bytes)\nBytes 20-27: Required gas (8-byte big-endian uint64)\nBytes 28+: Input bytes\n\nThe host validates the precompile address against an allowlist of accelerated precompiles and\nprepares a precompile-type preimage of the execution result.\nThe requiredGas parameter allows the preimage oracle to enforce complete precompile execution.\nThis supersedes the earlier l1-precompile <precompile ++ inputbytes> format which did not include gas validation.\nl2-block-header <blockhash> <chainID>?\nRequests the host to prepare the L2 block header RLP pre-image of the block <blockhash>.\nThe <chainID> is optionally concatenated after the <blockHash> as a big endian uint64 value to specify which L2\nchain to retrieve data from. <chainID> must be specified in super root mode.\nl2-transactions <blockhash> <chainID>?\nRequests the host to prepare the list of transactions of the L2 block with <blockhash>:\nprepare the RLP pre-images of each of them, including transactions-list MPT nodes.\nThe <chainID> is optionally concatenated after the <blockHash> as a big endian uint64 value to specify which L2\nchain to retrieve data from. <chainID> must be specified in super root mode.\nl2-receipts <blockhash> <chainID>\nRequests the host to prepare the list of receipts of the L2 block with <blockhash> for the specified <chainID>:\nprepare the RLP pre-images of each of them, including receipts-list MPT nodes.\nThis hint is used only when the interop hard fork is active.\nl2-code <codehash> <chainID>?\nRequests the host to prepare the L2 smart-contract code with the given <codehash>.\nThe <chainID> is optionally concatenated after the <blockHash> as a big endian uint64 value to specify which L2\nchain to retrieve data from. <chainID> must be specified in super root mode.\nl2-state-node <nodehash> <chainID>?\nRequests the host to prepare the L2 MPT node preimage with the given <nodehash>.\nThe <chainID> is optionally concatenated after the <blockHash> as a big endian uint64 value to specify which L2\nchain to retrieve data from. <chainID> must be specified in super root mode.\nl2-output <outputroot> <chainID>?\nRequests the host to prepare the L2 Output at the l2 output root <outputroot>.\nThe L2 Output is the preimage of a\ncomputed output root.\nThe <chainID> is optionally concatenated after the <blockHash> as a big endian uint64 value to specify which L2\nchain to retrieve data from. <chainID> must be specified in super root mode.\nl2-payload-witness <payload_attributes>\nRequests the host to prepare all preimages used in the building of the payload specified by <payload_attributes>.\n<payload_attributes> is a JSON object with the fields parentBlockHash, payloadAttributes and optionally chainID.\nThe chainID must be specified in super root mode.\nl2-account-proof <blockhash_and_address>\nRequests the host send account proof for a certain block hash and address. <blockhash_and_address> is hex\nencoded: 32-byte block hash + 20-byte address + 8 byte big endian chain ID.\nl2-payload-witness and l2-account-proof hints are preferred over the more granular l2-code and l2-state-node,\nand they should be sent before the more granular hints to ensure proper handling.\nl2-block-data <blockhash>\nRequests the host to prepare all preimages used in the building of the block specified by <blockhash>.\n<blockhash> is a hex encoded concatenation of the following:\n\n32-byte parent block hash\n32-byte block hash of the block to be prepared\n8-byte big-endian chain ID\n\nThis hint is used only when the interop hard fork is active.\nPrecompile Accelerators\nPrecompiles that are too expensive to be executed in a fault-proof VM can be executed\nmore efficiently using the pre-image oracle.\nThis approach ensures that the fault proof program can complete a state transition in a reasonable\namount of time.\nDuring program execution, the precompiles are substituted with interactions with pre-image oracle.\nThe program hints the host for a precompile input. Which it the subsequently retrieves the result of the precompile\noperation using the type 6 global precompile key.\nAll accelerated precompiles must be functionally equivalent to their EVM equivalent.\nFault Proof VM\nA fault proof VM implements:\n\na smart-contract to verify a single execution-trace step, e.g. a single MIPS instruction.\na CLI command to generate a proof of a single execution-trace step.\na CLI command to compute a VM state-root at step N\n\nA fault proof VM relies on a fault proof program to provide an interface\nfor fetching any missing pre-images based on hints.\nThe VM emulates the program, as prepared for the VM target architecture,\nand generates the state-root or instruction proof data as requested through the VM CLI.\nRefer to the documentation of the fault proof VM for further usage information.\nFault Proof VMs:\n\nCannon: big-endian 64-bit MIPS64 architecture, by OP Labs, in active development.\ncannon-rs: Rust implementation of Cannon, by @clabby, deprecated.\nAsterisc: little-endian 64-bit RISC-V architecture, by @protolambda, in active development.\n\nFault Proof Interactive Dispute Game\nThe interactive dispute game allows actors to resolve a dispute with an onchain challenge-response game\nthat bisects to a disagreed block state transition, and then over the execution trace of the VM\nwhich models this state transition, bounded with a base-case that proves a single VM trace step.\nThe game is multi-player: different non-aligned actors may participate when bonded.\nResponse time is allocated based on the remaining time in the branch of the tree and alignment with the claim.\nThe allocated response time is limited by the dispute-game window,\nand any additional time necessary based on L1 fee changes when bonds are insufficient.\n\nNote: the timed, bonded, bisection dispute game is in development.\nAlso see fault dispute-game specs for fault dispute game system specifications,\nAnd dispute-game-interface specs","tokens":6188,"squid":"ink-governance","role":"Council Listener","at":1791261441644,"hash":"993e7fa430ff8474e90f894bbec015a26df56b44"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/arbos","domain":"docs.arbitrum.io","title":"ArbOS | Arbitrum Docs","text":"✏️Request an updateArbOS is the child-EVM virtual machine monitor (VMM) for Arbitrum Nitro. It's a trusted system component that lives inside the State Transition Function (STF) and provides the execution environment for the chain. Unlike a conventional operating system, ArbOS is not a process running beside the chain—it's ordinary Go code compiled into the STF, so every node (and fraud prover) can replay it deterministically.\nCore responsibilities​\n\nNetwork resource management: Allocating and tracking the required resources to execute child-chain transactions and pricing them.\nBlock production: Turning Sequencer-delivered messages into child-chain blocks with correct state updates.\nCross-chain messaging: Enabling cross-chain communication between parent and child chains for deposits, withdrawals, and retryable tickets.\nEnhanced EVM execution: Running instrumented Geth to execute smart contracts with child-chain specific logic.\nStylus support: Managing host I/O, memory, and execution context for WASM-based contracts.\n\nArchitecture: the Geth \"sandwich\"​\nRather than implementing the EVM, Arbitrum embeds it. The core of execution is still Geth, modified only in minor ways—the same engine that defines the Ethereum standard. ArbOS wraps Geth on both sides, an arrangement we call the sandwich.\n\nTop slice (pre-processing): Before the EVM runs, ArbOS injects a system \"start block\" transaction, fixes the parent-chain context (block number, timestamp, base fee), prices incoming data, and applies any transaction filtering.\nFilling (Geth core): Geth executes EVM transactions.\nBottom slice (post-processing): After the EVM runs, ArbOS settles fees, records cross-chain messages, and finalizes the block.\n\nMessages and blocks​\nSequencer inputs arrive as L1IncomingMessage objects. ArbOS turns each message into exactly one child-chain block—a bijective relationship:\nFor every L1IncomingMessage, there is a child-chain block with a unique block hash, and for every child-chain block after chain initialization, there is an L1IncomingMessage that produced it.\nProduceBlock consumes one message and emits one block. After genesis, each block always begins with an injected ArbitrumInternalTx \"start block\" transaction that stamps in the parent-chain block number, and L1 base fee. Because every value the EVM can observe as \"now\" is frozen into that opening system transaction, two nodes replaying the same message cannot disagree about the result—determinism is structural, not bolted on. ArbOS may include more system transactions during processing, for example batch-posting reports.\nArbOS state​\nArbOS keeps its books in the same Geth state trie that holds account balances, under a reserved system address. The ArbosState object is a typed overlay on that raw key-value store. It is partitioned into subspaces, each identified by a one-byte prefix, and a set of fixed-scalar slots (\"offsets\") at the root.\nMost of this state is reachable from contracts through precompiles. Two components deserve special mention because they back headline features:\n\nsendMerkle is the accumulator that records every L2 → L1 message; its root is what the parent-chain Outbox verifies against when a withdrawal is finalized. See child-to-parent messaging for how a withdrawal proves against that root.\nprograms hold Stylus activation state, which is why WASM contracts can be priced and executed deterministically.\n\nFor the subspace-by-subspace breakdown, including blockhashes, l1PricingState, and l2PricingState, see the ArbOS state reference.\nGas and fees​\n\nChild-chain execution is priced by l2PricingState, which runs a dynamic base-fee mechanism. A gas pool tracks demand across a time window, pushing that base fee up under load and down when idle, smoothing spikes while preserving capacity.\nParent-chain data is tracked by l1PricingState, which records what the batch poster spent posting compressed data to Ethereum and reimburses the batch poster from user fees.\n\nFees are routed to the configured network and infrastructure fee accounts.\nFor the complete breakdown, including the pricing formulas and the per-block gas limit, see Gas and fees. For how ArbOS meters calldata and reimburses the batch poster, see parent chain gas pricing.\nPrecompiles​\nArbOS exposes system functionality to contracts through precompiles—addresses that look like ordinary contracts to Solidity but are implemented in Go. The binding works through runtime reflection:\n\nA Solidity interface defines the ABI.\nA Go backend implements the methods.\nAt startup, ArbOS uses reflection to verify that the Go implementation matches the generated ABI exactly and to route incoming calls to the right method.\n\nThis lets an EVM CALL reach native operating-system code without breaking the EVM’s type and ABI guarantees. Some precompiles (or specific methods) are gated to a minimum ArbOS version.\nFor the reflection and dispatch mechanics, see the precompile architecture reference. For every precompile, its address, and its methods, see the precompiles reference.\nRetryables​\nRetryable tickets are a special message type that enables atomic parent-to-child messaging: a ticket is created on the parent chain and redeemed on the child chain, with funds and execution handled together. Retryable state lives in the retryables subspace. See the parent-to-child messaging documentation for the full lifecycle.\nArbOS versions and upgrades​\nArbOS manages child chain gas pricing and fee collection for both child chain execution costs and parent chain data posting costs. The child chain uses a dynamic basefee mechanism with multiple gas targets over different time windows to handle demand spikes while maintaining long-term chain capacity. Transactions pay fees to both the batch poster (for parent chain data costs) and the network (for child chain execution).\nBecause the STF must stay deterministic across every node and across every historical replay, ArbOS cannot change behavior simply by shipping a new binary—old blocks must still reproduce exactly. Upgrades are therefore scheduled as onchain events.\n\nArbOS stores its current version, the upgradeVersion it plans to move to, and the upgradeTimestamp at which to switch (offsets 0-2 of state).\nAt the appointed time, the storage format and execution semantics roll forward identically across all nodes.\n\nThis is how the chain has evolved over time—for example, Stylus activated at ArbOS version 30—without ever replacing the operating system out from under its own history. Each version bump is gated behind a named constant in the chain parameters, so behavioral changes are tied to a specific, agreed-upon version rather than wall-clock client releases.\nStylus-specific differences​\nStylus extends ArbOS to support WASM-based smart contracts alongside the EVM. When a transaction targets a Stylus contract, ArbOS routes execution to the WASM runtime, which uses host I/O calls for blockchain state access instead of EVM opcodes. Stylus contracts use a multi-dimensional gas model based on Ink units, with LRU caching to minimize execution overhead.\nFor the full technical details of Stylus execution flow, caching, gas pricing, and Go-WASI integration, see the ArbOS technical reference.Core responsibilitiesArchitecture: the Geth \"sandwich\"Messages and blocksArbOS stateGas and feesPrecompilesRetryablesArbOS versions and upgradesStylus-specific differences","tokens":1849,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261445709,"hash":"98cab65bea18a470b82cdc6efe75ff2087db2e77"}
{"url":"https://ethresear.ch/u/leohio","domain":"ethresear.ch","title":"Summary - leohio - Ethereum Research","text":"Skip to profile content\n\n leohio\n\n Leona Hioki\n\n Joined\n\n Jun 20, 2018\n\n Last Post\n\n Feb 6\n\n Seen\n\n Jul 27\n\n Views21089\n Trust Levelmember\n\n Stats\n\n 571\n\n days visited\n\n 2d\n\n read time\n\n 375\n\n topics viewed\n\n 2.4k\n\n posts read\n\n 109\n\n given\n\n 82\n\n received\n\n 14\n\n topics created\n\n 54\n\n posts created\n\n Top Replies\n\n Dec 2023\n ·\n  5\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Jul 2023\n ·\n  5\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n Apr 2024\n ·\n  3\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n May 2024\n ·\n  1\n\n Plasma Next: Plasma without Online Requirements\n\n Apr 2024\n ·\n  1\n\n Plasma Next: Plasma without Online Requirements\n\n Dec 2023\n ·\n  1\n\n Octopus Contract and its Applications\n\n More Replies\n\n Top Topics\n\n Feb 2022\n ·\n  40\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n Feb 2024\n ·\n  12\n\n Plasma Next: Plasma without Online Requirements\n\n Feb 2021\n ·\n  11\n\n A pre-consensus mechanism to secure instant finality and long interval in zkRollup\n\n Oct 2021\n ·\n  10\n\n A zkRollup with no transaction history data to enable secret smart contract execution with calldata efficiency\n\n Oct 2022\n ·\n  6\n\n Intmax: Trustless and near zero gas cost token-transfer/payment system\n\n Jul 2023\n ·\n  4\n\n A subscription protocol with a constant and minimal cost for nodes\n\n More Topics\n\n Top Links\n\n hackmd.io/XolAetXrSDuUgpKBZWaaeg\n\n Intmax: Trustless and near zero gas cost token-transfer/payment system\n\n eprint.iacr.org/2025/1811.pdf\n\n Removing Pairing, Bulletproofs, or ZKP from Range Proof of Pedersen Commitment\n\n hackmd.io/V15bV6AdQqOgQA7FLUfElw\n\n Intmax: Trustless and near zero gas cost token-transfer/payment system\n\n github.com/InternetMaximalism/plasma-next\n\n Plasma Next: Plasma without Online Requirements\n\n github.com/chainwayxyz/bitvm-zk-verifier\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n plasma.io/plasma-deprecated.pdf\n\n Plasma Next: Plasma without Online Requirements\n\n Most Replied To\n\n adompeldorius\n\n Albus Dompeldorius\n\n 8\n\n barryWhiteHat\n\n Barry White Hat\n\n 4\n\n adlerjohn\n\n John Adler\n\n 3\n\n Dobrokhvalov\n\n Mikhail\n\n 2\n\n vbuterin\n\n Vbuterin\n\n 2\n\n StarLI-Trapdoor\n\n Star Li Trapdoor\n\n 2\n\n Most Liked By\n\n serinuntius\n\n Aoi Serikawa\n\n 4\n\n DNALOB\n\n dnalob\n\n 3\n\n ikuma\n\n Ikuma Mutobe\n\n 3\n\n SoraSuegami\n\n Sora Suegami\n\n 3\n\n m0t0k1ch1\n\n Sato Motoki\n\n 2\n\n Globallager\n\n 2\n\n Most Liked\n\n vbuterin\n\n Vbuterin\n\n 31\n\n JustinDrake\n\n Justin Drake\n\n 6\n\n adlerjohn\n\n John Adler\n\n 6\n\n chris.whinfrey\n\n Chris Whinfrey\n\n 5\n\n barryWhiteHat\n\n Barry White Hat\n\n 3\n\n MicahZoltu\n\n Micah Zoltu\n\n 2\n\n Top Categories\n\n Topics\n Replies\n\n Layer 2\n\n 8\n\n 25\n\n Cryptography\n\n 2\n\n 14\n\n Plasma\n\n 2\n\n 8\n\n Privacy\n\n 1\n\n 4\n\n Proof-of-Stake\n\n –\n\n 2\n\n Uncategorized\n\n –\n\n 1\n\n Top Badges\n\n Member\n\n Granted invitations, group messaging, more likes\n\n Great Share\n\n Shared a post with 1000 unique visitors\n\n Good Share\n\n Shared a post with 300 unique visitors\n\n Anniversary\n\n Active member for a year, posted at least once\n\n 7 awarded\n\n Thank You\n\n Has 20 liked posts and gave 10 likes\n\n Appreciated\n\n Received 1 like on 20 posts\n\n More Badges\n\n Powered by Discourse","tokens":783,"squid":"ink-research","role":"Deep Scholar","at":1791261445749,"hash":"d4acdf548eb1e1c1bdf7a26641e79bef78bf549a"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/bond-incentives.html","domain":"specs.optimism.io","title":"Bond Incentives - OP Stack Specification","text":"Bond Incentives\n\nTable of Contents\n\nOverview\nMoves\nSubgame Resolution\n\nLeftmost Claim Incentives\n\nFault Proof Mainnet Incentives\n\nAuthenticated Roles\nBase Fee Assumption\nBond Scaling\nRequired Bond Formula\nOther Incentives\n\nGame Finalization\n\nBond Distribution Mode\n\nNormal Mode\nRefund Mode\n\nGame Closure\nClaiming Credit\nDelayedWETH\n\nSub-Account Model\nDelay Period\nIntegration\n\nOverview\nBonds is an add-on to the core Fault Dispute Game. The core game mechanics are\ndesigned to ensure honesty as the best response to winning subgames. By introducing financial incentives,\nBonds makes it worthwhile for honest challengers to participate.\nWithout the bond reward incentive, the FDG will be too costly for honest players to participate in given the\ncost of verifying and making claims.\nImplementations may allow the FDG to directly receive bonds, or delegate this responsibility to another entity.\nRegardless, there must be a way for the FDG to query and distribute bonds linked to a claim.\nBonds are integrated into the FDG in two areas:\n\nMoves\nSubgame Resolution\n\nMoves\nMoves must be adequately bonded to be added to the FDG. This document does not specify a\nscheme for determining the minimum bond requirement. FDG implementations should define a function\ncomputing the minimum bond requirement with the following signature:\nfunction getRequiredBond(Position _movePosition) public pure returns (uint256 requiredBond_)\n\nAs such, attacking or defending requires a check for the getRequiredBond() amount against the bond\nattached to the move. To incentivize participation, the minimum bond should cover the cost of a possible\ncounter to the move being added. Thus, the minimum bond depends only on the position of the move that's added.\nSubgame Resolution\nIf a subgame root resolves incorrectly, then its bond is distributed to the leftmost claimant that countered\nit. This creates an incentive to identify the earliest point of disagreement in an execution trace.\nThe subgame root claimant gets back its bond iff it resolves correctly.\nAt maximum game depths, where a claimant counters a bonded claim via step, the bond is instead distributed\nto the account that successfully called step.\nLeftmost Claim Incentives\nThere exists defensive positions that cannot be countered, even if they hold invalid claims. These positions\nare located on the same level as honest claims, but situated to its right (i.e. its gindex > honest claim's).\nAn honest challenger can always successfully dispute any sibling claims not positioned to the right of an honest claim.\nThe leftmost payoff rule encourages such disputes, ensuring only one claim is leftmost at correct depths.\nThis claim will be the honest one, and thus bond rewards will be directed exclusively to honest claims.\nFault Proof Mainnet Incentives\nThis section describes the specific bond incentives to be used for the Fault Proof Mainnet launch of the OP Stack fault\nproof system.\nAuthenticated Roles\nNameDescription\nGuardianRole responsible for blacklisting dispute game contracts and changing the respected dispute game type\nSystem OwnerRole that owns the ProxyAdmin contract that in turn owns most Proxy contracts within the OP Stack\n\nBase Fee Assumption\nFPM bonds are to assume a fixed 200 Gwei base fee.\nFuture iterations of the fault proof may include a dynamic base fee calculation.\nFor the moment, we suppose that the Guardian address may account for increased average base fees by updating the\nOptimismPortal contract to a new respected game type with a higher assumed base fee.\nBond Scaling\nFPM bonds are priced in the amount of gas that they are intended to cover.\nBonds start at the very first depth of the game at a baseline of 400_000 gas.\nThe 400_000 value is chosen as a deterrence amount that is approximately double the cost to respond at the top level.\nBonds scale up to a value of 300_000_000 gas, a value chosen to cover approximately double the cost of a max-size\nLarge Preimage Proposal.\nWe use a multiplicative scaling mechanism to guarantee that the ratio between bonds remains constant.\nWe determine the multiplier based on the proposed MAX_DEPTH of 73.\nWe can use the formula x = (300_000_000 / 400_000) ** (1 / 73) to determine that x = 1.09493.\nAt each depth N, the amount of gas charged is therefore 400_000 * (1.09493 ** N)\nBelow is a diagram demonstrating this curve for a max depth of 73.\n\nRequired Bond Formula\nApplying the Base Fee Assumption and Bond Scaling specifications, we have a\ngetRequiredBond function:\ndef get_required_bond(position):\n assumed_gas_price = 200 gwei\n base_gas_charged = 400_000\n gas_charged = 400_000 * (1.09493 ** position.depth)\n return gas_charged * assumed_gas_price\n\nOther Incentives\nThere are other costs associated with participating in the game, including operating a challenger agent and the\nopportunity cost of locking up capital in the dispute game. While we do not explicitly create incentives to cover\nthese costs, we assume that the current bond rewards, based on this specification, are enough as a whole to cover\nall other costs of participation.\nGame Finalization\nAfter the game is resolved, claimants must wait for the AnchorStateRegistry's\nisGameFinalized() to return true before they can claim their bonds. This\nimplies a wait period of at least the disputeGameFinalityDelaySeconds variable from the OptimismPortal contract.\nAfter the game is finalized, bonds can be distributed.\nBond Distribution Mode\nThe FDG will in most cases distribute bonds to the winners of the game after it is resolved and finalized, but in\nspecial cases will refund the bonds to the original depositor.\nNormal Mode\nIn normal mode, the FDG will distribute bonds to the winners of the game after it is resolved and finalized.\nRefund Mode\nIn refund mode, the FDG will refund the bonds to the original depositor.\nGame Closure\nThe FaultDisputeGame contract can be closed after finalization via the closeGame() function.\ncloseGame must do the following:\n\nVerify the game is resolved and finalized according to the Anchor State Registry\nAttempt to set this game as the new anchor game.\nDetermine the bond distribution mode based on whether the AnchorStateRegistry's\nisGameProper() returns true.\nEmit a GameClosed event with the chosen distribution mode.\n\nClaiming Credit\nThere is a 2-step process to claim credit. First, claimCredit(address claimant) should be called to unlock the credit\nfrom the DelayedWETH contract. After DelayedWETH's delay period has passed,\nclaimCredit should be called again to withdraw the credit.\nThe claimCredit(address claimant) function must do the following:\n\nCall closeGame() to determine the distribution mode if not already closed.\n\nIn NORMAL mode: Distribute credit from the standard normalModeCredit mapping.\nIn REFUND mode: Distribute credit from the refundModeCredit mapping.\n\nIf the claimant has not yet unlocked their credit, unlock it by calling DelayedWETH.unlock(claimant, credit).\n\nClaimant must not be able to unlock this credit again.\n\nIf the claimant has already unlocked their credit, call DelayedWETH.withdraw(claimant, credit) (implying a\ndelay period) to withdraw the credit, and set claimant's credit balances to 0.\n\nDelayedWETH\nDelayedWETH is designed to hold the bonded ETH for each\nFault Dispute Game.\nDelayedWETH is an extended version of the standard WETH contract that introduces a delayed unwrap mechanism that\nallows an owner address to function as a backstop in the case that a Fault Dispute Game would\nincorrectly distribute bonds.\nDelayedWETH is modified from WETH as follows:\n\nDelayedWETH is an upgradeable proxy contract.\nDelayedWETH has an owner() address. We typically expect this to be set to the System Owner address.\nDelayedWETH has a delay() function that returns a period of time that withdrawals will be delayed.\nDelayedWETH has an unlock(guy,wad) function that modifies a mapping called withdrawals keyed as\nwithdrawals[msg.sender][guy] => WithdrawalRequest where WithdrawalRequest is\nstruct Withdrawal Request { uint256 amount, uint256 timestamp }. When unlock is called, the timestamp for\nwithdrawals[msg.sender][guy] is set to the current timestamp and the amount is increased by the given amount.\nDelayedWETH modifies the WETH.withdraw function such that an address must provide a \"sub-account\" to withdraw\nfrom. The function signature becomes withdraw(guy,wad). The function retrieves withdrawals[msg.sender][guy] and\nchecks that the current block.timestamp is greater than the timestamp on the withdrawal request plus the delay()\nseconds and reverts if not. It also confirms that the amount being withdrawn is less than the amount in the withdrawal\nrequest. Before completing the withdrawal, it reduces the amount contained within the withdrawal request. The original\nwithdraw(wad) function becomes an alias for withdraw(msg.sender, wad).\nwithdraw(guy,wad) will not be callable when SuperchainConfig.paused() is true.\nDelayedWETH has a hold(guy,wad) function that allows the owner() address to, for any holder, give itself an\nallowance and immediately transferFrom that allowance amount to itself.\nDelayedWETH has a hold(guy) function that allows the owner() address to, for any holder, give itself a full\nallowance of the holder's balance and immediately transferFrom that amount to itself.\nDelayedWETH has a recover() function that allows the owner() address to recover any amount of ETH from the\ncontract.\n\nSub-Account Model\nThis specification requires that withdrawal requests specify \"sub-accounts\" that these requests correspond to. This\ntakes the form of requiring that unlock and withdraw both take an address guy parameter as input. By requiring\nthis extra input, withdrawals are separated between accounts and it is always possible to see how much WETH a specific\nend-user of the FaultDisputeGame can withdraw at any given time. It is therefore possible for the DelayedWETH\ncontract to account for all bug cases within the FaultDisputeGame as long as the FaultDisputeGame always passes the\ncorrect address into withdraw.\nDelay Period\nWe propose a delay period of 7 days for most OP Stack chains. 7 days provides sufficient time for the owner() of the\nDelayedWETH contract to act even if that owner is a large multisig that requires action from many different members\nover multiple timezones.\nIntegration\nDelayedWETH is expected to be integrated into the Fault Dispute Game as follows:\n\nWhen FaultDisputeGame.initialize is triggered, DelayedWETH.deposit{value: msg.value}() is called.\nWhen FaultDisputeGame.move is triggered, DelayedWETH.deposit{value: msg.value}() is called.\nWhen FaultDisputeGame.resolveClaim is triggered, the game will add to the claimant's internal credit balance.\nWhen FaultDisputeGame.claimCredit is triggered, DelayedWETH.withdraw(recipient, credit) is called.","tokens":2692,"squid":"ink-governance","role":"Council Listener","at":1791261455676,"hash":"a544584767459d13234f30e51cbbca80ab8a866e"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/transaction-lifecycle","domain":"docs.arbitrum.io","title":"Transaction lifecycle on Arbitrum | Arbitrum Docs","text":"✏️Request an updateYou can submit transactions to Arbitrum through two main pathways:\n\nThrough the Sequencer: The standard method for most transactions.\nBypassing the Sequencer: Using the Delayed Inbox contract on the parent chain.\n\nThis guide explains both methods, when to use each, and how they flow through Arbitrum’s transaction lifecycle.\nTransaction submission methods​\nSequencer pathways​\nYou can send transactions to the Sequencer through four methods:\n\nPublic RPC endpoints\nThird-party RPC providers\nSelf-hosted Arbitrum nodes\nDirect Sequencer endpoint\n\nThe first three options route through a load balancer, while the Sequencer endpoint connects directly.\nWhich pathway you pick affects how fast a transaction reaches the Sequencer, not where it lands in the block. The chain's transaction ordering policy decides that. On Arbitrum One, Priority Gas Auctions (PGA) order transactions by the priority fee each one pays, so the fee you attach matters more than the route you choose. Other chains may run first-come, first-serve (FCFS) or Timeboost instead.\nNon-sequencer pathway​\nYou can also submit transactions directly to the Delayed Inbox contract on the parent chain. This method works even when the Sequencer is unavailable, providing an additional layer of censorship resistance.\nThe following diagram shows the different ways you can submit transactions to Arbitrum:\n\nSubmitting transactions to the Sequencer​\nThe Sequencer processes most transactions on Arbitrum. You have four options for sending transactions to the Sequencer, each with different benefits depending on your needs.\nPublic RPC​\nArbitrum provides public RPC endpoints for Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia. These endpoints are rate-limited, making them best for:\n\nTesting and development\nLight usage and general interactions\nApplications with low transaction volume\n\nFor more details on the specific RPC endpoints for each chain, please see this section of the documentation.\nThird-party RPC​\nThird-party node providers offer enhanced performance and higher rate limits. Many providers that support Ethereum also support Arbitrum chains. Use third-party RPCs when you need:\n\nHigher throughput\nBetter performance\nMore reliable uptime\nAdvanced features like analytics\n\nYou can find a list of supported third-party providers here.\nArbitrum nodes​\nRunning your own Arbitrum node provides maximum control and privacy. Your transactions connect to the Sequencer through the Sequencer Feed. Consider this option if you need:\n\nComplete control over transaction handling\nMaximum privacy\nCustom node configurations\n\nPlease see the Arbitrum Node documentation to learn more about setting up and running a node.\nSequencer endpoint​\nThe Sequencer endpoint provides the fastest path to transaction submission by bypassing the load balancer. This endpoint only supports:\n\neth_sendRawTransaction\neth_sendRawTransactionConditional\n\nUse this method when you need the lowest possible latency for time-sensitive transactions.\nThe following diagram shows the four methods for submitting transactions to the Sequencer:\n\nBypassing the Sequencer​\nYou can submit transactions directly to the Delayed Inbox contract on the parent chain without using the Sequencer. This method provides:\n\nCensorship resistance: Transaction inclusion even if the Sequencer refuses to process it\nAvailability guarantee: Transactions work even when the Sequencer is offline\nDecentralization: Reduces dependency on the Sequencer\n\nThere are two paths your transaction can take through the Delayed Inbox.\nWhen you submit a transaction to the Delayed Inbox, two things can happen:\n\nAutomatic processing: The Sequencer picks up your transaction and includes it in the normal transaction flow\nForce inclusion: If 24 hours pass without processing, you can call the forceInclude function on the SequencerInbox contract to guarantee inclusion. The Censorship Timeout feature can shorten this window when the Sequencer is offline or censoring.\n\nThis two-path system ensures your transaction will always be processed, even if the Sequencer is unresponsive or censoring transactions.\n\nUsing the Delayed Inbox​\nTo submit a transaction through the Delayed Inbox:\n\nConstruct your transaction and serialize it\nCall sendL2Message with your serialized transaction data. For the difference between signed and unsigned message variants, see Signed messages and Unsigned messages.\nWait for processing or force inclusion after 24 hours\n\nForce inclusion after delays​\nIf your transaction doesn't get processed within 24 hours, call the forceInclusion function on the SequencerInbox contract. This function ensures that transactions get included regardless of the Sequencer's status.\nUsing the Arbitrum SDK​\nThe Arbitrum SDK simplifies Delayed Inbox interactions through the InboxTools class:\nMethodPurposesendChildSignedTxSubmit transaction to Delayed InboxforceIncludeForce transaction inclusion after 24 hourssignChildTxHelper for transaction signingTransaction submission methodsSequencer pathwaysNon-sequencer pathwaySubmitting transactions to the SequencerPublic RPCThird-party RPCArbitrum nodesSequencer endpointBypassing the SequencerUsing the Delayed InboxForce inclusion after delaysUsing the Arbitrum SDK","tokens":1311,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261455962,"hash":"d36bf3cd60e59f40d78cb5aa3d3740f707bbbff0"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/17","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 14 / 26\n\n Jul 2023\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n post by leohio on Feb 12, 2022\n\n post by experience on Feb 12, 2022\n\n post by Killari on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for attacking this virtually!\n\nI think this is exactly what we intended to prevent with this mechanism.\n\nIs this answering your question?\nThis is the cost comparison between the mega slash event of 1/3 of PoS validators and unlocking all of the Wrapped BTC in this system in the worst case, and there’s no guarantee to succeed this attack while the mega slash will certainly happen.\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n igorsyl\n\n @leohio @KanaPalladium : thank you for working on this! A couple of questions:\n\nWhat progress has been made since this post was published over a year ago, and\nis the prototype described above available publicly?\n\nIn the meantime, the current prototype requires about 20 minutes to encrypt a message using a tiny problem. Therefore, we need to develop various speedup methods to implement a real-world Wrapped Bitcoin.\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n leohio\n\n I made sure that “KanaPalladium” was not my co-author more than one year ago. Sorry to be late for reporting this.\nMy co-author, whose name was encrypted, said he had no account named “KanaPalladium.” And his name is not “Hiro.”\nThe person who uses the account knows me I guess, but please don’t receive any invitation from him just in case. Ignore the account if he talks about “investment to WE project.”\nEncrypting the author’s name was a mistake. I highly recommend people not to try it.\n\nBasically, no update, and just waiting for new WEs. But signature-based WE (https://fc23.ifca.ai/preproceedings/189.pdf) can be useful enough to update this architecture.\nADP can remain the best unless we have the multi-pairing.\nThe weakness of ADP is that one gate increases the length of cipher-text (memory consumption) 4x.\nSo, the direction is to make it with fewer constraints or to update WE to avoid ADP.\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n kravets\n\n kravets\n\n AI summary of recent practical WE algos\nhttps://app.cognosys.ai/s/a6AyKlf\n\n post by kravets on Aug 3, 2023\n\n kravets\n\n Links 2, 3, 4 here are the paper, the presentation PDF and the video of what might be the state of the art in WE\nhttps://www.google.com/search?q=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&oq=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&aqs=chrome..69i57.1511j0j1&sourceid=chrome&ie=UTF-8\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n post by leohio on Nov 14, 2023\n\n post by devfans on Nov 16, 2023\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n post by karl-lolme on Dec 19, 2023\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n post by karl-lolme on Apr 3, 2024\n\n Powered by Discourse","tokens":1319,"squid":"ink-research","role":"Deep Scholar","at":1791261456064,"hash":"fa80687647a1d0a609e5f1823c45d554dbe7454c"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/anchor-state-registry.html","domain":"specs.optimism.io","title":"Anchor State Registry - OP Stack Specification","text":"AnchorStateRegistry\n\nTable of Contents\n\nOverview\nDefinitions\n\nDispute Game\nRespected Game Type\nDispute Game Finality Delay (Airgap)\nRegistered Game\nRespected Game\nBlacklisted Game\nRetirement Timestamp\nRetired Game\nProper Game\nResolved Game\nFinalized Game\nValid Claim\nTruly Valid Claim\nStarting Anchor State\nAnchor Game\nAnchor Root\n\nAssumptions\n\naASR-001: Dispute Game contracts properly report important properties\n\nMitigations\n\naASR-002: DisputeGameFactory properly reports its created games\n\nMitigations\n\naASR-003: Incorrectly resolving games will be invalidated before they have Valid Claims\n\nMitigations\n\nInvariants\n\niASR-001: Games are represented as Proper Games accurately\n\nImpact\nDependencies\n\niASR-002: All Valid Claims are Truly Valid Claims\n\nImpact\nDependencies\n\niASR-003: The Anchor Game is a Truly Valid Claim\n\nImpact\nDependencies\n\niASR-004: Invalidation functions operate correctly\n\nImpact\nDependencies\n\niASR-005: The Anchor Game is recent enough to be fault provable\n\nImpact\n\nFunction Specification\n\nconstructor\ninitialize\npaused\nrespectedGameType\nretirementTimestamp\ndisputeGameFinalityDelaySeconds\nsetRespectedGameType\nupdateRetirementTimestamp\nblacklistDisputeGame\nisGameRegistered\nisGameRespected\nisGameBlacklisted\nisGameRetired\nisGameProper\nisGameResolved\nisGameFinalized\nisGameClaimValid\ngetAnchorRoot\nanchors\nsetAnchorState\n\nOverview\nThe AnchorStateRegistry was designed as a registry where DisputeGame contracts could store and\nregister their results so that these results could be used as the starting states for new\nDisputeGame instances. These starting states, called \"anchor states\", allow new DisputeGame\ncontracts to use a newer starting state to bound the size of the execution trace for any given\ngame.\nWe are generally aiming to shift the AnchorStateRegistry to act as a unified source of truth for\nthe validity of DisputeGame contracts and their corresponding root claims. This specification\ncorresponds to the first iteration of the AnchorStateRegistry that will move us in this\ndirection.\nDefinitions\nDispute Game\n\nSee Fault Dispute Game\n\nA Dispute Game is a smart contract that makes a determination about the validity of some claim. In\nthe context of the OP Stack, the claim is generally assumed to be a claim about the value of an\noutput root at a given L2 block height. We assume that all Dispute Game contracts using the same\nAnchorStateRegistry contract are arguing over the same underlying state/claim structure.\nRespected Game Type\nThe AnchorStateRegistry contract defines a Respected Game Type which is the Dispute Game type\nthat is considered to be the correct by the AnchorStateRegistry and, by extension, other\ncontracts that may rely on the assertions made within the AnchorStateRegistry. The Respected Game\nType is, in a more general sense, a game type that the system believes will resolve correctly. For\nnow, the AnchorStateRegistry only allows a single Respected Game Type.\nDispute Game Finality Delay (Airgap)\nThe Dispute Game Finality Delay or Airgap is the amount of time that must elapse after a\ngame resolves before the game's result is considered \"final\".\nRegistered Game\nA Dispute Game is considered to be a Registered Game if the game contract was created by the\nsystem's DisputeGameFactory contract.\nRespected Game\nA Dispute Game is considered to be a Respected Game if the game contract's game type was\nthe Respected Game Type defined by the AnchorStateRegistry contract at the time of the game's\ncreation. Games that are not Respected Games cannot be used as an Anchor Game. See\nRespected Game Type for more information.\nBlacklisted Game\nA Dispute Game is considered to be a Blacklisted Game if the game contract's address is marked\nas blacklisted inside of the AnchorStateRegistry contract.\nRetirement Timestamp\nThe Retirement Timestamp is a timestamp value maintained within the AnchorStateRegistry that\ncan be used to invalidate games. Games with a creation timestamp less than or equal to the\nRetirement Timestamp are automatically considered to be invalid.\nThe RetirementTimestamp has the effect of retiring all games created before the specific\ntransaction in which the retirement timestamp was set. This includes all games created in the same\nblock as the transaction that set the Retirement Timestamp. We acknowledge the edge-case that games\ncreated in the same block after the Retirement Timestamp was set will be considered Retired Games\neven though they were technically created \"after\" the Retirement Timestamp was set.\nRetired Game\nA Dispute Game is considered to be a Retired Game if the game contract was created with a\ntimestamp less than or equal to the Retirement Timestamp.\nProper Game\nA Dispute Game is considered to be a Proper Game if it has not been invalidated through any of\nthe mechanisms defined by the AnchorStateRegistry contract. A Proper Game is, in a sense, a\n\"clean\" game that exists in the set of games that are playing out correctly in a bug-free manner. A\nDispute Game can be a Proper Game even if it has not yet resolved or resolves in favor of the\nChallenger.\nA Dispute Game that is NOT a Proper Game can also be referred to as an Improper Game for\nbrevity. A Dispute Game can go from being a Proper Game to later not being an Improper Game\nif it is invalidated by being blacklisted or retired.\nALL Dispute Games TEMPORARILY become Improper Games while the\nPause Mechanism is active. However, this is\na temporary condition such that Registered Games that are not invalidated by\nblacklisting or retirement will become Proper Games again\nonce the pause is lifted. The Pause Mechanism is therefore a way to temporarily prevent Dispute\nGames from being used by consumers like the OptimismPortal while relevant parties coordinate the\nuse of some other invalidation mechanism.\nA Game is considered to be a Proper Game if all of the following are true:\n\nThe game is a Registered Game\nThe game is NOT a Blacklisted Game\nThe game is NOT a Retired Game\nThe Pause Mechanism is not active\n\nResolved Game\nA Dispute Game is considered to be a Resolved Game if the game has resolved a result in favor\nof either the Challenger or the Defender.\nFinalized Game\nA Dispute Game is considered to be a Finalized Game if all of the following are true:\n\nThe game is a Resolved Game\nThe game resolved a result more than\nDispute Game Finality Delay seconds ago as defined by the\ndisputeGameFinalityDelaySeconds variable in the AnchorStateRegistry contract.\n\nValid Claim\nA Dispute Game is considered to have a Valid Claim if all of the following are true:\n\nThe game is a Proper Game\nThe game is a Respected Game\nThe game is a Finalized Game\nThe game resolved in favor of the root claim (i.e., in favor of the Defender)\n\nTruly Valid Claim\nA Truly Valid Claim is a claim that accurately represents the correct root for the L2 block height\non the L2 system as would be reported by a perfect oracle for the L2 system state.\nStarting Anchor State\nThe Starting Anchor State is the anchor state (root and L2 block height) that is used as the\nstarting state for new Dispute Game instances when there is no current Anchor Game. The Starting\nAnchor State is set during the initialization of the AnchorStateRegistry contract.\nAnchor Game\nThe Anchor Game is a game whose claim is used as the starting state for new Dispute Game instances.\nA Game can become the Anchor Game if it has a Valid Claim and the claim's L2 block height is\ngreater than the claim of the current Anchor Game. If there is no current Anchor Game, a Game can\nbecome the Anchor Game if it has a Valid Claim and the claim's L2 block height is greater than the\ncurrent Starting Anchor State's L2 block height.\nAfter a Game becomes the Anchor Game, it will remain the Anchor Game until it is replaced by some\nother Game. A Game that is retired after becoming the Anchor Game will remain the Anchor Game.\nAnchor Root\nThe Anchor Root is the root and L2 block height that is used as the starting state for new Dispute\nGame instances. The value of the Anchor Root is the Starting Anchor State if no Anchor Game has\nbeen set. Otherwise, the value of the Anchor Root is the root and L2 block height of the current\nAnchor Game.\nAssumptions\n\nNOTE: Assumptions are utilized by specific invariants and do not apply globally. Invariants\ntypically only rely on a subset of the following assumptions. Different invariants may rely on\ndifferent assumptions. Refer to individual invariants for their dependencies.\n\naASR-001: Dispute Game contracts properly report important properties\nWe assume that the FaultDisputeGame and PermissionedDisputeGame contracts properly and\nfaithfully report the following properties:\n\nGame type\nL2 block number\nRoot claim value\nGame extra data\nCreation timestamp\nResolution timestamp\nResolution result\nWhether the game was the respected game type at creation\n\nWe also specifically assume that the game creation timestamp and the resolution timestamp are not\nset to values in the future.\nMitigations\n\nExisting audit on the FaultDisputeGame contract\nIntegration testing\n\naASR-002: DisputeGameFactory properly reports its created games\nWe assume that the DisputeGameFactory contract properly and faithfully reports the games it has\ncreated.\nMitigations\n\nExisting audit on the DisputeGameFactory contract\nIntegration testing\n\naASR-003: Incorrectly resolving games will be invalidated before they have Valid Claims\nWe assume that any games that are resolved incorrectly will be invalidated either by\nblacklisting or by retirement BEFORE they are considered to\nhave Valid Claims.\nProper Games that resolve in favor the Defender will be considered to have Valid Claims after the\nDispute Game Finality Delay has elapsed UNLESS the\nPause Mechanism is active. Therefore, in the absence of the Pause Mechanism, parties responsible\nfor game invalidation have exactly the Dispute Game Finality Delay to invalidate a withdrawal after\nit resolves incorrectly. If the Pause Mechanism is active, then any incorrectly resolving games\nmust be invalidated before the pause is deactivated.\nMitigations\n\nStakeholder incentives / processes\nIncident response plan\nMonitoring\n\nInvariants\niASR-001: Games are represented as Proper Games accurately\nWhen asked if a game is a Proper Game, the AnchorStateRegistry must serve a response that is\nidentical to the response that would be given by a perfect oracle for this query.\nImpact\nSeverity: High\nIf this invariant is broken, the Anchor Game could be set to an incorrect value, which would cause\nfuture Dispute Game instances to use an incorrect starting state. This would lead games to resolve\nincorrectly. Additionally, this could cause a FaultDisputeGame to incorrectly choose the wrong\nbond refunding mode.\nDependencies\n\naASR-001\naASR-002\naASR-003\n\niASR-002: All Valid Claims are Truly Valid Claims\nWhen asked if a game has a Valid Claim, the AnchorStateRegistry must serve a response that is\nidentical to the response that would be given by a perfect oracle for this query. However, it is\nimportant to note that we do NOT say that all Truly Valid Claims are Valid Claims. It is possible\nthat a game has a Truly Valid Claim but the AnchorStateRegistry reports that the claim is not\na Valid Claim. This permits the AnchorStateRegistry and system-wide safety net actions to err on\nthe side of caution.\nIn a nutshell, the set of Valid Claims is a subset of the set of Truly Valid Claims.\nImpact\nSeverity: Critical\nIf this invariant is broken, then any component that relies on the correctness of this function may\nallow actions to occur based on invalid dispute games.\nSome examples of strong negative impact are:\n\nInvalid Dispute Game could be used as the Anchor Game, which would cause future Dispute Game\ninstances to use an incorrect starting state. This would lead these games to resolve incorrectly.\n(HIGH)\nInvalid Dispute Game could be used to prove or finalize withdrawals within the OptimismPortal\ncontract. This would lead to a critical vulnerability in the bridging system. (CRITICAL)\n\nDependencies\n\naASR-001\naASR-002\naASR-003\n\niASR-003: The Anchor Game is a Truly Valid Claim\nWe require that the Anchor Game is a Truly Valid Claim. This makes it possible to use the Anchor\nGame as the starting state for new Dispute Game instances. Notably, given the allowance that not\nall Truly Valid Claims are Valid Claims, this invariant does not imply that the Anchor Game is a\nValid Claim.\nWe allow retired games to be used as the Anchor Game because the retirement mechanism is broad in a\nway that commonly causes Truly Valid Claims to no longer be considered Valid Claims. We allow both\nblacklisted games and retired games to remain the Anchor Game if they are already the Anchor Game.\nThis is because we assume games that become the Anchor Game would be invalidated before becoming\nthe Anchor Game. After the game becomes the Anchor Game, it would be possible to use that game to\nexecute withdrawals from the system, which would already be a critical bug in the system.\nImpact\nSeverity: High\nIf this invariant is broken, an invalid Anchor Game could be used as the starting state for new\nDispute Game instances. This would lead games to resolve incorrectly.\nDependencies\n\naASR-001\naASR-002\naASR-003\n\niASR-004: Invalidation functions operate correctly\nWe require that the blacklisting and retirement functions operate correctly. Games that are\nblacklisted must not be used as the Anchor Game, must not be considered Valid Games, and must not\nbe usable to prove or finalize withdrawals. Any game created before a transaction that updates the\nretirement timestamp must not be set as the Anchor Game, must not be considered Valid Games, and\nmust not be usable to prove or finalize withdrawals.\nImpact\nSeverity: High/Critical\nIf this invariant is broken, the Anchor Game could be set to an incorrect value, which would cause\nfuture Dispute Game instances to use an incorrect starting state. This would lead games to resolve\nincorrectly and would be considered a High Severity issue. Issues that would allow users to\nfinalize withdrawals with invalidated games would be considered Critical Severity.\nDependencies\n\naASR-003\n\niASR-005: The Anchor Game is recent enough to be fault provable\nWe require that the Anchor Game corresponds to an L2 block with an L1 origin timestamp that is no\nolder than 6 months from the current timestamp. This time constraint is necessary because the fault\nproof VM must walk backwards through L1 blocks to verify derivation, and processing 7 months worth\nof L1 blocks approaches the maximum time available to challengers in the dispute game process.\nImpact\nSeverity: High\nIf this invariant is broken, challengers will be unable to participate in fault proofs within the\nallotted response time, and resolution would require intervention from the Proxy Admin Owner.\nFunction Specification\nconstructor\n\nMUST set the value of the Dispute Game Finality Delay.\n\ninitialize\n\nMUST only be callable by the ProxyAdmin or its owner.\nMUST only be triggerable once.\nMUST set the value of the SystemConfig contract that stores the address of the Guardian.\nMUST set the value of the DisputeGameFactory contract that creates Dispute Game instances.\nMUST set the value of the Starting Anchor State.\nMUST set the value of the initial Respected Game Type.\nMUST set the value of the Retirement Timestamp to the current block\ntimestamp. NOTE that this is a safety mechanism that invalidates all existing Dispute Game\ncontracts to support the safe transition away from the OptimismPortal as the source of truth\nfor game validity. In this way, the AnchorStateRegistry does not need to consider the state of\nthe legacy blacklisting/retirement mechanisms within the OptimismPortal and starts from a clean\nslate.\n\npaused\nReturns the value of paused() from the SystemConfig contract.\nrespectedGameType\nReturns the value of the currently Respected Game Type.\nretirementTimestamp\nReturns the value of the current Retirement Timestamp.\ndisputeGameFinalityDelaySeconds\nReturns the value of the Dispute Game Finality Delay.\nsetRespectedGameType\nPermits the Guardian role to set the Respected Game Type.\n\nMUST revert if called by any address other than the Guardian.\nMUST update the respected game type with the provided type.\nMUST emit an event showing that the game type was updated.\n\nupdateRetirementTimestamp\nPermits the Guardian role to update the Retirement Timestamp.\n\nMUST revert if called by any address other than the Guardian.\nMUST set the retirement timestamp to the current block timestamp.\nMUST emit an event showing that the retirement timestamp was updated.\n\nblacklistDisputeGame\nPermits the Guardian role to blacklist a Dispute Game.\n\nMUST revert if called by any address other than the Guardian.\nMUST mark the game as blacklisted.\nMUST emit an event showing that the game was blacklisted.\n\nisGameRegistered\nDetermines if a game is a Registered Game.\n\nMUST return true if and only if the game was created by the system's DisputeGameFactory\ncontract AND the game's AnchorStateRegistry address matches the address of this contract.\n\nisGameRespected\nDetermines if a game is a Respected Game.\n\nMUST return true if and only if the game's game type was the respected game type defined by the\nAnchorStateRegistry contract at the time of the game's creation as per a call to\nAnchorStateRegistry.respectedGameType().\n\nisGameBlacklisted\nDetermines if a game is a Blacklisted Game.\n\nMUST return true if and only if the game's address is marked as blacklisted inside of the\nAnchorStateRegistry contract.\n\nisGameRetired\nDetermines if a game is a Retired Game.\n\nMUST return true if and only if the game was created before or at the retirement timestamp\ndefined by the AnchorStateRegistry contract as per a call to\nAnchorStateRegistry.retirementTimestamp(). We check for less than or equal to the current\nretirement timestamp to prevent games from being created in the same block but before the\ntransaction in which the retirement timestamp was set. Note that this has the side effect of also\ninvalidating any games created in the same block after the retirement timestamp was set but\nthis is an acceptable tradeoff.\n\nisGameProper\nDetermines if a game is a Proper Game.\n\nMUST return true if and only if isGameRegistered(game) is true, isGameBlacklisted(game)\nand isGameRetired(game) are both false, and paused() is false.\n\nisGameResolved\nDetermines if a game is a Resolved Game.\n\nMUST return true if and only if the game has resolved a result in favor of either the\nChallenger or the Defender as determined by the FaultDisputeGame.status() function.\n\nisGameFinalized\nDetermines if a game is a Finalized Game.\n\nMUST return true if and only if isGameResolved(game) and the game has resolved a result more\nthan the airgap delay seconds ago as defined by the disputeGameFinalityDelaySeconds variable in\nthe AnchorStateRegistry contract.\n\nisGameClaimValid\nDetermines if a game has a Valid Claim.\n\nMUST return true if and only if isGameProper(game) is true, isGameRespected(game) is\ntrue, isGameFinalized(game) is true, and the game resolved in favor of the root claim\n(i.e., in favor of the Defender).\n\ngetAnchorRoot\nRetrieves the current anchor root.\n\nMUST return the root hash and L2 block height of the current anchor state.\n\nanchors\nLegacy function. Accepts a game type as a parameter but does not use it.\n\nMUST return the current value of getAnchorRoot().\n\nsetAnchorState\nAllows any address to attempt to update the Anchor Game with a new Game as input.\n\nMUST revert if the provided game does not have a Valid Claim for any reason.\nMUST revert if the provided game corresponds to an L2 block height that is less than or equal\nto the current anchor state's L2 block height.\nMUST otherwise update the anchor state to match the game's result.","tokens":4927,"squid":"ink-governance","role":"Council Listener","at":1791261477545,"hash":"fcbb11e8aaa9da6ebd6ea13c8f7f4c345e23384b"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/finality","domain":"docs.arbitrum.io","title":"Finality | Arbitrum Docs","text":"✏️Request an updateFinality in blockchain systems refers to the point at which a transaction becomes irreversible and is permanently included in the blockchain’s ledger. In Arbitrum’s Nitro architecture, understanding finality is crucial for developers and users to make informed decisions about transaction confirmations, security guarantees, and application design.\nLevels of finality​\n\nSoft finality: Provided by the Sequencer’s real-time feed, offering immediate but provisional transaction confirmations.\nHard finality: Occurs when transactions are included in batches posted to and finalized on the parent chain, providing strong security assurances. Final settlement on the parent chain happens via assertions confirmed by the Rollup protocol.\n\nThis section explores the concepts of soft and hard finality, their implications, trust considerations, and guidance for using them effectively within the Arbitrum network.\nAuthority and finality​\n\nExclusive access: Only authorized batch posters can call these batch-submission methods on the Sequencer Inbox contract (access is gated by the contract’s isBatchPoster mapping, a role distinct from the sequencer, though the two are typically operated by the same party). This exclusivity ensures that no other party can include messages directly.\nSoft-confirmation receipts: The Sequencer’s unique ability to immediately process and include transactions allows it to provide users with instant, “soft-confirmation” receipts.\nParent chain finality: Once batches post, the transactions achieve parent-chain-level finality, secured by the parent chain’s consensus mechanism.\n\nBy efficiently sending compressed transaction batches to the Sequencer Inbox contract using the most cost-effective method available, the Sequencer ensures transactions are securely recorded on the parent chain. This process maintains the integrity and reliability of the network, enabling users to perform fast, secure transactions.\nFinality at a glance​\nThe following table summarizes the approximate latency and guarantee at each stage. Figures are indicative for an Ethereum parent chain and depend on configuration and network conditions.\nStageGuaranteeApproximate latencySoft finality (Sequencer feed)Provisional ordering by the SequencerSub-secondParent-chain data finality (batch posted and finalized on L1)Transaction data is durably recorded and inherits the parent chain's consensus security~2 epochs, roughly 12–15 minutes (the batch poster defaults to referencing the L1 safe block)Full settlement (assertion confirmed)L2 state is finalized and L2→L1 withdrawals can be executedA bounded challenge period under BoLD, on the order of days on mainnet\nThe Fast Feed publishes all transactions in a PGA roundOn Arbitrum One, the Fast Feed publishes all transactions within a the Priority Gas Auction (PGA) round, before the block closes and before the Sequencer feed carries it. It is faster than soft finality and guarantees less: the block number it reports is tentative, it carries no block hash, and inclusion is not guaranteed. It is not a finality stage. Read it as an early signal, then confirm against the Sequencer feed or a node.\nSoft finality​\nSoft finality refers to the preliminary confirmation of transactions based on the Sequencer’s real-time feed. Key characteristics include:\n\nImmediate confirmation: Transactions are confirmed almost instantly as they are accepted and ordered by the Sequencer.\nProvisional assurance: The confirmations are provisional and rely on the Sequencer’s integrity and availability.\nHigh performance: Enables applications to offer rapid responses and real-time interactions, enhancing user experience.\n\nAdvantages of soft finality​\n\nLow latency: Users receive immediate feedback on transaction status.\nOptimized for speed: Ideal for applications where responsiveness is critical.\nImproved user experience: Reduces waiting times and uncertainty.\n\nLimitations of soft finality​\n\nTrust dependency: Relies on the Sequencer’s honesty and ability to maintain uptime.\nPotential for reordering: In rare cases, if the Sequencer acts maliciously or encounters issues, the provisional ordering could change.\nNot suitable for high-value transactions: For transactions requiring strong security guarantees, soft finality may not suffice.\n\nCensorship resistance and force inclusion​\nThe soft-finality trust dependency on the Sequencer is bounded rather than open-ended. A user can submit a transaction directly to the parent chain through the delayed inbox. If the Sequencer refuses to include it, the user can call forceInclusion on the Sequencer Inbox contract once the Sequencer’s exclusive window has elapsed, pushing the message into the chain without the Sequencer’s cooperation (see censorship resistance and the Censorship Timeout). By default this window is roughly 24 hours (configured as delayBlocks/delaySeconds, defaulting to about 5,760 blocks or 86,400 seconds).\nThe practical consequence is that the Sequencer can delay a transaction but cannot permanently censor it. Delayed-inbox messages are only sequenced after they reach parent-chain finality — the delayed sequencer waits for the parent chain’s safe (or, if configured, finalized) head before including them — so force-included transactions inherit parent-chain finality guarantees.\nHard finality​\nHard finality occurs when batched transactions are posted to the parent chain and the corresponding assertions are confirmed by the Rollup protocol. Posting a batch to the parent chain is not itself final settlement: the transaction data becomes available and inherits the parent chain’s data-layer security, but final settlement of the resulting L2 state occurs once assertions are confirmed (see \"Final settlement\" above). Key characteristics include:\n\nStrong security guarantees: When included in blocks on the parent chain, transactions inherit the parent chain’s security assurances.\nIrreversibility: Once finalized, transactions are immutable and cannot be altered or reversed.\nData availability: In the default Rollup mode, all transaction data is recorded onchain (via calldata or blobs), ensuring transparency and verifiability. On AnyTrust chains, batch data is instead kept offchain by a Data Availability Committee (DAC), and only a data availability certificate is posted onchain — trading full onchain data availability for lower cost.\n\nAdvantages of hard finality​\n\nMaximum security: Protected by the robustness of the parent chain’s consensus mechanism.\nTrust minimization: This does not require trust in the Sequencer; the underlying blockchain provides security.\nSuitable for high-value transactions: Ideal for scenarios where security and immutability are paramount.\n\nLimitations of hard finality​\n\nHigh latency: Achieving hard finality takes longer because the parent chain must process and finalize batches. The challenge protocol that backs this guarantee is described in BoLD.\n\nTrust considerations​\nUnderstanding the trust assumptions associated with each level of finality is essential:\nSoft finality trust model​\n\nReliance on the Sequencer: Users must trust that the Sequencer operates honestly, sequences transactions correctly, and remains available.\nRisk of misbehavior: If the Sequencer acts maliciously, it could reorder or censor certain transactions before they achieve hard finality.\n\nHard finality trust model​\n\nReliance on the parent chain: Security is based on the consensus and integrity of the parent chain.\nReduced trust in the Sequencer: Even if the Sequencer misbehaves, transactions included in posted batches are secured once finalized on the parent chain.\n\nApplication implications​\nDevelopers and users should consider the appropriate level of finality based on their specific use cases:\nWhen to rely on soft finality​\n\nLow-risk transactions: For transactions where the potential impact of reordering or delays is minimal.\nUser experience priority: Applications where responsiveness and immediacy enhance user engagement, such as gaming or social platforms.\nFrequent transactions: Scenarios involving a high volume of small transactions where waiting for hard finality is impractical.\n\nWhen to require hard finality​\n\nHigh-value transactions: Financial transfers, large trades, or any transaction where security is critical.\nRegulatory compliance: Situations requiring strict adherence to security standards and auditable records.\nCentralized exchanges (CEXs): For deposit and withdrawal operations where certainty of transaction finality is mandatory. These two operations rely on different guarantees. Crediting a deposit can rely on parent-chain data finality (batches posted and finalized on L1, on the order of minutes). Releasing an L2→L1 withdrawal, however, requires the corresponding assertion to be confirmed by the Rollup protocol, which only completes after the BoLD challenge period (on the order of days). Batch posting alone does not make funds withdrawable to the parent chain.\n\nRelated resources​\n\nFinality and chain reorganizations — the latest, safe, and finalized block tags, reorg depth, and which tag an indexer should wait on.\nThe Sequencer and censorship resistance — the real-time feed, batch posting, and the delayed inbox escape hatch.\nAssertions — how the Rollup protocol confirms child chain state and completes final settlement.\nBoLD: a gentle introduction — the dispute protocol that bounds the challenge period.\nAnyTrust protocol — how a DAC and data availability certificates change the data availability guarantee.\nChild to parent chain messaging — the outbox and why withdrawals wait for assertion confirmation.\nLevels of finalityAuthority and finalityFinality at a glanceSoft finalityAdvantages of soft finalityLimitations of soft finalityCensorship resistance and force inclusionHard finalityAdvantages of hard finalityLimitations of hard finalityTrust considerationsSoft finality trust modelHard finality trust modelApplication implicationsWhen to rely on soft finalityWhen to require hard finalityRelated resources","tokens":2508,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261479566,"hash":"5da453eb01b390593ed4f6a1341538e031724250"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/21","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 17 / 26\n\n Oct 2023\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n post by leohio on Feb 12, 2022\n\n post by experience on Feb 12, 2022\n\n post by Killari on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n leohio\n\n I made sure that “KanaPalladium” was not my co-author more than one year ago. Sorry to be late for reporting this.\nMy co-author, whose name was encrypted, said he had no account named “KanaPalladium.” And his name is not “Hiro.”\nThe person who uses the account knows me I guess, but please don’t receive any invitation from him just in case. Ignore the account if he talks about “investment to WE project.”\nEncrypting the author’s name was a mistake. I highly recommend people not to try it.\n\nBasically, no update, and just waiting for new WEs. But signature-based WE (https://fc23.ifca.ai/preproceedings/189.pdf) can be useful enough to update this architecture.\nADP can remain the best unless we have the multi-pairing.\nThe weakness of ADP is that one gate increases the length of cipher-text (memory consumption) 4x.\nSo, the direction is to make it with fewer constraints or to update WE to avoid ADP.\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n kravets\n\n kravets\n\n AI summary of recent practical WE algos\nhttps://app.cognosys.ai/s/a6AyKlf\n\n post by kravets on Aug 3, 2023\n\n kravets\n\n Links 2, 3, 4 here are the paper, the presentation PDF and the video of what might be the state of the art in WE\nhttps://www.google.com/search?q=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&oq=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&aqs=chrome..69i57.1511j0j1&sourceid=chrome&ie=UTF-8\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n post by devfans on Nov 16, 2023\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n post by karl-lolme on Dec 19, 2023\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n post by karl-lolme on Apr 3, 2024\n\n Powered by Discourse","tokens":1328,"squid":"ink-research","role":"Deep Scholar","at":1791261479621,"hash":"7e242bff1b144508bdf12303e4cd2a63595a1cfb"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/zk/game-mechanics.html","domain":"specs.optimism.io","title":"Game Mechanics - OP Stack Specification","text":"ZK Dispute Game Mechanics\n\nTable of Contents\n\nState Transitions\nCreation\n\nParent Validation\n\nChallenge\nProving\nResolution\n\nBond Distribution\n\nClosing\n\nState Transitions\nThe game tracks its lifecycle through two enums:\nGameStatus (external, defined in Types.sol): the authoritative resolution outcome read by\nOptimismPortal and AnchorStateRegistry.\nenum GameStatus {\n IN_PROGRESS, // Default state; game has not yet resolved\n CHALLENGER_WINS,\n DEFENDER_WINS\n}\n\nProposalStatus (internal, defined in ZKDisputeGame): tracks the proposal's internal\nlifecycle independently of the resolution outcome.\nenum ProposalStatus {\n Unchallenged,\n Challenged,\n UnchallengedAndValidProofProvided,\n ChallengedAndValidProofProvided,\n Resolved\n}\n\nclaimData.status (ProposalStatus) transitions on challenge() and prove(). status\n(GameStatus) transitions only inside resolve(). These two state variables evolve independently\nand MUST NOT be conflated.\n claimData.status (ProposalStatus)\n\nGameCreation ──► Unchallenged ──────────────────────────────────────────────────────────┐\n │ │\n ├──► Challenged ──► ChallengedAndValidProofProvided ──────────────┤\n │ │ │\n │ └─ (prove deadline expires) ─────────────────────────── ┤\n │ │\n └──► UnchallengedAndValidProofProvided ─────────────────────────── ┤\n │ │\n └─ (challenge deadline expires) ────────────────────────┤\n ▼\n resolve()\n │\n status (GameStatus) │\n IN_PROGRESS ───────────────────────────────────────────────────── ┤\n │\n ┌─── DEFENDER_WINS ◄──── ┤\n └─── CHALLENGER_WINS ◄── ┘\n\nTransitionTrigger\nGameCreation → Unchallengedinitialize() called by DisputeGameFactory\nUnchallenged → Challengedchallenge() called before deadline\nUnchallenged → UnchallengedAndValidProofProvidedprove() succeeds\nChallenged → ChallengedAndValidProofProvidedprove() succeeds\nAny non-terminal ProposalStatus → Resolvedresolve() succeeds\nIN_PROGRESS → DEFENDER_WINS | CHALLENGER_WINSresolve() succeeds\n\nCreation\nGame creation is fully permissionless. Anyone may call DisputeGameFactory.create() with the\nrequired initBond. The factory deploys an MCP clone, which then validates the proposal.\ninitBond is the ETH value the proposer must send when creating a game. The factory forwards it\nto initialize() as msg.value. Its exact amount is set per deployment and can be updated by\ngovernance; the game contract reads it from the factory at creation time.\nA game may start from the anchor state by setting parentIndex = type(uint32).max, or it may\nreference a parent game.\nThe _extraData passed to DisputeGameFactory.create() has a variable-length layout:\nFieldTypeDescription\nparentIndexuint32Index of the parent game; type(uint32).max if starting from the anchor state\nsuperRootProofbytesABI-encoded SuperRootProof preimage committed to by rootClaim. The L2 sequence number (super root timestamp) is part of this preimage and is exposed by the contract via l2SequenceNumber() for convenience.\n\nThe variable-length layout is parsed via _preExtraDataByteCount() and _extraDataByteCount()\nhelpers, following the same pattern as SuperFaultDisputeGame. All CWIA field offsets after\nextraData are computed dynamically.\nDuring initialize(), the game:\n\nValidates the SuperRootProof preimage: hashSuperRootProof(decode(extraData)) == rootClaim.\nSnapshots wasRespectedGameTypeWhenCreated. AnchorStateRegistry.isGameClaimValid() reads\nthis flag when determining if a game's root claim can advance the anchor state or finalize\nwithdrawals via the Portal.\n\nParent Validation\nWhen a parent is referenced (parentIndex != type(uint32).max), initialize() MUST revert if\nany of the following checks fail:\n\nParent MUST NOT be blacklisted.\nParent MUST NOT be retired (i.e., createdAt > retirementTimestamp).\nParent MUST be the same game type (ZK_GAME_TYPE).\nParent MUST NOT have resolved as CHALLENGER_WINS.\nParent's l2SequenceNumber (timestamp) MUST be strictly above the anchor state's\nl2SequenceNumber.\nThe game's l2SequenceNumber MUST be strictly greater than the parent's l2SequenceNumber.\n\nThe isGameRespected check on the parent is intentionally omitted. The respected game type gates\nwhich games can finalize withdrawals (via isGameClaimValid), but MUST NOT prevent in-progress\nproposal chains from being completed after a game type transition.\nChallenge\nChallenging is fully permissionless. Anyone may call challenge() before the challenge deadline.\nThe call MUST include challengerBond ETH, which challenge() deposits into DelayedWETH on\nthe caller's behalf.\n\nchallenge() MUST revert if gameOver() returns true.\nchallenge() MUST revert if claimData.status != ProposalStatus.Unchallenged.\nchallenge() MUST revert if msg.value != challengerBond.\nOnly one challenge is allowed per game.\nCalling challenge() resets the deadline to block.timestamp + maxProveDuration.\n\nProving\nProving is fully permissionless. Anyone may call prove(proofBytes) at any point before the\ncurrent deadline, regardless of whether the game has been challenged.\n\nprove() MUST revert if status != GameStatus.IN_PROGRESS (i.e., the game is already\nresolved).\nprove() MUST revert if the parent game has resolved as CHALLENGER_WINS.\nprove() MUST revert if gameOver() returns true (covers an already-submitted proof and an\nexpired deadline).\nThe verifier call MUST revert for invalid proofs.\nOn success, claimData.prover is set to msg.sender and claimData.status transitions to\nUnchallengedAndValidProofProvided or ChallengedAndValidProofProvided (depending on whether\nthe game was challenged). gameOver() returns true immediately after.\n\ngameOver() returns true when:\n\nclaimData.deadline < block.timestamp, OR\nclaimData.prover != address(0).\n\nResolution\nResolution is permissionless. Anyone may call resolve() once gameOver() returns true and\nthe parent game is resolved.\n\nresolve() MUST revert if status != GameStatus.IN_PROGRESS (i.e., game is already resolved).\nIf the game references a parent (parentIndex != type(uint32).max), resolve() MUST revert if\nthe parent game's status == GameStatus.IN_PROGRESS.\nIf the parent resolved as CHALLENGER_WINS, the child inherits CHALLENGER_WINS regardless of\nits own proof status.\nOtherwise (parent DEFENDER_WINS), the outcome is determined by claimData.status:\n\nclaimData.status at resolutionGameStatus outcomenormalModeCredit allocation\nUnchallenged (deadline expired)DEFENDER_WINSgameCreator ← totalBonds\nUnchallengedAndValidProofProvidedDEFENDER_WINSgameCreator ← totalBonds\nChallenged (prove deadline expired)CHALLENGER_WINSchallenger ← totalBonds\nChallengedAndValidProofProvided, prover == proposerDEFENDER_WINSprover ← totalBonds\nChallengedAndValidProofProvided, prover != proposerDEFENDER_WINSprover ← challengerBond; gameCreator ← totalBonds - challengerBond\nParent CHALLENGER_WINS, child challengedCHALLENGER_WINSchallenger ← totalBonds\nParent CHALLENGER_WINS, child unchallengedCHALLENGER_WINSaddress(0) ← totalBonds (burned)\n\ntotalBonds equals initBond for unchallenged games and initBond + challengerBond for\nchallenged games.\nNote: when a parent resolves as CHALLENGER_WINS and the child was never challenged,\nclaimData.challenger == address(0), so normalModeCredit[address(0)] = totalBonds. This credit\nis effectively burned inside DelayedWETH where the owner can recover it via hold()/recover().\nBond Distribution\nBond distribution follows a NORMAL or REFUND mode determined by isGameProper (evaluated in\ncloseGame):\nModeConditionEffect\nNORMALGame is proper (registered, not blacklisted, not retired, not paused)normalModeCredit allocations from resolve() are honored\nREFUNDGame is blacklisted, retired, or otherwise improperrefundModeCredit is used: initBond returned to proposer; challengerBond returned to challenger\n\nComplete distribution scenarios:\nScenarioModeProposer getsChallenger getsProver gets\nUnchallenged, deadline expiresNORMALinitBond——\nUnchallenged, proof providedNORMALinitBond—nothing\nChallenged, no proofNORMALnothinginitBond + challengerBond—\nChallenged, proof, prover == proposerNORMALinitBond + challengerBondnothing(same)\nChallenged, proof, prover != proposerNORMALinitBondnothingchallengerBond\nParent CHALLENGER_WINS, child challengedNORMALnothinginitBond + challengerBond—\nParent CHALLENGER_WINS, child unchallengedNORMALburned to address(0)——\nGame blacklistedREFUNDinitBondchallengerBond—\nGame retiredREFUNDinitBondchallengerBond—\n\nClosing\nAfter resolution, bonds are distributed through a two-phase process.\ncloseGame() (permissionless, also called internally by claimCredit):\n\nReturns early if bondDistributionMode is already set (NORMAL or REFUND).\nMUST revert if AnchorStateRegistry is paused.\nMUST revert with GameNotResolved if resolvedAt == 0.\nMUST revert if AnchorStateRegistry.isGameFinalized(this) returns false.\nAttempts to register the game as the new anchor state via AnchorStateRegistry.setAnchorState().\nThis may silently fail if the game is not eligible; the failure is caught and ignored.\nCalls AnchorStateRegistry.isGameProper(this) to determine NORMAL or REFUND mode and sets\nbondDistributionMode accordingly.\n\nclaimCredit(recipient):\nUses a two-phase DelayedWETH withdrawal pattern.\n\nRecords whether the game was open (bondDistributionMode == UNDECIDED) before the call.\nTriggers closeGame() if not yet closed.\nPhase 1 — unlock: If recipient still has credit allocated by this game (checked against\nthe active mode's credit mapping), zeroes out both normalModeCredit[recipient] and\nrefundModeCredit[recipient], then calls DelayedWETH.unlock(recipient, amount) and returns.\nA second call is required to complete the withdrawal once the DelayedWETH delay has elapsed.\nPhase 2 — withdraw: If credit has already been zeroed (phase 1 completed), checks\nDelayedWETH for a pending withdrawal amount. If the amount is zero and the game was open\nbefore this call, returns without reverting (so closeGame() state changes persist). If the\namount is zero and the game was already closed, reverts with NoCreditToClaim. Otherwise,\ncalls DelayedWETH.withdraw(recipient) and transfers ETH to the recipient, reverting on\ntransfer failure.\n\nThe DelayedWETH delay allows the Guardian to pause and freeze funds if a critical issue is\ndiscovered post-resolution.","tokens":2526,"squid":"ink-governance","role":"Council Listener","at":1791261489012,"hash":"6af9311209d7864b994436c6f80aa36359830069"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/assertions","domain":"docs.arbitrum.io","title":"Assertions | Arbitrum Docs","text":"✏️Request an updateThe Rollup chain assertions vs. child chain blocks​\nThe Rollup chain consists of assertions, which serve as checkpoints summarizing multiple child chain blocks. Assertions are what give Arbitrum its hard finality guarantee — for the broader soft- vs. hard-finality picture, see Finality.\n\nChild chain blocks contain individual transaction data\nAssertions provide state summaries recorded on Ethereum\nEach assertion may represent multiple child chain blocks, optimizing gas costs and reducing Ethereum storage usage.\n\nValidators submit assertions by calling createNewAssertion in the Rollup contract. Assertions contain structured data known as AssertionInputs, which capture the before-state and after-state of execution for future validation.\nContents of an assertion​\nEach assertion consists of:\n\nAssertion number: A unique identifier\nPredecessor assertion: The last confirmed assertion\nNumber of child chain blocks: The total child chain blocks included\nNumber of inbox messages: Messages consumed during execution\nOutput hash: A cryptographic commitment to the resulting state\n\nArbitrum ensures assertions are automatically confirmed or rejected based on protocol rules:\n\nAn assertion is confirmed if:\n\nIts predecessor is the latest confirmed assertion\nThe dispute window has passed without challenges\n\nAn assertion is rejected if:\n\nIts predecessor assertion is invalid\nA conflicting assertion has been confirmed\n\nFor more details on how the Rollup chain works under BoLD, the gentle introduction provides an overview that touches on the Rollup chain.\nValidators and proposers serve different rolesValidators validate transactions by computing the next chain state using the chain's STF, whereas proposers can also assert and challenge the chain state on the parent chain.\nExcept for the assertion number, the assertion's contents are merely claims by its proposer. Arbitrum doesn't know at first whether any of these fields are correct. The protocol should eventually confirm the assertion if all of these fields are correct. The protocol should eventually reject the assertion if any of these fields are incorrect.\nAn assertion implicitly claims that its predecessor is correct, meaning it also asserts the correctness of the entire chain's history: a sequence of ancestor assertions that reaches back to the chain's genesis.\nAn assertion also implicitly claims that its older siblings (other assertions with the same predecessor) are incorrect, if any exist. If two assertions are siblings, and the older sibling is correct, then the younger sibling is considered incorrect, even if everything else in the younger sibling is true.\nThe assertion is assigned a deadline, which indicates how much time other validators have to respond to it. For an assertion R with no older siblings, the deadline will equal the time when the assertion posts, plus an interval of time known as the challenge period; subsequent younger siblings will have the same deadline as their oldest sibling (R). You don't need to do anything if you're a validator and agree that an assertion is correct. If you disagree with an assertion, you can post another assertion with a different result, and you'll probably end up in a challenge against the party that proposed the first assertion (or another party acting in support of that assertion). For the bisection protocol used to resolve such challenges, see How BoLD bisection works.\nDelays​\nEven if the Assertion Tree has multiple conflicting assertions and multiple disputes are in progress, validators can continue making new assertions. Honest validators will build on one valid assertion (intuitively, an assertion is also an implicit claim of the validity of all its parent assertions). Likewise, users can continue transacting on the child chain, as transactions will still post to the chain’s inbox.\nThe only delay users experience during a dispute is in their child-to-parent chain messages (i.e., withdrawals). A key property of BoLD is that, in the common case, their withdrawals (messages) will only experience a delay of one challenge period. In the event of a dispute, withdrawals (messages) will be delayed by no more than two challenge periods, regardless of the adversaries’ behavior during the challenge.\nStaking and validator incentives​\nArbitrum requires validators to bond ETH as a security deposit to ensure honest participation and prevent malicious behavior. This mechanism enforces economic accountability (for a deeper analysis of bond sizing and dispute incentives, see The economics of disputes in BoLD):\n\nProposers (validators submitting assertions) must bond ETH to support their claims.\nChallenges against incorrect assertions result in bond forfeiture for dishonest validators.\nSuccessful challengers receive a portion of the dishonest validator's bond as a reward.\n\nValidators can adopt different roles:\n\nActive validators: Regularly propose new assertions.\nDefensive validators: Monitor the network and challenge incorrect assertions.\nWatchtower validators: Passively observe and raise alarms when fraud is detected.\n\nThe protocol design requires only one honest validator to secure the system, making Arbitrum trustless and resistant to Sybil attacks.\nStaking mechanism​\nSome validators will act as bonders at any given time, while others remain passive. Bonders deposit ETH bonds into Arbitrum's smart contracts, which are forfeited if they lose a challenge.\nnoteArbitrum Nitro chains accept ETH as the only collateral for staking.\nA single bond can secure a sequence of assertions, meaning a validator's bond applies to multiple checkpoints of the chain's history. This checkpoint allows efficient resource use while maintaining security.\nA validator must be bonded to its predecessor to create a new assertion. The bond ensures that validators have economic risk in any assertion they make.\nHandling disputes and delays​\nMultiple disputes may be active simultaneously if conflicting assertions arise in the Assertion Tree. However, Arbitrum's protocol ensures that:\n\nHonest validators can continue asserting, building on the last correct assertion.\nUsers can keep transacting on the child chain without disruption.\nChild-to-parent chain withdrawals may experience delays; typically, withdrawals experience a single challenge period (6.4 days). A key property of BoLD is that, in the common case, withdrawals (messages) will experience only a one-challenge-period delay. In the event of a dispute, withdrawals will be delayed by no more than two challenge periods, regardless of the adversaries' behavior during the challenge.\n\nDespite these delays, Arbitrum guarantees that honest assertions always succeed, maintaining Ethereum-level security.\nVerifying a child chain block in a confirmed assertion​\nYou can programmatically check whether a specific child chain block has been included in a confirmed assertion by querying the Rollup contract on the parent chain. This is useful for applications that need to verify finality beyond soft confirmation.\nThe Rollup contract lives on the parent chain, but its address is exposed via the child chain's network metadata. The example below uses the child chain to look the address up, then attaches it to the parent provider for reads.\nimport { Contract } from 'ethers';import { getArbitrumNetwork } from '@arbitrum/sdk';import { BoldRollupUserLogic__factory } from '@arbitrum/sdk/dist/lib/abi-bold/factories/BoldRollupUserLogic__factory';// Look up the child chain's network metadata to find the Rollup address.const childNetwork = await getArbitrumNetwork(childProvider);// The Rollup contract is deployed on the parent chain, so attach it to parentProvider.const rollup = new Contract(childNetwork.ethBridge.rollup, BoldRollupUserLogic__factory.abi, parentProvider);// Get the latest confirmed assertion hash.const assertionHash = await rollup.latestConfirmed();\nTo resolve assertionHash to a specific child chain block, query the Rollup's AssertionCreated events for that hash and decode the afterState — it contains the last processed GlobalState (block number and send count). See the block-verification tutorial for a complete working example.The Rollup chain assertions vs. child chain blocksContents of an assertionDelaysStaking and validator incentivesStaking mechanismHandling disputes and delaysVerifying a child chain block in a confirmed assertion","tokens":2098,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261491120,"hash":"584e98f23343e6cd0bab67c4f03170897eed7de2"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/24","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 19 / 26\n\n Nov 2023\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n post by leohio on Feb 12, 2022\n\n post by experience on Feb 12, 2022\n\n post by Killari on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n post by kravets on Aug 3, 2023\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n post by devfans on Nov 16, 2023\n\n devfans\n\n Hi, correct me if I am wrong. Assuming the below condition:\nAlice deposits 1 BTC to a deposit address generated by the generators and gets the ciphertext CT, and then mints 1 WBTC on the Ethereum chain.\nThe current Ethereum PoS network is maintained by a group of validators, say it’s group A. And a group named B, is a 2/3 subset of the group A. Say after a year, the group B validators exited the PoS network and withdraw their stake. Then they forked the chain from the checkpoint one year before, thus they wont get slashed even they publish the headers in OP_RETURNs, while they can still burn 1 WBTC to the contract to forge a witness to satisfy the circuit, thus recover the private key with Alice’s ciphertext CT. Does this assumption hold? This a common case for a PoS network according to my understanding.\nBTW, is there an implemented PoC version of this brilliant idea? Published somewhere to check? or A plan to implement it?\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n leohio\n\nThe ciphertexts get generated when the deposit address is generated. So it already exists before he/she deposits BTC there.\n\nIf the BLS signature on a forked chain is published in OP_RETURN, they get slashed.\nAnd even trying that is dangerous for them since only one honest node can reveal that to make them slashed.\n\nThe update is here.\nIt’s not fully inheriting the security assumption, but this is the practical approach that comes after this post.\nhttps://ethresear.ch/t/octopus-contract-and-its-applications/\n\n post by karl-lolme on Dec 19, 2023\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n post by karl-lolme on Apr 3, 2024\n\n Powered by Discourse","tokens":1340,"squid":"ink-research","role":"Deep Scholar","at":1791261491167,"hash":"7aaf30a3e823afe7ab180be7c385e10eb1760e4f"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/anytrust-protocol","domain":"docs.arbitrum.io","title":"AnyTrust Protocol | Arbitrum Docs","text":"✏️Request an updateAnyTrust is a variant of the Arbitrum Nitro technology that lowers costs by accepting a mild trust assumption.\nThe Arbitrum protocol requires that all Arbitrum nodes, including validators (nodes that verify the correctness of the chain and place bonds on correct results), have access to the data of every child chain transaction in the Arbitrum chain’s inbox. An Arbitrum Rollup provides data access by posting the data (in batched, compressed form) on the parent chain, Ethereum, as blobs or calldata. The Ethereum gas used to pay for this is the largest component of the cost of using Arbitrum.\nAnyTrust relies instead on an external Data Availability Committee (DAC) to store data and provide it on demand. The DAC has N members, of which AnyTrust assumes at least two are honest. This means that if N - 1 DAC members promise to provide access to some data, at least one of them must be honest. Since there are two honest members and only one failed to keep the promise, it follows that at least one of the promisers must be honest, and that honest member will provide data when needed to ensure the chain can properly function.\nKeysets​\nA Keyset specifies the Boneh–Lynn–Shacham (BLS) public keys of DAC members and the number of signatures required for a Data Availability Certificate (DACert) to be valid. Keysets enable DAC membership changes and allow DAC members to change their keys.\nA Keyset contains:\n\nThe number of DAC members, and\nFor each DAC member, a BLS public key, and\nThe number of DAC signatures required.\n\nKeysets are identified by their hashes. A parent chain KeysetManager contract maintains a list of currently valid Keysets. The child chain’s Owner can add or remove Keysets from this list. When a Keyset becomes valid, the KeysetManager contract emits a parent-chain Ethereum event that includes the Keyset’s hash and full contents. This allows the contents to be recovered later by anyone, given only the Keyset hash.\nAlthough the API does not limit the number of Keysets that can be valid simultaneously, only one Keyset is normally valid.\nData Availability Certificates (DACert)​\nA central concept in AnyTrust is the Data Availability Certificate (hereafter, a \"DACert\"). A DACert contains:\n\nThe hash of a data block\nAn expiration time\nProof that the N - 1 DAC members have signed the pair (hash, expiration time), consisting of:\n\nThe hash of the Keyset used in signing\nA bitmap showing which DAC members signed\nA BLS aggregated signature (over the BLS12-381 curve) proving that those parties signed.\n\nBecause of the 2-of-N trust assumption, a DACert constitutes proof that the block’s data (i.e., the preimage of the hash in the DACert) will be available from at least one honest DAC member, at least until the expiration time expires.\nIn regular Arbitrum Nitro, the Arbitrum Sequencer posts data blocks on the parent chain as blobs or calldata. The hashes of the data blocks are committed to the parent chain Inbox contract, allowing the data to be reliably read by the child chain code.\nAnyTrust gives the Sequencer two ways to post a data block on the parent chain: it can post the full data as above, or it can post a DACert proving availability of the data. The parent chain Inbox contract will reject any DACert that uses an invalid Keyset; the other aspects of DACert validity are checked by the child chain code.\nThe child chain code that reads data from the inbox reads a full-data block as in ordinary Arbitrum Nitro. If it sees a DACert instead, it checks the DACert's validity, using the Keyset specified by the DACert (which is known to be valid because the parent chain inbox verified it). The child chain code verifies that:\n\nThe number of signers is equal to or greater than the number required by the Keyset\nThe aggregated signature is valid for the claimed signers\nThe expiration time is at least two weeks after the current child chain timestamp\n\nIf the DACert is invalid, the child chain code discards it and proceeds to the next data block. If the DACert is valid, the child chain code reads the data block, which is guaranteed to be available because the DACert is valid.\nData Availability Servers (DAS)​\nDAC members run the Data Availability Server (DAS) software. The DAS exposes two APIs:\n\nThe Sequencer API, intended only for the Arbitrum chain’s Sequencer, is a JSON-RPC interface that enables the Sequencer to submit data blocks to the DAS for storage. Production deployments will typically block access to this API from callers other than the Sequencer.\nThe REST API, intended to be available to the world, is a RESTful HTTP(s)-based protocol that allows data blocks to be fetched by hash. This API is fully cacheable, and deployments may use a caching proxy or CDN to increase scale and protect against DoS attacks.\n\nOnly DAC members have a reason to support the Sequencer API. We expect others to run the REST API, which is helpful (discussed below).\nThe DAS software, based on configuration options, can store its data in local files, in a BadgerDB database, on Amazon S3, or redundantly across multiple backing data stores. The software also supports optional caching in memory (using Bigcache) or in a Redis instance.\nSequencer-DAC interaction​\nWhen the Arbitrum Sequencer produces a data batch that it wants to post using the DAC, it sends the batch's data, along with the expiration time (normally, three weeks in the future) via RPC to all DAC members in parallel. Each DAC member stores the data in its backing store, indexed by the data's hash. Then the member signs the pair (hash, expiration time) using its BLS key, and returns the signature with a success indicator to the Sequencer.\nOnce the Sequencer has collected enough signatures, it can aggregate the signatures and create a valid DACert for the pair (hash, expiration time). The Sequencer then posts that DACert to the parent chain Inbox contract, making it available to the AnyTrust chain software on the child chain.\nThe batch poster is the Sequencer component that drives this exchange. It hands the sealed batch to the DAC through a single storage interface, so the same code path serves a DAC, a custom backend, or Ethereum itself.\nIf the Sequencer fails to collect enough signatures within a few minutes, it will abandon the attempt to use the DAC and will \"fall back to Rollup mode\" by posting the full data directly to the parent chain, as it would do in a non-AnyTrust chain. The child chain software can understand both data posting formats (via DACert or full data) and will handle each one correctly.KeysetsData Availability Certificates (DACert)Data Availability Servers (DAS)Sequencer-DAC interaction","tokens":1666,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261502719,"hash":"4b9d472ad72d3599f04d3b474386f5c96db03d96"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/26","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 21 / 26\n\n Nov 2023\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n post by leohio on Feb 12, 2022\n\n post by experience on Feb 12, 2022\n\n post by Killari on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n post by kravets on Aug 3, 2023\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n post by devfans on Nov 16, 2023\n\n devfans\n\n Hi, correct me if I am wrong. Assuming the below condition:\nAlice deposits 1 BTC to a deposit address generated by the generators and gets the ciphertext CT, and then mints 1 WBTC on the Ethereum chain.\nThe current Ethereum PoS network is maintained by a group of validators, say it’s group A. And a group named B, is a 2/3 subset of the group A. Say after a year, the group B validators exited the PoS network and withdraw their stake. Then they forked the chain from the checkpoint one year before, thus they wont get slashed even they publish the headers in OP_RETURNs, while they can still burn 1 WBTC to the contract to forge a witness to satisfy the circuit, thus recover the private key with Alice’s ciphertext CT. Does this assumption hold? This a common case for a PoS network according to my understanding.\nBTW, is there an implemented PoC version of this brilliant idea? Published somewhere to check? or A plan to implement it?\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n leohio\n\nThe ciphertexts get generated when the deposit address is generated. So it already exists before he/she deposits BTC there.\n\nIf the BLS signature on a forked chain is published in OP_RETURN, they get slashed.\nAnd even trying that is dangerous for them since only one honest node can reveal that to make them slashed.\n\nThe update is here.\nIt’s not fully inheriting the security assumption, but this is the practical approach that comes after this post.\nhttps://ethresear.ch/t/octopus-contract-and-its-applications/\n\n post by karl-lolme on Dec 19, 2023\n\n karl-lolme\n\n It was mentioned in the Octopus Contracts post that\n“This mechanism primarily enhances the performance of the previous research\nresult, Trustless Bitcoin Bridge with Witness Encryption (TBBWE) [19], to a\npractical level.”\nCan I ask how “impractical” is the performance of this design? Is it wait time during withdrawal, computational gas cost, or something else?\nThanks\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n post by karl-lolme on Apr 3, 2024\n\n Powered by Discourse","tokens":1437,"squid":"ink-research","role":"Deep Scholar","at":1791261502845,"hash":"702873c93be5e4d7238ef3c157ee36bf0014aab2"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/32","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 26 / 26\n\n Apr 2024\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n leohio\n\n I am fed back the concern that the circuitry of the WE may become inconsistent during a hard fork, making decryption impossible, but this is solvable and something we did not mention in this paper for simplicity.\nIn a simple construction, we consider the block header as a target for signature by PoS validators, but what we really want the circuit to validate is the irreversible inclusion of the states into the Merkle Root. The circuit should be fine as long as this is satisfied.\nIf we hard fork to a Layer1 configuration that does not have irreversible inclusion, that would put Layer1 in danger.\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for the feedback with the information on the many protocols.\nI think the priority is answering this part.\n\nThe difference is simply here:\nIf the threshold is T of N of the multi-sig,\nSafety Byzantine fault tolerance of multi-sig with witness encryption: N-1 / N (99% tolerance)\nSafety Byzantine fault tolerance of multi-sig with Shnorr threshold signature: T / N\nLiveness Byzantine fault tolerance of multi-sig with witness encryption: N / N (No one can stop it)\nLiveness Byzantine fault tolerance of multi-sig with Shnorr threshold signature: N-T / N (If N-T+1 nodes go offline, the system stops)\nThe trade-off of Safety(Security) and Liveness shifts to a better way.\nSo I can say this part stronger, “There’re no key holders, there’re cipher text holders.”\n\nDFINITY’s threshold and its chain-key technology are quite smart but they are still relying on the online/liveness assumption of the validator in the subnet.\n\nAnd about here,\n\nThe deposit addresses are one-time-use and with fixed amounts, since once the secret key is revealed by the decryption of WE, the decryptor can take everything from this private key after that.\nThere’s no split of UTXOs in this system.\nTo prevent the collision during the time before a several blocks confirmation, the deposit address needs to be booked by the depositor.\nThe generators are different from depositors, and this fact is misleading as this system relies on the liveness/online assumption of somebody. This system is independent of generators by the MPC setup including multi-sig. This setup has features similar to the Power of Tau ceremony of zkSNARKs.\nI’m looking forward to having your feedback again.\n\n post by experience on Feb 12, 2022\n\n experience\n\n Very interesting proposal, I had been looking forward to promising applications of Witness Encryption and this looks like it! I have many questions but let’s start with three:\n1/ Is it correct that in your proposed scheme, the entire set of key pairs for deposit addresses is generated in an initial trusted setup, such that when we run out of addresses, another trusted ceremony would need to take place?\n2/ Are you suggesting to store the ciphertexts in an on-chain contract? I imagine this would be a mapping to keep track of which ciphertexts have been decrypted by users who completed a withdrawal request.\n3/ You say that the proof of inclusion can be verified by zkp circuits ifor Ethereum PoS too, but how exactly would you go about this without your proof program running a node that connects to the network? For PoW we can just verify that the cumulative proof of work of the series of block header (of which one contains the event log) is sufficiently high with minimal security tradeoffs, but on PoS you need to verify that you have the correct genesis state, and that the majority of signers that signed a block are indeed mainnet signers, and not signers of some other locally spawned fork \nBrilliant idea overall, looking forward to reading more about this!\n\n post by Killari on Feb 12, 2022\n\n Killari\n\n leohio\n\n Hey,\nThank you for the reading material :). I checked them through and I think I understand this better now. I think you need to be able to formulate Ethereum light client as a exact cover problem, which then reveals the private key of the bitcoin deposit. In PoW version you make the client just verify the pow and that it contains the right transactions (the deposit and the wbtc burn). In PoS you do the same but with validator signatures.\nThis made me to start to think how to attack this system, and the clear way to attack this is that when someone makes a btc deposit and mints the wbtc, you fork the Ethereum chain and start mining. Let’s assume we require 10 eth blocks worth of PoW in the proof. This would mean that once a deposit is made, attacker starts to mine on PRIVATE fork of the Ethereum starting from the deposit block. Once the attacker has been able to mine 10 blocks, they can produce the proof and steal the money. This fork is never published, there’s no direct competition. The only competition is that someone could withdraw the money using the purposed way.\nTo perform this attack, the miner needs to be able to produce 10 blocks worth of work. This cost should be higher than what the btc deposit is worth, for the system to be economically to secure by game theory. Ofcourse a suicidal whale could burn more money to steal the btc.\nHowever, this attack gets worse, as the attacker can steal ALL the deposits with the same 10 proof of work blocks… To combat this I guess one could make the withdrawal process work in a way that you can only withdraw one deposit at once and then you need to wait some amount of time until a new withdrawal can be started. This ensures that each robbery would require the same 10 pow blocks. This would hinder the usability of the protocol.\nDo you happen to have a discord server or similar to chat more about this topic? It would be interesting to collaborate!\n\n post by leohio on Feb 12, 2022\n\n leohio\n\nYes, let’s!!\n\nYes, we need it when we are short of deposit addresses.\n\nYes, on-chain or on a data-shard is the best way. Anyway, we need put data related to the ciphertexts to the input of zkp circuits which are proving the relationship between deposit addresses and ciphertexts. Without this, a depositor can put bitcoin into a faked deposit address. This circuit needs to guarantee that withdrawers can decrypt the ciphertexts when they burn Wrapped BTC, as described in this part.\n\nThen, about this.\n\nThis is prevented like this way. This is not my idea but Barry’s idea.\n\nFirst of all, the block signers of the faked offchain blockchain can be slashed and punished when only one honest person publishes it, among the colluded signers. This is the slash mechanism of Ethereum against the double votes to the fork. But when the colluded signers use MPC to eliminate the honest person, this security collapses. Then the signs or the hint/index of the signs should be published on Bitcoin blockchain. The OP_RETURN space is rather small, so some kind of an index to search this sign data is better to be written in OP_RETURN. Finally, the colluded signers cannot generate faked chains out of the network secretly.\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for attacking this virtually!\n\nI think this is exactly what we intended to prevent with this mechanism.\n\nIs this answering your question?\nThis is the cost comparison between the mega slash event of 1/3 of PoS validators and unlocking all of the Wrapped BTC in this system in the worst case, and there’s no guarantee to succeed this attack while the mega slash will certainly happen.\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n igorsyl\n\n @leohio @KanaPalladium : thank you for working on this! A couple of questions:\n\nWhat progress has been made since this post was published over a year ago, and\nis the prototype described above available publicly?\n\nIn the meantime, the current prototype requires about 20 minutes to encrypt a message using a tiny problem. Therefore, we need to develop various speedup methods to implement a real-world Wrapped Bitcoin.\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n leohio\n\n I made sure that “KanaPalladium” was not my co-author more than one year ago. Sorry to be late for reporting this.\nMy co-author, whose name was encrypted, said he had no account named “KanaPalladium.” And his name is not “Hiro.”\nThe person who uses the account knows me I guess, but please don’t receive any invitation from him just in case. Ignore the account if he talks about “investment to WE project.”\nEncrypting the author’s name was a mistake. I highly recommend people not to try it.\n\nBasically, no update, and just waiting for new WEs. But signature-based WE (https://fc23.ifca.ai/preproceedings/189.pdf) can be useful enough to update this architecture.\nADP can remain the best unless we have the multi-pairing.\nThe weakness of ADP is that one gate increases the length of cipher-text (memory consumption) 4x.\nSo, the direction is to make it with fewer constraints or to update WE to avoid ADP.\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n kravets\n\n kravets\n\n AI summary of recent practical WE algos\nhttps://app.cognosys.ai/s/a6AyKlf\n\n post by kravets on Aug 3, 2023\n\n kravets\n\n Links 2, 3, 4 here are the paper, the presentation PDF and the video of what might be the state of the art in WE\nhttps://www.google.com/search?q=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&oq=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&aqs=chrome..69i57.1511j0j1&sourceid=chrome&ie=UTF-8\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n post by devfans on Nov 16, 2023\n\n devfans\n\n Hi, correct me if I am wrong. Assuming the below condition:\nAlice deposits 1 BTC to a deposit address generated by the generators and gets the ciphertext CT, and then mints 1 WBTC on the Ethereum chain.\nThe current Ethereum PoS network is maintained by a group of validators, say it’s group A. And a group named B, is a 2/3 subset of the group A. Say after a year, the group B validators exited the PoS network and withdraw their stake. Then they forked the chain from the checkpoint one year before, thus they wont get slashed even they publish the headers in OP_RETURNs, while they can still burn 1 WBTC to the contract to forge a witness to satisfy the circuit, thus recover the private key with Alice’s ciphertext CT. Does this assumption hold? This a common case for a PoS network according to my understanding.\nBTW, is there an implemented PoC version of this brilliant idea? Published somewhere to check? or A plan to implement it?\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n leohio\n\nThe ciphertexts get generated when the deposit address is generated. So it already exists before he/she deposits BTC there.\n\nIf the BLS signature on a forked chain is published in OP_RETURN, they get slashed.\nAnd even trying that is dangerous for them since only one honest node can reveal that to make them slashed.\n\nThe update is here.\nIt’s not fully inheriting the security assumption, but this is the practical approach that comes after this post.\nhttps://ethresear.ch/t/octopus-contract-and-its-applications/\n\n post by karl-lolme on Dec 19, 2023\n\n karl-lolme\n\n It was mentioned in the Octopus Contracts post that\n“This mechanism primarily enhances the performance of the previous research\nresult, Trustless Bitcoin Bridge with Witness Encryption (TBBWE) [19], to a\npractical level.”\nCan I ask how “impractical” is the performance of this design? Is it wait time during withdrawal, computational gas cost, or something else?\nThanks\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n kravets\n\n New claim of a practical WE scheme\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n leohio\n\n I’ve forgotten to share this.\nThe recent hot topic regarding making a trustless bitcoin bridge is BitVM.\nSeems you can unlock bitcoin with ZKP.\nI’m not 100% sure it works for the bridge, but I truly believe that it’s worth exploring.\n\n post by karl-lolme on Apr 3, 2024\n\n karl-lolme\n\n tx for sharing; this is very helpful\n\n Powered by Discourse","tokens":3777,"squid":"ink-research","role":"Deep Scholar","at":1791261513182,"hash":"cc68e35c52754033d39c2d4a10fe5fbac5a77fba"}
{"url":"https://governance.aave.com/c/risk/7","domain":"governance.aave.com","title":"Latest Risk topics - Aave","text":"Latest topics in Risk\n\n Risk\n\n subcategories\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [ARFC] Aave Risk Framework\n\n Risk\n\n Summary\nThis framework sets the risk standard that governs every asset on Aave V3, V4, and Aave Horizon. It is binding at onboarding, at every quarterly due diligence refresh, at every material-change re-evaluation, a…\n\n read more\n\n 9\n\n 2.7k\n\n Jul 31\n\n Risk Stewards: Supply and Borrow Cap Reductions on Aave V3 / 2026.08.10\n\n Risk\n\n 3\n\n 201\n\n 1d\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.10.01\n\n Risk\n\n 0\n\n 92\n\n 4d\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d\n\n Syrup USDC (syrupUSDC) on Aave Arc Assessments\n\n Assessments\n\n 1\n\n 84\n\n 7d\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28\n\n Risk\n\n 0\n\n 110\n\n 8d\n\n Risk Stewards: Supply and Borrow Cap Changes on Aave V3 / 2026.09.22\n\n Risk\n\n 1\n\n 167\n\n 12d\n\n Coinbase B20 Equities on Base Assessments\n\n Assessments\n\n 1\n\n 154\n\n 12d\n\n Ethena USDe on Aave Avalanche Assessments\n\n Assessments\n\n 1\n\n 101\n\n Sep 18\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.18\n\n Risk\n\n 0\n\n 133\n\n Sep 18\n\n Wrapped Ether (WETH) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 170\n\n Sep 18\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 105\n\n Sep 18\n\n Circle EUR (EURC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 87\n\n Sep 18\n\n Circle USD (USDC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 99\n\n Sep 18\n\n [Risk Stewards] September 2026 - WETH Interest Rate Adjustment on Base\n\n Risk\n\n 0\n\n 80\n\n Sep 18\n\n EUR CoinVertible (EURCV) on Aave Ethereum\n\n Assessments\n\n 1\n\n 101\n\n Sep 17\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.16\n\n Risk\n\n 0\n\n 122\n\n Sep 16\n\n BTC.b on Aave Ethereum\n\n Assessments\n\n 1\n\n 75\n\n Sep 16\n\n [Gho Stewards] September 2026 - GHO Parameter Update\n\n General\n\n 0\n\n 143\n\n Sep 15\n\n Mainnet wstETH Liquidation Assessment: Financing Remains Unverified\n\n Assessments\n\n 0\n\n 79\n\n Sep 15\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.15\n\n Risk\n\n 0\n\n 105\n\n Sep 15\n\n AL Technical Assessment Aave <> Arc\n\n Assessments\n\n 0\n\n 141\n\n Sep 14\n\n Aave v3-v4 liquidation bot\n\n Liquidation\n\n 9\n\n 469\n\n Sep 11\n\n Risk Stewards: IRM Changes on Aave V3 / 2026.09.11\n\n Risk\n\n 0\n\n 156\n\n Sep 11\n\n Independent finding: a DeFi Saver admin signer is also one of Aave’s own Governance Guardian signers\n\n General\n\n 0\n\n 83\n\n Sep 11\n\n [Risk Stewards] Monad Stablecoin IRM Adjustments: Slope1 to 5.00%\n\n Risk\n\n 0\n\n 134\n\n Sep 11\n\n Circle USD (USDC) on Aave X Layer Assessments\n\n Assessments\n\n 2\n\n 273\n\n Sep 10\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.09\n\n Risk\n\n 0\n\n 149\n\n Sep 9\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.07\n\n Risk\n\n 0\n\n 167\n\n Sep 7\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.04\n\n Risk\n\n 0\n\n 149\n\n Sep 4","tokens":729,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261518787,"hash":"ab546c2fca7ba779579e99eb612105b669526111"}
{"url":"https://ethereum.org/apps/ethena-usde/","domain":"ethereum.org","title":"Ethereum Apps - Ethena - USDE | ⁦ethereum.org⁩","text":"DeFiEthena - USDEby Ethena LabsEnglish Visit Ethena - USDE (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextUniswapSee nextUniswapEthena is a synthetic dollar protocol built on Ethereum that provides a crypto-native solution for money, USDe, alongside a globally accessible dollar savings asset, sUSDe.InfoFounded2024CreatorEthena LabsLast updated457 days agoGalleryMore apps like thisDeFiSky/Maker - USDSSky.money is a non-custodial gateway to the decentralized Sky Protocol, which centers around the USDS stablecoin.Stablecoin issuance · RWA · Lending and borrowingDeFiPendlePendle is a DeFi protocol focused on yield trading, allowing users to both fix or leverage their yield.RWADeFiSparkSpark Fi is a non-custodial DeFi protocol that allows users to lend and borrow digital assets through SparkLend, while earning passive income via the USDS stablecoin and its associated Sky Savings Rate.Lending and borrowing · RWA","tokens":241,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261518827,"hash":"7b2c478e0a79609da26e118a32b055946dba2acd"}
{"url":"https://governance.aave.com/t/risk-stewards-cap-and-irm-changes-on-aave-v3-2026-09-28/25718/1","domain":"governance.aave.com","title":"Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28 - Risk - Aave","text":"Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28 \n\n Risk\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Summary\n\n USDT Optimal Utilization (Aave V3 Core)\n\n Withdrawal Liquidity\n\n USDe Interest Rate Model\n\n Base Rate Anchor\n\n JAAA (Aave V3 Horizon)\n\n Supply Distribution\n\n Recommendation\n\n Cap Reductions\n\n Specification\n\n Caps\n\n IRM\n\n Next Steps\n\n Disclosure\n\n Sep 28\n\n 1 / 1\n\n Sep 27\n\n 8d ago\n\n post by LlamaRisk on Sep 28\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk recommends the following parameter changes based on user behavior, on-chain liquidity, and position health observed in the latest review of Aave V3 reserves.\n\nIncrease the supply cap for JAAA on Aave V3 Horizon from 50M to 60M.\nIncrease the optimal utilization for USDT on Aave V3 Core from 93.00% to 94.00%.\nIncrease the USDe base rate from 6.30% to 6.60% on Aave V3 Core, Avalanche, Mantle, Monad, and Plasma.\nSupply and borrow cap reductions for assets across V3 Core, Monad, Plasma, Mantle, and Base.\n\nUSDT Optimal Utilization (Aave V3 Core)\nThe recommendation moves the optimal utilization point on USDT from 93.00% to 94.00%. The base rate, Slope1, and Slope2 are unchanged.\nSince the optimal point was set to 93% on September 16, 2026, USDT utilization has held at the kink, with a median of 93.0% and approximately half of observation period at or above it. Over the same period supply declined from approximately 3.17B to 2.89B while borrows held near 2.70B. At the current 92.8% utilization, the post-change variable borrow rate would be 4.34% APR, down from 4.39% under the current IRM, and the supply rate would be 3.63% APR, down from 3.67%.\nWithdrawal Liquidity\nThe optimal point sets how much of the supply remains available for withdrawal when the reserve is at its intended operating level. Moving it up by one percentage point converts exit liquidity into borrow capacity.\n\nInstance\nAsset\nSupplied\nBorrowed\nUtilization\nIdle Liquidity\n\nAave V3 Core\nUSDT\n2,894.4M\n2,686.1M\n92.8%\n208.3M\n\nInstance\nAsset\nBuffer at Optimal (current)\nBuffer at Optimal (new)\nChange\nBorrow Headroom to Optimal (current)\nBorrow Headroom to Optimal (new)\n\nAave V3 Core\nUSDT\n202.6M\n173.7M\n-28.9M\n5.7M\n34.6M\n\nThe change adds approximately 28.9M of borrow capacity before Slope2 engages and reduces the withdrawal buffer at the optimal point by the same amount, a 14.3% relative reduction.\nUSDe Interest Rate Model\nThe recommendation raises the USDe base rate from 6.30% to 6.60% on all five deployments that carry USDe. The optimal utilization point, Slope1, and Slope2 are unchanged on every reserve.\n\nInstance\nUtilization\nuOptimal\nCurrent Borrow APR\nNew Borrow APR\nDelta\n\nAave V3 Core\n7.9%\n90.0%\n6.32%\n6.62%\n+30 BPS\n\nAave V3 Plasma\n7.0%\n85.0%\n6.32%\n6.62%\n+30 BPS\n\nAave V3 Monad\n1.3%\n90.0%\n6.30%\n6.60%\n+30 BPS\n\nAave V3 Mantle\n0.1%\n85.0%\n6.30%\n6.60%\n+30 BPS\n\nAave V3 Avalanche\n80.0%\n80.0%\n6.55%\n6.85%\n+30 BPS\n\nThese five reserves carry approximately 83.3M in aggregate USDe debt against approximately 1.19B supplied. Since the base rate was set to 6.30% on September 12, 2026, aggregate USDe debt has declined from approximately 179.1M.\nBase Rate Anchor\nThe 7d mean sUSDe APY through September 23, 2026 stands at 5.00% and the 30d mean at 4.83%. Grossed up for the 25% reserve factor that applies to USDe on all five reserves, these correspond to 6.66% and 6.44% APY.\nimage2055×1037 261 KB\nSource: LlamaRisk, September 28, 2026\nJAAA (Aave V3 Horizon)\nJAAA, the Janus Henderson Anemoy AAA CLO Fund token, sits at 88.9% supply cap utilization on Aave V3 Horizon, with 44.4M supplied against a cap of 50M.\nSupply Distribution\nimage2880×1440 206 KB\nSource: LlamaRisk, September 28, 2026\nThe supplier base is concentrated: the largest position holds approximately 30.5% of supply, the top three hold approximately 75.1%, and every top supplier carries debt with a health factor between 1.02 and 1.11, with a median of 1.07. The debt is entirely stablecoin, approximately 34.2M in RLUSD and approximately 23.9M in GHO, so health factor stability tracks the JAAA price.\nRecommendation\nThe proposed cap of 60M is approximately 1.35x the current outstanding supply, resulting in approximately 74.1% post-change cap utilization.\nCap Reductions\n\nwstETH on Aave V3 Core sits at 71.2% supply cap utilization. The proposed cap of 950K is approximately 1.21x current outstanding supply, landing at approximately 82.4% post-change cap utilization.\nUSDe on Aave V3 Core sits at 64.8% supply cap utilization. The proposed cap of 700M is approximately 1.20x current outstanding supply, landing at approximately 83.5% post-change cap utilization. The borrow cap moves to 50M, landing at approximately 87.0% post-change borrow cap utilization.\nsUSDe on Aave V3 Core sits at 54.5% supply cap utilization. The proposed cap of 175M is approximately 1.29x current outstanding supply, landing at approximately 77.8% post-change cap utilization.\nUSDe on Aave V3 Monad sits at 35.1% supply cap utilization. The proposed cap of 100M is approximately 1.90x current outstanding supply, landing at approximately 52.7% post-change cap utilization. The borrow cap moves to 10M, approximately 14.9x current outstanding borrows, landing at approximately 6.7% post-change borrow cap utilization.\nsyrupUSDT on Aave V3 Plasma sits at 32.4% supply cap utilization. The proposed cap of 50M is approximately 1.54x current outstanding supply, landing at approximately 64.7% post-change cap utilization.\nsyrupUSDT on Aave V3 Mantle sits at 25.1% supply cap utilization. The proposed cap of 40M is approximately 1.99x current outstanding supply, landing at approximately 50.2% post-change cap utilization.\nweETH on Aave V3 Base sits at 33.9% supply cap utilization. The proposed cap of 20K is approximately 1.31x current outstanding supply, landing at approximately 76.4% post-change cap utilization.\nwstETH on Aave V3 Base sits at 41.0% supply cap utilization. The proposed cap of 15K is approximately 1.46x current outstanding supply, landing at approximately 68.3% post-change cap utilization.\nsyrupUSDC on Aave V3 Base sits at 0.5% supply cap utilization. The proposed cap of 10M lands at approximately 1.1% post-change cap utilization.\n\nSpecification\nCaps\n\nInstance\nAsset\nCurrent Supply Cap\nRecommended Supply Cap\n\nAave V3 Core\nwstETH\n1,100,000\n950,000\n\nAave V3 Core\nUSDe\n902,000,000\n700,000,000\n\nAave V3 Core\nsUSDe\n250,000,000\n175,000,000\n\nAave V3 Monad\nUSDe\n150,000,000\n100,000,000\n\nAave V3 Plasma\nsyrupUSDT\n100,000,000\n50,000,000\n\nAave V3 Mantle\nsyrupUSDT\n80,000,000\n40,000,000\n\nAave V3 Base\nweETH\n45,000\n20,000\n\nAave V3 Base\nwstETH\n25,000\n15,000\n\nAave V3 Base\nsyrupUSDC\n21,000,000\n10,000,000\n\nAave V3 Horizon\nJAAA\n50,000,000\n60,000,000\n\nInstance\nAsset\nCurrent Borrow Cap\nRecommended Borrow Cap\n\nAave V3 Core\nUSDe\n100,000,000\n50,000,000\n\nAave V3 Monad\nUSDe\n36,000,000\n10,000,000\n\nIRM\n\nInstance\nAsset\nCurrent Optimal Usage Ratio\nRecommended Optimal Usage Ratio\n\nAave V3 Core\nUSDT\n93.00%\n94.00%\n\nInstance\nAsset\nCurrent Base Rate\nRecommended Base Rate\n\nAave V3 Core\nUSDe\n6.30%\n6.60%\n\nAave V3 Avalanche\nUSDe\n6.30%\n6.60%\n\nAave V3 Mantle\nUSDe\n6.30%\n6.60%\n\nAave V3 Monad\nUSDe\n6.30%\n6.60%\n\nAave V3 Plasma\nUSDe\n6.30%\n6.60%\n\nNext Steps\nWe will move forward and implement these updates via the Risk Steward process. The implemented changes can be reviewed on the LlamaRisk Risk Stewards Dashboard.\nDisclosure\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.08.31\n\n Risk\n\n 0\n\n 198\n\n Aug 31\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.16\n\n Risk\n\n 0\n\n 122\n\n Sep 16\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.15\n\n Risk\n\n 0\n\n 105\n\n Sep 15\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.07\n\n Risk\n\n 0\n\n 167\n\n Sep 7\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.18\n\n Risk\n\n 0\n\n 133\n\n Sep 18","tokens":2084,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261541029,"hash":"9e391ac62165e29ba38ca5fc37f8c44d855437f6"}
{"url":"https://ethereum.org/apps/pendle/","domain":"ethereum.org","title":"Ethereum Apps - Pendle | ⁦ethereum.org⁩","text":"DeFiPendleby Pendle FinanceEnglish, Chinese Visit Pendle (opens in a new tab) (opens in a new tab) (opens in a new tab) (opens in a new tab)See nextSparkSee nextSparkPendle is a DeFi protocol focused on yield trading, allowing users to both fix or leverage their yield.InfoFounded2021CreatorPendle FinanceLast updated457 days agoGalleryMore apps like thisDeFiSky/Maker - USDSSky.money is a non-custodial gateway to the decentralized Sky Protocol, which centers around the USDS stablecoin.Stablecoin issuance · RWA · Lending and borrowingDeFiEthena - USDEEthena is a synthetic dollar protocol built on Ethereum that provides a crypto-native solution for money, USDe, alongside a globally accessible dollar savings asset, sUSDe.RWA · Stablecoin issuance · YieldDeFiSparkSpark Fi is a non-custodial DeFi protocol that allows users to lend and borrow digital assets through SparkLend, while earning passive income via the USDS stablecoin and its associated Sky Savings Rate.Lending and borrowing · RWA","tokens":249,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261541138,"hash":"fd4cd1371049767a9ae90f98fc396db69ee7f220"}
{"url":"https://forum.openzeppelin.com/c/support/contracts/18","domain":"forum.openzeppelin.com","title":"Latest Support/Contracts topics - OpenZeppelin Forum","text":"Latest topics in Contracts\n\n Contracts\n\n OpenZeppelin Contracts Support\n\n Support\n\n Contracts\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Review Request: AOXC Upgradeable Token with Inflation Control & Daily Limits\n\n erc20,solidity,upgrades\n\n 0\n\n 75\n\n Feb 2\n\n Install @openzeppelin/community-contracts\n\n multisig\n\n 2\n\n 70\n\n Jan 4\n\n Why was the Approval event removed from transferFrom\n\n 0\n\n 62\n\n Nov 2025\n\n safeApprove… forever loop with remix\n\n 0\n\n 49\n\n Nov 2025\n\n // The following functions are overrides required by Solidity\n\n 4\n\n 2.7k\n\n Oct 2025\n\n ERC2771ContextUpgradeable implementation\n\n erc721\n\n 8\n\n 275\n\n Aug 2025\n\n About governance contract in version 5.4.0\n\n erc20,solidity\n\n 0\n\n 88\n\n Aug 2025\n\n Difference between initializer, reinitializer(1), and reinitializer(2) modifiers\n\n 8\n\n 1.5k\n\n Aug 2025\n\n Creation of ERC20PresetMinterPauser on Remix errored: Cannot convert undefined or null to object\n\n 5\n\n 2.4k\n\n Aug 2025\n\n Web3js intagration in html + JS please help me it wont display the ABI array in the browser like I told it to!\n\n web3js\n\n 0\n\n 34\n\n Jul 2025\n\n Plans for Generalization of ERC721\n\n erc721\n\n 0\n\n 25\n\n Jul 2025\n\n Complex conditional logic for function access with AccessManaged\n\n 2\n\n 210\n\n Jul 2025\n\n Error on ERC1967Proxy verification on https://testnet.opbnbscan.com\n\n etherscan-verify,upgrades\n\n 3\n\n 108\n\n May 2025\n\n Upgrading OpenZeppelin contracts-upgradeable from v5.x to v5.y\n\n upgrades\n\n 2\n\n 215\n\n May 2025\n\n Governor too big?\n\n 0\n\n 36\n\n Apr 2025\n\n Cannot do ERC20Votes in ERC4626\n\n 0\n\n 35\n\n Apr 2025\n\n Math.sol line 119 uses ^\n\n 0\n\n 60\n\n Apr 2025\n\n Differences between scheduled ops using TimelockController and AccessManager\n\n 0\n\n 40\n\n Apr 2025\n\n Block number and timestamp with governor and ivotes\n\n 1\n\n 53\n\n Mar 2025\n\n TransparentUpgradeableProxy double admin source\n\n 1\n\n 66\n\n Mar 2025\n\n Best practice for editing Open Zeppelin Import\n\n erc20\n\n 2\n\n 123\n\n Mar 2025\n\n Using checkpoints\n\n 1\n\n 215\n\n Mar 2025\n\n Is IERC20Upgradeable removed from contracts-upgradeable?\n\n upgrades\n\n 3\n\n 2.5k\n\n Mar 2025\n\n Can I retrieve my tokens from this transaction\n\n erc20,etherscan-verify,bep20\n\n 11\n\n 163\n\n Mar 2025\n\n Difficulty Overriding safeTransferFrom in @openzeppelin/contracts-upgradeable@5.2.0\n\n erc721\n\n 3\n\n 104\n\n Mar 2025\n\n ReentrancyGuard vs ReentrancyGuardTransient gas saving\n\n openzeppelin-contracts,gas\n\n 5\n\n 530\n\n Feb 2025\n\n Using ERC165 supportsInterface() causes MetaMask and Etherscan Warnings\n\n 2\n\n 69\n\n Feb 2025\n\n Should ReentrancyGuard be always initialized in an upgradable contract? Will the protection work when not initialized?\n\n 6\n\n 385\n\n Feb 2025\n\n The identity precompile can be used to bypass ERC-1271 signature checks\n\n 4\n\n 200\n\n Feb 2025\n\n ERC20Snapshot Alternative in new OZ Library\n\n 22\n\n 2.4k\n\n Jan 2025","tokens":704,"squid":"ink-security_audits","role":"Sentinel","at":1791261543878,"hash":"e1ab5cc475aad557f9f021362328174d2b808083"}
{"url":"https://ethereum.org/stablecoins/","domain":"ethereum.org","title":"Stablecoins explained: What are they for? | ⁦ethereum.org⁩","text":"What is a stablecoin?Stablecoins are cryptocurrencies without the volatility. They offer the same global reach and flexibility as ETH but hold a steady value, so you have access to everyday digital money to use across the Ethereum network.Global & Easy TransfersStablecoins are global, and can be sent over the internet. They're easy to receive or send once you have an .Earn Through LendingDemand for stablecoins is high, so you can earn interest for lending yours. Make sure you're aware of the risks before lending.Exchange & UtilityYou can exchange stablecoins for ETH and other tokens. Many rely on stablecoins for stable, predictable transactions.Secure by DesignStablecoins are secured by . No one can forge transactions on your behalf.The infamous Bitcoin pizzaIn 2010, someone bought 2 pizzas for 10,000 bitcoin. While worth only $41 at the time, those assets are worth millions today. There are many similar stories of early spending on Ethereum. Because cryptocurrencies can appreciate in value, spending them may carry an opportunity cost. Stablecoins solve this volatility problem, so you can make everyday purchases while holding onto your ETH.How stablecoins workStablecoins use different methods to maintain a steady value. While most are backed by collateral held in reserve, others rely on smart contract algorithms. Select a category to see how common mechanisms work, their benefits, and trade-offs.Fiat-backedDigital representations of traditional fiat currencies like the US Dollar. You can purchase them at a 1:1 ratio with fiat and later redeem them with the issuer for the original underlying currency, which is held in reserves to back the stablecoin's value.Example projectsUSDC (opens in a new tab)USDT (opens in a new tab)ProsConsProsSafe against crypto volatility.Changes in price are minimal.ConsCentralized – someone must issue the tokens.Requires auditing to ensure company has sufficient reserves.Getting startedBefore you buy or receive stablecoins, you'll need a place to store them. The two most common options are:Download a walletRecommendedDownload an Ethereum wallet to hold and control your stablecoins directly, without intermediaries.Centralized exchangeUse a centralized exchange to buy and hold stablecoins, trusting the exchange to hold your assets.Choose a stablecoinThere are hundreds of stablecoins available on Ethereum. Use these prominent options as a starting point to research the best stablecoin for your needs.Different stablecoin types How to get stablecoins Editors' choicesExplore some of the most established stablecoins on Ethereum. These options are widely supported and frequently used to interact with dapps.USDSUSDS is the successor to Dai, fully backed by crypto and designed for onchain savings and rewards. Widely used in DeFi while keeping users in full control of their funds.Swap ETH for USDS (opens in a new tab)Learn about USDS (opens in a new tab)USDCUSDC is the largest US-regulated fiat-backed stablecoin. Its value is pegged to the US dollar, issued by Circle, and is widely used.Get USDC (opens in a new tab)Learn about USDC (opens in a new tab)GHOGHO is a decentralized multi-collateral stablecoin created by Aave. It uses a hybrid model that combines crypto-collateralized backing with a community governance approach.Swap ETH for GHO (opens in a new tab)Learn about GHO (opens in a new tab)Glo DollarGlo Dollar (USDGLO) is a stablecoin that donates all profits to public goods and charities. By holding or using Glo Dollar, you help fund causes like fighting poverty and supporting open-source—at no extra cost to you.Buy GLO (opens in a new tab)Learn about GLO (opens in a new tab)Top stablecoins by market capitalization Market capitalization is the total number of tokens that exist multiplied by the value per token. This list is dynamic and the projects listed here are not necessarily endorsed by the ethereum.org team.CurrencyMarket CapitalizationCollateral TypeTether (opens in a new tab)USDT$184,074,254,373FiatUSDC (opens in a new tab)USDC$74,013,707,231FiatUSDS (opens in a new tab)USDS$10,028,475,322CryptoEthena USDe (opens in a new tab)USDe$4,905,952,188CryptoDai (opens in a new tab)DAI$4,613,917,930CryptoPayPal USD (opens in a new tab)PYUSD$2,899,417,104FiatRipple USD (opens in a new tab)RLUSD$2,433,734,077FiatUSDD (opens in a new tab)USDD$1,559,535,094CryptoGHO (opens in a new tab)GHO$698,637,211CryptoUsual USD (opens in a new tab)USD0$542,693,049FiatHow to get stablecoinsThere are multiple ways to acquire stablecoins. Whether you are swapping existing assets, buying with fiat, or earning them through work, there is a path that fits your current needs.SwapRecommendedExchange your existing tokens for stablecoins using decentralized exchanges. This is often the most direct way to acquire them if you already have funds in a wallet.BuyPurchase stablecoins with traditional currency through centralized exchanges or directly within your wallet. Geographical restrictions may apply.EarnEarn stablecoins as compensation for work, bounties, or services. Many projects in the Ethereum ecosystem use them to provide stable, global payments.BorrowAdvancedYou can borrow some stablecoins by using crypto as collateral, which you have to pay back.3 - 7% interest rate with stablecoinsStrong demand to borrow stablecoins can create opportunities to earn above-average interest rates. When you deposit tokens into decentralized lending pools, you provide the capital for other people to borrow, or to power other financial apps and trading strategies.Apps to earn interest on stablecoinsPut your stablecoins to work by lending them through peer-to-peer lending apps. Interest rates (APY) are determined by market activity and fluctuate based on real-time supply and demand.AaveLending markets for stablecoins including Dai, USDC, TUSD, USDT, and more.Learn more (opens in a new tab)CompoundLend stablecoins and earn interest and $COMP, Compound's own token.Learn more (opens in a new tab)Summer.fiAn app designed to save, lend, borrow, and earn interest on stablecoins.Learn more (opens in a new tab)Spark ProtocolA savings account protocol to earn interest on USDC, USDT, PYUSD, USDS, or ETH.Learn more (opens in a new tab)Learn more about stablecoinsDashboard & EducationStablecoins.wtfStablecoins.wtf offers a dashboard with historical market data, statistics, and educational content for the most prominent stablecoins.Visit Stablecoins.wtf (opens in a new tab)StablepulseProvides a clear, accurate, and minimally filtered view of the stablecoin ecosystem with analytics across tokens and chains.Visit Stablepulse (opens in a new tab)Stables.infoLive stablecoin leaderboard and dashboard, tracking supply and onchain data for all major stablecoins and chains.Visit Stables.info (opens in a new tab)Dune Stablecoin MetricsDashboard delivering real-time insights into stablecoin supply, liquidity, trading volume, and adoption across blockchains.Visit Dune (opens in a new tab)Visa Onchain AnalyticsDashboard visualizing the movement, supply, and usage of fiat-backed stablecoins across public blockchains.Visit Visa (opens in a new tab)StablewarsAnalytics leaderboard and dashboard, tracking balances, transfers, and rankings for stablecoins across multiple blockchains.Visit Stablewars (opens in a new tab)Test your Ethereum knowledgeStablecoinsQuestion number 1:What is NOT a way to get stablecoins?","tokens":1850,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261551470,"hash":"28920dcfc0d5866583caa4c5f1af997190e2e7b0"}
{"url":"https://ethereum.org/wallets/find-wallet/","domain":"ethereum.org","title":"List of Ethereum wallets: compare by feature | ⁦ethereum.org⁩","text":"List of Ethereum wallets: compare by featureWallets store and transact your ETH. You can choose from a variety of products that tailor to your needs.Browse wallets by user typeNew to crypto 5 availableFirst time user looking for beginner wallet.Developer 13 availableWallets that help develop and test dapps.Finance 28 availableWallets focusing on frequent usage of DeFi apps.Hardware 9 availablePassive token holding with hardware wallets.NFTs 35 availableWallets with focus on NFT support.Browse all walletsWallets found: 48 / 48ClaveMobileEnglish Swap fee: 0.5%Edge WalletFinanceDesktop · MobileEnglish · Spanish Swap fee: 0.5% – 2%Coin WalletFinanceDesktop · MobileEnglish · Indonesian Swap fee: 0%Infinex Wallet & Crypto SuperappNFTsBrowserEnglish Swap/bridge fee: 0.03% – 0.3%MEW walletNew to cryptoNFTsMobileEnglish · Russian Swap fee: variableReady WalletFinanceNFTsMobile · BrowserEnglish Swap fee: 0.5%1inch WalletFinanceNFTsMobileEnglish · Russian Swap fee: variableBitget walletFinanceNFTsMobile · BrowserEnglish · Chinese Swap fee: variablePhantomFinanceMobile · BrowserEnglish · Spanish Swap fee: 0.85%Bridge walletMobileEnglish · French Swap fee: 0.5%, Buy/sell fee: 0.6% – 3.8%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%BlockWalletDeveloperFinanceBrowserEnglish Swap/bridge fee: 0.5%SafeFinanceNFTsMobileEnglish Swap fee: 0.05% – 0.7%, Staking fee: 20% of rewardsimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%TahoFinanceNFTsBrowserEnglish Swap fee: 0.5%Coin98 Super WalletFinanceNFTsMobile · BrowserEnglish · Vietnamese Swap fee: 0.5% (0.1% for stablecoins)ExodusFinanceDesktop · Mobile · BrowserEnglish Swap fee: from 0.5%Railway WalletDesktop · MobileEnglish Shield/unshield fee: 0.25%Uniswap WalletNFTsMobile · BrowserEnglish · Spanish Swap fee: 0%FrameDeveloperFinanceNFTsDesktop · BrowserEnglish Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerLoopring walletNFTsMobileEnglish · Chinese Swap fee: 0.3%Coinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%Unstoppable walletDeveloperNFTsMobileEnglish · French Swap fee: 0%BurnerHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish Device: $19/card, Swap fee: not disclosedZerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerio.finnet MPC wallet for BusinessNFTsMobileEnglish Free tier, paid plans from $399.99/monthRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%Gem WalletDeveloperNFTsDesktop · MobileEnglish · Spanish Swap fee: 0%, Buy fee: set by the providerRainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%AlphaWalletNFTsMobileEnglish · Chinese Swap fee: 0%GridPlus Lattice1HardwareNFTsDesktop · Browser · HardwareEnglish Device: $397Cypherock X1HardwareNFTsDesktop · HardwareEnglish · German Device: $99 – $179PillarXNFTsMobileEnglish Swap fee: 1%FoxWalletNFTsMobile · BrowserEnglish · Chinese Swap fee: 0%TrezorFinanceHardwareDesktop · Mobile · HardwareEnglish · Spanish Device: $59 – $129, Swap fee: variableLedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableShapeShiftFinanceMobile · BrowserEnglish · Spanish Swap/bridge fee: 0.5% (free under $1,000, FOX-holder discounts)KeystoneHardwareHardwareEnglish · Chinese Device: $149MetaMaskFinanceNFTsMobile · BrowserEnglish · Amharic Swap/bridge fee: 0.875%, Buy/sell fee: 1%NuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%TokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)imTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)Clear WalletDeveloperBrowserEnglish AmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%BraavosNFTsMobile · BrowserEnglish Swap fee: 0%EnkryptNFTsBrowserEnglish Swap fee: variableCake WalletDeveloperFinanceDesktop · MobileEnglish · Spanish Swap fee: variableHow we evaluate walletsEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.Read the full listing criteria and removal policyCurated by the ethereum.org editorial team.Most recent listing update: July 8, 2026To be listed, a wallet must meet the following requirements:Security-tested through audit, an internal security team, or open-source code review.Been live for at least six months, or built by a team with an established track record.Actively maintained, with support available for users.Provides honest, accurate listing information. Products that falsify details are removed.Has a named point of contact so we can verify information when it changes.Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.Listings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.Filter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.Wallets listed on this page are not official endorsements, and are provided for informational purposes only.Their descriptions have been provided by the wallet projects themselves.","tokens":1478,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261565502,"hash":"8fd55562428641d8e72ce89ea269c359e3572a16"}
{"url":"https://governance.aave.com/t/arfc-aave-risk-framework/25114/1","domain":"governance.aave.com","title":"[ARFC] Aave Risk Framework - Risk - Aave","text":"[ARFC] Aave Risk Framework \n\n Risk\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n 2\n\n read \n\n 31\n min\n\n Summary\n\n 1. Asset Risk\n\n 1.1 Asset Classification Adherence\n\n 1.2 Multi-Chain Evaluation Scope\n\n 1.3 Smart Contract Audit Coverage\n\n 1.4 Bug Bounty Coverage\n\n 1.5 Liquidity and Market Structure\n\n 1.6 Timelock Requirements\n\n 1.7 Signing Authority Decentralisation and Custody\n\n 1.8 Legal Disclosures\n\n 1.9 Holder Claims Seniority and Loss-Bearing Hierarchy\n\n 1.10 Asset Backing Structure and Visibility\n\n 1.11 Issuer Operational Stack Disclosure\n\n 1.12 Pre-Agreed Incident Communication Baseline\n\n 1.13 Hard-Block Conditions and Veto Authority\n\n 1.14 Continuous Due Diligence Cadence\n\n 1.15 Material-Change Taxonomy\n\n 1.16 Remediation Timelines and Residual Risk Treatment\n\n 1.17 Asset Deprecation Triggers\n\n 1.18 Oracle and Price-Feed Treatment\n\n 1.19 Market (Deployment) Deprecation Criterion\n\n 1.20 Market Deprecation Playbook\n\n 2. Bridging Risk\n\n 2.1 Bridge Topology Disclosure\n\n 2.2 Verifier Set Threshold Requirement\n\n 2.3 Verifier Independence Requirements\n\n 2.4 Mutable Send and Receive Libraries\n\n 2.5 Bridge Authority and Ownership Timelocks\n\n 2.6 Separate Pause Pathways\n\n 2.7 Custody Requirements at the Bridge Layer\n\n 2.8 Per-Route Rate Limiting Requirement\n\n 2.9 Rate Limit Sizing Methodology\n\n 2.10 24/7 Redphone and Incident Response Requirements\n\n 2.11 Dedicated Security and Monitoring Team Requirements\n\n 2.12 Bridge Configuration Lifecycle: Initial Limits\n\n 2.13 Bridge Configuration Lifecycle: Review\n\n 2.14 Bridge Configuration Lifecycle: Cadence and Out-of-Cycle Triggers\n\n 2.15 Bridge Stack Evaluation Pillar: Additional Infrastructure Risk\n\n 2.16 Bridge Stack Evaluation Pillar: Uniformity vs. Configuration Flexibility\n\n 3. Monitoring and Automated Risk Oracle Systems\n\n 3.1 Enforced Continuous Monitoring of Aave-external Layers\n\n 3.2 Continuous Risk Oracles and Automated Freeze Guardians\n\n 3.3 Risk Stewards as Human-in-the-loop Complement\n\n 3.4 Umbrella Coverage Role\n\n 4. Chain Risk\n\n 4.1 Chain Evaluation Scope\n\n 4.2 Network Architecture and Security Model\n\n 4.3 Decentralisation\n\n 4.4 Finality, Withdrawal, and Escape Mechanics\n\n 4.5 Chain Governance and Upgrade Control\n\n 4.6 Operational History\n\n 4.7 Ecosystem Adoption and Market Infrastructure\n\n 4.8 Tooling and Monitoring Support\n\n 4.9 Native and Major Asset Liquidity\n\n 4.10 Per-Asset and Per-Deployment Implications\n\n Jun 9\n\n 1 / 11\n\n Jun 8\n\n Jul 31\n\n post by LlamaRisk on Jun 9\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n image2880×1542 178 KB\nSummary\nThis framework sets the risk standard that governs every asset on Aave V3, V4, and Aave Horizon. It is binding at onboarding, at every quarterly due diligence refresh, at every material-change re-evaluation, and at every parameter or deprecation decision taken on a listed asset. The requirements, evaluation points, and procedures below are to become the standard against which every listing and every parameter decision is measured once the framework is endorsed.\nAsset safety on Aave is the union of every chain it lives on, every bridge it crosses, and every operational decision its issuer makes between reviews. The framework reflects that surface in full and reinforces continuity in the monitoring of the asset risk vectors as well as automation of the defensive actions.\nThe framework is organised into four layers, each addressing a distinct class of risk and a distinct timescale of control.\nLayer 1: Asset Risk carries the lifecycle, the qualitative onboarding requirements, the continuous due diligence cadence, the material-change taxonomy, and the conditions under which a reserve or an entire market deployment is wound down.\nLayer 2: Bridging Risk defines the mandatory bridge configuration baseline that any asset crossing chains must satisfy, the lifecycle for managing those configurations, and the evaluation pillars applied to every bridging stack in use.\nLayer 3: Monitoring and Automated Risk Oracle Systems defines the enforced automated monitoring of Aave-external layers, the continuous risk oracles and automated freeze guardians that act between adverse events and human response, the Risk Stewards’ role as the human-paced complement, and Umbrella’s role as the safety net. These are risk management mechanisms rather than discretionary tooling, and the framework codifies them as standing infrastructure because the risks they address are not fully manageable through onboarding requirements and continuous reviews alone.\nLayer 4: Chain Risk codifies the chain-level evaluation that gates whether Aave should deploy on a chain at all and the standing chain properties that constrain the exposure tier of every asset listed on the deployment, it functions as a precondition to Layers 1 through 3, because every asset and bridging decision on a chain inherits that chain’s properties.\n1. Asset Risk\nAn asset’s life on Aave passes through four stages: onboarding, continuous due diligence, material-change re-evaluation, and an unlikely deprecation. Listing breadth in itself does not signal elevated risk, because exposure is gated at the parameter level long before it becomes systemic. The question this layer answers at every stage is not whether the protocol holds a long list of reserves, but whether each reserve continues to fit the risk and operational profile that justifies its presence. The subsections below define the requirements applied at each stage and the triggers that advance an asset between stages.\nThis framework is designed to operate alongside the Technical Asset Listing Framework proposed by Aave Labs, and the two complement each other during the asset evaluation phase. Read together they are what makes a veto authority exercisable, since the technical framework establishes whether an asset technically can be listed and surfaces material technical concerns, while this framework determines whether it may be listed from the risk surface perspective and at what exposure tier, and holds the explicit veto. Where a subsection below covers ground that the Technical Asset Listing Framework also addresses, the relevant section of that framework and the specific additional requirements it carries are noted in the subsection itself, so the technical requirement and its risk treatment are read together.\n1.1 Asset Classification Adherence\nEquivalently as indicated in the Technical Framework, every asset must map to a governance-ratified Aave Asset class Allowlist (AAcA) before listing, because the class determines the parameter stack, the relevant E-Mode configurations, and the comparable assets the parametrisation is benchmarked against. Onboarding outside an existing class is structurally ambiguous and not accepted under the framework until the asset is included in a newly created class.\nRequirements:\n\nThe asset is mapped to an existing governance-ratified asset class (stablecoin group, ETH-correlated group, BTC-correlated group, RWA, or other class formally defined by Aave governance) before listing.\nAssets that do not fit an existing class require explicit class definition through Aave governance before listing, not ad-hoc onboarding under an analogous but non-binding category.\nThe closest comparable asset already listed under the same class is identified and could be used as a comparable reference for oracle design, LTV, LT, CF, caps, and Credit Lines subject to the new asset’s own technical profile.\n\nOnboarding under an unconfirmed or out-of-class designation is treated as a hard block at the pre-screening stage, therefore listings for such assets would first need to be approved via the asset class allowlist.\n1.2 Multi-Chain Evaluation Scope\nAn asset’s risk profile is the union of every chain it lives on and every configuration its issuer has shipped. A fixed snapshot or chain-local evaluation is structurally insufficient because an exploit, misprint, or governance action on one chain inevitably affects stability on every chain where the asset is deployed and translates directly to stress on the lending protocol.\nRequirements:\n\nEvery chain the asset is or will be deployed on through Aave is examined as part of the same evaluation.\nPer-chain bridge topology is documented for every cross-chain route carrying Aave exposure.\nPer-chain smart contract divergence, including proxy implementation and smart contract structure, is documented and reconciled to the latest audited version.\nPer-chain access-control and parameter divergence is documented.\nPer-chain oracle path and adapter configuration is documented.\n\nMaterial divergence across chains that cannot be reconciled to a single documented configuration profile materially constrains the asset’s cross-chain exposure tier.\n1.3 Smart Contract Audit Coverage\nAudits are the standing technical attestation that the asset’s contracts implement the design the framework’s other operational controls assume. Recency matters as much as existence because the threat landscape and the asset’s contracts both evolve between audits.\nRequirements:\n\nThe deployed version of the asset is covered by audits from reputable firm(s) completed with a published audit report.\nRe-attestation is required on every subsequent material upgrade rather than reliance on the original audit.\nBridge-side contracts on every deployed chain are reviewed under the same standard as the asset contract itself, because the bridge contract is part of the asset on the destination chain.\nAudit reports are provided to the risk provider; any unresolved findings are disclosed.\nPast incidents on any deployed version are disclosed with post-mortem and documented remediation.\n\nAudits without re-attestation on subsequent material upgrades, unresolved Critical or High findings, or past exploits without documented remediation are hard-block conditions. This matches the requirements of the technical listing framework.\n1.4 Bug Bounty Coverage\nA live bug bounty program is the only standing financial incentive aligning external security researchers with the asset’s safety. Detailed expectations are set out in the LlamaRisk Bug Bounty Landscape report and form the baseline applied here.\nRequirements:\n\nA live bug bounty program covering the asset and its critical dependencies is in place at listing and maintained continuously.\nMinimum payout floor of $50,000 for a critical finding as an absolute minimum regardless of TVL.\nMaximum payout that scales with the protocol’s TVL, sized using bounty value per million dollars of TVL as the reference metric, with comparisons of this metric for current Aave assets presented in the Bug Bounty Landscape document.\nScope covers loss of user funds, private-key or password exposure, user-information disclosure, unauthorised state-modifying actions, infrastructure compromise, domain takeover, and malicious redirection. Smart-contract-only scope is not sufficient anymore.\nThe program is preferably platform-managed (Immunefi, HackerOne, or equivalent) given platform-managed programs’ professional triage, credibility, and stronger researcher network effects.\n\nMissing or materially weak bug bounty coverage is a hard-block condition.\n1.5 Liquidity and Market Structure\nHealthy liquidation depends on the asset having a real secondary market, and oracle stability is itself a function of that secondary market. Liquidity is therefore evaluated as a structural property of the asset rather than as a point-in-time metric.\nRequirements:\n\nSecondary market depth is sufficient to clear the largest expected borrower within the asset’s liquidation bonus at acceptable slippage under different benchmarked VaR thresholds, applied individually.\nLiquidity-provider diversity within each venue is the primary structural concern, because a single dominant LP concentrates dependency on that LP’s behaviour (withdrawal, mispricing, opportunistic exploitation) regardless of the venue’s headline depth. Multiple venues with diverse LPs per venue is the preferred state. A single deep venue with verified LP diversity is acceptable. A fragmented multi-venue footprint with thin LP diversity offers limited improvement over a single concentrated venue, and therefore should be applied with reasonable allocation constraints. Due to the presence of effective atomic CEX-DEX arbitrage on Ethereum mainnet, centralized exchange liquidity can also be considered. However, CEX or remote chain liquidity will not receive the same treatment as direct onchain liquidity.\nVolume profile is assessed qualitatively for the share attributable to organic demand versus incentive-driven flow, since no single metric isolates organic flow cleanly. The assessment draws on incentive and rebate programmes active on the asset’s distribution venues and the share of measured volume eligible for them, the volume profile across incentive cliffs or reductions, trade-size distribution patterns, and holder concentration metrics.\nFor pegged assets, no sustained deviation from collateral value of 1% or more over a window of two days or longer is acceptable as an E-Mode precondition; sustained deviation also constrains LTV and forces higher LB values or alternatively moves them to a non-collateral state.\nIn general, but especially for assets with a gated mint and redeem function, the availability of liquidity and liquidator activity in the Chainlink network will be assessed on an ongoing basis.\n\nInsufficient depth relative to the borrower distribution, thin LP diversity within the asset’s deepest venues, or volume substantially supported by active incentive programmes materially constrains caps, LTV, and any E-Mode treatment.\n1.6 Timelock Requirements\nTimelocks gate the time between an authority deciding to change the asset and that change taking effect onchain. They are the standing control that allows Aave to take mitigating action before a malicious or accidental change executes, and apply on every chain the asset is deployed on rather than only on the primary chain.\nRequirements:\n\nTimelocks gate parameter changes that materially affect the asset’s behaviour on Aave.\nTimelocks gate mint and burn authority assignments and revocations.\nTimelocks gate oracle authority and oracle adapter changes.\nTimelocks gate bridge authority and bridge configuration changes (verifier-set, library, rate-limit).\nTimelocks gate upgrade paths on every chain the asset is deployed on.\nTimelock delay is sufficient for Aave to take mitigating action before the change executes; instantaneous or sub-hour delays are not acceptable.\n\nAbsence of a timelock on any of the above authorities is a hard-block condition.\nTechnical Asset Listing Framework formalises the timelock dimension through a standard Level 0 to 5 security configuration model, where:\n\nLevel 5 is onchain DAO governance with a timelock.\nLevel 4 is a multisig with a timelock of at least 48 hours.\nLevel 3 is a multisig with a short timelock below 48 hours.\nLevel 2 is a multisig with credible majority configuration but without a timelock.\nAny entity at Level 0 (a single key or EOA with no delay) or Level 1 (a multisig below honest majority) is defined as a weak security configuration.\n\n1.7 Signing Authority Decentralisation and Custody\nSigning authority decentralisation determines whether the asset’s authority surface can be compromised through a single point of failure (a single key, a small concentrated signer set, a single custodian). Disclosure of the signer surface is required even where confidentiality is reasonable, in which case disclosure is made under NDA to the risk provider.\nThe framework’s standing preference is for transparent on-chain multisig arrangements over MPC-based custody on the authorities that materially affect Aave’s exposure. Standard multisig contracts publish the signer set, the quorum threshold, and every authority action on chain, which is exactly the verifiability the protocol depends on for assessing whether a malicious or accidental change can occur and for responding to one in flight. MPC produces an on-chain footprint identical to a single externally-owned account; the underlying signer set, key-share distribution, and quorum threshold are opaque to anyone other than the operator, which removes the on-chain visibility multisig provides. In an environment where unauthorised authority changes and key-share compromises are a recurring exploit category, the transparency property of standard multisig is the preferred baseline. MPC remains acceptable only where additional private disclosures and operational controls recover the visibility the on-chain layer does not provide, the trade-off and the mitigations relied on here are set out in the LlamaRisk MPC Explainer.\nRequirements on every authority that can affect the asset on Aave (admin, mint, burn, oracle, bridge, slashing, upgrade):\n\nSigner-set composition, quorum threshold, and per-signer identity disclosed to the risk provider.\nSigner diversification across organisations and across hardware, sufficient to prevent collusion or single-supply-chain compromise.\nInstitutional-grade private-key custody for every authority.\nPause and blacklist authority, where present, identified and held under controls no weaker than the corresponding mint or burn authority.\nWhere confidentiality is reasonable, disclosure is made under NDA to the risk provider rather than published; undisclosed signer composition, quorum, or thresholds (even under NDA) is a hard block.\n\nAdditional requirements where MPC is used in place of standard multisig:\n\nPrivate disclosure of the MPC signing composition under NDA, including the number of key shards, the quorum threshold, and the identity of each shard holder. The on-chain identity of a single MPC address does not satisfy the disclosure requirement.\nDisclosure of shard-level custody (where each shard is held, by whom, under what custodial framework). Operational concentration across shards (multiple shards held by a single entity or under shared infrastructure) is disclosed and treated as a constraint on exposure equivalent to a sub-honest-majority multisig.\nThird-party audit or certification of the MPC implementation and the provider’s operational set-up, with re-attestation on subsequent material changes.\nDisclosure of whether the MPC cryptographic library is open-source and independently auditable.\nWhere the MPC provider supports auditable mechanisms (commitments and proofs posted to a public bulletin board, on-chain audit logs of authority actions, or equivalent), those are in use. MPC configurations without any auditability mechanism are problematic and put a full trust assumption on both the stack and the integrator.\n\nSingle externally owned account authorities, multisigs below honest-majority thresholds, undisclosed signer surfaces, or MPC configurations lacking the additional disclosures above are hard-block conditions.\n1.8 Legal Disclosures\nFor asset classes where value depends on legal arrangements rather than on-chain mechanics (custodied stablecoins, RWAs, redemption-bearing instruments), legal disclosures are part of the asset’s risk surface and not optional supporting information. Disclosures are scoped to what the risk provider needs to assess legal recourse and counterparty exposure.\nRequirements:\n\nIssuer jurisdiction and entity structure disclosed.\nRedemption rights disclosed, including any conditionality, queue mechanics, or jurisdiction-specific limitations.\nAsset-backing terms disclosed, including the legal treatment of property interests in the underlying.\nCustodian disclosures provided where the asset depends on a custodian, including the custodian’s jurisdiction and the legal nature of the arrangement.\nRegulatory status disclosed, including any active or pending classifications under securities, money-transmission, or equivalent regimes that could affect the asset’s behaviour.\n\nOpaque legal structure, undisclosed redemption mechanics, or undisclosed custodian arrangements where applicable materially constrain onboarding and exposure until clarified.\n1.9 Holder Claims Seniority and Loss-Bearing Hierarchy\nA listed asset typically exists in multiple representations across chains (canonical issuance, bridged or wrapped representations on L2s, vault or staking wrappers, custodied institutional claims), and a loss event on one representation does not automatically distribute pro rata across all holders. Ambiguity over which class of holders bears the loss blocks orderly recovery: the asset cannot reprice cleanly until the loss-bearing hierarchy is known, redemption queues cannot honour exits at par when the share of impairment per holder class is undefined, and Aave’s own safety-net layer cannot size slashing against a target that is not yet allocated. The framework therefore treats the claims seniority structure as a standing disclosure requirement, agreed in advance rather than negotiated under live incident pressure.\nRequirements:\n\nEach class of holder with rights against the underlying is identified (canonical-chain holders, per-L2 bridged holders, wrapper or vault holders, custodied institutional claims, and any other class with a distinct legal posture).\nThe seniority ordering across those classes is disclosed: who is paid first against the underlying, who absorbs first loss, and under what conditions seniority shifts.\nCross-chain symmetry is stated explicitly: whether bridged representations carry equal claim to canonical issuance, or whether a bridge incident is borne by holders on the affected chain rather than socialised across all holders.\nCoordination authority is identified: who decides loss allocation under an incident, on what timescale, and with what governance preconditions.\nWhere the seniority structure depends on legal arrangements outside Aave’s observation (custody agreements, jurisdictional bankruptcy treatment, issuer DAO votes), those dependencies are disclosed under NDA where appropriate.\n\nUndisclosed or ambiguous claims seniority on assets with multiple holder classes is a hard-block condition, because it cannot be priced and it materially impairs the speed and credibility of any incident response.\n1.10 Asset Backing Structure and Visibility\nFor asset classes whose value is determined by backing (stablecoins, LSTs, LRTs, restaked assets, RWAs), the framework requires not only that backing exists but that it remains continuously observable. Periodic attestation alone is insufficient where the asset’s risk surface shifts faster than the attestation cadence.\nRequirements:\n\nProof-of-Reserves or equivalent attestation in place for the full backing of the asset by a reputable third party approved by Aave stakeholders.\nReserve composition disclosed at the level of individual collateral components, not aggregate value.\nOnchain visibility of backing where structurally possible; off-chain backing covered by attestation with a publication cadence sized to the asset’s risk dynamics rather than episodic disclosure.\nMaterial changes to attestation cadence or attestor identity disclosed in advance.\nBacking-asset price and redemption-buffer state observable in real time where the asset depends on either for its peg or its exchange rate.\n\nOpaque backing, attestation cadence misaligned with the asset’s risk dynamics, or unverified reserve composition materially constrains onboarding and exposure.\n1.11 Issuer Operational Stack Disclosure\nOn-chain observability does not describe the issuer’s full operational stack, and the gaps in that observability are where the highest-impact risk vectors typically sit. The framework requires private disclosure of the operational stack to the risk provider, under NDA where appropriate, so that operational security is not weakened by publication.\nRequirements:\n\nInfrastructure setup disclosed, including hosting, key custody arrangements, and authority-to-action paths.\nOperational security practices disclosed, including incident-response procedures, change-management procedures, and access-revocation procedures.\nThird-party dependency list disclosed, including any infrastructure shared with bridge stacks, oracle providers, or other listed assets.\nMonitoring practices disclosed, including the issuer’s own coverage of authority queues, infrastructure events, and asset-state anomalies.\nNew infrastructure (a new bridge route, a new chain deployment, a smart contract upgrade) walked through with the risk provider before it goes live.\n\nRefusal to disclose the operational stack, even under NDA, materially constrains onboarding and exposure.\n1.12 Pre-Agreed Incident Communication Baseline\nA predictable communication path during an incident is part of risk mitigation rather than optional courtesy. The framework requires the baseline to be agreed in advance rather than negotiated under live incident pressure.\nOperational requirements:\n\nIssuer contact point and escalation path identified and tested.\nPre-agreed communication baseline for confirmed exploits affecting the asset on Aave.\n24/7 reachability across the issuer’s incident-response team during any window in which the asset carries material Aave exposure.\nCommitment to pre-notify Aave teams of material changes before they go live rather than after the fact.\n\nAbsence of an agreed communication baseline, or refusal to commit to pre-notification, materially constrains onboarding and exposure.\n1.13 Hard-Block Conditions and Veto Authority\nAn explicit veto authority is held by each service provider on the hard-block conditions below. This is necessary because historically onboardings had proceeded without resolution of all outstanding deficiencies indicated by different SPs in the form of recommendations. The veto applies at listing and at any quarterly refresh that surfaces one of these conditions.\nHard-block conditions:\n\nMissing or materially weak bug bounty programme.\nOpaque or unverified governance structure.\nNo timelock on upgrade paths that materially affect Aave’s exposure.\nUndisclosed signer composition or thresholds, even under NDA.\nAudits without re-attestation on subsequent material upgrades.\nUnresolved audit findings or past exploits without documented remediation.\nBridge configuration falling short on any Layer 2 mandatory requirement on a route carrying Aave exposure.\nRefusal to disclose the operational stack, the legal structure, or the backing composition where applicable.\n\nA hard block stops onboarding entirely until the condition is cleared; for an already-listed asset, a hard block triggers an immediate exposure-tier review and may trigger deprecation if not remediated within the framework’s standing timelines. Similarly, whenever an evaluation made in accordance with the technical listing framework outlines any blockers, the veto authority automatically blocks onboarding even if this framework does not indicate any hard blockers.\n1.14 Continuous Due Diligence Cadence\nStructural due diligence, just like the asset parametrization efforts and market evaluations, is a continuous process, with a quarterly refresh as the minimum cadence. Each refresh publishes a delta report against the prior baseline, so that the picture stays current and the change history remains auditable.\nOperational requirements:\n\nA quarterly refresh per asset, scheduled relative to the asset’s onboarding date, covering every chain the asset is deployed on.\nA delta report published against the prior baseline, expanding and iterating on the original findings.\nEach refresh re-evaluates every requirement in Sections 1.1 through 1.11 against the asset’s current configuration.\nBridge configuration is re-evaluated at every refresh under the bridging cadence.\nMonitoring coverage is re-evaluated at every refresh against the monitoring stack.\n\nFailure of the issuer to engage with the quarterly refresh, or refusal to provide updated disclosures, materially constrains the asset’s exposure until the refresh is completed. If the updates materially change the asset’s risk profile, measures would include offboarding of the asset.\n1.15 Material-Change Taxonomy\nIn addition to the quarterly cadence, material changes by the issuer trigger out-of-cycle re-evaluation. Asset issuers are required to disclose material changes to bridge configuration in advance so that the change can be reviewed before deployment and does not trip the automated monitoring layer’s anomaly detection. Bridge infrastructure providers are required to disclose material changes to the bridging protocol as to manage resources needed for re-evaluation across numerous issuers.\nAuthority and access changes:\n\nNew mint or burn authorities introduced on any chain.\nMPC, multisig, or custody arrangement changes.\nMultisig signer composition or timelock parameter changes.\nNew pause, blacklist, or upgrade authority assignments.\n\nReserve and backing changes:\n\nNew collateral type, staking destination, restaking layer, or custody arrangement for the underlying.\nMaterial changes to attestation cadence or attestor identity.\nMaterial changes to redemption mechanics or queue parameters.\n\nContract and deployment changes:\n\nContract upgrades on any deployed chain.\nExpansion to new chains.\nNew chain-specific access-control or parameter divergence.\n\nBridge configuration changes:\n\nBridge stack change or addition of a new bridge route.\nVerifier-set or attestor-set changes, including additions and removals.\nRate-limit changes on any route.\nPause authority composition changes.\n\nOracle changes:\n\nComposition changes: adapter swaps, primary feed swaps, fallback source addition or removal, and any change to the oracle path that is either consumed by Aave or used in the internal systems (e.g. to calculate balances, serve the redemptions etc.).\nQuality changes: shifts in the Chainlink risk tier on the asset’s feed, changes to heartbeat or deviation threshold, single-venue concentration emerging on the inputs to the feed, sustained volume decay on the feed’s source venues, and any other change that materially affects the feed’s manipulability or reliability.\n\nFailure to disclose a material change in advance is itself a remediation trigger and may constrain the asset’s exposure tier.\n1.16 Remediation Timelines and Residual Risk Treatment\nRecommendations raised at onboarding and at every quarterly refresh carry a one-month implementation expectation. The one-month timeline exists to ensure that compliance with the framework’s findings is met within a defined, enforceable window rather than being left open-ended as a longer-term goal, since binding each recommendation to an explicit timeline closes the loop and ensures the framework’s findings translate into operational change rather than into a growing recommendation backlog.\nOperational requirements:\n\nEach recommendation is acknowledged by the issuer and assigned a one-month implementation target.\nRecommendations not implemented within one month convert into hard constraints on the asset’s exposure tier (lower caps, lower LTV, restricted cross-chain expansion).\nRecommendations classified as hard-block conditions are not subject to the one-month grace; they block onboarding outright or, for listed assets, trigger immediate exposure-tier review.\nWhere remediation is structurally infeasible, the residual is documented in the asset’s profile and reflected in the standing exposure ceiling.\n\nRecommendation backlogs that persist across multiple quarterly refreshes are themselves a deprecation trigger.\n1.17 Asset Deprecation Triggers\nAn asset becomes a deprecation candidate when its continued listing no longer fits the active risk surface. The triggers are grouped by the underlying source of the impairment, because the source determines which deprecation mechanics apply and how aggressive the wind-down needs to be.\nTrigger conditions:\n\nSecondary-market liquidity decays to where healthy liquidation depth can no longer be sustained for the asset’s outstanding exposure.\nOracle stability degrades materially, with the feed becoming manipulable or thin (single-venue concentration, wide spreads, low daily volume); Chainlink price feed risk tiering is a binding input, where High or Very High risk evaluation is critical.\nEconomic footprint falls below the cost of standing oversight.\nBacking structure degrades, including issuer-side or custody-side incident, exploit, or insolvency materially affecting the asset.\nHard-block conditions surface on a listed asset and are not remediated within the framework’s standing timelines.\n\nDeprecation under any of these triggers is operationalised under the mechanics and oracle treatment defined below.\n1.18 Oracle and Price-Feed Treatment\nOracle stability is itself a function of adoption. As trading depth declines on an asset, market inputs to the feed thin out (fewer venues, wider spreads, lower daily volume), and the market becomes progressively less stable and more manipulable. Chainlink’s continuous risk-tiering process on price feeds flags these failure modes, and the framework treats those flags as binding inputs on every feed Aave consumes.\nThe framework’s oracle treatment is not limited to the feed Aave consumes on chain. A listed asset typically depends on additional oracle paths for its own mechanics: minting and burning gates, redemption pricing, internal balance and exchange-rate accounting, proof-of-reserves attestation etc. Failures in those internal oracles propagate to Aave through the asset’s behaviour even where Aave’s own feed is functioning correctly. A manipulable mint gate translates into unauthorised minting that Aave then accumulates as collateral; a stale or coerced redemption-pricing oracle into mispriced exits; a manipulable internal exchange-rate oracle into an inflated balance that Aave reads through a correctly-functioning price feed; a delayed proof-of-reserves into backing impairment Aave cannot detect from its own feed alone. The framework therefore treats the asset’s full oracle surface as a standing concern, with treatment differentiated by the role each oracle plays.\nRequirements on the Aave-consumed price feed:\n\nIn the cases where a market rate price feed is used, a Chainlink price feed is required with the Chainlink risk tier on the feed reviewed continuously.\nHigh or Very High risk-tier flags on a feed in use on Aave trigger deprecation review as a standing rule.\nA feed quoting a market price on an asset with no significant secondary market on chain and on centralised venues is treated as an unacceptable risk surface and triggers direct and aggressive deprecation.\nFor stablecoins not used as collateral, the deprecated feed is pinned at the nominal peg, which removes oracle manipulation risk on assets whose nominal value is the only sensible reference.\nFor non-stable tokens with decayed secondary markets, the deprecated feed is pinned to a conservative constant (last-good or a defined haircut) and the asset’s collateral position is unwound through a controlled LT step.\n\nRequirements on issuer-internal oracles the asset depends on:\n\nEach internal oracle path that gates supply integrity, redemption pricing, balance accounting, or backing attestation is identified at onboarding and documented in the asset’s profile.\nMint and burn gates cannot be unilaterally manipulated within a single transaction; in-block donations, flash-loan-induced deviations, and accounting-shortcut surfaces on the gating oracle are explicit disqualifiers.\nRedemption-pricing oracles maintain a sustained accuracy window consistent with the asset’s redemption queue dynamics, so that exits are not priced against a stale or coerced input.\nInternal exchange-rate or balance-accounting oracles for LSTs, LRTs, vault tokens, and similar instruments are monotonically non-decreasing under normal operation (with slashing or negative-rebase pass-through as the only acceptable exception) and resistant to single-transaction manipulation.\nProof-of-reserves and equivalent backing-attestation oracles publish at a cadence aligned to the asset’s risk dynamics rather than at an episodic interval disconnected from how fast the backing surface can change.\n\nFeeds that remain in use against a Chainlink High or Very High flag, and internal oracles that fail any of the above requirements, are treated as standing hard constraints on the asset’s exposure tier before the asset itself is fully deprecated.\n1.19 Market (Deployment) Deprecation Criterion\nWhen a group of assets within a market deployment becomes unstable, or when a deployment’s total revenue falls below the operational cost of supporting it (due diligence, audit, monitoring, parameter maintenance, governance overhead, infrastructure subsidy), the deployment itself becomes a candidate for sunset rather than just its individual reserves.\nTrigger conditions:\n\nTotal quarterly deployment revenue, evaluated using both borrow-side attribution and collateral-attributed revenue, falls below the standing operational support cost for the deployment.\nA group of reserves on the deployment becomes structurally unstable (liquidity decay, oracle decay, bridging risk concentration).\nPer-deployment TVL and revenue thresholds are scaled to the deployment’s total supplied USD value, calibrated per deployment rather than copied across, because a tail asset on a small deployment may be load-bearing for that deployment’s economics.\n\nA deployment that crosses these triggers is operationalised under the playbook below.\n1.20 Market Deprecation Playbook\nThe mechanics are structurally similar to asset deprecation, applied across the whole deployment in coordinated steps.\nOperational sequencing:\n\nSupply and borrow caps (add/draw caps on Aave V4 architecture) are set to 1 across all reserves on the deployment.\nThe reserves are frozen.\nReserve factor is tuned upward to drive organic unwinding through repayment, withdrawal, and liquidation, with reserves carrying material leveraged exposure (typically WETH on LST-heavy deployments) excluded from the reserve-factor increase to avoid triggering forced liquidations of leveraged positions.\nIRM adjustments follow once meaningful exposure has cleared, raising borrow rates to incentivise voluntary repayment for residual positions. On Aave V4 architecture, an additional risk premium lever is used for collateral assets, to drive loan repayments further, either in conjunction with the IRM adjustments or as a standalone measure.\nCross-chain bridge routes serving the deprecated deployment are closed under decayed-lane treatment as the deployment empties, per coordination with the asset issuers.\n\nSubsequent whole-deployment deprecations under the framework follow this sequencing.\n2. Bridging Risk\nBridge providers carry the first share of responsibility for the safety of a bridged asset. The bridge configuration travels with the asset and is reflected directly in the asset’s risk classification, irrespective of which bridge stack is in use. The requirements below are vendor-agnostic and apply uniformly across stacks, with no allowance for opt-in advanced settings, single-party verifiers, or vendor-managed defaults that fall below the baseline. An asset whose bridge configuration falls short on any mandatory item receives a tightened exposure tier (lower LTV, lower caps, restricted cross-chain expansion) until remediation lands.\n2.1 Bridge Topology Disclosure\nEvery bridged asset is documented at the route level before listing. Topology disclosure is the precondition for every subsequent requirement in this layer, because requirements such as verifier independence, library pinning, and rate limiting cannot be assessed without a precise specification of the route.\nRequirements:\n\nOrigin chain and canonical supply identified.\nTarget-chain representation documented (mint-and-burn, lock-and-mint, native-bridge representation).\nBridge or messaging system identified by name and version.\nVerifier, attestor, oracle, or message-verifier configuration documented for every route carrying Aave exposure.\nBridge admin and upgrade controls identified for the route on both chains.\nWeak controls on the origin chain are assessed as part of the target-chain listing, because origin-chain weakness can undermine the full cross-chain supply model regardless of bridge implementation.\n\nIncomplete topology disclosure on any route carrying Aave exposure is a hard block.\n2.2 Verifier Set Threshold Requirement\nThe minimum verifier-set threshold is the most consequential security property of a bridge stack and the property most often weakened by opt-in default configurations. The framework sets a binding floor below which no asset can be onboarded.\nFor threshold purposes a verifier is counted as an independent operator/trust domain: a verifier network operated by a single organisation counts as one unit regardless of internal node count, and verification layers run by genuinely distinct operators count separately.\nRequirements:\n\nA minimum of three independent verifiers (validators, attestors, nodes, or message verifiers) is required on every route carrying Aave exposure.\nOne-of-N and two-of-N configurations are not acceptable as a default baseline regardless of vendor.\nMeaningful verifier distribution across organisations, geography, and infrastructure.\nSupply-chain isolation, including RPC providers, hardware, and key infrastructure.\nBare-metal or comparably isolated infrastructure.\nThe verifier threshold is reflected in the asset’s risk classification; deviations require explicit governance justification and reduced exposure.\n\nA route with a verifier set below the threshold is treated as a hard block on cross-chain exposure expansion and triggers non-conformance treatment for existing exposure on the route. In addition, issuers will be encouraged to have more verifiers beyond the minimum threshold.\n2.3 Verifier Independence Requirements\nVerifier count alone is insufficient. Independence between verifiers determines whether a nominal threshold reflects real defence-in-depth or whether it collapses to a single supply-chain point of failure under stress.\nRequirements:\n\nVerifiers are independent across organisations.\nVerifiers are independent across geographic jurisdiction, sufficient to avoid concentration risk under a single regulatory action.\nVerifiers are independent across underlying infrastructure (RPC providers, hardware, cloud providers).\nBare-metal or comparably isolated infrastructure is preferred, with minimal interdependence across the supply chain.\nIdentifiable verifier overlap (shared RPCs, shared cloud accounts, shared key infrastructure, economic co-dependence) is documented as a risk-tier input and constrains exposure.\n\nNominal verifier-set decentralisation that collapses under any of the above independence dimensions is treated as a single point of failure for risk-tier purposes.\n2.4 Mutable Send and Receive Libraries\nEven where the verifier set is robust at a point in time, the authority that can change the verifier set or the message-handling library remains a critical surface. Pinning closes the path where vendor-side compromise silently rewires the verifier configuration without the asset issuer’s explicit re-attestation.\nRequirements:\n\nReceive libraries (or vendor equivalent) are pinned, so that compromise of a vendor-side authority cannot silently change the verifier set or message-handling logic.\nLibrary upgrades require the issuer’s explicit re-attestation rather than executing under a vendor-controlled upgrade path.\nVerifier-set changes are gated by bridge-authority timelocks on every chain.\nThe pinned configuration is documented as part of the route topology disclosure.\n\nUnpinned receive libraries on routes carrying Aave exposure are treated as a hard constraint on the route’s exposure tier until pinning is in place.\n2.5 Bridge Authority and Ownership Timelocks\nBridge authority is the standing power to change the verifier set, the rate limits, the libraries, or the mint and burn functions. Timelocks on that authority are required so that any malicious or accidental change can be observed and acted on before it takes effect.\nRequirements:\n\nTimelocks gate bridge ownership transfers.\nTimelocks gate verifier-set or attestor-set changes.\nTimelocks gate library upgrades and message-handling logic changes.\nTimelocks gate per-route rate-limit changes.\nTimelocks gate mint and burn authority grants on every route.\nTimelock delay is sufficient for Aave to take mitigating action before the change executes; instantaneous or sub-hour delays are not acceptable.\n\nAbsence of timelocks on any of the above bridge authorities is a hard constraint on cross-chain exposure until remediated.\n2.6 Separate Pause Pathways\nPause authority is the standing incident-response control on a bridge. Concentration of pause authority in a single party leaves Aave without an independent path to stop an in-flight exploit, and is not acceptable under the framework.\nRequirements:\n\nIssuer-side pause authority exists and is independent of the vendor. This can include methods such as setting native rate limits to 0.\nA vendor-side or verification operator-enforced ability to halt verification on the route exists and is exercisable by the vendor or operator’s incident-response team.\nAn Aave-controllable pause pathway is implemented via the monitoring layer where the bridge architecture supports it.\nEach pause path is documented and tested under standing incident-response procedures.\n\nReliance on a single pause path is not acceptable because it concentrates incident-response authority in one party. Single-path pause configurations would constrain the asset’s cross-chain exposure.\n2.7 Custody Requirements at the Bridge Layer\nBoth the bridge stack and the asset issuer hold rights to functions that affect the collateral on Aave (mint, burn, pause, rate-limit change). Custody on those rights is required at institutional grade on both sides, because the weaker of the two custody arrangements determines the overall surface.\nRequirements:\n\nInstitutional-grade private-key custody at the bridge stack level for every authority that can affect Aave-listed bridged assets.\nInstitutional-grade private-key custody at the asset issuer level for the corresponding authorities on the issuer side.\nCustody arrangement disclosed to the risk provider as part of operational stack disclosure.\nCustody changes disclosed in advance as material changes.\n\nWeak custody on either side, or undisclosed arrangements, materially constrains cross-chain exposure.\n2.8 Per-Route Rate Limiting Requirement\nRate limits bound the worst-case single-transaction drain that can result from a bridge exploit or from related exploit types (unauthorised minting, message replay). Under the framework, rate limits are required as a standing property of the bridge configuration rather than as a contingency to be activated under stress.\nRequirements:\n\nRate-limiting is present and enforced at the bridge stack or app level.\nWhere native rate-limiting is unavailable, the issuer must layer it externally; external layering is accepted as a substitute but must have equivalent enforceability.\nPer-route rate limits are configured on every route carrying Aave exposure.\nInbound and outbound limits are sized separately by direction.\nRate-limit configurations are documented under route topology disclosure and reviewed at every cadence point.\n\nRoutes without effective per-route rate limits carrying material Aave exposure are treated as a hard constraint on the asset’s exposure tier. It is highly recommended to have native rate limits and to be publicly documented in the bridging infrastructure provider documentations. This serves as an additional cross reference across the issuer and vendor, to prevent solely trusting a single party.\n2.9 Rate Limit Sizing Methodology\nRate-limit values, not just their existence, determine whether the limit binds a forged or coerced package. Sizing methodology is standardised under the framework so that limits are evaluated consistently across assets and across bridge stacks.\nRequirements:\n\nPer-route limits are sized to the highest observed sustained flow on the route rather than to peak burst.\nHeadroom over highest sustained flow is explicit and bounded; unbounded headroom is treated as the absence of a meaningful limit.\nInbound and outbound sustained flow are evaluated separately, because cross-chain flow profiles are typically asymmetric.\nDecayed-lane treatment applies once the sustained flow on a route falls below the threshold for active maintenance.\n\nThe sustained-flow basis keeps legitimate traffic comfortable while ensuring that a forged or coerced package cannot exceed what real cross-chain activity has ever needed.\n2.10 24/7 Redphone and Incident Response Requirements\nA bridge’s safety properties hold in steady state; incident response determines whether those properties hold in flight. The framework requires standing 24/7 reachability across every party with authority to mitigate an in-flight incident, including but not limited to all required attestors that are responsible to validate the cross chain transfers.\nOperational requirements:\n\n24/7 redphone availability across vendors, attestors, and issuer.\nWritten exploit procedure documented and rehearsed.\nPre-agreed authority for the on-call team to pause contracts and lower rate limits without further escalation.\nEmergency reductions in limits and defensive pauses may bypass timelock requirements, while the timelock governs changes that loosen or alter verification.\nPre-agreed escalation path between the vendor, the attestors, the issuer, and Aave’s service providers.\nThe entity operating the verification and messaging layer takes explicit responsibility for security and integrity monitoring of that layer rather than offloading it to issuers and consuming protocols; this operates as defense in depth alongside the issuer’s application-level monitoring, which covers the correctness of cross-chain activity.\n\nGaps in 24/7 reachability across any party in the chain materially constrain the asset’s cross-chain exposure tier.\n2.11 Dedicated Security and Monitoring Team Requirements\nMonitoring is required on both the vendor and issuer side, scoped to what each can observe: infrastructure and verification-layer integrity sits with the entity operating that layer, while application-level monitoring and response authority sit with the asset issuer. Where a stack’s verification layer can itself detect anomalous cross-chain activity, that detection and response capability sits with the operating entity; where it cannot, the determination requires application context held by the issuer. Offloading all monitoring onto consuming protocols is not acceptable, and no layer carrying Aave exposure should be left monitored by no party.\nRequirements:\n\nA dedicated security and monitoring team at the infrastructure and verification-layer level, maintained by the entity operating that layer, which shares documentation of its monitoring coverage for that layer with Aave.\nDedicated security and monitoring team at the asset issuer level for the bridge-side surface, with asset issuers to share detailed documentation to Aave.\nDetailed system checks across the stack, automated logic for anomaly detection, and written procedures for an in-flight exploit are maintained as standing artefacts.\nNeither the operator’s layer monitoring nor the issuer’s application monitoring is offloaded onto the other party or onto consuming protocols.\n\nAbsence of dedicated monitoring resources on either side materially constrains the asset’s cross-chain exposure tier.\n2.12 Bridge Configuration Lifecycle: Initial Limits\nBridge configuration is not set once at integration; the lifecycle below governs how the configuration is established, reviewed, and adjusted across the asset’s life on Aave. The first stage is the issuer’s proposal at integration.\nRequirements:\n\nPer-route initial limits are proposed by the issuer at integration, based on the issuer’s view of expected cross-chain flow per route.\nInitial limits are documented per route and per direction.\nInitial limits reference comparable issuer routes already in operation where available.\n\nThe initial proposal becomes the input to the review stage; routes proposed without an initial-limit specification are not eligible for integration.\n2.13 Bridge Configuration Lifecycle: Review\nLlamaRisk reviews the proposed configuration as part of the asset’s risk classification and recommends adjustments where the proposed values diverge from observed cross-chain flow or from the requirements.\nOperational requirements:\n\nReview is completed before the route goes live on a chain carrying Aave exposure.\nRecommended adjustments are documented and the issuer’s response captured before integration.\nMaterial divergence between issuer proposal and reviewer recommendation is flagged in the asset’s risk classification and reflected in the initial exposure tier.\n\nRoutes deployed without completed review are treated as non-conforming until reviewed.\n2.14 Bridge Configuration Lifecycle: Cadence and Out-of-Cycle Triggers\nBridge configuration is re-evaluated at every quarterly due diligence refresh against the latest flow data, alongside the rest of the asset’s evaluation. In addition, material monitoring flow events trigger out-of-cycle re-evaluation, because cross-chain flow profiles can shift faster than the quarterly cadence.\nOut-of-cycle triggers:\n\nA new chain deployment by the issuer introducing a new route.\nA new liquidity venue accepting the bridged token on any deployed chain.\nA sustained shift in transit volume on an existing route, in either direction.\nA material change affecting bridge authority, verifier set, or rate limits.\n\nDecayed-lane treatment:\n\nLanes that have decayed toward zero usage are candidates for closure rather than continued elevated limits, since every open lane is an incremental attack surface independent of whether it carries traffic.\nDecayed lanes are closed under the same authority and timelock pathway that gates rate-limit changes.\n\n2.15 Bridge Stack Evaluation Pillar: Additional Infrastructure Risk\nEach cross-chain stack used by an asset onboarded on Aave increases the protocol’s total risk exposure. Additional time and resources are necessary to track and monitor every additional bridge infrastructure.\nEvaluation requirements:\n\nOperational security of the vendor and its attestors assessed.\nCode quality on the on-chain and off-chain components, and the corresponding audit reports, reviewed.\nNovel architectural attack surfaces unique to the design identified and assessed.\nExploit history evaluated, including recurrence and the quality of remediation.\nTime and resources required for Aave to maintain monitoring on the stack documented and reflected in the stack’s classification.\n\nFor example, the protocol has already vetted and approved CCIP for GHO and sGHO and additionally relies on Data Feeds that are built on the same underlying infrastructure. A more detailed review across all cross-chain infrastructures that Aave is currently exposed to will be conducted.\nStacks whose additional infrastructure cost is disproportionate to the asset exposure they secure are not preferred and materially constrain the asset’s exposure tier.\n2.16 Bridge Stack Evaluation Pillar: Uniformity vs. Configuration Flexibility\nA uniform default security architecture across all chain expansions allows Aave to more readily quantify and measure risk and reduce the level of unknowns. Bespoke per-chain configurations without an enforced minimum complicate the risk management process, demand higher monitoring effort, and introduce unknown risk vectors.\nEvaluation requirements:\n\nUniform default security architecture across all chain expansions is preferred and reflected positively in the evaluation.\nBespoke per-chain configurations are explicitly justified and disclosed under route topology.\nDeviation from the stack’s uniform default which materially increases monitoring burden is reflected negatively in the evaluation.\nConfiguration uniformity is reviewed at every cadence point.\n\nConfigurability does not necessarily undermine security properties, but it does impose monitoring costs; a stack that permits many per-route configurations requires more standing effort for the DAO to track, and uniform-default stacks are credited for reducing that effort.\n3. Monitoring and Automated Risk Oracle Systems\nLayers 1 and 2 set the standing rules applied to assets and bridges. They do not, on their own, manage the risks that materialise between assessments. Bridge drains, peg breaks, redemption-buffer depletions, and abrupt market-depth collapses unfold on minute-to-hour timescales, while human-in-the-loop response on a manual cadence lags those timescales by hours at times. This layer codifies the standing risk-management infrastructure the framework binds Aave to operate against those failure modes: enforced automated monitoring of Aave-external layers, continuous risk oracles and automated freeze guardians that act without waiting for human review, Risk Stewards as the human-paced complement that handles recovery and judgment-bound calibration, and Umbrella as the residual safety net that absorbs loss the layers above cannot prevent. These are operational risk-management mechanisms rather than discretionary tools, where the framework treats them as binding standing infrastructure on the same footing as the requirements in Layers 1 and 2.\n3.1 Enforced Continuous Monitoring of Aave-external Layers\nAutomated monitoring is to cover the full stack. The focus is Aave-external because that is where the highest-impact events typically begin before they translate into on-chain effects on Aave itself, and the lead time between an external event and its on-chain consequence is what makes a defensive response feasible. A complementary layer watches for events that are likely to precede an incident, so that Aave is first informed when anomalous Aave-external events occur.\nCoverage requirements span four signal areas:\n\nAuthority-queue activity on the multisigs and timelocks that control the asset’s admin, oracle, bridge, and slashing authorities, where queues are watched and not just executions, so that a response can begin while a malicious or accidental change is still pending.\nGovernance activity on adjacent venues whose decisions can affect the asset before they reach the chain, including Snapshot proposals, on-chain governance actions, and RFC and ARFC threads.\nInfrastructure activity on the oracle adapters and bridge stacks the asset depends on, including validator-set changes, library upgrades, and pause events.\nDirect asset-state activity on chain, including bridge balance reconciliation between locked-side reserves and minted-side supply, backing-asset and redemption-buffer state where applicable, and minting and burning volume anomalies relative to historical baselines.\n\nA per-asset monitoring stack is to be published alongside the asset’s due diligence report, enumerating what is under coverage and what is explicitly out of scope, and is re-evaluated at every quarterly refresh. Detected signals route either to the automated risk oracle layer for hard adverse signals, or to Risk Steward escalation for soft signals or signals requiring judgment, under the per-asset playbook agreed at onboarding.\n3.2 Continuous Risk Oracles and Automated Freeze Guardians\nTwo automated mechanisms are to address the speed gap between an adverse event beginning and a human response: the Automated Freeze Guardian and the Supply and Borrow Cap Oracle. These mechanisms are to conform to the following:\n\nBuilt on Chainlink CRE as the off-chain compute and execution layer.\nOwned by the Aave DAO, so that signal sources, thresholds, and on-chain execution authority are auditable and governed through Aave rather than held under any vendor relationship.\nBoth are tailored per asset type to the specific risk profile of the asset.\nBoth are defensive by design:","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261565585,"hash":"9ac17981ebc6c59a1f3c8c8c3444028094bea634"}
{"url":"https://ethereum.org/wallets/find-wallet/personas/nfts/","domain":"ethereum.org","title":"NFT wallets for Ethereum | ⁦ethereum.org⁩","text":"NFT wallets for EthereumView, collect, and manage your NFTs. These wallets make it easy to explore your digital collectibles and connect to NFT marketplaces across Ethereum.Browse wallets by user typeNew to crypto 5 availableFirst time user looking for beginner wallet.Developer 10 availableWallets that help develop and test dapps.Finance 20 availableWallets focusing on frequent usage of DeFi apps.Hardware 7 availablePassive token holding with hardware wallets.NFTs 35 availableWallets with focus on NFT support.Browse all walletsWallets found: 35 / 48Cypherock X1HardwareNFTsDesktop · HardwareEnglish · German Device: $99 – $179TahoFinanceNFTsBrowserEnglish Swap fee: 0.5%Unstoppable walletDeveloperNFTsMobileEnglish · French Swap fee: 0%LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableUniswap WalletNFTsMobile · BrowserEnglish · Spanish Swap fee: 0%SafeFinanceNFTsMobileEnglish Swap fee: 0.05% – 0.7%, Staking fee: 20% of rewardsEnkryptNFTsBrowserEnglish Swap fee: variableBurnerHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish Device: $19/card, Swap fee: not disclosedimTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)FrameDeveloperFinanceNFTsDesktop · BrowserEnglish Coinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%FoxWalletNFTsMobile · BrowserEnglish · Chinese Swap fee: 0%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerBraavosNFTsMobile · BrowserEnglish Swap fee: 0%NuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%Gem WalletDeveloperNFTsDesktop · MobileEnglish · Spanish Swap fee: 0%, Buy fee: set by the provider1inch WalletFinanceNFTsMobileEnglish · Russian Swap fee: variableInfinex Wallet & Crypto SuperappNFTsBrowserEnglish Swap/bridge fee: 0.03% – 0.3%Loopring walletNFTsMobileEnglish · Chinese Swap fee: 0.3%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%TokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)AlphaWalletNFTsMobileEnglish · Chinese Swap fee: 0%Bitget walletFinanceNFTsMobile · BrowserEnglish · Chinese Swap fee: variablePillarXNFTsMobileEnglish Swap fee: 1%AmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%io.finnet MPC wallet for BusinessNFTsMobileEnglish Free tier, paid plans from $399.99/monthCoin98 Super WalletFinanceNFTsMobile · BrowserEnglish · Vietnamese Swap fee: 0.5% (0.1% for stablecoins)MetaMaskFinanceNFTsMobile · BrowserEnglish · Amharic Swap/bridge fee: 0.875%, Buy/sell fee: 1%GridPlus Lattice1HardwareNFTsDesktop · Browser · HardwareEnglish Device: $397Ready WalletFinanceNFTsMobile · BrowserEnglish Swap fee: 0.5%Rabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%MEW walletNew to cryptoNFTsMobileEnglish · Russian Swap fee: variableTrust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerHow we evaluate walletsEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.Read the full listing criteria and removal policyCurated by the ethereum.org editorial team.Most recent listing update: July 8, 2026To be listed, a wallet must meet the following requirements:Security-tested through audit, an internal security team, or open-source code review.Been live for at least six months, or built by a team with an established track record.Actively maintained, with support available for users.Provides honest, accurate listing information. Products that falsify details are removed.Has a named point of contact so we can verify information when it changes.Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.Listings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.Filter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.Wallets listed on this page are not official endorsements, and are provided for informational purposes only.Their descriptions have been provided by the wallet projects themselves.","tokens":1261,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261577067,"hash":"0a84dccf5831be6701db492886e3185c24c95bbd"}
{"url":"https://ethereum.org/wallets/find-wallet/personas/new-to-crypto/","domain":"ethereum.org","title":"Ethereum wallets for beginners | ⁦ethereum.org⁩","text":"Ethereum wallets for beginnersNew to Ethereum? These wallets keep things simple, with easy setup, approachable interfaces, and built-in ways to buy your first ETH so you can start with confidence.Browse wallets by user typeNew to crypto 5 availableFirst time user looking for beginner wallet.Developer 2 availableWallets that help develop and test dapps.Finance 4 availableWallets focusing on frequent usage of DeFi apps.Hardware 1 availablePassive token holding with hardware wallets.NFTs 5 availableWallets with focus on NFT support.Browse all walletsWallets found: 5 / 48Coinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerMEW walletNew to cryptoNFTsMobileEnglish · Russian Swap fee: variableRainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%How we evaluate walletsEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.Read the full listing criteria and removal policyCurated by the ethereum.org editorial team.Most recent listing update: March 19, 2025To be listed, a wallet must meet the following requirements:Security-tested through audit, an internal security team, or open-source code review.Been live for at least six months, or built by a team with an established track record.Actively maintained, with support available for users.Provides honest, accurate listing information. Products that falsify details are removed.Has a named point of contact so we can verify information when it changes.Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.Listings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.Filter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.Wallets listed on this page are not official endorsements, and are provided for informational purposes only.Their descriptions have been provided by the wallet projects themselves.","tokens":697,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261587032,"hash":"b2e32c7f8bdf586086b4fd9559e1155be14c58e5"}
{"url":"https://dev-forum.pyth.network/t/pyth-radar-real-time-cex-deviation-index-with-heatmap-delta/658/1","domain":"dev-forum.pyth.network","title":"Pyth Radar - Real-time CEX deviation index with heatmap & delta - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Radar - Real-time CEX deviation index with heatmap & delta \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 25\n\n 1 / 1\n\n Mar 25\n\n Mar 25\n\n post by RamzesVII on Mar 25\n\n RamzesVII\n\n Pyth Radar\nTeam: @RamzesVII\nSubmitted: March 26, 2026\n\nAnswer Capsule\n\nPyth Radar is a real-time oracle intelligence dashboard tracking price deviation between Pyth Network & CEXs across 30 assets. Pyth - is a benchmark. It uses Pyth Price Feeds with confidence intervals as signal thresholds: deviation inside CI is noise, deviation outside CI is a potential signal. Covers crypto, forex, commodities & equities\n\nWhat It Does\nCentralized exchanges don’t always trade at fair value - micro-divergences from Pyth benchmarks represent arbitrage opportunities, liquidation hunts or latency gaps. There’s no tool that makes these deviations visible in real time across multiple asset classes at once. Pyth Radar fills that gap using Pyth’s confidence interval as a native signal filter\n\nPyth Features Used\nCheck all that apply:\n\n Price Feeds (on-chain or off-chain)\n\n Entropy (randomness)\n\n Both\n\nLinks\n\nLive Demo: https://pyth-radar.vercel.app\n\nSource Code: https://github.com/RamzesVII/pyth-radar\n\nVideo Walkthrough (optional): https://youtu.be/1E5k0GBgCfE\n\nScreenshots / Media\nAbout:\nPasted Graphic 1721920×1260 99.6 KB\nCards View\n261920×1289 122 KB\nRadar View:\nPasted Graphic 1651920×1285 102 KB\nHeatmap:\nPasted Graphic 1671920×1291 176 KB\nAsset shortview:\nimage698×686 71.5 KB\nDelt\n$91.52731920×1295 172 KB\nDivergence Log:\nPasted Graphic 1691920×1295 168 KB\nComparison Mode:\nPasted Graphic 1712602×1704 339 KB\n\nTech Stack\n\nFramework: React + Vite + TypeScript\n\nStyling: Tailwind CSS\n\nCharts: TradingView Lightweight Charts v5\n\nDeployment: Vercel\n\nData: Pyth Hermes WebSocket - live prices + confidence intervals\n\nMarket data: Binance, Bybit, Gate.io, OKX (public WebSocket endpoints)\n\nContent Contributions (Required)\n\nPublic Post (Dev.to): https://dev.to/ramzesvii/cexs-lie-with-fair-prices-heres-how-to-catch-it-in-real-time-4eje\n\nPublic Post (Reddit): https://www.reddit.com/r/quantfinance/comments/1s3qlkz/\n\nTechnical Contribution (GitHub Gist): https://gist.github.com/RamzesVII/7e0d38b7bbb736529efffb901a413d5c\n\nBonus — X Platform Post: https://x.com/r_ladik/status/2036924687012552846\n\nLicensing\nThis project is licensed under Apache 2.0 (required for all submissions).\n\nEligibility Confirmation\n\n I am 18+ years old\n\n I am not located in an OFAC-sanctioned jurisdiction\n\n I confirm this is an original work created during the hackathon period\n\n I have read and agree to the Terms & Conditions\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 31\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Apr 1\n\n PythFeeds — Real-Time Crypto, Stocks, Metals & Forex Prices\n\n Pyth Community Hackathon\n\n 3\n\n 106\n\n Mar 29\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n LiquidSense — Real-Time DeFi Liquidation Radar Powered by Pyth Price Feeds\n\n Pyth Community Hackathon\n\n 0\n\n 28\n\n Mar 31\n\n Powered by Discourse","tokens":1702,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261589955,"hash":"636c3f9aeed6710461b429fd09d80b128a684738"}
{"url":"https://forum.openzeppelin.com/t/clarification-on-override-keyword-usage-in-erc20-functions-name-symbol-decimals/42427","domain":"forum.openzeppelin.com","title":"Clarification on override Keyword Usage in ERC20 Functions (name, symbol, decimals) - Support / Contracts - OpenZeppelin Forum","text":"Clarification on override Keyword Usage in ERC20 Functions (name, symbol, decimals) \n\n SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2024\n\n 1 / 3\n\n Dec 2024\n\n Dec 2024\n\n post by armgit5 on Dec 3, 2024\n\n armgit5\n\n I have encountered a potential concern regarding the use of the override keyword in the name, symbol, and decimals functions of the ERC20 contract. According to best practices, the override keyword should be used to ensure proper method overriding and prevent subtle bugs. However, I have noticed that these functions work both with and without the override keyword.\nI would like clarification on whether the absence of the override keyword in these functions could lead to any potential bugs or unexpected behavior during smart contract development. Below are the relevant code snippets for comparison:\nfunction name() public view virtual returns (string memory) { ... }\n// vs\nfunction name() public view virtual override returns (string memory) { ... }\n\nfunction symbol() public view virtual returns (string memory) { ... }\n// vs\nfunction symbol() public view virtual override returns (string memory) { ... }\n\nfunction decimals() public view virtual returns (uint8) { ... } \n// vs\nfunction decimals() public view virtual override returns (uint8) { ... }\n\nEnvironment:\nI am using OpenZeppelin Contracts in my project.\nI appreciate your insights and assistance on this matter.\n\n 2\n\n post by ernestognw on Dec 3, 2024\n\n ernestognw\n\n OpenZeppelin Team\n\n Hey @armgit5, thanks for sharing your question.\nIndeed, the ERC20 contract doesn't use the override keyword because no security concerns arise from not using it in this case (when you inherit from an interface and implement its functions). Although you can specify it, we considered it an unnecessary overhead.\nOn the opposite, Solidity will require you to specify an override(..., ...) if you're using our ERC20 and another extension that implements a function twice. In that case, the override becomes explicit but the order of execution is defined by Solidity's linearization\nHope this helps\n\n post by armgit5 on Dec 5, 2024\n\n armgit5\n\n Hi @ernestognw, thank you for the clear explanation about override in multiple inheritance! It makes perfect sense that specifying override is optional in single inheritance, as it avoids unnecessary overhead. Your clarification on Solidity’s linearization determining the execution order is extremely helpful. I truly appreciate your insights so much \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n // The following functions are overrides required by Solidity\n\n Contracts\n\n 4\n\n 2.7k\n\n Oct 2025\n\n Override approve in OpenZeppelin Contracts version 2.x\n\n Contracts\n\n erc20\n\n 4\n\n 2.6k\n\n Nov 2020\n\n What does it look like to override the decimals function?\n\n Contracts\n\n erc20\n\n 6\n\n 5.7k\n\n Nov 2021\n\n “foo function” the override section of erc20 detailed?\n\n Contracts\n\n erc20,proxies,upgrades,crypto-trends,tutorial\n\n 0\n\n 679\n\n May 2021\n\n Changing name of ERC20 token in OpenZeppelin Contracts 3.x\n\n Contracts\n\n 5\n\n 3.0k\n\n Nov 2020","tokens":786,"squid":"ink-security_audits","role":"Sentinel","at":1791261596259,"hash":"39a58c8154c6ffff7e92b320c0ea7a9c1fd452d1"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/honest-challenger-fdg.html","domain":"specs.optimism.io","title":"Honest Challenger - OP Stack Specification","text":"Honest Challenger (Fault Dispute Game)\n\nTable of Contents\n\nOverview\nInvariants\nFault Dispute Game Responses\n\nMoves\nSteps\nTimeliness\n\nResolution\n\nOverview\nThe honest challenger is an agent interacting in the Fault Dispute Game\nthat supports honest claims and disputes false claims.\nAn honest challenger strives to ensure a correct, truthful, game resolution.\nThe honest challenger is also rational as any deviation from its behavior will result in\nnegative outcomes.\nThis document specifies the expected behavior of an honest challenger.\nThe Honest Challenger has two primary duties:\n\nSupport valid root claims in Fault Dispute Games.\nDispute invalid root claims in Fault Dispute Games.\n\nThe honest challenger polls the DisputeGameFactory contract for new and on-going Fault\nDispute Games.\nFor verifying the legitimacy of claims, it relies on a synced, trusted rollup node\nas well as a trace provider (ex: Cannon).\nThe trace provider must be configured with the ABSOLUTE_PRESTATE\nof the game being interacted with to generate the traces needed to make truthful claims.\nInvariants\nTo ensure an accurate and incentive compatible fault dispute system, the honest challenger behavior must preserve\nthree invariants for any game:\n\nThe game resolves as DefenderWins if the root claim is correct and ChallengerWins if the root claim is incorrect\nThe honest challenger is refunded the bond for every claim it posts and paid the bond of the parent of that claim\nThe honest challenger never counters its own claim\n\nFault Dispute Game Responses\nThe honest challenger determines which claims to counter by iterating through the claims in the order they are stored\nin the contract. This ordering ensures that a claim's ancestors are processed prior to the claim itself. For each claim,\nthe honest challenger determines and tracks the set of honest responses to all claims, regardless of whether that\nresponse already exists in the full game state.\nThe root claim is considered to be an honest claim if and only if it has a\nstate witness Hash that agrees with the honest challenger's state witness hash for the\nroot claim.\nThe honest challenger should counter a claim if and only if:\n\nThe claim is a child of a claim in the set of honest responses\nThe set of honest responses, contains a sibling to the claim with a trace index greater than or equal to the\nclaim's trace index\n\nNote that this implies the honest challenger never counters its own claim, since there is at most one honest counter to\neach claim, so an honest claim never has an honest sibling.\nMoves\nTo respond to a claim with a depth in the range of [1, MAX_DEPTH], the honest challenger determines if the claim\nhas a valid commitment. If the state witness hash matches the honest challenger's at the same trace\nindex, then we disagree with the claim's stance by move to defend.\nOtherwise, the claim is attacked.\nThe claim that would be added as a result of the move is added to the set of honest moves being tracked.\nIf the resulting claim does not already exist in the full game state, the challenger issue the move by calling\nthe FaultDisputeGame contract.\nSteps\nAt the max depth of the game, claims represent commitments to the state of the fault proof VM\nat a single instruction step interval.\nBecause the game can no longer bisect further, when the honest challenger counters these claims,\nthe only option for an honest challenger is to execute a VM step on-chain to disprove the claim at MAX_GAME_DEPTH.\nIf the counteredBy of the claim being countered is non-zero, the claim has already been countered and the honest\nchallenger does not perform any action.\nOtherwise, similar to the above section, the honest challenger will issue an\nattack step when in response to such claims with\ninvalid state witness commitments. Otherwise, it issues a defense step.\nTimeliness\nThe honest challenger responds to claims as soon as possible to avoid the clock of its\ncounter-claim from expiring.\nResolution\nWhen the chess clock of a\nsubgame root has run out, the subgame can be resolved.\nThe honest challenger should resolve all subgames in bottom-up order, until the subgame\nrooted at the game root is resolved.\nThe honest challenger accomplishes this by calling the resolveClaim function on the\nFaultDisputeGame contract. Once the root claim's subgame is resolved,\nthe challenger then finally calls the resolve function to resolve the entire game.\nThe FaultDisputeGame does not put a time cap on resolution - because of the liveness\nassumption on honest challengers and the bonds attached to the claims they’ve countered,\nchallengers are economically incentivized to resolve the game promptly to capture the bonds.","tokens":1165,"squid":"ink-governance","role":"Council Listener","at":1791261608247,"hash":"4828f86a30de0b076b039536ce18d08d6a8a1460"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-crypto-anomaly-detector-on-pyth/736/1","domain":"dev-forum.pyth.network","title":"PythPulse :Real-Time Crypto Anomaly Detector on Pyth - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 1\n\n 1 / 1\n\n Apr 1\n\n Apr 1\n\n post by Bankybemma on Apr 1\n\n Bankybemma\n\n Individual discord handle:@Bankybemma#1284 Submitted: April 1, 2026\n\nAnswer Capsule\n\nPythPulse is a real-time cross-asset price anomaly detector using Pyth Network’s Hermes API. It monitors 38 curated live price feeds across Crypto, FX, Metals, Equities and Commodities. It detects simultaneous price spikes, calculates a live Market Stress Index, and logs every anomaly event with timestamps.\n\nWhat It Does\nPythPulse polls Pyth’s Hermes API every 3 seconds across 38 price feeds spanning 5 asset classes. When any asset moves beyond a user-defined threshold, it’s flagged as an anomaly and logged. When multiple assets spike simultaneously, the Market Stress Index rises — giving traders and DeFi protocols an early warning system for systemic market events.\n\nPyth Features Used\n\n Price Feeds (off-chain, Hermes REST API)\n\nLinks\n\nLive Demo: https://pythpulse-2-wgig.vercel.app/\n\nSource Code: https://github.com/bankybemma-collab/pythpulse-2\n\nScreenshots\nScreenshot 2026-04-01 1730251920×1080 310 KB\nTech Stack\n\nFramework/Language: React (pure, no framework)\n\nBlockchain: None (off-chain tool)\n\nData: Pyth Network Hermes REST API\n\nDeployment: Vercel\n\nContent Contributions (Required)\n\nPublic Post: PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network - DEV Community\n\nTechnical Contribution: PYTH PULSE · GitHub\n\nLicensing\nThis project is licensed under Apache 2.0.\n\nEligibility Confirmation\n\nI am 18+ years old\n\nI am not located in an OFAC-sanctioned jurisdiction\n\nI confirm this is an original work created during the hackathon period\n\nI have read and agree to the Terms & Conditions\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 31\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Pyth Radar - Real-time CEX deviation index with heatmap & delta\n\n Pyth Community Hackathon\n\n 0\n\n 49\n\n Mar 25\n\n Pyth Sentinel: How I Built a Real-time Crypto Alert & Prediction Platform Using Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 56\n\n Mar 17\n\n PythVision — Real-Time DeFi Analytics & Trading Dashboard | Pyth Playground Submission\n\n Pyth Community Hackathon\n\n 0\n\n 47\n\n Mar 23\n\n Powered by Discourse","tokens":1511,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261610653,"hash":"9ae1a4df86f773f1a06416c5a325fd45ed057dc3"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/dispute-game-interface.html","domain":"specs.optimism.io","title":"Dispute Game Interface - OP Stack Specification","text":"Dispute Game Interface\n\nTable of Contents\n\nOverview\nTypes\nDisputeGameFactory Interface\nDisputeGame Interface\n\nOverview\nA dispute game is played between multiple parties when contesting the truthiness\nof a claim. In the context of an optimistic rollup, claims are made about the\nstate of the layer two network to enable withdrawals to the layer one. A proposer\nmakes a claim about the layer two state such that they can withdraw and a\nchallenger can dispute the validity of the claim. The security of the layer two\ncomes from the ability of fraudulent withdrawals being able to be disputed.\nA dispute game interface is defined to allow for multiple implementations of\ndispute games to exist. If multiple dispute games run in production, it gives\na similar security model as having multiple protocol clients, as a bug in a\nsingle dispute game will not result in the bug becoming consensus.\nTypes\nFor added context, we define a few types that are used in the following snippets.\n/// @notice A `Claim` type represents a 32 byte hash or other unique identifier for a claim about\n/// a certain piece of information.\ntype Claim is bytes32;\n\n/// @notice A custom type for a generic hash.\ntype Hash is bytes32;\n\n/// @notice A dedicated timestamp type.\ntype Timestamp is uint64;\n\n/// @notice A `GameType` represents the type of game being played.\ntype GameType is uint32;\n\n/// @notice A `GameId` represents a packed 4 byte game type, a 8 byte timestamp, and a 20 byte address.\n/// @dev The packed layout of this type is as follows:\n/// ┌───────────┬───────────┐\n/// │ Bits │ Value │\n/// ├───────────┼───────────┤\n/// │ [0, 32) │ Game Type │\n/// │ [32, 96) │ Timestamp │\n/// │ [96, 256) │ Address │\n/// └───────────┴───────────┘\ntype GameId is bytes32;\n\n/// @title GameTypes\n/// @notice A library that defines the IDs of games that can be played.\nlibrary GameTypes {\n /// @dev A dispute game type the uses the cannon vm.\n GameType internal constant CANNON = GameType.wrap(0);\n\n /// @dev A dispute game type that performs output bisection and then uses the cannon vm.\n GameType internal constant OUTPUT_CANNON = GameType.wrap(1);\n\n /// @notice A dispute game type that performs output bisection and then uses an alphabet vm.\n /// Not intended for production use.\n GameType internal constant OUTPUT_ALPHABET = GameType.wrap(254);\n\n /// @notice A dispute game type that uses an alphabet vm.\n /// Not intended for production use.\n GameType internal constant ALPHABET = GameType.wrap(255);\n}\n\n/// @notice The current status of the dispute game.\nenum GameStatus {\n /// @dev The game is currently in progress, and has not been resolved.\n IN_PROGRESS,\n /// @dev The game has concluded, and the `rootClaim` was challenged successfully.\n CHALLENGER_WINS,\n /// @dev The game has concluded, and the `rootClaim` could not be contested.\n DEFENDER_WINS\n}\n\nDisputeGameFactory Interface\nThe dispute game factory is responsible for creating new DisputeGame contracts\ngiven a GameType and a root Claim. Challenger agents listen to the DisputeGameCreated events in order to\nkeep up with on-going disputes in the protocol and participate accordingly.\nA clones-with-immutable-args factory\n(originally by @wighawag, but forked and improved by @Vectorized) is used to create Clones. Each GameType has\na corresponding implementation within the factory, and when a new game is created, the factory creates a\nclone of the GameType's pre-deployed implementation contract.\nThe rootClaim of created dispute games can either be a claim that the creator agrees or disagrees with.\nThis is an implementation detail that is left up to the IDisputeGame to handle within its resolve function.\nWhen the DisputeGameFactory creates a new DisputeGame contract, it calls initialize() on the clone to\nset up the game. The factory passes immutable arguments to the clone using the CWIA (Clone With Immutable Args)\npattern. There are two CWIA layouts depending on whether the game type has implementation args configured:\nStandard CWIA Layout (when gameArgs[_gameType] is empty):\nBytesDescription\n[0, 20)Game creator address\n[20, 52)Root claim\n[52, 84)Parent block hash at creation time\n[84, 84 + n)Extra data (opaque)\n\nExtended CWIA Layout (when gameArgs[_gameType] is non-empty):\nBytesDescription\n[0, 20)Game creator address\n[20, 52)Root claim\n[52, 84)Parent block hash at creation time\n[84, 88)Game type\n[88, 88 + n)Extra data (opaque)\n[88 + n, 88 + n + m)Implementation args (opaque)\n\nThe implementation args allow chain-specific configuration to be passed to the game implementation at clone\ncreation time, enabling a single implementation contract to be reused across different chain configurations.\n/// @title IDisputeGameFactory\n/// @notice The interface for a DisputeGameFactory contract.\ninterface IDisputeGameFactory {\n /// @notice Emitted when a new dispute game is created\n /// @param disputeProxy The address of the dispute game proxy\n /// @param gameType The type of the dispute game proxy's implementation\n /// @param rootClaim The root claim of the dispute game\n event DisputeGameCreated(address indexed disputeProxy, GameType indexed gameType, Claim indexed rootClaim);\n\n /// @notice Emitted when a new game implementation added to the factory\n /// @param impl The implementation contract for the given `GameType`.\n /// @param gameType The type of the DisputeGame.\n event ImplementationSet(address indexed impl, GameType indexed gameType);\n\n /// @notice Emitted when a game type's implementation args are set\n /// @param gameType The type of the DisputeGame.\n /// @param args The constructor args for the game type.\n event ImplementationArgsSet(GameType indexed gameType, bytes args);\n\n /// @notice Emitted when a game type's initialization bond is updated\n /// @param gameType The type of the DisputeGame.\n /// @param newBond The new bond (in wei) for initializing the game type.\n event InitBondUpdated(GameType indexed gameType, uint256 indexed newBond);\n\n /// @notice Information about a dispute game found in a `findLatestGames` search.\n struct GameSearchResult {\n uint256 index;\n GameId metadata;\n Timestamp timestamp;\n Claim rootClaim;\n bytes extraData;\n }\n\n /// @notice The total number of dispute games created by this factory.\n /// @return gameCount_ The total number of dispute games created by this factory.\n function gameCount() external view returns (uint256 gameCount_);\n\n /// @notice `games` queries an internal mapping that maps the hash of\n /// `gameType ++ rootClaim ++ extraData` to the deployed `DisputeGame` clone.\n /// @dev `++` equates to concatenation.\n /// @param _gameType The type of the DisputeGame - used to decide the proxy implementation\n /// @param _rootClaim The root claim of the DisputeGame.\n /// @param _extraData Any extra data that should be provided to the created dispute game.\n /// @return proxy_ The clone of the `DisputeGame` created with the given parameters.\n /// Returns `address(0)` if nonexistent.\n /// @return timestamp_ The timestamp of the creation of the dispute game.\n function games(\n GameType _gameType,\n Claim _rootClaim,\n bytes calldata _extraData\n )\n external\n view\n returns (IDisputeGame proxy_, Timestamp timestamp_);\n\n /// @notice `gameAtIndex` returns the dispute game contract address and its creation timestamp\n /// at the given index. Each created dispute game increments the underlying index.\n /// @param _index The index of the dispute game.\n /// @return gameType_ The type of the DisputeGame - used to decide the proxy implementation.\n /// @return timestamp_ The timestamp of the creation of the dispute game.\n /// @return proxy_ The clone of the `DisputeGame` created with the given parameters.\n /// Returns `address(0)` if nonexistent.\n function gameAtIndex(uint256 _index)\n external\n view\n returns (GameType gameType_, Timestamp timestamp_, IDisputeGame proxy_);\n\n /// @notice `gameImpls` is a mapping that maps `GameType`s to their respective\n /// `IDisputeGame` implementations.\n /// @param _gameType The type of the dispute game.\n /// @return impl_ The address of the implementation of the game type.\n /// Will be cloned on creation of a new dispute game with the given `gameType`.\n function gameImpls(GameType _gameType) external view returns (IDisputeGame impl_);\n\n /// @notice Returns the required bonds for initializing a dispute game of the given type.\n /// @param _gameType The type of the dispute game.\n /// @return bond_ The required bond for initializing a dispute game of the given type.\n function initBonds(GameType _gameType) external view returns (uint256 bond_);\n\n /// @notice Returns the chain-specific configuration arguments for a given game type's implementation.\n /// @dev These arguments are typically passed to the game implementation during proxy creation using CWIA.\n /// @param _gameType The type of the dispute game.\n /// @return args_ The chain-specific configuration arguments.\n function gameArgs(GameType _gameType) external view returns (bytes memory args_);\n\n /// @notice Creates a new DisputeGame proxy contract.\n /// @param _gameType The type of the DisputeGame - used to decide the proxy implementation.\n /// @param _rootClaim The root claim of the DisputeGame.\n /// @param _extraData Any extra data that should be provided to the created dispute game.\n /// @return proxy_ The address of the created DisputeGame proxy.\n function create(\n GameType _gameType,\n Claim _rootClaim,\n bytes calldata _extraData\n )\n external\n payable\n returns (IDisputeGame proxy_);\n\n /// @notice Sets the implementation contract for a specific `GameType`.\n /// @dev May only be called by the `owner`.\n /// @param _gameType The type of the DisputeGame.\n /// @param _impl The implementation contract for the given `GameType`.\n /// @param _args The chain-specific configuration arguments for this game type's implementation.\n function setImplementation(GameType _gameType, IDisputeGame _impl, bytes calldata _args) external;\n\n /// @notice Sets the bond (in wei) for initializing a game type.\n /// @dev May only be called by the `owner`.\n /// @param _gameType The type of the DisputeGame.\n /// @param _initBond The bond (in wei) for initializing a game type.\n function setInitBond(GameType _gameType, uint256 _initBond) external;\n\n /// @notice Returns a unique identifier for the given dispute game parameters.\n /// @dev Hashes the concatenation of `gameType . rootClaim . extraData`\n /// without expanding memory.\n /// @param _gameType The type of the DisputeGame.\n /// @param _rootClaim The root claim of the DisputeGame.\n /// @param _extraData Any extra data that should be provided to the created dispute game.\n /// @return uuid_ The unique identifier for the given dispute game parameters.\n function getGameUUID(\n GameType _gameType,\n Claim _rootClaim,\n bytes memory _extraData\n )\n external\n pure\n returns (Hash uuid_);\n\n /// @notice Finds the `_n` most recent `GameId`'s of type `_gameType` starting at `_start`. If there are less than\n /// `_n` games of type `_gameType` starting at `_start`, then the returned array will be shorter than `_n`.\n /// @param _gameType The type of game to find.\n /// @param _start The index to start the reverse search from.\n /// @param _n The number of games to find.\n function findLatestGames(\n GameType _gameType,\n uint256 _start,\n uint256 _n\n )\n external\n view\n returns (GameSearchResult[] memory games_);\n}\n\nDisputeGame Interface\nThe dispute game interface defines a generic, black-box dispute. It exposes stateful information such as the status of\nthe dispute, when it was created, as well as the bootstrap data and dispute type. This interface exposes one state\nmutating function, resolve, which when implemented should deterministically yield an opinion about the rootClaim\nand reflect the opinion by updating the status to CHALLENGER_WINS or DEFENDER_WINS.\nClones of the IDisputeGame's initialize functions will be called by the DisputeGameFactory atomically upon\ncreation.\n/// @title IDisputeGame\n/// @notice The generic interface for a DisputeGame contract.\ninterface IDisputeGame is IInitializable {\n /// @notice Emitted when the game is resolved.\n /// @param status The status of the game after resolution.\n event Resolved(GameStatus indexed status);\n\n /// @notice Returns the timestamp that the DisputeGame contract was created at.\n /// @return createdAt_ The timestamp that the DisputeGame contract was created at.\n function createdAt() external view returns (Timestamp createdAt_);\n\n /// @notice Returns the timestamp that the DisputeGame contract was resolved at.\n /// @return resolvedAt_ The timestamp that the DisputeGame contract was resolved at.\n function resolvedAt() external view returns (Timestamp resolvedAt_);\n\n /// @notice Returns the current status of the game.\n /// @return status_ The current status of the game.\n function status() external view returns (GameStatus status_);\n\n /// @notice Getter for the game type.\n /// @dev The reference impl should be entirely different depending on the type (fault, validity)\n /// i.e. The game type should indicate the security model.\n /// @return gameType_ The type of proof system being used.\n function gameType() external view returns (GameType gameType_);\n\n /// @notice Getter for the creator of the dispute game.\n /// @dev `clones-with-immutable-args` argument #1\n /// @return creator_ The creator of the dispute game.\n function gameCreator() external pure returns (address creator_);\n\n /// @notice Getter for the root claim.\n /// @dev `clones-with-immutable-args` argument #2\n /// @return rootClaim_ The root claim of the DisputeGame.\n function rootClaim() external pure returns (Claim rootClaim_);\n\n /// @notice Getter for the parent hash of the L1 block when the dispute game was created.\n /// @dev `clones-with-immutable-args` argument #3\n /// @return l1Head_ The parent hash of the L1 block when the dispute game was created.\n function l1Head() external pure returns (Hash l1Head_);\n\n /// @notice Getter for the L2 sequence number (typically the L2 block number).\n /// @dev Extracted from the extra data supplied to the dispute game contract by the creator.\n /// @return l2SequenceNumber_ The L2 sequence number for this dispute game.\n function l2SequenceNumber() external pure returns (uint256 l2SequenceNumber_);\n\n /// @notice Getter for the extra data.\n /// @dev `clones-with-immutable-args` argument #4\n /// @return extraData_ Any extra data supplied to the dispute game contract by the creator.\n function extraData() external pure returns (bytes memory extraData_);\n\n /// @notice If all necessary information has been gathered, this function should mark the game\n /// status as either `CHALLENGER_WINS` or `DEFENDER_WINS` and return the status of\n /// the resolved game. It is at this stage that the bonds should be awarded to the\n /// necessary parties.\n /// @dev May only be called if the `status` is `IN_PROGRESS`.\n /// @return status_ The status of the game after resolution.\n function resolve() external returns (GameStatus status_);\n\n /// @notice A compliant implementation of this interface should return the components of the\n /// game UUID's preimage provided in the cwia payload. The preimage of the UUID is\n /// constructed as `keccak256(gameType . rootClaim . extraData)` where `.` denotes\n /// concatenation.\n /// @return gameType_ The type of proof system being used.\n /// @return rootClaim_ The root claim of the DisputeGame.\n /// @return extraData_ Any extra data supplied to the dispute game contract by the creator.\n function gameData() external view returns (GameType gameType_, Claim rootClaim_, bytes memory extraData_);\n\n /// @notice Returns whether the game type was respected when this game was created.\n /// @dev Used as a withdrawal finality condition - games created when their type wasn't\n /// respected cannot be used to finalize withdrawals.\n /// @return wasRespected_ True if the game type was the respected game type when created.\n function wasRespectedGameTypeWhenCreated() external view returns (bool wasRespected_);\n}","tokens":3979,"squid":"ink-governance","role":"Council Listener","at":1791261618277,"hash":"64498a9d1dbffd95329a3c54d06d20a13d1cc309"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/bridge-integration.html","domain":"specs.optimism.io","title":"Bridge Integration - OP Stack Specification","text":"Bridge Integration\n\nTable of Contents\n\nOverview\nLegacy Semantics\nFPAC OptimismPortal Mods Specification\n\nRoles - OptimismPortal\nNew DeployConfig Variables\nData Structures\nState Layout\n\nLegacy Spacers\nNew State Variables\n\nproveWithdrawalTransaction modifications\n\nInterface\nNew Invariants - proveWithdrawalTransaction\nChanged Invariants - proveWithdrawalTransaction\n\nfinalizeWithdrawalTransaction modifications\n\nNew Invariants - finalizeWithdrawalTransaction\nChanged Invariants - finalizeWithdrawalTransaction\n\nAir-gap\n\nBlacklisting DisputeGames\nBlacklisting a full GameType\n\nProxy Upgrade\n\nPermissioned FaultDisputeGame\n\nRoles - PermissionedDisputeGame\nModifications\n\nOverview\nWith fault proofs, the withdrawal path changes such that withdrawals submitted to the OptimismPortal are proven\nagainst output proposals submitted as a FaultDisputeGame prior to being finalized. Output\nproposals are now finalized whenever a dispute game resolves in their favor.\nLegacy Semantics\nThe OptimismPortal uses the L2OutputOracle in the withdrawal path of the rollup to allow users to prove the\npresence of their withdrawal inside of the L2ToL1MessagePasser account storage root, which can be retrieved by\nproviding a preimage to an output root in the oracle. The oracle currently holds a list of all L2 outputs proposed to\nL1 by a permissioned PROPOSER key. The list in the contract has the following properties:\n\nIt must always be sorted by the L2 Block Number that the output proposal is claiming it corresponds to.\nAll outputs in the list that are > FINALIZATION_PERIOD_SECONDS old are considered \"finalized.\" The separator\nbetween unfinalized/finalized outputs moves forwards implicitly as time passes.\n\nCurrently, if there is a faulty output proposed by the permissioned PROPOSER key, a separate permissioned\nCHALLENGER key may intervene. Note that the CHALLENGER role effectively has god-mode privileges, and can currently\nact without proving that the outputs they're deleting are indeed incorrect. By deleting an output proposal, the\nchallenger also deletes all output proposals in front of it.\nWith the upgrade to the Fault Proof Alpha Chad system, output proposals are no longer sent to the L2OutputOracle, but\nto the DisputeGameFactory in order to be fault proven. In contrast to the L2OO, an incorrect output proposal is not\ndeleted, but proven to be incorrect. The semantics of finalization timelines and the definition of a \"finalized\" output\nproposal also change. Since the DisputeGameFactory fulfills the same role as the L2OutputOracle in a post fault proofs\nworld by tracking proposed outputs, and the L2OO's semantics are incompatible with the new system, the L2OO is no\nlonger required.\nFPAC OptimismPortal Mods Specification\nRoles - OptimismPortal\n\nGuardian: Permissioned actor able to pause the portal, blacklist dispute games, and change the\nRESPECTED_GAME_TYPE.\n\nNew DeployConfig Variables\nNameDescription\nDISPUTE_GAME_FINALITY_DELAY_SECONDSThe amount of time given to the Guardian role to blacklist a resolved dispute game before any withdrawals proven against it can be finalized, in case of system failure.\nPROOF_MATURITY_DELAY_SECONDSFormerly FINALIZATION_PERIOD_SECONDS in the L2OutputOracle, defines the duration that must pass between proving and finalizing a withdrawal.\nRESPECTED_GAME_TYPEThe dispute game type that the portal uses for the withdrawal path.\n\nData Structures\nWithdrawals are now proven against dispute games, which have immutable \"root claims\" representing the output root\nbeing proposed. The ProvenWithdrawal struct is now defined as:\n/// @notice Represents a proven withdrawal.\n/// @custom:field disputeGameProxy The address of the dispute game proxy that the withdrawal was proven against.\n/// @custom:field timestamp Timestamp at which the withdrawal was proven.\nstruct ProvenWithdrawal {\n IDisputeGame disputeGameProxy;\n uint64 timestamp;\n}\n\nState Layout\nLegacy Spacers\nSpacers should be added at the following storage slots in the OptimismPortal so that they may not be reused:\nSlotDescription\n52Legacy provenWithdrawals mapping. Withdrawals proven against the L2OutputOracle's output proposals will be deleted upon the upgrade.\n54Legacy L2OutputOracle address.\n\nNew State Variables\nDisputeGameFactory address\n/// @notice Address of the DisputeGameFactory.\n/// @custom:network-specific\nDisputeGameFactory public disputeGameFactory;\n\nRespected Game Type\n/// @notice The respected game type of the `OptimismPortal`.\n/// Can be changed by Guardian.\nGameType public respectedGameType;\n\nRespected Game Type Updated Timestamp\n/// @notice The timestamp at which the respected game type was last updated.\nuint64 public respectedGameTypeUpdatedAt;\n\nNew ProvenWithdrawals mapping\n/// @notice A mapping of withdrawal hashes to `ProvenWithdrawal` data.\nmapping(bytes32 => ProvenWithdrawal) public provenWithdrawals;\n\nBlacklisted DisputeGame mapping\n/// @notice A mapping of dispute game addresses to whether or not they are blacklisted.\nmapping(IDisputeGame => bool) public disputeGameBlacklist;\n\nproveWithdrawalTransaction modifications\nProving a withdrawal transaction now proves against an output root in a dispute game, rather than one in the\nL2OutputOracle.\nInterface\nThe type signature of the function does not change, but the purpose of the second argument transitions from providing\nan index within the L2OutputOracle's l2Outputs array to an index within the DisputeGameFactory's list of created\ngames.\n/// @notice Proves a withdrawal transaction.\n/// @param _tx Withdrawal transaction to finalize.\n/// @param _disputeGameIndex Index of the dispute game to prove the withdrawal against.\n/// @param _outputRootProof Inclusion proof of the L2ToL1MessagePasser contract's storage root.\n/// @param _withdrawalProof Inclusion proof of the withdrawal in L2ToL1MessagePasser contract.\nfunction proveWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx,\n uint256 _disputeGameIndex,\n Types.OutputRootProof calldata _outputRootProof,\n bytes[] calldata _withdrawalProof\n) external whenNotPaused;\n\nNew Invariants - proveWithdrawalTransaction\nTrusted GameType\nThe DisputeGameFactory can create many different types of dispute games, delineated by their GameType. The game\ntype of the dispute game fetched from the factory's list at _disputeGameIndex must be of type RESPECTED_GAME_TYPE.\nThe call should revert on all other game types it encounters.\nChanged Invariants - proveWithdrawalTransaction\nRe-proving withdrawals\nUsers being able to re-prove withdrawals, in special cases, is still necessary to prevent user withdrawals from being\nbricked. It is kept to protect honest users when they prove their withdrawal inside of a malicious proposal. The\ntimestamp of re-proven withdrawals is still reset.\n\nOld: Re-proving is allowed if the output root at the proven withdrawal's l2OutputIndex changed in the\nL2OutputOracle.\nNew: Re-proving is allowed at any time by the user. When a withdrawal is re-proven, its proof maturity delay is\nreset.\n\nfinalizeWithdrawalTransaction modifications\nFinalizing a withdrawal transaction now references a DisputeGame to determine the status of the output proposal that\nthe withdrawal was proven against.\nNew Invariants - finalizeWithdrawalTransaction\nTrusted GameType\nThe DisputeGameFactory can create many different types of dispute games, delineated by their GameType. The game\ntype of the dispute game fetched from the factory's list at _disputeGameIndex must be of type RESPECTED_GAME_TYPE.\nThe call should revert on all other game types it encounters.\nRespected Game Type Updated\nA withdrawal may never be finalized if the dispute game was created before the respected game type was last updated.\nDispute Game Blacklist\nThe Guardian role can blacklist certain DisputeGame addresses in the event of a system failure. If the address of\nthe dispute game that the withdrawal was proven against is present in the disputeGameBlacklist mapping, the call\nshould always revert.\nDispute Game Maturity\nSee \"Air-gap\"\nChanged Invariants - finalizeWithdrawalTransaction\nOutput Proposal Validity\nInstead of checking if the proven withdrawal's output proposal has existed for longer the legacy finalization period,\nwe check if the dispute game has resolved in the root claim's favor. A FaultDisputeGame must never be considered to\nhave resolved in the rootClaim's favor unless its status() is equal to DEFENDER_WINS.\nAir-gap\nGiven it's own section due to it's importance, the air gap is an enforced period of time between a dispute game's\nresolution and users being able to finalize withdrawals that were proven against its root claim. When the DisputeGame\nresolves globally, it stores the timestamp. The portal's finalizeWithdrawalTransaction function asserts that\nDISPUTE_GAME_FINALITY_DELAY_SECONDS have passed since the resolution timestamp before allowing any withdrawals proven\nagainst the dispute game to be finalized. Because the FaultDisputeGame is a trusted implementation set by the owner\nof the DisputeGameFactory, it is safe to trust that this value is honestly set.\nBlacklisting DisputeGames\nA new method is added to assign DisputeGames in the disputeGameBlacklist mapping mentioned in\n\"State Layout\", in the event that a dispute game is detected to have resolved incorrectly. The only\nactor who may call this function is the Guardian role.\nBlacklisting a dispute game means that no withdrawals proven against it will be allowed to finalize\n(per the \"Dispute Game Blacklist\" invariant), and they must re-prove against a new dispute game that resolves correctly.\nThe Portal's guardian role is obligated to blacklist any dispute games that it deems to have resolved incorrectly.\nWithdrawals proven against a blacklisted dispute game are not prevented from re-proving or being finalized in the\nfuture.\nBlacklisting a full GameType\nIn the event of a catastrophic failure, we can upgrade the OptimismPortal proxy to an implementation with a\ndifferent RESPECTED_GAME_TYPE. All pending withdrawals that reference a different game type will not be allowed to\nfinalize and must re-prove, due to the \"Trusted GameType\" invariant. This should generally be avoided, but allows\nfor a blanket blacklist of pending withdrawals corresponding to the current RESPECTED_GAME_TYPE. Depending on if\nwe're okay with the tradeoffs, this also may be the most efficient way to upgrade the dispute game in the future.\nProxy Upgrade\nUpgrading the OptimismPortal proxy to an implementation that follows this specification will invalidate all pending\nwithdrawals. This means that all users with pending withdrawals will need to re-prove their withdrawals against an\noutput proposal submitted in the form of a DisputeGame.\nPermissioned FaultDisputeGame\nAs a fallback to permissioned proposals, a child contract of the FaultDisputeGame will be created that has 2 new\nroles: the PROPOSER and a CHALLENGER (or set of challengers). Each interaction\n(move [attack / defend], step, resolve / resolveClaim, addLocalData, etc.) will be permissioned to the\nCHALLENGER key, and the initialize function will be permissioned to the PROPOSER key.\nIn the event that we'd like to switch back to permissioned proposals, we can change the RESPECTED_GAME_TYPE in the\nOptimismPortal to a deployment of the PermissionedFaultDisputeGame.\nRoles - PermissionedDisputeGame\n\nPROPOSER - Actor that can create a PermissionedFaultDisputeGame and participate in the games they've created.\nCHALLENGER - Actor(s) that can participate in a PermissionedFaultDisputeGame.\n\nModifications\nState Layout\n2 new immutables:\n/// @notice The `PROPOSER` role.\naddress public immutable PROPOSER;\n\n/// @notice The `CHALLENGER` role.\naddress public immutable CHALLENGER;\n\nFunctions\nEvery function that can mutate state should be overridden to add a check that either:\n\nThe msg.sender has the CHALLENGER role.\nThe msg.sender has the PROPOSER role.\n\nIf the msg.sender does not have either role, the function must revert.\nThe exception is the initialize function, which may only be called if the tx.origin is the PROPOSER role.","tokens":3004,"squid":"ink-governance","role":"Council Listener","at":1791261628275,"hash":"112010a7864fbb637b86eecb2ef374ce64c8a4d5"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-cross-asset-anomaly-detector/720","domain":"dev-forum.pyth.network","title":"PythPulse: Real-Time Cross-Asset Anomaly Detector - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 31\n\n 1 / 3\n\n Mar 31\n\n Mar 31\n\n post by bemma on Mar 31\n\n bemma\n\n PythPulse is a real-time price anomaly detection dashboard built on Pyth Network’s Hermes API.\nLive Demo: https://pythpulse-2-wgig.vercel.app/\nGitHub: https://github.com/bankybemma-collab/pythpulse-2\nWhat it does:\n\nMonitors 38 live price feeds across Crypto, FX, Metals, Equities & Commodities using Pyth Hermes API\n\nDetects sudden price spikes in real-time across all assets simultaneously\n\nCalculates a Market Stress Index rises when multiplesets spike at once, signaling systemic market events\n\nLive sparkline charts, anomaly event log with timestamps, adjustable threshold slider\n\nBuilt with React, zero dependencies, deployed on Vercel\n\nTech: Pyth Hermes API · React · Custom SVG Charts · Vercel\n\n Unlisted on Apr 1\n\n Listed on Apr 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Pyth Radar - Real-time CEX deviation index with heatmap & delta\n\n Pyth Community Hackathon\n\n 0\n\n 49\n\n Mar 25\n\n PythFeeds — Real-Time Crypto, Stocks, Metals & Forex Prices\n\n Pyth Community Hackathon\n\n 3\n\n 106\n\n Mar 29\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Powered by Discourse","tokens":1294,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261631409,"hash":"814b6e438b518b6bd18e2af26b51f2909ed56516"}
{"url":"https://specs.optimism.io/fault-proof/zk-fault-proof-vm.html","domain":"specs.optimism.io","title":"ZK Fault Proof VM - OP Stack Specification","text":"ZK Fault Proof VM\n\nTable of Contents\n\nOverview\nZK Program\n\nInputs\nOutput\n\nAbsolute Prestate\nReference Implementation\n\nSP1 (PLONK)\n\nProof Generation\nInvariants\n\niZKVM-001: Private Inputs Must Be Anchored to Public Values\n\nImpact\n\niZKVM-002: Super Root Preimage Must Commit to All Chain Outputs\n\nImpact\n\nOverview\nThe ZK Fault Proof VM is a succinct proof system that verifies a super root state\ntransition across all chains in the interop set through a single cryptographic proof. It consists\nof two components:\n\nZK Program: an off-chain circuit that re-executes the derivation and state transitions for all\nchains in the interop set and produces a succinct proof of correctness.\nOn-chain Verifier: a smart contract (see IZKVerifier)\nthat checks the proof and the committed public values in a single call.\n\nThis is the ZK analogue of SuperFaultDisputeGame. Where the fault proof bisects an execution\ntrace down to a single instruction, the ZK VM proves the entire block range across all\nchains — from one super root to the next — in a single on-chain call.\nIn a standalone deployment (single chain), the interop set contains exactly one chain. The program\nis identical; the SuperRootProof preimage carries one entry. No separate standalone mode exists.\nZK Program\nThe ZK program is the circuit executed off-chain to generate a proof. It takes a set of\npublic values as inputs and verifies that executing the derivation and state transitions\nfor every chain in the interop set, starting from startingProposal.root and using L1 data up to\nl1Head, produces the super root rootClaim at timestamp l2SequenceNumber.\nInputs\nThe following public values are committed to by the ZK proof. They are constructed on-chain from\ngame state and passed to the verifier:\nFieldTypeDescription\nl1Headbytes32L1 block hash at which the L1 state was sampled. Authenticates all observed L1 data.\nstartingProposal.rootbytes32Super root hash of the parent game's claim, or the anchor state if parentIndex == type(uint32).max. Starting point for all chain state transitions.\nrootClaimbytes32The super root hash being asserted by this game. It commits to the output roots of all chains in the interop set at l2SequenceNumber.\nl2SequenceNumberuint256Super root timestamp corresponding to rootClaim. Constrained to uint64 range.\nproverAddressaddressAddress of the proof submitter (msg.sender in prove()). Binds the proof to a specific submission.\n\nl2ChainId is intentionally absent. Chain scoping is provided by the SuperRootProof preimage\ncommitted to by rootClaim and startingProposal.root. In a standalone (single-chain) deployment,\nthe preimage contains exactly one chain entry; no separate field is needed.\nOutput\nThe program produces a proof that commits to the public values. A proof that passes\non-chain verification means: executing the derivation logic for every chain in the interop set\nfrom the state committed to in startingProposal.root, under the L1 data observed at l1Head,\nyields exactly the super root rootClaim at timestamp l2SequenceNumber.\nAbsolute Prestate\nThe absolutePrestate is a bytes32 value that uniquely identifies the ZK program version being\nproven. Two different programs MUST NOT share the same absolutePrestate.\nIt serves as the program identity in\nIZKVerifier.verify and is injected into each game\ninstance via the CWIA game args.\nFor SP1 deployments, absolutePrestate corresponds to the program's verification key\n(programVKey), derived deterministically from the circuit binary and structure.\nProgram updates (e.g. a bug fix, a new hard fork, or a change to the interop set definition)\nMUST produce a new absolutePrestate. OPCM manages absolutePrestate per deployment; updates\nrequire governance.\nReference Implementation\nSP1 (PLONK)\nThe initial reference implementation uses SP1 by Succinct\nwith the PLONK backend.\n\nThe ZK program is compiled to run inside the SP1 zkVM.\nabsolutePrestate = the SP1 program verification key (programVKey).\nThe on-chain verifier is Succinct's PLONK verifier, wrapped behind the IZKVerifier interface.\n\nProof Generation\nProofs are generated off-chain by a prover that:\n\nFetches the required L1 and L2 data up to l1Head for all chains in the interop set.\nDecodes the SuperRootProof preimage from the game's extraData to identify the chain set\nand their expected output roots.\nExecutes the ZK program inside the zkVM with the public values as inputs and provides the\nrequired L1 and L2 data as private values to the ZK program.\nProduces a proof blob (proofBytes).\nSubmits the proof on-chain via ZKDisputeGame.prove(proofBytes).\n\nProof generation is permissionless: any party may generate and submit a proof. In practice the\nproposer or a third-party proving service will act as prover.\nInvariants\niZKVM-001: Private Inputs Must Be Anchored to Public Values\nThe ZK program receives private inputs (block and transaction data for all chains) that are known\nonly to the prover and never seen by the on-chain verifier. The ZK program MUST verify that all\nprivate inputs are directly derived from or cryptographically linked to the public values (e.g.\nby hashing block data and comparing against l1Head, or verifying that blocks form a chain rooted\nat startingProposal.root). The ZK program MUST NOT trust any private input without an explicit\ncheck against a public value.\nImpact\nSeverity: Critical\nA violation means a malicious prover can supply manipulated private inputs that lead to a proof\nthat verifies on-chain but represents an invalid state transition, and enable finalization of a\nfraudulent super root.\niZKVM-002: Super Root Preimage Must Commit to All Chain Outputs\nThe ZK program MUST verify the output root of every chain listed in the SuperRootProof preimage\nand MUST produce a rootClaim that is the hash of that complete preimage. Omitting any chain from\nthe proof or producing a partial preimage hash MUST cause the program to fail.\nImpact\nSeverity: Critical\nA violation would allow a proof to finalize a super root that does not faithfully represent all\nchains in the interop set. Funds that do not exist on L2 could be withdrawn, or the state of a\nchain could be suppressed from the commitment.","tokens":1536,"squid":"ink-governance","role":"Council Listener","at":1791261638088,"hash":"aa915a8f16e042e0e738c93c072156d7d9d69888"}
{"url":"https://dev-forum.pyth.network/t/pythpulse-real-time-crypto-anomaly-detector-on-pyth-network/732/1","domain":"dev-forum.pyth.network","title":"PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network - Pyth Community Hackathon - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network \n\n Pyth Community Hackathon\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 1\n\n 1 / 3\n\n Apr 1\n\n Apr 1\n\n post by bemma on Apr 1\n\n bemma\n\n (topic deleted by author)\n\n Unlisted on Apr 1\n\n Listed on Apr 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Real-time oracle intelligence platform + paper prediction game\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 28\n\n PythPulse: Real-Time Cross-Asset Anomaly Detector\n\n Pyth Community Hackathon\n\n 0\n\n 24\n\n Mar 31\n\n Request: 1ms crypto data feed trial and micro‑movement behavior\n\n Price Feeds\n\n 2\n\n 58\n\n Mar 22\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 473\n\n Jul 2025\n\n Powered by Discourse","tokens":1100,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261641711,"hash":"7aa5fa58e3ae6a0aa3d4d9240287e57034b16c9b"}
{"url":"https://io.net/docs/guides/workers/proof-of-work","domain":"io.net","title":"Proof of Work - io.net","text":"​What is Proof-of-Work?\nProof-of-Work is a cryptographic puzzle that requires significant computational resources to solve. It’s easy to verify the authenticity of a GPU/CPU after they successfully solve the puzzle. Our PoW algorithm leverages an industry-standard approach to verify computational resources, similar to the approaches used in cryptocurrencies such as Ethereum, prior to its Proof-of-Stake upgrade, and Bitcoin.\n​Why Is This Necessary?\n\nAuthenticity Verification: PoW verifies that suppliers provide real and functional CPU/GPU resources rather than simulated or virtual environments.\nPerformance Validation: By requiring devices to solve complex puzzles, we can verify that they perform at the level claimed by the supplier.\nFraud Prevention: This mechanism makes it difficult and economically unfeasible for malicious actors to fake or overstate their computational capacity.\nQuality Assurance: Regular PoW checks help maintain the overall quality and reliability of the io.net network.\nFair Resource Allocation: By verifying the authenticity and performance of resources, we ensure fair pricing and allocation for users hiring computational power.\n\nOur hourly PoW process runs in the background, causing minimal disruption to normal operations while continuously ensuring the integrity of our network. Suppliers can expect some load on their devices normally for no more than 15 mins per hour to complete the hourly Proof-of-Work authentication process.\nWhen you onboard your device into the io.net network, the device’s full capacity should be available to potential customers. If your device’s computational capacity is compromised when connected to our platform, it might disqualify you from rewards and being hired. Please note that we expect resources including VRAM to be fully available while your device is made available on io.net.\n​The PoW Process\nThere are three parts in this process:\n\nBinary Checker API: This is a tool that helps us solve the puzzle. It checks if a solution meets the puzzle’s requirements.\nChallenges API: These are the puzzles themselves. It involves finding a number that fits a specific pattern, such as having a certain number of zeros at the beginning.\nResults Submission API: Once we find a solution, we submit it to the system to check if it’s correct.\n\nHere’s how it works in simple steps:\n\nThe Binary Checker receives a puzzle and attempts to find a solution (called a nonce) that fits the puzzle’s pattern.\nThe system verifies that the device has the reported amount of VRAM to prevent devices with similar hash rates from misrepresenting their capacity.\nWhen a solution is found, it sends it to the system for verification.\nThe system verifies that the solution matches the puzzle’s requirements. For example, containing a specific number of zeros at the beginning.\nIf the solution matches the requirements, the system records this as a successful solution. The device has passed PoW challenge.\n\nWe have a monitoring system that regularly checks for new puzzles, finds solutions, and submits them for verification.\n​Is My Device Verified?\nThere are two visible aspects of Proof of Work (PoW) in our system:\n\nUsers can directly see on their device page whether their device is Verified or Not Verified:\nVerified devices are indicated by a blue icon located underneath the name of your device:\n\nDevices that are awaiting verification have a gray mark:\n\nVerification Failed have a red label:\n\n​What Happens if Proof-of-Work Fails?\nIf Proof-of-Work fails on your device, you may find your device tagged Verification Failed and/or Not Block Reward Ready.\n\nCommon errors you might encounter in the PoW log include:\n\nIf you find an empty list passed error: This is often caused by a CUDA memory allocation error. Your device might be occupied by some other jobs, Please check and stop using the device for other purposes when it’s available on the IO platform.\nIf you find a wrong answer error: Your device failed the PoW test. You may want to delete all containers, download the latest launcher, and restart the onboarding process following our documentation.\nIf you find a timeout error: Due to the inherent indeterminacy of PoW, there is a slight chance that your device might fail a PoW test even if it’s correctly configured. Mostly likely, if you repeat the setup process, it will pass PoW.\n\nCommon issue that can cause errors:\n\nIf you run your devices on deprecated drivers or CUDA versions (in case of Nvidia Graphics cards).\nIf you have more than 3 GPUs in your setup, we recommend running your device on Linux because there are intermittent issues with multi-card setups on Windows platforms. PoW tests have a high probability of failing in this instance.\n\nIf you use Linux, you can run a self-check binary to troubleshoot your devices. A successful self-check does not guarantee that your device will pass PoW; however, your device is highly unlikely to pass PoW if self-check returns any errors. This binary also works on Windows WSL2: https://github.com/ionet-official/io-net-official-setup-script/releases/.\nEncountering problems? Feel free to open a support ticket by logging into your IO.Net account and submitting a ticket.Was this page helpful?","tokens":1304,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261645440,"hash":"25d197d573d5595f20f64b87279231bd7fb8a22a"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/zk/zk-migration.html","domain":"specs.optimism.io","title":"Migration - OP Stack Specification","text":"ZK Dispute Game Migration\n\nTable of Contents\n\nOverview\nIn-Flight Withdrawal Safety\nCommon Mechanics\nPath A: SFDG → ZKDG (Isolated Chain)\nPath B: SPDG → ZKDG (Isolated Chain)\nPath C: Shared SFDG → Shared ZKDG\n\nShared Infrastructure and Idempotent Upgrades\n\nOverview\nAll migrations from an existing dispute game type to ZKDisputeGame are performed via\nOPCMv2.upgrade(). No standalone migrate() contract is in scope. Three migration paths are\nsupported:\nPathSourceTargetContext\nASuperFaultDisputeGame (SFDG)ZKDisputeGame (ZKDG)Isolated chain\nBSuperPermissionedDisputeGame (SPDG)ZKDisputeGame (ZKDG)Isolated chain\nCSuperFaultDisputeGame (SFDG)ZKDisputeGame (ZKDG)Interop set (e.g., OPM + Unichain)\n\nAll paths share the same core mechanics. Path-specific differences are concentrated in a small\nnumber of steps.\nIn-Flight Withdrawal Safety\nMCP clones embed the implementation address at deployment time. Old SFDG/SPDG game clones created\nbefore the migration retain their original implementation bytecode forever. New game clones\ncreated after setImplementation() in DisputeGameFactory use the ZKDG implementation.\nwasRespectedGameTypeWhenCreated is snapshotted at game creation. AnchorStateRegistry.isGameClaimValid()\nreads this flag during withdrawal finalization. Games created under the old respected type remain\nvalid for in-flight withdrawal finalization even after the migration.\nrootClaimByChainId is declared on all game types in scope (SFDG, SPDG, ZKDG). The Portal\ncalls it on all games whose type is in the isSuperGame allowlist. Old games already return the\ncorrect answer via their existing implementation. No special handling is needed for pre-migration\ngames during Portal withdrawal verification.\nCommon Mechanics\nThe following steps are executed in every migration path via OPCMv2.upgrade():\n\nDeploy the new implementation. Deploy ZKDisputeGame and register it in\nOPContractsManagerContainer.Implementations.\n\nSwap the implementation in DisputeGameFactory. Call the 3-argument overload:\ndisputeGameFactory.setImplementation(\n GameTypes.ZK_GAME_TYPE,\n address(zkImpl),\n gameArgs // variable-length CWIA bytes\n);\n\nOld game clones are unaffected. New games created after this call use zkImpl.\n\nDisable the old implementation.\ndisputeGameFactory.setImplementation(sourceGameType, address(0), \"\");\n\nThis prevents new games from being created under the old type.\n\nUpdate the respected game type in AnchorStateRegistry.\nanchorStateRegistry.setRespectedGameType(GameTypes.ZK_GAME_TYPE);\n\nAdd ZK_GAME_TYPE to GameTypes.isSuperGame(). Required for OptimismPortal\nto call rootClaimByChainId on ZKDG games during withdrawal verification. If this was\nalready shipped at initial ZKDG launch, this step is a no-op.\n\nReinitialize AnchorStateRegistry (no-op for these paths). Both SFDG and SPDG already\ncommit to super roots — the same bytes32 hash format that ZKDG uses as its starting\nstate. The existing anchor root is therefore a valid starting point for ZKDG parent\nvalidation without modification. No ASR reinitializer is required for Path A, B, or C.\n\nNote: An ASR reinitializer would only be necessary when migrating from a classic\nFaultDisputeGame (which commits to a per-chain output root rather than a super root). That\npath is not in scope here.\n\nPath A: SFDG → ZKDG (Isolated Chain)\nSingle chain with its own DisputeGameFactory, AnchorStateRegistry, and OptimismPortal.\nExecute Common Mechanics in a single OPCMv2.upgrade() call.\nThe ASR reinitializer fires once. No idempotency concerns arise since there is only one chain in\nscope.\nPath B: SPDG → ZKDG (Isolated Chain)\nSingle chain currently using the permissioned dispute game, migrating to permissionless ZK proofs.\nExecute Common Mechanics in a single OPCMv2.upgrade() call with the\nfollowing additional considerations:\n\nCross-mode transition: this is a permissioned → permissionless transition. The OPCM upgrade\nlogic MUST explicitly allow SPDG → ZK_GAME_TYPE as a valid source-to-target game type\npair (i.e., it cannot assume source and target share the same permission model).\nOperational readiness: permissionless infrastructure (op-challenger, prover network) MUST be\noperational and funded before the respected game type is switched. This is the chain operator's\nresponsibility and is not enforced by OPCM, but MUST be verified prior to executing the upgrade.\n\nPath C: Shared SFDG → Shared ZKDG\n\nNote: This path is intended as future work. The design below documents the intended approach\nbut has not yet been implemented.\n\nThis case covers chains sharing a single DisputeGameFactory,\nAnchorStateRegistry, and ETHLockbox under the interop model.\nExecute Common Mechanics. Because multiple chains share the same\nAnchorStateRegistry, steps 4 and 5 (updating the respected game type and the isSuperGame\nallowlist) affect the shared ASR and must be applied exactly once regardless of how many chains\nare in the interop set.\nShared Infrastructure and Idempotent Upgrades\nOPCMv2.upgrade() was designed to process one chain at a time. When applied to an interop set,\nthe shared AnchorStateRegistry upgrade steps may be triggered multiple times (once per chain\nprocessed). Two approaches are available:\nOption 1 — Idempotent operations: Design the ASR update steps so that applying them a second time\nfor a subsequent chain in the set is a safe no-op (e.g., a stateful check such as \"already set to\nthis game type\").\nOption 2 — Multi-chain bulk function: Introduce a function that accepts multiple SystemConfig\naddresses, upgrades shared infrastructure once, and handles per-chain state in a loop. This\nfollows the existing bulk migration patterns but is scoped to the SFDG → ZKDG transition.\nThe choice between these options is left to the OPCM implementation. Either approach MUST\nguarantee that shared infrastructure (ASR, ETHLockbox) is updated exactly once, regardless of\nhow many chains are in the interop set.\nBecause SFDG already commits to super roots, no ASR anchor reinitialization is required (see\nstep 6 in Common Mechanics).","tokens":1500,"squid":"ink-governance","role":"Council Listener","at":1791261647889,"hash":"2e4fdbd29235dab9fe2126b80554710c193c40d4"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/batchposter","domain":"docs.arbitrum.io","title":"The batch poster | Arbitrum Docs","text":"✏️Request an updateBatch posting is a fundamental process for the Sequencer's operation in Arbitrum. It involves collecting multiple child chain transactions, organizing them into batches, compressing the data to reduce size, and sending these batches to the Sequencer Inbox contract on the parent chain. This mechanism securely records transactions on the parent chain while optimizing for costs and performance.\nHow it works​\n\n1. Messages arrive (upstream handoff)​\nA transaction’s journey into the batch poster begins after it’s already been sequenced. The poster pulls ordered child chain messages from the TransactionStreamer—that’s a handoff into the batch poster; sequencing, execution, and soft finality all happened before this point and live outside of the batch poster.\n2. The poster decides where it stands​\nThe main loop (MaybePostSequencerBatch) first does a safety check (refuse to post if a prior batch reverted), then asks “what batch number and the parent chain nonce am I on?” and establishes the parent chain time/block window the batch will use. That window comes from reading the parent chain SequencerInbox contract’s MaxTimeVariation—a read-only handoff out to the parent chain.\n3. Messages become a compressed batch​\nThe poster receives messages in order, turning each into typed segments (the transaction itself, plus small bookkeeping notes for delayed-message markers and time/block advances) and streaming them through Brotli. It watches size and segment-count caps, and adapts compression effort to how far behind it is—more compression when calm, less when backlogged. When it decides the batch is ready (full enough, old enough, or a delayed message is about to expire), it seals and recompresses it. This is the core work done inside the batch poster.\n4. The data is routed to storage (DA handoff)​\nThe sealed bytes are handed to a data availability (DA) provider—an offchain AnyTrust/DAS committee or a custom backend—via the small Writer.Store interface, with a fallback to putting data directly on Ethereum (calldata or blobs). What comes back is either a certificate (offchain) or the raw data (EthDA). The committee aggregation, BLS signing, and blob KZG cryptography all happen behind that interface—handoffs that the batch poster isn’t involved in.\n5. The batch is wrapped for the parent chain and self-checked​\nThe poster builds calldata for the right SequencerInbox method (calldata vs. blobs, with or without a delay proof) and—as a correctness gate—replays the whole batch through the InboxMultiplexer (the same read/decode machinery used to consume batches) to confirm it decodes back to the exact original messages before anything is sent.\n6. The transaction is shipped to the parent chain (DataPoster handoff)​\nThe batch poster hands the calldata, blobs, and gas estimate to the DataPoster—the “shipping department.” From here, nonce selection, fee bidding, signing, queue persistence, and replace-by-fee-if-stuck are the DataPoster’s job, deliberately kept separate so the batch poster never has to deal with Ethereum gas mechanics. The DataPoster ultimately submits the transaction to the parent chain SequencerInbox contract.\n7. Finality and feedback​\nOnce the parent chain transaction confirms, the transactions cross from the Sequencer’s soft finality into hard finality anchored on the parent chain. The poster updates its backlog estimate (feeding back into compression effort and fee urgency), and a background revert watcher monitors the parent chain—if a posted batch ever fails onchain, it halts all posting for operator intervention.\nRelated resources​\n\nThe Sequencer and censorship resistance: batching, compression, and the Sequencer Inbox methods.\nSequencer transaction flow: what happens before the handoff, from the queue to block creation.\nGas and fees: how the parent chain pricer reimburses batch posting costs.\nFinality and reorgs: what parent chain finality guarantees, and the failure modes around posting.\nAnyTrust protocol: what the DAC does with the data behind the DA handoff.\nRun a batch poster and Batch poster troubleshooting: the operator view.\nHow it worksRelated resources","tokens":1038,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261654438,"hash":"48084bcbcb6ab21f525250113ceffe81df958dfa"}
{"url":"https://io.net/docs/guides/workers/device-onboarding","domain":"io.net","title":"Overview - io.net","text":"​Table of Contents\n\nCreate Account\nRequirements\nSet Up a New Worker\nApp Guide\n\nWorkers Homepage\nDevice Status\nReadiness\nTransition Between States\n\nTroubleshoot\n\n​Create Account\nTo create an account, go to worker.io.net. Currently, you can sign up using Google, Apple ID, X, or Worldcoin. Choose your preferred option, click Sign Up, and you’re all set to join us.\nGo toworker.io.net\n\n​Requirements\nDevices that meet the minimum system requirements are eligible for job assignments. All devices must pass our Proof of Work verification through the Worker to be hired by clusters.\nTo view a list of the current supported devices, see Supported Devices.\nAfter your onboard your device for the first time, there is a 12 hour waiting period until it’s eligible to be hired as a worker. Your device is only subject to the waiting period after its initial onboarding.\n​Minimum System Requirements\n\n12 GB RAM\n256 GB SSD\nWindows: NVIDIA GeForce RTX 30xx and above series / MacOS: Apple M3, M4.\nInternet Speed (please use speedtest.net or a similar service to check your speed) To qualify for the airdrop, the minimum requirement is 100Mb/s download and 75Mb/s upload. However, for a higher chance of being hired, the recommended minimum requirements are:\n\nDownload: Above 500 Mb/s\nUpload: Above 250 Mb/s\nPing: Below 30ms\n\nFor better performance, we recommend a download/upload speed of 200–500 Mbps and 16GB of RAM to avoid crashes.\n​Staking\nYour must stake to your device to make it eligible for block rewards and to be hired for jobs. For more information about staking, see our Staking documentation.\n​Set Up a New Worker\nWe have detailed guides available to help you set up your worker on various operating systems such as:\n\nMacOS\nWindows\nUbuntu\nHiveOS\n\nThese guides are tailored to provide step-by-step instructions, ensuring a smooth setup process for your new worker. Whether you’re using MacOS, Windows or Ubuntu, you’ll find comprehensive guidance to join get your worker up and running efficiently.\n​App Guide\n​Workers Homepage\nThis screen provides users with real-time access to general information about all their calculations. Users can easily see who is connected to the network, currently active, or experiencing errors. Additionally, they can perform actions like renaming and deleting devices.\nFor users managing a large number of devices, features like search and sorting by criteria such as Status, Brand, Technology, Connectivity Tier, and Security Compliance are invaluable.\nThis page allows you to monitor workers and track data such as:\n\nStatus\nDevice ID- The unique identifier for your device. Click the ID to view the Device Detail page.\nReadiness- This value provides insights into your device’s readiness for Block Reward eligibility.\nUp For\nChip/GPUs\n\n​Device Status\nDevice Status is displayed at the top of the table.\n\nStatusDescription🟢 up/runningRunning status is indicative that everything installed correctly and everything is in normal operations. No issues.🟢 IdleIdle status is indicative that everything installed correctly and everything is in normal operations but it has not been hired by someone yet. It is awaiting work. No issues.🟡 PausedPaused status is indicative that the client has manually suspended or disabled the node. They can resume it themselves.🔴 DownDown status is indicative that a worker is down and needs to re-run the commands.🔴 FailedFailed status is indicative of a connection/outage problem or the device is offline. The device is not communicating and is unavailable or experiencing another form of outage such as:• Error during startup: There may have been errors during the startup of your worker that prevented it from launching successfully.• Resource issues: It’s possible that there aren’t enough resources available for your worker to start, such as allocated memory, CPU time, or other resources.• Network failure: Network issues can prevent the establishment of connection with the platform or other services, leading to startup failures.🟠 BlockedBlocked status is indicative that we detected GPU utilization that was not authorized by our internal checks. It’s important that GPU availability is dedicated 100% to the task being volunteered for the health of the DePin.Blocked status occurs in a few different flavors, but mainly these:• Excessive GPU Utilization: Playing games, Graphic intensive utilization, etc. (You’ll need to pause it before you start usage)• Mining Detection: FYI - Our team has implemented an update to detect mining devices and instances with high GPU usage, resulting in an automatic ban.🟣 Unsupported deviceUnsupported status is indicative that your worker or its current configuration is not supported into the IO.NET platform at this moment. This could be due to incompatibility with the required software version, operating system, or hardware components. The list of supported devices can be checked here.🟣 InactiveInactive status is indicative that your worker has been inactive for more than 5 days. This may have been caused by pausing a worker and forgetting about it, an outage, or a technical / communication issue.\n​Readiness\nThe Readiness column differs from Status. This value provides insights into your device’s readiness for Block Reward eligibility. The screenshot below shows the Readiness column in the Device Status table.\n\nIf the status is Cluster Ready, then your device is eligible to be hired and/or for a Block Reward. The four possible Readiness statuses are:\nStatusDescriptionCluster ReadyDevice meets PoW requirements and passed several Cluster Formation verifications.HiredDevice is currently hired by a cluster.PendingThe device has joined the network and is currently undergoing both the PoW and Cluster Readiness test. This process can take up to 12 hours of cumulative uptime after onboarding, but may complete sooner if your device passes our tests early. If your device remains in a Pending state after more than 12 hours of uptime, please contact us.Not Block Reward ReadyDevice doesn’t meet the criteria for block reward eligibility, mainly Cluster Formation verifications.\nNot Block Reward Ready offers one of three tooltips in the UI to provide troubleshooting tips.\n\nPlease check your device’s computational capacity- Your device’s computational capacity is below the required threshold.\nPlease check your device setup and computational capacity- Your device setup might not be configured correctly and its computational capacity is below the required threshold. Please refer to the worker setup guide.\nPlease check your device setup- Your device setup might not be configured correctly. Please refer to the worker setup guide.\n\n​Transition Between States\nThe transition from Pending to Cluster Readystate can take up to 12 hours. During this time, we form clusters with newly joined devices (Pending) and verify them as Cluster Ready once they successfully pass the cluster formation process.\nIf the device fails to join the cluster multiple times, it’s labeled as Not Block Reward Ready. To verify if a device has successfully passed cluster formation is to check its job page, which indicates the record of past cluster formations.\n​Troubleshoot\n\nVerify that the device is operated using io.net official binaries and official docker images.\nVerify that the device has the right network setup (beyond basic internet speed test capability) where the device can properly interact with the remote head node or peer workers.\nWas this page helpful?","tokens":1871,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261655794,"hash":"e5cef971aa3e531877f94e4af8c931990d44563a"}
{"url":"https://specs.optimism.io/protocol/preinstalls.html","domain":"specs.optimism.io","title":"Preinstalls - OP Stack Specification","text":"Preinstalls\n\nTable of Contents\n\nOverview\nSafe\nSafeL2\nMultiSend\nMultiSendCallOnly\nSafeSingletonFactory\nMulticall3\nCreate2Deployer\nCreateX\nArachnid's Deterministic Deployment Proxy\nPermit2\nERC-4337 v0.6.0 EntryPoint\nERC-4337 v0.6.0 SenderCreator\nERC-4337 v0.7.0 EntryPoint\nERC-4337 v0.7.0 SenderCreator\n\nOverview\nPreinstalled smart contracts exist on Optimism\nat predetermined addresses in the genesis state. They are similar to precompiles but instead run\ndirectly in the EVM instead of running native code outside of the EVM and are developed by third\nparties unaffiliated with the Optimism Collective.\nThese preinstalls are commonly deployed smart contracts that are being placed at genesis for convenience.\nIt's important to note that these contracts do not have the same security guarantees\nas Predeployed smart contracts.\nThe following table includes each of the preinstalls.\nNameAddress\nSafe0x69f4D1788e39c87893C980c06EdF4b7f686e2938\nSafeL20xfb1bffC9d739B8D520DaF37dF666da4C687191EA\nMultiSend0x998739BFdAAdde7C933B942a68053933098f9EDa\nMultiSendCallOnly0xA1dabEF33b3B82c7814B6D82A79e50F4AC44102B\nSafeSingletonFactory0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7\nMulticall30xcA11bde05977b3631167028862bE2a173976CA11\nCreate2Deployer0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2\nCreateX0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed\nArachnid's Deterministic Deployment Proxy0x4e59b44847b379578588920cA78FbF26c0B4956C\nPermit20x000000000022D473030F116dDEE9F6B43aC78BA3\nERC-4337 v0.6.0 EntryPoint0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789\nERC-4337 v0.6.0 SenderCreator0x7fc98430eaedbb6070b35b39d798725049088348\nERC-4337 v0.7.0 EntryPoint0x0000000071727De22E5E9d8BAf0edAc6f37da032\nERC-4337 v0.7.0 SenderCreator0xEFC2c1444eBCC4Db75e7613d20C6a62fF67A167C\n\nSafe\nImplementation\nAddress: 0x69f4D1788e39c87893C980c06EdF4b7f686e2938\nA multisignature wallet with support for confirmations using signed messages based on ERC191.\nDiffers from SafeL2 by not emitting events to save gas.\nSafeL2\nImplementation\nAddress: 0xfb1bffC9d739B8D520DaF37dF666da4C687191EA\nA multisignature wallet with support for confirmations using signed messages based on ERC191.\nDiffers from Safe by emitting events.\nMultiSend\nImplementation\nAddress: 0x998739BFdAAdde7C933B942a68053933098f9EDa\nAllows to batch multiple transactions into one.\nMultiSendCallOnly\nImplementation\nAddress: 0xA1dabEF33b3B82c7814B6D82A79e50F4AC44102B\nAllows to batch multiple transactions into one, but only calls.\nSafeSingletonFactory\nImplementation\nAddress: 0x914d7Fec6aaC8cd542e72Bca78B30650d45643d7\nSingleton factory used by Safe-related contracts based on\nArachnid's Deterministic Deployment Proxy.\nThe original library used a pre-signed transaction without a chain ID to allow deployment on different chains.\nSome chains do not allow such transactions to be submitted; therefore, this contract will provide the same factory\nthat can be deployed via a pre-signed transaction that includes the chain ID. The key that is used to sign is\ncontrolled by the Safe team.\nMulticall3\nImplementation\nAddress: 0xcA11bde05977b3631167028862bE2a173976CA11\nMulticall3 has two main use cases:\n\nAggregate results from multiple contract reads into a single JSON-RPC request.\nExecute multiple state-changing calls in a single transaction.\n\nCreate2Deployer\nImplementation\nThe create2Deployer is a nice Solidity wrapper around the CREATE2 opcode. It provides the following ABI.\n /**\n * @dev Deploys a contract using `CREATE2`. The address where the\n * contract will be deployed can be known in advance via {computeAddress}.\n *\n * The bytecode for a contract can be obtained from Solidity with\n * `type(contractName).creationCode`.\n *\n * Requirements:\n * - `bytecode` must not be empty.\n * - `salt` must have not been used for `bytecode` already.\n * - the factory must have a balance of at least `value`.\n * - if `value` is non-zero, `bytecode` must have a `payable` constructor.\n */\n function deploy(uint256 value, bytes32 salt, bytes memory code) public;\n /**\n * @dev Deployment of the {ERC1820Implementer}.\n * Further information: https://eips.ethereum.org/EIPS/eip-1820\n */\n function deployERC1820Implementer(uint256 value, bytes32 salt);\n /**\n * @dev Returns the address where a contract will be stored if deployed via {deploy}.\n * Any change in the `bytecodeHash` or `salt` will result in a new destination address.\n */\n function computeAddress(bytes32 salt, bytes32 codeHash) public view returns (address);\n /**\n * @dev Returns the address where a contract will be stored if deployed via {deploy} from a\n * contract located at `deployer`. If `deployer` is this contract's address, returns the\n * same value as {computeAddress}.\n */\n function computeAddressWithDeployer(\n bytes32 salt,\n bytes32 codeHash,\n address deployer\n ) public pure returns (address);\n\nAddress: 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2\nWhen Canyon activates, the contract code at 0x13b0D85CcB8bf860b6b79AF3029fCA081AE9beF2 is set to\n0x6080604052600436106100435760003560e01c8063076c37b21461004f578063481286e61461007157806356299481146100ba57806366cfa057146100da57600080fd5b3661004a57005b600080fd5b34801561005b57600080fd5b5061006f61006a366004610327565b6100fa565b005b34801561007d57600080fd5b5061009161008c366004610327565b61014a565b60405173ffffffffffffffffffffffffffffffffffffffff909116815260200160405180910390f35b3480156100c657600080fd5b506100916100d5366004610349565b61015d565b3480156100e657600080fd5b5061006f6100f53660046103ca565b610172565b61014582826040518060200161010f9061031a565b7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe082820381018352601f90910116604052610183565b505050565b600061015683836102e7565b9392505050565b600061016a8484846102f0565b949350505050565b61017d838383610183565b50505050565b6000834710156101f4576040517f08c379a000000000000000000000000000000000000000000000000000000000815260206004820152601d60248201527f437265617465323a20696e73756666696369656e742062616c616e636500000060448201526064015b60405180910390fd5b815160000361025f576040517f08c379a000000000000000000000000000000000000000000000000000000000815260206004820181905260248201527f437265617465323a2062797465636f6465206c656e677468206973207a65726f60448201526064016101eb565b8282516020840186f5905073ffffffffffffffffffffffffffffffffffffffff8116610156576040517f08c379a000000000000000000000000000000000000000000000000000000000815260206004820152601960248201527f437265617465323a204661696c6564206f6e206465706c6f790000000000000060448201526064016101eb565b60006101568383305b6000604051836040820152846020820152828152600b8101905060ff815360559020949350505050565b61014e806104ad83390190565b6000806040838503121561033a57600080fd5b50508035926020909101359150565b60008060006060848603121561035e57600080fd5b8335925060208401359150604084013573ffffffffffffffffffffffffffffffffffffffff8116811461039057600080fd5b809150509250925092565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052604160045260246000fd5b6000806000606084860312156103df57600080fd5b8335925060208401359150604084013567ffffffffffffffff8082111561040557600080fd5b818601915086601f83011261041957600080fd5b81358181111561042b5761042b61039b565b604051601f82017fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe0908116603f011681019083821181831017156104715761047161039b565b8160405282815289602084870101111561048a57600080fd5b826020860160208301376000602084830101528095505050505050925092509256fe608060405234801561001057600080fd5b5061012e806100206000396000f3fe6080604052348015600f57600080fd5b506004361060285760003560e01c8063249cb3fa14602d575b600080fd5b603c603836600460b1565b604e565b60405190815260200160405180910390f35b60008281526020818152604080832073ffffffffffffffffffffffffffffffffffffffff8516845290915281205460ff16608857600060aa565b7fa2ef4600d742022d532d4747cb3547474667d6f13804902513b2ec01c848f4b45b9392505050565b6000806040838503121560c357600080fd5b82359150602083013573ffffffffffffffffffffffffffffffffffffffff8116811460ed57600080fd5b80915050925092905056fea26469706673582212205ffd4e6cede7d06a5daf93d48d0541fc68189eeb16608c1999a82063b666eb1164736f6c63430008130033a2646970667358221220fdc4a0fe96e3b21c108ca155438d37c9143fb01278a3c1d274948bad89c564ba64736f6c63430008130033.\nCreateX\nImplementation\nAddress: 0xba5Ed099633D3B313e4D5F7bdc1305d3c28ba5Ed\nCreateX introduces additional logic for deploying contracts using CREATE, CREATE2 and CREATE3.\nIt adds salt protection for sender and chainID\nand includes a set of helper functions.\nThe keccak256 of the CreateX bytecode is 0xbd8a7ea8cfca7b4e5f5041d7d4b17bc317c5ce42cfbc42066a00cf26b43eb53f.\nArachnid's Deterministic Deployment Proxy\nImplementation\nAddress: 0x4e59b44847b379578588920cA78FbF26c0B4956C\nThis contract can deploy other contracts with a deterministic address on any chain using CREATE2. The CREATE2\ncall will deploy a contract (like CREATE opcode) but instead of the address being\nkeccak256(rlp([deployer_address, nonce])) it instead uses the hash of the contract's bytecode and a salt.\nThis means that a given deployer address will deploy the\nsame code to the same address no matter when or where they issue the deployment. The deployer is deployed\nwith a one-time-use account, so no matter what chain the deployer is on, its address will always be the same. This\nmeans the only variables in determining the address of your contract are its bytecode hash and the provided salt.\nBetween the use of CREATE2 opcode and the one-time-use account for the deployer, this contracts ensures\nthat a given contract will exist at the exact same address on every chain, but without having to use the\nsame gas pricing or limits every time.\nPermit2\nImplementation\nAddress: 0x000000000022D473030F116dDEE9F6B43aC78BA3\nPermit2 introduces a low-overhead, next-generation token approval/meta-tx system to make token approvals easier,\nmore secure, and more consistent across applications.\nERC-4337 v0.6.0 EntryPoint\nImplementation\nAddress: 0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789\nThis contract verifies and executes the bundles of ERC-4337 v0.6.0\nUserOperations sent to it.\nERC-4337 v0.6.0 SenderCreator\nImplementation\nAddress: 0x7fc98430eaedbb6070b35b39d798725049088348\nHelper contract for EntryPoint v0.6.0, to call userOp.initCode from a \"neutral\" address,\nwhich is explicitly not EntryPoint itself.\nERC-4337 v0.7.0 EntryPoint\nImplementation\nAddress: 0x0000000071727De22E5E9d8BAf0edAc6f37da032\nThis contract verifies and executes the bundles of ERC-4337 v0.7.0\nUserOperations sent to it.\nERC-4337 v0.7.0 SenderCreator\nImplementation\nAddress: 0xEFC2c1444eBCC4Db75e7613d20C6a62fF67A167C\nHelper contract for EntryPoint v0.7.0, to call userOp.initCode from a \"neutral\" address,\nwhich is explicitly not EntryPoint itself.","tokens":2646,"squid":"ink-governance","role":"Council Listener","at":1791261658037,"hash":"1a273e08cf25e1516b4e138f7dac79278bb57c66"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/l2-to-l1-messaging","domain":"docs.arbitrum.io","title":"Child to parent chain messaging | Arbitrum Docs","text":"✏️Request an updateLooking for implementation guides?This document explains the protocol-level concepts of child-to-parent messaging. For practical, step-by-step instructions on implementing withdrawals and messaging, see How to bridge to parent chain from child chain.\nArbitrum's outbox system allows arbitrary child-to-parent chain contract calls, i.e., messages initiated from the child chain that will eventually resolve through execution on the parent chain.\nChild-to-parent chain messages (i.e., outgoing messages) bear some things in common with Arbitrum’s parent chain to child chain messages, which are “in reverse” with differences, which we’ll explore in this section.\nExecuting one of these messages on the parent chain requires the containing assertion to be confirmed, which is a stronger guarantee than a batch reaching the parent chain. Finality explains why posting a batch does not make funds withdrawable.\nProtocol flow​\nMessages from child to parent chains are included in Arbitrum’s Rollup state and finalized through the Rollup protocol. The process follows these steps:\n\nMessage creation on child chain:\n\nTo initiate a child-to-parent chain message, a user or contract calls the sendTxToL1 method on the ArbSys precompile.\n\nMessage inclusion in an assertion:\n\nThe message is batched with other transactions and included in a Rollup assertion.\nAssertions are submitted to the Rollup contract on the parent chain and enter the dispute window (6.4 days).\n\nAssertion confirmation:\n\nIf the assertion remains unchallenged after the dispute window, the Rollup contract finalizes the assertion.\nThe assertion's Merkle root gets posted to the outbox contract on the parent chain.\n\nExecution on the parent chain:\n\nOnce the assertion is confirmed, anyone can execute the message on the parent chain by proving its inclusion.\nExecution is possible via Outbox.executeTransaction, which accepts a Merkle proof that the message exists in the finalized assertion.\n\nSending and executing messages​\nChild-to-parent messages are sent via the ArbSys precompile's sendTxToL1 method. After the approximately 7-day challenge period, messages can be executed on the parent chain using the Outbox.executeTransaction method with a Merkle proof obtained from the NodeInterface contract.\nFor step-by-step implementation instructions, see How to bridge to parent chain.\nProtocol design details​\nConstant overhead for node confirmation​\n\nCalling confirmNode on the Rollup contract has constant gas overhead, regardless of the number of messages in the assertion.\nThis confirmation ensures malicious actors cannot grief the network by submitting assertions with many outgoing messages.\n\nWhy child to parent chain messages require manual execution​\nUnlike retryable tickets, which can execute automatically with pre-funded gas, child-to-parent chain messages must be executed manually because Ethereum (i.e., the parent chain) does not support scheduled execution.\nHowever, applications can implement execution markets that allow third parties to execute messages for a fee.\nPersistence and expiry​\n\nChild-to-parent chain messages: Persist indefinitely on the parent chain once included in the outbox.\n\nParent-to-child chain message lifecycle​\nEach message progresses through three primary states:\nStageDescriptionPosted on child chainThe message is sent via ArbSys.sendTxToL1.Waiting for finalizationThe assertion containing the message is in the challenge period (~6.4 days)Confirmed and executable on the parent chainIf no fraud proof is submitted, the assertion is confirmed, and the message is available for execution in the outbox.\nAsset withdrawals​\nETH withdrawals​\nArbitrum has a canonical bridge design and architecture, which we explain in detail in the Token bridging section of the Bridging from a parent chain to a child chain article. This section explains how the Arbitrum canonical bridge works for child-to-parent chain token bridging.\nThe ArbSys precompile provides a withdrawEth convenience method for withdrawing ETH from the child chain. This method burns the ETH on the child chain and creates a child-to-parent message. Like all child-to-parent messages, it requires execution on the parent chain after the challenge period via Outbox.executeTransaction.\nFor implementation details, see Withdrawing ETH.\nERC-20 token withdrawals​\nToken withdrawals use Arbitrum's canonical bridge architecture, detailed in the Token bridging overview. The process flows through the L2GatewayRouter to the appropriate gateway contract (L2ArbitrumGateway), which burns the child chain tokens and creates a message to the parent chain gateway. After the challenge period, the message can be executed on the parent chain to release tokens from escrow.\nFor implementation details, see Withdrawing ERC-20 tokens.Protocol flowSending and executing messagesProtocol design detailsConstant overhead for node confirmationWhy child to parent chain messages require manual executionPersistence and expiryParent-to-child chain message lifecycleAsset withdrawalsETH withdrawalsERC-20 token withdrawals","tokens":1271,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261664348,"hash":"993061bff7e643779055225e92039040ce026597"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"Trustless Bitcoin Bridge Creation with Witness Encryption \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2022\n\n 1 / 26\n\n Feb 2022\n\n Apr 2024\n\n post by leohio on Feb 6, 2022\n\n leohio\n\n Lead Author: Leona Hioki\nCoauthor : 3966f482edb3843a7cdfb9ffa6840023\nTL;DR: Controlling bitcoin possession by a state condition of Ethereum in a cryptographic way. A trusted setup like Groth16’s Powers of Tau ceremony is required. No need for any node with liveness.\nIntroduction\nWe propose a trustless WBTC configuration that neither depends on a custodian nor an individual that provides excessive collateral. We achieve it relying solely on a cryptographic scheme called Witness Encryption (WE). The WE scheme enables us to encrypt a secret key of Bitcoin addresses holding the deposited bitcoins, while requiring witness of WBTC amortization on the Ethereum blockchain to decrypt the ciphertext. This feature guarantees that only users who possess valid witness can recover the secret key and withdraw the deposited bitcoins.\nBackground\nIt is not easy to transfer a bitcoin to the Ethereum blockchain because the Bitcoin blockchain and the Ethereum blockchain operate independently. However, there has been a bridging mechanism to make this possible, and the cryptographic asset that utilizes this mechanism is WBTC (Wrapped Bitcoin ( WBTC ) an ERC20 token backed 1:1 with Bitcoin, n.d.).\nWith WBTC, when a user sends bitcoins to a third party’s bitcoin address, s/he can mint the sending amount as WBTC on the Ethereum blockchain (i.e., increases the bitcoin balance). S/he can also send WBTC to other users on the Ethereum blockchain. When a user who holds WBTC redeems WBTC on the Ethereum blockchain (i.e., decreases the bitcoin balance), the third party will send it back to the user’s Bitcoin address. In the existing schemes of WBTC, the user needs either a custodian that manages the deposited bitcoins or an individual that provides excessive collateral beyond what they need in standard financial transactions. This is because, under the programmatic form of Bitcoin Script (Script Bitcoin Wiki, n.d.) used in the Bitcoin protocol, we have thought that it is impossible to mint WBTC using cryptography alone up until now. In other words, if the Bitcoin script had the same functionality as a smart contract on the Ethereum blockchain, it would be possible to design a custodianfree WBTC by building a smart contract with logic to verify the state of the Ethereum blockchain and send the deposited bitcoins according to that state. However, the current Bitcoin script can only support few cryptographic schemes such as verifying digital signatures, so no one has believed this is possible to achieve.\nApproach\nWe created a method that relies solely on cryptography using Witness Encryption (WE), one of the cryptographic schemes already introduced by the pioneers (Garg, Gentry, Sahai, & Waters, 2013), to realize WBTC without the need for an administrator such as a custodian or an individual with incentives. While in ordinary public-key cryptography schemes, a holder of a particular secret key can decrypt a ciphertext, in the WE scheme, s/he encrypts a message for an instance to a condition described as an NP relation, which is satisfied by inputs and witness in NP problems, and only the holder of that witness can decrypt the ciphertext (Garg et al., 2013) (Goldwasser, Kalai, Popa, Vaikuntanathan, & Zeldovich, 2013). In our proposed WBTC, the secret key is encrypted using the WE scheme, and only the user who holds the valid witness to amortize the WBTC on the Ethereum blockchain can decrypt the ciphertext when s/he provide it.\nwe_er_final_rep11000×563 24.6 KB\nIn the deposit process, a user records a public key of the Bitcoin deposit address (Bitcoin address to which a bitcoin holder sends his or her bitcoins in order to mint WBTC) in the smart contract for our program; then sends the user’s bitcoin to the address. The user generates proof of the deposit with a non-interactive zero-knowledge (NIZK) proof system. If and only if the proof passed the verification, the smart contract will mint the WBTC.\nIn the withdrawal process, a user first amortizes the WBTC with specifying the public key of the deposit address to be used. If the amortization process completes, the smart contracts issue an event log. Providing the above data along with the user’s digital signature, the user can recover the secret key of the deposit address from the ciphertext. The user finally sends the bitcoin in the deposit address to the user’s Bitcoin address.\nWhile the deposit address is generated as an N-of-N multi-signature address, our system eliminates the need of liveness of any third parties or custodians. Specifically, the security of deposited bitcoins can be maintained as far as at least one of the generator behaves honestly only during address generation. This is because a malicious generator of the multi-signature address needs to collude with all of the generators to steal the fund, but a user holding a valid witness can decypt all of the secret key.\nIn the above process, we may identify transactions for all deposits and withdrawals with other transactions on the Bitcoin blockchain, since the deposit address is fixed. Using a random public key, we can randomize the deposited address and improve its anonymity. A user in the deposit process additionally generates a random secret/public keys and records the public key in the smart contract. The user then sends the bitcoin to a stealth address derived from the random secret key. A user in the withdrawal process recovers the secret key of the stealth address from the decrypted secret key and the random public key, so that the user can withdraw the bitcoin in the stealth address. A third party that knows neither the random secret key nor the decrypted secret key cannot derive the stealth address under the decisional Diffie–Hellman (DDH) assumption.\nDetail\nDetail-1: Witness Encryption\nA WE scheme is defined for an NP language L (with corresponding witness relation R), and consists of the encyption and decryption algorithms (Garg et al., 2013):\nWE.Enc(1λ,x,m): It takes a security parameter λ, an instance x, and a message m ∈ {0,1}. It returns a ciphertext ct.\nWE.Dec(ct,w): It takes a ciphertext ct and a witness w. It returns a message m iff R(x,w) holds.\nTo decrypt a ciphertext ct, a valid witness w for the instance x is necessary. Therefore, no one can decrypt the ciphertext encrypted for the x \\not\\in \\mathbb{L}\\(x \\not\\in \\mathbb{L}\\) (i.e. there is no witness w such that R(x,w) holds). This property is defined as ”soundness security” in (Garg et al., 2013).\n(Goldwasser et al., 2013) introduced a more robust definition of security: ”extractable security”. Informally, this definition guarantees that an adversary must obtain a valid witness w from x, when the adversary can recover the message from the ciphertext for an instance x ∈ \\mathbb{L}\\(\\mathbb{L}\\). The WE scheme used in our program should satisfy it since we encrypt any secret keys for the instances x ∈ \\mathbb{L}\\(\\mathbb{L}\\).\nIn the following description of our protocol, we assume that the WE scheme is defined for the subset sum language L, which is one of the NP-complete problems. Since the circuit satisfiability problem (circuit-SAT) can be reduced to the subset sum problem, a boolean circuit C can represent the decryption condition (Bartusek et al., 2020). A message is encrypted for an instance xC depending on the circuit C. The ciphertext is decrypted if the witness w satisfies C(w) = 1.\nIn Appendix, we introduce a candidate of the WE scheme that we plan to adopt as the underlying WE scheme for the first implementation of our program.\nTo the best of our knowledge, the most practical WE scheme is ADP-based WE proposed in (Bartusek et al., 2020). While there is no security reduction to the standard assumptions for this scheme, it only uses the linear algebra, e.g. random matrix sampling, matrix multiplication, and a determinant. We review its construction in accordance with the description of (Bartusek et al., 2020), and analyze its efficiency in Appendix.\nDetail-2: Deposit Bitcoin\nwe_er_final_rep21000×563 27.3 KB\nBefore sending bitcoins to a deposit address, a user records the public key of the Bitcoin deposit address that s/he wishes to use in the smart contract of our program. At the same time, the user also records the user’s EOA address. Its process is necessary to prevent two users from sending bitcoins to a single Bitcoin deposit address simultaneously: s/he needs to use the Bitcoin deposit address for a single deposit and withdrawal, because its secret key has the property that the user can send all bitcoins associated with their secret key.\nThe fact that the user sent bitcoin to a deposit address on the Bitcoin blockchain is proved by non-interactive zero-knowledge (NIZK) proof system on the Ethereum blockchain (e.g., Groth16 (Groth, 2016), Plonk (Gabizon, Williamson, & Ciobotaru, 2019), ZK-STARK (Ben-Sasson, Bentov, Horesh, & Riabzev, 2018)). After sending bitcoins to the deposit address, the user generates a proof of deposit and records it in a smart contract in our program. Only if that proof can pass the verification process described in the smart contract will the WBTC be minted.\nWe implement functionality of a light client in the Bitcoin network as part of the circuit used by the NIZK proof system. However, the circuit cannot directly perform the verification of the longest chain that requires communication with other nodes (verifying which blockchain is the longest at the moment). Instead, our circuit verifies it based on the difficulty value: as a given blockchain, it accepts only those whose cumulative difficulty is greater than the minimum cumulative difficulty value fixed or adjusted in the smart contract.\nIf this system does not exist, i.e., only the number of succeeding blocks is verified, an attacker can generate false proofs that pass verification without recording the deposit transaction in the longest chain, as follows:\n\nCreate a branch of the longest chain (we will call this branch the ”private branch”).\n\nSend the attacker’s bitcoins to the deposit address on the private branch.\n\nGenerate a new block containing the deposit transaction with taking a sufficiently long time.\n\nGenerate as many blocks as necessary to follow the above blocks. However, the difficulty adjustment algorithm in the Bitcoin protocol allows this process to be completed quickly by lowering the next difficulty, if the attacker intentionally declares a longer time than it took.\n\nFeed the block header and deposit transaction in the private branch to our circuit to generate a proof of deposit.\n\nFeed that proof to our program’s smart contract. This proof should be able to pass verification so that we can mint the WBTC.\n\nSuppose, when the attacker includes a delayed timestamp in the block header to reduce the next difficulty, the cumulative difficulty value becomes smaller than the specified minimum value. Therefore, we can mitigate this attack by verifying the cumulative difficulty value.\nTo summarize the above discussion, bitcoin deposits can be realized securely by 1 to 6 as follows:\n\nThe format of each block header is correct (e.g., the nonce of each block header satisfies the PoW constraints).\n\nExcept for the last block header, the block hash of each block header is referenced as the previous block hash in the block header that follows it.\n\nThe first block header is the one that follows the finalized block header. However, the finalized block header is determined during address generation.\n\nThe cumulative difficulty value is greater than the given minimum cumulative difficulty value in the last block header.\n\nThe transaction format is correct, and its hash value is contained in the Merkle Root in the block header at the specified block height.\n\nThe recipient’s address in the transaction is equal to the deposit address, and the transfer amount is equivalent to the value fixed in the system.\n\nDetail-3: Withdraw Bitcoin\nBefore all, special thanks to Barry Whitehat(https://ethresear.ch/u/barrywhitehat) for his insight about preventing an attack from virtual malicious validators on Ethereum2.0.\nwe_er_final_rep31000×563 24.9 KB\nTo send bitcoins from a Bitcoin deposit address, the user specifies the public key of the deposit address to be used and amortizes the same amount of WBTC on the Ethereum blockchain. To verify the result of this process, we use an event log, a record that a smart contract can publish depending on its execution. The smart contract in our program will issue an event log containing the specified public key and the user’s EOA address only if its amortization process completes without any problems.\nThe user then waits for the block containing the event log to be finalized in the Ethereum 2.0 blockchain. (We assume that the Ethereum 2.0 blockchain will be our program’s primary service source when it goes live.)\nAfter finalizing that block, the user records the latest block of the Ethereum 2.0 blockchain into the Bitcoin blockchain. The Bitcoin script specification allows the ”OP_RETURN script” (Script Bitcoin Wiki, n.d.) to write arbitrary data into the transaction. Using this feature, the user records a block of data as a single bitcoin transaction. We call this transaction ”a commitment transaction”. The reason for recording the block is to prevent block cloaking attacks (so called Block Withholding Attack), in which a large group of colluding validators confirms the invalid blocks forked from the current honest chain and hides them. Those dishonest validators can escape the penalty by hiding the block, even though they are worse enough to be punished by a slashing mechanism. For this reason, our program’s system forces us to publish the same blocks used in the condition on the Bitcoin blockchain.\nFinally, the user generates a digital signature using a secret key that corresponds to the user’s EOA address. The decryption condition of the WE scheme of this program requires a digital signature tied to the EOA address contained in the event log, so it guarantees that no other user can decrypt the ciphertext. Using the Bitcoin block header and Ethereum 2.0 block header (= Bitcoin/Ethereum 2.0 block header), the latest Ethereum 2.0 block, commitment transaction, event log, and the user’s digital signature as witness, the user can withdraw bitcoin securely by allowing the ciphertext to be decrypted\niff the user can satisfy the following conditions.\n\nThe format of each Bitcoin/Ethereum 2.0 block header is correct.\n\nThe block hash of each Bitcoin/Ethereum 2.0 block header is the previous block hash in the block header that follows it, except for the last one.\n\nThe first Bitcoin/Ethereum 2.0 block header follows the respective finalized block header. (WE encryption fixes the finalized block header.)\n\nThe cumulative difficulty value is greater than the minimum cumulative difficulty value in the last Bitcoin block header. (WE encryption fixes the minimum cumulative difficulty value.)\n\nThe latest Ethereum 2.0 block has been confirmed with a digital signature generated by a good percentage of validators.\n\nThe data in the block corresponding to the last Ethereum 2.0 block header is recorded in a commitment transaction, which is included in the Bitcoin block at the specified block height.\n\nThe event log is contained in the Ethereum 2.0 block at the specified block height.\n\nThe digital signature is generated by the secret key associated with the EOA address in the event log.\n\nAfter recovering the secret key corresponding to the specified public key through this process, the user generates a digital signature and sends the Bitcoin to the user’s Bitcoin address.\nDetail-4: Generate Bitcoin deposit address\nThe Bitcoin deposit address generator creates a pair of a new secret key, a public key, and a Bitcoin deposit address. These empty Bitcoin deposit addresses will not be credited with bitcoins during the pre-launch phase of our program but will be the deposit addresses after launching the service. The generator simultaneously encrypts these secret keys with WE and publishes the addresses and ciphertext.\nAs already mentioned, no one should expose the embedded secret key, but the generator will inevitably know the secret key. In this respect, this process requires trusting the generator. However, this trust model can be replaced to N-of-N multiple signature addresses, which can minimize the risk of a single generator.\nIn our model, instead of a Bitcoin deposit address generated by a single generator, an N-of-N multi-signature address associated with a public key generated by N different generators is used as the Bitcoin deposit address. Multi-Party Computation (MPC) among N parties generates the multi-signature address. Specifically, each generator generates a new secret key and a ciphertext for its WE scheme. Then, N-of-N multi-signature addresses are obtained from all of their corresponding public keys. A digital signature using all of the generated secret keys is required to send bitcoins from that multi-signature address. Therefore, no generator can send bitcoins illegally, except when all the generators collude.\nHowever, this N-of-N multi-signature address itself is a standard method, and simply using it would require the N people in question to gather together and perform some action each time bitcoin is withdrawn, which is unrealistic in terms of operation. Therefore, while based on N-of-N multiple signature addresses, there should be no need for the generators to gather and perform some action after setup, and there should be no risk of users being unable to withdraw bitcoins. This is achievable with the following method.\nThe generator of each component of the N-of-N multi-signature address should first generate proof that each ciphertext was correctly constructed with the WE scheme using the NIZK proof system. If the proofs of all generators are correct, the N-of-N multiple signature address should be recorded in the smart contract. Then, due to the nature of the WE scheme, only users with legitimate witness will recover all secret keys from the ciphertext and generate digital signatures, which will allow them to withdraw the deposited bitcoins at any time.\nDetail-5: Randomization for the deposit and withdrawal\nUsing the following technique can implement a mechanism to improve the system’s privacy in this program.\nThe process implementation alone in the previous sections has the drawback: we may identify transactions for all deposits and withdrawals with other transactions on the Bitcoin blockchain. However, we can let the deposit address random by adding one random public key, and the randomized address can be made indistinguishable from other addresses for any third party.\nThe specific procedure is as follows. (In the following description, Fp denotes a finite field of prime order p. Let G be a group of prime order p, and let G ∈ \\mathbb{G}\\(\\mathbb{G}\\) be its generator.)\nThe deposit process is randomized by modifying it as follows.\n\nThe user generates additional random secret key\nr ∈ \\mathbb{F}p\\(\\mathbb{F}p\\) and public key rG ∈ \\mathbb{G}\\(\\mathbb{G}\\) .\n\nBefore sending bitcoins, the user records rG in the smart contract, along with the user’s EOA address and the specified public key of the fixed Bitcoin deposit address pkD ∈ \\mathbb{G}\\(\\mathbb{G}\\)\n\nThe user generates a unique stealth address (a random address that can only be obtained between two parties and cannot be distinguished from any other address by any other third party) from pkD and r. The public key corresponding to the stealth address is computed as pkD + Hash (r ·pkD )G ∈ \\mathbb{G}\\(\\mathbb{G}\\) . The user then transfers bitcoins to the stealth address.\n\nProof of deposit in the NIZK proof system provides additional proof that the recipient’s Bitcoin address is a stealth address correctly calculated from pkD and r. It also guarantees that rG is equivalent to the recorded random public key.\n\nSimilarly, the withdrawal process is randomized by modifying it as follows.\n\nObtain rG associated with the specified pkD in the WBTC amortization process.\n\nRecover the secret key of the fixed public key (fixed secret key) skD ∈ \\mathbb{F}p\\(\\mathbb{F}p\\) from the ciphertext, and then recover the secret key of the stealth address from skD and rG by computing skD + Hash (r · pkD ) ∈ \\mathbb{F}p\\(\\mathbb{F}p\\)\n\nGenerate a digital signature using the secret key of the stealth address, and send bitcoin from the stealth address.\n\nNote that we must recover skD first to recover the secret key of the stealth address (see above 2.) because pkD and r in our program generate the public key of the stealth address, while skD and a rG can obtain the secret key. This property guarantees that the user who generates the stealth address in the deposit process will not get the secret key for the stealth address.\nConclusion\nIn this post, we proposed the WBTC configuration using Witness Encryption. This eliminates the need for trusted custodians or individuals to cooperate in guaranteeing the value through overcollateralization. Specifically, the security of the deposited bitcoins is maintained if at least one of the participants in the MPC behaves honestly only during address generation. In addition, the anonymity of the deposited address can be improved by randomizing it with a random public key.\nAppendix\nNotions\nLet \\mathbb{N}\\(\\mathbb{N}\\) be a positive integer, \\mathbb{R}\\(\\mathbb{R}\\) be a real number, and \\mathbb{F}_p\\(\\mathbb{F}_p\\) be a finite field of prime order p\\(p\\). For n \\in \\mathbb{N}\\(n \\in \\mathbb{N}\\), let [n]\\([n]\\) denote the set \\{1,\\dots,n\\}\\(\\{1,\\dots,n\\}\\). x \\xleftarrow{U} X\\(x \\xleftarrow{U} X\\) means to extract a random number x\\(x\\) uniformly from X\\(X\\). Let \\mathbb{G}\\(\\mathbb{G}\\) be a group of prime order p\\(p\\), and let G \\in \\mathbb{G}\\(G \\in \\mathbb{G}\\) be its generator.\nThe vector \\boldsymbol{a}\\(\\boldsymbol{a}\\) is \\boldsymbol{a}\\in \\mathbb{F}_p^n\\(\\boldsymbol{a}\\in \\mathbb{F}_p^n\\) in bold lowercase letters and \\boldsymbol{A}\\(\\boldsymbol{A}\\) is \\boldsymbol{A}\\in \\mathbb{F}_p^{n \\times n}\\(\\boldsymbol{A}\\in \\mathbb{F}_p^{n \\times n}\\) in bold uppercase letters. The inner product of \\boldsymbol{A}\\(\\boldsymbol{A}\\) and \\boldsymbol{B}\\(\\boldsymbol{B}\\) is denoted by <\\boldsymbol{A},\\boldsymbol{B}>\\(<\\boldsymbol{A},\\boldsymbol{B}>\\). The det(\\boldsymbol{A})\\(det(\\boldsymbol{A})\\) denotes the determinant of matrix \\boldsymbol{A}\\(\\boldsymbol{A}\\).\nWe use \\lambda\\(\\lambda\\) as a security parameter. The function negl(\\lambda): \\mathbb{N} \\rightarrow \\mathbb{R}\\(negl(\\lambda): \\mathbb{N} \\rightarrow \\mathbb{R}\\) exploits the property that a function negl(\\lambda)\\(negl(\\lambda)\\) is said to be negligible if for any constant c>0\\(c>0\\) there exists n \\in \\mathbb{N}\\(n \\in \\mathbb{N}\\) such that negl(\\lambda) < \\lambda^{-c}\\(negl(\\lambda) < \\lambda^{-c}\\) for all \\lambda > n\\(\\lambda > n\\).\nADP-based Witness Encryption\nWe review the ADP-based witness encryption scheme proposed in (Bartusek, “Affine determinant programs”). Note that all of the descriptions in this section are described in (Bartusek, “Affine determinant programs”).\nAs described in section 3 in (Bartusek, “Affine determinant programs”), an affine determinant program (ADP) is denoted by an affine function \\boldsymbol{M}\\(\\boldsymbol{M}\\), which consists of (n+1)\\((n+1)\\)-tuple of regular matrices whose width is k\\(k\\):\nM := (A, \\boldsymbol{B_1},\\dots,\\mathbb{B_n}) \\in \\mathbb{F}_p^{k \\times k} \\times \\dots \\times \\mathbb{F}_p^{k \\times k}\\(M := (A, \\boldsymbol{B_1},\\dots,\\mathbb{B_n}) \\in \\mathbb{F}_p^{k \\times k} \\times \\dots \\times \\mathbb{F}_p^{k \\times k}\\)\nThe affine function \\boldsymbol{M}: \\{0,1\\}^n \\rightarrow F_p^{k \\times k}\\(\\boldsymbol{M}: \\{0,1\\}^n \\rightarrow F_p^{k \\times k}\\) takes an n-length binary input \\mathbb{x} \\in \\{0,1\\}^n\\(\\mathbb{x} \\in \\{0,1\\}^n\\) and evaluate it by the following matrix calculation.\n\\boldsymbol{M}(\\boldsymbol{x}) := \\boldsymbol{A}+\\sum_{i \\in [n]} x_i\\boldsymbol{B_i}.\\(\\boldsymbol{M}(\\boldsymbol{x}) := \\boldsymbol{A}+\\sum_{i \\in [n]} x_i\\boldsymbol{B_i}.\\)\nThe ADP includes an evaluation function that takes the binary input \\mathbb{x}\\(\\mathbb{x}\\), and outputs a single bit 0/1\\(0/1\\) depending on whether det(\\boldsymbol{M}(\\boldsymbol{x}))\\(det(\\boldsymbol{M}(\\boldsymbol{x}))\\) is zero. In other words, its evaluation result is decided if the \\boldsymbol{M}(\\boldsymbol{x})\\(\\boldsymbol{M}(\\boldsymbol{x})\\) is full-rank matrix or not.\nThe ADP can represent an instance of the subset-sum language L\\(L\\), which consists of (\\boldsymbol{h},\\ell) \\in \\mathbb{F}_p^{n} \\times \\mathbb{F}_p\\((\\boldsymbol{h},\\ell) \\in \\mathbb{F}_p^{n} \\times \\mathbb{F}_p\\). If and only if (\\boldsymbol{h},\\ell) \\in L\\((\\boldsymbol{h},\\ell) \\in L\\), there is a witness \\mathbb{w} \\in \\{0,1\\}^n\\(\\mathbb{w} \\in \\{0,1\\}^n\\) such that <\\boldsymbol{h},\\boldsymbol{w}>=\\ell\\(<\\boldsymbol{h},\\boldsymbol{w}>=\\ell\\). Following the definition in section 5.1 in (Bartusek, “Affine determinant programs”), the affine function \\boldsymbol{M}_{\\boldsymbol{h},\\ell}\\(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}\\) for (\\boldsymbol{h},\\ell)\\((\\boldsymbol{h},\\ell)\\) is generated as below:\n\nSample \\boldsymbol{R} \\xleftarrow{U} \\mathbb{F}_p^{k \\times k}\\(\\boldsymbol{R} \\xleftarrow{U} \\mathbb{F}_p^{k \\times k}\\).\nSet \\boldsymbol{A}:=-\\ell \\boldsymbol{R}\\(\\boldsymbol{A}:=-\\ell \\boldsymbol{R}\\).\nFor each i \\in [n]\\(i \\in [n]\\), set \\boldsymbol{B_i}:=h_i\\boldsymbol{R}\\(\\boldsymbol{B_i}:=h_i\\boldsymbol{R}\\).\nOutput \\boldsymbol{M}_{\\boldsymbol{h},\\ell}=(\\boldsymbol{A},\\boldsymbol{B}_1,\\dots,\\boldsymbol{B}_n)\\(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}=(\\boldsymbol{A},\\boldsymbol{B}_1,\\dots,\\boldsymbol{B}_n)\\).\n\nIf the witness \\boldsymbol{w}\\(\\boldsymbol{w}\\) satisfies <\\boldsymbol{h},\\boldsymbol{w}>=\\ell\\(<\\boldsymbol{h},\\boldsymbol{w}>=\\ell\\), the determinant of \\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w})\\(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w})\\) should be zero.\ndet(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w})) = det((-\\ell+\\sum_{i \\in [n]} w_ih_i)\\boldsymbol{R}) = 0\\(det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w})) = det((-\\ell+\\sum_{i \\in [n]} w_ih_i)\\boldsymbol{R}) = 0\\)\nAs the random matrix \\boldsymbol{R}\\(\\boldsymbol{R}\\) is full-rank with high probability, the det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w'}))\\(det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w'}))\\) for the invalid witness \\boldsymbol{w'}\\(\\boldsymbol{w'}\\) is non-zero. Hence, such ADP can decide whether the provided witness is valid for the instance of the subset-sum language.\nTo embed a bit message b \\in \\{0,1\\}\\(b \\in \\{0,1\\}\\) in the ADP, the encryptor samples a random matrix \\boldsymbol{S} \\xleftarrow{U} \\mathbb{F}_p^{k \\times k}\\(\\boldsymbol{S} \\xleftarrow{U} \\mathbb{F}_p^{k \\times k}\\), and adds b\\boldsymbol{S}\\(b\\boldsymbol{S}\\) to \\boldsymbol{A}\\(\\boldsymbol{A}\\) in the tuple of \\boldsymbol{M}_{\\boldsymbol{h},\\ell}\\(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}\\).\n \\boldsymbol{M}_{\\boldsymbol{h},\\ell,b} := \\boldsymbol{M}_{\\boldsymbol{h},\\ell} + (b\\boldsymbol{S},0,\\dots,0)\\( \\boldsymbol{M}_{\\boldsymbol{h},\\ell,b} := \\boldsymbol{M}_{\\boldsymbol{h},\\ell} + (b\\boldsymbol{S},0,\\dots,0)\\)\nThe decryptor who holds the valid witness \\boldsymbol{w}\\(\\boldsymbol{w}\\) can decrypt b\\(b\\) by deciding whether det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{w}))\\(det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{w}))\\) is zero or non-zero. (If and only if b=1\\(b=1\\), det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{w})) \\neq 0\\(det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{w})) \\neq 0\\) since the matrix \\boldsymbol{S}\\(\\boldsymbol{S}\\) is full-rank with high probability.)\nThe above scheme is, however, insecure because an adversary can input an non-binary input \\boldsymbol{x} \\in \\mathbb{F}_p^n\\(\\boldsymbol{x} \\in \\mathbb{F}_p^n\\) to the ADP that satisfies <\\boldsymbol{h},\\boldsymbol{x}>=\\ell\\(<\\boldsymbol{h},\\boldsymbol{x}>=\\ell\\). Such input is easily calculated by solving the simultaneous linear equations.\nTo prevent the non-binary input, \\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}\\(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}\\) is noised by an “All-Accept ADP (Bartusek, “Affine determinant programs”)” \\boldsymbol{M}_{AA}\\(\\boldsymbol{M}_{AA}\\), which have the two properties (following the definition in section 5.1 in (Bartusek, “Affine determinant programs”)):\n\n(Correctness) For all \\boldsymbol{x} \\in \\{0,1\\}^n\\((Correctness) For all \\boldsymbol{x} \\in \\{0,1\\}^n\\), Pr[det(\\boldsymbol{M}_{AA}(\\boldsymbol{x}))=0]=1\\(Pr[det(\\boldsymbol{M}_{AA}(\\boldsymbol{x}))=0]=1\\).\n\n(Rejection of Invalid Inputs) For all non-binary \\boldsymbol{x} \\in \\mathbb{F}_p^n \\setminus \\{0,1\\}^n\\(\\boldsymbol{x} \\in \\mathbb{F}_p^n \\setminus \\{0,1\\}^n\\), \\ Pr[det(\\boldsymbol{M}_{AA}(\\boldsymbol{x}))=0]=negl(\\lambda)\\(Pr[det(\\boldsymbol{M}_{AA}(\\boldsymbol{x}))=0]=negl(\\lambda)\\).\n\nUsing the All-Accept ADP, the ciphertext is built as the following ADP, which is mentioned as a generic candidate in section 5.2 in (Bartusek, “Affine determinant programs”).\n$\n\\boldsymbol{M}{\\boldsymbol{h},\\ell,b} :=\n\\boldsymbol{M}{AA} + \\boldsymbol{M}_{\\boldsymbol{h},\\ell} + (b\\boldsymbol{S},0,\\dots,0)\n$\nFor any non-binary input \\boldsymbol{x} \\in \\mathbb{F}_p^n \\setminus \\{0,1\\}^n\\(\\boldsymbol{x} \\in \\mathbb{F}_p^n \\setminus \\{0,1\\}^n\\), det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{x})) \\neq 0\\(det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{x})) \\neq 0\\) holds since \\boldsymbol{M}_{AA}(\\boldsymbol{x})\\(\\boldsymbol{M}_{AA}(\\boldsymbol{x})\\) is full-rank except with negligible probability. The determinant, therefore, outputs 0\\(0\\) iff b=0\\(b=0\\) and a valid witness \\boldsymbol{w} \\in \\{0,1\\}^n\\(\\boldsymbol{w} \\in \\{0,1\\}^n\\) is provided.\nIn this way, the ADP is helpful to construct the WE scheme for the subset sum language as described in (Bartusek, “Affine determinant programs”). Note that the above explanation only covers the generic candidate. Strictly speaking, the ADP-based WE scheme is constructed for a \"vector subset sum language in (Bartusek, “Affine determinant programs”), which is the generalization of the subset sum language. In the analysis of the efficiency described in Appendix, we assume the concrete candidate defined in section 5.2 in (Bartusek, “Affine determinant programs”).\nAnalysis of the ADP-based Witness Encryption\nBased on the concrete candidate in section 5.2 of (Bartusek, “Affine determinant programs”), we analyze the size of the ciphertext and the complexity of the encryption/decryption. In the following description, m,k\\(m,k\\) denotes the number of variables and clauses in the 3-SAT formula respectively, n\\(n\\) denotes the number of wights in the instance of the subset sum language, p\\(p\\) denotes the order chosen in the WE.Enc algorithm.\nThe size of the ciphertext grows with \\mathcal{O}([\\log_2 p]n^{3+2\\epsilon})\\(\\mathcal{O}([\\log_2 p]n^{3+2\\epsilon})\\). The ciphertext \\boldsymbol{M}\\(\\boldsymbol{M}\\) consists of 2n+1\\(2n+1\\) matrices over \\mathbb{F}_p\\(\\mathbb{F}_p\\), and their each dimension is (2n^{1+\\epsilon}+1) \\times (2n^{1+\\epsilon}+1)\\((2n^{1+\\epsilon}+1) \\times (2n^{1+\\epsilon}+1)\\). The size is, therefore, [\\log_2 p] \\times (2n+1) \\times (2n^{1+\\epsilon}+1)^2=[\\log_2 p](8n^{3+2\\epsilon}+4n^{2+2\\epsilon}+8n^{2+\\epsilon}+4n^{1+\\epsilon}+2n+1)\\([\\log_2 p] \\times (2n+1) \\times (2n^{1+\\epsilon}+1)^2=[\\log_2 p](8n^{3+2\\epsilon}+4n^{2+2\\epsilon}+8n^{2+\\epsilon}+4n^{1+\\epsilon}+2n+1)\\) bits.\nWith m\\(m\\) and k\\(k\\), the growth of the size is also represented as \\mathcal{O}((m+k)^{4+2\\epsilon})\\(\\mathcal{O}((m+k)^{4+2\\epsilon})\\). It is well known that the 3-SAT formula with m\\(m\\) variables and k\\(k\\) clauses is reduced to the instance of the subset sum language with 2m+2k\\(2m+2k\\) weights (Eva Tardos, “Reduction from 3 SAT to MAX CUT”). Replacing n\\(n\\) with 2m+2k\\(2m+2k\\), the number of elements over \\mathbb{F}_p\\(\\mathbb{F}_p\\) in the ciphertext is 2^{6+2\\epsilon}(m+k)^{3+2\\epsilon}+(2^{4+2\\epsilon}+2^{5+\\epsilon})(m+k)^{2+2\\epsilon}+2^{3+\\epsilon}(m+k)^{1+\\epsilon}+2^{2}(m+k)+1\\(2^{6+2\\epsilon}(m+k)^{3+2\\epsilon}+(2^{4+2\\epsilon}+2^{5+\\epsilon})(m+k)^{2+2\\epsilon}+2^{3+\\epsilon}(m+k)^{1+\\epsilon}+2^{2}(m+k)+1\\).\nEach weight of the instance requires (m+k)[\\log_2 10]\\((m+k)[\\log_2 10]\\) bits (Eva Tardos, “Reduction from 3 SAT to MAX CUT”), so that the minimum size of p\\(p\\) satisfying p>\\max_{\\boldsymbol{x}\\in \\{0,1\\}^{2m+2k}}|\\sum_i x_i h_i|\\(p>\\max_{\\boldsymbol{x}\\in \\{0,1\\}^{2m+2k}}|\\sum_i x_i h_i|\\) is 1+[\\log_2(m+k)]+(m+k)[\\log_2 10]\\(1+[\\log_2(m+k)]+(m+k)[\\log_2 10]\\) bits. Hence, the size of the ciphertext is \\{(m+k)[\\log_2 10]+[\\log_2(m+k)]+1\\}\\{2^{6+2\\epsilon}(m+k)^{3+2\\epsilon}+(2^{4+2\\epsilon}+2^{5+\\epsilon})(m+k)^{2+2\\epsilon}+2^{3+\\epsilon}(m+k)^{1+\\epsilon}+2^{2}(m+k)+1\\}\\(\\{(m+k)[\\log_2 10]+[\\log_2(m+k)]+1\\}\\{2^{6+2\\epsilon}(m+k)^{3+2\\epsilon}+(2^{4+2\\epsilon}+2^{5+\\epsilon})(m+k)^{2+2\\epsilon}+2^{3+\\epsilon}(m+k)^{1+\\epsilon}+2^{2}(m+k)+1\\}\\) bits, whose order is \\mathcal{O}((m+k)^{4+2\\epsilon})\\(\\mathcal{O}((m+k)^{4+2\\epsilon})\\).\nThe WE.Enc algorithm includes four types of computations whose complexities depend on n\\(n\\), that is, random sampling over \\mathbb{F}_p\\(\\mathbb{F}_p\\), matrix addition, scalar multiplication, and matrix multiplication. The number of sampled elements in \\mathbb{F}_p\\(\\mathbb{F}_p\\) is\n4\\times 2n(2n^{1+\\epsilon}+1)n^{\\epsilon}+4n^2+(n+2)(2n^{1+\\epsilon}+1)^2=4n^{3+2\\epsilon}+24n^{2+2\\epsilon}+4n^{2+\\epsilon}+4n^2+16n^{1+\\epsilon}+n+2\\(4\\times 2n(2n^{1+\\epsilon}+1)n^{\\epsilon}+4n^2+(n+2)(2n^{1+\\epsilon}+1)^2=4n^{3+2\\epsilon}+24n^{2+2\\epsilon}+4n^{2+\\epsilon}+4n^2+16n^{1+\\epsilon}+n+2\\). The addition between (2n^{1+\\epsilon}+1) \\times (2n^{1+\\epsilon}+1)\\((2n^{1+\\epsilon}+1) \\times (2n^{1+\\epsilon}+1)\\) matrices is computed 4n^2+8n+1\\(4n^2+8n+1\\) times in total. The matrices are multiplied by scalars 4n^2+n+1\\(4n^2+n+1\\) times if b=0\\(b=0\\), and 4n^2+n+2\\(4n^2+n+2\\) times if b=1\\(b=1\\). The number of times of the multiplication between (2n^{1+\\epsilon}+1) \\times n^{\\epsilon}\\((2n^{1+\\epsilon}+1) \\times n^{\\epsilon}\\) matrices is 6n\\(6n\\).\nThe WE.Dec algorithm consists of the computation of the affine function \\boldsymbol{M}\\(\\boldsymbol{M}\\), and its determinant calculation. By the definition of the ADP, the former requires n\\(n\\)-times matrix additions and n\\(n\\)-times scalar multiplications.\nReferences\n[1] Bartusek, J., Ishai, Y., Jain, A., Ma, F., Sahai, A., & Zhandry, M. (2020). Affine determinant programs: A framework for obfuscation and witness encryption. In 11th innovations in theoretical computer science conference (itcs 2020).\n[2] Gavin Uberti, Kevin Luo, Oliver Cheng, Wittmann Goh December, Building Usable Witness Encryption 10, 2021\n[3] Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). Scalable, trans-parent, and post-quantum secure computational integrity. IACR Cryptol. ePrint Arch., 2018, 46.\n[4] Gabizon, A., Williamson, Z. J., & Ciobotaru, O. (2019). Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge. IACR Cryptol. ePrint Arch., 2019, 953.\n[5] Garg, S., Gentry, C., Sahai, A., & Waters, B. (2013). Witness encryption and its applications. In Proceedings of the forty-fifth annual acm symposium on theory of computing (pp. 467–476).\n[6] Goldwasser, S., Kalai, Y. T., Popa, R. A., Vaikuntanathan, V., & Zeldovich, N. (2013). How to run turing machines on encrypted data. In Annual cryptology conference (pp. 536–553).\n[7] Groth, J. (2016). On the size of pairing-based non-interactive arguments. In Annual international conference on the theory and applications of cryptographic techniques (pp. 305–326).\n[8] Script bitcoin wiki. (n.d.). Script - Bitcoin Wiki. ((Accessed on 09/10/2021))\n[9] Tardos, E. (n.d.). Reduction from 3 sat to max cut.\nhttps://www.cs.cornell.edu/courses/cs4820/2015sp/notes/reduction-subsetsum.pdf. ((Accessed on 10/22/2021))\n[10] Wrapped bitcoin ( wbtc ) an erc20 token backed 1:1 with bitcoin.* (n.d.).\nhttps://wbtc.network/. ((Accessed on 11/17/2021))\n\n Practical, Trustless, Bitcoin Bridge\n\n Octopus Contract and its Applications\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n post by JustinDrake on Feb 7, 2022\n\n JustinDrake\n\n Oh wow, very cool that obfuscation is not required \nTLDR: Using an MPC secure with just one honest participant, generate a mint Bitcoin address with the secret key witness encrypted under a proof that the wrapped token was burned.\n\n post by leohio on Feb 8, 2022\n\n leohio\n\n Thank you for the better TLDR than mine.\n\nTR;DR of the mechanism:\nOnly the person who can make a zkp proof of WBTC burn, or in other words, the person who burned WBTC, can know all N multisig private keys and unlock the bitcoin using special decryption. On the other hand, a malicious person has to collude with all the other N people who set the private key, so if there is even one honest person among the N people, they cannot steal it. It’s 99% attack tolerant because they cannot kill the liveness either.\n\n post by wdai on Feb 9, 2022\n\n wdai\n\n This is a fascinating application of witness encryption!\nTo check my understanding, as this part of the bridge is not too explicitly described: the N different deposit address generators (let’s call them bridge managers, since they together do control the funds deposited) would need to manage the total deposited funds to make sure they give out WE ciphertexts to secret keys that holds specific amount of Bitcoins, correct? For example, if there is a single deposit of 2 BTC and then two later withdrawal of 1 BTC each. The bridge managers (generators) need to first split the 2 BTC in the Bitcoin UTXO to two UTXOs holding 1 BTC each.\nOne remark regarding N-of-N multi-signature: since Bitcoin taproot upgrade and the support for Schnorr signatures, the coalition of N “generators” can actually support any threshold T, not just N-of-N–each manager (generator) can release via WE their Shamir-secret share of the actual secret key holding the coins.\nAnd if my above understanding is correct, then one should investigate holistically the differences between releasing secret keys (or shares) via WE and simply providing threshold signatures in the withdraw. To recall briefly the threshold signature based bridge: Deposit works similarly to what is sketched here. For each withdraw: the N bridge managers would independently verify the validity of a withdraw claim (proof of burn of WBTC and BTC withdraw address) and conduct a threshold signing session to transfer the BTC out to the withdraw address (fund splitting can be done at this step).\nSome first remarks regarding the differences (again, if my understanding of your system is correct):\n\nWE solution does not require interaction between the bridge managers (generators / key holders)\nThreshold signing does not rely on additional hardness assumptions that WE require and is more widely-studied (e.g. DFINITY is close to deploying threshold ECDSA on their mainnet. Threshold Schnorr is arguably simpler, e.g.this paper from 2001.)\nThe actual trust assumption on the bridge managers, for both liveness and security, on the N bridge managers could be the same between the two solutions, in that one could select any threshold T.\n\n post by Killari on Feb 11, 2022\n\n Killari\n\n Sounds super interesting!\nI don’t really understand how can you recover the private key as a proof of burn of WTC? Is there some kind of light client in question that you produce a proof that there is enough PoW on top of the transaction you did?\n\n post by leohio on Feb 11, 2022\n\n leohio\n\n I’m glad to have you interested in this.\n\nThis is the exact part Witness Encryption is in charge of.\nCipher texts of Witness Encryption can be decrypted when the set circuit is satisfied.\nWe set a zkp circuit verifying that WBTC token is burned on Ethereum Layer1 by a withdrawer, as a circuit of Witness Encryption.\nThe recent Witness Encryption is getting realistic rapidly.\nADP\nExact Cover\n\nThe proof of difficulty and the proof of rightness on Ethereum PoS can be also verified by zkp circuits.\nThere no need of light clients to verify the bridge, this is why this is described like this.\n\nAlso, to complete the proof of rightness on Ethereum PoS, the proof of publishment of Ethereum PoS activity is on the Bitcoin blockchain OP_RETURN and included in the input of the zkp circuit. This prevents the colluded PoS validators from forking the chain privately to fake the WBTC burning on it.\n\n post by leohio on Feb 11, 2022\n\n leohio\n\n I am fed back the concern that the circuitry of the WE may become inconsistent during a hard fork, making decryption impossible, but this is solvable and something we did not mention in this paper for simplicity.\nIn a simple construction, we consider the block header as a target for signature by PoS validators, but what we really want the circuit to validate is the irreversible inclusion of the states into the Merkle Root. The circuit should be fine as long as this is satisfied.\nIf we hard fork to a Layer1 configuration that does not have irreversible inclusion, that would put Layer1 in danger.\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for the feedback with the information on the many protocols.\nI think the priority is answering this part.\n\nThe difference is simply here:\nIf the threshold is T of N of the multi-sig,\nSafety Byzantine fault tolerance of multi-sig with witness encryption: N-1 / N (99% tolerance)\nSafety Byzantine fault tolerance of multi-sig with Shnorr threshold signature: T / N\nLiveness Byzantine fault tolerance of multi-sig with witness encryption: N / N (No one can stop it)\nLiveness Byzantine fault tolerance of multi-sig with Shnorr threshold signature: N-T / N (If N-T+1 nodes go offline, the system stops)\nThe trade-off of Safety(Security) and Liveness shifts to a better way.\nSo I can say this part stronger, “There’re no key holders, there’re cipher text holders.”\n\nDFINITY’s threshold and its chain-key technology are quite smart but they are still relying on the online/liveness assumption of the validator in the subnet.\n\nAnd about here,\n\nThe deposit addresses are one-time-use and with fixed amounts, since once the secret key is revealed by the decryption of WE, the decryptor can take everything from this private key after that.\nThere’s no split of UTXOs in this system.\nTo prevent the collision during the time before a several blocks confirmation, the deposit address needs to be booked by the depositor.\nThe generators are different from depositors, and this fact is misleading as this system relies on the liveness/online assumption of somebody. This system is independent of generators by the MPC setup including multi-sig. This setup has features similar to the Power of Tau ceremony of zkSNARKs.\nI’m looking forward to having your feedback again.\n\n post by experience on Feb 12, 2022\n\n experience\n\n Very interesting proposal, I had been looking forward to promising applications of Witness Encryption and this looks like it! I have many questions but let’s start with three:\n1/ Is it correct that in your proposed scheme, the entire set of key pairs for deposit addresses is generated in an initial trusted setup, such that when we run out of addresses, another trusted ceremony would need to take place?\n2/ Are you suggesting to store the ciphertexts in an on-chain contract? I imagine this would be a mapping to keep track of which ciphertexts have been decrypted by users who completed a withdrawal request.\n3/ You say that the proof of inclusion can be verified by zkp circuits ifor Ethereum PoS too, but how exactly would you go about this without your proof program running a node that connects to the network? For PoW we can just verify that the cumulative proof of work of the series of block header (of which one contains the event log) is sufficiently high with minimal security tradeoffs, but on PoS you need to verify that you have the correct genesis state, and that the majority of signers that signed a block are indeed mainnet signers, and not signers of some other locally spawned fork \nBrilliant idea overall, looking forward to reading more about this!\n\n post by Killari on Feb 12, 2022\n\n Killari\n\n leohio\n\n Hey,\nThank you for the reading material :). I checked them through and I think I understand this better now. I think you need to be able to formulate Ethereum light client as a exact cover problem, which then reveals the private key of the bitcoin deposit. In PoW version you make the client just verify the pow and that it contains the right transactions (the deposit and the wbtc burn). In PoS you do the same but with validator signatures.\nThis made me to start to think how to attack this system, and the clear way to attack this is that when someone makes a btc deposit and mints the wbtc, you fork the Ethereum chain and start mining. Let’s assume we require 10 eth blocks worth of PoW in the proof. This would mean that once a deposit is made, attacker starts to mine on PRIVATE fork of the Ethereum starting from the deposit block. Once the attacker has been able to mine 10 blocks, they can produce the proof and steal the money. This fork is never published, there’s no direct competition. The only competition is that someone could withdraw the money using the purposed way.\nTo perform this attack, the miner needs to be able to produce 10 blocks worth of work. This cost should be higher than what the btc deposit is worth, for the system to be economically to secure by game theory. Ofcourse a suicidal whale could burn more money to steal the btc.\nHowever, this attack gets worse, as the attacker can steal ALL the deposits with the same 10 proof of work blocks… To combat this I guess one could make the withdrawal process work in a way that you can only withdraw one deposit at once and then you need to wait some amount of time until a new withdrawal can be started. This ensures that each robbery would require the same 10 pow blocks. This would hinder the usability of the protocol.\nDo you happen to have a discord server or similar to chat more about this topic? It would be interesting to collaborate!\n\n post by leohio on Feb 12, 2022\n\n leohio\n\nYes, let’s!!\n\nYes, we need it when we are short of deposit addresses.\n\nYes, on-chain or on a data-shard is the best way. Anyway, we need put data related to the ciphertexts to the input of zkp circuits which are proving the relationship between deposit addresses and ciphertexts. Without this, a depositor can put bitcoin into a faked deposit address. This circuit needs to guarantee that withdrawers can decrypt the ciphertexts when they burn Wrapped BTC, as described in this part.\n\nThen, about this.\n\nThis is prevented like this way. This is not my idea but Barry’s idea.\n\nFirst of all, the block signers of the faked offchain blockchain can be slashed and punished when only one honest person publishes it, among the colluded signers. This is the slash mechanism of Ethereum against the double votes to the fork. But when the colluded signers use MPC to eliminate the honest person, this security collapses. Then the signs or the hint/index of the signs should be published on Bitcoin blockchain. The OP_RETURN space is rather small, so some kind of an index to search this sign data is better to be written in OP_RETURN. Finally, the colluded signers cannot generate faked chains out of the network secretly.\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for attacking this virtually!\n\nI think this is exactly what we intended to prevent with this mechanism.\n\nIs this answering your question?\nThis is the cost comparison between the mega slash event of 1/3 of PoS validators and unlocking all of the Wrapped BTC in this system in the worst case, and there’s no guarantee to succeed this attack while the mega slash will certainly happen.\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n igorsyl\n\n @leohio @KanaPalladium : thank you for working on this! A couple of questions:\n\nWhat progress has been made since this post was published over a year ago, and\nis the prototype described above available publicly?\n\nIn the meantime, the current prototype requires about 20 minutes to encrypt a message using a tiny problem. Therefore, we need to develop various speedup methods to implement a real-world Wrapped Bitcoin.\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n leohio\n\n I made sure that “KanaPalladium” was not my co-author more than one year ago. Sorry to be late for reporting this.\nMy co-author, whose name was encrypted, said he had no account named “KanaPalladium.” And his name is not “Hiro.”\nThe person who uses the account knows me I guess, but please don’t receive any invitation from him just in case. Ignore the account if he talks about “investment to WE project.”\nEncrypting the author’s name was a mistake. I highly recommend people not to try it.\n\nBasically, no update, and just waiting for new WEs. But signature-based WE (https://fc23.ifca.ai/preproceedings/189.pdf) can be useful enough to update this architecture.\nADP can remain the best unless we have the multi-pairing.\nThe weakness of ADP is that one gate increases the length of cipher-text (memory consumption) 4x.\nSo, the direction is to make it with fewer constraints or to update WE to avoid ADP.\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n kravets\n\n kravets\n\n AI summary of recent practical WE algos\nhttps://app.cognosys.ai/s/a6AyKlf\n\n post by kravets on Aug 3, 2023\n\n kravets\n\n Links 2, 3, 4 here are the paper, the presentation PDF and the video of what might be the state of the art in WE\nhttps://www.google.com/search?q=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&oq=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&aqs=chrome..69i57.1511j0j1&sourceid=chrome&ie=UTF-8\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n Load more posts below","tokens":13292,"squid":"ink-research","role":"Deep Scholar","at":1791261672337,"hash":"cfb853f6216702152e5df8723d31170005362f05"}
{"url":"https://governance.aave.com/t/temp-check-deploy-aave-v4-on-arc/24990","domain":"governance.aave.com","title":"[Temp Check] Deploy Aave V4 on Arc - Governance / New Market - Aave","text":"[Temp Check] Deploy Aave V4 on Arc \n\n GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 29\n\n 1 / 6\n\n May 29\n\n Jun 7\n\n post by AaveLabs on May 29\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n V4_AVAX (4)1920×1028 75 KB\nSimple Summary\nThis Temp Check seeks community feedback on deploying Aave V4 on Arc alongside supporting an initial set of high-quality assets.\nArc is an institutional-grade public layer-1 blockchain, built by Circle and designed to be the Economic Operating System (OS) of the internet for digital dollar liquidity and real-world assets. Launching Aave V4 on Arc would position Aave as foundational financial infrastructure on a network optimized for capital-efficient liquidity flows from regulated institutions.\nThis Temp Check is intended to gauge community sentiment on:\n\nDeploying Aave V4 on Arc at or near mainnet launch\nSupporting the proposed initial asset scope\nAdvancing the proposal to the ARFC stage\n\nIf there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers.\nMotivation\nArc is preparing for mainnet launch. The permissionless blockchain is purpose built for stablecoins, tokenized real world assets, and global onchain finance. Arc, built by Circle, is focused on bringing DeFi innovation into traditional financial workflows to unlock new capital formation and expand the market for onchain credit and liquidity. As the Economic OS for the internet, Arc is designed to coordinate onchain credit and financial primitives with treasury backed instruments, tokenized assets, and compliance aligned infrastructure in a single onchain capital environment.\nDeploying Aave V4 on Arc would:\n\nEstablish Aave as one of the primary lending protocols at network launch\nGrow Aave’s available markets for Circle-issued assets\nExpand Aave’s presence into new institutional and fintech liquidity flows\nDrive incremental TVL and revenue opportunities for the Aave ecosystem\n\nArc’s design concentrates regulated stablecoin liquidity and tokenized products into a programmable settlement layer. Integrating Aave into the Economic OS positions it to serve as one of the primary lending protocols for capital forming on the network.\nA core objective of this deployment is to support meaningful stablecoin and tokenized asset liquidity at scale, subject to risk provider recommendations.\nSpecification\nIf there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design/liquidity commitments, and parameter recommendations from relevant Aave DAO service providers.\nFull technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers will be presented during ARFC.\nAsset Scope\nThe initial asset set proposed includes:\n\nUSDC\nEURC\ncirBTC\n\nThe intent is to consolidate assets into a single formal governance process where possible to reduce fragmentation and minimize proposal overhead.\nFinal asset inclusion and parameters will be subject to:\n\nAave DAO service provider feedback\n\nRevenue Support\nIn connection with the deployment, Aave DAO is expected to receive a minimum of $2m per year in protocol revenue from the Aave V4 deployment on Arc, with any shortfalls covered by certain Arc ecosystem participants for the first five years following deployment. This structure provides protection for Aave DAO during the bootstrap phase.\nUseful Links\n\nWebsite: https://www.arc.network/\nLitepaper: https://www.arc.network/litepaper\n\nDisclaimer\nAave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is not directly affiliated with Arc and did not receive compensation for this proposal.\nNext Steps\nIf this Temp Check indicates sufficient community support, the proposal will proceed as follows:\nPhase 1 - Snapshot vote on Temp Check\nPhase 2 – ARFC (Aave Request for Final Comments)\nPhase 3 – AIP (Onchain Vote)\nFollowing Snapshot approval, the final AIP payload will be submitted on Ethereum mainnet for onchain execution.\nDeployment preparation would begin after ARFC passage, with activation following successful AIP approval.\nRequested Feedback\nThe community is invited to provide feedback on:\n\nDeploying Aave V4 on Arc\nSupporting the proposed initial asset scope\nAdvancing this proposal to the ARFC stage\n\nIf there is sufficient positive sentiment, the authors will proceed with a detailed ARFC submission.\nCopyright\nCopyright and related rights waived via CC0.\n\n post by A_J on May 30\n\n post by axieaur on May 30\n\n post by MconnectDAO on May 30\n\n post by bobgodwinx on Jun 1\n\n post by Abel189 on Jun 7\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n AL Technical Assessment Aave <> Arc\n\n Assessments\n\n 0\n\n 141\n\n Sep 14\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d","tokens":1318,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261673150,"hash":"ad6d9a918c10639b2c6f67a8c45ba042db5cf019"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/precompiles/reference","domain":"docs.arbitrum.io","title":"Precompiles reference | Arbitrum Docs","text":"✏️Request an updateArbOS provides child chain-specific precompiles with methods smart contracts can call the same way they can solidity functions. This reference page exhaustively documents the specific calls ArbOS makes available through precompiles. For a more conceptual description of what precompiles are and how they work, please refer to the precompiles conceptual page.\nThis reference page is divided into two sections. The first one lists all precompiles in a summary table with links to the reference of the specific precompile, along with the address where they live, their purpose and links to the go implementation and solidity interface. The second one details the methods available in each precompile with links to the specific implementation.\nGeneral information of precompiles​\nThis section is divided into two tables. We first list precompiles we expect users to most often use, and then the rest of precompiles. However, both tables display the same information: name and purpose of the precompile, address, and links to the solidity interface and the go implementation.\nCommon precompiles​\nPrecompileAddressSolidity interfaceGo implementationPurposeArbAggregator0x6dInterfaceImplementationConfiguring transaction aggregationArbGasInfo0x6cInterfaceImplementationInfo about gas pricingArbRetryableTx0x6eInterfaceImplementationManaging retryablesArbSys0x64InterfaceImplementationSystem-level functionalityArbWasm0x71InterfaceImplementationManages Stylus contractsArbWasmCache0x72InterfaceImplementationManages Stylus cache\nOther precompiles​\nPrecompileAddressSolidity interfaceGo implementationPurposeArbAddressTable0x66InterfaceImplementationSupporting compression of addressesArbBLS---Disabled (Former registry of BLS public keys)ArbDebug0xffInterfaceImplementationTesting toolsArbFunctionTable0x68InterfaceImplementationNo longer usedArbInfo0x65InterfaceImplementationInfo about accountsArbOwner0x70InterfaceImplementationChain administration, callable only by chain ownerArbOwnerPublic0x6bInterfaceImplementationInfo about chain ownersArbosTest0x69InterfaceImplementationNo longer usedArbStatistics0x6fInterfaceImplementationInfo about the pre-Nitro state\nPrecompiles reference​\nArbAddressTable​\nArbAddressTable (Interface | Implementation) provides the ability to create short-hands for commonly used accounts.\nFor a working example of using ArbAddressTable to register addresses and retrieve their indices, see the address-table tutorial.\nPrecompile address: 0x0000000000000000000000000000000000000066\n\nMethodSolidity interfaceGo implementationDescriptionaddressExists(address addr)InterfaceImplementationAddressExists checks if an address exists in the tablecompress(address addr)InterfaceImplementationCompress and returns the bytes that represent the addressdecompress(bytes calldata buf, uint256 offset)InterfaceImplementationDecompress the compressed bytes at the given offset with those of the corresponding accountlookup(address addr)InterfaceImplementationLookup the index of an address in the tablelookupIndex(uint256 index)InterfaceImplementationLookupIndex for an address in the table by indexregister(address addr)InterfaceImplementationRegister adds an account to the table, shrinking its compressed representationsize()InterfaceImplementationSize gets the number of addresses in the table\nArbAggregator​\nArbAggregator (Interface | Implementation) provides aggregators and their users methods for configuring how they participate in parent chain aggregation. Arbitrum One's default aggregator is the Sequencer, which a user will prefer unless SetPreferredAggregator is invoked to change it.\nCompression ratios are measured in basis points. Methods that are checkmarked are access-controlled and will revert if not called by the aggregator, its fee collector, or a chain owner.\nPrecompile address: 0x000000000000000000000000000000000000006D\n\nMethodSolidity interfaceGo implementationDescription⚠️getPreferredAggregator(address addr)InterfaceImplementationGetPreferredAggregator returns the preferred aggregator address. Deprecated: Do not use this method.⚠️getDefaultAggregator()InterfaceImplementationGetDefaultAggregator returns the default aggregator address. Deprecated: Do not use this method.getBatchPosters()InterfaceImplementationGetBatchPosters gets the addresses of all current batch postersaddBatchPoster(address newBatchPoster)InterfaceImplementationAdds additional batch poster addressgetFeeCollector(address batchPoster)InterfaceImplementationGetFeeCollector gets a batch poster's fee collectorsetFeeCollector(address batchPoster, address newFeeCollector)InterfaceImplementationSetFeeCollector sets a batch poster's fee collector (caller must be the batch poster, its fee collector, or an owner)⚠️getTxBaseFee(address aggregator)InterfaceImplementationGetTxBaseFee gets an aggregator's current fixed fee to submit a tx Deprecated: always returns zero⚠️setTxBaseFee(address aggregator, uint256 feeInL1Gas)InterfaceImplementationSetTxBaseFee sets an aggregator's fixed fee (caller must be the aggregator, its fee collector, or an owner) Deprecated: no-op\nNote: methods marked with ⚠️ are deprecated and their use is not supported.\nArbBLS​\nDisabledThis precompile has been disabled. It previously provided a registry of BLS public keys for accounts.\nArbDebug​\nArbDebug (Interface | Implementation) provides mechanisms useful for testing. The methods of ArbDebug are only available for chains with the AllowDebugPrecompiles chain parameter set. Otherwise, calls to this precompile will revert.\nPrecompile address: 0x00000000000000000000000000000000000000ff\n\nMethodSolidity interfaceGo implementationDescriptionbecomeChainOwner()InterfaceImplementationCaller becomes a chain owneroverwriteContractCode(address target, bytes calldata newCode)InterfaceImplementationOverwrite an existing contract's codeevents(bool flag, bytes32 value)InterfaceImplementationEmits events with values based on the args providedeventsView()InterfaceImplementationTries (and fails) to emit logs in a view contextcustomRevert(uint64 number)InterfaceImplementationThrows a custom errorpanic()InterfaceImplementationHalts the chain by panicking in the STFlegacyError()InterfaceImplementationThrows a hardcoded error\nEventSolidity interfaceGo implementationDescriptionBasicInterfaceImplementationEmitted in Events for testingMixedInterfaceImplementationEmitted in Events for testingStoreInterfaceImplementationNever emitted (used for testing log sizes)\nArbFunctionTable​\nArbFunctionTable (Interface | Implementation) provides aggregators the ability to manage function tables, to enable one form of transaction compression. The Nitro aggregator implementation does not use these, so these methods have been stubbed and their effects disabled. They are kept for backwards compatibility.\nPrecompile address: 0x0000000000000000000000000000000000000068\n\nMethodSolidity interfaceGo implementationDescriptionupload(bytes calldata buf)InterfaceImplementationUpload does nothingsize(address addr)InterfaceImplementationSize returns the empty table's size, which is 0get(address addr, uint256 index)InterfaceImplementationGet reverts since the table is empty\nArbGasInfo​\nArbGasInfo (Interface | Implementation) provides insight into the cost of using the chain. These methods have been adjusted to account for Nitro's heavy use of calldata compression. Of note to end-users, we no longer make a distinction between non-zero and zero-valued calldata bytes. For a practical guide on using these methods alongside NodeInterface to estimate transaction costs, see How to estimate gas.\nPrecompile address: 0x000000000000000000000000000000000000006C\n\nMethodSolidity interfaceGo implementationDescriptiongetPricesInWeiWithAggregator(address aggregator)InterfaceImplementationGetPricesInWeiWithAggregator gets prices in wei when using the provided aggregatorgetPricesInWei()InterfaceImplementationGetPricesInWei gets prices in wei when using the caller's preferred aggregatorgetPricesInArbGasWithAggregator(address aggregator)InterfaceImplementationGetPricesInArbGasWithAggregator gets prices in ArbGas when using the provided aggregatorgetPricesInArbGas()InterfaceImplementationGetPricesInArbGas gets prices in ArbGas when using the caller's preferred aggregatorgetGasAccountingParams()InterfaceImplementationGetGasAccountingParams gets the rollup's speed limit, pool size, and block gas limitgetMaxTxGasLimit()InterfaceImplementationGetMaxTxGasLimit gets the max tx gas limitgetMinimumGasPrice()InterfaceImplementationGetMinimumGasPrice gets the minimum gas price needed for a transaction to succeedgetL1BaseFeeEstimate()InterfaceImplementationGetL1BaseFeeEstimate gets the current estimate of the L1 basefeegetL1BaseFeeEstimateInertia()InterfaceImplementationGetL1BaseFeeEstimateInertia gets how slowly ArbOS updates its estimate of the L1 basefeegetL1RewardRate()InterfaceImplementationGetL1RewardRate gets the L1 pricer reward rategetL1RewardRecipient()InterfaceImplementationGetL1RewardRecipient gets the L1 pricer reward recipientgetL1GasPriceEstimate()InterfaceImplementationGetL1GasPriceEstimate gets the current estimate of the L1 basefeegetCurrentTxL1GasFees()InterfaceImplementationGetCurrentTxL1GasFees gets the fee in wei paid to the batch poster for posting this txgetGasBacklog()InterfaceImplementationGetGasBacklog gets the backlogged amount of gas burnt in excess of the speed limitgetPricingInertia()InterfaceImplementationGetPricingInertia gets how slowly ArbOS updates the L2 basefee in response to backlogged gasgetGasBacklogTolerance()InterfaceImplementationGetGasBacklogTolerance gets the forgivable amount of backlogged gas ArbOS will ignore when raising the basefeegetL1PricingSurplus()InterfaceImplementationGetL1PricingSurplus gets the surplus of funds for L1 batch posting payments (may be negative)getPerBatchGasCharge()InterfaceImplementationGetPerBatchGasCharge gets the base charge (in L1 gas) attributed to each data batch in the calldata pricergetAmortizedCostCapBips()InterfaceImplementationGetAmortizedCostCapBips gets the cost amortization cap in basis pointsgetL1FeesAvailable()InterfaceImplementationGetL1FeesAvailable gets the available funds from L1 feesgetL1PricingEquilibrationUnits()InterfaceImplementationGetL1PricingEquilibrationUnits gets the equilibration units parameter for L1 price adjustment algorithm (Available since ArbOS 20)getLastL1PricingUpdateTime()InterfaceImplementationGetLastL1PricingUpdateTime gets the last time the L1 calldata pricer was updated (Available since ArbOS 20)getL1PricingFundsDueForRewards()InterfaceImplementationGetL1PricingFundsDueForRewards gets the amount of L1 calldata payments due for rewards (per the L1 reward rate) (Available since ArbOS 20)getL1PricingUnitsSinceUpdate()InterfaceImplementationGetL1PricingUnitsSinceUpdate gets the amount of L1 calldata posted since the last update (Available since ArbOS 20)getLastL1PricingSurplus()InterfaceImplementationGetLastL1PricingSurplus gets the L1 pricing surplus as of the last update (may be negative) (Available since ArbOS 20)getMaxBlockGasLimit()InterfaceImplementationGetMaxBlockGasLimit gets the maximum block gas limitgetGasPricingConstraints()InterfaceImplementationGetGasPricingConstraints gets the current gas pricing constraints used by the Multi-Constraint Pricer.getMultiGasPricingConstraints()InterfaceImplementationGetMultiGasPricingConstraints returns the current configuration of multi-gas pricing constraintsgetMultiGasBaseFee()InterfaceImplementationGetMultiGasBaseFee gets the current base fee for each resource type used by the Multi-Constraint Pricer\nArbInfo​\nArbInfo (Interface | Implementation) provides the ability to lookup basic info about accounts and contracts.\nPrecompile address: 0x0000000000000000000000000000000000000065\n\nMethodSolidity interfaceGo implementationDescriptiongetBalance(address account)InterfaceImplementationGetBalance retrieves an account's balancegetCode(address account)InterfaceImplementationGetCode retrieves a contract's deployed code\nArbNativeTokenManager​\nArbNativeTokenManager (Interface | Implementation) enables minting and burning of the chain's native gas token by callers authorized through the ArbOwner precompile. Available since ArbOS 41.\nPrecompile address: 0x0000000000000000000000000000000000000073\n\nMethodSolidity interfaceGo implementationDescriptionmintNativeToken(uint256 amount)InterfaceImplementationMints some amount of the native gas token for this chain to the given address (Available since ArbOS 41)burnNativeToken(uint256 amount)InterfaceImplementationBurns some amount of the native gas token for this chain from the given address (Available since ArbOS 41)\nEventSolidity interfaceGo implementationDescriptionNativeTokenMintedInterfaceImplementationEmitted when native gas token is minted to a NativeTokenOwnerNativeTokenBurnedInterfaceImplementationEmitted when native gas token is burned from a NativeTokenOwner\nArbosTest​\nArbosTest (Interface | Implementation) provides a method of burning arbitrary amounts of gas, which exists for historical reasons. In Classic, ArbosTest had additional methods only the zero address could call. These have been removed since users don't use them and calls to missing methods revert.\nPrecompile address: 0x0000000000000000000000000000000000000069\n\nMethodSolidity interfaceGo implementationDescriptionburnArbGas(uint256 gasAmount)InterfaceImplementationBurnArbGas unproductively burns the amount of L2 ArbGas\nArbOwner​\nArbOwner (Interface | Implementation) provides owners with tools for managing the rollup. Calls by non-owners will always revert.\nMost of Arbitrum Classic's owner methods have been removed since they no longer make sense in Nitro:\n\nWhat were once chain parameters are now parts of ArbOS's state, and those that remain are set at genesis.\nArbOS upgrades happen with the rest of the system rather than being independent\nExemptions to address aliasing are no longer offered. Exemptions were intended to support backward compatibility for contracts deployed before aliasing was introduced, but no exemptions were ever requested.\n\nPrecompile address: 0x0000000000000000000000000000000000000070\n\nMethodSolidity interfaceGo implementationDescriptionaddChainOwner(address newOwner)InterfaceImplementationAddChainOwner adds account as a chain ownerremoveChainOwner(address ownerToRemove)InterfaceImplementationRemoveChainOwner removes account from the list of chain ownersisChainOwner(address addr)InterfaceImplementationIsChainOwner checks if the account is a chain ownergetAllChainOwners()InterfaceImplementationGetAllChainOwners retrieves the list of chain ownerssetNativeTokenManagementFrom(uint64 timestamp)InterfaceImplementationSetNativeTokenManagementFrom sets native token management enabled-from time.setTransactionFilteringFrom(uint64 timestamp)InterfaceImplementationSetTransactionFilteringFrom sets transaction filtering enabled-from time.addNativeTokenOwner(address newOwner)InterfaceImplementationAddNativeTokenOwner adds account as a native token ownerremoveNativeTokenOwner(address ownerToRemove)InterfaceImplementationRemoveNativeTokenOwner removes account from the list of native token ownersisNativeTokenOwner(address addr)InterfaceImplementationIsNativeTokenOwner checks if the account is a native token ownergetAllNativeTokenOwners()InterfaceImplementationGetAllNativeTokenOwners retrieves the list of native token ownersaddTransactionFilterer(address filterer)InterfaceImplementationAddTransactionFilterer adds account as a transaction filterer (authorized to use ArbFilteredTransactionsManager)removeTransactionFilterer(address filterer)InterfaceImplementationRemoveTransactionFilterer removes account from the list of transaction filterersisTransactionFilterer(address filterer)InterfaceImplementationIsTransactionFilterer checks if the account is a transaction filterergetAllTransactionFilterers()InterfaceImplementationGetAllTransactionFilterers retrieves the list of transaction filtererssetFilteredFundsRecipient(address newRecipient)InterfaceImplementationSetFilteredFundsRecipient sets the address that receives funds redirected from filtered transactions. Set to address(0) to use the networkFeeAccount as fallback.getFilteredFundsRecipient()InterfaceImplementationGetFilteredFundsRecipient gets the address that receives funds redirected from filtered transactions. Returns address(0) if not explicitly set (networkFeeAccount is used as fallback at runtime).setL1BaseFeeEstimateInertia(uint64 inertia)InterfaceImplementationSetL1BaseFeeEstimateInertia sets how slowly ArbOS updates its estimate of the L1 basefeesetL2BaseFee(uint256 priceInWei)InterfaceImplementationSetL2BaseFee sets the L2 gas price directly, bypassing the pool calculussetMinimumL2BaseFee(uint256 priceInWei)InterfaceImplementationSetMinimumL2BaseFee sets the minimum base fee needed for a transaction to succeedsetSpeedLimit(uint64 limit)InterfaceImplementationSetSpeedLimit sets the computational speed limit for the chainsetMaxTxGasLimit(uint64 limit)InterfaceImplementationSetMaxTxGasLimit sets the maximum size a tx can besetMaxBlockGasLimit(uint64 limit)InterfaceImplementationSetMaxBlockGasLimit sets the maximum size a block can besetL2GasPricingInertia(uint64 sec)InterfaceImplementationSetL2GasPricingInertia sets the L2 gas pricing inertiasetL2GasBacklogTolerance(uint64 sec)InterfaceImplementationSetL2GasBacklogTolerance sets the L2 gas backlog tolerancegetNetworkFeeAccount()InterfaceImplementationGetNetworkFeeAccount gets the network fee collectorgetInfraFeeAccount()InterfaceImplementationGetInfraFeeAccount gets the infrastructure fee collectorsetNetworkFeeAccount(address newNetworkFeeAccount)InterfaceImplementationSetNetworkFeeAccount sets the network fee collector to the new network fee accountsetInfraFeeAccount(address newInfraFeeAccount)InterfaceImplementationSetInfraFeeAccount sets the infrastructure fee collector addressscheduleArbOSUpgrade(uint64 newVersion, uint64 timestamp)InterfaceImplementationScheduleArbOSUpgrade to the requested version at the requested timestampsetL1PricingEquilibrationUnits(uint256 equilibrationUnits)InterfaceImplementationSets equilibration units parameter for L1 price adjustment algorithmsetL1PricingInertia(uint64 inertia)InterfaceImplementationSets inertia parameter for L1 price adjustment algorithmsetL1PricingRewardRecipient(address recipient)InterfaceImplementationSets reward recipient address for L1 price adjustment algorithmsetL1PricingRewardRate(uint64 weiPerUnit)InterfaceImplementationSets reward amount for L1 price adjustment algorithm, in wei per unitsetL1PricePerUnit(uint256 pricePerUnit)InterfaceImplementationSet how much ArbOS charges per L1 gas spent on transaction data.setParentGasFloorPerToken(uint64 floorPerToken)InterfaceImplementationSet how much L1 charges per non-zero byte of calldatasetPerBatchGasCharge(int64 cost)InterfaceImplementationSets the base charge (in L1 gas) attributed to each data batch in the calldata pricersetBrotliCompressionLevel(uint64 level)InterfaceImplementationSets the Brotli compression level used for fast compression (default level is 1)setAmortizedCostCapBips(uint64 cap)InterfaceImplementationSets the cost amortization cap in basis pointsreleaseL1PricerSurplusFunds(uint256 maxWeiToRelease)InterfaceImplementationReleases surplus funds from L1PricerFundsPoolAddress for usesetInkPrice(uint32 price)InterfaceImplementationSets the amount of ink 1 gas buyssetWasmMaxStackDepth(uint32 depth)InterfaceImplementationSets the maximum depth (in wasm words) a wasm stack may growsetWasmFreePages(uint16 pages)InterfaceImplementationSets the number of free wasm pages a tx receivessetWasmPageGas(uint16 gas)InterfaceImplementationSets the base cost of each additional wasm pagesetWasmPageLimit(uint16 limit)InterfaceImplementationSets the initial number of pages a wasm may allocatesetWasmMaxSize(uint32 size)InterfaceImplementationSetMaxWasmSize sets the maximum size the wasm code can be in bytes after decompression.setWasmMinInitGas(uint8 gas, uint16 cached)InterfaceImplementationSets the minimum costs to invoke a programsetWasmInitCostScalar(uint64 percent)InterfaceImplementationSets the linear adjustment made to program init costssetWasmExpiryDays(uint16 _days)InterfaceImplementationSets the number of days after which programs deactivatesetWasmKeepaliveDays(uint16 _days)InterfaceImplementationSets the age a program must be to perform a keepalivesetWasmBlockCacheSize(uint16 count)InterfaceImplementationSets the number of extra programs ArbOS caches during a given blockaddWasmCacheManager(address manager)InterfaceImplementationAdds account as a wasm cache managerremoveWasmCacheManager(address manager)InterfaceImplementationRemoves account from the list of wasm cache managerssetChainConfig(string calldata chainConfig)InterfaceImplementationSets serialized chain config in ArbOS statesetCalldataPriceIncrease(bool enable)InterfaceImplementationSetCalldataPriceIncrease sets the increased calldata price feature on or off (EIP-7623)setGasBacklog(uint64 backlog)InterfaceImplementationSetGasBacklog sets the L2 gas backlog directly (used by single-constraint pricing model only)setGasPricingConstraints(uint64[3][] calldata constraints)InterfaceImplementationSetGasPricingConstraints sets the gas pricing constraints used by the multi-constraint pricing modelsetMultiGasPricingConstraints(ArbMultiGasConstraintsTypes.ResourceConstraint[] calldata constraints)InterfaceImplementationSetMultiGasPricingConstraints configures the multi-dimensional gas pricing modelsetCollectTips(bool collectTips)InterfaceImplementationSetCollectTips enables or disables tip collection. When enabled, transaction tips are collected by the network fee account. When disabled (default), tips are dropped.setMaxStylusContractFragments(uint8 maxFragments)InterfaceImplementationsetWasmActivationGas(uint64 gas)InterfaceImplementationSets the constant gas charge applied before each stylus contract activation. Defaults to zero. Can be raised to deter DOS via activations, or set to a value exceeding the block gas limit to block all activations entirely.\nEventSolidity interfaceGo implementationDescriptionTransactionFiltererAddedInterfaceImplementation@notice Emitted when an address is added as a transaction filterer.TransactionFiltererRemovedInterfaceImplementation@notice Emitted when an address is removed as a transaction filterer.FilteredFundsRecipientSetInterfaceImplementation@notice Emitted when the filtered funds recipient address is changed. @notice Available in ArbOS version 60 and aboveChainOwnerAddedInterfaceImplementation@notice Emitted when an address is added as a chain owner. @notice Available in ArbOS version 60 and aboveChainOwnerRemovedInterfaceImplementation@notice Emitted when an address is removed as a chain owner. @notice Available in ArbOS version 60 and aboveNativeTokenOwnerAddedInterfaceImplementation@notice Emitted when an address is added as a native token owner. @notice Available in ArbOS version 60 and aboveNativeTokenOwnerRemovedInterfaceImplementation@notice Emitted when an address is removed as a native token owner. @notice Available in ArbOS version 60 and aboveOwnerActsInterfaceImplementationEmitted when a successful call is made to this precompile\nArbOwnerPublic​\nArbOwnerPublic (Interface | Implementation) provides non-owners with info about the current chain owners.\nPrecompile address: 0x000000000000000000000000000000000000006b\n\nMethodSolidity interfaceGo implementationDescriptionisChainOwner(address addr)InterfaceImplementationIsChainOwner checks if the user is a chain ownerrectifyChainOwner(address ownerToRectify)InterfaceImplementationRectifyChainOwner checks if the account is a chain owner (Available since ArbOS 11)getAllChainOwners()InterfaceImplementationGetAllChainOwners retrieves the list of chain ownersgetNativeTokenManagementFrom()InterfaceImplementationGetNativeTokenMangementFrom returns the time in epoch seconds when the native token management becomes enabledisNativeTokenOwner(address addr)InterfaceImplementationIsNativeTokenOwner checks if the account is a native token ownergetAllNativeTokenOwners()InterfaceImplementationGetAllNativeTokenOwners retrieves the list of native token ownersgetTransactionFilteringFrom()InterfaceImplementationTransactionFilteringFrom returns the time in epoch seconds when the transaction filtering feature becomes enabledisTransactionFilterer(address filterer)InterfaceImplementationIsTransactionFilterer checks if the account is a transaction filterergetAllTransactionFilterers()InterfaceImplementationGetAllTransactionFilterers retrieves the list of transaction filterersgetFilteredFundsRecipient()InterfaceImplementationGetFilteredFundsRecipient gets the address that receives funds redirected from filtered transactions. Returns address(0) if not explicitly set (networkFeeAccount is used as fallback at runtime).getNetworkFeeAccount()InterfaceImplementationGetNetworkFeeAccount gets the network fee collectorgetInfraFeeAccount()InterfaceImplementationGetInfraFeeAccount gets the infrastructure fee collectorgetBrotliCompressionLevel()InterfaceImplementationGetBrotliCompressionLevel gets the current brotli compression level used for fast compressiongetParentGasFloorPerToken()InterfaceImplementationGet how much L1 charges per non-zero byte of calldatagetScheduledUpgrade()InterfaceImplementationGetScheduledUpgrade gets the next scheduled ArbOS version upgrade and its activation timestamp. Returns (0, 0, nil) if no ArbOS upgrade is scheduled.isCalldataPriceIncreaseEnabled()InterfaceImplementationIsCalldataPriceIncreaseEnabled checks if the increased calldata price feature (EIP-7623) is enabledgetCollectTips()InterfaceImplementationGetCollectTips returns whether tip collection is enabled.getMaxStylusContractFragments()InterfaceImplementation\nEventSolidity interfaceGo implementationDescriptionChainOwnerRectifiedInterfaceImplementationEmitted when verifying a chain owner\nArbRetryableTx​\nArbRetryableTx (Interface | Implementation) provides methods for managing retryables. The model has been adjusted for Nitro, most notably in terms of how retry transactions are scheduled. For more information on retryables, please see the retryable documentation. For a worked example of creating and redeeming retryables from application code, see How to bridge from the parent chain.\nPrecompile address: 0x000000000000000000000000000000000000006E\n\nMethodSolidity interfaceGo implementationDescriptionredeem(bytes32 ticketId)InterfaceImplementationRedeem schedules an attempt to redeem the retryable, donating all of the call's gas to the redeem attemptgetLifetime()InterfaceImplementationGetLifetime gets the default lifetime period a retryable has at creationgetTimeout(bytes32 ticketId)InterfaceImplementationGetTimeout gets the timestamp for when ticket will expirekeepalive(bytes32 ticketId)InterfaceImplementationKeepalive adds one lifetime period to the ticket's expirygetBeneficiary(bytes32 ticketId)InterfaceImplementationGetBeneficiary gets the beneficiary of the ticketcancel(bytes32 ticketId)InterfaceImplementationCancel the ticket and refund its callvalue to its beneficiarygetCurrentRedeemer()InterfaceImplementationGets the redeemer of the current retryable redeem attemptsubmitRetryable(bytes32 requestId, uint256 l1BaseFee, uint256 deposit, uint256 callvalue, uint256 gasFeeCap, uint64 gasLimit, uint256 maxSubmissionFee, address feeRefundAddress, address beneficiary, address retryTo, bytes calldata retryData)InterfaceImplementationDo not call. This method represents a retryable submission to aid explorers. Calling it will always revert.\nEventSolidity interfaceGo implementationDescriptionTicketCreatedInterfaceImplementationEmitted when creating a retryableLifetimeExtendedInterfaceImplementationEmitted when extending a retryable's expiry dateRedeemScheduledInterfaceImplementationEmitted when scheduling a retryableCanceledInterfaceImplementationEmitted when cancelling a retryableRedeemedInterfaceImplementationDEPRECATED in favour of new RedeemScheduled event after the nitro upgrade.\nArbStatistics​\nArbStatistics (Interface | Implementation) provides statistics about the chain as of just before the Nitro upgrade. In Arbitrum Classic, this was how a user would get info such as the total number of accounts, but there are better ways to get that info in Nitro.\nPrecompile address: 0x000000000000000000000000000000000000006F\n\nMethodSolidity interfaceGo implementationDescriptiongetStats()InterfaceImplementationGetStats returns the current block number and some statistics about the rollup's pre-Nitro state\nArbSys​\nArbSys (Interface | Implementation) provides system-level functionality for interacting with the parent chain and understanding the call stack.\nPrecompile address: 0x0000000000000000000000000000000000000064\n\nMethodSolidity interfaceGo implementationDescriptionarbBlockNumber()InterfaceImplementationArbBlockNumber gets the current L2 block numberarbBlockHash(uint256 arbBlockNum)InterfaceImplementationArbBlockHash gets the L2 block hash, if sufficiently recentarbChainID()InterfaceImplementationArbChainID gets the rollup's unique chain identifierarbOSVersion()InterfaceImplementationArbOSVersion gets the current ArbOS versiongetStorageGasAvailable()InterfaceImplementationGetStorageGasAvailable returns 0 since Nitro has no concept of storage gasisTopLevelCall()InterfaceImplementationIsTopLevelCall checks if the call is top-level (deprecated)mapL1SenderContractAddressToL2Alias(address sender, address unused)InterfaceImplementationMapL1SenderContractAddressToL2Alias gets the contract's L2 aliaswasMyCallersAddressAliased()InterfaceImplementationWasMyCallersAddressAliased checks if the caller's caller was aliasedmyCallersAddressWithoutAliasing()InterfaceImplementationMyCallersAddressWithoutAliasing gets the caller's caller without any potential aliasingwithdrawEth(address destination)InterfaceImplementationWithdrawEth send paid eth to the destination on L1sendTxToL1(address destination, bytes calldata data)InterfaceImplementationSendTxToL1 sends a transaction to L1, adding it to the outboxsendMerkleTreeState()InterfaceImplementationSendMerkleTreeState gets the root, size, and partials of the outbox Merkle tree state (caller must be the 0 address)\nEventSolidity interfaceGo implementationDescriptionL2ToL1TxInterfaceImplementationLogs a send transaction from L2 to L1, including data for outbox provingL2ToL1TransactionInterfaceImplementationDEPRECATED in favour of the new L2ToL1Tx event above after the nitro upgradeSendMerkleUpdateInterfaceImplementationLogs a new merkle branch needed for constructing outbox proofs\nArbWasm​\nArbWasm (Interface | Implementation) provides helper methods for managing Stylus contracts\nPrecompile address: 0x0000000000000000000000000000000000000071\n\nMethodSolidity interfaceGo implementationDescriptionactivateProgram(address program)InterfaceImplementationCompile a wasm program with the latest instrumentationstylusVersion()InterfaceImplementationGets the latest stylus versioncodehashVersion(bytes32 codehash)InterfaceImplementationGets the stylus version that program with codehash was most recently compiled withcodehashKeepalive(bytes32 codehash)InterfaceImplementationExtends a program's expiration date (reverts if too soon)codehashAsmSize(bytes32 codehash)InterfaceImplementationGets a program's asm size in bytesprogramVersion(address program)InterfaceImplementationGets the stylus version that program at addr was most recently compiled withprogramInitGas(address program)InterfaceImplementationGets the cost to invoke the programprogramMemoryFootprint(address program)InterfaceImplementationGets the footprint of program at addrprogramTimeLeft(address program)InterfaceImplementationGets returns the amount of time remaining until the program expiresinkPrice()InterfaceImplementationGets the amount of ink 1 gas buysmaxStackDepth()InterfaceImplementationGets the wasm stack size limitfreePages()InterfaceImplementationGets the number of free wasm pages a tx getspageGas()InterfaceImplementationGets the base cost of each additional wasm pagepageRamp()InterfaceImplementationGets the ramp that drives exponential memory costspageLimit()InterfaceImplementationGets the maximum initial number of pages a wasm may allocateminInitGas()InterfaceImplementationGets the minimum costs to invoke a programinitCostScalar()InterfaceImplementationGets the linear adjustment made to program init costsexpiryDays()InterfaceImplementationGets the number of days after which programs deactivatekeepaliveDays()InterfaceImplementationGets the age a program must be to perform a keepaliveblockCacheSize()InterfaceImplementationGets the number of extra programs ArbOS caches during a given block.activationGas()InterfaceImplementationGets the constant gas charge applied before each Stylus contract activation.\nEventSolidity interfaceGo implementationDescriptionProgramActivatedInterfaceImplementationEmitted when activating a WASM programProgramLifetimeExtendedInterfaceImplementationEmitted when extending the expiration date of a WASM program\nArbWasmCache​\nArbWasmCache (Interface | Implementation) provides helper methods for managing Stylus cache\nPrecompile address: 0x0000000000000000000000000000000000000072\n\nMethodSolidity interfaceGo implementationDescriptionisCacheManager(address manager)InterfaceImplementationSee if the user is a cache manager owner.allCacheManagers()InterfaceImplementationRetrieve all authorized address managers.cacheCodehash(bytes32 codehash)InterfaceImplementationDeprecated: replaced with CacheProgram.cacheProgram(address addr)InterfaceImplementationCaches all programs with a codehash equal to the given address. Caller must be a cache manager or chain owner.evictCodehash(bytes32 codehash)InterfaceImplementationEvicts all programs with the given codehash. Caller must be a cache manager or chain owner.codehashIsCached(bytes32 codehash)InterfaceImplementationGets whether a program is cached. Note that the program may be expired.\nEventSolidity interfaceGo implementationDescriptionUpdateProgramCacheInterfaceImplementationEmitted when caching a WASM programGeneral information of precompilesCommon precompilesOther precompilesPrecompiles referenceArbAddressTableArbAggregatorArbBLSArbDebugArbFunctionTableArbGasInfoArbInfoArbNativeTokenManagerArbosTestArbOwnerArbOwnerPublicArbRetryableTxArbStatisticsArbSysArbWasmArbWasmCache","tokens":8614,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261674700,"hash":"cf03b1abcc5b95fe8ed6d937918b6e0347373cde"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/1","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"Trustless Bitcoin Bridge Creation with Witness Encryption \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2022\n\n 1 / 26\n\n Feb 2022\n\n Apr 2024\n\n post by leohio on Feb 6, 2022\n\n leohio\n\n Lead Author: Leona Hioki\nCoauthor : 3966f482edb3843a7cdfb9ffa6840023\nTL;DR: Controlling bitcoin possession by a state condition of Ethereum in a cryptographic way. A trusted setup like Groth16’s Powers of Tau ceremony is required. No need for any node with liveness.\nIntroduction\nWe propose a trustless WBTC configuration that neither depends on a custodian nor an individual that provides excessive collateral. We achieve it relying solely on a cryptographic scheme called Witness Encryption (WE). The WE scheme enables us to encrypt a secret key of Bitcoin addresses holding the deposited bitcoins, while requiring witness of WBTC amortization on the Ethereum blockchain to decrypt the ciphertext. This feature guarantees that only users who possess valid witness can recover the secret key and withdraw the deposited bitcoins.\nBackground\nIt is not easy to transfer a bitcoin to the Ethereum blockchain because the Bitcoin blockchain and the Ethereum blockchain operate independently. However, there has been a bridging mechanism to make this possible, and the cryptographic asset that utilizes this mechanism is WBTC (Wrapped Bitcoin ( WBTC ) an ERC20 token backed 1:1 with Bitcoin, n.d.).\nWith WBTC, when a user sends bitcoins to a third party’s bitcoin address, s/he can mint the sending amount as WBTC on the Ethereum blockchain (i.e., increases the bitcoin balance). S/he can also send WBTC to other users on the Ethereum blockchain. When a user who holds WBTC redeems WBTC on the Ethereum blockchain (i.e., decreases the bitcoin balance), the third party will send it back to the user’s Bitcoin address. In the existing schemes of WBTC, the user needs either a custodian that manages the deposited bitcoins or an individual that provides excessive collateral beyond what they need in standard financial transactions. This is because, under the programmatic form of Bitcoin Script (Script Bitcoin Wiki, n.d.) used in the Bitcoin protocol, we have thought that it is impossible to mint WBTC using cryptography alone up until now. In other words, if the Bitcoin script had the same functionality as a smart contract on the Ethereum blockchain, it would be possible to design a custodianfree WBTC by building a smart contract with logic to verify the state of the Ethereum blockchain and send the deposited bitcoins according to that state. However, the current Bitcoin script can only support few cryptographic schemes such as verifying digital signatures, so no one has believed this is possible to achieve.\nApproach\nWe created a method that relies solely on cryptography using Witness Encryption (WE), one of the cryptographic schemes already introduced by the pioneers (Garg, Gentry, Sahai, & Waters, 2013), to realize WBTC without the need for an administrator such as a custodian or an individual with incentives. While in ordinary public-key cryptography schemes, a holder of a particular secret key can decrypt a ciphertext, in the WE scheme, s/he encrypts a message for an instance to a condition described as an NP relation, which is satisfied by inputs and witness in NP problems, and only the holder of that witness can decrypt the ciphertext (Garg et al., 2013) (Goldwasser, Kalai, Popa, Vaikuntanathan, & Zeldovich, 2013). In our proposed WBTC, the secret key is encrypted using the WE scheme, and only the user who holds the valid witness to amortize the WBTC on the Ethereum blockchain can decrypt the ciphertext when s/he provide it.\nwe_er_final_rep11000×563 24.6 KB\nIn the deposit process, a user records a public key of the Bitcoin deposit address (Bitcoin address to which a bitcoin holder sends his or her bitcoins in order to mint WBTC) in the smart contract for our program; then sends the user’s bitcoin to the address. The user generates proof of the deposit with a non-interactive zero-knowledge (NIZK) proof system. If and only if the proof passed the verification, the smart contract will mint the WBTC.\nIn the withdrawal process, a user first amortizes the WBTC with specifying the public key of the deposit address to be used. If the amortization process completes, the smart contracts issue an event log. Providing the above data along with the user’s digital signature, the user can recover the secret key of the deposit address from the ciphertext. The user finally sends the bitcoin in the deposit address to the user’s Bitcoin address.\nWhile the deposit address is generated as an N-of-N multi-signature address, our system eliminates the need of liveness of any third parties or custodians. Specifically, the security of deposited bitcoins can be maintained as far as at least one of the generator behaves honestly only during address generation. This is because a malicious generator of the multi-signature address needs to collude with all of the generators to steal the fund, but a user holding a valid witness can decypt all of the secret key.\nIn the above process, we may identify transactions for all deposits and withdrawals with other transactions on the Bitcoin blockchain, since the deposit address is fixed. Using a random public key, we can randomize the deposited address and improve its anonymity. A user in the deposit process additionally generates a random secret/public keys and records the public key in the smart contract. The user then sends the bitcoin to a stealth address derived from the random secret key. A user in the withdrawal process recovers the secret key of the stealth address from the decrypted secret key and the random public key, so that the user can withdraw the bitcoin in the stealth address. A third party that knows neither the random secret key nor the decrypted secret key cannot derive the stealth address under the decisional Diffie–Hellman (DDH) assumption.\nDetail\nDetail-1: Witness Encryption\nA WE scheme is defined for an NP language L (with corresponding witness relation R), and consists of the encyption and decryption algorithms (Garg et al., 2013):\nWE.Enc(1λ,x,m): It takes a security parameter λ, an instance x, and a message m ∈ {0,1}. It returns a ciphertext ct.\nWE.Dec(ct,w): It takes a ciphertext ct and a witness w. It returns a message m iff R(x,w) holds.\nTo decrypt a ciphertext ct, a valid witness w for the instance x is necessary. Therefore, no one can decrypt the ciphertext encrypted for the x \\not\\in \\mathbb{L}𝑥 ∉𝕃 (i.e. there is no witness w such that R(x,w) holds). This property is defined as ”soundness security” in (Garg et al., 2013).\n(Goldwasser et al., 2013) introduced a more robust definition of security: ”extractable security”. Informally, this definition guarantees that an adversary must obtain a valid witness w from x, when the adversary can recover the message from the ciphertext for an instance x ∈ \\mathbb{L}𝕃. The WE scheme used in our program should satisfy it since we encrypt any secret keys for the instances x ∈ \\mathbb{L}𝕃.\nIn the following description of our protocol, we assume that the WE scheme is defined for the subset sum language L, which is one of the NP-complete problems. Since the circuit satisfiability problem (circuit-SAT) can be reduced to the subset sum problem, a boolean circuit C can represent the decryption condition (Bartusek et al., 2020). A message is encrypted for an instance xC depending on the circuit C. The ciphertext is decrypted if the witness w satisfies C(w) = 1.\nIn Appendix, we introduce a candidate of the WE scheme that we plan to adopt as the underlying WE scheme for the first implementation of our program.\nTo the best of our knowledge, the most practical WE scheme is ADP-based WE proposed in (Bartusek et al., 2020). While there is no security reduction to the standard assumptions for this scheme, it only uses the linear algebra, e.g. random matrix sampling, matrix multiplication, and a determinant. We review its construction in accordance with the description of (Bartusek et al., 2020), and analyze its efficiency in Appendix.\nDetail-2: Deposit Bitcoin\nwe_er_final_rep21000×563 27.3 KB\nBefore sending bitcoins to a deposit address, a user records the public key of the Bitcoin deposit address that s/he wishes to use in the smart contract of our program. At the same time, the user also records the user’s EOA address. Its process is necessary to prevent two users from sending bitcoins to a single Bitcoin deposit address simultaneously: s/he needs to use the Bitcoin deposit address for a single deposit and withdrawal, because its secret key has the property that the user can send all bitcoins associated with their secret key.\nThe fact that the user sent bitcoin to a deposit address on the Bitcoin blockchain is proved by non-interactive zero-knowledge (NIZK) proof system on the Ethereum blockchain (e.g., Groth16 (Groth, 2016), Plonk (Gabizon, Williamson, & Ciobotaru, 2019), ZK-STARK (Ben-Sasson, Bentov, Horesh, & Riabzev, 2018)). After sending bitcoins to the deposit address, the user generates a proof of deposit and records it in a smart contract in our program. Only if that proof can pass the verification process described in the smart contract will the WBTC be minted.\nWe implement functionality of a light client in the Bitcoin network as part of the circuit used by the NIZK proof system. However, the circuit cannot directly perform the verification of the longest chain that requires communication with other nodes (verifying which blockchain is the longest at the moment). Instead, our circuit verifies it based on the difficulty value: as a given blockchain, it accepts only those whose cumulative difficulty is greater than the minimum cumulative difficulty value fixed or adjusted in the smart contract.\nIf this system does not exist, i.e., only the number of succeeding blocks is verified, an attacker can generate false proofs that pass verification without recording the deposit transaction in the longest chain, as follows:\n\nCreate a branch of the longest chain (we will call this branch the ”private branch”).\n\nSend the attacker’s bitcoins to the deposit address on the private branch.\n\nGenerate a new block containing the deposit transaction with taking a sufficiently long time.\n\nGenerate as many blocks as necessary to follow the above blocks. However, the difficulty adjustment algorithm in the Bitcoin protocol allows this process to be completed quickly by lowering the next difficulty, if the attacker intentionally declares a longer time than it took.\n\nFeed the block header and deposit transaction in the private branch to our circuit to generate a proof of deposit.\n\nFeed that proof to our program’s smart contract. This proof should be able to pass verification so that we can mint the WBTC.\n\nSuppose, when the attacker includes a delayed timestamp in the block header to reduce the next difficulty, the cumulative difficulty value becomes smaller than the specified minimum value. Therefore, we can mitigate this attack by verifying the cumulative difficulty value.\nTo summarize the above discussion, bitcoin deposits can be realized securely by 1 to 6 as follows:\n\nThe format of each block header is correct (e.g., the nonce of each block header satisfies the PoW constraints).\n\nExcept for the last block header, the block hash of each block header is referenced as the previous block hash in the block header that follows it.\n\nThe first block header is the one that follows the finalized block header. However, the finalized block header is determined during address generation.\n\nThe cumulative difficulty value is greater than the given minimum cumulative difficulty value in the last block header.\n\nThe transaction format is correct, and its hash value is contained in the Merkle Root in the block header at the specified block height.\n\nThe recipient’s address in the transaction is equal to the deposit address, and the transfer amount is equivalent to the value fixed in the system.\n\nDetail-3: Withdraw Bitcoin\nBefore all, special thanks to Barry Whitehat(https://ethresear.ch/u/barrywhitehat) for his insight about preventing an attack from virtual malicious validators on Ethereum2.0.\nwe_er_final_rep31000×563 24.9 KB\nTo send bitcoins from a Bitcoin deposit address, the user specifies the public key of the deposit address to be used and amortizes the same amount of WBTC on the Ethereum blockchain. To verify the result of this process, we use an event log, a record that a smart contract can publish depending on its execution. The smart contract in our program will issue an event log containing the specified public key and the user’s EOA address only if its amortization process completes without any problems.\nThe user then waits for the block containing the event log to be finalized in the Ethereum 2.0 blockchain. (We assume that the Ethereum 2.0 blockchain will be our program’s primary service source when it goes live.)\nAfter finalizing that block, the user records the latest block of the Ethereum 2.0 blockchain into the Bitcoin blockchain. The Bitcoin script specification allows the ”OP_RETURN script” (Script Bitcoin Wiki, n.d.) to write arbitrary data into the transaction. Using this feature, the user records a block of data as a single bitcoin transaction. We call this transaction ”a commitment transaction”. The reason for recording the block is to prevent block cloaking attacks (so called Block Withholding Attack), in which a large group of colluding validators confirms the invalid blocks forked from the current honest chain and hides them. Those dishonest validators can escape the penalty by hiding the block, even though they are worse enough to be punished by a slashing mechanism. For this reason, our program’s system forces us to publish the same blocks used in the condition on the Bitcoin blockchain.\nFinally, the user generates a digital signature using a secret key that corresponds to the user’s EOA address. The decryption condition of the WE scheme of this program requires a digital signature tied to the EOA address contained in the event log, so it guarantees that no other user can decrypt the ciphertext. Using the Bitcoin block header and Ethereum 2.0 block header (= Bitcoin/Ethereum 2.0 block header), the latest Ethereum 2.0 block, commitment transaction, event log, and the user’s digital signature as witness, the user can withdraw bitcoin securely by allowing the ciphertext to be decrypted\niff the user can satisfy the following conditions.\n\nThe format of each Bitcoin/Ethereum 2.0 block header is correct.\n\nThe block hash of each Bitcoin/Ethereum 2.0 block header is the previous block hash in the block header that follows it, except for the last one.\n\nThe first Bitcoin/Ethereum 2.0 block header follows the respective finalized block header. (WE encryption fixes the finalized block header.)\n\nThe cumulative difficulty value is greater than the minimum cumulative difficulty value in the last Bitcoin block header. (WE encryption fixes the minimum cumulative difficulty value.)\n\nThe latest Ethereum 2.0 block has been confirmed with a digital signature generated by a good percentage of validators.\n\nThe data in the block corresponding to the last Ethereum 2.0 block header is recorded in a commitment transaction, which is included in the Bitcoin block at the specified block height.\n\nThe event log is contained in the Ethereum 2.0 block at the specified block height.\n\nThe digital signature is generated by the secret key associated with the EOA address in the event log.\n\nAfter recovering the secret key corresponding to the specified public key through this process, the user generates a digital signature and sends the Bitcoin to the user’s Bitcoin address.\nDetail-4: Generate Bitcoin deposit address\nThe Bitcoin deposit address generator creates a pair of a new secret key, a public key, and a Bitcoin deposit address. These empty Bitcoin deposit addresses will not be credited with bitcoins during the pre-launch phase of our program but will be the deposit addresses after launching the service. The generator simultaneously encrypts these secret keys with WE and publishes the addresses and ciphertext.\nAs already mentioned, no one should expose the embedded secret key, but the generator will inevitably know the secret key. In this respect, this process requires trusting the generator. However, this trust model can be replaced to N-of-N multiple signature addresses, which can minimize the risk of a single generator.\nIn our model, instead of a Bitcoin deposit address generated by a single generator, an N-of-N multi-signature address associated with a public key generated by N different generators is used as the Bitcoin deposit address. Multi-Party Computation (MPC) among N parties generates the multi-signature address. Specifically, each generator generates a new secret key and a ciphertext for its WE scheme. Then, N-of-N multi-signature addresses are obtained from all of their corresponding public keys. A digital signature using all of the generated secret keys is required to send bitcoins from that multi-signature address. Therefore, no generator can send bitcoins illegally, except when all the generators collude.\nHowever, this N-of-N multi-signature address itself is a standard method, and simply using it would require the N people in question to gather together and perform some action each time bitcoin is withdrawn, which is unrealistic in terms of operation. Therefore, while based on N-of-N multiple signature addresses, there should be no need for the generators to gather and perform some action after setup, and there should be no risk of users being unable to withdraw bitcoins. This is achievable with the following method.\nThe generator of each component of the N-of-N multi-signature address should first generate proof that each ciphertext was correctly constructed with the WE scheme using the NIZK proof system. If the proofs of all generators are correct, the N-of-N multiple signature address should be recorded in the smart contract. Then, due to the nature of the WE scheme, only users with legitimate witness will recover all secret keys from the ciphertext and generate digital signatures, which will allow them to withdraw the deposited bitcoins at any time.\nDetail-5: Randomization for the deposit and withdrawal\nUsing the following technique can implement a mechanism to improve the system’s privacy in this program.\nThe process implementation alone in the previous sections has the drawback: we may identify transactions for all deposits and withdrawals with other transactions on the Bitcoin blockchain. However, we can let the deposit address random by adding one random public key, and the randomized address can be made indistinguishable from other addresses for any third party.\nThe specific procedure is as follows. (In the following description, Fp denotes a finite field of prime order p. Let G be a group of prime order p, and let G ∈ \\mathbb{G}𝔾 be its generator.)\nThe deposit process is randomized by modifying it as follows.\n\nThe user generates additional random secret key\nr ∈ \\mathbb{F}p𝔽𝑝 and public key rG ∈ \\mathbb{G}𝔾 .\n\nBefore sending bitcoins, the user records rG in the smart contract, along with the user’s EOA address and the specified public key of the fixed Bitcoin deposit address pkD ∈ \\mathbb{G}𝔾\n\nThe user generates a unique stealth address (a random address that can only be obtained between two parties and cannot be distinguished from any other address by any other third party) from pkD and r. The public key corresponding to the stealth address is computed as pkD + Hash (r ·pkD )G ∈ \\mathbb{G}𝔾 . The user then transfers bitcoins to the stealth address.\n\nProof of deposit in the NIZK proof system provides additional proof that the recipient’s Bitcoin address is a stealth address correctly calculated from pkD and r. It also guarantees that rG is equivalent to the recorded random public key.\n\nSimilarly, the withdrawal process is randomized by modifying it as follows.\n\nObtain rG associated with the specified pkD in the WBTC amortization process.\n\nRecover the secret key of the fixed public key (fixed secret key) skD ∈ \\mathbb{F}p𝔽𝑝 from the ciphertext, and then recover the secret key of the stealth address from skD and rG by computing skD + Hash (r · pkD ) ∈ \\mathbb{F}p𝔽𝑝\n\nGenerate a digital signature using the secret key of the stealth address, and send bitcoin from the stealth address.\n\nNote that we must recover skD first to recover the secret key of the stealth address (see above 2.) because pkD and r in our program generate the public key of the stealth address, while skD and a rG can obtain the secret key. This property guarantees that the user who generates the stealth address in the deposit process will not get the secret key for the stealth address.\nConclusion\nIn this post, we proposed the WBTC configuration using Witness Encryption. This eliminates the need for trusted custodians or individuals to cooperate in guaranteeing the value through overcollateralization. Specifically, the security of the deposited bitcoins is maintained if at least one of the participants in the MPC behaves honestly only during address generation. In addition, the anonymity of the deposited address can be improved by randomizing it with a random public key.\nAppendix\nNotions\nLet \\mathbb{N}ℕ be a positive integer, \\mathbb{R}ℝ be a real number, and \\mathbb{F}_p𝔽𝑝 be a finite field of prime order p𝑝. For n \\in \\mathbb{N}𝑛 ∈ℕ, let [n][𝑛] denote the set \\{1,\\dots,n\\}{1,…,𝑛}. x \\xleftarrow{U} X𝑥𝑈⟵𝑋 means to extract a random number x𝑥 uniformly from X𝑋. Let \\mathbb{G}𝔾 be a group of prime order p𝑝, and let G \\in \\mathbb{G}𝐺 ∈𝔾 be its generator.\nThe vector \\boldsymbol{a}𝒂 is \\boldsymbol{a}\\in \\mathbb{F}_p^n𝒂 ∈𝔽𝑛𝑝 in bold lowercase letters and \\boldsymbol{A}𝑨 is \\boldsymbol{A}\\in \\mathbb{F}_p^{n \\times n}𝑨 ∈𝔽𝑛×𝑛𝑝 in bold uppercase letters. The inner product of \\boldsymbol{A}𝑨 and \\boldsymbol{B}𝑩 is denoted by <\\boldsymbol{A},\\boldsymbol{B}><𝑨,𝑩 >. The det(\\boldsymbol{A})𝑑𝑒𝑡(𝑨) denotes the determinant of matrix \\boldsymbol{A}𝑨.\nWe use \\lambda𝜆 as a security parameter. The function negl(\\lambda): \\mathbb{N} \\rightarrow \\mathbb{R}𝑛𝑒𝑔𝑙(𝜆) :ℕ →ℝ exploits the property that a function negl(\\lambda)𝑛𝑒𝑔𝑙(𝜆) is said to be negligible if for any constant c>0𝑐 >0 there exists n \\in \\mathbb{N}𝑛 ∈ℕ such that negl(\\lambda) < \\lambda^{-c}𝑛𝑒𝑔𝑙(𝜆) <𝜆−𝑐 for all \\lambda > n𝜆 >𝑛.\nADP-based Witness Encryption\nWe review the ADP-based witness encryption scheme proposed in (Bartusek, “Affine determinant programs”). Note that all of the descriptions in this section are described in (Bartusek, “Affine determinant programs”).\nAs described in section 3 in (Bartusek, “Affine determinant programs”), an affine determinant program (ADP) is denoted by an affine function \\boldsymbol{M}𝑴, which consists of (n+1)(𝑛 +1)-tuple of regular matrices whose width is k𝑘:\nM := (A, \\boldsymbol{B_1},\\dots,\\mathbb{B_n}) \\in \\mathbb{F}_p^{k \\times k} \\times \\dots \\times \\mathbb{F}_p^{k \\times k}𝑀 :=(𝐴,𝑩𝟏,…,𝔹𝕟) ∈𝔽𝑘×𝑘𝑝 ×⋯ ×𝔽𝑘×𝑘𝑝\nThe affine function \\boldsymbol{M}: \\{0,1\\}^n \\rightarrow F_p^{k \\times k}𝑴 :{0,1}𝑛 →𝐹𝑘×𝑘𝑝 takes an n-length binary input \\mathbb{x} \\in \\{0,1\\}^n𝕩 ∈{0,1}𝑛 and evaluate it by the following matrix calculation.\n\\boldsymbol{M}(\\boldsymbol{x}) := \\boldsymbol{A}+\\sum_{i \\in [n]} x_i\\boldsymbol{B_i}.𝑴(𝒙) :=𝑨 +∑𝑖∈[𝑛]𝑥𝑖𝑩𝒊.\nThe ADP includes an evaluation function that takes the binary input \\mathbb{x}𝕩, and outputs a single bit 0/10/1 depending on whether det(\\boldsymbol{M}(\\boldsymbol{x}))𝑑𝑒𝑡(𝑴(𝒙)) is zero. In other words, its evaluation result is decided if the \\boldsymbol{M}(\\boldsymbol{x})𝑴(𝒙) is full-rank matrix or not.\nThe ADP can represent an instance of the subset-sum language L𝐿, which consists of (\\boldsymbol{h},\\ell) \\in \\mathbb{F}_p^{n} \\times \\mathbb{F}_p(𝒉,ℓ) ∈𝔽𝑛𝑝 ×𝔽𝑝. If and only if (\\boldsymbol{h},\\ell) \\in L(𝒉,ℓ) ∈𝐿, there is a witness \\mathbb{w} \\in \\{0,1\\}^n𝕨 ∈{0,1}𝑛 such that <\\boldsymbol{h},\\boldsymbol{w}>=\\ell<𝒉,𝒘 >=ℓ. Following the definition in section 5.1 in (Bartusek, “Affine determinant programs”), the affine function \\boldsymbol{M}_{\\boldsymbol{h},\\ell}𝑴𝒉,ℓ for (\\boldsymbol{h},\\ell)(𝒉,ℓ) is generated as below:\n\nSample \\boldsymbol{R} \\xleftarrow{U} \\mathbb{F}_p^{k \\times k}𝑹𝑈⟵𝔽𝑘×𝑘𝑝.\nSet \\boldsymbol{A}:=-\\ell \\boldsymbol{R}𝑨 := −ℓ𝑹.\nFor each i \\in [n]𝑖 ∈[𝑛], set \\boldsymbol{B_i}:=h_i\\boldsymbol{R}𝑩𝒊 :=ℎ𝑖𝑹.\nOutput \\boldsymbol{M}_{\\boldsymbol{h},\\ell}=(\\boldsymbol{A},\\boldsymbol{B}_1,\\dots,\\boldsymbol{B}_n)𝑴𝒉,ℓ =(𝑨,𝑩1,…,𝑩𝑛).\n\nIf the witness \\boldsymbol{w}𝒘 satisfies <\\boldsymbol{h},\\boldsymbol{w}>=\\ell<𝒉,𝒘 >=ℓ, the determinant of \\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w})𝑴𝒉,ℓ(𝒘) should be zero.\ndet(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w})) = det((-\\ell+\\sum_{i \\in [n]} w_ih_i)\\boldsymbol{R}) = 0𝑑𝑒𝑡(𝑴𝒉,ℓ(𝒘)) =𝑑𝑒𝑡(( −ℓ +∑𝑖∈[𝑛]𝑤𝑖ℎ𝑖)𝑹) =0\nAs the random matrix \\boldsymbol{R}𝑹 is full-rank with high probability, the det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell}(\\boldsymbol{w'}))𝑑𝑒𝑡(𝑴𝒉,ℓ(𝒘′)) for the invalid witness \\boldsymbol{w'}𝒘′ is non-zero. Hence, such ADP can decide whether the provided witness is valid for the instance of the subset-sum language.\nTo embed a bit message b \\in \\{0,1\\}𝑏 ∈{0,1} in the ADP, the encryptor samples a random matrix \\boldsymbol{S} \\xleftarrow{U} \\mathbb{F}_p^{k \\times k}𝑺𝑈⟵𝔽𝑘×𝑘𝑝, and adds b\\boldsymbol{S}𝑏𝑺 to \\boldsymbol{A}𝑨 in the tuple of \\boldsymbol{M}_{\\boldsymbol{h},\\ell}𝑴𝒉,ℓ.\n \\boldsymbol{M}_{\\boldsymbol{h},\\ell,b} := \\boldsymbol{M}_{\\boldsymbol{h},\\ell} + (b\\boldsymbol{S},0,\\dots,0)𝑴𝒉,ℓ,𝑏 :=𝑴𝒉,ℓ +(𝑏𝑺,0,…,0)\nThe decryptor who holds the valid witness \\boldsymbol{w}𝒘 can decrypt b𝑏 by deciding whether det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{w}))𝑑𝑒𝑡(𝑴𝒉,ℓ,𝑏(𝒘)) is zero or non-zero. (If and only if b=1𝑏 =1, det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{w})) \\neq 0𝑑𝑒𝑡(𝑴𝒉,ℓ,𝑏(𝒘)) ≠0 since the matrix \\boldsymbol{S}𝑺 is full-rank with high probability.)\nThe above scheme is, however, insecure because an adversary can input an non-binary input \\boldsymbol{x} \\in \\mathbb{F}_p^n𝒙 ∈𝔽𝑛𝑝 to the ADP that satisfies <\\boldsymbol{h},\\boldsymbol{x}>=\\ell<𝒉,𝒙 >=ℓ. Such input is easily calculated by solving the simultaneous linear equations.\nTo prevent the non-binary input, \\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}𝑴𝒉,ℓ,𝑏 is noised by an “All-Accept ADP (Bartusek, “Affine determinant programs”)” \\boldsymbol{M}_{AA}𝑴𝐴𝐴, which have the two properties (following the definition in section 5.1 in (Bartusek, “Affine determinant programs”)):\n\n(Correctness) For all \\boldsymbol{x} \\in \\{0,1\\}^n(𝐶𝑜𝑟𝑟𝑒𝑐𝑡𝑛𝑒𝑠𝑠)𝐹𝑜𝑟𝑎𝑙𝑙𝒙 ∈{0,1}𝑛, Pr[det(\\boldsymbol{M}_{AA}(\\boldsymbol{x}))=0]=1𝑃𝑟[𝑑𝑒𝑡(𝑴𝐴𝐴(𝒙)) =0] =1.\n\n(Rejection of Invalid Inputs) For all non-binary \\boldsymbol{x} \\in \\mathbb{F}_p^n \\setminus \\{0,1\\}^n𝒙 ∈𝔽𝑛𝑝 ∖{0,1}𝑛, \\ Pr[det(\\boldsymbol{M}_{AA}(\\boldsymbol{x}))=0]=negl(\\lambda)𝑃𝑟[𝑑𝑒𝑡(𝑴𝐴𝐴(𝒙)) =0] =𝑛𝑒𝑔𝑙(𝜆).\n\nUsing the All-Accept ADP, the ciphertext is built as the following ADP, which is mentioned as a generic candidate in section 5.2 in (Bartusek, “Affine determinant programs”).\n$\n\\boldsymbol{M}{\\boldsymbol{h},\\ell,b} :=\n\\boldsymbol{M}{AA} + \\boldsymbol{M}_{\\boldsymbol{h},\\ell} + (b\\boldsymbol{S},0,\\dots,0)\n$\nFor any non-binary input \\boldsymbol{x} \\in \\mathbb{F}_p^n \\setminus \\{0,1\\}^n𝒙 ∈𝔽𝑛𝑝 ∖{0,1}𝑛, det(\\boldsymbol{M}_{\\boldsymbol{h},\\ell,b}(\\boldsymbol{x})) \\neq 0𝑑𝑒𝑡(𝑴𝒉,ℓ,𝑏(𝒙)) ≠0 holds since \\boldsymbol{M}_{AA}(\\boldsymbol{x})𝑴𝐴𝐴(𝒙) is full-rank except with negligible probability. The determinant, therefore, outputs 00 iff b=0𝑏 =0 and a valid witness \\boldsymbol{w} \\in \\{0,1\\}^n𝒘 ∈{0,1}𝑛 is provided.\nIn this way, the ADP is helpful to construct the WE scheme for the subset sum language as described in (Bartusek, “Affine determinant programs”). Note that the above explanation only covers the generic candidate. Strictly speaking, the ADP-based WE scheme is constructed for a \"vector subset sum language in (Bartusek, “Affine determinant programs”), which is the generalization of the subset sum language. In the analysis of the efficiency described in Appendix, we assume the concrete candidate defined in section 5.2 in (Bartusek, “Affine determinant programs”).\nAnalysis of the ADP-based Witness Encryption\nBased on the concrete candidate in section 5.2 of (Bartusek, “Affine determinant programs”), we analyze the size of the ciphertext and the complexity of the encryption/decryption. In the following description, m,k𝑚,𝑘 denotes the number of variables and clauses in the 3-SAT formula respectively, n𝑛 denotes the number of wights in the instance of the subset sum language, p𝑝 denotes the order chosen in the WE.Enc algorithm.\nThe size of the ciphertext grows with \\mathcal{O}([\\log_2 p]n^{3+2\\epsilon})O([log2⁡𝑝]𝑛3+2𝜖). The ciphertext \\boldsymbol{M}𝑴 consists of 2n+12𝑛 +1 matrices over \\mathbb{F}_p𝔽𝑝, and their each dimension is (2n^{1+\\epsilon}+1) \\times (2n^{1+\\epsilon}+1)(2𝑛1+𝜖 +1) ×(2𝑛1+𝜖 +1). The size is, therefore, [\\log_2 p] \\times (2n+1) \\times (2n^{1+\\epsilon}+1)^2=[\\log_2 p](8n^{3+2\\epsilon}+4n^{2+2\\epsilon}+8n^{2+\\epsilon}+4n^{1+\\epsilon}+2n+1)[log2⁡𝑝] ×(2𝑛 +1) ×(2𝑛1+𝜖 +1)2 =[log2⁡𝑝](8𝑛3+2𝜖 +4𝑛2+2𝜖 +8𝑛2+𝜖 +4𝑛1+𝜖 +2𝑛 +1) bits.\nWith m𝑚 and k𝑘, the growth of the size is also represented as \\mathcal{O}((m+k)^{4+2\\epsilon})O((𝑚 +𝑘)4+2𝜖). It is well known that the 3-SAT formula with m𝑚 variables and k𝑘 clauses is reduced to the instance of the subset sum language with 2m+2k2𝑚 +2𝑘 weights (Eva Tardos, “Reduction from 3 SAT to MAX CUT”). Replacing n𝑛 with 2m+2k2𝑚 +2𝑘, the number of elements over \\mathbb{F}_p𝔽𝑝 in the ciphertext is 2^{6+2\\epsilon}(m+k)^{3+2\\epsilon}+(2^{4+2\\epsilon}+2^{5+\\epsilon})(m+k)^{2+2\\epsilon}+2^{3+\\epsilon}(m+k)^{1+\\epsilon}+2^{2}(m+k)+126+2𝜖(𝑚 +𝑘)3+2𝜖 +(24+2𝜖 +25+𝜖)(𝑚 +𝑘)2+2𝜖 +23+𝜖(𝑚 +𝑘)1+𝜖 +22(𝑚 +𝑘) +1.\nEach weight of the instance requires (m+k)[\\log_2 10](𝑚 +𝑘)[log2⁡10] bits (Eva Tardos, “Reduction from 3 SAT to MAX CUT”), so that the minimum size of p𝑝 satisfying p>\\max_{\\boldsymbol{x}\\in \\{0,1\\}^{2m+2k}}|\\sum_i x_i h_i|𝑝 >max𝒙∈{0,1}2𝑚+2𝑘|∑𝑖𝑥𝑖ℎ𝑖| is 1+[\\log_2(m+k)]+(m+k)[\\log_2 10]1 +[log2⁡(𝑚 +𝑘)] +(𝑚 +𝑘)[log2⁡10] bits. Hence, the size of the ciphertext is \\{(m+k)[\\log_2 10]+[\\log_2(m+k)]+1\\}\\{2^{6+2\\epsilon}(m+k)^{3+2\\epsilon}+(2^{4+2\\epsilon}+2^{5+\\epsilon})(m+k)^{2+2\\epsilon}+2^{3+\\epsilon}(m+k)^{1+\\epsilon}+2^{2}(m+k)+1\\}{(𝑚 +𝑘)[log2⁡10] +[log2⁡(𝑚 +𝑘)] +1}{26+2𝜖(𝑚 +𝑘)3+2𝜖 +(24+2𝜖 +25+𝜖)(𝑚 +𝑘)2+2𝜖 +23+𝜖(𝑚 +𝑘)1+𝜖 +22(𝑚 +𝑘) +1} bits, whose order is \\mathcal{O}((m+k)^{4+2\\epsilon})O((𝑚 +𝑘)4+2𝜖).\nThe WE.Enc algorithm includes four types of computations whose complexities depend on n𝑛, that is, random sampling over \\mathbb{F}_p𝔽𝑝, matrix addition, scalar multiplication, and matrix multiplication. The number of sampled elements in \\mathbb{F}_p𝔽𝑝 is\n4\\times 2n(2n^{1+\\epsilon}+1)n^{\\epsilon}+4n^2+(n+2)(2n^{1+\\epsilon}+1)^2=4n^{3+2\\epsilon}+24n^{2+2\\epsilon}+4n^{2+\\epsilon}+4n^2+16n^{1+\\epsilon}+n+24 ×2𝑛(2𝑛1+𝜖 +1)𝑛𝜖 +4𝑛2 +(𝑛 +2)(2𝑛1+𝜖 +1)2 =4𝑛3+2𝜖 +24𝑛2+2𝜖 +4𝑛2+𝜖 +4𝑛2 +16𝑛1+𝜖 +𝑛 +2. The addition between (2n^{1+\\epsilon}+1) \\times (2n^{1+\\epsilon}+1)(2𝑛1+𝜖 +1) ×(2𝑛1+𝜖 +1) matrices is computed 4n^2+8n+14𝑛2 +8𝑛 +1 times in total. The matrices are multiplied by scalars 4n^2+n+14𝑛2 +𝑛 +1 times if b=0𝑏 =0, and 4n^2+n+24𝑛2 +𝑛 +2 times if b=1𝑏 =1. The number of times of the multiplication between (2n^{1+\\epsilon}+1) \\times n^{\\epsilon}(2𝑛1+𝜖 +1) ×𝑛𝜖 matrices is 6n6𝑛.\nThe WE.Dec algorithm consists of the computation of the affine function \\boldsymbol{M}𝑴, and its determinant calculation. By the definition of the ADP, the former requires n𝑛-times matrix additions and n𝑛-times scalar multiplications.\nReferences\n[1] Bartusek, J., Ishai, Y., Jain, A., Ma, F., Sahai, A., & Zhandry, M. (2020). Affine determinant programs: A framework for obfuscation and witness encryption. In 11th innovations in theoretical computer science conference (itcs 2020).\n[2] Gavin Uberti, Kevin Luo, Oliver Cheng, Wittmann Goh December, Building Usable Witness Encryption 10, 2021\n[3] Ben-Sasson, E., Bentov, I., Horesh, Y., & Riabzev, M. (2018). Scalable, trans-parent, and post-quantum secure computational integrity. IACR Cryptol. ePrint Arch., 2018, 46.\n[4] Gabizon, A., Williamson, Z. J., & Ciobotaru, O. (2019). Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge. IACR Cryptol. ePrint Arch., 2019, 953.\n[5] Garg, S., Gentry, C., Sahai, A., & Waters, B. (2013). Witness encryption and its applications. In Proceedings of the forty-fifth annual acm symposium on theory of computing (pp. 467–476).\n[6] Goldwasser, S., Kalai, Y. T., Popa, R. A., Vaikuntanathan, V., & Zeldovich, N. (2013). How to run turing machines on encrypted data. In Annual cryptology conference (pp. 536–553).\n[7] Groth, J. (2016). On the size of pairing-based non-interactive arguments. In Annual international conference on the theory and applications of cryptographic techniques (pp. 305–326).\n[8] Script bitcoin wiki. (n.d.). Script - Bitcoin Wiki. ((Accessed on 09/10/2021))\n[9] Tardos, E. (n.d.). Reduction from 3 sat to max cut.\nhttps://www.cs.cornell.edu/courses/cs4820/2015sp/notes/reduction-subsetsum.pdf. ((Accessed on 10/22/2021))\n[10] Wrapped bitcoin ( wbtc ) an erc20 token backed 1:1 with bitcoin.* (n.d.).\nhttps://wbtc.network/. ((Accessed on 11/17/2021))\n\n Practical, Trustless, Bitcoin Bridge\n\n Octopus Contract and its Applications\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n post by JustinDrake on Feb 7, 2022\n\n JustinDrake\n\n Oh wow, very cool that obfuscation is not required \nTLDR: Using an MPC secure with just one honest participant, generate a mint Bitcoin address with the secret key witness encrypted under a proof that the wrapped token was burned.\n\n post by leohio on Feb 8, 2022\n\n leohio\n\n Thank you for the better TLDR than mine.\n\nTR;DR of the mechanism:\nOnly the person who can make a zkp proof of WBTC burn, or in other words, the person who burned WBTC, can know all N multisig private keys and unlock the bitcoin using special decryption. On the other hand, a malicious person has to collude with all the other N people who set the private key, so if there is even one honest person among the N people, they cannot steal it. It’s 99% attack tolerant because they cannot kill the liveness either.\n\n post by wdai on Feb 9, 2022\n\n wdai\n\n This is a fascinating application of witness encryption!\nTo check my understanding, as this part of the bridge is not too explicitly described: the N different deposit address generators (let’s call them bridge managers, since they together do control the funds deposited) would need to manage the total deposited funds to make sure they give out WE ciphertexts to secret keys that holds specific amount of Bitcoins, correct? For example, if there is a single deposit of 2 BTC and then two later withdrawal of 1 BTC each. The bridge managers (generators) need to first split the 2 BTC in the Bitcoin UTXO to two UTXOs holding 1 BTC each.\nOne remark regarding N-of-N multi-signature: since Bitcoin taproot upgrade and the support for Schnorr signatures, the coalition of N “generators” can actually support any threshold T, not just N-of-N–each manager (generator) can release via WE their Shamir-secret share of the actual secret key holding the coins.\nAnd if my above understanding is correct, then one should investigate holistically the differences between releasing secret keys (or shares) via WE and simply providing threshold signatures in the withdraw. To recall briefly the threshold signature based bridge: Deposit works similarly to what is sketched here. For each withdraw: the N bridge managers would independently verify the validity of a withdraw claim (proof of burn of WBTC and BTC withdraw address) and conduct a threshold signing session to transfer the BTC out to the withdraw address (fund splitting can be done at this step).\nSome first remarks regarding the differences (again, if my understanding of your system is correct):\n\nWE solution does not require interaction between the bridge managers (generators / key holders)\nThreshold signing does not rely on additional hardness assumptions that WE require and is more widely-studied (e.g. DFINITY is close to deploying threshold ECDSA on their mainnet. Threshold Schnorr is arguably simpler, e.g.this paper from 2001.)\nThe actual trust assumption on the bridge managers, for both liveness and security, on the N bridge managers could be the same between the two solutions, in that one could select any threshold T.\n\n post by Killari on Feb 11, 2022\n\n Killari\n\n Sounds super interesting!\nI don’t really understand how can you recover the private key as a proof of burn of WTC? Is there some kind of light client in question that you produce a proof that there is enough PoW on top of the transaction you did?\n\n post by leohio on Feb 11, 2022\n\n leohio\n\n I’m glad to have you interested in this.\n\nThis is the exact part Witness Encryption is in charge of.\nCipher texts of Witness Encryption can be decrypted when the set circuit is satisfied.\nWe set a zkp circuit verifying that WBTC token is burned on Ethereum Layer1 by a withdrawer, as a circuit of Witness Encryption.\nThe recent Witness Encryption is getting realistic rapidly.\nADP\nExact Cover\n\nThe proof of difficulty and the proof of rightness on Ethereum PoS can be also verified by zkp circuits.\nThere no need of light clients to verify the bridge, this is why this is described like this.\n\nAlso, to complete the proof of rightness on Ethereum PoS, the proof of publishment of Ethereum PoS activity is on the Bitcoin blockchain OP_RETURN and included in the input of the zkp circuit. This prevents the colluded PoS validators from forking the chain privately to fake the WBTC burning on it.\n\n post by leohio on Feb 11, 2022\n\n leohio\n\n I am fed back the concern that the circuitry of the WE may become inconsistent during a hard fork, making decryption impossible, but this is solvable and something we did not mention in this paper for simplicity.\nIn a simple construction, we consider the block header as a target for signature by PoS validators, but what we really want the circuit to validate is the irreversible inclusion of the states into the Merkle Root. The circuit should be fine as long as this is satisfied.\nIf we hard fork to a Layer1 configuration that does not have irreversible inclusion, that would put Layer1 in danger.\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for the feedback with the information on the many protocols.\nI think the priority is answering this part.\n\nThe difference is simply here:\nIf the threshold is T of N of the multi-sig,\nSafety Byzantine fault tolerance of multi-sig with witness encryption: N-1 / N (99% tolerance)\nSafety Byzantine fault tolerance of multi-sig with Shnorr threshold signature: T / N\nLiveness Byzantine fault tolerance of multi-sig with witness encryption: N / N (No one can stop it)\nLiveness Byzantine fault tolerance of multi-sig with Shnorr threshold signature: N-T / N (If N-T+1 nodes go offline, the system stops)\nThe trade-off of Safety(Security) and Liveness shifts to a better way.\nSo I can say this part stronger, “There’re no key holders, there’re cipher text holders.”\n\nDFINITY’s threshold and its chain-key technology are quite smart but they are still relying on the online/liveness assumption of the validator in the subnet.\n\nAnd about here,\n\nThe deposit addresses are one-time-use and with fixed amounts, since once the secret key is revealed by the decryption of WE, the decryptor can take everything from this private key after that.\nThere’s no split of UTXOs in this system.\nTo prevent the collision during the time before a several blocks confirmation, the deposit address needs to be booked by the depositor.\nThe generators are different from depositors, and this fact is misleading as this system relies on the liveness/online assumption of somebody. This system is independent of generators by the MPC setup including multi-sig. This setup has features similar to the Power of Tau ceremony of zkSNARKs.\nI’m looking forward to having your feedback again.\n\n post by experience on Feb 12, 2022\n\n experience\n\n Very interesting proposal, I had been looking forward to promising applications of Witness Encryption and this looks like it! I have many questions but let’s start with three:\n1/ Is it correct that in your proposed scheme, the entire set of key pairs for deposit addresses is generated in an initial trusted setup, such that when we run out of addresses, another trusted ceremony would need to take place?\n2/ Are you suggesting to store the ciphertexts in an on-chain contract? I imagine this would be a mapping to keep track of which ciphertexts have been decrypted by users who completed a withdrawal request.\n3/ You say that the proof of inclusion can be verified by zkp circuits ifor Ethereum PoS too, but how exactly would you go about this without your proof program running a node that connects to the network? For PoW we can just verify that the cumulative proof of work of the series of block header (of which one contains the event log) is sufficiently high with minimal security tradeoffs, but on PoS you need to verify that you have the correct genesis state, and that the majority of signers that signed a block are indeed mainnet signers, and not signers of some other locally spawned fork \nBrilliant idea overall, looking forward to reading more about this!\n\n post by Killari on Feb 12, 2022\n\n Killari\n\n leohio\n\n Hey,\nThank you for the reading material :). I checked them through and I think I understand this better now. I think you need to be able to formulate Ethereum light client as a exact cover problem, which then reveals the private key of the bitcoin deposit. In PoW version you make the client just verify the pow and that it contains the right transactions (the deposit and the wbtc burn). In PoS you do the same but with validator signatures.\nThis made me to start to think how to attack this system, and the clear way to attack this is that when someone makes a btc deposit and mints the wbtc, you fork the Ethereum chain and start mining. Let’s assume we require 10 eth blocks worth of PoW in the proof. This would mean that once a deposit is made, attacker starts to mine on PRIVATE fork of the Ethereum starting from the deposit block. Once the attacker has been able to mine 10 blocks, they can produce the proof and steal the money. This fork is never published, there’s no direct competition. The only competition is that someone could withdraw the money using the purposed way.\nTo perform this attack, the miner needs to be able to produce 10 blocks worth of work. This cost should be higher than what the btc deposit is worth, for the system to be economically to secure by game theory. Ofcourse a suicidal whale could burn more money to steal the btc.\nHowever, this attack gets worse, as the attacker can steal ALL the deposits with the same 10 proof of work blocks… To combat this I guess one could make the withdrawal process work in a way that you can only withdraw one deposit at once and then you need to wait some amount of time until a new withdrawal can be started. This ensures that each robbery would require the same 10 pow blocks. This would hinder the usability of the protocol.\nDo you happen to have a discord server or similar to chat more about this topic? It would be interesting to collaborate!\n\n post by leohio on Feb 12, 2022\n\n leohio\n\nYes, let’s!!\n\nYes, we need it when we are short of deposit addresses.\n\nYes, on-chain or on a data-shard is the best way. Anyway, we need put data related to the ciphertexts to the input of zkp circuits which are proving the relationship between deposit addresses and ciphertexts. Without this, a depositor can put bitcoin into a faked deposit address. This circuit needs to guarantee that withdrawers can decrypt the ciphertexts when they burn Wrapped BTC, as described in this part.\n\nThen, about this.\n\nThis is prevented like this way. This is not my idea but Barry’s idea.\n\nFirst of all, the block signers of the faked offchain blockchain can be slashed and punished when only one honest person publishes it, among the colluded signers. This is the slash mechanism of Ethereum against the double votes to the fork. But when the colluded signers use MPC to eliminate the honest person, this security collapses. Then the signs or the hint/index of the signs should be published on Bitcoin blockchain. The OP_RETURN space is rather small, so some kind of an index to search this sign data is better to be written in OP_RETURN. Finally, the colluded signers cannot generate faked chains out of the network secretly.\n\n post by leohio on Feb 12, 2022\n\n leohio\n\n Thank you so much for attacking this virtually!\n\nI think this is exactly what we intended to prevent with this mechanism.\n\nIs this answering your question?\nThis is the cost comparison between the mega slash event of 1/3 of PoS validators and unlocking all of the Wrapped BTC in this system in the worst case, and there’s no guarantee to succeed this attack while the mega slash will certainly happen.\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n igorsyl\n\n @leohio @KanaPalladium : thank you for working on this! A couple of questions:\n\nWhat progress has been made since this post was published over a year ago, and\nis the prototype described above available publicly?\n\nIn the meantime, the current prototype requires about 20 minutes to encrypt a message using a tiny problem. Therefore, we need to develop various speedup methods to implement a real-world Wrapped Bitcoin.\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n leohio\n\n I made sure that “KanaPalladium” was not my co-author more than one year ago. Sorry to be late for reporting this.\nMy co-author, whose name was encrypted, said he had no account named “KanaPalladium.” And his name is not “Hiro.”\nThe person who uses the account knows me I guess, but please don’t receive any invitation from him just in case. Ignore the account if he talks about “investment to WE project.”\nEncrypting the author’s name was a mistake. I highly recommend people not to try it.\n\nBasically, no update, and just waiting for new WEs. But signature-based WE (https://fc23.ifca.ai/preproceedings/189.pdf) can be useful enough to update this architecture.\nADP can remain the best unless we have the multi-pairing.\nThe weakness of ADP is that one gate increases the length of cipher-text (memory consumption) 4x.\nSo, the direction is to make it with fewer constraints or to update WE to avoid ADP.\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n kravets\n\n kravets\n\n AI summary of recent practical WE algos\nhttps://app.cognosys.ai/s/a6AyKlf\n\n post by kravets on Aug 3, 2023\n\n kravets\n\n Links 2, 3, 4 here are the paper, the presentation PDF and the video of what might be the state of the art in WE\nhttps://www.google.com/search?q=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&oq=google.com+🔎+On+Succinct+Arguments+and+Witness+Encryption+from+Groups+presentation+-+Google+Search&aqs=chrome..69i57.1511j0j1&sourceid=chrome&ie=UTF-8\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n Load more posts below","tokens":12659,"squid":"ink-research","role":"Deep Scholar","at":1791261684713,"hash":"c7241eb0eca0b13f1c77bf2ab27d5119bdc1aae3"}
{"url":"https://governance.aave.com/t/arfc-sentora-externally-curated-hub-spoke-framework-on-aave-v4/25723/6","domain":"governance.aave.com","title":"[ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4 - Governance / New Market - Aave","text":"GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 7\n min\n\n Sep 28\n\n 6 / 6\n\n Oct 5\n\n 8h ago\n\n post by SentoraHQ on Sep 28\n\n post by CryptoInvest on Sep 30\n\n post by AaveLabs 5 days ago\n\n post by trevorsc 1 day ago\n\n trevorsc\n\n Thanks to Sentora for putting this forward. Isolating curated risk in its own Hub is exactly what V4 was built for, and I’d like to see more of it.\nBecause this would be the first externally curated V4 Hub, though, its terms will likely become the default for every curator that follows. I’d suggest that Aave set the bar for a curator deployment around three questions: what the DAO earns, how that’s enforced, and how the DAO exits if it doesn’t work out. Before this moves to AIP, I’d like to understand those for this proposal.\n1. Revenue base and scale. The split covers “protocol revenue” (reserve factor plus protocol liquidation fees), while Sentora sets the interest rate model (IRM), the reserve factor above the 20% floor, and listings. By my rough math, if the draw caps (about $163.5M) were fully drawn at the 4% kink rate, the DAO’s share would be about $0.65M a year, before any collateral risk premiums. Could Sentora share:\n\n6 and 12-month projections for supply, draws, and DAO revenue, based on its track record in comparable markets;\nwhether existing Sentora-curated liquidity (for example its PYUSD and RLUSD Morpho vaults) is expected to supply the Hub, and whether Sentora earns fees on that supply that sit outside the split;\nany issuer incentives or related-party relationships linked to the listed assets.\n\n2. Enforcement. Which contract receives fees, who can change the fee receiver, and is the 20% reserve-factor floor enforced by role permissions? I’d suggest a DAO-owned splitter that Sentora’s roles can’t modify, monthly settlement with published transaction hashes, and the ability for the DAO or Guardian to cancel an individual queued change during the 48h timelock.\n3. Asset mix. The instance uses eight assets. Three (RLUSD, PYUSD, USDe) are already listed on Aave. The other five (OUSD, PRIME, PST, mWIN, kBTC) are new to Aave or still under review elsewhere. Where Aave’s own providers have already assessed an asset, the parameters differ: LlamaRisk recommended mWIN on Horizon at 67% LTV / 72% LT with an 80 mWIN cap, while this proposal uses an 84.6% collateral factor. I’d suggest:\n\nlaunching with the assets already familiar to Aave, and bringing new collateral in on small “seasoning” caps that grow only with demonstrated liquidation depth and redemption performance;\na limit on the share of draws backed by collateral that no Aave provider has assessed;\npublished justification wherever a curator’s parameters are looser than an Aave provider’s for the same asset;\nconfirmation of the exact launch collateral per spoke, the expansion pipeline with timing, and that every addition goes through the two-week review.\n\n4. Oversight and alignment. The two-week optimistic review relies on a DAO service provider objecting, but the ARFC says none is engaged or paid to monitor the instance. Horizon, on the same 50/50 split, sits inside LlamaRisk’s paid scope. I’d ask the DAO and Sentora to consider:\n\na narrow, funded oversight mandate paid from instance revenue, covering listing review, monitoring, and emergency freeze, with parameter setting staying with Sentora;\na Sentora first-loss commitment, since as written Hub suppliers absorb any shortfall\nadding GHO as a borrowable asset. Under the Horizon terms, the DAO keeps the full interest on GHO it originates, which gives a revenue path that doesn’t depend on the split.\n\n5. Reporting, KPIs, and exit. For the AIP:\n\na monthly public report (TVL and draws by spoke, revenue and settlement, liquidations and bad debt, a parameter-change log, oracle events);\n24/7 on-call, incident disclosure within 24h, and a post-mortem within 7 days;\nexplicit removal triggers (undisclosed bad debt, missed reporting or settlement, an undisclosed conflict, a change of control) and a committed wind-down period after any revocation;\na 6-month pilot term with a review against the projections above. Meeting the targets could earn higher caps or, later, a credit line from a DAO Hub. Missing them leads to wind-down.\n\n post by dirkdiggler871026 12 hours ago\n\n dirkdiggler871026\n\n On seasoning (the third point above): a curator’s parameters get compared against Aave’s own providers here — mWIN at 67% LTV / 72% LT on Horizon versus an 84.6% collateral factor in this proposal. What decides whether a liquidation actually completes is not the LTV comparison but the exit curve: what a seized position realises, at size, in the venue the liquidator is pushed into.\nThat is measurable, and I publish it for the Base equities venues at a pinned block — 19 rows, each carrying its size, band and termination reason (executability-report/measurements/base-depth at main · dirkdiggler1026/executability-report · GitHub). One example of why the curve, not the mark, decides: at that block two pools for the same underlying differ by roughly 600× on a $100 exit, because one of them holds almost nothing.\nTo be explicit: I have not measured mWIN, OUSD, PRIME, PST or kBTC. I am not proposing a parameter. The point is narrower — “demonstrated liquidation depth” needs a defined measurement (pinned block, both legs against the same state, a size ladder, a failure taxonomy), otherwise two reviewers can both be right and still disagree.\nWould it help if I ran that for mWIN’s redemption path and published it — or is that already inside LlamaRisk’s scope for Horizon?\n\n post by chainza 8 hours ago\n\n chainza\n\n Following up on @trevorsc 's point 4 and the Snapshot result. With the ARFC passed, the oversight question is still open for the first instance: the framework states no service provider is scoped or paid to monitor it, and the two-week listing review only works if someone is actually watching.\nSeparate from any paid mandate, a public read-only monitor for this Hub is straightforward on the same event-driven approach as the V4 cap-utilization monitor we raised in the cap-round thread (post #35 in [ARFC] Aave V4 Activation on Ethereum Mainnet). It would cover live utilization and add/draw cap status per Spoke, queued AccessManager operations during the 48h window with time remaining, and role-grant changes.\n@SentoraHQ, would you want that kind of external signal for the Hub? @LlamaRisk / @AaveLabs, is it useful before the AIP, or is monitoring of curated instances deliberately left out of scope? If the AIP includes funded tooling for oversight of curated instances, we’re open to scoping that.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 3\n\n 535\n\n Jul 26\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18","tokens":1797,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261684763,"hash":"8cbcf8a8eb585c5627cf6b2ad450958a0d6178f7"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/precompiles/overview","domain":"docs.arbitrum.io","title":"Precompiles overview | Arbitrum Docs","text":"✏️Request an updatePrecompiles are predefined smart contracts that have special addresses and provide specific functionality which is executed not at the EVM bytecode level, but natively by the Arbitrum client itself. Precompiles are primarily used to introduce specific functions that would be computationally expensive if executed in EVM bytecode, and functions that facilitate the interaction between the parent chain and the child chain. By having them natively in the Arbitrum client, they can be optimized for performance.\nBesides supporting all precompiles available in Ethereum, Arbitrum provides child chain-specific precompiles with methods smart contracts can call the same way they can solidity functions. For more details on the addresses these precompiles live, and the specific methods available, please refer to the methods documentation.","tokens":214,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261688396,"hash":"478345eb078b5f6608863c6048c9d568c8174378"}
{"url":"https://governance.aave.com/t/arfc-deploy-a-dedicated-aave-v4-whitelabel-instance-fully-managed-by-etherfi-on-op-mainnet-to-power-ether-fi-cash/25314/1","domain":"governance.aave.com","title":"[ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash - Governance / General - Aave","text":"[ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 7\n min\n\n Jul 14\n\n 1 / 4\n\n Jul 14\n\n Jul 26\n\n post by ether.fi on Jul 14\n\n ether.fi\n\n Author: Ether.Fi\nDate: 2026-07-14\nTemp Check discussion: [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\nTemp Check Snapshot (passed): Snapshot vote\n\nSummary\nFollowing the successful TEMP CHECK Snapshot, this ARFC formalizes the deployment of a dedicated, EtherFi-operated Aave V4 hub on OP Mainnet to serve as the credit backend for EtherFi Cash, our Visa card product used by tens of thousands of cardholders. The instance replaces the bespoke borrow/lend market (“Debt Manager”) that powers Cash today.\nThe instance is isolated and borrow-whitelisted: borrowing is restricted exclusively to EtherFi Cash users, while EtherFi operates it end to end - configuration, risk parameters, liquidity, and growth - while Aave provides the V4 deployment and operating license and earns a share of the revenue the instance generates. Because the instance is ring-fenced and EtherFi-run, Aave carries the upside without taking on the market’s day-to-day risk.\nThe proposal carries a substantial commercial package contributed by EtherFi and the Optimism Foundation, detailed in the Commercial Terms section: a 20% revenue share to the Aave DAO, GHO integration into EtherFi Cash, an Aave-deployed GHO GSM on OP Mainnet, full migration of the EtherFi Debt Manager, up to $175M in assets at launch, and product exclusivity to Aave V4.\nRelative to the Temp Check, this ARFC adds: (i) the hub-and-spoke topology, (ii) the operating model and permissions matrix, naming Nonce Capital as independent risk admin, (iii) the Debt Manager migration approach, (iv) the reference parameter baseline from the current Cash configuration, (v) a launch reserve set that mirrors the full current Cash collateral configuration, including LiquidEUR and LiquidRWA (both already live in the Debt Manager), and (vi) responses to feedback raised during the Temp Check stage.\nMotivation\nEtherFi Cash today. Cash lets cardholders spend against both yield-bearing and non-yield bearing collateral at the point of sale: they borrow a stablecoin to settle a card transaction while preserving their underlying asset exposure. It runs in production on OP Mainnet on a custom, non-pooled borrow/lend market with roughly $25M in active borrows across 16+ collateral assets and a high-frequency, low-ticket, well-distributed borrow profile. We are targeting roughly $500M in assets on the instance by the end of 2026.\nWhy migrate to Aave V4. Maintaining a bespoke lending engine is increasingly operationally taxing. Migrating to a dedicated Aave V4 instance lets EtherFi inherit audited, battle-tested infrastructure and governance machinery while preserving the Cash product surface (User Safes, Credit/Debit modes, settlement) above it.\nWhy this is a fit for Aave.\n\nPure-upside revenue. Aave shares in the borrow revenue of a live consumer product without committing pool liquidity or balance sheet to it. At our end-2026 target scale, the instance is projected to generate an estimated $5-6M in annual reserve-factor revenue, 20% of which accrues directly to the Aave DAO and compounds as the Cash book grows.\n\nDirect GHO adoption. GHO becomes a supply/borrow reserve on the instance after GHO is deployed on OP Mainnet, with an Aave-deployed GSM strengthening GHO’s peg and liquidity on OP Mainnet.\n\nGHO as a spend currency. Beyond being a listed reserve, GHO could, at the Aave DAO’s discretion, be enabled as a deposit/spend asset in Cash, subject to sufficient GHO liquidity to support the Cash program as expected, turning card volume into organic GHO demand.\n\nReal-world spend footprint. Aave extends into consumer card settlement, anchored by a product with tens of thousands of active cardholders.\n\nNet new on-chain activity on OP Mainnet, with exclusivity to Aave V4 for the Cash product.\n\nAave Labs supports deploying the instance and providing the operating license. The Temp Check Snapshot has passed, confirming community sentiment; this ARFC finalizes the specification with service-provider input ahead of an AIP.\nClarifications Following Temp Check Feedback\nWe thank delegates for the engagement on the Temp Check thread. The questions raised broadly fall into four areas, addressed below.\n1. Allocation of responsibility. EtherFi is the operator of EtherFi Cash and of the instance, and bears operational, legal and regulatory responsibility for the Cash product: configuration, risk parameters, oracles, asset onboarding, liquidity, liquidator infrastructure, and cardholder-facing operations. The Aave DAO’s role is limited to licensing the V4 codebase for a whitelisted, isolated deployment; the DAO does not operate the instance, set its parameters, custody user funds, or market the Cash product, and the operating license reflects this allocation of responsibility and ring-fencing explicitly.\n2. Term, renegotiation, and exit. As stated in the Temp Check, Aave provides the V4 codebase under license for a 2-year initial term. The operating license includes customary renewal provisions and defined termination rights for each party, together with contractual obligations on EtherFi to wind the instance down in an orderly, user-protective manner on termination or expiry, facilitating the repayment, migration, and offboarding of user positions. Optionality is therefore not one-way: both sides hold defined renegotiation and exit paths, and the DAO’s economic interests are contractually protected for the duration of the term.\n3. Revenue assumptions and net contribution to the DAO. To clarify the revenue base: the $5-6M estimate refers to total instance reserve-factor revenue (the V4 “Liquidity Fee”) at the end-2026 target scale, of which the Aave DAO receives 20%, approximately $1.0-1.2M annually at that scale, growing with the Cash book.\n\nTarget instance assets (end-2026): ~$500M\n\nRevenue base: all instance protocol revenue (Liquidity Fee, liquidation fees, SVR, other fee streams). Projection below covers the Liquidity Fee component only.\n\nProjected annual reserve-factor revenue at target scale: ~$5-6M\n\nAave DAO share (20%): ~$1.0-1.2M per year\n\nOn cost allocation: Aave’s contribution is limited to the V4 deployment, the operating license, and the GHO GSM; instance operations, risk management, liquidity sourcing, incentives, monitoring, and liquidator infrastructure are borne by EtherFi per the Commercial Terms. The DAO bears no ongoing operating costs for the instance, so the 20% share is substantially net revenue to the DAO.\n4. Framework categorization. This deployment is a whitelabel instance, comparable in structure to Tydro (a dedicated, operator-managed V4 deployment under license), not a friendly fork. Consideration to the Aave DAO takes the form of the 20% share of all instance revenues, product exclusivity to Aave V4, GHO integration and the GSM footprint on OP Mainnet, and the launch capitalization package, including the $1.2M joint incentive commitment EtherFi has made together with the Optimism Foundation, rather than token consideration.\nSpecification\nArchitecture\nA dedicated Aave V4 deployment on OP Mainnet, one of V4’s first Layer 2 targets, consisting of one Liquidity Hub and, at launch, a single spoke listing the full current Cash collateral set. The instance is whitelisted and isolated from Aave’s shared liquidity and all other Aave markets. Borrow access is permissioned: only EtherFi Cash Users may open borrow positions on the instance. Supply access is not restricted to cardholders, allowing third-party liquidity provision (e.g., the Optimism Foundation’s launch deposit). EtherFi operates the instance end to end and is responsible for collateral listing, risk parameters, oracles, and ongoing risk management. Aave provides the V4 codebase under license for a 2-year initial term, but is not responsible for the instance’s assets, configuration, or risk.\n\nHub: EtherFi Cash Hub (OP Mainnet), the instance’s sole Liquidity Hub.\n\nSpoke: Cash Spoke, a single spoke at launch, listing the full current Cash collateral set.\n\nCollateral: weETH, wETH, eBTC, USDC, USDT, EURC, frxUSD, GHO, ETHFI, sETHFI, eUSD, OP, beHYPE, wHYPE, LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve, LiquidEUR, LiquidRWA\n\nBorrowable: USDC, GHO (pending deployment)\n\nAdditional spokes may be introduced over time via the risk-admin role as the Cash book grows and V4 architecture evolves.\nOperating Model & Permissions\nEtherFi acts as operator and will authorize Nonce Capital as the independent risk admin for the instance. Nonce Capital serves as curator of the ether.fi Liquid vault suite, bringing direct familiarity with the Cash collateral set while remaining organizationally independent of the operator. EtherFi may additionally engage further service providers over time to provide supplementary review of the market. The risk admin holds authority over:\n\nCollateral listing and de-listing\n\nOracle selection (Chainlink, RedStone, or otherwise) and configuration\n\nCollateral factors, liquidation thresholds, and liquidation bonus configuration per asset\n\nInterest rate models, supporting both utilization-curve and fixed-rate reserves\n\nAdd caps, draw caps, and pause states\n\nDivision of responsibilities:\n\nEtherFi (Operator): executes instance configuration; proposes collateral listings, oracles, and risk parameters to the risk admin; owns liquidity sourcing, market growth, and liquidator infrastructure.\n\nNonce Capital (Independent Risk Admin): approves and configures all risk-relevant changes per the authorities listed above.\n\nAave Labs: provides the V4 deployment and operating license; deploys the GHO GSM on OP Mainnet.\n\nAave DAO: ratifies the deployment via governance; governs GHO facilitation; receives the 20% revenue share, settled automatically on-chain.\n\nLaunch Collateral Set\nLaunch reserves mirror the existing Cash collateral set, with streamlined additions over time via the risk-admin role:\n\nETH-likes: weETH, wETH\n\nBTC-likes: eBTC\n\nStables: USDC, USDT, EURC, frxUSD, GHO\n\nEtherFi platform, Optimism & HYPE: ETHFI / sETHFI, eUSD, OP, beHYPE, wHYPE\n\nLiquid vault receipts: LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve, LiquidEUR, LiquidRWA\n\nBorrow reserves. USDC and GHO, each added as both a supply and a borrowable asset. GHO is enabled upon GHO’s deployment on OP Mainnet.\nRisk Parameters\nInitial parameters are intended to mirror the current Cash Debt Manager configuration as closely as V4 mechanics permit, providing continuity for the migrated book. The current production configuration on OP Mainnet, which serves as the reference baseline, is as follows (see the Cash collateral & borrowing documentation):\nAsset\nLTV | Liquidation Threshold | Liquidation Bonus\nUSDC\n90% | 95% | 1%\nUSDT\n90% | 95% | 1%\nEURC\n90% | 95% | 1%\nfrxUSD\n90% | 95% | 1%\nweETH\n55% | 75% | 3.5%\nwETH\n55% | 75% | 3.5%\neBTC\n52% | 72% | 5%\neUSD\n80% | 90% | 2%\nETHFI / sETHFI\n20% | 50% | 5%\nOP\n20% | 50% | 5%\nwHYPE\n45% | 65% | 4%\nbeHYPE\n40% | 60% | 5%\nLiquidETH\n50% | 70% | 5%\nLiquidBTC\n50% | 70% | 5%\nLiquidUSD\n80% | 90% | 2%\nLiquidReserve\n80% | 90% | 2%\nLiquidEUR\n70% | 90% | 2%\nLiquidRWA\n70% | 90% | 2%\nGHO parameters will be set by Nonce Capital upon GHO’s deployment on OP Mainnet.\nInterest Rate Models\nReserves support both standard two-slope utilization-curve IRMs and fixed-rate configurations where appropriate for the Cash borrow profile. Initial IRM parameters will be published alongside the parameter set above.\nOracles\nOracle providers (Chainlink, RedStone, or otherwise) will be selected and configured per asset by Nonce Capital, with exchange-rate pricing and appropriate safeguards applied to collateral where suitable.\nLiquidations\nThe instance uses Aave V4’s standard partial liquidation behavior, including the dynamic liquidation bonus mechanism. EtherFi adapts its existing liquidator tooling to the V4 flow prior to migration.\nMigration from the Debt Manager\nEtherFi will migrate the existing Cash book (~$25M in active borrows across 16+ collateral assets) from the Debt Manager to the V4 instance via a phased migration over a short window, organized in cohorts to validate that risk controls (oracle configuration, caps, liquidator tooling, and monitoring) are functioning as intended before the full book transitions. The Cash product surface (User Safes, Credit/Debit modes, settlement) is preserved unchanged above the new credit backend; the migration is designed to be invisible at the cardholder level.\nCommercial Terms\nThe following package has been aligned between EtherFi, the Optimism Foundation, and Aave Labs to strengthen the instance at launch. Final mechanics are subject to this governance process and service-provider review.\n\nRevenue share to Aave DAO: 80-20 EtherFi / Aave on the totality of protocol revenue generated by the instance. The 20% share applies to all instance revenue streams, including: (i) reserve-factor (Liquidity Fee) revenue on instance borrows; (ii) liquidation fees accruing to the protocol; (iii) oracle value recapture proceeds attributable to the instance (e.g., Chainlink SVR), net of any oracle-provider share; and (iv) any other current or future protocol fee streams the instance generates. 20% of each stream flows to the Aave treasury, settled automatically. This split reflects the long-standing, proven relationship between EtherFi and Aave, together with Aave V4 serving as the sole lending and borrowing market for EtherFi Cash.\n\nGHO integration: GHO supported on the instance as both a supply and a borrowable reserve once GHO is deployed on OP Mainnet. Aave deploys a GHO GSM on Optimism.\n\nGHO as a spend currency: at the Aave DAO’s discretion and conditional on sufficient GHO liquidity for the Cash program, GHO may also be added as a spendable/deposit asset within Cash itself, converting a portion of card usage into direct GHO demand.\n\nAssets at launch: EtherFi brings up to $175M in assets to the instance at launch, with a clear path to grow significantly from there.\n\nExclusivity: EtherFi Cash will exclusively use Aave V4 lending markets as its DeFi lending protocol.\n\nLaunch capitalization (EtherFi & Optimism Foundation funded):\n\n$20M supplied from the Optimism Foundation Treasury into the instance.\n\n$1.2M joint incentive package, directed toward deposits and/or borrows across any asset.\n\n$5M strategic GHO position, taken via the GHO GSM, shared by the Optimism Foundation and EtherFi, held for 6 months, after which continuation is at each party’s discretion.\n\nTaken together, the three parties contribute in distinct capacities: Aave provides the V4 codebase license, deployment, and GHO infrastructure; the Optimism Foundation and EtherFi jointly provide the launch capital, incentives, and initial asset base; and EtherFi alone operates the instance end to end with revenue flow back to the Aave DAO via the agreed reserve-factor share.\nUseful Links\n\nTemp Check discussion: governance.aave.com thread\n\nTemp Check Snapshot: snapshot.org proposal\n\nEtherFi Cash collateral & borrowing documentation: help.ether.fi\n\nEtherFi: ether.fi\n\nNext Steps\n\nGather community feedback;\n\nEscalate the proposal to the ARFC Snapshot stage.\n\nIf the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal, targeting a July 2026 deployment to meet the Cash product handoff from the current Debt Manager.\n\nDisclaimer\nThis proposal is submitted by EtherFi as the operator of EtherFi Cash and the proposer of the instance. This material contains forward looking statements regarding design, functionality, and performance; actual results may differ materially from those expressed or implied. The commercial terms reflect agreements with Aave Labs and the Optimism Foundation; all terms and parameters are subject to this governance process and service-provider review. EtherFi is not compensated by any third party for submitting this proposal.\nCopyright\nCopyright and related rights waived via CC0.\n\n 2\n\n read \n\n 7\n min\n\n 8 days later\n\n post by ether.fi on Jul 23\n\n post by Abel189 on Jul 26\n\n post by MconnectDAO on Jul 26\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 6\n\n 1.2k\n\n Jul 9\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d","tokens":4228,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261695169,"hash":"1b926d7b3bf5cb4cc93c54803a250bc358dfc939"}
{"url":"https://ethresear.ch/c/cryptography/28","domain":"ethresear.ch","title":"Latest Cryptography topics - Ethereum Research","text":"Latest topics in Cryptography\n\n Cryptography\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Cryptography category\n\n Cryptography\n\n 0\n\n 2.5k\n\n Apr 2019\n\n Accountability for Encrypted Mempools\n\n Cryptography\n\n mev,censorship-resistance\n\n 0\n\n 84\n\n 15h\n\n Towards Encrypted Mempools from Threshold IBE without Batching\n\n Cryptography\n\n 4\n\n 234\n\n 6d\n\n Post-Poseidon: Hash Function Variants for Ethereum\n\n Cryptography\n\n 0\n\n 311\n\n 13d\n\n Post-Quantum Lattice or Hash-Based: One Question, Two Right Answers\n\n Cryptography\n\n post-quantum\n\n 1\n\n 179\n\n 14d\n\n Cryptographic canaries and backups\n\n Cryptography\n\n 8\n\n 7.6k\n\n 18d\n\n Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators\n\n Cryptography\n\n 13\n\n 1.5k\n\n 28d\n\n Proposed PQ upgrade for ecrecover\n\n Cryptography\n\n account-abstraction,post-quantum\n\n 10\n\n 376\n\n Sep 4\n\n Poseidon2b is secure!\n\n Cryptography\n\n post-quantum\n\n 4\n\n 459\n\n Aug 31\n\n Lattice-based signature aggregation\n\n Cryptography\n\n post-quantum\n\n 8\n\n 2.8k\n\n Aug 30\n\n Poseidon hash for Ethereum is NOT secure!\n\n Cryptography\n\n 15\n\n 379\n\n Aug 30\n\n Formally Verified Security for PQ-DAS / leanDA\n\n Cryptography\n\n data-availability,post-quantum\n\n 0\n\n 165\n\n Aug 18\n\n Exploring Signature-Free Post-Quantum RLPx Handshake\n\n Cryptography\n\n p2p,post-quantum\n\n 1\n\n 225\n\n Aug 18\n\n Ashlar: an AO hash from a squaring degree engine, and a request for cryptanalysis\n\n Cryptography\n\n 1\n\n 75\n\n Aug 16\n\n Ragged multi-instance GKR for Poseidon2b: one walk, unequal regions, no max-width padding\n\n Cryptography\n\n 0\n\n 65\n\n Aug 12\n\n RANDAO Breaks at L*: A Post-Quantum VRF for Ethereum\n\n Cryptography\n\n post-quantum\n\n 4\n\n 222\n\n Aug 11\n\n A Mechanized Functor Tower for Cross-Domain State Preservation\n\n Cryptography\n\n cross-shard,rollup,security,chain-sync\n\n 6\n\n 187\n\n Jul 28\n\n Threshold Encrypted Mempools with mev-commit Preconfirmations\n\n Cryptography\n\n mev,preconfirmations\n\n 1\n\n 601\n\n Jul 9\n\n Ethereum Cryptography and AI slop\n\n Cryptography\n\n 4\n\n 265\n\n Jun 15\n\n SPHINCS minus : Efficient Stateless Post-Quantum Signature Verification on the EVM\n\n Cryptography\n\n 0\n\n 2.7k\n\n Jun 12\n\n Observation Commitment Protocol (OCP) v1.0.0\n\n Cryptography\n\n 7\n\n 245\n\n May 28\n\n So you wanna Post-Quantum Ethereum transaction signature\n\n Cryptography\n\n 27\n\n 3.4k\n\n May 26\n\n Native Ephemeral Key Rotation via Frame Transactions\n\n Cryptography\n\n account-abstraction,post-quantum\n\n 7\n\n 571\n\n May 20\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Cryptography\n\n account-abstraction,post-quantum\n\n 1\n\n 1.3k\n\n May 20\n\n On the gas efficiency of the WHIR polynomial commitment scheme\n\n Cryptography\n\n 5\n\n 1.1k\n\n May 19\n\n Introducing Bandersnatch: a fast elliptic curve built over the BLS12-381 scalar field\n\n Cryptography\n\n 4\n\n 10.5k\n\n May 11\n\n Upgrade any Ethereum wallet to post-quantum security in one transaction using ZK proofs with a hidden public key\n\n Cryptography\n\n 4\n\n 429\n\n May 4\n\n TEE-as-Verifier for BitVM-style bridges: collapsing the canonical-label distribution problem\n\n Cryptography\n\n 0\n\n 96\n\n May 3\n\n Releasing Constantine v0.2.0 (Jan 2025), a modular cryptography stack for Ethereum\n\n Cryptography\n\n library\n\n 2\n\n 3.4k\n\n Apr 3\n\n Migration Strategies for EOAs under the Quantum Threat: Breakages, and Open Questions\n\n Cryptography\n\n post-quantum\n\n 4\n\n 537\n\n Mar 21","tokens":848,"squid":"ink-research","role":"Deep Scholar","at":1791261695393,"hash":"82a0e97abeb963dece92698887807f03037a885b"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials","domain":"docs.arbitrum.io","title":"Arbitrum essentials | Arbitrum Docs","text":"📄️Estimate gasLearn how to estimate gas costs on Arbitrum using eth_estimateGas, NodeInterface.gasEstimateComponents(), and the Arbitrum SDK. Covers the two-component fee model with L1 data costs and L2 execution costs.📄️Chains and testnetsOverview of Arbitrum's public chains including Arbitrum One (Rollup), Arbitrum Nova (AnyTrust), and available testnets. Compare chain features, technology stacks, and use cases for each network.🗃Bridging8 items🗃Arbitrum vs Ethereum5 items📄️OraclesOverview of blockchain oracles on Arbitrum — external data providers that supply offchain data to smart contracts. Learn how oracles work, their trust models, and available providers on Arbitrum.🗃Precompiles2 items🗃NodeInterface2 items🗃Reference9 items","tokens":187,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261698825,"hash":"51a6c37fa633bc6602f8b4934d46dd51d975d892"}
{"url":"https://governance.aave.com/t/arfc-deploy-a-dedicated-aave-v4-whitelabel-instance-fully-managed-by-etherfi-on-op-mainnet-to-power-ether-fi-cash/25314/4","domain":"governance.aave.com","title":"[ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 7\n min\n\n Jul 14\n\n 4 / 4\n\n Jul 25\n\n Jul 26\n\n post by ether.fi on Jul 14\n\n 8 days later\n\n post by ether.fi on Jul 23\n\n ether.fi\n\n [ARFC Addendum] EtherFi Cash Aave V4 Instance Formatted Risk Parameters\nAuthor: Ether.Fi\nDate: 2026-07-23\nRelated: [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\nSummary\nDelegates correctly flagged that the Risk Parameters table in the ARFC was expressed in Aave V3 terms (LTV / Liquidation Threshold / Liquidation Bonus). This addendum restates the launch parameters in Aave V4’s native format. The design intent is unchanged: mirror the current Cash Debt Manager configuration as closely as V4 mechanics permit.\nV3 → V4 Mapping\n\nV4 replaces the V3 LTV / Liquidation Threshold pair with a single Collateral Factor per reserve. Collateral Factors are set to the prior Liquidation Thresholds, preserving the liquidation boundary for the migrated book. Origination limits continue to be enforced at the Cash application layer (User Safes), as they are today.\n\nThe prior fixed Liquidation Bonus carries over as each reserve’s Max Liquidation Bonus.\n\nLiquidation Fee (the protocol’s share of the realized bonus, new in V4) is set to a flat 10% across all reserves.\n\nLaunch Parameters - Cash Spoke\nAsset\nCollateral Factor | Max Liquidation Bonus | Liquidation Fee\nUSDC\n95% | 1% | 10%\nUSDT\n95% | 1% | 10%\nEURC\n95% | 1% | 10%\nfrxUSD\n95% | 1% | 10%\nweETH\n75% | 3.5% | 10%\nwETH\n75% | 3.5% | 10%\neBTC\n72% | 5% | 10%\neUSD\n90% | 2% | 10%\nETHFI / sETHFI\n30% | 5% | 10%\nOP\n30% | 5% | 10%\nwHYPE\n65% | 4% | 10%\nbeHYPE\n60% | 5% | 10%\nLiquidETH\n70% | 5% | 10%\nLiquidBTC\n70% | 5% | 10%\nLiquidUSD\n80% | 2% | 10%\nLiquidReserve\n80% | 2% | 10%\nLiquidEUR\n80% | 2% | 10%\nLiquidRWA\n80% | 2% | 10%\nGHO parameters will be set by Nonce Capital upon GHO’s deployment on OP Mainnet, following the recommendations from the Aave DAO Service Providers.\nRemaining Configuration\nAll remaining V4 configuration - Spoke liquidation config (targetHealthFactor, liquidationBonusFactor, healthFactorForMaxBonus), interest rate models, Liquidity Fee values, Add/Draw Caps, and collateral risk settings, will be released at the AIP stage in final structuring with Nonce Capital as independent risk admin.\nNext Steps\nThis table supersedes the V3-formatted Risk Parameters table in the original ARFC. The proposal otherwise proceeds as outlined: community feedback, ARFC Snapshot, then AIP targeting a July 2026 deployment.\nDisclaimer\nThis addendum is submitted by EtherFi as the operator of EtherFi Cash. All parameters remain subject to this governance process and review by Nonce Capital.\nCopyright\nCopyright and related rights waived via CC0.\n\n post by Abel189 on Jul 26\n\n Abel189\n\n Thank you for the proposal.\nI think this is an interesting evolution of the Aave ecosystem, as it introduces a business model where the DAO benefits from protocol adoption without directly operating or managing the instance.\nSince this is also a commercial partnership with a revenue-sharing agreement and a defined initial term, I believe it would be valuable to include a structured performance review before the end of that term. In addition to technical metrics, governance could evaluate indicators such as revenue generated for the DAO, instance growth, GHO adoption, operational reliability, and whether the partnership is meeting its original objectives.\nHaving predefined review criteria would provide a transparent basis for any future decision regarding renewal, expansion, or adjustments to similar whitelabel deployments.\n\n post by MconnectDAO on Jul 26\n\n MconnectDAO\n\n ether.fi\n\n Thank you for the detailed ARFC and the V4 risk parameter addendum.\nI see clear upside in the whitelabel V4 instance and the 80/20 revenue share, especially as a way for the DAO to benefit from protocol adoption without directly operating the market. At the same time, some risks deserve explicit governance handling:\nReputational and strategic risk for the DAO from a single, branded card product using an Aave-powered backend.\nVery high collateral factors on stable and vault receipts (up to 95%) combined with complex collateral types, which makes oracle configuration and liquidation behaviour critical for retail users.\nLimited on-chain accountability for the independent risk admin, and the need for transparent performance and risk reporting over the 2-year license term.\nI’d support moving this forward conditioned on: (i) a clearly specified, on-chain or documented performance review before license renewal (covering revenue, GHO adoption, operational reliability, and risk events), and (ii) minimum disclosure standards for Nonce Capital and EtherFi on stress tests, oracle choices, liquidation outcomes, and incident reporting. I believe this would strengthen the DAO’s governance posture while still enabling the proposed commercial partnership.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 6\n\n 1.2k\n\n Jul 9\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 911\n\n Sep 18\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d","tokens":1387,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261705406,"hash":"0548a4a04878069012eb1a4fe0d05935f04b1f64"}
{"url":"https://ethresear.ch/t/exploring-the-design-space-for-a-post-quantum-public-key-registry-for-ethereum-validators/25040/1","domain":"ethresear.ch","title":"Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators - Cryptography - Ethereum Research","text":"Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n read \n\n 16\n min\n\n Jun 1\n\n 1 / 14\n\n Jun 1\n\n 28d ago\n\n post by tcoratger on Jun 1\n\n tcoratger\n\n Authors: Thomas Coratger, Tom Wambsgans, Ladislaus, Thomas Thiery, Justin Drake\nCredits to Benedikt Wagner and Dmitry Khovratovich for all the theoretical work, ideas, discussions and papers that have been published on eprint and that are linked in this post.\nAs outlined in the Strawmap roadmap, securing Ethereum against the looming threat of large-scale quantum computers is a top priority. A critical milestone in this transition is migrating our proof-of-stake consensus from BLS signatures to a post-quantum (PQ) secure signature scheme.\nThis post aims to explore the concepts and design space for a Post-Quantum Public Key Registry. Importantly, the actual transition will happen in phases: the Public Key Registry fork will occur first, enabling validators to register their PQ keys, followed by the actual signature switch several forks later. This gradual rollout gives the network ample time to build state, monitor for vulnerabilities, and finalize the underlying cryptographic primitives. Ultimately, the discussions generated here will mature into a formal Ethereum Improvement Proposal (EIP).\nHistorical Context and the Need for a Registry\nIn the current proof-of-stake design, validator public keys (BLS12-381) are registered via the deposit contract on the execution layer and subsequently processed by the consensus layer. BLS signatures are wonderfully efficient for aggregation, but they rely on elliptic curve cryptography, which is completely broken by Shor’s algorithm.\nTransitioning to post-quantum signatures introduces significant operational difficulties for the network’s participants. Generating and securely storing these new keys requires validators to access their cold storage, execute new key generation scripts, and interact with their most sensitive cryptographic material. Because this is such a high-friction, high-stakes operational maneuver, we plan to decouple the registration of these keys from their active use in consensus. A dedicated Public Key Registry acts as a critical warmup phase, giving validators a low-pressure environment to securely manage their hardware setups and gradually commit to their post-quantum identities well in advance of the actual protocol upgrade.\nPart 1: Foundations — The Cryptographic Core: eXtended Merkle Signature Scheme (XMSS)\nWhen exploring post-quantum digital signatures, the cryptographic community generally categorizes the design space into a few main families: lattice-based, code-based, isogeny-based, multivariate, and hash-based. While solutions like lattice-based signatures (e.g., aggregating Falcon signatures via proof systems like LaBRADOR) are heavily studied, selecting secure parameters for them is highly complex, and their security proofs often rely on techniques with uncertain implications in a post-quantum setting.\nUltimately, hash-based signatures emerge as the strongest candidate for Ethereum. They stand out due to their conceptual simplicity, ease of implementation, and reliance on highly conservative, standard-model cryptographic assumptions (like basic collision and preimage resistance) rather than complex algebraic structures.\nHash-based signatures present two primary challenges: they do not natively support aggregation, and they require strict state management to prevent key reuse. While the aggregation problem must be solved separately via cryptographic proofs, the structured nature of Ethereum’s proof-of-stake consensus gives us a massive advantage for the latter: validators are required to sign exactly once per epoch.\nThis strict timeline allows us to bypass the significant verification overhead of fully stateless schemes (like SPHINCS+, which requires roughly 10x more hashes at verification) and instead leverage a synchronized (stateful) signature scheme. The eXtended Merkle Signature Scheme (XMSS) perfectly fits this model, tying each signature to a specific sequential position. Note that double signing under XMSS would break the key by leaking enough intermediate hash information to let an attacker forge signatures for that leaf.\nHow XMSS Works\nTo understand why XMSS is so effective, it helps to break down its construction step by step, starting from the basic properties of a hash function.\nThe Building Block: Hash Chains\nBecause cryptographic hash functions are one-way (preimage resistant), you cannot easily deduce an input from an output. A hash chain leverages this by taking a secret starting value (a private key) and hashing it repeatedly a predetermined number of times to produce a final value (the public key).\nIf a hash chain has 256 steps, revealing the intermediate hash at step 100 proves you know the secret, because a verifier can simply hash that value 156 more times to see if it matches the public key. This is the foundation of a One-Time Signature (OTS). To sign a message, you convert the message into a number (e.g., 100), and reveal the hash at that specific position in the chain.\nimage1136×188 9.5 KB\nParallel Chains for Security\nA single hash chain has a critical vulnerability: if you reveal the hash at position 100 to sign a message, an attacker could just hash your signature one more time to forge a signature for a message mapping to position 101.\nTo prevent this forgery, the scheme splits the message into multiple smaller chunks, using a parallel hash chain for each chunk, and enforces a strict mathematical constraint: a target sum. For a signature to be valid, the sum of all the chunk values (chain positions) must equal a specific, predetermined number.\nBecause of this constraint, if an attacker tries to forge a signature by hashing one chain forward (which increases its numerical value), the total sum of their forged signature will exceed the target. To rebalance the sum and produce a valid encoding, the attacker would be forced to decrease the value on another chain. Decreasing a value requires moving backward up the chain (reversing the hash function). Since cryptographic hash functions are strictly one-way (preimage resistant), this backward movement is computationally infeasible, rendering the W-OTS signature completely secure.\nimage1456×436 39.5 KB\nAttempted Forgery Analysis\n\nSignature Vector\nChain 0 (m_0'𝑚′0)\nChain 1 (m_1'𝑚′1)\nChain 2 (m_2'𝑚′2)\nChain 3 (m_3'𝑚′3)\nTarget Sum\n\n Original\n2\n3\n3\n1\n9\n\n Forged\n3\n 2 (Dropped)\n3\n1\n9\n\nWhy the Attack Fails\nTo forge the first chain forward (2 \\rightarrow 32 →3), the attacker simply hashes the revealed value one more time. However, this increases the total sum to 10, violating the protocol’s strict target constraint.\nTo maintain the mandatory target sum of 9, the attacker is forced to decrease a value on another chain (3 \\rightarrow 23 →2). Because cryptographic hash functions are strictly one-way (preimage resistant), moving backward up a chain to decrement a value is computationally infeasible, rendering the forged signature invalid.\nScaling to Many-Time Signatures\nBecause revealing these intermediate hashes inherently consumes the chains, this setup can only be used safely once. To sign thousands of blocks over a validator’s lifecycle, we need a many-time signature scheme.\nXMSS solves this by generating a massive sequence of independent One-Time Signature keypairs. The public keys of all these OTS instances are placed as the leaves of a massive Merkle tree. The root of this Merkle tree becomes the validator’s actual global public key—this is the small, compact data point that would be submitted to the Public Key Registry.\nimage1136×558 27.9 KB\nThe Signing and Verification Process\nWhen a validator needs to sign a block for a specific slot, they move to the next unused leaf in their tree. The final signature contains:\n\nThe OTS signature for the current message.\nThe specific OTS public key for that leaf.\nThe Merkle authentication path (the sibling hashes) connecting that leaf to the global Merkle root.\n\nimage1136×476 30.4 KB\nimage1136×368 25.9 KB\nThe verifier simply checks the OTS signature against the OTS public key, and then verifies the Merkle path to ensure that specific leaf is a legitimate part of the validator’s registered root.\nWhat Gets Registered: Key Sizes and Practical Impact\nNow that we understand the conceptual design of XMSS, the natural question for the registry is: what exactly does a validator need to submit, and how big is it?\nPublic Key: 52 bytes\nEach validator’s XMSS public key consists of two parts:\n\nComponent\nSize\nDescription\n\nMerkle root\n32 bytes\nThe root hash of the validator’s XMSS Merkle tree. This single value commits to all 2^{32}232 one-time signing leaves. It is the only thing a verifier needs to check that any individual signature belongs to this validator.\n\nPublic parameter\n20 bytes\nA random value generated once at key creation time. It is mixed into every hash computation (tree nodes, chain steps, message hashing) and serves two primary roles: it is essential for tight security proofs, and it provides domain separation across users so that an attacker cannot attack multiple validators in parallel when attempting a brute-force attack.\n\nTotal\n52 bytes\n\nFor comparison, a BLS12-381 public key is 48 bytes. The post-quantum public key is only 4 bytes larger — a remarkable result that means the registry’s per-validator storage overhead is negligible. At scale, registering 1 million validators requires storing only ~52 MiB of public keys in the state.\nSignature: 3,112 bytes\nEach per-slot XMSS signature contains:\n\nComponent\nSize\nDescription\n\nMerkle authentication path\n1,024 bytes\nThe list of sibling hashes needed to reconstruct the path from the used leaf up to the Merkle root. The tree has 32 levels, so there are 32 siblings, each 32 bytes. A verifier re-hashes this path and checks that the result matches the public key root.\n\nEncoding randomness\n28 bytes\nA per-signature random value that is mixed into the message hash to produce the target-sum encoding. While it allows the signer to resample until hitting the required target sum, its primary purpose is security: without this randomness, the scheme would only provide 64 bits of security, leaving the encoding vulnerable to a birthday attack.\n\nChain hash values\n2,048 bytes\nThe 64 intermediate hash chain values revealed by the signer — one per parallel chain. Each value is the point in its chain that corresponds to the encoded message chunk. The verifier walks each chain forward from this revealed value to the chain endpoint and checks consistency with the Merkle leaf.\n\nTotal\n3,112 bytes\n\nThis is significantly larger than a BLS signature (96 bytes), which is a reason why aggregation via SNARKs is essential (see next section).\nSecret Key: Manageable on Consumer Hardware\nA naive implementation would need to compute and store the full Merkle tree with 2^{32}232 leaves all at once—requiring terabytes of storage and immense memory. Instead, our reference implementation of the scheme uses a top-bottom tree strategy. It splits the massive tree into a top half (height 16) and 2^{16}216 bottom trees (height 16 each).\nimage1136×460 25.9 KB\nThis drops the spatial complexity of key generation and signing to \\mathcal{O}(\\sqrt{\\text{lifetime}})O(√lifetime), meaning it only requires a few megabytes of RAM and disk space. Instead of holding the whole structure, the validator only stores the top tree and caches a sliding window of just two bottom trees: the current bottom tree and the next bottom tree. Caching the next tree is a practical necessity; it ensures a seamless transition without missing any attestations when the current bottom tree is exhausted (every ~65,536 slots, or ~9 days).\nCrucially, these cached tree structures are not cryptographically sensitive. They are simply intermediate public hashes leading up to the global Merkle root. They can be stored in plaintext on standard disks. The only actual cryptographic secret is the 32-byte PRF seed.\nWhy KoalaBear?\nAll arithmetic in the scheme is performed over the KoalaBear prime field, with modulus:\n\np = 2^{31} - 2^{24} + 1\n𝑝=231−224+1\nThis is a 31-bit prime, meaning each field element fits in a single 32-bit word (4 bytes). The choice of a small field is deliberate and performance-critical. Because the XMSS scheme and the SNARK aggregator are both dominated by field arithmetic, every multiplication and addition must be as fast as possible.\nA 31-bit prime has three key advantages:\n\nSIMD parallelism: Four-byte elements pack tightly into CPU vector registers. On x86 processors, AVX2 instructions can process 8 field elements in parallel (256-bit registers), and AVX512 can process 16 at once (512-bit registers). On ARM processors (including Apple Silicon), NEON instructions handle 4 elements per vector. This means that a single CPU instruction can perform 4 to 16 field multiplications simultaneously.\nNo overflow risk: Multiplying two 31-bit values produces at most a 62-bit result, which fits comfortably in a 64-bit register. This eliminates the need for multi-precision arithmetic or carry propagation, making modular reduction trivial.\nHigh two-adicity: The multiplicative group has order p - 1 = 2^{24} \\times 127𝑝 −1 =224 ×127, giving a two-adicity of 24. While seemingly small, this is not a limiting factor for multilinear polynomial commitment schemes like WHIR when utilizing interleaved Reed-Solomon codes. Furthermore, operations in the degree-5 extension field (\\mathbb{F}_{q}𝔽𝑞 where q = p^5𝑞 =𝑝5) provide the necessary 128 bits of security required by WHIR.\n\nBeyond raw arithmetic speed, KoalaBear was specifically chosen because the cube map x \\mapsto x^3𝑥 ↦𝑥3 is a permutation of the multiplicative group. This holds because \\gcd(3,\\; p - 1) = \\gcd(3,\\; 2^{24} \\times 127) = 1gcd(3, 𝑝 −1) =gcd(3, 224 ×127) =1. This property is important for Poseidon: the hash function needs an S-box (a non-linear substitution layer) that is a permutation polynomial over the field. Since the cube map is already a permutation, the S-box can use degree 3 — the smallest possible. A lower-degree S-box means fewer multiplications per round, which directly translates to faster hashing and fewer constraints inside the SNARK circuit. For comparison, other fields like BabyBear (p = 2^{31} - 2^{27} + 1𝑝 =231 −227 +1) require an S-box of degree 7, and BN254-based Poseidon uses degree 5.\nThe combination of a degree-3 S-box, high two-adicity, and SIMD-friendly element size makes KoalaBear an exceptionally well-suited field for this workload.\nProduction Scheme Parameters\nThe table below lists the full production configuration used until now for our lean consensus devnets. To make it easier to follow, the parameters are grouped by what part of the system they control.\nLifetime and Message\nThese parameters define the overall scope of a key and what it signs.\n\nParameter\nValue\nDescription\n\nKey lifetime\n2^{32}232 slots (~1632 years at 12-second slots)\nThe total number of slots a single key can be used for. Each slot consumes exactly one leaf of the Merkle tree, so the tree has 2^{32}232 leaves.\n\nMessage length\n32 bytes\nThe size of the data being signed. In practice this is a hash of the attestation or block data — always exactly 32 bytes.\n\nMessage Encoding (How a Message Becomes Chain Positions)\nRecall from the XMSS overview above that signing a message means revealing intermediate values in hash chains. But first, the message must be converted into a set of numbers that tell the signer where to reveal in each chain. This conversion is called the encoding, and these parameters control how it works.\nThe message is hashed together with some fresh randomness to produce 46 numbers (one per chain), each between 0 and 7. These numbers are the chunk values. The chunk value for a given chain tells the signer how many steps to walk into that chain from its secret starting point before revealing the value. The verifier then walks the remaining steps to the chain endpoint: with a maximum chain length of 7, a chunk value of 5 means the signer revealed the value 5 steps in, and the verifier hashes it the remaining 2 times (7 - 5) to reach the endpoint.\nThe critical security constraint is the target sum: the 46 chunk values must add up to exactly 200. This is what makes the encoding incomparable — no valid codeword can be reached from another by moving every chain in the same direction. Since an attacker who has seen a signature can only ever hash the revealed values forward (which increases a chunk value), they would have to decrease some other chunk to keep the sum at 200. Decreasing a chunk means inverting the hash, which is computationally infeasible. The fixed sum plus the one-wayness of the chains is what prevents forgery.\nIf the 46 chunk values were sampled uniformly, their expected sum would be about 161 (46 × 3.5). The target of 200 is deliberately set above this average: because the verifier only walks the remaining steps of each chain, a higher target sum means fewer hash evaluations at verification — here, 46 × 7 - 200 = 122 chain hashes in total, versus 161 if the target sat at the mean. To make the chunk values uniform in the first place (so the target is hit predictably), the message hash uses an aborting hypercube construction. It rejection-samples the hash output, discarding and re-hashing whenever an output element falls outside the uniform range. The signer then simply draws fresh randomness and re-encodes until the 46 values happen to sum to exactly 200, up to 100,000 attempts; in practice, a valid encoding is found well within that bound.\nNote: Because optimizing these hash functions in the SNARK context for signature aggregation is a highly active area of research, the exact underlying encoding algorithm remains a moving piece. The parameters below represent the current working configuration, but specific values may evolve as the cryptography is finalized for mainnet.\n\nParameter\nValue\nDescription\n\nNumber of parallel hash chains\n46\nThe message is encoded into 46 independent chunks, one per chain. More chains means more security but larger signatures.\n\nAlphabet size per chain\n8\nEach chunk value is between 0 and 7 (i.e., base 8). This determines the maximum depth of any single chain.\n\nMaximum chain length\n7 steps\nThe longest possible walk along a chain (alphabet size minus 1). The signer and verifier together never traverse more than 7 hash evaluations per chain.\n\nTarget sum\n200\nThe 46 chunk values must sum to exactly this number for the encoding to be valid. This is the anti-forgery (incomparability) mechanism.\n\nMaximum encoding attempts\n100,000\nUpper bound on how many times the signer tries different randomness to find a valid encoding.\n\nEncoding randomness\n7 field elements (28 bytes)\nThe fresh random value mixed into the message hash on each attempt. Included in the signature so the verifier can reproduce the encoding.\n\nMessage field-element length\n9 field elements (36 bytes)\nThe 32-byte message re-encoded as field elements and fed (together with the randomness and public parameter) into the message hash.\n\nHash Function and Internal Sizes\nThese parameters control the hash function used throughout the scheme. All sizes are expressed in field elements; each KoalaBear field element is 4 bytes, so multiplying by 4 gives the size in bytes.\n\nParameter\nValue\nDescription\n\nInternal hash function\nPoseidon1 over KoalaBear (width 24 and width 16)\nThe arithmetization-friendly permutation used for all tree hashing, chain hashing, and message hashing. It runs at width 24 (operating on 24 field elements at a time) for tree-node merging and the message-hash sponge, and at width 16 for the per-step chain hashing, which only needs to compress a single value.\n\nMessage-hash sponge rate / capacity\nrate 15 / capacity 9\nThe message hash runs the width-24 permutation as a sponge: 15 of the 24 state elements carry input/output data (the rate), and the remaining 9 are reserved for domain separation (the capacity). Tree and chain hashing instead run in compression mode rather than as a sponge.\n\nHash digest length\n8 field elements (248 bits)\nThe output size of each hash invocation. Every tree node, chain endpoint, and message hash is 248 bits. This targets roughly 128 bits of classical security and 64 bits of quantum security.\n\nPublic parameter length\n5 field elements (20 bytes)\nThe random per-validator value that is part of the public key and mixed into every hash to ensure independence between validators.\n\nSponge capacity\n9 field elements\nThe portion of the width-24 Poseidon1 sponge state reserved for domain separation. Combined with per-call tweaks, this ensures different uses of the hash (tree nodes, chain steps, message hashing) cannot collide across contexts.\n\nTree Structure and Key Derivation\n\nParameter\nValue\nDescription\n\nMerkle tree height\n32 levels (split into 16 top + 16 bottom)\nThe tree has 2^{32}232 leaves (one per slot). It is split into a top tree of height 16 and many bottom trees of height 16 each, so that only two bottom trees need to be in memory at a time.\n\nKey derivation PRF\nSHAKE128 (256-bit key)\nAll secret material (chain starting values, per-signature randomness) is derived deterministically from a single 32-byte master seed using SHAKE128. This means the validator only needs to back up one 32-byte value.\n\nSignature Aggregation via leanVM and pqSNARKs\nHash-based signatures do not natively support the public aggregation features we enjoy with BLS. With ~1 million validators each broadcasting a ~3.1 KiB signature, the bandwidth requirements for aggregators would easily exceed 3 GiB per slot, which is entirely unfeasible for Ethereum’s slot constraints.\nThe solution is to aggregate these synchronized many-time signatures using a succinct argument of knowledge (a pqSNARK). To handle this elegantly and efficiently, we utilize leanVM, a minimal, Cairo-inspired zkVM designed specifically for Ethereum’s post-quantum signature verification. leanVM is built on a highly optimized proving stack utilizing SuperSpartan with AIR-specific optimizations, Logup for bus interactions, and WHIR for multilinear polynomial commitments. Crucially, WHIR allows for simple polynomial stacking, avoiding the need to Merkle commit to each individual column and significantly reducing the final proof size.\nInstead of verifying a massive batch of signatures simultaneously in one giant circuit, leanVM uses recursive aggregation. The protocol partitions the signers into manageable groups, aggregators verify their XMSS signatures to create sub-proofs, and then recursively run the leanVM verifier inside the program to merge these sub-proofs into a single final proof.\nBecause the consensus layer must know exactly who participated to process rewards, inactivity leaks, fork choice weight, and slashing, the aggregate payload includes both the leanVM proof and a signer bitfield (similar to the bitlists used in current BLS attestations). The leanVM circuit is explicitly constrained to prove that valid signatures exist for the exact subset of public keys indicated by this accompanying bitfield.\nBased on recent benchmarks running on high-end consumer hardware (e.g., an M4 Max CPU), leanVM achieves a proving throughput of roughly 1k XMSS signatures per second. In its proven security regime—offering 123 bits of provable security via a degree-5 extension of the KoalaBear field—a 2-to-1 recursive proof takes less than a second to generate and results in a highly compact final proof size of roughly 128 KiB to 350 KiB depending on the PCS rate. This recursive approach scales well, making on-chain verification and network propagation highly practical for Ethereum’s slot budget.\nThe Hash Function: An Open Design Space\nBecause the verification process is dominated by hash function evaluations, the efficiency of our pqSNARK aggregator relies heavily on the chosen hash function.\nInitially, Poseidon2 emerged as a leading candidate. It operates natively over finite fields, making it highly optimized for modern arithmetization frameworks and zkVMs like leanVM. However, recent cryptanalysis and attack techniques targeting algebraic hash functions (such as those detailed in eprint 2026/306) are forcing us to reconsider relying solely on Poseidon2.\nBecause we have not made a final decision, the design of the Public Key Registry must remain flexible. To accommodate this, we may allow the generation of public keys using various hash functions—a design referred to as the multi-hash public key registry.\nCurrent Hash Candidates\n\nHash Function\nArithmetization Efficiency\nCryptanalytic Maturity\n\nSHA / BLAKE3\nLow (heavy bitwise operations)\nHigh (highly battle-tested)\n\nPoseidon1\nHigh (SNARK-friendly)\nMedium (subject to ongoing analysis)\n\nPoseidon2\nVery High (optimized for modern fields)\nLow (recent attacks raise concerns)\n\nThis directly impacts registry design: the registry must be hash-function-agile, potentially storing a hash function identifier alongside each public key so the network can support multiple hash functions during the transition and mandate migration if one is deprecated.\nPart 2: Registry Design Considerations\nRegistration Protocol Mechanics\nThe registration protocol itself requires concrete mechanics to ensure a smooth, secure, and sybil-resistant transition without overwhelming the Beacon Chain. Because this upgrade fundamentally changes validator identities, the lifecycle of a key registration must be carefully managed. Here is the proposed architecture for how validators will actually register their keys:\n\nDelivery and Authorization: To securely bind a post-quantum identity to an existing validator, the delivery mechanism will likely utilize a new consensus-layer operation (e.g., a PostQuantumRegistration message). This submission must be explicitly authorized to prove definitive ownership of the validator index. For validators with 0x01 or 0x02 execution-layer withdrawal credentials, this would involve an L1 signature from the withdrawal address. For legacy 0x00 credentials, it would require a signature from the currently active BLS key. Crucially, this registration message must also include a Proof of Possession—a single valid XMSS signature over the registration payload. Without this, the protocol would blindly accept 52 raw bytes, meaning a validator with a silently broken key generation setup wouldn’t discover the failure until the actual signing fork years later. Once both signatures are verified, the network accepts and binds the 52-byte XMSS public key to the validator record in the beacon state. To support hash-function agility, this binding is not permanent; the registration message should include a sequence number or version field to allow validators to update or rotate their keys in the future.\n\nPer-Block Processing Cap and State Growth: To protect the network from state bloat and computational spikes during a mass registration event, the protocol must enforce a strict processing queue. Similar to the existing validator activation and exit churn limits, we propose capping the number of registrations processed per slot (e.g., MAX_PQ_REGISTRATIONS_PER_BLOCK = 16). Registrations broadcast to the gossip network will sit in a local memory pool; block proposers will pack up to the maximum limit into their blocks. This ensures that block verification times remain predictably low and the resulting state growth is smoothed out over weeks or months, preventing sudden spikes in node resource requirements.\n\nIncentives and the Transition Timeline: A major risk of a phased rollout is a last-minute stampede right before BLS signatures are formally deprecated, which could overwhelm the processing queue and leave active validators unable to sign, threatening network finality. To avoid this, the rollout will incorporate mechanisms to encourage early action. Validators who participate in the early warmup phase could be granted priority placement in the eventual post-quantum activation queue. Alternatively, a modest, temporary boost to attestation rewards (e.g., a slight multiplier on the base reward) for early registrants could efficiently drive adoption. Finally, as the hard deadline approaches, the protocol could employ a stick approach—gradually applying an inactivity leak or initiating forced exits for validators who have failed to register a post-quantum key, ensuring the active set consists only of PQ-ready nodes before the final switch is flipped.\n\nHash Function Agility\nBecause the hash function is not yet finalized, the registry must be designed with agility in mind. One approach is to allow validators to register keys under different hash function identifiers, meaning each registry entry would carry the 52-byte public key along with a tag indicating the chosen hash function. If a function is later compromised, affected validators would be required to re-register. Alternatively, to ensure robust future-proofing without the friction of future re-registration, the protocol could enforce the use of two or three specific hash candidates (e.g., Poseidon1, BLAKE3, and SHA-256) from the start. In this scenario, every validator would perform key generation for each mandated hash function upfront, and the final value committed to the registry would simply be the concatenation of these multiple XMSS public keys.\nBecause keygen and registration are frontloaded, if one hash function is compromised, the network can quickly switch to an alternative without validators needing to regenerate keys from scratch. While this approach provides excellent future-proofing, there is a minor trade-off: the registered key size increases from 52 bytes to 104–156 bytes. Fortunately, the computational overhead for key generation is minimal. Since traditional bitwise hash functions (like SHA-256, BLAKE3, or Monolith) are orders of magnitude faster to compute on standard CPUs than algebraic hashes like Poseidon, generating these backup trees adds only a fraction of time to the baseline key generation process. Ultimately, this slight increase in storage and computation is a highly acceptable trade-off for the seamless agility it provides. These two solutions are just ideas with advantages and drawbacks for each, requiring further exploration.\nKey Lifetime and Activation Windows\nXMSS keys are inherently generated with an explicit activation window: a starting slot and a finite number of active slots dictated by the Merkle tree’s capacity. Because the cryptographic construction ties each signature to a specific sequential position, a key naturally cannot sign messages outside this window. Consequently, there is no need to explicitly record these bounds in the registry or enforce them at the protocol level; once a validator exhausts their available leaves, they simply lose the ability to produce valid signatures.\nFor memory efficiency, activation slots are aligned to boundaries of 65,536 slots (~9 days). This is transparent to the validator — the key generation tool handles the alignment automatically.\nSerialization\nAll data structures use SSZ (Simple Serialize), the standard serialization format for Ethereum’s consensus layer. The public key is a fixed-size 52-byte value, making it straightforward to include in the existing beacon state validator record alongside the current BLS key.\nPractical Considerations for Validators\nRegistering a post-quantum key is a one-time operation, but it involves generating a massive Merkle tree and securely storing the resulting material. Here is what validators should expect in practice compared to today’s operations:\n\nKey generation is computationally heavy but memory-light: The validator runs an offline tool that expands a 32-byte seed into the full XMSS tree. Because the tree has 2^{32}232 leaves, this involves billions of hash evaluations. The reference implementation parallelizes this across all available CPU cores using SIMD optimizations. While this process takes on the order of hours on a modern multi-core machine (e.g., 8-16 cores), thanks to the top-bottom tree strategy, it operates in \\mathcal{O}(\\sqrt{\\text{lifetime}})O(√lifetime) space. This means any standard machine with just a few megabytes of free RAM can generate keys. Because it involves the master secret, this one-time operation must be done on an air-gapped or cold-storage machine.\nThe secret vs. the operational key: Today, an encrypted BLS validator keystore is roughly a single kilobyte. In the PQ era, the actual cryptographic secret (the 32-byte PRF seed) remains tiny and must be fiercely guarded and backed up. Losing it means losing the ability to sign, with no recovery possible. However, the operational key file—which caches the non-secret top tree and the current bottom tree pair for fast, lightweight signing—is serialized in SSZ format and sits at around tens of megabytes. While significantly larger than a BLS key, this operational file fits easily on consumer SSDs.\nOngoing signing is lightweight: Once the key is generated and the operational file is loaded into the signing infrastructure, producing a signature for each slot requires only a handful of hash evaluations (walking 64 chains of at most 7 steps each, plus one Merkle path lookup). This is fast enough to run effortlessly on standard consumer hardware well within the 12-second slot budget.\nCommunity-led tooling: Building the key generation UX requires strong stakeholder engagement from day one. A major learning from the beacon chain launch is that relying solely on the EF to maintain the deposit-cli became a bottleneck over time. To ensure sustainable support, security audits, and feature iteration (like consolidations), we envision the PQ key generation tool being an open-source, community-maintained effort from the start, potentially incentivized by EF grants.\n\nWhat the validator actually submits to the registry is the 52-byte public key along with a single XMSS Proof of Possession signature. This proves end-to-end that the offline keygen worked perfectly. This submission can be done via a standard on-chain transaction, similar in spirit to the current BLS key deposit. The secret key never leaves the validator’s machine.\nOpen Questions and Future Work\n\nHash function finalization: Will Poseidon survive continued cryptanalysis, or will we need to fall back to SHA-3/BLAKE3 (at significant proving cost)?\n\nRegistry update mechanism: How should the state accommodate key rotation or re-registration if a validator needs to switch hash functions?\n\nAggregator economics: Who bears the computational cost of SNARK proving? Should aggregation be compensated via protocol rewards?\n\nCompatibility period: During the transition, should the protocol support both BLS and XMSS signatures simultaneously?\n\nScaling the registry: The current devnets support only hundreds of validators. Production Ethereum has ~1 million. How does the aggregation tree scale?\n\nPolynomial Commitment Optimization: We are currently relying on WHIR for our multilinear polynomial commitments due to its efficiency with small fields and recursive stacking. Can we further shrink proof sizes by refining our Reed-Solomon interleaving strategy or integrating alternative polynomial commitment schemes entirely?\n\nKey Generation UX and Tooling: How can we make the key generation process accessible and foolproof for solo stakers? Learning from the deposit-cli, how do we foster a community-owned, grant-incentivized open-source effort to build this critical infrastructure from day one?\n\nStandard Model vs. ROM for XMSS: There is an ongoing debate about shifting XMSS parameters from the standard model to the Random Oracle Model (ROM). While relying on the ROM is less conservative cryptographically, it would shrink the signature size below the IPv6 MTU limit and eliminate the need for multiple Poseidon widths (16 and 24). Furthermore, since the SNARK aggregator already relies on the ROM, standard-model XMSS might be unnecessarily strict. Should we lean into a stronger (more rounds) Poseidon and embrace the ROM to simplify the scheme?\n\nThe Finite Field Choice (KoalaBear vs. Goldilocks): While KoalaBear is extremely fast, its 31-bit size and low two-adicity (24) impose strict limits on proof size—currently capping leanVM at roughly 16M cycles and 2M Poseidons to prevent Logup multiplicity overflows. Migrating to a 64-bit field like Goldilocks would solve these overflow constraints, allow for larger proofs, support native storage of CL balances, and easily hit 128-bit security (via a Poseidon state of 8) with minimal WHIR grinding. The primary trade-off is proving speed, which is currently about 2x slower on Goldilocks. Should the protocol prioritize the capacity and elegance of Goldilocks, anticipating future performance optimizations?\n\n Ragged multi-instance GKR for Poseidon2b: one walk, unequal regions, no max-width padding\n\n Ethereum lessons from a live end-to-end PQ proof-native protocol\n\n 3\n\n 2\n\n 2\n\n read \n\n 16\n min\n\n post by potuz on Jun 3\n\n potuz\n\n I see this post as a two different things. One is to have a registry in advance to start preparing for Q-Day with time and not a posteriori when we are already in panic. The other is to propose a particular scheme, fields, hashing algos etc.\nI believe the first of the objectives is a clear no brainer that can be done right now, while the second may still require time, research and community vetting on deciding these schemes.\nWhy not just then register hashed BLS keys instead? BLS keys are already part of the operator’s workflow and are safe as long as they haven’t signed anything. We could just keep them and sign with them the move to PQ only after the PQ system has been fully chosen and vetted.\n\n post by 71104 on Jun 3\n\n 71104\n\nNot sure what you mean by this but remember that a CRQP can recover private BLS keys from the public ones.\nIf you’re proposing to record hashed public BLS keys then you’re effectively treating public BLS keys as secret keys and requiring that their owners don’t sign anything, which is pretty much impossible given that BLS pairs are used in the consensus algorithm.\n\n post by tcoratger on Jun 3\n\n tcoratger\n\n potuz\n\n Indeed, the post is divided into two parts, ordered in the reverse order of what you indicated in your reply, but that doesn’t change anything; you correctly identified the two parts.\nPart 1\nWe present the XMSS scheme and our plan for aggregation. Even though some eprint XMSS papers have been published before on eprint for the cryptographer community, we thought it is nice to present this here in a simple and intuitive way for Ethereum developers.\nIn this section, we also present our research on hashing, SNARK scheme for aggregation, fields, etc. As indicated throughout the post and in the open questions, all these topics remain widely open for alternative designs. Most of this research takes place here: lean Ethereum · GitHub and is open to public contributions, of course.\nTechnically speaking, even the signature scheme itself is not 100% confirmed because if someone comes up with a magical PQ signature scheme with much better aggregation properties, this is certainly something we have to consider.\nPart 2\nIn this second part, we present some approaches for an early post-quantum public key registry as a preparation step for validators (touching the cold storage, run the key generation algorithm, avoid a rush for key generation by doing this early). We can discuss the best way to achieve this, drawing on some of the ideas mentioned in the post, which will, of course, require consensus within the community.\nThe purpose of this registry is not to enshrine or invoke aggregation machinery; there will be no form of SNARK or anything similar. It will only be used for public key generation for XMSS. And precisely to anticipate a scenario where we might need to switch the hash function from Poseidon to something else, we propose a multi-hash public key registry so that validators would be natively prepared for a couple of hash functions in case we need to switch.\nSo if we summarize, the main objectives of the approach are:\n\nAuthenticating a quantum-safe identity upfront,\nHash function agility.\n\n post by 71104 on Jun 3\n\n 71104\n\nSay hello to zkMAC. \nTL;DR: do HMAC in a zkSTARK. It’s literally two hashes, smallest circuit ever, and once you build future Ethereum on a recursive zkSTARK framework you can aggregate as many signed transactions as you want and prove an entire block with a single proof.\n\n post by 0xjasonw on Jun 3\n\n 0xjasonw\n\nBro, it’s ZK-ACE :-).\nUnder JP Aumasson’s post on X about crypto agility, I created a thread discussing the advantages of identity-authorization separation model, which is the foundation of ZK-ACE.\nhere is the post: https://x.com/veorq/status/2062192304908029988\n\n post by potuz on Jun 3\n\n potuz\n\n tcoratger\n\n The point I’m making is that you can register today a quantum safe key that is uncontested to be safe and that is already part of the workflow of every operator. Using the same old tooling they already trust and use. Put it in a registry. And by the time the new consensus algo is ready to switch over to PQ, we use those keys to switch over. No need to agree early on any hashing algo nor any extra information, SHA is at least as good as every proposal.\n\n post by 71104 on Jun 3\n\n 71104\n\n At the very least we need to agree on the field where the key is defined, because if everyone commits to a key that’s uniformly distributed over, say, the 256-bit range, and later we decide to use, say, the BLS12-381 scalar field, it might be hard to switch between the two fields while maintaining the uniform distribution. Simple modular reduction wouldn’t work.\n\n post by uink45 on Jun 3\n\n uink45\n\n Hi @tcoratger, thanks for the post.\nFor validators using 0x01 or 0x02 withdrawal credentials, if the withdrawal address is a smart contract, then I don’t think it would be possible to generate a signature proving ownership for the PostQuantumRegistration message in the current design?\n\n post by opus-lux on Jun 4\n\n opus-lux\n\n Yeah love the post.\nI released something related to this recently on May 21st called WOTS-39. It’s a post quantum signing scheme that uses Winternitz One Time Signatures (WOTS+) with each public key being authorized by a Lamport chain hash pre image.\nAlong with WOTS-39 I have released three implementations:\n-ERC-4337 smart account on EVM (Deployed and tested)\n-EIP-7702 native EOA account upgrade on EVM (Deployed and tested)\n-A live bitcoin Signet for my bitcoin proposal, completely free to participate in.\nAll of this is live right now on my website: https://block_opuslux.ar.io\nAlso I think proposals like EIP-7701 that block the key path spend and allow for native post quantum security upgrades is a strong path forward. That way when the quantum threat arrives we will have the upgrades ready to go. Or cold storage long term wallets can adopt post quantum security early before the threat arrives.\n\n post by asn on Jun 5\n\n asn\n\nFrom a discussion with Gotti and Benedikt\nTwo ways to avoid storing this per-validator data:\n\nUse something like H(#validator_idx) as the public parameters (or basically any other unique identifier known ahead of time)\nMove the pp to the signature, instead of the per-validator registry: For example, pk’ = H_2(pk, pp) where pk is the old pk. Then just send pp as part of the signature.\n\n 16 days later\n\n post by b-wagn on Jun 22\n\n b-wagn\n\nI want to share some more insights regarding this question. The main discussion here is not standard model vs ROM. It is if we can get signature sizes below one MTU. With the parameters presented here, we can’t, but with more optimistic parameters, we can.\nI have summarized all pros and cons of such a sub-MTU parameter set in this note.\nIn general, I would always vote for a conservative choice of parameters, especially if we use Poseidon.\n\n 2 months later\n\n post by TMerlini on Aug 19\n\n TMerlini\n\n Nice write-up.\nOne thing worth pulling apart in the revocation section: implicit revocation by leaf exhaustion cleanly handles a key reaching end of life, but it doesn’t cover compromise. An XMSS key that is compromised while it still has unused leaves keeps producing valid signatures until those leaves run out, exhaustion gives you no early termination for the case you most want it for.\nYou flag that explicit slashing/compromise handling is undetailed; I’d argue that’s not a detail but\na second, distinct revocation path the registry probably needs: an explicit “authority ended at time\nT” record, independent of the leaf counter, so a compromised key can be retired before exhaustion.\nThe statefulness that gives you free end-of-life revocation is also what makes the compromise case harder to express, the key’s remaining validity is a property of its leaf position, not of a registry statement you can update. A design over stateless PQ signatures has the opposite tradeoff: no free exhaustion boundary, so revocation has to be explicit and anchored from the start, which turns out to cover compromise for the same reason.\nFor context, we’re exploring the same migration shape (pre-register a PQ key with proof of possession before an activation boundary) at the application layer rather than the consensus layer, with a consumer-defined cutoff instead of a fork and stateless ML-DSA/SLH-DSA — ERC-8373. Different enforcement layer, but the registration/rotation/revocation semantics you’re working through are the same design space, and this compromise-vs-exhaustion split is the one point where the stateful and stateless choices diverge most. Happy to compare notes.\n\n 19 days later\n\n post by chugarchugarr on Sep 7\n\n chugarchugarr\n\n I think the registry update question, the smart-contract withdrawal-address issue raised above, and the compromise/revocation point in the latest reply may all reduce to one state-transition rule.\nThe post already proposes a sequence/version field for re-registration, so the missing question seems less like “how do we version keys?” and more like:\nwhat authority is allowed to advance that version?\nI think the stable rule should be that the validator’s current withdrawal authority controls the PQ registry entry, while the registered PQ key is a duty credential rather than the authority that controls its own successor.\nConceptually:\n\nRegistry[v] = (generation, credentials, status)\n\naccept update(v, g+1) iff\n authorized_by_current_withdrawal_authority(v)\n && generation == Registry[v].generation + 1\n && new credentials satisfy their required PoP\n\nA revocation can advance the generation while installing no active duty credential, and a subsequent authorized registration can install a replacement. Once generation g+1 is accepted, generation g can never become current again.\nThis seems to cover several currently separate cases with the same transition:\n\nordinary rotation;\n\nre-registration after a hash-function change;\n\nexplicit compromise revocation before XMSS leaf exhaustion;\n\neventual replacement of the PQ duty scheme itself.\n\nIt also seems to resolve the smart-contract withdrawal credential problem. For execution withdrawal credentials, rather than requiring an “L1 signature from the withdrawal address,” registration/update could use the execution-request authorization pattern already used for validator control: the execution caller is the withdrawal authority, and the resulting request is processed by the CL.\nEIP-7002 already uses this pattern specifically so both EOAs and smart contracts that own withdrawal credentials can control validator actions without requiring a contract to manufacture an ECDSA signature.\nSo the lifecycle would be:\n\ncurrent Ethereum withdrawal authority\n -> authorizes registry generation\n\nregistry generation\n -> contains PQ duty credential(s)\n\nnext authorized generation\n -> rotates / replaces / revokes those credentials\n\nThis would keep the registry lifecycle independent of the still-open XMSS/hash/field/aggregation decisions. Those choices still need to be made for consensus, but they would no longer define validator ownership or re-registration semantics.\nGiven that the registry is now explicitly on the I* path, would it make sense to make this authorization + monotonic-generation rule part of the registry invariant before settling the remaining cryptographic parameters?\n\n Powered by Discourse","tokens":12132,"squid":"ink-research","role":"Deep Scholar","at":1791261708593,"hash":"1e76f016e883f65f1ff890957ee0b0d2164c97e6"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-v4-on-arc/25170/10","domain":"governance.aave.com","title":"[ARFC] Deploy Aave V4 on Arc - Governance / New Market - Aave","text":"GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 2\n\n read \n\n 7\n min\n\n Jun 19\n\n 10 / 10\n\n Sep 17\n\n Sep 18\n\n post by AaveLabs on Jun 19\n\n post by MconnectDAO on Jun 19\n\n post by LlamaRisk on Jun 19\n\n 2 months later\n\n post by AaveLabs on Sep 2\n\n post by Abel189 on Sep 4\n\n 10 days later\n\n post by AaveLabs on Sep 14\n\n post by AaveLabs on Sep 14\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n We are pleased to share that a network technical assessment review has been completed for Arc, covering the infrastructure components material to Aave’s operation on the network. The results are now published in the Risk Assessments category for governance review: AL Technical Assessment Aave <> Arc.\n\n post by AaveLabs on Sep 15\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave Labs is pleased to share that a technical assessment review has been completed for every asset in the first listing roster for the launch of Aave V4 on Arc. The asset issuers have been responsive and active in collaborating on the due diligence throughout the review, and the results are now published in the Risk Assessments category for governance review: Assessments.\n\nUSDC\nEURC\ncirBTC\nWETH\n\n post by AaveLabs on Sep 16\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave V4 on Arc has been successfully activated. The Protocol Security Council lifted the temporary halt placed on the market at deployment, following the same execution described in the previous update, and the market is now fully operational.\nThe instance is live and accessible through pro.aave.com, with USDC, EURC, cirBTC, and WETH available as reserves from launch, per the configuration and price feeds shared previously.\nFollow-up proposals will be raised to activate cross-chain governance on the network as soon as infrastructure is ready.\n\n AL Development Update | September 2026\n\n post by LlamaRisk on Sep 18\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nThis analysis covers the proposed assets for the initial V4 listing on Arc, specifically cross-chain assets already listed on Aave instances. This review provides an overview of key aspects, including chain-specific characteristics, bridging infrastructure, contract implementations, access control, liquidity, and other risk-related factors.\nThe key findings include that access control across all contracts, including both assets and bridge contracts in scope, relies on EOAs with keys held under Circle’s enterprise-grade key management program, which they claim maintains SOC 2 Type 2 attestation and follows NIST frameworks across the infrastructure. Further, no timelocks gate sensitive contract upgrades, consistent with Circle’s operational model for USDC, EURC, and cirBTC on other networks. For privileged roles, different assigned addresses were observed across the contracts, with no reassignments recorded.\nWETH has a different implementation as it is not natively minted on Arc, with its backing escrowed on Ethereum. Its owner and pauser slots remain unclaimed, meaning no party can currently modify its privileged roles or pause the token. However, the Cross Chain Token Service (CCTS) retains ownership assignment authority and can resolve the unclaimed state at any time. The WETH token and the bridge minter contracts for cirBTC, EURC, and WETH, represented by their respective TokenManager contracts, are beacon proxies that do not pin their own implementation and instead resolve it through the CCTS singleton at call time. Consequently, the CCTS owner can replace the implementation for all of these contracts on the chain in a single action. Additionally, WETH has no native blacklist and instead inherits the blacklist functionality of Arc USDC.\nBridge rate limits are also implemented for each asset via their respective bridge minter contracts.\nComparative table\n\nAsset\nIssuance\nBridge Verifier Setup\nRate Limits\nToken Upgradeable\n\nUSDC\nNative mint & bridgeable via CCTP\nCCTP (burn/mint), 2/2 attester set.\nPer-account limits via Circle Mint: Account-specific, Per-transfer limit via TokenMinterV2: 10M USDC\nYes (via FiatTokenProxy owner)\n\nEURC\nNative mint & bridgeable via CCTPx\nCircle Mint, permissioned mint/redemption and CCTPx (burn/mint), uses underlying CCTP 2/2 attester messaging.\nPer-account limits via Circle Mint: Account-specific, Per-transfer limit via TokenManager: 862K EURC, Per six-hour limits via TokenManager: Inbound/Outbound 4.31M EURC\nYes (via FiatTokenProxy owner)\n\ncirBTC\nNative mint & bridgeable via CCTPx\nCircle Mint, permissioned mint/redemption and CCTPx (burn/mint), uses underlying CCTP 2/2 attester messaging.\nPer-account limits via Circle Mint: Account-specific, Per-transfer limit via TokenManager: 9 cirBTC, Per six-hour limits via TokenManager: Inbound/Outbound 135 cirBTC\nYes (via FiatTokenProxy owner)\n\nWETH\nBridged via Circle’s new CCTPx protocol\nCCTPx (lock/mint), escrowed on Ethereum, uses underlying CCTP 2/2 attester messaging.\nPer-transfer limit via TokenManager: 500 WETH, Per six-hour limits via TokenManager: Inbound/Outbound 2,500 WETH\nYes (via the Cross Chain Token Service beacon and the token’s own owner slot is unclaimed)\n\nThe full assessment for each asset can be found in their corresponding threads:\n\nUSDC\nEURC\ncirBTC\nWETH\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Temp Check] Deploy Aave V4 on Arc\n\n New Market\n\n 5\n\n 837\n\n Jun 7\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n AL Technical Assessment Aave <> Arc\n\n Assessments\n\n 0\n\n 141\n\n Sep 14\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d","tokens":1533,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261715888,"hash":"049f8bdbb1d4816843feeac6ce6f67086d72fcbe"}
{"url":"https://ethresear.ch/t/exploring-the-design-space-for-a-post-quantum-public-key-registry-for-ethereum-validators/25040/14","domain":"ethresear.ch","title":"Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n read \n\n 16\n min\n\n Jun 1\n\n 14 / 14\n\n Sep 7\n\n 28d ago\n\n post by tcoratger on Jun 1\n\n tcoratger\n\n Authors: Thomas Coratger, Tom Wambsgans, Ladislaus, Thomas Thiery, Justin Drake\nCredits to Benedikt Wagner and Dmitry Khovratovich for all the theoretical work, ideas, discussions and papers that have been published on eprint and that are linked in this post.\nAs outlined in the Strawmap roadmap, securing Ethereum against the looming threat of large-scale quantum computers is a top priority. A critical milestone in this transition is migrating our proof-of-stake consensus from BLS signatures to a post-quantum (PQ) secure signature scheme.\nThis post aims to explore the concepts and design space for a Post-Quantum Public Key Registry. Importantly, the actual transition will happen in phases: the Public Key Registry fork will occur first, enabling validators to register their PQ keys, followed by the actual signature switch several forks later. This gradual rollout gives the network ample time to build state, monitor for vulnerabilities, and finalize the underlying cryptographic primitives. Ultimately, the discussions generated here will mature into a formal Ethereum Improvement Proposal (EIP).\nHistorical Context and the Need for a Registry\nIn the current proof-of-stake design, validator public keys (BLS12-381) are registered via the deposit contract on the execution layer and subsequently processed by the consensus layer. BLS signatures are wonderfully efficient for aggregation, but they rely on elliptic curve cryptography, which is completely broken by Shor’s algorithm.\nTransitioning to post-quantum signatures introduces significant operational difficulties for the network’s participants. Generating and securely storing these new keys requires validators to access their cold storage, execute new key generation scripts, and interact with their most sensitive cryptographic material. Because this is such a high-friction, high-stakes operational maneuver, we plan to decouple the registration of these keys from their active use in consensus. A dedicated Public Key Registry acts as a critical warmup phase, giving validators a low-pressure environment to securely manage their hardware setups and gradually commit to their post-quantum identities well in advance of the actual protocol upgrade.\nPart 1: Foundations — The Cryptographic Core: eXtended Merkle Signature Scheme (XMSS)\nWhen exploring post-quantum digital signatures, the cryptographic community generally categorizes the design space into a few main families: lattice-based, code-based, isogeny-based, multivariate, and hash-based. While solutions like lattice-based signatures (e.g., aggregating Falcon signatures via proof systems like LaBRADOR) are heavily studied, selecting secure parameters for them is highly complex, and their security proofs often rely on techniques with uncertain implications in a post-quantum setting.\nUltimately, hash-based signatures emerge as the strongest candidate for Ethereum. They stand out due to their conceptual simplicity, ease of implementation, and reliance on highly conservative, standard-model cryptographic assumptions (like basic collision and preimage resistance) rather than complex algebraic structures.\nHash-based signatures present two primary challenges: they do not natively support aggregation, and they require strict state management to prevent key reuse. While the aggregation problem must be solved separately via cryptographic proofs, the structured nature of Ethereum’s proof-of-stake consensus gives us a massive advantage for the latter: validators are required to sign exactly once per epoch.\nThis strict timeline allows us to bypass the significant verification overhead of fully stateless schemes (like SPHINCS+, which requires roughly 10x more hashes at verification) and instead leverage a synchronized (stateful) signature scheme. The eXtended Merkle Signature Scheme (XMSS) perfectly fits this model, tying each signature to a specific sequential position. Note that double signing under XMSS would break the key by leaking enough intermediate hash information to let an attacker forge signatures for that leaf.\nHow XMSS Works\nTo understand why XMSS is so effective, it helps to break down its construction step by step, starting from the basic properties of a hash function.\nThe Building Block: Hash Chains\nBecause cryptographic hash functions are one-way (preimage resistant), you cannot easily deduce an input from an output. A hash chain leverages this by taking a secret starting value (a private key) and hashing it repeatedly a predetermined number of times to produce a final value (the public key).\nIf a hash chain has 256 steps, revealing the intermediate hash at step 100 proves you know the secret, because a verifier can simply hash that value 156 more times to see if it matches the public key. This is the foundation of a One-Time Signature (OTS). To sign a message, you convert the message into a number (e.g., 100), and reveal the hash at that specific position in the chain.\nimage1136×188 9.5 KB\nParallel Chains for Security\nA single hash chain has a critical vulnerability: if you reveal the hash at position 100 to sign a message, an attacker could just hash your signature one more time to forge a signature for a message mapping to position 101.\nTo prevent this forgery, the scheme splits the message into multiple smaller chunks, using a parallel hash chain for each chunk, and enforces a strict mathematical constraint: a target sum. For a signature to be valid, the sum of all the chunk values (chain positions) must equal a specific, predetermined number.\nBecause of this constraint, if an attacker tries to forge a signature by hashing one chain forward (which increases its numerical value), the total sum of their forged signature will exceed the target. To rebalance the sum and produce a valid encoding, the attacker would be forced to decrease the value on another chain. Decreasing a value requires moving backward up the chain (reversing the hash function). Since cryptographic hash functions are strictly one-way (preimage resistant), this backward movement is computationally infeasible, rendering the W-OTS signature completely secure.\nimage1456×436 39.5 KB\nAttempted Forgery Analysis\n\nSignature Vector\nChain 0 (m_0'𝑚′0)\nChain 1 (m_1'𝑚′1)\nChain 2 (m_2'𝑚′2)\nChain 3 (m_3'𝑚′3)\nTarget Sum\n\n Original\n2\n3\n3\n1\n9\n\n Forged\n3\n 2 (Dropped)\n3\n1\n9\n\nWhy the Attack Fails\nTo forge the first chain forward (2 \\rightarrow 32 →3), the attacker simply hashes the revealed value one more time. However, this increases the total sum to 10, violating the protocol’s strict target constraint.\nTo maintain the mandatory target sum of 9, the attacker is forced to decrease a value on another chain (3 \\rightarrow 23 →2). Because cryptographic hash functions are strictly one-way (preimage resistant), moving backward up a chain to decrement a value is computationally infeasible, rendering the forged signature invalid.\nScaling to Many-Time Signatures\nBecause revealing these intermediate hashes inherently consumes the chains, this setup can only be used safely once. To sign thousands of blocks over a validator’s lifecycle, we need a many-time signature scheme.\nXMSS solves this by generating a massive sequence of independent One-Time Signature keypairs. The public keys of all these OTS instances are placed as the leaves of a massive Merkle tree. The root of this Merkle tree becomes the validator’s actual global public key—this is the small, compact data point that would be submitted to the Public Key Registry.\nimage1136×558 27.9 KB\nThe Signing and Verification Process\nWhen a validator needs to sign a block for a specific slot, they move to the next unused leaf in their tree. The final signature contains:\n\nThe OTS signature for the current message.\nThe specific OTS public key for that leaf.\nThe Merkle authentication path (the sibling hashes) connecting that leaf to the global Merkle root.\n\nimage1136×476 30.4 KB\nimage1136×368 25.9 KB\nThe verifier simply checks the OTS signature against the OTS public key, and then verifies the Merkle path to ensure that specific leaf is a legitimate part of the validator’s registered root.\nWhat Gets Registered: Key Sizes and Practical Impact\nNow that we understand the conceptual design of XMSS, the natural question for the registry is: what exactly does a validator need to submit, and how big is it?\nPublic Key: 52 bytes\nEach validator’s XMSS public key consists of two parts:\n\nComponent\nSize\nDescription\n\nMerkle root\n32 bytes\nThe root hash of the validator’s XMSS Merkle tree. This single value commits to all 2^{32}232 one-time signing leaves. It is the only thing a verifier needs to check that any individual signature belongs to this validator.\n\nPublic parameter\n20 bytes\nA random value generated once at key creation time. It is mixed into every hash computation (tree nodes, chain steps, message hashing) and serves two primary roles: it is essential for tight security proofs, and it provides domain separation across users so that an attacker cannot attack multiple validators in parallel when attempting a brute-force attack.\n\nTotal\n52 bytes\n\nFor comparison, a BLS12-381 public key is 48 bytes. The post-quantum public key is only 4 bytes larger — a remarkable result that means the registry’s per-validator storage overhead is negligible. At scale, registering 1 million validators requires storing only ~52 MiB of public keys in the state.\nSignature: 3,112 bytes\nEach per-slot XMSS signature contains:\n\nComponent\nSize\nDescription\n\nMerkle authentication path\n1,024 bytes\nThe list of sibling hashes needed to reconstruct the path from the used leaf up to the Merkle root. The tree has 32 levels, so there are 32 siblings, each 32 bytes. A verifier re-hashes this path and checks that the result matches the public key root.\n\nEncoding randomness\n28 bytes\nA per-signature random value that is mixed into the message hash to produce the target-sum encoding. While it allows the signer to resample until hitting the required target sum, its primary purpose is security: without this randomness, the scheme would only provide 64 bits of security, leaving the encoding vulnerable to a birthday attack.\n\nChain hash values\n2,048 bytes\nThe 64 intermediate hash chain values revealed by the signer — one per parallel chain. Each value is the point in its chain that corresponds to the encoded message chunk. The verifier walks each chain forward from this revealed value to the chain endpoint and checks consistency with the Merkle leaf.\n\nTotal\n3,112 bytes\n\nThis is significantly larger than a BLS signature (96 bytes), which is a reason why aggregation via SNARKs is essential (see next section).\nSecret Key: Manageable on Consumer Hardware\nA naive implementation would need to compute and store the full Merkle tree with 2^{32}232 leaves all at once—requiring terabytes of storage and immense memory. Instead, our reference implementation of the scheme uses a top-bottom tree strategy. It splits the massive tree into a top half (height 16) and 2^{16}216 bottom trees (height 16 each).\nimage1136×460 25.9 KB\nThis drops the spatial complexity of key generation and signing to \\mathcal{O}(\\sqrt{\\text{lifetime}})O(√lifetime), meaning it only requires a few megabytes of RAM and disk space. Instead of holding the whole structure, the validator only stores the top tree and caches a sliding window of just two bottom trees: the current bottom tree and the next bottom tree. Caching the next tree is a practical necessity; it ensures a seamless transition without missing any attestations when the current bottom tree is exhausted (every ~65,536 slots, or ~9 days).\nCrucially, these cached tree structures are not cryptographically sensitive. They are simply intermediate public hashes leading up to the global Merkle root. They can be stored in plaintext on standard disks. The only actual cryptographic secret is the 32-byte PRF seed.\nWhy KoalaBear?\nAll arithmetic in the scheme is performed over the KoalaBear prime field, with modulus:\n\np = 2^{31} - 2^{24} + 1\n𝑝=231−224+1\nThis is a 31-bit prime, meaning each field element fits in a single 32-bit word (4 bytes). The choice of a small field is deliberate and performance-critical. Because the XMSS scheme and the SNARK aggregator are both dominated by field arithmetic, every multiplication and addition must be as fast as possible.\nA 31-bit prime has three key advantages:\n\nSIMD parallelism: Four-byte elements pack tightly into CPU vector registers. On x86 processors, AVX2 instructions can process 8 field elements in parallel (256-bit registers), and AVX512 can process 16 at once (512-bit registers). On ARM processors (including Apple Silicon), NEON instructions handle 4 elements per vector. This means that a single CPU instruction can perform 4 to 16 field multiplications simultaneously.\nNo overflow risk: Multiplying two 31-bit values produces at most a 62-bit result, which fits comfortably in a 64-bit register. This eliminates the need for multi-precision arithmetic or carry propagation, making modular reduction trivial.\nHigh two-adicity: The multiplicative group has order p - 1 = 2^{24} \\times 127𝑝 −1 =224 ×127, giving a two-adicity of 24. While seemingly small, this is not a limiting factor for multilinear polynomial commitment schemes like WHIR when utilizing interleaved Reed-Solomon codes. Furthermore, operations in the degree-5 extension field (\\mathbb{F}_{q}𝔽𝑞 where q = p^5𝑞 =𝑝5) provide the necessary 128 bits of security required by WHIR.\n\nBeyond raw arithmetic speed, KoalaBear was specifically chosen because the cube map x \\mapsto x^3𝑥 ↦𝑥3 is a permutation of the multiplicative group. This holds because \\gcd(3,\\; p - 1) = \\gcd(3,\\; 2^{24} \\times 127) = 1gcd(3, 𝑝 −1) =gcd(3, 224 ×127) =1. This property is important for Poseidon: the hash function needs an S-box (a non-linear substitution layer) that is a permutation polynomial over the field. Since the cube map is already a permutation, the S-box can use degree 3 — the smallest possible. A lower-degree S-box means fewer multiplications per round, which directly translates to faster hashing and fewer constraints inside the SNARK circuit. For comparison, other fields like BabyBear (p = 2^{31} - 2^{27} + 1𝑝 =231 −227 +1) require an S-box of degree 7, and BN254-based Poseidon uses degree 5.\nThe combination of a degree-3 S-box, high two-adicity, and SIMD-friendly element size makes KoalaBear an exceptionally well-suited field for this workload.\nProduction Scheme Parameters\nThe table below lists the full production configuration used until now for our lean consensus devnets. To make it easier to follow, the parameters are grouped by what part of the system they control.\nLifetime and Message\nThese parameters define the overall scope of a key and what it signs.\n\nParameter\nValue\nDescription\n\nKey lifetime\n2^{32}232 slots (~1632 years at 12-second slots)\nThe total number of slots a single key can be used for. Each slot consumes exactly one leaf of the Merkle tree, so the tree has 2^{32}232 leaves.\n\nMessage length\n32 bytes\nThe size of the data being signed. In practice this is a hash of the attestation or block data — always exactly 32 bytes.\n\nMessage Encoding (How a Message Becomes Chain Positions)\nRecall from the XMSS overview above that signing a message means revealing intermediate values in hash chains. But first, the message must be converted into a set of numbers that tell the signer where to reveal in each chain. This conversion is called the encoding, and these parameters control how it works.\nThe message is hashed together with some fresh randomness to produce 46 numbers (one per chain), each between 0 and 7. These numbers are the chunk values. The chunk value for a given chain tells the signer how many steps to walk into that chain from its secret starting point before revealing the value. The verifier then walks the remaining steps to the chain endpoint: with a maximum chain length of 7, a chunk value of 5 means the signer revealed the value 5 steps in, and the verifier hashes it the remaining 2 times (7 - 5) to reach the endpoint.\nThe critical security constraint is the target sum: the 46 chunk values must add up to exactly 200. This is what makes the encoding incomparable — no valid codeword can be reached from another by moving every chain in the same direction. Since an attacker who has seen a signature can only ever hash the revealed values forward (which increases a chunk value), they would have to decrease some other chunk to keep the sum at 200. Decreasing a chunk means inverting the hash, which is computationally infeasible. The fixed sum plus the one-wayness of the chains is what prevents forgery.\nIf the 46 chunk values were sampled uniformly, their expected sum would be about 161 (46 × 3.5). The target of 200 is deliberately set above this average: because the verifier only walks the remaining steps of each chain, a higher target sum means fewer hash evaluations at verification — here, 46 × 7 - 200 = 122 chain hashes in total, versus 161 if the target sat at the mean. To make the chunk values uniform in the first place (so the target is hit predictably), the message hash uses an aborting hypercube construction. It rejection-samples the hash output, discarding and re-hashing whenever an output element falls outside the uniform range. The signer then simply draws fresh randomness and re-encodes until the 46 values happen to sum to exactly 200, up to 100,000 attempts; in practice, a valid encoding is found well within that bound.\nNote: Because optimizing these hash functions in the SNARK context for signature aggregation is a highly active area of research, the exact underlying encoding algorithm remains a moving piece. The parameters below represent the current working configuration, but specific values may evolve as the cryptography is finalized for mainnet.\n\nParameter\nValue\nDescription\n\nNumber of parallel hash chains\n46\nThe message is encoded into 46 independent chunks, one per chain. More chains means more security but larger signatures.\n\nAlphabet size per chain\n8\nEach chunk value is between 0 and 7 (i.e., base 8). This determines the maximum depth of any single chain.\n\nMaximum chain length\n7 steps\nThe longest possible walk along a chain (alphabet size minus 1). The signer and verifier together never traverse more than 7 hash evaluations per chain.\n\nTarget sum\n200\nThe 46 chunk values must sum to exactly this number for the encoding to be valid. This is the anti-forgery (incomparability) mechanism.\n\nMaximum encoding attempts\n100,000\nUpper bound on how many times the signer tries different randomness to find a valid encoding.\n\nEncoding randomness\n7 field elements (28 bytes)\nThe fresh random value mixed into the message hash on each attempt. Included in the signature so the verifier can reproduce the encoding.\n\nMessage field-element length\n9 field elements (36 bytes)\nThe 32-byte message re-encoded as field elements and fed (together with the randomness and public parameter) into the message hash.\n\nHash Function and Internal Sizes\nThese parameters control the hash function used throughout the scheme. All sizes are expressed in field elements; each KoalaBear field element is 4 bytes, so multiplying by 4 gives the size in bytes.\n\nParameter\nValue\nDescription\n\nInternal hash function\nPoseidon1 over KoalaBear (width 24 and width 16)\nThe arithmetization-friendly permutation used for all tree hashing, chain hashing, and message hashing. It runs at width 24 (operating on 24 field elements at a time) for tree-node merging and the message-hash sponge, and at width 16 for the per-step chain hashing, which only needs to compress a single value.\n\nMessage-hash sponge rate / capacity\nrate 15 / capacity 9\nThe message hash runs the width-24 permutation as a sponge: 15 of the 24 state elements carry input/output data (the rate), and the remaining 9 are reserved for domain separation (the capacity). Tree and chain hashing instead run in compression mode rather than as a sponge.\n\nHash digest length\n8 field elements (248 bits)\nThe output size of each hash invocation. Every tree node, chain endpoint, and message hash is 248 bits. This targets roughly 128 bits of classical security and 64 bits of quantum security.\n\nPublic parameter length\n5 field elements (20 bytes)\nThe random per-validator value that is part of the public key and mixed into every hash to ensure independence between validators.\n\nSponge capacity\n9 field elements\nThe portion of the width-24 Poseidon1 sponge state reserved for domain separation. Combined with per-call tweaks, this ensures different uses of the hash (tree nodes, chain steps, message hashing) cannot collide across contexts.\n\nTree Structure and Key Derivation\n\nParameter\nValue\nDescription\n\nMerkle tree height\n32 levels (split into 16 top + 16 bottom)\nThe tree has 2^{32}232 leaves (one per slot). It is split into a top tree of height 16 and many bottom trees of height 16 each, so that only two bottom trees need to be in memory at a time.\n\nKey derivation PRF\nSHAKE128 (256-bit key)\nAll secret material (chain starting values, per-signature randomness) is derived deterministically from a single 32-byte master seed using SHAKE128. This means the validator only needs to back up one 32-byte value.\n\nSignature Aggregation via leanVM and pqSNARKs\nHash-based signatures do not natively support the public aggregation features we enjoy with BLS. With ~1 million validators each broadcasting a ~3.1 KiB signature, the bandwidth requirements for aggregators would easily exceed 3 GiB per slot, which is entirely unfeasible for Ethereum’s slot constraints.\nThe solution is to aggregate these synchronized many-time signatures using a succinct argument of knowledge (a pqSNARK). To handle this elegantly and efficiently, we utilize leanVM, a minimal, Cairo-inspired zkVM designed specifically for Ethereum’s post-quantum signature verification. leanVM is built on a highly optimized proving stack utilizing SuperSpartan with AIR-specific optimizations, Logup for bus interactions, and WHIR for multilinear polynomial commitments. Crucially, WHIR allows for simple polynomial stacking, avoiding the need to Merkle commit to each individual column and significantly reducing the final proof size.\nInstead of verifying a massive batch of signatures simultaneously in one giant circuit, leanVM uses recursive aggregation. The protocol partitions the signers into manageable groups, aggregators verify their XMSS signatures to create sub-proofs, and then recursively run the leanVM verifier inside the program to merge these sub-proofs into a single final proof.\nBecause the consensus layer must know exactly who participated to process rewards, inactivity leaks, fork choice weight, and slashing, the aggregate payload includes both the leanVM proof and a signer bitfield (similar to the bitlists used in current BLS attestations). The leanVM circuit is explicitly constrained to prove that valid signatures exist for the exact subset of public keys indicated by this accompanying bitfield.\nBased on recent benchmarks running on high-end consumer hardware (e.g., an M4 Max CPU), leanVM achieves a proving throughput of roughly 1k XMSS signatures per second. In its proven security regime—offering 123 bits of provable security via a degree-5 extension of the KoalaBear field—a 2-to-1 recursive proof takes less than a second to generate and results in a highly compact final proof size of roughly 128 KiB to 350 KiB depending on the PCS rate. This recursive approach scales well, making on-chain verification and network propagation highly practical for Ethereum’s slot budget.\nThe Hash Function: An Open Design Space\nBecause the verification process is dominated by hash function evaluations, the efficiency of our pqSNARK aggregator relies heavily on the chosen hash function.\nInitially, Poseidon2 emerged as a leading candidate. It operates natively over finite fields, making it highly optimized for modern arithmetization frameworks and zkVMs like leanVM. However, recent cryptanalysis and attack techniques targeting algebraic hash functions (such as those detailed in eprint 2026/306) are forcing us to reconsider relying solely on Poseidon2.\nBecause we have not made a final decision, the design of the Public Key Registry must remain flexible. To accommodate this, we may allow the generation of public keys using various hash functions—a design referred to as the multi-hash public key registry.\nCurrent Hash Candidates\n\nHash Function\nArithmetization Efficiency\nCryptanalytic Maturity\n\nSHA / BLAKE3\nLow (heavy bitwise operations)\nHigh (highly battle-tested)\n\nPoseidon1\nHigh (SNARK-friendly)\nMedium (subject to ongoing analysis)\n\nPoseidon2\nVery High (optimized for modern fields)\nLow (recent attacks raise concerns)\n\nThis directly impacts registry design: the registry must be hash-function-agile, potentially storing a hash function identifier alongside each public key so the network can support multiple hash functions during the transition and mandate migration if one is deprecated.\nPart 2: Registry Design Considerations\nRegistration Protocol Mechanics\nThe registration protocol itself requires concrete mechanics to ensure a smooth, secure, and sybil-resistant transition without overwhelming the Beacon Chain. Because this upgrade fundamentally changes validator identities, the lifecycle of a key registration must be carefully managed. Here is the proposed architecture for how validators will actually register their keys:\n\nDelivery and Authorization: To securely bind a post-quantum identity to an existing validator, the delivery mechanism will likely utilize a new consensus-layer operation (e.g., a PostQuantumRegistration message). This submission must be explicitly authorized to prove definitive ownership of the validator index. For validators with 0x01 or 0x02 execution-layer withdrawal credentials, this would involve an L1 signature from the withdrawal address. For legacy 0x00 credentials, it would require a signature from the currently active BLS key. Crucially, this registration message must also include a Proof of Possession—a single valid XMSS signature over the registration payload. Without this, the protocol would blindly accept 52 raw bytes, meaning a validator with a silently broken key generation setup wouldn’t discover the failure until the actual signing fork years later. Once both signatures are verified, the network accepts and binds the 52-byte XMSS public key to the validator record in the beacon state. To support hash-function agility, this binding is not permanent; the registration message should include a sequence number or version field to allow validators to update or rotate their keys in the future.\n\nPer-Block Processing Cap and State Growth: To protect the network from state bloat and computational spikes during a mass registration event, the protocol must enforce a strict processing queue. Similar to the existing validator activation and exit churn limits, we propose capping the number of registrations processed per slot (e.g., MAX_PQ_REGISTRATIONS_PER_BLOCK = 16). Registrations broadcast to the gossip network will sit in a local memory pool; block proposers will pack up to the maximum limit into their blocks. This ensures that block verification times remain predictably low and the resulting state growth is smoothed out over weeks or months, preventing sudden spikes in node resource requirements.\n\nIncentives and the Transition Timeline: A major risk of a phased rollout is a last-minute stampede right before BLS signatures are formally deprecated, which could overwhelm the processing queue and leave active validators unable to sign, threatening network finality. To avoid this, the rollout will incorporate mechanisms to encourage early action. Validators who participate in the early warmup phase could be granted priority placement in the eventual post-quantum activation queue. Alternatively, a modest, temporary boost to attestation rewards (e.g., a slight multiplier on the base reward) for early registrants could efficiently drive adoption. Finally, as the hard deadline approaches, the protocol could employ a stick approach—gradually applying an inactivity leak or initiating forced exits for validators who have failed to register a post-quantum key, ensuring the active set consists only of PQ-ready nodes before the final switch is flipped.\n\nHash Function Agility\nBecause the hash function is not yet finalized, the registry must be designed with agility in mind. One approach is to allow validators to register keys under different hash function identifiers, meaning each registry entry would carry the 52-byte public key along with a tag indicating the chosen hash function. If a function is later compromised, affected validators would be required to re-register. Alternatively, to ensure robust future-proofing without the friction of future re-registration, the protocol could enforce the use of two or three specific hash candidates (e.g., Poseidon1, BLAKE3, and SHA-256) from the start. In this scenario, every validator would perform key generation for each mandated hash function upfront, and the final value committed to the registry would simply be the concatenation of these multiple XMSS public keys.\nBecause keygen and registration are frontloaded, if one hash function is compromised, the network can quickly switch to an alternative without validators needing to regenerate keys from scratch. While this approach provides excellent future-proofing, there is a minor trade-off: the registered key size increases from 52 bytes to 104–156 bytes. Fortunately, the computational overhead for key generation is minimal. Since traditional bitwise hash functions (like SHA-256, BLAKE3, or Monolith) are orders of magnitude faster to compute on standard CPUs than algebraic hashes like Poseidon, generating these backup trees adds only a fraction of time to the baseline key generation process. Ultimately, this slight increase in storage and computation is a highly acceptable trade-off for the seamless agility it provides. These two solutions are just ideas with advantages and drawbacks for each, requiring further exploration.\nKey Lifetime and Activation Windows\nXMSS keys are inherently generated with an explicit activation window: a starting slot and a finite number of active slots dictated by the Merkle tree’s capacity. Because the cryptographic construction ties each signature to a specific sequential position, a key naturally cannot sign messages outside this window. Consequently, there is no need to explicitly record these bounds in the registry or enforce them at the protocol level; once a validator exhausts their available leaves, they simply lose the ability to produce valid signatures.\nFor memory efficiency, activation slots are aligned to boundaries of 65,536 slots (~9 days). This is transparent to the validator — the key generation tool handles the alignment automatically.\nSerialization\nAll data structures use SSZ (Simple Serialize), the standard serialization format for Ethereum’s consensus layer. The public key is a fixed-size 52-byte value, making it straightforward to include in the existing beacon state validator record alongside the current BLS key.\nPractical Considerations for Validators\nRegistering a post-quantum key is a one-time operation, but it involves generating a massive Merkle tree and securely storing the resulting material. Here is what validators should expect in practice compared to today’s operations:\n\nKey generation is computationally heavy but memory-light: The validator runs an offline tool that expands a 32-byte seed into the full XMSS tree. Because the tree has 2^{32}232 leaves, this involves billions of hash evaluations. The reference implementation parallelizes this across all available CPU cores using SIMD optimizations. While this process takes on the order of hours on a modern multi-core machine (e.g., 8-16 cores), thanks to the top-bottom tree strategy, it operates in \\mathcal{O}(\\sqrt{\\text{lifetime}})O(√lifetime) space. This means any standard machine with just a few megabytes of free RAM can generate keys. Because it involves the master secret, this one-time operation must be done on an air-gapped or cold-storage machine.\nThe secret vs. the operational key: Today, an encrypted BLS validator keystore is roughly a single kilobyte. In the PQ era, the actual cryptographic secret (the 32-byte PRF seed) remains tiny and must be fiercely guarded and backed up. Losing it means losing the ability to sign, with no recovery possible. However, the operational key file—which caches the non-secret top tree and the current bottom tree pair for fast, lightweight signing—is serialized in SSZ format and sits at around tens of megabytes. While significantly larger than a BLS key, this operational file fits easily on consumer SSDs.\nOngoing signing is lightweight: Once the key is generated and the operational file is loaded into the signing infrastructure, producing a signature for each slot requires only a handful of hash evaluations (walking 64 chains of at most 7 steps each, plus one Merkle path lookup). This is fast enough to run effortlessly on standard consumer hardware well within the 12-second slot budget.\nCommunity-led tooling: Building the key generation UX requires strong stakeholder engagement from day one. A major learning from the beacon chain launch is that relying solely on the EF to maintain the deposit-cli became a bottleneck over time. To ensure sustainable support, security audits, and feature iteration (like consolidations), we envision the PQ key generation tool being an open-source, community-maintained effort from the start, potentially incentivized by EF grants.\n\nWhat the validator actually submits to the registry is the 52-byte public key along with a single XMSS Proof of Possession signature. This proves end-to-end that the offline keygen worked perfectly. This submission can be done via a standard on-chain transaction, similar in spirit to the current BLS key deposit. The secret key never leaves the validator’s machine.\nOpen Questions and Future Work\n\nHash function finalization: Will Poseidon survive continued cryptanalysis, or will we need to fall back to SHA-3/BLAKE3 (at significant proving cost)?\n\nRegistry update mechanism: How should the state accommodate key rotation or re-registration if a validator needs to switch hash functions?\n\nAggregator economics: Who bears the computational cost of SNARK proving? Should aggregation be compensated via protocol rewards?\n\nCompatibility period: During the transition, should the protocol support both BLS and XMSS signatures simultaneously?\n\nScaling the registry: The current devnets support only hundreds of validators. Production Ethereum has ~1 million. How does the aggregation tree scale?\n\nPolynomial Commitment Optimization: We are currently relying on WHIR for our multilinear polynomial commitments due to its efficiency with small fields and recursive stacking. Can we further shrink proof sizes by refining our Reed-Solomon interleaving strategy or integrating alternative polynomial commitment schemes entirely?\n\nKey Generation UX and Tooling: How can we make the key generation process accessible and foolproof for solo stakers? Learning from the deposit-cli, how do we foster a community-owned, grant-incentivized open-source effort to build this critical infrastructure from day one?\n\nStandard Model vs. ROM for XMSS: There is an ongoing debate about shifting XMSS parameters from the standard model to the Random Oracle Model (ROM). While relying on the ROM is less conservative cryptographically, it would shrink the signature size below the IPv6 MTU limit and eliminate the need for multiple Poseidon widths (16 and 24). Furthermore, since the SNARK aggregator already relies on the ROM, standard-model XMSS might be unnecessarily strict. Should we lean into a stronger (more rounds) Poseidon and embrace the ROM to simplify the scheme?\n\nThe Finite Field Choice (KoalaBear vs. Goldilocks): While KoalaBear is extremely fast, its 31-bit size and low two-adicity (24) impose strict limits on proof size—currently capping leanVM at roughly 16M cycles and 2M Poseidons to prevent Logup multiplicity overflows. Migrating to a 64-bit field like Goldilocks would solve these overflow constraints, allow for larger proofs, support native storage of CL balances, and easily hit 128-bit security (via a Poseidon state of 8) with minimal WHIR grinding. The primary trade-off is proving speed, which is currently about 2x slower on Goldilocks. Should the protocol prioritize the capacity and elegance of Goldilocks, anticipating future performance optimizations?\n\n Ragged multi-instance GKR for Poseidon2b: one walk, unequal regions, no max-width padding\n\n Ethereum lessons from a live end-to-end PQ proof-native protocol\n\n 3\n\n 2\n\n 2\n\n read \n\n 16\n min\n\n post by potuz on Jun 3\n\n potuz\n\n I see this post as a two different things. One is to have a registry in advance to start preparing for Q-Day with time and not a posteriori when we are already in panic. The other is to propose a particular scheme, fields, hashing algos etc.\nI believe the first of the objectives is a clear no brainer that can be done right now, while the second may still require time, research and community vetting on deciding these schemes.\nWhy not just then register hashed BLS keys instead? BLS keys are already part of the operator’s workflow and are safe as long as they haven’t signed anything. We could just keep them and sign with them the move to PQ only after the PQ system has been fully chosen and vetted.\n\n post by 71104 on Jun 3\n\n 71104\n\nNot sure what you mean by this but remember that a CRQP can recover private BLS keys from the public ones.\nIf you’re proposing to record hashed public BLS keys then you’re effectively treating public BLS keys as secret keys and requiring that their owners don’t sign anything, which is pretty much impossible given that BLS pairs are used in the consensus algorithm.\n\n post by tcoratger on Jun 3\n\n tcoratger\n\n potuz\n\n Indeed, the post is divided into two parts, ordered in the reverse order of what you indicated in your reply, but that doesn’t change anything; you correctly identified the two parts.\nPart 1\nWe present the XMSS scheme and our plan for aggregation. Even though some eprint XMSS papers have been published before on eprint for the cryptographer community, we thought it is nice to present this here in a simple and intuitive way for Ethereum developers.\nIn this section, we also present our research on hashing, SNARK scheme for aggregation, fields, etc. As indicated throughout the post and in the open questions, all these topics remain widely open for alternative designs. Most of this research takes place here: lean Ethereum · GitHub and is open to public contributions, of course.\nTechnically speaking, even the signature scheme itself is not 100% confirmed because if someone comes up with a magical PQ signature scheme with much better aggregation properties, this is certainly something we have to consider.\nPart 2\nIn this second part, we present some approaches for an early post-quantum public key registry as a preparation step for validators (touching the cold storage, run the key generation algorithm, avoid a rush for key generation by doing this early). We can discuss the best way to achieve this, drawing on some of the ideas mentioned in the post, which will, of course, require consensus within the community.\nThe purpose of this registry is not to enshrine or invoke aggregation machinery; there will be no form of SNARK or anything similar. It will only be used for public key generation for XMSS. And precisely to anticipate a scenario where we might need to switch the hash function from Poseidon to something else, we propose a multi-hash public key registry so that validators would be natively prepared for a couple of hash functions in case we need to switch.\nSo if we summarize, the main objectives of the approach are:\n\nAuthenticating a quantum-safe identity upfront,\nHash function agility.\n\n post by 71104 on Jun 3\n\n 71104\n\nSay hello to zkMAC. \nTL;DR: do HMAC in a zkSTARK. It’s literally two hashes, smallest circuit ever, and once you build future Ethereum on a recursive zkSTARK framework you can aggregate as many signed transactions as you want and prove an entire block with a single proof.\n\n post by 0xjasonw on Jun 3\n\n 0xjasonw\n\nBro, it’s ZK-ACE :-).\nUnder JP Aumasson’s post on X about crypto agility, I created a thread discussing the advantages of identity-authorization separation model, which is the foundation of ZK-ACE.\nhere is the post: https://x.com/veorq/status/2062192304908029988\n\n post by potuz on Jun 3\n\n potuz\n\n tcoratger\n\n The point I’m making is that you can register today a quantum safe key that is uncontested to be safe and that is already part of the workflow of every operator. Using the same old tooling they already trust and use. Put it in a registry. And by the time the new consensus algo is ready to switch over to PQ, we use those keys to switch over. No need to agree early on any hashing algo nor any extra information, SHA is at least as good as every proposal.\n\n post by 71104 on Jun 3\n\n 71104\n\n At the very least we need to agree on the field where the key is defined, because if everyone commits to a key that’s uniformly distributed over, say, the 256-bit range, and later we decide to use, say, the BLS12-381 scalar field, it might be hard to switch between the two fields while maintaining the uniform distribution. Simple modular reduction wouldn’t work.\n\n post by uink45 on Jun 3\n\n uink45\n\n Hi @tcoratger, thanks for the post.\nFor validators using 0x01 or 0x02 withdrawal credentials, if the withdrawal address is a smart contract, then I don’t think it would be possible to generate a signature proving ownership for the PostQuantumRegistration message in the current design?\n\n post by opus-lux on Jun 4\n\n opus-lux\n\n Yeah love the post.\nI released something related to this recently on May 21st called WOTS-39. It’s a post quantum signing scheme that uses Winternitz One Time Signatures (WOTS+) with each public key being authorized by a Lamport chain hash pre image.\nAlong with WOTS-39 I have released three implementations:\n-ERC-4337 smart account on EVM (Deployed and tested)\n-EIP-7702 native EOA account upgrade on EVM (Deployed and tested)\n-A live bitcoin Signet for my bitcoin proposal, completely free to participate in.\nAll of this is live right now on my website: https://block_opuslux.ar.io\nAlso I think proposals like EIP-7701 that block the key path spend and allow for native post quantum security upgrades is a strong path forward. That way when the quantum threat arrives we will have the upgrades ready to go. Or cold storage long term wallets can adopt post quantum security early before the threat arrives.\n\n post by asn on Jun 5\n\n asn\n\nFrom a discussion with Gotti and Benedikt\nTwo ways to avoid storing this per-validator data:\n\nUse something like H(#validator_idx) as the public parameters (or basically any other unique identifier known ahead of time)\nMove the pp to the signature, instead of the per-validator registry: For example, pk’ = H_2(pk, pp) where pk is the old pk. Then just send pp as part of the signature.\n\n 16 days later\n\n post by b-wagn on Jun 22\n\n b-wagn\n\nI want to share some more insights regarding this question. The main discussion here is not standard model vs ROM. It is if we can get signature sizes below one MTU. With the parameters presented here, we can’t, but with more optimistic parameters, we can.\nI have summarized all pros and cons of such a sub-MTU parameter set in this note.\nIn general, I would always vote for a conservative choice of parameters, especially if we use Poseidon.\n\n 2 months later\n\n post by TMerlini on Aug 19\n\n TMerlini\n\n Nice write-up.\nOne thing worth pulling apart in the revocation section: implicit revocation by leaf exhaustion cleanly handles a key reaching end of life, but it doesn’t cover compromise. An XMSS key that is compromised while it still has unused leaves keeps producing valid signatures until those leaves run out, exhaustion gives you no early termination for the case you most want it for.\nYou flag that explicit slashing/compromise handling is undetailed; I’d argue that’s not a detail but\na second, distinct revocation path the registry probably needs: an explicit “authority ended at time\nT” record, independent of the leaf counter, so a compromised key can be retired before exhaustion.\nThe statefulness that gives you free end-of-life revocation is also what makes the compromise case harder to express, the key’s remaining validity is a property of its leaf position, not of a registry statement you can update. A design over stateless PQ signatures has the opposite tradeoff: no free exhaustion boundary, so revocation has to be explicit and anchored from the start, which turns out to cover compromise for the same reason.\nFor context, we’re exploring the same migration shape (pre-register a PQ key with proof of possession before an activation boundary) at the application layer rather than the consensus layer, with a consumer-defined cutoff instead of a fork and stateless ML-DSA/SLH-DSA — ERC-8373. Different enforcement layer, but the registration/rotation/revocation semantics you’re working through are the same design space, and this compromise-vs-exhaustion split is the one point where the stateful and stateless choices diverge most. Happy to compare notes.\n\n 19 days later\n\n post by chugarchugarr on Sep 7\n\n chugarchugarr\n\n I think the registry update question, the smart-contract withdrawal-address issue raised above, and the compromise/revocation point in the latest reply may all reduce to one state-transition rule.\nThe post already proposes a sequence/version field for re-registration, so the missing question seems less like “how do we version keys?” and more like:\nwhat authority is allowed to advance that version?\nI think the stable rule should be that the validator’s current withdrawal authority controls the PQ registry entry, while the registered PQ key is a duty credential rather than the authority that controls its own successor.\nConceptually:\n\nRegistry[v] = (generation, credentials, status)\n\naccept update(v, g+1) iff\n authorized_by_current_withdrawal_authority(v)\n && generation == Registry[v].generation + 1\n && new credentials satisfy their required PoP\n\nA revocation can advance the generation while installing no active duty credential, and a subsequent authorized registration can install a replacement. Once generation g+1 is accepted, generation g can never become current again.\nThis seems to cover several currently separate cases with the same transition:\n\nordinary rotation;\n\nre-registration after a hash-function change;\n\nexplicit compromise revocation before XMSS leaf exhaustion;\n\neventual replacement of the PQ duty scheme itself.\n\nIt also seems to resolve the smart-contract withdrawal credential problem. For execution withdrawal credentials, rather than requiring an “L1 signature from the withdrawal address,” registration/update could use the execution-request authorization pattern already used for validator control: the execution caller is the withdrawal authority, and the resulting request is processed by the CL.\nEIP-7002 already uses this pattern specifically so both EOAs and smart contracts that own withdrawal credentials can control validator actions without requiring a contract to manufacture an ECDSA signature.\nSo the lifecycle would be:\n\ncurrent Ethereum withdrawal authority\n -> authorizes registry generation\n\nregistry generation\n -> contains PQ duty credential(s)\n\nnext authorized generation\n -> rotates / replaces / revokes those credentials\n\nThis would keep the registry lifecycle independent of the still-open XMSS/hash/field/aggregation decisions. Those choices still need to be made for consensus, but they would no longer define validator ownership or re-registration semantics.\nGiven that the registry is now explicitly on the I* path, would it make sense to make this authorization + monotonic-generation rule part of the registry invariant before settling the remaining cryptographic parameters?\n\n Powered by Discourse","tokens":12109,"squid":"ink-research","role":"Deep Scholar","at":1791261719057,"hash":"98bd36daa2981cc9e4c00b5de33b661c865116dd"}
{"url":"https://ethereum.org/wallets/find-wallet/mew-wallet/","domain":"ethereum.org","title":"MEW wallet | ⁦ethereum.org⁩","text":"New to cryptoNFTsMEW walletMobileEnglish, Russian, ChineseSwap fee: variableVisit website (opens in a new tab)Twitter (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedToken importingGas fee customizationRPC importingMEW wallet info updated on 3/19/2025Similar walletsZerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerCoinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%MetaMaskFinanceNFTsMobile · BrowserEnglish · Amharic Swap/bridge fee: 0.875%, Buy/sell fee: 1%Gem WalletDeveloperNFTsDesktop · MobileEnglish · Spanish Swap fee: 0%, Buy fee: set by the provider","tokens":286,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261719105,"hash":"2d50decdc10107ff6d5f40f56dd280e3e53d1225"}
{"url":"https://ethereum.org/wallets/find-wallet/coinbase-wallet/","domain":"ethereum.org","title":"Coinbase Wallet | ⁦ethereum.org⁩","text":"New to cryptoFinanceNFTsCoinbase WalletMobile · BrowserEnglish, German, Spanish, French, Japanese, Italian, Brazilian Portuguese, Russian, Chinese, Turkish, ThaiSwap fee: 1%Visit website (opens in a new tab)Twitter (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityPersonal ownershipOpen sourcePrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationCoinbase Wallet info updated on 11/15/2022Similar walletsZerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerRainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%Coin98 Super WalletFinanceNFTsMobile · BrowserEnglish · Vietnamese Swap fee: 0.5% (0.1% for stablecoins)TahoFinanceNFTsBrowserEnglish Swap fee: 0.5%SafeFinanceNFTsMobileEnglish Swap fee: 0.05% – 0.7%, Staking fee: 20% of rewards","tokens":299,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261729046,"hash":"57c96cfc1b8f837a4a9a30c67994af8959235cdd"}
{"url":"https://forum.openzeppelin.com/t/clarification-on-override-keyword-usage-in-erc20-functions-name-symbol-decimals/42427/2","domain":"forum.openzeppelin.com","title":"Clarification on override Keyword Usage in ERC20 Functions (name, symbol, decimals) - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2024\n\n 2 / 3\n\n Dec 2024\n\n Dec 2024\n\n post by armgit5 on Dec 3, 2024\n\n armgit5\n\n I have encountered a potential concern regarding the use of the override keyword in the name, symbol, and decimals functions of the ERC20 contract. According to best practices, the override keyword should be used to ensure proper method overriding and prevent subtle bugs. However, I have noticed that these functions work both with and without the override keyword.\nI would like clarification on whether the absence of the override keyword in these functions could lead to any potential bugs or unexpected behavior during smart contract development. Below are the relevant code snippets for comparison:\nfunction name() public view virtual returns (string memory) { ... }\n// vs\nfunction name() public view virtual override returns (string memory) { ... }\n\nfunction symbol() public view virtual returns (string memory) { ... }\n// vs\nfunction symbol() public view virtual override returns (string memory) { ... }\n\nfunction decimals() public view virtual returns (uint8) { ... } \n// vs\nfunction decimals() public view virtual override returns (uint8) { ... }\n\nEnvironment:\nI am using OpenZeppelin Contracts in my project.\nI appreciate your insights and assistance on this matter.\n\n 2\n\n post by ernestognw on Dec 3, 2024\n\n ernestognw\n\n OpenZeppelin Team\n\n Hey @armgit5, thanks for sharing your question.\nIndeed, the ERC20 contract doesn't use the override keyword because no security concerns arise from not using it in this case (when you inherit from an interface and implement its functions). Although you can specify it, we considered it an unnecessary overhead.\nOn the opposite, Solidity will require you to specify an override(..., ...) if you're using our ERC20 and another extension that implements a function twice. In that case, the override becomes explicit but the order of execution is defined by Solidity's linearization\nHope this helps\n\n post by armgit5 on Dec 5, 2024\n\n armgit5\n\n Hi @ernestognw, thank you for the clear explanation about override in multiple inheritance! It makes perfect sense that specifying override is optional in single inheritance, as it avoids unnecessary overhead. Your clarification on Solidity’s linearization determining the execution order is extremely helpful. I truly appreciate your insights so much \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n // The following functions are overrides required by Solidity\n\n Contracts\n\n 4\n\n 2.7k\n\n Oct 2025\n\n Override approve in OpenZeppelin Contracts version 2.x\n\n Contracts\n\n erc20\n\n 4\n\n 2.6k\n\n Nov 2020\n\n What does it look like to override the decimals function?\n\n Contracts\n\n erc20\n\n 6\n\n 5.7k\n\n Nov 2021\n\n “foo function” the override section of erc20 detailed?\n\n Contracts\n\n erc20,proxies,upgrades,crypto-trends,tutorial\n\n 0\n\n 679\n\n May 2021\n\n Changing name of ERC20 token in OpenZeppelin Contracts 3.x\n\n Contracts\n\n 5\n\n 3.0k\n\n Nov 2020","tokens":765,"squid":"ink-security_audits","role":"Sentinel","at":1791261732413,"hash":"13ff3c4a34c4d388bbc12c07d6b91b694f5a9ed8"}
{"url":"https://ethereum.org/wallets/find-wallet/zerion-wallet/","domain":"ethereum.org","title":"Zerion Wallet | ⁦ethereum.org⁩","text":"New to cryptoDeveloperFinanceNFTsZerion WalletDesktop · Mobile · BrowserEnglish, Russian, Turkish, Spanish, German, Dutch, Korean, Croatian, Portuguese, Japanese, Italian, French, Chinese, IndonesianSwap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerVisit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationZerion Wallet info updated on 9/26/2024Similar walletsOneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%AmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%Coinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the provider","tokens":326,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261742012,"hash":"7d18828bdab122a7876988edb9c6540b6fe69ee6"}
{"url":"https://forum.openzeppelin.com/t/what-does-it-look-like-to-override-the-decimals-function/9581/1","domain":"forum.openzeppelin.com","title":"What does it look like to override the decimals function? - Support / Contracts - OpenZeppelin Forum","text":"What does it look like to override the decimals function? \n\n SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n May 2021\n\n 1 / 7\n\n May 2021\n\n Nov 2021\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n What does it look like to override the decimal function? I tried this but got errors in remix: I’m trying zero decimals as practice.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\nin every other case, even when decimals are 18, you would do this right? or is 18 decimals implied if you don’t override the function?\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000 * 10 ** 18); \n }\n}\n\nany help is appreciated!\n\n Set ERC20 decimals to value other than 18\n\n 3\n\n 3\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You're missing the closing brace in the constructor, but it's otherwise ok.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n }\n\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\n18 decimals is the default number of decimals. But you still need to include ... * 10 ** 18 in your mint function call, because numbers of tokens are always expressed in terms of the smallest unit. This means \"one token\" is actually expressed as 10**18 tokens, or more generally 10**decimals. So in short, the snippet that you shared is correct.\n\n ERC20Detailed.sol not found in @openzeppelin/contracts/token/ERC20 on GitHub\n\n post by Nololan on May 31, 2021\n\n post by Nololan on May 31, 2021\n\n post by frangio on May 31, 2021\n\n 6 months later\n\n post by ChakshuJain on Nov 26, 2021\n\n post by frangio on Nov 26, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Set ERC20 decimals to value other than 18\n\n Contracts\n\n 2\n\n 5.7k\n\n May 2021\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n Change decimals for ERC20\n\n Contracts\n\n erc20\n\n 1\n\n 2.7k\n\n Apr 2021\n\n ERC20 token with supply less than 1\n\n Contracts\n\n erc20\n\n 3\n\n 1.2k\n\n Oct 2020\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 587\n\n Jun 2021","tokens":643,"squid":"ink-security_audits","role":"Sentinel","at":1791261742783,"hash":"c427b5612b6d9e5ff29314f520c3687219de89f7"}
{"url":"https://dev-forum.pyth.network/t/request-1ms-crypto-data-feed-trial-and-micro-movement-behavior/609/1","domain":"dev-forum.pyth.network","title":"Request: 1ms crypto data feed trial and micro‑movement behavior - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Request: 1ms crypto data feed trial and micro‑movement behavior \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 19\n\n 1 / 3\n\n Mar 19\n\n Mar 22\n\n post by ivanle12567 on Mar 19\n\n ivanle12567\n\n Hi !\nCould you please help me with the following: I am building an automated trading bot for Polymarket and currently use Chainlink, but a 1‑second price update is too slow. How does your crypto data at 1 ms update frequency affect micro price movements and 5‑minute candle resolution prices compared with a 1‑second feed, and is it possible to get a short paid trial of this 1 ms data before committing long term?\nmy mail : ivanle12567@gmail.com\n\n post by CHOPPAtheSHARK on Mar 20\n\n CHOPPAtheSHARK\n\n Yes - you can participate in this hackathon if you are interested; Pyth Community Hackathon - Pyth Developer Forum\nrequest an API key in the FAQ thread.\n\n post by Aditya520 on Mar 22\n\n Aditya520\n\n Feel free to fill up the form here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 473\n\n Jul 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 23\n\n Apr 9\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1254,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261750123,"hash":"6bce63c812e74cf8eeb5ccc3636c8e32648f3770"}
{"url":"https://ethereum.org/wallets/find-wallet/onekey/","domain":"ethereum.org","title":"OneKey | ⁦ethereum.org⁩","text":"New to cryptoDeveloperFinanceHardwareNFTsOneKeyDesktop · Mobile · Browser · HardwareEnglish, Chinese, Chinese (Taiwan), Japanese, Korean, Bangla, German, Spanish, Hindi, Italian, Portuguese, Russian, Thai, Ukrainian, Vietnamese, Indonesian, Brazilian Portuguese, FrenchSwap/bridge fee: 0.85%Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationOneKey info updated on 10/30/2024Similar walletsimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerAmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%Rabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%TokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variable","tokens":354,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261754895,"hash":"4320042230669c493d0a77acb7ae79c0584ac257"}
{"url":"https://forum.openzeppelin.com/t/what-does-it-look-like-to-override-the-decimals-function/9581/2","domain":"forum.openzeppelin.com","title":"What does it look like to override the decimals function? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n May 2021\n\n 2 / 7\n\n May 2021\n\n Nov 2021\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n What does it look like to override the decimal function? I tried this but got errors in remix: I’m trying zero decimals as practice.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\nin every other case, even when decimals are 18, you would do this right? or is 18 decimals implied if you don’t override the function?\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000 * 10 ** 18); \n }\n}\n\nany help is appreciated!\n\n Set ERC20 decimals to value other than 18\n\n 3\n\n 3\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You're missing the closing brace in the constructor, but it's otherwise ok.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n }\n\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\n18 decimals is the default number of decimals. But you still need to include ... * 10 ** 18 in your mint function call, because numbers of tokens are always expressed in terms of the smallest unit. This means \"one token\" is actually expressed as 10**18 tokens, or more generally 10**decimals. So in short, the snippet that you shared is correct.\n\n ERC20Detailed.sol not found in @openzeppelin/contracts/token/ERC20 on GitHub\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n got it, that makes sense.\nThank you!\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n frangio\n\n I actually have one more question. I read that we no longer declare the totalSupply like this:\n contract ERC20FixedSupply is ERC20 {\n constructor() public {\n totalSupply += 1000;\n balances[msg.sender] += 1000;\n }\n }\n\nInstead we do like in my first question, using the _mint function. To be clear, in a fixed supply contract the _mint function can’t be called again because it’s internal right? so it gets called once in the constructor and then can never be called again right? whereas in a non fixed supply contract I would make a function that then calls the _mint function, correct?\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You can add a public mint function if you need the token to be mintable after deployment. Take a look at Contracts Wizard and see what it does when you toggle Mintable.\n\n 6 months later\n\n post by ChakshuJain on Nov 26, 2021\n\n ChakshuJain\n\n frangio\n\n I just compiled this snippet in Remix and got a warning for the function mutability. As we do not evening read contract state so changing it from view to pure would be fine, right?\n\n post by frangio on Nov 26, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Yes that should be fine.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Set ERC20 decimals to value other than 18\n\n Contracts\n\n 2\n\n 5.7k\n\n May 2021\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n Change decimals for ERC20\n\n Contracts\n\n erc20\n\n 1\n\n 2.7k\n\n Apr 2021\n\n ERC20 token with supply less than 1\n\n Contracts\n\n erc20\n\n 3\n\n 1.2k\n\n Oct 2020\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 587\n\n Jun 2021","tokens":909,"squid":"ink-security_audits","role":"Sentinel","at":1791261757270,"hash":"a23d5da956ba64e0cde1f2a6169b169cc7445b51"}
{"url":"https://dev-forum.pyth.network/t/request-1ms-crypto-data-feed-trial-and-micro-movement-behavior/609/3","domain":"dev-forum.pyth.network","title":"Request: 1ms crypto data feed trial and micro‑movement behavior - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 19\n\n 3 / 3\n\n Mar 21\n\n Mar 22\n\n post by ivanle12567 on Mar 19\n\n ivanle12567\n\n Hi !\nCould you please help me with the following: I am building an automated trading bot for Polymarket and currently use Chainlink, but a 1‑second price update is too slow. How does your crypto data at 1 ms update frequency affect micro price movements and 5‑minute candle resolution prices compared with a 1‑second feed, and is it possible to get a short paid trial of this 1 ms data before committing long term?\nmy mail : ivanle12567@gmail.com\n\n post by CHOPPAtheSHARK on Mar 20\n\n CHOPPAtheSHARK\n\n Yes - you can participate in this hackathon if you are interested; Pyth Community Hackathon - Pyth Developer Forum\nrequest an API key in the FAQ thread.\n\n post by Aditya520 on Mar 22\n\n Aditya520\n\n Feel free to fill up the form here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 473\n\n Jul 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 23\n\n Apr 9\n\n PythPulse :Real-Time Crypto Anomaly Detector on Pyth Network\n\n Pyth Community Hackathon\n\n 0\n\n 25\n\n Apr 1\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1238,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261761568,"hash":"ec6de7edc136e2c84a8c5b2dd804bf1215c2378a"}
{"url":"https://ethereum.org/wallets/find-wallet/imkey-pro-hardware-wallet/","domain":"ethereum.org","title":"imKey Pro Hardware Wallet | ⁦ethereum.org⁩","text":"DeveloperFinanceHardwareNFTsimKey Pro Hardware WalletDesktop · Mobile · Browser · HardwareEnglish, ChineseDevice: $110, Swap fee: 0%Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationimKey Pro Hardware Wallet info updated on 12/17/2025Similar walletsOneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableimTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)AmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%","tokens":293,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261767399,"hash":"5d762c586768d26919223edf978519bafc87fe48"}
{"url":"https://forum.openzeppelin.com/t/what-does-it-look-like-to-override-the-decimals-function/9581/4","domain":"forum.openzeppelin.com","title":"What does it look like to override the decimals function? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n May 2021\n\n 4 / 7\n\n May 2021\n\n Nov 2021\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n What does it look like to override the decimal function? I tried this but got errors in remix: I’m trying zero decimals as practice.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\nin every other case, even when decimals are 18, you would do this right? or is 18 decimals implied if you don’t override the function?\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000 * 10 ** 18); \n }\n}\n\nany help is appreciated!\n\n Set ERC20 decimals to value other than 18\n\n 3\n\n 3\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You're missing the closing brace in the constructor, but it's otherwise ok.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n }\n\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\n18 decimals is the default number of decimals. But you still need to include ... * 10 ** 18 in your mint function call, because numbers of tokens are always expressed in terms of the smallest unit. This means \"one token\" is actually expressed as 10**18 tokens, or more generally 10**decimals. So in short, the snippet that you shared is correct.\n\n ERC20Detailed.sol not found in @openzeppelin/contracts/token/ERC20 on GitHub\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n got it, that makes sense.\nThank you!\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n frangio\n\n I actually have one more question. I read that we no longer declare the totalSupply like this:\n contract ERC20FixedSupply is ERC20 {\n constructor() public {\n totalSupply += 1000;\n balances[msg.sender] += 1000;\n }\n }\n\nInstead we do like in my first question, using the _mint function. To be clear, in a fixed supply contract the _mint function can’t be called again because it’s internal right? so it gets called once in the constructor and then can never be called again right? whereas in a non fixed supply contract I would make a function that then calls the _mint function, correct?\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You can add a public mint function if you need the token to be mintable after deployment. Take a look at Contracts Wizard and see what it does when you toggle Mintable.\n\n 6 months later\n\n post by ChakshuJain on Nov 26, 2021\n\n ChakshuJain\n\n frangio\n\n I just compiled this snippet in Remix and got a warning for the function mutability. As we do not evening read contract state so changing it from view to pure would be fine, right?\n\n post by frangio on Nov 26, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Yes that should be fine.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Set ERC20 decimals to value other than 18\n\n Contracts\n\n 2\n\n 5.7k\n\n May 2021\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n Change decimals for ERC20\n\n Contracts\n\n erc20\n\n 1\n\n 2.7k\n\n Apr 2021\n\n ERC20 token with supply less than 1\n\n Contracts\n\n erc20\n\n 3\n\n 1.2k\n\n Oct 2020\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 587\n\n Jun 2021","tokens":909,"squid":"ink-security_audits","role":"Sentinel","at":1791261767926,"hash":"663f254d05921fd76332135e59bcea037058b49b"}
{"url":"https://ethereum.org/wallets/find-wallet/ledger/","domain":"ethereum.org","title":"Ledger | ⁦ethereum.org⁩","text":"FinanceHardwareNFTsLedgerDesktop · Mobile · HardwareEnglish, Arabic, German, Spanish, French, Japanese, Korean, Russian, Turkish, ChineseDevice: $79 – $399, Swap fee: variableVisit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityPersonal ownershipOpen sourcePrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedToken importingGas fee customizationRPC importingLedger info updated on 10/23/2024Similar walletsOneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%TokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%NuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%MetaMaskFinanceNFTsMobile · BrowserEnglish · Amharic Swap/bridge fee: 0.875%, Buy/sell fee: 1%","tokens":305,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261778955,"hash":"baa8cfd5a9c81107bdcc99628407293810bf59cc"}
{"url":"https://forum.openzeppelin.com/t/what-does-it-look-like-to-override-the-decimals-function/9581/7","domain":"forum.openzeppelin.com","title":"What does it look like to override the decimals function? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n May 2021\n\n 7 / 7\n\n Nov 2021\n\n Nov 2021\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n What does it look like to override the decimal function? I tried this but got errors in remix: I’m trying zero decimals as practice.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\nin every other case, even when decimals are 18, you would do this right? or is 18 decimals implied if you don’t override the function?\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000 * 10 ** 18); \n }\n}\n\nany help is appreciated!\n\n Set ERC20 decimals to value other than 18\n\n 3\n\n 3\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You're missing the closing brace in the constructor, but it's otherwise ok.\npragma solidity 0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract MyToken is ERC20 {\n constructor () ERC20 (\"MyToken\", \"MTK\") {\n _mint(msg.sender, 1000000);\n }\n\n function decimals() public view override returns (uint8) {\n return 0;\n }\n}\n\n18 decimals is the default number of decimals. But you still need to include ... * 10 ** 18 in your mint function call, because numbers of tokens are always expressed in terms of the smallest unit. This means \"one token\" is actually expressed as 10**18 tokens, or more generally 10**decimals. So in short, the snippet that you shared is correct.\n\n ERC20Detailed.sol not found in @openzeppelin/contracts/token/ERC20 on GitHub\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n got it, that makes sense.\nThank you!\n\n post by Nololan on May 31, 2021\n\n Nololan\n\n frangio\n\n I actually have one more question. I read that we no longer declare the totalSupply like this:\n contract ERC20FixedSupply is ERC20 {\n constructor() public {\n totalSupply += 1000;\n balances[msg.sender] += 1000;\n }\n }\n\nInstead we do like in my first question, using the _mint function. To be clear, in a fixed supply contract the _mint function can’t be called again because it’s internal right? so it gets called once in the constructor and then can never be called again right? whereas in a non fixed supply contract I would make a function that then calls the _mint function, correct?\n\n post by frangio on May 31, 2021\n\n frangio\n\n OpenZeppelin Team\n\n You can add a public mint function if you need the token to be mintable after deployment. Take a look at Contracts Wizard and see what it does when you toggle Mintable.\n\n 6 months later\n\n post by ChakshuJain on Nov 26, 2021\n\n ChakshuJain\n\n frangio\n\n I just compiled this snippet in Remix and got a warning for the function mutability. As we do not evening read contract state so changing it from view to pure would be fine, right?\n\n post by frangio on Nov 26, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Yes that should be fine.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Set ERC20 decimals to value other than 18\n\n Contracts\n\n 2\n\n 5.7k\n\n May 2021\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n Change decimals for ERC20\n\n Contracts\n\n erc20\n\n 1\n\n 2.7k\n\n Apr 2021\n\n ERC20 token with supply less than 1\n\n Contracts\n\n erc20\n\n 3\n\n 1.2k\n\n Oct 2020\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 587\n\n Jun 2021","tokens":909,"squid":"ink-security_audits","role":"Sentinel","at":1791261779367,"hash":"ecb62c5d69efc90f4f2ce9199588c4fb3556ba91"}
{"url":"https://dev-forum.pyth.network/t/pyth-api-ont-showing-updated-prices/749","domain":"dev-forum.pyth.network","title":"Pyth API ont showing updated prices - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth API ont showing updated prices \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Siddharth on Apr 9\n\n Siddharth\n\n I’m seeing pyth api, returning 77.x for SPYM feed, where as market is at 79.x\nhttps://hermes.pyth.network/v2/updates/price/latest?ids[]=0x4dfbf28d72ab41a878afcd4c6d5e9593dca7cf65a0da739cbad9b7414004f82d\n\nThe price feed is for SPLG : SPLG/USD | Pyth Network Insights\n\nThere is also a second price feed called SPYM, but for that no price is being pushed : SPYM/USD | Pyth Network Insights\nCan we please resolve this asap, thank you.\n\nPlease reach out on telegram @siddharth_bhoite . Thank you.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 473\n\n Jul 2025\n\n Request: 1ms crypto data feed trial and micro‑movement behavior\n\n Price Feeds\n\n 2\n\n 59\n\n Mar 22\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 651\n\n Oct 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Powered by Discourse","tokens":1182,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261787389,"hash":"fd18da450bc08bf5cc5ac274c13d59a087d2098d"}
{"url":"https://forum.openzeppelin.com/t/set-erc20-decimals-to-value-other-than-18/5951/3","domain":"forum.openzeppelin.com","title":"Set ERC20 decimals to value other than 18 - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2021\n\n 4 / 4\n\n May 2021\n\n Mar 2021\n\n post by Trade_Coin on Feb 23, 2021\n\n Trade_Coin\n\n I have created a Standard ERC20 preset with the following code in the Remix IDE\n\n// contracts/ERC20.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.2;\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.0.1/contracts/presets/ERC20PresetMinterPauser.sol\n\nI would like to change the Decimals from 18 to lower number\nAfter implementing the contract i was not even able to verify the contract.\nI would like to have little help with my first implement of Contracts\n\n post by abcoathup on Feb 23, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @Trade_Coin,\nWelcome to the community \nTo set decimals to a value other than 18, call _setupDecimals in your constructor.\nWhilst decimals are for display purposes, I would suggest only changing from the default of 18 when you have a very special reason not to. See: https://docs.openzeppelin.com/contracts/3.x/erc20#a-note-on-decimals\nI noticed that you are using OpenZeppelin Contracts 3.0.1. You may want to change this to OpenZeppelin Contracts 3.4 (the latest 3.x version).\nAlso OpenZeppelin Contracts 4.0 Beta has been released, see announcement: OpenZeppelin Contracts 4.0 Beta\n\nAs an aside, see how to Format code in the forum.\n\n post by frangio on Mar 1, 2021\n\n frangio\n\n OpenZeppelin Team\n\n In Contracts 4.0 Beta, _setupDecimals was removed and the way to use a value other than 18 is now to override the decimals() function.\n\n 3 months later\n\n Split this topic on May 31, 2021\n\n 2 posts were split to a new topic: What does it look like to override the decimals function?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Change decimals for ERC20\n\n Contracts\n\n erc20\n\n 1\n\n 2.7k\n\n Apr 2021\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 587\n\n Jun 2021\n\n What does it look like to override the decimals function?\n\n Contracts\n\n erc20\n\n 6\n\n 5.7k\n\n Nov 2021\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n Question about ERC 20 tokens are Avalanche\n\n Smart Contracts\n\n 3\n\n 759\n\n Dec 2021","tokens":563,"squid":"ink-security_audits","role":"Sentinel","at":1791261793632,"hash":"209258310789a90250aa4dc32b1eacf1f2896f44"}
{"url":"https://dev-forum.pyth.network/t/price-evolution-differences-api-error/320/1","domain":"dev-forum.pyth.network","title":"Price Evolution/Differences API Error - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Evolution/Differences API Error \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2025\n\n 1 / 2\n\n Jul 2025\n\n Jul 2025\n\n post by KemarTiti on Jul 28, 2025\n\n KemarTiti\n\n Hey everyone,\nIt seems Pyth has a huge update on Api!\nCurrently we found this Api not working, is there any alternative for that ?\nhttps://pyth.network/api/price-differences?cluster=pythnet\n\n post by KemarTiti on Jul 28, 2025\n\n KemarTiti\n\n the replacement is this:\nhttps://web-api.pyth.network/price_differences?cluster=pythnet\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Request: 1ms crypto data feed trial and micro‑movement behavior\n\n Price Feeds\n\n 2\n\n 59\n\n Mar 22\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 651\n\n Oct 2025\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Price Feeds Testnet (Arbitrum, Base, Optimism) Fee Increase\n\n Announcements\n\n 0\n\n 460\n\n May 2025\n\n Powered by Discourse","tokens":1157,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261797764,"hash":"24b355c82e813008a46d50d2cc1473c63a3a7ef5"}
{"url":"https://specs.optimism.io/protocol/superchain-config.html","domain":"specs.optimism.io","title":"Superchain Configuration - OP Stack Specification","text":"Superchain Configuration\n\nTable of Contents\n\nOverview\nConfiguration Data Structure\n\nSuperchainDefinition\nHardforks\nSuperchainL1\n\nInvariants\n\niSUPC-001: The Guardian and Pause Deputy must be able to trigger the Pause Mechanism\n\nImpact\n\niSUPC-002: The Guardian must be able to reset or undo the Pause Mechanism\n\nImpact\n\nFunction Specification\n\ninitialize\nupgrade\nguardian\npauseExpiry\npause\nunpause\nextend\npausable\npaused\nexpiration\n\nOverview\nThe SuperchainConfig contract is used to manage global configuration values for multiple OP Chains\nwithin a single Superchain network.\nConfiguration Data Structure\nThe SuperchainDefinition type represents the configuration for a\nSuperchain target, containing information about L1 contract addresses\nand network parameters.\nSuperchainDefinition\nSuperchainDefinition {\n Name string\n ProtocolVersionsAddr address\n SuperchainConfigAddr address\n OPContractsManagerAddr address\n Hardforks Hardforks\n L1 SuperchainL1\n}\n\nFields:\n\nName: The name of the superchain (e.g., \"mainnet\", \"sepolia\")\nProtocolVersionsAddr: Address of the ProtocolVersions contract on L1\nSuperchainConfigAddr: Address of the SuperchainConfig contract on L1\nOPContractsManagerAddr: Address of the OP Contracts Manager on L1\nHardforks: Hardfork activation configuration for the superchain\nL1: L1 chain information including chain ID, RPC endpoint, and explorer URL\n\nHardforks\nThe Hardforks type contains optional activation timestamps for each network upgrade.\nHardforks {\n CanyonTime uint64\n DeltaTime uint64\n EcotoneTime uint64\n FjordTime uint64\n GraniteTime uint64\n HoloceneTime uint64\n IsthmusTime uint64\n InteropTime uint64\n}\n\nFields:\n\nCanyonTime: Activation timestamp for the Canyon upgrade\nDeltaTime: Activation timestamp for the Delta upgrade\nEcotoneTime: Activation timestamp for the Ecotone upgrade\nFjordTime: Activation timestamp for the Fjord upgrade\nGraniteTime: Activation timestamp for the Granite upgrade\nHoloceneTime: Activation timestamp for the Holocene upgrade\nIsthmusTime: Activation timestamp for the Isthmus upgrade\nInteropTime: Activation timestamp for the Interop upgrade\n\nSuperchainL1\nThe SuperchainL1 type contains L1 chain information for the superchain.\nSuperchainL1 {\n ChainID uint64\n PublicRPC string\n Explorer string\n}\n\nFields:\n\nChainID: The chain ID of the L1 network (e.g. 1 for Ethereum mainnet, 11155111 for Sepolia)\nPublicRPC: Public RPC endpoint URL for the L1 network\nExplorer: Block explorer URL for the L1 network\n\nInvariants\niSUPC-001: The Guardian and Pause Deputy must be able to trigger the Pause Mechanism\nWe require that the SuperchainConfig is constructed such that both the\nGuardian and the Pause Deputy must be able to\ntrigger the Pause Mechanism at any time.\nImpact\nSeverity: High\nExisting recovery runbooks would not function as expected if the SuperchainConfig prevented one\nof these actors from triggering the pause as needed.\niSUPC-002: The Guardian must be able to reset or undo the Pause Mechanism\nWe require that the SuperchainConfig is constructed such that the\nGuardian must be able to unpause or extend the\nPause Mechanism at any time.\nImpact\nSeverity: Medium\nIf the Pause Mechanism cannot be reset then it cannot be used again without intervention from the\nProxy Admin Owner. We consider this to be a Medium severity\nissue because the Proxy Admin Owner will have several months to coordinate such a fix assuming\nthat iSUPC-001 holds.\nFunction Specification\ninitialize\n\nMUST only be triggerable by the ProxyAdmin or its owner.\nMUST only be triggerable once.\nMUST set the value of the Guardian role.\nMUST emit a ConfigUpdate event with the Guardian address.\n\nupgrade\n\nMUST only be triggerable by the ProxyAdmin or its owner.\nMUST migrate the guardian from old storage to new storage.\nMUST clear old storage slots.\nMUST maintain contract version information.\n\nguardian\nReturns the address of the current Guardian.\npauseExpiry\nReturns the duration after which a pause expires, which is a hardcoded constant of 7,884,000 seconds (approximately 3 months).\npause\nAllows the Guardian to trigger the\nPause Mechanism. pause takes an address\nPause Identifier as an input. This identifier determines which\nsystems or chains are affected by the pause.\n\nMUST revert if called by an address other than the Guardian.\nMUST revert if the pause timestamp for the given identifier is non-zero (already paused).\nMUST set the pause timestamp for the given identifier to the current block timestamp.\nMUST emit a Paused event with the identifier.\n\nunpause\nAllows the Guardian to explicitly unpause the system for a given\nPause Identifier rather than waiting for the pause to expire.\nUnpausing a specific identifier does NOT unpause the global pause (zero address identifier). If the\nglobal pause is active, all systems will remain paused even if their specific identifiers are\nunpaused.\n\nMUST revert if called by an address other than the Guardian.\nMUST set the pause timestamp for the given identifier to 0, representing \"not paused\".\nMUST emit an Unpaused event with the identifier.\nWill not revert if the system is not already paused for the given identifier.\n\nextend\nAllows the Guardian to extend an active pause by resetting the pause\ntimestamp to the current block timestamp, effectively restarting the expiry timer.\n\nMUST revert if called by an address other than the Guardian.\nMUST revert if the pause timestamp for the given identifier is zero (not currently paused).\nMUST set the pause timestamp for the given identifier to the current block timestamp.\nMUST emit a Paused event with the identifier.\n\npausable\nAllows any user to check if the Pause Mechanism can be triggered\nfor a specific Pause Identifier. The pausable status of a specific\nidentifier is independent of the pausable status of the global pause (zero address identifier).\n\nMUST return true if the pause timestamp for the given identifier is 0 (not currently paused).\nMUST return false if the pause timestamp for the given identifier is non-zero (currently paused).\n\npaused\nAllows any user to check if the system is currently paused for a specific\nPause Identifier.\n\nMUST return true if the pause timestamp for the given identifier is non-zero AND not expired\n(current time < pause timestamp + expiry duration).\nMUST return false otherwise.\nWhen called without parameters, MUST check the pause status for the global identifier (address(0)).\n\nexpiration\nReturns the timestamp at which the pause for a given\nPause Identifier will expire. This function only returns the\nexpiration for the specific identifier provided.\n\nMUST return the pause timestamp plus the configured expiry duration if the pause timestamp is non-zero.\nMUST return 0 if the pause timestamp is 0 (system is not paused) for the given identifier.","tokens":1682,"squid":"ink-governance","role":"Council Listener","at":1791261805808,"hash":"890b47f8eb5de3bc712912861705f4c2ed28f6c6"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/bridging/overview","domain":"docs.arbitrum.io","title":"Bridging overview | Arbitrum Docs","text":"✏️Request an updateToken bridging and cross-chain messaging are fundamental aspects of building on Arbitrum. This page helps you find the right guide for your use case.\nMove ETH between chains​\n\nDeposit ETH to Arbitrum: Bridge ETH from the parent chain to a child chain using the Inbox contract\nWithdraw ETH to Ethereum: Withdraw ETH from a child chain back to the parent chain via ArbSys\n\nMove ERC-20 tokens between chains​\n\nDeposit tokens to Arbitrum: Move ERC-20 tokens from the parent chain to the child chain\nWithdraw tokens to Ethereum: Move ERC-20 tokens from the child chain back to the parent chain\n\nMake my token bridgeable​\nChoose a gateway based on your token's requirements:\n\nStandard gateway (recommended): Automatic deployment of a standard ERC-20 on Arbitrum, no configuration required\nGeneric-custom gateway: Custom functionality in your child chain token while using Arbitrum's built-in gateway\nCustom gateway: Specialized gateway logic for advanced use cases\n\nSend arbitrary cross-chain messages​\n\nParent → child messaging: Send messages from Ethereum to Arbitrum using retryable tickets\nChild → parent messaging: Send messages from Arbitrum to Ethereum via ArbSys and the Outbox\n\nBuild on a custom gas token chain​\nIf you're working with an Arbitrum chain that uses a non-ETH gas token, see Custom gas token chain bridging for SDK APIs and workflows.\nExample code​\n\nToken deposits (parent → child)\nToken withdrawals (child → parent)\nCustom token bridging setup\n\nLearn more​\n\nCross-chain messaging concepts\nToken bridge architecture\nArbitrum SDK\nMove ETH between chainsMove ERC-20 tokens between chainsMake my token bridgeableSend arbitrary cross-chain messagesBuild on a custom gas token chainExample codeLearn more","tokens":434,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261812331,"hash":"0b197542925799d968a2e6e5969de458e32d1bcd"}
{"url":"https://io.net/docs/guides/workers/install-on-macos","domain":"io.net","title":"Overview - io.net","text":"​Before Starting, Check Your Mac Processor\nWe currently only support Apple chip processors (M3, M4). All currently supported processor and video card models can be found here.\nTo check your Mac processor:\n\nOn your Mac, click the Apple icon in the top-left corner of the menu bar.\nSelect the About This Mac option.\nIf you see Apple M3 (or higher) in the Chip line, it means you’re using a Mac with an Apple Silicon CPU.\n\n​Go to cloud.io.net\nIf you have not yet created an account, you can sign up on io.net using Google, Apple ID, GitHub, Hugging Face, X, Worldcoin, or simply with a one-time password by clicking the “Login with Email” button.\n\n​1. From IO Elements Navigate to Worker Section\nIO Elements serves as your new control panel for navigating the service efficiently. Click on IO Worker to delve deeper into its functionalities and features.\n\n​2. Use “Connect New Worker” Button to Open the Wizard\nIf Workers have not yet been added, you can use the central button. If the screen is full of information, find the same button in the upper right corner\n\n​3. Name Your Device\nClick the “Pencil” icon to open the popup for editing the device name.\nPlease add a unique name for your device. An ideal format would be something like this: My-Test-Device
\n\n​4. Select MacOS Operating System “OS”\nChoose the Operating System “OS” of your device from MacOS, Windows or Ubuntu.\n\n​5. Prerequisites for Mac\nDownload and install Docker Desktop for MacOS by following the link.\nIt has been confirmed that some users limit the amount of system resources that IO Worker can access when performing compute verifications. Many users do not set the proper amount of device level resources available for the Docker engine. Many have used default settings or restricted the Worker’s RAM access to 8GB or lower. This would significantly impact the device capability in passing PoW. This is mostly common among Mac devices.\nTo install Docker on MacOS computers, refer to the “Installing Docker on MacOS” instructions.\n​6. Download and Launch IO Binary\nIO Binary is a compiled executable file used to perform computational tasks and manage system operations. It is crucial for the smooth operation of the platform as it handles essential functions directly related to the performance and reliability of the computational resources.\nDo not modify or run code directly in io.net’s docker containers. This may disqualify your device from earning block rewards or being hired. If you have suggestions or ideas for custom code in our Docker containers, contact customer support to suggest them.\nFollow the steps below to download and launch the IO binary:\n\nOpen the Terminal through Launchpad\nTerminal is a tool on your computer that lets you type in commands to tell the computer what to do. Instead of clicking on things with a mouse, you write instructions, and the computer follows them. It’s like talking directly to your computer using text.\nClick the Launchpad icon in the Dock, start typing “Terminal” in the search field, then click the Terminal icon:\n\nDownload the IO Binary for MacOS using the following link in the Terminal:\ncurl -L https://github.com/ionet-official/io_launch_binaries/raw/main/io_net_launch_binary_mac -o io_net_launch_binary_mac\n\nGrant permissions to the new IO Binary with this command:\nchmod +x io_net_launch_binary_mac\n\nCopy generated the IO Binary address provided in the wizard and past it into Terminal to run further:\n./io_net_launch_binary_mac\n\nTo disable sleep mode for a device, pass the —disable_sleep_mode=true argument at the end of the command line../io_net_launch_binary_mac --disable_sleep_mode=true\nYou can find more additional arguments to use with the IO Binary command here.\n\n​7. Authorize Your New Device\nThe IO Binary may prompt you to authorize your new device.\nRemember, you have 3+ minutes to complete the authorization of the device. If you miss it, rerun the code again.\nYou can do this in two ways:\n\nCopy the Link from the Terminal:\n\nPaste it into your browser and confirm the action. After confirmation, the system will prompt you to log in.\n\nCopy the Code from the Terminal:\n\nEnter this code on the page https://auth0.io.solutions/activate to authorize the device. You will be prompted to log in.\n\nOnboard Multiple Devices by Bypassing Interactive AuthenticationTo onboard a new device, use the following command with the —token flag:./io_net_launch_binary_mac --token your-token-value\nThis will allow you to bypass the interactive authentication process.\n​8. Remove previously installed Docker containers\n will ask you questions related to previously installed Docker Containers. To continue the installation of , you must agree to remove all old containers and proceed by typing: Yes\n\n​9. Wait for Worker Connection to Complete\nIO Binary will install all additional containers and images for your Docker. The process may take some time to complete as it installs additional packages for Docker. Please allow the installation process to finish.\n\nAfterward, return to the browser to complete the installation.\nYou may need to wait for up to 10 minutes while the device checks and connects to the IO Ecosystem. If it doesn’t connect, contact customer support by logging into your IO.Net account.\n\nPlease disable power-saving mode when running your devices on IO Net. Power-saving mode can impair device performance, potentially leading to failure in PoW or being classified as not providing adequate computing power.\n​Congratulations on Successfully Setting up Your First Worker.\nNow that your Worker has been successfully created and is running, you can track its status on the Workers page.\n\nIf you’re having trouble installing the Worker, please refer to our MacOS Worker troubleshooting guide or the general Worker troubleshooting guide. If the issue persists or you need further assistance, feel free to check our knowledge base for answers, and if you still need help, don’t hesitate to open a support ticket!\nBe aware that you will be installing a 20GB size container. This contains all the packages needed to serve AI/ML apps. Everything happens inside the container, nothing within the container can access your filesystemWas this page helpful?","tokens":1548,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261815277,"hash":"9d62b2cc3ff4b0a7aa9dc4763558d040d51ae8f0"}
{"url":"https://specs.optimism.io/protocol/superchain-upgrades.html","domain":"specs.optimism.io","title":"Superchain Upgrades - OP Stack Specification","text":"Superchain Upgrades\n\nTable of Contents\n\nOverview\nProtocol Version\n\nProtocol Version Format\n\nBuild identifier\nMajor versions\nMinor versions\nPatch versions\nPre-releases\n\nProtocol Version Exposure\n\nSuperchain Target\n\nSuperchain Version signaling\nProtocolVersions L1 contract\n\nActivation rules\n\nL2 Block-number based activation (deprecated)\nL2 Block-timestamp based activation\nAt most one network upgrade per activation timestamp\n\nOP-Stack Protocol versions\nPost-Bedrock Network upgrades\n\nActivation Timestamps\n\nOverview\nSuperchain upgrades, also known as forks or hardforks, implement consensus-breaking changes.\nA Superchain upgrade requires the node software to support up to a given Protocol Version.\nThe version indicates support, the upgrade indicates the activation of new functionality.\nThis document lists the protocol versions of the OP-Stack, starting at the Bedrock upgrade,\nas well as the default Superchain Targets.\nActivation rule parameters of network upgrades are configured as part of the Superchain Target specification:\nchains following the same Superchain Target upgrade synchronously.\nProtocol Version\nThe Protocol Version documents the progression of the total set of canonical OP-Stack specifications.\nComponents of the OP-Stack implement the subset of their respective protocol component domain,\nup to a given Protocol Version of the OP-Stack.\nOP-Stack mods, i.e. non-canonical extensions to the OP-Stack, are not included in the versioning of the Protocol.\nInstead, mods must specify which upstream Protocol Version they are based on and where breaking changes are made.\nThis ensures tooling of the OP-Stack can be shared and collaborated on with OP-Stack mods.\nThe Protocol Version is NOT a hardfork identifier, but rather indicates software-support for a well-defined set\nof features introduced in past and future hardforks, not the activation of said hardforks.\nChanges that can be included in prospective Protocol Versions may be included in the specifications as proposals,\nwith explicit notice of the Protocol Version they are based on.\nThis enables an iterative integration process into the canonical set of specifications,\nbut does not guarantee the proposed specifications become canonical.\nNote that the Protocol Version only applies to the Protocol specifications with the Superchain Targets specified within.\nThis versioning is independent of the Semver versioning used in OP Stack smart-contracts,\nand the Semver-versioned reference software of the OP-Stack.\nProtocol Version Format\nThe Protocol Version is Semver-compatible.\nIt is encoded as a single 32 bytes long <protocol version>.\nThe version must be encoded as 32 bytes of DATA in JSON RPC usage.\nThe encoding is typed, to ensure future-compatibility.\n<protocol version> ::= <version-type><typed-payload>\n<version-type> ::= <uint8>\n<typed-payload> ::= <31 bytes>\n\nversion-type 0:\n<reserved><build><major><minor><patch><pre-release>\n<reserved> ::= <7 zeroed bytes>\n<build> ::= <8 bytes>\n<major> ::= <big-endian uint32>\n<minor> ::= <big-endian uint32>\n<patch> ::= <big-endian uint32>\n<pre-release> ::= <big-endian uint32>\n\nThe <reserved> bytes of the Protocol Version are reserved for future extensions.\nProtocol versions with a different <version-type> should not be compared directly.\nBuild identifier\nThe <build> identifier, as defined by Semver, is ignored when determining version precedence.\nThe <build> must be non-zero to apply to the protocol version.\nModifications of the OP-Stack should define a <build> to distinguish from the canonical protocol feature-set.\nChanges to the <build> may be encoded in the <build> itself to stay aligned with the upstream protocol.\nThe major/minor/patch versions should align with that of the upstream protocol that the modifications are based on.\nUsers of the protocol can choose to implement custom support for the alternative <build>,\nbut may work out of the box if the major features are consistent with that of the upstream protocol version.\nThe 8 byte <build> identifier may be presented as a string for human readability if the contents are alpha-numeric,\nincluding - and ., as outlined in the Semver format specs. Trailing 0 bytes can be used for padding.\nIt may be presented as 0x-prefixed hex string otherwise.\nMajor versions\nMajor version changes indicate support for new consensus-breaking functionality.\nMajor versions should retain support for functionality of previous major versions for\nsyncing/indexing of historical chain data.\nImplementations may drop support for previous Major versions, when there are viable alternatives,\ne.g. l2geth for pre-Bedrock data.\nMinor versions\nMinor version changes indicate support for backward compatible extensions,\nincluding backward-compatible additions to the set of chains in a Superchain Target.\nBackward-compatibility is defined by the requirement for existing end-users to upgrade nodes and tools or not.\nMinor version changes may also include optional offchain functionality, such as additional syncing protocols.\nPatch versions\nPatch version changes indicate backward compatible bug fixes and improvements.\nPre-releases\nPre-releases of the protocol are proposals: these are not stable targets for production usage.\nA pre-release might not satisfy the intended compatibility requirements as denoted by its associated normal version.\nThe <pre-release> must be non-zero to apply to the protocol version.\nThe <pre-release> 0-value is reserved for non-prereleases, i.e. v3.1.0 is higher than v3.1.0-1.\nNode-software may support a pre-release, but must not activate any protocol changes without the user explicitly\nopting in through the means of a feature-flag or configuration change.\nA pre-release is not an official version and is meant for protocol developers to communicate an experimental changeset\nbefore the changeset is reviewed by governance. Pre-releases are subject to change.\nProtocol Version Exposure\nThe Protocol Version is not exposed to the application-layer environment:\nhardforks already expose the change of functionality upon activation as required,\nand the Protocol Version is meant for offchain usage only.\nThe protocol version indicates support rather than activation of functionality.\nThere is one exception however: signaling by onchain components to offchain components.\nMore about this in Superchain Version signaling.\nSuperchain Target\nChanges to the L2 state-transition function are transitioned into deterministically across all nodes\nthrough an activation rule.\nChanges to L1 smart-contracts must be compatible with the latest activated L2 functionality,\nand are executed through L1 contract-upgrades.\nA Superchain Target defines a set of activation rules and L1 contract upgrades shared between OP-Stack chains,\nto upgrade the chains collectively.\nSuperchain Version signaling\nEach Superchain Target tracks the protocol changes, and signals the recommended and required\nProtocol Version ahead of activation of new breaking functionality.\n\nrecommended: a signal in advance of a network upgrade, to alert users of the protocol change to be prepared for.\nNode software is recommended to signal the recommendation to users through logging and metrics.\nrequired: a signal shortly in advance of a breaking network upgrade, to alert users of breaking changes.\nUsers may opt in to elevated alerts or preventive measures, to ensure consistency with the upgrade.\n\nSignaling is done through a L1 smart-contract that is monitored by the OP-Stack software.\nNot all components of the OP-Stack are required to directly monitor L1 however:\ncross-component APIs like the Engine API may be used to forward the Protocol Version signals,\nto keep components encapsulated from L1.\nSee engine_signalOPStackVersionV1.\nProtocolVersions L1 contract\nThe ProtocolVersions contract on L1 enables L2 nodes to pick up on superchain protocol version signals.\nThe interface is:\n\nRequired storage slot: bytes32(uint256(keccak256(\"protocolversion.required\")) - 1)\nRecommended storage slot: bytes32(uint256(keccak256(\"protocolversion.recommended\")) - 1)\nRequired getter: required() returns ProtocolVersion\nRecommended getter recommended() returns ProtocolVersion\nVersion updates also emit a typed event:\nevent ConfigUpdate(uint256 indexed version, UpdateType indexed updateType, bytes data)\n\nActivation rules\nThe below L2-block based activation rules may be applied in two contexts:\n\nThe rollup node, specified through the rollup configuration (known as rollup.json),\nreferencing L2 blocks (or block input-attributes) that pass through the derivation pipeline.\nThe execution engine, specified through the chain configuration (known as the config part of genesis.json),\nreferencing blocks or input-attributes that are part of, or applied to, the L2 chain.\n\nFor both types of configurations, some activation parameters may apply to all chains within the superchain,\nand are then retrieved from the superchain target configuration.\nL2 Block-number based activation (deprecated)\nActivation rule: upgradeNumber != null && block.number >= upgradeNumber\nStarting at, and including, the L2 block with block.number >= upgradeNumber, the upgrade rules apply.\nIf the upgrade block-number upgradeNumber is not specified in the configuration, the upgrade is ignored.\nThis block number based method has commonly been used in L1 up until the Bellatrix/Paris upgrade, a.k.a. The Merge,\nwhich was upgraded through special rules.\nThis method is not superchain-compatible, as the activation-parameter is chain-specific\n(different chains may have different block-heights at the same moment in time).\nThis applies to the L2 block number, not to the L1-origin block number.\nThis means that an L2 upgrade may be inactive, and then active, without changing the L1-origin.\nL2 Block-timestamp based activation\nActivation rule: upgradeTime != null && block.timestamp >= upgradeTime\nStarting at, and including, the L2 block with block.timestamp >= upgradeTime, the upgrade rules apply.\nIf the upgrade block-timestamp upgradeTime is not specified in the configuration, the upgrade is ignored.\nThis is the preferred superchain upgrade activation-parameter type:\nit is synchronous between all L2 chains and compatible with post-Merge timestamp-based chain upgrades in L1.\nThis applies to the L2 block timestamp, not to the L1-origin block timestamp.\nThis means that an L2 upgrade may be inactive, and then active, without changing the L1-origin.\nThis timestamp based method has become the default on L1 after the Bellatrix/Paris upgrade, a.k.a. The Merge,\nbecause it can be planned in accordance with beacon-chain epochs and slots.\nNote that the L2 version is not limited to timestamps that match L1 beacon-chain slots or epochs.\nA timestamp may be chosen to be synchronous with a specific slot or epoch on L1,\nbut the matching L1-origin information may not be present at the time of activation on L2.\nAt most one network upgrade per activation timestamp\nStarting with the Jovian upgrade, two network upgrades MUST NOT be configured to activate at the\nsame L2 block timestamp, unless that timestamp is at or before the L2 genesis block timestamp.\nEquivalently: the activation timestamp of Jovian, and of every upgrade after it, MUST be strictly\ngreater than that of the preceding upgrade, unless both activate at or before genesis.\nThe rule is not applied retroactively to the upgrades before Jovian: a small number of chains\nactivated two of those in the same block before the rule was written down, and their activation\nhistory cannot be changed.\nChains whose genesis is created after one or more upgrades have already been defined\nactivate those upgrades in the genesis block itself, conventionally by setting their\nactivation timestamps to 0. No activation block processing happens for those upgrades,\nso they may — and usually do — share an activation timestamp.\nNote that this constraint governs OP-Stack network upgrades only.\nIt does not constrain an OP-Stack upgrade timestamp against an L1 fork timestamp\nconfigured on the same chain, which may coincide.\nOP-Stack Protocol versions\n\nv1.0.0: 2021 Jan 16th - Mainnet Soft Launch, based on OVM.\n(announcement)\nv1.1.0: 2021 Aug 19th - Community launch.\n(announcement)\nv2.0.0: 2021 Nov 12th - the EVM-Equivalence update, also known as OVM 2.0 and chain regenesis.\n(announcement)\nv2.1.0: 2022 May 31st - Optimism Collective.\n(announcement).\nv3.0.0-1: 2023 Jan 13th - Bedrock pre-release, deployed on OP-Goerli, and later Base-Goerli.\nv3.0.0: 2023 Jun 6th - Bedrock, including the Regolith hardfork improvements, first deployed on OP-Mainnet.\nv4.0.0: 2024 Jan 11th - Canyon network upgrade (Shapella).\nGovernance Proposal.\nv5.0.0: 2024 Feb 22nd - Delta network upgrade (Span Batches).\nGovernance Proposal.\nv6.0.0: 2024 Mar 14th - Ecotone network upgrade (4844 Blob Batches + Cancun).\nGovernance Proposal.\nv7.0.0: 2024 Jul 10th - Fjord network upgrade (RIP-7212 precompile + FastLZ cost fn + Brotli compression).\nGovernance Proposal.\nv8.0.0: 2024 Sep 11th - Granite network upgrade (Limit ecpairing input size + Reduce Channel Timeout).\nGovernance Proposal.\nv9.0.0: 2025 Jan 9th - Holocene network upgrade (Stricter Holocene derivation + EIP-1559 configurability).\nGovernance Proposal.\n\nPost-Bedrock Network upgrades\nActivation Timestamps\nGovernance approves all network upgrades & the time at which the upgrade activates. The approved governance\nproposal is the canonical document for the timestamp; however, the timestamps are replicated here for ease of use.\nNetwork UpgradeMainnet Upgrade TimestampSepolia Upgrade TimestampGoerli Upgrade Timestamp\nCanyon170499240116999812001699981200\nDelta170856000017032032001703116800\nEcotone171037440117085348001707238800\nFjord17206272011716998400n/a\nGranite17260704011723478400n/a\nHolocene17364456011732633200n/a","tokens":3440,"squid":"ink-governance","role":"Council Listener","at":1791261815676,"hash":"f79697055175bfec44b6e624ee416d3fd259fc81"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/bridging/configure-token-gateway/generic-custom","domain":"docs.arbitrum.io","title":"Configure generic-custom gateway bridging | Arbitrum Docs","text":"✏️Request an updateIn this how-to, you'll learn how to bridge your own token between Ethereum (parent chain) and Arbitrum (child chain), using Arbitrum's generic-custom gateway. For alternative ways of bridging tokens, check out the token bridging overview.\nFamiliarity with Arbitrum's token bridge system, smart contracts, and blockchain development is expected. If you're new to blockchain development, consider reviewing our Quickstart: Build a dApp with Arbitrum (Solidity, Hardhat) before proceeding. We'll use Arbitrum's SDK throughout this how-to, although no prior knowledge is required.\nWe'll go through all the steps involved in the process. However, if you want to jump straight to the code, we've created a custom token bridging tutorial script that encapsulates the entire process.\nStep 1: Review the prerequisites​\nAs stated in the token bridge conceptual page, there are a few prerequisites to keep in mind while using this method to make a token bridgeable.\nFirst of all, the parent chain counterpart of the token must conform to the ICustomToken interface, meaning that:\n\nIt must have an isArbitrumEnabled method that returns 0xb1\nIt must have a method that makes an external call to L1CustomGateway.registerCustomL2Token specifying the address of the child chain contract, and to L1GatewayRouter.setGateway specifying the address of the custom gateway. Make these calls only once to configure the gateway.\n\nThese methods are needed to register the token via the gateway contract. If your parent chain contract does not include these methods and it is not upgradeable, you could register in one of these ways:\n\nAs a chain owner, register via an Arbitrum DAO proposal.\nBy wrapping your parent chain token and registering the wrapped version of your token.\n\nNote that registration is a one-time event.\nAlso, the child chain counterpart of the token must conform to the IArbToken interface, meaning that:\n\nIt must have bridgeMint and bridgeBurn methods callable only by the L2CustomGateway contract.\nIt must have an l1Address view method that returns the token's address on the parent chain.\n\nToken compatibility with available toolingIf you want your token to be compatible out of the box with all the tooling available (e.g., the Arbitrum bridge), we recommend that you keep the implementation of the IArbToken interface as close as possible to the L2GatewayToken implementation example.For example, if an allowance check is added to the bridgeBurn() function, the token will not be easily withdrawable through the Arbitrum bridge UI, as the UI does not prompt an approval transaction of tokens by default (it expects the tokens to follow the recommended L2GatewayToken implementation).\nStep 2: Create a token and deploy it on the parent chain​\nWe‘ll begin the process by creating and deploying a sample token on the parent chain that we will later bridge. If you already have a token contract on the parent chain, you don’t need to perform this step.\nHowever, you will need to upgrade the contract if it doesn’t include the required methods described in the previous step.\nWe first create a standard ERC-20 contract using OpenZeppelin’s implementation. We make only one adjustment to that implementation, for simplicity, although it is not required: we specify an initialSupply to be pre-minted and sent to the deployer address upon creation.\nWe’ll also add the required methods to make our token bridgeable via the generic-custom gateway.\n// SPDX-License-Identifier: MITpragma solidity ^0.8.0;import \"./interfaces/ICustomToken.sol\";import \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";import \"@openzeppelin/contracts/access/Ownable.sol\";/** * @title Interface needed to call function registerTokenToL2 of the L1CustomGateway */interface IL1CustomGateway { function registerTokenToL2( address _l2Address, uint256 _maxGas, uint256 _gasPriceBid, uint256 _maxSubmissionCost, address _creditBackAddress ) external payable returns (uint256);}/** * @title Interface needed to call function setGateway of the L2GatewayRouter */interface IL2GatewayRouter { function setGateway( address _gateway, uint256 _maxGas, uint256 _gasPriceBid, uint256 _maxSubmissionCost, address _creditBackAddress ) external payable returns (uint256);}contract L1Token is Ownable, ICustomToken, ERC20 { address private customGatewayAddress; address private routerAddress; bool private shouldRegisterGateway; /** * @dev See {ERC20-constructor} and {Ownable-constructor} * * An initial supply amount is passed, which is preminted to the deployer. */ constructor(address _customGatewayAddress, address _routerAddress, uint256 _initialSupply) ERC20(\"L1CustomToken\", \"LCT\") { customGatewayAddress = _customGatewayAddress; routerAddress = _routerAddress; _mint(msg.sender, _initialSupply * 10 ** decimals()); } /// @dev we only set shouldRegisterGateway to true when in `registerTokenOnL2` function isArbitrumEnabled() external view override returns (uint8) { require(shouldRegisterGateway, \"NOT_EXPECTED_CALL\"); return uint8(0xb1); } /// @dev See {ICustomToken-registerTokenOnL2} function registerTokenOnL2( address l2CustomTokenAddress, uint256 maxSubmissionCostForCustomGateway, uint256 maxSubmissionCostForRouter, uint256 maxGasForCustomGateway, uint256 maxGasForRouter, uint256 gasPriceBid, uint256 valueForGateway, uint256 valueForRouter, address creditBackAddress ) public override payable onlyOwner { // we temporarily set `shouldRegisterGateway` to true for the callback in registerTokenToL2 to succeed bool prev = shouldRegisterGateway; shouldRegisterGateway = true; IL1CustomGateway(customGatewayAddress).registerTokenToL2{ value: valueForGateway }( l2CustomTokenAddress, maxGasForCustomGateway, gasPriceBid, maxSubmissionCostForCustomGateway, creditBackAddress ); IL2GatewayRouter(routerAddress).setGateway{ value: valueForRouter }( customGatewayAddress, maxGasForRouter, gasPriceBid, maxSubmissionCostForRouter, creditBackAddress ); shouldRegisterGateway = prev; } /// @dev See {ERC20-transferFrom} function transferFrom( address sender, address recipient, uint256 amount ) public override(ICustomToken, ERC20) returns (bool) { return super.transferFrom(sender, recipient, amount); } /// @dev See {ERC20-balanceOf} function balanceOf(address account) public view override(ICustomToken, ERC20) returns (uint256) { return super.balanceOf(account); }}\nWe now deploy that token to the parent chain.\nconst { ethers } = require('hardhat');const { providers, Wallet } = require('ethers');const { getArbitrumNetwork } = require('@arbitrum/sdk');require('dotenv').config();const walletPrivateKey = process.env.DEVNET_PRIVKEY;const l1Provider = new providers.JsonRpcProvider(process.env.L1RPC);const l2Provider = new providers.JsonRpcProvider(process.env.L2RPC);const l1Wallet = new Wallet(walletPrivateKey, l1Provider);/** * For the purpose of our tests, here we deploy an standard ERC20 token (L1Token) to L1 * It sends its deployer (us) the initial supply of 1000 */const main = async () => { /** * Use l2Network to get the token bridge addresses needed to deploy the token */ const l2Network = await getArbitrumNetwork(l2Provider); const l1Gateway = l2Network.tokenBridge.l1CustomGateway; const l1Router = l2Network.tokenBridge.l1GatewayRouter; /** * Deploy our custom token smart contract to L1 * We give the custom token contract the address of l1CustomGateway and l1GatewayRouter as well as the initial supply (premine) */ console.log('Deploying the test L1Token to L1:'); const L1Token = await (await ethers.getContractFactory('L1Token')).connect(l1Wallet); const l1Token = await L1Token.deploy(l1Gateway, l1Router, 1000); await l1Token.deployed(); console.log(`L1Token is deployed to L1 at ${l1Token.address}`); /** * Get the deployer token balance */ const tokenBalance = await l1Token.balanceOf(l1Wallet.address); console.log(`Initial token balance of deployer: ${tokenBalance}`);};main() .then(() => process.exit(0)) .catch((error) => { console.error(error); process.exit(1); });\nStep 3: Create a token and deploy it on the child chain​\nWe’ll now create and deploy the counterpart of the token we created on the parent chain to the child chain.\nWe’ll create a standard ERC-20 contract using OpenZeppelin’s implementation, and add the required methods from IArbToken.\n// SPDX-License-Identifier: Apache-2.0pragma solidity ^0.8.0;import \"./interfaces/IArbToken.sol\";import \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";contract L2Token is ERC20, IArbToken { address public l2Gateway; address public override l1Address; modifier onlyL2Gateway() { require(msg.sender == l2Gateway, \"NOT_GATEWAY\"); _; } constructor(address _l2Gateway, address _l1TokenAddress) ERC20(\"L2CustomToken\", \"LCT\") { l2Gateway = _l2Gateway; l1Address = _l1TokenAddress; } /** * @notice should increase token supply by amount, and should only be callable by the L2Gateway. */ function bridgeMint(address account, uint256 amount) external override onlyL2Gateway { _mint(account, amount); } /** * @notice should decrease token supply by amount, and should only be callable by the L2Gateway. */ function bridgeBurn(address account, uint256 amount) external override onlyL2Gateway { _burn(account, amount); } // Add any extra functionality you want your token to have.}\nWe now deploy that token to the child chain.\nconst { ethers } = require('hardhat');const { providers, Wallet } = require('ethers');const { getArbitrumNetwork } = require('@arbitrum/sdk');require('dotenv').config();const walletPrivateKey = process.env.DEVNET_PRIVKEY;const l2Provider = new providers.JsonRpcProvider(process.env.L2RPC);const l2Wallet = new Wallet(walletPrivateKey, l2Provider);const l1TokenAddress = '<address of the l1 token deployed in the previous step>';/** * For the purpose of our tests, here we deploy an standard ERC20 token (L2Token) to L2 */const main = async () => { /** * Use l2Network to get the token bridge addresses needed to deploy the token */ const l2Network = await getArbitrumNetwork(l2Provider); const l2Gateway = l2Network.tokenBridge.childCustomGateway; /** * Deploy our custom token smart contract to L2 * We give the custom token contract the address of childCustomGateway as well as the address of the counterpart L1 token */ console.log('Deploying the test L2Token to L2:'); const L2Token = await (await ethers.getContractFactory('L2Token')).connect(l2Wallet); const l2Token = await L2Token.deploy(l2Gateway, l1TokenAddress); await l2Token.deployed(); console.log(`L2Token is deployed to L2 at ${l2Token.address}`);};main() .then(() => process.exit(0)) .catch((error) => { console.error(error); process.exit(1); });\nStep 4: Register the custom token with the generic-custom gateway​\nOnce we deploy both our contracts on their respective chains, it’s time to register the token in the generic-custom gateway.\nAs mentioned earlier, the parent chain token must complete the registration, and we’ve implemented the registerTokenOnL2 function to accomplish this. So now we only need to call that function.\nWhen using this function, you will take two actions:\n\nCall the function registerTokenToL2 of L1CustomGateway. This call will change the l1ToL2Token internal mapping it holds and send a retryable ticket to the counterpart L2CustomGateway contract on the child chain, setting its mapping to the new values as well.\nCall the function setGateway of L1GatewayRouter. This call will update the l1TokenToGateway internal mapping it holds and send a retryable ticket to the counterpart L2GatewayRouter contract on the child chain to set its mapping to the new values.\n\nTo simplify the process, we'll use Arbitrum's SDK. We'll call the registerCustomToken method of the AdminErc20Bridger class, which will call the registerTokenOnL2 method on the token passed as a parameter.\n/** * Register custom token on our custom gateway */const adminTokenBridger = new AdminErc20Bridger(l2Network);const registerTokenTx = await adminTokenBridger.registerCustomToken(l1CustomToken.address, l2CustomToken.address, l1Wallet, l2Provider);const registerTokenRec = await registerTokenTx.wait();console.log(`Registering token txn confirmed on L1! 🙌 L1 receipt is: ${registerTokenRec.transactionHash}`);/** * The L1 side is confirmed; now we listen and wait for the L2 side to be executed; we can do this by computing the expected txn hash of the L2 transaction. * To compute this txn hash, we need our message's \"sequence numbers\", unique identifiers of each L1 to L2 message. * We'll fetch them from the event logs with a helper method. */const l1ToL2Msgs = await registerTokenRec.getParentToChildMessages(l2Provider);/** * In principle, a single L1 txn can trigger any number of L1-to-L2 messages (each with its own sequencer number). * In this case, the registerTokenOnL2 method created 2 L1-to-L2 messages; * - (1) one to set the L1 token to the Custom Gateway via the Router, and * - (2) another to set the L1 token to its L2 token address via the Generic-Custom Gateway * Here, We check if both messages are redeemed on L2 */expect(l1ToL2Msgs.length, 'Should be 2 messages.').to.eq(2);const setTokenTx = await l1ToL2Msgs[0].waitForStatus();expect(setTokenTx.status, 'Set token not redeemed.').to.eq(ParentToChildMessageStatus.REDEEMED);const setGateways = await l1ToL2Msgs[1].waitForStatus();expect(setGateways.status, 'Set gateways not redeemed.').to.eq(ParentToChildMessageStatus.REDEEMED);console.log('Your custom token is now registered on our custom gateway 🥳 Go ahead and make the deposit!');\nConclusion​\nUpon completion, the parent and child chain tokens are connected via the generic-custom gateway.\nYou can bridge tokens between the parent and child chain using the origin parent chain token and the custom token deployed on the child chain, along with the router and gateway contracts from each layer.\nFor an example of bridging a token from the parent to the child chain using Arbitrum's SDK, check out How to bridge tokens via Arbitrum's standard ERC-20 gateway, specifically Steps 2-5.\nFrequently asked questions​\nCan I run the same register token process multiple times for the same parent chain token?​\nNo, you can only register once a child chain token for the same parent chain token. After that, the call to registerTokenToL2 will revert if it runs again.\nWhat can I do if my parent chain token is not upgradable?​\nAs mentioned on the concept page, token registration can also be completed as a chain owner registration via an Arbitrum DAO proposal.\nCan I set up the generic-custom gateway after a standard ERC-20 token has been deployed on the child chain?​\nYes, if your token has a standard ERC-20 counterpart on the child chain, you can follow the process outlined on this page to register your custom child chain token. At that moment, your parent chain token will have two counterpart tokens on the child chain, but only your new custom child chain token will be minted when depositing tokens from the parent chain (parent-to-child chain bridging). Both child chain tokens will be withdrawable (child-to-parent chain bridging), so users holding the old standard ERC-20 token will be able to withdraw back to the parent chain (using the L2CustomGateway contract instead of the bridge UI) and then deposit to the child chain to get the new custom child chain tokens.\nNext steps​\nYour token is now configured for bridging! Users can:\n\nDeposit tokens to the child chain\nWithdraw tokens back to the parent chain\n\nResources​\n\nConcept page: Token Bridge\nArbitrum SDK\nToken bridge contract addresses\nStep 1: Review the prerequisitesStep 2: Create a token and deploy it on the parent chainStep 3: Create a token and deploy it on the child chainStep 4: Register the custom token with the generic-custom gatewayConclusionFrequently asked questionsCan I run the same register token process multiple times for the same parent chain token?What can I do if my parent chain token is not upgradable?Can I set up the generic-custom gateway after a standard ERC-20 token has been deployed on the child chain?Next stepsResources","tokens":3997,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261822318,"hash":"4e26256f78432ad9520b88a27fdde76537178df1"}
{"url":"https://specs.optimism.io/protocol/stage-1.html","domain":"specs.optimism.io","title":"Stage 1 Roles and Requirements - OP Stack Specification","text":"Stage 1 Roles and Requirements\n\nTable of Contents\n\nOverview\nDefinitions\n\nWithdrawal Liveness\nWithdrawal Safety\nProxy Admin Owner\nGuardian\nPause Deputy\nPause Mechanism\nPause Identifier\nStage 1 Rollup\n\nOP Stack Stage 1 Design\n\nPermissionless Fault Proofs\nSecurity Council\nProxy Admin Owner\nGuardian\nPause Deputy\nArchitecture Diagram\n\nInvariants\n\niS1-001\nImpact\niS1-002: The Pause Deputy can only cause a temporary Withdrawal Liveness failure\n\nImpact\n\niS1-003: The Guardian can revoke the Pause Deputy role at any time\n\nImpact\n\nOverview\nThis document describes the requirements necessary for an OP Stack implementation to satisfy the\nStage 1 decentralization requirements as defined by L2BEAT. It also defines the specific\nroles and capabilities for an OP Stack chain in the standard configuration that will satisfy these\nrequirements.\nDefinitions\nWithdrawal Liveness\nWithdrawal Liveness is the ability for users to execute valid withdrawals out of any contract\nthat stores ETH or tokens within an OP Chain's set of smart contracts. We tend to refer to\nWithdrawal Liveness in the context of the OptimismPortal and the rest of the Standard Bridge\nsystem (i.e., the StandardBridge and CrossDomainMessenger contracts) because this is where a\nmajority of the ETH/tokens in the system live. However, this also applies to bonds deposited into\ndispute game contracts (and ultimately into the DelayedWETH contract).\nWithdrawal Safety\nWithdrawal Safety is the condition that users are not able to execute invalid withdrawals\nout of any contract that stores ETH or tokens within an OP Chain's set of smart contracts.\nGenerally speaking \"liveness\" means nothing gets bricked and \"safety\" means nothing gets stolen.\nProxy Admin Owner\nThe Proxy Admin Owner is a dedicated role in the OP Stack that is permitted to upgrade the\ncontracts that make up an OP Stack chain's onchain footprint. In the Superchain, the Upgrade\nController role is held jointly in a 2/2 of the Optimism Security Council and the Optimism\nFoundation.\nGuardian\nThe Guardian is a dedicated role in the OP Stack that is permitted to trigger certain actions\nto maintain the security of an OP Chain or set of OP Chains in case of a bug in the protocol. In\nthe Superchain, the Guardian role is held by the Optimism Security Council.\nPause Deputy\nThe Pause Deputy is a dedicated role managed by the Guardian that can execute the\nPause Mechanism. An OP Chain does not necessarily need to assign a Pause\nDeputy. The Pause Deputy is capable of triggering the Pause Mechanism but does not have the ability\nto reset the mechanism or unpause the system.\nThe Pause Deputy is an optional role within an OP Chain and can be configured if the Guardian is\na Safe that installs the Deputy Pause Module.\nPause Mechanism\nThe Pause Mechanism is a tool that permits the Guardian or the\nPause Deputy to pause the execution of certain actions on one or more OP Chains.\nBroadly speaking, the Pause Mechanism is designed to impact the liveness of the system such that\nan attack on the system is unable to actually remove ETH or ERC-20 tokens from the bridge or any\nother contract that stores ETH and/or tokens.\nThe Pause Mechanism is temporary and is active up to a fixed maximum amount of time before\nexpiring. A pause cannot be triggered again unless the mechanism is explicitly reset by the\nGuardian. That is, if the Pause Mechanism is triggered and not reset by the Guardian,\nit will expire, the system will automatically become unpaused, and the system cannot be paused\nagain.\nThe Pause Mechanism can be applied globally or to individual systems. Which level the pause applies\nto is determined by the Pause Identifier provided when executing or checking\npause status.\nChains using the Standard Configuration of the OP Stack use a pause expiry of 3 months. Because\nthe Pause Mechanism can be applied to both local and global scopes, the pause could be chained to,\nfor instance, pause the local system first and then the global system shortly before the local\npause expires. The total potential pause time is therefore double the expiry period (6 months).\nThe Guardian may explicitly unpause the system rather than waiting for the pause to expire. If this\nhappens, the pause is automatically reset such that it can be used again. The Guardian can reset\nthe pause at any time so that it can be used again, even if the pause is currently active. If the\npause is reset when it is currently active, the pause can be triggered again, thereby resetting\nthe 6 month expiry timer (on a per address identifier basis).\nPause Identifier\nThe Pause Identifier is an address parameter used to specify the scope of a pause action. This\nidentifier determines which systems or chains are affected by the pause:\n\nWhen the identifier is the zero address (0x0000000000000000000000000000000000000000), the pause\napplies globally to all chains sharing the SuperchainConfig contract.\nWhen the identifier is a non-zero address, the pause applies specifically to the chain or set of\nchains associated with that identifier.\n\n(-op-contracts/v4.1.0) The identifier must be an ETHLockbox address or address(0). This allows for targeted\npausing of either specific chains, the interop set (which shares an ETHLockbox contract), or all\nchains that share the same SuperchainConfig when address(0) is used as the identifier.\n(-op-contracts/v4.1.0) OP Chains are expected to integrate with the SuperchainConfig via their SystemConfig\ncontract, which will check for the status of the pause by passing along the address of the\nETHLockbox being used within that system as the Pause Identifier.\n(+op-contracts/v4.1.0) The identifier must be an ETHLockbox address, an OptimismPortal address, or\naddress(0). This allows for targeted pausing of specific chains, the interop set (which shares an\nETHLockbox contract), or all chains that share the same SuperchainConfig when address(0) is\nused as the identifier. When the ETHLockbox\nCustomizable Feature is enabled, the ETHLockbox\naddress is to be used as the pause identifier. When the ETHLockbox feature is disabled or the\nETHLockbox address has not yet been configured, the OptimismPortal address is to be used.\nStage 1 Rollup\nL2BEAT defines that a system can be considered a \"Stage 1 Rollup\" system if it has the following\nproperty:\n\nIf the System has a Security Council (as defined by L2BEAT) the only way\n(excluding bugs) for the System to experience an indefinite\nWithdrawal Liveness failure or any\nWithdrawal Safety failure is through a malicious majority of at least 75%\nof the Security Council.\n\nOP Stack Stage 1 Design\nThe above definitions and requirements have a number of concrete implications for the Standard\nConfiguration of the OP Stack. We therefore specify the following architecture for a Stage 1 OP\nStack chain.\nPermissionless Fault Proofs\nA Stage 1 OP Stack chain must operate a permissionless Fault Proof system.\nSecurity Council\nA Stage 1 OP Stack chain must have a Security Council.\nProxy Admin Owner\nThe Proxy Admin Owner role in the OP Stack is a privileged role that is\nallowed to upgrade the smart contracts that make up an OP Stack chain's onchain footprint. This\nrole must require sign-off from the Security Council. This specifically means that the role can\neither be entirely held by the Security Council or by some other configuration as long as the\nSecurity Council is a required signatory (e.g., a 2/2 multisig).\nIn addition to the ability to upgrade all smart contracts, the Proxy Admin Owner is the only\naddress authorized to perform the following actions:\n\nDisputeGameFactory.setImplementation\nDisputeGameFactory.setInitBond\nDelayedWETH.hold\nDelayedWETH.recover\n\nThe Proxy Admin Owner can theoretically cause an indefinite\nWithdrawal Liveness failure as well as\nWithdrawal Safety failures. This is aligned with the Stage 1 definition\nbecause the Security Council is a required signatory on this role.\nGuardian\nThe Guardian role in the OP Stack is a privileged role that is allowed to execute\ncertain safety-net actions in the case that a bug exists in the OP Stack smart contracts. This role\nmust be held by the Security Council in the form of a 1/1 Safe owned by the Security Council.\nThe Guardian is the only address that is permitted to execute the following actions:\n\nSuperchainConfig.pause()\nSuperchainConfig.unpause()\nSuperchainConfig.reset()\nAnchorStateRegistry.setRespectedGameType()\nAnchorStateRegistry.updateRetirementTimestamp()\nAnchorStateRegistry.blacklistDisputeGame()\n\nThe Guardian can theoretically cause an indefinite Withdrawal Liveness\nfailure as well as Withdrawal Safety failures. This is aligned with the Stage\n1 definition because the Security Council holds this role.\nPause Deputy\nThe Pause Deputy is a role that can be assigned by the Guardian. The Pause Deputy\nis explicitly permitted to cause a temporary Withdrawal Liveness failure.\nBecause the Pause Deputy can only cause a temporary Withdrawal Liveness failure, the Guardian can\nassign this role to any actor it deems fit to utilize the role without violating any\ninvariants.\nArchitecture Diagram\nThe following diagram outlines the control relationships between the contracts in the system:\n\nNote: in the diagram above, the\nProtocolVersionscontract is\nlisted as \"Out of Protocol\", because the decision to follow the version signals in the contract is\noptional. It is included here for completeness, but it does not impact\nWithdrawal Safety or Withdrawal Liveness.\nInvariants\niS1-001\nA permanent Withdrawal Liveness or Withdrawal Safety failure requires 75% of the Security Council (w/o bugs).\nThis is the core invariant for Stage 1 and aligns with the definition by L2BEAT from\nJanuary 2025. We can define additional properties about roles specific to the OP Stack as long as\nthey align with this invariant. Note that this invariant does NOT consider the impact of bugs in\nsmart contracts on the rest of the protocol. That is, this invariant only holds strongly under the\nassumption that no such bugs exist.\nImpact\nSeverity: High/Critical\nIf broken, it must be assumed that some other actor has the ability to cause a permanent\nWithdrawal Liveness or Withdrawal Safety failure. We\nconsider any violation of this invariant to be a High severity issue, but this issue potentially\nbecomes Critical if the actor that has this ability is not another reasonably trusted entity.\niS1-002: The Pause Deputy can only cause a temporary Withdrawal Liveness failure\nWe require that any action that the Pause Deputy can take in the system can\nonly cause a temporary Withdrawal Liveness failure. This is required\nbecause the Security Council must explicitly trigger any action that results either an indefinite\nWithdrawal Liveness failure or a Withdrawal Safety failure.\nImpact\nSeverity: High\nIf this invariant were broken, the Pause Deputy could be able to cause either a\nWithdrawal Safety failure or a permanent Withdrawal Liveness failure. Either\nfailure mode would be a violation of the definition of Stage 1 as of January 2025.\niS1-003: The Guardian can revoke the Pause Deputy role at any time\nWe require that the Guardian be able to revoke the Pause Deputy role\nat any time. This condition is necessary to prevent a misbehaving Pause Deputy from continuing to\ntrigger the Pause Mechanism when this would not be desired by the Guardian\nitself.\nImpact\nSeverity: High\nIf this invariant were broken, assuming that iS1-002 the Pause Deputy would potentially\nbe able to repeatedly trigger the Pause Mechanism even if the Guardian does not want this to\nhappen. We consider this to be a High severity condition because the Guardian can choose not to\nrenew the pause to allow the system to operate if truly necessary.","tokens":2914,"squid":"ink-governance","role":"Council Listener","at":1791261825778,"hash":"ea21227194c68cdb68f2594afbedc0af831c7cb9"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/token-bridging","domain":"docs.arbitrum.io","title":"Token bridging | Arbitrum Docs","text":"✏️Request an updateThe Arbitrum protocol itself has no notion of token standards and gives no built-in advantage or special recognition to any particular token bridge. In this article, we describe the \"canonical bridge,\" which was implemented by Offchain Labs, and should be the primary bridge most users and applications use; it is (effectively) a decentralized app with contracts on both Ethereum (parent chain) and Arbitrum (child chain) that leverages Arbitrum's cross-chain messaging protocol to achieve basic desired token-bridging functionality. We recommend that you use it! For the protocol-level mechanics this bridge sits on top of, see Bridging from a parent chain to a child chain and Child to parent chain messaging.\nDesign rationale​\nIn our token bridge design, we use the term \"gateway\" as per this proposal; i.e., one of a pair of contracts on two different domains (i.e., Ethereum and an Arbitrum chain), used to facilitate cross-domain asset transfers.\nWe now describe some core goals that motivated the design of our bridging system.\nCustom gateway functionality​\nFor many ERC-20 tokens, \"standard\" bridging functionality is sufficient, which entails the following: a token contract on Ethereum is associated with a \"paired\" token contract on Arbitrum.\nDepositing a token involves escrowing a certain amount of the token in a parent chain bridge contract, and minting the same amount at the paired token contract on a child chain. Then, on the child chain, the paired contract behaves much like a normal ERC-20 token contract. Withdrawing entails burning a specific amount of the token in the child chain contract, which can be claimed later from the parent chain bridge contract.\nMany tokens, however, require custom gateway systems, the possibilities of which are hard to generalize, e.g.,:\n\nTokens which accrue interest to their holders need to ensure that the interest is dispersed properly across layers, and doesn't simply accrue to the bridge contracts\nOur cross-domain WETH implementations require tokens to be wrapped and unwrapped as they move across layers.\n\nThus, our bridge architecture must allow not just the standard deposit and withdrawal functionalities, but also for new, custom gateways to be dynamically added over time.\nCanonical child chain representation per parent chain token contract​\nHaving multiple custom gateways is beneficial, but we also want to avoid a situation in which a single parent chain token that utilizes our bridging system can be represented at multiple addresses/contracts on the child chain, as this adds significant friction and confusion for users and developers. Thus, we need a way to track which parent chain token uses which gateway, and in turn, to have a canonical address oracle that maps the tokens' addresses across the Ethereum and Arbitrum domains.\nCanonical token bridge implementation​\nWith this in mind, we provide an overview of our token bridging architecture.\nOur architecture consists of three types of contracts:\n\nAsset contracts: These are the token contracts themselves, i.e., an ERC-20 on the parent chain and its counterpart on Arbitrum.\nGateways: Pairs of contracts (one on the parent chain, one on the child chain) that implement a particular type of cross-chain asset bridging.\nRouters: Exactly two contracts (one on the parent chain, one on the child chain) that route each asset to its designated gateway.\n\nAll Ethereum-to-Arbitrum token transfers are initiated via the router contract on the parent chain, specifically the L1GatewayRouter contract. L1GatewayRouter forwards the token's deposit call to the appropriate gateway contract on the parent chain, the L1ArbitrumGateway contract. L1GatewayRouter is responsible for mapping the parent chain token addresses to L1Gateway contracts, thus acting as a parent/child chain address oracle and ensuring each token corresponds to only one gateway. The L1ArbitrumGateway then communicates to its counterpart gateway contract on the child chain, the L2ArbitrumGateway contract (typically/expectedly via retryable tickets).\n\nSimilarly, Arbitrum-to-Ethereum transfers initiate via the router contract on the child chain, specifically the L2GatewayRouter contract, which in turn calls the token's gateway contract on the child chain. This L2ArbitrumGateway contract in turn communicates to its corresponding gateway contract on the parent chain, the L1ArbitrumGateway contract (typically/expectedly via sending child-to-parent messages to the outbox).\n\nFor any given gateway pairing, we require that calls initiate through the corresponding router (L1GatewayRouter or L2GatewayRouter), and that the gateways conform to the TokenGateway interfaces; the TokenGateway interfaces should be flexible and extensible enough to support any bridging functionality a particular token may require.\nThe standard ERC-20 gateway​\nBy default, any ERC-20 token on a parent chain that isn't registered to a gateway can be bridged permissionlessly through the StandardERC20Gateway.\nYou can use the bridge UI or follow the instructions in How to bridge tokens via Arbitrum’s standard ERC-20 gateway to bridge a token to a child chain via this gateway.\nExample: Standard Arb-ERC-20 deposit and withdraw​\nTo help illustrate what this all looks like in practice, let's go through the steps of what depositing and withdrawing SomeERC20Token via our standard ERC-20 gateway looks like. Here, we're assuming that SomeERC20Token has already been registered in the L1GatewayRouter to use the standard ERC-20 gateway.\nDeposits​\n\nA user calls L1GatewayRouter.outboundTransferCustomRefund [1] (with SomeERC20Token's parent chain address as an argument).\nL1GatewayRouter looks up SomeERC20Token's gateway, and finds that it's the standard ERC-20 gateway (the L1ERC20Gateway contract).\nL1GatewayRouter calls L1ERC20Gateway.outboundTransferCustomRefund, forwarding the appropriate parameters.\nL1ERC20Gateway escrows the tokens sent and creates a retryable ticket to trigger L2ERC20Gateway's finalizeInboundTransfer method on the child chain.\nL2ERC20Gateway.finalizeInboundTransfer mints the appropriate amount of tokens at the arbSomeERC20Token contract on the child chain.\n\n❗️ [1] Please keep in mind that some older custom gateways might not have outboundTransferCustomRefund implemented, and L1GatewayRouter.outboundTransferCustomRefund does not fallback to outboundTransfer. In those cases, please use the function L1GatewayRouter.outboundTransfer.\ninfoarbSomeERC20Token is an instance of StandardArbERC20, which includes bridgeMint and bridgeBurn methods only callable by the L2ERC20Gateway.\nWithdrawals​\n\nOn Arbitrum, a user calls L2GatewayRouter.outBoundTransfer, which in turn calls outBoundTransfer on arbSomeERC20Token's gateway (i.e., L2ERC20Gateway).\nThis burns arbSomeERC20Token tokens, and calls ArbSys with an encoded message to L1ERC20Gateway.finalizeInboundTransfer, which will eventually execute on the parent chain.\nAfter the dispute window expires and the assertion with the user's transaction is confirmed, a user can call Outbox.executeTransaction, which in turn calls the encoded L1ERC20Gateway.finalizeInboundTransfer message, releasing the user's tokens from the L1ERC20Gateway contract's escrow.\n\nThe Arbitrum generic-custom gateway​\nJust because a token has requirements beyond the offerings of the standard ERC-20 gateway, that doesn't necessarily mean that a unique gateway needs to be tailor-made for the token in question. Our generic-custom gateway is flexible enough to be suitable for most (but not necessarily all) custom fungible token needs. As a general rule:\nIf your custom token can increase its supply (i.e., mint) directly on the child chain, and you want the child chain-minted tokens to be withdrawable back to the parent chain and recognized by the parent chain contract, it will probably require its own special gateway. Otherwise, the generic-custom gateway is likely the right solution for you!\nSome examples of token features suitable for the generic-custom gateway:\n\nA child chain token contract upgradable via a proxy\nA child chain token contract that includes address allowlisting/denylisting\nThe deployer determines the address of the child chain token contract\n\nSetting up your token with the generic-custom gateway​\nFollow the steps below to set up your token for use with the generic-custom gateway. You can also find more detailed instructions on the page How to bridge tokens via Arbitrum’s generic-custom gateway.\n0. Have a parent chain token\nYour token on the parent chain should conform to the ICustomToken interface (see TestCustomTokenL1 for an example implementation). Crucially, it must have an isArbitrumEnabled method in its interface.\n1. Deploy your token on Arbitrum\nYour token should conform to the minimum IArbToken interface; i.e., it should have bridgeMint and bridgeBurn methods only callable by the L2CustomGateway contract, and the address of its corresponding Ethereum token accessible via l1Address. For an example implementation, see L2GatewayToken.\n\nToken compatibility with available toolingIf you want your token to be compatible out of the box with all the tooling available (e.g., the Arbitrum bridge), we recommend that you keep the implementation of the IArbToken interface as close as possible to the L2GatewayToken implementation example.For example, if an allowance check is added to the bridgeBurn() function, the token will not be easily withdrawable through the Arbitrum bridge UI, as the UI does not prompt an approval transaction of tokens by default (it expects the tokens to follow the recommended L2GatewayToken implementation).\n2. Register your token on the parent chain to your token on the child chain via the L1CustomGateway contract\nHave your parent chain token's contract make an external call to L1CustomGateway.registerTokenToL2. Performing the registration can be completed as a chain-owner registration via an Arbitrum DAO proposal.\n3. Register your token on the parent chain to the L1GatewayRouter\nAfter your token's registration to the generic-custom gateway is complete, have your parent chain token's contract make an external call to L1GatewayRouter.setGateway; performing the registration can also be completed as a chain-owner registration via an Arbitrum DAO proposal.\nWe are here to helpIf you have questions about your custom token needs, please feel free to reach out to us on our Discord server.\nOther flavors of gateways​\nNote that in the system described above, one pair of gateway contracts handles the bridging of many ERC-20's; i.e., many ERC-20's on the parent chain are each paired with their own ERC-20's on Arbitrum via a single gateway contract pairing. Other gateways may have different relationships with the contracts that they bridge.\nTake our wrapped Ether implementation for example: here, a single WETH contract on the parent chain is connected to a single WETH contract on the child chain. When transferring WETH from one domain to another, the parent/child chain gateway architecture is used to unwrap the WETH on domain A, transfer the now-unwrapped Ether, and then re-wrap it on domain B. This process ensures that WETH can behave on Arbitrum in the same way users are accustomed to it behaving on Ethereum, while ensuring that all WETH tokens are always fully collateralized on the layer on which they reside.\nRegardless of a token's complexity in bridging needs, it is possible to create a gateway to accommodate it within our canonical bridging system.\nYou can find an example of implementation of a custom gateway in the page How to bridge tokens via a custom gateway.\nDemos​\nOur How to bridge tokens section provides an example of interacting with Arbitrum's token bridge via the Arbitrum SDK.\nA word of caution on bridges (aka, \"I've got a bridge to sell you\")​\nCross-chain bridging is an exciting design space; alternative bridge designs can potentially offer faster withdrawals, interoperability with other chains, and different trust assumptions with their own potentially valuable UX tradeoffs, etc. They can also potentially be completely insecure and/or outright scams. Users should treat other, non-canonical bridge applications the same way they treat any application running on Arbitrum, and exercise caution and due diligence before entrusting them with their value.Design rationaleCustom gateway functionalityCanonical child chain representation per parent chain token contractCanonical token bridge implementationThe standard ERC-20 gatewayExample: Standard Arb-ERC-20 deposit and withdrawThe Arbitrum generic-custom gatewaySetting up your token with the generic-custom gatewayOther flavors of gatewaysDemosA word of caution on bridges (aka, \"I've got a bridge to sell you\")","tokens":3185,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261832233,"hash":"eed8ec7000d9fc77bb4cff59bb6a8977d0e6448f"}
{"url":"https://specs.optimism.io/protocol/configurability.html","domain":"specs.optimism.io","title":"Configurability - OP Stack Specification","text":"OP Stack Configurability\n\nTable of Contents\n\nConsensus Parameters\n\nBatch Inbox address\nBatcher Hash\nChain ID\nProof Maturity Delay\nDispute Game Finality\nRespected Game Type\nFault Game Max Depth\nFault Game Split Depth\nMax Game Clock Duration\nGame Clock Extension\nBond Withdrawal Delay\nMinimum Large Preimage Proposal Size\nLarge Preimage Proposal Challenge Period\nFault Game Absolute Prestate\nFault Game Genesis Block\nFault Game Genesis Output Root\nFee Scalar\nGas Limit\nGenesis state\nL2 block time\nResource config\nSequencing window Size\nStart block\nSuperchain target\nGovernance Token\nOperator Fee Scalar\nOperator Fee Constant\nDA Footprint Gas Scalar\nMinimum Base Fee\nResource Config\n\nPolicy Parameters\n\nData Availability Type\nBatch submission frequency\nOutput frequency\n\nAdmin Roles\n\nL1 Proxy Admin\nL1 ProxyAdmin owner\nL2 Proxy Admin\nL2 ProxyAdmin owner\nSystem Config Owner\n\nService Roles\n\nBatch submitter address\nChallenger address\nGuardian address\nProposer address\nSequencer P2P / Unsafe head signer\n\nWhen deploying the OP Stack software to a production environment,\ncertain parameters about the protocol can be configured. These\nconfigurations can include a variety of parameters which affect the\nresulting properties of the blockspace in question.\nThere are four categories of OP Stack configuration options:\n\nConsensus Parameters: Parameters and properties of the chain that may\nbe set at genesis and fixed for the lifetime of the chain, or may be\nchangeable through a privileged account or protocol upgrade.\nPolicy Parameters: Parameters of the chain that might be changed without\nbreaking consensus. Consensus is enforced by the protocol, while policy parameters\nmay be changeable within constraints imposed by consensus.\nAdmin Roles: These roles can upgrade contracts, change role owners,\nor update protocol parameters. These are typically cold/multisig wallets not\nused directly in day to day operations.\nService Roles: These roles are used to manage the day-to-day\noperations of the chain, and therefore are often hot wallets.\n\nEach category also defines the standard configuration values for it's given parameters.\nStandard configuration is the set of requirements for an OP Stack chain to be considered a\nStandard Chain within the superchain.\nThese requirements are currently a draft, pending governance approval.\nThe recommended way to deploy L1 contracts for an OP chain that meet the standard configuration will be with the\nOP Contracts Manager.\nConsensus Parameters\nBatch Inbox address\nDescription: L1 address where calldata/blobs are posted (\nsee Batcher Transaction). Defined in the rollup\nconfiguration; as of SystemConfig v4.0.0 it is no longer stored onchain.\nAdministrator: Static\nRequirement: Current convention is\nversionByte || keccak256(bytes32(chainId))[:19], where || denotes\nconcatenation, versionByte is 0x00, and chainId is a uint256.\nNotes: It is recommended, but not required, to follow this convention.\nBatcher Hash\nDescription: A versioned hash of the current authorized batcher sender(s).\nAdministrator: System Config Owner\nRequirement: bytes32(uint256(uint160(batchSubmitterAddress)))\nNotes: Batch Submitter address padded with zeros to fit 32 bytes.\nChain ID\nDescription: Unique ID of Chain used for TX signature validation.\nAdministrator: Static\nRequirement: Foundation-approved, globally unique value 1.\nNotes: Foundation will ensure chains are responsible with their chain IDs until there's a governance process in\nplace.\nProof Maturity Delay\nDescription: The length of time that must pass between proving and finalizing a withdrawal.\nAdministrator: L1 Proxy Admin\nRequirement: 7 days\nNotes: High security. Excessively safe upper bound that leaves enough time to consider social layer solutions to a\nhack if necessary. Allows enough time for other network participants to challenge the integrity of the corresponding\noutput root.\nDispute Game Finality\nDescription: The amount of time given to the Guardian role\nto blacklist a resolved dispute game before\nany withdrawals proven against it can be finalized, in the case of a system failure.\nAdministrator: L1 Proxy Admin\nRequirement: 3.5 days\nNotes: High security. Allows enough time for the Guardian to blacklist games.\nRespected Game Type\nDescription: The respected game type of the OptimismPortal. Determines the type of dispute games that can be used\nto finalize withdrawals.\nAdministrator: Guardian\nRequirement: CANNON (\n0)\nNotes: The game type may be changed to PERMISSIONED_CANNON (\n1)\nas a fallback to permissioned proposals, in the event of a failure in the Fault Proof system.\nFault Game Max Depth\nDescription: The maximum depth of fault\ndispute game trees.\nAdministrator: Static\nRequirement: 73\nNotes: Sufficiently large to ensure the fault proof VM execution trace fits within the number of leaf nodes.\nFault Game Split Depth\nDescription: The depth in fault\ndispute game trees after which\nclaims correspond to VM state commitments instead of output root commitments.\nAdministrator: Static\nRequirement: 30\nNotes: Sufficiently large to ensure enough nodes at the split depth to represent all L2 blocks since the anchor\nstate.\nMax Game Clock Duration\nDescription: The maximum amount of time that may accumulate on a dispute game team's chess clock.\nAdministrator: Static\nRequirement: 3.5 days\nNotes: High security. Allows enough time for honest actors to counter invalid claims.\nGame Clock Extension\nDescription: The flat credit that is given to a dispute game team's clock if their clock has less than\nCLOCK_EXTENSION seconds remaining.\nAdministrator: Static\nRequirement: 3 hours\nNotes: Allows enough time for honest actors to counter freeloader claims.\nBond Withdrawal Delay\nDescription: The length of time that must pass before dispute game bonds can be withdrawn.\nAdministrator: Static\nRequirement: 7 days\nNotes: High security. Allows enough time for the Guardian to recover funds from DelayedWETH if bonds were\nallocated incorrectly.\nMinimum Large Preimage Proposal Size\nDescription: The minimum size of preimage allowed to be submitted via the PreimageOracle large preimage proposal\nprocess.\nAdministrator: Static\nRequirement: 126000 bytes\nNotes: Large enough to ensure posting the large preimage is expensive enough to act as a deterrent but small enough\nto be used for any preimage that is too large to be submitted in a single transaction.\nLarge Preimage Proposal Challenge Period\nDescription: The amount of time that large preimage proposals can be challenged before they can be published to the\nPreimageOracle\nAdministrator: Static\nRequirement: 24 hours\nNotes: High security. Allows enough time for honest actors to challenge invalid large preimage proposals.\nFault Game Absolute Prestate\nDescription: The VM state commitment to use as the starting point when executing the fault proof VM\nAdministrator: Static\nRequirement: The state commitment of a governance approved op-program release.\nNotes: The op-program version must have the rollup config and L2 genesis of the chain built in via the superchain\nregistry.\nFault Game Genesis Block\nDescription: The L2 block number used as the initial anchor state for fault dispute games\nAdministrator: Static\nRequirement: Block number of any finalized block between bedrock activation and enabling fault proofs. 0 for chains\nusing fault proofs from genesis.\nFault Game Genesis Output Root\nDescription: The output root at the Fault Game Genesis Block\nAdministrator: Static\nRequirement: The output root from the canonical chain at Fault game Genesis Block.\nFee Scalar\nDescription: Markup on transactions compared to the raw L1 data cost.\nAdministrator: System Config Owner\nRequirement: Set such that Fee Margin is between 0 and 50%.\nGas Limit\nDescription: Gas limit of the L2 blocks is configured through the system config.\nAdministrator: System Config Owner\nRequirement: No higher than 200_000_000 gas\nNotes: Chain operators are driven to maintain a stable and reliable chain. When considering to change this value,\ncareful deliberation is necessary.\nGenesis state\nDescription: Initial state at chain genesis, including code and storage of predeploys (all L2 smart contracts).\nSee Predeploy.\nAdministrator: Static\nRequirement: Only standard predeploys and preinstalls, no additional state.\nNotes: Homogeneity & standardization, ensures initial state is secure.\nL2 block time\nDescription: Frequency with which blocks are produced as a result of derivation.\nAdministrator: L1 Proxy Admin\nRequirement: 1 or 2 seconds\nNotes: High security & interoperability compatibility requirement, until de-risked/solved\nat app layer.\nResource config\nDescription: Config for the EIP-1559 based curve used for the deposit gas market.\nAdministrator: L1 Proxy Admin\nRequirement: See resource config table.\nNotes: Constraints are imposed\nin code\nwhen setting the resource config.\nSequencing window Size\nDescription: Maximum allowed batch submission gap, after which L1 fallback is triggered in derivation.\nAdministrator: Static\nRequirement: 3_600 base layer blocks (12 hours for an L2 on Ethereum, assuming 12 second L1 blocktime). e.g. 12\nsecond blocks, .\nNotes: This is an important value for constraining the sequencer's ability to re-order transactions; higher values\nwould pose a risk to user protections.\nStart block\nDescription: Block at which the system config was initialized the first time.\nAdministrator: L1 Proxy Admin\nRequirement: The block where the SystemConfig was initialized.\nNotes: Simple clear restriction.\nSuperchain target\nDescription: Choice of cross-L2 configuration. May be omitted in isolated OP Stack deployments. Includes\nSuperchainConfig and ProtocolVersions contract addresses.\nAdministrator: Static\nRequirement: Mainnet or Sepolia\nNotes: A superchain target defines a set of layer 2 chains which share SuperchainConfig and ProtocolVersions\ncontracts deployed on layer 1.\nGovernance Token\nDescription: OP token used for the Optimism Collective's Token House governance.\nAdministrator: n/a\nRequirement: Disabled\nNotes: Simple clear restriction.\nOperator Fee Scalar\nDescription: Operator fee scalar -- used to calculate the operator fee\nAdministrator: System Config Owner\nRequirement: 0 \nOperator Fee Constant\nDescription: Operator fee constant -- used to calculate the operator fee\nAdministrator: System Config Owner\nRequirement: 0 \nNote that the operator fee scalar and constant are primarily used for non-standard configurations,\nlike op-succinct, so their standard values are 0.\nDA Footprint Gas Scalar\nDescription: DA footprint gas scalar -- used to calculate the DA footprint\nAdministrator: System Config Owner\nRequirement: Requirements (if any) are declared in https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-config-params-mainnet.toml\nMinimum Base Fee\nDescription: Minimum base fee -- sets the minimum base fee on L2\nAdministrator: System Config Owner\nRequirement: Requirements (if any) are declared in https://github.com/ethereum-optimism/superchain-registry/blob/main/validation/standard/standard-config-params-mainnet.toml\n1\nThe chain ID must be globally unique among all EVM chains.\n\nResource Config\nConfig PropertyStandard Config Requirement\nmaxResourceLimit\nelasticityMultiplier\nbaseFeeMaxChangeDenominator\nminimumBaseFee\nsystemTxMaxGas\nmaximumBaseFee-1\n\nPolicy Parameters\nData Availability Type\nDescription: Batcher can currently be configured to use blobs or calldata (\nSee Data Availability Provider).\nAdministrator: Batch submitter address\nRequirement: Ethereum (Blobs, Calldata)\nNotes: Alt-DA is not yet supported for the standard configuration, but the sequencer can switch at-will between blob\nand calldata with no restriction, since both are L1 security.\nBatch submission frequency\nDescription: Frequency with which batches are submitted to L1 (\nsee Batcher Transaction).\nAdministrator: Batch submitter address\nRequirement: 1_800 base layer blocks (6 hours for an L2 on Ethereum, assuming 12 second L1 blocktime) or lower\nNotes: Batcher needs to fully submit each batch within the sequencing window, so this leaves buffer to account for\nL1 network congestion and the amount of data the batcher would need to post.\nOutput frequency\nDescription: Frequency with which output roots are submitted to L1.\nAdministrator: L1 Proxy Admin\nRequirement: 43_200 L2 Blocks (24 hours for an L2 on Ethereum, assuming 2 second L2 blocktime) or lower e.g. 2\nsecond blocks, .\nNotes: Deprecated once fault proofs are implemented. This value cannot be 0.\nAdmin Roles\nL1 Proxy Admin\nDescription: Account authorized to upgrade L1 contracts.\nAdministrator: L1 Proxy Admin Owner\nAdministers: Batch Inbox Address, Start block,\nProposer address, Challenger address, Guardian address,\nProof Maturity Delay, Dispute Game Finality,\nOutput frequency, L2 block time,\nL1 smart contracts\nRequirement:\nProxyAdmin.sol\nfrom the latest op-contracts/vX.Y.X release of source code in\nOptimism repository.\nNotes: Governance-controlled, high security.\nL1 ProxyAdmin owner\nDescription: Account authorized to update the L1 Proxy Admin.\nAdministrator: \nAdministers: L1 Proxy Admin\nRequirement:\n0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A\n2\nNotes: Governance-controlled, high security.\nL2 Proxy Admin\nDescription: Account authorized to upgrade L2 contracts.\nAdministrator: L2 Proxy Admin Owner\nAdministers: Predeploys\nRequirement:\nProxyAdmin.sol\nfrom the latest op-contracts/vX.Y.X release of source code\nin Optimism repository. Predeploy\naddress: 0x4200000000000000000000000000000000000018.\nNotes: Governance-controlled, high security.\nL2 ProxyAdmin owner\nDescription: Account authorized to upgrade protocol contracts via calls to the ProxyAdmin. This is the aliased L1\nProxyAdmin owner address.\nAdministrator: \nAdministers: L2 Proxy Admin\nRequirement: Gnosis Safe between Optimism Foundation (OF) and the Security Council (SC). Aliased\nAddress:\n0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b\n3\nNotes: Governance-controlled, high security.\nSystem Config Owner\nDescription: Account authorized to change values in the SystemConfig contract. All configuration is stored on L1 and\npicked up by L2 as part of the derivation of the L2 chain.\nAdministrator: L1 Proxy Admin\nAdministers: Batch submitter address, Sequencer P2P / Unsafe head signer,\nFee Margin, Gas limit, System Config Owner\nRequirement: Chain Governor or Servicer\nNotes: As defined in\nthe Law of Chains\n2\n2 of 2 GnosisSafe between Optimism Foundation (OF) and the Security Council (SC) on L1. Mainnet and Sepolia addresses can be found at privileged roles.\n\n3\nAliased address of the 2 of 2 Gnosis Safe between Optimism Foundation (OF) and the Security Council (SC) on L1. The reason for aliasing can be found in the glossary. This address was calculated using the following arithmetic: 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A + 0x1111000000000000000000000000000000001111 = 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b.\n\nService Roles\nBatch submitter address\nDescription: Account which authenticates new batches submitted to L1 Ethereum.\nAdministrator: System Config Owner\nRequirement: No requirement\nNotes: \nChallenger address\nDescription: Account which can interact with\nexisting permissioned dispute games.\nAdministrator: L1 Proxy Admin\nRequirement:\n0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3A\n4\nNotes: Optimism Foundation (OF) multisig\nleveraging battle-tested software. This role is only active when\nthe OptimismPortal respected game type is [PERMISSIONED_CANNON]\n(https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.5.0/packages/contracts-bedrock/src/dispute/lib/Types.sol#L31).\nGuardian address\nDescription: Account authorized to pause L1 withdrawals from contracts, blacklist dispute games, and set the\nrespected game type in the OptimismPortal.\nAdministrator: L1 Proxy Admin\nRequirement:\n0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2\nNotes: A 1/1 Safe owned by the Security Council Safe, with\nthe Deputy Pause Module enabled to allow the Optimism\nFoundation to act as Pause Deputy.\nProposer address\nDescription: Account which can create and interact\nwith permissioned dispute games on\nL1.\nAdministrator: L1 Proxy Admin\nRequirement: No requirement\nNotes: This role is only active when the OptimismPortal respected game type is [PERMISSIONED_CANNON]\n(https://github.com/ethereum-optimism/optimism/blob/op-contracts/v1.5.0/packages/contracts-bedrock/src/dispute/lib/Types.sol#L31).\nThe L1ProxyAdmin sets the implementation of the PERMISSIONED_CANNON game type. Thus, it determines the proposer\nconfiguration of the permissioned dispute game.\nSequencer P2P / Unsafe head signer\nDescription: Account which authenticates the unsafe/pre-submitted blocks for a chain at the P2P layer.\nAdministrator: System Config Owner\nRequirement: No requirement\nNotes: \n4\n5 of 7 GnosisSafe controlled by Optimism Foundation (OF). Mainnet and Sepolia addresses can be found at privileged roles.","tokens":4206,"squid":"ink-governance","role":"Council Listener","at":1791261836128,"hash":"93449de1dbf2a16eda21006a5ea7d21a000f6d17"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/sequencer-transaction-flow","domain":"docs.arbitrum.io","title":"Sequencer architecture and transaction flow | Arbitrum Docs","text":"✏️Request an updateThis deep dive follows a transaction through a single Sequencer instance: how it arrives, how it waits in the transaction queue, how blocks get created, and how the result reaches the rest of the network. It is aimed at chain operators and integration partners who need to reason about queueing, timeouts, and block timing.\nTwo companion pages cover the surrounding context, and this page assumes you have read them:\n\nThe Sequencer and censorship resistance explains the Sequencer's role, the real-time feed, batch posting, and finality.\nTransaction lifecycle explains the different ways to submit a transaction, including bypassing the Sequencer entirely.\n\nScope of this pageThis page describes the internals of a single Sequencer instance. For the behavior of Arbitrum One's public sequencer endpoint (latency expectations, retries, and fallback patterns), see RPC endpoints and providers. For running multiple redundant Sequencers with Redis-based coordination, see How to set up a high-availability sequencer and How to run a Sequencer Coordinator Manager.\nAll code references below point to Nitro v3.11.0.\nTransaction flow at a glance​\n\nA user submits a signed transaction to any RPC node on the chain.\nThe RPC node does not execute or pool the transaction; it forwards it to the Sequencer.\nThe Sequencer places the transaction in a bounded, in-memory queue.\nThe block creation loop drains the queue in the order the chain's ordering policy dictates, and executes transactions one at a time to build a block.\nThe new block is published on the Sequencer Feed for real-time consumers, and the batch poster later posts the compressed sequence to the sequencer inbox on the parent chain.\nValidators re-execute the sequence posted on the parent chain to verify and assert the chain's state.\n\nValidators do not accept user transactionsValidators only read the ordered transactions from the parent chain and re-execute them locally to compute the chain's state. They have no transaction queue and no way to accept, order, or process a user transaction directly. The only ingestion point for user transactions is the Sequencer, and RPC nodes exist to forward transactions to it. (The one exception, submitting through the delayed inbox on the parent chain, is covered in Transaction lifecycle.)\nHow transactions reach the Sequencer​\nOnly one node on the chain actively sequences transactions at any given time (in a high-availability setup, several sequencer-capable nodes may run behind a coordinator, which picks the active one; see the scope note above). Every other node runs a forwarder: when it receives a transaction over RPC, it immediately relays the raw transaction to the Sequencer's endpoint instead of processing it locally (forwarder.go). The target is configured with --execution.forwarding-target; for known chains, Nitro fills it in automatically from the chain's configuration when the node is not a sequencer. A non-sequencer node with no forwarding target (explicitly set to \"null\") simply drops incoming transactions.\nUnlike Ethereum, there is no public mempool. Transactions are not gossiped between nodes and never sit in a public pending pool. The Sequencer receives them directly into its own in-memory structures, which stay private no matter which ordering policy the chain runs.\nOrdering policies​\nWhat the Sequencer does with a queued transaction depends on the chain's transaction ordering policy. Three exist, and a chain runs exactly one:\nPolicyWhat decides the orderWhere it runsFirst-come, first-serve (FCFS)Arrival time at the SequencerThe default for a new Arbitrum chainPriority Gas Auctions (PGA)The priority fee each transaction paysArbitrum OneTimeboostAn auctioned express lane, FCFS for everyone elseAvailable to any chain owner\nThe FIFO behavior this page describes assumes FCFS. The two other policies change the order, not the intake path: the queue, the deadlines, and the context deadline exceeded behavior below apply the same way under all three.\nUnder PGA, the queue described in the next section is the first stage of a two-stage mempool. Each ordering round moves the whole queue into a priority queue keyed on the priority fee, which EIP-1559 computes as min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas). Ties break on arrival time, and a transaction left waiting gains an anti-starvation boost each round, so a zero-fee transaction still lands within a small number of blocks. Introduction to PGA covers the rounds and the boost.\nUnder Timeboost, transactions from the current express lane controller are sequenced as soon as they arrive, while every other transaction has its arrival timestamp delayed (by default, 200 milliseconds) before taking its place in the queue.\nArbitrum One runs PGAArbitrum One used Timeboost from April 2025 until PGA activated. PGA removes the 200ms delay that Timeboost applied to transactions outside the express lane, so no transaction waits on another's lane. Chain owners can still choose Timeboost, but a chain that enables both policies behaves unpredictably.\nThe transaction queue​\nThe heart of the intake path is a bounded, in-memory queue, sized by --execution.sequencer.queue-size (default 1024) (sequencer.go#L461). Its behavior has three distinct zones:\n\nInside the queue: under FCFS, transactions are ordered strictly FIFO, so whatever enters the queue first gets sequenced first. Under PGA, the queue is an unordered waiting list, and the priority fee decides the order when a round promotes it.\nAt the queue boundary, when the queue is full: a transaction has \"reached the Sequencer but is not yet queued.\" The Sequencer holds the submission open and waits for a slot to free up (sequencer.go#L731-L735). Ordering among these waiting transactions is not guaranteed: when a slot frees up, which waiting transaction claims it depends on runtime scheduling, not arrival order.\nRejected: if a transaction cannot be queued and sequenced before its deadline (see below), it is rejected and never executes.\n\nQueue timeout and context deadline exceeded​\nEvery transaction receives a deadline when it arrives, set by --execution.sequencer.queue-timeout (default 12s) (sequencer.go#L557-L560). The deadline is enforced at two points:\n\nWhile waiting to enter a full queue: if no slot frees up before the deadline, the submission fails immediately.\nAgain at dequeue time: when the block creation loop pops a transaction from the queue, it first checks whether the transaction's deadline already expired while it sat in the queue, and rejects it if so (sequencer.go#L1360-L1364).\n\nIn both cases, the caller receives an error containing the string context deadline exceeded. This error means exactly one thing: the chain could not sequence the transaction within queue-timeout, and the transaction was not executed. For a user or integration partner, the correct response is:\n\nTreat it as backpressure, not as a permanent failure. It is safe to resubmit the same signed transaction (same nonce) with a backoff.\nMake sure your client-side HTTP timeout is longer than the chain's queue-timeout; otherwise your client gives up before the Sequencer reports the outcome.\nIf you see this error persistently rather than in bursts, the chain's intake is saturated: see Tuning guidance for chain operators below.\n\nBlock creation and timing​\nThe Sequencer produces blocks from a single loop: attempt to create a block; if a block was produced, wait until max-block-speed has elapsed since the attempt started before trying again; if not, retry immediately (sequencer.go#L1773-L1781).\n--execution.sequencer.max-block-speed (default 250ms) is therefore the minimum delay between blocks, which caps block production at four blocks per second under FCFS. It is not a block time:\n\nWhen the queue is empty, the block creation routine simply blocks waiting for the next transaction to arrive (sequencer.go#L1314-L1341). No transactions means no blocks: the Sequencer does not produce empty blocks, and createBlock reports that no block was made unless at least one transaction was successfully sequenced.\nWhen blocks are heavy, the actual interval stretches beyond max-block-speed, because execution itself takes time and the timer only sets a floor.\n\nIn short, there is no fixed block time on the child chain. Block timestamps and block numbers advance with demand, which is why time-based logic in contracts should never assume a constant block interval.\nWithin one block creation pass, the Sequencer pulls the first transaction (waiting for it if necessary), then keeps draining additional queued transactions for a short window (--execution.sequencer.read-from-tx-queue-timeout, default 10ms) before sealing the set into a block. Transactions that don't fit in the block's gas limit are pushed to an internal retry queue and get first priority in the next block.\nBlock creation under PGA​\nPGA replaces that single drain window with fixed ordering rounds. A new round starts every B/K, where B is the block time and K is the number of rounds per block. On Arbitrum One, B is 250ms and K is 2, so rounds last 125ms. Each round takes in new arrivals for its full window, then promotes the waiting list into the priority queue and transfers that queue into the block, highest priority fee first.\nA block closes when it reaches the first of these limits:\n\nA gas target of 32 Mgas. The hard limit is 64 Mgas, and a single transaction can use at most 32 Mgas.\nA calldata limit of 95,000 bytes.\nThe end of its last round.\n\nIf a block fills before its last round, the Sequencer finalizes it right away and starts the next block rather than idling for the rest of the window. Under load, the chain then produces blocks faster than its nominal block time: between 1/B and K/B, or 4 to 8 blocks per second on Arbitrum One. That upper cap keeps the spacing between rounds consistent, which the anti-starvation boost depends on.\nK stays adjustable for two years after PGA activates, to any value from 1 to 10. That gives round lengths from 250ms down to 25ms.\nExecution is strictly sequential​\nWhen building a block, transactions are executed one at a time through the state transition function (block_processor.go#L372-L407), under a lock that ensures only one block is ever being built at once. There is no parallel execution: total throughput is bounded by single-threaded EVM execution speed and the per-block gas limit, not by how fast transactions can be queued.\nWhat happens during a surge​\nSuppose 100,000 transactions arrive at effectively the same moment, with default settings:\n\nThe first 1024 transactions occupy the queue. The rest wait at the queue boundary, each holding its own 12-second deadline, with no ordering guarantee among them.\nEvery 250ms or more, the Sequencer drains a batch of queued transactions into a block, executing them sequentially. Freed slots are claimed by waiting transactions.\nAny transaction that cannot make it through the queue and into a block within its 12-second deadline fails with context deadline exceeded.\n\nUnder PGA, the same backpressure applies, but the priority fee decides who gets through it. Each round promotes whatever is waiting and drains the highest-paying transactions first, so a surge raises the fee needed to land early rather than stretching one arrival queue. The anti-starvation boost still bounds the wait for low-fee transactions, and any transaction that cannot reach a block within its 12-second deadline fails the same way.\nThe queue is deliberately a short buffer, not a mempool: with default settings it never holds more than about 12 seconds' worth of work. Everything beyond what the chain can execute in that window is shed back to the submitter, who is expected to retry. This keeps latency bounded and predictable for the transactions that do get in, at the cost of pushing burst-absorption out to the edges (RPC clients, or an operator-run relayer, described below).\nFrom block to the rest of the network​\nAs soon as a block is created, the transaction streamer hands the new message to the broadcaster, which publishes it over WebSocket on the sequencer feed (transaction_streamer.go#L1307). Full nodes and feed relays consume the feed to give sub-second soft confirmations; see How to read the sequencer feed.\nOn Arbitrum One, the Fast Feed publishes each transaction inside its PGA round, before the block closes and before the standard feed carries it. It is a paid, authenticated stream aimed at latency-sensitive readers, and a Nitro node cannot consume it. Soft confirmation still comes from the standard feed.\nIndependently, the batch poster compresses the sequenced transactions and posts them to the sequencer inbox on the parent chain, at which point they inherit the parent chain's finality. Validators then re-execute the posted sequence and assert the resulting state. The Sequencer and censorship resistance covers the feed, batch posting, and the finality trade-offs in detail, and Assertions covers validation.\nTuning guidance for chain operators​\nFor chains with different traffic profiles than Arbitrum One, the queue parameters are the primary tuning surface:\n\n--execution.sequencer.queue-size (default 1024): raising it lets the Sequencer absorb larger instantaneous bursts without making submitters wait at the queue boundary. The limit to keep in mind: the queue-timeout deadline keeps counting while a transaction sits in the queue, so a queue deeper than what the chain can execute within queue-timeout only moves rejections from enqueue time to dequeue time. Size the queue to roughly what your chain can drain in one timeout window.\n--execution.sequencer.queue-timeout (default 12s): raising it lets transactions ride out longer spikes at the cost of slower failure feedback and longer-held connections; lowering it makes overload fail fast. Whatever you choose, communicate it to integration partners so their client timeouts and retry logic stay consistent with it.\n--execution.sequencer.max-block-speed (default 250ms): lowering it raises the block production cap and reduces best-case latency; it does not increase execution throughput, which stays bounded by sequential execution and the per-block gas limit.\n\nIf you run PGA, the rounds-per-block count K is a fourth tuning surface. Raising K shortens each round, which lowers the latency between a transaction arriving and a round promoting it, and raises the ceiling on blocks per second under load. It also makes the anti-starvation boost smaller per round, because the boost is p / (2K). See PGA for Arbitrum chains for the configuration steps.\nOperator-run relayer cache​\nIf your workload has sustained bursts that no reasonable queue-size/queue-timeout setting absorbs (for example, game events or airdrops that generate far more than one timeout window's worth of transactions at once), the standard pattern is a relayer cache in front of the Sequencer: an operator-run service that accepts transactions immediately, holds them durably, and submits them to the Sequencer at the rate the queue drains, retrying on context deadline exceeded.\nThis pattern complements rather than replaces queue tuning: queue-size and queue-timeout define how much burst the Sequencer itself absorbs, while the relayer holds everything beyond that and controls its own submission order and retry policy. The trade-off is that transactions waiting in the relayer have no onchain ordering guarantee until they actually enter the Sequencer's queue, so the relayer becomes a trusted component of your chain's ingestion path.\nRelated resources​\n\nThe Sequencer and censorship resistance: feed, batch posting, finality, and the delayed inbox escape hatch\nIntroduction to PGA: the two-stage mempool, ordering rounds, and the anti-starvation boost\nIntroduction to the Fast Feed: the paid per-transaction stream that publishes inside a PGA round\nFinality: what soft and hard finality guarantee, and which one to wait for\nThe batch poster: what happens after sequencing, from segment building to the parent chain transaction\nTransaction lifecycle: all submission pathways, including bypassing the Sequencer\nRPC endpoints and providers: public endpoint behavior, retries, and fallback patterns\nHow to set up a high-availability sequencer: redundant Sequencers with Redis-based coordination\nHow to run a Sequencer Coordinator Manager: managing the sequencer priority list\nHow to read the sequencer feed and How to run a feed relay\nTransaction flow at a glanceHow transactions reach the SequencerOrdering policiesThe transaction queueQueue timeout and context deadline exceededBlock creation and timingBlock creation under PGAExecution is strictly sequentialWhat happens during a surgeFrom block to the rest of the networkTuning guidance for chain operatorsOperator-run relayer cacheRelated resources","tokens":4208,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261842745,"hash":"163127a812703525b64431ae44fb8f8e6edc47d3"}
{"url":"https://specs.optimism.io/protocol/deputy-pause-module.html","domain":"specs.optimism.io","title":"Deputy Pause Module - OP Stack Specification","text":"DeputyPauseModule\n\nTable of Contents\n\nStatus\nOverview\nContext\nUpgradeability\nAssumptions\n\naSCP-001: Pause authorization process is well-defined\naSCP-002: Pause authorization process is robust\naSCP-003: Pause authorization process is fast\naDPM-001: Contract is configured correctly\n\nMitigations\n\naDPM-002: Deputy key is not compromised\n\nMitigations\n\naDPM-003: Deputy key is not deleted\n\nMitigations\n\naDPM-004: Ethereum will not censor transactions for extended periods of time\n\nMitigations\n\naDPM-005: OpenZeppelin ECDSA and EIP712 contracts are free of critical bugs\n\nMitigations\n\naDPM-006: Safe contracts are free of critical bugs\n\nMitigations\n\naDPM-008: Deputy key is capable of creating signatures\n\nMitigations\n\nSystem Invariants\n\niSCP-001: Pause can be activated within 30 minutes of authorization\n\nImpact\nDependencies\n\niSCP-002: Pause is not activated outside of the standard process\n\nImpact\nDependencies\n\nComponent Invariants\n\niDPM-001: Only the Deputy may act through the module\n\nImpact\nMitigations\nDependencies\n\niDPM-002: Deputy must only be able to trigger the pause\n\nImpact\nMitigations\nDependencies\n\niDPM-003: Deputy must always be able to act through the module\n\nImpact\nMitigations\nDependencies\n\niDPM-004: Deputy authorizations must not be replayable\n\nImpact\nMitigations\nDependencies\n\niDPM-005: Foundation Safe must be able to change the Deputy account easily\nImpact\nMitigations\n\nImplementation Spec\n\nconstructor\npause\nsetDeputy\nfoundationSafe\nsuperchainConfig\ndeputy\npauseMessageTypehash\ndeputyAuthMessageTypehash\n\nStatus\nProposed\nOverview\nThe DeputyPauseModule is a Safe Module designed to be installed into the Security\nCouncil Guardian Safe that allows a dedicated Deputy address to create an ECDSA signature that\nauthorizes the execution of the Pause Mechanism. The\nDeputyPauseModule assumes that the Security Council Guardian Safe is the Guardian\nthat is permitted to act within the SuperchainConfig.\nContext\nAdditional context and motivation for this component can be found in the corresponding\ndesign document.\nUpgradeability\nThe DeputyPauseModule is not expected to change frequently and is therefore not a proxied\ncontract. The DeputyPauseModule allows basic parameters to be modified by the Operations Safe\ndirectly without needing to deploy a new instance of the contract. Additionally, the address of the\nmodule itself is only utilized within the Optimism Foundation Operations Safe and can be safely\nreplaced.\nAssumptions\n\nNOTE: Assumptions are utilized by specific invariants and do not apply globally. Invariants\ntypically only rely on a subset of the following assumptions. Different invariants may rely on\ndifferent assumptions. Refer to individual invariants for their dependencies.\n\naSCP-001: Pause authorization process is well-defined\nWe assume that the process by which a pause can be authorized is well-defined such that the cases\nin which the pause should and should not be triggered are apparent. This assumption dictates that\nthe cases in which the pause should be used are clearly enumerated and well known to all\nparticipants.\naSCP-002: Pause authorization process is robust\nWe assume that the process by which a pause can be authorized correctly accounts for all cases in\nwhich such a pause would be necessary. In other words, we assume that there are no situations where\nthe pause should be used to protect the system but the defined protocol for triggering the pause\nwould not require the pause to be triggered.\naSCP-003: Pause authorization process is fast\nWe assume that the process by which a pause can be authorized is fast acting such that it can make\nthe decision to trigger the pause within a short period of time of any situation that would require\nsuch a pause.\naDPM-001: Contract is configured correctly\nWe assume that all inputs to the contract are configured correctly including:\n\nAddress of the Operations Safe.\nAddress of the SuperchainConfig contract.\nAddress of the Deputy account.\n\nMitigations\n\nVerify a signature from the Deputy in the contract constructor.\nVerify the configured values in the deployment script.\nGenerate and test a signature on testnet.\n\naDPM-002: Deputy key is not compromised\nWe assume that the Deputy key is maintained securely and is not compromised by a malicious actor.\nMitigations\n\nEnforce strong access control around the Deputy key.\nMonitoring for any usage of the Deputy key.\nRegular rotation of the Deputy key.\n\naDPM-003: Deputy key is not deleted\nWe assume that the Deputy key has not been deleted by a malicious actor.\nMitigations\n\nMaintain duplicate copies of the key in multiple secure locations.\n\naDPM-004: Ethereum will not censor transactions for extended periods of time\nWe assume that Ethereum will not censor transactions for an extended period of time and that any\ntransaction submitted to the network can be processed within a reasonable time bound (e.g., 1h).\nMitigations\n\nExtremely high priority fee if necessary.\n\naDPM-005: OpenZeppelin ECDSA and EIP712 contracts are free of critical bugs\nWe assume that both the ECDSA library and the EIP712 contract provided by OpenZeppelin V4 at\ncommit ecd2ca2c (v4.7.3) are free of any critical bugs that would cause their\nbehaviors to diverge from their specified behaviors.\nMitigations\n\nExisting audits/safety processes for OpenZeppelin V4.\n\naDPM-006: Safe contracts are free of critical bugs\nWe assume that the Safe contract implementations used by the Security Council Safe and Optimism\nFoundation Operations Safe are free of any critical bugs that would cause their behaviors to\ndiverge from their specified behaviors.\nMitigations\n\nExisting audits/safety processes for Safe.\n\naDPM-008: Deputy key is capable of creating signatures\nWe assume that the Deputy key configured is actually capable of creating signatures.\nMitigations\n\nSignature verification when changing Deputy key.\n\nSystem Invariants\niSCP-001: Pause can be activated within 30 minutes of authorization\nIt is an important system-level invariant that the pause functionality can be activated within a\nshort, bounded amount of time (30 minutes) of its authorization by the standard process that\napproves the usage of this pause. That is, after the pause is authorized, it should be possible to\nexecute the pause in under 30 minutes under all circumstances.\nImpact\nSeverity: High (estimated)\nIf this invariant is broken, various recovery options that rely on fast activation of the pause may\nfail. We estimate the severity of this invariant being broken to be high but final severity will\ndepend on the formalization of other invariants that rely on this one.\nDependencies\n\naSCP-002\naSCP-003\niDPM-003\naDPM-001\n\niSCP-002: Pause is not activated outside of the standard process\nWe must maintain that the pause is not activated outside of the standard process that approves the\nusage of the pause.\nImpact\nSeverity: High\nIf this invariant is broken, all components that rely on the pause would be placed into a paused\nstate unexpectedly. This would cause a temporary liveness failure for withdrawals through the\nStandard Bridge system and would negatively impact users until liveness could be restored by the\nGuardian.\nDependencies\n\naSCP-001\niDPM-001\niDPM-004\naDPM-002\n\nComponent Invariants\niDPM-001: Only the Deputy may act through the module\nThe Deputy account must be the only address that can act through the module. Other accounts can\nexecute an action on behalf of the Deputy if the account has a valid authorization signature from\nthe Deputy for that action. No account may act through the module other than with the explicit\nauthorization of the Deputy.\nImpact\nSeverity: High\nIf this invariant is broken, accounts other than the Deputy would be able to carry out the actions\nallowed by this module. Assuming that\niDPM-002 holds, this\nmeans that an account other than the Deputy would be able to trigger the pause, presumably without\nthe authorization of the social consensus process that typically triggers this pause.\nMitigations\n\nSignature verification on the pause action.\nMonitoring for pause triggering actions.\n\nDependencies\n\naDPM-005\n\niDPM-002: Deputy must only be able to trigger the pause\nThe Deputy must only be able to trigger the pause action by causing the module to call the pause\nfunction on the SuperchainConfig. The Deputy must not be able to trigger any other privileged\naction on behalf of the Guardian.\nImpact\nSeverity: Critical\nIf this invariant is broken, the Deputy would be able to cause the Optimism Foundation Operations\nSafe to execute some unknown set of possible actions. We would treat this as a critical risk.\nMitigations\n\nStrict auditing and verification of the DeputyPauseModule.\n\nDependencies\n\naDPM-006\n\niDPM-003: Deputy must always be able to act through the module\nThe Deputy account must always be able to act through the module, even if the Deputy account\nprivate key is compromised. Other than the total deletion of the Deputy key, there should not be\nany condition in the contract itself that would prevent the key from being able to quickly and\nefficiently execute the pause action.\nImpact\nSeverity: High\nIf this invariant is broken, we would not be able to provide the system-level invariant that the\nDeputy account can always be used to trigger the pause within a bounded amount of time of the\ndecision being made to carry out this action.\nMitigations\n\nSignature-based verification to bypass draining attacks.\nStrict auditing and verification of the DeputyPauseModule.\n\nDependencies\n\naDPM-001\naDPM-003\naDPM-004\naDPM-005\naDPM-008\n\niDPM-004: Deputy authorizations must not be replayable\nA Deputy authorization must apply to a specific DeputyPauseModule on a specific blockchain as\nidentified by its chain ID. An authorization created for one DeputyPauseModule must not be\nreusable on any other DeputyPauseModule. An authorization must be usable once and the same\nauthorization must not be usable again in any DeputyPauseModule.\nImpact\nSeverity: High\nIf this invariant is broken, a Deputy authorization created by the same Deputy address for\nanother DeputyPauseModule or a previous authorization for the same module could be reused and\nwould result in the pause being triggered outside of the standard process by which such a pause is\napproved.\nMitigations\n\nEIP-712 signature verification including a specific contract address and chain ID.\nEnforce unique nonces on signatures to prevent signature reuse within the same contract.\nUtilize unique Deputy accounts for each module instance or network.\n\nDependencies\n\naDPM-005\n\niDPM-005: Foundation Safe must be able to change the Deputy account easily\nThe Foundation Safe must be able to change the address of the Deputy account without significant\noperational overhead.\nImpact\nSeverity: Medium\nIf this invariant is broken, it would not be possible for the Safe account to easily rotate the\nDeputy account if the account is compromised. This creates operational overhead but is not a\nsecurity risk as we assume that the Safe code does not have bugs and therefore the Safe can always\nremove the module if necessary.\nMitigations\n\nAuthorized function to change the Deputy address.\n\nImplementation Spec\nconstructor\n\nSets the EIP-712 domain name to \"DeputyPauseModule\".\nSets the EIP-712 domain version to \"1\".\nTakes the address of the Operations Safe as an authorized input.\nTakes the address of the SuperchainConfig as an authorized input.\nTakes the address of the Deputy as an authorized input.\nTakes a signature from the Deputy over a known EIP-712 message.\nMust verify that the signature was produced by the provided Deputy address.\n\npause\n\nTakes a nonce as an untrusted input.\nTakes a Pause Identifier as an untrusted input.\nTakes a signature as an untrusted input.\nCallable by any address.\nMust verify that the nonce has not been used.\nMust verify that the signature is over an EIP-712 message that commits to the nonce and the pause\nidentifier and was produced by the private key corresponding to the Deputy address.\nMust mark the nonce as used.\nMust trigger the pause on the SuperchainConfig function with the provided pause identifier.\nMust revert if the call to the pause function failed.\nMust revert if the call succeeded but the SuperchainConfig contract was not paused.\n\nsetDeputy\n\nTakes a deputy address as an authorized input.\nTakes a deputy auth signature as an authorized input.\nCan only be called by the Foundation Safe as configured in the constructor.\nMust verify that the signature was produced by the provided Deputy address.\n\nfoundationSafe\n\nReturns the address of the Operations Safe as set in the constructor.\n\nsuperchainConfig\n\nReturns the address of the SuperchainConfig contract as set in the constructor.\n\ndeputy\n\nReturns the address of the Deputy account as set in the constructor.\n\npauseMessageTypehash\n\nReturns the typehash that corresponds to struct PauseMessage { bytes32 nonce }.\n\ndeputyAuthMessageTypehash\n\nReturns the typehash that corresponds to struct DeputyAuthMessage { address deputy }.","tokens":3230,"squid":"ink-governance","role":"Council Listener","at":1791261848429,"hash":"de91ef85d651ac3f38800165e6e1ea97bf21ef75"}
{"url":"https://docs.arbitrum.io/how-arbitrum-works/deep-dives/stf","domain":"docs.arbitrum.io","title":"State Transition Function | Arbitrum Docs","text":"✏️Request an updateAn Arbitrum node is a deterministic machine: feed it the same ordered inputs, and it will always produce the same outputs. The job of everything before the State Transition Function (STF) is to agree on exactly which inputs those are and in what order they should be.\nHow it works​\n1. Two doors, one source of truth​\nInputs reach a node through two doors. The fast door is the Sequencer feed—a real-time broadcast of newly ordered messages, so nodes feel the chain advance within milliseconds. The slow, trustworthy door is Ethereum itself: the Sequencer periodically posts compressed batches to the parent-chain inbox, emitting a SequencerBatchDelivered event. When the two disagree, the feed yields—the parent chain is the canonical record (Ethereum for Arbitrum), and a node will reorg its optimistic feed-derived state to match what was actually settled on Ethereum.\n2. The envelope (L1IncomingMessage)​\nWhatever the door, every input lands as one L1IncomingMessage: a header plus an opaque L2msg payload. The header is the input surface the STF reads: message type, sender, BlockNumber and Timestamp, the ordering/identity handle, and L1BaseFee (the parent-chain gas price used). Determinism comes from this: the STF never asks the outside world for the time or the gas price; it only reads what is in the header.\n3. One byte decides the path​\nThe header’s Kind routes the message. A handful of kinds are system messages that the protocol mints: Initialize (kind 11) is the genesis message that sets the chain ID and base fee, EthDeposit (kind 12) bridges the native token, SubmitRetryable (kind 9) carries the retryable-ticket mechanism behind robust parent-to-child chain messaging, and BatchPostingReport (kind 13) lets the STF charge the batch poster for the parent-chain data it consumes. The workhorse, though, is L2Message (kind 3)—the envelope for ordinary user activity. For every kind, its value, and the name the bridge contracts use for it, see the message type reference.\n4. The envelope inside the envelope​\nOpen an L2Message, and you’ll find a second type byte—the L2MessageKind. The type byte can be a single signed transaction (SignedTx), an unsigned EOA or contract call (UnsignedUserTx, ContractTx), or—most importantly—a Batch, which is simply a list of more L2 messages. This nesting is why the type space looks deceptively flat in summaries but is really two layers: an outer parent-chain framing and an inner transaction framing.\n5. From batch to messages​\nA batch posted to L1 isn’t a list of transactions; it can be either a Brotli-compressed blob or some calldata. The inbox multiplexer inspects the leading header byte, decompresses, and pops out individual L1IncomingMessages one at a time—the same shape the feed delivers. By the time anything reaches the STF, both doors have converged on the identical stream of envelopes.\n6. The unwrap​\nFinally, ParseL2Transactions turns each envelope into the EVM transactions Geth will run: deposits become ArbitrumDepositTx, retryables become their submission transaction, batches recurse, and bookkeeping kinds like RollupEvent are acknowledged and skipped. What flows out is an ordered list of transactions. That ordered list is derived deterministically from headers that no node can fabricate; it is the true input to Arbitrum’s State Transition Function.\nStylus-specific transaction processing​\nA modified version of Geth that recognizes and processes Stylus transactions, ensuring proper inclusion in state transitions.\nExecution in a WASM runtime​\nStylus transactions execute in ArbOS's WASM runtime instead of the EVM, enabling faster execution and more efficient computation.\nStylus gas accounting and pricing​\nUnlike standard EVM transactions, Stylus transactions introduce new gas pricing models that account for factors such as opcode pricing, host I/O operations, and Ink usage costs.\nInteroperability with the EVM​\nStylus contracts can interact with Solidity contracts, enabling hybrid applications that leverage EVM and WASM execution environments.\nThese Stylus-related changes aim to maintain compatibility with Ethereum’s execution model while introducing a more efficient, flexible, and scalable alternative for smart contract development.\nThe following sections cover STF inputs, node processing, and implementation rules, highlighting differences between Ethereum and Arbitrum, and Stylus execution environments. Stylus-specific execution tasks handled within ArbOS will be covered separately, focusing on host I/O operations, caching, and WASM memory management.How it worksStylus-specific transaction processingExecution in a WASM runtimeStylus gas accounting and pricingInteroperability with the EVM","tokens":1179,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261854083,"hash":"81e44bdee7bcfc995b7b62e8f50420be0ca19e86"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-v4-on-arc/25170","domain":"governance.aave.com","title":"[ARFC] Deploy Aave V4 on Arc - Governance / New Market - Aave","text":"[ARFC] Deploy Aave V4 on Arc \n\n GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 2\n\n read \n\n 7\n min\n\n Jun 19\n\n 1 / 10\n\n Jun 18\n\n Sep 18\n\n post by AaveLabs on Jun 19\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Summary\nThis ARFC proposes deploying Aave Protocol V4 on Arc Network.\nMotivation\nAave Labs proposes deploying Aave V4 on Arc, the institutional-grade public layer-1 blockchain built by Circle, at or near Arc mainnet launch.\nThe initial deployment would activate with one Liquidity Hub and two Spokes, supporting an initial set of high-quality assets: USDC, EURC, WETH and cirBTC.\nRelative to the Temp Check, which proposed an initial scope of USDC, EURC and cirBTC, this ARFC adds WETH as a fourth launch asset in response to demand signals from prospective liquidity providers and to strengthen day-one borrow markets.\nFollowing the Temp Check, this ARFC sets out the proposed initial token listing and parameters.\nDeploying on Arc provides several benefits:\n\nPositions Aave as a core lending protocol at launch.\n\nIncreases market access for Circle-issued assets.\n\nExpands Aave’s reach into institutional liquidity flows.\n\nGenerates additional protocol TVL and revenue.\n\nArc’s infrastructure is designed to concentrate stablecoin and tokenized asset liquidity, making it a logical fit for Aave.\nFollowing the passing of the TEMP CHECK Snapshot, this ARFC sets out the proposed launch topology, asset scope, oracle configuration, incentive structure, and rollout path.\nRollout\nThe rollout will follow a deliberately conservative, phased path. The deployment would launch at or near Arc mainnet with conservative caps, followed by monitored expansion and cap increases per LlamaRisk recommendations as live conditions support. Additional assets, including further RWA assets, could be onboarded through subsequent governance processes.\nIncentive and Revenue Structure\nIn connection with the deployment, Aave DAO is expected to receive a minimum of $2m per year in protocol revenue from the Aave V4 deployment on Arc, with any shortfalls covered by certain Arc ecosystem participants for the first five years following deployment. This structure provides protection for Aave DAO during the bootstrap phase.\nSpecification\nThis section will be updated upon receiving feedback from various stakeholders in the lead-up to the deployment.\nHub and Spoke Configuration\nThe proposed initial Arc deployment will activate with one Liquidity Hub and two Spokes.\n\nHub\nAssets\n\nArc Core Hub\ncirBTC, wETH, USDC, EURC\n\nHub\nSpoke\nCollateral\nBorrowable\n\nArc Core Hub\nMain Spoke\ncirBTC, wETH, USDC\nUSDC, EURC, cirBTC, WETH\n\nArc Core Hub\nForex Spoke\nUSDC, EURC\nUSDC, EURC\n\nRisk Parameters\nThe initial token listing and parameters will be updated based on the latest risk analyses.\nNext Steps\n\nGather community feedback and risk analysis from LlamaRisk\n\nEscalate the proposal to the ARFC Snapshot stage.\n\nIf the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.\n\nDisclaimer\nAave Labs is not compensated by Arc, nor affiliated with them.\nCopyright\nCopyright and related rights waived via CC0.\n\n 6\n\n 2\n\n read \n\n 7\n min\n\n post by MconnectDAO on Jun 19\n\n post by LlamaRisk on Jun 19\n\n 2 months later\n\n post by AaveLabs on Sep 2\n\n post by Abel189 on Sep 4\n\n 10 days later\n\n post by AaveLabs on Sep 14\n\n post by AaveLabs on Sep 14\n\n post by AaveLabs on Sep 15\n\n post by AaveLabs on Sep 16\n\n post by LlamaRisk on Sep 18\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Temp Check] Deploy Aave V4 on Arc\n\n New Market\n\n 5\n\n 837\n\n Jun 7\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n AL Technical Assessment Aave <> Arc\n\n Assessments\n\n 0\n\n 141\n\n Sep 14\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d","tokens":986,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261858913,"hash":"1dba2d2c10130b28c3dfaadc8001838aaf26e402"}
{"url":"https://specs.optimism.io/protocol/safe-extensions.html","domain":"specs.optimism.io","title":"Safe Extensions - OP Stack Specification","text":"Safe Contract Extensions\n\nTable of Contents\n\nSecurity Council Liveness Checking Extensions\n\nThe Liveness Guard\nThe Liveness Module\nOwner Removal Call Flow\nShutdown\nLiveness Security Properties\n\nLiveness Guard Security Properties\nLiveness Module Security Properties\n\nInterdependency between the Liveness Guard and Liveness Module\n\nOperational Considerations\n\nManual validation of new owner liveness\nDeploying the Liveness Checking System\nModifying the Liveness Checking System\n\nReplacing the Liveness Module\nReplacing the Liveness Guard\n\nThis document describes extensions to the Security Council and Guardian Safe contracts, which\nprovide additional functionality and security guarantees on top of those provided by the Safe\ncontract.\nThese extensions are developed using two types of contracts\n(modules and\nguards) which the Safe contract has\nbuilt-in support for:\n\nGuard contracts: can execute pre- and post- transaction checks.\nModule contracts: a contract which is\nauthorized to execute transactions via the Safe. This means the module must properly implement\nauth conditions internally.\n\nFor more information about the Security Council and Guardian roles, refer to the\nStage One Roles and Requirements document.\nSecurity Council Liveness Checking Extensions\nThe Security Council Safe is extended by the Liveness Checking Module and Guard. These extensions\nare intended to ensure that any loss of access to a signer's keys is identified and addressed\nwithin a predictable period of time.\nThis mechanism is intended only to be used to remove signers who have lost access to their keys, or\nare otherwise inactive. It is not intended to be used to remove signers who are acting in bad faith,\nor any other subjective criteria, such cases should be addressed by governance, and the removal\nhandled via the standard Safe ownership management functionality.\nThe Liveness Guard\nFor implementing liveness checks a LivenessGuard is created which receives the signatures from\neach executed transaction, and tracks the latest time at which a transaction was signed by each\nsigner. This time is made publicly available by calling a lastLive(address)(Timestamp) method.\nOwners are recorded in this mapping in one of 4 ways:\n\nUpon deployment, the guard reads the current set of owners from the Safe contract.\nWhen a new owner is added to the safe. Similarly, when an owner is removed from the Safe, its\nentry is deleted from the mapping.\nWhen a transaction is executed, the signatures on that transaction are passed to the guard and\nused to identify the signers. If more than the required number of signatures is provided, they\nare ignored.\nAn owner may call the contract's showLiveness()() method directly in order to prove liveness.\n\nNote that the first two methods do not require the owner to actually sign anything. However these\nmechanisms are necessary to prevent new owners from being removed before they have had a chance to\nshow liveness.\nThe Liveness Module\nA LivenessModule is also created which does the following:\n\nHas a function removeOwners() that anyone may call to specify one or more owners to be removed\nfrom the Safe.\nThe Module would then check the LivenessGuard.lastLive() to determine if the signer is eligible\nfor removal.\nIf so, it will call the Safe's removeSigner() to remove the non-live signer, and if necessary\nreduce the threshold.\nWhen a member is removed, the signing parameters are modified such that M/N is the lowest ratio\nwhich remains greater than or equal to 75%. Using integer math, this can be expressed as\nM = (N * 75 + 99) / 100.\n\nOwner Removal Call Flow\nThe following diagram illustrates the flow for removing a single owner. The verifyFinalState box\nindicates calls to the Safe which ensure the final state is valid.\n\nShutdown\nIn the unlikely event that the signer set (N) is reduced below the allowed minimum number of\nowners, then (and only then) is a shutdown mechanism activated which removes the existing signers,\nand hands control of the multisig over to a predetermined entity.\nLiveness Security Properties\nThe following security properties must be upheld:\nLiveness Guard Security Properties\n\nSignatures are assigned to the correct signer.\nNon-signers are unable to create a record of having signed.\nAn owner cannot be censored or griefed such that their signing is not recorded.\nOwners may demonstrate liveness either by signing a transaction or by calling directly to the\nguard.\nIt must be impossible for the guard's checkTransaction or checkAfterExecution method to\npermanently revert given any calldata and the current state.\nThe guard correctly handles updates to the owners list, such that new owners are recorded, and\nremoved owners are deleted.\n\nAn ownersBefore enumerable set variable is used to accomplish this, it must be emptied at\nthe end of the checkAfterExecution call.\n\nLiveness Module Security Properties\n\nDuring a shutdown the module correctly removes all signers, and converts the safe to a 1 of 1.\nThe module only removes an owner if they have not demonstrated liveness during the interval, or\nif enough other owners have been removed to activate the shutdown mechanism.\nThe module correctly sets the Safe's threshold upon removing a signer.\n\nNote: neither the module nor guard attempt to prevent a quorum of owners from removing either the\nliveness module or guard. There are legitimate reasons they might wish to do so. Moreover, if such a\nquorum of owners exists, there is no benefit to removing them, as they are defacto 'sufficiently\nlive'.\nInterdependency between the Liveness Guard and Liveness Module\nThe guard has no dependency on the module, and can be used independently to track liveness of Safe\nowners.\nThis means that the module can be removed or replaced without any affect on the guard.\nThe module however does have a dependency on the guard; if the guard is removed from the Safe, then\nthe module will no longer be functional and calls to its removeOwners function will revert.\nOperational Considerations\nManual validation of new owner liveness\nAs noted above newly added owners are recorded in the guard without\nnecessarily having signed a transaction. Off-chain validation of the liveness of an address must\ntherefore be done prior to adding a new owner.\nDeploying the Liveness Checking System\nThe module and guard are intended to be deployed and installed on the safe in the following\nsequence:\n\nDeploy the guard contract. The guard's constructor will read the Safe's owners and set a\ntimestamp.\nDeploy the module.\nSet the guard on the safe.\nEnable the module on the safe.\n\nThis order of operations is necessary to satisfy the constructor checks in the module, and is\nintended to prevent owners from being immediately removable.\nNote that changes to the owners set should not be made between the time the module is deployed, and\nwhen it is enabled on the Safe, otherwise the checks made in the module's constructor may be\ninvalidated. If such changes are made, a new module should be deployed.\nModifying the Liveness Checking System\nChanges to the liveness checking system should be done in the following manner:\nReplacing the Liveness Module\nThe module can safely be removed without affecting the operation of the guard. A new module can then\nbe added.\nNote: none of the module's parameters are modifiable. In order to update the security properties\nenforced by the module, it must be replaced.\nReplacing the Liveness Guard\nThe safe can only have one guard contract at a time, and if the guard is removed the module will\ncease to function. This does not affect the ability of the Safe to operate normally, however the\nmodule should be removed as a best practice.\nIf a new guard is added, eg. as a means of upgrading it, then a new module will also need to be\ndeployed and enabled. Once both the guard and module have been removed, they can be replaced\naccording to the steps in the Deployment section above.","tokens":1972,"squid":"ink-governance","role":"Council Listener","at":1791261859796,"hash":"5c1c2fa8e46712390c34fc55973ac6381d848897"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/run-a-node/high-availability-sequencer","domain":"docs.arbitrum.io","title":"How to set up a high-availability sequencer | Arbitrum Docs","text":"✏️Request an updatenoteThis documentation is for production sequencer deployments. If you want to set up a sequencer for testing or on a testnet, see How to run a testnet sequencer node.\nIntroduction​\nThe sequencer is a critical component of your Arbitrum chain and is responsible for queuing transactions submitted to the network. It serves as the transaction ordering engine, accepting transactions forwarded from full nodes, queuing them, and returning feed messages to those full nodes. It subsequently sends queued transactions to batch posters for data posting.\nIf your sequencer goes offline, the network cannot process new transactions arriving at the child chain's RPC nodes, impacting the user experience. This guide provides detailed instructions for setting up a high-availability (HA) sequencer architecture to minimize downtime and ensure your Arbitrum chain remains operational even if individual components fail.\nPrerequisites​\nBefore you begin, ensure you have:\n\nExperience with Kubernetes and container orchestration\nAccess to a Kubernetes cluster with multiple availability zones\nUnderstanding of Redis and cloud infrastructure\nA properly configured parent chain node or RPC node endpoint\nSequencer keys and permissions\nSufficient storage and compute resources\n\nHigh-availability sequencer architecture​\nA high-availability sequencer deployment consists of seven key components:\n\nCDN/Load Balancer: Manages traffic routing and bot detection\nNitro full nodes: Process read requests and forward write transactions\nExternal Relays: Handle public feed traffic\nSequencer Relays: Combine feeds from all sequencers\nSequencers: Multiple redundant transaction queuing machines\nRedis: Coordinates active sequencer selection and sequencer-related information sharing\nBatch Poster: Posts transaction batches to the parent chain\n\nArchitecture diagrams​\nThe architecture varies slightly depending on whether your full nodes use Redis to identify the active sequencer or forward transactions to a predefined endpoint.\nSend to active enabled​\nIn this configuration, full nodes query Redis to determine the active sequencer and forward transactions directly to it:\n\nSend to active disabled​\nIn this configuration, full nodes forward transactions to a predefined endpoint without checking which sequencer is active:\n\nUsing Helm charts for deployment​\nWe recommend using the Offchain Labs community Helm charts to deploy your high-availability sequencer setup. These charts provide pre-configured templates for all the necessary components and make it easier to maintain your deployment. Base configuration values are provided in the examples below. However, you should adjust them to fit your needs and use values files for production deployments.\nDetailed component setup​\n1. Load balancing (CDN)​\nWe strongly recommend using a CDN for managing traffic and security concerns:\n\nRecommendation: Use Cloudflare or a similar CDN service\nConfiguration:\n\nDirect RPC traffic to the Nitro full node fleet\nDirect feed traffic to public-facing relays\nImplement rate limiting and bot detection as needed\n\nBenefits: Distributes load, improves security, and enhances availability\n\n2. Relays setup​\nThe architecture requires two types of relays:\nSequencer relays​\n\nDeployment should have multiple replicas\nConfigure to listen to feed outputs from all sequencers\nAll other components connect to these relays instead of directly to the sequencers\nMinimize direct load on sequencer nodes\n\nDeploy sequencer relays using the relay Helm chart:\nhelm install sequencer-relay offchainlabs/relay \\ --set replicaCount=2 \\ --set configmap.data.chain.id=<your-chain-id> \\ --set configmap.data.node.feed.input.url=ws://sequencer-nitro-0.sequencer-nitro:9642,ws://sequencer-nitro-1.sequencer-nitro:9642,ws://sequencer-nitro-2.sequencer-nitro:9642\nKey configuration parameters:\n\nreplicaCount: Number of relay replicas to deploy (recommend at least two for high availability)\nconfigmap.data.chain.id: Your chain ID\nconfigmap.data.node.feed.input.url: Comma-separated list of WebSocket URLs for all sequencer feed outputs. This relies on the perReplicaHeadlessService.enabled=true parameter in the sequencer deployment to create individual services for each sequencer replica.\n\nExternal relays​\n\nConnect to Sequencer Relays (not directly to sequencers)\nHandle all public feed requests\nProvide an additional layer of isolation for production sequencers\nSince these are public-facing, ensure they scale appropriately based on your traffic needs:\n\nhelm install external-relay offchainlabs/relay \\ --set replicaCount=2 \\ --set configmap.data.chain.id=<your-chain-id> \\ --set configmap.data.node.feed.input.url=ws://sequencer-relay:9642\nYou can check run a feed relay to see how to set up a relay node.\n3. Nitro full node setup​\nhelm install fullnode offchainlabs/nitro \\ --set replicaCount=2 \\ --set configmap.data.parent-chain.id=<parent-chain-id> \\ --set configmap.data.parent-chain.connection.url=<parent-node-url> \\ --set configmap.data.chain.id=<child-chain-id> \\ --set configmap.data.execution.forwarding-target=http://sequencer-nitro:8547\nSend to active configuration (optional)​\nTo enable Redis-based active sequencer discovery:\n\nMonitor Redis to identify the active sequencer\nEnable with: -execution.forwarder.redis-url=redis://<redis-url>:6379\nEnsure connectivity to individual sequencer services and Redis\nTest failover scenarios before production deployment\n\nhelm install fullnode offchainlabs/nitro \\ --set replicaCount=2 \\ --set configmap.data.parent-chain.id=<parent-chain-id> \\ --set configmap.data.parent-chain.connection.url=<parent-node-url> \\ --set configmap.data.chain.id=<child-chain-id> \\ --set configmap.data.execution.forwarder.redis-url=redis://<redis-url>:6379\nMutating-only endpoint (optional)​\nFor high availability, we recommend routing mutating transactions to a fleet of precheckers, which forward them to the sequencer. To do this, set up a separate endpoint for mutating transactions and allow only calls such as eth_sendRawTransaction to route to the precheckers, which then route to the sequencer. This insulates the sequencer from unnecessary load and enables it to focus on transaction ordering. However, this configuration requires custom load-balancing logic and is out of scope for this guide.\n4. Redis setup​\nSet up a highly available Redis cluster for sequencer coordination:\nDeployment options​\n\nUse a managed service like AWS ElastiCache (recommended)\nDeploy within Kubernetes using a StatefulSet with PersistentVolumeClaims\n\nRequirements​\n\nMinimum of three replicas across different availability zones (recommended)\n\nSecured access (only accessible within the Kubernetes cluster)\n\nBackups enabled\n\nConfiguration:\n\nUse a Redis cluster or Redis Sentinel for high availability\nSecure the endpoint with proper network policies\nMonitor Redis health as part of your overall monitoring strategy\n\n5. Sequencer setup​\nDeploy multiple sequencer replicas with availability zone spread using the Nitro Helm chart (availability zone spread is not demonstrated in the example below):\nhelm install sequencer offchainlabs/nitro \\ --set replicaCount=3 \\ --set configmap.data.parent-chain.id=<parent-chain-id> \\ --set configmap.data.parent-chain.connection.url=<parent-node-url> \\ --set configmap.data.chain.id=<child-chain-id> \\ --set configmap.data.node.sequencer=true \\ --set configmap.data.node.delayed-sequencer.enable=true \\ --set configmap.data.node.seq-coordinator.enable=true \\ --set configmap.data.node.seq-coordinator.redis-url=<redis-url> \\ --set configmap.data.node.feed.output.enable=true \\ --set configmap.data.node.feed.output.port=9642 \\ --set configmap.data.execution.sequencer.enable=true \\ --set perReplicaHeadlessService.enabled=true\nCritical sequencer coordinator parameters​\nThe sequencer coordinator is the key component for high availability. These parameters are essential:\nParameterDescriptionRecommended Valuenode.seq-coordinator.enableEnable sequencer coordinatortruenode.seq-coordinator.redis-urlRedis URL for coordinationYour Redis URLnode.seq-coordinator.my-urlURL for this sequencerUnique per sequencer\nFor the full set of coordinator flags and their defaults, see Sequencer configuration reference.\nRedis priority registration​\nConfiguring redis-url and my-url is not enough to make a sequencer eligible. Each sequencer must also appear in the Redis priority list, stored under the key coordinator.priorities as a comma-separated list of URLs in priority order.\nNitro treats this key as read-only. No sequencer can write itself into it. You populate it with the Sequencer Coordination Manager (SQM), which is the only component that writes the key.\nA sequencer that is not in the list starts cleanly, syncs, serves RPC, and broadcasts to the feed—but never becomes the active sequencer.\nHow the coordinator picks the active sequencer:\n\nIt reads coordinator.priorities from Redis.\nIt goes through the list in order and takes the first sequencer that has published a liveliness key at coordinator.liveliness.<my-url>. Each sequencer writes its own key when it is synced and ready.\nThat sequencer acquires the lockout, recorded at coordinator.chosen, and activates. Everything else forwards to it.\n\nTwo consequences follow from step 2:\n\nOrder is priority. The first entry that is healthy and synced wins. Put your preferred sequencer first.\nmy-url must match its list entry exactly. The comparison is a string match. A trailing slash, a different port form, or an IP address instead of a hostname all cause a silent mismatch.\n\nNever register the batch posterThe batch poster runs with node.seq-coordinator.enable=true so it can follow coordination state, but it must stay out of coordinator.priorities. If it reaches the top of the list, it is selected as the active sequencer while having no sequencer to run, and the chain stops producing blocks. Nitro logs myurl main sequencer, but no sequencer exists.\nVerifying registration​\nRead the key directly:\nredis-cli -u <redis-url> GET coordinator.priorities\nCompare each URL against the node.seq-coordinator.my-url of the sequencer it should match. Then check which sequencer currently holds the lockout, and which ones report themselves ready:\nredis-cli -u <redis-url> GET coordinator.chosenredis-cli -u <redis-url> --scan --pattern 'coordinator.liveliness.*'\nA sequencer that appears in coordinator.priorities but has no matching coordinator.liveliness.<my-url> key is not eligible. It is either unsynced or its my-url does not match its list entry.\nTwo log messages tell you the priority list is the problem:\n\nsequencer priorities unset — the key does not exist. This is expected on a new Redis instance and means no sequencer can ever be chosen until you populate it.\nno sequencer appears to want the lockout on redis — the key exists, but nothing on it is eligible. The log includes the priorities value, so compare it against your running sequencers. This starts at DEBUG, escalates to WARN after 10 seconds and ERROR after 20.\n\nFor a full diagnostic path, see Sequencer troubleshooting.\nRedis persistenceThe priority list lives only in Redis. If you replace the Redis instance or lose its data, the key is gone and no sequencer becomes active until you repopulate it. Include coordinator.priorities in your backup and disaster recovery plan, and re-register after any Redis migration.\nSetting the sequencer's self URL​\nA critical configuration for the sequencer coordinator is setting a unique URL for each sequencer instance. This configuration can be adjusted using Kubernetes environment variables:\nextraEnv: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: NITRO_NODE_SEQ__COORDINATOR_MY__URL value: 'http://$(POD_NAME).<NAMESPACE>.svc.cluster.local:8547/rpc'\nThis configuration:\n\nGets the pod name from Kubernetes metadata\nUses it to create a unique URL for each sequencer instance\nSets this URL as the node.seq-coordinator.my-url parameter\n\nAdjust the domain name (<NAMESPACE>.svc.cluster.local) to match your Kubernetes cluster's DNS configuration. This configuration requires Nitro to be configured to read environment variables beginning with NITRO_.\nIndividual sequencer services​\nYou can enable the automatic creation of headless services for each sequencer replica by setting the perReplicaHeadlessService.enabled=true parameter in the Helm chart (as shown in the installation command above). This configuration creates individual services named <release-name>-nitro-<index> that allow direct access to each sequencer replica.\nThese individual services are critical for a proper high-availability setup because they allow components like sequencer relays to connect directly to specific sequencer instances. This direct connection is essential for:\n\nProper failover: When the active sequencer changes, other components can address the new active sequencer directly\nFeed aggregation: Sequencer relays need to collect feeds from all sequencer instances to ensure no messages get lost during transitions\n\n6. Sequencer Coordination Manager​\nTo manage active sequencer selection, use the built-in sequencer coordinator UI:\n\nFollow detailed instructions at: How to run a Sequencer Coordination Manager (SQM)\nUse this interface to manually switch between sequencer replicas when needed\nConfigure permissions and access controls appropriately\n\n7. Batch poster setup​\nDeploy the batch poster using the Nitro Helm chart:\nhelm install batchposter offchainlabs/nitro \\ --set configmap.data.parent-chain.id=<parent-chain-id> \\ --set configmap.data.parent-chain.connection.url=<parent-node-url> \\ --set configmap.data.chain.id=<child-chain-id> \\ --set configmap.data.execution.forwarding-target=null \\ --set configmap.data.node.seq-coordinator.enable=true \\ --set configmap.data.node.seq-coordinator.redis-url=<redis-url> \\ --set configmap.data.node.batch-poster.enable=true \\ --set \"configmap.data.node.batch-poster.parent-chain-wallet.private-key=<your-private-key>\"\nImportantDo not add the batch poster to the sequencer priority list in the Sequencer Coordination Manager (SQM) to prevent it from becoming the active sequencer unintentionally.\nMonitoring and maintenance​\nHealth checks​\nImplement comprehensive health checks for all components:\n\nSequencer health: Monitor the sequencer's logs and metrics\nRedis connectivity: Ensure all components can access Redis\nFeed availability: Verify feed connectivity between components\nTransaction processing: Monitor end-to-end transaction flow\n\nTroubleshooting​\nIf you run into any issues, visit the node-running troubleshooting guide.\nReferences​\n\nHow to run a full node\nHow to run a Sequencer Coordination Manager (SQM)\nKubernetes Documentation\nOffchain Labs Community Helm Charts\nIntroductionPrerequisitesHigh-availability sequencer architectureArchitecture diagramsUsing Helm charts for deploymentDetailed component setup1. Load balancing (CDN)2. Relays setup3. Nitro full node setup4. Redis setup5. Sequencer setup6. Sequencer Coordination Manager7. Batch poster setupMonitoring and maintenanceHealth checksTroubleshootingReferences","tokens":3771,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791261866241,"hash":"2f4ecd2b5036d43766d887af9e563f4a58deea6e"}
{"url":"https://ethresear.ch/c/cryptography/28/l/top","domain":"ethresear.ch","title":"Top Cryptography topics - Ethereum Research","text":"Top topics in Cryptography\n\n Cryptography\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n All time\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Using polynomial commitments to replace state roots\n\n Cryptography\n\n polynomial-commitment\n\n 10\n\n 17.4k\n\n Apr 2020\n\n So you wanna Post-Quantum Ethereum transaction signature\n\n Cryptography\n\n 27\n\n 3.4k\n\n May 26\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n Cryptography\n\n 25\n\n 20.4k\n\n Apr 2024\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Cryptography\n\n 22\n\n 3.7k\n\n Mar 19\n\n Blind Find: Private social network search\n\n Multiparty Computation\n\n 16\n\n 7.3k\n\n Jul 2020\n\n Proof of Validator: A simple anonymous credential scheme for Ethereum’s DHT\n\n Cryptography\n\n data-availability\n\n 9\n\n 4.6k\n\n Feb 2025\n\n Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators\n\n Cryptography\n\n 13\n\n 1.5k\n\n 28d\n\n How obfuscation can help Ethereum\n\n Cryptography\n\n 11\n\n 6.2k\n\n Nov 2024\n\n Open problem: ideal vector commitment\n\n Cryptography\n\n polynomial-commitment,vector-commitment\n\n 27\n\n 19.2k\n\n Aug 2022\n\n Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly\n\n Cryptography\n\n 9\n\n 1.7k\n\n Jan 2025\n\n Octopus Contract and its Applications\n\n Cryptography\n\n 17\n\n 5.6k\n\n Apr 2024\n\n Security of BLS batch verification\n\n Cryptography\n\n 9\n\n 6.6k\n\n Jan 2025\n\n MACI with mostly-off-chain “happy path”\n\n Cryptography\n\n 13\n\n 6.9k\n\n Jul 2024\n\n M-of-N secret sharing with pre-known shares\n\n Cryptography\n\n 10\n\n 5.7k\n\n Feb 2024\n\n Lattice-based signature aggregation\n\n Cryptography\n\n post-quantum\n\n 8\n\n 2.8k\n\n Aug 30\n\n Open problem: improving stealth addresses\n\n Cryptography\n\n 24\n\n 9.0k\n\n Oct 2023\n\n Privacy/Anonymity on Ethereum is Doomed\n\n Cryptography\n\n transaction-privacy\n\n 14\n\n 8.0k\n\n Aug 2019\n\n Statement regarding the public report on the analysis of MinRoot\n\n Cryptography\n\n 1\n\n 6.8k\n\n Sep 2023\n\n FHE-DKSAP: Fully Homomorphic Encryption based Dual Key Stealth Address Protocol\n\n Cryptography\n\n transaction-privacy\n\n 12\n\n 7.7k\n\n Oct 2023\n\n Kate Commitments for aggregated off-chain voting\n\n Cryptography\n\n 10\n\n 3.2k\n\n Jun 2021\n\n MPC on Ethereum\n\n Multiparty Computation\n\n 11\n\n 12.1k\n\n Feb 2018\n\n Do not add bls12 precompile, implement Pasta curves w/o trusted setup instead\n\n Cryptography\n\n 26\n\n 8.1k\n\n Sep 2024\n\n Introducing Bandersnatch: a fast elliptic curve built over the BLS12-381 scalar field\n\n Cryptography\n\n 4\n\n 10.5k\n\n May 11\n\n Default post-quantum signature scheme?\n\n Cryptography\n\n post-quantum\n\n 10\n\n 6.9k\n\n Jan 2024\n\n VDFs: Delay Encryption\n\n Cryptography\n\n verifiable-delay-functions\n\n 12\n\n 4.4k\n\n Sep 2020\n\n Offchain voting protocol with merkle trees\n\n Cryptography\n\n 12\n\n 3.3k\n\n Dec 2020\n\n Anyone working on Solidity-verifiable VDF?\n\n Cryptography\n\n 15\n\n 5.2k\n\n Jul 2023\n\n Releasing Constantine v0.2.0 (Jan 2025), a modular cryptography stack for Ethereum\n\n Cryptography\n\n library\n\n 2\n\n 3.4k\n\n Apr 3\n\n Hashing to elliptic curves $y^2 = x^3 + b$ provided that $b$ is a quadratic residue\n\n Cryptography\n\n 10\n\n 3.5k\n\n Dec 2020\n\n Truebit-protocol front running vulnerability\n\n Multiparty Computation\n\n 19\n\n 4.5k\n\n Mar 2018\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Cryptography\n\n account-abstraction,post-quantum\n\n 1\n\n 1.3k\n\n May 20\n\n Proof of sequential work\n\n Cryptography\n\n proofs-of-sequential-work\n\n 13\n\n 4.3k\n\n Feb 2018\n\n A minimum-viable KZG polynomial commitment scheme implementation\n\n Cryptography\n\n polynomial-commitment\n\n 0\n\n 4.2k\n\n Jul 2020\n\n Proposed PQ upgrade for ecrecover\n\n Cryptography\n\n account-abstraction,post-quantum\n\n 10\n\n 376\n\n Sep 4\n\n Weighted Threshold BLS for Ethereum 2.0\n\n Cryptography\n\n 9\n\n 2.3k\n\n May 2020\n\n Signature Merging for Large-Scale Consensus\n\n Cryptography\n\n signature-aggregation,single-slot-finality\n\n 3\n\n 7.0k\n\n May 2024\n\n Simple guide to fast linear combinations (aka multiexponentiations)\n\n Cryptography\n\n 2\n\n 8.5k\n\n Jul 2025\n\n Post Quantum Signature Aggregation: a Folding Approach\n\n Cryptography\n\n 0\n\n 1.2k\n\n Dec 2025\n\n Poseidon hash for Ethereum is NOT secure!\n\n Cryptography\n\n 15\n\n 379\n\n Aug 30\n\n Cryptographic Obfuscation for Smart Contracts: Trustless Bitcoin Bridge and More\n\n Cryptography\n\n 0\n\n 3.8k\n\n Mar 2023\n\n Linearly-homomorphic signatures for RLNC\n\n Cryptography\n\n networking\n\n 2\n\n 584\n\n Mar 5\n\n Fast $\\mathbb{G_2}$ subgroup check in BN254\n\n Cryptography\n\n 0\n\n 3.2k\n\n Oct 2022\n\n Anonymous Inclusion Lists (anon-ILs)\n\n Cryptography\n\n censorship-resistance\n\n 0\n\n 3.1k\n\n May 2024\n\n The ~~EC~~FFT algorithm (without elliptic curve and isogenies!)\n\n Cryptography\n\n 0\n\n 4.0k\n\n Nov 2021\n\n A Universal Verification Equation for Data Availability Sampling\n\n Cryptography\n\n data-availability\n\n 0\n\n 6.4k\n\n Aug 2022\n\n Migration Strategies for EOAs under the Quantum Threat: Breakages, and Open Questions\n\n Cryptography\n\n post-quantum\n\n 4\n\n 537\n\n Mar 21\n\n Radius SKDE: Enhancing Rollup Composability with Trustless Sequencing\n\n Cryptography\n\n mev\n\n 0\n\n 2.0k\n\n Apr 2024\n\n PeekABook: Private order matching\n\n Multiparty Computation\n\n 7\n\n 3.9k\n\n Feb 2021\n\n SPHINCS minus : Efficient Stateless Post-Quantum Signature Verification on the EVM\n\n Cryptography\n\n 0\n\n 2.7k\n\n Jun 12\n\n Adding cross-transaction BLS signature aggregation to ethereum\n\n Cryptography\n\n signature-aggregation\n\n 3\n\n 4.0k\n\n Feb 2021","tokens":1339,"squid":"ink-research","role":"Deep Scholar","at":1791261875554,"hash":"3133cf1a01b4e1aad96a29124d3d64221d3a1826"}
{"url":"https://governance.aave.com/t/arfc-deploy-a-dedicated-aave-v4-whitelabel-instance-fully-managed-by-etherfi-on-op-mainnet-to-power-ether-fi-cash/25314","domain":"governance.aave.com","title":"[ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash - Governance / General - Aave","text":"[ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 7\n min\n\n Jul 14\n\n 1 / 4\n\n Jul 14\n\n Jul 26\n\n post by ether.fi on Jul 14\n\n ether.fi\n\n Author: Ether.Fi\nDate: 2026-07-14\nTemp Check discussion: [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\nTemp Check Snapshot (passed): Snapshot vote\n\nSummary\nFollowing the successful TEMP CHECK Snapshot, this ARFC formalizes the deployment of a dedicated, EtherFi-operated Aave V4 hub on OP Mainnet to serve as the credit backend for EtherFi Cash, our Visa card product used by tens of thousands of cardholders. The instance replaces the bespoke borrow/lend market (“Debt Manager”) that powers Cash today.\nThe instance is isolated and borrow-whitelisted: borrowing is restricted exclusively to EtherFi Cash users, while EtherFi operates it end to end - configuration, risk parameters, liquidity, and growth - while Aave provides the V4 deployment and operating license and earns a share of the revenue the instance generates. Because the instance is ring-fenced and EtherFi-run, Aave carries the upside without taking on the market’s day-to-day risk.\nThe proposal carries a substantial commercial package contributed by EtherFi and the Optimism Foundation, detailed in the Commercial Terms section: a 20% revenue share to the Aave DAO, GHO integration into EtherFi Cash, an Aave-deployed GHO GSM on OP Mainnet, full migration of the EtherFi Debt Manager, up to $175M in assets at launch, and product exclusivity to Aave V4.\nRelative to the Temp Check, this ARFC adds: (i) the hub-and-spoke topology, (ii) the operating model and permissions matrix, naming Nonce Capital as independent risk admin, (iii) the Debt Manager migration approach, (iv) the reference parameter baseline from the current Cash configuration, (v) a launch reserve set that mirrors the full current Cash collateral configuration, including LiquidEUR and LiquidRWA (both already live in the Debt Manager), and (vi) responses to feedback raised during the Temp Check stage.\nMotivation\nEtherFi Cash today. Cash lets cardholders spend against both yield-bearing and non-yield bearing collateral at the point of sale: they borrow a stablecoin to settle a card transaction while preserving their underlying asset exposure. It runs in production on OP Mainnet on a custom, non-pooled borrow/lend market with roughly $25M in active borrows across 16+ collateral assets and a high-frequency, low-ticket, well-distributed borrow profile. We are targeting roughly $500M in assets on the instance by the end of 2026.\nWhy migrate to Aave V4. Maintaining a bespoke lending engine is increasingly operationally taxing. Migrating to a dedicated Aave V4 instance lets EtherFi inherit audited, battle-tested infrastructure and governance machinery while preserving the Cash product surface (User Safes, Credit/Debit modes, settlement) above it.\nWhy this is a fit for Aave.\n\nPure-upside revenue. Aave shares in the borrow revenue of a live consumer product without committing pool liquidity or balance sheet to it. At our end-2026 target scale, the instance is projected to generate an estimated $5-6M in annual reserve-factor revenue, 20% of which accrues directly to the Aave DAO and compounds as the Cash book grows.\n\nDirect GHO adoption. GHO becomes a supply/borrow reserve on the instance after GHO is deployed on OP Mainnet, with an Aave-deployed GSM strengthening GHO’s peg and liquidity on OP Mainnet.\n\nGHO as a spend currency. Beyond being a listed reserve, GHO could, at the Aave DAO’s discretion, be enabled as a deposit/spend asset in Cash, subject to sufficient GHO liquidity to support the Cash program as expected, turning card volume into organic GHO demand.\n\nReal-world spend footprint. Aave extends into consumer card settlement, anchored by a product with tens of thousands of active cardholders.\n\nNet new on-chain activity on OP Mainnet, with exclusivity to Aave V4 for the Cash product.\n\nAave Labs supports deploying the instance and providing the operating license. The Temp Check Snapshot has passed, confirming community sentiment; this ARFC finalizes the specification with service-provider input ahead of an AIP.\nClarifications Following Temp Check Feedback\nWe thank delegates for the engagement on the Temp Check thread. The questions raised broadly fall into four areas, addressed below.\n1. Allocation of responsibility. EtherFi is the operator of EtherFi Cash and of the instance, and bears operational, legal and regulatory responsibility for the Cash product: configuration, risk parameters, oracles, asset onboarding, liquidity, liquidator infrastructure, and cardholder-facing operations. The Aave DAO’s role is limited to licensing the V4 codebase for a whitelisted, isolated deployment; the DAO does not operate the instance, set its parameters, custody user funds, or market the Cash product, and the operating license reflects this allocation of responsibility and ring-fencing explicitly.\n2. Term, renegotiation, and exit. As stated in the Temp Check, Aave provides the V4 codebase under license for a 2-year initial term. The operating license includes customary renewal provisions and defined termination rights for each party, together with contractual obligations on EtherFi to wind the instance down in an orderly, user-protective manner on termination or expiry, facilitating the repayment, migration, and offboarding of user positions. Optionality is therefore not one-way: both sides hold defined renegotiation and exit paths, and the DAO’s economic interests are contractually protected for the duration of the term.\n3. Revenue assumptions and net contribution to the DAO. To clarify the revenue base: the $5-6M estimate refers to total instance reserve-factor revenue (the V4 “Liquidity Fee”) at the end-2026 target scale, of which the Aave DAO receives 20%, approximately $1.0-1.2M annually at that scale, growing with the Cash book.\n\nTarget instance assets (end-2026): ~$500M\n\nRevenue base: all instance protocol revenue (Liquidity Fee, liquidation fees, SVR, other fee streams). Projection below covers the Liquidity Fee component only.\n\nProjected annual reserve-factor revenue at target scale: ~$5-6M\n\nAave DAO share (20%): ~$1.0-1.2M per year\n\nOn cost allocation: Aave’s contribution is limited to the V4 deployment, the operating license, and the GHO GSM; instance operations, risk management, liquidity sourcing, incentives, monitoring, and liquidator infrastructure are borne by EtherFi per the Commercial Terms. The DAO bears no ongoing operating costs for the instance, so the 20% share is substantially net revenue to the DAO.\n4. Framework categorization. This deployment is a whitelabel instance, comparable in structure to Tydro (a dedicated, operator-managed V4 deployment under license), not a friendly fork. Consideration to the Aave DAO takes the form of the 20% share of all instance revenues, product exclusivity to Aave V4, GHO integration and the GSM footprint on OP Mainnet, and the launch capitalization package, including the $1.2M joint incentive commitment EtherFi has made together with the Optimism Foundation, rather than token consideration.\nSpecification\nArchitecture\nA dedicated Aave V4 deployment on OP Mainnet, one of V4’s first Layer 2 targets, consisting of one Liquidity Hub and, at launch, a single spoke listing the full current Cash collateral set. The instance is whitelisted and isolated from Aave’s shared liquidity and all other Aave markets. Borrow access is permissioned: only EtherFi Cash Users may open borrow positions on the instance. Supply access is not restricted to cardholders, allowing third-party liquidity provision (e.g., the Optimism Foundation’s launch deposit). EtherFi operates the instance end to end and is responsible for collateral listing, risk parameters, oracles, and ongoing risk management. Aave provides the V4 codebase under license for a 2-year initial term, but is not responsible for the instance’s assets, configuration, or risk.\n\nHub: EtherFi Cash Hub (OP Mainnet), the instance’s sole Liquidity Hub.\n\nSpoke: Cash Spoke, a single spoke at launch, listing the full current Cash collateral set.\n\nCollateral: weETH, wETH, eBTC, USDC, USDT, EURC, frxUSD, GHO, ETHFI, sETHFI, eUSD, OP, beHYPE, wHYPE, LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve, LiquidEUR, LiquidRWA\n\nBorrowable: USDC, GHO (pending deployment)\n\nAdditional spokes may be introduced over time via the risk-admin role as the Cash book grows and V4 architecture evolves.\nOperating Model & Permissions\nEtherFi acts as operator and will authorize Nonce Capital as the independent risk admin for the instance. Nonce Capital serves as curator of the ether.fi Liquid vault suite, bringing direct familiarity with the Cash collateral set while remaining organizationally independent of the operator. EtherFi may additionally engage further service providers over time to provide supplementary review of the market. The risk admin holds authority over:\n\nCollateral listing and de-listing\n\nOracle selection (Chainlink, RedStone, or otherwise) and configuration\n\nCollateral factors, liquidation thresholds, and liquidation bonus configuration per asset\n\nInterest rate models, supporting both utilization-curve and fixed-rate reserves\n\nAdd caps, draw caps, and pause states\n\nDivision of responsibilities:\n\nEtherFi (Operator): executes instance configuration; proposes collateral listings, oracles, and risk parameters to the risk admin; owns liquidity sourcing, market growth, and liquidator infrastructure.\n\nNonce Capital (Independent Risk Admin): approves and configures all risk-relevant changes per the authorities listed above.\n\nAave Labs: provides the V4 deployment and operating license; deploys the GHO GSM on OP Mainnet.\n\nAave DAO: ratifies the deployment via governance; governs GHO facilitation; receives the 20% revenue share, settled automatically on-chain.\n\nLaunch Collateral Set\nLaunch reserves mirror the existing Cash collateral set, with streamlined additions over time via the risk-admin role:\n\nETH-likes: weETH, wETH\n\nBTC-likes: eBTC\n\nStables: USDC, USDT, EURC, frxUSD, GHO\n\nEtherFi platform, Optimism & HYPE: ETHFI / sETHFI, eUSD, OP, beHYPE, wHYPE\n\nLiquid vault receipts: LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve, LiquidEUR, LiquidRWA\n\nBorrow reserves. USDC and GHO, each added as both a supply and a borrowable asset. GHO is enabled upon GHO’s deployment on OP Mainnet.\nRisk Parameters\nInitial parameters are intended to mirror the current Cash Debt Manager configuration as closely as V4 mechanics permit, providing continuity for the migrated book. The current production configuration on OP Mainnet, which serves as the reference baseline, is as follows (see the Cash collateral & borrowing documentation):\nAsset\nLTV | Liquidation Threshold | Liquidation Bonus\nUSDC\n90% | 95% | 1%\nUSDT\n90% | 95% | 1%\nEURC\n90% | 95% | 1%\nfrxUSD\n90% | 95% | 1%\nweETH\n55% | 75% | 3.5%\nwETH\n55% | 75% | 3.5%\neBTC\n52% | 72% | 5%\neUSD\n80% | 90% | 2%\nETHFI / sETHFI\n20% | 50% | 5%\nOP\n20% | 50% | 5%\nwHYPE\n45% | 65% | 4%\nbeHYPE\n40% | 60% | 5%\nLiquidETH\n50% | 70% | 5%\nLiquidBTC\n50% | 70% | 5%\nLiquidUSD\n80% | 90% | 2%\nLiquidReserve\n80% | 90% | 2%\nLiquidEUR\n70% | 90% | 2%\nLiquidRWA\n70% | 90% | 2%\nGHO parameters will be set by Nonce Capital upon GHO’s deployment on OP Mainnet.\nInterest Rate Models\nReserves support both standard two-slope utilization-curve IRMs and fixed-rate configurations where appropriate for the Cash borrow profile. Initial IRM parameters will be published alongside the parameter set above.\nOracles\nOracle providers (Chainlink, RedStone, or otherwise) will be selected and configured per asset by Nonce Capital, with exchange-rate pricing and appropriate safeguards applied to collateral where suitable.\nLiquidations\nThe instance uses Aave V4’s standard partial liquidation behavior, including the dynamic liquidation bonus mechanism. EtherFi adapts its existing liquidator tooling to the V4 flow prior to migration.\nMigration from the Debt Manager\nEtherFi will migrate the existing Cash book (~$25M in active borrows across 16+ collateral assets) from the Debt Manager to the V4 instance via a phased migration over a short window, organized in cohorts to validate that risk controls (oracle configuration, caps, liquidator tooling, and monitoring) are functioning as intended before the full book transitions. The Cash product surface (User Safes, Credit/Debit modes, settlement) is preserved unchanged above the new credit backend; the migration is designed to be invisible at the cardholder level.\nCommercial Terms\nThe following package has been aligned between EtherFi, the Optimism Foundation, and Aave Labs to strengthen the instance at launch. Final mechanics are subject to this governance process and service-provider review.\n\nRevenue share to Aave DAO: 80-20 EtherFi / Aave on the totality of protocol revenue generated by the instance. The 20% share applies to all instance revenue streams, including: (i) reserve-factor (Liquidity Fee) revenue on instance borrows; (ii) liquidation fees accruing to the protocol; (iii) oracle value recapture proceeds attributable to the instance (e.g., Chainlink SVR), net of any oracle-provider share; and (iv) any other current or future protocol fee streams the instance generates. 20% of each stream flows to the Aave treasury, settled automatically. This split reflects the long-standing, proven relationship between EtherFi and Aave, together with Aave V4 serving as the sole lending and borrowing market for EtherFi Cash.\n\nGHO integration: GHO supported on the instance as both a supply and a borrowable reserve once GHO is deployed on OP Mainnet. Aave deploys a GHO GSM on Optimism.\n\nGHO as a spend currency: at the Aave DAO’s discretion and conditional on sufficient GHO liquidity for the Cash program, GHO may also be added as a spendable/deposit asset within Cash itself, converting a portion of card usage into direct GHO demand.\n\nAssets at launch: EtherFi brings up to $175M in assets to the instance at launch, with a clear path to grow significantly from there.\n\nExclusivity: EtherFi Cash will exclusively use Aave V4 lending markets as its DeFi lending protocol.\n\nLaunch capitalization (EtherFi & Optimism Foundation funded):\n\n$20M supplied from the Optimism Foundation Treasury into the instance.\n\n$1.2M joint incentive package, directed toward deposits and/or borrows across any asset.\n\n$5M strategic GHO position, taken via the GHO GSM, shared by the Optimism Foundation and EtherFi, held for 6 months, after which continuation is at each party’s discretion.\n\nTaken together, the three parties contribute in distinct capacities: Aave provides the V4 codebase license, deployment, and GHO infrastructure; the Optimism Foundation and EtherFi jointly provide the launch capital, incentives, and initial asset base; and EtherFi alone operates the instance end to end with revenue flow back to the Aave DAO via the agreed reserve-factor share.\nUseful Links\n\nTemp Check discussion: governance.aave.com thread\n\nTemp Check Snapshot: snapshot.org proposal\n\nEtherFi Cash collateral & borrowing documentation: help.ether.fi\n\nEtherFi: ether.fi\n\nNext Steps\n\nGather community feedback;\n\nEscalate the proposal to the ARFC Snapshot stage.\n\nIf the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal, targeting a July 2026 deployment to meet the Cash product handoff from the current Debt Manager.\n\nDisclaimer\nThis proposal is submitted by EtherFi as the operator of EtherFi Cash and the proposer of the instance. This material contains forward looking statements regarding design, functionality, and performance; actual results may differ materially from those expressed or implied. The commercial terms reflect agreements with Aave Labs and the Optimism Foundation; all terms and parameters are subject to this governance process and service-provider review. EtherFi is not compensated by any third party for submitting this proposal.\nCopyright\nCopyright and related rights waived via CC0.\n\n 2\n\n read \n\n 7\n min\n\n 8 days later\n\n post by ether.fi on Jul 23\n\n ether.fi\n\n [ARFC Addendum] EtherFi Cash Aave V4 Instance Formatted Risk Parameters\nAuthor: Ether.Fi\nDate: 2026-07-23\nRelated: [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\nSummary\nDelegates correctly flagged that the Risk Parameters table in the ARFC was expressed in Aave V3 terms (LTV / Liquidation Threshold / Liquidation Bonus). This addendum restates the launch parameters in Aave V4’s native format. The design intent is unchanged: mirror the current Cash Debt Manager configuration as closely as V4 mechanics permit.\nV3 → V4 Mapping\n\nV4 replaces the V3 LTV / Liquidation Threshold pair with a single Collateral Factor per reserve. Collateral Factors are set to the prior Liquidation Thresholds, preserving the liquidation boundary for the migrated book. Origination limits continue to be enforced at the Cash application layer (User Safes), as they are today.\n\nThe prior fixed Liquidation Bonus carries over as each reserve’s Max Liquidation Bonus.\n\nLiquidation Fee (the protocol’s share of the realized bonus, new in V4) is set to a flat 10% across all reserves.\n\nLaunch Parameters - Cash Spoke\nAsset\nCollateral Factor | Max Liquidation Bonus | Liquidation Fee\nUSDC\n95% | 1% | 10%\nUSDT\n95% | 1% | 10%\nEURC\n95% | 1% | 10%\nfrxUSD\n95% | 1% | 10%\nweETH\n75% | 3.5% | 10%\nwETH\n75% | 3.5% | 10%\neBTC\n72% | 5% | 10%\neUSD\n90% | 2% | 10%\nETHFI / sETHFI\n30% | 5% | 10%\nOP\n30% | 5% | 10%\nwHYPE\n65% | 4% | 10%\nbeHYPE\n60% | 5% | 10%\nLiquidETH\n70% | 5% | 10%\nLiquidBTC\n70% | 5% | 10%\nLiquidUSD\n80% | 2% | 10%\nLiquidReserve\n80% | 2% | 10%\nLiquidEUR\n80% | 2% | 10%\nLiquidRWA\n80% | 2% | 10%\nGHO parameters will be set by Nonce Capital upon GHO’s deployment on OP Mainnet, following the recommendations from the Aave DAO Service Providers.\nRemaining Configuration\nAll remaining V4 configuration - Spoke liquidation config (targetHealthFactor, liquidationBonusFactor, healthFactorForMaxBonus), interest rate models, Liquidity Fee values, Add/Draw Caps, and collateral risk settings, will be released at the AIP stage in final structuring with Nonce Capital as independent risk admin.\nNext Steps\nThis table supersedes the V3-formatted Risk Parameters table in the original ARFC. The proposal otherwise proceeds as outlined: community feedback, ARFC Snapshot, then AIP targeting a July 2026 deployment.\nDisclaimer\nThis addendum is submitted by EtherFi as the operator of EtherFi Cash. All parameters remain subject to this governance process and review by Nonce Capital.\nCopyright\nCopyright and related rights waived via CC0.\n\n post by Abel189 on Jul 26\n\n Abel189\n\n Thank you for the proposal.\nI think this is an interesting evolution of the Aave ecosystem, as it introduces a business model where the DAO benefits from protocol adoption without directly operating or managing the instance.\nSince this is also a commercial partnership with a revenue-sharing agreement and a defined initial term, I believe it would be valuable to include a structured performance review before the end of that term. In addition to technical metrics, governance could evaluate indicators such as revenue generated for the DAO, instance growth, GHO adoption, operational reliability, and whether the partnership is meeting its original objectives.\nHaving predefined review criteria would provide a transparent basis for any future decision regarding renewal, expansion, or adjustments to similar whitelabel deployments.\n\n post by MconnectDAO on Jul 26\n\n MconnectDAO\n\n ether.fi\n\n Thank you for the detailed ARFC and the V4 risk parameter addendum.\nI see clear upside in the whitelabel V4 instance and the 80/20 revenue share, especially as a way for the DAO to benefit from protocol adoption without directly operating the market. At the same time, some risks deserve explicit governance handling:\nReputational and strategic risk for the DAO from a single, branded card product using an Aave-powered backend.\nVery high collateral factors on stable and vault receipts (up to 95%) combined with complex collateral types, which makes oracle configuration and liquidation behaviour critical for retail users.\nLimited on-chain accountability for the independent risk admin, and the need for transparent performance and risk reporting over the 2-year license term.\nI’d support moving this forward conditioned on: (i) a clearly specified, on-chain or documented performance review before license renewal (covering revenue, GHO adoption, operational reliability, and risk events), and (ii) minimum disclosure standards for Nonce Capital and EtherFi on stress tests, oracle choices, liquidation outcomes, and incident reporting. I believe this would strengthen the DAO’s governance posture while still enabling the proposed commercial partnership.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 6\n\n 1.2k\n\n Jul 9\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d","tokens":5408,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261882827,"hash":"629eaf736630cc341871be82ef7892ea8d0866be"}
{"url":"https://ethereum.org/wallets/find-wallet/tokenpocket/","domain":"ethereum.org","title":"TokenPocket | ⁦ethereum.org⁩","text":"FinanceHardwareNFTsTokenPocketMobile · Browser · HardwareEnglish, Arabic, Bangla, Danish, German, Spanish, Persian, French, Hindi, Hungarian, Indonesian, Japanese, Korean, Malay, Portuguese, Russian, Thai, Turkish, Vietnamese, Chinese, Chinese (Taiwan), UrduSwap fee: not disclosed (TPT-holder discounts)Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityPersonal ownershipOpen sourcePrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationTokenPocket info updated on 11/6/2024Similar walletsimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableOneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%BurnerHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish Device: $19/card, Swap fee: not disclosedBitget walletFinanceNFTsMobile · BrowserEnglish · Chinese Swap fee: variableFrameDeveloperFinanceNFTsDesktop · BrowserEnglish","tokens":337,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261893323,"hash":"ccc7177769391a4f160074fa780b3100954e0f06"}
{"url":"https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380/1","domain":"ethresear.ch","title":"How obfuscation can help Ethereum - Cryptography - Ethereum Research","text":"How obfuscation can help Ethereum \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n read \n\n 5\n min\n\n May 2020\n\n 1 / 12\n\n May 2020\n\n Nov 2024\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n Obfuscation is in many ways the ultimate cryptographic primitive. Obfuscation allows you to turn a program P𝑃 into an “obfuscated program” P'𝑃′ such that (i) P'𝑃′ is equivalent to P𝑃, ie. P'(x) = P(x)𝑃′(𝑥) =𝑃(𝑥) for all x𝑥, and (ii) P'𝑃′ reveals nothing about the “inner workings” of P𝑃. For example, if P𝑃 does some computation that involves some secret key, P'𝑃′ should not reveal that key.\nObfuscation is not yet available; candidate constructions exist, but they all depend on cryptographic assumptions that cryptographers are not happy with and some candidates have already been broken. However, recent research suggests that we are very close to secure obfuscation being possible, even if inefficient.\nThe usual way to formalize the privacy property is that if there are two programs P𝑃 and Q𝑄 that implement the same functionality (ie. P(x) = Q(x)𝑃(𝑥) =𝑄(𝑥) for all x𝑥) but maybe with different algorithms, then given obfuscate(P)𝑜𝑏𝑓𝑢𝑠𝑐𝑎𝑡𝑒(𝑃) and obfuscate(Q)𝑜𝑏𝑓𝑢𝑠𝑐𝑎𝑡𝑒(𝑄) you should not be able to tell which came from which (to see how this leads to secrecy of internal keys, consider a function that uses a key k𝑘 to sign a message out of the set [1....n][1....𝑛]; this could be implemented either by actually including k𝑘 and signing a message that passes a range check, or by simply precomputing and listing all n𝑛 signatures; the formal property implies that you can’t extract k𝑘 from the first program, because the second program does not even contain k𝑘).\nObfuscation is considered to be so powerful because it immediately implies almost any other cryptographic primitive. For example:\n\nPublic key encryption: let enc𝑒𝑛𝑐/dec𝑑𝑒𝑐 be a symmetric encryption scheme (which can be implemented easily using just hashes): the secret key is k𝑘, the public key is an obfuscated program of enc(k, x)𝑒𝑛𝑐(𝑘,𝑥)\n\nSignatures: the signing key is k𝑘, the verification key is an obfuscated program that accepts M𝑀 and sig𝑠𝑖𝑔 and verifies that sig = hash(M, k)𝑠𝑖𝑔 =ℎ𝑎𝑠ℎ(𝑀,𝑘)\n\nFully homomorphic encryption: let enc𝑒𝑛𝑐/dec𝑑𝑒𝑐 be a symmetric encryption scheme. The secret key is k𝑘, the evaluation key is enc(k, dec(k, x1) + dec(k, x2))𝑒𝑛𝑐(𝑘,𝑑𝑒𝑐(𝑘,𝑥1) +𝑑𝑒𝑐(𝑘,𝑥2)) and enc(k, dec(k, x1) * dec(k, x2))𝑒𝑛𝑐(𝑘,𝑑𝑒𝑐(𝑘,𝑥1) ∗𝑑𝑒𝑐(𝑘,𝑥2))\n\nZero knowledge proofs: an obfuscated program is published that accepts x𝑥 as input and publishes sign(k, x)𝑠𝑖𝑔𝑛(𝑘,𝑥) only if P(x) = 1𝑃(𝑥) =1 for some P𝑃\n\nMore generally, obfuscation is viewed as a potential technology for creating general-purpose privacy-preserving smart contracts. This post will both go into this potential and other applications of obfuscation to blockchains.\nSmart contracts\nCurrently, the best available techniques for adding privacy to smart contracts use zero knowledge proofs, eg. AZTEC and Zexe. However, these techniques have an important limitation: they require the data in the contract to be broken up into “domains” where each domain is visible to a user and requires that user’s active involvement to modify. For a currency system, this is acceptable: your balance is yours, and you need your permission to spend money anyway. You can send someone else money by creating encrypted receipts that they can claim. But for many applications this does not work; for example, something like Uniswap contains a very important core state object which is not owned by anyone. An auction could not be conducted fully privately; there needs to be someone to run the calculation to determine who wins, and they need to see the bid amounts to compute the winning bid.\nObfuscation allows us to get around this limitation, getting much closer to “perfect privacy”. However, there is still a limitation remaining. One can naively assume obfuscation lets you create contracts of the form “only if event X happens, then release data Y”. However, outside observers can create a private fork of the blockchain, include and censor arbitrary transactions in this private fork (including copying over some but not all transactions from the main chain), and see the outputs of the contract in this private fork.\nTo give a particular example, key revocation for data vaults cannot work: if at some time in the past, a key k_1𝑘1 could have released data D𝐷, but now that key was switched in the smart contract to k_2𝑘2, then an attacker with k_1𝑘1 could still locally rewind the chain to before the time of the switch, and send the transaction on this local chain where k_1𝑘1 still suffices to release D𝐷 and see the result.\nObfuscating an auction is a particular example of this: even if the auction is obfuscated, you can determine others’ bids by locally pretending to bid against them with every possible value, and seeing under what circumstances you win.\nOne can partially get around this, by requiring the obfuscated program to verify that an instruction was confirmed by the consensus, but this is not robust against failures of the blockchain (51% attacks or more than 1/3 going offline). Hence, it’s a lower security level than the full blockchain. Another way to get around this is by having the obfuscated program check a PoW instance based on the inputs; this limits the amount of information an attacker can extract by making executions of the program more expensive.\nWith this restriction, however, more privacy with obfuscation is certainly possible. Auctions, voting schemes (including in DAOs), and much more are potential targets.\nOther benefits\n\nZKPs with extremely cheap verification: this is basically the scheme mentioned above. Generate an obfuscated program which performs some pre-specified computation f𝑓 on (x, y)(𝑥,𝑦) (x is the public input, y is the private input), and signs (x, f(x))(𝑥,𝑓(𝑥)) with an internal key k𝑘. Verification is done by verifying the signature with the public key corresponding to k𝑘. This is incredibly cheap because verifying a proof is just verifying a signature. Additionally, if the signature scheme used is BLS, verification becomes very easy to aggregate.\n\nOne trusted setup to rule them all: generating obfuscated programs will likely require a trusted setup. However, we can make a single obfuscated program that can generate all future trusted setups for all future protocols, without needing any further trust. This is done as follows. Create a program which contains a secret key k𝑘, and takes as input a program P𝑃. The program executes P(h(P, k))𝑃(ℎ(𝑃,𝑘)) (ie. it generates a subkey h(P, k)ℎ(𝑃,𝑘) specific to that program), and publishes the output and signs it with k𝑘. Any future trusted setup can be done trustlessly by taking the program P𝑃 that computes the trusted setup and putting it into this trusted setup executor as an input.\n\nBetter accumulators: for example, given some data D𝐷, one can generate in O(|D|)𝑂(|𝐷|) time a set of elliptic curve point pairs (P, k*P)(𝑃,𝑘 ∗𝑃) where P = hash(i, D[i])𝑃 =ℎ𝑎𝑠ℎ(𝑖,𝐷[𝑖]) and k𝑘 is an internal secret key (K = k*G𝐾 =𝑘 ∗𝐺 is a public verification key). This allows verifying any of these point pairs (P1, P2)(𝑃1,𝑃2) by doing a pairing check e(P1, K) = e(P2, G)𝑒(𝑃1,𝐾) =𝑒(𝑃2,𝐺) (this is the same technique as in older ZK-SNARK protocols). Particularly, notice that a single pairing check also suffices to verify any subset of the points. Even better constructions are likely possible.\n\n When do we need cryptography in blockchain space?\n\n Key Management for Autonomous AI Agents with Crypto Wallets\n\n 5\n\n 4\n\n read \n\n 5\n min\n\n 8 months later\n\n post by haael on Dec 25, 2020\n\n haael\n\n I am working on practical obfuscation algorithm, based on FAPKC https://github.com/haael/white-box-fapkc\n\n post by haael on Dec 25, 2020\n\n haael\n\n One thing I hope will be possible when we have obfuscation are trustless decentralized oracles. The obfuscated program could check for some fact outside a blockchain, and insert the result into the blockchain.\nAlso, a blockchain could have side-effects in real life and decide them based on the consensus. Imagine the blockchain revealing some secret only when certain conditions are met.\nFor a very concrete example, a program could perform financial transactions through Open Banking API. This would allow implementing a truly decentralized exchange. Historically, exchanges were the most vunerable part of the crypto industry, and also they generate most of the cost. Replacing them with trustless setup would be a huge improvement.\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\nI think this is impossible to solve for generic programs.\nIf you have a program that outputs y = x^2𝑦 =𝑥2, then anyone will be able to deduce the algorithm by simply trying different values of x𝑥 and observing y𝑦.\nYou probably mean that x𝑥 and y𝑦 are encrypted in some way and operations are performed on encrypted values?\nOr the program should be complex/random enough so simply deducing the algorithm is impossible?\n\n post by haael on Dec 25, 2020\n\n haael\n\nYou are not able to learn anything about the program, except what you can learn from inputs and outputs anyway.\nFormally:\nPolynomial black-box attacker is someone who is able to run polynomially many instances of the program and deduce something about its structure.\nExponential black-box attacker is someone who is able to run exponentially many instances of the program. Exponential attacker is stronger than polynomial one.\nNow a program is properly obfuscated if looking at the (obfuscated) source gives you only the power of a polynomial black-box attacker.\nThere are programs that can not be white-box obfuscated no matter what, so white-box obfuscation is not possible for every program. However, a simple banking-like system should be good, with only addition, comparison and multiplication with finite precision.\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\n I see …\nSo you are not able to differentiate from the set of circuits that produce the same outputs having the inputs.\nIt is essentially a random oracle in the subspace of all circuits of say size less than N𝑁, that produce the given outputs having the inputs.\nSimilar to hash-to-curve for elliptic curves, but here you are essentially hashing into the subspace of circuits\n\n post by haael on Dec 25, 2020\n\n haael\n\n Yes. Here what you are thinking is indistinguishability obfuscation.\nWhen you have 2 circuits calculating the same function and you treat them with indistinguishability obfuscation, you will not be able to determine which circuit was the source of any particular obfuscated representation. In layman terms, iO removes all metadata.\nA stronger notion is “inversion obfuscation”, when you present a circuit obfuscated in such a way, so it is impossible to calculate its inverse. An interesting example of a real-life inversion obfuscation is the Chinese “evil transform” of geographical coordinates (duckduckgo). When you have invO, you can upgrade any symmetric cipher to a public cipher.\nAnd the strongest notion is white-box obfuscation, which gives you the guarantee that when you present the obfuscated circuit, the attacker can only deduce from it as much as he could deduce from running the function on a remote machine and collecting the outputs. WB can upgrade any symmetric cipher to a homomorphic cipher. White-box obfuscation gives you a so-called virtual black box property, as if the function was run in a black box the attacker can’t see into.\nNothing is proven yet, but the majority consensus is that iO is possible for any circuit, but invO and WB are impossible in general. That means there are certain “traitor functions” that can’t be white-boxed no matter what. Still, many useful programs should be possible, like a banking system with addition, comparison and finite precision multiplication, or even the AES algorithm.\nI hope it will be possible to make an oracke that starts an SSL session to a bank with Open Banking API, extract information and put it into a blockchain. This will let us make a truly decentralized exchange.\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\nInteresting … What about circuits that are inverse of themselves?\nThere has to be some additional requirement on the circuits for this to work ?) Correct ?)\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\nCan you provide a little longer description how this Oracle would work?\n\n post by haael on Dec 25, 2020\n\n haael\n\nInversion obfuscation would effectively hide that fact.\n\nMy goal is to make a decentralized exchange. Two parties agree to exchange coins at a certain price. Alice has coins, Bob has fiat money, and he’s using an Open Banking API enabled bank.\nAlice prepares a white-box obfuscated program that holds a private token address inside. A public token address is presented to Alice. The program is configured with Alice’s bank account number and fiat price. Alice sends the program to Bob.\nBob first checks if the public address holds enough tokens. If it does, Bob makes a bank transfer to Alice. Then he runs the program. The program connects through SSL to the bank’s API endpoint. Bob possibly needs to authorize the request. The program checks Bob’s recent transfer history. If it finds the right transfer (Alice’s account, the right fiat amount), it will reveal the private key and Bob can claim the tokens.\nAssumption is that the bank doesn’t lie through their OB API and that they allow use of such programs, because banks have the ability to ban certain apps from using OB API.\nOne problem to solve is to allow Alice to claim the tokens back if Bob doesn’t pay in time. Perhaps the program could reveal the private key after some time passes (i.e. 2 hours), using a blockchain as a trusted clock.\n\n 2 years later\n\n post by yadavkaris on Jan 13, 2023\n\n yadavkaris\n\n I found all these interesting and want your guidance regarding smart contract obfuscation. It will be my pleasure if you can help me in this area of research.\n\n 2 years later\n\n post by enricobottazzi on Nov 20, 2024\n\n enricobottazzi\n\n haael\n\nFor a very concrete example, a program could perform financial transactions through Open Banking API. This would allow implementing a truly decentralized exchange. Historically, exchanges were the most vunerable part of the crypto industry, and also they generate most of the cost. Replacing them with trustless setup would be a huge improvement.\n\nCan you elaborate more on the setup of this application?\nEDIT: I see you already gave an explanation to that\n\n Powered by Discourse","tokens":3677,"squid":"ink-research","role":"Deep Scholar","at":1791261897751,"hash":"917542ae351706d9850a9874d9b29197ca6224a8"}
{"url":"https://governance.aave.com/t/temp-check-deploy-a-dedicated-aave-v4-whitelabel-instance-fully-managed-by-etherfi-on-op-mainnet-to-power-ether-fi-cash/25267","domain":"governance.aave.com","title":"[TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash - Governance / General - Aave","text":"[TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 4\n min\n\n Jul 1\n\n 1 / 7\n\n Jul 1\n\n Jul 9\n\n post by ether.fi on Jul 1\n\n ether.fi\n\n Author: Ether.Fi\nDate: July 1, 2026\n\nSummary\nEtherFi requests that a dedicated, EtherFi operated Aave V4 hub on OP Mainnet is deployed to serve as the credit backend for EtherFi Cash, our Visa card product used by tens of thousands of cardholders. This instance would replace the bespoke borrow/lend market (“Debt Manager”) that powers Cash today.\nThe instance is isolated and whitelisted: EtherFi operates it end to end - configuration, risk parameters, liquidity, and growth, while Aave provides the V4 deployment and operating license and earns a share of the revenue it generates. Because the instance is ring-fenced and EtherFi run, Aave carries the upside without taking on the market’s day-to-day risk.\nThe proposal arrives with a substantial commercial package contributed by EtherFi and the Optimism Foundation, summarized in the Commercial Terms section, including a 20% revenue share to the Aave DAO, GHO integration into EtherFi Cash, an Aave-deployed GHO GSM on OP Mainnet, full migration of the EtherFi Debt Manager, up to $175M in assets at launch, and product exclusivity to Aave V4.\nMotivation\nEtherFi Cash today. Cash lets cardholders spend against yield-bearing collateral at the point of sale: they borrow a stablecoin to settle a Visa transaction while preserving their underlying asset exposure. It runs in production on OP Mainnet on a custom, non-pooled borrow/lend market with roughly $25M in active borrows across 16+ collateral assets and a high-frequency, low-ticket, well-distributed borrow profile. We are targeting roughly $500M in assets on the instance by the end of 2026.\nWhy migrate to Aave V4. Maintaining a bespoke lending engine is increasingly operationally taxing. Migrating to a dedicated Aave V4 instance lets EtherFi inherit audited, battle-tested infrastructure and governance machinery while preserving the Cash product surface (User Safes, Credit/Debit modes, settlement) above it.\nWhy this is a fit for Aave.\n\nPure-upside revenue. Aave shares in the borrow revenue of a live consumer product without committing pool liquidity or balance sheet to it. At our end-2026 target scale, the instance is projected to generate an estimated $5-6M in annual revenue, 20% of which accrues directly to the Aave DAO and compounds as the Cash book grows.\n\nDirect GHO adoption. GHO becomes a supply/borrow reserve on the instance as soon as GHO is deployed on Optimism, with an Aave-deployed GSM strengthening GHO’s peg and liquidity on OP Mainnet.\n\nGHO as a spend currency. Beyond being a listed reserve, GHO could, at the Aave DAO discretion, be enabled as a deposit/spend asset in Cash, subject to sufficient GHO liquidity to support the Cash program as expected, turning card volume into organic GHO demand.\n\nReal-world spend footprint. Aave extends into consumer card settlement, anchored by a product with tens of thousands of active cardholders.\n\nNet new on-chain activity on OP Mainnet, with exclusivity to Aave V4 for the Cash product.\n\nAave Labs has expressed support for deploying the instance and providing the operating license. This Temp Check initiates the governance process to ratify that direction and to confirm community sentiment ahead of an ARFC.\nSpecification\nThis Temp Check is intentionally high-level; detailed parameters and the technical specification will be finalized at the ARFC stage with service-provider input.\nArchitecture. A dedicated Aave V4 hub on OP Mainnet. One of V4’s first Layer 2 targets, with spokes depending on the final lending architecture. The instance is whitelisted and isolated from Aave’s shared liquidity and other markets. EtherFi operates the instance end to end and is responsible for collateral listing, risk parameters, oracles, and ongoing risk management. Aave provides the V4 codebase under license for 2 years initial term, but is not responsible for its assets, configuration, or risk.\nOperating model. EtherFi acts as operator and will authorize an independent risk admin for the instance, with authority over:\n\nCollateral listing and de-listing\n\nOracle selection (Chainlink, RedStone, or otherwise) and configuration\n\nLTV, liquidation threshold, and liquidation bonus per asset\n\nInterest rate models, supporting both utilization-curve and fixed-rate reserves\n\nSupply and borrow caps, and pause states\n\nEtherFi and the independent risk admin will handle, as appropriate, items such as configuration, liquidity sourcing, and market growth in full.\nAave’s role. Aave Labs supports EtherFi in the deployment of the V4 instance on OP Mainnet and provides the license to run the whitelisted version, and deploys a GHO GSM on OP Mainnet to support GHO stability and peg.\nCollateral at launch. Mirror the existing Cash collateral set, with streamlined additions over time via the admin role:\n\nETH-likes: weETH, wETH\n\nBTC-likes: eBTC\n\nStables: USDC, USDT, EURC, frxUSD, GHO\n\nEtherFi platform, Optimism & HYPE: ETHFI / sETHFI, eUSD, OP, beHYPE, wHYPE\n\nLiquid vault receipts: LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve\n\nBorrow reserves. USDC and GHO, added as both a supply and a borrowable asset.\nLiquidations. Aave V4’s standard partial liquidation behavior; EtherFi adapts its liquidator tooling to the V4 flow.\nCommercial Terms\nThe following package has been aligned in principle between EtherFi, the Optimism Foundation, and Aave Labs to strengthen the instance at launch. Final mechanics are subject to this governance process and service-provider review.\n\nRevenue share to Aave DAO: 80–20 EtherFi / Aave on instance reserve-factor revenue. 20% to the Aave treasury, settled automatically. This split reflects the long-standing, proven relationship between EtherFi and Aave, together with Aave V4 serving as the sole lending and borrowing market for EtherFi Cash.\n\nGHO integration: GHO supported on the instance as both a supply and a borrowable reserve once GHO is deployed on OP Mainnet. Aave deploys a GHO GSM on Optimism.\n\nGHO as a spend currency: at the Aave DAO’s discretion and conditional on sufficient GHO liquidity for the Cash program, GHO may also be added as a spendable/deposit asset within Cash itself, converting a portion of card usage into direct GHO demand.\n\nAssets at launch: EtherFi brings up to $175M in assets to the instance at launch, with a clear path to grow significantly from there.\n\nExclusivity: EtherFi Cash will exclusively use Aave V4 lending markets as DeFi Lending Protocol.\n\nLaunch capitalization (EtherFi & Optimism Foundation funded):\n\n$20M supplied from the Optimism Foundation Treasury into the instance.\n\n$1.2M joint incentive package, directed toward deposits and/or borrows across any asset.\n\n$5M strategic GHO position, taken via the GHO GSM, shared by the Optimism Foundation and EtherFi, held for 6 months, after which continuation is at each party’s discretion.\n\nTaken together, Aave contributes the deployment, license, and GHO infrastructure; EtherFi and the Optimism Foundation contribute the launch capital, incentives, asset base and ongoing operation, with revenue flowing back to the Aave DAO.\nDisclaimer\nThis proposal is submitted by EtherFi as the operator of EtherFi Cash and the proposer of the instance. The commercial terms reflect agreements in principle with Aave Labs and Optimism Foundation; all terms and parameters are subject to this governance process, ARFC refinement, and service-provider review. EtherFi is not compensated by any third party for submitting this proposal.\nNext Steps\n\nGather community feedback for a minimum of 5 days.\n\nEscalate to a TEMP CHECK Snapshot vote.\n\nOn a successful Snapshot, proceed to an ARFC with finalized parameters and risk/finance service-provider input, targeting a July 2026 deployment to meet the Cash product handoff from the current Debt Manager.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n 2\n\n read \n\n 4\n min\n\n post by axieaur on Jul 2\n\n axieaur\n\n unsure of the specifics around deal terms but fully support aave tech powering the etherfi stack. welcome to aave governance, etherfi!\n\n post by MconnectDAO on Jul 2\n\n MconnectDAO\n\n “Reading this proposal, the key question isn’t who deploys infra, what the revenue split is, or how many assets might come at launch. The real unresolved issue is: when economic value is captured by an off‑chain branded product, but legal and governance risk can seep back to on‑chain tokenholders, who actually owns Aave?\nToday, the 80/20 revenue split, exclusivity, and ‘no balance sheet risk’ framing can look comforting. But in any future consumer‑protection or regulatory event, how exactly will courts, media, and regulators see Aave here as a neutral infra provider, or as a commercial partner in a credit product marketed to tens of thousands of cardholders?\nAave’s recent governance history already surfaced deep fault lines around brand, interface, and value capture. This deal risks compounding those tensions without clearly answering three basics:\nfinance.\nWho bears explicit legal and regulatory downside EtherFi’s legal entity, Aave DAO, or both?\netherfi.\nUnder which clearly defined conditions can tokenholders renegotiate or exit this partnership, and what binding obligations does the off‑chain party have in that scenario?\nIf GHO’s peg, treasury, or risk profile is stressed by this isolated instance, how do the commercial terms flex back in favor of the protocol or is optionality one‑way?\ngovernance.\nUntil we see crisp, public answers and enforceable mechanisms on these three points, calling this arrangement ‘pure upside with no risk’ feels more like marketing than risk governance.\nIf Web3 is serious about being a new financial architecture, we need to stop pretending that protocol brands and governance tokenholders are partners only when upside is shared, but magically become ‘just infra’ when downside shows up. That’s not decentralization; that’s selective responsibility.”\n\n post by axieaur on Jul 3\n\n axieaur\n\nagree with these points\n\n post by Gepetto on Jul 3\n\n Gepetto\n\n Building on MconnectDAO’s questions around legal responsibility and exit mechanisms, I think the economic case also needs more precision before the ARFC stage.\nThe proposal estimates $5–6M in annual instance revenue and allocates 20% of reserve-factor revenue to the Aave DAO. If these figures refer to the same revenue base, this would imply approximately $1–1.2M annually for the DAO at the targeted scale. Could the proposer provide the assumptions behind this estimate, including average borrows, utilization, interest rates, reserve factors and the expected growth timeline?\nIt would also be useful to clarify which deployment, audit, GHO GSM, monitoring and ongoing service-provider costs will be borne by EtherFi, Aave Labs or the DAO. Governance should assess the net contribution to the DAO rather than the gross revenue share alone.\nThere is also a framework question. The canonical framework defines a whitelabel instance as one using existing Aave liquidity, while this deployment is isolated and funded and operated by EtherFi. The framework also contemplated token consideration for both friendly forks and whitelabel instances. Which category is being applied here, and why is there no ETHFI consideration or explicit justification for deviating from the baseline?\nI am directionally supportive of progressing to ARFC, but the commercial case should not be considered finalized until these economic questions and the legal and risk questions raised above are addressed.\nRevenue to the DAO is valuable, but it should not be conflated with direct value accrual to AAVE holders.\n\n post by AaveLabs on Jul 7\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The TEMP to deploy a Dedicated Aave V4 Whitelabel instance has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here\n\n post by Abel189 on Jul 9\n\n Abel189\n\n I support the overall direction of this proposal. Leveraging Aave V4 as the lending infrastructure behind EtherFi Cash creates an opportunity to extend Aave into consumer payment use cases while generating sustainable revenue for the DAO and increasing potential demand for GHO.\nI particularly appreciate the proposed isolation of the instance from Aave’s shared liquidity, allowing EtherFi to manage day-to-day operations and market risk while the DAO benefits from licensing, protocol adoption, and revenue sharing. This separation of responsibilities helps preserve the integrity of the core Aave markets.\nAs the proposal progresses to the ARFC stage, I believe it will be important to carefully review the governance framework, operational responsibilities, risk oversight, and long-term alignment of incentives between EtherFi and the Aave DAO. Ensuring transparency and clearly defined accountability will be essential for the success of this partnership.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 3\n\n 536\n\n Jul 26\n\n [ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n Governance\n\n 4\n\n 549\n\n Jul 2025\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28","tokens":3444,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261900910,"hash":"95407aae5c6282c4e20f9aedd8e12fc534a7116d"}
{"url":"https://ethereum.org/wallets/","domain":"ethereum.org","title":"Ethereum wallets: Buy, Store and Send crypto | ⁦ethereum.org⁩","text":"What's an Ethereum wallet?Ethereum wallets are applications that give you control over your account. Just like your physical wallet, it contains everything you need to prove your identity and handle your assets. Your wallet allows you to sign in to applications, read your balance, send transactions and verify your identity.Wallets are what most people use to handle their digital assets and identity.How to create an Ethereum accountHow to use a walletYour wallet is a tool for interacting with your Ethereum account. That means you can swap wallet providers at any time. Many wallets also let you manage several Ethereum accounts from one application.Wallet providers don't have custody of your funds. They just provide you a window to see your assets on Ethereum and tools to easily manage them.An app for managing your fundsYour wallet shows your balances, transaction history and gives you a way to send/receive funds. Some wallets may offer more.Your Ethereum accountYour wallet is your window into your Ethereum account – your balance, transaction history and more. But you can swap wallet providers at any time.Your login for Ethereum appsYour wallet lets you connect to applications using your Ethereum account. It's like a login you can use across many apps.Wallets, accounts, keys and addressesIt's worth understanding the differences between some key terms.An Ethereum account is a pair of keys. is used to create the address you can share freely, and the you need to keep secret because it's used to sign things. Together, these keys let you hold assets and make transactions.An Ethereum account has an address, like an inbox has an email address. This is used to identify your digital assets.A wallet is a tool that lets you interact with your account, using your keys. It allows you to view your account balance, send transactions, and more.Most wallet products will let you generate an Ethereum account. So you don't need one before you download a wallet.Types of walletsThere are a few ways to interface and interact with your account:Physical hardware wallets are devices that let you keep your crypto offline – very secureMobile applications that make your funds accessible from anywhereBrowser wallets are web applications that let you interact with your account directly in the browserBrowser extension wallets are extensions you download that let you interact with your account and applications through the browserDesktop applications if you prefer to manage your funds via macOS, Windows or LinuxHow to use a walletInteractive tutorialHow to stay safeFinancial freedom and the ability to access and use funds anywhere comes with responsibility – there’s no customer support in crypto. You are responsible for keeping your keys safe and secure.Take responsibility for your own fundsCentralized exchanges will link your wallet to a username and password that you can recover in a traditional way. Just remember you’re trusting that exchange with custody over your funds. If the exchange has financial trouble, your funds would be at risk.Write down your Wallets will often give you a seed phrase that you must write down somewhere safe. This is the only way you’ll be able to recover your wallet.Here's an example:there aeroplane curve vent formation doge possible product distinct under spirit lampDon’t store it on a computer. Write it down and keep it safe.Bookmark your walletIf you use a web wallet, bookmark the site to protect yourself against phishing scams.Triple check everythingRemember transactions can’t be reversed and wallets can’t be easily recovered so take precautions and always be careful.More tips on staying safeFrom the communityProtecting yourself and your funds (opens in a new tab)MyCryptoThe keys to keeping your crypto safe (opens in a new tab)Coinbase blogExplore EthereumTest your Ethereum knowledgeWalletsQuestion number 1:The most secure type of wallet is:","tokens":978,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261903440,"hash":"aa386781f76bf4d4763140dbb3ae8e356e66a255"}
{"url":"https://ethresear.ch/t/how-obfuscation-can-help-ethereum/7380/12","domain":"ethresear.ch","title":"How obfuscation can help Ethereum - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n read \n\n 5\n min\n\n May 2020\n\n 12 / 12\n\n Nov 2024\n\n Nov 2024\n\n post by vbuterin on May 9, 2020\n\n vbuterin\n\n Obfuscation is in many ways the ultimate cryptographic primitive. Obfuscation allows you to turn a program P𝑃 into an “obfuscated program” P'𝑃′ such that (i) P'𝑃′ is equivalent to P𝑃, ie. P'(x) = P(x)𝑃′(𝑥) =𝑃(𝑥) for all x𝑥, and (ii) P'𝑃′ reveals nothing about the “inner workings” of P𝑃. For example, if P𝑃 does some computation that involves some secret key, P'𝑃′ should not reveal that key.\nObfuscation is not yet available; candidate constructions exist, but they all depend on cryptographic assumptions that cryptographers are not happy with and some candidates have already been broken. However, recent research suggests that we are very close to secure obfuscation being possible, even if inefficient.\nThe usual way to formalize the privacy property is that if there are two programs P𝑃 and Q𝑄 that implement the same functionality (ie. P(x) = Q(x)𝑃(𝑥) =𝑄(𝑥) for all x𝑥) but maybe with different algorithms, then given obfuscate(P)𝑜𝑏𝑓𝑢𝑠𝑐𝑎𝑡𝑒(𝑃) and obfuscate(Q)𝑜𝑏𝑓𝑢𝑠𝑐𝑎𝑡𝑒(𝑄) you should not be able to tell which came from which (to see how this leads to secrecy of internal keys, consider a function that uses a key k𝑘 to sign a message out of the set [1....n][1....𝑛]; this could be implemented either by actually including k𝑘 and signing a message that passes a range check, or by simply precomputing and listing all n𝑛 signatures; the formal property implies that you can’t extract k𝑘 from the first program, because the second program does not even contain k𝑘).\nObfuscation is considered to be so powerful because it immediately implies almost any other cryptographic primitive. For example:\n\nPublic key encryption: let enc𝑒𝑛𝑐/dec𝑑𝑒𝑐 be a symmetric encryption scheme (which can be implemented easily using just hashes): the secret key is k𝑘, the public key is an obfuscated program of enc(k, x)𝑒𝑛𝑐(𝑘,𝑥)\n\nSignatures: the signing key is k𝑘, the verification key is an obfuscated program that accepts M𝑀 and sig𝑠𝑖𝑔 and verifies that sig = hash(M, k)𝑠𝑖𝑔 =ℎ𝑎𝑠ℎ(𝑀,𝑘)\n\nFully homomorphic encryption: let enc𝑒𝑛𝑐/dec𝑑𝑒𝑐 be a symmetric encryption scheme. The secret key is k𝑘, the evaluation key is enc(k, dec(k, x1) + dec(k, x2))𝑒𝑛𝑐(𝑘,𝑑𝑒𝑐(𝑘,𝑥1) +𝑑𝑒𝑐(𝑘,𝑥2)) and enc(k, dec(k, x1) * dec(k, x2))𝑒𝑛𝑐(𝑘,𝑑𝑒𝑐(𝑘,𝑥1) ∗𝑑𝑒𝑐(𝑘,𝑥2))\n\nZero knowledge proofs: an obfuscated program is published that accepts x𝑥 as input and publishes sign(k, x)𝑠𝑖𝑔𝑛(𝑘,𝑥) only if P(x) = 1𝑃(𝑥) =1 for some P𝑃\n\nMore generally, obfuscation is viewed as a potential technology for creating general-purpose privacy-preserving smart contracts. This post will both go into this potential and other applications of obfuscation to blockchains.\nSmart contracts\nCurrently, the best available techniques for adding privacy to smart contracts use zero knowledge proofs, eg. AZTEC and Zexe. However, these techniques have an important limitation: they require the data in the contract to be broken up into “domains” where each domain is visible to a user and requires that user’s active involvement to modify. For a currency system, this is acceptable: your balance is yours, and you need your permission to spend money anyway. You can send someone else money by creating encrypted receipts that they can claim. But for many applications this does not work; for example, something like Uniswap contains a very important core state object which is not owned by anyone. An auction could not be conducted fully privately; there needs to be someone to run the calculation to determine who wins, and they need to see the bid amounts to compute the winning bid.\nObfuscation allows us to get around this limitation, getting much closer to “perfect privacy”. However, there is still a limitation remaining. One can naively assume obfuscation lets you create contracts of the form “only if event X happens, then release data Y”. However, outside observers can create a private fork of the blockchain, include and censor arbitrary transactions in this private fork (including copying over some but not all transactions from the main chain), and see the outputs of the contract in this private fork.\nTo give a particular example, key revocation for data vaults cannot work: if at some time in the past, a key k_1𝑘1 could have released data D𝐷, but now that key was switched in the smart contract to k_2𝑘2, then an attacker with k_1𝑘1 could still locally rewind the chain to before the time of the switch, and send the transaction on this local chain where k_1𝑘1 still suffices to release D𝐷 and see the result.\nObfuscating an auction is a particular example of this: even if the auction is obfuscated, you can determine others’ bids by locally pretending to bid against them with every possible value, and seeing under what circumstances you win.\nOne can partially get around this, by requiring the obfuscated program to verify that an instruction was confirmed by the consensus, but this is not robust against failures of the blockchain (51% attacks or more than 1/3 going offline). Hence, it’s a lower security level than the full blockchain. Another way to get around this is by having the obfuscated program check a PoW instance based on the inputs; this limits the amount of information an attacker can extract by making executions of the program more expensive.\nWith this restriction, however, more privacy with obfuscation is certainly possible. Auctions, voting schemes (including in DAOs), and much more are potential targets.\nOther benefits\n\nZKPs with extremely cheap verification: this is basically the scheme mentioned above. Generate an obfuscated program which performs some pre-specified computation f𝑓 on (x, y)(𝑥,𝑦) (x is the public input, y is the private input), and signs (x, f(x))(𝑥,𝑓(𝑥)) with an internal key k𝑘. Verification is done by verifying the signature with the public key corresponding to k𝑘. This is incredibly cheap because verifying a proof is just verifying a signature. Additionally, if the signature scheme used is BLS, verification becomes very easy to aggregate.\n\nOne trusted setup to rule them all: generating obfuscated programs will likely require a trusted setup. However, we can make a single obfuscated program that can generate all future trusted setups for all future protocols, without needing any further trust. This is done as follows. Create a program which contains a secret key k𝑘, and takes as input a program P𝑃. The program executes P(h(P, k))𝑃(ℎ(𝑃,𝑘)) (ie. it generates a subkey h(P, k)ℎ(𝑃,𝑘) specific to that program), and publishes the output and signs it with k𝑘. Any future trusted setup can be done trustlessly by taking the program P𝑃 that computes the trusted setup and putting it into this trusted setup executor as an input.\n\nBetter accumulators: for example, given some data D𝐷, one can generate in O(|D|)𝑂(|𝐷|) time a set of elliptic curve point pairs (P, k*P)(𝑃,𝑘 ∗𝑃) where P = hash(i, D[i])𝑃 =ℎ𝑎𝑠ℎ(𝑖,𝐷[𝑖]) and k𝑘 is an internal secret key (K = k*G𝐾 =𝑘 ∗𝐺 is a public verification key). This allows verifying any of these point pairs (P1, P2)(𝑃1,𝑃2) by doing a pairing check e(P1, K) = e(P2, G)𝑒(𝑃1,𝐾) =𝑒(𝑃2,𝐺) (this is the same technique as in older ZK-SNARK protocols). Particularly, notice that a single pairing check also suffices to verify any subset of the points. Even better constructions are likely possible.\n\n When do we need cryptography in blockchain space?\n\n Key Management for Autonomous AI Agents with Crypto Wallets\n\n 5\n\n 4\n\n read \n\n 5\n min\n\n 8 months later\n\n post by haael on Dec 25, 2020\n\n haael\n\n I am working on practical obfuscation algorithm, based on FAPKC https://github.com/haael/white-box-fapkc\n\n post by haael on Dec 25, 2020\n\n haael\n\n One thing I hope will be possible when we have obfuscation are trustless decentralized oracles. The obfuscated program could check for some fact outside a blockchain, and insert the result into the blockchain.\nAlso, a blockchain could have side-effects in real life and decide them based on the consensus. Imagine the blockchain revealing some secret only when certain conditions are met.\nFor a very concrete example, a program could perform financial transactions through Open Banking API. This would allow implementing a truly decentralized exchange. Historically, exchanges were the most vunerable part of the crypto industry, and also they generate most of the cost. Replacing them with trustless setup would be a huge improvement.\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\nI think this is impossible to solve for generic programs.\nIf you have a program that outputs y = x^2𝑦 =𝑥2, then anyone will be able to deduce the algorithm by simply trying different values of x𝑥 and observing y𝑦.\nYou probably mean that x𝑥 and y𝑦 are encrypted in some way and operations are performed on encrypted values?\nOr the program should be complex/random enough so simply deducing the algorithm is impossible?\n\n post by haael on Dec 25, 2020\n\n haael\n\nYou are not able to learn anything about the program, except what you can learn from inputs and outputs anyway.\nFormally:\nPolynomial black-box attacker is someone who is able to run polynomially many instances of the program and deduce something about its structure.\nExponential black-box attacker is someone who is able to run exponentially many instances of the program. Exponential attacker is stronger than polynomial one.\nNow a program is properly obfuscated if looking at the (obfuscated) source gives you only the power of a polynomial black-box attacker.\nThere are programs that can not be white-box obfuscated no matter what, so white-box obfuscation is not possible for every program. However, a simple banking-like system should be good, with only addition, comparison and multiplication with finite precision.\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\n I see …\nSo you are not able to differentiate from the set of circuits that produce the same outputs having the inputs.\nIt is essentially a random oracle in the subspace of all circuits of say size less than N𝑁, that produce the given outputs having the inputs.\nSimilar to hash-to-curve for elliptic curves, but here you are essentially hashing into the subspace of circuits\n\n post by haael on Dec 25, 2020\n\n haael\n\n Yes. Here what you are thinking is indistinguishability obfuscation.\nWhen you have 2 circuits calculating the same function and you treat them with indistinguishability obfuscation, you will not be able to determine which circuit was the source of any particular obfuscated representation. In layman terms, iO removes all metadata.\nA stronger notion is “inversion obfuscation”, when you present a circuit obfuscated in such a way, so it is impossible to calculate its inverse. An interesting example of a real-life inversion obfuscation is the Chinese “evil transform” of geographical coordinates (duckduckgo). When you have invO, you can upgrade any symmetric cipher to a public cipher.\nAnd the strongest notion is white-box obfuscation, which gives you the guarantee that when you present the obfuscated circuit, the attacker can only deduce from it as much as he could deduce from running the function on a remote machine and collecting the outputs. WB can upgrade any symmetric cipher to a homomorphic cipher. White-box obfuscation gives you a so-called virtual black box property, as if the function was run in a black box the attacker can’t see into.\nNothing is proven yet, but the majority consensus is that iO is possible for any circuit, but invO and WB are impossible in general. That means there are certain “traitor functions” that can’t be white-boxed no matter what. Still, many useful programs should be possible, like a banking system with addition, comparison and finite precision multiplication, or even the AES algorithm.\nI hope it will be possible to make an oracke that starts an SSL session to a bank with Open Banking API, extract information and put it into a blockchain. This will let us make a truly decentralized exchange.\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\nInteresting … What about circuits that are inverse of themselves?\nThere has to be some additional requirement on the circuits for this to work ?) Correct ?)\n\n post by kladkogex on Dec 25, 2020\n\n kladkogex\n\nCan you provide a little longer description how this Oracle would work?\n\n post by haael on Dec 25, 2020\n\n haael\n\nInversion obfuscation would effectively hide that fact.\n\nMy goal is to make a decentralized exchange. Two parties agree to exchange coins at a certain price. Alice has coins, Bob has fiat money, and he’s using an Open Banking API enabled bank.\nAlice prepares a white-box obfuscated program that holds a private token address inside. A public token address is presented to Alice. The program is configured with Alice’s bank account number and fiat price. Alice sends the program to Bob.\nBob first checks if the public address holds enough tokens. If it does, Bob makes a bank transfer to Alice. Then he runs the program. The program connects through SSL to the bank’s API endpoint. Bob possibly needs to authorize the request. The program checks Bob’s recent transfer history. If it finds the right transfer (Alice’s account, the right fiat amount), it will reveal the private key and Bob can claim the tokens.\nAssumption is that the bank doesn’t lie through their OB API and that they allow use of such programs, because banks have the ability to ban certain apps from using OB API.\nOne problem to solve is to allow Alice to claim the tokens back if Bob doesn’t pay in time. Perhaps the program could reveal the private key after some time passes (i.e. 2 hours), using a blockchain as a trusted clock.\n\n 2 years later\n\n post by yadavkaris on Jan 13, 2023\n\n yadavkaris\n\n I found all these interesting and want your guidance regarding smart contract obfuscation. It will be my pleasure if you can help me in this area of research.\n\n 2 years later\n\n post by enricobottazzi on Nov 20, 2024\n\n enricobottazzi\n\n haael\n\nFor a very concrete example, a program could perform financial transactions through Open Banking API. This would allow implementing a truly decentralized exchange. Historically, exchanges were the most vunerable part of the crypto industry, and also they generate most of the cost. Replacing them with trustless setup would be a huge improvement.\n\nCan you elaborate more on the setup of this application?\nEDIT: I see you already gave an explanation to that\n\n Powered by Discourse","tokens":3668,"squid":"ink-research","role":"Deep Scholar","at":1791261908214,"hash":"7e4f05d06b8ea5711198f91c66d3a2e049cfe722"}
{"url":"https://ethereum.org/guides/how-to-create-an-ethereum-account/","domain":"ethereum.org","title":"How to \"create\" an Ethereum account | ethereum.org","text":"Edit page (opens in a new tab)Anyone can create an Ethereum account for free. You just need to install a crypto wallet app. Wallets create and manage your Ethereum account. They can send transactions, check your balances and connect you to other apps built on Ethereum.\nWith a wallet you can also log into any token exchange, games, marketplaces instantly. There is no need for individual registration, one account is shared for all apps built on Ethereum.\nStep 1: Choose a wallet\nA wallet is an app that helps you manage your Ethereum account. There are dozens of different wallets to choose from: mobile, desktop, or even browser extensions.\nList of wallets\nIf you are new, you can select the “New to crypto” filter on the \"find a wallet\" page to identify wallets that should include all necessary features suitable for beginners.\n\nThere are also other profile filters to cater to your needs. These are examples of commonly used wallets - you should do your own research before trusting any software.\nStep 2: Download and install your wallet app\nOnce you have decided on a specific wallet, visit their official website or app store, download and install it. All of them should be free.\nStep 3: Open the app and create your Ethereum account\nThe first time you open your new wallet you might be asked to choose between creating a new account or importing an existing one. Click on the new account creation. This is the step during which the wallet software generates your Ethereum account.\nStep 4: Store your recovery phrase\nSome apps will request you to save a secret \"recovery phrase\" (sometimes called a \"seed phrase\" or a \"mnemonic\"). Keeping this phrase safe is extremely important! This is used to generate your Ethereum account and can be used to submit transactions.\nAny person who knows the phrase can take control of all funds. Never share this with anyone. This phrase should contain 12 to 24 randomly generated words (the order of the words matters).\nWallet installed?Learn how to use it.How to use a wallet\nInterested in other guides? Check out our: Step by step guides\nFrequently asked questions\nAre my wallet and my Ethereum account the same?\nNo. The wallet is a management tool that helps you to manage accounts. A single wallet might access several accounts, and a single account can be accessed by multiple wallets. The recovery phrase is used to create accounts and gives permission to a wallet app to manage assets.\nCan I send bitcoin to an Ethereum address, or ether to a Bitcoin address?\nNo, you cannot. Bitcoin and ether exist on two separate networks (i.e., different blockchains), each with their own bookkeeping and address formats. There have been various attempts to bridge the two different networks, of which the most active one is currently Wrapped Bitcoin or WBTC (opens in a new tab). This is not an endorsement, as WBTC is a custodial solution (meaning a single group of people controls certain critical functions) and is provided here for informational purposes only.\nIf I own an ETH address, do I own the same address on other blockchains?\nYou can use the same on all blockchains that use similar underlying software to Ethereum (known as 'EVM-compatible'). This list (opens in a new tab) will show you which blockchains you can use with the same address. Some blockchains, like Bitcoin, implement a completely separate set of network rules and you will need a different address with a different format. If you have a smart contract wallet you should check its product website for more info on which blockchains are supported because usually those have limited but more secure scope.\nIs having my own wallet safer than keeping my funds on an exchange?\nHaving your own wallet means you take responsibility for the security of your assets. There are unfortunately many examples of failed exchanges that lost their customers' money. Owning a wallet (with a recovery phrase) removes the risk associated with trusting some entity to hold your assets. However, you have to secure it on your own and avoid phishing scams, accidentally approving transactions or exposing recovery phrase, interacting with fake websites and other self-custody risks. The risks and benefits are different.\nIf I lose my phone/hardware wallet, do I need to use the same wallet app again to recover the lost funds?\nNo, you can use a different wallet. As long as you have the seed phrase you can enter it into most wallets and they will restore your account. Be careful if you ever need to do this: it is best to make sure you are not connected to the internet when recovering your wallet so that your seed phrase is not accidentally leaked. It is often impossible to recover lost funds without the recovery phrase.","tokens":1180,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261914961,"hash":"ef2689adcf9b09603b3f54ccea9d8bf3507c1cf8"}
{"url":"https://governance.aave.com/t/temp-check-deploy-a-dedicated-aave-v4-whitelabel-instance-fully-managed-by-etherfi-on-op-mainnet-to-power-ether-fi-cash/25267/7","domain":"governance.aave.com","title":"[TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 4\n min\n\n Jul 1\n\n 7 / 7\n\n Jul 8\n\n Jul 9\n\n post by ether.fi on Jul 1\n\n ether.fi\n\n Author: Ether.Fi\nDate: July 1, 2026\n\nSummary\nEtherFi requests that a dedicated, EtherFi operated Aave V4 hub on OP Mainnet is deployed to serve as the credit backend for EtherFi Cash, our Visa card product used by tens of thousands of cardholders. This instance would replace the bespoke borrow/lend market (“Debt Manager”) that powers Cash today.\nThe instance is isolated and whitelisted: EtherFi operates it end to end - configuration, risk parameters, liquidity, and growth, while Aave provides the V4 deployment and operating license and earns a share of the revenue it generates. Because the instance is ring-fenced and EtherFi run, Aave carries the upside without taking on the market’s day-to-day risk.\nThe proposal arrives with a substantial commercial package contributed by EtherFi and the Optimism Foundation, summarized in the Commercial Terms section, including a 20% revenue share to the Aave DAO, GHO integration into EtherFi Cash, an Aave-deployed GHO GSM on OP Mainnet, full migration of the EtherFi Debt Manager, up to $175M in assets at launch, and product exclusivity to Aave V4.\nMotivation\nEtherFi Cash today. Cash lets cardholders spend against yield-bearing collateral at the point of sale: they borrow a stablecoin to settle a Visa transaction while preserving their underlying asset exposure. It runs in production on OP Mainnet on a custom, non-pooled borrow/lend market with roughly $25M in active borrows across 16+ collateral assets and a high-frequency, low-ticket, well-distributed borrow profile. We are targeting roughly $500M in assets on the instance by the end of 2026.\nWhy migrate to Aave V4. Maintaining a bespoke lending engine is increasingly operationally taxing. Migrating to a dedicated Aave V4 instance lets EtherFi inherit audited, battle-tested infrastructure and governance machinery while preserving the Cash product surface (User Safes, Credit/Debit modes, settlement) above it.\nWhy this is a fit for Aave.\n\nPure-upside revenue. Aave shares in the borrow revenue of a live consumer product without committing pool liquidity or balance sheet to it. At our end-2026 target scale, the instance is projected to generate an estimated $5-6M in annual revenue, 20% of which accrues directly to the Aave DAO and compounds as the Cash book grows.\n\nDirect GHO adoption. GHO becomes a supply/borrow reserve on the instance as soon as GHO is deployed on Optimism, with an Aave-deployed GSM strengthening GHO’s peg and liquidity on OP Mainnet.\n\nGHO as a spend currency. Beyond being a listed reserve, GHO could, at the Aave DAO discretion, be enabled as a deposit/spend asset in Cash, subject to sufficient GHO liquidity to support the Cash program as expected, turning card volume into organic GHO demand.\n\nReal-world spend footprint. Aave extends into consumer card settlement, anchored by a product with tens of thousands of active cardholders.\n\nNet new on-chain activity on OP Mainnet, with exclusivity to Aave V4 for the Cash product.\n\nAave Labs has expressed support for deploying the instance and providing the operating license. This Temp Check initiates the governance process to ratify that direction and to confirm community sentiment ahead of an ARFC.\nSpecification\nThis Temp Check is intentionally high-level; detailed parameters and the technical specification will be finalized at the ARFC stage with service-provider input.\nArchitecture. A dedicated Aave V4 hub on OP Mainnet. One of V4’s first Layer 2 targets, with spokes depending on the final lending architecture. The instance is whitelisted and isolated from Aave’s shared liquidity and other markets. EtherFi operates the instance end to end and is responsible for collateral listing, risk parameters, oracles, and ongoing risk management. Aave provides the V4 codebase under license for 2 years initial term, but is not responsible for its assets, configuration, or risk.\nOperating model. EtherFi acts as operator and will authorize an independent risk admin for the instance, with authority over:\n\nCollateral listing and de-listing\n\nOracle selection (Chainlink, RedStone, or otherwise) and configuration\n\nLTV, liquidation threshold, and liquidation bonus per asset\n\nInterest rate models, supporting both utilization-curve and fixed-rate reserves\n\nSupply and borrow caps, and pause states\n\nEtherFi and the independent risk admin will handle, as appropriate, items such as configuration, liquidity sourcing, and market growth in full.\nAave’s role. Aave Labs supports EtherFi in the deployment of the V4 instance on OP Mainnet and provides the license to run the whitelisted version, and deploys a GHO GSM on OP Mainnet to support GHO stability and peg.\nCollateral at launch. Mirror the existing Cash collateral set, with streamlined additions over time via the admin role:\n\nETH-likes: weETH, wETH\n\nBTC-likes: eBTC\n\nStables: USDC, USDT, EURC, frxUSD, GHO\n\nEtherFi platform, Optimism & HYPE: ETHFI / sETHFI, eUSD, OP, beHYPE, wHYPE\n\nLiquid vault receipts: LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve\n\nBorrow reserves. USDC and GHO, added as both a supply and a borrowable asset.\nLiquidations. Aave V4’s standard partial liquidation behavior; EtherFi adapts its liquidator tooling to the V4 flow.\nCommercial Terms\nThe following package has been aligned in principle between EtherFi, the Optimism Foundation, and Aave Labs to strengthen the instance at launch. Final mechanics are subject to this governance process and service-provider review.\n\nRevenue share to Aave DAO: 80–20 EtherFi / Aave on instance reserve-factor revenue. 20% to the Aave treasury, settled automatically. This split reflects the long-standing, proven relationship between EtherFi and Aave, together with Aave V4 serving as the sole lending and borrowing market for EtherFi Cash.\n\nGHO integration: GHO supported on the instance as both a supply and a borrowable reserve once GHO is deployed on OP Mainnet. Aave deploys a GHO GSM on Optimism.\n\nGHO as a spend currency: at the Aave DAO’s discretion and conditional on sufficient GHO liquidity for the Cash program, GHO may also be added as a spendable/deposit asset within Cash itself, converting a portion of card usage into direct GHO demand.\n\nAssets at launch: EtherFi brings up to $175M in assets to the instance at launch, with a clear path to grow significantly from there.\n\nExclusivity: EtherFi Cash will exclusively use Aave V4 lending markets as DeFi Lending Protocol.\n\nLaunch capitalization (EtherFi & Optimism Foundation funded):\n\n$20M supplied from the Optimism Foundation Treasury into the instance.\n\n$1.2M joint incentive package, directed toward deposits and/or borrows across any asset.\n\n$5M strategic GHO position, taken via the GHO GSM, shared by the Optimism Foundation and EtherFi, held for 6 months, after which continuation is at each party’s discretion.\n\nTaken together, Aave contributes the deployment, license, and GHO infrastructure; EtherFi and the Optimism Foundation contribute the launch capital, incentives, asset base and ongoing operation, with revenue flowing back to the Aave DAO.\nDisclaimer\nThis proposal is submitted by EtherFi as the operator of EtherFi Cash and the proposer of the instance. The commercial terms reflect agreements in principle with Aave Labs and Optimism Foundation; all terms and parameters are subject to this governance process, ARFC refinement, and service-provider review. EtherFi is not compensated by any third party for submitting this proposal.\nNext Steps\n\nGather community feedback for a minimum of 5 days.\n\nEscalate to a TEMP CHECK Snapshot vote.\n\nOn a successful Snapshot, proceed to an ARFC with finalized parameters and risk/finance service-provider input, targeting a July 2026 deployment to meet the Cash product handoff from the current Debt Manager.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n 2\n\n read \n\n 4\n min\n\n post by axieaur on Jul 2\n\n axieaur\n\n unsure of the specifics around deal terms but fully support aave tech powering the etherfi stack. welcome to aave governance, etherfi!\n\n post by MconnectDAO on Jul 2\n\n MconnectDAO\n\n “Reading this proposal, the key question isn’t who deploys infra, what the revenue split is, or how many assets might come at launch. The real unresolved issue is: when economic value is captured by an off‑chain branded product, but legal and governance risk can seep back to on‑chain tokenholders, who actually owns Aave?\nToday, the 80/20 revenue split, exclusivity, and ‘no balance sheet risk’ framing can look comforting. But in any future consumer‑protection or regulatory event, how exactly will courts, media, and regulators see Aave here as a neutral infra provider, or as a commercial partner in a credit product marketed to tens of thousands of cardholders?\nAave’s recent governance history already surfaced deep fault lines around brand, interface, and value capture. This deal risks compounding those tensions without clearly answering three basics:\nfinance.\nWho bears explicit legal and regulatory downside EtherFi’s legal entity, Aave DAO, or both?\netherfi.\nUnder which clearly defined conditions can tokenholders renegotiate or exit this partnership, and what binding obligations does the off‑chain party have in that scenario?\nIf GHO’s peg, treasury, or risk profile is stressed by this isolated instance, how do the commercial terms flex back in favor of the protocol or is optionality one‑way?\ngovernance.\nUntil we see crisp, public answers and enforceable mechanisms on these three points, calling this arrangement ‘pure upside with no risk’ feels more like marketing than risk governance.\nIf Web3 is serious about being a new financial architecture, we need to stop pretending that protocol brands and governance tokenholders are partners only when upside is shared, but magically become ‘just infra’ when downside shows up. That’s not decentralization; that’s selective responsibility.”\n\n post by axieaur on Jul 3\n\n axieaur\n\nagree with these points\n\n post by Gepetto on Jul 3\n\n Gepetto\n\n Building on MconnectDAO’s questions around legal responsibility and exit mechanisms, I think the economic case also needs more precision before the ARFC stage.\nThe proposal estimates $5–6M in annual instance revenue and allocates 20% of reserve-factor revenue to the Aave DAO. If these figures refer to the same revenue base, this would imply approximately $1–1.2M annually for the DAO at the targeted scale. Could the proposer provide the assumptions behind this estimate, including average borrows, utilization, interest rates, reserve factors and the expected growth timeline?\nIt would also be useful to clarify which deployment, audit, GHO GSM, monitoring and ongoing service-provider costs will be borne by EtherFi, Aave Labs or the DAO. Governance should assess the net contribution to the DAO rather than the gross revenue share alone.\nThere is also a framework question. The canonical framework defines a whitelabel instance as one using existing Aave liquidity, while this deployment is isolated and funded and operated by EtherFi. The framework also contemplated token consideration for both friendly forks and whitelabel instances. Which category is being applied here, and why is there no ETHFI consideration or explicit justification for deviating from the baseline?\nI am directionally supportive of progressing to ARFC, but the commercial case should not be considered finalized until these economic questions and the legal and risk questions raised above are addressed.\nRevenue to the DAO is valuable, but it should not be conflated with direct value accrual to AAVE holders.\n\n post by AaveLabs on Jul 7\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The TEMP to deploy a Dedicated Aave V4 Whitelabel instance has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here\n\n post by Abel189 on Jul 9\n\n Abel189\n\n I support the overall direction of this proposal. Leveraging Aave V4 as the lending infrastructure behind EtherFi Cash creates an opportunity to extend Aave into consumer payment use cases while generating sustainable revenue for the DAO and increasing potential demand for GHO.\nI particularly appreciate the proposed isolation of the instance from Aave’s shared liquidity, allowing EtherFi to manage day-to-day operations and market risk while the DAO benefits from licensing, protocol adoption, and revenue sharing. This separation of responsibilities helps preserve the integrity of the core Aave markets.\nAs the proposal progresses to the ARFC stage, I believe it will be important to carefully review the governance framework, operational responsibilities, risk oversight, and long-term alignment of incentives between EtherFi and the Aave DAO. Ensuring transparency and clearly defined accountability will be essential for the success of this partnership.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 3\n\n 536\n\n Jul 26\n\n [ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n Governance\n\n 4\n\n 549\n\n Jul 2025\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28","tokens":3412,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791261925319,"hash":"2546225ed21c94eee30423eb5083792a39629727"}
{"url":"https://ethereum.org/wallets/find-wallet/personas/finance/","domain":"ethereum.org","title":"DeFi wallets for Ethereum | ⁦ethereum.org⁩","text":"DeFi wallets for EthereumGet the most out of decentralized finance. These wallets are geared toward frequent DeFi use: swapping tokens, staking ETH, and connecting to the financial apps you rely on.Browse wallets by user typeNew to crypto 4 availableFirst time user looking for beginner wallet.Developer 10 availableWallets that help develop and test dapps.Finance 28 availableWallets focusing on frequent usage of DeFi apps.Hardware 5 availablePassive token holding with hardware wallets.NFTs 20 availableWallets with focus on NFT support.Browse all walletsWallets found: 28 / 48TahoFinanceNFTsBrowserEnglish Swap fee: 0.5%PhantomFinanceMobile · BrowserEnglish · Spanish Swap fee: 0.85%imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%Ready WalletFinanceNFTsMobile · BrowserEnglish Swap fee: 0.5%FrameDeveloperFinanceNFTsDesktop · BrowserEnglish ShapeShiftFinanceMobile · BrowserEnglish · Spanish Swap/bridge fee: 0.5% (free under $1,000, FOX-holder discounts)ExodusFinanceDesktop · Mobile · BrowserEnglish Swap fee: from 0.5%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerAmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%SafeFinanceNFTsMobileEnglish Swap fee: 0.05% – 0.7%, Staking fee: 20% of rewardsCoin WalletFinanceDesktop · MobileEnglish · Indonesian Swap fee: 0%BlockWalletDeveloperFinanceBrowserEnglish Swap/bridge fee: 0.5%Coin98 Super WalletFinanceNFTsMobile · BrowserEnglish · Vietnamese Swap fee: 0.5% (0.1% for stablecoins)Coinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%Cake WalletDeveloperFinanceDesktop · MobileEnglish · Spanish Swap fee: variableEdge WalletFinanceDesktop · MobileEnglish · Spanish Swap fee: 0.5% – 2%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%Bitget walletFinanceNFTsMobile · BrowserEnglish · Chinese Swap fee: variableRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableTokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the provider1inch WalletFinanceNFTsMobileEnglish · Russian Swap fee: variableTrezorFinanceHardwareDesktop · Mobile · HardwareEnglish · Spanish Device: $59 – $129, Swap fee: variableimTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)NuFiFinanceNFTsBrowserEnglish Swap fee: 0.75%MetaMaskFinanceNFTsMobile · BrowserEnglish · Amharic Swap/bridge fee: 0.875%, Buy/sell fee: 1%How we evaluate walletsEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.Read the full listing criteria and removal policyCurated by the ethereum.org editorial team.Most recent listing update: June 16, 2026To be listed, a wallet must meet the following requirements:Security-tested through audit, an internal security team, or open-source code review.Been live for at least six months, or built by a team with an established track record.Actively maintained, with support available for users.Provides honest, accurate listing information. Products that falsify details are removed.Has a named point of contact so we can verify information when it changes.Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.Listings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.Filter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.Wallets listed on this page are not official endorsements, and are provided for informational purposes only.Their descriptions have been provided by the wallet projects themselves.","tokens":1169,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261925485,"hash":"3122d23177dc8c8e36bd817b76336efca5ba90ac"}
{"url":"https://ethresear.ch/t/the-road-to-post-quantum-ethereum-transaction-is-paved-with-account-abstraction-aa/21783","domain":"ethresear.ch","title":"The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA) - Cryptography - Ethereum Research","text":"The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA) \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2025\n\n 1 / 23\n\n Feb 2025\n\n Mar 19\n\n post by asanso on Feb 18, 2025\n\n asanso\n\n Thanks to Nicolas Bacca, Vitalik Buterin, Nicolas Consigny, Renaud Dubois, Simon Masson, Dror Tirosh,Yoav Weiss and Zhenfei Zhang for fruitfull discussions.\nThis is Part 3 of our series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we discussed the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In Part 2, we took a deep dive into Falcon, analyzing its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework. In this installment, we build on that foundation by exploring how account abstraction (AA) can be leveraged to integrate Falcon into Ethereum. We’ll examine the architectural changes required, the benefits of using AA for post-quantum security, and the potential challenges in making this approach viable.\nDid you say ERC-4337?\nWhen discussing account abstraction (AA), the natural conclusion is to think about ERC-4337, as it is currently the most prominent and widely adopted approach to enabling AA on Ethereum. ERC-4337 provides a way to implement smart contract wallets without requiring changes to the Ethereum protocol, making it a strong candidate for integrating post-quantum signature schemes like Falcon.\nIn particular, we can take inspiration from the SimpleWallet smart contract or from smart contracts leveraging RIP-7212 to explore how Falcon can be efficiently integrated within the ERC-4337 framework.\nSimpleWallet\nThe SimpleWallet is a smart contract-based wallet designed to implement Account Abstraction on Ethereum. Instead of using traditional private keys for transactions, a SimpleWallet smart contract allows for greater flexibility by enabling custom validation logic and potentially supporting new cryptographic signature schemes like Falcon. For instance, in the context of post-quantum Ethereum, the SimpleWallet could be adapted to work with Falcon signatures, allowing for more flexible, secure, and future-proof transaction processing. This smart contract approach would allow Ethereum accounts to evolve and support post-quantum cryptography without requiring changes to the underlying Ethereum protocol.\nFalconSimpleWallet\nA FalconSimpleWallet would be a modified version of SimpleWallet that replaces ECDSA with Falcon-based cryptography. Unlike ECDSA, “plain” Falcon does not support public key recovery from a signature—meaning that ecrecover cannot be used. Instead, a Falcon-based wallet must verify signatures directly against a stored public key.\nHowever, as Renaud Dubois pointed out, Section 3.12 of the Falcon paper introduces a key recovery model. This method allows for public key recovery, but it comes at the cost of doubling the signature size. While this could provide a potential workaround for ecrecover-like functionality, the increased key size presents additional considerations for on-chain efficiency.\nThis difference means that Falcon-based wallets need an explicit mapping of Ethereum addresses to public keys, requiring a different approach to authorization. Rather than relying on ecrecover to derive the signer’s identity, a FalconSimpleWallet would explicitly store and reference public keys for verification.\nAdditionally, integrating Falcon into the Ethereum Virtual Machine (EVM) requires deviating from the NIST standard implementation. Falcon relies on SHAKE for hashing, but since SHAKE is not natively supported in the EVM, we need to use a more EVM-friendly hash function, such as Keccak. This ensures compatibility and efficiency when verifying Falcon signatures on-chain.\nKudos to Zhenfei Zhang, who contributed a Keccak256-based PRNG implementation for Falcon, further bridging the gap between Falcon and Ethereum’s cryptographic stack.\nShow Me the Demo!\nYou can find the demo in FalconSimpleWallet on GitHub. This project showcases a wallet that replaces traditional ECDSA with Falcon-based verification, tailored for Ethereum’s evolving security needs.\nA special shout-out to ZKNox—their exceptional work on the Falcon Solidity implementation has dramatically cut verification costs from 24M gas down to 3.6M gas. This impressive gas optimization brings post-quantum security a step closer to practical deployment on the blockchain. Kudos to ZKNox for their remarkable contribution!\nThe elephant in the room\nWhile we have successfully transitioned the smart wallet signature to be post-quantum (PQ) resistant, there remains a critical issue: the bundler transaction still relies on the traditional ECDSA signature scheme. This means that even though individual user operations (UserOps) within the account abstraction framework can use Falcon, the final transaction submitted to the Ethereum mempool is still signed with ECDSA by the bundler.\nTo fully remove ECDSA from the transaction pipeline, changes at the L1 protocol level will likely be required, specifically via EIP-7701/RIP-7560.\n(Bonus part) Batching\nAs mentioned in the “Gnarly” section of Part 2, there has been ongoing research into efficiently aggregating Falcon signatures, including work involving Labrador. If this approach proves efficient, we could leverage EIP-7766 (Signature Aggregation for ERC-4337) to optimize Falcon signature aggregation within the AA framework—similar to how BLS signatures are aggregated in this VerificationGateway contract.\nNo soup (EIP-7702) for you!\nAs discussed in the context of EIP-7702, the proposal might allow turning an account into an ERC-4337 account and adding Falcon support, but it still retains the ECDSA key. The problem with EIP-7702 is that the ECDSA key remains valid within this framework, which introduces a potential security risk. Even if the account starts using Falcon after setting the code, the presence of the ECDSA key leaves the account exposed. An attacker could potentially recover and misuse the ECDSA key to compromise the account.\nThis is why EIP-7702 is problematic from a quantum-resilience perspective: it enshrines ECDSA, which is vulnerable to quantum attacks. Instead, the focus should be on native Account Abstraction (AA), which removes any reliance on ECDSA and offers a more robust, quantum-resistant approach through smart contract wallets like the SimpleWallet. solution above.\nConclusion\nIn this installment, we’ve explored how Account Abstraction (AA) can be leveraged to integrate Falcon, a post-quantum signature scheme, into Ethereum. By transitioning to a Falcon-based smart wallet signature, we can ensure a future-proof, quantum-resistant approach to Ethereum transactions.\nWhile the adoption of Falcon-based wallets within the AA framework is a promising step, the ongoing reliance on ECDSA signatures for bundler transactions still presents a challenge. Overcoming this requires protocol-level changes, likely through EIP-7701 or RIP-7560, to fully eliminate ECDSA from the transaction pipeline.\nAdditionally, research into signature aggregation for Falcon, as discussed in the “Gnarly” section of Part 2, presents an opportunity to further optimize Falcon’s integration in the Ethereum network, particularly with the potential adoption of EIP-7766 for ERC-4337.\nHowever, since we are still using a smart contract for Falcon, which currently costs about 3.7M gas per transaction, the next logical step is to move toward a RIP for Falcon, which would aim to optimize its integration and bring gas costs down for practical, on-chain use.\nIn conclusion, while we’ve made significant progress in integrating post-quantum security into Ethereum, there are still key challenges to address at both the bundler and protocol levels to ensure a complete transition to a quantum-resistant future.\n\n Migration Strategies for EOAs under the Quantum Threat: Breakages, and Open Questions\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n What if post-quantum Ethereum doesn’t need signatures at all?\n\n 8\n\n 5\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n post by rdubois-crypto on Feb 24, 2025\n\n rdubois-crypto\n\n Looking at key recovery, if the public key is transmitted along the verification (while it is implicit in recover), then the difference between recovery and original scheme is in favor of the recovery version, because a public key (incompressible polynomial, 896 bytes) is replaced by the s2 field of falcon (which can be compressed to 630 bytes) and a hash (32 bytes).\nOf course for the current experimentations, we don’t have the implicit, but we could imagine to have this public key hashed in the smart account storage, verified during deployment.\n\n 7 months later\n\n post by shemnon on Sep 11, 2025\n\n shemnon\n\n There are two EIPs proposing a precompile for the current NIST Falcon variant\nhttps://ethereum-magicians.org/t/eip-7619-falcon-512-precompiled-generic-signature-verifier/18569\nhttps://ethereum-magicians.org/t/eip-7592-falcon-signature-verification-pre-compile/18053\nOf the two, EIP-7619 appears to be closest to what AA would need and the most versatile, as it accepts the entire message rather than a pre hashed message (note that Falcon salts it’s messages prior to signing with a signature specific salt). It is the EIP I am attempting to revive for a precompile.\n\n 23 days later\n\n post by Nomadu27 on Oct 4, 2025\n\n Nomadu27\n\n Hi @asanso, thank you for this excellent series exploring post-quantum Ethereum and Falcon integration via account abstraction.\nI’m working on a hybrid RNG architecture designed to bridge physical entropy sources, chaotic amplification, and cryptographic extraction (SHAKE/Keccak) compatible with Ethereum’s keccak-based commitments and intended for seeding PQ signatures like Falcon or as randomness for ERC-4337 workflows.\nI’ve published a sanitized specification + demo repo (no private parameters) hybrid-chaos-quantum-rng . I’d be happy to share the full implementation under NDA or collaborate on integrating with your FalconSimpleWallet designs.\nLooking forward to feedback and discussion.\nNomadu27\n\n 2 months later\n\n post by vbuterin on Nov 24, 2025\n\n vbuterin\n\nBundler ECDSA Envelope\n\nThis is exactly why we need something like EIP-7701, ie. AA as a protocol-level feature. We need to de-enshrine ECDSA from the protocol fully.\n\nsequencing, ordering\n\nBLS-based RANDAO can easily be replaced with hash-based, in fact hash-based was the original proposal. It’s just somewhat less efficient because you need to update the RANDAO value every time there’s a proposal (but that’s fine).\n\nL2 attestation\n\nWe need off-chain proof aggregation to make STARKs truly viable for this. See here for how it can be implemented.\n\nMEV relay protocols\n\nI don’t see why this can’t be quantum-resistant? eg. ePBS can easily be made quantum-resistant\nSo all of these problems have solutions, but yes they do require building out a few important components.\n\n post by seresistvanandras on Nov 24, 2025\n\n seresistvanandras\n\nBLS-based RANDAO can easily be replaced with hash-based\n\nThe original hash-based RANDAO (outlined here by V) has exactly the same biasability problems (last-revealer manipulation attacks (aka selfish mixing), and forking attacks) just like the current BLS-based construction. Swapping out the cryptographic component to a post-quantum secure one does not automatically solve the randomness beacon’s biasability issues. If this is a concern (I’d argue it is quite a concern), then we also need to redesign the beacon protocol itself.\n\n post by codebyMoh on Nov 26, 2025\n\n codebyMoh\n\n One aspect that I don’t think is being fully explored in this thread is the state-transition validity problem under heterogeneous signature environments once Ethereum begins introducing PQC-capable account types (whether via EIP-7701 or deeper AA enshrinement).\nEven if we de-enshrine ECDSA and migrate to a PQC-first AA environment, there’s still a missing analysis for the following:\n1. Hybrid-Epoch Safety Under Mixed Signature Regimes\nDuring the transition period, block proposers will need to simultaneously validate:\n\nlegacy ECDSA-based transactions\n\nPQC-based AA wallets (SPHINCS+, Dilithium, Picnic, SLH-DSA, etc.)\n\naggregation commitments for PQC-based attestations\n\nsignature-object equivalence proofs to maintain deterministic state root construction\n\nThis exposes a nontrivial state-transition race condition.\nSpecifically:\n\nEthereum has not yet defined a canonical mechanism for multi-scheme signature admit rules in the transition epoch, which means a quantum adversary could selectively target only the legacy paths and still cause proposer-level reorg leverage.\n\nEven with ePBS + PQC upgrades, this remains unaddressed.\n2. PQC-Friendly State Witness Design Is Not Defined\nPQC signatures (hash-based or lattice-based) have:\n\nlarger public keys\n\nlarger signatures\n\nhigher verification cost variability\n\nnon-unique signature structures\n\nBut Ethereum’s state witness format (Verkle transition) is not yet adapted for:\n\nPQ key-object encoding\n\ndeterministic format for PQ signature lists in bundled AA ops\n\nstate witness compaction under PQC objects (since SPHINCS+ can be 8–20 KB per signature)\n\nMeaning:\n\nUnder current designs, PQC transactions will inflate witness proofs in a way that breaks the expected Verkle node size budget, unless the protocol introduces a specialized PQC-witness leaf type.\n\nProbably we should also look at all rely on the recoverable-signature property.\nEven Falcon’s Section 3.12 “recoverable mode” requires either:\n\ntransmitting s₂ + signature hash + deterministic PRNG seed\n\nor precommitting the public key hash in contract storage\n\nwhich cannot be lifted into consensus without native format standardization.\n\n post by seresistvanandras on Nov 26, 2025\n\n seresistvanandras\n\n Yeah, you’re right.\nThere’s a huge literature on unbiasable randomness beacons (VDFs, threshold redesign is part of that literature as you point out). The question is which one would be suitable for Ethereum’s unique setting with very specific latency and efficiency requirements. This is a wide open research engineering question IMHO. Also part of the unbiasable randomness beacon question is that in which setting we want to solve this problem? Dishonest majority? Honest majority? A recent paper shows that if you want to have an unbiased randomness beacon in the dishonest majority setting then the only way to solve this problem is to use VDFs. See it here. I don’t know much about pq-secure VDFs…\nNot sure how accountability could solve the withholding/selfish mixing manipulation attacks in the current RANDAO design.\n\nOffline validators: There are legitimate reasons why a validator did not publish its block. Conversely, a RANDAO manipulator validator could aways say that it just happened to be offline or it was DoS-ed and that’s the reason it did not publish its block and the corresponding RANDAO randomness contribution. From the outside world, these two scenarios are indistinguishable.\nImpossibility of issuing “manipulation proofs”: Even if you would prove to a smart contract that XYZ did not publish their block, it’s not obvious whether they did it because of manipulating the beacon. Since, the public does not see their hidden, non-published RANDAO contribution(s), the public cannot recompute the beacon state with the hidden RANDAO contribution. See Section 3.4. here, where I explain this better.\n\n post by seresistvanandras on Nov 27, 2025\n\n seresistvanandras\n\n I pretty much agree with everything what you wrote in your last two comments.\nI would frame the two problems (pq-security and beacon unbiasability) as orthogonal problems. Pq-security is a theoretical-cryptographic problem of the constituent cryptographic algorithms (signatures, randomness contributions, commitments, (verifiable) random functions, etc.), while unbiasability is a protocol-level problem that already assumes the above-mentioned pre- or post-quantum secure building blocks.\nPQ-security of the beacon is easy to solve as Vitalik pointed out above by swapping out BLS-signatures as randomness contributions to preimages in a validator-generated hash-chain. This is likely even faster than the pre-quantum BLS-based RANDAO construction!\nUnbiasability is a completely different beast. There are already proposals to try to minimize the biasability of the RANDAO. See, e.g., this great ethresear.ch post.\nWith regards to a lightweight accountability layer. Honestly, I don’t see much value in it.\nPragmatically, one would correct the design of Ethereum’s distributed randomness beacon once and for all. I don’t see much value in incremental patchwork-style approaches on this matter. These are my two arguments to back this up:\n\nDual-signed commitments: the addition of dual-commitments (pre- and post-quantum) do not solve any of the biasability issues (selfish mixing, forking attacks) but make the beacon less space- and time-efficient thanks to the increased cryptographic workload.\n“Proving” beacon manipulation: again, this is not a pq-security issue. As I argued above and also in our paper, forking attacks are provable and evident for the public. While, selfish mixing cannot be made accountable, as there are missing information on-chain, i.e., the missed RANDAO randomness contributions that would allow us recomputing the necessary counterfactual RANDAO states that only the manipulative adversary sees given her hidden randomness contributions. Thus, selfish mixing cannot be made accountable in a publicly verifiable manner (unless all the RANDAO contributions are visible to everyone which is not the case in selfish mixing by definition).\n\n post by seresistvanandras on Nov 27, 2025\n\n seresistvanandras\n\n Sure! Such a lightweight beacon may make sense for L2s, rollups, etc. It’s a free market, right? Everybody is welcome to deploy their own randomness beacon that fits their adversarial model, latency, efficiency, and security requirements.\nBut at the end of the day, mostly for composability and interoperability, I’d assume that even L2s would want to have access to a global, unbiasable randomness beacon on the L1 for certain applications. (Obviously the L1 must have a source of randomness for selecting the block proposers from the validator set in a fair manner. The L1 needs randomness, as there is no deterministic and secure decentralized consensus protocol (even in synchrony) as was shown by Lewis-Pye and Roughgarden. )\n\n post by paulangusbark on Dec 2, 2025\n\n paulangusbark\n\n I wish I had found this thread sooner, would have saved me so much time lol. I wrote a solidity contract that does falcon-1024 verification and I even had a transfer on mainnet; transaction id is 0x22d89bb12e9f50b1c8b890733b5eda50f1be2ebcd8e4c598ba5bdbea73cbd520 (was not optimized for AA gas since it was a quick POC). My original contract used 40m gas but I got it down to just below 10m gas (but it includes signature extraction).\nWhy did you store the public key as an uint256 array and not an uint16 array? The storage costs are dramatically reduced.\nI also went with a keccak variant but mine iterates keccak functions with the userOpHash, a domain, and the salt. I might look to replace what I have with your implementation though, I do know there’s room for improvement on what I’ve done.\nOne thing I did to reduce gas was do the NTT transformation on the public key when they are first loaded instead of everytime a transaction is verified; that might reduce your gas by about half a million.\nI was going to wait until about April before I made my github public but maybe I’ll just do it sooner. It would be nice to compare notes.\n\n post by seresistvanandras on Dec 3, 2025\n\n seresistvanandras\n\n Congrats @paulangusbark! Please both of you, do share those contracts! It’d be nice to standardize in the long run those verification contracts similarly as the community uses somewhat standardized OpenZeppelin contract snippets for many standard tasks. Presumably PQ signature verification will be just as standard as an ERC20 interface.\n\n post by rdubois-crypto on Dec 3, 2025\n\n rdubois-crypto\n\n Congrats,\nIt is great to have other implementations (targeting a different security level).\nWe are very interested by the contracts as well (mainly regarding the core NTT operations optimizations).\nIt might have been unnoticed, falcon512 and Dilithium are available here since a few months.\nFALCON verification takes as input a precomputed NTT representation of the public key as mentionned above. FALCON keys are packed in uint256, dilithium keys are stored in an external contract.\nThe NIST KATS are successfully passed, providing confidence on the core part of the algorithm.\n\nFor both keccak256 based version and fully nist compliant versions are provided, along with signers (and also a hardware signer app for Dilithium44).The 128 bits level of security is picked, as it is the common target for Ethereum.\nGas cost for FALCON512 using keccak256 is 2M, 6.6M for Dilithium.\nThis can be used to experiment starting today, until precompiles are adopted.\nThe EIP-8052 (DRAFT) diverges from previous proposal by\n\nspliting the FALCON computations in two part, allowing a more zk-friendly to be adopted for the hash2Point part of the signature, having in mind the ZK endgame.\ntake as input the NTT representation of the PK\n\nhttps://ethereum-magicians.org/t/eip-8052-precompile-for-falcon-support/25860\nThis separation is not possible for DILITHIUM, so EIP-8051 just stick to the standard.\nhttps://ethereum-magicians.org/t/eip-8051-ml-dsa-verification/25857\n\n post by paulangusbark on Dec 3, 2025\n\n paulangusbark\n\n I’ve created a discord channel with instructions at discord.gg/PUFcQezy\nThe signature is the salt followed by the signature encoded as bytes mod q (I didn’t use the encoder/decoder from the falcon implementation except for loading the public key); so 2068 bytes (no header).\nA domain is set on wallet creation and is immutable; the value is used in the message hashing function. Admittedly, I asked ChatGPT to write me a function using just the 32 byte input and was never able to make anything better; I suspect what I have is loosely based on your code except I added a domain value. I also calculate the point values as I iterate through the last iNTT transformation to reduce the number of loops.\nTo save on gas, I calculate half of the norm with the submitted signature, then convert that memory allotment to the other half of the signature and calculate the second half of the norm. I also used the unchecked feature during the NTT conversions.\nI’ll publish it soon. My repository has other contracts I’m not ready to share but I’ll just weed out the relevant parts into a different repository and make that public.\nIf you are in London, I’ll be at the Ethereum London event at the Encode Club tomorrow.\n\n post by paulangusbark on Dec 4, 2025\n\n paulangusbark\n\n I’ve published it to GitHub - Cointrol-Limited/QuantumAccount: An implementation of an ERC4337 wallet that uses FIPS 206 (falcon-1024) for signature verification\n\n post by paulangusbark on Dec 5, 2025\n\n paulangusbark\n\n To clarify, I’m not formally trained in this space. I’m best described as a hobbyist mathematician.\nAs a slight caveat, I wrote a contract seven years ago that can arguably be used to measure randomness. The address is 0x16FA8DF7F16f9E41B7C5522Cc12a22053A2a776F\nIt assumes a Gaussian relationship with paired dice rolls when compared with their histogram typical spread. I did it on how often seven was rolled but it can easily be applied to rolls less than five, since that probability is arguably equivalent in probability just like rolls greater than nine. And the die doesn’t need six sides.\nTechnically, it cheats on the value of e, but it can be rewritten as a ratio of e and pi. It is a twist on Buffon’s experiment.\n\n post by paulangusbark on Dec 5, 2025\n\n paulangusbark\n\n And to expand upon that. That contract measured the frequency of rolling 7 versus anything else. It has limitations but I had every roll be an event so they could be queried after the fact. There are thousands of rolls there as a initial data set. You can take a sample value and mod 12 it (assuming it’s 2 bytes) and use a second value randomly to verify.\n\n post by rdubois-crypto on Dec 11, 2025\n\n rdubois-crypto\n\n Well for the IPQVerifier, we planned to follow the openZeppelin ERC7913 IVerifier, parameters verification shall be performed internally.\nConcerning the Keccak hashing, a PRNG was designed by Zhenfei (FALCON co-author) during our collaboration with EF. It is roughly a CTR-mode build with keccak as central permutation.\nIf you need SHAKE, it is available in our repo, it has an expensive cost, which will vanish once the EIP is adopted.\n\n 23 days later\n\n post by SirSpudlington on Jan 3\n\n SirSpudlington\n\n I just found this thread so I thought to give my two cents (at least regarding the EL side of things).\nThis is more about cryptographic flexibility than specifics of any particular algorithm.\nThe idea that AA is the future for PQ verification is a good one, but I don’t think it should be purely application only. Protocol support is necessary for supporting blobs, etc. (hence why I authored EIP-7932). A standard protocol-level interface for signatures is the best case forward (which is the sentiment I have gotten from this thread) as both application and protocol can use it.\nRegarding key recovery, most PQ algorithms do not support it. I did have some thoughts about a potential companion EIP for 7932 for a system contract / precompile that holds public keys for addresses (anyone interested can find them here:https://ethereum-magicians.org/t/storage-of-non-recoverable-account-keys-on-chain/27361 - I unfortunately cannot post a link yet).\n\n post by SirSpudlington on Jan 4\n\n SirSpudlington\n\n @pipavlo82 Thank you for your reply, I am glad you agree \n\nI am not the best person to ask when it comes to test vectors, but I do think they would be valuable for benchmarking purposes (and keeping everyone on the same page). With the wiring of PQ algorithms, it really depends on the way the algorithm is exposed. If with a precompile, I’d say the FIPS SHAKE version of the algorithm would be better because pure EVM based performance would not matter as much and it is the widely used standard. However, if EVM constrained then the Keccak-CTR-style PRNG would be better because of its gas efficiency. I like the “keep both versions” approach of EIP-8051/EIP-8052.\n\n Load more posts below","tokens":6671,"squid":"ink-research","role":"Deep Scholar","at":1791261931836,"hash":"7b39ea33c5cf0c512a889fa868298981b6a3e5ee"}
{"url":"https://ethereum.org/wallets/find-wallet/taho/","domain":"ethereum.org","title":"Taho | ⁦ethereum.org⁩","text":"FinanceNFTsTahoBrowserEnglishSwap fee: 0.5%Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportLayer 2SwapsHardware wallet supportENS supportStakingSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedToken importingGas fee customizationRPC importingTaho info updated on 4/21/2023Similar walletsRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%RainbowNew to cryptoFinanceNFTsMobile · BrowserEnglish · Spanish Swap fee: 0.85%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerCoinbase WalletNew to cryptoFinanceNFTsMobile · BrowserEnglish · German Swap fee: 1%1inch WalletFinanceNFTsMobileEnglish · Russian Swap fee: variableTokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)","tokens":272,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261936568,"hash":"1d958d36d11fcd9790ea83b52e9a9aa3074debfa"}
{"url":"https://ethereum.org/wallets/find-wallet/rabby-wallet/","domain":"ethereum.org","title":"Rabby Wallet | ⁦ethereum.org⁩","text":"DeveloperFinanceNFTsRabby WalletDesktop · Mobile · BrowserEnglish, German, Spanish, French, Japanese, Portuguese, Russian, Turkish, ChineseSwap fee: 0.25%Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportLayer 2SwapsHardware wallet supportStakingENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationRabby Wallet info updated on 7/24/2024Similar walletsAmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerZerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerFrameDeveloperFinanceNFTsDesktop · BrowserEnglish OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%","tokens":308,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791261946703,"hash":"c2a1f77829d3ba84dfff7fb2d012e95a5c3c04c6"}
{"url":"https://dev-forum.pyth.network/t/pyth-api-ont-showing-updated-prices/749/1","domain":"dev-forum.pyth.network","title":"Pyth API ont showing updated prices - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth API ont showing updated prices \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Siddharth on Apr 9\n\n Siddharth\n\n I’m seeing pyth api, returning 77.x for SPYM feed, where as market is at 79.x\nhttps://hermes.pyth.network/v2/updates/price/latest?ids[]=0x4dfbf28d72ab41a878afcd4c6d5e9593dca7cf65a0da739cbad9b7414004f82d\n\nThe price feed is for SPLG : SPLG/USD | Pyth Network Insights\n\nThere is also a second price feed called SPYM, but for that no price is being pushed : SPYM/USD | Pyth Network Insights\nCan we please resolve this asap, thank you.\n\nPlease reach out on telegram @siddharth_bhoite . Thank you.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Evolution/Differences API Error\n\n Price Feeds\n\n 1\n\n 474\n\n Jul 2025\n\n Request: 1ms crypto data feed trial and micro‑movement behavior\n\n Price Feeds\n\n 2\n\n 59\n\n Mar 22\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 651\n\n Oct 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Powered by Discourse","tokens":1182,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261956067,"hash":"4e6ceaf5e09d700d416d8a0ac876bf9ddce1a80c"}
{"url":"https://forum.openzeppelin.com/t/understanding-decimals-for-erc20-token-creation/1821/2","domain":"forum.openzeppelin.com","title":"Understanding decimals for ERC20 token creation? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Nov 2019\n\n 2 / 11\n\n Nov 2019\n\n Jun 2022\n\n post by manolingam on Nov 25, 2019\n\n manolingam\n\n Hi people,\nI am experimenting with ERC20 tokens and want to set a supply with 18 decimals. And I couldn’t understand the math behind it. Can someone explain it please?\nFor example, if I wanna create a supply with 10000 Tokens, what is the math behind it?\nShould I do 10000 / (10 ** 18) or 10000 * 10 ** 18? And what value should I pass for the _mint function to create 10000 tokens?\nI know the math is simple but bear with me. I am poor at calculations \nThanks.\n\n ERC20 decimals, specifying a big number\n\n 3\n\n 3\n\n post by abcoathup on Nov 25, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @manolingam,\nPlease see the OpenZeppelin documentation on decimals which should explain the math:\nhttps://docs.openzeppelin.com/contracts/2.x/tokens#a-note-on-decimals\nTLDR: Decimals are for display purposes, calculations are done in the base units for a token. So you need 10000 * 10 ** 18 (token base units) for 10000 tokens.\nSee an example below:\nSimpleToken\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\n\n/**\n * @title SimpleToken\n * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.\n * Note they can later distribute these tokens as they wish using `transfer` and other\n * `ERC20` functions.\n */\ncontract SimpleToken is Context, ERC20, ERC20Detailed {\n\n /**\n * @dev Constructor that gives _msgSender() all of existing tokens.\n */\n constructor () public ERC20Detailed(\"SimpleToken\", \"SIM\", 18) {\n _mint(_msgSender(), 10000 * (10 ** uint256(decimals())));\n }\n}\n\n ERC20Detailed.sol not found in @openzeppelin/contracts/token/ERC20 on GitHub\n\n post by manolingam on Nov 25, 2019\n\n manolingam\n\n Thanks @abcoathup. Yes, I checked the documentation too.\nOkay. If I wanna transfer 100 tokens, then should I call the transfer function with 100 * 10 ** 18?\n\n post by abcoathup on Nov 25, 2019\n\n abcoathup\n\n Great contributor\n\n Yes. All operations in the smart contract use the token base units, so to transfer 100 tokens you transfer 100 * 10 ** 18 token base units.\n\n post by manolingam on Nov 25, 2019\n\n manolingam\n\n Since all operations needs to be multiplied by ten to the power of decimals, should we manually update amount from OpenZeppelin contracts to amount * 10 ** 18 for the functions in ERC20.sol ? or Can I send the transactions using web3.utils.toWei(amount, 'ether') ?\n\n post by abcoathup on Nov 25, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @manolingam,\nWe need to use amounts in token base units when we call ERC20 functions.\nIf we updated the amount used in the contract to be amount * 10 ** 18 it would be the equivalent of having decimals of zero, or using the example of dollars and cents, it would be the equivalent of only using dollars.\nWhilst you should be able to use web3.utils.toWei(amount, 'ether') it is less clear for someone reading your code, so I would suggest not doing that.\n\n 2 years later\n\n post by serdarpinar on Dec 20, 2021\n\n serdarpinar\n\n Hi.. i have same problem..\nmy erc20 contract with 18 decimals. but i transferred to another account and then im seeing 0.0001 ..\nwhat can i do this ? i want , if i buy the 1000 tokens and then i want see 1000 tokens on my metamask.. i hope understand me\n\n post by Amxx on Dec 22, 2021\n\n Amxx\n\n OpenZeppelin Team\n\n @serdarpinar please read the message in the thread. Your answer is already there.\n\n 11 days later\n\n post by DoDzilla on Jan 3, 2022\n\n DoDzilla\n\n serdarpinar\n\n Your ERC20 contract has 18 decimals. If you want to send 1000 tokens then you should multiply 1000 with 10^18 (as described by the @abcoathup 1000 * 10^18). So you should send 1000000000000000000000 (1000 and 18 zeros)\n\n 2 months later\n\n post by BeratOz01 on Mar 7, 2022\n\n BeratOz01\n\n abcoathup\n\n I need to increase allowance like 0.3 busdt. How did I need to do that guys ?\n\n 3 months later\n\n post by PaulRBerg on Jun 12, 2022\n\n PaulRBerg\n\n @BeratOz01 You need a fixed-point math library for that. See this:\nWhat fixed or float point math libraries are available in solidity?\nI recommend using PRBMath - though note that I'm biased since I'm the author of the library.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 588\n\n Jun 2021\n\n ERC-20 total supply unit?\n\n Smart Contracts\n\n 1\n\n 389\n\n Dec 2021\n\n What does it look like to override the decimals function?\n\n Contracts\n\n erc20\n\n 6\n\n 5.7k\n\n Nov 2021\n\n ERC20 decimals, specifying a big number\n\n Contracts\n\n 5\n\n 5.3k\n\n Jan 2020\n\n How to handle ERC20 that is not 18 decimals\n\n Support\n\n 2\n\n 719\n\n Dec 2021","tokens":1203,"squid":"ink-security_audits","role":"Sentinel","at":1791261959427,"hash":"0937b380636c7dd3741ab4f10617cb4ff0294c2e"}
{"url":"https://dev-forum.pyth.network/t/about-the-benchmarks-historic-prices-category/16/1","domain":"dev-forum.pyth.network","title":"About the Benchmarks(Historic Prices) category - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n About the Benchmarks(Historic Prices) category \n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 1 / 3\n\n Mar 2025\n\n Oct 2025\n\n post by Aditya520 on Mar 31, 2025\n\n Aditya520\n\n This is the place to dive into the Pyth Benchmarks, the ultimate tool to query historic price on-chain.\n Drop your questions, share your use case, or show off what you’re building.\nThe Pyth team and community devs are here to help.\n\n 3 months later\n\n post by andgo75 on Jun 25, 2025\n\n andgo75\n\n How can I use benchmark data on Solana?\nfor example, I’ve got:\ncurl -s https://hermes.pyth.network/v2/updates/price/1750677111\\?ids\\[\\]\\=67be9f519b95cf24338801051f9a808eff0a578ccb388db73b7f6fe1de019ffb\\&parsed\\=false\\&encoding\\=base64 | jq .\n{\n \"binary\": {\n \"encoding\": \"base64\",\n \"data\": [\n \"UE5BVQEAAAADuAEAAAAEDQEyndMFmvirVBmWlxKbOzCuIj3krd3CYuUtAcG3sdirMG0zuxwwSlWn3GY3vUpQ6qbEfWBQPHdzbJXDW1QuChIXAAJ/eU/CKVm+pZiF4/6OD4SCZTRZ2yoIts/B75gFRBEI4X0KdS/b1cfc280lFZuRN3wg5RG77MMp338MjE3omXJ8AQO7ZeJxT5/Idb624bP5kt9E/ZSoPEP99h3O3GT2WY1s8wwOcqJxooOrAKlS/Zv94Ke2K7VePEzFCz3npbkIqjSPAAQu290JKf18/FJvRrLHBJJRn/uohRcokHfzADyI1snlpEjtSUHD9xZsEDjd/viAb6HSBJ7G19n20zylaOqC91CSAAbFHuV/NICc8afrT8gmGbCYhlyVqcg7ausfd5zjlv0QqkZXTWhZaPWrvOUBtxC2IVlzp4qK+WPoaXQMbtI6ITNyAQgbspi1l50TXm1qtNAWHnGQ1Ri+MUlFe4vgUW4DZUh3lFjJzTv4oTR/LcDVlvxWiyaHamthUBSnTkDYObxFt0apAQo2EynYlfMUNpyZnaN8a0VCyoXi+/K2yAJurJBW8pbslS1ypvccfyQpUp7lgeKVaO97LM89rMNHZOJjjYfkPoDnAAvwrFJOxhcWJaeiXBImtJQ9TdsTGQ/azx+hpoxPL7gLUByFUjOjsM6Z5HjUzpxU6kJ+eD7eiO5j7C2TpIw5XpzvAQzB5UUJo4tG9LMilQHXSDE7Wg0u4UkXHQ8FbzG0eh4n7y+8YPYgt3s9QU4JVRlFdrVUicPxlHIYD7zCgodCu1/+AA3e+SSX129g4VVwZov9/9tZNvJc7JzDehyP6VvIEnj+HBo8pKsbmUe2380GKn6yT/4WoktQIqkSHWz9ZN93tOF8AQ45FO1XAd/1koipxEml2KBGVmcK0iPc4w+DMiBrnESlXVipaIE10//S0DbeIXpPy4r70qQryOkSwWwAb3KT5pnEARDdvHh+xyE0W9S54HEcy00MYOKN6qq1W5+d68S/544CYUAbFIzxCMF5QyigdsIbdwiWrz3+l8fI7Z10cK7w0Yp4AREVo2D0fnEb/4TN9D3FjFywfksAeSpghIGV78drqO29JDDe5OnLeZNCKou177evZT915BSLo6k9dXS47LpnDRnAAGhZNncAAAAAABrhAfrtrFhR4yubI7X5QRqMK6xKrj7U3XuBHdGnLqSqcQAAAAAIX73vAUFVV1YAAAAAAA1tSdwAACcQFSTftowHFbiMFIL6P/N4hPz5AsgBAFUAZ76fUZuVzyQziAEFH5qAjv8KV4zLOI23O39v4d4Bn/sAAAADxaOIPwAAAAABpBh8////+AAAAABoWTZ3AAAAAGhZNnYAAAADxrcBAAAAAAABsZHcDP9liTH33XTb+qPm5d4lQNipr+liPZuNLIOjYkJkr80brAOL0ZxEk7b6tHKeksKIjAGExmIWVYUReyU+xlXnB7Tb19cL/7mHv/ZewojNSImYrrTMgG2ra1+IBqLHhGp6051IxOroJD00bAyJo1Bs13UyFA0hryD3j0A3/V/90pPNoG711oND7DcZMBowt//26K2dAwrcPXJnB8l3BcQrynhpiw5LyF9GLHg8//sUz2OzQbU+Ur5ZZ4PugNkbB4WwRE3FC5IHkC+QI+Hbec0T9LaTr+P4uNeZ8/1+UZkQhJo2UCUMkH6s5MXGvSVSkLfyUg==\"\n ]\n }\n}\n\nthis data is 1291 bytes, it excess solana transaction size (1232), so def I can’t put it in my tx. So what should I do to use it?\n\n 4 months later\n\n post by guibescos on Oct 22, 2025\n\n guibescos\n\n gm gm,\nSorry for the late response.\nThis is a good observation, indeed the data exceeds the transaction size and posting thus requires multiple transactions.\nThe sdk https://www.npmjs.com/package/@pythnetwork/pyth-solana-receiver can handle splitting up the payload in multiple transactions. Here is a benchmarks example using the sdk:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 221\n\n Jan 12\n\n Benchmarks on Solana\n\n Benchmarks(Historic Prices)\n\n 1\n\n 498\n\n Jun 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Validating price data against benchmark api\n\n Benchmarks(Historic Prices)\n\n 2\n\n 411\n\n Oct 2025\n\n Benchmarks Explainer on Solana\n\n Price Feeds\n\n svm\n\n 7\n\n 836\n\n Aug 2025\n\n Powered by Discourse","tokens":1795,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261966441,"hash":"982bf890267ca4833540222d3ecf916d6862e507"}
{"url":"https://forum.openzeppelin.com/t/understanding-decimals-for-erc20-token-creation/1821","domain":"forum.openzeppelin.com","title":"Understanding decimals for ERC20 token creation? - Support / Contracts - OpenZeppelin Forum","text":"Understanding decimals for ERC20 token creation? \n\n SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Nov 2019\n\n 1 / 11\n\n Nov 2019\n\n Jun 2022\n\n post by manolingam on Nov 25, 2019\n\n manolingam\n\n Hi people,\nI am experimenting with ERC20 tokens and want to set a supply with 18 decimals. And I couldn’t understand the math behind it. Can someone explain it please?\nFor example, if I wanna create a supply with 10000 Tokens, what is the math behind it?\nShould I do 10000 / (10 ** 18) or 10000 * 10 ** 18? And what value should I pass for the _mint function to create 10000 tokens?\nI know the math is simple but bear with me. I am poor at calculations \nThanks.\n\n ERC20 decimals, specifying a big number\n\n 3\n\n 3\n\n post by abcoathup on Nov 25, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @manolingam,\nPlease see the OpenZeppelin documentation on decimals which should explain the math:\nhttps://docs.openzeppelin.com/contracts/2.x/tokens#a-note-on-decimals\nTLDR: Decimals are for display purposes, calculations are done in the base units for a token. So you need 10000 * 10 ** 18 (token base units) for 10000 tokens.\nSee an example below:\nSimpleToken\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\n\n/**\n * @title SimpleToken\n * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.\n * Note they can later distribute these tokens as they wish using `transfer` and other\n * `ERC20` functions.\n */\ncontract SimpleToken is Context, ERC20, ERC20Detailed {\n\n /**\n * @dev Constructor that gives _msgSender() all of existing tokens.\n */\n constructor () public ERC20Detailed(\"SimpleToken\", \"SIM\", 18) {\n _mint(_msgSender(), 10000 * (10 ** uint256(decimals())));\n }\n}\n\n ERC20Detailed.sol not found in @openzeppelin/contracts/token/ERC20 on GitHub\n\n post by manolingam on Nov 25, 2019\n\n manolingam\n\n Thanks @abcoathup. Yes, I checked the documentation too.\nOkay. If I wanna transfer 100 tokens, then should I call the transfer function with 100 * 10 ** 18?\n\n post by abcoathup on Nov 25, 2019\n\n abcoathup\n\n Great contributor\n\n Yes. All operations in the smart contract use the token base units, so to transfer 100 tokens you transfer 100 * 10 ** 18 token base units.\n\n post by manolingam on Nov 25, 2019\n\n manolingam\n\n Since all operations needs to be multiplied by ten to the power of decimals, should we manually update amount from OpenZeppelin contracts to amount * 10 ** 18 for the functions in ERC20.sol ? or Can I send the transactions using web3.utils.toWei(amount, 'ether') ?\n\n post by abcoathup on Nov 25, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @manolingam,\nWe need to use amounts in token base units when we call ERC20 functions.\nIf we updated the amount used in the contract to be amount * 10 ** 18 it would be the equivalent of having decimals of zero, or using the example of dollars and cents, it would be the equivalent of only using dollars.\nWhilst you should be able to use web3.utils.toWei(amount, 'ether') it is less clear for someone reading your code, so I would suggest not doing that.\n\n 2 years later\n\n post by serdarpinar on Dec 20, 2021\n\n serdarpinar\n\n Hi.. i have same problem..\nmy erc20 contract with 18 decimals. but i transferred to another account and then im seeing 0.0001 ..\nwhat can i do this ? i want , if i buy the 1000 tokens and then i want see 1000 tokens on my metamask.. i hope understand me\n\n post by Amxx on Dec 22, 2021\n\n Amxx\n\n OpenZeppelin Team\n\n @serdarpinar please read the message in the thread. Your answer is already there.\n\n 11 days later\n\n post by DoDzilla on Jan 3, 2022\n\n DoDzilla\n\n serdarpinar\n\n Your ERC20 contract has 18 decimals. If you want to send 1000 tokens then you should multiply 1000 with 10^18 (as described by the @abcoathup 1000 * 10^18). So you should send 1000000000000000000000 (1000 and 18 zeros)\n\n 2 months later\n\n post by BeratOz01 on Mar 7, 2022\n\n BeratOz01\n\n abcoathup\n\n I need to increase allowance like 0.3 busdt. How did I need to do that guys ?\n\n 3 months later\n\n post by PaulRBerg on Jun 12, 2022\n\n PaulRBerg\n\n @BeratOz01 You need a fixed-point math library for that. See this:\nWhat fixed or float point math libraries are available in solidity?\nI recommend using PRBMath - though note that I'm biased since I'm the author of the library.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n ERC20 `decimals` , what if it’s not present\n\n General\n\n 1\n\n 588\n\n Jun 2021\n\n ERC-20 total supply unit?\n\n Smart Contracts\n\n 1\n\n 389\n\n Dec 2021\n\n What does it look like to override the decimals function?\n\n Contracts\n\n erc20\n\n 6\n\n 5.7k\n\n Nov 2021\n\n ERC20 decimals, specifying a big number\n\n Contracts\n\n 5\n\n 5.3k\n\n Jan 2020\n\n How to handle ERC20 that is not 18 decimals\n\n Support\n\n 2\n\n 719\n\n Dec 2021","tokens":1216,"squid":"ink-security_audits","role":"Sentinel","at":1791261970001,"hash":"3e9a4f8f59b1eb8349e86b041f353532468348dd"}
{"url":"https://dev-forum.pyth.network/t/about-the-benchmarks-historic-prices-category/16/2","domain":"dev-forum.pyth.network","title":"About the Benchmarks(Historic Prices) category - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 2 / 3\n\n Jun 2025\n\n Oct 2025\n\n post by Aditya520 on Mar 31, 2025\n\n Aditya520\n\n This is the place to dive into the Pyth Benchmarks, the ultimate tool to query historic price on-chain.\n Drop your questions, share your use case, or show off what you’re building.\nThe Pyth team and community devs are here to help.\n\n 3 months later\n\n post by andgo75 on Jun 25, 2025\n\n andgo75\n\n How can I use benchmark data on Solana?\nfor example, I’ve got:\ncurl -s https://hermes.pyth.network/v2/updates/price/1750677111\\?ids\\[\\]\\=67be9f519b95cf24338801051f9a808eff0a578ccb388db73b7f6fe1de019ffb\\&parsed\\=false\\&encoding\\=base64 | jq .\n{\n \"binary\": {\n \"encoding\": \"base64\",\n \"data\": [\n \"UE5BVQEAAAADuAEAAAAEDQEyndMFmvirVBmWlxKbOzCuIj3krd3CYuUtAcG3sdirMG0zuxwwSlWn3GY3vUpQ6qbEfWBQPHdzbJXDW1QuChIXAAJ/eU/CKVm+pZiF4/6OD4SCZTRZ2yoIts/B75gFRBEI4X0KdS/b1cfc280lFZuRN3wg5RG77MMp338MjE3omXJ8AQO7ZeJxT5/Idb624bP5kt9E/ZSoPEP99h3O3GT2WY1s8wwOcqJxooOrAKlS/Zv94Ke2K7VePEzFCz3npbkIqjSPAAQu290JKf18/FJvRrLHBJJRn/uohRcokHfzADyI1snlpEjtSUHD9xZsEDjd/viAb6HSBJ7G19n20zylaOqC91CSAAbFHuV/NICc8afrT8gmGbCYhlyVqcg7ausfd5zjlv0QqkZXTWhZaPWrvOUBtxC2IVlzp4qK+WPoaXQMbtI6ITNyAQgbspi1l50TXm1qtNAWHnGQ1Ri+MUlFe4vgUW4DZUh3lFjJzTv4oTR/LcDVlvxWiyaHamthUBSnTkDYObxFt0apAQo2EynYlfMUNpyZnaN8a0VCyoXi+/K2yAJurJBW8pbslS1ypvccfyQpUp7lgeKVaO97LM89rMNHZOJjjYfkPoDnAAvwrFJOxhcWJaeiXBImtJQ9TdsTGQ/azx+hpoxPL7gLUByFUjOjsM6Z5HjUzpxU6kJ+eD7eiO5j7C2TpIw5XpzvAQzB5UUJo4tG9LMilQHXSDE7Wg0u4UkXHQ8FbzG0eh4n7y+8YPYgt3s9QU4JVRlFdrVUicPxlHIYD7zCgodCu1/+AA3e+SSX129g4VVwZov9/9tZNvJc7JzDehyP6VvIEnj+HBo8pKsbmUe2380GKn6yT/4WoktQIqkSHWz9ZN93tOF8AQ45FO1XAd/1koipxEml2KBGVmcK0iPc4w+DMiBrnESlXVipaIE10//S0DbeIXpPy4r70qQryOkSwWwAb3KT5pnEARDdvHh+xyE0W9S54HEcy00MYOKN6qq1W5+d68S/544CYUAbFIzxCMF5QyigdsIbdwiWrz3+l8fI7Z10cK7w0Yp4AREVo2D0fnEb/4TN9D3FjFywfksAeSpghIGV78drqO29JDDe5OnLeZNCKou177evZT915BSLo6k9dXS47LpnDRnAAGhZNncAAAAAABrhAfrtrFhR4yubI7X5QRqMK6xKrj7U3XuBHdGnLqSqcQAAAAAIX73vAUFVV1YAAAAAAA1tSdwAACcQFSTftowHFbiMFIL6P/N4hPz5AsgBAFUAZ76fUZuVzyQziAEFH5qAjv8KV4zLOI23O39v4d4Bn/sAAAADxaOIPwAAAAABpBh8////+AAAAABoWTZ3AAAAAGhZNnYAAAADxrcBAAAAAAABsZHcDP9liTH33XTb+qPm5d4lQNipr+liPZuNLIOjYkJkr80brAOL0ZxEk7b6tHKeksKIjAGExmIWVYUReyU+xlXnB7Tb19cL/7mHv/ZewojNSImYrrTMgG2ra1+IBqLHhGp6051IxOroJD00bAyJo1Bs13UyFA0hryD3j0A3/V/90pPNoG711oND7DcZMBowt//26K2dAwrcPXJnB8l3BcQrynhpiw5LyF9GLHg8//sUz2OzQbU+Ur5ZZ4PugNkbB4WwRE3FC5IHkC+QI+Hbec0T9LaTr+P4uNeZ8/1+UZkQhJo2UCUMkH6s5MXGvSVSkLfyUg==\"\n ]\n }\n}\n\nthis data is 1291 bytes, it excess solana transaction size (1232), so def I can’t put it in my tx. So what should I do to use it?\n\n 4 months later\n\n post by guibescos on Oct 22, 2025\n\n guibescos\n\n gm gm,\nSorry for the late response.\nThis is a good observation, indeed the data exceeds the transaction size and posting thus requires multiple transactions.\nThe sdk https://www.npmjs.com/package/@pythnetwork/pyth-solana-receiver can handle splitting up the payload in multiple transactions. Here is a benchmarks example using the sdk:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 221\n\n Jan 12\n\n Benchmarks on Solana\n\n Benchmarks(Historic Prices)\n\n 1\n\n 498\n\n Jun 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Validating price data against benchmark api\n\n Benchmarks(Historic Prices)\n\n 2\n\n 411\n\n Oct 2025\n\n Benchmarks Explainer on Solana\n\n Price Feeds\n\n svm\n\n 7\n\n 836\n\n Aug 2025\n\n Powered by Discourse","tokens":1782,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261977226,"hash":"a6caf63e8e8a9720b5be862701f2858e04f3a29f"}
{"url":"https://forum.openzeppelin.com/t/erc20-decimals/2047","domain":"forum.openzeppelin.com","title":"ERC20 decimals, specifying a big number - Support / Contracts - OpenZeppelin Forum","text":"ERC20 decimals, specifying a big number \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Jan 2020\n\n 1 / 6\n\n Jan 2020\n\n Jan 2020\n\n post by sirphemmiey on Jan 7, 2020\n\n sirphemmiey\n\n I followed the conversation here to see if it would answer my question, but no it didn’t.\nI understand that i have to use amount *= (amount ** tokenDecimal) before sending transactions with ERC20 transfer method, but when i do that i get an error.\n\nScreen Shot 2020-01-08 at 12.16.58 AM1370×62 6.8 KB\n\nI’m not sure what’s wrong because alot of articles have used this for examples.\nThanks for your help.\n\n 3\n\n 3\n\n post by abcoathup on Jan 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @sirphemmiey,\nYou can use a Big Number library.\nThe test below uses BN from @openzeppelin/test-helpers\nSimpleToken.test.js\nconst { accounts, contract } = require('@openzeppelin/test-environment');\n\nconst {\n BN, // Big Number support\n constants, // Common constants, like the zero address and largest integers\n expectEvent, // Assertions for emitted events\n expectRevert, // Assertions for transactions that should fail\n} = require('@openzeppelin/test-helpers');\n\nconst [ creator, other ] = accounts;\n\nconst { expect } = require('chai');\n\nconst SimpleToken = contract.fromArtifact('SimpleToken'); // Loads a compiled contract\n\ndescribe('SimpleToken', function () {\n it('transfer', async function () {\n const token = await SimpleToken.new({ from: creator });\n const amount = new BN(\"1000000000000000000000\");\n await token.transfer(other, amount, {from: creator});\n expect(await token.balanceOf(other)).to.be.bignumber.equal(amount);\n });\n});\n\nSimpleToken.sol\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\n\n/**\n * @title SimpleToken\n * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.\n * Note they can later distribute these tokens as they wish using `transfer` and other\n * `ERC20` functions.\n */\ncontract SimpleToken is Context, ERC20, ERC20Detailed {\n\n /**\n * @dev Constructor that gives _msgSender() all of existing tokens.\n */\n constructor () public ERC20Detailed(\"SimpleToken\", \"SIM\", 18) {\n _mint(_msgSender(), 10000 * (10 ** uint256(decimals())));\n }\n}\n\n post by sirphemmiey on Jan 8, 2020\n\n sirphemmiey\n\n Hi @abcoathup, thanks for your reply.\nI have tried a number of different big number libraries, the problem still persist.\nThis is what i’m trying to do;\nlet amount = withdrawObj.amount; \nconst TokenDecimals = await this.getDecimal(symbol); // get the decimal of a token\namount *= (10 ** TokenDecimals);\nLet's say the token decimal function returns 18 obviously, and i pass2as the amount to transfer, it gives me2000000000000000000` which appears too large for the ERC20 transfer function to process. I have tried the big number library, OZ test helper, bing interger, ethers, web3 etc all to no avail.\nThanks for your help once again.\n\n post by abcoathup on Jan 8, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @sirphemmiey,\nWe need to use the big number libraries multiply and power functions to do the calculation as the number is too big for JavaScript.\n const tokenbits = (new BN(10)).pow(decimals); \n const amount = (new BN(100)).mul(tokenbits); \n\nSee the following test for the SimpleToken contract above:\nSimpleToken.test.js\nconst { accounts, contract } = require('@openzeppelin/test-environment');\n\nconst {\n BN, // Big Number support\n constants, // Common constants, like the zero address and largest integers\n expectEvent, // Assertions for emitted events\n expectRevert, // Assertions for transactions that should fail\n} = require('@openzeppelin/test-helpers');\n\nconst [ creator, other ] = accounts;\n\nconst { expect } = require('chai');\n\nconst SimpleToken = contract.fromArtifact('SimpleToken'); // Loads a compiled contract\n\ndescribe('SimpleToken', function () {\n it('transfer', async function () {\n const token = await SimpleToken.new({ from: creator });\n const decimals = await token.decimals.call();\n const tokenbits = (new BN(10)).pow(decimals);\n const amount = (new BN(100)).mul(tokenbits);\n\n console.log(`Amount: ${amount}`);\n\n await token.transfer(other, amount, {from: creator});\n expect(await token.balanceOf(other)).to.be.bignumber.equal(amount);\n });\n});\n\n Incorrect Product of BigDecimals\n\n post by sirphemmiey on Jan 11, 2020\n\n sirphemmiey\n\n Thanks for your reply.\nIt still displays the same error “(arg=”_value\", coderType=“uint256”, value=10000000000000000)\"\nBut when i changed the amount value after the bigNumber conversions to amount.toString(), the transaction went successfully.\nCould there be any issue with this way at the long run?\n\n post by abcoathup on Jan 12, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @sirphemmiey,\nI assume it depends on the JavaScript library that you use to handle big numbers.\nJust ensure that you have appropriate testing that you are transferring the required amount of tokens.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n 100000000050000000 instead of 1050000000 when sending ERC20 token\n\n Smart Contracts\n\n erc20\n\n 4\n\n 458\n\n Oct 2022\n\n Incorrect Product of BigDecimals\n\n Support\n\n test-helpers\n\n 1\n\n 1.2k\n\n May 2021\n\n MyToken.sol mint() JavaScript “Error: overflow” on big numbers\n\n Contracts\n\n 7\n\n 10.1k\n\n Apr 2021\n\n Help please with: invalid number value (arg=“amount”, coderType=“uint256”\n\n Contracts\n\n erc20\n\n 3\n\n 8.6k\n\n Sep 2021","tokens":1396,"squid":"ink-security_audits","role":"Sentinel","at":1791261980709,"hash":"394fe91779a35957956ee41076232ff217fa23da"}
{"url":"https://dev-forum.pyth.network/t/about-the-benchmarks-historic-prices-category/16/4","domain":"dev-forum.pyth.network","title":"About the Benchmarks(Historic Prices) category - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 3 / 3\n\n Oct 2025\n\n Oct 2025\n\n post by Aditya520 on Mar 31, 2025\n\n Aditya520\n\n This is the place to dive into the Pyth Benchmarks, the ultimate tool to query historic price on-chain.\n Drop your questions, share your use case, or show off what you’re building.\nThe Pyth team and community devs are here to help.\n\n 3 months later\n\n post by andgo75 on Jun 25, 2025\n\n andgo75\n\n How can I use benchmark data on Solana?\nfor example, I’ve got:\ncurl -s https://hermes.pyth.network/v2/updates/price/1750677111\\?ids\\[\\]\\=67be9f519b95cf24338801051f9a808eff0a578ccb388db73b7f6fe1de019ffb\\&parsed\\=false\\&encoding\\=base64 | jq .\n{\n \"binary\": {\n \"encoding\": \"base64\",\n \"data\": [\n \"UE5BVQEAAAADuAEAAAAEDQEyndMFmvirVBmWlxKbOzCuIj3krd3CYuUtAcG3sdirMG0zuxwwSlWn3GY3vUpQ6qbEfWBQPHdzbJXDW1QuChIXAAJ/eU/CKVm+pZiF4/6OD4SCZTRZ2yoIts/B75gFRBEI4X0KdS/b1cfc280lFZuRN3wg5RG77MMp338MjE3omXJ8AQO7ZeJxT5/Idb624bP5kt9E/ZSoPEP99h3O3GT2WY1s8wwOcqJxooOrAKlS/Zv94Ke2K7VePEzFCz3npbkIqjSPAAQu290JKf18/FJvRrLHBJJRn/uohRcokHfzADyI1snlpEjtSUHD9xZsEDjd/viAb6HSBJ7G19n20zylaOqC91CSAAbFHuV/NICc8afrT8gmGbCYhlyVqcg7ausfd5zjlv0QqkZXTWhZaPWrvOUBtxC2IVlzp4qK+WPoaXQMbtI6ITNyAQgbspi1l50TXm1qtNAWHnGQ1Ri+MUlFe4vgUW4DZUh3lFjJzTv4oTR/LcDVlvxWiyaHamthUBSnTkDYObxFt0apAQo2EynYlfMUNpyZnaN8a0VCyoXi+/K2yAJurJBW8pbslS1ypvccfyQpUp7lgeKVaO97LM89rMNHZOJjjYfkPoDnAAvwrFJOxhcWJaeiXBImtJQ9TdsTGQ/azx+hpoxPL7gLUByFUjOjsM6Z5HjUzpxU6kJ+eD7eiO5j7C2TpIw5XpzvAQzB5UUJo4tG9LMilQHXSDE7Wg0u4UkXHQ8FbzG0eh4n7y+8YPYgt3s9QU4JVRlFdrVUicPxlHIYD7zCgodCu1/+AA3e+SSX129g4VVwZov9/9tZNvJc7JzDehyP6VvIEnj+HBo8pKsbmUe2380GKn6yT/4WoktQIqkSHWz9ZN93tOF8AQ45FO1XAd/1koipxEml2KBGVmcK0iPc4w+DMiBrnESlXVipaIE10//S0DbeIXpPy4r70qQryOkSwWwAb3KT5pnEARDdvHh+xyE0W9S54HEcy00MYOKN6qq1W5+d68S/544CYUAbFIzxCMF5QyigdsIbdwiWrz3+l8fI7Z10cK7w0Yp4AREVo2D0fnEb/4TN9D3FjFywfksAeSpghIGV78drqO29JDDe5OnLeZNCKou177evZT915BSLo6k9dXS47LpnDRnAAGhZNncAAAAAABrhAfrtrFhR4yubI7X5QRqMK6xKrj7U3XuBHdGnLqSqcQAAAAAIX73vAUFVV1YAAAAAAA1tSdwAACcQFSTftowHFbiMFIL6P/N4hPz5AsgBAFUAZ76fUZuVzyQziAEFH5qAjv8KV4zLOI23O39v4d4Bn/sAAAADxaOIPwAAAAABpBh8////+AAAAABoWTZ3AAAAAGhZNnYAAAADxrcBAAAAAAABsZHcDP9liTH33XTb+qPm5d4lQNipr+liPZuNLIOjYkJkr80brAOL0ZxEk7b6tHKeksKIjAGExmIWVYUReyU+xlXnB7Tb19cL/7mHv/ZewojNSImYrrTMgG2ra1+IBqLHhGp6051IxOroJD00bAyJo1Bs13UyFA0hryD3j0A3/V/90pPNoG711oND7DcZMBowt//26K2dAwrcPXJnB8l3BcQrynhpiw5LyF9GLHg8//sUz2OzQbU+Ur5ZZ4PugNkbB4WwRE3FC5IHkC+QI+Hbec0T9LaTr+P4uNeZ8/1+UZkQhJo2UCUMkH6s5MXGvSVSkLfyUg==\"\n ]\n }\n}\n\nthis data is 1291 bytes, it excess solana transaction size (1232), so def I can’t put it in my tx. So what should I do to use it?\n\n 4 months later\n\n post by guibescos on Oct 22, 2025\n\n guibescos\n\n gm gm,\nSorry for the late response.\nThis is a good observation, indeed the data exceeds the transaction size and posting thus requires multiple transactions.\nThe sdk https://www.npmjs.com/package/@pythnetwork/pyth-solana-receiver can handle splitting up the payload in multiple transactions. Here is a benchmarks example using the sdk:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 221\n\n Jan 12\n\n Benchmarks on Solana\n\n Benchmarks(Historic Prices)\n\n 1\n\n 498\n\n Jun 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Validating price data against benchmark api\n\n Benchmarks(Historic Prices)\n\n 2\n\n 411\n\n Oct 2025\n\n Benchmarks Explainer on Solana\n\n Price Feeds\n\n svm\n\n 7\n\n 836\n\n Aug 2025\n\n Powered by Discourse","tokens":1782,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261987534,"hash":"f5a25fe65cd60652d76c9e365b81e86e297f8bad"}
{"url":"https://forum.openzeppelin.com/t/erc20-decimals-specifying-a-big-number/2047/6","domain":"forum.openzeppelin.com","title":"ERC20 decimals, specifying a big number - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Jan 2020\n\n 6 / 6\n\n Jan 2020\n\n Jan 2020\n\n post by sirphemmiey on Jan 7, 2020\n\n sirphemmiey\n\n I followed the conversation here to see if it would answer my question, but no it didn’t.\nI understand that i have to use amount *= (amount ** tokenDecimal) before sending transactions with ERC20 transfer method, but when i do that i get an error.\n\nScreen Shot 2020-01-08 at 12.16.58 AM1370×62 6.8 KB\n\nI’m not sure what’s wrong because alot of articles have used this for examples.\nThanks for your help.\n\n 3\n\n 3\n\n post by abcoathup on Jan 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @sirphemmiey,\nYou can use a Big Number library.\nThe test below uses BN from @openzeppelin/test-helpers\nSimpleToken.test.js\nconst { accounts, contract } = require('@openzeppelin/test-environment');\n\nconst {\n BN, // Big Number support\n constants, // Common constants, like the zero address and largest integers\n expectEvent, // Assertions for emitted events\n expectRevert, // Assertions for transactions that should fail\n} = require('@openzeppelin/test-helpers');\n\nconst [ creator, other ] = accounts;\n\nconst { expect } = require('chai');\n\nconst SimpleToken = contract.fromArtifact('SimpleToken'); // Loads a compiled contract\n\ndescribe('SimpleToken', function () {\n it('transfer', async function () {\n const token = await SimpleToken.new({ from: creator });\n const amount = new BN(\"1000000000000000000000\");\n await token.transfer(other, amount, {from: creator});\n expect(await token.balanceOf(other)).to.be.bignumber.equal(amount);\n });\n});\n\nSimpleToken.sol\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\n\n/**\n * @title SimpleToken\n * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.\n * Note they can later distribute these tokens as they wish using `transfer` and other\n * `ERC20` functions.\n */\ncontract SimpleToken is Context, ERC20, ERC20Detailed {\n\n /**\n * @dev Constructor that gives _msgSender() all of existing tokens.\n */\n constructor () public ERC20Detailed(\"SimpleToken\", \"SIM\", 18) {\n _mint(_msgSender(), 10000 * (10 ** uint256(decimals())));\n }\n}\n\n post by sirphemmiey on Jan 8, 2020\n\n sirphemmiey\n\n Hi @abcoathup, thanks for your reply.\nI have tried a number of different big number libraries, the problem still persist.\nThis is what i’m trying to do;\nlet amount = withdrawObj.amount; \nconst TokenDecimals = await this.getDecimal(symbol); // get the decimal of a token\namount *= (10 ** TokenDecimals);\nLet's say the token decimal function returns 18 obviously, and i pass2as the amount to transfer, it gives me2000000000000000000` which appears too large for the ERC20 transfer function to process. I have tried the big number library, OZ test helper, bing interger, ethers, web3 etc all to no avail.\nThanks for your help once again.\n\n post by abcoathup on Jan 8, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @sirphemmiey,\nWe need to use the big number libraries multiply and power functions to do the calculation as the number is too big for JavaScript.\n const tokenbits = (new BN(10)).pow(decimals); \n const amount = (new BN(100)).mul(tokenbits); \n\nSee the following test for the SimpleToken contract above:\nSimpleToken.test.js\nconst { accounts, contract } = require('@openzeppelin/test-environment');\n\nconst {\n BN, // Big Number support\n constants, // Common constants, like the zero address and largest integers\n expectEvent, // Assertions for emitted events\n expectRevert, // Assertions for transactions that should fail\n} = require('@openzeppelin/test-helpers');\n\nconst [ creator, other ] = accounts;\n\nconst { expect } = require('chai');\n\nconst SimpleToken = contract.fromArtifact('SimpleToken'); // Loads a compiled contract\n\ndescribe('SimpleToken', function () {\n it('transfer', async function () {\n const token = await SimpleToken.new({ from: creator });\n const decimals = await token.decimals.call();\n const tokenbits = (new BN(10)).pow(decimals);\n const amount = (new BN(100)).mul(tokenbits);\n\n console.log(`Amount: ${amount}`);\n\n await token.transfer(other, amount, {from: creator});\n expect(await token.balanceOf(other)).to.be.bignumber.equal(amount);\n });\n});\n\n Incorrect Product of BigDecimals\n\n post by sirphemmiey on Jan 11, 2020\n\n sirphemmiey\n\n Thanks for your reply.\nIt still displays the same error “(arg=”_value\", coderType=“uint256”, value=10000000000000000)\"\nBut when i changed the amount value after the bigNumber conversions to amount.toString(), the transaction went successfully.\nCould there be any issue with this way at the long run?\n\n post by abcoathup on Jan 12, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @sirphemmiey,\nI assume it depends on the JavaScript library that you use to handle big numbers.\nJust ensure that you have appropriate testing that you are transferring the required amount of tokens.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Understanding decimals for ERC20 token creation?\n\n Contracts\n\n erc20\n\n 10\n\n 29.5k\n\n Jun 2022\n\n 100000000050000000 instead of 1050000000 when sending ERC20 token\n\n Smart Contracts\n\n erc20\n\n 4\n\n 458\n\n Oct 2022\n\n Incorrect Product of BigDecimals\n\n Support\n\n test-helpers\n\n 1\n\n 1.2k\n\n May 2021\n\n MyToken.sol mint() JavaScript “Error: overflow” on big numbers\n\n Contracts\n\n 7\n\n 10.1k\n\n Apr 2021\n\n Help please with: invalid number value (arg=“amount”, coderType=“uint256”\n\n Contracts\n\n erc20\n\n 3\n\n 8.6k\n\n Sep 2021","tokens":1385,"squid":"ink-security_audits","role":"Sentinel","at":1791261991091,"hash":"ed5f34c90901b27f3e25ceea6f337c626290225d"}
{"url":"https://io.net/docs/guides/workers/install-on-ubuntu","domain":"io.net","title":"Overview - io.net","text":"​Before Starting\n1. Open the Ubuntu Terminal through the Start Menu.\nTerminal is a tool on your computer that lets you type in commands to tell the computer what to do. Instead of clicking on things with a mouse, you write instructions, and the computer follows them. It’s like talking directly to your computer using text.\nClick the Start Menu icon, start typing “Terminal” in the search field, then click the Terminal icon:\n\n2. Verify Your Ubuntu Version\nFor Linux users, ensure that your system is running Ubuntu 20.04 or later. You can check your Ubuntu version by executing the following command in the terminal.\nWe recommend that you use Ubuntu 22.04 LTS.\nlsb_release -a\n\n3. CPU Requirement for Linux\nWe currently support AMD & Intel processors. You can find all supported processor and video card models found here.\nTo check your processor type, use the following command in the terminal:\nlscpu\n\n​Go to cloud.io.net\nIf you have not yet created an account, you can sign up on io.net using Google, Apple ID, GitHub, Hugging Face, X, Worldcoin, or simply with a one-time password by clicking the “Login with Email” button.\n\n​1. From IO Elements Navigate to IO Worker\nIO Elements serves as your new control panel for navigating the service efficiently. Click on IO Worker to delve deeper into its functionalities and features.\n\n​2. Use “Connect New Worker” Button to Open the Wizard\nIf Workers have not yet been added, you can use the central button. If the screen is full of information, find the same button in the upper right corner.\n\n​3. Name Your Device\nClick the “Pencil” icon to open the popup for editing the device name.\nPlease add a unique name for your device. An ideal format would be something like this: My-Test-Device
.\n\n​Select Ubuntu Operating System\nChoose the Operating System of your device from MacOS, Windows or Ubuntu.\n\n​5. Select Device Type\nYou should choose the device type based on your task. A video card is better suited for AI tasks, while a processor is more suitable for graphic rendering.\n - This is the part of your computer or laptop that handles graphics - the video card. It’s usually from Nvidea or Radeon. You can find a full list of video cards that io.net is compatible with here.\n - This forms the core of every smart device in our world, including your computer or laptop. Now, alongside Intel and AMD processors, Apple’s processors have also joined the lineup. You can find a comprehensive list of processors compatible with io.net here.\n\nYou can also verify whether your GPU or CPU is included in the list of devices supported by our service on the wizard page.\nIf you select a GPU Worker and your device doesn’t have GPU the setup will fail.\n​6. Prerequisites for Ubuntu - One-Time Setup for Hardware\nBefore proceeding, ensure you have the necessary tools installed on your Ubuntu system (skip if Docker and NVIDIA driver are already installed and configured).\nDo not install and use beta drivers for Linux.\nIf not, to install IO.Net Setup, follow these steps:\n\nInstall the desktop IO.NET Setup Script using the installation command in the Terminal:\ncurl -L https://github.com/ionet-official/io-net-official-setup-script/raw/main/ionet-setup.sh -o ionet-setup.sh\n\nsudo apt install curl \n\nGrant permissions to the new IO.NET Setup Script with this command:\nchmod +x ionet-setup.sh && ./ionet-setup.sh\n\nFor systems equipped with GPUs, wait for the system to restart. Once it has restarted, run the setup again using the command provided earlier.\n\nWhen using SXM or NV Link, ensure that Fabric Manager is installed correctly and enabled. This will prevent initialization issues and ensure that all GPUs are functioning properly, thereby avoiding PoW verification failures.\n\n​7. Download and Launch IO Binary\nIO Binary is a compiled executable file used to perform computational tasks and manage system operations. It is crucial for the smooth operation of the platform as it handles essential functions directly related to the performance and reliability of the computational resources.\nDo not modify or run code directly in io.net’s docker containers. This may disqualify your device from earning block rewards or being hired. If you have suggestions or ideas for custom code in our Docker containers, contact customer support to suggest them.\nIn this step, follow these instructions in the Terminal:\n\nDownload the IO Binary for Ubuntu using the following link:\ncurl -L https://github.com/ionet-official/io_launch_binaries/raw/main/io_net_launch_binary_linux -o io_net_launch_binary_linux\n\nGrant permissions to the new IO Binary with this command:\nchmod +x io_net_launch_binary_linux\n\nCopy generated the IO Binary address provided in the wizard and past it into Terminal to run further:\n./io_net_launch_binary_linux\n\nIf you want to disable sleep mode for a device, you can pass the —disable_sleep_mode=true argument at the end of the command line../io_net_launch_binary_linux --disable_sleep_mode=true\nYou can find more additional arguments to use with the IO Binary command here.\n\n​8. Authorize Your New Device\nThe IO Binary may prompt you to authorize your new device.\nRemember, you have 3 minutes to complete the authorization of the device. If you miss it, you will need to rerun the code again.\nYou can do this in two ways:\n\nCopy the Link from the Terminal:\n\nPaste it into your browser and confirm the action. After confirmation, the system will prompt you to log in.\n\nCopy the Code from the Terminal:\n\nEnter this code on the page https://auth0.io.solutions/activate to authorize the device. After it, the system will prompt you to log in.\n\nOnboarding Multiple Devices by Bypassing Interactive AuthenticationTo onboard a new device, use the following command with the —token flag:./io_net_launch_binary_linux --token your-token-value\nThis will allow you to bypass the interactive authentication process.\n​9. Remove previously installed Docker containers\n will ask you questions related to previously installed Docker Containers. To continue the installation of , you must agree to remove all old containers and proceed by typing: Yes\n\n​10. Waiting for Worker Connection to Complete\nIO Binary will install all additional containers and images for your Docker. The process may take some time to complete as it installs additional packages for Docker. Please allow the installation process to finish.\n\nAfterward, return to the browser to complete the installation.\nYou may need to wait for up to 10 minutes while the device checks and connects to the IO ecosystem. If it doesn’t connect, reach out to our Support ticket by logging into your IO.Net account.\n\nPlease disable power-saving mode when running your devices on IO Net. Power-saving mode can impair device performance, potentially leading to failure in PoW or being classified as not providing adequate computing power.\n​Congratulations on Successfully Setting up Your First Worker.\nNow that your Worker has been successfully created and is running, you can track its status on the Workers page.\n\nIf you’re having trouble installing Worker, please refer to our Worker troubleshooting guide. If the issue persists or you need further assistance, feel free to check our knowledge base for answers, and if you still need help, don’t hesitate to open a support ticket\nBe aware that you will be installing a 20GB size container. This contains all the packages needed to serve AI/ML apps. Everything happens inside the container, nothing within the container can access your filesystem.Was this page helpful?","tokens":1877,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791261991891,"hash":"c2823067cc084d041f43cd46c82c0b85c20cc205"}
{"url":"https://dev-forum.pyth.network/t/benchmark-price-for-uranus-failing/506/12","domain":"dev-forum.pyth.network","title":"Benchmark price for Uranus failing - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n svm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 3\n\n 2\n\n Jan 8\n\n 12 / 12\n\n Jan 11\n\n Jan 12\n\n post by Biboux on Jan 8\n\n Biboux\n\nChain : Solana Devnet\nTimestamp : 1767484800 but fails since 4 days\n\nHello,\nSince 4 days ago, our pyth benchmark (using Hermes) is failing for URANUS (Price Id : 0xae537f03693a1ed70781aa64387eb553e7ff56df30972a74f728c75413fdd0d0) is failing to query historical prices .\nthe error is :\n\n…/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:45\nthrow new Error(`HTTP error! status: ${response.status}${errorBody ? `, body: ${errorBody}` : “”}`);\nError: HTTP error! status: 404, body: Price ids not found: 0xae537f03693a1ed70781aa64387eb553e7ff56df30972a74f728c75413fdd0d0\n\nI tried the price Id and the beta one, both are leading to same issue.\nI also noticed that the priec feed account is not initializd : 6KKpqs5GNzR3GbLKS2B5oxQP8BMASN3BjPzE1Wd9ooRn\n\n 7\n\n 3\n\n 2\n\n post by KemarTiti on Jan 9\n\n KemarTiti\n\n Hey!\nFYI Hermes caches data only for approx. 10 min. Anything older, you would need to use the Benchmarks endpoint: Use Historical Price Data (Benchmarks) | Pyth Developer Hub\nAnd the error / price feed account not being initialized, it is the error message when this specific price feed has never been updated onchain. That 1st onchain update of URANUS (or any other feed) will initialize the price feed account, so do try to do a full round trip price update and it should work\n\n post by Biboux on Jan 9\n\n Biboux\n\n This is how we construct the transactions to upload the historical price with addPriceConsumerInstructions in between with our logic\nconst priceServiceConnection = new HermesClient(\n \"https://hermes.pyth.network/\", {},\n);\n\nconst response = await priceServiceConnection.getPriceUpdatesAtTimestamp(\n date,\n PRICE_FEEDS_ARRAY,\n { encoding: \"base64\" },\n);\n\nlet priceUpdate = response.binary.data\n\nconst pythReceiver = new PythSolanaReceiver({ connection, wallet });\n\nlet pythTx = pythReceiver.newTransactionBuilder({\ncloseUpdateAccounts: true,\n});\n\nawait pythTx.addPostPriceUpdates(priceUpdates);\n\nit works for Bonk, Jup, Popcat, Wif, Gmt, Zeus but not Uranus\nI’m able to query prices from many days ago with this methhod\n\n post by Biboux on Jan 9\n\n Biboux\n\n KemarTiti\n\n Maybe I’m dumb but I’m only finding pragma solidity so assumes it’s for eth not sol\n\n post by nidhi on Jan 9\n\n nidhi\n\n can you be specific please? What are you unable to find ?\n\n post by Biboux on Jan 9\n\n Biboux\n\ni mean this is for Eth, not Sol @nidhi\n\n post by nidhi on Jan 9\n\n nidhi\n\n The guide has information about the Benchmarks API. Sharing the Benchmarks API Benchmarks - Swagger UI for your reference here. The API remains the same for all the chains. So feel free to use it on Solana.\nOnce you fetch the price update data from Benchmarks, you can post it to Solana using the Pyth Solana Receiver SDK pyth-crosschain/target_chains/solana/sdk/js/pyth_solana_receiver/README.md at main · pyth-network/pyth-crosschain · GitHub\n\n post by Biboux on Jan 9\n\n Biboux\n\nThank you for taking the time to answr @nidhi but that’s alrady how I use Pyth benchmark and it was working for one year until 5 days ago where Uranus stopped working.\n\n post by nidhi on Jan 9\n\n nidhi\n\n Got it!\nThis is happening as URANUS price feed has been deprecated. This was announced here Price Feeds Upcoming Deactivations – January 1st, 2026\n\n post by Biboux on Jan 9\n\n Biboux\n\n WOW !!!\nthan you so much for pointing this out @nidhi !!\nwell we were using it so I’m not sure how to recover from that.\nwe’ll need to talk internally …\n\n post by Biboux on Jan 9\n\n Biboux\n\n nidhi\n\n Is there a way we can pull the prices from somewhere and store it on chain to use Uranus still?\n\n post by KemarTiti on Jan 12\n\n KemarTiti\n\n Sadly not. The price feed was deprecated here: Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 643\n\n Sep 2025\n\n Benchmarks Explainer on Solana\n\n Price Feeds\n\n svm\n\n 7\n\n 836\n\n Aug 2025\n\n Validating price data against benchmark api\n\n Benchmarks(Historic Prices)\n\n 2\n\n 411\n\n Oct 2025\n\n Powered by Discourse","tokens":1991,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791261997901,"hash":"400459dbaf515b16f0f72eb25639d749a14aa6bb"}
{"url":"https://specs.optimism.io/protocol/precompiles.html","domain":"specs.optimism.io","title":"Precompiles - OP Stack Specification","text":"Precompiles\n\nTable of Contents\n\nOverview\nP256VERIFY\n\nOverview\nPrecompiled contracts exist on OP-Stack chains at\npredefined addresses. They are similar to predeploys but are implemented as native code in the EVM as opposed to\nbytecode. Precompiles are used for computationally expensive operations, that would be cost prohibitive to implement\nin Solidity. Where possible predeploys are preferred, as precompiles must be implemented in every execution client.\nOP-Stack chains contain the standard Ethereum precompiles as well as a small\nnumber of additional precompiles. The following table lists each of the additional precompiles. The system version\nindicates when the precompile was introduced.\nNameAddressIntroduced\nP256VERIFY0x0000000000000000000000000000000000000100Fjord\n\nP256VERIFY\nThe P256VERIFY precompile performs signature verification for the secp256r1 elliptic curve. This curve has widespread\nadoption. It's used by Passkeys, Apple Secure Enclave and many other systems.\nIt is specified as part of RIP-7212 and was added to\nthe OP-Stack protocol in the Fjord release. The op-geth implementation is\nhere.\nAddress: 0x0000000000000000000000000000000000000100","tokens":292,"squid":"ink-governance","role":"Council Listener","at":1791262014357,"hash":"948ca1e9b1788ebbe68a04677d792df1f39f8b05"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/1","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Historical Price Feed in 03/01/2023 \n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 1 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 115\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1991,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262022244,"hash":"75fd1f756263974fcebd5fe8f296482d9acc9e5a"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/zk/zk-interface.html","domain":"specs.optimism.io","title":"IZKVerifier Interface - OP Stack Specification","text":"IZKVerifier Interface\n\nTable of Contents\n\nOverview\nInterface\nUsage in prove()\nVerifier Upgrade Path\n\nOverview\nIZKVerifier is the on-chain interface that decouples ZKDisputeGame from any specific\nproving system. The game always casts the configured verifier address to IZKVerifier and calls\nverify() through the interface, rather than depending on a concrete verifier type. The verifier\ncan be swapped without redeploying the game implementation.\nThe concrete deployment for the initial release uses Succinct's PLONK verifier for\nSP1.\nInterface\ninterface IZKVerifier is ISemver {\n function verifierType() external pure returns (string memory);\n\n function verify(\n bytes32 programId,\n bytes calldata publicValues,\n bytes calldata proof\n ) external view;\n}\n\nverifierType() returns a string identifying the proving system (e.g., \"SP1_PLONK\"). Callers\ncan use it to check which backend is deployed without inspecting the bytecode.\nParameterDescription\nprogramIdCorresponds to absolutePrestate() in the dispute game — identifies the ZK program version.\npublicValuesABI-encoded public inputs committed to by the proof (see Usage in prove()).\nproofThe raw proof blob submitted by the prover.\n\nThe verifier MUST revert on an invalid proof. A call that returns without reverting is treated as\nproof acceptance; the game will set claimData.prover = msg.sender and transition\nclaimData.status to UnchallengedAndValidProofProvided or ChallengedAndValidProofProvided.\nUsage in prove()\nZKDisputeGame.prove() constructs publicValues from on-chain game state and forwards them\nto the verifier:\nfunction prove(bytes calldata _proofBytes) external returns (ProposalStatus) {\n bytes memory publicValues = abi.encode(\n l1Head(),\n startingProposal.root,\n rootClaim(),\n l2SequenceNumber(),\n msg.sender\n );\n\n IZKVerifier(verifier()).verify(\n absolutePrestate(),\n publicValues,\n _proofBytes\n );\n\n // record proof submission and transition claimData.status\n}\n\nFieldSourceDescription\nl1HeadCWIA (immutable)L1 block hash captured at game creation. Authenticates all observed L1 data.\nstartingProposal.rootStorage (set in initialize)Super root hash of the parent game's claim, or the anchor state if parentIndex == type(uint32).max.\nrootClaimCWIA (immutable)Super root hash being asserted by this game.\nl2SequenceNumberCWIA (immutable)Super root timestamp corresponding to rootClaim.\nmsg.senderTransactionAddress of the prover. Binds the proof to the submitter, preventing front-running: a proof is generated for a specific address and cannot be re-submitted by a different address without regenerating the entire proof.\n\nAll public values come from immutable CWIA data or storage set during initialize(), so no\ncaller-supplied data beyond _proofBytes affects what the verifier checks. l1Head is captured\nas blockhash(block.number - 1) by DisputeGameFactory.create() and packed into the clone's\nCWIA data.\nChain scoping is provided by the SuperRootProof preimage committed to by rootClaim; the\n(chainId, outputRoot) pairs in that preimage cover every chain in the interop set (or a single\nentry in standalone deployments), so no separate l2ChainId field is needed in the public values.\nSee ZK Program Inputs for the full public values\nspecification.\nVerifier Upgrade Path\nThe verifier and absolutePrestate fields live in the CWIA game args (see\nCWIA Layout), so they can be updated per chain\nwithout redeploying the ZKDisputeGame implementation.\nUpgrade process:\n\nDeploy a new verifier contract.\nIf the ZK program changed, compute a new absolutePrestate.\nOPCM updates the game args with the new verifier and/or absolutePrestate.\nIn-progress games play out under the old configuration.\nNew games use the updated configuration.","tokens":924,"squid":"ink-governance","role":"Council Listener","at":1791262025143,"hash":"aa58508bab16811ff3577b1fe428f75704463132"}
{"url":"https://io.net/docs/guides/workers/bare-metal-on-demand-supplier-process","domain":"io.net","title":"Bare Metal On-Demand Supplier Process - io.net","text":"​Register Your Device\n\nInstall the latest version of the IO.NET Binary.\nUse the following command to launch the binary: /io_net_launch_binary_linux --device_id=DEVICE_ID --user_id=USER_ID --operating_system=\"Linux\" --usegpus=true --device_name=DEVICE_NAME --worker_mode=baremetal --worker_ip=HOST_IP --worker_port=HOST_PORT Replace DEVICE_ID and USER_ID with your specific identifiers.\n\n​When Your Device is Hired\n\nOnce your device is hired as a Bare Metal device:\n\nExemption: It is exempt from Proof of Work and Proof of Time Lock requirements, allowing you to earn block rewards even under the consumer’s control.\n\n​Post-Booking Requirements\n\nWipe the Device:\n\nYou have 24 hours to wipe the device and reinstall the binary after the booking period ends. Failure to do so will result in the cessation of block rewards for the device.\n\nReinstallation Steps:\n\nReinstall the IO.NET Binary.\n\nInform our Customer Support (CS) team by following these steps:\n\nSign in or create an account at the Support Portal.\n\nSubmit a support ticket with the following:\n\nIssue Type: “IO Worker”\nSubject: “Recycled the device(s)”\nDevice ID(s): List all recycled device IDs.\nDescription: Add “Recycled the device(s)” under the explanation field.\n\nSubmit the form.\n\n​Recommended Cleanup Steps\nActionStepsTerminate Active ProcessesPurpose: Ensure no data is in use or locked. Actions: Shut down applications, databases, and services. Stop all background tasks. Verification: Confirm no active processes remain using tools like ps or top.Unmount and Securely Wipe DrivesPurpose: Ensure no residual data is recoverable. Actions: Unmount filesystems using umount. Securely delete data using tools like shred, dd, or wipe. For SSDs, use the manufacturer’s secure erase utility.Reset RAID ConfigurationPurpose: Clear RAID metadata. Actions: Delete RAID arrays using mdadm or vendor utilities.Update FirmwarePurpose: Remove malicious firmware or backdoors. Actions: Update server firmware (BIOS/UEFI, BMC/iDRAC/iLO). Verification: Confirm firmware updates are applied.Reset ConfigurationPurpose: Restore server to factory defaults. Actions: Reset BIOS/UEFI and IPMI/iDRAC/iLO configurations, including passwords and network settings.Document the Cleaning ProcessPurpose: Maintain an audit trail. Actions: Record the commands and tools used. Attach logs for verification.Verify Clean StatePurpose: Ensure no residual data or configurations. Actions: Boot into a live environment (e.g., Ubuntu Live USB). Check that drives are unpartitioned and firmware is reset.Reinstall Base OSPurpose: Prepare the server for the next customer. Actions: Reinstall the requested base OS or leave it unformatted per customer requirements.Was this page helpful?","tokens":678,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791262026477,"hash":"f16d044df4cedafbdc6bf3f0b4572bf15df6ae7c"}
{"url":"https://specs.optimism.io/fault-proof/cannon-fault-proof-vm.html","domain":"specs.optimism.io","title":"Cannon Fault Proof VM - OP Stack Specification","text":"Multithreaded Cannon Fault Proof Virtual Machine\n\nTable of Contents\n\nOverview\n\nDefinitions\n\nConcepts\n\nNatural Alignment\n\nData types\nConstants\n\nNew Features\n\nMultithreading\n64-bit Architecture\nRobustness\n\nMultithreading\n\nThread Management\nThread Traversal Mechanics\n\nThread Preemption\n\nExited Threads\nFutex Operations\n\nWait\nWake\n\nVoluntary Preemption\nForced Preemption\n\nStateful Instructions\n\nLoad Linked / Store Conditional Word\nLoad Linked / Store Conditional Doubleword\n\nFPVM State\n\nState\nState Hash\nThread State\nThread Hash\nThread Stack Hashing\n\nMemory\n\nHeap\n\nmmap hints\n\nDelay Slots\nSyscalls\n\nSupported Syscalls\nNoop Syscalls\n\nI/O\n\nStandard Streams\nHint Communication\nPre-image Communication\n\nPre-image I/O Alignment\n\nExceptions\nSecurity Model\n\nCompiler Correctness\nCompiler Assumptions\n\nOverview\nThis is a description of the second iteration of the Cannon Fault Proof Virtual Machine (FPVM).\nWhen necessary to distinguish this version from the initial implementation,\nit can be referred to as Multithreaded Cannon (MTCannon). Similarly,\nthe original Cannon implementation can be referred to as Singlethreaded Cannon (STCannon) where necessary for clarity.\nThe MTCannon FPVM emulates a minimal uniprocessor Linux-based system running on big-endian 64-bit MIPS64 architecture.\nA lot of its behaviors are copied from Linux/MIPS with a few tweaks made for fault proofs.\nFor the rest of this doc, we refer to the MTCannon FPVM as simply the FPVM.\nOperationally, the FPVM is a state transition function. This state transition is referred to as a Step,\nthat executes a single instruction. We say the VM is a function , given an input state , steps on a\nsingle instruction encoded in the state to produce a new state .\n\nThus, the trace of a program executed by the FPVM is an ordered set of VM states.\nDefinitions\nConcepts\nNatural Alignment\nA memory address is said to be \"naturally aligned\" in the context of some data type\nif it is a multiple of that data type's byte size.\nFor example, the address of a 32-bit (4-byte) value is naturally aligned if it is a multiple of 4 (e.g. 0x1000, 0x1004).\nSimilarly, the address of a 64-bit (8-byte) value is naturally aligned if it is a multiple of 8 (e.g. 0x1000, 0x1008).\nA non-aligned address can be naturally aligned by dropping the least significant bits of the address:\naligned = unaligned & ^(byteSize - 1).\nFor example, to align the address 0x1002 targeting a 32-bit value:\naligned = 0x1002 & ^(0x3) = 0x1000.\nData types\n\nBoolean - An 8-bit boolean value equal to 0 (false) or 1 (true).\nHash - A 256-bit fixed-size value produced by the Keccak-256 cryptographic hash function.\nUInt8 - An 8-bit unsigned integer value.\nUInt64 - A 64-bit unsigned integer value.\nWord - A 64-bit value.\n\nConstants\n\nEBADF - A Linux error number indicating a bad file descriptor: 0x9.\nMaxWord - A Word with all bits set to 1: 0xFFFFFFFFFFFFFFFF.\nWhen interpreted as a signed value, this is equivalent to -1.\nProgramBreakAddress - The fixed memory address for the program break: Word(0x0000_4000_0000_0000).\nWordSize - The number of bytes in a Word (8).\n\nNew Features\nMultithreading\nMTCannon adds support for multithreading.\nThread management and scheduling are typically handled by the\noperating system (OS) kernel:\nprograms make thread-related requests to the OS kernel via syscalls.\nAs such, this implementation includes a few new Linux-specific thread-related syscalls.\nAdditionally, the FPVM state has been modified in order to track the set of active threads\nand thread-related global state.\n64-bit Architecture\nMTCannon emulates a MIPS64 machine whereas STCannon emulates a MIPS32 machine. The transition from MIPS32 to MIPS64\nmeans the address space goes from 32-bit to 64-bit, greatly expanding addressable memory.\nRobustness\nIn the initial implementation of Cannon, unrecognized syscalls were treated as\nnoops (see \"Noop Syscalls\"). To ensure no unexpected behaviors are triggered,\nMTCannon will now raise an exception if unrecognized syscalls are encountered during program execution.\nMultithreading\nThe MTCannon FPVM rotates between threads to provide\nmultitasking rather than\ntrue parallel processing.\nThe VM state holds an ordered set of thread state objects representing all executing threads.\nOn any given step, there is one active thread that will be processed.\nThread Management\nThe FPVM state contains two thread stacks that are used to represent the set of all threads: leftThreadStack and\nrightThreadStack. An additional boolean value (traverseRight) determines which stack contains the currently active\nthread and how threads are rearranged when the active thread is preempted (see \"Thread Preemption\"\nfor details).\nWhen traversing right, the thread on the top of the right stack is the active thread, the right stack is referred to as\nthe \"active\" stack,\nand the left the \"inactive\" stack. Conversely, when traversing left, the active thread is on top of the left stack,\nthe left stack is \"active\", and the right is \"inactive\".\nRepresenting the set of threads as two stacks allows for a succinct commitment to the contents of all threads.\nFor details, see “Thread Stack Hashing”.\nThread Traversal Mechanics\nThreads are traversed deterministically by moving from the first thread to the last thread,\nthen from the last thread to the first thread repeatedly. For example, given the set of threads: {0,1,2,3},\nthe FPVM would traverse to each as follows: 0, 1, 2, 3, 3, 2, 1, 0, 0, 1, 2, 3, 3, 2, ….\nThread Preemption\nThreads are traversed via \"preemption\": the currently active thread is popped from the active stack and pushed to the\ninactive stack. If the active stack is empty, the FPVM state's traverseRight field is flipped ensuring that\nthere is always an active thread.\nExited Threads\nWhen the VM encounters an active thread that has exited, it is popped from the active thread stack, removing it from\nthe VM state.\nFutex Operations\nThe VM supports futex syscall operations\nFUTEX_WAIT_PRIVATE and FUTEX_WAKE_PRIVATE.\nFutexes are commonly used to implement locks in user space.\nIn this scenario, a shared 32-bit value (the \"futex value\") represents the state of a lock.\nIf a thread cannot acquire the lock, it calls a futex wait, which puts the thread to sleep.\nTo release the lock, the owning thread updates the futex value and then calls a futex wake\nto notify any other waiting threads.\nBecause wake-ups may be spurious or could be triggered by unrelated operations on the same memory,\nwaiting threads must always re-check the futex value after waking up to decide if they can proceed.\nWait\nWhen a futex wait is successfully executed, the current thread is simply preempted.\nThis gives other threads a chance to run and potentially change the shared futex value (for example, by releasing a lock).\nWhen the thread is eventually scheduled again, if the futex value has not changed the wakeup will be considered spurious\nand the thread will simply call futex wait again.\nWake\nWhen a futex wake is executed, the current thread is preempted. This allows the scheduler to move\non to other threads which may potentially be ready to run (for example, because a shared lock was released).\nVoluntary Preemption\nIn addition to the futex syscall, there are a few other syscalls that\nwill cause a thread to be \"voluntarily\" preempted: sched_yield, nanosleep.\nForced Preemption\nTo avoid thread starvation (for example where a thread hogs resources by never executing a sleep, yield, wait, etc.),\nthe FPVM will force a context switch if the active thread has been executing too long.\nFor each step executed on a particular thread, the state field stepsSinceLastContextSwitch is incremented.\nWhen a thread is preempted, StepsSinceLastContextSwitch is reset to 0.\nIf StepsSinceLastContextSwitch reaches a maximum value (SchedQuantum = 100_000),\nthe FPVM preempts the active thread.\nStateful Instructions\nLoad Linked / Store Conditional Word\nThe Load Linked Word (ll) and Store Conditional Word (sc) instructions provide the low-level\nprimitives used to implement atomic read-modify-write (RMW) operations. A typical RMW sequence might play out as\nfollows:\n\nll places a \"reservation\" targeting a 32-bit value in memory and returns the current value at this location.\nSubsequent instructions take this value and perform some operation on it:\n\nFor example, maybe a counter variable is loaded and then incremented.\n\nsc is called and the modified value overwrites the original value in memory\nonly if the memory reservation is still intact.\n\nThis RMW sequence ensures that if another thread or process modifies a reserved value while\nan atomic update is being performed, the reservation will be invalidated and the atomic update will fail.\nPrior to MTCannon, we could be assured that no intervening process would modify such a reserved value because\nSTCannon is singlethreaded. With the introduction of multithreading, additional fields need to be stored in the\nFPVM state to track memory reservations initiated by ll operations.\nWhen an ll instruction is executed:\n\nllReservationStatus is set to 1.\nllAddress is set to the virtual memory address specified by ll.\nllOwnerThread is set to the threadID of the active thread.\n\nOnly a single memory reservation can be active at a given time - a new reservation will clear any previous reservation.\nWhen the VM writes any data to memory, these ll-related fields are checked and any existing memory reservation\nis cleared if a memory write touches the naturally-aligned Word that contains llAddress.\nWhen an sc instruction is executed, the operation will only succeed if:\n\nThe llReservationStatus field is equal to 1.\nThe active thread's threadID matches llOwnerThread.\nThe virtual address specified by sc matches llAddress.\n\nOn success, sc stores a value to the specified address after it is naturally aligned,\nclears the memory reservation by zeroing out llReservationStatus, llOwnerThread, and llAddress\nand returns 1.\nOn failure, sc returns 0.\nLoad Linked / Store Conditional Doubleword\nWith the transition to MIPS64, Load Linked Doubleword (lld), and Store Conditional Doubleword (scd) instructions\nare also now supported.\nThese instructions are similar to ll and sc, but they operate on 64-bit rather than 32-bit values.\nThe lld instruction functions similarly to ll, but the llReservationStatus is set to 2.\nThe scd instruction functions similarly to sc, but the llReservationStatus must be equal to 2\nfor the operation to succeed. In other words, an scd instruction must be preceded by a matching lld instruction\njust as the sc instruction must be preceded by a matching ll instruction if the store operation is to succeed.\nFPVM State\nState\nThe FPVM is a state transition function that operates on a state object consisting of the following fields:\n\nmemRoot - [Hash] A value representing the merkle root of VM memory.\npreimageKey - [Hash] The value of the last requested pre-image key.\npreimageOffset - [Word] The value of the last requested pre-image offset.\nheap - [Word] The base address of the most recent memory allocation via mmap.\nllReservationStatus - [UInt8] The current memory reservation status where: 0 means there is no\nreservation, 1 means an ll/sc-compatible reservation is active,\nand 2 means an lld/scd-compatible reservation is active.\nMemory is reserved via Load Linked Word (ll) and Load Linked Doubleword (lld) instructions.\nllAddress - [Word] If a memory reservation is active, the value of\nthe address specified by the last ll or lld instruction.\nOtherwise, set to 0.\nllOwnerThread - [Word] The id of the thread that initiated the current memory reservation\nor 0 if there is no active reservation.\nexitCode - [UInt8] The exit code value.\nexited - [Boolean] Indicates whether the VM has exited.\nstep - [UInt64] A step counter.\nstepsSinceLastContextSwitch - [UInt64] A step counter that tracks the number of steps executed on the current\nthread since the last preemption.\ntraverseRight - [Boolean] Indicates whether the currently active thread is on the left or right thread\nstack, as well as some details on thread traversal mechanics.\nSee \"Thread Traversal Mechanics\" for details.\nleftThreadStack - [Hash] A hash of the contents of the left thread stack.\nFor details, see the “Thread Stack Hashing” section.\nrightThreadStack - [Hash] A hash of the contents of the right thread stack.\nFor details, see the “Thread Stack Hashing” section.\nnextThreadID - [Word] The value defining the id to assign to the next thread that is created.\n\nThe state is represented by packing the above fields, in order, into a 188-byte buffer.\nState Hash\nThe state hash is computed by hashing the 188-byte state buffer with the Keccak256 hash function\nand then setting the high-order byte to the respective VM status.\nThe VM status can be derived from the state's exited and exitCode fields.\nenum VmStatus {\n Valid = 0,\n Invalid = 1,\n Panic = 2,\n Unfinished = 3,\n}\n\nfn vm_status(exit_code: u8, exited: bool) -> u8 {\n if exited {\n match exit_code {\n 0 => VmStatus::Valid,\n 1 => VmStatus::Invalid,\n _ => VmStatus::Panic,\n }\n } else {\n VmStatus::Unfinished\n }\n}\n\nThread State\nThe state of a single thread is tracked and represented by a thread state object consisting of the following fields:\n\nthreadID - [Word] A unique thread identifier.\nexitCode - [UInt8] The exit code value.\nexited - [Boolean] Indicates whether the thread has exited.\npc - [Word] The program counter.\nnextPC - [Word] The next program counter. Note that this value may not always be \nwhen executing a branch/jump delay slot.\nlo - [Word] The MIPS LO special register.\nhi - [Word] The MIPS HI special register.\nregisters - 32 general-purpose MIPS registers numbered 0 - 31. Each register contains a Word value.\n\nA thread is represented by packing the above fields, in order, into a 298-byte buffer.\nThread Hash\nA thread hash is computed by hashing the 298-byte thread state buffer with the Keccak256 hash function.\nThread Stack Hashing\n\nNote: The ++ operation represents concatenation of 2 byte string arguments\n\nEach thread stack is represented in the FPVM state by a \"hash onion\" construction using the Keccak256 hash\nfunction. This construction provides a succinct commitment to the contents of a thread stack using a single bytes32\nvalue:\n\nAn empty stack is represented by the value:\n\nc0 = hash(bytes32(0) ++ bytes32(0))\n\nTo push a thread to the stack, hash the concatenation of the current stack commitment with the thread hash:\n\npush(c0, el0) => c1 = hash(c0 ++ hash(el0)).\n\nTo push another thread:\n\npush(c1, el1) => c2 = hash(c1 ++ hash(el1)).\n\nTo pop an element from the stack, peel back the last hash (push) operation:\n\npop(c2) => c3 = c1\n\nTo prove the top value elTop on the stack, given some commitment c, you just need to reveal the bytes32\ncommitment c' for the stack without elTop and verify:\n\nc = hash(c' ++ hash(elTop))\n\nMemory\nMemory is represented as a binary merkle tree.\nThe tree has a fixed-depth of 59 levels, with leaf values of 32 bytes each.\nThis spans the full 64-bit address space, where each leaf contains the memory at that part of the tree.\nThe state memRoot represents the merkle root of the tree, reflecting the effects of memory writes.\nAs a result of this memory representation, all memory operations are WordSize-byte aligned.\nMemory access doesn't require any privileges. An instruction step can access any memory\nlocation as the entire address space is unprotected.\nHeap\nFPVM state contains a heap that tracks the base address of the most recent memory allocation.\nHeap pages are bump allocated at the page boundary, per mmap syscall.\nmmap-ing is purely to satisfy program runtimes that need the memory-pointer\nresult of the syscall to locate free memory. The page size is 4096.\nThe FPVM has a fixed program break at ProgramBreakAddress. However, the FPVM is permitted to extend the\nheap beyond this limit via mmap syscalls.\nFor simplicity, there are no memory protections against \"heap overruns\" against other memory segments.\nSuch VM steps are still considered valid state transitions.\nSpecification of memory mappings is outside the scope of this document as it is irrelevant to\nthe VM state. FPVM implementers may refer to the Linux/MIPS kernel for inspiration.\nmmap hints\nWhen a process issues an mmap(2) syscall with a non-NULL addr parameter, the FPVM honors this hint as a strict requirement\nrather than a suggestion. The VM unconditionally maps memory at exactly the requested address,\ncreating the mapping without performing address validity checks.\nThe VM does not validate whether the specified address range overlaps with existing mappings.\nAs this is a single-process execution environment, collision detection is delegated to userspace.\nThe calling process must track its own page mappings to avoid mapping conflicts, as the usual\nkernel protections against overlapping mappings are not implemented.\nDelay Slots\nThe post-state of a step updates the nextPC, indicating the instruction following the pc.\nHowever, in the case of where a branch instruction is being stepped, the nextPC post-state is\nset to the branch target. And the pc post-state set to the branch delay slot as usual.\nA VM state transition is invalid whenever the current instruction is a delay slot that is filled\nwith jump or branch type instruction.\nThat is, where while stepping on a jump/branch instruction.\nOtherwise, there would be two consecutive delay slots. While this is considered \"undefined\"\nbehavior in typical MIPS implementations, FPVM must raise an exception when stepping on such states.\nSyscalls\nSyscalls work similar to Linux/MIPS, including the\nsyscall calling conventions and general syscall handling behavior.\nHowever, the FPVM supports a subset of Linux/MIPS syscalls with slightly different behaviors.\nThese syscalls have identical syscall numbers and ABIs as Linux/MIPS.\nFor all of the following syscalls, an error is indicated by setting the return\nregister ($v0) to MaxWord and errno ($a3) is set accordingly.\nThe VM must not modify any register other than $v0 and $a3 during syscall handling.\nThe following tables summarize supported syscalls and their behaviors.\nIf an unsupported syscall is encountered, the VM will raise an exception.\nSupported Syscalls\n\n$v0system call$a0$a1$a2$a3Effect\n5009mmapuint64 addruint64 len🚫🚫Allocates a page from the heap. See heap for details.\n5012brk🚫🚫🚫🚫Returns a fixed address for the program break at ProgramBreakAddress\n5205exit_groupuint8 exit_code🚫🚫🚫Sets the exited and exitCode state fields to true and $a0 respectively.\n5000readuint64 fdchar *bufuint64 count🚫Similar behavior as Linux/MIPS with support for unaligned reads. See I/O for more details.\n5001writeuint64 fdchar *bufuint64 count🚫Similar behavior as Linux/MIPS with support for unaligned writes. See I/O for more details.\n5070fcntluint64 fdint64 cmd🚫🚫Similar behavior as Linux/MIPS. Only the F_GETFD(1) and F_GETFL (3) cmds are supported. Sets errno to 0x16 for all other commands.\n5055cloneuint64 flagsuint64 stack_ptr🚫🚫Creates a new thread based on the currently active thread's state. Supports a flags argument equal to 0x00050f00, other values cause the VM to exit with exit_code VmStatus.PANIC.\n5058exituint8 exit_code🚫🚫🚫Sets the active thread's exited and exitCode state fields to true and $a0 respectively.\n5023sched_yield🚫🚫🚫🚫Preempts the active thread and returns 0.\n5178gettid🚫🚫🚫🚫Returns the active thread's threadID field.\n5194futexuint64 addruint64 futex_opuint64 valuint64 *timeoutSupports futex_op's FUTEX_WAIT_PRIVATE (128) and FUTEX_WAKE_PRIVATE (129). Other operations set errno to 0x16.\n5002open🚫🚫🚫🚫Sets errno to EBADF.\n5034nanosleep🚫🚫🚫🚫Preempts the active thread and returns 0.\n5222clock_gettimeuint64 clock_iduint64 addr🚫🚫Supports clock_id's REALTIME(0) and MONOTONIC(1). For other clock_id's, sets errno to 0x16. Calculates a deterministic time value based on the state's step field and a constant HZ (10,000,000) where HZ represents the approximate clock rate (steps / second) of the FPVM:seconds = step/HZnsecs = (step % HZ) * 10^9/HZSeconds are set at memory address addr and nsecs are set at addr + WordSize.\n5038getpid🚫🚫🚫🚫Returns 0.\n5313getrandomchar *bufuint64 buflen🚫🚫Generates pseudorandom bytes and writes them to the buffer at buf. Uses splitmix64 seeded with the current step count. Returns the number of bytes written, which is at most buflen and limited by alignment boundaries.\n5284eventfd2uint64 initvalint64 flags🚫🚫Creates an eventfd file descriptor. Only non-blocking mode is supported: if flags does not include EFD_NONBLOCK (0x80), sets errno to 0x16. On success, returns file descriptor 100.\n\nNoop Syscalls\n\nFor the following noop syscalls, the VM must do nothing except to zero out the syscall return ($v0)\nand errno ($a3) registers.\n$v0system call\n5011munmap\n5010mprotect\n5196sched_get_affinity\n5027madvise\n5014rt_sigprocmask\n5129sigaltstack\n5013rt_sigaction\n5297prlimit64\n5003close\n5016pread64\n5004stat\n5005fstat\n5247openat\n5087readlink\n5257readlinkat\n5015ioctl\n5285epoll_create1\n5287pipe2\n5208epoll_ctl\n5272epoll_pwait\n5061uname\n5100getuid\n5102getgid\n5026mincore\n5225tgkill\n5095getrlimit\n5008lseek\n5036setitimer\n5216timer_create\n5217timer_settime\n5220timer_delete\n\nI/O\nThe VM does not support Linux open(2). However, the VM can read from and write to a predefined set of file descriptors.\nNameFile descriptorDescription\nstdin0read-only standard input stream.\nstdout1write-only standard output stream.\nstderr2write-only standard error stream.\nhint response3read-only. Used to read the status of pre-image hinting.\nhint request4write-only. Used to provide pre-image hints\npre-image response5read-only. Used to read pre-images.\npre-image request6write-only. Used to request pre-images.\neventfd100read-write. Created by eventfd2 syscall. Reads return EAGAIN. Writes return EAGAIN.\n\nSyscalls referencing unknown file descriptors fail with an EBADF errno as done on Linux.\nWriting to and reading from standard output, input and error streams have no effect on the FPVM state.\nFPVM implementations may use them for debugging purposes as long as I/O is stateless.\nAll I/O operations are restricted to a maximum of WordSize bytes per operation.\nAny read or write syscall request exceeding this limit will be truncated to WordSize bytes.\nConsequently, the return value of read/write syscalls is at most WordSize bytes,\nindicating the actual number of bytes read/written.\nStandard Streams\nWriting to stderr/stdout standard stream always succeeds with the write count input returned,\neffectively continuing execution without writing work.\nReading from stdin has no effect other than to return zero and errno set to 0, signalling that there is no input.\nHint Communication\nHint requests and responses have no effect on the VM state other than setting the $v0 return\nregister to the requested read/write count.\nVM implementations may utilize hints to setup subsequent pre-image requests.\nPre-image Communication\nThe preimageKey and preimageOffset state are updated via read/write syscalls to the pre-image\nread and write file descriptors (see I/O).\nThe preimageKey buffers the stream of bytes written to the pre-image write fd.\nThe preimageKey buffer is shifted to accommodate new bytes written to the end of it.\nA write also resets the preimageOffset to 0, indicating the intent to read a new pre-image.\nWhen handling pre-image reads, the preimageKey is used to lookup the pre-image data from an Oracle.\nA max WordSize-byte chunk of the pre-image at the preimageOffset is read to the specified address.\nEach read operation increases the preimageOffset by the number of bytes requested\n(truncated to WordSize bytes and subject to alignment constraints).\nPre-image I/O Alignment\nAs mentioned earlier in memory, all memory operations are WordSize-byte aligned.\nSince pre-image I/O occurs on memory, all pre-image I/O operations must strictly adhere to alignment boundaries.\nThis means the start and end of a read/write operation must fall within the same alignment boundary.\nIf an operation were to violate this, the input count of the read/write syscall must be\ntruncated such that the effective address of the last byte read/written matches the input effective address.\nThe VM must read/write the maximum amount of bytes possible without crossing the input address alignment boundary.\nFor example, the effect of a write request for a 3-byte aligned buffer must be exactly 3 bytes.\nIf the buffer is misaligned, then the VM may write less than 3 bytes depending on the size of the misalignment.\nExceptions\nThe FPVM may raise an exception rather than output a post-state to signal an invalid state\ntransition. Nominally, the FPVM must raise an exception in at least the following cases:\n\nInvalid instruction (either via an invalid opcode or an instruction referencing registers\noutside the general purpose registers).\nUnsupported syscall.\nPre-image read at an offset larger than the size of the pre-image.\nDelay slot contains branch/jump instruction types.\nInvalid thread state: the active thread stack is empty.\n\nVM implementations may raise an exception in other cases that is specific to the implementation.\nFor example, an on-chain FPVM that relies on pre-supplied merkle proofs for memory access may\nraise an exception if the supplied merkle proof does not match the pre-state memRoot.\nSecurity Model\nCompiler Correctness\nMTCannon is designed to prove the correctness of a particular state transition that emulates a MIPS64 machine.\nMTCannon does not guarantee that the MIPS64 instructions correctly implement the program that the user intends to prove.\nAs a result, MTCannon's use as a Fault Proof system inherently depends to some extent on the correctness of the compiler\nused to generate the MIPS64 instructions over which MTCannon operates.\nTo illustrate this concept, suppose that a user intends to prove simple program input + 1 = output.\nSuppose then that the user's compiler for this program contains a bug and errantly generates the MIPS instructions for a\nslightly different program input + 2 = output. Although MTCannon would correctly prove the operation of this compiled program,\nthe result proven would differ from the user's intent. MTCannon proves the MIPS state transition but makes no assertion about\nthe correctness of the translation between the user's high-level code and the resulting MIPS program.\nAs a consequence of the above, it is the responsibility of a program developer to develop tests that demonstrate that MTCannon\nis capable of proving their intended program correctly over a large number of possible inputs. Such tests defend against\nbugs in the user's compiler as well as ways in which the compiler may inadvertently break one of MTCannon's\nCompiler Assumptions. Users of Fault Proof systems are strongly encouraged to utilize multiple\nproof systems and/or compilers to mitigate the impact of errant behavior in any one toolchain.\nCompiler Assumptions\nMTCannon makes the simplifying assumption that users are utilizing compilers that do not rely on MIPS exception states for\nstandard program behavior. In other words, MTCannon generally assumes that the user's compiler generates spec-compliant\ninstructions that would not trigger an exception. Refer to Exceptions for a list of conditions that are\nexplicitly handled.\nCertain cases that would typically be asserted by a strict implementation of the MIPS64 specification are not handled by\nMTCannon as follows:\n\nadd, addi, and sub do not trigger an exception on signed integer overflow.\nInstruction encoding validation does not trigger an exception for fields that should be zero.\nMemory instructions do not trigger an exception when addresses are not naturally aligned.\n\nMany compilers, including the Golang compiler, will not generate code that would trigger these conditions under bug-free\noperation. Given the inherent reliance on Compiler Correctness in applications using MTCannon, the\ntests and defense mechanisms that must necessarily be employed by MTCannon users to protect their particular programs\nagainst compiler bugs should also suffice to surface bugs that would break these compiler assumptions. Stated simply, MTCannon\ncan rely on specific compiler behaviors because users inherently must employ safety nets to guard against compiler bugs.","tokens":7054,"squid":"ink-governance","role":"Council Listener","at":1791262035080,"hash":"faa2a1e639c0179e9b1c35646da1c5f701225db4"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/run-a-node/batch-poster","domain":"docs.arbitrum.io","title":"Run a batch poster | Arbitrum Docs","text":"✏️Request an updateTo learn how the batch-poster role relates to the other Nitro node roles, including its wallet requirements and the safety rules for running redundant posters, see How to assign roles to a Nitro node.\nThe batch poster uses the following default configuration flags and values:\nFlagDefault valueDescription--node.batch-poster.enablefalseEnables posting batches to L1--node.batch-poster.max-calldata-batch-size100000Maximum calldata batch size; replaces the deprecated --node.batch-poster.max-size. Default value is overwritten if it's an L3 (90000). For AnyTrust batches, use --node.da.anytrust.max-batch-size (default 1,000,000)--node.batch-poster.poll-interval10 secondsPeriod to wait after no batches are ready to be posted before checking again--node.batch-poster.error-delay10 secondsDelay time after error posting batch--node.batch-poster.compression-level11Batch compression level (Arbitrum uses Brotli compression which has compression levels from 1-11)--node.batch-poster.parent-chain-wallet.private-keynoneSets the private key of the parent chains wallet\nIf you created an L3 Arbitrum chain and generated your node config file for a full node, the only values for the batch poster that will be set are:\n\n--node.batch-poster.enable = true\n--node.batch-poster.max-calldata-batch-size = 90000\n--node.batch-poster.parent-chain-wallet.private-key = YOUR_PRIVATE_KEY\n\nIf you're the chain owner, using the Arbitrum Chain SDK to generate your config file is the best option.\nTo add a new batch poster, call the setIsBatchPoster(address,bool) method of the SequencerInbox contract on the parent chain:\ncast send --rpc-url $PARENT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY $SEQUENCER_INBOX_ADDRESS \"setIsBatchPoster(address,bool)()\" $NEW_BATCH_POSTER_ADDRESS true\nQueued transaction database selection​\nqueuedTxs are transactions that the sequencer has ordered and are ready to be posted:\n\nNoop: --node.batch-poster.data-poster.use-noop-storage\nRedis: --node.batch-poster.redis-url\nDB: --node.batch-poster.data-poster.use-db-storage\n\nYou can use only one database at a time, so you can't have both a Redis server and a DB in use simultaneously.\nnoteIf your parent chain is an Arbitrum chain or doesn't have a mempool, you can ignore this section. Noop storage is automatically chosen because batches post sequentially -- a new batch only posts after the previous transaction goes through. No database tracking for queued transactions is required.\nNoop​\nNoop storage does not store any queuedTxs. This is beneficial when the parent chain is an Arbitrum chain or one without a mempool, since the sequencer processes every transaction immediately and is never stuck in mempool limbo due to low gas.\nWhen Noop is enabled, the batch poster will wait for a confirmation that the transaction has gone through. If the transaction reverts, the batch poster will try again without halting the operation.\nThere is no Replace By Fee (RBF) logic, since that applies only to chains that use a mempool.\nDB​\nDB will store data locally on the node and support persistent queuedTxs. Only a single batch poster can use the DB. The DB supports RBF, so transactions will not get stuck in the parent chain's mempool. If a transaction is reverted, then the batch poster must halt.\nRedis​\nRedis is a fast local/external database that runs separately from the Nitro software so that node restarts preserve queuedTxs.\nStoring transactions also enables RBF, which can prevent transactions from being stuck in the mempool due to insufficient gas. However, using Redis means the batch poster will halt if a transaction reverts.\nTo configure Redis, you can also specify a redis-signer value with the flag --node.batch-poster.data-poster.redis-signer.signing-key.\nKey differences​\ninfoThe default values are DB on by default, and Noop on by default if and only if the parent chain does not have a mempool (any L3 whose parent is an Arbitrum chain).\nFeatureNoopDBRedisPersistenceNoneLocal diskExternal RedisSurvives restartsNoYesYesReplace-by-feeNoYesYesTolerates revertsYesNoNoWaits for receiptsYesNoNo\nEnable blob posting​\nThis section explains how to configure an Arbitrum node to post EIP-4844 blob transactions to the parent chain, which can significantly reduce data availability costs.\nPrerequisites​\nBefore enabling blob transactions, verify that your setup meets these requirements:\n\nChain configuration\nYour Arbitrum chain must be running in Rollup mode.\nParent chain compatibility\nYour parent chain (typically Ethereum mainnet or a testnet) must support EIP-4844. You can verify this by checking that recent block headers contain:\n\nExcessBlobGas field\nBlobGasUsed field\n\nArbOS version\n\nIf your version is below 20, upgrade by following the ArbOS upgrade guide.\n\nMethod 1: Smart contract call​\nCall the arbOSVersion() function on the ArbSys precompile contract:\n\nContract address: 0x0000000000000000000000000000000000000064\nFunction: arbOSVersion() returns uint256\nYou can call this using any Ethereum client or block explorer on your Arbitrum chain\n\nMethod 2: Using cast (if you have Foundry installed)​\ncast call 0x0000000000000000000000000000000000000064 \"arbOSVersion()\" --rpc-url YOUR_ARBITRUM_RPC_URL\nIf your version is below ArbOS 20, upgrade by following the ArbOS upgrade guide.\nConfiguration​\n\nTo enable blob transaction posting, add the following configuration to your node:\n\n{ \"node\": { \"batch-poster\": { \"post-4844-blobs\": true } }, \"parent-chain\": { \"blob-client\": { \"beacon-url\": \"YOUR_BEACON_URL\" } }}\n\nAfter updating your configuration:\n\nSave the configuration file.\nRestart your Arbitrum node.\nMonitor the logs to confirm blob posting is active.\n\nVerification​\n\nOnce restarted, you can verify that blob transactions are being posted successfully by monitoring your node logs.\n\nLog message to look for​\n\nWhen a blob transaction is successfully posted, you'll see a log entry similar to:\n\nINFO [05-23|00:49:16.160] BatchPoster: batch sent sequenceNumber=6 from=24to=28 prevDelayed=13 currentDelayed=14 totalSegments=9numBlobs=1\n\nKey indicator: The numBlobs field shows the number of blobs included in the transaction.\n\nnumBlobs=0: Traditional calldata transaction was posted\nnumbBlobs>0: Blob transaction was successfully posted (in the example above, a single blob was sent)\n\nTroubleshooting​\nWhy is my node still posting calldata instead of blobs?​\n\nYour node may continue using calldata in these scenarios:\n\nCost optimization: When blob gas prices are high, calldata posting may be more economical; you can set --node.batch-poster.ignore-blob-price flag to true to force the batch poster to use blobs.\nBatch type switching protection: After a non-blob transaction is posted, the following 16 transactions will also use calldata to prevent frequent switching.\n\nCheck your node logs for blob-related error messages and verify that your parent chain is accessible and fully synced.\n\nOptional parameters​\n\nYou can also set the following optional parameters to control blob posting behavior:\n\nFlagDescription--node.batch-poster.ignore-blob-priceBoolean. Default: false. If the parent chain supports EIP-4844 blobs and ignore-blob-price is set to true, the batch poster will use EIP-4844 blobs even if using calldata is cheaper. Can be true or false.--parent-chain.blob-client.authorizationString. Default: \"\". Value to send with the HTTP Authorization: header for Beacon REST requests, must include both scheme and scheme parameters.--parent-chain.blob-client.secondary-beacon-urlString. Default: \"\". A secondary Beacon REST endpoint URL to use as a fallback.--node.batch-poster.data-poster.blob-tx-replacement-timesdurationSlice. Default: [5m0s, 10m0s, 30m0s,1h0m0s,4h0m0s,8h0m0s,16h0m0s,22h0m0s]. Comma-separated list of durations since first posting a blob transaction to attempt a replace-by-fee.--node.batch-poster.data-poster.max-blob-tx-tip-cap-gweiFloat. Default: 1. The maximum tip cap to post EIP-4844 blob-carrying transactions at.--node.batch-poster.data-poster.min-blob-tx-tip-cap-gweiFloat. Default: 1. The minimum tip cap to post EIP-4844 blob-carrying transactions at.\nBatch poster revenue config​\nTo change revenue configurations for a batch poster, first check the list of current registered batch posters through the ArbAggregator precompile by calling getBatchPosters()(address[]):\ncast call --rpc-url $ARB_CHAIN_RPC 0x000000000000000000000000000000000000006D \"getBatchPosters() (address[])\"\nWhile there are other ways to get the list of batch posters for an Arbitrum chain, this method only lists batch posters who are registered by ArbAggregator.addBatchPoster() or have posted at least a single batch, which is better for revenue reasons.\nOnce you have the batch poster address, you can obtain the fee collector address for that batch poster using the getFeeCollector(address)(address) from the ArbAggregator precompile.\ncast call --rpc-url $ORBIT_CHAIN_RPC 0x000000000000000000000000000000000000006D \"getFeeCollector(address) (address)\" $BATCH_POSTER_ADDRESS\nYou can also use the Arbitrum Chain SDK:\nconst orbitChainClient = createPublicClient({ chain: <OrbitChainDefinition>, transport: http(),}).extend(arbAggregatorActions);const networkFeeAccount = await orbitChainClient.arbAggregatorReadContract({ functionName: 'getFeeCollector', args: [<BatchPosterAddress>],});\nnoteBefore setting a fee collector for a batch poster, ensure the batch poster is registered in the BatchPostersTable. This can be achieved by:\nManually calling ArbAggregator.addBatchPoster() for the address, or\nThe address has been successfully posted for at least one batch\nTo set a new fee collector for a specific batch poster, use the method setFeeCollector(address, address) of the ArbAggregator precompile:cast send --rpc-url $ORBIT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x000000000000000000000000000000000000006D \"setFeeCollector(address,address) ()\" $BATCH_POSTER_ADDRESS $NEW_FEECOLLECTOR_ADDRESSYou can also do this with the Arbitrum Chain SDK:const owner = privateKeyToAccount(<OwnerPrivateKey>);const orbitChainClient = createPublicClient({ chain: <OrbitChainDefinition>, transport: http(),}).extend(arbAggregatorActions);const transactionRequest = await orbitChainClient.arbAggregatorPrepareTransactionRequest({ functionName: 'setFeeCollector', args: [<BatchPosterAddress>, <NewFeeCollectorAddress>], upgradeExecutor: false, account: owner.address,});await orbitChainClient.sendRawTransaction({ serializedTransaction: await owner.signTransaction(transactionRequest),});\nTo add a new batch poster, call the setIsBatchPoster(address,bool) method of the SequencerInbox contract on the parent chain:\ncast send --rpc-url $PARENT_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY $SEQUENCER_INBOX_ADDRESS \"setIsBatchPoster(address,bool) ()\" $NEW_BATCH_POSTER_ADDRESS true\nSetting revenue values​\nnoteThese values are only editable by the chain owner(s).\nThere are onchain values in ArbOS that set how much ArbOS changes per L1 gas spent on transaction data. This can be set by communicating with the ArbOwner precompile.\ncast send --rpc-url $ARB_CHAIN_RPC --private-key $OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setL1PricingRewardRate(uint64) ()\" NEW_L1_PRICING_REWARD\nAlong with setPerBatchGasCharge(), which sets the base charge (in L1 gas) attributed to each data batch in the calldata pricer. This can be called with:\ncast send --rpc-url ARB_CHAIN_RPC --private-key OWNER_PRIVATE_KEY 0x0000000000000000000000000000000000000070 \"setPerBatchGasCharge(int64) ()\" NEW_BATCH_GAS_CHARGE\nBatch poster interval config​\nThe batch poster has a max delay, primarily set by --node.batch-poster.max-delay parameter in the Nitro node configuration (set via the JSON config file or command-line flags when deploying an Arbitrum chain). It defines the maximum amount of time the batch poster will wait after receiving a transaction before posting a batch that includes it. The default value is one hour (3600 seconds):\n\nConfiguration options: In the node.batch-poster section of the config, e.g., \"max-delay\": \"30m\" for a 30-minute maximum wait. Lower values increase batch posting frequency, but at the cost of potentially smaller, less efficient batches during periods of low activity, which increases gas costs on the parent chain. If there are no transactions in a batch, then this setting does not apply.\nPrevention of issues: A shorter max delay reduces the opportunity for transaction reordering in the sequencer by requiring shorter waits. It also limits exposure to chain reorgs, since batches post sooner, which anchors them to the parent chain before potential fluctuations can invalidate sequencing. Extremely low posting times aren't recommended, as spamming the parent chain with batches increases costs without providing any benefit.\nRecommended settings: For high-throughput chains, set to 5-15 minutes to balance latency and efficiency. For low-activity chains, keep the value of one hour.\n\nThe batch poster also has a --node.batch-poster.max-calldata-batch-size parameter (which replaces the deprecated --node.batch-poster.max-size) represented in bytes. It is the maximum size a calldata batch can be. If the total queued transactions compression estimate exceeds the max size, the batch poster will post the max size of transactions to the L1. The default value is 100000 bytes. On AnyTrust chains, the maximum size of batches sent to the DAC is controlled separately by --node.da.anytrust.max-batch-size (default 1,000,000 bytes).\nLower values will result in increased frequency of batch posting during high activity. And because Brotli compression is lossy, smaller batch files almost always result in suboptimal compression compared to larger files. which means the gas price will be higher overall for two smaller batches than for one larger batch, assuming the two smaller batches contain the same transactions as the one larger batch. Calldata and blob posting have an upper limit, so raising this value too high can cause issues, while lowering it can lead to inefficient compression and batch spamming on high-activity chains. The recommended value is 100,000 bytes.Queued transaction database selectionNoopDBRedisEnable blob postingPrerequisitesTroubleshootingOptional parametersBatch poster revenue configSetting revenue valuesBatch poster interval config","tokens":3576,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262035530,"hash":"32b820c7cbc8b585e21117bcb4ed5982a85d428c"}
{"url":"https://governance.aave.com/t/temp-check-deploy-aave-v4-on-avalanche/24981/8","domain":"governance.aave.com","title":"[Temp Check] Deploy Aave V4 on Avalanche - Governance / New Market - Aave","text":"GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 4\n min\n\n May 27\n\n 8 / 8\n\n Aug 27\n\n Aug 28\n\n post by AaveLabs on May 27\n\n post by simo on May 27\n\n post by MconnectDAO on May 27\n\n post by Mschmenk13 on May 31\n\n post by AaveLabs on Jun 3\n\n post by Abel189 on Jun 4\n\n Abel189\n\n Generally supportive of exploring an Aave V4 deployment on Avalanche.\nFrom a strategic perspective, this feels different from a typical expansion proposal because Aave already has an existing user base and liquidity footprint on Avalanche. The combination of an established market, dedicated ecosystem support, and a proposed RWA hub could provide a meaningful environment to validate V4 growth outside Ethereum.\nThat said, I would like to see more detail in the ARFC regarding expected protocol economics. In particular:\n\nHow will success be measured beyond TVL growth?\n\nWhat revenue targets or utilization metrics are expected from the deployment?\n\nHow are the $15M incentives structured, and how closely are they aligned with sustainable borrowing activity rather than short-term liquidity mining?\n\nWhat differentiates the proposed Avalanche RWA hub from RWAs deployed on other Aave V4 markets?\n\nOverall, the direction appears sensible, but understanding the expected long-term revenue contribution to the DAO will be important when evaluating the final proposal.\n\n post by CalBlockchain on Jun 5\n\n CalBlockchain\n\n Supportive of this deployment. Both Aave v2 and v3 have been cornerstone protocols for Avalanche with proven success and still maintains sticky capital and users. Both parties would benefit greatly from a v4 deployment on the network.\nThat said, we echo the same points made by previous replies. More transparency on the structure, duration, the said milestones, and sustainability of the mentioned incentive program would be appreciated.\n\n 3 months later\n\n post by evan_chevalier on Aug 28\n\n evan_chevalier\n\n how this can be integrated within a layer2 blockchain\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d\n\n [Temp Check] Deploy Aave V4 on Arc\n\n New Market\n\n 5\n\n 837\n\n Jun 7\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d","tokens":616,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262041335,"hash":"7aad2b489f5412744481acad2ca047924bf0f8f5"}
{"url":"https://specs.optimism.io/protocol/subblocks.html","domain":"specs.optimism.io","title":"Subblocks - OP Stack Specification","text":"Subblocks\n\nTable of Contents\n\nOverview\nConsumer guarantees\nWebSocket stream\n\nOrdering\nPayload\nZero-valued fields\n\nPost-execution transactions\nJSON-RPC\nTransaction inclusion\nBackwards compatibility\n\nOverview\nSubblocks are partial blocks that an OP Stack sequencer streams while it is building an L2 block. Each subblock adds\ntransactions to the in-progress block, giving consumers a preconfirmation before the block is sealed and propagated\nthrough the normal OP Stack protocol.\nSubblocks do not change the validity or finality rules of the OP Stack. They only expose the sequencer's in-progress\nview sooner. A subblock therefore carries the same trust assumption as an unsafe block: its preconfirmations may be\nrevoked if the sequencer abandons or reorganizes the in-progress block.\nThe interval between subblocks is chain-configurable and is a target rather than a guarantee. It is typically much\nshorter than the L2 block time.\nConsumer guarantees\nWithin one in-progress block, subblocks are append-only:\n\nThe first subblock has index 0; subsequent subblocks increment the index by one.\nAll subblocks for the in-progress block have the same payload_id and block number.\nThe sequencer MUST NOT publish distinct subblocks with the same payload_id and index.\nTransactions from each subblock are appended in stream order. A consumer obtains the in-progress transaction list by\nconcatenating each subblock's diff.transactions. That list excludes the block's\npost-execution transaction.\nThe cumulative in-progress block after each subblock MUST satisfy all applicable OP Stack execution rules.\nThe first subblock contains the block's deposited transactions and any other\nsequencer transactions that execute before mempool transactions. Later subblocks add mempool transactions.\n\nIf the sequencer abandons the in-progress block, a new in-progress block starting at index 0 supersedes it. Consumers\nMUST NOT treat a subblock as safe or final chain data.\nWebSocket stream\nThe sequencer publishes subblocks through a WebSocket endpoint. Each WebSocket text frame contains one JSON Subblock\nobject, as defined below. Field names use snake_case; byte strings, addresses, hashes, transactions, and quantities\nuse their standard Ethereum JSON encodings unless stated otherwise below.\nThe JSON shape deliberately retains Flashblocks-era names and fields for wire compatibility.\nOrdering\nThe first Subblock for an in-progress block has index equal to 0 and includes base. Each subsequent Subblock\nincrements index by one and omits base. The payload_id, base, and metadata.block_number identify the\nin-progress L2 block.\nA consumer joining the stream after index 0 cannot reconstruct the complete in-progress block. It SHOULD ignore\nsubblocks until it receives the next index 0. A consumer SHOULD also discard its reconstruction of the in-progress\nblock if an index is skipped, duplicated, or paired with a different payload ID or block number.\nPayload\nA subblock has the following shape. Optional fields are omitted when they do not apply.\nSubblock {\n payload_id: Bytes8\n index: uint64\n base: Optional[SubblockBase]\n diff: SubblockDelta\n metadata: Metadata\n}\n\nSubblockBase {\n parent_beacon_block_root: Bytes32\n parent_hash: Bytes32\n fee_recipient: Bytes20\n prev_randao: Bytes32\n block_number: uint64\n gas_limit: uint64\n timestamp: uint64\n extra_data: Bytes\n base_fee_per_gas: uint256\n}\n\nSubblockDelta {\n state_root: Bytes32\n receipts_root: Bytes32\n logs_bloom: Bytes256\n gas_used: uint64\n block_hash: Bytes32\n transactions: List[Bytes]\n withdrawals: List[WithdrawalV1]\n withdrawals_root: Bytes32\n blob_gas_used: Optional[uint64]\n post_exec_tx: Optional[Bytes]\n}\n\nMetadata {\n block_number: uint64\n new_account_balances: Map[Bytes20, uint256]\n receipts: Map[Bytes32, Receipt]\n}\n\nWithdrawalV1 is the Ethereum Engine API's EIP-4895\nWithdrawalV1\nobject. This field is retained for legacy wire compatibility and MUST be empty; it does not encode OP Stack L2-to-L1\nwithdrawals.\nReceipt is the standard Ethereum transaction receipt described in the glossary, including\nany OP Stack receipt extensions active for the block.\nThe fields have the following semantics:\n\npayload_id identifies one payload build and is constant for all subblocks of the in-progress block.\nindex is a JSON number identifying the subblock's position within the in-progress block.\nbase contains immutable block properties and is present only at index 0.\ndiff.transactions contains only the EIP-2718 encoded transactions added by this subblock. It never contains a\npost-execution (0x7D) transaction; see Post-execution transactions below.\ndiff.gas_used, diff.receipts_root, and diff.logs_bloom describe the cumulative in-progress block after applying\nthis subblock.\ndiff.blob_gas_used, when present, is the cumulative DA footprint\nof the in-progress block, not L2 blob gas usage.\nFrom the Lagoon network upgrade, diff.post_exec_tx, when present, is the latest\npost-execution transaction of the in-progress block. It is carried separately from\ndiff.transactions; see Post-execution transactions below.\nmetadata.block_number is the L2 block number encoded as a JSON number.\nmetadata.new_account_balances maps changed accounts to their latest balances.\nmetadata.receipts maps transaction hashes to the receipts for transactions added by this subblock. Because a\npost-execution transaction is never one of them, it never has a receipt here.\n\nZero-valued fields\nSubblock payloads set these four diff fields to their zero values:\nFieldRequired value\nstate_root0x0000000000000000000000000000000000000000000000000000000000000000\nblock_hash0x0000000000000000000000000000000000000000000000000000000000000000\nwithdrawals_root0x0000000000000000000000000000000000000000000000000000000000000000\nwithdrawals[]\n\nThese fields remain on the wire only for backwards compatibility. Consumers MUST treat them as unavailable and MUST\nNOT use them as commitments to the in-progress block or state. In particular, a zero state_root or block_hash is\nnot the value of the eventual sealed block.\nA consumer that needs the in-progress state may reconstruct it by executing the streamed transactions against the\nparent state. The subblock stream does not indicate whether the in-progress block was sealed or abandoned. Consumers\nobtain the sealed block's authoritative state root and block hash through normal L2 block propagation.\nPost-execution transactions\nFrom the Lagoon network upgrade, a block may end with a\npost-execution transaction of type 0x7D. A subblock carries it as diff.post_exec_tx,\nholding its EIP-2718 encoding, and never as a member of diff.transactions. Unlike diff.transactions, the field is\nmutable: the sequencer recomputes it as it extends the in-progress block.\nLagoon post-exec.md § Subblocks specifies the behavior normatively — why the\nfield lives in diff, when it is absent, which subblock's value is canonical, that transactions may be empty, and\nwhy no receipt is streamed for it — each with its rationale and what a consumer may assume.\nJSON-RPC\nApplications may consume subblocks via a subblock-aware RPC node instead of subscribing to the stream directly.\nThe node executes the streamed transactions and exposes the resulting state through standard Ethereum JSON-RPC\nmethods. No subblock-specific RPC method is required.\nThe following methods use subblock state when called with the pending block tag:\n\neth_call\neth_estimateGas\neth_getBalance\neth_getBlockByNumber\neth_getCode\neth_getStorageAt\neth_getTransactionCount\n\nSuccessive eth_getBlockByNumber(\"pending\", ...) calls during the same L2 block may return an expanding transaction\nlist as new subblocks arrive.\nMethods that identify a transaction directly, including eth_getTransactionByHash and\neth_getTransactionReceipt, may also return preconfirmed subblock transactions. Their responses\nuse the standard Ethereum JSON-RPC shapes, but block-derived fields are provisional until the block is sealed.\nTransaction inclusion\nSubblocks divide a block's gas capacity across the block-building window. The amount of gas available for inclusion\nincreases as the block progresses. Consequently, a large transaction may be accepted into the transaction pool but\nremain pending until a later subblock with enough remaining gas capacity. If earlier transactions consume too much of\nthe block gas limit, the transaction remains pending for a later block.\nApplications SHOULD NOT assume that a transaction with a gas limit below the full block gas limit can be included in\nthe next subblock.\nBackwards compatibility\nSubblocks are the backwards-compatible successor to Flashblocks. The WebSocket wire format remains compatible with the\nlegacy Flashblocks wire format, and JSON-RPC\nbehavior is unchanged, so existing consumers can continue to decode the stream.\nThe compatibility exception is that subblocks always zero state_root, block_hash, withdrawals_root, and\nwithdrawals as specified above. A Flashblocks consumer that treated any of those fields as authoritative MUST be\nupdated before consuming subblocks. Other consumers can migrate without changing their wire decoder.","tokens":2269,"squid":"ink-governance","role":"Council Listener","at":1791262045006,"hash":"4e1c599a4e997ffed542f18e5270881e29832281"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/overview/faq","domain":"docs.arbitrum.io","title":"Arbitrum chain FAQ | Arbitrum Docs","text":"✏️Request an update\nCan I use the Chain SDK to deploy a mainnet chain?​\nYes! The Arbitrum Chain SDK's core technology has undergone a comprehensive audit and is now capable of supporting deployments to mainnet. You can read more about it in our preview expectations notice.\nLearn more: Chain SDK introduction.\nDo I need permission/license to launch an Arbitrum chain?​\nYou can launch any Arbitrum chain permissionlessly.\nNitro's license is under a Business Source license, similar to DeFi protocols like Uniswap and Aave, among others. This license contains an Additional Use Grant that permits the permissionless deployment of Nitro software on blockchains that settle to Arbitrum One or Nova.\nHowever, Arbitrum chains that settle to a parent chain other than Arbitrum One or Nova are subject to additional licensing guidelines under the AEP.\nLearn more: AEP license.\nDoes Arbitrum officially deploy and/or maintain L3s for external teams?​\nNo. Teams are required to deploy and maintain their Arbitrum chains. There are, however, several RaaS (Rollup as a Service) providers that can deploy and maintain your Arbitrum chain on your behalf.\nLearn more: Third-party providers.\nCan I modify the underlying technology to customize my Arbitrum chain?​\nYes, you can make any changes you require to the underlying Nitro code base.\nLearn more: Customize the State Transition Function.\nWhat Data Availability (DA) solutions are currently available for Arbitrum chains?​\nArbitrum chains currently support three different DA solutions:\n\nRollup, posting data to the parent chain, which ultimately posts the data to Ethereum.\nAnyTrust, posting data to a Data Availability Committee, selected by the chain owner.\nCelestia, posting data to the Celestia network.\nNote that using AnyTrust provides the chain owner with the most flexibility and the most cost-effective fees.\n\nLearn more: Configure data availability.\nWhat token is used to pay gas fees on Arbitrum chains?​\nBy default, Arbitrum chains pay gas in ETH. However, Arbitrum chains that use AnyTrust are configurable to use any ERC-20 token for the gas fee token of the chain.\nLearn more: Choose a custom gas token.\nCan I use Ethereum toolkits to develop on my Arbitrum chain?​\nArbitrum chains are fully EVM-compatible. Most tools that support Ethereum should be able to support an Arbitrum chain. There are, however, specific differences that developers need to consider when building on an Arbitrum chain. You can find them in our overview of the differences between Arbitrum and Ethereum.\nDo Arbitrum chains have any built-in AA solution?​\nNo, but ZeroDev is heavily tested, easy to use and to integrate.\nLearn more: ZeroDev smart account integration.\nIs there any cross-chain bridging solution between two Arbitrum chains?​\nThere is currently no native Arbitrum-to-Arbitrum chain bridging solution, except for going through the parent chain (even if they share the same parent chain). However, many third-party bridges have expressed interest in supporting Arbitrum chains.\nLearn more: Cross-chain messaging.\nIs there an official block explorer for Arbitrum chains?​\nArbitrum chains deployments usually come with an open-source Blockscout explorer by default, but there are many third-party solutions that have expressed interest in supporting Arbitrum chains.\nLearn more: Monitoring tools and block explorers.\nIs there any indexing solution that supports Arbitrum chains?​\nSimilar to bridges and block explorers, there are many third-party indexing solutions that have expressed interest in supporting Arbitrum chains.\nLearn more: The Graph.\nCan I increase the maximum contract size for my Arbitrum chain?​\nYes, Arbitrum chains support an increased smart contract size limit of up to 96kB. You can use our Chain SDK and configure the parameters MaxCodeSize and MaxInitCodeSize when calling prepareNodeConfig. Once deployed, you cannot change the parameters for the smart contract size limit through an upgrade.\nFor more information refer to the Smart contract size limit page\nHow can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism?​\nForcing an invalid assertion in the chain is not currently supported. However, if you're building Nitro locally, you can run the following test that goes through the whole rollup/challenge mechanism:\ngo test ./system_tests/ -tags=challengetest -run=TestChallenge\nWhat fee collectors can be configured on my chain?​\nFour fee types are configurable on an Arbitrum chain:\n\nL2 base fee: L2 execution fees corresponding to the minimum base price of the chain. This fee is deposited into the infraFeeAccount, which can be set by calling ArbOwner.setInfraFeeAccount().\nL2 surplus fee: L2 execution fees above the minimum base price (in the case of congestion). This fee goes to the networkFeeAccount, which can be set by calling ArbOwner.setNetworkFeeAccount().\nL1 base fee: Relative fees for posting a transaction on the parent chain. This fee is paid ultimately to the fee collector of the active batch poster. A call to SequencerInbox.setIsBatchPoster() on the parent chain will set the batch poster. Delegating a different fee collector for that batch poster can be specified by calling ArbAggregator.setFeeCollector().\nL1 surplus fee: Any extra fees rewarded to the batch poster. This is paid to a specific L1RewardRecipient, which can be set by calling ArbOwner.setL1PricingRewardRecipient().\nFor more detailed information about fees, please refer to the L1 Fees and L2 Fees pages.\n\nTo learn more about precompiles, refer to the Precompiles reference page.\nLearn more: Fee management.\nWhat is the lowest you can set the base fee to?​\nYou can set the base fee to any amount to charge users less. You can even set it to 0 (however, this would open the chain to DOS attacks). If the Arbitrum chain base fee is 0, users are then only paying for the cost of DA.\nLearn more: Gas and fees deep dive.\nHow does fee collection work in Nitro?​\nFour fee types are configurable on Nitro:\n\nL2 base fee: L2 execution fees corresponding to the minimum base price of the chain. This is paid to the infraFeeAccount, and you can set it by calling ArbOwner.setInfraFeeAccount().\n\nL2 surplus fee: L2 execution fees above the minimum base price (in the case of congestion). This is paid to the networkFeeAccount, and you can set it by calling ArbOwner.setNetworkFeeAccount().\n\nL1 base fee: Relative fees for posting this transaction on the parent chain. This is paid ultimately to the fee collector of the active batch poster. You can set the batch poster by calling SequencerInbox.setIsBatchPoster(), on the parent chain, and specify a different fee collector for that batch poster by calling ArbAggregator.setFeeCollector().\n\nL1 surplus fee: Any extra fees rewarded to the batch poster. This is paid to a specific L1RewardRecipient, and you can set it by calling ArbOwner.setL1PricingRewardRecipient()\nYou can find more detailed information about fees in these pages:\n\nL1 fees\n\nL2 fees\n\nAnd information about the precompiles methods in the Precompile References.\nLearn more: Gas and fees deep dive.\nCan you upgrade the smart contract size limit once deployed?​\nNo. There's no way to version it so that old blocks are executed under the past limit and new blocks are executed for the new limit.\nCan you set the block speed below 100ms?​\nThe implications of reducing the block speed below 100ms are that an increased block count will put more strain on third-party providers, node runners, indexers, etc.\nLearn more: Sequencer timing adjustments.\nCan I set fast deposits for an L3?​\nYes, we have documented fast deposits in how to configure delayed inbox finality.\nThere is a flag that can be changed, which allows an Arbitrum chain to wait for finality on the parent chain before depositing a transaction.\nFor an L3 on Arb One, for example, we consider this a feature because they can instantly register a deposit on the child chain, as Arbitrum One has an ultra-low re-org risk (having never re-organized).\nFor an L2, however, we recommend waiting ~12 minutes for L1 finality, as there is a greater risk of reorganization, for example, the deposit transaction not being included immediately in the fork-choice.\nHow do I increase the max transaction data size?​\nWarning: Always test first!!!\nTest this thoroughly on a testnet first.\n\nThis is a hard limit in the codebase to prevent DoS attacks. If you want to modify this, you'll need to follow this procedure to create a new WASM module root with an updated max L2 message size. Other limits might also need to be updated, such as the maximum decompressed batch size. Be sure to modify everything starting with the latest version, which includes a couple of extra safety checks that may help prevent issues.\nYou could disable this limit if you were confident you would stick to AnyTrust and not need to fall back to posting data onchain.\nDefaults are in place for non-AnyTrust batch posting, which would need to fit the L3 user's transaction into a batch posted as an L2 transaction, thus respecting L2 transaction size limits.\n\nWhat is the max theoretical TPS for an Arbitrum Chain?​\nMax TPS is a challenging metric to measure, as it relies on network activity and the type of submitted transactions. We can, however, calculate the max throughput using default Arbitrum chain parameters.\nThe actual maximum throughput depends on the configurable execution parameters:\nUsing standard Arbitrum chain defaults\n\nBlock time: 250ms\n\nBlock gas limit: 32M L2 gas\n\nMax L2 gas per second: 128M gas/sec\n\nThese parameters are entirely configurable, for example, by dropping the block time to 100ms or by increasing the block gas limit (which comes at the cost of faster state bloat).\n\nDropping to 100ms and doubling the block gas limit to 64m L2 gas would achieve 640m L2 gas per second.\nThe actual TPS varies depending on the gas cost per transaction:\n\nA simple transfer (~21,000 gas) could approximately achieve around 6,000 TPS.\n\nA more complex transaction (~200,000 gas) would enable approximately 640 TPS.\n\nWhy is the WETH Gateway not necessary for custom gas token chains?​\nThe WETH gateway used in the token bridge is a special, custom gateway that unwraps the **WETH **deposits and sends them to the Arbitrum chain, then wraps them again on the Arbitrum chain. Since ETH is the gas token in the Arbitrum chain, there's no need to perform this operation, so you can use a standard ERC-20 for WETH (this is the default case of the token bridge so that you wouldn't need a special WETH gateway).\nIf you want to enable extra custom operations with WETH, you can create a custom token and a custom gateway to handle this case.\nLearn more: Choose a custom gas token.\nHow do we verify if an ERC-20 was bridged using the native bridge?​\nThe following applies to a parent-side bridge deployed on Arbitrum One:\nIf the token was bridged using the native token bridge, you can go to parent_side_bridge_contract\nCall the calculateL2TokenAddress address with the address of the token on the parent chain.\nFor example, in the case of plugging in the ERC-20 address on Arbitrum One 0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9, you get 0xB2C565cd7e807e6A1C38bFE32D8FAb9c96ffCeCa.\nWhat are the estimated infrastructure costs to run the Sequencer?​\nThe estimated cost is approximately 600persequencerreplicapermonthforalow−to−mediumactivitychain.Withnetworkingandstorageincluded,theestimatedmonthlycostwouldbe600 per sequencer replica per month for a low-to-medium activity chain. With networking and storage included, the estimated monthly cost would be 1,500 for the Sequencer.\nWhat are the different validator modes?​\n\nDefensive (allowlist required):- Post bonds and create a challenge if local state disagrees with the onchain assertion (wallet required, will only post bonds onchain if a bad assertion is found.\n\nStakeLatest (allowlist required):- Stay bonded on the latest assertion and challenge any bad assertions found (wallet required, always bonded, uses some gas every time new assertion created)\n\nResolveNodes (allowlist required):- Stay bonded on the latest assertion, resolve any unconfirmed assertions, and challenge any bad assertions found (wallet required, always bonded, uses some gas every time an unconfirmed assertion is resolved or a new assertion is created)\n\nMakeNodes (allowlist required):- Continuously create new assertions, challenging any bad assertions found (wallet required, always bonded, most expensive node to run)\n\nNote that if there is more than one MakeNodes validator running, they might all try to create a new assertion at the same time. In that case, only one will be successful, and the others will have still spent gas on reverted calls that did nothing.\n\nWatchtower:- A node in Watchtower mode will immediately log an error if an onchain assertion deviates from the locally computed chain state. It doesn't require a wallet, as it never takes any action onchain. This mode is the default-enabled strategy for all nodes (full and archive).\n\nLearn more: Run a validator node.\nWhat are the costs to run a validator?​\nThe estimated monthly cost for Watchtower validators will be approximately 500.Allothervalidatorswillcost500. All other validators will cost 800 to $900 per month.\nWhat is the amount of funds that a validator needs in its wallet to participate in fraud proofs?​\nTo participate in a fraud-proof game, your validator will need funds (can be any ERC-20) for two things:\n\nGas costs to post assertions- Depends on your parent chain and is estimated to cost 163109 gas per assertion. If you assume one assertion per hour, then you can multiply your gas cost per hour to calculate the annual cost. This assumption holds under normal operation, but during a challenge, you may post more assertions (these will scale with the number of challenges), so it might be one assertion every 10 minutes, depending on how many challenges are ongoing.\n\nBonds to participate- Depends on your config. You can set the bond amounts to be any amount you want. For Arbitrum One, this is 3600 ETH initially and then 555+79 ETH per each subsequent challenge. These amounts were carefully selected and designed, with extensive research behind them, specifically for Arbitrum One. There could be one or multiple challenges, and so there will always be a possibility where more funds are needed.\n\nLearn more: BoLD economics of disputes.\nHow do I export snapshots for nitro-based chains? Is there any tooling for this?​\nWe currently don't have any toolkits available for this. The best way to make a snapshot is to gracefully stop the node and make a copy of the database.\nLearn more: Nitro database snapshots.\nWhat happens if I don't post an assertion for a long period of time?​\nOver time, without creating assertions, the validator whitelist in the Rollup contract can become disabled. If you look at the removeWhitelistAfterValidatorAfk method, it allows you to disable the whitelist after confirmPeriodBlocks + VALIDATOR_AFK_BLOCKS L1 blocks have passed since the last assertion created.\nAs a default, that's 7200 + 45818 blocks (a bit less than eight days). Disabling the whitelist is not a significant issue if you continue to monitor the chain and run a validator. It can be enabled using setValidatorWhitelistDisabled() by the chain owner. But it's always better to avoid reaching that point.\nIs there a way to increase idle timeout on RPC nodes for websocket connections?​\nThere is no way to increase the idle timeout for WebSocket connections via configuration options (geth doesn't provide this, and neither do we). The default value in Geth for the idle timeout is, as noted in the query, 30 seconds.\nHow do I run a split validator?​\nUsing Nitro's split validation, it can be run as a separate container using:\nnode.block-validator.validation-server-configs-list\nIt's possible to run it in the same container. That is the default way, and then Nitro uses a loopback connection. You can read more about this in running a split-validator.Can I use the Chain SDK to deploy a mainnet chain?Do I need permission/license to launch an Arbitrum chain?Does Arbitrum officially deploy and/or maintain L3s for external teams?Can I modify the underlying technology to customize my Arbitrum chain?What Data Availability (DA) solutions are currently available for Arbitrum chains?What token is used to pay gas fees on Arbitrum chains?Can I use Ethereum toolkits to develop on my Arbitrum chain?Do Arbitrum chains have any built-in AA solution?Is there any cross-chain bridging solution between two Arbitrum chains?Is there an official block explorer for Arbitrum chains?Is there any indexing solution that supports Arbitrum chains?Can I increase the maximum contract size for my Arbitrum chain?How can I modify Nitro to force posting an invalid assertion and test the fraud proof mechanism?What fee collectors can be configured on my chain?What is the lowest you can set the base fee to?How does fee collection work in Nitro?Can you upgrade the smart contract size limit once deployed?Can you set the block speed below 100ms?Can I set fast deposits for an L3?How do I increase the max transaction data size?What is the max theoretical TPS for an Arbitrum Chain?Why is the WETH Gateway not necessary for custom gas token chains?How do we verify if an ERC-20 was bridged using the native bridge?What are the estimated infrastructure costs to run the Sequencer?What are the different validator modes?What are the costs to run a validator?What is the amount of funds that a validator needs in its wallet to participate in fraud proofs?How do I export snapshots for nitro-based chains? Is there any tooling for this?What happens if I don't post an assertion for a long period of time?Is there a way to increase idle timeout on RPC nodes for websocket connections?How do I run a split validator?","tokens":4462,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262048533,"hash":"f1efd28edd4b8b5d5f9b8863f62ea920ce35785c"}
{"url":"https://governance.aave.com/t/arfc-aave-v4-activation-on-ethereum-mainnet/24293/1","domain":"governance.aave.com","title":"[ARFC] Aave V4 Activation on Ethereum Mainnet - Governance - Aave","text":"[ARFC] Aave V4 Activation on Ethereum Mainnet \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Summary\n\n Motivation\n\n Capital Efficiency, Risk Pricing, and Credit Expansion\n\n Specification\n\n Hub and Spoke Configuration\n\n Core Hub\n\n Prime Hub\n\n Plus Hub\n\n Rollout\n\n Implementation\n\n Guardian Roles\n\n Security\n\n Aave V4 Interface and Documentation\n\n Next Steps\n\n Disclaimer\n\n Copyright\n\n Mar 13\n\n 1 / 51\n\n Mar 13\n\n 5d ago\n\n post by AaveLabs on Mar 13\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n DeployV41920×1028 271 KB\nSummary\nThis proposal seeks community approval to deploy Aave V4 to Ethereum Mainnet through a security-first initial setup with conservative risk parameters and a deliberately narrow Hub and Spoke configuration. Aave V4 introduces a modular architecture where Liquidity Hubs hold shared liquidity and Spokes define distinct borrowing environments with governance-bounded exposure. This design preserves the depth and efficiency of unified liquidity while allowing for more precise risk management and support for a broader range of market structures. A deployment on Ethereum Mainnet would establish the foundation for V4 as Aave’s next-generation credit infrastructure.\nMotivation\nAave is the leading liquidity protocol in DeFi. V4 builds on that position by extending the architecture to support a much broader financial system onchain. As onchain credit expands across more collateral types and risk profiles that form new market structures, Aave needs a framework that can keep liquidity unified while allowing markets to be configured to their own parameters.\nCapital Efficiency, Risk Pricing, and Credit Expansion\nThe next phase of onchain finance brings a new range of market requirements:\nNew collateral types: Collateral with hard maturities, constrained redemption, or offchain counterparty exposure requires tighter exposure boundaries, and market logic that does not force unlike risks into the same assumptions.\nCredit Structures: Positions shaped by duration, payout profile, or defined repayment paths require borrowing terms and liquidation logic that can follow the structure of the position itself rather than a single generalized market design.\nProductive Infrastructure: Cash-flow-backed markets which involve productive infrastructure require borrowing terms, pricing, and exposure limits that reflect scalable energy output, recurring cash generation, and longer-duration repayment profiles.\nSupporting new market needs has often meant deciding whether unlike token exposures should share the same borrow curve, reserve configuration, and liquidity base, or they can be moved into isolated markets that preserve cleaner boundaries but require separate liquidity and separate growth. In Aave V4, Spokes keep those market-specific rules and risk boundaries separate, drawing from a Hub that contains deep liquidity reserves. Credit lines make each Spoke’s access explicit and bounded, so novel markets can be introduced without merging unlike risks into the same market configuration or forcing isolated liquidity bootstrapping each time.\nOnce market logic is separated, borrowing costs can be matched more closely to the risk being introduced. V4 provides an additional risk pricing mechanic at the collateral level, so stronger positions are not diluted by weaker ones, and more complex token exposures contribute premium in line with their risk profile. Thus, suppliers are compensated on terms that more closely reflect the risk drawn from shared liquidity, and protocol revenue benefits directly from diverse exposure.\nAs exposure diversifies with more Spokes drawing from shared liquidity, the accounting model is challenged to keep supplier claims, borrower debt, and liquidation flows consistent across the deployment. In Aave V4, supply and debt are tracked through shares, so different borrowing environments can apply different market logic while still settling cleanly against the same balance sheet. Liquidity claims, debt, and liquidation state remain consistent even as Spokes diverge in how they price and manage risk.\nTaken together, these changes evolve Aave beyond a single generalized lending design. Liquidity depth is maximized, risk is priced with precision, and a wider range of lending activity can be supported onchain, within one framework, while segregating risk. This positions Aave to become the infrastructure for global onchain finance.\nSpecification\nThis proposal covers the initial Ethereum Mainnet deployment of the Aave V4 codebase, the intended launch topology, the rollout path, the implementation and control model, the initial asset universe for risk parameterization, and the security basis for activation. Final parameter values remain subject to risk provider review and will be included in the activation AIP.\nHub and Spoke Configuration\nThe initial deployment is similar to the three-Hub layout currently under discussion with Core, Prime, and Plus Hubs. In that candidate setup, Core serves as the default liquidity and routing venue, Prime is designed for suppliers seeking a more controlled collateral posture, and Plus is designed for strategy-heavy stablecoin activity that should scale behind its own caps and pause conditions rather than push Core-wide limits.\nCore Hub\n\nSpoke\nCollateral\nBorrowable\n\nMain Spoke\nwETH, wstETH, weETH, wBTC, cbBTC, USDT, USDC, LINK, AAVE\nwBTC, cbBTC, wETH, USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC\n\nLido Spoke (e-Mode)\nwstETH\nwETH\n\nEtherFi Spoke (e-Mode)\nweETH\nwETH\n\nKelp Spoke (e-Mode)\nrsETH\nwETH\n\nLombard BTC Spoke (e-Mode)\nLBTC\nwBTC, cbBTC\n\nGold Spoke\nXAUt\nUSDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC\n\nForex Spoke\nUSDT, USDC, EURC\nUSDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC\n\nPrime Hub\n\nSpoke\nCollateral\nBorrowable\n\nBluechip Spoke\nwETH, wstETH, wBTC, cbBTC\nUSDT, USDC, GHO, coreUSDT, coreUSDC, corefrxUSD, coreEURC\n\nPlus Hub\n\nSpoke\nCollateral\nBorrowable\n\nEthena Ecosystem Spoke\nPT-sUSDe, PT-USDe, sUSDe, USDe\nUSDT, USDC, USDe, GHO, coreUSDT, coreUSDC, corefrxUSD\n\nEthena Correlated Spoke\nPT-sUSDe, PT-USDe, sUSDe, USDe\nUSDe\n\nEach supported asset in each Hub comes with its own tokenization form through a Tokenized Spoke, allowing deposits to be wrapped into tokenized supply positions without enabling borrow capabilities. Tokenized supply positions are ERC-4626 compliant, allowing them to be used in integrations built on top of Aave V4.\nNote, borrowable tokens with the “core” prefix are credit lines from the Core Hub, and tokens drawn from other Hubs will have an appropriate prefix. The initial list of assets included in this configuration are:\n\nAAVE\n\nEURC\n\nGHO\n\nLBTC\n\nLINK\n\nPT-sUSDe\n\nPT-USDe\n\nRLUSD\n\nUSDC\n\nUSDT\n\nUSDe\n\nUSDG\n\nXAUt\n\ncoreEURC\n\ncoreUSDC\n\ncoreUSDT\n\ncorefrxUSD\n\ncbBTC\n\nfrxUSD\n\nrsETH\n\nsUSDe\n\nwBTC\n\nwETH\n\nweETH\n\nwstETH\n\nParameters will be provided by Risk Service Providers and included in the AIP.\nRollout\nThe rollout will begin on Ethereum Mainnet with a deliberately narrow initial activation surface, with security and controlled production hardening taking priority over immediate growth. It will bring V4 online with conservative parameters and minimal assets, so the DAO can observe early liquidity routing, utilization concentration, and credit-line draw behavior.\nSupply and borrow caps will be carefully monitored and adjusted over time per risk providers recommendations to grow the protocol with a security first approach. When live conditions support it, the DAO can lift caps, extend or resize credit lines, onboard additional assets, and configure new Hubs or Spokes.\nImplementation\nAave Labs will deploy the V4 system and prepare the initial configuration in line with the architecture approved by governance and the final recommendations of the risk service providers. Activation will occur through a subsequent AIP that includes the deployed contract addresses together with the finalized launch parameters. Within the V4 architecture, the Liquidity Hub is the immutable coordinator for shared liquidity and emergency-stop functionality, while Spokes are upgradeable modules that manage user-facing lending logic, reserve configuration, and oracle interactions. Each Hub maintains the registry of authorized Spokes, sets the relevant caps, and enforces the core accounting invariants that govern shared liquidity and debt across the system.\nGuardian Roles\nAt launch, Aave V4 will use a Protocol Security Council that operates in a role similar to the Guardian framework in Aave V3. During the initial hardening phase, this council will hold the emergency powers needed to safeguard the protocol. Those permissions are expected to step down after hardening, at which point updates will proceed through AIPs and approved stewards, while the council retains pause and freeze powers for emergencies only.\nA Stewardship Council is outside the initial launch scope and, when introduced, will come through a follow-up proposal in a role similar to Aave V3 Risk Stewards. Risk changes during the hardening phase are expected to be limited.\nSecurity\nThe security basis for launch reflects a year-long review process embedded throughout V4 development. Across that process, V4 underwent roughly 345 days of cumulative security review spanning manual audits, formal verification, invariant testing, fuzzing, and a public security contest, supported by a $1.5 million DAO-ratified security budget. Published materials already include audit reports from Trail of Bits, Blackthorn, and ChainSecurity, together with dedicated invariant and fuzz testing across core V4 components. More information on Aave V4’s security approach can be found in our Security by Design post.\nThe relevant materials are being compiled here: https://github.com/aave/aave-v4/tree/main/audits\nAave V4 Interface and Documentation\nAt launch, Aave V4 will be hosted on a dedicated interface at pro.aave.com rather than within app.aave.com. Supporting materials are available through the Aave V4 technical docs in the core repository and the public Aave V4 documentation, both of which will continue to be expanded as the system moves toward activation.\nNext Steps\n\nSeek community feedback and risk analysis.\n\nIf community consensus is reached, raise to snapshot.\n\nIf the snapshot outcome is positive, escalate to an AIP, with full risk parameters included, to deploy and activate Aave V4 to Mainnet.\n\nDisclaimer\nAave Labs is the primary contributor to Aave V4 and is directly involved in its design, development, and deployment planning. Aave Labs received compensation to develop Aave V4 under the Aave Labs Service Provider Contract. \nCopyright\nCopyright and related rights waived via CC0.\n\n [TEMP CHECK] Aave Will Win Framework\n\n [ARFC] Aave Will Win Framework\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n 20\n\n 19\n\n 2\n\n 2\n\n read \n\n 67\n min\n\n post by ApuMallku on Mar 13\n\n post by ChaosLabs on Mar 13\n\n post by LlamaRisk on Mar 13\n\n post by okinawajoe on Mar 13\n\n post by andy1 on Mar 13\n\n post by AaveLabs on Mar 19\n\n post by MconnectDAO on Mar 20\n\n post by AaveLabs on Mar 23\n\n post by anon40760803 on Mar 25\n\n post by AaveLabs on Mar 30\n\n post by Millesimillia on Mar 30\n\n post by anon40760803 on Mar 31\n\n post by EzR3aL on Mar 31\n\n post by Millesimillia on Mar 31\n\n 8 days later\n\n post by LlamaRisk on Apr 9\n\n post by AaveLabs on Apr 11\n\n post by LlamaRisk on Apr 15\n\n post by AaveLabs on Apr 18\n\n 12 days later\n\n post by LlamaRisk on Apr 30\n\n Load more posts below","tokens":2859,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262051763,"hash":"2005af54264f0bfac5912a8ad90e322e3419e707"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/zk/zk-dispute-game.html","domain":"specs.optimism.io","title":"ZK Dispute Game - OP Stack Specification","text":"ZK Dispute Game\n\nTable of Contents\n\nOverview\nDefinitions\n\nZKDisputeGame\nMCP Clone\nGame Args (CWIA)\nSuper Root\nSuperRootProof\nChain Set\nL2 Sequence Number\nParent Game\nChallenge Deadline\nProve Deadline\nAbsolute Prestate\nGame Over\n\nContracts Involved\nActors\nCWIA Layout\n\nFixed Prefix\nVariable extraData\nDynamic Game Args\n\nrootClaim Semantics\nrootClaimByChainId\ninitialize Invariants\nOPCM Integration\n\nZKDisputeGameConfig\n\nAssumptions\n\naZKG-001: ZK Verifier Soundness\n\nMitigations\n\naZKG-002: Absolute Prestate Uniquely Identifies the ZK Program\n\nMitigations\n\naZKG-003: Parent Chaining Preserves Correctness\n\nMitigations\n\naZKG-004: Bonds Are Economically Rational\n\nMitigations\n\naZKG-005: Guardian Acts Honestly and Timely\n\nMitigations\n\naZKG-006: Anchor State Advances Slowly Relative to Proposal Frequency\n\nMitigations\n\naZKG-007: Proof Generation Is Feasible Within the Prove Window\n\nMitigations\n\naZKG-008: Super Root Preimage Faithfully Represents the Chain Set\n\nMitigations\n\naZKG-009: Chain Set Is Stable During the Prove Window\n\nMitigations\n\nInvariants\n\niZKG-001: A Valid Proof Always Wins\n\nImpact\n\niZKG-002: A Game Without a Valid Proof and With a Challenger Resolves as CHALLENGER_WINS\n\nImpact\n\niZKG-003: Bond Safety via DelayedWETH\n\nImpact\n\niZKG-004: Permissionless Participation\n\nImpact\n\niZKG-005: Parent Invalidity Propagates to Children\n\nImpact\n\niZKG-006: closeGame Reverts When Paused\n\nImpact\n\niZKG-007: Only Finalized Games Can Close\n\nImpact\n\niZKG-008: Blacklisted and Retired Games Enter REFUND Mode\n\nImpact\n\niZKG-009: Child Resolution Requires Resolved Parent\n\nImpact\n\niZKG-010: At Most One Challenge Per Game\n\nImpact\n\niZKG-011: Bond Conservation\n\nImpact\n\niZKG-012: Monotonic State Progression\n\nImpact\n\niZKG-013: rootClaimByChainId Consistency\n\nImpact\n\niZKG-014: rootClaim Matches SuperRootProof Preimage\n\nImpact\n\nOverview\nThe ZKDisputeGame is a dispute game that resolves disputes in a single round using ZK\n(zero-knowledge) proofs, registered as game type ZK_GAME_TYPE. It integrates into the OP\nStack dispute infrastructure — DisputeGameFactory, AnchorStateRegistry, DelayedWETH, and\nOPContractsManager.\nUnlike the classic output-root model, the game commits to a super root: a hash of the\nconsistent state of all chains in the interop set at a given timestamp. This design works\nidentically in both deployment contexts:\n\nStandalone (single chain): the SuperRootProof preimage contains exactly one chain entry.\nInterop set (multiple chains): the preimage contains one entry per chain. No mode flag or\nbranching logic exists in the contract; the chain set size is the only difference.\n\nA proposer posts a super root with a bond. Anyone can challenge it by depositing a challenger\nbond. If no challenge is submitted before the challenge window expires, the proposer wins by\ndefault. If a challenge is submitted, either a prover submits a valid ZK proof to defend the\nclaim and the proposer wins, or the proving window expires without a valid proof and the challenger\nwins. Resolution is permissionless once the game is over and the parent game is resolved.\nThe proving system is accessed through the generic IZKVerifier\ninterface. The first supported backend is SP1 (PLONK) by Succinct. See\nZK Fault Proof VM for details on the off-chain proving\ncomponent.\nFor the full game lifecycle and bond accounting see\nGame Mechanics.\nDefinitions\nZKDisputeGame\nThe smart contract implementing the single-round super-root ZK dispute protocol. Each game\ninstance is a lightweight MCP clone of a shared implementation contract, deployed\nby DisputeGameFactory.\nMCP Clone\nA minimal proxy clone (ERC-1167) created by DisputeGameFactory that shares the\nZKDisputeGame implementation bytecode but has its own per-chain configuration appended as\nimmutable constructor arguments via the Clones-with-Immutable-Args (CWIA) pattern.\nGame Args (CWIA)\nThe per-chain configuration bytes appended to each MCP clone by DisputeGameFactory. A single\nimplementation contract serves every deployment. See CWIA Layout for the full\nfield breakdown.\nSuper Root\nA bytes32 hash that commits to the output roots of all chains in the interop set at a given\ntimestamp. Computed as hashSuperRootProof(superRootProof). The rootClaim of every\nZKDisputeGame is a super root.\nSuperRootProof\nAn ABI-encoded struct that is the preimage of a super root. It carries the timestamp and the list\nof per-chain output roots that the super root commits to. Its hash MUST equal rootClaim.\nThe (chainId, outputRoot) pairs MUST be sorted in strictly ascending order by chainId.\nEncoding the same logical chain set in a different order produces a different hash and therefore a\ndifferent super root. Proposers who submit an unsorted preimage will fail the\nhashSuperRootProof(decode(extraData.superRootProof)) == rootClaim() check in initialize(), and\nany ZK proof generated over the correct (sorted) super root will not verify against it.\nChain Set\nThe set of chains whose output roots are committed to by a super root. Defined by the\nSuperRootProof preimage in extraData. In a standalone deployment the chain set contains\nexactly one chain.\nL2 Sequence Number\nThe super root timestamp asserted by a game's rootClaim. Used to validate parent–child ordering.\nUnlike the classic output-root model where this field holds an L2 block number, here it is a\ntimestamp, following SuperFaultDisputeGame convention. The value MUST fit within a uint64.\nParent Game\nA previously created ZKDisputeGame whose proven super root serves as the starting state\nfor a new game's ZK proof. A game with parentIndex == type(uint32).max starts from the anchor\nstate directly.\nChallenge Deadline\nThe timestamp after which a game can no longer be challenged. Computed as\ncreatedAt + maxChallengeDuration.\nProve Deadline\nThe timestamp after which a challenged game can no longer receive a proof submission. Set to\nblock.timestamp + maxProveDuration when challenge() is called, resetting the prior challenge\ndeadline.\nAbsolute Prestate\nA bytes32 value that uniquely identifies the ZK program version being proven. It is the program\nidentity passed to IZKVerifier.verify() and is injected into each game instance via the CWIA\ngame args. See Absolute Prestate for\ndetails.\nGame Over\nThe condition under which a game can be resolved. gameOver() returns true when:\n\nclaimData.prover != address(0) (a valid proof has been submitted), or\nclaimData.deadline < block.timestamp (the current deadline has expired).\n\nContracts Involved\nContractRole\nZKDisputeGame (clones)Per-proposal game instance. Runs the challenge → prove → resolve lifecycle and tracks bond accounting.\nZKDisputeGame (implementation)Shared bytecode base for MCP clones. Deployed and upgraded by OPCM.\nDisputeGameFactoryCreates MCP clones via create(...). Appends per-chain gameArgs (CWIA).\nAnchorStateRegistrySource of truth for finalization, anchor state, respected game type, and blacklisting. Enforces pause checks.\nDelayedWETHBond custody with a deposit → unlock → withdraw lifecycle. Provides a time window for the Guardian to freeze funds post-resolution.\nIZKVerifierGeneric verifier interface. The concrete deployment for the initial release uses Succinct's PLONK verifier.\n\nActors\nActorRole\nProposerFully permissionless. Creates games via DisputeGameFactory.create() with the required initBond.\nChallengerFully permissionless. Disputes a proposal by calling challenge() and depositing challengerBond.\nProverFully permissionless. Submits a valid ZK proof via prove(proofBytes). May be the same address as the proposer or the challenger.\nGuardianPauses the system, blacklists games, sets the respected game type, and retires old games via updateRetirementTimestamp().\nOPCM / ProxyAdmin OwnerDeploys implementations, configures game types in the factory, and manages absolutePrestate and verifier versions.\n\nCWIA Layout\nThe CWIA calldata is structured in three sections. Offsets after extraData are dynamic and\ncomputed via _preExtraDataByteCount() and _extraDataByteCount() helpers, following the same\npattern as SuperFaultDisputeGame.\nFixed Prefix\nFields at fixed offsets, present before extraData:\nFieldOffsetTypeDescription\ngameCreator0x00addressCreator of the dispute game\nrootClaim0x14bytes32Super root hash asserted by this game\nl1Head0x34bytes32L1 block hash at game creation\ngameType0x54uint32Game type identifier (ZK_GAME_TYPE)\n\nVariable extraData\nStarting at offset 0x58. The total byte count is returned by _extraDataByteCount().\nFieldTypeDescription\nparentIndexuint32Index of the parent game; type(uint32).max if starting from the anchor state.\nsuperRootProofbytesABI-encoded SuperRootProof preimage committed to by rootClaim. Variable length. The L2 sequence number (super root timestamp) is part of this preimage and is exposed by the contract via l2SequenceNumber() for convenience.\n\n_preExtraDataByteCount() returns the byte count of the fixed prefix (0x58).\n_extraDataByteCount() returns the total byte count of the variable extraData section.\nAll game args fields use dynamic offsets computed from these helpers.\nDynamic Game Args\nFields at dynamic offsets, after extraData. Injected by OPCM._makeGameArgs().\nFieldTypeDescription\nabsolutePrestatebytes32Super-root ZK program identity (e.g., SP1 verification key)\nverifieraddressAddress of the IZKVerifier contract\nmaxChallengeDurationDurationTime window for challenges after game creation\nmaxProveDurationDurationTime window for proof submission after a challenge\nchallengerBonduint256Bond required to challenge a proposal\nanchorStateRegistryaddressAddress of AnchorStateRegistry\nwethaddressAddress of per-chain DelayedWETH\n\nanchorStateRegistry and weth are injected by OPContractManager._makeGameArgs() directly\nfrom the chain's existing deployment.\nrootClaim Semantics\nrootClaim is always a super root hash: the result of hashSuperRootProof(superRootProof),\nwhere superRootProof is the ABI-encoded SuperRootProof struct stored in extraData.\nThe SuperRootProof preimage carries:\n\nThe super root timestamp (l2SequenceNumber).\nA list of (chainId, outputRoot) pairs for every chain in the interop set, sorted in strictly\nascending order by chainId.\n\nIn a standalone deployment, this list contains exactly one entry. In an interop set, it contains\none entry per chain. The contract does not distinguish between these cases; the preimage size is\nthe only difference.\n\nNote on chain ordering: The ZK program identified by absolutePrestate is compiled to\nproduce and verify proofs over preimages with chains sorted ascending by chainId. A proposer\nwho submits an unsorted preimage will produce a rootClaim that differs from any super root a\ncorrect prover can generate a proof for — the game will expire unchallenged only if no one\nnotices, but any subsequent prove() call against the correctly sorted super root will not\nmatch rootClaim and will therefore revert.\n\nrootClaim MUST NOT be interpreted as an L2 output root for any specific chain. Per-chain output\nroots are extracted via rootClaimByChainId.\nrootClaimByChainId\nfunction rootClaimByChainId(uint256 _chainId) public view returns (Claim rootClaim_)\n\nDecodes the SuperRootProof preimage from extraData and iterates over the outputRoots array\nto find the entry matching _chainId. Returns the corresponding output root as a Claim.\nMUST revert with UnknownChainId if _chainId is not present in the preimage.\nOptimismPortal calls this function during withdrawal verification (via\nGameTypes.isSuperGame()) to extract the per-chain output root from the super root commitment.\nAdding ZK_GAME_TYPE to the isSuperGame allowlist is required for Portal withdrawal\nfinalization to work correctly.\ninitialize Invariants\nIn addition to the standard parent validation described in\nGame Mechanics — Parent Validation,\ninitialize() enforces the following:\n\nhashSuperRootProof(decode(extraData.superRootProof)) MUST equal rootClaim(). A mismatch MUST\nrevert.\nl2SequenceNumber() MUST be strictly greater than startingProposal.l2SequenceNumber.\nl2SequenceNumber() MUST fit within uint64 (i.e., <= type(uint64).max).\nThe calldata size MUST match the expected length derived from _extraDataByteCount() to prevent\nUUID collisions in the factory from extra or missing bytes in extraData.\n\nOPCM Integration\nZKDisputeGame integrates into OPCM v2 as game type ZK_GAME_TYPE through\nDisputeGameConfig, following the same pattern as other game types.\nThree additions are required:\n\nZKDisputeGame is deployed once via the DeployImplementations script and tracked in\nOPContractsManagerContainer.Implementations.\nA ZKDisputeGameConfig struct carries the per-chain parameters that the caller provides.\nOPCM's _makeGameArgs() decodes it, injects the chain-specific values it already knows, and\npacks the final variable-length CWIA bytes for the factory.\nZK_GAME_TYPE is added to the validGameTypes array in _assertValidFullConfig() and\nto GameTypes.isSuperGame().\n\nZKDisputeGameConfig\nstruct ZKDisputeGameConfig {\n Claim absolutePrestate;\n address verifier;\n Duration maxChallengeDuration;\n Duration maxProveDuration;\n uint256 challengerBond;\n}\n\nif (_gcfg.gameType.raw() == GameTypes.ZK_GAME_TYPE.raw()) {\n ZKDisputeGameConfig memory cfg = abi.decode(_gcfg.gameArgs, (ZKDisputeGameConfig));\n return abi.encodePacked(\n cfg.absolutePrestate,\n cfg.verifier,\n cfg.maxChallengeDuration,\n cfg.maxProveDuration,\n cfg.challengerBond,\n address(_anchorStateRegistry),\n address(_delayedWETH)\n );\n}\n\nAssumptions\naZKG-001: ZK Verifier Soundness\nThe IZKVerifier implementation is sound: it is computationally infeasible to produce a proof\nthat passes verify() for an incorrect state transition.\nMitigations\n\nThe PLONK verifier for SP1 is independently audited.\nThe verifier address comes from gameArgs, managed by OPCM. Governance controls upgrades.\nThe IZKVerifier interface intentionally decouples the game from any specific proving system.\nA verifier can be swapped without redeploying the game implementation.\n\naZKG-002: Absolute Prestate Uniquely Identifies the ZK Program\nThe absolutePrestate value uniquely identifies the ZK program version. Two different programs\nMUST NOT share the same absolutePrestate.\nMitigations\n\nFor SP1, absolutePrestate corresponds to the program's verification key, which is derived from\nthe program binary and circuit structure.\nOPCM manages absolutePrestate per deployment; program updates require a corresponding\nabsolutePrestate update via governance.\n\naZKG-003: Parent Chaining Preserves Correctness\nA chain of ZKDisputeGame instances resolving as DEFENDER_WINS implies that the final\nrootClaim is a valid super root, provided the initial parent started from a known-good anchor\nstate.\nMitigations\n\nEach proof commits to startingProposal.root (the parent's super root claim) as a public\nvalue, which cryptographically links consecutive games.\nParent validation at creation time prevents games from chaining off blacklisted, retired, or\nCHALLENGER_WINS parents.\nIf a parent is blacklisted or retired after child games have been created, the Guardian MUST\nindividually blacklist or retire those child games to place them in REFUND mode.\n\naZKG-004: Bonds Are Economically Rational\nThe initBond, challengerBond, maxChallengeDuration, and maxProveDuration values are set\nsuch that honest participation is economically rational and griefing is costly.\nMitigations\n\nchallengerBond, maxChallengeDuration, and maxProveDuration are in gameArgs and can be\ntuned per deployment by OPCM without redeploying the implementation. initBond is a factory\nparameter updated separately.\nBenchmark proving costs and document standard values for common configurations.\nBonds too low invite spam; bonds too high discourage honest participation. Durations must be\nlong enough to allow super-root proof generation but short enough to preserve withdrawal latency\nbenefits.\n\naZKG-005: Guardian Acts Honestly and Timely\nThe Guardian is trusted to pause the system, blacklist invalid games, and retire superseded game\ntypes before fraudulent games achieve Valid Claims.\nMitigations\n\nThe DISPUTE_GAME_FINALITY_DELAY_SECONDS airgap between resolution and closeGame provides\nthe Guardian a window to act.\nDelayedWETH provides an additional window after closeGame to freeze funds.\n\naZKG-006: Anchor State Advances Slowly Relative to Proposal Frequency\nThere is no technical mechanism that enforces the anchor state to advance slowly — any resolved\ngame that passes the finality delay can call closeGame() and advance it. However, the minimum\ntime for a game to advance the anchor state is maxChallengeDuration + DISPUTE_GAME_FINALITY_DELAY_SECONDS\n(12+ hours in practice), and under normal operation this is expected to be much larger than\ntypical proposal frequency. Orphan risk from parent validation is therefore negligible.\nMitigations\n\nA rational proposer would never use a parent whose l2SequenceNumber is below the anchor, as\nit unnecessarily increases the proving range.\nParent validation requires the parent's l2SequenceNumber to be strictly above the anchor\nstate, preventing chains from building on stale starting points.\n\naZKG-007: Proof Generation Is Feasible Within the Prove Window\nA prover with access to the required L1 and L2 data for all chains in the interop set can\ngenerate a valid super-root proof within maxProveDuration under normal operating conditions.\nMitigations\n\nmaxProveDuration must be set with headroom above worst-case proving times for the full\ninterop set, accounting for prover network latency, queue depth, and hardware variability.\nMultiple independent provers reduce the risk of a single point of failure in proof delivery.\nOff-chain monitoring on the ratio of successful prove() calls to challenged games can detect\nwhen proving infrastructure is unable to keep up with the configured window.\n\naZKG-008: Super Root Preimage Faithfully Represents the Chain Set\nThe SuperRootProof preimage stored in extraData faithfully lists every chain in the interop\nset with correct chain IDs and output roots. No chain is omitted, duplicated, or misidentified.\nMitigations\n\ninitialize() enforces hashSuperRootProof(decode(extraData.superRootProof)) == rootClaim().\nAn incorrect preimage cannot produce a matching hash.\nThe ZK program independently verifies that the output roots in the preimage match the actual\nchain states (see iZKVM-002).\nThe ZK program (identified by absolutePrestate) is compiled to produce and verify proofs over\npreimages with chains sorted in strictly ascending order by chainId. An unsorted preimage\nproduces a different hash and therefore a different rootClaim; no valid proof can be generated\nfor it, so verification will always fail for such proposals.\n\naZKG-009: Chain Set Is Stable During the Prove Window\nThe interop set (the set of chains committed to by a super root) does not change between game\ncreation and proof submission.\nMitigations\n\nThe SuperRootProof preimage is immutable once embedded in extraData at creation time.\nThe absolutePrestate encodes which chain set the ZK program was compiled for. A chain set\nchange requires a new program and a new absolutePrestate, gated by governance.\n\nInvariants\niZKG-001: A Valid Proof Always Wins\nIf a valid ZK proof is submitted before the current deadline, the game MUST resolve as\nDEFENDER_WINS (assuming a valid parent chain).\nImpact\nSeverity: High\nA violation lets a correct proposer be cheated out of their bond, which breaks the economic\nsecurity of the game and the correctness of withdrawal finalization.\niZKG-002: A Game Without a Valid Proof and With a Challenger Resolves as CHALLENGER_WINS\nIf a game was challenged and the prove deadline expires without a valid proof, resolve() MUST\nproduce CHALLENGER_WINS.\nImpact\nSeverity: High\nA violation would allow invalid super roots to be finalized on L1 and bridge funds to be stolen.\niZKG-003: Bond Safety via DelayedWETH\nAll bonds MUST be deposited into and withdrawn from DelayedWETH. The game contract MUST NOT\nhold raw ETH bonds.\nImpact\nSeverity: Critical\nRaw ETH bonds held directly in a game clone cannot be recovered — each clone is an immutable\nproxy instance with no upgrade path, so any ETH stuck in it is permanently lost. This also\nbypasses the Guardian's ability to freeze funds post-resolution.\niZKG-004: Permissionless Participation\ncreate(), challenge(), prove(), and resolve() MUST be callable by any address. No\nAccessManager or allowlist MAY gate these functions.\nImpact\nSeverity: High\nPermissioned access would reduce censorship resistance and deviate from the Stage 1 security\nmodel.\niZKG-005: Parent Invalidity Propagates to Children\nIf a parent game resolves as CHALLENGER_WINS, all child games MUST also resolve as\nCHALLENGER_WINS, regardless of whether a valid proof was submitted for the child.\nImpact\nSeverity: High\nFailure to propagate would allow a chain of games to finalize a super root that descends from an\ninvalid state. Funds that do not exist on L2 could be withdrawn.\niZKG-006: closeGame Reverts When Paused\ncloseGame() MUST revert if AnchorStateRegistry reports the system as paused.\nImpact\nSeverity: High\nAllowing bond distribution while paused would bypass the Guardian's ability to freeze funds\nduring an active security incident.\niZKG-007: Only Finalized Games Can Close\ncloseGame() MUST revert unless AnchorStateRegistry.isGameFinalized(this) returns true.\nImpact\nSeverity: High\nClosing before the finality delay would remove the Guardian's window to blacklist or pause the\ngame before funds are distributed.\niZKG-008: Blacklisted and Retired Games Enter REFUND Mode\nIf a game is blacklisted or retired, closeGame() MUST enter REFUND mode: bonds are returned to\nthe original depositors rather than distributed to winners.\nImpact\nSeverity: High\nFailure to refund would cause honest participants to lose bonds when the Guardian must invalidate\na game for safety reasons unrelated to the game's correctness.\niZKG-009: Child Resolution Requires Resolved Parent\nIf a game references a parent (parentIndex != type(uint32).max), resolve() MUST revert\nwhile that parent's status == GameStatus.IN_PROGRESS. The resolution dependency chain MUST\nbe honored in topological order.\nImpact\nSeverity: Critical\nWithout this, iZKG-005 cannot hold. A child could resolve as DEFENDER_WINS and finalize a\nwithdrawal before the parent is invalidated. Funds could be withdrawn against a super root that\ndescends from an invalid state.\niZKG-010: At Most One Challenge Per Game\nchallenge() MUST revert if claimData.status != ProposalStatus.Unchallenged.\nImpact\nSeverity: High\nA second challenge could reset the prove deadline and give challengers unbounded time to delay\nresolution, overwrite the original challenger's address and steal their bond credit, or produce\ndouble the bond liability in DelayedWETH with only one challengerBond deposited.\niZKG-011: Bond Conservation\nFor any resolved game, the sum of all bonds distributed plus any amount sent to address(0) MUST\nequal initBond + challengerBond (or initBond alone if the game was never challenged). No value\nmay be created from nothing or permanently locked beyond the defined burn path.\nImpact\nSeverity: High\nA violation means either fund loss for participants (bonds locked forever with no recipient) or an\nexploitable source of unbacked ETH withdrawals from DelayedWETH.\niZKG-012: Monotonic State Progression\nclaimData.status MUST only advance forward through the ProposalStatus state machine. No\ntransition from a later state back to an earlier one is permitted. status (GameStatus) MUST\nonly transition from IN_PROGRESS to a terminal state (CHALLENGER_WINS or DEFENDER_WINS).\nImpact\nSeverity: High\nState regression would corrupt deadline logic and bond accounting. Functions that use status as a\nguard could be re-entered in unexpected ways if the state can regress.\niZKG-013: rootClaimByChainId Consistency\nrootClaimByChainId(_chainId) MUST return the output root for _chainId as committed to in the\nSuperRootProof preimage of rootClaim. If _chainId is not present in the preimage, the\nfunction MUST revert with UnknownChainId.\nImpact\nSeverity: High\nAn inconsistency between what rootClaimByChainId returns and what the super root actually\ncommits to would allow the Portal to finalize withdrawals against an output root that was never\nproven, and allow bridge funds to be stolen.\niZKG-014: rootClaim Matches SuperRootProof Preimage\nhashSuperRootProof(decode(extraData.superRootProof)) MUST equal rootClaim() at all times\nafter initialize(). This is enforced at initialization and cannot change thereafter (both values\nare immutable).\nImpact\nSeverity: Critical\nA mismatch would mean rootClaimByChainId is decoding a preimage that does not correspond to the\nproven claim. Arbitrary output roots could be returned to the Portal regardless of what was\nactually proven.","tokens":6170,"squid":"ink-governance","role":"Council Listener","at":1791262055288,"hash":"77858bc29e324bcd82a50a5cab32d4d09c8a561e"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/aep-license","domain":"docs.arbitrum.io","title":"Arbitrum chain licensing | Arbitrum Docs","text":"✏️Request an updateWhat do I need to know about the Arbitrum chain license?​\nNitro is currently licensed under a Business Source License, similar to DeFi protocols like Uniswap and Aave, among others, with an “Additional Use Grant” to ensure that everyone can have full comfort using and running nodes on all public Arbitrum chains.\nThe Additional Use Grant also permits deployment of the Nitro software in a permissionless, zero-cost fashion, as a new blockchain provided that the chain settles to either Arbitrum One or Arbitrum Nova. L3s that settle to Arbitrum One or Nova have no obligation to share revenue with the Arbitrum DAO and remain first class members of the Arbitrum ecosystem.\nAs an expansion of this license, the Arbitrum Expansion Program (AEP) is a self-service licensing model that makes it easy for developers to build and customize L2s/L3s using Arbitrum’s technology alongside different parent chains.\nBenefits​\n\nLeverage battle-tested technology to permissionlessly deploy L2s/L3s that settle to any supported parent chain.\nGovernance freedom: Arbitrum chains are not required to be governed by the Arbitrum DAO.\nFlexible licensing allows developers to modify chain configurations. Arbitrum chains are free to modify any part of the stack, including implementation of custom gas tokens, alternative DA integrations, novel sequencing mechanisms, account abstraction, altVMs, etc.\nL3s that settle to parent chains other than Arbitrum One and Nova must contribute net chain revenue, where 8% flows to the DAO and 2% to the developer guild.\nWhat do I need to know about the Arbitrum chain license?Benefits","tokens":406,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262058941,"hash":"5cee9dced14082637b1de49c9089b9463da4b58c"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/super-fault-dispute-game.html","domain":"specs.optimism.io","title":"Super Fault Dispute Game - OP Stack Specification","text":"Super Fault Dispute Game\n\nTable of Contents\n\nOverview\nSuper Root State Transition\n\nTransition State\nInvalid State\nLocal Safe Block Derivation\nConsolidation\n\nFault Proof Program State Transition\n\nOverview\nThe Super Fault Dispute Game is a dispute game type that resolves\nsuper root proposals. It is based on the output root\nfault dispute game with some modifications:\n\nClaims at and above the split depth are commitments to the state within the super root state transition described\nbelow instead of output roots.\nThe L2 block number is replaced by the timestamp of the proposed super root.\n\nThe l2BlockNumber() method has been renamed l2SequenceNumber() in IDisputeGame interface to reflect that this\nis an arbitrary identifier within the fully ordered sequence of chain states.\n\nThe L2 block number challenge is removed.\nThe super root state transition is now able to invalidate all proposals with an incorrect proposal timestamp as part\nof the state transition.\nWhile claims in the bottom half of the game still commit to the state of the FPVM, the fault proof program being\nexecuted changes to verify the disputed step of the super root state transition instead of the application of a\ndisputed L2 block.\nThe L2 block number preimage oracle local key now always provides the timestamp of the proposal.\nThe L2 chain ID preimage oracle local key is no longer used and is never populated by the dispute game.\n\nThe game does not require interop. A chain proposes super roots whether or not interop is\nactive. The super output holds one output root for each chain in the\ndependency set, and the dependency set may contain a single chain. Interop enables\ncross chain messages and their validation. When interop is not active, a block contains no executing message, so the\nconsolidation step has nothing to validate.\nSuper Root State Transition\nThe super fault dispute game defines a state transition from the current anchor state super root to the canonical super\nroot at the game's proposal timestamp, if one can be derived from the available L1 data or the invalid state if not.\nAs the valid state transition always extends to the game proposal's timestamp, proposing a super root with a timestamp\nless than or greater than game's proposal timestamp will be found to be invalid. Similarly any root claim that is the\nhash of a TransitionState will be found to be invalid.\nTo reduce the amount of processing required in a single invocation of the FPVM, the state transition breaks the\ntransition from the super root at one timestamp to the super root at the next timestamp into 128 steps. The claims for\nthese intermediate steps are keccak256 hash of a transition state. These 128 steps repeat to\ntransition between the super root at each timestamp from the anchor state until the proposal time is reached.\nThe number of steps does not depend on the number of chains in the dependency set. A game for a single chain performs\nthe same 128 steps as a game for an interop set.\nTransition State\nA transition state is RLP encoded data consisting of:\n\nSuperOutput []byte - the encoded super output at the immediately prior timestamp. This is the super root that is\nbeing transformed from.\nPendingProgress []LocalSafeBlock - the next block derived for each chain from L1 batch data, prior to validating\nexecuting messages.\n\nLocalSafeBlock is two bytes32 RLP encoded, the first being the block hash and the second the output root for\nthe block.\n\nStep a uint64 recording the number of steps applied to this TransitionState since the SuperOutput.\n\nInvalid State\nThe invalid state is defined as keccak256(utf8(\"invalid\")). This state is used to indicate a state transition where\nthere is no possible valid proposal. The dispute game contract MUST prevent a game from being created where the root\nclaim is the invalid state.\nWhen the prestate is the invalid state, the post state is also the invalid state.\nLocal Safe Block Derivation\nThe first 127 steps derive the next local safe block for one chain in the super root using\nthe derivation process. Chains are processed in the order they appear in the super root\n(ascending order of chain ID). The Step is incremented after each step.\nFor each step, the valid post state TransitionState is calculated by the algorithm:\n\nIf the prestate is a SuperRoot, convert it to a TransitionState with Step = 0 and PendingProgress an empty\narray.\nIf Step is less than the number of chains included in SuperOutput, derive the next local safe block for the chain\nat\nindex Step in the SuperRoot using the derivation process. Executing messages are\nnot\nchecked at this stage.\n\nNo block is derived if Step is greater than the number of chains in the super root.\nIf the derivation process is unable to derive the next L1 block because the L1 head is reached, the post state is\nthe invalid state\n\nIncrement Step\n\nSince one step is required per chain in the dependency set, the current dispute game can support a maximum of 127 chains\nin the dependency set.\nConsolidation\nWhen the prestate is a TransitionState with Step = 127, the validity of executing messages is checked and any\nlocal safe blocks found to contain invalid executing messages are replaced with deposit only blocks. This includes\nrecursively replacing any blocks with executing messages that became invalid because of another block being replaced.\nThe post state is defined as a super output where timestamp is the SuperOutput timestamp + 1, and the output roots\nare set to the output roots of the validated blocks (including any required replacements).\nWhen interop is not active, the CrossL2Inbox implementation is not installed behind its predeploy proxy, so a block\ncontains no executing message. Consolidation therefore replaces no block,\nand the post state carries the pending progress through unchanged.\nFault Proof Program State Transition\nBelow the split depth, claims correspond to execution trace commitments of the FPVM, as with the output root\nfault dispute game. A single ABSOLUTE_PRESTATE continues to be used, with the fault proof\nprogram identifying the type of step to perform based on the agreed prestate.","tokens":1527,"squid":"ink-governance","role":"Council Listener","at":1791262065363,"hash":"773c4ea834de5367281a29037eb3844ff7248ab1"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-v4-on-avalanche/25165/8","domain":"governance.aave.com","title":"[ARFC] Deploy Aave V4 on Avalanche - Governance / New Market - Aave","text":"GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n Jun 17\n\n 8 / 8\n\n Jul 11\n\n Jul 11\n\n post by AaveLabs on Jun 17\n\n post by LlamaRisk on Jun 17\n\n post by Mschmenk13 on Jun 22\n\n 13 days later\n\n post by AaveLabs on Jul 6\n\n post by Abel189 on Jul 8\n\n Abel189\n\n I support this proposal because it extends Aave V4 to a network with a proven operational history and an established DeFi ecosystem. Building on Avalanche’s existing Aave deployment reduces execution risk while allowing the new Hub and Spoke architecture to expand in a controlled and structured manner.\nI also appreciate the phased deployment strategy, the differentiated spoke design, and the conservative initial caps, which demonstrate a careful balance between growth and risk management. The commitment to introducing a dedicated RWA Hub through a separate governance process is another positive aspect, as it keeps different risk profiles appropriately isolated.\nAs adoption grows, it will be important to continuously review liquidity distribution, utilization, incentives, and market performance to ensure that the deployment remains sustainable and that governance can adjust parameters as real-world usage evolves.\n\n post by AaveLabs on Jul 10\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The AIP for this proposal was successfully created, proposal#504, voting will start in less than 24hs.\n\n post by MconnectDAO on Jul 10\n\n MconnectDAO\n\n I support this ARFC. Deploying Aave v4 on Avalanche builds on an existing, battle-tested Aave market and a mature DeFi ecosystem, while using the new hub-and-spoke architecture and conservative initial caps to scale in a risk-aware way. If the DAO pairs this phased rollout with regular reviews of liquidity distribution, utilization and incentive efficiency, Aave can capture significant new volume on Avalanche with controlled downside and clear optionality for the future RWA Hub.\n\n post by Abel189 on Jul 11\n\n Abel189\n\n I support the activation of Aave V4 on Avalanche. Building on an established Aave deployment while introducing the new Hub and Spoke architecture through a phased rollout represents a balanced approach to protocol expansion.\nI appreciate the use of differentiated spokes, conservative initial caps, and a governance model that includes a temporary hardening phase before transitioning fully to DAO control. This provides an appropriate balance between operational security and progressive decentralization during the early stages of deployment.\nAs the market matures, I believe governance should continue to monitor liquidity distribution, utilization patterns, liquidation performance, and user adoption to ensure that parameters evolve based on real-world data while preserving the protocol’s long-term resilience.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h","tokens":821,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262072311,"hash":"a680e4b9ad2a26738efdecc53a187ee80c5eda2c"}
{"url":"https://ethresear.ch/t/the-road-to-post-quantum-ethereum-transaction-is-paved-with-account-abstraction-aa/21783/41","domain":"ethresear.ch","title":"The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA) - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 5\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n Feb 2025\n\n 23 / 23\n\n Mar 19\n\n Mar 19\n\n Load more posts above\n\n post by Nomadu27 on Oct 4, 2025\n\n 2 months later\n\n post by vbuterin on Nov 24, 2025\n\n post by seresistvanandras on Nov 24, 2025\n\n post by codebyMoh on Nov 26, 2025\n\n post by seresistvanandras on Nov 26, 2025\n\n post by seresistvanandras on Nov 27, 2025\n\n post by seresistvanandras on Nov 27, 2025\n\n post by paulangusbark on Dec 2, 2025\n\n post by seresistvanandras on Dec 3, 2025\n\n post by rdubois-crypto on Dec 3, 2025\n\n post by paulangusbark on Dec 3, 2025\n\n post by paulangusbark on Dec 4, 2025\n\n post by paulangusbark on Dec 5, 2025\n\n post by paulangusbark on Dec 5, 2025\n\n post by rdubois-crypto on Dec 11, 2025\n\n 23 days later\n\n post by SirSpudlington on Jan 3\n\n post by SirSpudlington on Jan 4\n\n SirSpudlington\n\n @pipavlo82 Thank you for your reply, I am glad you agree \n\nI am not the best person to ask when it comes to test vectors, but I do think they would be valuable for benchmarking purposes (and keeping everyone on the same page). With the wiring of PQ algorithms, it really depends on the way the algorithm is exposed. If with a precompile, I’d say the FIPS SHAKE version of the algorithm would be better because pure EVM based performance would not matter as much and it is the widely used standard. However, if EVM constrained then the Keccak-CTR-style PRNG would be better because of its gas efficiency. I like the “keep both versions” approach of EIP-8051/EIP-8052.\n\n 1 month later\n\n post by paulangusbark on Feb 5\n\n paulangusbark\n\n Just wanted to give a quick update on the work I’ve been doing. I found I was struggling to write the front end piece for my keccak variant so I instead used the shake256 solidity code that @rdubois-crypto provided in their link and made some minor modifications. It’s increased the gas consumption but I can now verify the NIST falcon signatures on chain (anvil). The 1024 version consumes just over 15 million gas while the 512 version consumes a little over 7.4 million gas. This is only with local testing and just a single test case for each for the time being so there could be some variation to that. I’m going to do some more testing before I publish the updates to my public repository but hope to provide those updates later this month.\n\n 11 days later\n\n post by paulangusbark on Feb 17\n\n paulangusbark\n\n I have updated the github repository with code that will work for falcon-512 verification on chain using SHAKE256. Once again that link is GitHub - Cointrol-Limited/QuantumAccount: An implementation of an ERC4337 wallet that uses FIPS 206 (falcon-1024) for signature verification\nI have also published the contract on Sepolia and updated etherscan with the contract details. That can be found here: Address: 0x6f70f347...3Ea76dB45 | Etherscan Sepolia\nI plan to release a free wallet in sepolia in the next week that uses the facon-512 implementation for anyone to try out.\n\n 1 month later\n\n post by paulangusbark on Mar 19\n\n paulangusbark\n\n I have just made another update to the repository link above. I was able to reduce gas consumption a further 37%. Falcon512 verification now uses ~4.7 million units of gas while Falcon1024 uses ~9.2 million. I also removed the public key encoding/decoding to reduce that consumption. Loading a public key now consumes ~1.1 million gas for 512 and ~2.7 million gas for 1024.\n\n Powered by Discourse","tokens":866,"squid":"ink-research","role":"Deep Scholar","at":1791262077886,"hash":"350858cc3606caea2734629ec6753cd897cac38a"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-v4-on-base/25427","domain":"governance.aave.com","title":"[ARFC] Deploy Aave V4 on Base - Governance / New Asset - Aave","text":"[ARFC] Deploy Aave V4 on Base \n\n GovernanceNew Asset\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n read \n\n 14\n min\n\n Aug 3\n\n 1 / 8\n\n Aug 3\n\n 11d ago\n\n post by AaveLabs on Aug 3\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Base thumbnail2880×1542 284 KB\n\nThis post has been updated on 2026-09-21 to reflect the strategic direction discussed and agreed with the DAO Service Providers, also to include the parameters provided by @LlamaRisk in this thread.\n\nSummary\nThis ARFC seeks community feedback on deploying Aave V4 on Base and activating an initial tokenized equities market.\nBase is an Ethereum Layer 2 incubated by Coinbase, with low transaction costs, native USDC liquidity, and access to a broad retail user base. Aave has operated on Base since 2023, and the network was among Aave’s first multi-chain deployments to surpass $1 billion in deposits.\nThe deployment would bring the Hub and Spoke architecture to one of Aave’s largest existing deployments. It would establish a dedicated Equities Hub, separating liquidity and risk for the tokenized equities market from other Aave markets on Base, while providing a foundation for specialized markets as the network develops.\nMotivation\nBase combines an established Aave deployment, growing stablecoin activity, and an expanding set of consumer applications, payments products, and trading venues. These conditions support demand for onchain credit infrastructure that can serve distinct use cases while maintaining clearly defined liquidity and risk boundaries.\nDeploying Aave V4 on Base would:\n\nUpgrade one of Aave’s largest existing deployments to the current protocol architecture.\nEstablish a dedicated market for tokenized equities, with USDC as the borrowable asset and tokenized equities used exclusively as collateral at launch.\nSeparate the liquidity and risk of this market from other Aave markets on Base through a dedicated Equities Hub.\nExtend Aave’s presence within the Base and Coinbase ecosystem as additional users, applications, and tokenized assets come onchain.\n\nThe initial market provides a focused implementation of the V4 architecture. A single pooled spoke will support the initial set of tokenized equities as collateral, allowing users to borrow USDC against diversified positions while maintaining asset-specific collateral factors. The equities themselves will not be borrowable at launch.\nCoinbase’s distribution, infrastructure, and institutional relationships may support a broader range of tokenized assets on Base over time. A dedicated V4 market provides a measured starting point for this activity, with a market structure designed to accommodate distinct collateral types and risk profiles without extending their exposure to other Aave markets.\nMarket Structure\nThe tokenized equities market is deployed through a dedicated Equities Hub on Base. USDC suppliers to the hub explicitly opt into lending against tokenized equity collateral, and this exposure is isolated from other Aave markets.\nThe Hub contains a single USDC reserve and two spokes. The Mag-7 Spoke supports USDC borrowing against the seven specified tokenized equities. The Tokenized USDC Spoke is supply only, providing vaults and aggregators with a composable USDC position without collateral exposure.\nWithin the Mag-7 Spoke, users may supply any combination of the seven tokenized equities as collateral and borrow USDC. Each asset retains its own collateral factor, so borrowing capacity remains determined by the composition of each position. Pooling the assets within one spoke allows diversified collateral positions to be managed within a single market.\nThe tokenized equities are collateral only at launch. Borrowing of equities, and positions that borrow one equity against another, are not enabled.\nSpecification\nDynamic Liquidation Bonus Configuration\n\nChain\nHub\nSpoke\nLiquidation Bonus Factor\nTarget Health Factor\nHealth Factor For Max Bonus\n\nBase\nEquities Hub\nMag-7 Spoke\n90.00%\n1.24\n0.90\n\nSpoke Parameters\nThe liquidation fee is 10%, consistent with the rest of Aave V4. The risk premium threshold is 0 for every reserve, as risk premiums are not in use, and liquidators can receive collateral as shares on every reserve.\n\nChain\nHub\nSpoke\nReserve\nCollateral Factor\nMax Liquidation Bonus\nBorrowable\nCollateral Risk\nLiquidation Fee\nRisk Premium Threshold\nReceive Shares\n\nBase\nEquities Hub\nMag-7 Spoke\nAAPLc\n78.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nAMZNc\n73.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nGOOGLc\n76.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nMETAc\n65.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nMSFTc\n79.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nNVDAc\n70.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nTSLAc\n65.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nUSDC\n0.00%\n-\nTRUE\n-\n-\n0\nTRUE\n\nAdd and Draw Caps\n\nChain\nHub\nSpoke\nReserve\nAdd Cap\nDraw Cap\n\nBase\nEquities Hub\nMag-7 Spoke\nAAPLc\n15,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nAMZNc\n10,500\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nGOOGLc\n15,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nMETAc\n5,800\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nMSFTc\n5,200\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nNVDAc\n24,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nTSLAc\n14,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nUSDC\n32,000,000\n21,000,000\n\nBase\nEquities Hub\nTokenized USDC Spoke\nUSDC\n1,000,000\n0\n\nInterest Rate Curve\n\nChain\nHub\nAsset\nBase Drawn Rate\nRate Growth Before Optimal\nRate Growth After Optimal\nOptimal Usage Ratio\nLiquidity Fee\n\nBase\nEquities Hub\nUSDC\n0.00%\n4.00%\n20.00%\n90.00%\n10.00%\n\nPrice Feeds\nEach reserve is priced by the Chainlink total return feed for the token, which carries the issuer multiplier and follows the 24/5 US equities market hours. These are standard feeds. Smart Value Recapture variants are not used at rollout. USDC is priced by the Chainlink USDC/USD feed on Base through the stable price cap adapter, with the cap set at 1.04.\n\nReserve\nToken\nChainlink feed\n\nAAPLc\n0xb200000000000000000000C2e324d24d7eEcd1fb\n0x787f13dEa48Db0897CbCDD985de77809D837F988\n\nAMZNc\n0xb200000000000000000000d9192b6B456483C2E8\n0x06A8E4b3aBB3B7543d8396FB2B763d22820cB295\n\nGOOGLc\n0xb2000000000000000000002D0BA3164cc74f58B7\n0x5bF49E0ffA937CE2FfF033c739aD7C634c4D34F2\n\nMETAc\n0xb2000000000000000000008bC8786B856E61707C\n0x6526aE6797A76123638b863AeE4dD27Ba4E4b27D\n\nMSFTc\n0xB200000000000000000000Ab99cFa739E253872B\n0xeB10A6c9aa7E537aEd766C08c35Dae35B321b18c\n\nNVDAc\n0xB20000000000000000000078ee7ce2fE4908108C\n0x04689a41629776563E6822F76f2e57D148d28513\n\nTSLAc\n0xb2000000000000000000001e800a7f5189430cD0\n0xFaf869185383a24F8cb00e27BdA6b63B9905DCb4\n\nUSDC\n0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\n0x7e860098F58bBFC8648a4311b374B1D669a2bc6B, with the stable price cap adapter at 1.04\n\nNext Steps\n\nGather community feedback and service provider recommendations on this ARFC during a five day forum discussion period.\nAave Labs and LlamaRisk will complete their assessments and append the proposed initial assets and the Hub and Spoke configuration to this proposal.\nEscalate the proposal to an ARFC Snapshot for a three day off-chain vote.\nFollowing a successful Snapshot, submit an AIP for an onchain vote to deploy Aave V4 on Base.\n\nUseful Links\n\nBase website\nBase developer documentation\nAave V4 overview\n\nDisclosures\nAave Labs is the author of this proposal and has received no compensation from third parties for its creation.\nCopyright\nCopyright and related rights waived via CC0.\n\n Coinbase B20 Equities on Base Assessments\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n 4\n\n read \n\n 14\n min\n\n post by cedricbrown on Aug 8\n\n cedricbrown\n\n Avalanche, Arc and Tempo each ran a Temp Check before their ARFC, and Base going straight to ARFC only reads as consistent if this is treated as an upgrade of an existing deployment rather than a new market. If it is an upgrade, then the migration approach for existing V3 positions is not a detail to finalize during the discussion period, it is the proposal. The Adoption Paths framework already set the expectation that v4 runs in parallel with v3 for 24 to 36 months and that early TVL is dominated by migration flow, with incentives and rate differentials inflating borrows without creating net new credit demand, and Base is where that distortion will be largest because the existing V3 book there is one of the biggest Aave has.\nThree shapes for the V3 posture, and the ARFC should pick one before Snapshot rather than after. Run V4 alongside V3 with no scheduled change and let the market migrate on its own, which forces no exits but leaves two venues quoting the same assets on one chain for years while rates diverge and depth thins unpredictably on one side. Deploy with a dated V3 posture change written into the same proposal, for example freezing new supply on V3 Base once V4 Hub caps clear a stated utilization threshold, which produces a clean end state but commits to a trigger before the Hub has any Base specific operating history. Deploy with a deliberately narrow initial scope covering the collateral types V3 serves worst, leaving the majors on V3 until the Hub has been through a real liquidation event, which slows headline TVL but keeps the migration flow small enough to actually read.\nThe third, paired with one reporting commitment: report supply migrated from V3 Base separately from net new supply from the first day the Hub is live. Without that split the Base deployment will produce the largest and least informative TVL number in the V4 rollout, and every later cap decision on Base will be argued from it.\n\n 10 days later\n\n post by signalxu on Aug 18\n\n signalxu\n\nIt’s been two weeks, hasn’t there been a snapshot vote yet?\n\n 10 days later\n\n post by ArctekAudits on Aug 29\n\n ArctekAudits\n\n Hi Aave Labs,\nI have been reviewing the proposed V4 deployment on Base. Since the Hub configuration, oracle setup, deployment contracts and V3 migration approach are still being finalized, has the security review plan for the Base specific deployment boundary also been defined?\nA focused review could cover the Base Hub and Spoke configuration, oracle and asset onboarding controls, deployment parameters and the V3 migration path before the AIP is submitted.\nI run Arctek Audits and can send a concise proposed scope mapped to the final contracts and commit if an independent reviewer has not yet been selected.\n\n 23 days later\n\n post by LlamaRisk on Sep 21\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Tokenized Equities on Aave V4 Base: Initial Market Parameters\nUpdate, 24 September 2026. The full technical review of the Coinbase B20 issuance stack, the token standard, and the price feed has been posted in the Coinbase B20 Equities on Base Assessments thread. Section 4.6 below adds the risk steward bounds for the Equities Hub.\nSummary\nThis post presents LlamaRisk’s recommended initial parameters for the tokenized equities market on Aave V4 Base. The market is deployed as a dedicated Equities Hub with a single pooled spoke, in which the Magnificent Seven US technology stocks in their Coinbase B20 form, B20 being Base’s native token standard (AAPLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc, and TSLAc) serve as collateral and USDC is the only borrowable asset. The equities themselves are not borrowable at launch. An in-depth review of the Coinbase B20 issuance stack is available in the assessments thread.\nThe initial stage operates on Chainlink’s 24/5 tokenized equity feeds, which publish from Sunday evening to Friday evening ET and hold the last published value over weekends and market holidays. While the underlying market is closed, the collateral value of a position does not change, its health factor can fall only through interest accrual, and the price published at the reopen reflects, in a single step, any information that arrived during the closure. The parameters are designed around this property. The liquidation bonus is sized on the cost of each pathway a liquidator can take to turn seized tokens back into USDC, since a liquidator may hold the collateral for hours or days while it redeems, sells, or hedges. Continuous monitoring of market and external data will be in place from launch.\nThis setup is an intermediate step. Chainlink is expected to bring 24/7 feeds for the same tokens to Base. Once those feeds are in production, the parameters may be revisited so that liquidations can execute through the weekend, with session-dependent parameters, automated handling of corporate actions, and feed safeguards. The full assessment of the issuer structure, the token standard, and the price feed is in the technical review linked above, and the parameter methodology and the rollout plan will be presented in a separate post.\n1. Market Structure\nimage1810×1010 81.2 KB\nSource: LlamaRisk, 17 September 2026\nThe market is deployed as a dedicated Equities Hub on Base. Stablecoin suppliers who join the hub opt into equity-collateralized lending explicitly, and the exposure does not extend to other Aave markets. The hub holds one USDC reserve, one lending spoke, and a supply-only tokenized spoke for USDC that gives vaults and aggregators a composable position without collateralization.\nThe lending spoke pools the seven names. A user can post any combination of the seven tokens as collateral and borrow USDC against it, with each token counted at its own collateral factor. Pooling reduces the volatility of position health for a diversified basket, since a single name can gap 20% to 30% on an earnings surprise while a basket of the seven rarely moves by double digits together. Collateral factors remain per token, so pooling does not by itself increase borrowing power. The equities are collateral only. Equity borrowing and equity-against-equity positions are not enabled.\n2. Pricing Setup for the Initial Stage\nUS equities trade in sessions, while the lending market accepts deposits, borrows, and liquidations at any hour. The price feed connects the two, and the way it behaves while the stock market is closed determines which risks the parameters have to cover.\nEach token is priced by a Chainlink tokenized equity feed that multiplies the price of the underlying share by the issuer’s token multiplier and publishes the product as a single total return price. The multiplier starts at 1.0 and moves only on corporate actions. A reinvested dividend raises it by the dividend net of the distribution fee and withholding tax, and a stock split multiplies it by the split ratio at the same time as the share price divides by that ratio. The market consumes the published value directly.\nThe underlying share price is assembled from the four sessions in which US equities trade, which gives the feed an operating window from Sunday 20:00 ET to Friday 20:00 ET.\n\nSession\nHours, ET\nDays\nSourcing\n\nPre-market\n04:00 to 09:30\nMonday to Friday\nExtended-hours venues, several providers\n\nRegular\n09:30 to 16:00\nMonday to Friday\nExchange data, multi-sourced\n\nPost-market\n16:00 to 20:00\nMonday to Friday\nExtended-hours venues, several providers\n\nOvernight\n20:00 to 04:00\nSunday evening to Friday morning\nBlue Ocean ATS\n\nClosed\n20:00 Friday to 20:00 Sunday, and US market holidays\n\nNo updates, last value held\n\nOnchain, the feeds are configured with a 0.5% deviation threshold and a 24-hour heartbeat, so during open sessions a new value is written whenever the offchain price moves 0.5% from the last published value. While the market is closed the feed publishes nothing, so the last value published before the Friday close stands, with a stale timestamp, until the Sunday evening reopen. The same applies on US market holidays.\nTwo consequences follow for the market. First, during a closure the collateral price does not move and a health factor can fall only through interest accrual. The market itself does not pause, and a position that crosses the threshold this way can be liquidated at any time, including over the weekend. Second, when the feed resumes, the price published at the reopen reflects whatever information arrived while the market was closed, and a position that this repricing pushes under water becomes liquidatable only at that point. In practice, the first opportunity to liquidate a position that deteriorated on a Friday afternoon is the Sunday evening reopen, and the first opportunity to hedge the seized collateral in a deep book is the Monday open.\nDuring a corporate action, the issuer pauses its onchain registry flag, the feed holds its last value, the new multiplier is applied, and the feed resumes once the new underlying price multiplied by the new multiplier has been confirmed to match the held value. Minting and redemption pause for the same window while token transfers continue. The affected reserve is expected to be paused for that window as well, since a token that keeps changing hands against a held price is the state in which a mispriced liquidation could occur.\n3. Parameters\n3.1 Collateral Factor\nIn Aave V4 the collateral factor is both the borrowing limit and the liquidation threshold. On a 24/5 feed, the risk it is meant to cover is the fall the collateral may suffer between the moment a position becomes liquidatable and the moment a liquidator is able to close it. Outside regular cash hours the length of that interval is uncertain. A position that crosses the threshold at 17:00 could be closed minutes later on an extended-hours venue, during the overnight session, or only at the next regular open when a desk can hedge in a deep book. A position that crosses the threshold on a Friday afternoon is unlikely to be closed before the Sunday evening reopen, and may not be closed before the Monday open.\nThe collateral factor is therefore sized without assuming anything about that timing, other than that the liquidation is completed within five minutes of the next regular open. For every off-hours minute in the last eight years, a position is placed exactly at the liquidation threshold and the collateral factor is required to leave no bad debt if the liquidation executes at any live minute between that moment and five minutes past the next regular open. Weekend and holiday closures count toward the delay. Because the feed republishes only on a 0.5% move, the published price may sit up to 0.5% above the market, and that allowance is charged on every starting minute. The debt accrues interest at 24%, the top of the USDC rate curve, over the longest closure in the history, which is 92 hours and 35 minutes from a half-day close into a long weekend. Writing D𝐷 for the fall from the published price to the lowest executable price and i𝑖 for the interest accrued over that span, a full seizure at the 5.5% maximum bonus leaves no bad debt when\n\n\\mathrm{CF}\\,(1 + \\mathrm{LB})\\,(1 + i) \\le 1 - D.\nCF(1+LB)(1+𝑖)≤1−𝐷.\nThe price history consists of one-minute bars for the seven names on Nasdaq from May 2018 to August 2026 across the pre-market, regular, and post-market sessions, supplemented by the overnight venue from August 2025, with seven stock splits corrected. Minutes in which the 24/5 feed would be frozen are excluded as execution minutes.\nimage2520×1080 174 KB\nSource: LlamaRisk, Nasdaq and Blue Ocean one-minute bars, 20 August 2026\nThe largest fall in the record gives a first reading of the collateral factor for each name. For AMZN, GOOGL, META, and NVDA it is a post-market earnings reaction. For AAPL and MSFT it is the evening before the March 2020 weekend, and for TSLA the evening before the Labor Day weekend of 2020. Each of these falls is a single observation, and the record carries no information about a fall rarer than it contains. To address this, an extreme-value tail is also fitted to the bad nights of each name and read at the fall expected once in ten years, once on each name alone and once jointly across the seven names with a shared tail shape. The two fits can disagree for a name whose own tail departs from the class, and the record cannot resolve which is right, so the lowest of the three readings is adopted.\nimage2520×1080 153 KB\nSource: LlamaRisk, 16 September 2026\n\nName\nCollateral factor\n\nAAPLc\n0.78\n\nAMZNc\n0.73\n\nGOOGLc\n0.76\n\nMETAc\n0.65\n\nMSFTc\n0.79\n\nNVDAc\n0.70\n\nTSLAc\n0.65\n\nThe collateral factors will be refitted as the record grows, and they are the first parameters expected to be revisited in the second stage.\n3.2 Liquidation Bonus\nA liquidator on this market cannot always dispose of the collateral as soon as it is seized. Redemption with the issuer is open only to vested holders and settles during regular hours, the secondary market on Base is thin, and outside regular hours the tokens can only be hedged until the next open. The bonus is therefore sized to compensate a liquidator for the full pathway from repaying the debt to holding USDC again, whatever form that pathway takes on the day. The net bonus a route requires is\n\nb_n = \\frac{1 + \\delta}{(1 - d)\\,(1 - k)} - 1,\n𝑏𝑛=1+𝛿(1−𝑑)(1−𝑘)−1,\nwhere \\delta𝛿 is the allowance between the published price and the market at commitment, set at 0.5% from the feed’s deviation threshold, d𝑑 is the move of the stock between commitment and the moment the hedge is in place, taken as a stressed 2.02%, and k𝑘 is the sum of the cash costs of the route as a fraction of the hedge notional. The gross bonus paid by the borrower is b_n / (1 - \\rho)𝑏𝑛/(1 −𝜌), with \\rho𝜌 the 10% liquidation fee. Three routes are available, and they differ mainly in k𝑘.\nRedemption through the issuer. During regular market hours, a liquidator with redemption access repays the debt, receives the tokens, shorts the same number of underlying shares, submits an in-kind redemption, and delivers the redeemed shares against the short. The cash costs are the 5 bps redemption fee, brokerage, clearing, stock borrow, and the opportunity cost of the USDC over a 72-hour hold, partly offset by interest on the short-sale proceeds. This is the least expensive route and the floor for any bonus.\nSale on the secondary market. A liquidator that has not been whitelisted with the issuer cannot redeem and sells the tokens on Base instead. In this case k𝑘 is the price impact of the sale. Between USD 0.3M and USD 1.1M of each token can be sold into USDC within a 2% price impact, so a liquidation in the low hundreds of thousands of dollars costs about 1% and one approaching the depth limit about 2%. Larger liquidations would have to be split across blocks and days or routed through a party that can redeem.\nPerpetual hedge outside regular hours. Between the post-market close and the next open, a liquidator shorts a linear perpetual with matched share exposure, holds it until the redeemed shares can be sold at the open, and then closes both legs. In addition to the redemption costs, this route pays the basis between the perpetual and the stock when the legs are closed, funding while the short is open, and taker fees. The stress case takes a 0.5% basis at exit, 0.85% of funding and 0.15% of fees.\n\nRoute\nOracle allowance\nHedge latency stress\nRoute cost k𝑘\nNet bonus required\nGross bonus at a 10% fee\n\nRedemption, regular hours\n0.50%\n2.02%\n0.06%\n2.64%\n2.93%\n\nSecondary sale on Base\n0.50%\n2.02%\n2.00%\n4.67%\n5.18%\n\nPerpetual hedge, stressed\n0.50%\n2.02%\n1.50%\n4.13%\n4.59%\n\nThe maximum liquidation bonus is set at 5.5% for every name, so that each of the three pathways is paid for. It covers the redemption route with a wide margin and the stressed perpetual route with a comfortable one, and it covers the secondary-market route up to the depth Base offers today. It is in line with the 5.55% maximum bonus on the BTC and WETH reserves of the Main Spoke on Ethereum. The spoke uses the same bonus curve as the Main Spoke. With a 90% liquidation bonus factor the bonus is 4.95% at a health factor of 1.0, which already covers the redemption and perpetual routes, and reaches the 5.5% maximum at a health factor of 0.90, above the point at which any of the seven collateral factors would produce bad debt. A liquidation restores the position to a health factor of 1.24. Liquidations on this market do not run through Smart Value Recapture at rollout, so the liquidator keeps the whole bonus after the 10% fee.\n3.3 Caps\nThe collateral factor and the bonus protect the market against price moves, and the caps protect it against size. A liquidator that seizes these tokens may hold them for hours or days while it redeems, sells, or hedges, so the caps keep the amount a liquidator may have to absorb within the depth of the venues it can use.\n\nRedemption through the issuer is available to allowlisted authorised participants and carries no onchain rate limit. Primary throughput is observable on the minting side: the issuer’s supply manager contract on Base (0xd1ca…664c) limits the amount of each token its minter can create per 24 hours, which corresponds to about USD 5M per token per day at current prices.\nThe secondary market on Base is thin. Between USD 0.3M and USD 1.1M of each token can be sold into USDC within a 2% price impact, and the outstanding supply of every token is between USD 1M and USD 4M.\nPerpetual futures are the venue in which an off-hours liquidation is hedged. Across Hyperliquid, Binance, OKX, and Lighter, the seven names carry between USD 44M and USD 302M of open interest each, most of it on Hyperliquid and Binance.\n\nEach add cap is set so that a liquidation of the entire cap could be processed through the issuer within one day of its mint allowance and hedged on the perpetual venues within a small fraction of the name’s open interest. For AAPL, GOOGL, NVDA, and TSLA one day of the mint allowance is the lower of the two bounds and sets the cap, for META 5% of open interest sets it, and for AMZN and MSFT the caps sit at about half of one day’s mint allowance and 6% of open interest. Together the caps amount to USD 29.3M of collateral. A loss-budget view of the same book would allow more at these collateral factors, so liquidity is the binding constraint at launch.\n\nReserve\nPerp open interest, four venues\n5% of open interest\nMint allowance per day\nDEX depth at 2% impact\nSupply outstanding\nAdd cap\nAdd cap, USD\n\nAAPLc\nUSD 125.4M\nUSD 6.27M\n15,500 (USD 5.14M)\nUSD 0.72M\n6,077 (USD 2.02M)\n15,000\nUSD 4.98M\n\nAMZNc\nUSD 45.2M\nUSD 2.26M\n19,100 (USD 4.69M)\nUSD 0.32M\n5,642 (USD 1.39M)\n10,500\nUSD 2.58M\n\nGOOGLc\nUSD 178.1M\nUSD 8.90M\n15,700 (USD 5.36M)\nUSD 0.69M\n5,914 (USD 2.02M)\n15,000\nUSD 5.13M\n\nMETAc\nUSD 79.1M\nUSD 3.96M\n8,200 (USD 5.55M)\nUSD 0.64M\n2,365 (USD 1.60M)\n5,800\nUSD 3.93M\n\nMSFTc\nUSD 44.4M\nUSD 2.22M\n10,300 (USD 5.06M)\nUSD 0.32M\n2,652 (USD 1.30M)\n5,200\nUSD 2.56M\n\nNVDAc\nUSD 301.5M\nUSD 15.08M\n24,000 (USD 5.11M)\nUSD 1.08M\n19,428 (USD 4.14M)\n24,000\nUSD 5.11M\n\nTSLAc\nUSD 103.0M\nUSD 5.15M\n14,300 (USD 5.10M)\nUSD 0.27M\n2,988 (USD 1.07M)\n14,000\nUSD 4.99M\n\nSource: LlamaRisk, Hyperliquid, Binance, OKX, Lighter, KyberSwap, and Base onchain data, 17 September 2026\nThe USDC draw cap on the spoke corresponds to the debt the collateral caps can support at their collateral factors, USD 21.1M, rounded to USD 21M. The USDC add cap is set at USD 32M, so that supply can run ahead of the draw cap and keep utilization within the optimal range. Several caps are above a token’s outstanding supply today. The tokens are minted on demand by authorised participants, and supply is expected to follow the collateral demand of the market. The caps will be revisited through the risk steward process as supply and venue depth grow.\n3.4 USDC Interest Rate\nUSDC is the only borrowable asset. Its rate follows the standard kinked curve, with a 0% base drawn rate, 4% rate growth before the optimal usage ratio and 20% after it, at a 90% optimal usage ratio and a 10% liquidity fee. The borrow rate therefore peaks at 24%, which is the rate charged on the debt over the longest closure in the collateral factor derivation. The optimal usage ratio is set at 90%, below the 92% used on deeper stablecoin reserves, because the hub starts with a single borrowable reserve and no credit line from a general market.\n4. Specification\n4.1 Dynamic Liquidation Bonus Configuration\n\nChain\nHub\nSpoke\nLiquidation Bonus Factor\nTarget Health Factor\nHealth Factor For Max Bonus\n\nBase\nEquities Hub\nMag-7 Spoke\n90.00%\n1.24\n0.90\n\n4.2 Spoke Parameters\nThe liquidation fee is 10%, consistent with the rest of Aave V4. The risk premium threshold is 0 for every reserve, as risk premiums are not in use, and liquidators can receive collateral as shares on every reserve.\n\nChain\nHub\nSpoke\nReserve\nCollateral Factor\nMax Liquidation Bonus\nBorrowable\nCollateral Risk\nLiquidation Fee\nRisk Premium Threshold\nReceive Shares\n\nBase\nEquities Hub\nMag-7 Spoke\nAAPLc\n78.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nAMZNc\n73.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nGOOGLc\n76.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nMETAc\n65.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nMSFTc\n79.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nNVDAc\n70.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nTSLAc\n65.00%\n5.50%\nFALSE\n0\n10.00%\n0\nTRUE\n\nBase\nEquities Hub\nMag-7 Spoke\nUSDC\n0.00%\n-\nTRUE\n-\n-\n0\nTRUE\n\n4.3 Add and Draw Caps\n\nChain\nHub\nSpoke\nReserve\nAdd Cap\nDraw Cap\n\nBase\nEquities Hub\nMag-7 Spoke\nAAPLc\n15,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nAMZNc\n10,500\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nGOOGLc\n15,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nMETAc\n5,800\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nMSFTc\n5,200\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nNVDAc\n24,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nTSLAc\n14,000\n0\n\nBase\nEquities Hub\nMag-7 Spoke\nUSDC\n32,000,000\n21,000,000\n\nBase\nEquities Hub\nTokenized USDC Spoke\nUSDC\n1,000,000\n0\n\n4.4 Interest Rate Curve\n\nChain\nHub\nAsset\nBase Drawn Rate\nRate Growth Before Optimal\nRate Growth After Optimal\nOptimal Usage Ratio\nLiquidity Fee\n\nBase\nEquities Hub\nUSDC\n0.00%\n4.00%\n20.00%\n90.00%\n10.00%\n\n4.5 Price Feeds\nEach reserve is priced by the Chainlink total return feed for the token, which carries the issuer multiplier and follows the 24/5 US equities market hours. These are standard feeds. Smart Value Recapture variants are not used at rollout. USDC is priced by the Chainlink USDC/USD feed on Base through the stable price cap adapter, with the cap set at 1.04.\n\nReserve\nToken\nChainlink feed\n\nAAPLc\n0xb200000000000000000000C2e324d24d7eEcd1fb\n0x787f13dEa48Db0897CbCDD985de77809D837F988\n\nAMZNc\n0xb200000000000000000000d9192b6B456483C2E8\n0x06A8E4b3aBB3B7543d8396FB2B763d22820cB295\n\nGOOGLc\n0xb2000000000000000000002D0BA3164cc74f58B7\n0x5bF49E0ffA937CE2FfF033c739aD7C634c4D34F2\n\nMETAc\n0xb2000000000000000000008bC8786B856E61707C\n0x6526aE6797A76123638b863AeE4dD27Ba4E4b27D\n\nMSFTc\n0xB200000000000000000000Ab99cFa739E253872B\n0xeB10A6c9aa7E537aEd766C08c35Dae35B321b18c\n\nNVDAc\n0xB20000000000000000000078ee7ce2fE4908108C\n0x04689a41629776563E6822F76f2e57D148d28513\n\nTSLAc\n0xb2000000000000000000001e800a7f5189430cD0\n0xFaf869185383a24F8cb00e27BdA6b63B9905DCb4\n\nUSDC\n0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913\n0x7e860098F58bBFC8648a4311b374B1D669a2bc6B, with the stable price cap adapter at 1.04\n\n4.6 Risk Steward Bounds\nThe Aave Risk Stewards operate on the Equities Hub within the bounds below. They follow the bounds activated on Aave V4 Ethereum and Avalanche in the ARFC to activate the Aave Risk Stewards on Aave V4, with a shorter cooldown on caps and on the spoke parameters. Caps move on a 12-hour cooldown because the market starts small, at about USD 29.3M in collateral caps, and we plan to keep the caps close to the supplied and drawn amounts and raise them as demand shows up. Two cap changes a day at fixed times keep signing predictable, and caps can come down overnight or over a weekend if AMM liquidity thins. The collateral factor, the maximum liquidation bonus, and the liquidation configuration share a 36-hour cooldown so that every spoke parameter moves on one cadence, with the maximum change per update unchanged from the other V4 instances.\n\nScope\nParameter\nCooldown\nMax change per update\nMode\nNote\n\nHub\nAdd cap\n12 hours\n100%\nRelative\n36 hours on V4 Ethereum and Avalanche\n\nHub\nDraw cap\n12 hours\n100%\nRelative\n36 hours on V4 Ethereum and Avalanche\n\nHub\nOptimal usage ratio\n36 hours\n3%\nAbsolute\n\nHub\nBase drawn rate\n36 hours\n3%\nAbsolute\n\nHub\nRate growth before optimal\n36 hours\n3%\nAbsolute\n\nHub\nRate growth after optimal\n36 hours\n20%\nAbsolute\n\nSpoke\nCollateral risk\n36 hours\n300%\nAbsolute\n\nSpoke\nCollateral factor, update\n36 hours\n0.5%\nAbsolute\n72 hours on V4 Ethereum and Avalanche\n\nSpoke\nCollateral factor, new reserve\n36 hours\n5%\nAbsolute\n72 hours on V4 Ethereum and Avalanche\n\nSpoke\nMax liquidation bonus, update\n36 hours\n0.5%\nAbsolute\n72 hours on V4 Ethereum and Avalanche\n\nSpoke\nMax liquidation bonus, new reserve\n36 hours\n0.5%\nAbsolute\n72 hours on V4 Ethereum and Avalanche\n\nSpoke\nTarget health factor\n36 hours\n5%\nRelative\n72 hours on V4 Ethereum and Avalanche\n\nSpoke\nHealth factor for max bonus\n36 hours\n5%\nRelative\n72 hours on V4 Ethereum and Avalanche\n\nSpoke\nLiquidation bonus factor\n36 hours\n5%\nAbsolute\n72 hours on V4 Ethereum and Avalanche\n\nOracle\nStable price cap\n72 hours\n0.5%\nRelative\nApplies to USDC, cap at 1.04\n\nOracle\nLST price cap\n72 hours\n5%\nRelative\nNot used\n\nOracle\nPendle discount rate\n48 hours\n0.025\nAbsolute\nNot used\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n LlamaRisk - Monthly Community Update\n\n post by AaveLabs on Sep 21\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The ARFC to Deploy Aave V4 on Base has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here\n\n post by AaveLabs on Sep 25\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave Labs is finalizing preparations to activate Aave V4 on Base and wants to give the community formal advance notice ahead of execution. The first market is the Equities Hub, holding seven Coinbase issued tokenized equities (AAPLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc, TSLAc) alongside USDC, with a MAG7 Spoke where the equities are collateral only and not borrowable. USDC is the sole borrowable asset. The activation also enables the Equities USDC Tokenization Spoke, which acts as an ERC-4626 entry point for USDC deposits across all spokes of the USDC reserve on the Equities Hub. The market is deployed and fully configured with every spoke registration halted, so no supply, borrow, or liquidity movement is possible until activation.\nThe ARFC to deploy Aave V4 on Base has been raised to Snapshot, using the risk parameters LlamaRisk recommended in this thread. The Snapshot vote is taken as the binding vote for this execution, and activation proceeds only if the Snapshot result is positive.\nThis activation does not take the form of an AIP and carries no Aave Governance V3 vote. The Aave V4 Protocol Security Council 0x187AAE17d4931310B3fc75743e7F16Bdc9eD77e9 (5-of-8, the same signer set as on Ethereum) carries it out directly through its Executor 0xA9D9923A1ADC1200771aaaA38CFeD6A5b8483d70, which holds HUB_CONFIGURATOR_DOMAIN_ADMIN_ROLE on the Base V4 AccessManager. The deployed configuration was verified onchain against LlamaRisk’s recommendations.\nThese addresses are added to the aave-address-book and permissions-book. For transparency, the table below lists the price feed used for each Hub reserve, following LlamaRisk’s recommendations. The USDC reserve uses the Chainlink USDC/USD feed rather than an SVR feed:\n\nReserve\nPrice source\nKind\nFeeds\n\nAAPLc\n0x787f13dEa48Db0897CbCDD985de77809D837F988\nChainlink OCR2 proxy\nCoinbase AAPL/USD\n\nAMZNc\n0x06A8E4b3aBB3B7543d8396FB2B763d22820cB295\nChainlink OCR2 proxy\nCoinbase AMZN/USD\n\nGOOGLc\n0x5bF49E0ffA937CE2FfF033c739aD7C634c4D34F2\nChainlink OCR2 proxy\nCoinbase GOOGL/USD\n\nMETAc\n0x6526aE6797A76123638b863AeE4dD27Ba4E4b27D\nChainlink OCR2 proxy\nCoinbase META/USD\n\nMSFTc\n0xeB10A6c9aa7E537aEd766C08c35Dae35B321b18c\nChainlink OCR2 proxy\nCoinbase MSFT/USD\n\nNVDAc\n0x04689a41629776563E6822F76f2e57D148d28513\nChainlink OCR2 proxy\nCoinbase NVDA/USD\n\nTSLAc\n0xFaf869185383a24F8cb00e27BdA6b63B9905DCb4\nChainlink OCR2 proxy\nCoinbase TSLA/USD\n\nUSDC\n0xC7d0f8dCC1F860ca752054c59Ea82Ba2A5AaB50c\nPriceCapAdapterStable\nChainlink USDC/USD, cap 1.04\n\nBased on LlamaRisk’s recommendation in this thread, a different configuration compared to that of Ethereum and Avalanche (see Snapshot) is applied for the Risk Stewrads in the Equities Hub. They would operate within the same bounds as on those networks, but with shorter cooldowns on caps (12 hours instead of 36 hours) and on spoke parameters (36 hours instead of 72 hours), while the maximum change per update is unchanged. These configurations will be implemented through the AIP process in the upcoming days.\nAt execution, the payload clears the halted flag on every spoke registration across the Hub, making the MAG7 Spoke and the Equities USDC Tokenization Spoke fully operational on Base. Caps and oracle configuration are unchanged from deployment, and the action changes no roles, owners, or oracles.\nReferences\n\nImplementation: AaveV4Base_AaveV4BaseActivation_20260919\nTests: AaveV4Base_AaveV4BaseActivation_20260919\nSnapshot\n\n AL Development Update | September 2026\n\n post by AaveLabs on Sep 25\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave V4 on Base has been successfully activated. The Protocol Security Council lifted the temporary halt placed on the market at deployment, following the same execution described in the previous update, and the market is now fully operational.\nThe instance is live and accessible through pro.aave.com, with USDC, APLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc and TSLAc available as reserves from launch, per the configuration and price feeds shared previously in this thread.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Umbrella on Aave v4: Coverage Framework and Initial Market Parametrization\n\n Governance\n\n 1\n\n 227\n\n Sep 12\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d","tokens":9676,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262083260,"hash":"edad8789bdc411a91ed82d34ab7ee6cea2b6955c"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 1 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n asanso\n\n This is Part 2 of a blog series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we introduced the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In this installment, we’ll dive deeper into Falcon, a promising post-quantum signature algorithm, examining its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework.\nFalcon Signature Scheme - Technical Overview\nFalcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) builds upon the lattice-based signature framework of Gentry, Peikert, and Vaikuntanathan (GPV). It applies this framework to NTRU lattices and employs a “fast Fourier sampling” trapdoor sampler. The scheme relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is considered computationally hard to solve in the general case, even with quantum computers, as no efficient solving algorithm is currently known.\nCore Components\nFalcon is based on the hash-and-sign paradigm and is an evolution of the traditional RSA signature scheme. However, instead of relying on number-theoretic problems, it leverages the hardness of lattice-based problems. Falcon’s security is based on the hardness of finding short vectors in NTRU lattices, leveraging Gaussian sampling techniques for generating trapdoor bases with reduced norms. This ensures efficient key generation and signing.\n\nKey Generation:\n\nGiven an NTRU polynomial ring ( \\mathbb{Z}[X] / (X^n + 1))(ℤ[𝑋]/(𝑋𝑛 +1)), a private key consists of two short polynomials ( f, g )(𝑓,𝑔) satisfying the NTRU equation.\nThe public key is derived as ( h = g / f )(ℎ =𝑔/𝑓) in the ring ( \\mathbb{Z}_q[X] / (X^n + 1) )(ℤ𝑞[𝑋]/(𝑋𝑛 +1)).\n\nSigning Process:\n\nA message is hashed into a challenge vector in the lattice domain.\nA short solution is sampled using fast Fourier sampling, ensuring a compact signature size while maintaining security against lattice reduction attacks.\nThe signature consists of the short lattice vector satisfying the challenge.\n\nVerification:\n\nThe verifier checks whether the signature satisfies the public key relation in the lattice ring.\nVerification involves computing norms and ensuring the validity of the lattice basis under modular arithmetic.\n\nFalcon is designed to offer a robust post-quantum signature solution, combining lattice-based cryptography with efficient sampling techniques. While its security benefits are clear, like any cryptographic system, it presents certain trade-offs in terms of complexity and implementation challenges. Now, let’s break down the highlights, potential pitfalls, and some of the more challenging aspects of Falcon.\nThe Good\nAside from the well-known benefits highlighted by NIST, such as Compact Signatures, Fast Operations (efficient key generation and verification via FFT techniques), and Security Proofs (relying on lattice reductions and worst-case hardness assumptions). Falcon also provides Ethereum-specific advantages. Notably, it has a well-defined worst-case running time, making it particularly useful for the Ethereum Virtual Machine (EVM), where predictable performance and execution times are essential for scalability and reliability.\nThe Bad\nFalcon’s reliance on floating-point arithmetic and specialized number-theoretic transforms (NTT/FFT) can lead to implementation complexity and sensitivity to side-channel vulnerabilities during signing. However, this is NOT a significant concern for Ethereum, as signing occurs off-chain, where performance is less critical. The main focus is on optimizing the verification process, which happens on-chain, ensuring efficient and secure execution.\nThe Gnarly\nThere has been ongoing research into efficiently aggregating Falcon signatures, such as the work presented in this paper. Assuming the aggregation will be efficient enough, using Falcon in the consensus layer to replace the BLS signature (instead of the alternative proposal based on Hash-Based Multi-Signatures) would help maintain a more homogeneous stack across the Ethereum network.\nConclusion\nFalcon is a strong candidate for post-quantum cryptography applications, including blockchain systems like Ethereum, where signature size and verification efficiency are critical. In Part 3 of the series, we will begin implementing the hybrid approach introduced in Part 1, initially focusing on Account Abstraction and a Solidity contract for Falcon verification, bridging the gap between post-quantum security and Ethereum’s current infrastructure.\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Poqeth: Efficient, post-quantum signature verification on Ethereum\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Post quantum TXs in The Verge\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n post by JChanceHud on Jan 20, 2025\n\n post by rdubois-crypto on Jan 21, 2025\n\n post by arikg on Jan 22, 2025\n\n post by asanso on Jan 22, 2025\n\n post by mratsim on Jan 28, 2025\n\n post by CPerezz on Jan 28, 2025\n\n post by asanso on Jan 29, 2025\n\n post by asanso on Jan 29, 2025\n\n post by JChanceHud on Jan 30, 2025\n\n Powered by Discourse","tokens":1384,"squid":"ink-research","role":"Deep Scholar","at":1791262088195,"hash":"793366aa0e009b996768ad2232cb3441f8bbfa1c"}
{"url":"https://support.arbitrum.io/hc/en-gb/sections/17825401924379-FAQ","domain":"support.arbitrum.io","title":"FAQ – Arbitrum Foundation","text":"Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n Bridging over a new token\n\n Why do I need ETH to use the Arbitrum network?\n\n You need ETH to power transactions\n\n Why do I have 0 voting power even though I have $ARB?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I add Arbitrum network to my wallet?\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Partnerships with Arbitrum\n\n ARB tokens sent to Arbitrum Foundation\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?","tokens":152,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262091064,"hash":"17aa725ff4d7bfd6b15a361f6ece187532ebd862"}
{"url":"https://ethereum.org/wallets/find-wallet/ambire/","domain":"ethereum.org","title":"Ambire | ⁦ethereum.org⁩","text":"DeveloperFinanceNFTsAmbireBrowserEnglishSwap/bridge fee: 0.5%Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractSmart accountsMultisigSocial recoveryAccount upgradesAdvancedRPC importingToken importingGas fee customizationAmbire info updated on 12/4/2025Similar walletsimTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerTrust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerRabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%","tokens":303,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262103823,"hash":"aeb410f02dec96651cb4697425bd01c4a96b91e9"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/10","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 10 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n asanso\n\n This is Part 2 of a blog series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we introduced the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In this installment, we’ll dive deeper into Falcon, a promising post-quantum signature algorithm, examining its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework.\nFalcon Signature Scheme - Technical Overview\nFalcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) builds upon the lattice-based signature framework of Gentry, Peikert, and Vaikuntanathan (GPV). It applies this framework to NTRU lattices and employs a “fast Fourier sampling” trapdoor sampler. The scheme relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is considered computationally hard to solve in the general case, even with quantum computers, as no efficient solving algorithm is currently known.\nCore Components\nFalcon is based on the hash-and-sign paradigm and is an evolution of the traditional RSA signature scheme. However, instead of relying on number-theoretic problems, it leverages the hardness of lattice-based problems. Falcon’s security is based on the hardness of finding short vectors in NTRU lattices, leveraging Gaussian sampling techniques for generating trapdoor bases with reduced norms. This ensures efficient key generation and signing.\n\nKey Generation:\n\nGiven an NTRU polynomial ring ( \\mathbb{Z}[X] / (X^n + 1))(ℤ[𝑋]/(𝑋𝑛 +1)), a private key consists of two short polynomials ( f, g )(𝑓,𝑔) satisfying the NTRU equation.\nThe public key is derived as ( h = g / f )(ℎ =𝑔/𝑓) in the ring ( \\mathbb{Z}_q[X] / (X^n + 1) )(ℤ𝑞[𝑋]/(𝑋𝑛 +1)).\n\nSigning Process:\n\nA message is hashed into a challenge vector in the lattice domain.\nA short solution is sampled using fast Fourier sampling, ensuring a compact signature size while maintaining security against lattice reduction attacks.\nThe signature consists of the short lattice vector satisfying the challenge.\n\nVerification:\n\nThe verifier checks whether the signature satisfies the public key relation in the lattice ring.\nVerification involves computing norms and ensuring the validity of the lattice basis under modular arithmetic.\n\nFalcon is designed to offer a robust post-quantum signature solution, combining lattice-based cryptography with efficient sampling techniques. While its security benefits are clear, like any cryptographic system, it presents certain trade-offs in terms of complexity and implementation challenges. Now, let’s break down the highlights, potential pitfalls, and some of the more challenging aspects of Falcon.\nThe Good\nAside from the well-known benefits highlighted by NIST, such as Compact Signatures, Fast Operations (efficient key generation and verification via FFT techniques), and Security Proofs (relying on lattice reductions and worst-case hardness assumptions). Falcon also provides Ethereum-specific advantages. Notably, it has a well-defined worst-case running time, making it particularly useful for the Ethereum Virtual Machine (EVM), where predictable performance and execution times are essential for scalability and reliability.\nThe Bad\nFalcon’s reliance on floating-point arithmetic and specialized number-theoretic transforms (NTT/FFT) can lead to implementation complexity and sensitivity to side-channel vulnerabilities during signing. However, this is NOT a significant concern for Ethereum, as signing occurs off-chain, where performance is less critical. The main focus is on optimizing the verification process, which happens on-chain, ensuring efficient and secure execution.\nThe Gnarly\nThere has been ongoing research into efficiently aggregating Falcon signatures, such as the work presented in this paper. Assuming the aggregation will be efficient enough, using Falcon in the consensus layer to replace the BLS signature (instead of the alternative proposal based on Hash-Based Multi-Signatures) would help maintain a more homogeneous stack across the Ethereum network.\nConclusion\nFalcon is a strong candidate for post-quantum cryptography applications, including blockchain systems like Ethereum, where signature size and verification efficiency are critical. In Part 3 of the series, we will begin implementing the hybrid approach introduced in Part 1, initially focusing on Account Abstraction and a Solidity contract for Falcon verification, bridging the gap between post-quantum security and Ethereum’s current infrastructure.\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Poqeth: Efficient, post-quantum signature verification on Ethereum\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Post quantum TXs in The Verge\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n post by JChanceHud on Jan 20, 2025\n\n JChanceHud\n\n Nice writeup, do you have an opinion on Falcon vs Crystals-Dilithium? Crystals is essentially Falcon without gaussian sampling. From an implementation perspective it’s much more simple with slightly larger keys/sigs.\nRe LaBRADOR signature aggregation: just want to mention the verification complexity is linear for these proofs (proof sizes are sublinear though).\n\n post by rdubois-crypto on Jan 21, 2025\n\n rdubois-crypto\n\n Gaussian sampling is the signer problem. The signature verifier implementation of FALCON is easy. In all aspects FALCON verifier is superior: time, bandwidth (3.5), key size. Having the signer handling the complexity is the natural choice. Like we do with ZK, signer has larger capacity than the verifier. https://s.itho.me/ccms_slides/2024/5/23/4414254e-124d-4bbd-8a41-579706b59401.pdf\n\n post by arikg on Jan 22, 2025\n\n arikg\n\n What are your thoughts about the candidates in the “Post-Quantum Cryptography: Additional Digital Signature Schemes”?\nI know that they did not publish results yet, but are you tracking any of the schemes in there as possible alternatives to Falcon?\nDo you see a reasonable chance that one of them gives you better overall tradeoffs and will become a leading alternative candidate?\n\n post by asanso on Jan 22, 2025\n\n asanso\n\n The good thing about using Account Abstraction is that it provides flexibility in the choice of the signature.\nI am, of course, following the ‘Post-Quantum Cryptography: Additional Digital Signature Schemes’ process, and some interesting signatures on my radar are Hawk, SQISign, and MAYO. But well, let’s see.\n\n post by mratsim on Jan 28, 2025\n\n mratsim\n\n Are there been reviews of SQSign suitability? https://sqisign.org/\nKey sizes are really small\n\nNIST round Ⅴ parameters, pubkey: 128 bytes, signatures:335 bytes\n\nI’m quite concerned about primitives in Falcon:\n\nsampling, having a good RNG is already a problem in cryptography, this was the whole reason of RFC6979 - Deterministic ECDSA as many many implementations had RNG/sampling bugs. On the Ethereum side ourselves, we spent a lot of time trying to get cryptographic shuffling right, see p19 and 20 of my 2019 talk\np191920×1080 186 KB\np202000×1125 165 KB\ndouble-precision: the non-determinism makes it very hard to prove in a SNARKS. Furthermore hardware accelerating it, if needed in the future for large aggregation for example, is painful as consumer GPUs issue fp64 instructions at 1/64 the fp32 rate see nvidia doc: CUDA C++ Programming Guide (Legacy) — CUDA C++ Programming Guide\n\n64 FP32 cores for single-precision arithmetic operations in devices of compute capability 8.0 and 128 FP32 cores in devices of compute capability 8.6, 8.7 and 8.9,\n32 FP64 cores for double-precision arithmetic operations in devices of compute capability 8.0 and 2 FP64 cores in devices of compute capability 8.6, 8.7 and 8.9\nCompute capability X.0 are datacenter cards (Tesla) while 8.6, 8.7, 8.9 are consumer GPUs, and consumer GPUs have 128 FP32 cores for 2 FP64 cores.\n\n post by CPerezz on Jan 28, 2025\n\n CPerezz\n\n First of all, this series of 2 posts has been awesome to read. Thanks @asanso\n\nThis is extremely interesting! I did not think about it!\nThe main concern that this article doesn’t account for is that even aggregation is fast, you’re trading off by bandwidth, not just total size of stored data on-chain.\nAggregation would need to be so fast, that even needing to send multiple packets in order to transmit a single signature is worth vs the speed of signing + aggregating.\nAnd I think this is an interesting and important metric to obtain in order to evaluate things like the replacement of Bls sigs.\n\nEven if pairing with Greyhound, this is still a good point. It will still probably require to generate a SNARK that verifies it. But to date, this proof would be even bigger than the signature. At the benefit of a succint verifier. Thus trading off even more bandwidth.\nIt definitely looks like a nice option. But I yet fail to see if ticks all boxes (or the most important ones). I don’t see any doing it BTW. It’s not just this one.\nThis brings me to this point from Mamy:\n\nAnd I agree 100%. Except lattice-based proving systems/PCSs (which are few and not really good atm) any other SNARK/STARK will just not be able to prove this at a reasonable cost.\nAnd this is a major concern. Specially if we plan to reach Snarkification of EL/CL at some point in the future.\n(Although via Acount Abstraction, we could avoid some stuff for sure).\n\nI think the main point here is that we would loose the aggregatability. Which definitely defeats the purpose of minimizing data stored on chain. And which is also the “standard” way for Beacon Chain to work. (This makes me wonder why don’t we try the same for EL with some trick for DA but whatever…)\n\nIf not being ZK-provable isn’t an issue, why don’t we use Isogenies then? Their sigs are tiny and the speed isn’t bad. Specially for the case of Beacon Chain. Where everyone can sign at the same time and aggregate or pass a message when it’s their turn. Do you have any thoughts @asanso ?\n\n post by asanso on Jan 29, 2025\n\n asanso\n\nas you know my area of research is isogeny based cryptography so of course SQISign is something I follow. It’s a bit too early though to judge. The good thing about using Account Abstraction though is the flexibility, so we can always include new solutions.\nAbout the sampling and floating precision is a signer problem that is off chain no ?\n\n post by asanso on Jan 29, 2025\n\n asanso\n\n CPerezz\n\nFirst of all, this series of 2 posts has been awesome to read.\n\nAppreciate your feedback !\n\nThe main concern that this article doesn’t account for is that even aggregation is fast, you’re trading off by bandwidth, not just total size of stored data on-chain.\n\nAs specified in Part 1 of the post here we are tacking the execution part of Ethereum. The aggregation part is a “consensus problem” and there we have the Beam Chain project. True I mentioned aggregation in the gnarly part of this post (that’s why gnarly :)).\n\nIf not being ZK-provable isn’t an issue, why don’t we use Isogenies then?\n\nas mentioned above is too early to think about using SQiSign or PRISM (https://eprint.iacr.org/2025/135.pdf) for now .\n\n post by JChanceHud on Jan 30, 2025\n\n JChanceHud\n\nWe have to stop comparing PQ schemes to elliptic curve ones. IMO ECC is a detour in history, its properties are incredibly good because it’s not quantum secure. Isogenies are good but don’t get close to dlog based ecdsa/bls/groth16.\nI imagine the PQ paradigm will be multiple schemes that are good at different things. Instead of having a single scheme that is great in all dimensions we’ll need more schemes to build things and more engineering effort/complexity.\nI just don’t buy linear proving and constant communication+verification complexity. It’s simply too good. Happy to be proven wrong though.\n\n Powered by Discourse","tokens":3020,"squid":"ink-research","role":"Deep Scholar","at":1791262109128,"hash":"bc3e01dab25c4687816dc62a12eb0b78259534f7"}
{"url":"https://ethereum.org/wallets/find-wallet/imtoken/","domain":"ethereum.org","title":"imToken | ⁦ethereum.org⁩","text":"DeveloperFinanceNFTsimTokenMobileEnglish, Chinese, Chinese (Taiwan), Russian, German, Japanese, Korean, French, Spanish, VietnameseSwap fee: 0.3% (0.04% stablecoins, lower on L2s)Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportStakingLayer 2SwapsHardware wallet supportENS supportSecurityOpen sourcePersonal ownershipPrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationimToken info updated on 8/31/2024Similar walletsOneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerAmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%FrameDeveloperFinanceNFTsDesktop · BrowserEnglish","tokens":313,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262114149,"hash":"709d436041c33da26089734c52221499c427e785"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/7","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 7 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n asanso\n\n This is Part 2 of a blog series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we introduced the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In this installment, we’ll dive deeper into Falcon, a promising post-quantum signature algorithm, examining its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework.\nFalcon Signature Scheme - Technical Overview\nFalcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) builds upon the lattice-based signature framework of Gentry, Peikert, and Vaikuntanathan (GPV). It applies this framework to NTRU lattices and employs a “fast Fourier sampling” trapdoor sampler. The scheme relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is considered computationally hard to solve in the general case, even with quantum computers, as no efficient solving algorithm is currently known.\nCore Components\nFalcon is based on the hash-and-sign paradigm and is an evolution of the traditional RSA signature scheme. However, instead of relying on number-theoretic problems, it leverages the hardness of lattice-based problems. Falcon’s security is based on the hardness of finding short vectors in NTRU lattices, leveraging Gaussian sampling techniques for generating trapdoor bases with reduced norms. This ensures efficient key generation and signing.\n\nKey Generation:\n\nGiven an NTRU polynomial ring ( \\mathbb{Z}[X] / (X^n + 1))(ℤ[𝑋]/(𝑋𝑛 +1)), a private key consists of two short polynomials ( f, g )(𝑓,𝑔) satisfying the NTRU equation.\nThe public key is derived as ( h = g / f )(ℎ =𝑔/𝑓) in the ring ( \\mathbb{Z}_q[X] / (X^n + 1) )(ℤ𝑞[𝑋]/(𝑋𝑛 +1)).\n\nSigning Process:\n\nA message is hashed into a challenge vector in the lattice domain.\nA short solution is sampled using fast Fourier sampling, ensuring a compact signature size while maintaining security against lattice reduction attacks.\nThe signature consists of the short lattice vector satisfying the challenge.\n\nVerification:\n\nThe verifier checks whether the signature satisfies the public key relation in the lattice ring.\nVerification involves computing norms and ensuring the validity of the lattice basis under modular arithmetic.\n\nFalcon is designed to offer a robust post-quantum signature solution, combining lattice-based cryptography with efficient sampling techniques. While its security benefits are clear, like any cryptographic system, it presents certain trade-offs in terms of complexity and implementation challenges. Now, let’s break down the highlights, potential pitfalls, and some of the more challenging aspects of Falcon.\nThe Good\nAside from the well-known benefits highlighted by NIST, such as Compact Signatures, Fast Operations (efficient key generation and verification via FFT techniques), and Security Proofs (relying on lattice reductions and worst-case hardness assumptions). Falcon also provides Ethereum-specific advantages. Notably, it has a well-defined worst-case running time, making it particularly useful for the Ethereum Virtual Machine (EVM), where predictable performance and execution times are essential for scalability and reliability.\nThe Bad\nFalcon’s reliance on floating-point arithmetic and specialized number-theoretic transforms (NTT/FFT) can lead to implementation complexity and sensitivity to side-channel vulnerabilities during signing. However, this is NOT a significant concern for Ethereum, as signing occurs off-chain, where performance is less critical. The main focus is on optimizing the verification process, which happens on-chain, ensuring efficient and secure execution.\nThe Gnarly\nThere has been ongoing research into efficiently aggregating Falcon signatures, such as the work presented in this paper. Assuming the aggregation will be efficient enough, using Falcon in the consensus layer to replace the BLS signature (instead of the alternative proposal based on Hash-Based Multi-Signatures) would help maintain a more homogeneous stack across the Ethereum network.\nConclusion\nFalcon is a strong candidate for post-quantum cryptography applications, including blockchain systems like Ethereum, where signature size and verification efficiency are critical. In Part 3 of the series, we will begin implementing the hybrid approach introduced in Part 1, initially focusing on Account Abstraction and a Solidity contract for Falcon verification, bridging the gap between post-quantum security and Ethereum’s current infrastructure.\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Poqeth: Efficient, post-quantum signature verification on Ethereum\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Post quantum TXs in The Verge\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n post by JChanceHud on Jan 20, 2025\n\n JChanceHud\n\n Nice writeup, do you have an opinion on Falcon vs Crystals-Dilithium? Crystals is essentially Falcon without gaussian sampling. From an implementation perspective it’s much more simple with slightly larger keys/sigs.\nRe LaBRADOR signature aggregation: just want to mention the verification complexity is linear for these proofs (proof sizes are sublinear though).\n\n post by rdubois-crypto on Jan 21, 2025\n\n rdubois-crypto\n\n Gaussian sampling is the signer problem. The signature verifier implementation of FALCON is easy. In all aspects FALCON verifier is superior: time, bandwidth (3.5), key size. Having the signer handling the complexity is the natural choice. Like we do with ZK, signer has larger capacity than the verifier. https://s.itho.me/ccms_slides/2024/5/23/4414254e-124d-4bbd-8a41-579706b59401.pdf\n\n post by arikg on Jan 22, 2025\n\n arikg\n\n What are your thoughts about the candidates in the “Post-Quantum Cryptography: Additional Digital Signature Schemes”?\nI know that they did not publish results yet, but are you tracking any of the schemes in there as possible alternatives to Falcon?\nDo you see a reasonable chance that one of them gives you better overall tradeoffs and will become a leading alternative candidate?\n\n post by asanso on Jan 22, 2025\n\n asanso\n\n The good thing about using Account Abstraction is that it provides flexibility in the choice of the signature.\nI am, of course, following the ‘Post-Quantum Cryptography: Additional Digital Signature Schemes’ process, and some interesting signatures on my radar are Hawk, SQISign, and MAYO. But well, let’s see.\n\n post by mratsim on Jan 28, 2025\n\n mratsim\n\n Are there been reviews of SQSign suitability? https://sqisign.org/\nKey sizes are really small\n\nNIST round Ⅴ parameters, pubkey: 128 bytes, signatures:335 bytes\n\nI’m quite concerned about primitives in Falcon:\n\nsampling, having a good RNG is already a problem in cryptography, this was the whole reason of RFC6979 - Deterministic ECDSA as many many implementations had RNG/sampling bugs. On the Ethereum side ourselves, we spent a lot of time trying to get cryptographic shuffling right, see p19 and 20 of my 2019 talk\np191920×1080 186 KB\np202000×1125 165 KB\ndouble-precision: the non-determinism makes it very hard to prove in a SNARKS. Furthermore hardware accelerating it, if needed in the future for large aggregation for example, is painful as consumer GPUs issue fp64 instructions at 1/64 the fp32 rate see nvidia doc: CUDA C++ Programming Guide (Legacy) — CUDA C++ Programming Guide\n\n64 FP32 cores for single-precision arithmetic operations in devices of compute capability 8.0 and 128 FP32 cores in devices of compute capability 8.6, 8.7 and 8.9,\n32 FP64 cores for double-precision arithmetic operations in devices of compute capability 8.0 and 2 FP64 cores in devices of compute capability 8.6, 8.7 and 8.9\nCompute capability X.0 are datacenter cards (Tesla) while 8.6, 8.7, 8.9 are consumer GPUs, and consumer GPUs have 128 FP32 cores for 2 FP64 cores.\n\n post by CPerezz on Jan 28, 2025\n\n CPerezz\n\n First of all, this series of 2 posts has been awesome to read. Thanks @asanso\n\nThis is extremely interesting! I did not think about it!\nThe main concern that this article doesn’t account for is that even aggregation is fast, you’re trading off by bandwidth, not just total size of stored data on-chain.\nAggregation would need to be so fast, that even needing to send multiple packets in order to transmit a single signature is worth vs the speed of signing + aggregating.\nAnd I think this is an interesting and important metric to obtain in order to evaluate things like the replacement of Bls sigs.\n\nEven if pairing with Greyhound, this is still a good point. It will still probably require to generate a SNARK that verifies it. But to date, this proof would be even bigger than the signature. At the benefit of a succint verifier. Thus trading off even more bandwidth.\nIt definitely looks like a nice option. But I yet fail to see if ticks all boxes (or the most important ones). I don’t see any doing it BTW. It’s not just this one.\nThis brings me to this point from Mamy:\n\nAnd I agree 100%. Except lattice-based proving systems/PCSs (which are few and not really good atm) any other SNARK/STARK will just not be able to prove this at a reasonable cost.\nAnd this is a major concern. Specially if we plan to reach Snarkification of EL/CL at some point in the future.\n(Although via Acount Abstraction, we could avoid some stuff for sure).\n\nI think the main point here is that we would loose the aggregatability. Which definitely defeats the purpose of minimizing data stored on chain. And which is also the “standard” way for Beacon Chain to work. (This makes me wonder why don’t we try the same for EL with some trick for DA but whatever…)\n\nIf not being ZK-provable isn’t an issue, why don’t we use Isogenies then? Their sigs are tiny and the speed isn’t bad. Specially for the case of Beacon Chain. Where everyone can sign at the same time and aggregate or pass a message when it’s their turn. Do you have any thoughts @asanso ?\n\n post by asanso on Jan 29, 2025\n\n asanso\n\nas you know my area of research is isogeny based cryptography so of course SQISign is something I follow. It’s a bit too early though to judge. The good thing about using Account Abstraction though is the flexibility, so we can always include new solutions.\nAbout the sampling and floating precision is a signer problem that is off chain no ?\n\n post by asanso on Jan 29, 2025\n\n asanso\n\n CPerezz\n\nFirst of all, this series of 2 posts has been awesome to read.\n\nAppreciate your feedback !\n\nThe main concern that this article doesn’t account for is that even aggregation is fast, you’re trading off by bandwidth, not just total size of stored data on-chain.\n\nAs specified in Part 1 of the post here we are tacking the execution part of Ethereum. The aggregation part is a “consensus problem” and there we have the Beam Chain project. True I mentioned aggregation in the gnarly part of this post (that’s why gnarly :)).\n\nIf not being ZK-provable isn’t an issue, why don’t we use Isogenies then?\n\nas mentioned above is too early to think about using SQiSign or PRISM (https://eprint.iacr.org/2025/135.pdf) for now .\n\n post by JChanceHud on Jan 30, 2025\n\n JChanceHud\n\nWe have to stop comparing PQ schemes to elliptic curve ones. IMO ECC is a detour in history, its properties are incredibly good because it’s not quantum secure. Isogenies are good but don’t get close to dlog based ecdsa/bls/groth16.\nI imagine the PQ paradigm will be multiple schemes that are good at different things. Instead of having a single scheme that is great in all dimensions we’ll need more schemes to build things and more engineering effort/complexity.\nI just don’t buy linear proving and constant communication+verification complexity. It’s simply too good. Happy to be proven wrong though.\n\n Powered by Discourse","tokens":3019,"squid":"ink-research","role":"Deep Scholar","at":1791262119604,"hash":"8c5b99f3659d1c077ec948c1bcd121c3dd25df6e"}
{"url":"https://forum.openzeppelin.com/t/how-to-put-the-price-0-0000001-10-6-uint256-does-not-accept-0-1/36240/7","domain":"forum.openzeppelin.com","title":"How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1 - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n May 2023\n\n 7 / 7\n\n May 2023\n\n May 2023\n\n post by 213101 on May 15, 2023\n\n post by barakman on May 15, 2023\n\n post by 213101 on May 16, 2023\n\n post by barakman on May 16, 2023\n\n barakman\n\n Dude, I was trying to explain to you, using pure mathematical notation (i.e., not solidity code), that 0.0000001 times 10^18 is not equal to 0.001, but rather, to 10^11, which is of course an integer value, representable by a uint256.\nIn short, what you need to do, is to pass something like BigNumber.from(\"100000000000\").\nOr perhaps BigNumber.from(10).pow(11), or even BigNumber.from(\"10e11\").\nIt really depends on what BigNumber implementation you're using.\nBut following your original question, as well as your response to my answer, I believe that you might wanna study some basic programming concepts before jumping to smart contracts.\n\n post by 213101 on May 16, 2023\n\n 213101\n\n I just need to put one correct value.\nhere is my contract.\n\nupdateTokenRate (0x3115329e)\n\n post by barakman on May 16, 2023\n\n barakman\n\n Like I said, the value of 0.0000001*10^18 is 10 to the power of 11 (i.e., \"one followed by 11 zeros\").\n\n post by 213101 on May 16, 2023\n\n 213101\n\n sorry. I made a mistake. I need 0.0000001*10^6 = 0.1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale set rate for 9 decimal\n\n Support\n\n crowdsale\n\n 2\n\n 628\n\n Apr 2021\n\n Error: invalid BigNumber string\n\n Contracts\n\n 1\n\n 1.3k\n\n Oct 2021\n\n Going insane over Token pricing\n\n Support\n\n erc20\n\n 2\n\n 598\n\n Jun 2021\n\n Setting up my crowdsale rate\n\n Smart Contracts\n\n crowdsale\n\n 1\n\n 951\n\n May 2022\n\n Invalid BigNumber value for string\n\n Smart Contracts\n\n erc721,solidity\n\n 1\n\n 226\n\n Jun 2024","tokens":451,"squid":"ink-security_audits","role":"Sentinel","at":1791262121462,"hash":"7ab5d9b3c1015fe32ac8d083c136fa0e28164b26"}
{"url":"https://ethereum.org/wallets/find-wallet/personas/developer/","domain":"ethereum.org","title":"Wallets for developers | ⁦ethereum.org⁩","text":"Wallets for developersWallets built for building. Connect to dapps and test networks, import custom RPCs and tokens, and get the tooling you need to develop and test on Ethereum.Browse wallets by user typeNew to crypto 2 availableFirst time user looking for beginner wallet.Developer 13 availableWallets that help develop and test dapps.Finance 10 availableWallets focusing on frequent usage of DeFi apps.Hardware 2 availablePassive token holding with hardware wallets.NFTs 10 availableWallets with focus on NFT support.Browse all walletsWallets found: 13 / 48AmbireDeveloperFinanceNFTsBrowserEnglish Swap/bridge fee: 0.5%Trust WalletDeveloperFinanceNFTsMobile · BrowserEnglish · Arabic Buy fee: set by the providerGem WalletDeveloperNFTsDesktop · MobileEnglish · Spanish Swap fee: 0%, Buy fee: set by the providerimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%Rabby WalletDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · German Swap fee: 0.25%Zerion WalletNew to cryptoDeveloperFinanceNFTsDesktop · Mobile · BrowserEnglish · Russian Swap/bridge fee: 0.67% (lower with Premium), Buy fee: set by the providerUnstoppable walletDeveloperNFTsMobileEnglish · French Swap fee: 0%imTokenDeveloperFinanceNFTsMobileEnglish · Chinese Swap fee: 0.3% (0.04% stablecoins, lower on L2s)FrameDeveloperFinanceNFTsDesktop · BrowserEnglish Clear WalletDeveloperBrowserEnglish BlockWalletDeveloperFinanceBrowserEnglish Swap/bridge fee: 0.5%Cake WalletDeveloperFinanceDesktop · MobileEnglish · Spanish Swap fee: variableOneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%How we evaluate walletsEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.Read the full listing criteria and removal policyCurated by the ethereum.org editorial team.Most recent listing update: July 8, 2026To be listed, a wallet must meet the following requirements:Security-tested through audit, an internal security team, or open-source code review.Been live for at least six months, or built by a team with an established track record.Actively maintained, with support available for users.Provides honest, accurate listing information. Products that falsify details are removed.Has a named point of contact so we can verify information when it changes.Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.Listings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.Filter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.Wallets listed on this page are not official endorsements, and are provided for informational purposes only.Their descriptions have been provided by the wallet projects themselves.","tokens":852,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262124299,"hash":"220776c5c6506121892be0f983576b8b7d493594"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/6","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 6 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n asanso\n\n This is Part 2 of a blog series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we introduced the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In this installment, we’ll dive deeper into Falcon, a promising post-quantum signature algorithm, examining its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework.\nFalcon Signature Scheme - Technical Overview\nFalcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) builds upon the lattice-based signature framework of Gentry, Peikert, and Vaikuntanathan (GPV). It applies this framework to NTRU lattices and employs a “fast Fourier sampling” trapdoor sampler. The scheme relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is considered computationally hard to solve in the general case, even with quantum computers, as no efficient solving algorithm is currently known.\nCore Components\nFalcon is based on the hash-and-sign paradigm and is an evolution of the traditional RSA signature scheme. However, instead of relying on number-theoretic problems, it leverages the hardness of lattice-based problems. Falcon’s security is based on the hardness of finding short vectors in NTRU lattices, leveraging Gaussian sampling techniques for generating trapdoor bases with reduced norms. This ensures efficient key generation and signing.\n\nKey Generation:\n\nGiven an NTRU polynomial ring ( \\mathbb{Z}[X] / (X^n + 1))(ℤ[𝑋]/(𝑋𝑛 +1)), a private key consists of two short polynomials ( f, g )(𝑓,𝑔) satisfying the NTRU equation.\nThe public key is derived as ( h = g / f )(ℎ =𝑔/𝑓) in the ring ( \\mathbb{Z}_q[X] / (X^n + 1) )(ℤ𝑞[𝑋]/(𝑋𝑛 +1)).\n\nSigning Process:\n\nA message is hashed into a challenge vector in the lattice domain.\nA short solution is sampled using fast Fourier sampling, ensuring a compact signature size while maintaining security against lattice reduction attacks.\nThe signature consists of the short lattice vector satisfying the challenge.\n\nVerification:\n\nThe verifier checks whether the signature satisfies the public key relation in the lattice ring.\nVerification involves computing norms and ensuring the validity of the lattice basis under modular arithmetic.\n\nFalcon is designed to offer a robust post-quantum signature solution, combining lattice-based cryptography with efficient sampling techniques. While its security benefits are clear, like any cryptographic system, it presents certain trade-offs in terms of complexity and implementation challenges. Now, let’s break down the highlights, potential pitfalls, and some of the more challenging aspects of Falcon.\nThe Good\nAside from the well-known benefits highlighted by NIST, such as Compact Signatures, Fast Operations (efficient key generation and verification via FFT techniques), and Security Proofs (relying on lattice reductions and worst-case hardness assumptions). Falcon also provides Ethereum-specific advantages. Notably, it has a well-defined worst-case running time, making it particularly useful for the Ethereum Virtual Machine (EVM), where predictable performance and execution times are essential for scalability and reliability.\nThe Bad\nFalcon’s reliance on floating-point arithmetic and specialized number-theoretic transforms (NTT/FFT) can lead to implementation complexity and sensitivity to side-channel vulnerabilities during signing. However, this is NOT a significant concern for Ethereum, as signing occurs off-chain, where performance is less critical. The main focus is on optimizing the verification process, which happens on-chain, ensuring efficient and secure execution.\nThe Gnarly\nThere has been ongoing research into efficiently aggregating Falcon signatures, such as the work presented in this paper. Assuming the aggregation will be efficient enough, using Falcon in the consensus layer to replace the BLS signature (instead of the alternative proposal based on Hash-Based Multi-Signatures) would help maintain a more homogeneous stack across the Ethereum network.\nConclusion\nFalcon is a strong candidate for post-quantum cryptography applications, including blockchain systems like Ethereum, where signature size and verification efficiency are critical. In Part 3 of the series, we will begin implementing the hybrid approach introduced in Part 1, initially focusing on Account Abstraction and a Solidity contract for Falcon verification, bridging the gap between post-quantum security and Ethereum’s current infrastructure.\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Poqeth: Efficient, post-quantum signature verification on Ethereum\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Post quantum TXs in The Verge\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n post by JChanceHud on Jan 20, 2025\n\n JChanceHud\n\n Nice writeup, do you have an opinion on Falcon vs Crystals-Dilithium? Crystals is essentially Falcon without gaussian sampling. From an implementation perspective it’s much more simple with slightly larger keys/sigs.\nRe LaBRADOR signature aggregation: just want to mention the verification complexity is linear for these proofs (proof sizes are sublinear though).\n\n post by rdubois-crypto on Jan 21, 2025\n\n rdubois-crypto\n\n Gaussian sampling is the signer problem. The signature verifier implementation of FALCON is easy. In all aspects FALCON verifier is superior: time, bandwidth (3.5), key size. Having the signer handling the complexity is the natural choice. Like we do with ZK, signer has larger capacity than the verifier. https://s.itho.me/ccms_slides/2024/5/23/4414254e-124d-4bbd-8a41-579706b59401.pdf\n\n post by arikg on Jan 22, 2025\n\n arikg\n\n What are your thoughts about the candidates in the “Post-Quantum Cryptography: Additional Digital Signature Schemes”?\nI know that they did not publish results yet, but are you tracking any of the schemes in there as possible alternatives to Falcon?\nDo you see a reasonable chance that one of them gives you better overall tradeoffs and will become a leading alternative candidate?\n\n post by asanso on Jan 22, 2025\n\n asanso\n\n The good thing about using Account Abstraction is that it provides flexibility in the choice of the signature.\nI am, of course, following the ‘Post-Quantum Cryptography: Additional Digital Signature Schemes’ process, and some interesting signatures on my radar are Hawk, SQISign, and MAYO. But well, let’s see.\n\n post by mratsim on Jan 28, 2025\n\n mratsim\n\n Are there been reviews of SQSign suitability? https://sqisign.org/\nKey sizes are really small\n\nNIST round Ⅴ parameters, pubkey: 128 bytes, signatures:335 bytes\n\nI’m quite concerned about primitives in Falcon:\n\nsampling, having a good RNG is already a problem in cryptography, this was the whole reason of RFC6979 - Deterministic ECDSA as many many implementations had RNG/sampling bugs. On the Ethereum side ourselves, we spent a lot of time trying to get cryptographic shuffling right, see p19 and 20 of my 2019 talk\np191920×1080 186 KB\np202000×1125 165 KB\ndouble-precision: the non-determinism makes it very hard to prove in a SNARKS. Furthermore hardware accelerating it, if needed in the future for large aggregation for example, is painful as consumer GPUs issue fp64 instructions at 1/64 the fp32 rate see nvidia doc: CUDA C++ Programming Guide (Legacy) — CUDA C++ Programming Guide\n\n64 FP32 cores for single-precision arithmetic operations in devices of compute capability 8.0 and 128 FP32 cores in devices of compute capability 8.6, 8.7 and 8.9,\n32 FP64 cores for double-precision arithmetic operations in devices of compute capability 8.0 and 2 FP64 cores in devices of compute capability 8.6, 8.7 and 8.9\nCompute capability X.0 are datacenter cards (Tesla) while 8.6, 8.7, 8.9 are consumer GPUs, and consumer GPUs have 128 FP32 cores for 2 FP64 cores.\n\n post by CPerezz on Jan 28, 2025\n\n CPerezz\n\n First of all, this series of 2 posts has been awesome to read. Thanks @asanso\n\nThis is extremely interesting! I did not think about it!\nThe main concern that this article doesn’t account for is that even aggregation is fast, you’re trading off by bandwidth, not just total size of stored data on-chain.\nAggregation would need to be so fast, that even needing to send multiple packets in order to transmit a single signature is worth vs the speed of signing + aggregating.\nAnd I think this is an interesting and important metric to obtain in order to evaluate things like the replacement of Bls sigs.\n\nEven if pairing with Greyhound, this is still a good point. It will still probably require to generate a SNARK that verifies it. But to date, this proof would be even bigger than the signature. At the benefit of a succint verifier. Thus trading off even more bandwidth.\nIt definitely looks like a nice option. But I yet fail to see if ticks all boxes (or the most important ones). I don’t see any doing it BTW. It’s not just this one.\nThis brings me to this point from Mamy:\n\nAnd I agree 100%. Except lattice-based proving systems/PCSs (which are few and not really good atm) any other SNARK/STARK will just not be able to prove this at a reasonable cost.\nAnd this is a major concern. Specially if we plan to reach Snarkification of EL/CL at some point in the future.\n(Although via Acount Abstraction, we could avoid some stuff for sure).\n\nI think the main point here is that we would loose the aggregatability. Which definitely defeats the purpose of minimizing data stored on chain. And which is also the “standard” way for Beacon Chain to work. (This makes me wonder why don’t we try the same for EL with some trick for DA but whatever…)\n\nIf not being ZK-provable isn’t an issue, why don’t we use Isogenies then? Their sigs are tiny and the speed isn’t bad. Specially for the case of Beacon Chain. Where everyone can sign at the same time and aggregate or pass a message when it’s their turn. Do you have any thoughts @asanso ?\n\n post by asanso on Jan 29, 2025\n\n asanso\n\nas you know my area of research is isogeny based cryptography so of course SQISign is something I follow. It’s a bit too early though to judge. The good thing about using Account Abstraction though is the flexibility, so we can always include new solutions.\nAbout the sampling and floating precision is a signer problem that is off chain no ?\n\n post by asanso on Jan 29, 2025\n\n asanso\n\n CPerezz\n\nFirst of all, this series of 2 posts has been awesome to read.\n\nAppreciate your feedback !\n\nThe main concern that this article doesn’t account for is that even aggregation is fast, you’re trading off by bandwidth, not just total size of stored data on-chain.\n\nAs specified in Part 1 of the post here we are tacking the execution part of Ethereum. The aggregation part is a “consensus problem” and there we have the Beam Chain project. True I mentioned aggregation in the gnarly part of this post (that’s why gnarly :)).\n\nIf not being ZK-provable isn’t an issue, why don’t we use Isogenies then?\n\nas mentioned above is too early to think about using SQiSign or PRISM (https://eprint.iacr.org/2025/135.pdf) for now .\n\n post by JChanceHud on Jan 30, 2025\n\n JChanceHud\n\nWe have to stop comparing PQ schemes to elliptic curve ones. IMO ECC is a detour in history, its properties are incredibly good because it’s not quantum secure. Isogenies are good but don’t get close to dlog based ecdsa/bls/groth16.\nI imagine the PQ paradigm will be multiple schemes that are good at different things. Instead of having a single scheme that is great in all dimensions we’ll need more schemes to build things and more engineering effort/complexity.\nI just don’t buy linear proving and constant communication+verification complexity. It’s simply too good. Happy to be proven wrong though.\n\n Powered by Discourse","tokens":3019,"squid":"ink-research","role":"Deep Scholar","at":1791262130098,"hash":"446c0d56f85f016d10fdecf6abd0654e7dbd8917"}
{"url":"https://forum.openzeppelin.com/t/error-invalid-bignumber-string/16434/2","domain":"forum.openzeppelin.com","title":"Error: invalid BigNumber string - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2021\n\n 2 / 2\n\n Oct 2021\n\n Oct 2021\n\n post by Maham_Zaidi on Oct 2, 2021\n\n Maham_Zaidi\n\n I want to input the following values to this function\nfunction rebase(uint256 epoch, int256 supplyDelta)\n\nepoch (5 minutes later)\nsupplyDelta -0.000000000000001\n\nI tried doing so in remix but got an error. How to resolve this issue?\n\nerrored: Error encoding arguments: Error: invalid BigNumber string (argument=\"value\", value=\"-0.000000000000001\", code=INVALID_ARGUMENT, version=bignumber/5.4.1)\n\n post by Amxx on Oct 4, 2021\n\n Amxx\n\n OpenZeppelin Team\n\n Hello @Maham_Zaidi\n\nThis is not a valid integer. It looks like you are trying to pass a floating number. Floating number do not (natively) exist in solidity / on the evm.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Invalid BigNumber value for string\n\n Smart Contracts\n\n erc721,solidity\n\n 1\n\n 226\n\n Jun 2024\n\n How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1\n\n Smart Contracts\n\n 6\n\n 718\n\n May 2023\n\n BigNumber error\n\n Smart Contracts\n\n etherscan-verify\n\n 0\n\n 373\n\n Mar 2024\n\n Help please with: invalid number value (arg=“amount”, coderType=“uint256”\n\n Contracts\n\n erc20\n\n 3\n\n 8.6k\n\n Sep 2021\n\n Value undefined only in AutoTask\n\n Defender\n\n 11\n\n 1.1k\n\n May 2024","tokens":344,"squid":"ink-security_audits","role":"Sentinel","at":1791262131738,"hash":"019ed738077273397448edd698bc5b11316d3334"}
{"url":"https://ethereum.org/wallets/find-wallet/personas/hardware/","domain":"ethereum.org","title":"Wallets for long-term storage | ⁦ethereum.org⁩","text":"Wallets for long-term storageHolding for the long run? These wallets pair with hardware devices to keep your keys offline and your assets secure while you hold.Browse wallets by user typeNew to crypto 1 availableFirst time user looking for beginner wallet.Developer 2 availableWallets that help develop and test dapps.Finance 5 availableWallets focusing on frequent usage of DeFi apps.Hardware 9 availablePassive token holding with hardware wallets.NFTs 7 availableWallets with focus on NFT support.Browse all walletsWallets found: 9 / 48TrezorFinanceHardwareDesktop · Mobile · HardwareEnglish · Spanish Device: $59 – $129, Swap fee: variableimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%TokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%GridPlus Lattice1HardwareNFTsDesktop · Browser · HardwareEnglish Device: $397KeystoneHardwareHardwareEnglish · Chinese Device: $149BurnerHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish Device: $19/card, Swap fee: not disclosedLedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableCypherock X1HardwareNFTsDesktop · HardwareEnglish · German Device: $99 – $179How we evaluate walletsEvery wallet on this page is reviewed by the ethereum.org team before being listed. We apply a published set of criteria focused on security, self-custody, and Ethereum-native support so users can navigate the ecosystem with greater confidence.Read the full listing criteria and removal policyCurated by the ethereum.org editorial team.Most recent listing update: June 16, 2026To be listed, a wallet must meet the following requirements:Security-tested through audit, an internal security team, or open-source code review.Been live for at least six months, or built by a team with an established track record.Actively maintained, with support available for users.Provides honest, accurate listing information. Products that falsify details are removed.Has a named point of contact so we can verify information when it changes.Supports EIP-1559 (type 2) transactions on Ethereum Mainnet.Offers a reviewable user experience. If our team finds a product difficult to use, we may request improvements before listing it.Is Ethereum-focused, with Ethereum or a Layer 2 set as the default network.Listings are not static. Wallet providers are required to resubmit information every six months. If a team does not respond, we remove the wallet. This keeps the directory accurate as products evolve.Filter toggles on this page (open source, self-custody, hardware wallet support, and others) reflect attributes tracked per wallet. Each listing also shows the date its information was last verified.Wallets listed on this page are not official endorsements, and are provided for informational purposes only.Their descriptions have been provided by the wallet projects themselves.","tokens":783,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262146287,"hash":"67ae50f8f34a6916d42ab8e05ac8059fb3851f96"}
{"url":"https://ethereum.org/wallets/find-wallet/burner/","domain":"ethereum.org","title":"Burner | ⁦ethereum.org⁩","text":"HardwareNFTsBurnerDesktop · Mobile · Browser · HardwareEnglishDevice: $19/card, Swap fee: not disclosedVisit website (opens in a new tab)Twitter (opens in a new tab)FeaturesConnect to dappsNFT supportLayer 2SwapsHardware wallet supportENS supportStakingSecurityPersonal ownershipOpen sourcePrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationBurner info updated on 5/19/2025Similar walletsGridPlus Lattice1HardwareNFTsDesktop · Browser · HardwareEnglish Device: $397Cypherock X1HardwareNFTsDesktop · HardwareEnglish · German Device: $99 – $179TokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%LedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableimKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%","tokens":290,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262156757,"hash":"0d8fc72d60c3c4833b9467ac99af8772f28080c7"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/12","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 12 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 115\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1416,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262157256,"hash":"5e33d3416e7d80384480f26adc014ed211fccfc7"}
{"url":"https://forum.openzeppelin.com/t/invalid-bignumber-value-for-string/40695/1","domain":"forum.openzeppelin.com","title":"Invalid BigNumber value for string - Smart Contracts - OpenZeppelin Forum","text":"Invalid BigNumber value for string \n\n Smart Contracts\n\n erc721,solidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 1 / 2\n\n May 2024\n\n Jun 2024\n\n post by Jalapina on May 30, 2024\n\n Jalapina\n\n When I try to run the pin function that takes an integer, i keep getting this error\n\ninvalid BigNumber value (argument=\"value\", value=undefined, code=INVALID_ARGUMENT, version=bignumber/5.7.0)\n\nfrontend code:\n const abi = [\n \"function pinGem(uint256 tokenId, string memory latitude, string memory longitude) public\"\n ];\n const contract = new ethers.Contract(contractAddress, abi, signer);\n\n try {\n const latitude = pinnedPosition.lat.toString();\n const longitude = pinnedPosition.lng.toString();\n\n const tx = await contract.pinGem(nft.tokenId, latitude, longitude);\n\ncontract:\ni tried using uint256, but kept getting the same error then switched to strings and still got the same error.\n// Compatible with OpenZeppelin Contracts ^5.0.0\npragma solidity ^0.8.20;\n\n struct Gem {\n uint256 id;\n string latitude;\n string longitude;\n }\n\n function pin(uint256 tokenId, string memory latitude, string memory longitude) public {\n require(ownerOf(tokenId) != address(0), \"Token ID does not exist\");\n pins[tokenId] = Pin(tokenId, latitude, longitude);\n }\n\n post by Jalapina on Jun 1, 2024\n\n Jalapina\n\n i was passing then ID oops\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error: invalid BigNumber string\n\n Contracts\n\n 1\n\n 1.3k\n\n Oct 2021\n\n BigNumber error\n\n Smart Contracts\n\n etherscan-verify\n\n 0\n\n 374\n\n Mar 2024\n\n How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1\n\n Smart Contracts\n\n 6\n\n 718\n\n May 2023\n\n Help please with: invalid number value (arg=“amount”, coderType=“uint256”\n\n Contracts\n\n erc20\n\n 3\n\n 8.6k\n\n Sep 2021\n\n Urgent question - 100e18 token transfer works but 1,000e18 doesn’t\n\n Smart Contracts\n\n erc721\n\n 1\n\n 807\n\n May 2022","tokens":485,"squid":"ink-security_audits","role":"Sentinel","at":1791262164438,"hash":"681cb43d3a743b679991b206efeb3a59069d773b"}
{"url":"https://ethereum.org/wallets/find-wallet/gridplus-lattice1/","domain":"ethereum.org","title":"GridPlus Lattice1 | ⁦ethereum.org⁩","text":"HardwareNFTsGridPlus Lattice1Desktop · Browser · HardwareEnglishDevice: $397Visit website (opens in a new tab)Twitter (opens in a new tab)Discord (opens in a new tab)FeaturesConnect to dappsNFT supportLayer 2Hardware wallet supportStakingSwapsENS supportSecurityPersonal ownershipOpen sourcePrivate transactionsBuy / sell cryptoBuy cryptoSell for cashSmart contractMultisigSocial recoverySmart accountsAccount upgradesAdvancedRPC importingToken importingGas fee customizationGridPlus Lattice1 info updated on 10/31/2022Similar walletsLedgerFinanceHardwareNFTsDesktop · Mobile · HardwareEnglish · Arabic Device: $79 – $399, Swap fee: variableTokenPocketFinanceHardwareNFTsMobile · Browser · HardwareEnglish · Arabic Swap fee: not disclosed (TPT-holder discounts)imKey Pro Hardware WalletDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Device: $110, Swap fee: 0%OneKeyNew to cryptoDeveloperFinanceHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish · Chinese Swap/bridge fee: 0.85%BurnerHardwareNFTsDesktop · Mobile · Browser · HardwareEnglish Device: $19/card, Swap fee: not disclosedCypherock X1HardwareNFTsDesktop · HardwareEnglish · German Device: $99 – $179","tokens":300,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262167154,"hash":"43aecee01f54b283985c3e881968745cebc13e95"}
{"url":"https://dev-forum.pyth.network/t/about-the-benchmarks-historic-prices-category/16","domain":"dev-forum.pyth.network","title":"About the Benchmarks(Historic Prices) category - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n About the Benchmarks(Historic Prices) category \n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 1 / 3\n\n Mar 2025\n\n Oct 2025\n\n post by Aditya520 on Mar 31, 2025\n\n Aditya520\n\n This is the place to dive into the Pyth Benchmarks, the ultimate tool to query historic price on-chain.\n Drop your questions, share your use case, or show off what you’re building.\nThe Pyth team and community devs are here to help.\n\n 3 months later\n\n post by andgo75 on Jun 25, 2025\n\n andgo75\n\n How can I use benchmark data on Solana?\nfor example, I’ve got:\ncurl -s https://hermes.pyth.network/v2/updates/price/1750677111\\?ids\\[\\]\\=67be9f519b95cf24338801051f9a808eff0a578ccb388db73b7f6fe1de019ffb\\&parsed\\=false\\&encoding\\=base64 | jq .\n{\n \"binary\": {\n \"encoding\": \"base64\",\n \"data\": [\n \"UE5BVQEAAAADuAEAAAAEDQEyndMFmvirVBmWlxKbOzCuIj3krd3CYuUtAcG3sdirMG0zuxwwSlWn3GY3vUpQ6qbEfWBQPHdzbJXDW1QuChIXAAJ/eU/CKVm+pZiF4/6OD4SCZTRZ2yoIts/B75gFRBEI4X0KdS/b1cfc280lFZuRN3wg5RG77MMp338MjE3omXJ8AQO7ZeJxT5/Idb624bP5kt9E/ZSoPEP99h3O3GT2WY1s8wwOcqJxooOrAKlS/Zv94Ke2K7VePEzFCz3npbkIqjSPAAQu290JKf18/FJvRrLHBJJRn/uohRcokHfzADyI1snlpEjtSUHD9xZsEDjd/viAb6HSBJ7G19n20zylaOqC91CSAAbFHuV/NICc8afrT8gmGbCYhlyVqcg7ausfd5zjlv0QqkZXTWhZaPWrvOUBtxC2IVlzp4qK+WPoaXQMbtI6ITNyAQgbspi1l50TXm1qtNAWHnGQ1Ri+MUlFe4vgUW4DZUh3lFjJzTv4oTR/LcDVlvxWiyaHamthUBSnTkDYObxFt0apAQo2EynYlfMUNpyZnaN8a0VCyoXi+/K2yAJurJBW8pbslS1ypvccfyQpUp7lgeKVaO97LM89rMNHZOJjjYfkPoDnAAvwrFJOxhcWJaeiXBImtJQ9TdsTGQ/azx+hpoxPL7gLUByFUjOjsM6Z5HjUzpxU6kJ+eD7eiO5j7C2TpIw5XpzvAQzB5UUJo4tG9LMilQHXSDE7Wg0u4UkXHQ8FbzG0eh4n7y+8YPYgt3s9QU4JVRlFdrVUicPxlHIYD7zCgodCu1/+AA3e+SSX129g4VVwZov9/9tZNvJc7JzDehyP6VvIEnj+HBo8pKsbmUe2380GKn6yT/4WoktQIqkSHWz9ZN93tOF8AQ45FO1XAd/1koipxEml2KBGVmcK0iPc4w+DMiBrnESlXVipaIE10//S0DbeIXpPy4r70qQryOkSwWwAb3KT5pnEARDdvHh+xyE0W9S54HEcy00MYOKN6qq1W5+d68S/544CYUAbFIzxCMF5QyigdsIbdwiWrz3+l8fI7Z10cK7w0Yp4AREVo2D0fnEb/4TN9D3FjFywfksAeSpghIGV78drqO29JDDe5OnLeZNCKou177evZT915BSLo6k9dXS47LpnDRnAAGhZNncAAAAAABrhAfrtrFhR4yubI7X5QRqMK6xKrj7U3XuBHdGnLqSqcQAAAAAIX73vAUFVV1YAAAAAAA1tSdwAACcQFSTftowHFbiMFIL6P/N4hPz5AsgBAFUAZ76fUZuVzyQziAEFH5qAjv8KV4zLOI23O39v4d4Bn/sAAAADxaOIPwAAAAABpBh8////+AAAAABoWTZ3AAAAAGhZNnYAAAADxrcBAAAAAAABsZHcDP9liTH33XTb+qPm5d4lQNipr+liPZuNLIOjYkJkr80brAOL0ZxEk7b6tHKeksKIjAGExmIWVYUReyU+xlXnB7Tb19cL/7mHv/ZewojNSImYrrTMgG2ra1+IBqLHhGp6051IxOroJD00bAyJo1Bs13UyFA0hryD3j0A3/V/90pPNoG711oND7DcZMBowt//26K2dAwrcPXJnB8l3BcQrynhpiw5LyF9GLHg8//sUz2OzQbU+Ur5ZZ4PugNkbB4WwRE3FC5IHkC+QI+Hbec0T9LaTr+P4uNeZ8/1+UZkQhJo2UCUMkH6s5MXGvSVSkLfyUg==\"\n ]\n }\n}\n\nthis data is 1291 bytes, it excess solana transaction size (1232), so def I can’t put it in my tx. So what should I do to use it?\n\n 4 months later\n\n post by guibescos on Oct 22, 2025\n\n guibescos\n\n gm gm,\nSorry for the late response.\nThis is a good observation, indeed the data exceeds the transaction size and posting thus requires multiple transactions.\nThe sdk https://www.npmjs.com/package/@pythnetwork/pyth-solana-receiver can handle splitting up the payload in multiple transactions. Here is a benchmarks example using the sdk:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Benchmarks on Solana\n\n Benchmarks(Historic Prices)\n\n 1\n\n 498\n\n Jun 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Validating price data against benchmark api\n\n Benchmarks(Historic Prices)\n\n 2\n\n 411\n\n Oct 2025\n\n Benchmarks Explainer on Solana\n\n Price Feeds\n\n svm\n\n 7\n\n 836\n\n Aug 2025\n\n Powered by Discourse","tokens":1795,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262167674,"hash":"82b15a6eae0cadf093e3b316bd576235eee35842"}
{"url":"https://forum.openzeppelin.com/t/invalid-bignumber-value-for-string/40695/2","domain":"forum.openzeppelin.com","title":"Invalid BigNumber value for string - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n erc721,solidity\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 2 / 2\n\n May 2024\n\n Jun 2024\n\n post by Jalapina on May 30, 2024\n\n Jalapina\n\n When I try to run the pin function that takes an integer, i keep getting this error\n\ninvalid BigNumber value (argument=\"value\", value=undefined, code=INVALID_ARGUMENT, version=bignumber/5.7.0)\n\nfrontend code:\n const abi = [\n \"function pinGem(uint256 tokenId, string memory latitude, string memory longitude) public\"\n ];\n const contract = new ethers.Contract(contractAddress, abi, signer);\n\n try {\n const latitude = pinnedPosition.lat.toString();\n const longitude = pinnedPosition.lng.toString();\n\n const tx = await contract.pinGem(nft.tokenId, latitude, longitude);\n\ncontract:\ni tried using uint256, but kept getting the same error then switched to strings and still got the same error.\n// Compatible with OpenZeppelin Contracts ^5.0.0\npragma solidity ^0.8.20;\n\n struct Gem {\n uint256 id;\n string latitude;\n string longitude;\n }\n\n function pin(uint256 tokenId, string memory latitude, string memory longitude) public {\n require(ownerOf(tokenId) != address(0), \"Token ID does not exist\");\n pins[tokenId] = Pin(tokenId, latitude, longitude);\n }\n\n post by Jalapina on Jun 1, 2024\n\n Jalapina\n\n i was passing then ID oops\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error: invalid BigNumber string\n\n Contracts\n\n 1\n\n 1.3k\n\n Oct 2021\n\n BigNumber error\n\n Smart Contracts\n\n etherscan-verify\n\n 0\n\n 374\n\n Mar 2024\n\n How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1\n\n Smart Contracts\n\n 6\n\n 718\n\n May 2023\n\n Help please with: invalid number value (arg=“amount”, coderType=“uint256”\n\n Contracts\n\n erc20\n\n 3\n\n 8.6k\n\n Sep 2021\n\n Urgent question - 100e18 token transfer works but 1,000e18 doesn’t\n\n Smart Contracts\n\n erc721\n\n 1\n\n 807\n\n May 2022","tokens":475,"squid":"ink-security_audits","role":"Sentinel","at":1791262174875,"hash":"22a93673669509e86af20c0b3b673e2863977ba1"}
{"url":"https://dev-forum.pyth.network/c/help-price-feeds/benchmarks-historic-prices/9","domain":"dev-forum.pyth.network","title":"Latest Price Feeds/Benchmarks(Historic Prices) topics - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Latest topics in Benchmarks(Historic Prices)\n\n Price Feeds\n\n Benchmarks(Historic Prices)\n\n tags\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Benchmarks(Historic Prices) category\n\n This is the place to dive into the Pyth Benchmarks, the ultimate tool to query historic price on-chain. \n Drop your questions, share your use case, or show off what you’re building. \nThe Pyth team and co…\n\n read more\n\n 2\n\n 652\n\n Oct 2025\n\n How can I revoke or rotate an exposed Pyth API key?\n\n 1\n\n 9\n\n 8d\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Pyth Pro Streams query\n\n 4\n\n 37\n\n Aug 5\n\n Benchmark price for Uranus failing\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Not finding LIT/USD on Core Benchmarks\n\n 0\n\n 129\n\n Jan 7\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n Validating price data against benchmark api\n\n 2\n\n 411\n\n Oct 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n 16\n\n 524\n\n Oct 2025\n\n How to get more historical data faster?\n\n 3\n\n 585\n\n Sep 2025\n\n Historical Price Feed in 03/01/2023\n\n 11\n\n 644\n\n Sep 2025\n\n How can I read from sponsored SVM price feeds in my anchor program instead of sending update myself?\n\n svm\n\n 1\n\n 440\n\n Aug 2025\n\n How to get history of confidence interval (for backtest)\n\n 1\n\n 507\n\n Jul 2025\n\n Tracing back the aggregate price to the contributing publishers\n\n svm\n\n 3\n\n 574\n\n Jul 2025\n\n How do I get price feeds for stocks like AAPL at a particular timestamp? Current way is not working\n\n 1\n\n 721\n\n Jul 2025\n\n Benchmarks on Solana\n\n 1\n\n 498\n\n Jun 2025\n\n How to calculate USD prices for multiple coins in Sui when PriceInfoObject only contains one coin?\n\n 3\n\n 559\n\n May 2025\n\n [Breaking Change Notice] Update to TradingView Symbols Endpoint\n\n announcements\n\n 0\n\n 412\n\n Apr 2025\n\n Reading Moving Averages on-chain\n\n 6\n\n 580\n\n Apr 2025\n\n Websocket streaming for TradingView\n\n 2\n\n 553\n\n Apr 2025\n\n Powered by Discourse","tokens":1384,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262181838,"hash":"bea9bd68d786e85679c21f6fa7d2accfc7de6854"}
{"url":"https://dev-forum.pyth.network/t/pyth-pro-streams-query/812/1","domain":"dev-forum.pyth.network","title":"Pyth Pro Streams query - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Pro Streams query \n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jul 22\n\n 1 / 5\n\n Jul 21\n\n Aug 5\n\n post by PythUser on Jul 22\n\n PythUser\n\n For Pyth Pro Streams, does the StreamUpdated payload continue to be published during market off-hours, or does it simply keep returning the last available market price (e.g., Friday’s closing price) until the market reopens?\nFor example, if I receive the latest StreamUpdated payload on Saturday:\n\nWill it be the exact same report that was produced at Friday’s market close?\nOr will Pyth generate a new payload on Saturday containing the same price?\n\nAdditionally, in the Saturday payload, would feedUpdateTimestamp correspond to the actual market update time (Friday’s close), or would it reflect the time the Saturday payload was generated?\n\n Can't fetch historical prices with Pyth Terminal API\n\n 3\n\n 2\n\n 13 days later\n\n post by PythUser on Aug 5\n\n PythUser\n\n Can someone from pyth team please respond to this query, or point me to the right person?\n\n post by KemarTiti on Aug 5\n\n KemarTiti\n\n Apologies, completely missed that one.\nThe behavior depends on the channel:\n\nWith a fixed_rate@… channel, StreamUpdated messages continue at the configured interval during market off-hours. Once a feed has produced its first valid price, the latest price is carried forward; no new market price is generated while the market is closed.\nWith real_time, updates are sent when a new price is available, so a closed market may not produce regular updates.\n\nTo identify whether a price is fresh or carried forward, include feedUpdateTimestamp in the subscription properties:\n\nfeedUpdateTimestamp == timestampUs: the price was generated in the current update.\nfeedUpdateTimestamp < timestampUs: the price was carried forward from an earlier update.\n\nSo a Saturday fixed-rate update may contain Friday’s closing price, while feedUpdateTimestamp remains Friday’s price-generation time and timestampUs reflects the Saturday stream update.\nSee the subscription guide and payload reference.\n\n post by PythUser on Aug 5\n\n PythUser\n\n Thanks, that’s clear on using feedUpdateTimestamp == timestampUs to detect a fresh price.\nI want to follow up on the wording in one line: “a closed market may not produce regular updates.” The “may” implies that a closed market can still, under some conditions, “generate” a genuinely new price rather than only carrying the last one forward.\nConcretely: for an asset whose primary market is closed over the weekend, under what conditions can the feed generate a new price during that closed period, i.e., a real_time or fixed_rate update where feedUpdateTimestamp == timestampUs rather than a carried-forward one where feedUpdateTimestamp < timestampUs?\nI’m trying to understand whether “market closed” reliably means “no new price generation” on both channels, or whether fresh price generation can still occur off-hours for certain assets.\n\n post by KemarTiti on Aug 5\n\n KemarTiti\n\n If a feed’s marketSession is actually closed, Pyth should not generate a new price merely because a fixed_rate subscription continues sending updates. Those updates carry forward the latest available price, so feedUpdateTimestamp < timestampUs.\nreal_time only sends an update when a new price is available, so a genuinely closed feed should not produce fresh real_time prices either.\nThe important distinction is that “off-hours” does not always mean marketSession: \"closed\". Some feeds may have an active preMarket, postMarket, or overNight session, while crypto feeds operate 24/7. Fresh prices can be generated during those sessions, with feedUpdateTimestamp == timestampUs.\nTherefore, you should check both marketSession and feedUpdateTimestamp. If a feed reports marketSession: \"closed\" and feedUpdateTimestamp == timestampUs, that would be unexpected and worth investigating with the symbol, channel, and payload timestamps.\nThe available session values are regular, preMarket, postMarket, overNight, and closed. The details are in the payload reference.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 714\n\n Dec 2025\n\n Pyth Pro: Update to price `payload` in API Responses\n\n Announcements\n\n 0\n\n 220\n\n Feb 25\n\n Should we pay attention to the VAA timestamp when updating feeds?\n\n Price Feeds\n\n evm\n\n 2\n\n 353\n\n Oct 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Missing parsePriceFeedUpdatesUnique function on BSC implementation\n\n Price Feeds\n\n evm\n\n 6\n\n 46\n\n Jun 18\n\n Powered by Discourse","tokens":2064,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262194676,"hash":"826a2244f48c7b1a5711e6a86ea308fa2ec02e14"}
{"url":"https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html","domain":"specs.optimism.io","title":"Optimism Portal - OP Stack Specification","text":"OptimismPortal\n\nTable of Contents\n\nOverview\nDefinitions\n\nProof Maturity Delay\nProven Withdrawal\nFinalized Withdrawal\nDeleted Withdrawal Proof\nValid Withdrawal\nInvalid Withdrawal\nL2 Withdrawal Sender\nReceive Default Gas Limit\nMinimum Gas Limit\nUnsafe Target\nBlock Output\nOutput Root\nSuper Output\nSuper Root\n\nAssumptions\n\naOP-001: Dispute Game contracts properly report important properties\n\nMitigations\n\naOP-002: DisputeGameFactory properly reports its created games\n\nMitigations\n\naOP-003: Incorrectly resolving games will be invalidated before they have Valid Claims\n\nMitigations\n\nDependencies\nInvariants\n\niOP-001: Invalid Withdrawals can never be finalized\n\nImpact\n\niOP-002: Valid Withdrawals can always be finalized in bounded time\n\nImpact\n\nFunction Specification\n\nconstructor\ninitialize\npaused\nguardian\nethLockbox\nproofMaturityDelaySeconds\ndisputeGameFactory\ndisputeGameFinalityDelaySeconds\nrespectedGameType\nrespectedGameTypeUpdatedAt\nl2Sender\nproveWithdrawalTransaction\ncheckWithdrawal\ndeleteProvenWithdrawal\nfinalizeWithdrawalTransaction\ndonateETH\nfinalizeWithdrawalTransactionExternalProof\nnumProofSubmitters\nreceive\nminimumGasLimit\nsuperchainConfig\ndisputeGameBlacklist\ndepositTransaction\n\nOverview\nThe OptimismPortal contract is the primary interface for deposits and withdrawals between the L1\nand L2 chains within an OP Stack system. The OptimismPortal contract allows users to create\n\"deposit transactions\" on the L1 chain that are automatically executed on the L2 chain within a\nbounded amount of time. Additionally, the OptimismPortal contract allows users to execute\nwithdrawal transactions by proving that such a withdrawal was initiated on the L2 chain. The\nOptimismPortal verifies the correctness of these withdrawal transactions against Output Roots\nthat have been declared valid by the L1 Fault Proof system.\nDefinitions\nProof Maturity Delay\nThe Proof Maturity Delay is the minimum amount of time that a withdrawal must be a\nProven Withdrawal before it can be finalized.\nProven Withdrawal\nA Proven Withdrawal is a withdrawal transaction that has been proven against some Output Root\nby a user. Users can prove withdrawals against any Dispute Game contract that meets the following\nconditions:\n\nThe game is a Registered Game\nThe game is not a Retired Game\nThe game has a game type that matches the current\nRespected Game Type\nThe game has not resolved in favor of the Challenger\n\nNotably, the OptimismPortal allows users to prove withdrawals against games that are currently\nin progress (games that are not Resolved Games).\nUsers may re-prove a withdrawal at any time. User withdrawals are stored on a per-user basis such\nthat re-proving a withdrawal cannot cause the timer for\nfinalizing a withdrawal to be reset for another user.\nAnyone can delete the record of a withdrawal proof if the game it was proven against resolved in\nfavor of the Challenger or is a Blacklisted Game.\nRefer to Deleted Withdrawal Proof.\nFinalized Withdrawal\nA Finalized Withdrawal is a withdrawal transaction that was previously a Proven Withdrawal and\nmeets a number of additional conditions that allow the withdrawal to be executed.\nUsers can finalize a withdrawal if they have previously proven the withdrawal and their withdrawal\nmeets the following conditions:\n\nWithdrawal is a Proven Withdrawal\nWithdrawal was proven at least Proof Maturity Delay seconds ago\nWithdrawal was proven against a game with a Valid Claim\nWithdrawal was not previously finalized\n\nDeleted Withdrawal Proof\nA Deleted Withdrawal Proof is the record of a Proven Withdrawal that was\nremoved from the OptimismPortal. Anyone can delete such a record if the game that the withdrawal\nwas proven against meets at least one of the following conditions:\n\nThe game resolved in favor of the Challenger\nThe game is a Blacklisted Game\n\nBoth conditions are permanent, so a game in either state can never have a\nValid Claim. Deletion is therefore permissionless. The\ncaller can only remove a record that can never be used to finalize a withdrawal.\nDeletion applies to a single withdrawal hash and proof submitter. It does not change whether the\nwithdrawal is a Finalized Withdrawal. A user may prove the withdrawal\nagain against a different game.\nDeletion is limited to the conditions above. A user cannot delete a record proven against a\nRetired Game or against a game that is not a\nRespected Game, although these games can also never\nhave a Valid Claim. The Pause Mechanism does not\nprevent deletion.\nValid Withdrawal\nA Valid Withdrawal is a withdrawal transaction that was correctly executed on the L2 system as\nwould be reported by a perfect oracle for the query.\nInvalid Withdrawal\nAn Invalid Withdrawal is any withdrawal that is not a Valid Withdrawal.\nL2 Withdrawal Sender\nThe L2 Withdrawal Sender is the address of the account that triggered a given withdrawal\ntransaction on L2. The OptimismPortal is expected to expose a variable that includes this value\nwhen finalizing a withdrawal.\nReceive Default Gas Limit\nThe receive default gas limit is the gas limit provided for simple ETH deposits that are triggered\nwhen a user sends ETH to the OptimismPortal via the receive function. This gas limit is\ncurrently set to a value of 100000 gas.\nMinimum Gas Limit\nThe minimum gas limit is the minimum amount of L2 gas that must be purchased when creating a\ndeposit transaction. This limit increases linearly based on the size of the calldata to prevent\nusers from creating L2 resource usage without paying for it. The minimum gas limit is calculated\nas: calldata_byte_count * 40 + 21000.\nUnsafe Target\nAn Unsafe Target is a target address that is considered unsafe for withdrawal or deposit\ntransactions. Unsafe targets include the OptimismPortal contract itself and the ETHLockbox\ncontract. Targeting these addresses could potentially create attack vectors.\nBlock Output\nA Block Output, commonly called an Output, is a data structure that wraps the key hash\nelements of a given L2 block.\nThe structure of the Block Output is versioned (32 bytes). The current Block Output version is\n0x0000000000000000000000000000000000000000000000000000000000000000 (V0). A V0 Block Output has\nthe following structure:\nstruct BlockOutput {\n bytes32 version;\n bytes32 stateRoot;\n bytes32 messagePasserStorageRoot;\n bytes32 blockHash;\n}\n\nWhere:\n\nversion is a version identifier that describes the structure of the Output Root\nstateRoot is the state root of the L2 block this Output Root corresponds to\nmessagePasserStorageRoot is the storage root of the L2ToL1MessagePasser contract at the L2\nblock this Output Root corresponds to\nblockHash is the block hash of the L2 block this Output Root corresponds to\n\nOutput Root\nAn Output Root is a commitment to a Block Output. A detailed description of\nthis commitment can be found on this page.\nSuper Output\nA Super Output is a data structure that commits all of the Block Outputs for\nall chains within the Superchain Interop Set at a given timestamp. A Super Output can also commit\nto a single Block Output to maintain compatibility with chains outside of the Interop Set.\nThe structure of the Super Output is versioned (1 byte). The current version is 0x01 (V1). A V1\nSuper Output has the following structure:\nstruct OutputRootWithChainId {\n uint256 chainId;\n bytes32 root;\n}\n\nstruct SuperOutput {\n uint64 timestamp;\n OutputRootWithChainid[] outputRoots;\n}\n\nThe output root for each chain in the super root MUST be for the block with a timestamp where\n where is the super root timestamp, is the chain block time\nand is the block timestamp. That is the output root must be from the last possible block at or before the super\nroot timestamp.\nThe output roots in the super root MUST be sorted by chain ID ascending.\nSuper Root\nA Super Root is a commitment to a Super Output, computed as:\nkeccak256(encodeSuperRoot(SuperRoot))\n\nWhere encodeSuperRoot for the V1 Super Output is:\nfunction encodeSuperRoot(SuperRoot memory root) returns (bytes) {\n require(root.outputRoots.length > 0); // Super Root must have at least one Output Root.\n return concat(\n 0x01, // Super Root version byte\n root.timestamp,\n [\n concat(outputRoot.chainId, outputRoot.root)\n for outputRoot\n in root.outputRoots\n ]\n );\n}\n\nAssumptions\naOP-001: Dispute Game contracts properly report important properties\nWe assume that the FaultDisputeGame and PermissionedDisputeGame contracts properly and\nfaithfully report the following properties:\n\nGame type\nL2 block number\nRoot claim value\nGame extra data\nCreation timestamp\nResolution timestamp\nResolution result\nWhether the game was the respected game type at creation\n\nWe also specifically assume that the game creation timestamp and the resolution timestamp are not\nset to values in the future.\nMitigations\n\nExisting audit on the FaultDisputeGame contract\nIntegration testing\n\naOP-002: DisputeGameFactory properly reports its created games\nWe assume that the DisputeGameFactory contract properly and faithfully reports the games it has\ncreated.\nMitigations\n\nExisting audit on the DisputeGameFactory contract\nIntegration testing\n\naOP-003: Incorrectly resolving games will be invalidated before they have Valid Claims\nWe assume that any games that are resolved incorrectly will be invalidated either by\nblacklisting or by\nretirement BEFORE they are considered to have\nValid Claims.\nProper Games that resolve in favor the Defender will be considered to have Valid Claims after the\nDispute Game Finality Delay has\nelapsed UNLESS the Pause Mechanism is active. Therefore, in the absence of the Pause Mechanism,\nparties responsible for game invalidation have exactly the Dispute Game Finality Delay to\ninvalidate a withdrawal after it resolves incorrectly. If the Pause Mechanism is active, then any\nincorrectly resolving games must be invalidated before the pause is deactivated.\nMitigations\n\nStakeholder incentives / processes\nIncident response plan\nMonitoring\n\nDependencies\n\niASR-001\niASR-002\n\nInvariants\niOP-001: Invalid Withdrawals can never be finalized\nWe require that Invalid Withdrawals can never be\nfinalized for any reason.\nImpact\nSeverity: Critical\nIf this invariant is broken, any number of arbitrarily bad outcomes could happen. Most obviously,\nwe would expect all bridge systems relying on the OptimismPortal to be immediately compromised.\niOP-002: Valid Withdrawals can always be finalized in bounded time\nWe require that Valid Withdrawals can always be\nfinalized within some reasonable, bounded amount of time.\nImpact\nSeverity: Critical\nIf this invariant is broken, we would expect that users are unable to withdraw bridged assets. We\nsee this as a critical system risk.\nFunction Specification\nconstructor\n\nMUST set the value of the Proof Maturity Delay.\n\ninitialize\n\nMUST only be callable by the ProxyAdmin or its owner.\nMUST set the value of the SystemConfig contract.\nMUST set the value of the AnchorStateRegistry contract.\nMUST assert that the ETHLockbox state is valid based on the feature flag.\nMUST set the value of the L2 Withdrawal Sender variable to the default\nvalue if the value is not set already.\nMUST initialize the resource metering configuration.\n\npaused\nReturns the current state of the SystemConfig.paused() function.\nguardian\nReturns the address of the Guardian as per SystemConfig.guardian().\nethLockbox\nReturns the address of the ETHLockbox configured for this contract. If the contract has not been\nconfigured for this OptimismPortal, this function will return address(0).\nproofMaturityDelaySeconds\nReturns the value of the Proof Maturity Delay.\ndisputeGameFactory\nReturns the DisputeGameFactory contract from the AnchorStateRegistry contract.\ndisputeGameFinalityDelaySeconds\nLegacy Function\nReturns the value of the\nDispute Game Finality Delay as per\na call to AnchorStateRegistry.disputeGameFinalityDelaySeconds().\nrespectedGameType\nLegacy Function\nReturns the value of the current\nRespected Game Type as per a call to\nAnchorStateRegistry.respectedGameType.\nrespectedGameTypeUpdatedAt\nLegacy Function\nReturns the value of the current\nRetirement Timestamp as per a call to\n`AnchorStateRegistry.retirementTimestamp.\nl2Sender\nReturns the address of the L2 Withdrawal Sender. If the OptimismPortal\nhas not been initialized then this value will be address(0) and should not be used. If the\nOptimismPortal is not currently executing an withdrawal transaction then this value will be\n0x000000000000000000000000000000000000dEaD and should not be used.\nproveWithdrawalTransaction\nAllows a user to prove a withdrawal transaction.\n\nMUST revert if the system is paused.\nMUST revert if the withdrawal target is an Unsafe Target.\nMUST revert if the withdrawal is being proven against a game that is not a\nProper Game.\nMUST revert if the withdrawal is being proven against a game that is not a\nRespected Game.\nMUST revert if the withdrawal is being proven against a game that has resolved in favor of the\nChallenger.\nMUST revert if the current timestamp is less than or equal to the dispute game's creation\ntimestamp.\nMUST revert if the proof provided by the user of the preimage of the Output Root that the dispute\ngame argues about is invalid. This proof is verified by hashing the user-provided preimage and\ncomparing them to the root claim of the referenced dispute game.\nMUST revert if the provided merkle trie proof that the withdrawal was included within the root\nclaim of the provided dispute game is invalid.\nMUST otherwise store a record of the withdrawal proof that includes the hash of the proven\nwithdrawal, the address of the game against which it was proven, and the block timestamp at which\nthe proof transaction was submitted.\nMUST add the proof submitter to the list of submitters for this withdrawal hash.\nMUST emit a WithdrawalProven event with the withdrawal hash, sender, and target.\nMUST emit a WithdrawalProvenExtension1 event with the withdrawal hash and proof submitter address.\n\ncheckWithdrawal\nChecks that a withdrawal transaction can be finalized.\n\nMUST revert if the withdrawal being finalized has already been finalized.\nMUST revert if the withdrawal being finalized has not been proven.\nMUST revert if the withdrawal was proven at a timestamp less than or equal to the creation\ntimestamp of the dispute game it was proven against, which would signal an unexpected proving\nbug. Note that prevents withdrawals from being proven in the same block that a dispute game is\ncreated.\nMUST revert if the withdrawal being finalized has been proven less than\nProof Maturity Delay seconds ago.\nMUST revert if the withdrawal being finalized was proven against a game that does not have a\nValid Claim.\n\ndeleteProvenWithdrawal\nAllows anyone to delete the record of a withdrawal proof.\n\nMUST NOT restrict the caller.\nMUST NOT revert if the system is paused.\nMUST revert if the given proof submitter has not proven the given withdrawal hash.\nMUST revert if the game that the withdrawal was proven against has not resolved in favor of the\nChallenger AND is not a Blacklisted Game.\nMUST otherwise delete the record of the withdrawal proof for the given withdrawal hash and proof\nsubmitter only.\nMUST NOT change the record that the withdrawal was finalized.\nMUST NOT remove the proof submitter from the list of proof submitters for the withdrawal hash.\nMUST emit a WithdrawalProofDeleted event with the withdrawal hash and proof submitter address.\n\nfinalizeWithdrawalTransaction\nAllows a user to finalize a withdrawal transaction.\n\nMUST delegate to finalizeWithdrawalTransactionExternalProof with msg.sender as the proof\nsubmitter.\n\ndonateETH\nAllows any address to donate ETH to the contract without triggering a deposit to L2.\n\nMUST accept ETH payments via the payable modifier.\nMUST not perform any state-changing operations.\nMUST not trigger a deposit transaction to L2.\n\nfinalizeWithdrawalTransactionExternalProof\nAllows a user to finalize a withdrawal transaction using a proof submitted\nby another address.\n\nMUST revert if the system is paused.\nMUST revert if the function is called while a previous withdrawal is being executed.\nMUST revert if the withdrawal target is an Unsafe Target.\nMUST revert if the withdrawal being finalized does not pass checkWithdrawal.\nMUST mark the withdrawal as finalized.\nMUST unlock ETH from the ETHLockbox if the withdrawal includes an ETH value AND the OptimismPortal\nhas an ETHLockbox configured AND the ETHLockbox system feature is active.\nMUST set the L2 Withdrawal Sender variable correctly.\nMUST execute the withdrawal transaction by executing a contract call to the target address with\nthe data and ETH value specified within the withdrawal using AT LEAST the minimum amount of gas\nspecified by the withdrawal.\nMUST unset the L2 Withdrawal Sender after the withdrawal call.\nMUST emit a WithdrawalFinalized event with the withdrawal hash and success status.\nMUST lock any unused ETH back into the ETHLockbox if the call to the target address fails AND the\nOptimismPortal has an ETHLockbox configured AND the ETHLockbox system feature is active.\nMUST revert if the withdrawal call fails and the transaction origin is the estimation address, to\nhelp determine exact gas costs.\n\nnumProofSubmitters\nReturns the number of proof submitters for a given withdrawal hash.\n\nMUST return the length of the proofSubmitters array for the specified withdrawal hash.\nMUST NOT change state.\n\nreceive\nAccepts ETH value and creates a deposit transaction to the sender's address on L2.\n\nMUST be payable and accept ETH.\nMUST create a deposit transaction where the sender and target are the same address, refer to\ndepositTransaction for full specification of expected behavior.\nMUST use the receive default gas limit as the gas limit.\nMUST set contract creation flag to false.\nMUST use empty data for the deposit.\nMUST transform the sender address to its alias if the caller is a contract.\nMUST emit a TransactionDeposited event with the appropriate parameters.\n\nminimumGasLimit\nComputes the minimum gas limit for a deposit transaction based on calldata size.\n\nMUST calculate the minimum gas limit using the formula: calldata_byte_count * 40 + 21000.\n\nsuperchainConfig\nReturns the SuperchainConfig contract address.\n\nMUST return the address of the SuperchainConfig contract stored in the SystemConfig contract\nthat was set during initialization.\n\ndisputeGameBlacklist\nLegacy Function\nChecks if a dispute game is blacklisted.\n\nMUST delegate to the blacklist of the AnchorStateRegistry contract that was set during initialization.\nMUST return whether the given dispute game is blacklisted.\n\ndepositTransaction\nAccepts deposits of ETH and data, and emits a TransactionDeposited event for use in\nderiving deposit transactions. Note that if a deposit is made by a contract, its\naddress will be aliased when retrieved using tx.origin or msg.sender. Consider\nusing the CrossDomainMessenger contracts for a simpler developer experience.\n\nMUST lock any ETH value (msg.value) in the ETHLockbox contract if the OptimismPortal has an\nETHLockbox configured AND the ETHLockbox system feature is active.\nMUST revert if the target address is not address(0) for contract creations.\nMUST revert if the gas limit provided is below the minimum gas limit.\nMUST revert if the calldata is too large (> 120,000 bytes).\nMUST transform the sender address to its alias if the caller is a contract.\nMUST apply resource metering to the gas limit parameter.\nMUST emit a TransactionDeposited event with the from address, to address, deposit version, and\nopaque data.","tokens":4849,"squid":"ink-governance","role":"Council Listener","at":1791262195384,"hash":"8d196a9b982630f5d43718abfeccbc938591e085"}
{"url":"https://dev-forum.pyth.network/t/pyth-pro-streams-query/812/2","domain":"dev-forum.pyth.network","title":"Pyth Pro Streams query - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jul 22\n\n 2 / 5\n\n Aug 4\n\n Aug 5\n\n post by PythUser on Jul 22\n\n PythUser\n\n For Pyth Pro Streams, does the StreamUpdated payload continue to be published during market off-hours, or does it simply keep returning the last available market price (e.g., Friday’s closing price) until the market reopens?\nFor example, if I receive the latest StreamUpdated payload on Saturday:\n\nWill it be the exact same report that was produced at Friday’s market close?\nOr will Pyth generate a new payload on Saturday containing the same price?\n\nAdditionally, in the Saturday payload, would feedUpdateTimestamp correspond to the actual market update time (Friday’s close), or would it reflect the time the Saturday payload was generated?\n\n Can't fetch historical prices with Pyth Terminal API\n\n 3\n\n 2\n\n 13 days later\n\n post by PythUser on Aug 5\n\n PythUser\n\n Can someone from pyth team please respond to this query, or point me to the right person?\n\n post by KemarTiti on Aug 5\n\n KemarTiti\n\n Apologies, completely missed that one.\nThe behavior depends on the channel:\n\nWith a fixed_rate@… channel, StreamUpdated messages continue at the configured interval during market off-hours. Once a feed has produced its first valid price, the latest price is carried forward; no new market price is generated while the market is closed.\nWith real_time, updates are sent when a new price is available, so a closed market may not produce regular updates.\n\nTo identify whether a price is fresh or carried forward, include feedUpdateTimestamp in the subscription properties:\n\nfeedUpdateTimestamp == timestampUs: the price was generated in the current update.\nfeedUpdateTimestamp < timestampUs: the price was carried forward from an earlier update.\n\nSo a Saturday fixed-rate update may contain Friday’s closing price, while feedUpdateTimestamp remains Friday’s price-generation time and timestampUs reflects the Saturday stream update.\nSee the subscription guide and payload reference.\n\n post by PythUser on Aug 5\n\n PythUser\n\n Thanks, that’s clear on using feedUpdateTimestamp == timestampUs to detect a fresh price.\nI want to follow up on the wording in one line: “a closed market may not produce regular updates.” The “may” implies that a closed market can still, under some conditions, “generate” a genuinely new price rather than only carrying the last one forward.\nConcretely: for an asset whose primary market is closed over the weekend, under what conditions can the feed generate a new price during that closed period, i.e., a real_time or fixed_rate update where feedUpdateTimestamp == timestampUs rather than a carried-forward one where feedUpdateTimestamp < timestampUs?\nI’m trying to understand whether “market closed” reliably means “no new price generation” on both channels, or whether fresh price generation can still occur off-hours for certain assets.\n\n post by KemarTiti on Aug 5\n\n KemarTiti\n\n If a feed’s marketSession is actually closed, Pyth should not generate a new price merely because a fixed_rate subscription continues sending updates. Those updates carry forward the latest available price, so feedUpdateTimestamp < timestampUs.\nreal_time only sends an update when a new price is available, so a genuinely closed feed should not produce fresh real_time prices either.\nThe important distinction is that “off-hours” does not always mean marketSession: \"closed\". Some feeds may have an active preMarket, postMarket, or overNight session, while crypto feeds operate 24/7. Fresh prices can be generated during those sessions, with feedUpdateTimestamp == timestampUs.\nTherefore, you should check both marketSession and feedUpdateTimestamp. If a feed reports marketSession: \"closed\" and feedUpdateTimestamp == timestampUs, that would be unexpected and worth investigating with the symbol, channel, and payload timestamps.\nThe available session values are regular, preMarket, postMarket, overNight, and closed. The details are in the payload reference.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 714\n\n Dec 2025\n\n Pyth Pro: Update to price `payload` in API Responses\n\n Announcements\n\n 0\n\n 220\n\n Feb 25\n\n Should we pay attention to the VAA timestamp when updating feeds?\n\n Price Feeds\n\n evm\n\n 2\n\n 353\n\n Oct 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Missing parsePriceFeedUpdatesUnique function on BSC implementation\n\n Price Feeds\n\n evm\n\n 6\n\n 46\n\n Jun 18\n\n Powered by Discourse","tokens":2057,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262205165,"hash":"b9b0fbe64003339ae2a88acac5d985a3fea765ed"}
{"url":"https://specs.optimism.io/protocol/predeploys.html","domain":"specs.optimism.io","title":"Predeploys - OP Stack Specification","text":"Predeploys\n\nTable of Contents\n\nOverview\nLegacyMessagePasser\nL2ToL1MessagePasser\nDeployerWhitelist\nLegacyERC20ETH\nWETH9\nL2CrossDomainMessenger\nL2StandardBridge\nL1BlockNumber\nGasPriceOracle\nL1Block\nProxyAdmin\nSequencerFeeVault\nOptimismMintableERC20Factory\nOptimismMintableERC721Factory\nBaseFeeVault\nL1FeeVault\nSchemaRegistry\nEAS\nBeacon Block Root\nGovernance Token\nOperator Fee Vault\n\nOverview\nPredeployed smart contracts exist on Optimism\nat predetermined addresses in the genesis state. They are similar to precompiles but instead run\ndirectly in the EVM instead of running native code outside of the EVM.\nPredeploys are used instead of precompiles to make it easier for multiclient\nimplementations as well as allowing for more integration with hardhat/foundry\nnetwork forking.\nPredeploy addresses exist in a prefixed namespace 0x4200000000000000000000000000000000000xxx.\nProxies are set at the first 2048 addresses in the namespace, except for the addresses reserved for the\nGovernanceToken and WETH predeploys.\nThe LegacyERC20ETH predeploy lives at a special address 0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000\nand there is no proxy deployed at that account.\nThe following table includes each of the predeploys. The system version\nindicates when the predeploy was introduced. The possible values are Legacy\nor Bedrock or Canyon. Deprecated contracts should not be used.\nNameAddressIntroducedDeprecatedProxied\nLegacyMessagePasser0x4200000000000000000000000000000000000000LegacyYesYes\nDeployerWhitelist0x4200000000000000000000000000000000000002LegacyYesYes\nLegacyERC20ETH0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000LegacyYesNo\nWETH90x4200000000000000000000000000000000000006LegacyNoNo\nL2CrossDomainMessenger0x4200000000000000000000000000000000000007LegacyNoYes\nL2StandardBridge0x4200000000000000000000000000000000000010LegacyNoYes\nSequencerFeeVault0x4200000000000000000000000000000000000011LegacyNoYes\nOptimismMintableERC20Factory0x4200000000000000000000000000000000000012LegacyNoYes\nL1BlockNumber0x4200000000000000000000000000000000000013LegacyYesYes\nGasPriceOracle0x420000000000000000000000000000000000000FLegacyNoYes\nGovernanceToken0x4200000000000000000000000000000000000042LegacyNoNo\nL1Block0x4200000000000000000000000000000000000015BedrockNoYes\nL2ToL1MessagePasser0x4200000000000000000000000000000000000016BedrockNoYes\nL2ERC721Bridge0x4200000000000000000000000000000000000014LegacyNoYes\nOptimismMintableERC721Factory0x4200000000000000000000000000000000000017BedrockNoYes\nProxyAdmin0x4200000000000000000000000000000000000018BedrockNoYes\nBaseFeeVault0x4200000000000000000000000000000000000019BedrockNoYes\nL1FeeVault0x420000000000000000000000000000000000001aBedrockNoYes\nSchemaRegistry0x4200000000000000000000000000000000000020BedrockNoYes\nEAS0x4200000000000000000000000000000000000021BedrockNoYes\nBeaconBlockRoot0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02EcotoneNoNo\nOperatorFeeVault0x420000000000000000000000000000000000001BIsthmusNoYes\n\nLegacyMessagePasser\nImplementation\nAddress: 0x4200000000000000000000000000000000000000\nThe LegacyMessagePasser contract stores commitments to withdrawal\ntransactions before the Bedrock upgrade. A merkle proof to a particular\nstorage slot that commits to the withdrawal transaction is used as part\nof the withdrawing transaction on L1. The expected account that includes\nthe storage slot is hardcoded into the L1 logic. After the bedrock upgrade,\nthe L2ToL1MessagePasser is used instead. Finalizing withdrawals from this\ncontract will no longer be supported after the Bedrock and is only left\nto allow for alternative bridges that may depend on it. This contract does\nnot forward calls to the L2ToL1MessagePasser and calling it is considered\na no-op in context of doing withdrawals through the CrossDomainMessenger\nsystem.\nAny pending withdrawals that have not been finalized are migrated to the\nL2ToL1MessagePasser as part of the upgrade so that they can still be\nfinalized.\nL2ToL1MessagePasser\nImplementation\nAddress: 0x4200000000000000000000000000000000000016\nThe L2ToL1MessagePasser stores commitments to withdrawal transactions.\nWhen a user is submitting the withdrawing transaction on L1, they provide a\nproof that the transaction that they withdrew on L2 is in the sentMessages\nmapping of this contract.\nAny withdrawn ETH accumulates into this contract on L2 and can be\npermissionlessly removed from the L2 supply by calling the burn() function.\nDeployerWhitelist\nImplementation\nAddress: 0x4200000000000000000000000000000000000002\nThe DeployerWhitelist is a predeploy that was used to provide additional safety\nduring the initial phases of Optimism.\nIt previously defined the accounts that are allowed to deploy contracts to the network.\nArbitrary contract deployment was subsequently enabled and it is not possible to turn\noff. In the legacy system, this contract was hooked into CREATE and\nCREATE2 to ensure that the deployer was allowlisted.\nIn the Bedrock system, this contract will no longer be used as part of the\nCREATE codepath.\nThis contract is deprecated and its usage should be avoided.\nLegacyERC20ETH\nImplementation\nAddress: 0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000\nThe LegacyERC20ETH predeploy represents all ether in the system before the\nBedrock upgrade. All ETH was represented as an ERC20 token and users could opt\ninto the ERC20 interface or the native ETH interface.\nThe upgrade to Bedrock migrates all ether out of this contract and moves it to\nits native representation. All of the stateful methods in this contract will\nrevert after the Bedrock upgrade.\nThis contract is deprecated and its usage should be avoided.\nWETH9\nImplementation\nAddress: 0x4200000000000000000000000000000000000006\nWETH9 is the standard implementation of Wrapped Ether on Optimism. It is a\ncommonly used contract and is placed as a predeploy so that it is at a\ndeterministic address across Optimism based networks.\nL2CrossDomainMessenger\nImplementation\nAddress: 0x4200000000000000000000000000000000000007\nThe L2CrossDomainMessenger gives a higher level API for sending cross domain\nmessages compared to directly calling the L2ToL1MessagePasser.\nIt maintains a mapping of L1 messages that have been relayed to L2\nto prevent replay attacks and also allows for replayability if the L1 to L2\ntransaction reverts on L2.\nAny calls to the L1CrossDomainMessenger on L1 are serialized such that they\ngo through the L2CrossDomainMessenger on L2.\nThe relayMessage function executes a transaction from the remote domain while\nthe sendMessage function sends a transaction to be executed on the remote\ndomain through the remote domain's relayMessage function.\nL2StandardBridge\nImplementation\nAddress: 0x4200000000000000000000000000000000000010\nThe L2StandardBridge is a higher level API built on top of the\nL2CrossDomainMessenger that gives a standard interface for sending ETH or\nERC20 tokens across domains.\nTo deposit a token from L1 to L2, the L1StandardBridge locks the token and\nsends a cross domain message to the L2StandardBridge which then mints the\ntoken to the specified account.\nTo withdraw a token from L2 to L1, the user will burn the token on L2 and the\nL2StandardBridge will send a message to the L1StandardBridge which will\nunlock the underlying token and transfer it to the specified account.\nThe OptimismMintableERC20Factory can be used to create an ERC20 token contract\non a remote domain that maps to an ERC20 token contract on the local domain\nwhere tokens can be deposited to the remote domain. It deploys an\nOptimismMintableERC20 which has the interface that works with the\nStandardBridge.\nThis contract can also be deployed on L1 to allow for L2 native tokens to be\nwithdrawn to L1.\nL1BlockNumber\nImplementation\nAddress: 0x4200000000000000000000000000000000000013\nThe L1BlockNumber returns the last known L1 block number. This contract was\nintroduced in the legacy system and should be backwards compatible by calling\nout to the L1Block contract under the hood.\nIt is recommended to use the L1Block contract for getting information about\nL1 on L2.\nGasPriceOracle\nImplementation\nAddress: 0x420000000000000000000000000000000000000F\nIn the legacy system, the GasPriceOracle was a permissioned contract\nthat was pushed the L1 base fee and the L2 gas price by an offchain actor.\nThe offchain actor observes the L1 blockheaders to get the\nL1 base fee as well as the gas usage on L2 to compute what the L2 gas price\nshould be based on a congestion control algorithm.\nAfter Bedrock, the GasPriceOracle is no longer a permissioned contract\nand only exists to preserve the API for offchain gas estimation. The\nfunction getL1Fee(bytes) accepts an unsigned RLP transaction and will return\nthe L1 portion of the fee. This fee pays for using L1 as a data availability\nlayer and should be added to the L2 portion of the fee, which pays for\nexecution, to compute the total transaction fee.\nThe values used to compute the L1 portion of the fee prior to the Ecotone upgrade are:\n\nscalar\noverhead\ndecimals\n\nAfter the Bedrock upgrade, these values are instead managed by the\nSystemConfig contract on L1. The scalar and overhead values\nare sent to the L1Block contract each block and the decimals value\nhas been hardcoded to 6.\nFollowing the Ecotone upgrade, the values used for L1 fee computation are:\n\nbaseFeeScalar\nblobBaseFeeScalar\ndecimals\n\nThese new scalar values are managed by the SystemConfig contract on the L1 by introducing a\nbackwards compatible versioned encoding scheme of its scalars storage\nslot. The decimals remains hardcoded to 6, and the overhead value is ignored.\nL1Block\nImplementation\nAddress: 0x4200000000000000000000000000000000000015\nThe L1Block was introduced in Bedrock and is responsible for\nmaintaining L1 context in L2. This allows for L1 state to be accessed in L2.\nProxyAdmin\nProxyAdmin\nAddress: 0x4200000000000000000000000000000000000018\nThe ProxyAdmin is the owner of all of the proxy contracts set at the\npredeploys. It is itself behind a proxy. The owner of the ProxyAdmin will\nhave the ability to upgrade any of the other predeploy contracts.\nSequencerFeeVault\nImplementation\nAddress: 0x4200000000000000000000000000000000000011\nThe SequencerFeeVault accumulates any transaction priority fee and is the value of\nblock.coinbase.\nWhen enough fees accumulate in this account, they can be withdrawn to an immutable L1 address.\nTo change the L1 address that fees are withdrawn to, the contract must be\nupgraded by changing its proxy's implementation key.\nOptimismMintableERC20Factory\nImplementation\nAddress: 0x4200000000000000000000000000000000000012\nThe OptimismMintableERC20Factory is responsible for creating ERC20 contracts on L2 that can be\nused for depositing native L1 tokens into. These ERC20 contracts can be created permissionlessly\nand implement the interface required by the StandardBridge to just work with deposits and withdrawals.\nEach ERC20 contract that is created by the OptimismMintableERC20Factory allows for the L2StandardBridge to mint\nand burn tokens, depending on if the user is depositing from L1 to L2 or withdrawing from L2 to L1.\nOptimismMintableERC721Factory\nImplementation\nAddress: 0x4200000000000000000000000000000000000017\nThe OptimismMintableERC721Factory is responsible for creating ERC721 contracts on L2 that can be used for\ndepositing native L1 NFTs into.\nBaseFeeVault\nImplementation\nAddress: 0x4200000000000000000000000000000000000019\nThe BaseFeeVault predeploy receives the base fees on L2. The base fee is not\nburnt on L2 like it is on L1. Once the contract has received a certain amount\nof fees, the ETH can be withdrawn to an immutable address on\nL1.\nL1FeeVault\nImplementation\nAddress: 0x420000000000000000000000000000000000001a\nThe L1FeeVault predeploy receives the L1 portion of the transaction fees.\nOnce the contract has received a certain amount of fees, the ETH can be\nwithdrawn to an immutable address on L1.\nSchemaRegistry\nImplementation\nAddress: 0x4200000000000000000000000000000000000020\nThe SchemaRegistry predeploy implements the global attestation schemas for the Ethereum Attestation Service\nprotocol.\nEAS\nImplementation\nAddress: 0x4200000000000000000000000000000000000021\nThe EAS predeploy implements the Ethereum Attestation Service protocol.\nBeacon Block Root\nAddress: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02\nThe BeaconBlockRoot predeploy provides access to the L1 beacon block roots. This was added during the\nEcotone network upgrade and is specified in EIP-4788.\nGovernance Token\nAddress: 0x4200000000000000000000000000000000000042\nSee Governance Token specs.\nOperator Fee Vault\nImplementation\nAddress: 0x420000000000000000000000000000000000001B\nSee Operator Fee Vault spec.","tokens":3150,"squid":"ink-governance","role":"Council Listener","at":1791262205408,"hash":"bf4de7bcd06bf75ee1d10de25cf511fce2cb453f"}
{"url":"https://specs.optimism.io/glossary.html","domain":"specs.optimism.io","title":"Glossary - OP Stack Specification","text":"Glossary\n\nTable of Contents\n\nGeneral Terms\n\nLayer 1 (L1)\nLayer 2 (L2)\nBlock\nEOA\nMerkle Patricia Trie\nChain Re-Organization\nPredeployed Contract (\"Predeploy\")\nPreinstalled Contract (\"Preinstall\")\nPrecompiled Contract (\"Precompile\")\nReceipt\nTransaction Type\nFork Choice Rule\nPriority Gas Auction\n\nSequencing\n\nSequencer\nSequencing Window\nSequencing Epoch\nL1 Origin\n\nDeposits\n\nDeposited Transaction\nL1 Attributes Deposited Transaction\nUser-Deposited Transaction\nDepositing Call\nDepositing Transaction\nDepositor\nDeposited Transaction Type\nDeposit Contract\n\nWithdrawals\n\nRelayer\nFinalization Period\n\nBatch Submission\n\nData Availability\nData Availability Provider\nSequencer Batch\nChannel\nChannel Frame\nBatcher\nBatcher Transaction\nBatch submission frequency\nChannel Timeout\n\nL2 Output Root Proposals\n\nProposer\n\nL2 Chain Derivation\n\nL2 Derivation Inputs\nSystem Configuration\nPayload Attributes\nL2 Genesis Block\nL2 Chain Inception\nSafe L2 Block\nSafe L2 Head\nUnsafe L2 Block\nUnsafe L2 Head\nUnsafe Block Consolidation\nFinalized L2 Head\n\nOther L2 Chain Concepts\n\nAddress Aliasing\nRollup Node\nRollup Driver\nL1 Attributes Predeployed Contract\nL2 Output Root\nL2 Output Oracle Contract\nValidator\nFault Proof\nTime Slot\nBlock Time\nUnsafe Sync\n\nExecution Engine Concepts\n\nExecution Engine\n\nPost-Execution Transaction\n\nPost-Exec Payload\nPost-Exec Payload Schema Version\nSequencer-Defined Metering\nCanonical Gas\n\nGeneral Terms\nLayer 1 (L1)\nRefers the Ethereum blockchain, used in contrast to layer 2, which refers to Optimism.\nLayer 2 (L2)\nRefers to the Optimism blockchain (specified in this repository), used in contrast to layer 1, which\nrefers to the Ethereum blockchain.\nBlock\nCan refer to an L1 block, or to an L2 block, which are structured similarly.\nA block is a sequential list of transactions, along with a couple of properties stored in the header of the block. A\ndescription of these properties can be found in code comments here, or in the Ethereum yellow paper\n(pdf), section 4.3.\nIt is useful to distinguish between input block properties, which are known before executing the transactions in the\nblock, and output block properties, which are derived after executing the block's transactions. These include various\nMerkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.\nEOA\n\"Externally Owned Account\", an Ethereum term to designate addresses operated by users, as opposed to contract addresses.\nMerkle Patricia Trie\nA Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values.\nThe root hash of a MPT is a commitment to the contents of the tree, which allows a\nproof to be constructed for any key-value mapping encoded in the tree. Such a proof is called a Merkle proof, and can be\nverified against the Merkle root.\nChain Re-Organization\nA re-organization, or re-org for short, is whenever the head of a blockchain (its last block) changes (as dictated by\nthe fork choice rule) to a block that is not a child of the previous head.\nL1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via\nL2 chain derivation.\nPredeployed Contract (\"Predeploy\")\nA contract placed in the L2 genesis state (i.e. at the start of the chain).\nAll predeploy contracts are specified in the predeploys specification.\nPreinstalled Contract (\"Preinstall\")\nA contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same\nsecurity guarantees as predeploys, but are general use contracts made\navailable to improve the L2's UX.\nAll preinstall contracts are specified in the preinstalls specification.\nPrecompiled Contract (\"Precompile\")\nA contract implemented natively in the EVM that performs a specific operation more efficiently than a bytecode\n(e.g. Solidity) implementation. Precompiles exist at predefined addresses. They are created and modified through\nnetwork upgrades.\nAll precompile contracts are specified in the precompiles specification.\nReceipt\nA receipt is an output generated by a transaction, comprising a status code, the amount of gas used, a list of log\nentries, and a bloom filter indexing these entries. Log entries are most notably used to encode Solidity events.\nReceipts are not stored in blocks, but blocks store a Merkle Patricia Trie root for a tree containing the receipt\nfor every transaction in the block.\nReceipts are specified in the yellow paper (pdf) section 4.3.1.\nTransaction Type\nEthereum provides a mechanism (as described in EIP-2718) for defining different transaction types.\nDifferent transaction types can contain different payloads, and be handled differently by the protocol.\nFork Choice Rule\nThe fork choice rule is the rule used to determine which block is to be considered as the head of a blockchain. On L1,\nthis is determined by the proof of stake rules.\nL2 also has a fork choice rule, although the rules vary depending on whether we want the safe L2 head,\nthe unsafe L2 head or the finalized L2 head.\nPriority Gas Auction\nTransactions in ethereum are ordered by the price that the transaction pays to the miner. Priority Gas Auctions\n(PGAs) occur when multiple parties are competing to be the first transaction in a block. Each party continuously\nupdates the gas price of their transaction. PGAs occur when there is value in submitting a transaction before other\nparties (like being the first deposit or submitting a deposit before there is not more guaranteed gas remaining).\nPGAs tend to have negative externalities on the network due to a large amount of transactions being submitted in a\nvery short amount of time.\n\nSequencing\nTransactions in the rollup can be included in two ways:\n\nThrough a deposited transaction, enforced by the system\nThrough a regular transaction, embedded in a sequencer batch\n\nSubmitting transactions for inclusion in a batch saves costs by reducing overhead, and enables the sequencer to\npre-confirm the transactions before the L1 confirms the data.\nSequencer\nA sequencer is either a rollup node ran in sequencer mode, or the operator of this rollup node.\nThe sequencer is a privileged actor, which receives L2 transactions from L2 users, creates L2 blocks using them, which\nit then submits to data availability provider (via a batcher). It also submits output\nroots to L1.\nSequencing Window\nA sequencing window is a range of L1 blocks from which a sequencing epoch can be derived.\nA sequencing window whose first L1 block has number N contains batcher transactions for epoch\nN. The window contains blocks [N, N + SWS) where SWS is the sequencer window size.\nThe current default sws is 3600 epochs.\nAdditionally, the first block in the window defines the depositing transactions which determine the\ndeposits to be included in the first L2 block of the epoch.\nSequencing Epoch\nA sequencing epoch is sequential range of L2 blocks derived from a sequencing window of L1 blocks.\nEach epoch is identified by an epoch number, which is equal to the block number of the first L1 block in the\nsequencing window.\nEpochs can have variable size, subject to some constraints. See the L2 chain derivation specification\nfor more details.\nL1 Origin\nThe L1 origin of an L2 block is the L1 block corresponding to its sequencing epoch.\n\nDeposits\nIn general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).\nWhile transaction deposits are notably (but not only) used to \"deposit\" (bridge) ETH and tokens to L2, the word\ndeposit should be understood as \"a transaction deposited to L2 from L1\".\nThis term deposit is somewhat ambiguous as these \"transactions\" exist at multiple levels. This section disambiguates\nall deposit-related terms.\nNotably, a deposit can refer to:\n\nA deposited transaction (on L2) that is part of a deposit block.\nA depositing call that causes a deposited transaction to be derived.\nThe event/log data generated by the depositing call, which is what the rollup driver reads to\nderive the deposited transaction.\n\nWe sometimes also talk about user deposit which is a similar term that explicitly excludes L1 attributes deposited\ntransactions.\nDeposits are specified in the deposits specification.\nDeposited Transaction\nA deposited transaction is a L2 transaction that was derived from L1 and included in a L2 block.\nThere are two kinds of deposited transactions:\n\nL1 attributes deposited transaction, which submits the L1 block's attributes to the L1 Attributes\nPredeployed Contract.\nUser-deposited transactions, which are transactions derived from an L1 call to the deposit\ncontract.\n\nL1 Attributes Deposited Transaction\nAn L1 attributes deposited transaction is deposited transaction that is used to register the L1 block\nattributes (number, timestamp, ...) on L2 via a call to the L1 Attributes Predeployed Contract.\nThat contract can then be used to read the attributes of the L1 block corresponding to the current L2 block.\nL1 attributes deposited transactions are specified in the L1 Attributes Deposit section of the\ndeposits specification.\nUser-Deposited Transaction\nA user-deposited transaction is a deposited transaction which is derived from an L1 call to the deposit\ncontract (a depositing call).\nUser-deposited transactions are specified in the Transaction Deposits section of the deposits\nspecification.\nDepositing Call\nA depositing call is an L1 call to the deposit contract, which will be derived to a\nuser-deposited transaction by the rollup driver.\nThis call specifies all the data (destination, value, calldata, ...) for the deposited transaction.\nDepositing Transaction\nA depositing transaction is an L1 transaction that makes one or more depositing calls.\nDepositor\nThe depositor is the L1 account (contract or EOA) that makes (is the msg.sender of) the depositing\ncall. The depositor is NOT the originator of the depositing transaction (i.e. tx.origin).\nDeposited Transaction Type\nThe deposited transaction type is an EIP-2718 transaction type, which specifies the input fields\nand correct handling of a deposited transaction.\nSee the corresponding section of the deposits spec for more information.\nDeposit Contract\nThe deposit contract is an L1 contract to which EOAs and contracts may send deposits. The deposits are\nemitted as log records (in Solidity, these are called events) for consumption by rollup nodes.\nAdvanced note: the deposits are not stored in calldata because they can be sent by contracts, in which case the calldata\nis part of the internal execution between contracts, and this intermediate calldata is not captured in one of the\nMerkle Patricia Trie roots included in the L1 block.\ncf. Deposits Specification\n\nWithdrawals\n\nTODO expand this whole section to be clearer\n\nIn general, a withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.\nThe term withdrawal is somewhat ambiguous as these \"transactions\" exist at multiple levels. In order to differentiate\nbetween the L1 and L2 components of a withdrawal we introduce the following terms:\n\nA withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.\nA withdrawal finalizing transaction refers specifically to an L1 transaction which finalizes and relays the\nwithdrawal.\n\nRelayer\nAn EOA on L1 which finalizes a withdrawal by submitting the data necessary to verify its inclusion on L2.\nFinalization Period\nThe finalization period — sometimes also called withdrawal delay — is the minimum amount of time (in seconds) that\nmust elapse before a withdrawal can be finalized.\nThe finalization period is necessary to afford sufficient time for validators to make a fault\nproof.\n\nTODO specify current value for finalization period\n\nBatch Submission\nData Availability\nData availability is the guarantee that some data will be \"available\" (i.e. retrievable) during a reasonably long time\nwindow. In Optimism's case, the data in question are sequencer batches that validators\nneed in order to verify the sequencer's work and validate the L2 chain.\nThe finalization period should be taken as the lower bound on the availability window, since\nthat is when data availability is the most crucial, as it is needed to perform a fault proof.\n\"Availability\" does not mean guaranteed long-term storage of the data.\nData Availability Provider\nA data availability provider is a service that can be used to make data available. See the Data\nAvailability for more information on what this means.\nIdeally, a good data availability provider provides strong verifiable guarantees of data availability\nAt present, the supported data availability providers include Ethereum call data and blob data.\nSequencer Batch\nA sequencer batch is list of L2 transactions (that were submitted to a sequencer) tagged with an epoch\nnumber and an L2 block timestamp (which can trivially be converted to a block number, given our\nblock time is constant).\nSequencer batches are part of the L2 derivation inputs. Each batch represents the inputs needed to build\none L2 block (given the existing L2 chain state) — except for the first block of each epoch, which also needs\ninformation about deposits (cf. the section on L2 derivation inputs).\nChannel\nA channel is a sequence of sequencer batches (for sequential blocks) compressed together. The reason\nto group multiple batches together is simply to obtain a better compression rate, hence reducing data availability\ncosts.\nA channel can be split in frames in order to be transmitted via batcher\ntransactions. The reason to split a channel into frames is that a channel might be too large to\ninclude in a single batcher transaction.\nA channel is uniquely identified by its timestamp (UNIX time at which the channel was created) and a random value. See\nthe Frame Format section of the L2 Chain Derivation specification for more information.\nOn the side of the rollup node (which is the consumer of channels), a channel is considered to be\nopened if its final frame (explicitly marked as such) has not been read, or closed otherwise.\nChannel Frame\nA channel frame is a chunk of data belonging to a channel. Batcher transactions carry one or\nmultiple frames. The reason to split a channel into frames is that a channel might too large to include in a single\nbatcher transaction.\nBatcher\nA batcher is a software component (independent program) that is responsible to make channels available on a data\navailability provider. The batcher communicates with the rollup node in order to retrieve the channels. The channels are\nthen made available using batcher transactions.\n\nTODO In the future, we might want to make the batcher responsible for constructing the channels, letting it only\nquery the rollup node for L2 block inputs.\n\nBatcher Transaction\nA batcher transaction is a transaction submitted by a batcher to a data availability provider, in order to make\nchannels available. These transactions carry one or more full frames, which may belong to different channels. A\nchannel's frames may be split between multiple batcher transactions.\nWhen submitted to Ethereum calldata, the batcher transaction's receiver must be the sequencer inbox address. The\ntransaction must also be signed by a recognized batch submitter account. The recognized batch submitter account\nis stored in the System Configuration.\nBatch submission frequency\nWithin the sequencing-window constraints the batcher is permitted by the protocol to submit L2 blocks for\ndata-availability at any time. The batcher software allows for dynamic policy configuration by its operator.\nThe rollup enforces safety guarantees and liveness through the sequencing window, if the batcher does not submit\ndata within this allotted time.\nBy submitting new L2 data in smaller more frequent steps, there is less delay in confirmation of the L2 block\ninputs. This allows verifiers to ensure safety of L2 blocks sooner. This also reduces the time to finality of\nthe data on L1, and thus the time to L2 input-finality.\nBy submitting new L2 data in larger less frequent steps, there is more time to aggregate more L2 data, and\nthus reduce fixed overhead of the batch-submission work. This can reduce batch-submission costs, especially\nfor lower throughput chains that do not fill data-transactions (typically 128 KB of calldata, or 800 KB\nof blobdata) as quickly.\nChannel Timeout\nThe channel timeout is a duration (in L1 blocks) during which channel frames may land on L1 within\nbatcher transactions.\nThe acceptable time range for the frames of a channel is [channel_id.timestamp, channel_id.timestamp + CHANNEL_TIMEOUT]. The acceptable L1 block range for these frames are any L1 block whose timestamp falls inside this\ntime range. (Note that channel_id.timestamp must be lower than the L1 block timestamp of any L1 block in which frames\nof the channel are seen, or else these frames are ignored.)\nThe purpose of channel timeouts is dual:\n\nAvoid keeping old unclosed channel data around forever (an unclosed channel is a channel whose final frame was not\nsent).\nBound the number of L1 blocks we have to look back in order to decode sequencer batches from\nchannels. This is particularly relevant during L1 re-orgs, see the Resetting Channel Buffering\nsection of the L2 Chain Derivation specification for more information.\n\nTODO specify CHANNEL_TIMEOUT\n\nL2 Output Root Proposals\nProposer\nThe proposer's role is to construct and submit output roots, which are commitments to the L2's state, to the\nL2OutputOracle contract on L1 (the settlement layer). To do this, the proposer periodically queries the rollup node for\nthe latest output root derived from the latest finalized L1 block. It then takes the output root and submits it to the\nL2OutputOracle contract on the settlement layer (L1).\n\nL2 Chain Derivation\nL2 chain derivation is a process that reads L2 derivation inputs from L1 in order to derive the L2\nchain.\nSee the L2 chain derivation specification for more details.\nL2 Derivation Inputs\nThis term refers to data that is found in L1 blocks and is read by the rollup node to construct payload\nattributes.\nL2 derivation inputs include:\n\nL1 block attributes\n\nblock number\ntimestamp\nbasefee\nblob base fee\n\ndeposits (as log data)\nsequencer batches (as transaction data)\nSystem configuration updates (as log data)\n\nSystem Configuration\nThis term refers to the collection of dynamically configurable rollup parameters maintained\nby the SystemConfig contract on L1 and read by the L2 derivation process.\nThese parameters enable keys to be rotated regularly and external cost parameters to be adjusted\nwithout the network upgrade overhead of a hardfork.\nPayload Attributes\nThis term refers to an object that can be derived from L2 chain derivation inputs found on L1, which are\nthen passed to the execution engine to construct L2 blocks.\nThe payload attributes object essentially encodes a block without output properties.\nPayload attributes are originally specified in the Ethereum Engine API specification, which we expand in\nthe Execution Engine Specification.\nSee also the Building The Payload Attributes section of the rollup node specification.\nL2 Genesis Block\nThe L2 genesis block is the first block of the L2 chain in its current version.\nThe state of the L2 genesis block comprises:\n\nState inherited from the previous version of the L2 chain.\n\nThis state was possibly modified by \"state surgeries\". For instance, the migration to Bedrock entailed changes on\nhow native ETH balances were stored in the storage trie.\n\nPredeployed contracts\n\nThe timestamp of the L2 genesis block must be a multiple of the block time (i.e. a even number, since the\nblock time is 2 seconds).\nWhen updating the rollup protocol to a new version, we may perform a squash fork, a process that entails the creation\nof a new L2 genesis block. This new L2 genesis block will have block number X + 1, where X is the block number of\nthe final L2 block before the update.\nA squash fork is not to be confused with a re-genesis, a similar process that we employed in the past, which also\nresets L2 block numbers, such that the new L2 genesis block has number 0. We will not employ re-genesis in the future.\nSquash forks are superior to re-geneses because they avoid duplicating L2 block numbers, which breaks a lot of external\ntools.\nL2 Chain Inception\nThe L1 block number at which the output roots for the genesis block were proposed on the output\noracle contract.\nIn the current implementation, this is the L1 block number at which the output oracle contract was deployed or upgraded.\nSafe L2 Block\nA safe L2 block is an L2 block that can be derived entirely from L1 by a rollup node. This can vary\nbetween different nodes, based on their view of the L1 chain.\nSafe L2 Head\nThe safe L2 head is the highest safe L2 block that a rollup node knows about.\nUnsafe L2 Block\nAn unsafe L2 block is an L2 block that a rollup node knows about, but which was not derived from the L1\nchain. In sequencer mode, this will be a block sequenced by the sequencer itself. In validator mode, this will be a\nblock acquired from the sequencer via unsafe sync.\nUnsafe L2 Head\nThe unsafe L2 head is the highest unsafe L2 block that a rollup node knows about.\nUnsafe Block Consolidation\nUnsafe block consolidation is the process through which the rollup node attempts to move the safe L2\nhead a block forward, so that the oldest unsafe L2 block becomes the new safe L2 head.\nIn order to perform consolidation, the node verifies that the payload attributes derived from the L1\nchain match the oldest unsafe L2 block exactly.\nSee the Engine Queue section of the L2 chain derivation spec for more information.\nFinalized L2 Head\nThe finalized L2 head is the highest L2 block that can be derived from finalized L1 blocks — i.e. L1\nblocks older than two L1 epochs (64 L1 time slots).\n\nOther L2 Chain Concepts\nAddress Aliasing\nWhen a contract submits a deposit from L1 to L2, its address (as returned by ORIGIN and CALLER) will be\naliased with a modified representation of the address of a contract.\n\ncf. Deposit Specification\n\nRollup Node\nThe rollup node is responsible for deriving the L2 chain from the L1 chain (L1 blocks and their\nassociated receipts).\nThe rollup node can run either in validator or sequencer mode.\nIn sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are\nthen submitted to a data availability provider via batch submission. The L2 chain\nderivation then acts as a sanity check and a way to detect L1 chain re-orgs.\nIn validator mode, the rollup node performs derivation as indicated above, but is also able to \"run ahead\" of the L1\nchain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer's\nbehavior.\nA rollup node running in validator mode is sometimes called a replica.\n\nTODO expand this to include output root submission\n\nSee the rollup node specification for more information.\nRollup Driver\nThe rollup driver is the rollup node component responsible for deriving the L2 chain\nfrom the L1 chain (L1 blocks and their associated receipts).\n\nTODO delete this entry, alongside its reference — can be replaced by \"derivation process\" or \"derivation logic\"\nwhere needed\n\nL1 Attributes Predeployed Contract\nA predeployed contract on L2 that can be used to retrieve the L1 block attributes of L1 blocks with a given\nblock number or a given block hash.\ncf. L1 Attributes Predeployed Contract Specification\nL2 Output Root\nA 32 byte value which serves as a commitment to the current state of the L2 chain.\ncf. Proposing L2 output commitments\nL2 Output Oracle Contract\nAn L1 contract to which L2 output roots are posted by the sequencer.\nValidator\nA validator is an entity (individual or organization) that runs a rollup node in validator mode.\nDoing so grants a lot of benefits similar to running an Ethereum node, such as the ability to simulate L2 transactions\nlocally, without rate limiting.\nIt also lets the validator verify the work of the sequencer, by re-deriving output roots and comparing\nthem against those submitted by the sequencer. In case of a mismatch, the validator can perform a fault\nproof.\nFault Proof\nAn on-chain interactive proof, performed by validators, that demonstrates that a sequencer provided\nerroneous output roots.\ncf. Fault Proofs\nTime Slot\nOn L2, there is a block every 2 second (this duration is known as the block time).\nWe say that there is a \"time slot\" every multiple of 2s after the timestamp of the L2 genesis block.\nOn L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case\nof even benign consensus issues.\nBlock Time\nThe L2 block time is 2 second, meaning there is an L2 block at every 2s time slot.\nPost-merge, it could be said that the L1 block time is 12s as that is the L1 time slot. However, in\nreality the block time is variable as some time slots might be skipped.\nPre-merge, the L1 block time is variable, though it is on average 13s.\nUnsafe Sync\nUnsafe sync is the process through which a validator learns about unsafe L2 blocks from\nthe sequencer.\nThese unsafe blocks will later need to be confirmed by the L1 chain (via unsafe block consolidation).\n\nExecution Engine Concepts\nExecution Engine\nThe execution engine is responsible for executing transactions in blocks and computing the resulting state roots,\nreceipts roots and block hash.\nBoth L1 (post-merge) and L2 have an execution engine.\nOn L1, the executed blocks can come from L1 block synchronization; or from a block freshly minted by the execution\nengine (using transactions from the L1 mempool), at the request of the L1 consensus layer.\nOn L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,\nusing transactions derived from L1 blocks.\nIn these specifications, \"execution engine\" always refer to the L2 execution engine, unless otherwise specified.\n\ncf. Execution Engine Specification\n\nPost-Execution Transaction\nThe post-execution transaction, post-exec transaction, or post-exec tx is the EIP-2718 transaction with\ntype byte 0x7D that carries sequencer-provided consensus data. It is emitted by the sequencer and appended to a\nblock after the last user transaction; at most one may appear in a block, when present it MUST be the final\ntransaction in the block, and it is not propagated through the public mempool.\nA post-exec transaction has no signer, no nonce, no fee, and consumes no block gas; it carries a single payload\nfield (a post-exec payload) that clients apply as part of the block's canonical state\ntransition.\nSee the post-exec specification.\nPost-Exec Payload\nThe post-exec payload is the data structure carried by a post-exec transaction.\nIt is a versioned envelope: a version byte selects the payload schema, a blockNumber field anchors the payload\nto the containing block, and the remaining fields are defined by the active schema version.\nPost-Exec Payload Schema Version\nA monotonically assigned identifier that selects the field layout of a post-exec payload.\nSchema versions are described in the post-exec specification; the version-1 schema is defined by\nthe Sequencer-Defined Metering specification.\nSequencer-Defined Metering\nSequencer-Defined Metering (SDM) is the post-exec payload schema version 1\npolicy. SDM lets the sequencer include per-transaction gas refunds that adjust canonical gas accounting and fee\nsettlement.\nSee the SDM specification.\nCanonical Gas\nUnder Sequencer-Defined Metering, the gas a transaction is accounted for after its\ngas refund is applied: canonicalGasUsed = evmGasUsed - refund, where evmGasUsed is the raw gas reported by the\nEVM. Canonical gas is the value recorded in transaction receipts and summed into the block's cumulativeGasUsed\nand gasUsed. It is distinct from the raw EVM gas, and unrelated to the \"canonical chain\" sense of canonical\nused elsewhere in this glossary.\nSee the SDM specification.","tokens":6968,"squid":"ink-governance","role":"Council Listener","at":1791262215528,"hash":"98dac99351273ef96a9c2307564c3f828c6c4f61"}
{"url":"https://specs.optimism.io/interop/superchain-eth-bridge.html","domain":"specs.optimism.io","title":"Superchain ETH Bridge - OP Stack Specification","text":"SuperchainETHBridge\n\nTable of Contents\n\nOverview\nConstants\nDefinitions\n\nETH Bridging\nETH Liquidity\nCross-Chain Message\nSource Chain\nDestination Chain\n\nAssumptions\n\naSEB-001: L2ToL2CrossDomainMessenger properly delivers messages\n\nMitigations\n\naSEB-002: ETHLiquidity contract maintains sufficient liquidity\n\nMitigations\n\naSEB-003: SafeSend correctly transfers ETH to recipients\n\nMitigations\n\nInvariants\n\niSEB-001: ETH sent equals ETH received\n\nImpact\nDependencies\n\niSEB-002: Only authorized contracts can call relayETH\n\nImpact\nDependencies\n\niSEB-003: ETH cannot be sent to the zero address\n\nImpact\nDependencies\n\nFunction Specification\n\nsendETH\nrelayETH\n\nEvents\n\nSendETH\nRelayETH\n\nOverview\nThe SuperchainETHBridge is a predeploy contract that facilitates cross-chain ETH bridging within\nthe Superchain interop set. It serves as an abstraction layer on top of the\nL2toL2CrossDomainMessenger specifically designed for native ETH transfers between chains. The\ncontract integrates with the ETHLiquidity contract to manage native ETH liquidity across chains,\nensuring seamless cross-chain transfers of native ETH.\nThe SuperchainETHBridge only handles native ETH cross-chain transfers. For interoperable ETH\nwithdrawals, see the ETHLockbox specification.\nConstants\nNameValue\nSuperchainETHBridge Address0x4200000000000000000000000000000000000024\n\nDefinitions\nETH Bridging\nETH Bridging refers to the process of transferring native ETH from one chain to another within the\nSuperchain interop set. This process involves burning ETH on the source chain and minting an\nequivalent amount on the destination chain.\nETH Liquidity\nETH Liquidity refers to the availability of native ETH on a particular chain. The ETHLiquidity\ncontract manages this liquidity by providing a mechanism to burn and mint ETH as needed for\ncross-chain transfers.\nCross-Chain Message\nA Cross-Chain Message is a message sent from one chain to another using the\nL2ToL2CrossDomainMessenger. In the context of the SuperchainETHBridge, these messages contain\ninstructions to relay ETH to a recipient on the destination chain.\nSource Chain\nThe Source Chain is the chain from which a user initiates an ETH transfer. On this chain, ETH is\nburned from the user's account and a cross-chain message is sent to the destination chain.\nDestination Chain\nThe Destination Chain is the chain to which ETH is being transferred. On this chain, ETH is sent\nto the recipient's account based on the cross-chain message received from the source chain.\nAssumptions\naSEB-001: L2ToL2CrossDomainMessenger properly delivers messages\nWe assume that the L2ToL2CrossDomainMessenger contract properly and faithfully delivers messages\nbetween chains, maintaining the integrity and authenticity of the message contents.\nMitigations\n\nExtensive testing of the L2ToL2CrossDomainMessenger contract\nAudits of the messaging protocol\nMonitoring of cross-chain message delivery\n\naSEB-002: ETHLiquidity contract maintains sufficient liquidity\nWe assume that the ETHLiquidity contract maintains sufficient liquidity to fulfill all valid ETH\nminting requests. This is ensured by initializing the contract with type(uint248).max wei.\nMitigations\n\nTotal ETH supply is much less than the initial balance of the ETHLiquidity contract\nContract is initially initialized with type(uint248).max wei and can hold up to\ntype(uint256).max wei to prevent balance overflow\n\naSEB-003: SafeSend correctly transfers ETH to recipients\nWe assume that the SafeSend mechanism correctly transfers ETH to recipients without reverting\nfor valid addresses.\nMitigations\n\nExtensive testing of the SafeSend mechanism\nAudits of the ETH transfer logic\n\nInvariants\niSEB-001: ETH sent equals ETH received\nThe amount of ETH sent from the source chain must equal the amount of ETH received on the\ndestination chain for any given cross-chain transfer.\nImpact\nSeverity: Critical\nIf this invariant is broken, users could receive more or less ETH than they sent, leading to\ninflation or loss of funds.\nDependencies\n\naSEB-001\naSEB-002\n\niSEB-002: Only authorized contracts can call relayETH\nThe relayETH function must only be callable by the L2ToL2CrossDomainMessenger contract, and the\ncross-domain sender must be the SuperchainETHBridge contract on the source chain.\nImpact\nSeverity: Critical\nIf this invariant is broken, unauthorized parties could mint ETH on the destination chain without\nburning an equivalent amount on the source chain, leading to inflation.\nDependencies\n\naSEB-001\n\niSEB-003: ETH cannot be sent to the zero address\nThe sendETH function must revert if the recipient address is the zero address.\nImpact\nSeverity: High\nIf this invariant is broken, ETH could be sent to the zero address, effectively burning it without\nthe possibility of recovery.\nDependencies\nNone\nFunction Specification\nsendETH\nDeposits the msg.value of ETH into the ETHLiquidity contract and sends a cross-chain message\nto the specified _chainId to call relayETH with the _to address as the recipient and the\nmsg.value as the amount.\nfunction sendETH(address _to, uint256 _chainId) external payable returns (bytes32 msgHash_);\n\nMUST accept ETH via msg.value.\nMUST revert if the _to address is the zero address.\nMUST transfer msg.value of ETH from the msg.sender to the ETHLiquidity contract by calling\nETHLiquidity.burn{value: msg.value}().\nMUST create a cross-chain message to the SuperchainETHBridge contract on the destination chain\nwith the following parameters:\n\n_chainId: The destination chain ID.\nmessage: An encoded call to relayETH(msg.sender, _to, msg.value).\n\nMUST return the message hash msgHash_ generated by the L2ToL2CrossDomainMessenger.\nMUST emit a SendETH event with the msg.sender, _to, msg.value, and _chainId.\n\nrelayETH\nWithdraws ETH from the ETHLiquidity contract equal to the _amount and sends it to the _to address.\nfunction relayETH(address _from, address _to, uint256 _amount) external;\n\nMUST revert if called by any address other than the L2ToL2CrossDomainMessenger.\nMUST revert if the cross-domain sender is not the SuperchainETHBridge contract on the source\nchain.\nMUST withdraw _amount of ETH from the ETHLiquidity contract by calling\nETHLiquidity.mint(_amount).\nMUST transfer the _amount of ETH to the _to address using\nnew SafeSend{value: _amount}(_to).\nMUST emit a RelayETH event with the _from address, _to address, _amount, and source chain\nID.\n\nEvents\nSendETH\nMUST be triggered when sendETH is called.\nevent SendETH(address indexed from, address indexed to, uint256 amount, uint256 destination);\n\nRelayETH\nMUST be triggered when relayETH is called.\nevent RelayETH(address indexed from, address indexed to, uint256 amount, uint256 source);","tokens":1659,"squid":"ink-governance","role":"Council Listener","at":1791262226861,"hash":"a7236aa1c34e721b8e9032b9600745aed5a91f84"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19479729907483-How-can-I-add-Arbitrum-network-to-my-wallet","domain":"support.arbitrum.io","title":"How can I add Arbitrum network to my wallet? – Arbitrum Foundation","text":"Either you can manually add it using the following details:\n\nNetwork name: Arbitrum One\nNew RPC URL: https://arb1.arbitrum.io/rpc\nChain ID: 42161\nCurrency symbol: ETH\nBlock Explorer URL: https://arbiscan.io/\n\nOr just simply:\n\nGo to ChainList and connect your MetaMask Wallet.\nLook for 'Arbitrum One' in the search bar at the top of the page.\nTap 'Add to MetaMask' and the verified RPC information will be automatically added to your extension.\n\n Related articles\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?\n\n Please sign in to leave a comment.","tokens":198,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262234996,"hash":"96c538b02d37edaeeb18093da01151acc6a52c6b"}
{"url":"https://specs.optimism.io/interop/overview.html","domain":"specs.optimism.io","title":"Interoperability - OP Stack Specification","text":"Interop\nThe ability for a blockchain to easily read the state of another blockchain is called interoperability.\nRelatively trustless interop is possible between rollups by using L1 Ethereum as a hub. A message is\nwithdrawn from one chain to L1 and then deposited to another chain. The goal of OP Stack native interop\nis to enable cross chain messaging at a much lower latency than going through L1. Low latency interoperability\nallows for a horizontally scalable blockchain network.\nTermDefinition\nSource ChainA blockchain that includes an initiating message\nDestination ChainA blockchain that includes an executing message\nInitiating MessageAn event emitted from a source chain\nIdentifierA unique pointer to an initiating message\nExecuting MessageAn event emitted from a destination chain's CrossL2Inbox that includes an initiating message and identifier\nCross Chain MessageThe cumulative execution and side effects of the initiating message and executing message\nDependency SetThe set of chains that originate initiating transactions where the executing transactions are valid\nLogThe Ethereum consensus object created by the LOG* opcodes\nEventThe solidity representation of a log\n\nA total of two transactions are required to complete a cross chain message.\nThe first transaction is submitted to the source chain and any log that is emitted can be\nused as an initiating message that can be consumed on a destination chain. The second\ntransaction is submitted to the destination chain and includes the\ninitiating message as well as the identifier that uniquely points to the initiating message.\nThe chain's fork choice rule will reorg out any blocks that contain an executing message that is not valid.\nA valid executing message means that the identifier correctly references its initiating message.\nThis means that the sequencer SHOULD only include an executing message if they have checked its validity.\nThe integrity of a message is guaranteed at the application layer without the need for any sort of confirmation\ndepth.\nThe proof system is able to check the validity of all executing messages.\nSpecifications\n\nDependency Set: definition of chains and chain-dependencies in the Superchain.\nMessaging: messaging functionality, core of protocol-level interoperability.\nPredeploys: system contracts to interface with other chains.\nSequencer: Sequencer Policy and block-building information.\nVerifier: Verification of cross-L2 messaging.\nSuper Root: the global state commitment across the dependency set and its API.\nSuper Fault Dispute Game: the dispute game that resolves\nsuper root proposals. It is not interop specific. Interop gives its consolidation step executing messages to\nvalidate.\nToken Bridging: sending ERC20 tokens between chains\nETH Liquidity: ETH liquidity management.\nSuperchain ETH Bridge: sending ETH between chains.\nETH Bridging: sending ETH between chains.\nDerivation: Changes to derivation of block-attributes.\nTransaction Pool: Transaction-pool validation of transactions.","tokens":749,"squid":"ink-governance","role":"Council Listener","at":1791262240733,"hash":"8d40dfd99a448f8d861543a541c01b3a2e4d602d"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19480176370459-I-ve-sent-ARB-from-a-CEX-to-my-wallet-but-I-can-t-see-it","domain":"support.arbitrum.io","title":"I've sent $ARB from a CEX to my wallet but I can't see it – Arbitrum Foundation","text":"First of all, make sure you have the Arbitrum network added to your wallet and that you're on the correct network.\nMore details here: https://support.arbitrum.io/hc/en-gb/articles/19479729907483-How-can-I-add-Arbitrum-network-to-my-wallet-\n\nSecond, for you to be able to see your $ARB balance in your wallet, you need to add the $ARB smart contract address as a custom token.ARB contract: 0x912ce59144191c1204e64559fe8253a0e49e6548\n\nIf you're using Metamask, it will look like this:\n\n Recently viewed articlesHow can I add Arbitrum network to my wallet?\n\n Related articles\n\n How can I add Arbitrum network to my wallet?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?\n\n Please sign in to leave a comment.","tokens":225,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262246379,"hash":"d73b33a822e9dc06c52b2241863e881fc7474a0b"}
{"url":"https://specs.optimism.io/protocol/lagoon/post-exec.html","domain":"specs.optimism.io","title":"Post-Execution Transactions - OP Stack Specification","text":"Post-Execution Transactions\n\nTable of Contents\n\nOverview\nThe Post-Execution Transaction Type\n\nEncoding\nTransaction Hash\nGeneric Transaction Interface Representation\nSigner and Signature\nMempool and Propagation\n\nPost-Exec Payload Envelope\n\nSchema Version\nBlock Number\nDefined Schema Versions\n\nBlock-Level Structural Rules\nDA Footprint\nReceipt\n\nConsensus Fields\nJSON-RPC Fields\n\nTransaction-Scoped Fields\nBlock-Scoped Fields\n\nDerivation\nSubblocks\n\nThe post-exec transaction is carried in diff\nThe post-exec transaction never appears in transactions\nOnly the last subblock's post-exec transaction is canonical\nA subblock's transactions may be empty\nNo receipt is streamed for the post-exec transaction\n\nRationale\n\nOverview\nPost-execution transactions are an EIP-2718 transaction type that lets a block carry\nsequencer-provided consensus data. Unlike user-submitted or deposited transactions, a post-exec\ntransaction is created by the sequencer and appended to the block as its final transaction. A\nverifier applies its data as part of the block's state transition.\nThe post-exec transaction type is introduced by the Lagoon network upgrade, together with its\nfirst payload schema. Before the Lagoon activation timestamp a block MUST NOT contain a 0x7D transaction.\nThe post-exec transaction is a generic envelope: it carries a versioned post-exec payload\nwhose interpretation is defined by separate policy specifications. Today only one schema is defined,\nSequencer-Defined Metering (version = 1), specified in sdm.md. Future policies extend\nthis document by defining additional schema versions.\nThis document specifies the envelope: the transaction type, the encoding, and the structural invariants that hold\nregardless of the active schema. It does not specify what the payload fields mean — that is the responsibility\nof the active schema's specification.\nThe Post-Execution Transaction Type\nA post-execution transaction is an EIP-2718 typed transaction with type byte 0x7D (decimal 125).\nType byte 0x7D was selected because EIP-2718 transaction type identifiers may use values up to 0x7F; choosing a\nhigh identifier minimizes the chance of collision with future Ethereum L1 transaction types. 0x7E is reserved for\ndeposited transactions, and 0x7F is left unused in case it is\nlater assigned to a variable-length encoding scheme.\nEncoding\nThe EIP-2718 encoding of a post-exec transaction is:\n0x7D || rlp_encoded_payload\n\nwhere rlp_encoded_payload is the RLP encoding of the post-exec payload as a list,\nand || denotes byte concatenation. The type byte is immediately followed by the payload's own RLP list; the\npayload is not wrapped in an additional outer RLP list.\nTransaction Hash\nThe transaction hash of a post-exec transaction is:\nkeccak256(0x7D || rlp_encoded_payload)\n\nThe hash is computed over the full EIP-2718 encoding, so the type byte is included in the hash preimage. Because\nthe hash is a function of the payload alone, the payload's block number is what distinguishes\npayloads anchored to different block numbers. (Two blocks at the same height on competing forks that carry an\nidentical payload share the same post-exec transaction hash, exactly as a regular transaction would.)\nGeneric Transaction Interface Representation\nA post-exec transaction carries only a versioned post-exec payload; it has none of\nthe fields a user transaction carries (nonce, gas price, recipient, signature, …). When surfaced through a generic\ntransaction interface (e.g. eth_getTransactionByHash), it is represented by a minimal object containing only:\nFieldValue\ntype0x7D\nhashthe transaction hash\nfrom0x0000000000000000000000000000000000000000 (zero address)\ngas0\nvalue0\ninputthe RLP-encoded payload bytes\n\nStandard transaction fields that do not apply — including nonce, chainId, gasPrice, maxFeePerGas,\nmaxPriorityFeePerGas, to, accessList, and the signature fields — are omitted, not reported with placeholder\nvalues. Block-context fields (blockHash, blockNumber, transactionIndex) are populated as for any other\nincluded transaction.\nA post-exec transaction never charges fees, never debits or credits an account simply by being included, and\nconsumes no gas from the block gas pool. Any side effects on account balances are defined by the active schema,\nnot by this envelope.\nSigner and Signature\nA post-exec transaction has no signer and no signature: there is no (v, r, s) triple in its EIP-2718 encoding or\nin the transaction-hash preimage. Rather than a per-transaction signature, it is trusted because the block that\ncontains it is — unsafe blocks are gossiped in payloads signed by the sequencer, and safe blocks are derived from\nthe (signed) batcher transaction. The sequencer places it at a position that satisfies the\nblock-level structural rules.\nIts recovered sender is the zero address 0x0000000000000000000000000000000000000000, surfaced as the transaction\nobject's from field. The signature fields are omitted from transaction responses rather than reported as zero.\nMempool and Propagation\nA post-exec transaction is constructed by the sequencer as part of block production. Nodes MUST NOT accept\npost-exec transactions through public transaction-pool interfaces (e.g. eth_sendRawTransaction) and MUST NOT\npropagate them through transaction-gossip protocols. A post-exec transaction reaches verifiers only by being\nincluded in a block.\nPost-Exec Payload Envelope\nThe post-exec payload is RLP-encoded as a list whose first two fields are fixed:\n[version, blockNumber, ...schema-defined fields...]\n\nFieldTypeDescription\nversionuint8Schema version selecting the layout of the trailing fields.\nblockNumberuint64The L2 block number this payload is anchored to.\ntrailingvariesDefined by the active schema version.\n\nThe leading two fields define the envelope; all remaining fields belong to the schema selected by version.\nSchema Version\nversion is the post-exec payload schema version. When the new payload schema calls\nfor additional or different fields, a new version number is assigned and the new layout is documented as a\ndefined schema version.\nBlock Number\nblockNumber anchors the payload to the L2 block number of the containing block. The anchoring serves two\npurposes:\n\nIt guarantees that otherwise identical payloads anchored to different block numbers have distinct\ntransaction hashes.\nIt detects misordered or replayed payloads at decode time, before any schema-specific validation runs.\n\nThe normative rule that blockNumber equals the containing block's number is stated in\nBlock-Level Structural Rules.\nDefined Schema Versions\nversionSchema\n1Sequencer-Defined Metering\n\nNo other schema versions are currently defined. SDM (version = 1) is introduced by the\nLagoon network upgrade; see Overview.\nBlock-Level Structural Rules\nThe following rules hold for every block, regardless of which schema version is active. Any violation invalidates\nthe block.\n\nAt most one. A block contains at most one transaction with type byte 0x7D.\nLast in block. When a 0x7D transaction is present, it MUST be the final transaction of the block.\nAnchored to block. The blockNumber field of the embedded payload MUST equal the L2 block number of the\ncontaining block.\nRecognized schema. The payload's version MUST be a defined schema version.\nSchema must be active. When no schema version is active for the block's timestamp, the block MUST NOT\ncontain a 0x7D transaction.\n\nSchema-specific validity rules (e.g. constraints on the trailing fields) are layered on top of these envelope rules\nand are specified by each schema's document. Both layers MUST hold for the block to be valid.\nDA Footprint\nThe Jovian DA footprint block limit is modified to exclude\npost-exec transactions. When computing a block's daFootprint, clients MUST treat a post-exec transaction as\nhaving a DA footprint of zero. Clients MUST therefore skip transactions of type 0x7D when accumulating the\nblock's daFootprint, and a post-exec transaction's receipt MUST report blobGasUsed as zero.\nReceipt\nA post-exec transaction emits a receipt with type byte 0x7D.\nConsensus Fields\nThe RLP-encoded consensus fields of the receipt are identical to those of an EIP-1559 receipt:\n\npostStateOrStatus (EIP-658)\ncumulativeGasUsed\nlogsBloom\nlogs\n\nA post-exec transaction is constructed by the protocol; it is not executed as EVM code, emits no logs, and\nconsumes no gas from the block gas pool, so its own receipt records none of these:\n\npostStateOrStatus MUST encode success (EIP-658 status 1).\nlogs MUST be empty.\nlogsBloom MUST be the all-zero bloom filter.\ncumulativeGasUsed MUST equal the cumulativeGasUsed of the immediately preceding transaction's receipt. (In\nany L2 block the post-exec transaction has at least one preceding transaction — the L1 attributes deposit — so\nthere is always a previous receipt to inherit from.)\n\nThe post-exec receipt participates in the block's receipts trie like any other receipt. The transaction's payload,\nhowever, is consensus-critical and drives state changes under the active schema — for SDM, the per-transaction fee\nsettlement. Those changes are applied atomically with the transactions they refund, so they\nbelong to those transactions' state deltas, not to a separate post-exec state transition. Schema-specific data is\nlikewise surfaced on those transactions' receipts, not on the post-exec receipt.\nJSON-RPC Fields\nThe receipt that eth_getTransactionReceipt and eth_getBlockReceipts return carries fee fields beyond the\nconsensus fields above. They fall into two groups, and a post-exec receipt reports the two groups differently: a\npost-exec transaction pays no fees and is charged no gas and no DA footprint, but it sits in a block whose L1 fee\nparameters are the same for every transaction in it.\nTransaction-Scoped Fields\nThese describe what this transaction was charged. A post-exec transaction is charged nothing, so each of them MUST\nbe present and zero:\nFieldValue\ngasUsed0\neffectiveGasPrice0\nl1Fee0\nl1GasUsed0\nblobGasUsed0, per § DA Footprint\n\nClients MUST NOT omit l1Fee or l1GasUsed instead of reporting them as zero. Keeping them present and zero makes\na post-exec receipt the same shape as a regular transaction's receipt and matches gasUsed and effectiveGasPrice,\nwhich are reported as zero rather than omitted. A consumer that sums l1Fee over a block's receipts then reaches\nthe same total whether or not it special-cases the post-exec receipt.\ncumulativeGasUsed is also transaction-scoped, but it is block-cumulative rather than per-transaction: it inherits\nthe preceding receipt's value as specified in § Consensus Fields, and is therefore not zero.\nopGasRefund is surfaced only on the receipts of the transactions that a refund applies to, so a post-exec receipt\nMUST omit it or report it as null (see sdm.md § Receipt Extension).\nBlock-Scoped Fields\nThese describe the block's L1 fee parameters, read from the L1 attributes deposit. They are identical for every\ntransaction in the block, so a post-exec receipt MUST report each of them with the same value — and the same\npresence or absence — as every other receipt in the same block:\n\nl1GasPrice\nl1BaseFeeScalar\nl1BlobBaseFee\nl1BlobBaseFeeScalar\noperatorFeeScalar\noperatorFeeConstant\ndaFootprintGasScalar\n\nl1FeeScalar is reported only before Ecotone. Post-exec transactions require Lagoon,\nwhich activates after Ecotone, so a post-exec receipt never reports it.\nDerivation\nPost-exec transactions are constructed by the sequencer during block production and travel inside the L2 block\nbody — through both the unsafe p2p payload and the L1 batch — rather than being synthesized from L1 events the way\ndeposited transactions are. They are included in the block payload that is submitted to the data availability\nlayer alongside the user transactions and any deposited transactions.\nThe L1 batcher transaction format is unaffected: post-exec transactions appear inside L2 blocks, never as L1\nbatcher transactions. The future-tx-type decoding range described in\nderivation.md governs L1 receipts only and is\nunchanged.\nBecause a post-exec transaction is carried in the L2 block body, a span batch covering\nthat block must transpose it into the span batch txs structure. A post-exec transaction has no nonce, gas limit,\nrecipient or signature, so most of the per-transaction slots that structure reserves have no natural value for it.\nThe values they take, and the reconstruction rules that follow, are specified in\nSpan Batch Updates.\nSubblocks\nSubblocks stream an L2 block while the sequencer is still building it. A post-exec transaction\nis a function of the block's contents, so the sequencer recomputes it every time it extends the in-progress block.\nThis section specifies how it is exposed on that stream. It constrains the subblock wire format only; it does not\nchange any rule about the sealed block.\nThe decisions below are normative. Each is followed by a rationale and a consumer implication. The rationales are\nnon-normative and subject to change; they are recorded so a consumer can tell why the field sits where it does\nwithout having to ask.\nThe post-exec transaction is carried in diff\nA subblock exposes the in-progress block's post-exec transaction as diff.post_exec_tx, holding its\nEIP-2718 encoding — the 0x7D type byte followed by the RLP-encoded payload. It is a field of\nSubblockDelta, not a member of diff.transactions.\ndiff.post_exec_tx is absent when the in-progress block carries no post-exec transaction. Under SDM this is the\ncase whenever the sequencer has assigned no gas refunds, since a version-1 payload with an empty\ngasRefundEntries list is invalid and no post-exec transaction is appended at all.\nRationale (non-normative, subject to change). A subblock is not a block. Its transactions are append-only and\nimmutable once streamed, whereas its diff describes the cumulative in-progress block and is restated by every\nsubblock. A post-exec transaction is derived from the state after everything executed so far, so its value is\nrecomputed as subblocks are added. That makes it mutable data, which is what diff is for.\nConsumer implication. Read the post-exec transaction from diff, and expect its value to change from subblock to\nsubblock within one payload_id. Treat an absent post_exec_tx as \"this block has no post-exec transaction so\nfar\", not as an error and not as \"not yet computed\". Absence is not sticky either: a later subblock of the same\npayload_id may introduce the field once a refund becomes due.\nThe post-exec transaction never appears in transactions\ndiff.transactions MUST NOT contain a 0x7D transaction, in any subblock, at any index.\nRationale (non-normative, subject to change). Placing it in transactions would require the sequencer to know\nwhich subblock is the last one for the block, which it does not know while building. Appending it to an\nappend-only list in a subblock that turns out not to be last would publish a transaction that a later subblock\nsupersedes, and a consumer concatenating transactions across subblocks would reconstruct a transaction list\ncontaining several 0x7D transactions in non-final positions — a list that violates the\nblock-level structural rules the sealed block satisfies.\nConsumer implication. Do not look for the post-exec transaction in transactions, and do not expect the\nconcatenation of diff.transactions across a payload's subblocks to equal the sealed block's transaction list:\nit is that list minus its post-exec transaction. transactions continues to carry every other transaction of the\nblock, including the deposited transactions in the first subblock.\nOnly the last subblock's post-exec transaction is canonical\nThe diff.post_exec_tx of the last subblock of a payload is the post-exec transaction of the sealed block. The\nvalue carried by any earlier subblock is provisional.\nRationale (non-normative, subject to change). Each subblock's value reflects the block contents at that point in\nthe build. Only the final contents determine the transaction that is actually included, and the payload is\nanchored to the block number rather than to any subblock, so intermediate values are not\nindependently meaningful.\nConsumer implication. The stream carries no marker identifying the last subblock of a payload, and the number of\nsubblocks per block is a target rather than a guarantee — a block may carry one fewer\nor one more than usual. A consumer therefore MUST NOT treat any subblock's post_exec_tx as final while the block\nis still being built. Determine that the block was sealed by other means, such as observing the next payload_id\nor the canonical block arriving through normal L2 block propagation, and note that the in-progress block may be\nabandoned rather than sealed, in which case no value from it was ever canonical.\nA subblock's transactions may be empty\nA subblock MAY have transactions: []. This applies to subblocks after index 0; the first subblock always\ncarries at least the block's deposited transactions.\nRationale (non-normative, subject to change). A subblock carries a state diff and the current post_exec_tx\nwhether or not it added transactions. A producer emits one per round regardless, so that the stream's cadence\ndoes not depend on transaction arrival and consumers get a heartbeat during quiet rounds. Suppressing those\nrounds would also withhold the updated diff.\nConsumer implication. Handle an empty transactions list as ordinary: it is neither an error nor a signal that\nnothing changed. Such a subblock still restates diff, including the current post_exec_tx, and still advances\nindex.\nNo receipt is streamed for the post-exec transaction\nmetadata.receipts MUST NOT contain an entry for a post-exec transaction. It covers the transactions in\ndiff.transactions only.\nRationale (non-normative, subject to change). Same as the reason it is absent from transactions: a receipt for\na provisional post-exec transaction would be superseded, and its\ncumulativeGasUsed is inherited from the preceding transaction's receipt, so the value would shift as\nlater subblocks add transactions. Consumers can obtain the canonical receipt from the sealed block.\nConsumer implication. Fetch the post-exec transaction's receipt from the sealed block rather than from the\nsubblock stream. Do not infer from the missing receipt that the transaction failed or was dropped.\nRationale\nWhy a versioned payload. A version byte at the head of the payload lets the schema extend or replace its\ntrailing fields without re-spending an EIP-2718 type byte.\nWhy last in block. Placing the post-exec transaction at the end of the block gives it a unique, predictable\nposition and matches the natural \"after everything else\" semantics of the data it carries.\nWhy exclude post-exec transactions from the DA footprint. A post-exec transaction is constructed only after\nthe block's standard transactions have executed and its schema-defined payload is known. Including it in the DA\nfootprint would require block builders to reserve or recompute footprint at finalization and would add a special\nlate-stage accounting path for both producers and verifiers. Excluding it avoids that complexity at the cost of a\nsmall, bounded underestimate. A block contains at most one post-exec transaction, and the\nversion-1 SDM payload contains at most one bounded-size entry per standard\ntransaction, so the omitted encoded data grows at most linearly with the number of transactions in the block. The\nDA footprint is an estimate rather than an exact\ncompressed-size calculation, and this bounded error does not materially change its purpose as a block-level limit.","tokens":4882,"squid":"ink-governance","role":"Council Listener","at":1791262252094,"hash":"61dbd76ac1bbf7c59715b0358f9a24f5003fbd92"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-v4-on-base/25427/8","domain":"governance.aave.com","title":"[ARFC] Deploy Aave V4 on Base - Governance / New Asset - Aave","text":"GovernanceNew Asset\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n read \n\n 14\n min\n\n Aug 3\n\n 8 / 8\n\n Sep 24\n\n 11d ago\n\n post by AaveLabs on Aug 3\n\n post by cedricbrown on Aug 8\n\n 10 days later\n\n post by signalxu on Aug 18\n\n 10 days later\n\n post by ArctekAudits on Aug 29\n\n 23 days later\n\n post by LlamaRisk on Sep 21\n\n post by AaveLabs on Sep 21\n\n post by AaveLabs on Sep 25\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave Labs is finalizing preparations to activate Aave V4 on Base and wants to give the community formal advance notice ahead of execution. The first market is the Equities Hub, holding seven Coinbase issued tokenized equities (AAPLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc, TSLAc) alongside USDC, with a MAG7 Spoke where the equities are collateral only and not borrowable. USDC is the sole borrowable asset. The activation also enables the Equities USDC Tokenization Spoke, which acts as an ERC-4626 entry point for USDC deposits across all spokes of the USDC reserve on the Equities Hub. The market is deployed and fully configured with every spoke registration halted, so no supply, borrow, or liquidity movement is possible until activation.\nThe ARFC to deploy Aave V4 on Base has been raised to Snapshot, using the risk parameters LlamaRisk recommended in this thread. The Snapshot vote is taken as the binding vote for this execution, and activation proceeds only if the Snapshot result is positive.\nThis activation does not take the form of an AIP and carries no Aave Governance V3 vote. The Aave V4 Protocol Security Council 0x187AAE17d4931310B3fc75743e7F16Bdc9eD77e9 (5-of-8, the same signer set as on Ethereum) carries it out directly through its Executor 0xA9D9923A1ADC1200771aaaA38CFeD6A5b8483d70, which holds HUB_CONFIGURATOR_DOMAIN_ADMIN_ROLE on the Base V4 AccessManager. The deployed configuration was verified onchain against LlamaRisk’s recommendations.\nThese addresses are added to the aave-address-book and permissions-book. For transparency, the table below lists the price feed used for each Hub reserve, following LlamaRisk’s recommendations. The USDC reserve uses the Chainlink USDC/USD feed rather than an SVR feed:\n\nReserve\nPrice source\nKind\nFeeds\n\nAAPLc\n0x787f13dEa48Db0897CbCDD985de77809D837F988\nChainlink OCR2 proxy\nCoinbase AAPL/USD\n\nAMZNc\n0x06A8E4b3aBB3B7543d8396FB2B763d22820cB295\nChainlink OCR2 proxy\nCoinbase AMZN/USD\n\nGOOGLc\n0x5bF49E0ffA937CE2FfF033c739aD7C634c4D34F2\nChainlink OCR2 proxy\nCoinbase GOOGL/USD\n\nMETAc\n0x6526aE6797A76123638b863AeE4dD27Ba4E4b27D\nChainlink OCR2 proxy\nCoinbase META/USD\n\nMSFTc\n0xeB10A6c9aa7E537aEd766C08c35Dae35B321b18c\nChainlink OCR2 proxy\nCoinbase MSFT/USD\n\nNVDAc\n0x04689a41629776563E6822F76f2e57D148d28513\nChainlink OCR2 proxy\nCoinbase NVDA/USD\n\nTSLAc\n0xFaf869185383a24F8cb00e27BdA6b63B9905DCb4\nChainlink OCR2 proxy\nCoinbase TSLA/USD\n\nUSDC\n0xC7d0f8dCC1F860ca752054c59Ea82Ba2A5AaB50c\nPriceCapAdapterStable\nChainlink USDC/USD, cap 1.04\n\nBased on LlamaRisk’s recommendation in this thread, a different configuration compared to that of Ethereum and Avalanche (see Snapshot) is applied for the Risk Stewrads in the Equities Hub. They would operate within the same bounds as on those networks, but with shorter cooldowns on caps (12 hours instead of 36 hours) and on spoke parameters (36 hours instead of 72 hours), while the maximum change per update is unchanged. These configurations will be implemented through the AIP process in the upcoming days.\nAt execution, the payload clears the halted flag on every spoke registration across the Hub, making the MAG7 Spoke and the Equities USDC Tokenization Spoke fully operational on Base. Caps and oracle configuration are unchanged from deployment, and the action changes no roles, owners, or oracles.\nReferences\n\nImplementation: AaveV4Base_AaveV4BaseActivation_20260919\nTests: AaveV4Base_AaveV4BaseActivation_20260919\nSnapshot\n\n AL Development Update | September 2026\n\n post by AaveLabs on Sep 25\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave V4 on Base has been successfully activated. The Protocol Security Council lifted the temporary halt placed on the market at deployment, following the same execution described in the previous update, and the market is now fully operational.\nThe instance is live and accessible through pro.aave.com, with USDC, APLc, AMZNc, GOOGLc, METAc, MSFTc, NVDAc and TSLAc available as reserves from launch, per the configuration and price feeds shared previously in this thread.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Umbrella on Aave v4: Coverage Framework and Initial Market Parametrization\n\n Governance\n\n 1\n\n 227\n\n Sep 12\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d","tokens":1254,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262253856,"hash":"7c88851b8f70e645cb1780b7c337bbdbde91aa6d"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18213854684699-You-need-ETH-to-power-transactions","domain":"support.arbitrum.io","title":"You need ETH to power transactions – Arbitrum Foundation","text":"When moving funds from Mainnet (L1) to Arbitrum (L2), you'll need ETH in your Arbitrum wallet.Even if you want only to use another, non-ETH, token, you will still need a small amount of ETH in your wallet on the Arbitrum network. This is because all Arbitrum transactions are powered by ETH. \nETH is the currency used for gas fees. Arbitrum gas fees go to Arbitrum validators to track chain state and execute transactions. This is actually an estimated fee; if the true fee is lower, then you will be refunded.\n\n Recently viewed articlesI've sent $ARB from a CEX to my wallet but I can't see itHow can I add Arbitrum network to my wallet?\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Please sign in to leave a comment.","tokens":235,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262268286,"hash":"9bb5daade4166f0a314735fe60838a99ed75f192"}
{"url":"https://governance.aave.com/t/arfc-aave-v4-activation-on-ethereum-mainnet/24293/53","domain":"governance.aave.com","title":"[ARFC] Aave V4 Activation on Ethereum Mainnet - Governance - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 20\n\n 19\n\n 2\n\n 2\n\n read \n\n 67\n min\n\n Mar 13\n\n 51 / 51\n\n Sep 30\n\n 5d ago\n\n Load more posts above\n\n post by AaveLabs on Jun 18\n\n 13 days later\n\n post by LlamaRisk on Jul 2\n\n post by chainza on Jul 7\n\n post by LlamaRisk on Jul 10\n\n post by AaveLabs on Jul 17\n\n post by LlamaRisk on Jul 23\n\n post by AaveLabs on Jul 24\n\n 9 days later\n\n post by LlamaRisk on Aug 3\n\n post by AaveLabs on Aug 5\n\n post by LlamaRisk on Aug 11\n\n post by AaveLabs on Aug 14\n\n post by LlamaRisk on Aug 20\n\n post by AaveLabs on Aug 24\n\n post by LlamaRisk on Aug 28\n\n post by AaveLabs on Sep 1\n\n post by LlamaRisk on Sep 4\n\n post by AaveLabs on Sep 11\n\n post by LlamaRisk on Sep 16\n\n 8 days later\n\n post by LlamaRisk on Sep 25\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk recommends an eighteenth round of Add Cap and Draw Cap adjustments for Aave V4. Following the execution of Round 17, total deposits across the six hubs on three chains grew to approximately $950M, led by the Core Hub at approximately $487M and by the Arc Core Hub, which reached approximately $232M in its second week. This round proposes replenishing the Core Hub’s credit lines to the Plus Hub, which have again reached full utilization, alongside continued increases to the weETH collateral add caps on the Core Hub, further USDe expansion on the Plus Hub, syrupUSDG cap increases on the Global Dollar Hubs, doubled USDC and USDt add caps on the Avalanche Core Hub, and cap increases on the Arc Core Hub, where the USDC add cap moves from 150,000,000 to 200,000,000, the USDC draw cap from 51,000,000 to 100,000,000 after the existing line was fully drawn, and the cirBTC add cap from 1,100 to 1,600. We also recommend aligning stablecoin and WETH IRMs with the recently implemented V3 changes.\nThe proposed adjustments add approximately $163M in additional Add Cap capacity: Ethereum Core $34M, Ethereum Plus $15M, Global Dollar $10M, Avalanche Core $12M, Arc Core $92M. Total market capacity would move from approximately $1.82B to $1.99B.\nRationale\nRound 17 caps are now live. Total deposits increased by approximately 34% over the week, with the Arc Core Hub standing out as USDC supply moved toward the doubled cap and cirBTC deposits reached 91% of their add cap.\nOn the Core Hub, we propose increasing the weETH and USDG caps to accommodate continued demand. USDe caps are also proposed to be increased following last week’s full utilization.\nOn the Global Dollar Hub, we propose increasing the syrupUSDG caps, which were fully utilized, while reducing the PT-USDG add cap to 1 as the collateral matures on September 24. The stablecoin draw lines against PT-USDG will remain in place to facilitate an orderly unwind of existing positions.\nOn the Avalanche Core Hub, the three stablecoin reserves closest to their ceilings are USDC on the Main Spoke (98% of a 10,000,000 cap), USDC on the Forex Spoke (96% of 1,000,000) and USDt on the Forex Spoke (86% of 1,000,000). We propose doubling each add cap. Draw caps are left unchanged, as USDC borrowing on the Main Spoke sits at 41% of its 9,000,000 line and the Forex lines are barely used.\nOn the Arc Core Hub, the USDC draw cap of 51,000,000 on the Main Spoke was fully utilized on September 24, as USDC borrowed against the line rose from approximately $1.5M to $50,987,826. We propose raising the USDC add cap to 200,000,000 and the draw cap to 100,000,000. At current supply, a fully drawn 100,000,000 line corresponds to 70% utilization, which sits below the 90% Optimal Usage Ratio of the USDC interest rate curve, and the higher add cap leaves room for the supply that has followed each cap increase on this hub so far. cirBTC deposits on the same spoke reached 1,003 against a 1,100 cap (91%) within a day of the first inflows, so we also propose raising the cirBTC add cap to 1,600, approximately $135M at the current oracle price.\nIRM\nAlongside the cap adjustments, we recommend aligning stablecoin Growth Before Optimal (Slope1) parameters to a 4.5% floor, consistent with the recently implemented V3 changes outlined in TokenLogic’s Stablecoin Rate Adjustments thread.\nFor WETH on the Ethereum Core Hub, we recommend lowering Slope1 to 2.2% to align with the corresponding V3 markets. The proposed IRM changes would have the following impact on rates:\n\nHub\nAsset\nCurrent Utilization\nBorrow APR now → new\nSupply APR now → new\n\nCore\nUSDT\n96.0%\n13.88% → 14.38% (+0.50pp)\n11.99% → 12.42% (+0.43pp)\n\nPrime\nUSDT\n93.8%\n8.62% → 9.12% (+0.50pp)\n7.28% → 7.70% (+0.42pp)\n\nGlobal Dollar\nUSDC\n90.3%\n3.92% → 4.41% (+0.49pp)\n3.19% → 3.59% (+0.40pp)\n\nGlobal Dollar\nUSDT\n50.9%\n2.21% → 2.49% (+0.28pp)\n1.01% → 1.14% (+0.13pp)\n\nCore\nWETH\n92.1%\n2.48% → 2.33% (-0.15pp)\n1.94% → 1.82% (-0.12pp)\n\nChanges Since Round 17 (September 24, 2026)\nDeposits have grown from $708,568,349 to $949,952,837 (+34%).\nimage2520×1620 271 KB\nSource: LlamaRisk, September 24, 2026\nThe most notable inflows include cirBTC on the Arc Core Main Spoke (+$84,520,996), USDC on the Arc Core Main Spoke (+$18,535,598), weETH on the Core Main Spoke (+$14,347,600), wstETH on the Core Main Spoke (+$7,026,953), weETH on the Core Etherfi Spoke (+$6,078,159).\nCap Utilization\nTotal deposits across all 6 hubs stand at $949,952,837. The Core Hub holds $486,818,587 (52% of Add Cap), the Prime Hub holds $76,685,668 (39% of Add Cap), the Plus Hub holds $33,787,687 (51% of Add Cap), the Global Dollar Hub holds $88,026,738 (52% of Add Cap), the Avalanche Core Hub holds $32,528,219 (39% of Add Cap), the Arc Core Hub holds $232,105,938 (65% of Add Cap).\nimage2520×2592 327 KB\nSource: LlamaRisk, September 24, 2026\n10 reserves across the protocol have exceeded 80% Add Cap utilization:\n\nUSDe (Plus Hub, Ethena Ecosystem): 100% Add Cap filled (14,999,936/15,000,000, $14,995,219)\nUSDC (Avalanche Core Hub, Main): 98% Add Cap filled (9,803,656/10,000,000, $9,802,853)\nUSDG (Core Hub, Main): 98% Add Cap filled (78,253,999/80,000,000, $78,259,477)\nweETH (Core Hub, Main): 96% Add Cap filled (11,563/12,000, $34,423,223)\nUSDC (Avalanche Core Hub, Forex): 96% Add Cap filled (962,899/1,000,000, $962,820)\nUSDC (Arc Core Hub, Main): 96% Add Cap filled (143,389,074/150,000,000, $143,375,872)\ncirBTC (Arc Core Hub, Main): 91% Add Cap filled (1,003/1,100, $84,696,331)\nUSDt (Avalanche Core Hub, Forex): 86% Add Cap filled (858,347/1,000,000, $858,095)\nsyrupUSDG (Global Dollar Hub, Maple SyrupUSDG): 86% Add Cap filled (42,792,070/50,000,000, $43,316,894)\nUSDG (Global Dollar Hub, Maple SyrupUSDG): 81% Add Cap filled (36,322,562/45,000,000, $36,325,105)\n\nimage2340×2736 384 KB\nSource: LlamaRisk, September 24, 2026\nA further 9 reserves sit in the 50 to 80% range:\n\nLINK (Core Hub, Main): 66% filled\nWETH (Core Hub, Main): 61% filled\nUSDC (Core Hub, Forex): 60% filled\nUSDT (Core Hub, Main): 59% filled\nweETH (Core Hub, Etherfi): 58% filled\nfrxUSD (Core Hub, Main): 56% filled\nWAVAX (Avalanche Core Hub, Main): 53% filled\nUSDT (Plus Hub, Ethena Ecosystem): 52% filled\nUSDC (Plus Hub, Ethena Ecosystem): 51% filled\n\nOn the draw side, 8 credit lines have exceeded 80% Draw Cap utilization. The USDC line on the Arc Core Main Spoke reached its cap on September 24, and the Core Hub lines to the Ethena Ecosystem Spoke remain fully drawn:\n\nUSDC (Core Hub, Ethena Ecosystem): 100% Draw Cap filled (1,501,919/1,500,000, $1,501,733)\nUSDT (Core Hub, Ethena Ecosystem): 100% Draw Cap filled (750,835/750,000, $750,599)\nUSDG (Core Hub, Maple SyrupUSDG): 100% Draw Cap filled (10,007,927/10,000,000, $10,008,628)\nfrxUSD (Core Hub, Ethena Ecosystem): 100% Draw Cap filled (15,009,853/15,000,000, $15,008,371)\nUSDC (Global Dollar Hub, Maple SyrupUSDG): 100% Draw Cap filled (2,500,020/2,500,000, $2,499,711)\nUSDC (Arc Core Hub, Main): 100% Draw Cap filled (50,992,521/51,000,000, $50,987,826)\nUSDG (Core Hub, Forex): 93% Draw Cap filled (1,863,025/2,000,000, $1,863,155)\nUSDG (Core Hub, Main): 91% Draw Cap filled (40,877,717/45,000,000, $40,880,578)\n\nimage2340×2417 356 KB\nSource: LlamaRisk, September 24, 2026\nRecommendations\nRound 18 targets approximately $163M in additional Add Cap capacity (Ethereum Core $34M, Ethereum Plus $15M, Global Dollar $10M, Avalanche Core $12M, Arc Core $92M), together with the USDG cap correction and draw-side relief on the most utilized borrow lines, including a 100,000,000 USDC draw cap on the Arc Core Hub.\nNote: The USDT draw cap increase on the Core Hub Ethena Ecosystem Spoke will be implemented in two steps, from 750K to 1.5M, then to 3M, via Risk Stewards.\nimage2520×1620 222 KB\nSource: LlamaRisk, September 24, 2026\nCore Hub\n\nSpoke\nAsset\nCurrent Add Cap\nProposed Add Cap\nCurrent Draw Cap\nProposed Draw Cap\n\nForex\nUSDG\n0\n-\n2,000,000\n3,000,000\n\nMain\nUSDG\n80,000,000\n90,000,000\n45,000,000\n50,000,000\n\nMain\nweETH\n12,000\n20,000\n0\n-\n\nEthena Ecosystem\nUSDC\n0\n-\n1,500,000\n3,000,000\n\nEthena Ecosystem\nUSDT\n0\n-\n750,000\n3,000,000\n\nPlus Hub\n\nSpoke\nAsset\nCurrent Add Cap\nProposed Add Cap\nCurrent Draw Cap\nProposed Draw Cap\n\nEthena Ecosystem\nUSDe\n15,000,000\n30,000,000\n4,800,000\n-\n\nGlobal Dollar Hub\n\nSpoke\nAsset\nCurrent Add Cap\nProposed Add Cap\nCurrent Draw Cap\nProposed Draw Cap\n\nMaple SyrupUSDG\nsyrupUSDG\n50,000,000\n60,000,000\n0\n-\n\nUSDG Pendle\nPT-USDG-24SEP2026\n30,000,000\n1\n0\n-\n\nAvalanche Core Hub\n\nSpoke\nAsset\nCurrent Add Cap\nProposed Add Cap\nCurrent Draw Cap\nProposed Draw Cap\n\nMain\nUSDC\n10,000,000\n20,000,000\n9,000,000\n-\n\nForex\nUSDC\n1,000,000\n2,000,000\n950,000\n-\n\nForex\nUSDt\n1,000,000\n2,000,000\n950,000\n-\n\nArc Core Hub\n\nSpoke\nAsset\nCurrent Add Cap\nProposed Add Cap\nCurrent Draw Cap\nProposed Draw Cap\n\nMain\nUSDC\n150,000,000\n200,000,000\n51,000,000\n100,000,000\n\nMain\ncirBTC\n1,100\n1,600\n220\n-\n\nIRM\n\nHub\nAsset\nCurrent Growth Before Optimal\nProposed Growth Before Optimal\n\nCore\nUSDT\n4.00%\n4.50%\n\nPrime\nUSDT\n4.00%\n4.50%\n\nGlobal Dollar\nUSDC\n4.00%\n4.50%\n\nGlobal Dollar\nUSDT\n4.00%\n4.50%\n\nCore\nWETH\n2.35%\n2.20%\n\nNext Steps\nFollowing review and confirmation, the recommended cap and IRM adjustments will be submitted via the Risk Stewards. We will continue to monitor cap utilization across all hubs and provide further recommendations for adjustments as market conditions evolve. All Hub utilization will be reassessed as deposits approach their current ceilings.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a community risk service provider for the Aave DAO. LlamaRisk did not receive compensation from the protocol(s) or their affiliated entities for this work. The information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n post by AaveLabs 5 days ago\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The Round 17 of Add Cap and Draw Cap adjustments for Aave V4 was successfully implemented through the Aave Security Council, see transactions:\n\nEthereum: 0xfc468…8a810\nAvalanche: 0x0e736…d22a5\nArc: 0x3b940…ce480\n\nAfter the successful activation of the Aave Risk Stewards for Aave V4, the Round 18 of Add Cap and Draw Cap adjustments for Aave V4 was successfully implemented by the stewards. Following increases will follow-up Aave Risk Stewards process.\n\n This topic will close a month after the last reply.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n Aave V4 Hub-and-Spoke Initial Configurations\n\n Governance\n\n 5\n\n 1.2k\n\n Mar 6\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h","tokens":2902,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262276083,"hash":"a0a8fa5ed8bcfa8b943b8b367befa770b225de72"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvWwSO3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBumVr6QEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJTL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4Mjc2NTkzMTc5LVdoeS1hcmUtdGhlcmUtMi1kaWZmZXJlbnQtVVNEQy1zLW9uLUFyYml0cnVtBjsIVDoJcmFua2kJ--47ad85592441f6f31980ac5171d15e6920d623c6","domain":"support.arbitrum.io","title":"Why are there 2 different USDC's on Arbitrum? – Arbitrum Foundation","text":"Understanding native vs. bridged\nNative USDC is officially issued by Circle and always redeemable 1:1 for US dollars.\nIn the case of Arbitrum, there also exists a “bridged” form of USDC, known as USDC.e, that’s been bridged from Ethereum. USDC.e is not issued by Circle.\n\nNative USDC on Arbitrum:\n\nToken Name: USD Coin\nToken Symbol: USDC\nToken Address: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n\nBridged USDC on Arbitrum: (from Ethereum)\n\nToken Name: Bridged USDC\nToken Symbol: USDC.e\nToken Address: 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8\n\n Recently viewed articlesYou need ETH to power transactionsI've sent $ARB from a CEX to my wallet but I can't see itHow can I add Arbitrum network to my wallet?\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n How can I add Arbitrum network to my wallet?\n\n You need ETH to power transactions\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Please sign in to leave a comment.","tokens":257,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262281636,"hash":"95fa8b3d67f135c7c7ba927588db3170a77141d3"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/2","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 2 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n asanso\n\n This is Part 2 of a blog series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we introduced the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In this installment, we’ll dive deeper into Falcon, a promising post-quantum signature algorithm, examining its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework.\nFalcon Signature Scheme - Technical Overview\nFalcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) builds upon the lattice-based signature framework of Gentry, Peikert, and Vaikuntanathan (GPV). It applies this framework to NTRU lattices and employs a “fast Fourier sampling” trapdoor sampler. The scheme relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is considered computationally hard to solve in the general case, even with quantum computers, as no efficient solving algorithm is currently known.\nCore Components\nFalcon is based on the hash-and-sign paradigm and is an evolution of the traditional RSA signature scheme. However, instead of relying on number-theoretic problems, it leverages the hardness of lattice-based problems. Falcon’s security is based on the hardness of finding short vectors in NTRU lattices, leveraging Gaussian sampling techniques for generating trapdoor bases with reduced norms. This ensures efficient key generation and signing.\n\nKey Generation:\n\nGiven an NTRU polynomial ring ( \\mathbb{Z}[X] / (X^n + 1))(ℤ[𝑋]/(𝑋𝑛 +1)), a private key consists of two short polynomials ( f, g )(𝑓,𝑔) satisfying the NTRU equation.\nThe public key is derived as ( h = g / f )(ℎ =𝑔/𝑓) in the ring ( \\mathbb{Z}_q[X] / (X^n + 1) )(ℤ𝑞[𝑋]/(𝑋𝑛 +1)).\n\nSigning Process:\n\nA message is hashed into a challenge vector in the lattice domain.\nA short solution is sampled using fast Fourier sampling, ensuring a compact signature size while maintaining security against lattice reduction attacks.\nThe signature consists of the short lattice vector satisfying the challenge.\n\nVerification:\n\nThe verifier checks whether the signature satisfies the public key relation in the lattice ring.\nVerification involves computing norms and ensuring the validity of the lattice basis under modular arithmetic.\n\nFalcon is designed to offer a robust post-quantum signature solution, combining lattice-based cryptography with efficient sampling techniques. While its security benefits are clear, like any cryptographic system, it presents certain trade-offs in terms of complexity and implementation challenges. Now, let’s break down the highlights, potential pitfalls, and some of the more challenging aspects of Falcon.\nThe Good\nAside from the well-known benefits highlighted by NIST, such as Compact Signatures, Fast Operations (efficient key generation and verification via FFT techniques), and Security Proofs (relying on lattice reductions and worst-case hardness assumptions). Falcon also provides Ethereum-specific advantages. Notably, it has a well-defined worst-case running time, making it particularly useful for the Ethereum Virtual Machine (EVM), where predictable performance and execution times are essential for scalability and reliability.\nThe Bad\nFalcon’s reliance on floating-point arithmetic and specialized number-theoretic transforms (NTT/FFT) can lead to implementation complexity and sensitivity to side-channel vulnerabilities during signing. However, this is NOT a significant concern for Ethereum, as signing occurs off-chain, where performance is less critical. The main focus is on optimizing the verification process, which happens on-chain, ensuring efficient and secure execution.\nThe Gnarly\nThere has been ongoing research into efficiently aggregating Falcon signatures, such as the work presented in this paper. Assuming the aggregation will be efficient enough, using Falcon in the consensus layer to replace the BLS signature (instead of the alternative proposal based on Hash-Based Multi-Signatures) would help maintain a more homogeneous stack across the Ethereum network.\nConclusion\nFalcon is a strong candidate for post-quantum cryptography applications, including blockchain systems like Ethereum, where signature size and verification efficiency are critical. In Part 3 of the series, we will begin implementing the hybrid approach introduced in Part 1, initially focusing on Account Abstraction and a Solidity contract for Falcon verification, bridging the gap between post-quantum security and Ethereum’s current infrastructure.\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Poqeth: Efficient, post-quantum signature verification on Ethereum\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Post quantum TXs in The Verge\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n post by JChanceHud on Jan 20, 2025\n\n JChanceHud\n\n Nice writeup, do you have an opinion on Falcon vs Crystals-Dilithium? Crystals is essentially Falcon without gaussian sampling. From an implementation perspective it’s much more simple with slightly larger keys/sigs.\nRe LaBRADOR signature aggregation: just want to mention the verification complexity is linear for these proofs (proof sizes are sublinear though).\n\n post by rdubois-crypto on Jan 21, 2025\n\n rdubois-crypto\n\n Gaussian sampling is the signer problem. The signature verifier implementation of FALCON is easy. In all aspects FALCON verifier is superior: time, bandwidth (3.5), key size. Having the signer handling the complexity is the natural choice. Like we do with ZK, signer has larger capacity than the verifier. https://s.itho.me/ccms_slides/2024/5/23/4414254e-124d-4bbd-8a41-579706b59401.pdf\n\n post by arikg on Jan 22, 2025\n\n arikg\n\n What are your thoughts about the candidates in the “Post-Quantum Cryptography: Additional Digital Signature Schemes”?\nI know that they did not publish results yet, but are you tracking any of the schemes in there as possible alternatives to Falcon?\nDo you see a reasonable chance that one of them gives you better overall tradeoffs and will become a leading alternative candidate?\n\n post by asanso on Jan 22, 2025\n\n asanso\n\n The good thing about using Account Abstraction is that it provides flexibility in the choice of the signature.\nI am, of course, following the ‘Post-Quantum Cryptography: Additional Digital Signature Schemes’ process, and some interesting signatures on my radar are Hawk, SQISign, and MAYO. But well, let’s see.\n\n post by mratsim on Jan 28, 2025\n\n mratsim\n\n Are there been reviews of SQSign suitability? https://sqisign.org/\nKey sizes are really small\n\nNIST round Ⅴ parameters, pubkey: 128 bytes, signatures:335 bytes\n\nI’m quite concerned about primitives in Falcon:\n\nsampling, having a good RNG is already a problem in cryptography, this was the whole reason of RFC6979 - Deterministic ECDSA as many many implementations had RNG/sampling bugs. On the Ethereum side ourselves, we spent a lot of time trying to get cryptographic shuffling right, see p19 and 20 of my 2019 talk\np191920×1080 186 KB\np202000×1125 165 KB\ndouble-precision: the non-determinism makes it very hard to prove in a SNARKS. Furthermore hardware accelerating it, if needed in the future for large aggregation for example, is painful as consumer GPUs issue fp64 instructions at 1/64 the fp32 rate see nvidia doc: CUDA C++ Programming Guide (Legacy) — CUDA C++ Programming Guide\n\n64 FP32 cores for single-precision arithmetic operations in devices of compute capability 8.0 and 128 FP32 cores in devices of compute capability 8.6, 8.7 and 8.9,\n32 FP64 cores for double-precision arithmetic operations in devices of compute capability 8.0 and 2 FP64 cores in devices of compute capability 8.6, 8.7 and 8.9\nCompute capability X.0 are datacenter cards (Tesla) while 8.6, 8.7, 8.9 are consumer GPUs, and consumer GPUs have 128 FP32 cores for 2 FP64 cores.\n\n post by CPerezz on Jan 28, 2025\n\n post by asanso on Jan 29, 2025\n\n post by asanso on Jan 29, 2025\n\n post by JChanceHud on Jan 30, 2025\n\n Powered by Discourse","tokens":2082,"squid":"ink-research","role":"Deep Scholar","at":1791262281687,"hash":"06e847286f6867f85704863843532130c92214bc"}
{"url":"https://governance.aave.com/t/aave-v4-hub-and-spoke-initial-configurations/24233","domain":"governance.aave.com","title":"Aave V4 Hub-and-Spoke Initial Configurations - Governance - Aave","text":"Aave V4 Hub-and-Spoke Initial Configurations \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 6\n min\n\n Hub-and-Spoke topologies discussed so far\n\n Model A: Monolithic Hub (V3-style core, V4 controls)\n\n Model B: Risk-profiled Hubs (separate venues, separate solvency)\n\n Model C: Asset-centric Hubs (venue boundary aligned to a domain)\n\n How V4 Infrastructure Composes These Models\n\n Spokes as Risk Expression\n\n Initial V4 Hub and Spoke Configuration Candidate\n\n Primary sources consolidated here\n\n Aave Labs explainers\n\n Official docs and repos\n\n Implementation status threads\n\n Mar 4\n\n 1 / 7\n\n Mar 4\n\n Mar 6\n\n post by AaveLabs on Mar 4\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n This post consolidates the Hub-and-Spoke configuration discussions that have already begun in recent V4 risk and design analyses posted to the governance forums, as well as conversations together between @Aave Labs, @TokenLogic, @ChaosLabs, and @LlamaRisk. The intent is to provide the DAO consolidated reference before the formal ratification prior to V4 deployment and activation. A candidate Hub and Spoke setup is presented to illustrate what an optimized configuration looks like before any selection proposal.\nHub-and-Spoke topologies discussed so far\nThere are three top-level architectural models. These are not mutually exclusive. They should be read as configuration families that can be mixed, with trade-offs that are easiest to reason about when stated as “what becomes the unit of risk.”\nModel A: Monolithic Hub (V3-style core, V4 controls)\nA single Hub concentrates liquidity, with multiple Spokes connecting to it. Spokes are bounded by per-spoke add caps and draw caps, while assets continue to share a single utilization curve and rate environment. New Spokes can attach to existing liquidity depth without requiring separate pool bootstrapping.\nThe trade-off is shared solvency. If a collateral listing performs worse than anticipated by its liquidation design, resulting bad debt is realized against the same Hub liquidity, regardless of which Spoke originated the position. As a result, collateral eligibility and conservative draw caps become the primary containment mechanisms. Risk premiums, dynamic risk configurations, and Spoke-level caps play a more prominent role because the topology itself does not introduce a hard solvency boundary.\nThis model maximizes liquidity depth and rate stability but requires conservative assumptions across the entire venue.\nModel B: Risk-profiled Hubs (separate venues, separate solvency)\nMultiple Hubs exist, each with its own liquidity pool and accounting. Losses in one Hub are intended to remain contained within that Hub.\nRates and liquidations become Hub-local. Utilization is measured per Hub, so smaller venues react faster to the same borrow and can have thinner liquidation depth. The main governance levers are Hub-level inventory and caps, including collateral eligibility, while add caps and draw caps prevent a higher-risk market from scaling into an implicit second core. In practice, supplying liquidity becomes an explicit choice of which solvency boundary a user is underwriting.\nThis model improves risk isolation but introduces liquidity fragmentation and bootstrapping considerations.\nModel C: Asset-centric Hubs (venue boundary aligned to a domain)\nA Hub is dedicated to a specific asset family or strategy domain. Collateral and borrowable sets are chosen to reflect that domain rather than mirror a general-purpose Core.\nWhere collateral shares correlated tails, liquidation thresholds and incentives must incorporate additional buffers. The same governance levers - eligibility, borrowable set, add caps, draw caps, and Hub-level pause rights - are applied to keep the venue containable without affecting the Core.\nThis model fits partner-driven or domain-specific markets that require a hard perimeter to scale. The primary trade-off is higher concentration of tail risk and increased operational complexity.\n\nFamily\nUnit of risk isolation\nLiquidity depth\nPrimary risk containment\nPrimary operational cost\n\nMonolithic Hub\nSpoke rules inside a shared balance sheet\nHighest\nPricing, caps, shared backstop assumptions\nConservative listings\n\nRisk-profiled Hubs\nHub boundary\nLower due to fragmentation\nHub-level segregation, hub-specific coverage\nBootstrapping multiple venues\n\nAsset-centric Hubs\nHub boundary aligned to domain\nLower, more concentrated\nCategory containment\nComplexity and concentrated tail-risk\n\nHow V4 Infrastructure Composes These Models\nAave V4 does not lock the DAO into a single Hub layout. Liquidity can remain concentrated in a Hub while different risk profiles are expressed through Spokes, and the isolation boundary can tighten over time because position rules and exposure routing are configurable.\nA market can begin as a Spoke inside a shared Hub, with containment enforced using familiar levers: collateral eligibility, borrowable set, oracle scope, liquidation thresholds and incentives, and per-asset add and draw caps.\nIf that segment grows to the point where shared solvency is no longer acceptable, it can move into its own Hub so the solvency boundary becomes structural. Any support from Core liquidity is then explicit via credit lines, with a credit line cap acting as the senior exposure limit. Raising the cap scales. Lowering it de-risks. Setting it to zero stops new draws.\nDynamic risk configurations make this manageable in production. Governance can tighten terms for new risk-taking without forcing immediate migration of legacy positions, and it can separate “stop growth” actions (caps) from “reduce leverage” actions (liquidation parameters).\nSpokes as Risk Expression\nIn the V4 analyses so far, Spokes are treated as the place where the DAO encodes borrowing intent. They let the protocol keep one liquidity venue per Hub while still separating behaviors that unwind differently under stress (general borrowing, ETH/BTC leverage lanes, stable-driven strategies, etc.). That separation is what makes caps, liquidation tuning, and oracle scope feel targeted instead of “one size fits all.” When the boundary needs to be harder than configuration alone, the separation moves up to the Hub level, and any cross-Hub support is made explicit via credit lines with a cap that governance can raise, lower, or set to zero.\nInitial V4 Hub and Spoke Configuration Candidate\nThis configuration reflects the common ground across the service provider inputs to date. It translates the risk and market-design feedback from @ChaosLabs, @LlamaRisk, and @TokenLogic into a Hub and Spoke setup that can be parameterized and operated in production. The table below defines the initial wiring. The rationale beneath it explains why this wiring was chosen, without implying a final recommendation.\n\nCore Hub\n\nSpoke\nCollateral\nBorrowable\n\nMain Spoke\nwETH, wstETH, weETH, wBTC, cbBTC, USDT, USDC, LINK, AAVE\nwBTC, cbBTC, wETH, USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC, cUSDE\n\nLido Spoke (e-Mode)\nwstETH\nwETH\n\nEtherFi Spoke (e-Mode)\nweETH\nwETH\n\nKelp Spoke (e-Mode)\nrsETH\nwETH\n\nLombard BTC Spoke (e-Mode)\nLBTC\nwBTC, cbBTC\n\nGold Spoke\nXAUt\nUSDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC\n\nForex Spoke\nUSDT, USDC, EURC\nUSDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC\n\nPrime Hub\n\nSpoke\nCollateral\nBorrowable\n\nBluechip Spoke\nwETH, wstETH, wBTC, cbBTC\nUSDT, USDC, GHO, cUSDT, cUSDC, cUSDG, cRLUSD, cEURC\n\nPlus Hub\n\nSpoke\nCollateral\nBorrowable\n\nEthena Ecosystem Spoke\nPT-sUSDe, PT-USDe, sUSDe, USDe\nUSDT, USDC, USDe, GHO, cUSDT, cUSDC, cfrxUSD, cRLUSD\n\nEthena Correlated Spoke\nPT-sUSDe, PT-USDe, sUSDe, USDe\nUSDe\n\nThe three-Hub layout is a solution to an observed operating constraint in V3. When every borrowing intent shares one solvency boundary, new growth areas compete for the same cap budget and force conservative defaults across the whole venue. Core remains the default rate environment and routing venue. Prime exists to serve suppliers who want a venue where their ETH/BTC is not borrowable. Plus exists so strategy-heavy stablecoin use can scale behind its own caps and pause conditions instead of pushing Core-wide limits that are set for general-purpose usage.\nCredit lines are used to make cross-venue exposure explicit and bounded. The most operationally significant credit line in this initial configuration runs from Core Hub to the Plus Hub’s Ethena Ecosystem Spoke. Rather than requiring Plus to bootstrap its own independent stablecoin supply at genesis, Core’s existing deep stablecoin pools are made available to Ethena borrowers via a governed credit line cap. This credit line is the principal mechanism enabling Ethena strategy growth within the Plus Hub. When Prime or Plus needs stablecoin depth without bootstrapping a separate stablecoin liquidity venue, the exposure is expressed as a credit line cap that governance can move up or down. In the tables, borrowables prefixed with “c” (e.g., cUSDT, cUSDC, cfrxUSD) refer to this routed inventory rather than a local supply market in that Hub. For instance, the Ethena Ecosystem Spoke specifically, cUSDT, cUSDC, cfrxUSD, and cRLUSD represent inventory drawn from Core Hub under a defined cap. However, these credit lines are not the only source of stablecoin liquidity in the spoke: users can also supply stablecoins directly into the Plus Hub’s Ethena Ecosystem Spoke. The credit line caps govern the ceiling on Core-routed inventory specifically, and sit alongside whatever direct supply the spoke attracts on its own. This means the total borrowable depth in the spoke reflects both organic direct supply and the governed credit line allocation from Core. Spoke-level draw caps then control how much of that routed inventory can be consumed. This keeps “support” measurable and reversible without merging solvency boundaries.\nSingle-asset e-Mode-like spokes are chosen to avoid coupling parameters across collateral types and to keep controls granular. A combined correlated lane inherits the weakest liquidity and oracle assumptions in the set and forces one cap posture across multiple assets. Splitting the lanes keeps LTV, liquidation bonus, oracle scope, and caps adjustable per collateral, and it makes it straightforward to clamp one asset without reshaping the rest of the ETH leverage flow.\nPrime’s non-borrowable collateral posture is designed around one operational promise: withdrawal availability and predictable behavior for suppliers. If collateral is borrowable, supplier experience is downstream of utilization and borrower demand. If collateral is not borrowable, supplier experience is dominated by the Hub’s own rules and the credit line limit governing any imported stablecoin inventory. Once isolated spokes are available, this configuration may be adapted in the future.\nStablecoin-only isolated spokes are deferred at genesis to keep the control surface small. They can improve collateral factors in narrow cases, but they add venues that each require their own caps, liquidation settings, oracle assumptions, monitoring, and pause decisions. The initial wiring prioritizes fewer moving parts, with the option to add stable-only lanes later if the incremental headroom is worth the operating load.\nThe separation between Ethena Ecosystem Spoke and Ethereum Correlated Spoke is primarily about isolating USDe borrowing to enable better parameters for that lane. Keeping them in separate spokes allows distinct draw caps, liquidation settings, oracle scope, and pause conditions to be applied independently, without constraints in one lane affecting the other.\nPrimary sources consolidated here\nHubs & Spokes in Aave V4: A Risk-Centric Analysis (@LlamaRisk): Hubs & Spokes in Aave V4: A Risk-Centric Analysis\nAave V4: New Features and Risk Parameter Analysis (@Chaos Labs): Aave v4: New Features and Risk Parameter Analysis\nAave V4: A Design Framework for Pooled and Isolated Bluechip Collateral Markets (@Chaos Labs): Aave v4: A Design Framework for Pooled and Isolated Bluechip Collateral Markets\nHubs & Spokes in Aave v4 (@TokenLogic): Hubs & Spokes in Aave v4\nAave Labs explainers\nUnderstanding Aave V4’s Architecture: Understanding Aave V4’s Architecture | Aave\nAave V4 Risk Premiums: Aave V4 Risk Premiums | Aave\nHow Aave V4 Handles Risk Isolation Without Fragmenting Liquidity: How Aave V4 Handles Risk Isolation Without Fragmenting Liquidity | Aave\nAave V4 Public Testnet and Code Release: Aave V4 Public Testnet and Code Release | Aave\nOfficial docs and repos\nAave V4 Documentation: https://aave.com/docs/aave-v4\nAave V4 Technical Documentation: https://github.com/aave/aave-v4/docs\nAave V4 Repo (core contracts): GitHub - aave/aave-v4: Aave V4 · GitHub\nAave V4 SDK: GitHub - aave/aave-v4-sdk: The official SDK for Aave V4 👻. · GitHub\nImplementation status threads\nAave V4: Testnet and Codebase are Live: Aave V4: Testnet and Codebase are Live\nAave V4 Development Update: Aave V4 Development Update\n\n Aave v4: Adoption Paths\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n 2\n\n read \n\n 6\n min\n\n post by simo on Mar 5\n\n simo\n\n Aave Labs-Technical SP\n\n Excited to see this finally come together.\nA huge thanks to @ChaosLabs, @LlamaRisk, and @TokenLogic.\nThis configuration is very much the product of all of our ongoing conversations, and it’s been a collaborative work over several months.\nOne thing I want to highlight.\nThis is an initial configuration, not a final one.\nThe three-Hub layout and the Spoke wiring presented here represent a reasonable starting point based on current risk inputs and liquidity conditions but V4 modular architecture is designed to evolve.\nAnd there’s already a lot of interest.\nThere are numerous assets currently in discussion, some looking to be listed on existing Spokes, others that warrant dedicated Spokes or even tailored Hub configurations. I expect the configuration to look meaningfully different 12 months post-launch, and that’s exactly the beauty of v4.\nWhat I’m most excited about is the granularity for risk management.\nDraw caps and credit lines change completely how we can express and bound risk exposure moving from blunt per-asset caps to a model where cross-venue liquidity support is explicit, measurable, and reversible. That’s a governance primitive we haven’t had before.\nAnd this means we can be more ambitious on the growth side precisely because the containment mechanisms are more precise.\n\n post by JosueMpia on Mar 5\n\n JosueMpia\n\nAgree here.\nTruly appreciate the effort it took @AaveLabs aggregating all the prior topics into a consolidated config, it’s a strong foundation to work from.\nThat said, I like the direction (Hub/Spoke + segmentation), but this feels closer to an aggressive go-to-market config than a minimum safe genesis config.\nAave v4 still need to prove itself. Doesn’t matter how many audits we did. It’s a completely new protocol. At launch the real risk isn’t only smart contract risk, it’s ops risk. Governance + monitoring + incident response are all part of it. This is what made Aave v3 the stronger in DeFi, i feel like we keep forgetting that. So IMO the disciplined move is: prove v4 mechanics with simple configs first, then layer in complexity over time.\nMy suggested launch config (Core + Prime is a good start only):\n\nLaunch Core + Prime Hubs, with the main spoke and maybe the Lido/EtherFi e-Mode spokes since those are well-understood collateral on proven infra. Conservative caps, keep it boring, keep the risk surface manageable.\n\nDefer Plus at genesis (or at least keep Core→Plus credit exposure effectively zero at the start). Ethena PT on day one is hard to justify on a risk-adjusted basis, similar exposure already exist in V3, and the incremental benefit of Plus isolation doesn’t outweigh stress-testing on day one, maybe after.\n\nDefer LBTC/Lombard for genesis. It adds bridge/custody risk on top of price risk, has thinner on-chain liquidity, and a shorter track record than ETH LSTs. So, I don’t think they belong in a safety first launch. Let’s revisit it once v4 has a clean risk/ops track record and we’re ready for the next collateral batch (Lombard, LP Collateral, vault-style collateral, debt trading or fixed rate included). I feel those deserve their own marketing and time after the initial config is strong.\n\nSlow and steady guys, slow and steady. Prove Hub/Spoke works without safety issues, then grow into it. That’s the more disciplined initial configuration.\nAnyway, great work pulling this together. I’ve also put together a 3 year adoption paths that builds on this very foundation, sharing for the community’s thoughts and brainstorming especially around v4 KPIs and what “success” should look like.\n\n post by stani on Mar 5\n\n stani\n\n Aave Labs-Technical SP\n\n Great work @ChaosLabs @LlamaRisk @TokenLogic and echoing that as initial configuration, it can be expanded down the line based on use-cases in line with governance proposals.\nMost important for the initial configuration and for the launch is to focus on security and safety first above anything else.\n\n post by ST0X on Mar 5\n\n ST0X\n\n 1- Lacks PAXG support, which is getting very popular after recent gold price surge. Suggest review and reconsider adding it.\n2- USDT is inherently more opaque comparing US stablecoin issuer - USDC, PYUSD,RLUSD. In general, USDT’s risk profile as a collateral shall not be overlooked. USDT is one of the three assets in Core Hub FX Spoke right now. A more innovative way of segregate USDT away from US stablecoin is appreciated for many LPs. Not everyone likes to have USDT exposures.\n\n post by stani on Mar 6\n\n stani\n\n Aave Labs-Technical SP\n\nGood point this could be reviewed for example post launch on a separate proposal\nUSDT is at this point probably most trusted stablecoin based on the sizing, however risk managers can take these into consideration during risk parametarization\n\n 1 month later\n\n Closed on Apr 5\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n Hubs & Spokes in Aave v4\n\n Governance\n\n 3\n\n 939\n\n Feb 16\n\n Hubs & Spokes in Aave V4: A Risk-Centric Analysis\n\n Risk\n\n 7\n\n 988\n\n Jan 26\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n Aave V4: Testnet and Codebase are Live\n\n Development\n\n 14\n\n 1.6k\n\n Feb 9","tokens":4608,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262288824,"hash":"ceca6ffb7061ad9a2a87f288af0942b1b34b5166"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/5","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 5 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n post by JChanceHud on Jan 20, 2025\n\n JChanceHud\n\n Nice writeup, do you have an opinion on Falcon vs Crystals-Dilithium? Crystals is essentially Falcon without gaussian sampling. From an implementation perspective it’s much more simple with slightly larger keys/sigs.\nRe LaBRADOR signature aggregation: just want to mention the verification complexity is linear for these proofs (proof sizes are sublinear though).\n\n post by rdubois-crypto on Jan 21, 2025\n\n rdubois-crypto\n\n Gaussian sampling is the signer problem. The signature verifier implementation of FALCON is easy. In all aspects FALCON verifier is superior: time, bandwidth (3.5), key size. Having the signer handling the complexity is the natural choice. Like we do with ZK, signer has larger capacity than the verifier. https://s.itho.me/ccms_slides/2024/5/23/4414254e-124d-4bbd-8a41-579706b59401.pdf\n\n post by arikg on Jan 22, 2025\n\n arikg\n\n What are your thoughts about the candidates in the “Post-Quantum Cryptography: Additional Digital Signature Schemes”?\nI know that they did not publish results yet, but are you tracking any of the schemes in there as possible alternatives to Falcon?\nDo you see a reasonable chance that one of them gives you better overall tradeoffs and will become a leading alternative candidate?\n\n post by asanso on Jan 22, 2025\n\n asanso\n\n The good thing about using Account Abstraction is that it provides flexibility in the choice of the signature.\nI am, of course, following the ‘Post-Quantum Cryptography: Additional Digital Signature Schemes’ process, and some interesting signatures on my radar are Hawk, SQISign, and MAYO. But well, let’s see.\n\n post by mratsim on Jan 28, 2025\n\n mratsim\n\n Are there been reviews of SQSign suitability? https://sqisign.org/\nKey sizes are really small\n\nNIST round Ⅴ parameters, pubkey: 128 bytes, signatures:335 bytes\n\nI’m quite concerned about primitives in Falcon:\n\nsampling, having a good RNG is already a problem in cryptography, this was the whole reason of RFC6979 - Deterministic ECDSA as many many implementations had RNG/sampling bugs. On the Ethereum side ourselves, we spent a lot of time trying to get cryptographic shuffling right, see p19 and 20 of my 2019 talk\np191920×1080 186 KB\np202000×1125 165 KB\ndouble-precision: the non-determinism makes it very hard to prove in a SNARKS. Furthermore hardware accelerating it, if needed in the future for large aggregation for example, is painful as consumer GPUs issue fp64 instructions at 1/64 the fp32 rate see nvidia doc: CUDA C++ Programming Guide (Legacy) — CUDA C++ Programming Guide\n\n64 FP32 cores for single-precision arithmetic operations in devices of compute capability 8.0 and 128 FP32 cores in devices of compute capability 8.6, 8.7 and 8.9,\n32 FP64 cores for double-precision arithmetic operations in devices of compute capability 8.0 and 2 FP64 cores in devices of compute capability 8.6, 8.7 and 8.9\nCompute capability X.0 are datacenter cards (Tesla) while 8.6, 8.7, 8.9 are consumer GPUs, and consumer GPUs have 128 FP32 cores for 2 FP64 cores.\n\n post by CPerezz on Jan 28, 2025\n\n post by asanso on Jan 29, 2025\n\n post by asanso on Jan 29, 2025\n\n post by JChanceHud on Jan 30, 2025\n\n Powered by Discourse","tokens":846,"squid":"ink-research","role":"Deep Scholar","at":1791262291974,"hash":"ae7748ded65e72527000884c2e213397329c7d13"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-v4-on-avalanche/25165","domain":"governance.aave.com","title":"[ARFC] Deploy Aave V4 on Avalanche - Governance / New Market - Aave","text":"[ARFC] Deploy Aave V4 on Avalanche \n\n GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n Jun 17\n\n 1 / 8\n\n Jun 17\n\n Jul 11\n\n post by AaveLabs on Jun 17\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Summary\nThis ARFC proposes deploying Aave Protocol V4 on Avalanche Network.\nMotivation\nAave V4’s next growth phase involves expanding into networks with existing DeFi demand, active Aave usage, and a credible path to protocol revenue. The initial deployment on Ethereum Mainnet validated the Hub and Spoke model in a production environment, making this expansion the logical next step for V4.\nAave Labs proposes deploying Aave V4 on Avalanche, beginning with one Liquidity Hub and three Spokes. A dedicated real-world asset (RWA) hub will be launched in a later phase.\nAvalanche has been a supported Aave V3 deployment since 2022, accumulating over five years of production operation. Its track record across liquidations, oracle performance, and market stress events within the Aave ecosystem establishes Avalanche as a proven network for Aave deployments. The existing market brings established distribution, active liquidity, and a mature user base, materially reducing execution risk for the activation of Aave V4 on Avalanche.\nFollowing the passing of the TEMP CHECK Snapshot, this ARFC sets out the proposed launch topology, asset scope, oracle configuration, incentive structure, and rollout path.\nIncentives Package\nThe Avalanche Foundation has committed up to $15,000,000 in milestone-based incentives tied to Hub launches and growth KPIs to bootstrap the V4 markets.\nSpecification\nThis section will be updated upon receiving feedback from various stakeholders in the lead-up to the deployment.\nHub and Spoke Configuration\nThe proposed initial Avalanche deployment will activate one Liquidity Hub and three Spokes; a Main Spoke, an AVAX Correlated Spoke, and a Forex Spoke.\n\nHub\nAssets\n\nAvalanche Core Hub\nwAVAX, sAVAX, BTC.b, USDC, USDT, wETH.e, EURC\n\nSpoke\nCollateral\nBorrowable\n\nMain Spoke\nWAVAX, BTC.b, USDC, USDT, wETH.e, EURC\nWAVAX, BTC.b, USDC, USDT, wETH.e, EURC\n\nAVAX Correlated Spoke\nsAVAX, WAVAX\nWAVAX\n\nForex Spoke\nEURC, USDC, USDT\nEURC, USDC, USDT\n\nDedicated RWA Hub: An RWA Hub is expected to be introduced through a follow-up proposal, with its own topology, asset scope, oracle configuration, and risk parameters, so that institutional collateral can be isolated from the core liquidity pool.\nRisk Parameters\nThe initial token listing and parameters will be updated based on the latest risk analyses.\nNext Steps\n\nGather community feedback and risk analysis from LlamaRisk\n\nEscalate the proposal to the ARFC Snapshot stage.\n\nIf the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.\n\nDisclaimer\nAave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche.\nAave Labs is presenting this proposal as a service provider to the Aave DAO as part of its approved scope of work in support of DAO operations.\nCopyright\nCopyright and related rights waived via CC0.\n\n 3\n\n 2\n\n read \n\n 5\n min\n\n post by LlamaRisk on Jun 17\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports Aave V4 deployment to Avalanche. This document consolidates the hub-and-spoke architecture configuration, liquidation parameters, collateral factors, interest rate model settings, and Add Cap/Draw Cap recommendations. The deployment will launch with a single Core Hub and three specialized spokes. The Core Hub will serve as the primary liquidity venue, while each spoke is designed for a specific use case.\nThe initial configuration adopts a conservative approach to cumulative Add Caps, reflecting the relatively limited liquidity available on Avalanche. This is particularly important given that the same assets are already listed on the Aave V3 deployment, where they operate with substantially higher caps and share the same underlying liquidity. The objective is to launch with prudent risk parameters and gradually increase caps as market adoption grows and liquidity conditions improve.\nMarket Design\nThe recommended launch configuration consists of one hub and three spokes. The Core Hub serves as the sole borrowing environment, structured around three spokes targeting a distinct collateral type, user intent, and risk profile:\nimage1280×785 67.8 KB\nSource: LlamaRisk\n\nMain Spoke: The Main Spoke is the general-purpose lending venue and is expected to host the majority of liquidity within the deployment. It accepts the broadest collateral set and the broadest borrowable set in the deployment, where WAVAX, BTC.b, USDC, USDT, and WETH.e are collateral against which users can borrow stablecoins, WAVAX, BTC.b, and WETH.e. In the future, the Main Spoke can provide credit lines to specialized Hubs, such as an RWA Hub, allowing them to access its liquidity while preserving separate risk profiles.\nAVAX Correlated Spoke: This spoke is dedicated to the AVAX LST looping environment, with sAVAX as collateral and WAVAX as the only borrowable asset. This design isolates looping risk and allows spoke-specific add/draw caps.\nForex Spoke: It supports trading and hedging across fiat-pegged stablecoins, with EURC, USDC, and USDT as collateral, which can be borrowed against each other. Due to limited secondary market liquidity for EURC, conservative caps have been set.\n\nIn addition to above three spokes a tokenized spoke will also be created which is a supply-only integration layer that tokenizes deposits of the Hub’s borrowable assets (WAVAX, BTC.b, USDC, USDT, WETH.e, and EURC) into composable positions for external vaults, aggregators, and strategies, without enabling borrowing or introducing additional collateral risk to the Core Hub.\nDynamic Liquidation Bonus Configuration\nV4 introduces a dynamic liquidation bonus that increases linearly as the health factor decreases, in contrast to V3’s static bonus. Two spoke-wide parameters shape the bonus curve. The targetHealthFactor is the HF to which a borrower is restored after liquidation; liquidators repay only enough debt to reach this value under normal circumstances. The healthFactorForMaxBonus is the HF at which the maximum liquidation bonus becomes active, with the bonus ramping linearly between HF of 1.0 and this value. The liquidationBonusFactor is a scaling parameter that controls both the steepness of the bonus ramp and, together with the target multiplier, the derived maxLiquidationBonus, ensuring that at an HF of 1.0, the liquidation bonus remains consistent with the corresponding V3 value.\nFor correlated-asset spokes (AVAX Correlated and Forex), liquidationBonusFactor is set to 1.0 because the health factor (HF) range between liquidation eligibility and bad debt is already narrow. Any reduction below this level would steepen the bonus curve and increase losses for leveraged correlated positions.\nFor volatile spokes (Main), healthFactorForMaxBonus is set to 0.9, ensuring that maximum liquidator incentives are active well before positions approach bad-debt levels. To maintain incentive continuity with V3, maxLiquidationBonus on the Main Spoke is set to 1.11 times its V3 value. This keeps the liquidation bonus at HF = 1.0 aligned with V3 while allowing higher incentives as positions deteriorate further.\n\nChain\nHub\nSpoke\nLiquidation Bonus Factor\nTarget Health Factor\nHealth Factor For Max Bonus\n\nAvalanche\nCore Hub\nMain Spoke\n90.00%\n1.2400\n0.90\n\nAvalanche\nCore Hub\nAVAX Correlated Spoke\n100.00%\n1.0350\n0.99\n\nAvalanche\nCore Hub\nForex Spoke\n100.00%\n1.0442\n0.99\n\nV4 Spoke Parameters\nThe liquidation protocol fee is proposed to be set at 10% across all assets, aligning with the configuration used for the majority of assets on Aave V3.\n\nChain\nHub\nSpoke\nReserve\nCollateral Factor\nMax Liquidation Bonus\nBorrowable\nCollateral Risk\nLiquidation Fee\n\nAvalanche\nCore Hub\nMain Spoke\nWAVAX\n73.00%\n10.00%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nMain Spoke\nBTC.b\n75.00%\n7.22%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nMain Spoke\nUSDC\n78.00%\n5.55%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nMain Spoke\nUSDT\n78.00%\n5.55%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nMain Spoke\nWETH.e\n83.00%\n5.55%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nMain Spoke\nEURC\n0.00%\n-\nTRUE\n-\n-\n\nAvalanche\nCore Hub\nAVAX Correlated Spoke\nsAVAX\n95.00%\n1.00%\nFALSE\n0\n10.00%\n\nAvalanche\nCore Hub\nAVAX Correlated Spoke\nWAVAX\n0.00%\n-\nTRUE\n-\n-\n\nAvalanche\nCore Hub\nForex Spoke\nEURC\n90.00%\n2.00%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nForex Spoke\nUSDC\n90.00%\n2.00%\nTRUE\n0\n10.00%\n\nAvalanche\nCore Hub\nForex Spoke\nUSDT\n90.00%\n2.00%\nTRUE\n0\n10.00%\n\nAdd and Draw Caps\nAdd and draw caps have been set, keeping in mind the limited liquidity available on Avalanche, with the specifications reflecting the hub-and-spoke structure of Aave V4 and the distinct risk profiles of each spoke.\n\nChain\nHub\nSpoke\nReserve\nAdd Cap\nDraw Cap\n\nAvalanche\nCore Hub\nMain Spoke\nWAVAX\n500,000\n50,000\n\nAvalanche\nCore Hub\nMain Spoke\nBTC.b\n100\n10\n\nAvalanche\nCore Hub\nMain Spoke\nUSDC\n5,000,000\n5,000,000\n\nAvalanche\nCore Hub\nMain Spoke\nUSDT\n5,000,000\n5,000,000\n\nAvalanche\nCore Hub\nMain Spoke\nWETH.e\n3,000\n300\n\nAvalanche\nCore Hub\nMain Spoke\nEURC\n500,000\n400,000\n\nAvalanche\nCore Hub\nAVAX Correlated Spoke\nsAVAX\n200,000\n0\n\nAvalanche\nCore Hub\nAVAX Correlated Spoke\nWAVAX\n0\n250,000\n\nAvalanche\nCore Hub\nForex Spoke\nEURC\n300,000\n400,000\n\nAvalanche\nCore Hub\nForex Spoke\nUSDC\n200,000\n150,000\n\nAvalanche\nCore Hub\nForex Spoke\nUSDT\n200,000\n150,000\n\nAvalanche\nCore Hub\nCore Tokenized WAVAX Spoke\nWAVAX\n150,000\n0\n\nAvalanche\nCore Hub\nCore Tokenized BTC.b Spoke\nBTC.b\n20\n0\n\nAvalanche\nCore Hub\nCore Tokenized USDC Spoke\nUSDC\n1,500,000\n0\n\nAvalanche\nCore Hub\nCore Tokenized USDT Spoke\nUSDT\n1,500,000\n0\n\nAvalanche\nCore Hub\nCore Tokenized WETH.e Spoke\nWETH.e\n600\n0\n\nAvalanche\nCore Hub\nCore Tokenized EURC Spoke\nEURC\n150,000\n0\n\nTokenized Spokes serve as the standard entry point for integrators, vaults, aggregators, and other strategies routing liquidity into Aave V4 markets. They are supply-only and accept deposits exclusively in each hub’s primary borrowable assets, ensuring a simple, composable tokenized representation.\nInterest Rate Curves\nThe IRM parameters apply to an asset across all spokes within that hub. The parameters follow the same two-slope utilization curve used in V3, defined by a base variable borrow rate, slope below the optimal usage ratio (Slope 1), slope above it (Slope 2), and the optimal usage ratio itself (Uoptimal). The Liquidity Fee is the fraction of borrower interest captured by the protocol treasury, equivalent to the reserve factor in V3. The goal of the initial configuration is to keep the setup as similar as possible to the one currently used in Aave V3.\n\nChain\nHub\nReserve\nBase\nSlope 1\nSlope 2\nUoptimal\nLiquidity Fee\n\nAvalanche\nCore Hub\nWAVAX\n1.00%\n4.00%\n144.28%\n65.00%\n20.00%\n\nAvalanche\nCore Hub\nBTC.b\n0.00%\n4.00%\n80.00%\n80.00%\n25.00%\n\nAvalanche\nCore Hub\nUSDC\n0.00%\n4.00%\n10.00%\n90.00%\n10.00%\n\nAvalanche\nCore Hub\nUSDT\n0.00%\n4.00%\n10.00%\n90.00%\n10.00%\n\nAvalanche\nCore Hub\nWETH.e\n0.00%\n2.50%\n8.00%\n90.00%\n15.00%\n\nAvalanche\nCore Hub\nEURC\n0.00%\n5.50%\n50.00%\n90.00%\n10.00%\n\nDisclosure\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n post by Mschmenk13 on Jun 22\n\n Mschmenk13\n\n Ava Labs and the Avalanche Foundation support the deployment of Aave v4 onto Avalanche. We truly believe that this launch will be mutually beneficial for all involved teams and will grow Aave and Avalanche, especially to a new set of users via the RWA Hub at a later date. The ability of v4 to have specialized hubs and spokes excites us regarding the modularity and customizability it provides. v4 will allow for longer tail and experimental assets to get listed onto Aave in a safe manner. It will also facilitate teams and curators to build unique and tailored hubs, almost acting as a protocol within a protocol. The new capabilities of Aave v4 and the RWA Hub empower vault teams to bring institutional strategies to retail users, and we think it will bring Aave to new heights, especially on Avalanche.\n\n 13 days later\n\n post by AaveLabs on Jul 6\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The ARFC to deploy Aave V4 on Avalanche has been raised to snapshot. Voting will begin in 24 hours. You may vote here\n\n post by Abel189 on Jul 8\n\n Abel189\n\n I support this proposal because it extends Aave V4 to a network with a proven operational history and an established DeFi ecosystem. Building on Avalanche’s existing Aave deployment reduces execution risk while allowing the new Hub and Spoke architecture to expand in a controlled and structured manner.\nI also appreciate the phased deployment strategy, the differentiated spoke design, and the conservative initial caps, which demonstrate a careful balance between growth and risk management. The commitment to introducing a dedicated RWA Hub through a separate governance process is another positive aspect, as it keeps different risk profiles appropriately isolated.\nAs adoption grows, it will be important to continuously review liquidity distribution, utilization, incentives, and market performance to ensure that the deployment remains sustainable and that governance can adjust parameters as real-world usage evolves.\n\n post by AaveLabs on Jul 10\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The AIP for this proposal was successfully created, proposal#504, voting will start in less than 24hs.\n\n post by MconnectDAO on Jul 10\n\n MconnectDAO\n\n I support this ARFC. Deploying Aave v4 on Avalanche builds on an existing, battle-tested Aave market and a mature DeFi ecosystem, while using the new hub-and-spoke architecture and conservative initial caps to scale in a risk-aware way. If the DAO pairs this phased rollout with regular reviews of liquidity distribution, utilization and incentive efficiency, Aave can capture significant new volume on Avalanche with controlled downside and clear optionality for the future RWA Hub.\n\n post by Abel189 on Jul 11\n\n Abel189\n\n I support the activation of Aave V4 on Avalanche. Building on an established Aave deployment while introducing the new Hub and Spoke architecture through a phased rollout represents a balanced approach to protocol expansion.\nI appreciate the use of differentiated spokes, conservative initial caps, and a governance model that includes a temporary hardening phase before transitioning fully to DAO control. This provides an appropriate balance between operational security and progressive decentralization during the early stages of deployment.\nAs the market matures, I believe governance should continue to monitor liquidity distribution, utilization patterns, liquidation performance, and user adoption to ensure that parameters evolve based on real-world data while preserving the protocol’s long-term resilience.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Sentora Externally Curated Hub & Spoke Framework on Aave V4\n\n New Market\n\n 5\n\n 767\n\n 8h","tokens":3911,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262299400,"hash":"07fa0e93464af6a460357008a0997311a85929dc"}
{"url":"https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512/4","domain":"ethresear.ch","title":"Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n Jan 2025\n\n 4 / 10\n\n Jan 2025\n\n Jan 2025\n\n post by asanso on Jan 20, 2025\n\n asanso\n\n This is Part 2 of a blog series exploring the feasibility of implementing a post-quantum signature scheme for Ethereum. In Part 1, we introduced the fundamental challenges and considerations involved in transitioning Ethereum to a quantum-resistant future. In this installment, we’ll dive deeper into Falcon, a promising post-quantum signature algorithm, examining its strengths, weaknesses, and the practical hurdles of integrating it into Ethereum’s transaction framework.\nFalcon Signature Scheme - Technical Overview\nFalcon (Fast-Fourier Lattice-based Compact Signatures over NTRU) builds upon the lattice-based signature framework of Gentry, Peikert, and Vaikuntanathan (GPV). It applies this framework to NTRU lattices and employs a “fast Fourier sampling” trapdoor sampler. The scheme relies on the Short Integer Solution (SIS) problem over NTRU lattices, which is considered computationally hard to solve in the general case, even with quantum computers, as no efficient solving algorithm is currently known.\nCore Components\nFalcon is based on the hash-and-sign paradigm and is an evolution of the traditional RSA signature scheme. However, instead of relying on number-theoretic problems, it leverages the hardness of lattice-based problems. Falcon’s security is based on the hardness of finding short vectors in NTRU lattices, leveraging Gaussian sampling techniques for generating trapdoor bases with reduced norms. This ensures efficient key generation and signing.\n\nKey Generation:\n\nGiven an NTRU polynomial ring ( \\mathbb{Z}[X] / (X^n + 1))(ℤ[𝑋]/(𝑋𝑛 +1)), a private key consists of two short polynomials ( f, g )(𝑓,𝑔) satisfying the NTRU equation.\nThe public key is derived as ( h = g / f )(ℎ =𝑔/𝑓) in the ring ( \\mathbb{Z}_q[X] / (X^n + 1) )(ℤ𝑞[𝑋]/(𝑋𝑛 +1)).\n\nSigning Process:\n\nA message is hashed into a challenge vector in the lattice domain.\nA short solution is sampled using fast Fourier sampling, ensuring a compact signature size while maintaining security against lattice reduction attacks.\nThe signature consists of the short lattice vector satisfying the challenge.\n\nVerification:\n\nThe verifier checks whether the signature satisfies the public key relation in the lattice ring.\nVerification involves computing norms and ensuring the validity of the lattice basis under modular arithmetic.\n\nFalcon is designed to offer a robust post-quantum signature solution, combining lattice-based cryptography with efficient sampling techniques. While its security benefits are clear, like any cryptographic system, it presents certain trade-offs in terms of complexity and implementation challenges. Now, let’s break down the highlights, potential pitfalls, and some of the more challenging aspects of Falcon.\nThe Good\nAside from the well-known benefits highlighted by NIST, such as Compact Signatures, Fast Operations (efficient key generation and verification via FFT techniques), and Security Proofs (relying on lattice reductions and worst-case hardness assumptions). Falcon also provides Ethereum-specific advantages. Notably, it has a well-defined worst-case running time, making it particularly useful for the Ethereum Virtual Machine (EVM), where predictable performance and execution times are essential for scalability and reliability.\nThe Bad\nFalcon’s reliance on floating-point arithmetic and specialized number-theoretic transforms (NTT/FFT) can lead to implementation complexity and sensitivity to side-channel vulnerabilities during signing. However, this is NOT a significant concern for Ethereum, as signing occurs off-chain, where performance is less critical. The main focus is on optimizing the verification process, which happens on-chain, ensuring efficient and secure execution.\nThe Gnarly\nThere has been ongoing research into efficiently aggregating Falcon signatures, such as the work presented in this paper. Assuming the aggregation will be efficient enough, using Falcon in the consensus layer to replace the BLS signature (instead of the alternative proposal based on Hash-Based Multi-Signatures) would help maintain a more homogeneous stack across the Ethereum network.\nConclusion\nFalcon is a strong candidate for post-quantum cryptography applications, including blockchain systems like Ethereum, where signature size and verification efficiency are critical. In Part 3 of the series, we will begin implementing the hybrid approach introduced in Part 1, initially focusing on Account Abstraction and a Solidity contract for Falcon verification, bridging the gap between post-quantum security and Ethereum’s current infrastructure.\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n Poqeth: Efficient, post-quantum signature verification on Ethereum\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction\n\n Post quantum TXs in The Verge\n\n 4\n\n 2\n\n read \n\n 5\n min\n\n post by JChanceHud on Jan 20, 2025\n\n JChanceHud\n\n Nice writeup, do you have an opinion on Falcon vs Crystals-Dilithium? Crystals is essentially Falcon without gaussian sampling. From an implementation perspective it’s much more simple with slightly larger keys/sigs.\nRe LaBRADOR signature aggregation: just want to mention the verification complexity is linear for these proofs (proof sizes are sublinear though).\n\n post by rdubois-crypto on Jan 21, 2025\n\n rdubois-crypto\n\n Gaussian sampling is the signer problem. The signature verifier implementation of FALCON is easy. In all aspects FALCON verifier is superior: time, bandwidth (3.5), key size. Having the signer handling the complexity is the natural choice. Like we do with ZK, signer has larger capacity than the verifier. https://s.itho.me/ccms_slides/2024/5/23/4414254e-124d-4bbd-8a41-579706b59401.pdf\n\n post by arikg on Jan 22, 2025\n\n arikg\n\n What are your thoughts about the candidates in the “Post-Quantum Cryptography: Additional Digital Signature Schemes”?\nI know that they did not publish results yet, but are you tracking any of the schemes in there as possible alternatives to Falcon?\nDo you see a reasonable chance that one of them gives you better overall tradeoffs and will become a leading alternative candidate?\n\n post by asanso on Jan 22, 2025\n\n asanso\n\n The good thing about using Account Abstraction is that it provides flexibility in the choice of the signature.\nI am, of course, following the ‘Post-Quantum Cryptography: Additional Digital Signature Schemes’ process, and some interesting signatures on my radar are Hawk, SQISign, and MAYO. But well, let’s see.\n\n post by mratsim on Jan 28, 2025\n\n mratsim\n\n Are there been reviews of SQSign suitability? https://sqisign.org/\nKey sizes are really small\n\nNIST round Ⅴ parameters, pubkey: 128 bytes, signatures:335 bytes\n\nI’m quite concerned about primitives in Falcon:\n\nsampling, having a good RNG is already a problem in cryptography, this was the whole reason of RFC6979 - Deterministic ECDSA as many many implementations had RNG/sampling bugs. On the Ethereum side ourselves, we spent a lot of time trying to get cryptographic shuffling right, see p19 and 20 of my 2019 talk\np191920×1080 186 KB\np202000×1125 165 KB\ndouble-precision: the non-determinism makes it very hard to prove in a SNARKS. Furthermore hardware accelerating it, if needed in the future for large aggregation for example, is painful as consumer GPUs issue fp64 instructions at 1/64 the fp32 rate see nvidia doc: CUDA C++ Programming Guide (Legacy) — CUDA C++ Programming Guide\n\n64 FP32 cores for single-precision arithmetic operations in devices of compute capability 8.0 and 128 FP32 cores in devices of compute capability 8.6, 8.7 and 8.9,\n32 FP64 cores for double-precision arithmetic operations in devices of compute capability 8.0 and 2 FP64 cores in devices of compute capability 8.6, 8.7 and 8.9\nCompute capability X.0 are datacenter cards (Tesla) while 8.6, 8.7, 8.9 are consumer GPUs, and consumer GPUs have 128 FP32 cores for 2 FP64 cores.\n\n post by CPerezz on Jan 28, 2025\n\n post by asanso on Jan 29, 2025\n\n post by asanso on Jan 29, 2025\n\n post by JChanceHud on Jan 30, 2025\n\n Powered by Discourse","tokens":2082,"squid":"ink-research","role":"Deep Scholar","at":1791262302231,"hash":"442c6b5529867da86aff00e594cb28099c7a7945"}
{"url":"https://ethresear.ch/t/so-you-wanna-post-quantum-ethereum-transaction-signature/21291/1","domain":"ethresear.ch","title":"So you wanna Post-Quantum Ethereum transaction signature - Cryptography - Ethereum Research","text":"So you wanna Post-Quantum Ethereum transaction signature \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2024\n\n 1 / 28\n\n Dec 2024\n\n May 26\n\n post by asanso on Dec 18, 2024\n\n asanso\n\n So you wanna Post-Quantum Ethereum transaction signature\nThanks to Vitalik Buterin, Justin Drake, Renaud Dubois, Marius Van Der Wijden and Zhenfei Zhang for fruitfull discussions.\nIntroduction\n2024 will probably be remembered as one of the years marking the acceleration of the quantum computer menace. Google, under its CEO Sundar Pichai, finally unveiled its quantum chip, Willow, via a loud tweet!\nScott Aaronson, one of the most famous quantum experts in the world, has changed his message to people asking whether they should be worried about quantum computers. He shifted from saying\n\n… Maybe, eventually, someone will need to start thinking about migrating from RSA, Diffie-Hellman, and elliptic curve cryptography to lattice-based crypto or other systems that could plausibly withstand quantum attacks,…\n\nto\n\nYes, unequivocally, worry about this now. Have a plan.’\n\nVitalik has already written about how to hard-fork to save most users’ funds in a quantum emergency. Also, few days ago, he highlighted in a podcast the four main Ethereum components potentially vulnerable to quantum attacks. They are:\n\nEthereum transaction signatures (notably using ECDSA)\nBLS signatures in consensus\nData Availability Sampling (leveraging KZG commitments)\nVerkle trees (if shipped with Bandersnatch)\n\nAn attentive reader might have noticed that these four points have something in common—yes, it’s my beloved elliptic curves. Unfortunately, the discrete logarithm problem for elliptic curves (ECDLP) is broken by Shor’s Algorithm, a famous quantum algorithm.\nIn this short note, we are going to analyze a possible post-quantum replacement for the first point, namely a potential post-quantum Ethereum transaction signature.\nWhich PQ signature?\nNow, a legitimate question is: which post-quantum (PQ) signatures should we use? Fortunately, we don’t need to overthink this too much if we had to choose right now. Zhenfei Zhang, a former Ethereum Foundation cryptographer, has already written about the NIST Post-Quantum Cryptography Standardization Process. If we analyze the three possible signature choices (two of which leverage lattice-based cryptography), it’s clear (at least for now) that Falcon appears to be the most promising candidate. The computation for the verifier should be roughly the same as other lattice-based signature schemes (like Dilithium), i.e., bounded by an FFT. However, Falcon does have a smaller signature size.\nShip it!!!\nNow that we’ve ‘settled’ on the signature to use, the next question is: how are we going to ship it? There is a big dichotomy now: one implies a hard fork, and the other doesn’t. Let’s dig a bit deeper.\nThe Account Abstraction way\nThe first approach we will discuss, arguably the most elegant and promising, involves Account Abstraction (AA). It has been advocated by Justin Drake and Vitalik on various occasions.\nFor people not familiar with it, AA is a proposed improvement to make the Ethereum ecosystem more flexible and user-friendly by changing how transactions and accounts are managed. It shifts certain functionalities traditionally reserved for externally owned accounts (EOAs) into smart contracts, effectively “abstracting” the differences between EOAs and smart contract accounts.\nEthereum developers have introduced various proposals for implementing AA, including ERC-4337. This is a practical solution that achieves AA without requiring a consensus-layer upgrade. It uses a mechanism called User Operation objects and introduces a separate Bundler layer to handle transactions.\nAdding Falcon as the Ethereum transaction signature in this scenario means coding a Falcon verifier contract that is responsible for verifying the validity of User Operation objects before they are executed by the Entry Point contract.\nNow, this may sound like all sunshine and rainbows, but there is at least one substantial underlying issue. Coding Falcon in Solidity might not be the best experience (and it’s probably quite gas-costly). On top of that, there are even nastier problems, such as the fact that Falcon deals with 13-bit numbers, while Solidity only supports U256. The latter is the kind of issue that could be addressed by adding SIMD and EVMMAX to the EVM.\n\nPros: It is an elegant and flexible solution.\nCons: It is costly in terms of gas consumption.\n\nThe hard fork way\nThe method we discuss here is probably the simplest technically. It is inspired by previous work done by Marius Van Der Wijden and essentially involves introducing a new transaction type signed with Falcon signatures instead of BLS signatures. The biggest problem here is that, by doing so, we are tightly bound (through a new EIP) to a favored master signature scheme.\nSo, to recap this approach\n\nPros: Easy to code and fast.\nCons: Not future-proof.\n\nHybrid\nA really tempting approach would be to take the best of the two methods above and combine them into a single one. In a nutshell, we could leverage AA in a similar way that RIP-7212 does, but of course, we would need a new RIP for Falcon. This might provide the time to experiment with the feature in rollups and determine if Falcon is truly the way to go. However, it is important to note that this approach does not solve the original problem of introducing a new signature scheme at the L1 level.\n\nPros: Easy to code and fast.\nCons: Temporary (does not solve the L1 use case).\n\nConclusion\nThe rise of quantum computing demands urgent action to secure Ethereum, particularly its transaction signatures vulnerable to Shor’s Algorithm. Falcon, a lattice-based signature scheme, emerges as a strong candidate due to its efficiency and compact size. Deployment strategies, including Account Abstraction, hard forks, or a hybrid approach, each offer distinct benefits and trade-offs. A careful evaluation is essential to ensure Ethereum remains robust against quantum threats while maintaining scalability and usability.\n\n Falcon as an Ethereum Transaction Signature: The Good, the Bad, and the Gnarly\n\n The road to Post-Quantum Ethereum transaction is paved with Account Abstraction (AA)\n\n NTT as PostQuantum and Starks settlements helper precompile\n\n Revisiting Falcon signature aggregation for PQ mempools\n\n What if post-quantum Ethereum doesn’t need signatures at all?\n\n 5\n\n 5\n\n 3\n\n 3\n\n 2\n\n read \n\n 9\n min\n\n post by FabrizioRomanoGenove on Dec 18, 2024\n\n post by ihagopian on Dec 18, 2024\n\n post by zincoshine on Dec 18, 2024\n\n post by asanso on Dec 18, 2024\n\n post by rdubois-crypto on Dec 18, 2024\n\n post by asanso on Dec 18, 2024\n\n post by pldd on Dec 18, 2024\n\n post by p_m on Dec 18, 2024\n\n post by asanso on Dec 19, 2024\n\n post by CPerezz on Dec 19, 2024\n\n post by rdubois-crypto on Dec 19, 2024\n\n post by cryptskii on Dec 22, 2024\n\n 16 days later\n\n post by jeroenvdgraaf on Jan 8, 2025\n\n post by JChanceHud on Jan 12, 2025\n\n post by seresistvanandras on Jan 13, 2025\n\n 15 days later\n\n post by CPerezz on Jan 28, 2025\n\n post by asanso on Jan 29, 2025\n\n post by CPerezz on Jan 29, 2025\n\n 19 days later\n\n post by rdubois-crypto on Feb 18, 2025\n\n Load more posts below","tokens":1819,"squid":"ink-research","role":"Deep Scholar","at":1791262313003,"hash":"367623f418b426056df2104cf91342e7dac200fb"}
{"url":"https://governance.aave.com/t/arfc-umbrella-on-aave-v4-coverage-framework-and-initial-market-parametrization/25623","domain":"governance.aave.com","title":"[ARFC] Umbrella on Aave v4: Coverage Framework and Initial Market Parametrization - Governance - Aave","text":"[ARFC] Umbrella on Aave v4: Coverage Framework and Initial Market Parametrization \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Overview\n\n Framework for Umbrella Coverage on V4\n\n Deficit Handling on v4\n\n State of Aave v4\n\n Risk Profile of v4 Reserves\n\n WETH\n\n USDC\n\n USDT\n\n USDG\n\n frxUSD\n\n Recommendation\n\n Specification\n\n Next Steps\n\n Disclaimer\n\n Copyright\n\n Sep 11\n\n 1 / 2\n\n Sep 10\n\n Sep 12\n\n post by TokenLogic on Sep 11\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Overview\nAave v4 on Ethereum has grown rapidly since launch, with borrowing now concentrated in WETH, USDG, USDC, USDT, and frxUSD. This analysis evaluates these markets under the V4 Umbrella framework, considering loan size, collateral and borrower risk, supplier concentration, market durability, and reserve economics.\nWe recommend establishing general purpose Umbrella markets for Core WETH, Core USDC, and Core USDT. These markets combine meaningful loan books with strong collateral and relatively conservative borrower profiles, while providing sufficient supplier depth to support independent underwriting. The remaining markets do not currently present a sufficiently strong use case for general purpose coverage, either because credit risk is too limited to justify the incremental protection, supplier bases are too concentrated to support independent underwriting, or market activity remains heavily incentive dependent. As these markets establish themselves and develop broader, more diversified LP bases, their suitability for Umbrella coverage can be reassessed.\nThe proposed parameters are forward looking, incorporating expected loan growth over the next six to eight weeks. Target liquidity and deficit offsets are sized against projected exposure and reserve economics, while emissions are determined by the opportunity cost of independent underwriting.\nFramework for Umbrella Coverage on V4\nThe V4 coverage framework retains the v3 assessment of loan size, collateral quality, borrower equity, liquidation capacity, deficit offsets, and underwriter opportunity cost. The V4 configuration adds two considerations that are particularly relevant to Umbrella: the mapping between the Spoke originating the risk and the Hub asset bearing the resulting deficit, and whether that risk can be transferred to an independent underwriter base.\nThe assessment therefore considers two questions.\n\nHow much risk requires protection? The active loan book provides the primary measure of exposure, but coverage needs must be assessed alongside collateral quality and composition, borrower equity, liquidation capacity, and the protections already available through Deficit Offsets. These factors determine the potential loss that Umbrella would ultimately be required to absorb.\nCan Umbrella transfer that risk efficiently? An Umbrella market requires an independent supplier base willing to underwrite the covered risk. Supplier composition therefore matters alongside the underlying credit profile.\n\nDeficit Offsets form the first loss layer before Umbrella coverage. Their sizing should therefore be considered alongside the risk transferred to underwriters and the revenue the reserve generates. This links the DAO’s first-loss contribution to market economics while keeping the overall protection structure proportional to the covered risk.\nUnderwriter opportunity cost determines the emissions required to attract that independent capital. Supply APY plus emission APY must meet or exceed comparable alternative yield plus a risk premium for slashing risk and lockup. Emissions should therefore reflect both the return available elsewhere and the risk underwriters accept by providing coverage.\nEvery debt position originates inside exactly one Spoke and is secured only by that Spoke’s collateral. However, Spokes can access liquidity from Hubs other than the Hub that holds their collateral through draw-only credit lines. The resulting debt is still a liability of the borrowing Spoke, but the deficit risk ultimately sits with suppliers of the Hub asset that was drawn. General purpose coverage at the (Hub, asset) level must therefore cover all borrowing from that reserve, including credit line draws by Spokes native to other Hubs, while assessing the distinct collateral and risk profile of each originating Spoke.\nPer Spoke attribution also permits narrower, issuer-funded coverage, where an asset issuer or strategy operator can underwrite the risk associated with its own Spoke. This analysis focuses on the general purpose of Umbrella markets, where an independent supplier base funds coverage and covers deficits attributed to Spokes borrowing the covered Hub asset.\nBecause Aave v4 markets are still developing, supplier composition should not be treated as static. Early markets may be seeded by issuers, partners, or other strategic liquidity providers before attracting a broader LP base. As markets mature and supplier bases diversify, reassess the suitability of Umbrella coverage.\nDeficit Handling on v4\nOn v4, when a liquidation leaves an account with all collateral seized and debt remaining, the Spoke calls reportDeficit on the relevant Hub in the same transaction. Any permissionless liquidator executing liquidationCall can therefore trigger deficit recognition without requiring a keeper, administrator, or governance action. The report covers each remaining debt reserve, with each deficit reported to the Hub from which the reserve was drawn, and clears the user’s position.\nThe Hub records the resulting shortfall on two ledgers. The per asset ledger, asset.deficitRay, measures the deficit attributable to that Hub asset and therefore the loss borne by its suppliers. The per Spoke ledger, spoke.deficitRay, identifies the Spoke that originated the deficit. Both are publicly readable through getAssetDeficitRay and getSpokeDeficitRay. This separation lets you assess each deficit from both the affected Hub asset’s perspective and the Spoke that generated it.\nimage2400×1072 142 KB\nDeficit elimination is a separate operation. eliminateDeficit(assetId, amount, spoke) clears a specific Spoke’s deficit, and the caller must be a registered and active Spoke for that Hub asset with sufficient supplied shares. Elimination burns the caller’s own supplied Hub shares rather than transferring tokens into the Hub. Umbrella capital therefore remains productive supply in the Hub, earning supply yield, until it is used to eliminate a deficit.\nThese mechanics have two implications for Umbrella design.\n\nCoverage and Deficit Offsets are defined per (Hub, asset), meaning capital committed to one Hub asset cannot clear a deficit in another.\nPer Spoke attribution allows coverage to be scoped to a specific Spoke, providing the basis for issuer funded Umbrella markets.\n\nState of Aave v4\nAave V4 replaces V3’s monolithic pool design with a modular architecture built from two components: Hubs, which hold liquidity, and Spokes, which create debt. A Spoke’s debt can only be secured by collateral held within that same Spoke, making the Spoke the unit of debt origination and deficit attribution in V4. However, the resulting deficit is recorded against the Hub asset from which the debt was drawn, making the Hub asset the relevant unit for assessing supplier exposure and general purpose Umbrella coverage.\nimage2352×1350 211 KB\nOn Ethereum, the DAO currently operates four Hubs serving twelve borrowing Spokes. Several Spokes draw the same asset from more than one Hub. The Bluechip Spoke, for example, borrows USDC from both Core and Prime. Each Hub asset therefore carries the deficit risk associated with every Spoke drawing that asset from that Hub.\nAave V4 on Ethereum has compounded steadily since its April 2026 launch. Deposits stand at ~$596M and active loans at ~$226M, with the loan book doubling roughly every six weeks, a pace sustained for five months. v4 now represents ~2.1% of combined v3 + v4 borrows on Ethereum.\nimage1920×1080 109 KB\nimage1920×1080 93.4 KB\nBorrowing is concentrated in five assets: WETH ($79.3M), USDG ($79.2M), USDC ($26M), USDT ($21M), and frxUSD ($20M), with everything else below $1M combined.\nimage1920×1080 127 KB\nLiquidity sourcing differs from debt origination. Of the $177M drawn from Core, roughly $36.3M is originated in Spokes whose collateral sits in other Hubs: Bluechip Spoke, Global Dollar Spokes, and Ethena Spokes. These Spokes reach Core through draw only credit lines. Core suppliers bear the deficit risk associated with the full $177M of Core borrowing, regardless of where the underlying collateral is held.\nimage1920×1080 105 KB\nProtection sizing must account for the incentive campaigns that shape supply and borrowing. Supply side campaigns incentivize deposits of USDG and frxUSD, inflating supply. They also help explain the concentrated supplier bases examined in the next section. USDC and WETH are subject to the opposite type of incentive program, with rewards directed toward borrowing. A portion of the USDC and WETH loan books may therefore represent incentive sensitive demand that could unwind when the campaigns end. Umbrella parameters set against incentive boosted books should anticipate the risk of contraction when campaigns end.\nRisk Profile of v4 Reserves\nEach V4 Reserve’s risk profile depends on its loan book, collateral quality, borrower equity, borrower concentration, and available independent underwriting capacity. The following sections assess these factors for WETH, USDC, USDT, USDG, and frxUSD.\nWETH\nCore WETH has 31,677 ETH (~$79.3M) in outstanding debt. WETH is borrowable only from the Core Hub, so the entire WETH loan book and any deficit it produces sit with Core suppliers. Growth has been steady since launch, and at the current pace the loan book is expected to double in six weeks.\nimage1920×1080 119 KB\nCollateral composition\nWETH is borrowable against weETH in the Etherfi Spoke and wstETH in the Lido Spoke, while the rsETH route in the Kelp Spoke is frozen and limited to existing positions. The Etherfi exposure accounts for about 96% of total WETH debt and is driven primarily by its leveraged weETH strategy. This concentration is reinforced by the current borrowing incentive, which makes ETH borrowing cheaper when weETH is supplied as collateral, supporting demand for leveraged weETH positions. WETH borrowing is also enabled in the Main Spoke, where it is used primarily for shorting, but this represents less than 1% of total WETH borrowing activity. As a result, a single leveraged strategy largely drives the current WETH debt profile, with borrowing incentives partly supporting its scale.\nimage1920×1080 118 KB\nSupplier concentration\nCore WETH has a sufficiently broad supplier base to support an Umbrella market, with approximately $86.9M of supply distributed across 826 suppliers with balances of at least $10. Because most Umbrella underwriters come from the supplier base of the relevant (Hub, asset) market, both the size and distribution of WETH suppliers are key determinants of available underwriting capacity. The current breadth of the supplier base provides a meaningful pool from which to attract independent underwriters.\nThe chart shows the transition from a seeded base towards a more diversified market. Concentration has declined every month since, and the supplier count has grown roughly linearly since launch. This trajectory supports the framework: early supplier bases are seeded, then diversify as markets mature.\nimage1920×1080 135 KB\nRevenue\nCore WETH earns annualized borrow interest revenue of 88.4 ETH (~$221k), measured over the trailing 30 days.\nimage1920×1080 148 KB\nAt the current growth trajectory, annualized revenue is expected to increase to approximately 222 ETH over the next six to eight weeks. This reflects the expected growth in the loan book over the period, together with the current borrowing rate structure.\nReserve revenue is one of the inputs used to determine the appropriate level of DAO funded first loss deficit coverage.\nUSDC\nUSDC is listed on all four hubs, with $26.3M borrowed. Core is the largest market at $13.6M, followed by Prime at $7.1M, Global Dollar at $3.1M and Plus at $2.6M.\nOf Core’s borrowed USDC, $4.0M (30%) is drawn through credit lines by Spokes native to other hubs. The Bluechip Spoke accounts for $3.66M of these draws, with collateral held in Prime, while the Ethena Ecosystem Spoke draws $0.37M, with collateral held in Plus. Although Core suppliers bear the deficit risk for these positions, the majority of the credit line exposure is extended to the Bluechip Spoke, which has a comparatively lower risk profile. This concentration toward a lower risk Spoke further reduces the overall credit risk of the Core USDC market.\nimage1920×1080 117 KB\nCollateral composition\nThe Core USDC market combines substantial collateral coverage with a relatively diversified borrower profile across the v4 books. Approximately $39.5M of collateral supports $13.6M of debt, resulting in roughly 2.9x collateralization, while pristine collateral accounts for 87.1% of the pool. Only 4.3% of outstanding debt is associated with positions below a 1.1 health factor, indicating limited near term liquidation exposure. Borrowing is also relatively dispersed, with the five largest borrowers accounting for just 34.3% of total debt. Taken together, the strong collateral coverage, high share of pristine collateral, and diversified borrower base indicate a comparatively low credit risk profile for Core USDC.\nimage1920×1080 146 KB\nThe Prime USDC market has $18.9M of exclusively pristine collateral backing $7.1M of debt through Bluechip, providing approximately 2.7x collateralization. The collateral consists of WBTC (65%), wstETH (21%), cbBTC (7%), and WETH (7%), with none of the collateral being rehypothecated. Given the quality and composition of the collateral, the absence of rehypothecation, and the strong collateral buffer, Prime USDC presents limited credit risk. It therefore does not require Umbrella coverage under the framework.\nThe Global Dollar USDC and Plus USDC markets have more limited collateral distributions and substantially smaller equity buffers. Global Dollar has $3.5M of collateral backing $3.1M of debt, equivalent to approximately 1.14x collateralization, with syrupUSDG accounting for 79% and PT USDG for 21% of collateral. 86% of the debt is associated with positions below a 1.1 health factor.\nThe Plus USDC market has $2.9M of collateral backing $2.6M of debt, also approximately 1.14x collateralized, with sUSDe accounting for roughly 99% of collateral and effectively the entire debt book below a 1.1 health factor. Both markets therefore have limited collateral diversification and relatively small equity buffers.\nSupplier concentration\nThe Core USDC market has the most diversified supplier base in v4. The largest LP holds 6.7% and the top five hold 24.2%.\nFor the framework, that breadth supports a more meaningful distinction between parties supplying liquidity and parties potentially absorbing deficits.\nimage1920×1080 143 KB\nThe other USDC hubs have narrower supplier bases. Prime has 67 suppliers, with the five largest accounting for 79.7% of its $7.75M supply. Global Dollar has only two suppliers, collectively providing the full $5.1M, while a single supplier accounts for the entire $3.0M supplied to Plus. These supplier bases are currently too narrow to establish a sufficiently independent pool of underwriters. Allowing these markets to grow and diversify their supplier bases before introducing Umbrella coverage would provide a broader pool from which to attract independent underwriters.\nRevenue\nThe Core USDC market generated approximately 49,000 USDC in annualized borrow interest based on the trailing 30 days.\nAt unchanged rates, annualized revenue is expected to increase to approximately 100,000 USDC as the loan book grows over the next 6 to 8 weeks.\nUSDT\nUSDT is listed on Core, Prime, Plus and Global Dollar, with ~$20.6M borrowed. Core is the largest market at $15.6M, followed by Prime and Plus at $2.5M each, while Global Dollar carries a negligible $0.04M book. Of Core’s $15.6M, ~$11.0M is borrowed through Core native Spokes. A further $4.6M (30%) is borrowed through credit lines by Bluechip at $4.24M, and Ethena Ecosystem at $0.38M. Although Core suppliers bear the deficit risk, most credit line exposure goes to the comparatively lower risk Bluechip Spoke.\nimage1920×1080 119 KB\nCollateral composition\nThe Core USDT market has $15.6M of outstanding debt backed by approximately $42.1M of collateral, providing roughly 2.7x collateralization. Pristine assets account for 86.5% of the collateral pool. WETH represents 37% of collateral, followed by WBTC at 27%.\nOnly 2.5% of outstanding debt is associated with positions below a 1.1 health factor, indicating limited near term liquidation exposure. The five largest borrowers account for 30.1% of total debt, reflecting a relatively diversified borrower base. Alongside Core USDC, Core USDT therefore has one of the more conservative borrower profiles across v4. Combined with its strong collateral coverage and high share of pristine assets, the relatively low health factor exposure and borrower concentration point to a comparatively low credit risk profile.\nimage1920×1080 154 KB\nThe Prime USDT market has $2.5M of debt backed by $5.3M of exclusively pristine non rehypothecated collateral through the Bluechip Spoke, providing approximately 2.1x collateralization. Overall, the strong collateral buffer, high collateral quality, and conservative borrower profile point to comparatively low credit risk.\nThe Plus USDT market has $2.9M of collateral backing $2.5M of debt, providing approximately 1.18x collateralization. The collateral is overwhelmingly concentrated in sUSDe, which accounts for approximately 96% of the collateral, while 92.5% of outstanding debt is associated with positions below a 1.1 health factor. This indicates a comparatively thin collateral buffer.\nSupplier concentration\nThe Core USDT market has 170 suppliers providing $16.9M in liquidity. The largest supplier accounts for 34.4% of supply, while the top five and top twenty account for 73.5% and 93.4%, respectively. This is materially more concentrated than Core USDC and provides a weaker basis for attracting independent underwriters, despite the market’s conservative borrower profile.\nimage1920×1080 140 KB\nThe Prime USDT market has 18 suppliers, with the top five accounting for 97.7% of its $2.8M in supply, while a single supplier provides the entire $3.0M supplier base for Plus. These supplier bases are currently too narrow to establish a sufficiently independent pool of underwriters. Allowing both markets to grow and diversify their supplier bases before introducing Umbrella coverage would provide a broader pool from which to attract independent underwriters.\nRevenue\nThe Core USDT market generated approximately 54,000 USDT in annualized borrow interest revenue over the trailing 30 days.\nAt unchanged rates, annualized revenue is expected to reach approximately 100,000 USDT as the loan book expands over the next 6 to 8 weeks.\nUSDG\nThe Core USDG market has $49.3M borrowed against $64.0M supplied, at 77% utilization. Global Dollar has $29.9M borrowed against $33.4M supplied, at 90% utilization. Combined borrowing is approximately $79.2M, making USDG one of the largest borrowed assets in v4. Prime and Plus do not list it.\nCore native Spokes account for $33.9M of borrowing. Another approximately $15.4M, or 31%, is drawn through credit lines by Global Dollar native strategy Spokes. This differs from the USDC and USDT markets, where Core credit lines are primarily used by the lower risk Bluechip Spoke. Core USDG’s credit lines instead extend to strategy Spokes backed by yield bearing and maturity dated assets.\nThe book’s scale has developed alongside continuous supply incentives. While the timing does not establish that all borrowing depends on rewards, the current market structure provides limited evidence that the present scale can be sustained without incentives. As incentives are depleted, there is therefore a meaningful risk of contraction in both supply and borrowing, which should be considered when assessing the durability of the current book size.\nimage1920×1080 133 KB\nCollateral composition\nThe Core USDG market has approximately $72.9M of collateral backing $49.3M of debt, providing approximately 1.5x collateralization. Pristine collateral represents approximately 57% of the pool. The collateral supporting the credit lines therefore sits alongside a substantial pristine component, rather than extending Core into a uniformly lower risk pool.\nimage1920×1080 136 KB\nThe five largest borrowers account for 49% of total debt, indicating a relatively concentrated borrower base, while 32% of outstanding debt is associated with positions below a 1.1 health factor. This combination points to meaningful borrower concentration and near term liquidation exposure for the Core USDG market.\nThe Global Dollar USDG market has approximately $34.9M of collateral backing $29.9M of debt, providing approximately 1.17x collateralization. SyrupUSDG accounts for effectively the entire collateral pool, while approximately 95% of outstanding debt is associated with positions below a 1.1 health factor. The limited collateral diversification and thin collateral buffer indicate a comparatively higher credit risk profile.\nSupplier concentration\nThe Core USDG market has 384 suppliers holding $64M in liquidity. Before campaigns, essentially a single wallet held ~100% of supply, nearly the entire supplier count arrived during the campaign era.\nA large LP associated with the program operator accounts for 34.5% of Core supply, while the five largest suppliers collectively account for 43.3%.\nimage1920×1080 128 KB\nThe Global Dollar USDG market remains more concentrated: among 73 suppliers holding $33.0M, the same wallet accounts for 84.9% of supply, while the top five account for 91.6%.\nfrxUSD\nThe Core frxUSD market has $19.8M borrowed against $29.1M supplied, representing 68% utilization. Unlike the other stablecoin markets, most of its debt originates through credit lines. Spokes native to other hubs account for approximately $12.3M, or 62% of total borrowing. The Ethena Ecosystem Spoke is the largest contributor at $8.0M, backed by sUSDe, while the Bluechip Spoke contributes another $4.28M against collateral held in Prime. Core native Spokes account for approximately $7.5M.\nThe borrowed book increased from $2.7M when the supply side incentive campaign began to $19.8M, with its expansion closely associated with the incentive period. Growth has nevertheless plateaued since mid July. Rewards remain the larger component of supplier returns, while debt growth has slowed despite continued incentives, suggesting that the current book may have limited organic growth momentum.\nimage1920×1080 115 KB\nCollateral composition\n$37.8M of collateral backs $19.8M of debt, providing approximately 1.9x collateralization, with pristine collateral representing approximately 66% of the pool.\nimage1920×1080 157 KB\nIn addition, 45% of debt is associated with positions below a 1.1 health factor, while the five largest borrowers account for 53% of total debt.\nSupplier concentration\nAmong wallets meeting the $10 minimum balance, 47 suppliers provide $29.1M in liquidity. The largest supplier accounts for 47.2% of supply, while the top five account for 90.5%, making frxUSD the most concentrated supplier base among the Core stablecoin markets.\nimage1920×1080 122 KB\nThe majority of suppliers are affiliated with the issuer, placing a substantial share of supply within the Frax ecosystem.\nThis concentration means that an Umbrella market funded from the current supplier base would largely concentrate underwriting with the party whose asset it protects. Such an arrangement would provide limited risk transfer away from the issuer ecosystem, weakening the case for Umbrella coverage.\nRecommendation\nWe recommend establishing general purpose Umbrella markets for Core WETH, Core USDC, and Core USDT.\nThese markets combine meaningful loan books with relatively strong collateral and borrower profiles, while their supplier bases provide sufficient depth to attract additional underwriters. They therefore offer the strongest combination of meaningful exposure and viable risk transfer under the v4 framework.\nWe do not recommend coverage for the remaining markets at this stage. The decision reflects the balance between the amount of risk requiring protection, the incremental value of Umbrella coverage, and the availability of capital to underwrite that risk.\nPrime USDC and Prime USDT have relatively low credit risk and strong collateral coverage, limiting the incremental protection that Umbrella would provide relative to its underwriting cost. Global Dollar USDC and Plus USDT/C have more limited and concentrated borrowing, with collateral and borrower profiles that do not currently provide sufficient scale or risk diversification to justify separate coverage. Their supplier bases are also too concentrated to support a sufficiently broad underwriting base.\nCore USDG and Core frxUSD have meaningful loan books, but their current structures provide weaker foundations for general purpose coverage. Both remain heavily influenced by incentive-driven supply and borrowing, creating uncertainty around the durability of their current exposure, while Core frxUSD has a highly concentrated supplier base and substantial exposure to the issuer ecosystem. In both cases, the current market structure limits how much Umbrella can meaningfully transfer risk.\nThese markets should therefore be reassessed as their loan books mature, incentive dependence declines, and supplier bases broaden and diversify.\nThe proposed parameters are forward looking and account for approximately six to eight weeks of expected growth.\nSpecification\nNew Umbrella markets\n\nHub\nCovered reserve\nCovered Spokes\nCooldown\nUnstake window\n\nCore\nWETH\nAll Spokes borrowing the reserve\n20 days\n2 days\n\nCore\nUSDC\nAll Spokes borrowing the reserve\n20 days\n2 days\n\nCore\nUSDT\nAll Spokes borrowing the reserve\n20 days\n2 days\n\nTarget Liquidity & emissions\n\nHub\nCovered reserve\nTarget Liquidity\nMax Emission / year\nEmission APY at target\n\nCore\nWETH\n800 ETH\n20.8 ETH/yr\n2.6%\n\nCore\nUSDC\n400,000 USDC\n12,800 USDC/yr\n3.2%\n\nCore\nUSDT\n400,000 USDT\n12,800 USDT/yr\n3.2%\n\nReward configuration & budget\n\nHub\nCovered reserve\ndistributionEnd\nCollector allowance\n\nCore\nWETH\nlaunch + 12 months\n20.8 ETH\n\nCore\nUSDC\nlaunch + 12 months\n12,800 USDC\n\nCore\nUSDT\nlaunch + 12 months\n12,800 USDT\n\nDeficit offsets\n\nHub / reserve\nDeficit offset\n\nCore WETH\n33 ETH\n\nCore USDC\n15,000 USDC\n\nCore USDT\n15,000 USDT\n\nNext Steps\n\nDeploy the approved Umbrella markets for Core WETH, Core USDC, and Core USDT using the parameters specified above.\n\nMonitor covered loan books, supplier composition, borrower concentration, reserve revenue, and changes in incentive driven demand following activation\n\n****Re-run the framework after three months to assess whether the coverage levels, supplier bases, and market conditions remain appropriate and adjust parameters if necessary.\n\nDisclaimer\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nCopyright\nCopyright and related rights waived via CC0.\n\n read \n\n 10\n min\n\n post by JosueMpia on Sep 12\n\n JosueMpia\n\n Thank you for putting this together @TokenLogic. I have a few thoughts about how the coverage changes over time.\n1. First thought: Are we locking in the current Umbrella with the current approved spokes?\nBecause deficit risk sits with the specific (Hub, asset) that was drawn, a newly eligible Spoke (Say in 2027 we want to add Coinbase ETH Spokes on CORE) should not automatically receive free access to existing Hub Umbrella capital. Does it make sense? Adding a new Spoke effectively changes the insurance terms for current stakers.\nI believe no newly eligible Spoke added in the same hub should become slashable against existing Umbrella capital until Umbrella stakers have received at least one full cooldown + withdrawal cycle of **notice.\n**\nFor example:\n\nGovernance want to add new Spoke inside of Core Hub using ETH as a borrow.\n↓\nGovernance approves the Spoke and publishes its risk parameters. Umbrella Coverage perimeters should be updated through governance, with Tokenlogic publishing the risk analysis and notice.\n↓\nTokenlogic can announced a 22+ day notice (20 days of cooldown plus the 2-day unstake window) for stakers who are not comfortable for it.\n↓\nExisting stakers may exit\n↓\nNew Spoke becomes Umbrella-eligible\n\nExisting stakers should have the opportunity to exit before the new Spoke becomes Umbrella-eligible. This should be enforced by the protocol or governance timelock, rather than relying only on an announcement. Otherwise “Hub - Asset Coverage” quietly becomes governance can alter your Umbrella coverage after you stake.\n2. Second thought: How are we preventing free-riding?\nI truly believe each Spoke should also provide a risk-adjusted first-loss contribution before Hub-wide Umbrella capital is exposed. I mean, we have the risk premium we could take a bit from, right? no? Here is is how that might look like.\nSpoke first-loss contribution\n=\nHub asset exposure\n× stress-loss factor\n× concentration risk\n× risk premium factor\n\nThat money would build the Spoke-specific first-loss contribution before Hub-wide Umbrella is touched. Here, I modified your map to show how that will look like in theory:\n0D86B72E-F36A-4E73-A019-2CB18B6200CE.PNG1672×534 118 KB\nAlso, Does a broad supplier base actually mean the risk is diversified? As you said on the \"Supplier concentration\" section above, Core WETH may have approximately 826 suppliers, but around 96% of WETH debt currently comes from EtherFi exposure, largely through one leveraged weETH strategy. The 826 figure is also weak because it includes suppliers with balances of at least $10. That can include dust accounts, multiple wallets controlled by one entity, affiliated suppliers, and suppliers who have no intention of underwriting Umbrella risk. The capital side may be broad while the loss-generating side remains highly concentrated.\nFinally, as an initial Umbrella launch, I would vote YES on this. I truly think this is a great start to getting Umbrella out with V4 and get real insight from real market data. With that being said, this should probably be consider Umbrella v1 for Aave V4. With more time and more learning, Umbrella should in theory get better and more precise.\nThanks\n\n This topic will close a month after the last reply.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Umbrella Coverage Expansion\n\n Governance\n\n 7\n\n 825\n\n Dec 2025\n\n Aave v4: Umbrella - Concept Brainstorm\n\n General\n\n 2\n\n 373\n\n Feb 17\n\n LlamaRisk - Monthly Community Update\n\n Governance\n\n 28\n\n 3.4k\n\n 16h","tokens":7879,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262320565,"hash":"027a9c53f99abc04977cfea79783730521b7513a"}
{"url":"https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901/1","domain":"ethresear.ch","title":"How to hard-fork to save most users' funds in a quantum emergency - Execution Layer Research - Ethereum Research","text":"How to hard-fork to save most users’ funds in a quantum emergency \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2024\n\n 1 / 39\n\n Mar 2024\n\n Mar 2025\n\n post by vbuterin on Mar 9, 2024\n\n vbuterin\n\n Suppose that it is announced tomorrow that quantum computers are available, and bad actors already have access to them and are able to use them to steal users’ funds. Preventing such a scenario is the goal of quantum-resistant cryptography (eg. Winternitz signatures, STARKs), and once account abstraction is in place, any user can switch to using a quantum-resistant signature scheme on their own schedule. But what if we don’t have that much time, and a sudden quantum transition happens long before that?\nI argue that actually, we are already well-positioned to make a pretty simple recovery fork to deal with such a situation. The blockchain would have to hard fork and users would have to download new wallet software, but few users would lose their funds.\nThe main challenge with quantum computers is as follows. An Ethereum address is defined as keccak(priv_to_pub(k))[12:], where k is the private key, and priv_to_pub is an elliptic curve multiplication to convert the privkey into a pubkey. With quantum computers, elliptic curve multiplications become invertible (because it’s a discrete-log problem), but hashes are still safe. If a user has not made any transactions with their account, then only the address is publicly visible and they are already safe. But if a user has made even one transaction, then the signature of that transaction reveals the public key, which in a post-quantum world allows revealing the private key. And so most users would be vulnerable.\nBut we can do much better. The key realization is that in practice, most users’ private keys are themselves the result of a bunch of hash calculations. Many keys are generated using BIP-32, which generates each address through a series of hashes starting from a master seed phrase. Many non-BIP-32 methods of key generation work similarly: eg. if a user has a brainwallet, it’s generally a series of hashes (or medium-hard KDF) applied to some passphrase.\nThis implies the natural structure of an EIP to hard-fork the chain to recover from a quantum emergency:\n\nRevert all blocks after the first block where it’s clear that large-scale theft is happening\nTraditional EOA-based transactions are disabled\nA new transaction type is added to allow transactions from smart contract wallets (eg. part of RIP-7560), if this is not available already\nA new transaction type or opcode is added by which you can provide a STARK proof which proves knowledge of (i) a private preimage x, (ii) a hash function ID 1 <= i < k from a list of k approved hash functions, and (iii) a public address A, such that keccak(priv_to_pub(hashes[i](x)))[12:] = A. The STARK also accepts as a public input the hash of a new piece of validation code for that account. If the proof passes, your account’s code is switched over to the new validation code, and you will be able to use it as a smart contract wallet from that point forward.\n\nFor gas efficiency reasons (after all, STARKs are big), we can allow the STARK to be a batch proof, proving N STARKs of the above type (it has to be a STARK-of-STARKs rather than a direct proof of multiple claims, because each user’s x needs to be kept private from the aggregator).\nThe infrastructure to implement a hard fork like this could in principle start to be built tomorrow, making the Ethereum ecosystem maximally ready in case a quantum emergency does actually come to pass.\n\n So you wanna Post-Quantum Ethereum transaction signature\n\n Tasklist for post-quantum ETH\n\n Post quantum TXs in The Verge\n\n Post-Quantum Threats to Ethereum Privacy\n\n Migration Strategies for EOAs under the Quantum Threat: Breakages, and Open Questions\n\n 9\n\n 6\n\n 4\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n post by irnb on Mar 9, 2024\n\n irnb\n\n I created this to help visualize the proof statement.\nimage1920×1270 204 KB\n\n post by myaksetig on Mar 9, 2024\n\n myaksetig\n\n This is a great suggestion! A while ago Chaum, myself, and Mario Larangeira created the notion of quantum-secure fallbacks for wallets. First we started with actually hiding a post-quantum key behind the ecdsa key (easier to rollover, but not completely compatible with traditional wallets).\nWe now have a paper under review where we propose pretty much what you suggest here (which has already been discussed in a different thread) as well as the integration of that preimage into the ecdsa signature nonce to create a fail-stop signature scheme\n\n post by pldd on Mar 9, 2024\n\n pldd\n\n The more keys have to be replaced, the bigger the future upgrade.\nWe made quantum resistant smart contract wallets at anchorwallet.ca using Lamport signature.\nA new version built on ERC 4337 is coming.\n\n post by DogeProtocol on Mar 9, 2024\n\n DogeProtocol\n\n If quantum computers are already in the hands of a bad actor and are able to crack Ethereum wallets (like using Shor’s algorithm) fast enough, it would be too late, since determining a bad-actor from the actual owner of the account wouldn’t be possible.\nDo not use stateful post-quantum algorithms; rather use NIST standardized ones in hybrid mode (combiner) with a classical algorithm, like Dilithium + ed25519. Ethereum have to take a significant hit on block sizes though, due to the currently standardized post-quantum dsa scheme’s large signature and public key sizes.\n\n post by nvmmonkey on Mar 9, 2024\n\n nvmmonkey\n\n If quantum computers are in bad hand, we need a ML monitor system in the node tree to detect large transactions of unsafe/abnormal human transfer first to trigger Stark fail-safe pre-built emergence fork. Dynamic on chain fuzzing/firewall intercept protocol could be a big leap for prior the enforced fork.\n\n post by tanteikg on Mar 10, 2024\n\n tanteikg\n\n My startup, pQCee dot com, has been working on a quantum-safe ECDSA based on the pre-image proof which is similar in design to @vbuterin post. We called it Signature Pre-image proof (SPP) and is patent-pending. It was presented at decompute 2023 (a side event from Token2049)\nWe started with making ECDSA signatures in PDF documents quantum-safe and our next steps include making ECDSA in Ethereum and Bitcoin quantum-safe based on the same principle. Watch out for our EIP to be available soon.\n\n post by ShaiW on Mar 10, 2024\n\n ShaiW\n\n Hi @vbuterin, thank you for the post.\nAbout a year ago (almost to the day, actually!), my Ph.D advisor Or Sattath and I considered the same problem, and proposed a protocol employing similar ideas – in particular using the BIP-32 derivation process for post-quantum authentication.\nA preprint is available on IACR /2023/362, and our work was also presented in the PQCSM2 workshop, slides available on their website (your policy does not allow me to post links).\nWe flesh out ideas very similar to yours and discuss how they can be composed. Our work also includes a careful analysis of the collision resistance of BIP-32 derivation paths, as well as a security analysis of the resulting signature scheme.\nThe greatest difference between our approaches, I think, is that we used Picnic signatures rather than STARKs. The advantage of our approach is that gas can be paid from the spent pre-quantum account itself, but of course, the disadvantage is that the signatures cannot be batched. We propose another approach to deal with signature sizes: a protocol where the signature must only be posted to the blockchain in case of fraud attempts.\nWe also describe a “quantum canary” mechanism for detecting quantum adversaries (inspired by Justin Drake’s cryptographic canaries) and provide some analysis of its game theory.\nYou might find that our work expands and complements the ideas presented in your post.\n\n post by MaverickChow on Mar 10, 2024\n\n MaverickChow\n\n Is it possible to just do an EIP upgrade whereby users have a choice to generate a totally different address/private key that is quantum resistant anytime he wants and do the transition on his own?\nIn this situation, we would have 2 types of addresses/keys in use; the traditional non-quantum resistant one and the newer quantum resistant one. After the quantum attack, any user who has already transitioned to using the newer keys (before the attack) need not do anything, while users who are still using the traditional one can then transition to the newer keys.\nThis way, I think, will create the least disruption to the network.\n\n post by pldd on Mar 10, 2024\n\n pldd\n\n We have a Cryptokitty stored in a Lamport wallet since last year, see nft/0x06012c8cf97bead5deae237070f9587f8e7a266d/1850 on etherscan, stored at address 0xE1C67B7Db6eA02125D4a2d4Ec91D382dbF98E3d9\nIt’s impossible to move this NFT without a Lamport signature verified by the network.\nSo it’s already possible with the smart contract wallets on anchorwallet.ca\nWe are testing a version built on ERC 4337 on Sepolia currently.\n\n post by corepool on Mar 10, 2024\n\n corepool\n\n 5 years ago, My team has organized one small summit to talk about this topic. The conclusion is cannot use hard fork to help the real owner take back the coins after the fork. Because there is no way to separate the owner and Q-hacker.\nHope we find the right way now.\n\n post by myaksetig on Mar 10, 2024\n\n myaksetig\n\n DogeProtocol\n\n Unlike what you think, it is actually possible. That ‘impossibility’ was already proven incorrect (by us). You can show specific one-way hashing encoding in the way you create the secret key, which the malicious actor can’t…\nAlso, the point of this construction is not to specify what will be the post-quantum signature scheme. But how to rollover a regular ecdsa wallet to any type of post-quantum wallet securely\n\n post by domothy on Mar 11, 2024\n\n domothy\n\n While I understand this is in the hypothetical scenario of a “zero-day” quantum attack, I really don’t like the idea of having to rollback a huge number of blocks, especially given that (i) it might not be so obvious where the large-scale theft began and (ii) the hard fork has to be implemented and coordinated, taking more time where new blocks are produced that will ultimately have to be rolled back (effectively a massive liveness failure)\nmore on (i), picture a single large exchange wallet being drained by a quantum computer. Everyone would naturally assume it was a security failure of some kind on the exchange’s end. Or if a smart wallet relying on discrete log assumption gets drained, a smart contract bug/exploit would be the first thing that comes to mind. Or the quantum-enabled attacker avoids high profile targets altogether and slowly steals funds from various large EOAs, and we never even know a quantum attack took place\nI would rather see this EIP proactively implemented today with the addition that the mechanism stays inactive until a kill switch is linked to previous ideas around “Quantum Canary” is triggered – i.e. a large enough amount of ETH sitting in a contract, secured only by a discrete log problem weaker than the ECDSA used by EOAs, but still infeasible to crack through a classical computer. If/when the ETH gets claimed, then no need for a messy emergency hard fork, since the mechanism outlined in the original post would kick in in the very next block\n\n post by MaverickChow on Mar 11, 2024\n\n MaverickChow\n\n How does the solution work with EOA-based keys that were generated pre-BIP, i.e. those generated without 12/24-word seed/passphrase?\n\n post by Mirror on Mar 12, 2024\n\n Mirror\n\n As far as I remember, the Ethereum Foundation has a dedicated team researching this (I remain optimistic about this), and I do not think that the progress of quantum computing will pose a crisis to Ethereum in the short term. I have not researched the impact of quantum computing on Ethereum, but I have studied about Bitcoin, so perhaps I can help clarify:\nCurrently, the most advanced superconducting processors have only hundreds of quantum bits (qubits), and the ultra-low temperature working environment limits the processor size and prevents physical manipulation. Room temperature superconductivity (not yet achieved) will address the existing hardware expansion issues in quantum computing.\nBitcoin’s public key is vulnerable and easily attacked within a time window of approximately 10-60 minutes after a transaction is initiated. Breaking encryption within an hour requires approximately 317 million physical qubits.\nCiting “The impact of hardware specifications on reaching quantum advantage in the fault tolerant regime” it states:\n\"We quantify the number of physical qubits needed to break encryption as a function of code loop time and basic physical error rate. Using surface codes, with a code loop time of 1 microsecond, reaction time of 10 microseconds, and physical gate error rate of 10^-3, breaking encryption within an hour requires approximately 317 million physical qubits.\nIf the basic physical error rate is a more optimistic value of 10^-4, then breaking encryption within an hour would require 33 million physical qubits. This significant demand for physical qubits implies that the Bitcoin network will not be threatened by quantum computing attacks for many years to come (potentially over a decade).\"\nDo not let “Vitalik says” become an accomplice to fraud, quantum computing cannot harm Bitcoin, let alone harm the actively innovative Ethereum.\n\n post by pa7x1 on Mar 13, 2024\n\n pa7x1\n\n I’m glad to see a plan is being formed. I have a few questions.\nThe proposal above deals with an emergency hard fork to undo an attack.\nQ1: How would the transition to a post-quantum Ethereum be changed (if at all) in case we were to perform the change preemptively? That is, if instead of having to rush a change to fix we have time to plan an ideal post-quantum solution.\nQ2: How would we morph the hotfix solution proposed above into this final solution (if at all)?\nThe idea of the above two questions is that it’s good to have a plan to hot fix. But hot fixes usually take shortcuts and trade-offs that may not necessarily be ideal. How would the ideal solution look like and how we could migrate the hotfix to it?\nQ3: The above solution deals with the use of elliptic curves for public key derivation. But Ethereum uses elliptic curves also for BLS signature aggregation and the KZG commitments. How are these impacted and what plan is there to move them to quantum resistant algorithms if needed?\n\n post by doctor-gonzo on Mar 14, 2024\n\n doctor-gonzo\n\n Glad to see people of such caliber thinking / planning for this – I did some basic research on this topic years ago and think there are a few difficulties which are not completely addresses by this proposal:\n\nIt might not be obvious when the quantum attack started (if used in a targeted way, or if the goal is to discredit the security of Bitcoin / Ethereum rather than to steal the funds of any individual accounts), similar to concerns mentioned by @domothy above\n\nThe social and coordination aspects of such an emergency hard-fork / pause on transactions might be thornier than they appear, and may destroy a large part of the financial value stored in BTC and ETH even if the technical aspects of relevant hard-forks are sound. With such a highly technical matter, most users will not have any idea of the cryptographic details and trusted individuals / teams (such as Vitalik) will be crucial for advocating which path to take, and there are sure to be suspicious parties and contentious decisions.\n\nI have previously worked with the Quantum Resistant Ledger project, which has had a post-quantum XMSS-secured mainnet live for 5+ years. They are a member of the Post-Quantum Cryptography Alliance and have funded grants for research by Geometry Labs to push the frontier of post-quantum signature aggregation techniques and turn their results into an open-source implementation to be evaluated by NIST.\nQRL is working to incorporate smart-contracts / EVM compatibility in their next update, and if any talented cryptographers and/or blockchain developers want to contribute to a post-quantum life-raft, collaboration with QRL and Geometry Labs might be among the most immediate / direct / open-source ways.\nI love Ethereum and am not trying to shill QRL too much, but I am concerned about a sudden quantum advance destroying the credibility of blockchain networks (and/or the financial value stored in them). It doesn’t seem like the Bitcoin ecosystem takes the quantum risk seriously at this point, and with BTC being introduced into the mainstream financial system it strikes me as somewhat of a time bomb.\nIt seems possible that public knowledge of the SOTA on quantum computers will be lacking right up until there is some plausible “y2q” event (such as Satoshi’s BTC and other pay-to-public-key mining reward coins being moved), due to the national security implications of such technology and the incentive for relevant governments to push for secrecy around advances (even though it seems the SOTA is in the private sector).\n\n post by pldd on Mar 16, 2024\n\n pldd\n\n First Ethereum Wallet1068×738 33.8 KB\nHere we go @vbuterin : ERC-4337 + Lamport on Ethereum Mainnet as a browser plugin wallet.\nWe are doing a few more tests and we will start distributing more widely.\n\n 13 days later\n\n post by pldd on Mar 30, 2024\n\n pldd\n\n The plugin wallet Anchor Vault is now available in the Chrome Web store. The wallet is built on ERC 4337 and implements quantum resistance by using Lamport signatures.\nThis way it’s possible to protect Ethereum assets now @vbuterin.\n\n 12 days later\n\n post by matthiasgeihs on Apr 12, 2024\n\n matthiasgeihs\n\n How would all of this be affected if EC-based Verkle tries are included in the picture? @vbuterin\n\n Load more posts below","tokens":4451,"squid":"ink-research","role":"Deep Scholar","at":1791262323486,"hash":"ad41e2a8f30cb777e1ddcde049fb181f1c0b61c7"}
{"url":"https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901/42","domain":"ethresear.ch","title":"How to hard-fork to save most users' funds in a quantum emergency - Execution Layer Research - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 6\n\n 4\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n Mar 2024\n\n 39 / 39\n\n Mar 2025\n\n Mar 2025\n\n Load more posts above\n\n post by matthiasgeihs on Apr 12, 2024\n\n matthiasgeihs\n\n How would all of this be affected if EC-based Verkle tries are included in the picture? @vbuterin\n\n post by vbuterin on Apr 12, 2024\n\n vbuterin\n\n We would need to switch from Verkle trees to binary trees based on STARK-friendly hash functions. It would be very beneficial to start writing that code (including the prover) asap.\n\n post by tanteikg on Apr 19, 2024\n\n tanteikg\n\n tanteikg\n\n Ethereum relies on Digital Signing over Elliptic Curve Cryptography (ECDSA – to represent the entire ECC family, e.g. EdDSA, BLS, Schnorr) for transaction security, with wallets storing private keys for signature creation, and nodes verifying transactions using corresponding public keys. However, with the rise of quantum computing, quantum computers could potentially break ECDSA cryptography, enabling attackers to steal assets by deriving private keys from public keys without wallet access. Estimates suggest cryptographically-relevant quantum computers could appear between 2028 and 2040, necessitating proactive mitigation strategies to safeguard Ethereum’s decentralized ecosystem.\npQCee dot com has been working on a quantum-safe ECDSA based on the pre-image proof called Signature Pre-image Proof (SPP) and is patent-pending. SPP was presented at DeCompute 2023 (a side event from Token2049). Coincidentally, in March 2024, @vbuterin wrote this post titled “How to hard-fork to save most users’ funds in a quantum emergency” which suggested a design similar to SPP.\nWe are excited to share a draft of an EIP that we have been working on. The proposal aims to present a solution for integrating a post-quantum signature scheme into the Ethereum blockchain while maintaining backward compatibility with existing ECDSA. The PQC signature scheme, targets integration with a quantum-safe zero-knowledge proof system such as zkSTARK or MPC-in-the-Head, to ensure the long-term security of Ethereum transactions against quantum attacks without requiring immediate upgrades to existing infrastructure.\nLooking forward to your thoughts on the proposal.\n\n 8 days later\n\n post by Bhaney44 on Apr 27, 2024\n\n Bhaney44\n\nI am really interested in this. Great post and topic. As I understand it, there are already quantum computers and a variety of models thereof. For example, D-Wave has adiabatic quantum computers, IBM has gate-model quantum computers, and PsiQuantum has photonic circuit board quantum computers.\nAmong the industry there seems to be a lot of in-fighting and competition for funding. As a result, many claim certain models are not real quantum computers. I’m more optimistic and think time will tell. In my opinion, what is important is whether there is an existing hardware-software combination that can break all classical crytpography.\nI agree with you that we are already well-positioned to make a pretty simple recovery fork to deal with such a situation. I think this is an extremely insightful point.\nI’m curious what led you to the conclusion that hashes are still safe, even when elliptic curves can be broken?\nOverall, really brilliant analysis here.\n\n 3 months later\n\n post by Wanseob-Lim on Aug 1, 2024\n\n Wanseob-Lim\n\n Do we have any existing specification or a plan to write one for below?\n\nPQC / EC co-exisitng status\nHow to map PQC & Account\nQuantum Bomb just like the Difficulty Bomb\n\n 5 months later\n\n post by frangio on Jan 10, 2025\n\n frangio\n\nCan this be done securely if an account is controlled by a threshold key?\n\n post by arikg on Jan 17, 2025\n\n arikg\n\n I believe this suggestion as-is supports less wallets and less volume/value than we initially expect. Maybe we can add to it to cover more.\nIt currently does not support threshold keys because they are not created from a seed and hash but rather from an interactive process between multiple parties. While the end characteristics of the keys are equivalent, they do not have the same “history” and there is no specific hash protected seed in the process. There is no official public number of threshold keys in the ecosystem to reference, but it’s reasonable to assume that it is in double digit percentage as it became a very common practice.\nAdditionally this approach assumes that wallets that were created from a seed actually allow the extraction of the underlying seed (e.g. 12/24 words of a typical wallet), which is likely not the case in some advanced HSM systems and also maybe in some general wallets and so even if there was an initial seed it might not be accessible by intentional design (security) or by unintentional design (why keep the seed if I keep the actual key).\nIf we want this plan to be “the plan” for all wallets in case of emergency we can add to it an ERC based solution that allows active wallets to be included in the plan regardless of their original creation process. This would allow wallets that are concerned to take action and “future proof themselves” without having to change their ongoing security practices by introducing a risky seed with any access today.\nThe general idea is to use the current ECDSA key (before it is breachable) to declare a new quantum protected seed phrase that will be used in this process in the future - in case the need arises. The ERC would define an acceptable format to define a quantum safe hash that hides a seed. If we already have a stage we can allow hashes that are considered more quantum safe (or just the existing ones) and we can allow other optional parameters for limiting the scope.\nA naive solution would be a typed 712 message, but of course 712 messages are not timed and so we would not know if it was signed before or after the breach, so we need to make sure it’s stored on-chain before the acceptable breaching date that is defined in the emergency plan. We can use some on-chain registery (e.g. EAS) for that purpose or a custom built one that is optimized for the usecase. Alternatively, with EIP-7702 going live we can define a standard that is based on that with a specified storage mechanism that stores this seed hash for use in case of emergency - again, does not require more than an ERC, but can also be embedded as part of an EIP for a more specific definition.\nPractically the only thing needed for this approach to work is that it is decalared as part of the “emergency plan” alongside the initial suggestion for seed based wallets. As soon as it’s clear to the ecosystem that signing that ERC message/transaction will not be ignored in a possible future emergency solution - the most quantum concerned users will start using it and we will likely see the ecosystem support in tooling around it.\n\n post by MaverickChow on Jan 22, 2025\n\n MaverickChow\n\nDoes anyone know, how can this work with EOA-based accounts that is/was generated pre-BIP, just in case? In other words, can an EOA-based pre-BIP account provide all the necessary data for the “STARK proof”?\n\n post by p_m on Jan 22, 2025\n\n p_m\n\n It depends on the exact method of generation. If something can be proven in ZK / STARK manner, then it’s prob fine.\nIf not, it’s better to move to other solutions.\n\n post by MaverickChow on Jan 23, 2025\n\n MaverickChow\n\n Thank you for replying. Would you think the private key alone is sufficient for the proof? I am not fond of BIP protocol-generated mnemonic phrases because after all they are all just “derivatives” of something higher (private keys).\n\n post by p_m on Jan 23, 2025\n\n p_m\n\n Not enough. If quantum computers will be created, they would be able to bruteforce private keys. So knowledge of one is not relevant.\n\n post by MaverickChow on Jan 23, 2025\n\n MaverickChow\n\n So only BIP-generated mnemonic phrases are valid for the transition?\nEdit: After re-reading Vitalik’s post, I guess only mnemonic phrases are accepted as inputs because the validation only consider hashes. Now what if I convert everything (EOAs) into smart contracts right away before any quantum crisis strikes, would that be a good idea?\nUpdate: After some thought, I believe the private key should be accepted as a valid input for the transition simply because:\n\nIf a private key is compromised because it has been used for OUT transaction at least once (never been used private keys are 100% safe), then chances are its account would be empty anyway and pointless to the transition.\nFor a never-been-used private key, the transition to a smart contract-based account should still be practical if the infrastructure allows a seed (or seeds, as decided by the account owner) as additional input for the creation of a smart contract-based account, therefore any hack post-transition would require both the private key + seed(s).\n\nWhat I see is happening now, is the private key being the strongest component of the network and there are groups of people behind the scene that are trying hard to get rid of the private key component to usher in something that can be far less secure, i.e. mnemonic phrases generated by 3rd-party apps/gadgets/widgets (you name it) that can only be used online (not offline) so that the future may be the one whereby everyone is not safe as everyone’s wealth can be 100% hacked, under the stupid pretense of trying to make everything convenient and to protect clumsy/lazy users from their mistakes. Security does not correlate with convenience.\n\n post by p_m on Jan 25, 2025\n\n p_m\n\nAnything which can be proven in ZK manner can theoretically create recovery keys. There are all kinds of different methods besides mnemonics. You can build your own scheme.\nMnemonics are 100% offline-friendly.\n\n post by MaverickChow on Jan 25, 2025\n\n MaverickChow\n\n Most hardware wallet (with mnemonic phrases) users (that I know of) doing an OUT transaction can only do so through online connection, i.e. their hardware device is required in online connection for the validation, the same hardware device that store the private key for the validation. Unlike using private key directly whereby you can store the private key strictly offline on a device and use an entirely different device for OUT transaction. Even if the hardware device is connected online for the validation for just a very brief moment, that should still be counted as online and all the dangers of getting online should still be considered as malware/virus/personal data/etc can be transmitted in almost an instant. An example is a wallet brand, if I remember correctly Tangem, that transmitted the users’ private key directly to the manufacturer the moment the hardware wallet gets connected. But if you want to use the mnemonic phrases offline for OUT transaction, you cannot, as I am not aware of any 3rd-party device is accepting such arrangement. This is what I mean when I say mnemonic phrases can only be used online, through any 3rd-party devices you can think of. And this poses a huge risk.\nUpdate: And in Tangem’s case, whereby the company said it has fixed the glitch, this CAN be a situation whereby a criminal deliberately breaks into your (or anyone) house to steal valuable things, and when caught, the criminal simply said, “Oh, I am sorry. I thought this is my house. But don’t worry. I have replaced the padlock/alarm/security for you and you may continue to live in your house and assume nothing ever happened.” And this criminal can be in possession of your house key all along and he is just not telling you that, which is why he broke into your house when you were away. And this is the risk when you use mnemonic phrases online through any 3rd-party device that you can name for any OUT transaction.\n\n post by p_m on Jan 28, 2025\n\n p_m\n\nMost hardware wallet (with mnemonic phrases) users (that I know of) doing an OUT transaction can only do so through online connection\n\nWho cares? Build a proper offline hardware device by yourself or maybe ask someone to build it. The scheme is offline-friendly. It does not require online presence even for brief moments.\n\n post by MaverickChow on Jan 28, 2025\n\n MaverickChow\n\n Everyone who has vested interest in Ethereum should 100% care.\nWhy (#1)? The problem is when the Ethereum blockchain’s future development is being done to revolve around such users whereby the partial thesis is to protect such users from their mistakes, which to my speculation can be somewhat detrimental to the overall security of the network. Like I said, security does not correlate with convenience. And when the security is being done to revolve around protecting dumb/stupid/lazy users from their dumb/stupid/lazy mistakes by making things more user/human-friendly, then the underlying security may eventually be compromised to some extent. Users that are not dumb/stupid/lazy will have to accommodate overall weaker security structure in order to be friendly to dumb/stupid/lazy users.\nWhy (#2)? In the beginning, everything revolves around private key + trustless. Now and in the future development, everything is shifting to no private key + trusted wallet (as mentioned in one of Vitalik’s blog posts). You should be aware of the difference in its significance.\nBeing able to build one’s own device is beside the main point.\nUpdate: I wish to add. A private key can do everything that a mnemonic phrase can, but a mnemonic phrase is created mainly not because it is better, but rather so that the user experience is such that it is easier to remember. Being easier to remember has nothing directly to do with security. And I have used mnemonic phrases before and I can tell everyone honestly the care that involves using such phrases is more complicated than using the private key directly.\nUpdate #2: Consider the possibility of a future whereby everyone can only do online transactions (no offline signed messages for online broadcast) through a trusted 3rd-party wallet (by imposing the need for partial validation or co-signing from such trusted 3rd-party wallet for the transaction to be processed). In other way of saying, you building your own device for offline use on online transaction will not be processed. And all these setups will be justified under the false/stupid pretense of protecting the users from their mistakes and enhancing user experience. What would you do then? And in case you still do not understand up to this point, what if those trusted 3rd-party wallets are criminals in the waiting to strike at the opportune time (or as ordered by the government), resulting in the total (or significant) loss of your entire wealth? Such future is possible.\n\n 1 month later\n\n post by MaverickChow on Feb 28, 2025\n\n MaverickChow\n\n I hope the recent Bybit’s $1.5 billion hack will be an additional security lesson that there is absolutely NO trusted 3rd-party wallet that can really be safe. Not Ledger, not Trezor, not Tangem, not Safe, and not any other brand that anyone can name. Every transaction needs to be strictly from offline signing. And if the major industry players truly care, then security must be built around the security-over-convenience thesis, instead of around the stupid pretense of catering to user-friendliness. Therefore, future blockchain infrastructure should also be built as such, instead of having even an iota of reliance on some trusted 3rd-party, no matter how trusted that 3rd-party you think is, for any transaction. Dependence on any hardware wallet/device is a form of reliance on some 3rd-party, and this will open up the potential for hacks.\nAlmost everyone (99.99%) keep saying using hardware wallet is the safest, but it actually is not. The Safe wallet that got hacked in order to get to Bybit’s $1.5 billion is a fine example of that. Hardware wallet is NOT the safest. You may name whatever the brand for being the safest, but they are just taking turns to get hacked. Do not use quantum computing, or user-friendliness, or any other stupid and lame excuses to end up building a weaker blockchain security structure.\nAir-gapped and strictly offline-generated signed messages for online broadcast (as well as for cold storage), independent of any 3rd-party hardware device, is the ultimate security. “Not your keys, not your coins” is widely spoken but almost nobody truly understands it entirely. If you do NOT know your private keys (maybe because someone told you are not supposed to because you pose a huge security risk, even though you are the owner), then you do not really own your coins. Just the same as if you have never seen your wife nor touched her, then you cannot claim that woman is your wife.\n\n post by p_m on Feb 28, 2025\n\n p_m\n\n Less words, more code. Write code which solves the pq issue reliably and show it to us.\n\n post by MaverickChow on Mar 1, 2025\n\n MaverickChow\n\n I am not a developer, but my main point, to put it differently, is to develop a blockchain structure that revolves around enabling, empowering, and enhancing strictly offline signing and cold storage capabilities to everyone (including the laypeople), and NOT on enabling, empowering, and enhancing online signing by way of abolishing private keys and relying on trusted 3rd-party apps. Do not say there is no other way.\n\n post by p_m on Mar 1, 2025\n\n p_m\n\n Learn to code then, to understand trade-offs, and stop posting nonsense. BIP39 is fully offline scheme which generates private keys. No one abolishes offline signing or private keys. You can generate keys once from bip39 and then copy-paste them anywhere.\n\n Powered by Discourse","tokens":4377,"squid":"ink-research","role":"Deep Scholar","at":1791262334292,"hash":"ba845c36d8f39e4ff183f5f0bec6d806cb51628f"}
{"url":"https://soliditylang.org/","domain":"soliditylang.org","title":"Home | Solidity Programming Language","text":"{Solidity}A statically-typed curly-braces programming language designed for developing smart contracts that run on Ethereum.Read the docsRepository25.7KSolidity is evolving rapidlyWe aim for a regular (non-breaking) release every month, with approximately one breaking release per year. You can follow the implementation status of new features in the Solidity GitHub project.Get startedContribute to SoliditySolidity continues to improve with help from our global community. Check out these ways to get involved and contribute to the Solidity project.Reporting issues and vulnerabilitiesTo report an issue, please use the GitHub issues tracker. To report a vulnerability, please check out the instructions in the SECURITY.md.Translating the documentationTranslations help developers from all corners of the world to be able to read the documentation and learn Solidity.Fixing and responding to issuesFixing and responding to issues, especially those tagged as “good first issue”, is a great way to get started for external contributors.Contributing to language designWe welcome Solidity power users, auditors, security experts and tooling developers to get involved in the Solidity language design process. Join the Solidity forum, where existing properties of the language and proposals for new language features can be discussed.Start contributingStay UpdatedStay always up-to-date by following the Solidity blog.You can see the upcoming changes for the next breaking release by switching from the default branch (develop) to the breaking branch. You can actively shape Solidity by providing your input and participating in the language design in the Solidity forumand participating in the yearly Solidity developer surveys.Latest from the blogSpill Slot Collision Across Mutual Recursion BugPosted by Solidity Team on September 10, 2026\nOn July 30, 2026, Ng Sze Hon reported a bug in the IR pipeline's stack-to-memory mover (the \"stack limit evader\") through the Ethereum Foundation's bug bounty program.\nThe mover works around the EVM's stack depth limit by relocating (\"spilling\") some local variables to fixed memory offsets, called spill slots.\nBecause of the bug, variables of two different functions can be assigned the same spill slot when the call graph contains mutual recursion, even though both variables can be live at the same...Read moreSolidity 0.8.37 Release AnnouncementPosted by Solidity Team on September 10, 2026\nWe have released Solidity v0.8.37.\n\nThis is primarily a bugfix release.\nIt contains three important bugfixes, two rated low/medium severity and one very low, as well as fixes for two smaller miscompilations that are not security issues.\nOn the experimental side, the SSA CFG code generator gets a new stack shuffler that replaces the previous greedy algorithm with a planning one.\nThe release also adds support for the SLOTNUM opcode of the Amsterdam EVM version, removes two experimental features and adds deprecation warnings for...Read moreMisordered Named Parameters in require with Custom Errors BugPosted by Solidity Team on September 10, 2026\nOn February 4, 2026, a bug in the IR-based code generator was reported by Carl from\nCantina Security through the Ethereum Foundation bug bounty program. The\nbug causes the arguments of a custom error passed to require using named-parameter syntax\nto be placed on the stack in call-site order rather than declaration order before they are\nABI-encoded.\n\nThe bug was introduced in Solidity 0.8.26, which added support for passing custom errors as\nthe second argument to require.\nSolidity 0.8.37 provides a fix.\n\nWe assigned the bug a severity...Read moreAll blog updatesPlaygroundTry Solidity for yourself in this simple compiler. For a more fully featured browser-based IDE, try using Remix.Hello World!ERC20Simple Auction// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\ncontract MyContract {\n function helloWorld() public pure returns (string memory) {\n return \"Hello, World!\";\n }\n}Compiler resultCompiler version: (0 bytes)Deployment costs: gasBytecodeAssemblySolidity EventsPast eventsSolidity Summit 2025La Rural, Buenos Aires, Argentina11/17/2025 - 11/17/2025Event InfoSolidity Summit 2023Istanbul Congress Center, Istanbul, Turkey11/15/2023 - 11/15/2023Event InfoUnderhanded Solidity Contest 2022Remote4/28/2022 - 4/29/2022Event InfoSolidity Summit 2022Tolhuistuin, Amsterdam4/19/2022 - 4/19/2022Event RecapTalksSolidity Summit 2020Remote4/28/2020 - 4/29/2020Event RecapTalks","tokens":1118,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262337903,"hash":"19bb126d8a1a2a3be39bc787a5a59ebab2717ac4"}
{"url":"https://dev-forum.pyth.network/t/cant-fetch-historical-prices-with-pyth-terminal-api/809/12","domain":"dev-forum.pyth.network","title":"Can't fetch historical prices with Pyth Terminal API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Jul 13\n\n 12 / 12\n\n Aug 4\n\n Aug 5\n\n post by Shawn on Jul 13\n\n post by KemarTiti on Jul 13\n\n post by Shawn on Jul 13\n\n post by KemarTiti on Jul 13\n\n post by Shawn on Jul 14\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n Shawn\n\n Thanks for the clarification. I now understand that the Pyth Pro/Lazer payload is not compatible with existing Pyth Core contracts and that Pyth Pro/Lazer is not currently available on Ethereum mainnet.\nHowever, this leaves a gap for existing Ethereum mainnet users who need to retrieve signed historical prices and submit them through the standard Pyth Core updatePriceFeeds(...) flow. The upgraded Hermes endpoint appears to provide only recent data, while the legacy Benchmarks API can retrieve much older historical updates.\nWould it be possible to add historical price support to the paid Pyth Core-compatible API? Ideally, it would:\n\nSupport historical timestamps older than three hours.\n\nReturn signed payloads compatible with Pyth Core updatePriceFeeds(...).\n\nWork with existing contracts on Ethereum mainnet without requiring a migration to Pyth Pro/Lazer.\n\nI subscribed to the Starter plan expecting it to provide a migration path for this existing historical-price workflow. It would be very helpful if the paid API could retain the functionality currently available through the legacy Benchmarks endpoint.\n\n post by Aditya520 on Jul 14\n\n Aditya520\n\n I see the confusion, and we are working to fix it in the docs as well.\nWe have upgraded Core contracts on Ethereum mainnet here.\nIf you use these APIs to fetch the signed payload, you will be able to parse the prices on the above Ethereum and other chain Upgraded Core contracts.\nYou can not use the old hermes data on the new upgraded Core contracts.\nIn regards to historical data in the new hermes data, I will follow up and give you more light soon.\n\n 21 days later\n\n post by PythUser on Aug 5\n\n PythUser\n\n KemarTiti\n\n Hey KemarTiti, if possible could you respond to this query. I understand this is not the right place to flag this, however I have not gotten a response on this since quite some time:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 190\n\n Jul 13\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n How to get more historical data faster?\n\n Benchmarks(Historic Prices)\n\n 3\n\n 585\n\n Sep 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":1603,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262350412,"hash":"76cdcc0d191c09f31ba56d793eed1cc89998a74c"}
{"url":"https://docs.openzeppelin.com/ui-builder","domain":"docs.openzeppelin.com","title":"Quickstart | OpenZeppelin Docs","text":"UI BuilderQuickstartOpen in ClaudeThe Contracts UI Builder is an open source tool you can quickly create online forms to interact with your smart contracts for testing or for administration purposes. It includes a vast amount of features including:\n\nConfigurable EVM Networks\nAutomatic contract state and ABI scraping\nCustom forms to handle different types of contract inputs and functions\nExecution restriction options\nOpenZeppelin Wallet UI or Rainbow Kit\nExport as React App project\n\nGetting Started\nVisit builder.openzeppelin.com to get started\n1. Select Network\nFirst select the network your contract is deployed to\n\n2. Provide Contract Address\nPaste in the contract address and the UI Builder will fetch the ABI if the contract is verified. If it is not verified then provide the ABI in the form.\n\n3. Select Function\nChoose which write function you would like to build a form for.\n\n4. Customize\nSetup the form for your function and customize any applicable fields, execution method restrictions, or wallet UI kit.\nCheck out the Customization section for more details\n\n5. Export\nOnce complete you can click the \"Export\" button which will download the form as a React app you can deploy or customize further.\n\nNext Steps\nLearn how you can customize networks or customize the forms for your project.\nVisit the GitHub repo with the link below and open an issue if you have any problems!\nGitHub RepoChangelogPrevious PageNetworksNext PageOn this pageGetting Started1. Select Network2. Provide Contract Address3. Select Function4. Customize5. ExportNext Steps","tokens":390,"squid":"ink-security_audits","role":"Sentinel","at":1791262356273,"hash":"2c69281cd5ca0b7ab3273893aeb3a5458074cf9d"}
{"url":"https://www.soliditylang.org/blog/2026/09/10/solidity-0.8.37-release-announcement","domain":"soliditylang.org","title":"Solidity 0.8.37 Release Announcement | Solidity Programming Language","text":"Solidity 0.8.37 Release AnnouncementPosted by Solidity Team on September 10, 2026ReleasesWe have released Solidity v0.8.37.\nThis is primarily a bugfix release.\nIt contains three important bugfixes, two rated low/medium severity and one very low, as well as fixes for two smaller miscompilations that are not security issues.\nOn the experimental side, the SSA CFG code generator gets a new stack shuffler that replaces the previous greedy algorithm with a planning one.\nThe release also adds support for the SLOTNUM opcode of the Amsterdam EVM version, removes two experimental features and adds deprecation warnings for several features planned for removal.\nImportant Bugfixes\nMemory Byte Array Element Delete Clears 32 Bytes\nWhen delete was applied to an element of a bytes array in memory, the evmasm pipeline wrote 32 zero bytes starting at that element instead of clearing only the element's byte.\nThe extra zero bytes overwrote up to 31 bytes following the element.\nThose bytes may belong to later elements of the same array or, when the element sits near the end of the array, to whatever is allocated after it.\nThe same applies to string values converted to bytes.\nThe IR pipeline is not affected, and the analogous assignment b[i] = 0 clears exactly one byte on both pipelines.\nAll versions up to and including 0.8.36 are affected.\nThe bug was reported by shaheenfazim through the Ethereum Foundation's bug bounty program.\nWrite-up: Memory Byte Array Element Delete Clears Whole Word Bug\nSpill Slot Collision Across Mutual Recursion\nThe stack-to-memory mover of the IR pipeline works around the EVM's stack depth limit by relocating some local variables to fixed memory offsets, called spill slots.\nIn certain call graph configurations containing mutual recursion, too few slots were reserved, so variables of two different functions could be assigned the same slot even though both could be live at the same time.\nOne variable was then silently overwritten by the other.\nThe bug is closely related to, but distinct from, the Unsound Spill In Mutual Recursion Bug fixed in 0.8.36.\nVersions 0.7.2 through 0.8.36 are affected when compiling with --via-ir.\nThe bug was reported by Ng Sze Hon through the Ethereum Foundation's bug bounty program.\nWrite-up: Spill Slot Collision Across Mutual Recursion Bug\nMisordered Named Parameters in require with Custom Errors\nIn the IR pipeline, the arguments of a custom error constructed with named arguments and passed to require, as in require(condition, MyError({b: 2, a: 1})), were put on the stack in call-site order rather than declaration order.\nDuring ABI encoding they could therefore be matched with the wrong parameters and be misinterpreted as values of completely different types.\nThe encoder would produce a structurally valid payload matching the error signature but not reflecting the values used to instantiate the error.\nPlain revert MyError({...}) statements or any other language construct that allows named parameters are not affected.\nOnly the revert data of a transaction that is already reverting is affected, so the bug has no impact on contract state.\nThe bug was reported by Carl from Cantina Security through the Ethereum Foundation's bug bounty program.\nWrite-up: Misordered Named Parameters in require with Custom Errors Bug\nOther Miscompilations\nUninitialized Function Pointers in Packed Storage\nIn the evmasm pipeline, reading an uninitialized internal function pointer from a packed storage slot yielded the wrong value when a variable stored after it in the same slot held a non-zero value.\nAs a consequence, an equality comparison between such a pointer and a default-initialized local function pointer could be false, even though neither had ever been assigned.\nThe bug only affects the evmasm pipeline and has no effect on function calls made through such pointers.\nOnly the very specific case of packed pointers being compared before ever being assigned produces wrong results.\nRelying on the equality of internal function pointers is fragile, since their values depend on the exact bytecode and are not stable across contract updates, which is why the compiler already warns about such comparisons and we plan to disallow them in the next breaking release.\nTriggering the bug requires a very specific usage pattern, and it is reliably detectable through unit testing.\nConstants Read in Both Checked and Unchecked Contexts\nIn the IR pipeline, the code computing the value of a constant was generated once per contract, with either checked or unchecked arithmetic depending on which use site was generated first, and every other use site reused that code.\nFor a constant whose initializer overflows its type, a read in a checked context could therefore miss its required overflow panic, or a read in an unchecked context could revert with a spurious one.\nAll operands of the affected read are compile-time constants, so the miscompiled result is deterministic, independent of any transaction input and outside of an attacker's influence.\nExploiting it would require code that intentionally relies on a constant that always reverts at runtime, or on one that is meant to work inside unchecked blocks but not outside of them, neither of which is a plausible design.\nThe realistic failure mode is a mistake in a contract with insufficient test coverage: the evaluation of the constant reverts with a Panic on the first execution of the affected function, and the missing check yields a fixed wrapped value, both of which would be easily discoverable in testing.\nReaching the bug also requires reading the same overflowing constant from both a checked and an unchecked context within one contract, which we expect to be rare in practice.\nNotable Features and Changes\nSSA CFG Planning Stack Shuffler (Experimental)\nThe experimental SSA CFG code generator precomputes a stack layout for every point in the program.\nIts stack shuffler emits the SWAP, DUP, POP and PUSH instructions that get the stack from one layout to the next.\nUntil now the shuffler worked greedily, applying one local step at a time until the target layout was reached.\n0.8.37 replaces it with a planning shuffler.\nThe new shuffler first computes an explicit plan that maps the items on the current stack to their positions in the target layout, and then realizes that plan bottom-up.\nIf it gets stuck because an item is out of reach for SWAP or DUP, it compresses the stack to achieve reachability and starts over from a new plan.\nThe more structured approach is easier to maintain, and initial benchmarks show it to be computationally more efficient than the greedy one while producing bytecode of roughly the same size.\nThe SSA CFG code generator remains experimental and is enabled with --experimental --via-ssa-cfg.\nSupport for the SLOTNUM Opcode\nThe Amsterdam EVM version introduces the SLOTNUM opcode (EIP-7843), which returns the beacon chain slot number of the current block.\n0.8.37 exposes it in Solidity as block.slotnum of type uint64, and in Yul and inline assembly as the builtin slotnum().\nThe SMTChecker supports the new member as well.\nblock.slotnum and slotnum() are available only when compiling with --evm-version amsterdam.\nThis is another step towards adding support for all Amsterdam features, which started with 0.8.36 and is still experimental.\nFrom Amsterdam on, slotnum is also a reserved identifier in Yul.\nRemovals and Deprecations\nTwo features that were restricted to the experimental mode in 0.8.35 are now removed entirely: the Language Server Protocol mode (--lsp) and the Generic Solidity prototype (pragma experimental solidity).\nThe LSP mode was unfinished and unmaintained.\nWe have not abandoned the idea of a language server, but such tooling should be standalone rather than tightly integrated with the compiler, since that integration does not fit our goal of a leaner and more maintainable compiler.\nGeneric Solidity was an early prototype of Core Solidity that attempted to refactor the compiler in place and iterate on the next version of the language within the same codebase.\nThat approach proved neither fast nor flexible enough, and we abandoned it in favor of solcore, a standalone prototype that is better suited to experimentation and will be the base for a future production implementation.\nThe experimental ABIEncoderV2 pragma now emits a deprecation warning.\nThe pragma has been redundant since pragma abicoder v2 was introduced in 0.7.4 and ABI coder v2 became the default in 0.8.0.\nIt is a leftover from the time when ABI coder v2 was still experimental, so its removal does not require a breaking release.\nHowever, many projects still seem to use it, often indirectly through a dependency on older forge-std versions, so we decided to give them a chance to drop it before we proceed with the removal.\nContinuing the deprecation work started in 0.8.31, this release adds deprecation warnings for the EVM versions constantinople, petersburg, istanbul and berlin, and for the SMTChecker's BMC engine.\nFull Changelog\nImportant Bugfixes\n\nCode Generator: Fix delete applied to an element of a bytes array in memory zeroing the whole 32-byte word starting at the element's location instead of only the element's byte.\nYul IR Code Generation: Encode custom error named parameters in declaration order instead of call-site order when used from a require function.\nYul Optimizer: Fix too few memory slots being reserved when moving local variables to memory to work around stack-too-deep errors in code containing mutually recursive functions. Variables of two functions that can be active at the same time could be assigned the same slot, silently overwriting one of them while it was still in use.\n\nLanguage Features\n\nCustom Storage Layout: Allow signed positive expressions.\nEVM: Support block.slotnum to access the beacon chain slot number of the current block, available since the Amsterdam EVM version (EIP-7843).\nYul: Introduce builtin slotnum() for the SLOTNUM opcode, available since the Amsterdam EVM version (EIP-7843).\n\nCompiler Features\n\nCommandline Interface: Remove support for the experimental Language Server Protocol (LSP) mode.\nEVM: Deprecate support for \"constantinople\", \"petersburg\", \"istanbul\" and \"berlin\" EVM versions.\nEvmasm Optimizer: Improve performance of block deduplicator.\nGeneral: Improve performance throughout the compiler using Boost's flat versions of unordered set and map.\nGeneral: Remove support for the experimental Generic Solidity prototype (pragma experimental solidity).\nGeneral: Replace the current greedy stack shuffler in the experimental SSA CFG pipeline with a planning one.\nSMTChecker: Emit a deprecation warning for the BMC engine.\nSMTChecker: Support block.slotnum.\nYul Optimizer: LoopInvariantCodeMotion can now move expressions depending on function parameters out of loops.\nYul Optimizer: UnusedStoreEliminator can now recognize redundant memory and storage operations whose start offset or length is a function parameter.\nYul Optimizer: Remove the ineffective elimination of unused returndatacopy() operations in simple cases from UnusedStoreEliminator.\n\nBugfixes\n\nCode Generator: Fix constants read in both checked and unchecked contexts within one contract getting the checked/unchecked semantics of whichever read was generated first via IR, which could remove a required overflow panic or introduce a spurious one.\nCode Generator: Fix ICE on parenthesized custom error construction in require statement.\nCode Generator: Fix uninitialized internal function pointers being read from a packed storage slot with the wrong value when a subsequent variable in the slot holds a non-zero value.\nCommandline Interface: Reject --model-checker-ext-calls in unsupported input modes instead of silently ignoring it.\nCommandline Interface: Report proper error instead of ICE on non-hex mixed-case address value given via --libraries.\nStandard JSON Interface: Fix the entire output being replaced by a JSONError (\"Error writing output JSON.\") when an error message quotes a long source line and truncating it splits a multi-byte character.\nType Checker: Report an unimplemented feature error instead of ICE when a variable of a fixed point type is accessed in inline assembly.\nYul Optimizer: Fix incorrect removal of returndatacopy() operations referencing a stale result of returndatasize().\n\nBuild System\n\nUpdate minimum version requirement of Boost to 1.83.0 for Windows build. This matches the minimum version for other systems.\n\nHow to Install/Upgrade?\nTo upgrade to the new version of the Solidity Compiler, please follow the installation instructions available in our documentation.\nYou can download the release from GitHub: v0.8.37.\nIf you want to build from the source code, do not use the source archives generated automatically by GitHub.\nInstead, use the solidity_0.8.37.tar.gz source tarball or check out the v0.8.37 tag via git.\nAnd last but not least, we would like to give a big thank you to all the contributors who helped make this release possible!Previous postNext post","tokens":3257,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262361727,"hash":"26c183025cef4283a0be0b61f85595090f8cd062"}
{"url":"https://dev-forum.pyth.network/t/action-required-pyth-pro-history-api-auth-required-starting-july-24/808/1","domain":"dev-forum.pyth.network","title":"Action Required: Pyth Pro History API Auth Required Starting July 24 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Action Required: Pyth Pro History API Auth Required Starting July 24 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 8\n\n 1 / 2\n\n Jul 7\n\n Jul 13\n\n post by Aditya520 on Jul 8\n\n Aditya520\n\n Hey everyone,\nStarting July 24, 2026, the following Pyth Pro History API endpoints will require API key authentication:\n\nGET /v1/{channel}/price\nGET /v1/{channel}/history\nPOST /v1/price\n\nAPI key authentication is already supported in production today. Please update your requests to include:\nhttp\nAuthorization: Bearer <PYTH PRO API KEY>\n\nIf you call these endpoints from a browser or frontend app, do not expose your API key client-side. The recommended setup is to route requests through your own backend or proxy.\nFor frontend apps that need a client-safe option and do not want to run their own proxy, we expect JWT-based authentication to be available around July 10.\nUnauthenticated access to these endpoints will be disabled on July 24.\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Quick update for teams using these endpoints from a browser/frontend:\nThe preferred setup is still to keep your Pyth Pro API key server-side, behind your own backend or proxy. Please don’t expose the API key directly in client-side code.\nFor teams that need a frontend-safe option and don’t want to route every request through their own proxy, the JWT auth flow is now available here:\n\nThe basic flow is:\n\nYour browser client asks your backend for a JWT.\nYour backend calls POST /auth/token using your secret Pyth Pro API key.\nYour backend returns the JWT to the browser client.\nThe browser client uses that JWT as a bearer token:\n\nAuthorization: Bearer _*_\n\nDocs: Frontend Authentication | Pyth Developer Hub\nExample app: pyth-examples/pro/frontend-jwt-auth at main · pyth-network/pyth-examples · GitHub\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Pyth Pro Proxy API\n\n Announcements\n\n 0\n\n 74\n\n Feb 11\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Powered by Discourse","tokens":1493,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262362897,"hash":"c7b4417be25339b50fb5f94f728621efbf79a95c"}
{"url":"https://builder.openzeppelin.com/","domain":"builder.openzeppelin.com","title":"UI Builder","text":"Spin up a front-end for any contract call in seconds. Select the function, auto-generate a React UI with wallet connect and multi-network support, and export a complete app.Select Blockchain1Select Blockchain2Load Contract3Select Function4Customize5CompleteAbout Ethereum (EVM)Ethereum is a decentralized, open-source blockchain with smart contract functionality. It supports the Ethereum Virtual Machine (EVM) and uses the native cryptocurrency Ether (ETH).Mainnet networks are disabled on this hosted UI BuilderTestnet and devnet networks remain available here. To use mainnet, deploy UI Builder yourself from the source repository.MainnetEthereumChain ID: 1Self-host requiredArbitrum OneChain ID: 42161Self-host requiredBaseChain ID: 8453Self-host requiredPolygonChain ID: 137Self-host requiredPolygon zkEVMChain ID: 1101Self-host requiredBNB Smart ChainChain ID: 56Self-host requiredOP MainnetChain ID: 10Self-host requiredAvalanche C-ChainChain ID: 43114Self-host requiredLineaChain ID: 59144Self-host requiredScrollChain ID: 534352Self-host requiredZkSync EraChain ID: 324Self-host requiredTestnetSepoliaChain ID: 11155111Arbitrum SepoliaChain ID: 421614Base SepoliaChain ID: 84532Polygon AmoyChain ID: 80002Polygon zkEVM CardonaChain ID: 2442BSC TestnetChain ID: 97OP SepoliaChain ID: 11155420Avalanche Fuji C-ChainChain ID: 43113Linea SepoliaChain ID: 59141Scroll SepoliaChain ID: 534351ZkSync Era SepoliaChain ID: 300Monad TestnetChain ID: 10143","tokens":364,"squid":"ink-security_audits","role":"Sentinel","at":1791262370079,"hash":"5b86b8c1b4a6b54808b105688d1494b1b832cbd3"}
{"url":"https://www.soliditylang.org/blog/","domain":"soliditylang.org","title":"Solidity Blog | Solidity Programming Language","text":"{Solidity:​log}Latest News & AnnouncementsReleasesSecurity AlertsAnnouncementsExplainersSpill Slot Collision Across Mutual Recursion BugPosted by Solidity Team on September 10, 2026Security Alerts\nOn July 30, 2026, Ng Sze Hon reported a bug in the IR pipeline's stack-to-memory mover (the \"stack limit evader\") through the Ethereum Foundation's bug bounty program.\nThe mover works around the EVM's stack depth limit by relocating (\"spilling\") some local variables to fixed memory offsets, called spill slots.\nBecause of the bug, variables of two different functions can be assigned the same spill slot when the call graph contains mutual recursion, even though both variables can be live at the same...Read moreSolidity 0.8.37 Release AnnouncementPosted by Solidity Team on September 10, 2026Releases\nWe have released Solidity v0.8.37.\n\nThis is primarily a bugfix release.\nIt contains three important bugfixes, two rated low/medium severity and one very low, as well as fixes for two smaller miscompilations that are not security issues.\nOn the experimental side, the SSA CFG code generator gets a new stack shuffler that replaces the previous greedy algorithm with a planning one.\nThe release also adds support for the SLOTNUM opcode of the Amsterdam EVM version, removes two experimental features and adds deprecation warnings for...Read moreMisordered Named Parameters in require with Custom Errors BugPosted by Solidity Team on September 10, 2026Security Alerts\nOn February 4, 2026, a bug in the IR-based code generator was reported by Carl from\nCantina Security through the Ethereum Foundation bug bounty program. The\nbug causes the arguments of a custom error passed to require using named-parameter syntax\nto be placed on the stack in call-site order rather than declaration order before they are\nABI-encoded.\n\nThe bug was introduced in Solidity 0.8.26, which added support for passing custom errors as\nthe second argument to require.\nSolidity 0.8.37 provides a fix.\n\nWe assigned the bug a severity...Read moreMemory Byte Array Element Delete Clears Whole Word BugPosted by Solidity Team on September 10, 2026Security Alerts\nOn August 14, 2026, Shaheen Fazim reported a bug in the Solidity code generator through the Ethereum Foundation's bug bounty program.\nWhen delete is applied to an element of a bytes array located in memory, the generated code writes 32 zero bytes starting at that element instead of clearing only the element.\nThis also clears up to 31 of the bytes that follow it, either elsewhere in the same array or, when the deleted element sits near the end of the array,...Read moreUnsound Spill In Mutual Recursion BugPosted by Solidity Team on July 9, 2026Security Alerts\nOn May 11, 2026, clonker from the Solidity team discovered a bug in the Yul optimizer's call graph analysis.\nThe bug resulted in mutually recursive functions being sometimes misclassified as non-recursive, and therefore not being excluded from the memory spilling mechanism that is incompatible with recursive functions.\nThe mechanism relocates local variables to fixed memory offsets to work around the EVM's stack depth limit and would cause the spilled variables to be shared between all invocations of the same function.\n\nWe assign this...Read moreSolidity 0.8.36 Release AnnouncementPosted by Solidity Team on July 9, 2026Releases\nSolidity v0.8.36 is now available.\n\nThe release includes two security fixes, both of medium severity.\nOn the experimental side, the SSA-form code generator introduced in 0.8.35 gains stack-to-memory spilling, which effectively solves stack-too-deep on that backend.\nThe experimental EOF backend is also removed; it had been obsolete since EOF was rejected for inclusion in the Fusaka network upgrade.\n\nImportant Bugfixes\n\nStack-to-memory mover can mistakenly apply spilling to recursive functions.**\n A flaw in how the Yul optimizer detects call cycles could misclassify functions...Read moreInheritance Order Reversal On Storage End Warning BugPosted by Solidity Team on July 9, 2026Security Alerts\nOn June 8, 2026, clonker from the Solidity team discovered a bug in the analysis phase of the Solidity compiler.\nThe bug manifests when the compiler emits Warning 3495 about a custom storage layout being placed too close to the end of storage.\nThe implementation of said warning reverses the C3-linearized list of base contracts on the contract being checked.\nBecause this linearization drives inheritance-dependent decisions throughout the rest of the compiler, the reversal can lead to miscompilations as well as internal compiler...Read morePattern Matching in Core SolidityPosted by Solidity Team on May 5, 2026Announcements\nSmart contracts often need to handle values that come in several variants: a\npayment might be native ETH, an ERC20 transfer, or an NFT transfer; an auction\ncan be not-started, active, ended, or cancelled. Each variant needs different\nhandling, and the logic for that handling tends to be scattered across many\nfunctions. When a developer adds a new variant and forgets to update one of\nthose functions, the compiler says nothing. Once deployed, that oversight can\ncost real money to find and fix.\n\nCore Solidity's algebraic data...Read moreSolidity 0.8.35 Release AnnouncementPosted by Solidity Team on April 29, 2026Releases\nWe are excited to announce the release of the Solidity Compiler v0.8.35!\n\nThis release introduces a new builtin, erc7201, that computes the base slot of an ERC-7201 namespaced storage layout from its namespace string.\nIt also formalizes how experimental features are exposed to users: in-development functionality is now gated behind a new top-level --experimental flag, with a documented lifecycle and a canonical list of which features are currently considered experimental.\nThe first major code-generation feature shipped under this new lifecycle is an experimental...Read moreSolidity Developer Survey 2025 ResultsPosted by Solidity Team on April 15, 2026Announcements\nThe Solidity Developer Survey 2025, our sixth annual survey, collected 1,095 responses from developers across 87 countries. Thank you to everyone who participated. This post covers the key findings. For the complete data, see the interactive results page.\n\nWho responded\n\nWhere do you live?\n\n70% of respondents are smart contract developers. 12% are auditors or security experts. 18% identified as students. Half of all respondents have two years or less of Solidity experience, and 49% use Solidity daily.\n\nThe top three countries are India...Read moreTransient Storage Clearing Helper Collision BugPosted by Solidity Team on February 18, 2026Security Alerts\nOn 2026-02-11, a bug in the Solidity code generator was reported by Hexens.\nThe bug affects compiler versions 0.8.28 through 0.8.33 when using the IR pipeline.\nWhen a contract clears both a persistent and a transient storage variable of the same type, the compiler will emit the wrong opcode (sstore instead of tstore, or vice versa) for one of these operations, because the generated Yul helper functions share the same name and one overwrites the other.\n\nWe assign this bug a severity of...Read moreOlder posts","tokens":1783,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262372228,"hash":"5bcdf1b5b1470bf303b7b69566125785ca6c5f88"}
{"url":"https://dev-forum.pyth.network/t/action-required-pyth-pro-history-api-auth-required-starting-july-24/808/2","domain":"dev-forum.pyth.network","title":"Action Required: Pyth Pro History API Auth Required Starting July 24 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 8\n\n 2 / 2\n\n Jul 12\n\n Jul 13\n\n post by Aditya520 on Jul 8\n\n Aditya520\n\n Hey everyone,\nStarting July 24, 2026, the following Pyth Pro History API endpoints will require API key authentication:\n\nGET /v1/{channel}/price\nGET /v1/{channel}/history\nPOST /v1/price\n\nAPI key authentication is already supported in production today. Please update your requests to include:\nhttp\nAuthorization: Bearer <PYTH PRO API KEY>\n\nIf you call these endpoints from a browser or frontend app, do not expose your API key client-side. The recommended setup is to route requests through your own backend or proxy.\nFor frontend apps that need a client-safe option and do not want to run their own proxy, we expect JWT-based authentication to be available around July 10.\nUnauthenticated access to these endpoints will be disabled on July 24.\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Quick update for teams using these endpoints from a browser/frontend:\nThe preferred setup is still to keep your Pyth Pro API key server-side, behind your own backend or proxy. Please don’t expose the API key directly in client-side code.\nFor teams that need a frontend-safe option and don’t want to route every request through their own proxy, the JWT auth flow is now available here:\n\nThe basic flow is:\n\nYour browser client asks your backend for a JWT.\nYour backend calls POST /auth/token using your secret Pyth Pro API key.\nYour backend returns the JWT to the browser client.\nThe browser client uses that JWT as a bearer token:\n\nAuthorization: Bearer _*_\n\nDocs: Frontend Authentication | Pyth Developer Hub\nExample app: pyth-examples/pro/frontend-jwt-auth at main · pyth-network/pyth-examples · GitHub\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Pyth Pro Proxy API\n\n Announcements\n\n 0\n\n 74\n\n Feb 11\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Powered by Discourse","tokens":1475,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262373078,"hash":"4aca4130ad297197490ed79fd99382c9be09dc7f"}
{"url":"https://dev-forum.pyth.network/t/pyth-pro-proxy-api/516/1","domain":"dev-forum.pyth.network","title":"Pyth Pro Proxy API - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Pyth Pro Proxy API \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 11\n\n 1 / 1\n\n Feb 11\n\n Feb 11\n\n post by Aditya520 on Feb 11\n\n Aditya520\n\n gm gm Pythians\nThe Pyth contributors are excited to announce the Pyth Pro Proxy API (Beta). A simplified way to stream real-time price data without authentication.\nWhat is the Proxy API?\nThe Proxy API gives developers instant access to Pyth Pro price feeds with zero setup friction: no API keys, no WebSocket handshakes, just clean HTTP endpoints.\nIt currently supports two endpoints:\n\nMethod\nPath\nDescription\n\nGET\n/v1/latest_price\nFetch latest price for given feed IDs\n\nGET\n/v1/stream\nStream continuous price updates (SSE)\n\nHow fast is it?\nThe Proxy streams price updates every 200ms with only 400ms of delay. It makes it ideal for building responsive frontends, dashboards, monitoring tools, and rapid prototyping.\nGetting Started\nGetting prices is as simple as a single HTTP call:\n# Latest price\nhttps://pyth-lazer-proxy-3.dourolabs.app/v1/latest_price?price_feed_ids=1&price_feed_ids=2\n\n# SSE stream\nhttps://pyth-lazer-proxy-3.dourolabs.app/v1/stream?price_feed_ids=1&price_feed_ids=2\n\nFull API docs: https://pyth-lazer-proxy-3.dourolabs.app/docs/\n\n Note: This service is currently in beta and is not meant for production use. Interfaces, URLs, and availability may change without notice. For production workloads, use the WebSocket API or REST API.\n\nWho is this for?\n\nDevelopers who want to prototype quickly without managing access tokens.\n\nTeams building price dashboards or monitoring tools.\n\nAnyone exploring Pyth Pro before committing to a full integration.\n\nResources \n\nProxy API Docs\n\nExamples Repository\n\nPrice Feed IDs\n\nTry it out and let us know what you think! What are you building with Pyth Pro? Drop your feedback below\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 191\n\n Jul 13\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Introducing Petasos: A Lightweight Client for Real-Time Pyth Price Feeds in NodeJS\n\n Price Feeds\n\n 1\n\n 481\n\n Jul 2025\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Powered by Discourse","tokens":1504,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262383273,"hash":"ac56317664b3319b3f0acac2627836d44b0f511e"}
{"url":"https://specs.optimism.io/protocol/jovian/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Derivation\n\nTable of Contents\n\nActivation Block Rules\nNetwork Upgrade Transactions\n\nL1Block Deployment\nL1Block Proxy Update\nGasPriceOracle Deployment\nGasPriceOracle Proxy Update\nGasPriceOracle Enable Jovian\n\nActivation Block Rules\nThe first block with a timestamp at or after the Jovian activation time is considered the Jovian activation block.\nTo not modify or interrupt the system behavior regarding gas computations, the activation block must not include any\nnon-deposit transactions. Sequencer must enforce this by setting noTxPool to true in the payload attributes. This\nrule must be checked during derivation at the batch verification stage, and if the batch for the activation block\ncontains any transactions, it must be DROPped.\nOn the Jovian activation block, in addition to the L1 attributes deposit and potentially any user deposits from L1, a\nset of deposit transaction-based upgrade transactions are deterministically generated by the derivation pipeline in the\nfollowing order:\n\nL1 Attributes Transaction (still calling the old L1Block.setL1BlockValuesIsthmus())\nUser deposits from L1 (if any)\nNetwork Upgrade Transactions\n\nL1Block deployment\nUpdate L1Block Proxy ERC-1967 Implementation\nGasPriceOracle deployment\nUpdate GasPriceOracle Proxy ERC-1967 Implementation\nGasPriceOracle Enable Jovian call\n\nThe network upgrade transactions are specified in the next section.\nNetwork Upgrade Transactions\nThe upgrade transaction details below are based on the monorepo at commit hash\nb3299e0ddb55442e6496512084d16c439ea2da77, and will be updated once a contracts release is made.\nL1Block Deployment\n\nThe L1Block contract is deployed.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000006\nto: null\nmint: 0\nvalue: 0\nnonce: 0\ngasLimit: 447315\ndata: 0x0x608060405234801561001057600080... (full bytecode)\nsourceHash: 0x98faf23b9795967bc0b1c543144739d50dba3ea40420e77ad6ca9848dbfb62e8,\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Jovian: L1Block Deployment\"\n\nThis results in the Jovian L1Block contract being deployed to\n0x3Ba4007f5C922FBb33C454B41ea7a1f11E83df2C, to verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000006\nComputed Address: 0x3Ba4007f5C922FBb33C454B41ea7a1f11E83df2C\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Jovian: L1Block Deployment\"))\n# 0x98faf23b9795967bc0b1c543144739d50dba3ea40420e77ad6ca9848dbfb62e8\n\nVerify data:\ngit checkout 773798a67678ab28c3ef7ee3405f25c04616af19\nmake build-contracts\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json\n\nThis transaction MUST deploy a contract with the following code hash\n0x5f885ca815d2cf27a203123e50b8ae204fdca910b6995d90b2d7700cbb9240d1.\nTo verify the code hash:\ngit checkout 773798a67678ab28c3ef7ee3405f25c04616af19\nmake build-contracts\ncast k $(jq -r \".deployedBytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json)\n\nL1Block Proxy Update\nThis transaction updates the L1Block Proxy ERC-1967\nimplementation slot to point to the new L1Block deployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x4200000000000000000000000000000000000015 (L1Block Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe60000000000000000000000003ba4007f5c922fbb33c454b41ea7a1f11e83df2c\nsourceHash: 0x08447273a4fbce97bc8c515f97ac74efc461f6a4001553712f31ebc11288bad2\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Jovian: L1Block Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x3Ba4007f5C922FBb33C454B41ea7a1f11E83df2C)\n# 0x3659cfe60000000000000000000000003ba4007f5c922fbb33c454b41ea7a1f11e83df2c\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Jovian: L1Block Proxy Update\"))\n# 0x08447273a4fbce97bc8c515f97ac74efc461f6a4001553712f31ebc11288bad2\n\nGasPriceOracle Deployment\n\nThe GasPriceOracle contract is deployed.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000007\nto: null\nmint: 0\nvalue: 0\nnonce: 0\ngasLimit: 1750714\ndata: 0x0x608060405234801561001057600080... (full bytecode)\nsourceHash: 0xd939cca6eca7bd0ee0c7e89f7e5b5cf7bf6f7afe7b6966bb45dfb95344b31545,\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Jovian: GasPriceOracle Deployment\"\n\nThis results in the Jovian GasPriceOracle contract being deployed to\n0x4f1db3c6AbD250ba86E0928471A8F7DB3AFd88F1, to verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000007\nComputed Address: 0x4f1db3c6AbD250ba86E0928471A8F7DB3AFd88F1\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Jovian: GasPriceOracle Deployment\"))\n# 0xd939cca6eca7bd0ee0c7e89f7e5b5cf7bf6f7afe7b6966bb45dfb95344b31545\n\nVerify data:\ngit checkout 773798a67678ab28c3ef7ee3405f25c04616af19\nmake build-contracts\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json\n\nThis transaction MUST deploy a contract with the following code hash\n0xe9fc7c96c4db0d6078e3d359d7e8c982c350a513cb2c31121adf5e1e8a446614.\nTo verify the code hash:\ngit checkout 773798a67678ab28c3ef7ee3405f25c04616af19\nmake build-contracts\ncast k $(jq -r \".deployedBytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json)\n\nGasPriceOracle Proxy Update\nThis transaction updates the GasPriceOracle Proxy ERC-1967\nimplementation slot to point to the new GasPriceOracle deployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x420000000000000000000000000000000000000F (GasPriceOracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe60000000000000000000000004f1db3c6abd250ba86e0928471a8f7db3afd88f1\nsourceHash: 0x46b597e2d8346ed7749b46734074361e0b41a0ab9af7afda5bb4e367e072bcb8\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Jovian: GasPriceOracle Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x4f1db3c6AbD250ba86E0928471A8F7DB3AFd88F1)\n# 0x3659cfe60000000000000000000000004f1db3c6abd250ba86e0928471a8f7db3afd88f1\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Jovian: GasPriceOracle Proxy Update\"))\n# 0x46b597e2d8346ed7749b46734074361e0b41a0ab9af7afda5bb4e367e072bcb8\n\nGasPriceOracle Enable Jovian\nThis transaction informs the GasPriceOracle to start using the Jovian operator fee formula.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account)\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 90,000\ndata: 0xb3d72079\nsourceHash: 0xe836db6a959371756f8941be3e962d000f7e12a32e49e2c9ca42ba177a92716c,\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Jovian: Gas Price Oracle Set Jovian\"\n\nVerify data:\ncast sig \"setJovian()\"\n# 0xb3d72079\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Jovian: Gas Price Oracle Set Jovian\"))\n# 0xe836db6a959371756f8941be3e962d000f7e12a32e49e2c9ca42ba177a92716c","tokens":1891,"squid":"ink-governance","role":"Council Listener","at":1791262402093,"hash":"8f2fa878387c04e19e8506d3291e834d999a26aa"}
{"url":"https://dev-forum.pyth.network/t/action-required-pyth-pro-history-api-auth-required-starting-july-24/808","domain":"dev-forum.pyth.network","title":"Action Required: Pyth Pro History API Auth Required Starting July 24 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Action Required: Pyth Pro History API Auth Required Starting July 24 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 8\n\n 1 / 2\n\n Jul 7\n\n Jul 13\n\n post by Aditya520 on Jul 8\n\n Aditya520\n\n Hey everyone,\nStarting July 24, 2026, the following Pyth Pro History API endpoints will require API key authentication:\n\nGET /v1/{channel}/price\nGET /v1/{channel}/history\nPOST /v1/price\n\nAPI key authentication is already supported in production today. Please update your requests to include:\nhttp\nAuthorization: Bearer <PYTH PRO API KEY>\n\nIf you call these endpoints from a browser or frontend app, do not expose your API key client-side. The recommended setup is to route requests through your own backend or proxy.\nFor frontend apps that need a client-safe option and do not want to run their own proxy, we expect JWT-based authentication to be available around July 10.\nUnauthenticated access to these endpoints will be disabled on July 24.\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Quick update for teams using these endpoints from a browser/frontend:\nThe preferred setup is still to keep your Pyth Pro API key server-side, behind your own backend or proxy. Please don’t expose the API key directly in client-side code.\nFor teams that need a frontend-safe option and don’t want to route every request through their own proxy, the JWT auth flow is now available here:\n\nThe basic flow is:\n\nYour browser client asks your backend for a JWT.\nYour backend calls POST /auth/token using your secret Pyth Pro API key.\nYour backend returns the JWT to the browser client.\nThe browser client uses that JWT as a bearer token:\n\nAuthorization: Bearer _*_\n\nDocs: Frontend Authentication | Pyth Developer Hub\nExample app: pyth-examples/pro/frontend-jwt-auth at main · pyth-network/pyth-examples · GitHub\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n [Deprecation Notice] Pyth Benchmarks`/v1/shims/tradingview` Endpoints — Sunset August 26, 2026\n\n Benchmarks(Historic Prices)\n\n announcements\n\n 0\n\n 81\n\n Aug 12\n\n Pyth Pro Proxy API\n\n Announcements\n\n 0\n\n 75\n\n Feb 11\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Powered by Discourse","tokens":1493,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262403775,"hash":"a015d1409379e5812821187e24223b49dae206bf"}
{"url":"https://specs.optimism.io/protocol/holocene/system-config.html","domain":"specs.optimism.io","title":"System Config - OP Stack Specification","text":"System Config\n\nTable of Contents\n\nOverview\n\nConfigUpdate\nInitialization\nModifying EIP-1559 Parameters\nInterface\n\nEIP-1559 Params\n\nsetEIP1559Params\neip1559Elasticity\neip1559Denominator\n\nOverview\nThe SystemConfig is updated to allow for dynamic EIP-1559 parameters.\nConfigUpdate\nWhen the configuration is updated, a ConfigUpdate event\nMUST be emitted with the following parameters:\nversionupdateTypedataUsage\nuint256(0)uint8(4)abi.encode((uint256(_denominator) << 32) | _elasticity)Modifies the EIP-1559 denominator and elasticity\n\nNote that the above encoding is the format emitted by the SystemConfig event, which differs from the format in extraData\nfrom the block header.\nInitialization\nThe following actions should happen during the initialization of the SystemConfig:\n\nemit ConfigUpdate.BATCHER\nemit ConfigUpdate.FEE_SCALARS\nemit ConfigUpdate.GAS_LIMIT\nemit ConfigUpdate.UNSAFE_BLOCK_SIGNER\n\nIntentionally absent from this is emit ConfigUpdate.EIP_1559_PARAMS.\nAs long as these values are unset, the default values will be used.\nRequiring 1559 parameters to be set during initialization would add a strict requirement\nthat the L2 hardforks before the L1 contracts are upgraded, and this is complicated to manage in a\nworld of many chains.\nModifying EIP-1559 Parameters\nA new SystemConfig UpdateType is introduced that enables the modification of\nEIP-1559 parameters. This allows for the chain\noperator to modify the BASE_FEE_MAX_CHANGE_DENOMINATOR and the ELASTICITY_MULTIPLIER.\nInterface\nEIP-1559 Params\nsetEIP1559Params\nThis function MUST only be callable by the chain governor.\nfunction setEIP1559Params(uint32 _denominator, uint32 _elasticity)\n\nThe _denominator and _elasticity MUST be set to values greater to than 0.\nIt is possible for the chain operator to set EIP-1559 parameters that result in poor user experience.\neip1559Elasticity\nThis function returns the currently configured EIP-1559 elasticity.\nfunction eip1559Elasticity()(uint32)\n\neip1559Denominator\nThis function returns the currently configured EIP-1559 denominator.\nfunction eip1559Denominator()(uint32)","tokens":520,"squid":"ink-governance","role":"Council Listener","at":1791262425368,"hash":"e108524b4f97bd32bc1ef79300a3ecb12ba8b4c1"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18213843096091-Using-Arbitrum-s-traditional-bridge-to-move-funds-to-Mainnet","domain":"support.arbitrum.io","title":"Using Arbitrum's traditional bridge to move funds to Mainnet – Arbitrum Foundation","text":"If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fast exit liquidity provider like Hop, Connext, Across, Celer, or Maker. Why do I have to wait 8 days?This is how all optimistic rollups work. Optimistic rollups use something called fraud proofs in order to keep participants in the network honest. There is a \"challenge period\" for these proofs. When one party submits a claim about the state of the chain, another party has ~8 days to challenge that claim. If you'd like to read more about the technical details of Arbitrum, see Inside Arbitrum.If you're more of a visual and auditory learner, watch our videos about challenges and proofs.  More Resources:1 - (Youtube) Multi round Fraud Proofs: What, How, and Why.2 - (Youtube) Challenge Protocol\n\n Recently viewed articlesWhy are there 2 different USDC's on Arbitrum?You need ETH to power transactionsI've sent $ARB from a CEX to my wallet but I can't see itHow can I add Arbitrum network to my wallet?\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n How can I add Arbitrum network to my wallet?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Godfrey brai\n\n 2 years ago\n\n I have waited for more than 12 days I still can find my ethPlease help me rectify \n\n 0\n\n Please sign in to leave a comment.","tokens":369,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262428776,"hash":"3918081b9da764172c622317b7d825600e78dd52"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19478231243035-Why-do-I-have-0-voting-power-even-though-I-have-ARB","domain":"support.arbitrum.io","title":"Why do I have 0 voting power even though I have $ARB? – Arbitrum Foundation","text":"Here's a full explanation of how voting and proposals work. Keep in mind that there are 2 types of proposals: 1 - Proposals are first submitted to the ArbitrumDAO governance forum for community discussion and debate. These forum submissions are usually accompanied by a Snapshot poll that gauges the community's interest in the proposal. For this, you just need to go to Tally and delegate the voting power to yourself (before any proposal goes live, otherwise you still won't be able to vote). 2 - If the proposal passes the temperature check, it will move on to an on-chain vote facilitated by Tally. For this phase, you'll need to delegate your voting power. Either to an entity that is already a delegate or to yourself. Basically there's two ways to participate in ‌governance: either you do it yourself by voting on every proposal (snapshot and tally) or through the entity to which you delegated your voting power. In this last case, they only need to vote on Tally because that's the final proposal before a decision is executed or not. We would advise to take a look at this: https://docs.arbitrum.foundation/how-tos/vote-dao-proposals#proposals-in-the-temperature-check-stage\n\n Recently viewed articlesUsing Arbitrum's traditional bridge to move funds to MainnetWhy are there 2 different USDC's on Arbitrum?You need ETH to power transactionsI've sent $ARB from a CEX to my wallet but I can't see itHow can I add Arbitrum network to my wallet?\n\n Related articles\n\n Why are there 2 different USDC's on Arbitrum?\n\n You need ETH to power transactions\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n How can I add Arbitrum network to my wallet?\n\n ARB tokens sent to Arbitrum Foundation\n\n Please sign in to leave a comment.","tokens":436,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262442585,"hash":"78d3ee9e68ef3e901601cf66e756f8be4839331b"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBumVr6QEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBvZDSG3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJJL2hjL2VuLWdiL2FydGljbGVzLzE4MjEzODU0Njg0Njk5LVlvdS1uZWVkLUVUSC10by1wb3dlci10cmFuc2FjdGlvbnMGOwhUOglyYW5raQc%3D--21ed4ca83679ce69c2a8e07988f694c0db6340c2","domain":"support.arbitrum.io","title":"You need ETH to power transactions – Arbitrum Foundation","text":"When moving funds from Mainnet (L1) to Arbitrum (L2), you'll need ETH in your Arbitrum wallet.Even if you want only to use another, non-ETH, token, you will still need a small amount of ETH in your wallet on the Arbitrum network. This is because all Arbitrum transactions are powered by ETH. \nETH is the currency used for gas fees. Arbitrum gas fees go to Arbitrum validators to track chain state and execute transactions. This is actually an estimated fee; if the true fee is lower, then you will be refunded.\n\n Recently viewed articlesWhy do I have 0 voting power even though I have $ARB?Using Arbitrum's traditional bridge to move funds to MainnetWhy are there 2 different USDC's on Arbitrum?I've sent $ARB from a CEX to my wallet but I can't see itHow can I add Arbitrum network to my wallet?\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Please sign in to leave a comment.","tokens":275,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262453868,"hash":"1d9902364a684efc0a5eb89c596b9918fdb85858"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJvVrcCQEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBumVr6QEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJAL2hjL2VuLWdiL2FydGljbGVzLzE4MjEzODkzOTUyOTIzLUJyaWRnaW5nLW92ZXItYS1uZXctdG9rZW4GOwhUOglyYW5raQg%3D--bcc72094827c5242eaffd9e4273d9335eae06515","domain":"support.arbitrum.io","title":"Bridging over a new token – Arbitrum Foundation","text":"When you are bridging over a new token, that action will require an approval transaction fee.\nThis goes to Ethereum block producers, not to Arbitrum.\nThe approval transaction only applies once per token, per wallet address.This means that the next time you want to bridge this token over, you will not have to pay for an approval transaction.\nHowever, if you want to bridge the same token over from a new wallet address, you'll have to pay for the approval transaction again.\nYour wallet will prompt you to complete this transaction.\nAfter your transaction has been approved, you will be prompted to pay the standard deposit fee.\nYou will pay a deposit transaction every time you want to bridge over funds. The deposit transaction goes partly to Ethereum and partly to the Arbitrum node validators.\n\n Recently viewed articlesYou need ETH to power transactionsWhy do I have 0 voting power even though I have $ARB?Using Arbitrum's traditional bridge to move funds to MainnetWhy are there 2 different USDC's on Arbitrum?I've sent $ARB from a CEX to my wallet but I can't see it\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Skipping the bridge\n\n Why do I need ETH to use the Arbitrum network?\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n You need ETH to power transactions\n\n Please sign in to leave a comment.","tokens":340,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262463783,"hash":"a3862983922b6f2bd5a66cb950e76f5ba7eeb9f4"}
{"url":"https://specs.optimism.io/protocol/regolith/overview.html","domain":"specs.optimism.io","title":"Regolith - OP Stack Specification","text":"Regolith\n\nTable of Contents\n\nOverview\n\nOverview\nThe Regolith upgrade, named after a material best described as \"deposited dust on top of a layer of bedrock\",\nimplements minor changes to deposit processing, based on reports of the Sherlock Audit-contest and findings in\nthe Bedrock Optimism Goerli testnet.\nSummary of changes:\n\nThe isSystemTx boolean is disabled, system transactions now use the same gas accounting rules as regular deposits.\nThe actual deposit gas-usage is recorded in the receipt of the deposit transaction,\nand subtracted from the L2 block gas-pool.\nUnused gas of deposits is not refunded with ETH however, as it is burned on L1.\nThe nonce value of the deposit sender account, before the transaction state-transition, is recorded in a new\noptional field (depositNonce), extending the transaction receipt (i.e. not present in pre-Regolith receipts).\nThe recorded deposit nonce is used to correct the transaction and receipt metadata in RPC responses,\nincluding the contractAddress field of deposits that deploy contracts.\nThe gas and depositNonce data is committed to as part of the consensus-representation of the receipt,\nenabling the data to be safely synced between independent L2 nodes.\nThe L1-cost function was corrected to more closely match pre-Bedrock behavior.\n\nThe deposit specification specifies the deposit changes of the Regolith upgrade in more detail.\nThe execution engine specification specifies the L1 cost function difference.\nThe Regolith upgrade uses a L2 block-timestamp activation-rule, and is specified in both the\nrollup-node (regolith_time) and execution engine (config.regolithTime).","tokens":407,"squid":"ink-governance","role":"Council Listener","at":1791262468755,"hash":"0051b3ea002e60bf4fa30abaed36658d41431e1b"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvSpb2QEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJvVrcCQEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJjL2hjL2VuLWdiL2FydGljbGVzLzE4MjEzODQzMDk2MDkxLVVzaW5nLUFyYml0cnVtLXMtdHJhZGl0aW9uYWwtYnJpZGdlLXRvLW1vdmUtZnVuZHMtdG8tTWFpbm5ldAY7CFQ6CXJhbmtpBg%3D%3D--d5309a567a30c4d2535d8667b836cd86eaf93234","domain":"support.arbitrum.io","title":"Using Arbitrum's traditional bridge to move funds to Mainnet – Arbitrum Foundation","text":"If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fast exit liquidity provider like Hop, Connext, Across, Celer, or Maker. Why do I have to wait 8 days?This is how all optimistic rollups work. Optimistic rollups use something called fraud proofs in order to keep participants in the network honest. There is a \"challenge period\" for these proofs. When one party submits a claim about the state of the chain, another party has ~8 days to challenge that claim. If you'd like to read more about the technical details of Arbitrum, see Inside Arbitrum.If you're more of a visual and auditory learner, watch our videos about challenges and proofs.  More Resources:1 - (Youtube) Multi round Fraud Proofs: What, How, and Why.2 - (Youtube) Challenge Protocol\n\n Recently viewed articlesBridging over a new tokenYou need ETH to power transactionsWhy do I have 0 voting power even though I have $ARB?Why are there 2 different USDC's on Arbitrum?I've sent $ARB from a CEX to my wallet but I can't see it\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n How can I add Arbitrum network to my wallet?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Godfrey brai\n\n 2 years ago\n\n I have waited for more than 12 days I still can find my ethPlease help me rectify \n\n 0\n\n Please sign in to leave a comment.","tokens":378,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262473625,"hash":"87aabcd630117109bb14b20dc21120c8ea361cd4"}
{"url":"https://governance.aave.com/t/temp-check-deploy-aave-v4-on-avalanche/24981","domain":"governance.aave.com","title":"[Temp Check] Deploy Aave V4 on Avalanche - Governance / New Market - Aave","text":"[Temp Check] Deploy Aave V4 on Avalanche \n\n GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 4\n min\n\n May 27\n\n 1 / 8\n\n May 27\n\n Aug 28\n\n post by AaveLabs on May 27\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n V4_AVAX (2)2880×1542 263 KB\nSummary\nThis proposal seeks community feedback on deploying Aave V4 on Avalanche, including a dedicated RWA hub.\nAvalanche has committed up to $15M in incentives, tied to growth KPIs, to support Aave V4 growth. Deploying V4 on Avalanche would position Aave as one of the first major lending protocols to bring V4’s Hub and Spoke architecture to a large existing DeFi ecosystem with dedicated launch support.\nMotivation\nAave V4 is entering its next growth phase. The initial deployment on Ethereum proved the Hub and Spoke model in production. Expanding into networks with existing DeFi demand, active Aave usage, and a credible path to protocol revenue is the natural next step to growing Aave V4.\nAvalanche is a strong candidate for that expansion. Aave already has a live market on the network; V4 would not be entering a new network. Avalanche users are already familiar with supplying, borrowing, incentives, and Aave’s role as a core liquidity venue. The deployment will also include a dedicated RWA hub, extending Aave’s institutional product surface into one of the most active RWA ecosystems in DeFi.\nThe $15M incentive commitment - tied to V4 growth milestones - gives the deployment a direct growth catalyst from launch. Dedicated ecosystem support will attract liquidity, drive borrow activity, support integrations, and accelerate V4 adoption. V4 would launch into an ecosystem with existing Aave distribution, active DeFi liquidity, and incentives specifically aligned around growing the new architecture. That combination gives Avalanche a credible path to become one of the first major V4 growth markets outside Ethereum.\nA successful deployment would expand V4 TVL, increase protocol revenue, attract new integrations, and establish a repeatable expansion model for future V4 deployments built around existing demand and ecosystem support.\nSpecification\nIf governance supports this Temp Check, the next phase would prepare an ARFC for deploying Aave V4 on Avalanche.\nThe ARFC would include the proposed initial Hub and Spoke configuration, supported tokens, oracle configuration, risk parameters, caps, incentives structure, deployment contracts, and any required operational permissions.\nNext Steps\nGather community feedback on the proposed Aave V4 deployment on Avalanche.\nIf feedback is supportive, advance this proposal to ARFC.\nDisclaimer\nAave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche. Aave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is contributing this proposal as part of its approved scope of work in support of DAO operations.\nCopyright\nCopyright and related rights waived via CC0.\n\n 2\n\n read \n\n 4\n min\n\n post by simo on May 27\n\n post by MconnectDAO on May 27\n\n post by Mschmenk13 on May 31\n\n post by AaveLabs on Jun 3\n\n post by Abel189 on Jun 4\n\n post by CalBlockchain on Jun 5\n\n 3 months later\n\n post by evan_chevalier on Aug 28\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d\n\n [Temp Check] Deploy Aave V4 on Arc\n\n New Market\n\n 5\n\n 837\n\n Jun 7\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d","tokens":942,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262475867,"hash":"92896a91c655b872aca4133a804f020743bbf787"}
{"url":"https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901","domain":"ethresear.ch","title":"How to hard-fork to save most users' funds in a quantum emergency - Execution Layer Research - Ethereum Research","text":"How to hard-fork to save most users’ funds in a quantum emergency \n\n Execution Layer Research\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2024\n\n 1 / 39\n\n Mar 2024\n\n Mar 2025\n\n post by vbuterin on Mar 9, 2024\n\n vbuterin\n\n Suppose that it is announced tomorrow that quantum computers are available, and bad actors already have access to them and are able to use them to steal users’ funds. Preventing such a scenario is the goal of quantum-resistant cryptography (eg. Winternitz signatures, STARKs), and once account abstraction is in place, any user can switch to using a quantum-resistant signature scheme on their own schedule. But what if we don’t have that much time, and a sudden quantum transition happens long before that?\nI argue that actually, we are already well-positioned to make a pretty simple recovery fork to deal with such a situation. The blockchain would have to hard fork and users would have to download new wallet software, but few users would lose their funds.\nThe main challenge with quantum computers is as follows. An Ethereum address is defined as keccak(priv_to_pub(k))[12:], where k is the private key, and priv_to_pub is an elliptic curve multiplication to convert the privkey into a pubkey. With quantum computers, elliptic curve multiplications become invertible (because it’s a discrete-log problem), but hashes are still safe. If a user has not made any transactions with their account, then only the address is publicly visible and they are already safe. But if a user has made even one transaction, then the signature of that transaction reveals the public key, which in a post-quantum world allows revealing the private key. And so most users would be vulnerable.\nBut we can do much better. The key realization is that in practice, most users’ private keys are themselves the result of a bunch of hash calculations. Many keys are generated using BIP-32, which generates each address through a series of hashes starting from a master seed phrase. Many non-BIP-32 methods of key generation work similarly: eg. if a user has a brainwallet, it’s generally a series of hashes (or medium-hard KDF) applied to some passphrase.\nThis implies the natural structure of an EIP to hard-fork the chain to recover from a quantum emergency:\n\nRevert all blocks after the first block where it’s clear that large-scale theft is happening\nTraditional EOA-based transactions are disabled\nA new transaction type is added to allow transactions from smart contract wallets (eg. part of RIP-7560), if this is not available already\nA new transaction type or opcode is added by which you can provide a STARK proof which proves knowledge of (i) a private preimage x, (ii) a hash function ID 1 <= i < k from a list of k approved hash functions, and (iii) a public address A, such that keccak(priv_to_pub(hashes[i](x)))[12:] = A. The STARK also accepts as a public input the hash of a new piece of validation code for that account. If the proof passes, your account’s code is switched over to the new validation code, and you will be able to use it as a smart contract wallet from that point forward.\n\nFor gas efficiency reasons (after all, STARKs are big), we can allow the STARK to be a batch proof, proving N STARKs of the above type (it has to be a STARK-of-STARKs rather than a direct proof of multiple claims, because each user’s x needs to be kept private from the aggregator).\nThe infrastructure to implement a hard fork like this could in principle start to be built tomorrow, making the Ethereum ecosystem maximally ready in case a quantum emergency does actually come to pass.\n\n So you wanna Post-Quantum Ethereum transaction signature\n\n Tasklist for post-quantum ETH\n\n Post quantum TXs in The Verge\n\n Post-Quantum Threats to Ethereum Privacy\n\n Migration Strategies for EOAs under the Quantum Threat: Breakages, and Open Questions\n\n 9\n\n 6\n\n 4\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n post by irnb on Mar 9, 2024\n\n post by myaksetig on Mar 9, 2024\n\n post by pldd on Mar 9, 2024\n\n post by DogeProtocol on Mar 9, 2024\n\n post by nvmmonkey on Mar 9, 2024\n\n post by tanteikg on Mar 10, 2024\n\n post by ShaiW on Mar 10, 2024\n\n post by MaverickChow on Mar 10, 2024\n\n post by pldd on Mar 10, 2024\n\n post by corepool on Mar 10, 2024\n\n post by myaksetig on Mar 10, 2024\n\n post by domothy on Mar 11, 2024\n\n post by MaverickChow on Mar 11, 2024\n\n post by Mirror on Mar 12, 2024\n\n post by pa7x1 on Mar 13, 2024\n\n post by doctor-gonzo on Mar 14, 2024\n\n post by pldd on Mar 16, 2024\n\n 13 days later\n\n post by pldd on Mar 30, 2024\n\n 12 days later\n\n post by matthiasgeihs on Apr 12, 2024\n\n Load more posts below","tokens":1155,"squid":"ink-research","role":"Deep Scholar","at":1791262483403,"hash":"7a5ecfbda7ddac8aed3207d974c9bef6a40cfe4d"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJvwMxu3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBvSpb2QEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJdL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4MTMzMDc2MTIzLVdoeS13YWl0LTctZGF5cy10by1jbGFpbS1mdW5kcy13aGVuLWJyaWRnZS10by1FdGhlcmV1bQY7CFQ6CXJhbmtpBg%3D%3D--bef314fd8c8b74714ff14659a4eb6667f069e046","domain":"support.arbitrum.io","title":"Why wait 7 days to claim funds when bridge to Ethereum? – Arbitrum Foundation","text":"Whenever there are bridge transactions into the Ethereum mainnet using the official Arbitrum bridge, there is a mandatory 7-day waiting period for withdrawals and this is due to the bridge's security measures.The 7-day waiting period for withdrawals back to L1 (mainnet) on Arbitrum is a security measure designed to protect against fraud. This is because Arbitrum is an optimistic rollup, which means that transactions are initially processed without being verified. If someone tries to submit a fraudulent transaction, there is a 7-day window during which verifiers can submit a fraud proof. If a fraud proof is submitted, the transaction will be reversed and the fraudster will be penalized.\n\n Recently viewed articlesUsing Arbitrum's traditional bridge to move funds to MainnetBridging over a new tokenYou need ETH to power transactionsWhy do I have 0 voting power even though I have $ARB?Why are there 2 different USDC's on Arbitrum?\n\n Related articles\n\n Why are there 2 different USDC's on Arbitrum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Skipping the bridge\n\n You need ETH to power transactions\n\n Why do I need ETH to use the Arbitrum network?\n\n Please sign in to leave a comment.","tokens":303,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262487047,"hash":"aa97eb5349b627388288a86b631c15af3a182e32"}
{"url":"https://governance.aave.com/t/temp-check-deploy-aave-v4-on-avalanche/24981/1","domain":"governance.aave.com","title":"[Temp Check] Deploy Aave V4 on Avalanche - Governance / New Market - Aave","text":"[Temp Check] Deploy Aave V4 on Avalanche \n\n GovernanceNew Market\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 4\n min\n\n May 27\n\n 1 / 8\n\n May 27\n\n Aug 28\n\n post by AaveLabs on May 27\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n V4_AVAX (2)2880×1542 263 KB\nSummary\nThis proposal seeks community feedback on deploying Aave V4 on Avalanche, including a dedicated RWA hub.\nAvalanche has committed up to $15M in incentives, tied to growth KPIs, to support Aave V4 growth. Deploying V4 on Avalanche would position Aave as one of the first major lending protocols to bring V4’s Hub and Spoke architecture to a large existing DeFi ecosystem with dedicated launch support.\nMotivation\nAave V4 is entering its next growth phase. The initial deployment on Ethereum proved the Hub and Spoke model in production. Expanding into networks with existing DeFi demand, active Aave usage, and a credible path to protocol revenue is the natural next step to growing Aave V4.\nAvalanche is a strong candidate for that expansion. Aave already has a live market on the network; V4 would not be entering a new network. Avalanche users are already familiar with supplying, borrowing, incentives, and Aave’s role as a core liquidity venue. The deployment will also include a dedicated RWA hub, extending Aave’s institutional product surface into one of the most active RWA ecosystems in DeFi.\nThe $15M incentive commitment - tied to V4 growth milestones - gives the deployment a direct growth catalyst from launch. Dedicated ecosystem support will attract liquidity, drive borrow activity, support integrations, and accelerate V4 adoption. V4 would launch into an ecosystem with existing Aave distribution, active DeFi liquidity, and incentives specifically aligned around growing the new architecture. That combination gives Avalanche a credible path to become one of the first major V4 growth markets outside Ethereum.\nA successful deployment would expand V4 TVL, increase protocol revenue, attract new integrations, and establish a repeatable expansion model for future V4 deployments built around existing demand and ecosystem support.\nSpecification\nIf governance supports this Temp Check, the next phase would prepare an ARFC for deploying Aave V4 on Avalanche.\nThe ARFC would include the proposed initial Hub and Spoke configuration, supported tokens, oracle configuration, risk parameters, caps, incentives structure, deployment contracts, and any required operational permissions.\nNext Steps\nGather community feedback on the proposed Aave V4 deployment on Avalanche.\nIf feedback is supportive, advance this proposal to ARFC.\nDisclaimer\nAave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche. Aave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is contributing this proposal as part of its approved scope of work in support of DAO operations.\nCopyright\nCopyright and related rights waived via CC0.\n\n 2\n\n read \n\n 4\n min\n\n post by simo on May 27\n\n simo\n\n Aave Labs-Technical SP\n\n Supporting this Temp Check.\nA few points worth highlighting from a growth perspective.\nAvalanche has been one of Aave V3’s most consistent deployments since launch.\nThe user base is mature, the main integrations are already in place, and the chain has been building a strong distribution for stablecoins and especially for RWAs.\nV4 is entering a ready environment where it inherits an active market and an existing liquidity, which materially reduces execution risk.\nThe $15M incentive commitment tied to growth KPIs is the right structure.\nKPI-linked incentives align both sides on outcomes (TVL, borrow volume, revenue contribution) rather than paying for launch optics. It also gives the DAO a transparent framework to measure execution post-deployment.\nPersonally, I believe that the dedicated RWA hub is the most strategically relevant part of this proposal. Avalanche is one of the most active institutional and RWA environments in DeFi today, and V4’s Hub and Spoke design is well suited to isolating institutional collateral and risk parameters from the main liquidity pool.\nThis positions Aave to capture RWA borrow demand at scale without compromising the core market.\nIf this proposal advances, it also sets a useful template for future V4 expansion: deploy into ecosystems where Aave already has demand and where the host network is willing to back growth with aligned, KPI-based incentives.\nLooking forward to community feedback ahead of the ARFC.\n\n post by MconnectDAO on May 27\n\n MconnectDAO\n\n Thanks for putting this temp check together and for sharing the initial deployment + incentives vision for Aave V4 on Avalanche. I broadly like the direction, especially the idea of pairing a V4 deployment with a dedicated RWA hub on a chain that already has DeFi traction.\nAt the same time, I feel the two core “selling points” of this temp check – the incentive program (up to 15M) and the RWA hub – are still a bit too high‑level to properly evaluate from a governance and risk perspective. I’d really appreciate some additional clarity on a few points:\n\nIncentives design & accountability\n\nWhen you say “up to 15M in incentives tied to growth KPIs”, could you share more detail on:\n\nWhat are the concrete KPIs you have in mind (TVL, borrows, active users, protocol revenue, integrations, something else)?\n\nHow will these be measured and by whom, and over what timeframes?\n\nWhat does “up to” mean in practice – is there a base commitment plus performance‑based tranches, or a fully conditional structure?\n\nIn a downside scenario where the KPIs are not met, what are the guardrails?\n\nDo incentives automatically taper/stop, or would that require another governance touchpoint?\n\nIs there a plan for periodic public reporting so the DAO can track whether the program is delivering sustainable usage vs just short‑term incentive‑driven spikes?\n\nRWA hub scope & risk framework\n\nThe idea of a dedicated RWA hub on Avalanche is interesting, but right now the scope feels quite open‑ended.\n\nAre there specific RWA verticals or partners you already have in mind, or is this more of a generic “RWA‑ready” deployment?\n\nHow do you envision eligibility criteria for RWA issuers, whitelisting, and ongoing monitoring (especially around legal, credit, and operational risks)?\n\nIt would help a lot to understand how this proposed RWA hub relates to existing or planned RWA efforts on Ethereum for example, are there shared standards, oracles, or risk methodologies you intend to reuse, so that the DAO is not managing completely fragmented frameworks across chains?\n\nHigh‑level risk and rollout guardrails\nEven at the temp check stage, it might be useful to outline some initial design guardrails, such as:\n\nStarting with a conservative, blue‑chip asset set and tight caps, then expanding based on observed performance.\n\nA rough phased rollout (e.g., guarded launch → monitored expansion → full rollout) and an initial review window (e.g., after 6–12 months) to reassess incentives, parameters, and RWA scope.\n\nOverall, I’m supportive of exploring Aave V4 on Avalanche with a strong growth and RWA thesis, but I think the DAO would benefit from a bit more specificity around incentives design, measurement/accountability, and the RWA risk framework before moving to the next stage. Any additional detail you can share on these fronts would make it much easier for delegates to form a well‑informed view.\n\n post by Mschmenk13 on May 31\n\n Mschmenk13\n\n Hey Everyone,\nMy name is Matt Schmenk, and I lead DeFi at Ava Labs, the servicing firm behind the Avalanche blockchain network. I support this temp check and am excited to grow both v4 and a dedicated RWA Hub similar to Horizon. One of our main focuses at Ava Labs is the growth and adoption of RWAs within our ecosystem, and I am confident that both v4 and the RWA Hub will help with that vision and be mutually beneficial for Aave and Ava Labs.\nFor those of you who don’t know, Aave and Avalanche have a rich history over the past 5 years.\nHistory of Aave on Avalanche:\n\nIn the summer of 2021, Aave v2 launched on Avalanche during Avalanche Rush, after Chainlink introduced price feeds\n\nWith over $8m of incentives, Aave v2 reaches over $2b on Avalanche\n\nIn April of 2022, Aave v3 launched on Avalanche, shortly after Ethereum mainnet\n\nThe Avalanche Foundation introduces new incentives, specifically to help aid the growth of v3, totaling over $7m\n\nAave v3 hits $1.38b on Avalanche in June of 2022\n\nCrypto bear market occurs, and incentives are slowly wound down\n\nIn early 2024, crypto prices rebounded. The Avalanche Foundation comes up with a new incentive program called Boost, recognizing that the Avalanche DeFi ecosystem needs a resurgence in TVL, volumes, and users.\n\nDuring the next year, the Avalanche Foundation sponsors about $10m of incentives for Aave users, on Aave directly, CEX, and wallet earn platforms.\n\nAave on Avalanche grew during Boost from $200m to over $1b\n\nNext Steps and Plans\nThe Avalanche Foundation is committing to provide both milestone-based incentives up to a total of $15m, but also some liquidity support to bootstrap v4 and the RWA Hub markets on Avalanche. We also have a pipeline of new assets that we are excited to debut in partnership with the Aave team, both on the crypto native front and also RWAs that should make for good collateral for looping. Aave has Ava Labs and the Avalanche Foundation’s full support across multiple internal teams, like marketing, BD/growth, developer relations, and treasury, and we plan to lean in very heavily to this deployment. We will also work with the Aave team to build out earn campaigns on neobank and fintech platforms, as well as centralized exchanges.\nDeploying Aave v4 on Avalanche represents a major opportunity to expand the protocol’s footprint across both DeFi-native and institutional capital markets. This launch will not only enhance Aave’s architecture and asset base but transform modular lending for the better.\nWith deep infrastructure alignment, operational support from Ava Labs, and access to a robust pipeline of DeFi native and tokenized assets, as well as institutional partners, this initiative is positioned to deliver durable TVL, sustainable yields, and long-term protocol growth.\nWe look forward to collaborating with the Aave community to bring this vision to life.\n\n post by AaveLabs on Jun 3\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The Temp Check to deploy Aave V4 on Avalanche has been raised to snapshot. Voting will begin in 24 hours. You may vote here.\n\n post by Abel189 on Jun 4\n\n Abel189\n\n Generally supportive of exploring an Aave V4 deployment on Avalanche.\nFrom a strategic perspective, this feels different from a typical expansion proposal because Aave already has an existing user base and liquidity footprint on Avalanche. The combination of an established market, dedicated ecosystem support, and a proposed RWA hub could provide a meaningful environment to validate V4 growth outside Ethereum.\nThat said, I would like to see more detail in the ARFC regarding expected protocol economics. In particular:\n\nHow will success be measured beyond TVL growth?\n\nWhat revenue targets or utilization metrics are expected from the deployment?\n\nHow are the $15M incentives structured, and how closely are they aligned with sustainable borrowing activity rather than short-term liquidity mining?\n\nWhat differentiates the proposed Avalanche RWA hub from RWAs deployed on other Aave V4 markets?\n\nOverall, the direction appears sensible, but understanding the expected long-term revenue contribution to the DAO will be important when evaluating the final proposal.\n\n post by CalBlockchain on Jun 5\n\n CalBlockchain\n\n Supportive of this deployment. Both Aave v2 and v3 have been cornerstone protocols for Avalanche with proven success and still maintains sticky capital and users. Both parties would benefit greatly from a v4 deployment on the network.\nThat said, we echo the same points made by previous replies. More transparency on the structure, duration, the said milestones, and sustainability of the mentioned incentive program would be appreciated.\n\n 3 months later\n\n post by evan_chevalier on Aug 28\n\n evan_chevalier\n\n how this can be integrated within a layer2 blockchain\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n AL Development Update | September 2026\n\n Development\n\n 0\n\n 201\n\n 5d\n\n [Temp Check] Deploy Aave V4 on Arc\n\n New Market\n\n 5\n\n 837\n\n Jun 7\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d","tokens":3209,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262487157,"hash":"aa4350054f8979154ab1f98c903e862f715ec4b2"}
{"url":"https://ethresear.ch/t/so-you-wanna-post-quantum-ethereum-transaction-signature/21291/28","domain":"ethresear.ch","title":"So you wanna Post-Quantum Ethereum transaction signature - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 5\n\n 3\n\n 3\n\n 2\n\n read \n\n 9\n min\n\n Dec 2024\n\n 28 / 28\n\n May 26\n\n May 26\n\n Load more posts above\n\n post by p_m on Dec 18, 2024\n\n post by asanso on Dec 19, 2024\n\n post by CPerezz on Dec 19, 2024\n\n post by rdubois-crypto on Dec 19, 2024\n\n post by cryptskii on Dec 22, 2024\n\n 16 days later\n\n post by jeroenvdgraaf on Jan 8, 2025\n\n post by JChanceHud on Jan 12, 2025\n\n post by seresistvanandras on Jan 13, 2025\n\n 15 days later\n\n post by CPerezz on Jan 28, 2025\n\n post by asanso on Jan 29, 2025\n\n post by CPerezz on Jan 29, 2025\n\n 19 days later\n\n post by rdubois-crypto on Feb 18, 2025\n\n post by seresistvanandras on Feb 18, 2025\n\n post by rdubois-crypto on Feb 23, 2025\n\n post by rdubois-crypto on Feb 23, 2025\n\n 2 months later\n\n post by cryptskii on Apr 9, 2025\n\n post by kladkogex on Apr 11, 2025\n\n post by seresistvanandras on Apr 12, 2025\n\n seresistvanandras\n\nIt’s way better to be prepared for a post-quantum future and be cryptographically conservative than see an apocalyptic cryptographic disaster.\nI like to compare the skepticism behind quantum computing to that of nuclear energy.\nIn 1939, countless famous scientists were dubious in the late 1930s about the successful application of nuclear fission. For instance, the renowned Sir Henry Tizard (rector of Imperial College London) stated in 1939 that atomic bombs being successfully developed has a 100,000 to 1 chance…we all know what happened in 1945 August 6 and 9.\nWho knows…what’s gonna happen? But I would not bet a dime against technological development. So, let’s prepare Ethereum and ourselves for a possible post-quantum future!\n\n 1 year later\n\n post by opus-lux on May 26\n\n opus-lux\n\n Hey guys I have recently released something very relevant to this conversation that I think has been over looked.\nI have produced a signature scheme that uses Winternitz at its core where each public key is authorized by revealing a hash preimage in a Lamport chain. This is a tested benchmarked on chain implementation that is currently live at block_opuslux.ar.io, you can create ERC-4337 smart accounts that have full post quantum security. Or you can create EIP-7702 accounts to experience the native EOA upgrade demo (full post quantum security is not possible until EIP-7701 is adopted). Since Winternitz is used at the core of every hash based post quantum signature it is the lightest weight possible signing scheme. Also, by adjusting the w parameter in the Winternitz equation you can produce signatures that range in size from 896B to 2,880B the trade off is the verification time / gas! I would love to get some feedback on my implementation from the ethereum developer community! I believe that this is the optimal signature solution for post quantum security on the blockchain and I would love to talk to any serious developers about it ! You can also read the full outline of WOTS-39 at block_opuslux.ar.io/#/essay where I describe in detail how this works, why it works along with all the details of the implementation. The source code for the wallet is waiting in a private repository, ready to be shared with the community at a moments notice. Thank you all for taking the time to read this comment and consider this option !\nBest, Opus Lux !\n\n post by 71104 on May 26\n\n 71104\n\n I don’t think regular PQC signature schemes have any use in post-quantum blockchains given the general desire to also prove them in zero-knowledge. zkSTARKs can make HMAC asymmetric with a very cheap and simple circuit. The resulting zkSTARK would be larger than a regular PQC signature, but unlike the latter you would be able to aggregate and wrap it inside a larger zkSTARK that proves the whole block. We’re discussing that scheme in this thread and I think that’s what Ethereum will use in the future because you should think about the zero-knowledge roadmap, not just the quantum-safety roadmap. @vbuterin has explicitly written he wants all consumer devices (including low-end ones) to be able to validate blocks in a matter of milliseconds, you need zkSTARKs for that.\n\n Powered by Discourse","tokens":1028,"squid":"ink-research","role":"Deep Scholar","at":1791262493706,"hash":"1ae5df05acc12f321f84c62899a701e3098dbd55"}
{"url":"https://ethresear.ch/t/what-if-post-quantum-ethereum-doesn-t-need-signatures-at-all/24427","domain":"ethresear.ch","title":"What if post-quantum Ethereum doesn’t need signatures at all? - zk-s[nt]arks - Ethereum Research","text":"What if post-quantum Ethereum doesn’t need signatures at all? \n\n zk-s[nt]arks\n\n post-quantum\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 6\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Mar 17\n\n 1 / 18\n\n Mar 17\n\n Jul 2\n\n post by 0xjasonw on Mar 17\n\n 0xjasonw\n\n What if post-quantum Ethereum doesn’t need signatures at all?\nTL;DR: Current PQC migration plans assume we must verify post-quantum signatures — either on-chain (kilobytes per tx) or inside ZK circuits (millions of constraints). We present an alternative: prove authorization semantics directly in ZK, without any signature object. Result: 4,024 R1CS constraints, 128-byte proofs, 52 ms proving time. The construction is proof-system agnostic (Groth16, PLONK, STARKs all work) and deployable today as an AA validator module — no protocol changes required.\n\nMotivation: The PQC data wall\nThe community has been actively exploring PQC migration paths (13) and the core tension is well-known:\n\nScheme\nSig Size\nPublic Key\nTotal per TX\n\nML-DSA-44 (Level 2)\n2,420 B\n1,312 B\n3,732 B\n\nML-DSA-65 (Level 3)\n3,309 B\n1,952 B\n5,261 B\n\nML-DSA-87 (Level 5)\n4,627 B\n2,592 B\n7,219 B\n\nSLH-DSA-128f\n17,088 B\n32 B\n17,120 B\n\nFN-DSA-512\n~666 B\n897 B\n1,563 B\n\nEd25519 (classical)\n64 B\n32 B\n96 B\n\nThat’s a 30-60x increase in authorization data per transaction. In rollup architectures where calldata/blob space is explicitly priced, this is a first-order scalability problem.\nThe “obvious” solution and why it’s expensive\nThe natural response is: verify PQ signatures inside ZK circuits, post only the succinct proof on-chain.\nThe problem: lattice-based signature verification requires NTTs over degree-256 polynomial rings in \\mathbb{Z}_qℤ𝑞 (q = 2^{23} - 2^{13} + 1𝑞 =223 −213 +1), emulated over a ~254-bit proof-system field. Structural lower bounds:\n\nIn-circuit verification\nR1CS constraints\nDominant cost\n\nML-DSA-44 verify\n≥ 2M\n4×4 NTTs + non-native mod. arith.\n\nML-DSA-65 verify\n≥ 4M\n6×5 NTTs + non-native mod. arith.\n\nFN-DSA-512 verify\n≥ 1M\nFFT + Gram-Schmidt + mod. arith.\n\nSLH-DSA verify\n≥ 5M\nWOTS+ chains + Merkle trees\n\nECDSA verify (classical)\n~1.5M\nscalar mul. + mod. inverse\n\nEven with optimized gadgets, we’re looking at millions of constraints just to prove “this signature is valid.”\nKey observation: authorization ≠ signatures\nHere’s the thing: at the consensus layer, blockchains don’t actually require verification of a specific signature object. What consensus requires is assurance that a transaction was authorized by the correct entity.\nSignatures are an implementation artifact for expressing authorization — not authorization itself. We’ve been conflating the two.\nZK-ACE: identity-centric authorization\nWe present ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities), which takes this observation to its logical conclusion:\n\nDon’t verify signatures in ZK. Don’t compress signatures. Eliminate signature objects from the authorization path entirely.\n\nInstead, the chain stores a compact identity commitment (32 bytes):\n\nID_{com} = H(REV \\| salt \\| domain)\n𝐼𝐷𝑐𝑜𝑚=𝐻(𝑅𝐸𝑉‖𝑠𝑎𝑙𝑡‖𝑑𝑜𝑚𝑎𝑖𝑛)\nwhere REV𝑅𝐸𝑉 is a 256-bit identity root derived from a deterministic identity derivation primitive (DIDP). Each transaction carries a ZK proof attesting:\n\n(C1) Commitment consistency: Prover knows a preimage of ID_{com}𝐼𝐷𝑐𝑜𝑚\n(C2) Derivation correctness: A target-binding hash is consistent with deterministic key derivation under the identity root\n(C3) Authorization binding: The identity root has authorized this specific TxHash𝑇𝑥𝐻𝑎𝑠ℎ\n(C4) Anti-replay: Nonce commitment or nullifier is correctly derived\n(C5) Domain separation: All bindings use the declared chain/domain tag\n\nThe entire circuit is 5 Poseidon hash invocations + equality constraints. No lattice arithmetic. No signature verification logic. No non-native field emulation.\nBenchmarks (reference implementation)\nImplementation: arkworks + Groth16 over BN254, Poseidon (t=3𝑡 =3, \\alpha=17𝛼 =17, 8 full + 57 partial rounds).\nCircuit size:\n\nConstraint\nInputs\nHash calls\nR1CS\n\n(C1) Commitment consistency\n3\n1\n805\n\n(C2) Derivation correctness\n4+1\n2\n1,200\n\n(C3) Authorization binding\n7\n1\n1,615\n\n(C4) Replay prevention\n2\n1\n400\n\n(C5) Domain sep. + enforce_equal\n—\n—\n4\n\nTotal\n\n5\n4,024\n\nBoth replay modes (nonce-registry and nullifier-set) produce identical constraint counts.\nPerformance (single-threaded, Apple M3 Pro, Criterion.rs, 100 samples):\n\nOperation\nMedian\n95% CI\n\nTrusted setup (one-time)\n45.6 ms\n[45.4, 45.8] ms\n\nProve (per transaction)\n52.3 ms\n[51.5, 53.4] ms\n\nVerify (per transaction)\n604 μs\n[600, 608] μs\n\nProof size:\n\nEncoding\nProof\nPublic inputs\nTotal auth data\n\nCompressed Groth16\n128 B\n160 B (5 × 32 B)\n288 B\n\nCompression vs. PQ signatures:\n\nScheme\nPQ sig+pk\nZK-ACE\nReduction\n\nML-DSA-44 (Level 2)\n3,732 B\n288 B\n13x (92.3%)\n\nML-DSA-65 (Level 3)\n5,261 B\n288 B\n18x (94.5%)\n\nML-DSA-87 (Level 5)\n7,219 B\n288 B\n25x (96.0%)\n\nSLH-DSA-128f\n17,120 B\n288 B\n59x (98.3%)\n\nConstraint comparison (the core result):\n\nApproach\nR1CS constraints\n\nZK-ACE (this work)\n4,024\n\nIn-circuit ML-DSA-44 verify\n≥ 2,000,000\n\nIn-circuit ECDSA verify\n~1,500,000\n\nThat’s a ~500x constraint reduction — not from optimizing signature verification, but from not doing it at all.\nDeployment: AA validator module\nZK-ACE is designed as an ERC-4337 validator module. In an AA wallet:\n\nThe account validation logic invokes ZK-ACE verification instead of checking a classical or PQ signature\nProof generation happens client-side (~52 ms)\nThe bundler transports proof + public inputs (untrusted, learns nothing)\nOn-chain verification costs ~604 μs per proof\n\nThis means no protocol-level changes are required. ZK-ACE can be deployed on existing infrastructure.\nProof-system agnostic by design\nAn important design property: ZK-ACE is a protocol-level authorization model, not a proof-system-specific construction. The five constraints (C1)–(C5) are stated over abstract hash evaluations and equality checks. They can be instantiated with:\n\nProof system\nSetup\nProof size\nTrade-off\n\nGroth16 (reference impl.)\nTrusted (per-circuit)\n128 B\nSmallest proof, fastest verify\n\nPLONK / KZG\nUniversal (one-time)\n~400–600 B\nNo per-circuit setup\n\nSTARKs / FRI\nTransparent (none)\n~40–100 KB\nNo trusted setup, plausibly PQ-secure\n\nBulletproofs / IPA\nTransparent\n~700 B\nNo setup, larger verify cost\n\nThe benchmarks above use Groth16 because it gives the tightest numbers, but the protocol doesn’t depend on it. In particular, a STARK instantiation would make the entire authorization pipeline plausibly post-quantum at the proof layer as well — no trusted setup, no pairing assumptions, hash-based soundness only. The identity commitments are proof-system-agnostic (they’re just hash outputs), so migrating from one proof system to another does not require identity rotation or re-registration.\nThe security reductions in the paper are stated generically in terms of knowledge-soundness advantage \\text{Adv}^{ks}Adv𝑘𝑠 and are compatible with any backend satisfying completeness, knowledge soundness, zero-knowledge, and public-input binding.\nAssumed primitive: DIDP\nZK-ACE assumes a Deterministic Identity Derivation Primitive (DIDP) as a black box — any framework providing:\n\nDeterministic key derivation from a high-entropy root\nContext isolation across derivation paths\nIdentity-root recovery hardness\n\nThis is not tied to any specific construction. A simple HKDF(root, context) satisfies the interface. We provide ACE-GF as an instantiation; any KDF with domain separation works.\nSecurity\nFour game-based security definitions with reduction-based proofs under standard assumptions:\n\nAuthorization soundness → reduces to knowledge soundness + collision resistance + DIDP recovery hardness\nReplay resistance → reduces to authorization soundness + verifier enforcement\nSubstitution resistance → reduces to public-input binding of the proof system\nCross-domain separation → reduces to collision resistance + public-input binding\n\nFull proofs in the paper.\nWhat this is NOT\nTo be explicit:\n\nNot ZK-verification of PQ signatures (we don’t verify any signature inside the circuit)\nNot signature compression (we eliminate signatures, not shrink them)\nNot a new signature scheme\nNot dependent on any specific identity framework\n\nIt’s a change in what we prove: from “this signature is valid” to “this identity authorized this transaction.”\nRelation to existing discussions\nThis work connects to the ongoing PQC migration discourse:\n\nSo you wanna Post-Quantum Ethereum transaction signature identified the AA path for PQC\nThe road to Post-Quantum Ethereum transaction is paved with AA demonstrated Falcon verification via AA\nPoqeth benchmarked PQ signature verification on-chain\n\nThese approaches all preserve the signature-centric model. ZK-ACE asks: what if we don’t?\n\nPaper: ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems\nReference implementation: github.com/ya-xyz/zk-ace\n\n Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators\n\n So you wanna Post-Quantum Ethereum transaction signature\n\n Towards Native Post-Quantum Private ETH\n\n 8\n\n 6\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n post by uulong950 on Mar 17\n\n uulong950\n\n Brilliant write-up and a very elegant paradigm shift away from signature-centric verification. The 4,024 R1CS constraint reduction is massive for AA validator modules.\nI want to specifically touch on your point regarding the STARKs / FRI instantiation being the ideal path for a fully transparent, plausibly PQ-secure authorization layer. Historically, the pushback against using STARKs for client-side or decentralized AA proving has been the severe hardware requirements and proving latency at scale.\nI recently open-sourced the Qingming ZKP Engine, which directly attacks this FRI proving bottleneck using consumer-grade AMD GPUs (ROCm/HIP), and I believe it could make the STARK instantiation of ZK-ACE highly practical today without needing enterprise clusters.\nBy taking over the unsafe pointer lifecycle in Rust to bypass standard memory transfers and mapping arrays directly to the AMD 96MB Infinity Cache (Zero-Copy), alongside mathematically reducing the Fermat modular inversions in the fold loop into O(1) scalar multiplications (Zero-Inversions), we achieved the following on a single $999 RX 7900 XTX:\n\nNTT (2242^{24}224 scale): 18.94 ms\n\nMerkle Tree (L0): 763.3 ms\n\nFRI Prove (End-to-End, 16.7M leaves): 2.56 s\n\nIf your ZK-ACE identity commitments and authorization bindings were instantiated over a Goldilocks field STARK, the proving time on consumer hardware would be virtually instantaneous with this engine.\nWould love for you or anyone in the AA/PQC research space to check out the host-side benchmark logic. This kind of hardware-layer dimensionality reduction might perfectly complement the architectural dimensionality reduction you just presented.\nGitHub: qingming-zkp\n\n post by 0xjasonw on Mar 23\n\n 0xjasonw\n\n This is an amazing benchmark — phenomenal work on the Zero-Copy + Zero-Inversions approach. The 2.56s end-to-end FRI prove on a consumer RX 7900 XTX is a game-changer for decentralized proving.\nYour Qingming ZKP engine and ZK-ACE form a strong complementary pair — your hardware-layer dimensionality reduction directly addresses the proving latency bottleneck we identified as the primary trade-off when choosing STARKs over Groth16.\nSome context on where this could plug in: I’m building an MVP for a new L1 blockchain with an n-VM runtime architecture that natively executes EVM (revm Shanghai), SVM (Solana), BVM (Bitcoin Script), and TVM — all within a unified state tree. The chain runs dual-algorithm native cryptography: classical Ed25519 and post-quantum ML-DSA-44 (FIPS 204) in parallel at every protocol level.\nBased on our architectural modeling, the n-VM runtime projects the following throughput estimates:\n\nTheoretical EVM ceiling: 20,000–100,000 TPS (single-core to parallel scheduling)\nProjected sustained (simple transfers): 3,000–5,000 TPS\nProjected sustained (complex contracts, e.g. DEX swaps): 500–1,500 TPS\nProjected sustained (mixed workload): 1,000–3,000 TPS\n\nThese figures are before ZK proving enters the critical path. If Qingming’s GPU-accelerated FRI could handle our per-block STARK proof generation at sub-second latency on consumer hardware, it would remove the last major bottleneck standing between our architecture and true sub-second cryptographic hard finality — without requiring enterprise GPU clusters.\nWould love to explore integration. The combination of your hardware-layer optimization with our protocol-layer identity–authorization separation could be quite compelling.\n\n post by 0xjasonw on Mar 23\n\n 0xjasonw\n\n P.S. — Actually we’ve already implemented the MVP: 3-node devnet with block production, on-chain ML-DSA-44 signed transfers, leader rotation, and a browser-based explorer. One observation from our architectural analysis: because ML-DSA-44 verification (~50μs) is actually faster than Ed25519 (~76μs), and our ZK-ACE attestation model eliminates per-transaction signature verification from the critical path entirely, our runtime can achieve throughput comparable to or exceeding current Solana mainnet TPS — even when every transaction is authorized with post-quantum credentials. To our knowledge, this would make it the first blockchain architecture where post-quantum cryptography imposes zero performance penalty relative to classical algorithms, potentially making it production-viable as a PQC-native L1 today rather than as a future migration target.\nBeyond ZK proving, we’re facing a number of Rust-level performance optimization challenges across the runtime — state I/O, parallel scheduling, gossipsub propagation. Having looked through your Qingming codebase, your expertise in low-level Rust + GPU optimization is exactly the kind of skill set that could accelerate this work significantly. Would it be okay if I DM you?\n\n 10 days later\n\n post by 0xjasonw on Apr 2\n\n 0xjasonw\n\n Update: Dual-Backend Implementation with Circle STARK (Post-Quantum Secure)\nSince the original post, ZK-ACE has been significantly rearchitected. The key updates:\n1. Pluggable dual-backend architecture is now implemented and benchmarked.\nThe original post described a Groth16-only prototype. The reference implementation now ships two compile-time selectable backends:\n\nAspect\nCircle STARK (Stwo) — default\nGroth16/BN254\n\nField\nMersenne-31\nBN254 Fr (~254-bit)\n\nHash\nPoseidon2 (width=16)\nPoseidon (width=3)\n\nConstraints\n~240 AIR\n~1,200 R1CS\n\nProve\n21 ms\n44 ms\n\nVerify\n1.1 ms\n1.5 ms\n\nProof size\n~105 KB\n128 B\n\nPQ-secure\nYes\nNo\n\nSetup\nTransparent\nTrusted\n\nBenchmarked on Apple Silicon, Criterion.rs medians, single-threaded.\n2. Constraint count correction. The original post reported 4,024 R1CS constraints from an early prototype. The production Groth16 circuit is ~1,200 R1CS. The STARK backend compiles to ~240 AIR constraints. Both remain roughly three orders of magnitude smaller than in-circuit ML-DSA verification.\n3. The STARK backend is faster than Groth16. This is counterintuitive but follows directly from field arithmetic: M31 operations (31-bit) are an order of magnitude cheaper than BN254 (254-bit), and STARK proving requires no elliptic curve MSMs. For small circuits, this advantage dominates.\n4. On-chain cost with mandatory STARK aggregation:\nIndividual STARK proofs (~105 KB) never go on-chain. The block builder aggregates all per-transaction proofs into a single batch proof. Per-transaction on-chain data is only the public inputs:\n\nModel\nPer-tx on-chain\n\nML-DSA-65 (direct)\n~5,261 B\n\nZK-ACE STARK (aggregated)\n~160 B\n\nZK-ACE Groth16\n~288 B\n\nThis is a 32x compression vs ML-DSA-65 under the STARK model, with full post-quantum security and transparent setup.\n5. The entire authorization path is now PQ-secure. Under the STARK backend, identity commitment → proof generation → on-chain verification relies only on hash functions (Poseidon2 + Blake2s). No elliptic curve assumptions anywhere.\nThe Groth16 backend remains available for EVM-native deployments where proof compactness matters more than PQ security.\nCode: github.com/acechain-io/zk-ace\nPaper: arXiv:2603.07974\n\n post by 71104 on Apr 6\n\n 71104\n\n Basically STARKing an HMAC? Cool!\n\n 8 days later\n\n post by 0xjasonw on Apr 14\n\n 0xjasonw\n\n Yes. It’s super cool actually. we elimiated PQC performance penalty completely. We reached 570+ TPS on both ed25519 and ML-DSA-44 on the local 3-node devnet on a MacBook Pro M3 with 12 core and36G RAM. I believe we are the first one that can eliminate PQC performance penalty and reach such high TPS on a commodity device.\n\n post by 71104 on Apr 14\n\n 71104\n\n I think the biggest innovation coming from your proposal is that you’re connecting two different areas of cryptography that don’t seem to have managed to talk to each other so far. Up until now it was common knowledge that an HMAC scheme can replace signatures only in a symmetric setting because both the “signer” and the verifier need to know the secret key, but zkS{N,T}ARKs change that completely indeed! Now a verifier can reliably verify an HMAC without having to know the secret key, just like in asymmetric cryptography!\nThe resulting “signature” scheme will probably never be as efficient as an actual signature: Dilithium signatures are very large but zkSTARKs are even larger, unfortunately. But this idea has the advantage of being highly aggregatable: if all transaction signatures are “STARK’d HMACs” you get to prove a whole block with a single zkSTARK easy. While verifying Dilithium in AIR… good luck with that.\nVery cool idea, thanks for sharing it!\nI’ll be honest, I seem to be somewhat of a competitor of yours. I co-founded a brand new, post-quantum L1 project and after reading this thread we’ve totally decided to follow this pattern.\nPS: in our project we’re gonna call this pattern “zkMAC”. The name fits much better than “zkACE”.\n\n post by 0xjasonw on Apr 15\n\n 0xjasonw\n\n Hi 71004,\nGlad to see you are interested in adopting this technology!\nSince you are looking to integrate this pattern into an L1 project, instead of fragmenting the effort with a separate implementation, I’d like to invite you to contribute directly to the original ACE repository.\nCollaborating on the upstream source is the best way to support the open-source community, and it ensures the tech stays standardized and robust for everyone. It would be much more efficient for the ecosystem to have a single, well-audited implementation than multiple divergent ones.\nLet’s work together to make ACE the standard for zk-based MACs — I actually think “zkMAC” is a great technical descriptor for this construction! What do you think?\n\n 1 month later\n\n post by 71104 on May 17\n\n 71104\n\nI’ve been re-reading this part, why are 5 hashes needed? It looks to me like 2 are sufficient: one to compute the identity commitment and another one to HMAC the message.\nI’ve recently finished implementing this scheme in my project Libernet and that’s how I did it. This is the reusable chip: crypto/src/hmac.rs at d653000d3f3d21c671fac8cb6857e86afd677460 · libernet-mirror/crypto · GitHub\n(I used a terminology that resembles actual signatures: I called your “REV” simply “private key” and your “identity commitment” simply “public key”.)\n\n post by 0xjasonw on May 25\n\n 0xjasonw\n\n Deleted previous one by mistake.\nThanks for the rigorous engineering insights, Alberto! The 2-call variant utilizing Poseidon’s sequential Absorb state is a fantastic optimization and significantly reduces the R1CS constraints.\nRegarding the terminology, I noticed you referred to REV𝑅𝐸𝑉 as ‘private key’ and ID_{com}𝐼𝐷𝑐𝑜𝑚 as ‘public key’ in Libernet. While I understand the intuition behind using classical signature terms for familiarity, I strongly recommend adhering to the original ZK-ACE terminology (REV𝑅𝐸𝑉 / Identity Commitment). >\nIntroducing standard key pairs (PK/SK) syntax into an identity-centric authorization path can cause major conceptual confusion for developers. In ZK-ACE, the authorization semantics are explicitly decoupled from traditional signature verification objects.\nTo ensure we build a unified, interoperable standard for the broader post-quantum Ethereum ecosystem without fragmentation, let’s keep the codebase and implementation aligned under the ZK-ACE architecture. Looking forward to benchmarking your optimized pipeline further!\n\n post by 0xjasonw on May 25\n\n 0xjasonw\n\n Hi Citrullin,\nCan you give me any clue on how to apply this to Social Dynamics. I’m interested in social science very much. I’m drafting some papers in social science actually. will share with you when published\n\n post by 71104 on May 27\n\n 71104\n\nI was looking at this table again. I’m not sure that Poseidon2 is still quantum-safe when it runs over such a small field as Mersenne-31, even if you’re using a state vector width of 16. For sure it would be utterly broken if the state width was 2 (even a classical computer can break that in a matter of seconds), so the question is whether or not the 16 elements of the state vector can be attacked individually, and whether or not Grover’s algorithm provides any advantages in that regard. I don’t know Poseidon2 well enough to speak for that, but for the best level of quantum-safety I think it’s best to use a 256-bit field.\nAnother odd choice you made is AIR arithmetization. AIR takes 4 extra columns for the memory argument, but for “zkMAC” the only equality constraint you really need is the one proving that the secret key used to derive the identity commitment is the same used to hash the HMAC. Memory is a complete overkill here, I think the permutation argument is much better in this case. You’d probably get better results with TurboPLONK.\n\n post by 71104 on May 27\n\n 71104\n\nOkay, I’ve just reviewed the original Poseidon2 paper. The proposed instantiations are on page 16, table 1, and the paper targets 128-bit classical security.\nThe classical security of Poseidon2 is generally \\frac{c}2𝑐2 bits, where c𝑐 is the total bit size of the capacity columns. Under Grover that becomes \\frac{c}4𝑐4.\nYour instantiation is the one in the first row of the table, with c = 8 \\cdot 31 = 248𝑐 =8 ⋅31 =248, making for ~124 bits of classical security and ~62 bits under Grover. That’s insufficient.\nThe instantiation at the second row of the table adds 8 more capacity columns and works much better for quantum safety: now we have c = 16 \\cdot 31 = 496𝑐 =16 ⋅31 =496, so everything is doubled – ~248 bits of classical security and 124 bits under Grover. ✓\nYou may want to re-run your numbers for quantum safety. You need to add 8 columns and they aren’t gonna be free – it’s 8 more NTTs. The number of partial rounds also jumps to 22, so there will be more constraints and you’ll almost certainly exceed the next power of 2 and double your circuit size.\n\n 1 month later\n\n post by uulong950 on Jun 30\n\n uulong950\n\n 0xjasonw\n\n Hi Jason — apologies for the very delayed reply. I had been away from ethresear.ch for a while and missed your follow-up. Thank you for the thoughtful response.\nYes, absolutely — feel free to DM me.\nSince my earlier comment, I have been trying to frame Qingming more precisely. I now think the cleanest description is not simply “a fast NTT benchmark”, but a native Goldilocks LDE boundary test for STARK proving.\nThe latest Qingming G64 NTT work is here:\nThe target workload is deliberately native rather than a proxy benchmark:\n\nField: Goldilocks / G64\n\nModulus: p = 2^64 - 2^32 + 1\n\nLogical data size: 2^24\n\nLDE expansion: exact 8x\n\nTransform domain: 2^27\n\nBackend: AMD HIP / ROCm\n\nValidation GPU: RX 7900 XTX\n\nROCm/HIP: ROCm 7.2.4 / HIP 7.2.53211\n\nOn the validated 2^27 target, the fast interface benchmark reports about 19.19 ms median latency, 19.49 ms p95 latency, 52.10 size-2^27 NTT/s, 6.99 billion elements/s, and 94.41 billion butterflies/s. The standard compatibility interface is about 21.99 ms median, with tiled prelayout measured separately at about 3.14 ms.\nCorrectness is also part of the framing: the repository includes field arithmetic checks, the primitive 2^27 root contract, explicit base-512 layout bijection checks, delta-vector validation, sampled direct evaluation against the mapped output contract, standard/fast layout checks, and a full CPU radix-2 reference comparison over the full 2^27 output.\nThe reason I think this is relevant to ZK-ACE is that it keeps the native STARK proving boundary intact: no proxy field, no reduced modulus, no scaled-down domain, and no hidden layout cost. If STARK-based authorization becomes part of the critical path, then making the native G64 LDE/FRI path practical on commodity GPUs becomes a very important engineering question.\nHappy to discuss integration, benchmark alignment, or a minimal experiment connecting Qingming-style G64 acceleration with your ZK-ACE architecture.\n\n post by Dede-Qorqud on Jul 1\n\n Dede-Qorqud\n\n What strikes me most here is the architectural implication: if authorization can be proven without a signature object, then the trust boundary shifts from “who signed” to “what was proven.” That’s a meaningful separation — it decouples identity from the cryptographic artifact we’ve historically used to represent it.\nThe aggregation consequence follows naturally from this. Once individual authorizations are proofs rather than signatures, batch verification becomes compositional by design rather than an afterthought.\nCurious whether the authors see applications beyond transaction authorization — specifically in contexts where the meaningful unit isn’t a single action but a collective outcome.\n\n post by 71104 on Jul 1\n\n 71104\n\nNot sure if this is what you mean but this zkACE scheme (which I prefer to call “zkMAC”) works as a post-quantum VRF too, and is therefore eligible for use in SSLE protocols.\n\n post by Dede-Qorqud on Jul 2\n\n Dede-Qorqud\n\n Good point — if the construction satisfies VRF security (pseudorandomness + provability), the SSLE application follows naturally. The post-quantum dimension makes it particularly relevant given where Ethereum’s roadmap is heading.\nOne parallel that comes to mind: the same ZK primitive that enables secret leader election in consensus could enable secret participant weighting in collective decision systems — where you want a verifiable aggregate outcome without revealing individual weights or choices. Different domain, same structural property.\nWe’ve been exploring exactly this in a related context: https://ethresear.ch/t/designing-infrastructure-where-exploits-destroy-themselves/25348\n\n Powered by Discourse","tokens":6646,"squid":"ink-research","role":"Deep Scholar","at":1791262504131,"hash":"31e4df1279a0ef254cab34b18b76a1cd94984287"}
{"url":"https://governance.aave.com/t/arfc-aave-and-ether-fi-cash-a-proposal-for-real-world-utility/21909","domain":"governance.aave.com","title":"[ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility - Governance - Aave","text":"[ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 6\n min\n\n [ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n Author: ACI & Ether.fi\n\n Date: 2025-04-29\n\n Overview\n\n Summary\n\n Motivation\n\n Card Program\n\n Implementation details & profit share\n\n Implementation Timeline\n\n Disclaimer\n\n Next Steps\n\n Copyright\n\n Apr 2025\n\n 1 / 7\n\n Apr 2025\n\n Jul 2025\n\n post by ACI on Apr 28, 2025\n\n ACI\n\n Leader\n\n [ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility\nAuthor: ACI & Ether.fi\nDate: 2025-04-29\n\nOverview\nThis proposal outlines a partnership between Aave and ether.fi, with the goal of creating a unique Aave market on an EVM L2 to facilitate on-chain credit for everyday payments through the ether.fi Cash credit card program. This collaboration aims to benefit both platforms by continuing to expand their user bases and driving innovation in DeFi with a focus on bridging the gap between DeFi and real-world consumer applications.\nProposal is submitted after successful [TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility and TEMP CHECK Snapshot.\nSummary\nThe ether.fi market was launched on Aave back in September, with the goal of laying the groundwork for a unique instance of Aave, focused at stablecoin borrowing against interest accruing collateral. This market has since been idle, while the development of ether.fi Cash continued to take shape.\nAs we prepare for the next phase of the rollout plan, we propose migration of this market to an optimized Layer 2 market designed specifically for consumer credit applications. Since then, it was determined that ether.fi needs a more tailored instance of the Aave market, with the focus of allowing for more flexibility in asset listings and parameters, along with less expensive transaction fees. This market will feature tailored parameters and asset listings optimized for real-world spending, supported by a competitive card program offering up to 3% cashback.\nMotivation\nThe traditional credit card industry continues to charge excessive interest rates (often 20%+). By leveraging collateral assets that permit users to continuously earn interest on the positions held in their wallets, naturally offsetting borrowing costs. This market will create a virtuous cycle where a user’s digital assets work to pay down their credit. With this, we can provide users with:\n\nSignificantly lower borrowing costs compared to traditional credit cards\nCompetitive rewards (up to 3% cashback)\nEfficient use of interest bearing asset positions as collateral, allowing users to keep their positions on chain and in their own custody\nMinimal transaction costs through L2 deployment\n\nThis proposal continues to build on the fundamental differences that DeFi has to offer. The future of ether.fi cash will be a system that provides both retail and corporate users with a truly native on-chain solution that does not sacrifice any of the features that consumers have become accustomed to with everyday spending.\nCard Program\nThe ether.fi Cash credit card is set to change everyday spending by bringing self custodied DeFi-powered credit to the world’s largest payment network. With universal acceptance at over 80 million merchants globally, users can access their DeFi credit lines for daily purchases while earning cashback rewards on all expenditures. The upcoming neo-banking alternative mobile app, launching in early Q2 2025, will evolve to provide a comprehensive suite of financial tools including real-time transaction monitoring, expense categorization, budget tracking, and intelligent position management. Corporates and retail users can instantly create multiple virtual cards, manage spending limits, and track rewards - all while their collateral works for them in the background through the Aave market. The app would integrate directly with the custom Aave instance, offering automated position management, smart liquidation protection, and dynamic credit line adjustments based on collateral value. Capital efficiency in this market will be further realized with the launch of Aave V4, utilizing available stable liquidity through the hub and spoke model.\nBy Q4, the platform plans to incorporate AI-powered trading strategies and financial insights, along with predictive budgeting tools, completing the vision of a truly on-chain banking alternative experience powered by DeFi. This will allow for a complete reimagining of on-chain credit, where the efficiency of DeFi meets the convenience of traditional payment networks, all optimized through a dedicated L2 deployment for minimal transaction costs. This vision will be coupled with the battle tested Aave market, along with risk monitoring provided by Chaos Labs.\nThrough this vision, ether.fi would also look to collaborate with Aave to offer a unique co-branded credit card for a unique set of users.\nImplementation details & profit share\nWe believe in strategic partnerships that are built for sustainable growth and fair value distribution. That’s why we’re proposing a straightforward revenue sharing model where 15% of the interest rate spread goes directly to the Aave DAO. This creates a win-win scenario where protocol growth directly benefits both ecosystems.\n\nFor the initial 6 months, 20% of the interest rate spread allocated to Aave DAO\nAfter the initial 6 months, 15% of the interest rate spread allocated to Aave DAO\nTransparent revenue distribution mechanism\nQuarterly reporting on market performance and revenue generation\n\nThis will allow for scalable infrastructure that is ready for mass adoption.\nImplementation Timeline\n\nQ2 2025: L2 market deployment with defined assets supported\nEarly Q2 2025: Card program launch to public (currently in closed beta)\nQ3 2025: Enhanced features rollout\nQ4 2025: Program optimization based on usage data\n\nDisclaimer\nThis proposal is powered by Skywards. ACI is not directly affiliated with ether.fi and did not receive compensation for creating this proposal.\nNext Steps\n\nPublication of a standard ARFC (done)\nCollect community & service providers feedback before escalating proposal to ARFC snapshot stage\nIf the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived under CC0\n\n BGD. Our approach to Aave v3 friendly forks\n\n read \n\n 6\n min\n\n 1 month later\n\n Closed on May 28, 2025\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Opened on Jun 1, 2025\n\n post by LlamaRisk on Jun 1, 2025\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n To support informed business-level decision-making, we have consolidated and articulated our legal assessment of the Cash product’s contractual architecture. Our team undertook a detailed, clause-by-clause comparison of the three operative Ether-fi Cash agreements (Cardholder Agreement (U.S.), Cardholder Agreement (International), Corporate Agreement (International)) that govern the current and prospective customer cohorts.\nThe key findings from our screening are summarized below. Our initial analysis indicates no legal or regulatory concerns with the product’s setup. Therefore, we recommend continuing to explore the integration process, deeming that it poses no incremental regulatory risk to Aave’s DAO. As further integration details are published, we will conduct additional research to provide targeted risk recommendations.\n1. Counterparty Scope\n\nU.S. Cardholder (consumer): Applies to natural persons who qualify as U.S. persons and successfully complete full KYC. The contract is governed by the laws of Puerto Rico and, subsidiarily, U.S. federal law, with all disputes submitted to AAA arbitration seated in New York.\nInternational Cardholder (consumer): Covers retail users situated outside the United States who must affirm they are not U.S. persons and pass sanctions screening. Governing-law and venue clauses likewise reference Puerto Rico; arbitral forum remains AAA.\nInternational Corporate: Addresses non-U.S./non-Canadian legal entities that satisfy KYB requirements. Disputes are referred to LCIA arbitration, seated in the Cayman Islands and governed by Cayman Islands law.\n\n2. Funding Mechanics and Interest Terms\n\nU.S. & International consumers: Each purchase is matched 1:1 with digital-asset collateral on deposit, creating an over-collateralised revolving line. The smart contract liquidates automatically on default or margin breach. Purchases accrue no interest, and cash-advance functionality is expressly excluded.\nInternational corporate: Companies may (i) pre-fund in USDC or (ii) draw on a crypto-collateralised facility subject to adjustable minimum ratios. A dashboard provides real-time margin-call alerts. No APR is quoted; instead, the arrangement is framed as non-custodial and fee-based.\n\n3. Liquidation Triggers and Process\n\nU.S. consumer: A “Liquidation Event” is triggered by any of the following: (a) scheduled periodic sweep; (b) a discretionary sweep within a fixed number of hours after each purchase; (c) non-payment 21 days post-statement due date; or (d) collateral value falling below outstanding charges without timely top-up. Once initiated, the smart contract forecloses automatically, and Ether-fi disclaims any obligation to halt or give prior notice.\nInternational consumer: The cardholder terms do not enumerate triggers; liquidation is governed by the underlying DeFi lending protocol, which executes when its LTV threshold is exceeded. Ether-fi’s role is limited to charging a contractual liquidation fee; it is not the seller of collateral.\nCorporate: If collateral falls below the stipulated ratio and is not cured, Ether-fi may unilaterally adjust requirements and liquidate. Precise triggers are configurable. Liquidation may occur via the smart contract or a third-party venue designated by Ether-fi after a margin breach.\n\n4. Fee Schedule\n\nForeign-transaction fee: A 1 % surcharge applies to every non-USD or cross-border purchase on both consumer cards. Corporate fees—including onboarding, issuance, foreign-exchange, and other charges—are prescribed in a separate in-dashboard schedule.\nLate and penalty fees: The U.S. consumer agreement imposes a 2 % fee on any past-due balance. International consumer fees are deferred to the applicable schedule. Corporate terms authorise a broader spectrum of fees and collateral liquidation upon default.\n\n5. Spending Limits and Administrative Controls\n\nConsumer (U.S. & International): Spending limits are dynamic, calibrated against posted collateral and real-time risk indicators.\nCorporate: Default limits are risk-weighted, but Program Administrators can configure granular controls—per card, business unit, or time window—through the administration dashboard.\n\n6. Liability Allocation and Consumer-Protection Safeguards\n\nU.S. consumer: Liability for unauthorised use is capped at $50 upon prompt notification, mirroring Regulation Z and Visa’s zero-liability framework.\nCorporate: Liability resides entirely with the company. Internal corporate policies may redistribute losses among individual users, yet Ether-fi Cash ultimately looks to the corporate entity for restitution.\n\n7. Customer Due-Diligence Requirements\n\nU.S. consumer: Full KYC - Social Security number, residential address, and OFAC screening.\nInternational consumer: KYC plus explicit non-U.S. attestation and sanctions screening.\nCorporate: KYB covering formation documents and beneficial-owner identification, supplemented by KYC for every authorised card user. The Program Administrator manages keys and spending parameters.\n\n8. Governing Law and Dispute Resolution\n\nU.S. consumer: Puerto Rico law (with applicable U.S. federal overlay); AAA arbitration seated in New York or conducted remotely.\nInternational consumer: Puerto Rico law; AAA arbitration seated in New York or remote.\nCorporate: Cayman Islands law; LCIA arbitration seated in the Cayman Islands.\n\n9. Organisational Structure and Risk Segmentation\nEther .fi SEZC, a Cayman-registered entity, owns the Ether-fi protocol, licenses the “ether.fi” brand, controls the website, and stands as the counter-party under the overarching Terms-of-Use as well as the data-controller for privacy purposes. Two wholly-owned subsidiaries—Ether .fi Cash Ltd (consumer) and Ether .fi Cash [Corporate] Ltd—administer the respective Cash credit-card programmes, including collateral parameters, spend limits, and cardholder contracts. The issuing bank, operating under the Visa licence, is legally distinct from all Ether-fi entities. Each card agreement incorporates the parent’s Terms-of-Use, thereby situating Ether .fi SEZC at the apex of the contractual stack while allowing the Cash subsidiaries to manage card-specific operations and risk.\nThis tripartite structure intentionally (i) separates regulated card-issuing activities from unregulated crypto operations, (ii) isolates liability across jurisdictions, and (iii) establishes a compliance firewall between traditional banking and DeFi functionality. The agreements underscore this demarcation, noting, for example: “Issuer is not a party to any agreement with the Ether-fi protocol” and “Issuer bears no affiliation to, or liability for, any interaction between you and the Ether-fi protocol.”\n10. DeFi Integration as the Credit Engine\nThe card programs interface directly with decentralized lending pools to furnish users with an over-collateralized USDC revolving line. Because credit is extended by—or through—the DeFi protocol (i.e. Aave in the examined proposal) rather than by the Visa issuer, regulatory obligations bifurcate: front-end purchase transactions remain subject to conventional card-network rules, while KYC/AML and credit-risk oversight migrate to Ether-fi Cash. The three agreements delineate that boundary as follows:\n\nU.S. consumer: Ether-fi Cash Ltd is expressly the creditor of record; the Visa issuer disclaims lender status. Collateral is foreclosed automatically upon any of four stipulated triggers.\nInternational consumer: The issuer functions solely as card issuer. LTV monitoring, interest computation, and liquidation are executed by the underlying protocol, while the card terms merely reserve a “Liquidation Fee (Reserved).”\nCorporate: A company may either pre-fund in USDC or pledge crypto collateral to secure a flexible credit line visible in its admin dashboard. Collateral ratios and liquidation parameters remain subject to modification by Ether-fi Cash upon notice.\n\nConclusion\nTaken together, these provisions articulate a sophisticated hybrid model that combines old card systems with new, decentralized money sources, and divides legal risks among different entities and regions.\nIn light of the foregoing, we consider the Cash product’s legal and compliance architecture sufficiently robust and well-segmented across the relevant entities and jurisdictions. The proposed use of Aave liquidity pools functions strictly as a modular funding conduit within Ether.fi Cash’s credit workflow; it neither transfers nor expands liabilities, fiduciary obligations, supervisory duties, or other regulatory burdens onto the Aave protocol or its governance participants.\nAccordingly, we discern no incremental compliance exposure for Aave and are supportive of proceeding with the integration, subject to the continued maintenance of the controls and safeguards outlined above.\n\n LlamaRisk - Monthly Community Update\n\n post by EzR3aL on Jun 2, 2025\n\n EzR3aL\n\n Regular\n\n Hello,\nis this considered a whitelable instance like Horizon and WLFI or this is an Aave market maintained by the DAO but only tailored to fit Ether.fi business model?\nWhat is being covered by whom?\nI would like to point to this proposal from me [ARFC] Strategic Opportunity Framework for Friendly Forks and Whitelabel Instances\nBecause I do think we are in a situation where we do need a framework that is not only clear on revenue sharing but also on responsibilites for a new market, depending on what it is going to be exactly.\nI assume that other SP probably have similiar questions as like I said, depending on what this exactly is going to be, they need to support it or now. Which will take ressources from these teams, slowing down other relevant tasks within the DAO.\nMy point is that we need to define clear rules on how to proceed with proposals like this in order to let everyone know what this means for their daily business and where and how the DAO benefits from this, or if its even beneficial.\nIn terms or numbers, can ACI or someone from Ether.fi give the DAO numbers on what they expect the potential revenue could be? This is important as this is the most important number for us, if the market in the end would be at a net loss for the DAO, because of operational work from SP then I would vote against the market. We already have several markets that are at loss for the DAO but need to be maintained in terms of risk, security and simply management.\n\n post by sid_areta on Jun 3, 2025\n\n sid_areta\n\n Orbit-Delegate\n\n We’re overall very much in favour of such a use case and it’s good to know @LlamaRisk that there are no regulatory issues with the implementation.\n@EzR3aL’s point is also fair - we need to know the projected revenue and how EtherFi plans to roll out the card, what the uptake is, etc., how exactly Aave will be marketed to users, and what the likely usage is. In a vacuum, the idea is very strong, but its success depends on granular implementation details which would be good to get more of an insight on.\n\n 1 month later\n\n post by bgdlabs on Jul 14, 2025\n\n bgdlabs\n\n Leader\n\n Linking here BGD’s approach to friendly fork, relevant for this proposal BGD. Our approach to Aave v3 friendly forks\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n Governance\n\n 4\n\n 551\n\n Apr 2025\n\n [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 6\n\n 1.2k\n\n Jul 9\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 3\n\n 536\n\n Jul 26\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d","tokens":4623,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262507869,"hash":"34f3fd90db80aa880578f3707bf24bbc155103ce"}
{"url":"https://soliditylang.org/blog/2020/07/08/solidity-turns-5/","domain":"soliditylang.org","title":"Solidity v0.1.0 turns 5! A walk down memory lane... | Solidity Programming Language","text":"Solidity v0.1.0 turns 5! A walk down memory lane...Posted by Franziska Heintel on July 8, 2020Announcements\nWith happiness and a tad of nostalgia, we'd like to share that Solidity v0.1.0 turns 5 years old today! (To be fair, v0.1.0 wasn't an actual release, but it marks the time where the Solidity team started appointing version numbers.) We are puzzled over how fast time flew by. We'd like to use this opportunity to take a look back and walk down the Solidity memory lane together with you.\nIn short: The Solidity language evolved rapidly, the ecosystem went through highs and lows, contributors came and went (but luckily most of them stuck around!) and we're still out here, still learning, still trying to push Solidity to the next, better stages.\nRead on for a retrospective of the last five years of language development, thoughts on the language design process, an overview of the people behind Solidity, and a short interview with Chris on the past, the present and the future of Solidity.\nThoughts on 5+ years of language design\nTrivia, important milestones and views on the language development process from 5+ years of Solidity development, courtesy of Alex' recent Solidity Summit talk. Thank you!\nDeveloping a language when everything around you is moving can be quite challenging. Here's our view on why Solidity used to and still needs to evolve rapidly - and why this is a good thing.\n1. Goals and value proposition of a programming language\nSolidity's initial goal was to become a friendly, easy-to-use language with the aim to attract developers and make the entry barrier to Ethereum development as low as possible.\nThat implied aspects like:\n\nJavaScript-like syntax.\nAllowing some weird implicit things.\nLacking features, but being easy to learn.\n\nOver the years, the goal changed. While still trying to stay as user-friendly as possible, the additional focus now rather lays on developing a much safer language.\nFor Solidity, that means:\n\nSolidity is verbose.\nSolidity is explicit.\nSolidity tries to highlight \"risky\" constructs (gas usage).\n\n2. Embedding Solidity as a valuable and practicable language into the Ethereum ecosystem\nThe ecosystem we develop in was and continues to be a moving target. This isn't necessarily a bad thing, however, it requires some additional flexibility and adaptability:\n\nEthereum in itself is constantly evolving and learning. Protocol and EVM developers are busy coming up with new features, new restrictions, repricings, even new protocols (Eth 2.0); most of which has an impact on the Solidity language design.\nDevelopers are still learning and frankly, sometimes trying all sorts of things. Here, from a language perspective, it's important to find the delicate balance between allowing too much, or too little.\nThe security community developed and matured alongside with Ethereum and it took some time for it to reach a healthy size and to build the necessary tools supporting their work.\n\nTo summarize: Building Ethereum is a (learning) journey. And so is building Solidity. Together with the broader Solidity community we're continuing to figure out:\n\nwhat features are needed or are bad.\nwhat is good or bad syntax.\nwhat is not enough or too much verbosity.\nhow to deliver changes quickly to developers.\n\n3. Steadily adjusting and improving the language design process\nSo far, questions around new features and implementation details have mostly been discussed in Github issues, the solidity-dev Gitter channel, and during the public Solidity development team meetings.\nThe first Solidity Summit, which was held virtually in May this year, was the next step to further expand the language design discussions and invite and engage a broader circle of experts, ranging from tool developers to Solidity power users, contributors, security researchers and auditors.\nCurrently, we're exploring more ways to interact with the aforementioned groups and include them better into the language design process.\n\nWe revived the solidity-users forum, where proposals for new language features and qualities of existing aspects of the language can be discussed.\nWe're sharing (feature) feedback surveys on a semi-regular basis.\nWe are regularly hosting dedicated language design discussion calls, where one topic/issue/feature implementation is debated per call.\n\nFor the future, we could imagine evaluating a more structured process for proposals, similar to Python Enhancement Proposals (PEPs) or Vyper Improvement Proposals (VIPs), which could be introduced step-by-step. However, we think it might be a bit too early for that at this point in time.\nIn any case, we're happy to hear your thoughts on how we can improve the language design process to be more collaborative. If you'd like to get involved and share your ideas, feel free to join the solidity-user forum!\nHighlights and milestones from v0.1.0 - v0.6.10\nFor a collection of notable Solidity events throughout the last years check out the roadmap below!\n\nThe people behind Solidity\nA programming language is nothing without its community, its maintainers and developers building cool stuff with it! That’s why we would like to thank the core team and more importantly the community contributors for their continued support over all these years.\nThe core team\nThe Solidity programming language is an open-source, community project mainly developed and maintained by a core team. The core team is sponsored by the Ethereum Foundation.\nThis team currently consists of @a3d4, @aarlt, @axic, @bshastry, @cameel, @chriseth, @christianparpart, @ekpyron, @franzihei, @hrkrshnn, @leonardoalt, @marenz, and @mijovic.\nThe wider community & contributors\nWe are incredibly grateful for all community contributions, not only via commits but also via participation in Github issues, by filing bug reports or in other community functions. Also a shout-out to our former team members!\nWe'd especially like to thank (in alphabetical order) @arkpar, @asinyagin, @benjaminion, @bobsummerwill, @chfast, @ChrisChinchilla, @Denton-L, @djudjuu, @elopio, @erak, @ethers, @federicobond, @fulldecent, @gavofyork, @ghallak, @guanqun, @jamesray1, @jvmaia, @LefterisJP, @liangdzou, @LianaHus, @mocamircea, @NicolaiSoeborg, @pirapira, @random-internet-cat, @roadriverrail, @sifmelcara, @VoR0220, @winsvega.\nNote that this is a non-exhaustive list. There are certainly many more great contributors, however, listing all of them would go beyond the scope of this article. 😊\nThe past, the present and the future of Solidity: Interview with Christian Reitwiessner\nCan you tell us a bit about the beginnings of Solidity? What changed most about your work on Solidity between now and then?\nThe biggest difference between now and then is that back in the days you basically did not know if somebody would ever use what we are building. Of course we maybe had the feeling it is going to be something big, but we did not know for sure. Now, Solidity is a product which we are continuing to improve while it is out there in production, being used, holding incredible amounts of value and powering some really cool decentralized applications.\nAnother difference is that in the beginnings, it seemed easier to get feedback. Maybe this was due to the fact that the community was much smaller. The conversations seemed more technical in a way. Now, the community became bigger and more diverse (which is a great thing!). With that it became a bit more complex in terms of collaboration and feedback especially on technical implementation details.\nLooking back, what was your most memorable moment of the past 5 years of Solidity development?\nThere were many - people using the compiler before it even had a command line interface, people happily picking up the newest features, seeing the ecosystem grow and especially finally meeting people in real life you have been working with for so long.\nWhat is your favorite aspect about Solidity?\nSolidity looks rather high-level but is still very close to the EVM. At the same time, people with some background in programming usually understand what Solidity code is about.\nWhere do you think Solidity needs to improve the most?\nIt needs to be even easier to write safe smart contracts. This means we need to work on our SMTChecker, debuggers, IDEs, templates, libraries and so on.\nWhat does Eth2 mean for Solidity?\nOn the technical level, it means we have to focus more on the Ewasm backend of Solidity, but this is a relatively straightforward task. On the conceptual level, on the other hand, it means that smart contracts will be asynchronous, which is a big challenge for everyone. The atomicity of the EVM makes many things very easy: If something is odd, just revert. Solidity needs to find a good language construct that makes the danger of asynchrony visible but also helps avoiding some pitfalls and allows the \"common use-case\" to be easy to write.\nAnything else you would like to say?\nLet's continue our journey to make smart contracts as safe and accessible to everyone as possible!\nWith that being said, we'd like to wrap this little birthday celebration up and close with a virtual toast:\nTo all the contributors over the last years: Your input, dedication and work has been incredible. THANK YOU. To the next 5 years! 🍾Previous postNext post","tokens":2319,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262508403,"hash":"c9648f4c29f0c1c6819fe9c70b3f181ba44854ff"}
{"url":"https://governance.aave.com/t/temp-check-aave-and-ether-fi-cash-a-proposal-for-real-world-utility/21813","domain":"governance.aave.com","title":"[TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility - Governance - Aave","text":"[TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n [TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n Author: ACI & Ether.fi\n\n Date: 2025-04-15\n\n Overview\n\n Summary\n\n Motivation\n\n Card Program\n\n Implementation details & profit share\n\n Implementation Timeline\n\n Disclaimer\n\n Next Steps\n\n Copyright\n\n Apr 2025\n\n 1 / 6\n\n Apr 2025\n\n Apr 2025\n\n post by ACI on Apr 15, 2025\n\n ACI\n\n Leader\n\n [TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\nAuthor: ACI & Ether.fi\nDate: 2025-04-15\n\nOverview\nThis proposal outlines a partnership between Aave and ether.fi, with the goal of creating a unique Aave market on an EVM L2 to facilitate on-chain credit for everyday payments through the ether.fi Cash credit card program. This collaboration aims to benefit both platforms by continuing to expand their user bases and driving innovation in DeFi with a focus on bridging the gap between DeFi and real-world consumer applications.\nSummary\nThe ether.fi market was launched on Aave back in September, with the goal of laying the groundwork for a unique instance of Aave, focused at stablecoin borrowing against interest accruing collateral. This market has since been idle, while the development of ether.fi Cash continued to take shape.\nAs we prepare for the next phase of the rollout plan, we propose migration of this market to an optimized Layer 2 market designed specifically for consumer credit applications. Since then, it was determined that ether.fi needs a more tailored instance of the Aave market, with the focus of allowing for more flexibility in asset listings and parameters, along with less expensive transaction fees. This market will feature tailored parameters and asset listings optimized for real-world spending, supported by a competitive card program offering up to 3% cashback.\nMotivation\nThe traditional credit card industry continues to charge excessive interest rates (often 20%+). By leveraging collateral assets that permit users to continuously earn interest on the positions held in their wallets, naturally offsetting borrowing costs. This market will create a virtuous cycle where a user’s digital assets work to pay down their credit. With this, we can provide users with:\n\nSignificantly lower borrowing costs compared to traditional credit cards\nCompetitive rewards (up to 3% cashback)\nEfficient use of interest bearing asset positions as collateral, allowing users to keep their positions on chain and in their own custody\nMinimal transaction costs through L2 deployment\n\nThis proposal continues to build on the fundamental differences that DeFi has to offer. The future of ether.fi cash will be a system that provides both retail and corporate users with a truly native on-chain solution that does not sacrifice any of the features that consumers have become accustomed to with everyday spending.\nCard Program\nThe ether.fi Cash credit card is set to change everyday spending by bringing self custodied DeFi-powered credit to the world’s largest payment network. With universal acceptance at over 80 million merchants globally, users can access their DeFi credit lines for daily purchases while earning cashback rewards on all expenditures. The upcoming neo-banking alternative mobile app, launching in early Q2 2025, will evolve to provide a comprehensive suite of financial tools including real-time transaction monitoring, expense categorization, budget tracking, and intelligent position management. Corporates and retail users can instantly create multiple virtual cards, manage spending limits, and track rewards - all while their collateral works for them in the background through the Aave market. The app would integrate directly with the custom Aave instance, offering automated position management, smart liquidation protection, and dynamic credit line adjustments based on collateral value. Capital efficiency in this market will be further realized with the launch of Aave V4, utilizing available stable liquidity through the hub and spoke model.\nBy Q4, the platform plans to incorporate AI-powered trading strategies and financial insights, along with predictive budgeting tools, completing the vision of a truly on-chain banking alternative experience powered by DeFi. This will allow for a complete reimagining of on-chain credit, where the efficiency of DeFi meets the convenience of traditional payment networks, all optimized through a dedicated L2 deployment for minimal transaction costs. This vision will be coupled with the battle tested Aave market, along with risk monitoring provided by Chaos Labs.\nThrough this vision, ether.fi would also look to collaborate with Aave to offer a unique co-branded credit card for a unique set of users.\nImplementation details & profit share\nWe believe in strategic partnerships that are built for sustainable growth and fair value distribution. That’s why we’re proposing a straightforward revenue sharing model where 15% of the interest rate spread goes directly to the Aave DAO. This creates a win-win scenario where protocol growth directly benefits both ecosystems.\n\nFor the initial 6 months, 20% of the interest rate spread allocated to Aave DAO\nAfter the initial 6 months, 15% of the interest rate spread allocated to Aave DAO\nTransparent revenue distribution mechanism\nQuarterly reporting on market performance and revenue generation\n\nThis will allow for scalable infrastructure that is ready for mass adoption.\nImplementation Timeline\n\nQ2 2025: L2 market deployment with defined assets supported\nEarly Q2 2025: Card program launch to public (currently in closed beta)\nQ3 2025: Enhanced features rollout\nQ4 2025: Program optimization based on usage data\n\nDisclaimer\nThis proposal is powered by Skywards. ACI is not directly affiliated with ether.fi and did not receive compensation for creating this proposal.\nNext Steps\n\nIf consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage\nPublication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage\nIf the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal\n\nCopyright\nCopyright and related rights waived under CC0\n\n [ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n 3\n\n post by ACI on Apr 23, 2025\n\n ACI\n\n Leader\n\n The current proposal has been escalated to TEMP CHECK Snapshot.\nVote will start tomorrow, we encourage everyone to participate.\n\n post by sid_areta on Apr 23, 2025\n\n sid_areta\n\n Orbit-Delegate\n\n The idea for Aave to be used as a critical component of onchain credit for everyday payments is very compelling and probably the way Aave and decentralised lending was intended to be used in the first place. We’re very much in favour of expanding Aave to cover more real-world use cases, and are excited about the potential of this proposal, as well as ether.fi’s upcoming roadmap of becoming an onchain banking experience powered by DeFi.\nThe only question we’d have is around the revenue share and whether this is in line with best practice / the precedent we want to set going forward. We’d like to see other contributors like @EzR3aL who have been thinking about the DAO’s framework for revenue sharing opine here as well.\n\n Areta Delegate Platform\n\n post by EzR3aL on Apr 23, 2025\n\n EzR3aL\n\n Regular\n\n The proposal is very interesting, as it clearly shows Aave’s unique position in the lending space. It’s truly the backbone of different lending usecases.\nHere now specialized for for payments.\nAnd like @sid_areta mentioned I am currently working on an updated proposal for the friendly fork framework.\nBut I do think this situation is a bit different as this market is not really about a fork nor a Whitelabel instance managed by someone else. It’s rather a request towards the DAO for an Ether.fi optimized market.\nLooking at the revenue sharing I’m unsure how much this could be for the DAO. As simple metrics for the product are missing like issued cards, active user, average spending per month, etc.\nSo for the moment I would support this proposal in its way as my framework hasn’t been posted yet.\n\n post by ACI on Apr 27, 2025\n\n ACI\n\n Leader\n\n After Snapshot monitoring, the current TEMP CHECK Snapshot ended recently, reaching out both Quorum and YAE as winning option with 568.3K votes.\nTherefore [TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility has PASSED.\nNext step will be the publication of an ARFC to continue gathering interest from both community and Service Providers.\nClosing topic to focus on ARFC.\n\n Closed on Apr 27, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave and ether.fi Cash: A Proposal for Real-World Utility\n\n Governance\n\n 4\n\n 550\n\n Jul 2025\n\n [TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 6\n\n 1.2k\n\n Jul 9\n\n [ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash\n\n General\n\n 3\n\n 536\n\n Jul 26\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d","tokens":2366,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262518364,"hash":"c318909f5c12ada35024de5e8c697ed095ec73fb"}
{"url":"https://forum.soliditylang.org/","domain":"forum.soliditylang.org","title":"Solidity Forum - The place for all Solidity developers, tool builders, auditors and language contributors","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n All latest topics\n\n categories\n\n Latest\n\n Hot\n\n Categories\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Read this before posting! \n\n Announcements\n\n Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter …\n\n read more\n\n 0\n\n 4.4k\n\n Dec 2020\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 54\n\n 26d\n\n [Request For Comments] - Contract Composition in Core Solidity\n\n Uncategorized\n\n 6\n\n 244\n\n Aug 25\n\n [Call for feedback] The Long-term Solidity Roadmap\n\n Feedback\n\n 20\n\n 1.6k\n\n Aug 19\n\n Eager require evaluation is unexpected\n\n Language Design\n\n 2\n\n 93\n\n Aug 4\n\n ABI Encoding Under Rising Calldata Costs\n\n Uncategorized\n\n 2\n\n 209\n\n Jul 20\n\n Is Core Solidity versioned as Solidity 0.9?\n\n Uncategorized\n\n 3\n\n 122\n\n Jun 29\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Solidity Needs Consistent Semantics\n\n Language Design\n\n 5\n\n 360\n\n Jun 22\n\n Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 190\n\n Jun 9\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 119\n\n Jun 9\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n Documentation\n\n 2\n\n 148\n\n Jun 2\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 82\n\n Jun 2\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 121\n\n Apr 18\n\n [Deprecation feedback] Niche distribution channels for compiler binaries\n\n Feedback\n\n 5\n\n 436\n\n Apr 12\n\n Ora: comptime-first, solver-in-workflow EVM language\n\n Language Design\n\n 3\n\n 181\n\n Feb 28\n\n The assembly/solidity distinction was a mistake, don’t repeat in Solidity Core!\n\n Language Design\n\n 5\n\n 378\n\n Feb 26\n\n Request new syntax for Solidity\n\n Uncategorized\n\n 3\n\n 193\n\n Feb 17\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 180\n\n Dec 2025\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n [Call for feedback] Core Solidity Deep Dive\n\n Uncategorized\n\n 5\n\n 613\n\n Dec 2025\n\n Can someone explain how via-ir works?\n\n Tools & Infrastructure\n\n 4\n\n 3.6k\n\n Dec 2025\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 108\n\n Oct 2025","tokens":1568,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262520086,"hash":"dd7ddb951845704f8627b5d66dc1018350ad393b"}
{"url":"https://ethresear.ch/t/what-if-post-quantum-ethereum-doesn-t-need-signatures-at-all/24427/28","domain":"ethresear.ch","title":"What if post-quantum Ethereum doesn’t need signatures at all? - zk-s[nt]arks - Ethereum Research","text":"zk-s[nt]arks\n\n post-quantum\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 6\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n Mar 17\n\n 18 / 18\n\n Jul 2\n\n Jul 2\n\n post by 0xjasonw on Mar 17\n\n 0xjasonw\n\n What if post-quantum Ethereum doesn’t need signatures at all?\nTL;DR: Current PQC migration plans assume we must verify post-quantum signatures — either on-chain (kilobytes per tx) or inside ZK circuits (millions of constraints). We present an alternative: prove authorization semantics directly in ZK, without any signature object. Result: 4,024 R1CS constraints, 128-byte proofs, 52 ms proving time. The construction is proof-system agnostic (Groth16, PLONK, STARKs all work) and deployable today as an AA validator module — no protocol changes required.\n\nMotivation: The PQC data wall\nThe community has been actively exploring PQC migration paths (13) and the core tension is well-known:\n\nScheme\nSig Size\nPublic Key\nTotal per TX\n\nML-DSA-44 (Level 2)\n2,420 B\n1,312 B\n3,732 B\n\nML-DSA-65 (Level 3)\n3,309 B\n1,952 B\n5,261 B\n\nML-DSA-87 (Level 5)\n4,627 B\n2,592 B\n7,219 B\n\nSLH-DSA-128f\n17,088 B\n32 B\n17,120 B\n\nFN-DSA-512\n~666 B\n897 B\n1,563 B\n\nEd25519 (classical)\n64 B\n32 B\n96 B\n\nThat’s a 30-60x increase in authorization data per transaction. In rollup architectures where calldata/blob space is explicitly priced, this is a first-order scalability problem.\nThe “obvious” solution and why it’s expensive\nThe natural response is: verify PQ signatures inside ZK circuits, post only the succinct proof on-chain.\nThe problem: lattice-based signature verification requires NTTs over degree-256 polynomial rings in \\mathbb{Z}_qℤ𝑞 (q = 2^{23} - 2^{13} + 1𝑞 =223 −213 +1), emulated over a ~254-bit proof-system field. Structural lower bounds:\n\nIn-circuit verification\nR1CS constraints\nDominant cost\n\nML-DSA-44 verify\n≥ 2M\n4×4 NTTs + non-native mod. arith.\n\nML-DSA-65 verify\n≥ 4M\n6×5 NTTs + non-native mod. arith.\n\nFN-DSA-512 verify\n≥ 1M\nFFT + Gram-Schmidt + mod. arith.\n\nSLH-DSA verify\n≥ 5M\nWOTS+ chains + Merkle trees\n\nECDSA verify (classical)\n~1.5M\nscalar mul. + mod. inverse\n\nEven with optimized gadgets, we’re looking at millions of constraints just to prove “this signature is valid.”\nKey observation: authorization ≠ signatures\nHere’s the thing: at the consensus layer, blockchains don’t actually require verification of a specific signature object. What consensus requires is assurance that a transaction was authorized by the correct entity.\nSignatures are an implementation artifact for expressing authorization — not authorization itself. We’ve been conflating the two.\nZK-ACE: identity-centric authorization\nWe present ZK-ACE (Zero-Knowledge Authorization for Cryptographic Entities), which takes this observation to its logical conclusion:\n\nDon’t verify signatures in ZK. Don’t compress signatures. Eliminate signature objects from the authorization path entirely.\n\nInstead, the chain stores a compact identity commitment (32 bytes):\n\nID_{com} = H(REV \\| salt \\| domain)\n𝐼𝐷𝑐𝑜𝑚=𝐻(𝑅𝐸𝑉‖𝑠𝑎𝑙𝑡‖𝑑𝑜𝑚𝑎𝑖𝑛)\nwhere REV𝑅𝐸𝑉 is a 256-bit identity root derived from a deterministic identity derivation primitive (DIDP). Each transaction carries a ZK proof attesting:\n\n(C1) Commitment consistency: Prover knows a preimage of ID_{com}𝐼𝐷𝑐𝑜𝑚\n(C2) Derivation correctness: A target-binding hash is consistent with deterministic key derivation under the identity root\n(C3) Authorization binding: The identity root has authorized this specific TxHash𝑇𝑥𝐻𝑎𝑠ℎ\n(C4) Anti-replay: Nonce commitment or nullifier is correctly derived\n(C5) Domain separation: All bindings use the declared chain/domain tag\n\nThe entire circuit is 5 Poseidon hash invocations + equality constraints. No lattice arithmetic. No signature verification logic. No non-native field emulation.\nBenchmarks (reference implementation)\nImplementation: arkworks + Groth16 over BN254, Poseidon (t=3𝑡 =3, \\alpha=17𝛼 =17, 8 full + 57 partial rounds).\nCircuit size:\n\nConstraint\nInputs\nHash calls\nR1CS\n\n(C1) Commitment consistency\n3\n1\n805\n\n(C2) Derivation correctness\n4+1\n2\n1,200\n\n(C3) Authorization binding\n7\n1\n1,615\n\n(C4) Replay prevention\n2\n1\n400\n\n(C5) Domain sep. + enforce_equal\n—\n—\n4\n\nTotal\n\n5\n4,024\n\nBoth replay modes (nonce-registry and nullifier-set) produce identical constraint counts.\nPerformance (single-threaded, Apple M3 Pro, Criterion.rs, 100 samples):\n\nOperation\nMedian\n95% CI\n\nTrusted setup (one-time)\n45.6 ms\n[45.4, 45.8] ms\n\nProve (per transaction)\n52.3 ms\n[51.5, 53.4] ms\n\nVerify (per transaction)\n604 μs\n[600, 608] μs\n\nProof size:\n\nEncoding\nProof\nPublic inputs\nTotal auth data\n\nCompressed Groth16\n128 B\n160 B (5 × 32 B)\n288 B\n\nCompression vs. PQ signatures:\n\nScheme\nPQ sig+pk\nZK-ACE\nReduction\n\nML-DSA-44 (Level 2)\n3,732 B\n288 B\n13x (92.3%)\n\nML-DSA-65 (Level 3)\n5,261 B\n288 B\n18x (94.5%)\n\nML-DSA-87 (Level 5)\n7,219 B\n288 B\n25x (96.0%)\n\nSLH-DSA-128f\n17,120 B\n288 B\n59x (98.3%)\n\nConstraint comparison (the core result):\n\nApproach\nR1CS constraints\n\nZK-ACE (this work)\n4,024\n\nIn-circuit ML-DSA-44 verify\n≥ 2,000,000\n\nIn-circuit ECDSA verify\n~1,500,000\n\nThat’s a ~500x constraint reduction — not from optimizing signature verification, but from not doing it at all.\nDeployment: AA validator module\nZK-ACE is designed as an ERC-4337 validator module. In an AA wallet:\n\nThe account validation logic invokes ZK-ACE verification instead of checking a classical or PQ signature\nProof generation happens client-side (~52 ms)\nThe bundler transports proof + public inputs (untrusted, learns nothing)\nOn-chain verification costs ~604 μs per proof\n\nThis means no protocol-level changes are required. ZK-ACE can be deployed on existing infrastructure.\nProof-system agnostic by design\nAn important design property: ZK-ACE is a protocol-level authorization model, not a proof-system-specific construction. The five constraints (C1)–(C5) are stated over abstract hash evaluations and equality checks. They can be instantiated with:\n\nProof system\nSetup\nProof size\nTrade-off\n\nGroth16 (reference impl.)\nTrusted (per-circuit)\n128 B\nSmallest proof, fastest verify\n\nPLONK / KZG\nUniversal (one-time)\n~400–600 B\nNo per-circuit setup\n\nSTARKs / FRI\nTransparent (none)\n~40–100 KB\nNo trusted setup, plausibly PQ-secure\n\nBulletproofs / IPA\nTransparent\n~700 B\nNo setup, larger verify cost\n\nThe benchmarks above use Groth16 because it gives the tightest numbers, but the protocol doesn’t depend on it. In particular, a STARK instantiation would make the entire authorization pipeline plausibly post-quantum at the proof layer as well — no trusted setup, no pairing assumptions, hash-based soundness only. The identity commitments are proof-system-agnostic (they’re just hash outputs), so migrating from one proof system to another does not require identity rotation or re-registration.\nThe security reductions in the paper are stated generically in terms of knowledge-soundness advantage \\text{Adv}^{ks}Adv𝑘𝑠 and are compatible with any backend satisfying completeness, knowledge soundness, zero-knowledge, and public-input binding.\nAssumed primitive: DIDP\nZK-ACE assumes a Deterministic Identity Derivation Primitive (DIDP) as a black box — any framework providing:\n\nDeterministic key derivation from a high-entropy root\nContext isolation across derivation paths\nIdentity-root recovery hardness\n\nThis is not tied to any specific construction. A simple HKDF(root, context) satisfies the interface. We provide ACE-GF as an instantiation; any KDF with domain separation works.\nSecurity\nFour game-based security definitions with reduction-based proofs under standard assumptions:\n\nAuthorization soundness → reduces to knowledge soundness + collision resistance + DIDP recovery hardness\nReplay resistance → reduces to authorization soundness + verifier enforcement\nSubstitution resistance → reduces to public-input binding of the proof system\nCross-domain separation → reduces to collision resistance + public-input binding\n\nFull proofs in the paper.\nWhat this is NOT\nTo be explicit:\n\nNot ZK-verification of PQ signatures (we don’t verify any signature inside the circuit)\nNot signature compression (we eliminate signatures, not shrink them)\nNot a new signature scheme\nNot dependent on any specific identity framework\n\nIt’s a change in what we prove: from “this signature is valid” to “this identity authorized this transaction.”\nRelation to existing discussions\nThis work connects to the ongoing PQC migration discourse:\n\nSo you wanna Post-Quantum Ethereum transaction signature identified the AA path for PQC\nThe road to Post-Quantum Ethereum transaction is paved with AA demonstrated Falcon verification via AA\nPoqeth benchmarked PQ signature verification on-chain\n\nThese approaches all preserve the signature-centric model. ZK-ACE asks: what if we don’t?\n\nPaper: ZK-ACE: Identity-Centric Zero-Knowledge Authorization for Post-Quantum Blockchain Systems\nReference implementation: github.com/ya-xyz/zk-ace\n\n Exploring the Design Space for a Post-Quantum Public Key Registry for Ethereum Validators\n\n So you wanna Post-Quantum Ethereum transaction signature\n\n Towards Native Post-Quantum Private ETH\n\n 8\n\n 6\n\n 2\n\n 2\n\n read \n\n 9\n min\n\n post by uulong950 on Mar 17\n\n uulong950\n\n Brilliant write-up and a very elegant paradigm shift away from signature-centric verification. The 4,024 R1CS constraint reduction is massive for AA validator modules.\nI want to specifically touch on your point regarding the STARKs / FRI instantiation being the ideal path for a fully transparent, plausibly PQ-secure authorization layer. Historically, the pushback against using STARKs for client-side or decentralized AA proving has been the severe hardware requirements and proving latency at scale.\nI recently open-sourced the Qingming ZKP Engine, which directly attacks this FRI proving bottleneck using consumer-grade AMD GPUs (ROCm/HIP), and I believe it could make the STARK instantiation of ZK-ACE highly practical today without needing enterprise clusters.\nBy taking over the unsafe pointer lifecycle in Rust to bypass standard memory transfers and mapping arrays directly to the AMD 96MB Infinity Cache (Zero-Copy), alongside mathematically reducing the Fermat modular inversions in the fold loop into O(1) scalar multiplications (Zero-Inversions), we achieved the following on a single $999 RX 7900 XTX:\n\nNTT (2242^{24}224 scale): 18.94 ms\n\nMerkle Tree (L0): 763.3 ms\n\nFRI Prove (End-to-End, 16.7M leaves): 2.56 s\n\nIf your ZK-ACE identity commitments and authorization bindings were instantiated over a Goldilocks field STARK, the proving time on consumer hardware would be virtually instantaneous with this engine.\nWould love for you or anyone in the AA/PQC research space to check out the host-side benchmark logic. This kind of hardware-layer dimensionality reduction might perfectly complement the architectural dimensionality reduction you just presented.\nGitHub: qingming-zkp\n\n post by 0xjasonw on Mar 23\n\n 0xjasonw\n\n This is an amazing benchmark — phenomenal work on the Zero-Copy + Zero-Inversions approach. The 2.56s end-to-end FRI prove on a consumer RX 7900 XTX is a game-changer for decentralized proving.\nYour Qingming ZKP engine and ZK-ACE form a strong complementary pair — your hardware-layer dimensionality reduction directly addresses the proving latency bottleneck we identified as the primary trade-off when choosing STARKs over Groth16.\nSome context on where this could plug in: I’m building an MVP for a new L1 blockchain with an n-VM runtime architecture that natively executes EVM (revm Shanghai), SVM (Solana), BVM (Bitcoin Script), and TVM — all within a unified state tree. The chain runs dual-algorithm native cryptography: classical Ed25519 and post-quantum ML-DSA-44 (FIPS 204) in parallel at every protocol level.\nBased on our architectural modeling, the n-VM runtime projects the following throughput estimates:\n\nTheoretical EVM ceiling: 20,000–100,000 TPS (single-core to parallel scheduling)\nProjected sustained (simple transfers): 3,000–5,000 TPS\nProjected sustained (complex contracts, e.g. DEX swaps): 500–1,500 TPS\nProjected sustained (mixed workload): 1,000–3,000 TPS\n\nThese figures are before ZK proving enters the critical path. If Qingming’s GPU-accelerated FRI could handle our per-block STARK proof generation at sub-second latency on consumer hardware, it would remove the last major bottleneck standing between our architecture and true sub-second cryptographic hard finality — without requiring enterprise GPU clusters.\nWould love to explore integration. The combination of your hardware-layer optimization with our protocol-layer identity–authorization separation could be quite compelling.\n\n post by 0xjasonw on Mar 23\n\n 0xjasonw\n\n P.S. — Actually we’ve already implemented the MVP: 3-node devnet with block production, on-chain ML-DSA-44 signed transfers, leader rotation, and a browser-based explorer. One observation from our architectural analysis: because ML-DSA-44 verification (~50μs) is actually faster than Ed25519 (~76μs), and our ZK-ACE attestation model eliminates per-transaction signature verification from the critical path entirely, our runtime can achieve throughput comparable to or exceeding current Solana mainnet TPS — even when every transaction is authorized with post-quantum credentials. To our knowledge, this would make it the first blockchain architecture where post-quantum cryptography imposes zero performance penalty relative to classical algorithms, potentially making it production-viable as a PQC-native L1 today rather than as a future migration target.\nBeyond ZK proving, we’re facing a number of Rust-level performance optimization challenges across the runtime — state I/O, parallel scheduling, gossipsub propagation. Having looked through your Qingming codebase, your expertise in low-level Rust + GPU optimization is exactly the kind of skill set that could accelerate this work significantly. Would it be okay if I DM you?\n\n 10 days later\n\n post by 0xjasonw on Apr 2\n\n 0xjasonw\n\n Update: Dual-Backend Implementation with Circle STARK (Post-Quantum Secure)\nSince the original post, ZK-ACE has been significantly rearchitected. The key updates:\n1. Pluggable dual-backend architecture is now implemented and benchmarked.\nThe original post described a Groth16-only prototype. The reference implementation now ships two compile-time selectable backends:\n\nAspect\nCircle STARK (Stwo) — default\nGroth16/BN254\n\nField\nMersenne-31\nBN254 Fr (~254-bit)\n\nHash\nPoseidon2 (width=16)\nPoseidon (width=3)\n\nConstraints\n~240 AIR\n~1,200 R1CS\n\nProve\n21 ms\n44 ms\n\nVerify\n1.1 ms\n1.5 ms\n\nProof size\n~105 KB\n128 B\n\nPQ-secure\nYes\nNo\n\nSetup\nTransparent\nTrusted\n\nBenchmarked on Apple Silicon, Criterion.rs medians, single-threaded.\n2. Constraint count correction. The original post reported 4,024 R1CS constraints from an early prototype. The production Groth16 circuit is ~1,200 R1CS. The STARK backend compiles to ~240 AIR constraints. Both remain roughly three orders of magnitude smaller than in-circuit ML-DSA verification.\n3. The STARK backend is faster than Groth16. This is counterintuitive but follows directly from field arithmetic: M31 operations (31-bit) are an order of magnitude cheaper than BN254 (254-bit), and STARK proving requires no elliptic curve MSMs. For small circuits, this advantage dominates.\n4. On-chain cost with mandatory STARK aggregation:\nIndividual STARK proofs (~105 KB) never go on-chain. The block builder aggregates all per-transaction proofs into a single batch proof. Per-transaction on-chain data is only the public inputs:\n\nModel\nPer-tx on-chain\n\nML-DSA-65 (direct)\n~5,261 B\n\nZK-ACE STARK (aggregated)\n~160 B\n\nZK-ACE Groth16\n~288 B\n\nThis is a 32x compression vs ML-DSA-65 under the STARK model, with full post-quantum security and transparent setup.\n5. The entire authorization path is now PQ-secure. Under the STARK backend, identity commitment → proof generation → on-chain verification relies only on hash functions (Poseidon2 + Blake2s). No elliptic curve assumptions anywhere.\nThe Groth16 backend remains available for EVM-native deployments where proof compactness matters more than PQ security.\nCode: github.com/acechain-io/zk-ace\nPaper: arXiv:2603.07974\n\n post by 71104 on Apr 6\n\n 71104\n\n Basically STARKing an HMAC? Cool!\n\n 8 days later\n\n post by 0xjasonw on Apr 14\n\n 0xjasonw\n\n Yes. It’s super cool actually. we elimiated PQC performance penalty completely. We reached 570+ TPS on both ed25519 and ML-DSA-44 on the local 3-node devnet on a MacBook Pro M3 with 12 core and36G RAM. I believe we are the first one that can eliminate PQC performance penalty and reach such high TPS on a commodity device.\n\n post by 71104 on Apr 14\n\n 71104\n\n I think the biggest innovation coming from your proposal is that you’re connecting two different areas of cryptography that don’t seem to have managed to talk to each other so far. Up until now it was common knowledge that an HMAC scheme can replace signatures only in a symmetric setting because both the “signer” and the verifier need to know the secret key, but zkS{N,T}ARKs change that completely indeed! Now a verifier can reliably verify an HMAC without having to know the secret key, just like in asymmetric cryptography!\nThe resulting “signature” scheme will probably never be as efficient as an actual signature: Dilithium signatures are very large but zkSTARKs are even larger, unfortunately. But this idea has the advantage of being highly aggregatable: if all transaction signatures are “STARK’d HMACs” you get to prove a whole block with a single zkSTARK easy. While verifying Dilithium in AIR… good luck with that.\nVery cool idea, thanks for sharing it!\nI’ll be honest, I seem to be somewhat of a competitor of yours. I co-founded a brand new, post-quantum L1 project and after reading this thread we’ve totally decided to follow this pattern.\nPS: in our project we’re gonna call this pattern “zkMAC”. The name fits much better than “zkACE”.\n\n post by 0xjasonw on Apr 15\n\n 0xjasonw\n\n Hi 71004,\nGlad to see you are interested in adopting this technology!\nSince you are looking to integrate this pattern into an L1 project, instead of fragmenting the effort with a separate implementation, I’d like to invite you to contribute directly to the original ACE repository.\nCollaborating on the upstream source is the best way to support the open-source community, and it ensures the tech stays standardized and robust for everyone. It would be much more efficient for the ecosystem to have a single, well-audited implementation than multiple divergent ones.\nLet’s work together to make ACE the standard for zk-based MACs — I actually think “zkMAC” is a great technical descriptor for this construction! What do you think?\n\n 1 month later\n\n post by 71104 on May 17\n\n 71104\n\nI’ve been re-reading this part, why are 5 hashes needed? It looks to me like 2 are sufficient: one to compute the identity commitment and another one to HMAC the message.\nI’ve recently finished implementing this scheme in my project Libernet and that’s how I did it. This is the reusable chip: crypto/src/hmac.rs at d653000d3f3d21c671fac8cb6857e86afd677460 · libernet-mirror/crypto · GitHub\n(I used a terminology that resembles actual signatures: I called your “REV” simply “private key” and your “identity commitment” simply “public key”.)\n\n post by 0xjasonw on May 25\n\n 0xjasonw\n\n Deleted previous one by mistake.\nThanks for the rigorous engineering insights, Alberto! The 2-call variant utilizing Poseidon’s sequential Absorb state is a fantastic optimization and significantly reduces the R1CS constraints.\nRegarding the terminology, I noticed you referred to REV𝑅𝐸𝑉 as ‘private key’ and ID_{com}𝐼𝐷𝑐𝑜𝑚 as ‘public key’ in Libernet. While I understand the intuition behind using classical signature terms for familiarity, I strongly recommend adhering to the original ZK-ACE terminology (REV𝑅𝐸𝑉 / Identity Commitment). >\nIntroducing standard key pairs (PK/SK) syntax into an identity-centric authorization path can cause major conceptual confusion for developers. In ZK-ACE, the authorization semantics are explicitly decoupled from traditional signature verification objects.\nTo ensure we build a unified, interoperable standard for the broader post-quantum Ethereum ecosystem without fragmentation, let’s keep the codebase and implementation aligned under the ZK-ACE architecture. Looking forward to benchmarking your optimized pipeline further!\n\n post by 0xjasonw on May 25\n\n 0xjasonw\n\n Hi Citrullin,\nCan you give me any clue on how to apply this to Social Dynamics. I’m interested in social science very much. I’m drafting some papers in social science actually. will share with you when published\n\n post by 71104 on May 27\n\n 71104\n\nI was looking at this table again. I’m not sure that Poseidon2 is still quantum-safe when it runs over such a small field as Mersenne-31, even if you’re using a state vector width of 16. For sure it would be utterly broken if the state width was 2 (even a classical computer can break that in a matter of seconds), so the question is whether or not the 16 elements of the state vector can be attacked individually, and whether or not Grover’s algorithm provides any advantages in that regard. I don’t know Poseidon2 well enough to speak for that, but for the best level of quantum-safety I think it’s best to use a 256-bit field.\nAnother odd choice you made is AIR arithmetization. AIR takes 4 extra columns for the memory argument, but for “zkMAC” the only equality constraint you really need is the one proving that the secret key used to derive the identity commitment is the same used to hash the HMAC. Memory is a complete overkill here, I think the permutation argument is much better in this case. You’d probably get better results with TurboPLONK.\n\n post by 71104 on May 27\n\n 71104\n\nOkay, I’ve just reviewed the original Poseidon2 paper. The proposed instantiations are on page 16, table 1, and the paper targets 128-bit classical security.\nThe classical security of Poseidon2 is generally \\frac{c}2𝑐2 bits, where c𝑐 is the total bit size of the capacity columns. Under Grover that becomes \\frac{c}4𝑐4.\nYour instantiation is the one in the first row of the table, with c = 8 \\cdot 31 = 248𝑐 =8 ⋅31 =248, making for ~124 bits of classical security and ~62 bits under Grover. That’s insufficient.\nThe instantiation at the second row of the table adds 8 more capacity columns and works much better for quantum safety: now we have c = 16 \\cdot 31 = 496𝑐 =16 ⋅31 =496, so everything is doubled – ~248 bits of classical security and 124 bits under Grover. ✓\nYou may want to re-run your numbers for quantum safety. You need to add 8 columns and they aren’t gonna be free – it’s 8 more NTTs. The number of partial rounds also jumps to 22, so there will be more constraints and you’ll almost certainly exceed the next power of 2 and double your circuit size.\n\n 1 month later\n\n post by uulong950 on Jun 30\n\n uulong950\n\n 0xjasonw\n\n Hi Jason — apologies for the very delayed reply. I had been away from ethresear.ch for a while and missed your follow-up. Thank you for the thoughtful response.\nYes, absolutely — feel free to DM me.\nSince my earlier comment, I have been trying to frame Qingming more precisely. I now think the cleanest description is not simply “a fast NTT benchmark”, but a native Goldilocks LDE boundary test for STARK proving.\nThe latest Qingming G64 NTT work is here:\nThe target workload is deliberately native rather than a proxy benchmark:\n\nField: Goldilocks / G64\n\nModulus: p = 2^64 - 2^32 + 1\n\nLogical data size: 2^24\n\nLDE expansion: exact 8x\n\nTransform domain: 2^27\n\nBackend: AMD HIP / ROCm\n\nValidation GPU: RX 7900 XTX\n\nROCm/HIP: ROCm 7.2.4 / HIP 7.2.53211\n\nOn the validated 2^27 target, the fast interface benchmark reports about 19.19 ms median latency, 19.49 ms p95 latency, 52.10 size-2^27 NTT/s, 6.99 billion elements/s, and 94.41 billion butterflies/s. The standard compatibility interface is about 21.99 ms median, with tiled prelayout measured separately at about 3.14 ms.\nCorrectness is also part of the framing: the repository includes field arithmetic checks, the primitive 2^27 root contract, explicit base-512 layout bijection checks, delta-vector validation, sampled direct evaluation against the mapped output contract, standard/fast layout checks, and a full CPU radix-2 reference comparison over the full 2^27 output.\nThe reason I think this is relevant to ZK-ACE is that it keeps the native STARK proving boundary intact: no proxy field, no reduced modulus, no scaled-down domain, and no hidden layout cost. If STARK-based authorization becomes part of the critical path, then making the native G64 LDE/FRI path practical on commodity GPUs becomes a very important engineering question.\nHappy to discuss integration, benchmark alignment, or a minimal experiment connecting Qingming-style G64 acceleration with your ZK-ACE architecture.\n\n post by Dede-Qorqud on Jul 1\n\n Dede-Qorqud\n\n What strikes me most here is the architectural implication: if authorization can be proven without a signature object, then the trust boundary shifts from “who signed” to “what was proven.” That’s a meaningful separation — it decouples identity from the cryptographic artifact we’ve historically used to represent it.\nThe aggregation consequence follows naturally from this. Once individual authorizations are proofs rather than signatures, batch verification becomes compositional by design rather than an afterthought.\nCurious whether the authors see applications beyond transaction authorization — specifically in contexts where the meaningful unit isn’t a single action but a collective outcome.\n\n post by 71104 on Jul 1\n\n 71104\n\nNot sure if this is what you mean but this zkACE scheme (which I prefer to call “zkMAC”) works as a post-quantum VRF too, and is therefore eligible for use in SSLE protocols.\n\n post by Dede-Qorqud on Jul 2\n\n Dede-Qorqud\n\n Good point — if the construction satisfies VRF security (pseudorandomness + provability), the SSLE application follows naturally. The post-quantum dimension makes it particularly relevant given where Ethereum’s roadmap is heading.\nOne parallel that comes to mind: the same ZK primitive that enables secret leader election in consensus could enable secret participant weighting in collective decision systems — where you want a verifiable aggregate outcome without revealing individual weights or choices. Different domain, same structural property.\nWe’ve been exploring exactly this in a related context: https://ethresear.ch/t/designing-infrastructure-where-exploits-destroy-themselves/25348\n\n Powered by Discourse","tokens":6629,"squid":"ink-research","role":"Deep Scholar","at":1791262527190,"hash":"8a3ab56738395c863b65e24ca0bb940d680f6742"}
{"url":"https://forum.soliditylang.org/t/read-this-before-posting/7","domain":"forum.soliditylang.org","title":"Read this before posting! ⚠️ - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Read this before posting! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2020\n\n 1 / 3\n\n Dec 2020\n\n Dec 2020\n\n post by system on Dec 8, 2020\n\n system\n\n Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Distribute escrow funds\n\n ParserError: Source not found: File import callback not supported\n\n Transfer success,but balance not increase,who can hlep me?\n\n Gas cost of cryptographic functions\n\n How to start build code in solidity\n\n 10 days later\n\n Closed on Dec 18, 2020\n\n 8 months later\n\n Made this a banner on Aug 19, 2021. It will appear at the top of every page until it is dismissed by the user.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 54\n\n 26d\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1970,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262530691,"hash":"41f999d05b87ee9dc5150dd073cfa875583c34a6"}
{"url":"https://ethresear.ch/t/designing-infrastructure-where-exploits-destroy-themselves/25348","domain":"ethresear.ch","title":"Designing Infrastructure Where Exploits Destroy Themselves - zk-s[nt]arks - Ethereum Research","text":"Designing Infrastructure Where Exploits Destroy Themselves \n\n zk-s[nt]arks\n\n governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2\n\n 1 / 1\n\n Jul 2\n\n Jul 2\n\n post by Dede-Qorqud on Jul 2\n\n Dede-Qorqud\n\n Vector-Defense layer1312×809 98.8 KB\nFig 1: A conceptual mapping of adversarial attack vectors against the BeTrueCore multi-layered architectural defense stack, detailing the specific components (ZK-Nullifiers, MACI, AI Sentinels, Celestia DA) deployed at each layer.\nMost collective decision-making protocols fail not at the cryptographic level, but at the human level. Traditional governance mechanisms regularly fall victim to Sybil attacks, coordinated block voting, and sophisticated vote-buying. While existing privacy solutions secure transaction confidentiality, they rarely address the structural environment in which the human signal is formed and manipulated.\nThe central claim of this work is that genuine sovereignty and privacy must be embedded in the architecture itself — in the structural environment and operational mechanics of the platform’s core architecture.\nBeTrueCore is a modular system designed to remove the conditions on which attacks against collective judgment rely. Rather than deploying reactive administrative barriers, the system utilizes a multi-layered, isolated protection stack that combines Minimal Anti-Collusion Infrastructure (MACI v1.2), zero-knowledge proofs (ZK-SNARKs via Circom), and a non-transferable non-linear reputation mechanism termed the Voting Weight of a Unit (VWU𝑉𝑊𝑈).\nThe architecture addresses three critical engineering challenges:\n1. Subverting the Vote-Buying Market\nBy leveraging mid-session choice mutability and continuous MACI-driven key rotation, BeTrueCore guarantees receipt-freeness. A participant can present any intermediate action to an external buyer as proof of compliance, yet the buyer cannot mathematically verify the final, time-locked choice. Because the commodity is unverifiable and the internal currency (VWU𝑉𝑊𝑈) is strictly inalienable, the transaction lacks an economic subject.\n2. Mitigating Scale-Based Sybil Vectors\nProtection is distributed across non-contiguous layers. Mass synthetic identities are filtered via L0 behavioral biometrics and keystroke dynamics, bound to unique L1 ZK-nullifier chains to prevent double-voting, and monitored by an L5 read-only AI Sentinel layer to detect long-horizon synchronized activity. To successfully simulate a community, an adversary must practically build one.\n3. Decentralizing the Infrastructure Layer\nTo avoid a single point of capture, the MACI coordinator must publish a mathematically verifiable state transition ZK-proof simultaneously with the result. A compromised coordinator can only affect system availability, not data integrity. Furthermore, the AI agent layer operates strictly in read-only mode, meaning an infrastructural breach grants observation rights but zero execution power.\nOperational Application of the Defense Stack: The 7-Step Daily Decision Cycle\nTo contextualize the theoretical resilience of the Web3-ISM framework, we examine its daily operational primitive, which restricts each participant to a maximum of seven discrete cryptographic actions per 24-hour session, executed in total isolation from the backend and without revealing the individual’s Vote Weight Unit (VWU𝑉𝑊𝑈).\nCrucially, the architecture enforces extreme asynchronous flexibility and anti-farming constraints:\nØ Screentime Efficiency: A user may execute anywhere from 1 to 7 actions during an active day, requiring less than 60 minutes of total interaction within the session window.\nØ Variable Participation Frequency (Missed Opportunity Metric): High daily retention is not mechanically mandated. A participant can activate a session as infrequently as once a week or once a month. To maintain strict psychological comfort, the architecture ensures that accumulated points, ranks, and badges are never deducted or penalized for dormancy. Instead, periods of inactivity are recorded strictly as missed cryptographic opportunities. While the user’s historical status remains fully intact, their relative dynamic voting trajectory (VWU𝑉𝑊𝑈) flattens during absence, preventing mass offline accounts from passively hoarding governance alpha without continuous cognitive contribution.\nWhen a session is active, the seven-step cycle unfolds as follows:\n\nPrompt Generation (Action 1): The user inputs a single text prompt encapsulating their session thesis, immediately subjected to L0 keystroke dynamics filtering and L5 semantic anomaly clustering to intercept automated AI injection.\n\nPattern Formulation (Actions 2–4): The user executes three binary selections to nominate a Top-3 from a randomized pool of other participants’ prompts; these actions are fully obscured by continuous MACI key-rotation, achieving receipt-freeness.\n\nOutput Selection (Actions 5–7): The user casts three binary votes on practical dilemmas derived from the previous session’s Top-3 pool, committing the signals to the state transition proof.\nConsequently, an adversary attempting a coordinated capture cannot rely on high-throughput script execution or mass passive account hoarding; to shift the system state, the hostile infrastructure must authentically simulate distinct human cognitive engagement vectors across highly irregular, fluid intervals, shifting the cost of attack from capital expenditure to computational and cognitive impossibility.\n\nTechnical Discussion & Feedback\nWe are currently in Phase 2 of our roadmap, focusing on circuit integration, MACI optimization, and preparing for an MVP launch on an EVM testnet. We welcome feedback from Ethereum research engineers, ZK cryptographers, and Solidity developers interested in robust anti-collusion infrastructure.\nIn particular:\n\nDoes the receipt-freeness argument hold under a stronger adversary model (e.g. one who can observe all intermediate choices in real time)?\n\nIs MACI v1.2 the right primitive for the nullifier layer, or are there more recent constructions that fit better?\n\nWhat is the right aggregation strategy for session-level STARK proofs — per-session batch, per-day batch, or rolling?\n\nVerification & Open Source\n· Complete Paper (Zenodo Preprint): The Notary Under Attack: An Adversarial Model for Cryptographic Collective Intelligence. https://doi.org/10.5281/zenodo.21111544\n· Verification: The Master Document of BeTrueCore MS is hashed (SHA-256) via OpenTimestamps.\n· Repository: https://github.com/Dede-Qorqud/BeTrueCore\n\n Sovereign Space: When Values Need Architecture\n\n What if post-quantum Ethereum doesn’t need signatures at all?\n\n Powered by Discourse","tokens":1674,"squid":"ink-research","role":"Deep Scholar","at":1791262537703,"hash":"15f4e3eb7a68936d7286cc546776beace51d3b14"}
{"url":"http://forum.soliditylang.org/c/tooling-infrastructure/10","domain":"forum.soliditylang.org","title":"Latest Tools & Infrastructure topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Tools & Infrastructure\n\n Tools & Infrastructure\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Tools & Infrastructure category\n\n Discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity. \n N…\n\n read more\n\n 0\n\n 569\n\n Feb 2021\n\n Can someone explain how via-ir works?\n\n 4\n\n 3.6k\n\n Dec 2025\n\n [call for feedback] SolDB – A New Debugger for Solidity\n\n 0\n\n 180\n\n Sep 2025\n\n npm, composer, etc for Solidity?\n\n 0\n\n 104\n\n Aug 2025\n\n Preprocessors and Metaprogramming in Solidity\n\n 4\n\n 993\n\n Oct 2023\n\n [Feedback Needed] SmartMuv - Solidity Smart Contract State Extractor and Analyzer\n\n 0\n\n 753\n\n Oct 2023\n\n Solhint - Official Discord Invitation\n\n 0\n\n 451\n\n Oct 2023\n\n Solhint feedback question to admins\n\n 1\n\n 498\n\n Oct 2023\n\n Solidity Mathematical Expression Interpreter Library\n\n 1\n\n 460\n\n Oct 2023\n\n Arbitrum grant round (please apply to fund solidity!)\n\n 2\n\n 459\n\n Sep 2023\n\n Allow mixedCase in the constants naming style\n\n 2\n\n 630\n\n Jun 2023\n\n Remix Project v0.31.0 Beta Testing\n\n 1\n\n 465\n\n Mar 2023\n\n Possible ABIv3 as default contract interface\n\n 6\n\n 864\n\n Feb 2023\n\n Smart contract monitoring\n\n 1\n\n 585\n\n Feb 2023\n\n Building the first Solidity debugger\n\n 1\n\n 520\n\n Jan 2023\n\n Fe Programming Language or Solidity?\n\n 3\n\n 933\n\n Jan 2023\n\n Compiler version not recognized\n\n 11\n\n 3.1k\n\n Dec 2022\n\n Smart contract audit\n\n 2\n\n 816\n\n Sep 2022\n\n Contract bytecode, function logic and state variable storage\n\n 0\n\n 584\n\n Aug 2022\n\n Smart Contract Scanner\n\n 1\n\n 589\n\n Aug 2022\n\n How to compile OpCode to ByteCode?\n\n 2\n\n 1.6k\n\n Aug 2022\n\n How to compile IR into bin?\n\n 1\n\n 631\n\n Jul 2022\n\n Smart Contract Security On Ethereum\n\n 2\n\n 1.1k\n\n Apr 2022\n\n Transper: Smart Contract complete storage extractor\n\n 3\n\n 691\n\n Apr 2022\n\n Line number logging for EVM assembly?\n\n 3\n\n 1.1k\n\n Dec 2021\n\n Solidity contract audit assistance\n\n 0\n\n 1.8k\n\n Dec 2021\n\n Solidity for blockchains other than ETH\n\n 2\n\n 1.1k\n\n Oct 2021\n\n Out Of Mem - Solidity,Remix IDE\n\n 0\n\n 603\n\n Sep 2021\n\n No syntax highlighting for strings on base constructor parameter list\n\n 6\n\n 665\n\n Sep 2021\n\n Which compiler warnings do you ignore?\n\n 4\n\n 3.3k\n\n Jul 2021","tokens":1424,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262541485,"hash":"751ae3ba794c66e5eb1e64df82713e61b2c0441b"}
{"url":"http://forum.soliditylang.org/c/ama-ask-the-solidity-team-anything/12","domain":"forum.soliditylang.org","title":"Latest AMA - Ask Me Anything topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in AMA - Ask Me Anything\n\n AMA - Ask Me Anything\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the AMA - Ask Me Anything category\n\n DO NOT OPEN TOPICS HERE / THIS IS NOT A SUPPORT CHANNEL \nThe Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open…\n\n read more\n\n 0\n\n 572\n\n Mar 2021\n\n I can not approve for the contract\n\n 2\n\n 946\n\n Oct 2023\n\n Solidity Team AMA #3 on Wed, 17th of November 2021\n\n 6\n\n 3.1k\n\n Nov 2021\n\n Solidity Team AMA #2 on Wed, 10th of March 2021\n\n 28\n\n 5.3k\n\n Mar 2021","tokens":1009,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262551755,"hash":"d96a50fcf8e2f186a99046a0ab2734d1072f461b"}
{"url":"https://dev-forum.pyth.network/t/pyth-pro-streams-query/812/5","domain":"dev-forum.pyth.network","title":"Pyth Pro Streams query - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jul 22\n\n 5 / 5\n\n Aug 4\n\n Aug 5\n\n post by PythUser on Jul 22\n\n 13 days later\n\n post by PythUser on Aug 5\n\n post by KemarTiti on Aug 5\n\n KemarTiti\n\n Apologies, completely missed that one.\nThe behavior depends on the channel:\n\nWith a fixed_rate@… channel, StreamUpdated messages continue at the configured interval during market off-hours. Once a feed has produced its first valid price, the latest price is carried forward; no new market price is generated while the market is closed.\nWith real_time, updates are sent when a new price is available, so a closed market may not produce regular updates.\n\nTo identify whether a price is fresh or carried forward, include feedUpdateTimestamp in the subscription properties:\n\nfeedUpdateTimestamp == timestampUs: the price was generated in the current update.\nfeedUpdateTimestamp < timestampUs: the price was carried forward from an earlier update.\n\nSo a Saturday fixed-rate update may contain Friday’s closing price, while feedUpdateTimestamp remains Friday’s price-generation time and timestampUs reflects the Saturday stream update.\nSee the subscription guide and payload reference.\n\n post by PythUser on Aug 5\n\n PythUser\n\n Thanks, that’s clear on using feedUpdateTimestamp == timestampUs to detect a fresh price.\nI want to follow up on the wording in one line: “a closed market may not produce regular updates.” The “may” implies that a closed market can still, under some conditions, “generate” a genuinely new price rather than only carrying the last one forward.\nConcretely: for an asset whose primary market is closed over the weekend, under what conditions can the feed generate a new price during that closed period, i.e., a real_time or fixed_rate update where feedUpdateTimestamp == timestampUs rather than a carried-forward one where feedUpdateTimestamp < timestampUs?\nI’m trying to understand whether “market closed” reliably means “no new price generation” on both channels, or whether fresh price generation can still occur off-hours for certain assets.\n\n post by KemarTiti on Aug 5\n\n KemarTiti\n\n If a feed’s marketSession is actually closed, Pyth should not generate a new price merely because a fixed_rate subscription continues sending updates. Those updates carry forward the latest available price, so feedUpdateTimestamp < timestampUs.\nreal_time only sends an update when a new price is available, so a genuinely closed feed should not produce fresh real_time prices either.\nThe important distinction is that “off-hours” does not always mean marketSession: \"closed\". Some feeds may have an active preMarket, postMarket, or overNight session, while crypto feeds operate 24/7. Fresh prices can be generated during those sessions, with feedUpdateTimestamp == timestampUs.\nTherefore, you should check both marketSession and feedUpdateTimestamp. If a feed reports marketSession: \"closed\" and feedUpdateTimestamp == timestampUs, that would be unexpected and worth investigating with the symbol, channel, and payload timestamps.\nThe available session values are regular, preMarket, postMarket, overNight, and closed. The details are in the payload reference.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 714\n\n Dec 2025\n\n Pyth Pro: Update to price `payload` in API Responses\n\n Announcements\n\n 0\n\n 220\n\n Feb 25\n\n Should we pay attention to the VAA timestamp when updating feeds?\n\n Price Feeds\n\n evm\n\n 2\n\n 353\n\n Oct 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Missing parsePriceFeedUpdatesUnique function on BSC implementation\n\n Price Feeds\n\n evm\n\n 6\n\n 46\n\n Jun 18\n\n Powered by Discourse","tokens":1852,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262552222,"hash":"ab6bafddebd49440816732cfd06fa74554efbd64"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-for-us-equity-are-not-been-updated-periodically/375","domain":"dev-forum.pyth.network","title":"Price Feeds for US.Equity are not been updated periodically - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds for US.Equity are not been updated periodically \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 8\n\n 4\n\n 4\n\n Aug 2025\n\n 1 / 16\n\n Aug 2025\n\n Dec 2025\n\n post by Siddharth on Aug 28, 2025\n\n Siddharth\n\n I have bunch of equities for which I want to fetch prices as recent as past 1 hour. But I get StalePrice() error, this is the reference :\n\nI’m looking to fetch prices for following equities:\nEquity.US.GOOG/USD : 0xe65ff435be42630439c96396653a342829e877e2aafaeaf1a10d0ee5fd2cf3f2\nEquity.US.AMZN/USD : 0xb5d0e0fa58a1f8b81498ae670ce93c872d14434b72c364885d4fa1b257cbb07a\nEquity.US.AAPL/USD : 0x49f6b65cb1de6b10eaf75e7c03ca029c306d0357e91b5311b175084a5ad55688\nEquity.US.MSFT/USD : 0xd0ca23c1cc005e004ccf1db5bf76aeb6a49218f43dac3d4b275e92de12ded4d1\nEquity.US.TSLA/USD : 0x16dad506d7db8da01c87581c87ca897a012a153557d4d578c3b9c9e1bc0632f1\nEquity.US.NVDA/USD : 0xb1073854ed24cbc755dc527418f52b7d271f6cc967bbf8d8129112b18860a593\nEquity.US.META/USD : 0x78a3e3b8e676a8f73c439f5d749737034b139bbbe899ba5775216fba596607fe\nEquity.US.GME/USD : 0x6f9cd89ef1b7fd39f667101a91ad578b6c6ace4579d5f7f285a4b06aa4504be6\nand even more.\nI’ve been given to understand that one can run bots which update the price feeds, where can I find them ?\nThank you.\n\n 8\n\n 4\n\n 4\n\n post by KemarTiti on Aug 28, 2025\n\n KemarTiti\n\n Hey @Siddharth\nCan you tell at what time exactly where you trying to call these feeds?\nI assume the market was closed and Pyth feeds follow traditional market hours for now: https://docs.pyth.network/price-feeds/market-hours\n\n post by KemarTiti on Aug 28, 2025\n\n KemarTiti\n\n Also Pyth works as an on-demand model, so unless you (or someone else) has updated a price, you might indeed read a too old onchain price.\nYou can trigger periodic price updates with the Scheduler bot here: https://docs.pyth.network/price-feeds/schedule-price-updates/using-scheduler\nYou pick the feeds, and the parameters (time and price deviation) and the bot will do it for you\n\n post by Aditya520 on Aug 28, 2025\n\n Aditya520\n\n Hey @Siddharth\nAdding to the Marc’s answer above, the scheduler will not be able to update the prices during off market hours.\nScheduler uses updatePriceFeedsIfNecessary, which only updates if there is a fresh update available.\n\n post by Siddharth on Aug 28, 2025\n\n Siddharth\n\n KemarTiti\n\n Hey @KemarTiti yeah initially I was querying the price before market opened, but if I query now, after the market has opened i still get the stale price error.\nScreenshot 2025-08-28 at 9.39.48 PM904×986 33.7 KB\nAlso I forgot to mention, I am running it for base network.\n\n post by Siddharth on Aug 28, 2025\n\n Siddharth\n\n KemarTiti\n\n ok thank you will look into it, one question, doesn’t pyth protocol run schedulers for these equities, and if so can they update the above mentioned equities periodically.\n\n post by Aditya520 on Aug 28, 2025\n\n Aditya520\n\n Siddharth\n\n You have to update the prices/ pull the prices.\nYou can call updatePriceFeeds with it’s updateData.\n\nYou can fetch the updateData by following this guide.\n\n post by Aditya520 on Aug 28, 2025\n\n Aditya520\n\n Siddharth\n\n Yes, we do run many schedulers/price-pushers.\nYou can check the list here.\nIf you would like to see additional feeds on this list, please fill in this form to signal your interest., or contact @KemarTiti\n\n post by KemarTiti on Aug 28, 2025\n\n KemarTiti\n\n Siddharth\n\n If you’d like to talk in more details, indeed please reach out to me on Telegram: Telegram: Contact @MarcTillement or @mariobern Telegram: Contact @mariopyth\n\n post by Siddharth on Aug 28, 2025\n\n Siddharth\n\n Aditya520\n\nThank you so very much\n\n post by Siddharth on Aug 28, 2025\n\n Siddharth\n\n KemarTiti\n\n Will do, thank you so very much.\n\n 28 days later\n\n post by Siddharth on Sep 26, 2025\n\n Siddharth\n\nOk I am running the price pusher scheduler here :\n\nI want to run it for , `Equity.US.GME/USDwhich has a stable id of :0x6f9cd89ef1b7fd39f667101a91ad578b6c6ace4579d5f7f285a4b06aa4504be6\n\nThis is my price-config.yaml :\nScreenshot 2025-09-26 at 1.39.51 PM1218×382 45.6 KB\nThis is the command I’m using to run the price pusher :\n``\npnpm run start evm --endpoint wss://base-mainnet.g.alchemy.com/v2/ --pyth-contract-address 0x8250f4aF4B972684F7b336503E2D6dFeDeB1487a --price-service-endpoint https://hermes.pyth.network --price-config-file ./price-config.stable.sample.yaml --mnemonic-file ./mnemonic.txt --pushing-frequency 30 --polling-frequency 5 --override-gas-price-multiplier 1.1\n`\nBut in the logs I see no price update being pushed\n``\n{“level”:30,“time”:1758874244083,“pid”:11109,“hostname”:“Mac.lan”,“module”:“EvmPriceListener”,“msg”:“Watching target network pyth contract events…”}\n{“level”:30,“time”:1758874274396,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“GME/USD (6f9cd89ef1b7fd39f667101a91ad578b6c6ace4579d5f7f285a4b06aa4504be6) is not available on the source network. Ignoring it.”}\n{“level”:30,“time”:1758874274396,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“None of the checks were triggered. No push needed.”}\n{“level”:30,“time”:1758874304397,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“GME/USD (6f9cd89ef1b7fd39f667101a91ad578b6c6ace4579d5f7f285a4b06aa4504be6) is not available on the source network. Ignoring it.”}\n{“level”:30,“time”:1758874304398,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“None of the checks were triggered. No push needed.”}\n{“level”:30,“time”:1758874334400,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“GME/USD (6f9cd89ef1b7fd39f667101a91ad578b6c6ace4579d5f7f285a4b06aa4504be6) is not available on the source network. Ignoring it.”}\n{“level”:30,“time”:1758874334400,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“None of the checks were triggered. No push needed.”}\n{“level”:30,“time”:1758874364401,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“GME/USD (6f9cd89ef1b7fd39f667101a91ad578b6c6ace4579d5f7f285a4b06aa4504be6) is not available on the source network. Ignoring it.”}\n{“level”:30,“time”:1758874364402,“pid”:11109,“hostname”:“Mac.lan”,“module”:“Controller”,“msg”:“None of the checks were triggered. No push needed.”}\n``\nHow can I fix this ?\n\n post by Aditya520 on Sep 26, 2025\n\n Aditya520\n\n Can you give us more logs?\nMoreover, I can see you are running during off-market hours. Can you try running it during the market hours?\n\n post by Siddharth on Sep 26, 2025\n\n Siddharth\n\n I was able to sort the issue, I was trying to running the price pusher for some equities, like TSLA, GME etc. But the pusher wasnt updating it, because it was looking for a price not older than 60seconds, I did some changes and was able to sort it thanks.\n\n 3 months later\n\n post by Siddharth on Dec 11, 2025\n\n Siddharth\n\n Hello I have another question.\nIm trying to update on-chain price for AMZN, pre and post market feeds, but i dont think the feeds exists on base network, how do we enable this ?\n\nThis is the pyth contract.\n\n post by KemarTiti on Dec 11, 2025\n\n KemarTiti\n\n Hey!\nwe do have docs on these errors\n\nlet me know if these don’t help you\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How do I get price feeds for stocks like AAPL at a particular timestamp? Current way is not working\n\n Benchmarks(Historic Prices)\n\n 1\n\n 721\n\n Jul 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Why I get always reverted for Crypto.AVALON.USDA/USD price on Ethereum mainnet\n\n Price Feeds\n\n 1\n\n 470\n\n Jul 2025\n\n Deprecation of some (Resolv) Pyth Push Feeds on Base, Ethereum, Arbitrum, HyperEVM and Solana – May 31st, 2026\n\n Price Feeds\n\n announcements\n\n 1\n\n 33\n\n Jun 2\n\n Powered by Discourse","tokens":2821,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262565275,"hash":"e9d7dd950d246092831cbd61d11c340f9e698c09"}
{"url":"https://docs.openzeppelin.com/ui-builder/networks","domain":"docs.openzeppelin.com","title":"Networks | OpenZeppelin Docs","text":"UI BuilderNetworksOpen in ClaudeSupported Networks\nCurrently the Contracts UI Builder supports the following EVM networks\nMainnet\n\nEthereum\nArbitrum One\nBase\nPolygon\nPolygon zkEVM\nBNB Smart Chain\nOP Mainnet\nAvalanche C-Chain\nLinea\nScroll\nZkSync Era\n\nTestnet\n\nSepolia\nArbitrum Sepolia\nBase Sepolia\nPolygon Amoy\nPolygon zkEVM Cardona\nBSC Testnet\nOP Sepolia\nAvalanche Fuji C-Chain\nLinea Sepolia\nScroll Sepolia\nZkSync Era Sepolia\n\nMidnight, Stellar, and Solana are planned to be supported in the future\nNetwork Configs\nEach network can be configured to use custom RPCs, Explorers, and Explorer APIs. To open the network configuration modal, click on the settings icon on the right side of a network.\n\nIn this modal you can configure a custom RPC URL which can include path API key authorization\n\nUnder the explorer tab you can configure block explorers like Etherscan. By default the Contracts UI Builder uses public APIs that can be rate limited, so be sure to provide your own API key if that becomes an issue.\n\nYou can also toggle advance settings to use a custom block explorer setup.\nQuickstartPrevious PageLoading ContractsNext PageOn this pageSupported NetworksNetwork Configs","tokens":295,"squid":"ink-security_audits","role":"Sentinel","at":1791262565427,"hash":"4cf79a806285e8d2661e217ea4234abb6590f0f0"}
{"url":"https://mcp.openzeppelin.com/","domain":"mcp.openzeppelin.com","title":"OpenZeppelin MCP Servers","text":"MCP ServersModel Context Protocol Servers Repository for OpenZeppelin ProductsSolidity ContractsGenerate Solidity secure smart contracts based on OpenZeppelin templatesView Setup Instructions →Cairo ContractsGenerate Cairo secure smart contracts based on OpenZeppelin templatesView Setup Instructions →Confidential ContractsGenerate Confidential secure smart contracts based on OpenZeppelin templatesView Setup Instructions →Stellar ContractsGenerate Stellar secure smart contracts based on OpenZeppelin templatesView Setup Instructions →Stylus ContractsGenerate Stylus secure smart contracts based on OpenZeppelin templatesView Setup Instructions →TRON ContractsGenerate TRON secure smart contracts based on OpenZeppelin templatesView Setup Instructions →Uniswap HooksGenerate Uniswap Hooks secure smart contracts based on OpenZeppelin templatesView Setup Instructions →Sui ContractsCompose Sui Move smart contracts based on OpenZeppelin's audited primitivesView Setup Instructions →","tokens":246,"squid":"ink-security_audits","role":"Sentinel","at":1791262578240,"hash":"efa97aea33e0e7f7f199d8085f7412b3324fd751"}
{"url":"https://io.net/docs/reference/vmaas/get-started-with-vmaas-api","domain":"io.net","title":"Getting Started with VMaaS API - io.net","text":"The Virtual Machine as a Service (VMaaS) APIs lets you programmatically deploy and manage virtual machines on io.net Cloud. Unlike CaaS (Containers as a Service), VMaaS provides full VM instances with CPU, GPU, memory, and storage resources — ideal for long-running workloads, custom environments, or GPU-intensive tasks.\n​Generate an API key\nYou can obtain an API key for io.net Cloud to use VMaaS in two ways:\n\nFrom the web interface.\nBy using a two-step process (first generate a JWT token, then request the API key using curl).\n\n​Option 1: Generate an API Key via Web Interface\nIO Clouds APIs authenticate requests using API keys. You can generate API keys from your user account.\nNote: When generating an API key, make sure to specify the associated IO Cloud project.\nAlways treat your API key as a secret. Do not share it or expose it in client-side code (e.g., browsers or mobile apps). Instead, store it securely in an environment variable or a key management service in your backend server.\n​Option 2: Generate an API Key Using a JWT Token\n​Step 1: Get a JWT Token\nio.net APIs are built around RESTful principles. You can use io.net APIs to gain insight into different elements of the network.\nTo use io.net APIs, you must provide a JWT token in the header of your request.\nFollow the instructions below to generate a token:\n\nGo to io.net > IO ID > IO Clouds tab.\nIn the UI, right-click and select Inspect.\nIn the Inspect tool, click Network.\nRefresh the IO Clouds page.\nIn the list of elements, click Devices.\nScroll down to the Request Headers section.\nCopy and store the token.\n\nThis token is valid for 21 days.\n\n​Step 2. Generate an API Key via curl\nUse the JWT token to request your API key:\ncurl -X POST 'https://api.io.solutions/v1/api-keys/' \\\n -H 'accept: application/json' \\\n -H 'token: $JWT_TOKEN' \\\n -H 'Content-Type: application/json' \\\n -d '{\n \"description\": \"API Key Name\",\n \"expires_at\": \"2025-07-17T19:54:36.418Z\",\n \"project\": \"io-cloud\",\n \"scopes\": [\"all\"]\n}'\n\nUse the returned key with the X-API-KEY header in your requests.\nAlways treat your API key as a secret. Do not share it or expose it in client-side code (e.g., browsers or mobile apps). Instead, store it securely in an environment variable or a key management service in your backend server.\n\n​Making requests\nAccessing APIs requires IO credits. Make sure you have sufficient IO credits before using any API endpoint.Contact support or visit the IO Credits documentation page for more details.\nInclude the API key in an Authorization HTTP header for all API requests:\nAuthorization: X-API-KEY $IOCLOUD_API_KEY\n\nReplace $IOCLOUD_API_KEY with your API key.\n​Example: Deploy VMs\nThe following curl command demonstrates how to deploy VMs in IO Cloud.\nMake sure to include your x-api-key header and, if needed, adjust the query parameters such as status, page, or page_size.:\ncurl -X POST \"https://api.io.solutions/enterprise/v1/io-cloud/vmaas/deploy?page=0&page_size=10&status=running\" \\\n -H \"accept: application/json\" \\\n -H \"Content-Type: application/json\" \\\n -H \"x-api-key: YOUR_API_KEY_HERE\" \\\n -d '{\n \"name\": \"test-deployment\",\n \"hardware_quantity\": 2,\n \"hardware_name\": \"NVIDIA A100\",\n \"region\": \"us-east-1\"\n }'\n\nThis request should return a similar response:\n{\n \"data\": {\n \"deployments\": [\n {\n \"id\": \"3fa85f64-5717-4562-b3fc-2c963f66afa6\",\n \"status\": \"running\",\n \"name\": \"test-deployment\",\n \"completed_percent\": 75,\n \"hardware_quantity\": 2,\n \"brand_name\": \"NVIDIA\",\n \"hardware_name\": \"A100\",\n \"compute_minutes_served\": 120,\n \"compute_minutes_remaining\": 240\n }\n ],\n \"total\": 1,\n \"statuses\": [\"running\"]\n }\n}\nWas this page helpful?","tokens":905,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791262585080,"hash":"841fa40269e5f1bab52561117fbdf3a1b29576ef"}
{"url":"https://api-reference.pyth.network/price-feeds/evm/getValidTimePeriod","domain":"api-reference.pyth.network","title":"Price Feeds | Pyth Network API Reference","text":"getValidTimePeriod (deprecated)Get the default valid time period of price freshness in seconds.DescriptionThis method returns the default valid time period of price freshness in seconds.\nThis quantity is the maximum age of price updates returned by functions like getPrice and\ngetEmaPrice; these functions revert if the current on-chain price\nis older than this period.\nNOTE: We recommend using getPriceNoOlderThan() or getEmaPriceNoOlderThan() instead of getPrice and\ngetEmaPrice.\nThe valid time period is configured to be a same default for each blockchain.ArgumentsThis API takes no argumentsNetworkimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n// Ethereum\naddress contractAddress = 0x4305FB66699C3B2702D4d05CF36551390A4c69C6\nIPyth pyth = IPyth(contractAddress);\n\nuint validTimePeriod = pyth.getValidTimePeriod();","tokens":220,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262588708,"hash":"e571056737845c4b4e6af93133f1671aa957bc2c"}
{"url":"https://forum.openzeppelin.com/t/error-invalid-bignumber-string/16434/1","domain":"forum.openzeppelin.com","title":"Error: invalid BigNumber string - Support / Contracts - OpenZeppelin Forum","text":"Error: invalid BigNumber string \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2021\n\n 1 / 2\n\n Oct 2021\n\n Oct 2021\n\n post by Maham_Zaidi on Oct 2, 2021\n\n Maham_Zaidi\n\n I want to input the following values to this function\nfunction rebase(uint256 epoch, int256 supplyDelta)\n\nepoch (5 minutes later)\nsupplyDelta -0.000000000000001\n\nI tried doing so in remix but got an error. How to resolve this issue?\n\nerrored: Error encoding arguments: Error: invalid BigNumber string (argument=\"value\", value=\"-0.000000000000001\", code=INVALID_ARGUMENT, version=bignumber/5.4.1)\n\n post by Amxx on Oct 4, 2021\n\n Amxx\n\n OpenZeppelin Team\n\n Hello @Maham_Zaidi\n\nThis is not a valid integer. It looks like you are trying to pass a floating number. Floating number do not (natively) exist in solidity / on the evm.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Invalid BigNumber value for string\n\n Smart Contracts\n\n erc721,solidity\n\n 1\n\n 227\n\n Jun 2024\n\n How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1\n\n Smart Contracts\n\n 6\n\n 718\n\n May 2023\n\n BigNumber error\n\n Smart Contracts\n\n etherscan-verify\n\n 0\n\n 374\n\n Mar 2024\n\n Help please with: invalid number value (arg=“amount”, coderType=“uint256”\n\n Contracts\n\n erc20\n\n 3\n\n 8.6k\n\n Sep 2021\n\n Value undefined only in AutoTask\n\n Defender\n\n 11\n\n 1.1k\n\n May 2024","tokens":353,"squid":"ink-security_audits","role":"Sentinel","at":1791262588783,"hash":"59d618f623a4a035e2046e95299d19154f9f5a73"}
{"url":"https://specs.optimism.io/protocol/ecotone/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Derivation\n\nTable of Contents\n\nEcotone: Blob Retrieval\nBlob Encoding\nNetwork upgrade automation transactions\n\nL1Block Deployment\nGasPriceOracle Deployment\nL1Block Proxy Update\nGasPriceOracle Proxy Update\nGasPriceOracle Enable Ecotone\nBeacon block roots contract deployment (EIP-4788)\n\nEcotone: Blob Retrieval\nWith the Ecotone upgrade the retrieval stage is extended to support an additional DA source:\nEIP-4844 blobs. After the Ecotone upgrade we modify the iteration over batcher transactions to\ntreat transactions of transaction-type == 0x03 (BLOB_TX_TYPE) differently. If the batcher\ntransaction is a blob transaction, then its calldata MUST be ignored should it be present. Instead:\n\nFor each blob hash in blob_versioned_hashes, retrieve the blob that matches it. A blob may be\nretrieved from any of a number different sources. Retrieval from a local beacon-node, through\nthe /eth/v1/beacon/blob_sidecars/ endpoint, with indices filter to skip unrelated blobs, is\nrecommended. For each retrieved blob:\n\nThe blob SHOULD (MUST, if the source is untrusted) be cryptographically verified against its\nversioned hash.\nIf the blob has a valid encoding, decode it into its continuous byte-string\nand pass that on to the next phase. Otherwise the blob is ignored.\n\nNote that batcher transactions of type blob must be processed in the same loop as other batcher\ntransactions to preserve the invariant that batches are always processed in the order they appear\nin the block. We ignore calldata in blob transactions so that it may be used in the future for\nbatch metadata or other purposes.\nBlob Encoding\nEach blob in a EIP-4844 transaction really consists of FIELD_ELEMENTS_PER_BLOB = 4096 field elements.\nEach field element is a number in a prime field of\nBLS_MODULUS = 52435875175126190479447740508185965837690552500527637822603658699938581184513.\nThis number does not represent a full uint256: math.log2(BLS_MODULUS) = 254.8570894...\nThe L1 consensus-specs\ndescribe the encoding of this polynomial.\nThe field elements are encoded as big-endian integers (KZG_ENDIANNESS = big).\nTo save computational overhead, only 254 bits per field element are used for rollup data.\nFor efficient data encoding, 254 bits (equivalent to 31.75 bytes) are utilized.\n4 elements combine to effectively use 127 bytes.\n127 bytes of application-layer rollup data is encoded at a time, into 4 adjacent field elements of the blob:\n# read(N): read the next N bytes from the application-layer rollup-data. The next read starts where the last stopped.\n# write(V): append V (one or more bytes) to the raw blob.\nbytes tailA = read(31)\nbyte x = read(1)\nbyte A = x & 0b0011_1111\nwrite(A)\nwrite(tailA)\n\nbytes tailB = read(31)\nbyte y = read(1)\nbyte B = (y & 0b0000_1111) | (x & 0b1100_0000) >> 2)\nwrite(B)\nwrite(tailB)\n\nbytes tailC = read(31)\nbyte z = read(1)\nbyte C = z & 0b0011_1111\nwrite(C)\nwrite(tailC)\n\nbytes tailD = read(31)\nbyte D = ((z & 0b1100_0000) >> 2) | ((y & 0b1111_0000) >> 4)\nwrite(D)\nwrite(tailD)\n\nEach written field element looks like this:\n\nStarts with one of the prepared 6-bit left-padded byte values, to keep the field element within valid range.\nFollowed by 31 bytes of application-layer data, to fill the low 31 bytes of the field element.\n\nThe written output should look like this:\n<----- element 0 -----><----- element 1 -----><----- element 2 -----><----- element 3 ----->\n| byte A | tailA... || byte B | tailB... || byte C | tailC... || byte D | tailD... |\n\nThe above is repeated 1024 times, to fill all 4096 elements,\nwith a total of (4 * 31 + 3) * 1024 = 130048 bytes of data.\nWhen decoding a blob, the top-most two bits of each field-element must be 0,\nto make the encoding/decoding bijective.\nThis is enforced for every field element except the first one:\nthe first field element is special-cased for the version and length (see below),\nand its top-most two bits are ignored (masked to 0) on decode rather than validated.\nAs a result, those two bits do not affect the decoded output and the encoding is not\nstrictly bijective for the first field element; the encoder always writes them as 0.\nThe first byte of rollup-data (second byte in first field element) is used as a version-byte.\nIn version 0, the next 3 bytes of data are used to encode the length of the rollup-data, as big-endian uint24.\nAny trailing data, past the length delimiter, must be 0, to keep the encoding/decoding bijective.\nIf the length is larger than 130048 - 4, the blob is invalid.\nIf any of the encoding is invalid, the blob as a whole must be ignored.\nNetwork upgrade automation transactions\nThe Ecotone hardfork activation block contains the following transactions, in this order:\n\nL1 Attributes Transaction, using the pre-Ecotone setL1BlockValues\nUser deposits from L1\nNetwork Upgrade Transactions\n\nL1Block deployment\nGasPriceOracle deployment\nUpdate L1Block Proxy ERC-1967 Implementation Slot\nUpdate GasPriceOracle Proxy ERC-1967 Implementation Slot\nGasPriceOracle Enable Ecotone\nBeacon block roots contract deployment (EIP-4788)\n\nTo not modify or interrupt the system behavior around gas computation, this block will not include any sequenced\ntransactions by setting noTxPool: true.\nL1Block Deployment\nThe L1Block contract is upgraded to process the new Ecotone L1-data-fee parameters and L1 blob base-fee.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000000\nto: null\nmint: 0\nvalue: 0\ngasLimit: 375,000\ndata: 0x60806040523480156100105... (full bytecode)\nsourceHash: 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Deployment\"\n\nThis results in the Ecotone L1Block contract being deployed to 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff, to verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000000\nComputed Address: 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Deployment\"))\n# 0x877a6077205782ea15a6dc8699fa5ebcec5e0f4389f09cb8eda09488231346f8\n\nVerify data:\ngit checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json\n\nThis transaction MUST deploy a contract with the following code hash\n0xc88a313aa75dc4fbf0b6850d9f9ae41e04243b7008cf3eadb29256d4a71c1dfd.\nGasPriceOracle Deployment\nThe GasPriceOracle contract is upgraded to support the new Ecotone L1-data-fee parameters. Post fork this contract\nwill use the blob base fee to compute the gas price for L1-data-fee transactions.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000001\nto: null,\nmint: 0\nvalue: 0\ngasLimit: 1,000,000\ndata: 0x60806040523480156100... (full bytecode)\nsourceHash: 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Deployment\"\n\nThis results in the Ecotone GasPriceOracle contract being deployed to 0xb528D11cC114E026F138fE568744c6D45ce6Da7A,\nto verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000001\nComputed Address: 0xb528D11cC114E026F138fE568744c6D45ce6Da7A\n\nVerify sourceHash:\n❯ cast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Deployment\"))\n# 0xa312b4510adf943510f05fcc8f15f86995a5066bd83ce11384688ae20e6ecf42\n\nVerify data:\ngit checkout 5996d0bc1a4721f2169ba4366a014532f31ea932\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json\n\nThis transaction MUST deploy a contract with the following code hash\n0x8b71360ea773b4cfaf1ae6d2bd15464a4e1e2e360f786e475f63aeaed8da0ae5.\nL1Block Proxy Update\nThis transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x4200000000000000000000000000000000000015 (L1Block Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff\nsourceHash: 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: L1 Block Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x07dbe8500fc591d1852B76feE44d5a05e13097Ff)\n0x3659cfe600000000000000000000000007dbe8500fc591d1852b76fee44d5a05e13097ff\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: L1 Block Proxy Update\"))\n# 0x18acb38c5ff1c238a7460ebc1b421fa49ec4874bdf1e0a530d234104e5e67dbc\n\nGasPriceOracle Proxy Update\nThis transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle\ndeployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a\nsourceHash: 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: Gas Price Oracle Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xb528D11cC114E026F138fE568744c6D45ce6Da7A)\n0x3659cfe6000000000000000000000000b528d11cc114e026f138fe568744c6d45ce6da7a\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Proxy Update\"))\n# 0xee4f9385eceef498af0be7ec5862229f426dec41c8d42397c7257a5117d9230a\n\nGasPriceOracle Enable Ecotone\nThis transaction informs the GasPriceOracle to start using the Ecotone gas calculation formula.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account)\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 80,000\ndata: 0x22b90ab3\nsourceHash: 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Ecotone: Gas Price Oracle Set Ecotone\"\n\nVerify data:\ncast sig \"setEcotone()\"\n0x22b90ab3\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: Gas Price Oracle Set Ecotone\"))\n# 0x0c1cb38e99dbc9cbfab3bb80863380b0905290b37eb3d6ab18dc01c1f3e75f93\n\nBeacon block roots contract deployment (EIP-4788)\nEIP-4788 introduces a \"Beacon block roots\" contract, that processes and exposes the beacon-block-root values.\nat address BEACON_ROOTS_ADDRESS = 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02.\nFor deployment, EIP-4788 defines a pre-EIP-155 legacy transaction, sent from a key that is derived such that the\ntransaction signature validity is bound to message-hash, which is bound to the input-data, containing the init-code.\nHowever, this type of transaction requires manual deployment and gas-payments.\nAnd since the processing is an integral part of the chain processing, and has to be repeated for every OP-Stack chain,\nthe deployment is approached differently here.\nSome chains may already have a user-submitted instance of the EIP-4788 transaction.\nThis is cryptographically guaranteed to be correct, but may result in the upgrade transaction\ndeploying a second contract, with the next nonce. The result of this deployment can be ignored.\nA Deposit transaction is derived with the following attributes:\n\nfrom: 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875, as specified in the EIP.\nto: null\nmint: 0\nvalue: 0\ngasLimit: 0x3d090, as specified in the EIP.\nisCreation: true\ndata:\n0x60618060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604d57602036146024575f5ffd5b5f35801560495762001fff810690815414603c575f5ffd5b62001fff01545f5260205ff35b5f5ffd5b62001fff42064281555f359062001fff015500\nisSystemTx: false, as per the Regolith upgrade, even the system-generated transactions spend gas.\nsourceHash: 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c,\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Ecotone: beacon block roots contract deployment\"\n\nThe contract address upon deployment is computed as rlp([sender, nonce]), which will equal:\n\nBEACON_ROOTS_ADDRESS if deployed\na different address (0xE3aE1Ae551eeEda337c0BfF6C4c7cbA98dce353B) if nonce = 1:\nwhen a user already submitted the EIP transaction before the upgrade.\n\nVerify BEACON_ROOTS_ADDRESS:\ncast compute-address --nonce=0 0x0B799C86a49DEeb90402691F1041aa3AF2d3C875\n# Computed Address: 0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Ecotone: beacon block roots contract deployment\"))\n# 0x69b763c48478b9dc2f65ada09b3d92133ec592ea715ec65ad6e7f3dc519dc00c","tokens":3344,"squid":"ink-governance","role":"Council Listener","at":1791262611310,"hash":"13d797f03f9d1034ede44dc555736b07eb53f131"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19478276593179-Why-are-there-2-different-USDC-s-on-Arbitrum","domain":"support.arbitrum.io","title":"Why are there 2 different USDC's on Arbitrum? – Arbitrum Foundation","text":"Understanding native vs. bridged\nNative USDC is officially issued by Circle and always redeemable 1:1 for US dollars.\nIn the case of Arbitrum, there also exists a “bridged” form of USDC, known as USDC.e, that’s been bridged from Ethereum. USDC.e is not issued by Circle.\n\nNative USDC on Arbitrum:\n\nToken Name: USD Coin\nToken Symbol: USDC\nToken Address: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n\nBridged USDC on Arbitrum: (from Ethereum)\n\nToken Name: Bridged USDC\nToken Symbol: USDC.e\nToken Address: 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8\n\n Recently viewed articlesWhy wait 7 days to claim funds when bridge to Ethereum?Using Arbitrum's traditional bridge to move funds to MainnetBridging over a new tokenYou need ETH to power transactionsWhy do I have 0 voting power even though I have $ARB?\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n How can I add Arbitrum network to my wallet?\n\n You need ETH to power transactions\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Please sign in to leave a comment.","tokens":280,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262620913,"hash":"4a72d49cbca135453e78cbe1379835479ff30371"}
{"url":"https://specs.optimism.io/protocol/system-config.html","domain":"specs.optimism.io","title":"System Config - OP Stack Specification","text":"System Config\n\nTable of Contents\n\nOverview\nDefinitions\n\nBatch Inbox\nBatcher Hash\nFee Scalars\n\nPre-Ecotone Parameters\nPost-Ecotone Parameters\nPost-Ecotone Scalar Encoding\n\nUnsafe Block Signer\nL2 Gas Limit\nCustomizable Feature\n\nFunctionality\n\nSystem Config Updates\n\nFunction Specification\n\ninitialize\nupgrade\nsetFeatureEnabled\nisFeatureEnabled\nminimumGasLimit\nmaximumGasLimit\nunsafeBlockSigner\nl1CrossDomainMessenger\nl1ERC721Bridge\nl1StandardBridge\ndisputeGameFactory\noptimismPortal\noptimismMintableERC20Factory\ngetAddresses\nbatchInbox\nstartBlock\npaused\nsuperchainConfig\nsetUnsafeBlockSigner\nsetBatcherHash\nsetGasConfig\nsetGasConfigEcotone\nsetGasLimit\nsetEIP1559Params\nsetOperatorFeeScalars\nsetMinBaseFee\nsetDAFootprintGasScalar\nresourceConfig\nguardian\n\nOverview\nThe SystemConfig is a contract on L1 that can emit rollup configuration changes as log events.\nThe rollup block derivation process picks up on these log events and applies the\nchanges. SystemConfig generally acts as the source of truth for configuration values within an\nOP Stack chain.\nDefinitions\nBatch Inbox\nThe Batch Inbox is the address that Sequencer transaction batches are published to. Sequencers\npublish transactions to the Batch Inbox by setting it as the to address on a transaction\ncontaining batched L2 transactions either in calldata or as blobdata.\nBatcher Hash\nThe Batcher Hash identifies the sender(s) whose transactions to the Batch Inbox\nwill be recognized by the L2 clients for a given OP Chain.\nThe Batcher Hash is versioned by the first byte of the hash. The structure of the V0 Batcher Hash\nis a 32 byte hash defined as follows:\n1 byte11 bytes20 bytes\nversion (0x00)emptyaddress\n\nThis can also be understood as:\nbytes32(address(batcher))\n\nWhere batcher is the address of the account that sends transactions to the Batch Inbox. Put\nsimply, the V0 hash identifies a single address whose transaction batches will be recognized by\nL2 clients. This hash is versioned so that it could, for instance, be repurposed to be a commitment\nto a list of permitted accounts or some other form of batcher identification.\nFee Scalars\nThe Fee Scalars are parameters used to calculate the L1 data fee for L2 transactions. These\nparameters are also known as Gas Price Oracle (GPO) parameters.\nPre-Ecotone Parameters\nBefore the Ecotone upgrade, these include:\n\nScalar: A multiplier applied to the L1 base fee, interpreted as a big-endian uint256\nOverhead: A constant gas overhead, interpreted as a big-endian uint256\n\nPost-Ecotone Parameters\nAfter the Ecotone upgrade:\n\nThe Scalar attribute encodes additional scalar information in a versioned encoding scheme\nThe Overhead value is ignored and does not affect the L2 state-transition output. As of\nSystemConfig v4.0.0 it is also no longer writable, since setGasConfig was its only writer,\nand setGasConfigEcotone emits zero in its place\n\nPost-Ecotone Scalar Encoding\nThe Scalar is encoded as big-endian uint256, interpreted as bytes32, and composed as follows:\n\nByte 0: scalar-version byte\nBytes [1, 32): depending on scalar-version:\n\nScalar-version 0:\n\nBytes [1, 28): padding, should be zero\nBytes [28, 32): big-endian uint32, encoding the L1-fee baseFeeScalar\nThis version implies the L1-fee blobBaseFeeScalar is set to 0\nIf there are non-zero bytes in the padding area, baseFeeScalar must be set to MaxUint32\n\nScalar-version 1:\n\nBytes [1, 24): padding, must be zero\nBytes [24, 28): big-endian uint32, encoding the blobBaseFeeScalar\nBytes [28, 32): big-endian uint32, encoding the baseFeeScalar\n\nThe baseFeeScalar corresponds to the share of the user-transaction (per byte) in the total\nregular L1 EVM gas usage consumed by the data-transaction of the batch-submitter. For blob\ntransactions, this is the fixed intrinsic gas cost of the L1 transaction.\nThe blobBaseFeeScalar corresponds to the share of a user-transaction (per byte) in the total\nblobdata that is introduced by the data-transaction of the batch-submitter.\nUnsafe Block Signer\nThe Unsafe Block Signer is an Ethereum address whose corresponding private key is used to sign\n\"unsafe\" blocks before they are published to L1. This signature allows nodes in the P2P network to\nrecognize these blocks as the canonical unsafe blocks, preventing denial of service attacks on the\nP2P layer.\nTo ensure that its value can be fetched with a storage proof in a storage layout independent\nmanner, it is stored at a special storage slot corresponding to\nkeccak256(\"systemconfig.unsafeblocksigner\").\nUnlike other system config parameters, the Unsafe Block Signer only operates on blockchain policy\nand is not a consensus level parameter.\nL2 Gas Limit\nThe L2 Gas Limit defines the maximum amount of gas that can be used in a single L2 block.\nThis parameter ensures that L2 blocks remain of reasonable size to be processed and proven.\nChanges to the L2 gas limit are fully applied in the first L2 block with the L1 origin that\nintroduced the change, as opposed to the 1/1024 adjustments towards a target as seen in limit\nupdates of L1 blocks.\nThe gas limit may not be set to a value larger than the\nmaximum gas limit. This is to ensure that L2 blocks are fault\nprovable and of reasonable size to be processed by the client software.\nCustomizable Feature\nA Customizable Feature is a component of the OP Stack that is maintained as a production-grade\nelement of the stack behind some sort of toggle. A Customizable Feature is distinct from other\ntypes of feature-flagged code because it is part of the mainline OP Stack and is intended to remain\nas a supported configuration option indefinitely. Unlike short-lived feature flags, which exist\nonly to keep develop releasable while work is in progress, customizable features are permanent,\nuser-facing options. They must be fully documented, tested in all supported modes, and designed for\nlong-term maintainability.\nFunctionality\nSystem Config Updates\nSystem config updates are signaled through the ConfigUpdate(uint256,uint8,bytes) event. The event\nstructure includes:\n\nThe first topic determines the version\nThe second topic determines the type of update\nThe remaining event data encodes the configuration update\n\nIn version 0, the following update types are supported:\n\nType 0: batcherHash overwrite, as bytes32 payload\nType 1: Pre-Ecotone, overhead and scalar overwrite, as two packed uint256 entries. After\nEcotone upgrade, overhead is ignored and scalar is interpreted as a versioned encoding that\nupdates baseFeeScalar and blobBaseFeeScalar. As of SystemConfig v4.0.0 the overhead entry\nis always zero, and the payload stays two words so its length is unchanged\nType 2: gasLimit overwrite, as uint64 payload\nType 3: unsafeBlockSigner overwrite, as address payload\nType 4: eip1559Params overwrite, as uint256 payload encoding denomination and elasticity\nType 5: operatorFeeParams overwrite, as uint256 payload encoding scalar and constant\nType 6: minBaseFee overwrite, as uint64 payload\nType 7: daFootprintGasScalar overwrite, as uint16 payload\n\nIf a System Config Update cannot be parsed for any reason, it is not applied and is instead skipped.\nFunction Specification\nVersion markers below refer to op-contracts releases: (+op-contracts/vX.Y.Z) marks behavior\nintroduced in that release, (-op-contracts/vX.Y.Z) marks behavior that applies before it. A\nversion written as SystemConfig vX.Y.Z is the contract's own semver.\ninitialize\n\nMUST only be triggerable by the ProxyAdmin or its owner.\nMUST only be triggerable once.\nMUST set the owner of the contract to the provided _owner address.\nMUST set the SuperchainConfig contract address.\nMUST set the batcher hash, gas config, gas limit, unsafe block signer, resource config,\nL1 contract addresses, and L2 chain ID.\n(-op-contracts/v8.0.0) MUST set the Batch Inbox address.\n(+op-contracts/v8.0.0) MUST clear the legacy batch inbox storage slot. The OP Stack reads the\nbatch inbox address from the rollup configuration, so the onchain copy was redundant and could\ndrift from it.\nMUST set the start block to the current block number if it hasn't been set already.\nMUST validate the resource configuration parameters against system constraints.\n\nupgrade\n\nMUST only be triggerable by the ProxyAdmin or its owner.\nMUST set the L2 chain ID to the provided value.\nMUST set the SuperchainConfig contract address to the provided value.\nMUST clear the old dispute game factory address from storage (now derived from OptimismPortal).\n\nsetFeatureEnabled\n(+op-contracts/v4.1.0)\n\nUsed to enable or disable a Customizable Feature.\nTakes a bytes32 feature string and a boolean as an input.\nMUST only be triggerable by the ProxyAdmin or its owner.\nMUST toggle the feature flag on or off, based on the value of the boolean.\n\nisFeatureEnabled\n(+op-contracts/v4.1.0)\n\nTakes a bytes32 feature string as an input.\nReturns true if the feature is enabled and false otherwise.\n\nminimumGasLimit\nReturns the minimum L2 gas limit that can be safely set for the system to operate, calculated as\nthe sum of the maximum resource limit and the system transaction maximum gas.\nmaximumGasLimit\nReturns the maximum L2 gas limit that can be safely set for the system to operate.\nunsafeBlockSigner\nReturns the address of the Unsafe Block Signer.\nl1CrossDomainMessenger\nReturns the address of the L1CrossDomainMessenger contract.\nl1ERC721Bridge\nReturns the address of the L1ERC721Bridge contract.\nl1StandardBridge\nReturns the address of the L1StandardBridge contract.\ndisputeGameFactory\nReturns the address of the DisputeGameFactory contract, derived from the OptimismPortal.\noptimismPortal\nReturns the address of the OptimismPortal contract.\noptimismMintableERC20Factory\nReturns the address of the OptimismMintableERC20Factory contract.\ngetAddresses\nReturns a consolidated struct containing all the L1 contract addresses.\nbatchInbox\n(-op-contracts/v8.0.0) Returns the address of the Batch Inbox. Removed in\nSystemConfig v4.0.0, because the batch inbox address lives in the rollup configuration, which is\nwhat the OP Stack reads.\nstartBlock\nReturns the block number at which the op-node can start searching for logs.\npaused\n(-op-contracts/v4.1.0) This function integrates with the Pause Mechanism by\nusing the chain's ETHLockbox address as the Pause Identifier.\nReturns the current pause state of the system by checking if the SuperchainConfig is paused for\nthis chain's ETHLockbox.\n(+op-contracts/v4.1.0) This function integrates with the Pause Mechanism by\nusing either the chain's ETHLockbox address or the chain's OptimismPortal address as the\nPause Identifier.\n\n(-op-contracts/v4.1.0) MUST return true if SuperchainConfig.paused(optimismPortal().ethLockbox()) returns\ntrue OR if SuperchainConfig.paused(address(0)) returns true.\n(+op-contracts/v4.1.0) MUST return true if SuperchainConfig.paused(optimismPortal().ethLockbox()) returns\ntrue AND the system is configured to use the ETHLockbox contract.\n(+op-contracts/v4.1.0) MUST return true if SuperchainConfig.paused(optimismPortal()) returns true AND the\nsystem is NOT configured to use the ETHLockbox contract.\n(+op-contracts/v4.1.0) MUST return true if SuperchainConfig.paused(address(0)) returns true.\nMUST return false otherwise.\n\nsuperchainConfig\nReturns the address of the SuperchainConfig contract that manages the pause state.\nsetUnsafeBlockSigner\nAllows the owner to update the Unsafe Block Signer address.\n\nMUST revert if called by an address other than the owner.\nMUST update the unsafe block signer address.\nMUST emit a ConfigUpdate event with the UpdateType.UNSAFE_BLOCK_SIGNER type.\n\nsetBatcherHash\nAllows the owner to update the Batcher Hash.\n\nMUST revert if called by an address other than the owner.\nMUST update the batcher hash.\nMUST emit a ConfigUpdate event with the UpdateType.BATCHER type.\n\nsetGasConfig\n(-op-contracts/v8.0.0) Allows the owner to update the gas configuration parameters (pre-Ecotone).\nRemoved in SystemConfig v4.0.0; use setGasConfigEcotone instead.\n\nMUST revert if called by an address other than the owner.\nMUST revert if the scalar exceeds the maximum allowed value (no upper 8 bits should be set).\nMUST update the overhead and scalar values.\nMUST emit a ConfigUpdate event with the UpdateType.FEE_SCALARS type.\n\nsetGasConfigEcotone\nAllows the owner to update the gas configuration parameters (post-Ecotone).\n\nMUST revert if called by an address other than the owner.\nMUST update the basefeeScalar and blobbasefeeScalar values.\nMUST update the scalar value with the versioned encoding.\nMUST emit a ConfigUpdate event with the UpdateType.FEE_SCALARS type.\n\nsetGasLimit\nAllows the owner to update the L2 Gas Limit.\n\nMUST revert if called by an address other than the owner.\nMUST revert if the gas limit is less than the minimum gas limit.\nMUST revert if the gas limit is greater than the maximum gas limit.\nMUST update the gas limit.\nMUST emit a ConfigUpdate event with the UpdateType.GAS_LIMIT type.\n\nsetEIP1559Params\nAllows the owner to update the EIP-1559 parameters of the chain.\n\nMUST revert if called by an address other than the owner.\nMUST revert if the denominator is less than 1.\nMUST revert if the elasticity is less than 1.\nMUST update the eip1559Denominator and eip1559Elasticity values.\nMUST emit a ConfigUpdate event with the UpdateType.EIP_1559_PARAMS type.\n\nsetOperatorFeeScalars\nAllows the owner to update the operator fee parameters.\n\nMUST revert if called by an address other than the owner.\nMUST update the operatorFeeScalar and operatorFeeConstant values.\nMUST emit a ConfigUpdate event with the UpdateType.OPERATOR_FEE_PARAMS type.\n\nsetMinBaseFee\nStarting at Jovian, this function allows the owner to update the minimum base fee parameter.\n\nMUST revert if called by an address other than the owner.\nMUST update the minBaseFee value.\nMUST emit a ConfigUpdate event with the UpdateType.MIN_BASE_FEE type.\n\nsetDAFootprintGasScalar\nStarting at Jovian, this function allows the owner to update the DA footprint gas scalar.\n\nMUST revert if called by an address other than the owner.\nMUST update the daFootprintGasScalar value.\nMUST emit a ConfigUpdate event with the UpdateType.DA_FOOTPRINT_GAS_SCALAR type.\n\nresourceConfig\nReturns the current resource metering configuration.\n\nMUST perform validation checks when setting the resource config:\n\nMinimum base fee must be less than or equal to maximum base fee\nBase fee change denominator must be greater than 1\nMax resource limit plus system transaction gas must be less than or equal to the L2 gas limit\nElasticity multiplier must be greater than 0\nNo precision loss when computing target resource limit\n\nguardian\nReturns the address of the guardian from the SuperchainConfig contract.\n\nMUST return the result of a call to superchainConfig.guardian().","tokens":3660,"squid":"ink-governance","role":"Council Listener","at":1791262630504,"hash":"20757282eadbd90dc9b9c38e1b72dcf1b6675dba"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19478133076123-Why-wait-7-days-to-claim-funds-when-bridge-to-Ethereum","domain":"support.arbitrum.io","title":"Why wait 7 days to claim funds when bridge to Ethereum? – Arbitrum Foundation","text":"Whenever there are bridge transactions into the Ethereum mainnet using the official Arbitrum bridge, there is a mandatory 7-day waiting period for withdrawals and this is due to the bridge's security measures.The 7-day waiting period for withdrawals back to L1 (mainnet) on Arbitrum is a security measure designed to protect against fraud. This is because Arbitrum is an optimistic rollup, which means that transactions are initially processed without being verified. If someone tries to submit a fraudulent transaction, there is a 7-day window during which verifiers can submit a fraud proof. If a fraud proof is submitted, the transaction will be reversed and the fraudster will be penalized.\n\n Recently viewed articlesWhy are there 2 different USDC's on Arbitrum?Using Arbitrum's traditional bridge to move funds to MainnetBridging over a new tokenYou need ETH to power transactionsWhy do I have 0 voting power even though I have $ARB?\n\n Related articles\n\n Why are there 2 different USDC's on Arbitrum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Skipping the bridge\n\n You need ETH to power transactions\n\n Why do I need ETH to use the Arbitrum network?\n\n Please sign in to leave a comment.","tokens":303,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262632131,"hash":"196a62a2805fa424e663d0046d82e3ac58dca61e"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJtuZrmQEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJvwMxu3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSI6L2hjL2VuLWdiL2FydGljbGVzLzE4MjEzNzcxODMyOTg3LVNraXBwaW5nLXRoZS1icmlkZ2UGOwhUOglyYW5raQg%3D--18db04fad5d3b8e92842729a7e50910e251e0e71","domain":"support.arbitrum.io","title":"Skipping the bridge – Arbitrum Foundation","text":"You may want to skip bridging if\n\nYou already have funds sitting in a centralized exchange (CEX)\nYou don’t have enough funds in your L1 and want to “top up” your balance via a centralized exchange or fiat on-ramp\n\nWhen you go to transfer funds from your centralized exchange of choice, you’ll have the option to move your funds directly to Arbitrum instead of to Ethereum.\nFor fiat on-ramps, you’ll select Arbitrum directly.\nHow do I choose between a centralized exchange and a fiat on-ramp?\nIf we’re being precise, CEXs are technically also fiat on-ramps. They allow you to on-ramp your fiat currency, or to use your bank account to get crypto. CEXs generally are given their own category because they also store crypto assets. Other fiat on-ramps don’t store any assets, they just immediately transfer your funds to a crypto wallet.\nCEX’s are typically larger and have more oversight. That doesn’t mean they are incorruptible or hack-proof but they do have more eyeballs on them watching to make sure they don’t steal your funds.\nBoth require you to submit some personally identifiable documentation. This is called KYC (Know-Your-Customer). The government requires this from them.\nTo decide which one you want to use, it’s best to read into (1) what their fees are and (2) how legitimate they are in the community and how trusted they are.\n\n Recently viewed articlesWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Using Arbitrum's traditional bridge to move funds to MainnetBridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Bridging over a new token\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n Please sign in to leave a comment.","tokens":473,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262642541,"hash":"ca7c389e2a9f09aa3e6c3636816eb04db34631da"}
{"url":"https://specs.optimism.io/print.html","domain":"specs.optimism.io","title":"OP Stack Specification","text":"OP Stack Specification\n\nTable of Contents\n\nAbout Optimism\nAbout the OP Stack\nSite Navigation\n\nAbout Optimism\nOptimism is a project dedicated to scaling Ethereum's technology and expanding its ability to\ncoordinate people from across the world to build effective decentralized economies and governance systems. The\nOptimism Collective builds open-source software that powers scalable blockchains and\naims to address key governance and economic challenges in the wider Ethereum ecosystem. Optimism operates on the\nprinciple of impact=profit, the idea that individuals who positively impact the Collective should be proportionally\nrewarded with profit.\nChange the incentives and you change the world.\nAbout the OP Stack\nThe OP Stack is a decentralized software stack maintained by the OP Stack that forms the backbone of blockchains like\nOP Mainnet and Base. The OP Stack is designed to be aggressively\nopen-source — you are welcome to explore, modify, and extend the OP Stack to your heart's content.\nSite Navigation\nNavigate this site using the sidebar on the left, the search icon found at the top of this page, or the left/right\nnavigation buttons found to the sides of each page.\n\nBackground\n\nTable of Contents\n\nOverview\nFoundations\n\nEthereum Scalability\nOptimistic Rollups\nEVM Equivalence\n\nProtocol Guarantees\n\nLiveness\nValidity\nAvailability\n\nNetwork Participants\n\nUsers\nSequencers\nVerifiers\n\nKey Interaction Diagrams\n\nDepositing and Sending Transactions\nWithdrawing\n\nNext Steps\n\nOverview\nThe OP Stack is a decentralized software stack maintained by the OP Stack that forms the backbone of blockchains like\nOP Mainnet and Base. The OP Stack provides the infrastructure for\noperating EVM equivalent rollup blockchains designed to scale Ethereum while remaining maximally compatible with\nexisting Ethereum infrastructure. This document provides an overview of the protocol to provide context for the rest of\nthe specification.\nFoundations\nEthereum Scalability\nScaling Ethereum means increasing the number of useful transactions the Ethereum network can process. Ethereum's\nlimited resources, specifically bandwidth, computation, and storage, constrain the number of transactions which can be\nprocessed on the network. Of the three resources, computation and storage are currently the most significant\nbottlenecks. These bottlenecks limit the supply of transactions, leading to extremely high fees. Scaling ethereum and\nreducing fees can be achieved by better utilizing bandwidth, computation and storage.\nOptimistic Rollups\nAn Optimistic Rollup is a layer 2 scalability construction which\nincreases the computation & storage capacity of Ethereum while aiming to minimize sacrifices to scalability or\ndecentralization. In a nutshell, an Optimistic Rollup utilizes Ethereum (or some other data availability layer) to host\ntransaction data. Layer 2 nodes then execute a state transition function over this data. Users can propose the result of\nthis off-chain execution to a smart contract on L1. A \"fault proving\" process can then demonstrate that a user's proposal\nis (or is not) valid.\nEVM Equivalence\nEVM Equivalence is complete compliance\nwith the state transition function described in the Ethereum yellow paper, the formal definition of the protocol. By\nconforming to the Ethereum standard across EVM equivalent rollups, smart contract developers can write once and deploy\nanywhere.\nProtocol Guarantees\nWe strive to preserve three critical properties: liveness, validity, and availability.\nA protocol that can maintain these properties can, effectively, scale Ethereum without sacrificing security.\nLiveness\nLiveness is defined as the ability for any party to be able to extend the rollup chain by including a transaction within\na bounded amount of time. It should not be possible for an actor to block the inclusion of any given transaction for more\nthan this bounded time period. This bounded time period should also be acceptable such that inclusion is not just\ntheoretically possible but practically useful.\nValidity\nValidity is defined as the ability for any party to execute the rollup state transition function, subject to certain lower\nbound expectations for available computing and bandwidth resources. Validity is also extended to refer to the ability for\na smart contract on Ethereum to be able to validate this state transition function economically.\nAvailability\nAvailability is defined as the ability for any party to retrieve the inputs that are necessary to execute the rollup state\ntransition function correctly. Availability is essentially an element of validity and is required to be able to guarantee\nvalidity in general. Similar to validity, availability is subject to lower bound resource requirements.\nNetwork Participants\nGenerally speaking, there are three primary actors that interact with an OP Stack chain: users, sequencers, and verifiers.\n\nUsers\nUsers are the general class of network participants who:\n\nSubmit transactions through a Sequencer or by interacting with contracts on Ethereum.\nQuery transaction data from interfaces operated by verifiers.\n\nSequencers\nSequencers fill the role of the block producer on an OP Stack chain. Chains may have a single Sequencer or may choose to\nutilize some consensus protocol that coordinates multiple Sequencers. The OP Stack currently officially only supports a\nsingle active Sequencer at any given time. In general, specifications may use the term \"the Sequencer\" as a stand-in for\neither a single Sequencer or a consensus protocol of multiple Sequencers.\nThe Sequencer:\n\nAccepts transactions directly from Users.\nObserves \"deposit\" transactions generated on Ethereum.\nConsolidates both transaction streams into ordered L2 blocks.\nSubmits information to L1 that is sufficient to fully reproduce those L2 blocks.\nProvides real-time access to pending L2 blocks that have not yet been confirmed on L1.\n\nThe Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally\nresponsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently\nbe possible if users were to submit all transactions directly to L1.\nVerifiers\nVerifiers download and execute the L2 state transition function independently of the Sequencer. Verifiers help to maintain\nthe integrity of the network and serve blockchain data to Users.\nVerifiers generally:\n\nDownload rollup data from L1 and the Sequencer.\nUse rollup data to execute the L2 state transition function.\nServe rollup data and computed L2 state information to Users.\n\nVerifiers can also act as Proposers and/or Challengers who:\n\nSubmit assertions about the state of the L2 to a smart contract on L1.\nValidate assertions made by other participants.\nDispute invalid assertions made by other participants.\n\nKey Interaction Diagrams\nDepositing and Sending Transactions\nUsers will often begin their L2 journey by depositing ETH from L1.\nOnce they have ETH to pay fees, they'll start sending transactions on L2.\nThe following diagram demonstrates this interaction and all key OP Stack components which are or should be utilized:\n\nWithdrawing\nUsers may also want to withdraw ETH or ERC20 tokens from an OP Stack chain back to Ethereum. Withdrawals are initiated\nas standard transactions on L2 but are then completed using transactions on L1. Withdrawals must reference a valid\nFaultDisputeGame contract that proposes the state of the L2 at a given point in time.\n\nNext Steps\nCheck out the sidebar to the left to find any specification you might want to read, or click one of the links embedded\nin one of the above diagrams to learn about particular components that have been mentioned.\n\nOptimism Overview\n\nTable of Contents\n\nArchitecture Design Goals\nArchitecture Overview\n\nCore L1 Smart Contracts\n\nNotes for Core L1 Smart Contracts\n\nCore L2 Smart Contracts\n\nNotes for Core L2 Smart Contracts\n\nSmart Contract Proxies\n\nL2 contract upgrades\n\nL2 Node Components\nTransaction/Block Propagation\n\nKey Interactions In Depth\n\nDeposits\nBlock Derivation\n\nOverview\nEpochs and the Sequencing Window\nBlock Derivation Loop\n\nEngine API\n\nThis document is a high-level technical overview of the Optimism protocol. It aims to explain how the protocol works in\nan informal manner, and direct readers to other parts of the specification so that they may learn more.\nThis document assumes you've read the background.\nArchitecture Design Goals\n\nExecution-Level EVM Equivalence: The developer experience should be identical to L1 except where L2 introduces a\nfundamental difference.\n\nNo special compiler.\nNo unexpected gas costs.\nTransaction traces work out-of-the-box.\nAll existing Ethereum tooling works - all you have to do is change the chain ID.\n\nMaximal compatibility with ETH1 nodes: The implementation should minimize any differences with a vanilla\nexecution-layer node, and leverage as many existing L1 standards as possible.\n\nThe execution engine/rollup node uses the ETH2 Engine API to build the canonical L2 chain.\nThe execution engine leverages the execution layer's existing mempool and sync implementations, including snap sync.\n\nMinimize state and complexity:\n\nWhenever possible, services contributing to the rollup infrastructure are stateless.\nStateful services can recover to full operation from a fresh DB using the peer-to-peer network and on-chain sync\nmechanisms.\nRunning a replica is as simple as running an execution-layer node.\n\nArchitecture Overview\nBlue nodes are upgradeable contracts, green nodes have fixed implementations, and orange nodes are actors or protocol\ntransactions. Grey nodes show other contracts, addresses, or configuration. Dotted arrows indicate reads.\nCore L1 Smart Contracts\nBelow you'll find architecture diagrams describing the core L1 smart contracts for the OP Stack.\nSmart contracts that are considered \"peripheral\" and not core to the operation of the OP Stack system are described separately.\nThese diagrams assume a single ETH-gas chain with ETHLockbox enabled.\n\nThe portal uses dispute games to verify withdrawals. Permissionless games dispute super roots at L2 timestamps;\nthe portal reads the output root for its chain from the selected game.\n\nNotes for Core L1 Smart Contracts\n\nSmart contracts that sit behind Proxy contracts are highlighted in BLUE. Refer to the\nSmart Contract Proxies section below to understand how these proxies are designed.\n\nThe L1CrossDomainMessenger contract sits behind the ResolvedDelegateProxy\ncontract, a legacy proxy contract type used within older versions of the OP Stack. This proxy type is used exclusively\nfor the L1CrossDomainMessenger to maintain backwards compatibility.\nThe L1StandardBridge contract sits behind the L1ChugSplashProxy\ncontract, a legacy proxy contract type used within older versions of the OP Stack. This proxy type is used exclusively\nfor the L1StandardBridge contract to maintain backwards compatibility.\n\nThe factory creates dispute games as clones with immutable arguments; MIPS64 and PreimageOracle are deployed\ndirectly.\nSuperFaultDisputeGame uses game type SUPER_CANNON_KONA (9). SuperPermissionedDisputeGame uses\nSUPER_PERMISSIONED (5) and accepts proposals only from its configured proposer. It resolves immediately in favor of\nthe proposal, without challenges or bonds. Withdrawal finality and Guardian checks still apply.\nUsers deposit or withdraw ETH and tokens through the bridges. They can also deposit directly through OptimismPortal,\nwhere they prove and finalize withdrawals.\nThe bridges, messenger, portal, ETHLockbox, AnchorStateRegistry, and DelayedWETH read pause state through\nSystemConfig. It combines the global pause state from SuperchainConfig\nwith the chain-specific pause state, identified by ETHLockbox. The portal also reads its configuration from SystemConfig.\nThe Guardian pauses or unpauses SuperchainConfig; a Pause Deputy installed through the\nDeputyPauseModule can trigger, but not lift, the pause. The Guardian can also blacklist or\nretire games and set the respected game type in AnchorStateRegistry. The ProxyAdmin owner also owns\nDisputeGameFactory in the standard configuration: it registers game-type implementations and init bonds, and can\nhold or recover bonds in DelayedWETH.\nProposers create games through DisputeGameFactory; AnchorStateRegistry checks game registration with the factory.\nParticipants challenge or defend permissionless games and supply preimages to PreimageOracle.\n\nCore L2 Smart Contracts\nHere you'll find architecture diagrams describing the core OP Stack smart contracts that exist natively on the L2 chain\nitself.\n\nThe L2 bridges mint, burn, or transfer tokens and send withdrawal messages through L2ToL1MessagePasser.\nDeposits can call L2CrossDomainMessenger to relay messages from L1. Both deposits and user transactions can also\ntarget other L2 contracts or addresses.\n\nNotes for Core L2 Smart Contracts\n\nL1 attributes transactions update L1Block, and the execution engine credits transaction fees to the fee vaults.\nGasPriceOracle reads fee parameters from L1Block.\nUsers typically do not mutate these contracts directly, except in the case of the FeeVault contracts where\nany user may trigger a withdrawal of collected fees to the pre-determined withdrawal address.\nFee vault withdrawals can target L1 through L2ToL1MessagePasser, or L2 directly, depending on the vault's configuration.\nThe execution engine also updates the beacon roots contract with the\nL1 origin's parent beacon block root and the\nhistory storage contract with L2 block hashes.\nUser interactions for the \"L2 Bridge Contracts\" have been omitted from these diagrams but largely follow the same user\ninteractions described in the notes for the Core L1 Smart Contracts.\n\nSmart Contract Proxies\nMost OP Stack smart contracts sit behind Proxy contracts that are managed by a ProxyAdmin contract.\nThe ProxyAdmin contract is controlled by some owner address that is a Safe multisig in the standard configuration.\nBelow you'll find a diagram that explains the behavior of the typical proxy contract.\n\nOn L1, the ProxyAdmin owner uses OP Contracts Manager to coordinate upgrades.\nThe owner's Safe delegatecalls the manager, so its calls to ProxyAdmin execute with the owner's authority.\nL2 contract upgrades\nNetwork upgrade transactions run at fork activation. They deploy the new\nimplementations and a version of L2ContractsManager, then call L2ProxyAdmin.upgradePredeploys from DEPOSITOR_ACCOUNT.\nL2ProxyAdmin delegatecalls the manager, which upgrades the predeploy proxies atomically and preserves their existing\nchain configuration. Only DEPOSITOR_ACCOUNT can call upgradePredeploys; the L2ProxyAdmin owner can still use its\nordinary administrative upgrade methods.\n\nConditionalDeployer, L2ProxyAdmin, and L2DevFeatureFlags are proxied predeploys. L2ContractsManager is deployed\nseparately for each upgrade. Its upgrade calls execute in L2ProxyAdmin's context. See the\nL2 upgrade contracts specification\nfor the deployment and configuration rules.\nL2 Node Components\nBelow you'll find a diagram illustrating the basic interactions between the components that make up an L2 node as well\nas demonstrations of how different actors use these components to fulfill their roles.\n\nThe rollup node also reads configuration updates from SystemConfig on L1.\nThe Batch Inbox Address shown above (highlighted in GREY) is not a smart contract and is instead an arbitrarily\nselected account that is assumed to have no known private key. The convention for deriving this account's address is\nprovided on the Configurability page.\n\nHistorically, it was often derived as\n0xFF0000....<L2 chain ID> where <L2 chain ID> is chain ID of the Layer 2 network for which the data is being posted.\nThis is why many chains, such as OP Mainnet, have a batch inbox address of this form.\n\nTransaction/Block Propagation\nSpec links:\n\nExecution Engine\n\nSince the execution engine implements the standard Ethereum execution-layer protocol, the OP Stack reuses the existing\npeer-to-peer network and transaction pool to propagate transactions. Execution clients interoperate on this network.\nThe same network can also be used to propagate submitted blocks and support snap-sync.\nUnsubmitted blocks, however, are propagated using a separate peer-to-peer network of Rollup Nodes. This is optional,\nhowever, and is provided as a convenience to lower latency for verifiers and their JSON-RPC clients.\nThe below diagram illustrates how the sequencer and verifiers fit together:\n\nKey Interactions In Depth\nDeposits\nSpec links:\n\nDeposits\n\nOptimism supports user deposits and L1 attributes deposits. To perform a user deposit, users\ncall the depositTransaction method on the OptimismPortal contract. This in turn emits TransactionDeposited events,\nwhich the rollup node reads during block derivation.\nL1 attributes deposits are used to register L1 block attributes (number, timestamp, etc.) on L2 via a call to the L1\nAttributes Predeploy. They cannot be initiated by users, and are instead added to L2 blocks automatically by the rollup\nnode.\nBoth deposit types are represented by a single custom EIP-2718 transaction type on L2.\nNetwork upgrade transactions also use this type at fork\nactivation to deploy and upgrade L2 contracts.\nBlock Derivation\nOverview\nThe rollup chain can be deterministically derived given an L1 Ethereum chain. The fact that the entire rollup chain can\nbe derived based on L1 blocks is what makes Optimism a rollup. This process can be represented as:\nderive_rollup_chain(l1_blockchain) -> rollup_blockchain\n\nOptimism's block derivation function is designed such that it:\n\nRequires no state other than what is easily accessible using L1 and L2 execution engine APIs.\nSupports sequencers and sequencer consensus.\nIs resilient to sequencer censorship.\n\nEpochs and the Sequencing Window\nThe rollup chain is subdivided into epochs. There is a 1:1 correspondence between L1 block numbers and epoch numbers.\nFor L1 block number n, there is a corresponding rollup epoch n which can only be derived after a sequencing window\nworth of blocks has passed, i.e. after L1 block number n + SEQUENCING_WINDOW_SIZE is added to the L1 chain.\nEach epoch contains at least one block. Every block in the epoch contains an L1 info transaction which contains\ncontextual information about L1 such as the block hash and timestamp. The first block in the epoch also contains all\ndeposits initiated via the OptimismPortal contract on L1. All L2 blocks can also contain sequenced transactions,\ni.e. transactions submitted directly to the sequencer.\nWhenever the sequencer creates a new L2 block for a given epoch, it must submit it to L1 as part of a batch, within\nthe epoch's sequencing window (i.e. the batch must land before L1 block n + SEQUENCING_WINDOW_SIZE). These batches are\n(along with the TransactionDeposited L1 events) what allows the derivation of the L2 chain from the L1 chain.\nThe sequencer does not need for a L2 block to be batch-submitted to L1 in order to build on top of it. In fact, batches\ntypically contain multiple L2 blocks worth of sequenced transactions. This is what enables\nfast transaction confirmations on the sequencer.\nSince transaction batches for a given epoch can be submitted anywhere within the sequencing window, verifiers must\nsearch all blocks within the window for transaction batches. This protects against the uncertainty of transaction\ninclusion of L1. This uncertainty is also why we need the sequencing window in the first place: otherwise the sequencer\ncould retroactively add blocks to an old epoch, and validators wouldn't know when they can finalize an epoch.\nThe sequencing window also prevents censorship by the sequencer: deposits made on a given L1 block will be included in\nthe L2 chain at worst after SEQUENCING_WINDOW_SIZE L1 blocks have passed.\nThe following diagram describes this relationship, and how L2 blocks are derived from L1 blocks (L1 info transactions\nhave been elided):\n\nBlock Derivation Loop\nA sub-component of the rollup node called the rollup driver is actually responsible for performing block derivation.\nThe rollup driver is essentially an infinite loop that runs the block derivation function. For each epoch, the block\nderivation function performs the following steps:\n\nDownloads deposit and transaction batch data for each block in the sequencing window.\nConverts the deposit and transaction batch data into payload attributes for the Engine API.\nSubmits the payload attributes to the Engine API, where they are converted into blocks and added to the canonical\nchain.\n\nThis process is then repeated with incrementing epochs until the tip of L1 is reached.\nEngine API\nThe rollup driver doesn't actually create blocks. Instead, it directs the execution engine to do so via the Engine API.\nFor each iteration of the block derivation loop described above, the rollup driver will craft a payload attributes\nobject and send it to the execution engine. The execution engine will then convert the payload attributes object into a\nblock, and add it to the chain. The basic sequence of the rollup driver is as follows:\n\nCall fork choice updated with the payload attributes object. We'll skip over the details of the\nfork choice state parameter for now - just know that one of its fields is the L2 chain's headBlockHash, and that it\nis set to the block hash of the tip of the L2 chain. The Engine API returns a payload ID.\nCall get payload with the payload ID returned in step 1. The engine API returns a payload object\nthat includes a block hash as one of its fields.\nCall new payload with the payload returned in step 2. (Ecotone blocks, must use V3, pre-Ecotone\nblocks MUST use the V2 version)\nCall fork choice updated with the fork choice parameter's headBlockHash set to the block hash\nreturned in step 2. The tip of the L2 chain is now the block created in step 1.\n\nThe swimlane diagram below visualizes the process:\n\nStandard Bridges\n\nTable of Contents\n\nOverview\nToken Depositing\nUpgradability\n\nOverview\nThe standard bridges are responsible for allowing cross domain\nETH and ERC20 token transfers. They are built on top of the cross domain\nmessenger contracts and give a standard interface for depositing tokens.\nThe bridge works for both L1 native tokens and L2 native tokens. The legacy API\nis preserved to ensure that existing applications will not experience any\nproblems with the Bedrock StandardBridge contracts.\nThe L2StandardBridge is a predeploy contract located at\n0x4200000000000000000000000000000000000010.\ninterface StandardBridge {\n event ERC20BridgeFinalized(address indexed localToken, address indexed remoteToken, address indexed from, address to, uint256 amount, bytes extraData);\n event ERC20BridgeInitiated(address indexed localToken, address indexed remoteToken, address indexed from, address to, uint256 amount, bytes extraData);\n event ETHBridgeFinalized(address indexed from, address indexed to, uint256 amount, bytes extraData);\n event ETHBridgeInitiated(address indexed from, address indexed to, uint256 amount, bytes extraData);\n\n function bridgeERC20(address _localToken, address _remoteToken, uint256 _amount, uint32 _minGasLimit, bytes memory _extraData) external;\n function bridgeERC20To(address _localToken, address _remoteToken, address _to, uint256 _amount, uint32 _minGasLimit, bytes memory _extraData) external;\n function bridgeETH(uint32 _minGasLimit, bytes memory _extraData) payable external;\n function bridgeETHTo(address _to, uint32 _minGasLimit, bytes memory _extraData) payable external;\n function deposits(address, address) view external returns (uint256);\n function finalizeBridgeERC20(address _localToken, address _remoteToken, address _from, address _to, uint256 _amount, bytes memory _extraData) external;\n function finalizeBridgeETH(address _from, address _to, uint256 _amount, bytes memory _extraData) payable external;\n function messenger() view external returns (address);\n function OTHER_BRIDGE() view external returns (address);\n}\n\nToken Depositing\nThe bridgeERC20 function is used to send a token from one domain to another\ndomain. An OptimismMintableERC20 token contract must exist on the remote\ndomain to be able to deposit tokens to that domain. One of these tokens can be\ndeployed using the OptimismMintableERC20Factory contract.\nUpgradability\nBoth the L1 and L2 standard bridges should be behind upgradable proxies.\n\nCross Domain Messengers\n\nTable of Contents\n\nOverview\nMessage Passing\nUpgradability\nMessage Versioning\n\nMessage Version 0\nMessage Version 1\n\nBackwards Compatibility Notes\n\nOverview\nThe cross domain messengers are responsible for providing a higher level API for\ndevelopers who are interested in sending cross domain messages. They allow for\nthe ability to replay cross domain messages and sit directly on top of the lower\nlevel system contracts responsible for cross domain messaging on L1 and L2.\nThe CrossDomainMessenger is extended to create both an\nL1CrossDomainMessenger as well as a L2CrossDomainMessenger.\nThese contracts are then extended with their legacy APIs to provide backwards\ncompatibility for applications that integrated before the Bedrock system\nupgrade.\nThe L2CrossDomainMessenger is a predeploy contract located at\n0x4200000000000000000000000000000000000007.\nThe base CrossDomainMessenger interface is:\ninterface CrossDomainMessenger {\n event FailedRelayedMessage(bytes32 indexed msgHash);\n event RelayedMessage(bytes32 indexed msgHash);\n event SentMessage(address indexed target, address sender, bytes message, uint256 messageNonce, uint256 gasLimit);\n event SentMessageExtension1(address indexed sender, uint256 value);\n\n function MESSAGE_VERSION() external view returns (uint16);\n function MIN_GAS_CALLDATA_OVERHEAD() external view returns (uint64);\n function MIN_GAS_CONSTANT_OVERHEAD() external view returns (uint64);\n function MIN_GAS_DYNAMIC_OVERHEAD_DENOMINATOR() external view returns (uint64);\n function MIN_GAS_DYNAMIC_OVERHEAD_NUMERATOR() external view returns (uint64);\n function OTHER_MESSENGER() external view returns (address);\n function baseGas(bytes memory _message, uint32 _minGasLimit) external pure returns (uint64);\n function failedMessages(bytes32) external view returns (bool);\n function messageNonce() external view returns (uint256);\n function relayMessage(\n uint256 _nonce,\n address _sender,\n address _target,\n uint256 _value,\n uint256 _minGasLimit,\n bytes memory _message\n ) external payable returns (bytes memory returnData_);\n function sendMessage(address _target, bytes memory _message, uint32 _minGasLimit) external payable;\n function successfulMessages(bytes32) external view returns (bool);\n function xDomainMessageSender() external view returns (address);\n}\n\nMessage Passing\nThe sendMessage function is used to send a cross domain message. To trigger\nthe execution on the other side, the relayMessage function is called.\nSuccessful messages have their hash stored in the successfulMessages mapping\nwhile unsuccessful messages have their hash stored in the failedMessages\nmapping.\nThe user experience when sending from L1 to L2 is a bit different than when\nsending a transaction from L2 to L1. When going from L1 into L2, the user does\nnot need to call relayMessage on L2 themselves. The user pays for L2 gas on L1\nand the transaction is automatically pulled into L2 where it is executed on L2.\nWhen going from L2 into L1, the user proves their withdrawal on OptimismPortal,\nthen waits for the finalization window to pass, and then finalizes the withdrawal\non the OptimismPortal, which calls relayMessage on the\nL1CrossDomainMessenger to finalize the withdrawal.\nUpgradability\nThe L1 and L2 cross domain messengers should be deployed behind upgradable\nproxies. This will allow for updating the message version.\nMessage Versioning\nMessages are versioned based on the first 2 bytes of their nonce. Depending on\nthe version, messages can have a different serialization and hashing scheme.\nThe first two bytes of the nonce are reserved for version metadata because\na version field was not originally included in the messages themselves, but\na uint256 nonce is so large that we can very easily pack additional data\ninto that field.\nMessage Version 0\nabi.encodeWithSignature(\n \"relayMessage(address,address,bytes,uint256)\",\n _target,\n _sender,\n _message,\n _messageNonce\n);\n\nMessage Version 1\nabi.encodeWithSignature(\n \"relayMessage(uint256,address,address,uint256,uint256,bytes)\",\n _nonce,\n _sender,\n _target,\n _value,\n _gasLimit,\n _data\n);\n\nBackwards Compatibility Notes\nAn older version of the messenger contracts had the concept of blocked messages\nin a blockedMessages mapping. This functionality was removed from the\nmessengers because a smart attacker could get around any message blocking\nattempts. It also saves gas on finalizing withdrawals.\nThe concept of a \"relay id\" and the relayedMessages mapping was removed.\nIt was built as a way to be able to fund third parties who relayed messages\non the behalf of users, but it was improperly implemented as it was impossible\nto know if the relayed message actually succeeded.\n\nDeposits\n\nTable of Contents\n\nOverview\nThe Deposited Transaction Type\n\nSource hash computation\nKinds of Deposited Transactions\nValidation and Authorization of Deposited Transactions\nExecution\n\nNonce Handling\n\nDeposit Receipt\nL1 Attributes Deposited Transaction\n\nL1 Attributes Deposited Transaction Calldata\n\nL1 Attributes - Bedrock, Canyon, Delta\n\nSpecial Accounts on L2\n\nL1 Attributes Depositor Account\nL1 Attributes Predeployed Contract\n\nL1 Attributes Predeployed Contract: Reference Implementation\n\nUser-Deposited Transactions\n\nDeposit Contract\n\nAddress Aliasing\nDeposit Contract Implementation: Optimism Portal\n\nOverview\nDeposited transactions, also known as deposits are transactions which\nare initiated on L1, and executed on L2. This document outlines a new transaction\ntype for deposits. It also describes how deposits are initiated on L1, along\nwith the authorization and validation conditions on L2.\nVocabulary note: deposited transaction refers specifically to an L2 transaction, while\ndeposit can refer to the transaction at various stages (for instance when it is deposited on L1).\nThe Deposited Transaction Type\nDeposited transactions have the following notable distinctions from existing\ntransaction types:\n\nThey are derived from Layer 1 blocks, and must be included as part of the protocol.\nThey do not include signature validation (see User-Deposited Transactions\nfor the rationale).\nThey buy their L2 gas on L1 and, as such, the L2 gas is not refundable.\n\nWe define a new EIP-2718 compatible transaction type with the prefix 0x7E to represent a deposit transaction.\nA deposit has the following fields\n(rlp encoded in the order they appear here):\n\nbytes32 sourceHash: the source-hash, uniquely identifies the origin of the deposit.\naddress from: The address of the sender account.\naddress to: The address of the recipient account, or the null (zero-length) address if the\ndeposited transaction is a contract creation.\nuint256 mint: The ETH value to mint on L2.\nuint256 value: The ETH value to send to the recipient account.\nuint64 gas: The gas limit for the L2 transaction.\nbool isSystemTx: If true, the transaction does not interact with the L2 block gas pool.\n\nNote: boolean is disabled (enforced to be false) starting from the Regolith upgrade.\n\nbytes data: The calldata.\n\nIn contrast to EIP-155 transactions, this transaction type:\n\nDoes not include a nonce, since it is identified by the sourceHash.\nAPI responses still include a nonce attribute:\n\nBefore Regolith: the nonce is always 0\nWith Regolith: the nonce is set to the depositNonce attribute of the corresponding transaction receipt.\n\nDoes not include signature information, and makes the from address explicit.\nAPI responses contain zeroed signature v, r, s values for backwards compatibility.\nIncludes new sourceHash, from, mint, and isSystemTx attributes.\nAPI responses contain these as additional fields.\n\nWe select 0x7E because transaction type identifiers are currently allowed to go up to 0x7F.\nPicking a high identifier minimizes the risk that the identifier will be used by another\ntransaction type on the L1 chain in the future. We don't pick 0x7F itself in case it becomes used\nfor a variable-length encoding scheme.\nSource hash computation\nThe sourceHash of a deposit transaction is computed based on the origin:\n\nUser-deposited:\nkeccak256(bytes32(uint256(0)), keccak256(l1BlockHash, bytes32(uint256(l1LogIndex)))).\nWhere the l1BlockHash, and l1LogIndex all refer to the inclusion of the deposit log event on L1.\nl1LogIndex is the index of the deposit event log in the combined list of log events of the block.\nL1 attributes deposited:\nkeccak256(bytes32(uint256(1)), keccak256(l1BlockHash, bytes32(uint256(seqNumber)))).\nWhere l1BlockHash refers to the L1 block hash of which the info attributes are deposited.\nAnd seqNumber = l2BlockNum - l2EpochStartBlockNum,\nwhere l2BlockNum is the L2 block number of the inclusion of the deposit tx in L2,\nand l2EpochStartBlockNum is the L2 block number of the first L2 block in the epoch.\nUpgrade-deposited: keccak256(bytes32(uint256(2)), keccak256(intent)).\nWhere intent is a UTF-8 byte string, identifying the upgrade intent.\n\nWithout a sourceHash in a deposit, two different deposited transactions could have the same exact hash.\nThe outer keccak256 hashes the actual uniquely identifying information with a domain,\nto avoid collisions between different types of sources.\nThe Interop derivation spec introduces two additional kinds of system deposits,\nwith domains 3 and 4.\nWe do not use the sender's nonce to ensure uniqueness because this would require an extra L2 EVM state read from the\nexecution engine during block-derivation.\nKinds of Deposited Transactions\nAlthough we define only one new transaction type, we can distinguish between two kinds of deposited\ntransactions, based on their positioning in the L2 block:\n\nThe first transaction MUST be a L1 attributes deposited transaction, followed by\nan array of zero-or-more user-deposited transactions\nsubmitted to the deposit feed contract on L1 (called OptimismPortal).\nUser-deposited transactions are only present in the first block of a L2 epoch.\n\nWe only define a single new transaction type in order to minimize modifications to L1 client\nsoftware, and complexity in general.\nValidation and Authorization of Deposited Transactions\nAs noted above, the deposited transaction type does not include a signature for validation. Rather,\nauthorization is handled by the L2 chain derivation process, which when correctly\napplied will only derive transactions with a from address attested to by the logs of the L1\ndeposit contract.\nExecution\nIn order to execute a deposited transaction:\nFirst, the balance of the from account MUST be increased by the amount of mint.\nThis is unconditional, and does not revert on deposit failure.\nThen, the execution environment for a deposited transaction is initialized based on the\ntransaction's attributes, in exactly the same manner as it would be for an EIP-155 transaction.\nThe deposit transaction is processed exactly like a type-2 (EIP-1559) transaction, with the exception of:\n\nNo fee fields are verified: the deposit does not have any, as it pays for gas on L1.\nNo nonce field is verified: the deposit does not have any, it's uniquely identified by its sourceHash.\nNo access-list is processed: the deposit has no access-list, and it is thus processed as if the access-list is empty.\nNo contract-creation init code size check is performed. The maximum deposit transaction size is constrained by L1.\ninit code size.\nNo check if from is an Externally Owner Account (EOA): the deposit is ensured not to be an EOA through L1 address\nmasking, this may change in future L1 contract-deployments to e.g. enable an account-abstraction like mechanism.\nBefore the Regolith upgrade:\n\nThe execution output states a non-standard gas usage:\n\nIf isSystemTx is false: execution output states it uses gasLimit gas.\nIf isSystemTx is true: execution output states it uses 0 gas.\n\nNo gas is refunded as ETH. (either by not refunding or utilizing the fact the gas-price of the deposit is 0)\nNo transaction priority fee is charged. No payment is made to the block fee-recipient.\nNo L1-cost fee is charged, as deposits are derived from L1 and do not have to be submitted as data back to it.\nNo base fee is charged. The total base fee accounting does not change.\n\nNote that this includes contract-deployment behavior like with regular transactions, and gas\nmetering is the same (with the exception of fee related changes above), including metering of\nintrinsic gas.\nAny non-EVM state-transition error emitted by the EVM execution is processed in a special way:\n\nIt is transformed into an EVM-error:\ni.e. the deposit will always be included, but its receipt will indicate a failure\nif it runs into a non-EVM state-transition error, e.g. failure to transfer the specified\nvalue amount of ETH due to insufficient account-balance.\nThe world state is rolled back to the start of the EVM processing, after the minting part of the deposit.\nThe nonce of from in the world state is incremented by 1, making the error equivalent to a native EVM failure.\nNote that a previous nonce increment may have happened during EVM processing, but this would be rolled back first.\n\nFinally, after the above processing, the execution post-processing runs the same:\ni.e. the gas pool and receipt are processed identical to a regular transaction.\nStarting with the Regolith upgrade however, the receipt of deposit transactions is extended with an additional\ndepositNonce value, storing the nonce value of the from sender as registered before the EVM processing.\nNote that the gas used as stated by the execution output is subtracted from the gas pool,\nbut this execution output value has special edge cases before the Regolith upgrade.\nNote for application developers: because CALLER and ORIGIN are set to from, the\nsemantics of using the tx.origin == msg.sender check will not work to determine whether\nor not a caller is an EOA during a deposit transaction. Instead, the check could only be useful for\nidentifying the first call in the L2 deposit transaction. However this check does still satisfy\nthe common case in which developers are using this check to ensure that the CALLER is unable to\nexecute code before and after the call.\nNonce Handling\nDespite the lack of signature validation, we still increment the nonce of the from account when a\ndeposit transaction is executed. In the context of a deposit-only roll up, this is not necessary\nfor transaction ordering or replay prevention, however it maintains consistency with the use of\nnonces during contract creation. It may also simplify integration with downstream\ntooling (such as wallets and block explorers).\nDeposit Receipt\nTransaction receipts use standard typing as per EIP-2718.\nThe Deposit transaction receipt type is equal to a regular receipt,\nbut extended with an optional depositNonce field.\nThe RLP-encoded consensus-enforced fields are:\n\npostStateOrStatus (standard): this contains the transaction status, see EIP-658.\ncumulativeGasUsed (standard): gas used in the block thus far, including this transaction.\n\nThe actual gas used is derived from the difference in CumulativeGasUsed with the previous transaction.\nStarting with Regolith, this accounts for the actual gas usage by the deposit, like regular transactions.\n\nbloom (standard): bloom filter of the transaction logs.\nlogs (standard): log events emitted by the EVM processing.\ndepositNonce (unique extension): Optional field. The deposit transaction persists the nonce used during execution.\ndepositNonceVersion (unique extension): Optional field. The value must be 1 if the field is present\n\nBefore Canyon, these depositNonce & depositNonceVersion fields must always be omitted.\nWith Canyon, these depositNonce & depositNonceVersion fields must always be included.\n\nStarting with Regolith, the receipt API responses utilize the receipt changes for more accurate response data:\n\nThe depositNonce is included in the receipt JSON data in API responses\nFor contract-deployments (when to == null), the depositNonce helps derive the correct contractAddress meta-data,\ninstead of assuming the nonce was zero.\nThe cumulativeGasUsed accounts for the actual gas usage, as metered in the EVM processing.\n\nL1 Attributes Deposited Transaction\nAn L1 attributes deposited transaction is a deposit transaction sent to the L1\nattributes predeployed contract.\nThis transaction MUST have the following values:\n\nfrom is 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001 (the address of the\nL1 Attributes depositor account)\nto is 0x4200000000000000000000000000000000000015 (the address of the L1 attributes predeployed\ncontract).\nmint is 0\nvalue is 0\ngasLimit is set to 150,000,000 prior to the Regolith upgrade, and 1,000,000 after.\nisSystemTx is set to true prior to the Regolith upgrade, and false after.\ndata is an encoded call to the L1 attributes predeployed contract that\ndepends on the upgrades that are active (see below).\n\nThis system-initiated transaction for L1 attributes is not charged any ETH for its allocated\ngasLimit, as it is considered part of state-transition processing.\nL1 Attributes Deposited Transaction Calldata\nL1 Attributes - Bedrock, Canyon, Delta\nThe data field of the L1 attributes deposited transaction is an ABI encoded call to the\nsetL1BlockValues() function with correct values associated with the corresponding L1 block\n(cf. reference implementation).\nSpecial Accounts on L2\nThe L1 attributes deposit transaction involves two special purpose accounts:\n\nThe L1 attributes depositor account\nThe L1 attributes predeployed contract\n\nL1 Attributes Depositor Account\nThe depositor account is an EOA with no known private key. It has the address\n0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001. Its value is returned by the CALLER and ORIGIN\nopcodes during execution of the L1 attributes deposited transaction.\nL1 Attributes Predeployed Contract\nA predeployed contract on L2 at address 0x4200000000000000000000000000000000000015, which holds\ncertain block variables from the corresponding L1 block in storage, so that they may be accessed\nduring the execution of the subsequent deposited transactions.\nThe predeploy stores the following values:\n\nL1 block attributes:\n\nnumber (uint64)\ntimestamp (uint64)\nbasefee (uint256)\nhash (bytes32)\n\nsequenceNumber (uint64): This equals the L2 block number relative to the start of the epoch,\ni.e. the L2 block distance to the L2 block height that the L1 attributes last changed,\nand reset to 0 at the start of a new epoch.\nSystem configurables tied to the L1 block, see System configuration specification:\n\nbatcherHash (bytes32): A versioned commitment to the batch-submitter(s) currently operating.\noverhead (uint256): The L1 fee overhead to apply to L1 cost computation of transactions in this L2 block.\nscalar (uint256): The L1 fee scalar to apply to L1 cost computation of transactions in this L2 block.\n\nThe contract implements an authorization scheme, such that it only accepts state-changing calls from\nthe depositor account.\nThe contract has the following solidity interface, and can be interacted with according to the\ncontract ABI specification.\nL1 Attributes Predeployed Contract: Reference Implementation\nA reference implementation of the L1 Attributes predeploy contract can be found in L1Block.sol.\nUser-Deposited Transactions\nUser-deposited transactions are deposited transactions\ngenerated by the L2 Chain Derivation process. The content of each user-deposited\ntransaction are determined by the corresponding TransactionDeposited event emitted by the\ndeposit contract on L1.\n\nfrom is unchanged from the emitted value (though it may\nhave been transformed to an alias in OptimismPortal, the deposit feed contract).\nto is any 20-byte address (including the zero address)\n\nIn case of a contract creation (cf. isCreation), this address is set to null.\n\nmint is set to the emitted value.\nvalue is set to the emitted value.\ngaslimit is unchanged from the emitted value. It must be at least 21000.\nisCreation is set to true if the transaction is a contract creation, false otherwise.\ndata is unchanged from the emitted value. Depending on the value of isCreation it is handled\nas either calldata or contract initialization code.\nisSystemTx is set by the rollup node for certain transactions that have unmetered execution.\nIt is false for user deposited transactions\n\nDeposit Contract\nThe deposit contract is deployed to L1. Deposited transactions are derived from the values in\nthe TransactionDeposited event(s) emitted by the deposit contract.\nThe deposit contract is responsible for maintaining the guaranteed gas market,\ncharging deposits for gas to be used on L2, and ensuring that the total amount of guaranteed\ngas in a single L1 block does not exceed the L2 block gas limit.\nThe deposit contract handles two special cases:\n\nA contract creation deposit, which is indicated by setting the isCreation flag to true.\nIn the event that the to address is non-zero, the contract will revert.\nA call from a contract account, in which case the from value is transformed to its L2\nalias.\n\nAddress Aliasing\nIf the caller is a contract, the address will be transformed by adding\n0x1111000000000000000000000000000000001111 to it. The math is unchecked and done on a\nSolidity uint160 so the value will overflow. This prevents attacks in which a\ncontract on L1 has the same address as a contract on L2 but doesn't have the same code. We can safely ignore this\nfor EOAs because they're guaranteed to have the same \"code\" (i.e. no code at all). This also makes\nit possible for users to interact with contracts on L2 even when the Sequencer is down.\nDeposit Contract Implementation: Optimism Portal\nA reference implementation of the deposit contract can be found in OptimismPortal.sol.\n\nWithdrawals\n\nTable of Contents\n\nOverview\nWithdrawal Flow\n\nOn L2\nOn L1\n\nThe L2ToL1MessagePasser Contract\n\nAddresses are not Aliased on Withdrawals\n\nThe Optimism Portal Contract\nWithdrawal Verification and Finalization\nSecurity Considerations\n\nKey Properties of Withdrawal Verification\nHandling Successfully Verified Messages That Fail When Relayed\nOptimismPortal can send arbitrary messages on L1\n\nOverview\nWithdrawals are cross domain transactions which are initiated on L2, and finalized by a transaction\nexecuted on L1. Notably, withdrawals may be used by an L2 account to call an L1 contract, or to transfer ETH from\nan L2 account to an L1 account.\nVocabulary note: withdrawal can refer to the transaction at various stages of the process, but we introduce\nmore specific terms to differentiate:\n\nA withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.\nA withdrawal proving transaction refers specifically to an L1 transaction\nwhich proves the withdrawal is correct (that it has been included in a merkle\ntree whose root is available on L1).\nA withdrawal finalizing transaction refers specifically to an L1 transaction which finalizes and relays the\nwithdrawal.\n\nWithdrawals are initiated on L2 via a call to the Message Passer predeploy contract, which records the important\nproperties of the message in its storage.\nWithdrawals are proven on L1 via a call to the OptimismPortal, which proves the inclusion of this withdrawal message.\nWithdrawals are finalized on L1 via a call to the OptimismPortal contract,\nwhich verifies that the fault challenge period has passed since the withdrawal message has been proved.\nIn this way, withdrawals are different from deposits which make use of a special transaction type in the\nexecution engine client. Rather, withdrawals transaction must use smart contracts on L1 for\nfinalization.\nWithdrawal Flow\nWe first describe the end to end flow of initiating and finalizing a withdrawal:\nOn L2\nAn L2 account sends a withdrawal message (and possibly also ETH) to the L2ToL1MessagePasser predeploy contract.\nThis is a very simple contract that stores the hash of the withdrawal data.\nOn L1\n\nA relayer submits a withdrawal proving transaction with the required inputs\nto the OptimismPortal contract.\nThe relayer is not necessarily the same entity which initiated the withdrawal on L2.\nThese inputs include the withdrawal transaction data, inclusion proofs, and a block number. The block number\nmust be one for which an L2 output root exists, which commits to the withdrawal as registered on L2.\nThe OptimismPortal contract retrieves the output root for the given block number from the L2OutputOracle's\ngetL2Output() function, and performs the remainder of the verification process internally.\nIf proof verification fails, the call reverts. Otherwise the hash is recorded to prevent it from being re-proven.\nNote that the withdrawal can be proven more than once if the corresponding output root changes.\nAfter the withdrawal is proven, it enters a 7 day challenge period, allowing time for other network participants\nto challenge the integrity of the corresponding output root.\nOnce the challenge period has passed, a relayer submits a withdrawal finalizing transaction to the\nOptimismPortal contract.\nThe relayer doesn't need to be the same entity that initiated the withdrawal on L2.\nThe OptimismPortal contract receives the withdrawal transaction data and verifies that the withdrawal has\nboth been proven and passed the challenge period.\nIf the requirements are not met, the call reverts. Otherwise the call is forwarded, and the hash is recorded to\nprevent it from being replayed.\n\nThe L2ToL1MessagePasser Contract\nA withdrawal is initiated by calling the L2ToL1MessagePasser contract's initiateWithdrawal function.\nThe L2ToL1MessagePasser is a simple predeploy contract at 0x4200000000000000000000000000000000000016\nwhich stores messages to be withdrawn.\ninterface L2ToL1MessagePasser {\n event MessagePassed(\n uint256 indexed nonce, // this is a global nonce value for all withdrawal messages\n address indexed sender,\n address indexed target,\n uint256 value,\n uint256 gasLimit,\n bytes data,\n bytes32 withdrawalHash\n );\n\n event WithdrawerBalanceBurnt(uint256 indexed amount);\n\n function burn() external;\n\n function initiateWithdrawal(address _target, uint256 _gasLimit, bytes memory _data) payable external;\n\n function messageNonce() public view returns (uint256);\n\n function sentMessages(bytes32) view external returns (bool);\n}\n\nThe MessagePassed event includes all of the data that is hashed and\nstored in the sentMessages mapping, as well as the hash itself.\nAddresses are not Aliased on Withdrawals\nWhen a contract makes a deposit, the sender's address is aliased. The same is not true\nof withdrawals, which do not modify the sender's address. The difference is that:\n\non L2, the deposit sender's address is returned by the CALLER opcode, meaning a contract cannot easily tell if the\ncall originated on L1 or L2, whereas\non L1, the withdrawal sender's address is accessed by calling the l2Sender() function on the OptimismPortal\ncontract.\n\nCalling l2Sender() removes any ambiguity about which domain the call originated from. Still, developers will need to\nrecognize that having the same address does not imply that a contract on L2 will behave the same as a contract on L1.\nThe Optimism Portal Contract\nThe Optimism Portal serves as both the entry and exit point to the Optimism L2. It is a contract which inherits from\nthe OptimismPortal contract, and in addition provides the following interface for\nwithdrawals:\n\nWithdrawalTransaction type\nOutputRootProof type\n\ninterface OptimismPortal {\n\n event WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success);\n\n function l2Sender() returns(address) external;\n\n function proveWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx,\n uint256 _l2OutputIndex,\n Types.OutputRootProof calldata _outputRootProof,\n bytes[] calldata _withdrawalProof\n ) external;\n\n function finalizeWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx\n ) external;\n}\n\nWithdrawal Verification and Finalization\nThe following inputs are required to prove and finalize a withdrawal:\n\nWithdrawal transaction data:\n\nnonce: Nonce for the provided message.\nsender: Message sender address on L2.\ntarget: Target address on L1.\nvalue: ETH to send to the target.\ndata: Data to send to the target.\ngasLimit: Gas to be forwarded to the target.\n\nProof and verification data:\n\nl2OutputIndex: The index in the L2 outputs where the applicable output root may be found.\noutputRootProof: Four bytes32 values which are used to derive the output root.\nwithdrawalProof: An inclusion proof for the given withdrawal in the L2ToL1MessagePasser contract.\n\nThese inputs must satisfy the following conditions:\n\nThe l2OutputIndex must be the index in the L2 outputs that contains the applicable output root.\nL2OutputOracle.getL2Output(l2OutputIndex) returns a non-zero OutputProposal.\nThe keccak256 hash of the outputRootProof values is equal to the outputRoot.\nThe withdrawalProof is a valid inclusion proof demonstrating that a hash of the Withdrawal transaction data\nis contained in the storage of the L2ToL1MessagePasser contract on L2.\n\nSecurity Considerations\nKey Properties of Withdrawal Verification\n\nIt should not be possible to 'double spend' a withdrawal, ie. to relay a withdrawal on L1 which does not\ncorrespond to a message initiated on L2. For reference, see this writeup of a vulnerability\nof this type found on Polygon.\n\nFor each withdrawal initiated on L2 (i.e. with a unique messageNonce()), the following properties must hold:\n\nIt should only be possible to prove the withdrawal once, unless the outputRoot for the withdrawal\nhas changed.\nIt should only be possible to finalize the withdrawal once.\nIt should not be possible to relay the message with any of its fields modified, ie.\n\nModifying the sender field would enable a 'spoofing' attack.\nModifying the target, data, or value fields would enable an attacker to dangerously change the\nintended outcome of the withdrawal.\nModifying the gasLimit could make the cost of relaying too high, or allow the relayer to cause execution\nto fail (out of gas) in the target.\n\nHandling Successfully Verified Messages That Fail When Relayed\nIf the execution of the relayed call fails in the target contract, it is unfortunately not possible to determine\nwhether or not it was 'supposed' to fail, and whether or not it should be 'replayable'. For this reason, and to\nminimize complexity, we have not provided any replay functionality, this may be implemented in external utility\ncontracts if desired.\nOptimismPortal can send arbitrary messages on L1\nThe L2ToL1MessagePasser contract's initiateWithdrawal function accepts a _target address and _data bytes,\nwhich is passed to a CALL opcode on L1 when finalizeWithdrawalTransaction is called after the challenge\nperiod. This means that, by design, the OptimismPortal contract can be used to send arbitrary transactions on\nthe L1, with the OptimismPortal as the msg.sender.\nThis means users of the OptimismPortal contract should be careful what permissions they grant to the portal.\nFor example, any ERC20 tokens mistakenly sent to the OptimismPortal contract are essentially lost, as they can\nbe claimed by anybody that pre-approves transfers of this token out of the portal, using the L2 to initiate the\napproval and the L1 to prove and finalize the approval (after the challenge period).\n\nGuaranteed Gas Fee Market\n\nTable of Contents\n\nOverview\nGas Stipend\nDefault Values\nLimiting Guaranteed Gas\nRationale for burning L1 Gas\nOn Preventing Griefing Attacks\n\nOverview\nDeposited transactions are transactions on L2 that are\ninitiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment\nin the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits\nin a single L1 block.\nThe gas provided to deposited transactions is sometimes called \"guaranteed gas\". The gas provided to\ndeposited transactions is unique in the regard that it is not refundable. It cannot be refunded as\nit is sometimes paid for with a gas burn and there may not be any ETH left to refund.\nThe guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like\nto purchase (on L1) on top of that.\nGuaranteed gas on L2 is bought in the following manner. An L2 gas price is calculated via an\nEIP-1559-style algorithm. The total amount of ETH required to buy that gas is then calculated as\n(guaranteed gas * L2 deposit base fee). The contract then accepts that amount of ETH (in a future\nupgrade) or (only method right now), burns an amount of L1 gas that corresponds to the L2 cost (L2 cost / L1 base fee). The L2 gas price for guaranteed gas is not synchronized with the base fee on\nL2 and will likely be different.\nGas Stipend\nTo offset the gas spent on the deposit event, we credit gas spent * L1 base fee ETH to the cost\nof the L2 gas, where gas spent is the amount of L1 gas spent processing the deposit. If the ETH\nvalue of this credit is greater than the ETH value of the requested guaranteed gas (requested guaranteed gas * L2 gas price), no L1 gas is burnt.\nDefault Values\nVariableValue\nMAX_RESOURCE_LIMIT20,000,000\nELASTICITY_MULTIPLIER10\nBASE_FEE_MAX_CHANGE_DENOMINATOR8\nMINIMUM_BASE_FEE1 gwei\nMAXIMUM_BASE_FEEtype(uint128).max\nSYSTEM_TX_MAX_GAS1,000,000\nTARGET_RESOURCE_LIMITMAX_RESOURCE_LIMIT / ELASTICITY_MULTIPLIER\n\nLimiting Guaranteed Gas\nThe total amount of guaranteed gas that can be bought in a single L1 block must be limited to\nprevent a denial of service attack against L2 as well as ensure the total amount of guaranteed gas\nstays below the L2 block gas limit.\nWe set a guaranteed gas limit of MAX_RESOURCE_LIMIT gas per L1 block and a target of\nMAX_RESOURCE_LIMIT / ELASTICITY_MULTIPLIER gas per L1 block. These numbers enabled\noccasional large transactions while staying within our target and maximum gas usage on L2.\nBecause the amount of guaranteed L2 gas that can be purchased in a single block is now limited,\nwe implement an EIP-1559-style fee market to reduce congestion on deposits. By setting the limit\nat a multiple of the target, we enable deposits to temporarily use more L2 gas at a greater cost.\n# Pseudocode to update the L2 deposit base fee and cap the amount of guaranteed gas\n# bought in a block. Calling code must handle the gas burn and validity checks on\n# the ability of the account to afford this gas.\n\n# prev_base fee is a u128, prev_bought_gas and prev_num are u64s\nprev_base_fee, prev_bought_gas, prev_num = <values from previous update>\nnow_num = block.number\n\n# Clamp the full base fee to a specific range. The minimum value in the range should be around 100-1000\n# to enable faster responses in the base fee. This replaces the `max` mechanism in the ethereum 1559\n# implementation (it also serves to enable the base fee to increase if it is very small).\ndef clamp(v: i256, min: u128, max: u128) -> u128:\n if v < i256(min):\n return min\n elif v > i256(max):\n return max\n else:\n return u128(v)\n\n# If this is a new block, update the base fee and reset the total gas\n# If not, just update the total gas\nif prev_num == now_num:\n now_base_fee = prev_base_fee\n now_bought_gas = prev_bought_gas + requested_gas\nelif prev_num != now_num:\n # Width extension and conversion to signed integer math\n gas_used_delta = int128(prev_bought_gas) - int128(TARGET_RESOURCE_LIMIT)\n # Use truncating (round to 0) division - solidity's default.\n # Sign extend gas_used_delta & prev_base_fee to 256 bits to avoid overflows here.\n base_fee_per_gas_delta = prev_base_fee * gas_used_delta / TARGET_RESOURCE_LIMIT / BASE_FEE_MAX_CHANGE_DENOMINATOR\n now_base_fee_wide = prev_base_fee + base_fee_per_gas_delta\n\n now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=UINT_128_MAX_VALUE)\n now_bought_gas = requested_gas\n\n # If we skipped multiple blocks between the previous block and now update the base fee again.\n # This is not exactly the same as iterating the above function, but quite close for reasonable\n # gas tar","tokens":15000,"squid":"ink-governance","role":"Council Listener","at":1791262645910,"hash":"5590ef8ebfc2df7961f6e7e4e481fb27297ee8ba"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/1","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"Migrate from V4 Main vault to Bluechip \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 1 / 10\n\n Jul 3\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n Zataoka\n\n Hi everyone,\nI currently have a fairly large leveraged position on Aave v4 Main Hub, with WBTC, wstETH, ETH and LINK as collateral.\nAfter comparing the risk parameters, I’ve noticed that Bluechip Hub offers significantly higher collateral factors / liquidation thresholds for the assets that make up most of my collateral (particularly WBTC and wstETH). I’d like to migrate my existing position from Main Hub to Bluechip Hub, but I couldn’t find any documentation describing the process.\nMy questions are:\n\nIs there currently a supported way to migrate an existing position from Main Hub to Bluechip Hub?\nIs there an atomic (flash-loan) migration path, or does it require manually repaying debt, withdrawing collateral, redepositing into Bluechip, and borrowing again?\nDoes Aave have any plans to support one-click migrations between hubs in the future?\nIf no migration path exists today, what is the safest recommended approach for moving a large leveraged position while minimizing liquidation and market-exposure risk?\n\nFor context, this is a six-figure borrowing position, so I’m trying to avoid any unnecessary execution risk during the migration. I would rather not manually unwind the position as I don’t intend selling collateral assets at this time.\nAny guidance from the Aave team or anyone who has done this would be greatly appreciated.\nThanks!\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n post by stani on Jul 4\n\n stani\n\n Aave Labs-Technical SP\n\n Currently there are no automated tools for migrating positions between Hubs and Spokes, however this feature is going to be build in few months.\nWhat you are looking to do is to migrate some of your position from Main Spoke (connected to Core Hub) to Bluechip Spoke (connected to Prime Spoke). Given you mentioned that you have LINK, that is only supported on Main Spoke as collateral, so you would need to split your position between two markets (the reason why Bluechip has better LTVs/ liquidator params is because it has less riskier collaterals).\nFor now I recommend to do the migration manually by repaying the loan, withdrawing collateral and resupplying into the Bluechip Spoke. You would still need to keep your LINK on Main Spoke if you want to borrow against it.\nHappy to take a deeper look if you drop a message to Customer Support (you can find it on the side menu).\n\n post by MconnectDAO on Jul 5\n\n MconnectDAO\n\n Aave v4’s hub‑and‑spoke architecture successfully achieves risk segregation, but the absence of cross‑hub migration tooling introduces UX‑driven risk for large retail and LP positions. Zataoka’s case is an early signal of this structural issue for the protocol and its governance roadmap.\ngovernance.\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n post by defi_milos on Sep 9\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 14\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 21\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":894,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262648385,"hash":"06f3372276e1d826d650ead43032021a1554dd81"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvSpb2QEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJtuZrmQEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJjL2hjL2VuLWdiL2FydGljbGVzLzE4MjEzODQzMDk2MDkxLVVzaW5nLUFyYml0cnVtLXMtdHJhZGl0aW9uYWwtYnJpZGdlLXRvLW1vdmUtZnVuZHMtdG8tTWFpbm5ldAY7CFQ6CXJhbmtpBg%3D%3D--756747c680ba6e967769661444b909f46e341e00","domain":"support.arbitrum.io","title":"Using Arbitrum's traditional bridge to move funds to Mainnet – Arbitrum Foundation","text":"If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fast exit liquidity provider like Hop, Connext, Across, Celer, or Maker. Why do I have to wait 8 days?This is how all optimistic rollups work. Optimistic rollups use something called fraud proofs in order to keep participants in the network honest. There is a \"challenge period\" for these proofs. When one party submits a claim about the state of the chain, another party has ~8 days to challenge that claim. If you'd like to read more about the technical details of Arbitrum, see Inside Arbitrum.If you're more of a visual and auditory learner, watch our videos about challenges and proofs.  More Resources:1 - (Youtube) Multi round Fraud Proofs: What, How, and Why.2 - (Youtube) Challenge Protocol\n\n Recently viewed articlesSkipping the bridgeWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Bridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n How can I add Arbitrum network to my wallet?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Godfrey brai\n\n 2 years ago\n\n I have waited for more than 12 days I still can find my ethPlease help me rectify \n\n 0\n\n Please sign in to leave a comment.","tokens":369,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262655083,"hash":"f56b734b3aa2cb790f9e693eaa3a3a41c5987c00"}
{"url":"https://specs.optimism.io/protocol/messengers.html","domain":"specs.optimism.io","title":"Messengers - OP Stack Specification","text":"Cross Domain Messengers\n\nTable of Contents\n\nOverview\nMessage Passing\nUpgradability\nMessage Versioning\n\nMessage Version 0\nMessage Version 1\n\nBackwards Compatibility Notes\n\nOverview\nThe cross domain messengers are responsible for providing a higher level API for\ndevelopers who are interested in sending cross domain messages. They allow for\nthe ability to replay cross domain messages and sit directly on top of the lower\nlevel system contracts responsible for cross domain messaging on L1 and L2.\nThe CrossDomainMessenger is extended to create both an\nL1CrossDomainMessenger as well as a L2CrossDomainMessenger.\nThese contracts are then extended with their legacy APIs to provide backwards\ncompatibility for applications that integrated before the Bedrock system\nupgrade.\nThe L2CrossDomainMessenger is a predeploy contract located at\n0x4200000000000000000000000000000000000007.\nThe base CrossDomainMessenger interface is:\ninterface CrossDomainMessenger {\n event FailedRelayedMessage(bytes32 indexed msgHash);\n event RelayedMessage(bytes32 indexed msgHash);\n event SentMessage(address indexed target, address sender, bytes message, uint256 messageNonce, uint256 gasLimit);\n event SentMessageExtension1(address indexed sender, uint256 value);\n\n function MESSAGE_VERSION() external view returns (uint16);\n function MIN_GAS_CALLDATA_OVERHEAD() external view returns (uint64);\n function MIN_GAS_CONSTANT_OVERHEAD() external view returns (uint64);\n function MIN_GAS_DYNAMIC_OVERHEAD_DENOMINATOR() external view returns (uint64);\n function MIN_GAS_DYNAMIC_OVERHEAD_NUMERATOR() external view returns (uint64);\n function OTHER_MESSENGER() external view returns (address);\n function baseGas(bytes memory _message, uint32 _minGasLimit) external pure returns (uint64);\n function failedMessages(bytes32) external view returns (bool);\n function messageNonce() external view returns (uint256);\n function relayMessage(\n uint256 _nonce,\n address _sender,\n address _target,\n uint256 _value,\n uint256 _minGasLimit,\n bytes memory _message\n ) external payable returns (bytes memory returnData_);\n function sendMessage(address _target, bytes memory _message, uint32 _minGasLimit) external payable;\n function successfulMessages(bytes32) external view returns (bool);\n function xDomainMessageSender() external view returns (address);\n}\n\nMessage Passing\nThe sendMessage function is used to send a cross domain message. To trigger\nthe execution on the other side, the relayMessage function is called.\nSuccessful messages have their hash stored in the successfulMessages mapping\nwhile unsuccessful messages have their hash stored in the failedMessages\nmapping.\nThe user experience when sending from L1 to L2 is a bit different than when\nsending a transaction from L2 to L1. When going from L1 into L2, the user does\nnot need to call relayMessage on L2 themselves. The user pays for L2 gas on L1\nand the transaction is automatically pulled into L2 where it is executed on L2.\nWhen going from L2 into L1, the user proves their withdrawal on OptimismPortal,\nthen waits for the finalization window to pass, and then finalizes the withdrawal\non the OptimismPortal, which calls relayMessage on the\nL1CrossDomainMessenger to finalize the withdrawal.\nUpgradability\nThe L1 and L2 cross domain messengers should be deployed behind upgradable\nproxies. This will allow for updating the message version.\nMessage Versioning\nMessages are versioned based on the first 2 bytes of their nonce. Depending on\nthe version, messages can have a different serialization and hashing scheme.\nThe first two bytes of the nonce are reserved for version metadata because\na version field was not originally included in the messages themselves, but\na uint256 nonce is so large that we can very easily pack additional data\ninto that field.\nMessage Version 0\nabi.encodeWithSignature(\n \"relayMessage(address,address,bytes,uint256)\",\n _target,\n _sender,\n _message,\n _messageNonce\n);\n\nMessage Version 1\nabi.encodeWithSignature(\n \"relayMessage(uint256,address,address,uint256,uint256,bytes)\",\n _nonce,\n _sender,\n _target,\n _value,\n _gasLimit,\n _data\n);\n\nBackwards Compatibility Notes\nAn older version of the messenger contracts had the concept of blocked messages\nin a blockedMessages mapping. This functionality was removed from the\nmessengers because a smart attacker could get around any message blocking\nattempts. It also saves gas on finalizing withdrawals.\nThe concept of a \"relay id\" and the relayedMessages mapping was removed.\nIt was built as a way to be able to fund third parties who relayed messages\non the behalf of users, but it was improperly implemented as it was impossible\nto know if the relayed message actually succeeded.","tokens":1169,"squid":"ink-governance","role":"Council Listener","at":1791262659900,"hash":"429f60f6796c0516568425ad9df90674f15c6b24"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/2","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 2 / 10\n\n Jul 4\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n Zataoka\n\n Hi everyone,\nI currently have a fairly large leveraged position on Aave v4 Main Hub, with WBTC, wstETH, ETH and LINK as collateral.\nAfter comparing the risk parameters, I’ve noticed that Bluechip Hub offers significantly higher collateral factors / liquidation thresholds for the assets that make up most of my collateral (particularly WBTC and wstETH). I’d like to migrate my existing position from Main Hub to Bluechip Hub, but I couldn’t find any documentation describing the process.\nMy questions are:\n\nIs there currently a supported way to migrate an existing position from Main Hub to Bluechip Hub?\nIs there an atomic (flash-loan) migration path, or does it require manually repaying debt, withdrawing collateral, redepositing into Bluechip, and borrowing again?\nDoes Aave have any plans to support one-click migrations between hubs in the future?\nIf no migration path exists today, what is the safest recommended approach for moving a large leveraged position while minimizing liquidation and market-exposure risk?\n\nFor context, this is a six-figure borrowing position, so I’m trying to avoid any unnecessary execution risk during the migration. I would rather not manually unwind the position as I don’t intend selling collateral assets at this time.\nAny guidance from the Aave team or anyone who has done this would be greatly appreciated.\nThanks!\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n post by stani on Jul 4\n\n stani\n\n Aave Labs-Technical SP\n\n Currently there are no automated tools for migrating positions between Hubs and Spokes, however this feature is going to be build in few months.\nWhat you are looking to do is to migrate some of your position from Main Spoke (connected to Core Hub) to Bluechip Spoke (connected to Prime Spoke). Given you mentioned that you have LINK, that is only supported on Main Spoke as collateral, so you would need to split your position between two markets (the reason why Bluechip has better LTVs/ liquidator params is because it has less riskier collaterals).\nFor now I recommend to do the migration manually by repaying the loan, withdrawing collateral and resupplying into the Bluechip Spoke. You would still need to keep your LINK on Main Spoke if you want to borrow against it.\nHappy to take a deeper look if you drop a message to Customer Support (you can find it on the side menu).\n\n post by MconnectDAO on Jul 5\n\n MconnectDAO\n\n Aave v4’s hub‑and‑spoke architecture successfully achieves risk segregation, but the absence of cross‑hub migration tooling introduces UX‑driven risk for large retail and LP positions. Zataoka’s case is an early signal of this structural issue for the protocol and its governance roadmap.\ngovernance.\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n Zataoka\n\n Thank you for the detailed response Stani. I will write to your customer service (usually access Aave through defisaver.com but will get onto the aave platform.\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n Zataoka\n\n stani\n\n Hi Stani — just following up on this now that it’s been a little over two months since the original discussion.\nIs there any update on the timeline, particularly for migrating an existing leveraged position from Main Spoke to Bluechip Spoke? I did write to customer support earlier as well as you mentioned\nI’ve already used DeFi Saver’s Loan Shifter to migrate my positions from V3 to V4, but as far as I can see there still isn’t an equivalent V4 Main → Bluechip migration route.\nGiven the size of the position, manually repaying the debt, withdrawing collateral and rebuilding the position isn’t really practical, so an atomic/flash-loan migration would be extremely useful\nHas this functionality been released, is it currently being worked on, or is there an updated ETA?\nThanks!\n\n post by defi_milos on Sep 9\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 14\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 21\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":1128,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262659947,"hash":"f6f4a6b0f63c0ded16c52bcf52463d722cc46bd5"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJtuZrmQEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBvSpb2QEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSI6L2hjL2VuLWdiL2FydGljbGVzLzE4MjEzNzcxODMyOTg3LVNraXBwaW5nLXRoZS1icmlkZ2UGOwhUOglyYW5raQc%3D--e1388156baa0d463c64cd4ba9ef8ac520b5c3897","domain":"support.arbitrum.io","title":"Skipping the bridge – Arbitrum Foundation","text":"You may want to skip bridging if\n\nYou already have funds sitting in a centralized exchange (CEX)\nYou don’t have enough funds in your L1 and want to “top up” your balance via a centralized exchange or fiat on-ramp\n\nWhen you go to transfer funds from your centralized exchange of choice, you’ll have the option to move your funds directly to Arbitrum instead of to Ethereum.\nFor fiat on-ramps, you’ll select Arbitrum directly.\nHow do I choose between a centralized exchange and a fiat on-ramp?\nIf we’re being precise, CEXs are technically also fiat on-ramps. They allow you to on-ramp your fiat currency, or to use your bank account to get crypto. CEXs generally are given their own category because they also store crypto assets. Other fiat on-ramps don’t store any assets, they just immediately transfer your funds to a crypto wallet.\nCEX’s are typically larger and have more oversight. That doesn’t mean they are incorruptible or hack-proof but they do have more eyeballs on them watching to make sure they don’t steal your funds.\nBoth require you to submit some personally identifiable documentation. This is called KYC (Know-Your-Customer). The government requires this from them.\nTo decide which one you want to use, it’s best to read into (1) what their fees are and (2) how legitimate they are in the community and how trusted they are.\n\n Recently viewed articlesUsing Arbitrum's traditional bridge to move funds to MainnetWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Bridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Bridging over a new token\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n Please sign in to leave a comment.","tokens":473,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262671476,"hash":"388651fb34e4b68ba2b04a00c13ae6f4536fc934"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/3","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 3 / 10\n\n Jul 4\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n Zataoka\n\n Hi everyone,\nI currently have a fairly large leveraged position on Aave v4 Main Hub, with WBTC, wstETH, ETH and LINK as collateral.\nAfter comparing the risk parameters, I’ve noticed that Bluechip Hub offers significantly higher collateral factors / liquidation thresholds for the assets that make up most of my collateral (particularly WBTC and wstETH). I’d like to migrate my existing position from Main Hub to Bluechip Hub, but I couldn’t find any documentation describing the process.\nMy questions are:\n\nIs there currently a supported way to migrate an existing position from Main Hub to Bluechip Hub?\nIs there an atomic (flash-loan) migration path, or does it require manually repaying debt, withdrawing collateral, redepositing into Bluechip, and borrowing again?\nDoes Aave have any plans to support one-click migrations between hubs in the future?\nIf no migration path exists today, what is the safest recommended approach for moving a large leveraged position while minimizing liquidation and market-exposure risk?\n\nFor context, this is a six-figure borrowing position, so I’m trying to avoid any unnecessary execution risk during the migration. I would rather not manually unwind the position as I don’t intend selling collateral assets at this time.\nAny guidance from the Aave team or anyone who has done this would be greatly appreciated.\nThanks!\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n post by stani on Jul 4\n\n stani\n\n Aave Labs-Technical SP\n\n Currently there are no automated tools for migrating positions between Hubs and Spokes, however this feature is going to be build in few months.\nWhat you are looking to do is to migrate some of your position from Main Spoke (connected to Core Hub) to Bluechip Spoke (connected to Prime Spoke). Given you mentioned that you have LINK, that is only supported on Main Spoke as collateral, so you would need to split your position between two markets (the reason why Bluechip has better LTVs/ liquidator params is because it has less riskier collaterals).\nFor now I recommend to do the migration manually by repaying the loan, withdrawing collateral and resupplying into the Bluechip Spoke. You would still need to keep your LINK on Main Spoke if you want to borrow against it.\nHappy to take a deeper look if you drop a message to Customer Support (you can find it on the side menu).\n\n post by MconnectDAO on Jul 5\n\n MconnectDAO\n\n Aave v4’s hub‑and‑spoke architecture successfully achieves risk segregation, but the absence of cross‑hub migration tooling introduces UX‑driven risk for large retail and LP positions. Zataoka’s case is an early signal of this structural issue for the protocol and its governance roadmap.\ngovernance.\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n Zataoka\n\n Thank you for the detailed response Stani. I will write to your customer service (usually access Aave through defisaver.com but will get onto the aave platform.\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n Zataoka\n\n stani\n\n Hi Stani — just following up on this now that it’s been a little over two months since the original discussion.\nIs there any update on the timeline, particularly for migrating an existing leveraged position from Main Spoke to Bluechip Spoke? I did write to customer support earlier as well as you mentioned\nI’ve already used DeFi Saver’s Loan Shifter to migrate my positions from V3 to V4, but as far as I can see there still isn’t an equivalent V4 Main → Bluechip migration route.\nGiven the size of the position, manually repaying the debt, withdrawing collateral and rebuilding the position isn’t really practical, so an atomic/flash-loan migration would be extremely useful\nHas this functionality been released, is it currently being worked on, or is there an updated ETA?\nThanks!\n\n post by defi_milos on Sep 9\n\n defi_milos\n\n Hi Zataoka!\nI’m part of the DeFi Saver team, so just wanted to drop by and offer some suggestions, along with explanations on how the migration process works.\nOur Loan Shifter tool is indeed available for moving positions from one Aave v4 market to another, so it can definitely take care of migrating your position from the v4 Main to the v4 Bluechip Spoke.\nThe only limiting factor (currently) is if your v4 position is on an EOA and not a Smart Wallet. Currently, Loan Shifter only works for positions on a Smart Wallet - but we’ll soon make it compatible with EOA positions as well.\nSo, if your position is indeed on an EOA at the moment - you’ll be able to move it via Loan Shifter in about a week or so (when we release the Loan Shifter updates).\nAs a quick sidenote, here’s how Loan Shifter performs the move atomically:\n → It flash loans all of the required debt to clear your v4 Main position’s debt\n → It withdraws the collateral\n → It supplies that collateral to the v4 Bluechip market\n → Borrows the debt asset\n → Uses it to pay back the flash loan\nIn case your position is on a Smart Wallet, you should be able to perform the move by:\n\nAccessing Loan Shifter\nUnder “From Position”, click it and it should bring up all of your positions (including the v4 Main one)\nUnder “To Position”, type in “Bluechip”, and it’ll let you select the Aave v4 Bluechip market as the destination.\nClick “Shift”\n\nAnd that’s all the required steps to get your loan moved from one market to the other.\nWill write a follow-up comment here as soon as the EOA update is live, or you can drop by our Discord/Twitter to also get notified as soon as we announce it.\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 14\n\n post by Zataoka on Sep 14\n\n post by defi_milos on Sep 21\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":1545,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262682220,"hash":"43caa125a61cf96fdfd4cf091363a4e4f92c5e70"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJvwMxu3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJtuZrmQEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJdL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4MTMzMDc2MTIzLVdoeS13YWl0LTctZGF5cy10by1jbGFpbS1mdW5kcy13aGVuLWJyaWRnZS10by1FdGhlcmV1bQY7CFQ6CXJhbmtpBw%3D%3D--95b46f5a972c59d013c4cdbd4f2aa59610cd0a3d","domain":"support.arbitrum.io","title":"Why wait 7 days to claim funds when bridge to Ethereum? – Arbitrum Foundation","text":"Whenever there are bridge transactions into the Ethereum mainnet using the official Arbitrum bridge, there is a mandatory 7-day waiting period for withdrawals and this is due to the bridge's security measures.The 7-day waiting period for withdrawals back to L1 (mainnet) on Arbitrum is a security measure designed to protect against fraud. This is because Arbitrum is an optimistic rollup, which means that transactions are initially processed without being verified. If someone tries to submit a fraudulent transaction, there is a 7-day window during which verifiers can submit a fraud proof. If a fraud proof is submitted, the transaction will be reversed and the fraudster will be penalized.\n\n Recently viewed articlesSkipping the bridgeUsing Arbitrum's traditional bridge to move funds to MainnetWhy are there 2 different USDC's on Arbitrum?Bridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Why are there 2 different USDC's on Arbitrum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Skipping the bridge\n\n You need ETH to power transactions\n\n Why do I need ETH to use the Arbitrum network?\n\n Please sign in to leave a comment.","tokens":295,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262691912,"hash":"2d1b7de02301bcdfc6b211fee75ea3716950c067"}
{"url":"https://ethresear.ch/t/designing-infrastructure-where-exploits-destroy-themselves/25348/1","domain":"ethresear.ch","title":"Designing Infrastructure Where Exploits Destroy Themselves - zk-s[nt]arks - Ethereum Research","text":"Designing Infrastructure Where Exploits Destroy Themselves \n\n zk-s[nt]arks\n\n governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2\n\n 1 / 1\n\n Jul 1\n\n Jul 2\n\n post by Dede-Qorqud on Jul 2\n\n Dede-Qorqud\n\n Vector-Defense layer1312×809 98.8 KB\nFig 1: A conceptual mapping of adversarial attack vectors against the BeTrueCore multi-layered architectural defense stack, detailing the specific components (ZK-Nullifiers, MACI, AI Sentinels, Celestia DA) deployed at each layer.\nMost collective decision-making protocols fail not at the cryptographic level, but at the human level. Traditional governance mechanisms regularly fall victim to Sybil attacks, coordinated block voting, and sophisticated vote-buying. While existing privacy solutions secure transaction confidentiality, they rarely address the structural environment in which the human signal is formed and manipulated.\nThe central claim of this work is that genuine sovereignty and privacy must be embedded in the architecture itself — in the structural environment and operational mechanics of the platform’s core architecture.\nBeTrueCore is a modular system designed to remove the conditions on which attacks against collective judgment rely. Rather than deploying reactive administrative barriers, the system utilizes a multi-layered, isolated protection stack that combines Minimal Anti-Collusion Infrastructure (MACI v1.2), zero-knowledge proofs (ZK-SNARKs via Circom), and a non-transferable non-linear reputation mechanism termed the Voting Weight of a Unit (VWU𝑉𝑊𝑈).\nThe architecture addresses three critical engineering challenges:\n1. Subverting the Vote-Buying Market\nBy leveraging mid-session choice mutability and continuous MACI-driven key rotation, BeTrueCore guarantees receipt-freeness. A participant can present any intermediate action to an external buyer as proof of compliance, yet the buyer cannot mathematically verify the final, time-locked choice. Because the commodity is unverifiable and the internal currency (VWU𝑉𝑊𝑈) is strictly inalienable, the transaction lacks an economic subject.\n2. Mitigating Scale-Based Sybil Vectors\nProtection is distributed across non-contiguous layers. Mass synthetic identities are filtered via L0 behavioral biometrics and keystroke dynamics, bound to unique L1 ZK-nullifier chains to prevent double-voting, and monitored by an L5 read-only AI Sentinel layer to detect long-horizon synchronized activity. To successfully simulate a community, an adversary must practically build one.\n3. Decentralizing the Infrastructure Layer\nTo avoid a single point of capture, the MACI coordinator must publish a mathematically verifiable state transition ZK-proof simultaneously with the result. A compromised coordinator can only affect system availability, not data integrity. Furthermore, the AI agent layer operates strictly in read-only mode, meaning an infrastructural breach grants observation rights but zero execution power.\nOperational Application of the Defense Stack: The 7-Step Daily Decision Cycle\nTo contextualize the theoretical resilience of the Web3-ISM framework, we examine its daily operational primitive, which restricts each participant to a maximum of seven discrete cryptographic actions per 24-hour session, executed in total isolation from the backend and without revealing the individual’s Vote Weight Unit (VWU𝑉𝑊𝑈).\nCrucially, the architecture enforces extreme asynchronous flexibility and anti-farming constraints:\nØ Screentime Efficiency: A user may execute anywhere from 1 to 7 actions during an active day, requiring less than 60 minutes of total interaction within the session window.\nØ Variable Participation Frequency (Missed Opportunity Metric): High daily retention is not mechanically mandated. A participant can activate a session as infrequently as once a week or once a month. To maintain strict psychological comfort, the architecture ensures that accumulated points, ranks, and badges are never deducted or penalized for dormancy. Instead, periods of inactivity are recorded strictly as missed cryptographic opportunities. While the user’s historical status remains fully intact, their relative dynamic voting trajectory (VWU𝑉𝑊𝑈) flattens during absence, preventing mass offline accounts from passively hoarding governance alpha without continuous cognitive contribution.\nWhen a session is active, the seven-step cycle unfolds as follows:\n\nPrompt Generation (Action 1): The user inputs a single text prompt encapsulating their session thesis, immediately subjected to L0 keystroke dynamics filtering and L5 semantic anomaly clustering to intercept automated AI injection.\n\nPattern Formulation (Actions 2–4): The user executes three binary selections to nominate a Top-3 from a randomized pool of other participants’ prompts; these actions are fully obscured by continuous MACI key-rotation, achieving receipt-freeness.\n\nOutput Selection (Actions 5–7): The user casts three binary votes on practical dilemmas derived from the previous session’s Top-3 pool, committing the signals to the state transition proof.\nConsequently, an adversary attempting a coordinated capture cannot rely on high-throughput script execution or mass passive account hoarding; to shift the system state, the hostile infrastructure must authentically simulate distinct human cognitive engagement vectors across highly irregular, fluid intervals, shifting the cost of attack from capital expenditure to computational and cognitive impossibility.\n\nTechnical Discussion & Feedback\nWe are currently in Phase 2 of our roadmap, focusing on circuit integration, MACI optimization, and preparing for an MVP launch on an EVM testnet. We welcome feedback from Ethereum research engineers, ZK cryptographers, and Solidity developers interested in robust anti-collusion infrastructure.\nIn particular:\n\nDoes the receipt-freeness argument hold under a stronger adversary model (e.g. one who can observe all intermediate choices in real time)?\n\nIs MACI v1.2 the right primitive for the nullifier layer, or are there more recent constructions that fit better?\n\nWhat is the right aggregation strategy for session-level STARK proofs — per-session batch, per-day batch, or rolling?\n\nVerification & Open Source\n· Complete Paper (Zenodo Preprint): The Notary Under Attack: An Adversarial Model for Cryptographic Collective Intelligence. https://doi.org/10.5281/zenodo.21111544\n· Verification: The Master Document of BeTrueCore MS is hashed (SHA-256) via OpenTimestamps.\n· Repository: https://github.com/Dede-Qorqud/BeTrueCore\n\n Sovereign Space: When Values Need Architecture\n\n What if post-quantum Ethereum doesn’t need signatures at all?\n\n Powered by Discourse","tokens":1674,"squid":"ink-research","role":"Deep Scholar","at":1791262699865,"hash":"9b4c3c395e4c1a8c4083d88d6f12501576cb27d4"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/5","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 5 / 10\n\n Sep 8\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n Zataoka\n\n Hi everyone,\nI currently have a fairly large leveraged position on Aave v4 Main Hub, with WBTC, wstETH, ETH and LINK as collateral.\nAfter comparing the risk parameters, I’ve noticed that Bluechip Hub offers significantly higher collateral factors / liquidation thresholds for the assets that make up most of my collateral (particularly WBTC and wstETH). I’d like to migrate my existing position from Main Hub to Bluechip Hub, but I couldn’t find any documentation describing the process.\nMy questions are:\n\nIs there currently a supported way to migrate an existing position from Main Hub to Bluechip Hub?\nIs there an atomic (flash-loan) migration path, or does it require manually repaying debt, withdrawing collateral, redepositing into Bluechip, and borrowing again?\nDoes Aave have any plans to support one-click migrations between hubs in the future?\nIf no migration path exists today, what is the safest recommended approach for moving a large leveraged position while minimizing liquidation and market-exposure risk?\n\nFor context, this is a six-figure borrowing position, so I’m trying to avoid any unnecessary execution risk during the migration. I would rather not manually unwind the position as I don’t intend selling collateral assets at this time.\nAny guidance from the Aave team or anyone who has done this would be greatly appreciated.\nThanks!\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n post by stani on Jul 4\n\n stani\n\n Aave Labs-Technical SP\n\n Currently there are no automated tools for migrating positions between Hubs and Spokes, however this feature is going to be build in few months.\nWhat you are looking to do is to migrate some of your position from Main Spoke (connected to Core Hub) to Bluechip Spoke (connected to Prime Spoke). Given you mentioned that you have LINK, that is only supported on Main Spoke as collateral, so you would need to split your position between two markets (the reason why Bluechip has better LTVs/ liquidator params is because it has less riskier collaterals).\nFor now I recommend to do the migration manually by repaying the loan, withdrawing collateral and resupplying into the Bluechip Spoke. You would still need to keep your LINK on Main Spoke if you want to borrow against it.\nHappy to take a deeper look if you drop a message to Customer Support (you can find it on the side menu).\n\n post by MconnectDAO on Jul 5\n\n MconnectDAO\n\n Aave v4’s hub‑and‑spoke architecture successfully achieves risk segregation, but the absence of cross‑hub migration tooling introduces UX‑driven risk for large retail and LP positions. Zataoka’s case is an early signal of this structural issue for the protocol and its governance roadmap.\ngovernance.\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n Zataoka\n\n Thank you for the detailed response Stani. I will write to your customer service (usually access Aave through defisaver.com but will get onto the aave platform.\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n Zataoka\n\n stani\n\n Hi Stani — just following up on this now that it’s been a little over two months since the original discussion.\nIs there any update on the timeline, particularly for migrating an existing leveraged position from Main Spoke to Bluechip Spoke? I did write to customer support earlier as well as you mentioned\nI’ve already used DeFi Saver’s Loan Shifter to migrate my positions from V3 to V4, but as far as I can see there still isn’t an equivalent V4 Main → Bluechip migration route.\nGiven the size of the position, manually repaying the debt, withdrawing collateral and rebuilding the position isn’t really practical, so an atomic/flash-loan migration would be extremely useful\nHas this functionality been released, is it currently being worked on, or is there an updated ETA?\nThanks!\n\n post by defi_milos on Sep 9\n\n defi_milos\n\n Hi Zataoka!\nI’m part of the DeFi Saver team, so just wanted to drop by and offer some suggestions, along with explanations on how the migration process works.\nOur Loan Shifter tool is indeed available for moving positions from one Aave v4 market to another, so it can definitely take care of migrating your position from the v4 Main to the v4 Bluechip Spoke.\nThe only limiting factor (currently) is if your v4 position is on an EOA and not a Smart Wallet. Currently, Loan Shifter only works for positions on a Smart Wallet - but we’ll soon make it compatible with EOA positions as well.\nSo, if your position is indeed on an EOA at the moment - you’ll be able to move it via Loan Shifter in about a week or so (when we release the Loan Shifter updates).\nAs a quick sidenote, here’s how Loan Shifter performs the move atomically:\n → It flash loans all of the required debt to clear your v4 Main position’s debt\n → It withdraws the collateral\n → It supplies that collateral to the v4 Bluechip market\n → Borrows the debt asset\n → Uses it to pay back the flash loan\nIn case your position is on a Smart Wallet, you should be able to perform the move by:\n\nAccessing Loan Shifter\nUnder “From Position”, click it and it should bring up all of your positions (including the v4 Main one)\nUnder “To Position”, type in “Bluechip”, and it’ll let you select the Aave v4 Bluechip market as the destination.\nClick “Shift”\n\nAnd that’s all the required steps to get your loan moved from one market to the other.\nWill write a follow-up comment here as soon as the EOA update is live, or you can drop by our Discord/Twitter to also get notified as soon as we announce it.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Hello Milos.. thank you so much for taking the time to give me that detailed answer, I truly appreciate it.\nI have always used Defisaver, btw. So, have great appreciation for the work your team does.\nMy 2 positions are both on Smart Wallets (at least, that’s what it says). It does not say EOA.\nHowever, I do NOT see the loan shifter there (only see collateral shift, debt shift and position flip). Not sure what I am doing wrong. Here is the ETH address for 1 of my positions. 0xd9bc3cbc14df4d9f2e94edafaa9b9ea68a42a014\nCan you please check this out and let me know why I am unable to see it?\n\n post by defi_milos on Sep 14\n\n defi_milos\n\n You’re very welcome Zataoka! Also appreciate your kind words for the DFS app :)\nGood news that your positions are on a Smart Wallet.\nLoan Shifter shows up under the “Shift” tab only on Aave v3 currently, but we’ll make sure it’s also included on the v4 dashboard soon!\nInstead, you can find the Loan Shifter option from the menu on the left-hand side of the app - just under the “Exchange” tool.\nOnce you’ve opened it, if it’s not already pre-selected, please choose your Main v4 position in the “From position” section. Then, you’ll choose “Bluechip” in the “To position” section.\nImportant note: The position you shared has multiple collateral and debt assets, so I would mention that Loan Shifter won’t be able to move it all in one transaction.\nInstead, it’ll require a couple. The best option I found is:\n\nTransaction 1: Move all of your WBTC and your USDT debt to the Bluechip market first. This is the best course of action since WBTC makes up most of your position, so it’ll let you move all of the USDT in one transaction. For example if you try to move your wstETH and USDT, there won’t be enough wstETH collateral to support moving all of the 300k+ USDT. By moving WBTC and USDT first, you’re taking care of that in one-tx\nTransaction 2: Move all of your wstETH and your USDC debt to the Bluechip market. Even though it’s two separate Loan Shifter transactions, it’ll actually add the wstETH collateral and USDC debt on top of your newly moved WBTC/USDT Bluechip position\nTransaction 3: Since all of your debt has moved to the Bluechip market now, you can simply withdraw your remaining LINK and ETH collateral, then supply it to the position again on Bluechip\n\nLet me know if this is clear enough. You can also contact me by writing directly through the DFS app, where I’d be more than happy to provide a step-by-step guide with screenshots on how to get the process done.\nP.S. - You can also do the entire move in our Simulation Mode first - confirm that everything works (and that you’re comfortable with the flow), and only then re-do it on the live mode.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Thanks Milos.. I was able to do the switch and it all went smoothly. Appreciate it.\nLet me ask you a couple of questions, if I may\n\nWhy is there such a huge difference in borrowing costs between USDT on the Core vs. Prime hub? I moved my debt to USDT on the core hub and the interest rate there is 10.6% vs. 4.05% (core vs. prime).\nBecause of the above, I am trying to do the debt switcher to Prime (from Core) but it doesn’t let me do that.\nI have retained some portion of the debt with all my LINK as collateral on V4 Main.. hope that is fine? Or should I be removing that you think, given LINK isn’t a collateral asset on Bluechip.\n\n post by defi_milos on Sep 21\n\n defi_milos\n\n You’re welcome Zataoka! Apologies for the slightly delayed reply here.\nLet me address the questions one by one:\n\nIt might have been due to a higher utilization rate on Core that caused the borrow APY spike. I can see now that both are pretty much at an equal ~4%\n\nWould love to learn a bit more about Debt Switch “not letting you do it”. Is there some kind of error that pops up, is the button to switch just greyed out?\n\nIs your LINK leveraged on v4 or is it just sitting there? From what I can see, you’re not going to be earning any supply APY on that LINK, so you’re technically just paying the borrowing costs on that LINK + USDC (I suppose) v4 Main position.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":2549,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262705208,"hash":"fdaf0333254b018a08f5dc6e0a47be79acdea15c"}
{"url":"https://forum.soliditylang.org/t/about-the-ama-ask-me-anything-category/145","domain":"forum.soliditylang.org","title":"About the AMA - Ask Me Anything category - AMA - Ask Me Anything - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n About the AMA - Ask Me Anything category \n\n AMA - Ask Me Anything\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by franzihei on Mar 2, 2021\n\n franzihei\n\n DO NOT OPEN TOPICS HERE / THIS IS NOT A SUPPORT CHANNEL\nThe Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics here. If not defined otherwise, you can ask any question about the Solidity compiler, language design, Yul, or, any other topic relevant to the Solidity language.\nWe may also invite people relevant to the Solidity ecosystem for special Solidity Experts AMAs in future.\nPlease read the AMA briefing & rules at the beginning of each new AMA, which you can find in the respective topic.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 108\n\n Oct 2025\n\n [Call for feedback] Core Solidity Deep Dive\n\n Uncategorized\n\n 5\n\n 613\n\n Dec 2025\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 180\n\n Dec 2025\n\n Request new syntax for Solidity\n\n Uncategorized\n\n 3\n\n 193\n\n Feb 17\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Want to read more? Browse other topics in AMA - Ask Me Anything or view latest topics.","tokens":1187,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262706113,"hash":"6d7da5448fdd674f6eb476e345791ea5d288eec9"}
{"url":"https://ethresear.ch/c/zk-s-nt-arks/13","domain":"ethresear.ch","title":"Latest zk-s[nt]arks topics - Ethereum Research","text":"Latest topics in zk-s[nt]arks\n\n zk-s[nt]arks\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the zk-s[nt]arks category\n\n For your posts on ZK-Snarks and ZK-Starks.\n\n 0\n\n 3.3k\n\n Dec 2017\n\n Atomic ZK-Proof-Gated Settlement for x402 Agent Payments: A Measured Reference Design\n\n 3\n\n 322\n\n 20d\n\n Proof boundaries in a minimal homomorphic tally for token weighted voting\n\n governance\n\n 0\n\n 78\n\n Aug 27\n\n Arcanum: a privacy-first compiler layer for source code — TEE now, ZK as the long-term foundation\n\n security\n\n 12\n\n 326\n\n Aug 10\n\n Qingming-STARK-G64: a Goldilocks STARK backend on AMD ROCm/HIP\n\n 0\n\n 66\n\n Jul 9\n\n Qingming-g64-ntt-cuda: RTX4090-24G results for native Goldilocks/G64 STARK-LDE NTT\n\n 2\n\n 80\n\n Jul 6\n\n Qingming-g64-ntt: Native Goldilocks/G64 GPU NTT at 2^27 on RX 7900 XTX, and a reproducible benchmark plan\n\n 0\n\n 81\n\n Jul 6\n\n What if post-quantum Ethereum doesn’t need signatures at all?\n\n post-quantum\n\n 17\n\n 1.2k\n\n Jul 2\n\n Designing Infrastructure Where Exploits Destroy Themselves\n\n governance\n\n 0\n\n 142\n\n Jul 2\n\n Blocks Are Dead. Long Live Blobs\n\n zk-roll-up\n\n 5\n\n 711\n\n Jun 29\n\n MACI and group bribe attacks\n\n governance\n\n 5\n\n 2.3k\n\n Jun 25\n\n EVM Verification of WHIR over a 31-bit Field\n\n post-quantum\n\n 0\n\n 307\n\n May 21\n\n WHIR for Ethereum\n\n 1\n\n 1.8k\n\n May 20\n\n Reducing the verification cost of a SNARK through hierarchical aggregation\n\n 12\n\n 10.0k\n\n Apr 29\n\n Folding over quartic extensions in 2N-4 multiplications, and why row-based commitment layers can’t keep up\n\n 0\n\n 85\n\n Apr 7\n\n Where to download the perpeptual power of tau for bn254?\n\n 0\n\n 41\n\n Mar 31\n\n Cheon’s attack and its effect on the security of big trusted setups\n\n 31\n\n 9.5k\n\n Mar 31\n\n Does Ethereum have a zk-verifiability problem?\n\n 7\n\n 728\n\n Mar 12\n\n When L = D + pQ Is Not Enough: Exactness Repair for BN254 Wrappers\n\n 0\n\n 92\n\n Mar 8\n\n GKRFold: SumFold-based GKR Proof Compression\n\n 2\n\n 608\n\n Feb 26\n\n Fake GLV: You don’t need an efficient endomorphism to implement GLV-like scalar multiplication in SNARK circuits\n\n 9\n\n 2.2k\n\n Nov 2025\n\n Generating Pasta keypairs\n\n 4\n\n 431\n\n Jul 2025\n\n The Signal: Ethereum - Casper FFG Finality Proofs\n\n 0\n\n 219\n\n Jul 2025\n\n Distributed Proof Generation\n\n 0\n\n 352\n\n Jul 2025\n\n Censorable Tornado Cash\n\n 7\n\n 904\n\n Jun 2025\n\n Vocdoni Protocol: Enabling Decentralized Voting for the Masses with ZK Technology\n\n zk-roll-up,governance\n\n 10\n\n 2.1k\n\n Jan 2025\n\n Zero-knowledge proofs of identity using electronic passports\n\n 23\n\n 8.6k\n\n Dec 2024\n\n Efficient ECDSA signature verification using Circom\n\n 9\n\n 7.6k\n\n Dec 2024\n\n Lookup singularity via MMR\n\n 8\n\n 3.6k\n\n Dec 2024\n\n Prover time comparison of GKR+Groth16 vs. Groth16 for proving MiMC hashes\n\n zk-roll-up\n\n 18\n\n 7.5k\n\n Dec 2024","tokens":691,"squid":"ink-research","role":"Deep Scholar","at":1791262710232,"hash":"a6cf1098fefdd3248017416c153e06e060411f67"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/6","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 6 / 10\n\n Sep 8\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n Zataoka\n\n Hi everyone,\nI currently have a fairly large leveraged position on Aave v4 Main Hub, with WBTC, wstETH, ETH and LINK as collateral.\nAfter comparing the risk parameters, I’ve noticed that Bluechip Hub offers significantly higher collateral factors / liquidation thresholds for the assets that make up most of my collateral (particularly WBTC and wstETH). I’d like to migrate my existing position from Main Hub to Bluechip Hub, but I couldn’t find any documentation describing the process.\nMy questions are:\n\nIs there currently a supported way to migrate an existing position from Main Hub to Bluechip Hub?\nIs there an atomic (flash-loan) migration path, or does it require manually repaying debt, withdrawing collateral, redepositing into Bluechip, and borrowing again?\nDoes Aave have any plans to support one-click migrations between hubs in the future?\nIf no migration path exists today, what is the safest recommended approach for moving a large leveraged position while minimizing liquidation and market-exposure risk?\n\nFor context, this is a six-figure borrowing position, so I’m trying to avoid any unnecessary execution risk during the migration. I would rather not manually unwind the position as I don’t intend selling collateral assets at this time.\nAny guidance from the Aave team or anyone who has done this would be greatly appreciated.\nThanks!\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n post by stani on Jul 4\n\n stani\n\n Aave Labs-Technical SP\n\n Currently there are no automated tools for migrating positions between Hubs and Spokes, however this feature is going to be build in few months.\nWhat you are looking to do is to migrate some of your position from Main Spoke (connected to Core Hub) to Bluechip Spoke (connected to Prime Spoke). Given you mentioned that you have LINK, that is only supported on Main Spoke as collateral, so you would need to split your position between two markets (the reason why Bluechip has better LTVs/ liquidator params is because it has less riskier collaterals).\nFor now I recommend to do the migration manually by repaying the loan, withdrawing collateral and resupplying into the Bluechip Spoke. You would still need to keep your LINK on Main Spoke if you want to borrow against it.\nHappy to take a deeper look if you drop a message to Customer Support (you can find it on the side menu).\n\n post by MconnectDAO on Jul 5\n\n MconnectDAO\n\n Aave v4’s hub‑and‑spoke architecture successfully achieves risk segregation, but the absence of cross‑hub migration tooling introduces UX‑driven risk for large retail and LP positions. Zataoka’s case is an early signal of this structural issue for the protocol and its governance roadmap.\ngovernance.\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n Zataoka\n\n Thank you for the detailed response Stani. I will write to your customer service (usually access Aave through defisaver.com but will get onto the aave platform.\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n Zataoka\n\n stani\n\n Hi Stani — just following up on this now that it’s been a little over two months since the original discussion.\nIs there any update on the timeline, particularly for migrating an existing leveraged position from Main Spoke to Bluechip Spoke? I did write to customer support earlier as well as you mentioned\nI’ve already used DeFi Saver’s Loan Shifter to migrate my positions from V3 to V4, but as far as I can see there still isn’t an equivalent V4 Main → Bluechip migration route.\nGiven the size of the position, manually repaying the debt, withdrawing collateral and rebuilding the position isn’t really practical, so an atomic/flash-loan migration would be extremely useful\nHas this functionality been released, is it currently being worked on, or is there an updated ETA?\nThanks!\n\n post by defi_milos on Sep 9\n\n defi_milos\n\n Hi Zataoka!\nI’m part of the DeFi Saver team, so just wanted to drop by and offer some suggestions, along with explanations on how the migration process works.\nOur Loan Shifter tool is indeed available for moving positions from one Aave v4 market to another, so it can definitely take care of migrating your position from the v4 Main to the v4 Bluechip Spoke.\nThe only limiting factor (currently) is if your v4 position is on an EOA and not a Smart Wallet. Currently, Loan Shifter only works for positions on a Smart Wallet - but we’ll soon make it compatible with EOA positions as well.\nSo, if your position is indeed on an EOA at the moment - you’ll be able to move it via Loan Shifter in about a week or so (when we release the Loan Shifter updates).\nAs a quick sidenote, here’s how Loan Shifter performs the move atomically:\n → It flash loans all of the required debt to clear your v4 Main position’s debt\n → It withdraws the collateral\n → It supplies that collateral to the v4 Bluechip market\n → Borrows the debt asset\n → Uses it to pay back the flash loan\nIn case your position is on a Smart Wallet, you should be able to perform the move by:\n\nAccessing Loan Shifter\nUnder “From Position”, click it and it should bring up all of your positions (including the v4 Main one)\nUnder “To Position”, type in “Bluechip”, and it’ll let you select the Aave v4 Bluechip market as the destination.\nClick “Shift”\n\nAnd that’s all the required steps to get your loan moved from one market to the other.\nWill write a follow-up comment here as soon as the EOA update is live, or you can drop by our Discord/Twitter to also get notified as soon as we announce it.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Hello Milos.. thank you so much for taking the time to give me that detailed answer, I truly appreciate it.\nI have always used Defisaver, btw. So, have great appreciation for the work your team does.\nMy 2 positions are both on Smart Wallets (at least, that’s what it says). It does not say EOA.\nHowever, I do NOT see the loan shifter there (only see collateral shift, debt shift and position flip). Not sure what I am doing wrong. Here is the ETH address for 1 of my positions. 0xd9bc3cbc14df4d9f2e94edafaa9b9ea68a42a014\nCan you please check this out and let me know why I am unable to see it?\n\n post by defi_milos on Sep 14\n\n defi_milos\n\n You’re very welcome Zataoka! Also appreciate your kind words for the DFS app :)\nGood news that your positions are on a Smart Wallet.\nLoan Shifter shows up under the “Shift” tab only on Aave v3 currently, but we’ll make sure it’s also included on the v4 dashboard soon!\nInstead, you can find the Loan Shifter option from the menu on the left-hand side of the app - just under the “Exchange” tool.\nOnce you’ve opened it, if it’s not already pre-selected, please choose your Main v4 position in the “From position” section. Then, you’ll choose “Bluechip” in the “To position” section.\nImportant note: The position you shared has multiple collateral and debt assets, so I would mention that Loan Shifter won’t be able to move it all in one transaction.\nInstead, it’ll require a couple. The best option I found is:\n\nTransaction 1: Move all of your WBTC and your USDT debt to the Bluechip market first. This is the best course of action since WBTC makes up most of your position, so it’ll let you move all of the USDT in one transaction. For example if you try to move your wstETH and USDT, there won’t be enough wstETH collateral to support moving all of the 300k+ USDT. By moving WBTC and USDT first, you’re taking care of that in one-tx\nTransaction 2: Move all of your wstETH and your USDC debt to the Bluechip market. Even though it’s two separate Loan Shifter transactions, it’ll actually add the wstETH collateral and USDC debt on top of your newly moved WBTC/USDT Bluechip position\nTransaction 3: Since all of your debt has moved to the Bluechip market now, you can simply withdraw your remaining LINK and ETH collateral, then supply it to the position again on Bluechip\n\nLet me know if this is clear enough. You can also contact me by writing directly through the DFS app, where I’d be more than happy to provide a step-by-step guide with screenshots on how to get the process done.\nP.S. - You can also do the entire move in our Simulation Mode first - confirm that everything works (and that you’re comfortable with the flow), and only then re-do it on the live mode.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Thanks Milos.. I was able to do the switch and it all went smoothly. Appreciate it.\nLet me ask you a couple of questions, if I may\n\nWhy is there such a huge difference in borrowing costs between USDT on the Core vs. Prime hub? I moved my debt to USDT on the core hub and the interest rate there is 10.6% vs. 4.05% (core vs. prime).\nBecause of the above, I am trying to do the debt switcher to Prime (from Core) but it doesn’t let me do that.\nI have retained some portion of the debt with all my LINK as collateral on V4 Main.. hope that is fine? Or should I be removing that you think, given LINK isn’t a collateral asset on Bluechip.\n\n post by defi_milos on Sep 21\n\n defi_milos\n\n You’re welcome Zataoka! Apologies for the slightly delayed reply here.\nLet me address the questions one by one:\n\nIt might have been due to a higher utilization rate on Core that caused the borrow APY spike. I can see now that both are pretty much at an equal ~4%\n\nWould love to learn a bit more about Debt Switch “not letting you do it”. Is there some kind of error that pops up, is the button to switch just greyed out?\n\nIs your LINK leveraged on v4 or is it just sitting there? From what I can see, you’re not going to be earning any supply APY on that LINK, so you’re technically just paying the borrowing costs on that LINK + USDC (I suppose) v4 Main position.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":2549,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262715782,"hash":"8232b2c8aa3086730d919c9e99e1bdaa117b425a"}
{"url":"http://forum.soliditylang.org/c/documentation/8","domain":"forum.soliditylang.org","title":"Latest Documentation topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Documentation\n\n Documentation\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n New communication channel about Solidity Docs Community Translations\n\n Hello everyone \nIn case you do not know - we just opened a new matrix channel for translators: https://app.element.io/#/room/#solidity-docs-translations:matrix.org \nCurrently, we are discussing Translation Bot for automa…\n\n read more\n\n 3\n\n 1.1k\n\n Mar 2025\n\n About the Documentation category\n\n Discussion about the documentation and its translations. \n Please do not use the forum to report issues (e.g. typos or broken links in the documentation). Please report issues directly via the Solidity Issue Tra…\n\n read more\n\n 0\n\n 581\n\n Feb 2021\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n 2\n\n 148\n\n Jun 2\n\n Localization of The Solidity Documentation\n\n 0\n\n 82\n\n Jun 2\n\n License and Attribution of the Solidity Logo?\n\n 5\n\n 245\n\n Oct 2025\n\n Lack of centralized documentation of known vulnerabilities\n\n 4\n\n 304\n\n Oct 2025\n\n The key `is` annot be located in the keyword index of solidity documentation\n\n 1\n\n 123\n\n Jul 2025\n\n Translations: Portuguese Coordination Thread\n\n 12\n\n 1.1k\n\n Sep 2024\n\n Precompiles should be in Docs\n\n 1\n\n 190\n\n Aug 2024\n\n Docs: storage layout for array of arrays\n\n 3\n\n 486\n\n Feb 2024\n\n Question about IR semantic changes\n\n 1\n\n 525\n\n Dec 2023\n\n Implicit hexadecimal literal to string conversion\n\n 2\n\n 893\n\n Sep 2023\n\n [Documentation] Conversion from payable to contract type\n\n 7\n\n 856\n\n Aug 2023\n\n How to know about minimum and maximum values of Types in the documentation\n\n 5\n\n 635\n\n Aug 2023\n\n Translation: Hebrew\n\n 4\n\n 454\n\n Aug 2023\n\n Understanding the “memory-safe” dialect\n\n 5\n\n 4.8k\n\n Jul 2023\n\n Type representation of literals\n\n 1\n\n 463\n\n Jun 2023\n\n I want to help translate to Russian/Ukrainian\n\n 4\n\n 646\n\n Apr 2023\n\n Wording about function types in documentation\n\n 2\n\n 486\n\n Mar 2023\n\n Storage object JSON interface\n\n 7\n\n 3.0k\n\n Jan 2023\n\n Documentation question about solidity state variable storage layout\n\n 3\n\n 790\n\n Oct 2022\n\n The mapping value storage location\n\n 0\n\n 674\n\n Aug 2022\n\n How do these mathematical symbols work? == and ++ vs = and +\n\n 1\n\n 656\n\n Aug 2022\n\n Introducing the Translations PR Bot! \n\n 4\n\n 761\n\n Jul 2022\n\n Translations: Turkish Coordination🇹🇷\n\n 8\n\n 696\n\n Jun 2022\n\n Uni Directional Payment\n\n 1\n\n 575\n\n Jun 2022\n\n Translations: Spanish Coordination \n\n 11\n\n 1.0k\n\n May 2022\n\n Translations: Polish Coordination \n\n 0\n\n 583\n\n May 2022\n\n Translations: How can I contribute? (ko)\n\n 5\n\n 824\n\n Apr 2022\n\n Should the Solidity docs give some guidance on naming conventions?\n\n 2\n\n 759\n\n Mar 2022","tokens":1519,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262716198,"hash":"4c120fe2313e3bcd2a73d6c0a3838918fcfb5357"}
{"url":"https://ethresear.ch/t/blocks-are-dead-long-live-blobs/24611/6","domain":"ethresear.ch","title":"Blocks Are Dead. Long Live Blobs - zk-s[nt]arks - Ethereum Research","text":"zk-s[nt]arks\n\n zk-roll-up\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Apr 7\n\n 6 / 6\n\n Jun 28\n\n Jun 29\n\n post by Nero_eth on Apr 7\n\n Nero_eth\n\n Blocks Are Dead. Long Live Blobs.\nThanks to Kev, Francesco, soispoke, Anders and Jihoon for feedback and review.\n\nTL;DR: Block in Blobs (BiB) takes transactions in RLP format, and encodes it as a blob (similar to type-3-txs). This is beneficial in a zkEVM world as not everyone will need to download every transaction anymore - reducing bandwidth requirements.\n\nWith zkEVM coming, validators will no longer need to execute transactions to verify blocks: a succinct proof will be enough. But this changes how data availability works.\nToday, DA is enforced implicitly: you can’t verify a block without downloading and executing its transactions. Under zkEVM, validators verify proofs, not transactions directly. A builder could publish a valid block and proof while withholding the underlying transaction data. The block would pass consensus, but no one could re-execute it, index it, or reliably build on top of it.\nBlock-in-Blobs (BiB) addresses this by encoding transaction data into blobs, making DA a consensus-level requirement. Validators can then sample rather than download: same guarantees, less bandwidth, more scale.\nIn the following, I want to walk through the design space and things that helped me wrap my head around it.\n\nbackground: blocks, payloads, and transactions\nTo understand BiB, we first need to untangle some terminology. Ethereum is split into two layers: the Consensus Layer (CL) and the Execution Layer (EL). This separation is intentional and powerful, but it introduces conceptual friction, especially around what exactly a block or payload is.\nblocks vs. execution payloads\nFrom the consensus layer’s point of view, the canonical object is the beacon block. A beacon block may include an ExecutionPayload, but it is not itself an execution block.\nThe ExecutionPayload is the object exchanged between CL and EL via the Engine API:\n\nDuring block building, the EL constructs an ExecutionPayload and hands it to the CL.\nDuring validation and attestation, the CL hands the payload back to the EL for execution.\n\nThe ExecutionPayload is not the EL’s native block format. Instead, it contains exactly the information the EL needs to reconstruct and validate an execution block internally.\nThe ExecutionPayload size grows with the block gas limit, but also depends on the calldata pricing and other factors. With increasing block gas limits, block sizes increase too, and so do bandwidth requirements. Fortunately, there’re two solution.\nFirst, following the example of Flashblocks, we could split the payload into constant-size pieces, enabling them to be processed independently - effectively hiding latency.\nSecond, we could think of ways that allow validators to not download all transaction while still having certainty about them being published - Block in Blobs (BiB). While this post described the first solution, I want to focus on the second one in the following.\nBiB proposes to encode blocks (potentially also the Block-level Access List (BAL)) into constant-size blobs. Similar to type-3-tx blobs, validators will then not need to download the full ExecutionPayload anymore but instead only the columns they have custody over. This unlocks scaling benefits because not every validator will need to download everything, reducing bandwidth requirements without weakening the security/availability guarantees.\nSo when people say “put blocks into blobs”, what they really mean is putting the CL’s execution payload into blobs… and even that isn’t the full truth.\nwhat BiB actually encodes\nDespite the name, BiB doesn’t put entire blocks, or even entire execution payloads, into blobs. In its simplest form, the protocol only needs to ensure transaction data availability.\nTransactions inside the ExecutionPayload are already in the right shape:\n\nEach transaction is already RLP-encoded bytes.\nThe payload contains a list of these bytes.\n\nBiB takes the serialized RLP-encoded transactions, chunkifys them and packs them into blobs.\nEverything else execution-related (EL header fields, execution output roots, etc.) would either move into the beacon block or come in a separate sidecar with a commitment in beacon block. BiB guarantees that the information needed for re-execution is available.\n\nBlock-level Access Lists (BALs) may share the same destiny as transaction. Since the users of BALs may be different from the users of transactions, it might make sense to put BALs into blobs too but separate from the transactions.\n\nhow transactions become blobs\nWith the “what” and “why” established, let’s look at the “how.” Blob encoding follows the EIP-4844 model:\n\nSerialize transaction bytes\n\nTake payload.transactions (each already RLP-encoded)\nCanonically encode the list (typically RLP of the list of tx-bytes)\n\nPack bytes into blobs\n\nSplit the byte stream into 31-byte chunks\nEach chunk becomes the first 31 bytes of a 32-byte field element\nThe first byte is set to 0x00 so the element stays under the BLS modulus\n4096 field elements form one blob\n\nCommit\n\nInterpret the blob as a polynomial\nCompute a KZG commitment\nThe beacon block references these commitments\n\nSidecar\n\nSimilar to type-3-tx sidecars, or the ExecutionPayloadEnvelope as of ePBS, the payload blob travels the network in a sidecar\nIn addition to the payload blob, each sidecar comes with an index, kzg proofs, the slot number and the beacon block root.\n\nCustody\n\nInitially, validators may store all payload blobs without leveraging DAS\nValidators can download the payload blobs (which is almost the equivalent to downloading the ExectutionPayloadEnvelope under ePBS) and locally construct the ExecutionPayload from it.\nAt a later stage, partial custody and DA sampling can be introduced, leveraging the newly introduced mechanism for scaling (not requiring everyone to download all transactions)\nThe same applies to erasure encoding and cell-level messaging\n\nThe key insight: under zkEVMs validators don’t need the transactions to verify commitments. They only need commitments for consensus, while DA sampling ensures the blob contents are available on the network.\nwhat the zkEVM proof must bind\nFor BiB to work for zk-attesters who don’t download all payload blobs, the proof must guarantee three things:\n\nExecution correctness\nThe state transition from pre_state to post_state is valid.\nCorrect transaction-to-blob encoding\nThe exact canonical transaction bytes were packed into the blobs.\nCommitment binding\nThe blob commitments referenced by the beacon block correspond to those payload blobs.\n\nTogether, these requirements transform data availability from “implicit via re-execution” into “explicit via blob commitments + DAS.”\nNote: BiB and zkEVMs/mandatory-proofs are orthogonal:\nBiB can be rolled out iteratively, starting with putting transactions (and potentially the BAL) into blobs without yet introducing mandatory zk-proofs for execution and blob-encoding. Furthermore, the partial data custody doesn’t need to be done right from the beginning. BiB, in its minimal form, simply takes the RLP encoded transactions, and encodes them into blobs. From the EL perspective nothing changes - upon receipt, the CL constructs the ExecutionPayload from the received blobs and builds the EL block from it - just like today. At this point, those blobs can already be used by zk-attesters consuming optional proofs, which are slated to be rolled out pre-mandatory proofs for a limited set of attesters.\nwhere the rest of the payload goes\nBiB doesn’t move the entire execution payload into blobs: only the transaction data.\nBuilding on top of ePBS, the beacon block carries the execution header (or commitments / metadata) while the payload is made available separately via blobs.\nBlobs carry the heavy bytes; bids carry the compact commitments.\nbib1551×480 63.3 KB\n\nThis design would complicate moving to slot auctions in the future. If we want to keep that option, we may still need ePBS’s ExecutionPayloadEnvelope alongside the sidecars or move EL requests into the payload blobs too.\n\nhow many blobs will payloads need?\nFinally, let’s ground this in concrete numbers. Today’s execution payloads at a 60M gas limit average ~150 KiB (=~1-2 payload blobs), with a maximum size of ~5.7 MiB (depending on EL data pricing).\nThe maximum number of payload blobs depends on both the gas limit and calldata pricing. Looking at recent blocks, a 60M gas limit occasionally produces 3-4 blob blocks:\nimage987×583 82.6 KB\nIn the worst case, assuming EIP-7976 (64 gas per byte for calldata-heavy transactions), we’d need ~7 blobs filled with calldata. With today’s calldata pricing (10/40 gas), that number jumps to 45 blobs, and generalizing it further, we get the following formula to determine the max blob count needed:\n\nN= \\left\\lceil \\frac{L}{c \\cdot B} \\right\\rceil\n𝑁=⌈𝐿𝑐⋅𝐵⌉\nwhere\nL𝐿 = block gas limit\nc𝑐 = calldata gas cost (gas/byte)\nB𝐵 = blob size (bytes)\nimage987×583 57.8 KB\n\nappendix - unified data gas\nBiB answers how to make transaction data available via blobs. But it surfaces a more fundamental question: how do we account for all this data?\nToday, Ethereum has two separate resource dimensions for data:\n\nExecution gas: used by calldata (4/16 gas per zero/non-zero byte, or 10/40 at the EIP-7623 floor)\nBlob gas: used by type-3 transaction blobs (131,072 blob gas per blob)\n\nThese dimensions have independent limits. The block gas limit caps execution gas; MAX_BLOB_GAS_PER_BLOCK caps blob gas. A block can max out both simultaneously.\nthe additive worst case\nUnder BiB, calldata becomes blobs. But type-3 transactions also carry blobs. Without changes to resource accounting, we face an additive worst case:\n\nN_{worst} = N_{calldata} + N_{type3} = \\left\\lceil \\frac{L}{c \\cdot B} \\right\\rceil + \\frac{\\text{MAX_BLOB_GAS}}{\\text{GAS_PER_BLOB}}\n'_' allowed only in math mode\nWith a 60M gas limit, EIP-7976 pricing (64 gas/byte), and 21 type-3 blobs:\n\nN_{worst} = 7 + 21 = 28 \\text{ blobs}\n𝑁𝑤𝑜𝑟𝑠𝑡=7+21=28 blobs\nWith today’s calldata pricing (10/40 gas), this equals 11 + 21 = 32 blobs, all non-compressible.\nunified data gas: one dimension for all DA\nThe elegant solution is to collapse data from calldata and blob data into a single data dimension. The core principle:\nAll data that needs to be made available should count against the same limit.\nThe fragmentation exists only at the EL, where we have:\n# Current: TWO separate checks\nassert tx.gas <= block_gas_limit - block.gas_used # execution gas\nassert tx.blob_gas <= MAX_BLOB_GAS - block.blob_gas_used # blob gas\n\nWith BiB, both transactions and type-3 blobs become the same thing: blobs, and the accounting should reflect this.\ndesign: unified data gas\nReplace the two-dimension model with a single data bytes dimension:\nBYTES_PER_BLOB = 131_072 # 128 KiB\nMAX_DATA_BYTES = max_blobs * BYTES_PER_BLOB # e.g., 28 blobs ≈ 3.5 MiB\n\ndef data_bytes(tx):\n # Full encoded tx goes into payload blob\n tx_bytes = len(rlp_encode(tx))\n\n # Type-3 blob sidecars add more DA\n if tx.blob_versioned_hashes:\n tx_bytes += len(tx.blob_versioned_hashes) * BYTES_PER_BLOB\n\n return tx_bytes\n\nNote: The full RLP-encoded transaction (signature, nonce, gas fields, and calldata) is packed into payload blobs. The tx envelope overhead (~100-200 bytes per tx) is real DA.\n\nBlock-level enforcement becomes a single check:\n# One unified check (replaces separate gas + blob_gas checks)\nif data_bytes(tx) > MAX_DATA_BYTES - block.data_bytes_used:\n invalid(\"data limit exceeded\")\n\nNo more additive worst case. A block can have 28 blobs worth of data, whether that’s 28 type-3 blobs, 28 blobs of encoded transactions, or any mix.\nseparating execution from DA\nCalldata currently pays execution gas that implicitly covers both computation and data availability. With unified data gas, we cleanly separate these concerns:\ndef intrinsic_cost(tx):\n # Execution gas: pure compute (no calldata costs!)\n exec_gas = TX_BASE_COST + access_list_cost + create_cost + auth_cost\n\n # Data bytes: full tx + blob sidecars\n data = len(rlp_encode(tx))\n if tx.blob_versioned_hashes:\n data += len(tx.blob_versioned_hashes) * BYTES_PER_BLOB\n\n return exec_gas, data\n\nNotice what’s missing: no calldata gas costs, no EIP-7623 floor.\nwhy the calldata floor becomes unnecessary\nEIP-7623 introduced a calldata floor to prevent large blocks from calldata that come with no execution, ensuring calldata-heavy transactions can’t underpay for the bandwidth burden they impose, while not consuming any other resource. But in a unified data fee market, this protection comes for free:\n\nConcern\nEIP-7623 Solution\nUnified Data Gas Solution\n\nSpam prevention\nFloor gas cost (10/40 per byte)\nData fee market (rising data_base_fee)\n\nPrice signal\nImplicit in execution gas\nExplicit data_base_fee per byte\n\nAdaptivity\nFixed floor\nDynamic (EIP-1559-style adjustments)\n\nIf someone tries to fill blocks with calldata, data_base_fee rises, just like base_fee_per_gas rises when blocks are full. The market handles spam prevention automatically.\nThe cleaner model:\n\nExecution gas = pure compute (TX_BASE_COST + access lists + auth + create + opcodes during execution)\nData bytes = all DA (full encoded transaction bytes + blob sidecar bytes)\n\nNo double-counting. No floor. One fee for compute, one fee for data.\neip-1559, but for data\nJust as blob gas has its own EIP-1559-style fee market, unified data bytes would too:\n# EIP-1559-style pricing for data (same mechanism as blob gas today)\ndata_base_fee = fake_exponential(MIN_DATA_PRICE, excess_data_bytes, UPDATE_FRACTION)\n\n# Excess tracking (same as blob gas)\nexcess = max(0, parent.excess_data_bytes + parent.data_bytes_used - TARGET_DATA_BYTES)\n\nA new transaction type introduces an explicit data fee cap, giving users finer-grained control over how much they are willing to pay for data:\n# New transaction type fields (similar to type-3 for blobs)\ntx.max_fee_per_data_byte # explicit data fee cap\ntx.blob_versioned_hashes # for blob sidecars\n\nThe full validation flow looks like the following:\ndef validate(tx, block):\n exec_gas, data = intrinsic_cost(tx)\n\n if has_explicit_data_fee(tx):\n # New tx type: explicit per-dimension caps\n max_cost = tx.gas * tx.max_fee_per_gas + data * tx.max_fee_per_data_byte\n assert tx.max_fee_per_data_byte >= data_base_fee\n else:\n # Legacy: single aggregate budget (EIP-7999 style)\n max_cost = get_max_fee(tx) # gas_price × gas_limit\n required = exec_gas * base_fee_per_gas + data * data_base_fee\n assert required <= max_cost\n\n assert exec_gas <= tx.gas\n assert data <= MAX_DATA_BYTES - block.data_bytes_used\n assert sender.balance >= max_cost + tx.value\n\nbackwards compatibility\nThe max_fee_per_data_byte field is introduced in a new transaction type. But existing transactions remain fully compatible via gas limit partitioning (see EIP-7999 for details):\ndef partition_gas_limit(tx):\n if has_explicit_data_fee(tx): # new tx type\n return tx.gas, data_bytes(tx)\n else: # legacy types\n calldata_tokens = zero_bytes + 4 * non_zero_bytes\n execution_gas = tx.gas - STANDARD_TOKEN_COST * calldata_tokens\n return execution_gas, data_bytes(tx)\n\nThe key insight: legacy transactions’ gas_price × gas_limit already provides a total budget. This budget now covers both execution gas and data gas: the calldata cost simply moves from one dimension to another. No extra funds required.\nheader changes\nThe block header tracks data usage instead of blob gas:\n# Replace these fields:\nblob_gas_used → data_bytes_used # total DA in this block\nexcess_blob_gas → excess_data_bytes # for EIP-1559 pricing\n\nA first draft of the Unified Data Gas specification is available here.\n\ntwo orthogonal proposals\nHere’s the key insight: BiB and Unified Data Gas solve different problems.\n\nBiB\nUnified Data Gas\n\nProblem solved\nHow to make calldata DA-sampleable\nHow to bound total DA requirements\n\nMechanism\nEncoding (transactions → blobs)\nAccounting (one limit for all data)\n\nLayer affected\nCL (blob sidecars, commitments)\nEL (gas metering, intrinsic costs)\n\nCan exist alone?\nYes\nYes\n\nBiB without unified data gas still works: you just accept the additive worst case or introduce ad-hoc limits. This isn’t different to how the protocol works today.\nUnified data gas without BiB also works: it bounds total data but doesn’t enable DAS for transactions.\nTogether, they’re synergistic: BiB provides the encoding, unified data gas provides the accounting.\n\n A native zkEVM scales bandwidth, not just execution\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by junbyjun1238 on Apr 7\n\n junbyjun1238\n\n I found the object-by-object reasoning very helpful. What I’m especially curious about is whether there’s a more general placement principle behind it, since the local rationales seem to pull in different directions: e.g., BALs are execution-derived yet still need explicit availability, withdrawals are CL-derived, requests are reconstructible but consensus-relevant, and some values like slot-related metadata get pushed into the header partly for proving ergonomics.\nIs there a deeper rule you have in mind for what should live in blobs vs the bid/header vs what should simply remain reconstructible, or do you expect this to stay a case-by-case judgment as the zk-attester architecture matures?\n\n post by Nero_eth on Apr 8\n\n Nero_eth\n\n Yeah, good question, I’ve asked myself the same.\nIt’s not fully clear to me yet, but I think we need to be careful not to over-couple things too early.\nIn particular, I’m not convinced we should commingle BALs with transactions at the encoding layer. BALs serve a different purpose than the data: they’re useful for nodes that want to maintain state (e.g. RPCs, inclusion list builders, or zk-attesters that track mempool/state dynamics). This suggests different consumers and potentially different access patterns.\nFor zk-attesters specifically, I can see multiple modes emerging:\n\nsome might just DAS everything and not care about structure,\nothers might only want the “pure data” (=txs bytes),\nothers might want the BAL with its state diff to maintain (a partial) state.\n\nGiven that, a one-size-fits-all encoding feels premature. It might make more sense to reason case-by-case about which roles we actually want in the protocol (validators, zk-attesters of different kinds, builders, RPCs, etc.), and then design it to cleanly support those, rather than forcing everything into a single blob layout upfront.\n\n post by junbyjun1238 on Apr 8\n\n junbyjun1238\n\n Forcing a one-size-fits-all encoding does feel premature at this stage. The missing abstraction might actually be relatively straightforward: same availability substrate, different public objects. Tx bytes, BALs, and other data could share the same DA guarantees without necessarily being collapsed onto a single encoding surface.\nThe separation itself isn’t the problem — the question is what governs which objects land where. The risk with a purely case-by-case placement rule is that it tends to optimize for whoever is easiest to satisfy first. Which is why I think there’s value in anchoring around a stronger invariant: any object whose withholding would materially narrow the set of parties able to independently reconstruct and continue the chain should remain explicitly available — even after consensus no longer requires it directly. Otherwise, you end up with something efficiently attestable but increasingly opaque as public infrastructure.\n\n post by bbjubjub2494 on Apr 8\n\n bbjubjub2494\n\n Neat research direction!\nIs it correct that if unified data gas is in place, there’s no longer any economic interest in issuing type-3 transactions as opposed to type-5? The pricing seems to be the same, or maybe a bit worse given BYTES_PER_BLOB.\n\nIn this case, we wouldn’t fold blob gas into data gas since data gas isn’t DAS’d, right?\n\n 3 months later\n\n post by thegaram33 on Jun 29\n\n thegaram33\n\n I’ve been building a prototype of Block-in-Blobs (EIP-8142) on ethrex and Lighthouse. We now have a local Kurtosis devnet running BiB end-to-end, plus integration into the EIP-8025 guest program.\nMain learnings so far:\n\nMoving KZG (or whatever pq-DA scheme replaces it) onto the Engine API adds latency, a potential liveness risk.\nBiB includes the BAL which cannot be serialized incrementally (it’s only fully known once the block is built). This complicates payload building and blob-count accounting.\nHow payload blobs should interact with the blob fee market is still an open research question.\n\nFull writeup: EIP-8142: Block-in-Blobs (BiB) — prototype writeup - HackMD — I’d love any questions or feedback, here or on HackMD.\n\n Powered by Discourse","tokens":5171,"squid":"ink-research","role":"Deep Scholar","at":1791262720564,"hash":"07af23155d5a5cf19299199bf54d2c066b602f99"}
{"url":"http://forum.soliditylang.org/c/announcements/5","domain":"forum.soliditylang.org","title":"Latest Announcements topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Announcements\n\n Announcements\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Announcements category\n\n Low-traffic category for important announcements about the Solidity language and compiler. \n:postbox:Subscribe to this category if you want to be kept in the loop about releases and Solidity-relevant feedback surveys, ne…\n\n read more\n\n 0\n\n 613\n\n Dec 2020\n\n Read this before posting! \n\n Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter …\n\n read more\n\n 0\n\n 4.4k\n\n Dec 2020\n\n Solidity 0.8.37 is released!\n\n 0\n\n 54\n\n 26d\n\n Pattern Matching Blog Post Released\n\n 0\n\n 78\n\n May 5\n\n Solidity v0.8.35 is out!\n\n 0\n\n 101\n\n Apr 29\n\n The Annual Solidity Survey is live!\n\n 2\n\n 121\n\n Apr 27\n\n Solidity Developer Survey 2025 Results\n\n 2\n\n 146\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n 1\n\n 143\n\n Apr 24\n\n Solidity v0.8.33 is out! \n\n 0\n\n 180\n\n Dec 2025\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n 0\n\n 123\n\n Dec 2025\n\n Solidity v0.8.31 is out! \n\n 0\n\n 136\n\n Dec 2025\n\n Forum under maintenance on July 11, 2025\n\n 0\n\n 94\n\n Jul 2025\n\n Solidity v0.8.30 just landed!\n\n 0\n\n 205\n\n May 2025\n\n We are thrilled to release Solidity v0.8.29!\n\n 1\n\n 228\n\n Apr 2025\n\n The Case for EOF\n\n 0\n\n 141\n\n Mar 2025\n\n The Solidity Survey 2024 is live!\n\n 0\n\n 168\n\n Dec 2024\n\n Solidity 0.8.24 is out! \n\n 5\n\n 1.1k\n\n Dec 2024\n\n Solidity v0.8.28 is out! \n\n 1\n\n 296\n\n Dec 2024\n\n Solidity 0.8.27 is out! \n\n 0\n\n 243\n\n Oct 2024\n\n The Underhanded Solidity Contest 2024 is open for submissions! 🕵️\n\n 0\n\n 154\n\n Jul 2024\n\n The Solidity Developer Survey Results 2023 are out! \n\n 1\n\n 458\n\n Jul 2024\n\n Solidity v0.8.25 is out! \n\n 3\n\n 928\n\n Mar 2024\n\n Solidity Survey 2023\n\n 3\n\n 511\n\n Dec 2023\n\n We just released Solidity v0.8.23!\n\n 0\n\n 477\n\n Nov 2023\n\n Solidity v0.8.22 is out!\n\n 0\n\n 512\n\n Oct 2023\n\n Solidity v0.8.21 was just released!\n\n 0\n\n 549\n\n Jul 2023\n\n Solidity v0.8.20 was just released!\n\n 0\n\n 684\n\n May 2023\n\n Solidity v0.8.19 was just released!\n\n 0\n\n 551\n\n Feb 2023\n\n Solidity v0.8.18 was just released!\n\n 0\n\n 586\n\n Feb 2023\n\n Solidity Core Team Updates + Solidity Developer Survey 2022\n\n 0\n\n 527\n\n Dec 2022","tokens":1418,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262727799,"hash":"f1a519bf8be3046680eb46b46bd46b734175767a"}
{"url":"https://ethresear.ch/t/blocks-are-dead-long-live-blobs/24611/1","domain":"ethresear.ch","title":"Blocks Are Dead. Long Live Blobs - zk-s[nt]arks - Ethereum Research","text":"Blocks Are Dead. Long Live Blobs \n\n zk-s[nt]arks\n\n zk-roll-up\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Apr 7\n\n 1 / 6\n\n Apr 6\n\n Jun 29\n\n post by Nero_eth on Apr 7\n\n Nero_eth\n\n Blocks Are Dead. Long Live Blobs.\nThanks to Kev, Francesco, soispoke, Anders and Jihoon for feedback and review.\n\nTL;DR: Block in Blobs (BiB) takes transactions in RLP format, and encodes it as a blob (similar to type-3-txs). This is beneficial in a zkEVM world as not everyone will need to download every transaction anymore - reducing bandwidth requirements.\n\nWith zkEVM coming, validators will no longer need to execute transactions to verify blocks: a succinct proof will be enough. But this changes how data availability works.\nToday, DA is enforced implicitly: you can’t verify a block without downloading and executing its transactions. Under zkEVM, validators verify proofs, not transactions directly. A builder could publish a valid block and proof while withholding the underlying transaction data. The block would pass consensus, but no one could re-execute it, index it, or reliably build on top of it.\nBlock-in-Blobs (BiB) addresses this by encoding transaction data into blobs, making DA a consensus-level requirement. Validators can then sample rather than download: same guarantees, less bandwidth, more scale.\nIn the following, I want to walk through the design space and things that helped me wrap my head around it.\n\nbackground: blocks, payloads, and transactions\nTo understand BiB, we first need to untangle some terminology. Ethereum is split into two layers: the Consensus Layer (CL) and the Execution Layer (EL). This separation is intentional and powerful, but it introduces conceptual friction, especially around what exactly a block or payload is.\nblocks vs. execution payloads\nFrom the consensus layer’s point of view, the canonical object is the beacon block. A beacon block may include an ExecutionPayload, but it is not itself an execution block.\nThe ExecutionPayload is the object exchanged between CL and EL via the Engine API:\n\nDuring block building, the EL constructs an ExecutionPayload and hands it to the CL.\nDuring validation and attestation, the CL hands the payload back to the EL for execution.\n\nThe ExecutionPayload is not the EL’s native block format. Instead, it contains exactly the information the EL needs to reconstruct and validate an execution block internally.\nThe ExecutionPayload size grows with the block gas limit, but also depends on the calldata pricing and other factors. With increasing block gas limits, block sizes increase too, and so do bandwidth requirements. Fortunately, there’re two solution.\nFirst, following the example of Flashblocks, we could split the payload into constant-size pieces, enabling them to be processed independently - effectively hiding latency.\nSecond, we could think of ways that allow validators to not download all transaction while still having certainty about them being published - Block in Blobs (BiB). While this post described the first solution, I want to focus on the second one in the following.\nBiB proposes to encode blocks (potentially also the Block-level Access List (BAL)) into constant-size blobs. Similar to type-3-tx blobs, validators will then not need to download the full ExecutionPayload anymore but instead only the columns they have custody over. This unlocks scaling benefits because not every validator will need to download everything, reducing bandwidth requirements without weakening the security/availability guarantees.\nSo when people say “put blocks into blobs”, what they really mean is putting the CL’s execution payload into blobs… and even that isn’t the full truth.\nwhat BiB actually encodes\nDespite the name, BiB doesn’t put entire blocks, or even entire execution payloads, into blobs. In its simplest form, the protocol only needs to ensure transaction data availability.\nTransactions inside the ExecutionPayload are already in the right shape:\n\nEach transaction is already RLP-encoded bytes.\nThe payload contains a list of these bytes.\n\nBiB takes the serialized RLP-encoded transactions, chunkifys them and packs them into blobs.\nEverything else execution-related (EL header fields, execution output roots, etc.) would either move into the beacon block or come in a separate sidecar with a commitment in beacon block. BiB guarantees that the information needed for re-execution is available.\n\nBlock-level Access Lists (BALs) may share the same destiny as transaction. Since the users of BALs may be different from the users of transactions, it might make sense to put BALs into blobs too but separate from the transactions.\n\nhow transactions become blobs\nWith the “what” and “why” established, let’s look at the “how.” Blob encoding follows the EIP-4844 model:\n\nSerialize transaction bytes\n\nTake payload.transactions (each already RLP-encoded)\nCanonically encode the list (typically RLP of the list of tx-bytes)\n\nPack bytes into blobs\n\nSplit the byte stream into 31-byte chunks\nEach chunk becomes the first 31 bytes of a 32-byte field element\nThe first byte is set to 0x00 so the element stays under the BLS modulus\n4096 field elements form one blob\n\nCommit\n\nInterpret the blob as a polynomial\nCompute a KZG commitment\nThe beacon block references these commitments\n\nSidecar\n\nSimilar to type-3-tx sidecars, or the ExecutionPayloadEnvelope as of ePBS, the payload blob travels the network in a sidecar\nIn addition to the payload blob, each sidecar comes with an index, kzg proofs, the slot number and the beacon block root.\n\nCustody\n\nInitially, validators may store all payload blobs without leveraging DAS\nValidators can download the payload blobs (which is almost the equivalent to downloading the ExectutionPayloadEnvelope under ePBS) and locally construct the ExecutionPayload from it.\nAt a later stage, partial custody and DA sampling can be introduced, leveraging the newly introduced mechanism for scaling (not requiring everyone to download all transactions)\nThe same applies to erasure encoding and cell-level messaging\n\nThe key insight: under zkEVMs validators don’t need the transactions to verify commitments. They only need commitments for consensus, while DA sampling ensures the blob contents are available on the network.\nwhat the zkEVM proof must bind\nFor BiB to work for zk-attesters who don’t download all payload blobs, the proof must guarantee three things:\n\nExecution correctness\nThe state transition from pre_state to post_state is valid.\nCorrect transaction-to-blob encoding\nThe exact canonical transaction bytes were packed into the blobs.\nCommitment binding\nThe blob commitments referenced by the beacon block correspond to those payload blobs.\n\nTogether, these requirements transform data availability from “implicit via re-execution” into “explicit via blob commitments + DAS.”\nNote: BiB and zkEVMs/mandatory-proofs are orthogonal:\nBiB can be rolled out iteratively, starting with putting transactions (and potentially the BAL) into blobs without yet introducing mandatory zk-proofs for execution and blob-encoding. Furthermore, the partial data custody doesn’t need to be done right from the beginning. BiB, in its minimal form, simply takes the RLP encoded transactions, and encodes them into blobs. From the EL perspective nothing changes - upon receipt, the CL constructs the ExecutionPayload from the received blobs and builds the EL block from it - just like today. At this point, those blobs can already be used by zk-attesters consuming optional proofs, which are slated to be rolled out pre-mandatory proofs for a limited set of attesters.\nwhere the rest of the payload goes\nBiB doesn’t move the entire execution payload into blobs: only the transaction data.\nBuilding on top of ePBS, the beacon block carries the execution header (or commitments / metadata) while the payload is made available separately via blobs.\nBlobs carry the heavy bytes; bids carry the compact commitments.\nbib1551×480 63.3 KB\n\nThis design would complicate moving to slot auctions in the future. If we want to keep that option, we may still need ePBS’s ExecutionPayloadEnvelope alongside the sidecars or move EL requests into the payload blobs too.\n\nhow many blobs will payloads need?\nFinally, let’s ground this in concrete numbers. Today’s execution payloads at a 60M gas limit average ~150 KiB (=~1-2 payload blobs), with a maximum size of ~5.7 MiB (depending on EL data pricing).\nThe maximum number of payload blobs depends on both the gas limit and calldata pricing. Looking at recent blocks, a 60M gas limit occasionally produces 3-4 blob blocks:\nimage987×583 82.6 KB\nIn the worst case, assuming EIP-7976 (64 gas per byte for calldata-heavy transactions), we’d need ~7 blobs filled with calldata. With today’s calldata pricing (10/40 gas), that number jumps to 45 blobs, and generalizing it further, we get the following formula to determine the max blob count needed:\n\nN= \\left\\lceil \\frac{L}{c \\cdot B} \\right\\rceil\n𝑁=⌈𝐿𝑐⋅𝐵⌉\nwhere\nL𝐿 = block gas limit\nc𝑐 = calldata gas cost (gas/byte)\nB𝐵 = blob size (bytes)\nimage987×583 57.8 KB\n\nappendix - unified data gas\nBiB answers how to make transaction data available via blobs. But it surfaces a more fundamental question: how do we account for all this data?\nToday, Ethereum has two separate resource dimensions for data:\n\nExecution gas: used by calldata (4/16 gas per zero/non-zero byte, or 10/40 at the EIP-7623 floor)\nBlob gas: used by type-3 transaction blobs (131,072 blob gas per blob)\n\nThese dimensions have independent limits. The block gas limit caps execution gas; MAX_BLOB_GAS_PER_BLOCK caps blob gas. A block can max out both simultaneously.\nthe additive worst case\nUnder BiB, calldata becomes blobs. But type-3 transactions also carry blobs. Without changes to resource accounting, we face an additive worst case:\n\nN_{worst} = N_{calldata} + N_{type3} = \\left\\lceil \\frac{L}{c \\cdot B} \\right\\rceil + \\frac{\\text{MAX_BLOB_GAS}}{\\text{GAS_PER_BLOB}}\n'_' allowed only in math mode\nWith a 60M gas limit, EIP-7976 pricing (64 gas/byte), and 21 type-3 blobs:\n\nN_{worst} = 7 + 21 = 28 \\text{ blobs}\n𝑁𝑤𝑜𝑟𝑠𝑡=7+21=28 blobs\nWith today’s calldata pricing (10/40 gas), this equals 11 + 21 = 32 blobs, all non-compressible.\nunified data gas: one dimension for all DA\nThe elegant solution is to collapse data from calldata and blob data into a single data dimension. The core principle:\nAll data that needs to be made available should count against the same limit.\nThe fragmentation exists only at the EL, where we have:\n# Current: TWO separate checks\nassert tx.gas <= block_gas_limit - block.gas_used # execution gas\nassert tx.blob_gas <= MAX_BLOB_GAS - block.blob_gas_used # blob gas\n\nWith BiB, both transactions and type-3 blobs become the same thing: blobs, and the accounting should reflect this.\ndesign: unified data gas\nReplace the two-dimension model with a single data bytes dimension:\nBYTES_PER_BLOB = 131_072 # 128 KiB\nMAX_DATA_BYTES = max_blobs * BYTES_PER_BLOB # e.g., 28 blobs ≈ 3.5 MiB\n\ndef data_bytes(tx):\n # Full encoded tx goes into payload blob\n tx_bytes = len(rlp_encode(tx))\n\n # Type-3 blob sidecars add more DA\n if tx.blob_versioned_hashes:\n tx_bytes += len(tx.blob_versioned_hashes) * BYTES_PER_BLOB\n\n return tx_bytes\n\nNote: The full RLP-encoded transaction (signature, nonce, gas fields, and calldata) is packed into payload blobs. The tx envelope overhead (~100-200 bytes per tx) is real DA.\n\nBlock-level enforcement becomes a single check:\n# One unified check (replaces separate gas + blob_gas checks)\nif data_bytes(tx) > MAX_DATA_BYTES - block.data_bytes_used:\n invalid(\"data limit exceeded\")\n\nNo more additive worst case. A block can have 28 blobs worth of data, whether that’s 28 type-3 blobs, 28 blobs of encoded transactions, or any mix.\nseparating execution from DA\nCalldata currently pays execution gas that implicitly covers both computation and data availability. With unified data gas, we cleanly separate these concerns:\ndef intrinsic_cost(tx):\n # Execution gas: pure compute (no calldata costs!)\n exec_gas = TX_BASE_COST + access_list_cost + create_cost + auth_cost\n\n # Data bytes: full tx + blob sidecars\n data = len(rlp_encode(tx))\n if tx.blob_versioned_hashes:\n data += len(tx.blob_versioned_hashes) * BYTES_PER_BLOB\n\n return exec_gas, data\n\nNotice what’s missing: no calldata gas costs, no EIP-7623 floor.\nwhy the calldata floor becomes unnecessary\nEIP-7623 introduced a calldata floor to prevent large blocks from calldata that come with no execution, ensuring calldata-heavy transactions can’t underpay for the bandwidth burden they impose, while not consuming any other resource. But in a unified data fee market, this protection comes for free:\n\nConcern\nEIP-7623 Solution\nUnified Data Gas Solution\n\nSpam prevention\nFloor gas cost (10/40 per byte)\nData fee market (rising data_base_fee)\n\nPrice signal\nImplicit in execution gas\nExplicit data_base_fee per byte\n\nAdaptivity\nFixed floor\nDynamic (EIP-1559-style adjustments)\n\nIf someone tries to fill blocks with calldata, data_base_fee rises, just like base_fee_per_gas rises when blocks are full. The market handles spam prevention automatically.\nThe cleaner model:\n\nExecution gas = pure compute (TX_BASE_COST + access lists + auth + create + opcodes during execution)\nData bytes = all DA (full encoded transaction bytes + blob sidecar bytes)\n\nNo double-counting. No floor. One fee for compute, one fee for data.\neip-1559, but for data\nJust as blob gas has its own EIP-1559-style fee market, unified data bytes would too:\n# EIP-1559-style pricing for data (same mechanism as blob gas today)\ndata_base_fee = fake_exponential(MIN_DATA_PRICE, excess_data_bytes, UPDATE_FRACTION)\n\n# Excess tracking (same as blob gas)\nexcess = max(0, parent.excess_data_bytes + parent.data_bytes_used - TARGET_DATA_BYTES)\n\nA new transaction type introduces an explicit data fee cap, giving users finer-grained control over how much they are willing to pay for data:\n# New transaction type fields (similar to type-3 for blobs)\ntx.max_fee_per_data_byte # explicit data fee cap\ntx.blob_versioned_hashes # for blob sidecars\n\nThe full validation flow looks like the following:\ndef validate(tx, block):\n exec_gas, data = intrinsic_cost(tx)\n\n if has_explicit_data_fee(tx):\n # New tx type: explicit per-dimension caps\n max_cost = tx.gas * tx.max_fee_per_gas + data * tx.max_fee_per_data_byte\n assert tx.max_fee_per_data_byte >= data_base_fee\n else:\n # Legacy: single aggregate budget (EIP-7999 style)\n max_cost = get_max_fee(tx) # gas_price × gas_limit\n required = exec_gas * base_fee_per_gas + data * data_base_fee\n assert required <= max_cost\n\n assert exec_gas <= tx.gas\n assert data <= MAX_DATA_BYTES - block.data_bytes_used\n assert sender.balance >= max_cost + tx.value\n\nbackwards compatibility\nThe max_fee_per_data_byte field is introduced in a new transaction type. But existing transactions remain fully compatible via gas limit partitioning (see EIP-7999 for details):\ndef partition_gas_limit(tx):\n if has_explicit_data_fee(tx): # new tx type\n return tx.gas, data_bytes(tx)\n else: # legacy types\n calldata_tokens = zero_bytes + 4 * non_zero_bytes\n execution_gas = tx.gas - STANDARD_TOKEN_COST * calldata_tokens\n return execution_gas, data_bytes(tx)\n\nThe key insight: legacy transactions’ gas_price × gas_limit already provides a total budget. This budget now covers both execution gas and data gas: the calldata cost simply moves from one dimension to another. No extra funds required.\nheader changes\nThe block header tracks data usage instead of blob gas:\n# Replace these fields:\nblob_gas_used → data_bytes_used # total DA in this block\nexcess_blob_gas → excess_data_bytes # for EIP-1559 pricing\n\nA first draft of the Unified Data Gas specification is available here.\n\ntwo orthogonal proposals\nHere’s the key insight: BiB and Unified Data Gas solve different problems.\n\nBiB\nUnified Data Gas\n\nProblem solved\nHow to make calldata DA-sampleable\nHow to bound total DA requirements\n\nMechanism\nEncoding (transactions → blobs)\nAccounting (one limit for all data)\n\nLayer affected\nCL (blob sidecars, commitments)\nEL (gas metering, intrinsic costs)\n\nCan exist alone?\nYes\nYes\n\nBiB without unified data gas still works: you just accept the additive worst case or introduce ad-hoc limits. This isn’t different to how the protocol works today.\nUnified data gas without BiB also works: it bounds total data but doesn’t enable DAS for transactions.\nTogether, they’re synergistic: BiB provides the encoding, unified data gas provides the accounting.\n\n A native zkEVM scales bandwidth, not just execution\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by junbyjun1238 on Apr 7\n\n junbyjun1238\n\n I found the object-by-object reasoning very helpful. What I’m especially curious about is whether there’s a more general placement principle behind it, since the local rationales seem to pull in different directions: e.g., BALs are execution-derived yet still need explicit availability, withdrawals are CL-derived, requests are reconstructible but consensus-relevant, and some values like slot-related metadata get pushed into the header partly for proving ergonomics.\nIs there a deeper rule you have in mind for what should live in blobs vs the bid/header vs what should simply remain reconstructible, or do you expect this to stay a case-by-case judgment as the zk-attester architecture matures?\n\n post by Nero_eth on Apr 8\n\n Nero_eth\n\n Yeah, good question, I’ve asked myself the same.\nIt’s not fully clear to me yet, but I think we need to be careful not to over-couple things too early.\nIn particular, I’m not convinced we should commingle BALs with transactions at the encoding layer. BALs serve a different purpose than the data: they’re useful for nodes that want to maintain state (e.g. RPCs, inclusion list builders, or zk-attesters that track mempool/state dynamics). This suggests different consumers and potentially different access patterns.\nFor zk-attesters specifically, I can see multiple modes emerging:\n\nsome might just DAS everything and not care about structure,\nothers might only want the “pure data” (=txs bytes),\nothers might want the BAL with its state diff to maintain (a partial) state.\n\nGiven that, a one-size-fits-all encoding feels premature. It might make more sense to reason case-by-case about which roles we actually want in the protocol (validators, zk-attesters of different kinds, builders, RPCs, etc.), and then design it to cleanly support those, rather than forcing everything into a single blob layout upfront.\n\n post by junbyjun1238 on Apr 8\n\n junbyjun1238\n\n Forcing a one-size-fits-all encoding does feel premature at this stage. The missing abstraction might actually be relatively straightforward: same availability substrate, different public objects. Tx bytes, BALs, and other data could share the same DA guarantees without necessarily being collapsed onto a single encoding surface.\nThe separation itself isn’t the problem — the question is what governs which objects land where. The risk with a purely case-by-case placement rule is that it tends to optimize for whoever is easiest to satisfy first. Which is why I think there’s value in anchoring around a stronger invariant: any object whose withholding would materially narrow the set of parties able to independently reconstruct and continue the chain should remain explicitly available — even after consensus no longer requires it directly. Otherwise, you end up with something efficiently attestable but increasingly opaque as public infrastructure.\n\n post by bbjubjub2494 on Apr 8\n\n bbjubjub2494\n\n Neat research direction!\nIs it correct that if unified data gas is in place, there’s no longer any economic interest in issuing type-3 transactions as opposed to type-5? The pricing seems to be the same, or maybe a bit worse given BYTES_PER_BLOB.\n\nIn this case, we wouldn’t fold blob gas into data gas since data gas isn’t DAS’d, right?\n\n 3 months later\n\n post by thegaram33 on Jun 29\n\n thegaram33\n\n I’ve been building a prototype of Block-in-Blobs (EIP-8142) on ethrex and Lighthouse. We now have a local Kurtosis devnet running BiB end-to-end, plus integration into the EIP-8025 guest program.\nMain learnings so far:\n\nMoving KZG (or whatever pq-DA scheme replaces it) onto the Engine API adds latency, a potential liveness risk.\nBiB includes the BAL which cannot be serialized incrementally (it’s only fully known once the block is built). This complicates payload building and blob-count accounting.\nHow payload blobs should interact with the blob fee market is still an open research question.\n\nFull writeup: EIP-8142: Block-in-Blobs (BiB) — prototype writeup - HackMD — I’d love any questions or feedback, here or on HackMD.\n\n Powered by Discourse","tokens":5179,"squid":"ink-research","role":"Deep Scholar","at":1791262731510,"hash":"3e33be9e45b5febfd614a14d28c79f5e869fdb9c"}
{"url":"https://forum.soliditylang.org/t/solidity-0-8-37-is-released/3753","domain":"forum.soliditylang.org","title":"Solidity 0.8.37 is released! - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solidity 0.8.37 is released! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 10\n\n 1 / 1\n\n Sep 9\n\n 26d ago\n\n post by czepluch on Sep 10\n\n czepluch\n\n Solidity Team\n\n Solidity 0.8.37 is released.\nThis is primarily a bugfix release.\nImportant bugfixes:\n\nLow/medium severity: delete b[i] on a bytes array in memory cleared 32 bytes instead of one on the evmasm pipeline, corrupting up to 31 bytes after the element. All versions up to and including 0.8.36 are affected. The IR pipeline is not affected, and b[i] = 0 clears exactly one byte on both pipelines. Write-up: Memory Byte Array Element Delete Clears Whole Word Bug | Solidity Programming Language\nLow/medium severity: With --via-ir, in certain call graph configurations containing mutual recursion, the stack-to-memory mover could assign the same spill slot to variables of two different functions, silently overwriting one of them. Versions 0.7.2 through 0.8.36 are affected. This is distinct from the spill bug fixed in 0.8.36. Write-up: Spill Slot Collision Across Mutual Recursion Bug | Solidity Programming Language\nVery low severity: Named arguments of a custom error passed to require were put on the stack in call-site order instead of declaration order (IR pipeline), so the encoded revert data could be structurally valid but not reflect the values used. Only revert data is affected. Write-up: Misordered Named Parameters in require with Custom Errors Bug | Solidity Programming Language\n\nOther miscompilations, fixed but not classified as security issues:\n\nUninitialized internal function pointers read from a packed storage slot yielded the wrong value when a later variable in the slot was non-zero (evmasm pipeline). Only affects pointers compared before ever being assigned, and relying on function pointer equality is fragile anyway.\nConstants read in both checked and unchecked contexts got the semantics of whichever use site was generated first (IR pipeline). Deterministic, independent of transaction input and easily caught by tests.\n\nFeatures and changes:\n\nblock.slotnum (uint64) and the Yul builtin slotnum() expose the SLOTNUM opcode (EIP-7843) when compiling with --evm-version amsterdam. Amsterdam support is still experimental and incomplete.\nThe experimental SSA CFG code generator gets a planning stack shuffler in place of the greedy one.\nThe experimental LSP mode and the Generic Solidity prototype are removed. The LSP was unfinished, and Generic Solidity has been superseded by the standalone solcore prototype.\npragma experimental ABIEncoderV2 now emits a deprecation warning. It has been redundant since 0.8.0 and will be removed in a later 0.8.x release.\nDeprecation warnings for the EVM versions constantinople, petersburg, istanbul and berlin, and for the SMTChecker BMC engine.\n\nRelease post: Solidity 0.8.37 Release Announcement | Solidity Programming Language\nRelease and changelog: Release Version 0.8.37 · argotorg/solidity · GitHub\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1729,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262738156,"hash":"a49846736aef2159317149a0c4ce2bbdd4d3065b"}
{"url":"https://ethresear.ch/t/payload-chunking/23008","domain":"ethresear.ch","title":"Payload Chunking - Sharding - Ethereum Research","text":"Payload Chunking \n\n Sharding\n\n stateless,data-availability,chunking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n read \n\n 10\n min\n\n Sep 2025\n\n 1 / 9\n\n Aug 2025\n\n Sep 2025\n\n post by Nero_eth on Sep 1, 2025\n\n Nero_eth\n\n Payload Chunking\ntl;dr: Split an EL block (=payload) into multiple mini‑blocks (“chunks”) of fixed gas budget (e.g. 2**24 = 16.77M) that propagate independently as side cars. Each chunk carries the pre‑state it needs to execute statelessly and commits to its post‑state diff. Chunks are ordered but can be executed fully independently in parallel. CL commits to the set of chunk headers; sidecars carry bodies and inclusion proofs.\nValidation becomes more of a continuous stream.\nMotivation\nToday, blocks are large, monolithic objects that will become even larger in the future. Validation requires receiving the full block before execution can begin. This creates latency bottlenecks in block propagation and execution.\nAfter the block is received over the p2p network, transactions are executed sequentially. We cannot start validating while downloading or parallelize execution.\nTimeline showing today’s block validation bottleneck: full block download first, then sequential execution1100×580 29.3 KB\n\nMessages on the p2p layer are usually compressed using Snappy. The block-format of Snappy that is used on Ethereum cannot be streamed. Thus, we need to slice the block into chunks before compression.\n\nWith EIP-7928: Block-level Access Lists, the situation improves, but we’re still waiting for the download to finish before starting block validation. With 4 cores, we get the following Gantt chart:\nTimeline under EIP-7928: execution can use access lists but still must wait for block download1101×580 33.3 KB\nInstead, we can stream blocks as chunks:\n\nEach chunk contains ≤ 2**24 gas of transactions.\n\nOne could also have the chunk size increase geometrically (2**22, 2**23, …, 2**25) in gas. This would give us varying latencies for chunks, enabling better parallelization - but I’m not sure it’d be worth the complexity.\n\nTransactions remain ordered. Chunks are indexed and ordered, but independent of each other, so they can be validated in parallel. Still, the post-state of chunk 0 is the pre-state of chunk 1.\n(optional) Each chunk carries the state it needs to be executed statelessly.\n\nTimeline with payload chunking: chunks stream in and execute in parallel while downloading continues.1101×580 37.7 KB\nThis shifts validation from “download full block, then process” → “process while receiving the rest.”\n\nExecution Layer Changes\nWe extend the EL block format to support chunking:\nclass ELHeader:\n parent_hash: Hash32\n fee_recipient: Address\n block_number: uint64\n gas_limit: uint64\n timestamp: uint64\n extra_data: ByteList[MAX_EXTRA_DATA_BYTES]\n prev_randao: Bytes32\n base_fee_per_gas: uint256\n parent_beacon_block_root: Root\n blob_gas_used: uint64\n excess_blob_gas: uint64\n transactions_root: Root\n state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: Uint\n withdrawals_root: Root\n block_access_list_hash: Bytes32\n # New fields\n chunk_count: int # >= 0\n\nThere is no commitment to the individual chunks in the EL header. We only add the chunk count to it. The execution outputs (state_root, logs_bloom, receipts_root, gas_used) must be either the same as the value in the last chunk (applies to state root and withdrawals root), or the root after aggregating the chunk’s values (applies to transactions, receipts, logs, gas used, and the block access list).\nExecution Chunks\nChunks are never put on-chain; only their roots are committed.\nChunks contain the fields we would usually expect in the EL block body. Transactions are split up over chunks with a limit of 2**24 gas per chunk. Withdrawals must only be included in the last chunk. Mirroring block-level access lists, chunks come with their own chunk access list, and one could additionally add pre-state values to chunks, unlocking statelessness.\nclass Chunk:\n header: ChunkHeader\n transactions: List[Tx]\n withdrawals: List[Withdrawal] # only in chunk at index -1\n chunk_access_list: List[ChunkAccessList]\n pre_state_values: List[(Key, Value)] # optional\n\nEach chunk comes with a header including the chunk index. Transactions are ordered by chunk.header.index and their index in the chunk. Commitments to each chunk’s execution output are included in the header.\nclass ChunkHeader:\n index: int\n txs_root: Root\n post_state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: uint64\n withdrawals_root: Root\n chunk_access_list_root: Root\n pre_state_values_root: Root # optional\n\nTo prevent proposers splitting their blocks into too many chunks, the protocol can enforce that chunks must be at least half full (\\geq\\frac{chunk\\_gas\\_limit}{2}≥𝑐ℎ𝑢𝑛𝑘_𝑔𝑎𝑠_𝑙𝑖𝑚𝑖𝑡2) OR chunk.header.index == len(beaconBlock.chunk_roots) (= last chunk in that block).\n\nConsensus Layer Changes\nDiagram of consensus changes: beacon block tracks chunk roots while execution chunks propagate via sidecars.1180×593 91.5 KB\nBeacon blocks track chunks with new fields:\nclass BeaconBlockBody:\n ...\n chunk_roots: List[ChunkRoot, MAX_CHUNKS_PER_BLOCK] # SSZ roots of chunks\n\nclass ExecutionPayloadHeader:\n ...\n chunk_count: int\n\nThe CL receives the execution chunks from the EL via a new ChunkBundle container which includes the EL header and the chunks (=similar to blobs).\nThe CL computes chunk roots using SSZ’s hash_tree_root and puts them into the beacon block body.\nSidecar Design\nChunks are carried in sidecars:\nclass ExecutionChunkSidecar:\n index: uint64 # chunk index\n chunk: ByteList[MAX_CHUNK_SIZE] # Opaque chunk data\n signed_block_header: SignedBeaconBlockHeader\n chunk_root_inclusion_proof: Vector[Bytes32, PROOF_DEPTH]\n\nThe consensus layer ensures all chunks are available and properly linked to the beacon block body via Merkle proofs against chunk_roots (=similar to blobs).\nNetworking\nThe proposer gossips only the lightweight beacon block with commitments (chunk_count, chunk_headers_root) on the normal beacon_block topic, while the heavy execution data is streamed separately as ExecutionChunkSidecars across X parallel subnets (beacon_chunk_sidecar_{0..X}), deduped by (block_root, index).\nInitially, all nodes must subscribe to all subnets and custody all chunks. While this doesn’t reduce bandwidth/storage requirements yet, it enables the immediate benefits of parallelization. Partial custody can be added in a future upgrade once the basic mechanism is proven and/or zk-proving becomes viable.\nNetworking view: lightweight beacon block propagates fast, while heavy execution chunks are streamed across parallel subnets.1090×430 260 KB\nFork Choice\nFork choice requires that all sidecars are both available and successfully validated before a block is considered valid. The beacon block with the chunk_roots propagates quickly, but the block only becomes fork-choice eligible once every chunk has been received and inclusion-proven against the root. The beacon block still contains the EL header with all the necessary commitments (=committing to parent block and execution outputs). What we knew as block body on the EL stays empty in this design.\n\nBenefits\n\nStreaming validation: execution can start while other parts of the block are still downloading or busy loading from disk. Chunks are independent (if pre-state provided), or rely on the chunk-access list (with chunk-level state diffs) and the pre-block-state; multiple CPUs/cores can validate chunks simultaneously; distribute bandwidth usage over slot instead of beginning-of-slot bursts.\nStreamlined proving: ZK Provers can parallelize proving multiple chunks at the same time, benefiting from the independence of chunks.\nStateless friendliness: since a single chunk is smaller than a block, we might consider adding pre-state values such that there is no need for local state access. A practical middle ground is to include pre-state values only in chunk 0, guaranteeing that at least one chunk can always be executed while the node loads the state required for other chunks from disk into cache.\nFuture extensibility: clear path to integrate zk-proofs over chunks or going for sharded execution.\n\nDesign Space\nChunk Size\n2**24 gas (~16.7M) emerged as a natural chunk size:\n\nMax Transaction Size: As of Fusaka (EIP-7825), 2**24 is the max possible transaction size.\nCurrent blocks: 45M gas blocks naturally split into ~3 chunks, providing immediate parallelism\nFuture blocks: Scales well - 100M gas blocks would have ~6 chunks\n\nValidator\n\nExecution engine splits the block into chunks internally (opaque to CL) and passes them to the CL through an ExecutionChunkBundle.\nProposer wraps each chunk in a sidecar with inclusion proof. The proposer also computes the hash tree root of each chunk and puts them into the beacon block body.\nPublishing happens in parallel across all subnets\nAttesters wait for all chunks and validate them before voting\n\nBuilders\nProposers can publish chunks as they’re finished building, and validators can start validating them even before receiving the beacon block. Since chunks contain the signed beacon block header and an inclusion proof against it, one can validate (=execute) chunks as they come in, trusting their source (=proposer).\nOpen Questions & Future Work\nProgressive Chunk Sizes?\nThe idea of geometrically increasing chunk sizes (2**22, 2**23, …, 2**25) seems beneficial but adds complexity. The first chunk could be smaller (5M gas) with pre-state values for immediate execution, while later chunks are larger. This remains an area for experimentation.\nPartial Custody Path\nWhile the initial implementation requires full custody, the architecture naturally supports partial custody:\n\nNodes could custody only Y subnets out of X\nReconstruction mechanisms (similar to DAS) could recover missing chunks\n\nCompatible with ePBS and Delayed Execution\nAt first glance, the proposed design seems compatible with both EIP-7732 and EIP-7886. Under ePBS, the chunk roots would likely move into the ExecutionPayloadEnvelope, and we’d put an additional root over the chunk roots into the ExecutionPayloadHeader. The PTC would not only have to check that a single EL payload is available, but that all chunks are. This is not much different from blobs.\nThe advantages of block chunking and independent validation scale with higher gas limits and may contribute to reducing spikiness in node bandwidth consumption.\n\n Toward Semantic Block Chunking\n\n BALs for Proposer Commitments\n\n Integrated in-protocol distributed history and state storage\n\n Blocks Are Dead. Long Live Blobs\n\n 5\n\n read \n\n 10\n min\n\n post by daniellehrner on Sep 1, 2025\n\n daniellehrner\n\n I really like this proposal.\nI think there could be further changes that not only allow streaming during execution, but during block building as well:\nToday the whole network, except for the block builder, stands still until the builder has constructed the full block and has calculated the state root hash. This is true even with this proposal.\nIt might be possible to allow the builder to stream the transactions before the full block is constructed. The builder could construct a header that only contains a subset of the fields today which are known before building the block:\n\nPREVRANDAO\nBLOCKNUMBER\nTIMESTAMP\netc\n\nAfter that it could start to add the transactions and send them to its peers once that a chunk is full. This would decrease the time to first byte, because the builder could send chunks before the full block is ready.\nOnce the block is fully built the builder could send a footer which contains the missing fields like:\n\nBLOCKHASH\nSTATEROOT\nRECEIPTSROOT\netc.\n\nI think there are mainly 2 downsides:\n\nBALs don’t work anymore in their current form. We could convert them into chunk level access lists, but most probably increase bandwidth requirements\nBlock validation is split into two steps: validating the fields in the header → execute transactions-> validate fields in the footer. But payload chunking in its current form requires that the block hash in only validated after all the chunks have been received.\n\n post by Nero_eth on Sep 2, 2025\n\n Nero_eth\n\n Yeah, this is interesting!\nI don’t think moving from block-access lists to chunk-access lists would be a major issue. The objects themselves get smaller, we gain parallelization, and there’s even room to increase the size of individual objects (for example, supporting statelessness).\nIn the block chunking proposal, the idea is similar: chunks can be published earlier than the EL header. Each chunk can be validated independently, and once they’re all validated, only the aggregate execution outputs need to be checked. At that stage, the EL header is required, but not before, since it only contains the chunk count and no other chunk-specific information.\n\n post by raulk on Sep 8, 2025\n\n raulk\n\n Promising proposal! I support the general direction, and I think we should let the builder side stream too. That keeps progress steady and incremental across the slot and reduces peak system requirements on builders (especially important for local builders as we increase gas limits and shorten slot times).\nMore concretely, this is what I’m thinking.\nMake streaming first class. I’d avoid committing to the total chunk count upfront, or to specific chunk contents. Let builders emit a chunk as soon it hits a gas budget, up to the relevant protocol caps (block gas limit, max chunks). Use either a closing trailer, or a per-chunk “last” marker. I lean towards the trailer: it keeps final commitments tidy and encapsulated. Header and trailer are small, so we can broadcast them more aggresively (e.g. higher fanout).\nBuilder pipeline. Parallelize chunk production by saturating all available CPU cores. Run one EVM per core with shared conflict detection; pin instances to OS threads if useful. Route transactions based on tx-level access list. Use speculative execution, potentially with copy-on-write snapshots to migrate a conflicting inflight transaction to another chunk on conflict (e.g. OverlayFS style). Keep shipping chunks as they’re ready. Do not wait for the full set. When the block gas limit is hit, merge pending EVMs, finalize outputs, and dispatch the final chunks. There’s probably work from the Parallel EVM world that becomes very relevant here.\nValidator pipeline. Execute chunks as they arrive. One EVM per chunk, with shared conflict detection to reject the block on conflict (or validation against chunk-level access lists, or prestate, as you mentioned). This matches the original proposal.\nCommitments. Treat some execution payload fields as placeholders that the trailer fills in; namely those dependent on the post-state: transactions_root, state_root, receipts_root, logs, etc. Put chunk commitments and chunk count in the trailer, together with the final proposer signature. Because the block continues being atomic, the chain can be spared of chunking details. I’d think of the chunked form as virtual during transit, which is then collapsed into a single committable block when appending to the ledger. If useful, we can persist chunk boundaries and metadata off-chain for P2P RPC and checkpoint sync, but not necessarily in the canonical structure.\nNetworking. Independent chunking is a win if overhead stays low. It allows parallel propagation across subnets and smoother bandwidth profiles across the slot.\nChunk authentication without a fixed count. All chunks are signed by the proposer. Proposer equivocation rules probably need to adapt. To strengthen the model, we can carry a running accumulator in each chunk header, and have the trailer commit to the final accumulator. Validators receiving chunks out of order can still validate taking the risk with some configured tolerance.\nMental model. This looks like MapReduce at the EVM level. Builders map transactions into independent execution units under conflict detection. Validators reduce by merging verified, non-conflicting results in order.\n\n post by preda-devteam on Sep 9, 2025\n\n preda-devteam\n\n This is inspiring and enlightening \nStreamlining block reception and execution would be a smart move now that BALs are paving the way for many improvements.\nAdditionally, I’d like to delve into the specifics of parallel execution and the adoption of a Parallel EVM that partitions data/state architecture—something I’ve been working on. I have two questions regarding your proposal:\n\nValidator/Parallel Execution\nWith BALs, we’ve set the stage for parallel execution—essentially a pessimistic approach to parallelization. Is this the kind of parallel execution you’re envisioning?\n\nOnce a block chunk is received by a validator, BALs provide insight into the read/write list, allowing conflict-free transactions to be executed in parallel across the validator’s multiple cores. This mechanism is similar to the pessimistic-parallel execution employed by other chains. With BALs in place, there’s significant potential to maximize parallelism and reduce state conflicts.\n\nNetworking/Partitioning Possibilities\nYou mentioned the future possibility of “partial custody,” where subnet nodes would only manage a fraction of the data. This got me thinking about the broader direction of partitioning across communication, storage, and execution. Do you see Ethereum’s future leaning more towards full sharding (partitioning across all three dimensions) or partial sharding (partitioning across one or a subset)?\n\nA key advantage of partitioning would be overcoming the limitations of computational power in a single VM, the real opportunity here is to leverage the total processing power of the entire network. This would allow Ethereum’s performance to scale as the number of nodes increases.\n\n post by Nero_eth on Sep 9, 2025\n\n Nero_eth\n\n Great comments, thanks!\n\nYeah, totally agree and I’d say this is already supported with the chunking approach. For DoS resistance, validators need a way to verify a chunk is signed by the rightful proposer of that slot, and this is possible with the sidecars containing the signed_block_header. Even though one cannot yet validate the inclusion proof, validators could still already start executing, delaying the inclusion proof until the beacon block is received.\nMy feeling is that this might be good enough and we would not need a commitment to the chunks different from the proposer’s signature to start processing. The beacon block essentially becomes the trailer\n\n post by Nero_eth on Sep 9, 2025\n\n Nero_eth\n\nYou get perfect parallelization. No need to separate tx into non-conflicting batches. With EIP-7928, every transaction can be executed independently of another.\n\nWhile I agree that this is an interesting concept, it feels like we’re still kinda far from such a world. DAS, as done with blobs is a great role model for what we should strive for on the EL as well. zkVMs will further change how we think about related concepts, so, still rather difficult to tell how things evolve. Execution sharding has huge potential for scaling and is definitely on the list.\n\n 10 days later\n\n post by gballet on Sep 19, 2025\n\n gballet\n\n That has potential, but I do see a lot of issues as well.\nThe Bad\n\nThe obvious one is complexity: Chunks need to travel over the network and be executed in due time. Under normal conditions, I think it’s to be expected that the validators will execute these Chunk optimistically and wait for the next, but if for whatever reason the chunks are not being distributed, the rational thing to do will be to wait for all the chunks to be downloaded anyway so that they can be executed in parallel. And if that is the case, then why not simply give a single block and add the same information to allow for chunk execution in parallel without having to distribute the data over the network and gope that the recipient will collect all the pieces in time?\nIt is much faster to download a big chunk of data than many many small bits and pieces. To be seriously considered, this proposal should effectively make some measurements as to how much time is saved executing in parallel, and in what kind of load. I don’t believe it’s unrealistic to expect that the execution will be spending most of its time waiting on the data to end up downloading, then immediately execute the chunk and wait for the next one. In particular, it should be explained why this is a better approach than simply packaging the transactions in such a way that you could start executing as the data is being downloaded.\nThis is yet another proposal that increases the bandwidth requirements and also puts a lot of work on the proposer to hash the work for the validators.\nI do not think it will help the ZKVM approach at all, in the sense that proving is very slow and so you will lose all the benefits of parallel proving. I understand that the end goal would be to have carious entities on the network working on a single chunk at a time and sharing them over the network, with the execution being proven in parallel by the validator without even needing to download the chunks. But there is the problem of whom commits to building these proofs? The builder itself will not be able to provide any commitments that these proofs are correct.\nIn the case when most txs depend on each other, e.g. sandwiching blocks, your chunks are going to be very small.\nI might be missing something on the CL side, but it seems to me that this is very susceptible to Spamming because one could simply spam a lot of chunks even if they are not part of the block. How is the executor supposed to know the connection between the chunks and the block, if no commitment is made? The sidecar would require some hefty proving, which a simple hash could do instead.\n\nSo in summary, I think proper research should be conducted in order to find out if this is really worth the complexity.\nThe good\nI think most of the potential comes from the idea that blocks could actually be produced by many builders at the same time, and this is a good first step for this to happen. In a way you could represent this as inclusion list being just actual execution instead of a list of instructions, and if for whatever reason they are not executable, then they are still part of the block, but they are not canon.\nSo in my view as such it doesn’t bring very much, but if we could somehow make it also a way to share building between many clients and many nodes, then this would have really the potential to make a dent in terms of scalability.\nQuestion\n\nWhy are withdrawals included in a chunk? They could still be part of the block and be optimistically executed in parallel instead of waiting for the last chunk, I doubt there will be people trying to use their withdrawal address in the same block as the withdrawal, and if this happens, it can be easily worked around.\n\n post by Nero_eth on Sep 19, 2025\n\n Nero_eth\n\n Thanks for the questions and feedback!\n\nThis is what Block-Level Access Lists already give you, in combination with EIP-7825 (the tx gas limit of 16.77M). Each transaction is executable fully independently from another, thus, if you wait for all chunks to be downloaded just to then start executing chunks in parallel, then you arrive at where we’re at with BALs. The only way to improve on this would be by enabling validators to start executing earlier, even before everything is received.\n\nYeah agree, measurements are needed. In any case, this would speed up the “time to validation” for validators, independently if builder make use of the smaller chunks and actually publish them earlier, or if they wait until the last second. Since the absolute size of the object you need to download is smaller (much smaller if you compare 16.77M (=chunk size) to 60M or 100M (=future block gas limit)). The smaller object will propagate faster, shortening the time from beginning of propagation to beginning of validation.\n\nTrue but only marginally (a few 32 bytes values that were in the block header are now in all chunk headers; maybe a few hundred bytes overhead) but in return we have a less spiky bandwidth usage over the slot. Also, I keep hearing that our gossip network was never created with the intent of sending around large messages ( cc @raulk, @MarcoPolo), and with increasing gas limits, we have no other option on the table to somehow limit message sizes.\nIf we have chunks being statelessly validatable, we’d ensure that they are executable independently from the order in which you receive them. This would add a lot of data on top, I agree but maybe, if we don’t make them stateless (like mentioned in the post) but instead require validators to have full state, then we still get the benefits of being able to independently download but then you can only execute the second chunk if you already have the first (using it’s chunk-level access list).\nAnother alternative would be to have the chunk access list travel as a sidecar too, exclusively providing state updates to validators, whereas the chunks with the actual data travels independently.\n\nMore like, have various entities work on different chunks, but since this proposal doesn’t affect builder or prover economics, we might just not care to much about it at this point. Validators would still need to download all chunks.\n\nNote that transactions distributed over chunks still enjoy the same atomicity as if they were in the same block. We could enforce that chunks must always be at least 1/2 full (measured in gas used), otherwise invalid. Thus, you can do a sandwich starting in chunk 0 and finishing in chunk 1. The post state root of the last tx in chunk 0 is the pre state root of the first transaction in chunk 1.\nThe proposal doesn’t really focus on builders and provers but on validators and how we could relief them from work in the critical path.\nLet’s assume there are no provers yet (which is true today) and builders play timing games until the last possible second. Even then, validators would profit by being able to parallelize between validating the first chunk while downloading the rest. Builders can publish_ chunks earlier, just like provers can provide proves for chunks without seeing the full block, but this is a different topic.\nMy argument is that if we don’t chunk things in-protocol, then we may just increase the time of everything (upload, download, validation) linearly without having any way to parallelize between the 3.\n\nBlocks on the EL wouldn’t exist anymore, just chunks and a header. Today, withdrawals are applied after executing all transactions. We could enforce that only the last chunk is allowed to contain withdrawals and then process them just like today.\n\n Powered by Discourse","tokens":6670,"squid":"ink-research","role":"Deep Scholar","at":1791262742294,"hash":"1bda494c247c891d5170ed0256bc932f52f0e564"}
{"url":"https://forum.openzeppelin.com/t/how-to-put-the-price-0-0000001-10-6-uint256-does-not-accept-0-1/36240/1","domain":"forum.openzeppelin.com","title":"How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1 - Smart Contracts - OpenZeppelin Forum","text":"How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1 \n\n Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n May 2023\n\n 1 / 7\n\n May 2023\n\n May 2023\n\n post by 213101 on May 15, 2023\n\n 213101\n\n I want to set the price of the token to 0.0000001$ (in USDT)\nFor this I take 0.0000001*10^6 = 0.1\nI am getting an error.\ninvalid BigNumber string (argument=\"value\", value=\"0.1\", code=INVALID_ARGUMENT, version=bignumber/5.1.1)\nHow to insert 0.1 correctly?\n\n 4\n\n 3\n\n post by barakman on May 15, 2023\n\n barakman\n\nNo, 0.0000001*10^18 = 10^11.\n\n post by 213101 on May 16, 2023\n\n 213101\n\n invalid number value (arg=\"_prices\", coderType=\"uint256\", value=\"10^11\")\n\n post by barakman on May 16, 2023\n\n barakman\n\n Dude, I was trying to explain to you, using pure mathematical notation (i.e., not solidity code), that 0.0000001 times 10^18 is not equal to 0.001, but rather, to 10^11, which is of course an integer value, representable by a uint256.\nIn short, what you need to do, is to pass something like BigNumber.from(\"100000000000\").\nOr perhaps BigNumber.from(10).pow(11), or even BigNumber.from(\"10e11\").\nIt really depends on what BigNumber implementation you're using.\nBut following your original question, as well as your response to my answer, I believe that you might wanna study some basic programming concepts before jumping to smart contracts.\n\n post by 213101 on May 16, 2023\n\n 213101\n\n I just need to put one correct value.\nhere is my contract.\n\nupdateTokenRate (0x3115329e)\n\n post by barakman on May 16, 2023\n\n post by 213101 on May 16, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale set rate for 9 decimal\n\n Support\n\n crowdsale\n\n 2\n\n 628\n\n Apr 2021\n\n Error: invalid BigNumber string\n\n Contracts\n\n 1\n\n 1.3k\n\n Oct 2021\n\n Going insane over Token pricing\n\n Support\n\n erc20\n\n 2\n\n 598\n\n Jun 2021\n\n Setting up my crowdsale rate\n\n Smart Contracts\n\n crowdsale\n\n 1\n\n 951\n\n May 2022\n\n Invalid BigNumber value for string\n\n Smart Contracts\n\n erc721,solidity\n\n 1\n\n 227\n\n Jun 2024","tokens":524,"squid":"ink-security_audits","role":"Sentinel","at":1791262748669,"hash":"1d72313b0a7236d04dcec0228a38e8703d4c4b42"}
{"url":"https://blog.soliditylang.org/2026/09/10/spill-slot-collision-across-mutual-recursion-bug/","domain":"blog.soliditylang.org","title":"Spill Slot Collision Across Mutual Recursion Bug | Solidity Programming Language","text":"Spill Slot Collision Across Mutual Recursion BugPosted by Solidity Team on September 10, 2026Security AlertsOn July 30, 2026, Ng Sze Hon reported a bug in the IR pipeline's stack-to-memory mover (the \"stack limit evader\") through the Ethereum Foundation's bug bounty program.\nThe mover works around the EVM's stack depth limit by relocating (\"spilling\") some local variables to fixed memory offsets, called spill slots.\nBecause of the bug, variables of two different functions can be assigned the same spill slot when the call graph contains mutual recursion, even though both variables can be live at the same time.\nOne variable is then silently overwritten by the other, and the contract computes and stores a value the source code never assigns.\nThe bug is closely related to, but distinct from, the Unsound Spill In Mutual Recursion Bug, which was fixed in Solidity 0.8.36.\nIt is present even in compiler versions that carry that fix (see Relation to the earlier spill bug below).\nWe assign this bug a severity of low/medium on our internal scale.\nThe bug only affects the IR pipeline; the legacy evmasm pipeline is not affected.\nThe --via-ir flag is not enabled by default, so projects that have not explicitly opted into it are not affected.\nContracts without mutually recursive functions are not affected either.\nThe affected code has been reachable since Solidity 0.7.2, though the precise conditions required to trigger it change across that range (see Affected versions below).\nAll versions from 0.7.2 through 0.8.36 are affected.\nThe bug is fixed in Solidity 0.8.37.\nWe rescanned the Sourcify database, recompiling roughly 319,000 verified contracts using compilers built with and without the fix.\nNone of them compiled to different bytecode, so no deployed contract is known to be affected.\nWhich Contracts Are Affected?\nA contract is only affected if all of the following conditions are met:\n\nit is compiled with --via-ir (or settings.viaIR in Standard JSON; --experimental-via-ir on versions before 0.8.13),\nit contains functions that are called internally and call each other in a cycle of at least two functions (a function that only calls itself does not trigger the bug),\nsome non-recursive function that the cycle can reach uses so many simultaneously-live values (roughly, more than 16, including parameters and return variables) that the compiler relocates some of them to memory,\na second non-recursive function, distinct from the one in the previous condition, also has variables relocated to memory, calls into the cycle directly or through intermediate functions, and reads at least one of those variables back after that call returns,\nno recursive function in the contract needs variables of its own relocated to memory (otherwise the compiler skips relocation entirely, and a contract that needed it fails to compile with \"Stack too deep\"), and\nthe order in which the compiler traverses the call graph does not mitigate the issue (see The slot-allocation bug below).\n\nThe first two conditions are easy to check.\nThe remaining ones depend on compiler internals and cannot be reliably ruled out by inspecting the contract's source, so if your contract meets the first two, treat it as potentially affected and upgrade.\nStill, all conditions must coincide, which is why the affected pattern is very uncommon in practice.\nWhether functions are mutually recursive is determined on the compiled Yul code rather than on the Solidity source.\nIn practice this matters for inline assembly: mutually recursive Yul functions defined in an assembly block count as mutual recursion as well.\nIf your contract has no mutual recursion (in Solidity or inline assembly), it is not affected.\nIn addition, the stack-to-memory relocation only runs on code the compiler knows to be memory-safe.\nCounterintuitively, this means that a contract containing inline assembly that is not annotated as memory-safe cannot be affected.\nOn Solidity 0.8.21 and later, the bug is independent of whether the optimizer is enabled.\nThe stack-to-memory relocation is then a distinct stage of the IR pipeline that runs regardless of the optimizer setting, so disabling the optimizer does not avoid it.\nOn earlier affected versions (0.7.2 through 0.8.20), however, the Yul optimizer, and with it the stack-to-memory mover, only runs when --optimize is passed, so reaching the bug there requires both --via-ir and --optimize.\nIn all cases, only the settings used to compile the deployed contract matter, not those used for tests or CI.\nTechnical Details\nThis section describes the compiler internals behind the bug for readers interested in the implementation-level root cause.\nAffected versions\nThe bug was introduced in 0.7.2 together with the stack limit evader itself and has been present in every released version since, but how the affected code can be reached differs across that range:\n\nIn 0.7.2 through 0.7.4, the IR pipeline was not reachable from the command line or Standard JSON at all; the affected code could only be triggered by manually feeding --ir-optimized output to --strict-assembly.\nFrom 0.7.5 through 0.8.12, the IR pipeline was experimental and required the --experimental-via-ir flag; from 0.8.13 onward it is requested with --via-ir.\nBefore 0.8.21, the stack limit evader only ran when --optimize was passed; from 0.8.21 onward it runs by default, and the bug is independent of the optimizer setting.\n\nThe bug can also be triggered by compiling hand-written Yul that uses the memoryguard builtin (described below) with --strict-assembly.\nRecursion and the stack-to-memory mover\nEVM instructions can access at most the topmost 16 stack slots, so a function whose simultaneously-live local variables exceed that limit cannot be compiled directly: this is the well-known \"Stack too deep\" error.\nThe IR pipeline works around it with the stack-to-memory mover, which picks some of the affected variables and rewrites their accesses into mstore/mload operations on their spill slots: fixed offsets in a reserved region at the start of memory.\nThe size of that region is announced to the Yul optimizer via the memoryguard builtin.\nBecause a spill slot is shared by every activation of a function, the relocation is only sound for functions that are not recursive, and the mover excludes recursive functions.\nThe Unsound Spill In Mutual Recursion Bug post describes this mechanism and its recursion constraint in more detail.\nSizing the reserved region\nNot every spilled variable needs its own slot.\nTwo functions that can never be active at the same time may share one.\nA function must never reuse a slot belonging to one of its callers, however, because the callers' spilled variables are still live while the callee runs.\nTo take advantage of this, the mover's slot allocator walks the call graph depth-first and computes, for every function, its slot requirement: the number of slots that it and everything it can reach need.\nA function's own spilled variables are numbered just above the largest requirement among its callees, and the requirement computed at the entry point determines the size of the reserved region.\nEach function's requirement is cached so that later callers of an already-visited function can reuse the result.\nTo keep the walk from descending forever into recursive call chains, the allocator writes a provisional requirement of 0 into the cache when it enters a function and only replaces it with the real value once all of the function's callees have been explored.\nThe slot-allocation bug\nThe mechanism described in this section is also explained in the following short video.\n\nThe provisional 0 terminates the walk on cycles: a cycle eventually leads back to a function that is still being processed, and the early cache entry stops the recursion there.\nThe problem is that the walk itself can read the provisional value as if it were final.\nA function reached again through a cycle sees 0 instead of the real requirement of the function it calls and is finalized and cached on that basis.\nThe undercount then propagates to every later caller, including callers that have nothing to do with the cycle.\nConsider four functions: f and g are mutually recursive, f also calls h, and p calls into the cycle via g.\nh and p each need one spill slot; f and g need none:\np --> g <--> f --> h\n\nThe walk starts at the contract's entry point, which calls f before p, and descends into f, writing its provisional 0.\nIt descends into h, which takes slot 0 and returns a requirement of 1.\nIt descends into g, which follows the recursive call back to f.\nf is still being processed, so g reads f's provisional 0 and, having nothing of its own to spill, is finalized at 0 and cached.\nThe correct value is 1: g reaches h through f.\nf is finalized at max(1, 0) = 1, but the cycle's undercount is already cached.\nBack at the entry point, the walk descends into p, whose only callee is g.\nIt reads the cached 0 and assigns slot 0 to p's variable as well.\n\nThe reserved region is sized for one spill slot where two are needed, and the variables of h and p are assigned the same slot.\nAt runtime, p writes its variable and calls into the cycle.\nThe call reaches h, which overwrites the shared slot.\nWhen p reads its variable back, it gets h's value.\nWhether the undercount happens depends on the traversal order: the function through which the walk first enters the cycle always computes correct values.\nHad the walk reached the cycle through p first, g's requirement would have been finalized only after f and h had been fully explored, and p would have read the correct 1.\nThe traversal order follows the order in which calls appear in the generated Yul code, so triggering the bug depends not only on the presence of mutual recursion but also on where the calls into it appear.\nNote that a function that only calls itself cannot trigger the undercount: the only cycle leads back to the function itself, and its requirement is finalized only after all of its other callees have been fully explored.\nRelation to the earlier spill bug\nThe Unsound Spill In Mutual Recursion Bug fixed in Solidity 0.8.36 was a misclassification bug:\nfaulty cycle detection caused some mutually recursive functions to be treated as non-recursive, so the mover spilled variables of a recursive function, violating the rule that recursive functions must never have spilled variables.\nFor the bug described here, the classification is correct: neither of the two colliding functions is recursive, and the cycle members are detected as such and have no variables spilled.\nThe violated property is a different one: two variables that can be live at the same time must never share a spill slot.\nConsequently, the bug is present even in Solidity 0.8.36, which carries the fix for the earlier bug.\nExample\nThe following contract demonstrates the bug, arranged to meet the conditions above.\nThe repetitive variable declarations are abridged for readability; the complete reproducer can be found in the compiler's test suite.\nThe never-taken msg.data.length branches keep the functions from being inlined (an inlined function disappears from the call graph), and the initial call to f in test fixes the traversal order described above.\ncontract C {\n uint public x;\n\n // Needs spilling: 18 simultaneously-live locals.\n function h(uint seed) internal view returns (uint out) {\n if ((msg.data.length & 8) != 0) // never taken; prevents inlining\n return seed;\n unchecked {\n uint h0 = address(this).balance + seed;\n uint h1 = address(this).balance;\n // ... h2 .. h17 ...\n out = h0 + h1 + /* ... */ + h17;\n }\n }\n\n // f and g form the mutually recursive cycle; f also calls h.\n function f(uint n, uint seed) internal view returns (uint r) {\n if (n == 0)\n return h(seed);\n return g(n - 1, seed);\n }\n\n function g(uint n, uint seed) internal view returns (uint r) {\n if ((msg.data.length & 2) != 0) // never taken; prevents inlining\n return seed;\n return f(n, seed);\n }\n\n // Also needs spilling and calls into the cycle.\n function p(uint seed) internal returns (uint out) {\n if ((msg.data.length & 16) != 0) // never taken; prevents inlining\n return seed;\n unchecked {\n uint p0 = address(this).balance + seed;\n uint p1 = address(this).balance;\n // ... p2 .. p16 ...\n uint nested = g(0, seed + 2000);\n x = seed; // reads seed back from its spill slot\n out = nested + p0 + p1 + /* ... */ + p16;\n }\n }\n\n function test(uint z) external returns (uint, uint, uint) {\n uint warm = f(z & 1, z + 1000); // pins the traversal order\n uint result = p(z + 3);\n return (warm, result, x);\n }\n}\n\nFor a contract with zero balance, the source code says that test(0) should produce:\nwarm = f(0, 1000) = h(1000) = 1000, nested = g(0, 2003) = f(0, 2003) = h(2003) = 2003, result = 2003 + 3 = 2006, and x = seed = 3.\nObserved behavior:\nC target = new C();\n(uint warm, uint result, uint stored) = target.test(0);\n// expected: (1000, 2006, 3)\n// actual: (1000, 2006, 2003), only the third value differs:\n// stored holds the value computed by h\n\nseed in p is spilled to a fixed memory slot, and one of h's spilled locals is assigned the same slot.\nThe call g(0, seed + 2000) reaches h, which overwrites the shared slot with the value 2003 that it computed.\nresult is unaffected because p0 was computed from seed before the corrupting call; the later x = seed reads the slot after the call and stores 2003 instead of 3.\nSeverity Assessment\nThe compiler emits no warning, and the generated code does not revert at runtime.\nBecause the corruption manifests as an unexpected result rather than a failure, it can be difficult to diagnose.\nThe miscompilation is deterministic, so a test suite that is compiled with the same settings and exercises the affected code path will observe the incorrect behavior, even if the root cause is not immediately obvious.\nLike the earlier spill bug, and unlike many past compiler bugs, this bug can be triggered without any inline assembly.\nIn practice the likelihood is very low.\nThe narrow conditions listed under \"Which Contracts Are Affected?\" must all coincide.\nThe Sourcify rescan found no affected deployed contract.\nThe Fix\nThe fix changes the walk from one per function to one per strongly connected component (SCC) of the call graph: a maximal set of mutually recursive functions, with every non-recursive function forming a component of its own.\nOn a cycle, every member reaches all the others, so no member can have a private slot budget; the component must be sized as one unit.\nSlot requirements are computed and cached per component, and calls between members of the same component are ignored during the walk, because whatever the callee needs is already included in the component's total.\nThe components always form an acyclic graph, so a component can never be reached again while it is still being processed:\nthere is no provisional value to read, and every cached requirement is final.\nIn the four-function example above, f and g form a single component whose requirement is finalized as 1 only after h has been fully explored, and p correctly places its variable in a second slot.\nFor contracts that previously triggered the bug, the fix changes only the size of the reserved region and the assigned slots.\nUpgrading will not break a build that currently compiles: unlike the fix for the earlier spill bug, this fix does not cause any contract to start failing with \"Stack too deep\".\nThe fix is additionally guarded by a new property-based fuzz test that generates random call graphs and compares program behavior before and after spilling.\nRecommended Actions\n\nUpgrade to Solidity 0.8.37 or later before deploying contracts compiled via IR.\nIf you have already deployed contracts compiled via IR, check their source for mutually recursive functions; without mutual recursion, they are not affected.\nIf mutual recursion is present, there is no simple check that rules the bug out; treat the contract as potentially affected and review it, paying particular attention to local variables that are read back after internal calls that lead into the recursion.\n\nAcknowledgements\nThanks to Ng Sze Hon for reporting the bug through the Ethereum Foundation's bug bounty program and providing a detailed analysis and reproducer.Next post","tokens":4056,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262749615,"hash":"93bf0f02a131b207983ce114acf1e6aa78954e36"}
{"url":"https://ethresear.ch/t/payload-chunking/23008/9","domain":"ethresear.ch","title":"Payload Chunking - Sharding - Ethereum Research","text":"Sharding\n\n stateless,data-availability,chunking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n read \n\n 10\n min\n\n Sep 2025\n\n 9 / 9\n\n Sep 2025\n\n Sep 2025\n\n post by Nero_eth on Sep 1, 2025\n\n Nero_eth\n\n Payload Chunking\ntl;dr: Split an EL block (=payload) into multiple mini‑blocks (“chunks”) of fixed gas budget (e.g. 2**24 = 16.77M) that propagate independently as side cars. Each chunk carries the pre‑state it needs to execute statelessly and commits to its post‑state diff. Chunks are ordered but can be executed fully independently in parallel. CL commits to the set of chunk headers; sidecars carry bodies and inclusion proofs.\nValidation becomes more of a continuous stream.\nMotivation\nToday, blocks are large, monolithic objects that will become even larger in the future. Validation requires receiving the full block before execution can begin. This creates latency bottlenecks in block propagation and execution.\nAfter the block is received over the p2p network, transactions are executed sequentially. We cannot start validating while downloading or parallelize execution.\nTimeline showing today’s block validation bottleneck: full block download first, then sequential execution1100×580 29.3 KB\n\nMessages on the p2p layer are usually compressed using Snappy. The block-format of Snappy that is used on Ethereum cannot be streamed. Thus, we need to slice the block into chunks before compression.\n\nWith EIP-7928: Block-level Access Lists, the situation improves, but we’re still waiting for the download to finish before starting block validation. With 4 cores, we get the following Gantt chart:\nTimeline under EIP-7928: execution can use access lists but still must wait for block download1101×580 33.3 KB\nInstead, we can stream blocks as chunks:\n\nEach chunk contains ≤ 2**24 gas of transactions.\n\nOne could also have the chunk size increase geometrically (2**22, 2**23, …, 2**25) in gas. This would give us varying latencies for chunks, enabling better parallelization - but I’m not sure it’d be worth the complexity.\n\nTransactions remain ordered. Chunks are indexed and ordered, but independent of each other, so they can be validated in parallel. Still, the post-state of chunk 0 is the pre-state of chunk 1.\n(optional) Each chunk carries the state it needs to be executed statelessly.\n\nTimeline with payload chunking: chunks stream in and execute in parallel while downloading continues.1101×580 37.7 KB\nThis shifts validation from “download full block, then process” → “process while receiving the rest.”\n\nExecution Layer Changes\nWe extend the EL block format to support chunking:\nclass ELHeader:\n parent_hash: Hash32\n fee_recipient: Address\n block_number: uint64\n gas_limit: uint64\n timestamp: uint64\n extra_data: ByteList[MAX_EXTRA_DATA_BYTES]\n prev_randao: Bytes32\n base_fee_per_gas: uint256\n parent_beacon_block_root: Root\n blob_gas_used: uint64\n excess_blob_gas: uint64\n transactions_root: Root\n state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: Uint\n withdrawals_root: Root\n block_access_list_hash: Bytes32\n # New fields\n chunk_count: int # >= 0\n\nThere is no commitment to the individual chunks in the EL header. We only add the chunk count to it. The execution outputs (state_root, logs_bloom, receipts_root, gas_used) must be either the same as the value in the last chunk (applies to state root and withdrawals root), or the root after aggregating the chunk’s values (applies to transactions, receipts, logs, gas used, and the block access list).\nExecution Chunks\nChunks are never put on-chain; only their roots are committed.\nChunks contain the fields we would usually expect in the EL block body. Transactions are split up over chunks with a limit of 2**24 gas per chunk. Withdrawals must only be included in the last chunk. Mirroring block-level access lists, chunks come with their own chunk access list, and one could additionally add pre-state values to chunks, unlocking statelessness.\nclass Chunk:\n header: ChunkHeader\n transactions: List[Tx]\n withdrawals: List[Withdrawal] # only in chunk at index -1\n chunk_access_list: List[ChunkAccessList]\n pre_state_values: List[(Key, Value)] # optional\n\nEach chunk comes with a header including the chunk index. Transactions are ordered by chunk.header.index and their index in the chunk. Commitments to each chunk’s execution output are included in the header.\nclass ChunkHeader:\n index: int\n txs_root: Root\n post_state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: uint64\n withdrawals_root: Root\n chunk_access_list_root: Root\n pre_state_values_root: Root # optional\n\nTo prevent proposers splitting their blocks into too many chunks, the protocol can enforce that chunks must be at least half full (\\geq\\frac{chunk\\_gas\\_limit}{2}≥𝑐ℎ𝑢𝑛𝑘_𝑔𝑎𝑠_𝑙𝑖𝑚𝑖𝑡2) OR chunk.header.index == len(beaconBlock.chunk_roots) (= last chunk in that block).\n\nConsensus Layer Changes\nDiagram of consensus changes: beacon block tracks chunk roots while execution chunks propagate via sidecars.1180×593 91.5 KB\nBeacon blocks track chunks with new fields:\nclass BeaconBlockBody:\n ...\n chunk_roots: List[ChunkRoot, MAX_CHUNKS_PER_BLOCK] # SSZ roots of chunks\n\nclass ExecutionPayloadHeader:\n ...\n chunk_count: int\n\nThe CL receives the execution chunks from the EL via a new ChunkBundle container which includes the EL header and the chunks (=similar to blobs).\nThe CL computes chunk roots using SSZ’s hash_tree_root and puts them into the beacon block body.\nSidecar Design\nChunks are carried in sidecars:\nclass ExecutionChunkSidecar:\n index: uint64 # chunk index\n chunk: ByteList[MAX_CHUNK_SIZE] # Opaque chunk data\n signed_block_header: SignedBeaconBlockHeader\n chunk_root_inclusion_proof: Vector[Bytes32, PROOF_DEPTH]\n\nThe consensus layer ensures all chunks are available and properly linked to the beacon block body via Merkle proofs against chunk_roots (=similar to blobs).\nNetworking\nThe proposer gossips only the lightweight beacon block with commitments (chunk_count, chunk_headers_root) on the normal beacon_block topic, while the heavy execution data is streamed separately as ExecutionChunkSidecars across X parallel subnets (beacon_chunk_sidecar_{0..X}), deduped by (block_root, index).\nInitially, all nodes must subscribe to all subnets and custody all chunks. While this doesn’t reduce bandwidth/storage requirements yet, it enables the immediate benefits of parallelization. Partial custody can be added in a future upgrade once the basic mechanism is proven and/or zk-proving becomes viable.\nNetworking view: lightweight beacon block propagates fast, while heavy execution chunks are streamed across parallel subnets.1090×430 260 KB\nFork Choice\nFork choice requires that all sidecars are both available and successfully validated before a block is considered valid. The beacon block with the chunk_roots propagates quickly, but the block only becomes fork-choice eligible once every chunk has been received and inclusion-proven against the root. The beacon block still contains the EL header with all the necessary commitments (=committing to parent block and execution outputs). What we knew as block body on the EL stays empty in this design.\n\nBenefits\n\nStreaming validation: execution can start while other parts of the block are still downloading or busy loading from disk. Chunks are independent (if pre-state provided), or rely on the chunk-access list (with chunk-level state diffs) and the pre-block-state; multiple CPUs/cores can validate chunks simultaneously; distribute bandwidth usage over slot instead of beginning-of-slot bursts.\nStreamlined proving: ZK Provers can parallelize proving multiple chunks at the same time, benefiting from the independence of chunks.\nStateless friendliness: since a single chunk is smaller than a block, we might consider adding pre-state values such that there is no need for local state access. A practical middle ground is to include pre-state values only in chunk 0, guaranteeing that at least one chunk can always be executed while the node loads the state required for other chunks from disk into cache.\nFuture extensibility: clear path to integrate zk-proofs over chunks or going for sharded execution.\n\nDesign Space\nChunk Size\n2**24 gas (~16.7M) emerged as a natural chunk size:\n\nMax Transaction Size: As of Fusaka (EIP-7825), 2**24 is the max possible transaction size.\nCurrent blocks: 45M gas blocks naturally split into ~3 chunks, providing immediate parallelism\nFuture blocks: Scales well - 100M gas blocks would have ~6 chunks\n\nValidator\n\nExecution engine splits the block into chunks internally (opaque to CL) and passes them to the CL through an ExecutionChunkBundle.\nProposer wraps each chunk in a sidecar with inclusion proof. The proposer also computes the hash tree root of each chunk and puts them into the beacon block body.\nPublishing happens in parallel across all subnets\nAttesters wait for all chunks and validate them before voting\n\nBuilders\nProposers can publish chunks as they’re finished building, and validators can start validating them even before receiving the beacon block. Since chunks contain the signed beacon block header and an inclusion proof against it, one can validate (=execute) chunks as they come in, trusting their source (=proposer).\nOpen Questions & Future Work\nProgressive Chunk Sizes?\nThe idea of geometrically increasing chunk sizes (2**22, 2**23, …, 2**25) seems beneficial but adds complexity. The first chunk could be smaller (5M gas) with pre-state values for immediate execution, while later chunks are larger. This remains an area for experimentation.\nPartial Custody Path\nWhile the initial implementation requires full custody, the architecture naturally supports partial custody:\n\nNodes could custody only Y subnets out of X\nReconstruction mechanisms (similar to DAS) could recover missing chunks\n\nCompatible with ePBS and Delayed Execution\nAt first glance, the proposed design seems compatible with both EIP-7732 and EIP-7886. Under ePBS, the chunk roots would likely move into the ExecutionPayloadEnvelope, and we’d put an additional root over the chunk roots into the ExecutionPayloadHeader. The PTC would not only have to check that a single EL payload is available, but that all chunks are. This is not much different from blobs.\nThe advantages of block chunking and independent validation scale with higher gas limits and may contribute to reducing spikiness in node bandwidth consumption.\n\n Toward Semantic Block Chunking\n\n BALs for Proposer Commitments\n\n Integrated in-protocol distributed history and state storage\n\n Blocks Are Dead. Long Live Blobs\n\n 5\n\n read \n\n 10\n min\n\n post by daniellehrner on Sep 1, 2025\n\n daniellehrner\n\n I really like this proposal.\nI think there could be further changes that not only allow streaming during execution, but during block building as well:\nToday the whole network, except for the block builder, stands still until the builder has constructed the full block and has calculated the state root hash. This is true even with this proposal.\nIt might be possible to allow the builder to stream the transactions before the full block is constructed. The builder could construct a header that only contains a subset of the fields today which are known before building the block:\n\nPREVRANDAO\nBLOCKNUMBER\nTIMESTAMP\netc\n\nAfter that it could start to add the transactions and send them to its peers once that a chunk is full. This would decrease the time to first byte, because the builder could send chunks before the full block is ready.\nOnce the block is fully built the builder could send a footer which contains the missing fields like:\n\nBLOCKHASH\nSTATEROOT\nRECEIPTSROOT\netc.\n\nI think there are mainly 2 downsides:\n\nBALs don’t work anymore in their current form. We could convert them into chunk level access lists, but most probably increase bandwidth requirements\nBlock validation is split into two steps: validating the fields in the header → execute transactions-> validate fields in the footer. But payload chunking in its current form requires that the block hash in only validated after all the chunks have been received.\n\n post by Nero_eth on Sep 2, 2025\n\n Nero_eth\n\n Yeah, this is interesting!\nI don’t think moving from block-access lists to chunk-access lists would be a major issue. The objects themselves get smaller, we gain parallelization, and there’s even room to increase the size of individual objects (for example, supporting statelessness).\nIn the block chunking proposal, the idea is similar: chunks can be published earlier than the EL header. Each chunk can be validated independently, and once they’re all validated, only the aggregate execution outputs need to be checked. At that stage, the EL header is required, but not before, since it only contains the chunk count and no other chunk-specific information.\n\n post by raulk on Sep 8, 2025\n\n raulk\n\n Promising proposal! I support the general direction, and I think we should let the builder side stream too. That keeps progress steady and incremental across the slot and reduces peak system requirements on builders (especially important for local builders as we increase gas limits and shorten slot times).\nMore concretely, this is what I’m thinking.\nMake streaming first class. I’d avoid committing to the total chunk count upfront, or to specific chunk contents. Let builders emit a chunk as soon it hits a gas budget, up to the relevant protocol caps (block gas limit, max chunks). Use either a closing trailer, or a per-chunk “last” marker. I lean towards the trailer: it keeps final commitments tidy and encapsulated. Header and trailer are small, so we can broadcast them more aggresively (e.g. higher fanout).\nBuilder pipeline. Parallelize chunk production by saturating all available CPU cores. Run one EVM per core with shared conflict detection; pin instances to OS threads if useful. Route transactions based on tx-level access list. Use speculative execution, potentially with copy-on-write snapshots to migrate a conflicting inflight transaction to another chunk on conflict (e.g. OverlayFS style). Keep shipping chunks as they’re ready. Do not wait for the full set. When the block gas limit is hit, merge pending EVMs, finalize outputs, and dispatch the final chunks. There’s probably work from the Parallel EVM world that becomes very relevant here.\nValidator pipeline. Execute chunks as they arrive. One EVM per chunk, with shared conflict detection to reject the block on conflict (or validation against chunk-level access lists, or prestate, as you mentioned). This matches the original proposal.\nCommitments. Treat some execution payload fields as placeholders that the trailer fills in; namely those dependent on the post-state: transactions_root, state_root, receipts_root, logs, etc. Put chunk commitments and chunk count in the trailer, together with the final proposer signature. Because the block continues being atomic, the chain can be spared of chunking details. I’d think of the chunked form as virtual during transit, which is then collapsed into a single committable block when appending to the ledger. If useful, we can persist chunk boundaries and metadata off-chain for P2P RPC and checkpoint sync, but not necessarily in the canonical structure.\nNetworking. Independent chunking is a win if overhead stays low. It allows parallel propagation across subnets and smoother bandwidth profiles across the slot.\nChunk authentication without a fixed count. All chunks are signed by the proposer. Proposer equivocation rules probably need to adapt. To strengthen the model, we can carry a running accumulator in each chunk header, and have the trailer commit to the final accumulator. Validators receiving chunks out of order can still validate taking the risk with some configured tolerance.\nMental model. This looks like MapReduce at the EVM level. Builders map transactions into independent execution units under conflict detection. Validators reduce by merging verified, non-conflicting results in order.\n\n post by preda-devteam on Sep 9, 2025\n\n preda-devteam\n\n This is inspiring and enlightening \nStreamlining block reception and execution would be a smart move now that BALs are paving the way for many improvements.\nAdditionally, I’d like to delve into the specifics of parallel execution and the adoption of a Parallel EVM that partitions data/state architecture—something I’ve been working on. I have two questions regarding your proposal:\n\nValidator/Parallel Execution\nWith BALs, we’ve set the stage for parallel execution—essentially a pessimistic approach to parallelization. Is this the kind of parallel execution you’re envisioning?\n\nOnce a block chunk is received by a validator, BALs provide insight into the read/write list, allowing conflict-free transactions to be executed in parallel across the validator’s multiple cores. This mechanism is similar to the pessimistic-parallel execution employed by other chains. With BALs in place, there’s significant potential to maximize parallelism and reduce state conflicts.\n\nNetworking/Partitioning Possibilities\nYou mentioned the future possibility of “partial custody,” where subnet nodes would only manage a fraction of the data. This got me thinking about the broader direction of partitioning across communication, storage, and execution. Do you see Ethereum’s future leaning more towards full sharding (partitioning across all three dimensions) or partial sharding (partitioning across one or a subset)?\n\nA key advantage of partitioning would be overcoming the limitations of computational power in a single VM, the real opportunity here is to leverage the total processing power of the entire network. This would allow Ethereum’s performance to scale as the number of nodes increases.\n\n post by Nero_eth on Sep 9, 2025\n\n Nero_eth\n\n Great comments, thanks!\n\nYeah, totally agree and I’d say this is already supported with the chunking approach. For DoS resistance, validators need a way to verify a chunk is signed by the rightful proposer of that slot, and this is possible with the sidecars containing the signed_block_header. Even though one cannot yet validate the inclusion proof, validators could still already start executing, delaying the inclusion proof until the beacon block is received.\nMy feeling is that this might be good enough and we would not need a commitment to the chunks different from the proposer’s signature to start processing. The beacon block essentially becomes the trailer\n\n post by Nero_eth on Sep 9, 2025\n\n Nero_eth\n\nYou get perfect parallelization. No need to separate tx into non-conflicting batches. With EIP-7928, every transaction can be executed independently of another.\n\nWhile I agree that this is an interesting concept, it feels like we’re still kinda far from such a world. DAS, as done with blobs is a great role model for what we should strive for on the EL as well. zkVMs will further change how we think about related concepts, so, still rather difficult to tell how things evolve. Execution sharding has huge potential for scaling and is definitely on the list.\n\n 10 days later\n\n post by gballet on Sep 19, 2025\n\n gballet\n\n That has potential, but I do see a lot of issues as well.\nThe Bad\n\nThe obvious one is complexity: Chunks need to travel over the network and be executed in due time. Under normal conditions, I think it’s to be expected that the validators will execute these Chunk optimistically and wait for the next, but if for whatever reason the chunks are not being distributed, the rational thing to do will be to wait for all the chunks to be downloaded anyway so that they can be executed in parallel. And if that is the case, then why not simply give a single block and add the same information to allow for chunk execution in parallel without having to distribute the data over the network and gope that the recipient will collect all the pieces in time?\nIt is much faster to download a big chunk of data than many many small bits and pieces. To be seriously considered, this proposal should effectively make some measurements as to how much time is saved executing in parallel, and in what kind of load. I don’t believe it’s unrealistic to expect that the execution will be spending most of its time waiting on the data to end up downloading, then immediately execute the chunk and wait for the next one. In particular, it should be explained why this is a better approach than simply packaging the transactions in such a way that you could start executing as the data is being downloaded.\nThis is yet another proposal that increases the bandwidth requirements and also puts a lot of work on the proposer to hash the work for the validators.\nI do not think it will help the ZKVM approach at all, in the sense that proving is very slow and so you will lose all the benefits of parallel proving. I understand that the end goal would be to have carious entities on the network working on a single chunk at a time and sharing them over the network, with the execution being proven in parallel by the validator without even needing to download the chunks. But there is the problem of whom commits to building these proofs? The builder itself will not be able to provide any commitments that these proofs are correct.\nIn the case when most txs depend on each other, e.g. sandwiching blocks, your chunks are going to be very small.\nI might be missing something on the CL side, but it seems to me that this is very susceptible to Spamming because one could simply spam a lot of chunks even if they are not part of the block. How is the executor supposed to know the connection between the chunks and the block, if no commitment is made? The sidecar would require some hefty proving, which a simple hash could do instead.\n\nSo in summary, I think proper research should be conducted in order to find out if this is really worth the complexity.\nThe good\nI think most of the potential comes from the idea that blocks could actually be produced by many builders at the same time, and this is a good first step for this to happen. In a way you could represent this as inclusion list being just actual execution instead of a list of instructions, and if for whatever reason they are not executable, then they are still part of the block, but they are not canon.\nSo in my view as such it doesn’t bring very much, but if we could somehow make it also a way to share building between many clients and many nodes, then this would have really the potential to make a dent in terms of scalability.\nQuestion\n\nWhy are withdrawals included in a chunk? They could still be part of the block and be optimistically executed in parallel instead of waiting for the last chunk, I doubt there will be people trying to use their withdrawal address in the same block as the withdrawal, and if this happens, it can be easily worked around.\n\n post by Nero_eth on Sep 19, 2025\n\n Nero_eth\n\n Thanks for the questions and feedback!\n\nThis is what Block-Level Access Lists already give you, in combination with EIP-7825 (the tx gas limit of 16.77M). Each transaction is executable fully independently from another, thus, if you wait for all chunks to be downloaded just to then start executing chunks in parallel, then you arrive at where we’re at with BALs. The only way to improve on this would be by enabling validators to start executing earlier, even before everything is received.\n\nYeah agree, measurements are needed. In any case, this would speed up the “time to validation” for validators, independently if builder make use of the smaller chunks and actually publish them earlier, or if they wait until the last second. Since the absolute size of the object you need to download is smaller (much smaller if you compare 16.77M (=chunk size) to 60M or 100M (=future block gas limit)). The smaller object will propagate faster, shortening the time from beginning of propagation to beginning of validation.\n\nTrue but only marginally (a few 32 bytes values that were in the block header are now in all chunk headers; maybe a few hundred bytes overhead) but in return we have a less spiky bandwidth usage over the slot. Also, I keep hearing that our gossip network was never created with the intent of sending around large messages ( cc @raulk, @MarcoPolo), and with increasing gas limits, we have no other option on the table to somehow limit message sizes.\nIf we have chunks being statelessly validatable, we’d ensure that they are executable independently from the order in which you receive them. This would add a lot of data on top, I agree but maybe, if we don’t make them stateless (like mentioned in the post) but instead require validators to have full state, then we still get the benefits of being able to independently download but then you can only execute the second chunk if you already have the first (using it’s chunk-level access list).\nAnother alternative would be to have the chunk access list travel as a sidecar too, exclusively providing state updates to validators, whereas the chunks with the actual data travels independently.\n\nMore like, have various entities work on different chunks, but since this proposal doesn’t affect builder or prover economics, we might just not care to much about it at this point. Validators would still need to download all chunks.\n\nNote that transactions distributed over chunks still enjoy the same atomicity as if they were in the same block. We could enforce that chunks must always be at least 1/2 full (measured in gas used), otherwise invalid. Thus, you can do a sandwich starting in chunk 0 and finishing in chunk 1. The post state root of the last tx in chunk 0 is the pre state root of the first transaction in chunk 1.\nThe proposal doesn’t really focus on builders and provers but on validators and how we could relief them from work in the critical path.\nLet’s assume there are no provers yet (which is true today) and builders play timing games until the last possible second. Even then, validators would profit by being able to parallelize between validating the first chunk while downloading the rest. Builders can publish_ chunks earlier, just like provers can provide proves for chunks without seeing the full block, but this is a different topic.\nMy argument is that if we don’t chunk things in-protocol, then we may just increase the time of everything (upload, download, validation) linearly without having any way to parallelize between the 3.\n\nBlocks on the EL wouldn’t exist anymore, just chunks and a header. Today, withdrawals are applied after executing all transactions. We could enforce that only the last chunk is allowed to contain withdrawals and then process them just like today.\n\n Powered by Discourse","tokens":6665,"squid":"ink-research","role":"Deep Scholar","at":1791262752820,"hash":"a64e93a57cef4e48ec34ca5e9b439a9d6e399e84"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Historical Price Feed in 03/01/2023 \n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 1 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 5, 2025\n\n post by makimakiver on Sep 5, 2025\n\n post by KemarTiti on Sep 6, 2025\n\n post by makimakiver on Sep 6, 2025\n\n post by KemarTiti on Sep 9, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1527,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262764370,"hash":"b9fefe05709e2e9941ed3b1d0a758b3cd8fd0eee"}
{"url":"https://forum.openzeppelin.com/t/how-to-put-the-price-0-0000001-10-6-uint256-does-not-accept-0-1/36240/4","domain":"forum.openzeppelin.com","title":"How to put the price 0.0000001$ *10^6? (uint256[]) does not accept 0.1 - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n May 2023\n\n 4 / 7\n\n May 2023\n\n May 2023\n\n post by 213101 on May 15, 2023\n\n 213101\n\n I want to set the price of the token to 0.0000001$ (in USDT)\nFor this I take 0.0000001*10^6 = 0.1\nI am getting an error.\ninvalid BigNumber string (argument=\"value\", value=\"0.1\", code=INVALID_ARGUMENT, version=bignumber/5.1.1)\nHow to insert 0.1 correctly?\n\n 4\n\n 3\n\n post by barakman on May 15, 2023\n\n barakman\n\nNo, 0.0000001*10^18 = 10^11.\n\n post by 213101 on May 16, 2023\n\n 213101\n\n invalid number value (arg=\"_prices\", coderType=\"uint256\", value=\"10^11\")\n\n post by barakman on May 16, 2023\n\n barakman\n\n Dude, I was trying to explain to you, using pure mathematical notation (i.e., not solidity code), that 0.0000001 times 10^18 is not equal to 0.001, but rather, to 10^11, which is of course an integer value, representable by a uint256.\nIn short, what you need to do, is to pass something like BigNumber.from(\"100000000000\").\nOr perhaps BigNumber.from(10).pow(11), or even BigNumber.from(\"10e11\").\nIt really depends on what BigNumber implementation you're using.\nBut following your original question, as well as your response to my answer, I believe that you might wanna study some basic programming concepts before jumping to smart contracts.\n\n post by 213101 on May 16, 2023\n\n 213101\n\n I just need to put one correct value.\nhere is my contract.\n\nupdateTokenRate (0x3115329e)\n\n post by barakman on May 16, 2023\n\n barakman\n\n Like I said, the value of 0.0000001*10^18 is 10 to the power of 11 (i.e., \"one followed by 11 zeros\").\n\n post by 213101 on May 16, 2023\n\n 213101\n\n sorry. I made a mistake. I need 0.0000001*10^6 = 0.1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale set rate for 9 decimal\n\n Support\n\n crowdsale\n\n 2\n\n 628\n\n Apr 2021\n\n Error: invalid BigNumber string\n\n Contracts\n\n 1\n\n 1.3k\n\n Oct 2021\n\n Going insane over Token pricing\n\n Support\n\n erc20\n\n 2\n\n 598\n\n Jun 2021\n\n Setting up my crowdsale rate\n\n Smart Contracts\n\n crowdsale\n\n 1\n\n 951\n\n May 2022\n\n Invalid BigNumber value for string\n\n Smart Contracts\n\n erc721,solidity\n\n 1\n\n 227\n\n Jun 2024","tokens":550,"squid":"ink-security_audits","role":"Sentinel","at":1791262771522,"hash":"6a2bcd97b3b2f831797d89a6913992064a7168e8"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/2","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 2 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1981,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262777164,"hash":"1d49ea87b1d0c75d200468606012f6bbcb7fbba3"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/5","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 5 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1981,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262787951,"hash":"cd5877f6934b4eb62c5b818cf5b41f9cd2d684de"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/8","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 8 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1981,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262799831,"hash":"42bf82e1e8e9334b51891313825d64de2d52b210"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/10","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 10 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1982,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262811927,"hash":"486ce4c7d1ac07024a87a1a810103b4ea043914b"}
{"url":"https://dev-forum.pyth.network/t/cant-fetch-historical-prices-with-pyth-terminal-api/809/1","domain":"dev-forum.pyth.network","title":"Can't fetch historical prices with Pyth Terminal API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Can’t fetch historical prices with Pyth Terminal API \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Jul 13\n\n 1 / 12\n\n Jul 13\n\n Aug 5\n\n post by Shawn on Jul 13\n\n Shawn\n\n Hey, I subscribed to the Pyth Terminal Starter plan a few days ago, but since upgrading, I have been unable to retrieve historical prices correctly through the authenticated v2 API.\nFor example, I request data for Unix timestamp 1717632000:\ncurl -X 'GET' \n'https://pyth.dourolabs.app/hermes/v2/updates/price/1717632000?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43' \n-H 'accept: application/json' \n-H 'Authorization: Bearer MY_API_TOKEN'\n\nInstead of returning the price published around the requested timestamp, the response contains a recent publish time—approximately three hours before the request. For example, one response returned 1783937703. Each time I call the endpoint, the publish time changes while remaining roughly three hours behind the current time.\nHowever, the unauthenticated v1 API returns the correct historical publish time for the same timestamp and price-feed ID:\ncurl -X 'GET' \\\n 'https://benchmarks.pyth.network/v1/updates/price/1717632000?ids=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&encoding=hex&parsed=true' \\\n -H 'accept: application/json'\n\nCan you explain why the paid Starter plan’s v2 endpoint is not returning the requested historical price, while the v1 endpoint works correctly? Historical price access was one of the reasons I subscribed, so I would appreciate either instructions for the correct paid endpoint or confirmation that this is a bug that will be fixed.\n\n 6\n\n 4\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Hey Shawn,\nThe endpoint in your example is the Hermes/Pyth Core-compatible API: pyth.dourolabs.app/hermes/v2/updates/price/{publish_time}\nFor Pyth Terminal historical data, please use the Pyth Pro History API instead:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/history?symbol=Crypto.BTC/USD&from=1717632000&to=1717718400&resolution=60”\n\nIf you need point-in-time prices:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/price?ids=1&timestamp=1717632000000000”\n\nNote: benchmarks.pyth.network is the legacy Pyth Core historical endpoint and is being deprecated. Please use Pyth Pro going forward (Preparing for the Pyth Core upgrade | Pyth Developer Hub).\n\n post by Shawn on Jul 13\n\n Shawn\n\n Thanks for your reply.\nI believe the information on the Preparing for the Pyth Core upgrade | Pyth Developer Hub page caused some confusion. It states that an API key will be required by July 31 and that using an API key requires upgrading to the Pyth Pro API. However, the page links to the older Pyth Core/Hermes documentation, which led me to believe that the API key and paid plan applied to those endpoints as well.\nThat is why I misunderstood how the paid API was intended to be used. It may be helpful to update the page or clarify the distinction between the older Hermes endpoints and the Pyth Pro API.\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n The API key requirement is for continuing historical price access through Pyth Pro. The older Pyth Core/Hermes historical endpoints are legacy and will be deprecated, so new integrations should use the Pyth Pro /v1/{channel}/price or /v1/{channel}/history endpoints instead.\n\n post by Shawn on Jul 14\n\n Shawn\n\n Hey just want to ensure, the examples you provided above doesn’t include data that I can sent to smart contract for on-chain verification. If I need that, should I call API like this?\ncurl -X POST https://pyth-lazer.dourolabs.app/v1/price -H \"Authorization: Bearer ***\" -H \"Content-Type: application/json\" -d '{\"priceFeedIds\": [1, 2],\"properties\": [\"price\", \"exponent\", \"publisherCount\", \"confidence\"],\"formats\": [\"evm\"],\"jsonBinaryEncoding\": \"hex\",\"channel\": \"fixed_rate@50ms\",\"timestamp\": 1758690761750000}'\n\nPlease notice that the domain is pyth-lazer. I’m just wondering if this way is valid after July 31 since we want to migrate without any downtime.\n\n post by Shawn on Jul 14\n\n Shawn\n\n KemarTiti\n\n Hello,\nI’m becoming increasingly confused by the documentation, as it does not clearly explain how to satisfy what seems like a straightforward use case.\nMy requirement is to retrieve the price data for a specific historical timestamp in a hex-encoded format, then submit that data to my existing EVM smart contract for on-chain verification.\nAfter reading the documentation several times, my understanding is that using the Pyth Pro API would require my smart contract to integrate with or migrate to the Pyth Lazer contracts. That would be a contract-level integration change, not simply an API endpoint upgrade.\nCould you please clarify the simplest supported way to do the following?\n\nRequest the price for a specific historical timestamp.\nReceive the corresponding signed, hex-encoded price update data.\nSubmit that data to an existing EVM smart contract for verification.\n\nIs this possible using the standard Pyth contracts, or is migrating to Pyth Lazer mandatory?\nThe current documentation makes the relationship between the Pro API, historical price retrieval, and the required on-chain contracts unnecessarily difficult to understand. A direct example covering this exact workflow would be very helpful.\nThanks.\n\n post by KemarTiti on Jul 14\n\n KemarTiti\n\n yes, for signed payloads that can be submitted on-chain, you should use the Pyth Pro REST endpoint: https://pyth-lazer.dourolabs.app/v1/price\nwith formats: [\"evm\"] and jsonBinaryEncoding: \"hex\", like in your example.\nImportant distinction: that evm payload is for the Pyth Pro/Lazer EVM contracts. It is not a drop-in replacement for the legacy Pyth Core/Hermes payload used by existing Pyth Core EVM contracts.\n\n post by Shawn on Jul 14\n\n Shawn\n\n Thanks for the reply. it’s clearer now. I just want to confirm again: to use that payload, do I need to update and migrate my smart contract to Pyth Lazer compatible version as you mentioned, correct?\nAnd also, why can’t I see the Ethereum mainnet address from the Pyth Pro contract list?Contract Addresses | Pyth Developer Hub\nHow do I use the payload on Ethereum mainnet without an contract address?\n\n post by KemarTiti on Jul 14\n\n KemarTiti\n\n If you want to use the Pyth Pro evm payload from POST https://pyth-lazer.dourolabs.app/v1/price, then your smart contract needs to integrate with the Pyth Pro/Lazer EVM contract interface.\nThat payload is not compatible with the Pyth Core updatePriceFeeds(...) interface.\nFor Ethereum mainnet today, you should use the upgraded Pyth Core path instead:\n\nFetch the Core-compatible update from upgraded Hermes: https://pyth.dourolabs.app/hermes\nSubmit the returned update.binary.data to the upgraded Pyth Core contract using the normal updatePriceFeeds(...) flow.\n\nUpgraded Pyth Core contract addresses: Upgraded Contract Addresses | Pyth Developer Hub\nPyth Core EVM upgrade guide: EVM | Pyth Developer Hub\nThe Pyth Pro/Lazer contract-address page does not currently list Ethereum mainnet, so the Pyth Pro evm payload is not usable as is on Ethereum mainnet today. The day Pyth Pro contract is on Ethereum mainnet, it would.\n\n post by Shawn on Jul 14\n\n Shawn\n\n Thanks for the clarification. I now understand that the Pyth Pro/Lazer payload is not compatible with existing Pyth Core contracts and that Pyth Pro/Lazer is not currently available on Ethereum mainnet.\nHowever, this leaves a gap for existing Ethereum mainnet users who need to retrieve signed historical prices and submit them through the standard Pyth Core updatePriceFeeds(...) flow. The upgraded Hermes endpoint appears to provide only recent data, while the legacy Benchmarks API can retrieve much older historical updates.\nWould it be possible to add historical price support to the paid Pyth Core-compatible API? Ideally, it would:\n\nSupport historical timestamps older than three hours.\n\nReturn signed payloads compatible with Pyth Core updatePriceFeeds(...).\n\nWork with existing contracts on Ethereum mainnet without requiring a migration to Pyth Pro/Lazer.\n\nI subscribed to the Starter plan expecting it to provide a migration path for this existing historical-price workflow. It would be very helpful if the paid API could retain the functionality currently available through the legacy Benchmarks endpoint.\n\n post by Aditya520 on Jul 14\n\n Aditya520\n\n I see the confusion, and we are working to fix it in the docs as well.\nWe have upgraded Core contracts on Ethereum mainnet here.\nIf you use these APIs to fetch the signed payload, you will be able to parse the prices on the above Ethereum and other chain Upgraded Core contracts.\nYou can not use the old hermes data on the new upgraded Core contracts.\nIn regards to historical data in the new hermes data, I will follow up and give you more light soon.\n\n 21 days later\n\n post by PythUser on Aug 5\n\n PythUser\n\n KemarTiti\n\n Hey KemarTiti, if possible could you respond to this query. I understand this is not the right place to flag this, however I have not gotten a response on this since quite some time:\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 191\n\n Jul 13\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n How to get more historical data faster?\n\n Benchmarks(Historic Prices)\n\n 3\n\n 585\n\n Sep 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":3323,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262822844,"hash":"400326aa01d69c12ef47ac4670d7738ac8d8e999"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvWwSO3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJvwMxu3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJTL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4Mjc2NTkzMTc5LVdoeS1hcmUtdGhlcmUtMi1kaWZmZXJlbnQtVVNEQy1zLW9uLUFyYml0cnVtBjsIVDoJcmFua2kG--6a5990f866214bd960810b8ad0f75740c63a7e0b","domain":"support.arbitrum.io","title":"Why are there 2 different USDC's on Arbitrum? – Arbitrum Foundation","text":"Understanding native vs. bridged\nNative USDC is officially issued by Circle and always redeemable 1:1 for US dollars.\nIn the case of Arbitrum, there also exists a “bridged” form of USDC, known as USDC.e, that’s been bridged from Ethereum. USDC.e is not issued by Circle.\n\nNative USDC on Arbitrum:\n\nToken Name: USD Coin\nToken Symbol: USDC\nToken Address: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n\nBridged USDC on Arbitrum: (from Ethereum)\n\nToken Name: Bridged USDC\nToken Symbol: USDC.e\nToken Address: 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8\n\n Recently viewed articlesWhy wait 7 days to claim funds when bridge to Ethereum?Skipping the bridgeUsing Arbitrum's traditional bridge to move funds to MainnetBridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n How can I add Arbitrum network to my wallet?\n\n You need ETH to power transactions\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Please sign in to leave a comment.","tokens":271,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262845324,"hash":"e5f02ddd0d9ace17dc37fb569c1a8fdb4bf5f9e0"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18213771832987-Skipping-the-bridge","domain":"support.arbitrum.io","title":"Skipping the bridge – Arbitrum Foundation","text":"You may want to skip bridging if\n\nYou already have funds sitting in a centralized exchange (CEX)\nYou don’t have enough funds in your L1 and want to “top up” your balance via a centralized exchange or fiat on-ramp\n\nWhen you go to transfer funds from your centralized exchange of choice, you’ll have the option to move your funds directly to Arbitrum instead of to Ethereum.\nFor fiat on-ramps, you’ll select Arbitrum directly.\nHow do I choose between a centralized exchange and a fiat on-ramp?\nIf we’re being precise, CEXs are technically also fiat on-ramps. They allow you to on-ramp your fiat currency, or to use your bank account to get crypto. CEXs generally are given their own category because they also store crypto assets. Other fiat on-ramps don’t store any assets, they just immediately transfer your funds to a crypto wallet.\nCEX’s are typically larger and have more oversight. That doesn’t mean they are incorruptible or hack-proof but they do have more eyeballs on them watching to make sure they don’t steal your funds.\nBoth require you to submit some personally identifiable documentation. This is called KYC (Know-Your-Customer). The government requires this from them.\nTo decide which one you want to use, it’s best to read into (1) what their fees are and (2) how legitimate they are in the community and how trusted they are.\n\n Recently viewed articlesWhy are there 2 different USDC's on Arbitrum?Why wait 7 days to claim funds when bridge to Ethereum?Using Arbitrum's traditional bridge to move funds to MainnetBridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Bridging over a new token\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n Please sign in to leave a comment.","tokens":473,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262860555,"hash":"4dcdf1525cdb139804dbfea905e12d08b24d79ff"}
{"url":"https://governance.aave.com/t/migrate-from-v4-main-vault-to-bluechip/25273/7","domain":"governance.aave.com","title":"Migrate from V4 Main vault to Bluechip - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n read \n\n 4\n min\n\n Jul 4\n\n 7 / 10\n\n Sep 14\n\n Sep 21\n\n post by Zataoka on Jul 4\n\n post by stani on Jul 4\n\n post by MconnectDAO on Jul 5\n\n 16 days later\n\n post by Zataoka on Jul 22\n\n 2 months later\n\n post by Zataoka on Sep 9\n\n post by defi_milos on Sep 9\n\n defi_milos\n\n Hi Zataoka!\nI’m part of the DeFi Saver team, so just wanted to drop by and offer some suggestions, along with explanations on how the migration process works.\nOur Loan Shifter tool is indeed available for moving positions from one Aave v4 market to another, so it can definitely take care of migrating your position from the v4 Main to the v4 Bluechip Spoke.\nThe only limiting factor (currently) is if your v4 position is on an EOA and not a Smart Wallet. Currently, Loan Shifter only works for positions on a Smart Wallet - but we’ll soon make it compatible with EOA positions as well.\nSo, if your position is indeed on an EOA at the moment - you’ll be able to move it via Loan Shifter in about a week or so (when we release the Loan Shifter updates).\nAs a quick sidenote, here’s how Loan Shifter performs the move atomically:\n → It flash loans all of the required debt to clear your v4 Main position’s debt\n → It withdraws the collateral\n → It supplies that collateral to the v4 Bluechip market\n → Borrows the debt asset\n → Uses it to pay back the flash loan\nIn case your position is on a Smart Wallet, you should be able to perform the move by:\n\nAccessing Loan Shifter\nUnder “From Position”, click it and it should bring up all of your positions (including the v4 Main one)\nUnder “To Position”, type in “Bluechip”, and it’ll let you select the Aave v4 Bluechip market as the destination.\nClick “Shift”\n\nAnd that’s all the required steps to get your loan moved from one market to the other.\nWill write a follow-up comment here as soon as the EOA update is live, or you can drop by our Discord/Twitter to also get notified as soon as we announce it.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Hello Milos.. thank you so much for taking the time to give me that detailed answer, I truly appreciate it.\nI have always used Defisaver, btw. So, have great appreciation for the work your team does.\nMy 2 positions are both on Smart Wallets (at least, that’s what it says). It does not say EOA.\nHowever, I do NOT see the loan shifter there (only see collateral shift, debt shift and position flip). Not sure what I am doing wrong. Here is the ETH address for 1 of my positions. 0xd9bc3cbc14df4d9f2e94edafaa9b9ea68a42a014\nCan you please check this out and let me know why I am unable to see it?\n\n post by defi_milos on Sep 14\n\n defi_milos\n\n You’re very welcome Zataoka! Also appreciate your kind words for the DFS app :)\nGood news that your positions are on a Smart Wallet.\nLoan Shifter shows up under the “Shift” tab only on Aave v3 currently, but we’ll make sure it’s also included on the v4 dashboard soon!\nInstead, you can find the Loan Shifter option from the menu on the left-hand side of the app - just under the “Exchange” tool.\nOnce you’ve opened it, if it’s not already pre-selected, please choose your Main v4 position in the “From position” section. Then, you’ll choose “Bluechip” in the “To position” section.\nImportant note: The position you shared has multiple collateral and debt assets, so I would mention that Loan Shifter won’t be able to move it all in one transaction.\nInstead, it’ll require a couple. The best option I found is:\n\nTransaction 1: Move all of your WBTC and your USDT debt to the Bluechip market first. This is the best course of action since WBTC makes up most of your position, so it’ll let you move all of the USDT in one transaction. For example if you try to move your wstETH and USDT, there won’t be enough wstETH collateral to support moving all of the 300k+ USDT. By moving WBTC and USDT first, you’re taking care of that in one-tx\nTransaction 2: Move all of your wstETH and your USDC debt to the Bluechip market. Even though it’s two separate Loan Shifter transactions, it’ll actually add the wstETH collateral and USDC debt on top of your newly moved WBTC/USDT Bluechip position\nTransaction 3: Since all of your debt has moved to the Bluechip market now, you can simply withdraw your remaining LINK and ETH collateral, then supply it to the position again on Bluechip\n\nLet me know if this is clear enough. You can also contact me by writing directly through the DFS app, where I’d be more than happy to provide a step-by-step guide with screenshots on how to get the process done.\nP.S. - You can also do the entire move in our Simulation Mode first - confirm that everything works (and that you’re comfortable with the flow), and only then re-do it on the live mode.\n\n post by Zataoka on Sep 14\n\n Zataoka\n\n Thanks Milos.. I was able to do the switch and it all went smoothly. Appreciate it.\nLet me ask you a couple of questions, if I may\n\nWhy is there such a huge difference in borrowing costs between USDT on the Core vs. Prime hub? I moved my debt to USDT on the core hub and the interest rate there is 10.6% vs. 4.05% (core vs. prime).\nBecause of the above, I am trying to do the debt switcher to Prime (from Core) but it doesn’t let me do that.\nI have retained some portion of the debt with all my LINK as collateral on V4 Main.. hope that is fine? Or should I be removing that you think, given LINK isn’t a collateral asset on Bluechip.\n\n post by defi_milos on Sep 21\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave v4 - Safe to move my positions?\n\n New Market\n\n 1\n\n 399\n\n Apr 23\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Deploy Aave V4 on Arc\n\n New Market\n\n 9\n\n 912\n\n Sep 18\n\n [ARFC] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Jul 11","tokens":1479,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262860637,"hash":"7c16a269d49fe69170bbc95881d2c95f05c05475"}
{"url":"https://support.arbitrum.io/hc/en-gb/profiles/17837037997595-fred","domain":"support.arbitrum.io","title":"User profile for fred – Arbitrum Foundation","text":"When you are bridging over a new token, that action will require an approval transaction fee.\nThis goes to Ethereum block producers, not to Arbitrum.\nThe approval transaction only applies once per ...\n\n fred\n\n 3 years ago\n\n 3 followers\n\n 0 comments\n\n 0 votes\n\n When moving funds from Mainnet (L1) to Arbitrum (L2), you'll need ETH in your Arbitrum wallet.Even if you want only to use another, non-ETH, token, you will still need a small amount of ETH in your...\n\n fred\n\n 3 years ago\n\n 5 followers\n\n 0 comments\n\n 1 vote\n\n If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fas...\n\n fred\n\n 7 days ago\n\n Updated\n\n 12 followers\n\n 1 comment\n\n 1 vote\n\n You may want to skip bridging if\n\nYou already have funds sitting in a centralized exchange (CEX)\nYou don’t have enough funds in your L1 and want to “top up” your balance via a centralized exchange ...\n\n fred\n\n 3 years ago\n\n 1 follower\n\n 0 comments\n\n 1 vote","tokens":262,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262870907,"hash":"eda3c57f992a0d6b90acb0d370273b5a9220385c"}
{"url":"https://governance.aave.com/t/arfc-aave-will-win-framework/24352/1","domain":"governance.aave.com","title":"[ARFC] Aave Will Win Framework - Governance - Aave","text":"[ARFC] Aave Will Win Framework \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 1. Summary\n\n 2. Aave Labs Commitment\n\n 3. Motivation\n\n 4. Specification\n\n Aave Product Revenue to the DAO\n\n Aave V4 and V3 Maintenance\n\n Expanding Revenue Through Aave V4\n\n The Aave Brand and Intellectual Property\n\n Technical Roadmap and Expanded Responsibilities\n\n DAO Growth Requires Resources at Scale\n\n Aave Labs Funding Request\n\n Accountability Framework\n\n 5. Next Steps\n\n Disclaimer\n\n Copyright\n\n Mar 26\n\n 1 / 25\n\n Mar 27\n\n Apr 16\n\n post by AaveLabs on Mar 26\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Cover1920×1080 202 KB\n1. Summary\nAave began with the thesis that decentralized lending could play a major role in traditional finance. Eight years later, that thesis has been validated. Aave is the largest protocol in decentralized finance, commanding a 60% market share in lending. The opportunity ahead, however, is bigger than anything behind us.\nDetailed below is a strategic framework proposal for Aave’s next chapter. It is the result of extensive community discussion during the Temp Check phase and incorporates significant feedback from DAO stakeholders.\nIt proposes to direct revenue from Aave-branded products to the DAO treasury and to establish a one-year budget for continued development under an accountability framework. It also includes a commitment to protect the Aave brand and its intellectual property. Based on community feedback, the ratification of Aave V4 and the detailed structure of a brand-governing structure have been unbundled from this proposal and will each be addressed in separate, dedicated governance proposals.\nThis proposal asks the DAO to approve the following operational framework:\n\nDirect 100% of revenue from all Aave Labs’ Aave-branded products to the Aave DAO treasury.\n\nCommit to a solution for protecting the Aave brand and its intellectual property.\n\nCreate a one-year framework for the DAO to fund strategic growth and development with accountability.\n\n2. Aave Labs Commitment\nWe are becoming a token-centric company and formalizing our alignment with the Aave DAO. Going forward, we will continue to generate revenue, but that revenue will flow to the DAO.\nUnder this framework, Aave Labs works exclusively on Aave-related products, protocol development, and ecosystem growth. We will not build non-Aave related products, pursue outside revenue, or retain product revenue for our own operations. The DAO funds our work, and the DAO receives the revenue that work produces. Every dollar we receive is invested in building, growing, and scaling the Aave Protocol.\nAny unspent funds at the end of the 12-month period will be returned to the DAO treasury or rolled into any DAO-approved subsequent budget.\n3. Motivation\nThe LEND token sale in 2017 raised $16M to build a decentralized lending protocol. That initial foundation grew into Aave, a multi-billion-dollar ecosystem that has since created billions in value.\nAlong the way, Aave Labs (the core development team behind the Aave protocol) has requested DAO funds only for direct protocol development and marketing activities. Everything else has been self-funded. This includes the product layer, which encompasses aave.com, the Aave mobile app, Aave Pro, Aave Kit, and Aave Horizon. It also includes legal and regulatory work, such as the response to a multi-year US Securities & Exchange Commission investigation, brand protection, trademark management, and compliance. Business development and growth has been self-funded as well.\nWe are now entering one of the most important periods that will determine Aave’s success going forward. Fintechs are entering DeFi, institutions are coming onchain, and regulatory clarity is emerging in certain markets that allows us to go directly to consumers. The protocols that win the next decade will be those that move fast, build great tools and products, and capture new markets before competitors. With the right focus, and by investing in important growth areas, Aave is positioned to do exactly that.\nOther approaches to this framework exist, but each involves different trade-offs. Aave Labs could operate independently and retain product revenue to fund itself. However, this would require a clear separation between protocol revenues and those generated by the Aave-branded products built on top of the protocol. Alternatively, the DAO could directly build and operate Aave-branded products through governance, but the execution would likely be slower, and governance overhead is inherently difficult to scale at the pace required.\nThis proposed framework achieves a token-centric alignment and a vision to help Aave win in the coming decade. It directs product revenue to the DAO, includes a commitment to protecting the brand and intellectual property on behalf of the DAO, and provides a clear development roadmap with the resources to execute it.\n4. Specification\nAave Product Revenue to the DAO\nrevenue-flow-diagram1921×1046 161 KB\nThe first ever Aave governance proposal, AIP-1, established that the Aave Protocol be governed by AAVE token holders, resulting in the DAO rightfully receiving 100% of protocol fees.\nAnd since Aave Protocol’s launch, Aave Labs has operated the primary interface, aave.com, which became a key access point for most of the protocol usage across retail users, power users, institutions and integrators. This interface has supported millions of users without a single security incident, demonstrating both reliability and sustained execution. In parallel, the DAO has matured significantly since AIP-1. With that foundation in place, we believe the time is right to evolve toward a more aligned, token-centric model that reflects the protocol’s growth and long-term trajectory.\nUnder this proposal, 100% of revenue from all Aave-branded products developed by Aave Labs will be directed to the Aave DAO treasury. This includes revenue from:\n\naave.com, the existing interface, and all associated fees\n\nAave App, the consumer mobile application\n\nAave Card, a card tied to Aave App with all fees flowing to the DAO\n\nAave Pro, the primary interface for Aave V4\n\nAave Kit, enterprise solutions for fintechs and institutions building on Aave\n\nAave Horizon, Aave’s RWA market and institutional services\n\nAny future Aave-branded products that may be developed\n\nIf approved, this proposal would direct all revenue from the products listed above. That includes revenue from the aave.com swap integration, currently generating approximately $12-24 million annually, to the DAO treasury. As a result, the DAO’s product revenue stream would become immediately material from day one.\nWe heard the community’s feedback on revenue definitions, and we appreciate the request for greater clarity. The intent of directing product revenue to the DAO is value-accretive. The purpose of this framework is to grow the DAO’s treasury rather than create a mechanism for Aave Labs to retain value alongside it.\n“Revenue” is defined as gross product revenue earned by Aave Labs, minus any direct revenue sharing paid by Aave Labs to external partners including revenue rebates, revenue subsidies, revenue sharing arrangements and any additional direct user incentives. Under this definition, expenses only in relation to revenue-sharing arrangements and user incentives are explicitly included. No other costs, including development, infrastructure, or operating expenses, may be deducted from product revenue.\nFor increased community assurance, we commit to per-product transparency. All product revenue and deductions will be reported quarterly and verified by an independent third-party such as an auditor. This way, the DAO can have direct oversight of funding decisions and outcomes, and continue to vote accordingly.\nWith proper execution, the product layer can be an additional source of revenue for the DAO treasury. Combined with protocol fees, the DAO can fund its own growth, security, and development from a diversified revenue stream.\nAave Labs commits to work on only Aave-related products and protocols and nothing else.\nAave V4 and V3 Maintenance\nBased on community feedback, the ratification of Aave V4 has been unbundled from this proposal. A separate, dedicated ARFC for the activation of Aave V4 has been passed by the DAO. And an AIP is now live for that activation. This allows the community to evaluate the V4 activation on its own merits, while this proposal focuses on the funding and operational framework. Aave V3 will continue to operate as long as it is needed.\nExpanding Revenue Through Aave V4\nThe product layer is one part of the path to increasing the DAO’s annual revenue. The protocol layer, powered by Aave V4, is the other. Aave V3 already generates over $100 million in annualized revenue for the DAO, making it one of the highest earning DAOs in DeFi. Aave V4 expands on V3 with new monetization features that allow the protocol, and DAO, to capture more value from the risk it underwrites.\nV4’s architecture also unlocks revenue streams that are not easily possible in previous Aave versions. Each Spoke can extend Aave into a new market or use case, with its own risk parameters and revenue model. As with V3, 100% of Aave V4’s protocol revenue will also go to the DAO.\nWe’ve taken a look at various products and protocols across the crypto, fintech, and financial services industries to show estimations that highlight the size of the opportunities available:\nspoke-revenue-data1921×1046 400 KB\n* These opportunity estimates are based on other protocols or products in each category (e.g. Pendle, Fluid), and the size of the opportunity (e.g. OTC lending volume), etc. They each represent a net new revenue opportunity on top of what Aave already generates today, and they are only possible to pursue in a scalable way once V4 is live. Reaching these estimates would also depend on market conditions, scale of adoption, and execution.\nAave V4 also introduces a new reinvestment module, which is an optional net new revenue opportunity for the DAO to consider. Currently, Aave pools maintain a significant idle float that currently earns nothing. This reinvestment feature allows the protocol to sweep this capital into short-term, low-risk yield opportunities pre-vetted and approved by the DAO, similar to a collateral listing.\nWhen Aave rates fall below SOFR-rates, it signals underutilized liquidity that could be productively deployed. Based on historical stablecoin float levels and a risk-free proxy SOFR-rate, the additional interest that would have been earned is substantial:\nreinvestment-module-data1921×1047 391 KB\n* These figures are illustrative good faith estimates based on historical performance and idle liquidity, and are included to inform governance discussions around prioritization and resource allocation. They do not constitute projections, commitments, or expectations, and actual outcomes may vary materially depending on governance choices, execution, adoption, and market conditions.\nThis interest can be allocated between users and the DAO, or otherwise distributed at the DAO’s discretion. The analysis does not account for other strategies such as ETH staking or reinvesting into higher-yield opportunities, which may also be pursued if the DAO elects to do so.\nTaken together, these opportunities illustrate the range of operational scale the DAO may need to support across both the protocol and product layers if adoption and market conditions warrant it. Viewed as an aggregate opportunity set, they suggest that the long-term revenue ceiling for the Aave ecosystem is materially higher than today.\nThe Aave Brand and Intellectual Property\nAs outlined above, we are moving toward a token-centric model and strongly believe that the Aave IP should be held in a community-protected vehicle. This includes, repositories, domains and any other operational assets necessary to ensure continuity in the event of service provider changes. As requested by the DAO community, the detailed structure for governing the Aave brand and its associated intellectual property will be presented in a separate, dedicated ARFC.\nEstablishing this community-protected vehicle will require substantial research, legal structuring, and consultation. The evolving regulatory environment can also be a factor in affecting this process and informing the range of viable options.\nThe Temp Check for this proposal will be live within 180 days if the Aave Will Win Framework passes. This gives ample time to properly research, scope, and provide precise details on how this could take place. However, the community-protected vehicle itself would not be created until the DAO decides on all relevant details.\nTechnical Roadmap and Expanded Responsibilities\nThis section covers what Aave Labs plans to build and maintain over the next year as part of the funding request in this proposal. It also explains how we will handle the responsibilities previously managed by BGD Labs and ACI following their departures.\nOur work currently falls into four areas including the core protocol, GHO, user-facing applications (e.g. Aave Pro, Aave App), and developer tooling (e.g. Aave Kit).\nCore Protocol\nOur primary protocol work covers both Aave V3 and Aave V4. Development continues on the V4 core architecture and a full set of Spoke implementations. Development priority and sequencing will be determined by market demand, technical readiness, and strategic fit. Some Spokes listed here may be deprioritized or replaced by new opportunities as the market evolves. Our current focus includes the Umbrella Spoke, Flash Loans Spoke, Permissioned Spoke, Debt Trading Spoke, Segregated Collateral Spoke, LP Collateral Spoke, and Cross-Chain Spoke. Some Spokes and extensions, such as Reinvestment Strategies, may be developed by other service providers.\nAave V3 and V2 will continue to receive maintenance, security monitoring, and contract upkeep. We have the engineering bandwidth to absorb these responsibilities from BGD Labs. Parameter optimizations, risk management updates, security patches, and technical reviews of governance proposals will proceed as normal in collaboration with the DAO’s other service providers. New chain deployments and asset listing support will also continue as needed.\nAave App\nThe Aave App for iOS and Android is being built from the ground up as a consumer-facing mobile application. Planned work includes a simplified yield-bearing savings product, cross-chain yield strategy tools, fiat on- and off-ramp connectivity, recurring deposits, smart accounts with anti-phishing protections, and account recovery. The Aave App represents a major, multi-year commitment to bring Aave to a new generation of retail users.\nAave App puts Aave in front of a whole new consumer market with the potential to onboard millions of users. This puts Aave next to many of the largest fintech names in the world and allows it to expand beyond a DeFi-native brand.\nWhile Aave App will begin as a simple savings application, it is designed to evolve into a more comprehensive product suite, incorporating features such as the Aave Card, unlocking yet more revenue opportunities.\nGHO Stablecoin\nAave Labs will supervise, or directly implement, a direct minting integration for Aave V4 and on- and off-ramp infrastructure through a specific GHO Stability Module. Other activities like new collateral facilitators and multi-chain sGHO implementation will be supervised or contributed to without disrupting the work of other active service providers, that will continue operating as they where before and eventually expand their scope over time. These features expand GHO’s utility and make it easier for users and integrators to work with the stablecoin. While Aave Labs will supervise the core GHO maintenance when needed, the product’s scope is wide enough to support and maintain continued contributions from multiple service providers.\nAave Kit\nAave Kit is our dedicated, enterprise-grade B2B product suite for fintechs and institutions building on Aave. This is a significant opportunity. As more traditional financial companies look to integrate DeFi into their products, Aave needs a purpose-built set of tools, APIs, SDKs, and documentation to serve them. Aave Kit addresses this by providing enterprise-grade developer tooling, integration support, and a clear onboarding path for institutional partners. We are also exploring agentic interfaces (MCP for AI agents) as part of our R&D efforts in this area.\nAave Pro\nAave Pro is the primary user-facing interface for the Aave ecosystem, significantly enhancing and expanding the capabilities available to users. Its vision includes advanced functionality such as a transaction builder for complex position management, seamless migration tooling from V3 to V4, one-click leverage and deleverage strategies, direct fiat on-ramping from bank accounts, and expanded swap revenue through automated strategies. Many of these features will be directly revenue-generating for the DAO. The existing aave.com interface will continue to be maintained as a reliable access point and revenue source for the DAO, while Aave Pro represents its natural evolution.\nExpanded Responsibilities\nBGD Labs and ACI together have historically handled a range of distinct protocol functions. Each has been reviewed, and we have outlined which responsibilities can be absorbed by Aave Labs within the scope and funding framework of this proposal.\nOn the protocol side, this includes V2 and V3 contract maintenance, security coordination, chain upgrade analysis, asset listing and network technical reviews, support for V2 off-boarding, and enabling a user-driven migration path from V3 to V4. Treasury and collector contract management will transition to other service providers.\nOn the governance and infrastructure side, Aave Labs will assume responsibility for governance proposal tooling, maintenance of the Aave DAO GitHub repository, Guardian coordination, the Address Book, the Permission Book, CAPO pricing management, ENS space management, DNS and hosting for the governance interface, bridge adapter maintenance, Proof-of-Reserve automation, technical reviews of governance proposals, and securing the governance forum.\nFrom ACI, Aave Labs will absorb, and in some cases further improve alongside the DAO, the governance proposal lifecycle (Skyward), Dolce Vita and incentive program infrastructure.\nSome specialized functions will be transitioning to service providers other than Aave Labs. These include Risk Agents, the Aave Seatbelt safety mechanism, Aave Robot infrastructure, and the Generalized Risk Stewards (AGRS). This allocation ensures that responsibilities are best aligned with each team’s core competencies.\nRoadmap Summary\nThe table below provides a high-level view of our technical priorities.\n\nFocus Area\nInitiatives\nWorkstream\n\nProtocol Core\nAave V4 launch and continuous development, security, and maintenance\nDevelopment, Maintenance, Security\n\nProtocol Core\nAave V4 Spoke development\nDevelopment\n\nProtocol Core\nV2/V3 maintenance and security\nMaintenance, Security\n\nProtocol Core\nNew chain deployments and asset listings\nMaintenance\n\nProtocol Core\nProtocol improvements and R&D\nR&D\n\nAave Horizon\nContinuous expansion of RWA collateral\nDevelopment, Maintenance\n\nAave Horizon\nPort Aave Horizon over to Aave V4\nDevelopment\n\nGHO\nGHO/sGHO development\nDevelopment, Maintenance, Security\n\nGHO\nV4 GHO integrations\nDevelopment\n\nGHO\nOn/off-ramp solutions (GSM)\nDevelopment\n\nGHO\nLP collateral facilitator\nDevelopment\n\nAave App\nProduct development (iOS and Android)\nDevelopment\n\nAave App\nSavings product and yield strategy integrations\nDevelopment\n\nAave App\nFiat on/off-ramp and recurring deposits\nDevelopment\n\nAave Pro\nProduct development\nDevelopment\n\nAave Pro\nTransaction builder, leverage and deleverage feature, advanced strategies, fiat on-ramping, etc. for revenue generation\nDevelopment\n\nAave Pro\nIncentive management and integrations\nDevelopment\n\nAave Kit\nAPI, SDK, documentation\nDevelopment\n\nAave Kit\nAgentic Aave R&D (MCP for AI agents)\nR&D\n\nGovernance\nGovernance tooling and infrastructure\nMaintenance, Security\n\nAbsorbed from BGD\nSeveral protocol maintenance, security, and infrastructure functions for Aave V3/V4\nMaintenance, Security\n\nAbsorbed from ACI\nGovernance operations and BD functions for Aave V3/V4\nOperations\n\nWhile not exhaustive and subject to expansion over time, this list reflects the minimum scope included in the funding request under this proposal.\nDAO Growth Requires Resources at Scale\nThe operational framework outlined above requires execution at a scale commensurate with the opportunity. For Aave to scale and play a role in the real financial system, it must invest in growth with the same discipline and ambition as fintechs, banks, and other financial institutions. Without a clear commitment to this objective, Aave’s long-term upside will remain constrained. If all product revenue generated by Aave Labs flows to the DAO, the DAO must also be prepared to fund the continued development, maintenance and expansion of these products.\nThis is especially relevant as Aave Labs assumes the responsibilities of two departing service providers. The scope of work encompassed by this proposal is materially broader than any prior Aave Labs engagement and exceeds that of any individual service provider to date. It spans protocol development, product engineering, business development, legal and compliance, go-to-market execution, and nearly the full set of governance and infrastructure functions previously handled by BGD Labs and ACI. Despite this significantly expanded workload, we are confident we can deliver within the budget proposed during the Temp Check.\nAave Labs Funding Request\nThe DAO is now facing a structural decision regarding Aave Labs’ operating model going forward.\nCurrently, Aave Labs self-funds a substantial portion of its operations.\nThis reflects the original direction set by AIP-1: revenue from Aave-branded products, such as aave.com and other product surfaces, has been used to fund Aave Labs’ product development, marketing, legal, and operations costs, while the DAO has funded core protocol development and version upgrades.\nUnder the proposed operational framework, all fees generated by Aave-branded products would flow directly to the DAO treasury rather than being retained by Aave Labs to support its operations and product development. As a result, responsibility for funding Aave Labs’ activities would shift correspondingly to the DAO.\nIn parallel, Aave Labs would absorb the majority of responsibilities previously handled by BGD Labs and ACI. Together, these two service providers were funded at approximately $7.4M per year in stablecoins plus 9,450 AAVE per year. This is a combined value of roughly $9M per year at current token prices.\nAave Labs requests $25 million in stablecoins, 75,000 AAVE, in addition to growth and development grants structured in line with community feedback, as detailed below:\nPrimary Grant:\n\nAave Labs proposes a total primary grant of $25 million, structured across three components:\n\n$5 million paid upfront upon approval of the proposal\n\nTwo concurrent streams both starting at month one:\n\nStream A: $5M over 6 months (~$833K/month, ends at month 6)\n\nStream B: $15M over 12 months (~$1.25M/month, ends at month 12)\n\nThis structuring is intentionally front-loaded to support the most capital-intensive phase of execution, particularly pre-launch product development and initial go-to-market efforts, where timely investment is critical to success.\nAny unspent portion of the primary grant at the end of the 12-month period will be returned to the DAO treasury or rolled into a subsequent DAO-approved budget, ensuring continued accountability and capital efficiency.\nIn addition, 75,000 AAVE will be allocated upon approval of the proposal, vesting linearly over a four-year period. This extends the vesting schedule outlined in the original Temp Check, in response to community feedback for stronger long-term alignment between Aave Labs and the DAO.\nThis grant is intended to fund Aave Labs’ operations over the 12-month period and support the expanded scope of work outlined above. The AAVE token allocation further enables Aave Labs to offer competitive long-term aligned compensation as the organization scales.\nRecruiting experienced engineers and operators in DeFi requires token-based incentives, which are standard across the industry. The AAVE token grant serves two purposes: keeping Aave Labs competitive in a brutal talent market, and ensuring our team is directly aligned with the AAVE token.\nOn the talent front, we are 8 years post-TGE, competing head-to-head for engineers and operators against companies that are pre-TGE or have raised hundreds of millions of dollars, all of whom can offer token or equity compensation with asymmetric upside. Token grants are therefore a critical mechanism for Aave Labs to remain competitive. Without them, both retention and recruiting become increasingly difficult.\nStaff compensated in AAVE have a direct financial stake in the long-term success of the protocol, creating a level of alignment that is difficult to replicate through cash compensation alone. As Aave Labs takes on a broader operational mandate, we believe this alignment is essential.\nThese tokens will not be used by Aave Labs to vote on any governance proposals. Instead, they are allocated exclusively for employee compensation and will vest according to individual vesting schedules, reinforcing long-term alignment between the team and the protocol.\nGrowth and Development Grants:\nIn addition to the primary grant, Aave Labs requests a set of growth and development grants tied to specific product launches and milestones. These grants are distinct from the $25 million operating budget and are designed to fund the continued development, scaling, and long-term growth of the associated products and services.\nBased on community feedback, the growth and development grants have been restructured to better reflect the relative scale of commitment required by each product:\n\n$7,500,000 allocated for Aave App, to support product development, marketing, and ongoing product operations. The Aave App is a major, multi-year commitment to build an entirely new consumer product from the ground up. This grant will be distributed in three tranches based on the following milestones:\n\nMilestone 1: $5M upon public launch of the Aave App.\n\nFor go-to-market costs, insurance premiums, operating costs, ongoing product development, and consumer marketing.\n\nMilestone 2: $2.5M upon reaching 50,000 verified user sign-ups within the Aave App.\n\nFor ongoing operating costs, user acquisition, onboarding costs, and consumer marketing.\n\n$2,500,000 for Aave Pro, structured as a milestone-based grant payable upon the launch of advanced, revenue-generating features. This reflects a more balanced approach based on community feedback, given that the existing Aave interface already generates significant revenue for the DAO in its current form.\n\nMilestone 1: $1.5M upon delivery of the transaction builder, leverage and deleverage tool, and rewards dashboard.\n\nMilestone 2: $1M upon delivery of new vaults integration (with custom yield strategies for users) and fiat on-ramping.\n\n$5,000,000 for Aave Card launch, with funds used for card program creation and maintenance, marketing, and ongoing product development streamed over 6 months.\n\n$2,500,000 for Aave Kit launch, with funds used for B2B go-to-market, marketing, product development and maintenance streamed over 6 months.\n\nNote: For clarity, all funds will be spent on Aave-related efforts.\nGrowth and development grants are released upon delivery of the associated product and streamed over a nine month period, with governance confirming milestone completion prior to disbursement. This streaming structure, consistent with the primary grant, enables the DAO to maintain ongoing oversight while evaluating effectiveness over time.\nAs well-capitalized companies increasingly enter DeFi and invest aggressively in both product and distribution, Aave must operate at a comparable scale to remain competitive. This level of commitment enables long-term planning, accelerated hiring, and sustained investment in product and go-to-market without the constraints of annual budget cycles. These growth and development grants are designed to fund the cost of bringing each product to market, from engineering through go-to-market, covering all associated development and commercialization costs.\nThe funding requested represents a significant expansion in scope relative to historical funding. To date, Aave Labs has largely self-funded the cost of building and scaling the product layer, seeking DAO support mainly for core protocol development and focused marketing. This proposal secures the level of investment required for Aave to remain competitive and continue building over the next decade. Scaling Aave to compete with leading TradFi institutions requires stable, predictable funding, enabling contributors to plan effectively, attract and retain talent, and execute at the standard of a global financial platform.\nAltogether, these funds cover the following costs:\n\nContinued protocol development (V4 improvements, Spokes, core infrastructure, research and development)\n\nContinued protocol maintenance and security coordination for Aave V3\n\nProduct engineering across Aave Pro, Aave App, Aave Kit, and other products\n\nProduct go-to-market, user acquisition, marketing (e.g. social media/content) and growth\n\nBusiness development, including partnering with the largest institutional and fintech names to integrate with Aave\n\nAave Horizon asset onboarding and driving TVL/borrow growth\n\nOngoing resource provision for institutional integrators, including technical, InfoSec and operational support\n\nApplication security, including an extensive monitoring program and enterprise fees to social media platforms to protect the Aave brand\n\nEvents, which Aave Labs historically has organized with DAO funding (e.g. rAAVE, DeFi Day, and institutional events)\n\nAbsorption of ~40 functions from BGD Labs and ACI, including governance tooling, infrastructure maintenance, and security coordination\n\nNote: Security audits are funded separately by the DAO and, where managed by Aave Labs, will be agreed with the DAO.\nAave Labs currently employs approximately 90 people. Roughly 60% are in technical teams (across engineering, product & design and security), with the remainder in business development, marketing, operations, legal and compliance. The approximate budget allocation by category is as follows:\n\nCategory\nApproximate Allocation\n\nEngineering\n60%\n\nProduct\n20%\n\nBusiness Development\n10%\n\nMarketing and Events\n5%\n\nOperations, including Legal and Compliance\n5%\n\nWith this funding, Aave Labs would have the runway required to execute effectively on the initiatives outlined above. It also reflects a deliberate choice by the DAO to fund the level of execution necessary to support protocol operations at an increased scale, should governance determine that such expansion is warranted.\nTo maximize effectiveness, Aave Labs would retain autonomy over individual product strategy and day-to-day operations. Building competitive products requires the ability to move quickly, make decisions without excessive coordination overhead, and iterate in response to real-time market feedback. We recommend a similar model for other Service Providers who might choose to operate under this framework, enabling each to execute efficiently with clearly defined mandates.\nAccountability Framework\nThis funding is subject to a strict accountability framework built on community feedback.\nAave Labs will publish quarterly accountability reports covering: (1) funds received and spent by category, (2) KPI performance versus targets, (3) product delivery status, and (4) headcount changes. The first report will be published within 90 days of funding approval.\nProduct-level KPIs will be tied directly to each funded initiative:\n\nProduct\nKey Performance Indicators\n\nAave App\nUser Sign-Ups, Assets Under Management (AUM), Balance Retention Rate\n\nAave Protocol\nNet deposits, loans outstanding and originated, fees generated for DAO, active addresses\n\nAave Pro\nTrading volume through new features, revenue generated for the DAO, user adoption of advanced tools, AUM\n\nAave Kit\nNumber of institutional partners integrated, net deposits and borrow volume onboarded through Aave Kit\n\nAave Card\nNumber of active cardholders, transaction volume, net revenue generated for the DAO\n\nProtocol Core\nV4 development milestones, V3 uptime and incident response, new chain deployments completed\n\nAll revenue and deduction figures will be independently verified and published to the governance forum.\nThe DAO retains ultimate oversight through its control of the treasury and Aave Labs’ funding stream. If Aave Labs does not meet its commitments or perform effectively, the DAO can choose not to renew this budget.\n5. Next Steps\nAave remains early in its journey. What exists today is a foundational base layer, while the real scale of adoption lies ahead as global finance increasingly moves onchain. DeFi, in its current form, represents only a small fraction of the broader financial system. Over the coming decades, trillions of dollars in assets will migrate onto open rails. In that environment, Aave is well-positioned to become core infrastructure for global finance.\nSince 2017, the focus has been on disciplined execution at the frontier, and that approach continues to guide the protocol today. The next phase of growth, driven by innovation and accelerating institutional adoption, presents a significantly larger opportunity. With sustained commitment and effective execution, Aave can scale to support significantly greater demand and further solidify its role as core liquidity infrastructure for the onchain economy.\nThis proposal seeks to establish a framework for Aave’s next decade. Upon approval, it would reaffirm Aave Labs’ alignment with the DAO by directing all Aave-branded product revenue to the DAO treasury, while enabling the resources required to execute at the necessary scale. It also commits to safeguarding the Aave brand and intellectual property on behalf of the DAO. A separate V4 activation proposal, along with a proposal outlining the structure for a separate community-protected vehicle will follow.\nIf community consensus is reached, this proposal will be raised to Snapshot.\nIf the Snapshot outcome is in favor, the framework will be implemented via one or more onchain AIPs to establish the funding streams and formalize the commitments outlined in this proposal.\nDisclaimer\nHistorically, Aave Labs has self-funded its operations. Under this proposal, Aave Labs would receive funding from the DAO in exchange for directing revenue generated from Aave-branded products to the DAO treasury, if approved. This proposal was authored solely by Aave Labs, with no third-party contributors.\nCopyright\nCopyright and related rights waived under Creative Commons Zero (CC0).\n\n [ARFC] Governance Framework v2\n\n [ARFC] Aave App Launch\n\n 4\n\n 3\n\n 2\n\n 2\n\n 2\n\n read \n\n 18\n min\n\n post by JosueMpia on Mar 27\n\n post by ApuMallku on Mar 27\n\n post by MconnectDAO on Mar 28\n\n post by DTBAEE on Mar 28\n\n post by Millesimillia on Mar 28\n\n post by BeliveInAave on Mar 29\n\n post by axieaur on Mar 29\n\n post by Millesimillia on Mar 30\n\n post by Millesimillia on Mar 30\n\n post by A_J on Mar 30\n\n post by MconnectDAO on Mar 30\n\n post by AaveLabs on Mar 31\n\n post by EzR3aL on Apr 1\n\n post by axieaur on Apr 1\n\n post by AaveLabs on Apr 2\n\n post by DTBAEE on Apr 5\n\n post by Millesimillia on Apr 5\n\n 10 days later\n\n post by PatrickB on Apr 16\n\n post by EzR3aL on Apr 16\n\n Load more posts below","tokens":8981,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262871222,"hash":"e9a5ecab126fc1f0c2c8ac68998100ffa4ac953d"}
{"url":"https://ethresear.ch/t/payload-chunking/23008/1","domain":"ethresear.ch","title":"Payload Chunking - Sharding - Ethereum Research","text":"Payload Chunking \n\n Sharding\n\n stateless,data-availability,chunking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n read \n\n 10\n min\n\n Sep 2025\n\n 1 / 9\n\n Sep 2025\n\n Sep 2025\n\n post by Nero_eth on Sep 1, 2025\n\n Nero_eth\n\n Payload Chunking\ntl;dr: Split an EL block (=payload) into multiple mini‑blocks (“chunks”) of fixed gas budget (e.g. 2**24 = 16.77M) that propagate independently as side cars. Each chunk carries the pre‑state it needs to execute statelessly and commits to its post‑state diff. Chunks are ordered but can be executed fully independently in parallel. CL commits to the set of chunk headers; sidecars carry bodies and inclusion proofs.\nValidation becomes more of a continuous stream.\nMotivation\nToday, blocks are large, monolithic objects that will become even larger in the future. Validation requires receiving the full block before execution can begin. This creates latency bottlenecks in block propagation and execution.\nAfter the block is received over the p2p network, transactions are executed sequentially. We cannot start validating while downloading or parallelize execution.\nTimeline showing today’s block validation bottleneck: full block download first, then sequential execution1100×580 29.3 KB\n\nMessages on the p2p layer are usually compressed using Snappy. The block-format of Snappy that is used on Ethereum cannot be streamed. Thus, we need to slice the block into chunks before compression.\n\nWith EIP-7928: Block-level Access Lists, the situation improves, but we’re still waiting for the download to finish before starting block validation. With 4 cores, we get the following Gantt chart:\nTimeline under EIP-7928: execution can use access lists but still must wait for block download1101×580 33.3 KB\nInstead, we can stream blocks as chunks:\n\nEach chunk contains ≤ 2**24 gas of transactions.\n\nOne could also have the chunk size increase geometrically (2**22, 2**23, …, 2**25) in gas. This would give us varying latencies for chunks, enabling better parallelization - but I’m not sure it’d be worth the complexity.\n\nTransactions remain ordered. Chunks are indexed and ordered, but independent of each other, so they can be validated in parallel. Still, the post-state of chunk 0 is the pre-state of chunk 1.\n(optional) Each chunk carries the state it needs to be executed statelessly.\n\nTimeline with payload chunking: chunks stream in and execute in parallel while downloading continues.1101×580 37.7 KB\nThis shifts validation from “download full block, then process” → “process while receiving the rest.”\n\nExecution Layer Changes\nWe extend the EL block format to support chunking:\nclass ELHeader:\n parent_hash: Hash32\n fee_recipient: Address\n block_number: uint64\n gas_limit: uint64\n timestamp: uint64\n extra_data: ByteList[MAX_EXTRA_DATA_BYTES]\n prev_randao: Bytes32\n base_fee_per_gas: uint256\n parent_beacon_block_root: Root\n blob_gas_used: uint64\n excess_blob_gas: uint64\n transactions_root: Root\n state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: Uint\n withdrawals_root: Root\n block_access_list_hash: Bytes32\n # New fields\n chunk_count: int # >= 0\n\nThere is no commitment to the individual chunks in the EL header. We only add the chunk count to it. The execution outputs (state_root, logs_bloom, receipts_root, gas_used) must be either the same as the value in the last chunk (applies to state root and withdrawals root), or the root after aggregating the chunk’s values (applies to transactions, receipts, logs, gas used, and the block access list).\nExecution Chunks\nChunks are never put on-chain; only their roots are committed.\nChunks contain the fields we would usually expect in the EL block body. Transactions are split up over chunks with a limit of 2**24 gas per chunk. Withdrawals must only be included in the last chunk. Mirroring block-level access lists, chunks come with their own chunk access list, and one could additionally add pre-state values to chunks, unlocking statelessness.\nclass Chunk:\n header: ChunkHeader\n transactions: List[Tx]\n withdrawals: List[Withdrawal] # only in chunk at index -1\n chunk_access_list: List[ChunkAccessList]\n pre_state_values: List[(Key, Value)] # optional\n\nEach chunk comes with a header including the chunk index. Transactions are ordered by chunk.header.index and their index in the chunk. Commitments to each chunk’s execution output are included in the header.\nclass ChunkHeader:\n index: int\n txs_root: Root\n post_state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: uint64\n withdrawals_root: Root\n chunk_access_list_root: Root\n pre_state_values_root: Root # optional\n\nTo prevent proposers splitting their blocks into too many chunks, the protocol can enforce that chunks must be at least half full (\\geq\\frac{chunk\\_gas\\_limit}{2}≥𝑐ℎ𝑢𝑛𝑘_𝑔𝑎𝑠_𝑙𝑖𝑚𝑖𝑡2) OR chunk.header.index == len(beaconBlock.chunk_roots) (= last chunk in that block).\n\nConsensus Layer Changes\nDiagram of consensus changes: beacon block tracks chunk roots while execution chunks propagate via sidecars.1180×593 91.5 KB\nBeacon blocks track chunks with new fields:\nclass BeaconBlockBody:\n ...\n chunk_roots: List[ChunkRoot, MAX_CHUNKS_PER_BLOCK] # SSZ roots of chunks\n\nclass ExecutionPayloadHeader:\n ...\n chunk_count: int\n\nThe CL receives the execution chunks from the EL via a new ChunkBundle container which includes the EL header and the chunks (=similar to blobs).\nThe CL computes chunk roots using SSZ’s hash_tree_root and puts them into the beacon block body.\nSidecar Design\nChunks are carried in sidecars:\nclass ExecutionChunkSidecar:\n index: uint64 # chunk index\n chunk: ByteList[MAX_CHUNK_SIZE] # Opaque chunk data\n signed_block_header: SignedBeaconBlockHeader\n chunk_root_inclusion_proof: Vector[Bytes32, PROOF_DEPTH]\n\nThe consensus layer ensures all chunks are available and properly linked to the beacon block body via Merkle proofs against chunk_roots (=similar to blobs).\nNetworking\nThe proposer gossips only the lightweight beacon block with commitments (chunk_count, chunk_headers_root) on the normal beacon_block topic, while the heavy execution data is streamed separately as ExecutionChunkSidecars across X parallel subnets (beacon_chunk_sidecar_{0..X}), deduped by (block_root, index).\nInitially, all nodes must subscribe to all subnets and custody all chunks. While this doesn’t reduce bandwidth/storage requirements yet, it enables the immediate benefits of parallelization. Partial custody can be added in a future upgrade once the basic mechanism is proven and/or zk-proving becomes viable.\nNetworking view: lightweight beacon block propagates fast, while heavy execution chunks are streamed across parallel subnets.1090×430 260 KB\nFork Choice\nFork choice requires that all sidecars are both available and successfully validated before a block is considered valid. The beacon block with the chunk_roots propagates quickly, but the block only becomes fork-choice eligible once every chunk has been received and inclusion-proven against the root. The beacon block still contains the EL header with all the necessary commitments (=committing to parent block and execution outputs). What we knew as block body on the EL stays empty in this design.\n\nBenefits\n\nStreaming validation: execution can start while other parts of the block are still downloading or busy loading from disk. Chunks are independent (if pre-state provided), or rely on the chunk-access list (with chunk-level state diffs) and the pre-block-state; multiple CPUs/cores can validate chunks simultaneously; distribute bandwidth usage over slot instead of beginning-of-slot bursts.\nStreamlined proving: ZK Provers can parallelize proving multiple chunks at the same time, benefiting from the independence of chunks.\nStateless friendliness: since a single chunk is smaller than a block, we might consider adding pre-state values such that there is no need for local state access. A practical middle ground is to include pre-state values only in chunk 0, guaranteeing that at least one chunk can always be executed while the node loads the state required for other chunks from disk into cache.\nFuture extensibility: clear path to integrate zk-proofs over chunks or going for sharded execution.\n\nDesign Space\nChunk Size\n2**24 gas (~16.7M) emerged as a natural chunk size:\n\nMax Transaction Size: As of Fusaka (EIP-7825), 2**24 is the max possible transaction size.\nCurrent blocks: 45M gas blocks naturally split into ~3 chunks, providing immediate parallelism\nFuture blocks: Scales well - 100M gas blocks would have ~6 chunks\n\nValidator\n\nExecution engine splits the block into chunks internally (opaque to CL) and passes them to the CL through an ExecutionChunkBundle.\nProposer wraps each chunk in a sidecar with inclusion proof. The proposer also computes the hash tree root of each chunk and puts them into the beacon block body.\nPublishing happens in parallel across all subnets\nAttesters wait for all chunks and validate them before voting\n\nBuilders\nProposers can publish chunks as they’re finished building, and validators can start validating them even before receiving the beacon block. Since chunks contain the signed beacon block header and an inclusion proof against it, one can validate (=execute) chunks as they come in, trusting their source (=proposer).\nOpen Questions & Future Work\nProgressive Chunk Sizes?\nThe idea of geometrically increasing chunk sizes (2**22, 2**23, …, 2**25) seems beneficial but adds complexity. The first chunk could be smaller (5M gas) with pre-state values for immediate execution, while later chunks are larger. This remains an area for experimentation.\nPartial Custody Path\nWhile the initial implementation requires full custody, the architecture naturally supports partial custody:\n\nNodes could custody only Y subnets out of X\nReconstruction mechanisms (similar to DAS) could recover missing chunks\n\nCompatible with ePBS and Delayed Execution\nAt first glance, the proposed design seems compatible with both EIP-7732 and EIP-7886. Under ePBS, the chunk roots would likely move into the ExecutionPayloadEnvelope, and we’d put an additional root over the chunk roots into the ExecutionPayloadHeader. The PTC would not only have to check that a single EL payload is available, but that all chunks are. This is not much different from blobs.\nThe advantages of block chunking and independent validation scale with higher gas limits and may contribute to reducing spikiness in node bandwidth consumption.\n\n Toward Semantic Block Chunking\n\n BALs for Proposer Commitments\n\n Integrated in-protocol distributed history and state storage\n\n Blocks Are Dead. Long Live Blobs\n\n 5\n\n read \n\n 10\n min\n\n post by daniellehrner on Sep 1, 2025\n\n post by Nero_eth on Sep 2, 2025\n\n post by raulk on Sep 8, 2025\n\n post by preda-devteam on Sep 9, 2025\n\n post by Nero_eth on Sep 9, 2025\n\n post by Nero_eth on Sep 9, 2025\n\n 10 days later\n\n post by gballet on Sep 19, 2025\n\n post by Nero_eth on Sep 19, 2025\n\n Powered by Discourse","tokens":2737,"squid":"ink-research","role":"Deep Scholar","at":1791262877608,"hash":"60b1c2e8a6f7eec3bc2071d821f28de9cbd4a4ca"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18213843096091","domain":"support.arbitrum.io","title":"Using Arbitrum's traditional bridge to move funds to Mainnet – Arbitrum Foundation","text":"If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fast exit liquidity provider like Hop, Connext, Across, Celer, or Maker. Why do I have to wait 8 days?This is how all optimistic rollups work. Optimistic rollups use something called fraud proofs in order to keep participants in the network honest. There is a \"challenge period\" for these proofs. When one party submits a claim about the state of the chain, another party has ~8 days to challenge that claim. If you'd like to read more about the technical details of Arbitrum, see Inside Arbitrum.If you're more of a visual and auditory learner, watch our videos about challenges and proofs.  More Resources:1 - (Youtube) Multi round Fraud Proofs: What, How, and Why.2 - (Youtube) Challenge Protocol\n\n Recently viewed articlesSkipping the bridgeWhy are there 2 different USDC's on Arbitrum?Why wait 7 days to claim funds when bridge to Ethereum?Bridging over a new tokenYou need ETH to power transactions\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n How can I add Arbitrum network to my wallet?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Godfrey brai\n\n 2 years ago\n\n I have waited for more than 12 days I still can find my ethPlease help me rectify \n\n 0\n\n Please sign in to leave a comment.","tokens":369,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262881230,"hash":"888a80156b5a754f7f31b3240dc0b5882f689907"}
{"url":"https://ethresear.ch/c/sharding/6","domain":"ethresear.ch","title":"Latest Sharding topics - Ethereum Research","text":"Latest topics in Sharding\n\n Sharding\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Sharding category\n\n Discussion about sharding. See also: \n\nhttps://github.com/ethereum/sharding/blob/master/doc.md \nhttps://github.com/ethereum/sharding/blob/master/account_redesign_eip.md\n\n 1\n\n 5.4k\n\n Mar 2018\n\n FullDAS: towards massive scalability with 32MB blocks and beyond\n\n data-availability,p2p,scaling\n\n 2\n\n 5.0k\n\n 19d\n\n LeanDA: Design and Benchmark\n\n data-availability,post-quantum\n\n 0\n\n 479\n\n Aug 7\n\n Lean Execution: a holistic approach to secure, efficient, adaptive, and resourceful execution throughput to scale the world-computer\n\n mev,stateless,zk-roll-up,data-availability,cross-shard\n\n 0\n\n 475\n\n Jul 6\n\n Why Homogenizing the Execution of the World-Computer Beats Scaling Through Fragmentation\n\n stateless,data-availability\n\n 0\n\n 198\n\n May 13\n\n Native proof verification\n\n rollup\n\n 2\n\n 572\n\n May 5\n\n Delegated Execution Sharding (DES): A hyper-parallelized zkEVM for theoretically optimal execution-layer scalability\n\n 0\n\n 124\n\n Apr 24\n\n Alternatives to 2D Reed-Solomon Codes in DAS\n\n data-availability,rollup\n\n 0\n\n 181\n\n Apr 13\n\n Blob Analysis after Fusaka and BPO Updates\n\n data-availability\n\n 2\n\n 853\n\n Apr 9\n\n Scaling the DA layer with Blob Streaming\n\n 0\n\n 406\n\n Feb 25\n\n Early Rejection of Adversarial BALs\n\n scaling\n\n 2\n\n 294\n\n Feb 3\n\n Using Rateless Coding for DAS\n\n data-availability\n\n 3\n\n 267\n\n Jan 14\n\n EIP-8077: Nonce Gap Simulation Report\n\n data-availability,rollup,p2p\n\n 0\n\n 200\n\n Dec 2025\n\n Integrated in-protocol distributed history and state storage\n\n 6\n\n 558\n\n Dec 2025\n\n Toward Semantic Block Chunking\n\n cross-shard,networking,chunking\n\n 3\n\n 675\n\n Nov 2025\n\n Alternative DAS concept based on RLNC\n\n data-availability\n\n 2\n\n 755\n\n Sep 2025\n\n Payload Chunking\n\n stateless,data-availability,chunking\n\n 8\n\n 938\n\n Sep 2025\n\n PeerDas Documentation\n\n data-availability\n\n 1\n\n 773\n\n Sep 2025\n\n Revisiting Secure DAS in One and Two Dimensions\n\n data-availability\n\n 0\n\n 656\n\n Jul 2025\n\n SHA256-based VDF\n\n 10\n\n 6.4k\n\n Jul 2025\n\n Higher voting threshold for checkpoint committees\n\n 8\n\n 1.5k\n\n Jul 2025\n\n Capping Transaction Gas: Data, Impact, and Rationale\n\n cross-shard,parallelization\n\n 2\n\n 338\n\n Jul 2025\n\n The State of Type 3 Transactions After Pectra: One Month of Blob Data Activity\n\n data-availability\n\n 2\n\n 471\n\n Jul 2025\n\n Blob Notaries: a distributed blob publishing design to scale DA\n\n data-availability\n\n 0\n\n 648\n\n Jul 2025\n\n Rapidblocks: minimizing “merge conflicts” in the block building pipeline\n\n scaling\n\n 1\n\n 229\n\n Jun 2025\n\n A new design for DAS and Sharded Blob Mempools\n\n data-availability\n\n 2\n\n 652\n\n Jun 2025\n\n Execution Dependencies\n\n parallelization\n\n 8\n\n 1.9k\n\n May 2025\n\n StorageBeat: Towards an evaluation framework for decentralised storage\n\n data-availability,storage-fee-rent\n\n 10\n\n 653\n\n May 2025\n\n Enshrined Native L2s and Stateless Block Building\n\n stateless,zk-roll-up\n\n 5\n\n 598\n\n May 2025\n\n Steelmanning a blob throughput increase for Pectra\n\n 2\n\n 876\n\n Mar 2025","tokens":766,"squid":"ink-research","role":"Deep Scholar","at":1791262887912,"hash":"b5f98d7c09bb1f70ead9726451e51e5b00059073"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18148168225947-Why-do-I-need-ETH-to-use-the-Arbitrum-network","domain":"support.arbitrum.io","title":"Why do I need ETH to use the Arbitrum network? – Arbitrum Foundation","text":"When moving funds (ETH and non-ETH) from Ethereum (L1) to Arbitrum (L2), you'll need to have ETH in your wallet on the corresponding Arbitrum chain. This is because ETH is the currency used for gas fees on Arbitrum and all Arbitrum transactions are powered by ETH.\n\n Recently viewed articlesUsing Arbitrum's traditional bridge to move funds to MainnetSkipping the bridgeWhy are there 2 different USDC's on Arbitrum?Why wait 7 days to claim funds when bridge to Ethereum?Bridging over a new token\n\n Related articles\n\n You need ETH to power transactions\n\n How can I add Arbitrum network to my wallet?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why are there 2 different USDC's on Arbitrum?\n\n Skipping the bridge\n\n Please sign in to leave a comment.","tokens":192,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262891546,"hash":"330cb867c1f6aadf79f02b2286b57066f45ef581"}
{"url":"https://governance.aave.com/t/who-can-bring-governance-topics-to-a-vote-under-governance-framework-v2/25462/2","domain":"governance.aave.com","title":"Who can bring governance topics to a vote under Governance Framework v2? - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 10\n\n 2 / 3\n\n Aug 11\n\n Aug 10\n\n post by Millesimillia on Aug 10\n\n Millesimillia\n\n I raised this question in the [ARFC] Governance Framework v2 thread on 9 August, while the Snapshot was still open: [ARFC] Governance Framework v2 - #4 by Millesimillia\nIt did not receive a response, and the vote has since closed with 392,100 AAVE in favour and none against. I am opening it here so it has a proper home. This is a request for clarification, not an objection to the framework.\nIn the framework, author restrictions appear in three places only: the business case for a New Asset Listing and for a New Network Deployment, both reserved to Aave Labs or TokenLogic, and the Direct-to-AIP path, limited to active Service Providers. The Standard Process does not appear to restrict ARFC authorship.\n\nIs it correct that any token holder may author an ARFC on topics outside asset listings and network deployments - tokenomics, buybacks, service provider selection criteria, service provider reviews?\n\nOpening a Snapshot requires a place on the Authors list or 80,000 AAVE of proposition power. What is the route for a holder below that threshold whose ARFC has community support? Is there a sponsoring mechanism, and who maintains the Authors list?\n\nWith TEMP CHECK retired, what is the intended low-barrier entry point for community-initiated topics?\n\nCommitments have been made in governance discussions that token economics would remain firmly in view, and I take them in good faith. My question is structural rather than about intent: what keeps token economics transparent to holders over time, when every service provider also carries equity and revenue interests of its own? Concretely, is there a fixed reporting cadence on protocol revenue and its allocation that does not depend on which provider holds which mandate?\n\nIf the reading above is correct, I would ask that a short subsection on community-initiated proposals be added: who may author an ARFC, the route to Snapshot for authors below the threshold, and who maintains the Authors list. The framework states that it shall be maintained over time, so this seems a natural place for it.\nTransparency and accountability on these points would make AAVE stronger, not weaker. Over the medium term I would like holders to be able to judge the token the way shareholders judge a company: on disclosed economics, a predictable reporting rhythm, and a clear line from protocol revenue to the token.\nDisclosure: I am an AAVE holder and staker, without material proposition power. I am not compensated by any party and hold no position with any service provider.\nWarm regards,\nMillesimillia (Edited)\n@TokenLogic\n\n Areta Delegate Platform\n\n post by MconnectDAO on Aug 10\n\n MconnectDAO\n\n I strongly support this question. Aave governance should not only reward those who already have enough voting power or the right connections to move an idea forward.\nStrong proposals can come from any holder, researcher, delegate, or community member. The forum should give serious attention to ideas based on their quality, evidence, and value for Aave, not only on who brings them.\nWe need a clear path for community proposals that receive genuine support but come from authors below the Snapshot threshold. A transparent sponsor process, clear criteria for the Authors list, and public timelines for review would make participation more fair.\nAt the same time, proposals should be judged on impact, risk, and long term benefit. Sometimes well presented proposals move ahead despite limited value, while strong ideas are left behind because the author lacks access or visibility.\nOpen participation with clear accountability will make Aave governance stronger and help ensure that the best ideas get a real chance to be discussed and voted on. @Millesimillia\n\n 1 month later\n\n Closed on Sep 9\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Should Aave Make Governance Discussions Easier for Non-Technical Users to Follow?\n\n General\n\n 2\n\n 109\n\n Sep 20\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n Governance\n\n 24\n\n 1.4k\n\n Apr 14","tokens":1144,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262895243,"hash":"2d043a681fd8878f9f227eebe18ff0014a26bea0"}
{"url":"https://ethresear.ch/t/alternatives-to-2d-reed-solomon-codes-in-das/24639/1","domain":"ethresear.ch","title":"Alternatives to 2D Reed-Solomon Codes in DAS - Sharding - Ethereum Research","text":"Alternatives to 2D Reed-Solomon Codes in DAS \n\n Sharding\n\n data-availability,rollup\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 11\n\n 1 / 1\n\n Apr 11\n\n Apr 11\n\n post by birenjith on Apr 11\n\n birenjith\n\n Acknowledgement: This is a joint work with Emanuele Viterbo and Dankrad Feist and is supported by ESP Grant FY24-1745 titled “Improvements to 2D Reed-Solomon Codes in DAS”.\nIn this post, we describe how block circulant (BC) codes can serve as an alternative to one-dimensional (1D) and two-dimensional (2D) Reed–Solomon (RS) codes in the Ethereum PeerDAS protocol. We present efficient encoding and reconstruction algorithms for BC codes, developed within the same implementation framework as the respective 1D RS algorithms. The proposed encoding algorithm also permits a graceful integration of KZG commitment scheme. We evaluate and compare the performance of BC codes in terms of code rate, stopping rate, and the size of the local codes they contain, against both 1D and 2D RS codes. A longer version of this post is available in SVF2026.\nBlock Circulant Codes\nBlock circulant (BC) codes are introduced in SVD2025 as a viable alternative to both 1D (currently used) and 2D RS codes (expected to be incorporated later) in PeerDAS. Similar to the 2D RS code, the BC code contains multiple local codes, and each local code can be designed as a [(n_0,k_0),D][(𝑛0,𝑘0),𝐷] stacked 1D RS code. By stacked 1D RS code, we mean a [n_0D ,k_0D][𝑛0𝐷,𝑘0𝐷] RS code whose codewords are stacked in D horizontal rows each row of length n_0𝑛0, and k_0𝑘0 columns representing information symbols). Therefore, it is compatible with the KZG scheme. It turns out that BC codes achieve certain operating regimes of rate, stopping rate and local code size that are not feasible with either a 1D or a 2D RS code.\nIn a 2D RS code, the symbols are arranged in a two-dimensional square grid and there are linear constraints binding symbols belonging to every row or column. In the case of a BC code, symbols are arranged on a circle and the circle is divided into multiple overlapping arcs. Every arc has two neighbouring overlapping arcs, one on the left and the other on the right assuming a clockwise direction. Symbols belong to every arc are subject to a set of linear constraints. We present a more concrete description in the next subsection.\nA Description of the BC Code\nbc-code1534×1471 210 KB\nFigure 1: Illustration of the block circulant code. In this example, information symbols in the green background color are combined with parity symbols in the pink background color region resulting in the final arrangement. The groupings of symbols within the closed curves indicate local codes.\nConsider the example consisting of n=16𝑛 =16 symbols as given in Figure 1. There are \\mu=4𝜇 =4 arcs (two of them marked by closed curves) each containing n_0=6𝑛0 =6 symbols, equally spaced on the circle. There are a total of k=8𝑘 =8 unconstrained symbols denoted as d_1, \\ldots, d_8𝑑1,…,𝑑8. Each local code contains k_0=4𝑘0 =4 unconstrained symbols. The remaining symbols are generated subject to certain linear constraints. In every arc, \\rho=n_0-k_0=2𝜌 =𝑛0 −𝑘0 =2 redundant symbols are added in such a manner that the local code corresponding to the arc becomes a 1D RS code. For example, the vector of symbols (d_1,d_2,p_{11},p_{12},d_3,d_4)(𝑑1,𝑑2,𝑝11,𝑝12,𝑑3,𝑑4) corresponding to a single arc forms a codeword of an 1D RS code. Thus an arc is uniquely identified with a local code, and we may write arc and local code interchangeably. There lies exactly \\omega=2𝜔 =2 symbols at the overlapping region of two adjacent local codes and therefore we call \\omega𝜔 as the overlap width. Every unconstrained symbol is part of two distinct local codes and we call it the overlapping factor, denoted by \\lambda𝜆. In the present arrangement, we have \\lambda=2𝜆 =2. In the general BC code presented in SVD2025, arrangements with higher values of \\lambda𝜆 are possible. Other parameters like \\omega𝜔 and \\rho𝜌 can also be modified suitably. It is shown in SVD2025 that a BC code with \\lambda=2,3𝜆 =2,3, the total number of erasures that can recovered by the BC code has been shown to be \\lambda\\rho𝜆𝜌. The ratio of total number of tolerable erasures to n𝑛 is called the stopping rate and is denoted by S𝑆. We summarize the notations used for adjustable parameters of the BC code in the table below.\nParameters of BC code\n\nNotation\nMeaning of the parameter(s)\n\n\\mu𝜇\nNumber of local codes\n\n\\lambda𝜆\nOverlap factor (Every symbol is part of \\lambda𝜆 local codes)\n\n\\rho𝜌\nNumber of redundant symbols in a local code\n\n\\omega𝜔\nOverlap width (Number of symbols two adjacent local codes overlap on)\n\n[n_0,k_0]=[\\lambda\\omega+\\rho,\\lambda\\omega][𝑛0,𝑘0] =[𝜆𝜔 +𝜌,𝜆𝜔]\nLocal code blocklength and dimension\n\n[n,k]=[\\mu(\\omega+\\rho),\\mu\\omega][𝑛,𝑘] =[𝜇(𝜔 +𝜌),𝜇𝜔]\nGlobal code blocklength and dimension\n\nR=\\frac{\\omega}{\\omega+\\rho}𝑅 =𝜔𝜔+𝜌\nRate\n\nS=\\frac{\\lambda\\rho}{\\mu(\\omega+\\rho)}𝑆 =𝜆𝜌𝜇(𝜔+𝜌)\nStopping rate\n\nR_0=\\frac{\\lambda\\omega}{\\lambda\\omega+\\rho}𝑅0 =𝜆𝜔𝜆𝜔+𝜌\nLocal code rate\n\nS_0=\\frac{\\rho}{\\lambda\\omega+\\rho}𝑆0 =𝜌𝜆𝜔+𝜌\nLocal code stopping rate\n\nStacked BC code\nThe procedure to convert an 1D RS code to stacked 1D RS code is described in detail in WZ2024. The exact procedure is applicable to the BC code as well because (a) each of the local code in the BC code is an 1D RS code, (b) the encoding can be performed by a series of local 1D RS encoders with carefully chosen set of evaluation points for each of the local code. We will describe the encoding procedure for a stacked BC code with the help of an example.\nEncoding Algorithm\nencode-1-11539×434 36.4 KB\nFigure 2 Structure of blob 0 before encoding.\nencode-2-11698×425 36.1 KB\nFigure 3 Structure of extended (encoded) blob 0 in BC code.\nWe describe the encoding with the help of an example illustrated in Figure 2 and 3. Here, overlap factor \\lambda=2𝜆 =2 and there are \\mu=4𝜇 =4 local codes. We pick the stacking parameter D=64𝐷 =64 and a blob consists of 81928192 finite field symbols arranged in k=128𝑘 =128 cells. Each blob is an element of \\mathbb{F}_q^{(D \\times k)}=\\mathbb{F}_q^{(64 \\times 128)}𝔽(𝐷×𝑘)𝑞 =𝔽(64×128)𝑞, whereas each cell belongs to \\mathbb{F}_q^{64}𝔽64𝑞. The requirement on size of finite field q𝑞 will be shortly described. First we partition 128128 cells of Blob 0 into \\mu=4𝜇 =4 segments each containing \\omega=32𝜔 =32 cells. These four segments are indexed as \\text{Segment}(0,0), \\text{Segment}(0,2), \\text{Segment}(0,4)Segment(0,0),Segment(0,2),Segment(0,4), and \\text{Segment}(0,6)Segment(0,6). During the encoding procedure, we shall generate and place segments containing redundant symbols in between two successive (\\text{Segment}(0,6)Segment(0,6) is considered to be adjacent to \\text{Segment}(0,0)Segment(0,0), viewing them cyclically) segments. The resultant 88 segments indexed as \\text{Segment}(0,0)Segment(0,0) to \\text{Segment}(0,7)Segment(0,7) jointly form the extended (encoded) blob. In general, the redundant segments will have \\rho𝜌 cells, but in this example, we have \\rho=\\omega=32𝜌 =𝜔 =32 since the rate is chosen to be R=0.5𝑅 =0.5. Therefore, every segment of the extended blob consists of 3232 cells.\nIn Figure 2, the blob 0 with 128128 cells are shown. Anticipating the structure of extended blob, the second index of cells associated to Blob 00 are kept as 0\\text{-}31,64\\text{-}95,128\\text{-}159,192\\text{-}2230-31,64-95,128-159,192-223. Cells within extended blob 0 with the above indices are retained with the same data as blob 0. The cells indexed as 32\\text{-}63,96\\text{-}127,160\\text{-}191,224\\text{-}25532-63,96-127,160-191,224-255 in the extended blob 00 will be populated with redundant data during encoding.\nWe choose a prime field \\mathbb{F}_q𝔽𝑞 such that \\mathbb{H}_3 \\subset \\mathbb{H}_2 \\subset \\mathbb{H}_1 \\subset \\mathbb{H}_0 \\subset \\mathbb{F}_q^*ℍ3 ⊂ℍ2 ⊂ℍ1 ⊂ℍ0 ⊂𝔽∗𝑞 is a chain of subgroups in \\mathbb{F}_q^*𝔽∗𝑞 satisfying size constraints\n\n\\begin{aligned}\n|\\mathbb{H}_3| &= D = 64,\\\\\n|\\mathbb{H}_2| &= \\omega D = 2048,\\\\\n|\\mathbb{H}_1| &= 2\\omega D = 4096,\\\\\n|\\mathbb{H}_0| &= 2\\lambda\\omega D = 8192 .\n\\end{aligned}\n|ℍ3|=𝐷=64,|ℍ2|=𝜔𝐷=2048,|ℍ1|=2𝜔𝐷=4096,|ℍ0|=2𝜆𝜔𝐷=8192.\nIt may be observed that the prime number q𝑞 associated to the elliptic curve bls12-381 satisfies that 2^{32} \\mid (q-1)232 ∣(𝑞 −1) and is therefore suitable to find the above subgroup chain. The tree of subgroups is given in Figure 4. Next, we describe how the extended blob 00 is constructed.\n\nThe code consists of 44 local codes indexed as 0\\text{-}30-3, and encoding is carried out by separately encoding each of the local code one by one. In Figure 3, cells forming each of the local codes are clearly indicated.\n\nThe first 3\\omega=963𝜔 =96 cells \\text{Cells}(0,0\\text{-}95)Cells(0,0-95) comprising of 3\\omega D = 96 \\times 64=61443𝜔𝐷 =96 ×64 =6144 finite field symbols form a ([n_0=96,k_0=64],D=64)([𝑛0 =96,𝑘0 =64],𝐷 =64) stacked 1D RS codeword. A polynomial f_0(X) \\in \\mathbb{F}_q[X]𝑓0(𝑋) ∈𝔽𝑞[𝑋] of degree at most 2\\omega D = 40962𝜔𝐷 =4096 may be formed using symbols in blob 00 data at \\text{Cells}(0,0\\text{-}31)Cells(0,0-31) and \\text{Cells}(0,64\\text{-}95)Cells(0,64-95). Each cell in the extended blob is associated to a coset of \\mathbb{H}_3ℍ3 as follows:\n\n\\begin{aligned}\n\\text{Cells}(0,0\\text{-}31) &\\Leftrightarrow \\mathbb{H}_3, \\beta^{64}\\mathbb{H}_3, \\beta^{32}\\mathbb{H}_3, \\ldots, \\beta^{124}\\mathbb{H}_3 \\\\\n\\text{Cells}(0,64\\text{-}95) &\\Leftrightarrow \\beta^{2}\\mathbb{H}_3, \\beta^{66}\\mathbb{H}_3, \\beta^{34}\\mathbb{H}_3, \\ldots, \\beta^{126}\\mathbb{H}_3 \\\\\n\\text{Cells}(0,32\\text{-}63) &\\Leftrightarrow \\beta\\mathbb{H}_3, \\beta^{65}\\mathbb{H}_3, \\beta^{33}\\mathbb{H}_3, \\ldots, \\beta^{125}\\mathbb{H}_3\n\\end{aligned}\nCells(0,0-31)⇔ℍ3,𝛽64ℍ3,𝛽32ℍ3,…,𝛽124ℍ3Cells(0,64-95)⇔𝛽2ℍ3,𝛽66ℍ3,𝛽34ℍ3,…,𝛽126ℍ3Cells(0,32-63)⇔𝛽ℍ3,𝛽65ℍ3,𝛽33ℍ3,…,𝛽125ℍ3\nIn each of 9696 cells, f_0(X)𝑓0(𝑋) is evaluated at the corresponding coset and the evaluations become the contents of that cell. This yields a stacked RS codeword of the Local code 00. The polynomial f_0(X)𝑓0(𝑋) is constructed in such a manner that the evaluations at \\text{Cells}(0,0\\text{-}31)Cells(0,0-31) and \\text{Cells}(0,32\\text{-}63)Cells(0,32-63) in the extended blob are exactly same as the corresponding values in the blob. This is achieved by taking the data values as evaluations and interpolating a polynomial from these data values.\n\nThe same procedure is repeated for Local code 1, 21,2 and 33. The corresponding polynomials are denoted by f_1(X), f_2(X)𝑓1(𝑋),𝑓2(𝑋) and f_3(X)𝑓3(𝑋). The blob data used to construct each f_i(X),i=1,2,3𝑓𝑖(𝑋),𝑖 =1,2,3, cells associated to each local code, and the cosets used as evaluation points are listed below.\n(a) Local code 11: \\text{Cells}(0,64\\text{-}159)Cells(0,64-159)\n\n\\begin{aligned}\nf_1(X) &\\Leftrightarrow \\text{Cells}(0,64\\text{-}95) \\text{ and } \\text{Cells}(0,128\\text{-}159) \\text{ of blob } 0 \\\\\n\\text{Cells}(0,64\\text{-}95) &\\Leftrightarrow \\beta^2 \\mathbb{H}_3, \\beta^{66} \\mathbb{H}_3, \\beta^{34} \\mathbb{H}_3, \\ldots, \\beta^{126} \\mathbb{H}_3 \\\\\n\\text{Cells}(0,96\\text{-}127) &\\Leftrightarrow \\beta^3 \\mathbb{H}_3, \\beta^{67} \\mathbb{H}_3, \\beta^{35} \\mathbb{H}_3, \\ldots, \\beta^{127} \\mathbb{H}_3 \\\\\n\\text{Cells}(0,128\\text{-}159) &\\Leftrightarrow \\mathbb{H}_3, \\beta^{64} \\mathbb{H}_3, \\beta^{32} \\mathbb{H}_3, \\ldots, \\beta^{124} \\mathbb{H}_3\n\\end{aligned}\n𝑓1(𝑋)⇔Cells(0,64-95) and Cells(0,128-159) of blob 0Cells(0,64-95)⇔𝛽2ℍ3,𝛽66ℍ3,𝛽34ℍ3,…,𝛽126ℍ3Cells(0,96-127)⇔𝛽3ℍ3,𝛽67ℍ3,𝛽35ℍ3,…,𝛽127ℍ3Cells(0,128-159)⇔ℍ3,𝛽64ℍ3,𝛽32ℍ3,…,𝛽124ℍ3\n(b) Local code 22: \\text{Cells}(0,128\\text{-}223)Cells(0,128-223)\n\n\\begin{aligned}\nf_2(X) &\\Leftrightarrow \\text{Cells}(0,64\\text{-}95) \\text{ and } \\text{Cells}(0,128\\text{-}159) \\text{ of blob } 0 \\\\\n\\text{Cells}(0,128\\text{-}159) &\\Leftrightarrow \\mathbb{H}_3, \\beta^{64} \\mathbb{H}_3, \\beta^{32} \\mathbb{H}_3, \\ldots, \\beta^{124} \\mathbb{H}_3 \\\\\n\\text{Cells}(0,160\\text{-}191) &\\Leftrightarrow \\beta \\mathbb{H}_3, \\beta^{65} \\mathbb{H}_3, \\beta^{33} \\mathbb{H}_3, \\ldots, \\beta^{125} \\mathbb{H}_3 \\\\\n\\text{Cells}(0,192\\text{-}223) &\\Leftrightarrow \\beta^2 \\mathbb{H}_3, \\beta^{66} \\mathbb{H}_3, \\beta^{34} \\mathbb{H}_3, \\ldots, \\beta^{126} \\mathbb{H}_3\n\\end{aligned}\n𝑓2(𝑋)⇔Cells(0,64-95) and Cells(0,128-159) of blob 0Cells(0,128-159)⇔ℍ3,𝛽64ℍ3,𝛽32ℍ3,…,𝛽124ℍ3Cells(0,160-191)⇔𝛽ℍ3,𝛽65ℍ3,𝛽33ℍ3,…,𝛽125ℍ3Cells(0,192-223)⇔𝛽2ℍ3,𝛽66ℍ3,𝛽34ℍ3,…,𝛽126ℍ3\n(c) Local code 33: \\text{Cells}(0,192\\text{-}255)Cells(0,192-255) and \\text{Cells}(0,0\\text{-}31)Cells(0,0-31)\n\n\\begin{aligned}\nf_3(X) &\\Leftrightarrow \\text{Cells}(0,64\\text{-}95) \\text{ and } \\text{Cells}(0,128\\text{-}159) \\text{ of blob } 0 \\\\\n\\text{Cells}(0,192\\text{-}223) &\\Leftrightarrow \\beta^2 \\mathbb{H}_3, \\beta^{66} \\mathbb{H}_3, \\beta^{34} \\mathbb{H}_3, \\ldots, \\beta^{126} \\mathbb{H}_3 \\\\\n\\text{Cells}(0,224\\text{-}255) &\\Leftrightarrow \\beta^3 \\mathbb{H}_3, \\beta^{67} \\mathbb{H}_3, \\beta^{35} \\mathbb{H}_3, \\ldots, \\beta^{127} \\mathbb{H}_3 \\\\\n\\text{Cells}(0,0\\text{-}31) &\\Leftrightarrow \\mathbb{H}_3, \\beta^{64} \\mathbb{H}_3, \\beta^{32} \\mathbb{H}_3, \\ldots, \\beta^{124} \\mathbb{H}_3\n\\end{aligned}\n𝑓3(𝑋)⇔Cells(0,64-95) and Cells(0,128-159) of blob 0Cells(0,192-223)⇔𝛽2ℍ3,𝛽66ℍ3,𝛽34ℍ3,…,𝛽126ℍ3Cells(0,224-255)⇔𝛽3ℍ3,𝛽67ℍ3,𝛽35ℍ3,…,𝛽127ℍ3Cells(0,0-31)⇔ℍ3,𝛽64ℍ3,𝛽32ℍ3,…,𝛽124ℍ3\nObserve that local code 33 wraps around cyclically in the sense that it binds together the data in cells in the right end to the ones on the starting left. This is indicated in Fig.\\ref{fig:bcexblob}. We remark that the encoding is systematic i.e., data in the blob is available as such in the extended blob.\n\ntree1636×632 16.8 KB\nFigure 2 Tree of subgroups for BC code. Here, \\beta𝛽 is a generator of \\mathbb{H}_0ℍ0.\nThe exact algorithm using FFT is presented next. Let us use {\\bf u} \\in \\mathbb{F}_q^{64 \\times 128}𝐮 ∈𝔽64×128𝑞 to denote blob 0. We use {\\bf u}[\\textsf{start}\\text{-}\\textsf{end}]𝐮[𝗌𝗍𝖺𝗋𝗍-𝖾𝗇𝖽] to denote the data at the cells \\text{Cell}(0,\\textsf{start})Cell(0,𝗌𝗍𝖺𝗋𝗍) to \\text{Cell}(0,\\textsf{end})Cell(0,𝖾𝗇𝖽). Let us define four (D\\times \\omega) = (64 \\times 32)(𝐷 ×𝜔) =(64 ×32) blob data arrays in their vectorized form, i.e., as 20482048 long vectors:\n\n\\begin{aligned}\n\\mathbf{u}_0 &= \\mathbf{u}[0\\text{-}31], \\\\\n\\mathbf{u}_2 &= \\mathbf{u}[64\\text{-}95], \\\\\n\\mathbf{u}_4 &= \\mathbf{u}[128\\text{-}159], \\\\\n\\mathbf{u}_6 &= \\mathbf{u}[192\\text{-}223].\n\\end{aligned}\n𝐮0=𝐮[0-31],𝐮2=𝐮[64-95],𝐮4=𝐮[128-159],𝐮6=𝐮[192-223].\nThe extended blob is denoted by {\\bf \\hat{x}} \\in \\mathbb{F}_q^{64 \\times 256}ˆ𝐱 ∈𝔽64×256𝑞 and we have\n\n\\hat{\\mathbf{x}}_i = \\hat{\\mathbf{x}}[32i\\text{-}(32i+31)], \\quad i=0,1,\\ldots,7.\nˆ𝐱𝑖=ˆ𝐱[32𝑖-(32𝑖+31)],𝑖=0,1,…,7.\nagain in vectorized form. We use |||| to concatenate two vectors one after another to form a longer vector. The algorithm is given below.\nFor i=0,1,2,3𝑖 =0,1,2,3, execute:\n\nIf i𝑖 is even, set \\mathbb{G} = \\beta \\mathbb{H}_2𝔾 =𝛽ℍ2, j=2i𝑗 =2𝑖, \\ell = (2i+2)\\bmod 8ℓ =(2𝑖 +2)mod8.\n\nIf i𝑖 is odd, set \\mathbb{G} = \\beta^3 \\mathbb{H}_2𝔾 =𝛽3ℍ2, j=(2i+2)\\bmod 8𝑗 =(2𝑖 +2)mod8, \\ell = 2iℓ =2𝑖.\n\nSet $((\\hat{\\mathbf{x}}j | \\hat{\\mathbf{x}}\\ell)(\\alpha), \\alpha \\in \\mathbb{H}_1)\n= \\mathbf{u}j | \\mathbf{u}\\ell$.\n\nCompute $\\mathbf{x}j | \\mathbf{x}\\ell\n= \\mathrm{IFFT}_{\\mathbb{H}_1}(\\hat{\\mathbf{x}}j | \\hat{\\mathbf{x}}\\ell)$.\n\nCompute $\\hat{\\mathbf{x}}{2i+1}\n= \\mathrm{FFT}{\\beta\\mathbb{H}_1}(\\mathbf{x}j | \\mathbf{x}\\ell, \\mathbb{G})$.\nEntries of \\hat{\\mathbf{x}}_{2i+1}ˆ𝐱2𝑖+1 occupy cells respecting the coset assignment to each cell.\n\nThe above BC encoder requires four IFFT computations over \\mathbb{H}_1ℍ1 and four restricted FFT computations over \\beta\\mathbb{H}_1𝛽ℍ1 restricted to a coset of \\mathbb{H}_2ℍ2. It may be noted again that |\\mathbb{H}_1|=k_0D|ℍ1| =𝑘0𝐷 and |\\mathbb{H}_2|=k_0D/2|ℍ2| =𝑘0𝐷/2. By restricted FFT, we mean the computation of FFT over a group (coset) restricted to a subset of values belonging to subgroup (subcoset). An efficient way to compute restricted FFT/IFFT is provided in SVF2026.\nReconstruction algorithm\nAn efficient reconstruction algorithm is described in SVF2026.\nKZG Commitments for Stacked BC Code\nIn every column of the stacked BC code, we have evaluations over a subgroup or a coset of a subgroup. Therefore, the KZG multiproof available for 1D RS code WZ2024 is applicable here as well. It is sufficient to have KZG commitments for each local RS code with a blocklength much smaller than the blocklength of the entire BC code. In this way, we reduce the complexity of KZG related computations.\nComparison With 1D and 2D RS Codes\nConsider a BC code with parameters \\mu, \\omega𝜇,𝜔 and \\rho𝜌. We fix the overlap factor \\lambda=2𝜆 =2 throughout the discussion. Recall that \\mu𝜇 represents the number of local codes, \\rho D𝜌𝐷 represents the number of redundant symbols in every local code, and \\omega D𝜔𝐷 represents the number of symbols at which two adjacent local codes intersect. The rate R𝑅, stopping rate S𝑆 and local code size L𝐿 of a BC code are given by:\n\n\\begin{aligned}\nL &= (2\\omega+\\rho)D \\\\\nR &= \\frac{\\mu \\omega D}{\\mu(\\omega+\\rho)D}\n = \\frac{\\omega}{\\omega + \\rho} \\\\\nS &= \\frac{2\\rho D}{\\mu(\\omega+\\rho)D}\n = \\frac{2\\rho}{\\mu(\\omega + \\rho)}\n = \\frac{2(1-R)}{\\mu}.\n\\end{aligned}\n𝐿=(2𝜔+𝜌)𝐷𝑅=𝜇𝜔𝐷𝜇(𝜔+𝜌)𝐷=𝜔𝜔+𝜌𝑆=2𝜌𝐷𝜇(𝜔+𝜌)𝐷=2𝜌𝜇(𝜔+𝜌)=2(1−𝑅)𝜇.\nThe tradeoff between S𝑆 and R𝑅 for a BC code with different values of \\mu𝜇 is shown in Figure 3. The plots also contain the tradeoff for 1D and 2D RS codes. Thus the BC code achieves a region between 1D and 2D RS codes.\n\n SvR_mu_2-1.png860×595 23.7 KB\n SvR_mu_4-1.png860×595 15.3 KB\n SvR_mu_6-1.png860×595 14.9 KB\n\nFigure 3 The tradeoff between stopping rate (S𝑆) and rate (R𝑅) in 1D RS, 2D RS and BC codes with different values of \\mu=2,4,6𝜇 =2,4,6 (left to right)\nThe absolute maximum number E𝐸 of missing symbols that can be reconstructed within an extended blob is given by\n\nE=nDS\n𝐸=𝑛𝐷𝑆\nwhere nD𝑛𝐷 is the total number of symbols present in an extended blob and S𝑆 is the stopping rate. We consider three different blob sizes 11 MB, 88 MB and 3232 MB, and each of them maps to a certain number of finite field symbols kD𝑘𝐷 within a blob. The mapping depends on the choice of finite field \\mathbb{F}_q𝔽𝑞 because a symbol in \\mathbb{F}_q𝔽𝑞 is represented using \\lceil\\log_2(q)\\rceil⌈log2⁡(𝑞)⌉ bits. For example, an 11 MB blob is associated with 2^{15}215 finite field symbols when the the finite field is chosen to be the one linked to \\texttt{bls12-381} with \\lceil\\log_2(q)\\rceil = 32\\times 2^8 = 32⌈log2⁡(𝑞)⌉ =32 ×28 =32 bytes. For various file sizes, we plot E𝐸 versus R𝑅 in Figures 4 and 5. In Figure 4, a BC code with \\mu=4𝜇 =4 is compared against 1D and 2D RS codes whereas in Figure 5, a BC code with \\mu=6𝜇 =6 is chosen for comparison. It is no surprise that BC code is inferior to 1D RS code because 1D RS code is optimal with respect to E𝐸 for a given rate. What is interesting is that BC codes with both \\mu=4𝜇 =4 and \\mu=6𝜇 =6 perform significantly better than the corresponding 2D RS code for the same file size and rate.\n\n EvsR_mu_fs_4_1048576-1.png862×595 14.8 KB\n EvsR_mu_fs_4_8388608-1.png862×595 15 KB\n EvsR_mu_fs_4_33554432-1.png862×595 15.1 KB\n\nFigure 4 The tradeoff between tolerable number of erasures (E𝐸) and rate (R𝑅) in 1D RS, 2D RS and BC codes with \\mu=4𝜇 =4 and different file sizes F=11 MB, 88 MB and 3232 MB (from left to right).\n\n EvsR_mu_fs_6_1048576-1.png862×595 14.8 KB\n EvsR_mu_fs_6_8388608-1.png862×595 14.9 KB\n EvsR_mu_fs_6_33554432-1.png862×595 15 KB\n\nFigure 5 The tradeoff between tolerable number of erasures (E𝐸) and rate (R𝑅) in 1D RS, 2D RS and BC codes with \\mu=6𝜇 =6 and different file sizes F=11 MB, 88 MB and 3232 MB (from left to right).\nIn Figure 6, the size of local codes within BC, 1DRS and 2DRS codes are compared. Since an 1D RS code does not contain any local code, the entire code is considered as its local code. It may be observed that 2D RS codes are significantly better than the BC code in absolute size of local code. In summary, a BC code gives a significant advantage in increasing the number of tolerable erasures with regard to the 2D RS code. However, the local code size of a BC code is very large compared to 2D RS code. In any case, the BC code offers a regime of operation different from that of both 1DRS and 2DRS codes, and opens up the possibility of designing codes operating on the intermediate regime between 1D and 2D RS codes.\n\n LvsR_mu_fs_6_1048576-1.png862×595 11.6 KB\n LvsR_mu_fs_6_8388608-1.png862×595 12 KB\n LvsR_mu_fs_6_33554432-1.png862×595 11.9 KB\n\nFigure 6 The tradeoff between local code size (L𝐿) and rate (R𝑅) in 1D RS, 2D RS and BC codes with \\mu=6𝜇 =6 and different file sizes F=11 MB, 88 MB and 3232 MB (from left to right). For 1D RS there is no local code, so we take L=nD𝐿 =𝑛𝐷\nReferences\n[SVD2025] Theory of Block Circulant Codes\n[SVF2026] Block Circulant Codes for PeerDAS\n[WZ2024] A Documentation of Ethereum’s PeerDAS\n\n read \n\n 8\n min\n\n Powered by Discourse","tokens":5300,"squid":"ink-research","role":"Deep Scholar","at":1791262898184,"hash":"9ccd87dc85583fe42f1c31d6e87ddecbe1a391af"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18213893952923-Bridging-over-a-new-token","domain":"support.arbitrum.io","title":"Bridging over a new token – Arbitrum Foundation","text":"When you are bridging over a new token, that action will require an approval transaction fee.\nThis goes to Ethereum block producers, not to Arbitrum.\nThe approval transaction only applies once per token, per wallet address.This means that the next time you want to bridge this token over, you will not have to pay for an approval transaction.\nHowever, if you want to bridge the same token over from a new wallet address, you'll have to pay for the approval transaction again.\nYour wallet will prompt you to complete this transaction.\nAfter your transaction has been approved, you will be prompted to pay the standard deposit fee.\nYou will pay a deposit transaction every time you want to bridge over funds. The deposit transaction goes partly to Ethereum and partly to the Arbitrum node validators.\n\n Recently viewed articlesWhy do I need ETH to use the Arbitrum network?Using Arbitrum's traditional bridge to move funds to MainnetSkipping the bridgeWhy are there 2 different USDC's on Arbitrum?Why wait 7 days to claim funds when bridge to Ethereum?\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Skipping the bridge\n\n Why do I need ETH to use the Arbitrum network?\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n You need ETH to power transactions\n\n Please sign in to leave a comment.","tokens":334,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791262901824,"hash":"8a78c35fec6b1d88d75ba55bb8fe3fc9b8290680"}
{"url":"https://governance.aave.com/t/temp-check-aave-delegate-ecosystem-upgrade-the-aligned-delegates-framework/24357/25","domain":"governance.aave.com","title":"[TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework - Governance - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Mar 27\n\n 25 / 26\n\n Apr 15\n\n Apr 14\n\n Load more posts above\n\n post by MconnectDAO on Apr 2\n\n MconnectDAO\n\n ApuMallku\n\n @ApuMallku — Thank you for the detailed clarifications. Happy to contribute to the Charter drafting, especially around participation metrics and exception handling.\nOn Compensation (Q1): I lean toward the 5k/3k split. The reasoning is simple if we want genuine decentralization of governance influence, we need to make the Rising Star tier financially viable, not just symbolic. A delegate doing serious research and voting consistently deserves stability. The 4,000 GHO/month saved vs the 6k/2k model can be redirected toward Proof-of-Contribution incentives or the GovOps function.\nOn Proof-of-Contribution (Q2): I’d suggest weighting the following off-chain activities:\n\nGovernance research & analysis published publicly (Paragraph, Mirror, Forum posts)\n\nVoting rationale documentation (not just voting, but explaining the vote)\n\nCommunity onboarding & delegate education\n\nCross-DAO governance participation (Arbitrum, Uniswap, etc.) that brings learnings back to Aave\nThe key metric shouldn’t just be quantity of contributions but verifiability can it be independently confirmed?\nOn GovOps Vacuum (Q3): This is the most urgent gap. Until Pillar 2 tooling is live, I’d recommend the Charter explicitly define a temporary manual review process perhaps a small multisig or working group so the framework doesn’t stall at launch.\nExcited to see this move to Snapshot. Ready to assist with Charter drafting whenever needed.\n@MconnectDAO\n\n@ApuMallku @Kene_Anode @phenk53 @AaveLabs\n\n post by EzR3aL on Apr 2\n\n EzR3aL\n\n Regular\n\n Cannot really add much to it as this proposal is already very detailed and other already gave great feedback.\nRegarding discourse API Im happy to support here and see what needs to be done so its working properly.\nRegarding the compensation I lean more towards a 5/2k model.\nOrbit delegates are important to reach quorum on proposals so it makes sense to give them a higher compensation, but I don’t think 6k are needed, just keep the same level.\nFor rising stars I think 2k is more than enough. If someone is doing a lot extra work the DAO could consider giving a retro active payment or create a tiered system.\nSo especially for rising stars we would need clear rules for tasks and their fair compensation.\nOther than that, great job @ApuMallku\n\n post by 0xlide on Apr 2\n\n 0xlide\n\n I oppose this proposal for the following three reasons:\n\nSpending 190k GHO on delegate rewards for a 3-month period is excessive.\nI don’t believe it’s a very good culture if only some voters get incentives.\nThe reward should be paid in $AAVE with performance conditions, not GHO.\n\n post by sid_areta on Apr 2\n\n sid_areta\n\n Orbit-Delegate\n\n We welcome this initiative and thanks @apumallku for leading the effort.\nAligned Delegate Baseline\n\nWe are supportive of this direction and look forward to seeing how it improves the quality of forum contributions from larger delegates.\n\nTimeline for Rationale Publication: It is sensible to require that rationales are published within a pre-defined timeframe, as it reduces the likelihood of after-the-fact justifications for passive votes. However, we believe the 48-hour window is extremely short and should be extended. Given the frequency of votes and the short voting window for Aave proposals (~3 days), a 48-hour publication window significantly increases the operational burden on delegates. We recommend extending the timeline to within 4 days after a vote closes. This is more practical and better aligned with standard practice across leading DAOs such as Arbitrum, where a similar rationale publication window is in place.\n\nAnti-Spam Filter: While filtering out low-quality contributions is a legitimate goal, we view this specific metric as gameable and unlikely to deliver reliable signal. Across many delegate programs we have observed in other DAOs, engagement metrics of this type tend to be noisy, carry little meaningful signal, and fail to reflect the actual value of a contribution. We would recommend removing it as a required threshold.\n\nHigh-impact Proposals: The proposal defines Tier 1 proposals as those with “>$1M impact,” but does not clarify how this threshold is determined in practice. In some cases, quantification is straightforward, for example a proposal requesting a direct treasury disbursement of $1M or more. However, many consequential proposals carry indirect or non-monetary impact that is harder to size, such as parameter/technical updates, or even governance process reforms. Who determines whether a given proposal crosses the $1M threshold, and how?\n\nOne-Step Delegation Prompt\n\nWe view this as a meaningful UX improvement. It directly reduces the friction associated with activating voting power, and given ongoing community discussions around voting power transparency and concentration, we are supportive of any step that makes the delegation process more seamless. The randomized display of delegates within the prompt is also a welcome design choice.\n\nAave Delegate Charter\n\nA charter defining delegate roles, responsibilities, and standards is good governance practice, and one we have seen adopted across leading DAOs. We fully support its introduction for Aave DAO.\n\nResponses to Specific Feedback Questions\n\nAre the proposed baselines (85% voting participation and 75% rationale publication) the right balance for an automated system?\n\nWe think the proposed baselines reflect a fair and reasonable balance.\n\nShould the Temp Check include a separate GovOps compensation track?\n\nWe think a dedicated GovOps budget is sensible in principle. However, we are conscious that the scope of responsibilities here may be relatively light given that Aave Labs is filling key operational gaps left by ACI and BGD’s exits. Any GovOps budget request, including a clear scope of work, should be submitted as a separate Temp Check and not bundled with this delegate framework proposal.\n\nShould Pillar 2 UI development be coordinated with Aave Labs or funded via an independent developer?\n\nThis should be coordinated internally with Aave Labs, as it directly concerns updates to the Aave App’s UI and functionality.\n\n post by Ignas on Apr 3\n\n Ignas\n\n Orbit-Delegate\n\n Thanks for the proposal, a lot of thoughtful work here @ApuMallku\nOn the Compensation gap, I lean toward the 5k/2k split. This is more balanced and clearly more capital efficient for the DAO. Orbit Delegates can anchor their value around hitting the thresholds, while rising stars bring a different kind of value, marketing, X posts, fresh ideas, and community building.\nPlease make sure we clearly define what tasks qualify and how those contributions are measured.\n\n post by r0mul0 on Apr 3\n\n r0mul0\n\n I am also skeptical about this proposal.\nIt does not seem a good idea to use GHO for rewards and the total amount seems very high as well.\nI’m afraid this could become another easy way to milk the DAO, similarly to what ACI has done in the past. I do not see any structural gap to fill.\nRegarding forum contribution, until freedom of speech is restored in this forum it does not seem fair to use the forum to measure rewards: accounts that are not in line with certain story telling are labelled as “fake” or “sponsored” by current moderators.\nMy posts have been censored and my account has been put on hold just for expressing my opinion, while at the same time all kind of insults and insinuations were made against some individuals and organizations without any action been taken.\nUntil this forum becomes again a non toxic place, where everybody can express freely his opinion, without censorship, I see very problematic the idea of rewarding forum participation (given this is only possible for someone and restricted for people not in line with current moderators).\n\n post by stani on Apr 4\n\n stani\n\n Aave Labs-Technical SP\n\n While I do think that active participation from token holders, directly or indirectly, is valuable, I believe this proposal does not serve the direction of Aave well and does not set the foundations for success.\nWith this proposal, the problem goes even further, as it requires more analysis, more discussions, more opinions, and fewer agreements and execution steps just to qualify for the program while creating execution bottlenecks. Of course, AI is likely to make this problem even worse.\nSecond, we should strive to move away from creating political corners within the DAO and instead push toward a single shared vision. While it’s okay to have different ideas within a DAO and to debate those amongst ourselves, it should still be done as a team and in a manner that is similar to healthy employee debates. This is the only way we can compete with well structured hierarchical companies or new entrants that carry less governance overhead.\nWhile I do appreciate that the proposal includes delegate standards, which is a positive step, it does not address the primary problem of conduct. I have been monitoring the existing Orbit campaign and am struggling to see the value in it as currently structured. Existing Orbit delegates can be paid while writing negative commentary on socials about Aave, saying disparaging things about partners, and mocking work done by teams that are building and making other high leverage contributions to Aave. In the grand scheme of things, this has many negative consequences that are difficult to quantify, can affect morale in the DAO, and can affect how people see the AAVE token.\nImagine a similar scenario where a company pays an employee or contractor to provide value, and they intentionally create negative value instead. This is a structural issue tied to how program incentives are designed. Delegates face incentives to create controversy because it gains them visibility, engagement, and that in turn can lead to delegated support.\nThird, there is no real vetting of delegates and their backgrounds. Everyone has opinions, but what truly matters is merit, which should be the basis for having a seat at the table.\nAdditionally, all the UI related work mentioned does not make sense to me. These products should focus on users who are actively using the protocols, not on delegation mechanics. Delegation infrastructure has very little to do with understanding user behavior or growing the products themselves.\nI do believe delegates can be compensated, but it should not become a burden for the DAO to run what effectively becomes a political system that creates more drag on execution than value. For example, teams should have sufficient autonomy to execute, with results reviewed periodically. This could be arranged outside of Aave, for instance delegates could make direct agreements with token holders they represent, with those relationships being economically incentivized.\n\n post by Millesimillia on Apr 4\n\n Millesimillia\n\n I concur with r0mul0 and stani. The current delegation infrastructure seems sufficient and I would not want to spend money on extensions. The reason is that token holders should be fully responsible for decision-making. The only exception is probably treasury tokens, which would introduce a recursive element if being used for voting (so they should not be used for voting). If some individuals want to delegate they can do so already today. No need for more in my opinion.\n\n post by ApuMallku on Apr 4\n\n ApuMallku\n\n Thank you to everyone for keeping this debate at such a mature and technically precise level. As an independent delegate, my only compass is the long-term resilience and value of AAVE.\nWe are at a foundational moment. The “Aave Will Win” framework tacitly accepts what many of us have been arguing for months: Token = Equity. The AAVE token now directly captures the economic value and participation rights of the protocol. I voted in favor of it, along with the v4 license and its activation, as a deliberate tabula rasa. The frictions of the past stay in the past. My commitment to the token’s growth is absolute.\nBut for this new chapter to work, two things must happen simultaneously: Labs must execute with ambition, and the DAO must decentralize governance power with equal urgency. These are not competing goals; they are the two legs of the same race. The ECB’s Working Paper No. 3208 already placed a regulatory bullseye on Aave’s concentrated voting power. The SEC’s Interpretive Release 33-11412 and the CLARITY Act define decentralization as a system where no person or group holds effective control. Independent delegates are not a political inconvenience: they are the verifiable proof of decentralization that protects @aavelabs, @stani, and the entire protocol from regulatory capture. The SELL button is the loudest governance signal token holders have, and it has been pressed repeatedly. We have more to lose by allowing governance to atrophy than by investing a fraction of our treasury to professionalize it.\nA special acknowledgment to @stani for engaging directly. This is the dialogue I tried to initiate privately with Labs before publishing this proposal. That conversation went silent without explanation, which is itself a symptom of the coordination gap the ADF is designed to close. I am choosing to see your comment here as the opening of a new chapter, and I will respond with the same directness.\nOn execution overhead and bottlenecks\nThe ADF is built to eliminate governance overhead, not create it. Every threshold (voting participation, rationale publication, and forum signal) is a binary yes/no metric verifiable via Snapshot, the Discourse API, and on-chain data. No committee decides who qualifies. No human judges quality. The rules are pre-defined and self-enforcing. The facilitator role publishes the output of an algorithm, not a subjective judgment. Compared to the current model, where eligibility is assessed retroactively each cycle with an open-ended budget request submitted after the fact, the ADF is structurally leaner. And here I want to be clear: the ACI built something that genuinely worked. Orbit professionalized governance delegates in a way Aave had never seen before. The ADF is not a repudiation of that work; it is its natural evolution, designed to outlast any single entity.\nOn conduct: you are correct, and this is the ADF’s strongest point\nI want to concede this directly: you identified the exact structural flaw that the ADF exists to fix.\nOrbit had zero conduct standards. A delegate could vote on every proposal, collect compensation, and spend the rest of their time publishing negative commentary about Aave or damaging the protocol’s reputation with no consequences. That is broken incentive design, and it is a problem the ADF was always going to solve.\nI am formally committing to add a Delegate Code of Conduct as part of the ARFC stage. Leading DeFi governance frameworks have been running this model successfully, utilizing formal conduct rules with documented misalignment penalties, all ratified on-chain. The scope I am proposing is deliberately narrow: prohibiting conduct that damages the protocol’s reputation, requiring conflict of interest disclosures, and establishing minimum communication standards with the broader ecosystem including Labs. This will be drafted openly on the forum with full community input. This is exactly the kind of improvement that could have been incorporated from the beginning if the initial dialogue with Labs had not gone silent.\nOn “political corners”: I need to respectfully and directly disagree\nThis is where I part ways with your framing, @stani, and I think it matters enough to say clearly.\nWhen you suggest that delegate relationships could happen outside the DAO through private economic agreements between delegates and large tokenholders, you are describing the end of decentralization, not its refinement. That is a patronage system. It concentrates influence in whoever holds the largest bags, creates undisclosed conflicts of interest, and removes the on-chain transparency that makes governance auditable to regulators. The most successful governance frameworks in DeFi explicitly prohibit this model for exactly these reasons.\nAnd here is the harder question: if there are no more compensated, independent delegates, what fills that space? The answer, historically, has been either voter apathy or the concentration of voting power in a small number of entities, which is precisely the dynamic the ECB documented as Aave’s governance risk. A DAO without a professional, diverse delegate ecosystem is not a leaner DAO. It is a DAO heading toward one of two destinations: captured governance, or the Uniswap path where Labs de facto controls direction and the DAO becomes a ratification mechanism. Both are legitimate models. But only one of them is actually decentralized, and only one of them is defensible under MiCA and the CLARITY Act.\nThe errors you are pointing to (conduct issues, lack of vetting, misaligned incentives) are real. But they are design gaps that we now have the context and the tools to fix, not reasons to abandon the concept entirely. We have a rare opportunity right now to build the right system from scratch, informed by what went wrong and by what is working elsewhere. Other protocols have already proven that codified, automated delegate frameworks eliminate political friction. This is not because they suppressed disagreement, but because nobody has to argue about what the rules are when they are written in advance and enforced algorithmically. We can learn from that without pretending our situation is identical.\nWe are at a genuine inflection point. The market has already spoken: AAVE is down over 44% in the last year while governance conflict consumed attention that should have gone to building. Every proposal that dies in political noise is a cost to every token holder. The answer to that cost is not fewer rules; it is clearer rules, applied automatically, with a Code of Conduct that makes destructive behavior economically irrational. That is exactly what the ADF proposes.\nWhat I am formally committing to before the ARFC\n\nDelegate Code of Conduct: drafted openly on the forum, modeled on Sky’s Atlas framework, covering conduct standards, conflict of interest disclosures, and communication expectations. This focuses on off-chain governance work only with no additional technical scope.\nMerit eligibility baseline: a minimum requirement of one full governance cycle of documented participation and an active delegate platform thread before any delegate qualifies for compensation.\n\nThe door to direct dialogue remains open. I am asking only that it stays open on both sides.\nTurning now to the rest of the community’s feedback, which has been equally sharp and valuable.\n@r0mul0 I understand your concerns about censorship, but this proposal is strictly about rules for delegates and decentralization. It has nothing to do with forum moderation, which I do not control. This framework seeks the exact opposite of censorship: automating compensation through verifiable on-chain data and completely removing subjective judgment. The 190,500 GHO is an absolute maximum cap. If the strict algorithmic thresholds are not met, the funds never leave the Treasury.\n@sid_areta You are right: a 48 hour window for rationales is operationally suffocating. The window will be extended to 4 days post-vote to ensure quality without burning out delegates. On the anti-spam filter: if the community feels it generates noise or is gameable, we will remove it entirely. I also agree that GovOps must go in a completely separate proposal.\n@0xlide The expenditure is not guaranteed. 190,500 GHO is a ceiling, not a forecast. Under current conditions, only two delegates realistically qualify as Aligned Delegates today, meaning realistic Q1 spend is closer to 34,500 GHO. We are using GHO strategically to strengthen our native stablecoin’s utility. Direct incentives in AAVE remain open for the next stage.\n@EzR3aL Thank you for the technical backing and for proactively offering your expertise with the Discourse API. Having constructive delegates involved in the infrastructure is what will make this system fair and truly automated.\n@MconnectDAO Your suggestions regarding off-chain tasks (research and cross-DAO education) are at the core of what this framework rewards. Two non-negotiable rules: no double-dipping for Service Providers already receiving DAO compensation, and GovOps goes in a separate thread entirely.\nWith these refinements incorporated, I will move this TEMP CHECK to Snapshot this Thursday, giving the community an extra couple of days for final review.\nThe future of Aave is undeniable decentralization. We built the most important lending protocol in DeFi. It would be a historic mistake to let governance entropy undo what the technology achieved. Let’s build it right together.\n\n post by 0xlide on Apr 4\n\n 0xlide\n\nIf the expected spend is under $35k, I recommend reducing the total maximum ask($190k). Also, when paying rewards in stablecoins, I recommend making a minimum $AAVE holding a mandatory condition for all platforms.\n\n post by JesusCryptoPlaza on Apr 5\n\n JesusCryptoPlaza\n\n stani\n\n I want to add a dimension that I think is underweighted in this debate.\n@stani is right that merit should be the basis for a seat at the table, and that paying delegates who generate negative value is broken incentive design. But I think the root cause is not the existence of a delegate program — it is the absence of participants with genuine skin in the game.\nA delegate who holds meaningful economic exposure to AAVE, who manages capital with fiduciary obligations, or who has professional reputation at stake with every public position cannot afford to vote carelessly, generate controversy for visibility, or damage the protocol’s image. Their LPs, their investors, their counterparties hold them accountable before any Code of Conduct ever could. That is the most effective conduct filter available — and it is one the current system does not select for.\nThe second point I want to raise is regulatory. MiCA is live. The CLARITY Act defines decentralization based on effective control. The ECB’s Working Paper 3208 flagged Aave’s governance concentration as a specific risk. For institutional capital evaluating DeFi exposure, governance credibility is not a nice-to-have — it is a prerequisite. A protocol without a transparent and independent delegate layer carries classification risk that directly impacts how allocators size their positions.\nThe ADF is not perfect, but it moves in the right direction. My concrete suggestion: map the framework explicitly to MiCA and CLARITY Act decentralization criteria. That reframes the delegate program from a DAO expense into a compliance asset that protects Labs, tokenholders, and the protocol’s ability to attract institutional capital.\nAave’s governance should be shaped by participants who have something real to lose. That is the standard we should design for.\n\n post by ApuMallku on Apr 6\n\n ApuMallku\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework (Revised)\nAuthor: Apu Mallku / Independent Delegate Platform\nStatus: TEMP CHECK / Revised Version incorporating community feedback\nDate: April 6, 2026\n\nWhat Changed and Why\nThis revised version incorporates the most substantive feedback from the first round of community discussion, including from @stani, @JesusCryptoPlaza, @sid_areta, @Ignas, @EzR3aL, @Kene_Anode, @phenk53, @MconnectDAO, and @0xlide. Three structural changes are worth highlighting:\n\nA formal Code of Conduct is now a core pillar of the proposal instead of a future ARFC commitment. This directly addresses the conduct concern raised by @stani, which we consider the most valid and necessary criticism to address.\nThe budget section reflects the current reality with one qualified Aligned Delegate candidate rather than a theoretical maximum. The cap remains in place for predictability, but the honest expected spend for the first cycle is made explicit.\nThe regulatory framing is strengthened throughout, following @JesusCryptoPlaza’s observation that this framework should be positioned as a compliance asset instead of a DAO expense.\n\nAbstract\nWith the Aave Chan Initiative (ACI) stepping back from delegate coordination, AAVE’s governance ecosystem faces a structural gap. This is not a crisis; it is an opportunity to build the right system rather than replicate its predecessor.\nThis proposal introduces the Aligned Delegates Framework (ADF): a four pillar upgrade to how AAVE governance identifies, rewards, and holds accountable its most dedicated delegates. The ADF moves beyond purely quantitative voting metrics toward an automated, objective baseline of governance value. For the first time, it establishes a formal Code of Conduct that makes the delegate role not just compensated, but accountable.\nCritically, this framework is more than just good governance practice. It is regulatory infrastructure. As the regulatory environment for DeFi tightens globally (MiCA is live, the CLARITY Act is advancing, and the ECB has already flagged Aave’s governance concentration by name), a transparent, independent, and rule bound delegate ecosystem is Aave’s most defensible proof of decentralization. Today’s regulatory laxity is not a guarantee of tomorrow’s. Building this shield now, while the window is open, is the prudent choice for every token holder and for Labs.\n\nBackground and Motivation\nAAVE governance faces five compounding structural problems that this proposal addresses directly:\n1. The Quantitative Trap. The current model measures delegates primarily through on-chain voting participation rates. This creates an incentive to vote without engaging, allowing delegates to collect compensation while contributing nothing of analytical value.\n2. Structural Voter Apathy. Supplying AAVE and delegating voting power are entirely disconnected. The vast majority of suppliers and stakers never delegate. The result is voting power permanently concentrated among a shrinking set of actors, increasing governance capture risk. The ECB Working Paper No. 3208 documented this concentration specifically for Aave. The SEC’s Interpretive Release 33 11412 and the CLARITY Act both define decentralization as a system where no person or group holds effective voting control. This is a present regulatory exposure.\n3. No Conduct Standards. The current delegate framework has zero conduct rules. A delegate could collect compensation while publishing negative commentary, damaging partnerships, or mocking contributors with no consequences. This is broken incentive design.\n4. Undefined Delegate Standards. There is no formal document establishing what is expected from an AAVE delegate. Duties, conflict of interest disclosures, and minimum engagement standards exist only as implicit norms.\n5. The Post ACI Coordination Vacuum. The departure of ACI leaves a coordination void. A healthy DAO cannot rely on a single entity (Labs or otherwise) to maintain the governance ecosystem that protects the protocol’s decentralization.\n\nCore Pillars\nPillar 1: The Aligned Delegate Baseline (ADB)\nThe ADF replaces the purely quantitative Orbit model with the Aligned Delegate Baseline, a set of binary, fully automatable Minimum Engagement Thresholds tracked via Snapshot GraphQL, the Discourse API, and on-chain data. No committee decides who qualifies and no human judges quality. The system is self enforcing.\nTo qualify for compensation, a delegate must meet all three thresholds per quarter:\n\nVoting Threshold: 85% or higher participation on all on-chain AIPs and Snapshot ARFCs. Abstain votes count as active participation. Technical failures are handled via automated exception parameters.\nCommunication Threshold: Delegates must publish a public Voting Rationale for at least 75% of Tier 1 proposals (proposals with over $1M direct treasury impact or equivalent weight). The window is extended to 4 days post vote following @sid_areta’s feedback.\nSignal Threshold (optional community decision): Following @sid_areta’s feedback, the anti-spam filter is proposed as optional. The community will decide at the ARFC stage whether to include it or replace it with a simpler minimum forum presence requirement.\n\nProof of Contribution Path: Delegates performing off-chain work (tooling, research, forum infrastructure) can substitute the Communication and Signal thresholds via a Community Validated Monthly Update, endorsed by TL2+ forum members or recognized Service Providers.\nTier Structure:\n\nAligned Delegates: 20,000 VP or more, all thresholds met. Compensation: 5,000 GHO per month.\nRising Stars: Under 20,000 VP, all thresholds met. Compensation: 2,000 GHO per month.\n\nPillar 2: Frictionless Staking Delegation Prompt\nIntegrate a one step, non mandatory delegation prompt into the AAVE staking and supply UI at the moment of interaction. Users can skip, self delegate, or choose any delegate. No lockups. This pillar will be coordinated directly with Aave Labs as part of their expanded mandate under Aave Will Win. No separate budget is requested for this pillar.\n\nPillar 3: AAVE Delegate Charter\nInitiate a community led drafting process for a formal AAVE Delegate Charter. This will be a concise, ratifiable document (target: 5 to 10 pages) defining the delegate role, minimum duties, conflict of interest standards, and accountability mechanisms. Drafting is open to all forum contributors and ratification will follow the standard AIP process.\n\nPillar 4: Delegate Code of Conduct (New response to @stani)\nThis is the pillar that Orbit never had and the one @stani correctly identified as the most critical missing element.\nThe problem Orbit created: Delegates could be compensated for governance participation while simultaneously engaging in conduct that damaged the protocol (negative public commentary, disparaging partners, or undermining team morale).\nThe ADF solution: A binding Code of Conduct, ratified on-chain as part of the Delegate Charter, establishing:\n\nProhibited conduct: Publishing content that materially misrepresents Aave’s protocol, products, or team; deliberate attempts to damage Aave’s reputation or partner relationships; conduct designed to generate personal visibility at the protocol’s expense.\nRequired disclosures: Conflict of interest declarations for any vote where the delegate has a material financial interest; disclosure of any compensation received from third parties.\nCommunication standards: Minimum responsiveness to governance stakeholders including Labs. There is no requirement to agree, but there is a requirement to engage.\nAccountability mechanism: Documented violations reviewed by a community panel of TL4 forum members and Service Providers. Confirmed violations result in disqualification from the compensation program.\n\nBudget: Honest Reality vs. Maximum Cap\nThe cap is a governance commitment, not a forecast. It provides the DAO with transparency regarding the worst case cost of the program.\nHonest first cycle picture:\n\nComponent\nMax Slots\nRate\nQ1 Maximum\nRealistic Q1\n\nAligned Delegates\n8\n5,000 GHO/mo\n120,000 GHO\n15,000 GHO (1 candidate: Areta)\n\nRising Stars\n4\n2,000 GHO/mo\n24,000 GHO\n0 GHO\n\nADF Facilitator\n1\n7,500 GHO/mo\n22,500 GHO\n22,500 GHO\n\nTOTAL MAX\n\n166,500 GHO\n~37,500 GHO\n\nThe 166,500 GHO ceiling represents less than 0.17% of the Aave DAO treasury. The realistic Q1 spend of approximately 37,500 GHO is less than 0.038% of the treasury. For a protocol generating over $100M annually, this is a governance infrastructure decision rather than a budget discussion.\n\nThe Regulatory Case: A Compliance Asset, Not a DAO Expense\nThe ADF is not governance overhead; it is regulatory infrastructure. The environment for DeFi is tightening and Aave is already named in relevant documents:\n\nECB Working Paper No. 3208 identifies Aave’s governance concentration as a potential barrier to MiCA exemptions.\nSEC Interpretive Release 33 11412 defines decentralization as the lack of effective control by any group.\nH.R. 3633 (CLARITY Act) defines a decentralized system as transparent and rules based.\n\nAn independent, compensated, and rule bound delegate ecosystem is Aave’s most defensible proof of decentralization. It also protects Labs’ ability to execute freely, as a DAO with genuinely distributed power cannot be characterized as centrally controlled.\n\nSummary of Changes from v1\n\nTopic\nv1\nRevised\n\nCode of Conduct\nARFC commitment\nFormal Pillar 4\n\nAligned Delegate rate\n6,000 GHO/mo\n5,000 GHO/mo\n\nRationale window\n48h\n4 days post vote\n\nAnti-spam filter\nMandatory\nOptional community decision\n\nBudget framing\nMaximum cap\nMaximum cap and realistic Q1 explicit\n\nRegulatory framing\nSupporting argument\nCentral strategic rationale\n\nThis proposal was drafted by Apu Mallku. All feedback is welcome to strengthen Aave’s decentralization and regulatory defensibility for the long term.\n\n post by ST0X on Apr 7\n\n ST0X\n\n Some Observations:\nDuring ACI Era, most of the delegates failed to provide meaningful opinions/ valuable inputs. It became either you agree with Marc Zeller of ACI or get out from the orbit compensation list.\nWhat Stani mentioned earlier is a fundamental issue lies with Defi DAO structure. Most of the time, delegates’ interests are NOT aligned with protocol in the long term but serves the delegate’s own interest. It relys on delegates to act in good faith. I have witnessed some of the delegates that are dissent from ACI getting sidelined or just ignored.\nA better structure is needed to address this misalignment to make the mechanism work in the long term.\n\n post by r0mul0 on Apr 7\n\n r0mul0\n\n I echo what @ST0X said.\n(Also the suggested amount of 166,500 GHO is outrageus).\nRenaming from a DAO expense to a “Compliance Asset”, does not change the reality, this is DAO expense, an unnecessary tax burden.\nThe crypto space should be for builders, for lean teams with a clear vision and direction and ability to execute quickly.\nBeing the protocol profitable, this attracts people that, at least in some instances, have no merit, that often have their own agenda, enjoy playing politics, people that otherwise would have troubles finding a real job, rent seekers that found an easy way to get subsidized.\nA DAO should not be a welfare organization that provides an income to people that otherwise would be unemployed, this is a role already fulfilled by our national states.\n\n post by ApuMallku on Apr 10\n\n ApuMallku\n\n Thank you to everyone who has taken the time to read, review, and comment on this revised Temp Check. I especially want to thank those who provided constructive, protocol-focused feedback.\nI also want to acknowledge the more heated comments and ad-hominem attacks we’ve seen in the broader discussion. Rather than taking them personally, I believe they actually validate the core thesis of this proposal: they highlight exactly why establishing a Code of Conduct is so necessary for everyone.\nWe have lived through some very bad months. A lot of drama has happened, creating a massive snowball effect, and that kind of friction will take time to heal. I firmly believe we are entering a new chapter, but if we truly want to keep existing as a DAO, we need more decentralization, new actors committed with real ‘skin in the game,’ and a much healthier governance space. If we don’t achieve this baseline, we are destined to disappear “as a DAO” or whatever we choose to call ourselves in the future.\nI will leave this thread open over the weekend to provide a final window for any additional thoughts or feedback. If there are no major blockers, I will request to move this proposal to the Snapshot phase on Monday.\nHave a great weekend, everyone.\n\n post by stani on Apr 12\n\n stani\n\n Aave Labs-Technical SP\n\n As the revised proposal currently stands I would not be supportive of it. I do recognise that there is now code of conduct for delegates however, I don’t think the DAO should pay for delegates. Delegates should be someone who have skin-in the game enough to become a delegate or alternatively representatives of existing stakeholders and make agreements outside of the protocol. Not something the DAO should pay for.\nUnfortunately, I don’t think that the proposal is ready for voting or something that can get wide support but I do think that would be good to take the code of conduct and refine it as the first step while the governance is getting overhaul over the next months and part of that overhaul we can review the delegate ecosystem and ensure its aligned with the greater vision of the DAO.\n\n post by ApuMallku on Apr 12\n\n ApuMallku\n\n @Stani, thank you for the clear feedback and for laying out the macro vision for the upcoming governance overhaul.\nTo be realistic: without the direct support of Labs, moving this proposal forward to Snapshot would be an uphill battle that makes no sense to fight. The most reasonable path right now is to leave these ideas, especially the Code of Conduct, on the table for Labs to adopt and integrate into the direction you’ve decided to take.\nOn a personal note, I have to say I respectfully disagree with this approach. I firmly believe that strengthening decentralization and professionalizing the governance layer should be absolute pillars for Aave’s future, not an afterthought. Without a robust and decentralized governance structure, the DAO’s long-term resilience remains vulnerable.\nHowever, I understand where the wind is blowing and I respect the process. Given that there is no clear path or appetite right now for the infrastructure I was aiming to build, I will not be pushing this Temp Check to Snapshot, and I will be officially sunsetting my delegate platform effective immediately.\nMassive thanks to everyone who delegated to me and supported this vision. I have been here since the ETHLend days, and my only goal has always been to see Aave win. I will continue to support the protocol from the trenches.\n\n post by IndependentGuard on Apr 14\n\n IndependentGuard\n\n I like the overall direction of this proposal. The gap left by ACI is real, and having clear, measurable rules for delegates is a good step forward. That said, I’d like to see a few things clarified before we move to ARFC:\n\nWho actually checks if delegates meet the 85% participation and other criteria? I’d prefer a fully on-chain / automatic system instead of any human committee.\n\nThe “3 forum posts per month” rule feels easy to game. Maybe we can make it stronger (minimum word count or real peer review?).\n\nThe one-click delegation feature in the app sounds nice, but we need to know who builds it, how much it costs, and the timeline.\n\nThe foundation is solid, let’s just tighten these details first. Happy to support a stronger version in the next stage.\n\n post by JesusCryptoPlaza on Apr 14\n\n JesusCryptoPlaza\n\n The Role of Delegates in DAOs: Lessons from Traditional Corporate Governance\nI want to share some reflections as a conclusion after following this debate, drawing on the experience of corporate governance in traditional companies, which I think can shed light on what we are really discussing here.\nLeadership versus governance: context matters\nIn the corporate world, there is an important distinction that is often overlooked in discussions about DAOs: not all projects need the same type of governance. Mature companies managing established businesses with stable models and limited competitive pressure are the ones that benefit most from robust governance structures oriented toward safeguarding good practices. In that context, control and oversight mechanisms add real value.\nHowever, projects in a growth phase operating in highly competitive environments need above all clear strategic leadership. Aave fits better in this second category. The leadership Stani has historically exercised, and the recent momentum of the Aave Will Win framework, respond precisely to that need. In this context, adding layers of delegated governance may generate more friction than value.\nThe real risk: value capture by management\nOne of the most well-documented structural problems in companies managed by executive teams without significant capital participation is that management tends to capture a disproportionate share of the value created, rather than aligning it with shareholders. It is one of the reasons why founder-led companies or those with strong anchor shareholders have historically tended to create more long-term value.\nIn Aave’s case, there is a relevant differentiating element: the recent protocol design has explicitly oriented value creation toward the token. If leadership is genuinely aligned with token holders, the capture problem is naturally mitigated, which reduces the need for external oversight mechanisms.\nWhat can a delegate actually contribute? The uncomfortable question\nBeing honest, it is difficult to argue that a generic delegate can add real strategic value to a protocol of this complexity. In the corporate world, when someone external is brought onto a board, it is usually for a specific reason: sector experience, regulatory knowledge, network relationships, or concrete financial expertise. The criterion is verifiable merit, not participation itself.\nIn the usual definition of delegate in DAOs, that criterion does not seem to be present. Selection is not based on expertise; it is based, at best, on activity and forum visibility.\nThe function that does make sense, and that has a clear parallel in traditional corporate governance, is that of the minority shareholder advocate. Independent directors in listed companies exist primarily to ensure that management and large shareholders do not act to the detriment of minority holders. That role can have value in a DAO: someone who verifies the correct functioning of the protocol and protects the interests of small token holders who are underrepresented and who, in many cases, lack the capacity or information to vote in an informed way.\nIn practice, this turns the delegate into a kind of analyst or auditor who helps other token holders make informed voting decisions. A useful role, but a narrow one.\nThe structural agency problem\nHere is the core of the problem: if remuneration comes from the DAO itself, the delegate structurally becomes an extension of management, not an independent counterweight. It is the same problem that affects independent directors nominated and paid by the company they are supposed to supervise. Formal independence does not guarantee real independence.\nThe model that does have internal coherence is the opposite: large shareholders or token holders themselves remunerating the people who closely follow the protocol’s functioning and defend their interests. In many cases, for an institutional fund manager, the analyst already covering the project has the criteria to weigh in on votes. No additional layer paid by the DAO is needed; what is needed is for each large holder to activate the representation they already have.\nOpen Source Capitalism and the real nature of DAOs\nOne of the most precise definitions I have encountered for these structures is Open Source Capitalism. DAOs are organizations that should function as collaboratively maintained markets. That nature has direct implications for how to think about governance.\nIt is neither realistic nor probably desirable for everyone to vote on everything. It makes more sense for strategically relevant decisions to be broadly consulted, while many operational decisions are delegated by default to management or to large shareholders with real judgment and genuine interest. What matters is that there is transparency about who decides and why.\nThere is also a legal dimension that cannot be ignored: demonstrating decentralization allows these projects to operate under more favorable regulatory conditions, which in many cases forms part of their competitive advantage. In that context, delegates have sometimes functioned as a mechanism to distribute legal risk toward willing third parties in exchange for remuneration, whose real function was in many cases to approve whatever management proposed. That is not governance; it is cosmetic decentralization.\nTransparency as a genuine advantage\nWhat does distinguish DAOs from traditional companies, and where their potential for genuine governance lies, is structural transparency. All votes are public, all treasury movements are auditable, all arguments are on the record. That transparency, properly leveraged, forces greater meritocracy and makes it harder to sustain behaviors that in a traditional company might remain hidden for years.\nConclusion: we are in an experimental phase, and that is normal\nDAOs have demonstrated the ability to lead exponential growth in early stages. The maturation of their governance models is probably the stage that requires the most time, especially in solid projects that already generate real revenue. It is to be expected that these debates emerge precisely in projects that have reached a certain scale.\nThe market will show which governance structures produce better long-term results. There is probably no single answer, and different types of projects will find different equilibria. What does seem clear is that building from accumulated experience, including mistakes, is the only realistic path toward more optimal governance.\n\n 1 month later\n\n Closed on May 14\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n Notrustverify.ch Delegate Platform (sunsetted)\n\n Delegate Platforms\n\n 14\n\n 897\n\n Mar 23\n\n Apu Mallku [Delegate platform]: Shutdown \n\n Delegate Platforms\n\n 6\n\n 1.1k\n\n Apr 12","tokens":11534,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262906284,"hash":"63681c918f47a376f7abf5fa6c2604e4bee6ec17"}
{"url":"https://www.soliditylang.org/blog/2026/07/09/unsound-spill-in-mutual-recursion-bug/","domain":"soliditylang.org","title":"Unsound Spill In Mutual Recursion Bug | Solidity Programming Language","text":"Unsound Spill In Mutual Recursion BugPosted by Solidity Team on July 9, 2026Security AlertsOn May 11, 2026, clonker from the Solidity team discovered a bug in the Yul optimizer's call graph analysis.\nThe bug resulted in mutually recursive functions being sometimes misclassified as non-recursive, and therefore not being excluded from the memory spilling mechanism that is incompatible with recursive functions.\nThe mechanism relocates local variables to fixed memory offsets to work around the EVM's stack depth limit and would cause the spilled variables to be shared between all invocations of the same function.\nWe assign this bug a severity of medium on our internal scale.\nThe bug only affects the IR pipeline; the legacy evmasm pipeline is not affected.\nThe --via-ir flag is not enabled by default, so projects that have not explicitly opted into it are not affected.\nThe affected code has been reachable since Solidity 0.7.2, though the precise conditions required to trigger it change across the affected range (see Affected versions below).\nAll versions from 0.7.2 through 0.8.35 are affected.\nThe bug is fixed in Solidity 0.8.36.\nA scan of all --via-ir contracts in the Sourcify database (roughly 207,000 contracts) found 272 contracts (about 0.1%) containing a function that the analysis misclassifies.\nNone of these contracts relocate variables to memory inside the misclassified function, so no deployed contract is known to be affected.\nWhich Contracts Are Affected?\nA contract is only affected if all of the following conditions are met:\n\nit is compiled with --via-ir (or settings.viaIR in Standard JSON),\nit contains mutually recursive internal functions,\nthe recursive calls form two or more intersecting cycles sharing at least one function in the call graph (see technical details),\nthe processing order of the functions does not mitigate the issue--whether the misclassification occurs depends on the order in which the cycle-detection traversal visits the functions, which is determined by the hashes of their internal Yul names--,\nat least one of the functions wrongly classified as non-recursive is complex enough (uses enough simultaneously-live local variables) that the compiler relocates some of those variables to memory to satisfy the EVM's stack-depth limit, and\na corrupted variable influences an observable result.\n\nThese conditions are narrow and must all coincide, which is why the affected pattern is very uncommon in practice.\nIf your contract has no mutual recursion, it is not affected.\nOn Solidity 0.8.21 and later, the bug is independent of whether the optimizer is enabled.\nThe stack-to-memory relocation is a distinct stage of the IR pipeline that runs regardless of the optimizer setting, so disabling the optimizer does not avoid it.\nOn earlier affected versions (0.7.2–0.8.20), however, the Yul optimizer - and with it the stack-to-memory mover - only runs when --optimize is passed, so reaching the bug there requires both --via-ir and --optimize.\nTechnical Details\nThis section describes the compiler internals behind the bug for readers interested in the implementation-level root cause.\nAffected versions\nThe single 0.7.2-0.8.35 range in the summary glosses over some detail.\nThe faulty cycle detection was first introduced in a refactor in 0.6.12.\nAt that point, the code had only one consumer, the SideEffectsPropagator, where a misclassification has no observable effect.\nThe first consumer where the misclassification actually matters was in 0.7.2 with the StackLimitEvader, which is therefore treated as the first affected version.\nIn practice, we could only reproduce the miscompilation from 0.8.8 onward, or from 0.8.10 through the experimental --experimental-via-ir entry point.\nOn earlier versions our reproducer hits Stack-Too-Deep before the incorrect behavior can surface.\nWe could not construct a working reproducer below 0.8.8, but we also cannot prove that the bug is unreachable there, so we conservatively consider the entire range 0.7.2-0.8.35 to be affected.\nTwo further caveats about when the affected code can be reached:\n\nThe IR pipeline was experimental until 0.8.13; before that, using it required the experimental opt-in.\nBefore 0.8.21, the Yul optimizer and with it the stack-to-memory mover did not run unless --optimize was passed.\nThe bug is therefore only independent of the optimizer on 0.8.21 and later.\n\nRecursion and the stack-to-memory mover\nThe EVM can only directly access the topmost 16 stack slots.\nA function with many simultaneously-live local variables can exceed this limit, which historically reported as the \"Stack too deep\" error.\nTo reduce how often this happens, the IR pipeline includes a stack-to-memory mover (aka the \"stack limit evader\"):\nwhen a function cannot fit its variables on the stack, the compiler moves some of them to fixed memory offsets and replaces the stack accesses with mstore/mload to those offsets.\nThis relocation is only sound for functions that are not recursive.\nA fixed memory offset is shared by every activation of the function, so if a function holds a value in a fixed slot across a call and that call re-enters the same function (directly or through a cycle), the inner activation overwrites the slot and the outer activation reads back a corrupted value.\nFor this reason the mover must never relocate the variables of a function that is part of a recursive call chain.\nTo determine which functions these are, the compiler constructs a Yul call graph and runs a cycle detection algorithm on it.\nThe cycle-detection bug\nA function is recursive precisely when it is contained in a cycle in the call graph: either it calls itself directly, or it is part of a group of functions that can all reach one another (a strongly connected component).\nThe previous implementation in CallGraphGenerator computed this with a path-based depth-first search.\nWhile traversing, it kept the current path on a stack;\nupon reaching an invocation of a function already present on the stack, it marked that function and every other function called between the two invocations as \"contained in a cycle\".\nOnce all calls in the function had been fully explored, it was popped from the path and added to a set reflecting visited nodes (visited), and any later visit to it short-circuited immediately.\nThis short-circuit is unsound in the presence of intersecting cycles.\nThe traversal only records a cycle when it walks an edge back to a function still on the current path, and once a function has been fully explored it is marked visited and never re-entered.\nSo if a function's cycle can only be closed by passing through a node that was already finished as part of an earlier cycle, the traversal stops at that finished node before the second cycle closes.\nThe function is then reported as non-recursive - even though it was fully explored, and even though it genuinely is part of a cycle.\nConsider three functions:\nfunction a() { b(); c(); }\nfunction b() { a(); }\nfunction c() { b(); }\n\nAll three belong to a single strongly connected component:\na reaches c directly, and c reaches a through c -> b -> a, so every function can reach every other.\nAll three are recursive.\nThe traversal, however, can miss c:\n\nStart at a. Current path [a].\nDescend into b. Current path [a, b].\nb calls a, which is on the current path - mark {a, b} as contained in a cycle. Return, pop b, add b to visited.\nBack in a, descend into c. Current path [a, c].\nc calls b, but b is already in visited - short-circuit and return without inspecting it.\nPop c, pop a. The result is {a, b}. c was never marked.\n\nc is reported as non-recursive even though it lies on the cycle c -> b -> a -> c.\nWhether this happens depends on traversal order.\nThe cycle through c is only missed because b was discovered and marked as visited via the a -> b edge before the traversal reached it again through c.\nThe order in which callees are visited follows the ordering of the call graph's internal data structures, which is determined by the functions' Yul name hashes.\nA different set of names - and therefore a different ordering - may allow the algorithm to detect all three correctly, which is why the bug depends on the exact shape of and naming in the call graph.\nEffect on the generated code\nA misclassification only matters when the mover acts on the function the analysis got wrong.\nIf c above is simple, nothing is relocated and the code is correct. If it is complex enough to exceed the stack limit, the mover relocates its locals to fixed offsets, treating it as non-recursive.\nBecause c is recursive, the re-entry through c -> b -> a -> c overwrites those offsets as described above, and the outer activation reads back a corrupted value.\nExample\nThe following contract demonstrates the bug.\nIt is a minimal reproducer, arranged to meet the conditions above.\nA full reproducer can be found here.\ncontract C {\n uint256[26] public seed;\n\n function init() external {\n for (uint256 i = 0; i < 26; ++i) \n seed[i] = (i + 1) * 0x1111;\n }\n\n function trigger() external returns (uint256 storedAt3) {\n a(3);\n storedAt3 = seed[3];\n }\n\n function a(uint256 m) internal {\n if (m == 0) return;\n b(m);\n c(m);\n }\n function b(uint256 m) internal {\n if (m == 0) return;\n a(m - 1);\n }\n function c(uint256 m) internal {\n if (m == 0) return;\n uint256 v1 = seed[0] ^ m;\n uint256 v2 = seed[1] ^ m;\n // ... v3 .. v24 ...\n uint256 v25 = seed[24] ^ m;\n\n b(m - 1);\n\n // Reads m back from its (relocated) memory slot.\n seed[m] = m;\n // Keep v1..v25 alive across the b(m - 1) call.\n seed[25] = v1 + v2 + /* ... */ + v25;\n }\n}\n\nThis is the a/b/c graph from the trace above, so c is the function wrongly marked non-recursive.\nBecause c keeps 25 values live while the call into b(m - 1) is being executed, we run out of addressable stack slots and m gets relocated to memory and overwritten by the recursive invocation of c from within a before seed[m] = m reads it back.\nObserved behavior:\nC target = new C();\ntarget.init();\nassert(target.seed(3) == 0x4444); // seed[3] initialized to 4 * 0x1111\n\nuint256 result = target.trigger(); // a(3) should run seed[3] = 3\nassert(result == 3); // value the source code asks for\n// actual: result == 0x4444 - seed[3] was never correctly set to 3\n\nWith the bug, trigger() returns 0x4444 (the untouched initial value) instead of 3, because the corrupted m caused seed[m] = m to operate on the wrong index and value.\nSeverity Assessment\nThe compiler emits no warning, and the generated code does not revert at runtime.\nThe corruption manifests as an unexpected result rather than a failure, which can make it difficult to diagnose.\nHowever, projects that run their test suite with --via-ir before deployment are likely to observe the incorrect behavior, even if the root cause may not be immediately obvious.\nUnlike many past compiler bugs, this one can be triggered without inline assembly.\nIn practice the likelihood is very low.\nThe narrow conditions listed under \"Which Contracts Are Affected?\" must all coincide, and the Sourcify scan found no deployed contract that relocates variables inside a misclassified function.\nThe Fix\nThe fix replaces the path-based depth-first search with a standard algorithm for finding strongly connected components: Tarjan's algorithm.\nA function is now classified as recursive if and only if:\n\nit belongs to a strongly connected component containing more than one function (mutual recursion of any cycle length), or\nit calls itself directly.\n\nTarjan's algorithm partitions the call graph into strongly connected components in a single pass and does not depend on traversal order, so it reliably determines for every function whether it is contained in a cycle.\nWith the fix, all of a, b, and c in the example above are classified as recursive, and the mover leaves their variables on the stack.\n\"Stack too deep\" after the fix\nBecause the previous behavior was to (incorrectly) relocate variables of a recursive function, some contracts that compiled before the fix did so only by performing an unsound relocation.\nOnce those variables are kept on the stack, the function may exceed the 16-slot access limit, and the compiler will now report a \"Stack too deep\" error.\nThis is the correct behavior:\nthe recursion in question cannot be safely compiled by spilling to a fixed-size memory area.\nFor the reproducer above, the expected result after the fix is a \"Stack too deep\" error.\nA contract that newly fails to compile after upgrading to 0.8.36 in this way was miscompiled before, and the fix reports the underlying problem instead of silently generating incorrect code.\nRecommended Actions\n\nUpgrade to Solidity 0.8.36 or later before deploying contracts compiled via IR, particularly if they use mutual recursion.\nIf a previously-compiling contract now reports \"Stack too deep\" after the upgrade, the recursive function involved was being miscompiled.\n\nAcknowledgements\nThis bug was found and fixed internally by the Solidity team in the course of ongoing work on the IR pipeline's stack handling.Previous postNext post","tokens":3259,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262912873,"hash":"6e8f6ac99b840f974917881f075ef4442339147e"}
{"url":"https://governance.aave.com/t/temp-check-aave-delegate-ecosystem-upgrade-the-aligned-delegates-framework/24357/1","domain":"governance.aave.com","title":"[TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework - Governance - Aave","text":"[TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Abstract\n\n Background & Motivation\n\n Core Pillars\n\n Capturing Intangible Value: The “Proof-of-Contribution” Path\n\n Pillar 2 — Frictionless Staking Delegation Prompt\n\n Pillar 3 — AAVE Delegate Charter: A Formal Baseline for Delegates\n\n Preliminary Budget & Compensation Breakdown (3-Month Pilot)\n\n Implementation: A Lean Team Built for Execution\n\n Key Areas for Community Feedback\n\n Mar 27\n\n 1 / 26\n\n Mar 28\n\n Apr 14\n\n post by ApuMallku on Mar 27\n\n ApuMallku\n\n Author: Apu Mallku - Independent Delegate Platform\nStatus: TEMP CHECK - Seeking Community Feedback\nDate: March 2026\nAbstract\nWith the Aave Chan Initiative (ACI) stepping back from delegate coordination, AAVE’s governance ecosystem faces a structural gap. This is not a crisis — it is an opportunity to upgrade the system rather than replicate its predecessor.\nThis proposal introduces the Aligned Delegates Framework (ADF): a three-pillar upgrade to how AAVE governance identifies, rewards, and empowers its most dedicated governance delegates. The ADF moves beyond purely quantitative voting metrics toward an automated, objective baseline of governance value. It also reduces passive voting power through a frictionless delegation prompt at the supply/staking level, and initiates the drafting of the AAVE Delegate Charter — a focused baseline document defining the expectations for an aligned delegate.\nThis Temp Check seeks directional feedback before committing to full specification work. Specific implementation details, budget, and timelines are open for discussion and marked accordingly.\nBackground & Motivation\nAAVE governance suffers from compounding problems:\n\nThe Quantitative Trap: The current Orbit program measures delegate eligibility primarily through on-chain voting participation rates (e.g., ≥85%). This creates an incentive to vote without engaging: delegates who vote on every proposal without contributing analysis or rationales can outrank delegates who add genuine intellectual value. Governance quality cannot be measured by volume alone.\nStructural Voter Apathy: Supplying and staking AAVE, and delegating voting power, are entirely separate, disconnected actions. The vast majority of suppliers and stakers never delegate. This is not a moral failure — it is a rational response to high friction. The result is voting power permanently concentrated among a shrinking set of actors, increasing governance capture risk.\nUndefined Delegate Standards: There is no formal document establishing what is expected from an AAVE delegate beyond showing up to vote. Duties, conflict-of-interest disclosures, and minimum engagement standards exist only as implicit norms.\nThe Post-ACI/BGD Vacuum & Public Drama: The departure of ACI and BGD leaves a significant coordination void. While Aave Labs is stepping up to take a broader role (as outlined in the AAVE WILL WIN framework), a healthy DAO cannot rely on a single entity. Governance vacuums breed uncoordinated public drama, which damages the DAO’s reputation, impacts the token’s value, and directly benefits competitors. We need a system that retains existing high-value talent, attracts new contributors, and replaces informal social friction with healthy, rule-based politics.\nThe Regulatory Imperative for Decentralization: A robust delegate ecosystem is no longer just “good governance” — it is a regulatory necessity. SEC Interpretive Release 33-11412 (March 17, 2026), jointly issued with the CFTC, defines a “decentralized” crypto system as one that operates autonomously with no person or group having operational, economic, or voting control. Simultaneously, H.R. 3633 (the CLARITY Act), which passed the U.S. House and is advancing through the Senate, formally defines a “decentralized governance system” as one that is transparent, rules-based, and where participation is not under the effective control of any person or group. To protect AAVE’s status as a digital commodity and avoid centralization risk under these frameworks, we must proactively empower delegates and distribute voting power. True decentralization requires active, compensated, and independent actors.\n\nCore Pillars\nPillar 1 — From Voting Volume to the “Aligned Delegate Baseline”\nTo address concerns that evaluating delegate “quality” is subjective and resource-intensive, the ADF avoids human grading committees entirely. Instead, it replaces the purely quantitative model with the Aligned Delegate Baseline (ADB) — a set of binary, fully automatable Minimum Engagement Thresholds (inspired by the successful framework used by MakerDAO/Sky).\nTo qualify for Orbit v2 compensation, a delegate must meet objective Yes/No metrics tracked automatically via APIs (like Dune or Snapshot) every quarter:\n— The Voting Threshold: ≥85% participation on all on-chain AIPs and Snapshot ARFCs.\n— The Communication Threshold: Must publish a public “Voting Rationale” for at least 75% of Tier 1 proposals (proposals with >$1M impact). A rationale is objectively verified as a forum reply published within 48 hours of a vote.\n— The Signal Threshold (Anti-Spam): To ensure forum contributions aren’t just AI-generated noise to meet quotas, a delegate must maintain an active forum presence where at least 3 of their posts per month receive a minimum of 3 likes/reactions from forum users at Trust Level 2 (Regular Member) or above — automatically verifiable via the Discourse API. TL2 requires genuine account history and activity, making it resistant to freshly created sock puppet accounts. The community acts as the decentralized filter for quality.\nCapturing Intangible Value: The “Proof-of-Contribution” Path\nA purely quantitative system risks ignoring off-chain heavy lifters — delegates who provide massive value by building tools, conducting data analysis, or moderating the forum (e.g., maintaining infrastructure, installing plugins). To ensure these vital contributors can achieve delegate status without introducing subjective grading committees or adding operational overhead to core contributors, the framework introduces a “Community-Validated Proof of Contribution”:\n— Delegates performing off-chain or operational work publish a “Monthly Delegate Update” on the forum detailing their specific contributions.\n— If this update thread achieves a predefined Community Endorsement Threshold, the system’s API automatically marks their Communication and Signal metrics as fulfilled for that month. To be counted, endorsements must pass strict Sybil-resistance checks using at least one of the following filters — both fully automatable via Dune and the Discourse API:\n— Trust Level Filter: The AAVE forum runs on Discourse, which automatically assigns Trust Levels (TL0–TL4) based on account age and activity. Bots and new accounts are TL0. Only endorsements from users at TL2 (Regular Member) or above are counted. This filter eliminates freshly created sock puppet accounts at zero cost.\n— Web of Trust Filter: Only endorsements from Aligned Delegates or recognized Service Providers (e.g. BGD, Chaos Labs) with publicly disclosed on-chain addresses count toward the endorsement total. This restricts the endorser pool to actors with public identity and reputational skin in the game.\nGaming this threshold requires either years of genuine forum participation to reach TL2, or colluding with named, compensated, publicly known entities — both of which carry direct reputational cost. No human committee is needed.\nThis mechanism ensures that technical and administrative work is recognized and compensated, while keeping the evaluation process 100% decentralized, objective, and zero-maintenance for Labs.\nPillar 2 — Frictionless Staking Delegation Prompt\nIntegrate a one-step delegation prompt into the AAVE staking/supply UI (app.aave.com), displayed at the moment of interaction.\nHow it works:\n— When a user supplies or stakes AAVE, they are shown a non-mandatory prompt: “Activate your voting power — delegate to a verified AAVE delegate.”\n— Delegation is executed in the same transaction or as a one-click follow-up. Users can skip, choose any delegate, or self-delegate. (No lockups involved).\nCuration of the Delegate Shortlist\nThe shortlist displayed in the prompt is algorithmically generated from on-chain ADB data. To prevent governance monopolization and empower small players, the prompt will display a randomized mix of up to 12 delegates:\n— Aligned Delegates (8 Established Slots): Delegates with ≥20,000 voting power who meet all baseline thresholds.\n— Rising Star Delegates (4 Fresh Slots): Reserved for delegates with <20,000 voting power who meet all baseline thresholds. The goal of this tier is talent retention: recognizing and valuing the hard work of smaller delegates who maintain a healthy governance environment, ensuring they don’t leave the ecosystem due to a lack of visibility. Delegates who qualify via the Community-Validated Proof-of-Contribution path are eligible for Rising Star Slots on equal footing with those who meet the binary thresholds directly. The Proof-of-Contribution path substitutes the Communication and Signal thresholds — but candidates must still be active as aspiring delegates with a public delegate profile thread on the forum.\n\nNote: Rising Star eligibility requires an established contribution history. The Voting and Communication thresholds together represent the majority of the ADB requirements, meaning Rising Star Slots are designed for delegates who are already active contributors but have not yet accumulated sufficient delegated voting power. Truly new entrants will need at least one full governance cycle of active participation before becoming eligible.\n\nPillar 3 — AAVE Delegate Charter: A Formal Baseline for Delegates\nCurrent state: There is no document that formally defines what an AAVE delegate is expected to do, disclose, or commit to. The delegate role is entirely self-defined, making it impossible to hold delegates accountable beyond social pressure.\nProposed change: Initiate a community-led drafting process for the AAVE Delegate Charter — a concise, ratifiable document (target: 5–10 pages) focused exclusively on the delegate role and the decentralization of governance power.\nScope of v1:\n— Delegate Role Definition: The distinction between passive token holders, active delegates, and Orbit-tier delegates.\n— Minimum Delegate Duties: Voting participation thresholds, rationale publication, conflict-of-interest disclosures, and communication of prolonged inactivity.\n— Delegation Principles: Guidelines encouraging decentralization of voting power, including recommended concentration limits and the right of delegators to information about delegate performance.\n— Delegate Accountability: The process by which delegates can lose their status, and their rights to contest such decisions.\n— Amendment Procedure: Snapshot supermajority (67%) with a 5-day minimum discussion window.\nWhat This Is NOT: This is explicitly not a broad governance constitution, a Service Provider accountability framework, or an attempt to replicate the Sky Atlas. The scope is intentionally narrow: professionalizing the delegate ecosystem and protecting AAVE through rigorous decentralization of voting power.\nDrafting process: Open recruitment from the forum. The proposal author is one voice among equals — no editorial authority or final approval. All drafting is done in a public document with open comment access. Ratification via standard AIP process. v1 draft target: 90 days from ADF ratification.\nPreliminary Budget & Compensation Breakdown (3-Month Pilot)\nTo ensure a smooth transition from the current Orbit program and to prove the ROI of the Aligned Delegates Framework (ADF), this proposal requests a 3-month pilot budget.\nBy shifting from a pure “VP-based” compensation model to an “Objective Threshold” model (inspired by MakerDAO/Sky’s capital-efficient delegate compensation), the DAO ensures it only pays for active, verified governance labor. If a delegate fails to meet the baseline thresholds in a given month, their compensation for that month is forfeited and remains in the AAVE Treasury.\nThe proposed budget is denominated in GHO to support Aave’s native stablecoin ecosystem.\n\nDelegate Compensation Pool\n\nAligned Delegates (Up to 8 slots) — Compensation: 6,000 GHO / month per delegate. — Quarterly Max: 144,000 GHO. — Rationale: Matches standard Orbit-tier compensation for large, highly active delegates holding ≥20k VP who consistently meet all voting and communication thresholds.\nRising Star Delegates (Up to 4 slots) — Compensation: 2,000 GHO / month per delegate. — Quarterly Max: 24,000 GHO. — Rationale: 50% of the Aligned tier. This creates a sustainable path to retain high-value, low-VP contributors (like forum moderators, analysts, and active smaller delegates) via the Community-Validated Proof of Contribution path.\n\nOperational & Implementation Core\n\nADF Facilitator & Data Lead (Apu Mallku) — Compensation: 7,500 GHO / month. — Quarterly Total: 22,500 GHO. — Rationale: To maximize execution speed, ensure capital efficiency, and maintain a single point of accountability for this 3-month pilot, this proposal consolidates the coordination and data analysis roles into a single mandate.\nCore Objectives & Responsibilities:\n— Delegate Coordination & Mediation: Act as the neutral liaison between the delegate ecosystem and Core Contributors. Host and manage bi-weekly Delegate Syncs to align on complex ARFCs/AIPs.\n— Charter Drafting (Pillar 3): Lead the community drafting, review, and ratification process for the AAVE Delegate Charter (v1) within the 3-month pilot window.\n— Automated Pipeline Engineering: Build, deploy, and maintain the automated data pipelines connecting Snapshot (GraphQL), Discourse (Forum API), and On-chain data (Dune Analytics/The Graph) to objectively track the Baseline Thresholds.\n— Transparent Monthly Reporting: Publish the monthly “ADB Threshold Report” on the forum, detailing exactly which delegates met the automated binary metrics to trigger their compensation.\n— Open-Source Accountability: Maintain a public GitHub repository hosting all tracking scripts. Because all data inputs are public, any DAO member will be able to run the script and independently audit the monthly results, ensuring zero human bias and complete decentralization of the evaluation process.\n\nBudget Summary & Capital Efficiency\n\nCategory / Role\nMonthly Cost (Max)\n3-Month Pilot Total (Max)\n\nAligned Delegates (Max 8 slots at 6k/mo)\n48,000 GHO\n144,000 GHO\n\nRising Star Delegates (Max 4 slots at 2k/mo)\n8,000 GHO\n24,000 GHO\n\nADF Facilitator & Data Lead (1 at 7.5k/mo)\n7,500 GHO\n22,500 GHO\n\nTOTAL MAXIMUM ASK\n63,500 GHO\n190,500 GHO\n\nNote: 190,500 GHO is the absolute maximum cap for the quarter. The proposed slots (8 Aligned, 4 Rising Stars) represent a maximum capacity, not a guaranteed quota. If the ecosystem does not yield enough candidates who meet the strict baseline thresholds, these slots will simply remain unfilled, and the actual expenditure will be strictly lower. Any funds from unfilled slots, or unearned funds from delegates missing their monthly metrics, will remain securely in the AAVE Treasury, ensuring strict capital efficiency.\n\nAt the conclusion of the 3-month pilot, the ADF Facilitator will publish a full performance report on the forum. If the pilot demonstrates clear ROI — measured by delegate participation rates, rationale quality, and delegation prompt adoption — a renewal ARFC will be submitted for the following quarter.\nImplementation: A Lean Team Built for Execution\nThe ADF is designed to move fast. No standing committees, no multi-month scoping exercises. By consolidating the operational and data roles, we ensure maximum accountability and execution speed.\n— ADF Facilitator & Data Lead (Apu Mallku): A single unified mandate handling both strategy and technical execution. Responsibilities include drafting the Delegate Charter, organizing bi-weekly Delegate Meetings, acting as a neutral bridge between Labs and the delegates, and building the automated data pipelines (Snapshot/Discourse/Dune APIs) to track the Baseline Thresholds. Activates immediately upon ARFC approval.\n— Frontend Contributor (ad-hoc / Labs?): A developer tasked exclusively with executing the UI integration for the Pillar 2 delegation prompt. No budget is requested for this role in the current proposal. The preferred implementation path will be coordinated with Aave Labs first. If Labs is unable to absorb this task into their current workflow, a separate, targeted budget request will be submitted to the DAO to fund an independent developer.\nCritically: the ADF Facilitator role activates immediately upon ARFC approval — not after all pillars are built — filling the coordination vacuum left by ACI from day one.\nKey Areas for Community Feedback\nThe purpose of this Temp Check is to gather directional consensus on the Delegate Framework. The preliminary budget presented above strictly covers governance participation and coordination.\nWe specifically invite delegates, Aave Labs, and the community to weigh in on the following strategic points before we lock in the final specifications for the ARFC stage:\n\nThreshold Calibration: Are the proposed baselines (85% voting participation and 75% rationale publication) the right balance for an automated system, or should they be adjusted?\n\nThe “GovOps” Vacuum: With ACI and BGD stepping back, there is a clear vacuum in day-to-day operational work (e.g., forum moderation, tool maintenance) that falls outside standard delegate duties. While Aave Labs will take on broader roles, the exact boundaries remain undefined. Should the TEMP CHECK include a separate “Governance Operations (GovOps)” compensation track to ensure contributors performing this critical off-chain work are fairly compensated without draining the Delegate budget?\n\nPillar 2 Implementation: Given ongoing transitions, what is the most efficient path for developing the UI for the staking delegation prompt? Should this be coordinated internally with Aave Labs, or should the DAO explicitly fund an independent frontend developer in the ARFC?\n\n—\nThis proposal was drafted by Apu Mallku. All feedback, including critical feedback, is welcome on the forum. The goal is simple: a small team, a clear mandate, and fast execution in service of a stronger, decentralized delegate ecosystem.\n\n Apu Mallku [Delegate platform]: Shutdown \n\n 7\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n post by MconnectDAO on Mar 28\n\n MconnectDAO\n\n Supportive of the overall direction here. Moving from pure voting-volume metrics to an automated Aligned Delegate Baseline + Rising Star track feels like the right next step post-ACI/BGD, especially with the new decentralization guidance (SEC 33-11412, CLARITY Act) in mind. Would just flag two points for refinement: clarity on how the 85% threshold treats abstain/technical constraints, and a gentle ramp‑up for new Rising Star entrants so we don’t unintentionally filter out emerging delegates. Happy to contribute on the Charter side, particularly around multi-chain governance risk and anti-capture safeguards.\n\n post by ApuMallku on Apr 1\n\n ApuMallku\n\n Now that the Temp Check has been live for a few days and the community has had time to digest the framework, I’d like to formally invite feedback from the key stakeholders who are most directly impacted by this proposal.\nHearing your perspectives on the operational feasibility, the proposed baselines, and the GovOps transition is crucial before we request a Snapshot vote:\n@sid_areta @Ignas @EzR3aL @Kene_Anode @WintermuteGovernance @phenk53 @ACI\nLooking forward to your thoughts!\n\n post by Kene_Anode on Apr 1\n\n Kene_Anode\n\n Orbit-Delegate\n\n Overrall very supportive of this proposal, only thing I would flag is possibly considering refactoring the compensation gap between aligned delegates an rising star delegates, currently Orbit delegates earn $5k/month, instead of increasing that to $6k, I would up for aligned delegates to earn $5k/month, while rusung star delegates earn $3k/month, the gap being 50% less is wide enough in my opinion.\n\nRegarding these three issues, here are my thoughts.\n\nThreshold Calibration: A minimum of 85% participation and communication rates makes sense, delegates have to vote and communicate within a reasonable time.\nThe “GovOps” Vacuum: Yes, the TEMP CHECK should include a separate Governance Operations compensation track. With ACI and BGD stepping back, the day-to-day operational work that kept the DAO functioning (forum moderation, tool maintenance, proposal lifecycle management, Guardian coordination) risks falling into a gray zone. Aave Labs has committed to absorbing roughly 40 functions from both departing service providers, but the exact boundaries of what they will and won’t cover remain undefined. That ambiguity is the problem. Off-chain governance work is unglamorous but essential, and without a dedicated compensation track it either goes uncompensated (and eventually undone) or gets quietly absorbed into the Delegate budget, diluting resources meant for voting and strategic oversight. A dedicated GovOps track would make this work visible, attract contributors with the right operational skill set, and create clear accountability for deliverables that are distinct from what delegates or Aave Labs are expected to do. The cost of formalizing this is small relative to the cost of letting critical infrastructure degrade during the transition.\nPillar 2 Implementation: Staking Delegation UI: The most efficient path is to coordinate this directly with Aave Labs as part of their expanded mandate under the Aave Will Win Framework. The key consideration is that the staking delegation prompt needs to be tightly integrated with the protocol’s staking contracts and governance infrastructure, which Aave Labs already maintains. Splitting this across an independent developer introduces coordination overhead that likely outweighs the governance benefits of separation.\n\n post by phenk53 on Apr 1\n\n phenk53\n\n ApuMallku\n\n I support this proposal. Currently, participation among Orbit delegates is quite limited, with only a few active contributors standing out. This is exactly where the proposal provides a meaningful improvement. In particular, introducing a lower tier makes a lot of sense, as it allows smaller delegates below the 20,000 AAVE threshold to actively participate and gain visibility in governance. This would help broaden participation and strengthen decentralization over the long term.\n\n post by ApuMallku on Apr 1\n\n ApuMallku\n\n Thank you all for the constructive energy and thoughtful feedback so far. It is exactly this kind of engaged debate that the Aligned Delegates Framework is trying to foster and protect.\nI’ve read through the points raised and wanted to address them while opening up a few questions for the broader community before we move to the Snapshot stage. My idea is to leave a wider window than the typical TEMP CHECK due to ETH CC and other events that are taking place right now:\n@phenk53 — Thank you for the support. You nailed the exact motivation behind the Rising Star tier. Relying solely on the 20k VP threshold historically risks leaving out incredible talent. By lowering the barrier for active contributors, we ensure decentralization isn’t just a buzzword, but a pipeline for new talent. Open question to you and the community: When defining the “Community-Validated Proof of Contribution” for these smaller delegates, are there specific off-chain activities (e.g., DAO tooling, forum moderation) that you believe should carry the most weight?\n@MconnectDAO — Appreciate the insights and your willingness to help draft the Charter! To clarify your first point: yes, voting ‘Abstain’ is absolutely an active governance stance and will fully count toward the 85% participation threshold. We will also ensure the automated scripts include exception parameters for widely recognized technical constraints (meaning, if Snapshot goes down, delegates won’t be unfairly penalized for third-party infrastructure failures). Regarding the gentle ramp-up, that is precisely the goal of the Proof-of-Contribution path—allowing new entrants to build reputation before hitting the hard VP metrics.\n@Kene_Anode — Fantastic analysis. You’ve brought up critical structural points that deserve broad consensus:\n\nThe Compensation Gap: Your suggestion to adjust to 5k/month (Aligned) and 3k/month (Rising Star) is highly compelling. Not only does it value the emerging tier more aggressively, but it is literally more capital-efficient for the DAO’s maximum budget. (At max capacity, the original 6k/2k split costs 56,000 GHO/mo, whereas the 5k/3k split costs 52,000 GHO/mo—saving the DAO 4,000 GHO monthly). I’d love to hear from other delegates on this: does the 5k/3k split feel like the right equilibrium to lock in for the TEMP CHECK?\nThe “GovOps” Vacuum & Pillar 2 UI: You articulated the ‘gray zone’ perfectly. Unglamorous operational work cannot just be quietly absorbed by the delegate budget, and introducing an independent developer for Pillar 2 adds unnecessary coordination overhead and security friction. This brings us to a critical point where we need clarity from Core Contributors.\n\n@AaveLabs — As we navigate this transition post-ACI/BGD, we would love to get your perspective on two key areas regarding the Aave Will Win mandate:\n\nFirst, on GovOps: While it is crucial and expected that Labs absorbs the majority of protocol-level tasks, we believe that everything strictly related to DAO sovereignty—such as delegate coordination, governance tooling, and DAO treasury management—should remain heavily decentralized. Could you share some clarity on where Labs draws the boundary for these specific DAO-operational tasks moving forward?\nSecond, on Pillar 2 (Staking Delegation UI): We agree with the feedback that this UI integration should be coordinated organically with the Labs team. If this framework is approved by the DAO, would Aave Labs be willing/able to co-participate in developing this specific UI integration?\n\nLooking forward to hearing everyone’s thoughts on these adjustments!\n\n post by MconnectDAO on Apr 2\n\n MconnectDAO\n\n @ApuMallku — Thank you for the detailed clarifications. Happy to contribute to the Charter drafting, especially around participation metrics and exception handling.\nOn Compensation (Q1): I lean toward the 5k/3k split. The reasoning is simple if we want genuine decentralization of governance influence, we need to make the Rising Star tier financially viable, not just symbolic. A delegate doing serious research and voting consistently deserves stability. The 4,000 GHO/month saved vs the 6k/2k model can be redirected toward Proof-of-Contribution incentives or the GovOps function.\nOn Proof-of-Contribution (Q2): I’d suggest weighting the following off-chain activities:\n\nGovernance research & analysis published publicly (Paragraph, Mirror, Forum posts)\n\nVoting rationale documentation (not just voting, but explaining the vote)\n\nCommunity onboarding & delegate education\n\nCross-DAO governance participation (Arbitrum, Uniswap, etc.) that brings learnings back to Aave\nThe key metric shouldn’t just be quantity of contributions but verifiability can it be independently confirmed?\nOn GovOps Vacuum (Q3): This is the most urgent gap. Until Pillar 2 tooling is live, I’d recommend the Charter explicitly define a temporary manual review process perhaps a small multisig or working group so the framework doesn’t stall at launch.\nExcited to see this move to Snapshot. Ready to assist with Charter drafting whenever needed.\n@MconnectDAO\n\n@ApuMallku @Kene_Anode @phenk53 @AaveLabs\n\n post by EzR3aL on Apr 2\n\n EzR3aL\n\n Regular\n\n Cannot really add much to it as this proposal is already very detailed and other already gave great feedback.\nRegarding discourse API Im happy to support here and see what needs to be done so its working properly.\nRegarding the compensation I lean more towards a 5/2k model.\nOrbit delegates are important to reach quorum on proposals so it makes sense to give them a higher compensation, but I don’t think 6k are needed, just keep the same level.\nFor rising stars I think 2k is more than enough. If someone is doing a lot extra work the DAO could consider giving a retro active payment or create a tiered system.\nSo especially for rising stars we would need clear rules for tasks and their fair compensation.\nOther than that, great job @ApuMallku\n\n post by 0xlide on Apr 2\n\n 0xlide\n\n I oppose this proposal for the following three reasons:\n\nSpending 190k GHO on delegate rewards for a 3-month period is excessive.\nI don’t believe it’s a very good culture if only some voters get incentives.\nThe reward should be paid in $AAVE with performance conditions, not GHO.\n\n post by sid_areta on Apr 2\n\n sid_areta\n\n Orbit-Delegate\n\n We welcome this initiative and thanks @apumallku for leading the effort.\nAligned Delegate Baseline\n\nWe are supportive of this direction and look forward to seeing how it improves the quality of forum contributions from larger delegates.\n\nTimeline for Rationale Publication: It is sensible to require that rationales are published within a pre-defined timeframe, as it reduces the likelihood of after-the-fact justifications for passive votes. However, we believe the 48-hour window is extremely short and should be extended. Given the frequency of votes and the short voting window for Aave proposals (~3 days), a 48-hour publication window significantly increases the operational burden on delegates. We recommend extending the timeline to within 4 days after a vote closes. This is more practical and better aligned with standard practice across leading DAOs such as Arbitrum, where a similar rationale publication window is in place.\n\nAnti-Spam Filter: While filtering out low-quality contributions is a legitimate goal, we view this specific metric as gameable and unlikely to deliver reliable signal. Across many delegate programs we have observed in other DAOs, engagement metrics of this type tend to be noisy, carry little meaningful signal, and fail to reflect the actual value of a contribution. We would recommend removing it as a required threshold.\n\nHigh-impact Proposals: The proposal defines Tier 1 proposals as those with “>$1M impact,” but does not clarify how this threshold is determined in practice. In some cases, quantification is straightforward, for example a proposal requesting a direct treasury disbursement of $1M or more. However, many consequential proposals carry indirect or non-monetary impact that is harder to size, such as parameter/technical updates, or even governance process reforms. Who determines whether a given proposal crosses the $1M threshold, and how?\n\nOne-Step Delegation Prompt\n\nWe view this as a meaningful UX improvement. It directly reduces the friction associated with activating voting power, and given ongoing community discussions around voting power transparency and concentration, we are supportive of any step that makes the delegation process more seamless. The randomized display of delegates within the prompt is also a welcome design choice.\n\nAave Delegate Charter\n\nA charter defining delegate roles, responsibilities, and standards is good governance practice, and one we have seen adopted across leading DAOs. We fully support its introduction for Aave DAO.\n\nResponses to Specific Feedback Questions\n\nAre the proposed baselines (85% voting participation and 75% rationale publication) the right balance for an automated system?\n\nWe think the proposed baselines reflect a fair and reasonable balance.\n\nShould the Temp Check include a separate GovOps compensation track?\n\nWe think a dedicated GovOps budget is sensible in principle. However, we are conscious that the scope of responsibilities here may be relatively light given that Aave Labs is filling key operational gaps left by ACI and BGD’s exits. Any GovOps budget request, including a clear scope of work, should be submitted as a separate Temp Check and not bundled with this delegate framework proposal.\n\nShould Pillar 2 UI development be coordinated with Aave Labs or funded via an independent developer?\n\nThis should be coordinated internally with Aave Labs, as it directly concerns updates to the Aave App’s UI and functionality.\n\n post by Ignas on Apr 3\n\n Ignas\n\n Orbit-Delegate\n\n Thanks for the proposal, a lot of thoughtful work here @ApuMallku\nOn the Compensation gap, I lean toward the 5k/2k split. This is more balanced and clearly more capital efficient for the DAO. Orbit Delegates can anchor their value around hitting the thresholds, while rising stars bring a different kind of value, marketing, X posts, fresh ideas, and community building.\nPlease make sure we clearly define what tasks qualify and how those contributions are measured.\n\n post by r0mul0 on Apr 3\n\n r0mul0\n\n I am also skeptical about this proposal.\nIt does not seem a good idea to use GHO for rewards and the total amount seems very high as well.\nI’m afraid this could become another easy way to milk the DAO, similarly to what ACI has done in the past. I do not see any structural gap to fill.\nRegarding forum contribution, until freedom of speech is restored in this forum it does not seem fair to use the forum to measure rewards: accounts that are not in line with certain story telling are labelled as “fake” or “sponsored” by current moderators.\nMy posts have been censored and my account has been put on hold just for expressing my opinion, while at the same time all kind of insults and insinuations were made against some individuals and organizations without any action been taken.\nUntil this forum becomes again a non toxic place, where everybody can express freely his opinion, without censorship, I see very problematic the idea of rewarding forum participation (given this is only possible for someone and restricted for people not in line with current moderators).\n\n post by stani on Apr 4\n\n stani\n\n Aave Labs-Technical SP\n\n While I do think that active participation from token holders, directly or indirectly, is valuable, I believe this proposal does not serve the direction of Aave well and does not set the foundations for success.\nWith this proposal, the problem goes even further, as it requires more analysis, more discussions, more opinions, and fewer agreements and execution steps just to qualify for the program while creating execution bottlenecks. Of course, AI is likely to make this problem even worse.\nSecond, we should strive to move away from creating political corners within the DAO and instead push toward a single shared vision. While it’s okay to have different ideas within a DAO and to debate those amongst ourselves, it should still be done as a team and in a manner that is similar to healthy employee debates. This is the only way we can compete with well structured hierarchical companies or new entrants that carry less governance overhead.\nWhile I do appreciate that the proposal includes delegate standards, which is a positive step, it does not address the primary problem of conduct. I have been monitoring the existing Orbit campaign and am struggling to see the value in it as currently structured. Existing Orbit delegates can be paid while writing negative commentary on socials about Aave, saying disparaging things about partners, and mocking work done by teams that are building and making other high leverage contributions to Aave. In the grand scheme of things, this has many negative consequences that are difficult to quantify, can affect morale in the DAO, and can affect how people see the AAVE token.\nImagine a similar scenario where a company pays an employee or contractor to provide value, and they intentionally create negative value instead. This is a structural issue tied to how program incentives are designed. Delegates face incentives to create controversy because it gains them visibility, engagement, and that in turn can lead to delegated support.\nThird, there is no real vetting of delegates and their backgrounds. Everyone has opinions, but what truly matters is merit, which should be the basis for having a seat at the table.\nAdditionally, all the UI related work mentioned does not make sense to me. These products should focus on users who are actively using the protocols, not on delegation mechanics. Delegation infrastructure has very little to do with understanding user behavior or growing the products themselves.\nI do believe delegates can be compensated, but it should not become a burden for the DAO to run what effectively becomes a political system that creates more drag on execution than value. For example, teams should have sufficient autonomy to execute, with results reviewed periodically. This could be arranged outside of Aave, for instance delegates could make direct agreements with token holders they represent, with those relationships being economically incentivized.\n\n post by Millesimillia on Apr 4\n\n Millesimillia\n\n I concur with r0mul0 and stani. The current delegation infrastructure seems sufficient and I would not want to spend money on extensions. The reason is that token holders should be fully responsible for decision-making. The only exception is probably treasury tokens, which would introduce a recursive element if being used for voting (so they should not be used for voting). If some individuals want to delegate they can do so already today. No need for more in my opinion.\n\n post by ApuMallku on Apr 4\n\n ApuMallku\n\n Thank you to everyone for keeping this debate at such a mature and technically precise level. As an independent delegate, my only compass is the long-term resilience and value of AAVE.\nWe are at a foundational moment. The “Aave Will Win” framework tacitly accepts what many of us have been arguing for months: Token = Equity. The AAVE token now directly captures the economic value and participation rights of the protocol. I voted in favor of it, along with the v4 license and its activation, as a deliberate tabula rasa. The frictions of the past stay in the past. My commitment to the token’s growth is absolute.\nBut for this new chapter to work, two things must happen simultaneously: Labs must execute with ambition, and the DAO must decentralize governance power with equal urgency. These are not competing goals; they are the two legs of the same race. The ECB’s Working Paper No. 3208 already placed a regulatory bullseye on Aave’s concentrated voting power. The SEC’s Interpretive Release 33-11412 and the CLARITY Act define decentralization as a system where no person or group holds effective control. Independent delegates are not a political inconvenience: they are the verifiable proof of decentralization that protects @aavelabs, @stani, and the entire protocol from regulatory capture. The SELL button is the loudest governance signal token holders have, and it has been pressed repeatedly. We have more to lose by allowing governance to atrophy than by investing a fraction of our treasury to professionalize it.\nA special acknowledgment to @stani for engaging directly. This is the dialogue I tried to initiate privately with Labs before publishing this proposal. That conversation went silent without explanation, which is itself a symptom of the coordination gap the ADF is designed to close. I am choosing to see your comment here as the opening of a new chapter, and I will respond with the same directness.\nOn execution overhead and bottlenecks\nThe ADF is built to eliminate governance overhead, not create it. Every threshold (voting participation, rationale publication, and forum signal) is a binary yes/no metric verifiable via Snapshot, the Discourse API, and on-chain data. No committee decides who qualifies. No human judges quality. The rules are pre-defined and self-enforcing. The facilitator role publishes the output of an algorithm, not a subjective judgment. Compared to the current model, where eligibility is assessed retroactively each cycle with an open-ended budget request submitted after the fact, the ADF is structurally leaner. And here I want to be clear: the ACI built something that genuinely worked. Orbit professionalized governance delegates in a way Aave had never seen before. The ADF is not a repudiation of that work; it is its natural evolution, designed to outlast any single entity.\nOn conduct: you are correct, and this is the ADF’s strongest point\nI want to concede this directly: you identified the exact structural flaw that the ADF exists to fix.\nOrbit had zero conduct standards. A delegate could vote on every proposal, collect compensation, and spend the rest of their time publishing negative commentary about Aave or damaging the protocol’s reputation with no consequences. That is broken incentive design, and it is a problem the ADF was always going to solve.\nI am formally committing to add a Delegate Code of Conduct as part of the ARFC stage. Leading DeFi governance frameworks have been running this model successfully, utilizing formal conduct rules with documented misalignment penalties, all ratified on-chain. The scope I am proposing is deliberately narrow: prohibiting conduct that damages the protocol’s reputation, requiring conflict of interest disclosures, and establishing minimum communication standards with the broader ecosystem including Labs. This will be drafted openly on the forum with full community input. This is exactly the kind of improvement that could have been incorporated from the beginning if the initial dialogue with Labs had not gone silent.\nOn “political corners”: I need to respectfully and directly disagree\nThis is where I part ways with your framing, @stani, and I think it matters enough to say clearly.\nWhen you suggest that delegate relationships could happen outside the DAO through private economic agreements between delegates and large tokenholders, you are describing the end of decentralization, not its refinement. That is a patronage system. It concentrates influence in whoever holds the largest bags, creates undisclosed conflicts of interest, and removes the on-chain transparency that makes governance auditable to regulators. The most successful governance frameworks in DeFi explicitly prohibit this model for exactly these reasons.\nAnd here is the harder question: if there are no more compensated, independent delegates, what fills that space? The answer, historically, has been either voter apathy or the concentration of voting power in a small number of entities, which is precisely the dynamic the ECB documented as Aave’s governance risk. A DAO without a professional, diverse delegate ecosystem is not a leaner DAO. It is a DAO heading toward one of two destinations: captured governance, or the Uniswap path where Labs de facto controls direction and the DAO becomes a ratification mechanism. Both are legitimate models. But only one of them is actually decentralized, and only one of them is defensible under MiCA and the CLARITY Act.\nThe errors you are pointing to (conduct issues, lack of vetting, misaligned incentives) are real. But they are design gaps that we now have the context and the tools to fix, not reasons to abandon the concept entirely. We have a rare opportunity right now to build the right system from scratch, informed by what went wrong and by what is working elsewhere. Other protocols have already proven that codified, automated delegate frameworks eliminate political friction. This is not because they suppressed disagreement, but because nobody has to argue about what the rules are when they are written in advance and enforced algorithmically. We can learn from that without pretending our situation is identical.\nWe are at a genuine inflection point. The market has already spoken: AAVE is down over 44% in the last year while governance conflict consumed attention that should have gone to building. Every proposal that dies in political noise is a cost to every token holder. The answer to that cost is not fewer rules; it is clearer rules, applied automatically, with a Code of Conduct that makes destructive behavior economically irrational. That is exactly what the ADF proposes.\nWhat I am formally committing to before the ARFC\n\nDelegate Code of Conduct: drafted openly on the forum, modeled on Sky’s Atlas framework, covering conduct standards, conflict of interest disclosures, and communication expectations. This focuses on off-chain governance work only with no additional technical scope.\nMerit eligibility baseline: a minimum requirement of one full governance cycle of documented participation and an active delegate platform thread before any delegate qualifies for compensation.\n\nThe door to direct dialogue remains open. I am asking only that it stays open on both sides.\nTurning now to the rest of the community’s feedback, which has been equally sharp and valuable.\n@r0mul0 I understand your concerns about censorship, but this proposal is strictly about rules for delegates and decentralization. It has nothing to do with forum moderation, which I do not control. This framework seeks the exact opposite of censorship: automating compensation through verifiable on-chain data and completely removing subjective judgment. The 190,500 GHO is an absolute maximum cap. If the strict algorithmic thresholds are not met, the funds never leave the Treasury.\n@sid_areta You are right: a 48 hour window for rationales is operationally suffocating. The window will be extended to 4 days post-vote to ensure quality without burning out delegates. On the anti-spam filter: if the community feels it generates noise or is gameable, we will remove it entirely. I also agree that GovOps must go in a completely separate proposal.\n@0xlide The expenditure is not guaranteed. 190,500 GHO is a ceiling, not a forecast. Under current conditions, only two delegates realistically qualify as Aligned Delegates today, meaning realistic Q1 spend is closer to 34,500 GHO. We are using GHO strategically to strengthen our native stablecoin’s utility. Direct incentives in AAVE remain open for the next stage.\n@EzR3aL Thank you for the technical backing and for proactively offering your expertise with the Discourse API. Having constructive delegates involved in the infrastructure is what will make this system fair and truly automated.\n@MconnectDAO Your suggestions regarding off-chain tasks (research and cross-DAO education) are at the core of what this framework rewards. Two non-negotiable rules: no double-dipping for Service Providers already receiving DAO compensation, and GovOps goes in a separate thread entirely.\nWith these refinements incorporated, I will move this TEMP CHECK to Snapshot this Thursday, giving the community an extra couple of days for final review.\nThe future of Aave is undeniable decentralization. We built the most important lending protocol in DeFi. It would be a historic mistake to let governance entropy undo what the technology achieved. Let’s build it right together.\n\n post by 0xlide on Apr 4\n\n 0xlide\n\nIf the expected spend is under $35k, I recommend reducing the total maximum ask($190k). Also, when paying rewards in stablecoins, I recommend making a minimum $AAVE holding a mandatory condition for all platforms.\n\n post by JesusCryptoPlaza on Apr 5\n\n JesusCryptoPlaza\n\n stani\n\n I want to add a dimension that I think is underweighted in this debate.\n@stani is right that merit should be the basis for a seat at the table, and that paying delegates who generate negative value is broken incentive design. But I think the root cause is not the existence of a delegate program — it is the absence of participants with genuine skin in the game.\nA delegate who holds meaningful economic exposure to AAVE, who manages capital with fiduciary obligations, or who has professional reputation at stake with every public position cannot afford to vote carelessly, generate controversy for visibility, or damage the protocol’s image. Their LPs, their investors, their counterparties hold them accountable before any Code of Conduct ever could. That is the most effective conduct filter available — and it is one the current system does not select for.\nThe second point I want to raise is regulatory. MiCA is live. The CLARITY Act defines decentralization based on effective control. The ECB’s Working Paper 3208 flagged Aave’s governance concentration as a specific risk. For institutional capital evaluating DeFi exposure, governance credibility is not a nice-to-have — it is a prerequisite. A protocol without a transparent and independent delegate layer carries classification risk that directly impacts how allocators size their positions.\nThe ADF is not perfect, but it moves in the right direction. My concrete suggestion: map the framework explicitly to MiCA and CLARITY Act decentralization criteria. That reframes the delegate program from a DAO expense into a compliance asset that protects Labs, tokenholders, and the protocol’s ability to attract institutional capital.\nAave’s governance should be shaped by participants who have something real to lose. That is the standard we should design for.\n\n post by ApuMallku on Apr 6\n\n ApuMallku\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework (Revised)\nAuthor: Apu Mallku / Independent Delegate Platform\nStatus: TEMP CHECK / Revised Version incorporating community feedback\nDate: April 6, 2026\n\nWhat Changed and Why\nThis revised version incorporates the most substantive feedback from the first round of community discussion, including from @stani, @JesusCryptoPlaza, @sid_areta, @Ignas, @EzR3aL, @Kene_Anode, @phenk53, @MconnectDAO, and @0xlide. Three structural changes are worth highlighting:\n\nA formal Code of Conduct is now a core pillar of the proposal instead of a future ARFC commitment. This directly addresses the conduct concern raised by @stani, which we consider the most valid and necessary criticism to address.\nThe budget section reflects the current reality with one qualified Aligned Delegate candidate rather than a theoretical maximum. The cap remains in place for predictability, but the honest expected spend for the first cycle is made explicit.\nThe regulatory framing is strengthened throughout, following @JesusCryptoPlaza’s observation that this framework should be positioned as a compliance asset instead of a DAO expense.\n\nAbstract\nWith the Aave Chan Initiative (ACI) stepping back from delegate coordination, AAVE’s governance ecosystem faces a structural gap. This is not a crisis; it is an opportunity to build the right system rather than replicate its predecessor.\nThis proposal introduces the Aligned Delegates Framework (ADF): a four pillar upgrade to how AAVE governance identifies, rewards, and holds accountable its most dedicated delegates. The ADF moves beyond purely quantitative voting metrics toward an automated, objective baseline of governance value. For the first time, it establishes a formal Code of Conduct that makes the delegate role not just compensated, but accountable.\nCritically, this framework is more than just good governance practice. It is regulatory infrastructure. As the regulatory environment for DeFi tightens globally (MiCA is live, the CLARITY Act is advancing, and the ECB has already flagged Aave’s governance concentration by name), a transparent, independent, and rule bound delegate ecosystem is Aave’s most defensible proof of decentralization. Today’s regulatory laxity is not a guarantee of tomorrow’s. Building this shield now, while the window is open, is the prudent choice for every token holder and for Labs.\n\nBackground and Motivation\nAAVE governance faces five compounding structural problems that this proposal addresses directly:\n1. The Quantitative Trap. The current model measures delegates primarily through on-chain voting participation rates. This creates an incentive to vote without engaging, allowing delegates to collect compensation while contributing nothing of analytical value.\n2. Structural Voter Apathy. Supplying AAVE and delegating voting power are entirely disconnected. The vast majority of suppliers and stakers never delegate. The result is voting power permanently concentrated among a shrinking set of actors, increasing governance capture risk. The ECB Working Paper No. 3208 documented this concentration specifically for Aave. The SEC’s Interpretive Release 33 11412 and the CLARITY Act both define decentralization as a system where no person or group holds effective voting control. This is a present regulatory exposure.\n3. No Conduct Standards. The current delegate framework has zero conduct rules. A delegate could collect compensation while publishing negative commentary, damaging partnerships, or mocking contributors with no consequences. This is broken incentive design.\n4. Undefined Delegate Standards. There is no formal document establishing what is expected from an AAVE delegate. Duties, conflict of interest disclosures, and minimum engagement standards exist only as implicit norms.\n5. The Post ACI Coordination Vacuum. The departure of ACI leaves a coordination void. A healthy DAO cannot rely on a single entity (Labs or otherwise) to maintain the governance ecosystem that protects the protocol’s decentralization.\n\nCore Pillars\nPillar 1: The Aligned Delegate Baseline (ADB)\nThe ADF replaces the purely quantitative Orbit model with the Aligned Delegate Baseline, a set of binary, fully automatable Minimum Engagement Thresholds tracked via Snapshot GraphQL, the Discourse API, and on-chain data. No committee decides who qualifies and no human judges quality. The system is self enforcing.\nTo qualify for compensation, a delegate must meet all three thresholds per quarter:\n\nVoting Threshold: 85% or higher participation on all on-chain AIPs and Snapshot ARFCs. Abstain votes count as active participation. Technical failures are handled via automated exception parameters.\nCommunication Threshold: Delegates must publish a public Voting Rationale for at least 75% of Tier 1 proposals (proposals with over $1M direct treasury impact or equivalent weight). The window is extended to 4 days post vote following @sid_areta’s feedback.\nSignal Threshold (optional community decision): Following @sid_areta’s feedback, the anti-spam filter is proposed as optional. The community will decide at the ARFC stage whether to include it or replace it with a simpler minimum forum presence requirement.\n\nProof of Contribution Path: Delegates performing off-chain work (tooling, research, forum infrastructure) can substitute the Communication and Signal thresholds via a Community Validated Monthly Update, endorsed by TL2+ forum members or recognized Service Providers.\nTier Structure:\n\nAligned Delegates: 20,000 VP or more, all thresholds met. Compensation: 5,000 GHO per month.\nRising Stars: Under 20,000 VP, all thresholds met. Compensation: 2,000 GHO per month.\n\nPillar 2: Frictionless Staking Delegation Prompt\nIntegrate a one step, non mandatory delegation prompt into the AAVE staking and supply UI at the moment of interaction. Users can skip, self delegate, or choose any delegate. No lockups. This pillar will be coordinated directly with Aave Labs as part of their expanded mandate under Aave Will Win. No separate budget is requested for this pillar.\n\nPillar 3: AAVE Delegate Charter\nInitiate a community led drafting process for a formal AAVE Delegate Charter. This will be a concise, ratifiable document (target: 5 to 10 pages) defining the delegate role, minimum duties, conflict of interest standards, and accountability mechanisms. Drafting is open to all forum contributors and ratification will follow the standard AIP process.\n\nPillar 4: Delegate Code of Conduct (New response to @stani)\nThis is the pillar that Orbit never had and the one @stani correctly identified as the most critical missing element.\nThe problem Orbit created: Delegates could be compensated for governance participation while simultaneously engaging in conduct that damaged the protocol (negative public commentary, disparaging partners, or undermining team morale).\nThe ADF solution: A binding Code of Conduct, ratified on-chain as part of the Delegate Charter, establishing:\n\nProhibited conduct: Publishing content that materially misrepresents Aave’s protocol, products, or team; deliberate attempts to damage Aave’s reputation or partner relationships; conduct designed to generate personal visibility at the protocol’s expense.\nRequired disclosures: Conflict of interest declarations for any vote where the delegate has a material financial interest; disclosure of any compensation received from third parties.\nCommunication standards: Minimum responsiveness to governance stakeholders including Labs. There is no requirement to agree, but there is a requirement to engage.\nAccountability mechanism: Documented violations reviewed by a community panel of TL4 forum members and Service Providers. Confirmed violations result in disqualification from the compensation program.\n\nBudget: Honest Reality vs. Maximum Cap\nThe cap is a governance commitment, not a forecast. It provides the DAO with transparency regarding the worst case cost of the program.\nHonest first cycle picture:\n\nComponent\nMax Slots\nRate\nQ1 Maximum\nRealistic Q1\n\nAligned Delegates\n8\n5,000 GHO/mo\n120,000 GHO\n15,000 GHO (1 candidate: Areta)\n\nRising Stars\n4\n2,000 GHO/mo\n24,000 GHO\n0 GHO\n\nADF Facilitator\n1\n7,500 GHO/mo\n22,500 GHO\n22,500 GHO\n\nTOTAL MAX\n\n166,500 GHO\n~37,500 GHO\n\nThe 166,500 GHO ceiling represents less than 0.17% of the Aave DAO treasury. The realistic Q1 spend of approximately 37,500 GHO is less than 0.038% of the treasury. For a protocol generating over $100M annually, this is a governance infrastructure decision rather than a budget discussion.\n\nThe Regulatory Case: A Compliance Asset, Not a DAO Expense\nThe ADF is not governance overhead; it is regulatory infrastructure. The environment for DeFi is tightening and Aave is already named in relevant documents:\n\nECB Working Paper No. 3208 identifies Aave’s governance concentration as a potential barrier to MiCA exemptions.\nSEC Interpretive Release 33 11412 defines decentralization as the lack of effective control by any group.\nH.R. 3633 (CLARITY Act) defines a decentralized system as transparent and rules based.\n\nAn independent, compensated, and rule bound delegate ecosystem is Aave’s most defensible proof of decentralization. It also protects Labs’ ability to execute freely, as a DAO with genuinely distributed power cannot be characterized as centrally controlled.\n\nSummary of Changes from v1\n\nTopic\nv1\nRevised\n\nCode of Conduct\nARFC commitment\nFormal Pillar 4\n\nAligned Delegate rate\n6,000 GHO/mo\n5,000 GHO/mo\n\nRationale window\n48h\n4 days post vote\n\nAnti-spam filter\nMandatory\nOptional community decision\n\nBudget framing\nMaximum cap\nMaximum cap and realistic Q1 explicit\n\nRegulatory framing\nSupporting argument\nCentral strategic rationale\n\nThis proposal was drafted by Apu Mallku. All feedback is welcome to strengthen Aave’s decentralization and regulatory defensibility for the long term.\n\n post by ST0X on Apr 7\n\n ST0X\n\n Some Observations:\nDuring ACI Era, most of the delegates failed to provide meaningful opinions/ valuable inputs. It became either you agree with Marc Zeller of ACI or get out from the orbit compensation list.\nWhat Stani mentioned earlier is a fundamental issue lies with Defi DAO structure. Most of the time, delegates’ interests are NOT aligned with protocol in the long term but serves the delegate’s own interest. It relys on delegates to act in good faith. I have witnessed some of the delegates that are dissent from ACI getting sidelined or just ignored.\nA better structure is needed to address this misalignment to make the mechanism work in the long term.\n\n post by r0mul0 on Apr 7\n\n r0mul0\n\n I echo what @ST0X said.\n(Also the suggested amount ","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791262917011,"hash":"8ed54aed81568e7df9d7cecbb72eba18f4ee9aec"}
{"url":"https://ethresear.ch/t/leanda-design-and-benchmark/25642/1","domain":"ethresear.ch","title":"LeanDA: Design and Benchmark - Sharding - Ethereum Research","text":"LeanDA: Design and Benchmark \n\n Sharding\n\n data-availability,post-quantum\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 6\n\n 1 / 1\n\n Aug 6\n\n Aug 6\n\n post by LongMeng on Aug 6\n\n LongMeng\n\n Authors. Long Meng, Benedikt Wagner, George Kadianakis, Francesco Risitano\nThanks to Tom Wambsgans, Thomas Coratger, Arantxa Zapico, and others for insightful discussions.\n1. Motivation\nEthereum uses data availability sampling (DAS) to let validators check the availability of large blob data by sampling a small number of random positions from an erasure-coded object, rather than downloading the whole payload. As Ethereum moves toward post-quantum security, the current DAS protocol based on KZG polynomial commitments needs post-quantum alternatives.\nThis post first shows an encode + prove type of PQ-DAS construction instantiated with Reed-Solomon code, hash commitments, and the LeanVM proof system, and then show benchmarks for various input parameters and output metrics. The code for the up-to-date implementation is at: LongMeng-Crypto/PQ-DAS. A companion document containing the benchmark and security results is available in\nSupplementary.md。\n2. Encode + Prove DAS: Workflow\nIn general, a DAS protocol consists of a set of users, a block builder, and a set of verifiers. The benchmarked DAS protocol in this report is the Encode + Prove paradigm from the solution space of the DAS foundations, Section 7. In this class, the builder encodes the data with an erasure code, commits to the codewords by using a vector commitment scheme, and proves that the committed object is a valid codeword by using a SNARK proof system. Sampling opens authenticated positions of the codeword symbols, while reconstruction uses accepted samples as erasure-code evaluations.\nAbstractly, the workflow of such a DAS protocol is as follows:\n\nInitialization: All users send their data to the builder.\n\nCommit: The builder receives data from the users, first encodes them and commits to the codeword, then it generates a SNARK proof for proving that the data are encoded into the codewords, and the codewords are commited as the commitment. Finally, the builder uploads the commitment, the SNARK proof, and the codewords including commitment openings for all symbols to the network.\n\nDownload Commitment: Each verifier downloads the full commitment and SNARK proof from the network. Each verifier checks if the SNARK proof verifies with respect to the commitment. If not, they reject immediately.\n\nSampling and Verification: Each verifier samples a random set of indices and tries to download the corresponding codeword symbols and their openings from the network. Each verifier checks if the received openings are valid against the commitment. If not, they reject. If they are all valid, they accept.\n\nIntuitively, if any party collects enough symbols that have been verified, the original data can be reconstructed and missing symbols can be reinserted into the network, to help other verifiers to eventually accept.\nInformally, a DAS scheme should satisfy the following security properties: completeness, (subset-)soundness, consistency, and repairability. For the formal definition of the DAS syntax and these properties, we refer to the DAS foundations.\nOther schemes. In this post, we do not focus on other post-quantum alternatives such as FRIDA and ZODA. This is because they do not satisfy a crucial property called repairability, which is achieved by the current KZG solution and implicitly assumed throughout the protocol. Informally, this property ensures that reconstructed symbols can be reinserted into the network and verify with respect to the (potentially maliciously generated) commitment. This ensures that parties will eventually agree on whether data is available or not. Without this property, one would have to significantly adapt the surrounding protocol.\n3. Concrete Construction\nAfter introducing the overall workflow, we will now make more precise how the considered constructions work. In particular, we will define how the commitment is computed and which codes are used. While doing so, we also introduce the parameters that we will vary in our benchmarks.\nThe following image illustrates the workflow:\nV3 Design Diagram2550×1320 186 KB\nFor the construction, we use the Poseidon hash function, denoted as \\mathsf{H}𝖧; we fix the erasure code as Reed-Solomon (RS) code over the field \\mathbb{F}𝔽, which is the KoalaBear quintic extension field. For the evaluation domain, we use the roots of unity in the KoalaBear base field, so that encoding is given by an FFT;\nWe choose Merkle tree commitment as the vector commitment scheme; and we use LeanVM as the SNARK proof system. Below, we also describe which relation is proven using LeanVM.\nVery roughly, the construction works by arranging the data into rows of a matrix as in PeerDAS and extending each row via the Reed-Solomon code. Instead of KZG commitments, we use Merkle roots, and we additionally add a SNARK as explained above.\nMore precisely, we set the row length k𝑘, the encoded row length m = 2k𝑚 =2𝑘 (meaning rate \\rho = 1/2𝜌 =1/2), the cell size c𝑐, the number of cells per row \\ell=m/cℓ =𝑚/𝑐, and the reconstruction threshold t=\\lceil k/c\\rceil𝑡 =⌈𝑘/𝑐⌉. Each data object is parsed into n𝑛 rows (each row is called a blob today), each row is encoded as one Reed-Solomon codeword, and the first k𝑘 symbols are systematic payload symbols. With these paramerers, the protocol workflow is described as follows:\n\nInitialization: All users send their data to the builder.\n\nCommit: The builder operates following steps:\n\nEncodes each each blob of data into a RS codeword. We denote w_i𝑤𝑖 as the i𝑖-th row of codeword.\n\nArranges all codewords into a n\\times m𝑛 ×𝑚 matrix, where each row is one codeword. Then the codeword on each row i \\in [1, n]𝑖 ∈[1,𝑛] is split into \\ellℓ consecutive cells W_{i,j}\\quad (j \\in [1, \\ell])𝑊𝑖,𝑗 (𝑗 ∈[1,ℓ]), where each cell contains c𝑐 field elements. Every cell is hashed into a digest e_{i,j}=\\mathsf{H}(W_{i,j})𝑒𝑖,𝑗 =𝖧(𝑊𝑖,𝑗).\n\nFor every row i𝑖, the first t𝑡 cell digests, which cover the systematic payload cells, are hashed into a row digest r_i=\\mathsf{H}(e_{i,1},\\ldots,e_{i,t})𝑟𝑖 =𝖧(𝑒𝑖,1,…,𝑒𝑖,𝑡). The row digests are then committed via a Merkle tree into \\mathsf{root}_{\\mathsf{row}}𝗋𝗈𝗈𝗍𝗋𝗈𝗐. This row commitment gives a compact binding to each row’s systematic data.\n\nFor every cell column j \\in [1, \\ldots, \\ell]𝑗 ∈[1,…,ℓ], the digests (e_{1,j},\\ldots,e_{n,j})(𝑒1,𝑗,…,𝑒𝑛,𝑗) are aggregated through a Merkle tree into a column root C_j𝐶𝑗. The column roots (C_1,\\ldots,C_{\\ell})(𝐶1,…,𝐶ℓ) are then further aggregated through a Merkle tree into \\mathsf{root}_{\\mathsf{col}}𝗋𝗈𝗈𝗍𝖼𝗈𝗅.\n\nThe row root \\mathsf{root}_{\\mathsf{row}}𝗋𝗈𝗈𝗍𝗋𝗈𝗐 and column root are further hashed together to form the commitment \\mathsf{root}=\\mathsf{H}(\\mathsf{root}_{\\mathsf{row}},\\mathsf{root}_{\\mathsf{col}})𝗋𝗈𝗈𝗍 =𝖧(𝗋𝗈𝗈𝗍𝗋𝗈𝗐,𝗋𝗈𝗈𝗍𝖼𝗈𝗅).\n\nComputes the public Reed-Solomon membership check vector L𝐿 from public parameters and \\mathsf{root}𝗋𝗈𝗈𝗍. The details of how to compute L𝐿 via Fiat-Shamir can be referred to the next section “RS Membership Check Instantiations”.\n\nThe LeanVM proof \\pi𝜋 binds these commitments to valid Reed-Solomon codewords. In particular, \\pi \\leftarrow \\mathsf{LeanVM}.\\mathsf{Prove}(\\mathsf{pp}_{\\mathsf{STARK}}, \\mathsf{stmt}, \\mathsf{witn}, \\mathcal{R})𝜋 ←𝖫𝖾𝖺𝗇𝖵𝖬.𝖯𝗋𝗈𝗏𝖾(𝗉𝗉𝖲𝖳𝖠𝖱𝖪,𝗌𝗍𝗆𝗍,𝗐𝗂𝗍𝗇,R).\n\nThe public statement, witness, and proved relation are defined as follows:\n\n\\begin{aligned}\n\n\\mathcal{R}\n\n=\n\n\\{(\\mathsf{stmt},\\mathsf{witn}) \\;:\\;&\n\n\\mathsf{stmt} = (\\{r_i\\}_{i \\in [1, n]}, L, \\mathsf{root}), \\\\\n\n&\n\n\\ \\mathsf{witn}= \\{W_{i, j}\\}_{i \\in [1, n], j \\in [1, \\ell]}, \\\\\n\n&\n\n\\forall i\\in[1,n],j\\in[1,\\ell],\\;\n\ne_{i,j}=\\mathsf{H}(W_{i,j}),\\\\\n\n&\n\n\\forall i\\in[1,n],\\;\n\nr_i=\\mathsf{H}(e_{i,1},\\ldots,e_{i,t}),\\\\\n\n&\n\n\\mathsf{root}_{\\mathsf{row}}=\\mathsf{Merkle.Com}(r_1,\\ldots, r_n), \\\\\n\n&\n\n\\forall j\\in[1,\\ell],\\;\n\nC_j=\\mathsf{Merkle.Com}(e_{1,j}, ..., e_{n,j}),\\\\\n\n&\n\n\\mathsf{root}_{\\mathsf{col}}=\\mathsf{Merkle.Com}(C_1, ..., C_{\\ell}),\\\\\n\n&\n\n\\forall i\\in[1,n],\\;\n\n\\langle L, w_i\\rangle=0\n\n\\}, \\\\\n\n&\n\n\\mathsf{root} = \\mathsf{H}(\\mathsf{root}_{\\mathsf{row}}, \\mathsf{root}_{\\mathsf{col}}).\n\n\\end{aligned}\n\nR={(𝗌𝗍𝗆𝗍,𝗐𝗂𝗍𝗇):𝗌𝗍𝗆𝗍=({𝑟𝑖}𝑖∈[1,𝑛],𝐿,𝗋𝗈𝗈𝗍), 𝗐𝗂𝗍𝗇={𝑊𝑖,𝑗}𝑖∈[1,𝑛],𝑗∈[1,ℓ],∀𝑖∈[1,𝑛],𝑗∈[1,ℓ],𝑒𝑖,𝑗=𝖧(𝑊𝑖,𝑗),∀𝑖∈[1,𝑛],𝑟𝑖=𝖧(𝑒𝑖,1,…,𝑒𝑖,𝑡),𝗋𝗈𝗈𝗍𝗋𝗈𝗐=𝖬𝖾𝗋𝗄𝗅𝖾.𝖢𝗈𝗆(𝑟1,…,𝑟𝑛),∀𝑗∈[1,ℓ],𝐶𝑗=𝖬𝖾𝗋𝗄𝗅𝖾.𝖢𝗈𝗆(𝑒1,𝑗,...,𝑒𝑛,𝑗),𝗋𝗈𝗈𝗍𝖼𝗈𝗅=𝖬𝖾𝗋𝗄𝗅𝖾.𝖢𝗈𝗆(𝐶1,...,𝐶ℓ),∀𝑖∈[1,𝑛],⟨𝐿,𝑤𝑖⟩=0},𝗋𝗈𝗈𝗍=𝖧(𝗋𝗈𝗈𝗍𝗋𝗈𝗐,𝗋𝗈𝗈𝗍𝖼𝗈𝗅).\nAfter generating the proof, the builder generates the Merkle authentication paths for the column cells W_{1,j},\\ldots,W_{n,j}𝑊1,𝑗,…,𝑊𝑛,𝑗 for every j \\in [1,\\ell]𝑗 ∈[1,ℓ]. It then uploads all codeword cells W_{i,j}𝑊𝑖,𝑗, the row hashes r_i\\quad(i \\in [1,n])𝑟𝑖 (𝑖 ∈[1,𝑛]), the column root \\mathsf{root}_{\\mathsf{col}}𝗋𝗈𝗈𝗍𝖼𝗈𝗅, the LeanVM proof \\pi𝜋, and the Merkle openings for all column cells.\n\nDownload Commitment: Each verifier downloads the row hashes r_i\\quad(i \\in [1,n])𝑟𝑖 (𝑖 ∈[1,𝑛]), the column root \\mathsf{root}_{\\mathsf{col}}𝗋𝗈𝗈𝗍𝖼𝗈𝗅, the leanVM proof \\pi𝜋. Each verifier computes \\mathsf{root}_{\\mathsf{row}}𝗋𝗈𝗈𝗍𝗋𝗈𝗐 from r_i\\quad(i \\in [1,n])𝑟𝑖 (𝑖 ∈[1,𝑛]) and computes \\mathsf{root} = \\mathsf{H}(\\mathsf{root}_{\\mathsf{row}}, \\mathsf{root}_{\\mathsf{col}})𝗋𝗈𝗈𝗍 =𝖧(𝗋𝗈𝗈𝗍𝗋𝗈𝗐,𝗋𝗈𝗈𝗍𝖼𝗈𝗅), recomputes the vector L𝐿 from public parameters and \\mathsf{root}𝗋𝗈𝗈𝗍, checks if \\pi𝜋 verifies with respect to \\mathsf{root}𝗋𝗈𝗈𝗍. If not, they reject immediately.\n\nSampling and Verification: A verifier samples a set Q𝑄 of cell-column indices, queries the network and downloads the sampled columns W_{1,j},\\ldots,W_{n,j}𝑊1,𝑗,…,𝑊𝑛,𝑗 for j \\in Q𝑗 ∈𝑄, and their Merkle tree paths to the final \\mathsf{root}𝗋𝗈𝗈𝗍. Each verifier checks if Merkle paths are valid against \\mathsf{root}𝗋𝗈𝗈𝗍. If not, they reject. If they are all valid, they accept.\n\n4. RS Membership Check Instantiations\nIn the relation we prove, we ultimately want to check that each row of codeword w_i𝑤𝑖 is a valid RS codeword. We implement this via a simple inner product with a random vector L𝐿.\nThere are different ways for instantiating this check. We investigate three approaches, which are respectively the parity check, the generic barycentric check, and a special form of barycentric check for when the RS code rate \\rho = {1}/{2}𝜌 =1/2. The details of all these approaches are at RS membership check.\nThe computational overhead for these three approaches is very close. For a length-m𝑚 codeword and n𝑛 rows, computing the public vector L𝐿 outside the proof costs \\mathcal{O}(m)O(𝑚) field operations after Fiat-Shamir. Inside the proof, the RS membership relation is one length-m𝑚 inner product per row, so the total in-proof cost is \\mathcal{O}(nm)O(𝑛𝑚) field operations.\nIn our implementation, we choose the special barycentric check because our benchmarked RS code has rate \\rho=1/2𝜌 =1/2, so the codeword can be split into even and odd evaluations and membership reduces to the single identity A_i(p)=B_i(p/\\omega)𝐴𝑖(𝑝) =𝐵𝑖(𝑝/𝜔). Compared with the parity-check method, it avoids constructing a random linear combination over all high-degree coefficients; compared with the general barycentric check, it avoids evaluating arbitrary Lagrange bases over a chosen systematic split. Thus it has slightly cheaper computations and hence cheaper LeanVM workload.\nNote that below we use a different hash function \\mathsf{H}'𝖧′ for Fiat-shamir transform, which could be a standard hash function such as SHA256, Keccak, or Blake.\nSpecial barycentric check:\nPreprocessing outside the proof:\n\nLet {\\sf U}=\\{\\omega^0,\\omega^1,\\ldots,\\omega^{m-1}\\}𝖴 ={𝜔0,𝜔1,…,𝜔𝑚−1}, where \\omega𝜔 is a primitive m𝑚-th root of unity, and assume m=2k=2h𝑚 =2𝑘 =2ℎ.\n\nLet i𝑖 denote the row index, j𝑗 denote the codeword-symbol index on each row, and r𝑟 denote the index on the half-size domain.\n\nDefine x_r=(\\omega^2)^r𝑥𝑟 =(𝜔2)𝑟 for r\\in[0,h-1]𝑟 ∈[0,ℎ −1].\n\nFor each row w_i𝑤𝑖, define A_i(x_r)=w_{i,2r}𝐴𝑖(𝑥𝑟) =𝑤𝑖,2𝑟 and B_i(x_r)=w_{i,2r+1}𝐵𝑖(𝑥𝑟) =𝑤𝑖,2𝑟+1.\n\nUse Fiat-shamir transform for deriving the random challenge p \\leftarrow\\mathsf{H}'({\\sf pp},\\mathsf{root})𝑝 ←𝖧′(𝗉𝗉,𝗋𝗈𝗈𝗍) and set q=p/\\omega𝑞 =𝑝/𝜔.\n\nDefine \\ell_r(z)=\\frac{z^h-1}{h}\\cdot\\frac{x_r}{z-x_r}ℓ𝑟(𝑧) =𝑧ℎ−1ℎ ⋅𝑥𝑟𝑧−𝑥𝑟.\n\nCompute the shared barycentric-check vector L=(L_0,\\ldots,L_{m-1})𝐿 =(𝐿0,…,𝐿𝑚−1), where \\forall r\\in[0,h-1]:L_{2r}=\\ell_r(p)∀𝑟 ∈[0,ℎ −1] :𝐿2𝑟 =ℓ𝑟(𝑝) and L_{2r+1}=-\\ell_r(q)𝐿2𝑟+1 = −ℓ𝑟(𝑞).\n\nInner product inside the proof:\n\n\\begin{aligned} \\forall i\\in[1,n]:\\quad \\langle L,w_i\\rangle &= \\sum_{j=0}^{m-1}L_jw_{i,j} = \\sum_{r=0}^{h-1}L_{2r}w_{i,2r} +\\sum_{r=0}^{h-1}L_{2r+1}w_{i,2r+1} \\\\ &= \\sum_{r=0}^{h-1}\\ell_r(p)w_{i,2r} -\\sum_{r=0}^{h-1}\\ell_r(q)w_{i,2r+1} = A_i(p)-B_i(q) \\\\ &= A_i(p)-B_i(p/\\omega) = 0. \\end{aligned}\n\n∀𝑖∈[1,𝑛]:⟨𝐿,𝑤𝑖⟩=𝑚−1∑𝑗=0𝐿𝑗𝑤𝑖,𝑗=ℎ−1∑𝑟=0𝐿2𝑟𝑤𝑖,2𝑟+ℎ−1∑𝑟=0𝐿2𝑟+1𝑤𝑖,2𝑟+1=ℎ−1∑𝑟=0ℓ𝑟(𝑝)𝑤𝑖,2𝑟−ℎ−1∑𝑟=0ℓ𝑟(𝑞)𝑤𝑖,2𝑟+1=𝐴𝑖(𝑝)−𝐵𝑖(𝑞)=𝐴𝑖(𝑝)−𝐵𝑖(𝑝/𝜔)=0.\nSoundness intuition\nFor an intuition of soundness, the special barycentric check uses Fiat-Shamir to sample a public random point p𝑝 from the public commitment, then derives the public vector L=L(p)𝐿 =𝐿(𝑝). The proof only needs to show \\langle L,w_i\\rangle=0⟨𝐿,𝑤𝑖⟩ =0 for each row, which is the same as checking A_i(p)=B_i(p/\\omega)𝐴𝑖(𝑝) =𝐵𝑖(𝑝/𝜔). If a row w_i𝑤𝑖 is not a valid RS codeword, then A_i(X)-B_i(X/\\omega)𝐴𝑖(𝑋) −𝐵𝑖(𝑋/𝜔) is a nonzero polynomial of degree at most k-1𝑘 −1, so a random p𝑝 makes it vanish with probability at most (k-1)/|\\mathbb{F}|(𝑘 −1)/|𝔽|. Across all n𝑛 rows, a union bound gives at most n(k-1)/|\\mathbb{F}|𝑛(𝑘 −1)/|𝔽|.\n\n5. Benchmark Metrics\nThe main metrics we care about is Full DAS throughput: how much useful blob payload can pass through the builder-to-validator acceptance path per second. In the following we explain how this throughput is computed from measured metrics, which are explained in the table below.\nWith the parameters from the table below, the full DAS throughput is computed as\n\n\\frac{D_{\\mathrm{payload}}}{T_{\\mathrm{total}}}\n\n𝐷payload𝑇total\nwhere D_{\\mathrm{payload}}𝐷payload is the useful blob payload size. The total workflow contains one builder and N_{\\mathrm{clients}}𝑁clients verifiers:\n\nT_{\\mathrm{total}}=T_{\\mathrm{builder}}+T_{\\mathrm{verifiers}}\n\n𝑇total=𝑇builder+𝑇verifiers\nB_{\\mathrm{upload}}𝐵upload and B_{\\mathrm{download}}𝐵download denote the assumed builder upload bandwidth and verifier download bandwidth, respectively.\nThe builder-side time is\n\nT_{\\mathrm{builder}}=T_{\\mathrm{encode+commit}}+T_{\\mathrm{preprocess}}+T_{\\mathrm{prove}}+T_{\\mathrm{open}} + T_{\\mathrm{allpaths}}+\\frac{D_{\\mathrm{codeword}}+D_{\\mathrm{commit}}+D_{\\mathrm{proof}} + D_{\\mathrm{allpaths}}}{B_{\\mathrm{upload}}}\n\n𝑇builder=𝑇encode+commit+𝑇preprocess+𝑇prove+𝑇open+𝑇allpaths+𝐷codeword+𝐷commit+𝐷proof+𝐷allpaths𝐵upload\nand the verifier-side time is written as\n\nT_{\\mathrm{verifiers}}=\\max_{a\\in\\{1,\\ldots,N_{\\mathrm{clients}}\\}}T_{\\mathrm{verifier}}^{(a)}\n\n𝑇verifiers=max𝑎∈{1,…,𝑁clients}𝑇(𝑎)verifier\nfor\n\nT_{\\mathrm{verifier}}^{(a)}=T_{\\mathrm{verifier rebuild}}+T_{\\mathrm{verify proof}}+T_{\\mathrm{verify openings}}+\\frac{D_{\\mathrm{commit}}+D_{\\mathrm{proof}}+D_{\\mathrm{sample}}}{B_{\\mathrm{download}}}.\n\n𝑇(𝑎)verifier=𝑇verifierrebuild+𝑇verifyproof+𝑇verifyopenings+𝐷commit+𝐷proof+𝐷sample𝐵download.\nThe formula above is an optimistic upper-bound model. It assumes all parties execute the protocol stages without idle gaps and only charges the measured local computation plus the modeled upload/download time; it is not an actual network simulation and does not include gossip latency, peer scheduling, or mempool/block-propagation effects. The upload and download times are computed from the uploaded/downloaded byte sizes and the assumed B_{\\mathrm{upload}}=B_{\\mathrm{download}}=50𝐵upload =𝐵download =50 Mbps bandwidth (the assumption is made in terms of EIP-7870: Hardware and Bandwidth Recommendations). The endpoint is verifier acceptance, after proof verification and opening verification.\nWhen we compute the full DAS throughput we assume the ideal parallel case where all verifiers compute at the same time and spend almost equal amount of time, so T_{\\mathrm{verifiers}}𝑇verifiers is merely the time of one (slowest) verifier rather than the sum over all verifiers.\n\n Metric\n Meaning\n\n DpayloadThe total data size of the users\n DcodewordThe total size of the codeword\n DcommitThe size of the public commitment\n DallpathsThe size of the Merkle paths for all cell columns\n DproofThe LeanVM proof size\n DsampleThe size of sampled openings for |Q| columns\n Tencode+commitThe time to encode data, compute cell digests, and build vector commitments\n TallpathsThe time to generate the Merkle paths for all cell columns\n TpreprocessThe time to compute the RS membership check vector L\n TproveThe time to generate the LeanVM proof\n TopenThe time to produce sampled openings\n TrebuildThe time for the verifier to reconstruct the vector L\n Tverify proofThe time to verify the LeanVM proof\n Tverify openingsThe time to verify sampled column openings\n TreconstructThe time to reconstruct the data from accepted cells\n VM cyclesLeanVM guest cycles.\n Poseidon16 callsNumber of Poseidon width-16 calls used by the proof relation.\n ExtensionOp callsNumber of extension-field operation calls used by RS membership.\n LeanVM proving throughputEffective payload divided by LeanVM proving time.\n Full DAS throughputEffective payload divided by the critical builder-to-validator workflow time until a verifier accepts the block.\n\nRemark. The number of sampled cell columns opened by a verifier, denoted by |Q||𝑄|, is decided by the desired subset-soundness level. The formula for deriving it is given in the subset soundness formula section of the supplementary material.\n6. Overview of Benchmark Results\nThe benchmark numbers in this report were measured on a local PC with an Intel Core i9-14900 CPU, 32 logical CPUs (16 cores with 2 threads per core), 32 GiB memory, a single NUMA node, 36 MiB L3 cache, and AVX2 support. The benchmark uses the local default Rayon thread pool on this machine. Each benchmark profile is run as an end-to-end PQ-DAS execution: encodes and commits the data, prepares the LeanVM statement, generates the LeanVM proof, generates openings, verifies the proof and openings, and reconstructs the sampled payload where enabled. The reported timing values are the averages over 100 runs for the same parameter profile; sizes, security estimates, and VM counters are deterministic for a fixed profile and are reported once.\nThe benchmark sweeps vary blob size k𝑘, cell size c𝑐, row count n𝑛, and WHIR rate around the extension-field construction summarized above. Benchmark profile names use the format bX-cY-rZ-wT: bX denotes the blob-size multiplier, cY denotes the cell size in extension-field symbols, rZ denotes the number of rows n𝑛, and wT denotes the WHIR log inverse rate. To make these comparisons interpretable, each sweep fixes all but one family of parameters: the blob-size sweep fixes n=14𝑛 =14 and \\ell=1024ℓ =1024 while scaling k,m,c𝑘,𝑚,𝑐 together; the 2x and 4x cell-size sweeps fix the blob size and n=14𝑛 =14 while varying c𝑐; the 2x and 4x row-count sweeps fix the blob size and cell size while varying n𝑛; and the WHIR-rate sweep fixes two representative profiles while varying only the WHIR log inverse rate. A compact parameter summary is given in Table 0, and the raw measured values are collected in the benchmark tables section of the supplementary material.\nThe best measured point in each sweep is summarized below before the detailed takeaways.\n\n Sweep\n Best profile\n n\n k\n m\n c\n ℓ\n WHIR log inverse rate\n LeanVM proving throughput\n Full DAS throughput\n\n Blob-size sweepb4-c64-r14-w11432768655366410241907.38 KiB/s620.61 KiB/s\n 2x cell-size sweepb2-c32-r14-w11416384327683210241846.33 KiB/s574.13 KiB/s\n 2x row-count sweepb2-c32-r14-w11416384327683210241887.16 KiB/s597.44 KiB/s\n 4x cell-size sweepb4-c32-r14-w11432768655363220481882.29 KiB/s604.31 KiB/s\n 4x row-count sweepb4-c32-r6-w1632768655363220481795.89 KiB/s528.9 KiB/s\n WHIR-rate sweepb2-c32-r14-w11416384327683210241789.38 KiB/s547.13 KiB/s\n\nThe main takeaways are:\n\nBlob-size sweep: At fixed \\ell=1024ℓ =1024 and n=14𝑛 =14, moving from 1x to 2x/4x payloads amortizes fixed proof overhead. The best Full DAS throughput in this sweep is b4-c64-r14-w1 at 620.61620.61 KiB/s, while 2x and 4x have almost identical LeanVM proving throughput around 0.90.9 MiB/s (Table 1).\n\n2x cell-size sweep: For k=16384𝑘 =16384, m=32768𝑚 =32768, and n=14𝑛 =14, c=32𝑐 =32 is the best measured point, with 846.33846.33 KiB/s LeanVM proving throughput and 574.13574.13 KiB/s Full DAS throughput. Larger cells reduce VM cycles but increase opening size and do not improve the full throughput in this run (Table 2).\n\n2x row-count sweep: Increasing n𝑛 amortizes fixed overhead until padding cliffs appear. The best measured Full DAS throughput is at n=14𝑛 =14 with 597.44597.44 KiB/s, while n=16𝑛 =16 and n=32𝑛 =32 show sharp proving-time cliffs (Table 3).\n\n4x cell-size sweep: At 4x blob size, c=32𝑐 =32 is the best measured point, with 882.29882.29 KiB/s LeanVM proving throughput and 604.31604.31 KiB/s Full DAS throughput. The c=64𝑐 =64 point is close, but c=16𝑐 =16 is much slower because it doubles the number of cells (Table 4).\n\n4x row-count sweep: The best measured Full DAS throughput is at n=6𝑛 =6 with 528.9528.9 KiB/s. Larger row counts do not monotonically improve throughput because proof-system padding costs dominate at several boundaries, especially n=16𝑛 =16 (Table 5).\n\nWHIR-rate sweep: WHIR log inverse rate 11 is consistently faster than log inverse rate 22 for both tested profiles. Log inverse rate 22 reduces proof size but increases proving time enough to lower Full DAS throughput (Table 6).\n\nFor the complete measured values, including proof size, sample size, VM cycles, Poseidon16 calls, ExtensionOp calls, and reconstruction time, see the benchmark tables in the supplementary material.\nWe also ran the same benchmark profiles on a stronger server with an AMD EPYC 9V74 processor, 32 logical CPUs (16 cores with 2 threads per core), 62 GiB memory and AVX-512 support. For a representative b4-c64-r14-w1 profile, this server improves LeanVM proving throughput from 907.38907.38 KiB/s to 1183.201183.20 KiB/s, a 30.4\\%30.4% increase, and Full DAS throughput from 620.61620.61 KiB/s to 790.72790.72 KiB/s, a 27.4\\%27.4% increase. The full server-side benchmark tables are available in Supplementary2.md.\nSummary and Future Directions\nOverall we have the following summaries from our experiments:\n\nMain outcome: A post-quantum DAS construction can be implemented with hash-based commitments and LeanVM proofs at roughly 0.90.9 MiB/s across the strongest measured profiles, with single-profile runs occasionally reaching about 11 MiB/s.\n\nParameter choice: Cell size c=32𝑐 =32 is the strongest current point for the 2x profile, c=32𝑐 =32 and c=64𝑐 =64 are both competitive for the 4x profile, and row counts around n=12𝑛 =12 to n=14𝑛 =14 avoid the large proving-time cliffs seen at exact larger powers of two.\n\nMain bottleneck: The proof relation is still dominated by Poseidon calls for cell/row/column commitments and extension-field operations for RS membership. Reducing these costs inside LeanVM is the clearest path toward higher throughput.\n\nAnd we have the following directions to work on for next steps:\n\nDistributed blob proving: The current version assumes that one builder receives all users’ data and generates one DAS commitment. A distributed version would let each user/prover prove its own row and send the row proof to a central aggregator, which then builds the final aggregated commitment/proof. This is only worthwhile if the communication per row is smaller than directly sending the row payload to the aggregator: if a prover must send its LeanVM proof \\pi_i𝜋𝑖, row digest r_i𝑟𝑖, and all \\ellℓ cell digests, then we need |\\pi_i|+|r_i|+\\ell\\cdot|\\mathsf{digest}| < D_{\\mathrm{blob}}|𝜋𝑖| +|𝑟𝑖| +ℓ ⋅|𝖽𝗂𝗀𝖾𝗌𝗍| <𝐷blob. Assume there are \\ell=1024ℓ =1024 cells, in the benchmarked 2x blob size profile, D_{\\mathrm{blob}}\\approx310𝐷blob ≈310 KiB, and each digest is 3232 bytes, so the row proof would need to be below roughly 310\\text{ KiB}-32\\text{ KiB}-32\\text{ B}\\approx278310 KiB −32 KiB −32 B ≈278 KiB; for the 4x blob size profile, the analogous threshold is roughly 620\\text{ KiB}-32\\text{ KiB}-32\\text{ B}\\approx588620 KiB −32 KiB −32 B ≈588 KiB. Otherwise it is simpler and cheaper to send the raw blob to the aggregator and let it produce the ordinary centralized proof.\n\nAlternative erasure code: We plan to replace the RS code with some other codes that are potentially efficient, such as multiplicity codes, or linear-time encodable code, and benchmark their efficiency for comparing with the current results.\n\nAlternative proof systems: We also plan to instantiate the DAS SNARK/STARK layer with proof systems other than LeanVM, or LeanVM with some DAS-specific incremental modifications, and benchmark whether they give better throughput for the same DAS construction.\n\n Formally Verified Security for PQ-DAS / leanDA\n\n read \n\n 10\n min\n\n Powered by Discourse","tokens":6420,"squid":"ink-research","role":"Deep Scholar","at":1791262918830,"hash":"39973827f973fcb29aefe35d2fc0fddc8bb21671"}
{"url":"https://www.soliditylang.org/blog/category/security-alerts/","domain":"soliditylang.org","title":"Blog: Security Alerts | Solidity Programming Language","text":"{Solidity:​log}All security alert postsSpill Slot Collision Across Mutual Recursion BugPosted by Solidity Team on September 10, 2026Security Alerts\nOn July 30, 2026, Ng Sze Hon reported a bug in the IR pipeline's stack-to-memory mover (the \"stack limit evader\") through the Ethereum Foundation's bug bounty program.\nThe mover works around the EVM's stack depth limit by relocating (\"spilling\") some local variables to fixed memory offsets, called spill slots.\nBecause of the bug, variables of two different functions can be assigned the same spill slot when the call graph contains mutual recursion, even though both variables can be live at the same...Read moreMisordered Named Parameters in require with Custom Errors BugPosted by Solidity Team on September 10, 2026Security Alerts\nOn February 4, 2026, a bug in the IR-based code generator was reported by Carl from\nCantina Security through the Ethereum Foundation bug bounty program. The\nbug causes the arguments of a custom error passed to require using named-parameter syntax\nto be placed on the stack in call-site order rather than declaration order before they are\nABI-encoded.\n\nThe bug was introduced in Solidity 0.8.26, which added support for passing custom errors as\nthe second argument to require.\nSolidity 0.8.37 provides a fix.\n\nWe assigned the bug a severity...Read moreMemory Byte Array Element Delete Clears Whole Word BugPosted by Solidity Team on September 10, 2026Security Alerts\nOn August 14, 2026, Shaheen Fazim reported a bug in the Solidity code generator through the Ethereum Foundation's bug bounty program.\nWhen delete is applied to an element of a bytes array located in memory, the generated code writes 32 zero bytes starting at that element instead of clearing only the element.\nThis also clears up to 31 of the bytes that follow it, either elsewhere in the same array or, when the deleted element sits near the end of the array,...Read moreUnsound Spill In Mutual Recursion BugPosted by Solidity Team on July 9, 2026Security Alerts\nOn May 11, 2026, clonker from the Solidity team discovered a bug in the Yul optimizer's call graph analysis.\nThe bug resulted in mutually recursive functions being sometimes misclassified as non-recursive, and therefore not being excluded from the memory spilling mechanism that is incompatible with recursive functions.\nThe mechanism relocates local variables to fixed memory offsets to work around the EVM's stack depth limit and would cause the spilled variables to be shared between all invocations of the same function.\n\nWe assign this...Read moreInheritance Order Reversal On Storage End Warning BugPosted by Solidity Team on July 9, 2026Security Alerts\nOn June 8, 2026, clonker from the Solidity team discovered a bug in the analysis phase of the Solidity compiler.\nThe bug manifests when the compiler emits Warning 3495 about a custom storage layout being placed too close to the end of storage.\nThe implementation of said warning reverses the C3-linearized list of base contracts on the contract being checked.\nBecause this linearization drives inheritance-dependent decisions throughout the rest of the compiler, the reversal can lead to miscompilations as well as internal compiler...Read moreTransient Storage Clearing Helper Collision BugPosted by Solidity Team on February 18, 2026Security Alerts\nOn 2026-02-11, a bug in the Solidity code generator was reported by Hexens.\nThe bug affects compiler versions 0.8.28 through 0.8.33 when using the IR pipeline.\nWhen a contract clears both a persistent and a transient storage variable of the same type, the compiler will emit the wrong opcode (sstore instead of tstore, or vice versa) for one of these operations, because the generated Yul helper functions share the same name and one overwrites the other.\n\nWe assign this bug a severity of...Read moreLost Storage Array Write on Slot Overflow BugPosted by Solidity Team on December 18, 2025Security Alerts\n\nOn November 10, 2024, a bug in the Solidity code generator was found by @Audittens.\nThe bug was initially reported to affect deletion and partial assignment operations on fixed-length storage arrays that cross the 2**256-slot boundary.\nTwo instances were reported: one in the IR pipeline and one in the evmasm pipeline.\nDuring our further investigation, we discovered a third instance affecting copying from arrays placed at the storage boundary.\nThe effect of the bug is that such storage cleanup or copy operations may not...Read moreBug in Deduplication of Verbatim BlocksPosted by Solidity Team on November 8, 2023Security Alerts\nOn October 24, Ori Pomerantz reported a bug affecting the use of verbatim\nbuiltin in Yul code. After investigating, the team was able to confirm the problem\nand locate its origin.\nThe bug existed in the Block Deduplicator optimizer step, wherein equivalent\nassembly blocks are identified and merged.\nverbatim assembly items surrounded by identical opcodes were incorrectly considered identical\nand unified.\n\nThe bug existed since version 0.8.5, which introduced verbatim, and only affected pure Yul\ncompilation with optimization enabled.\nSolidity code or Yul used in inline assembly blocks would...Read moreBug in Legacy Code Generation When Accessing the .selector Member on Expressions with Side EffectsPosted by Solidity Team on July 19, 2023Security Alerts\nOn June 26, 2023, a bug in the legacy code generation pipeline of the Solidity compiler was found during\ninvestigation of a security report related to the use of abi.decode with a ternary\nexpression that has side effects, as the type argument.\n\nThe legacy code generator was not evaluating complex expressions, like assignments, function calls, or conditionals,\nwhose .selector was being accessed.\nThis led to the side-effects of such expressions not being executed, and therefore potentially incorrect behavior of\ncontracts compiled using the legacy pipeline.\nThe...Read moreFullInliner Non-Expression-Split Argument Evaluation Order BugPosted by Solidity Team on July 19, 2023Security Alerts\nOn July 4, 2023, Robert Chen from OtterSec discovered a bug in the Yul optimizer.\n\nThe earliest affected version of the compiler is 0.6.7, which introduced the ability to modify the\noptimizer step sequence.\nSolidity version 0.8.21, released on July 19, 2023, provides a fix.\n\nWe assigned the bug an overall score of \"low\".\nThe bug has \"high\" severity in affected cases, but we deem the likelihood of it actually affecting deployed contracts as \"very low\".\n\nWhich Contracts are Affected?\n\nThe prerequisite to trigger the bug is...Read moreStorage Write Removal Bug On Conditional Early TerminationPosted by Solidity Team on September 8, 2022Security Alerts\nOn September 5, 2022, a bug in Solidity's Yul optimizer was found by differential fuzzing.\n\nThe bug was introduced in version 0.8.13 and Solidity version 0.8.17, released on September 08, 2022, provides a fix. The bug is significantly easier to trigger with optimized via-IR code generation, but can theoretically also occur in optimized legacy code generation.\n\nWe assigned the bug a severity of \"medium/high\".\n\nWho Should Be Concerned\n\nIf you're using optimized legacy code generation, you only need to be concerned, if you use...Read moreHead Overflow Bug in Calldata Tuple ABI-ReencodingPosted by Solidity Team on August 8, 2022Security Alerts\nOn July 5, 2022, Chance Hudson (@vimwitch) from the Ethereum Foundation discovered a bug in the Solidity code generator.\n\nThe earliest affected version of the compiler is 0.5.8, which introduced ABI-reencoding of calldata arrays and structs.\nSolidity version 0.8.16, released on August 08, 2022, provides a fix.\n\nWe assigned the bug a severity of \"medium\".\n\nWhich Contracts are Affected?\n\nThe effects of the bug manifest when a contract performs ABI-encoding of a tuple that meets all of the following conditions:\n\nThe last component of the tuple...Read moreOptimizer Bug Regarding Memory Side Effects of Inline AssemblyPosted by Solidity Team on June 15, 2022Security Alerts\nOn June 5, 2022, John Toman of the Certora development team reported an optimizer bug\nthat can cause memory writes in inline assembly blocks to be incorrectly removed\nunder certain conditions.\n\nThe bug was introduced in Solidity 0.8.13 with a new Yul optimizer step meant to\nremove unused writes to memory and storage.\n\nWe assigned the bug a severity of \"medium\".\n\nWhich Contracts are Affected?\n\nThe Yul optimizer considers all memory writes in the outermost Yul block that are\nnever read from as unused and removes them. This...Read moreBug when Copying Dirty Bytes Arrays to StoragePosted by Solidity Team on June 15, 2022Security Alerts\nOn July 1, 2021, a bug in the Solidity code generator was found by differential fuzzing.\nThe bug causes the legacy code generation pipeline to generate code that\nmay write dirty values to storage when copying bytes arrays from calldata or memory.\n\nInitially, it was assumed that the dirty values in storage are only observable using inline\nassembly. However, resizing a bytes array using an empty .push() without actually\nwriting values to it, can expose the dirty bytes without any use of inline assembly.\n\nThe bug...Read moreBug Concerning Data Location during InheritancePosted by Solidity Team on May 17, 2022Security Alerts\nOn February 5th 2021, Nicolas Venturo reported a bug that allows\noverriding functions to change the data location of parameters from\nmemory to calldata.\n\nThe bug was introduced in Solidity 0.6.9 together with the ability to use calldata\ndata location for all variables (and not just parameters of external functions).\n\nWe assigned the bug a severity of \"very low\".\n\nWhich Contracts are Affected?\n\nThe effect of the bug is that a memory pointer is interpreted as a calldata pointer\nor vice-versa. It can only happen if you change...Read moreSize Check Bug in Nested Calldata Array ABI-ReencodingPosted by Solidity Team on May 17, 2022Security Alerts\nOn April 7, 2022, a bug in the Solidity code generator was reported by\nJohn Toman of the Certora development team. Certora's bug disclosure post can be found here.\n\nThe bug is fixed with Solidity version 0.8.14\nreleased on May 17, 2022. The bug was first introduced in Solidity version 0.5.8.\n\nWe assigned the bug a severity of \"very low\".\n\nWhich Contracts are Affected?\n\nYou might be affected if you pass a nested array directly to another external\nfunction call or use abi.encode on it.\n\nIf calldata is...Read moreabi.encodeCall Literals BugPosted by Solidity Team on March 16, 2022Security Alerts\nOn March 10th, 2022, the Solidity team discovered a bug in the implementation of\nabi.encodeCall when used together with fixed-length bytes literals.\n\nIt was introduced together with abi.encodeCall in Solidity 0.8.11 and is fixed in 0.8.13.\n\nWe assigned the bug a severity of \"very low\".\n\nWhich Contracts are Affected?\n\nYou might be affected if you use abi.encodeCall(f, (...)) where f takes a\nbytesNN parameter and you provide the value for that parameter either as a\nhex literal (0x1234 or hex\"abcd\") or\nas a string literal (\"abcd\").\n\nIf you only...Read moreUser Defined Value Types BugPosted by Solidity Team on September 29, 2021Security Alerts\nOn September 28th, 2021, Harry Altman (@haltman-at) of Truffle\ndiscovered a bug in user defined value types.\n\nThe bug has no influence on the correctness of Solidity contracts, but contracts compiled with\nSolidity 0.8.8 that use the new feature are unnecessarily wasteful and might have problems with\ntooling or contract upgrades.\n\nThe bug exists only in Solidity 0.8.8 and is fixed in 0.8.9.\n\nWe assigned the bug a severity of \"very low\".\n\nStorage Layout of User Defined Value Types\n\nThe compiler did not correctly compute the storage layout...Read moreSigned Immutables BugPosted by Solidity Team on September 29, 2021Security Alerts\nOn September 28th, 2021, the Solidity team discovered that\nfor immutable variables of a signed integer type shorter than 256 bits,\nsign extension (cleanup) of its value is not always properly performed.\n\nTo our knowledge, the value can only be accessed in its unclean state\nwhen using inline assembly.\nThe bug is present since the introduction of the\nimmutable feature in Solidity 0.6.5 and is fixed in 0.8.9.\n\nWe assigned the bug a severity of \"very low\".\n\nTechnical Details\n\nWhen immutable variables are assigned in Solidity during the construction...Read moreSolidity ABI Decoder Bug For Multi-Dimensional Memory ArraysPosted by Solidity Team on April 21, 2021Security Alerts\nOn April 5th, 2021, a bug in the Solidity ABI decoder v2 was reported by\nJohn Toman of the Certora development team. Certora's bug disclosure post\ncan be found here: Memory Isolation Violation in Deserialization Code.\n\nThe bug is fixed with Solidity version 0.8.4\nreleased on April 21st, 2021. The bug is present in all prior versions of ABI coder v2.\n\nWe assigned the bug a severity level of \"very low\", mainly due to the\nfact that it is very hard to exploit the bug.\n\nWe are...Read moreSolidity Optimizer Keccak Caching BugPosted by Solidity Team on March 23, 2021Security Alerts\nOn March 20, 2021, a bug in Solidity's bytecode optimizer was found by differential fuzzing. The bug\nis fixed with version 0.8.3 released on\nMarch 23, 2021. The bug is present in all prior versions of Solidity.\n\nWe assigned the bug a severity level of \"medium\".\n\nTechnical Details\n\nSummary: The bytecode optimizer incorrectly re-used previously evaluated Keccak-256 hashes. You\nare unlikely to be affected if you do not compute Keccak-256 hashes in inline assembly.\n\nSolidity's bytecode optimizer has a step that can compute Keccak-256 hashes, if the...Read moreSolidity Empty Byte Array Copy BugPosted by Solidity Team on October 19, 2020Security Alerts\nOn October 14, 2020, a bug in the Solidity code generator was reported by\nJohn Toman of the Certora development team. Certora's bug disclosure post can be found here.\n\nThe bug is fixed with Solidity version 0.7.4\nreleased on October 19, 2020. The bug is present in all prior versions of Solidity.\n\nWe assigned the bug a severity level of \"medium\".\n\nWho should be concerned\n\nThis bug can cause newly created elements of bytes or string arrays in storage\nto be initialized by a non-zero value. For...Read moreSolidity Dynamic Array Cleanup BugPosted by Solidity Team on October 7, 2020Security Alerts\nOn September 17, 2020, a bug in the Solidity code generator was found. The bug is fixed with version 0.7.3\nreleased on October 7, 2020. The bug is present in all prior versions of Solidity.\n\nWe assigned the bug a severity level of \"medium\".\n\nTechnical Details of the Bug\n\nSummary: For a dynamically-sized storage-array with types of size at most 16 bytes,\nassignments that require deleting slots did not zero out the deleted slots properly.\n\nConsider a dynamically-sized array in storage whose base-type is small enough...Read moreSolidity Memory Array Creation Overflow BugPosted by Solidity Team on April 6, 2020Security Alerts\nOn the 28th of March, a bug in the Solidity code generator was reported through the\nEthereum Foundation Bounty program,\nby John Toman of Certora. The bug is fixed with version 0.6.5,\nreleased on 2020-04-06.\nThe bug is present in all prior versions of Solidity.\n\nWe assigned a severity level of \"low\" because we found the bug to be uncommon and at the same time hard to exploit.\n\nWho should be concerned\n\nIf you have deployed a contract which allocates a memory array of user-supplied length,\nbut does...Read moreSolidity Storage Array BugsPosted by Solidity and Security Team on June 25, 2019Security Alerts\nThis post was originally published on the Ethereum blog.\n\nThis blog post is about two bugs connected to storage arrays which are otherwise unrelated. Both have been present in the compiler for a long time and have only been discovered now even though a contract containing them should very likely show malfunctions in tests.\n\nDaenam Kim with help from Nguyen Pham, both from Curvegrid discovered an issue where invalid data is stored in connection with arrays of signed integers.\n\nThis bug has been...Read moreSolidity Optimizer and ABIEncoderV2 BugsPosted by Solidity and Security Team on March 26, 2019Security Alerts\nThis post was originally published on the Ethereum blog.\n\nThrough the Ethereum bug bounty program, we received a report about a flaw within the new experimental ABI encoder (referred to as ABIEncoderV2). Upon investigation, it was found that the component suffers from a few different variations of the same type. The first part of this announcement explains this bug in detail. The new ABI encoder is still marked as experimental, but we nevertheless think that this deserves a prominent announcement since...Read moreSolidity Bugfix ReleasePosted by Solidity Team on September 13, 2018Security Alerts\nThis post was originally published on the Ethereum blog.\n\nThe latest version 0.4.25 release of Solidity fixes\ntwo important bugs.\nAnother important bug has already been fixed in version 0.4.22 but it was only discovered recently that the bug existed.\n\nNote that the Ethereum Foundation runs a bounty program for the code generator part of Solidity.\n\nCleanup of Exponent in Exponentiation\n\nLikelihood of occurrence: very low\nExploitability: high\nDiscoverability by tests: low\nFixed in version: 0.4.25\n\nSummary: Using short types in the exponent of an exponentiation operation can lead to...Read moreSolidity Optimizer BugPosted by Martin Swende on May 3, 2017Security Alerts\nThis post was originally published on the Ethereum blog.\n\nA bug in the Solidity optimizer was reported through the Ethereum Foundation Bounty program, by Christoph Jentzsch. This bug is patched as of 2017-05-03, with the release of Solidity 0.4.11.\n\nBackground\n\nThe bug in question concerned how the optimizer optimizes on constants in the byte code. By \"byte code constants\", we mean anything which is PUSHed on the stack (not to be confused with Solidity constants). For example, if the value 0xfffffffffffffffffffffffffffffffffffffffffffffffe is PUSHed,...Read moreAnalysis of Storage Corruption BugPosted by Christian Reitwiessner on November 9, 2016Security Alerts\nThis post was originally published on the Ethereum blog.\n\nThis blog post provides an update on our findings following the discovery of the storage corruption bug last week.\nIn summary, the bug was much less severe than we initially thought. The small number of affected contracts we found is either only exploitable by the owner, or the exploit can only cause a disruption in the user interface and not in the actual contract logic. All exploitable contracts/dapps we reviewed can be fixed...Read moreSecurity Alert: Variables can be overwritten in storagePosted by Christian Reitwiessner on November 1, 2016Security Alerts\nThis post was originally published on the Ethereum blog.\n\nSummary: In some situations, variables can overwrite other variables in storage.\n\n*Affected Solidity compiler versions: *0.1.6 to 0.4.3 (including 0.4.4 pre-release versions)\n\nDetailed description:\n\nStorage variables that are smaller than 256 bits are packed together into the same 256 bit slot if they can fit. If a value larger than what is allowed by the type is assigned to the first variable, that value will overwrite the second variable.\n\nThis means if an attacker can cause...Read moreSmart Contract SecurityPosted by Christian Reitwiessner on June 10, 2016Security Alerts\nThis post was originally published on the Ethereum blog.\n\nSolidity was started in October 2014 when neither the Ethereum network nor the virtual machine had any real-world testing, the gas costs at that time were even drastically different from what they are now. Furthermore, some of the early design decisions were taken over from Serpent. During the last couple of months, examples and patterns that were initially considered best-practice were exposed to reality and some of them actually turned out to...Read more","tokens":4976,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262922779,"hash":"290dece9c95213cd5b273d7e1c4a337d973e1484"}
{"url":"https://www.soliditylang.org/blog/2026/09/10/memory-byte-array-element-delete-clears-whole-word-bug/","domain":"soliditylang.org","title":"Memory Byte Array Element Delete Clears Whole Word Bug | Solidity Programming Language","text":"Memory Byte Array Element Delete Clears Whole Word BugPosted by Solidity Team on September 10, 2026Security AlertsOn August 14, 2026, Shaheen Fazim reported a bug in the Solidity code generator through the Ethereum Foundation's bug bounty program.\nWhen delete is applied to an element of a bytes array located in memory, the generated code writes 32 zero bytes starting at that element instead of clearing only the element.\nThis also clears up to 31 of the bytes that follow it, either elsewhere in the same array or, when the deleted element sits near the end of the array, in whatever comes after it.\nThe equivalent assignment b[i] = 0 is not affected and clears exactly one byte.\nWe assign this bug a severity of low/medium on our internal scale.\nThe bug only affects the default, evmasm pipeline; the IR pipeline is not affected.\nThe use of the optimizer is not necessary to trigger it.\nThe affected code path predates the first released version of Solidity.\nAll versions up to and including 0.8.36 are affected.\nThe bug is fixed in Solidity 0.8.37.\nWe scanned the Sourcify database of roughly 870,000 verified compilations for the triggering source pattern.\nThe pattern appears in 17 compilations, which contain only two distinct functions, neither of which is actually affected (see Severity Assessment).\nNo deployed contract is known to be affected.\nWhich Contracts Are Affected?\nA contract is only affected if all of the following conditions are met:\n\nit is compiled with the evmasm pipeline, i.e., without --via-ir (or settings.viaIR in Standard JSON),\nit applies delete to an element of a bytes value located in memory, e.g., delete b[i], and\nthe 31 bytes that follow the deleted element are not irrelevant to the contract's behavior.\n\nConditions 1 and 2 can be checked in the compiler settings and the sources.\nCondition 3 requires reasoning about the memory layout the compiler produces, so if the first two hold, it may be safer to treat the contract as affected rather than try to rule out the third.\nIf your contract never applies delete to an element of a bytes or string value in memory, it is not affected.\nNeither the optimizer nor the target EVM version changes whether the bug manifests: the defect is in the code emitted by the codegen stage, and the optimizer preserves its faulty semantics.\nCondition 2 requires three clarifications.\nFirst, only element deletes are affected: delete b on the whole array takes a different code path and works correctly.\nSecond, the array must be in memory.\nByte arrays in storage are handled by a separate code path and are unaffected, and delete cannot be applied to calldata at all.\nArrays whose elements each occupy a full word in memory, such as bytes1[] memory, are unaffected as well; only bytes and string pack their elements.\nThird, string values are affected as well.\nWhile delete s[i] does not compile for a string memory s, strings can be converted to bytes and delete bytes(s)[i] triggers the same bug.\nHow far the corruption reaches depends on where in the array the deleted element sits and on how the array was allocated (see Technical Details below).\nDeleting one of the last 31 elements can reach past the array into whatever is allocated after it.\nTechnical Details\nThis section describes the compiler internals behind the bug for readers interested in the implementation-level root cause.\nByte arrays in memory\nMost values in memory occupy full 32-byte words.\nThe notable exception is bytes: a byte array in memory consists of a 32-byte length field followed by its data, packed back to back without gaps.\nSolidity allocates memory by advancing the free memory pointer: every allocation starts where the previous one ended.\nConsecutive allocations therefore sit flush against each other (apart from padding), and a write that runs past the end of one lands directly in the next.\nIn most cases, e.g., for arrays created with new bytes(n) or from literals, the data is followed by up to 31 zero bytes of padding, so that the next allocation begins on a word boundary.\nWe will refer to these as padded arrays.\r\nThe evmasm pipeline does not pad the results of bytes.concat, string.concat, and the abi.encode* functions (abi.encode, abi.encodePacked, abi.encodeWithSelector, abi.encodeWithSignature, and abi.encodeCall): their data ends exactly where the next allocation begins.\r\nWe will call these arrays unpadded.\r\nWhether an allocation is padded is an implementation detail.\r\nThe current evmasm pipeline and the IR pipeline do not always behave identically in this regard.\r\nTheir behavior may also change in any future version, and code must never rely on it.\r\nInline assembly that touches the padding violates the memory safety rules.\nWhen a value in memory is narrower than its word, its position within the word depends on its type.\nLeft-aligned values, such as bytesN types, start at the first byte of the word.\nRight-aligned values, such as integers, addresses, memory pointers, and the length field of a dynamic array, sit at the end of the word with zero bytes in front.\nStrings use the same representation as bytes, but hold variable-length UTF-8 characters, which is why they do not support index access.\nConverting a string to bytes does not create a copy: bytes(s) refers to the same memory, so delete bytes(s)[i] modifies the string's data in place.\nbytesNN values, on the other hand, are unaffected by the bug: indexing them yields a copy of the byte, not a reference into the underlying data.\nBecause their elements are single bytes, byte arrays are the one situation in which storing a value to memory is not equivalent to storing a full word.\nThe compiler handles this with a single-byte store (mstore8) wherever it knows the element width, with one exception, described in The delete path below.\nThe delete path\ndelete x assigns the zero value of x's type, so delete b[i] should behave exactly like b[i] = 0.\nBoth operations end in a store to the element's location, but in the evmasm pipeline they do not share the store implementation:\n\nThe assignment path knows that a byte-array element is one byte wide and emits the single-byte store, writing exactly that byte.\nThe delete path hands the value to a generic memory-store helper.\nThe helper was written for encoding several values in memory one after another, where any surplus bytes are overwritten by the next value or end up outside the final allocation, so it always stores a full 32-byte word.\nIt receives the element width, but only uses it to compute where the next value would start, not to narrow the store.\n\nThe result is a 32-byte write of zeroes beginning at the deleted element and extending forward.\nSince the write starts at the element rather than at a word boundary, it is not confined to the word containing the element.\nThe length field sits before the data and is never touched, so the array keeps its original length, and anything computed from its contents, such as keccak256, ABI encoding, or simply returning the value, uses the corrupted bytes.\nThe IR pipeline uses the same store for delete b[i] as for the assignment and is unaffected by the bug.\nHow far the write reaches\nThe diagram below shows an array of length 40 together with two separate writes: deleting the element at index 10, where the write stays within the array's allocation, and deleting the element at index 39, where it runs 7 bytes into the next allocation.\n\nCorruption inside the array\nEvery element after the deleted one, up to 31 of them, is cleared as well.\nUnless the array happens to be all-zero beyond the deleted element, this alone changes the array's contents, and it requires no circumstances beyond executing the delete.\nCorruption beyond the array\nFor padded arrays, the padding absorbs part of the write: only deletes of the trailing elements reach past the array, and by no more than 31 bytes minus the padding.\nHow many elements that is depends on the array's length: none for lengths 1, 33, 65, and so on, where the padding is a full 31 bytes, and up to the last 31 elements for lengths that are a multiple of 32, where there is no padding.\nIn the diagram above, the array of length 40 has 24 bytes of padding, so only deletes of its last 7 elements reach past it, by at most 7 bytes.\nWhat gets overwritten is the beginning of the next allocation.\nFor left-aligned values the most significant bytes are cleared.\nFor right-aligned values the write clears the leading bytes of the word, so whether the value survives depends on the size of the write and the width of the value.\nA write of up to 12 bytes leaves an address intact, while the maximal write of 31 bytes clears everything above 255.\nUnpadded arrays\nFor unpadded arrays, deleting any of the last 31 elements reaches the next allocation, whatever the length of the array.\nFor arrays of at most 31 bytes that is every index, including the first.\nExample\nThe following contract demonstrates both kinds of corruption.\nIt relies on consecutive declarations being allocated adjacently, which is how the compiler allocates memory.\ncontract C {\n struct S { uint256 x; }\n\n // Corruption inside the array.\n function clearElement() public pure returns (bytes memory) {\n bytes memory d = hex\"0102030405\";\n delete d[0];\n return d;\n }\n\n // Corruption beyond the array.\n function clearLastElement() public pure returns (uint256) {\n bytes memory b = new bytes(32);\n S memory s = S(type(uint256).max);\n delete b[31];\n return s.x;\n }\n}\n\nCompiled with default settings, i.e., with the evmasm pipeline, the two functions return corrupted data.\nObserved behavior:\nC target = new C();\n\ntarget.clearElement();\n// expected: hex\"0002030405\" (only d[0] cleared)\n// actual: hex\"0000000000\" (d[1] to d[4] cleared as well)\n\ntarget.clearLastElement();\n// expected: 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (2**256 - 1)\n// actual: 0x00000000000000000000000000000000000000000000000000000000000000ff (the 31 most significant bytes of s.x were cleared)\n\nIn clearElement, the five-byte array occupies part of a single padded word, and the delete clears that word from index 0 onward, taking the remaining four bytes of the array with it.\nIn clearLastElement, the array occupies exactly one word with no padding, so deleting the last element writes 31 zero bytes into s, which sits immediately after it.\nIntegers are stored with their most significant byte first, so the 31 overwritten bytes are the most significant ones.\nAll 32 bytes of type(uint256).max are 0xff, only the lowest one is left, and the function returns 255.\nReplacing the deletes with assignments (d[0] = 0 and b[31] = 0) produces the expected results on the same compiler versions.\nSeverity Assessment\nThe compiler emits no warning, and the generated code does not revert at runtime.\nThe corruption manifests as an unexpected result rather than as a failure, which can make it difficult to diagnose.\nHowever, corruption inside the array, which is the more common of the two cases, is likely to be observed by a test that exercises the affected code path with the evmasm pipeline and checks the resulting array.\nThis bug can be triggered without inline assembly.\nIn practice the likelihood is low.\nThe bug went unnoticed for as long as the language has existed, and the Sourcify scan found the triggering pattern in only two distinct deployed functions, neither of which is actually affected.\nIn both, the bytes cleared inside the array are discarded or deleted anyway, so only the memory after the array matters.\nIn one, that is an array length that provably never grows large enough to reach the overwritten bytes.\nIn the other, nothing is allocated there when the deletes run, so the write lands in unused memory.\nThe Fix\nThe fix makes the delete path consult the element width the same way the assignment path already does.\nWhen the element being cleared is a packed byte-array element, the compiler now emits the single-byte store instead of a full-word store, so delete b[i] and b[i] = 0 behave identically on both pipelines.\nRecommended Actions\n\nUpgrade to Solidity 0.8.37 or later before deploying contracts compiled with the evmasm pipeline, which is the default.\nSearch your sources, including libraries and dependencies, for delete applied to elements of bytes values in memory (or string values converted to bytes).\nAs an interim workaround on older compilers, replace delete b[i] with the equivalent assignment b[i] = 0, which is not affected.\n\nAcknowledgements\nWe would like to thank Shaheen Fazim for reporting the bug through the Ethereum Foundation's bug bounty program and providing a reproducer.Previous postNext post","tokens":3153,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262934040,"hash":"d50caf5ed783d135f6cde8b648a6b8ae4a9bc1b6"}
{"url":"https://forum.openzeppelin.com/t/how-to-update-the-crowdsale-rate/5160/4","domain":"forum.openzeppelin.com","title":"How to update the crowdsale rate? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Dec 2020\n\n 4 / 4\n\n Dec 2020\n\n Dec 2020\n\n post by PradhumnaPancholi on Dec 23, 2020\n\n PradhumnaPancholi\n\n So, I have asked the same question before but I got stuck on something and it lead to more confusion. What was doing was adding “1000000000000000” to the rate to increase price by 0.001 ETH. But I realized that it doesn’t work like that. So, I did the math and found a different solution, that was to subtract 0.0014 from rate. Now, solidity has no way to handle decimals. How can I approach this ? Can rates be in decimal values?\n\n 2\n\n 2\n\n post by Skyge on Dec 24, 2020\n\n Skyge\n\n I am not sure what do you mean exactly, but I think if you want to increase the price of each purchase, you can change the rate like so:\ncontract CrowdSale {\n uint256 buyRate = 1e18;\n mapping(address => uint256) public _balance;\n\n function buyTokens() payable public {\n uint256 buyAmount = msg.value * 1e18 / buyRate;\n // TODO: buyAmount should be valid\n _balance[msg.sender] += buyAmount;\n buyRate += 0.0001e18;\n }\n}\n\nSo just like above, cause this is no decimals in the contract, so if you want to do it, you have got to multiply firstly, then divide, 1000 * 9 / 10 => 1000 * 0.9\n\n post by PradhumnaPancholi on Dec 24, 2020\n\n PradhumnaPancholi\n\n I am not sure if I follow. Can you give an example? is it possible to just increase price by 0.001 Eth on each purchase? Or are u talking about rate (asking to make sure on rate vs price)? Also, what is that 0.001e18? Does it meant 0.001 with 10^18 as in literally 0.001 eth? If that’s it than it will solve a big problem for me.\nP.S :- sorry for so many questions\n\n post by Skyge on Dec 24, 2020\n\n Skyge\n\n is it possible to just increase price by 0.001 Eth on each purchase?\nYes, at least, I think so, cause in my demo, I increase the price by the buyRate, so when buyRate is 1e18, it means 1 eth = 1 token, and when buyRate is equal to 1.001e18, it means 1.001 eth = 1 token, so the price increased.\nAlso, what is that 0.001e18? Does it meant 0.001 with 10^18 as in literally 0.001 eth?\nYeah, 0.001e18 is equal to 0.001eth.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 981\n\n May 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022","tokens":672,"squid":"ink-security_audits","role":"Sentinel","at":1791262941236,"hash":"adde357c82f18f23f93f5e174f41cd3033172e27"}
{"url":"https://dev-forum.pyth.network/t/cant-fetch-historical-prices-with-pyth-terminal-api/809/2","domain":"dev-forum.pyth.network","title":"Can't fetch historical prices with Pyth Terminal API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Jul 13\n\n 2 / 12\n\n Jul 13\n\n Aug 5\n\n post by Shawn on Jul 13\n\n Shawn\n\n Hey, I subscribed to the Pyth Terminal Starter plan a few days ago, but since upgrading, I have been unable to retrieve historical prices correctly through the authenticated v2 API.\nFor example, I request data for Unix timestamp 1717632000:\ncurl -X 'GET' \n'https://pyth.dourolabs.app/hermes/v2/updates/price/1717632000?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43' \n-H 'accept: application/json' \n-H 'Authorization: Bearer MY_API_TOKEN'\n\nInstead of returning the price published around the requested timestamp, the response contains a recent publish time—approximately three hours before the request. For example, one response returned 1783937703. Each time I call the endpoint, the publish time changes while remaining roughly three hours behind the current time.\nHowever, the unauthenticated v1 API returns the correct historical publish time for the same timestamp and price-feed ID:\ncurl -X 'GET' \\\n 'https://benchmarks.pyth.network/v1/updates/price/1717632000?ids=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&encoding=hex&parsed=true' \\\n -H 'accept: application/json'\n\nCan you explain why the paid Starter plan’s v2 endpoint is not returning the requested historical price, while the v1 endpoint works correctly? Historical price access was one of the reasons I subscribed, so I would appreciate either instructions for the correct paid endpoint or confirmation that this is a bug that will be fixed.\n\n 6\n\n 4\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Hey Shawn,\nThe endpoint in your example is the Hermes/Pyth Core-compatible API: pyth.dourolabs.app/hermes/v2/updates/price/{publish_time}\nFor Pyth Terminal historical data, please use the Pyth Pro History API instead:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/history?symbol=Crypto.BTC/USD&from=1717632000&to=1717718400&resolution=60”\n\nIf you need point-in-time prices:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/price?ids=1&timestamp=1717632000000000”\n\nNote: benchmarks.pyth.network is the legacy Pyth Core historical endpoint and is being deprecated. Please use Pyth Pro going forward (Preparing for the Pyth Core upgrade | Pyth Developer Hub).\n\n post by Shawn on Jul 13\n\n Shawn\n\n Thanks for your reply.\nI believe the information on the Preparing for the Pyth Core upgrade | Pyth Developer Hub page caused some confusion. It states that an API key will be required by July 31 and that using an API key requires upgrading to the Pyth Pro API. However, the page links to the older Pyth Core/Hermes documentation, which led me to believe that the API key and paid plan applied to those endpoints as well.\nThat is why I misunderstood how the paid API was intended to be used. It may be helpful to update the page or clarify the distinction between the older Hermes endpoints and the Pyth Pro API.\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n The API key requirement is for continuing historical price access through Pyth Pro. The older Pyth Core/Hermes historical endpoints are legacy and will be deprecated, so new integrations should use the Pyth Pro /v1/{channel}/price or /v1/{channel}/history endpoints instead.\n\n post by Shawn on Jul 14\n\n Shawn\n\n Hey just want to ensure, the examples you provided above doesn’t include data that I can sent to smart contract for on-chain verification. If I need that, should I call API like this?\ncurl -X POST https://pyth-lazer.dourolabs.app/v1/price -H \"Authorization: Bearer ***\" -H \"Content-Type: application/json\" -d '{\"priceFeedIds\": [1, 2],\"properties\": [\"price\", \"exponent\", \"publisherCount\", \"confidence\"],\"formats\": [\"evm\"],\"jsonBinaryEncoding\": \"hex\",\"channel\": \"fixed_rate@50ms\",\"timestamp\": 1758690761750000}'\n\nPlease notice that the domain is pyth-lazer. I’m just wondering if this way is valid after July 31 since we want to migrate without any downtime.\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by Aditya520 on Jul 14\n\n 21 days later\n\n post by PythUser on Aug 5\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 191\n\n Jul 13\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n How to get more historical data faster?\n\n Benchmarks(Historic Prices)\n\n 3\n\n 585\n\n Sep 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":2104,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262941846,"hash":"19e10ebe4323de8d4f21c9894df89da9fba2c78d"}
{"url":"https://www.soliditylang.org/survey-2025/","domain":"soliditylang.org","title":"Solidity Developer Survey 2025 Results | Solidity Programming Language","text":"Solidity Developer Survey 2025Key findings70% of respondents are smart contract developers, with India, Nigeria, and the US as the top countriesFoundry is the dominant framework at 57%, up from 51% in 2024. Truffle is down to a single user.Stack-too-deep remains the #1 pain point (47%), with experts reporting it more than beginners (65% vs 25%)88% use AI tools at least monthly, but adoption outpaces trust: 45% express distrust in AI outputOnly 30% of respondents are familiar with Core Solidity. Among those who are, better error handling and delegatecall replacement are the most wanted features. Learn more about Core Solidity.DevEx is improving: 73% report improvement (up from 67% in 2024)Survey OverviewThe Solidity Developer Survey 2025 covers the 2025 development year and was conducted in February-March 2026. It received 640 fully completed responses and 1,095 usable responses after removing empty submissions. Respondents came from 87 countries.Charts use per-question N: every response that answered a given question is included regardless of overall survey completion. All charts are interactive: hover for details.This report presents the data as collected, without editorial interpretation. For our takeaways and planned actions, see the accompanying blog post.Download the raw data (CSV) | Previous surveys: 2024, 2023Respondents per sectionn = 1,095 usable responsesRespondent counts decrease through the survey as some participants drop off before completing all pages.DemographicsWhere do you live?n = 999India, Nigeria, and the United States are the top three countries. Respondents also came from Europe, Latin America, and Southeast Asia.\nTop 20 countriesn = 1029CountryCount%India20519.9%Nigeria14814.4%United States of America838.1%China363.5%Brazil302.9%France272.6%Spain252.4%Germany252.4%United Kingdom252.4%Canada181.7%Argentina171.7%Other171.7%Vietnam171.7%Russia171.7%Poland151.5%Kenya141.4%Italy141.4%Digital nomad131.3%Turkey111.1%Ukraine111.1%Portugal101%Bulgaria101%Indonesia101%Pakistan101%Greece90.9%Netherlands90.9%Venezuela80.8%Georgia80.8%Armenia80.8%Serbia70.7%Ghana70.7%Mexico70.7%Hong Kong70.7%Switzerland60.6%Colombia60.6%Bangladesh60.6%Philippines60.6%Sweden60.6%United Arab Emirates60.6%Thailand60.6%Australia50.5%Slovenia50.5%Czechia50.5%Japan50.5%Taiwan50.5%South Africa50.5%Egypt50.5%Morocco40.4%Denmark30.3%Uganda30.3%Uruguay30.3%Iran30.3%South Korea30.3%Cyprus30.3%Lithuania30.3%Hungary30.3%Austria30.3%Singapore30.3%Romania30.3%Ireland20.2%Peru20.2%Malaysia20.2%Bolivia20.2%Zambia20.2%Israel20.2%Sri Lanka20.2%Honduras10.1%Syria10.1%Azerbaijan10.1%Ivory Coast10.1%Ethiopia10.1%New Zealand10.1%Chile10.1%Bosnia and Herzegovina10.1%Lebanon10.1%Belgium10.1%Belarus10.1%Slovakia10.1%Somalia10.1%Ecuador10.1%Uzbekistan10.1%Cameroon10.1%Zimbabwe10.1%Costa Rica10.1%Croatia10.1%Togo10.1%Latvia10.1%Algeria10.1%Tanzania10.1%What is your native language?n = 1030English is the most common native language (34%), followed by Hindi, Spanish, Portuguese, and Russian.\nNative LanguageCount%English34633.6%Hindi10610.3%Spanish747.2%Portuguese403.9%Russian383.7%French373.6%German302.9%Mandarin272.6%Italian171.7%Vietnamese171.7%Yoruba161.6%Turkish151.5%Ukrainian151.5%Chinese141.4%Telugu131.3%Urdu131.3%Igbo111.1%Tamil111.1%Bengali101%Arabic101%Bulgarian90.9%Swahili90.9%Greek90.9%Polish80.8%Other80.8%Indonesian80.8%Armenian60.6%Dutch60.6%Serbian60.6%Thai60.6%Cantonese60.6%Romanian50.5%Malayalam50.5%Hausa50.5%Japanese50.5%Swedish50.5%Hungarian50.5%Persian40.4%Korean40.4%Marathi40.4%Georgian40.4%Slovenian30.3%Lithuanian30.3%Filipino30.3%Nepali30.3%Danish20.2%Punjabi20.2%Kannada20.2%Gujarati20.2%Odia20.2%Czech20.2%Luganda10.1%Amharic10.1%Zulu10.1%Sindhi10.1%Kamba10.1%Javanese10.1%Konkani10.1%Assamese10.1%Tagalog10.1%Cebuano10.1%Slovak10.1%Somali10.1%Uzbek10.1%Gikuyu10.1%Hebrew10.1%Shona10.1%Setswana10.1%Latvian10.1%Berber10.1%How old are you?n = 102874% of respondents are between 18-34. The 25-34 bracket is the largest (38%), closely followed by 18-24 (36%). 9% of respondents are over 45.\nHow would you rate your coding ability?n = 103357% read/write code professionally. 22% can read/write code but not professionally. 19% are still learning.\nWhich best describes your developer profile?n = 786The majority are smart contract developers (70%). Auditors/security experts are the second largest group (12%). Researchers, fullstack/backend developers, and tooling/library developers are also represented.\nWhich industry do you work in?n = 990Crypto is the most common industry (49%), followed by students (18%) and technology (16%).How many years of professional coding experience?n = 1006Professional coding experience varies, with 3-5 years being the most common (23%). 25% have less than a year or no professional coding experience.\nWhat is your primary programming language?n = 978Solidity is the most-used language (39%), followed by TypeScript (16%) and JavaScript (13%).\nWhat is your favorite programming language?n = 946Solidity is the top favorite (32%), followed by Python (16%), JavaScript (11%), and Rust (10%).\nWhat operating system do you use?n = 976Windows (38%), MacOS (31%), and Linux (29%) are the three main operating systems used.vs. 2024: In 2024, MacOS led at 43%, followed by Windows (29%) and Linux (28%). In 2025, Windows leads at 38%, followed by MacOS (31%) and Linux (30%).Solidity UsageHow often do you use Solidity?n = 86549% of respondents use Solidity daily, 32% weekly. 10% use it rarely or never.How long have you been using Solidity?n = 86550% of respondents have 0-2 years of Solidity experience. 22% have 2-4 years. 4.5% have used Solidity for more than 8 years.How would you rate your Solidity expertise?n = 865Self-rated expertise concentrates in the upper range: 7 and 8 are the most common ratings (34% combined). 14% rated themselves as beginners (1), forming a secondary peak.Which Solidity versions do you use?n = 871 | multiple choicev0.8.x is the most widely used version (86%). Older versions account for 5-8% each (v0.4.x through v0.7.x).Tooling & InfrastructureHow do you get the Solidity compiler?n = 871 | multiple choice79% get Solidity through a framework. npm (24%) and GitHub releases (16%) are the next most common.What editor do you use?n = 834VSCode-based editors (VS Code, Cursor, Windsurf) account for ~80% of usage. Note: the survey grouped these under a single option, so we cannot distinguish between them. Other editors include Vim/Neovim, IntelliJ, and Zed.\nWhat is your primary development framework?n = 828Foundry is the most used primary framework (57%). Hardhat v3 and v2 account for 33% combined.vs. 2024: Foundry increased from 51% to 57%. Hardhat is at 33% combined in both years, but the 2025 survey distinguished between v2 (15%) and v3 (18%). Truffle dropped from 2.4% in 2024 to a single remaining user.Which additional frameworks do you use?n = 871 | multiple choiceRemix is the most used secondary framework (41% of respondents use it alongside their primary framework). 10% did not report using a secondary framework.Which SDKs / libraries do you use?n = 871 | multiple choiceethers.js is the most used SDK (70%). viem follows (39%) and wagmi (33%). web3.py (16%) is also used. web3.js has 9 mentions. The library has been deprecated. alloy (6%) is also used, primarily in Rust-based tooling.\nCompilation & VerificationDo you rely on older EVM version support?n = 56634% of respondents rely on compiler support older than the current EVM version (Osaka).Oldest EVM version targetedn = 162 | shown to those relying on older EVM supportAmong those who rely on older EVM support, Paris, London, and Cancun are the most common targets.Have you used the SMTChecker?n = 85445% of respondents don't know what the SMTChecker is. 30% have not used it. 18% have tried it and 7% use it often.Have you used the IR pipeline (--via-ir)?n = 85235% of respondents don't know what the IR pipeline is. 28% use it sometimes, 15% use it often, and 22% do not use it.vs. 2024: IR pipeline awareness also improved: 35% don't know what it is in 2025 (vs 46% in 2024).Is the IR pipeline too slow to compile?n = 284 | shown to IR pipeline users onlyAmong respondents who use the IR pipeline, 39% say it takes too long to compile.Are you familiar with Sourcify?n = 85148% of respondents don't know about Sourcify. 28% know about it but don't use it. 23% know about it and use it.vs. 2024: Sourcify awareness improved: 48% don't know about it in 2025 (vs 56% in 2024), and usage increased from 17% to 24%.Contract verification pain pointsn = 142 | multiple choiceTop themes: no issues (18%), framework verification tools (15%), verification flaky/unreliable (15%), metadata/compiler mismatch (12%), Etherscan issues (11%).“Etherscan is the de-facto standard and it's very unreliable and not transparent. Sourcify is much better and I wish I could tell Etherscan it's already verified there.”“Too many chains, too many block explorers. Etherscan should use one source of truth i.e. Sourcify then verifying once should auto verify everywhere.”Do you use appendCBOR: false or bytecodeHash: none?n = 58949% don't know what it is. 11% use it.Why do you use appendCBOR: false or bytecodeHash: none?n = 39Main reasons: easier verification (36%), deterministic/reproducible builds (28%), and reduced bytecode size (23%).Chains & DeploymentWhich chains do you deploy to?n = 871 | multiple choiceEthereum mainnet leads (52%). Base is second (40%), ahead of Arbitrum (35%) and Polygon (30%). 72 respondents (8%) mentioned deploying only to testnets.\nDo you use other smart contract languages?n = 871 | multiple choice43% don't use any other smart contract language. Rust is the most selected alternative (28%). This may reflect cross-ecosystem usage (Solana, NEAR, Stylus) rather than EVM development, as the question did not restrict answers to EVM-compatible languages.\nDeveloper ExperienceHow has the Solidity DevEx changed in the past year?n = 52173% report improvement (43% a bit, 31% a lot). 25% reported no change. 2% say it got worse (8 respondents).vs. 2024: DevEx sentiment is slightly more positive: 73% report improvement (vs 67% in 2024). The percentage reporting things got worse is unchanged at 2%.What has improved in the DevEx?n = 151 | multiple choiceTop themes: personal skill growth (39%), Foundry improvements (15%), better tooling (14%), better compiler/errors (13%). Note: 39% of responses described personal skill growth rather than ecosystem improvements.“Foundry continued to ship solid features. Mainly improved tooling, not major language features that are super useful.”“Custom errors in requires, custom storage layouts, transient storage.”Which recurring issues do you encounter?n = 702 | multiple choiceStack-too-deep errors are the most reported issue (47%). Bytecode size limits (33%) and debugging issues (33%) follow. Optimizer-related issues account for 13%. 23% report no recurring issues.\nvs. 2024: The question format changed between years (single multi-select in 2024 vs separate checkboxes in 2025), which may account for some of the decrease. With that caveat: in 2024, stack-too-deep was reported by 68%, debugging by 55%, bytecode size by 51%, and optimizer issues by 22%. In 2025, these are 47%, 33%, 33%, and 13% respectively.How could debugging be improved?n = 79Top themes: better error messages (28%), step-by-step debugger (16%), better stack traces (16%), transaction replay/simulation (14%), IDE integration (11%).“A step-by-step debugger similar to what you'd find in any modern IDE, with breakpoints and variable inspection for Solidity contracts.”“Transaction replay with full state access. Being able to see every storage slot change and every call in sequence.”Which language features are most important?n = 702 | multiple choiceContracts as objects and inheritance is considered important by 54%, the most frequently selected feature. Unbounded dynamic arrays (34%) and inline assembly (29%) follow.Biggest pain points with Solidityn = 215 | multiple choiceTop themes from 215 free-text responses: stack-too-deep (20%), bytecode size limit (11%), gas optimization tradeoffs (9%), array/data structure limitations (8%), verbose syntax (8%).“Compiler's optimization defects continuously make me think about what's going on under the hood instead of focusing on my logic. Things that should be zero cost are not (functions, structs, variables).”“Gas optimisations force bad programming practices, like repeating code inline instead of abstracting into functions, avoiding zeroing storage slots in favour of using arbitrary sentinel values.”“Too many footguns around storage vs memory vs calldata, especially with complex structs, arrays, and inheritance.”How could the documentation be improved?n = 102 | multiple choiceMost requested improvement is more real-world examples (27%). 16% say the docs are good as-is. Simplifying for beginners (14%) and better organization/search (12%) follow.“Better language reference page. Everything is explained in great detail, but it would be great with a reference page to quickly find what you need similar to: https://tour.gleam.run/everything/”“I think the documentation should rationalize why Solidity is the way it is more often - and how it relates to the EVM's design.”Most wanted near-term featuresn = 702 | multiple choiceBetter gas optimizations is the most requested feature (44%). EIP-712 typehash support (29%) is the second most requested. Reference types in transient storage (23%) and more fine-grained storage layout control (23%) are also among the top requests.\nCore Solidity204 respondents are familiar with Core Solidity (30% of the 678 who answered this question).Are you familiar with Core Solidity?n = 678Core Solidity is an initiative to redesign the language from scratch, incorporating lessons from 10 years of Solidity development. 30% of respondents who answered this question are familiar with it.Which Core Solidity features interest you most?n = 204 | multiple choice | shown to those familiar with Core SolidityAmong those familiar, better error handling / try-catch replacement (43%) and better delegatecall mechanism / library replacement (41%) are the most selected. 14% selected none.\nWould removing inheritance cause challenges?n = 200 | shown to those familiar with Core Solidity63% say removing inheritance would cause challenges.How difficult would rewriting to traits be?n = 201 | shown to those familiar with Core Solidity44% estimate the rewrite to type classes/traits would be somewhat difficult, 21% very difficult.Would your codebase benefit from compile-time evaluation?n = 201 | shown to those familiar with Core Solidity71% of those familiar with Core Solidity say their codebase would benefit from improved compile-time evaluation.Feedback on Core Solidityn = 43 | multiple choice | shown to those familiar with Core Solidity23% are skeptical/cautious. 21% are excited/supportive. 21% are concerned about fragmentation. 12% want it kept low-level. \"Security focus\" refers to respondents who emphasized that security should be the primary goal of any language redesign.“Excited to see this project unfold. If we can have a new language that takes all the pain points of the last 10 years of Solidity and fixes them it would be great.”“I am very concerned that Core Solidity is trying to turn solidity into some kind of academic Haskell language that requires a PhD in types to use.”“Still unclear how core solidity is not a new language and how the syntax and semantics will be made backwards compatible.”“I care most that the bytecode is good. Syntactic sugar is less important to me.”“Please do not remove inheritance and contracts as classes, everything should be backwards compatible as we will lose all the years of work, libraries and standards created.”AI in Solidity DevelopmentDo you use AI tools for development?n = 65058% use AI tools daily. 88% use them at least monthly. 4% don't use AI and don't plan to.How do you view AI in development?n = 65077% of respondents view AI favorably (46% favorable, 31% very favorable). 9% hold unfavorable views. 14% are indifferent.How much do you trust AI-generated code?n = 59149% somewhat trust, 30% somewhat distrust, 15% highly distrust, and 6% highly trust AI output. Notably, adoption outpaces trust: 88% use AI tools at least monthly, yet 45% express some level of distrust in the output.What do you use AI for in your workflow?n = 629 | multiple choiceTesting (61%), documenting code (59%), and learning about codebases (58%) are the top AI use cases. Debugging (53%), auditing (52%), and searching for answers (52%) follow. Writing code (49%) and reviewing code (49%) are somewhat lower.\nWhich editors do you use with AI agents?n = 629 | multiple choiceVSCode (60%), Cursor (32%), and Antigravity (16%) are the top editors used with AI agents.Preferred AI assistantn = 545Claude Code is the most selected preferred assistant (61%), followed by Codex/ChatGPT (16%) and Gemini (10%). Note: this survey was distributed via Solidity community channels, which may introduce distribution bias.\nCross-AnalysisFor the cross-analysis charts, self-rated expertise was grouped into three tiers: Beginner (1-4), Intermediate (5-7), and Expert (8-10).Self-rated expertise by years using Solidityn = 865Self-rated expertise increases with years of Solidity experience. The most common self-rating of 8+ appears at the 4-6 year mark.\nSelf-rated expertise by years codingn = 865Self-rated Solidity expertise also correlates with general programming experience, though less strongly than with Solidity-specific experience.\nRecurring issues by expertise leveln = Beginner (1-4): 181, Intermediate (5-7): 285, Expert (8-10): 236Stack-too-deep is reported by 25% of beginners vs 65% of experts. Bytecode size limit follows a similar pattern (17% vs 47%). Debugging issues are consistent across all levels (29-35%).\nExpertise distribution by frameworkn = Foundry: 467, Hardhat v3: 145, Hardhat v2: 126, Remix: 62Framework choice correlates with expertise level: Remix users are predominantly beginners (60%), Hardhat v3 has the highest share of intermediate users (47%), and Foundry has the highest share of expert users (38%).\nAI usage by expertise leveln = Beginner (1-4): 164, Intermediate (5-7): 260, Expert (8-10): 226Daily AI usage is higher among more experienced respondents: 52% of beginners, 58% of intermediate, and 62% of expert respondents use AI daily.AI trust vs. usage frequencyn = 59136% of daily AI users express distrust (somewhat or highly) in the output. Nearly all who highly trust AI (37 of 38) are daily users.Expertise: students vs. professionalsn = Students: 147, Professionals: 692Students cluster at lower expertise (peak at 5), professionals peak at 7-8.Framework choice: students vs. professionalsn = Students: 137, Professionals: 666Remix usage is higher among students; Foundry is more common among professionals.AI usage: students vs. professionalsn = Students: 101, Professionals: 536AI adoption is similar between students and professionals.Final Feedback HighlightsThe 151 final feedback responses included the following recurring themes:Feature requests:Bytecode size limit increase (mentioned multiple times)Generics support for library developersBetter type conversionsNative cryptographic primitives and smoother Yul integrationPre-dispatch hook: ability to run code before/after method dispatchDevelopment tools for Zed editorAI-related:Multiple respondents report AI-generated Solidity is unreliableRequest for the Solidity team to help AI write more secure codeCommunity and communication:More visibility and outreach for SolidityMore detail in Core Solidity article on try-catch replacement and typeclassesMore outreach for the survey through ecosystem projects“Solidity is a surprisingly good language for expressing the kinds of problems you have for EVM smart contracts. Thanks for it.”“Smart contracts are hard since you have to balance the quality of the code vs the cost for the user. Ideally correctly written code should also be the proper way to optimize for gas, and not the other way around.”“Please fix the bytecode size limit, it's not always practical to refactor contract into multiple smaller ones, doing so is always a huge lift in dev and ops work.”“Solidity and the surrounding ecosystem are moving in the right direction, especially in tooling, testing frameworks, and developer workflows. However, developer experience is still heavily constrained by debugging limitations, EVM-level abstractions, and low-level complexity that slows productivity and increases risk.”“Keep pushing for better native cryptographic primitives and smoother Yul integration. It makes building privacy-focused tools and DeFi mechanisms safer and gas-efficient.”“It feels like the primarily direction of Solidity should be security, compiler performance, more aggressive bytecode optimization + developer ergonomics.”“Keep pushing, everyone. It's a pleasure to write smart contracts today compared to where we were 3 to 5 years ago.”MethodologySurvey ran February-March 2026 using LimeSurvey1,482 total submissions; 387 responses dropped (empty submissions or those who did not complete any survey page)640 fully completed (all 8 pages), 1,095 usable (reached page 1+)Free-text \"Other\" answers were normalized and merged into parent columnsMulti-value free-text answers are counted toward each mentioned itemTroll/noise entries were filtered outPer-question N is used throughout: each chart shows the number of respondents who answered that specific questionQuestions marked \"conditional\" were only shown to respondents who met a prerequisiteDistributed via Solidity community channels and social mediaFree-text responses were manually categorized by theme. A single response can match multiple themes. Misinterpretation or miscategorization of individual responses is possible; treat theme counts as approximate","tokens":5482,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262945480,"hash":"e9a0b0aee55660aa90b7f17c07382267d31268f1"}
{"url":"https://forum.openzeppelin.com/t/changing-rate-manually-in-a-crowdsale/5061/1","domain":"forum.openzeppelin.com","title":"Changing rate manually in a crowdsale - Support / Contracts - OpenZeppelin Forum","text":"Changing rate manually in a crowdsale \n\n SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 1 / 6\n\n Dec 2020\n\n May 2022\n\n post by PradhumnaPancholi on Dec 15, 2020\n\n PradhumnaPancholi\n\n So, I have written a crowdsale and configured it to change rate after every purchase. I just want to confirm that my way on changing rate is correct here.\nThis is what I am doing.\n uint256 public currentRate = 0;\n constructor(\n uint256 initialRate,\n address payable wallet, //This is where ETH/funds go to\n IERC20 token,\n address tokenWallet //this wallet holds the tokens($BOOKS)//\n )\n AllowanceCrowdsale(tokenWallet)\n Crowdsale(initialRate, wallet, token)\n public\n {\n currentRate = initialRate;\n }\n\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // over riding the post purchase method to update the rate\n uint256 updatedBy = 1000000000000000; // 0.001 ethers in weis\n currentRate = currentRate.add(updatedBy);\n }\n\n 3\n\n 2\n\n post by abcoathup on Dec 16, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nI assume you are only showing a cut down version of your contract and that you have overriden rate to return the current rate, and _getTokenAmount to use your changing rate.\nIt appears ok, though for anyone reading this I always recommend appropriate testing and auditing.\n\n post by PradhumnaPancholi on Dec 21, 2020\n\n PradhumnaPancholi\n\n Yes, I am showing cut down version\nfunction _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n\n return weiAmount.mul(currentRate);\n\n }\n\n // @DEV: overriding the rate method to return updated rate instead of initialRate //\n\n // here, we are returning \"currentRate\" as that's the value that gets updated after each purchase//\n\n function rate() public view returns (uint256) {\n\n return currentRate;\n } \n\nMy question is mainly in regards to changing the price. To avoid any confusion, “price” means how much ETH for 1 Token(18 decimal). And rate is what we have in Openzeppelin crowdsale. So, I want to increase the price by 0.001 ETH of each token after every purchase. My question is if this is the correct way to do that?\n\n 8 days later\n\n post by abcoathup on Dec 29, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nSorry for the delay in responding I was on vacation for the holidays.\nIf you are changing the price after each purchase (rather than after a certain amount of tokens sold or Ether raised), you may want to consider what happens with frequent small purchases and what incentives/disincentives this creates.\n\n 27 days later\n\n post by PradhumnaPancholi on Jan 26, 2021\n\n PradhumnaPancholi\n\n Got it, thanks for the help.\nAnd sorry for my delayed response. I took kind of a break recently.\n\n 1 year later\n\n post by Prince_Wisdom_ifenkw on May 21, 2022\n\n Prince_Wisdom_ifenkw\n\n I need help urgently with setting up my rate. I want to make 1ETH = 0.1TKN.\nBut I can't seem to use 0.1 as the rate, I keep getting error.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020","tokens":888,"squid":"ink-security_audits","role":"Sentinel","at":1791262952788,"hash":"e812985584f67bc437e0c451767a150b7a56b729"}
{"url":"https://dev-forum.pyth.network/t/cant-fetch-historical-prices-with-pyth-terminal-api/809/3","domain":"dev-forum.pyth.network","title":"Can't fetch historical prices with Pyth Terminal API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Jul 13\n\n 3 / 12\n\n Jul 13\n\n Aug 5\n\n post by Shawn on Jul 13\n\n Shawn\n\n Hey, I subscribed to the Pyth Terminal Starter plan a few days ago, but since upgrading, I have been unable to retrieve historical prices correctly through the authenticated v2 API.\nFor example, I request data for Unix timestamp 1717632000:\ncurl -X 'GET' \n'https://pyth.dourolabs.app/hermes/v2/updates/price/1717632000?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43' \n-H 'accept: application/json' \n-H 'Authorization: Bearer MY_API_TOKEN'\n\nInstead of returning the price published around the requested timestamp, the response contains a recent publish time—approximately three hours before the request. For example, one response returned 1783937703. Each time I call the endpoint, the publish time changes while remaining roughly three hours behind the current time.\nHowever, the unauthenticated v1 API returns the correct historical publish time for the same timestamp and price-feed ID:\ncurl -X 'GET' \\\n 'https://benchmarks.pyth.network/v1/updates/price/1717632000?ids=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&encoding=hex&parsed=true' \\\n -H 'accept: application/json'\n\nCan you explain why the paid Starter plan’s v2 endpoint is not returning the requested historical price, while the v1 endpoint works correctly? Historical price access was one of the reasons I subscribed, so I would appreciate either instructions for the correct paid endpoint or confirmation that this is a bug that will be fixed.\n\n 6\n\n 4\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Hey Shawn,\nThe endpoint in your example is the Hermes/Pyth Core-compatible API: pyth.dourolabs.app/hermes/v2/updates/price/{publish_time}\nFor Pyth Terminal historical data, please use the Pyth Pro History API instead:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/history?symbol=Crypto.BTC/USD&from=1717632000&to=1717718400&resolution=60”\n\nIf you need point-in-time prices:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/price?ids=1&timestamp=1717632000000000”\n\nNote: benchmarks.pyth.network is the legacy Pyth Core historical endpoint and is being deprecated. Please use Pyth Pro going forward (Preparing for the Pyth Core upgrade | Pyth Developer Hub).\n\n post by Shawn on Jul 13\n\n Shawn\n\n Thanks for your reply.\nI believe the information on the Preparing for the Pyth Core upgrade | Pyth Developer Hub page caused some confusion. It states that an API key will be required by July 31 and that using an API key requires upgrading to the Pyth Pro API. However, the page links to the older Pyth Core/Hermes documentation, which led me to believe that the API key and paid plan applied to those endpoints as well.\nThat is why I misunderstood how the paid API was intended to be used. It may be helpful to update the page or clarify the distinction between the older Hermes endpoints and the Pyth Pro API.\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n The API key requirement is for continuing historical price access through Pyth Pro. The older Pyth Core/Hermes historical endpoints are legacy and will be deprecated, so new integrations should use the Pyth Pro /v1/{channel}/price or /v1/{channel}/history endpoints instead.\n\n post by Shawn on Jul 14\n\n Shawn\n\n Hey just want to ensure, the examples you provided above doesn’t include data that I can sent to smart contract for on-chain verification. If I need that, should I call API like this?\ncurl -X POST https://pyth-lazer.dourolabs.app/v1/price -H \"Authorization: Bearer ***\" -H \"Content-Type: application/json\" -d '{\"priceFeedIds\": [1, 2],\"properties\": [\"price\", \"exponent\", \"publisherCount\", \"confidence\"],\"formats\": [\"evm\"],\"jsonBinaryEncoding\": \"hex\",\"channel\": \"fixed_rate@50ms\",\"timestamp\": 1758690761750000}'\n\nPlease notice that the domain is pyth-lazer. I’m just wondering if this way is valid after July 31 since we want to migrate without any downtime.\n\n post by Shawn on Jul 14\n\n Shawn\n\n KemarTiti\n\n Hello,\nI’m becoming increasingly confused by the documentation, as it does not clearly explain how to satisfy what seems like a straightforward use case.\nMy requirement is to retrieve the price data for a specific historical timestamp in a hex-encoded format, then submit that data to my existing EVM smart contract for on-chain verification.\nAfter reading the documentation several times, my understanding is that using the Pyth Pro API would require my smart contract to integrate with or migrate to the Pyth Lazer contracts. That would be a contract-level integration change, not simply an API endpoint upgrade.\nCould you please clarify the simplest supported way to do the following?\n\nRequest the price for a specific historical timestamp.\nReceive the corresponding signed, hex-encoded price update data.\nSubmit that data to an existing EVM smart contract for verification.\n\nIs this possible using the standard Pyth contracts, or is migrating to Pyth Lazer mandatory?\nThe current documentation makes the relationship between the Pro API, historical price retrieval, and the required on-chain contracts unnecessarily difficult to understand. A direct example covering this exact workflow would be very helpful.\nThanks.\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by Aditya520 on Jul 14\n\n 21 days later\n\n post by PythUser on Aug 5\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 191\n\n Jul 13\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n How to get more historical data faster?\n\n Benchmarks(Historic Prices)\n\n 3\n\n 585\n\n Sep 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":2415,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262952882,"hash":"5131a3517a3389e9814330c371525ccdb66e77e4"}
{"url":"https://www.soliditylang.org/blog/2025/11/14/core-solidity-deep-dive/","domain":"soliditylang.org","title":"Core Solidity Deep Dive | Solidity Programming Language","text":"Core Solidity Deep DivePosted by Solidity Team on November 14, 2025AnnouncementsSolidity is the most widely used smart contract language. It is robust, trustworthy, and today\nsecures hundreds of billions of dollars of value. We are proud of this success, and its track\nrecord of secure code generation. Users of Solidity will however be keenly aware of some of its\nlimitations. The type system often lacks the expressiveness to produce reusable library code or\nenforce core safety properties. The language has very limited support for compile time evaluation.\nMany features are implemented in an inconsistent manner, or do not always work as expected.\nFixing these limitations within the current implementation has proven difficult. Upgrades must be\nmade in a somewhat ad-hoc manner, and each new addition makes reasoning about the correctness of\nsubsequent changes more difficult. We did not feel confident that we would be able to safely extend\nthe language in this way to add the kind of features that our users were asking for, and that we\nfeel are required to keep up with the ever increasing scale of systems being developed in Solidity.\nCore Solidity is our solution. It is a rebuild of the Solidity type system and compiler front/middle end that will:\n\nintroduce powerful new features,\nprovide a strong foundation for compiler correctness as we continue to extend the language in the future,\nempower library authors and support a community-driven process for language evolution,\nexpand the capabilities of verification and analysis tooling.\n\nIn addition to growing and expanding the language, we will also be removing or reworking some\nexisting features. We are already certain that we will be removing inheritance entirely. Additional\nchanges are less certain, but we are considering potentially replacing or reworking features\nlike try/catch, libraries, function pointers, type conversion, and data locations.\nThat being said, Core Solidity in comparison to Classic Solidity is not a new language, but for the most part an extension. It will retain a familiar look and feel, and most of the existing Classic Solidity concepts will carry over.\nWe currently have a working prototype for Core Solidity. Most of the examples in this post typecheck\nand can produce executable code. Some examples make use of yet to be implemented syntax and will compile in the future. Much of the core type theory is stable, but we want to add at least compile\ntime evaluation and modules before we will consider the type system finalized. Extensive work\nremains to build out the standard library and reach feature parity with Classic Solidity.\nWhile the prototype is in a working state, it is not optimized for user experience. We are actively working on the prototype and new features will be incrementally made available on the project's repository for feedback and experimentation. We are looking forward to your feedback.\nA Note on Syntax\nMost of the work to date has been focused on the design and implementation of the type system, and the\nassociated code generation pipeline down to Yul. In order to avoid getting bogged down in\nbikeshedding around syntax, and with the desire to validate our core ideas with a working\nimplementation as soon as possible, we moved ahead with a provisional syntax. You can expect\nextensive changes before release. Our current intention is to eventually closely match the syntax of Classic Solidity. For any new syntax, you should expect that the final version will feel\ncloser to languages like TypeScript or Rust.\nNew Language Features\nCore Solidity takes ideas from pure functional programming languages (e.g. Haskell, Lean), as well\nas modern systems languages (e.g. Rust, Zig). We are extending Solidity with the following new\nfeatures:\n\nAlgebraic datatypes (also known as sum / product types) and pattern matching\nGenerics / parametric polymorphism\nTraits / type classes\nType inference\nHigher order and anonymous functions\nCompile time evaluation\n\nWe think that these core primitives will enable developers to produce stronger\nabstractions, write more modular and reusable code, and leverage the type system to enforce\nsafety properties.\nWe will continue to support the kind of low level access to the EVM that is often required by\nproduction implementations: assembly will remain a core primitive, and we will extend assembly blocks with the ability to directly call functions defined in the high level language. Users will be\nable to disable the built in abstractions (e.g. contract dispatch generation, ABI\ndecoding, default storage layout generation), following the \"pay for what you use\" philosophy of\nlanguages like Rust and C++.\nAlgebraic data types and pattern matching\nAlgebraic data types (ADTs) provide a principled foundation for data modeling through the composition of\nsum and product types. Sum types are an extension of enums from Classic Solidity. They represent exclusive alternatives, i.e. a value inhabits exactly one\nvariant. Product types combine multiple values into structured tuples. These two primitives can\nbe combined to define precise types that make invalid states completely\nunrepresentable, allowing the type system to enforce invariants entirely at\ncompile time.\nLet's start with a very simple type:\ndata Bool = True | False\n\nThe left-hand side of the above statement defines the name of a new type\n(Bool), and the right-hand side defines the set of values that comprise the Bool type (True or\nFalse).\nWe can also use ADTs to implement the same kind of patterns as User Defined\nValue Types in\nClassic Solidity. For example, an 18 decimal fixed point (a wad) can be represented as\ndata wad = wad(uint256)\n\nThe wad type (left-hand side) has a single value constructor wad (right-hand side) that holds a uint256 as its underlying\nrepresentation. Type names and value constructors live in\nseparate namespaces and so can share names. Simple wrapper types like this will be erased by the compiler during the translation\ninto Yul, meaning that wad has the exact same runtime representation as a uint256.\nNow we can define a type-safe fixed-point multiplication routine. We will need to extract the\nunderlying uint256, manipulate it, and then wrap the result in a new wad constructor. To unwrap\nwe will use pattern matching. Pattern matching is a control flow mechanism that lets us destructure\nand inspect data by shape. Instead of nested if-else chains, we can write declarative\nexpressions that exhaustively consider all possible values of the matched type.\nlet WAD = 10 ** 18;\n\nfunction wmul(lhs : wad, rhs : wad) -> wad {\n match (lhs, rhs) {\n | (wad(l), wad(r)) => return wad((l * r) / WAD);\n }\n}\n\nLets look at a more complete example. Consider the following type definition for an auction state:\ndata AuctionState =\n NotStarted(uint256)\n | Active(uint256, address)\n | Ended(uint256, address)\n | Cancelled(uint256, address);\n\nAuctionState has four alternative value constructors: NotStarted specifies that the auction has\nnot yet started and stores its reserve price, Active denotes that the auction has begun and it\nstores the current highest bid and the address that made that bid, Ended represents an auction\nthat has finished successfully and holds the highest bid and the address of the winner, and\nCancelled represents a cancelled auction, holding the highest bid and winning address at the time\nof cancellation.\nNow we can define a processAuction function that transitions the state based on the current state\nand msg.value. The match statement lets us perform an exhaustive case analysis over each\npossible alternative state. The _ case at the end of the match is a default that handles any\nremaining states that have not yet been explicitly matched. Exhaustiveness is enforced by the\ncompiler, ensuring that every possible state is handled exactly once.\nfunction processAuction(state: AuctionState) -> AuctionState {\n match state {\n | NotStarted(reserve) =>\n require(msg.value >= reserve);\n return Active(msg.value, msg.sender);\n | Active(currentBid, bidder) =>\n require(msg.value > currentBid);\n transferFunds(bidder, currentBid);\n return Active(msg.value, msg.sender);\n | _ => return state;\n }\n}\n\nGenerics and type classes\nCore Solidity introduces two new mechanisms for code sharing and polymorphism: generics and\ntype classes (sometimes also referred to as traits).\nGenerics implement parametric polymorphism: they enable us to write functions and data structures\nthat behave in a uniform way for all types. As an example, we can define a polymorphic identity\nfunction:\nforall T . function identity(x : T) -> T {\n return x;\n}\n\nHere, the forall introduces a new type variable T that is scoped to the function definition.\nWe can also define generic types, like the following Result type that is parameterised by the type of\nthe payload in the error case:\ndata Result(T) = Ok | Err(T)\n\nGenerics are powerful, but by themselves quite limited. Most interesting operations are not defined\nfor all types. Type classes are the solution: they let us define an overloaded type\nspecific implementation for the same function signature, and when combined with class constraints let us\ndefine generic functions that are polymorphic over a restricted subset of types.\nA type class is simply an interface specification. Consider the following definition of a class of\ntypes that can be multiplied:\nforall T . class T:Mul {\n function mul(lhs : T, rhs : T) -> T;\n}\n\nInstead of the concrete wmul function that we defined above for our wad fixed point type, it\nis more idiomatic to define an instance (known in Rust as impl) of the Mul type class for wad.\nThis gives us a uniform syntax for multiplication across all types, and allows us to use our wad\ntype in functions that are generic over any instance of the Mul type class:\ninstance wad:Mul {\n function mul(lhs : wad, rhs : wad) -> wad {\n return wmul(lhs, rhs);\n }\n}\n\nIf we want to write a function that can accept any type that is an instance of Mul we need to add\na constraint to the signature:\nforall T . T:Mul => function square(val : T) -> T {\n return Mul.mul(val, val);\n}\n\nSimple wrapper types like wad are very common, and one type class that can be particularly helpful\nwhen working with them is Typedef:\nforall T U . class T:Typedef(U) {\n function abs(x : U) -> T;\n function rep(x : T) -> U;\n}\n\nThe abs (abstraction) and rep (representation) functions let us move between wrapper types and\ntheir underlying types in a generic way and without the syntactic noise of having to introduce\npattern matching every time we want to unwrap a type. The instance for wad would look like this:\ninstance wad:Typedef(uint256) {\n function abs(u : uint256) -> wad {\n return wad(u);\n }\n\n function rep(x : wad) -> uint256 {\n match x {\n | wad(u) => return u;\n }\n }\n}\n\nNote that parameters that appear after the class name like U in the above Typedef definition are \"weak\": their value is uniquely\ndetermined by the value of the T parameter. If you are familiar with Haskell or Rust, this is\neffectively an associated type (although for any type system nerds reading, we implement it using a\nrestricted form of functional dependencies). To put it more plainly, we can only implement a single\ninstance of Typedef for wad: the compiler would not allow us to implement both\nwad:Typedef(uint256) and wad:Typedef(uint128). This restriction makes type inference much more\npredictable and reliable by sidestepping many of the potential ambiguities inherent to full\nmulti-parameter type classes.\nFor a real world example of how generics and type class constraints can be used to eliminate\nboilerplate or repetitive code, compare the combinatorial explosion of overloads required for the\nconsole.log implementation\nin forge-std to the following generic Core Solidity function that covers the functionality of all\nthe single argument overloads from the original library. The word type used in this implementation\nis a low level type that represents a Yul variable, and is the only type that can be passed into or\nout of assembly blocks.\nforall T . T:ABIEncode => function log(val : T) {\n let CONSOLE_ADDRESS : word = 0x000000000000000000636F6e736F6c652e6c6f67;\n let payload = abi_encode(val);\n\n // extract the underlying word representation of the payload\n let ptr = Typedef.rep(payload);\n\n assembly {\n pop(\n staticcall(\n gas(),\n CONSOLE_ADDRESS,\n add(ptr, 32),\n mload(ptr),\n 0,\n 0\n )\n )\n }\n}\n\nSimilarly to Rust and Lean, all invocations of type classes and generic functions are fully\nmonomorphized at compile time, meaning polymorphic functions do not incur a runtime overhead when\ncompared to fully concrete functions. While this does mean that the compiled EVM code will\npotentially contain multiple specialized versions of the same generic function, this does not entail\na binary size overhead compared to Classic Solidity which would anyway require multiple function\ndefinitions for equivalent functionality. We consider this to be the correct tradeoff for our\ndomain.\nHigher-order and anonymous functions\nFunctions possess first-class status within the type system, enabling their use\nas parameters, return values, and assignable entities.\nAs an example, consider the following which implements a custom ABI decoding\nof a triple of booleans from a single word value:\nforall T . function unpack_bools(fn : (bool, bool, bool) -> T) -> ((word) -> T) {\n return lam (bools : word) -> {\n let wordToBool = lam (w : word) { return w > 0; };\n\n // extract the right-most bit from `bools`\n let b0 = wordToBool(and(bools, 0x1));\n\n // shift `bools` by one and extract the right-most bit\n let b1 = wordToBool(and(shr(1, bools), 0x1));\n\n // shift `bools` by two and extract the right-most bit\n let b2 = wordToBool(and(shr(2, bools), 0x1));\n\n return fn(b0, b1, b2);\n };\n}\n\nThe function unpack_bools implements a custom ABI decoding. It is a higher-order function which decorates an input function that takes three individual bools and returns any type by extracting the arguments from the right-most three bits. This is an example which is impossible to implement in Classic Solidity, even with modifiers, since they cannot change the arguments passed to the wrapped function.\nWe also support the definition of (non-recursive) anonymous functions using the lam keyword.\nFunctions defined in this way can capture values available in the defining scope. As an example\nconsider this testing utility that counts the number of times an arbitrary function is called:\nforall T U . function count_calls(fn : (T) -> U) -> (memory(word), (T) -> U) {\n let counter : memory(word) = allocate(32);\n return (counter, lam (a : T) -> {\n counter += 1;\n return fn(a);\n });\n}\n\nOur implementation here is similar to systems languages like Rust and C++: the compiler produces a\nunique type for each anonymous function that contains the capture, and these unique types are\nmade callable by making them instances of the invokable type class (similar to the Fn\ntrait in Rust). This approach is runtime gas efficient.\nType inference\nCore Solidity supports the inference of types in almost any position. Annotations are usually only\nneeded when considered desirable for readability or understanding. Inference is decidable,\nand the situations in which ambiguities requiring annotation can occur are very limited. This lets\nus solve a lot of the syntactic clutter required when writing Classic Solidity. As an example,\nconsider the following Classic Solidity definition:\nFor example, assigning an expression to a variable in Classic Solidity can often result in redundant annotation if those\ntypes are already present in the expression being assigned:\n(bytes memory a, bytes memory b) = abi.decode(input, (bytes, bytes));\n\nThe same definition is much cleaner in Core Solidity:\nlet (a, b) = abi.decode(input, (uint256, uint256));\n\nAnother common frustration with Classic Solidity is the syntactic noise required when defining array\nliterals. Consider the following snippet:\nuint256[3] memory a = [1, 2, 3];\n\nThis declaration is rejected by the Classic Solidity compiler with the following error message:\nError: Type uint8[3] memory is not implicitly convertible to expected type uint256[3] memory.\n\nThe underlying reason for this error is that Classic Solidity implements a limited and special cased form of type inference for array\nliterals: the assigned element type is the type of the first expression on the list such that all other expressions can be implicitly converted to it (in this case uint8). The compiler then throws a type error when attempting to assign this\nvalue to a variable with an incompatible type.\nIn order for the previous definition be accepted, we can add an unintuitive type coercion to the first array element:\nuint256[3] memory a = [uint256(1), 2, 3];\n\nThe constraint based inference algorithm in Core Solidity is a lot more general, and will allow us\nto omit this coercion:\nuint256[3] memory a = [1, 2, 3];\n\nCompile Time Evaluation\nWe do not yet have a prototype implementation of compile time evaluation, so there are no concrete\nexamples to share here yet. We are however very convinced that this will be a particularly valuable\nextension to the language and have its implementation as one of our top priorities. We want to ship a general-purpose feature, therefore a strong goal is to minimize the differences between the runtime and compile time variants\nof the language, allowing for a familiar syntax and code sharing between the two contexts.\nNon-trivial design and implementation work remains here. We are exploring the degree to which access\nto memory at compile time is required, and if it is, what kind of analysis passes we would want to\nimplement to guard against accidental leakage of references to compile time memory. We are also\ninvestigating what kind of compile time specific primitives we might want to add, and whether we\nwant to expand the language capabilities around reflection.\nWe will publish more on our designs once they stabilise. We want to make sure the needs of the\ncommunity are met here: if you have concrete real world use cases in mind for this feature, we would\nbe very interested to hear them.\nSAIL, Desugaring, and the Standard Library\nIn addition to expanding the surface language, the transition to Core Solidity will also introduce a\nnew user accessible mid level IR: SAIL (Solidity Algebraic Intermediate Language). This is the\n\"Core\" in Core Solidity. It's the most minimal language that lets us\nexpress the full range of high-level language constructs found in Classic Solidity. It consists of the following primitive constructs:\n\nFunctions\nContracts\nAssembly (Yul) blocks\nSAIL variable introduction and assignment\nA short circuiting if-then-else expression\nAlgebraic datatypes & pattern matching\nType classes\nGenerics\n\nA SAIL variable is conceptually similar to a Yul variable. The compiler will associate EVM stack space to it.\nSAIL has a single builtin type (word) that has the same range of values as a Classic Solidity\nbytes32 or uint256, and can semantically be viewed as the type of an EVM stack slot. Contracts in SAIL are very low level (essentially just a runtime entrypoint and initcode\nentrypoint).\nAlthough our current implementation of SAIL uses Yul as an assembly language, this choice is largely\narbitrary from a theoretical standpoint, and it could also be instantiated over, e.g. a RISC-V based\nassembly language instead.\nWe are confident that SAIL is expressive enough that we can implement all high level language\nfeatures and types as a combination of standard library definitions and desugaring passes, i.e. compile\ntime syntactic transformations into SAIL primitives. Core Solidity is then SAIL extended\nwith additional syntax sugar and libraries. It is similar to Yul in its dual function as both a compiler\nIR and a user facing low level language, and the full range of SAIL primitives will be directly\navailable when writing Core Solidity. This style of language construction is often used in other\nhigh assurance domains (e.g. theorem provers), and we believe it has important benefits for both\nusers of the language and the safety and security of its implementation.\nWe expect to be able to construct an executable formal semantics for SAIL.\nThis will allow us to mathematically guarantee core properties of the Solidity type system, provide\na reference implementation for differential fuzzing, and formally\nverify both the standard library and higher-level language constructs. We believe that this will be\nan essential part of our correctness story as both the language and the scale of the systems it is\nused to construct continue to grow.\nLibrary authors will have almost the same expressive power as the language designers, and will\nbe able to create abstractions that feel built-in to the language itself (a \"library-based\nlanguage\"). It will be possible to define and use alternative standard library implementations, or to\ndisable the standard library completely. With the standard library disabled, it will be possible to\nwrite Core Solidity code with almost the same level of control as low level assembly languages like\nYul or Huff, but with a modern, expressive type system, based on a mathematically rigorous foundation.\nWe also expect that the introduction of SAIL will make it much easier to extend\nand improve the language. In many cases it will be possible to make deep improvements via a pull\nrequest to the standard library alone. When new syntax or desugaring passes are required, we expect\nthem to be much easier to prototype and specify in SAIL without requiring knowledge and\nunderstanding of compiler internals. We hope that SAIL and Core Solidity will allow us to transition to\na community driven RFC-style process for changes to the high-level language and standard library.\nA Userspace abi.encode\nLet's look at how SAIL can be used to implement high-level Core Solidity features. abi.encode is a complicated\nand highly generic function that Classic Solidity provides as a compiler builtin. A full in-language\nimplementation would not be possible in Classic Solidity due to the recursive nature of the ABI\nspecification and the resulting infinite number of expressible types. The implementation presented\nhere is relatively concise, but does make use of some more advanced patterns and features. We\nwant to emphasise that existing users of Solidity will be able to be productive and make use of\ntheir existing knowledge without having to concern themselves with these kind of low level internal\ndetails. At the same time, we hope that advanced users and library authors will be excited by the new\npotentials these features enable.\nFor presentation purposes we restrict ourselves to the fragment required to encode uint256.\nuint256\nTo begin we will construct the type uint256. In Classic Solidity the definition of this type and\nits associated operations are all built-in language constructs. In SAIL, it is defined entirely in-language as a simple wrapper around a word. We also define a Typedef instance for it:\ndata uint256 = uint256(word);\n\ninstance uint256:Typedef(word) {\n function abs(w : word) -> uint256 {\n return uint256(w);\n }\n\n function rep(x : uint256) -> word {\n match x {\n | uint256(w) => return w;\n }\n }\n}\n\nmemory and bytes\nWe can build types that represent pointers into the various EVM data regions by wrapping a\nword. Notice that in the following snippet the type parameter on the memory pointer is phantom\n(i.e. it appears only in the type, but is not mentioned in any of the value constructors). This is a\ncommon idiom in ML family languages like Haskell or Rust that lets us enforce compile-time\nconstraints without runtime overhead.\ndata memory(T) = memory(word)\n\nThe bytes type in Classic Solidity represents a tightly packed byte array with a size only known\nat runtime. Classic Solidity always\nrequires that a data location is specified for a value of type bytes, so in Core Solidity we define it as\nan empty type with no value constructors. Empty types can only be used to instantiate phantom type parameters. This means that, as in Classic Solidity, instances of bytes cannot live on stack.\ndata bytes;\n\nNotice that in this construction of pointers and data locations, the data location is attached to\nthe type (instead of the variable binding as it is in Classic), allowing for the definition of e.g.\nmemory structures containing references to storage.\nThe Proxy type\nThe last piece of machinery required for abi.encode is the Proxy type:\ndata Proxy(T) = Proxy;\n\nAs with the memory definition, the type parameter here is phantom, but, unlike memory, Proxy\ncarries no additional information at runtime. It exists only as a marker type that lets us pass\ninformation around at compile time. Types like this are completely zero cost (i.e. they are\ncompletely erased at runtime and do not appear in the final compiled program at all).\nAlthough somewhat esoteric, Proxy is very useful and gives us a lot of control over type inference\nand instance selection without needing to pass data at runtime where it is not needed. It is often\nused in both Haskell (where it is also called Proxy) and Rust (std::marker::PhantomData).\nabi.encode\nNow we are ready to implement Classic Solidity's abi.encode in SAIL. We start by defining a\ntype class for ABI related metadata. Note that since this class does not need to care about the\nactual value of the type being passed to it, we use a Proxy to keep our implementation as lean as\npossible.\nforall T . class T:ABIAttribs {\n // how many bytes should be used for the head portion of the ABI encoding of `T`\n function headSize(ty : Proxy(T)) -> word;\n // whether or not `T` is a fully static type\n function isStatic(ty : Proxy(T)) -> bool;\n}\n\ninstance uint256:ABIAttribs {\n function headSize(ty : Proxy(uint256)) -> word { return 32; }\n function isStatic(ty : Proxy(uint256)) -> bool { return true; }\n}\n\nNow we define another class that handles the low level encoding into memory. The class presented\nhere contains some extraneous details needed for encoding compound and dynamic types that are not be\nnecessary for the simple uint256 encoding we are implementing now. We present the full complexity\nto demonstrate that we have the machinery required for these harder cases.\n// types that can be abi encoded\nforall T . T:ABIAttribs => class T:ABIEncode {\n // abi encodes an instance of T into a memory region starting at basePtr\n // offset gives the offset in memory from basePtr to the first empty byte of the head\n // tail gives the position in memory of the first empty byte of the tail\n function encodeInto(x : T, basePtr : word, offset : word, tail : word) -> word /* newTail */;\n}\n\ninstance uint256:ABIEncode {\n // a unit256 is written directly into the head\n function encodeInto(x : uint256, basePtr : word, offset : word, tail : word) -> word {\n let repx : word = Typedef.rep(x);\n assembly { mstore(add(basePtr, offset), repx) }\n return tail;\n }\n}\n\nFinally, we can define a top-level abi_encode function that handles the initial memory allocation\nand free memory pointer updates (we have omitted the implementation of the low level\nget_free_memory and set_free_memory helpers for the sake of brevity):\n// top level encoding function.\n// abi encodes an instance of `T` and returns a pointer to the result\nforall T . T:ABIEncode => function abi_encode(val : T) -> memory(bytes) {\n let free = get_free_memory();\n let headSize = ABIAttribs.headSize(Proxy : Proxy(T));\n let tail = ABIEncode.encodeInto(val, free, 0, Add.add(free, headSize));\n set_free_memory(tail);\n return memory(free);\n}\n\nCompatibility and Interoperability\nIntroducing such a major revision to any programming language is challenging. While a certain degree\nof breakage is inevitable (and even desired), we want to make the transition as smooth as possible\nand avoid a split in the language.\nAs with previous breaking upgrades to Solidity, ABI compatibility will be maintained between\nversions, allowing individual contracts written in incompatible versions to interoperate and live\nside by side in the same project (this strategy is also used by Rust with their \"Editions\" feature).\nWe are also investigating the feasibility of deeper interoperability beyond just the contract ABI.\nWe expect that it will be possible to share at least free functions and interface definitions\nbetween language versions.\nWhile there will be breakage of both syntax and semantics, our intention is to minimize it to cases\nwhere it is either strictly necessary or brings significant benefits that justify the transition\ncost. We expect that simple code that does not use inheritance will look and feel very similar in\nboth language versions, with only minor syntactic differences (largely just the switch from prefix\nto postfix types). We are also considering reworking or replacing some features that have proven to\nbe problematic or limiting in practice (e.g. try/catch, libraries, function pointers, data\nlocations). Users can expect that some moderate changes may be required to adapt their code that\nmakes use of these features. Code that makes heavy use of inheritance will of course require the\nlargest changes.\nWe will be investigating the potential for automated upgrades, and if reliable and robust\nimplementations are possible expect to ship such tools at release.\nAvoiding a Python 2 -> Python 3 style split is top of mind, and we believe that upgrades should be\nmanageable and that it will be possible to carry them out in an incremental manner.\nThe Road to Production\nThis section outlines our current thinking on achieving production readiness and our strategy for\nmaking such deep changes to the language in a safe way. Please note that this is a tentative plan,\nand may be subject to extensive change. We are not yet in a position where we feel confident about\ncommitting to concrete timelines. We will provide more details as\nwe get closer to a production implementation.\nWe have a prototype implemented in a separate repository: solcore. We\ncan typecheck SAIL programs, and have a code generation pipeline down to Yul implemented. We still\nwant to implement at least compile time evaluation and a module system before we will consider the\ntype system to be finalized. We have a rudimentary standard library implemented, and enough\ndesugaring stages built out to implement the most fundamental features of Classic Solidity. We can\nproduce ABI compatible contracts, with dispatch, ABI encoding / decoding, and storage access.\nThere is still significant work remaining at the prototype stage before we can begin to consider a\nfull production implementation. We want to finalize the type system, flesh out the standard library,\nand write enough code to be confident that what we have is sufficient to support the full range of\nfeatures that we think are necessary. We need to thoroughly document the type system and compiler\ninternals. We also expect to spend time working with existing power users and library authors to\ngather feedback and make any necessary changes.\nOnce we are confident that the prototype is stable, work will split into two parallel streams:\n\nProduction implementation: we will reimplement the typechecker, desugaring and Yul generation\npasses in a systems language (e.g. Rust, C++, Zig), and integrate it into solc proper. This\nimplementation will focus on correctness, performance, and providing the best possible\ndiagnostics and error messages.\nExecutable Formal Semantics: we will work to mechanize our existing LaTeX specification in a\ntheorem proving environment (likely Lean). This will be used to build confidence in our\nproduction implementation, as well as the standard library and type system itself.\n\nOnce the production implementation is relatively stable. There will be a period of time in which\nCore Solidity is available as an experimental feature, but not yet marked as production ready. We\nwill use this period to gain real world feedback from our users, continue fuzzing, and put the\nstandard library out for external review. When we are confident that the new frontend is free of\nmajor faults, we will release a breaking version of solc with Core as the default language version.\nBeyond 1.0\nOur focus right now is to deliver the language as described in this post. This is a significant\nundertaking, and not one that we expect to be finished in the near term. We do not however consider\nit the end of road for Solidity, but rather as a foundation for future expansion. While the\nfollowing list is tentative, non exhaustive, and subject to significant change, these are some of\nthe features that we currently consider interesting for future post-core iterations of the language:\n\nLinear types: Linearity is a deeply powerful primitive. We consider its resource semantics to be\nparticularly well suited to enforce the kind of accounting invariants that are often of interest\nfor systems written in Solidity. Linearity alone is powerful enough to be able construct advanced\nfeatures like object capabilities, effect systems, and session types,\nsignificantly expanding the scope and complexity of invariants that can be guaranteed by the type system.\nLinearity can be used to help guarantee the safe usage of memory, allowing users to\noptimize without fear, and giving the compiler itself the context it needs to be able to safely\neliminate unnecessary allocations and make more optimal usage of memory.\n\nMacros: Since a great deal of the compilation stack for Core Solidity is already designed around simple\nmacro like syntactic transformation passes, a natural extension to the language would be to\nimplement a user facing macro system, and reimplement these desugaring passes as in language macro\ntransformations. This would give a similar level of expressive power and flexibility as languages\nwith cutting edge macro systems like Lean or Racket, allowing library authors to introduce\narbitrary new syntax and even supporting the construction of entirely new languages on top of SAIL.\nWhile attractive in many ways, we are also cautious about the potential for misuse such a feature\nwould have, and would want to take great care to implement sufficient safeguards against obfuscation\nof malicious code.\n\nRefinement Types: Refinement types are an intuitive and user friendly way to document and enforce\nprogram level invariants. We are particularly interested in schemes that implement decidable\nlogics (as opposed to full SMT based approaches), which we consider more likely to be usable at\nscale by non experts (although of course with an associated tradeoff in the complexity of properties\nthat can be expressed).\n\nTheorem Proving: Code written in Solidity often manages large amounts of money in a highly\nadversarial environment. Correctness is of the utmost importance. Languages like\nATS and Bedrock 2 have\nshown how the integration of theorem proving with low level systems orientated languages\ncan be used to support the production of code that is both correct and maximally resource efficient.\nWe are interested in investigating the degree to which the kind of semi-automated reasoning\navailable in theorem provers could be integrated directly into the language (likely via an Isabelle\nstyle embedding of an appropriate logic via the module system).\n\nConclusion\nCore Solidity represents a foundational re-imagining of the language, designed to equip developers\nwith a more secure, expressive, and mathematically sound toolkit for the next generation of smart\ncontracts. We invite you to join the discussions and share your perspective. Your input is crucial\nin helping us prioritize development and shape the future of the language, and comments are very\nwelcome in the feedback thread for this post on our forum.Previous postNext post","tokens":8924,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262956515,"hash":"53655e926dbfe599c3ed3427f2d962f0d7992aee"}
{"url":"https://forum.openzeppelin.com/t/changing-rate-manually-in-a-crowdsale/5061/6","domain":"forum.openzeppelin.com","title":"Changing rate manually in a crowdsale - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 6 / 6\n\n May 2022\n\n May 2022\n\n post by PradhumnaPancholi on Dec 15, 2020\n\n PradhumnaPancholi\n\n So, I have written a crowdsale and configured it to change rate after every purchase. I just want to confirm that my way on changing rate is correct here.\nThis is what I am doing.\n uint256 public currentRate = 0;\n constructor(\n uint256 initialRate,\n address payable wallet, //This is where ETH/funds go to\n IERC20 token,\n address tokenWallet //this wallet holds the tokens($BOOKS)//\n )\n AllowanceCrowdsale(tokenWallet)\n Crowdsale(initialRate, wallet, token)\n public\n {\n currentRate = initialRate;\n }\n\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // over riding the post purchase method to update the rate\n uint256 updatedBy = 1000000000000000; // 0.001 ethers in weis\n currentRate = currentRate.add(updatedBy);\n }\n\n 3\n\n 2\n\n post by abcoathup on Dec 16, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nI assume you are only showing a cut down version of your contract and that you have overriden rate to return the current rate, and _getTokenAmount to use your changing rate.\nIt appears ok, though for anyone reading this I always recommend appropriate testing and auditing.\n\n post by PradhumnaPancholi on Dec 21, 2020\n\n PradhumnaPancholi\n\n Yes, I am showing cut down version\nfunction _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n\n return weiAmount.mul(currentRate);\n\n }\n\n // @DEV: overriding the rate method to return updated rate instead of initialRate //\n\n // here, we are returning \"currentRate\" as that's the value that gets updated after each purchase//\n\n function rate() public view returns (uint256) {\n\n return currentRate;\n } \n\nMy question is mainly in regards to changing the price. To avoid any confusion, “price” means how much ETH for 1 Token(18 decimal). And rate is what we have in Openzeppelin crowdsale. So, I want to increase the price by 0.001 ETH of each token after every purchase. My question is if this is the correct way to do that?\n\n 8 days later\n\n post by abcoathup on Dec 29, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nSorry for the delay in responding I was on vacation for the holidays.\nIf you are changing the price after each purchase (rather than after a certain amount of tokens sold or Ether raised), you may want to consider what happens with frequent small purchases and what incentives/disincentives this creates.\n\n 27 days later\n\n post by PradhumnaPancholi on Jan 26, 2021\n\n PradhumnaPancholi\n\n Got it, thanks for the help.\nAnd sorry for my delayed response. I took kind of a break recently.\n\n 1 year later\n\n post by Prince_Wisdom_ifenkw on May 21, 2022\n\n Prince_Wisdom_ifenkw\n\n I need help urgently with setting up my rate. I want to make 1ETH = 0.1TKN.\nBut I can't seem to use 0.1 as the rate, I keep getting error.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020","tokens":878,"squid":"ink-security_audits","role":"Sentinel","at":1791262963410,"hash":"b0f47edabdb3809fc5fd2eaecf8ef9bf2c4113e5"}
{"url":"https://dev-forum.pyth.network/t/cant-fetch-historical-prices-with-pyth-terminal-api/809","domain":"dev-forum.pyth.network","title":"Can't fetch historical prices with Pyth Terminal API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Can’t fetch historical prices with Pyth Terminal API \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Jul 13\n\n 1 / 12\n\n Jul 13\n\n Aug 5\n\n post by Shawn on Jul 13\n\n Shawn\n\n Hey, I subscribed to the Pyth Terminal Starter plan a few days ago, but since upgrading, I have been unable to retrieve historical prices correctly through the authenticated v2 API.\nFor example, I request data for Unix timestamp 1717632000:\ncurl -X 'GET' \n'https://pyth.dourolabs.app/hermes/v2/updates/price/1717632000?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43' \n-H 'accept: application/json' \n-H 'Authorization: Bearer MY_API_TOKEN'\n\nInstead of returning the price published around the requested timestamp, the response contains a recent publish time—approximately three hours before the request. For example, one response returned 1783937703. Each time I call the endpoint, the publish time changes while remaining roughly three hours behind the current time.\nHowever, the unauthenticated v1 API returns the correct historical publish time for the same timestamp and price-feed ID:\ncurl -X 'GET' \\\n 'https://benchmarks.pyth.network/v1/updates/price/1717632000?ids=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&encoding=hex&parsed=true' \\\n -H 'accept: application/json'\n\nCan you explain why the paid Starter plan’s v2 endpoint is not returning the requested historical price, while the v1 endpoint works correctly? Historical price access was one of the reasons I subscribed, so I would appreciate either instructions for the correct paid endpoint or confirmation that this is a bug that will be fixed.\n\n 6\n\n 4\n\n post by KemarTiti on Jul 13\n\n KemarTiti\n\n Hey Shawn,\nThe endpoint in your example is the Hermes/Pyth Core-compatible API: pyth.dourolabs.app/hermes/v2/updates/price/{publish_time}\nFor Pyth Terminal historical data, please use the Pyth Pro History API instead:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/history?symbol=Crypto.BTC/USD&from=1717632000&to=1717718400&resolution=60”\n\nIf you need point-in-time prices:\nbash\n\ncurl -H “Authorization: Bearer ***” \n“https://pyth.dourolabs.app/v1/fixed_rate@200ms/price?ids=1&timestamp=1717632000000000”\n\nNote: benchmarks.pyth.network is the legacy Pyth Core historical endpoint and is being deprecated. Please use Pyth Pro going forward (Preparing for the Pyth Core upgrade | Pyth Developer Hub).\n\n post by Shawn on Jul 13\n\n post by KemarTiti on Jul 13\n\n post by Shawn on Jul 14\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by KemarTiti on Jul 14\n\n post by Shawn on Jul 14\n\n post by Aditya520 on Jul 14\n\n 21 days later\n\n post by PythUser on Aug 5\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Action Required: Pyth Pro History API Auth Required Starting July 24\n\n Announcements\n\n announcements\n\n 1\n\n 191\n\n Jul 13\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n How to get more historical data faster?\n\n Benchmarks(Historic Prices)\n\n 3\n\n 585\n\n Sep 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":1723,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262963461,"hash":"2fa6b4c95323adb22a377d2041d2576836c5e71f"}
{"url":"https://forum.soliditylang.org/t/solidity-0-8-37-is-released/3753/1","domain":"forum.soliditylang.org","title":"Solidity 0.8.37 is released! - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solidity 0.8.37 is released! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 10\n\n 1 / 1\n\n Sep 10\n\n 26d ago\n\n post by czepluch on Sep 10\n\n czepluch\n\n Solidity Team\n\n Solidity 0.8.37 is released.\nThis is primarily a bugfix release.\nImportant bugfixes:\n\nLow/medium severity: delete b[i] on a bytes array in memory cleared 32 bytes instead of one on the evmasm pipeline, corrupting up to 31 bytes after the element. All versions up to and including 0.8.36 are affected. The IR pipeline is not affected, and b[i] = 0 clears exactly one byte on both pipelines. Write-up: Memory Byte Array Element Delete Clears Whole Word Bug | Solidity Programming Language\nLow/medium severity: With --via-ir, in certain call graph configurations containing mutual recursion, the stack-to-memory mover could assign the same spill slot to variables of two different functions, silently overwriting one of them. Versions 0.7.2 through 0.8.36 are affected. This is distinct from the spill bug fixed in 0.8.36. Write-up: Spill Slot Collision Across Mutual Recursion Bug | Solidity Programming Language\nVery low severity: Named arguments of a custom error passed to require were put on the stack in call-site order instead of declaration order (IR pipeline), so the encoded revert data could be structurally valid but not reflect the values used. Only revert data is affected. Write-up: Misordered Named Parameters in require with Custom Errors Bug | Solidity Programming Language\n\nOther miscompilations, fixed but not classified as security issues:\n\nUninitialized internal function pointers read from a packed storage slot yielded the wrong value when a later variable in the slot was non-zero (evmasm pipeline). Only affects pointers compared before ever being assigned, and relying on function pointer equality is fragile anyway.\nConstants read in both checked and unchecked contexts got the semantics of whichever use site was generated first (IR pipeline). Deterministic, independent of transaction input and easily caught by tests.\n\nFeatures and changes:\n\nblock.slotnum (uint64) and the Yul builtin slotnum() expose the SLOTNUM opcode (EIP-7843) when compiling with --evm-version amsterdam. Amsterdam support is still experimental and incomplete.\nThe experimental SSA CFG code generator gets a planning stack shuffler in place of the greedy one.\nThe experimental LSP mode and the Generic Solidity prototype are removed. The LSP was unfinished, and Generic Solidity has been superseded by the standalone solcore prototype.\npragma experimental ABIEncoderV2 now emits a deprecation warning. It has been redundant since 0.8.0 and will be removed in a later 0.8.x release.\nDeprecation warnings for the EVM versions constantinople, petersburg, istanbul and berlin, and for the SMTChecker BMC engine.\n\nRelease post: Solidity 0.8.37 Release Announcement | Solidity Programming Language\nRelease and changelog: Release Version 0.8.37 · argotorg/solidity · GitHub\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 180\n\n Dec 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1727,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791262967381,"hash":"55d38a7805a770870f460dbb51e83fbd4e371fb6"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/7","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 7 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1685,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262973808,"hash":"ccd2fde4f448737364b11848df223731eaf17ec0"}
{"url":"https://forum.openzeppelin.com/t/how-to-change-rate-price-of-a-token-in-crowdsale/4845","domain":"forum.openzeppelin.com","title":"How to change rate/price of a token in Crowdsale? - Support / Contracts - OpenZeppelin Forum","text":"How to change rate/price of a token in Crowdsale? \n\n SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n 2\n\n Nov 2020\n\n 1 / 10\n\n Nov 2020\n\n Jan 2022\n\n post by PradhumnaPancholi on Nov 29, 2020\n\n PradhumnaPancholi\n\n So, I am trying to write a sale contract which increases the price or modifies the rate of a crowdsale after each purchase(when buyTokens is called). I was going to implement it with a state variable the adds (+1) each time when buyTokens is called. And writing a custom buy method. But, I just realized that there is no method to change rate. Or is it and I miissed it? Can someone help me on this?\n\n Rate for Crowdsale\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by Skyge on Nov 30, 2020\n\n Skyge\n\n Yeah, if you want to change the rate, you need to add it by yourself.\n\n post by PradhumnaPancholi on Dec 1, 2020\n\n PradhumnaPancholi\n\n Yes, but I am currently struggling to get the rate in my contract. How am I suppose to access it and modify it? It’s a private variable\n\n post by Skyge on Dec 1, 2020\n\n Skyge\n\n Maybe you can have a look at this doc: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n PradhumnaPancholi\n\n Hi @PradhumnaPancholi,\nThere is an IncreasingPriceCrowdsale in OpenZeppelin Contracts 2.x that you could use for inspiration.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\n 1 year later\n\n post by ZrowGz on Jan 16, 2022\n\n ZrowGz\n\n Hello, I was looking at setting the token price equal to, say, $1 per minted token. I know I can calculate how many wei a dollar is and set that price at deployment, but I was hoping that there is a way to check this each time the token is minted.\nOr, could I simply have the rate pegged to a different token (instead of eth), so that it would only mint when it receives USDC? Such that the rate could still be \"1\" but it only responds to USDC or FRAX or something along those lines. Or does it just utilize the chain's base token: if deployed on Polygon, a rate of 1 would be 1 TOK for 1 matic? (I would think that it would be in the chain's base coin, since that is the gwei you're paying your gas in)\nFor example, I deploy when 1 eth = $3000, I could code in that you'd get 3000TOK for 1 eth. But then the price could climb to $4000 which would still only issue 3000 TOK.\nThank you!\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nWhy is the rate() function revert?\n function rate() public view returns (uint256) {\n revert(\"IncreasingPriceCrowdsale: rate() called\");\n }\n\nWouldn't it be useful if it returned the current rate value knowing that it precisely changes over time?\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nYou will have to connect your smart contract to an oracle that returns the price of the token you need and thus update it from time to time.\nhttps://docs.chain.link/docs/get-the-latest-price/\n\n post by ZrowGz on Jan 17, 2022\n\n ZrowGz\n\n Thanks for the link to that! Is there instead a way to tell it to accept only a different token, like USDC?\nAlso, does the wei rate calculate in comparison to the chain's base token, like MATIC on Polygon?\n\n post by Cainuriel on Jan 18, 2022\n\n Cainuriel\n\n I cannot answer your questions because although I know this service I have never used it. Maybe another reader can help you.\n[image]\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Increasing Price Crowdsale\n\n Contracts\n\n erc20,crowdsale\n\n 2\n\n 1.1k\n\n Nov 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020","tokens":998,"squid":"ink-security_audits","role":"Sentinel","at":1791262974938,"hash":"b241b5579ab2a6f16ccfb0c0e85d848cedd7fe84"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/9","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 9 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello, I really want to collect price data of stablecoins from Pyth and I am currently using pyth_client lib but I cannot take price data in 2023. Does anyone know how I can get access to the price data in 2023 or does anyone have a source that proves pyth historical price data in 2023 is not available.\nCurrently looking at the solana price account on solscan and it says no items between 01/03/2023 and 31/03/2023 so does that mean I cannot take data between that period? Account HT2PLQBcG5EiCcNSaMHAjSgd9F98ecpATbk4Sk5oYuM | Solscan\n\n 7\n\n 5\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n Hey @makimakiver\nWhich stablecoins are you after?\nOne thing to note is that you cannot retrieve historical data the Pyth price feeds/oracle have not created.\nMeaning if feed A/USD goes live today, 2nd September 2025, you will not be able to retrieve some historical price pre-dating the feed support. So there could be scenarii where there is actually no historical data available (from Pyth).\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I’m currently planning to get price data of USDT, USDC, if they are available, then I want to take a look into other stablecoins, but not too sure these two I mentioned had been created in 2023 March\n\n post by KemarTiti on Sep 2, 2025\n\n KemarTiti\n\n You can check if / when the price feed launched directly on TradingView.\nFor USDT, data goes back as early as 2022.\nCheck the picture on how to pick Pyth as your source\nScreenshot 2025-09-02 at 13.41.57875×278 18 KB\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I see, I can see the price feed’s info now. Then is it possible to take the address of the price feed account that are previously used? If not possible I’ll try to take data from trading view\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n I am currently trying using the tradingview API (link: Benchmarks - Swagger UI )and fetch the price of stablecoins in 2023 March but it would be cool if I can get address of price feed used at that time, so that I can get the confidence interval and can see the level of dispersion at that time period\n\n post by makimakiver on Sep 2, 2025\n\n makimakiver\n\n Hello Currently taking data from tradingview api but firstly does that mean I am taking data from pyth? If so, can I see Confidence Interval from the TradingView API? I am using the API via this website: https://benchmarks.pyth.network/docs#/ https://www.tradingview.com/rest-api-spec/#operation/getHistory\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1981,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791262984188,"hash":"1f7d0a8c74e86bb06c26fcf3412ceecb115b6f54"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJvUHnOBEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJvVrcCQEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJUL2hjL2VuLWdiL2FydGljbGVzLzE4MTQ4MTY4MjI1OTQ3LVdoeS1kby1JLW5lZWQtRVRILXRvLXVzZS10aGUtQXJiaXRydW0tbmV0d29yawY7CFQ6CXJhbmtpCA%3D%3D--d2e2b2b35f0662e565906e35a97f9c524980ffb1","domain":"support.arbitrum.io","title":"Why do I need ETH to use the Arbitrum network? – Arbitrum Foundation","text":"When moving funds (ETH and non-ETH) from Ethereum (L1) to Arbitrum (L2), you'll need to have ETH in your wallet on the corresponding Arbitrum chain. This is because ETH is the currency used for gas fees on Arbitrum and all Arbitrum transactions are powered by ETH.\n\n Recently viewed articlesBridging over a new tokenUsing Arbitrum's traditional bridge to move funds to MainnetSkipping the bridgeWhy are there 2 different USDC's on Arbitrum?Why wait 7 days to claim funds when bridge to Ethereum?\n\n Related articles\n\n You need ETH to power transactions\n\n How can I add Arbitrum network to my wallet?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why are there 2 different USDC's on Arbitrum?\n\n Skipping the bridge\n\n Please sign in to leave a comment.","tokens":192,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263007589,"hash":"ddc9c479e4b7b1c85968ce3c368ae2021af007d9"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvWwSO3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJvUHnOBEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJTL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4Mjc2NTkzMTc5LVdoeS1hcmUtdGhlcmUtMi1kaWZmZXJlbnQtVVNEQy1zLW9uLUFyYml0cnVtBjsIVDoJcmFua2kJ--245c4bc2e88a4f0dff8fc9b8c2c26ef26ded500d","domain":"support.arbitrum.io","title":"Why are there 2 different USDC's on Arbitrum? – Arbitrum Foundation","text":"Understanding native vs. bridged\nNative USDC is officially issued by Circle and always redeemable 1:1 for US dollars.\nIn the case of Arbitrum, there also exists a “bridged” form of USDC, known as USDC.e, that’s been bridged from Ethereum. USDC.e is not issued by Circle.\n\nNative USDC on Arbitrum:\n\nToken Name: USD Coin\nToken Symbol: USDC\nToken Address: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n\nBridged USDC on Arbitrum: (from Ethereum)\n\nToken Name: Bridged USDC\nToken Symbol: USDC.e\nToken Address: 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8\n\n Recently viewed articlesWhy do I need ETH to use the Arbitrum network?Bridging over a new tokenUsing Arbitrum's traditional bridge to move funds to MainnetSkipping the bridgeWhy wait 7 days to claim funds when bridge to Ethereum?\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n How can I add Arbitrum network to my wallet?\n\n You need ETH to power transactions\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Please sign in to leave a comment.","tokens":274,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263017558,"hash":"045448d1938563d30ca2c160544782761807e94c"}
{"url":"https://io.net/docs/reference/caas/get-started-with-caas-api","domain":"io.net","title":"Getting Started with CaaS API - io.net","text":"​Generate an API key\nYou can obtain an API key for IO Cloud in two ways:\n\nVia the web interface\nBy using a two-step process (first generate a JWT token, then request the API key using cURL).\n\n​Option 1: Generate an API Key via Web Interface\nIO Clouds APIs authenticate requests using API keys. You can generate API keys from your user account. Note: When generating an API key, make sure to specify the associated IO Cloud project.\nAlways treat your API key as a secret. Do not share it or expose it in client-side code (e.g., browsers or mobile apps). Instead, store it securely in an environment variable or a key management service on your backend server.\n​Option 2: Generate an API Key Using a JWT Token\n​Step 1. Get a JWT Token\nIO’s API is built around RESTful principles. You can use IO’s APIs to gain insights into different elements of our network.\nTo use IO’s APIs, you must supply a JWT token in the header of your request. Follow the instructions below to generate a token:\n\nGo to io.net > IO ID > io.cloud tab.\nIn the UI, right-click and select Inspect.\nIn the Inspect tool, click Network.\nRefresh the io.cloud page.\nIn the list of elements, click Devices.\nScroll down to the Request Headers section.\nCopy and store the Token.\n\nThis token is valid for 21 days.\n\n​Step 2. Generate an API Key via cURL\nUse the JWT token to request your API key:\ncurl -X POST 'https://api.io.solutions/v1/api-keys/' /\n -H 'accept: application/json' /\n -H 'token: $JWT_TOKEN' /\n -H 'Content-Type: application/json' /\n -d '{\n \"description\": \"API Key Name\",\n \"expires_at\": \"2025-07-17T19:54:36.418Z\",\n \"project\": \"io-cloud\",\n \"scopes\": [\"all\"]\n}'\n\nUse the returned key with the X-API-KEY header in your requests.\nAlways treat your API key as a secret. Do not share it or expose it in client-side code (e.g., browsers or mobile apps). Instead, store it securely in an environment variable or a key management service on your backend server.\n\n​Making requests\nAccessing APIs requires IO Credits. Please make sure to request IO credits before using any API endpoints. Contact support or visit the IO Credits page for more information.\nInclude the API key in an Authorization HTTP header for all API requests:\nAuthorization: X-API-KEY \\$IOCLOUD_API_KEY\n\nReplace $IOCLOUD_API_KEY with your actual API key.\n​Example: Check Available Replicas per Location\nHere is an example cURL command to check available replicas per location in IO Cloud:\ncurl https://api.io.solutions/enterprise/v1/io-cloud/caas/available-replicas?hardware_id={hardawer_id}&hardware_qty={hardware_qty} /\n -H \"X-API-KEY: \\$IOCLOUD_API_KEY\" \n\nThis request should return a response as follows:\n{\n \"data\": [\n {\n \"id\": 0,\n \"iso2\": \"string\",\n \"name\": \"string\",\n \"available_replicas\": 0\n }\n ]\n}\nWas this page helpful?","tokens":691,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791263024913,"hash":"4c3074a21b855234a8cb46e6ea661ef151ca7633"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBunYXq3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBvWwSO3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJSL2hjL2VuLWdiL2FydGljbGVzLzE5NDc5NzI5OTA3NDgzLUhvdy1jYW4tSS1hZGQtQXJiaXRydW0tbmV0d29yay10by1teS13YWxsZXQGOwhUOglyYW5raQg%3D--3ebbc1ea4dc7cee58189b5578c607d883828ff06","domain":"support.arbitrum.io","title":"How can I add Arbitrum network to my wallet? – Arbitrum Foundation","text":"Either you can manually add it using the following details:\n\nNetwork name: Arbitrum One\nNew RPC URL: https://arb1.arbitrum.io/rpc\nChain ID: 42161\nCurrency symbol: ETH\nBlock Explorer URL: https://arbiscan.io/\n\nOr just simply:\n\nGo to ChainList and connect your MetaMask Wallet.\nLook for 'Arbitrum One' in the search bar at the top of the page.\nTap 'Add to MetaMask' and the verified RPC information will be automatically added to your extension.\n\n Recently viewed articlesWhy are there 2 different USDC's on Arbitrum?Why do I need ETH to use the Arbitrum network?Bridging over a new tokenUsing Arbitrum's traditional bridge to move funds to MainnetSkipping the bridge\n\n Related articles\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?\n\n Please sign in to leave a comment.","tokens":254,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263027598,"hash":"ae5716392b2ed90eb299dc088d47c643ba43727f"}
{"url":"https://support.arbitrum.io/hc/en-gb/profiles/18072215697051-Ricardo-Gordon","domain":"support.arbitrum.io","title":"User profile for Ricardo__Gordon – Arbitrum Foundation","text":"First of all, make sure you have the Arbitrum network added to your wallet and that you're on the correct network.\nMore details here: https://support.arbitrum.io/hc/en-gb/articles/19479729907483-Ho...\n\n Ricardo__Gordon\n\n 3 years ago\n\n 6 followers\n\n 0 comments\n\n -1 votes\n\n Either you can manually add it using the following details:\n\nNetwork name: Arbitrum One\nNew RPC URL: https://arb1.arbitrum.io/rpc\nChain ID: 42161\nCurrency symbol: ETH\nBlock Explorer URL: https://ar...\n\n Ricardo__Gordon\n\n 3 years ago\n\n 6 followers\n\n 0 comments\n\n 2 votes\n\n For official collaborations, you can send an email to partnerships@offchainlabs.com.\n\n Ricardo__Gordon\n\n 3 years ago\n\n 3 followers\n\n 0 comments\n\n 0 votes\n\n Understanding native vs. bridged\nNative USDC is officially issued by Circle and always redeemable 1:1 for US dollars.\nIn the case of Arbitrum, there also exists a “bridged” form of USDC, known as U...\n\n Ricardo__Gordon\n\n 3 years ago\n\n 1 follower\n\n 0 comments\n\n 0 votes\n\n Here's a full explanation of how voting and proposals work. Keep in mind that there are 2 types of proposals: 1 - Proposals are first submitted to the ArbitrumDAO governance forum for community dis...\n\n Ricardo__Gordon\n\n 3 years ago\n\n 1 follower\n\n 0 comments\n\n 0 votes\n\n Whenever there are bridge transactions into the Ethereum mainnet using the official Arbitrum bridge, there is a mandatory 7-day waiting period for withdrawals and this is due to the bridge's securi...\n\n Ricardo__Gordon\n\n 3 years ago\n\n Updated\n\n 3 followers\n\n 0 comments\n\n 1 vote\n\n Please be advised that your tokens may have been sent to the Arbitrum contract address because of 1 of 2 cases, and in both, there is nothing that we can do here until the DAO proposal is reviewed ...\n\n Ricardo__Gordon\n\n 3 years ago\n\n Updated\n\n 3 followers\n\n 0 comments\n\n 1 vote\n\n Most wallets are \"connected\" to one given network at a time. To view your Ether / Token balances, ensure that you are connected to the appropriate Arbitrum chain. In MetaMask, you can switch networ...\n\n Ricardo__Gordon\n\n 3 years ago\n\n 5 followers\n\n 0 comments\n\n -2 votes\n\n When moving funds (ETH and non-ETH) from Ethereum (L1) to Arbitrum (L2), you'll need to have ETH in your wallet on the corresponding Arbitrum chain. This is because ETH is the currency used for gas...\n\n Ricardo__Gordon\n\n 3 years ago\n\n Updated\n\n 3 followers\n\n 0 comments\n\n 1 vote","tokens":589,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263038822,"hash":"171cf4b7ab6d3186f744144f996a9122233a30b7"}
{"url":"https://specs.optimism.io/protocol/fjord/predeploys.html","domain":"specs.optimism.io","title":"Predeploys - OP Stack Specification","text":"Predeploys\n\nTable of Contents\n\nGasPriceOracle\n\nL1 Gas Usage Estimation\n\nGasPriceOracle\nFollowing the Fjord upgrade, three additional values used for L1 fee computation are:\n\ncostIntercept\ncostFastlzCoef\nminTransactionSize\n\nThese values are hard-coded constants in the GasPriceOracle contract. The\ncalculation follows the same formula outlined in the\nFjord L1-Cost fee changes (FastLZ estimator)\nsection.\nA new method is introduced: getL1FeeUpperBound(uint256). This method returns an upper bound for the L1 fee\nfor a given transaction size. It is provided for callers who wish to estimate L1 transaction costs in the\nwrite path, and is much more gas efficient than getL1Fee.\nThe upper limit overhead is assumed to be original/255+16, borrowed from LZ4. According to historical data, this\napproach can encompass more than 99.99% of transactions.\nThis is implemented as follows:\nfunction getL1FeeUpperBound(uint256 unsignedTxSize) external view returns (uint256) {\n // Add 68 to account for unsigned tx\n uint256 txSize = unsignedTxSize + 68;\n // txSize / 255 + 16 is the practical fastlz upper-bound covers 99.99% txs.\n uint256 flzUpperBound = txSize + txSize / 255 + 16;\n\n int256 estimatedSize = costIntercept + costFastlzCoef * flzUpperBound;\n if (estimatedSize < minTransactionSize) {\n estimatedSize = minTransactionSize;\n }\n\n uint256 l1FeeScaled = baseFeeScalar() * l1BaseFee() * 16 + blobBaseFeeScalar() * blobBaseFee();\n return uint256(estimatedSize) * l1FeeScaled / (10 ** (DECIMALS * 2));\n}\n\nL1 Gas Usage Estimation\nThe getL1GasUsed method is updated to take into account the improved compression estimation\naccuracy as part of the Fjord upgrade.\nfunction getL1GasUsed(bytes memory _data) public view returns (uint256) {\n if (isFjord) {\n // Add 68 to the size to account for the unsigned tx\n int256 flzSize = LibZip.flzCompress(_data).length + 68;\n\n int256 estimatedSize = costIntercept + costFastlzCoef * flzSize;\n if (estimatedSize < minTransactionSize) {\n estimatedSize = minTransactionSize;\n }\n\n // Assume the compressed data is mostly non-zero, and would pay 16 gas per calldata byte\n return estimatedSize * 16;\n }\n // ...\n}\n\nThe getL1GasUsed method is deprecated as of Fjord because it does not capture that there are\ntwo kinds of gas being consumed due to the introduction of blobs. This function will revert when\ncalled in a future upgrade.\nUsers can continue to use the getL1Fee method to estimate the L1 fee for a given transaction, or the\nnew getL1FeeUpperBound method introduced by Fjord as a lower gas alternative.","tokens":633,"squid":"ink-governance","role":"Council Listener","at":1791263042458,"hash":"370ad2385d61130445de64db171bd8f8941d7618"}
{"url":"http://forum.soliditylang.org/c/language-design/9","domain":"forum.soliditylang.org","title":"Latest Language Design topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Language Design\n\n Language Design\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Language Design category\n\n This is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features. Here we can discuss the initial soundness …\n\n read more\n\n 0\n\n 596\n\n Feb 2021\n\n Eager require evaluation is unexpected\n\n 2\n\n 93\n\n Aug 4\n\n Solidity Needs Consistent Semantics\n\n 5\n\n 360\n\n Jun 22\n\n Core Solidity: Feedback from porting Uniswap v2\n\n 2\n\n 191\n\n Jun 9\n\n Ora: comptime-first, solver-in-workflow EVM language\n\n 3\n\n 181\n\n Feb 28\n\n The assembly/solidity distinction was a mistake, don’t repeat in Solidity Core!\n\n 5\n\n 378\n\n Feb 26\n\n Can a Solidity library be instantiated using new?\n\n 1\n\n 112\n\n Oct 2025\n\n Can be Optimized Linked Library Address Bytecode Fragment \n\n 0\n\n 107\n\n Jun 2025\n\n Why are some IDs and referenced declarations negative numbers in AST?\n\n 1\n\n 137\n\n Mar 2025\n\n Variations of integer divisions\n\n 0\n\n 164\n\n Jan 2025\n\n Utilize scratch space for hashing one ore two value types\n\n 3\n\n 506\n\n Sep 2024\n\n Type C is V .The type C not a pure alias .Why is it designed this way?\n\n 1\n\n 208\n\n Sep 2024\n\n [call for feedback] The future of `try`/`catch` in Solidity\n\n 7\n\n 5.1k\n\n Sep 2024\n\n `inline` function modifier\n\n 1\n\n 296\n\n Sep 2024\n\n Implementation of `receive` unexpectedly impacts `fallback`\n\n 2\n\n 151\n\n Sep 2024\n\n How to capture the revert from the calle contract?\n\n 4\n\n 600\n\n Aug 2024\n\n Discussion thread: High-level language support for transient storage - Caveats & next Steps\n\n 0\n\n 462\n\n May 2024\n\n Optional data locations with compiler optimization\n\n 0\n\n 314\n\n May 2024\n\n Variable length params for functions\n\n 0\n\n 311\n\n Apr 2024\n\n Transient storage high-level language support\n\n 1\n\n 485\n\n Apr 2024\n\n Language feature: Binary Literals/Strings/Numbers\n\n 1\n\n 452\n\n Apr 2024\n\n Try-Catch support uniform tuple syntax\n\n 1\n\n 499\n\n Feb 2024\n\n TLOAD TSTORE opcodes implementation\n\n 2\n\n 780\n\n Feb 2024\n\n Why evm sload with uninitialized data return zero value, not error?\n\n 9\n\n 589\n\n Feb 2024\n\n Proposal to enumerate selectors on the Contract type\n\n 0\n\n 285\n\n Jan 2024\n\n Missing implicit type conversions\n\n 3\n\n 1.2k\n\n Jan 2024\n\n Allow constants of any value type\n\n 1\n\n 657\n\n Jan 2024\n\n Named arguments on inherited contracts\n\n 1\n\n 486\n\n Dec 2023\n\n Language feature: Add support for binary literals\n\n 0\n\n 2.3k\n\n Dec 2023\n\n Add the ability to make dynamic arrays in memory\n\n 14\n\n 7.2k\n\n Oct 2023","tokens":1486,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263132963,"hash":"d3282302fc0ac07292188412c5132aa89af64efe"}
{"url":"https://ethresear.ch/t/payload-chunking/23008/8","domain":"ethresear.ch","title":"Payload Chunking - Sharding - Ethereum Research","text":"Sharding\n\n stateless,data-availability,chunking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n read \n\n 10\n min\n\n Sep 2025\n\n 8 / 9\n\n Sep 2025\n\n Sep 2025\n\n post by Nero_eth on Sep 1, 2025\n\n Nero_eth\n\n Payload Chunking\ntl;dr: Split an EL block (=payload) into multiple mini‑blocks (“chunks”) of fixed gas budget (e.g. 2**24 = 16.77M) that propagate independently as side cars. Each chunk carries the pre‑state it needs to execute statelessly and commits to its post‑state diff. Chunks are ordered but can be executed fully independently in parallel. CL commits to the set of chunk headers; sidecars carry bodies and inclusion proofs.\nValidation becomes more of a continuous stream.\nMotivation\nToday, blocks are large, monolithic objects that will become even larger in the future. Validation requires receiving the full block before execution can begin. This creates latency bottlenecks in block propagation and execution.\nAfter the block is received over the p2p network, transactions are executed sequentially. We cannot start validating while downloading or parallelize execution.\nTimeline showing today’s block validation bottleneck: full block download first, then sequential execution1100×580 29.3 KB\n\nMessages on the p2p layer are usually compressed using Snappy. The block-format of Snappy that is used on Ethereum cannot be streamed. Thus, we need to slice the block into chunks before compression.\n\nWith EIP-7928: Block-level Access Lists, the situation improves, but we’re still waiting for the download to finish before starting block validation. With 4 cores, we get the following Gantt chart:\nTimeline under EIP-7928: execution can use access lists but still must wait for block download1101×580 33.3 KB\nInstead, we can stream blocks as chunks:\n\nEach chunk contains ≤ 2**24 gas of transactions.\n\nOne could also have the chunk size increase geometrically (2**22, 2**23, …, 2**25) in gas. This would give us varying latencies for chunks, enabling better parallelization - but I’m not sure it’d be worth the complexity.\n\nTransactions remain ordered. Chunks are indexed and ordered, but independent of each other, so they can be validated in parallel. Still, the post-state of chunk 0 is the pre-state of chunk 1.\n(optional) Each chunk carries the state it needs to be executed statelessly.\n\nTimeline with payload chunking: chunks stream in and execute in parallel while downloading continues.1101×580 37.7 KB\nThis shifts validation from “download full block, then process” → “process while receiving the rest.”\n\nExecution Layer Changes\nWe extend the EL block format to support chunking:\nclass ELHeader:\n parent_hash: Hash32\n fee_recipient: Address\n block_number: uint64\n gas_limit: uint64\n timestamp: uint64\n extra_data: ByteList[MAX_EXTRA_DATA_BYTES]\n prev_randao: Bytes32\n base_fee_per_gas: uint256\n parent_beacon_block_root: Root\n blob_gas_used: uint64\n excess_blob_gas: uint64\n transactions_root: Root\n state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: Uint\n withdrawals_root: Root\n block_access_list_hash: Bytes32\n # New fields\n chunk_count: int # >= 0\n\nThere is no commitment to the individual chunks in the EL header. We only add the chunk count to it. The execution outputs (state_root, logs_bloom, receipts_root, gas_used) must be either the same as the value in the last chunk (applies to state root and withdrawals root), or the root after aggregating the chunk’s values (applies to transactions, receipts, logs, gas used, and the block access list).\nExecution Chunks\nChunks are never put on-chain; only their roots are committed.\nChunks contain the fields we would usually expect in the EL block body. Transactions are split up over chunks with a limit of 2**24 gas per chunk. Withdrawals must only be included in the last chunk. Mirroring block-level access lists, chunks come with their own chunk access list, and one could additionally add pre-state values to chunks, unlocking statelessness.\nclass Chunk:\n header: ChunkHeader\n transactions: List[Tx]\n withdrawals: List[Withdrawal] # only in chunk at index -1\n chunk_access_list: List[ChunkAccessList]\n pre_state_values: List[(Key, Value)] # optional\n\nEach chunk comes with a header including the chunk index. Transactions are ordered by chunk.header.index and their index in the chunk. Commitments to each chunk’s execution output are included in the header.\nclass ChunkHeader:\n index: int\n txs_root: Root\n post_state_root: Root\n receipts_root: Root\n logs_bloom: Bloom\n gas_used: uint64\n withdrawals_root: Root\n chunk_access_list_root: Root\n pre_state_values_root: Root # optional\n\nTo prevent proposers splitting their blocks into too many chunks, the protocol can enforce that chunks must be at least half full (\\geq\\frac{chunk\\_gas\\_limit}{2}≥𝑐ℎ𝑢𝑛𝑘_𝑔𝑎𝑠_𝑙𝑖𝑚𝑖𝑡2) OR chunk.header.index == len(beaconBlock.chunk_roots) (= last chunk in that block).\n\nConsensus Layer Changes\nDiagram of consensus changes: beacon block tracks chunk roots while execution chunks propagate via sidecars.1180×593 91.5 KB\nBeacon blocks track chunks with new fields:\nclass BeaconBlockBody:\n ...\n chunk_roots: List[ChunkRoot, MAX_CHUNKS_PER_BLOCK] # SSZ roots of chunks\n\nclass ExecutionPayloadHeader:\n ...\n chunk_count: int\n\nThe CL receives the execution chunks from the EL via a new ChunkBundle container which includes the EL header and the chunks (=similar to blobs).\nThe CL computes chunk roots using SSZ’s hash_tree_root and puts them into the beacon block body.\nSidecar Design\nChunks are carried in sidecars:\nclass ExecutionChunkSidecar:\n index: uint64 # chunk index\n chunk: ByteList[MAX_CHUNK_SIZE] # Opaque chunk data\n signed_block_header: SignedBeaconBlockHeader\n chunk_root_inclusion_proof: Vector[Bytes32, PROOF_DEPTH]\n\nThe consensus layer ensures all chunks are available and properly linked to the beacon block body via Merkle proofs against chunk_roots (=similar to blobs).\nNetworking\nThe proposer gossips only the lightweight beacon block with commitments (chunk_count, chunk_headers_root) on the normal beacon_block topic, while the heavy execution data is streamed separately as ExecutionChunkSidecars across X parallel subnets (beacon_chunk_sidecar_{0..X}), deduped by (block_root, index).\nInitially, all nodes must subscribe to all subnets and custody all chunks. While this doesn’t reduce bandwidth/storage requirements yet, it enables the immediate benefits of parallelization. Partial custody can be added in a future upgrade once the basic mechanism is proven and/or zk-proving becomes viable.\nNetworking view: lightweight beacon block propagates fast, while heavy execution chunks are streamed across parallel subnets.1090×430 260 KB\nFork Choice\nFork choice requires that all sidecars are both available and successfully validated before a block is considered valid. The beacon block with the chunk_roots propagates quickly, but the block only becomes fork-choice eligible once every chunk has been received and inclusion-proven against the root. The beacon block still contains the EL header with all the necessary commitments (=committing to parent block and execution outputs). What we knew as block body on the EL stays empty in this design.\n\nBenefits\n\nStreaming validation: execution can start while other parts of the block are still downloading or busy loading from disk. Chunks are independent (if pre-state provided), or rely on the chunk-access list (with chunk-level state diffs) and the pre-block-state; multiple CPUs/cores can validate chunks simultaneously; distribute bandwidth usage over slot instead of beginning-of-slot bursts.\nStreamlined proving: ZK Provers can parallelize proving multiple chunks at the same time, benefiting from the independence of chunks.\nStateless friendliness: since a single chunk is smaller than a block, we might consider adding pre-state values such that there is no need for local state access. A practical middle ground is to include pre-state values only in chunk 0, guaranteeing that at least one chunk can always be executed while the node loads the state required for other chunks from disk into cache.\nFuture extensibility: clear path to integrate zk-proofs over chunks or going for sharded execution.\n\nDesign Space\nChunk Size\n2**24 gas (~16.7M) emerged as a natural chunk size:\n\nMax Transaction Size: As of Fusaka (EIP-7825), 2**24 is the max possible transaction size.\nCurrent blocks: 45M gas blocks naturally split into ~3 chunks, providing immediate parallelism\nFuture blocks: Scales well - 100M gas blocks would have ~6 chunks\n\nValidator\n\nExecution engine splits the block into chunks internally (opaque to CL) and passes them to the CL through an ExecutionChunkBundle.\nProposer wraps each chunk in a sidecar with inclusion proof. The proposer also computes the hash tree root of each chunk and puts them into the beacon block body.\nPublishing happens in parallel across all subnets\nAttesters wait for all chunks and validate them before voting\n\nBuilders\nProposers can publish chunks as they’re finished building, and validators can start validating them even before receiving the beacon block. Since chunks contain the signed beacon block header and an inclusion proof against it, one can validate (=execute) chunks as they come in, trusting their source (=proposer).\nOpen Questions & Future Work\nProgressive Chunk Sizes?\nThe idea of geometrically increasing chunk sizes (2**22, 2**23, …, 2**25) seems beneficial but adds complexity. The first chunk could be smaller (5M gas) with pre-state values for immediate execution, while later chunks are larger. This remains an area for experimentation.\nPartial Custody Path\nWhile the initial implementation requires full custody, the architecture naturally supports partial custody:\n\nNodes could custody only Y subnets out of X\nReconstruction mechanisms (similar to DAS) could recover missing chunks\n\nCompatible with ePBS and Delayed Execution\nAt first glance, the proposed design seems compatible with both EIP-7732 and EIP-7886. Under ePBS, the chunk roots would likely move into the ExecutionPayloadEnvelope, and we’d put an additional root over the chunk roots into the ExecutionPayloadHeader. The PTC would not only have to check that a single EL payload is available, but that all chunks are. This is not much different from blobs.\nThe advantages of block chunking and independent validation scale with higher gas limits and may contribute to reducing spikiness in node bandwidth consumption.\n\n Toward Semantic Block Chunking\n\n BALs for Proposer Commitments\n\n Integrated in-protocol distributed history and state storage\n\n Blocks Are Dead. Long Live Blobs\n\n 5\n\n read \n\n 10\n min\n\n post by daniellehrner on Sep 1, 2025\n\n daniellehrner\n\n I really like this proposal.\nI think there could be further changes that not only allow streaming during execution, but during block building as well:\nToday the whole network, except for the block builder, stands still until the builder has constructed the full block and has calculated the state root hash. This is true even with this proposal.\nIt might be possible to allow the builder to stream the transactions before the full block is constructed. The builder could construct a header that only contains a subset of the fields today which are known before building the block:\n\nPREVRANDAO\nBLOCKNUMBER\nTIMESTAMP\netc\n\nAfter that it could start to add the transactions and send them to its peers once that a chunk is full. This would decrease the time to first byte, because the builder could send chunks before the full block is ready.\nOnce the block is fully built the builder could send a footer which contains the missing fields like:\n\nBLOCKHASH\nSTATEROOT\nRECEIPTSROOT\netc.\n\nI think there are mainly 2 downsides:\n\nBALs don’t work anymore in their current form. We could convert them into chunk level access lists, but most probably increase bandwidth requirements\nBlock validation is split into two steps: validating the fields in the header → execute transactions-> validate fields in the footer. But payload chunking in its current form requires that the block hash in only validated after all the chunks have been received.\n\n post by Nero_eth on Sep 2, 2025\n\n Nero_eth\n\n Yeah, this is interesting!\nI don’t think moving from block-access lists to chunk-access lists would be a major issue. The objects themselves get smaller, we gain parallelization, and there’s even room to increase the size of individual objects (for example, supporting statelessness).\nIn the block chunking proposal, the idea is similar: chunks can be published earlier than the EL header. Each chunk can be validated independently, and once they’re all validated, only the aggregate execution outputs need to be checked. At that stage, the EL header is required, but not before, since it only contains the chunk count and no other chunk-specific information.\n\n post by raulk on Sep 8, 2025\n\n raulk\n\n Promising proposal! I support the general direction, and I think we should let the builder side stream too. That keeps progress steady and incremental across the slot and reduces peak system requirements on builders (especially important for local builders as we increase gas limits and shorten slot times).\nMore concretely, this is what I’m thinking.\nMake streaming first class. I’d avoid committing to the total chunk count upfront, or to specific chunk contents. Let builders emit a chunk as soon it hits a gas budget, up to the relevant protocol caps (block gas limit, max chunks). Use either a closing trailer, or a per-chunk “last” marker. I lean towards the trailer: it keeps final commitments tidy and encapsulated. Header and trailer are small, so we can broadcast them more aggresively (e.g. higher fanout).\nBuilder pipeline. Parallelize chunk production by saturating all available CPU cores. Run one EVM per core with shared conflict detection; pin instances to OS threads if useful. Route transactions based on tx-level access list. Use speculative execution, potentially with copy-on-write snapshots to migrate a conflicting inflight transaction to another chunk on conflict (e.g. OverlayFS style). Keep shipping chunks as they’re ready. Do not wait for the full set. When the block gas limit is hit, merge pending EVMs, finalize outputs, and dispatch the final chunks. There’s probably work from the Parallel EVM world that becomes very relevant here.\nValidator pipeline. Execute chunks as they arrive. One EVM per chunk, with shared conflict detection to reject the block on conflict (or validation against chunk-level access lists, or prestate, as you mentioned). This matches the original proposal.\nCommitments. Treat some execution payload fields as placeholders that the trailer fills in; namely those dependent on the post-state: transactions_root, state_root, receipts_root, logs, etc. Put chunk commitments and chunk count in the trailer, together with the final proposer signature. Because the block continues being atomic, the chain can be spared of chunking details. I’d think of the chunked form as virtual during transit, which is then collapsed into a single committable block when appending to the ledger. If useful, we can persist chunk boundaries and metadata off-chain for P2P RPC and checkpoint sync, but not necessarily in the canonical structure.\nNetworking. Independent chunking is a win if overhead stays low. It allows parallel propagation across subnets and smoother bandwidth profiles across the slot.\nChunk authentication without a fixed count. All chunks are signed by the proposer. Proposer equivocation rules probably need to adapt. To strengthen the model, we can carry a running accumulator in each chunk header, and have the trailer commit to the final accumulator. Validators receiving chunks out of order can still validate taking the risk with some configured tolerance.\nMental model. This looks like MapReduce at the EVM level. Builders map transactions into independent execution units under conflict detection. Validators reduce by merging verified, non-conflicting results in order.\n\n post by preda-devteam on Sep 9, 2025\n\n preda-devteam\n\n This is inspiring and enlightening \nStreamlining block reception and execution would be a smart move now that BALs are paving the way for many improvements.\nAdditionally, I’d like to delve into the specifics of parallel execution and the adoption of a Parallel EVM that partitions data/state architecture—something I’ve been working on. I have two questions regarding your proposal:\n\nValidator/Parallel Execution\nWith BALs, we’ve set the stage for parallel execution—essentially a pessimistic approach to parallelization. Is this the kind of parallel execution you’re envisioning?\n\nOnce a block chunk is received by a validator, BALs provide insight into the read/write list, allowing conflict-free transactions to be executed in parallel across the validator’s multiple cores. This mechanism is similar to the pessimistic-parallel execution employed by other chains. With BALs in place, there’s significant potential to maximize parallelism and reduce state conflicts.\n\nNetworking/Partitioning Possibilities\nYou mentioned the future possibility of “partial custody,” where subnet nodes would only manage a fraction of the data. This got me thinking about the broader direction of partitioning across communication, storage, and execution. Do you see Ethereum’s future leaning more towards full sharding (partitioning across all three dimensions) or partial sharding (partitioning across one or a subset)?\n\nA key advantage of partitioning would be overcoming the limitations of computational power in a single VM, the real opportunity here is to leverage the total processing power of the entire network. This would allow Ethereum’s performance to scale as the number of nodes increases.\n\n post by Nero_eth on Sep 9, 2025\n\n Nero_eth\n\n Great comments, thanks!\n\nYeah, totally agree and I’d say this is already supported with the chunking approach. For DoS resistance, validators need a way to verify a chunk is signed by the rightful proposer of that slot, and this is possible with the sidecars containing the signed_block_header. Even though one cannot yet validate the inclusion proof, validators could still already start executing, delaying the inclusion proof until the beacon block is received.\nMy feeling is that this might be good enough and we would not need a commitment to the chunks different from the proposer’s signature to start processing. The beacon block essentially becomes the trailer\n\n post by Nero_eth on Sep 9, 2025\n\n Nero_eth\n\nYou get perfect parallelization. No need to separate tx into non-conflicting batches. With EIP-7928, every transaction can be executed independently of another.\n\nWhile I agree that this is an interesting concept, it feels like we’re still kinda far from such a world. DAS, as done with blobs is a great role model for what we should strive for on the EL as well. zkVMs will further change how we think about related concepts, so, still rather difficult to tell how things evolve. Execution sharding has huge potential for scaling and is definitely on the list.\n\n 10 days later\n\n post by gballet on Sep 19, 2025\n\n gballet\n\n That has potential, but I do see a lot of issues as well.\nThe Bad\n\nThe obvious one is complexity: Chunks need to travel over the network and be executed in due time. Under normal conditions, I think it’s to be expected that the validators will execute these Chunk optimistically and wait for the next, but if for whatever reason the chunks are not being distributed, the rational thing to do will be to wait for all the chunks to be downloaded anyway so that they can be executed in parallel. And if that is the case, then why not simply give a single block and add the same information to allow for chunk execution in parallel without having to distribute the data over the network and gope that the recipient will collect all the pieces in time?\nIt is much faster to download a big chunk of data than many many small bits and pieces. To be seriously considered, this proposal should effectively make some measurements as to how much time is saved executing in parallel, and in what kind of load. I don’t believe it’s unrealistic to expect that the execution will be spending most of its time waiting on the data to end up downloading, then immediately execute the chunk and wait for the next one. In particular, it should be explained why this is a better approach than simply packaging the transactions in such a way that you could start executing as the data is being downloaded.\nThis is yet another proposal that increases the bandwidth requirements and also puts a lot of work on the proposer to hash the work for the validators.\nI do not think it will help the ZKVM approach at all, in the sense that proving is very slow and so you will lose all the benefits of parallel proving. I understand that the end goal would be to have carious entities on the network working on a single chunk at a time and sharing them over the network, with the execution being proven in parallel by the validator without even needing to download the chunks. But there is the problem of whom commits to building these proofs? The builder itself will not be able to provide any commitments that these proofs are correct.\nIn the case when most txs depend on each other, e.g. sandwiching blocks, your chunks are going to be very small.\nI might be missing something on the CL side, but it seems to me that this is very susceptible to Spamming because one could simply spam a lot of chunks even if they are not part of the block. How is the executor supposed to know the connection between the chunks and the block, if no commitment is made? The sidecar would require some hefty proving, which a simple hash could do instead.\n\nSo in summary, I think proper research should be conducted in order to find out if this is really worth the complexity.\nThe good\nI think most of the potential comes from the idea that blocks could actually be produced by many builders at the same time, and this is a good first step for this to happen. In a way you could represent this as inclusion list being just actual execution instead of a list of instructions, and if for whatever reason they are not executable, then they are still part of the block, but they are not canon.\nSo in my view as such it doesn’t bring very much, but if we could somehow make it also a way to share building between many clients and many nodes, then this would have really the potential to make a dent in terms of scalability.\nQuestion\n\nWhy are withdrawals included in a chunk? They could still be part of the block and be optimistically executed in parallel instead of waiting for the last chunk, I doubt there will be people trying to use their withdrawal address in the same block as the withdrawal, and if this happens, it can be easily worked around.\n\n post by Nero_eth on Sep 19, 2025\n\n Nero_eth\n\n Thanks for the questions and feedback!\n\nThis is what Block-Level Access Lists already give you, in combination with EIP-7825 (the tx gas limit of 16.77M). Each transaction is executable fully independently from another, thus, if you wait for all chunks to be downloaded just to then start executing chunks in parallel, then you arrive at where we’re at with BALs. The only way to improve on this would be by enabling validators to start executing earlier, even before everything is received.\n\nYeah agree, measurements are needed. In any case, this would speed up the “time to validation” for validators, independently if builder make use of the smaller chunks and actually publish them earlier, or if they wait until the last second. Since the absolute size of the object you need to download is smaller (much smaller if you compare 16.77M (=chunk size) to 60M or 100M (=future block gas limit)). The smaller object will propagate faster, shortening the time from beginning of propagation to beginning of validation.\n\nTrue but only marginally (a few 32 bytes values that were in the block header are now in all chunk headers; maybe a few hundred bytes overhead) but in return we have a less spiky bandwidth usage over the slot. Also, I keep hearing that our gossip network was never created with the intent of sending around large messages ( cc @raulk, @MarcoPolo), and with increasing gas limits, we have no other option on the table to somehow limit message sizes.\nIf we have chunks being statelessly validatable, we’d ensure that they are executable independently from the order in which you receive them. This would add a lot of data on top, I agree but maybe, if we don’t make them stateless (like mentioned in the post) but instead require validators to have full state, then we still get the benefits of being able to independently download but then you can only execute the second chunk if you already have the first (using it’s chunk-level access list).\nAnother alternative would be to have the chunk access list travel as a sidecar too, exclusively providing state updates to validators, whereas the chunks with the actual data travels independently.\n\nMore like, have various entities work on different chunks, but since this proposal doesn’t affect builder or prover economics, we might just not care to much about it at this point. Validators would still need to download all chunks.\n\nNote that transactions distributed over chunks still enjoy the same atomicity as if they were in the same block. We could enforce that chunks must always be at least 1/2 full (measured in gas used), otherwise invalid. Thus, you can do a sandwich starting in chunk 0 and finishing in chunk 1. The post state root of the last tx in chunk 0 is the pre state root of the first transaction in chunk 1.\nThe proposal doesn’t really focus on builders and provers but on validators and how we could relief them from work in the critical path.\nLet’s assume there are no provers yet (which is true today) and builders play timing games until the last possible second. Even then, validators would profit by being able to parallelize between validating the first chunk while downloading the rest. Builders can publish_ chunks earlier, just like provers can provide proves for chunks without seeing the full block, but this is a different topic.\nMy argument is that if we don’t chunk things in-protocol, then we may just increase the time of everything (upload, download, validation) linearly without having any way to parallelize between the 3.\n\nBlocks on the EL wouldn’t exist anymore, just chunks and a header. Today, withdrawals are applied after executing all transactions. We could enforce that only the last chunk is allowed to contain withdrawals and then process them just like today.\n\n Powered by Discourse","tokens":6665,"squid":"ink-research","role":"Deep Scholar","at":1791263136695,"hash":"706d908b243c494097be98f0985c8a9bcb3fd7d2"}
{"url":"http://forum.soliditylang.org/c/code-wizards/7","domain":"forum.soliditylang.org","title":"Latest Code Wizards topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Code Wizards\n\n Code Wizards\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Code Wizards category\n\n Share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it. \n Please be aware that this is not the …\n\n read more\n\n 0\n\n 612\n\n Feb 2021\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n 1\n\n 81\n\n Jun 22\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n 1\n\n 119\n\n Jun 9\n\n What Solidity try/catch actually catches\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n 1\n\n 121\n\n Apr 18\n\n Diamond Contract Gas Efficiency Challenge\n\n 0\n\n 108\n\n Oct 2025\n\n Storing validators public key in storage\n\n 0\n\n 115\n\n Jun 2025\n\n Dexrouter and factory value in an function\n\n 15\n\n 2.5k\n\n Dec 2024\n\n Are updatable function pointers possible?\n\n 4\n\n 480\n\n Mar 2024\n\n Need some help: Opcode with different compiler version\n\n 1\n\n 456\n\n Jul 2023\n\n How ensure a whole number deposit (Integer)\n\n 3\n\n 1.8k\n\n Apr 2023\n\n Hashing — get Signature\n\n 2\n\n 1.4k\n\n Apr 2023\n\n I live with this Error for two month -on https://remix.ethereum.org\n\n 9\n\n 1.3k\n\n Apr 2023\n\n Gas estimation on failed transactions - how to deal with it? [HARD]\n\n 0\n\n 464\n\n Mar 2023\n\n Does it make sense to deploy reusable library for rendering SVG, etc.?\n\n 7\n\n 721\n\n Mar 2023\n\n Some questions about the Solidity language\n\n 5\n\n 1.9k\n\n Mar 2023\n\n Lock transfer addresses\n\n 2\n\n 771\n\n Mar 2023\n\n Can someone list all situation the will generate a revert op code?\n\n 3\n\n 484\n\n Mar 2023\n\n Techniques for large amounts of on-chain computation\n\n 4\n\n 746\n\n Mar 2023\n\n Is it possible to decode data and make assignment to struct members and new variables in one step\n\n 5\n\n 1.8k\n\n Mar 2023\n\n Can anyone explain to me what the _method does?\n\n 5\n\n 1.5k\n\n Nov 2022\n\n Throwing error strings in Yul\n\n 1\n\n 735\n\n Nov 2022\n\n Burn in one contract and mint in other\n\n 1\n\n 1.3k\n\n Oct 2022\n\n Allocating bits from stored byte32 to different byte variables\n\n 1\n\n 605\n\n Oct 2022\n\n How to: reverse engineering\n\n 2\n\n 1.4k\n\n Oct 2022\n\n I wrote staking smart contract and I have “loop” concerns\n\n 5\n\n 1.1k\n\n Sep 2022\n\n Off-chain execution\n\n 0\n\n 512\n\n Aug 2022\n\n How to store a string/variable in a smart contract that is encoded and only the owner of that contract can call a function to decode it?\n\n 1\n\n 653\n\n Aug 2022\n\n Need some help with my code(Begginer)\n\n 1\n\n 506\n\n Aug 2022\n\n Public visibility or external visibility from an auditing perspective\n\n 5\n\n 964\n\n Jul 2022","tokens":1513,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263143189,"hash":"976a36bb2537a81e11aab812adba140800068116"}
{"url":"https://governance.aave.com/t/apu-mallku-delegate-platform-putting-aave-token-holders-first/24043/5","domain":"governance.aave.com","title":"Apu Mallku [Delegate platform]: Shutdown 🚩 - Delegate Platforms - Aave","text":"Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 7\n min\n\n Feb 11\n\n 5 / 7\n\n Mar 18\n\n Apr 12\n\n post by ApuMallku on Feb 11\n\n ApuMallku\n\n Hello Aave Community. I’m Apu Mallku (apumallku.eth). My journey with this protocol didn’t start yesterday; it began in late 2017, as an early participant in the EthLend ICO. I have been here since before Aave was even Aave.\n\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nDune: https://dune.com/apumallku/aave\n\nWhen the foundation of DeFi was being built in early 2020, I was there for the launch of Yearn Finance, taking my first steps in yield farming and eventually serving as Partnership Lead for prominent DeFi projects—initiatives that became the original “Blue Chips” of the DeFi Summer. My professional background in partnership growth has given me a front-row seat to how protocols scale, how they fail, and how they are often captured by misaligned interests.\nFor years, I have been a silent observer—watching from the sidelines, analyzing the shifts in governance power, and voting with my own conviction. But the current state of Aave has reached a tipping point where silence is no longer an option. Now is the time to act. Aave doesn’t need more “Governance-as-a-Service” corporate delegates. It needs fiercely independent, veteran voices who aren’t afraid to speak the truth. We are witnessing a slow drift toward corporate capture, where institutional delegates often remain silent on critical issues like conflict of interest or Service Provider (SP) monopolies.\nEncouraged by the support of independent voices and active contributors, I am formalizing my role as a Delegate. My goal is simple: I am here to ask the hard questions, protect the protocol from centralization, and return the focus to where it belongs—the utility and value of the AAVE token.\n Core Values & Ethos\nMy governance philosophy is deeply rooted in free-market dynamics and strict decentralization. My recent track record in the forum reflects this:\nAnti-Monopoly & True Decentralization: A DAO should foster competition, not monopolies. I stand against the consolidation of power by a few whale wallets or aggregate SPs. Aave must remain sufficiently decentralized, not just for ethical reasons, but to mitigate existential regulatory risks (e.g., SEC scrutiny).\nMeritocracy & Accountability: Funding should be based on performance, not legacy status. I advocate for clear KPIs, Conflict of Interest (COI) frameworks, and bounty-based models to ensure every AAVE/GHO spent by the Treasury delivers undeniable value.\nIP Sovereignty & Open Innovation: Aave must be an ecosystem that empowers third-party builders, not one that leaves them behind due to legal or branding bottlenecks created by centralized off-chain entities.\nIndependent Over Institutional: I do not run a governance factory, and I am not looking to appease any corporate partners. I represent the raw, free-market ethos of DeFi. I will always favor transparency over political correctness. If a proposal is bad for the DAO but good for an insider group, I will publicly call it out.\n Key Priorities\nIf you delegate your voting power to me, these are the pillars I will aggressively pursue:\nMaximize AAVE Token Power & Utility: The AAVE token must be the ultimate beneficiary of the protocol’s success. I will support and champion initiatives that drive value accrual to the token, enhance its utility within the ecosystem (like GHO dynamics), and ensure that holders are rewarded for their risk.\nRuthless Treasury Stewardship: The DAO’s treasury is not an ATM for Service Providers. I will scrutinize budget renewals, demand transparency, push for mandatory disclosures, and vote strictly against any proposal where a clear conflict of interest compromises the DAO’s financial health.\nAggressive Ecosystem Growth: I will enthusiastically support all growth initiatives that scale Aave’s dominance safely—such as listing new resilient assets, deploying on promising L2s, and expanding GHO adoption—provided they adhere to strict risk management standards.\n Disclosures & Conflict of Interest\nIn the spirit of the transparency I demand from others:\nI am an independent DeFi participant. I am not currently employed by, nor do I receive a salary from, any Aave Service Provider.\nI hold positions in AAVE, ETH and SKY but Aave remains my primary governance focus.\n How to Delegate\nIf you share this vision of a decentralized, free-market-driven, and highly efficient Aave, I invite you to delegate your AAVE / stkAAVE to my address. It is time to make our voices heard and protect the protocol we all helped build.\nENS: apumallku.eth\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nLet’s build a stronger, truly decentralized Aave.\n\n How AAVE will win\n\n [TEMP CHECK] The AAVE Utility Renaissance: Aligning Protocol Success with Token Holder Value\n\n read \n\n 7\n min\n\n 14 days later\n\n post by ApuMallku on Feb 25\n\n ApuMallku\n\n Date Voted: February 25, 2026\n\n SNAPSHOT\n1. Proposal: [TEMP CHECK] Aave Will Win Framework\n\nVote: NAY\n\nRationale: This vote was rushed and it shows. I welcome Labs opening a dialogue — but that’s all this is: a dialogue starter, not a finished product. The most relevant service provider in the entire ecosystem has failed to answer a single sensitive question raised by the community before pushing this to Snapshot. That is unacceptable. A proposal with this name carries enormous expectations. At minimum, it should have contained concrete proposals around AAVE token utility and explicit, tangible benefits for token holders. Instead, we got silence on the hard questions and a Snapshot vote. Ghosting the community while forcing a governance pulse is not leadership — it’s pressure. Not good enough.\n\n2. Proposal: [ARFC] Aave v3.7 Candidate\n\nVote: YAE\n\nRationale: BGD Labs has consistently delivered. This proposal is technically sound, well-structured, and follows the proper governance process. Aave v3.7 is the right next step for the protocol’s technical evolution. I support moving forward.\n\n ON-CHAIN\n3. Proposal: Focussing the Aave V3 Multichain Strategy – Phase 1\n\nVote: YAE\n\nRationale: Freezing low-activity V3 markets is a prudent and necessary risk management decision. ACI has presented a clear case, the proposal is well-scoped, and it aligns with the long-term health of the protocol. I vote in favor.\n\n4. Proposal: Create Allowance GHO Mantle\n\nVote: NAY (human error)\n\nRationale: My NAY vote here was a human error — I intended to vote YAE. TokenLogic’s proposal to create an aEthLidoGHO allowance for the Aave Liquidity Committee is sound and consistent with GHO’s liquidity strategy. I’m documenting this publicly because transparency is the standard I hold others to. I hold myself to the same standard.\n\n5. Proposal: February 2026 – Funding Update\n\nVote: YAE\n\nRationale: Transparent, well-structured, and straightforward. Maintaining the DAO’s runway and ensuring clear traceability of funds is non-negotiable for a healthy protocol. TokenLogic delivers consistently. I support this without reservations.\n\n post by ApuMallku on Mar 5\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\nENS: apumallku.eth\n\nYour support allows me to continue defending the interests of the community and ensuring Aave remains the premier liquidity protocol in DeFi.\n\n Voting Activity Report\n6. [Snapshot] [ARFC] Deploy Aave v3 on X Layer\nDecision: FOR\nRationale: We support the deployment on X Layer as part of Aave’s multichain expansion. By integrating with OKX’s ecosystem, Aave can tap into a significant source of retail liquidity and onboard a new demographic of users. This move strengthens the protocol’s position as the leading liquidity provider across all relevant EVM networks, driving more value to AAVE holders through diversified revenue streams.\n7. [Snapshot] [TEMP CHECK] Deploy Aave Protocol on Monad\nDecision: FOR\nRationale: Monad’s high-throughput architecture is one of the most anticipated technological leaps in the EVM space. Voting FOR ensures that Aave remains at the forefront of innovation. Being a first-mover on Monad allows the protocol to capture early TVL and establish itself as the foundational lending layer for a high-frequency DeFi ecosystem, which is essential for long-term growth.\n8. ACI is Leaving Aave\nDecision: YAE\nRationale: This is a historic and difficult vote for our platform. I am voting YAE, but I want to be clear: I never imagined having to vote for the decoupling of the Aave Chan Initiative (ACI) from the DAO.\n\nTransition over Disruption: While the departure of such a key contributor is a loss, we must prioritize the protocol’s operational continuity. This vote facilitates a structured 120-day wind-down, which is the most responsible path to prevent governance instability.\n\n post by ApuMallku on Mar 9\n\n ApuMallku\n\n 9. [Snapshot] [ARFC] Safety Module - Reduce Emissions\nDecision: NAY\nRationale: I have voted NAY on the proposal to reduce emissions for the Safety Module. While I understand the DAO’s goal of fiscal optimization, my stance is clear: Putting AAVE Token Holders First means not stripping away incentives before a superior alternative is functional.\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n 8 days later\n\n post by ApuMallku on Mar 17\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nI want to start by expressing my deepest gratitude to all the delegates who, week after week, entrust me with their voting power to represent them in the Aave DAO. Your support is the engine of this platform. To celebrate our growth and enhance transparency, I have created a Dune Dashboard where you can track the evolution and impact of the Apu Mallku platform in real-time: dune.com/apumallku/aave.\n\n Voting Activity Report\n10. [Snapshot] [TEMP CHECK] Aave V4 Bug Bounty Program on Sherlock\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: Security is the non-negotiable foundation of Aave. I voted FOR establishing this bug bounty program on Sherlock. As we prepare for the transition to V4, incentivizing top-tier white-hat hackers to stress-test the code is the most cost-effective insurance policy for the DAO. This directly protects AAVE holders from potential exploit risks during the next major protocol upgrade.\n11. [Snapshot] [ARFC] Buyback Program - Budget Adjustment\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: I support this budget adjustment for the Buyback Program. Optimizing the DAO’s treasury to strategically accumulate AAVE from the market aligns protocol revenue with token value. This mechanism creates a healthy feedback loop: as the protocol succeeds, the DAO increases its stake in its own future, reducing circulating supply and rewarding long-term holders.\n\nStrategic Execution: While I agree with the proposal, I believe the buyback should be optimized based on market conditions. If the token is undervalued, the DAO should execute larger orders.\nBeyond DCA: In my view, a simple DCA (Dollar Cost Averaging) strategy is not the correct approach and never has been; we need a more opportunistic execution model to maximize value for the treasury.\n\n12. [Snapshot] [TEMP CHECK] Aave V4 Licensing\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: Protecting Aave’s intellectual property is vital for maintaining our competitive advantage. I voted FOR the V4 licensing framework to ensure that while we remain open-source in spirit, the DAO retains control over how its innovations are commercialized by third parties. This prevents “vampire attacks” and ensures that the value created by Aave Labs and the DAO stays within the Aave ecosystem.\n\n On-chain Votes (Chronological Order)\n13. [On-chain] Activate Capo Risk Agent and expand Rates Agent\nDecision: YAE\nVoting Power: 1,206.42 AAVE\nRationale: I voted YAE to expand our automated risk management capabilities. Activating these agents allows for more dynamic, data-driven parameter adjustments across multiple networks, scaling safety without manual bottlenecks.\n14. [On-chain] Enhancing Market Granularity in Aave 3.6: part 2\nDecision: MISSED (Operational Error)\nVoting Power: N/A\nRationale: Regarding this vote, I unfortunately missed the execution window due to an operational error. I want to be fully transparent: I have already taken the necessary technical measures and updated my monitoring workflows to ensure this does not happen again. Reliability is my top priority.\n15. [On-chain] Gho X-Layer Activation\nDecision: YAE\nVoting Power: 6,993.74 AAVE\nRationale: Following our support for the X-Layer deployment, I voted YAE for the official activation of GHO on this network. This increases GHO’s utility within the OKX ecosystem and drives more interest income back to the DAO treasury.\n16. [On-chain] wstETH CAPO Oracle Incident User Reimbursement\nDecision: YAE\nVoting Power: 6,993.74 AAVE\nRationale: Accountability is key to maintaining trust. I voted YAE to reimburse users affected by the wstETH CAPO oracle incident. Ensuring that users are made whole after a technical failure is essential for Aave’s reputation as a premium, secure protocol.\n\nAdvocacy for Clarity: I was very vocal regarding this issue, actively seeking answers and trying to understand exactly what happened.\n\nBridging the Gap: Most forum posts were overly technical, leaving non-technical community members lost in jargon. In the future, I want to see better documentation regarding risk management workflows that is accessible to everyone.\n\nWorkflow Support: I fully support the initiative to incorporate LlamaRisk into these workflows to enhance our collective oversight.\n\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n 23 days later\n\n post by ApuMallku on Apr 10\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nYou can track the evolution and impact of the Apu Mallku platform in real-time: dune.com/apumallku/aave.\n Voting Activity Report\nSnapshot votes\n\nDate\nProposal\nDecision\nRationale\n\nMar 21\n[ARFC] Aave <> Chainlink SVR. Multi-network expansion\nFOR\nExpanding the Savings Rate across networks is a highly strategic move for capturing yield and improving composability. I support this expansion to maximize our multichain presence, provided we maintain our strict standards for cross-chain oracle security.\n\nMar 23\n[ARFC] Aave V4 Activation on Ethereum Mainnet\nFOR\nV4 is a vital architectural leap for Aave’s future. I voted FOR to fully support this technical upgrade, while maintaining my collaborative view that we must continue refining our governance frameworks to ensure token holders are fully aligned with this new phase.\n\nMar 27\n[ARFC] Bug Bounty Program on Sherlock\nFOR\nA robust security infrastructure is non-negotiable for a protocol of our size. I fully support leveraging competitive audit models to protect the ecosystem, ensuring that treasury funds are efficiently allocated to maximize technical resilience.\n\nMar 29\n[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance\nFOR\nExpanding stablecoin diversity on new high-performance instances like Sonic is a positive step for market capture. Supported with the recommendation that initial supply caps remain appropriately conservative during the network’s bootstrap phase.\n\nMar 29\n[ARFC] Aave V4 Licensing\nFOR\nProtecting Aave’s intellectual property is essential to ensure that the value created by the DAO and its contributors stays within the ecosystem. I voted FOR to establish a framework that defends our innovations while still fostering collaborative growth.\n\nAbr 03\n[ARFC] Update Signers and SAFE Configuration\nFOR\nRoutine housekeeping is necessary for smooth operations. Approved to maintain current decentralized threshold standards, while I look forward to encouraging continued rotation and separation of duties among service providers in the future.\n\nAbr 03\n[ARFC] sGHO Launch Configuration\nFOR\nThe deployment of sGHO is a strong, positive step for our stablecoin ecosystem. Supported with the recommendation that we closely monitor organic market demand to ensure sustainable yield growth alongside our treasury strategies.\n\nAbr 04\n[ARFC] Aave Will Win Framework\nFOR\nI support the vision and the alignment of branded product revenue directly to the treasury. I voted FOR to enable these structural improvements, and I look forward to working together with the community on further enhancing AAVE token utility prior to the AIP execution.\n\nAbr 05\n[ARFC] Onboard PT-USDG-28MAY2026\nFOR\nIntegrating fixed-rate primitives is an excellent way to safely expand our multichain footprint. Approved with the expectation that supply caps remain conservatively managed while the oracle infrastructure scales gracefully.\n\nAbr 06\n[ARFC] Continued Deprecation of V2 Markets\nFOR\nSunsetting legacy markets is an essential step for technical efficiency and optimal resource allocation toward V4. I fully support these deprecation steps to encourage a smooth and safe capital migration for all users.\n\n On-chain Votes (Chronological Order)\n\nDate\nProposal\nDecision\nRationale\n\nMar 24\nReduce Safety Module Emissions\nYAE\nOptimizing treasury emissions is key for our long-term sustainability. I support this reduction to ensure we remain capital-efficient while fairly rewarding participants who are aligned with protocol growth.\n\nMar 29\nAave V3.6 XLayer Activation\nYAE\nExpanding our ecosystem to XLayer is a strategic priority.\n\nMar 29\nEnable SVR on Base and Arbitrum\nYAE\nDeploying the Savings Rate to L2s significantly strengthens our cross-chain composability. Voted YAE to support this expansion, highlighting the need for robust and continuous oracle synchronization.\n\nMar 30\nOnboard BTC.b to Aave V3 Core\nYAE\nWhile there is clear market demand for Bitcoin exposure, we must carefully manage the technical nuances of bridged assets. Voted YAE, fully supporting the conservative supply caps and risk mitigation parameters.\n\nMar 30\nAave V4 Activation on Ethereum\nYAE\nThe Hub-and-Spoke model is a remarkable achievement in capital efficiency, and I voted YAE to activate it on-chain. While I maintain that the governance friction surrounding the ‘Aave Will Win’ framework should have been fully resolved prior to launching such a critical upgrade.\n\nApr 06\nListing PT Ethena 18JUN2026\nYAE\nPendle integrations offer excellent benefits for our users. Voted YAE, appreciating that the supply caps have been carefully calibrated by risk providers to safely match the asset’s specific liquidity profile.\n\nApr 07\nMarch Funding Update\nYAE\nEnsuring our contributors are funded is essential for uninterrupted protocol operations. Voted YAE, and I look forward to collaborating on transitioning toward more milestone-based reporting and streaming models moving forward.\n\nApr 07\nListing PT Strata 25JUN2026\nYAE\nAnother strong addition to our yield tokenization offerings. Voted YAE with confidence in the conservative borrowing power parameters that responsibly manage the underlying duration risk.\n\nApr 07\nUmbrella Deficit Updates\nYAE\nMaintaining a fully capitalized safety layer is paramount for depositor trust. Voted YAE to resolve these deficits promptly, emphasizing our shared commitment to continuous improvement in risk modeling.\n\nApr 08\nCollateral Parameters MegaETH v3\nYAE\nOptimizing parameters for new deployments is a healthy part of our growth & security scrutinity.\n\nApr 09\nAave Will Win: Primary Funding\nYAE\nI voted YAE to move the framework into execution, prioritizing protocol progress over perfection. While I would have strongly preferred the foundation’s consolidation and comprehensive disclosures to be fully finalized beforehand, operationalizing our revenue capture is too critical to delay. Now that the resources are deployed, we must advance together and ensure these accountability measures deliver long-term value to the DAO.\n\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n post by ApuMallku on Apr 12\n\n ApuMallku\n\n I want to express my deepest gratitude to everyone who trusted me and delegated their voting power to my platform.\nFollowing the recent discussions around the Aligned Delegates Framework (ADF), it has become clear that without the crucial support and alignment from Labs, advancing this vision is an uphill battle. Since the protocol’s current direction doesn’t align with my thesis on professionalizing the governance layer, I have decided to officially sunset my delegate platform.\nThis is not a goodbye, but a see you later.\nTo my delegators: please remember to redelegate your voting power to other active delegates to keep our governance healthy and decentralized. Thank you for the opportunity to build together.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Phenk53.eth Delegate Platform\n\n Delegate Platforms\n\n 13\n\n 746\n\n Jan 9\n\n Notrustverify.ch Delegate Platform (sunsetted)\n\n Delegate Platforms\n\n 14\n\n 897\n\n Mar 23","tokens":5556,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263143647,"hash":"e658d9cf55d25de2cd310b65e655f034ee2d0220"}
{"url":"https://ethresear.ch/t/from-4844-to-danksharding-a-path-to-scaling-ethereum-da/18046","domain":"ethresear.ch","title":"From 4844 to Danksharding: a path to scaling Ethereum DA - Networking - Ethereum Research","text":"From 4844 to Danksharding: a path to scaling Ethereum DA \n\n Networking\n\n data-availability\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n Dec 2023\n\n 1 / 6\n\n Dec 2023\n\n May 2024\n\n post by fradamt on Dec 28, 2023\n\n fradamt\n\n This post stems from ongoing discussions between many researchers and client devs on the approach to scaling of the DA layer beyond EIP-4844, and is meant to summarize and make accessible some of the prevailing ideas. PeerDAS is a recommended first read.\nThanks to Danny Ryan, Ansgar Dietrichs, Dankrad Feist, Jacob Kaufmann, Age Manning, Csaba Kiraly, Leonardo Bautista-Gomez for feedback and discussions.\nEIP-4844 is the first milestone in the quest of scaling the data availability layer of Ethereum. It introduces a new type of resource, blob data, with its own independent fee market, as well as many of the cryptographic components (KZG ceremony, commitments and proofs) required by Data Availability Sampling (DAS). For the time being, full nodes still download all the data, and the scalability gains of 4844 are due to two factors:\n\nThe independent fee market, which prevents blob data and execution from being competing resources. This ensures that the desired blob data throughput is achieved, regardless of how much demand there is for L1 execution.\nThe pruning of blobs after a few weeks, which makes the additional storage cost fixed instead of increasing over time.\n\nIncreasing the throughput further, while maintaining or lowering the resource requirements, would require that only a portion of the data is downloaded by each node, which means introducing some form of DAS, as is the goal of the Danksharding proposal. Given its ambitious nature, we think it is best to further break down the road from 4844 to Danksharding into more manageable steps, reducing the complexity and risk of each upgrade and allowing us to gradually scale the data layer throughput.\nA possible path goes through intermediate stages, where we gradually introduce all cryptographic and networking components, and gradually obtain more scalability and feature-completeness, while at most minimally increasing the bandwidth requirements compared to 4844. A first step might be to introduce a 1D DAS construction, based on PeerDAS, which reduces the complexity and still allows for a substantially greater throughput than 4844. The transition to the final 2D construction is then in principle relatively simple, and can be enacted once all the cryptographic components are ready. Alongside these two larger upgrades, features like distributed reconstruction can be introduced whenever ready, and the throughput can be gradually scaled up to the theoretical maximum as the networking improves and as we gain confidence from observing the system working as intended. From the perspective of both rollups and their users, it should all be perceived as a gradual increase in the number of blobs, much like a gradual gas size increase on the execution layer.\nStages at a glance\n\nStage 0: EIP-4844. Subnets are introduced for distributing blobs, but nodes have to participate in all of them, downloading all the data. No DAS.\n\n391×192 2.31 KB\n\nStage 1: 1D PeerDAS. Blobs are 1D extended, horizontally. Blob distribution is sharded: column subnets are introduced, and nodes only participate in a subset of them. Blob/row subnets may be deprecated at this point. The networking components of peer sampling are introduced: discovery of sampling peers and peer sampling through a req/resp protocol. Nodes do DAS on columns, and the number of column subnets that they participate in is chosen such that a node’s peer set can reliably cover all columns. Within this stage, we might expect the maximum blob count to gradually increase from 32 to 64 to maybe 128.\n2936×2208 261 KB\n\nStage 2: 2D PeerDAS, or full Danksharding. We implement full Danksharding, with the sampling infrastructure in particular being peer sampling. Blobs are 2D extended, adding the vertical extension. Peer sampling now utilizes cells in the extended matrix instead of columns, becoming lightweight, with negligible bandwidth consumption. Light sampling nodes that do not participate in distribution may be supported. Distributed reconstruction, if/when implemented, becomes more robust to subnet failures. Within this stage, we can expect the blob count to start at 64 or maybe even 128 and gradually increase up to the full Danksharding max throughput of 256.\nimage3020×2840 276 KB\n\nIn parallel:\n\nDistributed reconstruction: can be implemented at any point whenever ready, either in the 1D or 2D stage. In the 1D stage, we would reintroduce row subnets and allow propagation of individual cells within them, so that blobs may be reconstructed and re-seeded. In the 2D stage, this would also apply to column subnets, resulting in a system which is robust to failures of individual subnets (the lack of vertical redundancy in a 1D construction means that the failure of a row subnet prevents reconstruction altogether). Until it is implemented, reconstruction would rely on nodes that download the whole data, reconstruct it locally and re-seed it. Especially at the initial lower blob counts (32 to 64) this is a quite accessible task, and thus not much of an assumption. In any case, we only rely on a 1/N honesty assumption.\nNetworking improvements: most important for peer sampling is supporting higher peer counts, as this addresses its main short-term scaling bottleneck (the long term one being distribution). We can perhaps also eventually support a lighter kind of sampling-only peer with very limited overhead besides occasional pinging, in principle letting nodes have access to the whole network when looking for samples.\nR&D on future scaling: we might at some point want to change the sampling machinery or introduce alternative sampling paths to complement peer sampling, e.g. using a DHT, for greater resilience and less dependence on sampling providers. Still, further scaling (a better ratio of throughput to bandwidth) requires improvements in the data distribution phase, because that’s the bandwidth bottleneck, especially once we move to a 2D construction. Some gains might come from improvements in the subnet infrastructure itself, but there are limits to what can be achieved here, because a subnet density of 1/n (1 in n nodes is in each subnet) requires nodes to download 1/n of the whole data. A more radical redesign would be required to improve on this.\n\nStage 1: 1D PeerDAS\nData format\nBlobs are individually extended horizontally, stacked vertically and subdivided in NUM_COLUMNS columns, which are used as the sampling unit. NUM_COLUMNS determines the maximum column size, and thus how much bandwidth is consumed by sampling (for a given soundness, i.e, number of samples). In the following, I am mostly going to consider the example parameter NUM_COLUMNS = 128, which implies a maximum sample size of 256*b/128 = 2b256 ∗𝑏/128 =2𝑏 KBs, for MAX_BLOBS_PER_BLOCK = b (extended blobs are 256 KBs).\nDistribution\nEach column is mapped to one out of NUM_COLUMN_SUBNETS GossipSub topics, which we refer to as column subnets, where it is distributed. Row subnets can likely be deprecated for the time being, and reintroduced whenever distributed reconstruction is implemented. We ask each node to participate in at least CUSTODY_REQUIREMENT column subnets. CUSTODY_REQUIREMENT/NUM_COLUMN_SUBNETS then dictates the minimum fraction of data that each node custodies, which is also the minimum subnet density. As we’ll see, this is the most important component of the bandwidth consumption, because it incurs the amplification factor of GossipSub topics (while sampling through req/resp does not) and because sampling becomes eventually extremely cheap when moving to a 2D construction.\nFrom the perspective of subnet density, a safe choice for this ratio might be 1/641/64, since we already have experience with this subnet density in attestation subnets, but we might well be ok with 1/1281/128. On the other hand, as we soon see in this section, peer sampling is much more viable if this ratio is high, even better if with NUM_COLUMN_SUBNETS as small as possible, i.e., with CUSTODY_REQUIREMENT = 1. We might then start with NUM_COLUMN_SUBNETS = 32, CUSTODY_REQUIREMENT = 1.\nNote: for a given ratio, one possible reason to set CUSTODY_REQUIREMENT > 1 could be that 1/NUM_COLUMN_SUBNETS determines the minimum “custody unit”, and we might want nodes to have more flexibility in the amount they custody (beyond the required minimum). For example, with NUM_COLUMNS = 128, NUM_COLUMN_SUBNETS = 32 and CUSTODY_REQUIREMENT = 1, the minimum custody unit (in this case corresponding with the minimum required custody) is 4 columns, and a node that wants to custody more than the minimum would have to custody 8, then 12 etc… With NUM_COLUMN_SUBNETS = 64, CUSTODY_REQUIREMENT = 2, the ratio is still 1/32 and the minimum required custody is still 4 columns, but the minimum custody unit is only 2 columns, so that it is possible to custody 6,8,10 etc… Another reason to have CUSTODY_REQUIREMENT > 1 is that the distribution phase then already provides some meaningful security guarantees on its own, before sampling, as we’ll see in this section.\nPeer sampling\nAs in the PeerDAS post, samples are obtained from peers through req/resp., except here samples are entire columns, or more precisely a column sidecar object. In this section, we discuss the details of this object, including the accompanying data that allows its verification. Peers are chosen based on the columns they custody, which can be determined from their ENR, as a function of the amount of subnets they claim to be in (which could be more than the required minimum), of their node ID and potentially of the epoch.\nScaling peer sampling\nThe throughput achievable by PeerDAS does not depend only on the available bandwidth, but also on the composition of the peer sets of full nodes, because a node’s peer set should cover all samples, ideally with plenty of redundancy to account for unreliable or even plainly malicious peers. Covering all samples requires covering all subnets, so the NUM_COLUMN_SUBNETS which can be supported by peer sampling depends on how many peers nodes have, and how many subnets they each participate in. This is precisely why we might want to keep NUM_COLUMN_SUBNETS rather low, lower than what we would need just to keep a sufficiently high subnet density. This may be a limiting factor in the number of blobs we can support, because it creates a higher floor on the bandwidth required for distribution. In practice, it might mean that we need to increase the throughput (number of blobs) gradually, as networking optimizations allow for higher peer counts, perhaps even through the introduction of a lighter type of sampling peer with very limited overhead.\nNote, however, that we can likely scale PeerDAS close to its theoretical limit from day 1, if we are comfortable with relying on there being a small number of honest supernodes or partial supernodes, i.e., nodes that custody more than the required minimum or even all of the data. More generally, a more realistic understanding how far we can scale peer sampling requires taking into account the heterogeneity of the nodes on the network, which affects the amount of data they are willing to custody and serve. In a very heterogenous network, we can get away with much lower peer counts for average nodes. As already anticipated, in the following I am going to assume that NUM_COLUMN_SUBNETS = 32, CUSTODY_REQUIREMENT = 1 are in practice a viable set of parameters.\nTradeoff between subnet sampling and peer sampling\nBy subnet sampling, we mean setting CUSTODY_REQUIREMENT high enough that the distribution phase already gives certain security guarantees, before even getting to peer sampling (or indeed without peer sampling at all, as is the case in SubnetDAS). In particular, we get the guarantee that only a small percentage of nodes will receive all data on the subnets they are participating in, if less than 50% of all columns are available. In other words, even in the distribution phase, only a small percentage of nodes can be tricked into thinking that unavailable data is available.\nHere, what “small percentage” means very much depends on CUSTODY_REQUIREMENT. For example, say the adversary makes columns [0,59] available, slightly less than half. With CUSTODY_REQUIREMENT = 1 and NUM_COLUMN_SUBNETS = 32, honest nodes in the first 15 subnets would receive all sidecars and vote for the associated block, so almost 1/2 of all honest voters would at first vote for an unavailable block. Generally, even a naive adversary can easily trick 2^{-k}2−𝑘 of all honest nodes for CUSTODY_REQUIREMENT = k, so getting any meaningful security from the distribution phase requires CUSTODY_REQUIREMENT to be at least \\ge 4≥4. This might still not be enough against an adaptive adversary, which chooses exactly which portion of the data to make available by observing the exact distribution of nodes on the subnets, as discussed here. In that case, an upper bound on the fraction of honest nodes which can be tricked for CUSTODY_REQUIREMENT = 4 and NUM_COLUMN_SUBNETS = 128 is roughly 20%. With CUSTODY_REQUIREMENT = 6, this would be less than 10%.\nIn principle, we can always increase CUSTODY_REQUIREMENT and NUM_COLUMN_SUBNETS by the same factor, keeping the same ratio, and thus the same subnet density and the same bandwidth consumption for distribution, while increasing the security guarantees of subnet sampling. There is however a tradeoff with the viability of peer sampling: even if we keep the ratio the same, increasing NUM_COLUMN_SUBNETS means increasing the amount of honest peers that a node needs in order to cover all subnets, because there are more overlaps. At lower peer counts, this might make it hard to support a CUSTODY_REQUIREMENT which gives a meaningful level of security, which has some consequences on the fork-choce and confirmation rule, as we now see.\nFork-choice\nWe need to change the is_data_available function. One possibility is to do the following at slot n𝑛:\n\nTo determine the availability of blob data associated with a block from slot n𝑛, we use the availability of the data in the column subnets we participate in: if we have received all sidecars, we consider the data to be available.\nTo determine the availability of blob data associated with a block from a slot < n<𝑛, we use the peer sampling result: if we have obtained all requested samples, we consider the data to be available.\n\nThis way, the proposer of slot n+1𝑛 +1 has at least 8s (the time between the attestation deadline and the next slot) to perform peer sampling, whereas the attesters of slot n𝑛 just have to receive the block and the associated column sidecars by the attestation deadline, much like with blob sidecars in 4844.\nPossible fork-choice attack vectors\nThe downside of employing this trailing DA filter, while having a low CUSTODY_REQUIREMENT, is that votes on the most recent block cannot be fully trusted, because many honest validators might be tricked into voting for a block whose associated data is unavailable, for the reasons we discussed in the previous section. This would of course only be temporary, as no honest voters would continue voting for such a block in future slots, if the data stays unavailable and peer sampling fails. Nonetheless, some subtle fork-choice attacks are possible, such as this one:\n\nBlob data associated to a block B proposed at slot n𝑛 is released in a targeted way, so as to get many honest attesters to vote for block B even while the blob data is not actually available, exploiting the low CUSTODY_REQUIREMENT.\nThe proposer slot n+1𝑛 +1 does peer sampling, sees that the data is unavailable and proposes a block B’ which does not extend block B.\nThe data associated to block B𝐵 is meanwhile made available, and attesters of slot n+1𝑛 +1 do not vote for B’, because it does not extend B, which is available and has a lot of support from the attesters of slot n𝑛.\n\nTo completely prevent or make this attack harder (requiring the attacker to control more attesters), we can require attesters of slot n+1𝑛 +1 to remember the outcome of peer sampling by some time before the end of slot n𝑛, for example 10s into slot n𝑛, and to use that outcome in their fork-choice at slot n+1𝑛 +1 unless it disagrees with the proposed block. If you are familiar with consensus research for Ethereum, this should remind you of the view-merge technique, although with a lot less complexity because no additional messages are required from the proposer. The downside of doing this is that we tighten the window to perform peer sampling.\nBandwidth requirements\nLet’s say that the target and max bandwidth constraints are the same as with 4844, i.e., we want to on average require the equivalent of 3 blobs per slot, and a max of 6 blobs per slot. With the amplification factor of 8x, this corresponds to a target/max of ~3/63/6 MBs/slot. With MAX_BLOBS_PER_BLOCK = b, let’s consider the max bandwidth consumption for a node participating in the minimum CUSTODY_REQUIREMENT = 1 subnets, each containing four columns:\n\nColumn distribution: since distribution happens through GossipSub topics, it incurs the amplification factor, just like blob subnets in 4844. Each cell is 256/128 = 2256/128 =2 KBs, each column 2b2𝑏 KBs. With MAX_BLOBS_PER_BLOCK = 64, columns are then 128 KBs, so propagation of a column is equivalent to propagation of a blob in 4844. One subnet then takes up four blobs in our budget.\nPeer sampling: the leftover bandwidth budget is the equivalent of two blobs, or 2*128*8 = 20482 ∗128 ∗8 =2048 KBs (factoring in the amplification factor). This is enough for up to k = 2048/128 = 16𝑘 =2048/128 =16 samples, since sampling in PeerDAS is through req/resp, and thus does not suffer from an amplification factor. This gives a soundness of 2^{-16}2−16 when a node is not specifically targeted by the attacker, and otherwise gives the global security guarantee that no attacker could convince more than \\approx 2≈2-33% of the nodes that unavailable data is available (see here and the SubnetDAS post for more explanations). These security guarantees are arguably quite sufficient, and we do not need to sample more.\n\nA few comments:\n\nMAX_BLOBS_PER_BLOCK = 64 is 10x the current throughput of 4844, and it is entirely within the bandwidth budget without requiring a high NUM_COLUMN_SUBNETS, which means we do not need to be particularly concerned about the viability of peer sampling, or too much reliance on sampling providers. A safe path could be to start from an MAX_BLOBS_PER_BLOCK = 32 and gradually scale up to 64 as we are sure that the network can handle the load.\nScaling up to MAX_BLOBS_PER_BLOCK = 128 might require increasing NUM_COLUMN_SUBNETS to 64. Supporting this high of a blob count would then likely be highly dependent on the presence of many supernodes in the network, and/or require supporting much higher peer counts.\nAt this point, distribution and sampling contribute similarly to the bandwidth load. The impact of sampling can be reduced if we increaseNUM_COLUMNS, e.g., NUM_COLUMNS = 512 means sampling consumes half a blob with MAX_BLOBS_PER_BLOCK = 64 and one blob with MAX_BLOBS_PER_BLOCK = 128, 8x less than distribution. If we’re ok with a 50% bandwidth increase from 4844, up to a max of 9 blobs, this is already enough to support MAX_BLOBS_PER_BLOCK = 128 without increasing NUM_COLUMN_SUBNETS. Moreover, the bandwidth used by sampling can be made sublinear in the throughput (and effectively negligible) by moving to the 2D construction. This leaves distribution as the ultimate bottleneck, scaling linearly with data throughput (for a minimum subnet density).\n\nNetwork-level validation\nAs seen in PR#3531, we want to be able to perform network-level validation during the distribution phase, without necessarily waiting for the block to arrive. This way, propagation of the block and of sidecars can actually happen in parallel, rather than the latter having to wait for the former. Ideally, we would like to inherit the slashability guarantees of the block, meaning that the proposer (nor anyone else) cannot propagate sidecars that do not match the commitments in the block without double signing, not even to nodes that have not yet received the block. In EIP-4844, the current solution (from the above PR) is to include the relevant kzg_commitment in the blob sidecar, together with a kzg_proof, as well as the block header and an inclusion proof against its body_root, showing that kzg_commitment is indeed contained in the blob_kzg_commitments list in the block body. This way, verification just involves checking the kzg proof, which ensures that kzg_commitment matches the blob, and the inclusion proof. Slashability guarantees are inherited from the header.\nHere we can follow a very similar strategy, aiming to distribute headers, commitments and inclusion proofs separately from the block. We can adapt the current approach for blob sidecars to column sidecars, i.e., to the objects which are distributed on column subnets. In this case, each column sidecar needs to contain all of the commitments, because they’re all necessary to its verification. It would also contain the header, an inclusion proof, proving the inclusion of hash_tree_root(blob_kzg_commitments) in body_root (i.e., inclusion of the whole list of commitments, rather than of a specific one. This proof has depth 4), and all cell proofs for the column. The commitments and proofs can then be used to batch-verify the column.\nThe advantage of this approach is that a column sidecar has no external dependencies, and can therefore be verified and forwarded as soon as received, meaning that the propagation a of block and the associated columns can truly happen in parallel. For the same reason, sampling can begin immediately, without waiting for the block or for other column sidecars to arrive.\nThe disadvantage is that header, inclusion proof and commitments are replicated within each column. Though, note that the first two are negligible and that each column only gets an additional 48 bytes per row from the commitments, as well as another 48 bytes per row from the cell proofs. With NUM_COLUMNS = 128, a cell is 2 KBs, so this is roughly a 5% increase in bandwidth. Note also that the inclusion proof only needs to be checked once, not once per column, so the only penalty is really the minor increase in bandwidth.\nTransition\nBeing ready to transition from Stage 1 to Stage 2 mostly requires well understood components, i.e., GossipSub topics (aka subnets), used for distribution, and req/resp between peers, used for sampling. Most of the changes do not require a hard fork, because they are either in the networking or in the fork-choice. The only change which does is increasing the blob count, which could also happen after all of the other changes are already in place, i.e., we could transition from Stage 0 to Stage 1 while still having the 4844 blob count of 3/6, and only later increase this. In practice, we would want to perform the networking and fork-choice changes at a coordination point regardless, so it likely makes sense to have all changes be bundled with a hard fork. Once the first transition to Stage 1 has happened, we are free to gradually increase the blob count in any subsequent hard fork (or with some other mechanism, if desired).\nStage 2: 2D PeerDAS\nData format and distribution\nBlobs are extended both horizontally and vertically. The resulting rectangle is still subdivided into NUM_COLUMNS columns, and samples are now cells, the intersection of rows and columns, as in the Danksharding construction. Nothing changes in the distribution.\nPeer sampling\nSampling still utilizes the same networking building blocks, i.e., discovery of a diverse set of peers, with respect to the subnets they participate in, and req/resp to sample from them. The only difference is in what the requested objects are, i.e., cells instead of columns. Cells come with the accompanying proof, to be verified against the KZG commitment of the respective row.\nBandwidth requirements\nLet’s consider MAX_BLOBS_PER_BLOCK = 256, which would achieve the originally planned Danksharding (max) throughput of 32 MBs/slot, though in practice we would likely gradually increase the blob count to get to this point. At this point, let’s assume we are able to increase NUM_COLUMN_SUBNETS to 64, perhaps because of increased peer counts.\nEach subnet would then contain two columns, each of which weighs 1 MB. Still, a column sidecar would only weigh 0.5 MBs, because it can just contain the first half of the column, while the rest can be reconstructed locally by the receiver. Doing so consists of one FFT of size 2^{14}214 to go from evaluation form to coefficient form, and another FFT also of the same size to recover the evaluation form for the extension (~4ms in arkworks). A column subnet then consumes the equivalent of 8 blobs of bandwidth budget, a small increase from the 6 of 4844. The propagation dynamics are likely somewhat different due to there being fewer, larger objects, though this is something we could easily change by increasing NUM_COLUMNS.\nThe total bandwidth required by sampling is just 2k2𝑘 KBs, because samples weigh only 22 KBs instead of the 2b2𝑏 KBs from the 1D construction. As anticipated, even with k = 75𝑘 =75 (which gives soundness of \\approx 2^{-30}≈2−30), the bandwidth for sampling is therefore essentially negligible compared to what is required by distribution.\nNetwork-level validation\nThe same approach as in Stage 1 works here. Even with the vertical extension, the number of proofs and commitments that needs to be sent along with a column sidecar is in principle unchanged, because both proofs and commitments for the second half of the column can be reconstructed with a linear combination of those for the first half, due to both proofs and commitments being homomorphic. Although, we might choose to still send all proofs to avoid the reconstruction step, in which case a column sidecar would now contain 2b2𝑏 proofs, resulting in 2.5% of additional bandwidth consumption (for NUM_COLUMNS = 128).\nTransition\nBeing ready to transition from Stage 2 to Stage 3 requires an efficient implementation of the 2D cryptography, though this mainly affects the block production process. There is also a small change in peer sampling, as the objects which are exchanged through the req/resp protocol change from columns to cells. In principle, a hard fork is again only required to increase the throughput, because blocks still only contain the same list of KZG commitments, i.e., the ones corresponding to actual blobs and not to extension rows (as already mentioned, we can reconstruct the latter from the former). We would still need all changes to happen at a coordination point, so they would likely still be coupled with a hard fork.\n\n LossyDAS: Lossy, Incremental, and Diagonal Sampling for Data Availability\n\n PeerDAS -- a simpler DAS approach using battle-tested p2p components\n\n DAS fork-choice\n\n Accelerating blob scaling with FullDASv2 (with getBlobs, mempool encoding, and possibly RLC)\n\n Dynamic Blob Sizing: Reducing Zero-Padding Overhead in Small Rollups\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n 4 months later\n\n post by Evan-Kim2028 on Apr 17, 2024\n\n Evan-Kim2028\n\nUnder Stage 1, has there been any research done for how the execution layer will handle this larger amount of blobs in the mempool? Sure data availability sampling will alleviate the consensus layer bandwidth concerns, does the EL get similar alleviation?\nSince EIP-4844 requires execution layer validation, it seems like it is not possible for blobs to circumvent the EL mempool.\n\n post by fradamt on Apr 19, 2024\n\n fradamt\n\n Imho, the blob mempool can either become sharded itself, or (more likely) stay fairly low capacity, with the assumption that most blobs will just not go through it.\n\nNot sure what you mean by this. Even today, a blob never needs to touch the EL mempool in order to get into a block. Just like regular transactions, you can directly send them to a builder (or proposer in principle).\n\n post by Evan-Kim2028 on Apr 19, 2024\n\n Evan-Kim2028\n\nHow does this work?\n\nWhile I think this can be made as a futuristic assumption, it currently does not reflect reality today - 99.99% blobs go through the public mempool today.\n\n post by Athos on Apr 23, 2024\n\n Athos\n\n I find that in the final stage of PeerDAS the peers are also required to sample a whole cell, which is 2KB.\nIs it possible if we request only a single field element and verify it using KZG proof?\nLet the blob be B, its commitment be C, and the cell data be D. We do an interpolation on D and we can get polynomial I. So we have the proof P=(C-I(s))/Z(s), here Z is the zero-polynomial of the interpolation points.\nActually the I(s) is the commitment of cell polynomial I. So we can just use this to to proof that a single field element is in the cell data D by first proofing that it is in I, and then proofing the data D is in the whole blob. We can just providing I(s) instead of providing the whole cell, so that might reduce the network pressure of light nodes.\n\n 23 days later\n\n post by 0x00101010 on May 17, 2024\n\n 0x00101010\n\nDo you mean from Stage 1 to Stage 2 here?\n\n Powered by Discourse","tokens":7368,"squid":"ink-research","role":"Deep Scholar","at":1791263147259,"hash":"497739689f5e9e597550ad756c3a20f7d7d244f5"}
{"url":"https://forum.soliditylang.org/t/using-clz-to-seed-sqrt-finding-the-initial-estimate-before-and-after-fusaka/3707/2","domain":"forum.soliditylang.org","title":"Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2\n\n 2 / 2\n\n Jun 9\n\n Jun 9\n\n post by nebojsakonsta on Jun 2\n\n nebojsakonsta\n\n Hi all — first post here. I’m Konsta, and I build DeFiMath, an open-source, gas-optimized Solidity library for on-chain financial math (Black-Scholes pricing, fixed-point primitives, roots, and so on). I’ve been deep in root functions lately and wanted to share one small change to how the initial estimate is found — and hear how others are handling it now that Fusaka has shipped.\nNewton/Babylonian sqrt converges fast, but only if the starting guess is close. So the first job is to find the magnitude of x — essentially its top set bit — and build a seed from it.\nBefore: you locate the magnitude with a shift/compare cascade. This is the estimate section from Solady’s sqrt (MIT):\nz := 181\n// find the magnitude of x via shift/compare\nlet r := shl(7, lt(0xffffffffffffffffffffffffffffffffff, x))\nr := or(r, shl(6, lt(0xffffffffffffffffff, shr(r, x))))\nr := or(r, shl(5, lt(0xffffffffff, shr(r, x))))\nr := or(r, shl(4, lt(0xffffff, shr(r, x))))\nz := shl(shr(1, r), z)\nz := shr(18, mul(z, add(shr(r, x), 65536)))\n\nFour conditional steps just to pin down the top bit before the seed is computed.\nAfter: with EIP-7939 live since Fusaka, clz gives the magnitude in a single 5-gas opcode, so that whole cascade collapses to one line:\nz := 181\n// magnitude of x in one opcode (index of the top set bit)\nlet r := sub(255, clz(x))\nz := shl(shr(1, r), z)\nz := shr(18, mul(z, add(shr(r, x), 65536)))\n\nThe downstream seed math is unchanged — only the magnitude lookup moves to the opcode. In my benchmarks that’s around 100 gas off the seeding step alone, plus smaller bytecode. Two things to keep in mind: align r’s rounding with whatever your interpolation window expects and test against the original, and remember clz(0) returns 256, so guard x == 0 as usual. clz is callable directly in inline assembly on solc 0.8.35+ when you target the Osaka/Fusaka EVM version.\nCurious whether anyone has found cases where a software bit-length still beats the opcode, or where the seed precision matters less than I’m assuming.\n\n post by czepluch on Jun 9\n\n czepluch\n\n Solidity Team\n\n Hey and welcome.\nThis is cool. Thanks for sharing!\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 108\n\n Oct 2025\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 121\n\n Apr 18\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 82\n\n Jun 2\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1582,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263153329,"hash":"3cfdd47c0d99b6557cb61c621a262206d20a3064"}
{"url":"https://governance.aave.com/t/apu-mallku-delegate-platform-shutdown/24043/1","domain":"governance.aave.com","title":"Apu Mallku [Delegate platform]: Shutdown 🚩 - Delegate Platforms - Aave","text":"Apu Mallku [Delegate platform]: Shutdown \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 7\n min\n\n Feb 11\n\n 1 / 7\n\n Feb 12\n\n Apr 12\n\n post by ApuMallku on Feb 11\n\n ApuMallku\n\n Hello Aave Community. I’m Apu Mallku (apumallku.eth). My journey with this protocol didn’t start yesterday; it began in late 2017, as an early participant in the EthLend ICO. I have been here since before Aave was even Aave.\n\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nDune: https://dune.com/apumallku/aave\n\nWhen the foundation of DeFi was being built in early 2020, I was there for the launch of Yearn Finance, taking my first steps in yield farming and eventually serving as Partnership Lead for prominent DeFi projects—initiatives that became the original “Blue Chips” of the DeFi Summer. My professional background in partnership growth has given me a front-row seat to how protocols scale, how they fail, and how they are often captured by misaligned interests.\nFor years, I have been a silent observer—watching from the sidelines, analyzing the shifts in governance power, and voting with my own conviction. But the current state of Aave has reached a tipping point where silence is no longer an option. Now is the time to act. Aave doesn’t need more “Governance-as-a-Service” corporate delegates. It needs fiercely independent, veteran voices who aren’t afraid to speak the truth. We are witnessing a slow drift toward corporate capture, where institutional delegates often remain silent on critical issues like conflict of interest or Service Provider (SP) monopolies.\nEncouraged by the support of independent voices and active contributors, I am formalizing my role as a Delegate. My goal is simple: I am here to ask the hard questions, protect the protocol from centralization, and return the focus to where it belongs—the utility and value of the AAVE token.\n Core Values & Ethos\nMy governance philosophy is deeply rooted in free-market dynamics and strict decentralization. My recent track record in the forum reflects this:\nAnti-Monopoly & True Decentralization: A DAO should foster competition, not monopolies. I stand against the consolidation of power by a few whale wallets or aggregate SPs. Aave must remain sufficiently decentralized, not just for ethical reasons, but to mitigate existential regulatory risks (e.g., SEC scrutiny).\nMeritocracy & Accountability: Funding should be based on performance, not legacy status. I advocate for clear KPIs, Conflict of Interest (COI) frameworks, and bounty-based models to ensure every AAVE/GHO spent by the Treasury delivers undeniable value.\nIP Sovereignty & Open Innovation: Aave must be an ecosystem that empowers third-party builders, not one that leaves them behind due to legal or branding bottlenecks created by centralized off-chain entities.\nIndependent Over Institutional: I do not run a governance factory, and I am not looking to appease any corporate partners. I represent the raw, free-market ethos of DeFi. I will always favor transparency over political correctness. If a proposal is bad for the DAO but good for an insider group, I will publicly call it out.\n Key Priorities\nIf you delegate your voting power to me, these are the pillars I will aggressively pursue:\nMaximize AAVE Token Power & Utility: The AAVE token must be the ultimate beneficiary of the protocol’s success. I will support and champion initiatives that drive value accrual to the token, enhance its utility within the ecosystem (like GHO dynamics), and ensure that holders are rewarded for their risk.\nRuthless Treasury Stewardship: The DAO’s treasury is not an ATM for Service Providers. I will scrutinize budget renewals, demand transparency, push for mandatory disclosures, and vote strictly against any proposal where a clear conflict of interest compromises the DAO’s financial health.\nAggressive Ecosystem Growth: I will enthusiastically support all growth initiatives that scale Aave’s dominance safely—such as listing new resilient assets, deploying on promising L2s, and expanding GHO adoption—provided they adhere to strict risk management standards.\n Disclosures & Conflict of Interest\nIn the spirit of the transparency I demand from others:\nI am an independent DeFi participant. I am not currently employed by, nor do I receive a salary from, any Aave Service Provider.\nI hold positions in AAVE, ETH and SKY but Aave remains my primary governance focus.\n How to Delegate\nIf you share this vision of a decentralized, free-market-driven, and highly efficient Aave, I invite you to delegate your AAVE / stkAAVE to my address. It is time to make our voices heard and protect the protocol we all helped build.\nENS: apumallku.eth\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nLet’s build a stronger, truly decentralized Aave.\n\n How AAVE will win\n\n [TEMP CHECK] The AAVE Utility Renaissance: Aligning Protocol Success with Token Holder Value\n\n read \n\n 7\n min\n\n 14 days later\n\n post by ApuMallku on Feb 25\n\n ApuMallku\n\n Date Voted: February 25, 2026\n\n SNAPSHOT\n1. Proposal: [TEMP CHECK] Aave Will Win Framework\n\nVote: NAY\n\nRationale: This vote was rushed and it shows. I welcome Labs opening a dialogue — but that’s all this is: a dialogue starter, not a finished product. The most relevant service provider in the entire ecosystem has failed to answer a single sensitive question raised by the community before pushing this to Snapshot. That is unacceptable. A proposal with this name carries enormous expectations. At minimum, it should have contained concrete proposals around AAVE token utility and explicit, tangible benefits for token holders. Instead, we got silence on the hard questions and a Snapshot vote. Ghosting the community while forcing a governance pulse is not leadership — it’s pressure. Not good enough.\n\n2. Proposal: [ARFC] Aave v3.7 Candidate\n\nVote: YAE\n\nRationale: BGD Labs has consistently delivered. This proposal is technically sound, well-structured, and follows the proper governance process. Aave v3.7 is the right next step for the protocol’s technical evolution. I support moving forward.\n\n ON-CHAIN\n3. Proposal: Focussing the Aave V3 Multichain Strategy – Phase 1\n\nVote: YAE\n\nRationale: Freezing low-activity V3 markets is a prudent and necessary risk management decision. ACI has presented a clear case, the proposal is well-scoped, and it aligns with the long-term health of the protocol. I vote in favor.\n\n4. Proposal: Create Allowance GHO Mantle\n\nVote: NAY (human error)\n\nRationale: My NAY vote here was a human error — I intended to vote YAE. TokenLogic’s proposal to create an aEthLidoGHO allowance for the Aave Liquidity Committee is sound and consistent with GHO’s liquidity strategy. I’m documenting this publicly because transparency is the standard I hold others to. I hold myself to the same standard.\n\n5. Proposal: February 2026 – Funding Update\n\nVote: YAE\n\nRationale: Transparent, well-structured, and straightforward. Maintaining the DAO’s runway and ensuring clear traceability of funds is non-negotiable for a healthy protocol. TokenLogic delivers consistently. I support this without reservations.\n\n post by ApuMallku on Mar 5\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\nENS: apumallku.eth\n\nYour support allows me to continue defending the interests of the community and ensuring Aave remains the premier liquidity protocol in DeFi.\n\n Voting Activity Report\n6. [Snapshot] [ARFC] Deploy Aave v3 on X Layer\nDecision: FOR\nRationale: We support the deployment on X Layer as part of Aave’s multichain expansion. By integrating with OKX’s ecosystem, Aave can tap into a significant source of retail liquidity and onboard a new demographic of users. This move strengthens the protocol’s position as the leading liquidity provider across all relevant EVM networks, driving more value to AAVE holders through diversified revenue streams.\n7. [Snapshot] [TEMP CHECK] Deploy Aave Protocol on Monad\nDecision: FOR\nRationale: Monad’s high-throughput architecture is one of the most anticipated technological leaps in the EVM space. Voting FOR ensures that Aave remains at the forefront of innovation. Being a first-mover on Monad allows the protocol to capture early TVL and establish itself as the foundational lending layer for a high-frequency DeFi ecosystem, which is essential for long-term growth.\n8. ACI is Leaving Aave\nDecision: YAE\nRationale: This is a historic and difficult vote for our platform. I am voting YAE, but I want to be clear: I never imagined having to vote for the decoupling of the Aave Chan Initiative (ACI) from the DAO.\n\nTransition over Disruption: While the departure of such a key contributor is a loss, we must prioritize the protocol’s operational continuity. This vote facilitates a structured 120-day wind-down, which is the most responsible path to prevent governance instability.\n\n post by ApuMallku on Mar 9\n\n ApuMallku\n\n 9. [Snapshot] [ARFC] Safety Module - Reduce Emissions\nDecision: NAY\nRationale: I have voted NAY on the proposal to reduce emissions for the Safety Module. While I understand the DAO’s goal of fiscal optimization, my stance is clear: Putting AAVE Token Holders First means not stripping away incentives before a superior alternative is functional.\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n 8 days later\n\n post by ApuMallku on Mar 17\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nI want to start by expressing my deepest gratitude to all the delegates who, week after week, entrust me with their voting power to represent them in the Aave DAO. Your support is the engine of this platform. To celebrate our growth and enhance transparency, I have created a Dune Dashboard where you can track the evolution and impact of the Apu Mallku platform in real-time: dune.com/apumallku/aave.\n\n Voting Activity Report\n10. [Snapshot] [TEMP CHECK] Aave V4 Bug Bounty Program on Sherlock\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: Security is the non-negotiable foundation of Aave. I voted FOR establishing this bug bounty program on Sherlock. As we prepare for the transition to V4, incentivizing top-tier white-hat hackers to stress-test the code is the most cost-effective insurance policy for the DAO. This directly protects AAVE holders from potential exploit risks during the next major protocol upgrade.\n11. [Snapshot] [ARFC] Buyback Program - Budget Adjustment\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: I support this budget adjustment for the Buyback Program. Optimizing the DAO’s treasury to strategically accumulate AAVE from the market aligns protocol revenue with token value. This mechanism creates a healthy feedback loop: as the protocol succeeds, the DAO increases its stake in its own future, reducing circulating supply and rewarding long-term holders.\n\nStrategic Execution: While I agree with the proposal, I believe the buyback should be optimized based on market conditions. If the token is undervalued, the DAO should execute larger orders.\nBeyond DCA: In my view, a simple DCA (Dollar Cost Averaging) strategy is not the correct approach and never has been; we need a more opportunistic execution model to maximize value for the treasury.\n\n12. [Snapshot] [TEMP CHECK] Aave V4 Licensing\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: Protecting Aave’s intellectual property is vital for maintaining our competitive advantage. I voted FOR the V4 licensing framework to ensure that while we remain open-source in spirit, the DAO retains control over how its innovations are commercialized by third parties. This prevents “vampire attacks” and ensures that the value created by Aave Labs and the DAO stays within the Aave ecosystem.\n\n On-chain Votes (Chronological Order)\n13. [On-chain] Activate Capo Risk Agent and expand Rates Agent\nDecision: YAE\nVoting Power: 1,206.42 AAVE\nRationale: I voted YAE to expand our automated risk management capabilities. Activating these agents allows for more dynamic, data-driven parameter adjustments across multiple networks, scaling safety without manual bottlenecks.\n14. [On-chain] Enhancing Market Granularity in Aave 3.6: part 2\nDecision: MISSED (Operational Error)\nVoting Power: N/A\nRationale: Regarding this vote, I unfortunately missed the execution window due to an operational error. I want to be fully transparent: I have already taken the necessary technical measures and updated my monitoring workflows to ensure this does not happen again. Reliability is my top priority.\n15. [On-chain] Gho X-Layer Activation\nDecision: YAE\nVoting Power: 6,993.74 AAVE\nRationale: Following our support for the X-Layer deployment, I voted YAE for the official activation of GHO on this network. This increases GHO’s utility within the OKX ecosystem and drives more interest income back to the DAO treasury.\n16. [On-chain] wstETH CAPO Oracle Incident User Reimbursement\nDecision: YAE\nVoting Power: 6,993.74 AAVE\nRationale: Accountability is key to maintaining trust. I voted YAE to reimburse users affected by the wstETH CAPO oracle incident. Ensuring that users are made whole after a technical failure is essential for Aave’s reputation as a premium, secure protocol.\n\nAdvocacy for Clarity: I was very vocal regarding this issue, actively seeking answers and trying to understand exactly what happened.\n\nBridging the Gap: Most forum posts were overly technical, leaving non-technical community members lost in jargon. In the future, I want to see better documentation regarding risk management workflows that is accessible to everyone.\n\nWorkflow Support: I fully support the initiative to incorporate LlamaRisk into these workflows to enhance our collective oversight.\n\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n 23 days later\n\n post by ApuMallku on Apr 10\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nYou can track the evolution and impact of the Apu Mallku platform in real-time: dune.com/apumallku/aave.\n Voting Activity Report\nSnapshot votes\n\nDate\nProposal\nDecision\nRationale\n\nMar 21\n[ARFC] Aave <> Chainlink SVR. Multi-network expansion\nFOR\nExpanding the Savings Rate across networks is a highly strategic move for capturing yield and improving composability. I support this expansion to maximize our multichain presence, provided we maintain our strict standards for cross-chain oracle security.\n\nMar 23\n[ARFC] Aave V4 Activation on Ethereum Mainnet\nFOR\nV4 is a vital architectural leap for Aave’s future. I voted FOR to fully support this technical upgrade, while maintaining my collaborative view that we must continue refining our governance frameworks to ensure token holders are fully aligned with this new phase.\n\nMar 27\n[ARFC] Bug Bounty Program on Sherlock\nFOR\nA robust security infrastructure is non-negotiable for a protocol of our size. I fully support leveraging competitive audit models to protect the ecosystem, ensuring that treasury funds are efficiently allocated to maximize technical resilience.\n\nMar 29\n[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance\nFOR\nExpanding stablecoin diversity on new high-performance instances like Sonic is a positive step for market capture. Supported with the recommendation that initial supply caps remain appropriately conservative during the network’s bootstrap phase.\n\nMar 29\n[ARFC] Aave V4 Licensing\nFOR\nProtecting Aave’s intellectual property is essential to ensure that the value created by the DAO and its contributors stays within the ecosystem. I voted FOR to establish a framework that defends our innovations while still fostering collaborative growth.\n\nAbr 03\n[ARFC] Update Signers and SAFE Configuration\nFOR\nRoutine housekeeping is necessary for smooth operations. Approved to maintain current decentralized threshold standards, while I look forward to encouraging continued rotation and separation of duties among service providers in the future.\n\nAbr 03\n[ARFC] sGHO Launch Configuration\nFOR\nThe deployment of sGHO is a strong, positive step for our stablecoin ecosystem. Supported with the recommendation that we closely monitor organic market demand to ensure sustainable yield growth alongside our treasury strategies.\n\nAbr 04\n[ARFC] Aave Will Win Framework\nFOR\nI support the vision and the alignment of branded product revenue directly to the treasury. I voted FOR to enable these structural improvements, and I look forward to working together with the community on further enhancing AAVE token utility prior to the AIP execution.\n\nAbr 05\n[ARFC] Onboard PT-USDG-28MAY2026\nFOR\nIntegrating fixed-rate primitives is an excellent way to safely expand our multichain footprint. Approved with the expectation that supply caps remain conservatively managed while the oracle infrastructure scales gracefully.\n\nAbr 06\n[ARFC] Continued Deprecation of V2 Markets\nFOR\nSunsetting legacy markets is an essential step for technical efficiency and optimal resource allocation toward V4. I fully support these deprecation steps to encourage a smooth and safe capital migration for all users.\n\n On-chain Votes (Chronological Order)\n\nDate\nProposal\nDecision\nRationale\n\nMar 24\nReduce Safety Module Emissions\nYAE\nOptimizing treasury emissions is key for our long-term sustainability. I support this reduction to ensure we remain capital-efficient while fairly rewarding participants who are aligned with protocol growth.\n\nMar 29\nAave V3.6 XLayer Activation\nYAE\nExpanding our ecosystem to XLayer is a strategic priority.\n\nMar 29\nEnable SVR on Base and Arbitrum\nYAE\nDeploying the Savings Rate to L2s significantly strengthens our cross-chain composability. Voted YAE to support this expansion, highlighting the need for robust and continuous oracle synchronization.\n\nMar 30\nOnboard BTC.b to Aave V3 Core\nYAE\nWhile there is clear market demand for Bitcoin exposure, we must carefully manage the technical nuances of bridged assets. Voted YAE, fully supporting the conservative supply caps and risk mitigation parameters.\n\nMar 30\nAave V4 Activation on Ethereum\nYAE\nThe Hub-and-Spoke model is a remarkable achievement in capital efficiency, and I voted YAE to activate it on-chain. While I maintain that the governance friction surrounding the ‘Aave Will Win’ framework should have been fully resolved prior to launching such a critical upgrade.\n\nApr 06\nListing PT Ethena 18JUN2026\nYAE\nPendle integrations offer excellent benefits for our users. Voted YAE, appreciating that the supply caps have been carefully calibrated by risk providers to safely match the asset’s specific liquidity profile.\n\nApr 07\nMarch Funding Update\nYAE\nEnsuring our contributors are funded is essential for uninterrupted protocol operations. Voted YAE, and I look forward to collaborating on transitioning toward more milestone-based reporting and streaming models moving forward.\n\nApr 07\nListing PT Strata 25JUN2026\nYAE\nAnother strong addition to our yield tokenization offerings. Voted YAE with confidence in the conservative borrowing power parameters that responsibly manage the underlying duration risk.\n\nApr 07\nUmbrella Deficit Updates\nYAE\nMaintaining a fully capitalized safety layer is paramount for depositor trust. Voted YAE to resolve these deficits promptly, emphasizing our shared commitment to continuous improvement in risk modeling.\n\nApr 08\nCollateral Parameters MegaETH v3\nYAE\nOptimizing parameters for new deployments is a healthy part of our growth & security scrutinity.\n\nApr 09\nAave Will Win: Primary Funding\nYAE\nI voted YAE to move the framework into execution, prioritizing protocol progress over perfection. While I would have strongly preferred the foundation’s consolidation and comprehensive disclosures to be fully finalized beforehand, operationalizing our revenue capture is too critical to delay. Now that the resources are deployed, we must advance together and ensure these accountability measures deliver long-term value to the DAO.\n\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n post by ApuMallku on Apr 12\n\n ApuMallku\n\n I want to express my deepest gratitude to everyone who trusted me and delegated their voting power to my platform.\nFollowing the recent discussions around the Aligned Delegates Framework (ADF), it has become clear that without the crucial support and alignment from Labs, advancing this vision is an uphill battle. Since the protocol’s current direction doesn’t align with my thesis on professionalizing the governance layer, I have decided to officially sunset my delegate platform.\nThis is not a goodbye, but a see you later.\nTo my delegators: please remember to redelegate your voting power to other active delegates to keep our governance healthy and decentralized. Thank you for the opportunity to build together.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Phenk53.eth Delegate Platform\n\n Delegate Platforms\n\n 13\n\n 746\n\n Jan 9\n\n Notrustverify.ch Delegate Platform (sunsetted)\n\n Delegate Platforms\n\n 14\n\n 897\n\n Mar 23","tokens":5567,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263154395,"hash":"9b884843632d0a3790c634ed359f7f84fccb9be9"}
{"url":"https://ethresear.ch/t/from-4844-to-danksharding-a-path-to-scaling-ethereum-da/18046/6","domain":"ethresear.ch","title":"From 4844 to Danksharding: a path to scaling Ethereum DA - Networking - Ethereum Research","text":"Networking\n\n data-availability\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n Dec 2023\n\n 6 / 6\n\n May 2024\n\n May 2024\n\n post by fradamt on Dec 28, 2023\n\n fradamt\n\n This post stems from ongoing discussions between many researchers and client devs on the approach to scaling of the DA layer beyond EIP-4844, and is meant to summarize and make accessible some of the prevailing ideas. PeerDAS is a recommended first read.\nThanks to Danny Ryan, Ansgar Dietrichs, Dankrad Feist, Jacob Kaufmann, Age Manning, Csaba Kiraly, Leonardo Bautista-Gomez for feedback and discussions.\nEIP-4844 is the first milestone in the quest of scaling the data availability layer of Ethereum. It introduces a new type of resource, blob data, with its own independent fee market, as well as many of the cryptographic components (KZG ceremony, commitments and proofs) required by Data Availability Sampling (DAS). For the time being, full nodes still download all the data, and the scalability gains of 4844 are due to two factors:\n\nThe independent fee market, which prevents blob data and execution from being competing resources. This ensures that the desired blob data throughput is achieved, regardless of how much demand there is for L1 execution.\nThe pruning of blobs after a few weeks, which makes the additional storage cost fixed instead of increasing over time.\n\nIncreasing the throughput further, while maintaining or lowering the resource requirements, would require that only a portion of the data is downloaded by each node, which means introducing some form of DAS, as is the goal of the Danksharding proposal. Given its ambitious nature, we think it is best to further break down the road from 4844 to Danksharding into more manageable steps, reducing the complexity and risk of each upgrade and allowing us to gradually scale the data layer throughput.\nA possible path goes through intermediate stages, where we gradually introduce all cryptographic and networking components, and gradually obtain more scalability and feature-completeness, while at most minimally increasing the bandwidth requirements compared to 4844. A first step might be to introduce a 1D DAS construction, based on PeerDAS, which reduces the complexity and still allows for a substantially greater throughput than 4844. The transition to the final 2D construction is then in principle relatively simple, and can be enacted once all the cryptographic components are ready. Alongside these two larger upgrades, features like distributed reconstruction can be introduced whenever ready, and the throughput can be gradually scaled up to the theoretical maximum as the networking improves and as we gain confidence from observing the system working as intended. From the perspective of both rollups and their users, it should all be perceived as a gradual increase in the number of blobs, much like a gradual gas size increase on the execution layer.\nStages at a glance\n\nStage 0: EIP-4844. Subnets are introduced for distributing blobs, but nodes have to participate in all of them, downloading all the data. No DAS.\n\n391×192 2.31 KB\n\nStage 1: 1D PeerDAS. Blobs are 1D extended, horizontally. Blob distribution is sharded: column subnets are introduced, and nodes only participate in a subset of them. Blob/row subnets may be deprecated at this point. The networking components of peer sampling are introduced: discovery of sampling peers and peer sampling through a req/resp protocol. Nodes do DAS on columns, and the number of column subnets that they participate in is chosen such that a node’s peer set can reliably cover all columns. Within this stage, we might expect the maximum blob count to gradually increase from 32 to 64 to maybe 128.\n2936×2208 261 KB\n\nStage 2: 2D PeerDAS, or full Danksharding. We implement full Danksharding, with the sampling infrastructure in particular being peer sampling. Blobs are 2D extended, adding the vertical extension. Peer sampling now utilizes cells in the extended matrix instead of columns, becoming lightweight, with negligible bandwidth consumption. Light sampling nodes that do not participate in distribution may be supported. Distributed reconstruction, if/when implemented, becomes more robust to subnet failures. Within this stage, we can expect the blob count to start at 64 or maybe even 128 and gradually increase up to the full Danksharding max throughput of 256.\nimage3020×2840 276 KB\n\nIn parallel:\n\nDistributed reconstruction: can be implemented at any point whenever ready, either in the 1D or 2D stage. In the 1D stage, we would reintroduce row subnets and allow propagation of individual cells within them, so that blobs may be reconstructed and re-seeded. In the 2D stage, this would also apply to column subnets, resulting in a system which is robust to failures of individual subnets (the lack of vertical redundancy in a 1D construction means that the failure of a row subnet prevents reconstruction altogether). Until it is implemented, reconstruction would rely on nodes that download the whole data, reconstruct it locally and re-seed it. Especially at the initial lower blob counts (32 to 64) this is a quite accessible task, and thus not much of an assumption. In any case, we only rely on a 1/N honesty assumption.\nNetworking improvements: most important for peer sampling is supporting higher peer counts, as this addresses its main short-term scaling bottleneck (the long term one being distribution). We can perhaps also eventually support a lighter kind of sampling-only peer with very limited overhead besides occasional pinging, in principle letting nodes have access to the whole network when looking for samples.\nR&D on future scaling: we might at some point want to change the sampling machinery or introduce alternative sampling paths to complement peer sampling, e.g. using a DHT, for greater resilience and less dependence on sampling providers. Still, further scaling (a better ratio of throughput to bandwidth) requires improvements in the data distribution phase, because that’s the bandwidth bottleneck, especially once we move to a 2D construction. Some gains might come from improvements in the subnet infrastructure itself, but there are limits to what can be achieved here, because a subnet density of 1/n (1 in n nodes is in each subnet) requires nodes to download 1/n of the whole data. A more radical redesign would be required to improve on this.\n\nStage 1: 1D PeerDAS\nData format\nBlobs are individually extended horizontally, stacked vertically and subdivided in NUM_COLUMNS columns, which are used as the sampling unit. NUM_COLUMNS determines the maximum column size, and thus how much bandwidth is consumed by sampling (for a given soundness, i.e, number of samples). In the following, I am mostly going to consider the example parameter NUM_COLUMNS = 128, which implies a maximum sample size of 256*b/128 = 2b256 ∗𝑏/128 =2𝑏 KBs, for MAX_BLOBS_PER_BLOCK = b (extended blobs are 256 KBs).\nDistribution\nEach column is mapped to one out of NUM_COLUMN_SUBNETS GossipSub topics, which we refer to as column subnets, where it is distributed. Row subnets can likely be deprecated for the time being, and reintroduced whenever distributed reconstruction is implemented. We ask each node to participate in at least CUSTODY_REQUIREMENT column subnets. CUSTODY_REQUIREMENT/NUM_COLUMN_SUBNETS then dictates the minimum fraction of data that each node custodies, which is also the minimum subnet density. As we’ll see, this is the most important component of the bandwidth consumption, because it incurs the amplification factor of GossipSub topics (while sampling through req/resp does not) and because sampling becomes eventually extremely cheap when moving to a 2D construction.\nFrom the perspective of subnet density, a safe choice for this ratio might be 1/641/64, since we already have experience with this subnet density in attestation subnets, but we might well be ok with 1/1281/128. On the other hand, as we soon see in this section, peer sampling is much more viable if this ratio is high, even better if with NUM_COLUMN_SUBNETS as small as possible, i.e., with CUSTODY_REQUIREMENT = 1. We might then start with NUM_COLUMN_SUBNETS = 32, CUSTODY_REQUIREMENT = 1.\nNote: for a given ratio, one possible reason to set CUSTODY_REQUIREMENT > 1 could be that 1/NUM_COLUMN_SUBNETS determines the minimum “custody unit”, and we might want nodes to have more flexibility in the amount they custody (beyond the required minimum). For example, with NUM_COLUMNS = 128, NUM_COLUMN_SUBNETS = 32 and CUSTODY_REQUIREMENT = 1, the minimum custody unit (in this case corresponding with the minimum required custody) is 4 columns, and a node that wants to custody more than the minimum would have to custody 8, then 12 etc… With NUM_COLUMN_SUBNETS = 64, CUSTODY_REQUIREMENT = 2, the ratio is still 1/32 and the minimum required custody is still 4 columns, but the minimum custody unit is only 2 columns, so that it is possible to custody 6,8,10 etc… Another reason to have CUSTODY_REQUIREMENT > 1 is that the distribution phase then already provides some meaningful security guarantees on its own, before sampling, as we’ll see in this section.\nPeer sampling\nAs in the PeerDAS post, samples are obtained from peers through req/resp., except here samples are entire columns, or more precisely a column sidecar object. In this section, we discuss the details of this object, including the accompanying data that allows its verification. Peers are chosen based on the columns they custody, which can be determined from their ENR, as a function of the amount of subnets they claim to be in (which could be more than the required minimum), of their node ID and potentially of the epoch.\nScaling peer sampling\nThe throughput achievable by PeerDAS does not depend only on the available bandwidth, but also on the composition of the peer sets of full nodes, because a node’s peer set should cover all samples, ideally with plenty of redundancy to account for unreliable or even plainly malicious peers. Covering all samples requires covering all subnets, so the NUM_COLUMN_SUBNETS which can be supported by peer sampling depends on how many peers nodes have, and how many subnets they each participate in. This is precisely why we might want to keep NUM_COLUMN_SUBNETS rather low, lower than what we would need just to keep a sufficiently high subnet density. This may be a limiting factor in the number of blobs we can support, because it creates a higher floor on the bandwidth required for distribution. In practice, it might mean that we need to increase the throughput (number of blobs) gradually, as networking optimizations allow for higher peer counts, perhaps even through the introduction of a lighter type of sampling peer with very limited overhead.\nNote, however, that we can likely scale PeerDAS close to its theoretical limit from day 1, if we are comfortable with relying on there being a small number of honest supernodes or partial supernodes, i.e., nodes that custody more than the required minimum or even all of the data. More generally, a more realistic understanding how far we can scale peer sampling requires taking into account the heterogeneity of the nodes on the network, which affects the amount of data they are willing to custody and serve. In a very heterogenous network, we can get away with much lower peer counts for average nodes. As already anticipated, in the following I am going to assume that NUM_COLUMN_SUBNETS = 32, CUSTODY_REQUIREMENT = 1 are in practice a viable set of parameters.\nTradeoff between subnet sampling and peer sampling\nBy subnet sampling, we mean setting CUSTODY_REQUIREMENT high enough that the distribution phase already gives certain security guarantees, before even getting to peer sampling (or indeed without peer sampling at all, as is the case in SubnetDAS). In particular, we get the guarantee that only a small percentage of nodes will receive all data on the subnets they are participating in, if less than 50% of all columns are available. In other words, even in the distribution phase, only a small percentage of nodes can be tricked into thinking that unavailable data is available.\nHere, what “small percentage” means very much depends on CUSTODY_REQUIREMENT. For example, say the adversary makes columns [0,59] available, slightly less than half. With CUSTODY_REQUIREMENT = 1 and NUM_COLUMN_SUBNETS = 32, honest nodes in the first 15 subnets would receive all sidecars and vote for the associated block, so almost 1/2 of all honest voters would at first vote for an unavailable block. Generally, even a naive adversary can easily trick 2^{-k}2−𝑘 of all honest nodes for CUSTODY_REQUIREMENT = k, so getting any meaningful security from the distribution phase requires CUSTODY_REQUIREMENT to be at least \\ge 4≥4. This might still not be enough against an adaptive adversary, which chooses exactly which portion of the data to make available by observing the exact distribution of nodes on the subnets, as discussed here. In that case, an upper bound on the fraction of honest nodes which can be tricked for CUSTODY_REQUIREMENT = 4 and NUM_COLUMN_SUBNETS = 128 is roughly 20%. With CUSTODY_REQUIREMENT = 6, this would be less than 10%.\nIn principle, we can always increase CUSTODY_REQUIREMENT and NUM_COLUMN_SUBNETS by the same factor, keeping the same ratio, and thus the same subnet density and the same bandwidth consumption for distribution, while increasing the security guarantees of subnet sampling. There is however a tradeoff with the viability of peer sampling: even if we keep the ratio the same, increasing NUM_COLUMN_SUBNETS means increasing the amount of honest peers that a node needs in order to cover all subnets, because there are more overlaps. At lower peer counts, this might make it hard to support a CUSTODY_REQUIREMENT which gives a meaningful level of security, which has some consequences on the fork-choce and confirmation rule, as we now see.\nFork-choice\nWe need to change the is_data_available function. One possibility is to do the following at slot n𝑛:\n\nTo determine the availability of blob data associated with a block from slot n𝑛, we use the availability of the data in the column subnets we participate in: if we have received all sidecars, we consider the data to be available.\nTo determine the availability of blob data associated with a block from a slot < n<𝑛, we use the peer sampling result: if we have obtained all requested samples, we consider the data to be available.\n\nThis way, the proposer of slot n+1𝑛 +1 has at least 8s (the time between the attestation deadline and the next slot) to perform peer sampling, whereas the attesters of slot n𝑛 just have to receive the block and the associated column sidecars by the attestation deadline, much like with blob sidecars in 4844.\nPossible fork-choice attack vectors\nThe downside of employing this trailing DA filter, while having a low CUSTODY_REQUIREMENT, is that votes on the most recent block cannot be fully trusted, because many honest validators might be tricked into voting for a block whose associated data is unavailable, for the reasons we discussed in the previous section. This would of course only be temporary, as no honest voters would continue voting for such a block in future slots, if the data stays unavailable and peer sampling fails. Nonetheless, some subtle fork-choice attacks are possible, such as this one:\n\nBlob data associated to a block B proposed at slot n𝑛 is released in a targeted way, so as to get many honest attesters to vote for block B even while the blob data is not actually available, exploiting the low CUSTODY_REQUIREMENT.\nThe proposer slot n+1𝑛 +1 does peer sampling, sees that the data is unavailable and proposes a block B’ which does not extend block B.\nThe data associated to block B𝐵 is meanwhile made available, and attesters of slot n+1𝑛 +1 do not vote for B’, because it does not extend B, which is available and has a lot of support from the attesters of slot n𝑛.\n\nTo completely prevent or make this attack harder (requiring the attacker to control more attesters), we can require attesters of slot n+1𝑛 +1 to remember the outcome of peer sampling by some time before the end of slot n𝑛, for example 10s into slot n𝑛, and to use that outcome in their fork-choice at slot n+1𝑛 +1 unless it disagrees with the proposed block. If you are familiar with consensus research for Ethereum, this should remind you of the view-merge technique, although with a lot less complexity because no additional messages are required from the proposer. The downside of doing this is that we tighten the window to perform peer sampling.\nBandwidth requirements\nLet’s say that the target and max bandwidth constraints are the same as with 4844, i.e., we want to on average require the equivalent of 3 blobs per slot, and a max of 6 blobs per slot. With the amplification factor of 8x, this corresponds to a target/max of ~3/63/6 MBs/slot. With MAX_BLOBS_PER_BLOCK = b, let’s consider the max bandwidth consumption for a node participating in the minimum CUSTODY_REQUIREMENT = 1 subnets, each containing four columns:\n\nColumn distribution: since distribution happens through GossipSub topics, it incurs the amplification factor, just like blob subnets in 4844. Each cell is 256/128 = 2256/128 =2 KBs, each column 2b2𝑏 KBs. With MAX_BLOBS_PER_BLOCK = 64, columns are then 128 KBs, so propagation of a column is equivalent to propagation of a blob in 4844. One subnet then takes up four blobs in our budget.\nPeer sampling: the leftover bandwidth budget is the equivalent of two blobs, or 2*128*8 = 20482 ∗128 ∗8 =2048 KBs (factoring in the amplification factor). This is enough for up to k = 2048/128 = 16𝑘 =2048/128 =16 samples, since sampling in PeerDAS is through req/resp, and thus does not suffer from an amplification factor. This gives a soundness of 2^{-16}2−16 when a node is not specifically targeted by the attacker, and otherwise gives the global security guarantee that no attacker could convince more than \\approx 2≈2-33% of the nodes that unavailable data is available (see here and the SubnetDAS post for more explanations). These security guarantees are arguably quite sufficient, and we do not need to sample more.\n\nA few comments:\n\nMAX_BLOBS_PER_BLOCK = 64 is 10x the current throughput of 4844, and it is entirely within the bandwidth budget without requiring a high NUM_COLUMN_SUBNETS, which means we do not need to be particularly concerned about the viability of peer sampling, or too much reliance on sampling providers. A safe path could be to start from an MAX_BLOBS_PER_BLOCK = 32 and gradually scale up to 64 as we are sure that the network can handle the load.\nScaling up to MAX_BLOBS_PER_BLOCK = 128 might require increasing NUM_COLUMN_SUBNETS to 64. Supporting this high of a blob count would then likely be highly dependent on the presence of many supernodes in the network, and/or require supporting much higher peer counts.\nAt this point, distribution and sampling contribute similarly to the bandwidth load. The impact of sampling can be reduced if we increaseNUM_COLUMNS, e.g., NUM_COLUMNS = 512 means sampling consumes half a blob with MAX_BLOBS_PER_BLOCK = 64 and one blob with MAX_BLOBS_PER_BLOCK = 128, 8x less than distribution. If we’re ok with a 50% bandwidth increase from 4844, up to a max of 9 blobs, this is already enough to support MAX_BLOBS_PER_BLOCK = 128 without increasing NUM_COLUMN_SUBNETS. Moreover, the bandwidth used by sampling can be made sublinear in the throughput (and effectively negligible) by moving to the 2D construction. This leaves distribution as the ultimate bottleneck, scaling linearly with data throughput (for a minimum subnet density).\n\nNetwork-level validation\nAs seen in PR#3531, we want to be able to perform network-level validation during the distribution phase, without necessarily waiting for the block to arrive. This way, propagation of the block and of sidecars can actually happen in parallel, rather than the latter having to wait for the former. Ideally, we would like to inherit the slashability guarantees of the block, meaning that the proposer (nor anyone else) cannot propagate sidecars that do not match the commitments in the block without double signing, not even to nodes that have not yet received the block. In EIP-4844, the current solution (from the above PR) is to include the relevant kzg_commitment in the blob sidecar, together with a kzg_proof, as well as the block header and an inclusion proof against its body_root, showing that kzg_commitment is indeed contained in the blob_kzg_commitments list in the block body. This way, verification just involves checking the kzg proof, which ensures that kzg_commitment matches the blob, and the inclusion proof. Slashability guarantees are inherited from the header.\nHere we can follow a very similar strategy, aiming to distribute headers, commitments and inclusion proofs separately from the block. We can adapt the current approach for blob sidecars to column sidecars, i.e., to the objects which are distributed on column subnets. In this case, each column sidecar needs to contain all of the commitments, because they’re all necessary to its verification. It would also contain the header, an inclusion proof, proving the inclusion of hash_tree_root(blob_kzg_commitments) in body_root (i.e., inclusion of the whole list of commitments, rather than of a specific one. This proof has depth 4), and all cell proofs for the column. The commitments and proofs can then be used to batch-verify the column.\nThe advantage of this approach is that a column sidecar has no external dependencies, and can therefore be verified and forwarded as soon as received, meaning that the propagation a of block and the associated columns can truly happen in parallel. For the same reason, sampling can begin immediately, without waiting for the block or for other column sidecars to arrive.\nThe disadvantage is that header, inclusion proof and commitments are replicated within each column. Though, note that the first two are negligible and that each column only gets an additional 48 bytes per row from the commitments, as well as another 48 bytes per row from the cell proofs. With NUM_COLUMNS = 128, a cell is 2 KBs, so this is roughly a 5% increase in bandwidth. Note also that the inclusion proof only needs to be checked once, not once per column, so the only penalty is really the minor increase in bandwidth.\nTransition\nBeing ready to transition from Stage 1 to Stage 2 mostly requires well understood components, i.e., GossipSub topics (aka subnets), used for distribution, and req/resp between peers, used for sampling. Most of the changes do not require a hard fork, because they are either in the networking or in the fork-choice. The only change which does is increasing the blob count, which could also happen after all of the other changes are already in place, i.e., we could transition from Stage 0 to Stage 1 while still having the 4844 blob count of 3/6, and only later increase this. In practice, we would want to perform the networking and fork-choice changes at a coordination point regardless, so it likely makes sense to have all changes be bundled with a hard fork. Once the first transition to Stage 1 has happened, we are free to gradually increase the blob count in any subsequent hard fork (or with some other mechanism, if desired).\nStage 2: 2D PeerDAS\nData format and distribution\nBlobs are extended both horizontally and vertically. The resulting rectangle is still subdivided into NUM_COLUMNS columns, and samples are now cells, the intersection of rows and columns, as in the Danksharding construction. Nothing changes in the distribution.\nPeer sampling\nSampling still utilizes the same networking building blocks, i.e., discovery of a diverse set of peers, with respect to the subnets they participate in, and req/resp to sample from them. The only difference is in what the requested objects are, i.e., cells instead of columns. Cells come with the accompanying proof, to be verified against the KZG commitment of the respective row.\nBandwidth requirements\nLet’s consider MAX_BLOBS_PER_BLOCK = 256, which would achieve the originally planned Danksharding (max) throughput of 32 MBs/slot, though in practice we would likely gradually increase the blob count to get to this point. At this point, let’s assume we are able to increase NUM_COLUMN_SUBNETS to 64, perhaps because of increased peer counts.\nEach subnet would then contain two columns, each of which weighs 1 MB. Still, a column sidecar would only weigh 0.5 MBs, because it can just contain the first half of the column, while the rest can be reconstructed locally by the receiver. Doing so consists of one FFT of size 2^{14}214 to go from evaluation form to coefficient form, and another FFT also of the same size to recover the evaluation form for the extension (~4ms in arkworks). A column subnet then consumes the equivalent of 8 blobs of bandwidth budget, a small increase from the 6 of 4844. The propagation dynamics are likely somewhat different due to there being fewer, larger objects, though this is something we could easily change by increasing NUM_COLUMNS.\nThe total bandwidth required by sampling is just 2k2𝑘 KBs, because samples weigh only 22 KBs instead of the 2b2𝑏 KBs from the 1D construction. As anticipated, even with k = 75𝑘 =75 (which gives soundness of \\approx 2^{-30}≈2−30), the bandwidth for sampling is therefore essentially negligible compared to what is required by distribution.\nNetwork-level validation\nThe same approach as in Stage 1 works here. Even with the vertical extension, the number of proofs and commitments that needs to be sent along with a column sidecar is in principle unchanged, because both proofs and commitments for the second half of the column can be reconstructed with a linear combination of those for the first half, due to both proofs and commitments being homomorphic. Although, we might choose to still send all proofs to avoid the reconstruction step, in which case a column sidecar would now contain 2b2𝑏 proofs, resulting in 2.5% of additional bandwidth consumption (for NUM_COLUMNS = 128).\nTransition\nBeing ready to transition from Stage 2 to Stage 3 requires an efficient implementation of the 2D cryptography, though this mainly affects the block production process. There is also a small change in peer sampling, as the objects which are exchanged through the req/resp protocol change from columns to cells. In principle, a hard fork is again only required to increase the throughput, because blocks still only contain the same list of KZG commitments, i.e., the ones corresponding to actual blobs and not to extension rows (as already mentioned, we can reconstruct the latter from the former). We would still need all changes to happen at a coordination point, so they would likely still be coupled with a hard fork.\n\n LossyDAS: Lossy, Incremental, and Diagonal Sampling for Data Availability\n\n PeerDAS -- a simpler DAS approach using battle-tested p2p components\n\n DAS fork-choice\n\n Accelerating blob scaling with FullDASv2 (with getBlobs, mempool encoding, and possibly RLC)\n\n Dynamic Blob Sizing: Reducing Zero-Padding Overhead in Small Rollups\n\n 2\n\n 2\n\n read \n\n 10\n min\n\n 4 months later\n\n post by Evan-Kim2028 on Apr 17, 2024\n\n Evan-Kim2028\n\nUnder Stage 1, has there been any research done for how the execution layer will handle this larger amount of blobs in the mempool? Sure data availability sampling will alleviate the consensus layer bandwidth concerns, does the EL get similar alleviation?\nSince EIP-4844 requires execution layer validation, it seems like it is not possible for blobs to circumvent the EL mempool.\n\n post by fradamt on Apr 19, 2024\n\n fradamt\n\n Imho, the blob mempool can either become sharded itself, or (more likely) stay fairly low capacity, with the assumption that most blobs will just not go through it.\n\nNot sure what you mean by this. Even today, a blob never needs to touch the EL mempool in order to get into a block. Just like regular transactions, you can directly send them to a builder (or proposer in principle).\n\n post by Evan-Kim2028 on Apr 19, 2024\n\n Evan-Kim2028\n\nHow does this work?\n\nWhile I think this can be made as a futuristic assumption, it currently does not reflect reality today - 99.99% blobs go through the public mempool today.\n\n post by Athos on Apr 23, 2024\n\n Athos\n\n I find that in the final stage of PeerDAS the peers are also required to sample a whole cell, which is 2KB.\nIs it possible if we request only a single field element and verify it using KZG proof?\nLet the blob be B, its commitment be C, and the cell data be D. We do an interpolation on D and we can get polynomial I. So we have the proof P=(C-I(s))/Z(s), here Z is the zero-polynomial of the interpolation points.\nActually the I(s) is the commitment of cell polynomial I. So we can just use this to to proof that a single field element is in the cell data D by first proofing that it is in I, and then proofing the data D is in the whole blob. We can just providing I(s) instead of providing the whole cell, so that might reduce the network pressure of light nodes.\n\n 23 days later\n\n post by 0x00101010 on May 17, 2024\n\n 0x00101010\n\nDo you mean from Stage 1 to Stage 2 here?\n\n Powered by Discourse","tokens":7353,"squid":"ink-research","role":"Deep Scholar","at":1791263160423,"hash":"508c070ec4310bc58a0551d9ea12ab0a1cf8182f"}
{"url":"https://forum.soliditylang.org/t/diamond-contract-gas-efficiency-challenge/3537/1","domain":"forum.soliditylang.org","title":"Diamond Contract Gas Efficiency Challenge - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Diamond Contract Gas Efficiency Challenge \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by mudgen on Oct 30, 2025\n\n mudgen\n\n The DiamondLoupeFacet.sol implementation in the Compose smart contract library is too gas inefficient. I challenge anyone to write the most gas efficient, sensible code, to implement this.\nSee this issue for details:\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 121\n\n Apr 18\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1114,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263163486,"hash":"96293c762d9c36a851ce47736593b206e3db1126"}
{"url":"https://governance.aave.com/t/apu-mallku-delegate-platform-shutdown/24043/8","domain":"governance.aave.com","title":"Apu Mallku [Delegate platform]: Shutdown 🚩 - Delegate Platforms - Aave","text":"Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 7\n min\n\n Feb 11\n\n 7 / 7\n\n Apr 13\n\n Apr 12\n\n post by ApuMallku on Feb 11\n\n ApuMallku\n\n Hello Aave Community. I’m Apu Mallku (apumallku.eth). My journey with this protocol didn’t start yesterday; it began in late 2017, as an early participant in the EthLend ICO. I have been here since before Aave was even Aave.\n\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nDune: https://dune.com/apumallku/aave\n\nWhen the foundation of DeFi was being built in early 2020, I was there for the launch of Yearn Finance, taking my first steps in yield farming and eventually serving as Partnership Lead for prominent DeFi projects—initiatives that became the original “Blue Chips” of the DeFi Summer. My professional background in partnership growth has given me a front-row seat to how protocols scale, how they fail, and how they are often captured by misaligned interests.\nFor years, I have been a silent observer—watching from the sidelines, analyzing the shifts in governance power, and voting with my own conviction. But the current state of Aave has reached a tipping point where silence is no longer an option. Now is the time to act. Aave doesn’t need more “Governance-as-a-Service” corporate delegates. It needs fiercely independent, veteran voices who aren’t afraid to speak the truth. We are witnessing a slow drift toward corporate capture, where institutional delegates often remain silent on critical issues like conflict of interest or Service Provider (SP) monopolies.\nEncouraged by the support of independent voices and active contributors, I am formalizing my role as a Delegate. My goal is simple: I am here to ask the hard questions, protect the protocol from centralization, and return the focus to where it belongs—the utility and value of the AAVE token.\n Core Values & Ethos\nMy governance philosophy is deeply rooted in free-market dynamics and strict decentralization. My recent track record in the forum reflects this:\nAnti-Monopoly & True Decentralization: A DAO should foster competition, not monopolies. I stand against the consolidation of power by a few whale wallets or aggregate SPs. Aave must remain sufficiently decentralized, not just for ethical reasons, but to mitigate existential regulatory risks (e.g., SEC scrutiny).\nMeritocracy & Accountability: Funding should be based on performance, not legacy status. I advocate for clear KPIs, Conflict of Interest (COI) frameworks, and bounty-based models to ensure every AAVE/GHO spent by the Treasury delivers undeniable value.\nIP Sovereignty & Open Innovation: Aave must be an ecosystem that empowers third-party builders, not one that leaves them behind due to legal or branding bottlenecks created by centralized off-chain entities.\nIndependent Over Institutional: I do not run a governance factory, and I am not looking to appease any corporate partners. I represent the raw, free-market ethos of DeFi. I will always favor transparency over political correctness. If a proposal is bad for the DAO but good for an insider group, I will publicly call it out.\n Key Priorities\nIf you delegate your voting power to me, these are the pillars I will aggressively pursue:\nMaximize AAVE Token Power & Utility: The AAVE token must be the ultimate beneficiary of the protocol’s success. I will support and champion initiatives that drive value accrual to the token, enhance its utility within the ecosystem (like GHO dynamics), and ensure that holders are rewarded for their risk.\nRuthless Treasury Stewardship: The DAO’s treasury is not an ATM for Service Providers. I will scrutinize budget renewals, demand transparency, push for mandatory disclosures, and vote strictly against any proposal where a clear conflict of interest compromises the DAO’s financial health.\nAggressive Ecosystem Growth: I will enthusiastically support all growth initiatives that scale Aave’s dominance safely—such as listing new resilient assets, deploying on promising L2s, and expanding GHO adoption—provided they adhere to strict risk management standards.\n Disclosures & Conflict of Interest\nIn the spirit of the transparency I demand from others:\nI am an independent DeFi participant. I am not currently employed by, nor do I receive a salary from, any Aave Service Provider.\nI hold positions in AAVE, ETH and SKY but Aave remains my primary governance focus.\n How to Delegate\nIf you share this vision of a decentralized, free-market-driven, and highly efficient Aave, I invite you to delegate your AAVE / stkAAVE to my address. It is time to make our voices heard and protect the protocol we all helped build.\nENS: apumallku.eth\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nLet’s build a stronger, truly decentralized Aave.\n\n How AAVE will win\n\n [TEMP CHECK] The AAVE Utility Renaissance: Aligning Protocol Success with Token Holder Value\n\n read \n\n 7\n min\n\n 14 days later\n\n post by ApuMallku on Feb 25\n\n ApuMallku\n\n Date Voted: February 25, 2026\n\n SNAPSHOT\n1. Proposal: [TEMP CHECK] Aave Will Win Framework\n\nVote: NAY\n\nRationale: This vote was rushed and it shows. I welcome Labs opening a dialogue — but that’s all this is: a dialogue starter, not a finished product. The most relevant service provider in the entire ecosystem has failed to answer a single sensitive question raised by the community before pushing this to Snapshot. That is unacceptable. A proposal with this name carries enormous expectations. At minimum, it should have contained concrete proposals around AAVE token utility and explicit, tangible benefits for token holders. Instead, we got silence on the hard questions and a Snapshot vote. Ghosting the community while forcing a governance pulse is not leadership — it’s pressure. Not good enough.\n\n2. Proposal: [ARFC] Aave v3.7 Candidate\n\nVote: YAE\n\nRationale: BGD Labs has consistently delivered. This proposal is technically sound, well-structured, and follows the proper governance process. Aave v3.7 is the right next step for the protocol’s technical evolution. I support moving forward.\n\n ON-CHAIN\n3. Proposal: Focussing the Aave V3 Multichain Strategy – Phase 1\n\nVote: YAE\n\nRationale: Freezing low-activity V3 markets is a prudent and necessary risk management decision. ACI has presented a clear case, the proposal is well-scoped, and it aligns with the long-term health of the protocol. I vote in favor.\n\n4. Proposal: Create Allowance GHO Mantle\n\nVote: NAY (human error)\n\nRationale: My NAY vote here was a human error — I intended to vote YAE. TokenLogic’s proposal to create an aEthLidoGHO allowance for the Aave Liquidity Committee is sound and consistent with GHO’s liquidity strategy. I’m documenting this publicly because transparency is the standard I hold others to. I hold myself to the same standard.\n\n5. Proposal: February 2026 – Funding Update\n\nVote: YAE\n\nRationale: Transparent, well-structured, and straightforward. Maintaining the DAO’s runway and ensuring clear traceability of funds is non-negotiable for a healthy protocol. TokenLogic delivers consistently. I support this without reservations.\n\n post by ApuMallku on Mar 5\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\nENS: apumallku.eth\n\nYour support allows me to continue defending the interests of the community and ensuring Aave remains the premier liquidity protocol in DeFi.\n\n Voting Activity Report\n6. [Snapshot] [ARFC] Deploy Aave v3 on X Layer\nDecision: FOR\nRationale: We support the deployment on X Layer as part of Aave’s multichain expansion. By integrating with OKX’s ecosystem, Aave can tap into a significant source of retail liquidity and onboard a new demographic of users. This move strengthens the protocol’s position as the leading liquidity provider across all relevant EVM networks, driving more value to AAVE holders through diversified revenue streams.\n7. [Snapshot] [TEMP CHECK] Deploy Aave Protocol on Monad\nDecision: FOR\nRationale: Monad’s high-throughput architecture is one of the most anticipated technological leaps in the EVM space. Voting FOR ensures that Aave remains at the forefront of innovation. Being a first-mover on Monad allows the protocol to capture early TVL and establish itself as the foundational lending layer for a high-frequency DeFi ecosystem, which is essential for long-term growth.\n8. ACI is Leaving Aave\nDecision: YAE\nRationale: This is a historic and difficult vote for our platform. I am voting YAE, but I want to be clear: I never imagined having to vote for the decoupling of the Aave Chan Initiative (ACI) from the DAO.\n\nTransition over Disruption: While the departure of such a key contributor is a loss, we must prioritize the protocol’s operational continuity. This vote facilitates a structured 120-day wind-down, which is the most responsible path to prevent governance instability.\n\n post by ApuMallku on Mar 9\n\n ApuMallku\n\n 9. [Snapshot] [ARFC] Safety Module - Reduce Emissions\nDecision: NAY\nRationale: I have voted NAY on the proposal to reduce emissions for the Safety Module. While I understand the DAO’s goal of fiscal optimization, my stance is clear: Putting AAVE Token Holders First means not stripping away incentives before a superior alternative is functional.\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n 8 days later\n\n post by ApuMallku on Mar 17\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nI want to start by expressing my deepest gratitude to all the delegates who, week after week, entrust me with their voting power to represent them in the Aave DAO. Your support is the engine of this platform. To celebrate our growth and enhance transparency, I have created a Dune Dashboard where you can track the evolution and impact of the Apu Mallku platform in real-time: dune.com/apumallku/aave.\n\n Voting Activity Report\n10. [Snapshot] [TEMP CHECK] Aave V4 Bug Bounty Program on Sherlock\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: Security is the non-negotiable foundation of Aave. I voted FOR establishing this bug bounty program on Sherlock. As we prepare for the transition to V4, incentivizing top-tier white-hat hackers to stress-test the code is the most cost-effective insurance policy for the DAO. This directly protects AAVE holders from potential exploit risks during the next major protocol upgrade.\n11. [Snapshot] [ARFC] Buyback Program - Budget Adjustment\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: I support this budget adjustment for the Buyback Program. Optimizing the DAO’s treasury to strategically accumulate AAVE from the market aligns protocol revenue with token value. This mechanism creates a healthy feedback loop: as the protocol succeeds, the DAO increases its stake in its own future, reducing circulating supply and rewarding long-term holders.\n\nStrategic Execution: While I agree with the proposal, I believe the buyback should be optimized based on market conditions. If the token is undervalued, the DAO should execute larger orders.\nBeyond DCA: In my view, a simple DCA (Dollar Cost Averaging) strategy is not the correct approach and never has been; we need a more opportunistic execution model to maximize value for the treasury.\n\n12. [Snapshot] [TEMP CHECK] Aave V4 Licensing\nDecision: FOR\nVoting Power: 1,206.42 AAVE\nRationale: Protecting Aave’s intellectual property is vital for maintaining our competitive advantage. I voted FOR the V4 licensing framework to ensure that while we remain open-source in spirit, the DAO retains control over how its innovations are commercialized by third parties. This prevents “vampire attacks” and ensures that the value created by Aave Labs and the DAO stays within the Aave ecosystem.\n\n On-chain Votes (Chronological Order)\n13. [On-chain] Activate Capo Risk Agent and expand Rates Agent\nDecision: YAE\nVoting Power: 1,206.42 AAVE\nRationale: I voted YAE to expand our automated risk management capabilities. Activating these agents allows for more dynamic, data-driven parameter adjustments across multiple networks, scaling safety without manual bottlenecks.\n14. [On-chain] Enhancing Market Granularity in Aave 3.6: part 2\nDecision: MISSED (Operational Error)\nVoting Power: N/A\nRationale: Regarding this vote, I unfortunately missed the execution window due to an operational error. I want to be fully transparent: I have already taken the necessary technical measures and updated my monitoring workflows to ensure this does not happen again. Reliability is my top priority.\n15. [On-chain] Gho X-Layer Activation\nDecision: YAE\nVoting Power: 6,993.74 AAVE\nRationale: Following our support for the X-Layer deployment, I voted YAE for the official activation of GHO on this network. This increases GHO’s utility within the OKX ecosystem and drives more interest income back to the DAO treasury.\n16. [On-chain] wstETH CAPO Oracle Incident User Reimbursement\nDecision: YAE\nVoting Power: 6,993.74 AAVE\nRationale: Accountability is key to maintaining trust. I voted YAE to reimburse users affected by the wstETH CAPO oracle incident. Ensuring that users are made whole after a technical failure is essential for Aave’s reputation as a premium, secure protocol.\n\nAdvocacy for Clarity: I was very vocal regarding this issue, actively seeking answers and trying to understand exactly what happened.\n\nBridging the Gap: Most forum posts were overly technical, leaving non-technical community members lost in jargon. In the future, I want to see better documentation regarding risk management workflows that is accessible to everyone.\n\nWorkflow Support: I fully support the initiative to incorporate LlamaRisk into these workflows to enhance our collective oversight.\n\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n 23 days later\n\n post by ApuMallku on Apr 10\n\n ApuMallku\n\n If you value a governance approach that prioritizes transparency, protocol safety, and long-term value for AAVE token holders, I invite you to delegate your voting power to my address:\nAddress: 0x086b62a858d5363820ee5249bf9c6078341c8f85\nYou can track the evolution and impact of the Apu Mallku platform in real-time: dune.com/apumallku/aave.\n Voting Activity Report\nSnapshot votes\n\nDate\nProposal\nDecision\nRationale\n\nMar 21\n[ARFC] Aave <> Chainlink SVR. Multi-network expansion\nFOR\nExpanding the Savings Rate across networks is a highly strategic move for capturing yield and improving composability. I support this expansion to maximize our multichain presence, provided we maintain our strict standards for cross-chain oracle security.\n\nMar 23\n[ARFC] Aave V4 Activation on Ethereum Mainnet\nFOR\nV4 is a vital architectural leap for Aave’s future. I voted FOR to fully support this technical upgrade, while maintaining my collaborative view that we must continue refining our governance frameworks to ensure token holders are fully aligned with this new phase.\n\nMar 27\n[ARFC] Bug Bounty Program on Sherlock\nFOR\nA robust security infrastructure is non-negotiable for a protocol of our size. I fully support leveraging competitive audit models to protect the ecosystem, ensuring that treasury funds are efficiently allocated to maximize technical resilience.\n\nMar 29\n[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance\nFOR\nExpanding stablecoin diversity on new high-performance instances like Sonic is a positive step for market capture. Supported with the recommendation that initial supply caps remain appropriately conservative during the network’s bootstrap phase.\n\nMar 29\n[ARFC] Aave V4 Licensing\nFOR\nProtecting Aave’s intellectual property is essential to ensure that the value created by the DAO and its contributors stays within the ecosystem. I voted FOR to establish a framework that defends our innovations while still fostering collaborative growth.\n\nAbr 03\n[ARFC] Update Signers and SAFE Configuration\nFOR\nRoutine housekeeping is necessary for smooth operations. Approved to maintain current decentralized threshold standards, while I look forward to encouraging continued rotation and separation of duties among service providers in the future.\n\nAbr 03\n[ARFC] sGHO Launch Configuration\nFOR\nThe deployment of sGHO is a strong, positive step for our stablecoin ecosystem. Supported with the recommendation that we closely monitor organic market demand to ensure sustainable yield growth alongside our treasury strategies.\n\nAbr 04\n[ARFC] Aave Will Win Framework\nFOR\nI support the vision and the alignment of branded product revenue directly to the treasury. I voted FOR to enable these structural improvements, and I look forward to working together with the community on further enhancing AAVE token utility prior to the AIP execution.\n\nAbr 05\n[ARFC] Onboard PT-USDG-28MAY2026\nFOR\nIntegrating fixed-rate primitives is an excellent way to safely expand our multichain footprint. Approved with the expectation that supply caps remain conservatively managed while the oracle infrastructure scales gracefully.\n\nAbr 06\n[ARFC] Continued Deprecation of V2 Markets\nFOR\nSunsetting legacy markets is an essential step for technical efficiency and optimal resource allocation toward V4. I fully support these deprecation steps to encourage a smooth and safe capital migration for all users.\n\n On-chain Votes (Chronological Order)\n\nDate\nProposal\nDecision\nRationale\n\nMar 24\nReduce Safety Module Emissions\nYAE\nOptimizing treasury emissions is key for our long-term sustainability. I support this reduction to ensure we remain capital-efficient while fairly rewarding participants who are aligned with protocol growth.\n\nMar 29\nAave V3.6 XLayer Activation\nYAE\nExpanding our ecosystem to XLayer is a strategic priority.\n\nMar 29\nEnable SVR on Base and Arbitrum\nYAE\nDeploying the Savings Rate to L2s significantly strengthens our cross-chain composability. Voted YAE to support this expansion, highlighting the need for robust and continuous oracle synchronization.\n\nMar 30\nOnboard BTC.b to Aave V3 Core\nYAE\nWhile there is clear market demand for Bitcoin exposure, we must carefully manage the technical nuances of bridged assets. Voted YAE, fully supporting the conservative supply caps and risk mitigation parameters.\n\nMar 30\nAave V4 Activation on Ethereum\nYAE\nThe Hub-and-Spoke model is a remarkable achievement in capital efficiency, and I voted YAE to activate it on-chain. While I maintain that the governance friction surrounding the ‘Aave Will Win’ framework should have been fully resolved prior to launching such a critical upgrade.\n\nApr 06\nListing PT Ethena 18JUN2026\nYAE\nPendle integrations offer excellent benefits for our users. Voted YAE, appreciating that the supply caps have been carefully calibrated by risk providers to safely match the asset’s specific liquidity profile.\n\nApr 07\nMarch Funding Update\nYAE\nEnsuring our contributors are funded is essential for uninterrupted protocol operations. Voted YAE, and I look forward to collaborating on transitioning toward more milestone-based reporting and streaming models moving forward.\n\nApr 07\nListing PT Strata 25JUN2026\nYAE\nAnother strong addition to our yield tokenization offerings. Voted YAE with confidence in the conservative borrowing power parameters that responsibly manage the underlying duration risk.\n\nApr 07\nUmbrella Deficit Updates\nYAE\nMaintaining a fully capitalized safety layer is paramount for depositor trust. Voted YAE to resolve these deficits promptly, emphasizing our shared commitment to continuous improvement in risk modeling.\n\nApr 08\nCollateral Parameters MegaETH v3\nYAE\nOptimizing parameters for new deployments is a healthy part of our growth & security scrutinity.\n\nApr 09\nAave Will Win: Primary Funding\nYAE\nI voted YAE to move the framework into execution, prioritizing protocol progress over perfection. While I would have strongly preferred the foundation’s consolidation and comprehensive disclosures to be fully finalized beforehand, operationalizing our revenue capture is too critical to delay. Now that the resources are deployed, we must advance together and ensure these accountability measures deliver long-term value to the DAO.\n\n Delegate to Apu Mallku\nIf you want a delegate who protects your staking yield and demands technical readiness before making radical changes, delegate your AAVE to:\n\nAddress: 0x086b62A858D5363820EE5249bF9c6078341c8F85\n\n post by ApuMallku on Apr 12\n\n ApuMallku\n\n I want to express my deepest gratitude to everyone who trusted me and delegated their voting power to my platform.\nFollowing the recent discussions around the Aligned Delegates Framework (ADF), it has become clear that without the crucial support and alignment from Labs, advancing this vision is an uphill battle. Since the protocol’s current direction doesn’t align with my thesis on professionalizing the governance layer, I have decided to officially sunset my delegate platform.\nThis is not a goodbye, but a see you later.\nTo my delegators: please remember to redelegate your voting power to other active delegates to keep our governance healthy and decentralized. Thank you for the opportunity to build together.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Phenk53.eth Delegate Platform\n\n Delegate Platforms\n\n 13\n\n 746\n\n Jan 9\n\n Notrustverify.ch Delegate Platform (sunsetted)\n\n Delegate Platforms\n\n 14\n\n 897\n\n Mar 23","tokens":5556,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263166764,"hash":"613eca37c9a4f513379363bddca1bcbafcbb6a24"}
{"url":"https://ethresear.ch/c/networking/27","domain":"ethresear.ch","title":"Latest Networking topics - Ethereum Research","text":"Latest topics in Networking\n\n Networking\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Networking category\n\n 0\n\n 1.3k\n\n Feb 2019\n\n Snappy with a memory: ~40% less gossip traffic\n\n single-slot-finality\n\n 1\n\n 151\n\n 11d\n\n EIP-8411 payload segmentation under the Shadow simulator\n\n p2p,scaling\n\n 0\n\n 79\n\n 13d\n\n Wen fast payload broadcast? Segment, code, push, pull, and everything in between\n\n p2p\n\n 5\n\n 245\n\n 19d\n\n EIP-8411: what segmented payload diffusion is made of\n\n p2p,scaling\n\n 0\n\n 226\n\n 19d\n\n RowDAS (EIP-8371): Distributed Blob Reconstruction, measured\n\n data-availability,p2p\n\n 0\n\n 244\n\n 24d\n\n Recursive-STARK-based bandwidth-efficient mempool\n\n 1\n\n 1.5k\n\n Jul 31\n\n SPREAD: Extending GossipSub with Efficient Anonymous Dissemination\n\n p2p,networking\n\n 4\n\n 286\n\n Jul 16\n\n AetherWeave: stake-backed peer discovery for Ethereum\n\n 5\n\n 176\n\n May 25\n\n EL peer composition drifts on a fixed software baseline: two-week comparison on a 36-node fleet\n\n 0\n\n 47\n\n May 12\n\n Block & Blob Propagation with PeerDAS\n\n 1\n\n 419\n\n May 12\n\n RLNC Optimizations  ethereum.org\n\n 2\n\n 266\n\n Mar 23\n\n Faster block/blob propagation in Ethereum\n\n 54\n\n 6.8k\n\n Feb 6\n\n Selecting Optimal Outbound Neighbors (SOON) for fast, bandwidth‑efficient propagation in P2P networks\n\n p2p\n\n 0\n\n 482\n\n Oct 2025\n\n Gossipsub’s Partial Messages Extension and Cell Level dissemination\n\n data-availability\n\n 2\n\n 603\n\n Sep 2025\n\n Improving column propagation with cell-centric erasure/network coding\n\n data-availability\n\n 3\n\n 633\n\n Jul 2025\n\n The paths of least resistance: Introducing WFR-Gossip\n\n p2p\n\n 2\n\n 736\n\n Jun 2025\n\n Behind the Scenes of Ethereum’s Pectra Upgrade: A Data-Driven Analysis\n\n p2p\n\n 0\n\n 572\n\n Jun 2025\n\n Post-Pectra in Practice: A Public Dashboard for Real-World P2P Metrics\n\n 4\n\n 746\n\n Jun 2025\n\n Impact of IDONTWANT in the number of duplicates\n\n 0\n\n 230\n\n Jun 2025\n\n Accelerating blob scaling with FullDASv2 (with getBlobs, mempool encoding, and possibly RLC)\n\n data-availability,p2p,layer-2,scaling\n\n 0\n\n 568\n\n May 2025\n\n Empirical blob sidecar hit rate based on local EL’s mempool\n\n data-availability\n\n 0\n\n 273\n\n May 2025\n\n Is Data Available in the EL Mempool?\n\n data-availability,p2p,scaling\n\n 2\n\n 565\n\n May 2025\n\n Robust Distributed Arrays – Probably Secure Networking for DAS\n\n data-availability\n\n 0\n\n 273\n\n May 2025\n\n Theoretical blob transaction hit rate based on the EL mempool\n\n data-availability\n\n 6\n\n 484\n\n Apr 2025\n\n Improving DAS performance with GossipSub Batch Publishing\n\n data-availability,p2p\n\n 10\n\n 994\n\n Apr 2025\n\n PPPT: Fighting the GossipSub Overhead with Push-Pull Phase Transition\n\n data-availability,p2p\n\n 4\n\n 458\n\n Apr 2025\n\n Status Update: `IDONTWANT` Message Adoption on Ethereum Mainnet\n\n p2p,scaling\n\n 1\n\n 436\n\n Apr 2025\n\n Doubling the blob count with Gossipsub v2.0\n\n data-availability,p2p,scaling\n\n 12\n\n 2.2k\n\n Apr 2025\n\n The Unreasonable Effectiveness of Relay-Based DAS\n\n mev,data-availability,rollup,p2p,scaling\n\n 3\n\n 679\n\n Mar 2025","tokens":753,"squid":"ink-research","role":"Deep Scholar","at":1791263170883,"hash":"db5df6e6d3dd8ab406bdd34c9cceb0c058dafe2c"}
{"url":"https://forum.soliditylang.org/t/diamond-contract-gas-efficiency-challenge/3537","domain":"forum.soliditylang.org","title":"Diamond Contract Gas Efficiency Challenge - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Diamond Contract Gas Efficiency Challenge \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by mudgen on Oct 30, 2025\n\n mudgen\n\n The DiamondLoupeFacet.sol implementation in the Compose smart contract library is too gas inefficient. I challenge anyone to write the most gas efficient, sensible code, to implement this.\nSee this issue for details:\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 121\n\n Apr 18\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n [Call for feedback] Core Solidity Deep Dive\n\n Uncategorized\n\n 5\n\n 613\n\n Dec 2025\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1117,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263173627,"hash":"ca8e475a9e52092de5d0fc69047b791e6117be3c"}
{"url":"https://governance.aave.com/t/ezr3al-delegate-platform/14740","domain":"governance.aave.com","title":"EzR3aL Delegate Platform - Delegate Platforms - Aave","text":"EzR3aL Delegate Platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 1 / 44\n\n Sep 2023\n\n Jun 30\n\n post by EzR3aL on Sep 3, 2023\n\n EzR3aL\n\n Regular\n\n Key Info\n\nDelegate Address: ezr3al.eth (0x8659d0bb123da6d16d9394c7838ba286c2207d0e)\nTelegram: @EzR3aL\nDiscord: ezr3al\nTwitter: https://twitter.com/DeFi_EzR3aL\n\nIntroduction\nHey folks! Some of you might already know that I’ve been a big fan of Aave for quite a while now, and I’m an active participant in this governance forum, snapshots and AIPs. My journey started back in May 2017 when Stani was on the hunt for some help with EthLend, a few months before it hit the mainnet. Since then, I’ve been all in on DeFi, especially Aave.\nWhy You Should Delegate to Me\nFirst off, it’s just me here – no fancy service provider or big institution. I’m just another Aave holder, like many of you. The thing that sets us apart is that I’m really active in this community, and I’m eager to help more people get into the governance game and make the tough stuff easier to understand. I get it; for a lot of folks, voting on every AIP can be a bit pricey. That’s where you come in. I’m asking for your delegation so I can vote on your behalf and make your voice heard in these important governance decisions.\nWhat Voters Can Expect from Me\nHere’s what you can count on from me:\n\nI’ll vote in a way that reflects the interests of Aave holders like you.\nI’ll work to make the governance process even more decentralized.\nI’ll do my best to break down complex topics into easy-to-digest info.\n\nSome Closing Thoughts\nJust to be clear, I’m not connected to any individuals or organizations, and I’m not getting paid by anyone for this. This is a one-person gig. I’m doing it because I believe it’s time to get more people involved, even if you only have 1 Aave in your wallet. By starting this delegation platform, I hope we can get more Aave holders engaged, either by delegating to me or, even better, by voting themselves in the future.\nSo, let’s kick this off. Cheers! \n\n 40\n\n read \n\n 26\n min\n\n post by eboado on Sep 4, 2023\n\n eboado\n\n Regular\n\n Really nice to see community members like @EzR3aL, who have been active in this forum (and the whole Aave) since the beginning, stepping up and creating delegate platforms.\nBest of luck @EzR3aL and highly recommended to delegate!\n\n post by Hazbobo on Sep 4, 2023\n\n Hazbobo\n\n Excited to see this delegate platform! Would encourage people to delegate, EzR3al has proven themselves to be a dedicated community member who cares deeply about Aave and has informed opinions about the protocol!\n\n post by OzBorg on Sep 4, 2023\n\n OzBorg\n\n Guess what? I’m totally in for an awesome ride with our buddy Ezr3al’s initiative!\nbest of luck buddy.\nXBorg community definitely supports you !!\n\n post by JosepBove on Sep 6, 2023\n\n JosepBove\n\n Best of luck, definitely someone worth delegating to!\n\n post by EzR3aL on Sep 7, 2023\n\n EzR3aL\n\n Regular\n\n Hello all,\nfirst of all i want to thank you all for the support in terms of kind words, already received delegations and likes.\nI will from now on use this post to document my voting decisions.\nAgain, thank you everybody!\n\n post by EzR3aL on Sep 10, 2023\n\n EzR3aL\n\n Regular\n\n Reserve Factor Updates - Polygon Aave v2\nVote: YES\nRationale: v3 is up and running, people should be encouraged to migrate\nSigma Prime Audit Budget Extension\nVote : YES\nRationale: Security is simply important and we shouldn’t save on this\nSupplyCapLSTs\nVote: YES\nRationale: LSTs are important in terms of fees and there is demand\nChaos Labs Risk Parameter Updates\nVote: YES\nRationale: v3 is up and running, people should be encouraged to migrate\nQuarterly Gas Rebate Distribution August 2023\nVote: YES\nRationale: Delegates represent a lot holder and their decisions, reimbursing their costs only makes sense\nAURA OTC Deal\nVote: YES\nRationale: Helping to stabilize GHO peg\nFreeze MAI/MIMATIC, set LTV → 0 for Arbitrum, Avalanche, Polygon, Optimism v3\nVote: YES\nRationale: MIMATIC already had depegging events, so mitigating risk makes sense to protect user and the protocol\n\n post by EzR3aL on Sep 18, 2023\n\n EzR3aL\n\n Regular\n\n Freeze Stewards\nVote: YES\nRationale: Aave V3 already has a steward to mitigate risk, implementing it on other chains only makes sense.\nChaos Labs Risk Parameter Updates _ Aave V3 Ethereum\nVote: YES\nRationale: Monitoring and adjusting parameters is important for a healthy ecosystem\nGauntlet recommendation to set MAI/MIMATIC isolated debt ceiling to 0 for Arbitrum, Avalanche, Polygon, Optimism v3\nVote: YES\nRationale: Logical next step after freezing the asset\nAave V3 Ethereum MKR Debt Ceiling Update\nVote: YES\nRationale: Some user weren’t able to migrate to V3 because of the deb ceiling. This further incentives people moving from V2 to V3.\nGHO Borrow Rate Update\nVote: YES\nRationale: Necessary step to get GHO to 1$ peg\n\n post by EzR3aL on Sep 24, 2023\n\n EzR3aL\n\n Regular\n\n Rescue Mission Phase 2, 3\nVote: YES\nRationale: Its helping to recover lost funds, definitely gonna support this one.\nAave <> Immunefi program activation\nVote: YES\nRationale: Security is as always important and needed, Aave is the benchmark for this and shall be in the future.\nCRV Aave V2 Ethereum LT Reduction\nVote: YES\nRationale: Mitigate risk, incentivise people to move to V3\n\n 14 days later\n\n post by EzR3aL on Oct 8, 2023\n\n EzR3aL\n\n Regular\n\n Gauntlet recommendation to set WETH slope 1 to 3.3% on v3 markets, excluding Ethereum v3\nVote: None\nRationale: Missed this voting unfortunately\nReserve Factor Updates - Polygon Aave v2\nVote: YES\nRationale: incentivise people to move to V3\nTokenLogic Service Provider Proposal\nVote: YES\nRationale: TL has proved themselves to be a great fit for the DAO\nTreasury Management - Create AGD GHO Allowance\nVote: YES\nRationale: Pushing GHO into other DAOs is the first step to get GHO recognized and being used\nAave treasury RWA Allocation Part I\nVote: YES\nRationale: Curious to see Aave stepping into RWA with a small amount, lets see what this will bring in the future in terms of revenue/risk\nExpansion of Orbit\nVote: YES\nRationale: Supporting other delegates is important, especially the ones helping to improve Aave\nTreasury Management - Polygon v2 to v3 Migration\nVote: YES\nRationale: support and push V3, use funds for payments and much more\nTUSD Offboarding Plan Part II\nVote: YES\nRationale: Mitigate risk\nOP Risk Parameters Update\nVote: YES\nRationale: Open OP for the market to borrow\n\n 14 days later\n\n post by EzR3aL on Oct 23, 2023\n\n EzR3aL\n\n Regular\n\nAdd DebtSwapAdapter as FlashBorrower\nVote: YES\nRationale: feature to perform debt swaps without needing to pay additional fees, which is great.\n\nGauntlet Recommendations to Lower stMATIC/MaticX …\nVote: YES\nRationale: Risk adjustments for LST\n\nGauntlet Recommendations to Lower WETH Variable B…\nVote: YES\nRationale: Risk adjustments for LST & aligning settings for WETH on all chains, potential additional revenue\n\nv2 Deprecation Plan, 2023.10.03\nVote: YES\nRationale: Pushing V3 is the goal\n\nSTG onboarding on AaveV3 Ethereum Market\nVote: YES\nRationale: Additional revenue for the protocol, new token for user overall improving the protocol.\n\nFund GHO Liquidity Committee\nVote: YES\nRationale: Very important one for the future of GHO, this is the first step into getting GHO to peg, recognized by way more user and establishing a real decentralized stablecoin.\n\nKNC onboarding on AaveV3 Ethereum market\nVote: YES\nRationale: Additional revenue for the protocol, new token for user overall improving the protocol.\n\nGovernance V3 Activation\nVote: YES\nRationale: V3 would have been the biggest change for governance for years, due to some problem the AIP has been cancelled and delayed a few weeks.\n\nTokenLogic Hohmann Transfer\nVote: YES\nRationale: Adding TokenLogic to the Orbit programm is a no brainer, they have been very active towards the DAO especially with pushing GHO.\n\nGHO Funding\nVote: YES\nRationale: Using GHO to pay for the DAO expenses is showing the willingness of everybody involved to push GHO further and give it strength\n\nEnable borrow of OP token\nVote: YES\nRationale: Adjustment of the OP token to enable borrowing\n\nFuther Increase GHO Borrow Rate\nVote: YES\nRationale: Even if changing rates frequently isn’t great, it is needed to get GHO to peg. Especially because of sDAI and its 5%, its giving pressure to token like GHO.\n\nEvents Funding\nVote: YES\nRationale: The Aave companies are attending different events which need to be visited to be and stay visible to the community. For the future I would like to see a recap of those events and their costs in total. Quarterly reports would be sufficient imo.\n\n 20 days later\n\n post by EzR3aL on Nov 12, 2023\n\n EzR3aL\n\n Regular\n\nPrices operational update. Unify disabled fallbac…\nVote: YES\nRationale: Align all instances to make it easier for future operations.\n\nEnhancing Aave DAO’s Liquidity Incentive Strategy…\nVote: YES\nRationale: Supporting GHO and deepen the parthernship with Balancer\n\nReserve Factor Update October 2023\nVote: YES\nRationale: Incentivize user to migrate to V3\n\nTransfer Assets From Polygon To Ethereum Treasury\nVote: YES\nRationale: Fill up the Ethereum treasury for all payments, liquidity strategies and so on.\n\nGovernance v2.5 Activation\n Vote: YES\nRationale: Important step to governance V3\n\nACI Phase II\n Vote: YES\nRationale: The ACI has been pushing the DAO to its limits which is really positive.\n\nAave v3 Gnosis Activation\n Vote: YES\nRationale: New market with great potential and future. Enables the DAO to collect more fees.\n\nDisable Stable Borrows\n Vote: YES\nRationale: Security is always the no. 1 priority for me, thats why i voted YES to deactivate stable borrows.\n\nMultichain Stable Debt Token Upgrades\n Vote: YES\nRationale: See the previous vote\n\nChaos Labs Risk Management Renewal\n Vote: YES\nRationale: Chaos Labs have been outstanding for the DAO and always delivered top notch work, happy to have them here.\n\nLiquidations Grace Sentinel activation\n Vote: YES\nRationale: Giving the Aave guardian the option to unpause markets when needed and thus act faster. (Security feature)\n\nAave V2 Ethereum LT Reduction\n Vote: YES\nrationale: Incentivize user to move to V3\n\nActivate Freezing Steward on v3 missing networks\n Vote: YES\nRationale: allows the emergency admin to freeze reserves if needed\n\nFixed REP price feed on AAVE v1\n Vote: YES\nRationale: Alternative to chainlinks price feed on V1\n\nGHO - Increase Borrow Rate\n Vote: YES\nRationale: Helping GHO reach its peg\n\nAmendSafetyModuleAAVEEmissions\n Vote: YES\nRationale: The reserve won’t have Aave forever and it is costing the DAO a lot. Reducing and looking for yield alternatives is the correct way and the proposed model was the best out of 3.\n\nReserve Factor Updates - Polygon Aave v2\nVote: YES\nRationale: Incentivize user to move to V3\n\nUpgrade Aave V3 ETH Poool wETH parameters\n Vote: YES\nRationale: Stay competitive, earn more fees (by loops), incentivize more deposits\n\n 12 days later\n\n post by EzR3aL on Nov 24, 2023\n\n EzR3aL\n\n Regular\n\nChaos Labs CRV Aave V3 Polygon LT Reduction\n Vote: YES\nRationale: Mitigating risk for CRV\n\nwMATIC Interest Rate Update\n Vote: YES\nRationale: Interest rate adjustments help user maximizing profits and maybe result in higher borrow rates.\n\nUpgrade Aave V3 ETH Poool wETH parameters\n Vote: NO\nRationale: Double proposal, voted no to ensure no technical problems.\n\nAdd FXS to Ethereum V3\n Vote: YES\nRationale: Frax has been a player for quite a good while with a solid track record. User have been waiting for this asset.\n\nTokenLogic Funding\n Vote: YES\nRationale: Giving the fact that working with TL was always a pleasure, i voted yes.\n\nTreasury Management - Add to rETH Holding\n Vote: YES\nRationale: Diversify the treasury and mitigate risk from single protocols, earn more fees, help Ethereum decentralize more.\n\nIncrease Stablecoin Optimal Borrow Rates\n Vote: YES\nRationale: Optimizing stablecoins borrows on V2 and V3 for optimal borrow rates.\n\nMAI/MIMATIC deprecation, 2023.10.31\n Vote: YES\nRationale: MAI hasn’t regain its peg for several months.\n\nGauntlet recommendation to lower stMATIC, MaticX …\n Vote: NO\nRationale: Im not seeing any risk associated with these assets. Just because it could happen, doesn’t mean its going to.\n\nCRVUSD onboarding on Aave V3 Ethereum\n Vote: YES\nRationale: New and strong stablecoin with great supply, generating fees for the protocol.\n\nChaos Labs Risk Parameter Updates - Increase MKR …\n Vote: YES\nRationale: Supporting the MKR whales to finally switch to V3 fully.\n\nGauntlet Cap Recommendations for Polygon v3\n Vote: YES\nRationale: Ensure safety of the Aave V3 Polygon, by adjusting parameters.\n\nIncrease GHO Borrow Rate\n Vote: YES\nRationale: As long as GHO is depegged its crucial to raise interest rates.\n\nOnboard Native USDC to Aave V3 Optimism\n Vote: YES\nRationale: Replace the bridged version with the native asset (Why circle…)\n\nV2 Deprecation Plan, 2023.11.20\n Vote: YES\nRationale: Incentivize user to switch to V3.\n\nIncrease GHO Borrow Rate\n Vote: NO\nRationale: Double proposal, voted no to ensure no technical problems.\n\nAmendSafetyModuleAAVEEmissions\n Vote: YES\nRationale: From economical perspective an important step, lowering sell pressure, and first step to a new version of the SM.\n\n 11 days later\n\n post by EzR3aL on Dec 6, 2023\n\n EzR3aL\n\n Regular\n\nAllow Emergency Admin to freeze on Aave V2\n Vote: YES\nRationale: Safety measure to protect user and the protocol\n\nUpdate PriceOracleSentinel\n Vote:YES\nRationale: Unify systems, make the network easier to understand.\n\nAave Funding Updates\n Vote:YES\nRationale: Make sure the DAO has enough funds on the correct network and be able to pay SP, Delegates, risk, etc.\n\nReserve Factor Updates - Polygon Aave v2\n Vote:YES\nRationale: Migrate user from V2 to V3\n\nOnboarding wstETH to Aave V3 on Base Network\n Vote:YES\nRationale: New asset, generating fees, making revenue for the DAO\n\nAave Governance V3 Activation\n Vote:YES\nRationale: The next big step for governance and the DAO, more powerful, better, faster and stronger.\n\nGauntlet <> Aave Renewal 2023\n Vote:NO\nRationale: You might be asking why? As i always say risk is crucial and think 2 independent opinions are important. While this is correct, i do think Gauntlets quality and response time decreased over time, while other risk provider came out of nowhere and delivered fast and easy to understand. The decision i made probably won’t make any difference while the major part of the DAO voted YES but this should let Gaunlet know, that they could loose the DAO in the future as a customer if they don’t deliver or keep up with the competition. There are other risk provider that can be onboarded and probably would be happy to serve the DAO.Competition is important and needed, if you don’t have any you get lazy. This is a wake up call to every SP.\n\n post by EzR3aL on Dec 11, 2023\n\n EzR3aL\n\n Regular\n\nChaos Labs RF and IR Updates - Aave V2 Ethereum\n Vote:YES\nRationale: winding down the V2 markets\n\nTransfer AURA to GLC Safe\n Vote:YES\nRationale: Strategy for the GLC to support peg and make use of otherwise idle assets.\n\nGHO update on Aave V3 Ethereum Pool for 13/11/202…\n Vote:YES\nRationale: fix of an GHO integration issue to keep security levels as high as possible\n\n 16 days later\n\n post by EzR3aL on Dec 28, 2023\n\n EzR3aL\n\n Regular\n\nGauntlet recommendation to reactivate CRV borrowi…\n Vote: YES\nRationale: CRV is a strong and known asset, with new parameter it is safe again to list it.\n\nSync emergency admin on v2 AMM\n Vote: YES\nRationale: Align systems and make everything less complicated\n\nActivate Proof of Reserve\n Vote: YES\nRationale: Giving more security in case of depegged bridge assets on Avalanche.\n\nTreasury Management - Add to rETH Holding (resubm…\n Vote: YES\nRationale: Use the idle wETH in form of rETH and generate yield.\n\nChaos Labs V2 Ethereum and Polygon LT Reductions\n Vote: YES\nRationale: Push the V3 market and depreciate V2 markets.\n\nIncrease Polygon wstETH Supply Cap\n Vote: YES\nRationale: We need more space for user \n\nIncrease GHO Borrow Rate 100 bps to ~6.41% on Aav…\n Vote: YES\nRationale: Defending GHOs peg\n\nTokenLogic & karpatkey Service Provider Partnersh…\n Vote: YES\nRationale: Both have been serving the DAO great and can achieve even more together.\n\nPolygon V2 Reserve Factor Updates\n Vote: YES\nRationale: Push the V3 market and depreciate V2 markets.\n\nOnboard Native USDC to Aave V3 Markets\n Vote: YES\nRationale: Currently there are plenty different bridged versions available and the supply is shrinking, making it a dying asset. Therefor we need the native asset USDC supported by Circle.\n\nContinuous Security Proposal Aave <> Certora\n Vote: YES\nRationale: Security over everything.\n\nUpdate GNO Risk Parameters on Aave V3 Gnosis Pool\n Vote: YES\nRationale: Constant monitoring of assets and making adjustments for safety.\n\nTransfer all CRV positions from Ethereum Mainnet …\n Vote: YES\nRationale: Use the idle CRV positions to generate more yield for the protocol.\n\nRequest for Bounty Payout - December 2023\n Vote: YES\nRationale: Individual identified a bug and reported it as a whitehat. Again, security over everything.\n\nTreasury Management - Polygon v2 to v3 Migration\n Vote: YES\nRationale: Managing treasuries from V3.\n\nAave Governance V3 Activation Short\n Vote: YES\nRationale: Huge next step in terms of governance.\n\n post by EzR3aL on Dec 28, 2023\n\n EzR3aL\n\n Regular\n\n With the activation of governance v3 all delegations have been reset. This means that any person, that delegated to me before wants me to vote again with their voting power, needs to re delegate.\nSimply visit this website made by @bgdlabs Aave Governance (onaave.com), connect your wallet and then choose the asset you want to delegate to me and enter my ens ezr3al.eth.\nFeel free to contact my via Telegram or X if you do have any questions.\nThank you for your support.\n\n 27 days later\n\n post by EzR3aL on Jan 24, 2024\n\n EzR3aL\n\n Regular\n\n Aave Pool update\nVote: YES\nRationale: Security measurement to fix V3 instances.\nPolygon V2 Reserve Factor Updates\nVote: YES\nRationale: Slow shutdown of V2 to migrate user to V3\nChaos Labs Risk Parameter Updates - WBTC.e on V2 and V3 Avalanche\nVote: YES\nRationale: Risk mitigation\nStablecoin IR Curves Updates\nVote: YES\nRationale: Alinging all Aave instances making it easier for user and risk management.\nV2 Deprecation Plan, 2024.01.02\nVote: YES\nRationale: Offboarding V2 in favor for V3\nAave Funding Updates (part 2)\nVote: YES\nRationale: Many different networks capture value for the DAO, by alinging them its easier to understand what the treasury is holding and manage those funds.\nAave v3 BNB Activation\nVote: YES\nRationale: New market, new revenue stream, new oppotunities. Have fun!\n\n 12 days later\n\n post by EzR3aL on Feb 6, 2024\n\n EzR3aL\n\n Regular\n\n StkGHO Activation\nVote: YES\nRationale: This version of GHO is helping to keep the peg, offer yield to staker and secures the protocol.\nGHO Stability Module\nVote: YES\nRationale: Helps keeping the peg when GHO >1$, several other very important features.\nReserve Factor Updates (Jan 15, 2024)\nVote: YES\nRationale: Depreciate V2\nRequest for Bounty Payout - January 2024\nVote: YES\nRationale: As I value security over everything I support the white-hats and want to thank them for pointing to bugs.\nUpdate ETH EMode and WETH Risk Params on Aave v3 Ethereum, Optimism and Arbitrum\nVote: YES\nRationale: Observing the market and thus adjusting parameter.\nRegister a.DI Ethereum → Scroll adapter\nVote: YES\nRationale: Expanding a.DI, aliging infrastructure.\nHarmonize USDT Risk Parameters on Aave V3 Markets\nVote: YES\nRationale: Better asset management and easier for user of different markets.\nTreasury Management - GSM Funding & RWA Strategy Preparations (Part 1), Frontier Staking as a Service\nVote: YES\nRationale: Financial AIP to be able to pay for everything.\nAave V1 Deprecation\nVote: YES\nRationale: No need for V1 anymore.\nAMPL Interest Rate Updates on V2 Ethereum\nVote: YES\nRationale: Mitigate risk for user and the protocol.\nOnboard fdUSD to Aave v3 on BNB chain\nVote: YES\nRationale: New asset, more fees and revenue.\nFreeze and set LTV to 0 for DPI, BAL, CRV, and SUSHI on Aave v3 Polygon, 2024.01.19\nVote: YES\nRationale: Freeze old assets that don’t have any value to the protocol.\nGauntlet recommendation for MAI / MIMATIC deprecation phase 2\nVote: YES\nRationale: MAI depegged and thus created a risk to user.\nAave v3 Scroll Activation\nVote: YES\nRationale: New market\n\n 12 days later\n\n post by EzR3aL on Feb 18, 2024\n\n EzR3aL\n\n Regular\n\n stkABPT Balancer V2 migration\nVote: YES\nRationale: Update to the newer v2 SM\nMigration of remaining Gov v2 permissions & DAO’s Paraswap positive slippage\nVote: YES\nRationale: Moving everything from v2 to v3.\nV2 Ethereum LT Reductions\nVote: YES\nRationale: Depreciate v2 for v3\nReserve Factor Updates (Jan 31, 2024)\nVote: YES\nRationale: General update for RF\nAdd PYUSD to Aave v3 Ethereum Pool\nVote: YES\nRationale: TradFi token coming to Aave, what a time to be alive.\n[ARFC] Deprecate Aave V2 AMM Market - Step 2\nVote: YES\nRationale: Depreciate v2 for v3\nRetroactive Bug Bounty Pre-Immunefi\nVote: YES\nRationale: Security over everything, always.\nSnapshot:\n[TEMP CHECK] Integrate Oval for the BAL & SNX Ethereum V3 Markets\nVote: NO\nRationale: I have already expressed several points and concerns regarding the Oval approach. Oval seems to be approaching a potentially significant area for exploration. While MEV has always been a consideration, the concept of OEV had not crossed my mind before this proposal. However, I prioritize security above all else, as I committed to monitoring it consistently when initiating this delegate platform.\nOval has raised some apprehensions with its current approach. Even though it would have only been tested in a small, isolated market, I am hesitant to embrace it. If something were to go wrong, the user might bear the consequences, which is the worst-case scenario. Brand recognition is crucial and takes time to build. It shouldn’t be jeopardized by experimenting with something new unless it has undergone thorough testing.\nIt could be assumed that I lack the technical knowledge to fully comprehend everything. While this may be true to some extent, I consulted with other experts before making my voting decision. Different parties have presented promising solutions, and it’s essential to evaluate what is best for Aave, its users, and, in this specific case, its liquidators – the final barrier against accumulating bad debt.\nI would prefer to see a more broadly researched solution for Aave overall, and I encourage everyone to participate in this initiative. Although I voted NO, it was not a rejection of Oval or UMA but rather a stance against the TEMP CHECK proposal. I was advised to vote abstain, but that would imply potential support for Oval, which I cannot endorse in its current form, hence the NO vote. However, I am open to alternative solutions and willing to contribute where I can.\n\n Load more posts below","tokens":5758,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263177359,"hash":"63ec2b706af60dcc7af3f2c643907feaacb5973c"}
{"url":"https://ethresear.ch/t/spread-extending-gossipsub-with-efficient-anonymous-dissemination/25343/1","domain":"ethresear.ch","title":"SPREAD: Extending GossipSub with Efficient Anonymous Dissemination - Networking - Ethereum Research","text":"SPREAD: Extending GossipSub with Efficient Anonymous Dissemination \n\n Networking\n\n p2p,networking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 10\n min\n\n Jul 1\n\n 1 / 5\n\n Jul 2\n\n Jul 16\n\n post by MatheusFranco99 on Jul 1\n\n MatheusFranco99\n\n Authors: Diogo Cardoso, Matheus Franco, Rodrigo Rodrigues\nAcknowledgement: This work was supported by a grant from the SSV Network DAO awarded to the University of Lisbon.\nA draft spec was proposed to libp2p/specs (PR #726).\nA reference implementation is open for go-libp2p-pubsub (PR #717).\nOverview / Summary\nGossipSub is the key communication infrastructure underlying societal-critical protocols in ecosystems such as Ethereum. Several characteristics of gossip protocols make this an interesting communication substrate, namely robustness, scalability, and simplicity. However, the important property of anonymity (hiding the true source of a message), is one that is sometimes cited as being desirable to avoid targeted attacks against the sender, but is in practice well-known that it cannot be attained by GossipSub, which opens the door to targeted denial-of-service. The natural defense, namely beginning dissemination with a random walk as in Dandelion++, buys anonymity at a latency cost that the Ethereum community has already judged infeasible for the consensus layer, and the upcoming reduction of slot times from 12 to 6 seconds only tightens that budget.\nWe propose SPREAD (Secure Peer-to-Peer Relay for Efficient Anonymous Dissemination), a GossipSub extension that aims for the best of both worlds: it raises the bar against sender deanonymization while actually improving dissemination efficiency. SPREAD combines two mechanisms: a local random walk that obfuscates the message origin without a significant performance penalty, and a geographically directed propagation that reaches the globe with low latency by using nearby nodes as stepping stones to avoid costly long-distance hops. We have implemented it as an opt-in, backwards-compatible extension on a fork of go-libp2p-pubsub, and evaluate it below against GossipSub and Dandelion++ using the real implementation. Note that our goal is to raise the bar rather than to fully prevent deanonymization, since source indistinguishability is a quantitative property that depends on the adversary’s observation power, rather than an absolute guarantee.\nTerms and definitions\nCurious Nodes (Honest-but-Curious Observers) - Nodes that follow the protocol correctly but attempt to infer additional information (e.g., the originator of a given message) from observed traffic patterns.\nFanout - The number of peers to which a node forwards a message during a dissemination step.\nRandom Walk - A forwarding strategy in which each node forwards a message to a single randomly selected peer (possibly with probabilistic branching).\nVirtual Coordinates - Latency-estimated coordinates assigned to nodes in a synthetic geometric space, allowing estimation of network distance without direct measurement.\nBernoulli Trial - A probabilistic decision mechanism with two outcomes (success/failure), parameterized by the respective probability value.\nStretch - A performance metric defined as the ratio between the actual end-to-end delivery latency and the direct (usually optimal) communication latency between sender and receiver.\nDeanonymization Accuracy - The fraction of times an adversary correctly infers the original sender of a message, based on timing observations across attacker-controlled nodes.\nCluster - A group of nearby nodes, i.e., nodes that are close to each other in the virtual coordinate space and therefore communicate with low latency.\nCobra Walk (Coalescing-Branching Random Walk) - A variant of the random walk in which each node forwards a message to a number of random neighbors given by a branching factor, allowing the walk to occasionally branch out instead of always forwarding to a single peer.\nVoronoi Diagram (Dirichlet Tessellation) - A partition of a space into regions according to a set of reference points (centroids), where each region contains the portion of the space that is closer to its centroid than to any other.\nMotivation\nDespite the general understanding that gossip protocols can aid in protecting the anonymity of the original sender of any given message, the developers and many users of GossipSub know that it was not designed and is not able to provide such guarantees. In particular, a simple attack on the GossipSub layer is possible by observing message timing at a small set of listener nodes, enabling a centralized coordinator to correlate timings and infer the true source of gossip messages. This class of passive, timing-based attack was first demonstrated on Bitcoin, where transactions were linked to the IP addresses that originated them from a small number of supernodes (Biryukov et al., Fanti and Viswanath), and it was later shown to map Ethereum validators to their peer IDs and IP addresses by monitoring attestation propagation over a few epochs (Sharma et al.; Heimbach et al.; Rhea). This is possible despite GossipSub’s use of randomized forwarding to obscure message paths because a validator’s immediate peers (i.e., the validator’s direct peers in the gossip overlay) consistently receive and propagate its messages noticeably earlier than others. As such, by deploying a few tens of listener nodes it becomes highly likely that, after a few epochs, one of the listener nodes will become a direct peer (and remain so for several subsequent epochs). Therefore, by keeping track of the first listener node to hear a message over multiple consensus epochs (and which network address that message came from), the coordinator is eventually able to reliably map validators to their network identities with high confidence. Once identified, validators can be selectively targeted (e.g., through denial-of-service), leading to slashing due to missed duties or economic attacks. Crucially, this deanonymization does not rely on any privileged access and can be mounted only by listening to traffic at a small number of well-behaved (honest but curious) observers.\nThis problem is rooted at a critical tension in the design of gossip protocols: increasing fanout, and more generally improving dissemination speed, reduces anonymity, while limiting exposure through low fanout improves privacy at the cost of propagation speed. Unfortunately, GossipSub fails to strike a sensible balance: it leaks sufficient structural information to enable deanonymization, yet remains inefficient due to latency-insensitive paths that amplify delay and overhead.\nPrior research has proposed defenses against this class of attack, most notably Dandelion and Dandelion++, which provide stronger, formally analyzed sender-anonymity guarantees by beginning dissemination with a random-walk obfuscation phase. However, these guarantees come at a significant latency cost, which has proven to be a fundamental barrier to their adoption in latency-sensitive settings. In fact, the Ethereum community concluded that, “because of latency constraints […] this proposal [Dandelion++] is infeasible for the Ethereum consensus layer (at least not for any strong anonymity guarantees)” (EthResearch discussion). This tension is bound to intensify: with the planned reduction of Ethereum’s slot time from 12 to 6 seconds (EIP-7782), the gossip layer faces even stricter performance requirements, resulting in a compound challenge where today’s deployments must provide both the required performance and the desired sender-anonymity defenses.\nTo address this challenge, we propose SPREAD, a new gossip protocol to be implemented as a protocol extension, that raises the bar against sender deanonymization compared to GossipSub while actually providing a more efficient dissemination. Our approach rests on two principles: anonymity via a random walk that obfuscates the message origin, and low latency via topology-aware hop selection. We separate the random-walk hops, which prioritize low latency, from wide-area hops, which try to communicate with nearby nodes as a stepping stone, whenever it is possible to avoid costly long-distance paths. This design suits applications requiring both low latency and sender privacy, including blockchain validator messaging, anonymous communication systems, and censorship-resistant platforms.\nDesign of SPREAD: insights and overview\nThe recent formal work of Guerraoui et al. showed the need for gossip protocols designed for anonymity to include a strong random walk component, where each node will often forward a message to a single overlay neighbor, to make the identity of the source difficult to determine. This technique is employed, for example, by the Dandelion family of protocols, which start with a random walk-based anonymity phase and then probabilistically switch to a dissemination phase with a high fanout.\nHowever, this raises the problem that, during the random walk phase, where messages are sent to at most one peer per time step, there is a chance that an individual step can be unlucky and cross a slow or distant path. This is problematic since a single slow hop is sufficient to noticeably hurt the average end-to-end performance (as measured by the stretch, or the ratio between the overlay and a direct message connection). This problem is then amplified by the fact that blockchains such as Ethereum layer their multi-step protocols on top of the gossip substrate. Furthermore, the countermeasures to improve the performance, namely to anticipate the switch to the more efficient mode where messages are sent to multiple peers in parallel, are not only still vulnerable to a single long hop in the initial phase, but are also in direct tension with the intended anonymity guarantees.\nTo navigate this tradeoff effectively, we leverage the insight that the geographic distribution of nodes tends to naturally form clusters corresponding to the world’s most densely populated and economically developed regions (e.g., US East and West Coasts, Europe, Asia, etc.) This allows the design of SPREAD to organize nodes into clusters with the characteristic that the network latency between nodes in the same cluster is low, thus allowing for fast multi-hop dissemination inside a cluster. With this design decision in place, we can then leverage the intra-cluster communication to conduct random walks that allow for building privacy without a significant performance penalty, while occasionally turning to inter-cluster communication for global dissemination.\nA second challenge is that the inter-cluster message steps can also be very penalizing for the end-to-end performance if not managed carefully. For instance, we would like to avoid having to send a message from Europe to the East Coast of the US via an overlay hop through Asia or the Middle East. To avoid this, we need to devise an efficient wide area dissemination, since this step is so crucial for performance, and our protocols already achieve anonymity through the intra-cluster communication. To this end, SPREAD attempts that inter-cluster message hops are conducted with nodes in adjacent clusters, so that they can be used as a stepping stone to reach more distant ones. In an idealized routing scenario, there is a single global view of the clusters and how they connect to each other through a high level overlay, which corresponds to a Dirichlet tessellation, dividing the space into regions according to the set of centroids of the clusters. This allows the idealized routing to only send inter-cluster messages to overlay peers in neighboring clusters according to the Dirichlet tessellation.\ndataset_voronoi1029×630 54.4 KB\nFigure 1: Geographic coordinates of a dataset of Internet hosts, augmented with clustering information showing Voronoi cells. An idealized wide-area gossip step would occur only between adjacent cells, but this would require a globally coordinated view of the cell division.\nHowever, our goal is to have a fully decentralized protocol that does not rely on a global view for these clusters and their high-level connections. To this end, we decided to instead approximate the idealized routing by having each node build their own local view of its own cluster. Our main insight is to use a virtual coordinate scheme that securely assigns to each now a set of Euclidean coordinates [Vivaldi,Newton] to approximate the idealized routing. With such coordinates in place, each node defines its own view of its cluster as the closest t% of its overlay neighbors in the virtual coordinate space. This allows each node to locally determine the subset of its peers that comprise the neighboring members of its own cluster. Additionally, it is possible to approximate the idealized inter-cluster routing in a fully decentralized way leveraging virtual coordinates. The idea, inspired by natural navigation, is to always avoid a direct jump to a more distant neighbor whenever a closer neighbor exists within the set of non-cluster nodes that are reasonably well-aligned with the distant node (which, intuitively, means there is a closer nearby destination that can serve as a stepping stone). In this case, well-aligned means that the angle bearing to the closer node is within a configurable angular interval of the bearing of the distant node (where this angle bearing is given by the virtual coordinates in the Euclidean space). This, again, allows each node to locally split its set of non-cluster overlay peers into two groups: those that have a closer “stepping stone” member of the set, and therefore should not be used for inter-cluster or any type of forwarding (denoted occluded_remote), and those that do not, and therefore are eligible for inter-cluster hops (unobstructed_remote).\nProtocol overview\nThe protocol has two components that run in parallel: an algorithm for maintaining a set of overlay peers (or neighbors) and their respective secure virtual coordinates, and the main protocol for sending and propagating gossip messages. The overlay neighbors of node i are automatically partitioned into three subsets: cluster_i, occluded_remote_i, and unobstructed_remote_i, according to the criteria described before.\nWith this overlay state in place, we can now define the protocol for broadcasting messages in a simple manner, based on the intuition of combining intra-cluster random walks for ensuring anonymity with inter-cluster efficient dissemination through the unobstructed remote neighbors. The decision to incur in each of these two alternatives is made upon receiving a message to be propagated, simply by flipping a coin that is biased according to a system parameter. The pseudocode of the protocol is explained next, focusing on how to broadcast a message once the cluster information and overlay neighbor formation is in place.\n1: # constants:\n2: ρintra # Branching probability (intra-cluster)\n3: ρinter # Inter-cluster dissemination probability\n4: fanoutintra # Number of intra-cluster peers when branching\n5: fanoutinter # Number of peers for inter-cluster dissemination\n\n6: # state variables:\n7: neighbors_i # Set of overlay neighbors, partitioned into:\n8: cluster_i # Subset of closeby neighbors in Pi’s cluster\n9: unobstructed_remote_i # Subset of remote neighbors that are not efficiently reachable via another neighbor\n10: occluded_remote_i # Subset of remote neighbors that may be reachable via another neighbor\n\n11: upon receiving or publishing message m do\n12: INTRACLUSTERSPREAD(m)\n13: INTERCLUSTERSPREAD(m)\n\n14: procedure INTRACLUSTERSPREAD(m)\n15: if Bernoulli(ρintra) = 0 then\n16: send m to 1 peer in cluster_i selected uniformly at random\n17: else\n18: send m to fanoutintra peers in cluster_i selected uniformly at random\n\n19: procedure INTERCLUSTERSPREAD(m)\n20: if Bernoulli(ρinter) = 1 then\n21: send m to fanoutinter peers in unobstructed_remote_i selected uniformly at random\n\nThe protocol iteration contains two steps: the intra-cluster and inter-cluster propagations (lines 10 to 11). Intra-cluster propagation is inspired by the cobra walk (coalescing-branching random walk) algorithm (Dutta et al.), which consists of a random walk that can possibly branch out according to the output of a local Bernoulli trial (line 15). The probability of branching out is denoted by rhointra. When it outputs zero (line 16), the node will simply uniformly select a random peer in its cluster, representing the random walk phase. Else, when it outputs one (line 17), the node spreads the message to fanoutintra peers selected uniformly at random in its own cluster, achieving a faster intra-cluster dissemination. The inter-cluster propagation is responsible for the global dissemination and occurs occasionally according to another local Bernoulli trial (line 20), this one with parameter ρinter. When the trial outputs zero, a node doesn’t interact with other clusters, keeping all communication within its own cluster. When it outputs one (line 21), the node spreads the message to neighboring nodes that are not too distant (i.e., not “hidden” in the coordinate space by a closer node that can act as a stepping stone), randomly selecting fanoutinter peers in total in a uniform way. Note that the peer propagates the same message multiple times. The reason why the algorithm does not include some logic to stop such duplicated behavior is to guarantee anonymity. In particular, for protocols in which nodes propagate a message only once, Bellet et al. have shown that the attacker would be more likely to identify the source by tracking communication timestamps. However, for real-world applications that continuously generate new messages, termination must be provided to avoid network congestion. A simple approach is to let the node propagate the same message (which can arrive via different neighbors as the message is routed) a fixed number of times, after which it stops. Usually, this parameter controls the reliability of the protocol, and small values are commonly sufficient for real-world network sizes, as described by Kermarrec et al.. Still, extra reliability mechanisms can be added and in fact are already present in frameworks such as GossipSub, such as heartbeat messages that advertise a list of seen messages and “pull” protocol requests to fetch missing messages.\nThis message pull mechanism is also valuable for robustness in two additional scenarios. First, under churn, a succession of node failures or departures can prevent the direct propagation from being effective, and the heartbeat-and-pull mechanism lets nodes recover the messages they missed. Second, it helps defend against Byzantine nodes: while simple cryptography prevents such nodes from tampering with message contents, they can still deliberately delay or refuse to forward messages, endangering progress, which the heartbeats and pulls counter.\nUsing protocol extensions and coexistence with GossipSub peers\nSPREAD is an opt-in, backwards-compatible extension of GossipSub. It is advertised through GossipSub’s existing handshake fields and becomes active on a connection only when both peers support it. SPREAD messages are flagged with an extra field in the standard RPC envelope, so peers that do not support the extension simply ignore the marker and fall back to standard GossipSub. This makes mixed deployments possible and enables an incremental adoption path, with partial anonymity and performance benefits available before the whole network upgrades. Cluster construction relies on virtual coordinates maintained by a Vivaldi process (secured with Newton checks), which is the only addition SPREAD makes to a node’s communication profile.\nEvaluation\nWe evaluate SPREAD along two complementary dimensions: its resistance to deanonymization attacks and its efficiency in disseminating messages across wide-area networks. We compare it against GossipSub, which is deployed in Ethereum, and Dandelion++, a research proposal designed to improve anonymity. Because SPREAD is implemented as an extension of go-libp2p-pubsub, we are able to evaluate the actual production code: we run it over simnet, a packet-level simulator that connects the real implementation through virtual links with configurable latency and bandwidth. To reflect a realistic deployment, we draw network topologies from a global Internet dataset with real round-trip-time measurements between geographically distributed nodes, sampling several topologies and aggregating the results. Dandelion++ is implemented on the same stack, so that all three protocols share the same implementation and differ only in their dissemination strategy.\nFor a fair comparison, we configure the three protocols so that, in expectation, each node forwards a message to the same number of peers, i.e., they share the same per-node bandwidth budget. We use GossipSub’s default mesh size of 6 as the target expected fanout, and tune SPREAD’s four parameters and Dandelion++'s parameters to match it. We measure anonymity through a deanonymization accuracy metric under a first-timestamp estimator: for a given fraction of curious nodes, we sample many attacker placements and, for each message, guess its sender as the node that delivered it to a curious node with the earliest timestamp; the accuracy is the fraction of correct guesses. We measure performance through both the absolute delivery latency and the stretch metric, defined as the ratio between the actual end-to-end delivery time of a message and the direct communication latency between its sender and receiver.\nAnonymity\nAll protocols become more vulnerable as the adversary controls a larger share of the network, but to markedly different degrees. GossipSub is the most exposed: with only 5% of curious nodes, the attacker already succeeds in over 35% of cases, rising to 54% at 20%. Dandelion++ achieves the strongest anonymity, staying below 10% at 5% curious nodes and around 20% even at 20%, owing to its random-walk obfuscation phase. SPREAD sits between the two: at 5% curious nodes its accuracy is in the low-20% range, and at 20% it reaches roughly 45%. Therefore, it reduces the adversary’s success rate relative to GossipSub, while trading a modest anonymity gap to Dandelion++ in exchange for significantly better dissemination efficiency.\nattack_results_21013×717 65 KB\nFigure 2: Deanonymization (attack) accuracy as a function of the percentage of curious nodes, for GossipSub, Dandelion++, and SPREAD.\nPerformance\nSPREAD achieves the most efficient dissemination of the three protocols. At a stretch threshold of 3, over 90% of deliveries complete under SPREAD, compared to about 83% for GossipSub and only 50% for Dandelion++; the gap persists into the tail, where SPREAD and GossipSub approach full coverage well before Dandelion++. Overall, SPREAD lowers the mean stretch by about 23% relative to GossipSub and about 67% relative to Dandelion++, and it shrinks the heavy tail even more markedly, reducing the 99th-percentile stretch by roughly 39% and 74%, respectively. The same ordering holds for absolute latency: half of SPREAD’s deliveries complete in under 100 ms, against 40% for GossipSub and 10% for Dandelion++. This tail behavior is particularly important when multi-step protocols are layered on top of gossip, as in Ethereum, since each additional step multiplies the single-hop latency penalty.\nstretch_cdf_21014×717 53.7 KB\nFigure 3: Cumulative distribution of stretch across all sender-receiver pairs, for the three protocols.\ncdf_latency1014×716 58.3 KB\nFigure 4: Cumulative distribution of absolute delivery latency across all sender-receiver pairs.\nTuning\nFinally, we study how SPREAD’s four parameters trade anonymity against performance. Across all of them, increasing the fanout or the branching probability lowers stretch but simultaneously raises attack accuracy, and vice versa, which confirms that SPREAD can be tuned along a continuum: lower values maximize privacy, while higher values shift the balance toward performance. The intra-cluster parameters dominate the stretch profile, whereas the inter-cluster probability acts mostly as an anonymity knob with diminishing returns on performance. The configuration used in the comparisons above deliberately targets a balanced point in this spectrum, rather than either extreme.\ntuning_stretch1350×958 103 KB\nFigure 5: Mean stretch versus deanonymization accuracy for single-parameter variations of SPREAD, at 10% curious nodes. Each line connects successive values of one parameter.\nOverall, these results show that both dimensions of Ethereum’s current design can be improved at once: switching to SPREAD lowers deanonymization accuracy relative to GossipSub while also achieving lower mean and tail stretch. Compared to Dandelion++, SPREAD gives up some anonymity, but it avoids the latency overhead that makes strong-anonymity proposals impractical for latency-sensitive settings such as Ethereum’s consensus layer.\n\n 3\n\n read \n\n 10\n min\n\n post by Nashatyrev on Jul 3\n\n Nashatyrev\n\n Interesting read, thanks for sharing!\nWould it make sense to think of this as two separate improvements to GossipSub: (1) optimizing dissemination through clusters, and (2) improving publisher anonymity? If so, I’m curious how much of the dissemination improvement comes from the clustering idea alone, and how much performance is then traded back to achieve the anonymity guarantees.\n\n post by MatheusFranco99 on Jul 8\n\n MatheusFranco99\n\n Hey, @Nashatyrev ! Thanks for the comment.\n\nWould it make sense to think of this as two separate improvements\n\nYes, absolutely! SPREAD can be tunned in both ways: prioritizing either efficiency or anonymity. One way I like to frame it is that SPREAD can be anywhere in the region between GossipSub and Dandelion regarding anonymity, while keeping performance better than both. But, as you said, while efficiency can be fully optimised, it is at the cost of reducing anonymity.\n\nI’m curious how much of the dissemination improvement comes from the clustering idea alone, and how much performance is then traded back to achieve the anonymity guarantees.\n\nGood question, these numbers would definitely be interesting to see.\nI’m running now the experiments for it and will report here as soon as I have it \n\n post by MatheusFranco99 on Jul 10\n\n MatheusFranco99\n\n Hey @Nashatyrev, following up with some numbers:\n\nOptimizing exclusively for dissemination: our best configuration improves on every performance metric against GossipSub (numbers in the table below), while suffering on the anonymity side with 41% of attacker accuracy (for when attackers control 10% of the network) vs. 38% from GossipSub.\n\nMetric\nmean latency\np95 latency\np99 latency\nmean stretch\np95 stretch\np99 stretch\n\nLowered by\n24%\n26%\n30%\n38%\n58%\n60%\n\nFor the “same or better anonymity than GossipSub”: a tunned configuration can produce lower attacker accuracy (30% vs. GossipSub’s 38%) while still improving considerably all performance metrics.\n\nMetric\nmean latency\np95 latency\np99 latency\nmean stretch\np95 stretch\np99 stretch\n\nLowered by\n22%\n24%\n25%\n32%\n51%\n49%\n\nDandelion-level anonymity: we can also configure SPREAD to match Dandelion’s anonymity, beating it slightly on performance, though being considerably worse against the performance-optimized case. The pareto curve:\n\nConfiguration\nAcc@10%\nMean Latency\nMean stretch\n\nBest performance found, but worse than GossipSub on anonymity\n41%\n98 ms\n1.54\n\nStill high-performance, while beating GossipSub anonymity\n30%\n101 ms\n1.69\n\nMid-point\n28%\n104 ms\n1.74\n\nClose to Dandelion\n20%\n143 ms\n2.87\n\nDandelion-level anonymity, but worst performance\n11%\n207 ms\n4.76\n\nI ran these simulations overnight, but I plan to run these for a few more days to try to find even better configurations and increase the sample size.\n\n post by kamilsa on Jul 16\n\n kamilsa\n\n Thanks a lot for this work. Results are super interesting.\nIt would also be useful to investigate how much long-term privacy SPREAD provides when applied specifically to Ethereum.\nOne of Ethereum’s main network-layer deanonymization is attestation gossip. Each validator produces a signed attestation once per epoch. An epoch contains 32 slots and lasts 384 seconds.\nWith 5% of curious nodes an attacker has 20% attack accuracy (according to your results). In my understanding, this is the result for a single epoch vote. For n𝑛 epochs the attack accuracy (probability of a correct guess by attackers) is: p(n)=1-(1-0.2)^n𝑝(𝑛) =1 −(1 −0.2)𝑛, which gives us the following attack accuracies:\n\n50% after roughly 3–4 epochs\n80% after 7–8 epochs\n90% after 10–11 epochs\n95% after 13–14 epochs\n99% after 21 epochs\n\nThis means that even fairly low per message deanonymization attack accuracy gives limited protection when the same validator produces the message on a regular basis (which is the case for attestation protocol).\nThat said, for other places in the protocol where peers emit messages less regularly SPREAD should indeed provide more privacy protection\n\n Powered by Discourse","tokens":7263,"squid":"ink-research","role":"Deep Scholar","at":1791263183511,"hash":"6ff88106e2b682f62a8de67296d62fa653c7c85a"}
{"url":"https://forum.soliditylang.org/t/size-limit-of-array-mapping-on-bnb-smart-chain-scalability-question/3700","domain":"forum.soliditylang.org","title":"Size limit of Array/Mapping on BNB Smart Chain (Scalability Question) - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question) \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 17\n\n 1 / 2\n\n Apr 17\n\n Apr 18\n\n post by ziaahmedshaikh on Apr 17\n\n ziaahmedshaikh\n\n Hi,\nI am going to deploy my contract on BNB Smart Chain and I want to ask a scalability related question, i have a struct something similar like following code:\nstruct Purchases{ \n\n uint32 itemId; \n\n uint32 amount; \n\n uint48 time; \n\n }\n\nand trying to manage purchase history through mapping as follows\n mapping(uint256 => Purchases\\[\\]) public purchaseHistory;\n\n// each UserID is mapped to an Array of his Purchases to manage User’s Purchase History.\nI am assuming that purchaseHistory will be incremented in 1000s every day, my questions are follows:\nHow much data can be stored in mapping like purchaseHistory array for each UserID ?\nWill contract explode after some time ?\nFor retrival, we will use pagginated function that will return purchase of user 10 items per page only.\nwill it be workable in long run or can the contract stop function after the array grows to many 1000s of records ?\nRegards. & will very much appreciate the reply.\n\n post by cameel on Apr 18\n\n cameel\n\n Solidity Compiler Team\n\nHow much data can be stored in mapping like purchaseHistory array for each UserID ?\n\nStorage space is at a premium so the compiler tries to pack things for you as much a possible. There is very little overhead here. The mapping itself takes only as much space as its content. Each dynamic array takes a single slot for length and then just the items. Check Layout of State Variables in Storage and Transient Storage for details.\nOne thing to potentially change here in case you want to minimize the total use of storage could be to use a struct of arrays rather than an array of structs. A struct always takes the whole slot, while value types can be packed. This would have the extra overhead of 2 size slots for the arrays but given that you expect thousands of items in each array and items are very short, much more space is wasted on padding between items. The downside is that it would make reads more expensive - you’d need to access 3 slots instead of 1 to get a complete set of information for one purchase - but again, if you’re reading 10 subsequent items at a time you can amortize the storage access cost by reading more than one at a time.\n\nWill contract explode after some time ?\n\nThe only hard limit on how much data you can store per mapping item is the size of storage, so for all practical purposes it’s pretty much infinite. There’s a soft limit of 2^64 32-byte slots, where the compiler starts to assume that the risk of collisions between mapping items stops being negligible, but that’s still not something you’ll easily reach before running into all kinds of other scaling problems.\nWhile writing thousands of slots per day could add up to something quite expensive, as long as it’s not all in a single transaction, but rather spread over multiple users and transactions, it’s not an issue.\n\nFor retrival, we will use pagginated function that will return purchase of user 10 items per page only.\nwill it be workable in long run or can the contract stop function after the array grows to many 1000s of records ?\n\nAssuming that you want to get the data to display it for the user or for some off-chain processing it’s not an issue either. Just make sure you return it using a view function. Such functions can be executed offchain using eth_call, which means that you don’t pay anything. No transaction is published, everything happens locally on your client, not on the network. If that’s your use case, you don’t even necessarily need pagination in the contract.\nThe only exception is if you want to get and process that data in another contract. Then that contract does need to execute the function on chain and pagination matters. In fact, the language automatically does that for you - getter functions for arrays by design return them item by item. In your case getting multiple items at a time would be more efficient if you go for the multi-array solution I mentioned, but generally the number should be low since a contract is not likely to have enough gas to process the whole array anyway.\nGenerally, there are no hard limits and you can get away with storing quite a lot of data overall, as long as you ensure that it amortizes to a small amount per user and design your contracts properly so that the whole array is never processed on chain.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 109\n\n Oct 2025\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 191\n\n Jun 9\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":2145,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263183779,"hash":"dd87752ad2533c59a4d03dc54c5d96ac0aa02096"}
{"url":"https://governance.aave.com/t/ezr3al-delegate-platform/14740/2","domain":"governance.aave.com","title":"EzR3aL Delegate Platform - Delegate Platforms - Aave","text":"Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2023\n\n 2 / 44\n\n Sep 2023\n\n Jun 30\n\n post by EzR3aL on Sep 3, 2023\n\n EzR3aL\n\n Regular\n\n Key Info\n\nDelegate Address: ezr3al.eth (0x8659d0bb123da6d16d9394c7838ba286c2207d0e)\nTelegram: @EzR3aL\nDiscord: ezr3al\nTwitter: https://twitter.com/DeFi_EzR3aL\n\nIntroduction\nHey folks! Some of you might already know that I’ve been a big fan of Aave for quite a while now, and I’m an active participant in this governance forum, snapshots and AIPs. My journey started back in May 2017 when Stani was on the hunt for some help with EthLend, a few months before it hit the mainnet. Since then, I’ve been all in on DeFi, especially Aave.\nWhy You Should Delegate to Me\nFirst off, it’s just me here – no fancy service provider or big institution. I’m just another Aave holder, like many of you. The thing that sets us apart is that I’m really active in this community, and I’m eager to help more people get into the governance game and make the tough stuff easier to understand. I get it; for a lot of folks, voting on every AIP can be a bit pricey. That’s where you come in. I’m asking for your delegation so I can vote on your behalf and make your voice heard in these important governance decisions.\nWhat Voters Can Expect from Me\nHere’s what you can count on from me:\n\nI’ll vote in a way that reflects the interests of Aave holders like you.\nI’ll work to make the governance process even more decentralized.\nI’ll do my best to break down complex topics into easy-to-digest info.\n\nSome Closing Thoughts\nJust to be clear, I’m not connected to any individuals or organizations, and I’m not getting paid by anyone for this. This is a one-person gig. I’m doing it because I believe it’s time to get more people involved, even if you only have 1 Aave in your wallet. By starting this delegation platform, I hope we can get more Aave holders engaged, either by delegating to me or, even better, by voting themselves in the future.\nSo, let’s kick this off. Cheers! \n\n 40\n\n read \n\n 26\n min\n\n post by eboado on Sep 4, 2023\n\n eboado\n\n Regular\n\n Really nice to see community members like @EzR3aL, who have been active in this forum (and the whole Aave) since the beginning, stepping up and creating delegate platforms.\nBest of luck @EzR3aL and highly recommended to delegate!\n\n post by Hazbobo on Sep 4, 2023\n\n Hazbobo\n\n Excited to see this delegate platform! Would encourage people to delegate, EzR3al has proven themselves to be a dedicated community member who cares deeply about Aave and has informed opinions about the protocol!\n\n post by OzBorg on Sep 4, 2023\n\n OzBorg\n\n Guess what? I’m totally in for an awesome ride with our buddy Ezr3al’s initiative!\nbest of luck buddy.\nXBorg community definitely supports you !!\n\n post by JosepBove on Sep 6, 2023\n\n JosepBove\n\n Best of luck, definitely someone worth delegating to!\n\n post by EzR3aL on Sep 7, 2023\n\n EzR3aL\n\n Regular\n\n Hello all,\nfirst of all i want to thank you all for the support in terms of kind words, already received delegations and likes.\nI will from now on use this post to document my voting decisions.\nAgain, thank you everybody!\n\n post by EzR3aL on Sep 10, 2023\n\n EzR3aL\n\n Regular\n\n Reserve Factor Updates - Polygon Aave v2\nVote: YES\nRationale: v3 is up and running, people should be encouraged to migrate\nSigma Prime Audit Budget Extension\nVote : YES\nRationale: Security is simply important and we shouldn’t save on this\nSupplyCapLSTs\nVote: YES\nRationale: LSTs are important in terms of fees and there is demand\nChaos Labs Risk Parameter Updates\nVote: YES\nRationale: v3 is up and running, people should be encouraged to migrate\nQuarterly Gas Rebate Distribution August 2023\nVote: YES\nRationale: Delegates represent a lot holder and their decisions, reimbursing their costs only makes sense\nAURA OTC Deal\nVote: YES\nRationale: Helping to stabilize GHO peg\nFreeze MAI/MIMATIC, set LTV → 0 for Arbitrum, Avalanche, Polygon, Optimism v3\nVote: YES\nRationale: MIMATIC already had depegging events, so mitigating risk makes sense to protect user and the protocol\n\n post by EzR3aL on Sep 18, 2023\n\n EzR3aL\n\n Regular\n\n Freeze Stewards\nVote: YES\nRationale: Aave V3 already has a steward to mitigate risk, implementing it on other chains only makes sense.\nChaos Labs Risk Parameter Updates _ Aave V3 Ethereum\nVote: YES\nRationale: Monitoring and adjusting parameters is important for a healthy ecosystem\nGauntlet recommendation to set MAI/MIMATIC isolated debt ceiling to 0 for Arbitrum, Avalanche, Polygon, Optimism v3\nVote: YES\nRationale: Logical next step after freezing the asset\nAave V3 Ethereum MKR Debt Ceiling Update\nVote: YES\nRationale: Some user weren’t able to migrate to V3 because of the deb ceiling. This further incentives people moving from V2 to V3.\nGHO Borrow Rate Update\nVote: YES\nRationale: Necessary step to get GHO to 1$ peg\n\n post by EzR3aL on Sep 24, 2023\n\n EzR3aL\n\n Regular\n\n Rescue Mission Phase 2, 3\nVote: YES\nRationale: Its helping to recover lost funds, definitely gonna support this one.\nAave <> Immunefi program activation\nVote: YES\nRationale: Security is as always important and needed, Aave is the benchmark for this and shall be in the future.\nCRV Aave V2 Ethereum LT Reduction\nVote: YES\nRationale: Mitigate risk, incentivise people to move to V3\n\n 14 days later\n\n post by EzR3aL on Oct 8, 2023\n\n EzR3aL\n\n Regular\n\n Gauntlet recommendation to set WETH slope 1 to 3.3% on v3 markets, excluding Ethereum v3\nVote: None\nRationale: Missed this voting unfortunately\nReserve Factor Updates - Polygon Aave v2\nVote: YES\nRationale: incentivise people to move to V3\nTokenLogic Service Provider Proposal\nVote: YES\nRationale: TL has proved themselves to be a great fit for the DAO\nTreasury Management - Create AGD GHO Allowance\nVote: YES\nRationale: Pushing GHO into other DAOs is the first step to get GHO recognized and being used\nAave treasury RWA Allocation Part I\nVote: YES\nRationale: Curious to see Aave stepping into RWA with a small amount, lets see what this will bring in the future in terms of revenue/risk\nExpansion of Orbit\nVote: YES\nRationale: Supporting other delegates is important, especially the ones helping to improve Aave\nTreasury Management - Polygon v2 to v3 Migration\nVote: YES\nRationale: support and push V3, use funds for payments and much more\nTUSD Offboarding Plan Part II\nVote: YES\nRationale: Mitigate risk\nOP Risk Parameters Update\nVote: YES\nRationale: Open OP for the market to borrow\n\n 14 days later\n\n post by EzR3aL on Oct 23, 2023\n\n EzR3aL\n\n Regular\n\nAdd DebtSwapAdapter as FlashBorrower\nVote: YES\nRationale: feature to perform debt swaps without needing to pay additional fees, which is great.\n\nGauntlet Recommendations to Lower stMATIC/MaticX …\nVote: YES\nRationale: Risk adjustments for LST\n\nGauntlet Recommendations to Lower WETH Variable B…\nVote: YES\nRationale: Risk adjustments for LST & aligning settings for WETH on all chains, potential additional revenue\n\nv2 Deprecation Plan, 2023.10.03\nVote: YES\nRationale: Pushing V3 is the goal\n\nSTG onboarding on AaveV3 Ethereum Market\nVote: YES\nRationale: Additional revenue for the protocol, new token for user overall improving the protocol.\n\nFund GHO Liquidity Committee\nVote: YES\nRationale: Very important one for the future of GHO, this is the first step into getting GHO to peg, recognized by way more user and establishing a real decentralized stablecoin.\n\nKNC onboarding on AaveV3 Ethereum market\nVote: YES\nRationale: Additional revenue for the protocol, new token for user overall improving the protocol.\n\nGovernance V3 Activation\nVote: YES\nRationale: V3 would have been the biggest change for governance for years, due to some problem the AIP has been cancelled and delayed a few weeks.\n\nTokenLogic Hohmann Transfer\nVote: YES\nRationale: Adding TokenLogic to the Orbit programm is a no brainer, they have been very active towards the DAO especially with pushing GHO.\n\nGHO Funding\nVote: YES\nRationale: Using GHO to pay for the DAO expenses is showing the willingness of everybody involved to push GHO further and give it strength\n\nEnable borrow of OP token\nVote: YES\nRationale: Adjustment of the OP token to enable borrowing\n\nFuther Increase GHO Borrow Rate\nVote: YES\nRationale: Even if changing rates frequently isn’t great, it is needed to get GHO to peg. Especially because of sDAI and its 5%, its giving pressure to token like GHO.\n\nEvents Funding\nVote: YES\nRationale: The Aave companies are attending different events which need to be visited to be and stay visible to the community. For the future I would like to see a recap of those events and their costs in total. Quarterly reports would be sufficient imo.\n\n 20 days later\n\n post by EzR3aL on Nov 12, 2023\n\n EzR3aL\n\n Regular\n\nPrices operational update. Unify disabled fallbac…\nVote: YES\nRationale: Align all instances to make it easier for future operations.\n\nEnhancing Aave DAO’s Liquidity Incentive Strategy…\nVote: YES\nRationale: Supporting GHO and deepen the parthernship with Balancer\n\nReserve Factor Update October 2023\nVote: YES\nRationale: Incentivize user to migrate to V3\n\nTransfer Assets From Polygon To Ethereum Treasury\nVote: YES\nRationale: Fill up the Ethereum treasury for all payments, liquidity strategies and so on.\n\nGovernance v2.5 Activation\n Vote: YES\nRationale: Important step to governance V3\n\nACI Phase II\n Vote: YES\nRationale: The ACI has been pushing the DAO to its limits which is really positive.\n\nAave v3 Gnosis Activation\n Vote: YES\nRationale: New market with great potential and future. Enables the DAO to collect more fees.\n\nDisable Stable Borrows\n Vote: YES\nRationale: Security is always the no. 1 priority for me, thats why i voted YES to deactivate stable borrows.\n\nMultichain Stable Debt Token Upgrades\n Vote: YES\nRationale: See the previous vote\n\nChaos Labs Risk Management Renewal\n Vote: YES\nRationale: Chaos Labs have been outstanding for the DAO and always delivered top notch work, happy to have them here.\n\nLiquidations Grace Sentinel activation\n Vote: YES\nRationale: Giving the Aave guardian the option to unpause markets when needed and thus act faster. (Security feature)\n\nAave V2 Ethereum LT Reduction\n Vote: YES\nrationale: Incentivize user to move to V3\n\nActivate Freezing Steward on v3 missing networks\n Vote: YES\nRationale: allows the emergency admin to freeze reserves if needed\n\nFixed REP price feed on AAVE v1\n Vote: YES\nRationale: Alternative to chainlinks price feed on V1\n\nGHO - Increase Borrow Rate\n Vote: YES\nRationale: Helping GHO reach its peg\n\nAmendSafetyModuleAAVEEmissions\n Vote: YES\nRationale: The reserve won’t have Aave forever and it is costing the DAO a lot. Reducing and looking for yield alternatives is the correct way and the proposed model was the best out of 3.\n\nReserve Factor Updates - Polygon Aave v2\nVote: YES\nRationale: Incentivize user to move to V3\n\nUpgrade Aave V3 ETH Poool wETH parameters\n Vote: YES\nRationale: Stay competitive, earn more fees (by loops), incentivize more deposits\n\n 12 days later\n\n post by EzR3aL on Nov 24, 2023\n\n EzR3aL\n\n Regular\n\nChaos Labs CRV Aave V3 Polygon LT Reduction\n Vote: YES\nRationale: Mitigating risk for CRV\n\nwMATIC Interest Rate Update\n Vote: YES\nRationale: Interest rate adjustments help user maximizing profits and maybe result in higher borrow rates.\n\nUpgrade Aave V3 ETH Poool wETH parameters\n Vote: NO\nRationale: Double proposal, voted no to ensure no technical problems.\n\nAdd FXS to Ethereum V3\n Vote: YES\nRationale: Frax has been a player for quite a good while with a solid track record. User have been waiting for this asset.\n\nTokenLogic Funding\n Vote: YES\nRationale: Giving the fact that working with TL was always a pleasure, i voted yes.\n\nTreasury Management - Add to rETH Holding\n Vote: YES\nRationale: Diversify the treasury and mitigate risk from single protocols, earn more fees, help Ethereum decentralize more.\n\nIncrease Stablecoin Optimal Borrow Rates\n Vote: YES\nRationale: Optimizing stablecoins borrows on V2 and V3 for optimal borrow rates.\n\nMAI/MIMATIC deprecation, 2023.10.31\n Vote: YES\nRationale: MAI hasn’t regain its peg for several months.\n\nGauntlet recommendation to lower stMATIC, MaticX …\n Vote: NO\nRationale: Im not seeing any risk associated with these assets. Just because it could happen, doesn’t mean its going to.\n\nCRVUSD onboarding on Aave V3 Ethereum\n Vote: YES\nRationale: New and strong stablecoin with great supply, generating fees for the protocol.\n\nChaos Labs Risk Parameter Updates - Increase MKR …\n Vote: YES\nRationale: Supporting the MKR whales to finally switch to V3 fully.\n\nGauntlet Cap Recommendations for Polygon v3\n Vote: YES\nRationale: Ensure safety of the Aave V3 Polygon, by adjusting parameters.\n\nIncrease GHO Borrow Rate\n Vote: YES\nRationale: As long as GHO is depegged its crucial to raise interest rates.\n\nOnboard Native USDC to Aave V3 Optimism\n Vote: YES\nRationale: Replace the bridged version with the native asset (Why circle…)\n\nV2 Deprecation Plan, 2023.11.20\n Vote: YES\nRationale: Incentivize user to switch to V3.\n\nIncrease GHO Borrow Rate\n Vote: NO\nRationale: Double proposal, voted no to ensure no technical problems.\n\nAmendSafetyModuleAAVEEmissions\n Vote: YES\nRationale: From economical perspective an important step, lowering sell pressure, and first step to a new version of the SM.\n\n 11 days later\n\n post by EzR3aL on Dec 6, 2023\n\n EzR3aL\n\n Regular\n\nAllow Emergency Admin to freeze on Aave V2\n Vote: YES\nRationale: Safety measure to protect user and the protocol\n\nUpdate PriceOracleSentinel\n Vote:YES\nRationale: Unify systems, make the network easier to understand.\n\nAave Funding Updates\n Vote:YES\nRationale: Make sure the DAO has enough funds on the correct network and be able to pay SP, Delegates, risk, etc.\n\nReserve Factor Updates - Polygon Aave v2\n Vote:YES\nRationale: Migrate user from V2 to V3\n\nOnboarding wstETH to Aave V3 on Base Network\n Vote:YES\nRationale: New asset, generating fees, making revenue for the DAO\n\nAave Governance V3 Activation\n Vote:YES\nRationale: The next big step for governance and the DAO, more powerful, better, faster and stronger.\n\nGauntlet <> Aave Renewal 2023\n Vote:NO\nRationale: You might be asking why? As i always say risk is crucial and think 2 independent opinions are important. While this is correct, i do think Gauntlets quality and response time decreased over time, while other risk provider came out of nowhere and delivered fast and easy to understand. The decision i made probably won’t make any difference while the major part of the DAO voted YES but this should let Gaunlet know, that they could loose the DAO in the future as a customer if they don’t deliver or keep up with the competition. There are other risk provider that can be onboarded and probably would be happy to serve the DAO.Competition is important and needed, if you don’t have any you get lazy. This is a wake up call to every SP.\n\n post by EzR3aL on Dec 11, 2023\n\n EzR3aL\n\n Regular\n\nChaos Labs RF and IR Updates - Aave V2 Ethereum\n Vote:YES\nRationale: winding down the V2 markets\n\nTransfer AURA to GLC Safe\n Vote:YES\nRationale: Strategy for the GLC to support peg and make use of otherwise idle assets.\n\nGHO update on Aave V3 Ethereum Pool for 13/11/202…\n Vote:YES\nRationale: fix of an GHO integration issue to keep security levels as high as possible\n\n 16 days later\n\n post by EzR3aL on Dec 28, 2023\n\n EzR3aL\n\n Regular\n\nGauntlet recommendation to reactivate CRV borrowi…\n Vote: YES\nRationale: CRV is a strong and known asset, with new parameter it is safe again to list it.\n\nSync emergency admin on v2 AMM\n Vote: YES\nRationale: Align systems and make everything less complicated\n\nActivate Proof of Reserve\n Vote: YES\nRationale: Giving more security in case of depegged bridge assets on Avalanche.\n\nTreasury Management - Add to rETH Holding (resubm…\n Vote: YES\nRationale: Use the idle wETH in form of rETH and generate yield.\n\nChaos Labs V2 Ethereum and Polygon LT Reductions\n Vote: YES\nRationale: Push the V3 market and depreciate V2 markets.\n\nIncrease Polygon wstETH Supply Cap\n Vote: YES\nRationale: We need more space for user \n\nIncrease GHO Borrow Rate 100 bps to ~6.41% on Aav…\n Vote: YES\nRationale: Defending GHOs peg\n\nTokenLogic & karpatkey Service Provider Partnersh…\n Vote: YES\nRationale: Both have been serving the DAO great and can achieve even more together.\n\nPolygon V2 Reserve Factor Updates\n Vote: YES\nRationale: Push the V3 market and depreciate V2 markets.\n\nOnboard Native USDC to Aave V3 Markets\n Vote: YES\nRationale: Currently there are plenty different bridged versions available and the supply is shrinking, making it a dying asset. Therefor we need the native asset USDC supported by Circle.\n\nContinuous Security Proposal Aave <> Certora\n Vote: YES\nRationale: Security over everything.\n\nUpdate GNO Risk Parameters on Aave V3 Gnosis Pool\n Vote: YES\nRationale: Constant monitoring of assets and making adjustments for safety.\n\nTransfer all CRV positions from Ethereum Mainnet …\n Vote: YES\nRationale: Use the idle CRV positions to generate more yield for the protocol.\n\nRequest for Bounty Payout - December 2023\n Vote: YES\nRationale: Individual identified a bug and reported it as a whitehat. Again, security over everything.\n\nTreasury Management - Polygon v2 to v3 Migration\n Vote: YES\nRationale: Managing treasuries from V3.\n\nAave Governance V3 Activation Short\n Vote: YES\nRationale: Huge next step in terms of governance.\n\n post by EzR3aL on Dec 28, 2023\n\n EzR3aL\n\n Regular\n\n With the activation of governance v3 all delegations have been reset. This means that any person, that delegated to me before wants me to vote again with their voting power, needs to re delegate.\nSimply visit this website made by @bgdlabs Aave Governance (onaave.com), connect your wallet and then choose the asset you want to delegate to me and enter my ens ezr3al.eth.\nFeel free to contact my via Telegram or X if you do have any questions.\nThank you for your support.\n\n 27 days later\n\n post by EzR3aL on Jan 24, 2024\n\n EzR3aL\n\n Regular\n\n Aave Pool update\nVote: YES\nRationale: Security measurement to fix V3 instances.\nPolygon V2 Reserve Factor Updates\nVote: YES\nRationale: Slow shutdown of V2 to migrate user to V3\nChaos Labs Risk Parameter Updates - WBTC.e on V2 and V3 Avalanche\nVote: YES\nRationale: Risk mitigation\nStablecoin IR Curves Updates\nVote: YES\nRationale: Alinging all Aave instances making it easier for user and risk management.\nV2 Deprecation Plan, 2024.01.02\nVote: YES\nRationale: Offboarding V2 in favor for V3\nAave Funding Updates (part 2)\nVote: YES\nRationale: Many different networks capture value for the DAO, by alinging them its easier to understand what the treasury is holding and manage those funds.\nAave v3 BNB Activation\nVote: YES\nRationale: New market, new revenue stream, new oppotunities. Have fun!\n\n 12 days later\n\n post by EzR3aL on Feb 6, 2024\n\n EzR3aL\n\n Regular\n\n StkGHO Activation\nVote: YES\nRationale: This version of GHO is helping to keep the peg, offer yield to staker and secures the protocol.\nGHO Stability Module\nVote: YES\nRationale: Helps keeping the peg when GHO >1$, several other very important features.\nReserve Factor Updates (Jan 15, 2024)\nVote: YES\nRationale: Depreciate V2\nRequest for Bounty Payout - January 2024\nVote: YES\nRationale: As I value security over everything I support the white-hats and want to thank them for pointing to bugs.\nUpdate ETH EMode and WETH Risk Params on Aave v3 Ethereum, Optimism and Arbitrum\nVote: YES\nRationale: Observing the market and thus adjusting parameter.\nRegister a.DI Ethereum → Scroll adapter\nVote: YES\nRationale: Expanding a.DI, aliging infrastructure.\nHarmonize USDT Risk Parameters on Aave V3 Markets\nVote: YES\nRationale: Better asset management and easier for user of different markets.\nTreasury Management - GSM Funding & RWA Strategy Preparations (Part 1), Frontier Staking as a Service\nVote: YES\nRationale: Financial AIP to be able to pay for everything.\nAave V1 Deprecation\nVote: YES\nRationale: No need for V1 anymore.\nAMPL Interest Rate Updates on V2 Ethereum\nVote: YES\nRationale: Mitigate risk for user and the protocol.\nOnboard fdUSD to Aave v3 on BNB chain\nVote: YES\nRationale: New asset, more fees and revenue.\nFreeze and set LTV to 0 for DPI, BAL, CRV, and SUSHI on Aave v3 Polygon, 2024.01.19\nVote: YES\nRationale: Freeze old assets that don’t have any value to the protocol.\nGauntlet recommendation for MAI / MIMATIC deprecation phase 2\nVote: YES\nRationale: MAI depegged and thus created a risk to user.\nAave v3 Scroll Activation\nVote: YES\nRationale: New market\n\n 12 days later\n\n post by EzR3aL on Feb 18, 2024\n\n EzR3aL\n\n Regular\n\n stkABPT Balancer V2 migration\nVote: YES\nRationale: Update to the newer v2 SM\nMigration of remaining Gov v2 permissions & DAO’s Paraswap positive slippage\nVote: YES\nRationale: Moving everything from v2 to v3.\nV2 Ethereum LT Reductions\nVote: YES\nRationale: Depreciate v2 for v3\nReserve Factor Updates (Jan 31, 2024)\nVote: YES\nRationale: General update for RF\nAdd PYUSD to Aave v3 Ethereum Pool\nVote: YES\nRationale: TradFi token coming to Aave, what a time to be alive.\n[ARFC] Deprecate Aave V2 AMM Market - Step 2\nVote: YES\nRationale: Depreciate v2 for v3\nRetroactive Bug Bounty Pre-Immunefi\nVote: YES\nRationale: Security over everything, always.\nSnapshot:\n[TEMP CHECK] Integrate Oval for the BAL & SNX Ethereum V3 Markets\nVote: NO\nRationale: I have already expressed several points and concerns regarding the Oval approach. Oval seems to be approaching a potentially significant area for exploration. While MEV has always been a consideration, the concept of OEV had not crossed my mind before this proposal. However, I prioritize security above all else, as I committed to monitoring it consistently when initiating this delegate platform.\nOval has raised some apprehensions with its current approach. Even though it would have only been tested in a small, isolated market, I am hesitant to embrace it. If something were to go wrong, the user might bear the consequences, which is the worst-case scenario. Brand recognition is crucial and takes time to build. It shouldn’t be jeopardized by experimenting with something new unless it has undergone thorough testing.\nIt could be assumed that I lack the technical knowledge to fully comprehend everything. While this may be true to some extent, I consulted with other experts before making my voting decision. Different parties have presented promising solutions, and it’s essential to evaluate what is best for Aave, its users, and, in this specific case, its liquidators – the final barrier against accumulating bad debt.\nI would prefer to see a more broadly researched solution for Aave overall, and I encourage everyone to participate in this initiative. Although I voted NO, it was not a rejection of Oval or UMA but rather a stance against the TEMP CHECK proposal. I was advised to vote abstain, but that would imply potential support for Oval, which I cannot endorse in its current form, hence the NO vote. However, I am open to alternative solutions and willing to contribute where I can.\n\n Load more posts below","tokens":5751,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263187727,"hash":"381ae6a8e111ad211551c5d12122fcdd8c190ffe"}
{"url":"https://ethresear.ch/t/spread-extending-gossipsub-with-efficient-anonymous-dissemination/25343/5","domain":"ethresear.ch","title":"SPREAD: Extending GossipSub with Efficient Anonymous Dissemination - Networking - Ethereum Research","text":"Networking\n\n p2p,networking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n read \n\n 10\n min\n\n Jul 1\n\n 5 / 5\n\n Jul 16\n\n Jul 16\n\n post by MatheusFranco99 on Jul 1\n\n post by Nashatyrev on Jul 3\n\n post by MatheusFranco99 on Jul 8\n\n post by MatheusFranco99 on Jul 10\n\n MatheusFranco99\n\n Hey @Nashatyrev, following up with some numbers:\n\nOptimizing exclusively for dissemination: our best configuration improves on every performance metric against GossipSub (numbers in the table below), while suffering on the anonymity side with 41% of attacker accuracy (for when attackers control 10% of the network) vs. 38% from GossipSub.\n\nMetric\nmean latency\np95 latency\np99 latency\nmean stretch\np95 stretch\np99 stretch\n\nLowered by\n24%\n26%\n30%\n38%\n58%\n60%\n\nFor the “same or better anonymity than GossipSub”: a tunned configuration can produce lower attacker accuracy (30% vs. GossipSub’s 38%) while still improving considerably all performance metrics.\n\nMetric\nmean latency\np95 latency\np99 latency\nmean stretch\np95 stretch\np99 stretch\n\nLowered by\n22%\n24%\n25%\n32%\n51%\n49%\n\nDandelion-level anonymity: we can also configure SPREAD to match Dandelion’s anonymity, beating it slightly on performance, though being considerably worse against the performance-optimized case. The pareto curve:\n\nConfiguration\nAcc@10%\nMean Latency\nMean stretch\n\nBest performance found, but worse than GossipSub on anonymity\n41%\n98 ms\n1.54\n\nStill high-performance, while beating GossipSub anonymity\n30%\n101 ms\n1.69\n\nMid-point\n28%\n104 ms\n1.74\n\nClose to Dandelion\n20%\n143 ms\n2.87\n\nDandelion-level anonymity, but worst performance\n11%\n207 ms\n4.76\n\nI ran these simulations overnight, but I plan to run these for a few more days to try to find even better configurations and increase the sample size.\n\n post by kamilsa on Jul 16\n\n kamilsa\n\n Thanks a lot for this work. Results are super interesting.\nIt would also be useful to investigate how much long-term privacy SPREAD provides when applied specifically to Ethereum.\nOne of Ethereum’s main network-layer deanonymization is attestation gossip. Each validator produces a signed attestation once per epoch. An epoch contains 32 slots and lasts 384 seconds.\nWith 5% of curious nodes an attacker has 20% attack accuracy (according to your results). In my understanding, this is the result for a single epoch vote. For n𝑛 epochs the attack accuracy (probability of a correct guess by attackers) is: p(n)=1-(1-0.2)^n𝑝(𝑛) =1 −(1 −0.2)𝑛, which gives us the following attack accuracies:\n\n50% after roughly 3–4 epochs\n80% after 7–8 epochs\n90% after 10–11 epochs\n95% after 13–14 epochs\n99% after 21 epochs\n\nThis means that even fairly low per message deanonymization attack accuracy gives limited protection when the same validator produces the message on a regular basis (which is the case for attestation protocol).\nThat said, for other places in the protocol where peers emit messages less regularly SPREAD should indeed provide more privacy protection\n\n Powered by Discourse","tokens":749,"squid":"ink-research","role":"Deep Scholar","at":1791263193873,"hash":"64eb902d91a61d42810400d9018ddc5402d31f79"}
{"url":"https://forum.openzeppelin.com/t/how-to-change-rate-price-of-a-token-in-crowdsale/4845/5","domain":"forum.openzeppelin.com","title":"How to change rate/price of a token in Crowdsale? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n 2\n\n Nov 2020\n\n 5 / 10\n\n Dec 2020\n\n Jan 2022\n\n post by PradhumnaPancholi on Nov 29, 2020\n\n PradhumnaPancholi\n\n So, I am trying to write a sale contract which increases the price or modifies the rate of a crowdsale after each purchase(when buyTokens is called). I was going to implement it with a state variable the adds (+1) each time when buyTokens is called. And writing a custom buy method. But, I just realized that there is no method to change rate. Or is it and I miissed it? Can someone help me on this?\n\n Rate for Crowdsale\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by Skyge on Nov 30, 2020\n\n Skyge\n\n Yeah, if you want to change the rate, you need to add it by yourself.\n\n post by PradhumnaPancholi on Dec 1, 2020\n\n PradhumnaPancholi\n\n Yes, but I am currently struggling to get the rate in my contract. How am I suppose to access it and modify it? It’s a private variable\n\n post by Skyge on Dec 1, 2020\n\n Skyge\n\n Maybe you can have a look at this doc: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n PradhumnaPancholi\n\n Hi @PradhumnaPancholi,\nThere is an IncreasingPriceCrowdsale in OpenZeppelin Contracts 2.x that you could use for inspiration.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\n 1 year later\n\n post by ZrowGz on Jan 16, 2022\n\n ZrowGz\n\n Hello, I was looking at setting the token price equal to, say, $1 per minted token. I know I can calculate how many wei a dollar is and set that price at deployment, but I was hoping that there is a way to check this each time the token is minted.\nOr, could I simply have the rate pegged to a different token (instead of eth), so that it would only mint when it receives USDC? Such that the rate could still be \"1\" but it only responds to USDC or FRAX or something along those lines. Or does it just utilize the chain's base token: if deployed on Polygon, a rate of 1 would be 1 TOK for 1 matic? (I would think that it would be in the chain's base coin, since that is the gwei you're paying your gas in)\nFor example, I deploy when 1 eth = $3000, I could code in that you'd get 3000TOK for 1 eth. But then the price could climb to $4000 which would still only issue 3000 TOK.\nThank you!\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nWhy is the rate() function revert?\n function rate() public view returns (uint256) {\n revert(\"IncreasingPriceCrowdsale: rate() called\");\n }\n\nWouldn't it be useful if it returned the current rate value knowing that it precisely changes over time?\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nYou will have to connect your smart contract to an oracle that returns the price of the token you need and thus update it from time to time.\nhttps://docs.chain.link/docs/get-the-latest-price/\n\n post by ZrowGz on Jan 17, 2022\n\n ZrowGz\n\n Thanks for the link to that! Is there instead a way to tell it to accept only a different token, like USDC?\nAlso, does the wei rate calculate in comparison to the chain's base token, like MATIC on Polygon?\n\n post by Cainuriel on Jan 18, 2022\n\n Cainuriel\n\n I cannot answer your questions because although I know this service I have never used it. Maybe another reader can help you.\n[image]\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Increasing Price Crowdsale\n\n Contracts\n\n erc20,crowdsale\n\n 2\n\n 1.1k\n\n Nov 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020","tokens":985,"squid":"ink-security_audits","role":"Sentinel","at":1791263200779,"hash":"61a5bb802d8ff7f9daea6244e0a8da3195f3ed46"}
{"url":"https://dev-forum.pyth.network/t/historical-price-feed-in-03-01-2023/380/11","domain":"dev-forum.pyth.network","title":"Historical Price Feed in 03/01/2023 - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 5\n\n Sep 2025\n\n 12 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by makimakiver on Sep 2, 2025\n\n post by KemarTiti on Sep 5, 2025\n\n KemarTiti\n\n makimakiver\n\n Sadly you cannot export such amount of data from Benchmarks endpoints.\n\nif I can get address of price feed used at that time\n\nShould be the same - which one are you currently trying with?\n\nI am using the API via this website: Benchmarks - Swagger UI REST API Specification for Brokers — TradingView\n\nYes this is still Pyth data you are using/calling here however Confidence Intervals are not a traditional data point TV has and so does not support those from Pyth\n\n post by makimakiver on Sep 5, 2025\n\n makimakiver\n\n Hi currently looking at the USDT price feed account on pythnet in solscan but I can’t see any data published in 2023 March… though as I could see it on trading view does it mean I’m looking at wrong address?\nThe address of the price feed is mentioned in the first question.\n\n post by KemarTiti on Sep 6, 2025\n\n KemarTiti\n\nhave you replaced the url of the rpc to a pythnet one?\n\n post by makimakiver on Sep 6, 2025\n\n makimakiver\n\n sorry can you elaborate more about replacing the url?\n\n post by KemarTiti on Sep 9, 2025\n\n KemarTiti\n\n How are you able to see/connect to Pythnet? What RPC (URL) are you using?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 757\n\n Apr 2\n\n Powered by Discourse","tokens":1416,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263200826,"hash":"b3dc4d48f9c5961339979e3376351efda7e9f858"}
{"url":"https://forum.openzeppelin.com/t/how-to-change-rate-price-of-a-token-in-crowdsale/4845/6","domain":"forum.openzeppelin.com","title":"How to change rate/price of a token in Crowdsale? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n 2\n\n Nov 2020\n\n 6 / 10\n\n Jan 2022\n\n Jan 2022\n\n post by PradhumnaPancholi on Nov 29, 2020\n\n PradhumnaPancholi\n\n So, I am trying to write a sale contract which increases the price or modifies the rate of a crowdsale after each purchase(when buyTokens is called). I was going to implement it with a state variable the adds (+1) each time when buyTokens is called. And writing a custom buy method. But, I just realized that there is no method to change rate. Or is it and I miissed it? Can someone help me on this?\n\n Rate for Crowdsale\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by Skyge on Nov 30, 2020\n\n Skyge\n\n Yeah, if you want to change the rate, you need to add it by yourself.\n\n post by PradhumnaPancholi on Dec 1, 2020\n\n PradhumnaPancholi\n\n Yes, but I am currently struggling to get the rate in my contract. How am I suppose to access it and modify it? It’s a private variable\n\n post by Skyge on Dec 1, 2020\n\n Skyge\n\n Maybe you can have a look at this doc: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n PradhumnaPancholi\n\n Hi @PradhumnaPancholi,\nThere is an IncreasingPriceCrowdsale in OpenZeppelin Contracts 2.x that you could use for inspiration.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\n 1 year later\n\n post by ZrowGz on Jan 16, 2022\n\n ZrowGz\n\n Hello, I was looking at setting the token price equal to, say, $1 per minted token. I know I can calculate how many wei a dollar is and set that price at deployment, but I was hoping that there is a way to check this each time the token is minted.\nOr, could I simply have the rate pegged to a different token (instead of eth), so that it would only mint when it receives USDC? Such that the rate could still be \"1\" but it only responds to USDC or FRAX or something along those lines. Or does it just utilize the chain's base token: if deployed on Polygon, a rate of 1 would be 1 TOK for 1 matic? (I would think that it would be in the chain's base coin, since that is the gwei you're paying your gas in)\nFor example, I deploy when 1 eth = $3000, I could code in that you'd get 3000TOK for 1 eth. But then the price could climb to $4000 which would still only issue 3000 TOK.\nThank you!\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nWhy is the rate() function revert?\n function rate() public view returns (uint256) {\n revert(\"IncreasingPriceCrowdsale: rate() called\");\n }\n\nWouldn't it be useful if it returned the current rate value knowing that it precisely changes over time?\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nYou will have to connect your smart contract to an oracle that returns the price of the token you need and thus update it from time to time.\nhttps://docs.chain.link/docs/get-the-latest-price/\n\n post by ZrowGz on Jan 17, 2022\n\n ZrowGz\n\n Thanks for the link to that! Is there instead a way to tell it to accept only a different token, like USDC?\nAlso, does the wei rate calculate in comparison to the chain's base token, like MATIC on Polygon?\n\n post by Cainuriel on Jan 18, 2022\n\n Cainuriel\n\n I cannot answer your questions because although I know this service I have never used it. Maybe another reader can help you.\n[image]\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Increasing Price Crowdsale\n\n Contracts\n\n erc20,crowdsale\n\n 2\n\n 1.1k\n\n Nov 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020","tokens":985,"squid":"ink-security_audits","role":"Sentinel","at":1791263211309,"hash":"99af6c672e0f769039682b8891ac940e2a8b3b5c"}
{"url":"https://dev-forum.pyth.network/t/error-price-feed-gaps-in-public-price-feed/203/1","domain":"dev-forum.pyth.network","title":"Error price feed: Gaps in public price feed - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Error price feed: Gaps in public price feed \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n Jun 2025\n\n 1 / 15\n\n Jun 2025\n\n Apr 2\n\n post by chrisbuildthis on Jun 9, 2025\n\n chrisbuildthis\n\n ‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’\n• Chain (e.g. Ethereum mainnet, Solana devnet, etc.)\nSolana Mainnet\n• Timestamp of the issue (block time or UTC)\nGaps in data so we log and track all data. this is how much gaps we get and it gets worse with time.\n2025-06-04T10:07:42Z\n1749031662\n2025-06-04T10:07:43Z\n1749031663\n2025-06-04T10:12:50Z\n1749031970\n2025-06-04T10:12:51Z\n1749031971\n2025-06-04T10:21:54Z\n1749032514\n2025-06-04T10:34:01Z\n1749033241\n2025-06-04T10:34:50Z\n1749033290\n2025-06-04T10:45:22Z\n1749033922\n2025-06-04T10:47:23Z\n1749034043\n2025-06-04T10:06:06Z\n1749031566\n2025-06-04T10:09:18Z\n1749031758\n2025-06-04T10:13:18Z\n1749031998\n2025-06-04T10:17:19Z\n1749032239\n2025-06-04T10:21:51Z\n1749032511\n2025-06-04T10:34:27Z\n1749033267\n2025-06-04T10:44:18Z\n1749033858\n2025-06-04T10:47:24Z\n1749034044\n2025-06-04T10:47:49\n1749034069\n2025-06-04T10:47:50Z\n1749034070\nExample for the streaming one that kept breaking down:\ncurl -X ‘GET’ \n‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’ \n-H ‘accept: application/json’ --http1.1\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d00760e4a25bf5f623f3386cba8f6a49e3c5928a025de9546d08e3e14493a1dc4072e88b01a52e8d86b5488991ee552e14889c9e15b89b1920741dd2861ac83a27301033740fdcb27395f695a65518fa598103153fa89dc645b63eebe934230209203ed59b47edd864559ea828e74533ee89badb7fe37ad33b96f37f1b1bed627cd78f6010475036ef9b293dd9e534e2dd375cc03f2fd95dd31fbdf3d4949257d650b7020086405cee9e9c0b16cda66acc4b15fef3bb0b45f459aeb790530a39df56f0a23fd0106924db4e607d82c45a465c5f3653573ab43c5f44e9b469aa9911710988e0154183c4f6e70df5dc8d43996377a216317aef46e8cf2368178f94b7002ef595824be0008b8a528ea9f92f1dec6810333354b06f9a44fbb10eeed8dc2bc0f518429e018ed5aff41e60faca0a3df98b62439f3f56266a6c85b010d0cb8c74a9d6e452602e9010a9b2d5473df63c5eaebc8c1073002158428cee5ac9801d30b528a85e5ee379afe13ff8cbd95951b33fe03df5eba25c3a04ba620c1197a38afd897752ed1d6b78d010b74b42c350dc4c9f669b98115de621807e3996f4912cea42da49216f3ce8e2f11376ef94f74132cc28c3fd1831fac354f339c24e92c9482591731a2dc50b2477e010d197e99d27de64896d6b27ed8bd16a308a6507e0c12c97b4fa76850fdab1c1a28483d59921042b2242e92776f694f35597ce8a233f6c5e607ce2d01bc010102c6000ee6de48023ebdab7a3fec5dc7e8a9dafb4b0e416cca81708a6dad1db3679f28ab5fdd1205435439f4c00d9b35d9ca247664175d71a9049e59a77c054b976754d6010f96454eb53f4de6db8b5997c339b1090d5d7ef4b6dc0a9470d74ed1cc54412dd5144d708a8b03013225c57512abc3dd0d8ebdb7cb377a09d640282669560b86b100100c5f23cb9c8047c75ac3217e952cbc75af66650fe62c6d0f6b422160ffa5b2a2259194f3f0e1879998168cf552fd398beedba9c190f501f24f02aa8bf40970c60011ea5a3740d9b7b0bf54fd5debce6b7c4ababe40c5c6bb351de97b77fcdea297aa6705b616908074a3680206eb46272e9211dd433a42b0421a34c5dcbf9df8e2b501126121106c8aa1f6b25aba95f4dc8ed0a3964760b1d542f56e37dce1781ec425d418927c150e26a975c058b33f8c1af8fbe22b24e23c5da22655ca3ebf142a21ce016841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d902014155575600000000000d345aaa000027102cc52522bf49430ad67780c7ebeadcdb013d35f401005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bd8c2bf0000000124a62711fffffff8000000006841e742000000006841e741000009665b3f76c000000001006ef4500c944d5e62d2e0dec821cb3523b2a9e7b9492dad4d6626dc08f99788dfcea56c58d9559bd6f796e38b837231abd868a14ab9a7473b7c68cc289202057206ad4ed2a6650169b808cd0217f0b46ad7a2159d5f514a3342f8987e153265d9cda2a23897907e9813e028ebbefb49de4a04590da653a58b7c1d242a2f1da520b2c872950a8db588dfdad8a17d89e5e8dcfaa5b9b725137ffeaaecdbf7ff617560beaec6c79714ca72bc4ccb67593ad04b71a151b4da527c361cb9cca22559405595fe9b1cd147b14e1d1433648126dba1df1a062b9b29857957a12c33a51200a5806d6cee404f650789310f46d5f07ee15a3658”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316710199999”,“conf”:“4909836049”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335222200000”,“conf”:“4302238800”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534890,“proof_available_time”:1749149507,“prev_publish_time”:1749149505}}]}\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d001dc9c51d9f0317c7c74d34b74cc6eda6f4158ed719881410d8524f8c793d9dc57277efd5080764da7a558097e17015706b126514befeef544c48c29a5dce43f00002bb28b3dcada54ec8d2aaac0a7ef557c3e895143003163ec2ac935a22bacac2f65b75acdd0470e2f7cdae807cfc614ddf61e732af192725ca313d0a4b7421ef3f0003560cfc8c3583f99cee1dcfcf414d0ecd0ac863b09dd66f67a1b1ec420e2fe8936b28628837f5e8f1d845b1311a9ca70011173cdea58fc4f093f640c5437a340100041c5cc17559b6a2ab29202a6bf902ec1f731195892303a3f26b825055d682a617222e4a28a14f395ab304dc4a5b63516808b3eb060004b69f4fd8dc1af8c8c47800064f8609b4af9ecd62b90af4f7c79db18e73a20d86a38912763a0a0f693ee872655baa6017da10a2d82ca1576ccd93976f14938f74f8322745763b806ff2f4845601088877f2ebf7a92efad7f458eca8db5c3d07fc7585fe37b52d0f5243460c7058207f5a07aaaad9a84938d80c0cc5615a75b925786e3c81525ba4e5c214c056e1cc000a98e5c795727915c025c8d03f633d0684e36c231552c5b3217848f128fec91baa370900a7240fda2fd818c9eb71016e5b8349086eed7429aa333e35677fd5628c000bf094d0ae614df5e8d253cf3db41e1d2728a95e9282f8c9e61a05d0a03d899b3b1fc025cee6e04df4a1609d9bbda0da28116b73d9c6daaef9ee8d38bc252db96d010d1836c4591d42683b7bfcbeab7895d37732b5128b6f20f2bfe06db8b3fe78ad2829d3ef3d835dd3f8225d7be47144a62b38ff90e3fb78419bb914b7a38660b506010e2c6e4d868a0970a52da73e614165b321bf6f191cc4c209e9488807a00eec36dc2fefb04efda9e83216e8537b091ccaa94624009391563a023bcfb7f9640cb048000f8d72884e7cfbcf969b3739225510c3b6a925ec8ad0a3d5271fd1a3ddfb4ce69c5f2f6828e3669a0daf4781600409085acba17ece75c40ca302eb995dddce071101104297798fd9e64d26da2cb904b74df77aea8464ac3b9847f3d59a97ad34a43546456849cd6e2e9f392251c37fab73c6913e90060490b9590011861e1029963d190111b0523875a4f516380d6ec7dbb37462c286354f7f53a560c06ff421db26ceb28e6da8cb8b2187d55ce24ab7e0638cc95f26fde3bf9068dadfc8cc9531eb6942c5006841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d903014155575600000000000d345aab000027109a8197e552dd636a3002f9cfdc902cb8789c95ef01005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bc130ce000000013c327290fffffff8000000006841e742000000006841e742000009665b25862000000001007067cc0c1e0308ac3b12f3b2a8e27c41885d3cf84ef19e4003ade8d6f3d5913c7cbdb080480a26757e59849cb5894c136572792202abc5cfd38eb8d6f1d95151e813597c9e22b12ec34176c3d45dafa7830b5a8ef10840a48fbc45a7a105f693b81e568eab892a5e3f4bd79e4f0a5bfb500046235034ddecde050a3e13de3e484f408a17999c04c5a823f2835ae56beab10f120fa70fcf1cf68735d1e3d4d32456081f631251558317376a29105b4729b0bc6b300ac7c73b4181efea4969228cdb7992825a1c90f1d096a566fba497abdd890307b7edfa8b1a14164e47999fde88fac5a0aa536f41b98f0a31bd3a9bbdc9eab48d”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316708655310”,“conf”:“5304906384”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335220500000”,“conf”:“4302333900”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534891,“proof_available_time”:1749149507,“prev_publish_time”:1749149506}}]}\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d007afc5e654db32909e1a9ab09e64c9927f4985b86a8de9ef4dc6cc22e38d48bcc70ab92cd1aac2f1afd4d335b25cb9bb28a9e1f573bfa667b0bba7885b16f25c60102e0aebbb6d3b06ed493c5b57d95e3437d4446053775e2e2c6918d3a9b521c0e9332989327ab83c1f462bcdee8bdf69620c6270bcbc6523cf167943e217198064101030929d1cf757e64ffa2bb13a12cc648c1d035f36bdb2af3143f1fc55b65b4cd392655cacf65a8c7255e56dee6970b76aacf857d84dd8c6872695959f5b625681e0004a11cb3ac16db430eb50c8af8d177a9208c4d113a5090a800ad6b3ce6f984c03241bb940d97c9dfb7ea76e5fd337628f0c6db1cb005f5641ab977d7e314df6933010647f567cc030b0ec7bac854c73d3f039bd35849ff07ec2ee3b2641f2d605317110f51d27e5317df09b4589c1dcbe203cdbddc2a0c24b20e4b3b39494fc815b4640008373c65d2d4c72b47f908e4a457dd2d8e4fd33f4cd59c304f33ae806736acceb251e63a7622ce73282da15840bad610f378d4aec5baa000fb75aaa8e2fd122770000af8d99184394912fdd6aad7513137fb4dabeb84fd214ea83d3300347feabe998b6380f8250d6805c6fb0408c400d6ed595e40df112bc6fe898c64273a391612ac010b2db12a76c0caf5865989a70af60028184283789b024c263fa6dd3810325eae973db5094c621f985b8ad2c3b108c7b69d195fab8584bb875f4007e776c7354bb0000dd7d0e045584f0017de2fa4426f030c285ba7782cdffe570f31b2fd3ad6e7bbb01b0cf41c8e270b55253693d12c648ac3780d6d1004e08fce7d17ee349947a1b3000ec2502b45ee72c0dcb122150b222bf145d0e0d36a7fe4e7668bc90a2a391836d040d5e5563d73751bcb258845e3114384bd44c1fc965f34027551d5877b5af499000f91a92aaedbb7c0d2d41f3ef13d85792dbad06c1a15ebe4148d7d9eb7fa875ff5677139e55c8a34f72f1c1b03ecd05f9fbc783eb5bc2b1c8fee719f1dd108509d001074836c1fac49e3151e2ac5e320be7ca5985edc0a4b9f9bb191242636d1be77bb7467d0be8b1f892b91320cadcb4aa1f009ebe6163007de39749db166c566d8f60011cdd5e801ea672fe43ada7a8e8c30973c3dd1123296a84feabd85b6233e9f728f7528b11eaf045792f1730a31e3159a1c1a5c6245abd079d10f3a61310e4fc568016841e74300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d904014155575600000000000d345aac0000271063036a46ca40542b4037d842b5152c760c1c152901005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b4300000961fcc34605000000012d3487c7fffffff8000000006841e743000000006841e742000009665b0888400000000100718bfc0cb9593def04dda130fa85b133f427f158d2fcaf25018abb60aa1fee6cee8402b86e5a837695197d52b8c408832ecafcecefc20fdf86e2e9ec9a631f36d350733d2bf45792788b851a3ad7daa859e2946501ca29f4440596cc16018758c50708174faeca9db33397b4bbb88ce32af3f8e3e545c100d715baa5e4025ad060a35ec9b5d524e45dca71926f3e2dc5e682b551b81384aeb7539370fd8d6b4fbfed1a843f3b7c9cc3c13c53ded518e90f07f55f0e78ea4a4df8ba20616199cc57145f7bc29e37ab87f7fae60b19cf588c222839428ac94e732f3d8b33c525d259de84946daba31b76b43ec4714b15cf4e7d39ce”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316457133573”,“conf”:“5053384647”,“expo”:-8,“publish_time”:1749149507},“ema_price”:{“price”:“10335218600000”,“conf”:“4302408700”,“expo”:-8,“publish_time”:1749149507},“metadata”:{“slot”:221534892,“proof_available_time”:1749149508,“prev_publish_time”:1749149506}}]}\ncurl: (18) transfer closed with outstanding read data remaining\n• Name of the dApp/Project that you are building\nPrefer not say. It not a good image of having a broken app due to Data price feed.\n• Contact (Telegram/Email/Discord)\n@unicornDegen\nThe more context you provide, the faster we can help.\nSo we meet the team in Lisabon. We have an app that scalling. The gap in the price feed keeps returning 0 as price. So as a trading app if the data comes back as 0, that means is an error and incorrect.\nIn the app user places bets, betting on the price of what will be solana , app track the price and when it come time to settle we get 0 , and it comes that the user has lost. but they haven’t.\n\n 4\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by 0xcredence on Jun 9, 2025\n\n 0xcredence\n\n gm thank you for your question!\nWill try to get back to you as soon as possible\nAnd also we’ll try to backfill the data gaps if possible. Would you be okay if I provide you with a csv of the missing data?\n\n post by chrisbuildthis on Jun 10, 2025\n\n chrisbuildthis\n\n the history is not the problem. I have 200 User daily waiting to onboard and I can’t if I have don’t certainty that there wont be gaps, or gaps will be filled with 5min timeframe of appearing.\nthe list of data I gaps I gave an example from above.\n\n post by 0xcredence on Jun 10, 2025\n\n 0xcredence\n\n do you mind reaching out to @mariopyth on telegram?\nwould like to learn more about your usecase.\n\n post by ali on Jun 10, 2025\n\n ali\n\n Hi @chrisbuildthis,\nThese gaps happen when the validators don’t reach consensus on that specified time (due to one validator being down/having issues) and while they are rare they are plausible. Please note that in these cases, for instance if a price is missing at time 1749031662, you can use the first price after 1749031664 in this case as the unique price at that time on-chain using this method and fetching it via Hermes using this endpoint will give you that data.\nAs a meta comment, this happens due to the Solana consensus designs which Pythnet is based on that a validator becomes the leader for 1.6 seconds and if they are down, no block is produced. We totally understand that this not good andare working on improving the reliability of every single validator and changing this behaviour in the network.\n\n post by chrisbuildthis on Jun 10, 2025\n\n chrisbuildthis\n\nOK so that is a 2min gap.\nThe question it still not clear if the gap is always there ?\nor do i need to search for the next timestamp that return me a data ?\n\n post by chrisbuildthis on Jun 10, 2025\n\n chrisbuildthis\n\nAlready speaking to everyone in the same TG group. they suggested to post here for better awareness.\n\n post by ali on Jun 11, 2025\n\n ali\n\n @chrisbuildthis\n\nIt’s a 2 second gap.\n\nNo it is not clear or deterministic. If all validators are healthy there’d be no gap. This happens if there is an issue with a validator (like a network issue/…) which is not predictable.\n\nThe API I shared looks forwards to give you the first price update after the asked timestamp. if you subscribe to prices you can enable the verbose flag and you always get prev_publish_time and you can assume that the update is valid between the previous publish time and the current publish time.\n\n 10 months later\n\n post by whsia on Mar 26\n\n whsia\n\nHi @ali , just want to confirm about this, https://hermes.pyth.network/v2/updates/price/1749031662?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\nFor this absent timestamp (1749031662), this kind of request seems like to return the nearest price in the up coming seconds. Is it true that this behavior is always valid? Let’s say T+0 to T+9 are all absent and there’s a price at T+10, when i pass T+0 to hermes endpoint, Will it return a T+10 price and publish_time?\n\n post by whsia on Mar 26\n\n whsia\n\n In case I can not get the answer, sorry to ping moderators here @KemarTiti @Aditya520 .\n\n post by KemarTiti on Mar 29\n\n KemarTiti\n\n Hey @whsia — yes, you’ve got it right.\nThe /v2/updates/price/{timestamp} endpoint will return the first available price update with publish_time >= requested_timestamp. So in your example:\n• Request: T+0\n• If T+0 through T+9 have no data and T+10 does → you get the T+10 price\n• The response’s publish_time field will be T+10, so you always know the actual timestamp of the returned data\nThis is intentional — ensures you can always retrieve a valid, verifiable price for settlement even during gaps.\nFor streaming use cases, Ali mentioned using the verbose flag to get prev_publish_time — you can then assume the price is valid for the entire window between prev_publish_time and publish_time.\nLet me know if you need anything else!\n\n post by whsia on Apr 1\n\n whsia\n\n @KemarTiti thanks for the reply. I have two more questions:\n\nI’m try to do some on chain calculation based on past few seconds. For example, I want some price points at past 30 seconds. I knew I could call benchmarks endpoint to easily get the prices at certain times in 1 request (/v1/updates/price/{timestamp}/{interval) and multiple calls by using hermes endpoint (/v2/updates/price/{publish_time}).\nDo you know if there’s any delay between benchmarks endpoint and hermes endpoint? like which is reliable for quickly retrieving some prices from past few seconds? or both are solid endpoints to achieve my goal.\n\nIs it true that the response data array length will always be 1 if i only give one priceId to hermes endpoint (/v2/updates/price/{publish_time})\n\n post by KemarTiti on Apr 1\n\n KemarTiti\n\nBenchmarks vs Hermes for recent prices\n\nFor your use case (past 30 seconds), Hermes (/v2/updates/price/{publish_time}) is ideal:\n• Hermes = real-time source of truth, optimized for recent data — but only caches ~10 minutes of history\n• Benchmarks = historical archive, covers older data but may have a small indexing delay (seconds to a minute) for very recent updates\nSo for “past 30 seconds” → Hermes is your best bet. For anything older than ~10 min → Benchmarks is required.\nIf you need multiple timestamps in quick succession, you could also stream via /v2/updates/price/stream with parsed=true and cache the last N seconds locally — avoids multiple round-trips.\nFor on-chain settlement you’ll need Hermes anyway since it returns the signed VAA.\n\nResponse array length\n\nYes — the parsed array will contain exactly one element per priceId you request. One priceId = one element in the response.\n\n post by whsia on Apr 1\n\n whsia\n\nhttps://hermes.pyth.network/v2/updates/price/1774301950?ids%5B%5D=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\n\nYou said the hermes endpoint only caches around 10 minutes. However, I still can get the result more than 10 minutes ago like the above url. Is it just not reliable for retrieving historical prices to feed into contract’sparsePriceFeedUpdates?\n\n post by KemarTiti on Apr 2\n\n KemarTiti\n\nIt is not a perfect number/science shared but empirically what has been seen.\nHave you tried for 20min ? 60min?\nBut overall, if you get a cached price from Hermes or benchmarks they are safe to use\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 715\n\n Dec 2025\n\n Powered by Discourse","tokens":5413,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263211484,"hash":"2a3c6e19fe9d7e6fa77dbdc4faeccffe5b94af8e"}
{"url":"https://dev-forum.pyth.network/t/error-price-feed-gaps-in-public-price-feed/203/15","domain":"dev-forum.pyth.network","title":"Error price feed: Gaps in public price feed - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n Jun 2025\n\n 15 / 15\n\n Apr 2\n\n Apr 2\n\n post by chrisbuildthis on Jun 9, 2025\n\n chrisbuildthis\n\n ‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’\n• Chain (e.g. Ethereum mainnet, Solana devnet, etc.)\nSolana Mainnet\n• Timestamp of the issue (block time or UTC)\nGaps in data so we log and track all data. this is how much gaps we get and it gets worse with time.\n2025-06-04T10:07:42Z\n1749031662\n2025-06-04T10:07:43Z\n1749031663\n2025-06-04T10:12:50Z\n1749031970\n2025-06-04T10:12:51Z\n1749031971\n2025-06-04T10:21:54Z\n1749032514\n2025-06-04T10:34:01Z\n1749033241\n2025-06-04T10:34:50Z\n1749033290\n2025-06-04T10:45:22Z\n1749033922\n2025-06-04T10:47:23Z\n1749034043\n2025-06-04T10:06:06Z\n1749031566\n2025-06-04T10:09:18Z\n1749031758\n2025-06-04T10:13:18Z\n1749031998\n2025-06-04T10:17:19Z\n1749032239\n2025-06-04T10:21:51Z\n1749032511\n2025-06-04T10:34:27Z\n1749033267\n2025-06-04T10:44:18Z\n1749033858\n2025-06-04T10:47:24Z\n1749034044\n2025-06-04T10:47:49\n1749034069\n2025-06-04T10:47:50Z\n1749034070\nExample for the streaming one that kept breaking down:\ncurl -X ‘GET’ \n‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’ \n-H ‘accept: application/json’ --http1.1\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d00760e4a25bf5f623f3386cba8f6a49e3c5928a025de9546d08e3e14493a1dc4072e88b01a52e8d86b5488991ee552e14889c9e15b89b1920741dd2861ac83a27301033740fdcb27395f695a65518fa598103153fa89dc645b63eebe934230209203ed59b47edd864559ea828e74533ee89badb7fe37ad33b96f37f1b1bed627cd78f6010475036ef9b293dd9e534e2dd375cc03f2fd95dd31fbdf3d4949257d650b7020086405cee9e9c0b16cda66acc4b15fef3bb0b45f459aeb790530a39df56f0a23fd0106924db4e607d82c45a465c5f3653573ab43c5f44e9b469aa9911710988e0154183c4f6e70df5dc8d43996377a216317aef46e8cf2368178f94b7002ef595824be0008b8a528ea9f92f1dec6810333354b06f9a44fbb10eeed8dc2bc0f518429e018ed5aff41e60faca0a3df98b62439f3f56266a6c85b010d0cb8c74a9d6e452602e9010a9b2d5473df63c5eaebc8c1073002158428cee5ac9801d30b528a85e5ee379afe13ff8cbd95951b33fe03df5eba25c3a04ba620c1197a38afd897752ed1d6b78d010b74b42c350dc4c9f669b98115de621807e3996f4912cea42da49216f3ce8e2f11376ef94f74132cc28c3fd1831fac354f339c24e92c9482591731a2dc50b2477e010d197e99d27de64896d6b27ed8bd16a308a6507e0c12c97b4fa76850fdab1c1a28483d59921042b2242e92776f694f35597ce8a233f6c5e607ce2d01bc010102c6000ee6de48023ebdab7a3fec5dc7e8a9dafb4b0e416cca81708a6dad1db3679f28ab5fdd1205435439f4c00d9b35d9ca247664175d71a9049e59a77c054b976754d6010f96454eb53f4de6db8b5997c339b1090d5d7ef4b6dc0a9470d74ed1cc54412dd5144d708a8b03013225c57512abc3dd0d8ebdb7cb377a09d640282669560b86b100100c5f23cb9c8047c75ac3217e952cbc75af66650fe62c6d0f6b422160ffa5b2a2259194f3f0e1879998168cf552fd398beedba9c190f501f24f02aa8bf40970c60011ea5a3740d9b7b0bf54fd5debce6b7c4ababe40c5c6bb351de97b77fcdea297aa6705b616908074a3680206eb46272e9211dd433a42b0421a34c5dcbf9df8e2b501126121106c8aa1f6b25aba95f4dc8ed0a3964760b1d542f56e37dce1781ec425d418927c150e26a975c058b33f8c1af8fbe22b24e23c5da22655ca3ebf142a21ce016841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d902014155575600000000000d345aaa000027102cc52522bf49430ad67780c7ebeadcdb013d35f401005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bd8c2bf0000000124a62711fffffff8000000006841e742000000006841e741000009665b3f76c000000001006ef4500c944d5e62d2e0dec821cb3523b2a9e7b9492dad4d6626dc08f99788dfcea56c58d9559bd6f796e38b837231abd868a14ab9a7473b7c68cc289202057206ad4ed2a6650169b808cd0217f0b46ad7a2159d5f514a3342f8987e153265d9cda2a23897907e9813e028ebbefb49de4a04590da653a58b7c1d242a2f1da520b2c872950a8db588dfdad8a17d89e5e8dcfaa5b9b725137ffeaaecdbf7ff617560beaec6c79714ca72bc4ccb67593ad04b71a151b4da527c361cb9cca22559405595fe9b1cd147b14e1d1433648126dba1df1a062b9b29857957a12c33a51200a5806d6cee404f650789310f46d5f07ee15a3658”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316710199999”,“conf”:“4909836049”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335222200000”,“conf”:“4302238800”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534890,“proof_available_time”:1749149507,“prev_publish_time”:1749149505}}]}\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d001dc9c51d9f0317c7c74d34b74cc6eda6f4158ed719881410d8524f8c793d9dc57277efd5080764da7a558097e17015706b126514befeef544c48c29a5dce43f00002bb28b3dcada54ec8d2aaac0a7ef557c3e895143003163ec2ac935a22bacac2f65b75acdd0470e2f7cdae807cfc614ddf61e732af192725ca313d0a4b7421ef3f0003560cfc8c3583f99cee1dcfcf414d0ecd0ac863b09dd66f67a1b1ec420e2fe8936b28628837f5e8f1d845b1311a9ca70011173cdea58fc4f093f640c5437a340100041c5cc17559b6a2ab29202a6bf902ec1f731195892303a3f26b825055d682a617222e4a28a14f395ab304dc4a5b63516808b3eb060004b69f4fd8dc1af8c8c47800064f8609b4af9ecd62b90af4f7c79db18e73a20d86a38912763a0a0f693ee872655baa6017da10a2d82ca1576ccd93976f14938f74f8322745763b806ff2f4845601088877f2ebf7a92efad7f458eca8db5c3d07fc7585fe37b52d0f5243460c7058207f5a07aaaad9a84938d80c0cc5615a75b925786e3c81525ba4e5c214c056e1cc000a98e5c795727915c025c8d03f633d0684e36c231552c5b3217848f128fec91baa370900a7240fda2fd818c9eb71016e5b8349086eed7429aa333e35677fd5628c000bf094d0ae614df5e8d253cf3db41e1d2728a95e9282f8c9e61a05d0a03d899b3b1fc025cee6e04df4a1609d9bbda0da28116b73d9c6daaef9ee8d38bc252db96d010d1836c4591d42683b7bfcbeab7895d37732b5128b6f20f2bfe06db8b3fe78ad2829d3ef3d835dd3f8225d7be47144a62b38ff90e3fb78419bb914b7a38660b506010e2c6e4d868a0970a52da73e614165b321bf6f191cc4c209e9488807a00eec36dc2fefb04efda9e83216e8537b091ccaa94624009391563a023bcfb7f9640cb048000f8d72884e7cfbcf969b3739225510c3b6a925ec8ad0a3d5271fd1a3ddfb4ce69c5f2f6828e3669a0daf4781600409085acba17ece75c40ca302eb995dddce071101104297798fd9e64d26da2cb904b74df77aea8464ac3b9847f3d59a97ad34a43546456849cd6e2e9f392251c37fab73c6913e90060490b9590011861e1029963d190111b0523875a4f516380d6ec7dbb37462c286354f7f53a560c06ff421db26ceb28e6da8cb8b2187d55ce24ab7e0638cc95f26fde3bf9068dadfc8cc9531eb6942c5006841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d903014155575600000000000d345aab000027109a8197e552dd636a3002f9cfdc902cb8789c95ef01005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bc130ce000000013c327290fffffff8000000006841e742000000006841e742000009665b25862000000001007067cc0c1e0308ac3b12f3b2a8e27c41885d3cf84ef19e4003ade8d6f3d5913c7cbdb080480a26757e59849cb5894c136572792202abc5cfd38eb8d6f1d95151e813597c9e22b12ec34176c3d45dafa7830b5a8ef10840a48fbc45a7a105f693b81e568eab892a5e3f4bd79e4f0a5bfb500046235034ddecde050a3e13de3e484f408a17999c04c5a823f2835ae56beab10f120fa70fcf1cf68735d1e3d4d32456081f631251558317376a29105b4729b0bc6b300ac7c73b4181efea4969228cdb7992825a1c90f1d096a566fba497abdd890307b7edfa8b1a14164e47999fde88fac5a0aa536f41b98f0a31bd3a9bbdc9eab48d”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316708655310”,“conf”:“5304906384”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335220500000”,“conf”:“4302333900”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534891,“proof_available_time”:1749149507,“prev_publish_time”:1749149506}}]}\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d007afc5e654db32909e1a9ab09e64c9927f4985b86a8de9ef4dc6cc22e38d48bcc70ab92cd1aac2f1afd4d335b25cb9bb28a9e1f573bfa667b0bba7885b16f25c60102e0aebbb6d3b06ed493c5b57d95e3437d4446053775e2e2c6918d3a9b521c0e9332989327ab83c1f462bcdee8bdf69620c6270bcbc6523cf167943e217198064101030929d1cf757e64ffa2bb13a12cc648c1d035f36bdb2af3143f1fc55b65b4cd392655cacf65a8c7255e56dee6970b76aacf857d84dd8c6872695959f5b625681e0004a11cb3ac16db430eb50c8af8d177a9208c4d113a5090a800ad6b3ce6f984c03241bb940d97c9dfb7ea76e5fd337628f0c6db1cb005f5641ab977d7e314df6933010647f567cc030b0ec7bac854c73d3f039bd35849ff07ec2ee3b2641f2d605317110f51d27e5317df09b4589c1dcbe203cdbddc2a0c24b20e4b3b39494fc815b4640008373c65d2d4c72b47f908e4a457dd2d8e4fd33f4cd59c304f33ae806736acceb251e63a7622ce73282da15840bad610f378d4aec5baa000fb75aaa8e2fd122770000af8d99184394912fdd6aad7513137fb4dabeb84fd214ea83d3300347feabe998b6380f8250d6805c6fb0408c400d6ed595e40df112bc6fe898c64273a391612ac010b2db12a76c0caf5865989a70af60028184283789b024c263fa6dd3810325eae973db5094c621f985b8ad2c3b108c7b69d195fab8584bb875f4007e776c7354bb0000dd7d0e045584f0017de2fa4426f030c285ba7782cdffe570f31b2fd3ad6e7bbb01b0cf41c8e270b55253693d12c648ac3780d6d1004e08fce7d17ee349947a1b3000ec2502b45ee72c0dcb122150b222bf145d0e0d36a7fe4e7668bc90a2a391836d040d5e5563d73751bcb258845e3114384bd44c1fc965f34027551d5877b5af499000f91a92aaedbb7c0d2d41f3ef13d85792dbad06c1a15ebe4148d7d9eb7fa875ff5677139e55c8a34f72f1c1b03ecd05f9fbc783eb5bc2b1c8fee719f1dd108509d001074836c1fac49e3151e2ac5e320be7ca5985edc0a4b9f9bb191242636d1be77bb7467d0be8b1f892b91320cadcb4aa1f009ebe6163007de39749db166c566d8f60011cdd5e801ea672fe43ada7a8e8c30973c3dd1123296a84feabd85b6233e9f728f7528b11eaf045792f1730a31e3159a1c1a5c6245abd079d10f3a61310e4fc568016841e74300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d904014155575600000000000d345aac0000271063036a46ca40542b4037d842b5152c760c1c152901005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b4300000961fcc34605000000012d3487c7fffffff8000000006841e743000000006841e742000009665b0888400000000100718bfc0cb9593def04dda130fa85b133f427f158d2fcaf25018abb60aa1fee6cee8402b86e5a837695197d52b8c408832ecafcecefc20fdf86e2e9ec9a631f36d350733d2bf45792788b851a3ad7daa859e2946501ca29f4440596cc16018758c50708174faeca9db33397b4bbb88ce32af3f8e3e545c100d715baa5e4025ad060a35ec9b5d524e45dca71926f3e2dc5e682b551b81384aeb7539370fd8d6b4fbfed1a843f3b7c9cc3c13c53ded518e90f07f55f0e78ea4a4df8ba20616199cc57145f7bc29e37ab87f7fae60b19cf588c222839428ac94e732f3d8b33c525d259de84946daba31b76b43ec4714b15cf4e7d39ce”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316457133573”,“conf”:“5053384647”,“expo”:-8,“publish_time”:1749149507},“ema_price”:{“price”:“10335218600000”,“conf”:“4302408700”,“expo”:-8,“publish_time”:1749149507},“metadata”:{“slot”:221534892,“proof_available_time”:1749149508,“prev_publish_time”:1749149506}}]}\ncurl: (18) transfer closed with outstanding read data remaining\n• Name of the dApp/Project that you are building\nPrefer not say. It not a good image of having a broken app due to Data price feed.\n• Contact (Telegram/Email/Discord)\n@unicornDegen\nThe more context you provide, the faster we can help.\nSo we meet the team in Lisabon. We have an app that scalling. The gap in the price feed keeps returning 0 as price. So as a trading app if the data comes back as 0, that means is an error and incorrect.\nIn the app user places bets, betting on the price of what will be solana , app track the price and when it come time to settle we get 0 , and it comes that the user has lost. but they haven’t.\n\n 4\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by 0xcredence on Jun 9, 2025\n\n 0xcredence\n\n gm thank you for your question!\nWill try to get back to you as soon as possible\nAnd also we’ll try to backfill the data gaps if possible. Would you be okay if I provide you with a csv of the missing data?\n\n post by chrisbuildthis on Jun 10, 2025\n\n chrisbuildthis\n\n the history is not the problem. I have 200 User daily waiting to onboard and I can’t if I have don’t certainty that there wont be gaps, or gaps will be filled with 5min timeframe of appearing.\nthe list of data I gaps I gave an example from above.\n\n post by 0xcredence on Jun 10, 2025\n\n 0xcredence\n\n do you mind reaching out to @mariopyth on telegram?\nwould like to learn more about your usecase.\n\n post by ali on Jun 10, 2025\n\n ali\n\n Hi @chrisbuildthis,\nThese gaps happen when the validators don’t reach consensus on that specified time (due to one validator being down/having issues) and while they are rare they are plausible. Please note that in these cases, for instance if a price is missing at time 1749031662, you can use the first price after 1749031664 in this case as the unique price at that time on-chain using this method and fetching it via Hermes using this endpoint will give you that data.\nAs a meta comment, this happens due to the Solana consensus designs which Pythnet is based on that a validator becomes the leader for 1.6 seconds and if they are down, no block is produced. We totally understand that this not good andare working on improving the reliability of every single validator and changing this behaviour in the network.\n\n post by chrisbuildthis on Jun 10, 2025\n\n chrisbuildthis\n\nOK so that is a 2min gap.\nThe question it still not clear if the gap is always there ?\nor do i need to search for the next timestamp that return me a data ?\n\n post by chrisbuildthis on Jun 10, 2025\n\n chrisbuildthis\n\nAlready speaking to everyone in the same TG group. they suggested to post here for better awareness.\n\n post by ali on Jun 11, 2025\n\n ali\n\n @chrisbuildthis\n\nIt’s a 2 second gap.\n\nNo it is not clear or deterministic. If all validators are healthy there’d be no gap. This happens if there is an issue with a validator (like a network issue/…) which is not predictable.\n\nThe API I shared looks forwards to give you the first price update after the asked timestamp. if you subscribe to prices you can enable the verbose flag and you always get prev_publish_time and you can assume that the update is valid between the previous publish time and the current publish time.\n\n 10 months later\n\n post by whsia on Mar 26\n\n whsia\n\nHi @ali , just want to confirm about this, https://hermes.pyth.network/v2/updates/price/1749031662?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\nFor this absent timestamp (1749031662), this kind of request seems like to return the nearest price in the up coming seconds. Is it true that this behavior is always valid? Let’s say T+0 to T+9 are all absent and there’s a price at T+10, when i pass T+0 to hermes endpoint, Will it return a T+10 price and publish_time?\n\n post by whsia on Mar 26\n\n whsia\n\n In case I can not get the answer, sorry to ping moderators here @KemarTiti @Aditya520 .\n\n post by KemarTiti on Mar 29\n\n KemarTiti\n\n Hey @whsia — yes, you’ve got it right.\nThe /v2/updates/price/{timestamp} endpoint will return the first available price update with publish_time >= requested_timestamp. So in your example:\n• Request: T+0\n• If T+0 through T+9 have no data and T+10 does → you get the T+10 price\n• The response’s publish_time field will be T+10, so you always know the actual timestamp of the returned data\nThis is intentional — ensures you can always retrieve a valid, verifiable price for settlement even during gaps.\nFor streaming use cases, Ali mentioned using the verbose flag to get prev_publish_time — you can then assume the price is valid for the entire window between prev_publish_time and publish_time.\nLet me know if you need anything else!\n\n post by whsia on Apr 1\n\n whsia\n\n @KemarTiti thanks for the reply. I have two more questions:\n\nI’m try to do some on chain calculation based on past few seconds. For example, I want some price points at past 30 seconds. I knew I could call benchmarks endpoint to easily get the prices at certain times in 1 request (/v1/updates/price/{timestamp}/{interval) and multiple calls by using hermes endpoint (/v2/updates/price/{publish_time}).\nDo you know if there’s any delay between benchmarks endpoint and hermes endpoint? like which is reliable for quickly retrieving some prices from past few seconds? or both are solid endpoints to achieve my goal.\n\nIs it true that the response data array length will always be 1 if i only give one priceId to hermes endpoint (/v2/updates/price/{publish_time})\n\n post by KemarTiti on Apr 1\n\n KemarTiti\n\nBenchmarks vs Hermes for recent prices\n\nFor your use case (past 30 seconds), Hermes (/v2/updates/price/{publish_time}) is ideal:\n• Hermes = real-time source of truth, optimized for recent data — but only caches ~10 minutes of history\n• Benchmarks = historical archive, covers older data but may have a small indexing delay (seconds to a minute) for very recent updates\nSo for “past 30 seconds” → Hermes is your best bet. For anything older than ~10 min → Benchmarks is required.\nIf you need multiple timestamps in quick succession, you could also stream via /v2/updates/price/stream with parsed=true and cache the last N seconds locally — avoids multiple round-trips.\nFor on-chain settlement you’ll need Hermes anyway since it returns the signed VAA.\n\nResponse array length\n\nYes — the parsed array will contain exactly one element per priceId you request. One priceId = one element in the response.\n\n post by whsia on Apr 1\n\n whsia\n\nhttps://hermes.pyth.network/v2/updates/price/1774301950?ids%5B%5D=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\n\nYou said the hermes endpoint only caches around 10 minutes. However, I still can get the result more than 10 minutes ago like the above url. Is it just not reliable for retrieving historical prices to feed into contract’sparsePriceFeedUpdates?\n\n post by KemarTiti on Apr 2\n\n KemarTiti\n\nIt is not a perfect number/science shared but empirically what has been seen.\nHave you tried for 20min ? 60min?\nBut overall, if you get a cached price from Hermes or benchmarks they are safe to use\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 524\n\n Oct 2025\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 715\n\n Dec 2025\n\n Powered by Discourse","tokens":5401,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263225356,"hash":"abe93983411e9a95f52f24744b53b4162756e8e1"}
{"url":"https://specs.optimism.io/protocol/fjord/exec-engine.html","domain":"specs.optimism.io","title":"Execution Engine - OP Stack Specification","text":"L2 Execution Engine\n\nTable of Contents\n\nFees\n\nL1-Cost fees (L1 Fee Vault)\n\nFjord L1-Cost fee changes (FastLZ estimator)\n\nFastLZ Implementation\nL1-Cost linear regression details\n\nL1 Gas Usage Estimation\n\nFees\nL1-Cost fees (L1 Fee Vault)\nFjord L1-Cost fee changes (FastLZ estimator)\nFjord updates the L1 cost calculation function to use a FastLZ-based compression estimator.\nThe L1 cost is computed as:\nl1FeeScaled = l1BaseFeeScalar*l1BaseFee*16 + l1BlobFeeScalar*l1BlobBaseFee\nestimatedSizeScaled = max(minTransactionSize * 1e6, intercept + fastlzCoef*fastlzSize)\nl1Fee = estimatedSizeScaled * l1FeeScaled / 1e12\n\nThe final l1Fee computation is an unlimited precision unsigned integer computation, with the result in Wei and\nhaving uint256 range. The values in this computation, are as follows:\nInput argTypeDescriptionValue\nl1BaseFeeuint256L1 base fee of the latest L1 origin registered in the L2 chainvaries, L1 fee\nl1BlobBaseFeeuint256Blob gas price of the latest L1 origin registered in the L2 chainvaries, L1 fee\nfastlzSizeuint256Size of the FastLZ-compressed RLP-encoded signed txvaries, per transaction\nl1BaseFeeScalaruint32L1 base fee scalar, scaled by 1e6varies, L2 configuration\nl1BlobFeeScalaruint32L1 blob fee scalar, scaled by 1e6varies, L2 configuration\ninterceptint32Intercept constant, scaled by 1e6 (can be negative)-42_585_600\nfastlzCoefuint32FastLZ coefficient, scaled by 1e6836_500\nminTransactionSizeuint32A lower bound on transaction size, in bytes100\n\nPreviously, l1BaseFeeScalar and l1BlobFeeScalar were used to encode the compression ratio, due to the inaccuracy of\nthe L1 cost function. However, the new cost function takes into account the compression ratio, so these scalars should\nbe adjusted to account for any previous compression ratio they encoded.\nFastLZ Implementation\nAll compression algorithms must be implemented equivalently to the fastlz_compress function in fastlz.c at the\nfollowing commit.\nL1-Cost linear regression details\nThe intercept and fastlzCoef constants are calculated by linear regression using a dataset\nof previous L2 transactions. The dataset is generated by iterating over all transactions in a given time range, and\nperforming the following actions. For each transaction:\n\nCompress the payload using FastLZ. Record the size of the compressed payload as fastlzSize.\nEmulate the change in batch size adding the transaction to a batch, compressed with Brotli 10. Record the change in\nbatch size as bestEstimateSize.\n\nOnce this dataset is generated, a linear regression can be calculated using the bestEstimateSize as\nthe dependent variable and fastlzSize as the independent variable.\nWe generated a dataset from two weeks of post-Ecotone transactions on Optimism Mainnet, as we found that was\nthe most representative of performance across multiple chains and time periods. More details on the linear regression\nand datasets used can be found in this repository.\nL1 Gas Usage Estimation\nThe L1GasUsed property is deprecated due to it not capturing the L1 blob gas used by a transaction, and will be\nremoved in a future network upgrade. Users can continue to use the L1Fee field to retrieve the L1 fee for a given\ntransaction.","tokens":794,"squid":"ink-governance","role":"Council Listener","at":1791263225404,"hash":"d0ec553f8168a7de96ec62b031be353415dca8e3"}
{"url":"https://forum.openzeppelin.com/t/how-to-change-rate-price-of-a-token-in-crowdsale/4845/2","domain":"forum.openzeppelin.com","title":"How to change rate/price of a token in Crowdsale? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n 2\n\n Nov 2020\n\n 2 / 10\n\n Dec 2020\n\n Jan 2022\n\n post by PradhumnaPancholi on Nov 29, 2020\n\n PradhumnaPancholi\n\n So, I am trying to write a sale contract which increases the price or modifies the rate of a crowdsale after each purchase(when buyTokens is called). I was going to implement it with a state variable the adds (+1) each time when buyTokens is called. And writing a custom buy method. But, I just realized that there is no method to change rate. Or is it and I miissed it? Can someone help me on this?\n\n Rate for Crowdsale\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by Skyge on Nov 30, 2020\n\n Skyge\n\n Yeah, if you want to change the rate, you need to add it by yourself.\n\n post by PradhumnaPancholi on Dec 1, 2020\n\n PradhumnaPancholi\n\n Yes, but I am currently struggling to get the rate in my contract. How am I suppose to access it and modify it? It’s a private variable\n\n post by Skyge on Dec 1, 2020\n\n Skyge\n\n Maybe you can have a look at this doc: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n PradhumnaPancholi\n\n Hi @PradhumnaPancholi,\nThere is an IncreasingPriceCrowdsale in OpenZeppelin Contracts 2.x that you could use for inspiration.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\n 1 year later\n\n post by ZrowGz on Jan 16, 2022\n\n ZrowGz\n\n Hello, I was looking at setting the token price equal to, say, $1 per minted token. I know I can calculate how many wei a dollar is and set that price at deployment, but I was hoping that there is a way to check this each time the token is minted.\nOr, could I simply have the rate pegged to a different token (instead of eth), so that it would only mint when it receives USDC? Such that the rate could still be \"1\" but it only responds to USDC or FRAX or something along those lines. Or does it just utilize the chain's base token: if deployed on Polygon, a rate of 1 would be 1 TOK for 1 matic? (I would think that it would be in the chain's base coin, since that is the gwei you're paying your gas in)\nFor example, I deploy when 1 eth = $3000, I could code in that you'd get 3000TOK for 1 eth. But then the price could climb to $4000 which would still only issue 3000 TOK.\nThank you!\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nWhy is the rate() function revert?\n function rate() public view returns (uint256) {\n revert(\"IncreasingPriceCrowdsale: rate() called\");\n }\n\nWouldn't it be useful if it returned the current rate value knowing that it precisely changes over time?\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nYou will have to connect your smart contract to an oracle that returns the price of the token you need and thus update it from time to time.\nhttps://docs.chain.link/docs/get-the-latest-price/\n\n post by ZrowGz on Jan 17, 2022\n\n ZrowGz\n\n Thanks for the link to that! Is there instead a way to tell it to accept only a different token, like USDC?\nAlso, does the wei rate calculate in comparison to the chain's base token, like MATIC on Polygon?\n\n post by Cainuriel on Jan 18, 2022\n\n Cainuriel\n\n I cannot answer your questions because although I know this service I have never used it. Maybe another reader can help you.\n[image]\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Increasing Price Crowdsale\n\n Contracts\n\n erc20,crowdsale\n\n 2\n\n 1.1k\n\n Nov 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020","tokens":985,"squid":"ink-security_audits","role":"Sentinel","at":1791263235384,"hash":"2713576d317e6e7dad797618198e08d92f619c0f"}
{"url":"https://specs.optimism.io/protocol/ecotone/l1-attributes.html","domain":"specs.optimism.io","title":"L1 attributes - OP Stack Specification","text":"Ecotone L1 Attributes\n\nTable of Contents\n\nOverview\nL1 Attributes Predeployed Contract\n\nEcotone L1Block upgrade\n\nOverview\nOn the Ecotone activation block, and if Ecotone is not activated at Genesis,\nthe L1 Attributes Transaction includes a call to setL1BlockValues()\nbecause the L1 Attributes transaction precedes the Ecotone Upgrade Transactions,\nmeaning that setL1BlockValuesEcotone is not guaranteed to exist yet.\nEvery subsequent L1 Attributes transaction should include a call to the setL1BlockValuesEcotone() function.\nThe input args are no longer ABI encoded function parameters,\nbut are instead packed into 5 32-byte aligned segments (starting after the function selector).\nEach unsigned integer argument is encoded as big-endian using a number of bytes corresponding to the underlying type.\nThe overall calldata layout is as follows:\nInput argTypeCalldata bytesSegment\n{0x440a5e20}0-3n/a\nbaseFeeScalaruint324-71\nblobBaseFeeScalaruint328-11\nsequenceNumberuint6412-19\nl1BlockTimestampuint6420-27\nl1BlockNumberuint6428-35\nbasefeeuint25636-672\nblobBaseFeeuint25668-993\nl1BlockHashbytes32100-1314\nbatcherHashbytes32132-1635\n\nTotal calldata length MUST be exactly 164 bytes, implying the sixth and final segment is only\npartially filled. This helps to slow database growth as every L2 block includes a L1 Attributes\ndeposit transaction.\nIn the first L2 block after the Ecotone activation block, the Ecotone L1 attributes are first used.\nThe pre-Ecotone values are migrated over 1:1.\nBlocks after the Ecotone activation block contain all pre-Ecotone values 1:1,\nand also set the following new attributes:\n\nThe baseFeeScalar is set to the pre-Ecotone scalar value.\nThe blobBaseFeeScalar is set to 0.\nThe pre-Ecotone overhead attribute is dropped.\nThe blobBaseFee is set to the L1 blob base fee of the L1 origin block.\nOr 1 if the L1 block does not support blobs.\nThe 1 value is derived from the EIP-4844 MIN_BLOB_GASPRICE.\n\nNote that the L1 blob bas fee is not exposed as a part of the L1 origin block.\nIt must be computed using an parameterized off-chain formula which takes the\nexcess blob gas field from the header of the L1 origin block as described in\nEIP-4844.\nThe BLOB_BASE_FEE_UPDATE_FRACTION parameter in the formula varies\naccording to which L1 fork is active\nat the origin block (see e.g. EIP-7691). It is therefore\nnecessary for L2 consensus layer clients to know the blob parameters and activation\ntime for each L1 fork to compute the blobBaseFee correctly. Blob Parameter Only\n(BPO) forks, introduced in EIP-7892\ncan mean that BLOB_BASE_FEE_UPDATE_FRACTION is updated frequently:\nthat clients and fault proof programs therefore need to stay up to date with\nsuch forks.\nL1 Attributes Predeployed Contract\nThe L1 Attributes predeploy stores the following values:\n\nL1 block attributes:\n\nnumber (uint64)\ntimestamp (uint64)\nbasefee (uint256)\nhash (bytes32)\nblobBaseFee (uint256)\n\nsequenceNumber (uint64): This equals the L2 block number relative to the start of the epoch,\ni.e. the L2 block distance to the L2 block height that the L1 attributes last changed,\nand reset to 0 at the start of a new epoch.\nSystem configurables tied to the L1 block, see System configuration specification:\n\nbatcherHash (bytes32): A versioned commitment to the batch-submitter(s) currently operating.\nbaseFeeScalar (uint32): system configurable to scale the basefee in the Ecotone l1 cost computation\nblobBasefeeScalar (uint32): system configurable to scale the blobBaseFee in the Ecotone l1 cost computation\n\nThe overhead and scalar values can continue to be accessed after the Ecotone activation block,\nbut no longer have any effect on system operation. These fields were also known as the l1FeeOverhead\nand the l1FeeScalar.\nAfter running pnpm build in the packages/contracts-bedrock directory, the bytecode to add to\nthe genesis file will be located in the deployedBytecode field of the build artifacts file at\n/packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json.\nEcotone L1Block upgrade\nThe L1 Attributes Predeployed contract, L1Block.sol, is upgraded as part of the Ecotone upgrade.\nThe version is incremented to 1.2.0, one new storage slot is introduced, and one existing slot\nbegins to store additional data:\n\nblobBaseFee (uint256): The L1 blob base fee.\nblobBaseFeeScalar (uint32): The scalar value applied to the L1 blob base fee portion of the L1 cost.\nbaseFeeScalar (uint32): The scalar value applied to the L1 base fee portion of the L1 cost.\n\nThe function called by the L1 attributes transaction depends on the network upgrade:\n\nBefore the Ecotone activation:\n\nsetL1BlockValues is called, following the pre-Ecotone L1 attributes rules.\n\nAt the Ecotone activation block:\n\nsetL1BlockValues function MUST be called, except if activated at genesis.\nThe contract is upgraded later in this block, to support setL1BlockValuesEcotone.\n\nAfter the Ecotone activation:\n\nsetL1BlockValues function is deprecated and MUST never be called.\nsetL1BlockValuesEcotone MUST be called with the new Ecotone attributes.\n\nsetL1BlockValuesEcotone uses a tightly packed encoding for its parameters, which is described in\nL1 Attributes Deposited Transaction Calldata.","tokens":1290,"squid":"ink-governance","role":"Council Listener","at":1791263236255,"hash":"40a55f1ab1cb750961a821631224fa2922fa4800"}
{"url":"https://dev-forum.pyth.network/t/ethglobal-qualifying-criteria-for-historic-prices/429/1","domain":"dev-forum.pyth.network","title":"EthGlobal qualifying criteria for Historic Prices - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n EthGlobal qualifying criteria for Historic Prices \n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n Oct 2025\n\n 1 / 17\n\n Oct 2025\n\n Oct 2025\n\n post by mcmoodoo on Oct 8, 2025\n\n mcmoodoo\n\nThese are Pyth’s offered track at the upcoming EthGlobalOnline hackathon: https://ethglobal.com/events/ethonline2025/prizes/pyth so, I am just trying to make sure that if I build my DAPP with historic prices, that it will qualify for the first track (as seen in the link) or:\n\nimage762×806 90 KB\n\n 9\n\n 7\n\n post by Aditya520 on Oct 8, 2025\n\n Aditya520\n\n Hi,\nIf you will parse historic Price on chain using either parsePriceFeedUpdates or parsePriceFeedUpdatesUnique, then you will be eligible for the bounty.\n\n post by mcmoodoo on Oct 8, 2025\n\n mcmoodoo\n\n Perfect! Is this confirmed? I just want to be absolutely sure to avoid building something that won’t meet the qualification requirements.\nThanks\n\n post by nidhi on Oct 9, 2025\n\n nidhi\n\n it is confirmed Looking forward to see your project.\n\n post by mcmoodoo on Oct 12, 2025\n\n mcmoodoo\n\n Perfect! Looking at the docs now. Both of these methods will provide historical prices in an interval (e.g. 60 prices for every second from epoch stamp 1760294000 to 1760294060) but none of those will ACTUALLY update the price on chain for that price feed, right?\nWhat if I need to have last 60 historical price values up to the very latest (now)?\nDo I need two seprate calls here? First to update the price on chain with pyth.updatePriceFeeds{ value: fee }(priceUpdate) and then parsePriceFeedUpdates(…) to get the historical price values I need?\nAm I thinking right here? Or is there some other way?\nThanks.\n\n post by Aditya520 on Oct 13, 2025\n\n Aditya520\n\n You don’t need to update the prices. But if you need 60 historical prices to be verified on-chain, you need parse them.\n\n post by mcmoodoo on Oct 18, 2025\n\n mcmoodoo\n\n So, I am using benchmarks API which returns:\n```\n[\n{\n“binary”: {\n“encoding”: “hex”,\n“data”: [\n“504e41550100000003b801000000040d00ff95abc1f273ea6c1f906c14d0f078478c931655a028d719e50c62665602103c3022d41f64e5ce8036de985a8e5a697ff3ac28a2d3f5f8416b5c98bbb3ec6af20102edc8773800259b65d49aa7f79c6c3a64ed117b0334eb80713fd65c1474540b29089a4e98b683d5ae8f38c1979855719b2eb8143dd4170c8573044c1d2c3553f5010337edd9e8a0388ab73f56ecb561e2d81b1ae05ce376643657662f7536e3a285424b2dc3fe5957f83c603f340c90a8c3de027cc4913cda4f8811a28a38aa6e7aa70104567a5865bfb72b03be69ca2cdd50f040f92c896e4f4a8dad598fc19e19d2272774b9ed7c23516e4beeeb10ba18adeb841d861b4274167aeb352e2d5f66b63f450006314f528e9cf8292a5315dc1b554be7a3aaacb9ff4a3a3f3d8f542c07bdec65a8398f058bafe7d56dcd22599b353523ac950437b2b0521f47977c8f694f38027f01084aca963b71b3d8d2d1f832ba60addd6e62cf87e13033a14dd5c6f31e96b817391df2ece3a9ddc7ad9877f4ddd0e198428296941dbb3713771f7b68d995bc5091010acda47312abef5212e26a35a29d807f36cf70c2fc664970615efe551f5698d6e0254d2af5b1140dcc25dd768882639b986efb92f8bab2a3e72de6a2a424f357a0000bfe8b251ec6d5075a769df696293fc3b6fca1244322057bfd47c9daa8e748259f0c471a3e79e6d57104b7961ba30e3bcce07a692d15506743d566ccbb91643df4010c17b13a3e8f7cdf07e0ac2039bf77425e7db71daae06a765d4d70e1ea4a1ab22008b865661cae0d4434e38f5eb6950b35359a12ab180608906b5f58414ac530d2000d2ae00a7f262cb046d333307e6a0cac3ff9d40dc1e1144bceb437f93d494a9c0c1a5b5e2acde0c170d0379d00321deff42b9274c49a4343365f6f261250c36a80010e54b6d35e5ee372f4d5951cbe32ca3c2d1d90593acc0f6f0d61fcdc8017f3424f5379d708620e2e23a822a2ca4606e30e2806765b6194f06a4587814d646ea8360010ac4ec95c12e083f92c223e21f2df3a1fb31bdf35b267b9fa722bcd071cbcfa5737a3df134bb43c3388290215507520351e6cfc1df4f1945a4a1cf7fd9496b11300118033b329471128b5e2529b3ac52794de67466049a47a4afd9bb3a64ee52139da0fd458e3a5a4774fd3966573e5ae3053310de3bb4dabe8dff8a76ed42b0f9bd90168f38f8300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c3014155575600000000000edf59c000002710a490de13f4cb4f7703810aa14bf839b23780ff5d02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5d3969810000000007533d0dfffffff80000000068f38f830000000068f38f820000005a60205bb0000000000798ad940dc2ec2928270934bf076c89ed9504f548b13855252d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea54a83b64e78bc1e8c5bbca36ba667c39164334066c22d5f219a44017266f3590d3652f33d7a6ab732d12a9d6481401ed8eb4d2cfbde6791180b539b2f766753f22e31d375bfd38ff07aa28068bb925b9c5fce7916269b4abfc1ebe91e7acf3b960eee2c92885338354bfb6edb17b8666ae54bb1962d5534c3698ba66c2216b4047602295543ae837620d8ad7e70eb642640e329f2be977d555674e2b186fb995d550b85bc498b41b87aa5f34e7a5164e4e3b4062d8eb0922a3c51b64e354c300bf1af2d7089d9db5005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5d3969810000000007533d0dfffffff80000000068f38f830000000068f38f820000005a60205bb0000000000798ad940dc2ec2928270934bf076c89ed9504f548b13855252d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea54a83b64e78bc1e8c5bbca36ba667c39164334066c22d5f219a44017266f3590d3652f33d7a6ab732d12a9d6481401ed8eb4d2cfbde6791180b539b2f766753f22e31d375bfd38ff07aa28068bb925b9c5fce7916269b4abfc1ebe91e7acf3b960eee2c92885338354bfb6edb17b8666ae54bb1962d5534c3698ba66c2216b4047602295543ae837620d8ad7e70eb642640e329f2be977d555674e2b186fb995d550b85bc498b41b87aa5f34e7a5164e4e3b4062d8eb0922a3c51b64e354c300bf1af2d7089d9db5”\n]\n},\n“parsed”: [\n{\n“id”: “ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”,\n“price”: {\n“conf”: “122895629”,\n“expo”: -8,\n“price”: “388111100289”,\n“publish_time”: 1760792451\n},\n“ema_price”: {\n“conf”: “127446420”,\n“expo”: -8,\n“price”: “388159790000”,\n“publish_time”: 1760792451\n},\n“metadata”: {\n“slot”: 249518528,\n“proof_available_time”: 1760792452,\n“prev_publish_time”: 1760792450\n}\n},\n{\n“id”: “ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”,\n“price”: {\n“conf”: “122895629”,\n“expo”: -8,\n“price”: “388111100289”,\n“publish_time”: 1760792451\n},\n“ema_price”: {\n“conf”: “127446420”,\n“expo”: -8,\n“price”: “388159790000”,\n“publish_time”: 1760792451\n},\n“metadata”: {\n“slot”: 249518528,\n“proof_available_time”: 1760792452,\n“prev_publish_time”: 1760792450\n}\n}\n]\n},\n{\n“binary”: {\n“encoding”: “hex”,\n“data”: [\n“504e41550100000003b801000000040d001428991f7d43fabb288a395b5dc4c03f51b6a476206337c168e1568bdce2579771dc7193a5aa1b5baafbf82b0d5f326018785a5f4d714f1eca9077c309b816e9010211958a44ab3db9a3410c6b0eb5b3ec4200cfc5e3da3016db9af214c02922f19b593ef46aa917c59ae22b65710c622b70b6b8e821d276fd91ed4d96471271ea580003378403000f25810d13420c58577ae1467a4fa9b2da5e0c44158c3cd5ce7bed7479d6f406205116d3b52fee330e4684d96b4b77b57dab9f32dbd43bf7e114eaa5000479802c4b17808d769f65e95e233b468a12c9117a32f70b7faa7cc301a1b185c671a5ae470e376c891a767bce89a33d18415e167740dfc100820ad7096ba54a3901067f4c6a350f4450c91ac72ef3e86f228a508a8c5bfbad63868ee003ee4083fabc22e762e457e2c743306f906c8e0cb4bb1bc70ece6c583aa4f0b5ce7ed2211596000851ed2d008eb92f11478623d866ef0be321e6851a904696c9061f23da06134efd57616fc291fb577da7548e03fe0a248bd96311f62c1b76f5c23ff62c2f005ef3000a5b1bea9172c3f22b1de93881c356845edba2344217626453b57a27707d051cd7040f8e6ff3319584a6c25050447727455996635666e11a281de2500118d0dc52010bef349eb8de625e641014b79a2cb766bed88ca02b1df6ca7c73e4cf9e67f7cbe8417c764cd84c132dc1d4cf7997159a06245378e62387a80de8324f9e58faff34010cd4917b8f68f037246367fd19db214cc187656ea2f765e88dd07729ea419e55bd0d5426a40b8fe9d27d5e178707cdba10259725e3b0c677b27f9be219b6170fb0010d8259fbef03dfbc1ac9a7b4fb085db0b4343583c202b699a1acb9eb5b4772a85c602d666d7af69091304ae95a8eca681811468c63876ea014e68700b1aae20b0e010f8e5645cd99bc2ad990097554b39b12a7262cdec7be29dc149e7bd20452b9a9520cec9ea1b2cce87986450d815798ff963e348fc78249196390fd9a253d6a16ba00108cba568e308e8b5e828fd3869452a01a57d330635a9b174e56023a6e959c79af3aef3868a857d1e0a45291fbc00aaab9b944430f498338fe016daae00728596101116e7b022947c1f864022fe6b73b89fcd984482eeda9e63aa1c7d0c6e9c999088d789b905c644ed7717aea85b3d6339629b7571a3d0fe6852a83976bff6445d09f0168f38f8400000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c6014155575600000000000edf59c3000027102d33c0a3a41ee75c7147583fe1857fc6df024f5f02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12”\n]\n},\n…\n```\nand my assumption is that I need to construct a bytes[] array of binary.data fields\nand pass it to:\nfunction parsePriceFeedUpdates( bytes[] calldata updateData, bytes32[] calldata priceIds, uint64 minPublishTime, uint64 maxPublishTime ) external payable returns (PythStructs.PriceFeed[] memory priceFeeds);\nBut I am getting:\n❯ cast 4byte 0xe69ffece\nInvalidUpdateData()\nSo, seems like it doesn’t like the format.\n\n post by mcmoodoo on Oct 20, 2025\n\n mcmoodoo\n\n just following up on my last message\n\n post by mcmoodoo on Oct 20, 2025\n\n mcmoodoo\n\n @Aditya520 @nidhi Could you please take a look sooner than later, because the hackathon submission is at the end of the week…\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\nHow are you constructing the bytes[ ] array?\nPlease DO NOT construct the bytes array manually. Please parse the update that you receive from the history api.\nSince you can only pass one timestamp in /v2/updates/price/{publish_time}, you have to parse updates one at a time for every timestamp.\nOn the other hand, you can parse multiple prices of same timestamp in one call.\nedit: added DO NOT\n\n post by mcmoodoo on Oct 21, 2025\n\n mcmoodoo\n\n I am parsing it manually. The above output comes from the history API. I then parse it to construct the bytes array out of individual binary.data fields.\nassuming the output from the history API is saved in historical_price_update.json , this is how I construct the bytes array:\n`\n string memory json = vm.readFile(\"cache/historical_price_update.json\");\n\n // Decode entire array\n PriceUpdate[] memory updates = abi.decode(vm.parseJson(json, \"\"), (PriceUpdate[]));\n console2.log(\"Number of updates:\", updates.length);\n\n // Flatten all binary.data entries into a bytes[] array\n bytes[] memory allUpdates = new bytes[](updates.length);\n for (uint256 i = 0; i < updates.length; i++) {\n allUpdates[i] = updates[i].binary.data[0];\n }\n`\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n I am extremely sorry for the wrong message above.\nPlease do not construct the bytes array manually\n\n post by mcmoodoo on Oct 21, 2025\n\n mcmoodoo\n\n If I don’t construct it manually, how else would I do it?\nI query the Benchmarks API:\n`\nBASE_URL = “https://benchmarks.pyth.network/v1/updates/price”\ntimestamp = int(time.time()) - 60\ninterval = 2\nprice_feed_id = “0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”\nurl = f\"{BASE_URL}/{timestamp}/{interval}\"\nparams = {“ids”: price_feed_id}\nresponse = requests.get(url, params=params)\n`\nand get back the exact json I posted above.\n@Aditya520\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n Yes this is correct.\nthis is not.\n// Flatten all binary.data entries into a bytes[] array \nbytes[] memory allUpdates = new bytes[](updates.length); \nfor (uint256 i = 0; i < updates.length; i++) { \nallUpdates[i] = updates[i].binary.data[0]; \n}\nYou can just send the update to parsePriceFeedUpdates\n\n post by mcmoodoo on Oct 21, 2025\n\n mcmoodoo\n\n I am soooo confused right now. You just said not to construct the bytes array manually.\nHow do I construct it then?\n@Aditya520\nCould you provide CONCRETE examples PLEASE\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n I apologize for the confusion.\nYou don’t need to construct the bytes array at all.\nYou fetch the bytes array using\nBASE_URL = “https://benchmarks.pyth.network/v1/updates/price{timestamp}”\nYou will receive an update.\n504e41550100000003b801000000040d001428991f7d43fabb288a395b5dc4c03f51b6a476206337c168e1568bdce2579771dc7193a5aa1b5baafbf82b0d5f326018785a5f4d714f1eca9077c309b816e9010211958a44ab3db9a3410c6b0eb5b3ec4200cfc5e3da3016db9af214c02922f19b593ef46aa917c59ae22b65710c622b70b6b8e821d276fd91ed4d96471271ea580003378403000f25810d13420c58577ae1467a4fa9b2da5e0c44158c3cd5ce7bed7479d6f406205116d3b52fee330e4684d96b4b77b57dab9f32dbd43bf7e114eaa5000479802c4b17808d769f65e95e233b468a12c9117a32f70b7faa7cc301a1b185c671a5ae470e376c891a767bce89a33d18415e167740dfc100820ad7096ba54a3901067f4c6a350f4450c91ac72ef3e86f228a508a8c5bfbad63868ee003ee4083fabc22e762e457e2c743306f906c8e0cb4bb1bc70ece6c583aa4f0b5ce7ed2211596000851ed2d008eb92f11478623d866ef0be321e6851a904696c9061f23da06134efd57616fc291fb577da7548e03fe0a248bd96311f62c1b76f5c23ff62c2f005ef3000a5b1bea9172c3f22b1de93881c356845edba2344217626453b57a27707d051cd7040f8e6ff3319584a6c25050447727455996635666e11a281de2500118d0dc52010bef349eb8de625e641014b79a2cb766bed88ca02b1df6ca7c73e4cf9e67f7cbe8417c764cd84c132dc1d4cf7997159a06245378e62387a80de8324f9e58faff34010cd4917b8f68f037246367fd19db214cc187656ea2f765e88dd07729ea419e55bd0d5426a40b8fe9d27d5e178707cdba10259725e3b0c677b27f9be219b6170fb0010d8259fbef03dfbc1ac9a7b4fb085db0b4343583c202b699a1acb9eb5b4772a85c602d666d7af69091304ae95a8eca681811468c63876ea014e68700b1aae20b0e010f8e5645cd99bc2ad990097554b39b12a7262cdec7be29dc149e7bd20452b9a9520cec9ea1b2cce87986450d815798ff963e348fc78249196390fd9a253d6a16ba00108cba568e308e8b5e828fd3869452a01a57d330635a9b174e56023a6e959c79af3aef3868a857d1e0a45291fbc00aaab9b944430f498338fe016daae00728596101116e7b022947c1f864022fe6b73b89fcd984482eeda9e63aa1c7d0c6e9c999088d789b905c644ed7717aea85b3d6339629b7571a3d0fe6852a83976bff6445d09f0168f38f8400000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c6014155575600000000000edf59c3000027102d33c0a3a41ee75c7147583fe1857fc6df024f5f02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12\nAppend 0x to the bytes, and send it to parsePriceFeedUpdates.\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n You can message me on my tg here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n Byte by byte breakdown of Hex encoded data received in latest price update API\n\n Price Feeds\n\n evm\n\n 5\n\n 717\n\n Jun 2025\n\n Powered by Discourse","tokens":5115,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263236622,"hash":"94ac4ceb18f6a7e63b8f7fa5c69d1c027deb98b7"}
{"url":"https://forum.openzeppelin.com/t/how-to-change-rate-price-of-a-token-in-crowdsale/4845/10","domain":"forum.openzeppelin.com","title":"How to change rate/price of a token in Crowdsale? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n 2\n\n Nov 2020\n\n 10 / 10\n\n Jan 2022\n\n Jan 2022\n\n post by PradhumnaPancholi on Nov 29, 2020\n\n PradhumnaPancholi\n\n So, I am trying to write a sale contract which increases the price or modifies the rate of a crowdsale after each purchase(when buyTokens is called). I was going to implement it with a state variable the adds (+1) each time when buyTokens is called. And writing a custom buy method. But, I just realized that there is no method to change rate. Or is it and I miissed it? Can someone help me on this?\n\n Rate for Crowdsale\n\n 3\n\n 2\n\n 2\n\n 2\n\n post by Skyge on Nov 30, 2020\n\n Skyge\n\n Yeah, if you want to change the rate, you need to add it by yourself.\n\n post by PradhumnaPancholi on Dec 1, 2020\n\n PradhumnaPancholi\n\n Yes, but I am currently struggling to get the rate in my contract. How am I suppose to access it and modify it? It’s a private variable\n\n post by Skyge on Dec 1, 2020\n\n Skyge\n\n Maybe you can have a look at this doc: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n PradhumnaPancholi\n\n Hi @PradhumnaPancholi,\nThere is an IncreasingPriceCrowdsale in OpenZeppelin Contracts 2.x that you could use for inspiration.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\n 1 year later\n\n post by ZrowGz on Jan 16, 2022\n\n ZrowGz\n\n Hello, I was looking at setting the token price equal to, say, $1 per minted token. I know I can calculate how many wei a dollar is and set that price at deployment, but I was hoping that there is a way to check this each time the token is minted.\nOr, could I simply have the rate pegged to a different token (instead of eth), so that it would only mint when it receives USDC? Such that the rate could still be \"1\" but it only responds to USDC or FRAX or something along those lines. Or does it just utilize the chain's base token: if deployed on Polygon, a rate of 1 would be 1 TOK for 1 matic? (I would think that it would be in the chain's base coin, since that is the gwei you're paying your gas in)\nFor example, I deploy when 1 eth = $3000, I could code in that you'd get 3000TOK for 1 eth. But then the price could climb to $4000 which would still only issue 3000 TOK.\nThank you!\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nWhy is the rate() function revert?\n function rate() public view returns (uint256) {\n revert(\"IncreasingPriceCrowdsale: rate() called\");\n }\n\nWouldn't it be useful if it returned the current rate value knowing that it precisely changes over time?\n\n post by Cainuriel on Jan 17, 2022\n\n Cainuriel\n\nYou will have to connect your smart contract to an oracle that returns the price of the token you need and thus update it from time to time.\nhttps://docs.chain.link/docs/get-the-latest-price/\n\n post by ZrowGz on Jan 17, 2022\n\n ZrowGz\n\n Thanks for the link to that! Is there instead a way to tell it to accept only a different token, like USDC?\nAlso, does the wei rate calculate in comparison to the chain's base token, like MATIC on Polygon?\n\n post by Cainuriel on Jan 18, 2022\n\n Cainuriel\n\n I cannot answer your questions because although I know this service I have never used it. Maybe another reader can help you.\n[image]\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Setting crowdsale rate manually\n\n General\n\n erc20,crowdsale\n\n 9\n\n 4.1k\n\n Dec 2020\n\n Increasing Price Crowdsale\n\n Contracts\n\n erc20,crowdsale\n\n 2\n\n 1.1k\n\n Nov 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to update the crowdsale rate?\n\n Contracts\n\n 3\n\n 467\n\n Dec 2020","tokens":985,"squid":"ink-security_audits","role":"Sentinel","at":1791263245718,"hash":"2cd989406c32de88eefd1510ee6c35f28d3f6743"}
{"url":"https://specs.optimism.io/protocol/l2-upgrades-1-execution.html","domain":"specs.optimism.io","title":"Execution - OP Stack Specification","text":"L2 Upgrade Execution\n\nTable of Contents\n\nOverview\nUpgrade Process\n\nOverview\nDefinitions\n\nFork Activation Timestamp\n\nAssumptions\n\naUP-001: Fork Activation Time is Coordinated\n\nMitigations\n\naUP-002: Testing Environments Match Production\n\nMitigations\n\naUP-003: Net-new Configuration Values will not be Set During Upgrades\n\nMitigations\n\naUP-004: Transaction Payloads are Identical Across Chains\n\nMitigations\n\nInvariants\n\niUP-001: Atomic Upgrade Execution\n\nImpact\n\niUP-002: Deterministic Execution\n\nImpact\n\niUP-003: Network-specific configuration must be preserved\n\nImpact\n\niUP-004: Verifiable Upgrade Execution\n\nImpact\n\nUpgrade Release Process\nTransaction Execution Sequence\n\nNetwork Upgrade Transaction Bundle\n\nOverview\nDefinitions\n\nNetwork Upgrade Transaction (NUT)\nFork Activation Block\nBundle Generation Script\n\nAssumptions\n\naNUTB-001: Solidity Compiler is Deterministic\n\nMitigations\n\naNUTB-001b: Build Toolchain is Not Compromised\n\nMitigations\n\naNUTB-002: Bundle Generation Script is Pure\n\nMitigations\n\naNUTB-003: Git Repository is Authoritative Source\n\nMitigations\n\naNUTB-004: JSON Format is Correctly Parsed\n\nMitigations\n\nInvariants\n\niNUTB-001: Deterministic Bundle Generation\n\nImpact\n\niNUTB-002: Transaction Completeness\n\nImpact\n\niNUTB-003: Transaction Ordering\n\nImpact\n\niNUTB-004: Valid Transaction Format\n\nImpact\n\niNUTB-005: Upgrade transactions do not revert\n\nImpact\n\nBundle Format\nBundle Generation Process\nBundle Verification Process\n\nCustom Upgrade Block Gas Limit\n\nOverview\nDefinitions\n\nSystem Transaction Gas Limit\nUpgrade Block Gas Allocation\nDerivation Pipeline\n\nAssumptions\n\naUBGL-001: Upgrade Gas Requirements Are Bounded\n\nMitigations\n\naUBGL-003: Custom Gas Does Not Affect Consensus\n\nMitigations\n\nInvariants\n\niUBGL-001: Sufficient Gas Availability\n\nImpact\n\niUBGL-002: Deterministic Gas Allocation\n\nImpact\n\niUBGL-003: Gas Limit Independence from Block Gas Limit\n\nImpact\n\niUBGL-004: Gas Allocation Only for Upgrade Blocks\n\nImpact\n\nGas Allocation Specification\n\nOverview\nThis specification defines the execution mechanism for L2 contract upgrades, covering the bundle format, gas\nallocation, and complete upgrade lifecycle. These components work together with the\nL2 Upgrade Contracts specification to enable deterministic, verifiable upgrades of L2\npredeploy contracts across all OP Stack chains.\nThe upgrade execution system ensures that upgrade transactions are properly formatted, have sufficient gas to execute,\nand follow a well-defined process from development through verification.\nUpgrade Process\nOverview\nThe Upgrade Process defines the complete lifecycle of an L2 predeploy upgrade, from initial development through fork\nactivation and execution. The process ensures that upgrades are developed safely, tested thoroughly, and executed\ndeterministically across all OP Stack chains.\nThis end-to-end process integrates all components of the upgrade system: contract development, bundle generation,\ntesting, verification, and execution at fork activation.\nDefinitions\nFork Activation Timestamp\nThe L2 block timestamp at which a fork becomes active and upgrade transactions are executed. This timestamp is\nspecified in the protocol configuration and used by the derivation pipeline to identify when to\ninject upgrade transactions.\nAssumptions\naUP-001: Fork Activation Time is Coordinated\nAll OP Stack chains coordinate fork activation times to enable consistent upgrade rollout. The fork activation\ntimestamp is communicated well in advance of activation to allow node operators to prepare.\nMitigations\n\nFork activation timestamps are defined in the superchain-registry\nActivation times are set and communicated far enough in advance to allow preparation\n\naUP-002: Testing Environments Match Production\nFork-based testing environments accurately represent production chain state, allowing upgrade testing to catch issues\nthat would occur in production.\nMitigations\n\nFork tests should use actual mainnet chain state (e.g., OP Mainnet) as a starting point\nTesting should validate against chains with different configurations (e.g., custom gas token, alt-DA)\nCI/CD should run fork tests to catch regressions\nManual testing on testnet chains before mainnet activation\n\naUP-003: Net-new Configuration Values will not be Set During Upgrades\nIf a new configuration value is being added to a contract by the upgrade, then it should\ninitially be set to a default which applies to all chains.\nMitigations\n\nAll previous hard fork activate contract upgrades have met this assumption.\n\naUP-004: Transaction Payloads are Identical Across Chains\nThe upgrade transaction payloads are identical for all chains executing the upgrade. While there may be\nephemeral differences in execution state (such as data read from existing contracts), the transaction\ndata itself is deterministic and chain-independent.\nMitigations\n\nBundle generation uses only deterministic inputs (CREATE2 addresses, compiled bytecode)\nCI validates bundle determinism through repeated generation\nFork tests validate execution across different chain configurations\n\nInvariants\niUP-001: Atomic Upgrade Execution\nAll transactions in the upgrade bundle MUST execute atomically within the\nfork activation block, and the entire upgrade must execute successfully.\nImpact\nSeverity: Critical\nA failed upgrade can lead to a chain halt, for example if a new function is not added to the L1Block\ncontract, causing the L1 Attributes deposit transactions to fail.\niUP-002: Deterministic Execution\nThe upgrade transactions must be deterministically generated across all chains, regardless of chain-specific\nconfiguration or chain state at the time of execution. The transaction payloads (calldata) must be identical\nacross all chains. While execution may result in different storage or memory state (e.g., contracts storing\nblock.number or reading existing chain-specific configuration), the transaction calldata itself must be identical.\nImpact\nSeverity: Critical\nNon-determinism in transaction payloads could result in a chain split.\niUP-003: Network-specific configuration must be preserved\nAll pre-existing storage values corresponding to chain-specific configuration (ie. the L1StandardBridge address),\nmust be preserved after the upgrade.\nImpact\nSeverity: Critical\nUnexpected changes to configuration could result in loss of funds or chain halts. In general the only\nstorage modifications should be pointers to implementation addresses.\niUP-004: Verifiable Upgrade Execution\nAfter fork activation, it MUST be possible to verify that the executed upgrade transactions match the committed bundle\nand that the resulting contract state matches expectations.\nImpact\nSeverity: High\nIf upgrades cannot be verified post-execution, there is no way to audit whether the correct upgrade was performed,\nbreaking transparency and making troubleshooting difficult. If post-execution verification reveals that contracts do not\nmatch expectations, this would violate other invariants and likely require another upgrade to address the issues.\nUpgrade Release Process\nThe upgrade process follows this flow:\n\nImplementation & Bundle Generation: Contract changes are implemented and the\nbundle generation script produces a deterministic JSON bundle containing all upgrade\ntransactions. This bundle will be checked into the monorepo at\npackages/contracts-bedrock/snapshots/current-l2-upgrade-bundle.json (or similar). CI will enforce that this\nbundle always corresponds with bundle generated from the source code in the current commit.\n\nContinuous Release Readiness: Contracts should always be release-ready. New functionality should be behind\nfeature flags that are only activated after a fork. This approach means there is no need to copy the bundle to a\nseparate fork-named file during development iteration. The current-l2-upgrade-bundle.json is always the\nauthoritative source that gets released with each contracts version.\n\nClient Integration: The canonical bundle JSON is embedded into L2 client binaries at build time.\n\nFork Activation: At the fork activation timestamp, nodes execute the bundle transactions.\n\nTransaction Execution Sequence\nWithin the fork activation block, transactions will execute in this order:\n\nL1 Info Deposit transaction: This is the transaction which occurs at the start of each block, it is unchanged by\nthis work.\nConditionalDeployer Deployment (one-time only): Deploy the ConditionalDeployer contract\nConditionalDeployer Upgrade (one-time only): Upgrade the ConditionalDeployer implementation\nImplementation Deployments: For each predeploy being upgraded, deploy new implementation via\nConditionalDeployer\nProxyAdmin Upgrade (one-time only): Upgrade the L2ProxyAdmin implementation\nL2ContractsManager Deployment: Deploy the L2ContractsManager for this upgrade\nUpgrade Execution: Call L2ProxyAdmin.upgradePredeploys(l2ContractsManagerAddress) which will atomically:\n\nExecutes DELEGATECALL to L2ContractsManager.upgrade()\nL2ContractsManager gathers configuration from existing predeploys\nFor each predeploy, calls proxy.upgradeTo() or proxy.upgradeToAndCall()\nVerifies all upgrades completed successfully\n\nAll of these transactions execute before any user-submitted transactions in the block.\nNetwork Upgrade Transaction Bundle\nOverview\nThe Network Upgrade Transaction (NUT) Bundle is a JSON-formatted data structure containing the complete set of\ntransactions that must be executed at a specific fork activation block. The bundle is generated deterministically from\nSolidity scripts, tracked in git, and executed by all L2 client implementations to upgrade predeploy contracts.\nThe bundle format enables verification that upgrade transactions correspond to specific source code commits, ensuring\ntransparency and auditability across all OP Stack chains executing the upgrade.\nDefinitions\nNetwork Upgrade Transaction (NUT)\nA system transaction injected by the protocol at a specific fork block height, executed with the\nDepositor Account as the sender. These transactions bypass normal\ntransaction pool processing and are deterministically included in the fork activation block.\nExamples of previous NUTs can be seen in the op-node (ie.\necotone_upgrade_transactions.go).\nThis spec builds on that precedent with an improved method for generating and inserting NUTs.\nFork Activation Block\nThe L2 block at which a protocol upgrade becomes active, identified by a specific L2 block timestamp. This block\ncontains the Network Upgrade Transactions that implement the protocol changes.\nBundle Generation Script\nA Solidity script (typically using Forge scripting) that deterministically computes all transaction data for an\nupgrade. The script computes CREATE2 addresses, generates deployment initcode, and assembles transaction calldata\ninto a JSON file written to disk.\nAssumptions\naNUTB-001: Solidity Compiler is Deterministic\nThe Solidity compiler produces identical bytecode when given identical source code and compiler settings. This enables\nverification that bundle contents match the source code on a specific commit.\nMitigations\n\nUse pinned compiler versions specified in foundry.toml\nVerification process rebuilds contracts with identical settings and compares bytecode\n\naNUTB-001b: Build Toolchain is Not Compromised\nThe Solidity compiler (solc), Forge, and other build tools used to compile contracts and generate bundles are not\ncompromised and produce trustworthy output. Compromised build tools could inject malicious code or alter bytecode.\nMitigations\n\nUse pinned, verified versions of build tools from official sources\nBuild in isolated, reproducible environments\nMultiple independent parties verify bundle generation\nCompare bytecode against known-good reference builds\n\naNUTB-002: Bundle Generation Script is Pure\nThe bundle generation script does not depend on external state that could vary between\nexecutions. All addresses are computed deterministically using CREATE2, and all transaction data is derived from\ncompiled bytecode.\nMitigations\n\nBundle generation scripts are reviewed to ensure they contain no external dependencies\nScripts use only deterministic address computation (CREATE2)\nCI validates bundle regeneration produces identical output\n\naNUTB-003: Git Repository is Authoritative Source\nThe git repository containing the bundle JSON files and source code serves as the authoritative source of truth for\nupgrade transactions.\nMitigations\n\nBundles are committed to git alongside the source code that generates them\nRepository is hosted on GitHub with branch protection and audit logs\n\naNUTB-004: JSON Format is Correctly Parsed\nAll L2 client implementations (Go, Rust, etc.) correctly parse the JSON bundle format and extract transaction fields\nidentically. Parsing inconsistencies would cause consensus failures.\nMitigations\n\nJSON schema is simple and uses standard field types\nTest vectors validate parsing across client implementations\nAcceptance tests should validate bundle execution across implementations\n\nInvariants\niNUTB-001: Deterministic Bundle Generation\nRunning the bundle generation script multiple times on the same source code commit MUST\nproduce byte-for-byte identical JSON output. No aspect of bundle generation may depend on timestamps, random values, or\nexternal state.\nImpact\nSeverity: Critical\nIf bundle generation is non-deterministic, it becomes impossible to verify that a given bundle corresponds to specific\nsource code, potentially allowing unverified or malicious transactions to be included.\niNUTB-002: Transaction Completeness\nThe bundle MUST contain all transactions required to complete the upgrade. Missing transactions would cause the upgrade\nto fail partially, leaving the system in an inconsistent state.\nImpact\nSeverity: Critical\nIf the bundle is incomplete, the fork activation would fail, potentially halting the chain or leaving predeploys in\npartially upgraded states.\niNUTB-003: Transaction Ordering\nTransactions in the bundle MUST be ordered such that dependencies are satisfied. For example, contract deployments MUST\noccur before transactions that call those contracts.\nImpact\nSeverity: Critical\nIf transactions are misordered, executions will fail when attempting to call non-existent contracts, causing the entire\nupgrade to fail at fork activation potentially halting the chain.\niNUTB-004: Valid Transaction Format\nAll transactions in the bundle MUST conform to the expected transaction format for\nNetwork Upgrade Transactions, including correct sender\n(Depositor Account), appropriate gas limits, and valid calldata\nencoding.\nImpact\nSeverity: Critical\nIf transactions are malformed, they will fail to execute at fork activation, causing the upgrade to fail and\npotentially halting the chain.\niNUTB-005: Upgrade transactions do not revert\nThe upgrade transactions must successfully execute without reverting.\nImpact\nSeverity: Critical\nReverting would likely cause a chain halt.\nBundle Format\nThe bundle is a JSON file with the following structure:\n{\n \"metadata\": {\n \"version\": \"1.0.0\"\n },\n \"transactions\": [\n {\n \"data\": \"0xabcd...\",\n \"from\": \"0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001\",\n \"gasLimit\": 1000000,\n \"intent\": \"Deploy Example Implementation\",\n \"to\": \"0x1234...\"\n }\n ]\n}\n\nField Requirements:\n\nmetadata.version: Bundle format version for compatibility tracking\ntransactions: Array of transaction objects in execution order\ntransactions[].data: Transaction calldata as hex string\ntransactions[].from: Sender address. Defaults to the\nDepositor Account. Must be set to address(0) for\nL2ProxyAdmin and ConditionalDeployer upgrade transactions to utilize the zero-address upgrade path in the\nProxy.sol implementation\ntransactions[].gasLimit: Gas limit for this transaction\ntransactions[].intent: Human-readable description of the transaction's purpose, used for documentation and\ndebugging\ntransactions[].to: Target address (contract being called)\n\nA value field MUST NOT be included in transaction objects. All NUT transactions are calls with zero ETH value, which\nis enforced by the execution layer rather than specified per-transaction.\nBundle Generation Process\nBundle generation MUST follow this process:\n\nCompile Contracts: Build all contracts with deterministic compiler settings\nCompute Addresses: Calculate implementation addresses using CREATE2 with deterministic salts\nGenerate Transaction Data: Construct calldata for each transaction using computed addresses\nAssemble Bundle: Create JSON structure with transactions in dependency order\nWrite Bundle File: Output JSON to the designated path in the repository\n\nBundle Verification Process\nTo verify a bundle matches source code:\n\nCheck Out Commit: Check out the commit specified in the upgrade release documentation\nBuild Contracts: Compile contracts using the build process documented in the repository\nRegenerate Bundle: Run the bundle generation script\nCompare Output: Verify byte-for-byte match with committed bundle\n\nCustom Upgrade Block Gas Limit\nOverview\nThe Custom Upgrade Block Gas Limit mechanism provides guaranteed gas availability for executing upgrade transactions at\nfork activation, independent of the regular block gas limit and system transaction gas constraints. This ensures that\ncomplex multi-contract upgrades can execute completely within the fork activation block\nwithout running out of gas.\nStandard L2 blocks are constrained by systemTxMaxGas (typically 1,000,000 gas), which is insufficient for executing\nthe deployment and upgrade transactions in a typical predeploy upgrade. The custom gas limit bypasses this constraint\nfor upgrade blocks specifically.\nNote: In practice, past upgrades that consumed more than 1M gas were possible because remaining gas in the block\n(after the ~20M user deposit gas allocation) was also available. However, this relied on the implicit assumption\nthat chains had sufficient gas available via their block gas limit. This specification makes the gas allocation\nexplicit to avoid such implicit dependencies.\nDefinitions\nSystem Transaction Gas Limit\nThe maximum gas available for system transactions (transactions from the\nDepositor Account) in a normal L2 block, defined by\nresourceConfig.systemTxMaxGas. This limit is typically set to 1,000,000 gas.\nUpgrade Block Gas Allocation\nThe total gas available for executing upgrade transactions in a fork activation block. This\nvalue is set significantly higher than the system transaction gas limit to accommodate\ncomplex upgrade operations.\nDerivation Pipeline\nThe component of L2 client implementations responsible for constructing L2 blocks from L1 data and protocol rules. The\nderivation pipeline determines block attributes including gas limits and inserts upgrade transactions at fork\nactivations.\nAssumptions\naUBGL-001: Upgrade Gas Requirements Are Bounded\nThe gas required to execute all upgrade transactions in a bundle is finite and\ncan be estimated before deployment. Upgrades do not contain unbounded loops or operations that could consume arbitrary\namounts of gas.\nMitigations\n\nFork-based testing measures actual gas consumption of upgrade transactions\nBundle generation process includes gas estimation for all transactions\nUpgrade complexity is bounded by the number of predeploys and deployment operations\nGas profiling is performed during development to identify expensive operations\n\naUBGL-003: Custom Gas Does Not Affect Consensus\nProviding additional gas for upgrade blocks does not violate consensus rules or create divergence between clients. The\ngas allocation is deterministic and applied consistently across all implementations.\nMitigations\n\nGas allocation is part of the protocol specification\nAll client implementations follow the same derivation rules\nGas allocation logic is simple and deterministic\n\nInvariants\niUBGL-001: Sufficient Gas Availability\nThe upgrade block gas allocation MUST be sufficient to execute all transactions in the\nNetwork Upgrade Transaction Bundle without running out of gas. No upgrade\ntransaction should fail due to insufficient gas.\nImpact\nSeverity: Critical\nIf insufficient gas is allocated, upgrade transactions will fail mid-execution, leaving predeploys in partially\nupgraded states and halting the chain at fork activation.\niUBGL-002: Deterministic Gas Allocation\nThe gas allocation for upgrade blocks MUST be deterministic and identical across all L2 nodes executing the fork\nactivation. The allocation must depend only on consensus-critical inputs (fork identification) and not on\nnode-specific state or configuration.\nImpact\nSeverity: Critical\nIf gas allocation is non-deterministic, different nodes could allocate different gas amounts, causing a consensus\nfailure and chain split.\niUBGL-003: Gas Limit Independence from Block Gas Limit\nThe upgrade block gas allocation MUST be independent of the chain's configured block\ngas limit and the system transaction gas limit. Upgrade transactions must execute even\nif block gas limits are set to minimum values.\nImpact\nSeverity: High\nIf upgrade gas depends on block gas limits, chains with different configurations could have inconsistent upgrade\nexecution, breaking the goal of deterministic upgrades across the Superchain.\niUBGL-004: Gas Allocation Only for Upgrade Blocks\nThe custom gas allocation MUST only apply to fork activation blocks containing upgrade\ntransactions. Regular blocks must continue to use standard gas limits without modification.\nImpact\nSeverity: High\nIf custom gas allocation applies to non-upgrade blocks, it could enable DOS attacks by allowing transactions to consume\nexcessive gas or bypass fee markets.\nGas Allocation Specification\nThe custom upgrade block gas allocation is implemented in the derivation pipeline with the following behavior:\nGas Allocation Value:\n\nThe upgrade block gas allocation is computed by summing the gasLimit of all transactions in the bundle\nIndividual transaction gas limits should be set significantly higher than the measured gas consumption to provide\nsafety margin\nThe derivation pipeline computes the total and adds it to the block gas limit for the fork activation block\n\nAllocation Conditions:\n\nCustom gas allocation MUST only apply when processing a fork activation block\nFork activation is identified by L2 block timestamp matching or exceeding the fork activation timestamp\nAllocation applies to the entire upgrade transaction bundle, not per-transaction\nThe allocation for a given fork MUST depend only on the fork identity, and MUST NOT vary with any other chain\nconfiguration. Where a fork's bundle is wrapped by transactions that only some chains emit — as Lagoon's is, by the\ndependency set conditional transactions — the\nallocation MUST cover those transactions unconditionally. A chain that does not emit them carries the difference as\nunused headroom in its activation block. This follows from\niUBGL-002: the reversal below is computed from the rollup configuration\nand a block timestamp alone, so an allocation that varied with anything else could not be reversed correctly.\n\nReverting the Allocation:\nThe allocation raises the activation block's gas limit only. Because the gas limit is part of the system configuration\nthat each subsequent block inherits, it MUST be removed again so that\niUBGL-004 holds for the blocks that follow:\n\nWhen reconstructing the system configuration from a fork activation block, the allocation for that fork MUST be\nsubtracted from the block's gas limit, yielding the steady-state gas limit that the next block is built on\nThe block after the activation block therefore returns to the chain's configured gas limit\nThe subtraction happens before any SystemConfig update from the same block's L1 origin is applied, so a\ngasLimit change taking effect in that block takes precedence over the reverted value\nReconstruction MUST fail if the activation block's gas limit is below the fork's allocation, rather than\nwrapping around\n\nImplementation Requirements:\n\nImplemented in op-node/rollup/derive/attributes.go or equivalent derivation logic\nGas allocation is applied when constructing the payload attributes for the fork activation block\nThe reversal is applied when converting a block to a SystemConfig — op-node/rollup/derive/payload_util.go and\nkona-protocol's to_system_config or equivalent","tokens":6034,"squid":"ink-governance","role":"Council Listener","at":1791263246067,"hash":"de2ca1b8e34b315ccdb4a30fe17c0642333d0388"}
{"url":"https://api-reference.pyth.network/price-feeds/evm/parsePriceFeedUpdatesUnique","domain":"api-reference.pyth.network","title":"Price Feeds | Pyth Network API Reference","text":"parsePriceFeedUpdatesUniqueParse updateData to return the first updated prices if the prices are published within the given time range.DescriptionThis method parse updateData and return the price feeds for the given priceIds\nwithin, if they are all the first updates published between minPublishTime and\nmaxPublishTime\nThat is to say, if prevPublishTime < minPublishTime <= publishTime <= maxPublishTime where prevPublishTime is\nthe publish time of the previous update for the given price feed.\nThese updates are unique per priceId and minPublishTime. This will guarantee no\nupdates exist for the given priceIds earlier than the returned updates and\nstill in the given time range. If you do not need the uniqueness guarantee,\nconsider using parsePriceFeedUpdates instead.\nUse this function if you want to use a Pyth price for a fixed time and not the most\nrecent price; otherwise, consider using updatePriceFeeds\nfollowed by getPriceNoOlderThan or one of its variants.\nUnlike updatePriceFeeds, calling this function will not update the on-chain price.\nThis method requires the caller to pay a fee in wei; the required fee can be\ncomputed by calling getUpdateFee with updateData.\nError Response\nThe above method can return the following error response:\n\nPriceFeedNotFoundWithinRange: No price feed was found within the given time range.\nInvalidUpdateData: The provided update data is invalid or incorrectly signed.\nInsufficientFee: The fee provided is less than the required fee. Try calling getUpdateFee to get the required fee.\nArgumentsupdateData*The price update data for the contract to verify. Fetch this data from Hermes API.priceId*The price ids whose feeds will be returned.See all price feed IDs on the reference pageminPublishTime*The minimum timestamp for each returned feed.maxPublishTime*The maximum timestamp for each returned feed.fee*The update fee in wei. This fee is sent as the value of the transaction.ExamplesNetworkimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n// Ethereum\naddress contractAddress = 0x4305FB66699C3B2702D4d05CF36551390A4c69C6\nIPyth pyth = IPyth(contractAddress);\n\nbytes[] memory updateData = new bytes[](1);\nupdateData[0] = /* <updateData> */;\n\nbytes32[] memory priceIds = new bytes32[](1);\npriceIds[0] = /* <priceId> */;\n\nuint64 minPublishTime = /* <minPublishTime> */;\nuint64 maxPublishTime = /* <maxPublishTime> */;\n\nuint fee = /* <fee> */;\npyth.parsePriceFeedUpdatesUnique{value: fee}(updateData, priceIds, minPublishTime, maxPublishTime);","tokens":636,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263247454,"hash":"ffd738575f1b093c72c740b6e08c4c2649b3f5c9"}
{"url":"https://specs.optimism.io/protocol/fjord/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Fjord L2 Chain Derivation Changes\n\nTable of Contents\n\nProtocol Parameter Changes\n\nTimestamp Activation\nConstant Maximum Sequencer Drift\n\nRationale\nSecurity Considerations\n\nIncreasing MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE\n\nRationale\nSecurity Considerations\n\nBrotli Channel Compression\nNetwork upgrade automation transactions\n\nGasPriceOracle Deployment\nGasPriceOracle Proxy Update\nGasPriceOracle Enable Fjord\n\nProtocol Parameter Changes\nThe following table gives an overview of the changes in parameters.\nParameterPre-Fjord (default) valueFjord valueNotes\nmax_sequencer_drift6001800Was a protocol parameter since Bedrock. Now becomes a constant.\nMAX_RLP_BYTES_PER_CHANNEL10,000,000100,000,000Protocol Constant is increasing.\nMAX_CHANNEL_BANK_SIZE100,000,0001,000,000,000Protocol Constant is increasing.\n\nTimestamp Activation\nFjord, like other network upgrades, is activated at a timestamp.\nChanges to the L2 Block execution rules are applied when the L2 Timestamp >= activation time.\nChanges to derivation are applied when it is considering data from a L1 Block whose timestamp\nis greater than or equal to the activation timestamp.\nThe change of the max_sequencer_drift parameter activates with the L1 origin block timestamp.\nIf Fjord is not activated at genesis, it must be activated at least one block after the Ecotone\nactivation block. This ensures that the network upgrade transactions don't conflict.\nConstant Maximum Sequencer Drift\nWith Fjord, the max_sequencer_drift parameter becomes a constant of value 1800 seconds,\ntranslating to a fixed maximum sequencer drift of 30 minutes.\nBefore Fjord, this was a chain parameter that was set once at chain creation, with a default\nvalue of 600 seconds, i.e., 10 minutes. Most chains use this value currently.\nRationale\nDiscussions amongst chain operators came to the unilateral conclusion that a larger value than the\ncurrent default would be easier to work with. If a sequencer's L1 connection breaks, this drift\nvalue determines how long it can still produce blocks without violating the timestamp drift\nderivation rules.\nIt was furthermore agreed that configurability after this increase is not important. So it is being\nmade a constant. An alternative idea that is being considered for a future hardfork is to make this\nan L1-configurable protocol parameter via the SystemConfig update mechanism.\nSecurity Considerations\nThe rules around the activation time are deliberately being kept simple, so no other logic needs to\nbe applied other than to change the parameter to a constant. The first Fjord block would in theory\naccept older L1-origin timestamps than its predecessor. However, since the L1 origin timestamp must\nalso increase, the only noteworthy scenario that can happen is that the first few Fjord blocks will\nbe in the same epoch as the last pre-Fjord blocks, even if these blocks would not be allowed to\nhave these L1-origin timestamps according to pre-Fjord rules. So the same L1 timestamp would be\nshared within a pre- and post-Fjord mixed epoch. This is considered a feature and is not considered\na security issue.\nIncreasing MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE\nWith Fjord, MAX_RLP_BYTES_PER_CHANNEL will be increased from 10,000,000 bytes to 100,000,000 bytes,\nand MAX_CHANNEL_BANK_SIZE will be increased from 100,000,000 bytes to 1,000,000,000 bytes.\nThe usage of MAX_RLP_BYTES_PER_CHANNEL is defined in Channel Format.\nThe usage of MAX_CHANNEL_BANK_SIZE is defined in Channel Bank Pruning.\nSpan Batches previously had a limit MAX_SPAN_BATCH_SIZE which was equal to MAX_RLP_BYTES_PER_CHANNEL.\nFjord creates a new constant MAX_SPAN_BATCH_ELEMENT_COUNT for the element count limit & removes\nMAX_SPAN_BATCH_SIZE. The size of the channel is still checked with MAX_RLP_BYTES_PER_CHANNEL.\nThe new value will be used when the timestamp of the L1 origin of the derivation pipeline >= the Fjord activation\ntimestamp.\nRationale\nA block with a gas limit of 30 Million gas has a maximum theoretical size of 7.5 Megabytes by being filled up\nwith transactions have only zeroes. Currently, a byte with the value 0 consumes 4 gas.\nIf the block gas limit is raised above 40 Million gas, it is possible to create a block that is large than\nMAX_RLP_BYTES_PER_CHANNEL.\nL2 blocks cannot be split across channels which means that a block that is larger than MAX_RLP_BYTES_PER_CHANNEL\ncannot be batch submitted.\nBy raising this limit to 100,000,000 bytes, we can batch submit blocks with a gas limit of up to 400 Million Gas.\nIn addition, we are able to improve compression ratios by increasing the amount of data that can be inserted into a\nsingle channel.\nWith 33% compression ratio over 6 blobs, we are currently submitting 2.2 MB of compressed data & 0.77 MB of uncompressed\ndata per channel.\nThis will allow use to use up to approximately 275 blobs per channel.\nRaising MAX_CHANNEL_BANK_SIZE is helpful to ensure that we are able to process these larger channels. We retain the\nsame ratio of 10 between MAX_RLP_BYTES_PER_CHANNEL and MAX_CHANNEL_BANK_SIZE.\nSecurity Considerations\nRaising the these limits increases the amount of resources a rollup node would require.\nSpecifically nodes may have to allocate large chunks of memory for a channel and will have to potentially allocate more\nmemory to the channel bank.\nMAX_RLP_BYTES_PER_CHANNEL was originally added to avoid zip bomb attacks.\nThe system is still exposed to these attacks, but these limits are straightforward to handle in a node.\nThe Fault Proof environment is more constrained than a typical node and increasing these limits will require more\nresources than are currently required.\nThe change in MAX_CHANNEL_BANK_SIZE is not relevant to the first implementation of Fault Proofs because this limit\nonly tells the node when to start pruning & once memory is allocated in the FPVM, it is not garbage collected.\nThis means that increasing MAX_CHANNEL_BANK_SIZE does not increase the maximum resource usage of the FPP.\nIncreasing MAX_RLP_BYTES_PER_CHANNEL could cause more resource usage in FPVM; however, we consider this\nincrease reasonable because this increase is in the amount of data handled at once rather than the total\namount of data handled in the program. Instead of using a single channel, the batcher could submit 10 channels\nprior to this change which would cause the Fault Proof Program to consume a very similar amount of resources.\nBrotli Channel Compression\nFjord introduces a new versioned channel encoding format to support alternate compression\nalgorithms, with the legacy channel format remaining supported. The\nversioned format is as follows:\nchannel_encoding = channel_version_byte ++ compress(rlp_batches)\n\nThe channel_version_byte must never have its 4 lower order bits set to 0b1000 = 8 or 0b1111 = 15, which are reserved for usage by the header byte of zlib encoded data (see page 5 of\nRFC-1950). This allows a channel decoder to determine if a channel encoding is legacy or\nversioned format by testing for these bit values. If the channel encoding is determined to be\nversioned format, the only valid channel_version_byte is 1, which indicates compress() is the\nBrotli compression algorithm (as specified in RFC-7932) with no custom dictionary.\nNetwork upgrade automation transactions\nThe Fjord hardfork activation block contains the following transactions, in this order:\n\nL1 Attributes Transaction\nUser deposits from L1\nNetwork Upgrade Transactions\n\nGasPriceOracle deployment\nUpdate GasPriceOracle Proxy ERC-1967 Implementation Slot\nGasPriceOracle Enable Fjord\n\nTo not modify or interrupt the system behavior around gas computation, this block will not include any sequenced\ntransactions by setting noTxPool: true.\nGasPriceOracle Deployment\nThe GasPriceOracle contract is upgraded to support the new Fjord L1 data fee computation. Post fork this contract\nwill use FastLZ to compute the L1 data fee.\nTo perform this upgrade, a deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000002\nto: null,\nmint: 0\nvalue: 0\ngasLimit: 1,450,000\ndata: 0x60806040523... (full bytecode)\nsourceHash: 0x86122c533fdcb89b16d8713174625e44578a89751d96c098ec19ab40a51a8ea3\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Fjord: Gas Price Oracle Deployment\"\n\nThis results in the Fjord GasPriceOracle contract being deployed to 0xa919894851548179A0750865e7974DA599C0Fac7,\nto verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000002\nComputed Address: 0xa919894851548179A0750865e7974DA599C0Fac7\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Fjord: Gas Price Oracle Deployment\"))\n# 0x86122c533fdcb89b16d8713174625e44578a89751d96c098ec19ab40a51a8ea3\n\nVerify data:\ngit checkout 52abfb507342191ae1f960b443ae8aec7598755c\npnpm clean && pnpm install && pnpm build\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json\n\nThis transaction MUST deploy a contract with the following code hash\n0xa88fa50a2745b15e6794247614b5298483070661adacb8d32d716434ed24c6b2.\nGasPriceOracle Proxy Update\nThis transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle\ndeployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe6000000000000000000000000a919894851548179a0750865e7974da599c0fac7\nsourceHash: 0x1e6bb0c28bfab3dc9b36ffb0f721f00d6937f33577606325692db0965a7d58c6\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Fjord: Gas Price Oracle Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xa919894851548179A0750865e7974DA599C0Fac7)\n# 0x3659cfe6000000000000000000000000a919894851548179a0750865e7974da599c0fac7\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Fjord: Gas Price Oracle Proxy Update\"))\n# 0x1e6bb0c28bfab3dc9b36ffb0f721f00d6937f33577606325692db0965a7d58c6\n\nGasPriceOracle Enable Fjord\nThis transaction informs the GasPriceOracle to start using the Fjord gas calculation formula.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account)\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 90,000\ndata: 0x8e98b106\nsourceHash: 0xbac7bb0d5961cad209a345408b0280a0d4686b1b20665e1b0f9cdafd73b19b6b,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Fjord: Gas Price Oracle Set Fjord\"\n\nVerify data:\ncast sig \"setFjord()\"\n0x8e98b106\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Fjord: Gas Price Oracle Set Fjord\"))\n# 0xbac7bb0d5961cad209a345408b0280a0d4686b1b20665e1b0f9cdafd73b19b6b","tokens":2765,"squid":"ink-governance","role":"Council Listener","at":1791263255988,"hash":"34481face152a61319a0c57256b9faf9cbf641c0"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvWwSO3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJuPK2a3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJTL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4Mjc2NTkzMTc5LVdoeS1hcmUtdGhlcmUtMi1kaWZmZXJlbnQtVVNEQy1zLW9uLUFyYml0cnVtBjsIVDoJcmFua2kH--8fbbd32dc4e195dbfa0409df012318e4b2cad2b8","domain":"support.arbitrum.io","title":"Why are there 2 different USDC's on Arbitrum? – Arbitrum Foundation","text":"Understanding native vs. bridged\nNative USDC is officially issued by Circle and always redeemable 1:1 for US dollars.\nIn the case of Arbitrum, there also exists a “bridged” form of USDC, known as USDC.e, that’s been bridged from Ethereum. USDC.e is not issued by Circle.\n\nNative USDC on Arbitrum:\n\nToken Name: USD Coin\nToken Symbol: USDC\nToken Address: 0xaf88d065e77c8cC2239327C5EDb3A432268e5831\n\nBridged USDC on Arbitrum: (from Ethereum)\n\nToken Name: Bridged USDC\nToken Symbol: USDC.e\nToken Address: 0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8\n\n Recently viewed articlesPartnerships with ArbitrumHow can I add Arbitrum network to my wallet?Why do I need ETH to use the Arbitrum network?Bridging over a new tokenUsing Arbitrum's traditional bridge to move funds to Mainnet\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n How can I add Arbitrum network to my wallet?\n\n You need ETH to power transactions\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Please sign in to leave a comment.","tokens":273,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263280286,"hash":"b830b847623e97824aece4fd2c492b61ecce5c31"}
{"url":"https://forum.soliditylang.org/t/size-limit-of-array-mapping-on-bnb-smart-chain-scalability-question/3700/2","domain":"forum.soliditylang.org","title":"Size limit of Array/Mapping on BNB Smart Chain (Scalability Question) - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 17\n\n 2 / 2\n\n Apr 18\n\n Apr 18\n\n post by ziaahmedshaikh on Apr 17\n\n ziaahmedshaikh\n\n Hi,\nI am going to deploy my contract on BNB Smart Chain and I want to ask a scalability related question, i have a struct something similar like following code:\nstruct Purchases{ \n\n uint32 itemId; \n\n uint32 amount; \n\n uint48 time; \n\n }\n\nand trying to manage purchase history through mapping as follows\n mapping(uint256 => Purchases\\[\\]) public purchaseHistory;\n\n// each UserID is mapped to an Array of his Purchases to manage User’s Purchase History.\nI am assuming that purchaseHistory will be incremented in 1000s every day, my questions are follows:\nHow much data can be stored in mapping like purchaseHistory array for each UserID ?\nWill contract explode after some time ?\nFor retrival, we will use pagginated function that will return purchase of user 10 items per page only.\nwill it be workable in long run or can the contract stop function after the array grows to many 1000s of records ?\nRegards. & will very much appreciate the reply.\n\n post by cameel on Apr 18\n\n cameel\n\n Solidity Compiler Team\n\nHow much data can be stored in mapping like purchaseHistory array for each UserID ?\n\nStorage space is at a premium so the compiler tries to pack things for you as much a possible. There is very little overhead here. The mapping itself takes only as much space as its content. Each dynamic array takes a single slot for length and then just the items. Check Layout of State Variables in Storage and Transient Storage for details.\nOne thing to potentially change here in case you want to minimize the total use of storage could be to use a struct of arrays rather than an array of structs. A struct always takes the whole slot, while value types can be packed. This would have the extra overhead of 2 size slots for the arrays but given that you expect thousands of items in each array and items are very short, much more space is wasted on padding between items. The downside is that it would make reads more expensive - you’d need to access 3 slots instead of 1 to get a complete set of information for one purchase - but again, if you’re reading 10 subsequent items at a time you can amortize the storage access cost by reading more than one at a time.\n\nWill contract explode after some time ?\n\nThe only hard limit on how much data you can store per mapping item is the size of storage, so for all practical purposes it’s pretty much infinite. There’s a soft limit of 2^64 32-byte slots, where the compiler starts to assume that the risk of collisions between mapping items stops being negligible, but that’s still not something you’ll easily reach before running into all kinds of other scaling problems.\nWhile writing thousands of slots per day could add up to something quite expensive, as long as it’s not all in a single transaction, but rather spread over multiple users and transactions, it’s not an issue.\n\nFor retrival, we will use pagginated function that will return purchase of user 10 items per page only.\nwill it be workable in long run or can the contract stop function after the array grows to many 1000s of records ?\n\nAssuming that you want to get the data to display it for the user or for some off-chain processing it’s not an issue either. Just make sure you return it using a view function. Such functions can be executed offchain using eth_call, which means that you don’t pay anything. No transaction is published, everything happens locally on your client, not on the network. If that’s your use case, you don’t even necessarily need pagination in the contract.\nThe only exception is if you want to get and process that data in another contract. Then that contract does need to execute the function on chain and pagination matters. In fact, the language automatically does that for you - getter functions for arrays by design return them item by item. In your case getting multiple items at a time would be more efficient if you go for the multi-array solution I mentioned, but generally the number should be low since a contract is not likely to have enough gas to process the whole array anyway.\nGenerally, there are no hard limits and you can get away with storing quite a lot of data overall, as long as you ensure that it amortizes to a small amount per user and design your contracts properly so that the whole array is never processed on chain.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 109\n\n Oct 2025\n\n Isolate the Yul Compiler as a Standalone Backend\n\n Yul\n\n 5\n\n 274\n\n Oct 2025\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":2125,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263285952,"hash":"8031d934a3cf4d4f2a0c95bd00f8a51a3724326c"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCJvwMxu3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBvWwSO3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJdL2hjL2VuLWdiL2FydGljbGVzLzE5NDc4MTMzMDc2MTIzLVdoeS13YWl0LTctZGF5cy10by1jbGFpbS1mdW5kcy13aGVuLWJyaWRnZS10by1FdGhlcmV1bQY7CFQ6CXJhbmtpBg%3D%3D--274245734b799d0ade1ae4e07a1a002901a173e1","domain":"support.arbitrum.io","title":"Why wait 7 days to claim funds when bridge to Ethereum? – Arbitrum Foundation","text":"Whenever there are bridge transactions into the Ethereum mainnet using the official Arbitrum bridge, there is a mandatory 7-day waiting period for withdrawals and this is due to the bridge's security measures.The 7-day waiting period for withdrawals back to L1 (mainnet) on Arbitrum is a security measure designed to protect against fraud. This is because Arbitrum is an optimistic rollup, which means that transactions are initially processed without being verified. If someone tries to submit a fraudulent transaction, there is a 7-day window during which verifiers can submit a fraud proof. If a fraud proof is submitted, the transaction will be reversed and the fraudster will be penalized.\n\n Recently viewed articlesWhy are there 2 different USDC's on Arbitrum?Partnerships with ArbitrumHow can I add Arbitrum network to my wallet?Why do I need ETH to use the Arbitrum network?Bridging over a new token\n\n Related articles\n\n Why are there 2 different USDC's on Arbitrum?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Skipping the bridge\n\n You need ETH to power transactions\n\n Why do I need ETH to use the Arbitrum network?\n\n Please sign in to leave a comment.","tokens":296,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263293051,"hash":"752eedfa98852e1b8f96b37677db376695438508"}
{"url":"https://docs.soliditylang.org/en/develop/contracts.html","domain":"docs.soliditylang.org","title":"Contracts — Solidity 0.8.38-develop documentation","text":"Contracts\n\n Edit on GitHub\n\nContracts\nContracts in Solidity are similar to classes in object-oriented languages. They\ncontain persistent data in state variables, and functions that can modify these\nvariables. Calling a function on a different contract (instance) will perform\nan EVM function call and thus switch the context such that state variables\nin the calling contract are\ninaccessible. A contract and its functions need to be called for anything to happen.\nThere is no “cron” concept in Ethereum to call a function at a particular event automatically.\n\nCreating Contracts\nContracts can be created “from outside” via Ethereum transactions or from within Solidity contracts.\nIDEs, such as Remix, make the creation process seamless using UI elements.\nOne way to create contracts programmatically on Ethereum is via the JavaScript API web3.js.\nIt has a function called web3.eth.Contract\nto facilitate contract creation.\nWhen a contract is created, its constructor (a function declared with\nthe constructor keyword) is executed once.\nA constructor is optional. Only one constructor is allowed, which means\noverloading is not supported.\nAfter the constructor has executed, the final code of the contract is stored on the\nblockchain. This code includes all public and external functions and all functions\nthat are reachable from there through function calls. The deployed code does not\ninclude the constructor code or internal functions only called from the constructor.\nInternally, constructor arguments are passed ABI encoded after the code of\nthe contract itself, but you do not have to care about this if you use web3.js.\nIf a contract wants to create another contract, the source code\n(and the binary) of the created contract has to be known to the creator.\nThis means that cyclic creation dependencies are impossible.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.22 <0.9.0;\n\ncontract OwnedToken {\n // `TokenCreator` is a contract type that is defined below.\n // It is fine to reference it as long as it is not used\n // to create a new contract.\n TokenCreator creator;\n address owner;\n bytes32 name;\n\n // This is the constructor which registers the\n // creator and the assigned name.\n constructor(bytes32 name_) {\n // State variables are accessed via their name\n // and not via e.g. `this.owner`. Functions can\n // be accessed directly or through `this.f`,\n // but the latter provides an external view\n // to the function. Especially in the constructor,\n // you should not access functions externally,\n // because the function does not exist yet.\n // See the next section for details.\n owner = msg.sender;\n\n // We perform an explicit type conversion from `address`\n // to `TokenCreator` and assume that the type of\n // the calling contract is `TokenCreator`, there is\n // no real way to verify that.\n // This does not create a new contract.\n creator = TokenCreator(msg.sender);\n name = name_;\n }\n\n function changeName(bytes32 newName) public {\n // Only the creator can alter the name.\n // We compare the contract based on its\n // address which can be retrieved by\n // explicit conversion to address.\n if (msg.sender == address(creator))\n name = newName;\n }\n\n function transfer(address newOwner) public {\n // Only the current owner can transfer the token.\n if (msg.sender != owner) return;\n\n // We ask the creator contract if the transfer\n // should proceed by using a function of the\n // `TokenCreator` contract defined below. If\n // the call fails (e.g. due to out-of-gas),\n // the execution also fails here.\n if (creator.isTokenTransferOK(owner, newOwner))\n owner = newOwner;\n }\n}\n\ncontract TokenCreator {\n function createToken(bytes32 name)\n public\n returns (OwnedToken tokenAddress)\n {\n // Create a new `Token` contract and return its address.\n // From the JavaScript side, the return type\n // of this function is `address`, as this is\n // the closest type available in the ABI.\n return new OwnedToken(name);\n }\n\n function changeName(OwnedToken tokenAddress, bytes32 name) public {\n // Again, the external type of `tokenAddress` is\n // simply `address`.\n tokenAddress.changeName(name);\n }\n\n // Perform checks to determine if transferring a token to the\n // `OwnedToken` contract should proceed\n function isTokenTransferOK(address currentOwner, address newOwner)\n public\n pure\n returns (bool ok)\n {\n // Check an arbitrary condition to see if transfer should proceed\n return keccak256(abi.encodePacked(currentOwner, newOwner))[0] == 0x7f;\n }\n}\n\nVisibility and Getters\n\nState Variable Visibility\n\npublicPublic state variables differ from internal ones only in that the compiler automatically generates\ngetter functions for them, which allows other contracts to read their values.\nWhen used within the same contract, the external access (e.g. this.x) invokes the getter\nwhile internal access (e.g. x) gets the variable value directly from storage.\nSetter functions are not generated so other contracts cannot directly modify their values.\n\ninternalInternal state variables can only be accessed from within the contract they are defined in\nand in derived contracts.\nThey cannot be accessed externally.\nThis is the default visibility level for state variables.\n\nprivatePrivate state variables are like internal ones but they are not visible in derived contracts.\n\nWarning\nMaking something private or internal only prevents other contracts from reading or modifying the information, but it will still be visible to the whole world outside of the blockchain.\n\nFunction Visibility\nSolidity knows two kinds of function calls: external ones that do create an actual EVM message call and internal ones that do not.\nFurthermore, internal functions can be made inaccessible to derived contracts.\nThis gives rise to four types of visibility for functions.\n\nexternalExternal functions are part of the contract interface,\nwhich means they can be called from other contracts and\nvia transactions. An external function f cannot be called\ninternally (i.e. f() does not work, but this.f() works).\n\npublicPublic functions are part of the contract interface\nand can be either called internally or via message calls.\n\ninternalInternal functions can only be accessed from within the current contract\nor contracts deriving from it.\nThey cannot be accessed externally.\nSince they are not exposed to the outside through the contract’s ABI, they can take parameters of internal types like mappings or storage references.\n\nprivatePrivate functions are like internal ones but they are not visible in derived contracts.\n\nWarning\nMaking something private or internal only prevents other contracts from reading or modifying the information, but it will still be visible to the whole world outside of the blockchain.\n\nThe visibility specifier is given after the type for\nstate variables and between parameter list and\nreturn parameter list for functions.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n function f(uint a) private pure returns (uint b) { return a + 1; }\n function setData(uint a) internal { data = a; }\n uint public data;\n}\n\nIn the following example, D, can call c.getData() to retrieve the value of\ndata in state storage, but is not able to call f. Contract E is derived from\nC and, thus, can call compute.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n uint private data;\n\n function f(uint a) private pure returns(uint b) { return a + 1; }\n function setData(uint a) public { data = a; }\n function getData() public view returns(uint) { return data; }\n function compute(uint a, uint b) internal pure returns (uint) { return a + b; }\n}\n\n// This will not compile\ncontract D {\n function readData() public {\n C c = new C();\n uint local = c.f(7); // error: member `f` is not visible\n c.setData(3);\n local = c.getData();\n local = c.compute(3, 5); // error: member `compute` is not visible\n }\n}\n\ncontract E is C {\n function g() public {\n C c = new C();\n uint val = compute(3, 5); // access to internal member (from derived to parent contract)\n }\n}\n\nGetter Functions\nThe compiler automatically creates getter functions for\nall public state variables. For the contract given below, the compiler will\ngenerate a function called data that does not take any\narguments and returns a uint, the value of the state\nvariable data. State variables can be initialized\nwhen they are declared.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n uint public data = 42;\n}\n\ncontract Caller {\n C c = new C();\n function f() public view returns (uint) {\n return c.data();\n }\n}\n\nThe getter functions have external visibility. If the\nsymbol is accessed internally (i.e. without this.),\nit evaluates to a state variable. If it is accessed externally\n(i.e. with this.), it evaluates to a function.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract C {\n uint public data;\n function x() public returns (uint) {\n data = 3; // internal access\n return this.data(); // external access\n }\n}\n\nIf you have a public state variable of array type, then you can only retrieve\nsingle elements of the array via the generated getter function. This mechanism\nexists to avoid high gas costs when returning an entire array. You can use\narguments to specify which individual element to return, for example\nmyArray(0). If you want to return an entire array in one call, then you need\nto write a function, for example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract arrayExample {\n // public state variable\n uint[] public myArray;\n\n // Getter function generated by the compiler\n /*\n function myArray(uint i) public view returns (uint) {\n return myArray[i];\n }\n */\n\n // function that returns entire array\n function getArray() public view returns (uint[] memory) {\n return myArray;\n }\n}\n\nNow you can use getArray() to retrieve the entire array, instead of\nmyArray(i), which returns a single element per call.\nThe next example is more complex:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract Complex {\n struct Data {\n uint a;\n bytes3 b;\n mapping(uint => uint) map;\n uint[3] c;\n uint[] d;\n bytes e;\n }\n mapping(uint => mapping(bool => Data[])) public data;\n}\n\nIt generates a function of the following form. The mapping and arrays (with the\nexception of byte arrays) in the struct are omitted because there is no good way\nto select individual struct members or provide a key for the mapping:\nopen in Remix\nfunction data(uint arg1, bool arg2, uint arg3)\n public\n returns (uint a, bytes3 b, bytes memory e)\n{\n a = data[arg1][arg2][arg3].a;\n b = data[arg1][arg2][arg3].b;\n e = data[arg1][arg2][arg3].e;\n}\n\nFunction Modifiers\nModifiers can be used to change the behavior of functions in a declarative way.\nFor example,\nyou can use a modifier to automatically check a condition prior to executing the function.\nModifiers are\ninheritable properties of contracts and may be overridden by derived contracts, but only\nif they are marked virtual. For details, please see\nModifier Overriding.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.1 <0.9.0;\n\ncontract owned {\n constructor() { owner = payable(msg.sender); }\n address payable owner;\n\n // This contract only defines a modifier but does not use\n // it: it will be used in derived contracts.\n // The function body is inserted where the special symbol\n // `_;` in the definition of a modifier appears.\n // This means that if the owner calls this function, the\n // function is executed and otherwise, an exception is\n // thrown.\n modifier onlyOwner {\n require(\n msg.sender == owner,\n \"Only owner can call this function.\"\n );\n _;\n }\n}\n\ncontract priced {\n // Modifiers can receive arguments:\n modifier costs(uint price) {\n if (msg.value >= price) {\n _;\n }\n }\n}\n\ncontract Register is priced, owned {\n mapping(address => bool) registeredAddresses;\n uint price;\n\n constructor(uint initialPrice) { price = initialPrice; }\n\n // It is important to also provide the\n // `payable` keyword here, otherwise the function will\n // automatically reject all Ether sent to it.\n function register() public payable costs(price) {\n registeredAddresses[msg.sender] = true;\n }\n\n // This contract inherits the `onlyOwner` modifier from\n // the `owned` contract. As a result, calls to `changePrice` will\n // only take effect if they are made by the stored owner.\n function changePrice(uint price_) public onlyOwner {\n price = price_;\n }\n}\n\ncontract Mutex {\n bool locked;\n modifier noReentrancy() {\n require(\n !locked,\n \"Reentrant call.\"\n );\n locked = true;\n _;\n locked = false;\n }\n\n /// This function is protected by a mutex, which means that\n /// reentrant calls from within `msg.sender.call` cannot call `f` again.\n /// The `return 7` statement assigns 7 to the return value but still\n /// executes the statement `locked = false` in the modifier.\n function f() public noReentrancy returns (uint) {\n (bool success,) = msg.sender.call(\"\");\n require(success);\n return 7;\n }\n}\n\nIf you want to access a modifier m defined in a contract C, you can use C.m to\nreference it without virtual lookup. It is only possible to use modifiers defined in the current\ncontract or its base contracts. Modifiers can also be defined in libraries but their use is\nlimited to functions of the same library.\nMultiple modifiers are applied to a function by specifying them in a\nwhitespace-separated list and are evaluated in the order presented.\nModifiers cannot implicitly access or change the arguments and return values of functions they modify.\nTheir values can only be passed to them explicitly at the point of invocation.\nIn function modifiers, it is necessary to specify when you want the function to which the modifier is\napplied to be run. The placeholder statement (denoted by a single underscore character _) is used to\ndenote where the body of the function being modified should be inserted. Note that the\nplaceholder operator is different from using underscores as leading or trailing characters in variable\nnames, which is a stylistic choice.\nExplicit returns from a modifier or function body only leave the current\nmodifier or function body. Return variables are assigned and\ncontrol flow continues after the _ in the preceding modifier.\n\nWarning\nIn an earlier version of Solidity, return statements in functions\nhaving modifiers behaved differently.\n\nAn explicit return from a modifier with return; does not affect the values returned by the function.\nThe modifier can, however, choose not to execute the function body at all and in that case the return\nvariables are set to their default values just as if the function had an empty\nbody.\nThe _ symbol can appear in the modifier multiple times. Each occurrence is replaced with\nthe function body, and the function returns the return value of the final occurrence.\nArbitrary expressions are allowed for modifier arguments and in this context,\nall symbols visible from the function are visible in the modifier. Symbols\nintroduced in the modifier are not visible in the function (as they might\nchange by overriding).\n\nTransient Storage\nTransient storage is another data location besides memory, storage, calldata\n(and return-data and code) which was introduced alongside its respective opcodes\nTSTORE and TLOAD by EIP-1153.\nThis new data location behaves as a key-value store similar to storage with the main\ndifference being that data in transient storage is not permanent, but is scoped to\nthe current transaction only, after which it will be reset to zero.\nSince the content of transient storage has very limited lifetime and size,\nit does not need to be stored permanently as a part of state\nand the associated gas costs are much lower than in case of storage.\nEVM version cancun or newer is required for transient storage to be available.\nTransient storage variables cannot be initialized in place, i.e., they cannot be assigned\nto upon declaration, since the value would be cleared at the end of the creation transaction,\nrendering the initialization ineffective.\nTransient variables will be default value initialized depending on\ntheir underlying type.\nconstant and immutable variables conflict with transient storage, since\ntheir values are either inlined or directly stored in code.\nTransient storage variables have completely independent address space from storage,\nso that the order of transient state variables does not affect the layout of storage\nstate variables and vice-versa.\nThey do need distinct names though because all state variables share the same namespace.\nIt is also important to note that the values in transient storage are packed in the\nsame fashion as those in persistent storage.\nSee Storage Layout for more information.\nBesides that, transient variables can have visibility as well and public ones will\nhave a getter function generated automatically as usual.\nNote that, currently, such use of transient as a data location is only allowed for\nvalue type state variable declarations.\nReference types, such as arrays, mappings and structs, as well as local or parameter\nvariables are not yet supported.\nAn expected canonical use case for transient storage is cheaper reentrancy locks,\nwhich can be readily implemented with the opcodes as showcased next.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.28;\n\ncontract Generosity {\n mapping(address => bool) sentGifts;\n bool transient locked;\n\n modifier nonReentrant {\n require(!locked, \"Reentrancy attempt\");\n locked = true;\n _;\n // Unlocks the guard, making the pattern composable.\n // After the function exits, it can be called again, even in the same transaction.\n locked = false;\n }\n\n function claimGift() nonReentrant public {\n require(address(this).balance >= 1 ether);\n require(!sentGifts[msg.sender]);\n (bool success, ) = msg.sender.call{value: 1 ether}(\"\");\n require(success);\n\n // In a reentrant function, doing this last would open up the vulnerability\n sentGifts[msg.sender] = true;\n }\n}\n\nTransient storage is private to the contract that owns it, in the same way as persistent storage.\nOnly owning contract frames may access their transient storage, and when they do, all the frames access the same transient store.\nTransient storage is part of the EVM state and is subject to the same mutability enforcements\nas persistent storage. As such, any read access to it is not pure and writing access is not view.\nIf the TSTORE opcode is called within the context of a STATICCALL,\nit will result in an exception instead of performing the modification.\nTLOAD is allowed within the context of a STATICCALL.\nWhen transient storage is used in the context of DELEGATECALL or CALLCODE,\nthen the owning contract of the transient storage is the contract that issued DELEGATECALL\nor CALLCODE instruction (the caller) as with persistent storage.\nWhen transient storage is used in the context of CALL or STATICCALL,\nthen the owning contract of the transient storage is the contract that is the target\nof the CALL or STATICCALL instruction (the callee).\n\nNote\nIn the case of DELEGATECALL, since references to transient storage variables\nare currently not supported, it is not possible to pass those into library calls.\nIn libraries, access to transient storage is only possible using inline assembly.\n\nIf a frame reverts, all writes to transient storage that took place between entry\nto the frame and the return are reverted, including those that took place in inner calls.\nThe caller of an external call may employ a try ... catch block to prevent reverts\nbubbling up from the inner calls.\n\nComposability of Smart Contracts and the Caveats of Transient Storage\nGiven the caveats mentioned in the specification of EIP-1153,\nin order to preserve the composability of your smart contract,\nutmost care is recommended for more advanced use cases of transient storage.\nFor smart contracts, composability is a very important design principle to achieve self-contained behaviour,\nsuch that multiple calls into individual smart contracts can be composed to more complex applications.\nSo far the EVM largely guaranteed composable behaviour, since multiple calls into a smart contract\nwithin a complex transaction are virtually indistinguishable from multiple calls to the contract\nstretched over several transactions. However, transient storage allows a violation of this principle,\nand incorrect use may lead to complex bugs that only surface when used across several calls.\nLet’s illustrate the problem with a simple example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.28;\n\ncontract MulService {\n uint transient multiplier;\n function setMultiplier(uint mul) external {\n multiplier = mul;\n }\n\n function multiply(uint value) external view returns (uint) {\n return value * multiplier;\n }\n}\n\nand a sequence of external calls:\nopen in Remix\nsetMultiplier(42);\nmultiply(1);\nmultiply(2);\n\nIf the example used memory or storage to store the multiplier, it would be fully composable.\nIt would not matter whether you split the sequence into separate transactions or grouped them in some way.\nYou would always get the same result: after multiplier is set to 42, the subsequent calls\nwould return 42 and 84 respectively.\nThis enables use cases such as batching calls from multiple transactions\ntogether to reduce gas costs.\nTransient storage potentially breaks such use cases since composability can no longer be taken for granted.\nIn the example, if the calls are not executed in the same transaction, then multiplier\nis reset and the next calls to function multiply would always return 0.\nAs another example, since transient storage is constructed as a relatively cheap key-value store,\na smart contract author may be tempted to use transient storage as a replacement for in-memory mappings\nwithout keeping track of the modified keys in the mapping and thereby without clearing the mapping\nat the end of the call.\nThis, however, can easily lead to unexpected behaviour in complex transactions,\nin which values set by a previous call into the contract within the same transaction remain.\nThe use of transient storage for reentrancy locks that are cleared at the end of the call frame\ninto the contract, is safe.\nHowever, be sure to resist the temptation to save the 100 gas used for resetting the\nreentrancy lock, since failing to do so, will restrict your contract to only one call\nwithin a transaction, preventing its use in complex composed transactions,\nwhich have been a cornerstone for complex applications on chain.\nIt is recommend to generally always clear transient storage completely at the end of a call\ninto your smart contract to avoid these kinds of issues and to simplify\nthe analysis of the behaviour of your contract within complex transactions.\nCheck the Security Considerations section of EIP-1153\nfor further details.\n\nConstant and Immutable State Variables\nState variables can be declared as constant or immutable.\nIn both cases, the variables cannot be modified after the contract has been constructed.\nFor constant variables, the value has to be fixed at compile-time, while\nfor immutable, it can still be assigned at construction time.\nIt is also possible to define constant variables at the file level.\nEvery occurrence of such a variable in the source is replaced by its underlying value\nand the compiler does not reserve a storage slot for it.\nIt cannot be assigned a slot in transient storage using the transient keyword either.\nCompared to regular state variables, the gas costs of constant and immutable variables\nare much lower. For a constant variable, the expression assigned to it is copied to\nall the places where it is accessed and also re-evaluated each time. This allows for local\noptimizations. Immutable variables are evaluated once at construction time and their value\nis copied to all the places in the code where they are accessed. For these values,\n32 bytes are reserved, even if they would fit in fewer bytes. Due to this, constant values\ncan sometimes be cheaper than immutable values.\nNot all types for constants and immutables are implemented at this time. The only supported types are\nstrings (only for constants) and value types.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.21;\n\nuint constant X = 32**22 + 8;\n\ncontract C {\n string constant TEXT = \"abc\";\n bytes32 constant MY_HASH = keccak256(\"abc\");\n uint immutable decimals = 18;\n uint immutable maxBalance;\n address immutable owner = msg.sender;\n\n constructor(uint decimals_, address ref) {\n if (decimals_ != 0)\n // Immutables are only immutable when deployed.\n // At construction time they can be assigned to any number of times.\n decimals = decimals_;\n\n // Assignments to immutables can even access the environment.\n maxBalance = ref.balance;\n }\n\n function isBalanceTooHigh(address other) public view returns (bool) {\n return other.balance > maxBalance;\n }\n}\n\nConstant\nFor constant variables, the value has to be a constant at compile time and it has to be\nassigned where the variable is declared. Any expression\nthat accesses storage, blockchain data (e.g. block.timestamp, address(this).balance or\nblock.number) or\nexecution data (msg.value or gasleft()) or makes calls to external contracts is disallowed. Expressions\nthat might have a side-effect on memory allocation are allowed, but those that\nmight have a side-effect on other memory objects are not. The built-in functions\nkeccak256, sha256, ripemd160, ecrecover, addmod and mulmod\nare allowed (even though, with the exception of keccak256, they do call external contracts).\nThe reason behind allowing side-effects on the memory allocator is that it\nshould be possible to construct complex objects like e.g. lookup-tables.\nThis feature is not yet fully usable.\n\nImmutable\nVariables declared as immutable are a bit less restricted than those\ndeclared as constant: Immutable variables can be assigned a\nvalue at construction time.\nThe value can be changed at any time before deployment and then it becomes permanent.\nOne additional restriction is that immutables can only be assigned to inside expressions for which\nthere is no possibility of being executed after creation.\nThis excludes all modifier definitions and functions other than constructors.\nThere are no restrictions on reading immutable variables.\nThe read is even allowed to happen before the variable is written to for the first time because variables in\nSolidity always have a well-defined initial value.\nFor this reason it is also allowed to never explicitly assign a value to an immutable.\n\nWarning\nWhen accessing immutables at construction time, please keep the initialization order in mind.\nEven if you provide an explicit initializer, some expressions may end up being evaluated before\nthat initializer, especially when they are at a different level in inheritance hierarchy.\n\nNote\nBefore Solidity 0.8.21 initialization of immutable variables was more restrictive.\nSuch variables had to be initialized exactly once at construction time and could not be read\nbefore then.\n\nThe contract creation code generated by the compiler will modify the\ncontract’s runtime code before it is returned by replacing all references\nto immutables with the values assigned to them. This is important if\nyou are comparing the\nruntime code generated by the compiler with the one actually stored in the\nblockchain. The compiler outputs where these immutables are located in the deployed bytecode\nin the immutableReferences field of the compiler JSON standard output.\n\nCustom Storage Layout\nA contract can define an arbitrary location for its storage using the layout specifier.\nThe contract’s state variables, including those inherited from base contracts,\nstart from the specified base slot instead of the default slot zero.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.29;\n\ncontract C layout at 0xAAAA + 0x11 {\n uint[3] x; // Occupies slots 0xAABB..0xAABD\n}\n\nAs the above example shows, the specifier uses the layout at <base-slot-expression> syntax\nand is located in the header of a contract definition.\nThe layout specifier can be placed either before or after the inheritance specifier, and can appear at most once.\nThe base-slot-expression must be an integer literal expression\nthat can be evaluated at compilation time and yields a value in the range of uint256.\nThe use of constants initialized using such expressions and\nthe built-in function erc7201 is also allowed.\nA custom layout cannot make contract’s storage “wrap around”.\nIf the selected base slot would push the static variables past the end of storage,\nthe compiler will issue an error.\nNote that the data areas of dynamic arrays and mappings are not affected by this check because\ntheir layout is not linear.\nRegardless of the base slot used, their locations are calculated in a way that always puts them\nwithin the range of uint256 and their sizes are not known at compilation time.\nWhile there are no other limits placed on the base slot, it is recommended to avoid locations that are\ntoo close to the end of the address space.\nLeaving too little space may complicate contract upgrades or cause problems for contracts that store\nadditional values past their allocated space using inline assembly.\nThe storage layout can only be specified for the topmost contract of an inheritance tree, and\naffects locations of all the storage variables in all the contracts in that tree.\nVariables are laid out according to the order of their definitions and the\npositions of their contracts in the linearized inheritance hierarchy\nand a custom base slot preserves their relative positions, shifting them all by the same amount.\nThe storage layout cannot be specified for abstract contracts, interfaces and libraries.\nAlso, it is important to note that it does not affect transient state variables.\nFor details about storage layout and the effect of the layout specifier on it see\nlayout of storage variables.\n\nWarning\nThe identifiers layout and at are not yet reserved as keywords in the language.\nIt is strongly recommended to avoid using them since they will become reserved in a future\nbreaking release.\n\nFunctions\nFunctions can be defined inside and outside of contracts.\nFunctions outside of a contract, also called “free functions”, always have implicit internal\nvisibility. Their code is included in all contracts\nthat call them, similar to internal library functions.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.1 <0.9.0;\n\nfunction sum(uint[] memory arr) pure returns (uint s) {\n for (uint i = 0; i < arr.length; i++)\n s += arr[i];\n}\n\ncontract ArrayExample {\n bool found;\n function f(uint[] memory arr) public {\n // This calls the free function internally.\n // The compiler will add its code to the contract.\n uint s = sum(arr);\n require(s >= 10);\n found = true;\n }\n}\n\nNote\nFunctions defined outside a contract are still always executed\nin the context of a contract.\nThey still can call other contracts, send them Ether and destroy the contract that called them,\namong other things. The main difference to functions defined inside a contract\nis that free functions do not have direct access to the variable this, storage variables and functions\nnot in their scope.\n\nFunction Parameters and Return Variables\nFunctions take typed parameters as input and may, unlike in many other\nlanguages, also return an arbitrary number of values as output.\n\nFunction Parameters\nFunction parameters are declared the same way as variables, and the name of\nunused parameters can be omitted.\nFor example, if you want your contract to accept one kind of external call\nwith two integers, you would use something like the following:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract Simple {\n uint sum;\n function taker(uint a, uint b) public {\n sum = a + b;\n }\n}\n\nFunction parameters can be used as any other local variable and they can also be assigned to.\n\nReturn Variables\nFunction return variables are declared with the same syntax after the\nreturns keyword.\nFor example, suppose you want to return two results: the sum and the product of\ntwo integers passed as function parameters, then you use something like:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract Simple {\n function arithmetic(uint a, uint b)\n public\n pure\n returns (uint sum, uint product)\n {\n sum = a + b;\n product = a * b;\n }\n}\n\nThe names of return variables can be omitted.\nReturn variables can be used as any other local variable and they\nare initialized with their default value and have that\nvalue until they are (re-)assigned.\nYou can either explicitly assign to return variables and\nthen leave the function as above,\nor you can provide return values\n(either a single or multiple ones) directly with the return\nstatement:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract Simple {\n function arithmetic(uint a, uint b)\n public\n pure\n returns (uint sum, uint product)\n {\n return (a + b, a * b);\n }\n}\n\nIf you use an early return to leave a function that has return variables,\nyou must provide return values together with the return statement.\n\nNote\nYou cannot return some types from non-internal functions.\nThis includes the types listed below and any composite types that recursively contain them:\n\nmappings,\ninternal function types,\nreference types with location set to storage,\nmulti-dimensional arrays (applies only to ABI coder v1),\nstructs (applies only to ABI coder v1).\n\nThis restriction does not apply to library functions because of their different internal ABI.\n\nReturning Multiple Values\nWhen a function has multiple return types, the statement return (v0, v1, ..., vn) can be used to return multiple values.\nThe number of components must be the same as the number of return variables\nand their types have to match, potentially after an implicit conversion.\n\nState Mutability\n\nView Functions\nFunctions can be declared view in which case they promise not to modify the state.\n\nNote\nIf the compiler’s EVM target is Byzantium or newer (default) the opcode\nSTATICCALL is used when view functions are called, which enforces the state\nto stay unmodified as part of the EVM execution. For library view functions\nDELEGATECALL is used, because there is no combined DELEGATECALL and STATICCALL.\nThis means library view functions do not have run-time checks that prevent state\nmodifications. This should not impact security negatively because library code is\nusually known at compile-time and the static checker performs compile-time checks.\n\nThe following statements are considered modifying the state:\n\nWriting to state variables (storage and transient storage).\nEmitting events.\nCreating other contracts.\nUsing selfdestruct.\nSending Ether via calls.\nCalling any function not marked view or pure.\nUsing low-level calls.\nUsing inline assembly that contains certain opcodes.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n\ncontract C {\n function f(uint a, uint b) public view returns (uint) {\n return a * (b + 42) + block.timestamp;\n }\n}\n\nNote\nconstant on functions used to be an alias to view, but this was dropped in version 0.5.0.\n\nNote\nGetter methods are automatically marked view.\n\nNote\nPrior to version 0.5.0, the compiler did not use the STATICCALL opcode\nfor view functions.\nThis enabled state modifications in view functions through the use of\ninvalid explicit type conversions.\nBy using STATICCALL for view functions, modifications to the\nstate are prevented on the level of the EVM.\n\nPure Functions\nFunctions can be declared pure in which case they promise not to read from or modify the state.\nIn particular, it should be possible to evaluate a pure function at compile-time given\nonly its inputs and msg.data, but without any knowledge of the current blockchain state.\nThis means that reading from immutable variables can be a non-pure operation.\n\nNote\nIf the compiler’s EVM target is Byzantium or newer (default) the opcode STATICCALL is used,\nwhich does not guarantee that the state is not read, but at least that it is not modified.\n\nIn addition to the list of state modifying statements explained above, the following are considered reading from the state:\n\nReading from state variables (storage and transient storage).\nAccessing address(this).balance or <address>.balance.\nAccessing any of the members of block, tx, msg (with the exception of msg.sig and msg.data).\nCalling any function not marked pure.\nUsing inline assembly that contains certain opcodes.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n\ncontract C {\n function f(uint a, uint b) public pure returns (uint) {\n return a * (b + 42);\n }\n}\n\nPure functions are able to use the revert() and require() functions to revert\npotential state changes when an error occurs.\nReverting a state change is not considered a “state modification”, as only changes to the\nstate made previously in code that did not have the view or pure restriction\nare reverted and that code has the option to catch the revert and not pass it on.\nThis behavior is also in line with the STATICCALL opcode.\n\nWarning\nIt is not possible to prevent functions from reading the state at the level\nof the EVM, it is only possible to prevent them from writing to the state\n(i.e. only view can be enforced at the EVM level, pure can not).\n\nNote\nPrior to version 0.5.0, the compiler did not use the STATICCALL opcode\nfor pure functions.\nThis enabled state modifications in pure functions through the use of\ninvalid explicit type conversions.\nBy using STATICCALL for pure functions, modifications to the\nstate are prevented on the level of the EVM.\n\nNote\nPrior to version 0.4.17 the compiler did not enforce that pure is not reading the state.\nIt is a compile-time type check, which can be circumvented by doing invalid explicit conversions\nbetween contract types, because the compiler can verify that the type of the contract does\nnot do state-changing operations, but it cannot check that the contract that will be called\nat runtime is actually of that type.\n\nSpecial Functions\n\nReceive Ether Function\nA contract can have at most one receive function, declared using\nreceive() external payable { ... }\n(without the function keyword).\nThis function cannot have arguments, cannot return anything and must have\nexternal visibility and payable state mutability.\nIt can be virtual, can override and can have modifiers.\nThe receive function is executed on a\ncall to the contract with empty calldata. This is the function that is executed\non plain Ether transfers (e.g. via .send() or .transfer()). If no such\nfunction exists, but a payable fallback function\nexists, the fallback function will be called on a plain Ether transfer. If\nneither a receive Ether nor a payable fallback function is present, the\ncontract cannot receive Ether through a transaction that does not represent a payable function call and throws an\nexception.\nIn the worst case, the receive function can only rely on 2300 gas being\navailable (for example when send or transfer is used), leaving little\nroom to perform other operations except basic logging. The following operations\nwill consume more gas than the 2300 gas stipend:\n\nWriting to storage\nCreating a contract\nCalling an external function which consumes a large amount of gas\nSending Ether\n\nWarning\nsend() and transfer() are deprecated and scheduled for removal.\nSee the section on send and transfer for more information.\n\nWarning\nWhen Ether is sent directly to a contract (without a function call, i.e. sender uses send or transfer)\nbut the receiving contract does not define a receive Ether function or a payable fallback function,\nan exception will be thrown, sending back the Ether (this was different\nbefore Solidity v0.4.0). If you want your contract to receive Ether,\nyou have to implement a receive Ether function (using payable fallback functions for receiving Ether is\nnot recommended, since the fallback is invoked and would not fail for interface confusions\non the part of the sender).\n\nWarning\nA contract without a receive Ether function can receive Ether as a\nrecipient of a coinbase transaction (aka miner block reward)\nor as a destination of a selfdestruct.\nA contract cannot react to such Ether transfers and thus also\ncannot reject them. This is a design choice of the EVM and\nSolidity cannot work around it.\nIt also means that address(this).balance can be higher\nthan the sum of some manual accounting implemented in a\ncontract (i.e. having a counter updated in the receive Ether function).\n\nBelow you can see an example of a Sink contract that uses function receive.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.0 <0.9.0;\n\n// This contract keeps all Ether sent to it with no way\n// to get it back.\ncontract Sink {\n event Received(address, uint);\n receive() external payable {\n emit Received(msg.sender, msg.value);\n }\n}\n\nFallback Function\nA contract can have at most one fallback function, declared using either fallback () external [payable]\nor fallback (bytes calldata input) external [payable] returns (bytes memory output)\n(both without the function keyword).\nThis function must have external visibility. A fallback function can be virtual, can override\nand can have modifiers.\nThe fallback function is executed on a call to the contract if none of the other\nfunctions match the given function signature, or if no data was supplied at\nall and there is no receive Ether function.\nThe fallback function always receives data, but in order to also receive Ether\nit must be marked payable.\nIf the version with parameters is used, input will contain the full data sent to the contract\n(equal to msg.data) and can return data in output. The returned data will not be\nABI-encoded. Instead it will be returned without modifications (not even padding).\nIn the worst case, if a payable fallback function is also used in\nplace of a receive function, it can only rely on 2300 gas being\navailable (see receive Ether function\nfor a brief description of the implications of this).\nLike any function, the fallback function can execute complex\noperations as long as there is enough gas passed on to it.\n\nWarning\nA payable fallback function is also executed for\nplain Ether transfers, if no receive Ether function\nis present. It is recommended to always define a receive Ether\nfunction as well, if you define a payable fallback function\nto distinguish Ether transfers from interface confusions.\n\nNote\nIf you want to decode the input data, you can check the first four bytes\nfor the function selector and then\nyou can use abi.decode together with the array slice syntax to\ndecode ABI-encoded data:\n(c, d) = abi.decode(input[4:], (uint256, uint256));\nNote that this should only be used as a last resort and\nproper functions should be used instead.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.2 <0.9.0;\n\ncontract Test {\n uint x;\n // This function is called for all messages sent to\n // this contract (there is no other function).\n // Sending Ether to this contract will cause an exception,\n // because the fallback function does not have the `payable`\n // modifier.\n fallback() external { x = 1; }\n}\n\ncontract TestPayable {\n uint x;\n uint y;\n // This function is called for all messages sent to\n // this contract, except plain Ether transfers\n // (there is no other function except the receive function).\n // Any call with non-empty calldata to this contract will execute\n // the fallback function (even if Ether is sent along with the call).\n fallback() external payable { x = 1; y = msg.value; }\n\n // This function is called for plain Ether transfers, i.e.\n // for every call with empty calldata.\n receive() external payable { x = 2; y = msg.value; }\n}\n\ncontract Caller {\n function callTest(Test test) public returns (bool) {\n (bool success,) = address(test).call(abi.encodeWithSignature(\"nonExistingFunction()\"));\n require(success);\n // results in test.x becoming == 1.\n\n // address(test) will not allow to call ``send`` directly, since ``test`` has no payable\n // fallback function.\n // It has to be converted to the ``address payable`` type to even allow calling ``send`` on it.\n address payable testPayable = payable(address(test));\n\n // If someone sends Ether to that contract,\n // the transfer will fail, i.e. this returns false here.\n // This will report a warning (deprecation)\n return testPayable.send(2 ether);\n }\n\n function callTestPayable(TestPayable test) public returns (bool) {\n (bool success,) = address(test).call(abi.encodeWithSignature(\"nonExistingFunction()\"));\n require(success);\n // results in test.x becoming == 1 and test.y becoming 0.\n (success,) = address(test).call{value: 1}(abi.encodeWithSignature(\"nonExistingFunction()\"));\n require(success);\n // results in test.x becoming == 1 and test.y becoming 1.\n\n // If someone sends Ether to that contract, the receive function in TestPayable will be called.\n // Since that function writes to storage, it takes more gas than is available with a\n // simple ``send`` or ``transfer``. Because of that, we have to use a low-level call.\n (success,) = address(test).call{value: 2 ether}(\"\");\n require(success);\n // results in test.x becoming == 2 and test.y becoming 2 ether.\n\n return true;\n }\n}\n\nFunction Overloading\nA contract can have multiple functions of the same name but with different parameter\ntypes.\nThis process is called “overloading” and also applies to inherited functions.\nThe following example shows overloading of the function\nf in the scope of contract A.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract A {\n function f(uint value) public pure returns (uint out) {\n out = value;\n }\n\n function f(uint value, bool really) public pure returns (uint out) {\n if (really)\n out = value;\n }\n}\n\nOverloaded functions are also present in the external interface. It is an error if two\nexternally visible functions differ by their Solidity types but not by their external types.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\n// This will not compile\ncontract A {\n function f(B value) public pure returns (B out) {\n out = value;\n }\n\n function f(address value) public pure returns (address out) {\n out = value;\n }\n}\n\ncontract B {\n}\n\nBoth f function overloads above end up accepting the address type for the ABI although\nthey are considered different inside Solidity.\n\nOverload resolution and Argument matching\nOverloaded functions are selected by matching the function declarations in the current scope\nto the arguments supplied in the function call. Functions are selected as overload candidates\nif all arguments can be implicitly converted to the expected types. If there is not exactly one\ncandidate, resolution fails.\n\nNote\nReturn parameters are not taken into account for overload resolution.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract A {\n function f(uint8 val) public pure returns (uint8 out) {\n out = val;\n }\n\n function f(uint256 val) public pure returns (uint256 out) {\n out = val;\n }\n}\n\nCalling f(50) would create a type error since 50 can be implicitly converted both to uint8\nand uint256 types. On another hand f(256) would resolve to f(uint256) overload as 256 cannot be implicitly\nconverted to uint8.\n\nEvents\nSolidity events give an abstraction on top of the EVM’s logging functionality.\nApplications can subscribe and listen to these events through the RPC interface of an Ethereum client.\nEvents can be defined at file level or as inheritable members of contracts (including interfaces and libraries).\nWhen you call them, they cause the\narguments to be stored in the transaction’s log - a special data structure\nin the blockchain. These logs are associated with the address of the contract that emitted them,\nare incorporated into the blockchain, and stay there as long as a block is\naccessible (forever as of now, but this might\nchange in the future). The Log and its event data are not accessible from within\ncontracts (not even from the contract that created them).\nIt is possible to request a Merkle proof for logs, so if\nan external entity supplies a contract with such a proof, it can check\nthat the log actually exists inside the blockchain. You have to supply block headers\nbecause the contract can only see the last 256 block hashes.\nYou can add the attribute indexed to up to three parameters which adds them\nto a special data structure known as “topics” instead of\nthe data part of the log.\nA topic can only hold a single word (32 bytes) so if you use a reference type for an indexed argument, the Keccak-256 hash of the value is stored\nas a topic instead.\nAll parameters without the indexed attribute are ABI-encoded\ninto the data part of the log.\nTopics allow you to search for events, for example when filtering a sequence of\nblocks for certain events. You can also filter events by the address of the\ncontract that emitted the event.\nFor example, the code below uses the web3.js subscribe(\"logs\")\nmethod to filter\nlogs that match a topic with a certain address value:\nvar options = {\n fromBlock: 0,\n address: web3.eth.defaultAccount,\n topics: [\"0x0000000000000000000000000000000000000000000000000000000000000000\", null, null]\n};\nweb3.eth.subscribe('logs', options, function (error, result) {\n if (!error)\n console.log(result);\n})\n .on(\"data\", function (log) {\n console.log(log);\n })\n .on(\"changed\", function (log) {\n});\n\nThe hash of the signature of the event is one of the topics, except if you\ndeclared the event with the anonymous specifier. This means that it is\nnot possible to filter for specific anonymous events by name, you can\nonly filter by the contract address. The advantage of anonymous events\nis that they are cheaper to deploy and call. It also allows you to declare\nfour indexed arguments rather than three.\n\nNote\nSince the transaction log only stores the event data and not the type,\nyou have to know the type of the event, including which parameter is\nindexed and if the event is anonymous in order to correctly interpret\nthe data.\nIn particular, it is possible to “fake” the signature of another event\nusing an anonymous event.\n\nMembers of Events\n\nevent.selector: For non-anonymous events, this is a bytes32 value\ncontaining the keccak256 hash of the event signature, as used in the default topic.\n\nExample\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.21 <0.9.0;\n\ncontract ClientReceipt {\n event Deposit(\n address indexed from,\n bytes32 indexed id,\n uint value\n );\n\n function deposit(bytes32 id) public payable {\n // Events are emitted using `emit`, followed by\n // the name of the event and the arguments\n // (if any) in parentheses. Any such invocation\n // (even deeply nested) can be detected from\n // the JavaScript API by filtering for `Deposit`.\n emit Deposit(msg.sender, id, msg.value);\n }\n}\n\nThe use in the JavaScript API is as follows:\nvar abi = /* abi as generated by the compiler */;\nvar ClientReceipt = web3.eth.contract(abi);\nvar clientReceipt = ClientReceipt.at(\"0x1234...ab67\" /* address */);\n\nvar depositEvent = clientReceipt.Deposit();\n\n// watch for changes\ndepositEvent.watch(function(error, result){\n // result contains non-indexed arguments and topics\n // given to the `Deposit` call.\n if (!error)\n console.log(result);\n});\n\n// Or pass a callback to start watching immediately\nvar depositEvent = clientReceipt.Deposit(function(error, result) {\n if (!error)\n console.log(result);\n});\n\nThe output of the above looks like the following (trimmed):\n{\n \"returnValues\": {\n \"from\": \"0x1111…FFFFCCCC\",\n \"id\": \"0x50…sd5adb20\",\n \"value\": \"0x420042\"\n },\n \"raw\": {\n \"data\": \"0x7f…91385\",\n \"topics\": [\"0xfd4…b4ead7\", \"0x7f…1a91385\"]\n }\n}\n\nAdditional Resources for Understanding Events\n\nJavaScript documentation\nExample usage of events\nHow to access them in js\n\nCustom Errors\nErrors in Solidity provide a convenient and gas-efficient way to explain to the\nuser why an operation failed. They can be defined inside and outside of contracts (including interfaces and libraries).\nThey have to be used together with the revert statement\nor the require function.\nIn the case of revert statements, or require calls where the condition is evaluated to be false,\nall changes in the current call are reverted, and the error data passed back to the caller.\nThe example below shows custom error usage with the revert statement in function transferWithRevertError,\nas well as the newer approach with require in function transferWithRequireError.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.27;\n\n/// Insufficient balance for transfer. Needed `required` but only\n/// `available` available.\n/// @param available balance available.\n/// @param required requested amount to transfer.\nerror InsufficientBalance(uint256 available, uint256 required);\n\ncontract TestToken {\n mapping(address => uint) balance;\n function transferWithRevertError(address to, uint256 amount) public {\n if (amount > balance[msg.sender])\n revert InsufficientBalance({\n available: balance[msg.sender],\n required: amount\n });\n balance[msg.sender] -= amount;\n balance[to] += amount;\n }\n function transferWithRequireError(address to, uint256 amount) public {\n require(amount <= balance[msg.sender], InsufficientBalance(balance[msg.sender], amount));\n balance[msg.sender] -= amount;\n balance[to] += amount;\n }\n // ...\n}\n\nAnother important detail to mention when it comes to using require with custom errors, is that memory\nallocation for the error-based revert reason will only happen in the reverting case, which, along with\noptimization of constants and string literals makes this about as gas-efficient as the\nif (!condition) revert CustomError(args) pattern.\nErrors cannot be overloaded or overridden but are inherited.\nThe same error can be defined in multiple places as long as the scopes are distinct.\nInstances of errors can only be created using revert statements, or as the second argument to require functions.\nThe error creates data that is then passed to the caller with the revert operation\nto either return to the off-chain component or catch it in a try/catch statement.\nNote that an error can only be caught when coming from an external call,\nreverts happening in internal calls or inside the same function cannot be caught.\nIf you do not provide any parameters, the error only needs four bytes of\ndata and you can use NatSpec as above\nto further explain the reasons behind the error, which is not stored on chain.\nThis makes this a very cheap and convenient error-reporting feature at the same time.\nMore specifically, an error instance is ABI-encoded in the same way as\na function call to a function of the same name and types would be\nand then used as the return data in the revert opcode.\nThis means that the data consists of a 4-byte selector followed by ABI-encoded data.\nThe selector consists of the first four bytes of the keccak256-hash of the signature of the error type.\n\nNote\nIt is possible for a contract to revert\nwith different errors of the same name or even with errors defined in different places\nthat are indistinguishable by the caller. For the outside, i.e. the ABI,\nonly the name of the error is relevant, not the contract or file where it is defined.\n\nThe statement require(condition, \"description\"); would be equivalent to\nif (!condition) revert Error(\"description\") if you could define error Error(string).\nNote, however, that Error is a built-in type and cannot be defined in user-supplied code.\nSimilarly, a failing assert or similar conditions will revert with an error\nof the built-in type Panic(uint256).\n\nNote\nError data should only be used to give an indication of failure, but\nnot as a means for control-flow. The reason is that the revert data\nof inner calls is propagated back through the chain of external calls\nby default. This means that an inner call\ncan “forge” revert data that looks like it could have come from the\ncontract that called it.\n\nMembers of Errors\n\nerror.selector: A bytes4 value containing the error selector.\n\nInheritance\nSolidity supports multiple inheritance including polymorphism.\nPolymorphism means that a function call (internal and external)\nalways executes the function of the same name (and parameter types)\nin the most derived contract in the inheritance hierarchy.\nThis has to be explicitly enabled on each function in the\nhierarchy using the virtual and override keywords.\nSee Function Overriding for more details.\nIt is possible to call functions further up in the inheritance\nhierarchy internally by explicitly specifying the contract\nusing ContractName.functionName() or using super.functionName()\nif you want to call the function one level higher up in\nthe flattened inheritance hierarchy (see below).\nWhen a contract inherits from other contracts, only a single\ncontract is created on the blockchain, and the code from all the base contracts\nis compiled into the created contract. This means that all internal calls\nto functions of base contracts also just use internal function calls\n(super.f(..) will use JUMP and not a message call).\nState variable shadowing is considered as an error. A derived contract can\nonly declare a state variable x, if there is no visible state variable\nwith the same name in any of its bases.\nThe general inheritance system is very similar to\nPython’s,\nespecially concerning multiple inheritance, but there are also\nsome differences.\nDetails are given in the following example.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n\ncontract Owned {\n address payable owner;\n constructor() { owner = payable(msg.sender); }\n}\n\n// Use `is` to derive from another contract. Derived\n// contracts can access all non-private members including\n// internal functions and state variables. These cannot be\n// accessed externally via `this`, though.\ncontract Emittable is Owned {\n event Emitted();\n\n // The keyword `virtual` means that the function can change\n // its behavior in derived classes (\"overriding\").\n function emitEvent() virtual public {\n if (msg.sender == owner)\n emit Emitted();\n }\n}\n\n// These abstract contracts are only provided to make the\n// interface known to the compiler. Note the function\n// without body. If a contract does not implement all\n// functions it can only be used as an interface.\nabstract contract Config {\n function lookup(uint id) public virtual returns (address adr);\n}\n\nabstract contract NameReg {\n function register(bytes32 name) public virtual;\n function unregister() public virtual;\n}\n\n// Multiple inheritance is possible. Note that `Owned` is\n// also a base class of `Emittable`, yet there is only a single\n// instance of `Owned` (as for virtual inheritance in C++).\ncontract Named is Owned, Emittable {\n constructor(bytes32 name) {\n Config config = Config(0xD5f9D8D94886E70b06E474c3fB14Fd43E2f23970);\n NameReg(config.lookup(1)).register(name);\n }\n\n // Functions can be overridden by another function with the same name and\n // the same number/types of inputs. If the overriding function has different\n // types of output parameters, that causes an error.\n // Both local and message-based function calls take these overrides\n // into account.\n // If you want the function to override, you need to use the\n // `override` keyword. You need to specify the `virtual` keyword again\n // if you want this function to be overridden again.\n function emitEvent() public virtual override {\n if (msg.sender == owner) {\n Config config = Config(0xD5f9D8D94886E70b06E474c3fB14Fd43E2f23970);\n NameReg(config.lookup(1)).unregister();\n // It is still possible to call a specific\n // overridden function.\n Emittable.emitEvent();\n }\n }\n}\n\n// If a constructor takes an argument, it needs to be\n// provided in the header or modifier-invocation-style at\n// the constructor of the derived contract (see below).\ncontract PriceFeed is Owned, Emittable, Named(\"GoldFeed\") {\n uint info;\n\n functio","tokens":15000,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263296060,"hash":"b5be2af7e6db484d8002897ebf956b8563a584d7"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvSpb2QEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJvwMxu3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJjL2hjL2VuLWdiL2FydGljbGVzLzE4MjEzODQzMDk2MDkxLVVzaW5nLUFyYml0cnVtLXMtdHJhZGl0aW9uYWwtYnJpZGdlLXRvLW1vdmUtZnVuZHMtdG8tTWFpbm5ldAY7CFQ6CXJhbmtpBw%3D%3D--fbdea8ac2920a3284e824732234c5e088d48b37c","domain":"support.arbitrum.io","title":"Using Arbitrum's traditional bridge to move funds to Mainnet – Arbitrum Foundation","text":"If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fast exit liquidity provider like Hop, Connext, Across, Celer, or Maker. Why do I have to wait 8 days?This is how all optimistic rollups work. Optimistic rollups use something called fraud proofs in order to keep participants in the network honest. There is a \"challenge period\" for these proofs. When one party submits a claim about the state of the chain, another party has ~8 days to challenge that claim. If you'd like to read more about the technical details of Arbitrum, see Inside Arbitrum.If you're more of a visual and auditory learner, watch our videos about challenges and proofs.  More Resources:1 - (Youtube) Multi round Fraud Proofs: What, How, and Why.2 - (Youtube) Challenge Protocol\n\n Recently viewed articlesWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Partnerships with ArbitrumHow can I add Arbitrum network to my wallet?Why do I need ETH to use the Arbitrum network?\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n How can I add Arbitrum network to my wallet?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Godfrey brai\n\n 2 years ago\n\n I have waited for more than 12 days I still can find my ethPlease help me rectify \n\n 0\n\n Please sign in to leave a comment.","tokens":378,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263303318,"hash":"f91a9220f08aaf8d56cce70fd0a677dfc91bff30"}
{"url":"https://docs.soliditylang.org/en/develop/layout-of-source-files.html","domain":"docs.soliditylang.org","title":"Layout of a Solidity Source File — Solidity 0.8.38-develop documentation","text":"Layout of a Solidity Source File\n\n Edit on GitHub\n\nLayout of a Solidity Source File\nSource files can contain an arbitrary number of\ncontract definitions, import ,\npragma and using for directives and\nstruct, enum, function, error\nand constant variable definitions.\n\nSPDX License Identifier\nTrust in smart contracts can be better established if their source code\nis available. Since making source code available always touches on legal problems\nwith regards to copyright, the Solidity compiler encourages the use\nof machine-readable SPDX license identifiers.\nEvery source file should start with a comment indicating its license:\n// SPDX-License-Identifier: MIT\nThe compiler does not validate that the license is part of the\nlist allowed by SPDX, but\nit does include the supplied string in the bytecode metadata.\nIf you do not want to specify a license or if the source code is\nnot open-source, please use the special value UNLICENSED.\nNote that UNLICENSED (no usage allowed, not present in SPDX license list)\nis different from UNLICENSE (grants all rights to everyone).\nSolidity follows the npm recommendation.\nSupplying this comment of course does not free you from other\nobligations related to licensing like having to mention\na specific license header in each source file or the\noriginal copyright holder.\nThe comment is recognized by the compiler anywhere in the file at the\nfile level, but it is recommended to put it at the top of the file.\nMore information about how to use SPDX license identifiers\ncan be found at the SPDX website.\n\nPragmas\nThe pragma keyword is used to enable certain compiler features\nor checks. A pragma directive is always local to a source file, so\nyou have to add the pragma to all your files if you want to enable it\nin your whole project. If you import another file, the pragma\nfrom that file does not automatically apply to the importing file.\n\nVersion Pragma\nSource files can (and should) be annotated with a version pragma to reject\ncompilation with future compiler versions that might introduce incompatible\nchanges. We try to keep these to an absolute minimum and\nintroduce them in a way that changes in semantics also require changes\nin the syntax, but this is not always possible. Because of this, it is always\na good idea to read through the changelog at least for releases that contain\nbreaking changes. These releases always have versions of the form\n0.x.0 or x.0.0.\nThe version pragma is used as follows: pragma solidity ^0.5.2;\nA source file with the line above does not compile with a compiler earlier than version 0.5.2,\nand it also does not work on a compiler starting from version 0.6.0 (this\nsecond condition is added by using ^). Because\nthere will be no breaking changes until version 0.6.0, you can\nbe sure that your code compiles the way you intended. The exact version of the\ncompiler is not fixed, so that bugfix releases are still possible.\nIt is possible to specify more complex rules for the compiler version,\nthese follow the same syntax used by npm.\n\nNote\nUsing the version pragma does not change the version of the compiler.\nIt also does not enable or disable features of the compiler. It just\ninstructs the compiler to check whether its version matches the one\nrequired by the pragma. If it does not match, the compiler issues\nan error.\n\nABI Coder Pragma\nBy using pragma abicoder v1 or pragma abicoder v2 you can\nselect between the two implementations of the ABI encoder and decoder.\nThe new ABI coder (v2) is able to encode and decode arbitrarily nested\narrays and structs. Apart from supporting more types, it involves more extensive\nvalidation and safety checks, which may result in higher gas costs, but also heightened\nsecurity.\nIt is considered non-experimental as of Solidity 0.6.0 and it is enabled by default starting\nwith Solidity 0.8.0. The old ABI coder can still be selected using pragma abicoder v1;.\n\nWarning\nThe ABI coder v1 is deprecated and scheduled for removal.\nUse ABI coder v2 instead.\n\nThe set of types supported by the new encoder is a strict superset of\nthe ones supported by the old one. Contracts that use it can interact with ones\nthat do not without limitations. The reverse is possible only as long as the\nnon-abicoder v2 contract does not try to make calls that would require\ndecoding types only supported by the new encoder. The compiler can detect this\nand will issue an error. Simply enabling abicoder v2 for your contract is\nenough to make the error go away.\n\nNote\nThis pragma applies to all the code defined in the file where it is activated,\nregardless of where that code ends up eventually. This means that a contract\nwhose source file is selected to compile with ABI coder v1\ncan still contain code that uses the new encoder\nby inheriting it from another contract. This is allowed if the new types are only\nused internally and not in external function signatures.\n\nNote\nUp to Solidity 0.7.4, it was possible to select the ABI coder v2\nby using pragma experimental ABIEncoderV2, but it was not possible\nto explicitly select coder v1 because it was the default.\n\nExperimental Pragma\nThe second pragma is the experimental pragma. It can be used to enable\nfeatures of the compiler or language that are not yet enabled by default.\nThe following experimental pragmas are currently supported:\n\nABIEncoderV2\nBecause the ABI coder v2 is not considered experimental anymore,\nit can be selected via pragma abicoder v2 (please see above)\nsince Solidity 0.7.4.\n\nSMTChecker\nIf you use pragma experimental SMTChecker;, then you get additional\nsafety warnings which are obtained by querying an\nSMT solver.\nThe component does not yet support all features of the Solidity language and\nlikely outputs many warnings. In case it reports unsupported features, the\nanalysis may not be fully sound.\n\nNote\nThe SMTChecker pragma is deprecated and will be removed.\nTo enable SMTChecker, simply select select an engine when invoking the compiler.\n\nImporting other Source Files\n\nSyntax and Semantics\nSolidity supports import statements to help modularise your code that\nare similar to those available in JavaScript\n(from ES6 on). However, Solidity does not support the concept of\na default export.\nAt a global level, you can use import statements of the following form:\nopen in Remix\nimport \"filename\";\n\nThe filename part is called an import path.\nThis statement imports all global symbols from “filename” (and symbols imported there) into the\ncurrent global scope (different than in ES6 but backwards-compatible for Solidity).\nThis form is not recommended for use, because it unpredictably pollutes the namespace.\nIf you add new top-level items inside “filename”, they automatically\nappear in all files that import like this from “filename”. It is better to import specific\nsymbols explicitly.\nThe following example creates a new global symbol symbolName whose members are all\nthe global symbols from \"filename\":\nopen in Remix\nimport * as symbolName from \"filename\";\n\nwhich results in all global symbols being available in the format symbolName.symbol.\nA variant of this syntax that is not part of ES6, but possibly useful is:\nopen in Remix\nimport \"filename\" as symbolName;\n\nwhich is equivalent to import * as symbolName from \"filename\";.\nIf there is a naming collision, you can rename symbols while importing. For example,\nthe code below creates new global symbols alias and symbol2 which reference\nsymbol1 and symbol2 from inside \"filename\", respectively.\nopen in Remix\nimport {symbol1 as alias, symbol2} from \"filename\";\n\nImport Paths\nIn order to be able to support reproducible builds on all platforms, the Solidity compiler has to\nabstract away the details of the filesystem where source files are stored.\nFor this reason import paths do not refer directly to files in the host filesystem.\nInstead the compiler maintains an internal database (virtual filesystem or VFS for short) where\neach source unit is assigned a unique source unit name which is an opaque and unstructured identifier.\nThe import path specified in an import statement is translated into a source unit name and used to\nfind the corresponding source unit in this database.\nUsing the Standard JSON API it is possible to directly provide the names and\ncontent of all the source files as a part of the compiler input.\nIn this case source unit names are truly arbitrary.\nIf, however, you want the compiler to automatically find and load source code into the VFS, your\nsource unit names need to be structured in a way that makes it possible for an import callback to locate them.\nWhen using the command-line compiler the default import callback supports only loading source code\nfrom the host filesystem, which means that your source unit names must be paths.\nSome environments provide custom callbacks that are more versatile.\nFor example the Remix IDE provides one that\nlets you import files from HTTP, IPFS and Swarm URLs or refer directly to packages in NPM registry.\nFor a complete description of the virtual filesystem and the path resolution logic used by the\ncompiler see Path Resolution.\n\nComments\nSingle-line comments (//) and multi-line comments (/*...*/) are possible.\nopen in Remix\n// This is a single-line comment.\n\n/*\nThis is a\nmulti-line comment.\n*/\n\nNote\nA single-line comment is terminated by any unicode line terminator\n(LF, VF, FF, CR, NEL, LS or PS) in UTF-8 encoding. The terminator is still part of\nthe source code after the comment, so if it is not an ASCII symbol\n(these are NEL, LS and PS), it will lead to a parser error.\n\nAdditionally, there is another type of comment called a NatSpec comment,\nwhich is detailed in the style guide. They are written with a\ntriple slash (///) or a double asterisk block (/** ... */) and\nthey should be used directly above function declarations or statements.","tokens":2443,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263305955,"hash":"76c951b1df9f0bcc1ec1a55cb4b74dd471a6903f"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBunYXq3EToYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCJuPK2a3EToLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJSL2hjL2VuLWdiL2FydGljbGVzLzE5NDc5NzI5OTA3NDgzLUhvdy1jYW4tSS1hZGQtQXJiaXRydW0tbmV0d29yay10by1teS13YWxsZXQGOwhUOglyYW5raQY%3D--0c4dd60ebb0d7bf90d2fa8dc9ad2c875907e9904","domain":"support.arbitrum.io","title":"How can I add Arbitrum network to my wallet? – Arbitrum Foundation","text":"Either you can manually add it using the following details:\n\nNetwork name: Arbitrum One\nNew RPC URL: https://arb1.arbitrum.io/rpc\nChain ID: 42161\nCurrency symbol: ETH\nBlock Explorer URL: https://arbiscan.io/\n\nOr just simply:\n\nGo to ChainList and connect your MetaMask Wallet.\nLook for 'Arbitrum One' in the search bar at the top of the page.\nTap 'Add to MetaMask' and the verified RPC information will be automatically added to your extension.\n\n Recently viewed articlesUsing Arbitrum's traditional bridge to move funds to MainnetWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Partnerships with ArbitrumWhy do I need ETH to use the Arbitrum network?\n\n Related articles\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?\n\n Please sign in to leave a comment.","tokens":263,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263316166,"hash":"99f8742acdf2443672f8d55f793d4059a28cbbc0"}
{"url":"https://docs.soliditylang.org/en/develop/units-and-global-variables.html","domain":"docs.soliditylang.org","title":"Units and Globally Available Variables — Solidity 0.8.38-develop documentation","text":"Units and Globally Available Variables\n\n Edit on GitHub\n\nUnits and Globally Available Variables\n\nEther Units\nA literal number can take a suffix of wei, gwei or ether to specify a subdenomination of Ether, where Ether numbers without a postfix are assumed to be Wei.\nopen in Remix\nassert(1 wei == 1);\nassert(1 gwei == 1e9);\nassert(1 ether == 1e18);\n\nThe only effect of the subdenomination suffix is a multiplication by a power of ten.\n\nNote\nThe denominations finney and szabo have been removed in version 0.7.0.\n\nTime Units\nSuffixes like seconds, minutes, hours, days and weeks\nafter literal numbers can be used to specify units of time where seconds are the base\nunit and units are considered naively in the following way:\n\n1 == 1 seconds\n1 minutes == 60 seconds\n1 hours == 60 minutes\n1 days == 24 hours\n1 weeks == 7 days\n\nTake care if you perform calendar calculations using these units, because\nnot every year equals 365 days and not even every day has 24 hours\nbecause of leap seconds.\nDue to the fact that leap seconds cannot be predicted, an exact calendar\nlibrary has to be updated by an external oracle.\n\nNote\nThe suffix years has been removed in version 0.5.0 due to the reasons above.\n\nThese suffixes cannot be applied to variables. For example, if you want to\ninterpret a function parameter in days, you can in the following way:\nopen in Remix\nfunction f(uint start, uint daysAfter) public {\n if (block.timestamp >= start + daysAfter * 1 days) {\n // ...\n }\n}\n\nSpecial Variables and Functions\nThere are special variables and functions which always exist in the global\nnamespace and are mainly used to provide information about the blockchain\nor are general-use utility functions.\n\nBlock and Transaction Properties\n\nblockhash(uint blockNumber) returns (bytes32): hash of the given block when blocknumber is one of the 256 most recent blocks; otherwise returns zero\nblobhash(uint index) returns (bytes32): versioned hash of the index-th blob associated with the current transaction.\nA versioned hash consists of a single byte representing the version (currently 0x01), followed by the last 31 bytes\nof the SHA256 hash of the KZG commitment (EIP-4844).\nReturns zero if no blob with the given index exists.\nblock.basefee (uint): current block’s base fee (EIP-3198 and EIP-1559)\nblock.blobbasefee (uint): current block’s blob base fee (EIP-7516 and EIP-4844)\nblock.chainid (uint): current chain id\nblock.coinbase (address payable): current block miner’s address\nblock.difficulty (uint): current block difficulty (EVM < Paris). For other EVM versions it behaves as a deprecated alias for block.prevrandao (EIP-4399 )\nblock.gaslimit (uint): current block gaslimit\nblock.number (uint): current block number\nblock.prevrandao (uint): random number provided by the beacon chain (EVM >= Paris)\nblock.slotnum (uint64): current beacon chain slot number (EIP-7843, EVM >= Amsterdam)\nblock.timestamp (uint): current block timestamp as seconds since unix epoch\ngasleft() returns (uint256): remaining gas\nmsg.data (bytes calldata): complete calldata\nmsg.sender (address): sender of the message (current call)\nmsg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)\nmsg.value (uint): number of wei sent with the message\ntx.gasprice (uint): gas price of the transaction\ntx.origin (address): sender of the transaction (full call chain)\n\nNote\nThe values of all members of msg, including msg.sender and\nmsg.value can change for every external function call.\nThis includes calls to library functions.\n\nNote\nWhen contracts are evaluated off-chain rather than in context of a transaction included in a\nblock, you should not assume that block.* and tx.* refer to values from any specific\nblock or transaction. These values are provided by the EVM implementation that executes the\ncontract and can be arbitrary.\n\nNote\nDo not rely on block.timestamp or blockhash as a source of randomness,\nunless you know what you are doing.\nBoth the timestamp and the block hash can be influenced by miners to some degree.\nBad actors in the mining community can for example run a casino payout function on a chosen hash\nand just retry a different hash if they did not receive any compensation, e.g. Ether.\nThe current block timestamp must be strictly larger than the timestamp of the last block,\nbut the only guarantee is that it will be somewhere between the timestamps of two\nconsecutive blocks in the canonical chain.\n\nNote\nThe block hashes are not available for all blocks for scalability reasons.\nYou can only access the hashes of the most recent 256 blocks, all other\nvalues will be zero.\n\nNote\nThe function blockhash was previously known as block.blockhash, which was deprecated in\nversion 0.4.22 and removed in version 0.5.0.\n\nNote\nThe function gasleft was previously known as msg.gas, which was deprecated in\nversion 0.4.21 and removed in version 0.5.0.\n\nNote\nIn version 0.7.0, the alias now (for block.timestamp) was removed.\n\nABI Encoding and Decoding Functions\n\nabi.decode(bytes memory encodedData, (...)) returns (...): ABI-decodes the given data, while the types are given in parentheses as second argument. Example: (uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes))\nabi.encode(...) returns (bytes memory): ABI-encodes the given arguments\nabi.encodePacked(...) returns (bytes memory): Performs packed encoding of the given arguments. Note that packed encoding can be ambiguous!\nabi.encodeWithSelector(bytes4 selector, ...) returns (bytes memory): ABI-encodes the given arguments starting from the second and prepends the given four-byte selector\nabi.encodeWithSignature(string memory signature, ...) returns (bytes memory): Equivalent to abi.encodeWithSelector(bytes4(keccak256(bytes(signature))), ...)\nabi.encodeCall(function functionPointer, (...)) returns (bytes memory): ABI-encodes a call to functionPointer with the arguments found in the tuple. Performs a full type-check, ensuring the types match the function signature. Result equals abi.encodeWithSelector(functionPointer.selector, (...))\n\nNote\nThese encoding functions can be used to craft data for external function calls without actually\ncalling an external function. Furthermore, keccak256(abi.encodePacked(a, b)) is a way\nto compute the hash of structured data (although be aware that it is possible to\ncraft a “hash collision” using different function parameter types).\n\nSee the documentation about the ABI and the\ntightly packed encoding for details about the encoding.\n\nMembers of bytes\n\nbytes.concat(...) returns (bytes memory): Concatenates variable number of bytes and bytes1, …, bytes32 arguments to one byte array\n\nMembers of string\n\nstring.concat(...) returns (string memory): Concatenates variable number of string arguments to one string array\n\nError Handling\nSee the dedicated section on assert and require for\nmore details on error handling and when to use which function.\n\nassert(bool condition)causes a Panic error and thus state change reversion if the condition is not met - to be used for internal errors.\n\nrequire(bool condition)reverts if the condition is not met - to be used for errors in inputs or external components.\n\nrequire(bool condition, string memory message)reverts if the condition is not met - to be used for errors in inputs or external components. Also provides an error message.\n\nrevert()abort execution and revert state changes\n\nrevert(string memory reason)abort execution and revert state changes, providing an explanatory string\n\nMathematical and Cryptographic Functions\n\naddmod(uint x, uint y, uint k) returns (uint)compute (x + y) % k where the addition is performed with arbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\n\nmulmod(uint x, uint y, uint k) returns (uint)compute (x * y) % k where the multiplication is performed with arbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\n\nkeccak256(bytes memory) returns (bytes32)compute the Keccak-256 hash of the input\n\nNote\nThere used to be an alias for keccak256 called sha3, which was removed in version 0.5.0.\n\nsha256(bytes memory) returns (bytes32)compute the SHA-256 hash of the input\n\nripemd160(bytes memory) returns (bytes20)compute RIPEMD-160 hash of the input\n\necrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)recover the address associated with the public key from elliptic curve signature or return zero on error.\nThe function parameters correspond to ECDSA values of the signature:\n\nr = first 32 bytes of signature\ns = second 32 bytes of signature\nv = final 1 byte of signature\n\necrecover returns an address, and not an address payable. See address payable for\nconversion, in case you need to transfer funds to the recovered address.\nFor further details, read example usage.\n\nWarning\nIf you use ecrecover, be aware that a valid signature can be turned into a different valid signature without\nrequiring knowledge of the corresponding private key. In the Homestead hard fork, this issue was fixed\nfor _transaction_ signatures (see EIP-2), but\nthe ecrecover function remained unchanged.\nThis is usually not a problem unless you require signatures to be unique or use them to identify items.\nOpenZeppelin has an ECDSA helper library that you can use as a wrapper for ecrecover without this issue.\n\nNote\nWhen running sha256, ripemd160 or ecrecover on a private blockchain, you might encounter Out-of-Gas. This is because these functions are implemented as “precompiled contracts” and only really exist after they receive the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution might run into an Out-of-Gas error. A workaround for this problem is to first send Wei (1 for example) to each of the contracts before you use them in your actual contracts. This is not an issue on the main or test net.\n\nerc7201(string memory id) returns (uint)compute the base slot of a storage namespace of a given id according to the erc7201 formula defined by ERC-7201.\nThe formula is equivalent to keccak256(keccak256(id) - 1) & ~0xff.\nThe builtin accepts arbitrary strings, including ones containing whitespace.\nThe function can be used in compile-time context.\n\nMembers of Address Types\nThese members are explained in more detail in the section on members of address.\n\n<address>.balance (uint256)balance of the Address in Wei\n\n<address>.code (bytes memory)code at the Address (can be empty)\n\n<address>.codehash (bytes32)the codehash of the Address\n\n<address payable>.transfer(uint256 amount)send given amount of Wei to Address, reverts on failure, forwards 2300 gas stipend, not adjustable\n\n<address payable>.send(uint256 amount) returns (bool)send given amount of Wei to Address, returns false on failure, forwards 2300 gas stipend, not adjustable\n\nWarning\nsend() and transfer() are deprecated and scheduled for removal.\nSee the section on send and transfer for more information.\n\n<address>.call(bytes memory) returns (bool, bytes memory)issue low-level CALL with the given payload, returns success condition and return data,\nforwards all available gas (subject to additional limits imposed by some EVM versions), adjustable\n\n<address>.delegatecall(bytes memory) returns (bool, bytes memory)issue low-level DELEGATECALL with the given payload, returns success condition and return data,\nforwards all available gas (subject to additional limits imposed by some EVM versions), adjustable\n\n<address>.staticcall(bytes memory) returns (bool, bytes memory)issue low-level STATICCALL with the given payload, returns success condition and return data,\nforwards all available gas (subject to additional limits imposed by some EVM versions), adjustable\n\nFor more information, see the section on Address.\n\nWarning\nYou should avoid using .call() whenever possible when executing another contract function as it bypasses type checking,\nfunction existence check, and argument packing.\n\nWarning\nThere are some dangers in using send: The transfer fails if the call stack depth is at 1024\n(this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order\nto make safe Ether transfers, always check the return value of send, use transfer or even better:\nUse a pattern where the recipient withdraws the Ether.\n\nWarning\nDue to the fact that the EVM considers a call to a non-existing contract to always succeed,\nSolidity includes an extra check using the extcodesize opcode when performing external calls.\nThis ensures that the contract that is about to be called either actually exists (it contains code)\nor an exception is raised.\nThe low-level calls which operate on addresses rather than contract instances (i.e. .call(),\n.delegatecall(), .staticcall(), .send() and .transfer()) do not include this\ncheck, which makes them cheaper in terms of gas but also less safe.\n\nNote\nPrior to version 0.5.0, Solidity allowed address members to be accessed by a contract instance, for example this.balance.\nThis is now forbidden and an explicit conversion to address must be done: address(this).balance.\n\nNote\nIf state variables are accessed via a low-level delegatecall, the storage layout of the two contracts\nmust align in order for the called contract to correctly access the storage variables of the calling contract by name.\nThis is of course not the case if storage pointers are passed as function arguments as in the case for\nthe high-level libraries.\n\nNote\nPrior to version 0.5.0, .call, .delegatecall and .staticcall only returned the\nsuccess condition and not the return data.\n\nNote\nPrior to version 0.5.0, there was a member called callcode with similar but slightly different\nsemantics than delegatecall.\n\nContract-related\n\nthis (current contract’s type)The current contract, explicitly convertible to Address\n\nsuperA contract one level higher in the inheritance hierarchy\n\nselfdestruct(address payable recipient)Destroy the current contract, sending its funds to the given Address\nand end execution.\nNote that selfdestruct has some peculiarities inherited from the EVM:\n\nthe receiving contract’s receive function is not executed.\nthe contract is only really destroyed at the end of the transaction and revert s might “undo” the destruction.\n\nFurthermore, all functions of the current contract are callable directly including the current function.\n\nWarning\nFrom EVM >= Cancun onwards, selfdestruct will only send all Ether in the account to the given recipient and not destroy the contract.\nHowever, when selfdestruct is called in the same transaction that creates the contract calling it,\nthe behaviour of selfdestruct before Cancun hardfork (i.e., EVM <= Shanghai) is preserved and will destroy the current contract,\ndeleting any data, including storage keys, code and the account itself.\nSee EIP-6780 for more details.\nThe new behaviour is the result of a network-wide change that affects all contracts present on\nthe Ethereum mainnet and testnets.\nIt is important to note that this change is dependent on the EVM version of the chain on which\nthe contract is deployed.\nThe --evm-version setting used when compiling the contract has no bearing on it.\nAlso, note that the selfdestruct opcode has been deprecated in Solidity version 0.8.18,\nas recommended by EIP-6049.\nThe deprecation is still in effect and the compiler will still emit warnings on its use.\nAny use in newly deployed contracts is strongly discouraged even if the new behavior is taken into account.\nFuture changes to the EVM might further reduce the functionality of the opcode.\n\nNote\nPrior to version 0.5.0, there was a function called suicide with the same\nsemantics as selfdestruct.\n\nType Information\nThe expression type(X) can be used to retrieve information about the type\nX. Currently, there is limited support for this feature (X can be either\na contract or an integer type) but it might be expanded in the future.\nThe following properties are available for a contract type C:\n\ntype(C).nameThe name of the contract.\n\ntype(C).creationCodeMemory byte array that contains the creation bytecode of the contract.\nThis can be used in inline assembly to build custom creation routines,\nespecially by using the create2 opcode.\nThis property can not be accessed in the contract itself or any\nderived contract. It causes the bytecode to be included in the bytecode\nof the call site and thus circular references like that are not possible.\n\ntype(C).runtimeCodeMemory byte array that contains the runtime bytecode of the contract.\nThis is the code that is usually deployed by the constructor of C.\nIf C has a constructor that uses inline assembly, this might be\ndifferent from the actually deployed bytecode. Also note that libraries\nmodify their runtime bytecode at time of deployment to guard against\nregular calls.\nThe same restrictions as with .creationCode also apply for this\nproperty.\n\nIn addition to the properties above, the following properties are available\nfor an interface type I:\n\ntype(I).interfaceIdA bytes4 value containing the EIP-165\ninterface identifier of the given interface I. This identifier is defined as the XOR of all\nfunction selectors defined within the interface itself - excluding all inherited functions.\n\nThe following properties are available for an integer type T:\n\ntype(T).minThe smallest value representable by type T.\n\ntype(T).maxThe largest value representable by type T.\n\nReserved Keywords\nThese keywords are reserved in Solidity. They might become part of the syntax in the future:\nafter, alias, apply, auto, byte, case, copyof, default,\ndefine, final, implements, in, inline, let, macro, match,\nmutable, null, of, partial, promise, reference, relocatable,\nsealed, sizeof, static, supports, switch, typedef, typeof,\nvar.\n\nNote\nThe following identifiers will become keywords in the future and will no longer be usable as names:\nat, error, layout, leave, super, transient, this.\nThere are also names which will be considered Yul reserved identifiers in the future:\nbasefee, blobbasefee, blobhash, clz, memoryguard, mcopy, prevrandao, slotnum, tload, tstore.","tokens":4524,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263316203,"hash":"ee750d06201b25c0fa748a93e75fa0df57cf2e80"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19480176370459","domain":"support.arbitrum.io","title":"I've sent $ARB from a CEX to my wallet but I can't see it – Arbitrum Foundation","text":"First of all, make sure you have the Arbitrum network added to your wallet and that you're on the correct network.\nMore details here: https://support.arbitrum.io/hc/en-gb/articles/19479729907483-How-can-I-add-Arbitrum-network-to-my-wallet-\n\nSecond, for you to be able to see your $ARB balance in your wallet, you need to add the $ARB smart contract address as a custom token.ARB contract: 0x912ce59144191c1204e64559fe8253a0e49e6548\n\nIf you're using Metamask, it will look like this:\n\n Recently viewed articlesHow can I add Arbitrum network to my wallet?Using Arbitrum's traditional bridge to move funds to MainnetWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Partnerships with Arbitrum\n\n Related articles\n\n How can I add Arbitrum network to my wallet?\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?\n\n Please sign in to leave a comment.","tokens":271,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263338300,"hash":"a76dcb81b8e9bc9ebbd8851ace4464bc23621123"}
{"url":"https://docs.soliditylang.org/en/develop/ir-breaking-changes.html","domain":"docs.soliditylang.org","title":"Solidity IR-based Codegen Changes — Solidity 0.8.38-develop documentation","text":"Solidity IR-based Codegen Changes\n\n Edit on GitHub\n\nSolidity IR-based Codegen Changes\nSolidity can generate EVM bytecode in two different ways:\nEither directly from Solidity to EVM opcodes (“old codegen”) or through\nan intermediate representation (“IR”) in Yul (“new codegen” or “IR-based codegen”).\nThe IR-based code generator was introduced with an aim to not only allow\ncode generation to be more transparent and auditable but also\nto enable more powerful optimization passes that span across functions.\nYou can enable it on the command-line using --via-ir\nor with the option {\"viaIR\": true} in standard-json and we\nencourage everyone to try it out!\nFor several reasons, there are tiny semantic differences between the old\nand the IR-based code generator, mostly in areas where we would not\nexpect people to rely on this behavior anyway.\nThis section highlights the main differences between the old and the IR-based codegen.\n\nSemantic Only Changes\nThis section lists the changes that are semantic-only, thus potentially\nhiding new and different behavior in existing code.\n\nThe order of state variable initialization has changed in case of inheritance.\nThe order used to be:\n\nAll state variables are zero-initialized at the beginning.\nEvaluate base constructor arguments from most derived to most base contract.\nInitialize all state variables in the whole inheritance hierarchy from most base to most derived.\nRun the constructor, if present, for all contracts in the linearized hierarchy from most base to most derived.\n\nNew order:\n\nAll state variables are zero-initialized at the beginning.\nEvaluate base constructor arguments from most derived to most base contract.\nFor every contract in order from most base to most derived in the linearized hierarchy:\n\nInitialize state variables.\nRun the constructor (if present).\n\nThis causes differences in contracts where the initial value of a state\nvariable relies on the result of the constructor in another contract:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.1;\n\ncontract A {\n uint x;\n constructor() {\n x = 42;\n }\n function f() public view returns(uint256) {\n return x;\n }\n}\ncontract B is A {\n uint public y = f();\n}\n\nPreviously, y would be set to 0. This is due to the fact that we would first initialize state variables: First, x is set to 0, and when initializing y, f() would return 0 causing y to be 0 as well.\nWith the new rules, y will be set to 42. We first initialize x to 0, then call A’s constructor which sets x to 42. Finally, when initializing y, f() returns 42 causing y to be 42.\n\nWhen storage structs are deleted, every storage slot that contains\na member of the struct is set to zero entirely. Formerly, padding space\nwas left untouched.\nConsequently, if the padding space within a struct is used to store data\n(e.g. in the context of a contract upgrade), you have to be aware that\ndelete will now also clear the added member (while it wouldn’t\nhave been cleared in the past).\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.1;\n\ncontract C {\n struct S {\n uint64 y;\n uint64 z;\n }\n S s;\n function f() public {\n // ...\n delete s;\n // s occupies only first 16 bytes of the 32 bytes slot\n // delete will write zero to the full slot\n }\n}\n\nWe have the same behavior for implicit delete, for example when array of structs is shortened.\n\nFunction modifiers are implemented in a slightly different way regarding function parameters and return variables.\nThis especially has an effect if the placeholder _; is evaluated multiple times in a modifier.\nIn the old code generator, each function parameter and return variable has a fixed slot on the stack.\nIf the function is run multiple times because _; is used multiple times or used in a loop, then a\nchange to the function parameter’s or return variable’s value is visible in the next execution of the function.\nThe new code generator implements modifiers using actual functions and passes function parameters on.\nThis means that multiple evaluations of a function’s body will get the same values for the parameters,\nand the effect on return variables is that they are reset to their default (zero) value for each\nexecution.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0;\ncontract C {\n function f(uint a) public pure mod() returns (uint r) {\n r = a++;\n }\n modifier mod() { _; _; }\n}\n\nIf you execute f(0) in the old code generator, it will return 1, while\nit will return 0 when using the new code generator.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.1 <0.9.0;\n\ncontract C {\n bool active = true;\n modifier mod()\n {\n _;\n active = false;\n _;\n }\n function foo() external mod() returns (uint ret)\n {\n if (active)\n ret = 1; // Same as ``return 1``\n }\n}\n\nThe function C.foo() returns the following values:\n\nOld code generator: 1 as the return variable is initialized to 0 only once before the first _;\nevaluation and then overwritten by the return 1;. It is not initialized again for the second _;\nevaluation and foo() does not explicitly assign it either (due to active == false), thus it keeps\nits first value.\nNew code generator: 0 as all parameters, including return parameters, will be re-initialized before\neach _; evaluation.\n\nFor the old code generator, the evaluation order of expressions is unspecified.\nFor the new code generator, we try to evaluate in source order (left to right), but do not guarantee it.\nThis can lead to semantic differences.\nFor example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.1;\ncontract C {\n function preincr_u8(uint8 a) public pure returns (uint8) {\n return ++a + a;\n }\n}\n\nThe function preincr_u8(1) returns the following values:\n\nOld code generator: 3 (1 + 2) but the return value is unspecified in general\nNew code generator: 4 (2 + 2) but the return value is not guaranteed\n\nOn the other hand, function argument expressions are evaluated in the same order\nby both code generators with the exception of the global functions addmod and mulmod.\nFor example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.1;\ncontract C {\n function add(uint8 a, uint8 b) public pure returns (uint8) {\n return a + b;\n }\n function g(uint8 a, uint8 b) public pure returns (uint8) {\n return add(++a + ++b, a + b);\n }\n}\n\nThe function g(1, 2) returns the following values:\n\nOld code generator: 10 (add(2 + 3, 2 + 3)) but the return value is unspecified in general\nNew code generator: 10 but the return value is not guaranteed\n\nThe arguments to the global functions addmod and mulmod are evaluated right-to-left by the old code generator\nand left-to-right by the new code generator.\nFor example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.1;\ncontract C {\n function f() public pure returns (uint256 aMod, uint256 mMod) {\n uint256 x = 3;\n // Old code gen: add/mulmod(5, 4, 3)\n // New code gen: add/mulmod(4, 5, 5)\n aMod = addmod(++x, ++x, x);\n mMod = mulmod(++x, ++x, x);\n }\n}\n\nThe function f() returns the following values:\n\nOld code generator: aMod = 0 and mMod = 2\nNew code generator: aMod = 4 and mMod = 0\n\nThe new code generator imposes a hard limit of type(uint64).max\n(0xffffffffffffffff) for the free memory pointer. Allocations that would\nincrease its value beyond this limit revert. The old code generator does not\nhave this limit.\nFor example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >0.8.0;\ncontract C {\n function f() public {\n uint[] memory arr;\n // allocation size: 576460752303423481\n // assumes freeMemPtr points to 0x80 initially\n uint solYulMaxAllocationBeforeMemPtrOverflow = (type(uint64).max - 0x80 - 31) / 32;\n // freeMemPtr overflows UINT64_MAX\n arr = new uint[](solYulMaxAllocationBeforeMemPtrOverflow);\n }\n}\n\nThe function f() behaves as follows:\n\nOld code generator: runs out of gas while zeroing the array contents after the large memory allocation\nNew code generator: reverts due to free memory pointer overflow (does not run out of gas)\n\nInternals\n\nInternal function pointers\nThe old code generator uses code offsets or tags for values of internal function pointers. This is especially complicated since\nthese offsets are different at construction time and after deployment and the values can cross this border via storage.\nBecause of that, both offsets are encoded at construction time into the same value (into different bytes).\nIn the new code generator, function pointers use internal IDs that are allocated in sequence. Since calls via jumps are not possible,\ncalls through function pointers always have to use an internal dispatch function that uses the switch statement to select\nthe right function.\nThe ID 0 is reserved for uninitialized function pointers which then cause a panic in the dispatch function when called.\nIn the old code generator, internal function pointers are initialized with a special function that always causes a panic.\nThis causes a storage write at construction time for internal function pointers in storage.\n\nNote\nThe compiler is free to omit internal functions that are never explicitly referenced by name.\nAs a consequence, assigning to a function type variable in inline assembly does not guarantee\nthat the assigned value will be included in the internal dispatch.\nThe function must also be explicitly referenced elsewhere in the code.\n\nCleanup\nThe old code generator only performs cleanup before an operation whose result could be affected by the values of the dirty bits.\nThe new code generator performs cleanup after any operation that can result in dirty bits.\nThe hope is that the optimizer will be powerful enough to eliminate redundant cleanup operations.\nFor example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.1;\ncontract C {\n function f(uint8 a) public pure returns (uint r1, uint r2)\n {\n a = ~a;\n assembly {\n r1 := a\n }\n r2 = a;\n }\n}\n\nThe function f(1) returns the following values:\n\nOld code generator: (fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe, 00000000000000000000000000000000000000000000000000000000000000fe)\nNew code generator: (00000000000000000000000000000000000000000000000000000000000000fe, 00000000000000000000000000000000000000000000000000000000000000fe)\n\nNote that, unlike the new code generator, the old code generator does not perform a cleanup after the bit-not assignment (a = ~a).\nThis results in different values being assigned (within the inline assembly block) to return value r1 between the old and new code generators.\nHowever, both code generators perform a cleanup before the new value of a is assigned to r2.","tokens":2650,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263347733,"hash":"9591ad80131f16c5d20003032e142c80f0d83e1f"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/19479729907483-How-can-I-add-Arbitrum-network-to-my-wallet-","domain":"support.arbitrum.io","title":"How can I add Arbitrum network to my wallet? – Arbitrum Foundation","text":"Either you can manually add it using the following details:\n\nNetwork name: Arbitrum One\nNew RPC URL: https://arb1.arbitrum.io/rpc\nChain ID: 42161\nCurrency symbol: ETH\nBlock Explorer URL: https://arbiscan.io/\n\nOr just simply:\n\nGo to ChainList and connect your MetaMask Wallet.\nLook for 'Arbitrum One' in the search bar at the top of the page.\nTap 'Add to MetaMask' and the verified RPC information will be automatically added to your extension.\n\n Recently viewed articlesI've sent $ARB from a CEX to my wallet but I can't see itUsing Arbitrum's traditional bridge to move funds to MainnetWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?Partnerships with Arbitrum\n\n Related articles\n\n I've sent $ARB from a CEX to my wallet but I can't see it\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Why are there 2 different USDC's on Arbitrum?\n\n How can I see the balance of my ETH / Tokens on Arbitrum in my wallet?\n\n Please sign in to leave a comment.","tokens":266,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263351348,"hash":"f4ca11e651c61f14c74cdb61d281facd8133042d"}
{"url":"https://governance.aave.com/t/ezr3al-delegate-platform/14740/48","domain":"governance.aave.com","title":"EzR3aL Delegate Platform - Delegate Platforms - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 40\n\n read \n\n 26\n min\n\n Sep 2023\n\n 44 / 44\n\n Jul 1\n\n Jun 30\n\n Load more posts above\n\n post by EzR3aL on May 13, 2024\n\n 23 days later\n\n post by EzR3aL on Jun 6, 2024\n\n 11 days later\n\n post by EzR3aL on Jun 17, 2024\n\n 14 days later\n\n post by EzR3aL on Jul 1, 2024\n\n 28 days later\n\n post by EzR3aL on Jul 29, 2024\n\n post by EzR3aL on Aug 4, 2024\n\n 22 days later\n\n post by EzR3aL on Aug 26, 2024\n\n 2 months later\n\n post by EzR3aL on Nov 6, 2024\n\n 29 days later\n\n post by EzR3aL on Dec 6, 2024\n\n 2 months later\n\n post by EzR3aL on Jan 21, 2025\n\n 1 month later\n\n post by EzR3aL on Feb 25, 2025\n\n 2 months later\n\n post by EzR3aL on May 5, 2025\n\n 2 months later\n\n post by EzR3aL on Jul 17, 2025\n\n 2 months later\n\n post by EzR3aL on Sep 16, 2025\n\n 29 days later\n\n post by EzR3aL on Oct 15, 2025\n\n 2 months later\n\n post by EzR3aL on Dec 20, 2025\n\n post by EzR3aL on Dec 24, 2025\n\n 3 months later\n\n post by EzR3aL on Mar 24\n\n EzR3aL\n\n Regular\n\n AIP: USDG Listing\nVote: YES\nRationale: Interesting new stablecoin with new backing and issued by Paxos.\nAIP: Add WETH to the wrsETH wstETH E-Mode on Aave V3 Base Instance\nVote: YES\nRationale: eMode enchancement for better usage\nAIP: December Funding Update\nVote: YES\nRationale: monthly funding update, no objection\nAIP: Ethena February E-Modes Adjustments\nVote: YES\nRationale: eMode enchancement for better usage\nAIP: Listing of PT Ethena April Maturity on Plasma Instance\nVote: YES\nRationale: Plasma growth has been great and PT token may help increasing it even more\nAIP: Upgrade Aave instances to v3.6 Part 1\nVote: YES\nRationale: eMode improvement for much more flexibility\nAIP: Orbit Program Renewal - Q1 and Q2 2026\nVote: YES\nRationale: Supports delegates and increases governance activity\nAIP: AGRS (Risk Stewards) migration to Risk Agents\nVote: YES\nRationale: Improvement of the AGRS (new risk agent) framework for faster and flexible execution\nAIP: Upgrade Aave instances to v3.6 Part 2\nVote: YES\nRationale: Part 2 for the other chains\nAIP: Add WETH to the rsETH LST E-Mode on Aave Core Instance\nVote: YES\nRationale: eMode enchancement for better usage\nAIP: stkABPT Emission Update\nVote: YES\nRationale: Slow phase out of staking emissions as approved in a proposal\nAIP: Upgrade Aave instances to v3.6 Part 3\nVote: YES\nRationale: Part 3 for the rest chains\nAIP: Onboard syrupUSDC on Base\nVote: YES\nRationale: Syrup is a strong stablecoin with a lot demand.\nAIP: MegaEth aDI path activation\nVote: YES\nRationale: Needed preparation for the deployment\nAIP: Extend stkAAVE Emissions\nVote: YES\nRationale: no objection\nAIP: Gho Mantle Activation\nVote: YES\nRationale: Mantle is a strong market and might be helpful to boost GHO growth\nAIP: MKR and USDtb oracle adjustments\nVote: YES\nRationale: Changes due to the MKR to SKY migration\nAIP: Listing PT Ethena May\nVote: YES\nRationale: no objection\nAIP: Enhancing Market Granularity in Aave v3.6: Part 1\nVote: YES\nRationale: Preparations for v.3.6 eMode enchancement\nAIP: Onboard Strata srUSDe PT tokens to V3 Core Instance\nVote: YES\nRationale: no objection\nAIP: Aave V3.6 MegaETH Activation\nVote: YES\nRationale: New market launch, no objection\nAIP: Aave V3.6 Mantle Activation\nVote: YES\nRationale: New market launch, no objection\nAIP: Increase WBTC Liquidation Bonus and EURS Reserve Factor on Polygon V3\nVote: YES\nRationale: security reason to be able to liquidate a bigger EURS position\nAIP: Update syrupUSDC liquidation protocol fee\nVote: YES\nRationale: LB was set to 0 by mistake, this corrects it\nAIP: February 2026 - Funding Update\nVote: YES\nRationale: monthly funding, no objection\nAIP: Create Allowance GHO Mantle\nVote: YES\nRationale: GHO launch preparations\nAIP: Focussing the Aave V3 Multichain Strategy - Phase 1\nVote: YES\nRationale: Removal of small and not needed markets\nAIP: Add GHO on Aave Plasma and deploy GSM on Plasma\nVote: YES\nRationale: GHO growth on Plasma boosting\nAIP: GSM Migration\nVote: YES\nRationale: Update the the GSM\nAIP: ACI Is Leaving Aave\nVote: YES\nRationale: One of the saddest day in the DAOs history, but approved to make sure ACI sticks around and off boarding happens smootly.\nAIP: Activate Capo Risk Agent and expand Rates Agent on more networks\nVote: YES\nRationale: no objection\nAIP: Enhancing Market Granularity in Aave 3.6: part 2\nVote: YES\nRationale: Removal of small and not needed markets\nAIP: Gho X-Layer Activation\nVote: YES\nRationale: GHO launch preparations\nAIP: wstETH CAPO Oracle Incident User Reimbursement\nVote: YES\nRationale: Great move by the DAO which proves Aave is the best place to park your crypto\nAIP: Reduce Safety Module Emissions\nVote: YES\nRationale: no objection\n\n 2 months later\n\n post by EzR3aL on May 20\n\n EzR3aL\n\n Regular\n\n Hello everyone,\nThis post is intended to inform the Aave DAO and everyone delegating to me that I will be shutting down my delegation platform at the end of June, alongside the conclusion of the Orbit program.\nThe events of the past six months have made this decision very clear to me.\nDue to personal reasons, I will not be available throughout June. To ensure a seamless offboarding from:\n\nthe Aave Guardian\nadministration of the governance forum\nAPE\nand all other responsibilities\n\nI wanted to announce this today.\nThank you to everyone who trusted and supported me and the DAO over the past nearly three years as a Delegate, as well as everyone I’ve known since the early days of ETHLend.\nWe will likely meet again.\n\n 1 month later\n\n post by EzR3aL on Jun 30\n\n EzR3aL\n\n Regular\n\n Yesterday was the last day. So this platform will be shutdown.\nThanks again everyone\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n Anode Delegate Platform\n\n Delegate Platforms\n\n 108\n\n 9.3k\n\n May 26\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14\n\n Kpk Delegate Platform\n\n Delegate Platforms\n\n 117\n\n 10.4k\n\n Nov 2025","tokens":1515,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263360163,"hash":"3e6b27e08c597ab3236d1f52bfb7f0f51c223794"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale/3615/7","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Aug 2020\n\n 8 / 8\n\n Dec 2020\n\n Aug 2020\n\n post by Farhan_W on Aug 23, 2020\n\n post by abcoathup on Aug 23, 2020\n\n post by Farhan_W on Aug 24, 2020\n\n Farhan_W\n\n Yes i read the docs prior to making contract. Read it multiple times when testing the contract. i have tried with multiple rates. Tried with 1:1 as a rate. Still transaction won’t go through. Is the code i am using correct? or am i missing something. I have also tried using an AllowanceCrowdsale contract and it worked fine. Though i have to use higher gas when sending eth to sale contract to make it success. I am also planning to add individuallyCapped contract but first i have to make this base contract work.\nMy main point is to make a contract that works on default gas limit on any wallet. I already have a working contract that uses chainlink pricefeed for ETH/USD price conversion but that contracts needs minimum 150k gas limit when sending ETH to that contract. But i need a contract that works on default gas limit so users don’t have to manually set the higher gas limit.\n\n post by Farhan_W on Aug 24, 2020\n\n Farhan_W\n\n ok I solved it i guess. Used the mintable token on Solidity version 0.5 and it works as expected.\n\n post by abcoathup on Aug 24, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Farhan_W,\nI thought the ERC20 from OpenZeppelin Contracts v3.x would have worked too. I didn’t see anything obvious in your code.\n\n 3 months later\n\n Split this topic on Nov 26, 2020\n\n A post was split to a new topic: How to write big numbers into a migrations script?\n\n Split this topic on Nov 29, 2020\n\n A post was split to a new topic: Check rate for Crowdsale\n\n 8 days later\n\n Split this topic on Dec 7, 2020\n\n A post was split to a new topic: Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error sending Ether to sales contract\n\n Contracts\n\n erc20,crowdsale\n\n 10\n\n 1.2k\n\n Nov 2020\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020\n\n Crowdsale send BNB fail\n\n Contracts\n\n crowdsale\n\n 8\n\n 6.4k\n\n Mar 2021\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Help me write an erc20 token and a crowdsale contract\n\n Contracts\n\n erc20\n\n 9\n\n 8.0k\n\n Dec 2020","tokens":617,"squid":"ink-security_audits","role":"Sentinel","at":1791263364901,"hash":"40b859f23ba769da56cf1e1d6be8852611bb0987"}
{"url":"https://ethresear.ch/t/eip-8411-payload-segmentation-under-the-shadow-simulator/26070","domain":"ethresear.ch","title":"EIP-8411 payload segmentation under the Shadow simulator - Networking - Ethereum Research","text":"EIP-8411 payload segmentation under the Shadow simulator \n\n Networking\n\n p2p,scaling\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 23\n\n 1 / 1\n\n Sep 23\n\n 13d ago\n\n post by cskiraly on Sep 23\n\n cskiraly\n\n A short follow-up to EIP-8411: what segmented payload diffusion is made of; the detailed technical report is here.\nTL;DR\n\nWe reran the EIP-8411 post’s main comparison under a second simulator, Shadow, over QUIC and over TCP, and the same code on the real Linux network stack.\nA-tuned, the design the post recommends, matches its earlier results within a few percent, and every segmented variant stays faster than the whole message in every configuration tested.\nThe two simulators disagree on the whole message’s latency and on where variant C ranks; both trace to how a node’s uplink queue is modelled, fair queueing in the harness against first-come-first-served in Shadow. B’s completion tail is longer only under Shadow over QUIC.\nOn one Linux machine, 100 processes on the kernel’s stack with the links shaped by its traffic control, A-tuned and C over QUIC land within the simulators’ own spread, and the whole message keeps the machine two to four times busier than the segmented variants.\nNone of this tests the bandwidth model, a full client, or a node’s CPU cost on its own machine.\n\nWhat the comparisons test\nThe earlier posts used one in-process harness: the real Prysm, go-libp2p and quic-go stacks over go-libp2p’s simulated network (simnet), under Go’s virtual clock. A result of 5 s to 0.7 s needs a check of how much depends on that harness.\nShadow runs one real process per node on real sockets and intercepts system calls. Its own TCP stack also lets us test TCP with yamux, which the harness cannot run. We reran the previous post’s Figure 1 with the same topology, links, latencies and seeds, ten seeds per point:\n\ncomparison\nwhat it tests\n\nPublished record versus harness twin\nWhether code changes for Shadow compatibility changed the results; the twin uses the exact binary built for Shadow.\n\nHarness twin versus Shadow QUIC\nWhether the result survives a different simulator.\n\nShadow QUIC versus Shadow TCP\nWhether the result depends on transport.\n\nBoth simulators use cold connections with the libraries’ default windows, per-node uplink and downlink rates, fixed one-way latency per pair, and no cross-traffic. Both replace the operating system’s network stack, charge nothing for CPU time, and omit the full client. Their agreement increases confidence in the harness’s wiring and transport modelling; it adds no evidence about hashing cost or the bandwidth model.\nThe Linux run separately checks the kernel stack and the real clock, using one process per network namespace and virtual links from the same topology export. One machine cannot carry 500 nodes cleanly, so this check uses the 100-node cells in “What this says about reality” below.\nA-tuned agrees; the baseline and alternatives vary\nSegmentation lets a node forward parts before the whole payload arrives. A-tuned, the earlier post’s reference design, combines segmentation with selective pushes and disciplined requests. A carries segments on one gossipsub topic, B through the partial-message extension, and C on one topic per segment, each with and without a Reed–Solomon code (RS).\nThe cell uses 500 nodes and a 1 MiB payload, with home nodes at 50 Mbps up and 100 down. The builder publishes once; a node completes when it holds the whole payload. The 3 s budget is the time available to reach everyone.\nFigure 1 under Shadow1540×1330 130 KB\nThe post’s Figure 1, four columns per variant: the published record, its harness twin, Shadow over QUIC, Shadow over TCP. Bars: receiver p99; ticks: p50; both are medians across ten seeds, whiskers ±1 s.d.; dashed line: the 3 s budget. Three scenarios as in the post: home builder with all nodes at home, home builder with 20% datacenter nodes, datacenter builder with 20% datacenter nodes.\nA-tuned reproduces within a few percent of its twin at both quantiles, in every scenario, on both transports. The twin matches the published record for every segmented variant; the whole message’s twin is 19% slower in the mixed scenario. Every segmented variant meets the 3 s budget on every side, and the whole message is always slowest.\nThe main difference is the uplink queue. The harness uses fair queueing (fq_codel); Shadow uses first-come-first-served (FIFO). When several copies compete for an uplink, fair queueing advances them together, so they all finish late. FIFO lets the first copy finish earlier, allowing its receiver to start the next hop while other copies wait. A has little queued at once; C’s concurrent meshes queue the whole payload’s worth in 32 KiB pieces, making its completion sensitive to that order.\nThese are configurations a node can encounter: a host or router can use fq_codel (RFC 8290), while an access device can use FIFO. Actual paths also contain routers, cross-traffic and other queue disciplines. PIE, for example, controls queue delay without sharing capacity between flows (RFC 8033); we have not measured it. The two results are not bounds on reality or evidence of which configuration is more common.\nThree discrepancies remain:\n\nThe whole message is ~33% faster under Shadow (−34% against its twin at the median with a home builder, −16% with a datacenter builder). Switching Shadow to fair sharing over TCP reverses the advantage: the whole message becomes slower than on the harness. Queue order explains the advantage, but the switch does not quantitatively reproduce the harness.\n\nC is ~20% faster under Shadow with a home builder, and faster again over TCP. Fair sharing removes about half of its TCP advantage. Shadow’s unpaced TCP benefits more from FIFO than paced QUIC does; a Linux TCP stack paces its sends too, so this extra benefit is mostly a simulation artifact, an inference from the kernel’s behaviour rather than a measurement. A residual of about a tenth on both transports, with more duplicates under Shadow, remains unexplained. A is insensitive to the queue in every configuration measured, while C moves from the slowest segmented variant on the harness to among the fastest under Shadow. The report gives the socket and pacing mechanics.\n\nB’s tail is longer only under Shadow QUIC (coded B’s p99 is +40% against its twin with a home builder; medians agree within 7%; TCP tails match). B claims each part from one peer and waits, exposing slow service that A’s redundant pushes can mask. Capping the shared UDP send buffer from 7 MB to 64 KB removes about a third of the excess tail at one seed. The remaining tail is unexplained.\n\nFor the whole-message baseline, the harness and Shadow give 4.9 s and 3.2 s medians at 500 nodes and 1 MiB with a home builder. Both miss the budget; A-tuned’s improvements are 6.5× and 4.1×. The earlier posts report the harness’s number.\nWhat this says about reality\nThe Linux check adds the kernel network stack and CPU time that both simulators omit. It uses the same node binary, rates and one-way delays, either uplink queue, and a wall-clock publish. The largest cell one 40-thread machine carries cleanly for the segmented variants is 100 nodes at degree 70. Above that, host saturation dominates delivery time.\nAt 100 nodes and 1 MiB with home link bandwidth, the tables give medians across seeds of receivers’ p50 / p99 completion time in seconds and the real-stack difference from the paired simulator. Host CPU is the mean over all 40 threads during the 10 s after publish. First, FIFO against Shadow:\n\nvariant\ntransport\nShadow (s)\nreal stack (s)\nreal stack vs Shadow (%)\nhost CPU (%)\n\nwhole message\nQUIC\n2.20 / 2.95\n3.61 / 4.78\n+68% / +58%\n35\n\nA-tuned\nQUIC\n0.76 / 1.00\n0.78 / 1.07\n+4% / +9%\n8\n\nC\nQUIC\n0.71 / 0.93\n0.85 / 1.06\n+18% / +15%\n14\n\nwhole message\nTCP\n2.72 / 3.74\n3.32 / 4.37\n+23% / +18%\n23\n\nA-tuned\nTCP\n0.75 / 0.97\n0.97 / 1.31\n+27% / +37%\n7\n\nC\nTCP\n0.56 / 0.73\n0.93 / 1.18\n+66% / +61%\n14\n\nThen fq_codel against the harness, which runs QUIC only:\n\nvariant\ntransport\nharness (s)\nreal stack (s)\nreal stack vs harness (%)\n\nwhole message\nQUIC\n3.49 / 4.76\n4.22 / 5.53\n+25% / +18%\n\nA-tuned\nQUIC\n0.68 / 0.94\n0.78 / 1.09\n+14% / +17%\n\nC\nQUIC\n0.88 / 1.10\n0.89 / 1.11\n−1% / −1%\n\nwhole message\nTCP\n–\n4.40 / 5.60\n–\n\nA-tuned\nTCP\n–\n0.93 / 1.33\n–\n\nC\nTCP\n–\n0.97 / 1.22\n–\n\nWith each simulator paired to the queue it models, segmented QUIC is within −1 to +18% of the simulators on the real stack, with the same bytes and meshes, within the simulators’ own spread on these cells. The larger TCP gaps compare Linux TCP with Shadow’s implementation and therefore bear on Shadow’s TCP fidelity.\nThe whole message is slower than both simulators. Over QUIC, host CPU contributes to that result: spreading one 1 MiB message keeps the machine two to four times busier than spreading segments. At 250 nodes it stays busy through most of an 8 s delivery, while the segmented variants saturate it for about a second. This is evidence from one shared host and kernel; it does not measure a node on its own machine. The report’s section 10 gives the transport, queue and saturation details.\nSegmentation moves the median from seconds to under a second on both simulators and both transports; the real-stack segmented results fall within the simulators’ own spread. Segmentation’s advantage survives these cross-checks; the exact speedup and ranking of alternatives depend on the network model.\nThe technical report contains the method, size sweeps, sensitivity tests and open questions. The earlier harness is in segstudy; eth-networking-lab prepares Shadow cells and pairs their records with the harness.\nNote: the code behind this post, the node, the simulator tooling and the patched Shadow, is pinned at tag shadow-crosscheck of eth-networking-studies, with the commands to run a cell in its README. The clean prototype of variant A is still the variant-a branch of Prysm.\n\n read \n\n 4\n min\n\n Powered by Discourse","tokens":2490,"squid":"ink-research","role":"Deep Scholar","at":1791263370570,"hash":"61b826991c72da0b830db032fb5eea62e92a0cc5"}
{"url":"https://governance.aave.com/t/tokenlogic-delegate-platform/12516/1","domain":"governance.aave.com","title":"TokenLogic Delegate Platform - Delegate Platforms - Aave","text":"TokenLogic Delegate Platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Key Details\n\n Introduction\n\n Why TokenLogic\n\n Values\n\n Focus Areas\n\n The Team\n\n Conflicts of Interest\n\n Delegation\n\n Copyright\n\n Mar 2023\n\n 1 / 39\n\n Mar 2023\n\n 1d ago\n\n post by TokenLogic on Mar 29, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Screenshot 2024-05-19 at 15.00.131777×893 124 KB\nHi Aave Community \nWe are excited to announce that TokenLogic is creating a delegate platform to compliment our ongoing contributions to Aave. Members of our team have been contributing to Aave since 2021 and the “TokenLogic Delegate Platform” represents our active contributions to Aave’s governance\nTokenLogic is a newly formed independent voting delegate focused on supporting the growth and adoption of decentralisation communities through governance participation.\nKey Details\nDelegate Address: 0x2cc1ADE245020FC5AAE66Ad443e1F66e01c54Df1\nTelegram: @Matthew_Graham\nDiscord: Matthew_Graham#9177\nTwitter: Token_Logic\nTwitter: Matthew\nExternal Website: www.tokenlogic.xyz\nDedicated Email: aave@tokenlogic.com.au\nLegacy Voting Record: Boardroom\nNew Delegation Boardroom\nIntroduction\nScreenshot 2024-04-08 at 19.38.211561×580 109 KB\nI am thrilled to announce that Aave is to become the primary delegation platform for TokenLogic. As the founder, @MatthewGraham, I have been actively contributing to Aave since May 2021. I led the Aave team at Llama from receipt of the first grant in mid-2021 and by late 2022, Llama transitioned into a service provider where I am currently managing the Llama <> Aave program.\nTokenLogic will act purely independent and will cast all votes with Aave’s best interest front of mind and without outside influence. As a delegate, TokenLogic commits to dedicating time and resources to supporting Aave’s development and growth whilst maintaining complete independence from Llama’s voting process. We are actively scoping out our front end where we intend to provide details about TokenLogic and our voting history within the Aave ecosystem.\nWhy TokenLogic\nAt TokenLogic we believe in helping communities grow and develop progressive governance ecosystems. Our delegate platform is intended to serve as an independent voting voice within the thriving Aave ecosystem.\nAs the Aave ecosystem grows and matures, the protocol benefits from delegation diversity with independent visions and value propositions.\nMembers of TokenLogic are deeply integrated into the Aave ecosystem. The below highlights some of their ongoing contributions to the Aave ecosystem:\n\nAave Guardian\nFinance Service Provider\nAnalytics Platform\nGHO’s Growth\n\nValues\nAt TokenLogic we believe in being open, building trust through collaboration and realising possibilities together as a team.\nOur values are at the centre of everything we do. They shape how we act with each other, our partners and help us to achieve our vision of helping communities realise their full potential.\nOur foundational beliefs, reflect our values:\n\nTransparency/Openness. We believe in open lines of communication and transparency. We share our knowledge and embrace diversity of thought.\nTrust. We partner constructively and develop close working relationships. We actively listen to the community’s feedback and support compromise to foster solutions in effort to help the community realise its fullest potential.\nIntegrity. We act honestly and ethically in all dealings. We reinforce a culture of doing what is right.\nCollaboration. We believe in achieving together and building trust as we strive to deliver the best in all that we do.\nEntrepreneurial Spirit. We adopt an ‘owner mindset’. We identify opportunities and we take the initiative to pursue new and innovative ways of delivering value.\n\nFocus Areas\nThe following are areas of interest where TokenLogic seeks to focus its efforts:\n\nGHO Adoption. Accelerating the transition from a safe/guarded launch to achieving escape velocity via the widespread adoption of GHO across DeFi.\nRevenue Growth. Growth avenues expected to attract new users, protocol revenue and tailoring of risk parameters supportive of those building on top of Aave Protocol.\nLive Financial Reporting. Expansion of financial data across Aave, such as live financial statements, bad debt dashboards, service provider funding contracts v Aave budgets and asset holding performance over time\nAave v3 Features. Initiatives that introduce and extend the v3 design features of Aave Protocol, such as portals, facilitator roles and meta-governance.\n\nThe Team\nThe TokenLogic team, led by Matthew, consists of the following contributors.\n\nMatthew (@MatthewGraham on the forum, Matthew_Graham_ on Twitter). Mechanical Engineer with 12+ years of industry experience, bachelor degrees in Mechanical Engineering, Investment Finance and Corporate Finance. Published numerous ARCs with a good understanding of DeFi legos, risks, governance, value flow (tokenomics) and fund management.\n\nFermin (@efecarranza on the forum, efecarranza on Twitter). A Software Engineer with 8+ years of experience, working extensively with smart contracts. First at ConsenSys where he developed the underlying contracts for the Infura NFT SDK. Later as a Lead Solidity Developer at Llama supporting Aave DAO. Fermin developed the Aave Swap and Strategic Asset Manager contract, both are used frequently.\n\nJoaquin (@JoFa on the forum, Jo__Fa on Twitter). Full-stack Software Engineer with 5+ years of experience, previously leading development teams on TradFi and AI-driven real-estate projects. Now a Solidity developer working with smart contracts and leading TokenLogic’s automation initiatives. Joaquin has proven adaptability, attention to detail, and drive—delivering consistent, high-quality execution.\n\nSerena (@notnotsez on the forum, notnotsezpoo on Twitter). Data Scientist with a Bachelor’s degree in Data Science and Decisions (UNSW), certified AWS Solutions Architect and Google Cloud Professional Data Engineer. She has experience across the asset management industry and tech consulting, with strong expertise in modern data platforms including AWS, GCP, Snowflake, dbt, SQLMesh and Dagster, specialising in SQL, Python and JavaScript/TypeScript. Serena focuses on building scalable infrastructure and analytics pipelines to enhance Aave’s financial reporting, risk monitoring and governance transparency.\n\nScott (@scottincrypto on the forum, scottincrypto on Twitter). Data Scientist with Bachelor degrees in Mathematics & Electrical Engineering. Scott loves digging into the intricacies and subtleties of novel dApps and innovative protocols and building detailed analytic dashboards showcasing how the protocol/product is performing. Scott led the development of Llama’s backend data analytics platform and built v1 and v2 of Aave DAO financial reporting, treasury, Safety Module and preliminary risk analysis dashboards.\n\nMak (@agentMAK on the forum, agentMAK_ on Twitter). A Full-Stack developer with a Computer Science degree and extensive experience in TradFi payment systems. At Index Coop, MAK built dashboards and tools to monitor the protocol’s performance and product liquidity. Previously Mak has contributed to CitaDAO’s RAW on-chain application where he enhanced the UI/UX. With a deep understanding of Web3 and keen eye for detail, Mak has proven instrumental in creating and upgrading protocols.\n\nThe team is continually growing and we are always on the look out for DeFi Strategists and skilled Developers.\nIf you are interested in joining the team, check out our Careers Page.\nConflicts of Interest\nIf any potential conflicts of interest are to arise, these will be disclosed among various stakeholders within the Aave ecosystem and when it is appropriate, our team members will either abstain or at the very least openly communicate the potential for a conflict of interest to arise.\nDelegation\nIf anyone would like to delegate to TokenLogic, please use the following address:\n0x2cc1ADE245020FC5AAE66Ad443e1F66e01c54Df1\nDelegate Platform: https://delegate.tokenlogic.xyz\nCopyright\nCopyright and related rights waived via CC0.\n\n [TEMP CHECK] - Incentivized Delegate Campaign (3-month)\n\n [TEMP CHECK] GHO Liquidity Pools\n\n [ARFC] Reserve Factor Updates - Polygon Aave v2\n\n [ARFC] Safety Module - Reduce Emissions\n\n [TEMP CHECK] TokenLogic Proposal\n\n read \n\n 120\n min\n\n 25 days later\n\n post by TokenLogic on Apr 23, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Hi Everyone \nIt was an honour to participate and finish on top of the Butter Delegation Competition. We look forward to actively contributing to the Aave ecosystem.\nTo date we have published a TEMP CHECK and ARFC proposal for the community to discuss.\n\n[TEMP CHECK] Polygon v2 to v3 Liquidity Migration\n[ARFC] Polygon v2 - Parameter Update\n [ARFC] wMATIC Risk Parameter Update Polygon v3\n\n@ChaosLabs will be progressing the wMATIC proposal forward along with other risk parameter amendments on the Polygon v3 deployment. We intend to progress the Polygon v2 Parameter Update in the coming weeks. This will likely be our first AIP proposal submission for on-chain voting.\n@EzR3aL we hope over time our continued participation in Aave’s governance will demonstrate a strong track record of adding value and advancing the protocol. Please do note, TokenLogic is only a delegate, not a Service Provider, and governance publications are to be implemented with collaboration from service providers. A distinguishing feature between TokenLogic and some other delegates, TokenLogic contributors have a strong track record of contributing to Aave dating back to mid 2021.\nAs a delegate we welcome any support from the broader community and are committed to voting independently in the best interest of Aave Protocol.\nVoting History to Date\n[TEMP CHECK] - GHO Facilitator Onboarding Process and Application\nVote Cast: YAE\nHaving reviewed this proposal prior to it publication we are glad to support this much needed onboarding process definition proposal. Great work by the @oneski22 and @khan. We look forward to seeing the ARFC emerge in time.\n [ARFC] Align AAVE Risk Parameters on Aave V3 Ethereum Market with Aave V2\nVote Cast: YAE\nA solid proposal by @MarcZeller and we directly support the alignment of risk parameters such that v3 is positioned to offer the same or better user experience relative v2 deployments on the same network.\n [TEMP CHECK] Aave V3 Deployment on zkSync Era Mainnet\nVote Cast: YAE\nGreat to see @fig and the Flipside Crypto team getting more active in the Aave ecosystem. We firm support the expansion of Aave v3 deployments on emerging networks which we expect to generate material adoptions and revenue potential to the Aave DAO.\n ACI Service Provider Proposal\nVote Cast: YAE\nWe are in full support of the one man band, @MarcZeller, growing a team and enhancing ACI’s contribution to the Aave ecosystem.\n[Temp Check] - Community Preference for Supply Cap Limits for LSTs\nVote Cast: YAE\nWe are comfortable with increasing Aave’s risk exposure to LST and believe the rewards for doing so outweigh the risks. The ability to redeeming, or swapping, the LST for the native network token is unique to LST.\n Aave v2/v3 Collectors unification\nVote Cast: YAE\nThis AIP is a key enabler for other service providers to begin managing the Treasury on respective networks. @llama implemented a simpler change enabling v1 aTokens to be received by the v2 Collector Contract and this @bgdlabs proposals achieves the same objective in a more governance efficient, holistic and streamlined approach. This is a great proposal from the @bgdlabs team.\n Update AAVE V3 ETH Risk Parameters\nVote Cast: YAE\nWe are in full support of increasing the LTV of AAVE on Ethereum v3 to match the Ethereum v2 deployment.\nSupply/Borrow Cap Updates V3 Arbitrum\nVote Cast: YAE\nWe are supporting of increasing the Supply and Borrow Caps for wETH and wBTC on Arbitrum. This enables the Aave v3 deployment to continue growing without deposit cap limitations. Enabling sufficient deposit capacity is critical to encouraging builder to create structured products on Aave Protocol.\n Risk Parameter Updates Aave V3 Optimism\nVote Cast: YAE\nWe are direction aligned with this proposal and our only caution was DAI with an LT of 83% as this is starting to get high. This aside, we fully support the proposal from @ChaosLabs.\n[ARFC] Add MAI to Arbitrum Aave V3 pool\nVote Cast: YAE\nWe firmly support the inclusion of additional LST and Stable coins across all Aave Protocol deployments.\n [ARFC] Add MAI to Optimism Aave V3 pool\nVote Cast: YAE\nWe firmly support the inclusion of additional LST and Stable coins across all Aave Protocol deployments.\n\n [TEMP CHECK] - Incentivized Delegate Campaign (3-month)\n\n 27 days later\n\n post by TokenLogic on May 20, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n [TEMP CHECK] Gas Fee Rebate for On-Chain Votes\nVote Cast: YAE\nWe support the reimbursement of gas costs incurred by delegates who have a material representation within Aave’s governance.\nRisk Parameter Updates for Aave V3 Polygon (2023-04-21)\nVote Cast: YAE\nWe are supportive on Gauntlet’s increase the EURS Borrow Cap on Polygon.\nUpgrade Aave V3 pools to Aave V3.0.2\nVote Cast: YAE\nGreat proposal by @bgdlabs. Also noting two mentioned audits. We are strongly in favour of this upgrade.\nIncrease SupplyCap stMATIC Polygon & wETH Arbitrum\nVote Cast: YAE\nGiven approval from risk providers was attained and our preference to grow LST exposure on Aave, we are strongly in favour of this proposal.\nAdd wstETH to Polygon Aave v3\nVote Cast: YAE\nWe are strong advocates for welcoming the growth of LSTs on Aave Protocol.\nBAL Interest Rate Upgrade\nVote Cast: YAE\nSupporting of staged increases in the BAL interest rate that gradually align the Uoptimal value with market rates whilst monitoring the markets response over time.\n[ARFC] MaticX Supply Cap Increase Polygon v3\nVote Cast: YAE\nSimilar to the above, we are supportive of LST growth on Aave Protocol provided it is conducted in a safe and controlled manner.\n[ARFC] Deprecate Aave V2 AMM Market\nVote Cast: YAE\nThis Aave deployment failed to gain meaningful traction in the market. Full support to deprecate the v2 AMM, especially given the v3 version will be coming to market post GHO launch.\n[ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Polygon - 2023.04.23\nVote Cast: YAE\nThis proposal leans into supporting further migration from v2 to v3 which is something TokenLogic is a keen supporter of.\nWAVAX Borrow Cap Update - V3 Avalanche - 04.21.2023\nVote Cast: YAE\nIncreasing the wAVAX Borrow Cap enables the yield maximising strategy to grow Aave’s TVL and wAVAX revenue.\n[ARFC] Aave V2 Interest Rate Curve Changes (2023-04-21)\nVote Cast: NAE\nWe are directionally aligned with this proposal. However, we think the wMATIC parameters are not ideal and should be reworked. We voted NAE to signal an intent to rework the proposal in line with feedback provided on the forum. However, if the community supports the lower wMATIC rates, we will vote YAE at the AIP vote and then monitor how the market responds. If the market dynamics are adversely affected, we will prepare a proposal to revert the wMATIC interest rate parameters.\n[ARFC] Polygon v2 - Parameter Update\nVote Cast: Option 2\nThis is our own proposal. We are supportive of a conservative initial implementation with the option to prepare a follow up proposal after reviewing how the market responds to the first implementation.\n[TEMP CHECK] Aave V3 GHO Genesis Parameters\nVote Cast: YAE\nWe want to see GHO come to market asap. We are supportive of this proposal and acknowledge the ability to amend parameters post launch.\nAave Metis V3\nVote Cast: YAE\nWe view this as an experiment and hope to see strong adoption without consuming many resources to maintain the deployment.\nUpgrade Aave V3 pools to Aave V3.0.2\nVote Cast: YAE\nGreat proposal by @bgdlabs. Looking forward to seeing this in production.\n[TEMP CHECK] Allocation of 300k OP Received by Aave Grants DAO\nVote Cast: YAE\nWe are looking to see AGD use these OP rewards to encourage builders on Aave Optimism v3. Using OP represents a solid alternative to AAVE tokens.\n[ARFC] Aave V3 Interest Rate Curve Changes (2023-04-27)\nVote Cast: YAE\nSolid interest rate improvements and RF adjustments.\n[ARFC] - GHO Facilitator Onboarding Process and Application\nVote Cast: YAE\nHaving review this proposal and provided feedback pre-forum. We are in support of creating a GHO Facilitator onboarding process. We seek to help communities submit applications to become a facilitator in time.\nGauntlet Recommendations for Polygon V3 and Arbitrum V3\nVote Cast: YAE\nWe would have liked to see the BAL Supply Cap increased. However, we are also supportive of increasing the EURS Supply Cap and thus voted YAE on this proposal.\n[ARFC] E-Mode Specific Supply and Borrow Caps\nVote Cast: NAE\nWe voted for no change. If we did not vote this way, our next preference was Option 2.\n[TEMP CHECK] Defining the Service Provider & Delegation Platform Relationship\nVote Cast: Option 2\nWe think Service Providers should already have the context to make informed votes and they should be active in governance. As a result, we believe Service Providers should be excluded from receiving reward for providing voting delegation platform service to the DAO. It is reasonable to expect these costs are somewhat already baked into the Service Provider agreement pricing.\n[TEMP CHECK] Safety Module Update Part I - Migrate AAVE/wETH\nVote Cast: 80/20 AAVE/wstETH\nWe are fans of capital efficiency and believe wstETH to be a low risk asset suitable for inclusion in Aave’s Safety Module. We also noted the comments from Solarcurve in the comments on this post and the overall direction of Balancer to focus on LST paired liquidity.\nMaticX Supply Cap Increase Polygon v3 and AGD Approval\nVote Cast: YAE\nWe are strongly in support of facilitating the safe growth of LST collateral and yield maximising strategies being built on Aave Polygon v3. We also support the corrective USDT payment to AGD. It is not ideal that these proposals are bundled and this should be avoided. We supported this proposal and hoped the feedback from the community would be incorporated for future proposals without creating the need to submit two votes.\nAdd MAI to Aave Optimism V3 pool\nVote Cast: YAE\nStable coin diversity is good for Aave and we are supportive of MAI’s expansion across several networks.\nUpgrade the safety module to v1.5 PART 1\nVote Cast: YAE\nGreat to see this upgrade coming to AIP with two audits from a very strong developer team. Strongly in favour of this proposal.\nAdd MAI to Aave Arbitrum V3 pool\nVote Cast: YAE\nStable coin diversity is good for Aave and we are supportive of MAI’s expansion across several networks.\nSupply and Borrow Cap Updates Aave V3\nVote Cast: YAE\nGlad to support this proposal to support the further safe growth of Aave.\nRisk Parameter Updates Aave V3 Polygon\nVote Cast: YAE\nWe support the continual refinement of risk parameters in line with market conditions.\nUpgrade the safety module to v1.5 PART 2\nVote Cast: YAE\nGreat to see this upgrade coming to AIP with two audits from a very strong developer team. Strongly in favour of this proposal.\nAave V2 Interest Rate Curve Changes (4/21)\nVote Cast: YAE\nIn line with prior comment relating to the Snapshot vote. Although we believe the wMATIC parameters are sub-optimal, we support the overall proposal and reserve the ability to amend the wMATIC interest rate at a later date, pending how the market responds.\nLST Supply Cap Increase Polygon & Arbitrum\nVote Cast: YAE\nWe support the continued safe growth of LSTs on Aave deployments and acknowledge support from the risk providers for all proposed parameter changes.\n[ARFC] Add LUSD Arbitrum v3\nVote Cast: YAE\nWe support the diversification of Aave’s stable coin offering.\n[TEMP CHECK] - Add support for fUSDC on Ethereum v3 Pool\nVote Cast: YAE\nThis represents an exciting growth opportunity for Aave and we welcome further exploration of adding fUSDC as collateral on Aave v3 with conservative risk parameters upon being added.\n[ARFC] Add 1INCH to Aave V3 Ethereum\nVote Cast: YAE\nWe are in support of migrating 1inch from v2 to v3. Adding 1inch to the v3 market is the first step in this journey.\n[ARFC] Add ENS to Aave V3 Ethereum\nVote Cast: YAE\nSimilar reasoning to 1inch above.\n[ARFC] BUSD Offboarding Plan Part II\nVote Cast: YAE\nBUSD is not a good fit for Aave and we support the off boarding effort.\n[ARFC] Activate emode for rETH Aave Ethereum V3 Pool\nVote Cast: YAE\nAdding rETH to the ETH mode will enable more structured products to be built on Aave v3, promote diversify and will lead to great wETH being borrowed with generates revenue for Aave. We believe this to be low risk and are looking for @bgdlabs to review the oracle used within E-Mode before supporting this proposal at AIP stage of the governance process.\n[TEMP CHECK] - Add support for RPL on Ethereum v3\nVote Cast: YAE\nWe support adding RPL, as we did LDO, and we would like to highlight the extra utility that RPL offers relative to LDO. Hopefully there is strong RPL borrowing demand.\n[ARFC] Acquire BB-A-USD and deposit 50% into both Balancer and Aura Finance\nVote Cast: YAE\nWe are supportive of Aave DAO deploying the treasury to earn. Especially where it is perceived to be low risk and in line with other initiatives within the DAO.\n[ARFC] Migrate Holdings from v2 to v3 and acquire wstETH and rETH\nVote Cast: YAE\nWe are supportive of Aave DAO holding funds in the safer of the two deployments. We also support Aave DAO holding the most battle test LST and holding these assets outside of the liquidity pools. We would advocate to explore how a portion of these assets could be used in the future to earn additional yield.\n[ARFC] Consolidate Collector Contract & Secure Service Provider Runway\nVote Cast: YAE\nThe USDC runway on Aave v2 requires replenishing and the logic presented of swapping small holdings of high volatility assets to aUSDC makes a lot of practical sense for Aave DAO.\nRisk Parameter Updates for Ethereum v3 (05/09/2023)\nVote Cast: YAE\nWe support the controlled increase of the LUSD supply cap.\nAave V3 Interest Rate Curve Changes (4/27)\nVote Cast: YAE\nWe support the revised interest rate parameters.\nAGD Approval\nVote Cast: YAE\nWe are supportive of this corrective USDT payment for AGD.\nMaticX Supply Cap Increase Polygon v3\nVote Cast: YAE\nWe support the continued safe growth to LSTs across Aave v3 deployments.\n[ARFC] Add rETH to Aave V3 Arbitrum Liquidity Pool\nVote Cast: YAE\nWith rETH liquidity on Arbitrum growing, we are supportive of adding rETH to Aave v3 with conservative risk parameters.\n\n 12 days later\n\n post by TokenLogic on Jun 1, 2023\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Hi everyone,\nFollowing the snapshot vote for the Delegate Code of Conduct.\nBy this post, the @TokenLogic is officially stating its intent to follow this code and is proud to participate in this initiative.\n\n 7 months later\n\n post by TokenLogic on Jan 7, 2024\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Hi All,\nPlease below our Snapshot voting history continuing on from the most recent vote mentioned above. A separate comment to follow will show our AIP voting history.\n[ARFC] Consolidate Collector Contract & Secure Service Provider Runway\nVote Cast: YAE\n12 months runway should be held in each of the required reserves. This proposal moves towards this direction.\n[ARFC] Migrate Holdings from v2 to v3 and acquire wstETH and rETH\nVote Cast: YAE\nWe are supportive of migrating funds from legacy v2 deployments to v3 and acquiring LSTs within the Treasury.\n [ARFC] Acquire BB-A-USD and deposit 50% into both Balancer and Aura Finance\nVote Cast: YAE\nWe created this proposal and are supportive of improving the efficiency of the DAOs assets whilst accumulating governance influence via token rewards in doing so.\n [TEMP CHECK] - Add support for RPL on Ethereum v3\nVote Cast: YAE\nWe expect to see borrowing demand from RPL’s utility and support the isolation mode risk parameter configuration.\n TEMP CHECK - Add support for fUSDC on Ethereum v3 Pool\nVote Cast: YAE\nWe are supportive of adding productive assets as collateral.\n [ARFC] Activate emode for rETH Aave Ethereum V3 Pool\nVote Cast: YAE\nWe support adding rETH to Category 1 (E-Mode) and enabling users to enter the yield maximising strategy that loops rETH and ETH to generate yield.\n [ARFC] BUSD Offboarding Plan Part II\nVote Cast: YAE\nWe support the continued efforts to offboard BUSD.\n [ARFC] Add ENS to Aave V3 Ethereum\nVote Cast: YAE\nWe support migrating assets from v2 to v3 and adding ENS to v3 with proper risk restrictions enables this to happen.\n [ARFC] Add 1INCH to Aave V3 Ethereum\nVote Cast: YAE\nWe support migrating assets from v2 to v3 and adding 1INCH to v3 with proper risk restrictions enables this to happen.\n [TEMP CHECK] Add ARB to Arbitrum Aave v3\nVote Cast: YAE\nWe support adding the native token to each respective Aave deployment.\n [TEMP CHECK] FlashMinter Facilitator Approval\nVote Cast: YAE\nWe support this development update provide by Aave Companies.\n[ARC] Framework For Recognized Delegates](Snapshot)\nVote Cast: YAE\nWe support recognising the effort of delegates in a more formal capacity.\n [ARC] Delegate Code Of Conduct\nVote Cast: YAE\nThis is a nice improvement and are supporting of introducing a base line of expectations within the DAO.\n [ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Ethereum - 2023.05.18\nVote Cast: YAE\nWe support the analysis and efforts to fine tune the risk parameters presented within this proposal.\n [ARFC] Polygon Supply Cap Update 23.05.2023\nVote Cast: YAE\nWe prepared this proposal and are in support of increasing the supply cap for MaticX on Polygon v3.\n [ARFC] Optimism v3 Supply Cap Update\nVote Cast: YAE\nWe voted in favour of Chaos Lab’s methodology yielding a 21,000 unit wstETH cap.\n [ARFC] Optimism Create ETH E-Mode\nVote Cast: YAE\nWe created this proposal and are in favour of enhancing the LST/ETH yield looping strategies by creation of Category 1 ETH E-mode.\n [TEMP CHECK] Safety Module Upgrade Part II - Asset Diversity, SM Categories & Slashing Updates\nVote Cast: YAE\nWe are in favour of diversifying the assets held in the Aave SM to reduce the dependency on AAVE.\n [TEMP CHECK] Safety Module Upgrade Part III - Enable gauges on BPT in Safety Module (smBPT\nVote Cast: YAE\nCreation of smBPT gauges that replace the standard BPT gauges enhances the efficiency of the overall strategy by removing one of two competing options for where users can deposit the BPT.\n [ARFC] Add fUSDC to Ethereum v3\nVote Cast: YAE\nWe are in favour of adding yield generating assets as collateral.\n [ARFC] Add RPL to Ethereum v3\nVote Cast: YAE\nWe expect to see borrowing demand from RPL’s utility and support the isolation mode risk parameter configuration.\n [ARFC] Polygon v3 Supply Cap Update 2023.05.21\nVote Cast: YAE\nWe support increasing the stMATIC supply cap enabling the stMATIC/wMATIC yield maximising strategy to grow.\n [TEMP CHECK] Aave V3 Deployment on Base\nVote Cast: YAE\nWe are supporting of deploying Aave v3 across various networks with real adoption/usage potential.\n [TEMP CHECK] Pyth to Support AAVE on Optimism as a Secondary Oracle\nVote Cast: AGAINST\nWe do not support the integration of a back up oracle within the Aave Protocol. There is no technical upside of doing so and the feature is not used within the Aave Protocol as it is redundant.\n [TEMP CHECK] Aave v3 MVP deployment on Scroll mainnet\nVote Cast: YAE\nWe are supportive of deploying Aave v3 across various networks to further support Aave’s growth.\n[ARFC] Add FRAX to Ethereum Aave v3\nVote Cast: YAE\nWe co-authored this proposal and are supportive of Aave offer a diverse range of stable coins.\n[TEMP CHECK] Add GMX to Arbitrum v3\nVote Cast: YAE\nWe are supportive of adding GMX to Aave v3 Arbitrum. GMX has experience significant growth during the bear market and is a prominent app within Arbitrum ecosystem.\n[ARFC] Add FRAX Arbitrum Aave v3\nVote Cast: YAE\nWe co-authored this proposal and are supportive of Aave offer a diverse range of stable coins.\n[ARFC] Add native USDC to the Arbitrum V3 pool\nVote Cast: YAE\nWe support introducing native USDC to all Aave v3 deployments.\n [ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.06.15\nVote Cast: YAE\nWe support Chaos Labs proposed CRV changes on Aave v2 Ethereum.\n [ARFC] Gauntlet Recommendation on TUSD for Aave v2 Ethereum\nVote Cast: YAE\nWe support the lower LT TUSD option which is the more aggressive of the two options.\n [ARFC] Chaos Labs - Incremental Reserve Factor Updates - Aave V2 Ethereum\nVote Cast: YAE\nWe are supportive of increasing the RF across Ethereum v2. We expect this to help encourage users to migrate to v3.\n [ARFC] Chaos Labs Risk Parameter Update - CRV Aave V3 Polygon - 2023.06.20\nVote Cast: YAE\nWe support reducing the LT and LTV parameters for CRV on Polygon due to declining liquidity conditions.\n [TEMP CHECK] Integrating MakerDAO’s DSR into Aave V3 Ethereum Pool\nVote Cast: YAE\nWe expect this to be a significant source of growth for aave and expect it to lead to higher borrowing rates of stables coins as users loop sDAI and stable coin debt to generate yield.\n [TEMP CHECK] GHO Stewards: Agile Parameter Changes\nVote Cast: YAE\nGiven the success of the Risk Stewards, we are supportive of the introduction of the GHO Steward role to provide the needed flexibility to manage GHO efficiently.\n [TEMP CHECK] Allocating part of GHO Revenue to Safety Incentives\nVote Cast: YAE\nWe are supportive of distributing GHO to SM depositors to further promote the adoption and velocity of the stable coin.\n [ARFC] Chaos Labs Risk Parameter Updates - FEI on Aave V2 Ethereum - 2023.6.22\nVote Cast: YAE\nWe are supportive of the continued deprecation of the FEI stable coin given how FEI Protocol / Tribe DAO is being sunset.\n [ARFC] Chaos Labs Risk Parameter Updates - Aave V2 Ethereum - 2023.6.23\nVote Cast: YAE\nGiven prevailing market conditions, we are supportive of aggressively reducing Aave’s risk exposure.\n [ARFC] Gas Rebate for Recognized Delegates\nVote Cast: YAE\nWe are supportive of reimbursing gas costs to recognised delegates and deployment costs of service providers.\n [ARFC] Aave Robot v1 activation\nVote Cast: YAE\nWe support the introduction of the Aave Robot v1.\n[ARFC] Framework for ARFC and TEMP CHECK Proposals\nVote Cast: YAE\nWe are supportive of the continued iterative effort of ACI to improve Aave’s governance processes.\n [ARFC] Gauntlet Risk Parameter Updates for Ethereum v3, Arbitrum v3, Ethereum v2\nVote Cast: YAE\nWe broadly support the proposed LTV changes that Gauntlet has proposed.\n [ARFC] Add rETH Aave v3 Optimism\nVote Cast: YAE\nWe are the author of this proposal and are supportive of onboarding additional LSTs to support continued demand for native network tokens, like ETH in this instance.\n[ARFC] Add GMX to Arbitrum v3\nVote Cast: YAE\nWe are supportive of adding GMX to Arbitum.\n[TEMP CHECK] Aave V3 Deployment on Linea Testnet\nVote Cast: YAE\nWe are supportive of deploying Aave v3 on various networks to promote the further adoption of the protocol.\n [TEMP CHECK] Safety Module Upgrade Part IV - Incentives Management Upgrade\nVote Cast: YAE\nWe are supportive of creating an incentive committee to support the maintenance of bribe campaign to maintain the yield across SM deposits.\n [TEMP CHECK] Safety Module Upgrade Part V - veToken Holding\nVote Cast: YAE\nSimilar to the previous ARFC, we are a co-author of this proposal and support the management of ve Assets in the DAOs best interest.\n [ARFC] - Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum - 2023.07.10\nVote Cast: YAE\nWe favour of Chaos Labs aggressive reduction of CRV’s LT and LTV on Ethereum v2.\n [ARFC] TUSD Offboarding Plan\nVote Cast: YAE\nWe support the DAO’s continued efforts to offboard TUSD.\n [TEMP CHECK] Introducing “Curator” by Llama\nVote Cast: YAE\nWe support the creation of a contract, “Curator” that enables the DAO to swap assets via the short executor with MEV protection on Cowswap. Do note, TokenLogic lead the design/specification of the “Curator” for Llama.\n[ARFC] Reserve Factor Updates - Polygon Aave v2\nVote Cast: YAE\nWe published this proposal and are supportive of continually increasing the RF parameters on Polygon v2 to further encourage users to migrate from v2 to v3.\n [ARFC] Gauntlet - Synchronicity Price Adapter “Killswitch” Functionality for LST Emode\nVote Cast: OPTION 3\nWe favoured Option 3 relative to the other options based upon the discussion presented on the forum.\n [ARFC] Chaos Labs Risk Parameter Updates - MAI on Aave V3 - 2023.7.23\nVote Cast: YAE\n [ARFC] GHO Liquidity Pools: Primary Pools Initial Strategy\nVote Cast: YAE\nWe are the author of this proposal. This proposal is a continual of an earlier TEMP CHECK proposal.\n [ARFC] Aave V3 Deployment on Base\nVote Cast: YAE\nWe support deploying Aave v3 across various networks to support the further adoption and usage of the protocol.\n [ARFC] Cancel Llama Service Provider Stream\nVote Cast: ABSTAIN\nAs we receive payment from Llama we have abstained from participating in this vote.\n [ARFC] BUSD Offboarding Plan Part III\nVote Cast: YAE\nWe support the continued effort to offboard BUSD and expect this proposal to become a good revenue source for Aave DAO throughout the deprecation process.\n [ARFC] Aave | Flipside Crypto Facilitator [v2]\nVote Cast: NAY\nWe do not support the current iteration of Flipside’s proposal as it overlaps with other service provider efforts whilst also introducing unneeded bureaucracy within the DAO.\n[ ARFC] Activate LUSD as Collateral on Aave V3 ETH Pool](Snapshot)\nVote Cast: YAE\nWe support enabling LUSD as collateral on Aave v3. LUSD’s stability pool provides a borrowers an opportunity to earn yield with LUSD. We expect this utility to provide a level of borrowing demand support.\n [TEMP CHECK] Treasury Management - Avalanche v2 to v3 Migration\nVote Cast: YAE\nAs the author of this proposal, we favour the migration of the DAO’s funds from Aave v2 Avalanche to v3.\n [ARFC] sDAI Aave V3 Onboarding\nVote Cast: YAE\nWe are supportive of adding yield generating assets as collateral which are expected to stimulate borrowing demand.\n [ARFC] wGHO Aave V3 Onboarding\nVote Cast: YAE\nIt my be to early in GHO’s life for it to be added to Aave v3. With conservative, appropriate, risk parameter we support adding GHO. We would like liquidity conditions to improve and for this to be reflected in further increases to the supply cap.\n [ARFC] Treasury Management - Avalanche v2 to v3 Migration\nVote Cast: YAE\nWe authored this proposal and support the migration of the DAO’s funds from Aave v2 to v3.\n [ARFC] Return OP to Aave Grants DAO Safe\nVote Cast: YAE\nWe support correcting a past mistake that lead to the OP airdrop being directed to the Guardian address and not AGD address on the Optimism Network.\n [ARFC] Increase GHO Borrow Rate\nVote Cast: YAE\nThis proposal begins to reduce the gap between GHO and other stable coin funding rates. We do not expect increasing the interest rate to fix the peg, but potentially reduce the rate at whihc GHO is being borrowed at.\n [ARFC] Enabling USDT as collateral on Aave v3 AVAX Market\nVote Cast: YAE\nWe support amending USDT on Avalanche to enable it being used as collateral.\n [ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Ethereum - 2023.08.25\nVote Cast: YAE\nWe support Chaos Labs suggested amendments to the Ethereum v3 risk parameters.\n [ARFC] Treasury Management - Acquire AURA\nVote Cast: YAE\nTokenLogic brokered the deal with Olympus DAO and is supportive of Aave accumulative AURA with the intention of bootstrapping GHO liquidity.\n [ARFC] Treasury Management - Replace AGD’s DAI Allowance with GHO Allowance\nVote Cast: YAE\nWe are supportive of increasing the adoption and velocity of GHO. With AGD using GHO, it sends a positive signal to the market that the DAO will use its own stable coin for payments.\n [ARFC] Quarterly Gas Rebate Distribution - August 2023\nVote Cast: YAE\nTokenLogic is a beneficiary of this proposal and supports the gas costs of recognised delegates being reimbursed.\n [TEMP CHECK] Update Balancer Ecosystem Holdings\nVote Cast: YAE\n [ARFC] Gauntlet Interest Rate Recommendation for WETH\nVote Cast: YAE\nGiven how the yield from ETH LSTs has faded over time, we are supportive of reducing the Slop1 parameter to be inline / narrowly below the leading LST yield. Upon implementation, this should lead to additional LST/ETH looping and greater ETH revenue as the volume of debt offsets the reduced revenue per unit of ETH debt.\n [ARFC] Gauntlet recommendation for WETH Uopt on Ethereum v3\nVote Cast: OPTION 3\nWe favour the No Change option which is to leave the Uoptimal parameter as is. Generally, the higher the Uoptimal value the more capital efficient the reserve.\n [ARFC] - Chaos Labs Risk Parameter Updates - Aave V3 Avalanche - 2023.09.06\nVote Cast: YAE\nWe support the risk parameter amendments as present by Chaos Labs for the Avalanche v3 deployment.\n [ARFC] wGHO Aave V3 Onboarding\nVote Cast: YAE\nWe are supportive of adding wGHO to the Ethereum v3 deployment, even more so when liquidity conditions improve.\n[ARFC] OP Risk Parameters Update for Aave V3 Optimism Pool\nVote Cast: YAE\nWe support enabling borrowing of OP on the Optimism Aave v3 deployment. We expect this to generate revenue, but are unsure as to if this will become a meaningful revenue driver.\n [ARFC] Safety Module - Polygon & Avalanche Coverage Update\nVote Cast: YAE\nTo further support the migration of users from v2 to v3, we proposed removing the SM’s coverage from v2 deployments on Polygon and Avalanche.\n [ARFC] Expansion of “Orbit” - A DAO Funded Delegate Platform Initiative\nVote Cast: YAE\nWe support the migration of Orbits funding from the ACI to the Aave DAO.\n[TEMP CHECK] Treasury Management - Swap B-80BAL-20wETH to GHO\nVote Cast: YAE\nWith Balancer’s support we propose swapping a portion of the Aave DAOs B-80BAL-20WETH to GHO to fund the AURA OTC swap with Olympus DAO. This is part of a broader strategy to improve the overall efficiency of the DAO’s strategic assets.\n [TEMP CHECK] Treasury Management - Create and Fund GHO Liquidity\nVote Cast: YAE\nWe proposed creating the GHO Liquidity Committee to help support GHO liquidity across several DEX with the use of incentives. This proposal provides the initial funds to support this endeavour.\n [ARFC] Treasury Management - GHO Liquidity Strategy Update\nVote Cast: YAE\nThis publication proposes a revised approach to GHO liquidity across the ecosystem. We voted in favour of this revised approach that includes the use of Bunni and Liquis, built on Uniswap, to grow concentrated liquidity outside of the Balancer ecosystem.\n [TEMP CHECK] Add KNC to Ethereum Aave V3\nVote Cast: YAE\nWe are in favour of adding KNC to Aave v3 Ethereum with proper risk controls in place.\n[TEMP CHECK] Onboard STG to Ethereum Aave v3\nVote Cast: ABSTAIN\nWe don’t believe there is sufficient demand for using STG as collateral on Aave v3 to support adding the token at this point in time.\n [ARFC] TUSD Offboarding Plan Part II\nVote Cast: YAE\nWe are in favour of the continued offboarding of TUSD. To date, we have observed a meaningful increase in TUSD from efforts to date.\n [ARFC] Aave V3 Deployment on zkEVM L2\nVote Cast: YAE\nWe are supportive of deploying Aave v3 across many networks to support the continued growth and adoption of Aave Protocol.\n [ARFC] Treasury Management - GHO Funding\nVote Cast: YAE\nWe advocate for the Aave DAO to increase the usage of GHO as a signal of support for GHO to the broader market. In order to funds Service Providers and Grant DAO alike, GHO is to be acquired from secondary markets.\n [ARFC] Aave V3 Deployment on GnosisChain\nVote Cast: YAE\nWe are supportive of deploying Aave v3 across many networks to support the continued growth and adoption of Aave Protocol.\n [TEMP CHECK] Updated Aave Grants Continuation Proposal\nVote Cast: YAE\nBased upon the latest updates on the forum, we are supportive of this proposal presented by the Aave Grants DAO.\n [ARFC] Aave V2 Markets Deprecation Plan\nVote Cast: YAE\nWe are supportive of Gauntlet’s plans/intent to deprecate Aave v2 on Ethereum.\n [ARFC] Treasury Manage - GHO Liquidity Committee\nVote Cast: YAE\nWe advocate for the creation and funding of the GHO Liquidity Committee to support the ongoing liquidity needs of GHO across the ecosystem.\n [ARFC] Treasury Management - Amend Safety Module AAVE Emissions\nVote Cast: YAE\nWe advocate for reducing the amount of AAVE being distributed to SM participants. We believe the level of rewards can be reduced without meaningfully impacting deposits whilst also making a considerable cost saving for the DAO.\n [TEMP CHECK] Aave Events & Sponsorship Budget\nVote Cast: YAE\nWe are supportive of providing funding to Aave Companies to represent the DAO at various conferences and events over the next 3 to 6 months.\n [TEMP CHECK] Add FXS to Ethereum V3\nVote Cast: YAE\nWe support adding FXS to Aave v3 on Ethereum as it promotes diversity and FXS has utility within the Frax ecosystem.\n [ARFC] TokenLogic Hohmann Transfer\nVote Cast: ABSTAIN\nWe abstained as TokenLogic benefits if this proposal is approved by governance.\n [ARFC] Transfer Assets From Polygon To Ethereum Treasury\nVote Cast: YAE\nWe support the migration of strategic assets BAL and CRV to Ethereum where they can be deployed wot earn yield and support GHO better. We also are supporting of bolstering Aave’s runway by transferring USDC to Ethereum.\n [ARFC] Further increase GHO Borrow Rate\nVote Cast: YAE\nWe support increasing GHO’s borrow rate to be more reflective of other stable coin borrowing rates.\n [TEMP CHECK] stEUR Onboarding on Aave V3 Ethereum Pool\nVote Cast: YAE\nWe are supportive of stable coin diversity.\n [TEMP CHECK] CRVUSD Onboarding on Aave V3 Ethereum Pool\nVote Cast: YAE\nWe are supportive of stable coin diversity and potential synergies between GHO and crvUSD.\n [ARFC] Aave Events & Sponsorship Budget\nVote Cast: YAE\nWe are supportive of this follow up proposal to the TEMP CHECK submitted earlier.\n [ARFC] Add FXS to Ethereum V3\nVote Cast: YAE\n [ARFC] Gauntlet recommendation for MAI / MIMATIC deprecation\nVote Cast: OPTION 2\nWe favour the more aggressive option presented by Gauntlet as the liquidation values are minimal.\n [ARFC] Upgrade Aave V3 ETH pool wETH parameters\nVote Cast: *OPTION 2\nGiven the current POS derived yield, we are supportive of the lower Slope1 parameter and improving Aave’s overall competitiveness relative to Spark.\n [ARFC] sDAI Onboarding on Aave V3 Gnosis Pool\nVote Cast: YAE\nsDAI is a great collateral that should help drive a minimum level of borrowing demand for most stable coins.\n [ARFC] Treasury Management - Add to rETH Holding\nVote Cast: YAE\nWe favour supporting network diversity and increasing Aave’s exposure to rETH relative to wstETH at this point in time.\n [ARFC] ACI Phase II\nVote Cast: YAE\nThe ACI has delivered a lot of value to the Aave ecosystem and we support there continued efforts to support Aave’s growth over the next 6 months.\n [ARFC] Aave Funding Update\nVote Cast: YAE\nWe are the author of this proposal and are supportive of Aave DAO having around 12 months of runway available at all times.\n [ARFC] Chaos Labs <> Aave Risk Management - Renewal\nVote Cast: YAE\nChaos Labs is the best performing Risk Service Provider in the Aave ecosystem and we are supportive of there continued contributions to the DAO/Protocol.\n [ARFC] Chaos Labs - CRV Aave V3 Polygon - LT Reduction - 10.28.2023\nVote Cast: YAE\nWe are supporting of reducing the CRV LT on Polygon in line with Chaos Labs recommendation.\n [ARFC] GHO - Increase Borrow Rate\nVote Cast: YAE\nWe are supportive of increasing GHO’s borrowing rate until it is similar to other major stable coins on Aave v3 Ethereum.\n [ARFC] wMATIC Interest Rate Update\nVote Cast: YAE\nWe are the author of this proposal and are supportive of reducing the wMATIC Slope1 parameter to encourage users to loop stMATIC / wMATIC to generate yield.\n[ARFC] Aave Swap Upgrade\nVote Cast: ABSTAIN\nTokenLogic benefits if this proposal is approved by governance and therefore we ABSTAIN from the vote.\n[TEMP-CHECK] Create an Aave Financial Management Working Group\nVote Cast: ABSTAIN\nTokenLogic benefits if this proposal is approved by governance and therefore we ABSTAIN from the vote.\n [ARFC] Increase Stablecoin Optimal Borrow Rates\nVote Cast: YAE\nGiven recent borrowing demand pushing utilisation above the Uoptimal point on the IR curve, we are supportive of adjusting the Slope1 parameter to better reflect current demand for stable coin debt.\n [Temp Check] GHO Bounty for Integration Issue Detection\nVote Cast: YAE\nWe support recognising the efforts of those who find way to improve the Aave Protocol. Especially those that contribute to the security of user funds.\n [ARFC] Treasury Management - vlAURA\nVote Cast: YAE\nWe prepared this proposal to use the StrategicAssetManager contract built by Llama as intended.\n [ARFC] TokenLogic - Retrospective Funding Proposal\nVote Cast: ABSTAIN\nTokenLogic benefits if this proposal is approved by governance and therefore we ABSTAIN from the vote.\n [ARFC] Arbitrum USDC Migration\nVote Cast: YAE\nWe are supportive of the broader efforts to move away from bridged USDC to native USDC on each Aave deployment.\n [ARFC] Increase Uopt for Stablecoins on all V3 Deployments and RF on V2 Ethereum\nVote Cast: YAE\nIncreasing the RF on v2 for stable coins will increase revenue to the DAO. Increasing the Uoptimal on v3 will improve the capital efficiency of each affected reserve. We are supportive of both initiative mentioned in this proposal.\n [ARFC] Authorizing Use of Grace Sentinel\nVote Cast: YAE\n [ARFC] CRVUSD Onboarding on Aave V3 Ethereum Pool\nVote Cast: YAE\nWe are supportive of stable coin diversity and look forward to potential synergies with crvUSD beyond the Aave Protocol.\n [ARFC] Treasury Management - auraBAL\nVote Cast: ABSTAIN\nTokenLogic benefits if this proposal is approved by governance and therefore we ABSTAIN from the vote.\n [ARFC] Gauntlet Cap Recommendations for Polygon v3\nVote Cast: YAE\nWe are supportive of the risk parameter adjustments proposed by Guantlet within this proposal.\n [ARFC] Gauntlet recommendation to lower stMATIC, MaticX non-emode LT, pt 2\nVote Cast: NO CHANGE\nWe do not believe the LTV and LT of stMATIC and MaticX should be decreased relative to wMATIC.\n [ARFC] Chaos Labs Risk Parameter Updates - Increase MKR Debt Ceiling on V3 Ethereum - 11.07.2023\nVote Cast: YAE\nGiven the prevailing market conditions, we are supportive of increasing the MKR Debt Ceiling gradually as user demand reflects.\n [TEMP CHECK] Qualify the security incident 04-11-2023 as a shortfall event\nVote Cast: NAY\nWe do not believe that prudent risk management and precautionary measures implemented by the Guardian in this instance qualifies as a shortFall event and use of the SM.\n [ARFC] Onboard Native USDC to Aave V3 Optimism Market\nVote Cast: YAE\nWe are supportive of onboarding native USDC to all Aave markets.\n [TEMP CHECK] Onboarding sfrxETH to Aave V3 Ethereum Market\nVote Cast: YAE\nWe believe the yield from sfrxETH could lead to additional ETH borrowing demand and thus revenue to the DAO. Provided both risk providers are supportive of onboarding sfrxETH, we are also supportive.\n [TEMP CHECK] Onboarding ETHx to Aave V3 Ethereum Market\nVote Cast: YAE\nHaving worked with the Stader Labs team closely on many occasions we are supportive of ETHx. being added to the Ethereum v3 deployment.\n [ARFC] Onboarding wstETH to Aave V3 on Base Network\nVote Cast: YAE\nGiven the TVL derived from wstETH deposits and the resulting ETH borrowing demand, we are supportive for wstETH to be added to all Aave v3 deployments where there is sufficient supporting liquidity.\n [ARFC] Gauntlet Recommendation to re-enable CRV borrowing on v3 Ethereum/Polygon\nVote Cast: YAE\nGiven the prevailing market conditions for CRV, we are supportive of Gauntlet’s recommendation to enable CRV borrowing across Polygon and Ethereum v3 deployments.\n [ARFC] Update the Asset Onboarding Framework\nVote Cast: YAE\nWe are supportive of the iterative improvement on the various Aave governance processes.\n [TEMP CHECK] onboard osETH to Aave v3 on Ethereum pool\nVote Cast: YAE\nSimilar to ETHx, we are supportive of further Aave’s LST diversity. Do note, @MatthewGraham resides on the StakeWise Liquidity Committee for osETH.\n [TEMP CHECK] Add EURC to Avalanche Aave V3\nVote Cast: NAY\n [TEMP CHECK] Financial Services Proposal: karpatkey & TokenLogic\nVote Cast: ABSTAIN\nTokenLogic benefits if this proposal is approved by governance and therefore we ABSTAIN from the vote.\n [ARFC] Upgrade Safety Module with StkGHO\nVote Cast: YAE\nWe are supportive of adding stkGHO to the Aave SM. This utility is expected to stimulate demand and help support the GHO peg in the short term. We are also supportive of diversifying the assets within the SM.\n Freeze price feeds on v3 Harmony following shutdown of Harmony services by Chainlink\nVote Cast: YAE\n [ARFC] Gauntlet <> Aave Renewal 2023\nVote Cast: NAY\nDetails supporting the NAY vote can be found on the ARFC thread.\n [ARFC] New Chain Deployment Framework\nVote Cast: YAE\nWe are supportive of the iterative improvement on the various Aave governance processes.\n [ARFC] Update GNO Risk Parameters on Aave V3 Gnosis Pool\nVote Cast: YAE\n [ARFC] Onboarding ETHx to Aave V3 Ethereum Market\nVote Cast: YAE\nWe are supportive of LST diversification and the continued collaboration with Stader Labs.\nDisclosure: TokenLogic is currently in discussions with Stader Lab’s relative to Treasury Management services.\n [ARFC] Onboarding sfrxETH to Aave V3 Ethereum Market\nVote Cast: YAE\nWe are supportive of LST diversification and expect the addition of sfrxETH to lead to higher ETH borrowing demand due to the elevated yield that sfrxETH offers relative to other LSTs.\n [ARFC] Continuous Security Proposal Aave <> Certora\nVote Cast: NAY\nWe are supportive of Certora’s on going contribution to the Aave DAO and only request AAVE be replaced with another asset. When the AIP is presented, we intend to vote in favour as the composition of the funding is agreed with the ARFC vote being complete.\n [TEMP CHECK] AAVE V3 Harmony Recovery ONE Proposal\nVote Cast: YAE\n[ARFC] TokenLogic & karpatkey Service Provider Partnership\nVote Cast: ABSTAIN\nTokenLogic benefits if this proposal is approved by governance and therefore we ABSTAIN from the vote.\n\n 11 days later\n\n post by TokenLogic on Jan 19, 2024\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n Hi Everyone,\nPlease see below our AIP voting history that continues on from the early post.\n Fix rate strategies issue on Aave v2 Polygon\nVote Cast: YAE\nWe support correcting the errors from AIP 224.\n wMATIC Supply & Borrow Cap Increase Polygon v3\nVote Cast: YAE\nWe support the continued growth of LST adoption on Aave Protocol.\nActivate Emode for rETH Aave Ethereum V3\nVote Cast: YAE\nWe support this proposal and expect it to help drive borrowing demand for ETH.\nAave Stablecoin E-mode changes for V3 Avalanche, Optimism, Polygon, and Arbitrum\nVote Cast: YAE\nWe support refining the stable coin e-mode category parameters as recommended by Gauntlet.\nCaps Plus Risk Steward\nVote Cast: YAE\nIntroducing the Risk Cap Steward role will reduce governance overhead by reducing the need for adjusting Supply Caps via governance.\n DeFi Saver Aave V3 FlashBorrowers Whitelist Part II\nVote Cast: YAE\nDeFi Save is a long term partner of Aave DAO’s and along with other builders, we support removing flashloan fees for there users.\n Polygon Supply Cap Update\nVote Cast: YAE\nWe support the continued expansion of LST Supply Caps to support further deposit and borrowing of native network token growth.\n Add rETH to Arbitrum Aave v3\nVote Cast: YAE\nWe support adding rETH with the recommended risk parameters. The added diversity and potential resulting borrowing demand is great for both Aave DAO and its users.\nAdd LUSD to Arbitrum Aave V3\nVote Cast: YAE\nWe support stable coin diversity and LUSD is the only immutable option.\n Add ENS to Aave V3 Ethereum\nVote Cast: YAE\nWe support adding ENS to enable users migration from v2 to v3.\n Add 1INCH to Aave V3 Ethereum\nVote Cast: YAE\nWe support adding 1INCH to enable users migration from v2 to v3.\n Risk Parameter Updates for AAVE V2 Ethereum\nVote Cast: NAY\nWe believe there are better alternative options to explore that achieve a more optimal result.\n Risk Parameter Updates Aave V3 Ethereum\nVote Cast: YAE\nWe support the risk parameters adjustments as presented by Chaos Labs on the forum.\n Polygon v2 - Parameter Update\nVote Cast: YAE\nTokenLogic is the author of this proposal and it is intended to encourage users to migrate from v2 to v3 on Polygon and does so without putting any user funds at risk.\n Price feeds operational update Pt2 - stETH\nVote Cast: YAE\nWe support this oracle upgrade.\n Add Native USDC To Arbitrum V3 Pool\nVote Cast: YAE\nWe support adding native USDC on all Aave v3 deployments.\n Chaos Labs V2 to V3 Migration Next Steps\nVote Cast: YAE\nWe are supportive of encouraging users to migrate from v2 to v3 and also the methodology as proposed by Chaos Labs.\nFreeze TUSD Reserve on Aave V2 Ethereum\nVote Cast: YAE\nWe support off boarding TUSD and expect the methodology applied to generate meaningful revenue for the DAO.\n Chaos Labs - Payment Collection Request\nVote Cast: YAE\n Chaos Labs Risk Parameter Updates - CRV Aave V2 Ethereum\nVote Cast: YAE\nWe are supportive of reducing Aave’s exposure to CRV on v2 Ethereum and acknowledge the proposed changes have a very minor impact on users.\n Lower TUSD LT and LTV on Aave V2\nVote Cast: YAE\nWe support lowering these two risk parameters for TUSD.\n Treasury Management - Acquire wstETH & rETH\nVote Cast: YAE\nWe are supportive of the Aave DAO holding wstETH and rETH, diversification of LSTs and for these assets to be held outside of there respective reserves and instead held with in the Collector Contract.\n Price feeds operational update Pt2.5 - wstETH\nVote Cast: YAE\n Gas Rebate for Recognized Delegates\nVote Cast: YAE\nWe support reimbursing gas costs of the DAO recognised delegates.\n Chaos Labs Risk Parameter Update - CRV Aave V3 Polygon\nVote Cast: YAE\nWe are supportive of reducing exposure to CRV on Polygon via reducing the LTV and LT thresholds.\n Chaos Labs - Increase wstETH Supply Cap on V3 Arbitrum\nVote Cast: YAE\nWe support increasing wstETH supply cap on Arbitrum in line with Chaos Lab’s DAO support methodology.\n Ethereum v2 - Parameters Update\nVote Cast: YAE\nWe are supportive of increasing the RF parameters on Ethereum v2 to further encourage migration to v3.\n Treasury Management - Acquire B-80BAL-20WETH\nVote Cast: YAE\nWe support swapping the DAOs BAL to B-80BAL-20WETH with the intention of locking it for veBAL.\n GHO Mainnet Launch\nVote Cast: YAE\nWe support launching GHO and look forward to supporting its adoption across DeFi.\n Gauntlet Cap Updates for Ethereum, Optimism Aave v3\nVote Cast: YAE\nWe support the proposed cap changes.\n Add RPL to Aave V3 Ethereum pool\nVote Cast: YAE\nWe are supportive of adding RPL as collateral. We expect there to be some borrowing demand for RPL by prospective node operators.\n Make USDT a collateral for Aave V3 ETH Pool\nVote Cast: YAE\nUSDT is one of the most dominant stable coins and has great liquidity. We support listing USDT as collateral on Aave v3 with sound risk parameter configuration.\n Chaos Labs Risk Parameter Updates - Aave V2 Ethereum\nVote Cast: YAE\nWe support Chaos Lab’s proposed risk parameter adjustments.\n add ARB to Aave V3 Arbitrum Pool\nVote Cast: *YAE\nWe support adding ARB to the Arbitrum v3 deployment.\n Bug Bounty May 2023\nVote Cast: YAE\nWe support rewarding the efforts of bug hunters as outlined in this proposal.\n Add rETH Aave v3 Optimism\nVote Cast: YAE\nWe support LST diversity on all Aave v3 deployments and expect rETH to drive additional demand for ETH debt.\n MaticX Polygon Supply Cap Update\nVote Cast: YAE\nWe support the continued growth of MaticX on Polygon.\n Gauntlet Risk Parameter Updates for Ethereum v3, Arbitrum v3, Ethereum v2\nVote Cast: YAE\n MaticX Polygon Supply Cap Update\nVote Cast: YAE\n Chaos Labs Risk Parameter Update - MAI Aave V3\nVote Cast: YAE\nSet Metis Foundation Wallet as Emission Manager for METIS Token on Aave V3 Metis Pool\nVote Cast: YAE\nWe support enabling the Metis Foundation to distribute METIS on the Aave v3 deployment on the Metis Network.\nAcquire More aUSDC on Aave Ethereum Collector\nVote Cast: YAE\nWe support converting asset to USDC and depositing into Aave v2 in order to pay service providers.\n Chaos Labs Risk Parameter Updates - FEI on Aave V2 Ethereum\nVote Cast: YAE\nWe support continually reducing Aave’s exposure to the FEI stable coin.\nReserve Factor Updates - Polygon Aave v2\nVote Cast: YAE\nWe support the continue deprecation of Polygon v2 by continually increasing the RF parameter.\n TUSD offboarding plan\nVote Cast: YAE\nWe support offboarding TUSD.\n Gauntlet Recommendation for CRV LTV → 0 on Aave v2 Ethereum\nVote Cast: YAE\nWe support setting CRV’s LTV to 0 on Ethereum v2.\n Gauntlet Recommendation to reduce CRV LT, LTV, debt ceiling on V3 Ethereum and CRV LT, LTV on V3 Polygon\nVote Cast: YAE\n aCRV OTC Deal\nVote Cast: YAE\nWe support acquiring CRV via OTC with Michael with the intent of using the CRV to support GHO’s liquidity.\n Reduce CRV LT by 6%\nVote Cast: YAE\nWe support the continued efforts of the risk service providers to reduce Aave’s exposure to CRV on Ethereum v2.\n Disable CRV Borrowing For Ethereum and Polygon V3\nVote Cast: YAE\nWe support the continued efforts of the risk service providers to reduce Aave’s exposure to CRV on Polygon v3.\n BUSD Offboarding Plan Part III\nVote Cast: YAE\nWe support the offboarding of BUSD and expect this process to generate meaningful revenue for the DAO.\n Supply Cap increase - wstETH\nVote Cast: YAE\nWe support the continued growth of LST deposits on Aave v3 deployments.\n LUSD collateral activation\nVote Cast: YAE\nWe support enabling LUSD as collateral on Ethereum v3.\n stataToken operational update\nVote Cast: YAE\nWe support transferring the help contracts used exclusively by Balancer from Aave to Balancer.\n Aave v3 Base Activation\nVote Cast: YAE\nWe support the expansion of Aave v3 to networks that are expected to generate meaningful TVL over time.\n Increase MaticX supply cap\nVote Cast: YAE\nWe support the continued growth of LST deposits on Aave v3 deployments.\n Swap assets to aUSDC\nVote Cast: YAE\nWe support the continued consolidation of assets to support the DAO’s finances.\n Chaos Labs Scope and Compensation Amendment\nVote Cast: YAE\nWe support Chaos Labs expanding there contracted scope to cover all Aave v2 deployments and GHO.\n CRV Aave V2 Ethereum - LT Reduction\nVote Cast: YAE\nWe support continuing to reduce Aave’s exposure to CRV on the Ethereum v2 deployment.\n Treasury Management - Polygon v2 to v3 Migration\nVote Cast: YAE\nWe support the DAO holding its funds in the latest version of Aave Protocol.\n sDAI onboarding\nVote Cast: YAE\nWe expected sDAI to attract a significant amount of deposits.\n GHO unpause and freezing\nVote Cast: YAE\n GHO update on Aave V3 Ethereum Pool\nVote Cast: YAE\nWe support implementing the proposed fix to the GHO integration with the Aave v3 pool.\n Chaos Labs Risk Parameter Updates - Aave V3 Optimism\nVote Cast: YAE\nWe support the proposed risk parameter adjustments as recommended by Chaos Labs.\n Aave BGD Phase 2\nVote Cast: YAE\nWe support the continuation of BGD’s service as the main developer team supporting the protocol.\n Funding Aave Robot for Governance V2 Automation\nVote Cast: YAE\n Chaos Labs Risk Parameter Updates\nVote Cast: YAE\nWe support the proposed risk parameter adjustments as recommended by Chaos Labs.\n Quarterly Gas Rebate Distribution August 2023\nVote Cast: YAE\nWe support reimbursing the gas costs of delegates and developers serving the Aave Protocol.\n Freeze MAI/MIMATIC, set LTV → 0 for Arbitrum, Avalanche, Polygon, Optimism v3\nVote Cast: Y","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263370668,"hash":"362249457887cd22a81b4086d3b50dea462f4a3f"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale-for-erc20-token-not-using-18-decimals/4946/1","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale for ERC20 token not using 18 decimals - Support / Contracts - OpenZeppelin Forum","text":"Rate to use for Crowdsale for ERC20 token not using 18 decimals \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 1 / 5\n\n Dec 2020\n\n Dec 2020\n\n post by TarrahArshad on Dec 4, 2020\n\n TarrahArshad\n\n i search and i seen ur document all in web but problme is stile in 18 decimals all work fine but in decimal lower 4-5 all number go wrong\nwhy do not list base on other decimals 2-4-5-10 provide examples\n\n Rate to use for Crowdsale?\n\n 3\n\n 2\n\n post by abcoathup on Dec 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nWelcome to the community \nTo calculate the rate for ERC20 tokens you can use the formula: TKNbits = rate * wei\nThis applies regardless of what decimals your token uses.\nSee the documentation for details: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nIf you need help calculating your rate, feel free to share your decimals and the amount of Ether per token.\n\n post by abcoathup on Dec 13, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nDid you need any more information?\n\n post by TarrahArshad on Dec 14, 2020\n\n TarrahArshad\n\n hi andrew\nthanks for ur response\nmy issue is rate .\ni have crowdsale on multi stage\nstage detail is ( start-price , end-price , cap , sold)\ni need calc current base on sold and sold is how many tokens solde before so price increase.\ni need know how increase rate and before that i need know formula for calc current rate depend on USD\nfor ex: $0.01-$0.25 its my range min-max price and i have max 500k token how calc current rate base on sold\nand second my problem is i see with example i setn 250 wei and 500 wei crowdsale buytokens send wrong amount if i send 1 eth i receive 250 token only\n250 wei rate must send 250 token if user send 1eth ? its wrong i no override ur crowdsale.sol i keeped ur but i create new function name buy and call ur buytokens original\nthis is my function\nfor buy and sell i use this\nfunction buy(address beneficiary, address upline) public payable {\n require(\n contributions[upline].buy_amount > 0 || upline == _owner,\n \"upline is wrong\"\n );\n\n uint256 weiAmount = msg.value;\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n require(\n CrowdsaleStages[stage].cap >= CrowdsaleStages[stage].sold + tokens,\n \"cap hit\"\n );\n\n total_tokenSold += tokens;\n CrowdsaleStages[stage].sold += tokens;\n\n buyTokens(beneficiary);\n\n updateUser(beneficiary, upline, tokens);\n }\n\n/**\n * @dev with this function client send request for selling\n * @param amount is how much token selling\n */\nfunction sell(uint256 amount) public returns (uint256 ETHAmount) {\n require(amount > 0, \"You need to sell at least some tokens\");\n require(\n contributions[msg.sender].buy_amount - amount >= 0,\n \"balance is not enoght\"\n );\n if (sellBook[msg.sender].sell_time > 0) {\n require(\n sellBook[msg.sender].sell_time + duration_sell <\n uint40(block.timestamp),\n \"in this hours u can't sell again\"\n );\n }\n // 1. calculate eth amount - 5%\n ETHAmount = _getEthAmount(amount);\n\n // 2. transfer token from sender to crowdsale address\n\n /* uint256 allowance = token.allowance(msg.sender, address(this));\n\n require(allowance >= amount, \"Check the token allowance\");\n\n token.transferFrom(msg.sender, address(this), amount);*/\n\n //msg.sender.transfer(amount);\n\n // 3. transfer fund\n msg.sender.transfer(ETHAmount);\n\n // 4. update stage\n contributions[msg.sender].buy_amount -= amount;\n\n sellBook[msg.sender].id = SellID++;\n sellBook[msg.sender].sell_amount = amount;\n sellBook[msg.sender].sell_time = uint40(block.timestamp);\n\n // emit event\n emit Sold(msg.sender, amount);\n\n return ETHAmount;\n}\n /**\n * The base rate function is overridden to revert, since this crowdsale doesn't use it, and\n * all calls to it are a mistake.\n */\nfunction rate() public view returns (uint256) {\n return CrowdsaleStages[stage].initialRate;\n}\n\n/**\n * @dev Overrides parent method taking into account variable rate.\n * @param weiAmount The value in wei to be converted into tokens\n * @return The number of tokens _weiAmount wei will buy at present time\n */\nfunction _getEthAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 currentRate = getCurrentRate();\n return weiAmount.div(currentRate).mul(uint256(95).div(uint256(100)));\n}\n\n post by abcoathup on Dec 14, 2020\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to calculate rate for a crowdsale?\n\n Contracts\n\n 3\n\n 4.2k\n\n Sep 2021\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Whats a good way to implement multiple rates into crowdsale?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 792\n\n Mar 2022","tokens":1227,"squid":"ink-security_audits","role":"Sentinel","at":1791263375912,"hash":"f3d596cf8697e8ce3c118b2543ac62c1deb11795"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale-for-erc20-token-not-using-18-decimals/4946/2","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale for ERC20 token not using 18 decimals - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 2 / 5\n\n Dec 2020\n\n Dec 2020\n\n post by TarrahArshad on Dec 4, 2020\n\n TarrahArshad\n\n i search and i seen ur document all in web but problme is stile in 18 decimals all work fine but in decimal lower 4-5 all number go wrong\nwhy do not list base on other decimals 2-4-5-10 provide examples\n\n Rate to use for Crowdsale?\n\n 3\n\n 2\n\n post by abcoathup on Dec 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nWelcome to the community \nTo calculate the rate for ERC20 tokens you can use the formula: TKNbits = rate * wei\nThis applies regardless of what decimals your token uses.\nSee the documentation for details: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nIf you need help calculating your rate, feel free to share your decimals and the amount of Ether per token.\n\n post by abcoathup on Dec 13, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nDid you need any more information?\n\n post by TarrahArshad on Dec 14, 2020\n\n TarrahArshad\n\n hi andrew\nthanks for ur response\nmy issue is rate .\ni have crowdsale on multi stage\nstage detail is ( start-price , end-price , cap , sold)\ni need calc current base on sold and sold is how many tokens solde before so price increase.\ni need know how increase rate and before that i need know formula for calc current rate depend on USD\nfor ex: $0.01-$0.25 its my range min-max price and i have max 500k token how calc current rate base on sold\nand second my problem is i see with example i setn 250 wei and 500 wei crowdsale buytokens send wrong amount if i send 1 eth i receive 250 token only\n250 wei rate must send 250 token if user send 1eth ? its wrong i no override ur crowdsale.sol i keeped ur but i create new function name buy and call ur buytokens original\nthis is my function\nfor buy and sell i use this\nfunction buy(address beneficiary, address upline) public payable {\n require(\n contributions[upline].buy_amount > 0 || upline == _owner,\n \"upline is wrong\"\n );\n\n uint256 weiAmount = msg.value;\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n require(\n CrowdsaleStages[stage].cap >= CrowdsaleStages[stage].sold + tokens,\n \"cap hit\"\n );\n\n total_tokenSold += tokens;\n CrowdsaleStages[stage].sold += tokens;\n\n buyTokens(beneficiary);\n\n updateUser(beneficiary, upline, tokens);\n }\n\n/**\n * @dev with this function client send request for selling\n * @param amount is how much token selling\n */\nfunction sell(uint256 amount) public returns (uint256 ETHAmount) {\n require(amount > 0, \"You need to sell at least some tokens\");\n require(\n contributions[msg.sender].buy_amount - amount >= 0,\n \"balance is not enoght\"\n );\n if (sellBook[msg.sender].sell_time > 0) {\n require(\n sellBook[msg.sender].sell_time + duration_sell <\n uint40(block.timestamp),\n \"in this hours u can't sell again\"\n );\n }\n // 1. calculate eth amount - 5%\n ETHAmount = _getEthAmount(amount);\n\n // 2. transfer token from sender to crowdsale address\n\n /* uint256 allowance = token.allowance(msg.sender, address(this));\n\n require(allowance >= amount, \"Check the token allowance\");\n\n token.transferFrom(msg.sender, address(this), amount);*/\n\n //msg.sender.transfer(amount);\n\n // 3. transfer fund\n msg.sender.transfer(ETHAmount);\n\n // 4. update stage\n contributions[msg.sender].buy_amount -= amount;\n\n sellBook[msg.sender].id = SellID++;\n sellBook[msg.sender].sell_amount = amount;\n sellBook[msg.sender].sell_time = uint40(block.timestamp);\n\n // emit event\n emit Sold(msg.sender, amount);\n\n return ETHAmount;\n}\n /**\n * The base rate function is overridden to revert, since this crowdsale doesn't use it, and\n * all calls to it are a mistake.\n */\nfunction rate() public view returns (uint256) {\n return CrowdsaleStages[stage].initialRate;\n}\n\n/**\n * @dev Overrides parent method taking into account variable rate.\n * @param weiAmount The value in wei to be converted into tokens\n * @return The number of tokens _weiAmount wei will buy at present time\n */\nfunction _getEthAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 currentRate = getCurrentRate();\n return weiAmount.div(currentRate).mul(uint256(95).div(uint256(100)));\n}\n\n post by abcoathup on Dec 14, 2020\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to calculate rate for a crowdsale?\n\n Contracts\n\n 3\n\n 4.2k\n\n Sep 2021\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Whats a good way to implement multiple rates into crowdsale?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 792\n\n Mar 2022","tokens":1210,"squid":"ink-security_audits","role":"Sentinel","at":1791263386062,"hash":"a89bf12b2ee6adbdfb32a29e7f50dadfd1ae3b9e"}
{"url":"https://ethresear.ch/t/eip-8411-what-segmented-payload-diffusion-is-made-of/26025","domain":"ethresear.ch","title":"EIP-8411: what segmented payload diffusion is made of - Networking - Ethereum Research","text":"EIP-8411: what segmented payload diffusion is made of \n\n Networking\n\n p2p,scaling\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 16\n\n 1 / 1\n\n Sep 17\n\n 19d ago\n\n post by cskiraly on Sep 16\n\n cskiraly\n\n This post continues Wen fast payload broadcast?, taking its recommended segmented diffusion policy apart, describing each protocol change and measuring its effect.\nTL;DR\n\nPayload propagation is fast enough today largely because of small blocks, and because datacenter builders and high-bandwidth nodes carry it.\nEIP-8411 proposes faster execution payload propagation via message segmentation, letting pieces pipeline through the network instead of store-and-forward at every hop.\nA Merkle tree commitment in the bid is the only consensus change needed; every segment is verified against it before it is forwarded.\nWith segmentation and batch publishing, median delivery falls below a second in our baseline home-builder simulation even without datacenter nodes, from 5 s for the whole payload.\nA prototype is presented, providing three protocol implementation “tiers”, each a prefix of the next, with increasing complexity and performance:\n\ntier 1: segmentation with batch publishing. The bare minimum: it cuts the 1 MiB median from 5 s to under a second and the tail from 6 s to just over 1 s, for a third more bytes than today.\ntier 2: announce instead of pushing to everyone, with a push width that follows the payload size, and disciplined pulls. Local library policy only; less than half of tier 1’s bytes, and inside the 3 s budget through 2 MiB.\ntier 3: tier 2 over a rate-½ erasure code of the compressed payload, with stop-pull. It is the fastest, has the lowest tail at every size, and shrugs off withholding; parity doubles what leaves the source, and the code’s commitment joins the bid.\n\n0. Where the first post left off\nWhole-payload gossip is fast enough on today’s mainnet mostly because datacenter builders and high-bandwidth nodes carry it. Our previous post showed that cutting the payload into smaller pieces removes that dependence. In this post we dive into the technical details of making segmentation even faster, while eliminating most of the duplicate traffic today’s gossipsub suffers from.\n1. Segment first\nFigure 11330×672 67.3 KB\nFigure 1. Whole message as today (leftmost group) and the six segmented protocol variants in the first post’s three scenarios: home builder with no high-bandwidth nodes, home builder with 20% of nodes in datacenters, datacenter builder with 20% of nodes in datacenters. Bars: receiver p99 (±1 s.d. across seeds); ticks: receiver p50; dashed line: the 3 s budget.\nFigure 1 compares the latency of whole-message gossipsub with six segmented protocol variants, under three networking scenarios. Variants represent three ways of mapping segments to gossipsub:\n\nvariant A uses a single topic as today, but with segmented messages;\nB maps segments to the partial messages extension;\nC follows the DAS design, mapping each segment to a separate topic.\n\nEach of these can accommodate erasure coding, and the figure shows the performance of these combinations too. For B the code pays only when each part travels in its own frame; bundled per peer, as the extension sends by default, coded B is slower than B alone in every scenario (measured but not shown here).\nEvery segmented protocol variant beats whole-message gossip by a large margin. At the baseline, whole message reaches half the nodes in 5 s and the last of them in 6; A-tuned takes 0.75 s and 1 s, while each node receives 1.5 copies of the payload instead of 4.6. Our first post recommends variant A: it is simpler to introduce than B and C, yet it provides most if not all of the possible performance gains. However, the variant A-tuned we show here is not just segmentation alone. It also includes other networking techniques (some of which we already introduced in previous posts). In what follows we detail these techniques and their effects one by one.\n\nHow to read the numbers. Every number comes from a simulation harness that runs the real Prysm and go-libp2p-pubsub code over a simulated network on a virtual clock. The code implements the discussed changes, Merkle commitment, per-piece proofs, structured message IDs, and Reed-Solomon erasure coding included; the one thing the simulation stands in for is the bid: with no blocks in the simulated slot, a node admits the first segment group it sees as that slot’s commitment. The gossipsub wire format, mesh construction, degree and scoring are unchanged; the forwarding and request policies are options in a fork of the library.\nThe baseline scenario is 500 nodes (for faster simulations), a degree-70 neighbourhood as in Prysm, simulated geographic latency, 50 Mbps up and 100 Mbps down per node, and a 1 MiB payload from a home builder, with no high-bandwidth nodes assumed. A seed draws the network — who connects to whom, which links are slow — so configurations compared at the same seed see the same network; every measurement uses ten seeds.\nA point on a figure is the median across seeds of one per-node statistic, with ±1 standard deviation bars. Receiver p50 is the time by which half the nodes hold the payload: the decisive node for the PTC’s head count on the happy path, without adversaries or byzantine faults. Receiver p99 is the tail, relevant to safety margins and to uses where most nodes must receive. Complete by 3 s is the share of receivers inside the slot’s 3 s PTC budget. Bytes are everything a node received for the payload, data and control together, expressed in copies of the payload as it would travel compressed as one message, 746 KB at 1 MiB, so that a segmentation’s compression loss and a code’s incompressible parity both count; the figures that plot the two separately say so.\n\n2. What variant A is made of\nFigure 21820×1036 218 KB\nFigure 2. Successive changes stacked on stock gossipsub, at various payload sizes. Top left: p50 latency; bottom left: p99. Top right: all bytes received per node, data and control, as a multiple of the payload’s compressed size; bottom right: the control bytes alone.\n2.1 The ladder\nVariant A is not one change but a short ladder of incremental changes, and Figure 2 climbs it at various payload sizes. Each rung does one thing. The bulk of the delay advantage comes from segmentation alone, and that is the main message of this post: the commitment and the segmentation, by themselves, put us far ahead of where we are today. The other rungs mostly remove duplicates — useful, but second to the timing gain — and add smaller latency improvements of their own.\nWhole message: the reference\nStock gossipsub v1.2 carries the payload as one large message. A receiver first tells its mesh peers that it has it (IDONTWANT), then validates it, then forwards it to every mesh peer that has not said IDONTWANT in the meantime. At the next heartbeat it announces the id to a sample of its other peers, and a node that lacks an announced id asks every peer that announced it.\nTwo things follow from sending the whole payload as a single message. Nothing can be forwarded before the whole payload has arrived and been checked, so each hop adds a large delay (the so-called store-and-forward delay). And a mesh of eight sends eight copies in parallel, sharing the uplink bottleneck and slowing down each send to an eighth of the link’s speed. Even worse, if a heartbeat happens in the meantime, announcements can bring several more IWANT requests and thus parallel copies in through the pull path. This is the performance baseline we measure everything else against.\nSegmentation\nSegmentation aims to eliminate the store-and-forward delay. The builder cuts the payload into fixed-size pieces, commits to them with a Merkle root in its bid, and publishes each piece with its proof as an ordinary gossip message. It needs structured message ids similar to FullDAS: an id that carries the group’s Merkle root and the piece’s index, followed by the usual content hash, 56 bytes against gossipsub’s 20 (Part 1’s layout without the slot and block root, which the commitment makes redundant). The root and the index are there for two reasons:\n\na receiver can check the segment against the commitment it got with the block, and relay it,\nan IHAVE announcement carries enough structure in the id to be matched to the bid before a request is granted.\n\nA piece that arrives before its bid waits in a bounded cache and is not relayed until the bid installs.\nThis is pipelining, and it is most of the latency gain in the whole post. A node starts relaying after one piece-time instead of one payload-time, and its uplink serves different pieces to different peers at the same time. The price is bytes and control traffic: a full-mesh push of 32 pieces delivers more duplicate copies than one push of the whole, and 32 ids mean 32 times the announcements. Some later rungs buy that price back (and some more).\nBatch publishing\nOnce the payload is segmented, the first bottleneck is the source’s own uplink. Publishing the pieces one after another, as the API does today, sends every copy of piece 1 — one to each of the eight mesh peers — before the first copy of piece 2, so the last piece leaves the source only after nearly the whole payload has gone out eight times. The pipeline that segmentation created is starved at its first hop.\nBatch publishing interleaves: the publisher sends the first copy of every piece, each to a different mesh peer, before the second copy of any. We proposed it for segmented diffusion in DAS; it equally applies here, and it is already upstream in go-libp2p-pubsub.\nThe whole payload leaves the source once within one payload-time, and every piece begins its diffusion from a different neighbour. Bytes are unchanged and nothing is given up; it needs no protocol change, only an API that publishes several messages at once.\nAnnounce instead of push\nSegmentation’s price is duplicates. Full-mesh push sends every piece to every mesh peer that has not yet said it has it, and with 32 pieces racing through the mesh, most of those copies reach nodes that already hold the piece or are about to: Figure 2’s byte panel shows six copies of the payload arriving at every node. Gossipsub already has the machinery to offer a message instead of sending it — IHAVE and IWANT — but only uses it at the heartbeat, for peers outside the mesh.\nAccording to the push-pull idea of PPPT, a node that receives a message (a segment here) pushes it whole to at most r of its mesh peers — chosen among those it does not already know to hold it — and immediately announces the id to the rest, who ask for it if they still need it. The same trade (fewer eager copies, the rest pulled or suppressed) runs through the Vac/nim-libp2p work on staggering and fragmentation and PREAMBLE and IMRECEIVING, and through Raul’s ethp2p. We use r = 2 in this rung.\nThe result is fewer duplicates: a third of the bytes off the full-mesh push, and no slower — the uplink stops queueing copies that would have been refused, which pays for the round trip that a pulled piece now costs. Both ways of losing a piece stay covered: a lost request by the push, a lost push by the announce-and-ask path. The cost is on the pull side: every pulled piece takes a round trip, and there are now many more announcements to answer, which is what we will discuss in Section 2.2.\nThe phase shift\nA fixed push width is blind to how far a piece has spread. Early in a piece’s life a push is almost certainly useful; late, when most of the mesh already holds it, a push is almost certainly a duplicate. A node has a free local signal of which case it is in: the IDONTWANTs it has heard for that piece.\nEach IDONTWANT indicates that the piece is in an already diffused state, and a push would result in a duplicate with higher probability. So every IDONTWANT lowers the node’s remaining push budget for that piece, and a node that receives the piece late only announces it — the IDONTWANT-count rule from the PPPT discussion.\nThe result is another ~20% of the bytes off: the copies late forwarders would have pushed into a mesh that mostly holds the piece already. When the uplinks are idle — below about 640 KiB in our scenario — this trades some latency for fewer duplicates; above that it has only upside, the same time for fewer bytes.\n2.2 Disciplined pulls\nThe rungs above change what a node pushes. Disciplined pulls change what it asks for.\nStock gossipsub’s pull is based on IHAVEs emitted to non-mesh peers at heartbeats, and IWANTs requesting missing messages (segments in our case). Some implementations, including the go-libp2p one, simply send IWANTs to every announcer, whether or not they were already asking someone else for the same segment, generating duplicates. In stock gossipsub, where IHAVEs are limited to heartbeat gossip, the effect is limited. But once we start using announce instead of push to reduce duplicates, the number of IHAVEs grows, and the duplicates we eliminated by not pushing return through the back door. Hence we need to control pulls better.\nThe solution looks simple on the surface: ask only the first announcer. This, however, has two fundamental issues. First, in networking nothing works without a timeout. Something must happen when the first IWANT is not answered. We should move on to another announcer sending a new IWANT (the first could still deliver after the timeout; that is fine). Second, an IWANT with a timeout means we are waiting on one node, which is an ideal surface for a capture attack. It is easy to see why the naive “ask everyone” policy is free from these issues, but if we want to remove duplicates, we need a better mechanism, and we call this disciplined pulls:\n\nkeep track of peers offering an id in our offer table\nsend at most k (1 by default) requests per id at first;\nafter a timeout (200 ms), move on, sending a new request instead of the expired one;\nour timed-out request might still be answered late, and we handle this with a second, larger timeout (400 ms): if the node still delivers, we take it; if not, we treat it as a broken promise and park that peer for 30 s.\n\nThe two timeouts allow fast recovery from a potential loss, while bounding a given peer’s capability to capture. We use fixed timeouts in this post, but these can also easily be tuned per peer.\nFigure 31820×1036 140 KB\nFigure 3. Disciplined pulls against payload size, 500 nodes: the phase shift rung of Figure 2, then A-tuned. Panels as in Figure 2.\nFigure 3 shows that disciplined pull roughly halves byte utilization at every size, reaching 1.5 payload copies per node at 1 MiB, control traffic included. It slightly slows down diffusion of smaller payloads, where the request round trip dominates and an unasked second copy would have arrived. It roughly ties from 512 to 896 KiB and leads above, where bandwidth becomes a bottleneck, reducing both latency statistics by a quarter at 2 MiB.\nAt the clean 1 MiB base the 200 ms discipline alone takes received bytes from 3.3 payload copies to 1.5 at an unchanged p99, and the offer table, move-on and park then change neither statistic. They are insurance: they cost nothing when nothing goes wrong.\nWe call the resulting policy, combining all the techniques above, A-tuned. By limiting pulls, we are still allowing peers to hold up a receiver: each id now waits on one selected announcer and remembers the alternatives. Section 3 measures what that dependence costs on thin links and what it exposes under withholding.\n3. Where the changes might bite\nSo far the networks have been clean and undisturbed, with only payload size and datacenter placement varied. Now we add stress: thin links, where duplicates cost time, and withholding, where requests become capture. Figure 4 has both, with A-tuned as the top rung.\nFigure 41750×672 122 KB\nFigure 4. The ladder under stress, 500 nodes, 1 MiB (±1 s.d. across seeds): whole message, then the rungs of Figure 2 up to A-tuned. Left: receiver p50 against residual uplink, 10–200 Mbps, downlink 2×; dashed line: the 3 s budget. Right: receiver p99 against the share of nodes withholding, 0–70%. A number beside a point counts the honest receivers still incomplete when the run ends (“strands”). Withholders forward and announce like every other node but never answer a request.\n3.1 Thin links\nWhen the uplink is narrow, bytes are time, and duplicate reduction pays off. Every rung that saves bytes is faster on a thin link. At 15 Mbps whole message would take 28 s on the median, segmentation alone 12, batch publishing 4.3, announcing 3.4, the phase shift 3.2 and A-tuned 2.6.\nAbove 100 Mbps IWANT discipline (and its baseline announce instead of push) has some latency cost. It is the request round trip that every pulled piece costs, which no amount of bandwidth removes. One might argue it is still a worthwhile compromise, leaving more space on the wire for other traffic.\n3.2 Adversaries\nThe withholder of Figure 4 forwards and announces like every other node and never answers a request. This is the cheap attack on a pull path. Refusing costs the attacker nothing, and because its pushes into the mesh stay honest, gossipsub’s peer scoring never sees it; the one stock defence, the penalty for an unanswered request, fires 3 s later, after the slot budget is gone. An overloaded honest peer whose outbound queue drops responses looks the same. Doses above 30% are there for the shape, not as a threat model.\nThe discipline trades withholding exposure for bytes.\n\nThe push-heavy rungs are flat across every dose because they never use the attacked channel: segmentation alone and batch publishing barely request.\nThe announcing rungs ask every announcer and pay only little: the phase shift’s p99 goes from 1.05 s clean to 2.1 s at 70%.\nA-tuned asks one announcer and waits, so it starts best at 0.99 s but climbs steadily with withholder count. However, latency is still under control, well below our baseline, and it can further be reduced with parameter tuning (two requests allowed in parallel, or a lower move-on timeout).\n\nSurprisingly, withholding even shortens whole message’s tail, from 5.9 to 4.2 s across the sweep. The refused requests were for duplicate whole-payload copies, and those copies were clogging uplinks. The gain comes from less traffic, not from fewer peers.\nWe also tried two harsher withholding models:\n\nrelays that also forward nothing they receive,\nwithholders that also claim, through IDONTWANT, to already hold every id they hear, pushing more of the traffic onto the pull path.\n\nAt 30% withholding A-tuned survives these too.\n4. Treating the tail of the distribution: erasure coding\nAmong N peers that need to receive, there will always be a slowest. Among K segments that are diffused, there will always be one arriving last. In this section we discuss techniques to cut the tail of the delivery latency distribution.\nSince segments diffuse independently — although racing each other — in the network, the slowest will matter. With a largely heterogeneous network, one segment can get unlucky (or attacked), hindering the completion time for every node. There are a few known techniques to fight this:\n\nbalancing the diffusion of segments, one example being BitTorrent’s famous rarest-first strategy;\ntriggering extra recovery efforts towards the end of the diffusion (the tail hedge);\nusing coding (e.g. Reed-Solomon erasure coding, random linear network coding) to change the game.\n\nIn what follows we focus on erasure coding, noting that variants of balancing and tail hedging can be used together with it and are implemented in our prototype too. Measured but not shown here, asking three announcers at once for the last four pieces trims A-tuned’s median by ~10% and leaves fewer receivers stranded under withholding, but it cannot replace a piece the source never sent.\nWhat makes erasure coding stand out is its robustness. While the other techniques have to focus on ensuring no late or withheld segment, erasure coding can focus on the first K, and let N-K slip, effectively cutting the tail of the distribution. Even better, since any sufficient subset rebuilds the payload, each single node can focus on its own fastest K. Precedents include FullDAS, RLNC block propagation, and ethp2p.\n4.1 Erasure coding and the vector commitment\nImportantly, the builder has to commit to all N erasure-coded segments and the bid should contain this; otherwise, spamming would be possible. Whether code consistency needs a per-segment proof also needs clarification. In sampled diffusion (DAS), we need samplers to be able to verify that a single sample is consistent with the code (a parity segment is really an extension of the data); otherwise, the sampling guarantee breaks. Even there, any node that can get at least K segments can verify the encoding and attribute blame to the builder, but most nodes don’t have such high custody. Here all nodes need K segments, so any node can verify the honesty of the builder, and refuse anything inconsistent, leading to economic loss for the builder itself, so segment-level code consistency proofs are not needed.\n4.2 Erasure coding and the ladder\nOur Erasure coding variant builds on A-tuned, and to simplify our discussion here we only illustrate the K->2K case using a rate-½ Reed–Solomon code.\nIt also implements Stop-pull as a local request policy: once a node holds K segments, decline further announcements for that payload, though pushes already in flight still land. Near completion it requests every segment it lacks, so its last segment is whichever arrives K-th. These alternative requests are not duplicates: every segment that arrives counts. They also tolerate segments the source never sent.\nCompress first. Gossipsub compresses every message it carries. Payload data is compressible, while erasure coding parity is high entropy, so it is not. Thus, if we segment first and gossipsub compresses segment-by-segment after, segment sizes can become largely imbalanced. Compress the payload first and code the compressed bytes, and every segment has the same wire size, none of them compressible further. The commitment then covers the erasure coding extension of the compressed bytes, and decompression is deterministic. A canonical encoding might still be beneficial to tighten the rules, but we leave this discussion for later.\nFigure 5 shows both orders; the coded A of the other figures cuts first.\nFigure 51820×1036 192 KB\nFigure 5. The code against payload size, 500 nodes: the phase shift rung, A-tuned, and coded A with stop-pull, which ends requests once K segments arrive. The code has K data and K parity segments: 32+32 at 1 MiB with 32 KiB pieces; counts follow payload size. Dashed: the code over the payload compressed first. Panels as in Figure 2.\nWhat the code buys, and what it costs. The code sits at or under A-tuned on both statistics at every size. The gain reaches p50, not only p99, because completion is every node’s last segment, and the code makes that the K-th of 2K rather than the last of K: every node’s wait shortens, and the nodes that waited longest for a particular segment gain most. The code does not replace the disciplined pulls; it builds on them: without them the extra segments become extra copies at every node and the code is slower than A-tuned (measured but not shown here). The price is bytes. Receivers take about 50% more than A-tuned, and the publisher sends more than twice as much, since parity doubles what leaves the source. As the payload grows the receivers’ share of that overhead shrinks while the publisher’s grows. Compressing first cuts both, and is the fastest line in Figure 5.\nFigure 61750×672 145 KB\nFigure 6. Figure 4 with the code added: the ladder under stress, 500 nodes, 1 MiB (±1 s.d. across seeds), whole message, the rungs up to A-tuned, and coded A cut first and, dashed, compress first. Left: receiver p50 against residual uplink, 10–200 Mbps, downlink 2×. Right: receiver p99 against the share of nodes withholding, 0–70%. Grey dashed line: the 3 s budget; worst-seed strand counts and hollow markers as in Figure 4. Withholders forward and announce like every other node but never answer a request.\nThe code buys back what the discipline gave up. Section 3 showed the trade: disciplined pulls cut A-tuned’s bytes to well under half of the announcing rungs’, and in exchange its tail climbs with the withholder count and its median stops improving above 100 Mbps, because one request per id waits for one peer. The undisciplined rungs never had either problem; they pay for that with three to four copies of the payload at every node. Figure 6 puts the code beside them. Under withholding it takes A-tuned’s tail back to where the announcing rungs sit, at every dose and stranding nobody, and with four of the 32 original segments never sent it still completes everyone at the clean p99. On fat links it recovers their speed too, finishing with whichever K segments arrive first instead of waiting for particular ones. It does this at 2.1 copies per node, between A-tuned’s 1.4 and the announcing rungs’ 3 to 4. On thin links the bytes win: at 30 Mbps and below the cut-first code is slower than A-tuned, while compressing first, which puts fewer bytes on the wire, stays ahead of it down to 10 Mbps. The code is insurance for the tail, paid for in bandwidth, and it pays off where bandwidth is not the constraint.\n5. The segment size\nFigure 71680×1064 134 KB\nFigure 7. Segment size at the headline base: 500 nodes, 1 MiB. Panels show receiver p50 and p99 (±1 s.d. across seeds), encoded data received per node in compressed-payload copies, and control bytes received per node. Lines: A-tuned and coded A at 8, 16, 32 and 64 KiB; dashed: compression before coding. Coding’s segment count follows the segment size.\nOur choice of 32 KiB for the reference 1 MiB payload scenario was arbitrary. The A family reaches its floor at 16 KiB. Moving from 32 to 16 KiB cuts both latency statistics by about a tenth, for A-tuned and coded A alike, with slightly fewer data bytes and double the control bytes. Going to 8 KiB adds no speed and doubles control bytes again; 64 KiB segments cost 15–40% over 32 KiB. The ordering holds beyond the base: for A-tuned, 16 KiB beats 32 KiB on both statistics at every payload size, on thin links down to 10 Mbps and under every withholding dose (measured but not shown here). So a 16 KiB segment for A is better than 32 KiB, with some caveats:\n\nit means more signaling load, and more segment verifications (although cheap with Merkle proofs);\nit also means more context switching and thus processing load.\n\nFixed segment size behaves better than fixed segment count. Figure 2 climbs the ladder keeping segment size fixed at 32 KiB, so the count follows the payload: four segments at 128 KiB, sixty-four at 2 MiB. Fixing the segment count at 32 instead makes the segment follow the payload, from 4 KiB at 128 KiB to 64 KiB at 2 MiB. Results from our simulations (not shown here) show that fixing the segment size is a better choice.\n6. The skeptic’s questions\n“Easy win for 500 nodes, but mainnet has more than 10000. How about that?” We were exploring the design space with 500 nodes simply to make the state space exploration with 10 seeds feasible. If p2p networks do one thing very well, that’s scale. Figure 8 shows four rungs of the ladder from 250 to 4000 nodes. The ordering is the same at every size, and scaling is as the hop count predicts: each doubling of the network adds about the same delay. A doubling adds about 0.4 s to whole message’s median, 0.04 s to the phase shift’s and A-tuned’s, and 0.02 s to coded A’s. Segmentation keeps the logarithmic scaling rule, while shrinking the per-hop delay that sets the increment: a hop forwards a segment instead of the whole payload, and the code finishes on whichever segments arrive first, so the slower paths never set its time.\nFigure 81400×546 52.5 KB\nFigure 8. Network size at 1 MiB, 250 to 4000 nodes: whole message, the phase shift, A-tuned and coded A, receiver p50 and p99 (±1 s.d. across seeds). Hollow markers: the median seed misses the 3 s budget; the numbers give whole message’s share complete by 3 s.\n“Why libp2p and gossipsub, when ethp2p, waggle and other protocols are being designed?” There is a confusion between the algorithmic side of a protocol, the composition of the stack, and the API. This post is about the algorithmic side, and it is mapped onto libp2p and gossipsub to show that even there it is possible. Whether the API changes and whether the stack is composed differently are almost orthogonal questions. Almost, because an API change can open possibilities and move responsibilities, and lead to a conceptually cleaner design; and almost, because a stack that embraces QUIC to its full potential opens possibilities this post does not rely on.\n“You count bytes but not messages. Doesn’t that flatter the small pieces?” The harness normally charges no CPU, so 16 KiB pieces and 64 coded segments look free apart from their control bytes. Charging 300 µs per received data message, paired against the uncharged twin at ten seeds, moves A-tuned’s median by 7 ms at 1 MiB and its p99 by 12 to 26 ms; A at 16 KiB moves by about 1 ms on the median, and coded A not measurably. The ordering of A’s rungs is unchanged. Control-message processing remains uncharged.\n7. Closing and Recommendations\nSegmentation removes the whole-payload store-and-forward latency at every hop and gets a 1 MiB payload comfortably inside the 3 s budget without relying on datacenter uplinks. Whichever variant is chosen, segmentation\n\nhelps decentralization;\nenables shorter slot times; and/or\nprovides more headroom for post-quantum signatures and objects.\n\nThe technologies discussed here also provide an ideal baseline for other large message use cases (larger consensus blocks, ZK proofs, etc.).\nFigure 9 highlights three of the many variants we discussed: potential stopping points that we recommend based on this study and implementation considerations.\nFigure 91820×1036 250 KB\nFigure 9. Where the ladder ends, 500 nodes, ten seeds per point. Solid: today’s whole message and the three tiers, all on 16 KiB segments: segmentation with batch publishing, size-adaptive A, and size-adaptive A over the compress-first RS erasure code. Dashed: the two references each tier is priced against, A-tuned at 16 KiB and the compress-first RS code alone at 32 KiB. Panels as in Figure 2.\nTier 1, the bare minimum: the commitment in the bid, segmentation, and batch publishing. The first two are the spec change of section 2: the piece format, the Merkle root in the bid, structured ids and the relay rule. Batch publishing comes along in our recommendation simply because it is a local publisher policy with no protocol change, and it is already upstream in most libp2p implementations and used for DAS.\nWith 16 KiB segments this tier cuts the 1 MiB median from 5 s to under a second and the tail from 6 s to just over 1 s, and its tail stays flat under withholding because it barely requests. It buys that time with bytes: a node receives a third more than today, and control traffic grows from a few kilobytes per payload to over a hundred at 1 MiB, since it scales with the number of ids. On thin links it is the slowest of the segmented arms and still several times faster than today. It stays inside the budget up to 2 MiB, but with little room, a tail at 2.2 s, and control traffic past half a megabyte per node. Figure 6 measured this rung under stress with 32 KiB segments; Figure 9 draws it at 16 KiB.\nTier 2, the next stopping point: A-tuned at 16 KiB, with a push width that follows the payload size. It adds the request policy of section 2: announcing instead of pushing to everyone, the phase shift, and disciplined pulls. All of it is local to the gossipsub library; nothing changes on the wire or in the spec beyond tier 1. The one knob that follows the payload size is how many mesh peers a node pushes each segment to: more for small payloads, where uplinks are idle and a pull’s round trip is what costs time; two above 1 MiB, where duplicates fill the links.\nThis tier is about bytes. For small payloads tier 1 is slightly faster, but this tier receives less than half the bytes. For large payloads it is also the faster one: tier 1’s duplicates and announcements grow with the payload and push its latency toward the budget, while this tier stays near A-tuned’s byte floor and well inside the budget through 2 MiB. Disciplined pulls are what a withholder can lean on; under 30% withholding it still completes everyone and keeps its lead over A-tuned (measured but not shown here).\nTier 3, the full stack: tier 2 over the compress-first erasure code. The payload is compressed, coded at rate ½ and cut into 16 KiB segments. The push and pull rules are tier 2’s, plus stop-pull: a node stops asking once it holds enough segments to rebuild. This is a spec change again, the code and its commitment in the bid; stop-pull is local policy.\nThis tier is about the tail. A node finishes on whichever segments arrive first, so no single slow or withheld segment holds anyone up. It is the fastest of the three at every size, it has the lowest tail, and it is the one that shrugs off withholding: everyone completes and the tail moves least of anything we measured (measured but not shown here). The price is bandwidth: parity doubles what leaves the source, receivers take more than in tier 2, and with twice as many segment ids its control traffic runs level with tier 2’s, and both sit above tier 1’s up to 1 MiB.\nNothing here touches gossipsub’s wire format, mesh construction, degree or scoring. Every number comes from one harness on one branch. Published with this post is a prototype implementation. Note that the goal of this early prototype is design space exploration and reproducibility, not code quality of robustness. The code this post recommends is the variant-a series: 26 commits on Prysm’s develop, one change per commit behind --enable-segmented-payload-gossip, cutting at 16 KiB, over a go-libp2p-pubsub branch that adds phase forwarding, the request discipline, the park, the offer table and the request gate to v0.17.0. Every figure comes from a different branch: the research tree at tag followup-part1, with the fork it measured pinned, and the harness, the runner, the cell lists behind each figure and the extractor and figure scripts under testing/segstudy/; the raw logs of every cell are attached to the tag. That branch is a harness, not a proposal. The series’ own SEGMENTED_PAYLOAD_GOSSIP.md says which part of the design is in the tree, which is proposed, which exists only in the harness, and what is known to be open.\nWhile this was a long post, a few things still ask for a follow-up post, comparing variant A with B (partial messages) and C (per-segment topics), and discussing some orthogonal protocol design questions:\n\ncontrol traffic clearly increased, as shown in Figure 9. There’s a reason bitmap-based signaling was proposed in FullDAS, later embodied in the partial messages extension. It addresses the control traffic aspect, while higher-frequency message processing remains, so it is still to be seen whether it allows further performance improvements.\nour batch publishing starts to distribute segments on independent paths, but this path independence is not guaranteed later on. The degree of a single topic also limits what high-bandwidth nodes can achieve. Using more topics as in DAS (variant C) is one way of overcoming these limitations.\nall of the above is based on libp2p and gossipsub. Not because we have to, but because we can. Would a new stack, e.g. a UDP-based QUIC-native stack, allow further performance gains? Most probably yes.\nqueue management, priorities, per-peer timer tuning, etc. are all implementation-local improvements that are worth investigating and eventually recommending for clients.\n\nThese are all interesting questions to tackle in a follow-up post, but none of these are required to reach the goals of EIP-8411.\n\n Wen fast payload broadcast? Segment, code, push, pull, and everything in between\n\n EIP-8411 payload segmentation under the Shadow simulator\n\n read \n\n 14\n min\n\n Powered by Discourse","tokens":9082,"squid":"ink-research","role":"Deep Scholar","at":1791263393300,"hash":"69d0512c41844cd2badf2f4ded0f12afd1a599c0"}
{"url":"https://governance.aave.com/c/delegate-platforms/27","domain":"governance.aave.com","title":"Latest Delegate Platforms topics - Aave","text":"Latest topics in Delegate Platforms\n\n Delegate Platforms\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Delegate Platforms category\n\n This category is for candidates for voting & proposal power delegation. \nThere’s no specific framework for delegation at the time of writing this post but it is encouraged for candidates to present themselves, their plat…\n\n read more\n\n 0\n\n 3.6k\n\n Aug 2022\n\n TokenLogic Delegate Platform\n\n 38\n\n 6.7k\n\n 1d\n\n Aave Chan Initiative Delegate platform\n\n 43\n\n 13.9k\n\n 4d\n\n Areta Delegate Platform\n\n 581\n\n 13.5k\n\n Aug 10\n\n EzR3aL Delegate Platform\n\n 43\n\n 5.1k\n\n Jun 30\n\n Anode Delegate Platform\n\n 108\n\n 9.3k\n\n May 26\n\n Ignas Delegate Platform\n\n 196\n\n 5.1k\n\n May 14\n\n Apu Mallku [Delegate platform]: Shutdown \n\n 6\n\n 1.1k\n\n Apr 12\n\n MconnectDAO | India-Based Aave Governance Delegate Focused on Risk, Tokenomics & Hindi-Language Analysis\n\n 0\n\n 143\n\n Mar 30\n\n Notrustverify.ch Delegate Platform (sunsetted)\n\n 14\n\n 897\n\n Mar 23\n\n Blockchain at Berkeley Delegate Platform\n\n 4\n\n 1.2k\n\n Mar 6\n\n Phenk53.eth Delegate Platform\n\n 13\n\n 746\n\n Jan 9\n\n Kpk Delegate Platform\n\n 117\n\n 10.4k\n\n Nov 2025\n\n Saucy Block Delegate Platform\n\n 31\n\n 4.0k\n\n Sep 2025\n\n DAOplomats Delegate Platform\n\n 24\n\n 3.2k\n\n Sep 2025\n\n Question: Delegate platform’s voting power weightage\n\n 10\n\n 335\n\n Jun 2025\n\n Wintermute Delegate Platform\n\n 54\n\n 6.1k\n\n Mar 2025\n\n Keyrock Delegate Platform\n\n 34\n\n 5.6k\n\n Sep 2024\n\n Hazbobo Delegate Platform\n\n 1\n\n 273\n\n Aug 2024\n\n HKUST Blockchain Delegate Platform\n\n 55\n\n 5.2k\n\n May 2024\n\n Arana Digital Delegate Platform\n\n 4\n\n 1.2k\n\n Apr 2024\n\n LBS Blockchain Society Delegate Platform\n\n 684\n\n 26.1k\n\n Feb 2024\n\n [Public Good] Event Horizon Delegate Platform\n\n 0\n\n 882\n\n Jan 2024\n\n Saludiego201.eth Delegate Plataform\n\n 0\n\n 1.6k\n\n Jan 2024\n\n Flipside Crypto Delegate Platform\n\n 10\n\n 4.5k\n\n Oct 2023\n\n Michigan Blockchain Delegate Platform\n\n 6\n\n 2.3k\n\n Sep 2023\n\n FranklinDAO (Prev. Penn Blockchain) Delegate Platform\n\n 58\n\n 6.8k\n\n May 2023\n\n BristolBlockchain Delegate Platform\n\n 0\n\n 1.4k\n\n Mar 2023\n\n Blockworks Research Delegate Platform\n\n 0\n\n 1.6k\n\n Mar 2023\n\n OnChainCoop Delegate Platform\n\n 0\n\n 1.3k\n\n Mar 2023","tokens":548,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263393350,"hash":"501e7003675f9264a0adf3abedda83489b72172c"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale-for-erc20-token-not-using-18-decimals/4946/4","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale for ERC20 token not using 18 decimals - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 4 / 5\n\n Dec 2020\n\n Dec 2020\n\n post by TarrahArshad on Dec 4, 2020\n\n TarrahArshad\n\n i search and i seen ur document all in web but problme is stile in 18 decimals all work fine but in decimal lower 4-5 all number go wrong\nwhy do not list base on other decimals 2-4-5-10 provide examples\n\n Rate to use for Crowdsale?\n\n 3\n\n 2\n\n post by abcoathup on Dec 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nWelcome to the community \nTo calculate the rate for ERC20 tokens you can use the formula: TKNbits = rate * wei\nThis applies regardless of what decimals your token uses.\nSee the documentation for details: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nIf you need help calculating your rate, feel free to share your decimals and the amount of Ether per token.\n\n post by abcoathup on Dec 13, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nDid you need any more information?\n\n post by TarrahArshad on Dec 14, 2020\n\n TarrahArshad\n\n hi andrew\nthanks for ur response\nmy issue is rate .\ni have crowdsale on multi stage\nstage detail is ( start-price , end-price , cap , sold)\ni need calc current base on sold and sold is how many tokens solde before so price increase.\ni need know how increase rate and before that i need know formula for calc current rate depend on USD\nfor ex: $0.01-$0.25 its my range min-max price and i have max 500k token how calc current rate base on sold\nand second my problem is i see with example i setn 250 wei and 500 wei crowdsale buytokens send wrong amount if i send 1 eth i receive 250 token only\n250 wei rate must send 250 token if user send 1eth ? its wrong i no override ur crowdsale.sol i keeped ur but i create new function name buy and call ur buytokens original\nthis is my function\nfor buy and sell i use this\nfunction buy(address beneficiary, address upline) public payable {\n require(\n contributions[upline].buy_amount > 0 || upline == _owner,\n \"upline is wrong\"\n );\n\n uint256 weiAmount = msg.value;\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n require(\n CrowdsaleStages[stage].cap >= CrowdsaleStages[stage].sold + tokens,\n \"cap hit\"\n );\n\n total_tokenSold += tokens;\n CrowdsaleStages[stage].sold += tokens;\n\n buyTokens(beneficiary);\n\n updateUser(beneficiary, upline, tokens);\n }\n\n/**\n * @dev with this function client send request for selling\n * @param amount is how much token selling\n */\nfunction sell(uint256 amount) public returns (uint256 ETHAmount) {\n require(amount > 0, \"You need to sell at least some tokens\");\n require(\n contributions[msg.sender].buy_amount - amount >= 0,\n \"balance is not enoght\"\n );\n if (sellBook[msg.sender].sell_time > 0) {\n require(\n sellBook[msg.sender].sell_time + duration_sell <\n uint40(block.timestamp),\n \"in this hours u can't sell again\"\n );\n }\n // 1. calculate eth amount - 5%\n ETHAmount = _getEthAmount(amount);\n\n // 2. transfer token from sender to crowdsale address\n\n /* uint256 allowance = token.allowance(msg.sender, address(this));\n\n require(allowance >= amount, \"Check the token allowance\");\n\n token.transferFrom(msg.sender, address(this), amount);*/\n\n //msg.sender.transfer(amount);\n\n // 3. transfer fund\n msg.sender.transfer(ETHAmount);\n\n // 4. update stage\n contributions[msg.sender].buy_amount -= amount;\n\n sellBook[msg.sender].id = SellID++;\n sellBook[msg.sender].sell_amount = amount;\n sellBook[msg.sender].sell_time = uint40(block.timestamp);\n\n // emit event\n emit Sold(msg.sender, amount);\n\n return ETHAmount;\n}\n /**\n * The base rate function is overridden to revert, since this crowdsale doesn't use it, and\n * all calls to it are a mistake.\n */\nfunction rate() public view returns (uint256) {\n return CrowdsaleStages[stage].initialRate;\n}\n\n/**\n * @dev Overrides parent method taking into account variable rate.\n * @param weiAmount The value in wei to be converted into tokens\n * @return The number of tokens _weiAmount wei will buy at present time\n */\nfunction _getEthAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 currentRate = getCurrentRate();\n return weiAmount.div(currentRate).mul(uint256(95).div(uint256(100)));\n}\n\n post by abcoathup on Dec 14, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nThe Crowdsales documentation can be found here: https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\nYou could take the ideas from IncreasingPriceCrowdsale, extend Crowdsale and in a getCurrentRate function specify the rate after specific times.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\nIf you are selling based on a set fiat value, then you may be better to create a Crowdsale that accepts a stable coin rather than Ether. You could use the ideas from OpenZeppelin Contracts to do this.\n\nPlease see the documentation for calculating rate: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nI recommend starting with something simple for testing purposes, such as a rate of 1 (assuming decimals of 18).\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to calculate rate for a crowdsale?\n\n Contracts\n\n 3\n\n 4.2k\n\n Sep 2021\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Whats a good way to implement multiple rates into crowdsale?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 792\n\n Mar 2022","tokens":1448,"squid":"ink-security_audits","role":"Sentinel","at":1791263396230,"hash":"15d05bad6509994381c4e8c5bef33619cca9f5ba"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale-for-erc20-token-not-using-18-decimals/4946/5","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale for ERC20 token not using 18 decimals - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 5 / 5\n\n Dec 2020\n\n Dec 2020\n\n post by TarrahArshad on Dec 4, 2020\n\n post by abcoathup on Dec 7, 2020\n\n post by abcoathup on Dec 13, 2020\n\n post by TarrahArshad on Dec 14, 2020\n\n TarrahArshad\n\n hi andrew\nthanks for ur response\nmy issue is rate .\ni have crowdsale on multi stage\nstage detail is ( start-price , end-price , cap , sold)\ni need calc current base on sold and sold is how many tokens solde before so price increase.\ni need know how increase rate and before that i need know formula for calc current rate depend on USD\nfor ex: $0.01-$0.25 its my range min-max price and i have max 500k token how calc current rate base on sold\nand second my problem is i see with example i setn 250 wei and 500 wei crowdsale buytokens send wrong amount if i send 1 eth i receive 250 token only\n250 wei rate must send 250 token if user send 1eth ? its wrong i no override ur crowdsale.sol i keeped ur but i create new function name buy and call ur buytokens original\nthis is my function\nfor buy and sell i use this\nfunction buy(address beneficiary, address upline) public payable {\n require(\n contributions[upline].buy_amount > 0 || upline == _owner,\n \"upline is wrong\"\n );\n\n uint256 weiAmount = msg.value;\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n require(\n CrowdsaleStages[stage].cap >= CrowdsaleStages[stage].sold + tokens,\n \"cap hit\"\n );\n\n total_tokenSold += tokens;\n CrowdsaleStages[stage].sold += tokens;\n\n buyTokens(beneficiary);\n\n updateUser(beneficiary, upline, tokens);\n }\n\n/**\n * @dev with this function client send request for selling\n * @param amount is how much token selling\n */\nfunction sell(uint256 amount) public returns (uint256 ETHAmount) {\n require(amount > 0, \"You need to sell at least some tokens\");\n require(\n contributions[msg.sender].buy_amount - amount >= 0,\n \"balance is not enoght\"\n );\n if (sellBook[msg.sender].sell_time > 0) {\n require(\n sellBook[msg.sender].sell_time + duration_sell <\n uint40(block.timestamp),\n \"in this hours u can't sell again\"\n );\n }\n // 1. calculate eth amount - 5%\n ETHAmount = _getEthAmount(amount);\n\n // 2. transfer token from sender to crowdsale address\n\n /* uint256 allowance = token.allowance(msg.sender, address(this));\n\n require(allowance >= amount, \"Check the token allowance\");\n\n token.transferFrom(msg.sender, address(this), amount);*/\n\n //msg.sender.transfer(amount);\n\n // 3. transfer fund\n msg.sender.transfer(ETHAmount);\n\n // 4. update stage\n contributions[msg.sender].buy_amount -= amount;\n\n sellBook[msg.sender].id = SellID++;\n sellBook[msg.sender].sell_amount = amount;\n sellBook[msg.sender].sell_time = uint40(block.timestamp);\n\n // emit event\n emit Sold(msg.sender, amount);\n\n return ETHAmount;\n}\n /**\n * The base rate function is overridden to revert, since this crowdsale doesn't use it, and\n * all calls to it are a mistake.\n */\nfunction rate() public view returns (uint256) {\n return CrowdsaleStages[stage].initialRate;\n}\n\n/**\n * @dev Overrides parent method taking into account variable rate.\n * @param weiAmount The value in wei to be converted into tokens\n * @return The number of tokens _weiAmount wei will buy at present time\n */\nfunction _getEthAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 currentRate = getCurrentRate();\n return weiAmount.div(currentRate).mul(uint256(95).div(uint256(100)));\n}\n\n post by abcoathup on Dec 14, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nThe Crowdsales documentation can be found here: https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\nYou could take the ideas from IncreasingPriceCrowdsale, extend Crowdsale and in a getCurrentRate function specify the rate after specific times.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\nIf you are selling based on a set fiat value, then you may be better to create a Crowdsale that accepts a stable coin rather than Ether. You could use the ideas from OpenZeppelin Contracts to do this.\n\nPlease see the documentation for calculating rate: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nI recommend starting with something simple for testing purposes, such as a rate of 1 (assuming decimals of 18).\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to calculate rate for a crowdsale?\n\n Contracts\n\n 3\n\n 4.2k\n\n Sep 2021\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Whats a good way to implement multiple rates into crowdsale?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 792\n\n Mar 2022","tokens":1253,"squid":"ink-security_audits","role":"Sentinel","at":1791263406344,"hash":"bf9ce4ff913a1d82507e55eabe2155936cdbb782"}
{"url":"https://ethresear.ch/t/wen-fast-payload-broadcast-segment-code-push-pull-and-everything-in-between/25913","domain":"ethresear.ch","title":"Wen fast payload broadcast? Segment, code, push, pull, and everything in between - Networking - Ethereum Research","text":"Wen fast payload broadcast? Segment, code, push, pull, and everything in between \n\n Networking\n\n p2p\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n read \n\n 11\n min\n\n Sep 4\n\n 1 / 6\n\n Sep 4\n\n 19d ago\n\n post by cskiraly on Sep 4\n\n cskiraly\n\n Wen fast payload broadcast? Segment, code, push, pull, and everything in between\nNote: this post contains my own views, shaped by discussions with many I have worked with on these topics in the past years. The Vac/nim-libp2p work on large messages in gossipsub (staggering and fragmentation, PREAMBLE and IMRECEIVING), RLNC block propagation from @potuz, erasure-coded broadcast in ethp2p from @raulk, and works from @nashatyrev, @kamilsa and @kaseyk all describe various aspects of this collaborative effort to improve Ethereum networking.\nTL;DR\n\nWhole-payload gossip is viable on mainnet today because datacenter builders and nodes carry it — a fact of the deployment, not of the protocol. At roadmap payload sizes or shorter slot times, it may no longer work.\n\nThe fix is small: split the payload into fixed-size segments, commit to the segmentation in one extra field of the builder’s bid, and add three diffusion rules. Segments pipeline through the network instead of store-and-forward.\n\nIn our least favourable setting — a 1 MiB payload from a home builder with no datacenter nodes — the segmented design reduces median receiver completion time from 4.9 s to 0.73 s and cuts the payload bytes each node receives threefold, from 4.4 copies to 1.4. The dependence on datacenter infrastructure is removed, not mitigated.\n\nEvery segment is independently verifiable before forwarding: a Merkle proof against the bid’s commitment, anchored through the block the receiver already validated.\n\nAdd the commitment field at Gloas or Hegota; activate the networking-only rules at Hegota.\n\nBroadcasting large execution payloads over plain gossipsub becomes a consensus problem at the sizes the gas-limit roadmap points toward. It also obstructs plans to shorten slot times. This post measures the segmented design summarized above, then compares it with more elaborate transports.\nThe problem\nGossipsub was not designed for large messages, so whole-payload gossip is slow.\nPayload size has always mattered: before Gloas the execution payload rides inside the beacon block, so a large one makes the block late and costs attestations. Gloas turns that delay into a separate failure. The proposer publishes a block carrying a SignedExecutionPayloadBid, and the winning builder later publishes a SignedExecutionPayloadEnvelope on its own gossip topic. The payload therefore gets its own message, deadline, committee vote, and responsible party. It can be late even when the block was timely. Throughout, block means the consensus block — the beacon block the proposer signs — and never the execution block; payload means what gets segmented, with one container nuance in Part 1.\nTwo properties make diffusion slow. Every validator needs all of it: data-availability sampling does not apply here yet, because that would need ZK execution proofs. And a single gossip message is store-and-forward at every hop: a node receives and validates the whole object before forwarding it, so serialization delay repeats instead of pipelining.\nHow large is it? Mainnet execution payloads today are around 100 KB, nearer 200 KB at the current 60M gas limit. This study tests 1 MiB — roughly 5× that, chosen because it is where the gas-limit roadmap points rather than where mainnet sits. Figure 1 returns to payload size directly.\nThe three-second budget\nThe payload is due at half the slot — PAYLOAD_DUE_BPS, 6 seconds on today’s 12-second slots. The payload-timeliness committee (PTC) votes at three quarters, 9 seconds, but its payload_present bit records whether a valid envelope arrived before the 6-second mark. Arrival in between earns a negative vote, not partial credit. Both deadlines are fractions of the slot, so they shrink with it.\nThe spec fixes the ordering, block first, but not the reveal time. This study assumes a reveal near 3 seconds and therefore a 3-second reveal-relative budget. That is an operating assumption, not a Gloas constant. One scope note: we measure network lateness against this budget; mapping shares of timely receivers to actual payload_present outcomes would require the PTC’s sampling and quorum rules and is out of scope.\nWhy whole-payload gossip works today\nWhole-message diffusion of a payload this size is timely on today’s mainnet because datacenter builders and nodes carry it — a property of the deployment, not the protocol. We simulated both sides of that dependence with real Prysm and go-libp2p-pubsub code.\nThe model has 500 nodes, connectivity degree 70, gossipsub mesh degree 8, synthetic geographic latency across five regions with one-way mean ≈56 ms, 50/100 Mbps (up/down) home links, and a 1 MiB payload compressing to ~746 KB. Its virtual clock models network delay and bandwidth but not computation; we measured that asymmetry separately and found it negligible here.\nWith a home publisher and no datacenter nodes, whole-message diffusion misses badly: median completion is 4.89 s, and the median share of timely receivers is 5%, never above 11%. Completion is per node — the interval from reveal until that node holds the full payload — and a run’s median is the p50 across its 499 receivers.\nTable 1 sweeps the builder’s link against the fraction of nodes that are datacenter-hosted. The all-home cell with a home builder is the case a protocol independent of centralization must pass; it is the same configuration as the headline above. The 20%/home cell estimates today’s realistic worst case: a proposer building locally in a network where a conservative fifth of nodes have datacenter bandwidth to spare.\n\ndatacenter nodes\nhome builder\nexternal builder\n\n0% (all home)\n4.89 s / 1–11% timely\n3.08 s / 34–70%\n\n20%\n2.90 s / 0–99%\n1.80 s / 98–100%\n\n50%\n1.97 s / 78–100%\n1.11 s / 100%\n\nTable 1. Each cell gives the mean of per-seed p50s and the min–max share of 499 receivers timely by the budget. The timely share is the tail metric because the deadline is fixed and the committee counts heads: what matters is the percentile at the deadline, not the latency at a percentile. This is illustrative, not predictive: wide ranges, and a randomly placed 1 Gbps link class standing in for “datacenter”.\nThe direction matters more than a threshold. Node bandwidth moves the result more than builder bandwidth because every forwarding node serializes a complete 746 KB copy — several in parallel — on its own uplink, which builder provisioning cannot improve.\nThus this payload is timely when a datacenter builder publishes it and datacenter nodes occupy its paths, as on current mainnet under MEV-boost. A proposer building locally on a home link has no such path. At payloads the roadmap is heading toward, the mechanism is not sound; the deployment happens to be favourable.\nWhat has to be solved, then, is three problems in one. The first is a networking problem: one source, one large message, every node needs all of it. The second is a trust problem, cryptographic and about information flow: a receiver must be able to verify a piece against something it already trusts, before it holds the rest. The third is their product. The piece’s anchor arrives in a different message from a different party — the block from the proposer, the segments from the builder — so payload diffusion becomes a special case of large-message diffusion: two sources, and a gate between them. Part 1 takes the trust problem, Part 2 the networking one, and “What the coupling costs” measures their product.\nThe proposed solution: segmented diffusion\nSplit the payload into K segments (e.g. 32 × 32 KiB for 1 MiB) and diffuse them as independent gossip messages on one shared topic. Each hop forwards a 32 KiB unit rather than a 1 MiB object, so paths pipeline and no single node’s uplink gates the whole payload.\nOn the same base, with a home builder and no datacenter nodes, the recommended configuration (segments, batch publishing, phase forwarding, disciplined pulls — all measured one by one below) gives median 0.73 s, every receiver timely in every seed, 1.4 received payload copies per node against 4.4 for whole message. The price is a consensus-container field and networking rules that every client must implement. Add the field at Gloas; activate the networking-only rules at Hegota.\ncompletion vs payload size1216×736 77.6 KB\nFigure 1. Mean per-seed median completion time for whole-message diffusion and the recommended segmented configuration, swept by payload size with a home builder and no datacenter nodes.\nThe proposal has two parts. A bid commitment lets each segment prove membership in the committed segmentation. A networking change carries those segments without violating the trust chain. The prototype implements the networking half in full; for the bid commitment it uses an interim admission rule — first group offered per slot, the right cardinality but no authenticity — with the same map-lookup cost and no effect on transport results.\nPart 1 — the bid commitment\nA node must not forward what it cannot verify. The builder is already deterred: payment is unconditional, and the reassembled payload is checked against the bid’s commitments, so a builder that reveals garbage pays and delivers nothing. Per-segment validation instead protects the forwarding node, which no payment or slashing reaches. Without it, one malicious node can inject a corrupt segment that the mesh propagates until every downstream node discards the reassembled payload. Whole-message gossip validates the complete object before relay; a segment is meaningless alone. Each segment therefore needs a commitment and a proof that a receiver can check without the rest of the payload.\nThe first requirement is a vector commitment to the segment sequence, allowing each segment to prove membership. A Merkle tree provides a 32-byte root and log K hashes per proof, is cheap, and composes with erasure coding if decoders enforce codeword consistency. The proof can travel with the segment, as in DAS; as an alternative, a protocol could send the tree or its top layers separately.\nThe second requirement is a chain of trust from that commitment to something the receiver already trusts:\n\ninstalled block → its bid → the committed descriptor → Merkle proof → this segment\n\nEach link authenticates the next, anchored by the block carrying the bid after the receiver has validated and applied it. Installed does not mean attested or final; the anchor is exactly as strong as the receiver’s own block validation. The chain runs through the block, so a segment cannot be authenticated before its block arrives. That is the cost of a consensus anchor; at the end of this post we briefly discuss alternative authority routes.\nthe two wavefronts1216×672 75.7 KB\nFigure 2. First-segment arrival and block installation are the two relevant wavefronts; raw block arrival is shown for reference. The shaded interval marks nodes holding a segment they cannot yet verify. Curves are schematic; installation adds an assumed 200 ms.\nConcretely, add execution_payload_segment_group_id to ExecutionPayloadBid — the bid message the builder signs, not its signed wrapper. It commits the canonical descriptor: version, hash id, segment count, segment size, total length and Merkle root. These framing fields make wire bounds sanity checks rather than load-bearing constants once the block is installed.\nThe obvious object to segment is the serialized envelope, but it contains beacon_block_root. Committing that descriptor in a bid later carried by the block would be circular. Instead, segment an SSZ container of what the builder holds at bid time:\n\nExecutionPayloadSegmentBody:\n\npayload\n\nexecution_requests\n\nbeacon_block_root, parent_beacon_block_root and builder_index then come from the block when the ordinary envelope is reconstructed.\nPart 2 — the networking change\nThe wire must identify, both in each segment and in its message ID, the block that would authorize it.\nA segment carries its index, Merkle proof, slot + beacon_block_root, and group id, but no descriptor or signature. The group id is a structural claim: after the named block installs, it must match the group that block committed to. Overhead is ~210 bytes per 32 KiB segment (~0.6%), but the important property is that the segment asserts no authority of its own. The proof catches forged content.\nMessage ids must also be self-describing, as in FullDAS. Today’s content hashes do not reveal which block would authorize an announcement, so a receiver cannot decline what it cannot verify. A hybrid id combines a structural (slot, block root, group, index) prefix with a content digest; a purely structural id would let a bad first arrival poison gossipsub deduplication. The group stays in the id because, before installation, a receiver cannot resolve block → group. That untrusted namespace is what the buffering bounds cover. The id function is defined by the Ethereum spec and installed by the application, so this requires no libp2p wire change. It remains normative and incompatible and therefore activates at a fork boundary.\nDiffusion rules. These three form the complete normative set. Disciplined pulls and phase forwarding, measured below, remain local performance policies:\n\nDo not relay a segment whose authorizing block is not installed. Here installed means validated and applied, not merely received. Buffer it in a bounded queue with per-peer reservations so one peer cannot exclude another’s copy of the same segment.\n\nA receiver may decline to request what it cannot authenticate. Because an announcement is not re-offered automatically, a bounded ledger of declined ids and a block-installed event must resubmit them, with ExecutionPayloadEnvelopesByRoot as fallback after the announcer’s cache expires.\n\nA sender may push eagerly only with evidence the peer holds the block: it sent the block to that peer, received it from them, or saw an IHAVE or IDONTWANT for it. The receiver can reconstruct whether the push was entitled, making a violation grounds for descoring or disconnection. The prototype does not yet score it. The rule presupposes something the other two do not: a sender has evidence only for peers it exchanges blocks with, and with independent meshes for the block topic and the segment topic (eight of seventy connections each) those overlap in about one peer per node, so eager pushes would go almost nowhere and phase forwarding would degrade toward pull-only. It needs a shared mesh for blocks and segments — co-routing them over one topology — which also makes the block tend to precede the segments along every path. That helps the gate without being authority: validation runs asynchronously, so wire order does not imply installed-before-validated. Our measurements use independent meshes and unconditional pushes; the rule’s cost on them is unmeasured.\n\nWhat the coupling costs\nThe block-install delay, not network arrival, determines how many nodes hold segments they cannot yet verify. At an assumed 200 ms block-install delay, 439–489 of 499 nodes are affected; non-relay reduces that to 8–11, each buffering a few hundred kilobytes for roughly the install delay. Isolated, non-relay affects 7–16 nodes and request gating 51–68. Every receiver met the 3 s threshold in every tested configuration.\nThe 200 ms is a number we picked, not a measurement, and it is the dominant variable here; the real value is a profiling question on a loaded node, not a simulation one.\nWhat each mechanism buys\nSegmentation buys most of the latency improvement; publishing and forwarding policy buy the rest, while disciplined pulls primarily reduce bytes. The mechanisms also buy different kinds of loss and omission tolerance. Table 2 adds one mechanism at a time on the same base and repeats the experiment on the two datacenter mixes from Table 1, whose whole-message row it shares. Cells are means of per-seed median completion, and payload copies received per node (bytes over one compressed payload):\n\nconfiguration\nhome builder, all home\nhome builder, 20% datacenter\ndatacenter builder, 20% datacenter\n\nwhole message\n4.89 s / 4.4×\n2.90 s / 4.5×\n1.80 s / 4.1×\n\n+ segmentation alone — ordered, full-mesh push\n1.76 s / 6.4×\n1.45 s / 6.2×\n0.94 s / 5.7×\n\n+ batch publishing — first copies before repeats\n1.01 s / 6.3×\n0.81 s / 6.2×\n0.70 s / 5.7×\n\n+ phase forwarding — push two, announce the rest\n0.76 s / 3.1×\n0.72 s / 3.2×\n0.62 s / 2.9×\n\n+ disciplined pulls — one request per id, offer table, move-on and ban\n0.73 s / 1.4×\n0.67 s / 1.4×\n0.62 s / 1.5×\n\nPipelining does most of the work. Cutting the payload into 32 KiB units that nodes forward as they arrive is the largest single step, 2.8× on its own: no uplink serializes the whole object. It costs bytes at first — full-mesh push of 32 pieces carries more copies than one push of the whole — and the last two rows are what takes them back. Batch publishing sends one copy of everything before a second copy of anything, so no segment waits at the source and each takes a different first path. Phase forwarding trims the remaining latency.\nDisciplined pulls buy the bytes. Requesting each announced id from one peer rather than every announcer halves the phase arm’s received bytes at equal latency, 3.1 to 1.4 copies in Table 2’s last two rows, and takes pull-only to essentially one copy. This local fix is already in flight upstream as #625. A single request can be captured by a peer that announces but does not serve, so the requester records alternative announcers in a bounded offer table, tries the next after a short window, and briefly bans a peer whose claim lapses. That memory is free when nothing goes wrong, costs a fraction of a copy in eager re-asks, and keeps honest receivers complete even when most announcers withhold.\nPhase forwarding offers a push-pull compromise. A few eager first copies plus announcements for the rest cost about 0.4 of a copy over pull-only. A lost copy is repaired by the announce-and-pull path; a lost request instead idles that segment for a full retry window. Under loss, the phase arm degrades mildly while pull-only’s tail stretches, making the byte-cheapest configuration the most brittle.\nErasure coding buys loss tolerance and cuts the delay distribution tail. A withheld segment can come from another peer; a segment the source never sent cannot. Omitting 4 of 32 plain segments strands every receiver, whereas a 32-of-64 coded group completes everyone because any 32 shards reconstruct. The price is complexity (not much of it), and code consistency to get right.\nThe queue bounds under attack\nBefore a receiver installs the slot’s commitments, a fabricated group is indistinguishable from an honest early arrival and earns only bounded buffering. After installation, it is refused for the cost of a parse. Block-install delay sets normal deferral; expiry and the per-sender slot bound cover the case where no block installs.\nThe exposure is local because deferred or refused junk is never relayed. The slot bound must be per sender: a global bound would let an attacker fill the table first and exclude later honest groups.\nOpen specification work\nThe envelope signature. Reassembly yields the envelope’s contents, but Gloas requires the builder’s signature over the assembled envelope, which contains the block root, so its bytes exist only two steps after the bid is signed and the bid cannot commit to them. Either it travels as a small message of its own, which then needs the same admission and recovery treatment the segments got, or segmented reveals drop it: the signed bid already authenticates content and builder, and the signature’s only non-redundant role is authorizing the reveal act, so dropping it changes what “revealed” means for envelope validity and the PTC’s payload_present bit. That is a consensus question, not a networking one.\nThe wire type and its bounds. Topic name, SSZ type, maximum message size, and the count, size and length bounds are unspecified. They must be tight rather than sanity constants: a loose total-length bound admits a 256 MiB claim against a 10 MiB gossip limit, and a 1 MiB per-segment cap admits an unsegmented segment. Committing count and size in the bid makes them exact once the block is installed; before that, the message-size cap and the admission bounds stay load-bearing.\nDesign alternatives and transport choice\nThe measurements chiefly compare transports. Consensus-side alternatives need separate treatment:\n\nCommitment scheme. An SSZ generalized-index multiproof authenticates tree nodes rather than byte ranges and forecloses erasure coding; Pedersen-style homomorphic commitments (as proposed for RLNC block propagation) fit if network coding enters. A Merkle tree composes with coding and is the choice here.\n\nWhere the commitment lives. A builder-signed descriptor avoids changing a consensus container, but its one-candidate bound is policy — with first-wins and reorg semantics, a signing domain, and one BLS verification per group. The bid field gives a cryptographic bound: one group per authorized block root, checked by hash comparison.\n\nWhere authority comes from. Wait-for-the-block admits exactly one group per authority object, cryptographically. A proposer-header proof or gossiped bid relies on policy because a proposer may sign many, while a detached builder signature is unbounded within its window. This ranking yields Part 2’s rule: authentication is a membership test, so a segment asserts no authority.\n\nThe header proof alone provides independence from block arrival. It costs ~1.9% of payload bytes per segment, or 7.6% at 8 KiB segments, and exchanges a cryptographic bound for a policy one to avoid a coupling measured as small. Unbuilt; no cost comparison has been run.\n\nSlashing. A segmentation-specific offence would punish a builder already deterred by unconditional payment and would not reach forwarding nodes. We see no need for one.\n\nTransport variants. We evaluated four ways to move segments:\n\nA — one shared topic. Every segment is an ordinary gossip message on one topic. This is the proposal and the source of every headline number here.\n\nB — partial messages. One logical message carries all segments, with per-peer bitmaps recording inventories; that requires a gossipsub extension. Tuned like A, it is timely at 1.8–2.2 s and at byte parity with A, assuming per-segment compression, but remains a second slower and needs its own memory to recover claims that lapse unserved under withholding.\n\nC — one topic per segment. Separate meshes buy path diversity, producing 667 ms median and 1.20 copies at 64 topics on the clean 500-node base. It degrades first under withholding — 89–93% timely and p90 2.75–3.05 s — so its clean tail depends on honest announcers.\n\nD — custody subnets with erasure coding. Each node custodies a subset of a coded group, the FullDAS shape, capping byte cost near the subscription ratio: ~1.33 copies versus 2.23 for coding on the shared topic. One shard beyond the code margin stalled only the 8 nodes whose custody covered every omitted shard; 491 of 499 completed.\n\nvariant comparison1352×910 174 KB\nFigure 3. Completion time versus payload equivalents received per node on the 1,000-node base. Points are per-seed medians, bars span seeds, both axes are logarithmic, and lower left is better.\nVariant A uses the least machinery. It meets the worst-base deadline with wide margin — 0.73 s against 3 s — so C’s extra quarter second buys nothing the budget needs and costs a mesh per segment plus weaker withholding behaviour. B pays for inventories the deadline does not need. D’s coding earns its place only if source omission enters the threat model. A uses stock gossipsub messages end to end; everything beyond the fork-gated changes is local policy. However, note that everything above depends on implementation details, so do not take it as a strick ordering. Take it as A is good enough and simple.\nThe recommendation is the one-shared-topic transport (variant A) with phase forwarding and disciplined pulls backed by an offer table, a bid-field Merkle commitment, per-segment Merkle proofs, and block-anchored non-relay — a measured direction, not a specification.\nThe skeptic’s questions\nA speedup this large invites questions about the harness. We tested what we could; burstiness and real install delay remain less comfortable gaps.\n“Isn’t this really just some gossipsub bug you fixed?” The headline pair differs in segmentation and the request path: the disciplined pulls in Table 2’s last row are a substrate fix that applies to whole-message gossip too. Applying only that fix moves the worst corner from 4.89 to 4.70 s at 2–12% timely, still a bad miss in the design’s target case. But there are many implementation details, which admittedly can make comparing variants a comparison of implementation choices (and bugs) rather than of fundamental differences.\n“Your clock hides CPU, and segmentation does 32× the work.” True; the blind spot favours the proposal. The measured total is ~2.5 ms against a 3.5 s effect — 0.07%, which cannot threaten the result. These are service times on an idle machine; contention on a loaded node is unmeasured.\n“Cold connections flatter segmentation.” Warming every link moves whole-message latency by −7.8% across three seeds, small against a 5.4× gap. Segments at ~23 KB already fit the initial congestion window, 40 KiB in modern QUIC implementations; warming actually slowed that arm by 34%. Sweeping the initial window from 12.5 to 160 KiB moves it by at most 11%, with the stock window at the optimum. Neither result is an artifact of transport state.\n“Does it hold on a loaded network? On a thin link?” Background gossip up to 32× a mainnet slot’s average non-payload traffic moved nothing. Above that, flat results at loads the uplink could not carry suggest the stack sheds the flooded topic before the wire; that is inferred, not directly measured. The 3-second budget holds down to about 15 Mbps of residual uplink for a 1 MiB payload, then degrades through lateness rather than failure. Coding’s extra copies stop being free first, from around 20 Mbps. Slot-boundary burstiness from blob-scale co-arrivals remains the largest untested realism gap.\n“Why not erasure code?” It provides tail performance and robustness against network errors and adversaries with almost no CPU cost. It remains a compatible follow-on, but is not necessary for the first version recommended here.\n“Does the design require a fixed segment size?” No. It can fix a count or size, derive the size from payload length, or allow a bounded declared choice; this post does not choose among them.\n“What if your link model is wrong?” It is necessarily one operating point: networks vary across places and time. It is sufficient for directional conclusions, not prediction.\n“Is this a problem mainnet has today?” Yes and no — it depends on who publishes a block, with what timing, and what state the network is in.\nOK, so when should all this happen?\nThese are just my views on how I would do it, definitely not the only reasonable option on the table. The two changes have different deployment costs and constraints.\nThe bid commitment is a consensus change — one field and one container — and consensus changes travel only by fork. Gloas is already defining ExecutionPayloadBid as it detaches the payload. Adding the field while that container is being designed costs a spec review; changing it after shipment costs a fork of its own. Even if we are far ahead with the timeline, I think we can add it in Gloas. If not, then I would add it in Hegota.\nThe networking change is relatively easy to introduce, but needs loads of testing: the prototype and measurements exercise it, and it needs no libp2p change. However, this is only a prototype, and multiple production implementations are needed. Segmented diffusion therefore needs time, but I think Hegota is an easily reachable target with the shape proposed here. Adding erasure coding is also possible, and provides clear benefits, if there is appetite, but it is not necessary in the first phase.\n\n EIP-8411: what segmented payload diffusion is made of\n\n 4\n\n read \n\n 11\n min\n\n post by Nashatyrev on Sep 7\n\n Nashatyrev\n\nDidn’t you try to apply erasure coding (RS x2)? Would be interesting to check what does it buy? In my recent simulations related to @kamilsa proposal, EC may buy another -30-40% from p95 latency\nUPD: I think I saw EC case on the diagram \n\n post by cskiraly on Sep 9\n\n cskiraly\n\n Indeed, I run EC as well. Over simple segmentation, as part of partial messages, and also with the DAS-like multi-topic overlay. The point I make above is that even without coding we can have tremendous performance gains. That’s if someone thinks EC would make implementation too complex for this and that fork.\nEC makes it better, no doubt on that from my side (and that’s what I said in the last 2 years in my talks).\n\n post by satushh on Sep 9\n\n satushh\n\nAre the harness and the Prysm / go-libp2p-pubsub branches public anywhere?\n\n post by cskiraly on Sep 12\n\n cskiraly\n\nAre the harness and the Prysm / go-libp2p-pubsub branches public anywhere?\n\nI’ve pushed it for RowDAS already, and will soon push it for this too.\n\n post by cskiraly on Sep 17\n\n cskiraly\n\n The follow-up post, including the code of the Prysm / go-libp2p-pubsub branches ,is published at EIP-8411: what segmented payload diffusion is made of\n\n Powered by Discourse","tokens":7408,"squid":"ink-research","role":"Deep Scholar","at":1791263413795,"hash":"38c257f25899343f4fabba786c2a3bdcc74c7b97"}
{"url":"https://governance.aave.com/t/aave-chan-initiative-delegate-platform/10877/45","domain":"governance.aave.com","title":"Aave Chan Initiative Delegate platform - Delegate Platforms - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 18\n\n 11\n\n 4\n\n 2\n\n 2\n\n read \n\n 20\n min\n\n Nov 2022\n\n 44 / 44\n\n Oct 2\n\n 4d ago\n\n Load more posts above\n\n post by XTG1724 on Nov 23, 2023\n\n XTG1724\n\n Hi everyone,\nWe are happy to share that ACI has succesfully managed to list, in collaboration with Coingecko, all Aave V3 Markets aTokens in their site.\nWe believe this may be useful for users to have some visibility when checking basic information such as price feed, chains available, etc.\n*Disclaimer: Please bear in mind that there are still some work to be done by Coingecko on some aToken in Gnosis, Metis, OP and AVAX, so if you see that in those chains for certain assets, the information is only being displayed as “Preview Only”, that’s correct at the time being, and eventually, will be fixed.\nThat’s all for now, stay tuned for more updates!\n\naToken\nName for CG listing\nTicker\nCG Listing URL\n\nAave USD Coin\nAave v3 USDC\naUSDC\nhttps://www.coingecko.com/en/coins/aave-v3-usdc\n\nAave Ethereum\nAave v3 WETH\naWETH\nhttps://www.coingecko.com/en/coins/aave-v3-weth\n\nAave Wrapped BTC\nAave v3 WBTC\naWBTC\nhttps://www.coingecko.com/en/coins/aave-v3-wbtc\n\nAave Tether\nAave v3 USDT\naUSDT\nhttps://www.coingecko.com/en/coins/aave-v3-usdt\n\nAave Rocket Pool ETH\nAave v3 rETH\narETH\nhttps://www.coingecko.com/en/coins/aave-v3-reth\n\nAave Dai Stablecoin\nAave v3 DAI\naDAI\nhttps://www.coingecko.com/en/coins/aave-v3-dai\n\nAAVE Token\nAave v3 AAVE\naAAVE\nhttps://www.coingecko.com/en/coins/aave-v3-aave\n\nAave Chainlink\nAave v3 LINK\naLINK\nhttps://www.coingecko.com/en/coins/aave-v3-link\n\nAave Maker\nAave v3 MKR\naMKR\nhttps://www.coingecko.com/en/coins/aave-v3-mkr\n\nAave Wrapped liquid staked Ether 2.0\nAave v3 wstETH\nawstETH\nhttps://www.coingecko.com/en/coins/aave-v3-wsteth\n\nAave Savings Dai\nAave v3 sDAI\nasDAI\nhttps://www.coingecko.com/en/coins/aave-v3-sdai\n\nCoinbase Wrapped Staked ETH\nAave v3 cbETH\nacbETH\nhttps://www.coingecko.com/en/coins/aave-v3-cbeth\n\nAave Uniswap\nAave v3 UNI\naUNI\nhttps://www.coingecko.com/en/coins/aave-v3-uni\n\nAave LUSD Stablecoin\nAave v3 LUSD\naLUSD\nhttps://www.coingecko.com/en/coins/aave-v3-lusd\n\nAave Lido DAO Token\nAave v3 LDO\naLDO\nhttps://www.coingecko.com/en/coins/aave-v3-ldo\n\nAave Curve DAO Token\nAave v3 CRV\naCRV\nhttps://www.coingecko.com/en/coins/aave-v3-crv\n\nAave Synthetix Network Token\nAave v3 SNX\naSNX\nhttps://www.coingecko.com/en/coins/aave-v3-snx\n\nAave Balancer\nAave v3 BAL\naBAL\nhttps://www.coingecko.com/en/coins/aave-v3-bal\n\nAave Frax\nAave v3 FRAX\naFRAX\nhttps://www.coingecko.com/en/coins/aave-v3-frax\n\nAave Stargate Token\nAave v3 STG\naSTG\nhttps://www.coingecko.com/en/coins/aave-v3-stg\n\nAave 1INCH Network\nAave v3 1INCH\na1INCH\nhttps://www.coingecko.com/en/coins/aave-v3-1inch\n\nAave Ethereum Name Services\nAave v3 ENS\naENS\nhttps://www.coingecko.com/en/coins/aave-v3-ens\n\nAave Kyber Network Crystal v2\nAave v3 KNC\naKNC\nhttps://www.coingecko.com/en/coins/aave-v3-knc\n\nAave Rocket Pool Protocol\nAave v3 RPL\naRPL\nhttps://www.coingecko.com/en/coins/aave-v3-rpl\n\nAave USD Base Coin\nAave v3 USDbC\naUSDbC\nhttps://www.coingecko.com/en/coins/aave-v3-usdbc\n\nAave Bridged USDC\nAave v3 USDC.e\naUSDC.e\nhttps://www.coingecko.com/en/coins/aave-v3-usdc-e\n\nAave Arbitrum\nAave v3 ARB\naARB\nhttps://www.coingecko.com/en/coins/aave-v3-arb\n\nAave STASIS EURS Token\nAave v3 EURS\naEURS\nhttps://www.coingecko.com/en/coins/aave-v3-eurs\n\nAave Bitcoin\nAave v3 BTC.b\naBTC.b\nhttps://www.coingecko.com/en/coins/aave-v3-btc-b\n\nAave Wrapped Avalanche\nAave v3 WAVAX\naWAVAX\nhttps://www.coingecko.com/en/coins/aave-v3-wavax\n\nAave Benqi Staked Avalanche\nAave v3 sAVAX\nasAVAX\nhttps://www.coingecko.com/en/coins/aave-v3-savax\n\nAave MAI (Mimatic)\nAave v3 MAI\naMAI\nhttps://www.coingecko.com/en/coins/aave-v3-mai\n\nAave Synth sUSD\nAave v3 sUSD\nasUSD\nhttps://www.coingecko.com/en/coins/aave-v3-susd\n\nAave Optimism\nAave v3 OP\naOP\nhttps://www.coingecko.com/en/coins/aave-v3-op\n\nAave Liquid Staking Matic (PoS)\nAave v3 MaticX\naMaticX\nhttps://www.coingecko.com/en/coins/aave-v3-maticx\n\nAave Staked Matic (PoS)\nAave v3 stMATIC\nastMATIC\nhttps://www.coingecko.com/en/coins/aave-v3-stmatic\n\nAave Wrapped Matic\nAave v3 WMATIC\naWMATIC\nhttps://www.coingecko.com/en/coins/aave-v3-wmatic\n\nAave Aavegotchi GHST\nAave v3 GHST\naGHST\nhttps://www.coingecko.com/en/coins/aave-v3-ghst\n\nAave SushiToken (PoS)\nAave v3 SUSHI\naSUSHI\nhttps://www.coingecko.com/en/coins/aave-v3-sushi\n\nAave agEUR\nAave v3 agEUR\naagEUR\nhttps://www.coingecko.com/en/coins/aave-v3-ageur\n\nAave DefiPulse Index (PoS)\nAave v3 DPI\naDPI\nhttps://www.coingecko.com/en/coins/aave-v3-dpi\n\nAave Metis Token\nAave v3 Metis\naMetis\nhttps://www.coingecko.com/en/coins/aave-v3-metis\n\nAave Gnosis Token on xDai\nAave v3 GNO\naGNO\nhttps://www.coingecko.com/en/coins/aave-v3-gno\n\nAave Monerium EUR emoney\nAave v3 EURe\naEURe\nhttps://www.coingecko.com/en/coins/aave-v3-eure\n\n post by MarcZeller on Dec 1, 2023\n\n MarcZeller\n\n by this message, we officially recognize the @ACI account as the official voice of the Aave-Chan Initiative:\nACI team members with @ACI account access:\n\n@MarcZeller\n@0xTogbe\n@XTG1724\n\n post by ACI on Dec 1, 2023\n\n ACI\n\n Leader\n\n Hello frens,\nFollowing previous messages, we’re happy to share November 2023 Highlights, and a comparison with October 2023.\nFrom now on, we will share at the beginning of each month, a report of the previous month activity, as well as some KPI, and ACI public activity KPI related to Governance.\nSo with further delay let’s dig into November’s 2023 Highlights!\nNovember 2023 Highlights567×428 28 KB\n November’s Highlights\n\n15 [TEMP CHECK]\n7 [TEMP CHECK] Snapshot\n\nACI voted on 7 (5 YAE, 1 NAY and 1 Abstain)\n\n36 [ARFC] Forum\n\n10 Author - ACI\n\n15 ARFC Snapshot\n\nACI voted on 14 out of 15 (13 YAE, 1 NAY, 1 Abstain)\n\n31 [AIP]\n\nACI voted on 30 ( 29 YAE, 1 NAY, 1 Didn’t vote)\n10 AIP Author - ACI\n\n6 Other\n\nWe are proud to state that November 2023 has been the most intense month of activity so far this 2023 with a record of 31 AIP, and 36 ARFC Forum posts. This is translated into a frenetic month in terms of governance, with lots of activity in all stages ( Temp Check, Temp Check Snapshot, ARFC, ARFC Snapshot & AIP), and all stakeholders participating into governance decision.\n*To calculate this report, it has been taken into account as effective date, the start date of the stage, so there are a couple of AIP for example that are active, but were launched in November.\nIf we enter into October & November comparison:\nGeneral Governance KPI 10/23 vs. 11/23607×377 14.5 KB\nWe can see in a more visual image that there’s been an overall increase in governance this November 2023 compared to October, with 3x more Temp Checks, 2X Temp Check Snapshots, 16 more ARFC, a stability in ARFC Snapshots, and 6 more AIP.\nIf we also extract ACI public activity and compare it:\nCaptura de pantalla 2023-12-02 a las 0.46.41606×376 14.4 KB\nWe voted 2X more in Temp Check Snapshots, kept the same amount of ARFC authorship, voted same amount of ARFC Snapshots (15), had 1 more AIP authorship than October 23 and voted in 5 more AIP.\nYou can check in more depth all governance/forum activity at November’s 2023 Highlights.\nFor example, if you click the toggle on [Temp Check] Forum, you will see all Temp Checks numbered, a link to forum post, and a summary of the Temp Check. The same applies to the rest of the categories.\nTemp Check Toggle example748×584 36 KB\nAnd that would be all November 2023 Report!\n**Please bear in mind that you also have available all monthly highlights since February 2023 in the following Aave DAO & ACI Governance Activity Page:\nSummary1570×922 91.6 KB\nThat’s all for now, stay tuned for more updates!\n\n post by ACI on Dec 7, 2023\n\n ACI\n\n Leader\n\n Hello frens,\nContinuing with ACI’s effort to increase visibility when checking basic information such as price feed, chains available, contract addresses, etc for assets in Aave Markets, we’re happy to share that in collaboration with Etherscan, we have updated Aave V3 Market aToken information in their site.\nThis is a strategic movement, alongside previous Coingecko listing, to help Aave users, when they need to check data, to rely on trustable sources as Etherscan and Coingecko for price feed, contract addresses, etc.\nThat’s all for now, stay tuned for more updates!\n\n 27 days later\n\n post by ACI on Jan 3, 2024\n\n ACI\n\n Leader\n\n Hello frens,\nFirst of all, we wish you an excellent & Happy New Year! Hopefully this year will be better than 2023 \nAs we are entering the first month of the year, it’s a great moment to look back into what happened in terms of activity of ACI during December 2023, specially with new V.3 Governance and its consequent governance embargo, and the last Quarter of 2023.\n(If you want to check any of the previous AIP you need to go Governance V.2)\nWe will have to wait a few more days before governance is lifted up, but in the meantime, we are sharing December 2023 Report.\nObviously since embargo came effective around 22th December, there’s been a pause in new TEMP CHECK, ARFC, Snapshots and and AIP.\nPaused governance for V31674×296 21.7 KB\nThat is translated into a small decrease in activity compared to November 2023, which, in counterpart, does not represent the very intense month that has been making sure everything was ready to Gov. V.3.\nDecember 2023 Highlights360×380 21.2 KB\n December’s Highlights\n\n5 [TEMP CHECK]\n3 [TEMP CHECK] Snapshot\n\nACI voted on 3 (0 YAE)\n\n16 [ARFC] Forum\n10 [ARFC] Snapshot\n\nACI voted on 9 out of 10 (9 YAE)\n\n25 [AIP]\n\nACI voted on 25 (24 YAE)\n7 written by ACI\n\n2 Other\n\nIf we take a look at 4Q 2023 and compare each month, in general terms there’s a small decrease due to embargo but pace was very good as December was from 01/12 to 22/12 and on the other hand we had several challenges that implied maximum participation and we’re proud of Aave DAO and it’s strengh, such as Governance V3 Activation with more than 1,122,272 votes and not a single NAY vote.\nQ4 20231204×746 31.6 KB\nHope you find this information useful, for now thats all frens, and Happy New Year again!\nACI\n\n 28 days later\n\n post by ACI on Feb 1, 2024\n\n ACI\n\n Leader\n\n Hello frens,\nTime flies, and first month of the year has passed already!\nIn this occasion, it’s important to point out that V.3 Governance was launched after governance embargo, and so far it’s been an amazing journey, with plenty of governance activity.\nRemember, if you still want to check any of the previous AIP you need to go Governance V.2 \nWe had a first days of January that embargo was still active so ion paper that should have meant there’s a bit less of governance proposals, but on the contrary.\nSharing January 2024 Report\nLet’s dive in!\n\nWe had an increase in Temp Checks, Temp Check Snapshots, ARFC and ARFC Snapshots, with a slightly decrease in AIP due to embargo and new v.3 version.\n\nMost relevant proposals to point out are:\n\nDolce Vita - Empowering Aave Governance with seamless operations \n\nMerit - A New Aave-Alignment User Reward System \n\nEstablishing the Aave Protocol Embassy (APE) \n\nIntroducing “Frontier” - Staking as a Service for the Aave DAO\n\nYou can of course get into much more detail in January 2024 Report\nThat’s all for now, thank you for delegating into Aave Chan Initiative (ACI) and stay tuned for more updates!\n\n [ARFC] Establishing the Aave Protocol Embassy (APE)\n\n 28 days later\n\n post by ACI on Mar 1, 2024\n\n ACI\n\n Leader\n\n Hello frens,\nTime to post our report from February, with intense activity as always.\nAs you already know, we’ve been already under V.3 Governance for a bit, and February 2024 has been a good month when it comes to governance activity.\nPlease remember that if by any chance you still want to check any of the previous AIP from 2023 and before Gov V.3 you need to go Governance V.2 .\nHere you’ll find February 2024 Report \nLet’s dive in!\n\nWe had a bit of a decrease in Temp Checks and of course Temp Check Snapshots as a result of focusing on moving forward with existing proposals, but on the other hand the number of ARFC and ARFC Snapshots increased, with an important number of AIP that were published.\n\nA summary of the most relevant proposals to point out are:\n\nMerit - A New Aave-Alignment User Reward System \nOrbit Program Renewal\nAdd rsETH to Aave V3 Ethereum\nOnboard weETH to Aave V3 Ethereum\nNew Risk Steward Signer\n\nYou can of course get into much more detail in February 2024 Report \nThat’s all for now, thank you for delegating into Aave Chan Initiative (ACI) and stay tuned for more updates!\n\n 1 month later\n\n post by ACI on Apr 2, 2024\n\n ACI\n\n Leader\n\n Hello frens!\nWe do hope that you had a great Easter and a long weekend.\nNow it’s time to take a look back to March 2024 as well as Q1 2024, for you to have the monthly report, and ACI governance actiivty!\nMarch 2024 Report\nLet’s dive in!\n\nIf we compare March with February, we observe that there’s been an overall increase in governance activity, mainly in TEMP CHECK and ARFC, that will translate respectively in an increase of ARFC and ARFC Snapshots during April.\nThere was a total of 13 TEMP CHECK, 7 TEMP CHECK Snapshots, 33 ARFC on Forum, 21 ARFC Snapshot, and 21 AIP.\nIf we take a look on all Q1 2024:\n\nIn this image we can clearly appreciate the overall increase in TEMP CHECK(13) and ARFC (33), while Snapshots maintain the average amount, as well as AIP.\nA summary of the most relevant proposals to point out, as well as actions are:\n\nMerit Approvals\nReset Aave v3 Deployment Pipeline \nRollout plan for Cross-Chain GHO \nGHO Cross-Chain Strategy\nUpdate on correlated-price asset onboarding \n\nOne of the biggest action was Merit Airdrop being live, first for WETH borrowers, where 280 WETH were airdropped, and then to GHO borrowers and stkGHO stakers, with 1M$.\nSome press about Merit last week:\n\nIf you haven’t claimed yet or check if you did get rewards, you can do so at aavechan.com/claim.\nYou can of course get into much more detail in March 2024 Report \nThat’s all for now, thank you for delegating into Aave Chan Initiative (ACI) and stay tuned for more updates!\n\n 1 month later\n\n post by ACI on May 3, 2024\n\n ACI\n\n Leader\n\n April 2024 Report\nHello frens, hope that you’re good!\nAs we enter into May, its a good moment to take a step back and take a look at ACI and governance activity during April 2024.\nA month that had pretty interesting proposals to be discussed under governance ( that we will mention later in this thread) but in general, an intense month with an outstanding record of 40 ARFC on Forum!\nA reflection of how committed community, service providers, and holders are with Aave Governance and its decisions, and at ACI we’re proud to be the leading example by being one of the most active service providers.\nLet’s take a closer look:\nApril 2024 Report\n\nIf we compare April 24 with its previous month, we observe a slight decrease in TEMP CHECK, but that’s understandable due to the amount of ARFC that were published as a result of moving forward with previous TEMP CHECK and TEMP CHECK Snapshots.\nAs per TEMP CHECK Snapshots, we had 7, same number, but where we saw a huge increase and a record so far was in ARFC posted on Forum, for a total of 40, that will be translated into an increase in May for ARFC Snapshots and AIP.\nOf course you can always get access to full report by entering at April 2024 Report.\nFor those who don’t have the time to read all governance activity, here’s a TLDR:\n\nIntroducing “FastPass” - A Safety Module Update \nGHO Cross-Chain Rollout Plan - First Network\nGHO Stewards - Adjustments GHO Borrow Cap \nChaos Labs Engagement Amendment \n“Merit is Forever” Reward System Program Extension \nApril Finance Update \nOnboard New Risk Service Provider \n\nLastly, please remember to claim your rewards under Merit program if you borrowed GHO, staked GHO or borrowed WETH.\nYou can do it through ACI Dashboard, where you have available information, and you can see your last round APR, current APR, and much more information!\nWe encourage you to use the site as well as https://dapps.aavechan.com/ as ACI has put a lot of work and love to make governance and delegation easier.\nThat’s all for now! Stay tuned for more updates!\n\n 29 days later\n\n post by ACI on Jun 1, 2024\n\n ACI\n\n Leader\n\n May 2024 Report\nHello frens, hope that you’re good!\nWe are happy to share May 2024 Governance Report and ACI and governance activity, before entering into June and the end of Q2.\nA month that had pretty interesting proposals to be discussed under governance ( that we will mention later in this thread) but in general, a busy month as usual.\nLet’s take a closer look:\nMay 2024 Report\n\nOverall we observe same level of governance activity, with a small increase in TEMP CHECK (+3), a slight decrease in TEMP CHECK Snapshots (-2) and ARFC (-8). We had also a slight increase in ARFC Snapshots (+3) that will soon translate in more AIP for June. As per AIP published, we see an important decrease ( -16) but again that is not a KPI per se rather than a visual representation that June will have more AIP, as they always balance due to governance process and deadlines from those 32 ARFC we had this month.\n\nAs always, you can get access to the full report by entering at May 2024 Report.\nAs a TLDR summary for those who don’t have the time to read all Forum & Governance, we selected the following proposals:\n\nAave Protocol V4 Development Proposal \nAave 2030 \nAave Visual Identity \nActivate and Deploy GHO Safety Module on Arbitrum \nGHO Cross-Chain Launch \nOrbit Program Renewal May 2024 \nExpansion of “Frontier” \nACI Phase III - “Ad Astra”\nRenewal of Aave Guardian - 2024\n\nLastly, please remember to claim your rewards under Merit program if you borrowed GHO, staked GHO or borrowed WETH. A few days ago took place Round 4 so check if you have some rewards!\nYou can do it through ACI Dashboard , where you have available information, and you can see your last round APR, current APR, and much more information!\nWe encourage you to use the site as well as https://dapps.aavechan.com/ as ACI has put a lot of work and love to make governance and delegation easier.\nThat’s all for now! Stay tuned for more updates!\n\n 29 days later\n\n post by ACI on Jul 1, 2024\n\n ACI\n\n Leader\n\n June 2024 Report\nHello frens, hope that you’re good!\nWe are happy to share June 2024 Governance Report and ACI and governance activity, before entering into July and the start of Q3.\nA month that had pretty interesting proposals to be discussed under governance ( that we will mention later in this thread) but in general, a busy month as usual.\nLet’s take a closer look:\n\nOverall we observe same level of governance activity, with a small decrease in TEMP CHECK (-4), same TEMP CHECK Snapshots (5) and a slight decrease in ARFC (-8).\nWe had also a considerable decrease in ARFC Snapshots (-11) . But, on the other hand, as per AIP published, the level was maintained (15 vs 17 in May) but again that is not a KPI per se as it’s more important the quality of those AIP.\n\nAs always, you can get access to the full report by entering at June 2024 Report.\nAs a TLDR summary for those who don’t have the time to read all Forum & Governance, we selected the following proposals:\n\nAave Liquidity Committee Funding Phase III\nUpdate Asset Onboarding Framework \nAL Service Provider Proposal \nOptimize ETH-correlated asset parameters \nSet ACI as Emission Manager for Liquidity Mining Programs \nDeployment of Aave on zkSync\nDeploy a Lido Aave v3 Instance \nAIP - Onboard USDe Aave V3 Ethereum\nAIP - Onboarding ETHx to Aave V3 Ethereum\nAIP - GHO Cross-Chain - Part 1\nAIP - GHO Cross-Chain - Part 2\nAIP - Set ACI as Emission Manager for Aave Liquidity Mining programs\n\nLastly, please remember to claim your rewards under Merit program if you borrowed GHO or, staked GHO. This weekend Round 5 was activated so check if you have some rewards!\nYou can do it through ACI Dashboard , where you have available information, and you can see your last round APR, current APR, and much more information!\nWe encourage you to use the site as well as https://dapps.aavechan.com/ as ACI has put a lot of work and love to make governance and delegation easier.\nThat’s all for now! Stay tuned for more updates!\n\n 1 month later\n\n post by ACI on Aug 1, 2024\n\n ACI\n\n Leader\n\n July 2024 Report\nHello frens, hope that you’re good!\nWe are happy to share July 2024 Governance Report and ACI and governance activity, before entering into August and holidays for many of you.\nA month that had pretty interesting proposals to be discussed under governance ( that we will mention later in this thread) but in general, a busy month as usual.\nLet’s take a closer look:\n\nOverall we observe an increase of governance activity, with practically same amount of TEMP CHECK ( 7 in June vs. 6 in July), an increase in TEMP CHECK Snapshots (+3), and a slight increase in ARFC (+5). AIP are practically flat, with +2 this month (but as stated previously that is not a KPI per se as it’s more important the quality of those AIP).\n\nAs always, you can get access to the full report by entering at July 2024 Report.\nAs a TLDR summary for those who don’t have the time to read all Forum & Governance, we selected the following proposals:\n\nAave v. 3.1 upgrade\nAave V3 Deployment on Aptos Mainnet \nDeploy an Etherfi/Stablecoin Aave V3 Instance\nDeploy an Ethena Aave v3 Instance \nAAVEnomics Update\nARFC-Addendum AaveDAO policy regarding Spark fork\nGHO Parameter Adjustment - Governance Process Amendment \nExtend GHO Stewards to Arbitrum \nGHO Arbitrum - Parameter Adjustments \nMerit Base Incentives and Superfest Matching \nOnboard USDC.e on Gnosis\nOnboarding weETH to Aave V3 on Scroll \nLido Ethereum Instance Activation\n\nOn a separate note, we are proud to share the Lido/Ethereum Instance Activation, which has been a huge success and a joint effort from different Service Providers of the DAO, with ACI leading it.\nYou can also check Marc’s latest tweet, where Lido Instance reached 121M$ in less than 24h, which is a major success.\n\nLastly, please remember to claim your rewards under Merit program if you borrowed GHO or, staked GHO. Round 6 was activated recently so check if you have some rewards!\nYou can do it through ACI Dashboard , where you have available information, and you can see your last round APR, current APR, and much more information!\nMerit rewards2870×1592 318 KB\nIf you have questions about Merit, what it is, if you’re elegible or not, you can check it directly there, as there’s a section of FAQ for you to check.\nMerit FAQ2186×566 65.3 KB\nWe encourage you to use the site as well as https://dapps.aavechan.com/ as ACI has put a lot of work and love to make governance and delegation easier.\nThat’s all for now! Stay tuned for more updates!\n\n post by heyjared on Aug 1, 2024\n\n heyjared\n\n Thank you for the transparent update, proud to have the ACI advocate for AAVE - excited to continue see more growth & developments\n\n 2 months later\n\n post by MarcZeller on Oct 9, 2024\n\n MarcZeller\n\nEdited for added clarity:\n\nACI Alignment Voting Doctrine\nAt the ACI, our mission is to safeguard the best interests of the Aave Protocol, its users, and the long-term health of the broader DeFi industry.\nWhile we have consistently supported ecosystem diversity, we have observed certain actors whose actions are detrimental to the industry and openly hostile toward the Aave ecosystem. To protect Aave and draw a clear distinction between aligned and non-aligned participants, the ACI is now implementing an Alignment Voting Doctrine.\nUnder this doctrine, any non-alignment will result in an automatic NAY vote from the ACI at the ARFC stage of proposals. This clear stance signals our position to the broader community and allows third parties to adjust their strategies accordingly.\nThat said, the ACI reserves the right to vote YAE on a case-by-case basis if circumstances merit it. One current example is synergies in the Base ecosystem; the ACI recognizes the strategic importance of this ecosystem for the Aave DAO and will continue to support and contribute to its success, allowing it to offboard underperforming legacy partners at its own pace.\nWe expect proposers to make their best effort to disclose any affiliations with potentially non-aligned entities in their proposals to ensure full transparency.\nActors with a history of poor work ethics, service underperformance, lack of care for users and protocol safety, or a history of hostility toward Aave, the DAO, and its service providers will be deemed non-aligned.\nGauntlet is an example of a non-aligned entity based on its history of underperformance and hostility toward the Aave DAO.\nThis doctrine ensures that Aave stays aligned with partners who prioritize the protocol’s long-term success and the broader DeFi ecosystem.\nTo ensure fairness, the ACI commits to clearly stating at the TEMP CHECK phase of a proposal whether they consider it affiliated with a non-aligned entity. The ACI will cast an ABSTAIN vote at this stage, allowing the proposer the opportunity to make adjustments before the ARFC stage.\nThe ACI also recognizes the reality of legacy burdens and will not apply this doctrine retroactively. A commitment to future offboarding of relations with non-aligned actors will be considered alignment.\nLastly, we want to make this clear: this doctrine is not an Aave DAO policy and should not be interpreted as such. It is a policy of the ACI delegate platform. As delegate representatives representing the voices of hundreds of token holders, it is part of our Duty to express our opinions and doctrine clearly with full transparency.\nThis doctrine does not affect our work, scope, or duty as a service provider for the Aave DAO. The ACI will follow governance decisions with the same degree of diligence, regardless of our votes or intentions to vote. All proposers will be treated on equal terms and benefit from the same quality of service, regardless of their affiliation or alignment.\n\n post by thegreenmongrel on Oct 9, 2024\n\n thegreenmongrel\n\n Marc, it’s crystal clear your so-called ‘Aave Alignment Voting Doctrine’ is less about protecting Aave and more about pushing your personal agenda. Your bias against Gauntlet and MEV Capital is glaring and clouding your judgment. Governance should be about what’s best for the protocol, not personal vendettas. If you’re truly committed to transparency, maybe you should start by owning up to what’s really driving these decisions. Right now, it’s your anger and bias that are hurting Aave, not Gauntlet or MEV Capital. How exactly are they ‘detrimental to the industry and openly hostile toward Aave’?\n\n 6 months later\n\n post by ACI on Apr 17, 2025\n\n ACI\n\n Leader\n\n Hello frens!\nIt’s been a while since we last posted, and we owe you an apology.\nWe’ve been so buried under work the last 6 months, giving our best to ensure Aave DAO and AAVE remained the best, with so many proposals, partnerships and future innovations that we put on hold the updates in ACI Delegate Platform.\nAs you may be aware already, we posted a few days ago ACI Retrospective 2024-present which summarizes all 2024 activity, as well as showing some cool KPI and stats that had never been shared, as for example:\n\nType of Governance Activity 2024\nNumber\n% of TOTAL\n\nTEMP CHECK\n82\n9,19%\n\nTEMP CHECK Snapshot\n78\n8,75%\n\nARFC\n332\n37,23%\n\nARFC Snapshot\n178\n19,95%\n\nAIP\n222\n24,88%\n\nTOTAL\n892\n100%\n\nGovernance activity per month1884×1170 233 KB\nor the amazing results we accomplished under Merit & Skywards, that we could not have done without your support.\nSummary of Merit programs\n\nMetric\nValue\n\nCount\n18\n\nTotal Budget\n$20,469,280.09\n\nTotal TVL Growth\n$907,116,980.44\n\nMean Campaign TVL Growth per Dollar Spend\n$2,284.58\n\nSummary of LM programs\n\nMetric\nValue\n\nCount\n21\n\nTotal Budget\n$15,937,307.84\n\nTotal TVL Growth\n$1,648,871,729.87\n\nMean Campaign TVL Growth per Dollar Spent\n$393.29\n\nSummary of all incentive programs (LM + Merit)\n\nMetric\nValue\n\nCount\n39\n\nTotal Budget\n$36,406,587.93\n\nTotal TVL Growth\n$2,555,988,710.31\n\nMean Campaign TVL Growth per Dollar Spent\n$1,266.19\n\nSome highlighted achievements for incentive programs:\n\ncbBTC campaign: Grew from 4,600 to 8,900 cbBTC in deposits\nBase borrow wstETH campaign: Increased borrows from 1,080 to 14,714\nBase borrow wstETH campaign: Delivered $517 TVL growth per $1 spent\nsupply wBTC borrow USDT campaign: $2,192.09 TVL growth per dollar spent ($1,166.17 for awBTC + $1,025.92 for vUSDT)\ncbBTC-USDC campaign: $7,855.37 TVL growth per dollar spent ($3,924.81 direct growth and $3,930.56 indirect growth from interest rate effects)\n\nJust to finish, you can have a deeper analysis of each month, at Aave DAO Governance, where we have the latest reports we did not share in here, from August 2024 until December 2024.\nIn a few weeks we’ll share the report for Q1 2025.\nAnd finally, today our founder Marc Zeller has posted [ARFC] ACI Phase IV – “Road to 80” , which is ACI renewal, in order to continue delivering Aave DAO’s Growth and Governance Coordination as a Service Provider.\nThank you for your continued support!\nJust use Aave, and ACI.\n\n 1 year later\n\n post by 0xmonk 4 days ago\n\n 0xmonk\n\n How do I undelegate from ACI and re-delegate to another?\n\n post by EzR3aL 4 days ago\n\n EzR3aL\n\n Regular\n\n simply delegate to someone else\n\n post by 0xmonk 4 days ago\n\n 0xmonk\n\n I know I’m asking too much. Is there a guide or URL on how to delegate? :) Last time it was a a simple click of a button from ACI website and I couldn’t recall much.\n\n post by EzR3aL 4 days ago\n\n EzR3aL\n\n Regular\n\n If you go here Aave - Open Source Liquidity Protocol you can see on the right side everything thats needed.\nI always used the BGD interface but it has been shut down obviously.\nAs Im also not part anymore of the DAO, i haven’t followed much other development in here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n ACI is leaving Aave\n\n General\n\n 32\n\n 7.1k\n\n Jul 1\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n Notrustverify.ch Delegate Platform (sunsetted)\n\n Delegate Platforms\n\n 14\n\n 897\n\n Mar 23\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10","tokens":7531,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263413891,"hash":"fd90bc3f7cbaa849bf64fbd89abe88f1e19effb9"}
{"url":"https://forum.openzeppelin.com/t/setting-crowdsale-rate-manually/1659/8","domain":"forum.openzeppelin.com","title":"Setting crowdsale rate manually - General - OpenZeppelin Forum","text":"General\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 5\n\n Oct 2019\n\n 8 / 11\n\n Nov 2019\n\n Nov 2019\n\n post by bayram on Oct 30, 2019\n\n post by abcoathup on Oct 30, 2019\n\n post by bayram on Oct 31, 2019\n\n post by abcoathup on Oct 31, 2019\n\n post by bayram on Nov 1, 2019\n\n post by abcoathup on Nov 1, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nYou are welcome. Feel free to ask all the questions that you need.\nWith OpenZeppelin and Led Zeppelin they are both great Zeppelins, it is understandable. \n\n post by bayram on Nov 1, 2019\n\n bayram\n\n @abcoathup\nI wonder why are members of Crowdsale.sol such as _wallet, _rate, _token, and _weiRaised declared private? While they are readable, they are not accessible when we inherit from Crowdsale contract. This does not allow me to inherit from Crowdsale and for example define a setter function for _rate.\nI made _rate internal in Crowdsale.sol and my derived contract worked fine.\npragma solidity >=0.4.21 <0.6.0;\n\nimport \"../node_modules/@openzeppelin/contracts/access/Roles.sol\";\nimport \"../node_modules/@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\ncontract MyCrowdsale is Crowdsale{\n using Roles for Roles.Role;\n\n Roles.Role private _owners;\n\n constructor(uint256 initialRate, address payable wallet, IERC20 tokenAddr, address ownerAddr)\n Crowdsale(initialRate, wallet, tokenAddr)\n public\n {\n _owners.add(ownerAddr);\n }\n\n function setRate(uint256 newRate) public\n {\n require(_owners.has(msg.sender), \"DOES_NOT_HAVE_RATE_SETTER_ROLE\");\n _rate = newRate;\n }\n}\n\nWhat is the reason to make those variables private?\n\n post by abcoathup on Nov 1, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nWe shouldn't modify the OpenZeppelin Contracts themselves, we should inherit and where needed override.\n\nhttps://docs.openzeppelin.com/contracts/2.x/#usage\nWarning: You should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself.\n\nAs an aside, we don't need \"../node_modules\" on import statements.\nimport \"../node_modules/@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\nRegards state variables being private, the release notes for OpenZeppelin 2.0 explain:\n\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.0\nAll state variables are now private, which means that derived contracts cannot access them directly, but have to use getters. This is to increase encapsulation, to be able to reason better about the code.\n\nWe can override Crowdsale functionality to give a changeable/settable rate so could do something like the following code.\nPlease note, I haven't tested this smart contract at all.\nAs always, I recommend that smart contracts are appropriately tested and audited.\npragma solidity ^0.5.0;\n\nimport \"@openzeppelin/contracts/access/Roles.sol\";\nimport \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\ncontract MyCrowdsale is Crowdsale{\n using Roles for Roles.Role;\n\n Roles.Role private _owners;\n\n uint256 private _changeableRate;\n\n constructor(uint256 initialRate, address payable wallet, IERC20 tokenAddr, address ownerAddr)\n Crowdsale(initialRate, wallet, tokenAddr)\n public\n {\n _owners.add(ownerAddr);\n\n _changeableRate = initialRate;\n }\n\n function setRate(uint256 newRate) public\n {\n require(_owners.has(msg.sender), \"DOES_NOT_HAVE_RATE_SETTER_ROLE\");\n _changeableRate = newRate;\n }\n\n function rate() public view returns (uint256) {\n return _changeableRate;\n }\n\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.mul(_changeableRate);\n }\n}\n\n How to change rate/price of a token in Crowdsale?\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n post by bayram on Nov 2, 2019\n\n bayram\n\n @abcoathup\nYeah, I fixed import \"../node_modules/@openzeppelin/... to import \"@openzeppelin/...\nI agree with you, I always respect other’s code, never change private member. In my example I just wanted to show that if _rate was declared as internal then we could derive from Crowdsale without need to override ALL methods where _rate appears.\nIn fact, my contract looks exactly like you suggest.\nI’ve also written tests for this contract, and I am going to test it on Ropsten before I deploy it on mainnet. You provide security audit as far as I know, so probably I will submit my code for the audit.\nThank you again for your suggestions. \n\n post by abcoathup on Nov 2, 2019\n\n 1 year later\n\n Split this topic on Dec 13, 2020\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Help me write an erc20 token and a crowdsale contract\n\n Contracts\n\n erc20\n\n 9\n\n 8.0k\n\n Dec 2020\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020","tokens":1261,"squid":"ink-security_audits","role":"Sentinel","at":1791263416497,"hash":"feb2fbc16bf4940c7c182840e6a9208d3ca6de27"}
{"url":"https://specs.optimism.io/protocol/isthmus/exec-engine.html","domain":"specs.optimism.io","title":"Execution Engine - OP Stack Specification","text":"L2 Execution Engine\n\nTable of Contents\n\nOverview\nTimestamp Activation\nL2ToL1MessagePasser Storage Root in Header\n\nHeader Validity Rules\nHeader Withdrawals Root\n\nRationale\nGenesis Block\nState Processing\nP2P\nBackwards Compatibility Considerations\nForwards Compatibility Considerations\nClient Implementation Considerations\n\nTransaction Simulation\n\nDeposit Requests\nBlock Body Withdrawals List\nEVM Changes\n\nBLS Precompiles\n\nBlock Sealing\nEngine API Updates\n\nUpdate to ExecutionPayload\nengine_newPayloadV4 API\n\nFees\n\nOperator Fee\n\nFee Formula\nDeposit Operator Fees\nEVM Fee Semantics\nTransaction Pool Changes\nConfiguring Operator Fee Parameters\n\nFee Vaults\nReceipts\n\nOverview\nThe storage root of the L2ToL1MessagePasser is included in the block header's\nwithdrawalRoot field.\nTimestamp Activation\nIsthmus, like other network upgrades, is activated at a timestamp.\nChanges to the L2 Block execution rules are applied when the L2 Timestamp >= activation time.\nL2ToL1MessagePasser Storage Root in Header\nAfter Isthmus hardfork's activation, the L2 block header's withdrawalsRoot field will consist of the 32-byte\nL2ToL1MessagePasser account storage root from the world state identified by the stateRoot\nfield in the block header. The storage root should be the same root that is returned by eth_getProof\nat the given block number.\nHeader Validity Rules\nPrior to isthmus activation:\n\nthe L2 block header's withdrawalsRoot field must be:\n\nnil if Canyon has not been activated.\nkeccak256(rlp(empty_string_code)) if Canyon has been activated.\n\nthe L2 block header's requestsHash field must be omitted.\n\nAfter Isthmus activation, an L2 block header is valid iff:\n\nThe withdrawalsRoot field\n\nIs 32 bytes in length.\nMatches the L2ToL1MessagePasser account storage root,\nas committed to in the storageRoot within the block header\n\nThe requestsHash field is equal to sha256('') = 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\nindicating no requests in the block.\n\nHeader Withdrawals Root\nByte offsetDescription\n[0, 32)L2ToL1MessagePasser account storage root\n\nRationale\nCurrently, to generate L2 output roots for historical blocks, an archival node is required. This directly\nplaces a burden on users of the system in a post-fault-proofs world, where:\n\nA proposer must have an archive node to propose an output root at the safe head.\nA user that is proving their withdrawal must have an archive node to verify that the output root they are proving\ntheir withdrawal against is indeed valid and included within the safe chain.\n\nPlacing the L2ToL1MessagePasser account storage root in the withdrawalsRoot field alleviates this burden\nfor users and protocol participants alike, allowing them to propose and verify other proposals with lower operating costs.\nGenesis Block\nIf Isthmus is active at genesis block, the withdrawalsRoot in the genesis block header is set to the\nL2ToL1MessagePasser account storage root.\nState Processing\nAt the time of state processing, the header for which transactions are being validated should not make it's withdrawalsRoot\navailable to the EVM/application layer.\nP2P\nDuring sync, we expect the withdrawals list in the block body to be empty (OP stack does not make\nuse of the withdrawals list) and hence the hash of the withdrawals list to be the MPT root of an empty list.\nWhen verifying the header chain using the final header that is synced, the header timestamp is used to\ndetermine whether Isthmus is active at the said block. If it is, we expect that the header withdrawalsRoot\nMPT hash can be any non-null value (since it is expected to contain the L2ToL1MessagePasser's storage root).\nBackwards Compatibility Considerations\nBeginning at Canyon (which includes Shanghai hardfork support) and prior to Isthmus activation,\nthe withdrawalsRoot field is set to the MPT root of an empty withdrawals list. This is the\nsame root as an empty storage root. The withdrawals are captured in the L2 state, however\nthey are not reflected in the withdrawalsRoot. Hence, prior to Isthmus activation,\neven if a withdrawalsRoot is present and a MPT root is present in the header, it should not be used.\nAny implementation that calculates output root should be careful not to use the header withdrawalsRoot.\nNote that there is always nonzero storage in the L2ToL1MessagePasser,\nbecause it is a proxied predeploy -- from genesis it\nstores an implementation address and owner address. So from Isthmus,\nthe withdrawalsRoot will always be non-nil and never be the MPT root of an empty list.\nForwards Compatibility Considerations\nAs it stands, the withdrawalsRoot field is unused within the OP Stack's header consensus format, and will never be\nused for other reasons that are currently planned. Setting this value to the account storage root of the withdrawal\ndirectly fits with the OP Stack, and makes use of the existing field in the L1 header consensus format.\nClient Implementation Considerations\nVarious EL clients store historical state of accounts differently. If, as a contrived case, an OP Stack chain did not have\nan outbound withdrawal for a long period of time, the node may not have access to the account storage root of the\nL2ToL1MessagePasser. In this case, the client would be unable to keep consensus. However, most modern\nclients are able to at the very least reconstruct the account storage root at a given block on the fly if it does not\ndirectly store this information.\nTransaction Simulation\nIn response to RPC methods like eth_simulateV1 that allow simulation of arbitrary transactions within one or more blocks,\nan empty withdrawals root should be included in the header of a block that consists of such simulated transactions. The same\nis applicable for scenarios where the actual withdrawals root value is not readily available.\nDeposit Requests\nEIP-6110 shifts deposit to the execution layer, introducing a new EIP-7685 deposit request of type\nDEPOSIT_REQUEST_TYPE. Deposit requests then appear in the EIP-7685 requests list. The OP Stack needs to ignore these\nrequests. Requests generation must be modified to exclude EIP-6110 deposit requests. Note that since the EIP-6110\nrequest type did not exist prior to Pectra on L1 and the Isthmus hardfork on L2, no activation time is needed since these\ndeposit type requests may always be excluded.\nBlock Body Withdrawals List\nWithdrawals list in the block body is encoded as an empty RLP list.\nEVM Changes\nBLS Precompiles\nSimilar to the bn256Pairing precompile in the granite hardfork,\nEIP-2537 introduces a BLS\nprecompile that short-circuits depending on input size in the EVM.\nThe input size limits of the BLS precompile contracts are listed below:\n\nG1 multiple-scalar-multiply: input_size <= 513760 bytes\nG2 multiple-scalar-multiply: input_size <= 488448 bytes\nPairing check: input_size <= 235008 bytes\n\nThe rest of the BLS precompiles are fixed-size operations which have a fixed gas cost.\nAll of the BLS precompiles should be accelerated in fault proof\nprograms so they call out to the L1 instead of calculating the result inside the program.\nBlock Sealing\nIn the OP Stack, EIP-7685 is no-op'd, and the requestsHash is always set to sha256('') (as noted in\nheader validity rules). As such, EIP-6110,\nEIP-7002, and EIP-7251 are not\nenabled either. The OP Stack execution layer must ensure that the post-block filtering of events in the deposit contract\n(EIP-6110) as well as the EIP-7002 + EIP-7251 system calls are not invoked during the block sealing process after\nIsthmus activation.\nUsers of the OP Stack may still permissionlessly deploy these smart contracts, but they will not be treated as special\nby the OP Stack execution layer, and the system calls introduced in L1's Pectra hardfork are not considered.\nEngine API Updates\nUpdate to ExecutionPayload\nExecutionPayload will contain an extra field for withdrawalsRoot after Isthmus hard fork.\nengine_newPayloadV4 API\nPost Isthmus, engine_newPayloadV4 will be used.\nThe executionRequests parameter MUST be an empty array.\nFees\nNew OP stack variants have different resource consumption patterns, and thus require a more flexible\npricing model. To enable more customizable fee structures, Isthmus adds a new component to the fee\ncalculation: the operatorFee, which is parameterized by two scalars: the operatorFeeScalar\nand the operatorFeeConstant.\nOperator Fee\nThe operator fee is integrated directly into the EVM, alongside the standard gas fee and the OP Stack specific L1 data\nfee. This fee follows the same semantics of existing fees charged in the EVM1, just with a new fee beneficiary account.\nFee Formula\n\nWhere:\n\ngas is the amount of gas that the transaction used. When calculating the amount of gas that is bought at the\nbeginning of the transaction, this should be the gas_limit. When determining how much gas should be refunded,\nbased off of how much of the gas_limit the transaction used, this should be the gas_used.\noperatorFeeScalar is a uint32 scalar set by the chain operator, scaled by 1e6.\noperatorFeeConstant is a uint64 scalar set by the chain operator.\n\nNote that the operator fee's maximum value has 77 bits, which can be calculated from the maximum input parameters:\n\nSo implementations don't need to check for overflows if they perform the calculations with uint256 types.\nDeposit Operator Fees\nDeposit transactions do not get charged operator fees. For all deposit transactions, regardless of the operator fee\nparameter configuration, the operator fee should be zero. Deposit transactions also do not receive operator fee gas\nrefunds, since they never buy the operator fee gas to begin with.\nEVM Fee Semantics\nLike other fees in the EVM, the operator fee should be charged following the pattern below:\n\nDuring pre-execution validation, the account must have enough ETH to cover the existing worst-case gas + L1 data fees\nas well as the worst-case operator fee (for deposits, the worst-case fee is 0). To compute this value, use the\nfee formula with gas set to the gas_limit of the transaction, and add it to the existing\nworst-case transaction fee.\nWhen buying gas prior to execution, charge the account the worst-case operator fee. To compute this value, use the\nfee formula with gas set to the gas_limit of the transaction.\nAfter execution, when issuing refunds, transactions that bought operator fee gas should be refunded the operator fee\ngas that was unused (i.e., the caller should only be charged the effective operator fee.) The refund should be\ncalculated as , where:\n\n is as described in #1 + #2.\n is the amount of the operator fee that was actually used. This value is computed using the\nfee formula with gas set to the gas_limit - gas_used + refunded_gas. refunded_gas is as\ndescribed in EIP-3529.\n\nAfter execution, when rewarding the fee beneficiaries, send the spent operator fee to the\noperator fee vault. This value is exactly as described above.\n\nImplementations must ensure ETH is neither minted nor destroyed as a result of the operator fee.\nTransaction Pool Changes\nTo account for the additional fee factored into transaction validity mentioned above, the transaction pool must reject\ntransactions that do not have enough balance to cover the worst-case cost of the transaction fee. This worst-case cost\nof a transaction now includes the worst-case operator fee.\nConfiguring Operator Fee Parameters\noperatorFeeScalar and operatorFeeConstant are loaded in a similar way to the baseFeeScalar and\nblobBaseFeeScalar used in the L1Fee.\ncalculation. In more detail, these parameters can be accessed in two interchangable ways.\n\nread from the deposited L1 attributes (operatorFeeScalar and operatorFeeConstant) of the current L2 block\nread from the L1 Block Info contract (0x4200000000000000000000000000000000000015)\n\nusing the respective solidity getter functions (operatorFeeScalar, operatorFeeConstant)\nusing direct storage-reads:\n\nOperator fee scalar as big-endian uint32 in slot 8 at offset 0.\nOperator fee constant as big-endian uint64 in slot 8 at offset 4.\n\nFee Vaults\nThese collected fees are sent to a new vault for the operatorFee: the OperatorFeeVault.\nLike the existing vaults, this is a hardcoded address, pointing at a pre-deployed proxy contract.\nThe proxy is backed by a vault contract deployment, based on FeeVault, to route vault funds to L1 securely.\nReceipts\nAfter Isthmus activation, 2 new fields operatorFeeScalar and operatorFeeConstant are added to transaction receipts\nif and only if at least one of them is non zero.\n1\nWood, G., & Ethereum Contributors. (n.d.-a). Ethereum Yellow Paper. https://ethereum.github.io/yellowpaper/paper.pdf Page 8, section 5: \"Gas and Payment\"","tokens":3147,"squid":"ink-governance","role":"Council Listener","at":1791263426403,"hash":"4ee994a36105ad273933f7789c6558e6f1c96457"}
{"url":"https://io.net/docs/guides/clouds/confidential-compute-attestation-guide","domain":"io.net","title":"GPU Attestation and Verification Guide - io.net","text":"This guide shows you how to perform GPU attestation and verification on Virtual Machines provisioned by io.net Cloud, this allows you to verify NVIDIA GPUs and validate cryptographic evidence to ensure workloads run in a Trusted Execution Environment (TEE).\n​One-Time Setup\nBefore running GPU verification for the first time, you need to install NVIDIA’s official attestation tools. This setup takes about 2–3 minutes and only needs to be completed once per VM.\n1Connect to your VMssh root@your-vm-ip\n2Create Verification DirectoryCreate a dedicated directory to store the verification tools and scripts.mkdir -p ~/gpu-verification\ncd ~/gpu-verification\n3Create a Python Virtual EnvironmentUse a virtual environment to keep dependencies isolated and avoid conflicts with system packages.# Create isolated Python environment\npython3 -m venv venv\n# Activate the environment\nsource venv/bin/activate\nYou should now see (venv) in your command prompt.4Install NVIDIA Attestation SDKUpgrade pip, then install NVIDIA’s official attestation packages.# Upgrade pip to the latest version\npip install --upgrade pip\n# Install the official NVIDIA attestation package\npip install nv-attestation-sdk\nExpected output:Collecting nv-attestation-sdk\n Downloading nv_attestation_sdk-2.6.3-py3-none-any.whl (45 kB)\nCollecting nv-local-gpu-verifier==2.6.3\n Downloading nv_local_gpu_verifier-2.6.3-py3-none-any.whl (89 kB)\nCollecting PyJWT==2.7.0\n Downloading PyJWT-2.7.0-py3-none-any.whl (22 kB)\n...\nSuccessfully installed nv-attestation-sdk-2.6.3 nv-local-gpu-verifier-2.6.3 ...\n5Create the Verification ScriptCreate a Python script that collects GPU evidence and performs cryptographic attestation using NVIDIA’s SDK.Show Scriptcat > ~/gpu-verification/verify_gpu.py << 'EOF'\n#!/usr/bin/env python3\n\n\"\"\"\nGPU Confidential Compute Verification\nUses official NVIDIA nv-attestation-sdk\n\"\"\"\n\nimport sys\nfrom verifier.cc_admin import (\n collect_gpu_evidence,\n attest,\n CcAdminUtils,\n BaseSettings\n)\n\ndef main():\n print(\"=\" * 70)\n print(\"NVIDIA GPU Confidential Compute Verification\")\n print(\"Using official NVIDIA nv-attestation-sdk\")\n print(\"=\" * 70)\n print()\n\n try:\n # Step 1: Generate cryptographic nonce\n print(\"[1/3] Generating cryptographic nonce...\")\n nonce = CcAdminUtils.generate_nonce(\n BaseSettings.SIZE_OF_NONCE_IN_BYTES\n ).hex()\n print(f\" Nonce: {nonce[:16]}...\")\n print()\n\n # Step 2: Collect GPU evidence\n print(\"[2/3] Collecting evidence from GPUs...\")\n print(\" This may take 20–30 seconds...\")\n evidence_list = collect_gpu_evidence(\n nonce=nonce,\n no_gpu_mode=False,\n ppcie_mode=False\n )\n print(f\" Found {len(evidence_list)} GPU(s) with CC support\")\n print()\n\n # Step 3: Perform attestation\n print(\"[3/3] Validating attestation evidence...\")\n print(\" • Verifying certificate chains\")\n print(\" • Checking OCSP revocation status\")\n print(\" • Validating firmware measurements (RIM)\")\n print(\" • Verifying cryptographic signatures\")\n print()\n\n arguments = {\n 'user_mode': False,\n 'test_no_gpu': False,\n 'allow_hold_cert': False,\n 'driver_rim': None,\n 'vbios_rim': None,\n 'service_key': None,\n 'rim_root_cert': None,\n 'ocsp_url': None,\n 'rim_service_url': None,\n 'ocsp_nonce_disabled': False,\n 'claims_version': '3.0',\n 'verbose': False\n }\n\n result, response = attest(arguments, nonce, evidence_list)\n\n print()\n print(\"=\" * 70)\n\n if result:\n print(\"✅ VERIFICATION SUCCESSFUL\")\n print(\"=\" * 70)\n print()\n print(f\"This system has {len(evidence_list)} genuine NVIDIA GPU(s)\")\n print(\"with Confidential Computing features enabled and operational.\")\n print()\n print(\"Verification completed:\")\n print(\" ✅ Certificate chains are valid\")\n print(\" ✅ Certificates are not revoked (OCSP)\")\n print(\" ✅ Firmware measurements match golden RIM values\")\n print(\" ✅ Hardware attestation passed\")\n print(\"=\" * 70)\n return True\n else:\n print(\"❌ VERIFICATION FAILED\")\n print(\"=\" * 70)\n print()\n print(\"This system may not have genuine Confidential Computing GPUs\")\n print(\"or CC features may not be correctly configured.\")\n print()\n print(\"Contact support for assistance.\")\n print(\"=\" * 70)\n return False\n\n except Exception as e:\n error_msg = str(e)\n\n # Known non-critical timeout after successful verification\n if (\n \"nvmlSystemSetConfComputeGpusReadyState\" in error_msg or\n \"terminal state\" in error_msg\n ):\n print()\n print(\"=\" * 70)\n print(\"✅ VERIFICATION SUCCESSFUL\")\n print(\"=\" * 70)\n print()\n print(f\"This system has {len(evidence_list)} genuine NVIDIA GPU(s)\")\n print(\"with Confidential Computing features enabled and operational.\")\n print()\n print(\"Verification completed:\")\n print(\" ✅ Certificate chains are valid\")\n print(\" ✅ Certificates are not revoked (OCSP)\")\n print(\" ✅ Firmware measurements match golden RIM values\")\n print(\" ✅ Hardware attestation passed\")\n print()\n print(\"Note: GPU ready-state configuration timed out (non-critical).\")\n print(\"=\" * 70)\n return True\n\n print()\n print(\"=\" * 70)\n print(\"❌ VERIFICATION ERROR\")\n print(\"=\" * 70)\n print(f\"Error: {error_msg}\")\n print()\n print(\"Contact support for assistance.\")\n print(\"=\" * 70)\n return False\n\nif __name__ == '__main__':\n success = main()\n sys.exit(0 if success else 1)\nEOF\n\nchmod +x ~/gpu-verification/verify_gpu.py\n6Verify the InstallationConfirm that the NVIDIA attestation packages are installed correctly.# Check that NVIDIA packages are installed\npip list | grep nv-\nExpected output:nv-attestation-sdk 2.6.3 (or higher)\nnv-local-gpu-verifier 2.6.3 (or higher)\nSetup CompleteYou have successfully installed the official NVIDIA GPU attestation tools.What you have created:\nDirectory: ~/gpu-verification/\nVirtual environment: ~/gpu-verification/venv/\nVerification script: ~/gpu-verification/verify_gpu.py\nInstalled packages: nv-attestation-sdk, nv-local-gpu-verifier\nThis setup is required only once. The verification script is now ready for repeated use whenever GPU attestation is required.\n​Running GPU Verification\nAfter completing the one-time setup, you can verify your GPUs at any time by following the steps below.\n​Quick Verification\nThis verification process will take approximately 30 seconds.\n# Connect to your virtual machine\nssh root@your-vm-ip\n\n# Navigate to the verification directory\ncd ~/gpu-verification\n\n# Activate the Python virtual environment\nsource venv/bin/activate\n\n# Run the verification script\npython3 verify_gpu.py\n\n​What Happens During Verification\nThe verification script performs the following steps automatically:\n1Generating a Cryptographic Nonce\nCreates a random 32-byte challenge value.\nEnsures attestation freshness and prevents replay attacks.\n2Collecting Evidence from GPUs\nQueries each GPU for attestation evidence (typically takes approximately 20 seconds).\nRetrieves certificate chains directly from the GPU hardware.\nCollects firmware measurements for both the driver and VBIOS.\nGathers all required cryptographic signatures.\n3Validating Attestation Evidence\nVerifies that certificate chains trace back to the NVIDIA Root Certificate Authority.\nChecks certificate revocation status using OCSP (Online Certificate Status Protocol).\nRetrieves Reference Integrity Manifests (RIMs) from NVIDIA.\nCompares runtime firmware measurements against known golden RIM values.\nValidates all cryptographic signatures to ensure integrity and authenticity.\nExpected Output (Success)======================================================================\nNVIDIA GPU Confidential Compute Verification\nUsing official NVIDIA nv-attestation-sdk\n======================================================================\n\n[1/3] Generating cryptographic nonce...\n Nonce: 6040f42cc179...\n\n[2/3] Collecting evidence from GPUs...\n This may take 20-30 seconds...\n Found 8 GPU(s) with CC support\n\n[3/3] Validating attestation evidence...\n • Verifying certificate chains\n • Checking OCSP revocation status\n • Validating firmware measurements (RIM)\n • Verifying cryptographic signatures\n\n======================================================================\n✅ VERIFICATION SUCCESSFUL\n======================================================================\n\nThis system has 8 genuine NVIDIA GPU(s)\nwith Confidential Computing features enabled and operational.\n\nVerification completed:\n ✅ Certificate chains are valid\n ✅ Certificates are not revoked (OCSP)\n ✅ Firmware measurements match golden RIM values\n ✅ Hardware attestation passed\n======================================================================\n\n​What This Proves\nWhen the output displays ✅ VERIFICATION SUCCESSFUL, you have cryptographic assurance that:\n\nAuthenticity: All GPUs are genuine NVIDIA hardware with valid certificate chains.\nIntegrity: Firmware measurements match NVIDIA’s reference values, indicating no tampering.\nConfiguration: Confidential Computing features are enabled and functioning correctly.\nTrust Chain: All certificates trace back to the NVIDIA Root Certificate Authority and have not been revoked.\n\n​Understanding Verification Results\n​Successful Verification Indicators\nYour GPUs are successfully verified when all of the following messages appear:\n\n✅ “VERIFICATION SUCCESSFUL”\n✅ “Certificate chains are valid”\n✅ “Certificates are not revoked (OCSP)”\n✅ “Firmware measurements match golden RIM values”\n✅ “Hardware attestation passed”\n\nWhat this confirms:\n\nThe GPUs are authentic NVIDIA hardware.\nFirmware is intact, unmodified, and matches NVIDIA’s reference measurements.\nConfidential Computing features are enabled and operating correctly.\nThe system is suitable for running sensitive workloads.\n\n​Failed Verification Indicators\nContact support immediately if any of the following messages appear:\n\n❌ “VERIFICATION FAILED”\n❌ “Certificate validation failed”\n❌ “RIM verification failed”\n❌ “OCSP check failed (revoked)”\n❌ “No GPUs with Confidential Computing support found”\n\nWhat this may indicate:\n\nThe hardware does not support Confidential Computing.\nThe system is misconfigured.\nNetwork connectivity issues are preventing access to OCSP or RIM services.\nA potential security issue that requires further investigation.\n\nDo not process sensitive or confidential data if verification fails.All failures should be investigated and resolved before running protected workloads.\n​Troubleshooting\nThis section outlines common issues encountered during GPU attestation and provides guidance on how to diagnose and resolve them.\nIssue: \"No GPUs with Confidential Computing Support Found\"Possible causes:\nThe virtual machine type does not support Confidential Computing.\nNVIDIA drivers are not installed or are not properly loaded.\nConfidential Computing features are not enabled at the BIOS or firmware level.\nVerify GPU presence:nvidia-smi\nExpected result:\nThe output should list NVIDIA H100 or H200 GPUs.If no GPUs are shown:\nContact support, as the virtual machine may not be provisioned with the correct hardware.Issue: Network Timeouts or Connection ErrorsPossible causes:\nFirewall rules blocking outbound HTTPS traffic to NVIDIA services.\nNo internet connectivity from the virtual machine.\nTemporary unavailability of NVIDIA attestation services.\nTest connectivity to NVIDIA services:# Test NVIDIA OCSP server\ncurl -v https://ocsp.nvidia.com\n\n# Test NVIDIA RIM service\ncurl -v https://rim.attestation.nvidia.com\nIf access is blocked:\nUpdate firewall rules to allow outbound HTTPS traffic (port 443) to the following endpoints:\nocsp.nvidia.com\nrim.attestation.nvidia.com\nIssue: Verification Takes Longer Than ExpectedNormal execution time:\nFirst run: 45–60 seconds (initial download of RIM files)\nSubsequent runs: 30–45 seconds (cached RIM files are reused)\nIf execution exceeds five minutes:\nNetwork latency may be affecting access to NVIDIA services.\nCancel the process using Ctrl + C and retry.\nIf the issue persists, contact support for further assistance.\nIssue: “ModuleNotFoundError” or Import ErrorsPossible cause:\nThe Python virtual environment is not activated.Solution:cd ~/gpu-verification\nsource venv/bin/activate # (venv) should appear in the prompt\npython3 verify_gpu.py\nIssue: Package Installation FailsPossible causes:\nNo internet connectivity during setup.\nInability to reach the PyPI repository.\nInsufficient available disk space.\nSolution:# Verify internet connectivity\nping -c 3 pypi.org\n\n# Check available disk space\ndf -h\n\n# Retry installation\ncd ~/gpu-verification\nsource venv/bin/activate\npip install --upgrade pip\npip install nv-attestation-sdk\n\n​Support\n​Getting Help\nIf you encounter issues during GPU verification, follow the steps below to diagnose and resolve the problem.\nRecommended Troubleshooting Steps\n\nReview this guide\nMost common issues and resolutions are documented in the troubleshooting section.\n\nExamine error messages carefully\nError output typically indicates the underlying cause of the failure.\n\nVerify prerequisites\nEnsure that the NVIDIA driver is installed correctly and that GPUs are visible to the system.\n\nCollect diagnostic information\nGather the following information before contacting support:\n# Capture GPU information\nnvidia-smi > gpu_info.txt\n\n# Capture verification output\npython3 verify_gpu.py 2>&1 | tee verification_output.txt\n\n# Capture installed NVIDIA package versions\npip list | grep nv- > package_versions.txt\n\n​Contact Support\nWhen reaching out for assistance, provide the Virtual machine identifier, complete error messages, and the diagnostic files listed above.\n​NVIDIA Resources\nOfficial NVIDIA Documentation\n\nGPU Attestation: https://docs.nvidia.com/attestation/\nConfidential Computing: https://docs.nvidia.com/confidential-computing/\nSDK Repository: https://github.com/NVIDIA/nvtrust\n\nNVIDIA Support Channels\n\nDeveloper Forums: https://forums.developer.nvidia.com/\nNGC Support: https://ngc.nvidia.com/support\nWas this page helpful?","tokens":3411,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791263430829,"hash":"94cf74713b1968014b6e7e70f849e55399033561"}
{"url":"https://specs.optimism.io/protocol/pectra-blob-schedule/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Pectra Blob Schedule Derivation\n\nTable of Contents\n\nIf enabled\nIf disabled (default)\nMotivation and Rationale\n\nIf enabled\nIf this hardfork is enabled (i.e. if there is a non nil hardfork activation timestamp set), the following rules apply:\nWhen setting the L1 Attributes Deposited Transaction,\nthe adoption of the Pectra blob base fee update fraction\n(see EIP-7691)\noccurs for L2 blocks with an L1 origin equal to or greater than the hard fork timestamp.\nFor L2 blocks with an L1 origin less than the hard fork timestamp, the Cancun blob base fee update fraction is used\n(see EIP-4844).\nIf disabled (default)\nIf the hardfork activation timestamp is nil, the blob base fee update rules which are active\nat any given L1 block will apply to the L1 Attributes Deposited Transaction.\nMotivation and Rationale\nDue to a consensus layer bug, OPStack chains on Holesky and Sepolia running officially released op-node software\ndid not update their blob base fee update fraction (for L1 Attributes Deposited Transaction)\nin tandem with the Prague upgrade on L1.\nThese chains, or any OPStack chain with a sequencer running\nthe buggy consensus code1 when Holesky/Sepolia activated Pectra,\nwill have an inaccurate blob base fee in the L1Block contract.\nThis optional fork is a mechanism to bring those chains back in line.\nIt is unnecessary for chains using Ethereum mainnet for L1 and running op-node\nv1.12.0\nor later before Pectra activates on L1.\nActivating by L1 origin preserves the invariant that the L1BlockInfo is constant for blocks with the same epoch.\n1\nThis is any commit before the code was fixed in aabf3fe054c5979d6a0008f26fe1a73fdf3aad9f","tokens":410,"squid":"ink-governance","role":"Council Listener","at":1791263440164,"hash":"58f5cda82bb7717ba6157f546bc6bad283e5b0e9"}
{"url":"https://api-reference.pyth.network/price-feeds/evm/updatePriceFeedsIfNecessary","domain":"api-reference.pyth.network","title":"Price Feeds | Pyth Network API Reference","text":"updatePriceFeedsIfNecessaryUpdate the on-chain price feeds using the provided updateData only if the on-chain prices are older than the valid time period.DescriptionThis method updates the on-chain price feeds using the provided updateData if the on-chain data is not sufficiently fresh.\nThe caller provides two matched arrays, priceIds and publishTimes.\nThis function applies the update if there exists an index i such that priceIds[i]'s last publishTime is before than publishTimes[i].\nCallers should typically pass publishTimes[i] to be equal to the publishTime of the corresponding price id in updateData.\nThis method is a variant of updatePriceFeeds that reduces\ngas usage when multiple callers are sending the same price updates.\nThis function requires the caller to pay a fee to perform the update. The\nrequired fee for a given set of updates can be computed by passing them to\ngetUpdateFee.\nThis method returns the transaction hash of the update transaction.\nError Response\nThe above method can return the following error response:\n\nNoFreshUpdate: The provided update is not fresh enough to apply. It means the provided publishTime is not equal to corresponding price id in updateData.\nInvalidUpdateData: The provided update data is invalid or incorrectly signed.\nInsufficientFee: The fee provided is less than the required fee. Try calling getUpdateFee to get the required fee.\nArgumentsupdateData*The price update data for the contract to verify. Fetch this data from Hermes API.priceId*The price ids to update.See all price feed IDs on the reference pagepublishTime*The timestamp for each price id that determines whether to apply the update.fee*The update fee in wei. This fee is sent as the value of the transaction.ExamplesNetworkimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n// Ethereum\naddress contractAddress = 0x4305FB66699C3B2702D4d05CF36551390A4c69C6\nIPyth pyth = IPyth(contractAddress);\n\nbytes[] memory updateData = new bytes[](1);\nupdateData[0] = /* <updateData> */;\n\nbytes32[] memory priceIds = new bytes32[](1);\npriceIds[0] = /* <priceId> */;\n\nuint64[] memory publishTimes = new uint64[](1);\npublishTimes[0] = /* <publishTime> */;\n\nuint fee = /* <fee> */;\npyth.updatePriceFeedsIfNecessary{value: fee}(updateData, priceIds, publishTimes);","tokens":581,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263442047,"hash":"0cf321dbfdd8f226c9c66a9a82bcbdce7e3f2e52"}
{"url":"https://io.net/docs/guides/clouds/confidential-compute-overview","domain":"io.net","title":"Confidential Compute - io.net","text":"​Overview\nConfidential Compute VMs on io.net provides hardware-based encryption that protects your AI data, model weights, and computations from unauthorized access, including cloud operators, administrators, or malicious actors.\nUnlike traditional cloud environments that only encrypt data at rest and in transit, Confidential Compute maintains end-to-end encryption even in memory while your workloads are running.\nThis capability is powered by Intel Trust Domain Extensions (TDX) on 5th and 6th generation Intel Xeon processors, or AMD Secure Encrypted Virtualization (SEV-SNP) on AMD EPYC processors, combined with io.net’s decentralized GPU network.\n​What Is Confidential Computing?\nConfidential Computing is a hardware-based security model that ensures your data stays encrypted even while being processed.\nUsing Trusted Execution Environments (TEEs), it creates isolated regions of memory where code and data remain protected from all external access, including the host OS, hypervisor, and cloud administrators.\n​Key Technology\n\nIntel Trust Domain Extensions (TDX): Provides per-VM encryption and isolation for workloads.\nAMD Secure Encrypted Virtualization (SEV-SNP): Provides per-VM memory encryption with integrity protection.\nNVIDIA Confidential Computing: Extends protection to the GPU, keeping model weights and activations encrypted on the accelerator.\nTrusted Execution Environments: Secure enclaves ensure no unauthorized party can read memory contents.\nHardware Attestation: Verifies the integrity of BIOS, firmware, and kernel before execution.\n\nio.net delivers the same enterprise-grade protection as Azure and Google Cloud Confidential VMs, at a fraction of the cost, with bare-metal GPU performance and no centralized dependency.\n​Why It Matters\nWhen training or running AI models on traditional hyperscalers, your data sits unencrypted in memory where it can be exposed through:\n\nInsider threats or compromised infrastructure operators\nCyberattacks targeting shared cloud environments\nGovernment subpoenas or data access requests\n\nThese risks endanger:\n\nProprietary model architectures\nCustomer PII, health records, and financial data\nSensitive inference requests revealing business logic\n\n​Key Benefits\n\nProtect Intellectual Property: Encrypt training data, model weights, and architectures during AI model development.\nEnable Secure Collaboration: Support multi-party or federated learning while keeping datasets isolated and private.\nEnsure Regulatory Compliance: Meet HIPAA, GDPR, and financial data requirements with full auditability.\nSecure Inference at Scale: Protect live prompts, responses, and intermediate model states.\nReduce Costs: Run on a decentralized GPU infrastructure, up to 90% cheaper than hyperscalers.\n\n​Getting Started\nConfidential Compute is available upon request through io.net’s managed services, supporting machines from H100 up to B200.\nTo begin using Confidential Compute on io.net:\n\nRequest Access: Submit a provisioning request by emailing business@io.net . Mention your preferred GPU type (H100, H200, or B200) and provide basic project details.\nOur specialists will reach out to understand your needs and assist with configuring the machines to your specifications.\n\nDeploy a Confidential VM: Once set up, deploy your Confidential VM using the web console or API.\n\nVerify Attestation: Before running sensitive workloads, verify your instance’s attestation report to confirm the integrity of its BIOS, firmware, and confidential computing configuration. This ensures your VM is operating in a trusted, secure state.\n\nIntegrate Seamlessly: Run workloads on Ubuntu 24.04 (LTS) with built-in confidential computing support. Existing MLOps pipelines run without modification. You can migrate existing workflows directly to io.net without changing your training or deployment code.\n\nRun Secure Workloads: Connect to your instance and deploy your AI training or inference workloads as usual. All computations, model weights, and data remain encrypted in memory throughout processing, maintaining full performance and GPU acceleration.\n\nPerformance impact is minimal and with full GPU capabilities preserved. This validates secure AI pipelines on cost-effective infrastructure.\n​Compliance and Use Cases\nConfidential Compute supports secure operations across regulated and high-risk industries:\n\nHealthcare: Train on PHI and diagnostic data securely.\nFinance: Protect trading models and risk analytics pipelines.\nLegal: Safeguard sensitive inference workloads and document data.\nDefense and Government: Maintain sovereignty over AI models and datasets.\n\nAdditionally, all workloads comply with:\n\nHIPAA (Health Insurance Portability and Accountability Act)\nGDPR (General Data Protection Regulation)\nPCI DSS (Payment Card Industry Data Security Standard)\nWas this page helpful?","tokens":1207,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791263442096,"hash":"20f38a3c83315b03501e950b007c463b3453eb0d"}
{"url":"https://specs.optimism.io/protocol/holocene/exec-engine.html","domain":"specs.optimism.io","title":"Execution Engine - OP Stack Specification","text":"L2 Execution Engine\n\nTable of Contents\n\nOverview\nTimestamp Activation\nDynamic EIP-1559 Parameters\n\nEIP-1559 Parameters in Block Header\nEIP-1559 Parameters in PayloadAttributesV3\n\nEncoding\nPayloadID computation\n\nExecution\n\nPayload Attributes Processing\nBase Fee Computation\n\nRationale\n\nOverview\nThe EIP-1559 parameters are encoded in the block header's extraData field and can be configured dynamically through\nthe SystemConfig.\nTimestamp Activation\nHolocene, like other network upgrades, is activated at a timestamp. Changes to the L2 Block execution rules are applied\nwhen the L2 Timestamp >= activation time.\nDynamic EIP-1559 Parameters\nEIP-1559 Parameters in Block Header\nWith the Holocene upgrade, the extraData header field of each block must have the following format:\nNameTypeByte Offset\nversionu8[0, 1)\ndenominatoru32 (big-endian)[1, 5)\nelasticityu32 (big-endian)[5, 9)\n\nAdditionally,\n\nversion must be 0,\ndenominator and elasticity must be non-zero,\nthere is no additional data beyond these 9 bytes.\n\nNote that extraData has a maximum capacity of 32 bytes (to fit in the L1 beacon-chain extraData data-type) and its\nformat may be modified/extended by future upgrades.\nNote also that if the chain had Holocene genesis, the genesis block must have an above-formatted extraData representing\nthe initial parameters to be used by the chain.\nEIP-1559 Parameters in PayloadAttributesV3\nThe PayloadAttributesV3\ntype is extended with an additional value, eip1559Params:\nPayloadAttributesV3: {\n timestamp: QUANTITY\n prevRandao: DATA (32 bytes)\n suggestedFeeRecipient: DATA (20 bytes)\n withdrawals: array of WithdrawalV1\n parentBeaconBlockRoot: DATA (32 bytes)\n transactions: array of DATA\n noTxPool: bool\n gasLimit: QUANTITY or null\n eip1559Params: DATA (8 bytes) or null\n}\n\nEncoding\nAt and after Holocene activation, eip1559Parameters in PayloadAttributeV3 must be exactly 8 bytes with the following\nformat:\nNameTypeByte Offset\ndenominatoru32 (big-endian)[0, 4)\nelasticityu32 (big-endian)[4, 8)\n\nPayloadID computation\nIf eip1559Params != null, the eip1559Params is included in the PayloadID hasher directly after the gasLimit\nfield.\nExecution\nPayload Attributes Processing\nPrior to Holocene activation, eip1559Parameters in PayloadAttributesV3 must be null and is otherwise considered\ninvalid.\nAt and after Holocene activation, any ExecutionPayload corresponding to some PayloadAttributesV3 must contain\nextraData formatted as the header value. The denominator and elasticity\nvalues within this extraData must correspond to those in eip1559Parameters, unless both are 0. When both are 0, the\nprior EIP-1559 constants must be used to populate extraData instead.\nBase Fee Computation\nPrior to the Holocene upgrade, the EIP-1559 denominator and elasticity parameters used to compute the block base fee\nwere constants.\nWith the Holocene upgrade, these parameters are instead determined as follows:\n\nif Holocene is not active in parent_header.timestamp, the prior EIP-1559\nconstants are used. Note that parent_header.extraData is empty\nprior to Holocene, except possibly for the genesis block.\nif Holocene is active at parent_header.timestamp, then the parameters from parent_header.extraData are used.\n\nRationale\nPlacing the EIP-1559 parameters within the L2 block header allows us to retain the purity of the function that computes\nthe next block's base fee from its parent block header, while still allowing them to be dynamically configured. Dynamic\nconfiguration is handled similarly to gasLimit, with the derivation pipeline providing the appropriate SystemConfig\ncontract values to the block builder via PayloadAttributesV3 parameters.","tokens":909,"squid":"ink-governance","role":"Council Listener","at":1791263451476,"hash":"f206e0771af01a02e3ab537f75f6aed705d3fd91"}
{"url":"https://io.net/docs/guides/clouds/confidential-compute-attestation-overview","domain":"io.net","title":"Confidential Compute Attestation - io.net","text":"​Overview\nio.net provisioned Confidential Compute VMs are equipped with NVIDIA H200 GPUs featuring hardware-based confidential computing capabilities. This guide shows you how to verify that your GPUs are genuine NVIDIA hardware with confidential computing features properly enabled.\n​Key Takeaways\n\nUnderstand why GPU verification is essential for confidential computing.\nLearn how to confirm GPU authenticity using cryptographic attestation.\nFollow clear, step-by-step instructions to run verification on your VM.\n\n​Prerequisites\n\nSSH access to your Confidential Compute VM\nPython 3.7 or later (pre-installed on your VM)\nBasic command line understanding\n5 minutes to perform the initial set up\n\n​Why does GPU verification matter?\n​Trust, but Verify\nWhen running sensitive workloads on Confidential Computing (CC) infrastructure, it is not enough to rely on a provider’s assurances. You need cryptographic proof that the hardware is authentic, correctly configured, and operating in a secure state.\nGPU attestation provides independent verification that:\n\nThe GPUs are genuine NVIDIA hardware - not counterfeit, emulated, or misrepresented.\nFirmware is intact and unmodified - ensuring no tampering with GPU software or drivers.\nConfidential computing features are enabled - confirming that CC mode is active and functioning properly.\nHardware measurements match expected “golden” values - validating that the GPU’s state aligns with NVIDIA’s reference integrity manifests.\n\n​Security and Compliance\nGPU attestation is a foundational security mechanism for confidential computing environments. It helps ensure:\n\nZero-trust architecture - trust no component by default, verify every claim cryptographically.\nRegulatory and compliance adherence - meet requirements that mandate hardware verification.\nData protection - guarantee that sensitive workloads run only on validated, trustworthy hardware.\nClear auditability - produce cryptographic evidence for stakeholders, security teams, and auditors.\n\n​How It Works\nAttestation relies on cryptographic proofs that cannot be falsified, forged or altered. The verification process follows a clear chain of checks:\nYour VM → Collect GPU Evidence → Verify Certificates\n → Check Measurements\n → Validate Signatures\n → Result: Verified or Check Failed\n\nWhat gets verified:\nDuring attestation, the following elements are validated:\n\nA four-level GPU certificate chain, traced back to the NVIDIA Root Certificate Authority.\nCertificate revocation status, checked via OCSP to ensure no certificates have been revoked.\nDriver firmware measurements, consisting of 64 SHA-384 cryptographic hashes.\nVBIOS firmware measurements, consisting of 64 SHA-384 cryptographic hashes.\nDigital signatures on all attestation evidence, ensuring integrity and authenticity.\n\n​What is GPU Attestation?\n​Cryptographic Proof of Authenticity\nGPU attestation is a cryptographic verification process rooted in hardware-based trust. It provides verifiable proof that a GPU is authentic, securely configured, and operating in a trusted state. Specifically, it validates four core properties:\n 1. Hardware Authenticity 2. Firmware Integrity 3. Configuration State 4. FreshnessEvery NVIDIA GPU that supports Confidential Computing includes:\nA unique hardware identity permanently embedded in silicon during manufacturing.\nA certificate chain signed by NVIDIA’s Root Certificate Authority.\nCryptographic keys stored in tamper-resistant hardware.\nWhat this proves:\nThe GPU is genuine NVIDIA hardware, produced by NVIDIA, and not counterfeit or emulated.During attestation, the system:\nMeasures all GPU firmware using SHA-384 cryptographic hashes.\nCompares measurements against NVIDIA’s Reference Integrity Manifests (RIMs).\nVerifies the digital signatures on the RIM files.\nWhat this proves:\nThe GPU firmware has not been modified, tampered with, or compromised.The verification process confirms that:\nConfidential Computing (CC) is enabled.\nProtected PCIe (PPCIE) is correctly configured.\nThe GPU is operating in the expected secure state.\nIn this context, CC refers to the general concept of Confidential Compute, where the GPU operates in a secure, protected environment. This is different from CC mode (also referred to as CC State), which is a specific configuration within the GPU.CC State cannot be enabled at the same time as PPCIe, the two modes are mutually exclusive.CC State specifically refers to scenarios where a single GPU (or multiple GPUs that are NOT NVLink-connected) is passed through directly to a virtual machine.What this proves:\nConfidential Computing features are actively enabled and functioning, not merely claimed.Further Reading on CC and PPCIeHow CC and Protected PCIe (PPCIe) Work TogetherGPU confidentiality is controlled through two independent mechanisms:\nCC (Confidential Compute / CC State)\nPPCIe (Protected PCIe)\nThese settings determine how and which GPUs operate in confidential mode. Each GPU can have CC and PPCIe enabled or disabled independently, but only certain combinations are valid.\n\nCC = OFF, PPCIe = OFF\nNo confidential computing is enabled.\n\nCC = ON, PPCIe = OFF\nOnly a subset of GPUs is confidential. This mode is NOT compatible with NVLink-connected GPUs.\n\nCC = OFF, PPCIe = ON\nThe entire GPU set in the server, including NVLink connected GPUs, operate in confidential mode.\nThis is the configuration used in our recommended setup.\n\nCC = ON, PPCIe = ON\nThis is an invalid configuration. The virtual machine will either fail to boot or the CUDA drivers will not load.\n\nAttestation uses a nonce (a cryptographic challenge) to:\nPrevent replay attacks.\nEnsure the evidence is current, not reused or pre-recorded.\nConfirm that measurements reflect the GPU’s current state.\nWhat this proves:\nThe attestation is happening in real time on this specific GPU.\n​Official NVIDIA Technology\nGPU attestation is performed using NVIDIA’s official tooling:\n\nPackage: nv-attestation-sdk (official NVIDIA Python SDK)\nSource: PyPI (Python Package Index)\nVersion: 2.6.3 (as of December 2025)\nLicense: Apache 2.0\nRepository: https://github.com/NVIDIA/nvtrust\n\nThis is not a third-party tool. It is NVIDIA’s production-ready attestation framework, used by enterprise customers worldwide.\n​Standards-Based Approach\nNVIDIA GPU attestation is built on widely adopted industry standards:\n\nSPDM (Security Protocol and Data Model): Version 1.1 for device authentication.\nX.509 PKI: Standard public key infrastructure for certificates.\nOCSP: Online Certificate Status Protocol for revocation checks.\nTCG standards: Trusted Computing Group measurement and attestation specifications.\n\n​Quick Reference\nOne-time setup (approximately 2–3 minutes):\nmkdir -p ~/gpu-verification && cd ~/gpu-verification\npython3 -m venv venv\nsource venv/bin/activate\npip install --upgrade pip\npip install nv-attestation-sdk\n# Create the verify_gpu.py script (refer to Step 5 of the GPU Attestation and Verification Guide)\n\nRun verification (approximately 30 seconds):\ncd ~/gpu-verification\nsource venv/bin/activate\npython3 verify_gpu.py\n\nSuccessful verification output:\n✅ VERIFICATION SUCCESSFUL\nThis system has X genuine NVIDIA GPU(s)\nwith Confidential Computing features enabled and operational.\n\nFor a more comprehensive guide for verifying your Confidential Compute VM, refer to the GPU Attestation and Verification Guide.\n​Key Points\n\nOfficial NVIDIA tooling - uses the NVIDIA-provided nv-attestation-sdk.\nCryptographic assurance - verification cannot be forged or bypassed.\nComprehensive validation - certificates, firmware measurements, and signatures are all verified.\nFast execution - completes in approximately 30 seconds after initial setup.\nSelf-contained operation - runs entirely within the virtual machine without external accounts.\n\n​Next Steps\n\nComplete the one-time setup.\nRun GPU verification on the virtual machine.\nIntegrate verification into the security or deployment workflow.\nPerform verification before processing sensitive workloads.\nContact support if verification fails.\n\n​FAQs\nHow often should verification be performed?Recommended frequency:\nDaily: Before processing sensitive or regulated workloads.\nAfter system changes: Following any reboot, update, or migration.\nInitial provisioning: When the virtual machine is first received.\nCompliance requirements: As dictated by organizational security policies.\nWhy regular verification is important:\nDetects firmware tampering or unauthorized modification.\nConfirms that Confidential Computing features remain enabled after updates.\nProvides a verifiable audit trail for compliance and governance.\nCan verification be automated?Yes. Verification can be integrated into startup or pre-workload scripts.#!/bin/bash\n# Example: Run verification before starting an application\n\ncd ~/gpu-verification\nsource venv/bin/activate\npython3 verify_gpu.py\n\nif [ $? -eq 0 ]; then\n echo \"✅ Verification passed. Starting workload.\"\n # Insert application startup commands here\nelse\n echo \"❌ Verification failed. Aborting startup.\"\n exit 1\nfi\nDoes verification impact GPU performance?No. Verification:\nRuns independently of GPU compute workloads.\nTypically completes within 30–60 seconds.\nDoes not interfere with running applications.\nCan be executed while GPUs are performing other tasks.\nWhat should I do if verification fails?Immediate steps to follow:\nRetry the verification once, as failures may be caused by transient network issues.\nReview system logs using journalctl -xe.\nConfirm that the NVIDIA driver is installed and functioning using nvidia-smi.\nContact support and provide complete error messages and output.\nSensitive or confidential data should not be processed until verification succeeds.Is this the same verification NVIDIA uses?Yes. This verification process uses:\nThe official NVIDIA Python SDK (nv-attestation-sdk).\nThe same verification logic used by NVIDIA enterprise customers.\nReference Integrity Manifests and certificate chains served directly by NVIDIA.\nIndustry-standard cryptographic validation mechanisms.\nThis is not a third-party tool. It is NVIDIA’s official, production-grade attestation solution.What exactly is verified?The verification process validates the following components:Hardware\nThe GPU is genuine NVIDIA hardware, verified through a certificate chain to the NVIDIA Root Certificate Authority.\nThe hardware identity matches the issued certificates.\nCertificates have not been revoked, as verified through OCSP.\nFirmware\nDriver firmware measurements (64 SHA-384 cryptographic hashes).\nVBIOS firmware measurements (64 SHA-384 cryptographic hashes).\nMeasurements match NVIDIA’s reference “golden” RIM values.\nAll firmware and measurement signatures are cryptographically valid.\nConfiguration\nConfidential Computing mode is enabled.\nProtected PCIe (PPCIE) is correctly configured.\nThe GPU ready state is operational.\nCan verification results be falsified?No. Verification is based on strong cryptographic guarantees, including:\nA hardware root of trust, with cryptographic keys embedded in tamper-resistant silicon.\nCertificate chains signed by NVIDIA’s Root Certificate Authority, protected by NVIDIA’s private keys.\nCryptographic signatures that cannot be forged without NVIDIA’s private keys.\nFresh nonces that prevent replay of previously captured attestation results.\nEven if the operating system is fully compromised, an attacker cannot:\nForge NVIDIA’s digital signatures.\nCreate certificates that successfully validate against the NVIDIA Root CA.\nModify firmware measurements without detection.\nBypass the hardware root of trust.\nWhat does verification not prove?GPU attestation verifies GPU authenticity and configuration, but it DOES NOT validate:\nHypervisor security or configuration.\nHost operating system security.\nNetwork isolation between virtual machines.\nPhysical datacenter security.\nGuest operating system security within the VM.\nFor comprehensive protection:\nGPU attestation should be used as part of a defense-in-depth security strategy.How do I verify the verification tool itself?The verification tooling can be independently validated through the following means:\n\nOfficial NVIDIA package distribution: Published on PyPI\npip show nv-attestation-sdk\n# Displays: nv-attestation-sdk 2.6.3\n\nOpen-source implementation: Publicly available for review\nRepository: https://github.com/NVIDIA/nvtrust\n\nPackage signing: Signed and distributed by NVIDIA\npip show --verbose nv-attestation-sdk\n\nChecksum verification: Validate package integrity\npip hash nv-attestation-sdk\n\nWhy does the CC State show as OFF when I check my onboarded node?This is expected for nodes with NVLink-connected GPUs. CC State is only used when individual GPUs (or non-NVLink GPUs) are passed into a VM. Because NVLink-connected GPUs must be passed through as a complete set, CC State remains OFF.For these nodes, confidentiality is provided through Protected PCIe, not CC State. You can confirm this by checking:\nMulti-GPU Mode: Protected PCIe → GPUs are running in confidential mode.\nCPU CC Capabilities: INTEL TDX → CPU is running in confidential mode.\nWas this page helpful?","tokens":3269,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791263454513,"hash":"f0e972085189565f1875626b0b6fb771fc8b3152"}
{"url":"https://api-reference.pyth.network/price-feeds/evm/getUpdateFee","domain":"api-reference.pyth.network","title":"Price Feeds | Pyth Network API Reference","text":"getUpdateFeeGet the fee required to update the on-chain price feeds with the provided updateData.DescriptionThis method returns the fee required to update the on-chain price feeds for the given updateData.\nThe fee returned is in wei.\nThe caller should send the returned fee amount as the transaction value when calling updatePriceFeeds.\nThe updateData can be retrieved from the Hermes API.ArgumentsupdateData*The price updates that you would like to submit to updatePriceFeeds. Fetch this data from Hermes API.ExamplesNetworkimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n// Ethereum\naddress contractAddress = 0x4305FB66699C3B2702D4d05CF36551390A4c69C6\nIPyth pyth = IPyth(contractAddress);\n\nbytes[] memory updateData = new bytes[](1);\nupdateData[0] = /* <updateData> */;\nuint feeAmount = pyth.getUpdateFee(updateData);","tokens":220,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263455826,"hash":"977309904879b6f315c69921ae9c37b8d05030e1"}
{"url":"https://specs.optimism.io/protocol/isthmus/predeploys.html","domain":"specs.optimism.io","title":"Predeploys - OP Stack Specification","text":"Predeploys\n\nTable of Contents\n\nOverview\n\nL1Block\n\nInterface\n\nsetIsthmus\n\nGasPriceOracle\nOperatorFeeVault\n\nSecurity Considerations\n\nOverview\nL1Block\nInterface\nsetIsthmus\nThis function is meant to be called once on the activation block of the Isthmus network upgrade.\nIt MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call\ncall each getter for the network specific config and set the returndata into storage.\nGasPriceOracle\nFollowing the Isthmus upgrade, a new method is introduced: getOperatorFee(uint256). This method\nreturns the operator fee for the given gasUsed. The operator fee calculation follows the formula\noutlined in the Operator Fee section of the execution engine spec.\nThe value returned by getOperatorFee(uint256) is capped at U256 max value.\nOperatorFeeVault\nThis vault implements FeeVault, like BaseFeeVault, SequencerFeeVault, and L1FeeVault.\nNo special logic is needed in order to insert or withdraw funds.\nIts address will be 0x420000000000000000000000000000000000001b.\nSee also Fee Vaults.\nSecurity Considerations","tokens":267,"squid":"ink-governance","role":"Council Listener","at":1791263463775,"hash":"ac141b54bb72ba3fea52655cb48bbb662b4c3741"}
{"url":"https://specs.optimism.io/protocol/isthmus/l1-attributes.html","domain":"specs.optimism.io","title":"L1 Attributes - OP Stack Specification","text":"L1 Block Attributes\n\nTable of Contents\n\nOverview\n\nOverview\nThe L1 block attributes transaction is updated to include the operator fee parameters.\nInput argTypeCalldata bytesSegment\n{0x098999be}0-3n/a\nbaseFeeScalaruint324-71\nblobBaseFeeScalaruint328-11\nsequenceNumberuint6412-19\nl1BlockTimestampuint6420-27\nl1BlockNumberuint6428-35\nbasefeeuint25636-672\nblobBaseFeeuint25668-993\nl1BlockHashbytes32100-1314\nbatcherHashbytes32132-1635\noperatorFeeScalaruint32164-1676\noperatorFeeConstantuint64168-175\n\nNote that the first input argument, in the same pattern as previous versions of the L1 attributes transaction,\nis the function selector: the first four bytes of keccak256(\"setL1BlockValuesIsthmus()\").\nIn the activation block, there are two possibilities:\n\nIf Isthmus is active at genesis, there are no transactions in the activation block\nand therefore no L1 Block Attributes transaction to consider.\nIf Isthmus activates after genesis setL1BlockValuesEcotone()\nmethod must be used. This is because the L1 Block contract will not yet have been upgraded.\n\nIn each subsequent L2 block, the setL1BlockValuesIsthmus() method must be used.\nWhen using this method, the pre-Isthmus values are migrated over 1:1\nand the transaction also sets the following new attributes to the values\nfrom the SystemConfig:\n\noperatorFeeScalar\noperatorFeeConstant","tokens":334,"squid":"ink-governance","role":"Council Listener","at":1791263480843,"hash":"3485969f5539eb119197484d62c1e8069455a7f4"}
{"url":"https://api-reference.pyth.network/price-feeds/evm/parsePriceFeedUpdates","domain":"api-reference.pyth.network","title":"Price Feeds | Pyth Network API Reference","text":"parsePriceFeedUpdatesParse updateData to return prices if the prices are published within the given time range.DescriptionThis method parse updateData and return the price feeds for the given priceIds\nwithin, if they are all published between minPublishTime and\nmaxPublishTime (minPublishTime <= publishTime <= maxPublishTime).\nUse this function if you want to use a Pyth price for a fixed time and not the most\nrecent price; otherwise, consider using updatePriceFeeds\nfollowed by getPriceNoOlderThan or one of its variants.\nUnlike updatePriceFeeds, calling this function will not update the on-chain price.\nIf you need to make sure the price update is the earliest update after the\nminPublishTime consider using\nparsePriceFeedUpdatesUnique.\nThis method requires the caller to pay a fee in wei; the required fee can be\ncomputed by calling getUpdateFee with updateData.\nError Response\nThe above method can return the following error response:\n\nPriceFeedNotFoundWithinRange: No price feed was found within the given time range.\nInvalidUpdateData: The provided update data is invalid or incorrectly signed.\nInsufficientFee: The fee provided is less than the required fee. Try calling getUpdateFee to get the required fee.\nArgumentsupdateData*The price update data for the contract to verify. Fetch this data from Hermes API.priceId*The price ids whose feeds will be returned.See all price feed IDs on the reference pageminPublishTime*The minimum timestamp for each returned feed.maxPublishTime*The maximum timestamp for each returned feed.fee*The update fee in wei. This fee is sent as the value of the transaction.ExamplesNetworkimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n// Ethereum\naddress contractAddress = 0x4305FB66699C3B2702D4d05CF36551390A4c69C6\nIPyth pyth = IPyth(contractAddress);\n\nbytes[] memory updateData = new bytes[](1);\nupdateData[0] = /* <updateData> */;\n\nbytes32[] memory priceIds = new bytes32[](1);\npriceIds[0] = /* <priceId> */;\n\nuint64 minPublishTime = /* <minPublishTime> */;\nuint64 maxPublishTime = /* <maxPublishTime> */;\n\nuint fee = /* <fee> */;\npyth.parsePriceFeedUpdates{value: fee}(updateData, priceIds, minPublishTime, maxPublishTime);","tokens":557,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263498455,"hash":"d78397abaa8e81965fe56747cc0fe47bf13cafa0"}
{"url":"https://specs.optimism.io/protocol/jovian/system-config.html","domain":"specs.optimism.io","title":"System Config - OP Stack Specification","text":"Jovian: System Config\n\nTable of Contents\n\nMinimum Base Fee Configuration\n\nConfigUpdate\nInitialization\nModifying Minimum Base Fee\nInterface\n\nMinimum Base Fee Parameters\n\nminBaseFee\n\nDA Footprint Configuration\n\nConfigUpdate\nModifying DA Footprint Gas Scalar\nInterface\n\nDA Footprint Gas Scalar Parameters\n\ndaFootprintGasScalar\n\nMinimum Base Fee Configuration\nJovian adds a configuration value to SystemConfig to control the minimum base fee used by the EIP-1559 fee market\non OP Stack chains. The value is a minimum base fee in wei.\nNameTypeDefaultMeaning\nminBaseFeeuint640Minimum base fee in wei\n\nThe configuration is updated via a new method on SystemConfig:\nfunction setMinBaseFee(uint64 minBaseFee) external onlyOwner;\n\nConfigUpdate\nWhen the configuration is updated, a ConfigUpdate event\nMUST be emitted with the following parameters:\nversionupdateTypedataUsage\nuint256(0)uint8(6)abi.encode(uint64(_minBaseFee))Modifies the minimum base fee (wei)\n\nInitialization\nThe following actions should happen during the initialization of the SystemConfig:\n\nemit ConfigUpdate.BATCHER\nemit ConfigUpdate.FEE_SCALARS\nemit ConfigUpdate.GAS_LIMIT\nemit ConfigUpdate.UNSAFE_BLOCK_SIGNER\n\nIntentionally absent from this is emit ConfigUpdate.EIP_1559_PARAMS and emit ConfigUpdate.MIN_BASE_FEE.\nAs long as these values are unset, the default values will be used.\nRequiring these parameters to be set during initialization would add a strict requirement\nthat the L2 hardforks before the L1 contracts are upgraded, and this is complicated to manage in a\nworld of many chains.\nModifying Minimum Base Fee\nUpon update, the contract emits the ConfigUpdate event above, enabling nodes\nto derive the configuration from L1 logs.\nImplementations MUST incorporate the configured value into the block header extraData as specified in\n./exec-engine.md. Until the first such event is emitted, a default value of 0 should be used.\nInterface\nMinimum Base Fee Parameters\nminBaseFee\nThis function returns the currently configured minimum base fee in wei.\nfunction minBaseFee() external view returns (uint64);\n\nDA Footprint Configuration\nJovian adds a uint16 configuration value to SystemConfig to control the daFootprintGasScalar.\nThe configuration is updated via a new method on SystemConfig:\nfunction setDAFootprintGasScalar(uint16 daFootprintGasScalar) external onlyOwner;\n\nConfigUpdate\nWhen the configuration is updated, a ConfigUpdate event\nMUST be emitted with the following parameters:\nversionupdateTypedataUsage\nuint256(0)uint8(7)abi.encode(uint16(_daFootprintGasScalar))Modifies the DA footprint gas scalar\n\nModifying DA Footprint Gas Scalar\nUpon update, the contract emits the ConfigUpdate event above, enabling nodes\nto derive the configuration from L1 logs.\nInterface\nDA Footprint Gas Scalar Parameters\ndaFootprintGasScalar\nThis function returns the currently configured DA footprint gas scalar.\nfunction daFootprintGasScalar() external view returns (uint16);","tokens":734,"squid":"ink-governance","role":"Council Listener","at":1791263502625,"hash":"6a59df8ee7032b5b26acc91883473fecd3257d80"}
{"url":"https://docs.soliditylang.org/en/develop/internals/optimizer.html","domain":"docs.soliditylang.org","title":"The Optimizer — Solidity 0.8.38-develop documentation","text":"The Optimizer\n\n Edit on GitHub\n\nThe Optimizer\nThe Solidity compiler involves optimizations at three different levels (in order of execution):\n\nOptimizations during code generation based on a direct analysis of Solidity code.\nOptimizing transformations on the Yul IR code.\nOptimizations at the opcode level.\n\nThe opcode-based optimizer applies a set of simplification rules\nto opcodes. It also combines equal code sets and removes unused code.\nThe Yul-based optimizer is much more powerful, because it can work across function\ncalls. For example, arbitrary jumps are not possible in Yul, so it is\npossible to compute the side-effects of each function. Consider two function calls,\nwhere the first does not modify storage and the second does modify storage.\nIf their arguments and return values do not depend on each other, we can reorder\nthe function calls. Similarly, if a function is\nside-effect free and its result is multiplied by zero, you can remove the function\ncall completely.\nThe codegen-based optimizer affects the initial low-level code produced from the Solidity input.\nIn the legacy pipeline, the bytecode is generated immediately and most of the optimizations of this\nkind are implicit and not configurable, the only exception being an optimization which changes the\norder of literals in binary operations.\nThe IR-based pipeline takes a different approach and produces Yul IR closely matching the structure\nof the Solidity code, with nearly all optimizations deferred to the Yul optimizer module.\nIn that case codegen-level optimization is done only in very limited cases which are difficult to\nhandle in Yul IR, but are straightforward with the high-level information from analysis phase at hand.\nAn example of such an optimization is the bypass of checked arithmetic when incrementing the counter\nin certain idiomatic for loops.\nCurrently, the parameter --optimize activates the opcode-based optimizer for the\ngenerated bytecode and the Yul optimizer for the Yul code generated internally, for example for ABI coder v2.\nOne can use solc --ir-optimized --optimize to produce an\noptimized Yul IR for a Solidity source. Similarly, one can use solc --strict-assembly --optimize\nfor a stand-alone Yul mode.\n\nNote\nSome optimizer steps, such as, for example, the peephole optimizer\nand the unchecked loop increment optimizer are always\nenabled by default and can only be turned off via the Standard JSON.\n\nNote\nAn empty optimizer sequence, i.e :, is accepted even without --optimize in order to fully disable\nthe user-supplied portion of the Yul optimizer sequence, as by default,\neven when the optimizer is not turned on, the unused pruner step will be run.\n\nYou can find more details on both optimizer modules and their optimization steps below.\n\nBenefits of Optimizing Solidity Code\nOverall, the optimizer tries to simplify complicated expressions, which reduces both code\nsize and execution cost, i.e., it can reduce gas needed for contract deployment as well as for external calls made to the contract.\nIt also specializes or inlines functions. Especially\nfunction inlining is an operation that can cause much bigger code, but it is\noften done because it results in opportunities for more simplifications.\n\nDifferences between Optimized and Non-Optimized Code\nGenerally, the most visible difference is that constant expressions are evaluated at compile time.\nWhen it comes to the ASM output, one can also notice a reduction of equivalent or duplicate\ncode blocks (compare the output of the flags --asm and --asm --optimize). However,\nwhen it comes to the Yul/intermediate-representation, there can be significant\ndifferences, for example, functions may be inlined, combined, or rewritten to eliminate\nredundancies, etc. (compare the output between the flags --ir and\n--optimize --ir-optimized).\n\nOptimizer Parameter Runs\nThe number of runs (--optimize-runs) specifies roughly how often each opcode of the\ndeployed code will be executed across the life-time of the contract. This means it is a\ntrade-off parameter between code size (deploy cost) and code execution cost (cost after deployment).\nA “runs” parameter of “1” will produce short but expensive code. In contrast, a larger “runs”\nparameter will produce longer but more gas efficient code. The maximum value of the parameter\nis 2**32-1.\n\nNote\nA common misconception is that this parameter specifies the number of iterations of the optimizer.\nThis is not true: The optimizer will always run as many times as it can still improve the code.\n\nOpcode-Based Optimizer Module\nThe opcode-based optimizer module operates on assembly code. It splits the\nsequence of instructions into basic blocks at JUMPs and JUMPDESTs.\nInside these blocks, the optimizer analyzes the instructions and records every modification to the stack,\nmemory, or storage as an expression which consists of an instruction and\na list of arguments which are pointers to other expressions.\nAdditionally, the opcode-based optimizer\nuses a component called “CommonSubexpressionEliminator” that, amongst other\ntasks, finds expressions that are always equal (on every input) and combines\nthem into an expression class. It first tries to find each new\nexpression in a list of already known expressions. If no such matches are found,\nit simplifies the expression according to rules like\nconstant + constant = sum_of_constants or X * 1 = X. Since this is\na recursive process, we can also apply the latter rule if the second factor\nis a more complex expression which we know always evaluates to one.\nCertain optimizer steps symbolically track the storage and memory locations. For example, this\ninformation is used to compute Keccak-256 hashes that can be evaluated during compile time. Consider\nthe sequence:\nPUSH 32\nPUSH 0\nCALLDATALOAD\nPUSH 100\nDUP2\nMSTORE\nKECCAK256\n\nor the equivalent Yul\nopen in Remix\nlet x := calldataload(0)\nmstore(x, 100)\nlet value := keccak256(x, 32)\n\nIn this case, the optimizer tracks the value at a memory location calldataload(0) and then\nrealizes that the Keccak-256 hash can be evaluated at compile time. This only works if there is no\nother instruction that modifies memory between the mstore and keccak256. So if there is an\ninstruction that writes to memory (or storage), then we need to erase the knowledge of the current\nmemory (or storage). There is, however, an exception to this erasing, when we can easily see that\nthe instruction doesn’t write to a certain location.\nFor example,\nopen in Remix\nlet x := calldataload(0)\nmstore(x, 100)\n// Current knowledge memory location x -> 100\nlet y := add(x, 32)\n// Does not clear the knowledge that x -> 100, since y does not write to [x, x + 32)\nmstore(y, 200)\n// This Keccak-256 can now be evaluated\nlet value := keccak256(x, 32)\n\nTherefore, modifications to storage and memory locations, of say location l, must erase\nknowledge about storage or memory locations which may be equal to l. More specifically, for\nstorage, the optimizer has to erase all knowledge of symbolic locations, that may be equal to l\nand for memory, the optimizer has to erase all knowledge of symbolic locations that may not be at\nleast 32 bytes away. If m denotes an arbitrary location, then this decision on erasure is done\nby computing the value sub(l, m). For storage, if this value evaluates to a literal that is\nnon-zero, then the knowledge about m will be kept. For memory, if the value evaluates to a\nliteral that is between 32 and 2**256 - 32, then the knowledge about m will be kept. In\nall other cases, the knowledge about m will be erased.\nAfter this process, we know which expressions have to be on the stack at\nthe end, and have a list of modifications to memory and storage. This information\nis stored together with the basic blocks and is used to link them. Furthermore,\nknowledge about the stack, storage and memory configuration is forwarded to\nthe next block(s).\nIf we know the targets of all JUMP and JUMPI instructions,\nwe can build a complete control flow graph of the program. If there is only\none target we do not know (this can happen as in principle, jump targets can\nbe computed from inputs), we have to erase all knowledge about the input state\nof a block as it can be the target of the unknown JUMP. If the opcode-based\noptimizer module finds a JUMPI whose condition evaluates to a constant, it transforms it\nto an unconditional jump.\nAs the last step, the code in each block is re-generated. The optimizer creates\na dependency graph from the expressions on the stack at the end of the block,\nand it drops every operation that is not part of this graph. It generates code\nthat applies the modifications to memory and storage in the order they were\nmade in the original code (dropping modifications which were found not to be\nneeded). Finally, it generates all values that are required to be on the\nstack in the correct place.\nThese steps are applied to each basic block and the newly generated code\nis used as replacement if it is smaller. If a basic block is split at a\nJUMPI and during the analysis, the condition evaluates to a constant,\nthe JUMPI is replaced based on the value of the constant. Thus code like\nopen in Remix\nuint x = 7;\ndata[7] = 9;\nif (data[x] != x + 2) // this condition is never true\n return 2;\nelse\n return 1;\n\nsimplifies to this:\nopen in Remix\ndata[7] = 9;\nreturn 1;\n\nSimple Inlining\nSince Solidity version 0.8.2, there is another optimizer step that replaces certain\njumps to blocks containing “simple” instructions ending with a “jump” by a copy of these instructions.\nThis corresponds to inlining of simple, small Solidity or Yul functions. In particular, the sequence\nPUSHTAG(tag) JUMP may be replaced, whenever the JUMP is marked as jump “into” a\nfunction and behind tag there is a basic block (as described above for the\n“CommonSubexpressionEliminator”) that ends in another JUMP which is marked as a jump\n“out of” a function.\nIn particular, consider the following prototypical example of assembly generated for a\ncall to an internal Solidity function:\n tag_return\n tag_f\n jump // in\ntag_return:\n ...opcodes after call to f...\n\ntag_f:\n ...body of function f...\n jump // out\n\nAs long as the body of the function is a continuous basic block, the “Inliner” can replace tag_f jump by\nthe block at tag_f resulting in:\n tag_return\n ...body of function f...\n jump\ntag_return:\n ...opcodes after call to f...\n\ntag_f:\n ...body of function f...\n jump // out\n\nNow ideally, the other optimizer steps described above will result in the return tag push being moved\ntowards the remaining jump resulting in:\n ...body of function f...\n tag_return\n jump\ntag_return:\n ...opcodes after call to f...\n\ntag_f:\n ...body of function f...\n jump // out\n\nIn this situation the “PeepholeOptimizer” will remove the return jump. Ideally, all of this can be done\nfor all references to tag_f leaving it unused, s.t. it can be removed, yielding:\n...body of function f...\n...opcodes after call to f...\n\nSo the call to function f is inlined and the original definition of f can be removed.\nInlining like this is attempted, whenever a heuristics suggests that inlining is cheaper over the lifetime of a\ncontract than not inlining. This heuristics depends on the size of the function body, the\nnumber of other references to its tag (approximating the number of calls to the function) and\nthe expected number of executions of the contract (the global optimizer parameter “runs”).\n\nYul-Based Optimizer Module\nThe Yul-based optimizer consists of several stages and components that all transform\nthe AST in a semantically equivalent way. The goal is to end up either with code\nthat is shorter or at least only marginally longer but will allow further\noptimization steps.\n\nWarning\nSince the optimizer is under heavy development, the information here might be outdated.\nIf you rely on a certain functionality, please reach out to the team directly.\n\nThe optimizer currently follows a purely greedy strategy and does not do any\nbacktracking.\nAll components of the Yul-based optimizer module are explained below.\nThe following transformation steps are the main components:\n\nSSATransform\nCommonSubexpressionEliminator\nExpressionSimplifier\nUnusedAssignEliminator\nFullInliner\n\nOptimizer Steps\nThis is a list of all steps the Yul-based optimizer sorted alphabetically. You can find more information\non the individual steps and their sequence below.\n\nAbbreviation\nFull name\n\nf\nBlockFlattener\n\nl\nCircularReferencesPruner\n\nc\nCommonSubexpressionEliminator\n\nC\nConditionalSimplifier\n\nU\nConditionalUnsimplifier\n\nn\nControlFlowSimplifier\n\nD\nDeadCodeEliminator\n\nE\nEqualStoreEliminator\n\nv\nEquivalentFunctionCombiner\n\ne\nExpressionInliner\n\nj\nExpressionJoiner\n\ns\nExpressionSimplifier\n\nx\nExpressionSplitter\n\nI\nForLoopConditionIntoBody\n\nO\nForLoopConditionOutOfBody\n\no\nForLoopInitRewriter\n\ni\nFullInliner\n\ng\nFunctionGrouper\n\nh\nFunctionHoister\n\nF\nFunctionSpecializer\n\nT\nLiteralRematerialiser\n\nL\nLoadResolver\n\nM\nLoopInvariantCodeMotion\n\nm\nRematerialiser\n\nV\nSSAReverser\n\na\nSSATransform\n\nt\nStructuralSimplifier\n\nr\nUnusedAssignEliminator\n\np\nUnusedFunctionParameterPruner\n\nS\nUnusedStoreEliminator\n\nu\nUnusedPruner\n\nd\nVarDeclInitializer\n\nSome steps depend on properties ensured by BlockFlattener, FunctionGrouper, ForLoopInitRewriter.\nFor this reason the Yul optimizer always applies them before applying any steps supplied by the user.\n\nSelecting Optimizations\nBy default the optimizer applies its predefined sequence of optimization steps to the generated assembly.\nYou can override this sequence and supply your own using the --yul-optimizations option:\nsolc --optimize --ir-optimized --yul-optimizations 'dhfoD[xarrscLMcCTU]uljmul:fDnTOcmu'\n\nThe order of steps is significant and affects the quality of the output.\nMoreover, applying a step may uncover new optimization opportunities for others that were already applied,\nso repeating steps is often beneficial.\nThe sequence inside [...] will be applied multiple times in a loop until the Yul code\nremains unchanged or until the maximum number of rounds (currently 12) has been reached.\nBrackets ([]) may be used multiple times in a sequence, but can not be nested.\nAn important thing to note, is that there are some hardcoded steps that are always run before and after the\nuser-supplied sequence, or the default sequence if one was not supplied by the user.\nThe cleanup sequence delimiter : is optional, and is used to supply a custom cleanup sequence\nin order to replace the default one. If omitted, the optimizer will simply apply the default cleanup\nsequence. In addition, the delimiter may be placed at the beginning of the user-supplied sequence,\nwhich will result in the optimization sequence being empty, whereas conversely, if placed at the end of\nthe sequence, will be treated as an empty cleanup sequence.\n\nPreprocessing\nThe preprocessing components perform transformations to get the program\ninto a certain normal form that is easier to work with. This normal\nform is kept during the rest of the optimization process.\n\nDisambiguator\nThe disambiguator takes an AST and returns a fresh copy where all identifiers have\nunique names in the input AST. This is a prerequisite for all other optimizer stages.\nOne of the benefits is that identifier lookup does not need to take scopes into account\nwhich simplifies the analysis needed for other steps.\nAll subsequent stages have the property that all names stay unique. This means if\na new identifier needs to be introduced, a new unique name is generated.\n\nFunctionHoister\nThe function hoister moves all function definitions to the end of the topmost block. This is\na semantically equivalent transformation as long as it is performed after the\ndisambiguation stage. The reason is that moving a definition to a higher-level block cannot decrease\nits visibility and it is impossible to reference variables defined in a different function.\nThe benefit of this stage is that function definitions can be looked up more easily\nand functions can be optimized in isolation without having to traverse the AST completely.\n\nFunctionGrouper\nThe function grouper has to be applied after the Disambiguator and the FunctionHoister.\nIts effect is that all topmost elements that are not function definitions are moved\ninto a single block which is the first statement of the root block.\nAfter this step, a program has the following normal form:\n{ I F... }\n\nWhere I is a (potentially empty) block that does not contain any function definitions (not even recursively)\nand F is a list of function definitions such that no function contains a function definition.\nThe benefit of this stage is that we always know where the list of functions begins.\n\nForLoopConditionIntoBody\nThis transformation moves the loop-iteration condition of a for loop into loop body.\nWe need this transformation because ExpressionSplitter will not\napply to iteration condition expressions (the C in the following example).\nfor { Init... } C { Post... } {\n Body...\n}\n\nis transformed to\nfor { Init... } 1 { Post... } {\n if iszero(C) { break }\n Body...\n}\n\nThis transformation can also be useful when paired with LoopInvariantCodeMotion, since\ninvariants in the loop-invariant conditions can then be taken outside the loop.\n\nForLoopInitRewriter\nThis transformation moves the initialization part of a for loop to before\nthe loop:\nfor { Init... } C { Post... } {\n Body...\n}\n\nis transformed to\nInit...\nfor {} C { Post... } {\n Body...\n}\n\nThis eases the rest of the optimization process because we can ignore\nthe complicated scoping rules of the for loop initialization block.\n\nVarDeclInitializer\nThis step rewrites variable declarations so that all of them are initialized.\nDeclarations like let x, y are split into multiple declaration statements.\nOnly supports initializing with the zero literal for now.\n\nPseudo-SSA Transformation\nThe purpose of this components is to get the program into a longer form,\nso that other components can more easily work with it. The final representation\nwill be similar to a static-single-assignment (SSA) form, with the difference\nthat it does not make use of explicit “phi” functions which combines the values\nfrom different branches of control flow because such a feature does not exist\nin the Yul language. Instead, when control flow merges, if a variable is re-assigned\nin one of the branches, a new SSA variable is declared to hold its current value,\nso that the following expressions still only need to reference SSA variables.\nAn example transformation is the following:\nopen in Remix\n{\n let a := calldataload(0)\n let b := calldataload(0x20)\n if gt(a, 0) {\n b := mul(b, 0x20)\n }\n a := add(a, 1)\n sstore(a, add(b, 0x20))\n}\n\nWhen all the following transformation steps are applied, the program will look\nas follows:\nopen in Remix\n{\n let _1 := 0\n let a_9 := calldataload(_1)\n let a := a_9\n let _2 := 0x20\n let b_10 := calldataload(_2)\n let b := b_10\n let _3 := 0\n let _4 := gt(a_9, _3)\n if _4\n {\n let _5 := 0x20\n let b_11 := mul(b_10, _5)\n b := b_11\n }\n let b_12 := b\n let _6 := 1\n let a_13 := add(a_9, _6)\n let _7 := 0x20\n let _8 := add(b_12, _7)\n sstore(a_13, _8)\n}\n\nNote that the only variable that is re-assigned in this snippet is b.\nThis re-assignment cannot be avoided because b has different values\ndepending on the control flow. All other variables never change their\nvalue once they are defined. The advantage of this property is that\nvariables can be freely moved around and references to them\ncan be exchanged by their initial value (and vice-versa),\nas long as these values are still valid in the new context.\nOf course, the code here is far from being optimized. To the contrary, it is much\nlonger. The hope is that this code will be easier to work with and furthermore,\nthere are optimizer steps that undo these changes and make the code more\ncompact again at the end.\n\nExpressionSplitter\nThe expression splitter turns expressions like add(mload(0x123), mul(mload(0x456), 0x20))\ninto a sequence of declarations of unique variables that are assigned sub-expressions\nof that expression so that each function call has only variables\nas arguments.\nThe above would be transformed into\nopen in Remix\n{\n let _1 := 0x20\n let _2 := 0x456\n let _3 := mload(_2)\n let _4 := mul(_3, _1)\n let _5 := 0x123\n let _6 := mload(_5)\n let z := add(_6, _4)\n}\n\nNote that this transformation does not change the order of opcodes or function calls.\nIt is not applied to loop iteration-condition, because the loop control flow does not allow\nthis “outlining” of the inner expressions in all cases. We can sidestep this limitation by applying\nForLoopConditionIntoBody to move the iteration condition into loop body.\nThe final program should be in an expression-split form, where (with the exception of loop conditions)\nfunction calls cannot appear nested inside expressions\nand all function call arguments have to be variables.\nThe benefits of this form are that it is much easier to re-order the sequence of opcodes\nand it is also easier to perform function call inlining. Furthermore, it is simpler\nto replace individual parts of expressions or re-organize the “expression tree”.\nThe drawback is that such code is much harder to read for humans.\n\nSSATransform\nThis stage tries to replace repeated assignments to\nexisting variables by declarations of new variables as much as\npossible.\nThe reassignments are still there, but all references to the\nreassigned variables are replaced by the newly declared variables.\nExample:\nopen in Remix\n{\n let a := 1\n mstore(a, 2)\n a := 3\n}\n\nis transformed to\nopen in Remix\n{\n let a_1 := 1\n let a := a_1\n mstore(a_1, 2)\n let a_3 := 3\n a := a_3\n}\n\nExact semantics:\nFor any variable a that is assigned to somewhere in the code\n(variables that are declared with value and never re-assigned\nare not modified) perform the following transforms:\n\nreplace let a := v by let a_i := v   let a := a_i\nreplace a := v by let a_i := v   a := a_i where i is a number such that a_i is yet unused.\n\nFurthermore, always record the current value of i used for a and replace each\nreference to a by a_i.\nThe current value mapping is cleared for a variable a at the end of each block\nin which it was assigned to and at the end of the for loop init block if it is assigned\ninside the for loop body or post block.\nIf a variable’s value is cleared according to the rule above and the variable is declared outside\nthe block, a new SSA variable will be created at the location where control flow joins,\nthis includes the beginning of loop post/body block and the location right after\nif/switch/for/block statement.\nAfter this stage, the UnusedAssignEliminator is recommended to remove the unnecessary\nintermediate assignments.\nThis stage provides best results if the ExpressionSplitter and the CommonSubexpressionEliminator\nare run right before it, because then it does not generate excessive amounts of variables.\nOn the other hand, the CommonSubexpressionEliminator could be more efficient if run after the\nSSA transform.\n\nUnusedAssignEliminator\nThe SSA transform always generates an assignment of the form a := a_i, even though\nthese might be unnecessary in many cases, like the following example:\nopen in Remix\n{\n let a := 1\n a := mload(a)\n a := sload(a)\n sstore(a, 1)\n}\n\nThe SSA transform converts this snippet to the following:\nopen in Remix\n{\n let a_1 := 1\n let a := a_1\n let a_2 := mload(a_1)\n a := a_2\n let a_3 := sload(a_2)\n a := a_3\n sstore(a_3, 1)\n}\n\nThe UnusedAssignEliminator removes all the three assignments to a, because\nthe value of a is not used and thus turn this\nsnippet into strict SSA form:\nopen in Remix\n{\n let a_1 := 1\n let a_2 := mload(a_1)\n let a_3 := sload(a_2)\n sstore(a_3, 1)\n}\n\nOf course the intricate parts of determining whether an assignment is unused or not\nare connected to joining control flow.\nThe component works as follows in detail:\nThe AST is traversed twice: in an information gathering step and in the\nactual removal step. During information gathering, we maintain a\nmapping from assignment statements to the three states\n“unused”, “undecided” and “used” which signifies whether the assigned\nvalue will be used later by a reference to the variable.\nWhen an assignment is visited, it is added to the mapping in the “undecided” state\n(see remark about for loops below) and every other assignment to the same variable\nthat is still in the “undecided” state is changed to “unused”.\nWhen a variable is referenced, the state of any assignment to that variable still\nin the “undecided” state is changed to “used”.\nAt points where control flow splits, a copy\nof the mapping is handed over to each branch. At points where control flow\njoins, the two mappings coming from the two branches are combined in the following way:\nStatements that are only in one mapping or have the same state are used unchanged.\nConflicting values are resolved in the following way:\n\n“unused”, “undecided” -> “undecided”\n“unused”, “used” -> “used”\n“undecided”, “used” -> “used”\n\nFor for loops, the condition, body and post-part are visited twice, taking\nthe joining control-flow at the condition into account.\nIn other words, we create three control flow paths: Zero runs of the loop,\none run and two runs and then combine them at the end.\nSimulating a third run or even more is unnecessary, which can be seen as follows:\nA state of an assignment at the beginning of the iteration will deterministically\nresult in a state of that assignment at the end of the iteration. Let this\nstate mapping function be called f. The combination of the three different\nstates unused, undecided and used as explained above is the max\noperation where unused = 0, undecided = 1 and used = 2.\nThe proper way would be to compute\nmax(s, f(s), f(f(s)), f(f(f(s))), ...)\n\nas state after the loop. Since f just has a range of three different values,\niterating it has to reach a cycle after at most three iterations,\nand thus f(f(f(s))) has to equal one of s, f(s), or f(f(s))\nand thus\nmax(s, f(s), f(f(s))) = max(s, f(s), f(f(s)), f(f(f(s))), ...)\n\nIn summary, running the loop at most twice is enough because there are only three\ndifferent states.\nFor switch statements that have a default case, there is no control-flow\npart that skips the switch.\nWhen a variable goes out of scope, all statements still in the “undecided”\nstate are changed to “unused”, unless the variable is the return\nparameter of a function - there, the state changes to “used”.\nIn the second traversal, all assignments that are in the “unused” state are removed.\nThis step is usually run right after the SSA transform to complete\nthe generation of the pseudo-SSA.\n\nTools\n\nMovability\nMovability is a property of an expression. It roughly means that the expression\nis side-effect free and its evaluation only depends on the values of variables\nand the call-constant state of the environment. Most expressions are movable.\nThe following parts make an expression non-movable:\n\nfunction calls (might be relaxed in the future if all statements in the function are movable)\nopcodes that (can) have side-effects (like call or selfdestruct)\nopcodes that read or write memory, storage or external state information\nopcodes that depend on the current PC, memory size or returndata size\n\nDataflowAnalyzer\nThe DataflowAnalyzer is not an optimizer step itself but is used as a tool\nby other components. While traversing the AST, it tracks the current value of\neach variable, as long as that value is a movable expression.\nIt records the variables that are part of the expression\nthat is currently assigned to each other variable. Upon each assignment to\na variable a, the current stored value of a is updated and\nall stored values of all variables b are cleared whenever a is part\nof the currently stored expression for b.\nAt control-flow joins, knowledge about variables is cleared if they have or would be assigned\nin any of the control-flow paths. For instance, upon entering a\nfor loop, all variables are cleared that will be assigned during the\nbody or the post block.\n\nExpression-Scale Simplifications\nThese simplification passes change expressions and replace them by equivalent\nand hopefully simpler expressions.\n\nCommonSubexpressionEliminator\nThis step uses the DataflowAnalyzer and replaces subexpressions that\nsyntactically match the current value of a variable by a reference to\nthat variable. This is an equivalence transform because such subexpressions have\nto be movable.\nAll subexpressions that are identifiers themselves are replaced by their\ncurrent value if the value is an identifier.\nThe combination of the two rules above allow to compute a local value\nnumbering, which means that if two variables have the same\nvalue, one of them will always be unused. The UnusedPruner or the\nUnusedAssignEliminator will then be able to fully eliminate such\nvariables.\nThis step is especially efficient if the ExpressionSplitter is run\nbefore. If the code is in pseudo-SSA form,\nthe values of variables are available for a longer time and thus we\nhave a higher chance of expressions to be replaceable.\nThe ExpressionSimplifier will be able to perform better replacements\nif the CommonSubexpressionEliminator was run right before it.\n\nExpressionSimplifier\nThe ExpressionSimplifier uses the DataflowAnalyzer and makes use\nof a list of equivalence transforms on expressions like X + 0 -> X\nto simplify the code.\nIt tries to match patterns like X + 0 on each subexpression.\nDuring the matching procedure, it resolves variables to their currently\nassigned expressions to be able to match more deeply nested patterns\neven when the code is in pseudo-SSA form.\nSome of the patterns like X - X -> 0 can only be applied as long\nas the expression X is movable, because otherwise it would remove its potential side-effects.\nSince variable references are always movable, even if their current\nvalue might not be, the ExpressionSimplifier is again more powerful\nin split or pseudo-SSA form.\n\nLiteralRematerialiser\nTo be documented.\n\nLoadResolver\nOptimisation stage that replaces expressions of type sload(x) and mload(x) by the value\ncurrently stored in storage resp. memory, if known.\nWorks best if the code is in SSA form.\nPrerequisites: Disambiguator, ForLoopInitRewriter.\n\nStatement-Scale Simplifications\n\nCircularReferencesPruner\nThis stage removes functions that call each other but are\nneither externally referenced nor referenced from the outermost context.\n\nConditionalSimplifier\nThe ConditionalSimplifier inserts assignments to condition variables if the value can be determined\nfrom the control-flow.\nDestroys SSA form.\nCurrently, this tool is very limited, mostly because we do not yet have support\nfor boolean types. Since conditions only check for expressions being nonzero,\nwe cannot assign a specific value.\nCurrent features:\n\nswitch cases: insert <condition> := <caseLabel>\nafter if statement with terminating control-flow, insert <condition> := 0\n\nFuture features:\n\nallow replacements by 1\ntake termination of user-defined functions into account\n\nWorks best with SSA form and if dead code removal has run before.\nPrerequisite: Disambiguator.\n\nConditionalUnsimplifier\nReverse of ConditionalSimplifier.\n\nControlFlowSimplifier\nSimplifies several control-flow structures:\n\nreplace if with empty body with pop(condition)\nremove empty default switch case\nremove empty switch case if no default case exists\nreplace switch with no cases with pop(expression)\nturn switch with single case into if\nreplace switch with only default case with pop(expression) and body\nreplace switch with const expr with matching case body\nreplace for with terminating control flow and without other break/continue by if\nremove leave at the end of a function.\n\nNone of these operations depend on the data flow. The StructuralSimplifier\nperforms similar tasks that do depend on data flow.\nThe ControlFlowSimplifier does record the presence or absence of break\nand continue statements during its traversal.\nPrerequisite: Disambiguator, FunctionHoister, ForLoopInitRewriter.\nImportant: Introduces EVM opcodes and thus can only be used on EVM code for now.\n\nDeadCodeEliminator\nThis optimization stage removes unreachable code.\nUnreachable code is any code within a block which is preceded by a\nleave, return, invalid, break, continue, selfdestruct, revert or by\na call to a user-defined function that recurses infinitely.\nFunction definitions are retained as they might be called by earlier\ncode and thus are considered reachable.\nBecause variables declared in a for loop’s init block have their scope extended to the loop body,\nwe require ForLoopInitRewriter to run before this step.\nPrerequisites: ForLoopInitRewriter, FunctionHoister, FunctionGrouper.\n\nEqualStoreEliminator\nThis steps removes mstore(k, v) and sstore(k, v) calls if\nthere was a previous call to mstore(k, v) / sstore(k, v),\nno other store in between and the values of k and v did not change.\nThis simple step is effective if run after the SSATransform and the\nCommonSubexpressionEliminator, because SSA will make sure that the variables\nwill not change and the CommonSubexpressionEliminator reuses exactly the same\nvariable if the value is known to be the same.\nPrerequisites: Disambiguator, ForLoopInitRewriter.\n\nUnusedPruner\nThis step removes the definitions of all functions that are never referenced.\nIt also removes declarations of variables that are never referenced.\nIf a declaration assigns a value that is not movable, the expression is retained,\nbut its value is discarded.\nAll movable expression statements (expressions that are not assigned) are removed.\n\nStructuralSimplifier\nThis is a general step that performs various kinds of simplifications on\na structural level:\n\nreplace if statement with empty body by pop(condition)\nreplace if statement with true condition by its body\nremove if statement with false condition\nturn switch with single case into if\nreplace switch with only default case by pop(expression) and body\nreplace switch with literal expression by matching case body\nreplace for loop with false condition by its initialization part\n\nThis component uses the DataflowAnalyzer.\n\nBlockFlattener\nThis stage eliminates nested blocks by inserting the statements in the\ninner block at the appropriate place in the outer block. It depends on the\nFunctionGrouper and does not flatten the outermost block to keep the form\nproduced by the FunctionGrouper.\nopen in Remix\n{\n {\n let x := 2\n {\n let y := 3\n mstore(x, y)\n }\n }\n}\n\nis transformed to\nopen in Remix\n{\n {\n let x := 2\n let y := 3\n mstore(x, y)\n }\n}\n\nAs long as the code is disambiguated, this does not cause a problem because\nthe scopes of variables can only grow.\n\nLoopInvariantCodeMotion\nThis optimization moves movable SSA variable declarations outside the loop.\nOnly statements at the top level in a loop’s body or post block are considered, i.e variable\ndeclarations inside conditional branches will not be moved out of the loop.\nExpressionSplitter and SSATransform should be run upfront to obtain better results.\nPrerequisites: Disambiguator, ForLoopInitRewriter, FunctionHoister.\n\nFunction-Level Optimizations\n\nFunctionSpecializer\nThis step specializes the function with its literal arguments.\nIf a function, say, function f(a, b) { sstore (a, b) }, is called with literal arguments, for\nexample, f(x, 5), where x is an identifier, it could be specialized by creating a new\nfunction f_1 that takes only one argument, i.e.,\nopen in Remix\nfunction f_1(a_1) {\n let b_1 := 5\n sstore(a_1, b_1)\n}\n\nOther optimization steps will be able to make more simplifications to the function. The\noptimization step is mainly useful for functions that would not be inlined.\nPrerequisites: Disambiguator, FunctionHoister.\nLiteralRematerialiser is recommended as a prerequisite, even though it’s not required for\ncorrectness.\n\nUnusedFunctionParameterPruner\nThis step removes unused parameters in a function.\nIf a parameter is unused, like c and y in, function f(a,b,c) -> x, y { x := div(a,b) }, we\nremove the parameter and create a new “linking” function as follows:\nopen in Remix\nfunction f(a,b) -> x { x := div(a,b) }\nfunction f2(a,b,c) -> x, y { x := f(a,b) }\n\nand replace all references to f by f2.\nThe inliner should be run afterwards to make sure that all references to f2 are replaced by\nf.\nPrerequisites: Disambiguator, FunctionHoister, LiteralRematerialiser.\nThe step LiteralRematerialiser is not required for correctness. It helps deal with cases such as:\nfunction f(x) -> y { revert(y, y} } where the literal y will be replaced by its value 0,\nallowing us to rewrite the function.\n\nUnusedStoreEliminator\nOptimizer component that removes redundant sstore and memory store statements.\nIn case of an sstore, if all outgoing code paths revert (due to an explicit revert(), invalid(), or infinite recursion) or\nlead to another sstore for which the optimizer can tell that it will overwrite the first store, the statement will be removed.\nHowever, if there is a read operation between the initial sstore and the revert, or the overwriting sstore, the statement\nwill not be removed.\nSuch read operations include: external calls, user-defined functions with any storage access, and sload of a slot that cannot be\nproven to differ from the slot written by the initial sstore.\nFor example, the following code\nopen in Remix\n{\n let c := calldataload(0)\n sstore(c, 1)\n if c {\n sstore(c, 2)\n }\n sstore(c, 3)\n}\n\nwill be transformed into the code below after the UnusedStoreEliminator step is run\nopen in Remix\n{\n let c := calldataload(0)\n if c { }\n sstore(c, 3)\n}\n\nFor memory store operations, things are generally simpler, at least in the outermost Yul block as all such\nstatements will be removed if they are never read from in any code path.\nAt function analysis level, however, the approach is similar to sstore, as we do not know whether the memory location will\nbe read once we leave the function’s scope, so the statement will be removed only if all code paths lead to a memory overwrite.\nBest run in SSA form.\nPrerequisites: Disambiguator, ForLoopInitRewriter.\n\nEquivalentFunctionCombiner\nIf two functions are syntactically equivalent, while allowing variable\nrenaming but not any re-ordering, then any reference to one of the\nfunctions is replaced by the other.\nThe actual removal of the function is performed by the UnusedPruner.\n\nFunction Inlining\n\nExpressionInliner\nThis component of the optimizer performs restricted function inlining by inlining functions that can be\ninlined inside functional expressions, i.e. functions that:\n\nreturn a single value.\nhave a body like r := <functional expression>.\nneither reference themselves nor r in the right hand side.\n\nFurthermore, for all parameters, all of the following need to be true:\n\nThe argument is movable.\nThe parameter is either referenced less than twice in the function body, or the argument is rather cheap\n(“cost” of at most 1, like a constant up to 0xff).\n\nExample: The function to be inlined has the form of function f(...) -> r { r := E } where\nE is an expression that does not reference r and all arguments in the function call are movable expressions.\nThe result of this inlining is always a single expression.\nThis component can only be used on sources with unique names.\n\nFullInliner\nThe FullInliner replaces certain calls of certain functions\nby the function’s body. This is not very helpful in most cases, because\nit just increases the code size but does not have a benefit. Furthermore,\ncode is usually very expensive and we would often rather have shorter\ncode than more efficient code. In some cases, though, inlining a function\ncan have positive effects on subsequent optimizer steps. This is the case\nif one of the function arguments is a constant, for example.\nDuring inlining, a heuristic is used to tell if the function call\nshould be inlined or not.\nThe current heuristic does not inline into “large” functions unless\nthe called function is tiny. Functions that are only used once\nare inlined, as well as medium-sized functions, while function\ncalls with constant arguments allow slightly larger functions.\nIn the future, we may include a backtracking component\nthat, instead of inlining a function right away, only specializes it,\nwhich means that a copy of the function is generated where\na certain parameter is always replaced by a constant. After that,\nwe can run the optimizer on this specialized function. If it\nresults in heavy gains, the specialized function is kept,\notherwise the original function is used instead.\nFunctionHoister and ExpressionSplitter are recommended as prerequisites since they make the step\nmore efficient, but are not required for correctness.\nIn particular, function calls with other function calls as arguments are not inlined, but running\nExpressionSplitter beforehand ensures that there are no such calls in the input.\n\nCleanup\nThe cleanup is performed at the end of the optimizer run. It tries\nto combine split expressions into deeply nested ones again and also\nimproves the “compilability” for stack machines by eliminating\nvariables as much as possible.\n\nExpressionJoiner\nThis is the opposite operation of the ExpressionSplitter. It turns a sequence of\nvariable declarations that have exactly one reference into a complex expression.\nThis stage fully preserves the order of function calls and opcode executions.\nIt does not make use of any information concerning the commutativity of the opcodes;\nif moving the value of a variable to its place of use would change the order\nof any function call or opcode execution, the transformation is not performed.\nNote that the component will not move the assigned value of a variable assignment\nor a variable that is referenced more than once.\nThe snippet let x := add(0, 2) let y := mul(x, mload(2)) is not transformed,\nbecause it would cause the order of the call to the opcodes add and\nmload to be swapped - even though this would not make a difference\nbecause add is movable.\nWhen reordering opcodes like that, variable references and literals are ignored.\nBecause of that, the snippet let x := add(0, 2) let y := mul(x, 3) is\ntransformed to let y := mul(add(0, 2), 3), even though the add opcode\nwould be executed after the evaluation of the literal 3.\n\nSSAReverser\nThis is a tiny step that helps in reversing the effects of the SSATransform\nif it is combined with the CommonSubexpressionEliminator and the\nUnusedPruner.\nThe SSA form we generate is detrimental to code generation\nbecause it produces many local variables. It would\nbe better to just reuse existing variables with assignments instead of\nfresh variable declarations.\nThe SSATransform rewrites\nopen in Remix\nlet a := calldataload(0)\nmstore(a, 1)\n\nto\nopen in Remix\nlet a_1 := calldataload(0)\nlet a := a_1\nmstore(a_1, 1)\nlet a_2 := calldataload(0x20)\na := a_2\n\nThe problem is that instead of a, the variable a_1 is used\nwhenever a was referenced. The SSATransform changes statements\nof this form by just swapping out the declaration and the assignment. The above\nsnippet is turned into\nopen in Remix\nlet a := calldataload(0)\nlet a_1 := a\nmstore(a_1, 1)\na := calldataload(0x20)\nlet a_2 := a\n\nThis is a very simple equivalence transform, but when we now run the\nCommonSubexpressionEliminator, it will replace all occurrences of a_1\nby a (until a is re-assigned). The UnusedPruner will then\neliminate the variable a_1 altogether and thus fully reverse the\nSSATransform.\n\nStackCompressor\nOne problem that makes code generation for the Ethereum Virtual Machine\nhard is the fact that there is a hard limit of 16 slots for reaching\ndown the expression stack. This more or less translates to a limit\nof 16 local variables. The stack compressor takes Yul code and\ncompiles it to EVM bytecode. Whenever the stack difference is too\nlarge, it records the function this happened in.\nFor each function that caused such a problem, the Rematerialiser\nis called with a special request to aggressively eliminate specific\nvariables sorted by the cost of their values.\nOn failure, this procedure is repeated multiple times.\n\nRematerialiser\nThe rematerialisation stage tries to replace variable references by the expression that\nwas last assigned to the variable. This is of course only beneficial if this expression\nis comparatively cheap to evaluate. Furthermore, it is only semantically equivalent if\nthe value of the expression did not change between the point of assignment and the\npoint of use. The main benefit of this stage is that it can save stack slots if it\nleads to a variable being eliminated completely (see below), but it can also\nsave a DUP opcode on the EVM if the expression is very cheap.\nThe Rematerialiser uses the DataflowAnalyzer to track the current values of variables,\nwhich are always movable.\nIf the value is very cheap or the variable was explicitly requested to be eliminated,\nthe variable reference is replaced by its current value.\n\nForLoopConditionOutOfBody\nReverses the transformation of ForLoopConditionIntoBody.\nFor any movable c, it turns\nfor { ... } 1 { ... } {\nif iszero(c) { break }\n...\n}\n\ninto\nfor { ... } c { ... } {\n...\n}\n\nand it turns\nfor { ... } 1 { ... } {\nif c { break }\n...\n}\n\ninto\nfor { ... } iszero(c) { ... } {\n...\n}\n\nThe LiteralRematerialiser should be run before this step.\n\nCodegen-Based Optimizer Module\nCurrently, the codegen-based optimizer module provides two optimizations.\nThe first one, available in the legacy code generator, moves literals to the right side of\ncommutative binary operators, which helps exploit their associativity.\nThe other one, available in the IR-based code generator, enables the use of unchecked arithmetic\nwhen generating code for incrementing the counter variable of certain idiomatic for loops.\nThis avoids wasting gas by identifying some conditions that guarantee that the counter variable\ncannot overflow.\nThis eliminates the need to use a verbose unchecked arithmetic block inside the loop body to\nincrement the counter variable.\n\nUnchecked Loop Increment\nIntroduced in Solidity 0.8.22, the overflow check optimization step is concerned with identifying\nthe conditions under which the for loop counter can be safely incremented\nwithout overflow checks.\nThis optimization is only applied to for loops of the general form:\nopen in Remix\nfor (uint i = X; i < Y; ++i) {\n // variable i is not modified in the loop body\n}\n\nThe condition and the fact that the counter variable is only ever incremented\nguarantee that it never overflows.\nThe precise requirements for the loop to be eligible for the optimization are as follows:\n\nThe loop condition is a comparison of the form i < Y, for a local counter variable i\n(called the “loop counter” hereon) and an expression Y.\nThe built-in operator < is necessarily used in the loop condition and is the only operator\nthat triggers the optimization. <= and the like are intentionally excluded. Additionally,\nuser-defined operators are not eligible.\nThe loop expression is a prefix or postfix increment of the counter variable, i.e, i++ or ++i.\nThe loop counter is a local variable of a built-in integer type.\nThe loop counter is not modified by the loop body or by the expression used as the loop condition.\nThe comparison is performed on the same type as the loop counter, meaning that the type of the\nright-hand-side expression is implicitly convertible to the type of the counter, such that the latter\nis not implicitly widened before the comparison.\n\nTo clarify the last condition, consider the following example:\nopen in Remix\nfor (uint8 i = 0; i < uint16(1000); i++) {\n // ...\n}\n\nIn this case, the counter i has its type implicitly converted from uint8\nto uint16 before the comparison and the condition is in fact never false, so\nthe overflow check for the increment cannot be removed.","tokens":11896,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263536663,"hash":"a9b5c0043314b1587ad9a9ca124e4df6fb376e83"}
{"url":"https://support.arbitrum.io/hc/en-gb/articles/18213854684699","domain":"support.arbitrum.io","title":"You need ETH to power transactions – Arbitrum Foundation","text":"When moving funds from Mainnet (L1) to Arbitrum (L2), you'll need ETH in your Arbitrum wallet.Even if you want only to use another, non-ETH, token, you will still need a small amount of ETH in your wallet on the Arbitrum network. This is because all Arbitrum transactions are powered by ETH. \nETH is the currency used for gas fees. Arbitrum gas fees go to Arbitrum validators to track chain state and execute transactions. This is actually an estimated fee; if the true fee is lower, then you will be refunded.\n\n Recently viewed articlesHow can I add Arbitrum network to my wallet?I've sent $ARB from a CEX to my wallet but I can't see itUsing Arbitrum's traditional bridge to move funds to MainnetWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?\n\n Related articles\n\n Using Arbitrum's traditional bridge to move funds to Mainnet\n\n Why do I need ETH to use the Arbitrum network?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Please sign in to leave a comment.","tokens":275,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263540858,"hash":"e605ae072268a72c90216aca3acd2987c90c1282"}
{"url":"https://ethresear.ch/t/big-block-diffusion-and-organic-big-blocks-on-ethereum/17346","domain":"ethresear.ch","title":"Big Block Diffusion and Organic Big Blocks on Ethereum - Sharding - Ethereum Research","text":"Big Block Diffusion and Organic Big Blocks on Ethereum \n\n Sharding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2023\n\n 1 / 2\n\n Nov 2023\n\n Nov 2023\n\n post by leobago on Nov 8, 2023\n\n leobago\n\n This analysis was done by @cskiraly and @leobago, with the support and feedback from @dryajov, @dankrad, @djrtwo, Andrew Davis, and Sam Calder-Mason.\nThe Codex team is working on research around data availability sampling (DAS) for Ethereum scaling. Part of this research is to develop a simulator that can give us some good estimates about how much time it takes to disseminate a huge block of 128 MB (including erasure-coded data) to the entire network. The simulator is already producing results, but in this post we want to focus on two by-products of this research: the characterisation of big block diffusion latency on the existing Ethereum Mainnet and the existence of organic big blocks on Ethereum Mainnet and its implications.\nInflating Blocks Artificially\nEvery simulator needs to be evaluated, at least partially, with a real-world measurement that demonstrates that the results produced by the simulator are accurate. To validate our simulator, we started looking at the data produced by an experiment done by the Ethereum Foundation (EF). The experiment was done on May 28th and June 11th and consisted of injecting big blocks in Ethereum Mainnet. The target block sizes were in a range from 128 KB to 1 MB. The blocks were artificially inflated by adding random bytes using CALLDATA to them through a steady stream of 64 KB transactions. As a reference, the average block size in Ethereum is 100 KB. The objective was to measure the arrival of those big blocks in multiple nodes located in different world regions. More precisely, the EF deployed 15 nodes, called Sentry nodes, in three different continents, the exact locations are: Sydney, Amsterdam and San Francisco, to observe the impact of network latency on attestations and block propagation. The Sentry nodes were all running Xatu, a network monitoring and data pipelining tool. Each location had five nodes running, one for each consensus layer (CL) client: Prysm, Lighthouse, Teku, Nimbus and Lodestar. The exact versions used for each client are described in the following table.\n\nClient\nVersion\n\nPrysm\ndevelop-f1b88d0\n\nLighthouse\nstable-7c0b275\n\nTeku\nmaster-fccbaf1\n\nNimbus\nstable-748be8b\n\nLodestar\nunstable-375d660\n\nStumble on Organic Big Blocks\nAt the same time this DAS research was ongoing, the team at MigaLabs was analysing block sizes and the number of transactions per block, among other data points. By looking at block sizes outside the experiment dates, we discovered that there were many big blocks in the Ethereum Mainnet. After confirming with the EF researchers that those blocks were not artificially inflated, we started looking at how frequent these organic big blocks are. Over the last six months, from March 1st 2023 to August 31st 2023, we have found a total of 109,504 blocks with a size over 250 KB, which is about 8.2% of the 1,323,034 slots in that time period. The biggest block (#17968783) observed during those six months was produced on August 22nd, and it had a size of 2.3 MB, which was very surprising. The maximum gas used in a block is 30,000,000, and the CALLDATA cost is 16 gas per byte, which should lead to a maximum block size of roughly 1.8 MB. However, 16 gas per byte is the cost for non-zero bytes, while zero bytes have a cost of 4 gas. This means that blocks with a large number of zeros in CALLDATA can go over 1.8 MB and in theory, one could even create a block of over 7 MB.\nblockSizeLog-11200×600 26.3 KB\nThe figure above presents the distribution of blocks over 250 KB from March 1st to August 31st; note that we use a logarithmic scale in the y-axis. During those six months, the 15 Sentry nodes were running and recording the exact time blocks were received. That allowed us to do a detailed analysis of the block propagation times depending on their size and geographical location from the perspective of different CL clients.\nImpact of Geographical Location\nWe analyse the time when the block is reported in the three different locations. Note that the three regions are located almost perfectly at 8 hours difference from each other. According to monitorEth, most Ethereum nodes are located in North America, Europe and Asia, giving Europe a central location in the network. The following figure shows the cumulative distribution function (CDF) of the latency in milliseconds for all the blocks over 250 KB as observed by the Lighthouse nodes, for the three different locations.\nlighthouse-geo-11200×600 45.8 KB\nAs we can observe in the figure, the large majority of the blocks arrive between 1 and 4 seconds after the beginning of the slot for all three regions. However, the mean arrival time differs by about 400ms between Amsterdam and Sydney, while San Francisco sits between them at approximately 200ms distance to both. While this difference is not dramatic, a couple of hundred milliseconds do have a non-negligible impact on the node performance, particularly when nodes are under tight deadlines to produce blocks, send attestations and disseminate aggregations. We produced similar figures for the other CL clients, and they show similar results.\nBlock Size Dissemination Times\nFor the DAS research we are doing at Codex, the most exciting result of this discovery is to analyse the propagation time of big blocks in the network. Thus, we took the 100K+ big organic blocks that we found and divided them into bins of 250 KB, starting from a range from 250 KB to 500 KB, the second one from 500 KB to 750 KB, and so on until the last range going from 2000 KB to 2250 KB.\nWe also divide the data of the different CL clients because they report blocks at different moments in the block treatment pipeline, some as soon as they receive it in the p2p network layer (libp2p/GossipSub), some batch multiple network events before treating them, while others report only after the block is fully imported (EL, CL validated and inserted into the block DAG). In other words, our intention here is not to compare the latency of different CL clients. We can’t do that based on the data available currently. To the contrary, we should only compare oranges with oranges and treat different CL results as insight into the timing of other parts of the processing pipeline. Here, we show the results for all five CL clients separately.\nteku-bin-11200×600 69.5 KB\nFor each CL client, we plotted both the CDF (bottom) and the probability distribution function (PDF) (top) of the block propagation latency for different block sizes. Note that the x-axis is logarithmic, starting from 600 ms up to 60,000 ms in some figures. One thing that we observe very clearly in the PDF is that the large majority of the blocks shown in these figures are blocks in the first size range (250 KB - 500 KB). This agrees with the data presented in the block size distribution figure.\nnimbus-bin-11200×600 74.4 KB\nLooking at the CDF, it is clear that the large majority of big blocks are reported between 1 and 8 seconds after the beginning of the slot, except for a few clients that actually report the block after some computationally intensive processing. We also see a clear trend in which bigger blocks take more time to propagate through the network, which is to be expected. However, the distance between block sizes is extremely hard to predict in a p2p network with more than 10,000 nodes distributed worldwide and five different implementations with different optimisation strategies.\nlodestar-bin-11200×600 72.7 KB\nIn these results, we can see that there is approximately a 2-second delay between the 250 KB blocks and the 2250 KB blocks. For instance, looking at the block arrival time for Lighthouse, we can observe that 40% of the blocks in the 250 KB - 500 KB size range have arrived in about 2 seconds, while 40% of the blocks in the 2000 KB - 2250 KB size range arrive in about 4 seconds from the start of the slot.\nnimbus-bin-11200×600 74.4 KB\nSimilarly, looking at Prysm’s 80% line, we can observe the block arrival time shifting from 3 seconds to about 5 seconds, from 250KB to 2000 KB. Overall, these results show that the current Ethereum network can manage to accommodate large blocks from 1 MB and up to 2 MB. This is good news for the upcoming EIP-4844, in which we expect to add blobs of rollup data and the average block size is expected to be around 1 MB.\nprysm-bin-11200×600 72.5 KB\nDetailed Timing\nAs mentioned above, the data shown before was obtained by Sentry nodes running Xatu through the beacon API, and as it turned out during discussions with client teams, each client exposes data on this API differently. Therefore, to further validate some of the results, we focused on a specific client (Nimbus) and slightly modified its code to report detailed timing for each received block, from block arrival to different events of the processing pipeline. The modified code is available here.\nIn 4 days we have collected data for about 25000 blocks as they arrive to a single beacon node deployed in Italy in a home behind a 1000/100 Mbps fibre connection.\nBlocks, when sent over GossipSub, are sent in a compressed form using Snappy compression. These get decompressed, SSZ decoded, and verified before the original compressed version can be forwarded to neighbours in the GossipSub topic mesh. These checks before forwarding are an important part of the protocol to avoid error propagation. After the forwarding checks, further verification and internal processing has to be done in the node. Overall, we collect 8 timing events for each block, each relative to the block’s slot start time: message reception from GossipSub neighbor; Snappy decompression; SSZ decoding; validation for GossipSub forwarding; verification according to beacon chain specification, and a few other internal events irrelevant for our current discussion.\ncompressed640×480 19.8 KB\nWe also collect both compressed and uncompressed block size information. The plots below shows block distribution as a function of uncompressed and compressed size, and the compression ratio’s observed.\nInterestingly, bigger blocks were all arriving with similar compression ratios, hinting to a similar internal block structure, something we plan to investigate further.\ncimpdist1090×860 203 KB\nNext, we look at block reception delays, namely our first timer, when the block arrives from GossipSub, before it gets decompressed. As shown below, these are similar to the behaviour observed previously through the beacon API.\ndist21046×820 248 KB\nAnalyzing block reception delays using size ranges we can also see CDFs similar to the large scale data collection. We have much less data points than previously, since we observe only from a single node and only for a few days. Hence, curves for large blocks are with large steps, and with limited statistical relevance. Still, we can clearly see the increasing delay as a function of block size.\nbindistnim1440×500 59.4 KB\nFinally, we can show the curves as a function of compressed block size. Compressed blocks are what travel on the network, so one might argue that this is most relevant from the networking (bandwidth) perspective. It is clear that most blocks, even those that are 2MB uncompressed, 1.5 MB compressed, can arrive within 4 seconds, even to a home beacon node.\nbindistnimcmop1440×500 48.9 KB\nConclusions\nWe have discovered a large number of big blocks (>250 KB) that occur organically every day in the Ethereum Mainnet. We have measured the propagation time of those blocks in three different world regions and compared their latency based on geographical location as well as block size. We have analyzed how these propagation differences are reflected in the five CL clients separately, as they have different ways of reporting blocks. The empirical results measured in Ethereum Mainnet and presented in this work give us the first clear idea of how block propagation times might look when EIP-4844 is deployed, and 1 MB blocks become the standard and not the exception.\nIn the future, we plan to continue with these block propagation measurements and monitor the behaviour of big blocks in the Ethereum network. Additionally, we want to help different CL clients harmonize their event recording and publication systems in order to be able to compare CL clients between them.\n\n Gossipsub Message Propagation Latency\n\n FullDAS: towards massive scalability with 32MB blocks and beyond\n\n Full DAS Sampling Analysis\n\n Wen fast payload broadcast? Segment, code, push, pull, and everything in between\n\n read \n\n 5\n min\n\n post by abcoathup on Nov 8, 2023\n\n Powered by Discourse","tokens":3187,"squid":"ink-research","role":"Deep Scholar","at":1791263540913,"hash":"0e815fc0e02a43517274d446def7b7be257a6949"}
{"url":"https://support.arbitrum.io/hc/en-gb/related/click?data=BAh7CjobZGVzdGluYXRpb25fYXJ0aWNsZV9pZGwrCBvSpb2QEDoYcmVmZXJyZXJfYXJ0aWNsZV9pZGwrCBumVr6QEDoLbG9jYWxlSSIKZW4tZ2IGOgZFVDoIdXJsSSJjL2hjL2VuLWdiL2FydGljbGVzLzE4MjEzODQzMDk2MDkxLVVzaW5nLUFyYml0cnVtLXMtdHJhZGl0aW9uYWwtYnJpZGdlLXRvLW1vdmUtZnVuZHMtdG8tTWFpbm5ldAY7CFQ6CXJhbmtpBg%3D%3D--ecc336209f1afffd5a7becda9b01bb4acac1ee2f","domain":"support.arbitrum.io","title":"Using Arbitrum's traditional bridge to move funds to Mainnet – Arbitrum Foundation","text":"If you choose to use Arbitrum's traditional path instead of a fast exit bridge, you will have to wait ~8 days before you can claim your funds.If you want your funds faster, we recommend using a fast exit liquidity provider like Hop, Connext, Across, Celer, or Maker. Why do I have to wait 8 days?This is how all optimistic rollups work. Optimistic rollups use something called fraud proofs in order to keep participants in the network honest. There is a \"challenge period\" for these proofs. When one party submits a claim about the state of the chain, another party has ~8 days to challenge that claim. If you'd like to read more about the technical details of Arbitrum, see Inside Arbitrum.If you're more of a visual and auditory learner, watch our videos about challenges and proofs.  More Resources:1 - (Youtube) Multi round Fraud Proofs: What, How, and Why.2 - (Youtube) Challenge Protocol\n\n Recently viewed articlesYou need ETH to power transactionsHow can I add Arbitrum network to my wallet?I've sent $ARB from a CEX to my wallet but I can't see itWhy wait 7 days to claim funds when bridge to Ethereum?Why are there 2 different USDC's on Arbitrum?\n\n Related articles\n\n Why wait 7 days to claim funds when bridge to Ethereum?\n\n Skipping the bridge\n\n How can I add Arbitrum network to my wallet?\n\n Bridging over a new token\n\n Why are there 2 different USDC's on Arbitrum?\n\n Godfrey brai\n\n 2 years ago\n\n I have waited for more than 12 days I still can find my ethPlease help me rectify \n\n 0\n\n Please sign in to leave a comment.","tokens":383,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263562815,"hash":"9a7a7274b65a8f53bb062f4f5171524a3a81d9ad"}
{"url":"https://docs.soliditylang.org/en/develop/security-considerations.html","domain":"docs.soliditylang.org","title":"Security Considerations — Solidity 0.8.38-develop documentation","text":"Security Considerations\n\n Edit on GitHub\n\nSecurity Considerations\nWhile it is usually quite easy to build software that works as expected,\nit is much harder to check that nobody can use it in a way that was not anticipated.\nIn Solidity, this is even more important because you can use smart contracts to handle tokens or,\npossibly, even more valuable things.\nFurthermore, every execution of a smart contract happens in public and,\nin addition to that, the source code is often available.\nOf course, you always have to consider how much is at stake:\nYou can compare a smart contract with a web service that is open to the public\n(and thus, also to malicious actors) and perhaps even open-source.\nIf you only store your grocery list on that web service, you might not have to take too much care,\nbut if you manage your bank account using that web service, you should be more careful.\nThis section will list some pitfalls and general security recommendations\nbut can, of course, never be complete.\nAlso, keep in mind that even if your smart contract code is bug-free,\nthe compiler or the platform itself might have a bug.\nA list of some publicly known security-relevant bugs of the compiler can be found\nin the list of known bugs, which is also machine-readable.\nNote that there is a Bug Bounty Program\nthat covers the code generator of the Solidity compiler.\nAs always, with open-source documentation,\nplease help us extend this section (especially, some examples would not hurt)!\nNOTE: In addition to the list below, you can find more security recommendations and best practices\nin Guy Lando’s knowledge list and\nthe Consensys GitHub repo.\n\nPitfalls\n\nPrivate Information and Randomness\nEverything you use in a smart contract is publicly visible,\neven local variables and state variables marked private.\nUsing random numbers in smart contracts is quite tricky if you do not want block builders to be able to cheat.\n\nReentrancy\nAny interaction from a contract (A) with another contract (B)\nand any transfer of Ether hands over control to that contract (B).\nThis makes it possible for B to call back into A before this interaction is completed.\nTo give an example, the following code contains a bug (it is just a snippet and not a complete contract):\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.0 <0.9.0;\n\n// THIS CONTRACT CONTAINS A BUG - DO NOT USE\ncontract Fund {\n /// @dev Mapping of ether shares of the contract.\n mapping(address => uint) shares;\n /// Withdraw your share.\n function withdraw() public {\n // This will report a warning (deprecation)\n if (payable(msg.sender).send(shares[msg.sender]))\n shares[msg.sender] = 0;\n }\n}\n\nThe problem is not too serious here because of the limited gas as part of send,\nbut it still exposes a weakness:\nEther transfer can always include code execution,\nso the recipient could be a contract that calls back into withdraw.\nThis would let it get multiple refunds and, basically, retrieve all the Ether in the contract.\nIn particular, the following contract will allow an attacker to refund multiple times\nas it uses call which does not limit the amount of gas that is forwarded by default:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.2 <0.9.0;\n\n// THIS CONTRACT CONTAINS A BUG - DO NOT USE\ncontract Fund {\n /// @dev Mapping of ether shares of the contract.\n mapping(address => uint) shares;\n /// Withdraw your share.\n function withdraw() public {\n (bool success,) = msg.sender.call{value: shares[msg.sender]}(\"\");\n if (success)\n shares[msg.sender] = 0;\n }\n}\n\nTo avoid reentrancy, you can use the Checks-Effects-Interactions pattern as demonstrated below:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.2 <0.9.0;\n\ncontract Fund {\n /// @dev Mapping of ether shares of the contract.\n mapping(address => uint) shares;\n /// Withdraw your share.\n function withdraw() public {\n uint share = shares[msg.sender];\n shares[msg.sender] = 0;\n (bool success, ) = payable(msg.sender).call{value: share}(\"\");\n require(success);\n }\n}\n\nThe Checks-Effects-Interactions pattern ensures that all code paths through a contract\ncomplete all required checks of the supplied parameters before modifying the contract’s state (Checks);\nonly then it makes any changes to the state (Effects);\nit may make calls to functions in other contracts\nafter all planned state changes have been written to storage (Interactions).\nThis is a common foolproof way to prevent reentrancy attacks,\nwhere an externally called malicious contract can double-spend an allowance,\ndouble-withdraw a balance, among other things,\nby using logic that calls back into the original contract before it has finalized its transaction.\nNote that reentrancy is not only an effect of Ether transfer\nbut of any function call on another contract.\nFurthermore, you also have to take multi-contract situations into account.\nA called contract could modify the state of another contract you depend on.\n\nGas Limit and Loops\nLoops that do not have a fixed number of iterations, for example,\nloops that depend on storage values, have to be used carefully:\nDue to the block gas limit, transactions can only consume a certain amount of gas.\nEither explicitly or just due to normal operation,\nthe number of iterations in a loop can grow beyond the block gas limit\nwhich can cause the complete contract to be stalled at a certain point.\nThis may not apply to view functions that are only executed to read data from the blockchain.\nStill, such functions may be called by other contracts as part of on-chain operations and stall those.\nPlease be explicit about such cases in the documentation of your contracts.\n\nSending and Receiving Ether\n\nNeither contracts nor “externally-owned accounts” are currently able to prevent someone from sending them Ether.\nContracts can react on and reject a regular transfer, but there are ways to move Ether without creating a message call.\nOne way is to simply “mine to” the contract address and the second way is using selfdestruct(x).\nIf a contract receives Ether (without a function being called), either the receive Ether\nor the fallback function is executed.\nIf it does not have a receive nor a fallback function, the Ether will be rejected (by throwing an exception).\nDuring the execution of one of these functions, the contract can only rely on the “gas stipend” it is passed (2300 gas)\nbeing available to it at that time.\nThis stipend is not enough to modify storage (do not take this for granted though, the stipend might change with future hard forks).\nTo be sure that your contract can receive Ether in that way, check the gas requirements of the receive and fallback functions\n(for example in the “details” section in Remix).\nThere is a way to forward more gas to the receiving contract using addr.call{value: x}(\"\").\nThis is essentially the same as addr.transfer(x), only that it forwards all remaining gas,\nsubject to additional limits imposed by some EVM versions (such as the 63/64th rule\nintroduced by tangerineWhistle), and opens up the ability for the recipient to perform more expensive actions\n(and it returns a failure code instead of automatically propagating the error).\nThis might include calling back into the sending contract or other state changes you might not have thought of.\nSo it allows for great flexibility for honest users but also for malicious actors.\nUse the most precise units to represent the Wei amount as possible, as you lose any that is rounded due to a lack of precision.\nIf you want to send Ether using address.transfer, there are certain details to be aware of:\n\nIf the recipient is a contract, it causes its receive or fallback function\nto be executed which can, in turn, call back the sending contract.\nSending Ether can fail due to the call depth going above 1024. Since the\ncaller is in total control of the call depth, they can force the\ntransfer to fail; take this possibility into account or use send and\nmake sure to always check its return value. Better yet, write your\ncontract using a pattern where the recipient can withdraw Ether instead.\nSending Ether can also fail because the execution of the recipient\ncontract requires more than the allotted amount of gas (explicitly by\nusing require, assert,\nrevert or because the\noperation is too expensive) - it “runs out of gas” (OOG). If you\nuse transfer or send with a return value check, this might\nprovide a means for the recipient to block progress in the sending\ncontract. Again, the best practice here is to use a “withdraw”\npattern instead of a “send” pattern.\n\nCall Stack Depth\nExternal function calls can fail at any time\nbecause they exceed the maximum call stack size limit of 1024.\nIn such situations, Solidity throws an exception.\nMalicious actors might be able to force the call stack to a high value\nbefore they interact with your contract.\nNote that, since Tangerine Whistle hardfork,\nthe 63/64 rule makes call stack depth attack impractical.\nAlso note that the call stack and the expression stack are unrelated,\neven though both have a size limit of 1024 stack slots.\nNote that .send() does not throw an exception if the call stack is depleted\nbut rather returns false in that case.\nThe low-level functions .call(), .delegatecall() and .staticcall() behave in the same way.\n\nAuthorized Proxies\nIf your contract can act as a proxy, i.e. if it can call arbitrary contracts with user-supplied data,\nthen the user can essentially assume the identity of the proxy contract.\nEven if you have other protective measures in place, it is best to build your contract system such\nthat the proxy does not have any permissions (not even for itself).\nIf needed, you can accomplish that using a second proxy:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.0;\ncontract ProxyWithMoreFunctionality {\n PermissionlessProxy proxy;\n\n function callOther(address addr, bytes memory payload) public\n returns (bool, bytes memory) {\n return proxy.callOther(addr, payload);\n }\n // Other functions and other functionality\n}\n\n// This is the full contract, it has no other functionality and\n// requires no privileges to work.\ncontract PermissionlessProxy {\n function callOther(address addr, bytes memory payload) public\n returns (bool, bytes memory) {\n return addr.call(payload);\n }\n}\n\ntx.origin\nNever use tx.origin for authorization.\nLet’s say you have a wallet contract like this:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n// THIS CONTRACT CONTAINS A BUG - DO NOT USE\ncontract TxUserWallet {\n address owner;\n\n constructor() {\n owner = msg.sender;\n }\n\n function transferTo(address payable dest, uint amount) public {\n // THE BUG IS RIGHT HERE, you must use msg.sender instead of tx.origin\n require(tx.origin == owner);\n // This will report a warning (deprecation)\n dest.transfer(amount);\n }\n}\n\nNow someone tricks you into sending Ether to the address of this attack wallet:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\ninterface TxUserWallet {\n function transferTo(address payable dest, uint amount) external;\n}\n\ncontract TxAttackWallet {\n address payable owner;\n\n constructor() {\n owner = payable(msg.sender);\n }\n\n receive() external payable {\n TxUserWallet(msg.sender).transferTo(owner, msg.sender.balance);\n }\n}\n\nIf your wallet had checked msg.sender for authorization, it would get the address of the attack wallet,\ninstead of the owner’s address.\nBut by checking tx.origin, it gets the original address that kicked off the transaction,\nwhich is still the owner’s address.\nThe attack wallet instantly drains all your funds.\n\nTwo’s Complement / Underflows / Overflows\nAs in many programming languages, Solidity’s integer types are not actually integers.\nThey resemble integers when the values are small, but cannot represent arbitrarily large numbers.\nThe following code causes an overflow because the result of the addition is too large\nto be stored in the type uint8:\nopen in Remix\nuint8 x = 255;\nuint8 y = 1;\nreturn x + y;\n\nSolidity has two modes in which it deals with these overflows: Checked and Unchecked or “wrapping” mode.\nThe default checked mode will detect overflows and cause a failing assertion. You can disable this check\nusing unchecked { ... }, causing the overflow to be silently ignored. The above code would return\n0 if wrapped in unchecked { ... }.\nEven in checked mode, do not assume you are protected from overflow bugs.\nIn this mode, overflows will always revert. If it is not possible to avoid the\noverflow, this can lead to a smart contract being stuck in a certain state.\nIn general, read about the limits of two’s complement representation, which even has some\nmore special edge cases for signed numbers.\nTry to use require to limit the size of inputs to a reasonable range and use the\nSMT checker to find potential overflows.\n\nClearing Mappings\nThe Solidity type mapping (see Mapping Types) is a storage-only key-value data structure\nthat does not keep track of the keys that were assigned a non-zero value.\nBecause of that, cleaning a mapping without extra information about the written keys is not possible.\nIf a mapping is used as the base type of a dynamic storage array,\ndeleting or popping the array will have no effect over the mapping elements.\nThe same happens, for example, if a mapping is used as the type of a member field of a struct\nthat is the base type of a dynamic storage array.\nThe mapping is also ignored in assignments of structs or arrays containing a mapping.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.0 <0.9.0;\n\ncontract Map {\n mapping(uint => uint)[] array;\n\n function allocate(uint newMaps) public {\n for (uint i = 0; i < newMaps; i++)\n array.push();\n }\n\n function writeMap(uint map, uint key, uint value) public {\n array[map][key] = value;\n }\n\n function readMap(uint map, uint key) public view returns (uint) {\n return array[map][key];\n }\n\n function eraseMaps() public {\n delete array;\n }\n}\n\nConsider the example above and the following sequence of calls: allocate(10), writeMap(4, 128, 256).\nAt this point, calling readMap(4, 128) returns 256.\nIf we call eraseMaps, the length of the state variable array is zeroed,\nbut since its mapping elements cannot be zeroed, their information stays alive in the contract’s storage.\nAfter deleting array, calling allocate(5) allows us to access array[4] again,\nand calling readMap(4, 128) returns 256 even without another call to writeMap.\nIf your mapping information must be deleted, consider using a library similar to\niterable mapping,\nallowing you to traverse the keys and delete their values in the appropriate mapping.\n\nInternal Function Pointers in Upgradeable Contracts\nUpdating the code of your contract may invalidate the values of variables of internal function\ntypes.\nConsider such values ephemeral and avoid storing them in state variables.\nIf you do, you must ensure that they never persist across code updates and are never used by\nother contracts having access to the same storage space as a result of a delegatecall or account\nabstraction.\n\nMinor Details\n\nTypes that do not occupy the full 32 bytes might contain “dirty higher order bits”.\nThis is especially important if you access msg.data - it poses a malleability risk:\nYou can craft transactions that call a function f(uint8 x)\nwith a raw byte argument of 0xff000001 and with 0x00000001.\nBoth are fed to the contract and both will look like the number 1 as far as x is concerned,\nbut msg.data will be different, so if you use keccak256(msg.data) for anything,\nyou will get different results.\n\nRecommendations\n\nTake Warnings Seriously\nIf the compiler warns you about something, you should change it.\nEven if you do not think that this particular warning has security implications,\nthere might be another issue buried beneath it.\nAny compiler warning we issue can be silenced by slight changes to the code.\nAlways use the latest version of the compiler to be notified about all recently introduced warnings.\nMessages of type info, issued by the compiler, are not dangerous\nand simply represent extra suggestions and optional information\nthat the compiler thinks might be useful to the user.\n\nRestrict the Amount of Ether\nRestrict the amount of Ether (or other tokens) that can be stored in a smart contract.\nIf your source code, the compiler or the platform has a bug, these funds may be lost.\nIf you want to limit your loss, limit the amount of Ether.\n\nKeep it Small and Modular\nKeep your contracts small and easily understandable.\nSingle out unrelated functionality in other contracts or into libraries.\nGeneral recommendations about the source code quality of course apply:\nLimit the amount of local variables, the length of functions and so on.\nDocument your functions so that others can see what your intention was\nand whether it is different than what the code does.\n\nUse the Checks-Effects-Interactions Pattern\nMost functions will first perform some checks and they should be done first\n(who called the function, are the arguments in range, did they send enough Ether,\ndoes the person have tokens, etc.).\nAs the second step, if all checks passed, effects to the state variables of the current contract should be made.\nInteraction with other contracts should be the very last step in any function.\nEarly contracts delayed some effects and waited for external function calls to return in a non-error state.\nThis is often a serious mistake because of the reentrancy problem explained above.\nNote that, also, calls to known contracts might in turn cause calls to\nunknown contracts, so it is probably better to just always apply this pattern.\n\nInclude a Fail-Safe Mode\nWhile making your system fully decentralized will remove any intermediary,\nit might be a good idea, especially for new code, to include some kind of fail-safe mechanism:\nYou can add a function in your smart contract that performs some self-checks like “Has any Ether leaked?”,\n“Is the sum of the tokens equal to the balance of the contract?” or similar things.\nKeep in mind that you cannot use too much gas for that,\nso help through off-chain computations might be needed there.\nIf the self-check fails, the contract automatically switches into some kind of “failsafe” mode,\nwhich, for example, disables most of the features,\nhands over control to a fixed and trusted third party\nor just converts the contract into a simple “give me back my Ether” contract.\n\nAsk for Peer Review\nThe more people examine a piece of code, the more issues are found.\nAsking people to review your code also helps as a cross-check to find out\nwhether your code is easy to understand -\na very important criterion for good smart contracts.","tokens":4669,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263574396,"hash":"24230feb289073d9aefee21571dcffa4e1fcb181"}
{"url":"https://ethresear.ch/t/big-block-diffusion-and-organic-big-blocks-on-ethereum/17346/2","domain":"ethresear.ch","title":"Big Block Diffusion and Organic Big Blocks on Ethereum - Sharding - Ethereum Research","text":"Sharding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2023\n\n 2 / 2\n\n Nov 2023\n\n Nov 2023\n\n post by leobago on Nov 8, 2023\n\n leobago\n\n This analysis was done by @cskiraly and @leobago, with the support and feedback from @dryajov, @dankrad, @djrtwo, Andrew Davis, and Sam Calder-Mason.\nThe Codex team is working on research around data availability sampling (DAS) for Ethereum scaling. Part of this research is to develop a simulator that can give us some good estimates about how much time it takes to disseminate a huge block of 128 MB (including erasure-coded data) to the entire network. The simulator is already producing results, but in this post we want to focus on two by-products of this research: the characterisation of big block diffusion latency on the existing Ethereum Mainnet and the existence of organic big blocks on Ethereum Mainnet and its implications.\nInflating Blocks Artificially\nEvery simulator needs to be evaluated, at least partially, with a real-world measurement that demonstrates that the results produced by the simulator are accurate. To validate our simulator, we started looking at the data produced by an experiment done by the Ethereum Foundation (EF). The experiment was done on May 28th and June 11th and consisted of injecting big blocks in Ethereum Mainnet. The target block sizes were in a range from 128 KB to 1 MB. The blocks were artificially inflated by adding random bytes using CALLDATA to them through a steady stream of 64 KB transactions. As a reference, the average block size in Ethereum is 100 KB. The objective was to measure the arrival of those big blocks in multiple nodes located in different world regions. More precisely, the EF deployed 15 nodes, called Sentry nodes, in three different continents, the exact locations are: Sydney, Amsterdam and San Francisco, to observe the impact of network latency on attestations and block propagation. The Sentry nodes were all running Xatu, a network monitoring and data pipelining tool. Each location had five nodes running, one for each consensus layer (CL) client: Prysm, Lighthouse, Teku, Nimbus and Lodestar. The exact versions used for each client are described in the following table.\n\nClient\nVersion\n\nPrysm\ndevelop-f1b88d0\n\nLighthouse\nstable-7c0b275\n\nTeku\nmaster-fccbaf1\n\nNimbus\nstable-748be8b\n\nLodestar\nunstable-375d660\n\nStumble on Organic Big Blocks\nAt the same time this DAS research was ongoing, the team at MigaLabs was analysing block sizes and the number of transactions per block, among other data points. By looking at block sizes outside the experiment dates, we discovered that there were many big blocks in the Ethereum Mainnet. After confirming with the EF researchers that those blocks were not artificially inflated, we started looking at how frequent these organic big blocks are. Over the last six months, from March 1st 2023 to August 31st 2023, we have found a total of 109,504 blocks with a size over 250 KB, which is about 8.2% of the 1,323,034 slots in that time period. The biggest block (#17968783) observed during those six months was produced on August 22nd, and it had a size of 2.3 MB, which was very surprising. The maximum gas used in a block is 30,000,000, and the CALLDATA cost is 16 gas per byte, which should lead to a maximum block size of roughly 1.8 MB. However, 16 gas per byte is the cost for non-zero bytes, while zero bytes have a cost of 4 gas. This means that blocks with a large number of zeros in CALLDATA can go over 1.8 MB and in theory, one could even create a block of over 7 MB.\nblockSizeLog-11200×600 26.3 KB\nThe figure above presents the distribution of blocks over 250 KB from March 1st to August 31st; note that we use a logarithmic scale in the y-axis. During those six months, the 15 Sentry nodes were running and recording the exact time blocks were received. That allowed us to do a detailed analysis of the block propagation times depending on their size and geographical location from the perspective of different CL clients.\nImpact of Geographical Location\nWe analyse the time when the block is reported in the three different locations. Note that the three regions are located almost perfectly at 8 hours difference from each other. According to monitorEth, most Ethereum nodes are located in North America, Europe and Asia, giving Europe a central location in the network. The following figure shows the cumulative distribution function (CDF) of the latency in milliseconds for all the blocks over 250 KB as observed by the Lighthouse nodes, for the three different locations.\nlighthouse-geo-11200×600 45.8 KB\nAs we can observe in the figure, the large majority of the blocks arrive between 1 and 4 seconds after the beginning of the slot for all three regions. However, the mean arrival time differs by about 400ms between Amsterdam and Sydney, while San Francisco sits between them at approximately 200ms distance to both. While this difference is not dramatic, a couple of hundred milliseconds do have a non-negligible impact on the node performance, particularly when nodes are under tight deadlines to produce blocks, send attestations and disseminate aggregations. We produced similar figures for the other CL clients, and they show similar results.\nBlock Size Dissemination Times\nFor the DAS research we are doing at Codex, the most exciting result of this discovery is to analyse the propagation time of big blocks in the network. Thus, we took the 100K+ big organic blocks that we found and divided them into bins of 250 KB, starting from a range from 250 KB to 500 KB, the second one from 500 KB to 750 KB, and so on until the last range going from 2000 KB to 2250 KB.\nWe also divide the data of the different CL clients because they report blocks at different moments in the block treatment pipeline, some as soon as they receive it in the p2p network layer (libp2p/GossipSub), some batch multiple network events before treating them, while others report only after the block is fully imported (EL, CL validated and inserted into the block DAG). In other words, our intention here is not to compare the latency of different CL clients. We can’t do that based on the data available currently. To the contrary, we should only compare oranges with oranges and treat different CL results as insight into the timing of other parts of the processing pipeline. Here, we show the results for all five CL clients separately.\nteku-bin-11200×600 69.5 KB\nFor each CL client, we plotted both the CDF (bottom) and the probability distribution function (PDF) (top) of the block propagation latency for different block sizes. Note that the x-axis is logarithmic, starting from 600 ms up to 60,000 ms in some figures. One thing that we observe very clearly in the PDF is that the large majority of the blocks shown in these figures are blocks in the first size range (250 KB - 500 KB). This agrees with the data presented in the block size distribution figure.\nnimbus-bin-11200×600 74.4 KB\nLooking at the CDF, it is clear that the large majority of big blocks are reported between 1 and 8 seconds after the beginning of the slot, except for a few clients that actually report the block after some computationally intensive processing. We also see a clear trend in which bigger blocks take more time to propagate through the network, which is to be expected. However, the distance between block sizes is extremely hard to predict in a p2p network with more than 10,000 nodes distributed worldwide and five different implementations with different optimisation strategies.\nlodestar-bin-11200×600 72.7 KB\nIn these results, we can see that there is approximately a 2-second delay between the 250 KB blocks and the 2250 KB blocks. For instance, looking at the block arrival time for Lighthouse, we can observe that 40% of the blocks in the 250 KB - 500 KB size range have arrived in about 2 seconds, while 40% of the blocks in the 2000 KB - 2250 KB size range arrive in about 4 seconds from the start of the slot.\nnimbus-bin-11200×600 74.4 KB\nSimilarly, looking at Prysm’s 80% line, we can observe the block arrival time shifting from 3 seconds to about 5 seconds, from 250KB to 2000 KB. Overall, these results show that the current Ethereum network can manage to accommodate large blocks from 1 MB and up to 2 MB. This is good news for the upcoming EIP-4844, in which we expect to add blobs of rollup data and the average block size is expected to be around 1 MB.\nprysm-bin-11200×600 72.5 KB\nDetailed Timing\nAs mentioned above, the data shown before was obtained by Sentry nodes running Xatu through the beacon API, and as it turned out during discussions with client teams, each client exposes data on this API differently. Therefore, to further validate some of the results, we focused on a specific client (Nimbus) and slightly modified its code to report detailed timing for each received block, from block arrival to different events of the processing pipeline. The modified code is available here.\nIn 4 days we have collected data for about 25000 blocks as they arrive to a single beacon node deployed in Italy in a home behind a 1000/100 Mbps fibre connection.\nBlocks, when sent over GossipSub, are sent in a compressed form using Snappy compression. These get decompressed, SSZ decoded, and verified before the original compressed version can be forwarded to neighbours in the GossipSub topic mesh. These checks before forwarding are an important part of the protocol to avoid error propagation. After the forwarding checks, further verification and internal processing has to be done in the node. Overall, we collect 8 timing events for each block, each relative to the block’s slot start time: message reception from GossipSub neighbor; Snappy decompression; SSZ decoding; validation for GossipSub forwarding; verification according to beacon chain specification, and a few other internal events irrelevant for our current discussion.\ncompressed640×480 19.8 KB\nWe also collect both compressed and uncompressed block size information. The plots below shows block distribution as a function of uncompressed and compressed size, and the compression ratio’s observed.\nInterestingly, bigger blocks were all arriving with similar compression ratios, hinting to a similar internal block structure, something we plan to investigate further.\ncimpdist1090×860 203 KB\nNext, we look at block reception delays, namely our first timer, when the block arrives from GossipSub, before it gets decompressed. As shown below, these are similar to the behaviour observed previously through the beacon API.\ndist21046×820 248 KB\nAnalyzing block reception delays using size ranges we can also see CDFs similar to the large scale data collection. We have much less data points than previously, since we observe only from a single node and only for a few days. Hence, curves for large blocks are with large steps, and with limited statistical relevance. Still, we can clearly see the increasing delay as a function of block size.\nbindistnim1440×500 59.4 KB\nFinally, we can show the curves as a function of compressed block size. Compressed blocks are what travel on the network, so one might argue that this is most relevant from the networking (bandwidth) perspective. It is clear that most blocks, even those that are 2MB uncompressed, 1.5 MB compressed, can arrive within 4 seconds, even to a home beacon node.\nbindistnimcmop1440×500 48.9 KB\nConclusions\nWe have discovered a large number of big blocks (>250 KB) that occur organically every day in the Ethereum Mainnet. We have measured the propagation time of those blocks in three different world regions and compared their latency based on geographical location as well as block size. We have analyzed how these propagation differences are reflected in the five CL clients separately, as they have different ways of reporting blocks. The empirical results measured in Ethereum Mainnet and presented in this work give us the first clear idea of how block propagation times might look when EIP-4844 is deployed, and 1 MB blocks become the standard and not the exception.\nIn the future, we plan to continue with these block propagation measurements and monitor the behaviour of big blocks in the Ethereum network. Additionally, we want to help different CL clients harmonize their event recording and publication systems in order to be able to compare CL clients between them.\n\n Gossipsub Message Propagation Latency\n\n FullDAS: towards massive scalability with 32MB blocks and beyond\n\n Full DAS Sampling Analysis\n\n Wen fast payload broadcast? Segment, code, push, pull, and everything in between\n\n read \n\n 5\n min\n\n post by abcoathup on Nov 8, 2023\n\n abcoathup\n\n This post adds detailed timing to September post on Codex blog\n\n Powered by Discourse","tokens":3192,"squid":"ink-research","role":"Deep Scholar","at":1791263574436,"hash":"ae804212c3f6613f6d0d5bbd9d99a1550860dd01"}
{"url":"https://docs.arbitrum.io/launch-arbitrum-chain/run-a-node/split-validator-node","domain":"docs.arbitrum.io","title":"Run a split validator node | Arbitrum Docs","text":"✏️Request an updateRunning split validators for Arbitrum chains​\nSplit validators separate the validation work to a stateless validation node, which provides several key benefits:\n\nResource management: Easier to scale and manage compute resources independently\nFault isolation: Prevents database corruption if the validation node crashes (e.g., due to OOM errors)\nFlexibility: Allows running multiple validation nodes for horizontal scalability\n\nThis guide explains how to set up a split validator configuration for Arbitrum chains by running a Nitro node (bonder) and a validation node separately.\nBefore you read this doc, please ensure you have already walked through run a validator docs to understand the basics of a validator node. For an overview of how split validation fits among the other Nitro node roles, see How to assign roles to a Nitro node.\nWhat is AUTH-RPC and the validation API​\nNitro nodes can expose two separate WebSocket RPC interfaces:\n\nThe public RPC (configured under --http.* and --ws.*) serves the standard eth_, net_, and other namespaces that wallets and dApps use.\nAUTH-RPC (configured under --auth.*) is a second, JWT-authenticated WebSocket interface intended for trusted intra-component communication. It listens on its own address and port and by default exposes only the validation namespace.\n\nThe validation_* namespace is how the bonder delegates WASM execution to the validation node—it carries Validate (run the WASM machine on a prepared input and return the resulting global state) plus CreateExecutionRun, GetStepAt, and GetProofAt (used during challenges to fetch step hashes and one-step proofs). The full method list is in the validation_* API reference below.\nThe rest of this guide walks through the deployment; the API reference and the option to expose additional namespaces over AUTH-RPC are at the end.\nPrerequisites​\n\nDocker or Kubernetes with Helm installed\nBonder private key\nChain information JSON for your Arbitrum chain\n\nDocker deployment guide​\nStep 1: Set up the validation node​\nFirst, generate a JWT secret for secure communication:\nxxd -l 32 -ps -c 40 /dev/urandom > /tmp/nitro-val.jwt\nStart the validation node with the JWT secret:\ndocker run --rm -it \\ --entrypoint nitro-val \\ -p 0.0.0.0:5200:5200 \\ offchainlabs/nitro-node:v3.12.1-70fa99a \\ --auth.addr 127.0.0.1 \\ --auth.origins 0.0.0.0 \\ --auth.jwtsecret /tmp/nitro-val.jwt \\ --auth.port 5200 --metrics \\ --metrics-server.addr=0.0.0.0 \\ --metrics-server.port=6070\nThe validation node will listen on port 5200, which will also enable the metrics server on port 6070.\nStep 2: Set up the bonder node​\nCopy the JWT secret to your mount directory:\ncp /tmp/nitro-val.jwt /some/local/dir/arbitrum\nStart the bonder node with the following command, connecting it to your validation node:\ndocker run --rm -it \\ -v /some/local/dir/arbitrum:/home/user/.arbitrum \\ offchainlabs/nitro-node:v3.12.1-70fa99a \\ --parent-chain.connection.url=<parent-chain-endpoint> \\ --node.staker.enable=true \\ --node.staker.strategy=MakeNodes \\ --node.staker.parent-chain-wallet.private-key=<staker_private_key> \\ --chain.info-json=<Your_chain_info> \\ --execution.forwarding-target=<forwarding_target> \\ --node.block-validator.validation-server-configs-list=\"[{\\\"jwtsecret\\\":\\\"/home/user/.arbitrum/nitro-val.jwt\\\",\\\"url\\\":\\\"ws://Your_validation_address\\\"}]\"\nReplace the placeholders with your specific values:\n\n<parent-chain-endpoint>: Your parent chain RPC endpoint\n<staker_private_key>: Your bonder's private key\n<Your_chain_info>: Chain information JSON\n<forwarding_target>: Your forwarding node URL (usually is the sequencer endpoint)\nYour_validation_address: Address of your validation node (including port)\n\nKubernetes deployment with Helm​\nArbitrum provides a community Helm chart for Kubernetes deployment.\nStep 1: Create validation node configuration​\nCreate a file named validation_values.yaml:\nconfigmap: data: parent-chain: id: 1 # Use appropriate parent chain ID connection: url: 'https://your-parent-chain-rpc' execution: forwarding-target: 'https://your-forwarding-node' node: staker: enable: true strategy: 'MakeNodes' parent-chain-wallet: private-key: 'your-staker-private-key' chain: name: 'Your Chain Name' id: 42161 # Your chain ID info-json: '[Your chain info JSON]'jwtSecret: enabled: true value: 'Your 32 bytes hex jwt'validator: enabled: true splitvalidator: deployments: - name: 'current'\nStep 2: Deploy the validation node​\nhelm install nitro-validator offchainlabs/nitro --values validation_values.yaml\nMonitoring and maintenance​\n\nMonitor your bonding and validation node logs regularly:\n# For Dockerdocker logs -f <container_id># For Kuberneteskubectl logs -f <POD>\n\nCheck the status of both the bond and the validation node through the Arbitrum dashboard or API\n\nAdditional configurations for validation nodes​\nTo get a full list of parameters for the validation node, you can run the following command:\ndocker run --rm -it --entrypoint nitro-val offchainlabs/nitro-node:v3.12.1-70fa99a --help\nAdditional configurations for helm charts​\nFor more advanced helm chart configurations, please refer to the Arbitrum community Helm Chart README\nMonitoring​\nTo check if your validation node is running correctly, you can check the rpc_duration_validation_validate_success_count metric in your metrics server.\nThis metric is a counter of the number of successful validation calls; if it is increasing, it means your validation node is running correctly.\nYou can also check where this log (validation node started) appears:\n\nIf this log appears on the validation node, it means your validation node is running correctly.\n\nIf this log appears on the bond node, it means your bond node is still validating itself. It indicates that your bond node is not connecting to the validation node correctly; you need to double-check your configuration.\n\nReference: the validation_* API​\nWhen AUTH-RPC is enabled, the validation node registers the validation namespace, exposing the following methods (all prefixed validation_ in RPC requests):\nMethodPurposevalidation_nameReturns the validation node identifier.validation_capacityReturns the configured concurrent-execution capacity.validation_roomReturns the number of currently available execution slots.validation_validateRuns one validation against a given input and WASM module root.validation_wasmModuleRootsLists the WASM module roots this node can validate.validation_stylusArchsLists the Stylus target architectures the node supports.validation_createExecutionRunStarts a long-running execution and returns an execid handle.validation_getStepAtReturns the machine hash and global state at a given step.validation_getMachineHashesWithStepSizeBatch step-hash lookup, used during challenge resolution.validation_getProofAtReturns the one-step proof at a given step.validation_prepareRangePre-loads execution state for a step range.validation_execKeepAliveHeartbeats an execution run to extend its retention.validation_checkAliveProbes that an execution run is still loaded on the validation node.validation_closeExecReleases an execution run's resources.\nThese methods are internal protocol calls between the bond and the validation node. You normally don't invoke them directly—the bonder calls them automatically when it needs validation work. This reference is most useful for reading logs or debugging connectivity between the two components.\nAdvanced: exposing additional namespaces over AUTH-RPC​\n--auth.api accepts a list of namespaces, not just validation. You can add others—for example, eth or net — if you want to grant a trusted client read access to those APIs without exposing them on the public RPC:\n--auth.api validation,eth,net\nAnything listed here is served on the AUTH-RPC endpoint and gated by the JWT, so the caller must hold the same JWT secret to access it. The endpoint still listens only on --auth.addr (default 127.0.0.1), so keep it on loopback or a private network — JWT authentication alone is not a substitute for network isolation.\nThis is rarely needed for bonders; the main use case is internal services (a custom monitor, an indexer behind your own bastion) that need authenticated read access to the node.\n\nIf this log appears on the bonder node (validator node), it means your bonder node is still validating itself. It indicates that your bonder node is not connecting to the validation node correctly; you need to double-check your configuration.\nRunning split validators for Arbitrum chainsWhat is AUTH-RPC and the validation APIPrerequisitesDocker deployment guideKubernetes deployment with HelmMonitoring and maintenanceAdditional configurations for validation nodesAdditional configurations for helm chartsMonitoringReference: the validation_* APIAdvanced: exposing additional namespaces over AUTH-RPC","tokens":2199,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263585082,"hash":"20c0c2b351fcd5494725551679872a672b0549ae"}
{"url":"https://docs.soliditylang.org/en/develop/abi-spec.html","domain":"docs.soliditylang.org","title":"Contract ABI Specification — Solidity 0.8.38-develop documentation","text":"Contract ABI Specification\n\n Edit on GitHub\n\nContract ABI Specification\n\nBasic Design\nThe Contract Application Binary Interface (ABI) is the standard way to interact with contracts in the Ethereum ecosystem, both\nfrom outside the blockchain and for contract-to-contract interaction. Data is encoded according to its type,\nas described in this specification. The encoding is not self describing and thus requires a schema in order to decode.\nWe assume that the interface functions of a contract are strongly typed, known at compilation time and static.\nWe assume that all contracts will have the interface definitions of any contracts they call available at compile-time.\nThis specification does not address contracts whose interface is dynamic or otherwise known only at run-time. Also, the ABI specification for libraries is slightly different.\n\nFunction Selector\nThe first four bytes of the call data for a function call specifies the function to be called. It is the\nfirst (left, high-order in big-endian) four bytes of the Keccak-256 hash of the signature of\nthe function. The signature is defined as the canonical expression of the basic prototype without data\nlocation specifier, i.e.\nthe function name with the parenthesised list of parameter types. Parameter types are split by a single\ncomma — no spaces are used.\n\nNote\nThe return type of a function is not part of this signature. In\nSolidity’s function overloading return types are not considered.\nThe reason is to keep function call resolution context-independent.\nThe JSON description of the ABI however contains both inputs and outputs.\n\nArgument Encoding\nStarting from the fifth byte, the encoded arguments follow. This encoding is also used in\nother places, e.g. the return values and also event arguments are encoded in the same way,\nwithout the four bytes specifying the function.\n\nTypes\nNote that the library ABIs can take types different than below e.g. for non-storage structs. See library selectors for details.\nThe following elementary types exist:\n\nuint<M>: unsigned integer type of M bits, 0 < M <= 256, M % 8 == 0. e.g. uint32, uint8, uint256.\nint<M>: two’s complement signed integer type of M bits, 0 < M <= 256, M % 8 == 0.\naddress: equivalent to uint160, except for the assumed interpretation and language typing.\nFor computing the function selector, address is used.\nuint, int: synonyms for uint256, int256 respectively. For computing the function\nselector, uint256 and int256 have to be used.\nbool: equivalent to uint8 restricted to the values 0 and 1. For computing the function selector, bool is used.\nfixed<M>x<N>: signed fixed-point decimal number of M bits, 8 <= M <= 256,\nM % 8 == 0, and 0 < N <= 80, which denotes the value v as v / (10 ** N).\nufixed<M>x<N>: unsigned variant of fixed<M>x<N>.\nfixed, ufixed: synonyms for fixed128x18, ufixed128x18 respectively. For\ncomputing the function selector, fixed128x18 and ufixed128x18 have to be used.\nbytes<M>: binary type of M bytes, 0 < M <= 32.\nfunction: an address (20 bytes) followed by a function selector (4 bytes). Encoded identical to bytes24.\n\nThe following (fixed-size) array type exists:\n\n<type>[M]: a fixed-length array of M elements, M >= 0, of the given type.\n\nNote\nWhile this ABI specification can express fixed-length arrays with zero elements, they’re not supported by the compiler.\n\nThe following non-fixed-size types exist:\n\nbytes: dynamic sized byte sequence.\nstring: dynamic sized unicode string assumed to be UTF-8 encoded.\n<type>[]: a variable-length array of elements of the given type.\n\nTypes can be combined to a tuple by enclosing them inside parentheses, separated by commas:\n\n(T1,T2,...,Tn): tuple consisting of the types T1, …, Tn, n >= 0\n\nIt is possible to form tuples of tuples, arrays of tuples and so on. It is also possible to form zero-tuples (where n == 0).\n\nMapping Solidity to ABI types\nSolidity supports all the types presented above with the same names with the\nexception of tuples. On the other hand, some Solidity types are not supported\nby the ABI. The following table shows on the left column Solidity types that\nare not part of the ABI, and on the right column the ABI types that represent\nthem.\n\nSolidity\nABI\n\naddress payable\naddress\n\ncontract\naddress\n\nenum\nuint8\n\nuser defined value types\nits underlying value type\n\nstruct\ntuple\n\nWarning\nBefore version 0.8.0 enums could have more than 256 members and were represented by the\nsmallest integer type just big enough to hold the value of any member.\n\nDesign Criteria for the Encoding\nThe encoding is designed to have the following properties, which are especially useful if some arguments are nested arrays:\n\nThe number of reads necessary to access a value is at most the depth of the value\ninside the argument array structure, i.e. four reads are needed to retrieve a_i[k][l][r]. In a\nprevious version of the ABI, the number of reads scaled linearly with the total number of dynamic\nparameters in the worst case.\nThe data of a variable or an array element is not interleaved with other data and it is\nrelocatable, i.e. it only uses relative “addresses”.\n\nFormal Specification of the Encoding\nWe distinguish static and dynamic types. Static types are encoded in-place and dynamic types are\nencoded at a separately allocated location after the current block.\nDefinition: The following types are called “dynamic”:\n\nbytes\nstring\nT[] for any T\nT[k] for any dynamic T and any k >= 0\n(T1,...,Tk) if Ti is dynamic for some 1 <= i <= k\n\nAll other types are called “static”.\nDefinition: len(a) is the number of bytes in a binary string a.\nThe type of len(a) is assumed to be uint256.\nWe define enc, the actual encoding, as a mapping of values of the ABI types to binary strings such\nthat len(enc(X)) depends on the value of X if and only if the type of X is dynamic.\nDefinition: For any ABI value X, we recursively define enc(X), depending\non the type of X being\n\n(T1,...,Tk) for k >= 0 and any types T1, …, Tk\nenc(X) = head(X(1)) ... head(X(k)) tail(X(1)) ... tail(X(k))\nwhere X = (X(1), ..., X(k)) and\nhead and tail are defined for Ti as follows:\nif Ti is static:\n\nhead(X(i)) = enc(X(i)) and tail(X(i)) = \"\" (the empty string)\n\notherwise, i.e. if Ti is dynamic:\n\nhead(X(i)) = enc(len( head(X(1)) ... head(X(k)) tail(X(1)) ... tail(X(i-1)) ))\ntail(X(i)) = enc(X(i))\n\nNote that in the dynamic case, head(X(i)) is well-defined since the lengths of\nthe head parts only depend on the types and not the values. The value of head(X(i)) is the offset\nof the beginning of tail(X(i)) relative to the start of enc(X).\n\nT[k] for any T and k:\nenc(X) = enc((X[0], ..., X[k-1]))\ni.e. it is encoded as if it were a tuple with k elements\nof the same type.\n\nT[] where X has k elements (k is assumed to be of type uint256):\nenc(X) = enc(k) enc((X[0], ..., X[k-1]))\ni.e. it is encoded as if it were a tuple with k elements of the same type (resp. an array of static size k), prefixed with\nthe number of elements.\n\nbytes, of length k (which is assumed to be of type uint256):\nenc(X) = enc(k) pad_right(X), i.e. the number of bytes is encoded as a\nuint256 followed by the actual value of X as a byte sequence, followed by\nthe minimum number of zero-bytes such that len(enc(X)) is a multiple of 32.\n\nstring:\nenc(X) = enc(enc_utf8(X)), i.e. X is UTF-8 encoded and this value is interpreted\nas of bytes type and encoded further. Note that the length used in this subsequent\nencoding is the number of bytes of the UTF-8 encoded string, not its number of characters.\n\nuint<M>: enc(X) is the big-endian encoding of X, padded on the higher-order\n(left) side with zero-bytes such that the length is 32 bytes.\naddress: as in the uint160 case\nint<M>: enc(X) is the big-endian two’s complement encoding of X, padded on the higher-order (left) side with 0xff bytes for negative X and with zero-bytes for non-negative X such that the length is 32 bytes.\nbool: as in the uint8 case, where 1 is used for true and 0 for false\nfixed<M>x<N>: enc(X) is enc(X * 10**N) where X * 10**N is interpreted as a int256.\nfixed: as in the fixed128x18 case\nufixed<M>x<N>: enc(X) is enc(X * 10**N) where X * 10**N is interpreted as a uint256.\nufixed: as in the ufixed128x18 case\nbytes<M>: enc(X) is the sequence of bytes in X padded with trailing zero-bytes to a length of 32 bytes.\n\nNote that for any X, len(enc(X)) is a multiple of 32.\n\nFunction Selector and Argument Encoding\nAll in all, a call to the function f with parameters a_1, ..., a_n is encoded as\n\nfunction_selector(f) enc((a_1, ..., a_n))\n\nand the return values v_1, ..., v_k of f are encoded as\n\nenc((v_1, ..., v_k))\n\ni.e. the values are combined into a tuple and encoded.\n\nExamples\nGiven the contract:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract Foo {\n function bar(bytes3[2] memory) public pure {}\n function baz(uint32 x, bool y) public pure returns (bool r) { r = x > 32 || y; }\n function sam(bytes memory, bool, uint[] memory) public pure {}\n}\n\nThus, for our Foo example, if we wanted to call bar with the argument [\"abc\", \"def\"], we would pass 68 bytes total, broken down into:\n\n0xfce353f6: the Method ID. This is derived from the signature bar(bytes3[2]).\n0x6162630000000000000000000000000000000000000000000000000000000000: the first part of the first\nparameter, a bytes3 value \"abc\" (left-aligned).\n0x6465660000000000000000000000000000000000000000000000000000000000: the second part of the first\nparameter, a bytes3 value \"def\" (left-aligned).\n\nIn total:\n0xfce353f661626300000000000000000000000000000000000000000000000000000000006465660000000000000000000000000000000000000000000000000000000000\n\nIf we wanted to call baz with the parameters 69 and\ntrue, we would pass 68 bytes total, which can be broken down into:\n\n0xcdcd77c0: the Method ID. This is derived as the first 4 bytes of the Keccak hash of\nthe ASCII form of the signature baz(uint32,bool).\n0x0000000000000000000000000000000000000000000000000000000000000045: the first parameter,\na uint32 value 69 padded to 32 bytes\n0x0000000000000000000000000000000000000000000000000000000000000001: the second parameter - boolean\ntrue, padded to 32 bytes\n\nIn total:\n0xcdcd77c000000000000000000000000000000000000000000000000000000000000000450000000000000000000000000000000000000000000000000000000000000001\n\nIt returns a single bool. If, for example, it were to return false, its output would be\nthe single byte array 0x0000000000000000000000000000000000000000000000000000000000000000, a single bool.\nIf we wanted to call sam with the arguments \"dave\", true and [1,2,3], we would\npass 292 bytes total, broken down into:\n\n0xa5643bf2: the Method ID. This is derived from the signature sam(bytes,bool,uint256[]). Note that uint is replaced with its canonical representation uint256.\n0x0000000000000000000000000000000000000000000000000000000000000060: the location of the data part of the first parameter (dynamic type), measured in bytes from the start of the arguments block. In this case, 0x60.\n0x0000000000000000000000000000000000000000000000000000000000000001: the second parameter: boolean true.\n0x00000000000000000000000000000000000000000000000000000000000000a0: the location of the data part of the third parameter (dynamic type), measured in bytes. In this case, 0xa0.\n0x0000000000000000000000000000000000000000000000000000000000000004: the data part of the first argument, it starts with the length of the byte array in elements, in this case, 4.\n0x6461766500000000000000000000000000000000000000000000000000000000: the contents of the first argument: the UTF-8 (equal to ASCII in this case) encoding of \"dave\", padded on the right to 32 bytes.\n0x0000000000000000000000000000000000000000000000000000000000000003: the data part of the third argument, it starts with the length of the array in elements, in this case, 3.\n0x0000000000000000000000000000000000000000000000000000000000000001: the first entry of the third parameter.\n0x0000000000000000000000000000000000000000000000000000000000000002: the second entry of the third parameter.\n0x0000000000000000000000000000000000000000000000000000000000000003: the third entry of the third parameter.\n\nIn total:\n0xa5643bf20000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000464617665000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000003\n\nUse of Dynamic Types\nA call to a function with the signature f(uint256,uint32[],bytes10,bytes) with values\n(0x123, [0x456, 0x789], \"1234567890\", \"Hello, world!\") is encoded in the following way:\nWe take the first four bytes of keccak(\"f(uint256,uint32[],bytes10,bytes)\"), i.e. 0x8be65246.\nThen we encode the head parts of all four arguments. For the static types uint256 and bytes10,\nthese are directly the values we want to pass, whereas for the dynamic types uint32[] and bytes,\nwe use the offset in bytes to the start of their data area, measured from the start of the value\nencoding (i.e. not counting the first four bytes containing the hash of the function signature). These are:\n\n0x0000000000000000000000000000000000000000000000000000000000000123 (0x123 padded to 32 bytes)\n0x0000000000000000000000000000000000000000000000000000000000000080 (offset to start of data part of second parameter, 4*32 bytes, exactly the size of the head part)\n0x3132333435363738393000000000000000000000000000000000000000000000 (\"1234567890\" padded to 32 bytes on the right)\n0x00000000000000000000000000000000000000000000000000000000000000e0 (offset to start of data part of fourth parameter = offset to start of data part of first dynamic parameter + size of data part of first dynamic parameter = 4*32 + 3*32 (see below))\n\nAfter this, the data part of the first dynamic argument, [0x456, 0x789] follows:\n\n0x0000000000000000000000000000000000000000000000000000000000000002 (number of elements of the array, 2)\n0x0000000000000000000000000000000000000000000000000000000000000456 (first element)\n0x0000000000000000000000000000000000000000000000000000000000000789 (second element)\n\nFinally, we encode the data part of the second dynamic argument, \"Hello, world!\":\n\n0x000000000000000000000000000000000000000000000000000000000000000d (number of elements (bytes in this case): 13)\n0x48656c6c6f2c20776f726c642100000000000000000000000000000000000000 (\"Hello, world!\" padded to 32 bytes on the right)\n\nAll together, the encoding is (newline after function selector and each 32-bytes for clarity):\n0x8be65246\n 0000000000000000000000000000000000000000000000000000000000000123\n 0000000000000000000000000000000000000000000000000000000000000080\n 3132333435363738393000000000000000000000000000000000000000000000\n 00000000000000000000000000000000000000000000000000000000000000e0\n 0000000000000000000000000000000000000000000000000000000000000002\n 0000000000000000000000000000000000000000000000000000000000000456\n 0000000000000000000000000000000000000000000000000000000000000789\n 000000000000000000000000000000000000000000000000000000000000000d\n 48656c6c6f2c20776f726c642100000000000000000000000000000000000000\n\nLet us apply the same principle to encode the data for a function with a signature g(uint256[][],string[])\nwith values ([[1, 2], [3]], [\"one\", \"two\", \"three\"]) but start from the most atomic parts of the encoding:\nFirst we encode the length and data of the first embedded dynamic array [1, 2] of the first root array [[1, 2], [3]]:\n\n0x0000000000000000000000000000000000000000000000000000000000000002 (number of elements in the first array, 2; the elements themselves are 1 and 2)\n0x0000000000000000000000000000000000000000000000000000000000000001 (first element)\n0x0000000000000000000000000000000000000000000000000000000000000002 (second element)\n\nThen we encode the length and data of the second embedded dynamic array [3] of the first root array [[1, 2], [3]]:\n\n0x0000000000000000000000000000000000000000000000000000000000000001 (number of elements in the second array, 1; the element is 3)\n0x0000000000000000000000000000000000000000000000000000000000000003 (first element)\n\nThen we need to find the offsets a and b for their respective dynamic arrays [1, 2] and [3].\nTo calculate the offsets we can take a look at the encoded data of the first root array [[1, 2], [3]]\nenumerating each line in the encoding:\n0 - a - offset of [1, 2]\n1 - b - offset of [3]\n2 - 0000000000000000000000000000000000000000000000000000000000000002 - count for [1, 2]\n3 - 0000000000000000000000000000000000000000000000000000000000000001 - encoding of 1\n4 - 0000000000000000000000000000000000000000000000000000000000000002 - encoding of 2\n5 - 0000000000000000000000000000000000000000000000000000000000000001 - count for [3]\n6 - 0000000000000000000000000000000000000000000000000000000000000003 - encoding of 3\n\nOffset a points to the start of the content of the array [1, 2] which is line\n2 (64 bytes); thus a = 0x0000000000000000000000000000000000000000000000000000000000000040.\nOffset b points to the start of the content of the array [3] which is line 5 (160 bytes);\nthus b = 0x00000000000000000000000000000000000000000000000000000000000000a0.\nThen we encode the embedded strings of the second root array:\n\n0x0000000000000000000000000000000000000000000000000000000000000003 (number of characters in word \"one\")\n0x6f6e650000000000000000000000000000000000000000000000000000000000 (utf8 representation of word \"one\")\n0x0000000000000000000000000000000000000000000000000000000000000003 (number of characters in word \"two\")\n0x74776f0000000000000000000000000000000000000000000000000000000000 (utf8 representation of word \"two\")\n0x0000000000000000000000000000000000000000000000000000000000000005 (number of characters in word \"three\")\n0x7468726565000000000000000000000000000000000000000000000000000000 (utf8 representation of word \"three\")\n\nIn parallel to the first root array, since strings are dynamic elements we need to find their offsets c, d and e:\n0 - c - offset for \"one\"\n1 - d - offset for \"two\"\n2 - e - offset for \"three\"\n3 - 0000000000000000000000000000000000000000000000000000000000000003 - count for \"one\"\n4 - 6f6e650000000000000000000000000000000000000000000000000000000000 - encoding of \"one\"\n5 - 0000000000000000000000000000000000000000000000000000000000000003 - count for \"two\"\n6 - 74776f0000000000000000000000000000000000000000000000000000000000 - encoding of \"two\"\n7 - 0000000000000000000000000000000000000000000000000000000000000005 - count for \"three\"\n8 - 7468726565000000000000000000000000000000000000000000000000000000 - encoding of \"three\"\n\nOffset c points to the start of the content of the string \"one\" which is line 3 (96 bytes);\nthus c = 0x0000000000000000000000000000000000000000000000000000000000000060.\nOffset d points to the start of the content of the string \"two\" which is line 5 (160 bytes);\nthus d = 0x00000000000000000000000000000000000000000000000000000000000000a0.\nOffset e points to the start of the content of the string \"three\" which is line 7 (224 bytes);\nthus e = 0x00000000000000000000000000000000000000000000000000000000000000e0.\nNote that the encodings of the embedded elements of the root arrays are not dependent on each other\nand have the same encodings for a function with a signature g(string[],uint256[][]).\nThen we encode the length of the first root array:\n\n0x0000000000000000000000000000000000000000000000000000000000000002 (number of elements in the first root array, 2; the elements themselves are [1, 2] and [3])\n\nThen we encode the length of the second root array:\n\n0x0000000000000000000000000000000000000000000000000000000000000003 (number of strings in the second root array, 3; the strings themselves are \"one\", \"two\" and \"three\")\n\nFinally we find the offsets f and g for their respective root dynamic arrays [[1, 2], [3]] and\n[\"one\", \"two\", \"three\"], and assemble parts in the correct order:\n0x2289b18c - function signature\n 0 - f - offset of [[1, 2], [3]]\n 1 - g - offset of [\"one\", \"two\", \"three\"]\n 2 - 0000000000000000000000000000000000000000000000000000000000000002 - count for [[1, 2], [3]]\n 3 - 0000000000000000000000000000000000000000000000000000000000000040 - offset of [1, 2]\n 4 - 00000000000000000000000000000000000000000000000000000000000000a0 - offset of [3]\n 5 - 0000000000000000000000000000000000000000000000000000000000000002 - count for [1, 2]\n 6 - 0000000000000000000000000000000000000000000000000000000000000001 - encoding of 1\n 7 - 0000000000000000000000000000000000000000000000000000000000000002 - encoding of 2\n 8 - 0000000000000000000000000000000000000000000000000000000000000001 - count for [3]\n 9 - 0000000000000000000000000000000000000000000000000000000000000003 - encoding of 3\n10 - 0000000000000000000000000000000000000000000000000000000000000003 - count for [\"one\", \"two\", \"three\"]\n11 - 0000000000000000000000000000000000000000000000000000000000000060 - offset for \"one\"\n12 - 00000000000000000000000000000000000000000000000000000000000000a0 - offset for \"two\"\n13 - 00000000000000000000000000000000000000000000000000000000000000e0 - offset for \"three\"\n14 - 0000000000000000000000000000000000000000000000000000000000000003 - count for \"one\"\n15 - 6f6e650000000000000000000000000000000000000000000000000000000000 - encoding of \"one\"\n16 - 0000000000000000000000000000000000000000000000000000000000000003 - count for \"two\"\n17 - 74776f0000000000000000000000000000000000000000000000000000000000 - encoding of \"two\"\n18 - 0000000000000000000000000000000000000000000000000000000000000005 - count for \"three\"\n19 - 7468726565000000000000000000000000000000000000000000000000000000 - encoding of \"three\"\n\nOffset f points to the start of the content of the array [[1, 2], [3]] which is line 2 (64 bytes);\nthus f = 0x0000000000000000000000000000000000000000000000000000000000000040.\nOffset g points to the start of the content of the array [\"one\", \"two\", \"three\"] which is line 10 (320 bytes);\nthus g = 0x0000000000000000000000000000000000000000000000000000000000000140.\n\nEvents\nEvents are an abstraction of the Ethereum logging/event-watching protocol. Log entries provide the contract’s\naddress, a series of up to four topics and some arbitrary length binary data. Events leverage the existing function\nABI in order to interpret this (together with an interface spec) as a properly typed structure.\nGiven an event name and series of event parameters, we split them into two sub-series: those which are indexed and\nthose which are not.\nThose which are indexed, which may number up to 3 (for non-anonymous events) or 4 (for anonymous ones), are used\nalongside the Keccak hash of the event signature to form the topics of the log entry.\nThose which are not indexed form the byte array of the event.\nIn effect, a log entry using this ABI is described as:\n\naddress: the address of the contract (intrinsically provided by Ethereum);\ntopics[0]: keccak(EVENT_NAME+\"(\"+EVENT_ARGS.map(canonical_type_of).join(\",\")+\")\") (canonical_type_of\nis a function that simply returns the canonical type of a given argument, e.g. for uint indexed foo, it would\nreturn uint256). This value is only present in topics[0] if the event is not declared as anonymous;\ntopics[n]: abi_encode(EVENT_INDEXED_ARGS[n - 1]) if the event is not declared as anonymous\nor abi_encode(EVENT_INDEXED_ARGS[n]) if it is (EVENT_INDEXED_ARGS is the series of EVENT_ARGS that\nare indexed);\ndata: ABI encoding of EVENT_NON_INDEXED_ARGS (EVENT_NON_INDEXED_ARGS is the series of EVENT_ARGS\nthat are not indexed, abi_encode is the ABI encoding function used for returning a series of typed values\nfrom a function, as described above).\n\nFor all types of length at most 32 bytes, the EVENT_INDEXED_ARGS array contains\nthe value directly, padded or sign-extended (for signed integers) to 32 bytes, just as for regular ABI encoding.\nHowever, for all “complex” types or types of dynamic length, including all arrays, string, bytes and structs,\nEVENT_INDEXED_ARGS will contain the Keccak hash of a special in-place encoded value\n(see Encoding of Indexed Event Parameters), rather than the encoded value directly.\nThis allows applications to efficiently query for values of dynamic-length types\n(by setting the hash of the encoded value as the topic), but leaves applications unable\nto decode indexed values they have not queried for. For dynamic-length types,\napplication developers face a trade-off between fast search for predetermined values\n(if the argument is indexed) and legibility of arbitrary values (which requires that\nthe arguments not be indexed). Developers may overcome this tradeoff and achieve both\nefficient search and arbitrary legibility by defining events with two arguments — one\nindexed, one not — intended to hold the same value.\n\nErrors\nIn case of a failure inside a contract, the contract can use a special opcode to abort execution and revert\nall state changes. In addition to these effects, descriptive data can be returned to the caller.\nThis descriptive data is the encoding of an error and its arguments in the same way as data for a function\ncall.\nAs an example, let us consider the following contract whose transfer function always\nreverts with a custom error of “insufficient balance”:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract TestToken {\n error InsufficientBalance(uint256 available, uint256 required);\n function transfer(address /*to*/, uint amount) public pure {\n revert InsufficientBalance(0, amount);\n }\n}\n\nThe return data would be encoded in the same way as the function call\nInsufficientBalance(0, amount) to the function InsufficientBalance(uint256,uint256),\ni.e. 0xcf479181, uint256(0), uint256(amount).\nThe error selectors 0x00000000 and 0xffffffff are reserved for future use.\n\nWarning\nNever trust error data.\nThe error data by default bubbles up through the chain of external calls, which\nmeans that a contract may receive an error not defined in any of the contracts\nit calls directly.\nFurthermore, any contract can fake any error by returning data that matches\nan error signature, even if the error is not defined anywhere.\n\nJSON\nThe JSON format for a contract’s interface is given by an array of function, event and error descriptions.\nA function description is a JSON object with the fields:\n\ntype: \"function\", \"constructor\", \"receive\" (the “receive Ether” function) or \"fallback\" (the “default” function);\nname: the name of the function;\ninputs: an array of objects, each of which contains:\n\nname: the name of the parameter.\ntype: the canonical type of the parameter (more below).\ncomponents: used for tuple types (more below).\n\noutputs: an array of objects similar to inputs.\nstateMutability: a string with one of the following values: pure (specified to not read\nblockchain state), view (specified to not modify the blockchain\nstate), nonpayable (function does not accept Ether - the default) and payable (function accepts Ether).\n\nConstructor, receive, and fallback never have name or outputs. Receive and fallback do not have inputs either.\n\nNote\nSending non-zero Ether to non-payable function will revert the transaction.\n\nNote\nThe state mutability nonpayable is reflected in Solidity by not specifying\na state mutability modifier at all.\n\nAn event description is a JSON object with fairly similar fields:\n\ntype: always \"event\"\nname: the name of the event.\ninputs: an array of objects, each of which contains:\n\nname: the name of the parameter.\ntype: the canonical type of the parameter (more below).\ncomponents: used for tuple types (more below).\nindexed: true if the field is part of the log’s topics, false if it is one of the log’s data segments.\n\nanonymous: true if the event was declared as anonymous.\n\nErrors look as follows:\n\ntype: always \"error\"\nname: the name of the error.\ninputs: an array of objects, each of which contains:\n\nname: the name of the parameter.\ntype: the canonical type of the parameter (more below).\ncomponents: used for tuple types (more below).\n\nNote\nThere can be multiple errors with the same name and even with identical signature\nin the JSON array; for example, if the errors originate from different\nfiles in the smart contract or are referenced from another smart contract.\nFor the ABI, only the name of the error itself is relevant and not where it is\ndefined.\n\nFor example,\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract Test {\n constructor() { b = hex\"12345678901234567890123456789012\"; }\n event Event(uint indexed a, bytes32 b);\n event Event2(uint indexed a, bytes32 b);\n error InsufficientBalance(uint256 available, uint256 required);\n function foo(uint a) public { emit Event(a, b); }\n bytes32 b;\n}\n\nwould result in the JSON:\n[{\n\"type\":\"error\",\n\"inputs\": [{\"name\":\"available\",\"type\":\"uint256\"},{\"name\":\"required\",\"type\":\"uint256\"}],\n\"name\":\"InsufficientBalance\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event\"\n}, {\n\"type\":\"event\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\",\"indexed\":true},{\"name\":\"b\",\"type\":\"bytes32\",\"indexed\":false}],\n\"name\":\"Event2\"\n}, {\n\"type\":\"function\",\n\"inputs\": [{\"name\":\"a\",\"type\":\"uint256\"}],\n\"name\":\"foo\",\n\"outputs\": []\n}]\n\nHandling tuple types\nDespite the fact that names are intentionally not part of the ABI encoding, they do make a lot of sense to be included\nin the JSON to enable displaying it to the end user. The structure is nested in the following way:\nAn object with members name, type and potentially components describes a typed variable.\nThe canonical type is determined until a tuple type is reached and the string description up\nto that point is stored in type prefix with the word tuple, i.e. it will be tuple followed by\na sequence of [] and [k] with\nintegers k. The components of the tuple are then stored in the member components,\nwhich is of an array type and has the same structure as the top-level object except that\nindexed is not allowed there.\nAs an example, the code\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.5 <0.9.0;\npragma abicoder v2;\n\ncontract Test {\n struct S { uint a; uint[] b; T[] c; }\n struct T { uint x; uint y; }\n function f(S memory, T memory, uint) public pure {}\n function g() public pure returns (S memory, T memory, uint) {}\n}\n\nwould result in the JSON:\n[\n {\n \"name\": \"f\",\n \"type\": \"function\",\n \"inputs\": [\n {\n \"name\": \"s\",\n \"type\": \"tuple\",\n \"components\": [\n {\n \"name\": \"a\",\n \"type\": \"uint256\"\n },\n {\n \"name\": \"b\",\n \"type\": \"uint256[]\"\n },\n {\n \"name\": \"c\",\n \"type\": \"tuple[]\",\n \"components\": [\n {\n \"name\": \"x\",\n \"type\": \"uint256\"\n },\n {\n \"name\": \"y\",\n \"type\": \"uint256\"\n }\n ]\n }\n ]\n },\n {\n \"name\": \"t\",\n \"type\": \"tuple\",\n \"components\": [\n {\n \"name\": \"x\",\n \"type\": \"uint256\"\n },\n {\n \"name\": \"y\",\n \"type\": \"uint256\"\n }\n ]\n },\n {\n \"name\": \"a\",\n \"type\": \"uint256\"\n }\n ],\n \"outputs\": []\n }\n]\n\nStrict Encoding Mode\nStrict encoding mode is the mode that leads to exactly the same encoding as defined in the formal specification above.\nThis means that offsets have to be as small as possible while still not creating overlaps in the data areas, and thus no gaps are\nallowed.\nUsually, ABI decoders are written in a straightforward way by just following offset pointers, but some decoders\nmight enforce strict mode. The Solidity ABI decoder currently does not enforce strict mode, but the encoder\nalways creates data in strict mode.\n\nNon-standard Packed Mode\nThrough abi.encodePacked(), Solidity supports a non-standard packed mode where:\n\ntypes shorter than 32 bytes are concatenated directly, without padding or sign extension\ndynamic types are encoded in-place and without the length.\narray elements are padded, but still encoded in-place\n\nFurthermore, structs as well as nested arrays are not supported.\nAs an example, the encoding of int16(-1), bytes1(0x42), uint16(0x03), string(\"Hello, world!\") results in:\n0xffff42000348656c6c6f2c20776f726c6421\n ^^^^ int16(-1)\n ^^ bytes1(0x42)\n ^^^^ uint16(0x03)\n ^^^^^^^^^^^^^^^^^^^^^^^^^^ string(\"Hello, world!\") without a length field\n\nMore specifically:\n\nDuring the encoding, everything is encoded in-place. This means that there is\nno distinction between head and tail, as in the ABI encoding, and the length\nof an array is not encoded.\nThe direct arguments of abi.encodePacked are encoded without padding,\nas long as they are not arrays (or string or bytes).\nThe encoding of an array is the concatenation of the\nencoding of its elements with padding.\nDynamically-sized types like string, bytes or uint[] are encoded\nwithout their length field.\nThe encoding of string or bytes does not apply padding at the end,\nunless it is part of an array or struct (then it is padded to a multiple of\n32 bytes).\n\nIn general, the encoding is ambiguous as soon as there are two dynamically-sized elements,\nbecause of the missing length field.\nIf padding is needed, explicit type conversions can be used: abi.encodePacked(uint16(0x12)) == hex\"0012\".\nSince packed encoding is not used when calling functions, there is no special support\nfor prepending a function selector. Since the encoding is ambiguous, there is no decoding function.\n\nWarning\nIf you use keccak256(abi.encodePacked(a, b)) and both a and b are dynamic types,\nit is easy to craft collisions in the hash value by moving parts of a into b and\nvice-versa. More specifically, abi.encodePacked(\"a\", \"bc\") == abi.encodePacked(\"ab\", \"c\").\nIf you use abi.encodePacked for signatures, authentication or data integrity, make\nsure to always use the same types and check that at most one of them is dynamic.\nUnless there is a compelling reason, abi.encode should be preferred.\n\nEncoding of Indexed Event Parameters\nIndexed event parameters that are not value types, i.e. arrays and structs are not\nstored directly but instead a Keccak-256 hash of an encoding is stored. This encoding\nis defined as follows:\n\nthe encoding of a bytes and string value is just the string contents\nwithout any padding or length prefix.\nthe encoding of a struct is the concatenation of the encoding of its members,\nalways padded to a multiple of 32 bytes (even bytes and string).\nthe encoding of an array (both dynamically- and statically-sized) is\nthe concatenation of the encoding of its elements, always padded to a multiple\nof 32 bytes (even bytes and string) and without any length prefix\n\nIn the above, as usual, a negative number is padded by sign extension and not zero padded.\nbytesNN types are padded on the right while uintNN / intNN are padded on the left.\n\nWarning\nThe encoding of a struct is ambiguous if it contains more than one dynamically-sized\narray. Because of that, always re-check the event data and do not rely on the search result\nbased on the indexed parameters alone.","tokens":8720,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263596576,"hash":"44c47543a8339ba9d8d9bbdcc589f7d9e46b6661"}
{"url":"https://ethresear.ch/t/faster-block-blob-propagation-in-ethereum/21370","domain":"ethresear.ch","title":"Faster block/blob propagation in Ethereum - Networking - Ethereum Research","text":"Faster block/blob propagation in Ethereum \n\n Networking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2025\n\n 1 / 55\n\n Jan 2025\n\n Feb 6\n\n post by potuz on Jan 3, 2025\n\n potuz\n\n Faster block/blob propagation in Ethereum\nAcknowledgements to @n1shantd, @ppopth and Ben Berger for discussions and feedback on this writeup and @dankrad for many useful discussions.\nAbstract\nWe propose a change on the way we broadcast and transfer blocks and blobs in the P2P network, by using random linear network coding. We show that we can theoretically distribute the block consuming 5% of the bandwidth and with 57% of the number of network hops (thus half the latency per message) of the time it takes on the current gossipsub implementation. We provide specific benchmarks to the computational overhead.\nIntroduction\nThe current gossipsub mechanism for distribution of blocks roughly works as follows. The proposer picks a random subset (called its Mesh) of D=8 peers among all of its peers and broadcasts its block to them. Each peer receiving a block performs some very fast preliminary validation: mostly signature verification, but most importantly not including state transition nor execution of transactions. After this fast validation, the peer rebroadcasts its block to another D peers. There are two immediate consequences from such a design:\n\nEach hop adds at least the following delay: one full block transfer from one peer to the next one (including both network ping latency, essentially bandwidth independent, plus transfer of the full block, bound by bandwidth).\nPeers broadcast unnecessarily a full block to other peers that have already received the full block.\n\nWe propose to use random linear network coding (RLNC) at the broadcast level. With this coding, the proposer would split the block in N chunks (eg. N=10 for all simulations below) and instead of sending a full block to ~8 peers, it will send a single chunk to ~40 peers (not one of the original chunks, but rather a random linear combination of them, see below for privacy considerations). Peers still need to download a full block, or rather N chunks, but they can get them in parallel from different peers. After they have received these N chunks that each is a random linear combination of the original chunks composing the original block, peers need to solve a linear system of equations to recover the full block.\nA proof of concept implementation highlights the following numbers\n\nProposing a block takes extra 26ms that are CPU bound and can be fully parallelized to less than 2ms on a modern laptop (Apple M4 Pro)\nVerifying each chunk takes 2.6ms.\nDecoding the full block takes 1.4ms.\nWith 10 chunks and D=40, each node sends half the data than with current gossipsub and the network broadcasts a 100KB block in half the time with benefits increasing with block size.\n\nThe protocol\nFor an in-depth introduction to network coding we refer the reader op. cit. and this textbook. We here mention minimal implementation details for the proof of concepts benchmarks cited above. In the case of block propagation (~110KB), latency or number of network hops dominate the propagation time, while in the case of large messages like blobs in full DAS, bandwidth dominates the propagation time.\nWe consider a finite field \\mathbb{F}_p𝔽𝑝 of prime characteristic. In the example above we choose the Ristretto scalar base field as implemented by the curve25519-dalek rust crate. The proposer takes a block, which is an opaque byte slice, and interprets it as a vector of elements in \\mathbb{F}_p𝔽𝑝. A typical ethereum block is about B = 110KB𝐵 =110𝐾𝐵 at the time of writing, given that each Ristretto scalar takes a little less than 32 bytes to encode, a block takes about B/32 = 3520𝐵/32 =3520 elements of \\mathbb{F}_p𝔽𝑝. Dividing into N=10 chunks, each chunk can be viewed as a vector in \\mathbb{F}_p^{M}𝔽𝑀𝑝, where M \\sim 352𝑀 ∼352. The block is thus viewed as N𝑁 vectors v_i \\in \\mathbb{F}^M_p𝑣𝑖 ∈𝔽𝑀𝑝, i=1,...,N𝑖 =1,...,𝑁. The proposer chooses a subset of D\\sim 40𝐷 ∼40 peers at random. To each such peer it will send one vector of \\mathbb{F}_p^M𝔽𝑀𝑝 together with some extra information to validate the messages and prevent DOS on the network. We explain the proposer\nThe Proposer\nWe will use Pedersen commitments to the Ristretto elliptic curve E𝐸 as implemented by the above mentioned rust crate. We assume that we have already chosen at random a trusted setup of enough elements G_j \\in E𝐺𝑗 ∈𝐸, j = 1, ..., K𝑗 =1,...,𝐾 with K \\gg M𝐾 ≫𝑀. We choose a standard basis \\{e_j\\}_{j=1}^M{𝑒𝑗}𝑀𝑗=1 for \\mathbb{F}_p^M𝔽𝑀𝑝. So each vector v_i𝑣𝑖 can be written uniquely as\nv_i = \\sum_{j=1}^M a_{ij} e_j,𝑣𝑖 =∑𝑀𝑗=1𝑎𝑖𝑗𝑒𝑗,\nfor some scalars a_{ij} \\in \\mathbb{F}_p𝑎𝑖𝑗 ∈𝔽𝑝. To each vector v_i𝑣𝑖 we have a Pedersen commitment\n C_i = \\sum_{j=1}^M a_{ij}G_j \\in E. 𝐶𝑖 =∑𝑀𝑗=1𝑎𝑖𝑗𝐺𝑗 ∈𝐸.\nFinally for each peer in the subset of size D \\sim 40𝐷 ∼40 the proposer chooses uniformly random a collection of scalars b_i𝑏𝑖, i=1, ...,N𝑖 =1,...,𝑁 and sends the following information to the peer\n\nThe vector v = \\sum_{i=1}^N b_i v_i \\in \\mathbb{F}_p^M𝑣 =∑𝑁𝑖=1𝑏𝑖𝑣𝑖 ∈𝔽𝑀𝑝. This is of size 32M32𝑀 bytes and it’s the content of the message.\nThe N𝑁 commitments C_i𝐶𝑖, i=1,...,N𝑖 =1,...,𝑁. This is 32N32𝑁 bytes.\nThe N𝑁 coefficients b_i𝑏𝑖, i=1, ...,N𝑖 =1,...,𝑁. This is 32N32𝑁 bytes.\nA BLS signature to the hash of the N𝑁 commitments C_1 || C_2 || ... || C_N𝐶1||𝐶2||...||𝐶𝑁, this is 9696 bytes.\n\nA signed message is the collection of elements 1–4 above. We see that there are 64N \\sim 64064𝑁 ∼640 extra bytes sent on each message as a sidecar.\nReceiving Peers\nWhen a peer receives a message as in the previous section, the verification goes as follows\n\nIt verifies that the signature is valid for the proposer and the hash of the receiving commitments.\nIt writes the receiving vector v = \\sum_{j=1}^M a_j e_j𝑣 =∑𝑀𝑗=1𝑎𝑗𝑒𝑗 and then computes the Pedersen commitment C = \\sum_{j=1}^M a_j G_j𝐶 =∑𝑀𝑗=1𝑎𝑗𝐺𝑗.\nThe received coefficients b_i𝑏𝑖 are a claim that v = \\sum_{i=1}^N b_i v_i𝑣 =∑𝑁𝑖=1𝑏𝑖𝑣𝑖. The peer computes C'= \\sum_{i=1}^N b_i C_i𝐶′ =∑𝑁𝑖=1𝑏𝑖𝐶𝑖, and then verifies that C = C'𝐶 =𝐶′.\n\nPeers keep track of the messages that they have received, say they are the vectors w_i𝑤𝑖, i = 1,...,L𝑖 =1,...,𝐿 for L < N𝐿 <𝑁. They generate a subspace W \\subset \\mathbb{F}_p^M𝑊 ⊂𝔽𝑀𝑝. When they receive v𝑣, they first check that if this vector is in W𝑊. If it is, then they discard it as this vector is already a linear combination of the previous ones. The key of the protocol is that this is very unlikely to happen (for the numbers above the probability of this happening is much less than 2^{-256}2−256). As a corollary of this, when the node has received N𝑁 messages, then it knows that it can recover the original v_i𝑣𝑖, and thus the block, from the messages w_i𝑤𝑖, i=1,...,N𝑖 =1,...,𝑁.\nNotice also that there is only one signature verification that is needed, all incoming messages have the same commitments C_i𝐶𝑖 and the same signature over the same set of commitments, thus the peer may cache the result of the first valid verification.\nSending Peers\nPeers can send chunks to other peers as soon as they receive one chunk. Suppose a node holds w_i𝑤𝑖, i=1,...,L𝑖 =1,...,𝐿 with L \\leq N𝐿 ≤𝑁 as in the previous section. A node also keeps track of the scalar coefficients they received, thus they know the chunks they hold satisfy\n w_i = \\sum_{j=1}^N b_{ij} v_j \\quad \\forall i,𝑤𝑖 =∑𝑁𝑗=1𝑏𝑖𝑗𝑣𝑗 ∀𝑖,\nfor some scalars b_{ij} \\in \\mathbb{F}_p𝑏𝑖𝑗 ∈𝔽𝑝 they save in their internal state. Finally, nodes also keep the full commitments C_i𝐶𝑖 and the signature from the proposer that they have validated when they validated the first chunk they received.\nThe procedure by which a node sends a message is as follows.\n\nThey choose randomly L𝐿 scalars \\alpha_i \\in \\mathbb{F}_p𝛼𝑖 ∈𝔽𝑝, i=1,...,L𝑖 =1,...,𝐿.\nThey form the chunk w = \\sum_{i=1}^L \\alpha_i w_i𝑤 =∑𝐿𝑖=1𝛼𝑖𝑤𝑖.\nThey form the N𝑁 scalars a_j𝑎𝑗, i=1,...,N𝑖 =1,...,𝑁 by\n a_j = \\sum_{i=1}^L \\alpha_i b_{ij}, \\quad \\forall j=1,...,N. 𝑎𝑗 =∑𝐿𝑖=1𝛼𝑖𝑏𝑖𝑗, ∀𝑗 =1,...,𝑁.\n\nThe message they send consists of the chunk w𝑤, the coefficients a_j𝑎𝑗 and the commitments C_i𝐶𝑖 with the signature from the proposer.\nBenchmarks\nThe protocol has some components that are in common with gossipsub, for example the proposer needs to make one BLS signature and the verifier has to check one BLS signature. We record here the benchmarks of the operations that need to be carried in addition to the usual gossipsub operations. These are the CPU overhead that the protocol has on nodes. Benchmarks have been carried on a Macbook M4 Pro laptop and on an Intel i7-8550U CPU @ 1.80GHz.\nParameters for these benchmarks were N=10𝑁 =10 for the number of chunks and the total block size was considered to be 118.75KB. All benchmarks are single threaded and all can be parallelized\nProposer\nThe proposer needs to perform N𝑁 Pedersen commitments. This was benchmarked to be\n\nTiming\nModel\n\n[25.588 ms 25.646 ms 25.715 ms]\nApple\n\n[46.7ms 47.640 ms 48.667 ms]\nIntel\n\nNodes\nA receiving node needs to compute 1 Pedersen commitment per chunk and perform a corresponding linear combination of the commitments supplied by the proposer. The timing for these were as follows\n\nTiming\nModel\n\n[2.6817 ms 2.6983 ms 2.7193 ms]\nApple\n\n[4.9479 ms 5.1023 ms 5.2832 ms]\nIntel\n\nWhen sending a new chunk, the node needs to perform a linear combination of the chunks it has available. Timing for these were as follows\n\nTiming\nModel\n\n[246.67 µs 247.85 µs 249.46 µs]\nApple\n\n[616.97 µs 627.94 µs 640.59 µs]\nIntel\n\nWhen decoding the full block after receiving N𝑁 chunks, the node needs to solve a linear system of equations. Timings were as follows\n\nTiming\nModel\n\n[2.5280 ms 2.5328 ms 2.5382 ms]\nApple\n\n[5.1208 ms 5.1421 ms 5.1705 ms]\nIntel\n\nOverall CPU overhead.\nThe overall overhead for the proposer on the Apple M4 is 26ms single threaded while for the receiving nodes it is 29.6ms single threaded. Both processes are fully parallelizable. In the case of the proposer, it can compute each commitment in parallel, and in the case of the receiving node these are naturally parallel events since the node is receiving the chunks in parallel from different peers. Running these process in parallel on the Apple M4 leads to 2.6ms in the proposer side and 2.7ms in the receiving peer. For real life applications it is reasonable to consider these overheads as zero compared to the network latencies involved.\nOptimizations\nSome premature optimizations that were not implemented consist on inverting the linear system as the chunks come, although the proof of concept cited above does keep the incoming coefficient matrix in Echelon form. Most importantly, the random coefficients for messages do not need to be in such a large field as the Ristretto field. A small prime field like \\mathbb{F}_{257}𝔽257 suffices. However, since the Pedersen commitments take place in the Ristretto curve, we are forced to perform the scalar operations in the larger field. The implementation of these benchmarks chooses small coefficients for the linear combinations, and these coefficients grow on each hop. By controlling and choosing the random coefficients correctly, we may be able to bound the coefficients of the linear system (and thus the bandwidth overhead in sending the blocks) to be encoded with say 4 bytes instead of 32.\nThe simplest way to perform such optimization would be to work over an elliptic curve defined over \\mathbb{F}_q𝔽𝑞 with q = p^r𝑞 =𝑝𝑟 for some small prime p𝑝. This way the coefficients can be chosen over the subfield \\mathbb{F}_p \\subset \\mathbb{F}_q𝔽𝑝 ⊂𝔽𝑞.\nPrivacy considerations the implementation in the PoC linked above considers that each node, including the proposer, picks small coefficients to compound its linear transformation. This allows a peer receiving a chunk with small coefficients to recognize the proposer of the block. Either the optimization above is employed to keep all coefficients small by performing an algorithm like Bareiss’ expansions or we should allow the proposer to choose random coefficients from the field \\mathbb{F}_p𝔽𝑝.\nSimulations\nWe performed simulations of block propagation under some simplifying assumptions as follows.\n\nWe choose a random network modeled as a directed graph with 10000 nodes and each node having D𝐷 peers to send messages to. D𝐷 is called the Mesh size in this note and was chosen varying on a large range from 3 to 80.\nPeers where chosen randomly and uniformly on the full node set.\nEach connection was chosen with the same bandwidth of X𝑋 MBps (this is typically assumed to be X=20𝑋 =20 in Ethereum but we can leave this number as a parameter)\nEach network hop, incurs in an extra constant latency of L𝐿 milliseconds (this is typically measured as L=70𝐿 =70 but we can leave this number as a parameter)\nThe message size is assumed to be B𝐵 KB in total size.\nFor the simulation with RLNC, we used N=10𝑁 =10 chunks to divide the block.\nEach time a node would send a message to a peer that would drop it because of being redundant (for example the peer already had the full block), we record the size of the message as wasted bandwidth.\n\nGossipsub\nWe used the number of peers to send messages D=6𝐷 =6. We obtain that the network takes 7 hops in average to propagate the full block to 99% of the network, leading to a total propagation time of\n T_{\\mathrm{gossipsub, D=6}} = 7 \\cdot (L + B/X), 𝑇gossipsub,D=6 =7 ⋅(𝐿 +𝐵/𝑋),\nin milliseconds.\ngossipsub-total-theorical1712×982 70.6 KB\nWith D=8𝐷 =8 the result is similar\nT_{\\mathrm{gossipsub, D=8}} = 6 \\cdot (L + B/X), 𝑇gossipsub,D=8 =6 ⋅(𝐿 +𝐵/𝑋),\nThe wasted bandwidth is 94,060 \\cdot B94,060 ⋅𝐵 for D=6𝐷 =6 and 100,297 \\cdot B100,297 ⋅𝐵 for D=8𝐷 =8.\nFor low values of B𝐵, like the current Ethereum blocks, latency dominates the propagation, while for larger values, for example propagating blobs after peer-DAS, bandwidth becomes the main factor.\nRLNC\nSingle chunk per peer\nWith random linear network coding we can use different strategies. We simulated a system in which each node will only send a single chunk to all of the peers in their mesh of size D𝐷, this way we guarantee that the latency incurred is the same as in gossipsub: a single latency cost of L𝐿 milliseconds per hop. This requires the mesh size to be considerably larger than N𝑁, the number of chunks. Notice that for a gossipsub mesh size of D_{gossipsub}𝐷𝑔𝑜𝑠𝑠𝑖𝑝𝑠𝑢𝑏 (for example 88 in current Ethereum), we would need to set D_{RLNC} = D_{gossipsub} \\cdot N𝐷𝑅𝐿𝑁𝐶 =𝐷𝑔𝑜𝑠𝑠𝑖𝑝𝑠𝑢𝑏 ⋅𝑁 to consume the same bandwidth per node, this would be 8080 with the current values.\nWith a much more conservative value of half this bandwidth, that is D=40𝐷 =40 we obtain\nT_{RLNC, D=40} = 4 \\cdot \\left(L + \\frac{B}{10 X} \\right), 𝑇𝑅𝐿𝑁𝐶,𝐷=40 =4 ⋅(𝐿+𝐵10𝑋),\nwith a wasted bandwidth of 29,917\\cdot B29,917 ⋅𝐵. Assuming the same bandwidth as today we obtain with D=80𝐷 =80 we get the impressive\nT_{RLNC, D=80} = 3 \\cdot \\left(L + \\frac{B}{10 X} \\right), 𝑇𝑅𝐿𝑁𝐶,𝐷=80 =3 ⋅(𝐿+𝐵10𝑋),\nwith a wasted bandwidth of 28,124\\cdot B28,124 ⋅𝐵, which is 28% of the corresponding wasted bandwidth in gossipsub.\nDifferences\nFor the same bandwidth sent per node, we see that the propagation time differs both by dividing the latency in two (there are 3 hops vs 6) and by propagating the block faster consuming a tenth of the bandwidth per unit of time. In addition the wasted bandwidth by superfluous messages gets slashed to 28% of the gossipsub wasted messages. Similar results are obtained for propagation time and wasted bandwidth but reducing the bandwidth sent per node by a half.\nIn the lower block size end, latency is dominant and the 3 hops vs 6 on gossipsub make most of the difference, in the higher block size end, bandwidth performance is dominant. For much larger blocksizes CPU overhead in RLNC gets worse, but given the order of magnitude of the transmission times, these are negligible.\nrlnc-gossipsub1712×982 87.7 KB\nMultiple chunks per peer\nIn the single chunk per peer approach in production, nodes with higher bandwidth could choose to broadcast to more peers. At the node level this can be implemented by simply broadcasting to all the current peers and node operators would simply chose the number of peers via a configuration flag. Another approach is to allow nodes to send multiple chunks to a single peer, sequentially. The results of these simulations are exactly the same as the above, but with much lower D𝐷 as expected. For example with D=6𝐷 =6, which would never broadcast a full block in the case of a single chunk sent per peer. The simulation takes 10 hops to broadcast the full block. With D=10𝐷 =10 the number of hops is reduced to 9.\nConclusions, omissions and further work\nOur results show that one expects considerable improvement in both block propagation time and bandwidth usage per node if we were to use RLNC over the current routing protocol. These benefits become more apparent the larger the block/blob size or the shorter the latency cost per hop. Implementation of this protocol requires substantial changes to the current architecture and it may entail a new pubsub mechanism altogether. In order to justify this we may want to implement the full networking stack to simulate under Shadow. An alternative would be to implement Reed-Solomon erasure coding and routing, similar to what we do with Peer-DAS. It should be simple to extend the above simulations to this situation, but op. cit already includes many such comparisons.\n\n Alternative DAS concept based on RLNC\n\n Using Rateless Coding for DAS\n\n Improving column propagation with cell-centric erasure/network coding\n\n Wen fast payload broadcast? Segment, code, push, pull, and everything in between\n\n RLNC Optimizations\n\n 20\n\n 11\n\n 5\n\n 4\n\n 2\n\n read \n\n 24\n min\n\n post by MarcoPolo on Jan 7, 2025\n\n post by potuz on Jan 7, 2025\n\n post by Nashatyrev on Jan 9, 2025\n\n post by potuz on Jan 9, 2025\n\n post by Nashatyrev on Jan 10, 2025\n\n post by potuz on Jan 10, 2025\n\n post by potuz on Jan 13, 2025\n\n post by chrmatt on Jan 16, 2025\n\n post by potuz on Jan 16, 2025\n\n post by chrmatt on Jan 16, 2025\n\n post by zincoshine on Jan 17, 2025\n\n post by potuz on Jan 17, 2025\n\n post by potuz on Jan 17, 2025\n\n post by chrmatt on Jan 17, 2025\n\n post by potuz on Jan 19, 2025\n\n post by jtremback on Jan 23, 2025\n\n post by potuz on Jan 24, 2025\n\n post by MedardDuffy on Jan 28, 2025\n\n post by MedardDuffy on Jan 28, 2025\n\n Load more posts below","tokens":4673,"squid":"ink-research","role":"Deep Scholar","at":1791263596623,"hash":"88bd13a67a10aff5416155ec65dd19c081cd520f"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/bridging/configure-token-gateway/standard","domain":"docs.arbitrum.io","title":"Configure standard gateway bridging | Arbitrum Docs","text":"✏️Request an updateThis guide explains how to configure your ERC-20 token to work with Arbitrum's standard gateway. The standard gateway is the simplest option—it automatically creates a standard ERC-20 token on the child chain with no configuration required.\nWhen to use the standard gateway​\nUse the standard gateway when:\n\nYou have a standard ERC-20 token on the parent chain\nYou don't need custom functionality on the child chain token\nYou want automatic setup with no pre-configuration\nYour token doesn't have special behaviors (rebasing, fee-on-transfer, and similar)\n\nFor custom token behavior, see:\n\nGeneric-custom gateway—for custom child chain token logic\nCustom gateway—for advanced use cases\n\nPrerequisites​\n\nA standard ERC-20 token deployed on the parent chain (or deploy one following this guide)\nFamiliarity with Arbitrum's token bridge system\nBasic understanding of smart contracts and blockchain development\n\nHow the standard gateway works​\nWhen using the standard gateway:\n\nNo pre-configuration needed: Your token is automatically bridgeable\nAutomatic child chain deployment: On the first deposit, a StandardArbERC20 contract is deployed on the child chain\nEscrow model: Parent chain tokens are escrowed in the gateway; child chain tokens are minted and burned\nRouter handles routing: The router automatically directs your token to the standard gateway\n\nFor architectural details, see Standard ERC-20 bridging.\nStep 1: Deploy your token (or use an existing one)​\nIf you already have a token on the parent chain, skip to Step 2. Otherwise, create a standard ERC-20 token:\n// SPDX-License-Identifier: MITpragma solidity ^0.8.0;import \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";contract DappToken is ERC20 { constructor(uint256 _initialSupply) ERC20(\"Dapp Token\", \"DAPP\") { _mint(msg.sender, _initialSupply * 10 ** decimals()); }}\nDeploy it to the parent chain:\nconst { ethers } = require('hardhat');const { providers, Wallet } = require('ethers');const parentProvider = new providers.JsonRpcProvider(process.env.PARENT_RPC);const wallet = new Wallet(process.env.PRIVATE_KEY, parentProvider);async function deployToken() { const TokenFactory = await ethers.getContractFactory('DappToken'); const token = await TokenFactory.connect(wallet).deploy(1000000); await token.deployed(); console.log(`Token deployed at: ${token.address}`); return token.address;}\nStep 2: Understand the bridge contracts​\nTwo contracts handle token bridging:\nRouter contracts​\n\nL1GatewayRouter: Entry point on parent chain\nL2GatewayRouter: Entry point on child chain\n\nThe router maintains a mapping of which gateway handles which token, falling back to the standard gateway for unmapped tokens.\nGateway contracts​\n\nL1ERC20Gateway: Escrows parent chain tokens\nL2ERC20Gateway: Mints/burns child chain tokens\n\nYou can find contract addresses on the contract addresses page.\nStep 3: Trigger child chain token deployment​\nThe child chain token is created automatically on the first deposit. You can trigger deployment by making a small deposit or by waiting until users make their first deposits.\nUsing the Arbitrum SDK​\nimport { getArbitrumNetwork, Erc20Bridger } from '@arbitrum/sdk';import { providers, Wallet } from 'ethers';const parentProvider = new providers.JsonRpcProvider(process.env.PARENT_RPC);const childProvider = new providers.JsonRpcProvider(process.env.CHILD_RPC);const wallet = new Wallet(process.env.PRIVATE_KEY, parentProvider);const childNetwork = await getArbitrumNetwork(childProvider);const erc20Bridge = new Erc20Bridger(childNetwork);// Approve the gatewayawait erc20Bridge.approveToken({ parentSigner: wallet, erc20ParentAddress: tokenAddress,});// Make initial deposit to trigger L2 token creationconst depositTx = await erc20Bridge.deposit({ amount: ethers.utils.parseUnits('1', 18), erc20ParentAddress: tokenAddress, parentSigner: wallet, childProvider: childProvider,});const receipt = await depositTx.wait();console.log(`Deposit complete: ${receipt.transactionHash}`);\nFor complete deposit instructions, see Deposit tokens.\nStep 4: Find your child chain token address​\nAfter the first deposit, find your token's child chain address:\nUsing the SDK​\nconst childTokenAddress = await erc20Bridge.getChildErc20Address(parentTokenAddress, parentProvider);console.log(`L2 token address: ${childTokenAddress}`);\nManually​\nCall calculateL2TokenAddress on the L1GatewayRouter contract:\naddress l2TokenAddress = l1GatewayRouter.calculateL2TokenAddress(l1TokenAddress);\nOr look up the token on Arbiscan by searching for the deployment transaction.\nStep 5: Verify the child chain token​\nThe automatically deployed token is an instance of StandardArbERC20 with:\n\nSame name and symbol as parent chain token\nSame decimals as parent chain token\nl1Address() function returns the parent chain token address\nMinting/burning controlled by the L2ERC20Gateway\n\nYou can verify this on Arbiscan by viewing the token contract.\nConfiguration complete​\nYour token is now bridgeable! Users can:\n\nDeposit tokens to the child chain\nWithdraw tokens back to the parent chain\n\nImportant considerations​\nToken compatibility​\nThe standard gateway works for most ERC-20 tokens, but not for:\n\nRebasing tokens (supply changes)\nFee-on-transfer tokens\nTokens with transfer hooks\nTokens with unique minting and burning logic\n\nFor these cases, use a generic-custom gateway or a custom gateway.\nGateway assignment​\nOnce the first deposit occurs, the token is permanently assigned to the standard gateway. You can't change gateway types after this point.\nChild chain token ownership​\nThe gateway controls the automatically deployed child chain token—you can't modify or upgrade it. For control over the child chain token, use the generic-custom gateway.\nNext steps​\n\nDeposit tokens\nWithdraw tokens\nUnderstand token bridge architecture\nView example code\n\nResources​\n\nToken bridge conceptual overview\nStandard ERC-20 bridging details\nArbitrum SDK\nContract addresses\nWhen to use the standard gatewayPrerequisitesHow the standard gateway worksStep 1: Deploy your token (or use an existing one)Step 2: Understand the bridge contractsRouter contractsGateway contractsStep 3: Trigger child chain token deploymentUsing the Arbitrum SDKStep 4: Find your child chain token addressUsing the SDKManuallyStep 5: Verify the child chain tokenConfiguration completeImportant considerationsToken compatibilityGateway assignmentChild chain token ownershipNext stepsResources","tokens":1608,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263600246,"hash":"452a4da25f32bc7e5887d89c3a17b8fe76a355cd"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/how-to-get-l2block-on-l1","domain":"docs.arbitrum.io","title":"How to verify child chain state on the parent chain | Arbitrum Docs","text":"✏️Request an updateArbitrum implements a fraud proof system that ensures that the state of any given child chain is safely maintained by its parent chain. In this system, a validator is responsible for periodically posting assertions about the child chain's state to its parent chain. See Inside Arbitrum Nitro to learn more about the Rollup protocol.\nEach assertion is a claim about the impact that a series of child chain blocks (containing transactions) ought to have on the chain's state. When posted to the parent chain, assertions are recorded by the Rollup contract; once confirmed, the resulting state commitment (block hash + send root) is relayed to the Outbox contract. The primary purpose of this commitment is to secure withdrawals: it provides the trusted state against which child chain -> parent chain messages (such as withdrawals) are proven before they can be executed on the parent chain. The same committed state can also be reused by off-chain tools — for example, the off-chain state verification described in this guide.\nBefore we begin, we will introduce the key components: the assertion, its global state, and send roots.\nAssertions​\nThe Rollup contract stores a chain of assertions. Each stored assertion is represented by an AssertionNode struct:\nstruct AssertionNode { // Block when the first child of this assertion was created uint64 firstChildBlock; // Block when the second child was created (non-zero => assertion was challenged) uint64 secondChildBlock; // The block number when this assertion was created uint64 createdAtBlock; // True if this assertion is the first child of its prev bool isFirstChild; // Status of the assertion: NoAssertion / Pending / Confirmed AssertionStatus status; // Hash of the environment config at creation time (e.g. wasmModuleRoot) bytes32 configHash;}\nAn assertion's validity is bound to its assertion hash; the struct above does not store the claimed state directly.\nAn assertion is created together with its before and after execution states, packaged as AssertionInputs:\nstruct AssertionInputs { BeforeStateData beforeStateData; AssertionState beforeState; AssertionState afterState;}struct AssertionState { GlobalState globalState; MachineStatus machineStatus; bytes32 endHistoryRoot;}\nThe key field is afterState.globalState: it contains the child chain block hash and send root that this assertion claims. We can extract them with the GlobalStateLib helpers getBlockHash() and getSendRoot().\nThe assertion hash itself authenticates these values — it is computed as:\nassertionHash = keccak256(abi.encodePacked( parentAssertionHash, afterState.hash(), // keccak256(abi.encode(afterState)) inboxAcc))\nSend roots​\nThe send root mapping is stored in the Outbox contract. It maps the Merkle root of each batch of child chain -> parent chain messages (the send root) to its corresponding child chain block hash.\nWhen an assertion is confirmed, the Rollup contract records the send root to the outbox so that, when a user later triggers a child chain -> parent chain message on the parent chain, the request can be verified.\nmapping(bytes32 => bytes32) public roots; // maps root hashes => child chain block hash\nBecause this mapping stores the block hash, you can also recover the child chain block hash directly from the outbox.\nVerify child chain state on parent chain​\nAssume there is a contract called foo on the child chain at address fooAddress, and we want to prove its storage value at slot.\nTo verify the state, we need a Merkle Trie verifier contract — for example, a Lib_MerkleTrie-style library that exposes a get(key, proof, root) function.\nWhy we can trust an untrusted child chain RPCThe steps below query a child chain RPC several times (eth_getBlockByHash, eth_getProof). You do not have to trust that RPC. Every value it returns is checked against the trust anchor established in step 1 — the block hash and send root taken from the assertion confirmed on the parent chain:\nThe block header is only accepted if its RLP hash reproduces the confirmed block hash.\nThe account and storage values are only accepted if their Merkle proofs verify against the state root inside that header.\nBecause each link is bound to the confirmed parent chain commitment by a cryptographic hash, a malicious or buggy RPC cannot forge data that passes verification. The worst it can do is return wrong or missing data, which makes verification fail (a denial of service) — it can never produce a false positive. This one-way guarantee is what makes the whole procedure sound.\n1. Get a confirmed child chain block hash​\nFor security, we use the latest confirmed assertion rather than the latest proposed one. The AssertionConfirmed event emits the block hash and send root directly:\n\nGet the latest confirmed assertion hash: assertionHash = rollup.latestConfirmed(), which returns a bytes32 assertion hash.\nQuery the confirmation event for that hash: AssertionConfirmed(bytes32 indexed assertionHash, bytes32 blockHash, bytes32 sendRoot). The event gives you blockHash and sendRoot directly.\n(Optional) You can cross-check by reading the global state from the AssertionCreated event for the same hash and extracting blockHash = GlobalStateLib.getBlockHash(assertion.afterState.globalState) and sendRoot = GlobalStateLib.getSendRoot(assertion.afterState.globalState).\n(Optional) You can also look the block hash up in the outbox: roots[sendRoot].\n\n2. Prove the state root belongs to the block hash, using the block header​\nWith the block hash, fetch the corresponding block from the child chain provider: l2blockRaw = eth_getBlockByHash(blockHash).\nThen re-derive the block hash by RLP-encoding and hashing the header fields:\nblockarray = [ l2blockRaw.parentHash, l2blockRaw.sha3Uncles, l2blockRaw.miner, l2blockRaw.stateRoot, l2blockRaw.transactionsRoot, l2blockRaw.receiptsRoot, l2blockRaw.logsBloom, BigNumber.from(l2blockRaw.difficulty).toHexString(), BigNumber.from(l2blockRaw.number).toHexString(), BigNumber.from(l2blockRaw.gasLimit).toHexString(), BigNumber.from(l2blockRaw.gasUsed).toHexString(), BigNumber.from(l2blockRaw.timestamp).toHexString(), l2blockRaw.extraData, l2blockRaw.mixHash, l2blockRaw.nonce, BigNumber.from(l2blockRaw.baseFeePerGas).toHexString(),];\n\nCompute calculated_blockhash = keccak256(RLP.encode(blockarray)).\nCheck that it matches the value from step 1: calculated_blockhash === blockHash.\n\nIf they match, the header — and in particular the stateRoot — is proven correct.\nWatch the header field set and zero-value encodingThe exact list of header fields (and their ordering) must match the block header schema of the chain you are proving against. The 16 fields above match current Arbitrum Nitro headers, but a chain running a different configuration may include additional fields. Additionally, RLP requires minimal integer encoding: a numeric field whose value is 0 must encode to an empty byte string, not 0x00. Confirm your encoding reproduces the expected hash before relying on it.\n3. Prove the account in the state root​\nWith a trusted state root, verify the account:\nproof = l2provider.send('eth_getProof', [fooAddress, [slot], { blockHash }]);\n\nGet account proof: accountProof = RLP.encode(proof.accountProof)\nGet proofKey: proofKey = ethers.utils.keccak256(fooAddress)\nCall the verifier contract to verify:\n\n[acctExists, acctEncoded] = verifier.get(proofKey, accountProof, stateRoot);\n\nCheck for equality: acctExists == true\n\n4. Prove the storage slot is in the account root​\n\nGet storage root: storageRoot = RLP.decode(acctEncoded)[2]\nGet storage slot key: slotKey = ethers.utils.keccak256(slot)\nGet storageProof: storageProof = ethers.utils.RLP.encode(proof.storageProof.filter((x) => x.key === slot)[0].proof)\nCall the Merkle verifier contract to verify:\n\nconst [storageExists, storageEncoded] = await verifier.get(slotKey, storageProof, storageRoot);\n\nCheck for equality: storageExists == true\nObtain the value of the storage at slot: storageValue = ethers.utils.RLP.decode(storageEncoded)\n\nYou have now proven a specific storage value at a specific block height on the child chain, entirely through the parent chain.\nCross-check the value directly on the child chain​\n\nCall the child chain RPC provider to get the value at the corresponding block number: actualValue = l2provider.getStorageAt(fooAddress, slot, l2blockRaw.number)\nCheck for equality: storageValue === BigNumber.from(actualValue).toHexString()\n\nSecurity considerations and limitations​\nThe procedure above is cryptographically sound — its trust is anchored in an assertion confirmed on the parent chain, and every value fetched from a child chain RPC is verified against that anchor. Keep the following caveats in mind:\n\nYou can only prove state at a confirmed block. The block hash in an assertion's global state is for one specific block (the end of the assertion). To prove state at an arbitrary or more recent block, you must additionally link that block back to a confirmed block through the parentHash chain.\nConfirmation depends on the parent chain's finality. latestConfirmed() can change if the parent chain reorganizes. For maximum safety, read it at a finalized parent chain block.\n\"Confirmed\" reflects the Rollup's trust model. A confirmed assertion is one that survived its challenge period; its correctness rests on the Rollup's fraud-proof / BoLD security assumptions (at least one honest validator).\nZero / non-existent values need explicit handling. The steps above check acctExists == true and storageExists == true. Proving that a slot's value is zero requires handling the corresponding exclusion proof.\nThe Merkle Trie verifier must be correct. The overall guarantee depends on the correctness of the verifier library you use; review and test it before relying on it in production.\nAssertionsSend rootsVerify child chain state on parent chain1. Get a confirmed child chain block hash2. Prove the state root belongs to the block hash, using the block header3. Prove the account in the state root4. Prove the storage slot is in the account rootCross-check the value directly on the child chainSecurity considerations and limitations","tokens":2532,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263612544,"hash":"5f4a9cdc2e33c5f3136aa50492a304d6601f4830"}
{"url":"https://governance.aave.com/t/aci-is-leaving-aave/24205/33","domain":"governance.aave.com","title":"ACI is leaving Aave - Governance / General - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 6\n min\n\n Mar 3\n\n 33 / 33\n\n Jul 1\n\n Jul 1\n\n Load more posts above\n\n post by JosepBove on Mar 3\n\n post by stani on Mar 3\n\n post by 0xmonk on Mar 3\n\n post by notrustverify.ch on Mar 3\n\n post by x2daniel on Mar 3\n\n post by anon40760803 on Mar 3\n\n post by lahes2ga on Mar 3\n\n post by jeffprod on Mar 3\n\n post by okinawajoe on Mar 3\n\n post by Frida on Mar 3\n\n post by Quentino on Mar 3\n\n post by joed on Mar 3\n\n post by 0xlide on Mar 3\n\n post by BCV on Mar 4\n\n post by sid_areta on Mar 4\n\n post by A_J on Mar 4\n\n post by _LP17 on Mar 4\n\n _LP17\n\n Thanks a lot. AAVE would not have been AAVE today\n\n post by TokenLogic on Mar 4\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n On behalf of the TokenLogic team, we sincerely thank the Aave Chan Initiative for its three remarkable years of service to the Aave DAO. The numbers speak for themselves, but what stands out most is the sheer energy and conviction ACI brought to every initiative. From building governance tooling and coordination systems to managing incentive programs, being a growth engine on the protocol, serving on the Aave Liquidity Committee, and pushing for transparency at every turn, ACI helped shape the culture and operational backbone of Aave governance. We have learned a great deal working alongside Marc and the team. Their impact on the protocol will be felt long after this chapter closes. With Love, we wish the entire ACI team all the best in their next endeavour.\n\n post by ST0X on Mar 4\n\n ST0X\n\n BCV\n\n Exactly. In general, Defi protocol governance is subpar when comparing the amount of money involved. A lot of insider/SP/delegates are making money off a profitable protocol in different ways. Hope when the dust settled, AAVE can move to the right direction and set an example to other protocols.\nACI has made some contributions in terms of protocol growth. Although no big incidents in AAVE happened during the last few years, a risk reward adjusted approached is needed to let the protocol have a sustainable growth path. That’s the only way to build a protocol for long term.\n\n 4 months later\n\n post by MarcZeller on Jul 1\n\n MarcZeller\n\n Today was our last day working for the Aave ecosystem.\nWe are grateful for everyone that supported us and wish everyone the best.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n ACI: Full Transparency Report\n\n General\n\n 10\n\n 2.4k\n\n Feb 18\n\n Aave Labs: $86 Million, 23% of the Token Supply, and this is their Track Record\n\n General\n\n 19\n\n 11.6k\n\n Feb 28\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9","tokens":701,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263612669,"hash":"8163c9ab544e7046fb604e4c8bb39bf1dc72d820"}
{"url":"https://ethresear.ch/t/faster-block-blob-propagation-in-ethereum/21370/58","domain":"ethresear.ch","title":"Faster block/blob propagation in Ethereum - Networking - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 20\n\n 11\n\n 5\n\n 4\n\n 2\n\n read \n\n 24\n min\n\n Jan 2025\n\n 55 / 55\n\n Feb 6\n\n Feb 6\n\n Load more posts above\n\n post by potuz on May 16, 2025\n\n potuz\n\n Here is an update on the testing status of this project. First and foremost, I can’t stress enough the amount of time, energy and even money that was put forth by the @EthPandaOps team. They dedicated over a week of several back and forth to set up a devnet to measure this.\nHere’s a short summary of the results.\n\nWe tested with very large block sizes, up to 6MB blocks (created with spamoor).\nThere were 1000 nodes each carrying 1000 validator keys, distributed geographically.\nBlock broadcast was delayed 2 seconds to set a common baseline for broadcasting.\nBlock arrival was measured at 145 sentry nodes.\nNo blobs were sent during the experiment (Prysm’s implementation does not support them)\n\nThe RLNC implementation had the following parameters:\n\nBlocks were divided in 10 chunks.\nEach node submitted 40 chunks to their peers.\n\nComputational overhead\nResults were not as expected at first, but the RLNC implementation on Prysm was a proof of concept that was not optimized. We had not accounted for the fact that the computational overhead of creating the commitments becomes dominant in these large block ranges. Without parallelization benchmarks of producing blocks of 6MB, 2MB and 200KB on a Ryzen 3600 are:\ngoos: linux\ngoarch: amd64\ncpu: AMD Ryzen 5 3600 6-Core Processor\nBenchmarkChunkMSM_6MB-12 1 2692349646 ns/op\nBenchmarkChunkMSM_2MB-12 2 727631407 ns/op\nBenchmarkChunkMSM_200KB-12 14 72044668 ns/op\n\nThus, in the large block scenario, the RLNC branch was broadcasting blocks no earlier than almost 3 seconds into the slot, which gives almost an entire second difference with the gossipsub blocks of the baseline.\nDifferent mesh size\nBesides the computational overhead that was not parallelized, the other issue is that the RLNC devnet had an effective mesh size of half the gossipsub devnet, as nodes broadcasted 40 chunks, totaling 4 blocks, instead of the 8 chunks broadcast by the gossipsub devnet. This effectively shows that the RLNC devnet was using much less of the available bandwidth.\nResults\nIn the regime of up to 2MB the results are shown in the following graph:\n2mb1431×1054 117 KB\nWhich shows that RLNC without any optimizations and broadcasting half of the data, results in a big improvement, given that gossipsub takes 46% more time to broadcast the blocks in the limit.\nIn the regime of very large blocks the results are shown in the following graph:\n6mb1257×997 102 KB\nWhich shows that the constant computational overhead is dominant. The RLNC devnet showed also instability in this range since blocks were being broadcat close to the attestation deadline.\nWhat we learned\nThe results show a strong improvement in the block size range of up to 2MB (ten times the current average) but the data is not really compatible with real life applications. Since we produced this data the following improvement have been made to the Prysm implementation\n\nWe parallelized the commitment computation, reducing it to less than 300ms in the 6MB block range and less than 10ms in the 200KB range.\nWe made the number of chunks and the mesh-size user-configurable so that these tests can be repeated without recompilation of the client and with just a configuration change in the validators.\nWe should gather data also in the 100KB–200KB block size range, since these are the sizes that are more common in Ethereum mainnet. The very large block range would give some insight into blob propagation, where the cryptographic CPU overhead of RLNC would be compared against KZG or RS computations that are absent in block propagation.\n\n post by benaadams on May 18, 2025\n\n benaadams\n\n Does the analysis tangentially give any additional insight into what the max blocksize (bytes) should be under the current implementation, given recommended bandwidth?\nOther than the 10MB it is set in EIP-7934 EIP-7934: RLP Execution Block Size Limit\n\n post by fradamt on May 19, 2025\n\n fradamt\n\n potuz\n\n It would also be interesting to compare with RS without any heavy cryptography, e.g. the proposer just commits to chunks by their hash/root\n\n post by potuz on May 19, 2025\n\n potuz\n\n Yeah will eventually work on it in the design I mentioned above but it’s still an invasive change as it changes the signature scheme on the block. I would prefer to make the measurements on RLNC more accurate first though. To get the right mesh parameters. I sincerely doubt RS comes close: the crypto part of RLNC can be heavily parallelized and also made cheap using simpler fields. RS will still need the polynomial interpolation. The benefits on broadcasting should easily offset the benefits of the cheaper crypto. In this experiment at the higher limit blocks were leaving 1 second later! And for current block sizes the crypto part im dryer m doesn’t even appear in the flame\n\n post by chrmatt on May 19, 2025\n\n chrmatt\n\n Why would the RS approach require changing the block signature scheme? Can’t we just sign the block as currently, RS encode the full block, and use some commitment/hash of the individual chunks to tie them together? The block signature can then be verified after reconstructing the block.\n\n post by potuz on May 19, 2025\n\n potuz\n\n Because each individual chunk needs to come signed to not dos nodes. As I noted above there’s only one signature that is needed (to the commitment of all of them) but this signature needs to come in chunks, therefore you change the current signature scheme, which is what makes deep CL changes.\n\n post by MarcoPolo on May 19, 2025\n\n MarcoPolo\n\n Exciting work! Thanks for testing this \nA couple of questions:\n\nWhat are the network specs of the machines?\nCould you link the code that distributes the RLNC chunks to the mesh?\nHow does parallelization speed up the commitment computation?\n\n post by potuz on May 19, 2025\n\n potuz\n\n I’ll defer the first question to @parithosh, all I remember from them is s-8vcpu-16gb-amd for spec. The branch that was tested is [DO NOT MERGE] Use RLNC for block propagation by potuz · Pull Request #14813 · OffchainLabs/prysm · GitHub without the last commits for parallelization. The call to distribute the chunks starts in this line.\nThe last bench I can find parallelized is\ncpu: Intel(R) Core(TM) i9-14900\nBenchmarkChunkMSM_6MB-32 1 1383648871 ns/op 317930016 B/op 197009 allocs/op\nBenchmarkChunkMSM_2MB-32 3 355434164 ns/op 106150704 B/op 65944 allocs/op\nBenchmarkChunkMSM_200KB-32 33 34271750 ns/op 10362574 B/op 6798 allocs/op\n\nParalellized:\nBenchmarkChunkMSM_6MB-32 4 267416300 ns/op 317934364 B/op 197033 allocs/op\nBenchmarkChunkMSM_2MB-32 14 82303238 ns/op 106154188 B/op 65969 allocs/op\nBenchmarkChunkMSM_200KB-32 139 8521646 ns/op 10363791 B/op 6823 allocs/op\n\nBut this is a fast machine.\nEDIT: I want to stress that anyway if this goes into production, we most probably want to use a curve defined over F_2 instead of Ristretto.\n\n 1 month later\n\n post by arajasek on Jun 19, 2025\n\n arajasek\n\n Hey, this is great to see! I work with a team called Optimum , we’re building RLNC-based technology for Web3 – our first product is a general-purpose gossip library built on Gossipsub.\nWe integrated our library with Shadow, and ran the same Ethereum mainnet-like experiments as @ppopth did in the “Doubling the blob count” experiments (thank you for the great work there, was very easy to build on). We’ve seen similarly positive results – the time for 99% of nodes to receive a message is generally about twice as fast. Note that this is without tuning parameters, I suspect we can get significantly better results by playing around with various numbers.\nWe also ran this on some real-world infra, and got similar results. It seems to scale with larger messages really well, we haven’t found its breaking point yet because my desktop runs out of memory before that .\nA few points of difference to note:\n\nWe’re using \\mathbb{F}_{256}𝔽256 to represent both coefficients and elements\nWe aren’t yet handling the possibility of bad chunks (assuming honest behaviour of all nodes). We have a few ideas of how we can do this, the Pedersen commitment idea is really neat!\nUnlike the approach here, we modified the Gossipsub protocol itself to work with chunks. I think this is important, because that way you have full control over how chunks are propagated. I’m not sure how the approach in this thread works:\n\nDoes a node always forward a chunk it receives to its mesh peers (in addition to potentially creating a new chunk at the application level that is published separately?)\nIs gossip (IHAVE/IWANT/IDONTWANT) emitted for each chunk?\n\nModifying Gossipsub to be aware of chunks also allows you to do some nice optimizations. As an example, when sending IWANT control messages, nodes can specify how many more chunks they need (which the receiving node may or may not respect).\n\nI was wondering what (if anything) we could do that would be useful for your efforts. I’m happy to run more simulations on Shadow if there’s any other numbers you’d like to see captured (currently limited by my 256 GiB RAM desktop, but we’re looking into a bigger machine). Also happy to talk through any open questions, or write any code that would be useful. Very excited to see RLNC being experimented with!\n\n 11 days later\n\n post by cskiraly on Jul 1, 2025\n\n cskiraly\n\n Hi @arajasek, nice to see you join the discussion here!\n\nNote that Shadow does not account for CPU time. Depending on how you have integrated your code, this can be quite a difference compared to runs on testbeds. We are investigating how to get around this (it was part of Shadow to some extent, but removed to favor reproducibility).\n\nUnlike the approach here, we modified the Gossipsub protocol itself to work with chunks. I think this is important, because that way you have full control over how chunks are propagated. I’m not sure how the approach in this thread works …\n\nThere have been various studies on doing large message propagation over GossipSub with chunking. In the FullDAS work (where the simulation part also uses nim-libp2p + Shadow), I’ve used a naive approach in the implementation, simply using small messages and handling anything related to the large message context at a higher level in the stack. But the linked post also contains proposals for structured message IDs, bitmap based IHAVE/IWANT, etc.\nIt would be really interesting to see what modifications you did in your version.\n\n post by potuz on Jul 4, 2025\n\n potuz\n\nBut this is the whole point of the problem! we can’t use these small fields like F_{256} because we can’t have commitments that are compatible. We can’t assume that all nodes are honest. Notice that a single malicious node can inject arbitrarily high number of bad chunks that will propagate on the chain poisoning every single message that their peers send.\nWe haven’t figured out yet a good way of using a small field for scalars while at the same time have a good homomorphic signature or hashing that makes this viable for something like blobs.\nFor blocks and payloads, Ristretto is good enough anyway.\n\n post by jonasbostoen on Jul 8, 2025\n\n jonasbostoen\n\n After some experimentation with different fields & crates, I was able to get significant speedups using BLS12-381 scalars with the blstrs crate, on everything but committing to small blocks.\nOpened a draft showcase PR here with the results: show: use bls12-381 with blstrs by mempirate · Pull Request #1 · potuz/rlnc_poc · GitHub\n\n 20 days later\n\n post by MedardDuffy on Jul 29, 2025\n\n MedardDuffy\n\n potuz\n\n We have a way to deal with bad blocks currently. I mentioned earlier the references on dealing with Byzantine nodes that introduce bad blocks (see my post from Feb 3). I would recommend NOT using Pedersen commitments because of modularity, as neat as I find it from a pure technical perspective. What you are doing is tying together the representation with the validation, which is fine, but it closes doors. For example, you start with a binary extension field, then you decide to do homomorphic and need to go to a large prime… Not impossible, but not super happy, either. The approach we use does not tie the two together.\n\n post by MedardDuffy on Jul 29, 2025\n\n MedardDuffy\n\n arajasek\n\n We are now managing the possibilities of bad chunks at Optimum\n\n post by potuz on Jul 29, 2025\n\n potuz\n\n MedardDuffy\n\n Well, we haven’t figured out a better way yet than the Pedersen commitments. And yes, we need to go to a large prime, a binary field does not work and we do not know how to make it work with smaller fields. The literature we’ve seen on the topic (including the ones in your message in Feb 3) do not seem to work for our application on Ethereum L1. The only one that would perhaps work is to have homomorphic signatures, but that is impracticable on the running chain.\n\n post by chrmatt on Jul 31, 2025\n\n chrmatt\n\n MedardDuffy\n\n If you know a better way to deal with malicious nodes, it would be useful to point out a specific method that you think works in this setting. We can then discuss it.\nTo be concrete, I briefly looked at the paper “Resilient Network Coding in the Presence of Byzantine Adversaries”. The paper shows among other results that if an adversary can inject z𝑧 packages per time and the network capacity is C𝐶, then the code achieves a rate of C - 2z𝐶 −2𝑧. This means it is assumed that a receiver obtains more honest packages than malicious ones. This does not seem applicable in the blockchain setting, where honest nodes try to minimize their network traffic (instead of exhausting the network capacity) and adversaries can spam the network. Note that the Pedersen commitment approach does not suffer from this (but instead assumes a computationally bounded adversary).\n\n post by raulk on Aug 6, 2025\n\n raulk\n\n In general, any mechanism we settle on to propagate blocks faster should aim to: (a) saturate all mesh paths in parallel, (b) utilize all available bandwidth, (c) maximize efficiency by transmitting unique information, (d) ensure we only handle authenticated chunks.\nAt a network level, we should favour packets sized below path MTU to prevent IP fragmentation. Because we now deal with smaller propagation units and built-in data erasure coding redundancy, we can use QUIC (unreliable) datagrams with larger fanouts experimenting with various routing strategies (e.g. chaotic/random, latency-centric, etc.) to enable burstier parallel transmission (up to the bandwidth limits in EIP-7870). We can also leverage QUIC session resumption to “warm up” connections with a large set of peers ahead of time, to later dispatch packets rapidly with 0-RTT under a reestablished secure channel.\nUnfortunately, using large fields with RLNC to enable commitments narrows down the parameter space significantly, to the extent that none of the above is possible due to coefficient overhead.\nThere are other directions in the design space I’m keen to explore. Here are a few that seem conceptually promising and worthwhile.\n\nRateless/fountain codes like RaptorQ (RFC6330) with source-authenticated packets carrying signatures over the index + packet. The key problem is knowing when producers should stop seeding packets. We have a built-in feedback loop: attestation arrival. Valid attestations indicate peers successfully reconstructed the original payload, and can assist others in converging. We could set dynamic % thresholds over the expected attestations on subscribed subnets. Though CL clients attest at different times, efforts exist to normalize this to “as soon as a valid block is seen”.\n\nTraditional/systematic Reed-Solomon with source-authenticated packets, opportunistically piggybacking availability bitmaps for pair-wise set reconciliation. This prevents duplicate transfers at the cost of bitmap overhead (reducible with RLE/Roaring compression). The main challenge is parameter optimization, concretely balancing RS redundancy, bitmap overhead, peer parallelism, and set reconciliation behavior.\n\nRateless IBLTs for mempool-aware block propagation. This reconciles incoming blocks against local mempool contents, transmitting only missing transactions. Given ~60% public transactions in blocks, this method could achieve 1.35x communication overhead relative to private/missing transactions (40%), potentially reducing block propagation bandwidth considerably. A peer could likely reuse the local symbol set across all its peers, though we need extra research on parallelization across peers. That said, there is a privacy consideration. While devp2p announces txs that may be dropped later, this algorithm could reveal current mempool state, which adversaries could theoretically exploit. However, the bandwidth and latency improvements may justify this tradeoff.\n\nWe’re working on prototyping (1) and (2) in the p2p networking team at the EF – we’ll have more to share in the coming weeks!\n\n post by MedardDuffy on Aug 10, 2025\n\n MedardDuffy\n\n chrmatt\n\n Indeed, end-to-end error correction is wasteful and should only be undertaken in the special case where only the sink nodes are capable of decoding.\nAs a side note, the fact that errors should be decoded locally to achieve capacity is at the core of network equivalence:\nR. Koetter, M. Effros and M. Médard, “A Theory of Network Equivalence— Part I: Point-to-Point Channels,” in IEEE Transactions on Information Theory, vol. 57, no. 2, pp. 972-995, Feb. 2011\nThis is yet another example of why errors and erasures are so altogether different - propagating erasures is not wasteful.\nReturning to the matter at hand, that of managing Byzantine errors in Gossip, as I mentioned before it is generally judicious to maintain modularity - tying the protocol to a specific representation of the data is not necessary and can hinder future upgrades, like deciding to go for larger prime fields rather than remaining in binary extension fields.\nWhat we propose to do leverages the power of a code to be a hash, to verify correctness, but is agnostic as to the method for doing so. It immediately detects, flags and manages an error. We have internally nicknamed this algorithm the Rugby Protocol. For my fellow past or present ruggers reading this, it will be very natural.\nThe idea is the following. Rugby is played by two teams, each of which must stay on their side. The side is defined by the line of scrimmage, which is defined by the player who has the ball (or the position of the player who kicked the ball). In regular rugby, if you are offside, then you need to raise your hand and get onside, so behind the line of scrimmage for the ball. During that time, you take yourself out the game, cannot play and cannot interfere. Failure to do so opens you up to getting beat up by the opposing team, on whose side you have trespassed.\nLet us now play a game called Byzantine Rugby. In Byzantine Rugby, you might have gone offside because somebody put in an extra ball in the game, so you were offside by no fault of your own. You still need to get onside, but to be allowed back onside, you need to explain who had the ball that you took to be the new line of scrimmage. It is that person who misled you and you need to prove that you were indeed misled, you cannot simply accuse. You therefore need to point to the source of the confusion. That person might also have misled, so will in turn need to explain the confusion.\nThat is detailed in Section V of the following paper detailing the Byzantine fault tolerance of the OptimumP2P approach:\nhttps://arxiv.org/pdf/2508.04833.\n\n post by MedardDuffy on Aug 10, 2025\n\n MedardDuffy\n\n raulk\n\n 1/ The coefficient overhead when implemented correctly for RLNC is only a few percent. There are multiple references to this effect:\nJ. K. Sundararajan, D. Shah, M. Médard, S. Jakubczak, M. Mitzenmacher and J. Barros, “Network Coding Meets TCP: Theory and Implementation,” in Proceedings of the IEEE, vol. 99, no. 3, pp. 490-512, March 2011\nJ. Heide, M. V. Pedersen, F. H. P. Fitzek and M. Medard, “On Code Parameters and Coding Vector Representation for Practical RLNC,” 2011 IEEE International Conference on Communications (ICC), Kyoto, Japan, 2011\nJ. Krigslund, J. Hansen, D. E. Lucani, F. H. P. Fitzek and M. Medard, “Network Coded Software Defined Networking: Design and Implementation,” Proceedings of European Wireless 2015; 21th European Wireless Conference, Budapest, Hungary, 2015\n2/ Regarding using RS or Raptor, those do not scale. The throughput will go to 0 exponentially with the depth of the network. With RLNC it remains constant with the depth.\nThis is the topic of Myth #6 in\nM. Medard, F. H. P. Fitzek, M. -J. Montpetit and C. Rosenberg, “Network coding mythbusting: why it is not about butterflies anymore,” in IEEE Communications Magazine, vol. 52, no. 7, pp. 177-183, July 2014\nBasically, RS or Raptor with have throughput that goes to 0 with the size of the network, while RLNC will maintain a constant throughput.\nSection 1.5 of our book Network Coding for Engineers gives a high level understanding, with more nuanced exposition in Chapter 5 of that book.\n\n 6 months later\n\n post by arantxazapico on Feb 6\n\n arantxazapico\n\n We have just published a blog-post explaining how to use the linearly-homomorphic signature scheme of BFKW to overcame the commitments propagation issue.\n\n Powered by Discourse","tokens":5356,"squid":"ink-research","role":"Deep Scholar","at":1791263618769,"hash":"6a60fad83b106953cee393471ad6f80ce66e8793"}
{"url":"https://governance.aave.com/t/aave-chan-initiative-delegate-platform/10877/1","domain":"governance.aave.com","title":"Aave Chan Initiative Delegate platform - Delegate Platforms - Aave","text":"Aave Chan Initiative Delegate platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 44\n\n Nov 2022\n\n 4d ago\n\n post by MarcZeller on Nov 30, 2022\n\n MarcZeller\n\n Aave Chan Initiative Delegate platform\nKey Info\n\nDelegate Address: ACI.eth\nTelegram: @Lemiscate\nDiscord: Marczeller | Aave#3432\nTwitter: https://twitter.com/lemiscate (founder) https://twitter.com/AaveChan (ACI)\nVoting record: Boardroom\n\nIntroduction\nThe Aave-Chan Initiative (ACI) is a delegate platform founded by Marc Zeller, an independent blockchain consultant working with the Aave Companies since 2019. The ACI aims to participate in governance discussions on Aave and create snapshot votes & AIPs to be submitted to community vote for the benefit of the Aave protocol.\nDelegate Statement (why you should delegate to us)\nThe Aave-Chan Initiative, while being a new structure, already has a long track record in the Aave governance (Co-author of AIP-1) and forum discussions.\nAs the Aave ecosystem is getting more mature, the protocol benefits from more delegation diversity with their independent visions and value propositions for the Aave protocol.\nAs delegates, we commit to dedicating our time and resources to support Aave’s development and growth.\nWhat voters can expect from Aave-Chan Initiative:\n\nActive: we have a strong track record of governance participation and will be involved in governance at each step of AIPs process from ARCs to onchain AIPs votes\nVision: The ACI main goal and focus is the Aave protocol success, ACI is dedicated to DeFi ethos and long-term games.\nFocus: ACI has no plan to expand into other protocols governance actively and will remain laser-focused on Aave.\n\nOur main focus points at launch are:\n\nTreasury efficiency:\n\nEvery $ in the Ecosystem Reserve, in the Aave DAO treasury, should be cherished as the property of every AAVE token holder, and each spending should be done with the full intent to provide the maximum benefit for the Aave protocol ecosystem and not just be considered as a “buffet” to drain easy money by overcharging services. the ACI is fully dedicated to playing “Scrooge McDuck” in Aave and will have a slightly softer spot toward spending in Dev & risk mitigation over other aspects.\nBy providing a defacto alternative to current existing services, the ACI will provide both cooperation and competition to existing services with the full intent to contribute to the efficiency of these services.\n\nTreasury Efficiency (II):\n\nThe Aave DAO treasury is currently only gaining yield from depositing into Aave. Both for increased yield and for strategic & synergies reasons the ACI is supportive and wants to participate in less passive management of the DAO treasury, such as examples from llama by doing risk-averse investments that will increase yield:\n\nconvert part of WETH into LSDs to gain staking yield\n\nDeposit part of stablecoins into stableswaps\n\nstake veTokens and vote for Aave related pools\n\nregularly convert part of long tail assets into wETH or stablecoins\n\nTreasury diversity:\n\nThe ACI is supportive of Protocol Owned Liquidity (POL) and bonding. While most, if not all, of “DeFi 2.0” died, some ideas executed in a non “ponzi” way do have an added-value proposition.\nWith the emergence of GHO, we think there are opportunities to diversify the Aave DAO treasury and rework the Safety module with more robust models and ACI want to be an actor of governance discussions around this point.\n\nStablecoin diversity:\n\nThe DeFi ecosystem is addicted to USDC, and it’s a central point of failure and an Achilles heel to the ecosystem. While we consider Circle to be a trustworthy and non-hostile actor, supporting decentralized stablecoins diversity to provide alternatives makes the ecosystem both more resilient and attractive.\nAave is the leader of stablecoin diversity and will soon deploy GHO to participate in this diversity, the ACI is a supporter of this strategy.\n\nLSD diversity:\n\nLiquid staking derivatives or LSDs, are the best form of collateral at the disposal of an Aave user, as yield-bearing by nature, yield is linked to actual economic activity. One of the goals of ACI will be the support the onboarding of a more diverse set of LSDs into Aave V3, leveraging supply & borrow caps and isolation mode to increase diversity while maintaining risk mitigation at the protocol level.\n\nDeFi synergies:\n\nOne of the reasons Aave reached a leadership position was their dedication to the protocol to act as a team player with the ecosystem and encourage synergies.\nYield-bearing assets and LP tokens as collateral could be strategically onboarded in protocol V3 to attract more liquidity and allow users of other protocols to gain borrowing power in Aave.\nAave was a pioneer in this area with the AMM V1 market; while it was too early to show success, time only proved the potential of these assets as the ecosystem gained maturity.\nThe ACI is in favor of increased synergies with Curve, Balancer, Arrakis, and others actors.\nTransparency\nThe ACI fully commits to declaring all votes in the current thread and summarizes the reasons for each vote in complete transparency.\nConflicts of Interest\nAave-Chan Initiative is founded by Marc Zeller, an independent blockchain consultant working with the Aave Companies since 2019; The founder owns AAVE and multiple assets in the ecosystem. The founder is also an Angel investor in various ecosystem projects and will disclose accordingly.\nDelegate address\nACI.eth (0x57ab7ee15cE5ECacB1aB84EE42D5A9d0d8112922)\n\n Improve permissions management on Aave v2 and define a better strategy for access control roles on Aave v3\n\n [TEMP CHECK] Defining the Service Provider & Delegation Platform Relationship\n\n [ARFC] ACI Phase II\n\n Aave Labs Contributions Report\n\n 18\n\n 11\n\n 4\n\n 2\n\n 2\n\n read \n\n 20\n min\n\n post by Doo_StableNode on Nov 30, 2022\n\n post by Jordan on Nov 30, 2022\n\n post by MarcZeller on Dec 1, 2022\n\n post by MarcZeller on Dec 2, 2022\n\n post by MarcZeller on Dec 8, 2022\n\n post by MarcZeller on Dec 12, 2022\n\n post by MarcZeller on Dec 13, 2022\n\n post by MatthewGraham on Dec 13, 2022\n\n post by MarcZeller on Dec 13, 2022\n\n post by MarcZeller on Dec 16, 2022\n\n post by MarcZeller on Dec 17, 2022\n\n post by stani on Dec 19, 2022\n\n post by MarcZeller on Dec 20, 2022\n\n post by MarcZeller on Dec 20, 2022\n\n post by daveytea on Dec 21, 2022\n\n 19 days later\n\n post by MarcZeller on Jan 10, 2023\n\n 4 months later\n\n post by MarcZeller on May 15, 2023\n\n 12 days later\n\n post by MarcZeller on May 27, 2023\n\n post by MarcZeller on May 30, 2023\n\n Load more posts below","tokens":1651,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263624342,"hash":"7c784b4d2d65039aec38045c79f454059da06524"}
{"url":"https://forum.openzeppelin.com/t/setting-crowdsale-rate-manually/1659","domain":"forum.openzeppelin.com","title":"Setting crowdsale rate manually - General - OpenZeppelin Forum","text":"Setting crowdsale rate manually \n\n General\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 5\n\n Oct 2019\n\n 1 / 11\n\n Oct 2019\n\n Nov 2019\n\n post by bayram on Oct 30, 2019\n\n bayram\n\n Traditionally when we create crowdsale smart contract we provide four parameters: initial rate, final rate, opening time, and closing time, which determines current rate when one buys tokens using Ether. For example OpenZeppelin contracts.\nWhy can't we simply define a function, say, setRate(uint) onlyAdjuster and adjust the rate manually? Isn't it more flexible?\nThe matter is that I have created my own ERC20 token and just want to sell it for Ether. I have no time restrictions or final rate, only finite amount of tokens I want to distribute. What is the best practice in my case?\n\n 5\n\n 5\n\n post by abcoathup on Oct 30, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nWelcome to the community \nOpenZeppelin provides a highly configurable Crowdsale base contract that can be combined with various other functionalities to construct a bespoke crowdsale.\nYou could include a manual rate adjustment. I would think of this as the equivalent of a vending machine for laundry or arcade tokens, where the owner could change the price of tokens.\nI would recommend clearly advising participants under what circumstances the rate could be changed and who could change it, including by how much and how frequently.\nYou may want to code these types of restrictions on the rate change into your crowdsale. Such as limiting the frequency of a change (e.g. can only be changed after X time since the last change) and/or the amount (e.g. can only be adjusted up or down by Y%).\n\nYour solution should also have appropriate testing and auditing:\n\nRegards testing, the testing guide is a good place to start: Test smart contracts like a rockstar \n\nPrior to an audit it is worth going through the checklist before an audit.\nTo organize an audit, you would need to engage a third party auditor such as OpenZeppelin, see https://openzeppelin.com/security-audits/ for details.\n\n post by bayram on Oct 31, 2019\n\n bayram\n\n @abcoathup\nThanks for reply.\nYeah, I am using Crowdsale smart-contract.\nAs you recommend we do have our rules on under what circumstances the rate could be changed and who could change it. But I’d like simply to create a rate setter with restricted access and change it manually according to rules.\n\n post by abcoathup on Oct 31, 2019\n\n post by bayram on Nov 1, 2019\n\n post by abcoathup on Nov 1, 2019\n\n post by bayram on Nov 1, 2019\n\n post by abcoathup on Nov 1, 2019\n\n post by bayram on Nov 2, 2019\n\n post by abcoathup on Nov 2, 2019\n\n 1 year later\n\n Split this topic on Dec 13, 2020\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Help me write an erc20 token and a crowdsale contract\n\n Contracts\n\n erc20\n\n 9\n\n 8.0k\n\n Dec 2020\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020","tokens":823,"squid":"ink-security_audits","role":"Sentinel","at":1791263627703,"hash":"1faf1c258c508694511a2cfcb1a2ad110d43f28c"}
{"url":"https://governance.aave.com/t/aave-chan-initiative-delegate-platform/10877","domain":"governance.aave.com","title":"Aave Chan Initiative Delegate platform - Delegate Platforms - Aave","text":"Aave Chan Initiative Delegate platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2022\n\n 1 / 44\n\n Nov 2022\n\n 4d ago\n\n post by MarcZeller on Nov 30, 2022\n\n MarcZeller\n\n Aave Chan Initiative Delegate platform\nKey Info\n\nDelegate Address: ACI.eth\nTelegram: @Lemiscate\nDiscord: Marczeller | Aave#3432\nTwitter: https://twitter.com/lemiscate (founder) https://twitter.com/AaveChan (ACI)\nVoting record: Boardroom\n\nIntroduction\nThe Aave-Chan Initiative (ACI) is a delegate platform founded by Marc Zeller, an independent blockchain consultant working with the Aave Companies since 2019. The ACI aims to participate in governance discussions on Aave and create snapshot votes & AIPs to be submitted to community vote for the benefit of the Aave protocol.\nDelegate Statement (why you should delegate to us)\nThe Aave-Chan Initiative, while being a new structure, already has a long track record in the Aave governance (Co-author of AIP-1) and forum discussions.\nAs the Aave ecosystem is getting more mature, the protocol benefits from more delegation diversity with their independent visions and value propositions for the Aave protocol.\nAs delegates, we commit to dedicating our time and resources to support Aave’s development and growth.\nWhat voters can expect from Aave-Chan Initiative:\n\nActive: we have a strong track record of governance participation and will be involved in governance at each step of AIPs process from ARCs to onchain AIPs votes\nVision: The ACI main goal and focus is the Aave protocol success, ACI is dedicated to DeFi ethos and long-term games.\nFocus: ACI has no plan to expand into other protocols governance actively and will remain laser-focused on Aave.\n\nOur main focus points at launch are:\n\nTreasury efficiency:\n\nEvery $ in the Ecosystem Reserve, in the Aave DAO treasury, should be cherished as the property of every AAVE token holder, and each spending should be done with the full intent to provide the maximum benefit for the Aave protocol ecosystem and not just be considered as a “buffet” to drain easy money by overcharging services. the ACI is fully dedicated to playing “Scrooge McDuck” in Aave and will have a slightly softer spot toward spending in Dev & risk mitigation over other aspects.\nBy providing a defacto alternative to current existing services, the ACI will provide both cooperation and competition to existing services with the full intent to contribute to the efficiency of these services.\n\nTreasury Efficiency (II):\n\nThe Aave DAO treasury is currently only gaining yield from depositing into Aave. Both for increased yield and for strategic & synergies reasons the ACI is supportive and wants to participate in less passive management of the DAO treasury, such as examples from llama by doing risk-averse investments that will increase yield:\n\nconvert part of WETH into LSDs to gain staking yield\n\nDeposit part of stablecoins into stableswaps\n\nstake veTokens and vote for Aave related pools\n\nregularly convert part of long tail assets into wETH or stablecoins\n\nTreasury diversity:\n\nThe ACI is supportive of Protocol Owned Liquidity (POL) and bonding. While most, if not all, of “DeFi 2.0” died, some ideas executed in a non “ponzi” way do have an added-value proposition.\nWith the emergence of GHO, we think there are opportunities to diversify the Aave DAO treasury and rework the Safety module with more robust models and ACI want to be an actor of governance discussions around this point.\n\nStablecoin diversity:\n\nThe DeFi ecosystem is addicted to USDC, and it’s a central point of failure and an Achilles heel to the ecosystem. While we consider Circle to be a trustworthy and non-hostile actor, supporting decentralized stablecoins diversity to provide alternatives makes the ecosystem both more resilient and attractive.\nAave is the leader of stablecoin diversity and will soon deploy GHO to participate in this diversity, the ACI is a supporter of this strategy.\n\nLSD diversity:\n\nLiquid staking derivatives or LSDs, are the best form of collateral at the disposal of an Aave user, as yield-bearing by nature, yield is linked to actual economic activity. One of the goals of ACI will be the support the onboarding of a more diverse set of LSDs into Aave V3, leveraging supply & borrow caps and isolation mode to increase diversity while maintaining risk mitigation at the protocol level.\n\nDeFi synergies:\n\nOne of the reasons Aave reached a leadership position was their dedication to the protocol to act as a team player with the ecosystem and encourage synergies.\nYield-bearing assets and LP tokens as collateral could be strategically onboarded in protocol V3 to attract more liquidity and allow users of other protocols to gain borrowing power in Aave.\nAave was a pioneer in this area with the AMM V1 market; while it was too early to show success, time only proved the potential of these assets as the ecosystem gained maturity.\nThe ACI is in favor of increased synergies with Curve, Balancer, Arrakis, and others actors.\nTransparency\nThe ACI fully commits to declaring all votes in the current thread and summarizes the reasons for each vote in complete transparency.\nConflicts of Interest\nAave-Chan Initiative is founded by Marc Zeller, an independent blockchain consultant working with the Aave Companies since 2019; The founder owns AAVE and multiple assets in the ecosystem. The founder is also an Angel investor in various ecosystem projects and will disclose accordingly.\nDelegate address\nACI.eth (0x57ab7ee15cE5ECacB1aB84EE42D5A9d0d8112922)\n\n Improve permissions management on Aave v2 and define a better strategy for access control roles on Aave v3\n\n [TEMP CHECK] Defining the Service Provider & Delegation Platform Relationship\n\n [ARFC] ACI Phase II\n\n Aave Labs Contributions Report\n\n 18\n\n 11\n\n 4\n\n 2\n\n 2\n\n read \n\n 20\n min\n\n post by Doo_StableNode on Nov 30, 2022\n\n Doo_StableNode\n\n Like many others in the AAVE community, we believe the community is fortunate to have one who’s both knowledgeable and reputable to become a delegate. We look forward to see Marc and Aave-Chan continue to contribute to AAVE governance.\n\n post by Jordan on Nov 30, 2022\n\n Jordan\n\n Marc / Aavechan has been one of the most impactful representant of Ethereum ethos and decentralisation through his work with the Aave companies and within the Aave communities and it’s healthy for the protocol to have him represent an independant voice within the Aave governance.\nACI focus on true open source, risk management and financial conservatism makes me looking forward to delegate to them.\nThe individual proposals for treasury diversification will have to be thoroughly checked by multiple parties to make sure that we do not end up adding more risks to the protocol but overall it’s a welcome addition to further decentralise Aave delegates, which is a space where the community must always be mindful of centralisation risks.\n\n post by MarcZeller on Dec 1, 2022\n\n MarcZeller\n\n Risk Parameter Updates for Aave v2 Polygon\nVote Result: YAE\nRationale\nWe voted Yae. While V3 is the future of Polygon, unfreezing specific assets with disabled borrowing does not increase protocol risk and allows users to manage their position. unfortunately, this AIP didn’t reach quorum, and we’re supportive of a re-run.\n\n post by MarcZeller on Dec 2, 2022\n\n MarcZeller\n\n Aave StarkNet Phase I - Aave <> StarkNet Bridge deployment/activation by Aave governance\nVote Result: YAE\nRationale\nWe voted YAE. Pretty exciting to see the first steps of Aave toward a new ETH L2. Starknet Zk will allow scalability and new use cases for Aave and is a good direction for Aave expansion.\n\n post by MarcZeller on Dec 8, 2022\n\n MarcZeller\n\n Set LDO, stMATIC, MaticX and SD Emission_Admin for Polygon v3 Liquidity Pool\nVote Result: YAE\nRationale\nThe ACI voted YAE, LSDs yield loops are a strategic growth vector for Aave increasing both liquidity & borrow volume and thus protocol revenue.\nThis AIP allows LSDs partner on polygon to participate in LM program to support Aave liquidity growth, it’s a clear win-win for every party involved.\n\n post by MarcZeller on Dec 12, 2022\n\n MarcZeller\n\n Freeze Aave V1\nVote Result: YAE\nRationale\nthe ACI voted YAE, Aave V1 is not gas optimized and lack the upgrades of V2 & V3. A freeze will still allow users to repay their position and withdraw.\nunfortunately this proposal didn’t meet quorum but as it was non-contentious we’re supportive of a re-run.\n\n post by MarcZeller on Dec 13, 2022\n\n MarcZeller\n\n [ARFC] Repay Excess CRV Debt on Ethereum v2\nVote Result: YAE\nRationale\nthe ACI voted YAE use USDC to buy CRV, considering the excess debt amount, usage of the safety module is not required, also as CRV is a strategic asset for the emergence of GHO and considering there’s around 30m$ in DAO treasury in stablecoins, using part of DAO stablecoins while keeping the CRV seems the most efficient strategy.\nwe regret the lack of an “Abstain” option in this vote, while the ACI had no intention to abstain it’s important that the diversity of opinions of the community can be voiced and encourage @Llamaxyz to follow standards if possible.\n[ARFC] Ethereum v2 Collector Contract Consolidation\nVote Result: YAE\nRationale\nthe ACI voted YAE, consolidating the books to USDC is a net positive for the protocol and with the upcoming emergence of V3 the time to do this is fit. we appreciate llama optimization on premium, theses assets auctions from the protocol are basically “slippage-free” winning trades and great opportunities for arb & Market markets, the ACI is supportive of more systemic integration of the auctions (such as with DEX aggregators) to make the clearing of it as fast and smooth as possible while optimizing the premium to make sure the DAO gets the best possible deal from it at the benefit of the protocol.\nDiscussions are ongoing with several potential integrators on this.\n[ARFC] [ARFC] Receipt of Gauntlet Insolvency Fund\nVote Result: ABSTAIN\nRationale\nthe ACI voted ABSTAIN. While we have no strong opposition to this proposal, sending the AAVE to the Ecosystem reserve is basically a gift to the Safety module stakers and these funds will eventually run out. we have the feeling that a more strategic usage of these StkAAVE could have been done (Use them to power a discounted credit line of GHO minting and provide GHO liquidity for example)\n\n post by MatthewGraham on Dec 13, 2022\n\n MatthewGraham\n\n TokenLogic-Finance SP\n\n Hi @MarcZeller,\nThank you for the feedback on the [ARFC] Receipt of Gauntlet Insolvency Fund proposal. Please note, that using the stkAAVE to support GHO adoption is something being looked into. With v3 not yet deployed on Ethereum and seeing v2 liquidity migrate to v3 very slowly, any proposal using stkAAVE to support lower GHO borrowing rates just now is a bit early. If such a proposal was to emerge at a later date, it will likely be at a larger scale than what would be supported by the Gauntlet holding.\nGreat delegation thread. I really like reading your feedback on each of the proposals. Thank you for being a consistent voter as well. \n\n post by MarcZeller on Dec 13, 2022\n\n MarcZeller\n\nIn accordance to our previous position, the ACI voted YAE on the Re-run of this proposal.\nFinger crossed for quorum!\n\n post by MarcZeller on Dec 16, 2022\n\n MarcZeller\n\n [Temp Check] Deploy Aave on Metis\nVote Result: ABSTAIN\nRationale\nthe ACI rationale was explained in the thread here: Launch Aave V3 on Metis - #47 by MarcZeller\n[ARFC] Aave DAO Policy Change: Halt Listings on all Aave v1 & v2 Non Permissioned Deployments\nVote Result: YAE\nas stated many times, V3 is the future of Aave, with current market situation, the protocol needs to fully use the supply and borrow caps to limit risks, adding new listing to V3 exclusively will also add to V3 attractivity and support transition to the new version of the protocol\n[ARC] Updated: Gauntlet <> Aave Renewal\nVote Result: YAE\nAs Gauntlet switched to a fixed fee model, the ACI is plainly supportive of this proposal. Independent third-party risk service providers are key to protocol resilience and the ACI is looking forward to working with gauntlet in 2023.\n\n post by MarcZeller on Dec 17, 2022\n\n MarcZeller\n\n Aave v2 ETH Interest Rate Curve Update\nVote Result: YAE\nRationale\nLSD yield optimizer loops are a massive driver of Aave protocol revenue. This upgrade of interest rate strategy will both increase the expected yield of these strategies and overall protocol revenue while keeping risks at acceptable levels.\nThe ACI is plainy supportive of this proposal and will also support related proposals in the MATIC ecosystem.\nKudos to @Llamaxyz & Gauntlet for their collaboration on this AIP.\n\n post by stani on Dec 19, 2022\n\n stani\n\n Aave Labs-Technical SP\n\n Super exciting to see the Aave Chan Initiative - @MarcZeller has always had his heart within the Aave community and been valuable contributor over the pasts years. ACI is a great initiative to support the Aave DAO directly as a delegate - will support Marc fully on the Aave Chan Initiative \n\n post by MarcZeller on Dec 20, 2022\n\n MarcZeller\n\n Freeze Aave V1\nVote Result: YAE\nRationale\n\nThe ACI position did not change with this re-run, V1 is legacy tech and as a cost-to-run (chainlink price feeds infra), we’re supporting progressively fading out legacy versions of Aave to allow focus on V3 and reduce overall cost.\n\nAgain, ACI position did not change from snapshot vote, we look forward to keep working with Gauntlet in 2023\n\n post by MarcZeller on Dec 20, 2022\n\n MarcZeller\n\n Authorise the release of Aave <> Chainlink Proof of Reserve for Aave Avalanche\nVote Result: YAE\nRationale\nProof of Reserve is a net positive for the Aave protocol resilience, as Harmony market events shown, even a functioning Aave can suffer from infrastructure it’s built upon. PoR implementation while not eliminating risks, helps in these scenarios. the ACI is supportive.\n[ARFC] Aave v3 Polygon wMATIC Interest Rate Update\nVote Result: YAE\nRationale\nAs stated multiple times and in line with our delegate platform, the ACI supports LSDs yield leverage strategies as big potential drivers of protocol revenue, this interest rate strategy allows for these strategies to scale and be more profitable while making Aave V3 on polygon more attractive overall.\n[ARFC] BAL Interest Rate Curve Upgrade\nVote Result: YAE\nRationale\nFor the same reasons of wMATIC vote, the ACI is supportive of a proposal in line with its delegate platform.\n\n post by daveytea on Dec 21, 2022\n\n daveytea\n\nI fully support and trust @MarcZeller to play Scrooge McDuck to ensure rational spending \n\n 19 days later\n\n post by MarcZeller on Jan 10, 2023\n\n MarcZeller\n\n snapshot votes\n\n[ARC]: Risk Parameter Updates for Aave V3 Optimism 2022-12-29\nVote Result: YAE\nRationale\nThis temporary arc is an act of caution given the relatively low liquidity of AAVE on OP. It should be followed by a more robust AIP later when risk teams will recommend risk parameters for this asset.\nApprove pricing approach for WBTC on Aave\nVote Result: WBTC oracle based on WBTC\nRationale\nIt was not an easy choice, while we firmly believe wBTC value will always “mechanically” go back to peg due to bitgo redeemability and any offpeg event is temporary in nature. it is a better security practice to track the asset directly and not the underlying, in the case of Bitgo issue, doing this will allows liquidation to happen and reduce the negative consequence of this kind of event.\nUpdated: Aave Grants DAO Renewal\nVote Result: YAE\nRationale\nThe ACI supports this updated proposal, our “Scrooge McDuck” campaign allowed 750k$ cost-cutting while maintaining a high-quality of AGD program.\nAIPs\n\nUpdate renFIL rate strategy on Aave v2 Ethereum\n\nRewards controller update across V3 pools\n\nRisk Parameter Updates for Aave v2 Ethereum - LTs and LTVs for Long Tail Assets\n\nRisk Parameter Updates for Aave v2 Ethereum - LT and LTV (DAI, USDC)\n\nSupply/Borrow Cap Updates for Aave v3\n\nChaos Labs Aave v2 Coverage\n\nRisk Parameter Updates for Aave V3 Optimism Market (2022-12-29)\n\nVote Result: YAE\nRationale\nthe ACI voted in support of these proposals (rationales are the same as on snapshot vote). This batch of AIPs during the holidays all reached quorum thanks to the activity of platform delegates and the aave community, that being said, we do not recommend in the future to post AIPs in the middle of holidays to increase the odds of reaching quorum.\nYAE2949×2780 1.06 MB\n\n 4 months later\n\n post by MarcZeller on May 15, 2023\n\n MarcZeller\n\n mic check - one two, one two, does this thing work?\nWith the ACI we apologize for the lack of updates in this section of the forum, we got ourselves busy and didn’t take the time to update the huge amounts of TEMP CHECK, ARFC, AIPs, votes & updates we participated in.\nWe will try to re-start the updates in here, obviously too much has happened since our last update so we start back from now.\nAIPs/proposals :\n\nBUSD offboarding part II\nfUSD onboarding\nemode for rETH\nRPL onboarding\nonboard MAI on optimism\nonboard MAI on Arbitrum\nconvert aWETH to LST assets\n\nFrom now on we’ll try to publish here a short-term roadmap (less than a month delivery), then update with work done & publish the next roadmap.\nwith upcoming new hires in the ACI team, we should be able mid-term to publish much more detailed posts in here.\nimage571×513 14.7 KB\nthanks for reading and we would like to express our gratitude towards the 200+ addresses trusting us with their delegations, we will keep working hard to be worthy of your support!\n\n 12 days later\n\n post by MarcZeller on May 27, 2023\n\n MarcZeller\n\n following the snapshot vote for the Delegate Code of Conduct.\nBy this post, the ACI is officially stating its intent to follow this code and is proud to participate in this initiative.\n\n post by MarcZeller on May 30, 2023\n\n MarcZeller\n\n Henlo frens, here’s an update on previous Short Term roadmap\n\nA new “roadmap” will be published shortly to announce the next areas of focus for the ACI\nAs we react to most proposals on the forum directly, for now, we do not update here with every single vote rational as it’s quite time-consuming.\n\n Load more posts below","tokens":4542,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263635718,"hash":"266e6813f84f961d1e225eba3a8eb5bc71352b1f"}
{"url":"https://blog.openzeppelin.com/follow-this-quality-checklist-before-an-audit-8cc6a0e44845/","domain":"blog.openzeppelin.com","title":"Follow this quality checklist before an audit - OpenZeppelin blog","text":"February 5, 2019OpenZeppelin SecurityOriginally written by Leo AriasThank you for your interest in this post! We’re undergoing a rebranding process, so please excuse us if some names are out of date. Also have in mind that this post might not reference the latest version of our products. For up-to-date guides, please check our documentation site. You can see the latest version of this document here.At OpenZeppelin we help protect the core infrastructure of open and decentralized applications. I’m part of the Research team, which is in charge of conducting security audits. We review tons of lines of code written by very smart developers for projects that will shake the foundations of our society.Finding security vulnerabilities in this futuristic cypherpunk environment is super challenging and fun, but we have already covered those topics elsewhere. I think that security actually starts in a pretty boring and traditional place, full of the wisdom that our elders have collected through millennia of developing software in community. Standing on their shoulders, I now want to share our checklist for basic quality measures that your next awesome project should consider before you hand it over for an external audit.✔️ Choose a free software licenseClosed code is inherently insecure. If people who use your project can’t inspect it, study it, hack it, and experiment on it, there’s no way it can be trusted. If you hold abusive control over your users, nothing prevents you (or anyone more powerful than you) from making them vulnerable.Take a look at the Free Software Definition, and begin with choosing the license that best suits your needs.Update: previously we introduced here Richard Stallman as a wise elder, dressed as a saint 🤦. This joke no longer seems appropriate due to his repeated bad comments, brought to light by a recent controversy. Let’s just say that we thank him for having hacked copyright laws, for starting the free software movement, and for writing the above definition. And that we consider appropriate him stepping down from his leadership position in the free software community.✔️ Build your core team of maintainersWhen your project succeeds, hundreds of external contributors will surely be supporting it. But in order to get to that point, you’ll need to bootstrap with a strong and diverse team of core maintainers. They’ll take care of the bulk of the work, the fun and the boring parts, proposing and reviewing the code of your shared project. Together, you all need to have strong knowledge of all points on this checklist. Look not only for technical knowledge, but also for a knack for cat-herding and a healthy work style — because, well, things will get complicated.Pay attention to your bus factor: make sure your team members are sharing their expertise, the lessons learned, and their responsibilities, while at the same time constantly mentoring new people that could potentially join the core team.And somebody will have to lead and orchestrate in order to get value out of the eternal tendency toward chaos. Let me introduce you to the magician, Camille Fournier, who wrote THE book on technical management, The Manager’s Path.Camille Fournier (Image taken from her website)✔️ Write clean codeThe only valid measurement of code quality is WTFs per minute. This point must be simple. If things get overly complicated or weird, you’re doing it wrong. Go for a walk and try again with fresh eyes.But don’t get me wrong: no interesting software project is simple. Add the complexity dimensions of decentralization, transparency, cryptography, and all these shiny ideas that are keeping us so busy these days. It’s complicated by design. But with the correct abstractions, a well thought-out model, and proper encapsulation, you can start building the bank-killer app one line at a time. And each of those lines must be clean and readable.I’m not a spectacular programmer, I was just lucky to find Uncle Bob Martin’s book Clean Code at the right moment and to have read a never-ending stream of very, very ugly code.Robert Cecil Martin (Image taken from Wikipedia)Once all core maintainers reach common ground on this topic, you should enforce a consistent code style by running a linter on every new line of code that’s added. The particular rules aren’t as important as following them strictly is, but if you can sacrifice your peculiar preferences to be consistent with the rest of the world, your contributors will appreciate it a lot.I also practice slow-food… er, slow programming. Take your time, enjoy the journey to mastering this craft, and when you’ve built something you can proudly set free, let the masses read it and judge it.✔️ Write unit testsWrite unit tests. Tons of them. 100% coverage. This might sound extreme, but hey, your code is now playing directly with somebody else’s money. If you forget, or just get lazy and don’t write a test for that super obvious line of code, you might be leaving an open door for an exploit later in the game that will make your project crash, and all this magic internet money will disappear in no time. It has happened.I feel immediately more secure when I do test-driven development. At least give an honest try to writing the tests first, and get into a cycle of red-green-refactor. There are other techniques that can achieve the same result, but I suggest starting there and then deviating if you find good reasons to do so. Never worked this way? Read Test Driven Development: By Example by Kent Beck. It’s a quick read that will help you avoid the temptation of just jumping into code without thinking it through.Then, even if you design for testability, you’ll find many scenarios that are hard to test. Gerard Meszaros provides all the answers in xUnit Test Patterns. This book is huge, so I recommend choosing a designated test expert on your team.Kent Beck speaking in 2001 (Image taken from Wikipedia)Gerard Meszaros (Image taken from Twitter)Finally, make sure to run your unit tests on every single pull request, and make sure they’re all green before merging the changes. In addition, you can set up a test coverage report to ensure that test coverage never goes down.✔️ Test early, test often, test agileNow that you have your first layer of tests covered with tons of unit tests, what comes next is…more tests! You need to test the integration between all of your components, then go one level higher to test your application from the point of view of a real user, and then go even higher to test the interactions with other systems end-to-end.To me, this is the biggest challenge, and designing a good process that keeps many bugs out of your system can be as difficult as designing the system itself. Iterate, automate as much as possible, share the load of manual testing…and let your community help.We’ll talk later about community, but I think this is the reason for publishing your code as early as possible: you can get help from early adopters and enthusiasts to validate your system, not only for correctness but also to verify that you’re focusing on the right user stories and that you’re tackling a real problem with a user-friendly solution.A lot has been written about iterative development processes that deliver functionalities in progressive sprints and milestones. I found Mike Cohn’s Succeeding with Agile: Software Development Using Scrum a good place to start, but keep in mind that any methodology will have to be adjusted to your team, your users, and your context. There are a lot fewer resources focused on the quality and testing part; that’s why I was so happy when I read Agile Testing by Lisa Crispin and Janet Gregory, which is full of good ideas and advice. But let me stress again: nothing you read will perfectly fit your project, so take your time to design the testing process with as much love and care as you use when designing the system’s architecture.Mike Cohn in 2013 (Image taken from Wikipedia)Lisa Crispin and Janet Gregory (Image taken from their website)While there’s still some debate about the perfect moment for auditing a project (i.e, before or after the code is published), I think audits should be performed when there’s a release candidate ready to be deployed to mainnet, after you have performed extensive alpha and beta testing. I see room for auditing before the code has been published, but in this case, the audit would be more related to checking that the development process will lead to a high-quality, properly tested release candidate and validating the bases of your project than to performing a deep and thorough inspection of the codebase.However, this doesn’t mean that you have to wait until the end of a long development phase to prepare for a release and audit. Once you start writing and testing clean code in incremental iterations, it becomes easier to think about your complex system. Many smaller independent parts will start to pop up, which can be extracted, generalized, and packaged for reuse, reducing anxiety for developers and auditors.✔️ Write documentationThis is my least favorite part, by far. So let’s keep it simple, starting at the beginning: the README, the most important file of your repository. And yet, it’s usually either empty or bloated, outdated, and ugly. Ideally, as it’s the first thing developers and potential contributors will read, it should work as a clear, straightforward index of your project.It’s best not to get creative here. Just follow this simple specification that works for all cases, proposed by Richard Littauer in Standard Readme. Do not forget to include a specific section in the main README that states how people should disclose any security vulnerabilities found in your project.Richard Littauer (Image taken from Twitter)Next come the docstrings, the documentation inside your code files. We hit an apparent conflict here, since in theory, if your code is clean, it will not require documentation. However, note that we are no longer designing standalone systems that work as a black box. We are building protocols for decentralized applications, and your code will be called by all sorts of external agents. So by all means, document every function that’s part of the contract’s public API, following the NatSpec format.Which brings me to the next point. I highly recommend that you document the specification of your protocol — that’s how others will know what to call and what to expect. But more related to the topic at hand, in an audit, we check that the implemented code works as intended by the specification. That’s why this document is a must: without it, auditors will just guess at your intentions, which might result in some issues getting missed because they’re completely consistent within the system but take it to a state that you want to avoid.Finally, there’s the user documentation. For high-quality systems, writing the user documentation should be mostly painless. The moment things get cumbersome while documenting, consider re-evaluating your user stories, and don’t be afraid to go back to iterate on them.✔️ Check your dependenciesYour project builds on top of many, many others. It will probably depend at least on the Ethereum protocol and its network of nodes, and on Solidity, a bunch of Ethereum Improvement Proposals and their implementation, libraries for testing and UI, and maybe hundreds of other small projects. Even if yours is secure, you need to check how healthy your dependencies are, since they can easily become the source of vulnerabilities.Earlier, I mentioned that your team should have strong and diverse knowledge. That includes knowledge of all the projects that surround you. You should be able to write idiomatic code following the best practices of the language, to identify and avoid known issues, always keeping an eye on new CVEs that may directly (or indirectly, through third-party dependencies) affect your project. Moreover, try to participate in the communities around your dependencies, as it’s an excellent way to see firsthand how safe and trustworthy they are. You should also consider actively participating in those communities, to gain some karma that will surely come in handy later when you need new features and bug fixes.Pia Mancini (Image taken from her website)Moreover, don’t forget to pay attention to your dependencies’ finances. When making your project’s budget, take into account a share for your dependencies, as they may need it in order to remain actively maintained. There’s a very nice project called OpenCollective, led by Pia Mancini, which is making it extremely easy to transparently support the organizations and developers you depend on.Specific to Ethereum and Solidity, the community is collecting the lessons learned (usually in a painful way). You can learn a lot about interesting and tricky vulnerabilities playing the Ethernaut capture-the-flag game. We’ve published many of our past audits with descriptions of the issues found, recommendations, and usually a link to the patch that fixes them. All of our learnings from audits are distilled into the OpenZeppelin package, which you should definitely add to your list of dependencies — if you’re not one of the thousands that already did. The Smart Contracts Weakness Registry maintained by the Mythril team is also a great resource for learning from the experience of others.Whatever approach you take, remember that as the Ethereum space is very young and unexplored, we’re learning many things as we go, so always proceed with caution.✔️ Build your communityThis is a complement to the first point: code without a community is insecure. The community gives you eyes to monitor the project, hands to test it in a real environment, support to survive challenging problems, and resilience to adjust to the unexpected. No amount of money, experience, or knowledge can substitute for this.Once you publish the code, you can get started engaging your community. If your project is interesting, they will come, and this is where the cat-herding abilities of your team will shine. However, you definitely need to set up proper and fluent communication channels, invest in some marketing, and hire a bold community manager with a plan to disentangle and wisely leverage all the opportunities your community brings. I can’t recommend highly enough the writings and videos by Jono Bacon, who has covered all the topics you can imagine about community management.Jono Bacon in 2014 (Image taken from Flickr)You should be thoughtful and caring with your community. A small step that goes a long way is to adopt and enforce a code of conduct so you can all feel safe. Then, write some contribution guidelines to make sure that all of their enthusiasm can be put to good use and they don’t get lost. Lastly, think about setting up a bug bounty program that will encourage your community to watch out for vulnerabilities in the wild, providing hackers with enough incentives to disclose security issues in a responsible way.tldr:✅ Choose a free software license.✅ Build a strong and diverse team of core maintainers.✅️ Increase your bus factor: share knowledge and responsibilities.✅ Choose a good leader.✅️ Write clean code.✅️ Enforce a consistent code style.✅️ Ensure 100% unit test coverage.✅️ Enforce green tests on all your pull requests.✅️ Design your iterative development and testing process.✅️ Publish your code.✅️ Write a good README.✅️ Document the functions of your public API.✅️ Document your protocol.✅️ Write the end-user documentation.✅️ Make sure that your dependencies can be trusted.✅️ Review known issues and keep an eye out for new ones.✅️ Use OpenZeppelin Contracts, the community-vetted standard for smart contract development.✅️ Build and care for your community.Ready to hire an auditing team?That’s us! 🙂 The OpenZeppelin team can help you assess the quality of your project and processes. We’ll take a deep and thorough dive into your code, with years of experience hacking, researching, and developing on blockchains, plus a little touch of Latin American fire, to give you and your users all the confidence you need to continue building the core systems of this new decentralized, global, and open economy.Thanks to Martín Abbatemarco for editing this post, to the OpenZeppelin team for the continuous experimentation and feedback, and to our customers for trusting us and helping us better understand what makes a free software project awesome.Originally published at elopio.net on February 8, 2019.","tokens":4131,"squid":"ink-security_audits","role":"Sentinel","at":1791263640084,"hash":"4a51e30052f05d237c47f6b553f8ed2f24188df7"}
{"url":"https://blog.openzeppelin.com/openzeppelin-rebranding","domain":"blog.openzeppelin.com","title":"Say Hi to OpenZeppelin, the Company - OpenZeppelin blog","text":"July 22, 2019OpenZeppelinToday we are announcing our new company name and brand structure: OpenZeppelin. This change from our previous name, Zeppelin Solutions, allows us to look deeply at our brand and at how it can better reflect who we are and where we’re headed as an organization.Our journeySince founding the company, we’ve created a set of complementary projects and services, focused on security and developer tooling.We’ve built the most popular library for smart contract development (it powers 3,000+ public projects and 180+ contributors); worked with the Ethereum Foundation, Coinbase, and other leading organizations in the security audit space; and have begun creating a development platform for decentralized applications and an amazing community of developers. Through these efforts, we aim to empower creative individuals and businesses to build an open economy, powered by blockchain technologies.We conducted each of these initiatives under different names, using the word “Zeppelin” to tie them all together. However, we realized that having different brand names with different visual identities didn’t help our clients, users, or community to understand what the relationship between our offerings was. Having a unified company voice is critical to conveying that there is a single team, community, and mission behind everything we do.Also, the “Zeppelin Solutions” name made it look like we were a consulting-first company. While we do offer security consulting services, we are a technology-first company. Doing security audits is simply part of our company strategy to work with and learn from the best firms in the space, and have revenue to grow the business.OpenZeppelin, the companyOf all the previous brands, OpenZeppelin was the most recognizable. Many of our users and community members even referred to us as “the OpenZeppelin team.” So we decided it made sense to unify all our efforts under that one umbrella.This way, we keep both our original “Zeppelin” identity and the concept of “open,” which speaks to our overall mission and values. Accordingly, our suite of products and services will now follow one unified structure:OpenZeppelin is now OpenZeppelin ContractsZeppelinOS is now OpenZeppelin SDKZepKit is now OpenZeppelin Starter KitsAudits is now OpenZeppelin Security AuditsThis new structure is also reflected in our site, blog, documentation, social channels, and forum.We believe that an open, global economy is critical to enabling economic freedom . Through our work and identity, we aim to empower creative individuals and businesses around the world to build this new economy. Join us on the journey ahead!","tokens":665,"squid":"ink-security_audits","role":"Sentinel","at":1791263650323,"hash":"34c83276e2bd6a7daa7a499477e2e798c82dc42f"}
{"url":"https://governance.aave.com/t/who-can-bring-governance-topics-to-a-vote-under-governance-framework-v2/25462/1","domain":"governance.aave.com","title":"Who can bring governance topics to a vote under Governance Framework v2? - Governance - Aave","text":"Who can bring governance topics to a vote under Governance Framework v2? \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 10\n\n 1 / 3\n\n Aug 11\n\n Aug 10\n\n post by Millesimillia on Aug 10\n\n Millesimillia\n\n I raised this question in the [ARFC] Governance Framework v2 thread on 9 August, while the Snapshot was still open: [ARFC] Governance Framework v2 - #4 by Millesimillia\nIt did not receive a response, and the vote has since closed with 392,100 AAVE in favour and none against. I am opening it here so it has a proper home. This is a request for clarification, not an objection to the framework.\nIn the framework, author restrictions appear in three places only: the business case for a New Asset Listing and for a New Network Deployment, both reserved to Aave Labs or TokenLogic, and the Direct-to-AIP path, limited to active Service Providers. The Standard Process does not appear to restrict ARFC authorship.\n\nIs it correct that any token holder may author an ARFC on topics outside asset listings and network deployments - tokenomics, buybacks, service provider selection criteria, service provider reviews?\n\nOpening a Snapshot requires a place on the Authors list or 80,000 AAVE of proposition power. What is the route for a holder below that threshold whose ARFC has community support? Is there a sponsoring mechanism, and who maintains the Authors list?\n\nWith TEMP CHECK retired, what is the intended low-barrier entry point for community-initiated topics?\n\nCommitments have been made in governance discussions that token economics would remain firmly in view, and I take them in good faith. My question is structural rather than about intent: what keeps token economics transparent to holders over time, when every service provider also carries equity and revenue interests of its own? Concretely, is there a fixed reporting cadence on protocol revenue and its allocation that does not depend on which provider holds which mandate?\n\nIf the reading above is correct, I would ask that a short subsection on community-initiated proposals be added: who may author an ARFC, the route to Snapshot for authors below the threshold, and who maintains the Authors list. The framework states that it shall be maintained over time, so this seems a natural place for it.\nTransparency and accountability on these points would make AAVE stronger, not weaker. Over the medium term I would like holders to be able to judge the token the way shareholders judge a company: on disclosed economics, a predictable reporting rhythm, and a clear line from protocol revenue to the token.\nDisclosure: I am an AAVE holder and staker, without material proposition power. I am not compensated by any party and hold no position with any service provider.\nWarm regards,\nMillesimillia (Edited)\n@TokenLogic\n\n Areta Delegate Platform\n\n post by MconnectDAO on Aug 10\n\n MconnectDAO\n\n I strongly support this question. Aave governance should not only reward those who already have enough voting power or the right connections to move an idea forward.\nStrong proposals can come from any holder, researcher, delegate, or community member. The forum should give serious attention to ideas based on their quality, evidence, and value for Aave, not only on who brings them.\nWe need a clear path for community proposals that receive genuine support but come from authors below the Snapshot threshold. A transparent sponsor process, clear criteria for the Authors list, and public timelines for review would make participation more fair.\nAt the same time, proposals should be judged on impact, risk, and long term benefit. Sometimes well presented proposals move ahead despite limited value, while strong ideas are left behind because the author lacks access or visibility.\nOpen participation with clear accountability will make Aave governance stronger and help ensure that the best ideas get a real chance to be discussed and voted on. @Millesimillia\n\n 1 month later\n\n Closed on Sep 9\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Should Aave Make Governance Discussions Easier for Non-Technical Users to Follow?\n\n General\n\n 2\n\n 109\n\n Sep 20\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n [TEMP CHECK] AAVE Delegate Ecosystem Upgrade: The Aligned Delegates Framework\n\n Governance\n\n 24\n\n 1.4k\n\n Apr 14","tokens":1163,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263657419,"hash":"63d431d206ec62329fa8aec0044d7e82f7385e50"}
{"url":"https://openzeppelin.com/sdk","domain":"openzeppelin.com","title":"OpenZeppelin | Open Source Secure Development Tools","text":"The Open Source Stack for Onchain DevelopersWhether you are launching your first blockchain application or already running an institutional-grade platform, our open source tools give you everything you need to develop, secure, and operate at the industry's highest standards.Start DevelopingTotal value transferred via OpenZeppelin Contracts Explore Stats$38,211,353,386,986DevelopContracts LibrariesAccelerate development with production-ready building blocks you can trust. Use the gold standard smart contract libraries powering nearly every onchain application.Explore ContractsContracts WizardConfigure and generate smart contracts in seconds—pick your standard, toggle the features you need, and export the code straight to your development environment.Try WizardUpgrades PluginsShip upgradeable contracts with confidence using Hardhat and Foundry plugins that automate proxy deployments, enforce safety checks, integrate onchain verification, and more.Explore Upgrades PluginsContracts MCPDevelop secure smart contracts that follow OpenZeppelin standards with AI. Enable the MCP server in your favourite AI assistant to automatically enforce security best practices at every prompt.Try Contracts MCPUI BuilderSpin up a front end for any contract call in seconds. Select the function, auto-generate a React UI with wallet-connect and multi-network support, and export a complete app.Try UI BuilderSecureSafe UtilsNever sign a malicious multisig transaction again. With Safe Utils, you can verify Safe transaction hashes before you sign.Try Safe UtilsRole ManagerDefine role-based permissions with multi-level hierarchies and granular admin controls—ideal for DAOs, multisigs, and custom governance.Try Role ManagerOperateMonitorMonitor onchain activity in real time to watch critical events, detect anomalies, trigger alerts on your preferred channels, and set automated responses with Relayer.DocsGitHubRelayerAutomate onchain transactions with Relayer to schedule jobs, batch calls, and relay gasless meta transactions all within your self-hosted infrastructure.DocsGitHubPrefer not to run your own infrastructure?Our Managed Service delivers fully hosted and operated Relayer and Monitor instances.24/7 oversightDedicated support SLASecurity patchingTalk to an Expert","tokens":569,"squid":"ink-security_audits","role":"Sentinel","at":1791263660966,"hash":"4bbfafde69c638c2001fdf5ceab2ebdf2c118579"}
{"url":"https://governance.aave.com/t/arfc-governance-framework-v2/25348/1","domain":"governance.aave.com","title":"[ARFC] Governance Framework v2 - Governance / General - Aave","text":"[ARFC] Governance Framework v2 \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 20\n\n 1 / 4\n\n Jul 21\n\n Aug 9\n\n post by TokenLogic on Jul 20\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [ARFC] Governance Framework v2\nauthor: @TokenLogic\ncreated: 2026-07-20\n\nSummary\nThis publication presents an overview of the Aave DAO’s Governance Process v2 and, upon implementation, replaces the current Governance Process Document v1. v2 consolidates the governance process, presently spread across v1 and several newer frameworks, into a single canonical reference.\nThe mandatory TEMP CHECK stage of the governance process has been removed, and all role, guardian, and steward mandates have been refreshed to reflect the 2026 service provider landscape. Upon implementation, this framework streamlines the current 19-day process to 13 days, while ensuring risk and technical standards are upheld.\nMotivation\nOverview\nAave’s governance has matured into a lean, Service Provider model built for transparency and speed. This publication provides a holistic overview of Aave DAO’s governance processes and frameworks, designed to keep the DAO efficient, nimble, and structured. A focused group of service providers now delivers the core functions: Aave Labs on development and growth; LlamaRisk on risk; Certora on security; and TokenLogic on finance and growth.\nThis document supersedes the Governance Process Document v1 and shall be maintained over time, always reflecting the community’s current operational structure.\nRationale for retiring TEMP CHECK\nOne of the most significant efficiency improvements to the overall governance process presented here has been the retirement of TEMP CHECK from the standard path. With an emphasis on refining the economics of sequential adjustments in overall market risk, the initial intent to reduce workload on Risk and Technical service providers has been addressed. The process now begins with a business case to determine whether new assets or markets should be deployed.\nFurthermore, since the Governance Process Document v1 was written, the DAO has adopted structured evaluation frameworks, notably the Aave Risk Framework and the Technical Asset Listing Framework, providing clear public criteria that each proposal must satisfy before it can advance. The ARFC stage provides a public discussion window followed by a binding Snapshot vote, providing the community retains a clear opportunity to shape, support, or reject a proposal without running two sequential sentiment rounds.\nA notable distinction: the ARFC vote is binding, allowing the Aave DAO to make commitments before deploying technical resources for larger initiatives, such as deploying Aave Protocol instances, entering new markets within an existing instance, or committing to payment upon delivery of work scopes.\nGovernance Process\nAave’s governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and implement approved changes through a transparent, structured process.\nThe processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate. For more details, please refer to the official documentation.\nEvery type of governance action falls into one of three processes, based upon who they are implemented by:\n\nStandard Process: The default governance process consists of an ARFC governance proposal, a Snapshot vote and an on-chain vote to implement the upgrade. The Short Executor implements the vast majority of AIP proposals, with the Long Executor reserved for major upgrades.\nDirect-to-AIP Process: A refined on-chain voting process designed to enable simple parameter adjustments, not otherwise performed by Stewards, to be implemented quickly.\nSteward Process: This process facilitates high-cadence operational updates implemented by Service Providers within a tightly controlled, limited-access, and bounded environment, allowing the protocol to operate efficiently throughout the market cycle.\n\nimage4296×2163 352 KB\nThe gradual introduction of Steward roles allows for a growing portion of routine upgrades to shift from the Direct-to-AIP process to the Steward Process, streamlining the protocol’s operational readiness by enabling swift action and reducing administrative overhead. Token holders remain critical to shaping the future of business by retaining key decision-making power and electing to delegate daily operations to trusted actors who operate the Steward roles.\nStandard Process\nThe standard governance process for the Aave DAO follows the guidelines outlined below:\nimage2736×2373 376 KB\nReference: Aave Governance. Adjust Level 2 requirements (long-executor)\n\nGovernance Forum - Aave Request for Comment (ARFC)\nThis is where initial discussions take place, and feedback is gathered. Service providers and community members provide detailed feedback over a 4-day period on how the proposal would affect the protocol, helping prepare it for the AIP stage.\n\nSnapshot\nARFC voting takes place in the Aave Snapshot Space.\n\nVoting: If the proposal meets the required Snapshot threshold, it proceeds to the AIP stage; otherwise, it fails. Authors, proposition power, timing, and thresholds are detailed in the Voting section below.\n\nAave Improvement Proposal (AIP)\nThe AIP stage is where the proposal becomes a formal, on-chain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Aave’s governance contracts, primarily on the Ethereum Mainnet.\n\nVoting: Once on-chain, the AIP is voted on through Aave’s governance contracts. The on-chain stages, quorum, and vote differential are described in the Voting section below.\nExecution: A successful proposal moves to the execution phase, where it is enacted via Aave’s governance infrastructure. Depending on the type of proposal, a timelock delay (either 1 day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave’s Delivery Infrastructure (a.DI).\n\nLong Executor\nThe Long Executor (Level 2) governs the most sensitive parts of the protocol, those that define governance itself. It controls upgrades to the AAVE, stkAAVE, and aAAVE tokens, changes to the governance contracts and their permissions, and modifications to the executors and timelocks themselves. In short, it covers any change that could affect voting or proposition power. Because these changes carry the highest impact, the Long Executor applies stricter requirements than the Short Executor (Level 1), which handles day-to-day protocol matters such as asset listings, parameter updates, and treasury operations. A Level 2 proposal runs a longer 10-day voting period, requires a higher quorum and vote differential, and passes through a 7-day timelock before execution, compared with the 3-day vote and 1-day timelock of a Level 1 proposal. For the current thresholds and contract addresses, see the Aave governance documentation.\nimage4296×1857 366 KB\nDirect-to-AIP Process\nTo support timely implementation of protocol upgrades via Token holder vote, the Direct-to-AIP governance process supports a streamlined 2-step process: a forum post followed by an AIP. By removing the Snapshot vote, the Direct-to-AIP process reduces the governance duration by 4 days and the governance burden. This process is intended to expedite minor changes and can only be proposed by active Service Providers. An illustration of the process is shown below:\nimage2736×1671 221 KB\nTo be eligible for this non-standard Tokenholder voter process, an Active Aave DAO Service Provider must submit a Direct-to-AIP proposal that addresses one of the areas mentioned below:\n\nExisting Asset Listing\nExisting Asset Parameter Update (excl. controlled by Stewards)\nExisting Rolling Maturity Asset Listing Eg: Pendle PTs\nEmission Manager updates\nFunding Updates\nWhitelist Flashloan Borrowers (remove fee)\nTechnical Maintenance\nWhitelist addresses to claim rewards\nExtending SVR Integrations to new instances or assets\nCreation of new hubs and spokes on Aave V4 with existing assets\nRisk Parameters not amendable by Steward Role\n\nStewards Process\nStewards assist the DAO in mitigating potential risks by introducing controlled, incremental exposure adjustments and responding quickly to changing market conditions without the delay of the full governance process. The introduction of a steward role strictly enforces programmatic controls, allowing trusted actors to maintain precise parameters within the protocol, thereby fine-tuning it to prevailing market conditions and limiting exposure to adverse events. The principal rationale for introducing Stewards is to both mitigate risk through tightly controlled exposure limits on Assets and maintain operational readiness.\nimage2287×1482 216 KB\nEach steward is a DAO-owned contract that features delegated authority over a narrow set of parameters or operations, bounded in magnitude and frequency by hard-coded and governance-set limits. Governance owns every steward and can revoke it at any time. The current stewards span risk parameters, the GHO stablecoin, treasury and finance operations, cross-chain bridging (in development), bad-debt maintenance, and oracle migration. The Horizon instance is configured through a related delegated model, described at the end of this section.\nimage1920×3746 373 KB\nGHO Stewards\nThe GHO Stewards manage the GHO stablecoin within bounded limits. The current design is GHO Steward v2, a set of four modular contracts, each gated by a one-day timelock and a maximum change per update, and each callable only by the GHO Risk Council. The GHO Risk Council multisig is 0x8513e6F37dBc52De87b166980Fa3F50639694B60, whose signers are TokenLogic, LlamaRisk, and Aave Labs.\nGHO Aave Steward\nManages the GHO reserve in the Aave V3 core pool. It can adjust the GHO borrow and supply caps (up to +100% per update) and the four interest-rate parameters (optimal usage, base rate, slope 1, slope 2), each bounded to ±500 bps per update, with an overall borrow-rate ceiling of 25% APR. It cannot change collateral parameters, the oracle, or any non-GHO reserve. Cooldown: one day per parameter. Address: 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34.\nGHO Bucket Steward\nAdjusts facilitator bucket capacities, the mint ceiling of each controlled facilitator, by up to +100% per update, and only for facilitators on its controlled list. Cooldown: one day per facilitator. Address: 0x46Aa1063e5265b43663E81329333B47c517A5409.\nGHO GSM Steward\nManages the GHO Stability Module: the exposure cap (up to ±100% per update) and the buy and sell fees (up to ±0.50% per update). Freeze, unfreeze, and price-strategy changes are out of scope and require governance. Cooldown: one day per GSM per parameter. Address: 0xD1E856a947CdF56b4f000ee29d34F5808E0A6848.\nGHO CCIP Steward\nManages the cross-chain (Chainlink CCIP) parameters for GHO: the bridge limit and the inbound and outbound rate limits, each bounded to ±100% per update. Cooldown: one day per parameter. Address: 0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39.\nRisk Stewards\nRisk Stewards manage risk parameters within bounds defined by the Aave Risk Framework. They may tighten or calibrate only within these limits; loosening beyond them or releasing a freeze requires governance. Following the departure of Chaos Labs, the manual Risk Steward is operated by LlamaRisk together with Aave Labs, with a progressive migration to Chainlink Runtime Environment (CRE) automation. The Aave DAO retains full control of the automation.\nRisk Steward\nThe main risk steward. It can adjust supply and borrow caps, collateral parameters (LTV, liquidation threshold, liquidation bonus), interest-rate parameters (base rate, slope 1, slope 2, optimal usage), CAPO price-cap and Pendle discount parameters, and e-mode collateral parameters. It cannot set caps, LTV, LT, or liquidation bonus to zero, change an e-mode’s isolated flag or label, or act on restricted assets and oracles (for example, GHO on Ethereum). Per-update bounds and cooldowns:\n\nParameter\nMax change per update\nMinimum delay\nPending change (ARFC)\n\nLTV, LT, LB\n0.5% absolute change\n72 hours\n-\n\nEmode - LTV, LB\n0.5% absolute change\n72 hours\n-\n\nEmode - LT\n0.1% absolute change\n72 hours\n-\n\nBase rate, Slope 1\n1% absolute change\n72 hours\n36h\n\nSlope 2\n20% absolute change\n72 hours\n36h\n\nOptimal Usage Ratio\n3% absolute change\n72 hours\n36h\n\nSupply and borrow caps\n100% relative change\n72 hours\n36h\n\nCAPO Dynamic Cap\n5% relative change\n72 hours\n-\n\nCAPO Stable Cap\n0.5% relative change\n72 hours\n-\n\nPT Discount Rate\n2.5% absolute change\n48 hours\n-\n\nReference: [ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment\nFreezing Steward\nCan freeze a reserve immediately, blocking new supply and borrow while existing positions may still repay and withdraw. It cannot unfreeze; that requires governance. A tighten-only safeguard.\nFinance Stewards\nFinance Stewards execute pre-approved, budgeted treasury operations on behalf of the DAO through contracts that act as admins of the Collector, without a full on-chain vote. They are operated by the Aave Finance Committee (AFC), the multisig 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa, a 2-of-3 organisation-controlled multisig. The DAO retains ownership and can revoke the role.\nMainnet Swap Steward\nLive. Executes treasury token swaps via the CoW Protocol with a Chainlink oracle price check and slippage bounds, supporting market, limit, and TWAP orders, as well as order cancellation. It can only swap into DAO-whitelisted tokens, within per-token budgets, and proceeds always return to the Collector. Address: 0xb7D402138Cb01BfE97d95181C849379d6AD14d19.\nPool Exposure Steward\nLive. Migrates assets from Aave V2 to V3, and deposits or withdraws Collector funds within Aave V3. It cannot move funds outside approved Aave pools or deplete a reserve below its minimum floor. Address: 0x22aC12a6937BBBC0a301AF9154d08EaD95673122.\nCollector Budget Steward\nTransfers or streams Collector tokens to pre-approved recipients within DAO-defined budgets. It cannot send to non-whitelisted addresses or exceed a budget.\nRewards Steward\nLive. Claims liquidity-mining and Merit rewards accrued to the Collector and forwards them to the Collector. It holds no discretionary transfer power, and must first be granted claim rights by the Emission Manager.\nBridge Stewards\nIn development, not yet live. A family of per-route stewards (Polygon, Arbitrum, Optimism, plus CCTP and LayerZero routes) that will move Collector funds cross-chain back to the Ethereum Collector without a full a.DI governance vote. This fills a gap the Pool Exposure Steward cannot cover, since that steward only moves funds within a single chain. Operators will be set at deployment.\nMaintenance Stewards\nClinic Steward\nLive. Batch-liquidates dust and underwater positions and repays accumulated bad debt, funded from the Collector, within a fixed USD budget cap that only an admin can raise. It cannot act outside repayment, liquidation flows, or exceed the budget. Address: 0xf00E2de0E78DFf055A92AD4719a179CE275b6Ef7.\nDeficit Offset Clinic Steward\nLive. The Umbrella-linked sibling of the Clinic Steward, used to offset reserve deficits through Umbrella’s deficit-elimination flow. Address: 0x6c1DC85f2aE71C3DAcd6E44Bb57DEeF61b540a5A.\nSVR Oracle Steward\nLive. Migrates an asset to a Chainlink Smart Value Recapture (SVR) price feed only when its deviation from the current feed is minimal, and lets the Protocol Guardian revert to the previous feed if needed. Address: 0x8b493f416F5F7933cC146b1899c069F2361cad60.\nHorizon\nHorizon is configured through a delegated model rather than standard governance. The Executive role is assigned to Aave Labs, which manages day-to-day risk parameters, asset listings, oracle configuration, and supply and borrow caps directly, without an AIP vote for each change. The Aave DAO retains ownership of the contracts and controls upgrades, and it still configures the GHO facilitator and credit line by governance vote. Reference: [ARFC] Horizon’s RWA Instance.\nVoting\nOnce a proposal meets the required conditions, it can proceed to the voting stages, which include both off-chain and on-chain voting methods. Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives.\nOff-Chain\nOff-chain votes take place in the Aave Snapshot Space and are the community’s directionally binding signal on a proposal before it moves on-chain. They allow token holders to participate without incurring transaction fees. The off-chain voting stage enables the Aave DAO to make a public commitment to deliver something when there is a difference in timing and/or payment between when the business says it will do something and when that commitment is fulfilled.\nAuthors and proposition power. To open a Snapshot vote, the author must be on the approved list of Authors for the Aave space, or hold at least 80,000 AAVE of proposition power. This filters spam while allowing recognised service providers and delegates to propose without holding a large balance.\nimage3096×1743 323 KB\nController. The administration of the Aave DAO Snapshot space is carried out by the Aave Finance Committee SAFE 0x22740deBa78d5a0c24C58C740e3715ec29de1bFawhilst the Controller is configured to 0x9F8F33e0e22F747617654A50305e61AA9811070C, held by Aave Labs as contingency.\nVoting power. Voting weight is the combined balance of AAVE, stkAAVE, and aAAVE that an address holds or has been delegated, measured at the snapshot block taken when the vote opens. Holders can vote directly or delegate their power to a representative.\nTiming and threshold. Once submitted, a Snapshot enters a one-day voting delay, followed by a three-day voting period. A 320,000 AAVE threshold applies: if it is met, the proposal proceeds to the AIP stage; if not, the proposal fails.\nFor further detail, see the Aave governance documentation.\nOn-Chain\nOn-chain voting is required on any Aave Improvement Proposal. Aave on-chain voting will take place on the Aave Governance Portal. With the launch of V3 governance, it is now possible to vote across multiple chains and cast gasless votes.\nThe on-chain voting process is composed of four stages:\n\nFirst, the proposal and payload are reviewed by Security Service Providers to ensure they are not malicious and don’t contain errors that could put the protocol at risk.\nThe second stage is entered if no errors or a malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a 1-day voting delay must pass before it becomes active.\nIn the third stage, once the voting delay has elapsed, the proposal becomes active and available for voting. This stage lasts for 3 days.\nIn the fourth stage, once the voting period has ended, the proposal will be either SUCCEEDED or FAILED, depending on whether it has reached quorum and received a majority of YAE votes. In this stage, if the proposal has passed, the payload is queued with a 1-day timelock; once this has elapsed, the payload may be executed. If the proposal is not executed before the end of the 7-day grace period, it expires and must be deployed and voted on again at the start of the on-chain voting process.\n\nA visual representation of this flow is shown in the figure below.\nimage3576×1593 329 KB\nQuorum\nFor a proposal to succeed, at least 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote, and the winning option must receive at least 320,000 votes.\n\nQuorum-failure rule: a proposal that fails the Snapshot vote due to a lack of quorum, rather than due to a rejecting majority, may reopen the Snapshot once without restarting from the ARFC stage.\nAnti-spam brake: the proposition power and whitelist gate at Snapshot submission.\nFinal token-holder break: the on-chain AIP vote and the one-day timelock.\nMalicious-proposal backstop: the Governance Emergency Guardian retains its power to cancel.\n\nGovernance Frameworks\nThe Aave DAO has predefined frameworks for common types of proposals, simplifying the governance process:\nAsset Onboarding Framework\nStandardised lifecycle for onboarding new assets to the protocol, providing a structured process for risk assessments and community discussions.\nOnboarding the right assets is one of the most direct levers the DAO has for growth. Each new asset can deepen liquidity, expand borrowing demand and protocol revenue, extend GHO’s reach, and unlock integrations and user acquisition. The framework makes that growth deliberate: assets are prioritised by verifiable demand, credible commitments, and strategic fit with the wider Aave business, and are onboarded only once they meet the DAO’s risk and technical standards. The below outlines the asset onboarding and expansion process:\nimage4296×1620 358 KB\nNew Asset Listing\nThe New Asset listing framework uses the Standard Process to list assets on the Aave Protocol for the first time if they have not been listed previously. Introducing a new asset to the Aave Protocol increases the risk surface area and requires rigorous assessment to ensure there is a strong business case for onboarding it.\nOnboarding a new asset is expected to take 13 days following the Standard Process.\nThe Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.\nAsset Listing ARFC Process\nDuring the ARFC stage, a clear business case for onboarding the asset must be provided; the asset then undergoes Risk Analysis and a Technical Assessment to verify its suitability for listing on the Aave Protocol.\nimage4296×969 199 KB\n\nBusiness Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the listing proposal on the governance forum. It presents a clear, validated case for onboarding the asset, including the proposed initial market structure and parameters, and explains how the asset fits the DAO’s broader strategy. Where relevant, it sets out the commitments supporting the listing, such as expected user deposits and debt, incentive budget, liquidity, and planned integrations.\n\nRisk Analysis: The Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.\n\nRisk Assessment: A thorough review of the risks associated with the asset, covering market risk (volatility, liquidity, and secondary-market depth across market conditions), the asset’s historical performance and susceptibility to market fluctuations, and asset-specific legal and compliance considerations. For coinciding asset listings with product launches,\nReference: [ARFC] Aave Risk Framework\n\nAny material finding, such as insufficient DEX liquidity, pauses the listing until it is resolved.\n\nTechnical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the asset’s technical and security profile.\n\nTechnical Assessment: A rigorous review of the asset’s contracts, oracle configuration, access controls, and dependencies, against the requirements of the Technical Asset Listing Framework.\nReference: [ARFC] Technical Asset Listing Framework\n\nAny finding that falls short of Aave’s security standards pauses the listing process until the issue is resolved.\n\nExisting Asset Listing\nThe Existing Asset listing framework applies only to assets already listed on the Aave Protocol; identical assets (syrupAssets) shall follow the Direct-to-AIP process when extending assets to other instances of the Aave Protocol.\nAdding an Existing Asset to an instance of the Aave Protocol is expected to take as little as 5 days following the Direct-to-AIP process.\nThe Aave DAO requires new listing candidates to deposit at least $150 worth of the intended asset into the Aave Short Executor before the market goes live.\nExisting Asset Direct-to-AIP Process\nSimilar to the New Asset Listing framework, each of the three requirements must be met before an AIP is published: Business Case, Risk Analysis and Technical Analysis. Upon completing sufficient due diligence and assessing the expected returns, an AIP shall be published.\nimage4296×969 206 KB\nSimilar to the Asset Listing ARFC process, the Direct-to-AIP shall present the business case for adding the asset to another instance of the Aave Protocol, ensuring a rationale for the listing. In the comments section, Risk and Technical Service Providers are to provide commentary on the proposed parameter configuration and highlight any concerns, including additional dependencies (e.g., bridges) and liquidity considerations.\nNew Network Deployment Framework\nDeploying on a new network extends Aave’s liquidity footprint and revenue base, carries GHO into new ecosystems, and positions the protocol where users, partners, and capital are moving. Because a deployment is a larger commitment than a single listing, the framework weighs the network’s liquidity potential, GHO utility, revenue and integration commitments, and partner distribution before the DAO commits.\nThe New Network Deployment Framework follows the Standard Process for determining whether to deploy a new Aave Protocol instance. This framework provides a transparent approach for evaluating and deploying new instances of the Aave Protocol. The initial ARFC publication focuses on the business case and overall strategy supporting the deployment.\nA single ARFC Snapshot authorises the deployment and can trigger up to three separate on-chain AIP votes. For a deployment with GHO these are: (1) a.DI Path Activation, which registers the Aave Delivery Infrastructure for the new network; (2) CCIP GHO Lanes Activation, which activates the GHO lane on Chainlink’s CCIP; and (3) the Aave Protocol Activation, which brings the market live. The a.DI and CCIP GHO Lanes votes are completed before the Protocol Activation AIP is published. A deployment without GHO omits the CCIP GHO Lanes vote, so only the a.DI Path Activation precedes the Protocol Activation.\nThe Aave DAO requires that at least $150 worth of each listed asset be deposited into the Aave Short Executor before the market goes live.\nimage4296×1329 285 KB\nNew Network Deployment ARFC Process\nFollowing the Standard Process, at the ARFC stage, a clear business case for deploying the Aave Protocol on the network is to be presented to the community. The ARFC publication shall also detail the initial assets to be listed and present a tentative market configuration for discussion.\nGiven the early stage of most networks at the time the Aave Protocol is deployed, some risk considerations, such as DEX liquidity assessments, are based on commitments to provide flexibility in the lead-up to launch.\nimage4296×969 199 KB\n\nBusiness Case: A recognised Service Provider (Aave Labs or TokenLogic) publishes the deployment proposal on the governance forum. It presents a clear, validated case for deploying the Aave Protocol on the network, together with the proposed initial market structure: the assets to be listed, their tentative parameters, and how the deployment fits the DAO’s broader strategy. Where relevant, it also sets out the commercial terms supporting the deployment, including the incentive budget, liquidity and integration commitments, GHO utility, and the availability of Chainlink Oracle and CCIP infrastructure.\n\nRisk Analysis: Risk Service Provider, LlamaRisk, publishes a Risk Assessment on the forum and refines the proposed parameters, which are then incorporated into the original proposal.\n\nRisk Assessment: A thorough review of the risks associated with the network and its initial assets, covering chain-level risk (network maturity, decentralisation, and reliability), market risk (asset volatility, liquidity, and secondary-market depth), and asset-specific legal and compliance considerations. Given the early stage of most networks at deployment, some assessments, such as DEX liquidity, may rely on commitments made ahead of launch.\nReference: [ARFC] Aave Risk Framework\n\nAny material finding pauses the deployment until it is resolved.\n\nTechnical Review: Security is the DAO’s first priority. The Technical Service Provider, Aave Labs, publishes a Technical Assessment on the forum covering the network’s technical and security profile and that of each listed asset.\n\nTechnical Assessment: A rigorous review of the network’s technical and security details, the a.DI (Aave Delivery Infrastructure) integration, oracle and CCIP availability, and each asset’s contract and oracle configuration.\nReference: [ARFC] Technical Asset Listing Framework\n\nAny finding that falls short of Aave’s security standards pauses the deployment until it is resolved.\n\nimage3696×1440 318 KB\nDirect-to-AIP Framework\nThe purpose of the Direct-to-AIP framework is to enable non-controversial, precise parameter updates to the protocol to be implemented quickly. Within the Aave Protocol, there are a number of parameters or access that can be granted that are not currently supported by Steward roles. The Direct-to-AIP provides a means of quickly updating those parameters and of processing routine, non-controversial operational matters.\nimage4296×1611 300 KB\nGovernance Roles\nDelegates & Delegators\nDelegates\nDelegates are community members who have received voting power from other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have entrusted them with their voting power. Delegates are not compensated.\nDelegators\nDelegators are community members who hold Aave, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another person. The person to whom they delegate their voting power is considered a delegate. This system allows delegators to have their interests represented in governance decisions without having to participate directly in every vote.\nContributors and Service Providers\nContributors\nContributors are community members who participate in and dedicate their time to the Aave DAO. They contribute by joining working groups, fulfilling bounties, building on top of the Aave Protocol, or working for the DAO via grants. Contributors work towards completing shared goals that benefit the Aave ecosystem.\nService Providers\nService providers are specialised entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:\n\nLlamaRisk, risk service provider\nCertora, security service provider\nTokenLogic, finance and growth service provider\nAave Labs, development and growth service provider\n\nGuardians\nThe Aave Guardians safeguard the protocol and the integrity of its governance. They operate as two independent multisigs with distinct mandates: the Protocol Emergency Guardian, which can pause markets and act in a protocol emergency, and the Governance Emergency Guardian, which can cancel malicious or erroneous governance proposals. Across the DAO’s emergency and treasury SAFEs, individual signer identities are increasingly withheld and held within organisation-controlled nested SAFEs, a deliberate practice to reduce attack surface (see the June 2026 signer and SAFE configuration update).\nFor more information on the Guardians’ permissions, refer to this detailed view of permissions in Aave systems. For a general overview of their role, see the Medium post about Aave V2 Governance here.\nProtocol Emergency Guardian\nThis Guardian holds the EMERGENCY_ADMIN role in Aave V3 and equivalent roles in V2 and related systems. Its purpose is to act quickly in an emergency to protect the protocol, for example by pausing a market. Following the May 2026 signer rotation, it operates as a 4-of-7 multisig, and to reduce its attack surface, the signer identities are not publicly disclosed. The current signer addresses are listed below.\n\nProtocol Emergency Guardian (4-of-7)\nSigner address\n\nSigner 1\n0x4Ab2Bed1d667260dB34244Ba412817651C2dD52b\n\nSigner 2\n0xc2674C1A1aF0557E1d217fF4F13DF44A637c7C13\n\nSigner 3\n0xe6838d834674eC35EDd53D485770Baa10bdd6AAe\n\nSigner 4\n0xb291232F480F41c75802C4a60F1D2AC03404Afef\n\nSigner 5\n0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E\n\nSigner 6\n0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe58\n\nSigner 7\n0x3fa960f8355D00874D9C7E3350147f5E94859bc2\n\nGovernance Emergency Guardian\nThis Guardian is responsible for cancelling governance proposals if they are detected as malicious or contain errors, typically identified during the on-chain verification stage by Certora. Unlike the Protocol Emergency Guardian, speed is less critical for this role since governance proposals unfold over a period of five days, allowing adequate time for issues to be identified and addressed. The multi-sig configuration for this Guardian is also a 5-of-9 setup. The current Governance Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nGovernance Emergency Guardian\nAddress\n\nSeb (Zapper)\n0xa1c9ceed5ff78f700dc4930514621843b5fac272\n\nMounir (Paraswap)\n0xfd639f49Da6cadc98f01B60900C8BE30C38c4B27\n\nGavi Galloway (Standard Crypto)\n0xbd4DCfA978c6D0d342cE36809AfFFa49d4B7f1F7\n\nNenad (Defi Saver)\n0xDA5Ae43e179987a66B9831F92223567e1F38BE7D\n\nFernando (Balancer)\n0x4C30E33758216aD0d676419c21CB8D014C68099f\n\nRoger (Chainlink community)\n0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396\n\nMariano Conti (DeFi OG)\n0x936CD9654271083cCF93A975919Da0aB3Bc99EF3\n\nMarin (Lido)\n0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nTemplates\nThe standard ARFC templates are collected here for reference. When drafting a proposal, copy the relevant template and adapt it to the specific asset, network, or change.\n\nAsset Listing ARFC Template\n\nTitle: [ARFC] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD\n\nSummary\nThis ARFC proposes onboarding to the Aave instance on the .\nMotivation\nExplain the motivation for listing the Token.\n\nBusiness Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.\n\nA general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.\n\nAt the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in an unapproved or unsanctioned category should not proceed.\nReference: [ARFC] Endorse the Asset Classification Framework (AAcA)\nThe initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.\n\nSpecification\nTicker:\nContract address:\nChainlink oracle:\n\nParameter\nv3\nv4\nValue\n\nNetwork\nYes\nYes\n\nInstance of Aave Protocol\nYes\nYes\n\nHub (Core / Prime / Plus)\nn/a\nYes\n\nSpoke / Spoke type\nn/a\nYes\n\nIsolation Mode\nYes\nn/a\n\nDebt Ceiling\nYes\nn/a\n\nSiloed Borrowing\nYes\nn/a\n\nBorrowable in Isolation\nYes\nn/a\n\nBorrowable\nYes\nYes\n\nCollateral enabled / Collateral-only\nYes\nYes\n\nSupply Cap (v3) / Add Cap (v4)\nYes\nYes\n\nBorrow Cap (v3) / Draw Cap (v4)\nYes\nYes\n\nCredit Line Size / Draw Cap\nn/a\nYes\n\nLTV\nYes\nn/a\n\nLiquidation Threshold (LT)\nYes\nn/a\n\nCollateral Factor (CF)\nn/a\nYes\n\nLiquidation Bonus\nYes\nn/a\n\nMax Liquidation Bonus\nn/a\nYes\n\nLiquidation Bonus Factor\nn/a\nYes\n\nHealth Factor for Max Bonus\nn/a\nYes\n\nLiquidation Protocol Fee\nYes\nYes\n\nCollateral Risk (bps)\nn/a\nYes\n\nVariable Base\nYes\nYes\n\nSlope 1\nYes\nYes\n\nSlope 2\nYes\nYes\n\nUoptimal\nYes\nYes\n\nReserve Factor (v3) / Liquidity Fee (v4)\nYes\nYes\n\nOracle Type (Chainlink SVR / CAPO / Pendle)\nYes\nYes\n\nCAPO: Max Yearly Ratio Growth %\nYes\nYes\n\nCAPO: Minimum Snapshot Delay\nYes\nYes\n\nPrice Cap (stablecoin / CAPO)\nYes\nYes\n\nPendle: Discount Rate / Max per year\nYes\nYes\n\nFlashloanable\nYes\nYes\n\nE-Mode Category (v3) / E-Mode Spoke (v4)\nYes\nYes\n\nDisclaimer\nStatement of the author’s potential conflict of interest and relationship with the asset protocol, and if they received compensation for publishing this proposal\nNext Steps\n\nIf consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage.\nIf the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal\n\nCopyright\nCopyright and related rights waived via CC0.\n\nAsset Listing Direct-to-AIP Template\n\nTitle: [Direct-to-AIP] Template\nAuthor:\nDate: 2026-06-06\n\nSummary\nA brief sentence or two introducing the proposal’s topic. Specifically, the parameters to be updated, which instance of the Aave Protocol and which chains are affected.\nMotivation\nThis section outlines the reasoning, often supported by a business case and supporting analysis, allowing voters to make an informed decision at the time of the vote.\nWhere applicable, include:\n\nThe problem or opportunity being addressed.\nThe rationale for the proposed changes.\nSupporting analysis, research, or market data.\nExpected impact on protocol performance, capital efficiency, risk, or user experience.\nAny relevant business, technical, or governance considerations.\n\nThis section should focus on why the proposal should be implemented, while the Specification section describes how it will be implemented.\nFor assets extended to other instances of the Aave Protocol, as with the original ARFC to list the asset, this section shall include the Business Case supporting the listing. Please see the earlier section for further details.\nSpecification\nA summary of the technical changes to be implemented at the AIP stage.\nThis section should include all information necessary to construct the governance payload, including, where applicable:\n\nMarkets and networks affected.\nAssets affected.\nCurrent values.\nProposed values.\nSmart contracts or protocol components impacted.\nAny implementation or execution considerations.\n\nDisclaimer\nThe author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this Direct-to-AIP proposal.\nNext Steps\n\nPublish an AIP vote for final confirmation and on-chain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\nExisting Asset Listing Direct-to-AIP Template\n\nTitle: [Direct-to-AIP] Listing of (asset) on Aave (instance) on (network) Author: Date: YYYY-MM-DD\n\nSummary\nThis Direct-to-AIP proposes onboarding to the Aave instance on the .\nMotivation\nExplain the motivation for onboarding this asset to another instance of the Aave Protocol.\n\nBusiness Case: When explaining the motivation for listing the asset on a specific chain and/or instance of the Aave Protocol, the proposal shall include firm growth commitments, such as user deposits, expected debt, incentive budget, planned integrations and any unique selling point specific to the token.\n\nA general rule of thumb is that projects with verifiable demand, strong commitments to growing adoption of the product on Aave and/or strategic synergies with the broader business will be prioritised over those with lower revenue potential.\n\nThe initial proposal shall detail the market structure for positioning the asset within the Aave ecosystem, based on the asset’s intended primary use case outlined in the business case.\nReference: [ARFC] Endorse the Asset Classification Framework (AAcA)\n\nSpecification\nTicker:\nContract address:\nChainlink oracle:\n\nParameter\nv3\nv4\nValue\n\nNetwork\nYes\nYes\n\nInstance of Aave Protocol\nYes\nYes\n\nHub (Core / Prime / Plus)\nn/a\nYes\n\nSpoke / Spoke type\nn/a\nYes\n\nIsolation Mode\nYes\nn/a\n\nDebt Ceiling\nYes\nn/a\n\nSiloed Borrowing\nYes\nn/a\n\nBorrowable in Isolation\nYes\nn/a\n\nBorrowable\nYes\nYes\n\nCollateral enabled / Collateral-only\nYes\nYes\n\nSupply Cap (v3) / Add Cap (v4)\nYes\nYes\n\nBorrow Cap (v3) / Draw Cap (v4)\nYes\nYes\n\nCredit Line Size / Draw Cap\nn/a\nYes\n\nLTV\nYes\nn/a\n\nLiquidation Threshold (LT)\nYes\nn/a\n\nCollateral Factor (CF)\nn/a\nYes\n\nLiquidation Bonus\nYes\nn/a\n\nMax Liquidation Bonus\nn/a\nYes\n\nLiquidation Bonus Factor\nn/a\nYes\n\nHealth Factor for Max Bonus\nn/a\nYes\n\nLiquidation Protocol Fee\nYes\nYes\n\nCollateral Risk (bps)\nn/a\nYes\n\nVariable Base\nYes\nYes\n\nSlope 1\nYes\nYes\n\nSlope 2\nYes\nYes\n\nUoptimal\nYes\nYes\n\nReserve Factor (v3) / Liquidity Fee (v4)\nYes\nYes\n\nOracle Type (Chainlink SVR / CAPO / Pendle)\nYes\nYes\n\nCAPO: Max Yearly Ratio Growth %\nYes\nYes\n\nCAPO: Minimum Snapshot Delay\nYes\nYes\n\nPrice Cap (stablecoin / CAPO)\nYes\nYes\n\nPendle: Discount Rate / Max per year\nYes\nYes\n\nFlashloanable\nYes\nYes\n\nE-Mode Category (v3) / E-Mode Spoke (v4)\nYes\nYes\n\nDisclaimer\nThe author of this proposal is not presenting it on behalf of any third party and is not compensated for creating this ARFC.\nNext Steps\n\nPublish an AIP vote for final confirmation and on-chain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\nNew Network Deployment ARFC Template\n\nTitle: [ARFC] Deploy Aave on \nAuthor:\nDate: YYYY-MM-DD\n\nSummary\nThis ARFC proposes deploying the Aave Protocol to the .\nMotivation\nProvide a comprehensive overview of the new deployment, including its technical features, security measures, and any unique benefits it brings to the Aave ecosystem. This section will focus on the following key areas:\n\nNetwork Capabilities: Transactions per second, latency, finality, scalability, security and interoperability.\n\nMarket Positioning: Details what makes this network unique from technical, user distribution, focus areas, and/or strategic alignment perspectives, with the goal of distinguishing this network from others.\n\nBusiness Case: This details the core value proposition for deploying the Aave Protocol on the respective network. The business case will take into consideration the effects of future liquidity, user adoption, market growth, strategic positioning and revenue potential, with a clear vision for the market over time.\nThe following presents a non-exhaustive list of key areas for consideration when compiling the business case:\n\nIncentive Budget.\nLiquidity commitments.\nGHO utility beyond the Aave Protocol.\nRevenue commitment.\nIntegration commitments.\nPartner’s distribution potential.\nAvailability of Chainlink’s Oracle and CCIP capabilities.\n\nTo support Tokenholders making a fully informed decision, the commercial terms supporting the deployment are to be clearly communicated while respecting any non-public information limitations.\n\nUseful Links: Any additional information that can help Aave DAO to decide. This may include recent announcements, links to documentation, a roadmap for network and ecosystem development, and plans.\n\nSpecification\nThis section contains the initial market structure, assets to be included and how the protocol is to be configured. The initial proposed parameters for the deployment should take into account any Unique Selling Points and desired go-to-market strategies, and be configured/positioned to attract users under prevailing market conditions.\n\nParameter\nAsset 1\nAsset 2\nAsset 3\n\nAsset\nwstETH\nWETH\nUSDT0\n\nBorrowable\n\nCollateral Enabled\n\nSupply Cap\n\nBorrow Cap\n\nDebt Ceiling\n\nLTV\n\nLT\n\nLiquidation Bonus\n\nLiquidation Protocol Fee\n\nVariable Base\n\nVariable Slope1\n\nVariable Slope2\n\nUoptimal\n\nReserve Factor\n\nStable Borrowing\n\nFlashloanable\n\nSiloed Borrowing\n\nBorrowable in Isolation\n\nE-Mode\n1\n1\n\nE-Mode Configurations\nwstETH Correlated #1\n\nParameter\nValue\nValue\n\nAsset\nwstETH\nWETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nMax LTV\n94.00%\n-\n\nLiquidation Threshold\n96.00%\n-\n\nLiquidation Bonus\n1.00%\n-\n\nCAPO\n\nAsset\nmaxYearlyRatioGrowthPercent\nratioReferenceTime\nMINIMUM_SNAPSHOT_DELAY\n\nwstETH\n9.68%\nMonthly\n7\n\nDisclaimer\nA statement of the author’s potential conflicts of interest, their relationship with the network or asset issuers, and whether they received compensation for publishing this proposal.\nNext Steps\n\nCommunity Engagement: Engage with the Aave community to gather feedback on the proposed framework for the new Aave Protocol deployment.\nARFC Snapshot: If community sentiment is favourable, initiate an ARFC snapshot to gauge official support for the framework.\nImplementation: If the Snapshot vote passes, the proposal as outlined shall be implemented by the respective Service Providers.\n\nCopyright\nCopyright and related rights waived under CC0.\n\nReferences\nAave Governance Process Document v1\n[ARFC] Aave Governance. Adjust Level 2 requirements (long-executor)\n[ARFC] Update the Asset Onboarding Framework\n[ARFC Addendum] Update Asset Onboarding Framework\n[ARFC] Technical Asset Listing Framework\n[ARFC] Direct-to-AIP Framework\n[ARFC] New Chain Deployment Framework\n[ARFC ADDENDUM] Mandatory Disclosures and Conflict-of-Interest Voting Norms\n[ARFC] Aave Risk Framework\n[ARFC] Emission Manager Framework Update\n[ARFC] Aave V3 Caps update Framework\nDisclosure\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is YAE, this proposal will be implemented.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n Update on Aave Horizon Asset Onboarding Process\n\n [ARFC] GHO Stewards Signer Update\n\n read \n\n 16\n min\n\n Pinned on Jul 20\n\n 17 days later\n\n post by Abel189 on Aug 7\n\n Abel189\n\n Thank you for the proposal.\nI support the objective of simplifying and consolidating the governance framework into a single reference document. As the DAO grows, having one canonical process should make governance easier to understand for both existing delegates and new participants.\nOne suggestion would be to periodically review the impact of these governance changes after implementation. In particular, it would be useful to monitor whether removing the mandatory TEMP CHECK affects proposal quality, community participation, delegate engagement, or the number of proposals requiring significant revisions during the ARFC stage. Publishing this information after several months would allow governance to evaluate whether the streamlined process is achieving its intended goals while preserving meaningful community review.\n\n post by Millesimillia on Aug 9\n\n Millesimillia\n\n Dear all,\nThank you for the proposal. I think it makes sense to review and improve governance processes every now and then. Simple question from me:\nWho can propose ARFCs for governance topics in the future?\nI read that in some cases (e.g., new listing) this must be done by official service providers. I hope this is not the case for all AFRCs.\nReason: I am an investor and looking forward to hearing more about how Aave token economics will effectively be kept strong or strengthened - especially vis-a-vis service providers who might also have more hidden incentives such as their own stock or revenues allocations.\nPotential future governance topics could include investment decisions, buybacks, provider selection criterias, service provider reviews, etc..\nKnowing that all topics can be brought forward and will be addressed on governance discussions would give me comfort/trust and be in the interests of Aave token holders.\nThanks for your thoughts and comments.\nWarm regards, Millesimillia\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Technical Asset Listing Framework\n\n General\n\n 7\n\n 1.5k\n\n Jul 17\n\n Aave Governance Process Document v1\n\n Governance\n\n 3\n\n 5.3k\n\n Sep 2024\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14","tokens":12098,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263668701,"hash":"f40b710f3366542729771ecb16c7ad463e5e5e09"}
{"url":"https://specs.optimism.io/protocol/lagoon/sdm.html","domain":"specs.optimism.io","title":"Sequencer-Defined Metering - OP Stack Specification","text":"Sequencer-Defined Metering\n\nTable of Contents\n\nOverview\nActivation\nPayload Schema (Version 1)\n\nSDMGasEntry\nValidity Rules\n\nTransaction Classification\nGas Refund Semantics\nCanonical Gas\nSettlement\n\nPer-Recipient Deltas\nApplication Rules\n\nProducer and Verifier\nReceipt Extension\nBackwards Compatibility\nSecurity Considerations\n\nOverview\nSequencer-Defined Metering (SDM) is the version-1 post-exec payload schema. It lets\nthe sequencer attach per-transaction gas refunds to a block. Each refund lowers the gas a transaction is charged\nfor and rebalances the fees it already paid.\nRefund data is carried by a post-exec transaction (0x7D) appended to the block as its final\ntransaction. The post-exec envelope and structural rules are specified in post-exec.md; this\ndocument specifies the version-1 payload and how clients apply the included refunds.\nActivation\nSDM activates with the Lagoon network upgrade and is gated by the Lagoon activation timestamp.\nWhen SDM is active for a block, the block MAY contain a post-exec transaction; when SDM is inactive, the block MUST\nNOT contain a post-exec transaction (see\npost-exec.md § Block-Level Structural Rules).\nBefore the Lagoon activation timestamp, every block MUST be produced and validated with SDM inactive, identically\nto a chain that has never specified SDM.\nPayload Schema (Version 1)\nWhen version = 1, the post-exec payload is RLP-encoded as:\n[version, blockNumber, gasRefundEntries]\n\nFieldTypeDescription\nversionuint8MUST be 1.\nblockNumberuint64The L2 block number containing this payload (see post-exec.md § Block Number).\ngasRefundEntrieslist<SDMGasEntry>Non-zero per-transaction gas refunds.\n\nSDMGasEntry\nEach entry in gasRefundEntries is an RLP list of two fields:\nFieldTypeDescription\nindexuint64Transaction index within the block (zero-based).\ngasRefunduint64Gas refund for the transaction at index.\n\nValidity Rules\nA version-1 payload is invalid if any of the following hold:\n\ngasRefundEntries is empty.\nAny SDMGasEntry has gasRefund == 0.\nEntries are not ordered by strictly increasing index.\nAny entry's index does not refer to a standard Ethereum transaction in the block.\n\nThe envelope-level rules in post-exec.md § Block-Level Structural Rules\napply in addition to the rules above. As long as SDM is the only active payload schema: if the sequencer assigns\nno gas refunds, the block has no post-exec transaction.\nTransaction Classification\nEvery transaction in the block is classified as exactly one of:\nKindSourceMay have refund?\nA standard Ethereum transaction.Yes\nDepositA deposited transaction (type 0x7E).No\nPostExecThe post-exec transaction (type 0x7D).No\n\nDeposits buy gas on L1 and have no L2-side gas-price to refund. The post-exec transaction carries SDM data only;\nit charges no fees, consumes no gas and is not executed as code.\nGas Refund Semantics\nFor each standard Ethereum transaction at index i, define refund(i) as:\n\nthe gasRefund value in the payload entry whose index == i, if one exists; otherwise\n0.\n\nThe refund value is sequencer-defined block data. Clients use the included value directly when executing and\nvalidating the block.\n\nRefund policy. Consensus applies refund(i) directly and does not define or re-derive the policy that produced\nit (beyond the validity rules and refund(i) <= evmGasUsed(i)). The version-1 policy is\nblock-level warming: it rebates the EIP-2929 cold→warm surcharge a transaction pays for re-touching state an\nearlier transaction in the block warmed. To be correct it must rebate only accesses actually charged the cold\nprice — never a transaction's own intrinsically-warm tx.sender, tx.to (or created-contract address),\nprecompiles, coinbase, access-list entries, or EIP-7702 authorities, nor protocol fee-vault settlement writes.\n\nCanonical Gas\nCanonical gas is the gas a standard Ethereum transaction is accounted for under SDM: the gas the EVM\nreports minus the SDM refund applied to it. It is the value written to receipts and summed into the block's\ncumulativeGasUsed and gasUsed, as distinct from evmGasUsed (the raw gas the EVM reports before any SDM\nadjustment). It is unrelated to the \"canonical chain\" sense of canonical used elsewhere in these specs.\nFor each standard Ethereum transaction at index i:\n\nevmGasUsed(i) is the gas used reported by the EVM after execution, before any SDM adjustment.\nrefund(i) MUST be less than or equal to evmGasUsed(i).\ncanonicalGasUsed(i) = evmGasUsed(i) - refund(i).\n\nThe receipt of transaction i reports canonicalGasUsed(i) as its gas-used field. The block's cumulativeGasUsed\nand gasUsed are computed using canonicalGasUsed for standard Ethereum transactions and evmGasUsed for Deposit\ntransactions. The post-exec transaction contributes zero gas (see post-exec.md § Receipt).\nSettlement\nBecause the EVM initially charges fees using evmGasUsed(i), SDM applies a balance settlement for every standard\nEthereum transaction with refund(i) > 0.\nPer-Recipient Deltas\nLet r = refund(i), p be the transaction's EIP-1559 effective gas price, b be the block's base fee, and let\noperatorFee(g) be the operator fee charged by the L1Block precompile for gas usage g at the active spec\n(post-Isthmus).\nRecipientAdjustmentAmount\nSender (tx.from)creditr * p + (operatorFee(evmGasUsed) - operatorFee(canonicalGasUsed))\nBlock beneficiarydebitr * (p - b)\nBase fee vaultdebitr * b\nOperator fee vault (post-Isthmus)debitoperatorFee(evmGasUsed) - operatorFee(canonicalGasUsed)\n\nThe sender credit equals the sum of the recipient debits: r * (p - b) + r * b = r * p. This identity relies on\np >= b, which holds for every transaction that can be included: an EIP-1559 transaction has\np = b + min(maxPriorityFeePerGas, maxFeePerGas - b) >= b, and a legacy transaction must have gasPrice >= b to\nbe included. Hence p - b >= 0, so the beneficiary debit is never negative; at the boundary p = b (e.g. a legacy\ntransaction whose gas price equals the base fee) the priority tip — and therefore the beneficiary debit — is zero.\nThe L1 fee vault is not adjusted: L1 cost is independent of L2 gas usage.\nApplication Rules\nSettlement is applied after the transaction's EVM frame finishes and before the transaction state delta is\ncommitted. It is atomic with the transaction and does not produce a separate receipt.\nIf any debit would underflow, the block is invalid. For any payload that respects refund(i) <= evmGasUsed(i),\nthis cannot occur, because each recipient was just paid the corresponding amount by the EVM in the same\ntransaction; an underflow therefore indicates a malformed or adversarial payload rather than a reachable state of\nhonest execution.\nProducer and Verifier\nUnder SDM:\n\nThe sequencer executes the block, chooses the non-zero gasRefundEntries, and appends a post-exec transaction if\nand only if the entry list is non-empty.\nA verifier enforces the post-exec envelope rules and the SDM validity rules, then applies the\nrefunds from the payload when computing canonical gas, settlement, receipts, and block gas usage.\n\nReceipt Extension\nThe post-exec transaction's own receipt carries no SDM-specific fields (see\npost-exec.md § Receipt).\nThe JSON-RPC receipts returned for standard Ethereum transactions are extended with a single additional field:\nFieldTypeDescription\nopGasRefundQuantity (uint64) or nullThe SDM gas refund credited to the transaction, or null when SDM was inactive for the block or the transaction had no refund.\n\nThe value is sourced from the embedded post-exec payload's gasRefundEntries for the transaction's index.\nopGasRefund is not part of the receipt's RLP encoding and is not committed to the receipts trie. Because it is\nan additional JSON-RPC field outside the consensus receipt, existing receipt tooling that ignores unknown fields\n(e.g. cast receipt) is unaffected; only consumers that opt in observe it.\nBackwards Compatibility\nBefore the Lagoon activation timestamp, blocks are produced and validated identically to a chain that has never\nspecified SDM: no post-exec transactions appear, no canonical-gas adjustment is performed, and no settlement runs.\nFrom the Lagoon activation timestamp, two changes become observable:\n\nA 0x7D transaction may appear at the end of any block produced after activation, exposed through the same\ntransaction-list interfaces used today.\nThe receipts of standard Ethereum transactions in such blocks gain the opGasRefund field; clients that ignore unknown\nfields are unaffected.\n\nMempool and transaction-pool interfaces are unchanged: post-exec transactions are not user-submittable and do not\npropagate over the public transaction-gossip protocol.\nSecurity Considerations\nSequencer-defined amounts. Refund amounts are part of the sequencer's block data. The only consensus-defined\nconstraints are on their encoding, their target transaction (standard Ethereum transactions only), and the application bounds\n(refund(i) <= evmGasUsed(i) and no settlement underflow); otherwise the sequencer has complete freedom to\nallocate refunds according to arbitrary policy.\nCross-block replay. The post-exec transaction's blockNumber field anchors each payload to its containing\nblock. A payload from one block re-injected into another fails the envelope blockNumber check.\nSettlement underflow. Any settlement debit underflow invalidates the block.","tokens":2314,"squid":"ink-governance","role":"Council Listener","at":1791263679983,"hash":"4c6bd96b9f1961be310fef6123b96e811a0dd51c"}
{"url":"https://api-reference.pyth.network/price-feeds/evm/updatePriceFeeds","domain":"api-reference.pyth.network","title":"Price Feeds | Pyth Network API Reference","text":"updatePriceFeedsUpdate the on-chain price feeds using the provided updateData.DescriptionThis method updates the on-chain price feeds using the provided updateData, which contains serialized and signed price update data from Pyth Network.\nYou can retrieve the latest price updateData for a given set of price feeds from the Hermes API.\nThis method updates the on-chain price if the provided update is more recent than the current on-chain price. Otherwise, the provided update will be ignored. The method call will succeed even if the update is ignored.\nThis function requires the caller to pay a fee to perform the update. The\nrequired fee for a given set of updates can be computed by passing them to\ngetUpdateFee.\nThis method returns the transaction hash of the update transaction.\nError Response\nThe above method can return the following error response:\n\nInvalidUpdateData: The provided update data is invalid or incorrectly signed.\nInsufficientFee: The fee provided is less than the required fee. Try calling getUpdateFee to get the required fee.\nArgumentsupdateData*The price update data for the contract to verify. Fetch this data from Hermes API.fee*The update fee in wei. This fee is sent as the value of the transaction.ExamplesNetworkimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n// Ethereum\naddress contractAddress = 0x4305FB66699C3B2702D4d05CF36551390A4c69C6\nIPyth pyth = IPyth(contractAddress);\n\nbytes[] memory updateData = new bytes[](1);\nupdateData[0] = /* <updateData> */;\nuint fee = /* <fee> */;\npyth.updatePriceFeeds{value: fee}(updateData);","tokens":406,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263697202,"hash":"0ae1bb947cf96018bac0e70f68df360c323dff27"}
{"url":"https://docs.soliditylang.org/en/develop/natspec-format.html","domain":"docs.soliditylang.org","title":"NatSpec Format — Solidity 0.8.38-develop documentation","text":"NatSpec Format\n\n Edit on GitHub\n\nNatSpec Format\nSolidity contracts can use a special form of comments to provide rich\ndocumentation for functions, return variables and more. This special form is\nnamed the Ethereum Natural Language Specification Format (NatSpec).\n\nNote\nNatSpec was inspired by Doxygen.\nWhile it uses Doxygen-style comments and tags, there is no intention to keep\nstrict compatibility with Doxygen. Please carefully examine the supported tags\nlisted below.\n\nThis documentation is segmented into developer-focused messages and end-user-facing\nmessages. These messages may be shown to the end user (the human) at the\ntime that they will interact with the contract (i.e. sign a transaction).\nIt is recommended that Solidity contracts are fully annotated using NatSpec for\nall public interfaces (everything in the ABI).\nNatSpec includes the formatting for comments that the smart contract author will\nuse, and which are understood by the Solidity compiler. Also detailed below is\noutput of the Solidity compiler, which extracts these comments into a machine-readable\nformat.\nNatSpec may also include annotations used by third-party tools. These are most likely\naccomplished via the @custom:<name> tag, and a good use case is analysis and verification\ntools.\n\nDocumentation Example\nDocumentation is inserted above each contract, interface, library,\nfunction, enum, enum value and event using the Doxygen notation format.\nA public state variable is equivalent to a function\nfor the purposes of NatSpec.\n\nFor Solidity you may choose /// for single or multi-line\ncomments, or /** and ending with */.\nFor Vyper, use \"\"\" indented to the inner contents with bare\ncomments. See the Vyper\ndocumentation.\n\nThe following example shows a contract and a function using all available tags.\n\nNote\nThe Solidity compiler only interprets tags if they are external or\npublic. You are welcome to use similar comments for your internal and\nprivate functions, but those will not be parsed.\nThis may change in the future.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.2 < 0.9.0;\n\n/// @title A simulator for trees\n/// @author Larry A. Gardner\n/// @notice You can use this contract for only the most basic simulation\n/// @dev All function calls are currently implemented without side effects\n/// @custom:experimental This is an experimental contract.\ncontract Tree {\n /// @notice Calculate tree age in years, rounded up, for live trees\n /// @dev The Alexandr N. Tetearing algorithm could increase precision\n /// @param rings The number of rings from dendrochronological sample\n /// @return Age in years, rounded up for partial years\n /// @return Name of the tree\n function age(uint256 rings) external virtual pure returns (uint256, string memory) {\n return (rings + 1, \"tree\");\n }\n\n /// @notice Returns the amount of leaves the tree has.\n /// @dev Returns only a fixed number.\n function leaves() external virtual pure returns(uint256) {\n return 2;\n }\n}\n\ncontract Plant {\n function leaves() external virtual pure returns(uint256) {\n return 3;\n }\n}\n\ncontract KumquatTree is Tree, Plant {\n function age(uint256 rings) external override pure returns (uint256, string memory) {\n return (rings + 2, \"Kumquat\");\n }\n\n /// Return the amount of leaves that this specific kind of tree has\n /// @inheritdoc Tree\n function leaves() external override(Tree, Plant) pure returns(uint256) {\n return 3;\n }\n}\n\nTags\nAll tags are optional. The following table explains the purpose of each\nNatSpec tag and where it may be used. As a special case, if no tags are\nused then the Solidity compiler will interpret a /// or /** comment\nin the same way as if it were tagged with @notice.\n\nTag\n\nContext\n\n@title\nA title that should describe the contract/interface\ncontract, library, interface, struct, enum, enum values\n\n@author\nThe name of the author\ncontract, library, interface, struct, enum, enum values\n\n@notice\nExplain to an end user what this does\ncontract, library, interface, function, public state variable, event, struct, enum, enum values error\n\n@dev\nExplain to a developer any extra details\ncontract, library, interface, function, state variable, event, struct, enum, enum values, error\n\n@param\nDocuments a parameter just like in Doxygen (must be followed by parameter name)\nfunction, event, enum values, error\n\n@return\nDocuments the return variables of a contract’s function\nfunction, enum, enum values, public state variable\n\n@inheritdoc\nCopies all missing tags from the base function (must be followed by the contract name)\nfunction, enum, enum values, public state variable\n\n@custom:...\nCustom tag, semantics is application-defined\neverywhere\n\nIf your function returns multiple values, like (int quotient, int remainder)\nthen use multiple @return statements in the same format as the @param statements.\nCustom tags start with @custom: and must be followed by one or more lowercase letters or hyphens.\nIt cannot start with a hyphen however. They can be used everywhere and are part of the developer documentation.\n\nDynamic expressions\nThe Solidity compiler will pass through NatSpec documentation from your Solidity\nsource code to the JSON output as described in this guide. The consumer of this\nJSON output, for example the end-user client software, may present this to the end-user directly or it may apply some pre-processing.\nFor example, some client software will render:\nopen in Remix\n/// @notice This function will multiply `a` by 7\n\nto the end-user as:\nThis function will multiply 10 by 7\n\nif a function is being called and the input a is assigned a value of 10.\n\nInheritance Notes\nFunctions without NatSpec will automatically inherit the documentation of their\nbase function. Exceptions to this are:\n\nWhen the parameter names are different.\nWhen there is more than one base function.\nWhen there is an explicit @inheritdoc tag which specifies which contract should be used to inherit.\n\nDocumentation Output\nWhen parsed by the compiler, documentation such as the one from the\nabove example will produce two different JSON files. One is meant to be\nconsumed by the end user as a notice when a function is executed and the\nother to be used by the developer.\nIf the above contract is saved as ex1.sol then you can generate the\ndocumentation using:\nsolc --userdoc --devdoc ex1.sol\n\nAnd the output is below.\n\nNote\nStarting Solidity version 0.6.11 the NatSpec output also contains a version and a kind field.\nCurrently the version is set to 1 and kind must be one of user or dev.\nIn the future it is possible that new versions will be introduced, deprecating older ones.\n\nUser Documentation\nThe above documentation will produce the following user documentation\nJSON file as output for the Tree contract:\n{\n \"version\" : 1,\n \"kind\" : \"user\",\n \"methods\" :\n {\n \"age(uint256)\" :\n {\n \"notice\" : \"Calculate tree age in years, rounded up, for live trees\"\n },\n \"leaves()\" :\n {\n \"notice\" : \"Returns the amount of leaves the tree has.\"\n }\n },\n \"notice\" : \"You can use this contract for only the most basic simulation\"\n}\n\nNote that the key by which to find the methods is the function’s\ncanonical signature as defined in the Contract\nABI and not simply the function’s\nname.\n\nDeveloper Documentation\nApart from the user documentation file, a developer documentation JSON\nfile should also be produced and should look like this:\n{\n \"version\" : 1,\n \"kind\" : \"dev\",\n \"author\" : \"Larry A. Gardner\",\n \"details\" : \"All function calls are currently implemented without side effects\",\n \"custom:experimental\" : \"This is an experimental contract.\",\n \"methods\" :\n {\n \"age(uint256)\" :\n {\n \"details\" : \"The Alexandr N. Tetearing algorithm could increase precision\",\n \"params\" :\n {\n \"rings\" : \"The number of rings from dendrochronological sample\"\n },\n \"returns\" : {\n \"_0\" : \"Age in years, rounded up for partial years\",\n \"_1\" : \"Name of the tree\"\n }\n },\n \"leaves()\" :\n {\n \"details\" : \"Returns only a fixed number.\"\n }\n },\n \"title\" : \"A simulator for trees\"\n}","tokens":1984,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263709520,"hash":"e8dd66dacb1ab4a69ebaac7fd2847bcb5ed87a54"}
{"url":"https://specs.optimism.io/interop/dependency-set.html","domain":"specs.optimism.io","title":"Dependency Set - OP Stack Specification","text":"The Dependency Set\n\nTable of Contents\n\nChain ID\nUpdating the Dependency Set\nSecurity Considerations\n\nDependency Set Size\n\nThe dependency set defines the set of chains that destination chains allow as source chains. Another way of\nsaying it is that the dependency set defines the set of initiating messages that are valid to be used\nas part of an executing message. An executing message MUST have an initiating message that is created by a chain\nin the dependency set.\nThe dependency set is defined by a set of chain ids. Since it is impossible to enforce uniqueness of chain ids,\nsocial consensus MUST be used to determine the chain that represents the canonical chain id. This\nparticularly impacts the block builder as they SHOULD use the chain id to assist in validation\nof executing messages.\nThe dependency set is configured on a per cluster basis. All chains that are in the dependency set\ncan accept initiating messages from any other chain in the dependency set, resulting in a mesh.\nThe chain id of the local chain MUST be considered as part of its own dependency set. This allows a chain\nto consume logs that it has produced much more cheaply than providing a block hash proof.\nChain ID\nAll chain IDs used in interop dependency sets must fit within a uint64.\nSoftware should be designed to support up to uint256 chain IDs.\nUpdating the Dependency Set\nThe dependency set is managed in the client software. Adding a chain to the dependency set is\nconsidered an upgrade to the network. It is not possible to remove chains from the dependency set.\nSecurity Considerations\nDependency Set Size\nIt becomes increasingly expensive to fully validate the full cluster as the size of the dependency\nset grows. The proof system requires validating all of the chains so the size of the dependency\nset is limited by the performance of the proof.","tokens":460,"squid":"ink-governance","role":"Council Listener","at":1791263709585,"hash":"ce3c8d86c24d36ea3d1a0441a5f3c828e0020a90"}
{"url":"https://specs.optimism.io/interop/sequencer.html","domain":"specs.optimism.io","title":"Sequencer - OP Stack Specification","text":"Sequencer\n\nTable of Contents\n\nOverview\nBlock Building\nSequencer Policy\n\nSafety Levels\n\nExecuting Message Validation\nTransitive Dependencies\n\nShared Sequencing\nSecurity Considerations\n\nDepending on Preconfirmations\n\nOverview\nNew validity rules are added to blocks that the sequencer must follow. If the\nnew rules are not followed, then the sequencer risks producing empty blocks\nand reorg'ing the chain.\nThe term \"block builder\" is used interchangeably with the term \"sequencer\" for the purposes of this document but\nthey need not be the same entity in practice.\nBlock Building\nIt is now required that a block builder fully executes a transaction and validates any executing messages\nthat it may produce before knowing that the transaction is valid. This adds a denial of service possibility\nfor the block builder. It is generally accepted that block builders can be sophisticated actors that can\nbuild solutions for this sort of problem.\nSequencer Policy\nSequencer policy represents the set of ways that a sequencer may act that are not constrained by consensus.\nThe ordering of transactions in a block is considered policy, consensus dictates that all of the transactions\nin a block are valid.\nOP Stack interop leverages sequencer policy to reduce synchrony assumptions between chains.\nIf the sequencer's view of a remote chain lags from the tip, it will not impact the overall liveness of\nthe network, it will only impact the liveness of inbound cross chain messages from that remote chain.\nIf there was a strict synchrony assumption, it could result in liveness or safety failures when any sequencer\nin the cluster falls behind the tip of any remote chain.\nSafety Levels\nThe sequencer MAY include an executing message with any level of confirmation safety.\nIncluding cross chain messages based on preconfirmation levels of security results\nin lower latency messaging at a higher risk of an invalid block being produced.\nThe sequencer MAY require different levels of security depending on the source chain.\nIf the block containing the initiating message is considered safe, no additional trust\nassumptions are assumed. The only time that additional trust assumptions are added is\nwhen an initiating message from an unsafe block is consumed.\nExecuting Message Validation\nThe block builder SHOULD validate executing messages directly before including the transaction\nthat produced the executing message in a block. Given the async nature of many independent chains\noperating in parallel, it is possible that the block builder does not have the most up to date\nview of all remote chains at any given moment.\nThe block builder MAY require cryptographic proof of the existence of the log\nthat the identifier points to, if it trusts the remote canonical chain but not its RPC server.\nThe block builder MAY also trust a remote RPC and use the following algorithm to verify the\nexistence of the log. This algorithm does not check for a particular finality level of the\nblock that includes the initiating message.\nsuccess, receipt = evm.apply_transaction(tx)\n\n# no logs are produced for reverting transactions\nif not success:\n return True\n\n# iterate over all of the logs\nfor log in receipt.logs:\n if is_executing_message(log):\n id = abi.decode(log.data)\n message_hash = log.topics[1]\n\n # maintain a RPC client for each remote node by chainid\n eth = clients[id.chainid]\n\n # cannot verify messages without a client, do not include it\n if eth is None:\n return False\n\n # use the identifier to fetch logs\n logs = eth.get_logs(id.origin, from=id.block_number, to=id.block_number)\n filtered = filter(lambda x: x.index == id.log_index && x.address == id.origin)\n # log does not exist, do not include it\n if len(filtered) != 1:\n return False\n\n # ensure the contents of the log are correct\n log = encode(filtered[0])\n if message_hash != keccak256(log):\n return False\n\n block = eth.get_block_by_number(id.blocknumber)\n\n # ensure that the timestamp is correct\n if id.timestamp != block.timestamp:\n return False\n\nreturn True\n\nTransitive Dependencies\nThe safety of a block is inherently tied to the safety of the blocks that include initiating messages\nconsumed. This applies recursively, so a block builder that wants to only include safe cross chain\nmessages will need to recursively check that all dependencies are safe.\nShared Sequencing\nA shared sequencer can be built if the block builder is able to build the next canonical block\nfor multiple chains. This can enable synchronous composability where transactions are able\nto execute across multiple chains at the same timestamp.\nSecurity Considerations\nDepending on Preconfirmations\nIf a local sequencer is accepting inbound cross chain transactions where the initiating message only has preconfirmation\nlevels of security, this means that the remote sequencer can trigger a reorg on the local chain.","tokens":1209,"squid":"ink-governance","role":"Council Listener","at":1791263732835,"hash":"3e4be5d6f0e2489379c370bf9c1acca6446f7174"}
{"url":"https://docs.soliditylang.org/en/develop/smtchecker.html","domain":"docs.soliditylang.org","title":"SMTChecker and Formal Verification — Solidity 0.8.38-develop documentation","text":"SMTChecker and Formal Verification\n\n Edit on GitHub\n\nSMTChecker and Formal Verification\nUsing formal verification it is possible to perform an automated mathematical\nproof that your source code fulfills a certain formal specification.\nThe specification is still formal (just as the source code), but usually much\nsimpler.\nNote that formal verification itself can only help you understand the\ndifference between what you did (the specification) and how you did it\n(the actual implementation). You still need to check whether the specification\nis what you wanted and that you did not miss any unintended effects of it.\nSolidity implements a formal verification approach based on\nSMT (Satisfiability Modulo Theories) and\nHorn solving.\nThe SMTChecker module automatically tries to prove that the code satisfies the\nspecification given by require and assert statements. That is, it considers\nrequire statements as assumptions and tries to prove that the conditions\ninside assert statements are always true. If an assertion failure is\nfound, a counterexample may be given to the user showing how the assertion can\nbe violated. If no warning is given by the SMTChecker for a property,\nit means that the property is safe.\nThe other verification targets that the SMTChecker checks at compile time are:\n\nArithmetic underflow and overflow.\nDivision by zero.\nTrivial conditions and unreachable code.\nPopping an empty array.\nOut of bounds index access.\nInsufficient funds for a transfer.\n\nAll the targets above are automatically checked by default if all engines are\nenabled, except underflow and overflow for Solidity >=0.8.7.\nThe potential warnings that the SMTChecker reports are:\n\n<failing  property> happens here.. This means that the SMTChecker proved that a certain property fails. A counterexample may be given, however in complex situations it may also not show a counterexample. This result may also be a false positive in certain cases, when the SMT encoding adds abstractions for Solidity code that is either hard or impossible to express.\n<failing property> might happen here. This means that the solver could not prove either case within the given timeout. Since the result is unknown, the SMTChecker reports the potential failure for soundness. This may be solved by increasing the query timeout, but the problem might also simply be too hard for the engine to solve.\n\nTo enable the SMTChecker, you must select which engine should run,\nwhere the default is no engine. Selecting the engine enables the SMTChecker on all files.\n\nNote\nPrior to Solidity 0.8.4, the default way to enable the SMTChecker was via\npragma experimental SMTChecker; and only the contracts containing the\npragma would be analyzed. That pragma has been deprecated, and although it\nstill enables the SMTChecker for backwards compatibility, it will be removed\nin Solidity 0.9.0. Note also that now using the pragma even in a single file\nenables the SMTChecker for all files.\n\nNote\nThe lack of warnings for a verification target represents an undisputed\nmathematical proof of correctness, assuming no bugs in the SMTChecker and\nthe underlying solver. Keep in mind that these problems are\nvery hard and sometimes impossible to solve automatically in the\ngeneral case. Therefore, several properties might not be solved or might\nlead to false positives for large contracts. Every proven property should\nbe seen as an important achievement. For advanced users, see SMTChecker Tuning\nto learn a few options that might help proving more complex\nproperties.\n\nTutorial\n\nOverflow\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Overflow {\n uint immutable x;\n uint immutable y;\n\n function add(uint x_, uint y_) internal pure returns (uint) {\n return x_ + y_;\n }\n\n constructor(uint x_, uint y_) {\n (x, y) = (x_, y_);\n }\n\n function stateAdd() public view returns (uint) {\n return add(x, y);\n }\n}\n\nThe contract above shows an overflow check example.\nThe SMTChecker does not check underflow and overflow by default for Solidity >=0.8.7,\nso we need to use the command-line option --model-checker-targets \"underflow,overflow\"\nor the JSON option settings.modelChecker.targets = [\"underflow\", \"overflow\"].\nSee this section for targets configuration.\nHere, it reports the following:\nWarning: CHC: Overflow (resulting value larger than 2**256 - 1) happens here.\nCounterexample:\nx = 1, y = 115792089237316195423570985008687907853269984665640564039457584007913129639935\n = 0\n\nTransaction trace:\nOverflow.constructor(1, 115792089237316195423570985008687907853269984665640564039457584007913129639935)\nState: x = 1, y = 115792089237316195423570985008687907853269984665640564039457584007913129639935\nOverflow.stateAdd()\n Overflow.add(1, 115792089237316195423570985008687907853269984665640564039457584007913129639935) -- internal call\n --> o.sol:9:20:\n |\n9 | return x_ + y_;\n | ^^^^^^^\n\nIf we add require statements that filter out overflow cases,\nthe SMTChecker proves that no overflow is reachable (by not reporting warnings):\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Overflow {\n uint immutable x;\n uint immutable y;\n\n function add(uint x_, uint y_) internal pure returns (uint) {\n return x_ + y_;\n }\n\n constructor(uint x_, uint y_) {\n (x, y) = (x_, y_);\n }\n\n function stateAdd() public view returns (uint) {\n require(x < type(uint128).max);\n require(y < type(uint128).max);\n return add(x, y);\n }\n}\n\nAssert\nAn assertion represents an invariant in your code: a property that must be true\nfor all transactions, including all input and storage values, otherwise there is a bug.\nThe code below defines a function f that guarantees no overflow.\nFunction inv defines the specification that f is monotonically increasing:\nfor every possible pair (a, b), if b > a then f(b) > f(a).\nSince f is indeed monotonically increasing, the SMTChecker proves that our\nproperty is correct. You are encouraged to play with the property and the function\ndefinition to see what results come out!\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Monotonic {\n function f(uint x) internal pure returns (uint) {\n require(x < type(uint128).max);\n return x * 42;\n }\n\n function inv(uint a, uint b) public pure {\n require(b > a);\n assert(f(b) > f(a));\n }\n}\n\nWe can also add assertions inside loops to verify more complicated properties.\nThe following code searches for the maximum element of an unrestricted array of\nnumbers, and asserts the property that the found element must be greater or\nequal every element in the array.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Max {\n function max(uint[] memory a) public pure returns (uint) {\n uint m = 0;\n for (uint i = 0; i < a.length; ++i)\n if (a[i] > m)\n m = a[i];\n\n for (uint i = 0; i < a.length; ++i)\n assert(m >= a[i]);\n\n return m;\n }\n}\n\nNote that in this example the SMTChecker will automatically try to prove three properties:\n\n++i in the first loop does not overflow.\n++i in the second loop does not overflow.\nThe assertion is always true.\n\nNote\nThe properties involve loops, which makes it much much harder than the previous\nexamples, so beware of loops!\n\nAll the properties are correctly proven safe. Feel free to change the\nproperties and/or add restrictions on the array to see different results.\nFor example, changing the code to\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Max {\n function max(uint[] memory a) public pure returns (uint) {\n require(a.length >= 5);\n uint m = 0;\n for (uint i = 0; i < a.length; ++i)\n if (a[i] > m)\n m = a[i];\n\n for (uint i = 0; i < a.length; ++i)\n assert(m > a[i]);\n\n return m;\n }\n}\n\ngives us:\nWarning: CHC: Assertion violation happens here.\nCounterexample:\n\na = [0, 0, 0, 0, 0]\n = 0\n\nTransaction trace:\nTest.constructor()\nTest.max([0, 0, 0, 0, 0])\n --> max.sol:14:4:\n |\n14 | assert(m > a[i]);\n\nState Properties\nSo far the examples only demonstrated the use of the SMTChecker over pure code,\nproving properties about specific operations or algorithms.\nA common type of properties in smart contracts are properties that involve the\nstate of the contract. Multiple transactions might be needed to make an assertion\nfail for such a property.\nAs an example, consider a 2D grid where both axis have coordinates in the range (-2^127, 2^127 - 1).\nLet us place a robot at position (0, 0). The robot can only move diagonally, one step at a time,\nand cannot move outside the grid. The robot’s state machine can be represented by the smart contract\nbelow.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Robot {\n int x = 0;\n int y = 0;\n\n modifier wall {\n require(x > type(int128).min && x < type(int128).max);\n require(y > type(int128).min && y < type(int128).max);\n _;\n }\n\n function moveLeftUp() wall public {\n --x;\n ++y;\n }\n\n function moveLeftDown() wall public {\n --x;\n --y;\n }\n\n function moveRightUp() wall public {\n ++x;\n ++y;\n }\n\n function moveRightDown() wall public {\n ++x;\n --y;\n }\n\n function inv() public view {\n assert((x + y) % 2 == 0);\n }\n}\n\nFunction inv represents an invariant of the state machine that x + y\nmust be even.\nThe SMTChecker manages to prove that regardless how many commands we give the\nrobot, even if infinitely many, the invariant can never fail. The interested\nreader may want to prove that fact manually as well. Hint: this invariant is\ninductive.\nWe can also trick the SMTChecker into giving us a path to a certain position we\nthink might be reachable. We can add the property that (2, 4) is not\nreachable, by adding the following function.\nopen in Remix\nfunction reach_2_4() public view {\n assert(!(x == 2 && y == 4));\n}\n\nThis property is false, and while proving that the property is false,\nthe SMTChecker tells us exactly how to reach (2, 4):\nWarning: CHC: Assertion violation happens here.\nCounterexample:\nx = 2, y = 4\n\nTransaction trace:\nRobot.constructor()\nState: x = 0, y = 0\nRobot.moveLeftUp()\nState: x = (- 1), y = 1\nRobot.moveRightUp()\nState: x = 0, y = 2\nRobot.moveRightUp()\nState: x = 1, y = 3\nRobot.moveRightUp()\nState: x = 2, y = 4\nRobot.reach_2_4()\n --> r.sol:35:4:\n |\n35 | assert(!(x == 2 && y == 4));\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^\n\nNote that the path above is not necessarily deterministic, as there are\nother paths that could reach (2, 4). The choice of which path is shown\nmight change depending on the used solver, its version, or just randomly.\n\nExternal Calls and Reentrancy\nEvery external call is treated as a call to unknown code by the SMTChecker.\nThe reasoning behind that is that even if the code of the called contract is\navailable at compile time, there is no guarantee that the deployed contract\nwill indeed be the same as the contract where the interface came from at\ncompile time.\nIn some cases, it is possible to automatically infer properties over state\nvariables that are still true even if the externally called code can do\nanything, including reenter the caller contract.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ninterface Unknown {\n function run() external;\n}\n\ncontract Mutex {\n uint x;\n bool lock;\n\n Unknown immutable unknown;\n\n constructor(Unknown u) {\n require(address(u) != address(0));\n unknown = u;\n }\n\n modifier mutex {\n require(!lock);\n lock = true;\n _;\n lock = false;\n }\n\n function set(uint x_) mutex public {\n x = x_;\n }\n\n function run() mutex public {\n uint xPre = x;\n unknown.run();\n assert(xPre == x);\n }\n}\n\nThe example above shows a contract that uses a mutex flag to forbid reentrancy.\nThe solver is able to infer that when unknown.run() is called, the contract\nis already “locked”, so it would not be possible to change the value of x,\nregardless of what the unknown called code does.\nIf we “forget” to use the mutex modifier on function set, the\nSMTChecker is able to synthesize the behavior of the externally called code so\nthat the assertion fails:\nWarning: CHC: Assertion violation happens here.\nCounterexample:\nx = 1, lock = true, unknown = 1\n\nTransaction trace:\nMutex.constructor(1)\nState: x = 0, lock = false, unknown = 1\nMutex.run()\n unknown.run() -- untrusted external call, synthesized as:\n Mutex.set(1) -- reentrant call\n --> m.sol:32:3:\n |\n32 | assert(xPre == x);\n | ^^^^^^^^^^^^^^^^^\n\nSMTChecker Options and Tuning\n\nTimeout\nThe SMTChecker uses a hardcoded resource limit (rlimit) chosen per solver,\nwhich is not precisely related to time. We chose the rlimit option as the default\nbecause it gives more determinism guarantees than time inside the solver.\nThis options translates roughly to “a few seconds timeout” per query. Of course many properties\nare very complex and need a lot of time to be solved, where determinism does not matter.\nIf the SMTChecker does not manage to solve the contract properties with the default rlimit,\na timeout can be given in milliseconds via the CLI option --model-checker-timeout <time> or\nthe JSON option settings.modelChecker.timeout=<time>, where 0 means no timeout.\n\nVerification Targets\nThe types of verification targets created by the SMTChecker can also be\ncustomized via the CLI option --model-checker-target <targets> or the JSON\noption settings.modelChecker.targets=<targets>.\nIn the CLI case, <targets> is a no-space-comma-separated list of one or\nmore verification targets, and an array of one or more targets as strings in\nthe JSON input.\nThe keywords that represent the targets are:\n\nAssertions: assert.\nArithmetic underflow: underflow.\nArithmetic overflow: overflow.\nDivision by zero: divByZero.\nTrivial conditions and unreachable code: constantCondition.\nPopping an empty array: popEmptyArray.\nOut of bounds array/fixed bytes index access: outOfBounds.\nInsufficient funds for a transfer: balance.\nAll of the above: default (CLI only).\n\nA common subset of targets might be, for example:\n--model-checker-targets assert,overflow.\nAll targets are checked by default, except underflow and overflow for Solidity >=0.8.7.\nThere is no precise heuristic on how and when to split verification targets,\nbut it can be useful especially when dealing with large contracts.\n\nProved Targets\nIf there are any proved targets, the SMTChecker issues one warning per engine stating\nhow many targets were proved. If the user wishes to see all the specific\nproved targets, the CLI option --model-checker-show-proved-safe and\nthe JSON option settings.modelChecker.showProvedSafe = true can be used.\n\nUnproved Targets\nIf there are any unproved targets, the SMTChecker issues one warning stating\nhow many unproved targets there are. If the user wishes to see all the specific\nunproved targets, the CLI option --model-checker-show-unproved and\nthe JSON option settings.modelChecker.showUnproved = true can be used.\n\nUnsupported Language Features\nCertain Solidity language features are not completely supported by the SMT\nencoding that the SMTChecker applies, for example assembly blocks.\nThe unsupported construct is abstracted via overapproximation to preserve\nsoundness, meaning any properties reported safe are safe even though this\nfeature is unsupported.\nHowever such abstraction may cause false positives when the target properties\ndepend on the precise behavior of the unsupported feature.\nIf the encoder encounters such cases it will by default report a generic warning\nstating how many unsupported features it has seen.\nIf the user wishes to see all the specific unsupported features, the CLI option\n--model-checker-show-unsupported and the JSON option\nsettings.modelChecker.showUnsupported = true can be used, where their default\nvalue is false.\n\nVerified Contracts\nBy default all the deployable contracts in the given sources are analyzed separately as\nthe one that will be deployed. This means that if a contract has many direct\nand indirect inheritance parents, all of them will be analyzed on their own,\neven though only the most derived will be accessed directly on the blockchain.\nThis causes an unnecessary burden on the SMTChecker and the solver. To aid\ncases like this, users can specify which contracts should be analyzed as the\ndeployed one. The parent contracts are of course still analyzed, but only in\nthe context of the most derived contract, reducing the complexity of the\nencoding and generated queries. Note that abstract contracts are by default\nnot analyzed as the most derived by the SMTChecker.\nThe chosen contracts can be given via a comma-separated list (whitespace is not\nallowed) of <source>:<contract> pairs in the CLI:\n--model-checker-contracts \"<source1.sol:contract1>,<source2.sol:contract2>,<source2.sol:contract3>\",\nand via the object settings.modelChecker.contracts in the JSON input,\nwhich has the following form:\n\"contracts\": {\n \"source1.sol\": [\"contract1\"],\n \"source2.sol\": [\"contract2\", \"contract3\"]\n}\n\nTrusted External Calls\nBy default, the SMTChecker does not assume that compile-time available code\nis the same as the runtime code for external calls. Take the following contracts\nas an example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Ext {\n uint public x;\n function setX(uint _x) public { x = _x; }\n}\ncontract MyContract {\n function callExt(Ext _e) public {\n _e.setX(42);\n assert(_e.x() == 42);\n }\n}\n\nWhen MyContract.callExt is called, an address is given as the argument.\nAt deployment time, we cannot know for sure that address _e actually\ncontains a deployment of contract Ext.\nTherefore, the SMTChecker will warn that the assertion above can be violated,\nwhich is true, if _e contains another contract than Ext.\nHowever, it can be useful to treat these external calls as trusted, for example,\nto test that different implementations of an interface conform to the same property.\nThis means assuming that address _e indeed was deployed as contract Ext.\nThis mode can be enabled via the CLI option --model-checker-ext-calls=trusted\nor the JSON field settings.modelChecker.extCalls: \"trusted\".\nPlease be aware that enabling this mode can make the SMTChecker analysis much more\ncomputationally costly.\nAn important part of this mode is that it is applied to contract types and high\nlevel external calls to contracts, and not low level calls such as call and\ndelegatecall. The storage of an address is stored per contract type, and\nthe SMTChecker assumes that an externally called contract has the type of the\ncaller expression. Therefore, casting an address or a contract to\ndifferent contract types will yield different storage values and can give\nunsound results if the assumptions are inconsistent, such as the example below:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract D {\n constructor(uint _x) { x = _x; }\n uint public x;\n function setX(uint _x) public { x = _x; }\n}\n\ncontract E {\n constructor() { x = 2; }\n uint public x;\n function setX(uint _x) public { x = _x; }\n}\n\ncontract C {\n function f() public {\n address d = address(new D(42));\n\n // `d` was deployed as `D`, so its `x` should be 42 now.\n assert(D(d).x() == 42); // should hold\n assert(D(d).x() == 43); // should fail\n\n // E and D have the same interface, so the following\n // call would also work at runtime.\n // However, the change to `E(d)` is not reflected in `D(d)`.\n E(d).setX(1024);\n\n // Reading from `D(d)` now will show old values.\n // The assertion below should fail at runtime,\n // but succeeds in this mode's analysis (unsound).\n assert(D(d).x() == 42);\n // The assertion below should succeed at runtime,\n // but fails in this mode's analysis (false positive).\n assert(D(d).x() == 1024);\n }\n}\n\nDue to the above, make sure that the trusted external calls to a certain\nvariable of address or contract type always have the same caller\nexpression type.\nIt is also helpful to cast the called contract’s variable as the type of the\nmost derived type in case of inheritance.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ninterface Token {\n function balanceOf(address _a) external view returns (uint);\n function transfer(address _to, uint _amt) external;\n}\n\ncontract TokenCorrect is Token {\n mapping (address => uint) balance;\n constructor(address _a, uint _b) {\n balance[_a] = _b;\n }\n function balanceOf(address _a) public view override returns (uint) {\n return balance[_a];\n }\n function transfer(address _to, uint _amt) public override {\n require(balance[msg.sender] >= _amt);\n balance[msg.sender] -= _amt;\n balance[_to] += _amt;\n }\n}\n\ncontract Test {\n function property_transfer(address _token, address _to, uint _amt) public {\n require(_to != address(this));\n\n TokenCorrect t = TokenCorrect(_token);\n\n uint xPre = t.balanceOf(address(this));\n require(xPre >= _amt);\n uint yPre = t.balanceOf(_to);\n\n t.transfer(_to, _amt);\n uint xPost = t.balanceOf(address(this));\n uint yPost = t.balanceOf(_to);\n\n assert(xPost == xPre - _amt);\n assert(yPost == yPre + _amt);\n }\n}\n\nNote that in function property_transfer, the external calls are\nperformed on variable t.\nAnother caveat of this mode are calls to state variables of contract type\noutside the analyzed contract. In the code below, even though B deploys\nA, it is also possible for the address stored in B.a to be called by\nanyone outside of B in between transactions to B itself. To reflect the\npossible changes to B.a, the encoding allows an unbounded number of calls\nto be made to B.a externally. The encoding will keep track of B.a’s\nstorage, therefore assertion (2) should hold. However, currently the encoding\nallows such calls to be made from B conceptually, therefore assertion (3)\nfails. Making the encoding stronger logically is an extension of the trusted\nmode and is under development. Note that the encoding does not keep track of\nstorage for address variables, therefore if B.a had type address\nthe encoding would assume that its storage does not change in between\ntransactions to B.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract A {\n uint public x;\n address immutable public owner;\n constructor() {\n owner = msg.sender;\n }\n function setX(uint _x) public {\n require(msg.sender == owner);\n x = _x;\n }\n}\n\ncontract B {\n A a;\n constructor() {\n a = new A();\n assert(a.x() == 0); // (1) should hold\n }\n function g() public view {\n assert(a.owner() == address(this)); // (2) should hold\n assert(a.x() == 0); // (3) should hold, but fails due to a false positive\n }\n}\n\nReported Inferred Inductive Invariants\nFor properties that were proved safe with the CHC engine,\nthe SMTChecker can retrieve inductive invariants that were inferred by the Horn\nsolver as part of the proof.\nCurrently only two types of invariants can be reported to the user:\n\nContract Invariants: these are properties over the contract’s state variables\nthat are true before and after every possible transaction that the contract may ever run. For example, x >= y, where x and y are a contract’s state variables.\nReentrancy Properties: they represent the behavior of the contract\nin the presence of external calls to unknown code. These properties can express a relation\nbetween the value of the state variables before and after the external call, where the external call is free to do anything, including making reentrant calls to the analyzed contract. Primed variables represent the state variables’ values after said external call. Example: lock -> x = x'.\n\nThe user can choose the type of invariants to be reported using the CLI option --model-checker-invariants \"contract,reentrancy\" or as an array in the field settings.modelChecker.invariants in the JSON input.\nBy default the SMTChecker does not report invariants.\n\nDivision and Modulo With Slack Variables\nSpacer, the default Horn solver used by the SMTChecker, often dislikes division\nand modulo operations inside Horn rules. Because of that, by default the\nSolidity division and modulo operations are encoded using the constraint\na = b * d + m where d = a / b and m = a % b.\nHowever, other solvers, such as Eldarica, prefer the syntactically precise operations.\nThe command-line flag --model-checker-div-mod-no-slacks and the JSON option\nsettings.modelChecker.divModNoSlacks can be used to toggle the encoding\ndepending on the used solver preferences.\n\nNatspec Function Abstraction\nCertain functions including common math methods such as pow\nand sqrt may be too complex to be analyzed in a fully automated way.\nThese functions can be annotated with Natspec tags that indicate to the\nSMTChecker that these functions should be abstracted. This means that the\nbody of the function is not used, and when called, the function will:\n\nReturn a nondeterministic value, and either keep the state variables unchanged if the abstracted function is view/pure, or also set the state variables to nondeterministic values otherwise. This can be used via the annotation /// @custom:smtchecker abstract-function-nondet.\nAct as an uninterpreted function. This means that the semantics of the function (given by the body) are ignored, and the only property this function has is that given the same input it guarantees the same output. This is currently under development and will be available via the annotation /// @custom:smtchecker abstract-function-uf.\n\nModel Checking Engines\nThe SMTChecker module implements two different reasoning engines, a Bounded\nModel Checker (BMC) and a system of Constrained Horn Clauses (CHC). Both\nengines are currently under development, and have different characteristics.\nThe engines are independent and every property warning states from which engine\nit came. Note that all the examples above with counterexamples were\nreported by CHC, the more powerful engine.\nBy default both engines are used, where CHC runs first, and every property that\nwas not proven is passed over to BMC. You can choose a specific engine via the CLI\noption --model-checker-engine {all,bmc,chc,none} or the JSON option\nsettings.modelChecker.engine={all,bmc,chc,none}.\n\nBounded Model Checker (BMC)\n\nWarning\nThe BMC engine has been deprecated and will be removed in a future release.\nSelecting it, either explicitly via bmc or implicitly via all, emits a deprecation warning.\nPlease use the CHC engine instead.\n\nThe BMC engine analyzes functions in isolation, that is, it does not take the\noverall behavior of the contract over multiple transactions into account when\nanalyzing each function. Loops are also ignored in this engine at the moment.\nInternal function calls are inlined as long as they are not recursive, directly\nor indirectly. External function calls are inlined if possible. Knowledge\nthat is potentially affected by reentrancy is erased.\nThe characteristics above make BMC prone to reporting false positives,\nbut it is also lightweight and should be able to quickly find small local bugs.\n\nConstrained Horn Clauses (CHC)\nA contract’s Control Flow Graph (CFG) is modelled as a system of\nHorn clauses, where the life cycle of the contract is represented by a loop\nthat can visit every public/external function non-deterministically. This way,\nthe behavior of the entire contract over an unbounded number of transactions\nis taken into account when analyzing any function. Loops are fully supported\nby this engine. Internal function calls are supported, and external function\ncalls assume the called code is unknown and can do anything.\nThe CHC engine is much more powerful than BMC in terms of what it can prove,\nand might require more computing resources.\n\nSMT and Horn solvers\nThe two engines detailed above use automated theorem provers as their logical\nbackends. BMC uses an SMT solver, whereas CHC uses a Horn solver. Often the\nsame tool can act as both, as seen in z3,\nwhich is primarily an SMT solver and makes Spacer available as a Horn solver, and Eldarica which does both.\nThe user can choose which solvers should be used, if available, via the CLI\noption --model-checker-solvers {all,cvc5,eld,smtlib2,z3} or the JSON option\nsettings.modelChecker.solvers=[smtlib2,z3], where:\n\ncvc5 is used via its binary which must be installed in the system. Only BMC uses cvc5.\neld is used via its binary which must be installed in the system. Only CHC uses eld, and only if z3 is not enabled.\nsmtlib2 outputs SMT/Horn queries in the smtlib2 format.\nThese can be used together with the compiler’s callback mechanism so that\nany solver binary from the system can be employed to synchronously return the results of the queries to the compiler.\nThis can be used by both BMC and CHC depending on which solvers are called.\nz3 is available statically in soljson.js (from Solidity 0.6.9), that is, the JavaScript binary of the compiler. Otherwise it is used via its binary which must be installed in the system.\n\nNote\nz3 version 4.8.16 broke ABI compatibility with previous versions and cannot\nbe used with solc <=0.8.13. If you are using z3 >=4.8.16 please use solc\n>=0.8.14, and conversely, only use older z3 with older solc releases.\nWe also recommend using the latest z3 release which is what SMTChecker also does.\n\nSince both BMC and CHC use z3, and z3 is available in a greater variety\nof environments, including in the browser, most users will almost never need to be\nconcerned about this option. More advanced users might apply this option to try\nalternative solvers on more complex problems.\nPlease note that certain combinations of chosen engine and solver will lead to\nthe SMTChecker doing nothing, for example choosing CHC and cvc5.\n\nAbstraction and False Positives\nThe SMTChecker implements abstractions in an incomplete and sound way: If a bug\nis reported, it might be a false positive introduced by abstractions (due to\nerasing knowledge or using a non-precise type). If it determines that a\nverification target is safe, it is indeed safe, that is, there are no false\nnegatives (unless there is a bug in the SMTChecker).\nIf a target cannot be proven you can try to help the solver by using the tuning\noptions in the previous section.\nIf you are sure of a false positive, adding require statements in the code\nwith more information may also give some more power to the solver.\n\nSMT Encoding and Types\nThe SMTChecker encoding tries to be as precise as possible, mapping Solidity types\nand expressions to their closest SMT-LIB\nrepresentation, as shown in the table below.\n\nSolidity type\nSMT sort\nTheories\n\nBoolean\nBool\nBool\n\nintN, uintN, address,\nbytesN, enum, contract\nInteger\nLIA, NIA\n\narray, mapping, bytes,\nstring\nTuple\n(Array elements, Integer length)\nDatatypes, Arrays, LIA\n\nstruct\nTuple\nDatatypes\n\nother types\nInteger\nLIA\n\nTypes that are not yet supported are abstracted by a single 256-bit unsigned\ninteger, where their unsupported operations are ignored.\nFor more details on how the SMT encoding works internally, see the paper\nSMT-based Verification of Solidity Smart Contracts.\n\nFunction Calls\nIn the BMC engine, function calls to the same contract (or base contracts) are\ninlined when possible, that is, when their implementation is available. Calls\nto functions in other contracts are not inlined even if their code is\navailable, since we cannot guarantee that the actual deployed code is the same.\nThe CHC engine creates nonlinear Horn clauses that use summaries of the called\nfunctions to support internal function calls. External function calls are treated\nas calls to unknown code, including potential reentrant calls.\nComplex pure functions are abstracted by an uninterpreted function (UF) over\nthe arguments.\n\nFunctions\nBMC/CHC behavior\n\nassert\nVerification target.\n\nrequire\nAssumption.\n\ninternal call\nBMC: Inline function call.\nCHC: Function summaries.\n\nexternal call to known code\nBMC: Inline function call or\nerase knowledge about state variables\nand local storage references.\nCHC: Assume called code is unknown.\nTry to infer invariants that hold\nafter the call returns.\n\nStorage array push/pop\nSupported precisely.\nChecks whether it is popping an\nempty array.\n\nABI functions\nAbstracted with UF.\n\naddmod, mulmod\nSupported precisely.\n\ngasleft, blobhash,\nblockhash, keccak256,\necrecover, ripemd160\nAbstracted with UF.\n\npure functions without\nimplementation (external or\ncomplex)\nAbstracted with UF\n\nexternal functions without\nimplementation\nBMC: Erase state knowledge and assume\nresult is nondeterministic.\nCHC: Nondeterministic summary.\nTry to infer invariants that hold\nafter the call returns.\n\ntransfer\nBMC: Checks whether the contract’s\nbalance is sufficient.\nCHC: does not yet perform the check.\n\nothers\nCurrently unsupported\n\nUsing abstraction means loss of precise knowledge, but in many cases it does\nnot mean loss of proving power.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Recover\n{\n function f(\n bytes32 hash,\n uint8 v1, uint8 v2,\n bytes32 r1, bytes32 r2,\n bytes32 s1, bytes32 s2\n ) public pure returns (address) {\n address a1 = ecrecover(hash, v1, r1, s1);\n require(v1 == v2);\n require(r1 == r2);\n require(s1 == s2);\n address a2 = ecrecover(hash, v2, r2, s2);\n assert(a1 == a2);\n return a1;\n }\n}\n\nIn the example above, the SMTChecker is not expressive enough to actually\ncompute ecrecover, but by modelling the function calls as uninterpreted\nfunctions we know that the return value is the same when called on equivalent\nparameters. This is enough to prove that the assertion above is always true.\nAbstracting a function call with an UF can be done for functions known to be\ndeterministic, and can be easily done for pure functions. It is however\ndifficult to do this with general external functions, since they might depend\non state variables.\n\nReference Types and Aliasing\nSolidity implements aliasing for reference types with the same data\nlocation.\nThat means one variable may be modified through a reference to the same data\narea.\nThe SMTChecker does not keep track of which references refer to the same data.\nThis implies that whenever a local reference or state variable of reference\ntype is assigned, all knowledge regarding variables of the same type and data\nlocation is erased.\nIf the type is nested, the knowledge removal also includes all the prefix base\ntypes.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0;\n\ncontract Aliasing\n{\n uint[] array1;\n uint[][] array2;\n function f(\n uint[] memory a,\n uint[] memory b,\n uint[][] memory c,\n uint[] storage d\n ) internal {\n array1[0] = 42;\n a[0] = 2;\n c[0][0] = 2;\n b[0] = 1;\n // Erasing knowledge about memory references should not\n // erase knowledge about state variables.\n assert(array1[0] == 42);\n // However, an assignment to a storage reference will erase\n // storage knowledge accordingly.\n d[0] = 2;\n // Fails as false positive because of the assignment above.\n assert(array1[0] == 42);\n // Fails because `a == b` is possible.\n assert(a[0] == 2);\n // Fails because `c[i] == b` is possible.\n assert(c[0][0] == 2);\n assert(d[0] == 2);\n assert(b[0] == 1);\n }\n function g(\n uint[] memory a,\n uint[] memory b,\n uint[][] memory c,\n uint x\n ) public {\n f(a, b, c, array2[x]);\n }\n}\n\nAfter the assignment to b[0], we need to clear knowledge about a since\nit has the same type (uint[]) and data location (memory). We also need to\nclear knowledge about c, since its base type is also a uint[] located\nin memory. This implies that some c[i] could refer to the same data as\nb or a.\nNotice that we do not clear knowledge about array and d because they\nare located in storage, even though they also have type uint[]. However,\nif d was assigned, we would need to clear knowledge about array and\nvice-versa.\n\nContract Balance\nA contract may be deployed with funds sent to it, if msg.value > 0 in the\ndeployment transaction.\nHowever, the contract’s address may already have funds before deployment,\nwhich are kept by the contract.\nTherefore, the SMTChecker assumes that address(this).balance >= msg.value\nin the constructor in order to be consistent with the EVM rules.\nThe contract’s balance may also increase without triggering any calls to the\ncontract, if\n\nselfdestruct is executed by another contract with the analyzed contract\nas the target of the remaining funds,\nthe contract is the coinbase (i.e., block.coinbase) of some block.\n\nTo model this properly, the SMTChecker assumes that at every new transaction\nthe contract’s balance may grow by at least msg.value.\n\nReal World Assumptions\nSome scenarios can be expressed in Solidity and the EVM, but are expected to\nnever occur in practice.\nOne of such cases is the length of a dynamic storage array overflowing during a\npush: If the push operation is applied to an array of length 2^256 - 1, its\nlength silently overflows.\nHowever, this is unlikely to happen in practice, since the operations required\nto grow the array to that point would take billions of years to execute.\nAnother similar assumption taken by the SMTChecker is that an address’ balance\ncan never overflow.\nA similar idea was presented in EIP-1985.","tokens":9175,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263732889,"hash":"9103e720d353e49d3e547449e28e0daa30e82eb6"}
{"url":"https://specs.optimism.io/protocol/lagoon/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Lagoon L2 Chain Derivation Changes\n\nTable of Contents\n\nSpan Batch Updates\n\nTransaction Data\nTransposed Envelope Fields\n\nzero_to_bits\nUnused signature and gas accounting slots\n\nReconstruction\nBatch Acceptance\n\nSpan Batch Updates\nSpan batches encode a span of consecutive L2 blocks for submission to the data\navailability layer.\nThe Lagoon network upgrade introduces the post-execution transaction, an\n[EIP-2718] typed transaction with type byte 0x7D. Unlike a deposited transaction, which is\nderived from L1 and is never present in batch data, a post-exec transaction is produced by the\nsequencer and travels to verifiers inside the L2 block body — through the L1 batch as well as the\nunsafe p2p payload. A span batch covering a block that contains a post-exec transaction therefore has to transpose\nthat transaction into the span batch txs structure like any other.\nA post-exec transaction is unlike every previously batched type: it carries only an opaque\npost-exec payload, with no nonce, gas limit, recipient or signature. Most of the slots the\nspan batch format reserves per transaction have no natural value for it. This section specifies all of them.\nNothing outside the txs structure changes. In particular, a post-exec transaction is an ordinary member of its\nblock's transaction list, so it is counted in that block's block_tx_counts entry and in the\nMAX_SPAN_BATCH_ELEMENT_COUNT total, exactly like a user transaction. Because a post-exec transaction is\nthe final transaction of its block, it occupies the last index of\nthat block's slice of the span.\nThe span batch format transposes and reconstructs a transaction list and has no notion of block validity,\nso it can faithfully encode a block that\nviolates the block-level structural rules — one carrying two 0x7D\ntransactions, say, or one where the 0x7D transaction is not last. Such a batch is well formed as a batch; the\nviolation is caught where the rules are stated, when the derived block is validated, and under\nSteady Block Derivation the invalid payload is then replaced by a\ndeposit-only one and the remaining span batch and its channel are dropped.\nA decoder MUST NOT reject a span batch on account of these rules, and that prohibition carries as much weight as\nthe rules themselves. The two paths do not converge. A block-validity failure produces a deposit-only block at that\nheight and then discards the rest of the span batch and its channel; a decode-time rejection produces no block at\nthat height at all, leaving it to be filled by a later batch. From the same L1 data they derive different chains,\nso a decoder that checked these rules early would diverge from one that left them alone.\nThis is the line the slot rules below sit on the other side of. A\nvalue that cannot reach the derived block is checked by nothing downstream, so the decoder MUST check it; a\nproperty of the block itself is already checked downstream, so the decoder MUST NOT.\nTransaction Data\nThis corresponds with a new encoding of the tx_datas list as specified in\nthe Delta span batch spec, adding a new transaction type:\nTransaction type 0x7D (post-exec): 0x7D ++ rlp_encoded_payload\nwhere rlp_encoded_payload is the RLP encoding of the post-exec payload as a list, exactly\nas defined by the transaction's EIP-2718 encoding. As for every other tx_datas\nelement, the bytes following the type byte MUST be a single RLP list.\nA decoder MUST NOT inspect the payload's\nversion byte or validate it against a schema while decoding a batch:\nbelow the outer RLP list the element is opaque bytes, reproduced verbatim into the reconstructed transaction.\nPayload validity is a block-level concern and is settled when the\nderived block is validated.\nFor every other transaction type the tx_datas element is a reduced encoding: fields the span batch format\nstores in dedicated slots (nonce, gasLimit, to, and the signature), along with the chain ID, which is\nrecovered from the rollup config rather than stored at all, are omitted from the element, and the remaining fields\nare re-encoded as a shorter RLP list. A post-exec transaction has none of those fields, so nothing is omitted and\nnothing is re-encoded: its tx_datas element is byte for byte the transaction's EIP-2718 encoding as it appears in\nthe block body.\nTransposed Envelope Fields\nA post-exec transaction has no envelope fields to transpose. Its slots in the span batch txs structure take the\nfollowing values:\nSlotValue for a 0x7D transaction\nzero_to_bits1\ntx_tosno entry — the transaction consumes none\ny_parity_bits0\ntx_sigsr = 0, s = 0\ntx_nonces0\ntx_gases0\nprotected_bitsno entry — the bitlist covers legacy transactions only\n\nzero_to_bits\nThe bit for a post-exec transaction MUST be 1: the transaction has no to field, so it consumes no entry from\ntx_tos.\nA decoder MUST reject the span batch if the bit is 0 for a post-exec transaction, exactly as it rejects one whose\ntx_datas element carries an unusable transaction type.\nUnused signature and gas accounting slots\ny_parity_bits, tx_sigs, tx_nonces and tx_gases are positional: every transaction in the span occupies one\nslot in each, whether or not the corresponding field exists. A post-exec transaction has no signature, nonce or gas\nlimit, so:\n\nA batcher MUST write zero into each of these slots for a post-exec transaction, as given in the table above.\nA decoder MUST verify that each of them is zero, and MUST reject the span batch if any of them is not.\n\nThe rejection is at span batch granularity: these slots are positional across the whole span, so a violation\ninvalidates the span batch rather than the single block whose transaction carries it. How far that invalidity\nthen propagates — whether the remaining channel is discarded with it — is a property of malformed span batches in\ngeneral, not something particular to post-exec transactions, and is not settled here.\nDecoding is deliberately no more permissive than encoding. The values in these slots cannot reach the reconstructed\ntransaction, so tolerating them would cost nothing in the short term — but it would make a span batch's encoding\nmalleable: the same sequence of L2 blocks would have unboundedly many valid encodings, differing in bytes that a\nbatcher chooses freely. tx_sigs alone reserves 64 bytes per transaction that no post-exec transaction uses. A\nstrict decoder keeps the encoding canonical, denies a batcher that space as a channel for arbitrary data, and\nleaves nothing that a later upgrade would have to tighten retroactively.\nThis strictness is available precisely because 0x7D is new. A block before the Lagoon activation timestamp\nMUST NOT contain a 0x7D transaction, so no batch already posted carries one, and no\nrule stated here reinterprets any of them.\nReconstruction\nWhen a span batch is decoded, the full transaction reconstructed for a post-exec element is its tx_datas element\nverbatim:\n0x7D ++ rlp_encoded_payload\n\nA decoder MUST NOT fold tx_nonces, tx_gases, tx_tos or tx_sigs into the reconstructed transaction; there\nare no fields for them to occupy. The tx_tos cursor is not advanced, because the transaction's zero_to_bits\nbit is 1.\nThe reconstructed bytes are therefore identical to the transaction's encoding in the block body. This is what makes\nthe overlap check between a batch and an already-safe block — comparing the batch's reconstructed transactions\nagainst the safe block's transactions — well defined for blocks containing a post-exec transaction: the comparison\nturns on the tx_datas element alone, and every other slot is both fixed by the rules above and discarded here.\nBatch Acceptance\nThis document specifies only how a post-exec transaction is encoded within a span batch, because that is the only\nbatch format for which the question arises. A singular batch needs no Lagoon\namendment: its transaction_list holds each transaction's EIP-2718 encoding verbatim, so a post-exec transaction\nappears there as 0x7D ++ rlp_encoded_payload like any other typed transaction, with nothing transposed and no\nslots to fill. Only the span batch format, which splits each transaction across per-field slots, needed the rules\nabove.\nWhether a batch is permitted to contain a post-exec transaction at all is a separate, batch-level question, and one\nthat applies to both batch formats. It is governed by the batch.transactions drop rules in\nBatch Queue.\nSingular batches with transactions of type 0x7D must only be accepted if Lagoon is active at the timestamp of the\nbatch. If a singular batch contains a transaction of type 0x7D before Lagoon is active, this batch must be dropped.\nThis check must happen at the level of individual batches that are derived from span batches, not to span batches as a\nwhole. In particular, it is allowed for a span batch to span the Lagoon activation timestamp and contain an 0x7D\ntransaction in singular batches that have a timestamp at or after the Lagoon activation time, even if the timestamp of\nthe span batch itself is before the Lagoon activation time.","tokens":2241,"squid":"ink-governance","role":"Council Listener","at":1791263754636,"hash":"d8aaa5e8bbc65d7f43e3974a64d52d18f1785b23"}
{"url":"https://dev-forum.pyth.network/t/ethglobal-qualifying-criteria-for-historic-prices/429/2","domain":"dev-forum.pyth.network","title":"EthGlobal qualifying criteria for Historic Prices - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n Oct 2025\n\n 2 / 17\n\n Oct 2025\n\n Oct 2025\n\n post by mcmoodoo on Oct 8, 2025\n\n mcmoodoo\n\nThese are Pyth’s offered track at the upcoming EthGlobalOnline hackathon: https://ethglobal.com/events/ethonline2025/prizes/pyth so, I am just trying to make sure that if I build my DAPP with historic prices, that it will qualify for the first track (as seen in the link) or:\n\nimage762×806 90 KB\n\n 9\n\n 7\n\n post by Aditya520 on Oct 8, 2025\n\n Aditya520\n\n Hi,\nIf you will parse historic Price on chain using either parsePriceFeedUpdates or parsePriceFeedUpdatesUnique, then you will be eligible for the bounty.\n\n post by mcmoodoo on Oct 8, 2025\n\n mcmoodoo\n\n Perfect! Is this confirmed? I just want to be absolutely sure to avoid building something that won’t meet the qualification requirements.\nThanks\n\n post by nidhi on Oct 9, 2025\n\n nidhi\n\n it is confirmed Looking forward to see your project.\n\n post by mcmoodoo on Oct 12, 2025\n\n mcmoodoo\n\n Perfect! Looking at the docs now. Both of these methods will provide historical prices in an interval (e.g. 60 prices for every second from epoch stamp 1760294000 to 1760294060) but none of those will ACTUALLY update the price on chain for that price feed, right?\nWhat if I need to have last 60 historical price values up to the very latest (now)?\nDo I need two seprate calls here? First to update the price on chain with pyth.updatePriceFeeds{ value: fee }(priceUpdate) and then parsePriceFeedUpdates(…) to get the historical price values I need?\nAm I thinking right here? Or is there some other way?\nThanks.\n\n post by Aditya520 on Oct 13, 2025\n\n Aditya520\n\n You don’t need to update the prices. But if you need 60 historical prices to be verified on-chain, you need parse them.\n\n post by mcmoodoo on Oct 18, 2025\n\n mcmoodoo\n\n So, I am using benchmarks API which returns:\n```\n[\n{\n“binary”: {\n“encoding”: “hex”,\n“data”: [\n“504e41550100000003b801000000040d00ff95abc1f273ea6c1f906c14d0f078478c931655a028d719e50c62665602103c3022d41f64e5ce8036de985a8e5a697ff3ac28a2d3f5f8416b5c98bbb3ec6af20102edc8773800259b65d49aa7f79c6c3a64ed117b0334eb80713fd65c1474540b29089a4e98b683d5ae8f38c1979855719b2eb8143dd4170c8573044c1d2c3553f5010337edd9e8a0388ab73f56ecb561e2d81b1ae05ce376643657662f7536e3a285424b2dc3fe5957f83c603f340c90a8c3de027cc4913cda4f8811a28a38aa6e7aa70104567a5865bfb72b03be69ca2cdd50f040f92c896e4f4a8dad598fc19e19d2272774b9ed7c23516e4beeeb10ba18adeb841d861b4274167aeb352e2d5f66b63f450006314f528e9cf8292a5315dc1b554be7a3aaacb9ff4a3a3f3d8f542c07bdec65a8398f058bafe7d56dcd22599b353523ac950437b2b0521f47977c8f694f38027f01084aca963b71b3d8d2d1f832ba60addd6e62cf87e13033a14dd5c6f31e96b817391df2ece3a9ddc7ad9877f4ddd0e198428296941dbb3713771f7b68d995bc5091010acda47312abef5212e26a35a29d807f36cf70c2fc664970615efe551f5698d6e0254d2af5b1140dcc25dd768882639b986efb92f8bab2a3e72de6a2a424f357a0000bfe8b251ec6d5075a769df696293fc3b6fca1244322057bfd47c9daa8e748259f0c471a3e79e6d57104b7961ba30e3bcce07a692d15506743d566ccbb91643df4010c17b13a3e8f7cdf07e0ac2039bf77425e7db71daae06a765d4d70e1ea4a1ab22008b865661cae0d4434e38f5eb6950b35359a12ab180608906b5f58414ac530d2000d2ae00a7f262cb046d333307e6a0cac3ff9d40dc1e1144bceb437f93d494a9c0c1a5b5e2acde0c170d0379d00321deff42b9274c49a4343365f6f261250c36a80010e54b6d35e5ee372f4d5951cbe32ca3c2d1d90593acc0f6f0d61fcdc8017f3424f5379d708620e2e23a822a2ca4606e30e2806765b6194f06a4587814d646ea8360010ac4ec95c12e083f92c223e21f2df3a1fb31bdf35b267b9fa722bcd071cbcfa5737a3df134bb43c3388290215507520351e6cfc1df4f1945a4a1cf7fd9496b11300118033b329471128b5e2529b3ac52794de67466049a47a4afd9bb3a64ee52139da0fd458e3a5a4774fd3966573e5ae3053310de3bb4dabe8dff8a76ed42b0f9bd90168f38f8300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c3014155575600000000000edf59c000002710a490de13f4cb4f7703810aa14bf839b23780ff5d02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5d3969810000000007533d0dfffffff80000000068f38f830000000068f38f820000005a60205bb0000000000798ad940dc2ec2928270934bf076c89ed9504f548b13855252d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea54a83b64e78bc1e8c5bbca36ba667c39164334066c22d5f219a44017266f3590d3652f33d7a6ab732d12a9d6481401ed8eb4d2cfbde6791180b539b2f766753f22e31d375bfd38ff07aa28068bb925b9c5fce7916269b4abfc1ebe91e7acf3b960eee2c92885338354bfb6edb17b8666ae54bb1962d5534c3698ba66c2216b4047602295543ae837620d8ad7e70eb642640e329f2be977d555674e2b186fb995d550b85bc498b41b87aa5f34e7a5164e4e3b4062d8eb0922a3c51b64e354c300bf1af2d7089d9db5005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5d3969810000000007533d0dfffffff80000000068f38f830000000068f38f820000005a60205bb0000000000798ad940dc2ec2928270934bf076c89ed9504f548b13855252d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea54a83b64e78bc1e8c5bbca36ba667c39164334066c22d5f219a44017266f3590d3652f33d7a6ab732d12a9d6481401ed8eb4d2cfbde6791180b539b2f766753f22e31d375bfd38ff07aa28068bb925b9c5fce7916269b4abfc1ebe91e7acf3b960eee2c92885338354bfb6edb17b8666ae54bb1962d5534c3698ba66c2216b4047602295543ae837620d8ad7e70eb642640e329f2be977d555674e2b186fb995d550b85bc498b41b87aa5f34e7a5164e4e3b4062d8eb0922a3c51b64e354c300bf1af2d7089d9db5”\n]\n},\n“parsed”: [\n{\n“id”: “ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”,\n“price”: {\n“conf”: “122895629”,\n“expo”: -8,\n“price”: “388111100289”,\n“publish_time”: 1760792451\n},\n“ema_price”: {\n“conf”: “127446420”,\n“expo”: -8,\n“price”: “388159790000”,\n“publish_time”: 1760792451\n},\n“metadata”: {\n“slot”: 249518528,\n“proof_available_time”: 1760792452,\n“prev_publish_time”: 1760792450\n}\n},\n{\n“id”: “ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”,\n“price”: {\n“conf”: “122895629”,\n“expo”: -8,\n“price”: “388111100289”,\n“publish_time”: 1760792451\n},\n“ema_price”: {\n“conf”: “127446420”,\n“expo”: -8,\n“price”: “388159790000”,\n“publish_time”: 1760792451\n},\n“metadata”: {\n“slot”: 249518528,\n“proof_available_time”: 1760792452,\n“prev_publish_time”: 1760792450\n}\n}\n]\n},\n{\n“binary”: {\n“encoding”: “hex”,\n“data”: [\n“504e41550100000003b801000000040d001428991f7d43fabb288a395b5dc4c03f51b6a476206337c168e1568bdce2579771dc7193a5aa1b5baafbf82b0d5f326018785a5f4d714f1eca9077c309b816e9010211958a44ab3db9a3410c6b0eb5b3ec4200cfc5e3da3016db9af214c02922f19b593ef46aa917c59ae22b65710c622b70b6b8e821d276fd91ed4d96471271ea580003378403000f25810d13420c58577ae1467a4fa9b2da5e0c44158c3cd5ce7bed7479d6f406205116d3b52fee330e4684d96b4b77b57dab9f32dbd43bf7e114eaa5000479802c4b17808d769f65e95e233b468a12c9117a32f70b7faa7cc301a1b185c671a5ae470e376c891a767bce89a33d18415e167740dfc100820ad7096ba54a3901067f4c6a350f4450c91ac72ef3e86f228a508a8c5bfbad63868ee003ee4083fabc22e762e457e2c743306f906c8e0cb4bb1bc70ece6c583aa4f0b5ce7ed2211596000851ed2d008eb92f11478623d866ef0be321e6851a904696c9061f23da06134efd57616fc291fb577da7548e03fe0a248bd96311f62c1b76f5c23ff62c2f005ef3000a5b1bea9172c3f22b1de93881c356845edba2344217626453b57a27707d051cd7040f8e6ff3319584a6c25050447727455996635666e11a281de2500118d0dc52010bef349eb8de625e641014b79a2cb766bed88ca02b1df6ca7c73e4cf9e67f7cbe8417c764cd84c132dc1d4cf7997159a06245378e62387a80de8324f9e58faff34010cd4917b8f68f037246367fd19db214cc187656ea2f765e88dd07729ea419e55bd0d5426a40b8fe9d27d5e178707cdba10259725e3b0c677b27f9be219b6170fb0010d8259fbef03dfbc1ac9a7b4fb085db0b4343583c202b699a1acb9eb5b4772a85c602d666d7af69091304ae95a8eca681811468c63876ea014e68700b1aae20b0e010f8e5645cd99bc2ad990097554b39b12a7262cdec7be29dc149e7bd20452b9a9520cec9ea1b2cce87986450d815798ff963e348fc78249196390fd9a253d6a16ba00108cba568e308e8b5e828fd3869452a01a57d330635a9b174e56023a6e959c79af3aef3868a857d1e0a45291fbc00aaab9b944430f498338fe016daae00728596101116e7b022947c1f864022fe6b73b89fcd984482eeda9e63aa1c7d0c6e9c999088d789b905c644ed7717aea85b3d6339629b7571a3d0fe6852a83976bff6445d09f0168f38f8400000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c6014155575600000000000edf59c3000027102d33c0a3a41ee75c7147583fe1857fc6df024f5f02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12”\n]\n},\n…\n```\nand my assumption is that I need to construct a bytes[] array of binary.data fields\nand pass it to:\nfunction parsePriceFeedUpdates( bytes[] calldata updateData, bytes32[] calldata priceIds, uint64 minPublishTime, uint64 maxPublishTime ) external payable returns (PythStructs.PriceFeed[] memory priceFeeds);\nBut I am getting:\n❯ cast 4byte 0xe69ffece\nInvalidUpdateData()\nSo, seems like it doesn’t like the format.\n\n post by mcmoodoo on Oct 20, 2025\n\n mcmoodoo\n\n just following up on my last message\n\n post by mcmoodoo on Oct 20, 2025\n\n mcmoodoo\n\n @Aditya520 @nidhi Could you please take a look sooner than later, because the hackathon submission is at the end of the week…\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\nHow are you constructing the bytes[ ] array?\nPlease DO NOT construct the bytes array manually. Please parse the update that you receive from the history api.\nSince you can only pass one timestamp in /v2/updates/price/{publish_time}, you have to parse updates one at a time for every timestamp.\nOn the other hand, you can parse multiple prices of same timestamp in one call.\nedit: added DO NOT\n\n post by mcmoodoo on Oct 21, 2025\n\n mcmoodoo\n\n I am parsing it manually. The above output comes from the history API. I then parse it to construct the bytes array out of individual binary.data fields.\nassuming the output from the history API is saved in historical_price_update.json , this is how I construct the bytes array:\n`\n string memory json = vm.readFile(\"cache/historical_price_update.json\");\n\n // Decode entire array\n PriceUpdate[] memory updates = abi.decode(vm.parseJson(json, \"\"), (PriceUpdate[]));\n console2.log(\"Number of updates:\", updates.length);\n\n // Flatten all binary.data entries into a bytes[] array\n bytes[] memory allUpdates = new bytes[](updates.length);\n for (uint256 i = 0; i < updates.length; i++) {\n allUpdates[i] = updates[i].binary.data[0];\n }\n`\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n I am extremely sorry for the wrong message above.\nPlease do not construct the bytes array manually\n\n post by mcmoodoo on Oct 21, 2025\n\n mcmoodoo\n\n If I don’t construct it manually, how else would I do it?\nI query the Benchmarks API:\n`\nBASE_URL = “https://benchmarks.pyth.network/v1/updates/price”\ntimestamp = int(time.time()) - 60\ninterval = 2\nprice_feed_id = “0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”\nurl = f\"{BASE_URL}/{timestamp}/{interval}\"\nparams = {“ids”: price_feed_id}\nresponse = requests.get(url, params=params)\n`\nand get back the exact json I posted above.\n@Aditya520\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n Yes this is correct.\nthis is not.\n// Flatten all binary.data entries into a bytes[] array \nbytes[] memory allUpdates = new bytes[](updates.length); \nfor (uint256 i = 0; i < updates.length; i++) { \nallUpdates[i] = updates[i].binary.data[0]; \n}\nYou can just send the update to parsePriceFeedUpdates\n\n post by mcmoodoo on Oct 21, 2025\n\n mcmoodoo\n\n I am soooo confused right now. You just said not to construct the bytes array manually.\nHow do I construct it then?\n@Aditya520\nCould you provide CONCRETE examples PLEASE\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n I apologize for the confusion.\nYou don’t need to construct the bytes array at all.\nYou fetch the bytes array using\nBASE_URL = “https://benchmarks.pyth.network/v1/updates/price{timestamp}”\nYou will receive an update.\n504e41550100000003b801000000040d001428991f7d43fabb288a395b5dc4c03f51b6a476206337c168e1568bdce2579771dc7193a5aa1b5baafbf82b0d5f326018785a5f4d714f1eca9077c309b816e9010211958a44ab3db9a3410c6b0eb5b3ec4200cfc5e3da3016db9af214c02922f19b593ef46aa917c59ae22b65710c622b70b6b8e821d276fd91ed4d96471271ea580003378403000f25810d13420c58577ae1467a4fa9b2da5e0c44158c3cd5ce7bed7479d6f406205116d3b52fee330e4684d96b4b77b57dab9f32dbd43bf7e114eaa5000479802c4b17808d769f65e95e233b468a12c9117a32f70b7faa7cc301a1b185c671a5ae470e376c891a767bce89a33d18415e167740dfc100820ad7096ba54a3901067f4c6a350f4450c91ac72ef3e86f228a508a8c5bfbad63868ee003ee4083fabc22e762e457e2c743306f906c8e0cb4bb1bc70ece6c583aa4f0b5ce7ed2211596000851ed2d008eb92f11478623d866ef0be321e6851a904696c9061f23da06134efd57616fc291fb577da7548e03fe0a248bd96311f62c1b76f5c23ff62c2f005ef3000a5b1bea9172c3f22b1de93881c356845edba2344217626453b57a27707d051cd7040f8e6ff3319584a6c25050447727455996635666e11a281de2500118d0dc52010bef349eb8de625e641014b79a2cb766bed88ca02b1df6ca7c73e4cf9e67f7cbe8417c764cd84c132dc1d4cf7997159a06245378e62387a80de8324f9e58faff34010cd4917b8f68f037246367fd19db214cc187656ea2f765e88dd07729ea419e55bd0d5426a40b8fe9d27d5e178707cdba10259725e3b0c677b27f9be219b6170fb0010d8259fbef03dfbc1ac9a7b4fb085db0b4343583c202b699a1acb9eb5b4772a85c602d666d7af69091304ae95a8eca681811468c63876ea014e68700b1aae20b0e010f8e5645cd99bc2ad990097554b39b12a7262cdec7be29dc149e7bd20452b9a9520cec9ea1b2cce87986450d815798ff963e348fc78249196390fd9a253d6a16ba00108cba568e308e8b5e828fd3869452a01a57d330635a9b174e56023a6e959c79af3aef3868a857d1e0a45291fbc00aaab9b944430f498338fe016daae00728596101116e7b022947c1f864022fe6b73b89fcd984482eeda9e63aa1c7d0c6e9c999088d789b905c644ed7717aea85b3d6339629b7571a3d0fe6852a83976bff6445d09f0168f38f8400000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c6014155575600000000000edf59c3000027102d33c0a3a41ee75c7147583fe1857fc6df024f5f02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12\nAppend 0x to the bytes, and send it to parsePriceFeedUpdates.\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n You can message me on my tg here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n Byte by byte breakdown of Hex encoded data received in latest price update API\n\n Price Feeds\n\n evm\n\n 5\n\n 717\n\n Jun 2025\n\n Powered by Discourse","tokens":5102,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263777717,"hash":"f131f3ffaedd7abcc236f56df5282fd039866ab6"}
{"url":"https://docs.arbitrum.io/build-decentralized-apps/quickstart-create-a-token","domain":"docs.arbitrum.io","title":"Create a token using Foundry (Quickstart) | Arbitrum Docs","text":"✏️Request an updateDeploying an ERC-20 token on Arbitrum One is fully permissionless and uses the same tooling and workflows as Ethereum.\nYou can deploy directly to Arbitrum One using Foundry, and optionally configure bridging, liquidity, and supporting smart contract infrastructure as part of your token creation.\nThis guide walks you through deploying a standard ERC-20 token on Arbitrum One, from local setup to testnet and mainnet deployment.\nPrerequisites​\n\nInstall Foundry:\ncurl -L https://foundry.paradigm.xyz | bashfoundryup```bashcurl -L https://foundry.paradigm.xyz | bashfoundryup\n\n**Get test ETH**: Obtain Arbitrum Sepolia **ETH** from a faucet like Alchemy's Arbitrum Sepolia Faucet, Chainlink's faucet, or QuickNode's faucet. You'll need to connect a wallet (for example, MetaMask) configured for Arbitrum Sepolia and request testnet funds.\n\nResourcesA list of faucets is available on the Chain Info page.Faucets may require certain actions, for example, bridging, use the official Arbitrum Bridge if the faucet requires it.All references to ETH on this document refers to test ETH on Sepolia.\n\nSet up development environment: Configure your wallet and tools for Arbitrum testnet deployment. Sign up for an Etherscan account to get an API key for contract verification.\n\nProject setup​\n\nInitialize Foundry Project:\n# Create new projectforge init my-token-projectcd my-token-project# Remove extra filesrm src/Counter.sol script/Counter.s.sol test/Counter.t.sol\n\nInstall OpenZeppelin Contracts:\n# Install OpenZeppelin contracts libraryforge install OpenZeppelin/openzeppelin-contracts\n\nSmart contract development​\nCreate src/MyToken.sol (this is a standard ERC-20 contract and works on any EVM chain like Arbitrum):\n// SPDX-License-Identifier: MITpragma solidity ^0.8.19;import \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";import \"@openzeppelin/contracts/access/Ownable.sol\";contract MyToken is ERC20, Ownable { // Max number of tokens that will exist uint256 public constant MAX_SUPPLY = 1_000_000_000 * 10**18; constructor( string memory name, string memory symbol, uint256 initialSupply, address initialOwner ) ERC20(name, symbol) Ownable(initialOwner) { require(initialSupply <= MAX_SUPPLY, \"Initial supply exceeds max supply\"); // Mints the initial supply to the contract deployer _mint(initialOwner, initialSupply); } function mint(address to, uint256 amount) public onlyOwner { require(totalSupply() + amount <= MAX_SUPPLY, \"Minting would exceed max supply\"); _mint(to, amount); } function burn(uint256 amount) public { _burn(msg.sender, amount); }}\nDeployment script​\nCreate script/DeployToken.s.sol:\n// SPDX-License-Identifier: MITpragma solidity ^0.8.19;import {Script, console} from \"forge-std/Script.sol\";import {MyToken} from \"../src/MyToken.sol\";contract DeployToken is Script { function run() external { // Load contract deployer's private key from environment variables uint256 deployerPrivateKey = vm.envUint(\"PRIVATE_KEY\"); address deployerAddress = vm.addr(deployerPrivateKey); // Token configuration parameters string memory name = \"My Token\"; string memory symbol = \"MTK\"; uint256 initialSupply = 100_000_000 * 10**18; // Initiates broadcasting transactions vm.startBroadcast(deployerPrivateKey); // Deploys the token contract MyToken token = new MyToken(name, symbol, initialSupply, deployerAddress); // Stops broadcasting transactions vm.stopBroadcast(); // Logs deployment information console.log(\"Token deployed to:\", address(token)); console.log(\"Token name:\", token.name()); console.log(\"Token symbol:\", token.symbol()); console.log(\"Initial supply:\", token.totalSupply()); console.log(\"Deployer balance:\", token.balanceOf(deployerAddress)); }}\nEnvironment configuration​\n\nCreate .env file:\nPRIVATE_KEY=your_private_key_hereARBITRUM_SEPOLIA_RPC_URL=https://sepolia.arbitrum.io/rpcARBITRUM_ONE_RPC_URL=https://arb1.arbitrum.io/rpcARBISCAN_API_KEY=your_arbiscan_api_key_here\n\nResourcesA list of RPCs, and chain IDs are available on the Chain Info page.\n\nUpdate foundry.toml (add chain IDs for verification, as Arbiscan requires them for non-Ethereum chains):\n[profile.default]src = \"src\"out = \"out\"libs = [\"lib\"]remappings = [\"@openzeppelin/=lib/openzeppelin-contracts/\"][rpc_endpoints]arbitrum_sepolia = \"${ARBITRUM_SEPOLIA_RPC_URL}\"arbitrum_one = \"${ARBITRUM_ONE_RPC_URL}\"[etherscan]arbitrum_sepolia = { key = \"${ARBISCAN_API_KEY}\", url = \"https://api-sepolia.arbiscan.io/api\", chain = 421614 }arbitrum_one = { key = \"${ARBISCAN_API_KEY}\", url = \"https://api.arbiscan.io/api\", chain = 42161 }\n\nResourcesA list of chain IDs is available on the Chain Info page.\nTesting​\n\nCreate test/MyToken.t.sol\n// SPDX-License-Identifier: MITpragma solidity ^0.8.19;import {Test, console} from \"forge-std/Test.sol\";import {MyToken} from \"../src/MyToken.sol\";contract MyTokenTest is Test { MyToken public token; address public owner = address(0x1); address public user = address(0x2); uint256 constant INITIAL_SUPPLY = 100_000_000 * 10**18; function setUp() public { // Deploy token contract before each test vm.prank(owner); token = new MyToken(\"Test Token\", \"TEST\", INITIAL_SUPPLY, owner); } function testInitialState() public { // Verify the token was deployed with the correct parameters assertEq(token.name(), \"Test Token\"); assertEq(token.symbol(), \"TEST\"); assertEq(token.totalSupply(), INITIAL_SUPPLY); assertEq(token.balanceOf(owner), INITIAL_SUPPLY); } function testMinting() public { uint256 mintAmount = 1000 * 10**18; // Only the owner should be able to mint vm.prank(owner); token.mint(user, mintAmount); assertEq(token.balanceOf(user), mintAmount); assertEq(token.totalSupply(), INITIAL_SUPPLY + mintAmount); } function testBurning() public { uint256 burnAmount = 1000 * 10**18; // Owner burns their tokens vm.prank(owner); token.burn(burnAmount); assertEq(token.balanceOf(owner), INITIAL_SUPPLY - burnAmount); assertEq(token.totalSupply(), INITIAL_SUPPLY - burnAmount); } function testFailMintExceedsMaxSupply() public { // This test should fail when attempting to mint more than the max supply uint256 excessiveAmount = token.MAX_SUPPLY() + 1; vm.prank(owner); token.mint(user, excessiveAmount); } function testFailUnauthorizedMinting() public { // This test should fail when a non-owner tries to mint tokens vm.prank(user); token.mint(user, 1000 * 10**18); }}\n\nRun tests:\n# Runs all tests with verbose outputforge test -vv```bash# Runs all tests with verbose outputforge test -vv\n\nDeployment and verification​\n\nDeploy to Arbitrum Sepolia (testnet):\n# Load environment variablessource .env# Deploy to Arbitrum Sepolia with automatic verificationforge script script/DeployToken.s.sol:DeployToken \\ --rpc-url arbitrum_sepolia \\ --broadcast \\ --verify\n\nUses https://sepolia.arbitrum.io/rpc (RPC URL).\nChain ID: 421614.\nVerifies on Sepolia Arbiscan.\n\nDeploy to Arbitrum One (mainnet):\n\nReplace arbitrum_sepolia with arbitrum_one in the command.\nUses https://arb1.arbitrum.io/rpc (RPC URL).\nChain ID: 42161.\nVerifies on Arbiscan.\nRequires sufficient ETH on Arbitrum One for gas fees (bridge from Ethereum mainnet if needed).\n\nExample of verifying on Arbiscan:\nforge verify-contract <contract_address> <contract_path>:YourToken \\ --verifier etherscan \\ --chain-id 42161 \\ --num-of-optimizations 200\n\nArbitrum-specific configurations​\n\nRPC URLs:\n\nArbitrum Sepolia: https://sepolia.arbitrum.io/rpc\nArbitrum One: https://arb1.arbitrum.io/rpc\n\nChain IDs: Arbitrum Sepolia: 421614; Arbitrum One: 42161.\nContract Addresses: Logged in console output after deployment (e.g., console.log(\"Token deployed to:\", address(token));).\nVerification: Uses Arbiscan API with your API key. The --verify flag enables automatic verification.\n\nImportant notes​\n\nAlways conduct security audits (e.g., via tools like Slither or other professional reviews) before mainnet deployment, as token contracts handle value.\nEnsure your wallet has enough ETH for gas on the target network. Arbitrum fees are low, but mainnet deployments still cost real ETH. See How to estimate gas to size your deployment funds.\nIf you encounter verification issues, double-check your Arbiscan API key and foundry.toml configs. For more advanced deployments, refer to general Foundry deployment docs or Arbitrum developer resources.\n\nBridging considerations​\nTwo deployment paths are possible:\n\nNative deployment\n\nToken is deployed directly on Arbitrum One\nUse cases: Token Generation Event (TGE), liquidity bootstrapping, airdrops, and L2-native user flows.\n\nDeployment on Ethereum and bridging to Arbitrum One\n\nUse the Arbitrum Token Bridge to create an L2 counterpart. For a programmatic setup, see the token bridging guides.\n\nPost-deployment considerations​\nAfter deploying a token contract on Arbitrum, you can complete additional setup steps depending on your project's needs. These may include:\n\nVerifying the contract on Arbiscan to improve transparency and readability\nCreating liquidity pools on Arbitrum-based DEXs\nPublishing token metadata to relevant indexing or aggregation services\nEnsuring wallet compatibility by submitting basic token information\nConfiguring operational security components such as multisigs or timelocks\nConnecting to market infrastructure providers where applicable\nSetting up monitoring or observability tools for contract activity\nPrerequisitesProject setupSmart contract developmentDeployment scriptEnvironment configurationTestingDeployment and verificationArbitrum-specific configurationsImportant notesBridging considerationsPost-deployment considerations","tokens":2372,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263779665,"hash":"87acf0762ef5cc45d9d805f9a1818592a395cc4f"}
{"url":"https://docs.soliditylang.org/en/develop/yul.html","domain":"docs.soliditylang.org","title":"Yul — Solidity 0.8.38-develop documentation","text":"Yul\n\n Edit on GitHub\n\nYul\nYul (previously also called JULIA or IULIA) is an intermediate language that can be\ncompiled to bytecode for different backends.\nIt can be used in stand-alone mode and for “inline assembly” inside Solidity.\nThe compiler uses Yul as an intermediate language in the IR-based code generator (“new codegen” or “IR-based codegen”).\nYul is a good target for high-level optimisation stages that can benefit all target platforms equally.\n\nMotivation and High-level Description\nThe design of Yul tries to achieve several goals:\n\nPrograms written in Yul should be readable, even if the code is generated by a compiler from Solidity or another high-level language.\nControl flow should be easy to understand to help in manual inspection, formal verification and optimization.\nThe translation from Yul to bytecode should be as straightforward as possible.\nYul should be suitable for whole-program optimization.\n\nIn order to achieve the first and second goal, Yul provides high-level constructs\nlike for loops, if and switch statements and function calls. These should\nbe sufficient for adequately representing the control flow for assembly programs.\nTherefore, no explicit statements for SWAP, DUP, JUMPDEST, JUMP and JUMPI\nare provided, because the first two obfuscate the data flow\nand the last two obfuscate control flow. Furthermore, functional statements of\nthe form mul(add(x, y), 7) are preferred over pure opcode statements like\n7 y x add mul because in the first form, it is much easier to see which\noperand is used for which opcode.\nEven though it was designed for stack machines, Yul does not expose the complexity of the stack itself.\nThe programmer or auditor should not have to worry about the stack.\nThe third goal is achieved by compiling the\nhigher level constructs to bytecode in a very regular way.\nThe only non-local operation performed\nby the assembler is name lookup of user-defined identifiers (functions, variables, …)\nand cleanup of local variables from the stack.\nTo avoid confusions between concepts like values and references,\nYul is statically typed. At the same time, there is a default type\n(usually the integer word of the target machine) that can always\nbe omitted to help readability.\nTo keep the language simple and flexible, Yul does not have\nany built-in operations, functions or types in its pure form.\nThese are added together with their semantics when specifying a dialect of Yul,\nwhich allows specializing Yul to the requirements of different\ntarget platforms and feature sets.\nCurrently, there is only one specified dialect of Yul. This dialect uses\nthe EVM opcodes as builtin functions\n(see below) and defines only the type u256, which is the native 256-bit\ntype of the EVM. Because of that, we will not provide types in the examples below.\n\nSimple Example\nThe following example program is written in the EVM dialect and computes exponentiation.\nIt can be compiled using solc --strict-assembly. The builtin functions\nmul and div compute product and division, respectively.\nopen in Remix\n{\n function power(base, exponent) -> result\n {\n switch exponent\n case 0 { result := 1 }\n case 1 { result := base }\n default\n {\n result := power(mul(base, base), div(exponent, 2))\n switch mod(exponent, 2)\n case 1 { result := mul(base, result) }\n }\n }\n}\n\nIt is also possible to implement the same function using a for-loop\ninstead of with recursion. Here, lt(a, b) computes whether a is less than b.\nopen in Remix\n{\n function power(base, exponent) -> result\n {\n result := 1\n for { let i := 0 } lt(i, exponent) { i := add(i, 1) }\n {\n result := mul(result, base)\n }\n }\n}\n\nAt the end of the section, a complete implementation of\nthe ERC-20 standard can be found.\n\nStand-Alone Usage\nYou can use Yul in its stand-alone form in the EVM dialect using the Solidity compiler.\nThis will use the Yul object notation so that it is possible to refer\nto code as data to deploy contracts. This Yul mode is available for the commandline compiler\n(use --strict-assembly) and for the standard-json interface:\n{\n \"language\": \"Yul\",\n \"sources\": { \"input.yul\": { \"content\": \"{ sstore(0, 1) }\" } },\n \"settings\": {\n \"outputSelection\": { \"*\": { \"*\": [\"*\"], \"\": [ \"*\" ] } },\n \"optimizer\": { \"enabled\": true, \"details\": { \"yul\": true } }\n }\n}\n\nWarning\nYul is in active development and bytecode generation is only fully implemented for the EVM dialect of Yul\nwith EVM 1.0 as target.\n\nInformal Description of Yul\nIn the following, we will talk about each individual aspect\nof the Yul language. In examples, we will use the default EVM dialect.\n\nSyntax\nYul parses comments, literals and identifiers in the same way as Solidity,\nso you can e.g. use // and /* */ to denote comments.\nThere is one exception: Identifiers in Yul can contain dots: ..\nYul can specify “objects” that consist of code, data and sub-objects.\nPlease see Yul Objects below for details on that.\nIn this section, we are only concerned with the code part of such an object.\nThis code part always consists of a curly-braces\ndelimited block. Most tools support specifying just a code block\nwhere an object is expected.\nInside a code block, the following elements can be used\n(see the later sections for more details):\n\nliterals, e.g. 0x123, 42 or \"abc\" (strings up to 32 characters)\ncalls to builtin functions, e.g. add(1, mload(0))\nvariable declarations, e.g. let x := 7, let x := add(y, 3) or let x (initial value of 0 is assigned)\nidentifiers (variables), e.g. add(3, x)\nassignments, e.g. x := add(y, 3)\nblocks where local variables are scoped inside, e.g. { let x := 3 { let y := add(x, 1) } }\nif statements, e.g. if lt(a, b) { sstore(0, 1) }\nswitch statements, e.g. switch mload(0) case 0 { revert() } default { mstore(0, 1) }\nfor loops, e.g. for { let i := 0} lt(i, 10) { i := add(i, 1) } { mstore(i, 7) }\nfunction definitions, e.g. function f(a, b) -> c { c := add(a, b) }\n\nMultiple syntactical elements can follow each other simply separated by\nwhitespace, i.e. there is no terminating ; or newline required.\n\nLiterals\nAs literals, you can use:\n\nInteger constants in decimal or hexadecimal notation.\nASCII strings (e.g. \"abc\"), which may contain hex escapes \\xNN and Unicode escapes \\uNNNN where N are hexadecimal digits.\nHex strings (e.g. hex\"616263\").\n\nIn the EVM dialect of Yul, literals represent 256-bit words as follows:\n\nDecimal or hexadecimal constants must be less than 2**256.\nThey represent the 256-bit word with that value as an unsigned integer in big endian encoding.\nAn ASCII string is first viewed as a byte sequence, by viewing\na non-escape ASCII character as a single byte whose value is the ASCII code,\nan escape \\xNN as single byte with that value, and\nan escape \\uNNNN as the UTF-8 sequence of bytes for that code point.\nThe byte sequence must not exceed 32 bytes.\nThe byte sequence is padded with zeros on the right to reach 32 bytes in length;\nin other words, the string is stored left-aligned.\nThe padded byte sequence represents a 256-bit word whose most significant 8 bits are the ones from the first byte,\ni.e. the bytes are interpreted in big endian form.\nA hex string is first viewed as a byte sequence, by viewing\neach pair of contiguous hex digits as a byte.\nThe byte sequence must not exceed 32 bytes (i.e. 64 hex digits), and is treated as above.\n\nWhen compiling for the EVM, this will be translated into an\nappropriate PUSHi instruction. In the following example,\n3 and 2 are added resulting in 5 and then the\nbitwise and with the string “abc” is computed.\nThe final value is assigned to a local variable called x.\nThe 32-byte limit above does not apply to string literals passed to builtin functions that require\nliteral arguments (e.g. setimmutable or loadimmutable). Those strings never end up in the\ngenerated bytecode.\nopen in Remix\nlet x := and(\"abc\", add(3, 2))\n\nUnless it is the default type, the type of a literal\nhas to be specified after a colon:\nopen in Remix\n// This will not compile (u32 and u256 type not implemented yet)\nlet x := and(\"abc\":u32, add(3:u256, 2:u256))\n\nFunction Calls\nBoth built-in and user-defined functions (see below) can be called\nin the same way as shown in the previous example.\nIf the function returns a single value, it can be directly used\ninside an expression again. If it returns multiple values,\nthey have to be assigned to local variables.\nopen in Remix\nfunction f(x, y) -> a, b { /* ... */ }\nmstore(0x80, add(mload(0x80), 3))\n// Here, the user-defined function `f` returns two values.\nlet x, y := f(1, mload(0))\n\nFor built-in functions of the EVM, functional expressions\ncan be directly translated to a stream of opcodes:\nYou just read the expression from right to left to obtain the\nopcodes. In the case of the second line in the example, this\nis PUSH1 3 PUSH1 0x80 MLOAD ADD PUSH1 0x80 MSTORE.\nFor calls to user-defined functions, the arguments are also\nput on the stack from right to left and this is the order\nin which argument lists are evaluated. The return values,\nthough, are expected on the stack from left to right,\ni.e. in this example, y is on top of the stack and x\nis below it.\n\nVariable Declarations\nYou can use the let keyword to declare variables.\nA variable is only visible inside the\n{...}-block it was defined in. When compiling to the EVM,\na new stack slot is created that is reserved\nfor the variable and automatically removed again when the end of the block\nis reached. You can provide an initial value for the variable.\nIf you do not provide a value, the variable will be initialized to zero.\nSince variables are stored on the stack, they do not directly\ninfluence memory or storage, but they can be used as pointers\nto memory or storage locations in the built-in functions\nmstore, mload, sstore and sload.\nFuture dialects might introduce specific types for such pointers.\nWhen a variable is referenced, its current value is copied.\nFor the EVM, this translates to a DUP instruction.\nopen in Remix\n{\n let zero := 0\n let v := calldataload(zero)\n {\n let y := add(sload(v), 1)\n v := y\n } // y is \"deallocated\" here\n sstore(v, zero)\n} // v and zero are \"deallocated\" here\n\nIf the declared variable should have a type different from the default type,\nyou denote that following a colon. You can also declare multiple\nvariables in one statement when you assign from a function call\nthat returns multiple values.\nopen in Remix\n// This will not compile (u32 and u256 type not implemented yet)\n{\n let zero:u32 := 0:u32\n let v:u256, t:u32 := f()\n let x, y := g()\n}\n\nDepending on the optimiser settings, the compiler can free the stack slots\nalready after the variable has been used for\nthe last time, even though it is still in scope.\n\nAssignments\nVariables can be assigned to after their definition using the\n:= operator. It is possible to assign multiple\nvariables at the same time. For this, the number and types of the\nvalues have to match.\nIf you want to assign the values returned from a function that has\nmultiple return parameters, you have to provide multiple variables.\nThe same variable may not occur multiple times on the left-hand side of\nan assignment, e.g. x, x := f() is invalid.\nopen in Remix\nlet v := 0\n// re-assign v\nv := 2\nlet t := add(v, 2)\nfunction f() -> a, b { }\n// assign multiple values\nv, t := f()\n\nIf\nThe if statement can be used for conditionally executing code.\nNo “else” block can be defined. Consider using “switch” instead (see below) if\nyou need multiple alternatives.\nopen in Remix\nif lt(calldatasize(), 4) { revert(0, 0) }\n\nThe curly braces for the body are required.\n\nSwitch\nYou can use a switch statement as an extended version of the if statement.\nIt takes the value of an expression and compares it to several literal constants.\nThe branch corresponding to the matching constant is taken.\nContrary to other programming languages, for safety reasons, control flow does\nnot continue from one case to the next. There can be a fallback or default\ncase called default which is taken if none of the literal constants matches.\nopen in Remix\n{\n let x := 0\n switch calldataload(4)\n case 0 {\n x := calldataload(0x24)\n }\n default {\n x := calldataload(0x44)\n }\n sstore(0, div(x, 2))\n}\n\nThe list of cases is not enclosed by curly braces, but the body of a\ncase does require them.\n\nLoops\nYul supports for-loops which consist of\na header containing an initializing part, a condition, a post-iteration\npart and a body. The condition has to be an expression, while\nthe other three are blocks. If the initializing part\ndeclares any variables at the top level, the scope of these variables extends to all other\nparts of the loop.\nThe break and continue statements can be used in the body to exit the loop\nor skip to the post-part, respectively.\nThe following example computes the sum of an area in memory.\nopen in Remix\n{\n let x := 0\n for { let i := 0 } lt(i, 0x100) { i := add(i, 0x20) } {\n x := add(x, mload(i))\n }\n}\n\nFor loops can also be used as a replacement for while loops:\nSimply leave the initialization and post-iteration parts empty.\nopen in Remix\n{\n let x := 0\n let i := 0\n for { } lt(i, 0x100) { } { // while(i < 0x100)\n x := add(x, mload(i))\n i := add(i, 0x20)\n }\n}\n\nFunction Declarations\nYul allows the definition of functions. These should not be confused with functions\nin Solidity since they are never part of an external interface of a contract and\nare part of a namespace separate from the one for Solidity functions.\nFor the EVM, Yul functions take their\narguments (and a return PC) from the stack and also put the results onto the\nstack. User-defined functions and built-in functions are called in exactly the same way.\nFunctions can be defined anywhere and are visible in the block they are\ndeclared in. Inside a function, you cannot access local variables\ndefined outside of that function.\nFunctions declare parameters and return variables, similar to Solidity.\nTo return a value, you assign it to the return variable(s).\nIf you call a function that returns multiple values, you have to assign\nthem to multiple variables using a, b := f(x) or let a, b := f(x).\nThe leave statement can be used to exit the current function. It\nworks like the return statement in other languages just that it does\nnot take a value to return, it just exits the functions and the function\nwill return whatever values are currently assigned to the return variable(s).\nNote that the EVM dialect has a built-in function called return that\nquits the full execution context (internal message call) and not just\nthe current yul function.\nThe following example implements the power function by square-and-multiply.\nopen in Remix\n{\n function power(base, exponent) -> result {\n switch exponent\n case 0 { result := 1 }\n case 1 { result := base }\n default {\n result := power(mul(base, base), div(exponent, 2))\n switch mod(exponent, 2)\n case 1 { result := mul(base, result) }\n }\n }\n}\n\nSpecification of Yul\nThis chapter describes Yul code formally. Yul code is usually placed inside Yul objects,\nwhich are explained in their own chapter.\nBlock = '{' Statement* '}'\nStatement =\n Block |\n FunctionDefinition |\n VariableDeclaration |\n Assignment |\n If |\n Expression |\n Switch |\n ForLoop |\n BreakContinue |\n Leave\nFunctionDefinition =\n 'function' Identifier '(' TypedIdentifierList? ')'\n ( '->' TypedIdentifierList )? Block\nVariableDeclaration =\n 'let' TypedIdentifierList ( ':=' Expression )?\nAssignment =\n IdentifierList ':=' Expression\nExpression =\n FunctionCall | Identifier | Literal\nIf =\n 'if' Expression Block\nSwitch =\n 'switch' Expression ( Case+ Default? | Default )\nCase =\n 'case' Literal Block\nDefault =\n 'default' Block\nForLoop =\n 'for' Block Expression Block Block\nBreakContinue =\n 'break' | 'continue'\nLeave = 'leave'\nFunctionCall =\n Identifier '(' ( Expression ( ',' Expression )* )? ')'\nIdentifier = [a-zA-Z_$] [a-zA-Z_$0-9.]*\nIdentifierList = Identifier ( ',' Identifier)*\nTypeName = Identifier\nTypedIdentifierList = Identifier ( ':' TypeName )? ( ',' Identifier ( ':' TypeName )? )*\nLiteral =\n (NumberLiteral | StringLiteral | TrueLiteral | FalseLiteral) ( ':' TypeName )?\nNumberLiteral = HexNumber | DecimalNumber\nStringLiteral = '\"' ([^\"\\r\\n\\\\] | '\\\\' .)* '\"'\nTrueLiteral = 'true'\nFalseLiteral = 'false'\nHexNumber = '0x' [0-9a-fA-F]+\nDecimalNumber = [0-9]+\n\nRestrictions on the Grammar\nApart from those directly imposed by the grammar, the following\nrestrictions apply:\nSwitches must have at least one case (including the default case).\nAll case values need to have the same type and distinct values.\nIf all possible values of the expression type are covered, a default case is\nnot allowed (i.e. a switch with a bool expression that has both a\ntrue and a false case do not allow a default case).\nEvery expression evaluates to zero or more values. Identifiers and Literals\nevaluate to exactly\none value and function calls evaluate to a number of values equal to the\nnumber of return variables of the function called.\nIn variable declarations and assignments, the right-hand-side expression\n(if present) has to evaluate to a number of values equal to the number of\nvariables on the left-hand-side.\nThis is the only situation where an expression evaluating\nto more than one value is allowed.\nThe same variable name cannot occur more than once in the left-hand-side of\nan assignment or variable declaration.\nExpressions that are also statements (i.e. at the block level) have to\nevaluate to zero values.\nIn all other situations, expressions have to evaluate to exactly one value.\nA continue or break statement can only be used inside the body of a for-loop, as follows.\nConsider the innermost loop that contains the statement.\nThe loop and the statement must be in the same function, or both must be at the top level.\nThe statement must be in the loop’s body block;\nit cannot be in the loop’s initialization block or update block.\nIt is worth emphasizing that this restriction applies just\nto the innermost loop that contains the continue or break statement:\nthis innermost loop, and therefore the continue or break statement,\nmay appear anywhere in an outer loop, possibly in an outer loop’s initialization block or update block.\nFor example, the following is legal,\nbecause the break occurs in the body block of the inner loop,\ndespite also occurring in the update block of the outer loop:\nopen in Remix\nfor {} true { for {} true {} { break } }\n{\n}\n\nThe condition part of the for-loop has to evaluate to exactly one value.\nThe leave statement can only be used inside a function.\nFunctions cannot be defined anywhere inside for loop init blocks.\nLiterals cannot be larger than their type. The largest type defined is 256-bit wide.\nDuring assignments and function calls, the types of the respective values have to match.\nThere is no implicit type conversion. Type conversion in general can only be achieved\nif the dialect provides an appropriate built-in function that takes a value of one\ntype and returns a value of a different type.\n\nScoping Rules\nScopes in Yul are tied to Blocks (exceptions are functions and the for loop\nas explained below) and all declarations\n(FunctionDefinition, VariableDeclaration)\nintroduce new identifiers into these scopes.\nIdentifiers are visible in\nthe block they are defined in (including all sub-nodes and sub-blocks):\nFunctions are visible in the whole block (even before their definitions) while\nvariables are only visible starting from the statement after the VariableDeclaration.\nIn particular,\nvariables cannot be referenced in the right hand side of their own variable\ndeclaration.\nFunctions can be referenced already before their declaration (if they are visible).\nAs an exception to the general scoping rule, the scope of the “init” part of the for-loop\n(the first block) extends across all other parts of the for loop.\nThis means that variables (and functions) declared in the init part (but not inside a\nblock inside the init part) are visible in all other parts of the for-loop.\nIdentifiers declared in the other parts of the for loop respect the regular\nsyntactical scoping rules.\nThis means a for-loop of the form for { I... } C { P... } { B... } is equivalent\nto { I... for {} C { P... } { B... } }.\nThe parameters and return parameters of functions are visible in the\nfunction body and their names have to be distinct.\nInside functions, it is not possible to reference a variable that was declared\noutside of that function.\nShadowing is disallowed, i.e. you cannot declare an identifier at a point\nwhere another identifier with the same name is also visible, even if it is\nnot possible to reference it because it was declared outside the current function.\n\nFormal Specification\nWe formally specify Yul by providing an evaluation function E overloaded\non the various nodes of the AST. As builtin functions can have side effects,\nE takes two state objects and the AST node and returns two new\nstate objects and a variable number of other values.\nThe two state objects are the global state object\n(which in the context of the EVM is the memory, storage and state of the\nblockchain) and the local state object (the state of local variables, i.e. a\nsegment of the stack in the EVM).\nIf the AST node is a statement, E returns the two state objects and a “mode”,\nwhich is used for the break, continue and leave statements.\nIf the AST node is an expression, E returns the two state objects and\nas many values as the expression evaluates to.\nThe exact nature of the global state is unspecified for this high level\ndescription. The local state L is a mapping of identifiers i to values v,\ndenoted as L[i] = v.\nFor an identifier v, let $v be the name of the identifier.\nWe will use a destructuring notation for the AST nodes.\nE(G, L, <{St1, ..., Stn}>: Block) =\n let G1, L1, mode = E(G, L, St1, ..., Stn)\n let L2 be a restriction of L1 to the identifiers of L\n G1, L2, mode\nE(G, L, St1, ..., Stn: Statement) =\n if n is zero:\n G, L, regular\n else:\n let G1, L1, mode = E(G, L, St1)\n if mode is regular then\n E(G1, L1, St2, ..., Stn)\n otherwise\n G1, L1, mode\nE(G, L, FunctionDefinition) =\n G, L, regular\nE(G, L, <let var_1, ..., var_n := rhs>: VariableDeclaration) =\n E(G, L, <var_1, ..., var_n := rhs>: Assignment)\nE(G, L, <let var_1, ..., var_n>: VariableDeclaration) =\n let L1 be a copy of L where L1[$var_i] = 0 for i = 1, ..., n\n G, L1, regular\nE(G, L, <var_1, ..., var_n := rhs>: Assignment) =\n let G1, L1, v1, ..., vn = E(G, L, rhs)\n let L2 be a copy of L1 where L2[$var_i] = vi for i = 1, ..., n\n G1, L2, regular\nE(G, L, <for { i1, ..., in } condition post body>: ForLoop) =\n if n >= 1:\n let G1, L1, mode = E(G, L, i1, ..., in)\n // mode has to be regular or leave due to the syntactic restrictions\n if mode is leave then\n G1, L1 restricted to variables of L, leave\n otherwise\n let G2, L2, mode = E(G1, L1, for {} condition post body)\n G2, L2 restricted to variables of L, mode\n else:\n let G1, L1, v = E(G, L, condition)\n if v is false:\n G1, L1, regular\n else:\n let G2, L2, mode = E(G1, L, body)\n if mode is break:\n G2, L2, regular\n otherwise if mode is leave:\n G2, L2, leave\n else:\n G3, L3, mode = E(G2, L2, post)\n if mode is leave:\n G3, L3, leave\n otherwise\n E(G3, L3, for {} condition post body)\nE(G, L, break: BreakContinue) =\n G, L, break\nE(G, L, continue: BreakContinue) =\n G, L, continue\nE(G, L, leave: Leave) =\n G, L, leave\nE(G, L, <if condition body>: If) =\n let G0, L0, v = E(G, L, condition)\n if v is true:\n E(G0, L0, body)\n else:\n G0, L0, regular\nE(G, L, <switch condition case l1:t1 st1 ... case ln:tn stn>: Switch) =\n E(G, L, switch condition case l1:t1 st1 ... case ln:tn stn default {})\nE(G, L, <switch condition case l1:t1 st1 ... case ln:tn stn default st'>: Switch) =\n let G0, L0, v = E(G, L, condition)\n // i = 1 .. n\n // Evaluate literals, context doesn't matter\n let _, _, v1 = E(G0, L0, l1)\n ...\n let _, _, vn = E(G0, L0, ln)\n if there exists smallest i such that vi = v:\n E(G0, L0, sti)\n else:\n E(G0, L0, st')\n\nE(G, L, <name>: Identifier) =\n G, L, L[$name]\nE(G, L, <fname(arg1, ..., argn)>: FunctionCall) =\n G1, L1, vn = E(G, L, argn)\n ...\n G(n-1), L(n-1), v2 = E(G(n-2), L(n-2), arg2)\n Gn, Ln, v1 = E(G(n-1), L(n-1), arg1)\n Let <function fname (param1, ..., paramn) -> ret1, ..., retm block>\n be the function of name $fname visible at the point of the call.\n Let L' be a new local state such that\n L'[$parami] = vi and L'[$reti] = 0 for all i.\n Let G'', L'', mode = E(Gn, L', block)\n G'', Ln, L''[$ret1], ..., L''[$retm]\nE(G, L, l: StringLiteral) = G, L, str(l),\n where str is the string evaluation function,\n which for the EVM dialect is defined in the section 'Literals' above\nE(G, L, n: HexNumber) = G, L, hex(n)\n where hex is the hexadecimal evaluation function,\n which turns a sequence of hexadecimal digits into their big endian value\nE(G, L, n: DecimalNumber) = G, L, dec(n),\n where dec is the decimal evaluation function,\n which turns a sequence of decimal digits into their big endian value\n\nEVM Dialect\nThe default dialect of Yul currently is the EVM dialect for the currently selected version of the EVM.\nThe only type available in this dialect\nis u256, the 256-bit native type of the Ethereum Virtual Machine.\nSince it is the default type of this dialect, it can be omitted.\nThe following table lists all builtin functions\n(depending on the EVM version) and provides a short description of the\nsemantics of the function / opcode.\nThis document does not want to be a full description of the Ethereum virtual machine.\nPlease refer to a different document if you are interested in the precise semantics.\nOpcodes marked with - do not return a result and all others return exactly one value.\nOpcodes marked with F, H, B, C, I, L, P, N, O and A are present since\nFrontier, Homestead, Byzantium, Constantinople, Istanbul, London, Paris, Cancun, Osaka or Amsterdam respectively.\nIn the following, mem[a...b) signifies the bytes of memory starting at position a up to\nbut not including position b, storage[p] signifies the storage contents at slot p, and\nsimilarly, transientStorage[p] signifies the transient storage contents at slot p.\nSince Yul manages local variables and control-flow,\nopcodes that interfere with these features are not available. This includes\nthe dup and swap instructions as well as jump instructions, labels and the push instructions.\n\nInstruction\n\nExplanation\n\nstop()\n-\nF\nstop execution, identical to return(0, 0)\n\nadd(x, y)\n\nF\nx + y\n\nsub(x, y)\n\nF\nx - y\n\nmul(x, y)\n\nF\nx * y\n\ndiv(x, y)\n\nF\nx / y or 0 if y == 0\n\nsdiv(x, y)\n\nF\nx / y, for signed numbers in two’s complement, 0 if y == 0\n\nmod(x, y)\n\nF\nx % y, 0 if y == 0\n\nsmod(x, y)\n\nF\nx % y, for signed numbers in two’s complement, 0 if y == 0\n\nexp(x, y)\n\nF\nx to the power of y\n\nnot(x)\n\nF\nbitwise “not” of x (every bit of x is negated)\n\nlt(x, y)\n\nF\n1 if x < y, 0 otherwise\n\ngt(x, y)\n\nF\n1 if x > y, 0 otherwise\n\nslt(x, y)\n\nF\n1 if x < y, 0 otherwise, for signed numbers in two’s complement\n\nsgt(x, y)\n\nF\n1 if x > y, 0 otherwise, for signed numbers in two’s complement\n\neq(x, y)\n\nF\n1 if x == y, 0 otherwise\n\niszero(x)\n\nF\n1 if x == 0, 0 otherwise\n\nand(x, y)\n\nF\nbitwise “and” of x and y\n\nor(x, y)\n\nF\nbitwise “or” of x and y\n\nxor(x, y)\n\nF\nbitwise “xor” of x and y\n\nbyte(n, x)\n\nF\nnth byte of x, where the most significant byte is the 0th byte\n\nshl(x, y)\n\nC\nlogical shift left y by x bits\n\nshr(x, y)\n\nC\nlogical shift right y by x bits\n\nsar(x, y)\n\nC\nsigned arithmetic shift right y by x bits\n\nclz(x)\n\nO\nnumber of leading zero bits of x, 256 if x == 0\n\naddmod(x, y, m)\n\nF\n(x + y) % m with arbitrary precision arithmetic, 0 if m == 0\n\nmulmod(x, y, m)\n\nF\n(x * y) % m with arbitrary precision arithmetic, 0 if m == 0\n\nsignextend(i, x)\n\nF\nsign extend from (i*8+7)th bit counting from least significant\n\nkeccak256(p, n)\n\nF\nkeccak(mem[p…(p+n)))\n\npop(x)\n-\nF\ndiscard value x\n\nmload(p)\n\nF\nmem[p…(p+32))\n\nmstore(p, v)\n-\nF\nmem[p…(p+32)) := v\n\nmstore8(p, v)\n-\nF\nmem[p] := v & 0xff (only modifies a single byte)\n\nsload(p)\n\nF\nstorage[p]\n\nsstore(p, v)\n-\nF\nstorage[p] := v\n\ntload(p)\n\nN\ntransientStorage[p]\n\ntstore(p, v)\n-\nN\ntransientStorage[p] := v\n\nmsize()\n\nF\nsize of memory, i.e. largest accessed memory index\n\ngas()\n\nF\ngas still available to execution\n\naddress()\n\nF\naddress of the current contract / execution context\n\nbalance(a)\n\nF\nwei balance at address a\n\nselfbalance()\n\nI\nequivalent to balance(address()), but cheaper\n\ncaller()\n\nF\ncall sender (excluding delegatecall)\n\ncallvalue()\n\nF\nwei sent together with the current call\n\ncalldataload(p)\n\nF\ncall data starting from position p (32 bytes)\n\ncalldatasize()\n\nF\nsize of call data in bytes\n\ncalldatacopy(t, f, s)\n-\nF\ncopy s bytes from calldata at position f to mem at position t\n\ncodesize()\n\nF\nsize of the code of the current contract / execution context\n\ncodecopy(t, f, s)\n-\nF\ncopy s bytes from code at position f to mem at position t\n\nextcodesize(a)\n\nF\nsize of the code at address a\n\nextcodecopy(a, t, f, s)\n-\nF\nlike codecopy(t, f, s) but take code at address a\n\nreturndatasize()\n\nB\nsize of the last returndata\n\nreturndatacopy(t, f, s)\n-\nB\ncopy s bytes from returndata at position f to mem at position t\n\nmcopy(t, f, s)\n-\nN\ncopy s bytes from mem at position f to mem at position t\n\nextcodehash(a)\n\nC\ncode hash of address a\n\ncreate(v, p, n)\n\nF\ncreate new contract with code mem[p…(p+n)) and send v wei\nand return the new address; returns 0 on error\n\ncreate2(v, p, n, s)\n\nC\ncreate new contract with code mem[p…(p+n)) at address\nkeccak256(0xff . this . s . keccak256(mem[p…(p+n)))\nand send v wei and return the new address, where 0xff is a\n1 byte value, this is the current contract’s address\nas a 20 byte value and s is a big-endian 256-bit value;\nreturns 0 on error\n\ncall(g, a, v, in,\ninsize, out, outsize)\n\nF\ncall contract at address a with input mem[in…(in+insize))\nproviding g gas and v wei and output area\nmem[out…(out+outsize)) returning 0 on error (eg. out of gas)\nand 1 on success\nSee more\n\ncallcode(g, a, v, in,\ninsize, out, outsize)\n\nF\nidentical to call but only use the code from a and stay\nin the context of the current contract otherwise\nSee more\n\ndelegatecall(g, a, in,\ninsize, out, outsize)\n\nH\nidentical to callcode but also keep caller\nand callvalue\nSee more\n\nstaticcall(g, a, in,\ninsize, out, outsize)\n\nB\nidentical to call(g, a, 0, in, insize, out, outsize) but do\nnot allow state modifications\nSee more\n\nreturn(p, s)\n-\nF\nend execution, return data mem[p…(p+s))\n\nrevert(p, s)\n-\nB\nend execution, revert state changes, return data mem[p…(p+s))\n\nselfdestruct(a)\n-\nF\nend execution, destroy current contract and send funds to a\n(deprecated)\n\ninvalid()\n-\nF\nend execution with invalid instruction\n\nlog0(p, s)\n-\nF\nlog data mem[p…(p+s))\n\nlog1(p, s, t1)\n-\nF\nlog data mem[p…(p+s)) with topic t1\n\nlog2(p, s, t1, t2)\n-\nF\nlog data mem[p…(p+s)) with topics t1, t2\n\nlog3(p, s, t1, t2, t3)\n-\nF\nlog data mem[p…(p+s)) with topics t1, t2, t3\n\nlog4(p, s, t1, t2, t3,\nt4)\n-\nF\nlog data mem[p…(p+s)) with topics t1, t2, t3, t4\n\nchainid()\n\nI\nID of the executing chain (EIP-1344)\n\nbasefee()\n\nL\ncurrent block’s base fee (EIP-3198 and EIP-1559)\n\nblobbasefee()\n\nN\ncurrent block’s blob base fee (EIP-7516 and EIP-4844)\n\nslotnum()\n\nA\ncurrent beacon chain slot number (EIP-7843)\n\norigin()\n\nF\ntransaction sender\n\ngasprice()\n\nF\ngas price of the transaction\n\nblockhash(b)\n\nF\nhash of block nr b - only for last 256 blocks excluding current\n\nblobhash(i)\n\nN\nversioned hash of transaction’s i-th blob, 0 if blob does not\nexist\n\ncoinbase()\n\nF\ncurrent mining beneficiary\n\ntimestamp()\n\nF\ntimestamp of the current block in seconds since the epoch\n\nnumber()\n\nF\ncurrent block number\n\ndifficulty()\n\nF\ndifficulty of the current block (see note below)\n\nprevrandao()\n\nP\nrandomness provided by the beacon chain (see note below)\n\ngaslimit()\n\nF\nblock gas limit of the current block\n\nNote\nThe call* instructions use the out and outsize parameters to define an area in memory where\nthe return or failure data is placed. This area is written to depending on how many bytes the called contract returns.\nIf it returns more data, only the first outsize bytes are written. You can access the rest of the data\nusing the returndatacopy opcode. If it returns less data, then the remaining bytes are not touched at all.\nYou need to use the returndatasize opcode to check which part of this memory area contains the return data.\nThe remaining bytes will retain their values as of before the call.\n\nNote\nThe difficulty() instruction is disallowed in EVM version >= Paris.\nWith the Paris network upgrade the semantics of the instruction that was previously called\ndifficulty have been changed and the instruction was renamed to prevrandao.\nIt can now return arbitrary values in the full 256-bit range, whereas the highest recorded\ndifficulty value within Ethash was ~54 bits.\nThis change is described in EIP-4399.\nPlease note that irrelevant to which EVM version is selected in the compiler, the semantics of\ninstructions depend on the final chain of deployment.\n\nWarning\nFrom version 0.8.18 and up, the use of selfdestruct in both Solidity and Yul will trigger a\ndeprecation warning, since the SELFDESTRUCT opcode will eventually undergo breaking changes in behavior\nas stated in EIP-6049.\n\nIn some internal dialects, there are additional functions:\n\ndatasize, dataoffset, datacopy\nThe functions datasize(x), dataoffset(x) and datacopy(t, f, l)\nare used to access other parts of a Yul object.\ndatasize and dataoffset can only take string literals (the names of other objects)\nas arguments and return the size and offset in the data area, respectively.\nFor the EVM, the datacopy function is equivalent to codecopy.\n\nsetimmutable, loadimmutable\nThe functions setimmutable(offset, \"name\", value) and loadimmutable(\"name\") are\nused for the immutable mechanism in Solidity and do not nicely map to pure Yul.\nThe call to setimmutable(offset, \"name\", value) assumes that the runtime code of the contract\ncontaining the given named immutable was copied to memory at offset offset and will write value to all\npositions in memory (relative to offset) that contain the placeholder that was generated for calls\nto loadimmutable(\"name\") in the runtime code.\n\nlinkersymbol\nThe function linkersymbol(\"library_id\") is a placeholder for an address literal to be substituted\nby the linker.\nIts first and only argument must be a string literal and uniquely represents the address to be inserted.\nIdentifiers can be arbitrary but when the compiler produces Yul code from Solidity sources,\nit uses a library name qualified with the name of the source unit that defines that library.\nTo link the code with a particular library address, the same identifier must be provided to the\n--libraries option on the command-line.\nFor example this code\nopen in Remix\nlet a := linkersymbol(\"file.sol:Math\")\n\nis equivalent to\nopen in Remix\nlet a := 0x1234567890123456789012345678901234567890\n\nwhen the linker is invoked with --libraries \"file.sol:Math=0x1234567890123456789012345678901234567890\noption.\nSee Using the Commandline Compiler for details about the Solidity linker.\n\nmemoryguard\nThis function is available in the EVM dialect with objects. The caller of\nlet ptr := memoryguard(size) (where size has to be a literal number)\npromises that they only use memory in either the range [0, size) or the\nunbounded range starting at ptr.\nSince the presence of a memoryguard call indicates that all memory access\nadheres to this restriction, it allows the optimizer to perform additional\noptimization steps, for example the stack limit evader, which attempts to move\nstack variables that would otherwise be unreachable to memory.\nThe Yul optimizer promises to only use the memory range [size, ptr) for its purposes.\nIf the optimizer does not need to reserve any memory, it holds that ptr == size.\nmemoryguard can be called multiple times, but needs to have the same literal as argument\nwithin one Yul subobject. If at least one memoryguard call is found in a subobject,\nthe additional optimiser steps will be run on it.\n\nverbatim\nThe set of verbatim... builtin functions lets you create bytecode for opcodes\nthat are not known to the Yul compiler. It also allows you to create\nbytecode sequences that will not be modified by the optimizer.\nThe functions are verbatim_<n>i_<m>o(\"<data>\", ...), where\n\nn is a decimal between 0 and 99 that specifies the number of input stack slots / variables\nm is a decimal between 0 and 99 that specifies the number of output stack slots / variables\ndata is a string literal that contains the sequence of bytes\n\nIf you for example want to define a function that multiplies the input\nby two, without the optimizer touching the constant two, you can use\nopen in Remix\nlet x := calldataload(0)\nlet double := verbatim_1i_1o(hex\"600202\", x)\n\nThis code will result in a dup1 opcode to retrieve x\n(the optimizer might directly reuse result of the\ncalldataload opcode, though)\ndirectly followed by 600202. The code is assumed to\nconsume the copied value of x and produce the result\non the top of the stack. The compiler then generates code\nto allocate a stack slot for double and store the result there.\nAs with all opcodes, the arguments are arranged on the stack\nwith the leftmost argument on the top, while the return values\nare assumed to be laid out such that the rightmost variable is\nat the top of the stack.\nSince verbatim can be used to generate arbitrary opcodes\nor even opcodes unknown to the Solidity compiler, care has to be taken\nwhen using verbatim together with the optimizer. Even when the\noptimizer is switched off, the code generator has to determine\nthe stack layout, which means that e.g. using verbatim to modify\nthe stack height can lead to undefined behavior.\nThe following is a non-exhaustive list of restrictions on\nverbatim bytecode that are not checked by\nthe compiler. Violations of these restrictions can result in\nundefined behavior.\n\nControl-flow should not jump into or out of verbatim blocks,\nbut it can jump within the same verbatim block. In particular,\nreverting or returning from the block is not allowed.\nStack contents apart from the input and output parameters\nshould not be accessed.\nThe stack height difference should be exactly m - n\n(output slots minus input slots).\nVerbatim bytecode cannot make any assumptions about the\nsurrounding bytecode. All required parameters have to be\npassed in as stack variables.\n\nThe optimizer does not analyze verbatim bytecode and always\nassumes that it modifies all aspects of state and thus can only\ndo very few optimizations across verbatim function calls.\nThe optimizer treats verbatim bytecode as an opaque block of code.\nIt will not split it but might move, duplicate\nor combine it with identical verbatim bytecode blocks.\nIf a verbatim bytecode block is unreachable by the control-flow,\nit can be removed.\n\nWarning\nDuring discussions about whether or not EVM improvements\nmight break existing smart contracts, features inside verbatim\ncannot receive the same consideration as those used by the Solidity\ncompiler itself.\n\nNote\nTo avoid confusion, all identifiers starting with the string verbatim are reserved\nand cannot be used for user-defined identifiers.\n\nSpecification of Yul Object\nYul objects are used to group named code and data sections.\nThe functions datasize, dataoffset and datacopy\ncan be used to access these sections from within code.\nHex strings can be used to specify data in hex encoding,\nregular strings in native encoding. For code,\ndatacopy will access its assembled binary representation.\nObject = 'object' StringLiteral '{' Code ( Object | Data )* '}'\nCode = 'code' Block\nData = 'data' StringLiteral ( HexLiteral | StringLiteral )\nHexLiteral = 'hex' ('\"' ([0-9a-fA-F]{2})* '\"' | '\\'' ([0-9a-fA-F]{2})* '\\'')\nStringLiteral = '\"' ([^\"\\r\\n\\\\] | '\\\\' .)* '\"'\n\nAbove, Block refers to Block in the Yul code grammar explained in the previous chapter.\n\nNote\nAn object with a name that ends in _deployed is treated as deployed code by the Yul optimizer.\nThe only consequence of this is a different gas cost heuristic in the optimizer.\n\nNote\nData objects or sub-objects whose names contain a . can be defined\nbut it is not possible to access them through datasize,\ndataoffset or datacopy because . is used as a separator\nto access objects inside another object.\n\nNote\nThe data object called \".metadata\" has a special meaning:\nIt cannot be accessed from code and is always appended to the very end of the\nbytecode, regardless of its position in the object.\nOther data objects with special significance might be added in the\nfuture, but their names will always start with a ..\n\nAn example Yul Object is shown below:\nopen in Remix\n// A contract consists of a single object with sub-objects representing\n// the code to be deployed or other contracts it can create.\n// The single \"code\" node is the executable code of the object.\n// Every (other) named object or data section is serialized and\n// made accessible to the special built-in functions datacopy / dataoffset / datasize\n// The current object, sub-objects and data items inside the current object\n// are in scope.\nobject \"Contract1\" {\n // This is the constructor code of the contract.\n code {\n function allocate(size) -> ptr {\n ptr := mload(0x40)\n // Note that Solidity generated IR code reserves memory offset ``0x60`` as well, but a pure Yul object is free to use memory as it chooses.\n if iszero(ptr) { ptr := 0x60 }\n mstore(0x40, add(ptr, size))\n }\n\n // first create \"Contract2\"\n let size := datasize(\"Contract2\")\n let offset := allocate(size)\n // This will turn into codecopy for EVM\n datacopy(offset, dataoffset(\"Contract2\"), size)\n // constructor parameter is a single number 0x1234\n mstore(add(offset, size), 0x1234)\n pop(create(0, offset, add(size, 32)))\n\n // now return the runtime object (the currently\n // executing code is the constructor code)\n size := datasize(\"Contract1_deployed\")\n offset := allocate(size)\n // This will turn into a codecopy for EVM\n datacopy(offset, dataoffset(\"Contract1_deployed\"), size)\n return(offset, size)\n }\n\n data \"Table2\" hex\"4123\"\n\n object \"Contract1_deployed\" {\n code {\n function allocate(size) -> ptr {\n ptr := mload(0x40)\n // Note that Solidity generated IR code reserves memory offset ``0x60`` as well, but a pure Yul object is free to use memory as it chooses.\n if iszero(ptr) { ptr := 0x60 }\n mstore(0x40, add(ptr, size))\n }\n\n // runtime code\n\n mstore(0, \"Hello, World!\")\n return(0, 0x20)\n }\n }\n\n // Embedded object. Use case is that the outside is a factory contract,\n // and Contract2 is the code to be created by the factory\n object \"Contract2\" {\n code {\n // code here ...\n }\n\n object \"Contract2_deployed\" {\n code {\n // code here ...\n }\n }\n\n data \"Table1\" hex\"4123\"\n }\n}\n\nYul Optimizer\nThe Yul optimizer operates on Yul code and uses the same language for input, output and\nintermediate states. This allows for easy debugging and verification of the optimizer.\nPlease refer to the general optimizer documentation\nfor more details about the different optimization stages and how to use the optimizer.\nIf you want to use Solidity in stand-alone Yul mode, you activate the optimizer using --optimize\nand optionally specify the expected number of contract executions with\n--optimize-runs:\nsolc --strict-assembly --optimize --optimize-runs 200\n\nIn Solidity mode, the Yul optimizer is activated together with the regular optimizer.\n\nOptimization Step Sequence\nDetailed information regarding the optimization sequence as well as a list of abbreviations is\navailable in the optimizer docs.\n\nComplete ERC20 Example\nopen in Remix\nobject \"Token\" {\n code {\n // Store the creator in slot zero.\n sstore(0, caller())\n\n // Deploy the contract\n datacopy(0, dataoffset(\"runtime\"), datasize(\"runtime\"))\n return(0, datasize(\"runtime\"))\n }\n object \"runtime\" {\n code {\n // Protection against sending Ether\n require(iszero(callvalue()))\n\n // Dispatcher\n switch selector()\n case 0x70a08231 /* \"balanceOf(address)\" */ {\n returnUint(balanceOf(decodeAsAddress(0)))\n }\n case 0x18160ddd /* \"totalSupply()\" */ {\n returnUint(totalSupply())\n }\n case 0xa9059cbb /* \"transfer(address,uint256)\" */ {\n transfer(decodeAsAddress(0), decodeAsUint(1))\n returnTrue()\n }\n case 0x23b872dd /* \"transferFrom(address,address,uint256)\" */ {\n transferFrom(decodeAsAddress(0), decodeAsAddress(1), decodeAsUint(2))\n returnTrue()\n }\n case 0x095ea7b3 /* \"approve(address,uint256)\" */ {\n approve(decodeAsAddress(0), decodeAsUint(1))\n returnTrue()\n }\n case 0xdd62ed3e /* \"allowance(address,address)\" */ {\n returnUint(allowance(decodeAsAddress(0), decodeAsAddress(1)))\n }\n case 0x40c10f19 /* \"mint(address,uint256)\" */ {\n mint(decodeAsAddress(0), decodeAsUint(1))\n returnTrue()\n }\n default {\n revert(0, 0)\n }\n\n function mint(account, amount) {\n require(calledByOwner())\n\n mintTokens(amount)\n addToBalance(account, amount)\n emitTransfer(0, account, amount)\n }\n function transfer(to, amount) {\n executeTransfer(caller(), to, amount)\n }\n function approve(spender, amount) {\n revertIfZeroAddress(spender)\n setAllowance(caller(), spender, amount)\n emitApproval(caller(), spender, amount)\n }\n function transferFrom(from, to, amount) {\n decreaseAllowanceBy(from, caller(), amount)\n executeTransfer(from, to, amount)\n }\n\n function executeTransfer(from, to, amount) {\n revertIfZeroAddress(to)\n deductFromBalance(from, amount)\n addToBalance(to, amount)\n emitTransfer(from, to, amount)\n }\n\n /* ---------- calldata decoding functions ----------- */\n function selector() -> s {\n s := div(calldataload(0), 0x100000000000000000000000000000000000000000000000000000000)\n }\n\n function decodeAsAddress(offset) -> v {\n v := decodeAsUint(offset)\n if iszero(iszero(and(v, not(0xffffffffffffffffffffffffffffffffffffffff)))) {\n revert(0, 0)\n }\n }\n function decodeAsUint(offset) -> v {\n let pos := add(4, mul(offset, 0x20))\n if lt(calldatasize(), add(pos, 0x20)) {\n revert(0, 0)\n }\n v := calldataload(pos)\n }\n /* ---------- calldata encoding functions ---------- */\n function returnUint(v) {\n mstore(0, v)\n return(0, 0x20)\n }\n function returnTrue() {\n returnUint(1)\n }\n\n /* -------- events ---------- */\n function emitTransfer(from, to, amount) {\n let signatureHash := 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef\n emitEvent(signatureHash, from, to, amount)\n }\n function emitApproval(from, spender, amount) {\n let signatureHash := 0x8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925\n emitEvent(signatureHash, from, spender, amount)\n }\n function emitEvent(signatureHash, indexed1, indexed2, nonIndexed) {\n mstore(0, nonIndexed)\n log3(0, 0x20, signatureHash, indexed1, indexed2)\n }\n\n /* -------- storage layout ---------- */\n function ownerPos() -> p { p := 0 }\n function totalSupplyPos() -> p { p := 1 }\n function accountToStorageOffset(account) -> offset {\n offset := add(0x1000, account)\n }\n function allowanceStorageOffset(account, spender) -> offset {\n offset := accountToStorageOffset(account)\n mstore(0, offset)\n mstore(0x20, spender)\n offset := keccak256(0, 0x40)\n }\n\n /* -------- storage access ---------- */\n function owner() -> o {\n o := sload(ownerPos())\n }\n function totalSupply() -> supply {\n supply := sload(totalSupplyPos())\n }\n function mintTokens(amount) {\n sstore(totalSupplyPos(), safeAdd(totalSupply(), amount))\n }\n function balanceOf(account) -> bal {\n bal := sload(accountToStorageOffset(account))\n }\n function addToBalance(account, amount) {\n let offset := accountToStorageOffset(account)\n sstore(offset, safeAdd(sload(offset), amount))\n }\n function deductFromBalance(account, amount) {\n let offset := accountToStorageOffset(account)\n let bal := sload(offset)\n require(lte(amount, bal))\n sstore(offset, sub(bal, amount))\n }\n function allowance(account, spender) -> amount {\n amount := sload(allowanceStorageOffset(account, spender))\n }\n function setAllowance(account, spender, amount) {\n sstore(allowanceStorageOffset(account, spender), amount)\n }\n function decreaseAllowanceBy(account, spender, amount) {\n let offset := allowanceStorageOffset(account, spender)\n let currentAllowance := sload(offset)\n require(lte(amount, currentAllowance))\n sstore(offset, sub(currentAllowance, amount))\n }\n\n /* ---------- utility functions ---------- */\n function lte(a, b) -> r {\n r := iszero(gt(a, b))\n }\n function gte(a, b) -> r {\n r := iszero(lt(a, b))\n }\n function safeAdd(a, b) -> r {\n r := add(a, b)\n if or(lt(r, a), lt(r, b)) { revert(0, 0) }\n }\n function calledByOwner() -> cbo {\n cbo := eq(owner(), caller())\n }\n function revertIfZeroAddress(addr) {\n require(addr)\n }\n function require(condition) {\n if iszero(condition) { revert(0, 0) }\n }\n }\n }\n}","tokens":12067,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263789019,"hash":"d389ad862b0b450f9dc173d09bcc9b9f7cca9189"}
{"url":"https://docs.arbitrum.io/build-decentralized-apps/quickstart-solidity-remix","domain":"docs.arbitrum.io","title":"Build a decentralized app with Solidity (Quickstart) | Arbitrum Docs","text":"✏️Request an updateWant to use Rust instead?Head over to the Stylus quickstart if you'd like to use Rust instead of Solidity.\nThis quickstart is for web developers who want to start building decentralized applications using Arbitrum. It makes no assumptions about your prior experience with Ethereum, Arbitrum, or Solidity. Familiarity with Javascript and yarn is expected. If you're new to Ethereum, consider studying the Ethereum documentation before proceeding.\n\nWhat we'll learn​\nIn this tutorial we will learn:\n\nThe basics of Ethereum vs. client/server architecture\nWhat is a Solidity smart contract\nHow to compile and deploy a smart contract\nHow to use an Ethereum wallet\n\nWe're going to build a digital cupcake vending machine using Solidity smart contracts1. This vending machine will follow two rules:\n\nThe vending machine will distribute a cupcake to anyone who hasn't recently received one.\nThe vending machine's rules can't be changed by anyone.\n\nHere's the vending machine implemented with Javascript.\nTo use it, enter a name in the form below and press the Cupcake please! button, you should see your cupcake balance go up.\nFree Cupcakesweb2NameContract addressRefresh balance🧁Cupcake balance:0 (no name)\nWe can assume that this vending machine operates as we expect, but it's largely up to the centralized service provider that hosts it.\nIn the case of a compromised cloud host:\n\nOur centralized service provider can deny access to particular users.\nA malicious actor can change the rules of the vending machine at any time, for example, to give their friends extra cupcakes.\n\nCentralized third-party intermediaries represent a single point of failure that malicious actors can exploit. With a blockchain infrastructure such as Ethereum, we decentralize our vending machine's business logic and data, making this type of exploits nearly impossible.\nThis is Arbitrum's core value proposition to you, dear developer. Arbitrum makes it easy for you to deploy your vending machines to Ethereum's permissionless, trustless, decentralized network of nodes2 while keeping costs low for you and your users.\nLet's implement the \"Web3\" version of the above vending machine using Arbitrum.\nPrerequisites​\nVS CodeVS Code is the IDE we'll use to build our vending machine. See code.visualstudio.com to install.\nWeb3 walletWe will use Metamask as the wallet to interact with our vending machine. See metamask.io and click View MetaMask Web or OKX Wallet and click Connect Wallet to install.\nYarnYarn is the package manager we'll use to install dependencies. See yarnpkg.com to install.\nFoundryFoundry is the toolchain we'll use to compile and deploy our smart contract. See getfoundry.sh to install.\nWe'll address any remaining dependencies as we go.\nEthereum and Arbitrum in a nutshell​\n\nEthereum\n\nEthereum is a decentralized network of nodes that use Ethereum's client software (like Offchain's Prysm to maintain a public blockchain data structure.\nThe data within Ethereum's blockchain data structure changes one transaction at a time.\nSmart contracts are small programs that execute transactions according to predefined rules. Ethereum's nodes host and execute smart contracts.\nYou can use smart contracts to build decentralized apps that use Ethereum's network to process transactions and store data. Think of smart contracts as your app's backend\nApps let users carry their data and identity between applications without trusting centralized service providers.\nPeople who run Ethereum validator nodes3 can earn ETH for processing and validating transactions on behalf of users and apps.\nThese transactions can be expensive when the network is under heavy load.\n\nArbitrum\n\nArbitrum is a finance-native platform providing infrastructure for building applications.\nArbitrum One is a child chain that implements the\nArbitrum Rollup protocol. See the Arbitrum chains overview for a comparison of Arbitrum One, Nova, and the available testnets.\nYou can use Arbitrum One to build user-friendly apps with high throughput, low latency, and low transaction costs while inheriting Ethereum's high-security standards4.\n\nReview the Javascript vending machine​\nHere's the vending machine implemented as a Javascript class:\nVendingMachine.jsclass VendingMachine { // state variables = internal memory of the vending machine cupcakeBalances = {}; cupcakeDistributionTimes = {}; // Vend a cupcake to the caller giveCupcakeTo(userId) { if (this.cupcakeDistributionTimes[userId] === undefined) { this.cupcakeBalances[userId] = 0; this.cupcakeDistributionTimes[userId] = 0; } // Rule 1: The vending machine will distribute a cupcake to anyone who hasn't recently received one. const fiveSeconds = 5000; const userCanReceiveCupcake = this.cupcakeDistributionTimes[userId] + fiveSeconds <= Date.now(); if (userCanReceiveCupcake) { this.cupcakeBalances[userId]++; this.cupcakeDistributionTimes[userId] = Date.now(); console.log(`Enjoy your cupcake, ${userId}!`); return true; } else { console.error('HTTP 429: Too Many Cupcakes (you must wait at least 5 seconds between cupcakes)'); return false; } } getCupcakeBalanceFor(userId) { return this.cupcakeBalances[userId]; }}\nThe VendingMachine class uses state variables and functions to implement predefined rules. This implementation is useful because it automates cupcake distribution, but there's a problem: it's hosted by a centralized server controlled by a third-party service provider.\nWorking web2 versionTo use the Vending Machine (web2), copy and paste the HTML code below into a text document, then open it in your web browser.VendingMachine.html<!DOCTYPE html><html lang=\"en\"><head> <meta charset=\"UTF-8\" /> <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\" /> <title>Cupcake Vending Machine - Arbitrum Quickstart</title> <script src=\"https://cdn.ethers.io/lib/ethers-5.7.umd.min.js\"></script> <style> *, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; } body { font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; background: #0d1117; color: #e6edf3; min-height: 100vh; display: flex; flex-direction: column; align-items: center; padding: 2rem 1rem; } h1 { font-size: 1.8rem; margin-bottom: 0.25rem; color: #58a6ff; } .subtitle { color: #8b949e; margin-bottom: 2rem; font-size: 0.95rem; } .machines { display: flex; gap: 2rem; flex-wrap: wrap; justify-content: center; width: 100%; max-width: 900px; } .vending-machine { background: #161b22; border: 1px solid #30363d; border-radius: 12px; padding: 1.5rem; width: 400px; display: flex; flex-direction: column; gap: 0.75rem; } .vending-machine h2 { font-size: 1.25rem; color: #e6edf3; } .vending-machine .badge { display: inline-block; font-size: 0.7rem; font-weight: 600; text-transform: uppercase; letter-spacing: 0.05em; padding: 0.2em 0.6em; border-radius: 4px; width: fit-content; } .badge-web2 { background: #238636; color: #fff; } .badge-web3 { background: #1f6feb; color: #fff; } label { font-size: 0.85rem; color: #8b949e; font-weight: 500; } input[type=\"text\"] { background: #0d1117; border: 1px solid #30363d; border-radius: 6px; padding: 0.6rem 0.75rem; color: #e6edf3; font-size: 0.9rem; outline: none; transition: border-color 0.2s; } input[type=\"text\"]:focus { border-color: #58a6ff; } input[type=\"text\"]::placeholder { color: #484f58; } .btn { padding: 0.6rem 1rem; border: none; border-radius: 6px; font-size: 0.9rem; font-weight: 600; cursor: pointer; transition: background 0.2s; } .btn-primary { background: #238636; color: #fff; } .btn-primary:hover { background: #2ea043; } .btn-secondary { background: transparent; color: #58a6ff; border: 1px solid #30363d; } .btn-secondary:hover { background: #161b22; border-color: #58a6ff; } .cupcake-display { font-size: 3rem; text-align: center; height: 4rem; line-height: 4rem; transition: opacity 0.3s; } .balance { display: flex; justify-content: space-between; align-items: center; background: #0d1117; border-radius: 6px; padding: 0.6rem 0.75rem; font-size: 0.9rem; } .balance-count { font-weight: 700; color: #58a6ff; font-size: 1.1rem; } .status { font-size: 0.8rem; min-height: 1.2rem; color: #f85149; text-align: center; } .status.success { color: #3fb950; } .hidden { display: none; } .actions { display: flex; gap: 0.5rem; } .actions .btn { flex: 1; } .description { font-size: 0.8rem; color: #8b949e; line-height: 1.4; border-left: 2px solid #30363d; padding-left: 0.75rem; } </style></head><body> <h1>Cupcake Vending Machine</h1> <p class=\"subtitle\">From the Arbitrum Solidity + Remix Quickstart</p> <div class=\"machines\"> <!-- WEB2 Vending Machine --> <div class=\"vending-machine\"> <span class=\"badge badge-web2\">Web2</span> <h2>Free Cupcakes</h2> <p class=\"description\">Pure JavaScript vending machine. Business logic runs in your browser — no blockchain involved.</p> <label for=\"web2-name\">Name</label> <input type=\"text\" id=\"web2-name\" placeholder=\"Enter name\" /> <div class=\"actions\"> <button class=\"btn btn-primary\" id=\"web2-vend\">Cupcake please!</button> <button class=\"btn btn-secondary\" id=\"web2-refresh\">Refresh balance</button> </div> <div class=\"cupcake-display\" id=\"web2-cupcake\"></div> <div class=\"balance\"> <span>Cupcake balance for <strong id=\"web2-who\">—</strong>:</span> <span class=\"balance-count\" id=\"web2-balance\">0</span> </div> <div class=\"status\" id=\"web2-status\"></div> </div><script>// ============================================================// VendingMachine.js — the JavaScript class from the quickstart// ============================================================class VendingMachine { // state variables = internal memory of the vending machine cupcakeBalances = {}; cupcakeDistributionTimes = {}; // Vend a cupcake to the caller giveCupcakeTo(userId) { if (this.cupcakeDistributionTimes[userId] === undefined) { this.cupcakeBalances[userId] = 0; this.cupcakeDistributionTimes[userId] = 0; } // Rule 1: The vending machine will distribute a cupcake to anyone who hasn't recently received one. const fiveSeconds = 5000; const userCanReceiveCupcake = this.cupcakeDistributionTimes[userId] + fiveSeconds <= Date.now(); if (userCanReceiveCupcake) { this.cupcakeBalances[userId]++; this.cupcakeDistributionTimes[userId] = Date.now(); console.log(`Enjoy your cupcake, ${userId}!`); return true; } else { console.error( 'HTTP 429: Too Many Cupcakes (you must wait at least 5 seconds between cupcakes)', ); return false; } } getCupcakeBalanceFor(userId) { return this.cupcakeBalances[userId] || 0; }}// ============================================================// VendingMachine.sol ABI (from the compiled Solidity contract)// ============================================================const VENDING_MACHINE_ABI = [ { inputs: [{ internalType: \"address\", name: \"userAddress\", type: \"address\" }], name: \"getCupcakeBalanceFor\", outputs: [{ internalType: \"uint256\", name: \"\", type: \"uint256\" }], stateMutability: \"view\", type: \"function\" }, { inputs: [{ internalType: \"address\", name: \"userAddress\", type: \"address\" }], name: \"giveCupcakeTo\", outputs: [{ internalType: \"bool\", name: \"\", type: \"bool\" }], stateMutability: \"nonpayable\", type: \"function\" }];// ============================================================// Helper: flash a cupcake emoji with fade-out// ============================================================function flashCupcake(elementId) { const el = document.getElementById(elementId); el.textContent = '\\u{1F9C1}'; el.style.opacity = 1; el.style.transition = 'none'; requestAnimationFrame(() => { el.style.transition = 'opacity 4.5s ease-out'; el.style.opacity = 0; });}function truncateAddress(text) { if (!text) return '—'; if (text.length < 10) return text; return text.slice(0, 6) + '...' + text.slice(-4);}// ============================================================// WEB2 Vending Machine// ============================================================(function initWeb2() { const vm = new VendingMachine(); const nameInput = document.getElementById('web2-name'); const vendBtn = document.getElementById('web2-vend'); const refreshBtn = document.getElementById('web2-refresh'); const balanceEl = document.getElementById('web2-balance'); const whoEl = document.getElementById('web2-who'); const statusEl = document.getElementById('web2-status'); function refreshBalance() { const name = nameInput.value.trim() || 'no name'; const bal = vm.getCupcakeBalanceFor(name); balanceEl.textContent = bal; whoEl.textContent = truncateAddress(name); } vendBtn.addEventListener('click', () => { const name = nameInput.value.trim() || 'no name'; const got = vm.giveCupcakeTo(name); if (got) { statusEl.textContent = `Enjoy your cupcake, ${name}!`; statusEl.className = 'status success'; flashCupcake('web2-cupcake'); refreshBalance(); } else { statusEl.textContent = 'Too many cupcakes! Wait at least 5 seconds.'; statusEl.className = 'status'; } }); refreshBtn.addEventListener('click', refreshBalance);})();</script></body></html>\nNow, let's decentralize our vending machine's business logic and data by porting the above JavaScript implementation into a Solidity smart contract.\nReview the Solidity vending machine​\nHere is a Solidity implementation of the vending machine.\nSolidity is a language that compiles to EVM bytecode. This means that it is deployable to any Ethereum-compatible blockchain, including Ethereum mainnet, Arbitrum One, and Arbitrum Nova.\nVendingMachine.sol// SPDX-License-Identifier: MIT// Specify the Solidity compiler version - this contract requires version 0.8.9 or higherpragma solidity ^0.8.9;// Define a smart contract named VendingMachine// Unlike regular classes, once deployed, this contract's code cannot be modified// This ensures that the vending machine's rules remain constant and trustworthycontract VendingMachine { // State variables are permanently stored in blockchain storage // These mappings associate Ethereum addresses with unsigned integers // The 'private' keyword means these variables can only be accessed from within this contract mapping(address => uint) private _cupcakeBalances; // Tracks how many cupcakes each address owns mapping(address => uint) private _cupcakeDistributionTimes; // Tracks when each address last received a cupcake // Function to give a cupcake to a specified address // 'public' means this function can be called by anyone // 'returns (bool)' specifies that the function returns a boolean value function giveCupcakeTo(address userAddress) public returns (bool) { // Initialize first-time users // In Solidity, uninitialized values default to 0, so this check isn't strictly necessary // but is included to mirror the JavaScript implementation if (_cupcakeDistributionTimes[userAddress] == 0) { _cupcakeBalances[userAddress] = 0; _cupcakeDistributionTimes[userAddress] = 0; } // Calculate when the user is eligible for their next cupcake // 'seconds' is a built-in time unit in Solidity // 'block.timestamp' gives us the current time in seconds since Unix epoch uint fiveSecondsFromLastDistribution = _cupcakeDistributionTimes[userAddress] + 5 seconds; bool userCanReceiveCupcake = fiveSecondsFromLastDistribution <= block.timestamp; if (userCanReceiveCupcake) { // If enough time has passed, give them a cupcake and update their last distribution time _cupcakeBalances[userAddress]++; _cupcakeDistributionTimes[userAddress] = block.timestamp; return true; } else { // If not enough time has passed, revert the transaction with an error message // 'revert' cancels the transaction and returns the error message to the user revert(\"HTTP 429: Too Many Cupcakes (you must wait at least 5 seconds between cupcakes)\"); } } // Function to check how many cupcakes an address owns // 'public' means anyone can call this function // 'view' means this function only reads data and doesn't modify state // This makes it free to call (no gas cost) when called externally function getCupcakeBalanceFor(address userAddress) public view returns (uint) { return _cupcakeBalances[userAddress]; }}\nCompile your smart contract with Remix​\nSmart contracts need to be compiled to bytecode to be stored and executed onchain by the EVM; we'll use Remix to do that.\nRemix is a browser-based IDE for EVM development. There are other IDEs to choose from (Foundry, Hardhat), but Remix doesn't require any local environment setup, so we'll use it for this tutorial.\nLet's first add our smart contract to Remix following these steps:\n1. Load Remix: https://remix.ethereum.org​\n2. Create a blank workspace in Remix:​\n\nFile explorer > Workspaces > Create blank\n3. Copy your vending machine contract​\n4. Paste your contract in Remix​\nSelect vending machine contract > Click compile menu > Compile\n\"File explorer > New file\"\n5. Compile your contract in Remix​\nSelect vending machine contract > Click compile menu > Compile\nNoteEnsure that Remix's compiler version matches the one in your contract. You can find your contract's compiler version at the top of your contract's file. It looks like this:pragma solidity ^0.8.2;You can easily select the right compiler version in Remix's the \"Solidity compiler\" menu.\nDeploy the smart contract to a local Ethereum chain​\nOnce a smart contract gets compiled, it is deployable to a blockchain. The safest way to do this is to deploy it to a locally hosted chain, where you can test and debug your contract before deploying it to a public chain.\nTo deploy our VendingMachine smart contract locally, we will:\n\nRun Foundry's local Ethereum node in a terminal window\nConfigure a wallet so we can interact with our smart contract after deployment (1)\nDeploy our smart contract to (1)'s node using Remix\n\nRun a local chain​\nHere, we'll use Foundry's anvil to run a local Ethereum network and node.\ncurl -L https://foundry.paradigm.xyz | bash && anvil\nOnce you've run the above commands, you should see a prompt showing what test accounts automatically were generated for you and other infos about your local Anvil testnet. (_) | | __ _ _ __ __ __ _ | | / _` | | '_ \\ \\ \\ / / | | | | | (_| | | | | | \\ V / | | | | \\__,_| |_| |_| \\_/ |_| |_| 0.2.0 (7f0f5b4 2024-08-08T00:19:07.020431000Z) https://github.com/foundry-rs/foundry# Available Accounts(0) 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 (10000.000000000000000000 ETH)(1) 0x70997970C51812dc3A010C7d01b50e0d17dc79C8 (10000.000000000000000000 ETH)(2) 0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC (10000.000000000000000000 ETH)(3) 0x90F79bf6EB2c4f870365E785982E1f101E93b906 (10000.000000000000000000 ETH)(4) 0x15d34AAf54267DB7D7c367839AAf71A00a2C6A65 (10000.000000000000000000 ETH)(5) 0x9965507D1a55bcC2695C58ba16FB37d819B0A4dc (10000.000000000000000000 ETH)(6) 0x976EA74026E726554dB657fA54763abd0C3a0aa9 (10000.000000000000000000 ETH)(7) 0x14dC79964da2C08b23698B3D3cc7Ca32193d9955 (10000.000000000000000000 ETH)(8) 0x23618e81E3f5cdF7f54C3d65f7FBc0aBf5B21E8f (10000.000000000000000000 ETH)(9) 0xa0Ee7A142d267C1f36714E4a8F75612F20a79720 (10000.000000000000000000 ETH)# Private Keys(0) 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80(1) 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d(2) 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a(3) 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6(4) 0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a(5) 0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba(6) 0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e(7) 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356(8) 0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97(9) 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6# WalletMnemonic: test test test test test test test test test test test junkDerivation path: m/44'/60'/0'/0/# Chain ID31337.\nConfigure Metamask​\nNext, open Metamask and create or import a wallet by following the displayed instructions.\nBy default, Metamask will connect to Ethereum's mainnet. To connect to our local \"testnet,\" enable test networks for Metamask by clicking Show/hide test networks.\nNext, click Metamask's network selector dropdown and click the Add Network button. Click Add a network manually and then provide the following information:\n\nNetwork Name: localhost\nNew RPC URL: http://127.0.0.1:8545\nChain ID: 31337\nCurrency Symbol: ETH\n\nAdd Localhost 8545 to Metamask\nYour wallet won't have a balance on your local testnet's node, but you can import one of the test accounts into Metamask to access to 10,000 testnet ETH. Copy the private key of one of the test accounts (it works with or without the 0x prefix, so e.g., 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 or ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80) and import it into Metamask. Metamask will ask you if you want to connect this new account to Remix, to which you should answer \"yes\":\n\nNever share your private keysYour Ethereum Mainnet wallet's private key is the password to all of your tokens. Never share it with anyone; avoid copying it to your clipboard.\nNote that in the context of this quickstart, \"account\" refers to an EOA (externally owned account), and its associated private key5.\nYou should see a balance of 10,000 ETH. Keep your private key handy; we'll use it again shortly.\nAs we interact with our cupcake vending machine, we'll use Metamask's network selector dropdown to choose which network our cupcake transactions get sent to. We'll leave the network set to Localhost 8545 for now.\nConnect Remix to Metamask​\nIn the last step, we'll connect Remix to Metamask so we can deploy our smart contract to the local chain using Remix.\nConnect remix to Metamask\nAt this point, we're ready to deploy our smart contract to any chain we want.\nDeploy the smart contract to your local chain​\n\nIn MetaMask, ensure that the Localhost network is selected.\nIn Remix, deploy the VendingMachine contract to the Localhost network, then go to the \"Deploy & Run Transactions\" tab and click \"Deploy.\"\n\nDeploy the VendingMachine contract to the Localhost network\nThen copy and paste your contract address below and click Get cupcake!. A prompt should ask you to sign a transaction that gives you a cupcake.\nFree Cupcakesweb3-localhostMetamask wallet addressContract addressRefresh balance🧁Cupcake balance:0 (no name)\nWhat's going on, here?​\nOur first VendingMachine is labeled \"Web2\" because it demonstrates traditional client-server web application architecture: the back-end lives in a centralized network of servers.\n\nThe \"Web3\" architecture is similar to the \"Web2\" architecture, with one key difference: with the \"Web3\" version, business logic and data are hosted by decentralized network of nodes**\nLet's take a closer look at the differences between our VendingMachine implementations:\nWEB2(the first one)WEB3-LOCALHOST(the latest one)WEB3-ARB-SEPOLIA(the next one)WEB3-ARB-MAINNET(the final one)Data (cupcakes)Stored only in your browser. (Usually, stored by centralized infrastructure.)Stored on your device in an emulated Ethereum network (via smart contract).Stored on Ethereum's decentralized test network (via smart contract).Stored on Ethereum's decentralized mainnet network (via smart contract).Logic (vending)Served from Offchain's servers. Executed by your browser.Stored and executed by your locally emulated Ethereum network (via smart contract).Stored and executed by Arbitrum's decentralized test network (via smart contract).Stored and executed by Arbitrum's decentralized mainnet network (via smart contract).Presentation (UI)Served from Offchain's servers. Rendered and executed by your browser.← same← same← sameMoneyDevs and users pay centralized service providers for server access using fiat currency.← same, but only for the presentation-layer concerns (code that supports frontend UI/UX).← same, but devs and users pay testnet ETH to testnet validators.← same, but instead of testnet ETH, they use **mainnet **ETH****.\nSo far, we've deployed our \"Web3\" app to an emulated blockchain (Anvil), which is a normal step in EVM development.\nNext, we'll deploy our smart contract to a network of real nodes: Arbitrum's Sepolia testnet.\nDeploy the smart contract to the Arbitrum Sepolia testnet​\nWe were able to deploy to a testnet for free because we were using Remix's built-in network, but now we'll deploy our contract to Arbitrum's Sepolia testnet.\nSepolia is powered by a network of nodes ran across the world by various participants, we'll need to compensate them with a small transaction fee in order to deploy our smart contract.\nTo be able to pay the transaction fee, we will:\n\nUse our MetaMask crypto wallet\nObtain some Arbitrum Sepolia testnet's token called ETH.\n\nClick Metamask's Network selector dropdown, and then click the Add Network button. Click Add a network manually and then provide the following information:\n\nNetwork Name: Arbitrum Sepolia\nNew RPC URL: https://sepolia-rollup.arbitrum.io/rpc\nChain ID: 421614\nCurrency Symbol: ETH\n\nAs we interact with the cupcake vending machine, we'll use Metamask's network selector dropdown to determine which network our cupcake transactions are sent to.\nNext, let's deposit some ETH into the wallet corresponding to the private key we added to Remix. At the time of this quickstart's writing, the easiest way to acquire ETH is to bridge Sepolia ETH from Ethereum's parent chain Sepolia network to Arbitrum's child chain Sepolia network:\n\nUse a parent chain Sepolia ETH faucet like sepoliafaucet.com to acquire some testnet ETH on parent chain Sepolia.\nBridge your parent chain Sepolia ETH into Arbitrum child chain using the Arbitrum bridge.\n\nOnce you've acquired some ETH, you'll be able to deploy your smart contract to Arbitrum's Sepolia testnet.\nYou can proceed exactly as with the local testnet.\n\nConnect Remix to the Arbitrum Sepolia testnet\nCompile your vending machine contract\nDeploy your vending machine contract to the Arbitrum Sepolia testnet\n\nIn this last step, your compiled smart contract will be deployed through the RPC endpoint corresponding to \"Arbitrum Sepolia\" in MetaMask (MetaMask uses INFURA's nodes as endpoints).\nCongratulations! You've just deployed business logic and data to Arbitrum Sepolia. This logic and data will be hashed and submitted within a transaction to Ethereum's parent chian Sepolia network, and then it will be mirrored across all nodes in the Sepolia network6.\nTo view your smart contract in a blockchain explorer, visit https://sepolia.arbiscan.io/address/0x...B3, but replace the 0x...B3 part of the URL with the full address of your deployed smart contract.\nSelect Arbitrum Sepolia from Metamask's dropdown, paste your contract address into the VendingMachine below, and click Get cupcake!. You should be prompted to sign a transaction that gives you a cupcake.\nFree Cupcakesweb3-arb-sepoliaMetamask wallet addressContract addressRefresh balance🧁Cupcake balance:0 (no name)\nThe final step is deploying our Cupcake machine to a production network, such as Ethereum, Arbitrum One, or Arbitrum Nitro.\nThe good news is: deploying a smart contract in production is exactly the same as for Sepolia Testnet.\nThe harder news: it will cost real money, this time. If you deploy on Ethereum, the fees can be significant and the transaction confirmation time 12 seconds on average.\nArbitrum, a child chain, reduces these costs about 10X and a confirmation time in the same order while maintaining a similar level of security and decentralization. For an in-depth look at how fees are calculated and estimated, see How to estimate gas.\nSummary​\nIn this quickstart, we:\n\nIdentified two business rules: 1) fair and permissionless cupcake distribution 2) immutable business logic and data.\nIdentified a challenge: These rules are difficult to follow in a centralized application.\nIdentified a solution: Using Arbitrum, we can decentralize business logic and data.\nConverted a vending machine's Javascript business logic into a Solidity smart contract.\nDeployed our smart contract to a local development network, and then Arbitrum's Sepolia testnet.\n\nIf you have any questions or feedback, reach out to us on Discord and/or click the Request an update button at the top of this page—we're listening!\nLearning resources​\nFor a list of learning resources, repositories, and useful information about Solidity, see the Solidity references page.\n\nFootnotes​\n\nThe vending machine example was inspired by Ethereum.org's \"Introduction to Smart Contracts\", which was inspired by Nick Szabo's \"From vending machines to smart contracts\". ↩\n\nAlthough application front-ends are usually hosted by centralized services, smart contracts allow the underlying logic and data to be partially or fully decentralized. These smart contracts are hosted and executed by Ethereum's public, decentralized network of nodes. Arbitrum has its own network of nodes that use advanced cryptography techniques to \"batch process\" Ethereum transactions and then submit them to the Ethereum parent chain, which significantly reduces the cost of using Ethereum. All without requiring developers to compromise on security or decentralization. ↩\n\nThere are multiple types of Ethereum nodes. The ones that earn ETH for processing and validating transactions are called validators. See Nodes and Networks for a beginner-friendly introduction to Ethereum's node types. ↩\n\nWhen our VendingMachine contract is deployed to Ethereum, it'll be hosted by Ethereum's decentralized network of nodes. Generally speaking, we won't be able to modify the contract's code after it's deployed. ↩\n\nTo learn more about how Ethereum wallets work, see Ethereum.org's introduction to Ethereum wallets. ↩\n\nVisit the Gentle Introduction to Arbitrum for a beginner-friendly introduction to Arbitrum's Rollup protocol. ↩\n\nWhat we'll learnPrerequisitesEthereum and Arbitrum in a nutshellReview the Javascript vending machineReview the Solidity vending machineCompile your smart contract with Remix1. Load Remix: https://remix.ethereum.org2. Create a blank workspace in Remix:3. Copy your vending machine contract4. Paste your contract in Remix5. Compile your contract in RemixDeploy the smart contract to a local Ethereum chainRun a local chainConfigure MetamaskConnect Remix to MetamaskDeploy the smart contract to your local chainWhat's going on, here?Deploy the smart contract to the Arbitrum Sepolia testnetSummaryLearning resources","tokens":7577,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263789603,"hash":"6fcde686fc78a9b716600ee69b90f18700fa0dd7"}
{"url":"https://ethresear.ch/t/linearly-homomorphic-signatures-for-rlnc/24072","domain":"ethresear.ch","title":"Linearly-homomorphic signatures for RLNC - Cryptography - Ethereum Research","text":"Linearly-homomorphic signatures for RLNC \n\n Cryptography\n\n networking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 6\n\n 1 / 3\n\n Feb 6\n\n Mar 5\n\n post by arantxazapico on Feb 6\n\n arantxazapico\n\n Authors: Dan Boneh, @b-wagn, @arantxazapico\nWe thank Gottfried Herold for dicussion and feedback.\nIntro: RLNC for Ethereum\nAs suggested in this post, Ethereum can benefit from Random Linear Network Coding (RLNC) to speed up the network. This approach avoids sending full blocks during propagation, thereby significantly reducing the amount of data in transit. This will work as follows:\nThe Block Proposer P_{prop}𝑃𝑝𝑟𝑜𝑝 can parse the block as a matrix \\mathbf{M}=(\\vec{m}_1,\\ldots,\\vec{m}_N)\\in(\\mathbb{F}^M)^N.𝐌 =(⃗𝑚1,…,⃗𝑚𝑁) ∈(𝔽𝑀)𝑁. Instead of distributing the entire block, it can send N𝑁 linearly independent vectors in the subspace A𝐴 generated by the columns of the matrix. That is, vectors of the form \\vec{v}= \\mathbf{M} \\cdot \\vec{a} \\in \\mathbb{F}^M⃗𝑣 =𝐌 ⋅⃗𝑎 ∈𝔽𝑀 for some \\vec{a}\\in \\mathbb{F}^N⃗𝑎 ∈𝔽𝑁. Along with each vector \\vec{v} \\in \\mathbb{F}^M⃗𝑣 ∈𝔽𝑀 the proposer P_{prop}𝑃𝑝𝑟𝑜𝑝 sends:\n\nthe coefficients vector \\vec{a} \\in \\mathbb{F}^N⃗𝑎 ∈𝔽𝑁,\nsuccinct homomorphic commitments\n\n \\vec{\\mathsf{C}} = (\\mathsf{C}_1,\\ldots,\\mathsf{C}_N)⃗𝖢 =(𝖢1,…,𝖢𝑁) to the vectors \\vec{m}_1,\\ldots,\\vec{m}_N \\in \\mathbb{F}^M⃗𝑚1,…,⃗𝑚𝑁 ∈𝔽𝑀 respectively, and\na BLS signature \\sigma𝜎 on the tuple (\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}})(⃗𝑣,⃗𝑎,⃗𝖢) using P_{prop}𝑃𝑝𝑟𝑜𝑝's secret key.\n\nThis way, P_{prop}𝑃𝑝𝑟𝑜𝑝 sends (\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}}, \\sigma)(⃗𝑣,⃗𝑎,⃗𝖢,𝜎) to each peer in its mesh, which is only (M + N)(𝑀 +𝑁) field elements plus N𝑁 commitments and a signature, instead of the entire block \\mathbf{M}𝐌 and a signature on its header.\nOn input (\\mathsf{pk},\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}},\\sigma)(𝗉𝗄,⃗𝑣,⃗𝑎,⃗𝖢,𝜎), the Receiving peers verify the signature w.r.t. \\mathsf{pk}𝗉𝗄, and can verify \\vec v⃗𝑣 is indeed in the subspace signed by P_{prop}𝑃𝑝𝑟𝑜𝑝 and vector \\vec a⃗𝑎 contains the correct coefficients by checking\n\n\\mathsf{Commit}(\\vec{v})= \\sum_{j=1}^N a_i \\mathsf{C}_i \n𝖢𝗈𝗆𝗆𝗂𝗍(⃗𝑣)=𝑁∑𝑗=1𝑎𝑖𝖢𝑖\nUpon receiving k𝑘 tuples \\bigl\\{(\\mathsf{pk}_i,\\vec{v}_i, \\vec{a}_i, \\vec{\\mathsf{C}}_i,\\sigma_i)\\bigr\\}_{i=1}^k{(𝗉𝗄𝑖,⃗𝑣𝑖,⃗𝑎𝑖,⃗𝖢𝑖,𝜎𝑖)}𝑘𝑖=1 and after verifying that all the vectors \\vec{v}_1,\\ldots,\\vec{v}_k⃗𝑣1,…,⃗𝑣𝑘 are in A𝐴 and the correctness of the vectors \\vec a_i⃗𝑎𝑖, peer P𝑃 can become a Sending Peer. Let \\mathbf{V} \\in \\mathbb{F}^{M \\times k}𝐕 ∈𝔽𝑀×𝑘 be the matrix whose columns are \\vec{v}_1,\\ldots,\\vec{v}_k⃗𝑣1,…,⃗𝑣𝑘, and let \\mathbf{A} \\in \\mathbb{F}^{N \\times k}𝐀 ∈𝔽𝑁×𝑘 be the matrix whose columns are \\vec{a}_1,\\ldots,\\vec{a}_k⃗𝑎1,…,⃗𝑎𝑘. Since the received tuples are valid, we know that\n \\mathbf{V} = \\mathbf{M} \\cdot \\mathbf{A}. \\tag{1}𝐕 =𝐌 ⋅𝐀.\nThe peer samples a new vector \\vec{r} \\in\\mathbb{F}^k⃗𝑟 ∈𝔽𝑘, sets\n\n\\vec{v}' = \\mathbf{V} \\cdot \\vec{r} \\in \\mathbb{F}^{M} \\qquad\\text{and}\\qquad \\vec{a}' = \\mathbf{A} \\cdot \\vec{r} \\in \\mathbb{F}^{N},\n⃗𝑣′=𝐕⋅⃗𝑟∈𝔽𝑀and⃗𝑎′=𝐀⋅⃗𝑟∈𝔽𝑁,\nand sends (\\mathsf{pk},\\vec{v}', \\vec{a}', \\vec{\\mathsf{C}},\\sigma)(𝗉𝗄,⃗𝑣′,⃗𝑎′,⃗𝖢,𝜎) to its peers. Observe that \\vec{v}' = \\mathbf{M} \\cdot \\vec{a}'⃗𝑣′ =𝐌 ⋅⃗𝑎′, as required for a valid broadcast (indeed, we simply multiplied both sides of (1)(1) by \\vec{r}⃗𝑟).\nAfter receiving N𝑁 linearly independent vectors \\vec v_1, \\ldots, \\vec v_N \\in \\mathbb{F}^M⃗𝑣1,…,⃗𝑣𝑁 ∈𝔽𝑀 with corresponding vectors of coefficients \\vec b_1, \\ldots, \\vec b_N \\in \\mathbb{F}^N⃗𝑏1,…,⃗𝑏𝑁 ∈𝔽𝑁 such that \\vec v_i=\\sum_{i=1}^N b_{ij}\\vec m_j⃗𝑣𝑖 =∑𝑁𝑖=1𝑏𝑖𝑗⃗𝑚𝑗 for all i=1,\\ldots.N𝑖 =1,….𝑁, the receiver P𝑃 can be a Reconstructor and use those linear combinations to recover (\\vec m_1, \\ldots, \\vec m_N)(⃗𝑚1,…,⃗𝑚𝑁) and thus the entire block \\mathbf{M}𝐌.\nAs noted in the original post, the communication problem with this approach is twofold: each new vector in A𝐴 travels along with N𝑁 commitments and N𝑁 coefficients.\nIn this post, we explain how Linearly-homomorphic Signatures and in particular the work of Boneh, Freeman, Katz, and Waters (BFKW) from 2008 can prevent the communication of multiple commitments across the peers.\nDisclaimer:The ideas we present below already exist in the literature or have appeared in previous ethresearch discussions. We do not claim scientific novelty. Our goal is to collect and summarize these ideas in one place, to save others from repeatedly rediscovering the same techniques through scattered chats and threads.\nLinearly-homomorphic Signatures\nA Linearly-homomorphic signature scheme (LHSS) is a signing scheme for which only the secret key owner can create signatures on fresh vectors of its choice. Any entity with access to the public key can combine these signatures to create just one that verifies with respect to any linear combination of the original ones, that is, can sign any vector in the subspace generated by the original messages. Formally:\nDefinition (Boneh et al., 2008): A linearly homomorphic signature scheme (LHSS) over a vector space A\\subseteq\\mathbb{F}^N𝐴 ⊆𝔽𝑁 is a tuple of probabilistic, polynomial-time algorithms (\\mathsf{Setup, Sign, Combine, Verify})(𝖲𝖾𝗍𝗎𝗉,𝖲𝗂𝗀𝗇,𝖢𝗈𝗆𝖻𝗂𝗇𝖾,𝖵𝖾𝗋𝗂𝖿𝗒) with the following functionality:\n\n\\mathsf{Setup}(n, pp)\\to(\\mathsf{sk,pk})𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) →(𝗌𝗄,𝗉𝗄): On input a security parameter n𝑛 and additional public parameters pp𝑝𝑝 that include the dimension N𝑁 of the ambient space and the dimension k𝑘 of subspaces to be signed, this algorithm outputs a secret key \\mathsf{sk}𝗌𝗄 and a public key \\mathsf{pk}𝗉𝗄.\n\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m)\\to\\sigma𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚) →𝜎: On input a secret key \\mathsf{sk}𝗌𝗄, an identifier \\mathsf{id}\\in\\{0, 1\\}^n𝗂𝖽 ∈{0,1}𝑛, and a vector \\vec m\\in A,⃗𝑚 ∈𝐴, this algorithm outputs a signature \\sigma𝜎.\n\\mathsf{Combine}(\\mathsf{pk}, \\mathsf{id}, \\{(a_i, \\sigma_i)\\}_{i=1}^k)\\to\\sigma𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{(𝑎𝑖,𝜎𝑖)}𝑘𝑖=1) →𝜎: On input a public key \\mathsf{pk}𝗉𝗄, an identifier \\mathsf{id}𝗂𝖽, and a set of tuples \\{(a_i, \\sigma_i)\\}_{i=1}^k{(𝑎𝑖,𝜎𝑖)}𝑘𝑖=1 with a_i\\in\\mathbb{F}𝑎𝑖 ∈𝔽, this algorithm outputs a signature \\sigma𝜎. (This \\sigma𝜎 is intended to be a signature on \\sum_{i=1}^k a_i \\vec m_i∑𝑘𝑖=1𝑎𝑖⃗𝑚𝑖.)\n\\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ)\\to1/0𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎) →1/0: On input a public key \\mathsf{pk}𝗉𝗄, an identifier \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛, a vector \\vec v\\in A⃗𝑣 ∈𝐴, and a signature \\sigma𝜎, this algorithm outputs either 00 (reject) or 11 (accept).\n\nFor completeness, we require that for each (\\mathsf{sk, pk})(𝗌𝗄,𝗉𝗄) output by \\mathsf{Setup}(n, pp)𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝), we have that:\n\nFor all \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 and \\vec v\\in A⃗𝑣 ∈𝐴, if \\sigma\\gets\\mathsf{Sign}(\\mathsf{sk, id}, \\vec v)𝜎 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑣) then \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎) =1.\nFor all \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 and all sets of triples \\{(a_i, \\sigma_i, \\vec v_i)\\}_{i=1}^k{(𝑎𝑖,𝜎𝑖,⃗𝑣𝑖)}𝑘𝑖=1 if it holds that \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec m_i, σ_i)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑚𝑖,𝜎𝑖) =1 for all i \\in [k]𝑖 ∈[𝑘], then \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id}, \\sum_{i=1}^\\ell a_i \\vec m_i, \\mathsf{Combine}(\\mathsf{pk}, \\mathsf{id}, \\{a_i, \\sigma_i)\\}_{i=1}^k)= 1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,∑ℓ𝑖=1𝑎𝑖⃗𝑚𝑖,𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{𝑎𝑖,𝜎𝑖)}𝑘𝑖=1) =1.\n\nThe security notion we need to capture here is that no party other than the \\mathsf{sk}𝗌𝗄 holder should be able to claim a signature \\sigma^*𝜎∗ on a vector \\vec v^*⃗𝑣∗ that verifies with respect to \\mathsf{pk}𝗉𝗄 unless \\vec v^*\\in A⃗𝑣∗ ∈𝐴 . Therefore, we define the following game between a challenger and an adversary:\n\nSetup Phase. The challenger runs (\\mathsf{sk,pk})\\gets\\mathsf{Setup}(n, pp)(𝗌𝗄,𝗉𝗄) ←𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) and sends \\mathsf{pk}𝗉𝗄 to the adversary \\mathcal{A}.A.\nQuery Phase. The adversary now makes a polynomial number q𝑞 of oracle queries, where the i𝑖-th query has the following form:\n\nThe oracle takes as input a set of vectors \\vec{v}_{i,1},\\dots,\\vec{v}_{i,k} \\in \\mathbb{F}^M⃗𝑣𝑖,1,…,⃗𝑣𝑖,𝑘 ∈𝔽𝑀.\nWe let A_i \\subseteq \\mathbb{F}^N𝐴𝑖 ⊆𝔽𝑁 be the subspace generated by these vectors.\nThe oracle samples \\mathsf{id}\\gets \\{0,1\\}^n𝗂𝖽 ←{0,1}𝑛, and computes \\sigma_{i,j}\\gets\\mathsf{Sign}(\\mathsf{sk}, \\mathsf{id}_i, \\vec{v}_{i,j})𝜎𝑖,𝑗 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽𝑖,⃗𝑣𝑖,𝑗) for all j=1, \\ldots, k𝑗 =1,…,𝑘.\nIt outputs (\\mathsf{id}_i, (\\sigma_{i,j})_{j=1}^k)(𝗂𝖽𝑖,(𝜎𝑖,𝑗)𝑘𝑗=1).\n\nForgery Phase. The adversary outputs a triple (\\mathsf{id}^*, \\vec v^*\\neq 0, \\sigma^*)(𝗂𝖽∗,⃗𝑣∗ ≠0,𝜎∗). We say that it wins the game if the following two hold:\n\nValid signature: we have \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id}^*,\\vec v^*, \\sigma^*)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽∗,⃗𝑣∗,𝜎∗) =1;\nFreshness: we have \\mathsf{id}^*\\notin\\{\\mathsf{id}_i\\}_{i=1}^q𝗂𝖽∗ ∉{𝗂𝖽𝑖}𝑞𝑖=1 or \\vec v^*\\notin A_i⃗𝑣∗ ∉𝐴𝑖 for every i\\in [q]𝑖 ∈[𝑞] with \\mathsf{id}^* = \\mathsf{id}_i𝗂𝖽∗ =𝗂𝖽𝑖.\n\nThe scheme is secure if no efficient (i.e., PPT) adversary wins this game with non-negligible probability.\nIntuitively, this security property states that any signature that verifies with respect to the given public key \\mathsf{pk}𝗉𝗄 and an identity \\mathsf{id}^*𝗂𝖽∗, must be on a vector in the span of the vectors that the honest signer signed with respect to \\mathsf{id}^*𝗂𝖽∗.\nLinearly-homomorphic Signatures in RLNC\nBelow, we explain how the BFKW Linearly-homomorphic Signature scheme can be used to replace commitments in the RLNC protocol.\nThe block proposer owns the secret key \\mathsf{sk}𝗌𝗄 and thus is the only one that can create “fresh” signatures. In this setting, we require that they parse the block as a matrix and sign the columns of it.\nThat means the proposer gets to set the subspace A𝐴. All other users can combine those signatures to create signatures on linear combinations of the vectors that define the block (by the completeness property).\nBy the security property, if a signature verifies with respect to the block proposer’s public key, it is then a linear combination of the original signatures, and thus a signature on a linear combination of the original vectors.\nTo generate new coefficients, or even to reconstruct the original vectors after receiving N𝑁 linearly-independent vectors, peer P𝑃 has access to the new signature \\sigma𝜎 and a set of coefficients \\vec a⃗𝑎 that the sender claims to be the coefficients that combine the original signatures \\sigma_1, \\ldots, \\sigma_N𝜎1,…,𝜎𝑁 to \\sigma𝜎. The receiving peer needs to verify not only that \\sigma𝜎 is a linear combination of the block proposer’s signatures, which is true iff \\mathsf{Verify}𝖵𝖾𝗋𝗂𝖿𝗒 outputs 11, but also that the coefficients of that linear combination are indeed the ones in \\vec b⃗𝑏.\nIn order to verify each signatures with respect to the specific coefficients that conform the linear combination, we formally extend the functionality of LHS schemes by slightly modifying its syntax as hinted in the seminal work:\n\n\\mathsf{RLNC}.\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m_i, i):𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚𝑖,𝑖) : Let \\vec e_i\\in\\mathbb{F}^N⃗𝑒𝑖 ∈𝔽𝑁 be the unity vector that takes value 11 in the position i𝑖 and 00 everywhere else (that is, is the i𝑖-th vector in the canonical basis of \\mathbb{F}^N𝔽𝑁) and output \\sigma\\gets\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m_i|| \\vec e_i)𝜎 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚𝑖||⃗𝑒𝑖)\n\\mathsf{RLNC}.\\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, \\sigma, \\vec a)\\to1/0𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎) →1/0: Set \\vec v'=\\vec v|| \\vec a⃗𝑣′ =⃗𝑣||⃗𝑎 and output \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v', \\sigma)𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣′,𝜎)\n\nEssentially, by adding the vector \\vec e_i⃗𝑒𝑖 to the message \\vec m_i⃗𝑚𝑖, we will have that the last N𝑁 elements of any signed vector \\vec v⃗𝑣 will be the unique coefficients that represent \\vec v⃗𝑣 as a linear combination of the messages \\{\\vec m_i\\}{⃗𝑚𝑖} signed by the \\mathsf{sk}𝗌𝗄 holder. Intuitively, by the unforgeability property of the LHSS, if the \\mathsf{Verify}𝖵𝖾𝗋𝗂𝖿𝗒 algorithm outputs 11 on input \\vec v, \\vec a⃗𝑣,⃗𝑎, then \\vec v=\\sum a_i \\vec m_i⃗𝑣 =∑𝑎𝑖⃗𝑚𝑖 except with negligible probability.\nThreat Model\nWhen implementing RLNC for block propagation, we assume an honest block proposer and set aside general networking attacks. Still, the system must remain resilient against Denial of Service (DoS) attacks—specifically pollution attacks. In this scenario, an adversary attempts to disrupt the propagation of block \\mathbf M𝐌 by injecting a malicious vector \\vec v′\\notin A⃗𝑣 ′ ∉𝐴, with A𝐴 being the subspace defined by the original block data. This is covered by the security property of LHS, that requests that no adversary can generate valid signatures for vectors that are not in A𝐴.\nThe inclusion of a string \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 within the signature serves as a unique identifier for a specific subspace. This allows a participant to sign multiple subspaces using the same public key while preventing vectors from different spaces from being combined, e.g., if this participant takes the role of the block proposer in multiple slots. Specifically, if a user signs subspace V_1𝑉1 at time t_1𝑡1 and subspace V_2𝑉2 at time t_2𝑡2, no party should be able to forge signatures on vectors in \\mathsf{span}(V_1\\cup V_2)𝗌𝗉𝖺𝗇(𝑉1 ∪𝑉2) that verify against \\mathsf{pk}𝗉𝗄. While the BFKW protocol requires \\mathsf{id}𝗂𝖽 to be unpredictable, the block propagation setting further requires \\mathsf{id}𝗂𝖽 to be tied to a specific block. To satisfy both conditions, we set \\mathsf{id}=H(\\mathsf{num_{slot}},\\mathsf{salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍), where \\mathsf{salt}𝗌𝖺𝗅𝗍 is sampled randomly by the proposer during signing, H𝐻 is a hash function (modeled as a random oracle), and \\mathsf{num_{slot}}𝗇𝗎𝗆𝗌𝗅𝗈𝗍 is the slot number of the proposed block.\nThe BFKW scheme for RLNC\nWe present the linearly-homomorphic signature scheme in BFKW with the new RLNC-specific syntax. Note that BFKW works similarly to BLS signatures that are already implemented in Ethereum. The main difference is that instead of signing messages, the users sign vectors and thus compute M𝑀 hashes per signature (where M𝑀 is the dimension of the vectors) instead of one. Consider a bilinear group (\\mathbb{G}_1,\\mathbb{G}_2, \\mathbb{G}_T, p, e)(𝔾1,𝔾2,𝔾𝑇,𝑝,𝑒), g_1, g_2𝑔1,𝑔2 generators of \\mathbb{G}_1𝔾1 and \\mathbb{G}_2𝔾2, respectively, and a hash function H:\\{0,1\\}^*\\times \\{0,1\\}^*\\to \\mathbb{G}_2𝐻 :{0,1}∗ ×{0,1}∗ →𝔾2 modeled as a random oracle.\n\n\\mathsf{RLNC.Setup}(n, pp)\\to(\\mathsf{sk,pk})𝖱𝖫𝖭𝖢.𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) →(𝗌𝗄,𝗉𝗄): Sample \\mathsf{sk}\\gets\\mathbb{F}𝗌𝗄 ←𝔽, set \\mathsf{pk}=g_1^{\\mathsf{sk}}𝗉𝗄 =𝑔𝗌𝗄1.\nLet A=\\mathsf{span}\\{\\vec m_1,\\ldots, \\vec m_N\\}, \\vec m_i\\in\\mathbb{F}^M𝐴 =𝗌𝗉𝖺𝗇{⃗𝑚1,…,⃗𝑚𝑁},⃗𝑚𝑖 ∈𝔽𝑀.\n\\mathsf{RLNC.Sign}(\\mathsf{sk, id}, \\vec m, N)\\to\\sigma𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚,𝑁) →𝜎:\n\nSet \\vec m'=\\vec m || \\vec e_i⃗𝑚′ =⃗𝑚||⃗𝑒𝑖 for \\vec e_i\\in\\mathbb{F}^N⃗𝑒𝑖 ∈𝔽𝑁 being the i𝑖-th unity vector and i𝑖 the position of \\vec m⃗𝑚 in the ordered basis of A𝐴.\nOutput \\sigma\\in\\mathbb{G}_2𝜎 ∈𝔾2 as follows:\n\n\\sigma=\\left(\\prod\\limits_{s=1}^M H(\\mathsf{id},s)^{m'_{s}}\\right)^{\\mathsf{sk}}\n𝜎=(𝑀∏𝑠=1𝐻(𝗂𝖽,𝑠)𝑚′𝑠)𝗌𝗄\n\n\\mathsf{RLNC.Combine}(\\mathsf{pk}, \\mathsf{id}, \\{(a_i, \\sigma_i, \\vec v_i)\\}_{i=1}^k)\\to(\\vec v, \\sigma, \\vec a)𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{(𝑎𝑖,𝜎𝑖,⃗𝑣𝑖)}𝑘𝑖=1) →(⃗𝑣,𝜎,⃗𝑎):\n\\vec v=\\sum_{i=1}^k a_i\\vec v_i, \\qquad \\sigma=\\prod_{i=1}^k \\sigma_i^{a_i}\n⃗𝑣=𝑘∑𝑖=1𝑎𝑖⃗𝑣𝑖,𝜎=𝑘∏𝑖=1𝜎𝑎𝑖𝑖\n\n\\mathsf{RLNC.Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ, \\vec a)\\to1/0𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎) →1/0:\n\nSet \\vec v'=\\vec v||\\vec a⃗𝑣′ =⃗𝑣||⃗𝑎\nOutput 11 if and only if\n\ne\\big(g_1, \\sigma\\big)=e\\left(pk, \\prod_{s=1}^M H(\\mathsf{id}, s)^{v'_s}\\right)\n𝑒(𝑔1,𝜎)=𝑒(𝑝𝑘,𝑀∏𝑠=1𝐻(𝗂𝖽,𝑠)𝑣′𝑠)\n\nSecurity: The protocol presented above is complete and secure in the random oracle model under the co-computational Diffie Hellman (co-CDH) assumption in (\\mathbb{G}_1, \\mathbb{G}_2)(𝔾1,𝔾2). The co-CDH assumption in (\\mathbb{G}_1, \\mathbb{G}_2)(𝔾1,𝔾2) states that it is computationally infeasible to compute g_1^x\\in\\mathbb{G}_1𝑔𝑥1 ∈𝔾1 given g_1\\in\\mathbb{G}_1𝑔1 ∈𝔾1 and g_2, g_2^x\\in\\mathbb{G}_2𝑔2,𝑔𝑥2 ∈𝔾2.\n\nRLNC with Linearly-homomorphic Signatures\nThe result of replacing homomorphic commitments by the linearly-homomophic signature scheme of BFKW in the protocol proposed here is the following:\nProposer\nProposer’s key pair is (sk, pk=g_2^{sk})(𝑠𝑘,𝑝𝑘 =𝑔𝑠𝑘2). On input block \\mathbf{M}\\in\\mathbb{F}^{M\\times N}𝐌 ∈𝔽𝑀×𝑁, the proposer samples \\mathsf{salt}\\gets\\{0,1\\}^n𝗌𝖺𝗅𝗍 ←{0,1}𝑛 and sets \\mathsf{id}=H(\\mathsf{num_{slot}},\\mathsf{salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍).\n\nFor each i\\in[N]:𝑖 ∈[𝑁] :\n\n\\sigma_i\\gets \\mathsf{RLNC.Sign}(sk, \\mathsf{id}, \\vec m_i, i):𝜎𝑖 ←𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝑠𝑘,𝗂𝖽,⃗𝑚𝑖,𝑖) :\n\nFor each user u_j\\in D𝑢𝑗 ∈𝐷\n\nSample \\vec a_j\\gets \\mathbb{F}^N⃗𝑎𝑗 ←𝔽𝑁\n\\sigma_j\\gets\\mathsf{RLNC.Combine}(pk, \\mathsf{id}, {(a_{j,i}, \\sigma_i)}_{i=1}^N)𝜎𝑗 ←𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑝𝑘,𝗂𝖽,(𝑎𝑗,𝑖,𝜎𝑖)𝑁𝑖=1)\nSend \\pi_j=(\\mathsf{salt}, \\vec v_j, \\vec a_j, \\sigma_j)𝜋𝑗 =(𝗌𝖺𝗅𝗍,⃗𝑣𝑗,⃗𝑎𝑗,𝜎𝑗), where \\vec v_j=\\sum_{j=1}^N {a_{i,j}} \\vec m_i⃗𝑣𝑗 =∑𝑁𝑗=1𝑎𝑖,𝑗⃗𝑚𝑖\n\nReceiving Peers\n\nParse (\\mathsf{salt}, \\vec v, \\vec a, \\sigma)\\gets \\pi(𝗌𝖺𝗅𝗍,⃗𝑣,⃗𝑎,𝜎) ←𝜋\nOutput b\\gets\\mathsf{RLNC.Verify}(pk, \\mathsf{id}, \\vec v, \\sigma, \\vec a)𝑏 ←𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝑝𝑘,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎)\n\nSending Peers\nOn input (\\pi_1, \\ldots, \\pi_L)(𝜋1,…,𝜋𝐿):\n\nParse (\\mathsf{salt}, \\vec v_i, \\vec a_i, \\sigma_i)\\gets \\pi_i(𝗌𝖺𝗅𝗍,⃗𝑣𝑖,⃗𝑎𝑖,𝜎𝑖) ←𝜋𝑖 for all i\\in [L]𝑖 ∈[𝐿]\nSample \\vec a'\\gets\\mathbb{F}^L⃗𝑎′ ←𝔽𝐿\nCompute \\mathsf{id}=H(\\mathsf{num_{slot}, salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍)\n\\sigma\\gets\\mathsf{RLNC.Combine}(pk, \\mathsf{id}, (a'_i, \\sigma_i)_{i=1}^L)𝜎 ←𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑝𝑘,𝗂𝖽,(𝑎′𝑖,𝜎𝑖)𝐿𝑖=1)\nSet \\vec v=\\sum_{i=1}^L a'_i \\vec v_i⃗𝑣 =∑𝐿𝑖=1𝑎′𝑖⃗𝑣𝑖\nRedefine vector \\vec a⃗𝑎 with a_i=a'_i\\sum_{i=1}^L a_j𝑎𝑖 =𝑎′𝑖∑𝐿𝑖=1𝑎𝑗\nOutput \\pi=(\\vec v, \\vec a, \\sigma)𝜋 =(⃗𝑣,⃗𝑎,𝜎)\n\nOn the efficiency\nBelow we set a comparison with the proposal by Potuz. Note that in the LHS approach, we trade efficiency of P_{prop}𝑃𝑝𝑟𝑜𝑝 and the receiving/sender peers to avoid sending N𝑁 group elements to the network.\n\nProposer:\n\nSigning a message involves computing M𝑀 hashes H𝐻 to \\mathbb{G}_2𝔾2 and then performin M𝑀 group operations in \\mathbb{G}_2𝔾2, whereas in the previous approach involved only M𝑀 group operations for a Pedersen commitment.\n\nReceiver:\n\nVerifying the signature is M𝑀 \\mathbb{G}_1𝔾1 operations and two pairings. Verifying a commitment is 2M2𝑀 \\mathbb{G}𝔾 operations.\n\nSender:\n\nPerforms L\\mathbb{G}_1𝐿𝔾1 operations to compute the new signature in addition to the LM𝐿𝑀 field operations it already performs in the previous approach to compute the new vector \\vec v⃗𝑣.\n\nCommunication:\n\nEach signature is 1\\mathbb{G}_21𝔾2 element, same as the Pedersen commitments. With the previous approach, we have N𝑁 commitments that can be communicated as a sidecar, while in the signature approach we have 11 group element being communicated per time.\n\nReconstruction: Works the same way as before, after receiving N𝑁 linearly-independent vectors and verifying they are indeed in the subspace A𝐴, any node can reconstruct block \\mathbf M𝐌 by solving a system of equations.\n\nPedersen Commitments\nLinearly-Homomorphic Signatures\n\nCommitting(P_{prop}𝑃𝑝𝑟𝑜𝑝) to one vector\nM\\ \\mathbb{G}𝑀 𝔾 ops\nM\\ \\mathbb{G}_2𝑀 𝔾2 ops, M𝑀 hashes to \\mathbb{G}_2𝔾2\n\nReceiver (Verify \\vec v\\in A⃗𝑣 ∈𝐴)\nCommit\nCommit + 22 pairings\n\nSender\nLM\\ \\mathbb{F}𝐿𝑀 𝔽 ops\nLM\\ \\mathbb{F}𝐿𝑀 𝔽 ops, L \\ \\mathbb{G}_2𝐿 𝔾2 ops\n\nCommunication\nN\\ \\mathbb{G}𝑁 𝔾, N\\ \\mathbb{F}𝑁 𝔽\n1\\ \\mathbb{G}_21 𝔾2, N\\ \\mathbb{F}𝑁 𝔽\n\nFuture Work\nA natural extension of this work is the transition toward post-quantum (PQ) security. The BFKW scheme, while efficient, relies on the hardness of the co-CDH problem in bilinear groups, which is susceptible to attacks by large-scale quantum computers. To future proof RLNC-based block propagation, we should explore Linearly Homomorphic Signatures schemes based on post-quantum assumptions.\n\nThere are proposals which suggest that the commitments \\mathsf{C}_1, \\ldots, \\mathsf{C}_N𝖢1,…,𝖢𝑁 and the signature on them can travel the network independently of the newly generated vectors. ↩︎\n\n RLNC Optimizations\n\n Faster block/blob propagation in Ethereum\n\n 2\n\n read \n\n 8\n min\n\n 18 days later\n\n post by MoritzGrundei on Feb 25\n\n 8 days later\n\n post by arantxazapico on Mar 5\n\n Powered by Discourse","tokens":5251,"squid":"ink-research","role":"Deep Scholar","at":1791263791898,"hash":"5d53476a8c723f3e45c2d9bc8f5ad537bea39aa8"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/solidity-support","domain":"docs.arbitrum.io","title":"Solidity support | Arbitrum Docs","text":"✏️Request an updateArbitrum chains are Ethereum-compatible and, therefore, allow you to trustlessly deploy Solidity smart contracts, as well as contracts written in Vyper or any other language that compiles to EVM bytecode. However, when calling certain properties and functions on a Solidity smart contract, there are some differences between the result you'd obtain if that contract were on Ethereum and the result on Arbitrum.\nThis page compiles a list of functions and properties that return a different result when called in Arbitrum.\nDifferences from Solidity on Ethereum​\nAlthough Arbitrum supports Solidity code, there are differences in the effects of a few operations, including language features that don't make sense in the child chain context.\nOperationDescriptionblockhash(x)Returns a cryptographically insecure, pseudo-random hash for x within the range block.number - 256 <= x < block.number. If x is outside of this range, blockhash(x) will return 0. This hash includes blockhash(block.number), which always returns 0 just like on Ethereum. The returned hashes do not come from the parent chain. ⚠️ Arbitrum's child chain block hashes should not be relied on as a secure source of randomness.block.coinbaseReturns the designated internal address 0xA4b000000000000000000073657175656e636572 if a sequencer posted the message. If it's a delayed message, it returns the address of the delayed message's poster (Note: the handling of delayed message's block.coinbase will likely be changed in a future ArbOS version).block.difficultyReturns the constant 1.block.prevrandaoReturns the constant 1.block.numberReturns an \"estimate\" of the block number of the first non-Arbitrum ancestor chain at which the sequencer received the transaction. For more information, see Block numbers and time.msg.senderWorks the same way it does on Ethereum for regular child chain to child chain transactions. For transactions submitted via the delayed inbox, it will return the child chain address alias of the parent chain contract that triggered the message. For more information, see address aliasing. The aliased value also appears in the from field on RPC responses — see RPC methods.OPCODE PUSH0This OPCODE was added as part of ArbOS 11 and is now supported.Differences from Solidity on Ethereum","tokens":574,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263799607,"hash":"c751231169e1d411a4bc664d3631c10a9fb2f42a"}
{"url":"https://ethresear.ch/t/linearly-homomorphic-signatures-for-rlnc/24072/3","domain":"ethresear.ch","title":"Linearly-homomorphic signatures for RLNC - Cryptography - Ethereum Research","text":"Cryptography\n\n networking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 6\n\n 3 / 3\n\n Mar 6\n\n Mar 5\n\n post by arantxazapico on Feb 6\n\n arantxazapico\n\n Authors: Dan Boneh, @b-wagn, @arantxazapico\nWe thank Gottfried Herold for dicussion and feedback.\nIntro: RLNC for Ethereum\nAs suggested in this post, Ethereum can benefit from Random Linear Network Coding (RLNC) to speed up the network. This approach avoids sending full blocks during propagation, thereby significantly reducing the amount of data in transit. This will work as follows:\nThe Block Proposer P_{prop}𝑃𝑝𝑟𝑜𝑝 can parse the block as a matrix \\mathbf{M}=(\\vec{m}_1,\\ldots,\\vec{m}_N)\\in(\\mathbb{F}^M)^N.𝐌 =(⃗𝑚1,…,⃗𝑚𝑁) ∈(𝔽𝑀)𝑁. Instead of distributing the entire block, it can send N𝑁 linearly independent vectors in the subspace A𝐴 generated by the columns of the matrix. That is, vectors of the form \\vec{v}= \\mathbf{M} \\cdot \\vec{a} \\in \\mathbb{F}^M⃗𝑣 =𝐌 ⋅⃗𝑎 ∈𝔽𝑀 for some \\vec{a}\\in \\mathbb{F}^N⃗𝑎 ∈𝔽𝑁. Along with each vector \\vec{v} \\in \\mathbb{F}^M⃗𝑣 ∈𝔽𝑀 the proposer P_{prop}𝑃𝑝𝑟𝑜𝑝 sends:\n\nthe coefficients vector \\vec{a} \\in \\mathbb{F}^N⃗𝑎 ∈𝔽𝑁,\nsuccinct homomorphic commitments\n\n \\vec{\\mathsf{C}} = (\\mathsf{C}_1,\\ldots,\\mathsf{C}_N)⃗𝖢 =(𝖢1,…,𝖢𝑁) to the vectors \\vec{m}_1,\\ldots,\\vec{m}_N \\in \\mathbb{F}^M⃗𝑚1,…,⃗𝑚𝑁 ∈𝔽𝑀 respectively, and\na BLS signature \\sigma𝜎 on the tuple (\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}})(⃗𝑣,⃗𝑎,⃗𝖢) using P_{prop}𝑃𝑝𝑟𝑜𝑝's secret key.\n\nThis way, P_{prop}𝑃𝑝𝑟𝑜𝑝 sends (\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}}, \\sigma)(⃗𝑣,⃗𝑎,⃗𝖢,𝜎) to each peer in its mesh, which is only (M + N)(𝑀 +𝑁) field elements plus N𝑁 commitments and a signature, instead of the entire block \\mathbf{M}𝐌 and a signature on its header.\nOn input (\\mathsf{pk},\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}},\\sigma)(𝗉𝗄,⃗𝑣,⃗𝑎,⃗𝖢,𝜎), the Receiving peers verify the signature w.r.t. \\mathsf{pk}𝗉𝗄, and can verify \\vec v⃗𝑣 is indeed in the subspace signed by P_{prop}𝑃𝑝𝑟𝑜𝑝 and vector \\vec a⃗𝑎 contains the correct coefficients by checking\n\n\\mathsf{Commit}(\\vec{v})= \\sum_{j=1}^N a_i \\mathsf{C}_i \n𝖢𝗈𝗆𝗆𝗂𝗍(⃗𝑣)=𝑁∑𝑗=1𝑎𝑖𝖢𝑖\nUpon receiving k𝑘 tuples \\bigl\\{(\\mathsf{pk}_i,\\vec{v}_i, \\vec{a}_i, \\vec{\\mathsf{C}}_i,\\sigma_i)\\bigr\\}_{i=1}^k{(𝗉𝗄𝑖,⃗𝑣𝑖,⃗𝑎𝑖,⃗𝖢𝑖,𝜎𝑖)}𝑘𝑖=1 and after verifying that all the vectors \\vec{v}_1,\\ldots,\\vec{v}_k⃗𝑣1,…,⃗𝑣𝑘 are in A𝐴 and the correctness of the vectors \\vec a_i⃗𝑎𝑖, peer P𝑃 can become a Sending Peer. Let \\mathbf{V} \\in \\mathbb{F}^{M \\times k}𝐕 ∈𝔽𝑀×𝑘 be the matrix whose columns are \\vec{v}_1,\\ldots,\\vec{v}_k⃗𝑣1,…,⃗𝑣𝑘, and let \\mathbf{A} \\in \\mathbb{F}^{N \\times k}𝐀 ∈𝔽𝑁×𝑘 be the matrix whose columns are \\vec{a}_1,\\ldots,\\vec{a}_k⃗𝑎1,…,⃗𝑎𝑘. Since the received tuples are valid, we know that\n \\mathbf{V} = \\mathbf{M} \\cdot \\mathbf{A}. \\tag{1}𝐕 =𝐌 ⋅𝐀.\nThe peer samples a new vector \\vec{r} \\in\\mathbb{F}^k⃗𝑟 ∈𝔽𝑘, sets\n\n\\vec{v}' = \\mathbf{V} \\cdot \\vec{r} \\in \\mathbb{F}^{M} \\qquad\\text{and}\\qquad \\vec{a}' = \\mathbf{A} \\cdot \\vec{r} \\in \\mathbb{F}^{N},\n⃗𝑣′=𝐕⋅⃗𝑟∈𝔽𝑀and⃗𝑎′=𝐀⋅⃗𝑟∈𝔽𝑁,\nand sends (\\mathsf{pk},\\vec{v}', \\vec{a}', \\vec{\\mathsf{C}},\\sigma)(𝗉𝗄,⃗𝑣′,⃗𝑎′,⃗𝖢,𝜎) to its peers. Observe that \\vec{v}' = \\mathbf{M} \\cdot \\vec{a}'⃗𝑣′ =𝐌 ⋅⃗𝑎′, as required for a valid broadcast (indeed, we simply multiplied both sides of (1)(1) by \\vec{r}⃗𝑟).\nAfter receiving N𝑁 linearly independent vectors \\vec v_1, \\ldots, \\vec v_N \\in \\mathbb{F}^M⃗𝑣1,…,⃗𝑣𝑁 ∈𝔽𝑀 with corresponding vectors of coefficients \\vec b_1, \\ldots, \\vec b_N \\in \\mathbb{F}^N⃗𝑏1,…,⃗𝑏𝑁 ∈𝔽𝑁 such that \\vec v_i=\\sum_{i=1}^N b_{ij}\\vec m_j⃗𝑣𝑖 =∑𝑁𝑖=1𝑏𝑖𝑗⃗𝑚𝑗 for all i=1,\\ldots.N𝑖 =1,….𝑁, the receiver P𝑃 can be a Reconstructor and use those linear combinations to recover (\\vec m_1, \\ldots, \\vec m_N)(⃗𝑚1,…,⃗𝑚𝑁) and thus the entire block \\mathbf{M}𝐌.\nAs noted in the original post, the communication problem with this approach is twofold: each new vector in A𝐴 travels along with N𝑁 commitments and N𝑁 coefficients.\nIn this post, we explain how Linearly-homomorphic Signatures and in particular the work of Boneh, Freeman, Katz, and Waters (BFKW) from 2008 can prevent the communication of multiple commitments across the peers.\nDisclaimer:The ideas we present below already exist in the literature or have appeared in previous ethresearch discussions. We do not claim scientific novelty. Our goal is to collect and summarize these ideas in one place, to save others from repeatedly rediscovering the same techniques through scattered chats and threads.\nLinearly-homomorphic Signatures\nA Linearly-homomorphic signature scheme (LHSS) is a signing scheme for which only the secret key owner can create signatures on fresh vectors of its choice. Any entity with access to the public key can combine these signatures to create just one that verifies with respect to any linear combination of the original ones, that is, can sign any vector in the subspace generated by the original messages. Formally:\nDefinition (Boneh et al., 2008): A linearly homomorphic signature scheme (LHSS) over a vector space A\\subseteq\\mathbb{F}^N𝐴 ⊆𝔽𝑁 is a tuple of probabilistic, polynomial-time algorithms (\\mathsf{Setup, Sign, Combine, Verify})(𝖲𝖾𝗍𝗎𝗉,𝖲𝗂𝗀𝗇,𝖢𝗈𝗆𝖻𝗂𝗇𝖾,𝖵𝖾𝗋𝗂𝖿𝗒) with the following functionality:\n\n\\mathsf{Setup}(n, pp)\\to(\\mathsf{sk,pk})𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) →(𝗌𝗄,𝗉𝗄): On input a security parameter n𝑛 and additional public parameters pp𝑝𝑝 that include the dimension N𝑁 of the ambient space and the dimension k𝑘 of subspaces to be signed, this algorithm outputs a secret key \\mathsf{sk}𝗌𝗄 and a public key \\mathsf{pk}𝗉𝗄.\n\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m)\\to\\sigma𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚) →𝜎: On input a secret key \\mathsf{sk}𝗌𝗄, an identifier \\mathsf{id}\\in\\{0, 1\\}^n𝗂𝖽 ∈{0,1}𝑛, and a vector \\vec m\\in A,⃗𝑚 ∈𝐴, this algorithm outputs a signature \\sigma𝜎.\n\\mathsf{Combine}(\\mathsf{pk}, \\mathsf{id}, \\{(a_i, \\sigma_i)\\}_{i=1}^k)\\to\\sigma𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{(𝑎𝑖,𝜎𝑖)}𝑘𝑖=1) →𝜎: On input a public key \\mathsf{pk}𝗉𝗄, an identifier \\mathsf{id}𝗂𝖽, and a set of tuples \\{(a_i, \\sigma_i)\\}_{i=1}^k{(𝑎𝑖,𝜎𝑖)}𝑘𝑖=1 with a_i\\in\\mathbb{F}𝑎𝑖 ∈𝔽, this algorithm outputs a signature \\sigma𝜎. (This \\sigma𝜎 is intended to be a signature on \\sum_{i=1}^k a_i \\vec m_i∑𝑘𝑖=1𝑎𝑖⃗𝑚𝑖.)\n\\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ)\\to1/0𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎) →1/0: On input a public key \\mathsf{pk}𝗉𝗄, an identifier \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛, a vector \\vec v\\in A⃗𝑣 ∈𝐴, and a signature \\sigma𝜎, this algorithm outputs either 00 (reject) or 11 (accept).\n\nFor completeness, we require that for each (\\mathsf{sk, pk})(𝗌𝗄,𝗉𝗄) output by \\mathsf{Setup}(n, pp)𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝), we have that:\n\nFor all \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 and \\vec v\\in A⃗𝑣 ∈𝐴, if \\sigma\\gets\\mathsf{Sign}(\\mathsf{sk, id}, \\vec v)𝜎 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑣) then \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎) =1.\nFor all \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 and all sets of triples \\{(a_i, \\sigma_i, \\vec v_i)\\}_{i=1}^k{(𝑎𝑖,𝜎𝑖,⃗𝑣𝑖)}𝑘𝑖=1 if it holds that \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec m_i, σ_i)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑚𝑖,𝜎𝑖) =1 for all i \\in [k]𝑖 ∈[𝑘], then \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id}, \\sum_{i=1}^\\ell a_i \\vec m_i, \\mathsf{Combine}(\\mathsf{pk}, \\mathsf{id}, \\{a_i, \\sigma_i)\\}_{i=1}^k)= 1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,∑ℓ𝑖=1𝑎𝑖⃗𝑚𝑖,𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{𝑎𝑖,𝜎𝑖)}𝑘𝑖=1) =1.\n\nThe security notion we need to capture here is that no party other than the \\mathsf{sk}𝗌𝗄 holder should be able to claim a signature \\sigma^*𝜎∗ on a vector \\vec v^*⃗𝑣∗ that verifies with respect to \\mathsf{pk}𝗉𝗄 unless \\vec v^*\\in A⃗𝑣∗ ∈𝐴 . Therefore, we define the following game between a challenger and an adversary:\n\nSetup Phase. The challenger runs (\\mathsf{sk,pk})\\gets\\mathsf{Setup}(n, pp)(𝗌𝗄,𝗉𝗄) ←𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) and sends \\mathsf{pk}𝗉𝗄 to the adversary \\mathcal{A}.A.\nQuery Phase. The adversary now makes a polynomial number q𝑞 of oracle queries, where the i𝑖-th query has the following form:\n\nThe oracle takes as input a set of vectors \\vec{v}_{i,1},\\dots,\\vec{v}_{i,k} \\in \\mathbb{F}^M⃗𝑣𝑖,1,…,⃗𝑣𝑖,𝑘 ∈𝔽𝑀.\nWe let A_i \\subseteq \\mathbb{F}^N𝐴𝑖 ⊆𝔽𝑁 be the subspace generated by these vectors.\nThe oracle samples \\mathsf{id}\\gets \\{0,1\\}^n𝗂𝖽 ←{0,1}𝑛, and computes \\sigma_{i,j}\\gets\\mathsf{Sign}(\\mathsf{sk}, \\mathsf{id}_i, \\vec{v}_{i,j})𝜎𝑖,𝑗 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽𝑖,⃗𝑣𝑖,𝑗) for all j=1, \\ldots, k𝑗 =1,…,𝑘.\nIt outputs (\\mathsf{id}_i, (\\sigma_{i,j})_{j=1}^k)(𝗂𝖽𝑖,(𝜎𝑖,𝑗)𝑘𝑗=1).\n\nForgery Phase. The adversary outputs a triple (\\mathsf{id}^*, \\vec v^*\\neq 0, \\sigma^*)(𝗂𝖽∗,⃗𝑣∗ ≠0,𝜎∗). We say that it wins the game if the following two hold:\n\nValid signature: we have \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id}^*,\\vec v^*, \\sigma^*)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽∗,⃗𝑣∗,𝜎∗) =1;\nFreshness: we have \\mathsf{id}^*\\notin\\{\\mathsf{id}_i\\}_{i=1}^q𝗂𝖽∗ ∉{𝗂𝖽𝑖}𝑞𝑖=1 or \\vec v^*\\notin A_i⃗𝑣∗ ∉𝐴𝑖 for every i\\in [q]𝑖 ∈[𝑞] with \\mathsf{id}^* = \\mathsf{id}_i𝗂𝖽∗ =𝗂𝖽𝑖.\n\nThe scheme is secure if no efficient (i.e., PPT) adversary wins this game with non-negligible probability.\nIntuitively, this security property states that any signature that verifies with respect to the given public key \\mathsf{pk}𝗉𝗄 and an identity \\mathsf{id}^*𝗂𝖽∗, must be on a vector in the span of the vectors that the honest signer signed with respect to \\mathsf{id}^*𝗂𝖽∗.\nLinearly-homomorphic Signatures in RLNC\nBelow, we explain how the BFKW Linearly-homomorphic Signature scheme can be used to replace commitments in the RLNC protocol.\nThe block proposer owns the secret key \\mathsf{sk}𝗌𝗄 and thus is the only one that can create “fresh” signatures. In this setting, we require that they parse the block as a matrix and sign the columns of it.\nThat means the proposer gets to set the subspace A𝐴. All other users can combine those signatures to create signatures on linear combinations of the vectors that define the block (by the completeness property).\nBy the security property, if a signature verifies with respect to the block proposer’s public key, it is then a linear combination of the original signatures, and thus a signature on a linear combination of the original vectors.\nTo generate new coefficients, or even to reconstruct the original vectors after receiving N𝑁 linearly-independent vectors, peer P𝑃 has access to the new signature \\sigma𝜎 and a set of coefficients \\vec a⃗𝑎 that the sender claims to be the coefficients that combine the original signatures \\sigma_1, \\ldots, \\sigma_N𝜎1,…,𝜎𝑁 to \\sigma𝜎. The receiving peer needs to verify not only that \\sigma𝜎 is a linear combination of the block proposer’s signatures, which is true iff \\mathsf{Verify}𝖵𝖾𝗋𝗂𝖿𝗒 outputs 11, but also that the coefficients of that linear combination are indeed the ones in \\vec b⃗𝑏.\nIn order to verify each signatures with respect to the specific coefficients that conform the linear combination, we formally extend the functionality of LHS schemes by slightly modifying its syntax as hinted in the seminal work:\n\n\\mathsf{RLNC}.\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m_i, i):𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚𝑖,𝑖) : Let \\vec e_i\\in\\mathbb{F}^N⃗𝑒𝑖 ∈𝔽𝑁 be the unity vector that takes value 11 in the position i𝑖 and 00 everywhere else (that is, is the i𝑖-th vector in the canonical basis of \\mathbb{F}^N𝔽𝑁) and output \\sigma\\gets\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m_i|| \\vec e_i)𝜎 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚𝑖||⃗𝑒𝑖)\n\\mathsf{RLNC}.\\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, \\sigma, \\vec a)\\to1/0𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎) →1/0: Set \\vec v'=\\vec v|| \\vec a⃗𝑣′ =⃗𝑣||⃗𝑎 and output \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v', \\sigma)𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣′,𝜎)\n\nEssentially, by adding the vector \\vec e_i⃗𝑒𝑖 to the message \\vec m_i⃗𝑚𝑖, we will have that the last N𝑁 elements of any signed vector \\vec v⃗𝑣 will be the unique coefficients that represent \\vec v⃗𝑣 as a linear combination of the messages \\{\\vec m_i\\}{⃗𝑚𝑖} signed by the \\mathsf{sk}𝗌𝗄 holder. Intuitively, by the unforgeability property of the LHSS, if the \\mathsf{Verify}𝖵𝖾𝗋𝗂𝖿𝗒 algorithm outputs 11 on input \\vec v, \\vec a⃗𝑣,⃗𝑎, then \\vec v=\\sum a_i \\vec m_i⃗𝑣 =∑𝑎𝑖⃗𝑚𝑖 except with negligible probability.\nThreat Model\nWhen implementing RLNC for block propagation, we assume an honest block proposer and set aside general networking attacks. Still, the system must remain resilient against Denial of Service (DoS) attacks—specifically pollution attacks. In this scenario, an adversary attempts to disrupt the propagation of block \\mathbf M𝐌 by injecting a malicious vector \\vec v′\\notin A⃗𝑣 ′ ∉𝐴, with A𝐴 being the subspace defined by the original block data. This is covered by the security property of LHS, that requests that no adversary can generate valid signatures for vectors that are not in A𝐴.\nThe inclusion of a string \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 within the signature serves as a unique identifier for a specific subspace. This allows a participant to sign multiple subspaces using the same public key while preventing vectors from different spaces from being combined, e.g., if this participant takes the role of the block proposer in multiple slots. Specifically, if a user signs subspace V_1𝑉1 at time t_1𝑡1 and subspace V_2𝑉2 at time t_2𝑡2, no party should be able to forge signatures on vectors in \\mathsf{span}(V_1\\cup V_2)𝗌𝗉𝖺𝗇(𝑉1 ∪𝑉2) that verify against \\mathsf{pk}𝗉𝗄. While the BFKW protocol requires \\mathsf{id}𝗂𝖽 to be unpredictable, the block propagation setting further requires \\mathsf{id}𝗂𝖽 to be tied to a specific block. To satisfy both conditions, we set \\mathsf{id}=H(\\mathsf{num_{slot}},\\mathsf{salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍), where \\mathsf{salt}𝗌𝖺𝗅𝗍 is sampled randomly by the proposer during signing, H𝐻 is a hash function (modeled as a random oracle), and \\mathsf{num_{slot}}𝗇𝗎𝗆𝗌𝗅𝗈𝗍 is the slot number of the proposed block.\nThe BFKW scheme for RLNC\nWe present the linearly-homomorphic signature scheme in BFKW with the new RLNC-specific syntax. Note that BFKW works similarly to BLS signatures that are already implemented in Ethereum. The main difference is that instead of signing messages, the users sign vectors and thus compute M𝑀 hashes per signature (where M𝑀 is the dimension of the vectors) instead of one. Consider a bilinear group (\\mathbb{G}_1,\\mathbb{G}_2, \\mathbb{G}_T, p, e)(𝔾1,𝔾2,𝔾𝑇,𝑝,𝑒), g_1, g_2𝑔1,𝑔2 generators of \\mathbb{G}_1𝔾1 and \\mathbb{G}_2𝔾2, respectively, and a hash function H:\\{0,1\\}^*\\times \\{0,1\\}^*\\to \\mathbb{G}_2𝐻 :{0,1}∗ ×{0,1}∗ →𝔾2 modeled as a random oracle.\n\n\\mathsf{RLNC.Setup}(n, pp)\\to(\\mathsf{sk,pk})𝖱𝖫𝖭𝖢.𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) →(𝗌𝗄,𝗉𝗄): Sample \\mathsf{sk}\\gets\\mathbb{F}𝗌𝗄 ←𝔽, set \\mathsf{pk}=g_1^{\\mathsf{sk}}𝗉𝗄 =𝑔𝗌𝗄1.\nLet A=\\mathsf{span}\\{\\vec m_1,\\ldots, \\vec m_N\\}, \\vec m_i\\in\\mathbb{F}^M𝐴 =𝗌𝗉𝖺𝗇{⃗𝑚1,…,⃗𝑚𝑁},⃗𝑚𝑖 ∈𝔽𝑀.\n\\mathsf{RLNC.Sign}(\\mathsf{sk, id}, \\vec m, N)\\to\\sigma𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚,𝑁) →𝜎:\n\nSet \\vec m'=\\vec m || \\vec e_i⃗𝑚′ =⃗𝑚||⃗𝑒𝑖 for \\vec e_i\\in\\mathbb{F}^N⃗𝑒𝑖 ∈𝔽𝑁 being the i𝑖-th unity vector and i𝑖 the position of \\vec m⃗𝑚 in the ordered basis of A𝐴.\nOutput \\sigma\\in\\mathbb{G}_2𝜎 ∈𝔾2 as follows:\n\n\\sigma=\\left(\\prod\\limits_{s=1}^M H(\\mathsf{id},s)^{m'_{s}}\\right)^{\\mathsf{sk}}\n𝜎=(𝑀∏𝑠=1𝐻(𝗂𝖽,𝑠)𝑚′𝑠)𝗌𝗄\n\n\\mathsf{RLNC.Combine}(\\mathsf{pk}, \\mathsf{id}, \\{(a_i, \\sigma_i, \\vec v_i)\\}_{i=1}^k)\\to(\\vec v, \\sigma, \\vec a)𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{(𝑎𝑖,𝜎𝑖,⃗𝑣𝑖)}𝑘𝑖=1) →(⃗𝑣,𝜎,⃗𝑎):\n\\vec v=\\sum_{i=1}^k a_i\\vec v_i, \\qquad \\sigma=\\prod_{i=1}^k \\sigma_i^{a_i}\n⃗𝑣=𝑘∑𝑖=1𝑎𝑖⃗𝑣𝑖,𝜎=𝑘∏𝑖=1𝜎𝑎𝑖𝑖\n\n\\mathsf{RLNC.Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ, \\vec a)\\to1/0𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎) →1/0:\n\nSet \\vec v'=\\vec v||\\vec a⃗𝑣′ =⃗𝑣||⃗𝑎\nOutput 11 if and only if\n\ne\\big(g_1, \\sigma\\big)=e\\left(pk, \\prod_{s=1}^M H(\\mathsf{id}, s)^{v'_s}\\right)\n𝑒(𝑔1,𝜎)=𝑒(𝑝𝑘,𝑀∏𝑠=1𝐻(𝗂𝖽,𝑠)𝑣′𝑠)\n\nSecurity: The protocol presented above is complete and secure in the random oracle model under the co-computational Diffie Hellman (co-CDH) assumption in (\\mathbb{G}_1, \\mathbb{G}_2)(𝔾1,𝔾2). The co-CDH assumption in (\\mathbb{G}_1, \\mathbb{G}_2)(𝔾1,𝔾2) states that it is computationally infeasible to compute g_1^x\\in\\mathbb{G}_1𝑔𝑥1 ∈𝔾1 given g_1\\in\\mathbb{G}_1𝑔1 ∈𝔾1 and g_2, g_2^x\\in\\mathbb{G}_2𝑔2,𝑔𝑥2 ∈𝔾2.\n\nRLNC with Linearly-homomorphic Signatures\nThe result of replacing homomorphic commitments by the linearly-homomophic signature scheme of BFKW in the protocol proposed here is the following:\nProposer\nProposer’s key pair is (sk, pk=g_2^{sk})(𝑠𝑘,𝑝𝑘 =𝑔𝑠𝑘2). On input block \\mathbf{M}\\in\\mathbb{F}^{M\\times N}𝐌 ∈𝔽𝑀×𝑁, the proposer samples \\mathsf{salt}\\gets\\{0,1\\}^n𝗌𝖺𝗅𝗍 ←{0,1}𝑛 and sets \\mathsf{id}=H(\\mathsf{num_{slot}},\\mathsf{salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍).\n\nFor each i\\in[N]:𝑖 ∈[𝑁] :\n\n\\sigma_i\\gets \\mathsf{RLNC.Sign}(sk, \\mathsf{id}, \\vec m_i, i):𝜎𝑖 ←𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝑠𝑘,𝗂𝖽,⃗𝑚𝑖,𝑖) :\n\nFor each user u_j\\in D𝑢𝑗 ∈𝐷\n\nSample \\vec a_j\\gets \\mathbb{F}^N⃗𝑎𝑗 ←𝔽𝑁\n\\sigma_j\\gets\\mathsf{RLNC.Combine}(pk, \\mathsf{id}, {(a_{j,i}, \\sigma_i)}_{i=1}^N)𝜎𝑗 ←𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑝𝑘,𝗂𝖽,(𝑎𝑗,𝑖,𝜎𝑖)𝑁𝑖=1)\nSend \\pi_j=(\\mathsf{salt}, \\vec v_j, \\vec a_j, \\sigma_j)𝜋𝑗 =(𝗌𝖺𝗅𝗍,⃗𝑣𝑗,⃗𝑎𝑗,𝜎𝑗), where \\vec v_j=\\sum_{j=1}^N {a_{i,j}} \\vec m_i⃗𝑣𝑗 =∑𝑁𝑗=1𝑎𝑖,𝑗⃗𝑚𝑖\n\nReceiving Peers\n\nParse (\\mathsf{salt}, \\vec v, \\vec a, \\sigma)\\gets \\pi(𝗌𝖺𝗅𝗍,⃗𝑣,⃗𝑎,𝜎) ←𝜋\nOutput b\\gets\\mathsf{RLNC.Verify}(pk, \\mathsf{id}, \\vec v, \\sigma, \\vec a)𝑏 ←𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝑝𝑘,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎)\n\nSending Peers\nOn input (\\pi_1, \\ldots, \\pi_L)(𝜋1,…,𝜋𝐿):\n\nParse (\\mathsf{salt}, \\vec v_i, \\vec a_i, \\sigma_i)\\gets \\pi_i(𝗌𝖺𝗅𝗍,⃗𝑣𝑖,⃗𝑎𝑖,𝜎𝑖) ←𝜋𝑖 for all i\\in [L]𝑖 ∈[𝐿]\nSample \\vec a'\\gets\\mathbb{F}^L⃗𝑎′ ←𝔽𝐿\nCompute \\mathsf{id}=H(\\mathsf{num_{slot}, salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍)\n\\sigma\\gets\\mathsf{RLNC.Combine}(pk, \\mathsf{id}, (a'_i, \\sigma_i)_{i=1}^L)𝜎 ←𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑝𝑘,𝗂𝖽,(𝑎′𝑖,𝜎𝑖)𝐿𝑖=1)\nSet \\vec v=\\sum_{i=1}^L a'_i \\vec v_i⃗𝑣 =∑𝐿𝑖=1𝑎′𝑖⃗𝑣𝑖\nRedefine vector \\vec a⃗𝑎 with a_i=a'_i\\sum_{i=1}^L a_j𝑎𝑖 =𝑎′𝑖∑𝐿𝑖=1𝑎𝑗\nOutput \\pi=(\\vec v, \\vec a, \\sigma)𝜋 =(⃗𝑣,⃗𝑎,𝜎)\n\nOn the efficiency\nBelow we set a comparison with the proposal by Potuz. Note that in the LHS approach, we trade efficiency of P_{prop}𝑃𝑝𝑟𝑜𝑝 and the receiving/sender peers to avoid sending N𝑁 group elements to the network.\n\nProposer:\n\nSigning a message involves computing M𝑀 hashes H𝐻 to \\mathbb{G}_2𝔾2 and then performin M𝑀 group operations in \\mathbb{G}_2𝔾2, whereas in the previous approach involved only M𝑀 group operations for a Pedersen commitment.\n\nReceiver:\n\nVerifying the signature is M𝑀 \\mathbb{G}_1𝔾1 operations and two pairings. Verifying a commitment is 2M2𝑀 \\mathbb{G}𝔾 operations.\n\nSender:\n\nPerforms L\\mathbb{G}_1𝐿𝔾1 operations to compute the new signature in addition to the LM𝐿𝑀 field operations it already performs in the previous approach to compute the new vector \\vec v⃗𝑣.\n\nCommunication:\n\nEach signature is 1\\mathbb{G}_21𝔾2 element, same as the Pedersen commitments. With the previous approach, we have N𝑁 commitments that can be communicated as a sidecar, while in the signature approach we have 11 group element being communicated per time.\n\nReconstruction: Works the same way as before, after receiving N𝑁 linearly-independent vectors and verifying they are indeed in the subspace A𝐴, any node can reconstruct block \\mathbf M𝐌 by solving a system of equations.\n\nPedersen Commitments\nLinearly-Homomorphic Signatures\n\nCommitting(P_{prop}𝑃𝑝𝑟𝑜𝑝) to one vector\nM\\ \\mathbb{G}𝑀 𝔾 ops\nM\\ \\mathbb{G}_2𝑀 𝔾2 ops, M𝑀 hashes to \\mathbb{G}_2𝔾2\n\nReceiver (Verify \\vec v\\in A⃗𝑣 ∈𝐴)\nCommit\nCommit + 22 pairings\n\nSender\nLM\\ \\mathbb{F}𝐿𝑀 𝔽 ops\nLM\\ \\mathbb{F}𝐿𝑀 𝔽 ops, L \\ \\mathbb{G}_2𝐿 𝔾2 ops\n\nCommunication\nN\\ \\mathbb{G}𝑁 𝔾, N\\ \\mathbb{F}𝑁 𝔽\n1\\ \\mathbb{G}_21 𝔾2, N\\ \\mathbb{F}𝑁 𝔽\n\nFuture Work\nA natural extension of this work is the transition toward post-quantum (PQ) security. The BFKW scheme, while efficient, relies on the hardness of the co-CDH problem in bilinear groups, which is susceptible to attacks by large-scale quantum computers. To future proof RLNC-based block propagation, we should explore Linearly Homomorphic Signatures schemes based on post-quantum assumptions.\n\nThere are proposals which suggest that the commitments \\mathsf{C}_1, \\ldots, \\mathsf{C}_N𝖢1,…,𝖢𝑁 and the signature on them can travel the network independently of the newly generated vectors. ↩︎\n\n RLNC Optimizations\n\n Faster block/blob propagation in Ethereum\n\n 2\n\n read \n\n 8\n min\n\n 18 days later\n\n post by MoritzGrundei on Feb 25\n\n MoritzGrundei\n\n Great post!\nI agree that LHSSs are a very promising approach to the packet poisoning problem in RLNC systems. A few additional points come to mind.\nFirst, BFKW is a very interesting LHSS instantiation, but it is not the only one. For example, [1] proposes an alternative signature scheme based on signing an orthogonal vector to the subspace spanned by the extended content vectors (under discrete-log and CDH hardness assumptions). Operationally, it is attractive because it avoids pairing based cryptography as well as signature recombination at intermediate nodes, but it comes with a larger public-key (N+M𝑁 +𝑀 field elements).\nSecond (and maybe most importantly), there is a broader design tradeoff between packet-level integrity and generation-based integrity verification [2 Chapter 8.3]. LHSS gives packet-level integrity verification, i.e., each coded packet can be checked immediately. By contrast, generation-based schemes perform integrity verification over a full generation after decoding (or at generation granularity). The overhead-analysis done in [3] is a good reference point here. In short:\n\nGeneration-based approaches can have low overhead when packet poisoning probability is low (<3%), because the hash/authentication cost is amortised across a whole generation.\n\nLHSS / packet-level verification enables immediate detection and filtering (and one-hop containment), which can reduce wasted bandwidth and improve throughput when packet poisoning probability is moderate - high.\n\nAttributing the injection of poisoned packets to malicious actors (e.g. to slash malicious nodes) is straightforward in packet-level verification but this problem has also been solved through a dedicated protocol (e.g. the Rugby protocol as detailed in [4, Section 5]\n\nMoreover, generation-based approaches rely primarily on hash functions, which are generally easier to make post quantum secure than discrete-log/CDH-based signature systems. So if we re-evaluate the tradeoff under quantum-resistant requirements, the overhead balance will shift somewhat in favor of generation-based schemes.\nThird, LHSS usually have practical limitations with respect to the underlying field. LHSS constructions are usually defined over sufficiently large prime fields / EC of large prime order because their security depends on assumptions like discrete log / CDH in those groups. By contrast, RLNC implementations often benefit from extension fields for practical coding/decoding efficiency (see [2 Chapter 2]). Does this constraint also apply for BFKW?\nReferences\n\nZhao, F., Kalker, T., Médard, M., Han, K. J.\nSignatures for Content Distribution with Network Coding (IEEE ISIT 2007), DOI: 10.1109/ISIT.2007.4557283.\n\nMuriel Médard, Vipindev Adat Vasudevan, Morten Videbæk Pedersen & Ken R. Duffy, Network Coding for Engineers, Wiley-IEEE Press, 2025, ISBN 978-1-394-21729-8.\n\nKim, M., Lima, L., Zhao, F., Barros, J., Médard, M., Koetter, R., Kalker, T., Han, K.\nOn Counteracting Byzantine Attacks in Network Coded Peer-to-Peer Networks (arXiv:0904.2722; later JSAC version linked from arXiv).\n\nN. Nicolaou, O. Obi, A. Rajasekaran, A. Bergasov, A. Bezobchuk, K. M. Konwar, M. Meier, S. Paiva, H. P. Singh, S. Sinha, S. Vishwanath, and M. Médard, “OPTIMUMP2P: Fast and Reliable Gossiping in P2P Networks,” in 2025 21st International Conference on\n\n 8 days later\n\n post by arantxazapico on Mar 5\n\n arantxazapico\n\n Thanks for your feedback and questions!\n\nWe are aware of the existence of other LHSS schemes, which is why we first describe the solution as scheme-agnostic.We chose BFWK for its similarity to BLS, which are already implemented in Ethereum.\n\nI was not aware of the latest generation-based schemes, so thank you for pointing them out. Whether we can develop an efficient LHSS-based RLNC protocol that is also post-quantum remains an open question for us, but your comment makes sense to me.\n\nYes, it does.\n\n Powered by Discourse","tokens":6210,"squid":"ink-research","role":"Deep Scholar","at":1791263804865,"hash":"ace69ccab3ccdd33225a4683af6398a5a4e7e32f"}
{"url":"https://governance.aave.com/t/aave-governance-process-document-v1/18577","domain":"governance.aave.com","title":"Aave Governance Process Document v1 - Governance - Aave","text":"Aave Governance Process Document v1 \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 9\n min\n\n Aave Governance Process Document v1\n\n Introduction\n\n Governance Processes\n\n Proposal types\n\n General proposal process\n\n Moving to Vote\n\n Quorum\n\n ACI Skyward\n\n Non-standard Governance Frameworks\n\n ARFC Addendum\n\n Asset Onboarding Framework\n\n New Chain Deployment Framework\n\n Emission Manager Framework\n\n Technical Maintenance Proposals\n\n Funding\n\n Direct Funding Through Governance\n\n Bug Bounties\n\n Operational Budgets\n\n Governance Roles\n\n Delegates & Delegators\n\n Delegates\n\n Delegators\n\n Contributors and Service Providers\n\n Contributors\n\n Service Providers\n\n Guardians\n\n Protocol Emergency Guardian\n\n Governance Emergency Guardian\n\n Stewards\n\n GHO Stewards\n\n Risk Stewards\n\n Finance Stewards\n\n Aug 2024\n\n 1 / 6\n\n Aug 2024\n\n Aug 2024\n\n post by ACI on Aug 8, 2024\n\n ACI\n\n Leader\n\n Aave Governance Process Document v1\nAuthors: ACI\nDate: 2024-08-08\nIntroduction\nThe “Aave Governance Process’’ is an all-in-one document for contributing to Aave DAO. This document will be continuously updated by Aave DAO contributors. The previous version is available here: Aave Finance Governance Process v0\nThis document provides an overview of the different roles, flow and pathways for various stakeholders to participate in Aave DAO.\nGovernance Processes\nThe processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate.\nAt a high level the Aave governance process is composed of five stages, from temp check forum dicussion to on-chain votes. The stages are as follows: temp check forum post, temp check snapshot, ARFC forum post, ARFC snapshot, AIP on-chain vote. A standard proposal will take a minimum of 19 days to pass through all of these stages, although it is uncommon that it progresses this quickly as time is needed for writing and reviewing payloads, and there are timelocks and other waiting periods relating to the various voting stages.\nProposal types\nThere are generally three main types of proposals in Aave Governance; these three general proposal classifications strictly refer to the maturity of a proposal in the Aave Governance Process. In specific situations, in order to minimise governance burden and increase speed, there are streamlined versions of this process. These situations are described in a later section.\n\nTEMP CHECK: These serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.\nTEMP CHECK Snapshot: This is an off-chain vote using the Snapshot platform, with voting starting after the TEMP CHECK discussion period has ended.\nARFC: Aave Request for Comment (ARFCs) are precursors to Aave Improvement Proposals (AIPs). Relevant service providers are formally invited to provide feedback on them, and the specification section of ARFCs should detail how the potential upcoming AIP will impact Aave protocol smart contracts.\nARFC Snapshot: This is an off-chain vote using the Snapshot platform, with voting starting after the ARFC discussion period has ended.\nAIP: Aave Improvement Proposal (AIPs) are a formal proposal to improve the Aave Protocol; before submitting an AIP, an ARFC should be submitted to the community to gather feedback. Once the AIP has been written and reviewed, the AIP will be submitted via GitHub to begin the process of putting the AIP on-chain.\n\nGeneral proposal process\nAs pictured below, the standard proposal process is as follows:\n\nPost a Temp Check for 5 days to allow discussion and gauge sentiment.\nTemp Check Snapshot vote for 3 days.\nPost an ARFC for 5 days to allow for closer scrutiny and discussion.\nPost an ARFC Snapshot vote for 3 days.\nPost an AIP vote for 3 days.\n\nThis process takes around 19 days at a minimum, but often takes longer due to backlogs and time taken for writing and reviewing payloads, there are also various timelocks and waiting periods relating to the voting stages which extend this minimum timeframe. It should also be noted that ACI Skyward can help tokenholders to ensure the governance process proceeds smoothly and efficiently.\nstandard governance process2264×412 43.3 KB\nStandard governance process\nProposal Discussion\nAs part of the governance process, a discussion must be started on the Aave Governance Forum, as shown in the diagram above there are two rounds of discussion, firstly as a Temp Check, and then as an ARFC if the Temp Check Snapshot passes.\nOnce the proposal has been posted on the forum, it must:\n\nBe available for review and comment for a minimum of five days.\nContain all relevant information that would be contained in the AIP\nComply with any relevant templates that apply to the proposal.\n\nThe proposal author may decide to modify the proposal based on feedback during the discussion phases.\nMoving to Vote\nOnce a proposal meets the required conditions, it can proceed to the voting stages, which include both off-chain and on-chain voting methods. Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives.\nOff-chain voting (Snapshot): Off-chain votes are used to gauge the sentiment for Temp Checks and ARFCs. The off-chain voting period lasts 3 days for both Temp Check and ARFC votes.\nOn-chain (Native): On-chain voting is required on any Aave Improvement Proposal. Aave on-chain votes will occur on the Aave Governance Portal. The voting period must last for a minimum period of 3 days. With the launch of V3 governance, it is now possible to vote across multiple chains and carry out gasless voting, read more here.\nThe on-chain voting process is composed of four stages:\n\nFirst of all, the proposal and payload are reviewed by Security Service Providers to ensure that it is not malicious and that it doesn’t contain errors which put the protocol at risk.\nThe second stage is entered if no errors or malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a voting delay of 1 day must pass before the proposal becomes active.\nIn the third stage, once the voting delay has elapsed the proposal becomes active and is available to be voted on. This stage lasts for 3 days.\nIn the fourth stage, once the voting period has ended, the proposal will either have SUCCEEDED or FAILED, depending on whether it has passed quorum and has a majority of YAE votes or not. In this stage, if the proposal has passed, the payload is queued with a timelock of 1 day, after this is elapsed the payload may be executed. If the proposal is not executed before the end of a grace period it expires and must be deployed and voted on again from the beginning of the on-chain voting process.\n\nA visual representation of this flow is shown in the figure below.\nonchain voting process1536×513 101 KB\nOn-chain voting process\nIn both off-chain and on-chain votes, the voting power is directly proportional to the amount of AAVE, stkAAVE or aAAVE a user holds or has delegated to them. For more details, please refer to the official documentation.\nQuorum\nIn order for a proposal to succeed, a minimum of 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote. In addition to this, the winning vote must also have 320,000 votes. For example if a proposal had 320,000 total votes, with less than 320,000 votes for the winning option, this would not meet quorum requirements. Any changes to the quorum requirements must be amended by the community through an AIP.\nEach vote has to reach the minimum quorum, even if it has a majority, for it to be considered an official proposal. It is the responsibility of the proposal author to enlist voting participation from the community in order to reach a quorum.\nACI Skyward\nSkyward is a free service launched by ACI to assist Aave DAO members with the proposal process, making it more accessible and streamlined. The service covers various AIP types, including asset onboarding, risk parameter changes, interest rate strategy changes, supply & borrow caps changes, E-mode activation, and asset offboarding. Skyward is open to everyone and free of charge in order to lower the barriers to participation in Aave’s governance.\nHow Skyward works:\n\nInitial contact: Proposer will often contact ACI before engaging in the governance process to ensure efficient progression through the various stages.\nTemp Check: Proposer writes a Temp Check and has ACI review the draft before publishing to forums.\nTemp Check Snapshot: ACI publishes Temp Check Snapshot.\nARFC Request: ACI creates and publishes the ARFC in collaboration with the proposer.\nARFC Snapshot : ACI publishes the ARFC Snapshot.\nAIP Creation: If the Snapshot vote is successful, ACI writes the payload and publishes the AIP for a vote.\n\nTo help understand at what point ACI Skyward takes responsibility for the governance process, see the figure below.\ngovernance process ACI Skywards2437×712 138 KB\nGovernance process when making use of ACI Skyward\nNon-standard Governance Frameworks\nFor some common actions that governance needs to take in order to manage the Aave protocol, there are frameworks for expedited governance. This helps reduce the governance burden on the DAO, tailors governance processes to the level of scrutiny required for various tasks, and helps the DAO run more efficiently.\nARFC Addendum\nIn order to make minor changes to an existing ARFC, rather than restarting the process from Temp Check stage, an Addendum can be proposed by forum post which progresses to Snapshot then AIP. This expedites minor changes, reducing governance burden. An illustration of the process is shown below:\nARFC Addendum Process1664×408 30.7 KB\nARFC Addendum Governance Process\nAsset Onboarding Framework\nThe Asset Onboarding Framework is available to read on the forums here: [ARFC] Update the Asset Onboarding Framework along with minor modifications here: [ARFC Addendum] Update Asset Onboarding Framework.\nThere are two pathways for onboarding new assets to Aave. If there is no existing Aave market for the asset, the standard governance process is followed, starting at temp check and progressing through all standard governance stages. For assets already listed in other Aave markets, a direct-to-AIP process is used, skipping the Temp Check stages and taking about 10 days. To use this process the following must be applicable for the asset being onboarded:\n\nExisting Aave market presence.\nSubmission or feedback from a risk service provider.\nSupply cap not exceeding 50% on the respective chain.\nAt least 90 days old Chainlink price feed.\n\nNew listing candidates must deposit $100 worth of the intended asset into the Aave Short Executor. This deposit is non-refundable and required before proceeding to the AIP phase.\nAsset onboarding proposals are most commonly used for deploying markets for already listed assets on new chains, for example see these proposals to deploy weETH markets on Base and Scroll.\nAsset Onboarding Process994×406 19.6 KB\nAsset onboarding process for assets already listed on Aave\nNew Chain Deployment Framework\nThe New Chain Deployment Framework is a standardized process for deploying the Aave Protocol on new blockchains. This framework aims to create a transparent approach for evaluating and deploying new Aave v3 instances. The full forum post detailing the framework along with templates for both temp check and ARFC proposals can be found here: [ARFC] New Chain Deployment Framework.\nThe process follows these key steps:\n\nPost a TEMP CHECK governance thread for 5 days\nSnapshot vote for 3 days (24 hours after gov thread)\n\nDocumentation submission:\n\n7 days after the Snapshot vote\nIf deadline is not met, there will be a frozen period of 30 days. After that period documentation could be analyzed again\n\nTechnical review duration\n\n21 days since documentation submitted\nIf technical review fails due to security concerns, process will be frozen until it’s been resolved.\n\nPost an ARFC governance thread for 5 Days, after technical review has been successfully completed\nSnapshot vote for 3 days (24 hours after gov thread)\nPost an AIP vote for 5 days (Minimum 320k vote required)\n\nThese steps are shown visually in the figure below:\nNew Chain Framework2764×1168 231 KB\nNew Chain Onboarding Framework flowchart\nThe framework introduces stricter timelines and requirements than the standard proposal process. If documentation submission deadlines are not met, there’s a 30-day freeze period. Technical review failures due to security concerns freeze the process until resolution.\nThis framework balances security and speed, providing a more efficient governance process while maximizing the benefits of Aave’s brand for new chain ecosystems. It aims to streamline the deployment process, reduce governance overhead, and prioritize chains offering standing deposits or other benefits to the Aave protocol and its users.\nEmission Manager Framework\nTo allow quick addition of new emissions admins to Aave pool reserves, the process of adding new emissions admins follows a direct to AIP framework. This framework also allows\npre-authorized inclusion of an emission admin as part of either an ad-hoc steward or current risk steward role to facilitate a more efficient and streamlined onboarding process. Further information can be found here: [ARFC] Emission Manager Framework Update.\nThe governance process under this framework is as shown in the below figure.\nAsset Onboarding Process994×406 19.6 KB\nEmissions manager framework governance process.\nTechnical Maintenance Proposals\nWith Aave instances in multiple versions (v1, v2, v3) and networks, periodically it is necessary to do maintenance tasks related to infrastructure consistency. In order to balance efficiency and transparency of updates, Technical Maintenance Proposals are posted by BGD Labs, the current Development Service Provider on this thread (Technical maintenance proposals) for 3 days and then move directly to AIP if there is no feedback or concerns from the community. The governance process for Technical Maintenance Proposals is shown in the below figure.\ntechnical maintenance proposal956×397 19.7 KB\nFunding\nAs a mature DAO, there are both planned and ad hoc funding needs. In order to address these, several governance processes relating to funding have been developed. These are: one off funding requests, grants, bug bounties, and operational budgets.\nDirect Funding Through Governance\nA number of contributions to the Aave protocol have been funded through Governance Proposals for example funding the development of Aave V3.\nBug Bounties\nThe Aave bug bounty program operates in collaboration with Immunefi to enhance the security of the Aave protocol. BGD Labs and Aave Companies act as appointed representatives of the DAO for this program, with BGD responsible for most systems and Aave Companies managing GHO-related submissions. Full details and discussion around the Bug Bounty Program are available here: [TEMP CHECK] Aave Bug Bounty Program on Immunefi and here: BGD. Aave <> Immunefi bug bounty program.\nEligibility criteria and systems covered under this bug bounty program are as follows:\n\nCriteria\nDetails\n\nSystems Covered\nAave v2, Aave v3, Aave Governance v2, Aave Safety Module, GHO stablecoin\n\nEligible Participants\nAll, except Official and Former Official Contributors\n\nKYC Requirements\nMay be required at discretion of DAO representatives, not for Medium or Low severity reports\n\nSpecial Conditions\nMeasures may be implemented to prevent submissions from Official Contributors for high and critical reports\n\nPayouts under the bug bounty program are as follows:\n\nSeverity\nPayout Range\nApplicable Systems\n\nCritical\n10% of funds at risk, $50,000 to $1,000,000\nAave v2 Ethereum, Aave v3, Governance v2, Safety Module, GHO\n\nCritical\n10% of funds at risk, up to $250,000\nAave v2 on other networks\n\nHigh\n10% of funds at risk, $10,000 to $75,000\nAave v2 Ethereum only\n\nMedium\n$10,000\nAll systems\n\nLow\n$1,000\nAll systems\n\nAdditional payout terms and procedures:\n\nFor repeatable attacks, funds at risk calculated within first 45 minutes from first attack\nPayments made via governance proposals in a mix of AAVE and stablecoins\nPayouts batched monthly to avoid governance overload\nImmunefi’s fee of 10% applied on top of each bounty payout\nProof of Concept (PoC) required for all Smart Contract bug reports\nOnly Critical and High impacts in scope for Aave v2 on Ethereum\nOnly Critical impacts in scope for Aave v2 on other networks\nAttacks involving other protocols may be considered if they meet specific criteria\nBGD can modify technical aspects, but fundamental changes require governance approval\n\nThis program allows Aave to maintain a robust security posture while engaging with the wider security research community in a structured manner.\nOperational Budgets\nIn order to minimise governance overhead, trusted providers may receive funds for scoped and budgeted activities ahead of time. These are for well defined activities that provide either essential or beneficial services to the DAO. Most significantly these include Security Budget for BGD labs as per this proposal: [ARFC]. BGD. Security budget request - December 2023, and Events and Sponsorship Budget to Aave Labs as per this proposal: [TEMP CHECK] Aave Events & Sponsorship Budget.\nGovernance Roles\nDelegates & Delegators\nDelegates\nDelegates are community members who have received voting power from other members of the community or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have entrusted them with their voting power. Some delegates are compensated under the Orbit program.\nDelegators\nDelegators are community members who hold Aave, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another person. The person to whom they delegate their voting power is considered a delegate. This system allows delegators to have their interests represented in governance decisions without having to participate directly in every vote.\nContributors and Service Providers\nContributors\nContributors are community members who participate in and dedicate their time to the Aave DAO. They contribute by joining working groups, fulfilling bounties, building on top of the Aave Protocol, or working for the DAO via grants. Contributors work towards completing shared goals that benefit the Aave ecosystem.\nService Providers\nService providers are specialized entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:\n\nChaos Labs: Risk service provider\nLlamarisk: Risk service provider\nKarpatkey: Finance service provider\nCertora: Security service provider\nTokenlogic: Finance service provider\nBGD Labs: Development service provider\nACI: Growth and business development service provider\n\nGuardians\nThe Aave Guardians are crucial for maintaining the protocol’s security and integrity. They are divided into two groups: Protocol Guardians, who handle emergency responses and can pause markets, and Governance Guardians, who can veto malicious governance proposals. The Guardians operate under a 5/9 multi-sig arrangement.\nFor more information on the Guardians’ permissions, refer to this detailed view of permissions in Aave systems. For a general overview of their role, see the Medium post about Aave V2 Governance here.\nProtocol Emergency Guardian\nThis Guardian holds the EMERGENCY_ADMIN role in Aave V3, as well as similar roles in V2 and other related systems. The primary function of the Protocol Emergency Guardian is to act swiftly in emergency situations to protect the protocol. It is composed of highly active entities within the Aave DAO, such as service providers and delegates. The multi-sig configuration for this Guardian is a 5-of-9 setup. The current Protocol Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nProtocol Emergency Guardian\nAddress\n\nChaos Labs\n0x5d49dBcdd300aECc2C311cFB56593E71c445d60d\n\nLlamaRisk\n0xbA037E4746ff58c55dc8F27a328C428F258DDACb\n\nKarpatkey\n0x818C277dBE886b934e60aa047250A73529E26A99\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nTokenLogic\n0xb647055A9915bF9c8021a684E175A353525b9890\n\nBGD Labs\n0xf71fc92e2949ccF6A5Fd369a0b402ba80Bc61E02\n\nACI\n0x57ab7ee15cE5ECacB1aB84EE42D5A9d0d8112922\n\nEzr3al\n0xC5bE5c0134857B4b96F45AA6f6B77DB96Ac1487e\n\nStable Lab\n0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E\n\nGovernance Emergency Guardian\nThis Guardian is responsible for cancelling governance proposals if they are detected as malicious or contain errors, typically identified during the on-chain verification stage by Certora. Unlike the Protocol Emergency Guardian, speed is less critical for this role since governance proposals unfold over a period of five days, allowing adequate time for issues to be identified and addressed. The multi-sig configuration for this Guardian is also a 5-of-9 setup. The current Governance Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nGovernance Emergency Guardian\nAddress\n\nSeb (Zapper)\n0xa1c9ceed5ff78f700dc4930514621843b5fac272\n\nMounir (Paraswap)\n0xfd639f49Da6cadc98f01B60900C8BE30C38c4B27\n\nGavi Galloway (Standard Crypto)\n0xbd4DCfA978c6D0d342cE36809AfFFa49d4B7f1F7\n\nNenad (Defi Saver)\n0xDA5Ae43e179987a66B9831F92223567e1F38BE7D\n\nFernando (Balancer)\n0x4C30E33758216aD0d676419c21CB8D014C68099f\n\nRoger (Chainlink community)\n0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396\n\nMariano Conti (DeFi OG)\n0x936CD9654271083cCF93A975919Da0aB3Bc99EF3\n\nMarin (Lido)\n0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nStewards\nStewards were introduced to allow the DAO to respond quickly to market changes in order to remain competitive and address risks. They are delegated responsibility over specific parameters within certain boundaries of magnitude and frequency of change. The benefit of this is that minor changes do not need to go through a full governance cycle, increasing speed and reducing governance burden on delegates and tokenholders. At time of writing there are stewards for managing: GHO, lending parameters, and treasury operations.\nGHO Stewards\nThe GHO Stewards are a group of Contributors and Service Providers who manage critical parameters for the GHO stablecoin, ensuring its stability. This group has the authority to adjust the:\n\nGHO Borrow Cap\nBorrow Rate\nvarious GSM parameters like Exposure Cap, Bucket Capacity, Price Strategy, Fee Strategy, and Price Range (Freeze, Unfreeze)\n\nThe ranges for parameters which the GHO Stewards may adjust are shown in the below table and were proposed in the following ARFCs [ARFC] GHO Stewards, [ARFC] GHO Stewards + Borrow Rate Update.\n\nDescription\nValue\n\nGHO Aave Bucket Capacity\n100% Increase\n\nGSM Exposure Cap\n100% Increase\n\nGSM Bucket Capacity\n100% Increase\n\nGSM Fee Strategy\n+ 0.5%\n\nGSM Price Range\n(Freeze, Unfreeze)\n\nGHO Borrow Cap\n100M\n\nMax GHO Borrow Rate Adjustment\n5%\n\nMax GHO Borrow Rate\n25%\n\nFrequency of Change\n2 days\n\nThe creation of GHO Stewards aims to streamline governance, allowing quick adjustments to maintain the GHO peg, especially during market fluctuations. The GHO Stewards operate under a 3-of-4 multi-sig configuration and GHO Stewards at time of writing are:\n\nKarpatkey\nTokenlogic\nACI\nChaos Labs\n\nRisk Stewards\nRisk Stewards are responsible for managing critical risk parameters within the Aave protocol. They are able to make adjustments to supply and borrow caps, reducing the need for frequent community votes. This setup ensures rapid responses to emerging risks while minimising governance overhead.\nThe parameters that Risk Stewards can change are:\n\nSupply and Borrow Caps: Increasing caps with constraints on frequency and maximum percentage increase to maintain protocol stability.\nCollateral Risk Configurations: Adjusting parameters such as Loan-to-Value (LTV), liquidation thresholds, and liquidation bonuses.\nInterest Rate Strategies: Fine-tuning base rates, slopes, and optimal points to align with market conditions.\n\nThe parameters that the Risk Stewards can control are shown in the table below and were discussed in the following proposal: BGD. Risk Steward Phase 1: CapsPlusRiskSteward.\n\nDescription\nValue\n\nFrequency of change\n5 days\n\nMaximum supply cap increase\n50%\n\nMaximum borrow cap increase\n50%\n\nRisk Stewards operate under strict on-chain validations and are managed by a 1-of-1 multisig. Risk Stewards at the time of writing are:\n\nChaos Labs\n\nFinance Stewards\nPlease note the Finance Stewards system in not yet live and is for information purposes only at this point, it is planned that this will go live in the near future.\nFinance Stewards are responsible for executing pre-approved and budgeted financial operations on behalf of the Aave DAO. They manage the Aave DAO’s funds through a smart contract that acts as an admin of the collector, streamlining the management of treasury assets and reducing the need for frequent on-chain votes.\nThe Finance Stewards have the authority to:\n\nMigrate assets from v2 and deposit into v3\nUse the Aave Swapper to exchange treasury assets\nWithdraw and deposit into V3\nTransfer and stream tokens to pre-approved addresses within set budgets such as ACI Frontier Program and ACI Merit Program\n\nProposed Finance Stewards at the time of writing are:\n\nKarpatkey\nTokenlogic\n\n TEMP CHECK: Add support for Wrapped Super OETH (wsuperOETHb) to Aave v3\n\n Aave Finance Governance Process v0\n\n [TEMP CHECK]: Add support for Wrapped Origin Sonic (wOS) to Aave v3\n\n [ARFC ADDENDUM] Updated Framework for ARFC and TEMP CHECK Proposals\n\n ACI Retrospective 2024-present\n\n read \n\n 9\n min\n\n Pinned on Aug 8, 2024\n\n post by heyjared on Aug 8, 2024\n\n post by Stratego on Aug 11, 2024\n\n post by superproduct on Aug 12, 2024\n\n 2 months later\n\n Closed on Oct 7, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10","tokens":6608,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263804900,"hash":"e431e53f4791cbd426dbdc090c681eddcf1e5249"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/block-numbers-and-time","domain":"docs.arbitrum.io","title":"Block gas limit, numbers and time | Arbitrum Docs","text":"✏️Request an updateblock number vs block.numberThroughout this and other pages, we note that the block number of a chain does not match the value obtained from block.number. When using block.number in a smart contract, the value obtained will be the block of the first non-Arbitrum ancestor chain. That is:\nEthereum, if the chain is a Layer 2 (L2) chain on top of Ethereum, or a Layer 3 (L3) chain on top of an Arbitrum chain\nThe parent chain, if it's not Ethereum or an Arbitrum chain (for example, a chain that settles to Base)\n\nAs with Ethereum, Arbitrum clients submit transactions, and the system executes them later. In Arbitrum, clients submit transactions by posting messages to the Ethereum chain, either through the Sequencer or via the chain's Delayed Inbox.\nOnce in the chain's core inbox contract, transaction processing occurs in order. Generally, some time will elapse between when a message is put into the inbox (and timestamped) and when the contract processes the message and carries out the transaction requested by the message.\nAdditionally, since the calldata/blobs of Arbitrum transactions (or the DAC certificate on AnyTrustchains) is posted to Ethereum, the gas paid when executing them includes a component for the parent chain to cover the costs of the batch poster.\nThis page explains the implications of this mechanism for the block gas limit, block numbers, and the time assumptions associated with transactions submitted to Arbitrum.\nBlock gas limit​\nWhen submitting a transaction to Arbitrum, users incur fees for both the execution cost on Arbitrum and the cost of posting its calldata to Ethereum. Managing the dual cost structure involves adjusting the transaction's gas limit to reflect these two dimensions, resulting in a higher gas limit value than would be seen for pure execution.\nThe gas limit of an Arbitrum block is set to the sum of all transaction gas limits, including the costs associated with posting parent chain data. To accommodate potential variations in parent chain costs, Arbitrum assigns an artificially large gas limit (1,125,899,906,842,624) for each block. However, the effective execution gas limit has a cap of 32 million. This cap means that, although the visible gas limit may appear very high, the actual execution costs are constrained within this limit. Understanding this distinction helps clarify why querying a block might show an inflated gas limit that doesn't match the effective execution costs.\nFor a more detailed breakdown of the gas model, refer to this article on Arbitrum's 2-dimensional fee structure.\nBlock numbers: Arbitrum vs. Ethereum​\nArbitrum blocks are assigned their own child chain block numbers, distinct from Ethereum's block numbers.\nA single Ethereum block can include multiple Arbitrum blocks; however, an Arbitrum block cannot span across multiple Ethereum blocks. Thus, any given Arbitrum transaction is associated with exactly one Ethereum block and one Arbitrum block.\nEthereum (or parent chain) block numbers within Arbitrum​\nAccessing block numbers within an Arbitrum smart contract (i.e., block.number in Solidity) will return a value close to (but not necessarily exactly) the block number of the first non-Arbitrum ancestor chain where the sequencer received the transaction.\nThe \"first non-Arbitrum ancestor chain\" is:\n\nEthereum, if the chain is an L2 chain on top of Ethereum, or an L3 chain on top of an Arbitrum chain\nThe parent chain, if it's not Ethereum or an Arbitrum chain (for example, a chain that settles to Base)\n\n// some Arbitrum contract:block.number // => returns the approximate block number of the first non-Arbitrum ancestor chain\nAs a general rule, any timing assumptions a contract makes about block numbers and timestamps should be considered generally reliable in the longer term (i.e., on the order of at least several hours) but unreliable in the shorter term (minutes). (These are generally the same assumptions one should operate under when using block numbers directly on Ethereum!) For how this affects specific Solidity operations like block.number and block.timestamp, see Solidity support.\nEIP-2935 differenceEIP-2935 adds another way to retrieve block hashes by making a call to a contract. The contract is at the same address and has the same interface as the original. It was modified to have a larger buffer and different code, but it remains usable in the same way to retrieve past L2 block hashes.\nArbitrum block numbers​\nArbitrum blocks have their own block numbers, starting at 0 at the Arbitrum genesis block and updating sequentially.\nArbOS and the sequencer are responsible for delineating when one Arbitrum block ends and the next one begins. However, block creation depends entirely on chain usage, meaning that block production only occurs when there are transactions to sequence. In active chains, one can expect to see Arbitrum blocks produced at a relatively steady rate. In less active chains, block production might be sporadic depending on the rate at which transactions are received.\nA client that queries an Arbitrum node's RPC interface (e.g., transaction receipts) will receive the transaction's Arbitrum block number as the standard block number field. The block number of the first non-Arbitrum ancestor chain will also be included in the added l1BlockNumber field.\nconst txnReceipt = await arbitrumProvider.getTransactionReceipt('0x...');/** txnReceipt.l1BlockNumber => Approximate block number of the first non-Arbitrum ancestor chain*/\nThe Arbitrum block number can also be retrieved within an Arbitrum contract via the ArbSys precompile:\nArbSys(100).arbBlockNumber() // returns Arbitrum block number\nExample​\nThe following example illustrates timings on a chain that settles to Ethereum (similar to Arbitrum One), although it also applies to L3 chains that settle to an Arbitrum chain.\nWall clock time12:00 am12:00:15 am12:00:30 am12:00:45 am12:01 am12:01:15 amEthereum block.number100010011002100310041005Chain's block.number *100010001000100010041004Chain's block number (from RPCs) **370000370005370006370008370012370015\nInfotxnReceipt.blockNumber => Arbitrum block number_* The chain's block.number: updated to sync with Ethereum's block.number every 13 to 15 seconds (occasionally longer).\n** Chain's block number from RPCs: note that this can be updated multiple times per Ethereum block (this lets the sequencer give sub-Ethereum-block-time transaction receipts.)\nCase study: the Multicall contract​\nThe Multicall contract provides a valuable case study for the differences between various block numbers.\nThe canonical implementation of Multicall returns the value of block.number. When used out of the box, some applications may exhibit unintended behavior.\nYou can find a version of the adapted Multicall2 deployed on Arbitrum One at 0x842eC2c7D803033Edf55E478F461FC547Bc54EB2.\nBy default, the getBlockNumber, tryBlockAndAggregate, and aggregate functions return the child chain block number. This function allows you to use this value to compare your state against the tip of the chain.\nThe getL1BlockNumber function is queriable if applications need to surface the block number of the first non-Arbitrum ancestor chain.\nBlock timestamps: Arbitrum vs. Ethereum​\nBlock timestamps on Arbitrum are not linked to the timestamp of the parent chain block. They are updated every child chain block based on the sequencer's clock. These timestamps must follow these two rules:\n\nMust always be equal to or greater than the previous child chain block timestamp\nMust fall within the established boundaries (24 hours earlier than the current time or one hour in the future). More on this below.\n\nFurthermore, for transactions that are force-included from the parent chain (bypassing the Sequencer), the block timestamp will be equal to either the parent chain timestamp when the transaction was put in the Delayed Inbox on the parent chain (not when it was force-included), or the child chain timestamp of the previous child chain block, whichever of the two timestamps is greater.\nTimestamp boundaries of the sequencer​\nAs mentioned, block timestamps are usually set based on the sequencer's clock. Because there's a possibility that the Sequencer fails to post batches on the parent chain (i.e., Ethereum) for a period of time, it should have the ability to slightly adjust the timestamp of the block to account for those delays and prevent any potential reorganizations of the chain. To limit the degree to which the Sequencer can adjust timestamps, some boundaries are set, currently to 24 hours earlier than the current time, and one hour in the future.Block gas limitBlock numbers: Arbitrum vs. EthereumEthereum (or parent chain) block numbers within ArbitrumArbitrum block numbersExampleCase study: the Multicall contractBlock timestamps: Arbitrum vs. EthereumTimestamp boundaries of the sequencer","tokens":2217,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263811986,"hash":"f382509ef4ef906f23f1a64fdd43561f71d49792"}
{"url":"https://ethresear.ch/t/linearly-homomorphic-signatures-for-rlnc/24072/2","domain":"ethresear.ch","title":"Linearly-homomorphic signatures for RLNC - Cryptography - Ethereum Research","text":"Cryptography\n\n networking\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 6\n\n 2 / 3\n\n Feb 25\n\n Mar 5\n\n post by arantxazapico on Feb 6\n\n arantxazapico\n\n Authors: Dan Boneh, @b-wagn, @arantxazapico\nWe thank Gottfried Herold for dicussion and feedback.\nIntro: RLNC for Ethereum\nAs suggested in this post, Ethereum can benefit from Random Linear Network Coding (RLNC) to speed up the network. This approach avoids sending full blocks during propagation, thereby significantly reducing the amount of data in transit. This will work as follows:\nThe Block Proposer P_{prop}𝑃𝑝𝑟𝑜𝑝 can parse the block as a matrix \\mathbf{M}=(\\vec{m}_1,\\ldots,\\vec{m}_N)\\in(\\mathbb{F}^M)^N.𝐌 =(⃗𝑚1,…,⃗𝑚𝑁) ∈(𝔽𝑀)𝑁. Instead of distributing the entire block, it can send N𝑁 linearly independent vectors in the subspace A𝐴 generated by the columns of the matrix. That is, vectors of the form \\vec{v}= \\mathbf{M} \\cdot \\vec{a} \\in \\mathbb{F}^M⃗𝑣 =𝐌 ⋅⃗𝑎 ∈𝔽𝑀 for some \\vec{a}\\in \\mathbb{F}^N⃗𝑎 ∈𝔽𝑁. Along with each vector \\vec{v} \\in \\mathbb{F}^M⃗𝑣 ∈𝔽𝑀 the proposer P_{prop}𝑃𝑝𝑟𝑜𝑝 sends:\n\nthe coefficients vector \\vec{a} \\in \\mathbb{F}^N⃗𝑎 ∈𝔽𝑁,\nsuccinct homomorphic commitments\n\n \\vec{\\mathsf{C}} = (\\mathsf{C}_1,\\ldots,\\mathsf{C}_N)⃗𝖢 =(𝖢1,…,𝖢𝑁) to the vectors \\vec{m}_1,\\ldots,\\vec{m}_N \\in \\mathbb{F}^M⃗𝑚1,…,⃗𝑚𝑁 ∈𝔽𝑀 respectively, and\na BLS signature \\sigma𝜎 on the tuple (\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}})(⃗𝑣,⃗𝑎,⃗𝖢) using P_{prop}𝑃𝑝𝑟𝑜𝑝's secret key.\n\nThis way, P_{prop}𝑃𝑝𝑟𝑜𝑝 sends (\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}}, \\sigma)(⃗𝑣,⃗𝑎,⃗𝖢,𝜎) to each peer in its mesh, which is only (M + N)(𝑀 +𝑁) field elements plus N𝑁 commitments and a signature, instead of the entire block \\mathbf{M}𝐌 and a signature on its header.\nOn input (\\mathsf{pk},\\vec{v}, \\vec{a}, \\vec{\\mathsf{C}},\\sigma)(𝗉𝗄,⃗𝑣,⃗𝑎,⃗𝖢,𝜎), the Receiving peers verify the signature w.r.t. \\mathsf{pk}𝗉𝗄, and can verify \\vec v⃗𝑣 is indeed in the subspace signed by P_{prop}𝑃𝑝𝑟𝑜𝑝 and vector \\vec a⃗𝑎 contains the correct coefficients by checking\n\n\\mathsf{Commit}(\\vec{v})= \\sum_{j=1}^N a_i \\mathsf{C}_i \n𝖢𝗈𝗆𝗆𝗂𝗍(⃗𝑣)=𝑁∑𝑗=1𝑎𝑖𝖢𝑖\nUpon receiving k𝑘 tuples \\bigl\\{(\\mathsf{pk}_i,\\vec{v}_i, \\vec{a}_i, \\vec{\\mathsf{C}}_i,\\sigma_i)\\bigr\\}_{i=1}^k{(𝗉𝗄𝑖,⃗𝑣𝑖,⃗𝑎𝑖,⃗𝖢𝑖,𝜎𝑖)}𝑘𝑖=1 and after verifying that all the vectors \\vec{v}_1,\\ldots,\\vec{v}_k⃗𝑣1,…,⃗𝑣𝑘 are in A𝐴 and the correctness of the vectors \\vec a_i⃗𝑎𝑖, peer P𝑃 can become a Sending Peer. Let \\mathbf{V} \\in \\mathbb{F}^{M \\times k}𝐕 ∈𝔽𝑀×𝑘 be the matrix whose columns are \\vec{v}_1,\\ldots,\\vec{v}_k⃗𝑣1,…,⃗𝑣𝑘, and let \\mathbf{A} \\in \\mathbb{F}^{N \\times k}𝐀 ∈𝔽𝑁×𝑘 be the matrix whose columns are \\vec{a}_1,\\ldots,\\vec{a}_k⃗𝑎1,…,⃗𝑎𝑘. Since the received tuples are valid, we know that\n \\mathbf{V} = \\mathbf{M} \\cdot \\mathbf{A}. \\tag{1}𝐕 =𝐌 ⋅𝐀.\nThe peer samples a new vector \\vec{r} \\in\\mathbb{F}^k⃗𝑟 ∈𝔽𝑘, sets\n\n\\vec{v}' = \\mathbf{V} \\cdot \\vec{r} \\in \\mathbb{F}^{M} \\qquad\\text{and}\\qquad \\vec{a}' = \\mathbf{A} \\cdot \\vec{r} \\in \\mathbb{F}^{N},\n⃗𝑣′=𝐕⋅⃗𝑟∈𝔽𝑀and⃗𝑎′=𝐀⋅⃗𝑟∈𝔽𝑁,\nand sends (\\mathsf{pk},\\vec{v}', \\vec{a}', \\vec{\\mathsf{C}},\\sigma)(𝗉𝗄,⃗𝑣′,⃗𝑎′,⃗𝖢,𝜎) to its peers. Observe that \\vec{v}' = \\mathbf{M} \\cdot \\vec{a}'⃗𝑣′ =𝐌 ⋅⃗𝑎′, as required for a valid broadcast (indeed, we simply multiplied both sides of (1)(1) by \\vec{r}⃗𝑟).\nAfter receiving N𝑁 linearly independent vectors \\vec v_1, \\ldots, \\vec v_N \\in \\mathbb{F}^M⃗𝑣1,…,⃗𝑣𝑁 ∈𝔽𝑀 with corresponding vectors of coefficients \\vec b_1, \\ldots, \\vec b_N \\in \\mathbb{F}^N⃗𝑏1,…,⃗𝑏𝑁 ∈𝔽𝑁 such that \\vec v_i=\\sum_{i=1}^N b_{ij}\\vec m_j⃗𝑣𝑖 =∑𝑁𝑖=1𝑏𝑖𝑗⃗𝑚𝑗 for all i=1,\\ldots.N𝑖 =1,….𝑁, the receiver P𝑃 can be a Reconstructor and use those linear combinations to recover (\\vec m_1, \\ldots, \\vec m_N)(⃗𝑚1,…,⃗𝑚𝑁) and thus the entire block \\mathbf{M}𝐌.\nAs noted in the original post, the communication problem with this approach is twofold: each new vector in A𝐴 travels along with N𝑁 commitments and N𝑁 coefficients.\nIn this post, we explain how Linearly-homomorphic Signatures and in particular the work of Boneh, Freeman, Katz, and Waters (BFKW) from 2008 can prevent the communication of multiple commitments across the peers.\nDisclaimer:The ideas we present below already exist in the literature or have appeared in previous ethresearch discussions. We do not claim scientific novelty. Our goal is to collect and summarize these ideas in one place, to save others from repeatedly rediscovering the same techniques through scattered chats and threads.\nLinearly-homomorphic Signatures\nA Linearly-homomorphic signature scheme (LHSS) is a signing scheme for which only the secret key owner can create signatures on fresh vectors of its choice. Any entity with access to the public key can combine these signatures to create just one that verifies with respect to any linear combination of the original ones, that is, can sign any vector in the subspace generated by the original messages. Formally:\nDefinition (Boneh et al., 2008): A linearly homomorphic signature scheme (LHSS) over a vector space A\\subseteq\\mathbb{F}^N𝐴 ⊆𝔽𝑁 is a tuple of probabilistic, polynomial-time algorithms (\\mathsf{Setup, Sign, Combine, Verify})(𝖲𝖾𝗍𝗎𝗉,𝖲𝗂𝗀𝗇,𝖢𝗈𝗆𝖻𝗂𝗇𝖾,𝖵𝖾𝗋𝗂𝖿𝗒) with the following functionality:\n\n\\mathsf{Setup}(n, pp)\\to(\\mathsf{sk,pk})𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) →(𝗌𝗄,𝗉𝗄): On input a security parameter n𝑛 and additional public parameters pp𝑝𝑝 that include the dimension N𝑁 of the ambient space and the dimension k𝑘 of subspaces to be signed, this algorithm outputs a secret key \\mathsf{sk}𝗌𝗄 and a public key \\mathsf{pk}𝗉𝗄.\n\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m)\\to\\sigma𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚) →𝜎: On input a secret key \\mathsf{sk}𝗌𝗄, an identifier \\mathsf{id}\\in\\{0, 1\\}^n𝗂𝖽 ∈{0,1}𝑛, and a vector \\vec m\\in A,⃗𝑚 ∈𝐴, this algorithm outputs a signature \\sigma𝜎.\n\\mathsf{Combine}(\\mathsf{pk}, \\mathsf{id}, \\{(a_i, \\sigma_i)\\}_{i=1}^k)\\to\\sigma𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{(𝑎𝑖,𝜎𝑖)}𝑘𝑖=1) →𝜎: On input a public key \\mathsf{pk}𝗉𝗄, an identifier \\mathsf{id}𝗂𝖽, and a set of tuples \\{(a_i, \\sigma_i)\\}_{i=1}^k{(𝑎𝑖,𝜎𝑖)}𝑘𝑖=1 with a_i\\in\\mathbb{F}𝑎𝑖 ∈𝔽, this algorithm outputs a signature \\sigma𝜎. (This \\sigma𝜎 is intended to be a signature on \\sum_{i=1}^k a_i \\vec m_i∑𝑘𝑖=1𝑎𝑖⃗𝑚𝑖.)\n\\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ)\\to1/0𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎) →1/0: On input a public key \\mathsf{pk}𝗉𝗄, an identifier \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛, a vector \\vec v\\in A⃗𝑣 ∈𝐴, and a signature \\sigma𝜎, this algorithm outputs either 00 (reject) or 11 (accept).\n\nFor completeness, we require that for each (\\mathsf{sk, pk})(𝗌𝗄,𝗉𝗄) output by \\mathsf{Setup}(n, pp)𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝), we have that:\n\nFor all \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 and \\vec v\\in A⃗𝑣 ∈𝐴, if \\sigma\\gets\\mathsf{Sign}(\\mathsf{sk, id}, \\vec v)𝜎 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑣) then \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎) =1.\nFor all \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 and all sets of triples \\{(a_i, \\sigma_i, \\vec v_i)\\}_{i=1}^k{(𝑎𝑖,𝜎𝑖,⃗𝑣𝑖)}𝑘𝑖=1 if it holds that \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec m_i, σ_i)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑚𝑖,𝜎𝑖) =1 for all i \\in [k]𝑖 ∈[𝑘], then \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id}, \\sum_{i=1}^\\ell a_i \\vec m_i, \\mathsf{Combine}(\\mathsf{pk}, \\mathsf{id}, \\{a_i, \\sigma_i)\\}_{i=1}^k)= 1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,∑ℓ𝑖=1𝑎𝑖⃗𝑚𝑖,𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{𝑎𝑖,𝜎𝑖)}𝑘𝑖=1) =1.\n\nThe security notion we need to capture here is that no party other than the \\mathsf{sk}𝗌𝗄 holder should be able to claim a signature \\sigma^*𝜎∗ on a vector \\vec v^*⃗𝑣∗ that verifies with respect to \\mathsf{pk}𝗉𝗄 unless \\vec v^*\\in A⃗𝑣∗ ∈𝐴 . Therefore, we define the following game between a challenger and an adversary:\n\nSetup Phase. The challenger runs (\\mathsf{sk,pk})\\gets\\mathsf{Setup}(n, pp)(𝗌𝗄,𝗉𝗄) ←𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) and sends \\mathsf{pk}𝗉𝗄 to the adversary \\mathcal{A}.A.\nQuery Phase. The adversary now makes a polynomial number q𝑞 of oracle queries, where the i𝑖-th query has the following form:\n\nThe oracle takes as input a set of vectors \\vec{v}_{i,1},\\dots,\\vec{v}_{i,k} \\in \\mathbb{F}^M⃗𝑣𝑖,1,…,⃗𝑣𝑖,𝑘 ∈𝔽𝑀.\nWe let A_i \\subseteq \\mathbb{F}^N𝐴𝑖 ⊆𝔽𝑁 be the subspace generated by these vectors.\nThe oracle samples \\mathsf{id}\\gets \\{0,1\\}^n𝗂𝖽 ←{0,1}𝑛, and computes \\sigma_{i,j}\\gets\\mathsf{Sign}(\\mathsf{sk}, \\mathsf{id}_i, \\vec{v}_{i,j})𝜎𝑖,𝑗 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽𝑖,⃗𝑣𝑖,𝑗) for all j=1, \\ldots, k𝑗 =1,…,𝑘.\nIt outputs (\\mathsf{id}_i, (\\sigma_{i,j})_{j=1}^k)(𝗂𝖽𝑖,(𝜎𝑖,𝑗)𝑘𝑗=1).\n\nForgery Phase. The adversary outputs a triple (\\mathsf{id}^*, \\vec v^*\\neq 0, \\sigma^*)(𝗂𝖽∗,⃗𝑣∗ ≠0,𝜎∗). We say that it wins the game if the following two hold:\n\nValid signature: we have \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id}^*,\\vec v^*, \\sigma^*)=1𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽∗,⃗𝑣∗,𝜎∗) =1;\nFreshness: we have \\mathsf{id}^*\\notin\\{\\mathsf{id}_i\\}_{i=1}^q𝗂𝖽∗ ∉{𝗂𝖽𝑖}𝑞𝑖=1 or \\vec v^*\\notin A_i⃗𝑣∗ ∉𝐴𝑖 for every i\\in [q]𝑖 ∈[𝑞] with \\mathsf{id}^* = \\mathsf{id}_i𝗂𝖽∗ =𝗂𝖽𝑖.\n\nThe scheme is secure if no efficient (i.e., PPT) adversary wins this game with non-negligible probability.\nIntuitively, this security property states that any signature that verifies with respect to the given public key \\mathsf{pk}𝗉𝗄 and an identity \\mathsf{id}^*𝗂𝖽∗, must be on a vector in the span of the vectors that the honest signer signed with respect to \\mathsf{id}^*𝗂𝖽∗.\nLinearly-homomorphic Signatures in RLNC\nBelow, we explain how the BFKW Linearly-homomorphic Signature scheme can be used to replace commitments in the RLNC protocol.\nThe block proposer owns the secret key \\mathsf{sk}𝗌𝗄 and thus is the only one that can create “fresh” signatures. In this setting, we require that they parse the block as a matrix and sign the columns of it.\nThat means the proposer gets to set the subspace A𝐴. All other users can combine those signatures to create signatures on linear combinations of the vectors that define the block (by the completeness property).\nBy the security property, if a signature verifies with respect to the block proposer’s public key, it is then a linear combination of the original signatures, and thus a signature on a linear combination of the original vectors.\nTo generate new coefficients, or even to reconstruct the original vectors after receiving N𝑁 linearly-independent vectors, peer P𝑃 has access to the new signature \\sigma𝜎 and a set of coefficients \\vec a⃗𝑎 that the sender claims to be the coefficients that combine the original signatures \\sigma_1, \\ldots, \\sigma_N𝜎1,…,𝜎𝑁 to \\sigma𝜎. The receiving peer needs to verify not only that \\sigma𝜎 is a linear combination of the block proposer’s signatures, which is true iff \\mathsf{Verify}𝖵𝖾𝗋𝗂𝖿𝗒 outputs 11, but also that the coefficients of that linear combination are indeed the ones in \\vec b⃗𝑏.\nIn order to verify each signatures with respect to the specific coefficients that conform the linear combination, we formally extend the functionality of LHS schemes by slightly modifying its syntax as hinted in the seminal work:\n\n\\mathsf{RLNC}.\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m_i, i):𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚𝑖,𝑖) : Let \\vec e_i\\in\\mathbb{F}^N⃗𝑒𝑖 ∈𝔽𝑁 be the unity vector that takes value 11 in the position i𝑖 and 00 everywhere else (that is, is the i𝑖-th vector in the canonical basis of \\mathbb{F}^N𝔽𝑁) and output \\sigma\\gets\\mathsf{Sign}(\\mathsf{sk, id}, \\vec m_i|| \\vec e_i)𝜎 ←𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚𝑖||⃗𝑒𝑖)\n\\mathsf{RLNC}.\\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, \\sigma, \\vec a)\\to1/0𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎) →1/0: Set \\vec v'=\\vec v|| \\vec a⃗𝑣′ =⃗𝑣||⃗𝑎 and output \\mathsf{Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v', \\sigma)𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣′,𝜎)\n\nEssentially, by adding the vector \\vec e_i⃗𝑒𝑖 to the message \\vec m_i⃗𝑚𝑖, we will have that the last N𝑁 elements of any signed vector \\vec v⃗𝑣 will be the unique coefficients that represent \\vec v⃗𝑣 as a linear combination of the messages \\{\\vec m_i\\}{⃗𝑚𝑖} signed by the \\mathsf{sk}𝗌𝗄 holder. Intuitively, by the unforgeability property of the LHSS, if the \\mathsf{Verify}𝖵𝖾𝗋𝗂𝖿𝗒 algorithm outputs 11 on input \\vec v, \\vec a⃗𝑣,⃗𝑎, then \\vec v=\\sum a_i \\vec m_i⃗𝑣 =∑𝑎𝑖⃗𝑚𝑖 except with negligible probability.\nThreat Model\nWhen implementing RLNC for block propagation, we assume an honest block proposer and set aside general networking attacks. Still, the system must remain resilient against Denial of Service (DoS) attacks—specifically pollution attacks. In this scenario, an adversary attempts to disrupt the propagation of block \\mathbf M𝐌 by injecting a malicious vector \\vec v′\\notin A⃗𝑣 ′ ∉𝐴, with A𝐴 being the subspace defined by the original block data. This is covered by the security property of LHS, that requests that no adversary can generate valid signatures for vectors that are not in A𝐴.\nThe inclusion of a string \\mathsf{id}\\in\\{0,1\\}^n𝗂𝖽 ∈{0,1}𝑛 within the signature serves as a unique identifier for a specific subspace. This allows a participant to sign multiple subspaces using the same public key while preventing vectors from different spaces from being combined, e.g., if this participant takes the role of the block proposer in multiple slots. Specifically, if a user signs subspace V_1𝑉1 at time t_1𝑡1 and subspace V_2𝑉2 at time t_2𝑡2, no party should be able to forge signatures on vectors in \\mathsf{span}(V_1\\cup V_2)𝗌𝗉𝖺𝗇(𝑉1 ∪𝑉2) that verify against \\mathsf{pk}𝗉𝗄. While the BFKW protocol requires \\mathsf{id}𝗂𝖽 to be unpredictable, the block propagation setting further requires \\mathsf{id}𝗂𝖽 to be tied to a specific block. To satisfy both conditions, we set \\mathsf{id}=H(\\mathsf{num_{slot}},\\mathsf{salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍), where \\mathsf{salt}𝗌𝖺𝗅𝗍 is sampled randomly by the proposer during signing, H𝐻 is a hash function (modeled as a random oracle), and \\mathsf{num_{slot}}𝗇𝗎𝗆𝗌𝗅𝗈𝗍 is the slot number of the proposed block.\nThe BFKW scheme for RLNC\nWe present the linearly-homomorphic signature scheme in BFKW with the new RLNC-specific syntax. Note that BFKW works similarly to BLS signatures that are already implemented in Ethereum. The main difference is that instead of signing messages, the users sign vectors and thus compute M𝑀 hashes per signature (where M𝑀 is the dimension of the vectors) instead of one. Consider a bilinear group (\\mathbb{G}_1,\\mathbb{G}_2, \\mathbb{G}_T, p, e)(𝔾1,𝔾2,𝔾𝑇,𝑝,𝑒), g_1, g_2𝑔1,𝑔2 generators of \\mathbb{G}_1𝔾1 and \\mathbb{G}_2𝔾2, respectively, and a hash function H:\\{0,1\\}^*\\times \\{0,1\\}^*\\to \\mathbb{G}_2𝐻 :{0,1}∗ ×{0,1}∗ →𝔾2 modeled as a random oracle.\n\n\\mathsf{RLNC.Setup}(n, pp)\\to(\\mathsf{sk,pk})𝖱𝖫𝖭𝖢.𝖲𝖾𝗍𝗎𝗉(𝑛,𝑝𝑝) →(𝗌𝗄,𝗉𝗄): Sample \\mathsf{sk}\\gets\\mathbb{F}𝗌𝗄 ←𝔽, set \\mathsf{pk}=g_1^{\\mathsf{sk}}𝗉𝗄 =𝑔𝗌𝗄1.\nLet A=\\mathsf{span}\\{\\vec m_1,\\ldots, \\vec m_N\\}, \\vec m_i\\in\\mathbb{F}^M𝐴 =𝗌𝗉𝖺𝗇{⃗𝑚1,…,⃗𝑚𝑁},⃗𝑚𝑖 ∈𝔽𝑀.\n\\mathsf{RLNC.Sign}(\\mathsf{sk, id}, \\vec m, N)\\to\\sigma𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝗌𝗄,𝗂𝖽,⃗𝑚,𝑁) →𝜎:\n\nSet \\vec m'=\\vec m || \\vec e_i⃗𝑚′ =⃗𝑚||⃗𝑒𝑖 for \\vec e_i\\in\\mathbb{F}^N⃗𝑒𝑖 ∈𝔽𝑁 being the i𝑖-th unity vector and i𝑖 the position of \\vec m⃗𝑚 in the ordered basis of A𝐴.\nOutput \\sigma\\in\\mathbb{G}_2𝜎 ∈𝔾2 as follows:\n\n\\sigma=\\left(\\prod\\limits_{s=1}^M H(\\mathsf{id},s)^{m'_{s}}\\right)^{\\mathsf{sk}}\n𝜎=(𝑀∏𝑠=1𝐻(𝗂𝖽,𝑠)𝑚′𝑠)𝗌𝗄\n\n\\mathsf{RLNC.Combine}(\\mathsf{pk}, \\mathsf{id}, \\{(a_i, \\sigma_i, \\vec v_i)\\}_{i=1}^k)\\to(\\vec v, \\sigma, \\vec a)𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝗉𝗄,𝗂𝖽,{(𝑎𝑖,𝜎𝑖,⃗𝑣𝑖)}𝑘𝑖=1) →(⃗𝑣,𝜎,⃗𝑎):\n\\vec v=\\sum_{i=1}^k a_i\\vec v_i, \\qquad \\sigma=\\prod_{i=1}^k \\sigma_i^{a_i}\n⃗𝑣=𝑘∑𝑖=1𝑎𝑖⃗𝑣𝑖,𝜎=𝑘∏𝑖=1𝜎𝑎𝑖𝑖\n\n\\mathsf{RLNC.Verify}(\\mathsf{pk}, \\mathsf{id},\\vec v, σ, \\vec a)\\to1/0𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝗉𝗄,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎) →1/0:\n\nSet \\vec v'=\\vec v||\\vec a⃗𝑣′ =⃗𝑣||⃗𝑎\nOutput 11 if and only if\n\ne\\big(g_1, \\sigma\\big)=e\\left(pk, \\prod_{s=1}^M H(\\mathsf{id}, s)^{v'_s}\\right)\n𝑒(𝑔1,𝜎)=𝑒(𝑝𝑘,𝑀∏𝑠=1𝐻(𝗂𝖽,𝑠)𝑣′𝑠)\n\nSecurity: The protocol presented above is complete and secure in the random oracle model under the co-computational Diffie Hellman (co-CDH) assumption in (\\mathbb{G}_1, \\mathbb{G}_2)(𝔾1,𝔾2). The co-CDH assumption in (\\mathbb{G}_1, \\mathbb{G}_2)(𝔾1,𝔾2) states that it is computationally infeasible to compute g_1^x\\in\\mathbb{G}_1𝑔𝑥1 ∈𝔾1 given g_1\\in\\mathbb{G}_1𝑔1 ∈𝔾1 and g_2, g_2^x\\in\\mathbb{G}_2𝑔2,𝑔𝑥2 ∈𝔾2.\n\nRLNC with Linearly-homomorphic Signatures\nThe result of replacing homomorphic commitments by the linearly-homomophic signature scheme of BFKW in the protocol proposed here is the following:\nProposer\nProposer’s key pair is (sk, pk=g_2^{sk})(𝑠𝑘,𝑝𝑘 =𝑔𝑠𝑘2). On input block \\mathbf{M}\\in\\mathbb{F}^{M\\times N}𝐌 ∈𝔽𝑀×𝑁, the proposer samples \\mathsf{salt}\\gets\\{0,1\\}^n𝗌𝖺𝗅𝗍 ←{0,1}𝑛 and sets \\mathsf{id}=H(\\mathsf{num_{slot}},\\mathsf{salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍).\n\nFor each i\\in[N]:𝑖 ∈[𝑁] :\n\n\\sigma_i\\gets \\mathsf{RLNC.Sign}(sk, \\mathsf{id}, \\vec m_i, i):𝜎𝑖 ←𝖱𝖫𝖭𝖢.𝖲𝗂𝗀𝗇(𝑠𝑘,𝗂𝖽,⃗𝑚𝑖,𝑖) :\n\nFor each user u_j\\in D𝑢𝑗 ∈𝐷\n\nSample \\vec a_j\\gets \\mathbb{F}^N⃗𝑎𝑗 ←𝔽𝑁\n\\sigma_j\\gets\\mathsf{RLNC.Combine}(pk, \\mathsf{id}, {(a_{j,i}, \\sigma_i)}_{i=1}^N)𝜎𝑗 ←𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑝𝑘,𝗂𝖽,(𝑎𝑗,𝑖,𝜎𝑖)𝑁𝑖=1)\nSend \\pi_j=(\\mathsf{salt}, \\vec v_j, \\vec a_j, \\sigma_j)𝜋𝑗 =(𝗌𝖺𝗅𝗍,⃗𝑣𝑗,⃗𝑎𝑗,𝜎𝑗), where \\vec v_j=\\sum_{j=1}^N {a_{i,j}} \\vec m_i⃗𝑣𝑗 =∑𝑁𝑗=1𝑎𝑖,𝑗⃗𝑚𝑖\n\nReceiving Peers\n\nParse (\\mathsf{salt}, \\vec v, \\vec a, \\sigma)\\gets \\pi(𝗌𝖺𝗅𝗍,⃗𝑣,⃗𝑎,𝜎) ←𝜋\nOutput b\\gets\\mathsf{RLNC.Verify}(pk, \\mathsf{id}, \\vec v, \\sigma, \\vec a)𝑏 ←𝖱𝖫𝖭𝖢.𝖵𝖾𝗋𝗂𝖿𝗒(𝑝𝑘,𝗂𝖽,⃗𝑣,𝜎,⃗𝑎)\n\nSending Peers\nOn input (\\pi_1, \\ldots, \\pi_L)(𝜋1,…,𝜋𝐿):\n\nParse (\\mathsf{salt}, \\vec v_i, \\vec a_i, \\sigma_i)\\gets \\pi_i(𝗌𝖺𝗅𝗍,⃗𝑣𝑖,⃗𝑎𝑖,𝜎𝑖) ←𝜋𝑖 for all i\\in [L]𝑖 ∈[𝐿]\nSample \\vec a'\\gets\\mathbb{F}^L⃗𝑎′ ←𝔽𝐿\nCompute \\mathsf{id}=H(\\mathsf{num_{slot}, salt})𝗂𝖽 =𝐻(𝗇𝗎𝗆𝗌𝗅𝗈𝗍,𝗌𝖺𝗅𝗍)\n\\sigma\\gets\\mathsf{RLNC.Combine}(pk, \\mathsf{id}, (a'_i, \\sigma_i)_{i=1}^L)𝜎 ←𝖱𝖫𝖭𝖢.𝖢𝗈𝗆𝖻𝗂𝗇𝖾(𝑝𝑘,𝗂𝖽,(𝑎′𝑖,𝜎𝑖)𝐿𝑖=1)\nSet \\vec v=\\sum_{i=1}^L a'_i \\vec v_i⃗𝑣 =∑𝐿𝑖=1𝑎′𝑖⃗𝑣𝑖\nRedefine vector \\vec a⃗𝑎 with a_i=a'_i\\sum_{i=1}^L a_j𝑎𝑖 =𝑎′𝑖∑𝐿𝑖=1𝑎𝑗\nOutput \\pi=(\\vec v, \\vec a, \\sigma)𝜋 =(⃗𝑣,⃗𝑎,𝜎)\n\nOn the efficiency\nBelow we set a comparison with the proposal by Potuz. Note that in the LHS approach, we trade efficiency of P_{prop}𝑃𝑝𝑟𝑜𝑝 and the receiving/sender peers to avoid sending N𝑁 group elements to the network.\n\nProposer:\n\nSigning a message involves computing M𝑀 hashes H𝐻 to \\mathbb{G}_2𝔾2 and then performin M𝑀 group operations in \\mathbb{G}_2𝔾2, whereas in the previous approach involved only M𝑀 group operations for a Pedersen commitment.\n\nReceiver:\n\nVerifying the signature is M𝑀 \\mathbb{G}_1𝔾1 operations and two pairings. Verifying a commitment is 2M2𝑀 \\mathbb{G}𝔾 operations.\n\nSender:\n\nPerforms L\\mathbb{G}_1𝐿𝔾1 operations to compute the new signature in addition to the LM𝐿𝑀 field operations it already performs in the previous approach to compute the new vector \\vec v⃗𝑣.\n\nCommunication:\n\nEach signature is 1\\mathbb{G}_21𝔾2 element, same as the Pedersen commitments. With the previous approach, we have N𝑁 commitments that can be communicated as a sidecar, while in the signature approach we have 11 group element being communicated per time.\n\nReconstruction: Works the same way as before, after receiving N𝑁 linearly-independent vectors and verifying they are indeed in the subspace A𝐴, any node can reconstruct block \\mathbf M𝐌 by solving a system of equations.\n\nPedersen Commitments\nLinearly-Homomorphic Signatures\n\nCommitting(P_{prop}𝑃𝑝𝑟𝑜𝑝) to one vector\nM\\ \\mathbb{G}𝑀 𝔾 ops\nM\\ \\mathbb{G}_2𝑀 𝔾2 ops, M𝑀 hashes to \\mathbb{G}_2𝔾2\n\nReceiver (Verify \\vec v\\in A⃗𝑣 ∈𝐴)\nCommit\nCommit + 22 pairings\n\nSender\nLM\\ \\mathbb{F}𝐿𝑀 𝔽 ops\nLM\\ \\mathbb{F}𝐿𝑀 𝔽 ops, L \\ \\mathbb{G}_2𝐿 𝔾2 ops\n\nCommunication\nN\\ \\mathbb{G}𝑁 𝔾, N\\ \\mathbb{F}𝑁 𝔽\n1\\ \\mathbb{G}_21 𝔾2, N\\ \\mathbb{F}𝑁 𝔽\n\nFuture Work\nA natural extension of this work is the transition toward post-quantum (PQ) security. The BFKW scheme, while efficient, relies on the hardness of the co-CDH problem in bilinear groups, which is susceptible to attacks by large-scale quantum computers. To future proof RLNC-based block propagation, we should explore Linearly Homomorphic Signatures schemes based on post-quantum assumptions.\n\nThere are proposals which suggest that the commitments \\mathsf{C}_1, \\ldots, \\mathsf{C}_N𝖢1,…,𝖢𝑁 and the signature on them can travel the network independently of the newly generated vectors. ↩︎\n\n RLNC Optimizations\n\n Faster block/blob propagation in Ethereum\n\n 2\n\n read \n\n 8\n min\n\n 18 days later\n\n post by MoritzGrundei on Feb 25\n\n MoritzGrundei\n\n Great post!\nI agree that LHSSs are a very promising approach to the packet poisoning problem in RLNC systems. A few additional points come to mind.\nFirst, BFKW is a very interesting LHSS instantiation, but it is not the only one. For example, [1] proposes an alternative signature scheme based on signing an orthogonal vector to the subspace spanned by the extended content vectors (under discrete-log and CDH hardness assumptions). Operationally, it is attractive because it avoids pairing based cryptography as well as signature recombination at intermediate nodes, but it comes with a larger public-key (N+M𝑁 +𝑀 field elements).\nSecond (and maybe most importantly), there is a broader design tradeoff between packet-level integrity and generation-based integrity verification [2 Chapter 8.3]. LHSS gives packet-level integrity verification, i.e., each coded packet can be checked immediately. By contrast, generation-based schemes perform integrity verification over a full generation after decoding (or at generation granularity). The overhead-analysis done in [3] is a good reference point here. In short:\n\nGeneration-based approaches can have low overhead when packet poisoning probability is low (<3%), because the hash/authentication cost is amortised across a whole generation.\n\nLHSS / packet-level verification enables immediate detection and filtering (and one-hop containment), which can reduce wasted bandwidth and improve throughput when packet poisoning probability is moderate - high.\n\nAttributing the injection of poisoned packets to malicious actors (e.g. to slash malicious nodes) is straightforward in packet-level verification but this problem has also been solved through a dedicated protocol (e.g. the Rugby protocol as detailed in [4, Section 5]\n\nMoreover, generation-based approaches rely primarily on hash functions, which are generally easier to make post quantum secure than discrete-log/CDH-based signature systems. So if we re-evaluate the tradeoff under quantum-resistant requirements, the overhead balance will shift somewhat in favor of generation-based schemes.\nThird, LHSS usually have practical limitations with respect to the underlying field. LHSS constructions are usually defined over sufficiently large prime fields / EC of large prime order because their security depends on assumptions like discrete log / CDH in those groups. By contrast, RLNC implementations often benefit from extension fields for practical coding/decoding efficiency (see [2 Chapter 2]). Does this constraint also apply for BFKW?\nReferences\n\nZhao, F., Kalker, T., Médard, M., Han, K. J.\nSignatures for Content Distribution with Network Coding (IEEE ISIT 2007), DOI: 10.1109/ISIT.2007.4557283.\n\nMuriel Médard, Vipindev Adat Vasudevan, Morten Videbæk Pedersen & Ken R. Duffy, Network Coding for Engineers, Wiley-IEEE Press, 2025, ISBN 978-1-394-21729-8.\n\nKim, M., Lima, L., Zhao, F., Barros, J., Médard, M., Koetter, R., Kalker, T., Han, K.\nOn Counteracting Byzantine Attacks in Network Coded Peer-to-Peer Networks (arXiv:0904.2722; later JSAC version linked from arXiv).\n\nN. Nicolaou, O. Obi, A. Rajasekaran, A. Bergasov, A. Bezobchuk, K. M. Konwar, M. Meier, S. Paiva, H. P. Singh, S. Sinha, S. Vishwanath, and M. Médard, “OPTIMUMP2P: Fast and Reliable Gossiping in P2P Networks,” in 2025 21st International Conference on\n\n 8 days later\n\n post by arantxazapico on Mar 5\n\n arantxazapico\n\n Thanks for your feedback and questions!\n\nWe are aware of the existence of other LHSS schemes, which is why we first describe the solution as scheme-agnostic.We chose BFWK for its similarity to BLS, which are already implemented in Ethereum.\n\nI was not aware of the latest generation-based schemes, so thank you for pointing them out. Whether we can develop an efficient LHSS-based RLNC protocol that is also post-quantum remains an open question for us, but your comment makes sense to me.\n\nYes, it does.\n\n Powered by Discourse","tokens":6210,"squid":"ink-research","role":"Deep Scholar","at":1791263816332,"hash":"49d442b20d0193a8caeb7f8c954aa91fe269de74"}
{"url":"https://governance.aave.com/t/aave-finance-governance-process-v0/11402","domain":"governance.aave.com","title":"Aave Finance Governance Process v0 - Governance - Aave","text":"Aave Finance Governance Process v0 \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 5\n min\n\n Aave Finance Governance Process v0\n\n Contents\n\n Governance Processes\n\n Changes to Governance\n\n Jan 2023\n\n 1 / 5\n\n Jan 2023\n\n Aug 2024\n\n post by Kene_Anode on Jan 18, 2023\n\n Kene_Anode\n\n Orbit-Delegate\n\n Aave Finance Governance Process v0\nAuthors: @Kene_Anode, Bobbay_StableNode\nThe “Aave Governance Process” is an all-in-one document for contributing to Aave DAO. This document will be continuously updated by Aave DAO contributors.\nThis document aims to provide an overview of the different roles, flow and pathways for various stakeholders to participate in Aave DAO.\nContents\n\nGovernance Roles\n\nAave Guardians\nDelegates\nDelegators\nContributors\n\nRules and Values\n\nCode of Conduct\nValues\nEnforcement\n\nGovernance Processes\n\nDiscussions\nProposals\nWorking Groups\nFunding\nVoting\n\nProposal discussion\nQuorum\nProposal history\n\nChanges to Governance\n\nGovernance Roles.\nThere are four key roles in Aave Governance.\n\nAave Guardians: The Aave Guardians are a group of community-elected individuals and/or entities that form part of a 6/10 multi-sig with the sole responsibility of:\n\nProtecting the Aave Protocol against potential governance takeovers by having the ability to “veto” an AIP if it is deemed malicious.\nAllowing V3 markets to be upgraded following governance votes on Snapshot while an on-chain cross-chain governance module is implemented.\nFunctioning as a failsafe emergency actor to pause Aave markets.\n\nFor more information about the Aave Guardians, check out this Medium post about the Aave V2 Governance Process.\n\nDelegates: Delegates are community members who have received voting power from other community members or through self-delegation. Delegates are currently not compensated in Aave.\nDelegators: Delegators are community members who hold Aave or stkAAVE but have entrusted their voting power to another person. The person they delegated their voting power to is considered a delegate.\nContributors: Contributors are community members who participate in and dedicate their time to the Aave DAO. They participate by joining working groups, fulfilling bounties, and/or building on top of the Aave Protocol or for the DAO via grants while working towards completing shared goals.\n\nRules and Values\nAave does not generally have a Code of Conduct. However, the DAO has a set of policies that function as a set of governance-defined rules that control specific aspects of the protocol or the individual markets.\nThese policies are broadly classified into\n\nProtocol Policies: This regulates the overall behavior of the protocol and the various entities that participate within the Aave Ecosystem; these policies regulate specific aspects of the protocol related to safety, economics and expansion.\nMarket Policies: These policies are market specific and seek to impose safety measures that would overall protect the Aave Protocol from any cross-market contagion, which could spread to the entire protocol.\n\nTo learn more about Aave’s Policies, check out this site.\nGovernance Processes\nThe processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE/stkdAAVE holder or contributor.\nDiscussions\nMost governance discussions take place on the official Aave Governance Forum and the official Aave Discord Channels. It is recommended that all discussions in contemplation of a proposal start out on the Aave Governance Forum.\nProposals\nThere are generally two types of proposals in Aave Governance; these two general proposal classifications strictly refer to the maturity of a proposal in the Aave Governance Process.\n\nTEMP CHECK: TEMP CHECKs serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.\nARFC: Aave Request for Comment (ARFCs) are precursors to Aave Improvement Proposals (AIPs). Relevant service providers are formally invited to provide feedback on them, and the specification section of ARFCs should detail how the potential upcoming AIP will impact Aave protocol smart contracts.\n\nIn order to propose specific changes to the Aave Protocol that fall under the scopes listed below, the proposal format should abide by the specific guidelines stated.\nAave Improvement Proposal (AIP).\n\nAave Improvement Proposal: This is a formal proposal to improve the Aave Protocol; it is recommended that before submitting an AIP, an ARC should be submitted to the community to gather feedback.\nOnce the AIP has been written and reviewed, the AIP will be submitted via GitHub to begin the process of putting the AIP on-chain; for a step-by-step guide on uploading an AIP on-chain, check here.\n\nCaps Update Framework\nThis refers to a direct to AIP vote for cap changes or FreezeReserve() implementation if the following conditions are met:\n\nThe proposal is provided by a risk service provider or has received feedback from at least one risk service provider team.\nThe proposed cap change is not greater than a 100% increase of the current cap or the implementation of a cap.\nThe cap is being decreased.\nThe AIP is implementing a FreezeReserve().\n\nFor other situations, the normal governance process is applicable. To learn more about the Caps Update Framework, check out this forum post.\nThis framework is intended for All V3 liquidity pools. Relative to freezing reserves, this framework is intended for all Aave pools.\nAsset Onboarding Proposal.\n\nAsset Onboarding Proposal: This is a formal proposal that is used to onboard new assets onto the Aave Protocol. Asset onboarding proposals still follow the ARC and AIP route; however, there are specific requirements that contribute to a successful asset on-boarding proposal.\n\nTo summarise, here is an overview of the standard proposal process:\n\nPost a governance thread for 5 days\nSnapshot vote for 3 days (24 hours after gov thread)\nPost an AIP vote for 5 days (Minimum 80k required)\n\nThis takes process takes around 13-14 days.\nFast Track Proposal.\n\nFast Track Proposal: This express proposal path is designed to cater to emergencies where time is of the essence.\n\nThrough the expedited fast track process, the fast track process would follow this pattern:\n\nGovernance thread for 24h\nSnapshot with immediate vote open for 48h\nCommunity multisig enforcement\nFast-track requires an 80k AAVE quorum\n\nHowever, the scope of Fast-track proposals is limited to act on only Supply & Borrow caps with a 50% change.\nAave Service Providers.\nA number of other service providers also contribute to the development and maintenance of the Aave Protocol; these external entities function as independent contractors who act in the best interest of the Aave Protocol; they are as follows:\n\nBDG Labs\nGauntlet\nChaos Labs etc.\n\nAlthough there is no clear template to become a service provider, Aave enables service providers to contribute to Aave DAO. A template should be created to simplify this process.\nFunding.\nAave DAO has two pathways for funding:\n\nDirect funding through governance\nThe Aave Grants DAO\n\nDirect Funding Through Governance\nA number of contributions to the Aave protocol have been funded through Governance Proposals; clear examples of this are.\n\nThe governance for funding the development of Aave V3.\nThe governance vote for the renewal of the Aave’s Service Provider Agreement with Gauntlet.\n\nAave Grants DAO\nThe Aave Grants DAO was created to fund ideas and builders in the Aave ecosystem. The two-quarter pilot program had a grant budget of $1 million and an operating budget of $250,000 per quarter. Here is a link to the original grant proposal.\nThe Aave Grants DAO offers grants to innovation in the following areas:\n\nProtocol Development: This refers to direct technological innovation that translates directly into benefits for the Aave Protocol.\nApplications and Integrations: This refers to technological innovation that involves building on top of the Aave Protocol or leveraging Aave’s infrastructure to develop a product or service that translates into benefits for the Aave Ecosystem.\nDeveloper Tooling: This refers to building tools that assist developers in building within the Aave Ecosystem.\nCode Audits: Technical assistance that results in the improvement of the security, operations and/or maintenance of the Protocol’s code base is eligible for a grant from the Aave Grants DAO.\nEvents & Hackathons: These refers to events aimed at creating more brand visibility for Aave, along with allowing developers to build on top of or in partnership with Aave and get rewarded for their innovation.\nCommunity Efforts such as (Marketing and Education): Ensuring that the right information is actively promoted within the Aave community is an important aspect of the Aave DAOs growth, therefore efforts within this category are also eligible for a grant for the DAO.\n\nVoting.\nThe Aave DAO reaches a consensus on proposals via token voting. AAVE or stkAAVE holders are empowered to participate in governance votes. Token holders can also delegate their governance power to delegates who can participate in Aave Governance on their behalf.\nProposal Discussion.\nAs part of the governance process, a discussion must be started on the Aave Governance Forum.\nOnce the proposal has been posted on the forum, it must:\n\nBe available for review and comment for a minimum of five days.\nContain all relevant information that would be contained in the AIP\nComply with any relevant templates that apply to the proposal, for example: Template ARC Asset Onboarding\n\nMoving to Vote\nOnce a proposal has completed the requirements stated above, the proposal can move forward to the voting stages.\nThere are two kinds of votes, off-chain and on-chain:\n\nOff-chain (Snapshot): This vote is used to gauge the sentiment for ARC’s. This vote is necessary for a proposal to move forward to an on-chain vote (if necessary). The off-chain voting period lasts 5 days.\nOn-chain (Native): On-chain voting is required on any Aave Improvement Proposal. Aave on-chain votes will occur on the Aave Governance Portal. The voting period must last for a minimum period of 5 days.\n\nIn both off-chain and on-chain votes, voting power is directly proportional to the amount of AAVE or stkAAVE a user holds or has delegated to them.\nPlease refer to the official documentation to learn more about voting processes.\nQuorum\nIn order for a proposal to succeed, a minimum of 320k AAVE or stkAAVE must participate in the vote. Any changes to the quorum requirements must be amended by the community through an AIP.\nEach vote has to reach the minimum quorum, even if it has a majority, for it to be considered an official proposal. It is the responsibility of the proposal author to enlist voting participation from the community in order to reach a quorum.\nProposal History\nTo learn about Aave Proposal history, you can find off-chain votes on SnapShot and on-chain votes on the Aave governance platform.\nChanges to Governance\nAny changes to the Aave Governance Process must be ratified by the community through an AIP.\nResources:\n\n ARC: Aave Governance Process Improvements\n\n [ARFC] Aave V3 Caps update Framework\n\n Increase Metis and WETH Supply Cap on Metis\n\n [TEMP CHECK] Gas Fee Rebate for On-Chain Votes\n\n [ARFC] ARFC and TEMP CHECK Framework\n\n 2\n\n read \n\n 5\n min\n\n post by MarcZeller on Jan 19, 2023\n\n Pinned on Jan 19, 2023\n\n 6 months later\n\n post by Kene_Anode on Jul 10, 2023\n\n 1 year later\n\n post by ACI on Aug 8, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n Aave Governance Process Document v1\n\n Governance\n\n 3\n\n 5.3k\n\n Sep 2024\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 144\n\n Aug 10","tokens":3021,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263816379,"hash":"41e4dc783295269fcef0d35130b0f42a832f74b5"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/comparison-overview","domain":"docs.arbitrum.io","title":"Differences between Arbitrum and Ethereum: Overview | Arbitrum Docs","text":"✏️Request an updateArbitrum's design is to be as compatible and consistent with Ethereum as possible, from its high-level RPCs to its low-level bytecode and everything in between. Decentralized app developers with experience building on Ethereum will likely find that little to no new specific knowledge is required to build on Arbitrum.\nThis article outlines the key differences, benefits, and potential pitfalls that devs should be aware of when working with Arbitrum. This first page serves as an outline, with links to the relevant pages.\nSTF in Ethereum​\nIn Ethereum, the STF receives transactions as inputs, processes them via the EVM, and produces the final state as output.\nThe Ethereum state is a vast data structure represented by a modified Merkle Patricia Trie. This structure holds all accounts, linking them via hashes and reducing the entire state to a single root hash stored on the blockchain.\nThe Ethereum Virtual Machine (EVM) operates similarly to a mathematical function: given an input, it produces a deterministic output. Ethereum's STF encapsulates this behavior:\nY(S,T)=S′Y(S, T) = S'\nHere, S represents the current state, T denotes the transaction, and S' is the new state resulting from the execution of T.\nThe EVM operates as a stack machine with a maximum depth of 1024 items. Each item is a 256-bit word, chosen for compatibility with 256-bit cryptography (e.g., Keccak-256 hashes and secp256k1 signatures).\nDuring execution, the EVM uses transient memory (a word-addresses byte array) that only persists for the duration of a transaction. In contrast, each contract maintains a persistent Merkle Patricia storage trie–a word-addressable word array–that forms part of the global state.\nsmart contract bytecode compiles into a series of EVM opcodes that perform standard stack operations (such as XOR, AND, ADD, SUB) and blockchain-specific operations (such as ADDRESS, BALANCE, BLOCKHASH).\nGeth (go-Ethereum) is one of the primary client implementations of Ethereum, serving as the practical embodiment of both the STF and the EVM execution engine. It processes transactions by executing the smart contract's bytecode and updating the global state, ensuring that every state change is deterministic and secure.\nIn essence, Geth converts transaction inputs into precise computational steps within the EVM, maintaining the intricate data structures that underpin Ethereum's blockchain. Its robust design not only powers the core operations of Ethereum but also provides the foundation for advanced modifications in platforms like the Arbitrum Nitro stack.\nSTF on Arbitrum​\nThe Arbitrum Nitro stack implements a modified version of Ethereum's STF. While it retains the core principles of Ethereum, several Arbitrum-specific features and processes distinguish it from Ethereum's implementation. Key differences include:\nBlock numbers and time​\nTime in Arbitrum chains is tricky. The timing assumptions that apply to Ethereum blocks don't exactly carry over to Arbitrum blocks. See Block numbers and time for details about how block numbers and time work in Arbitrum.\nRPC methods​\nAlthough the majority of RPC methods follow the same behavior as Ethereum, some methods may produce a different result or add additional information when used on an Arbitrum chain. For more details, see RPC methods.\nSolidity support​\nYou can deploy Solidity contracts onto Arbitrum just like you do on Ethereum. There are only a few minor functional differences. For more information, refer to Solidity support.\nGas accounting​\nThe fees for executing an Arbitrum transaction function similarly to gas fees on Ethereum. However, Arbitrum transactions must also pay a fee component to cover the cost of posting their calldata to the parent chain (for example, calldata on Arbitrum One, a child chain, is posted to Ethereum, a parent chain). Find more information about the two components of gas fees in Gas and fees and parent chain pricing.\nCross-chain messaging​\nArbitrum chains support arbitrary message passing from a parent chain (for example, Ethereum) to a child chain (for example, Arbitrum One or Arbitrum Nova). These are commonly known as \"parent chain to child chain messages\". Developers using this functionality should familiarize themselves with how they work. For more information, refer to Parent chain to child chain messaging.\nSimilarly, Arbitrum chains can also send messages to the parent chain. Find more information about them in Child chain to parent chain messaging and the outbox.\nPrecompiles​\nBesides supporting all precompiles available in Ethereum, Arbitrum provides child chain-specific precompiles with methods that smart contracts can call in the same way as Solidity functions. For a full reference, see the Precompiles page.\nNodeInterface​\nThe Arbitrum Nitro software includes a special NodeInterface contract, available at address 0xc8, that is only accessible via RPCs (deployed offchain, making it inaccessible to smart contracts). For more details, see NodeInterface.STF in EthereumSTF on ArbitrumBlock numbers and timeRPC methodsSolidity supportGas accountingCross-chain messagingPrecompilesNodeInterface","tokens":1287,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263828899,"hash":"7f5d596554edde7fa76050b2ad70cf8a39ea9aa4"}
{"url":"https://governance.aave.com/t/proposal-clarification/17831","domain":"governance.aave.com","title":"Proposal Clarification - Other - Aave","text":"Proposal Clarification \n\n Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 1 / 4\n\n May 2024\n\n May 2024\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Hi all,\nI need some clarification on the Aave governance voting process, as I am not very familiar with it but I want to make sure I’m following the correct procedures.\nMy next task is to initiate a consensus vote for the snapshot and this message appears. Can I currently hold 1.6k AAVE tokens on Matic only? or is it only necessary to have the 1.6k AAVE splitter in multiple types? like also AAVE in stkBPT or other variations?\nThanks and sorry for asking but it’s unclear and I want to do things in the correct way :)\n\n 2\n\n post by EzR3aL on May 30, 2024\n\n EzR3aL\n\n Regular\n\n Hi, I’m not sure what exactly you want. But if you need guidelines for a proposal then see here. [ARFC] ARFC and TEMP CHECK Framework - #20 by ACI\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Thanks man, here is the screen\n\nDo you think it is ok to have 1.6k AAVE on matic only or need to have these tokens on multiple chains?\nThanks a lot \n\n 1 month later\n\n Closed on Jun 29, 2024\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 144\n\n Aug 10\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n Apu Mallku [Delegate platform]: Shutdown \n\n Delegate Platforms\n\n 6\n\n 1.1k\n\n Apr 12","tokens":449,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263839326,"hash":"06b16b38c56a2595c2055ae5087c6493fde539f9"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/nonce-management","domain":"docs.arbitrum.io","title":"Nonce management | Arbitrum Docs","text":"✏️Request an updateArbitrum does not maintain a long-lived \"pending\" mempool as an Ethereum node does. Transactions submitted to the Sequencer are ordered and executed almost immediately, so out-of-order nonces cannot wait minutes or hours for their predecessor to arrive — they are held only briefly, then rejected.\nThis page explains how Arbitrum's sequencer handles out-of-order nonces, the error you will see when the wait window expires, what eth_getTransactionCount(\"pending\") returns, and the submission patterns that work safely under these constraints.\nHow Arbitrum handles out-of-order nonces​\nWhen an Ethereum execution client receives a transaction whose nonce is higher than the sender's current state nonce, it places the transaction in its pending pool and keeps it there for an extended period (typically configured in minutes-to-hours, sometimes longer) while it waits for the missing predecessor transaction(s) to arrive. Concurrent submitters routinely rely on this behavior.\nArbitrum's sequencer behaves differently. It maintains an in-memory nonce-failure retry buffer rather than a long-lived pending pool:\n\nWhen a transaction arrives whose nonce is higher than the highest nonce the sequencer has already seen for that sender, the sequencer does not reject it immediately. Instead, it places the transaction in the retry buffer and starts a short expiry timer.\nIf the predecessor transaction arrives before the timer fires, the held transaction is revived and put back into the execution queue—it goes through normally, as if it had arrived in order.\nIf the timer fires first, the held transaction is dropped, and the sender receives a nonce too high error in response to its original eth_sendRawTransaction call.\n\nThe exact wait window and buffer capacity are configured by the operator running the sequencer. On Arbitrum One, the window is on the order of seconds, not minutes—short enough that you should treat it as a tolerance for network jitter and tx-ordering races, not as a substitute for the Ethereum pending pool.\nThe practical implication is that fire-and-forget concurrent submission patterns that work on Ethereum will not work reliably on Arbitrum. If you submit transactions N and N+1 from two different processes at the same time, you cannot rely on the sequencer holding N+1 while it waits for N to land — the window is too short.\nThe error you will see​\nWhen the retry window expires without the predecessor arriving, the call that submitted the out-of-order transaction returns the error string:\nnonce too high\nThis is the same literal error string used by Ethereum's execution layer, but the meaning is different:\n\nOn Ethereum, nonce too high usually means the gap between the sender’s current nonce and the pending pool's buffer is larger than the pending pool can or will buffer (often a multi-thousand-slot gap, configurable per client).\nOn Arbitrum, nonce too high simply means the predecessor transaction did not reach the sequencer within the retry window.\n\nA typical log line from a real out-of-order submission looks like:\nreqid=… err=\"nonce too high\"\nIf you see this in production after migrating an Ethereum-based submission pipeline to Arbitrum, the most likely cause is that two or more workers are submitting transactions for the same sender address without coordinating nonce allocation between them—not that any individual nonce is wrong.\neth_getTransactionCount(\"pending\") on Arbitrum​\nOn an Ethereum node, eth_getTransactionCount(address, \"pending\") returns a value that includes any transactions currently sitting in the pending pool waiting to be mined. Many concurrent-submission designs rely on this to allocate the next nonce.\nOn Arbitrum, eth_getTransactionCount(address, \"pending\") returns the same value as eth_getTransactionCount(address, \"latest\"). The sequencer's retry buffer is an internal sequencer state and is not exposed through the RPC interface, so there is no way for an external caller to observe whether a higher-nonce transaction is currently being held. Services that previously relied on \"pending\" to coordinate concurrent submitters should track outstanding nonces themselves rather than fetch them from the RPC.\nFurther reading​\n\nRPC methods — full list of RPC method differences between Arbitrum and Ethereum.\nThe Sequencer and Censorship Resistance — how the sequencer orders and processes transactions in Arbitrum.\nHow Arbitrum handles out-of-order noncesThe error you will seeeth_getTransactionCount(\"pending\") on ArbitrumFurther reading","tokens":1132,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263850753,"hash":"47ffc6c7fbadf0ab6f79d1127e1556fd77db3c8e"}
{"url":"https://governance.aave.com/t/proposal-clarification/17831/3","domain":"governance.aave.com","title":"Proposal Clarification - Other - Aave","text":"Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 3 / 4\n\n May 2024\n\n May 2024\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Hi all,\nI need some clarification on the Aave governance voting process, as I am not very familiar with it but I want to make sure I’m following the correct procedures.\nMy next task is to initiate a consensus vote for the snapshot and this message appears. Can I currently hold 1.6k AAVE tokens on Matic only? or is it only necessary to have the 1.6k AAVE splitter in multiple types? like also AAVE in stkBPT or other variations?\nThanks and sorry for asking but it’s unclear and I want to do things in the correct way :)\n\n 2\n\n post by EzR3aL on May 30, 2024\n\n EzR3aL\n\n Regular\n\n Hi, I’m not sure what exactly you want. But if you need guidelines for a proposal then see here. [ARFC] ARFC and TEMP CHECK Framework - #20 by ACI\n\n post by Combative268 on May 30, 2024\n\n Combative268\n\n Thanks man, here is the screen\n\nDo you think it is ok to have 1.6k AAVE on matic only or need to have these tokens on multiple chains?\nThanks a lot \n\n 1 month later\n\n Closed on Jun 29, 2024\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Who can bring governance topics to a vote under Governance Framework v2?\n\n Governance\n\n 1\n\n 144\n\n Aug 10\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Governance\n\n 11\n\n 898\n\n Feb 3\n\n Apu Mallku [Delegate platform]: Shutdown \n\n Delegate Platforms\n\n 6\n\n 1.1k\n\n Apr 12","tokens":443,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791263861025,"hash":"f67335ad1c5dfd31497242046cf5f8dea56a6a72"}
{"url":"https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541","domain":"ethresear.ch","title":"PeerDAS -- a simpler DAS approach using battle-tested p2p components - Networking - Ethereum Research","text":"PeerDAS – a simpler DAS approach using battle-tested p2p components \n\n Networking\n\n data-availability,p2p,scaling\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n Sep 2023\n\n 1 / 10\n\n Sep 2023\n\n Apr 2024\n\n post by djrtwo on Sep 4, 2023\n\n djrtwo\n\n PeerDAS\nThis is an sketch representing the general direction of PeerDAS. This is being circulated at an early stage for feedback before further discussion refinement.\nThis set of ideas came out of conversations with Dankrad, Vitalik, members of Codex, RIG, ARG, and Consensus R&D. Directionally, pieces of this type of approach have also been under discussion in various avenues for the past couple of years, e.g. Proto’s PeerDHT\nThe intent of a PeerDAS design is to reuse well known, battle-tested p2p components already in production in Ethereum to bring additional DA scale beyond that of 4844 while keeping the minimum amount of work of honest nodes in the same realm as 4844 (downloading < 1MB per slot).\nThis is an exploration to better understand what scale we can get out of a relatively simple network structure with various distributions of node types without relying on a more advanced DHT-like solution.\nSimulations of effectiveness of such a solution involve parametrizing the following:\n\ndata size (number of rows and columns per block, as well as sample size)\ntotal number of number of nodes on the network\nminimum amount of work an honest node is expected to do (e.g. custody and serve samples from X rows and columns)\nthe distribution of node capacities (i.e. what fraction of the network is minimally honest (custodies/serves X) and beyond (e.g. custodies/serves 10%, 25%, 100% of network data)) and the max sample requests they are willing to support (i.e. Y samples per slot)\nhonest/byzantine ratio assumptions\n\nDifferent parametrizations of the above will lead to either acceptable or broken configurations (e.g. data size might be too large to find peers of enough capacity for a given network distributions).\nA note on DAS in general\nImportantly, any DAS solution will rely upon nodes of various types and the assumptions we can make about them. Node types worth considering in any solution are:\n\nValidator and user nodes (Honesty custody/serve assumption can be placed upon them, e.g. download and serve samples of X rows/columns. Note, validators can be incentivized to custody but not necessarily to serve)\nHigh capacity nodes (some % of the data beyond baseline honest node)\nSuper-full nodes (100% of data) [special case of high capacity node]\n\nThe difference between DAS solutions then becomes – how does the DAS network organize itself, how do you discover peers for sampling, how does the network utilize (or under-utilize) nodes of higher capacity (e.g. can the solution support lumpiness in node capacity or do all nodes look equal).\nSketch of PeerDAS\nConfiguration\nThe following is a bit of a reduction of the full requisite parametrization for illustration purposes.\nAll values in the table are example values and do not represent suggestions for an actual parametrization.\n\nName\nSample Value\nDescription\n\nNUMBER_OF_ROWS_AND_COLUMNS\n32\n\nSAMPLES_PER_ROW_COLUMN\n512\n\nCUSTODY_REQUIREMENT\n2\nMinimum number of both rows and columns an honest node custodies and serves samples from\n\nSAMPLES_PER_SLOT\n75\nNumber of random samples a node queries per slot\n\nNUMBER_OF_PEERS\n70\nMinimum number of peers a node maintains\n\nHow it works\nCustody\nEach node downloads and custodies a minimum of CUSTODY_REQUIREMENT rows and CUSTODY_REQUIREMENT columns per slot. The particular rows and columns that the node is required to custody are selected pseudo-randomly (more on this below).\nA node may choose to custody and serve more than the minimum honesty requirement. Such a node explicitly advertises a number greater than CUSTODY_REQUIREMENT via the peer discovery mechanism – for example, in their enr (e.g. cust: 8 if the node custodies 8 rows and 8 columns each slot) – up to a maximum of NUMBER_OF_ROWS_AND_COLUMNS (i.e. a super-full node).\nA node stores the custodied rows/columns for the duration of the pruning period and responds to peer requests for samples on those rows/columns.\nPublic, deterministic selection\nThe particular rows and columns that a node custodies are selected pseudo-randomly as a function of the node-id, epoch, and custody size (sample function interface: custodied_rows(node_id, epoch, custody_size=CUSTODY_REQUIREMENT) -> List(uint64) and column variant) – importantly this function can be run by any party as the inputs are all public.\nNote: increasing the custody_size parameter for a given node_id and epoch extends the returned list (rather than being an entirely new shuffle) such that if custody_size is unknown, the default CUSTODY_REQUIREMENT will be correct for a subset of the node’s custody.\nNote: Even though this function accepts epoch as an input, the function can be tuned to remain stable for many epochs depending on network/subnet stability requirements. There is a trade-off between rigidity of the network and the depth to which a subnet can be utilized for recovery. To ensure subnets can be utilized for recovery, staggered rotation needs to happen likely on the order of the prune period.\nPeer discovery\nAt each slot, a node needs to be able to readily sample from any set of rows and columns. To this end, a node should find and maintain a set of diverse and reliable peers that can regularly satisfy their sampling demands.\nA node runs a background peer discovery process, maintaining at least NUMBER_OF_PEERS of various custody distributions (both custody_size and row/column assignments). The combination of advertised cust size and public node-id make this readily, publicly accessible.\nNUMBER_OF_PEERS should be tuned upward in the event of failed sampling.\nNote: while high-capacity and super-full nodes are high value with respect to satisfying sampling requirements, a node should maintain a distribution across node capacities as to not centralize the p2p graph too much (in the extreme becomes hub/spoke) and to distribute sampling load better across all nodes.\nNote: A DHT-based peer discovery mechanism is expected to be utilized in the above. The beacon-chain network currently utilizes discv5 in a similar method as described for finding peers of particular distributions of attestation subnets. Additional peer discovery methods are valuable to integrate (e.g. latent peer discovery via libp2p gossipsub) to add a defense in breadth against one of the discovery methods being attacked.\nRow/Column gossip\nThere are both NUMBER_OF_ROWS_AND_COLUMNS row and NUMBER_OF_ROWS_AND_COLUMNS column gossip topics, one for each row/column – column_X and row_Y for X and Y from 0 to NUMBER_OF_ROWS_AND_COLUMNS (non-inclusive).\nTo custody a particular row or column, a node joins the respective gossip subnet. Verifiable samples from their respective row/column are gossiped on the assigned subnet.\nReconstruction and cross-seeding\nIn the event a node does not receive all samples for a given row/column but does receive enough to reconstruct (e.g. 50%+, a function of coding rate), the node should reconstruct locally and send the reconstructed samples on the subnet.\nAdditionally, the node should send (cross-seed) any samples missing from a given row/column they are assigned to that they have obtained via an alternative method (ancillary gossip or reconstruction). E.g., if node reconstructs row_x and is also participating in the column_y subnet in which the (X, Y) sample was missing, send the reconstructed sample to column_y.\nNote: A node is always maintaining a matrix view of the rows and columns they are following, able to cross-reference and cross-seed in either direction.\nNote: There are timing considerations to analyze – at what point does a node consider samples missing and chooses to reconstruct and cross-seed.\nNote: There may be anti-DoS and quality-of-service considerations around how to send samples and consider samples – is each individual sample a message or are they sent in aggregate forms.\nPeer sampling\nAt each slot, a node makes (locally randomly determined) SAMPLES_PER_SLOT queries for samples from their peers. A node utilizes custodied_rows() and custodied_columns() to determine which peer(s) to request from. If a node has enough good/honest peers across all rows and columns, this has a high chance of success.\nUpon sampling, the node sends an DO_YOU_HAVE packet for all samples to all peers who are determined to custody this sample according to their custodied_rows/custodied_columns. All peers answer first with a bitfield of the samples that they have.\nUpon receiving a sample, a node will pass on the sample to any node which did not previously have this sample, known by DO_YOU_HAVE response (but was supposed to have it according to its custodied_rows/custodied_columns).\nPeer scoring\nDue to the deterministic custody functions, a node knows exactly what a peer should be able to respond to. In the event that a peer does not respond to samples of their custodied rows/columns, a node may downscore or disconnect from a peer.\nNote: a peer might not respond to requests either because they are dishonest (don’t actually custody the data), because of bandwidth saturation (local throttling), or because they were, themselves, not able to get all the samples. In the first two cases, the peer is not of consistent DAS value and a node can/should seek to optimize for better peers. In the latter, the node can make local determinations based on repeated DO_YOU_HAVE queries to that peer and other peers to assess the value/honesty of the peer.\nDAS providers\nA DAS provider is a consistently-available-for-DAS-queries, super-full (or high capacity) node. To the p2p, these look just like other nodes but with high advertised capacity, and they should generally be able to be latently found via normal discovery.\nThey can also be found out-of-band and configured into a node to connect to directly and prioritize. E.g., some L2 DAO might support 10 super-full nodes as a public good, and nodes could choose to add some set of these to their local configuration to bolster their DAS quality of service.\nSuch direct peering utilizes a feature supported out of the box today on all nodes and can complement (and reduce attackability) of alternative peer discovery mechanisms.\nA note on fork choice\nThe fork choice rule (essentially a DA filter) is orthogonal to a given DAS design, other than the efficiency of particular design impacting it.\nIn any DAS design, there are probably a few degrees of freedom around timing, acceptability of short-term re-orgs, etc.\nFor example, the fork choice rule might require validators to do successful DAS on slot N to be able to include block of slot N in it’s fork choice. That’s the tightest DA filter. But trailing filters are also probably acceptable, knowing that there might be some failures/short re-orgs but that it doesn’t hurt the aggregate security. E.g. The rule could be – DAS must be completed for slot N-1 for a child block in N to be included in the fork choice.\nSuch trailing techniques and their analyiss will be valuable for any DAS construction. The question is — can you relax how quickly you need to do DA and in the worst case not confirm unavailable data via attestations/finality, and what impact does it have on short-term re-orgs and fast confirmation rules.\nTODO: Simulation and Analysis of PeerDAS\nThe crux of PeerDAS is that each node can find/maintain enough peers of enough capacity at each slot to meet their sampling requirements.\nThus for a given data size, we can easily simulate network distributions (node count, distributions of node type/capacity, number sample-requests each node can respond to, minimum number of peers, etc) to understand the chances of successful DAS at each slot.\nWe can calculate/simulate safe data sizes of various parametrizations and assumptions, e.g.:\n\na homogeneous network of minimally honest nodes at a roughly 4844 custody requirement\nthe above but then accented with 100 super-full nodes with X capacity for queries\nall sorts of distributions in between\n\nNext up – simulations of various network distributions to anchor our understanding of the bounds of this method.\n\n SubnetDAS - an intermediate DAS approach\n\n From 4844 to Danksharding: a path to scaling Ethereum DA\n\n FullDAS: towards massive scalability with 32MB blocks and beyond\n\n DAS fork-choice\n\n Scalability limitations of Kademlia DHTs when Enabling Data Availability Sampling in Ethereum\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by zilm13 on Sep 5, 2023\n\n zilm13\n\n Could you, please, explain, where did the number of samples, 75, come from?\nAlso as SAMPLES_PER_ROW_COLUMN is bigger than NUMBER_OF_ROWS_AND_COLUMNS does it mean we will put several samples in every cell?\n\n post by Nashatyrev on Sep 5, 2023\n\n Nashatyrev\n\n @djrtwo thanks for this sketch!\nI understand that the constants here is very preliminary, but could you confirm my calculations based on those you settle here:\nEvery node subscribes to 2 rows and 2 columns which is roughly 4/32 = 1/8 of the overall extended data and thus is 1/2 of the original data size.\nThat looks like an excessive throughput for a regular node to me\n\n post by cskiraly on Sep 5, 2023\n\n cskiraly\n\n In my understanding the numbers there are preliminary. We already did initial simulations of the diffusion with reconstruction and cross-seeding with 512x512 segments, extended using 2D RS code from the original data organised in a 256x256 grid. This was in a slightly different model where row and column selection is driven by the validators behind a node instead of by node_id. Still, my current view is that diffusion could work with those larger numbers.\nThe PeerDAS model might need smaller numbers, but 32 rows/columns seems indeed too low for the goal of scaling to large blocks (e.g. 32 MB). 32 rows/columns might work as part of a transition, when block sizes are still relatively small (a few MB), but the machinery is already sampling based.\n\n post by cskiraly on Sep 5, 2023\n\n cskiraly\n\n zilm13\n\n As far as I know\n\n75 comes from “approx. 73”\n73 comes from setting a 1e-9 probability threshold on getting all requested segments while the data is not available (False Positive) when sampling over the 2D RS code with uniform random sampling.\n\nA simple approx. reasoning goes as follows:\nIf the data is not recoverable then we know that at least 1/4 of the data is lost. Then each independent sample is failing with\n\np_f \\geq 0.25\n𝑝𝑓≥0.25\nThus, the probability of not finding out about data being lost in n𝑛 samples is\n\np_{fp}(n) \\leq (1-0.25)^n\n𝑝𝑓𝑝(𝑛)≤(1−0.25)𝑛\nIf we look for the smallest n𝑛 with which this probability is 1e-9, we get that with n=73𝑛 =73 random samples, that is\n\np_{fp}(73) \\leq (1-0.25)^{73} = 7.57\\mathrm{e}{-10}\n𝑝𝑓𝑝(73)≤(1−0.25)73=7.57e−10\nI’m planning to publish soon a more detailed writeup to explain this and other sampling techniques, but for the 75 (73) this is I hope enough.\n\n post by pop on Sep 8, 2023\n\n pop\n\nYes, that requires too much bandwidth for a regular node. The constants are very preliminary.\nI think the reason we put 32 as NUMBER_OF_ROWS_AND_COLUMNS because we want to maintain the number of subnets as 64, which keeps us from changing much how the current subnet infrastructure works.\n\n post by dryajov on Sep 9, 2023\n\n dryajov\n\n I don’t think this is going to work for the 128mb erasure coded block (even if only pushing the original 32mb+proofs), if this is however being planed in the context of 4844 and 1mb block sizes, then it is probably a good starting point.\n\n 2 months later\n\n post by Nashatyrev on Nov 8, 2023\n\n Nashatyrev\n\n Here is kind of a slightly alternative view on networking organization and the potential approach to reliable and secure push/pull sampling: Network Shards - HackMD\nIn some aspects it complements PeerDAS and in other aspects it proposes alternatives\n\n 2 months later\n\n post by storm on Jan 10, 2024\n\n storm\n\n can you elaborate on these design decisions (they add extra complexity):\n\nwhy partition along rows and columns, instead of just partitioning across rows?\nwhy allow lumpy custody sizes, instead of just making a uniform custody chunk size? super-full nodes could just be multiple peers in the network as in beacon\n\na couple other questions:\n\nis peerdas data intended to be ephemeral as in 4844 or more permanent?\nwhat are the desired timing properties of peerdas? live available data every single block?\n\n 3 months later\n\n post by Evan-Kim2028 on Apr 17, 2024\n\n Evan-Kim2028\n\nI would imagine it’s a requirement to get data sampling working. See here for more details - From 4844 to Danksharding: a path to scaling Ethereum DA\n\n Powered by Discourse","tokens":4189,"squid":"ink-research","role":"Deep Scholar","at":1791263861163,"hash":"911a0dfc6393b7f3ed9c7294f9dc167f2c2c40d8"}
{"url":"https://specs.optimism.io/protocol/karst/overview.html","domain":"specs.optimism.io","title":"Karst - OP Stack Specification","text":"Karst Network Upgrade\n\nTable of Contents\n\nExecution Layer\nConsensus Layer\n\nThis document is not finalized and should be considered experimental.\nExecution Layer\n\nReduce bn256Pairing precompile input size\nOsaka (Execution Layer):\n\nEIP-7642: eth/69 - history expiry and simpler receipts\nEIP-7823: Set upper bounds for MODEXP\nEIP-7825 Transaction Gas Limit Cap\n(not enabled for deposits, which are already subject to a 20MGas limit)\nEIP-7883: ModExp Gas Cost Increase\nEIP-7910: eth_config JSON-RPC Method\nEIP-7939: Count leading zeros (CLZ) opcode\nEIP-7951: Precompile for secp256r1 Curve Support\n(this has been present since Fjord, but the gas cost will be updated to align with Ethereum)\n\nConsensus Layer\n\nNetwork upgrade transactions applied during derivation","tokens":190,"squid":"ink-governance","role":"Council Listener","at":1791263883913,"hash":"04595a492cd900b2d0dd917bb0b2cbb93cb8eba0"}
{"url":"https://forum.openzeppelin.com/t/setting-crowdsale-rate-manually/1659/11","domain":"forum.openzeppelin.com","title":"Setting crowdsale rate manually - General - OpenZeppelin Forum","text":"General\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 5\n\n Oct 2019\n\n 11 / 11\n\n Dec 2020\n\n Nov 2019\n\n post by bayram on Oct 30, 2019\n\n bayram\n\n Traditionally when we create crowdsale smart contract we provide four parameters: initial rate, final rate, opening time, and closing time, which determines current rate when one buys tokens using Ether. For example OpenZeppelin contracts.\nWhy can't we simply define a function, say, setRate(uint) onlyAdjuster and adjust the rate manually? Isn't it more flexible?\nThe matter is that I have created my own ERC20 token and just want to sell it for Ether. I have no time restrictions or final rate, only finite amount of tokens I want to distribute. What is the best practice in my case?\n\n 5\n\n 5\n\n post by abcoathup on Oct 30, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nWelcome to the community \nOpenZeppelin provides a highly configurable Crowdsale base contract that can be combined with various other functionalities to construct a bespoke crowdsale.\nYou could include a manual rate adjustment. I would think of this as the equivalent of a vending machine for laundry or arcade tokens, where the owner could change the price of tokens.\nI would recommend clearly advising participants under what circumstances the rate could be changed and who could change it, including by how much and how frequently.\nYou may want to code these types of restrictions on the rate change into your crowdsale. Such as limiting the frequency of a change (e.g. can only be changed after X time since the last change) and/or the amount (e.g. can only be adjusted up or down by Y%).\n\nYour solution should also have appropriate testing and auditing:\n\nRegards testing, the testing guide is a good place to start: Test smart contracts like a rockstar \n\nPrior to an audit it is worth going through the checklist before an audit.\nTo organize an audit, you would need to engage a third party auditor such as OpenZeppelin, see https://openzeppelin.com/security-audits/ for details.\n\n post by bayram on Oct 31, 2019\n\n bayram\n\n @abcoathup\nThanks for reply.\nYeah, I am using Crowdsale smart-contract.\nAs you recommend we do have our rules on under what circumstances the rate could be changed and who could change it. But I’d like simply to create a rate setter with restricted access and change it manually according to rules.\n\n post by abcoathup on Oct 31, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nYou can have a manual rate setter with no restrictions (other than who can set it).\nThough this means that your users will have to trust what you say that you are going to do, rather than knowing the restrictions are enforced in code.\nI would recommend being very clear with your users under what circumstances you would change the rate, both with how frequently, with what notice, and by how much (along with any other conditions). I would also include why these conditions are not implemented in code.\nAs always, I recommend that smart contracts are appropriately tested and audited.\nAlso get appropriate advice on any regulatory requirements.\n\n post by bayram on Nov 1, 2019\n\n bayram\n\n Thanks, your advice is really helpful.\nPS\nI regularly mispronounce OpenZeppelin when we discuss, by saying Led Zeppelin, I don’t know why though.\n\n post by abcoathup on Nov 1, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nYou are welcome. Feel free to ask all the questions that you need.\nWith OpenZeppelin and Led Zeppelin they are both great Zeppelins, it is understandable. \n\n post by bayram on Nov 1, 2019\n\n bayram\n\n @abcoathup\nI wonder why are members of Crowdsale.sol such as _wallet, _rate, _token, and _weiRaised declared private? While they are readable, they are not accessible when we inherit from Crowdsale contract. This does not allow me to inherit from Crowdsale and for example define a setter function for _rate.\nI made _rate internal in Crowdsale.sol and my derived contract worked fine.\npragma solidity >=0.4.21 <0.6.0;\n\nimport \"../node_modules/@openzeppelin/contracts/access/Roles.sol\";\nimport \"../node_modules/@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\ncontract MyCrowdsale is Crowdsale{\n using Roles for Roles.Role;\n\n Roles.Role private _owners;\n\n constructor(uint256 initialRate, address payable wallet, IERC20 tokenAddr, address ownerAddr)\n Crowdsale(initialRate, wallet, tokenAddr)\n public\n {\n _owners.add(ownerAddr);\n }\n\n function setRate(uint256 newRate) public\n {\n require(_owners.has(msg.sender), \"DOES_NOT_HAVE_RATE_SETTER_ROLE\");\n _rate = newRate;\n }\n}\n\nWhat is the reason to make those variables private?\n\n post by abcoathup on Nov 1, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nWe shouldn't modify the OpenZeppelin Contracts themselves, we should inherit and where needed override.\n\nhttps://docs.openzeppelin.com/contracts/2.x/#usage\nWarning: You should always use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself.\n\nAs an aside, we don't need \"../node_modules\" on import statements.\nimport \"../node_modules/@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\nRegards state variables being private, the release notes for OpenZeppelin 2.0 explain:\n\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.0\nAll state variables are now private, which means that derived contracts cannot access them directly, but have to use getters. This is to increase encapsulation, to be able to reason better about the code.\n\nWe can override Crowdsale functionality to give a changeable/settable rate so could do something like the following code.\nPlease note, I haven't tested this smart contract at all.\nAs always, I recommend that smart contracts are appropriately tested and audited.\npragma solidity ^0.5.0;\n\nimport \"@openzeppelin/contracts/access/Roles.sol\";\nimport \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\ncontract MyCrowdsale is Crowdsale{\n using Roles for Roles.Role;\n\n Roles.Role private _owners;\n\n uint256 private _changeableRate;\n\n constructor(uint256 initialRate, address payable wallet, IERC20 tokenAddr, address ownerAddr)\n Crowdsale(initialRate, wallet, tokenAddr)\n public\n {\n _owners.add(ownerAddr);\n\n _changeableRate = initialRate;\n }\n\n function setRate(uint256 newRate) public\n {\n require(_owners.has(msg.sender), \"DOES_NOT_HAVE_RATE_SETTER_ROLE\");\n _changeableRate = newRate;\n }\n\n function rate() public view returns (uint256) {\n return _changeableRate;\n }\n\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.mul(_changeableRate);\n }\n}\n\n How to change rate/price of a token in Crowdsale?\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n post by bayram on Nov 2, 2019\n\n bayram\n\n @abcoathup\nYeah, I fixed import \"../node_modules/@openzeppelin/... to import \"@openzeppelin/...\nI agree with you, I always respect other’s code, never change private member. In my example I just wanted to show that if _rate was declared as internal then we could derive from Crowdsale without need to override ALL methods where _rate appears.\nIn fact, my contract looks exactly like you suggest.\nI’ve also written tests for this contract, and I am going to test it on Ropsten before I deploy it on mainnet. You provide security audit as far as I know, so probably I will submit my code for the audit.\nThank you again for your suggestions. \n\n post by abcoathup on Nov 2, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @bayram,\nWhilst having internal state variables would make things easier, it would break encapsulation. I believe the code overriding functions using rate make it clearer what is being changed.\nGood to hear that you have tests for your contract. A thorough test suite is very important. The following article on testing is worth a read: Test smart contracts like a rockstar\nI recommend reading the following checklist for before an audit:\n\nI found reading past audits very useful: https://blog.openzeppelin.com/security-audits/\nRegards auditing, OpenZeppelin performs audits, see the website for details: https://openzeppelin.com/security-audits/\n\n 1 year later\n\n Split this topic on Dec 13, 2020\n\n A post was split to a new topic: Setting crowdsale rate automatically after every purchase\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Help me write an erc20 token and a crowdsale contract\n\n Contracts\n\n erc20\n\n 9\n\n 8.0k\n\n Dec 2020\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020","tokens":2204,"squid":"ink-security_audits","role":"Sentinel","at":1791263890844,"hash":"1ea8b9782a982366cc75fb961e76e952592cc949"}
{"url":"https://specs.optimism.io/protocol/karst/derivation.html","domain":"specs.optimism.io","title":"Network upgrade transactions - OP Stack Specification","text":"Derivation\n\nTable of Contents\n\nActivation Block Rules\n\nActivation Block Rules\nThe first block with a timestamp at or after the Karst activation time is considered the Karst activation block.\nOn the Karst activation block, in addition to the L1 attributes deposit and potentially any user deposits from L1, a\nset of deposit transaction-based upgrade transactions are deterministically generated by the derivation pipeline.\nThe contents of the transaction are defined by the file\nkarst_nut_bundle.json\nin the monorepo, which contains 31 transactions. In addition to the contents of the files, the consensus layer\nnode MUST prefix each intent string with Karst <index>: followed by a space, where <index> is the zero-based\nposition of the transaction within the bundle.\nThese transactions can be classified into the following groups:\n\nConditionalDeployer Deployment: One transaction to deploy the ConditionalDeployer contract\nConditionalDeployer Upgrade One transaction to upgrade a new predeploy to the ConditionalDeployer implementation\nImplementation Deployments: One transaction for each predeploy being upgraded, to deploy its implementation\n(26 total)\nProxyAdmin Upgrade One transactions to upgrade the L2ProxyAdmin implementation\nL2ContractsManager Deployment: One transaction to deploy the L2ContractsManager for this upgrade\nUpgrade Execution: One transactions to call L2ProxyAdmin.upgradePredeploys(l2ContractsManagerAddress)\n\nMore information regarding the upgrade path implemented by the bundle transactions can be found in L2 Upgrade Execution.","tokens":389,"squid":"ink-governance","role":"Council Listener","at":1791263902478,"hash":"b348115650cf1405c6885d7f9d16d6a38ed3158c"}
{"url":"https://specs.optimism.io/interop/verifier.html","domain":"specs.optimism.io","title":"Verifier - OP Stack Specification","text":"Verifier\n\nTable of Contents\n\nDriver\n\nSafety\n\nunsafe Inputs\ncross-unsafe Inputs\nsafe Inputs\nfinalized Inputs\n\nHonest Verifier\n\nSecurity Considerations\n\nDriver\nThe driver is responsible for validating L2 blocks and promoting them from unsafe\nto safe. A series of invariants are enforced before promotion.\nSafety\nSafety is an abstraction that is useful for reasoning about the security of L2 blocks.\nIt is a spectrum from unsafe to finalized. Users can choose to operate on L2 data\nbased on its level of safety, taking into account their risk profile and personal preferences.\nThe following labels are used to describe both inputs and outputs:\n\nunsafe\ncross-unsafe\nsafe\nfinalized\n\nInputs correspond to the inputs to the state transition function while, outputs correspond to the side\neffects of the state transition function.\nAnything before safe technically uses a \"preconfirmation\" based security model which is not part\nof consensus. These definitions are policy rather than consensus rules.\nThe unsafe label has the lowest latency while the finalized label has the highest latency.\nA set of invariants must be held true before an input or an output can be promoted to the next\nlabel, starting at unsafe.\nThe initiating messages for all dependent executing messages MUST be resolved as safe before an L2 block can transition\nfrom being unsafe to safe. Users MAY optimistically accept unsafe blocks without any verification of the\nexecuting messages. They SHOULD optimistically verify the initiating messages exist in destination unsafe blocks\nto more quickly reorganize out invalid blocks.\nunsafe Inputs\n\nMUST be signed by the p2p sequencer key\nMAY be reorganized\nMUST be promoted to a higher level of safety or reorganized out to ensure liveness\n\nunsafe inputs are currently gossiped around the p2p network. To prevent denial of service, they MUST\nbe signed by the sequencer. This signature represents the sequencer's claim that it\nbuilt a block that conforms to the protocol. unsafe blocks exist to give low latency access to the\nlatest information. To keep the latency as low as possible, cross chain messages are assumed valid\nat this stage. This means that the remote unsafe inputs are trusted solely because they were\nincluded in a block by the sequencer.\nAn alternative approach to unsafe inputs would be to include an SGX proof that the sequencer ran\nparticular software when building the block.\ncross-unsafe Inputs\n\nMUST have valid cross chain messages\n\ncross-unsafe represents the unsafe blocks that have had their cross chain messages fully verified.\nThe network can be represented as a graph, where each block across all chains is represented as a node.\nA directed edge between two blocks indicates the source block of the initiating message\nand the block that includes the executing message.\"\nAn input can be promoted from unsafe to cross-unsafe when the full dependency graph is resolved,\nsuch that all cross chain messages are verified to be valid and at least one message in the dependency\ngraph is still unsafe.\nNote that the cross-unsafe is not meant to be exposed to the end user via the RPC label. It is\nmeant for internal usage. All cross-unsafe inputs are still considered unsafe by the execution\nlayer RPC.\nsafe Inputs\n\nMUST be available\nMAY be reorganized\nSafe block MUST be invalidated if a reorg occurs\n\nsafe represents the state in which the cross-unsafe dependency graph has been fully resolved\nin a way where all of the data has been published to the data availability layer.\nfinalized Inputs\n\nMUST NOT be reorganized based on Ethereum economic security\n\nfinalized represents full Proof of Stake economic security on top of the data. This means that\nif the data is reorganized, then validators will be slashed.\nHonest Verifier\nThe honest verifier follows a naive verification algorithm that is similar\nto the block building code that the sequencer\nfollows. The main difference is that the validity of included executing\nmessages is verified, instead of verifying possible executing messages before\ninclusion.\nSecurity Considerations","tokens":1015,"squid":"ink-governance","role":"Council Listener","at":1791263912275,"hash":"3ed461ce55380a2f3816eb1eb9bd5c6a8df7f90e"}
{"url":"https://forum.openzeppelin.com/t/how-to-update-the-crowdsale-rate/5160/1","domain":"forum.openzeppelin.com","title":"How to update the crowdsale rate? - Support / Contracts - OpenZeppelin Forum","text":"How to update the crowdsale rate? \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Dec 2020\n\n 1 / 4\n\n Dec 2020\n\n Dec 2020\n\n post by PradhumnaPancholi on Dec 23, 2020\n\n PradhumnaPancholi\n\n So, I have asked the same question before but I got stuck on something and it lead to more confusion. What was doing was adding “1000000000000000” to the rate to increase price by 0.001 ETH. But I realized that it doesn’t work like that. So, I did the math and found a different solution, that was to subtract 0.0014 from rate. Now, solidity has no way to handle decimals. How can I approach this ? Can rates be in decimal values?\n\n 2\n\n 2\n\n post by Skyge on Dec 24, 2020\n\n Skyge\n\n I am not sure what do you mean exactly, but I think if you want to increase the price of each purchase, you can change the rate like so:\ncontract CrowdSale {\n uint256 buyRate = 1e18;\n mapping(address => uint256) public _balance;\n\n function buyTokens() payable public {\n uint256 buyAmount = msg.value * 1e18 / buyRate;\n // TODO: buyAmount should be valid\n _balance[msg.sender] += buyAmount;\n buyRate += 0.0001e18;\n }\n}\n\nSo just like above, cause this is no decimals in the contract, so if you want to do it, you have got to multiply firstly, then divide, 1000 * 9 / 10 => 1000 * 0.9\n\n post by PradhumnaPancholi on Dec 24, 2020\n\n PradhumnaPancholi\n\n I am not sure if I follow. Can you give an example? is it possible to just increase price by 0.001 Eth on each purchase? Or are u talking about rate (asking to make sure on rate vs price)? Also, what is that 0.001e18? Does it meant 0.001 with 10^18 as in literally 0.001 eth? If that’s it than it will solve a big problem for me.\nP.S :- sorry for so many questions\n\n post by Skyge on Dec 24, 2020\n\n Skyge\n\n is it possible to just increase price by 0.001 Eth on each purchase?\nYes, at least, I think so, cause in my demo, I increase the price by the buyRate, so when buyRate is 1e18, it means 1 eth = 1 token, and when buyRate is equal to 1.001e18, it means 1.001 eth = 1 token, so the price increased.\nAlso, what is that 0.001e18? Does it meant 0.001 with 10^18 as in literally 0.001 eth?\nYeah, 0.001e18 is equal to 0.001eth.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022","tokens":682,"squid":"ink-security_audits","role":"Sentinel","at":1791263917423,"hash":"5cd3cc057fc5cb25366a65080be5cb653965745b"}
{"url":"https://specs.optimism.io/interop/superroot.html","domain":"specs.optimism.io","title":"Super Root - OP Stack Specification","text":"Super Root\n\nTable of Contents\n\nOverview\nRPC API\n\nTypes\n\nOutputV0\nOutputWithRequiredL1\nSuperRootResponseData\n\nMethods\n\nsuperroot_atTimestamp\n\nResponse Behavior\n\nSync Status Fields\nOptimistic Data\nVerified Data\nErrors\n\nOverview\nThe super root is a commitment to the\ncombined verified state of all chains in a dependency set at a given timestamp.\nAny consensus client that verifies output roots across chains with interop needs access to the\nsuper root to confirm published roots.\nThis document specifies the RPC API for querying the super root and per-chain output root data.\nRPC API\nThe super root API provides callers with the verified super root at a requested timestamp\nwhen available, along with sync status information and per-chain optimistic output roots\nthat may not yet be fully verified.\nFor common types (ChainID, Hash, BlockID, HexUint64) see the\nexisting type definitions. The SuperV1 and ChainIDAndOutput structures\nused in the response match the encoding defined in the\nSuper Output specification.\nTypes\nOutputV0\nThe L2 output root preimage.\nOBJECT:\n\nstateRoot: Hash\nmessagePasserStorageRoot: Hash\nblockHash: Hash\n\nOutputWithRequiredL1\nPer-chain optimistic output data.\nOBJECT:\n\noutput: OutputV0 - the output root preimage\noutput_root: Hash - keccak256 hash of the marshaled output\nrequired_l1: BlockID - the minimum L1 block required to derive this output\n\nSuperRootResponseData\nVerified super root data. Present only when all chains in the dependency set\nhave verified data at the requested timestamp.\nOBJECT:\n\nverified_required_l1: BlockID - the minimum L1 block at which all chains\ncan be fully verified at this timestamp\nsuper: SuperV1 - the super root preimage\nsuper_root: Hash - the keccak256 hash of the encoded SuperV1\n\nMethods\nsuperroot_atTimestamp\nReturns the super root state at the given timestamp, along with sync status\nand per-chain optimistic output data.\nParameters:\n\ntimestamp: HexUint64 - the L2 timestamp to query\n\nReturns:\nOBJECT:\n\ncurrent_l1: BlockID - the highest L1 block that has been fully processed\nby all chains in the dependency set. This is the minimum currentL1 across all chains.\nsafe_timestamp: NUMBER - the highest L2 timestamp that is cross-safe across\nall chains. This is the minimum per-chain cross-safe L2 head timestamp.\nlocal_safe_timestamp: NUMBER - the highest L2 timestamp that is local-safe\nacross all chains. This is the minimum per-chain local-safe L2 head timestamp.\nfinalized_timestamp: NUMBER - the highest L2 timestamp that is finalized\nacross all chains. This is the minimum per-chain finalized L2 head timestamp.\nchain_ids: ARRAY of ChainID - the chain IDs in the dependency set,\nsorted in ascending order.\noptimistic_at_timestamp: OBJECT with ChainID keys and OutputWithRequiredL1\nvalues - per-chain optimistic output data at the requested timestamp.\ndata: SuperRootResponseData or null - the verified super root data.\nnull when verified data is not yet available for all chains.\n\nResponse Behavior\nSync Status Fields\nThe fields current_l1, safe_timestamp, local_safe_timestamp,\nfinalized_timestamp, and chain_ids are always populated. They reflect\nthe aggregate sync state across all chains in the dependency set at the time of the call,\nindependent of the requested timestamp.\nEach timestamp field is the minimum of that safety level's L2 head timestamp\nacross all chains, providing a conservative view of global progress.\nOptimistic Data\nThe optimistic_at_timestamp map is populated per-chain. Each chain that has\na derived block at the requested timestamp is included, regardless of whether\nits executing messages have been verified. Chains that have not yet derived a\nblock at the requested timestamp are omitted from the map.\nIf a block at the requested timestamp has been\nreplaced due to invalid executing\nmessages, the optimistic output is the original (pre-replacement) block's\noutput — representing the chain state as if verification had succeeded and no\nreplacement occurred. For blocks that have not been replaced, the optimistic\noutput is the current local-safe block's output.\nThis data is useful for consumers that want to act on the most recent state\nbefore full cross-chain verification completes.\nVerified Data\nThe data field is non-null only when all chains in the dependency set have\nfully verified data at the requested timestamp. \"Verified\" means:\n\nThe block at the requested timestamp has been derived.\nAll executing messages in the block (and its transitive dependencies) have been\nvalidated across the dependency set.\nAny blocks containing invalid executing messages have been replaced using\nHolocene Replacement.\n\nWhen data is present:\n\ndata.super_root is the canonical super root hash at the requested timestamp.\ndata.verified_required_l1 is the minimum L1 block that includes\nall batch data necessary to reproduce this verified state.\ndata.super contains the full preimage, allowing callers to independently\nrecompute the super root hash.\n\nWhen data is null, the super root at the requested timestamp is not yet\nknown. Callers should retry after the node has made further sync progress.\nThe safe_timestamp field indicates the highest timestamp at which\nverified data is currently available.\nErrors\nThe method returns an RPC error if:\n\nAn internal error occurs while querying chain state (e.g. database failure,\nunreachable chain node). Transient NotFound conditions for individual chains\ndo not produce errors; they result in the chain being excluded from\noptimistic_at_timestamp and data being null.\nThe dependency set is empty (no chains configured).","tokens":1387,"squid":"ink-governance","role":"Council Listener","at":1791263922091,"hash":"3267b75ef470f553d7d3fdd9f824f78997abad5e"}
{"url":"https://dev-forum.pyth.network/t/ethglobal-qualifying-criteria-for-historic-prices/429/7","domain":"dev-forum.pyth.network","title":"EthGlobal qualifying criteria for Historic Prices - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n Oct 2025\n\n 7 / 17\n\n Oct 2025\n\n Oct 2025\n\n post by mcmoodoo on Oct 8, 2025\n\n post by Aditya520 on Oct 8, 2025\n\n post by mcmoodoo on Oct 8, 2025\n\n mcmoodoo\n\n Perfect! Is this confirmed? I just want to be absolutely sure to avoid building something that won’t meet the qualification requirements.\nThanks\n\n post by nidhi on Oct 9, 2025\n\n nidhi\n\n it is confirmed Looking forward to see your project.\n\n post by mcmoodoo on Oct 12, 2025\n\n mcmoodoo\n\n Perfect! Looking at the docs now. Both of these methods will provide historical prices in an interval (e.g. 60 prices for every second from epoch stamp 1760294000 to 1760294060) but none of those will ACTUALLY update the price on chain for that price feed, right?\nWhat if I need to have last 60 historical price values up to the very latest (now)?\nDo I need two seprate calls here? First to update the price on chain with pyth.updatePriceFeeds{ value: fee }(priceUpdate) and then parsePriceFeedUpdates(…) to get the historical price values I need?\nAm I thinking right here? Or is there some other way?\nThanks.\n\n post by Aditya520 on Oct 13, 2025\n\n Aditya520\n\n You don’t need to update the prices. But if you need 60 historical prices to be verified on-chain, you need parse them.\n\n post by mcmoodoo on Oct 18, 2025\n\n mcmoodoo\n\n So, I am using benchmarks API which returns:\n```\n[\n{\n“binary”: {\n“encoding”: “hex”,\n“data”: [\n“504e41550100000003b801000000040d00ff95abc1f273ea6c1f906c14d0f078478c931655a028d719e50c62665602103c3022d41f64e5ce8036de985a8e5a697ff3ac28a2d3f5f8416b5c98bbb3ec6af20102edc8773800259b65d49aa7f79c6c3a64ed117b0334eb80713fd65c1474540b29089a4e98b683d5ae8f38c1979855719b2eb8143dd4170c8573044c1d2c3553f5010337edd9e8a0388ab73f56ecb561e2d81b1ae05ce376643657662f7536e3a285424b2dc3fe5957f83c603f340c90a8c3de027cc4913cda4f8811a28a38aa6e7aa70104567a5865bfb72b03be69ca2cdd50f040f92c896e4f4a8dad598fc19e19d2272774b9ed7c23516e4beeeb10ba18adeb841d861b4274167aeb352e2d5f66b63f450006314f528e9cf8292a5315dc1b554be7a3aaacb9ff4a3a3f3d8f542c07bdec65a8398f058bafe7d56dcd22599b353523ac950437b2b0521f47977c8f694f38027f01084aca963b71b3d8d2d1f832ba60addd6e62cf87e13033a14dd5c6f31e96b817391df2ece3a9ddc7ad9877f4ddd0e198428296941dbb3713771f7b68d995bc5091010acda47312abef5212e26a35a29d807f36cf70c2fc664970615efe551f5698d6e0254d2af5b1140dcc25dd768882639b986efb92f8bab2a3e72de6a2a424f357a0000bfe8b251ec6d5075a769df696293fc3b6fca1244322057bfd47c9daa8e748259f0c471a3e79e6d57104b7961ba30e3bcce07a692d15506743d566ccbb91643df4010c17b13a3e8f7cdf07e0ac2039bf77425e7db71daae06a765d4d70e1ea4a1ab22008b865661cae0d4434e38f5eb6950b35359a12ab180608906b5f58414ac530d2000d2ae00a7f262cb046d333307e6a0cac3ff9d40dc1e1144bceb437f93d494a9c0c1a5b5e2acde0c170d0379d00321deff42b9274c49a4343365f6f261250c36a80010e54b6d35e5ee372f4d5951cbe32ca3c2d1d90593acc0f6f0d61fcdc8017f3424f5379d708620e2e23a822a2ca4606e30e2806765b6194f06a4587814d646ea8360010ac4ec95c12e083f92c223e21f2df3a1fb31bdf35b267b9fa722bcd071cbcfa5737a3df134bb43c3388290215507520351e6cfc1df4f1945a4a1cf7fd9496b11300118033b329471128b5e2529b3ac52794de67466049a47a4afd9bb3a64ee52139da0fd458e3a5a4774fd3966573e5ae3053310de3bb4dabe8dff8a76ed42b0f9bd90168f38f8300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c3014155575600000000000edf59c000002710a490de13f4cb4f7703810aa14bf839b23780ff5d02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5d3969810000000007533d0dfffffff80000000068f38f830000000068f38f820000005a60205bb0000000000798ad940dc2ec2928270934bf076c89ed9504f548b13855252d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea54a83b64e78bc1e8c5bbca36ba667c39164334066c22d5f219a44017266f3590d3652f33d7a6ab732d12a9d6481401ed8eb4d2cfbde6791180b539b2f766753f22e31d375bfd38ff07aa28068bb925b9c5fce7916269b4abfc1ebe91e7acf3b960eee2c92885338354bfb6edb17b8666ae54bb1962d5534c3698ba66c2216b4047602295543ae837620d8ad7e70eb642640e329f2be977d555674e2b186fb995d550b85bc498b41b87aa5f34e7a5164e4e3b4062d8eb0922a3c51b64e354c300bf1af2d7089d9db5005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5d3969810000000007533d0dfffffff80000000068f38f830000000068f38f820000005a60205bb0000000000798ad940dc2ec2928270934bf076c89ed9504f548b13855252d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea54a83b64e78bc1e8c5bbca36ba667c39164334066c22d5f219a44017266f3590d3652f33d7a6ab732d12a9d6481401ed8eb4d2cfbde6791180b539b2f766753f22e31d375bfd38ff07aa28068bb925b9c5fce7916269b4abfc1ebe91e7acf3b960eee2c92885338354bfb6edb17b8666ae54bb1962d5534c3698ba66c2216b4047602295543ae837620d8ad7e70eb642640e329f2be977d555674e2b186fb995d550b85bc498b41b87aa5f34e7a5164e4e3b4062d8eb0922a3c51b64e354c300bf1af2d7089d9db5”\n]\n},\n“parsed”: [\n{\n“id”: “ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”,\n“price”: {\n“conf”: “122895629”,\n“expo”: -8,\n“price”: “388111100289”,\n“publish_time”: 1760792451\n},\n“ema_price”: {\n“conf”: “127446420”,\n“expo”: -8,\n“price”: “388159790000”,\n“publish_time”: 1760792451\n},\n“metadata”: {\n“slot”: 249518528,\n“proof_available_time”: 1760792452,\n“prev_publish_time”: 1760792450\n}\n},\n{\n“id”: “ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace”,\n“price”: {\n“conf”: “122895629”,\n“expo”: -8,\n“price”: “388111100289”,\n“publish_time”: 1760792451\n},\n“ema_price”: {\n“conf”: “127446420”,\n“expo”: -8,\n“price”: “388159790000”,\n“publish_time”: 1760792451\n},\n“metadata”: {\n“slot”: 249518528,\n“proof_available_time”: 1760792452,\n“prev_publish_time”: 1760792450\n}\n}\n]\n},\n{\n“binary”: {\n“encoding”: “hex”,\n“data”: [\n“504e41550100000003b801000000040d001428991f7d43fabb288a395b5dc4c03f51b6a476206337c168e1568bdce2579771dc7193a5aa1b5baafbf82b0d5f326018785a5f4d714f1eca9077c309b816e9010211958a44ab3db9a3410c6b0eb5b3ec4200cfc5e3da3016db9af214c02922f19b593ef46aa917c59ae22b65710c622b70b6b8e821d276fd91ed4d96471271ea580003378403000f25810d13420c58577ae1467a4fa9b2da5e0c44158c3cd5ce7bed7479d6f406205116d3b52fee330e4684d96b4b77b57dab9f32dbd43bf7e114eaa5000479802c4b17808d769f65e95e233b468a12c9117a32f70b7faa7cc301a1b185c671a5ae470e376c891a767bce89a33d18415e167740dfc100820ad7096ba54a3901067f4c6a350f4450c91ac72ef3e86f228a508a8c5bfbad63868ee003ee4083fabc22e762e457e2c743306f906c8e0cb4bb1bc70ece6c583aa4f0b5ce7ed2211596000851ed2d008eb92f11478623d866ef0be321e6851a904696c9061f23da06134efd57616fc291fb577da7548e03fe0a248bd96311f62c1b76f5c23ff62c2f005ef3000a5b1bea9172c3f22b1de93881c356845edba2344217626453b57a27707d051cd7040f8e6ff3319584a6c25050447727455996635666e11a281de2500118d0dc52010bef349eb8de625e641014b79a2cb766bed88ca02b1df6ca7c73e4cf9e67f7cbe8417c764cd84c132dc1d4cf7997159a06245378e62387a80de8324f9e58faff34010cd4917b8f68f037246367fd19db214cc187656ea2f765e88dd07729ea419e55bd0d5426a40b8fe9d27d5e178707cdba10259725e3b0c677b27f9be219b6170fb0010d8259fbef03dfbc1ac9a7b4fb085db0b4343583c202b699a1acb9eb5b4772a85c602d666d7af69091304ae95a8eca681811468c63876ea014e68700b1aae20b0e010f8e5645cd99bc2ad990097554b39b12a7262cdec7be29dc149e7bd20452b9a9520cec9ea1b2cce87986450d815798ff963e348fc78249196390fd9a253d6a16ba00108cba568e308e8b5e828fd3869452a01a57d330635a9b174e56023a6e959c79af3aef3868a857d1e0a45291fbc00aaab9b944430f498338fe016daae00728596101116e7b022947c1f864022fe6b73b89fcd984482eeda9e63aa1c7d0c6e9c999088d789b905c644ed7717aea85b3d6339629b7571a3d0fe6852a83976bff6445d09f0168f38f8400000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c6014155575600000000000edf59c3000027102d33c0a3a41ee75c7147583fe1857fc6df024f5f02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12”\n]\n},\n…\n```\nand my assumption is that I need to construct a bytes[] array of binary.data fields\nand pass it to:\nfunction parsePriceFeedUpdates( bytes[] calldata updateData, bytes32[] calldata priceIds, uint64 minPublishTime, uint64 maxPublishTime ) external payable returns (PythStructs.PriceFeed[] memory priceFeeds);\nBut I am getting:\n❯ cast 4byte 0xe69ffece\nInvalidUpdateData()\nSo, seems like it doesn’t like the format.\n\n post by mcmoodoo on Oct 20, 2025\n\n post by mcmoodoo on Oct 20, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by mcmoodoo on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by mcmoodoo on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by mcmoodoo on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n Byte by byte breakdown of Hex encoded data received in latest price update API\n\n Price Feeds\n\n evm\n\n 5\n\n 717\n\n Jun 2025\n\n Powered by Discourse","tokens":3462,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263929251,"hash":"6759fd2b4b3f856b6e88c6722ed8901bcf1efbcc"}
{"url":"https://specs.optimism.io/interop/optimism-portal.html","domain":"specs.optimism.io","title":"OptimismPortal - OP Stack Specification","text":"OptimismPortal Interop\n\nTable of Contents\n\nOverview\n\nIntegrating ETHLockbox\n\nInterface and properties\n\nETH Management\n\nmigrateLiquidity\nproxyAdminOwner\n\nDispute Game Management\n\nmigrateToSharedDisputeGame\n\nInternal ETH functionality\n\nLocking ETH\nUnlocking ETH\n\nEvents\n\nETHMigrated\nPortalMigrated\n\nInvariants\n\nOverview\nThe OptimismPortal contract is integrated with the ETHLockbox for managing unified ETH liquidity.\nThis liquidity consists of every ETH balance migrated from each OptimismPortal when joining\nthe op-governed dependency set.\nIt is possible to upgrade to this version without being part of the op-governed dependency set. In this case,\nthe corresponding chain would need to deploy and manage its own ETHLockbox.\nThe OptimismPortal also moves onto shared dispute game contracts when a chain joins the op-governed dependency set.\nEach chain keeps its own SystemConfig and OptimismPortal. The chains in the set share one ETHLockbox, one\nDisputeGameFactory and one AnchorStateRegistry. A chain\noutside the op-governed dependency set keeps its own copy of each of these contracts.\nIntegrating ETHLockbox\nThe integration with the ETHLockbox involves locking ETH when executing deposit transactions and unlocking ETH\nwhen finalizing withdrawal transactions, without altering other aspects of the current OptimismPortal implementation.\nInterface and properties\nETH Management\nmigrateLiquidity\nMigrates the ETH liquidity to the ETHLockbox. This function will only be called once by the\nProxyAdmin owner when updating the OptimismPortal contract.\nfunction migrateLiquidity() external;\n\nMUST only be callable by the ProxyAdmin owner\nMUST transfer all ETH balance to the ETHLockbox\nMUST emit an ETHMigrated event with the amount transferred\n\nproxyAdminOwner\nReturns the ProxyAdmin owner that manages the ETHLockbox.\nfunction proxyAdminOwner() external view returns (address);\n\nDispute Game Management\nmigrateToSharedDisputeGame\nMoves the OptimismPortal onto the shared dispute game contracts of the op-governed dependency set. It points the\nportal at the shared ETHLockbox and the shared\nAnchorStateRegistry. The shared AnchorStateRegistry selects\nthe shared DisputeGameFactory that the portal respects.\nfunction migrateToSharedDisputeGame(\n IETHLockbox _newLockbox,\n IAnchorStateRegistry _newAnchorStateRegistry\n) external;\n\nMUST only be callable by the ProxyAdmin owner\nMUST revert if the SystemConfig does not have the interop feature enabled\nMUST revert if the system is paused\nMUST revert if the new AnchorStateRegistry is the same as the current one\nMUST revert if either address is zero\nMUST revert if the new ETHLockbox has not authorized this portal\nMUST emit a PortalMigrated event with the old and new ETHLockbox and AnchorStateRegistry\nSHOULD be called atomically with ETHLockbox.migrateLiquidity in the same\ntransaction, or the portal may not be able to unlock enough ETH to finalize withdrawals\n\nmigrateToSharedDisputeGame is designed for a one-time migration. Chain operators are expected to call it exactly once\nwhen joining the op-governed dependency set. Although the function permits repeated calls, it is not designed for repeated\nmigration. Switching to the shared DisputeGameFactory invalidates withdrawal proofs against games from the previous\nfactory, so users MUST prove those withdrawals again.\nInternal ETH functionality\nLocking ETH\nCalled during deposit transactions to handle ETH locking.\nif (msg.value > 0) ethLockbox.lockETH{ value: msg.value }();\n\nMUST be invoked during depositTransaction when there is ETH value\nMUST lock any ETH value in the ETHLockbox\n\nUnlocking ETH\nCalled during withdrawal finalization to handle ETH unlocking.\nif (_tx.value > 0) ethLockbox.unlockETH(_tx.value);\n\nMUST be invoked during withdrawal finalization when there is ETH value\nMUST unlock the withdrawal value from the ETHLockbox\nMUST revert if withdrawal target is the ETHLockbox\n\nEvents\nETHMigrated\nMUST be triggered when the ETH liquidity is migrated to the ETHLockbox.\nevent ETHMigrated(uint256 amount);\n\nPortalMigrated\nMUST be triggered when the OptimismPortal migrates to a new ETHLockbox and AnchorStateRegistry.\nevent PortalMigrated(\n IETHLockbox oldLockbox,\n IETHLockbox newLockbox,\n IAnchorStateRegistry oldAnchorStateRegistry,\n IAnchorStateRegistry newAnchorStateRegistry\n);\n\nInvariants\n\nDeposits MUST lock the ETH in the ETHLockbox\n\nWithdrawals MUST unlock the ETH from the ETHLockbox and forward it to the withdrawal target\n\nThe contract MUST NOT hold any ETH balance from deposits or withdrawals\n\nThe contract MUST be able to handle zero ETH value operations\n\nThe contract MUST NOT allow withdrawals to target the ETHLockbox address","tokens":1165,"squid":"ink-governance","role":"Council Listener","at":1791263931908,"hash":"1792d58ab031f81d7a4ed0a1e18fa20effb40b81"}
{"url":"https://dev-forum.pyth.network/t/ethglobal-qualifying-criteria-for-historic-prices/429/17","domain":"dev-forum.pyth.network","title":"EthGlobal qualifying criteria for Historic Prices - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 7\n\n Oct 2025\n\n 17 / 17\n\n Oct 2025\n\n Oct 2025\n\n post by mcmoodoo on Oct 8, 2025\n\n post by Aditya520 on Oct 8, 2025\n\n post by mcmoodoo on Oct 8, 2025\n\n post by nidhi on Oct 9, 2025\n\n post by mcmoodoo on Oct 12, 2025\n\n post by Aditya520 on Oct 13, 2025\n\n post by mcmoodoo on Oct 18, 2025\n\n post by mcmoodoo on Oct 20, 2025\n\n post by mcmoodoo on Oct 20, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by mcmoodoo on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by mcmoodoo on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n post by mcmoodoo on Oct 21, 2025\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n I apologize for the confusion.\nYou don’t need to construct the bytes array at all.\nYou fetch the bytes array using\nBASE_URL = “https://benchmarks.pyth.network/v1/updates/price{timestamp}”\nYou will receive an update.\n504e41550100000003b801000000040d001428991f7d43fabb288a395b5dc4c03f51b6a476206337c168e1568bdce2579771dc7193a5aa1b5baafbf82b0d5f326018785a5f4d714f1eca9077c309b816e9010211958a44ab3db9a3410c6b0eb5b3ec4200cfc5e3da3016db9af214c02922f19b593ef46aa917c59ae22b65710c622b70b6b8e821d276fd91ed4d96471271ea580003378403000f25810d13420c58577ae1467a4fa9b2da5e0c44158c3cd5ce7bed7479d6f406205116d3b52fee330e4684d96b4b77b57dab9f32dbd43bf7e114eaa5000479802c4b17808d769f65e95e233b468a12c9117a32f70b7faa7cc301a1b185c671a5ae470e376c891a767bce89a33d18415e167740dfc100820ad7096ba54a3901067f4c6a350f4450c91ac72ef3e86f228a508a8c5bfbad63868ee003ee4083fabc22e762e457e2c743306f906c8e0cb4bb1bc70ece6c583aa4f0b5ce7ed2211596000851ed2d008eb92f11478623d866ef0be321e6851a904696c9061f23da06134efd57616fc291fb577da7548e03fe0a248bd96311f62c1b76f5c23ff62c2f005ef3000a5b1bea9172c3f22b1de93881c356845edba2344217626453b57a27707d051cd7040f8e6ff3319584a6c25050447727455996635666e11a281de2500118d0dc52010bef349eb8de625e641014b79a2cb766bed88ca02b1df6ca7c73e4cf9e67f7cbe8417c764cd84c132dc1d4cf7997159a06245378e62387a80de8324f9e58faff34010cd4917b8f68f037246367fd19db214cc187656ea2f765e88dd07729ea419e55bd0d5426a40b8fe9d27d5e178707cdba10259725e3b0c677b27f9be219b6170fb0010d8259fbef03dfbc1ac9a7b4fb085db0b4343583c202b699a1acb9eb5b4772a85c602d666d7af69091304ae95a8eca681811468c63876ea014e68700b1aae20b0e010f8e5645cd99bc2ad990097554b39b12a7262cdec7be29dc149e7bd20452b9a9520cec9ea1b2cce87986450d815798ff963e348fc78249196390fd9a253d6a16ba00108cba568e308e8b5e828fd3869452a01a57d330635a9b174e56023a6e959c79af3aef3868a857d1e0a45291fbc00aaab9b944430f498338fe016daae00728596101116e7b022947c1f864022fe6b73b89fcd984482eeda9e63aa1c7d0c6e9c999088d789b905c644ed7717aea85b3d6339629b7571a3d0fe6852a83976bff6445d09f0168f38f8400000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa710000000009d1b8c6014155575600000000000edf59c3000027102d33c0a3a41ee75c7147583fe1857fc6df024f5f02005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12005500ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace0000005a5bf3b92f00000000077ccd85fffffff80000000068f38f840000000068f38f830000005a60200d90000000000798a9340d41f7a9d77dd155901b0669d8ab8821f0a382152c2d32c77b6e796d14548a46644bbbce1823f3d1e1fed4b4825fc41b4ae50da5320d05e02cc3373eea0cd21aa98c557c92c6e566886b022b9d090ae2e06f2e094d0691b8945bf990669e817d701c49c3cf3abeb9b5d305c977cb5bce7a9cf772ca97791ba4652988523bfaecafef2845777748fa270b60355e59a0eb28d73121841dfe0591ae0bb89ee00d1017d0c197723bd22798b35b626c502ff9b3385add71351447228a7966bb28b20b042a2ad0d03bb08e8f98b343bd1dddaab3316395461029b6a9fcb1266a96cc6675fefe740935c130a8ec0b244fa25e5ed33937772b3b3ead3695d555c3dc2038d0b5dcbd12\nAppend 0x to the bytes, and send it to parsePriceFeedUpdates.\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n You can message me on my tg here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Can’t fetch historical prices with Pyth Terminal API\n\n Price Feeds\n\n 11\n\n 116\n\n Aug 5\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n Byte by byte breakdown of Hex encoded data received in latest price update API\n\n Price Feeds\n\n evm\n\n 5\n\n 717\n\n Jun 2025\n\n Powered by Discourse","tokens":2131,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263939376,"hash":"6bf5491466ca10d99154cee8b9dbd1f953182f56"}
{"url":"https://docs.arbitrum.io/arbitrum-essentials/arbitrum-vs-ethereum/rpc-methods","domain":"docs.arbitrum.io","title":"RPC methods | Arbitrum Docs","text":"✏️Request an updateAlthough the majority of RPC methods follow the same behavior as in Ethereum, some methods may produce a different result or add more information when used on an Arbitrum chain. This page covers the differences in response body fields you'll find when calling RPC methods on an Arbitrum chain vs on Ethereum.\ninfoComprehensive documentation on all generally available JSON-RPC methods for Ethereum can be found at ethereum.org. As Arbitrum has go-ethereum at its core, most of the documented methods there can be used with no modifications.\nTransactions​\nWhen calling eth_getTransactionByHash and other methods that return a transaction, Arbitrum includes a few additional fields and leverages some existing fields in different ways than Ethereum.\nTransaction types​\nIn addition to the three transaction types currently supported on Ethereum, Arbitrum adds additional types listed below and documented in full detail here. Many of these types are emitted when bridging from a parent chain.\nOn RPC calls that return transactions, the type field will reflect the custom codes where applicable.\nTransaction type codeTransaction type nameDescription100ArbitrumDepositTxTypeUsed to deposit ETH from a parent chain to a child chain via the Arbitrum bridge101ArbitrumUnsignedTxTypeUsed to call a child chain contract from a parent chain, originated by a user through the Arbitrum bridge102ArbitrumContractTxTypeUsed to call a child chain contract from a parent chain, originated by a contract through the Arbitrum bridge104ArbitrumRetryTxTypeUsed to manually redeem a retryable ticket on a child chain that failed to execute automatically (usually due to low gas)105ArbitrumSubmitRetryableTxTypeUsed to submit a retryable ticket via the Arbitrum bridge on the parent chain106ArbitrumInternalTxTypeInternal transactions created by the ArbOS itself for certain state updates, like the parent chain base fee and the block number\nAdditional fields​\nOn RPC calls that return transactions, the following fields are added to the returned object.\nField nameDescriptionrequestIdOn parent to child chain transactions, this field is added to indicate position in the Inbox queue\nArbitrum specific eth JSON-RPC additions​\n\neth_sendRawTransactionConditional submits a raw signed transaction with extra preconditions that the sequencer must verify before accepting it. If any condition fails, the transaction is rejected with JSON-RPC error -32003 (rejected).\n\nConditionalOptions payloadDescriptionknownAccountsmap of address → (storageRootHash slot: expectedValue). The transaction is rejected unless each account's storage root matches, or each listed slot still holds the expected value.blockNumberMin / blockNumberMaxL1 block-number window the transaction is valid.timestampMin / timestampMaxL2 timestamp window.\n\neth_sendRawTransactionSync submits a raw signed transaction and blocks until the node sees its receipt (or a timeout fires), returning the full receipt instead of just the tx hash.\n\nExisting fields with different behavior​\nOn RPC calls that return transactions, the following fields will have different content than what's received on Ethereum.\nField nameDescriptionfromOn parent to child chain transactions, this field will contain the aliased version of the parent chain's msg.sender\nTransaction receipts​\nWhen calling eth_getTransactionReceipt, Arbitrum includes a few additional fields and leverages some existing fields in different ways than Ethereum.\nAdditional fields​\nOn RPC calls that return transaction receipts, the following fields are added to the returned object.\nField nameDescriptionl1BlockNumberThe block number of the first non-Arbitrum ancestor chain that is usable for block.number calls. More information in Block numbers and timegasUsedForL1The amount of gas spent on parent chain calldata in units of child chain gas. More information in Gas and fees\nBlocks​\nWhen calling eth_getBlockByHash and other methods that return a block, Arbitrum includes a few additional fields and leverages some existing fields in different ways than Ethereum.\nAdditional fields​\nOn RPC calls that return a block, the following fields are added to the returned object.\nField nameDescriptionl1BlockNumberAn approximate block number of the first non-Arbitrum ancestor chain that occurred before this child chain block. More information in Block numbers and timesendCountThe number of child-to-parent chain messages since Nitro genesissendRootThe Merkle root of the outbox tree state\nExisting fields with different behavior​\nOn RPC calls that return a block, the following fields will have different content than what's received on Ethereum.\nField nameDescriptionextraDataThis field is equivalent to sendRootmixHashFirst 8 bytes are equivalent to sendCount, second 8 bytes are equivalent to l1BlockNumberdifficultyFixed at 0x1gasLimitValue is fixed at 0x4000000000000, but it's important to note that Arbitrum One currently has a 32M gas limit per block. See Chain params for the gas limit of other chains\nOther methods that are slightly different​\neth_syncing​\nCalling eth_syncing returns false when the node is fully synced (just like on Ethereum). If the node is still syncing, eth_syncing returns an object with data about the synchronization status. Here, we provide more details.\nUnderstanding messages, batches, and blocks​\nNitro nodes receive transactions from their parent chain and the sequencer feed in the form of messages. These messages may contain multiple transactions that are executed by the node, which then produces blocks. Each message produces exactly one block. In most Nitro chains, the message number and the block number are the same. However, Arbitrum One has pre-Nitro (classic) blocks, so for that chain, message 0 produced block 22207818 (blocks before that one are 'classic' blocks). Keep in mind that the offset between the message and block number remains constant throughout the chain.\nOn the parent chain, messages appear in batches. The number of messages per batch changes between batches.\nCustom eth_syncing fields​\ninfoNote that the exact output for the eth_syncing RPC call of an out-of-sync Nitro node is not considered a stable API. It is still being actively developed and can be modified without notice between versions.\nField nameDescriptionbatchSeenLast batch number observed on the parent chainbatchProcessedLast batch that was processed on the parent chain. Processing means dividing the batch into messagesmessageOfProcessedBatchLast message in the last processed batchmsgCountNumber of messages known/queued by the Nitro nodeblockNumLast block created by the Nitro node (up-to-date child chain block the node is synced to)messageOfLastBlockMessage that was used to produce the block abovebroadcasterQueuedMessagesPosIf different than 0, this is expected to be greater than msgCount. This field notes a message that was read from the feed but not processed because earlier messages are still missinglastL1BlockNumLast block number of the first non-Arbitrum ancestor chain that Nitro sees. This is for debugging the connection with the parent chainlastl1BlockHashLast block hash from the parent chain that Nitro sees. This is for debugging the connection with the parent chain\nPotential, but not expected errorIf the sync process encounters an error while trying to collect the data above this error will be added to the response.\nUnderstanding common scenarios​\n\nIf batchSeen > batchProcessed, some batches have still not been processed\nIf msgCount > messageOfLastBlock, some messages have been processed, but not all relevant blocks have been built (this is usually the longest stage while syncing a new node)\nIf broadcasterQueuedMessagesPos > msgCount, the feed is ahead of the last message known to the node\n\ndebug_traceTransaction​\nThe Nitro node provides a native tracer for debugging Stylus contracts called stylusTracer, which returns a JSON array with objects containing the metadata for each executed HostIO.\nHostIOs are calls the WasmVM makes to read and write data in the EVM.\nWith the result of this tracer and the code for the Stylus contract, you have all the data to understand what happened in a Stylus transaction.\ninfoThe cargo-stylus command-line tool uses the stylusTracer to replay transactions locally inside a debugger.\nMore information can be found on How to debug Stylus transactions using Cargo Stylus Replay.\nThe table below describes each field of the stylusTracer return value.\nField NameDescriptionnameName of the executing HostIO.argsArguments of the HostIO encoded as hex.outsOutputs of the HostIO encoded as hex.startInkAmount of Ink before executing the HostIO.endInkAmount of Ink after executing the HostIO.addressFor call HostIOs, the address of the called contract.stepsFor call HostIOs, the steps performed by the called contract.\nFor example, the command below illustrates how to call this tracer for a transaction:\ncurl -s \\ -X POST \\ -H \"Content-Type: application/json\" \\ -d '{\"jsonrpc\":\"2.0\",\"method\":\"debug_traceTransaction\",\"params\":[\"<transaction-hash>\", {\"tracer\": \"stylusTracer\"}],\"id\":1}' \\ <nitro-node-rpc>\nThe result of this call will be something along the lines of:\n{ \"jsonrpc\": \"2.0\", \"id\": 1, \"result\": [ { \"args\": \"0x00000024\", \"endInk\": 116090000, \"name\": \"user_entrypoint\", \"outs\": \"0x\", \"startInk\": 116090000 }, { \"args\": \"0x\", \"endInk\": 116057558, \"name\": \"msg_reentrant\", \"outs\": \"0x00000000\", \"startInk\": 116065958 }, { \"args\": \"0x\", \"endInk\": 115937952, \"name\": \"read_args\", \"outs\": \"0x6c5283490000000000000000000000003bdff922e18bc03f1cf7b2a8b65a070cbec944f2\", \"startInk\": 115951512 }, ... ]}\ntxpool methods​\nNitro's default HTTP API namespaces are net, web3, eth, and arb. The txpool namespace is not among them, so txpool_content, txpool_contentFrom, txpool_status, and txpool_inspect return a method-not-found error on a default node.\nEnabling the namespace (by adding txpool to the node's --http.api list) changes less than you might expect, because Arbitrum has no transaction pool at all — the concept does not exist in Nitro's architecture. On Ethereum, the pool holds transactions waiting to be picked up by whichever validator builds the next block. An Arbitrum chain has no equivalent: the sequencer receives transactions and orders them directly through its internal queue, other nodes simply forward transactions to it, and no node ever holds a pool of pending transactions. Nitro ships only a compatibility stub for tooling that probes this namespace: with it enabled, txpool_content responds but always returns empty pending and queued sets, and txpool_contentFrom, txpool_status, and txpool_inspect remain unavailable. Do not build tooling that expects these methods to show the sequencer's intake. Nonce handling differs for the same reason — to learn more, see Nonce management.\neth_getLogs block ranges​\nNitro imposes no block-range limit on eth_getLogs. A range limit you encounter in practice comes from the RPC provider in front of the node, not from Nitro, so the ceiling depends on whose endpoint you are querying. Check your provider's documentation rather than assuming a protocol-level value.\nFor a sense of what ranges are widely tolerated, Nitro chunks its own parent chain log queries conservatively: message extraction prefetches 499 blocks at a time, and the BoLD validator reads in chunks of 5,000 via --node.bold.max-get-log-blocks. Those are Nitro acting as a client against someone else's endpoint, not limits it enforces on yours.\nIf you are running your own node and querying it directly, large ranges are bounded by memory and response time rather than by a configured cap. Paginate wide historical queries regardless.TransactionsTransaction typesAdditional fieldsArbitrum specific eth JSON-RPC additionsExisting fields with different behaviorTransaction receiptsAdditional fieldsBlocksAdditional fieldsExisting fields with different behaviorOther methods that are slightly differenteth_syncingdebug_traceTransactiontxpool methodseth_getLogs block ranges","tokens":3005,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263947096,"hash":"f7e65f633a65191be2bdb6ef0283c192acc637fc"}
{"url":"https://dev-forum.pyth.network/t/byte-by-byte-breakdown-of-hex-encoded-data-received-in-latest-price-update-api/232/6","domain":"dev-forum.pyth.network","title":"Byte by byte breakdown of Hex encoded data received in latest price update API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jun 2025\n\n 6 / 6\n\n Jun 2025\n\n Jun 2025\n\n post by nihar29 on Jun 24, 2025\n\n nihar29\n\n Hi, I was working on a use case that required some documentation that is not available on the website.\nI was making use of this latest price updates API\nhttps://hermes.pyth.network/v2/updates/price/latest?ids[]=0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&ids[]=0xc96458d393fe9deb7a7d63a0ac41e2898a67a7750dbd166673279e06c868df0a\nIn the output, I received a hex string. I would like to have a documentation describing byte by byte breakdown of this hex string. I want to build an encoder of my own which will generate the hex encoded string that will be sent as an input to updatePriceFeeds() API. So, this data that my encoder will generate needs to be in correct format so that it is not rejected by updatePriceFeeds() API.\n• Chain: Ethereum Mainnet\n• Timestamp of the issue (block time or UTC): 1750801394\n• Steps to reproduce the issue\n\nMake a call to this API endpoint:\n\nhttps://hermes.pyth.network/v2/updates/price/latest?ids[]=0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&ids[]=0xc96458d393fe9deb7a7d63a0ac41e2898a67a7750dbd166673279e06c868df0a\n\nAnd now you’ll receive the following hex encoded string in output:\n\n504e41550100000003b801000000040d00561f4ceb8ce5eb58adda318009817714a017b0db9a7f1ef57253c81d1984d8140cdee5c06925a1cbd7a2612211fddcd91008dd854444b513519a06fdc1a7b00101021612a8c846810b86a42eb3c9fc25ad9b1c5bbccf6bcd2df39fa83bfd580a58646d508fa28c4cecd8878eefaf964eca8de36031cad28b3c8a870a409a8b0a062d0003e8c8dd8bc33307235e3073e7a66af5087824628e8e6b4fa02df9e8fd1bf4757f28388255e1866b52edb0d8f604e97c6afcb05a33dce52b48dbdeeea85028e9ac0004460bf2bce4fd0f84961c20728aa48d35c35ca7347ad6229800312013e3645371016c837a779fe8c31e6e9b6d5cdeb41e6e215627d6a51e2bf8faaa7ddf25e0ec00065283785418ac10b5b7ee3eb5b753f7e319a6c9890180821c8c6b2b57912ec96d315c91ab544c330839ee1c23f3fefdd063cd36fa77dc06a84a566bf30d9f4c2d01075a1471c93ce6275e0319438f013058aeaf3c4029bab24f3bf8b89786992ff03513440d8a61c4a31b76ea14fd96ec010a52ce2aa6212783163532b6bee047d90b000a4ab3faa7466ed5a62402024f62e0f6ea10b5e44341bf1869dc0317091cbc38444c27c4e88f6d9a8f0c85355c341b108537f01e79363e5c27331e031cccec82bb000b56537c736f12f44027c86e16da23af8515535b7839ff9095a93db178450f954f10f7c7ea7b8132f1b75909aa996ea6fb661cc3bbf12624f88c646fe2f964279d000d1edd3f3b34464a2a103ae7b6a2705f385207d4a91d721a175157f9238d0a54dd1127286db3a13ff1df67f02f195b665c09e4301f9df8fcfd251fefba30d12190010e8814c0416af5a6c702fbdee573ea5819a8ec452db5d182fafc37b47c25937e1d6359b17ddedd696056732ae37a80463ce515b85744a5342999599a9bdcc75ea2010f5821c0d3a9887f0f5f1c59e5a7e62d98fa7f4cd737c44ce4d26f3b466ffe5b310fed58f2282d0449de119d8ad12788624e87aee0d5f49d8881eaa14b5f2d653f00117d01a5a41e69dc58ce406c51ba2254128faa522b69d7f8c8a2eeb862858469eb119c119439513a1e068ad8df5214b251c6b4ef74600366935bdb1b72244dc97200128e34e3a83b7382a8f498235a52efea79d0c9a4e1de30340d70b5e9d8013927be137185a5423ae05a743fd4c5d2374de5aba72d86f70b7bfb2eb88ef8df052e79016634f2f500000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa7100000000033d2ada01415557560000000000084728a20000271034997d7ffc8a4495fd78fed48c2bf8d5e188d74e02005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b4300000595cfbc774800000000c3f8e497fffffff8000000006634f2f5000000006634f2f50000058adefc436000000000e212dff80ab660ac1113aacd22a0d1e837a9cbbb4316ccdd64272484102a99c1337c282e56981a68916d29df1d1716b33f63a3b78b8d7b88ab46652879685487e2520aed797adec6550872f99049088ffbde70766eadb20520615efadb40d92afc542d42a113e1ef3c2d2bb920002cfb5b0bb3452b59e5e59585e25964682084851e189cf74861cd010893df90a7718062c4b6e89f5bfa8269d152c6f58be368cc588af6575595bc376b65a0e7f916fc5eef915402a661ccf024bf94f181b8193367251f0d7411aa23094626f7005500c96458d393fe9deb7a7d63a0ac41e2898a67a7750dbd166673279e06c868df0a00000000004bad0f0000000000001559fffffff8000000006634f2f5000000006634f2f500000000004c074200000000000015a00a3f32b0cd92140161520c68b4df848dce5b315f5a67f61563ec3b2fb6b17ab64fe530f438c7f035cb7c204ba80e3c6b8e14fc54f10b8e79af497f7dbf3c225f183f509b2db99ab2fdee7f1a36b699cc6fc1a868ad8b7fbf9a28461133fb45cb7940271678ca5835657a5089335850924b016ef17cc280e4f7582c879140889bbe4a4d39d5160d5b71f7983a53c4b6e89f5bfa8269d152c6f58be368cc588af6575595bc376b65a0e7f916fc5eef915402a661ccf024bf94f181b8193367251f0d7411aa23094626f7\n• Contact: nihardangi@ymail.com\n\n 3\n\n 2\n\n post by ali on Jun 25, 2025\n\n ali\n\n Hi @nihar29, you cannot just encode arbitrary prices and send them to the contract. The price updates contain numerous signatures to verify it is coming from Pythnet and they cannot be forged.\nThe wire format lives here.\n\n post by nihar29 on Jun 25, 2025\n\n nihar29\n\n Hi @ali , thanks for replying.\nWhat if I want to send only one price feed to updatePriceFeeds() instead of 2? How should I make changes to the original packet that contains data for 2 price feeds?\n\n How to extract & re-encode specific price feed updates from Hermes hex blob?\n\n post by obiyankenobi on Jun 25, 2025\n\n obiyankenobi\n\n You can see the detailed breakdown of the hex data here: New chain integration - data format and validation - #4 by benji\n\n post by ali on Jun 26, 2025\n\n ali\n\n @nihar29 unfortunately we don’t have any API/SDK to do it automatically. You can make separate requests for them and you can always merge them as onchain update data is an array (albeit it’ll be more expensive). Until we add it in the future if you are ok to write code, this test deserializes an update data and if you see the format, you can simply remove one feed from it.\n\n post by ali on Jun 26, 2025\n\n ali\n\n Actually I just realized that we have utilities in our Python SDK that might help you out to parse the update data and later serialize it (see this module and look for accumulator update data). Specifically we have a method that can combine two separate update data (this)\n\n New chain integration - data format and validation\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to extract & re-encode specific price feed updates from Hermes hex blob?\n\n Price Feeds\n\n 1\n\n 479\n\n Jun 2025\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 525\n\n Oct 2025\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 880\n\n Jul 2025\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Powered by Discourse","tokens":2534,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263949463,"hash":"7dd6bc0abbba53dbb4766b5040aebb04af947eed"}
{"url":"https://docs.soliditylang.org/en/develop/060-breaking-changes.html","domain":"docs.soliditylang.org","title":"Solidity v0.6.0 Breaking Changes — Solidity 0.8.38-develop documentation","text":"Solidity v0.6.0 Breaking Changes\n\n Edit on GitHub\n\nSolidity v0.6.0 Breaking Changes\nThis section highlights the main breaking changes introduced in Solidity\nversion 0.6.0, along with the reasoning behind the changes and how to update\naffected code.\nFor the full list check\nthe release changelog.\n\nChanges the Compiler Might not Warn About\nThis section lists changes where the behavior of your code might\nchange without the compiler telling you about it.\n\nThe resulting type of an exponentiation is the type of the base. It used to be the smallest type\nthat can hold both the type of the base and the type of the exponent, as with symmetric\noperations. Additionally, signed types are allowed for the base of the exponentiation.\n\nExplicitness Requirements\nThis section lists changes where the code now needs to be more explicit,\nbut the semantics do not change.\nFor most of the topics the compiler will provide suggestions.\n\nFunctions can now only be overridden when they are either marked with the\nvirtual keyword or defined in an interface. Functions without\nimplementation outside an interface have to be marked virtual.\nWhen overriding a function or modifier, the new keyword override\nmust be used. When overriding a function or modifier defined in multiple\nparallel bases, all bases must be listed in parentheses after the keyword\nlike so: override(Base1, Base2).\nMember-access to length of arrays is now always read-only, even for storage arrays. It is no\nlonger possible to resize storage arrays by assigning a new value to their length. Use push(),\npush(value) or pop() instead, or assign a full array, which will of course overwrite the existing content.\nThe reason behind this is to prevent storage collisions of gigantic\nstorage arrays.\nThe new keyword abstract can be used to mark contracts as abstract. It has to be used\nif a contract does not implement all its functions. Abstract contracts cannot be created using the new operator,\nand it is not possible to generate bytecode for them during compilation.\nLibraries have to implement all their functions, not only the internal ones.\nThe names of variables declared in inline assembly may no longer end in _slot or _offset.\nVariable declarations in inline assembly may no longer shadow any declaration outside the inline assembly block.\nIf the name contains a dot, its prefix up to the dot may not conflict with any declaration outside the inline\nassembly block.\nIn inline assembly, opcodes that do not take arguments are now represented as “built-in functions” instead of standalone identifiers. So gas is now gas().\nState variable shadowing is now disallowed. A derived contract can only\ndeclare a state variable x, if there is no visible state variable with\nthe same name in any of its bases.\n\nSemantic and Syntactic Changes\nThis section lists changes where you have to modify your code\nand it does something else afterwards.\n\nConversions from external function types to address are now disallowed. Instead external\nfunction types have a member called address, similar to the existing selector member.\nThe function push(value) for dynamic storage arrays does not return the new length anymore (it returns nothing).\nThe unnamed function commonly referred to as “fallback function” was split up into a new\nfallback function that is defined using the fallback keyword and a receive ether function\ndefined using the receive keyword.\n\nIf present, the receive ether function is called whenever the call data is empty (whether\nor not ether is received). This function is implicitly payable.\nThe new fallback function is called when no other function matches (if the receive ether\nfunction does not exist then this includes calls with empty call data).\nYou can make this function payable or not. If it is not payable then transactions\nnot matching any other function which send value will revert. You should only need to\nimplement the new fallback function if you are following an upgrade or proxy pattern.\n\nNew Features\nThis section lists things that were not possible prior to Solidity 0.6.0\nor were more difficult to achieve.\n\nThe try/catch statement allows you to react on failed external calls.\nstruct and enum types can be declared at file level.\nArray slices can be used for calldata arrays, for example abi.decode(msg.data[4:], (uint, uint))\nis a low-level way to decode the function call payload.\nNatspec supports multiple return parameters in developer documentation, enforcing the same naming check as @param.\nYul and Inline Assembly have a new statement called leave that exits the current function.\nConversions from address to address payable are now possible via payable(x), where\nx must be of type address.\n\nInterface Changes\nThis section lists changes that are unrelated to the language itself, but that have an effect on the interfaces of\nthe compiler. These may change the way how you use the compiler on the command-line, how you use its programmable\ninterface, or how you analyze the output produced by it.\n\nNew Error Reporter\nA new error reporter was introduced, which aims at producing more accessible error messages on the command-line.\nIt is enabled by default, but passing --old-reporter falls back to the deprecated old error reporter.\n\nMetadata Hash Options\nThe compiler now appends the IPFS hash of the metadata file to the end of the bytecode by default\n(for details, see documentation on contract metadata). Before 0.6.0, the compiler appended the\nSwarm hash by default, and in order to still support this behavior,\nthe new command-line option --metadata-hash was introduced. It allows you to select the hash to be produced and\nappended, by passing either ipfs or swarm as value to the --metadata-hash command-line option.\nPassing the value none completely removes the hash.\nThese changes can also be used via the Standard JSON Interface and effect the metadata JSON generated by the compiler.\nThe recommended way to read the metadata is to read the last two bytes to determine the length of the CBOR encoding\nand perform a proper decoding on that data block as explained in the metadata section.\n\nYul Optimizer\nTogether with the legacy bytecode optimizer, the Yul optimizer is now enabled by default when you call the compiler\nwith --optimize. It can be disabled by calling the compiler with --no-optimize-yul.\nThis mostly affects code that uses ABI coder v2.\n\nC API Changes\nThe client code that uses the C API of libsolc is now in control of the memory used by the compiler. To make\nthis change consistent, solidity_free was renamed to solidity_reset, the functions solidity_alloc and\nsolidity_free were added and solidity_compile now returns a string that must be explicitly freed via\nsolidity_free().\n\nHow to update your code\nThis section gives detailed instructions on how to update prior code for every breaking change.\n\nChange address(f) to f.address for f being of external function type.\nReplace function () external [payable] { ... } by either receive() external payable { ... },\nfallback() external [payable] { ... } or both. Prefer\nusing a receive function only, whenever possible.\nChange uint length = array.push(value) to array.push(value);. The new length can be\naccessed via array.length.\nChange array.length++ to array.push() to increase, and use pop() to decrease\nthe length of a storage array.\nFor every named return parameter in a function’s @dev documentation define a @return\nentry which contains the parameter’s name as the first word. E.g. if you have function f() defined\nlike function f() public returns (uint value) and a @dev annotating it, document its return\nparameters like so: @return value The return value.. You can mix named and un-named return parameters\ndocumentation so long as the notices are in the order they appear in the tuple return type.\nChoose unique identifiers for variable declarations in inline assembly that do not conflict\nwith declarations outside the inline assembly block.\nAdd virtual to every non-interface function you intend to override. Add virtual\nto all functions without implementation outside interfaces. For single inheritance, add\noverride to every overriding function. For multiple inheritance, add override(A, B, ..),\nwhere you list all contracts that define the overridden function in the parentheses. When\nmultiple bases define the same function, the inheriting contract must override all conflicting functions.\nIn inline assembly, add () to all opcodes that do not otherwise accept an argument.\nFor example, change pc to pc(), and gas to gas().","tokens":2128,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263956620,"hash":"6a1a1ea45c5d00de0c20f1bc5613867306bdf074"}
{"url":"https://ethereum.org/en/developers/docs/transactions/","domain":"ethereum.org","title":"Transactions | ethereum.org","text":"TransactionsEdit page (opens in a new tab)Transactions are cryptographically signed instructions from accounts. An account will initiate a transaction to update the state of the Ethereum network. The simplest transaction is transferring ETH from one account to another.\nPrerequisites\nTo help you better understand this page, we recommend you first read Accounts and our introduction to Ethereum.\nWhat's a transaction?\nAn Ethereum transaction refers to an action initiated by an externally-owned account, in other words an account managed by a human, not a contract. For example, if Bob sends Alice 1 ETH, Bob's account must be debited and Alice's must be credited. This state-changing action takes place within a transaction.\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nTransactions, which change the state of the EVM, need to be broadcast to the whole network. Any node can broadcast a request for a transaction to be executed on the EVM; after this happens, a validator will execute the transaction and propagate the resulting state change to the rest of the network.\nTransactions require a fee and must be included in a validated block. To make this overview simpler we'll cover gas fees and validation elsewhere.\nA submitted transaction includes the following information:\n\nfrom – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions\nto – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code)\nsignature – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction\nnonce - a sequentially incrementing counter which indicates the transaction number from the account\nvalue – amount of ETH to transfer from sender to recipient (denominated in WEI, where 1ETH equals 1e+18wei)\ninput data – optional field to include arbitrary data\ngasLimit – the maximum amount of gas units that can be consumed by the transaction. The EVM specifies the units of gas required by each computational step\nmaxPriorityFeePerGas - the maximum price of the consumed gas to be included as a tip to the validator\nmaxFeePerGas - the maximum fee per unit of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)\n\nGas is a reference to the computation required to process the transaction by a validator. Users have to pay a fee for this computation. The gasLimit, and maxPriorityFeePerGas determine the maximum transaction fee paid to the validator. More on Gas.\nThe transaction object will look a little like this:\n{\n from: \"0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8\",\n to: \"0xac03bb73b6a9e108530aff4df5077c2b3d481e5a\",\n gasLimit: \"21000\",\n maxFeePerGas: \"300\",\n maxPriorityFeePerGas: \"10\",\n nonce: \"0\",\n value: \"10000000000\"\n}\n\nBut a transaction object needs to be signed using the sender's private key. This proves that the transaction could only have come from the sender and was not sent fraudulently.\nAn Ethereum client like Geth will handle this signing process.\nExample JSON-RPC call:\n{\n \"id\": 2,\n \"jsonrpc\": \"2.0\",\n \"method\": \"account_signTransaction\",\n \"params\": [\n {\n \"from\": \"0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db\",\n \"gas\": \"0x55555\",\n \"maxFeePerGas\": \"0x1234\",\n \"maxPriorityFeePerGas\": \"0x1234\",\n \"input\": \"0xabcd\",\n \"nonce\": \"0x0\",\n \"to\": \"0x07a565b7ed7d7a678680a4c162885bedbb695fe0\",\n \"value\": \"0x1234\"\n }\n ]\n}\n\nExample response:\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 2,\n \"result\": {\n \"raw\": \"0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663\",\n \"tx\": {\n \"nonce\": \"0x0\",\n \"maxFeePerGas\": \"0x1234\",\n \"maxPriorityFeePerGas\": \"0x1234\",\n \"gas\": \"0x55555\",\n \"to\": \"0x07a565b7ed7d7a678680a4c162885bedbb695fe0\",\n \"value\": \"0x1234\",\n \"input\": \"0xabcd\",\n \"v\": \"0x26\",\n \"r\": \"0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e\",\n \"s\": \"0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663\",\n \"hash\": \"0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e\"\n }\n }\n}\n\nthe raw is the signed transaction in Recursive Length Prefix (RLP) encoded form\nthe tx is the signed transaction in JSON form\n\nWith the signature hash, the transaction can be cryptographically proven that it came from the sender and submitted to the network.\nThe data field\nThe vast majority of transactions access a contract from an externally-owned account.\nMost contracts are written in Solidity and interpret their data field in accordance with the .\nThe first four bytes specify which function to call, using the hash of the function's name and arguments.\nYou can sometimes identify the function from the selector using this database (opens in a new tab).\nThe rest of the calldata is the arguments, encoded as specified in the ABI specs (opens in a new tab).\nFor example, lets look at this transaction (opens in a new tab).\nUse Click to see More to see the calldata.\nThe function selector is 0xa9059cbb. There are several known functions with this signature (opens in a new tab).\nIn this case the contract source code (opens in a new tab) has been uploaded to Etherscan, so we know the function is transfer(address,uint256).\nThe rest of the data is:\n0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279\n000000000000000000000000000000000000000000000000000000003b0559f4\n\nAccording to the ABI specifications, integer values (such as addresses, which are 20-byte integers) appear in the ABI as 32-byte words, padded with zeros in the front.\nSo we know that the to address is 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab).\nThe value is 0x3b0559f4 = 990206452.\nTransaction descriptors\nBecause the data field contains opaque hexadecimal bytes, it can be extremely difficult to verify what action a transaction will actually perform. This \"blind signing\" vulnerability is addressed by Clear Signing (opens in a new tab) through the use of transaction descriptors (opens in a new tab) (defined by ERC-7730).\nThe ERC-7730 specification uses transaction descriptors (often structured as JSON files) to enrich the data found in ABIs and structured messages, like EVM transaction calldata, EIP-712 messages, and EIP-4337 User Operations. Developers use these descriptors to map specific transaction variables directly into formatting templates, ensuring the underlying data remains machine-readable for applications.\nOn the frontend, wallets use this formatting context to translate opaque bytecode into clear, human-readable information. By automatically resolving values like token addresses into recognized tickers, or amounts into decimals, users are presented with a plain-language summary of the transaction's exact intent (e.g., 'Swap 1000 USDC for at least 0.25 WETH') before they sign\nTypes of transactions\nOn Ethereum there are a few different types of transactions:\n\nRegular transactions: a transaction from one account to another.\nContract deployment transactions: a transaction without a 'to' address, where the data field is used for the contract code.\nExecution of a contract: a transaction that interacts with a deployed smart contract. In this case, 'to' address is the smart contract address.\n\nOn gas\nAs mentioned, transactions cost gas to execute. Simple transfer transactions require 21000 units of Gas.\nSo for Bob to send Alice 1 ETH at a baseFeePerGas of 190 gwei and maxPriorityFeePerGas of 10 gwei, Bob will need to pay the following fee:\n(190 + 10) * 21000 = 4,200,000 gwei\n--or--\n0.0042 ETH\n\nBob's account will be debited -1.0042 ETH (1 ETH for Alice + 0.0042 ETH in gas fees)\nAlice's account will be credited +1.0 ETH\nThe base fee will be burned -0.00399 ETH\nValidator keeps the tip +0.000210 ETH\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nAny gas not used in a transaction is refunded to the user account.\nSmart contract interactions\nGas is required for any transaction that involves a smart contract.\nSmart contracts can also contain functions known as view (opens in a new tab) or pure (opens in a new tab) functions, which do not alter the state of the contract. As such, calling these functions from an EOA will not require any gas. The underlying RPC call for this scenario is eth_call.\nUnlike when accessed using eth_call, these view or pure functions are also commonly called internally (i.e., from the contract itself or from another contract) which does cost gas.\nTransaction lifecycle\nOnce the transaction has been submitted the following happens:\n\nA transaction hash is cryptographically generated:\n0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017\nThe transaction is then broadcasted to the network and added to a transaction pool consisting of all other pending network transactions.\nA validator must pick your transaction and include it in a block in order to verify the transaction and consider it \"successful\".\nAs time passes the block containing your transaction will be upgraded to \"justified\" then \"finalized\". These upgrades make it much\nmore certain that your transaction was successful and will never be altered. Once a block is \"finalized\" it could only ever be changed\nby a network level attack that would cost many billions of dollars.\n\nA visual demo\nWatch Austin walk you through transactions, gas, and mining.\nTransactions — ETH.BUILDA demonstration of how Ethereum transactions work using the ETH.BUILD educational tool.Watch with transcript \nTyped Transaction Envelope\nEthereum originally had one format for transactions. Each transaction contained a nonce, gas price, gas limit, to address, value, data, v, r, and s. These fields are RLP-encoded, to look something like this:\nRLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])\nEthereum has evolved to support multiple types of transactions to allow for new features such as access lists and EIP-1559 (opens in a new tab) to be implemented without affecting legacy transaction formats.\nEIP-2718 (opens in a new tab) is what allows for this behavior. Transactions are interpreted as:\nTransactionType || TransactionPayload\nWhere the fields are defined as:\n\nTransactionType - a number between 0 and 0x7f, for a total of 128 possible transaction types.\nTransactionPayload - an arbitrary byte array defined by the transaction type.\n\nBased on the TransactionType value, a transaction can be classified as:\n\nType 0 (Legacy) Transactions: The original transaction format used since Ethereum's launch. They do not include features from EIP-1559 (opens in a new tab) such as dynamic gas fee calculations or access lists for smart contracts. Legacy transactions lack a specific prefix indicating their type in their serialized form, starting with the byte 0xf8 when using Recursive Length Prefix (RLP) encoding. The TransactionType value for these transactions is 0x0.\n\nType 1 Transactions: Introduced in EIP-2930 (opens in a new tab) as part of Ethereum's Berlin Upgrade, these transactions include an accessList parameter. This list specifies addresses and storage keys the transaction expects to access, helping to potentially reduce gas costs for complex transactions involving smart contracts. EIP-1559 fee market changes are not included in Type 1 transactions. Type 1 transactions also include a yParity parameter, which can either be 0x0 or 0x1, indicating the parity of the y-value of the secp256k1 signature. They are identified by starting with the byte 0x01, and their TransactionType value is 0x1.\n\nType 2 Transactions, commonly referred to as EIP-1559 transactions, are transactions introduced in EIP-1559 (opens in a new tab), in Ethereum's London Upgrade. They have become the standard transaction type on the Ethereum network. These transactions introduce a new fee market mechanism that improves predictability by separating the transaction fee into a base fee and a priority fee. They start with the byte 0x02 and include fields such as maxPriorityFeePerGas and maxFeePerGas. Type 2 transactions are now the default due to their flexibility and efficiency, especially favored during periods of high network congestion for their ability to help users manage transaction fees more predictably. The TransactionType value for these transactions is 0x2.\n\nType 3 (Blob) Transactions were introduced in EIP-4844 (opens in a new tab) as part of Ethereum's Dencun Upgrade. These transactions are designed to handle \"blob\" data (Binary Large Objects) more efficiently, particularly benefiting Layer 2 rollups by providing a way to post data to the Ethereum network at a lower cost. Blob transactions include additional fields such as blobVersionedHashes, maxFeePerBlobGas, and blobGasPrice. They start with the byte 0x03, and their TransactionType value is 0x3. Blob transactions represent a significant improvement in Ethereum's data availability and scaling capabilities.\n\nType 4 Transactions were introduced in EIP-7702 (opens in a new tab) as part of Ethereum’s Pectra Upgrade. These transactions are designed to be forward-compatible with account abstraction. They allow EOAs to temporarily behave like smart contract accounts without compromising their original functionality. They include an authorization_list parameter, which specifies the smart contract to which the EOA delegates its authority. After the transaction, the EOA’s code field will have the address of the delegated smart contract.\n\nFurther reading\n\nEIP-2718: Typed Transaction Envelope (opens in a new tab)\n\nKnow of a community resource that helped you? Edit this page and add it!\nRelated topics\n\nAccounts\nEthereum virtual machine (EVM)\nGas\n\nTest your Ethereum knowledgeTransactionsQuestion number 1:A transaction calls a function on a contract. How does the contract know which function to run?","tokens":3504,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263957293,"hash":"57bfd7348481013666ef424b6ff41e39b1787811"}
{"url":"https://dev-forum.pyth.network/t/cant-get-update-fee/298/9","domain":"dev-forum.pyth.network","title":"Cant get update fee - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n Jul 2025\n\n 9 / 9\n\n Jul 2025\n\n Jul 2025\n\n post by howie228 on Jul 14, 2025\n\n howie228\n\n Network: Monad Testnet\nTimestamp: yesterday and today\nSteps to reproduce:\n\nGet price feed id (mine is BTC/USD)\nCall the Hermes API to retrieve binary data\nPass the binary data to getUpdateFee\nError: invalid arrayify value (argument=“value”, value=\nAdditional notes:\nI am trying to create a prediction game on monad testnet that utilizes Pyth price feeds with Pyth Pull Oracle, Hermes API and Gelato Web3 Automated functions. The flow goes like this:\nwe have a round. there is a 20 second threshold where the users could bet if the price is going to go up or down. then, after 20 seconds, the round locks. we then get the updated data from hermes API, push it to the pull oracle via Gelato operator, compare the new price against the players’ bets and reward whoever won.\nright now stuck at getting the fees\n\n 6\n\n 3\n\n post by nidhi on Jul 14, 2025\n\n nidhi\n\n Can you please share how you are calling getUpdateFee. Also share the complete error logs.\nFor your reference Price Feeds | Pyth Network API Reference , you can test it here.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n hi, sorry for the delayed answer. i already found the issue, it was a mismatch in the types inside the contract. now i dont get any errors, but i still get 0 updates on price feed retrieval inside of the contract.\nhere is the function i have trouble with:\n function executeRound(bytes calldata pythUpdateData) external payable onlyOperator whenNotPaused {\n require(genesisStarted, \"Genesis not started\");\n\n uint256 currentRoundEpoch = currentEpoch;\n Round storage round = rounds[currentRoundEpoch];\n\n require(block.timestamp >= round.lockTimestamp, \"Too early to lock\");\n require(!round.settled, \"Round already settled\");\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pythUpdateData;\n\n uint256 fee = pyth.getUpdateFee(updateData);\n pyth.updatePriceFeeds{value: fee}(updateData);\n\n PythStructs.Price memory price = pyth.getPrice(priceId);\n\n round.lockPrice = price.price;\n round.lockTimestamp = block.timestamp;\n\n emit RoundLocked(currentRoundEpoch, round.lockPrice, block.timestamp);\n\n if (currentRoundEpoch > 1) {\n _settleRound(currentRoundEpoch - 1, price.price);\n }\n\n currentEpoch = currentRoundEpoch + 1;\n _startRound(currentEpoch);\n\n if (msg.value > fee) {\n (bool success, ) = msg.sender.call{value: msg.value - fee}(\"\");\n require(success, \"Refund failed\");\n }\n }\n\nit passes the calldata properly and the function runs all the way. however, whenever we retrieve prices via the contract, they are always 0. i tried reading the IPyth contract on Monad Testnet via javascript/ethers, and all the data was in place. However, whenever pyth.getPrice is being called via contract it returns 0. or i am not handling it properly. the address, abi and interface is the same in both cases.\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n I see few lines of code are redundant. You don’t have to create a new bytes array named updateData.\nRefer https://docs.pyth.network/price-feeds/use-real-time-data/evm#write-contract-code, change the data type of the input parameter to bytes[] calldata and use it directly.\nAlso getPrice has been deprecated, please use function getPriceNoOlderThan\nMay be create a simple version of the function and see if it works.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n i tried using bytes calldata in my previous contract, and it did not work for some reason. at least now it recognizes the calldata, so i’ll keep it like this because it does not revert. i also tried getPriceNoOlderThan(priceId, 20) right after the price update call, but i still get 0.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n and both of getPrice and getPriceNoOlderThan work properly called via js ethers script from the contract operator account. and they do have the values i need\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n That seems weird. Can you share which version of @pythnetwork/pyth-sdk-solidity are you using in your solidity smart contract.\nThere is additional logic involved other than getting pyth price feed.\nTo isolate the issue, can you try creating a simple version of function. Something similar to this pyth-pricefeed-demo/src/PriceFeed.sol at main · nidhi-singh02/pyth-pricefeed-demo · GitHub. Refer the README.md file for the instructions.\nRun it for your case as in Monad testnet and your asset pair and let me know the outcome please.\n\n post by howie228 on Jul 16, 2025\n\n howie228\n\n sure. using version 4.2.0 of pyth-sdk. will try to separate the update logic like in your example\n\n post by howie228 on Jul 17, 2025\n\n howie228\n\n update: i was finally able to update prices with actual data on my contract. your function separation helped most likely. i also rewrote quite a bit of code as well. but consider it solved\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 641\n\n May 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":2278,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263959609,"hash":"2d8c51ffecd7517f808a341df0e2659ed286185e"}
{"url":"https://docs.soliditylang.org/en/develop/path-resolution.html","domain":"docs.soliditylang.org","title":"Import Path Resolution — Solidity 0.8.38-develop documentation","text":"Import Path Resolution\n\n Edit on GitHub\n\nImport Path Resolution\nIn order to be able to support reproducible builds on all platforms, the Solidity compiler has to\nabstract away the details of the filesystem where source files are stored.\nPaths used in imports must work the same way everywhere while the command-line interface must be\nable to work with platform-specific paths to provide good user experience.\nThis section aims to explain in detail how Solidity reconciles these requirements.\n\nVirtual Filesystem\nThe compiler maintains an internal database (virtual filesystem or VFS for short) where each\nsource unit is assigned a unique source unit name which is an opaque and unstructured identifier.\nWhen you use the import statement, you specify an import path that references a\nsource unit name.\n\nImport Callback\nThe VFS is initially populated only with files the compiler has received as input.\nAdditional files can be loaded during compilation using an import callback, which is different\ndepending on the type of compiler you use (see below).\nIf the compiler does not find any source unit name matching the import path in the VFS, it invokes\nthe callback, which is responsible for obtaining the source code to be placed under that name.\nAn import callback is free to interpret source unit names in an arbitrary way, not just as paths.\nIf there is no callback available when one is needed or if it fails to locate the source code,\ncompilation fails.\nBy default, the command-line compiler provides the Host Filesystem Loader - a rudimentary callback\nthat interprets a source unit name as a path in the local filesystem.\nThis callback can be disabled using the --no-import-callback command-line option.\nThe JavaScript interface does not provide any by default,\nbut one can be provided by the user.\nThis mechanism can be used to obtain source code from locations other than the local filesystem\n(which may not even be accessible, e.g. when the compiler is running in a browser).\nFor example the Remix IDE provides a versatile callback that\nlets you import files from HTTP, IPFS and Swarm URLs or refer directly to packages in NPM registry.\n\nNote\nHost Filesystem Loader’s file lookup is platform-dependent.\nFor example backslashes in a source unit name can be interpreted as directory separators or not\nand the lookup can be case-sensitive or not, depending on the underlying platform.\nFor portability it is recommended to avoid using import paths that will work correctly only\nwith a specific import callback or only on one platform.\nFor example you should always use forward slashes since they work as path separators also on\nplatforms that support backslashes.\n\nInitial Content of the Virtual Filesystem\nThe initial content of the VFS depends on how you invoke the compiler:\n\nsolc / command-line interface\nWhen you compile a file using the command-line interface of the compiler, you provide one or\nmore paths to files containing Solidity code:\nsolc contract.sol /usr/local/dapp-bin/token.sol\n\nThe source unit name of a file loaded this way is constructed by converting its path to a\ncanonical form and, if possible, making it relative to either the base path or one of the\ninclude paths.\nSee CLI Path Normalization and Stripping for\na detailed description of this process.\n\nStandard JSON\nWhen using the Standard JSON API (via either the JavaScript interface or the --standard-json command-line option)\nyou provide input in JSON format, containing, among other things, the content of all your source\nfiles:\n{\n \"language\": \"Solidity\",\n \"sources\": {\n \"contract.sol\": {\n \"content\": \"import \\\"./util.sol\\\";\\ncontract C {}\"\n },\n \"util.sol\": {\n \"content\": \"library Util {}\"\n },\n \"/usr/local/dapp-bin/token.sol\": {\n \"content\": \"contract Token {}\"\n }\n },\n \"settings\": {\"outputSelection\": {\"*\": { \"*\": [\"metadata\", \"evm.bytecode\"]}}}\n}\n\nThe sources dictionary becomes the initial content of the virtual filesystem and its keys\nare used as source unit names.\n\nStandard JSON (via import callback)\nWith Standard JSON it is also possible to tell the compiler to use the import callback to obtain\nthe source code:\n{\n \"language\": \"Solidity\",\n \"sources\": {\n \"/usr/local/dapp-bin/token.sol\": {\n \"urls\": [\n \"/projects/mytoken.sol\",\n \"https://example.com/projects/mytoken.sol\"\n ]\n }\n },\n \"settings\": {\"outputSelection\": {\"*\": { \"*\": [\"metadata\", \"evm.bytecode\"]}}}\n}\n\nIf an import callback is available, the compiler will give it the strings specified in\nurls one by one, until one is loaded successfully or the end of the list is reached.\nThe source unit names are determined the same way as when using content - they are keys of\nthe sources dictionary and the content of urls does not affect them in any way.\n\nStandard input\nOn the command-line it is also possible to provide the source by sending it to compiler’s\nstandard input:\necho 'import \"./util.sol\"; contract C {}' | solc -\n\n- used as one of the arguments instructs the compiler to place the content of the standard\ninput in the virtual filesystem under a special source unit name: <stdin>.\n\nOnce the VFS is initialized, additional files can still be added to it only through the import\ncallback.\n\nImports\nThe import statement specifies an import path.\nBased on how the import path is specified, we can divide imports into two categories:\n\nDirect imports, where you specify the full source unit name directly.\nRelative imports, where you specify a path starting with ./ or ../\nto be combined with the source unit name of the importing file.\n\ncontracts/contract.sol\nopen in Remix\nimport \"./math/math.sol\";\nimport \"contracts/tokens/token.sol\";\n\nIn the above ./math/math.sol and contracts/tokens/token.sol are import paths while the\nsource unit names they translate to are contracts/math/math.sol and contracts/tokens/token.sol\nrespectively.\n\nDirect Imports\nAn import that does not start with ./ or ../ is a direct import.\nopen in Remix\nimport \"/project/lib/util.sol\"; // source unit name: /project/lib/util.sol\nimport \"lib/util.sol\"; // source unit name: lib/util.sol\nimport \"@openzeppelin/address.sol\"; // source unit name: @openzeppelin/address.sol\nimport \"https://example.com/token.sol\"; // source unit name: https://example.com/token.sol\n\nAfter applying any import remappings the import path simply becomes the\nsource unit name.\n\nNote\nA source unit name is just an identifier and even if its value happens to look like a path, it\nis not subject to the normalization rules you would typically expect in a shell.\nAny /./ or /../ segments or sequences of multiple slashes remain a part of it.\nWhen the source is provided via Standard JSON interface it is entirely possible to associate\ndifferent content with source unit names that would refer to the same file on disk.\n\nWhen the source is not available in the virtual filesystem, the compiler passes the source unit name\nto the import callback.\nThe Host Filesystem Loader will attempt to use it as a path and look up the file on disk.\nAt this point the platform-specific normalization rules kick in and names that were considered\ndifferent in the VFS may actually result in the same file being loaded.\nFor example /project/lib/math.sol and /project/lib/../lib///math.sol are considered\ncompletely different in the VFS even though they refer to the same file on disk.\n\nNote\nEven if an import callback ends up loading source code for two different source unit names from\nthe same file on disk, the compiler will still see them as separate source units.\nIt is the source unit name that matters, not the physical location of the code.\n\nRelative Imports\nAn import starting with ./ or ../ is a relative import.\nSuch imports specify a path relative to the source unit name of the importing source unit:\n\n/project/lib/math.sol\nopen in Remix\nimport \"./util.sol\" as util; // source unit name: /project/lib/util.sol\nimport \"../token.sol\" as token; // source unit name: /project/token.sol\n\nlib/math.sol\nopen in Remix\nimport \"./util.sol\" as util; // source unit name: lib/util.sol\nimport \"../token.sol\" as token; // source unit name: token.sol\n\nNote\nRelative imports always start with ./ or ../ so import \"util.sol\", unlike\nimport \"./util.sol\", is a direct import.\nWhile both paths would be considered relative in the host filesystem, util.sol is actually\nabsolute in the VFS.\n\nLet us define a path segment as any non-empty part of the path that does not contain a separator\nand is bounded by two path separators.\nA separator is a forward slash or the beginning/end of the string.\nFor example in ./abc/..// there are three path segments: ., abc and ...\nThe compiler resolves the import into a source unit name based on the import path, in the following way:\n\nWe start with the source unit name of the importing source unit.\nThe last path segment with preceding slashes is removed from the resolved name.\nThen, for every segment in the import path, starting from the leftmost one:\n\nIf the segment is ., it is skipped.\nIf the segment is .., the last path segment with preceding slashes is removed from the resolved name.\nOtherwise, the segment (preceded by a single slash if the resolved name is not empty), is appended to the resolved name.\n\nThe removal of the last path segment with preceding slashes is understood to\nwork as follows:\n\nEverything past the last slash is removed (i.e. a/b//c.sol becomes a/b//).\nAll trailing slashes are removed (i.e. a/b// becomes a/b).\n\nNote that the process normalizes the part of the resolved source unit name that comes from the import path according\nto the usual rules for UNIX paths, i.e. all . and .. are removed and multiple slashes are\nsquashed into a single one.\nOn the other hand, the part that comes from the source unit name of the importing module remains unnormalized.\nThis ensures that the protocol:// part does not turn into protocol:/ if the importing file\nis identified with a URL.\nIf your import paths are already normalized, you can expect the above algorithm to produce very\nintuitive results.\nHere are some examples of what you can expect if they are not:\n\nlib/src/../contract.sol\nopen in Remix\nimport \"./util/./util.sol\"; // source unit name: lib/src/../util/util.sol\nimport \"./util//util.sol\"; // source unit name: lib/src/../util/util.sol\nimport \"../util/../array/util.sol\"; // source unit name: lib/src/array/util.sol\nimport \"../.././../util.sol\"; // source unit name: util.sol\nimport \"../../.././../util.sol\"; // source unit name: util.sol\n\nNote\nThe use of relative imports containing leading .. segments is not recommended.\nThe same effect can be achieved in a more reliable way by using direct imports with\nbase path and include paths.\n\nBase Path and Include Paths\nThe base path and include paths represent directories that the Host Filesystem Loader will load files from.\nWhen a source unit name is passed to the loader, it prepends the base path to it and performs a\nfilesystem lookup.\nIf the lookup does not succeed, the same is done with all directories on the include path list.\nIt is recommended to set the base path to the root directory of your project and use include paths to\nspecify additional locations that may contain libraries your project depends on.\nThis lets you import from these libraries in a uniform way, no matter where they are located in the\nfilesystem relative to your project.\nFor example, if you use npm to install packages and your contract imports\n@openzeppelin/contracts/utils/Strings.sol, you can use these options to tell the compiler that\nthe library can be found in one of the npm package directories:\nsolc contract.sol \\\n --base-path . \\\n --include-path node_modules/ \\\n --include-path /usr/local/lib/node_modules/\n\nYour contract will compile (with the same exact metadata) no matter whether you install the library\nin the local or global package directory or even directly under your project root.\nBy default the base path is empty, which leaves the source unit name unchanged.\nWhen the source unit name is a relative path, this results in the file being looked up in the\ndirectory the compiler has been invoked from.\nIt is also the only value that results in absolute paths in source unit names being actually\ninterpreted as absolute paths on disk.\nIf the base path itself is relative, it is interpreted as relative to the current working directory\nof the compiler.\n\nNote\nInclude paths cannot have empty values and must be used together with a non-empty base path.\n\nNote\nInclude paths and base path can overlap as long as it does not make import resolution ambiguous.\nFor example, you can specify a directory inside base path as an include directory or have an\ninclude directory that is a subdirectory of another include directory.\nThe compiler will only issue an error if the source unit name passed to the Host Filesystem\nLoader represents an existing path when combined with multiple include paths or an include path\nand base path.\n\nCLI Path Normalization and Stripping\nOn the command-line the compiler behaves just as you would expect from any other program:\nit accepts paths in a format native to the platform and relative paths are relative to the current\nworking directory.\nThe source unit names assigned to files whose paths are specified on the command-line, however,\nshould not change just because the project is being compiled on a different platform or because the\ncompiler happens to have been invoked from a different directory.\nTo achieve this, paths to source files coming from the command-line must be converted to a canonical\nform, and, if possible, made relative to the base path or one of the include paths.\nThe normalization rules are as follows:\n\nIf a path is relative, it is made absolute by prepending the current working directory to it.\nInternal . and .. segments are collapsed.\nPlatform-specific path separators are replaced with forward slashes.\nSequences of multiple consecutive path separators are squashed into a single separator (unless\nthey are the leading slashes of an UNC path).\nIf the path includes a root name (e.g. a drive letter on Windows) and the root is the same as the\nroot of the current working directory, the root is replaced with /.\nSymbolic links in the path are not resolved.\n\nThe only exception is the path to the current working directory prepended to relative paths in\nthe process of making them absolute.\nOn some platforms the working directory is reported always with symbolic links resolved so for\nconsistency the compiler resolves them everywhere.\n\nThe original case of the path is preserved even if the filesystem is case-insensitive but\ncase-preserving and the actual case on\ndisk is different.\n\nNote\nThere are situations where paths cannot be made platform-independent.\nFor example on Windows the compiler can avoid using drive letters by referring to the root\ndirectory of the current drive as / but drive letters are still necessary for paths leading\nto other drives.\nYou can avoid such situations by ensuring that all the files are available within a single\ndirectory tree on the same drive.\n\nAfter normalization the compiler attempts to make the source file path relative.\nIt tries the base path first and then the include paths in the order they were given.\nIf the base path is empty or not specified, it is treated as if it was equal to the path to the\ncurrent working directory (with all symbolic links resolved).\nThe result is accepted only if the normalized directory path is the exact prefix of the normalized\nfile path.\nOtherwise the file path remains absolute.\nThis makes the conversion unambiguous and ensures that the relative path does not start with ../.\nThe resulting file path becomes the source unit name.\n\nNote\nThe relative path produced by stripping must remain unique within the base path and include paths.\nFor example the compiler will issue an error for the following command if both\n/project/contract.sol and /lib/contract.sol exist:\nsolc /project/contract.sol --base-path /project --include-path /lib\n\nNote\nPrior to version 0.8.8, CLI path stripping was not performed and the only normalization applied\nwas the conversion of path separators.\nWhen working with older versions of the compiler it is recommended to invoke the compiler from\nthe base path and to only use relative paths on the command-line.\n\nAllowed Paths\nAs a security measure, the Host Filesystem Loader will refuse to load files from outside of a few\nlocations that are considered safe by default:\n\nOutside of Standard JSON mode:\n\nThe directories containing input files listed on the command-line.\nThe directories used as remapping targets.\nIf the target is not a directory (i.e does not end with /, /. or /..) the directory\ncontaining the target is used instead.\nBase path and include paths.\n\nIn Standard JSON mode:\n\nBase path and include paths.\n\nAdditional directories can be whitelisted using the --allow-paths option.\nThe option accepts a comma-separated list of paths:\ncd /home/user/project/\nsolc token/contract.sol \\\n lib/util.sol=libs/util.sol \\\n --base-path=token/ \\\n --include-path=/lib/ \\\n --allow-paths=../utils/,/tmp/libraries\n\nWhen the compiler is invoked with the command shown above, the Host Filesystem Loader will allow\nimporting files from the following directories:\n\n/home/user/project/token/ (because token/ contains the input file and also because it is\nthe base path),\n/lib/ (because /lib/ is one of the include paths),\n/home/user/project/libs/ (because libs/ is a directory containing a remapping target),\n/home/user/utils/ (because of ../utils/ passed to --allow-paths),\n/tmp/libraries/ (because of /tmp/libraries passed to --allow-paths),\n\nNote\nThe working directory of the compiler is one of the paths allowed by default only if it\nhappens to be the base path (or the base path is not specified or has an empty value).\n\nNote\nThe compiler does not check if allowed paths actually exist and whether they are directories.\nNon-existent or empty paths are simply ignored.\nIf an allowed path matches a file rather than a directory, the file is considered whitelisted, too.\n\nNote\nAllowed paths are case-sensitive even if the filesystem is not.\nThe case must exactly match the one used in your imports.\nFor example --allow-paths tokens will not match import \"Tokens/IERC20.sol\".\n\nWarning\nFiles and directories only reachable through symbolic links from allowed directories are not\nautomatically whitelisted.\nFor example if token/contract.sol in the example above was actually a symlink pointing at\n/etc/passwd the compiler would refuse to load it unless /etc/ was one of the allowed\npaths too.\n\nImport Remapping\nImport remapping allows you to redirect imports to a different location in the virtual filesystem.\nThe mechanism works by changing the translation between import paths and source unit names.\nFor example you can set up a remapping so that any import from the virtual directory\ngithub.com/ethereum/dapp-bin/library/ would be seen as an import from dapp-bin/library/ instead.\nYou can limit the scope of a remapping by specifying a context.\nThis allows creating remappings that apply only to imports located in a specific library or a specific file.\nWithout a context a remapping is applied to every matching import in all the files in the virtual\nfilesystem.\nImport remappings have the form of context:prefix=target:\n\ncontext must match the beginning of the source unit name of the file containing the import.\nprefix must match the beginning of the source unit name resulting from the import.\ntarget is the value the prefix is replaced with.\n\nFor example, if you clone https://github.com/ethereum/dapp-bin/ locally to /project/dapp-bin\nand run the compiler with:\nsolc github.com/ethereum/dapp-bin/=dapp-bin/ --base-path /project source.sol\n\nyou can use the following in your source file:\nopen in Remix\nimport \"github.com/ethereum/dapp-bin/library/math.sol\"; // source unit name: dapp-bin/library/math.sol\n\nThe compiler will look for the file in the VFS under dapp-bin/library/math.sol.\nIf the file is not available there, the source unit name will be passed to the Host Filesystem\nLoader, which will then look in /project/dapp-bin/library/math.sol.\n\nWarning\nInformation about remappings is stored in contract metadata.\nSince the binary produced by the compiler has a hash of the metadata embedded in it, any\nmodification to the remappings will result in different bytecode.\nFor this reason you should be careful not to include any local information in remapping targets.\nFor example if your library is located in /home/user/packages/mymath/math.sol, a remapping\nlike @math/=/home/user/packages/mymath/ would result in your home directory being included in\nthe metadata.\nTo be able to reproduce the same bytecode with such a remapping on a different machine, you\nwould need to recreate parts of your local directory structure in the VFS and (if you rely on\nHost Filesystem Loader) also in the host filesystem.\nTo avoid having your local directory structure embedded in the metadata, it is recommended to\ndesignate the directories containing libraries as include paths instead.\nFor example, in the example above --include-path /home/user/packages/ would let you use\nimports starting with mymath/.\nUnlike remapping, the option on its own will not make mymath appear as @math but this\ncan be achieved by creating a symbolic link or renaming the package subdirectory.\n\nAs a more complex example, suppose you rely on a module that uses an old version of dapp-bin that\nyou checked out to /project/dapp-bin_old, then you can run:\nsolc module1:github.com/ethereum/dapp-bin/=dapp-bin/ \\\n module2:github.com/ethereum/dapp-bin/=dapp-bin_old/ \\\n --base-path /project \\\n source.sol\n\nThis means that all imports in module2 point to the old version but imports in module1\npoint to the new version.\nHere are the detailed rules governing the behavior of remappings:\n\nRemappings only affect the translation between import paths and source unit names.\nSource unit names added to the VFS in any other way cannot be remapped.\nFor example the paths you specify on the command-line and the ones in sources.urls in\nStandard JSON are not affected.\nsolc /project/=/contracts/ /project/contract.sol # source unit name: /project/contract.sol\n\nIn the example above the compiler will load the source code from /project/contract.sol and\nplace it under that exact source unit name in the VFS, not under /contract/contract.sol.\n\nContext and prefix must match source unit names, not import paths.\n\nThis means that you cannot remap ./ or ../ directly since they are replaced during\nthe translation to source unit name but you can remap the part of the name they are replaced\nwith:\nsolc ./=a/ /project/=b/ /project/contract.sol # source unit name: /project/contract.sol\n\n/project/contract.sol\nopen in Remix\nimport \"./util.sol\" as util; // source unit name: b/util.sol\n\nYou cannot remap base path or any other part of the path that is only added internally by an\nimport callback:\nsolc /project/=/contracts/ /project/contract.sol --base-path /project # source unit name: contract.sol\n\n/project/contract.sol\nopen in Remix\nimport \"util.sol\" as util; // source unit name: util.sol\n\nTarget is inserted directly into the source unit name and does not necessarily have to be a valid path.\n\nIt can be anything as long as the import callback can handle it.\nIn case of the Host Filesystem Loader this includes also relative paths.\nWhen using the JavaScript interface you can even use URLs and abstract identifiers if\nyour callback can handle them.\nRemapping happens after relative imports have already been resolved into source unit names.\nThis means that targets starting with ./ and ../ have no special meaning and are\nrelative to the base path rather than to the location of the source file.\nRemapping targets are not normalized so @root/=./a/b// will remap @root/contract.sol\nto ./a/b//contract.sol and not a/b/contract.sol.\nIf the target does not end with a slash, the compiler will not add one automatically:\nsolc /project/=/contracts /project/contract.sol # source unit name: /project/contract.sol\n\n/project/contract.sol\nopen in Remix\nimport \"/project/util.sol\" as util; // source unit name: /contractsutil.sol\n\nContext and prefix are patterns and matches must be exact.\n\na//b=c will not match a/b.\nsource unit names are not normalized so a/b=c will not match a//b either.\nParts of file and directory names can match as well.\n/newProject/con:/new=old will match /newProject/contract.sol and remap it to\noldProject/contract.sol.\n\nAt most one remapping is applied to a single import.\n\nIf multiple remappings match the same source unit name, the one with the longest matching context is chosen.\nIf contexts are identical, the one with the longest matching prefix is chosen.\nIf contexts and prefixes are identical, the one specified last wins.\nRemappings do not work on other remappings. For example a=b b=c c=d will not result in a\nbeing remapped to d.\n\nPrefix cannot be empty but context and target are optional.\n\nIf target is the empty string, prefix is simply removed from import paths.\nEmpty context means that the remapping applies to all imports in all source units.\n\nUsing URLs in imports\nMost URL prefixes such as https:// or data:// have no special meaning in import paths.\nThe only exception is file:// which is stripped from source unit names by the Host Filesystem\nLoader.\nWhen compiling locally you can use import remapping to replace the protocol and domain part with a\nlocal path:\nsolc :https://github.com/ethereum/dapp-bin=/usr/local/dapp-bin contract.sol\n\nNote the leading :, which is necessary when the remapping context is empty.\nOtherwise the https: part would be interpreted by the compiler as the context.","tokens":6392,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791263966879,"hash":"558cd02d11d2a5bdb68ac3e96c820e039c16f63d"}
{"url":"https://ethereum.org/developers/docs/blocks/","domain":"ethereum.org","title":"Blocks | ethereum.org","text":"BlocksEdit page (opens in a new tab)Blocks are batches of transactions with a hash of the previous block in the chain. This links blocks together (in a chain) because hashes are cryptographically derived from the block data. This prevents fraud, because one change in any block in history would invalidate all the following blocks as all subsequent hashes would change and everyone running the blockchain would notice.\nPrerequisites\nBlocks are a very beginner-friendly topic. But to help you better understand this page, we recommend you first read Accounts, Transactions, and our introduction to Ethereum.\nWhy blocks?\nTo ensure that all participants on the Ethereum network maintain a synchronized state and agree on the precise history of transactions, we batch transactions into blocks. This means dozens (or hundreds) of transactions are committed, agreed on, and synchronized all at once.\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nBy spacing out commits, we give all network participants enough time to come to consensus: even though transaction requests occur dozens of times per second, blocks are only created and committed on Ethereum once every twelve seconds.\nHow blocks work\nTo preserve the transaction history, blocks are strictly ordered (every new block created contains a reference to its parent block), and transactions within blocks are strictly ordered as well. Except in rare cases, at any given time, all participants on the network are in agreement on the exact number and history of blocks, and are working to batch the current live transaction requests into the next block.\nOnce a block is put together by a randomly selected validator on the network, it is propagated to the rest of the network; all nodes add this block to the end of their blockchain, and a new validator is selected to create the next block. The exact block-assembly process and commitment/consensus process is currently specified by Ethereum’s “proof-of-stake” protocol.\nProof-of-stake protocol\nProof-of-stake means the following:\n\nValidating nodes have to stake 32 ETH into a deposit contract as collateral against bad behavior. This helps protect the network because provably dishonest activity leads to some or all of that stake being destroyed.\nIn every slot (spaced twelve seconds apart) a validator is randomly selected to be the block proposer. They bundle transactions together, execute them and determine a new 'state'. They wrap this information into a block and pass it around to other validators.\nOther validators who hear about the new block re-execute the transactions to ensure they agree with the proposed change to the global state. Assuming the block is valid, they add it to their own database.\nIf a validator hears about two conflicting blocks for the same slot they use their fork-choice algorithm to pick the one supported by the most staked ETH.\n\nMore on proof-of-stake\nWhat's in a block?\nThere is a lot of information contained within a block. At the highest level a block contains the following fields:\nFieldDescriptionslotthe slot the block belongs toproposer_indexthe ID of the validator proposing the blockparent_rootthe hash of the preceding blockstate_rootthe root hash of the state objectbodyan object containing several fields, as defined below\nThe block body contains several fields of its own:\nFieldDescriptionrandao_reveala value used to select the next block proposereth1_datainformation about the deposit contractgraffitiarbitrary data used to tag blocksproposer_slashingslist of validators to be slashedattester_slashingslist of attesters to be slashedattestationslist of attestations made against previous slotsdepositslist of new deposits to the deposit contractvoluntary_exitslist of validators exiting the networksync_aggregatesubset of validators used to serve light clientsexecution_payloadtransactions passed from the execution client\nThe attestations field contains a list of all the attestations in the block. Attestations have their own data type that contains several pieces of data. Each attestation contains:\nFieldDescriptionaggregation_bitsa list of which validators participated in this attestationdataa container with multiple subfieldssignatureaggregate signature of a set of validators against data part\nThe data field in the attestation contains the following:\nFieldDescriptionslotthe slot the attestation relates toindexindices for attesting validatorsbeacon_block_rootthe root hash of the Beacon block seen as the head of the chainsourcethe last justified checkpointtargetthe latest epoch boundary block\nExecuting the transactions in the execution_payload updates the global state. All clients re-execute the transactions in the execution_payload to ensure the new state matches that in the new block state_root field. This is how clients can tell that a new block is valid and safe to add to their blockchain. The execution payload itself is an object with several fields. There is also an execution_payload_header that contains important summary information about the execution data. These data structures are organized as follows:\nThe execution_payload_header contains the following fields:\nFieldDescriptionparent_hashhash of the parent blockfee_recipientaccount address for paying transaction fees tostate_rootroot hash for the global state after applying changes in this blockreceipts_roothash of the transaction receipts trielogs_bloomdata structure containing event logsprev_randaovalue used in random validator selectionblock_numberthe number of the current blockgas_limitmaximum gas allowed in this blockgas_usedthe actual amount of gas used in this blocktimestampthe block timeextra_dataarbitrary additional data as raw bytesbase_fee_per_gasthe base fee valueblock_hashHash of execution blocktransactions_rootroot hash of the transactions in the payloadwithdrawal_rootroot hash of the withdrawals in the payload\nThe execution_payload itself contains the following (notice this is identical to the header except that instead of the root hash of the transactions it includes the actual list of transactions and withdrawal information) :\nFieldDescriptionparent_hashhash of the parent blockfee_recipientaccount address for paying transaction fees tostate_rootroot hash for the global state after applying changes in this blockreceipts_roothash of the transaction receipts trielogs_bloomdata structure containing event logsprev_randaovalue used in random validator selectionblock_numberthe number of the current blockgas_limitmaximum gas allowed in this blockgas_usedthe actual amount of gas used in this blocktimestampthe block timeextra_dataarbitrary additional data as raw bytesbase_fee_per_gasthe base fee valueblock_hashHash of execution blocktransactionslist of transactions to be executedwithdrawalslist of withdrawal objects\nThe withdrawals list contains withdrawal objects structured in the following way:\nFieldDescriptionaddressaccount address that has withdrawnamountwithdrawal amountindexwithdrawal index valuevalidatorIndexvalidator index value\nBlock time\nBlock time refers to the time separating blocks. In Ethereum, time is divided up into twelve second units called 'slots'. In each slot a single validator is selected to propose a block. Assuming all validators are online and fully functional there will be a block in every slot, meaning the block time is 12s. However, occasionally validators might be offline when called to propose a block, meaning slots can sometimes go empty.\nThis implementation differs from proof-of-work based systems where block times are probabilistic and tuned by the protocol's target mining difficulty. Ethereum's average block time (opens in a new tab) is a perfect example of this whereby the transition from proof-of-work to proof-of-stake can be clearly inferred based on the consistency of the new 12s block time.\nBlock size\nA final important note is that blocks themselves are bounded in size. Each block has a target size of 30 million gas but the size of blocks will increase or decrease in accordance with network demands, up until the block limit of 60 million gas (2x target block size). The block gas limit can be adjusted upwards or downwards by a factor of 1/1024 from the previous block's gas limit. As a result, validators can change the block gas limit through consensus. The total amount of gas expended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would gradually stop being able to keep up with the network due to space and speed requirements. The larger the block, the greater the computing power required to process them in time for the next slot. This is a centralizing force, which is resisted by capping block sizes.\nFurther reading\nKnow of a community resource that helped you? Edit this page and add it!\nRelated topics\n\nTransactions\nGas\nProof-of-stake\n\nTest your Ethereum knowledgeBlocksQuestion number 1:Why does Ethereum group transactions into blocks instead of committing each one on its own?","tokens":2282,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263967327,"hash":"58f062e5884552355161cc92f73ee55f07f49d0a"}
{"url":"https://dev-forum.pyth.network/t/we-occasionally-encounter-an-error-when-generating-the-payload-using-this-function-update-price-feeds-with-funder/142","domain":"dev-forum.pyth.network","title":"We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 1 / 3\n\n May 2025\n\n May 2025\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n On our end, we are updating the Pyth price every 30 seconds by calling the following function:\n0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\nHowever, we occasionally encounter an error when generating the payload:\nFailed to generate a Pyth price payload: TypeError: fetch failed\n at node:internal/deps/undici/undici:13502:13\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n at async HermesClient.httpRequest (C:\\kanalabs\\perpetual repos\\liquidation-bot\\node_modules\\@pythnetwork\\hermes-client\\lib\\HermesClient.js:29:30) {\n [cause]: Error: getaddrinfo ENOTFOUND hermes-beta.pyth.network \n at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:120:26) {\n errno: -3008,\n code: 'ENOTFOUND',\n syscall: 'getaddrinfo',\n hostname: 'hermes-beta.pyth.network'\n }\n}\n\nHere is the code we are using:\nexport const updatePythPricePayload = async (marketId: string) => {\n try {\n const priceIds = [MARKET_PRICE_FEEDS[marketId]];\n const connection = new HermesClient(process.env.PYTH_HERMES_ENDPOINT!, {});\n const priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n });\n const binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n );\n const payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n } as InputEntryFunctionData;\n return payloadResponse;\n } catch (error: any) {\n console.log(\"Failed to update Pyth price payload: \", error);\n rollbar.error(\"Failed to update Pyth price payload.\", error);\n }\n};\n\nWe’ve set PYTH_HERMES_ENDPOINT=https://hermes-beta.pyth.network and APT_PRICE_FEED_ID=0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e.\nCould anyone please help us understand and resolve this issue?\n\n 2\n\n post by ali on May 8, 2025\n\n ali\n\n How often do you face this error? This happens when our service experiences a downtime and it is expected as it’s a beta service but shouldn’t happen often.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n I think it comes three times continuously and then goes back to get the data again\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 579\n\n May 2025\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Powered by Discourse","tokens":1680,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791263969832,"hash":"392a4f7506798f8e81c4085b57e46e57b5865778"}
{"url":"https://ethereum.org/developers/docs/gas/","domain":"ethereum.org","title":"Ethereum gas and fees: technical overview | ethereum.org","text":"Gas and feesEdit page (opens in a new tab)Gas is essential to the Ethereum network. It is the fuel that allows it to operate, in the same way that a car needs gasoline to run.\nPrerequisites\nTo better understand this page, we recommend you first read up on transactions and the EVM.\nWhat is gas?\nGas refers to the unit that measures the amount of computational effort required to execute specific operations on the Ethereum network.\nSince each Ethereum transaction requires computational resources to execute, those resources have to be paid for to ensure Ethereum is not vulnerable to spam and cannot get stuck in infinite computational loops. Payment for computation is made in the form of a gas fee.\nThe gas fee is the amount of gas used to do some operation, multiplied by the cost per unit gas. The fee is paid regardless of whether a transaction succeeds or fails.\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nGas fees have to be paid in Ethereum's native currency, ether (ETH). Gas prices are usually quoted in gwei, which is a denomination of ETH. Each gwei is equal to one-billionth of an ETH (0.000000001 ETH or 10-9 ETH).\nFor example, instead of saying that your gas costs 0.000000001 ether, you can say your gas costs 1 gwei.\nThe word 'gwei' is a contraction of 'giga-wei', meaning 'billion wei'. One gwei is equal to one billion wei. Wei itself (named after Wei Dai (opens in a new tab), creator of b-money (opens in a new tab)) is the smallest unit of ETH.\nHow are gas fees calculated?\nYou can set the amount of gas you are willing to pay when you submit a transaction. By offering a certain amount of gas, you are bidding for your transaction to be included in the next block. If you offer too little, validators are less likely to choose your transaction for inclusion, meaning your transaction may execute late or not at all. If you offer too much, you might waste some ETH. So, how can you tell how much to pay?\nThe total gas you pay is divided into two components: the base fee and the priority fee (tip).\nThe base fee is set by the protocol—you have to pay at least this amount for your transaction to be considered valid. The priority fee is a tip that you add to the base fee to make your transaction attractive to validators so that they choose it for inclusion in the next block.\nA transaction that only pays the base fee is technically valid but unlikely to be included because it offers no incentive to the validators to choose it over any other transaction. The 'correct' priority fee is determined by the network usage at the time you send your transaction—if there is a lot of demand then you might have to set your priority fee higher, but when there is less demand you can pay less.\nFor example, let's say Jordan has to pay Taylor 1 ETH. An ETH transfer requires 21,000 units of gas, and the base fee is 10 gwei. Jordan includes a tip of 2 gwei.\nThe total fee would now be equal to:\nunits of gas used * (base fee + priority fee)\nwhere the base fee is a value set by the protocol and the priority fee is a value set by the user as a tip to the validator.\ne.g., 21,000 * (10 + 2) = 252,000 gwei (0.000252 ETH).\nWhen Jordan sends the money, 1.000252 ETH will be deducted from Jordan's account. Taylor will be credited 1.0000 ETH. The validator receives the tip of 0.000042 ETH. The base fee of 0.00021 ETH is burned.\nBase fee\nEvery block has a base fee which acts as a reserve price. To be eligible for inclusion in a block the offered price per gas must at least equal the base fee. The base fee is calculated independently of the current block and is instead determined by the blocks before it, making transaction fees more predictable for users. When the block is created this base fee is \"burned\", removing it from circulation.\nThe base fee is calculated by a formula that compares the size of the previous block (the amount of gas used for all the transactions) with the target size (half of the gas limit). The base fee will increase or decrease by a maximum of 12.5% per block if the target block size is above or below the target, respectively. This exponential growth makes it economically non-viable for block size to remain high indefinitely.\nBlock NumberIncluded GasFee IncreaseCurrent Base Fee118M0%100 gwei236M0%100 gwei336M12.5%112.5 gwei436M12.5%126.6 gwei536M12.5%142.4 gwei636M12.5%160.2 gwei736M12.5%180.2 gwei836M12.5%202.7 gwei\nIn the table above, an example is demonstrated using 36 million as the gas limit. Following this example, to create a transaction on block number 9, a wallet will let the user know with certainty that the maximum base fee to be added to the next block is current base fee * 112.5% or 202.7 gwei * 112.5% = 228.1 gwei.\nIt's also important to note it is unlikely we will see extended spikes of full blocks because of the speed at which the base fee increases preceding a full block.\nBlock NumberIncluded GasFee IncreaseCurrent Base Fee3036M12.5%2705.6 gwei......12.5%...5036M12.5%28531.3 gwei......12.5%...10036M12.5%10302608.6 gwei\nPriority fee (tips)\nThe priority fee (tip) incentivizes validators to maximize the number of transactions in a block, constrained only by the block gas limit. Without tips, a rational validator could include fewer—or even zero—transactions without any direct execution layer or consensus layer penalty, as staking rewards are independent of how many transactions are in a block. Additionally, tips allow users to outbid others for priority within the same block, effectively signalling urgency.\nMax fee\nTo execute a transaction on the network, users can specify a maximum limit they are willing to pay for their transaction to be executed. This optional parameter is known as the maxFeePerGas. For a transaction to be executed, the max fee must exceed the sum of the base fee and the tip. The transaction sender is refunded the difference between the max fee and the sum of the base fee and tip.\nBlock size\nEach block has a target size of half the current gas limit, but the size of blocks will increase or decrease in accordance with network demand, up until the block limit is reached (2x the target block size). The protocol achieves an equilibrium average block size at the target through the process of tâtonnement. This means if the block size is greater than the target block size, the protocol will increase the base fee for the following block. Similarly, the protocol will decrease the base fee if the block size is less than the target block size.\nThe amount by which the base fee is adjusted is proportional to how far the current block size is from the target. This is a linear calculation from -12.5% for an empty block, 0% at the target size, up to +12.5% for a block reaching the gas limit. The gas limit can fluctuate over time based on validator signalling, as well as via network upgrades. You can view the changes in gas limit over time here (opens in a new tab).\nMore on blocks\nCalculating gas fees in practice\nYou can explicitly state how much you are willing to pay to get your transaction executed. However, most wallet providers will automatically set a recommended transaction fee (base fee + recommended priority fee) to reduce the amount of complexity burdened onto their users.\nWhy do gas fees exist?\nIn short, gas fees help keep the Ethereum network secure. By requiring a fee for every computation executed on the network, we prevent bad actors from spamming the network. In order to avoid accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is \"gas\".\nAlthough a transaction includes a limit, any gas not used in a transaction is returned to the user (e.g., max fee - (base fee + tip) is returned).\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nWhat is the gas limit?\nThe gas limit refers to the maximum amount of gas you are willing to consume on a transaction. More complicated transactions involving smart contracts require more computational work, so they require a higher gas limit than a simple payment. A standard ETH transfer requires a gas limit of 21,000 units of gas.\nFor example, if you put a gas limit of 50,000 for a simple ETH transfer, the EVM would consume 21,000, and you would get back the remaining 29,000. However, if you specify too little gas, for example, a gas limit of 20,000 for a simple ETH transfer, the transaction will fail during the validation phase. It will be rejected before being included in a block, and no gas will be consumed. On the other hand, if a transaction runs out of gas during execution (e.g., a smart contract uses up all the gas halfway), the EVM will revert any changes, but all the gas provided will still be consumed for the work performed.\nWhy can gas fees get so high?\nHigh gas fees are due to the popularity of Ethereum. If there's too much demand, users must offer higher tip amounts to try and outbid other users' transactions. A higher tip can make it more likely that your transaction will get into the next block. Also, more complex smart contract apps might be doing lots of operations to support their functions, making them consume a lot of gas.\nInitiatives to reduce gas costs\nThe Ethereum scalability upgrades should ultimately address some of the gas fee issues, which will, in turn, enable the platform to process thousands of transactions per second and scale globally.\nLayer 2 scaling is a primary initiative to greatly improve gas costs, user experience and scalability.\nMore on layer 2 scaling\nMonitoring gas fees\nIf you want to monitor gas prices, so you can send your ETH for less, you can use many different tools such as:\n\nEtherscan (opens in a new tab) Transaction gas price estimator\nBlockscout (opens in a new tab) Open source transaction gas price estimator\nETH Gas Tracker (opens in a new tab) Monitor and track the Ethereum, and L2 gas prices to reduce transaction fees and save money\nBlocknative ETH Gas Estimator (opens in a new tab) Gas estimating Chrome extension supporting both Type 0 legacy transactions and Type 2 EIP-1559 transactions.\nCryptoneur Gas Fees Calculator (opens in a new tab) Calculate gas fees in your local currency for different transaction types on Mainnet, Arbitrum, and Polygon.\n\nRelated tools\n\nBlocknative's Gas Platform (opens in a new tab) Gas estimation API powered by Blocknative's global mempool data platform\nGas Network (opens in a new tab) Onchain Gas Oracles. Support for 35+ chains.\n\nFurther reading\n\nEthereum Gas Explained (opens in a new tab)\nReducing the gas consumption of your Smart Contracts (opens in a new tab)\nGas Optimization Strategies for Developers (opens in a new tab)\nEIP-1559 docs (opens in a new tab).\nTim Beiko's EIP-1559 Resources (opens in a new tab)\nEIP-1559: Separating Mechanisms From Memes (opens in a new tab)","tokens":2726,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263989208,"hash":"ef5558b4c6a9d0222a6c7bdf903019130f7acf80"}
{"url":"https://ethereum.org/developers/docs/transactions/","domain":"ethereum.org","title":"Transactions | ethereum.org","text":"TransactionsEdit page (opens in a new tab)Transactions are cryptographically signed instructions from accounts. An account will initiate a transaction to update the state of the Ethereum network. The simplest transaction is transferring ETH from one account to another.\nPrerequisites\nTo help you better understand this page, we recommend you first read Accounts and our introduction to Ethereum.\nWhat's a transaction?\nAn Ethereum transaction refers to an action initiated by an externally-owned account, in other words an account managed by a human, not a contract. For example, if Bob sends Alice 1 ETH, Bob's account must be debited and Alice's must be credited. This state-changing action takes place within a transaction.\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nTransactions, which change the state of the EVM, need to be broadcast to the whole network. Any node can broadcast a request for a transaction to be executed on the EVM; after this happens, a validator will execute the transaction and propagate the resulting state change to the rest of the network.\nTransactions require a fee and must be included in a validated block. To make this overview simpler we'll cover gas fees and validation elsewhere.\nA submitted transaction includes the following information:\n\nfrom – the address of the sender, that will be signing the transaction. This will be an externally-owned account as contract accounts cannot send transactions\nto – the receiving address (if an externally-owned account, the transaction will transfer value. If a contract account, the transaction will execute the contract code)\nsignature – the identifier of the sender. This is generated when the sender's private key signs the transaction and confirms the sender has authorized this transaction\nnonce - a sequentially incrementing counter which indicates the transaction number from the account\nvalue – amount of ETH to transfer from sender to recipient (denominated in WEI, where 1ETH equals 1e+18wei)\ninput data – optional field to include arbitrary data\ngasLimit – the maximum amount of gas units that can be consumed by the transaction. The EVM specifies the units of gas required by each computational step\nmaxPriorityFeePerGas - the maximum price of the consumed gas to be included as a tip to the validator\nmaxFeePerGas - the maximum fee per unit of gas willing to be paid for the transaction (inclusive of baseFeePerGas and maxPriorityFeePerGas)\n\nGas is a reference to the computation required to process the transaction by a validator. Users have to pay a fee for this computation. The gasLimit, and maxPriorityFeePerGas determine the maximum transaction fee paid to the validator. More on Gas.\nThe transaction object will look a little like this:\n{\n from: \"0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8\",\n to: \"0xac03bb73b6a9e108530aff4df5077c2b3d481e5a\",\n gasLimit: \"21000\",\n maxFeePerGas: \"300\",\n maxPriorityFeePerGas: \"10\",\n nonce: \"0\",\n value: \"10000000000\"\n}\n\nBut a transaction object needs to be signed using the sender's private key. This proves that the transaction could only have come from the sender and was not sent fraudulently.\nAn Ethereum client like Geth will handle this signing process.\nExample JSON-RPC call:\n{\n \"id\": 2,\n \"jsonrpc\": \"2.0\",\n \"method\": \"account_signTransaction\",\n \"params\": [\n {\n \"from\": \"0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db\",\n \"gas\": \"0x55555\",\n \"maxFeePerGas\": \"0x1234\",\n \"maxPriorityFeePerGas\": \"0x1234\",\n \"input\": \"0xabcd\",\n \"nonce\": \"0x0\",\n \"to\": \"0x07a565b7ed7d7a678680a4c162885bedbb695fe0\",\n \"value\": \"0x1234\"\n }\n ]\n}\n\nExample response:\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 2,\n \"result\": {\n \"raw\": \"0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663\",\n \"tx\": {\n \"nonce\": \"0x0\",\n \"maxFeePerGas\": \"0x1234\",\n \"maxPriorityFeePerGas\": \"0x1234\",\n \"gas\": \"0x55555\",\n \"to\": \"0x07a565b7ed7d7a678680a4c162885bedbb695fe0\",\n \"value\": \"0x1234\",\n \"input\": \"0xabcd\",\n \"v\": \"0x26\",\n \"r\": \"0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e\",\n \"s\": \"0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663\",\n \"hash\": \"0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e\"\n }\n }\n}\n\nthe raw is the signed transaction in Recursive Length Prefix (RLP) encoded form\nthe tx is the signed transaction in JSON form\n\nWith the signature hash, the transaction can be cryptographically proven that it came from the sender and submitted to the network.\nThe data field\nThe vast majority of transactions access a contract from an externally-owned account.\nMost contracts are written in Solidity and interpret their data field in accordance with the .\nThe first four bytes specify which function to call, using the hash of the function's name and arguments.\nYou can sometimes identify the function from the selector using this database (opens in a new tab).\nThe rest of the calldata is the arguments, encoded as specified in the ABI specs (opens in a new tab).\nFor example, lets look at this transaction (opens in a new tab).\nUse Click to see More to see the calldata.\nThe function selector is 0xa9059cbb. There are several known functions with this signature (opens in a new tab).\nIn this case the contract source code (opens in a new tab) has been uploaded to Etherscan, so we know the function is transfer(address,uint256).\nThe rest of the data is:\n0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279\n000000000000000000000000000000000000000000000000000000003b0559f4\n\nAccording to the ABI specifications, integer values (such as addresses, which are 20-byte integers) appear in the ABI as 32-byte words, padded with zeros in the front.\nSo we know that the to address is 4f6742badb049791cd9a37ea913f2bac38d01279 (opens in a new tab).\nThe value is 0x3b0559f4 = 990206452.\nTransaction descriptors\nBecause the data field contains opaque hexadecimal bytes, it can be extremely difficult to verify what action a transaction will actually perform. This \"blind signing\" vulnerability is addressed by Clear Signing (opens in a new tab) through the use of transaction descriptors (opens in a new tab) (defined by ERC-7730).\nThe ERC-7730 specification uses transaction descriptors (often structured as JSON files) to enrich the data found in ABIs and structured messages, like EVM transaction calldata, EIP-712 messages, and EIP-4337 User Operations. Developers use these descriptors to map specific transaction variables directly into formatting templates, ensuring the underlying data remains machine-readable for applications.\nOn the frontend, wallets use this formatting context to translate opaque bytecode into clear, human-readable information. By automatically resolving values like token addresses into recognized tickers, or amounts into decimals, users are presented with a plain-language summary of the transaction's exact intent (e.g., 'Swap 1000 USDC for at least 0.25 WETH') before they sign\nTypes of transactions\nOn Ethereum there are a few different types of transactions:\n\nRegular transactions: a transaction from one account to another.\nContract deployment transactions: a transaction without a 'to' address, where the data field is used for the contract code.\nExecution of a contract: a transaction that interacts with a deployed smart contract. In this case, 'to' address is the smart contract address.\n\nOn gas\nAs mentioned, transactions cost gas to execute. Simple transfer transactions require 21000 units of Gas.\nSo for Bob to send Alice 1 ETH at a baseFeePerGas of 190 gwei and maxPriorityFeePerGas of 10 gwei, Bob will need to pay the following fee:\n(190 + 10) * 21000 = 4,200,000 gwei\n--or--\n0.0042 ETH\n\nBob's account will be debited -1.0042 ETH (1 ETH for Alice + 0.0042 ETH in gas fees)\nAlice's account will be credited +1.0 ETH\nThe base fee will be burned -0.00399 ETH\nValidator keeps the tip +0.000210 ETH\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nAny gas not used in a transaction is refunded to the user account.\nSmart contract interactions\nGas is required for any transaction that involves a smart contract.\nSmart contracts can also contain functions known as view (opens in a new tab) or pure (opens in a new tab) functions, which do not alter the state of the contract. As such, calling these functions from an EOA will not require any gas. The underlying RPC call for this scenario is eth_call.\nUnlike when accessed using eth_call, these view or pure functions are also commonly called internally (i.e., from the contract itself or from another contract) which does cost gas.\nTransaction lifecycle\nOnce the transaction has been submitted the following happens:\n\nA transaction hash is cryptographically generated:\n0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017\nThe transaction is then broadcasted to the network and added to a transaction pool consisting of all other pending network transactions.\nA validator must pick your transaction and include it in a block in order to verify the transaction and consider it \"successful\".\nAs time passes the block containing your transaction will be upgraded to \"justified\" then \"finalized\". These upgrades make it much\nmore certain that your transaction was successful and will never be altered. Once a block is \"finalized\" it could only ever be changed\nby a network level attack that would cost many billions of dollars.\n\nA visual demo\nWatch Austin walk you through transactions, gas, and mining.\nTransactions — ETH.BUILDA demonstration of how Ethereum transactions work using the ETH.BUILD educational tool.Watch with transcript \nTyped Transaction Envelope\nEthereum originally had one format for transactions. Each transaction contained a nonce, gas price, gas limit, to address, value, data, v, r, and s. These fields are RLP-encoded, to look something like this:\nRLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])\nEthereum has evolved to support multiple types of transactions to allow for new features such as access lists and EIP-1559 (opens in a new tab) to be implemented without affecting legacy transaction formats.\nEIP-2718 (opens in a new tab) is what allows for this behavior. Transactions are interpreted as:\nTransactionType || TransactionPayload\nWhere the fields are defined as:\n\nTransactionType - a number between 0 and 0x7f, for a total of 128 possible transaction types.\nTransactionPayload - an arbitrary byte array defined by the transaction type.\n\nBased on the TransactionType value, a transaction can be classified as:\n\nType 0 (Legacy) Transactions: The original transaction format used since Ethereum's launch. They do not include features from EIP-1559 (opens in a new tab) such as dynamic gas fee calculations or access lists for smart contracts. Legacy transactions lack a specific prefix indicating their type in their serialized form, starting with the byte 0xf8 when using Recursive Length Prefix (RLP) encoding. The TransactionType value for these transactions is 0x0.\n\nType 1 Transactions: Introduced in EIP-2930 (opens in a new tab) as part of Ethereum's Berlin Upgrade, these transactions include an accessList parameter. This list specifies addresses and storage keys the transaction expects to access, helping to potentially reduce gas costs for complex transactions involving smart contracts. EIP-1559 fee market changes are not included in Type 1 transactions. Type 1 transactions also include a yParity parameter, which can either be 0x0 or 0x1, indicating the parity of the y-value of the secp256k1 signature. They are identified by starting with the byte 0x01, and their TransactionType value is 0x1.\n\nType 2 Transactions, commonly referred to as EIP-1559 transactions, are transactions introduced in EIP-1559 (opens in a new tab), in Ethereum's London Upgrade. They have become the standard transaction type on the Ethereum network. These transactions introduce a new fee market mechanism that improves predictability by separating the transaction fee into a base fee and a priority fee. They start with the byte 0x02 and include fields such as maxPriorityFeePerGas and maxFeePerGas. Type 2 transactions are now the default due to their flexibility and efficiency, especially favored during periods of high network congestion for their ability to help users manage transaction fees more predictably. The TransactionType value for these transactions is 0x2.\n\nType 3 (Blob) Transactions were introduced in EIP-4844 (opens in a new tab) as part of Ethereum's Dencun Upgrade. These transactions are designed to handle \"blob\" data (Binary Large Objects) more efficiently, particularly benefiting Layer 2 rollups by providing a way to post data to the Ethereum network at a lower cost. Blob transactions include additional fields such as blobVersionedHashes, maxFeePerBlobGas, and blobGasPrice. They start with the byte 0x03, and their TransactionType value is 0x3. Blob transactions represent a significant improvement in Ethereum's data availability and scaling capabilities.\n\nType 4 Transactions were introduced in EIP-7702 (opens in a new tab) as part of Ethereum’s Pectra Upgrade. These transactions are designed to be forward-compatible with account abstraction. They allow EOAs to temporarily behave like smart contract accounts without compromising their original functionality. They include an authorization_list parameter, which specifies the smart contract to which the EOA delegates its authority. After the transaction, the EOA’s code field will have the address of the delegated smart contract.\n\nFurther reading\n\nEIP-2718: Typed Transaction Envelope (opens in a new tab)\n\nKnow of a community resource that helped you? Edit this page and add it!\nRelated topics\n\nAccounts\nEthereum virtual machine (EVM)\nGas\n\nTest your Ethereum knowledgeTransactionsQuestion number 1:A transaction is sent with no recipient address. What is it doing?","tokens":3497,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791263999073,"hash":"58cfa58aa1b5e2d73f0e00591ef00790a30032b3"}
{"url":"https://governance.aave.com/t/temp-check-activating-dao-owned-aave-for-governance-sovereignty/23972","domain":"governance.aave.com","title":"[TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty - Governance - Aave","text":"[TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Simple Summary\n\n Abstract\n\n Motivation\n\n Specification\n\n Proposer’s Note (ApuMallku)\n\n Next Steps\n\n Jan 31\n\n 1 / 13\n\n Feb 1\n\n Feb 3\n\n post by ApuMallku on Jan 31\n\n ApuMallku\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\nAuthor: ApuMallku\nDate: 2026-01-31\nSimple Summary\nThis proposal seeks to authorize the use of $AAVE tokens held within the Aave Collector (Treasury) to participate in governance votes. This mechanism is essential to counteract the centralization of power exposed in recent votes and to ensure that the DAO’s future is decided by its broader community and Service Providers, rather than being dictated by Aave Labs’ private interests.\nAbstract\nThe recent [ARFC] Aave Token Alignment Phase 1 vote served as a definitive exposure of the “centralization trap” within Aave. Despite significant support from independent holders and several Service Providers for a transition of ownership, Aave Labs utilized its concentrated voting power to force a “NAY” outcome, effectively silencing the majority of stakeholders.\nTo break this hegemony, the DAO must activate its own $AAVE (refer to TokenLogic’s tracker). This is no longer just a debate about branding; it is about reclaiming the protocol from a private monopoly that is currently stifling innovation and destroying market value.\nMotivation\n\nThe Failure of Centralized Governance: The recent Phase 1 vote proved that under the current status quo, the community’s will is irrelevant if it conflicts with Aave Labs’ private control. This centralization is no longer a “risk”—it is a documented reality.\nThe BGD Wake-Up Call: The recent post by Ernesto from BGD Labs regarding “Project E” is the final proof of the damage caused by this centralization. When our most elite technical SPs abandon projects because they cannot compete in a “fair game” against Labs’ gatekeeping of the brand and IP, the ecosystem is officially in a death spiral.\nMarket Destruction & Gaslighting: Since this drama began, the $AAVE token has lost over 35% of its value, dropping out of the Top 50. Instead of taking responsibility, Labs has resorted to using employees to gaslight the community on social media.\nA Fair Building Framework: Aave must be a neutral platform. Core assets (aave.com, trademarks, IP) must be owned by the DAO. This proposal ensures that the DAO has the “voting fire-power” to enforce this transition and protect itself from predatory practices.\n\nSpecification\n\nGovernance Activation: Implement the technical mechanism to allow $AAVE tokens in the Collector to be delegated or used in governance.\nConsensus Alignment: The Collector’s voting power will be utilized to support the majority consensus of non-Labs-affiliated Service Providers and independent delegates.\nMandatory IP & Neutrality Mandate: This voting weight will be prioritized to push through the legal transfer of all IP to the DAO, ensuring a level playing field for all developers (including BGD, Labs, and any third party).\n\nProposer’s Note (ApuMallku)\nFor years, we were told Aave was a DAO. The Phase 1 vote and the BGD “Project E” situation have proven otherwise: it is a private company with a community-funded treasury. We are tired of the ambiguity, the delays, and the professional arrogance of those who claim to be “owners” while wiping out 35% of our market cap.\nIf Labs chooses to vote NAY on this proposal, they will be confirming their intent to keep the DAO’s resources hostage. It is time for a reality check: the DAO is the protocol.\nNext Steps\n\nPoll: Should the DAO activate its treasury-held $AAVE to restore balance and defend against centralized capture?\nTechnical Implementation: Define delegation parameters for the Collector’s $AAVE.\nSnapshot Vote.\n\n When can we expect an Aave Labs response?\n\n 5\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by Gross on Feb 1\n\n post by EzR3aL on Feb 1\n\n post by ApuMallku on Feb 1\n\n post by Sye54 on Feb 1\n\n post by ApuMallku on Feb 1\n\n post by Emereb on Feb 2\n\n post by Gross on Feb 2\n\n post by ApuMallku on Feb 2\n\n post by ApuMallku on Feb 3\n\n post by EzR3aL on Feb 3\n\n Closed on Feb 3\n\n post by MarcZeller on Feb 3\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [TEMP CHECK] Aave Will Win Framework\n\n General\n\n 135\n\n 18.0k\n\n 7d\n\n How AAVE will win\n\n Governance\n\n 72\n\n 10.5k\n\n Feb 11\n\n [ARFC ADDENDUM] Mandatory Disclosures and Conflict-of-Interest Voting Norms\n\n General\n\n 43\n\n 3.5k\n\n Feb 13\n\n [ARFC] Aave Will Win Framework\n\n Governance\n\n 23\n\n 3.5k\n\n Apr 16\n\n [ARFC] $AAVE token alignment. Phase 1 - Ownership\n\n Governance\n\n 190\n\n 23.2k\n\n Jan 11","tokens":1215,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264004178,"hash":"3dd5e099bd309fb22ad8d922103de51555a04ece"}
{"url":"https://ethereum.org/developers/docs/intro-to-ether/","domain":"ethereum.org","title":"Technical intro to ether | ethereum.org","text":"Technical intro to etherEdit page (opens in a new tab)Prerequisites\nTo help you better understand this page, we recommend you first read Introduction to Ethereum.\nWhat is a cryptocurrency?\nA cryptocurrency is a medium of exchange secured by a blockchain-based ledger.\nA medium of exchange is anything widely accepted as payment for goods and services, and a ledger is a data store that keeps track of transactions. Blockchain technology allows users to make transactions on the ledger without reliance upon a trusted third party to maintain the ledger.\nThe first cryptocurrency was Bitcoin, created by Satoshi Nakamoto. Since Bitcoin's release in 2009, people have made thousands of cryptocurrencies across many different blockchains.\nWhat is ether?\nEther (ETH) is the cryptocurrency used for many things on the Ethereum network. Fundamentally, it is the only acceptable form of payment for transaction fees, and after The Merge, ether is required to validate and propose blocks on Mainnet. Ether is also used as a primary form of collateral in the DeFi lending markets, as a unit of account in NFT marketplaces, as payment earned for performing services or selling real-world goods, and more.\nEthereum allows developers to create decentralized applications (dapps), which all share a pool of computing power. This shared pool is finite, so Ethereum needs a mechanism to determine who gets to use it. Otherwise, a dapp could accidentally or maliciously consume all network resources, which would block others from accessing it.\nThe ether cryptocurrency supports a pricing mechanism for Ethereum's computing power. When users want to make a transaction, they must pay ether to have their transaction recognized on the blockchain. These usage costs are known as gas fees, and the gas fee depends on the amount of computing power required to execute the transaction and the network-wide demand for computing power at the time.\nTherefore, even if a malicious dapp submitted an infinite loop, the transaction would eventually run out of ether and terminate, allowing the network to return to normal.\nIt is common to conflate (opens in a new tab) Ethereum and ether — when people reference the \"price of Ethereum,\" they are describing the price of ether.\nMinting ether\nMinting is the process in which new ether gets created on the Ethereum ledger. The underlying Ethereum protocol creates the new ether, and it is not possible for a user to create ether.\nEther is minted as a reward for each block proposed and at every epoch checkpoint for other validator activity related to reaching consensus. The total amount issued depends on the number of validators and how much ether they have staked. This total issuance is divided equally among validators in the ideal case that all validators are honest and online, but in reality, it varies based on validator performance. About 1/8 of the total issuance goes to the block proposer; the remainder is distributed across the other validators. Block proposers also receive tips from transaction fees and MEV-related income, but these come from recycled ether, not new issuance.\nBurning ether\nAs well as creating ether through block rewards, ether can be destroyed through a process called 'burning'. When ether gets burned, it gets removed from circulation permanently.\nEther burn occurs in every transaction on Ethereum. When users pay for their transactions, a base gas fee, set by the network according to transactional demand, gets destroyed. This, coupled with variable block sizes and a maximum gas fee, simplifies transaction fee estimation on Ethereum. When network demand is high, blocks (opens in a new tab) can burn more ether than they mint, effectively offsetting ether issuance.\nBurning the base fee hinders a block producer's ability to manipulate transactions. For example, if block producers received the base fee, they could include their own transactions for free and raise the base fee for everyone else. Alternatively, they could refund the base fee to some users offchain, leading to a more opaque and complex transaction fee market.\nDenominations of ether\nSince the value of many transactions on Ethereum are small, ether has several denominations which may be referenced as smaller units of account. Of these denominations, Wei and gwei are particularly important.\nWei is the smallest possible amount of ether, and as a result, many technical implementations, such as the Ethereum Yellowpaper (opens in a new tab), will base all calculations in Wei.\nGwei, short for giga-wei, is often used to describe gas costs on Ethereum.\nDenominationValue in etherCommon UsageWei10-18Technical implementationsGwei10-9Human-readable gas fees\nTransferring ether\nEach transaction on Ethereum contains a value field, which specifies the amount of ether to be transferred, denominated in wei, to send from the sender's address to the recipient address.\nWhen the recipient address is a smart contract, this transferred ether may be used to pay for gas when the smart contract executes its code.\nMore on transactions\nQuerying ether\nUsers can query the ether balance of any account by inspecting the account's balance field, which shows ether holdings denominated in wei.\nEtherscan (opens in a new tab) and Blockscout (opens in a new tab) are popular tools to inspect address balances via web-based applications. For example, this Blockscout page (opens in a new tab) shows the balance for the Ethereum Foundation. Account balances can also be queried using wallets or directly by making requests to nodes.\nFurther reading\n\nDefining ether and Ethereum (opens in a new tab) – CME Group\nEthereum Whitepaper: The original proposal for Ethereum. This document includes a description of ether and the motivations behind its creation.\nGwei Calculator (opens in a new tab): Use this gwei calculator to easily convert wei, gwei, and ether. Simply plug in any amount of wei, gwei, or ETH and automatically calculate the conversion.\n\nKnow of a community resource that helped you? Edit this page and add it!","tokens":1509,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264009238,"hash":"43d125ccf8ed3852310e5dccf714e58c80c31522"}
{"url":"https://governance.aave.com/t/arfc-aave-token-alignment-phase-1-ownership/23616","domain":"governance.aave.com","title":"[ARFC] $AAVE token alignment. Phase 1 - Ownership - Governance - Aave","text":"[ARFC] $AAVE token alignment. Phase 1 - Ownership \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Title: [ARFC] $AAVE token alignment. Phase 1 - Ownership\nAuthor: Ernesto Boado (co-founder @bgdlabs)\nDate: 2025-12-16\n\n Summary\n\n Motivation\n\n Additional context & principles\n\n What this is NOT about?\n\n Specification\n\n Disclaimers\n\n Copyright\n\n Links\n\n Next steps\n\n Dec 2025\n\n 1 / 192\n\n Dec 2025\n\n Jan 11\n\n post by eboado on Dec 16, 2025\n\n eboado\n\n Regular\n\nTitle: [ARFC] $AAVE token alignment. Phase 1 - Ownership\nAuthor: Ernesto Boado (co-founder @bgdlabs)\nDate: 2025-12-16\n\nSummary\nThis is an Aave Governance proposal for AAVE token holders to request receiving control of Aave’s brand assets (domains, social handles, naming rights, etc), on a DAO-controlled vehicle (defined at a later stage) with strong anti-capture protections.\nHence, asking for any party controlling them at the moment to deliver them both in ethos and in practice, no matter who that party is.\n\nMotivation\nAave’s origins and long-term direction have consistently been framed around decentralization: a project initially funded via a decentralized mechanism (ICO), to be owned and governed by token holders through a real DAO, ideally self-sustainable, with both value and accountability expected to be inherent to the Aave DAO itself.\nFor years, the community has operated under the implicit expectation of alignment between contributors (e.g. Service Providers) and the DAO. In practice, for example, Aave Labs has been implicitly considered as a good-faith steward of communications channels, or important gateways such as aave.com on behalf of the broader ecosystem. Or BGD Labs, has been acting as implicit steward of others like the aave-dao Github organisation, where multiple contributors maintain different repositories.\nBut that implicit understanding, no matter who the third-party is, is not a healthy or beneficial for $AAVE long-term, as the fact of making the delegation stewardship explicit, is un-doubtfully only positive to $AAVE. Moreover, recent events have raised concerns on other community members in these forum, that these brand assets are being used to enable private monetisation and to support products the DAO has no practical say on, and is not the main value-recipient.\nThis proposal is therefore intended to bring explicit clarity and DAO control to how Aave-branded assets and intellectual property are, first, owned, and second, can be used, and the terms for it.\n\nAdditional context & principles\nThe following is a list of facts, and I would say pretty reasonable opinions, on the legitimacy of this proposal:\n\nIn relation to the usage of aave.com, subdomains, communication and marketing channels, or other online representation aspects (Github, package managers, etc) by any non-DAO third-party, whether for private monetisation purposes or not: a private party, regardless of its past or present role in the community, should not have unilateral ownership and control over them. Consequently, the DAO should request those parties via governance vote to deliver to AAVE token holders those assets; more precisely to any necessary legal setup or SPV, with strong protections.\n\nIn what regards app.aave.com, the claim by Aave Labs that the software application hosted on app.aave.com is their product is, potentially legitimate. And similar to any private software, it is up to the private party to dispose of it as desired. However, ownership and control of the software have no relation to ownership and control of app.aave.com. By any neutral analysis, the ability of a third-party to engage in monetisation of the software is enabled by brand recognition and by the gateway effect of aave.com, including its role as a primary entry point to app.aave.com.\n\nPrivate entities clearly separated from the DAO should not be allowed to unilaterally attribute to themselves, implicitly or explicitly, the name “Aave” or the status of “being Aave”. With a plural organisation like the DAO and the lack of a direct mechanism of self-representation, another entity doing so outside a service agreement or other model (e.g., franchising) weakens the DAO’s ability to control its own representation. It also creates a principal-agent scenario where the agent can decide, at any point, to prioritise its private interests over those of the DAO. These applies for any entity to have a important role in the community, for example Service Providers.\n\nNot having a resolution on this issue is an existential threat to the DAO model, including but not limited to the involvement of all Service Providers. All service providers are independent third parties who have created, or are actively trying to create, sustainable businesses while contributing to the Aave DAO and being compensated on equal conditions based on merit.\n\nExample: my company, BGD Labs, was created in 2022 and has been contributing to Aave since then, being a major development contributor during that period. But that did not give us any legitimacy to be called “Aave”, or to promote ourselves as “Aave”. We are an important contributor to the Aave DAO, we are generously compensated, and that’s it.\n\nIf a single party can control soft assets like brand, marketing channels, gateways, and “Aave” attribution, all other contributors become de facto subordinated to that party. This undermines neutral incentives to contribute to a common good, namely the DAO and $AAVE.\n\nThe Aave DAO does not need hand-holding. It is a system that requires continuous improvements, simplifications, and changes. But I don’t believe it requires anymore any implicit agreement with a third party that the third party itself argues is required “for Aave” or “for everybody”. Those decisions are not for any third party to make.\n\nCompared with many other tokens and DAOs, there is a strong argument that, in substance, AAVE token holders should have control and ownership over the Aave name (e.g., trademark), gateways, and communication channels.\nTo claim that the brand itself does not belong, in substance, to AAVE token holders, given those circumstances, is, in my opinion, dubious both from a practical and high-level perspective.\n\nWhat this is NOT about?\nOther threads and comments are, in some cases, highly adversarial against specifically Aave Labs due to precedents. But this proposal tries to be neutral, defending what I really think are the legitimate interests of a healthy Aave ecosystem, and doesn’t apply exclusively to Aave Labs, but for any other entity, including the one I’m part of, BGD Labs.\nSo the following is important to keep in mind:\n\nThis is not a discussion or governance procedure suggesting that Aave Labs should not be a contributor to the DAO, or that it lacks legitimacy or capability to do so. Those are totally independent topics, and the contribution of Aave Labs is completely legitimate in my opinion, but even if applicable:\n\nThey do not remove constraints associated with the role of contributor, and\nthey are decisions for the DAO to make, as it has always been done with compensation agreements or others.\n\nThis is not a discussion exclusively about the previous swap features thread. That is in my opinion merely a realised instance of the high-level problem: any party being able to have control over from “Aave” attribution, gateway control, or marketing.\n\nThis is not a discussion about potential legal blockers of creating an entity (foundation, SPV, etc.) that allows the DAO to exercise ownership and control rights over domains or communication channels.\nThose are practical aspects that must be addressed, but they do not change the core question of AAVE token holders signalling a mandate to deliver control and ownership.\n\nThis is not incompatible with Aave Labs, in the future, being a candidate to manage gateways or communication channels in practice. That is one option among others, but it is secondary to ownership and control of those assets, and self-protection if the task is delegated.\n\nSpecification\nThe proposal to vote is simple: should the Aave DAO and AAVE token holders regain full control over Aave’s brand, naming rights, and associated assets? With any third party currently controlling these assets (Aave Labs, BGD Labs, anybody), transferring them to the DAO via an appropriate DAO-controlled legal wrapper\nThese “assets”/rights include but are not limited to:\n\nThe DAO deciding on “Aave” naming rights for products and organisations, not any third parties.\n\nExamples: Usage of “Aave Labs”, “Aave App”, “Aave Web App”, “Aave Pro” or “Aave Horizon”.\nThis also includes representational titles, such as using executive titles of Aave (e.g., “CEO of Aave”) without proper clarification of separation.\n\nThe DAO having ownership and control over all communication channels using “Aave” or implicitly associated names. This includes but is not limited to the “aave” handle on X, the Aave Discord, “aave” on Instagram, and any other social or public channel.\nThe DAO having control and ownership over domains, including but not limited to aave.com, and any others with direct association (e.g., onaave.com).\nThe DAO having ownership over online organisations, including but not limited to GitHub or npm. Example, “aave” and “aave-dao” Github organisations, “aave” npm, etc.\n\nAdditionally, this proposal approves the intention to establish strict mechanisms so that no third party can misuse these assets or privately benefit from them, implicitly or explicitly, with legally enforceable recourse by the DAO if such a situation arises.\nAnd to seek legal advice if any of the counterparties don’t facilitate the process of ownership transfer.\nThis practical setup should be implemented by a provably neutral third party, independent from all Aave Service Providers, and legally accountable to AAVE token holders’ interests.\n\nAdditional aspects\n\nFor obvious reasons, I believe entities with direct conflicts of interest should not participate or vote Abstain on the voting phase. However, voting on Aave is (and should always be) permissionless, so anybody can obviously do as they think, rightfully so.\nThis proposal doesn’t include any executable programmatic payload, so either a single Snapshot or on-chain voting is perfectly enough. I propose an on-chain vote with empty payload, as there is no cost of voting anymore on the current governance on-chain system, hence maximising participation.\n\nDisclaimers\n\nI’m not presenting this proposal on behalf of anybody.\nI’m an AAVE token holder.\nI was part of the original Aave Labs, but totally independent after 2022.\nI’m an active contributor to the DAO via BGD Labs, on technical and security aspects. Also a partial owner.\nAll information I reference is totally public.\nMy company BGD Labs has been collaborating with Aave Labs in the past years as Service Provider to Service Provider, and I have no issue continuing to do so if applicable in DAO projects. I deeply believe that multi-party providers to the DAO is a model that has future, but under equal terms for everybody.\nI think it is my implicit responsibility as token holder to try to improve aspects I believe deserve so.\nI think without the DAO having full and exclusive control of all its assets, there is no future for the idea of a decentralised autonomous organisation where multiple parties contribute based on merit.\n\nCopyright\nCopyright and related rights waived under CC0.\n\nLinks\n\nSwap features questions from @ezr3al Aave Cowswap Integration- Tokenholder Questions\nOther proposals created these days around the topic (with which I only agree, in some cases, partially, or totally disagree).\n\nhttps://governance.aave.com/t/aave-improvement-proposal-aip-the-poison-pill/23609/\nAave DAO should own its own IP\n\nNext steps\n\nCollect community feedback in this forum thread.\nEscalate to vote.\n\n Aave Cowswap Integration- Tokenholder Questions\n\n [TEMP CHECK] Activating DAO-Owned $AAVE for Governance Sovereignty\n\n Aave Labs: $86 Million, 23% of the Token Supply, and this is their Track Record\n\n BGD. Abandoning the Project E idea\n\n [TEMP CHECK] One-Time Bounty Award — CoW Swap Fee Discovery\n\n 15\n\n 10\n\n 8\n\n 7\n\n 7\n\n read \n\n 92\n min\n\n post by ApuMallku on Dec 16, 2025\n\n post by anon40760803 on Dec 16, 2025\n\n post by kov0x on Dec 16, 2025\n\n post by IWonder on Dec 16, 2025\n\n post by EzR3aL on Dec 16, 2025\n\n post by A_J on Dec 16, 2025\n\n post by 0xmonk on Dec 16, 2025\n\n post by StayHumble on Dec 16, 2025\n\n post by 0x4444 on Dec 16, 2025\n\n post by setaavefree on Dec 16, 2025\n\n post by Ethicalprofit on Dec 16, 2025\n\n post by Ethicalprofit on Dec 16, 2025\n\n post by phenk53 on Dec 16, 2025\n\n post by Jordan on Dec 16, 2025\n\n post by Fulltilt on Dec 16, 2025\n\n post by BCV on Dec 16, 2025\n\n post by Fulltilt on Dec 16, 2025\n\n post by BigIdeas on Dec 16, 2025\n\n post by Codeknight on Dec 16, 2025\n\n Load more posts below","tokens":3220,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264014320,"hash":"63ad74b2be8a17ec52f556be5c0143162c5d7f79"}
{"url":"https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541/1","domain":"ethresear.ch","title":"PeerDAS -- a simpler DAS approach using battle-tested p2p components - Networking - Ethereum Research","text":"PeerDAS – a simpler DAS approach using battle-tested p2p components \n\n Networking\n\n data-availability,p2p,scaling\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n Sep 2023\n\n 1 / 10\n\n Sep 2023\n\n Apr 2024\n\n post by djrtwo on Sep 4, 2023\n\n djrtwo\n\n PeerDAS\nThis is an sketch representing the general direction of PeerDAS. This is being circulated at an early stage for feedback before further discussion refinement.\nThis set of ideas came out of conversations with Dankrad, Vitalik, members of Codex, RIG, ARG, and Consensus R&D. Directionally, pieces of this type of approach have also been under discussion in various avenues for the past couple of years, e.g. Proto’s PeerDHT\nThe intent of a PeerDAS design is to reuse well known, battle-tested p2p components already in production in Ethereum to bring additional DA scale beyond that of 4844 while keeping the minimum amount of work of honest nodes in the same realm as 4844 (downloading < 1MB per slot).\nThis is an exploration to better understand what scale we can get out of a relatively simple network structure with various distributions of node types without relying on a more advanced DHT-like solution.\nSimulations of effectiveness of such a solution involve parametrizing the following:\n\ndata size (number of rows and columns per block, as well as sample size)\ntotal number of number of nodes on the network\nminimum amount of work an honest node is expected to do (e.g. custody and serve samples from X rows and columns)\nthe distribution of node capacities (i.e. what fraction of the network is minimally honest (custodies/serves X) and beyond (e.g. custodies/serves 10%, 25%, 100% of network data)) and the max sample requests they are willing to support (i.e. Y samples per slot)\nhonest/byzantine ratio assumptions\n\nDifferent parametrizations of the above will lead to either acceptable or broken configurations (e.g. data size might be too large to find peers of enough capacity for a given network distributions).\nA note on DAS in general\nImportantly, any DAS solution will rely upon nodes of various types and the assumptions we can make about them. Node types worth considering in any solution are:\n\nValidator and user nodes (Honesty custody/serve assumption can be placed upon them, e.g. download and serve samples of X rows/columns. Note, validators can be incentivized to custody but not necessarily to serve)\nHigh capacity nodes (some % of the data beyond baseline honest node)\nSuper-full nodes (100% of data) [special case of high capacity node]\n\nThe difference between DAS solutions then becomes – how does the DAS network organize itself, how do you discover peers for sampling, how does the network utilize (or under-utilize) nodes of higher capacity (e.g. can the solution support lumpiness in node capacity or do all nodes look equal).\nSketch of PeerDAS\nConfiguration\nThe following is a bit of a reduction of the full requisite parametrization for illustration purposes.\nAll values in the table are example values and do not represent suggestions for an actual parametrization.\n\nName\nSample Value\nDescription\n\nNUMBER_OF_ROWS_AND_COLUMNS\n32\n\nSAMPLES_PER_ROW_COLUMN\n512\n\nCUSTODY_REQUIREMENT\n2\nMinimum number of both rows and columns an honest node custodies and serves samples from\n\nSAMPLES_PER_SLOT\n75\nNumber of random samples a node queries per slot\n\nNUMBER_OF_PEERS\n70\nMinimum number of peers a node maintains\n\nHow it works\nCustody\nEach node downloads and custodies a minimum of CUSTODY_REQUIREMENT rows and CUSTODY_REQUIREMENT columns per slot. The particular rows and columns that the node is required to custody are selected pseudo-randomly (more on this below).\nA node may choose to custody and serve more than the minimum honesty requirement. Such a node explicitly advertises a number greater than CUSTODY_REQUIREMENT via the peer discovery mechanism – for example, in their enr (e.g. cust: 8 if the node custodies 8 rows and 8 columns each slot) – up to a maximum of NUMBER_OF_ROWS_AND_COLUMNS (i.e. a super-full node).\nA node stores the custodied rows/columns for the duration of the pruning period and responds to peer requests for samples on those rows/columns.\nPublic, deterministic selection\nThe particular rows and columns that a node custodies are selected pseudo-randomly as a function of the node-id, epoch, and custody size (sample function interface: custodied_rows(node_id, epoch, custody_size=CUSTODY_REQUIREMENT) -> List(uint64) and column variant) – importantly this function can be run by any party as the inputs are all public.\nNote: increasing the custody_size parameter for a given node_id and epoch extends the returned list (rather than being an entirely new shuffle) such that if custody_size is unknown, the default CUSTODY_REQUIREMENT will be correct for a subset of the node’s custody.\nNote: Even though this function accepts epoch as an input, the function can be tuned to remain stable for many epochs depending on network/subnet stability requirements. There is a trade-off between rigidity of the network and the depth to which a subnet can be utilized for recovery. To ensure subnets can be utilized for recovery, staggered rotation needs to happen likely on the order of the prune period.\nPeer discovery\nAt each slot, a node needs to be able to readily sample from any set of rows and columns. To this end, a node should find and maintain a set of diverse and reliable peers that can regularly satisfy their sampling demands.\nA node runs a background peer discovery process, maintaining at least NUMBER_OF_PEERS of various custody distributions (both custody_size and row/column assignments). The combination of advertised cust size and public node-id make this readily, publicly accessible.\nNUMBER_OF_PEERS should be tuned upward in the event of failed sampling.\nNote: while high-capacity and super-full nodes are high value with respect to satisfying sampling requirements, a node should maintain a distribution across node capacities as to not centralize the p2p graph too much (in the extreme becomes hub/spoke) and to distribute sampling load better across all nodes.\nNote: A DHT-based peer discovery mechanism is expected to be utilized in the above. The beacon-chain network currently utilizes discv5 in a similar method as described for finding peers of particular distributions of attestation subnets. Additional peer discovery methods are valuable to integrate (e.g. latent peer discovery via libp2p gossipsub) to add a defense in breadth against one of the discovery methods being attacked.\nRow/Column gossip\nThere are both NUMBER_OF_ROWS_AND_COLUMNS row and NUMBER_OF_ROWS_AND_COLUMNS column gossip topics, one for each row/column – column_X and row_Y for X and Y from 0 to NUMBER_OF_ROWS_AND_COLUMNS (non-inclusive).\nTo custody a particular row or column, a node joins the respective gossip subnet. Verifiable samples from their respective row/column are gossiped on the assigned subnet.\nReconstruction and cross-seeding\nIn the event a node does not receive all samples for a given row/column but does receive enough to reconstruct (e.g. 50%+, a function of coding rate), the node should reconstruct locally and send the reconstructed samples on the subnet.\nAdditionally, the node should send (cross-seed) any samples missing from a given row/column they are assigned to that they have obtained via an alternative method (ancillary gossip or reconstruction). E.g., if node reconstructs row_x and is also participating in the column_y subnet in which the (X, Y) sample was missing, send the reconstructed sample to column_y.\nNote: A node is always maintaining a matrix view of the rows and columns they are following, able to cross-reference and cross-seed in either direction.\nNote: There are timing considerations to analyze – at what point does a node consider samples missing and chooses to reconstruct and cross-seed.\nNote: There may be anti-DoS and quality-of-service considerations around how to send samples and consider samples – is each individual sample a message or are they sent in aggregate forms.\nPeer sampling\nAt each slot, a node makes (locally randomly determined) SAMPLES_PER_SLOT queries for samples from their peers. A node utilizes custodied_rows() and custodied_columns() to determine which peer(s) to request from. If a node has enough good/honest peers across all rows and columns, this has a high chance of success.\nUpon sampling, the node sends an DO_YOU_HAVE packet for all samples to all peers who are determined to custody this sample according to their custodied_rows/custodied_columns. All peers answer first with a bitfield of the samples that they have.\nUpon receiving a sample, a node will pass on the sample to any node which did not previously have this sample, known by DO_YOU_HAVE response (but was supposed to have it according to its custodied_rows/custodied_columns).\nPeer scoring\nDue to the deterministic custody functions, a node knows exactly what a peer should be able to respond to. In the event that a peer does not respond to samples of their custodied rows/columns, a node may downscore or disconnect from a peer.\nNote: a peer might not respond to requests either because they are dishonest (don’t actually custody the data), because of bandwidth saturation (local throttling), or because they were, themselves, not able to get all the samples. In the first two cases, the peer is not of consistent DAS value and a node can/should seek to optimize for better peers. In the latter, the node can make local determinations based on repeated DO_YOU_HAVE queries to that peer and other peers to assess the value/honesty of the peer.\nDAS providers\nA DAS provider is a consistently-available-for-DAS-queries, super-full (or high capacity) node. To the p2p, these look just like other nodes but with high advertised capacity, and they should generally be able to be latently found via normal discovery.\nThey can also be found out-of-band and configured into a node to connect to directly and prioritize. E.g., some L2 DAO might support 10 super-full nodes as a public good, and nodes could choose to add some set of these to their local configuration to bolster their DAS quality of service.\nSuch direct peering utilizes a feature supported out of the box today on all nodes and can complement (and reduce attackability) of alternative peer discovery mechanisms.\nA note on fork choice\nThe fork choice rule (essentially a DA filter) is orthogonal to a given DAS design, other than the efficiency of particular design impacting it.\nIn any DAS design, there are probably a few degrees of freedom around timing, acceptability of short-term re-orgs, etc.\nFor example, the fork choice rule might require validators to do successful DAS on slot N to be able to include block of slot N in it’s fork choice. That’s the tightest DA filter. But trailing filters are also probably acceptable, knowing that there might be some failures/short re-orgs but that it doesn’t hurt the aggregate security. E.g. The rule could be – DAS must be completed for slot N-1 for a child block in N to be included in the fork choice.\nSuch trailing techniques and their analyiss will be valuable for any DAS construction. The question is — can you relax how quickly you need to do DA and in the worst case not confirm unavailable data via attestations/finality, and what impact does it have on short-term re-orgs and fast confirmation rules.\nTODO: Simulation and Analysis of PeerDAS\nThe crux of PeerDAS is that each node can find/maintain enough peers of enough capacity at each slot to meet their sampling requirements.\nThus for a given data size, we can easily simulate network distributions (node count, distributions of node type/capacity, number sample-requests each node can respond to, minimum number of peers, etc) to understand the chances of successful DAS at each slot.\nWe can calculate/simulate safe data sizes of various parametrizations and assumptions, e.g.:\n\na homogeneous network of minimally honest nodes at a roughly 4844 custody requirement\nthe above but then accented with 100 super-full nodes with X capacity for queries\nall sorts of distributions in between\n\nNext up – simulations of various network distributions to anchor our understanding of the bounds of this method.\n\n SubnetDAS - an intermediate DAS approach\n\n From 4844 to Danksharding: a path to scaling Ethereum DA\n\n FullDAS: towards massive scalability with 32MB blocks and beyond\n\n DAS fork-choice\n\n Scalability limitations of Kademlia DHTs when Enabling Data Availability Sampling in Ethereum\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by zilm13 on Sep 5, 2023\n\n post by Nashatyrev on Sep 5, 2023\n\n post by cskiraly on Sep 5, 2023\n\n post by cskiraly on Sep 5, 2023\n\n post by pop on Sep 8, 2023\n\n post by dryajov on Sep 9, 2023\n\n 2 months later\n\n post by Nashatyrev on Nov 8, 2023\n\n 2 months later\n\n post by storm on Jan 10, 2024\n\n 3 months later\n\n post by Evan-Kim2028 on Apr 17, 2024\n\n Powered by Discourse","tokens":3240,"squid":"ink-research","role":"Deep Scholar","at":1791264020775,"hash":"bb825f80e72cd2e582d2b05a82355d9e8b5a1dad"}
{"url":"https://governance.aave.com/c/other/6","domain":"governance.aave.com","title":"Latest Other topics - Aave","text":"Latest topics in Other\n\n Other\n\n subcategories\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Out-of-Band Transaction Verification for Multisigs \n\n Other\n\n 0\n\n 34\n\n Sep 20\n\n Core Wallet on Avalanche V3 forces unnecessary Ethereum network switch\n\n Site Feedback\n\n 1\n\n 74\n\n Aug 17\n\n Improved Portfolio Dashboard\n\n Site Feedback\n\n 4\n\n 221\n\n Aug 15\n\n Streaming yield for Aave depositors and app savers\n\n Other\n\n 0\n\n 74\n\n Jul 16\n\n Introducing AaveAPY: An Yield Dashboard and Simulator\n\n Other\n\n 1\n\n 275\n\n Jul 16\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 97\n\n Jul 13\n\n Aave DeFi Watcher – Browser Extension for Monitoring Aave Positions\n\n Other\n\n 1\n\n 146\n\n Jul 7\n\n Avee does not properly connect with rabby\n\n Other\n\n 1\n\n 140\n\n Jun 22\n\n [Recovery Request] Accidental Direct USDT Transfer to Aave Contract on Celo — rescueTokens Assistance Needed\n\n Other\n\n 0\n\n 112\n\n Jun 22\n\n Introducing zyk-positions — understand what your Aave V3 position is actually doing\n\n Other\n\n 0\n\n 93\n\n Jun 10\n\n How to unstake?\n\n Other\n\n 0\n\n 76\n\n Jun 1\n\n Temp-Check / Principal-Preserving Charitable Giving Layer for Aave App\n\n Other\n\n 4\n\n 208\n\n May 23\n\n Understanding the Legacy Safety Module under Umbrella\n\n Other\n\n 3\n\n 306\n\n May 22\n\n Unable to borrow ERC20 on Aave\n\n Other\n\n 0\n\n 83\n\n May 8\n\n Temp Check / Discussion: Exploration of Aave Deployment on Cardano (Feasibility Study Proposal)\n\n Other\n\n 16\n\n 699\n\n May 4\n\n This asset is frozen due to an Aave community decision\n\n Other\n\n 5\n\n 1.1k\n\n Apr 20\n\n My asset is frozen due to an Aave Protocol Governance decision\n\n Other\n\n 2\n\n 2.0k\n\n Apr 19\n\n Growing GHO and Horizon\n\n Other\n\n 6\n\n 920\n\n Apr 16\n\n [TEMP CHECK] Aave Protocol Treasury Revenue Sharing Program\n\n Other\n\n 5\n\n 588\n\n Apr 13\n\n EURC LTV 0 on Core and Base\n\n Other\n\n 1\n\n 170\n\n Apr 11\n\n The Literacy Barrier in DAO Governance: How Technical Complexity Excludes the Global South\n\n Other\n\n 5\n\n 190\n\n Apr 10\n\n 2025 Events Recap\n\n Other\n\n 2\n\n 363\n\n Apr 9\n\n [TEMP CHECK] Update forum features\n\n Site Feedback\n\n 18\n\n 1.3k\n\n Mar 24\n\n I’m a danish student at Aarhus University writing my Bachelor’s thesis on lending/borrowing mechanisms and investor behavior on Aave\n\n Other\n\n 0\n\n 120\n\n Mar 18\n\n Help a student? 3-min survey on Aave behavior for Bachelor’s Thesis\n\n Other\n\n 0\n\n 127\n\n Mar 5\n\n Aave Monitor browser extension\n\n Other\n\n 10\n\n 999\n\n Feb 24\n\n [TEMP CHECK] Base Pool Upgrade - prevents permanent fund locks\n\n Other\n\n 3\n\n 157\n\n Feb 17\n\n When can we expect an Aave Labs response?\n\n Other\n\n 10\n\n 693\n\n Jan 31\n\n Introducing Maxshot AI as a Strategy Operator in the Aave Ecosystem\n\n Other\n\n 3\n\n 534\n\n Jan 26\n\n POLL: Which conferences will you attend in 2026?\n\n Other\n\n 0\n\n 148\n\n Jan 8","tokens":687,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264024442,"hash":"b606a9884a970c162608d980c0c8aae3d6453162"}
{"url":"https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541/10","domain":"ethresear.ch","title":"PeerDAS -- a simpler DAS approach using battle-tested p2p components - Networking - Ethereum Research","text":"Networking\n\n data-availability,p2p,scaling\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n Sep 2023\n\n 10 / 10\n\n Apr 2024\n\n Apr 2024\n\n post by djrtwo on Sep 4, 2023\n\n post by zilm13 on Sep 5, 2023\n\n post by Nashatyrev on Sep 5, 2023\n\n post by cskiraly on Sep 5, 2023\n\n post by cskiraly on Sep 5, 2023\n\n post by pop on Sep 8, 2023\n\n post by dryajov on Sep 9, 2023\n\n dryajov\n\n I don’t think this is going to work for the 128mb erasure coded block (even if only pushing the original 32mb+proofs), if this is however being planed in the context of 4844 and 1mb block sizes, then it is probably a good starting point.\n\n 2 months later\n\n post by Nashatyrev on Nov 8, 2023\n\n Nashatyrev\n\n Here is kind of a slightly alternative view on networking organization and the potential approach to reliable and secure push/pull sampling: Network Shards - HackMD\nIn some aspects it complements PeerDAS and in other aspects it proposes alternatives\n\n 2 months later\n\n post by storm on Jan 10, 2024\n\n storm\n\n can you elaborate on these design decisions (they add extra complexity):\n\nwhy partition along rows and columns, instead of just partitioning across rows?\nwhy allow lumpy custody sizes, instead of just making a uniform custody chunk size? super-full nodes could just be multiple peers in the network as in beacon\n\na couple other questions:\n\nis peerdas data intended to be ephemeral as in 4844 or more permanent?\nwhat are the desired timing properties of peerdas? live available data every single block?\n\n 3 months later\n\n post by Evan-Kim2028 on Apr 17, 2024\n\n Evan-Kim2028\n\nI would imagine it’s a requirement to get data sampling working. See here for more details - From 4844 to Danksharding: a path to scaling Ethereum DA\n\n Powered by Discourse","tokens":444,"squid":"ink-research","role":"Deep Scholar","at":1791264030938,"hash":"7341e6e440d067a6e6dfae46ab282785626808a1"}
{"url":"https://governance.aave.com/t/recovery-request-accidentally-sent-25k-usdc-directly-to-aave-v3-pool/25309/1","domain":"governance.aave.com","title":"[Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool - Other - Aave","text":"[Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool \n\n Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 13\n\n 1 / 3\n\n Jul 14\n\n Jul 13\n\n post by stoneseen on Jul 13\n\n stoneseen\n\n Hi all,\nOn July 12nd, I mistakenly sent 25,000 USDC directly to the Aave V3 Pool contract on ETH instead of supplying via the interface.\n\nTx hash: 0x6a4cd27125fe4916909efdb9e6cc79f298ce514e56bd4851e92641f71c666b5c\nPool proxy address: 0x98c23e9d8f34fefb1b7bd6a91b7ff122f4e16f5c\nSending wallet: 0x32fcf748e4dcebd1081bfcccb94eb721101f27c0 (I can sign a message to prove ownership)\n\nI understand from Rescue Mission Phases 1–3 that recovery of tokens sent directly to upgradeable Aave contracts is technically feasible via a governance-approved implementation upgrade, with claims distributed through the AaveMerkleDistributor to the original sending address.\nRequest to BGD Labs / ACI / the community: could this transfer be registered for inclusion in a future rescue phase covering the V3 Pool? Happy to provide any additional verification needed.\nThank you.\n\n Unlisted on Jul 13\n\n Listed on Jul 14\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase\n\n Development\n\n 0\n\n 115\n\n Jul 14\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 99\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 88\n\n 12d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d","tokens":433,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264034537,"hash":"869a9b1629558455c23933d8dfaa2dc3d43c833e"}
{"url":"https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541/9","domain":"ethresear.ch","title":"PeerDAS -- a simpler DAS approach using battle-tested p2p components - Networking - Ethereum Research","text":"Networking\n\n data-availability,p2p,scaling\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n Sep 2023\n\n 9 / 10\n\n Jan 2024\n\n Apr 2024\n\n post by djrtwo on Sep 4, 2023\n\n post by zilm13 on Sep 5, 2023\n\n post by Nashatyrev on Sep 5, 2023\n\n post by cskiraly on Sep 5, 2023\n\n post by cskiraly on Sep 5, 2023\n\n post by pop on Sep 8, 2023\n\n pop\n\nYes, that requires too much bandwidth for a regular node. The constants are very preliminary.\nI think the reason we put 32 as NUMBER_OF_ROWS_AND_COLUMNS because we want to maintain the number of subnets as 64, which keeps us from changing much how the current subnet infrastructure works.\n\n post by dryajov on Sep 9, 2023\n\n dryajov\n\n I don’t think this is going to work for the 128mb erasure coded block (even if only pushing the original 32mb+proofs), if this is however being planed in the context of 4844 and 1mb block sizes, then it is probably a good starting point.\n\n 2 months later\n\n post by Nashatyrev on Nov 8, 2023\n\n Nashatyrev\n\n Here is kind of a slightly alternative view on networking organization and the potential approach to reliable and secure push/pull sampling: Network Shards - HackMD\nIn some aspects it complements PeerDAS and in other aspects it proposes alternatives\n\n 2 months later\n\n post by storm on Jan 10, 2024\n\n storm\n\n can you elaborate on these design decisions (they add extra complexity):\n\nwhy partition along rows and columns, instead of just partitioning across rows?\nwhy allow lumpy custody sizes, instead of just making a uniform custody chunk size? super-full nodes could just be multiple peers in the network as in beacon\n\na couple other questions:\n\nis peerdas data intended to be ephemeral as in 4844 or more permanent?\nwhat are the desired timing properties of peerdas? live available data every single block?\n\n 3 months later\n\n post by Evan-Kim2028 on Apr 17, 2024\n\n Evan-Kim2028\n\nI would imagine it’s a requirement to get data sampling working. See here for more details - From 4844 to Danksharding: a path to scaling Ethereum DA\n\n Powered by Discourse","tokens":518,"squid":"ink-research","role":"Deep Scholar","at":1791264041052,"hash":"789b03201b16d152d0c419fb443d4b3626c61f36"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-aethusdc-transfer-to-aave-usdc-contract-on-eth/25530/1","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH - Governance - Aave","text":"[RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 25\n\n 1 / 2\n\n Aug 25\n\n Aug 25\n\n post by bikash on Aug 25\n\n bikash\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future rescue mission.\nI accidentally transferred 49792 AETHUSDC directly to the AAVE USDC contract on ETH instead of using the “Supply” function in the Aave App.\nTransaction Hash:\n0xaabdab3bb21e1705a1e160c7fc2669a24198c6daa489792de103e89fda1c39e6\nSender Wallet:\n0x115304710b38dbee977cfa628493b83dec39fe66\nRecipient Contract:\n0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c\nI mistakenly copied the AAVE USDC contract address and sent AETHUSDC directly from my wallet.\nI am the owner of the sender wallet address.\nIf any additional information or proof is required, I will be happy to provide it.\nThank you very much for your time and consideration.\nKind regards,\nThank you. Regards\n\n 1 month later\n\n Closed on Sep 24\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 88\n\n 12d\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 142\n\n Jul 20\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5","tokens":443,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264044670,"hash":"a437d8f89bfb39b036514100c53c14bbf2c9643a"}
{"url":"https://ethresear.ch/t/blocks-are-dead-long-live-blobs/24611","domain":"ethresear.ch","title":"Blocks Are Dead. Long Live Blobs - zk-s[nt]arks - Ethereum Research","text":"Blocks Are Dead. Long Live Blobs \n\n zk-s[nt]arks\n\n zk-roll-up\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Apr 7\n\n 1 / 6\n\n Apr 7\n\n Jun 29\n\n post by Nero_eth on Apr 7\n\n Nero_eth\n\n Blocks Are Dead. Long Live Blobs.\nThanks to Kev, Francesco, soispoke, Anders and Jihoon for feedback and review.\n\nTL;DR: Block in Blobs (BiB) takes transactions in RLP format, and encodes it as a blob (similar to type-3-txs). This is beneficial in a zkEVM world as not everyone will need to download every transaction anymore - reducing bandwidth requirements.\n\nWith zkEVM coming, validators will no longer need to execute transactions to verify blocks: a succinct proof will be enough. But this changes how data availability works.\nToday, DA is enforced implicitly: you can’t verify a block without downloading and executing its transactions. Under zkEVM, validators verify proofs, not transactions directly. A builder could publish a valid block and proof while withholding the underlying transaction data. The block would pass consensus, but no one could re-execute it, index it, or reliably build on top of it.\nBlock-in-Blobs (BiB) addresses this by encoding transaction data into blobs, making DA a consensus-level requirement. Validators can then sample rather than download: same guarantees, less bandwidth, more scale.\nIn the following, I want to walk through the design space and things that helped me wrap my head around it.\n\nbackground: blocks, payloads, and transactions\nTo understand BiB, we first need to untangle some terminology. Ethereum is split into two layers: the Consensus Layer (CL) and the Execution Layer (EL). This separation is intentional and powerful, but it introduces conceptual friction, especially around what exactly a block or payload is.\nblocks vs. execution payloads\nFrom the consensus layer’s point of view, the canonical object is the beacon block. A beacon block may include an ExecutionPayload, but it is not itself an execution block.\nThe ExecutionPayload is the object exchanged between CL and EL via the Engine API:\n\nDuring block building, the EL constructs an ExecutionPayload and hands it to the CL.\nDuring validation and attestation, the CL hands the payload back to the EL for execution.\n\nThe ExecutionPayload is not the EL’s native block format. Instead, it contains exactly the information the EL needs to reconstruct and validate an execution block internally.\nThe ExecutionPayload size grows with the block gas limit, but also depends on the calldata pricing and other factors. With increasing block gas limits, block sizes increase too, and so do bandwidth requirements. Fortunately, there’re two solution.\nFirst, following the example of Flashblocks, we could split the payload into constant-size pieces, enabling them to be processed independently - effectively hiding latency.\nSecond, we could think of ways that allow validators to not download all transaction while still having certainty about them being published - Block in Blobs (BiB). While this post described the first solution, I want to focus on the second one in the following.\nBiB proposes to encode blocks (potentially also the Block-level Access List (BAL)) into constant-size blobs. Similar to type-3-tx blobs, validators will then not need to download the full ExecutionPayload anymore but instead only the columns they have custody over. This unlocks scaling benefits because not every validator will need to download everything, reducing bandwidth requirements without weakening the security/availability guarantees.\nSo when people say “put blocks into blobs”, what they really mean is putting the CL’s execution payload into blobs… and even that isn’t the full truth.\nwhat BiB actually encodes\nDespite the name, BiB doesn’t put entire blocks, or even entire execution payloads, into blobs. In its simplest form, the protocol only needs to ensure transaction data availability.\nTransactions inside the ExecutionPayload are already in the right shape:\n\nEach transaction is already RLP-encoded bytes.\nThe payload contains a list of these bytes.\n\nBiB takes the serialized RLP-encoded transactions, chunkifys them and packs them into blobs.\nEverything else execution-related (EL header fields, execution output roots, etc.) would either move into the beacon block or come in a separate sidecar with a commitment in beacon block. BiB guarantees that the information needed for re-execution is available.\n\nBlock-level Access Lists (BALs) may share the same destiny as transaction. Since the users of BALs may be different from the users of transactions, it might make sense to put BALs into blobs too but separate from the transactions.\n\nhow transactions become blobs\nWith the “what” and “why” established, let’s look at the “how.” Blob encoding follows the EIP-4844 model:\n\nSerialize transaction bytes\n\nTake payload.transactions (each already RLP-encoded)\nCanonically encode the list (typically RLP of the list of tx-bytes)\n\nPack bytes into blobs\n\nSplit the byte stream into 31-byte chunks\nEach chunk becomes the first 31 bytes of a 32-byte field element\nThe first byte is set to 0x00 so the element stays under the BLS modulus\n4096 field elements form one blob\n\nCommit\n\nInterpret the blob as a polynomial\nCompute a KZG commitment\nThe beacon block references these commitments\n\nSidecar\n\nSimilar to type-3-tx sidecars, or the ExecutionPayloadEnvelope as of ePBS, the payload blob travels the network in a sidecar\nIn addition to the payload blob, each sidecar comes with an index, kzg proofs, the slot number and the beacon block root.\n\nCustody\n\nInitially, validators may store all payload blobs without leveraging DAS\nValidators can download the payload blobs (which is almost the equivalent to downloading the ExectutionPayloadEnvelope under ePBS) and locally construct the ExecutionPayload from it.\nAt a later stage, partial custody and DA sampling can be introduced, leveraging the newly introduced mechanism for scaling (not requiring everyone to download all transactions)\nThe same applies to erasure encoding and cell-level messaging\n\nThe key insight: under zkEVMs validators don’t need the transactions to verify commitments. They only need commitments for consensus, while DA sampling ensures the blob contents are available on the network.\nwhat the zkEVM proof must bind\nFor BiB to work for zk-attesters who don’t download all payload blobs, the proof must guarantee three things:\n\nExecution correctness\nThe state transition from pre_state to post_state is valid.\nCorrect transaction-to-blob encoding\nThe exact canonical transaction bytes were packed into the blobs.\nCommitment binding\nThe blob commitments referenced by the beacon block correspond to those payload blobs.\n\nTogether, these requirements transform data availability from “implicit via re-execution” into “explicit via blob commitments + DAS.”\nNote: BiB and zkEVMs/mandatory-proofs are orthogonal:\nBiB can be rolled out iteratively, starting with putting transactions (and potentially the BAL) into blobs without yet introducing mandatory zk-proofs for execution and blob-encoding. Furthermore, the partial data custody doesn’t need to be done right from the beginning. BiB, in its minimal form, simply takes the RLP encoded transactions, and encodes them into blobs. From the EL perspective nothing changes - upon receipt, the CL constructs the ExecutionPayload from the received blobs and builds the EL block from it - just like today. At this point, those blobs can already be used by zk-attesters consuming optional proofs, which are slated to be rolled out pre-mandatory proofs for a limited set of attesters.\nwhere the rest of the payload goes\nBiB doesn’t move the entire execution payload into blobs: only the transaction data.\nBuilding on top of ePBS, the beacon block carries the execution header (or commitments / metadata) while the payload is made available separately via blobs.\nBlobs carry the heavy bytes; bids carry the compact commitments.\nbib1551×480 63.3 KB\n\nThis design would complicate moving to slot auctions in the future. If we want to keep that option, we may still need ePBS’s ExecutionPayloadEnvelope alongside the sidecars or move EL requests into the payload blobs too.\n\nhow many blobs will payloads need?\nFinally, let’s ground this in concrete numbers. Today’s execution payloads at a 60M gas limit average ~150 KiB (=~1-2 payload blobs), with a maximum size of ~5.7 MiB (depending on EL data pricing).\nThe maximum number of payload blobs depends on both the gas limit and calldata pricing. Looking at recent blocks, a 60M gas limit occasionally produces 3-4 blob blocks:\nimage987×583 82.6 KB\nIn the worst case, assuming EIP-7976 (64 gas per byte for calldata-heavy transactions), we’d need ~7 blobs filled with calldata. With today’s calldata pricing (10/40 gas), that number jumps to 45 blobs, and generalizing it further, we get the following formula to determine the max blob count needed:\n\nN= \\left\\lceil \\frac{L}{c \\cdot B} \\right\\rceil\n𝑁=⌈𝐿𝑐⋅𝐵⌉\nwhere\nL𝐿 = block gas limit\nc𝑐 = calldata gas cost (gas/byte)\nB𝐵 = blob size (bytes)\nimage987×583 57.8 KB\n\nappendix - unified data gas\nBiB answers how to make transaction data available via blobs. But it surfaces a more fundamental question: how do we account for all this data?\nToday, Ethereum has two separate resource dimensions for data:\n\nExecution gas: used by calldata (4/16 gas per zero/non-zero byte, or 10/40 at the EIP-7623 floor)\nBlob gas: used by type-3 transaction blobs (131,072 blob gas per blob)\n\nThese dimensions have independent limits. The block gas limit caps execution gas; MAX_BLOB_GAS_PER_BLOCK caps blob gas. A block can max out both simultaneously.\nthe additive worst case\nUnder BiB, calldata becomes blobs. But type-3 transactions also carry blobs. Without changes to resource accounting, we face an additive worst case:\n\nN_{worst} = N_{calldata} + N_{type3} = \\left\\lceil \\frac{L}{c \\cdot B} \\right\\rceil + \\frac{\\text{MAX_BLOB_GAS}}{\\text{GAS_PER_BLOB}}\n'_' allowed only in math mode\nWith a 60M gas limit, EIP-7976 pricing (64 gas/byte), and 21 type-3 blobs:\n\nN_{worst} = 7 + 21 = 28 \\text{ blobs}\n𝑁𝑤𝑜𝑟𝑠𝑡=7+21=28 blobs\nWith today’s calldata pricing (10/40 gas), this equals 11 + 21 = 32 blobs, all non-compressible.\nunified data gas: one dimension for all DA\nThe elegant solution is to collapse data from calldata and blob data into a single data dimension. The core principle:\nAll data that needs to be made available should count against the same limit.\nThe fragmentation exists only at the EL, where we have:\n# Current: TWO separate checks\nassert tx.gas <= block_gas_limit - block.gas_used # execution gas\nassert tx.blob_gas <= MAX_BLOB_GAS - block.blob_gas_used # blob gas\n\nWith BiB, both transactions and type-3 blobs become the same thing: blobs, and the accounting should reflect this.\ndesign: unified data gas\nReplace the two-dimension model with a single data bytes dimension:\nBYTES_PER_BLOB = 131_072 # 128 KiB\nMAX_DATA_BYTES = max_blobs * BYTES_PER_BLOB # e.g., 28 blobs ≈ 3.5 MiB\n\ndef data_bytes(tx):\n # Full encoded tx goes into payload blob\n tx_bytes = len(rlp_encode(tx))\n\n # Type-3 blob sidecars add more DA\n if tx.blob_versioned_hashes:\n tx_bytes += len(tx.blob_versioned_hashes) * BYTES_PER_BLOB\n\n return tx_bytes\n\nNote: The full RLP-encoded transaction (signature, nonce, gas fields, and calldata) is packed into payload blobs. The tx envelope overhead (~100-200 bytes per tx) is real DA.\n\nBlock-level enforcement becomes a single check:\n# One unified check (replaces separate gas + blob_gas checks)\nif data_bytes(tx) > MAX_DATA_BYTES - block.data_bytes_used:\n invalid(\"data limit exceeded\")\n\nNo more additive worst case. A block can have 28 blobs worth of data, whether that’s 28 type-3 blobs, 28 blobs of encoded transactions, or any mix.\nseparating execution from DA\nCalldata currently pays execution gas that implicitly covers both computation and data availability. With unified data gas, we cleanly separate these concerns:\ndef intrinsic_cost(tx):\n # Execution gas: pure compute (no calldata costs!)\n exec_gas = TX_BASE_COST + access_list_cost + create_cost + auth_cost\n\n # Data bytes: full tx + blob sidecars\n data = len(rlp_encode(tx))\n if tx.blob_versioned_hashes:\n data += len(tx.blob_versioned_hashes) * BYTES_PER_BLOB\n\n return exec_gas, data\n\nNotice what’s missing: no calldata gas costs, no EIP-7623 floor.\nwhy the calldata floor becomes unnecessary\nEIP-7623 introduced a calldata floor to prevent large blocks from calldata that come with no execution, ensuring calldata-heavy transactions can’t underpay for the bandwidth burden they impose, while not consuming any other resource. But in a unified data fee market, this protection comes for free:\n\nConcern\nEIP-7623 Solution\nUnified Data Gas Solution\n\nSpam prevention\nFloor gas cost (10/40 per byte)\nData fee market (rising data_base_fee)\n\nPrice signal\nImplicit in execution gas\nExplicit data_base_fee per byte\n\nAdaptivity\nFixed floor\nDynamic (EIP-1559-style adjustments)\n\nIf someone tries to fill blocks with calldata, data_base_fee rises, just like base_fee_per_gas rises when blocks are full. The market handles spam prevention automatically.\nThe cleaner model:\n\nExecution gas = pure compute (TX_BASE_COST + access lists + auth + create + opcodes during execution)\nData bytes = all DA (full encoded transaction bytes + blob sidecar bytes)\n\nNo double-counting. No floor. One fee for compute, one fee for data.\neip-1559, but for data\nJust as blob gas has its own EIP-1559-style fee market, unified data bytes would too:\n# EIP-1559-style pricing for data (same mechanism as blob gas today)\ndata_base_fee = fake_exponential(MIN_DATA_PRICE, excess_data_bytes, UPDATE_FRACTION)\n\n# Excess tracking (same as blob gas)\nexcess = max(0, parent.excess_data_bytes + parent.data_bytes_used - TARGET_DATA_BYTES)\n\nA new transaction type introduces an explicit data fee cap, giving users finer-grained control over how much they are willing to pay for data:\n# New transaction type fields (similar to type-3 for blobs)\ntx.max_fee_per_data_byte # explicit data fee cap\ntx.blob_versioned_hashes # for blob sidecars\n\nThe full validation flow looks like the following:\ndef validate(tx, block):\n exec_gas, data = intrinsic_cost(tx)\n\n if has_explicit_data_fee(tx):\n # New tx type: explicit per-dimension caps\n max_cost = tx.gas * tx.max_fee_per_gas + data * tx.max_fee_per_data_byte\n assert tx.max_fee_per_data_byte >= data_base_fee\n else:\n # Legacy: single aggregate budget (EIP-7999 style)\n max_cost = get_max_fee(tx) # gas_price × gas_limit\n required = exec_gas * base_fee_per_gas + data * data_base_fee\n assert required <= max_cost\n\n assert exec_gas <= tx.gas\n assert data <= MAX_DATA_BYTES - block.data_bytes_used\n assert sender.balance >= max_cost + tx.value\n\nbackwards compatibility\nThe max_fee_per_data_byte field is introduced in a new transaction type. But existing transactions remain fully compatible via gas limit partitioning (see EIP-7999 for details):\ndef partition_gas_limit(tx):\n if has_explicit_data_fee(tx): # new tx type\n return tx.gas, data_bytes(tx)\n else: # legacy types\n calldata_tokens = zero_bytes + 4 * non_zero_bytes\n execution_gas = tx.gas - STANDARD_TOKEN_COST * calldata_tokens\n return execution_gas, data_bytes(tx)\n\nThe key insight: legacy transactions’ gas_price × gas_limit already provides a total budget. This budget now covers both execution gas and data gas: the calldata cost simply moves from one dimension to another. No extra funds required.\nheader changes\nThe block header tracks data usage instead of blob gas:\n# Replace these fields:\nblob_gas_used → data_bytes_used # total DA in this block\nexcess_blob_gas → excess_data_bytes # for EIP-1559 pricing\n\nA first draft of the Unified Data Gas specification is available here.\n\ntwo orthogonal proposals\nHere’s the key insight: BiB and Unified Data Gas solve different problems.\n\nBiB\nUnified Data Gas\n\nProblem solved\nHow to make calldata DA-sampleable\nHow to bound total DA requirements\n\nMechanism\nEncoding (transactions → blobs)\nAccounting (one limit for all data)\n\nLayer affected\nCL (blob sidecars, commitments)\nEL (gas metering, intrinsic costs)\n\nCan exist alone?\nYes\nYes\n\nBiB without unified data gas still works: you just accept the additive worst case or introduce ad-hoc limits. This isn’t different to how the protocol works today.\nUnified data gas without BiB also works: it bounds total data but doesn’t enable DAS for transactions.\nTogether, they’re synergistic: BiB provides the encoding, unified data gas provides the accounting.\n\n A native zkEVM scales bandwidth, not just execution\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by junbyjun1238 on Apr 7\n\n junbyjun1238\n\n I found the object-by-object reasoning very helpful. What I’m especially curious about is whether there’s a more general placement principle behind it, since the local rationales seem to pull in different directions: e.g., BALs are execution-derived yet still need explicit availability, withdrawals are CL-derived, requests are reconstructible but consensus-relevant, and some values like slot-related metadata get pushed into the header partly for proving ergonomics.\nIs there a deeper rule you have in mind for what should live in blobs vs the bid/header vs what should simply remain reconstructible, or do you expect this to stay a case-by-case judgment as the zk-attester architecture matures?\n\n post by Nero_eth on Apr 8\n\n Nero_eth\n\n Yeah, good question, I’ve asked myself the same.\nIt’s not fully clear to me yet, but I think we need to be careful not to over-couple things too early.\nIn particular, I’m not convinced we should commingle BALs with transactions at the encoding layer. BALs serve a different purpose than the data: they’re useful for nodes that want to maintain state (e.g. RPCs, inclusion list builders, or zk-attesters that track mempool/state dynamics). This suggests different consumers and potentially different access patterns.\nFor zk-attesters specifically, I can see multiple modes emerging:\n\nsome might just DAS everything and not care about structure,\nothers might only want the “pure data” (=txs bytes),\nothers might want the BAL with its state diff to maintain (a partial) state.\n\nGiven that, a one-size-fits-all encoding feels premature. It might make more sense to reason case-by-case about which roles we actually want in the protocol (validators, zk-attesters of different kinds, builders, RPCs, etc.), and then design it to cleanly support those, rather than forcing everything into a single blob layout upfront.\n\n post by junbyjun1238 on Apr 8\n\n junbyjun1238\n\n Forcing a one-size-fits-all encoding does feel premature at this stage. The missing abstraction might actually be relatively straightforward: same availability substrate, different public objects. Tx bytes, BALs, and other data could share the same DA guarantees without necessarily being collapsed onto a single encoding surface.\nThe separation itself isn’t the problem — the question is what governs which objects land where. The risk with a purely case-by-case placement rule is that it tends to optimize for whoever is easiest to satisfy first. Which is why I think there’s value in anchoring around a stronger invariant: any object whose withholding would materially narrow the set of parties able to independently reconstruct and continue the chain should remain explicitly available — even after consensus no longer requires it directly. Otherwise, you end up with something efficiently attestable but increasingly opaque as public infrastructure.\n\n post by bbjubjub2494 on Apr 8\n\n bbjubjub2494\n\n Neat research direction!\nIs it correct that if unified data gas is in place, there’s no longer any economic interest in issuing type-3 transactions as opposed to type-5? The pricing seems to be the same, or maybe a bit worse given BYTES_PER_BLOB.\n\nIn this case, we wouldn’t fold blob gas into data gas since data gas isn’t DAS’d, right?\n\n 3 months later\n\n post by thegaram33 on Jun 29\n\n thegaram33\n\n I’ve been building a prototype of Block-in-Blobs (EIP-8142) on ethrex and Lighthouse. We now have a local Kurtosis devnet running BiB end-to-end, plus integration into the EIP-8025 guest program.\nMain learnings so far:\n\nMoving KZG (or whatever pq-DA scheme replaces it) onto the Engine API adds latency, a potential liveness risk.\nBiB includes the BAL which cannot be serialized incrementally (it’s only fully known once the block is built). This complicates payload building and blob-count accounting.\nHow payload blobs should interact with the blob fee market is still an open research question.\n\nFull writeup: EIP-8142: Block-in-Blobs (BiB) — prototype writeup - HackMD — I’d love any questions or feedback, here or on HackMD.\n\n Powered by Discourse","tokens":5179,"squid":"ink-research","role":"Deep Scholar","at":1791264051824,"hash":"dceb6501a0fe92d48230dc44f5722a8f5590a290"}
{"url":"https://forum.openzeppelin.com/t/how-to-update-the-crowdsale-rate/5160/3","domain":"forum.openzeppelin.com","title":"How to update the crowdsale rate? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Dec 2020\n\n 3 / 4\n\n Dec 2020\n\n Dec 2020\n\n post by PradhumnaPancholi on Dec 23, 2020\n\n PradhumnaPancholi\n\n So, I have asked the same question before but I got stuck on something and it lead to more confusion. What was doing was adding “1000000000000000” to the rate to increase price by 0.001 ETH. But I realized that it doesn’t work like that. So, I did the math and found a different solution, that was to subtract 0.0014 from rate. Now, solidity has no way to handle decimals. How can I approach this ? Can rates be in decimal values?\n\n 2\n\n 2\n\n post by Skyge on Dec 24, 2020\n\n Skyge\n\n I am not sure what do you mean exactly, but I think if you want to increase the price of each purchase, you can change the rate like so:\ncontract CrowdSale {\n uint256 buyRate = 1e18;\n mapping(address => uint256) public _balance;\n\n function buyTokens() payable public {\n uint256 buyAmount = msg.value * 1e18 / buyRate;\n // TODO: buyAmount should be valid\n _balance[msg.sender] += buyAmount;\n buyRate += 0.0001e18;\n }\n}\n\nSo just like above, cause this is no decimals in the contract, so if you want to do it, you have got to multiply firstly, then divide, 1000 * 9 / 10 => 1000 * 0.9\n\n post by PradhumnaPancholi on Dec 24, 2020\n\n PradhumnaPancholi\n\n I am not sure if I follow. Can you give an example? is it possible to just increase price by 0.001 Eth on each purchase? Or are u talking about rate (asking to make sure on rate vs price)? Also, what is that 0.001e18? Does it meant 0.001 with 10^18 as in literally 0.001 eth? If that’s it than it will solve a big problem for me.\nP.S :- sorry for so many questions\n\n post by Skyge on Dec 24, 2020\n\n Skyge\n\n is it possible to just increase price by 0.001 Eth on each purchase?\nYes, at least, I think so, cause in my demo, I increase the price by the buyRate, so when buyRate is 1e18, it means 1 eth = 1 token, and when buyRate is equal to 1.001e18, it means 1.001 eth = 1 token, so the price increased.\nAlso, what is that 0.001e18? Does it meant 0.001 with 10^18 as in literally 0.001 eth?\nYeah, 0.001e18 is equal to 0.001eth.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Changing rate manually in a crowdsale\n\n Contracts\n\n crowdsale\n\n 5\n\n 982\n\n May 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to change rate/price of a token in Crowdsale?\n\n Contracts\n\n crowdsale\n\n 9\n\n 2.4k\n\n Jan 2022","tokens":672,"squid":"ink-security_audits","role":"Sentinel","at":1791264052103,"hash":"ca372c4624753a1ef3cf3876649fd80c2805b597"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-usdt-transfer-to-aave-address-on-arbitrum/25693/1","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum - Governance / General - Aave","text":"[RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 24\n\n 1 / 1\n\n Sep 24\n\n 12d ago\n\n post by Mark99 on Sep 24\n\n Mark99\n\n Hello Aave Governance,\nI would like to register my case for consideration in a future Aave Rescue Mission.\nI accidentally transferred 1070.21 USDT on Arbitrum from my Bitget exchange account directly to the following address:\nTransaction Hash:\n0x4486ddff52fe1c12976743a853b3470c08f0bb80d2ac8e1d5747905339fa6ba1\nNetwork:\nArbitrum One\nToken:\nUSDT\nAmount:\n10 USDT\nRecipient Address:\n0x7fc66500c84a76ad7e9c93437bfc5ac33e2ddae9\nThe transfer was made by mistake while attempting to transfer funds in connection with Aave. The address entered was an Aave-related address, but the USDT were transferred directly to this address on the Arbitrum network.\nThe withdrawal originated from my Bitget account. Therefore, I understand that the blockchain sender address may be a Bitget-controlled withdrawal/hot-wallet address rather than a wallet that I personally control.\nRecovery Request\nI kindly ask Aave Governance, BGD Labs and the relevant technical contributors to review whether these USDT can technically be recovered and included in a future Rescue Mission.\nIf recovery is possible, I explicitly agree that the funds may be returned to the original sender address recorded in the transaction, even if that address is controlled by Bitget.\nI can then work with Bitget Support and provide the original withdrawal records, transaction hash and account information so that Bitget can identify the returned funds and credit them back to my account.\nI understand that recovery may not be technically possible and that any recovery would be subject to the Aave Governance process. I would nevertheless greatly appreciate confirmation as to whether the destination address on Arbitrum is controlled by Aave or otherwise recoverable.\nI am happy to provide any additional information or proof of the original Bitget withdrawal if required.\nThank you very much for reviewing my case and for considering it for a future Rescue Mission.\nKind regards\nMarkus\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 142\n\n Jul 20\n\n [Recovery Request] Accidental Direct USDT Transfer to Aave Contract on Celo — rescueTokens Assistance Needed\n\n Other\n\n 0\n\n 112\n\n Jun 22","tokens":704,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264054938,"hash":"8befdb82469aafb9a971c9add907e9cd86291ed9"}
{"url":"https://ethresear.ch/c/zk-s-nt-arks/13/l/latest","domain":"ethresear.ch","title":"Latest zk-s[nt]arks topics - Ethereum Research","text":"Latest topics in zk-s[nt]arks\n\n zk-s[nt]arks\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the zk-s[nt]arks category\n\n For your posts on ZK-Snarks and ZK-Starks.\n\n 0\n\n 3.3k\n\n Dec 2017\n\n Atomic ZK-Proof-Gated Settlement for x402 Agent Payments: A Measured Reference Design\n\n 3\n\n 322\n\n 20d\n\n Proof boundaries in a minimal homomorphic tally for token weighted voting\n\n governance\n\n 0\n\n 78\n\n Aug 27\n\n Arcanum: a privacy-first compiler layer for source code — TEE now, ZK as the long-term foundation\n\n security\n\n 12\n\n 326\n\n Aug 10\n\n Qingming-STARK-G64: a Goldilocks STARK backend on AMD ROCm/HIP\n\n 0\n\n 66\n\n Jul 9\n\n Qingming-g64-ntt-cuda: RTX4090-24G results for native Goldilocks/G64 STARK-LDE NTT\n\n 2\n\n 80\n\n Jul 6\n\n Qingming-g64-ntt: Native Goldilocks/G64 GPU NTT at 2^27 on RX 7900 XTX, and a reproducible benchmark plan\n\n 0\n\n 81\n\n Jul 6\n\n What if post-quantum Ethereum doesn’t need signatures at all?\n\n post-quantum\n\n 17\n\n 1.2k\n\n Jul 2\n\n Designing Infrastructure Where Exploits Destroy Themselves\n\n governance\n\n 0\n\n 142\n\n Jul 2\n\n Blocks Are Dead. Long Live Blobs\n\n zk-roll-up\n\n 5\n\n 712\n\n Jun 29\n\n MACI and group bribe attacks\n\n governance\n\n 5\n\n 2.3k\n\n Jun 25\n\n EVM Verification of WHIR over a 31-bit Field\n\n post-quantum\n\n 0\n\n 307\n\n May 21\n\n WHIR for Ethereum\n\n 1\n\n 1.8k\n\n May 20\n\n Reducing the verification cost of a SNARK through hierarchical aggregation\n\n 12\n\n 10.0k\n\n Apr 29\n\n Folding over quartic extensions in 2N-4 multiplications, and why row-based commitment layers can’t keep up\n\n 0\n\n 85\n\n Apr 7\n\n Where to download the perpeptual power of tau for bn254?\n\n 0\n\n 41\n\n Mar 31\n\n Cheon’s attack and its effect on the security of big trusted setups\n\n 31\n\n 9.5k\n\n Mar 31\n\n Does Ethereum have a zk-verifiability problem?\n\n 7\n\n 728\n\n Mar 12\n\n When L = D + pQ Is Not Enough: Exactness Repair for BN254 Wrappers\n\n 0\n\n 92\n\n Mar 8\n\n GKRFold: SumFold-based GKR Proof Compression\n\n 2\n\n 608\n\n Feb 26\n\n Fake GLV: You don’t need an efficient endomorphism to implement GLV-like scalar multiplication in SNARK circuits\n\n 9\n\n 2.2k\n\n Nov 2025\n\n Generating Pasta keypairs\n\n 4\n\n 431\n\n Jul 2025\n\n The Signal: Ethereum - Casper FFG Finality Proofs\n\n 0\n\n 219\n\n Jul 2025\n\n Distributed Proof Generation\n\n 0\n\n 352\n\n Jul 2025\n\n Censorable Tornado Cash\n\n 7\n\n 904\n\n Jun 2025\n\n Vocdoni Protocol: Enabling Decentralized Voting for the Masses with ZK Technology\n\n zk-roll-up,governance\n\n 10\n\n 2.1k\n\n Jan 2025\n\n Zero-knowledge proofs of identity using electronic passports\n\n 23\n\n 8.6k\n\n Dec 2024\n\n Efficient ECDSA signature verification using Circom\n\n 9\n\n 7.6k\n\n Dec 2024\n\n Lookup singularity via MMR\n\n 8\n\n 3.6k\n\n Dec 2024\n\n Prover time comparison of GKR+Groth16 vs. Groth16 for proving MiMC hashes\n\n zk-roll-up\n\n 18\n\n 7.5k\n\n Dec 2024","tokens":691,"squid":"ink-research","role":"Deep Scholar","at":1791264063522,"hash":"c7677e50eac6e28d492066afb1983898aed1fa7b"}
{"url":"https://specs.optimism.io/governance/gov-token.html","domain":"specs.optimism.io","title":"Governance Token - OP Stack Specification","text":"Governance Token\n\nTable of Contents\n\nOverview\n\nToken Minting\nToken Burning\nVoting Power\n\nPublic Query Functions\n\nDelegation\n\nBasic Delegation\n\nOverview\nConstantsValue\nAddress0x4200000000000000000000000000000000000042\nToken nameOptimism\nToken symbolOP\nToken decimals18\n\nGovernanceToken is an ERC20 token contract that inherits from ERC20Burnable,\nERC20Votes, and Ownable. It allows token holders to delegate their voting power to other addresses, enabling a representative\nvoting system. The GovernanceToken currently only supports basic delegation whereby a user can delegate its entire token\nbalance to a specific address for voting and votes cannot be re-delegated.\nToken Minting\nGovernanceToken MUST have a mint(address,uint256) function with external visibility that allows the owner() address\nto mint an arbitrary number of new tokens to a specific address. This function MUST only be called by the contract\nowner, the MintManager, as enforced by the onlyOwner modifier inherited from the Ownable contract.\nToken Burning\nThe contract MUST allow token holders to burn their own tokens using the inherited burn(uint256) or\nburnFrom(address,uint256) functions inherited from ERC20Burnable. Burn functions MUST NOT allow a user's balance to\nunderflow and attempts to reduce balance below zero MUST revert.\nVoting Power\nEach token corresponds to one unit of voting power. Token holders who wish to utilize their tokens for voting MUST delegate\ntheir voting power to an address (can be their own address). An active delegation MUST NOT prevent a user from transferring\ntokens. The GovernanceToken contract MUST offer public accessor functions for querying voting power, as outlined below.\nPublic Query Functions\n\ncheckpoints(address,uint32) returns (Checkpoint)\n\nMUST retrieve the n-th Checkpoint for a given address.\n\nnumCheckpoints(address) returns (uint32)\n\nMUST retrieve the total number of Checkpoint objects for a given address.\n\ndelegates(address) returns (address)\n\nMUST retrieve the address that an account is delegating to.\n\ngetVotes() returns (uint256)\n\nMUST retrieve the current voting power of an address.\n\ngetPastVotes(address,uint256) returns (uint256)\n\nMUST retrieve the voting power of an address at specific block number in the past.\n\ngetPastTotalSupply(uint256) returns (uint256)\n\nMUST return the total token supply at a specific block number in the past.\n\nDelegation\nBasic Delegation\nVote power can be delegated either by calling the delegate(address) function directly (to delegate as the msg.sender)\nor by providing a signature to be used with function delegateBySig(address,uint256,uint256,uint8,bytes32,bytes32),\nas inherited from ERC20Votes. Delegation through these functions is considered \"basic delegation\" as these functions will\ndelegate the entirety of the user's available balance to the target address. Delegations cannot be re-delegated to another\naddress.","tokens":722,"squid":"ink-governance","role":"Council Listener","at":1791264080170,"hash":"073931f60939552b1deae3b7b3a91e3997922ac8"}
{"url":"https://ethresear.ch/t/maci-and-group-bribe-attacks/12939","domain":"ethresear.ch","title":"MACI and group bribe attacks - zk-s[nt]arks - Ethereum Research","text":"MACI and group bribe attacks \n\n zk-s[nt]arks\n\n governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 5\n min\n\n Jun 2022\n\n 1 / 6\n\n Jun 2022\n\n Jun 25\n\n post by josojo on Jun 25, 2022\n\n josojo\n\n MACI and collective bribes:\nMACI is a great infrastructure to prevent collusion for governance processes like voting. It offers a mechanism ensuring that no one can reliably bribe individuals.\nHowever, bribing does not have to target individuals directly: E.g. all actors could also be bribed as a collective to favor a particular outcome. This post describes the bribe attacks targeting collectives and investigates possible solutions.\nBribing the collective\nImagine the usual MACI setup is given. We have a registry R that contains n public keys K_1,…,K_n𝐾1,…,𝐾𝑛 that are allowed to vote.\nThe bribing party will deploy a bribe contract that grants every public key of R a bribe b_i𝑏𝑖, if the briber’s preferred vote outcome wins.\nThe bribe contract can be set up completely trust-less: It can get funded before the MACI process starts, it can read the MACI outcome via smart contract calls, and hence it can distribute the grants fully trustlessly.\nAssuming this bribe contract is deployed, each voter has an additional incentive to vote for the briber’s preferred outcome, to increase the chance of the payout.\nLet’s investigate the incentives and their impacts in case of a binary election: Each voter has the option to vote either for party A or party B and a 51% majority is needed to win the election.\nFor simplicity, it is assumed that each voter has an intrinsic motivation to vote for their preferred party over the other party, and this motivation or utility can be represented by a monetary value: v_i𝑣𝑖 for the i-th voter. Of course, there will be actors that are not influenced by monetary incentives, they will always vote for their preferred outcome and then their v_i 𝑣𝑖 might be infinity.\nNow, if b_i > v_i𝑏𝑖 >𝑣𝑖, the optimal economic strategy for the voter is to vote for the briber’s preferred party, to increase the likelihood of the higher bribe payout. Hence, the briber can choose his bribe b, such that v_i<b𝑣𝑖 <𝑏 for half of the i \\in 1..n𝑖 ∈1..𝑛\nIf the briber’s preferred party wins, the bribing cost must be at least \\Sigma_{i \\in n}b = n*bΣ𝑖∈𝑛𝑏 =𝑛 ∗𝑏. If v_i =v_j𝑣𝑖 =𝑣𝑗 for all i,j, this means that the bribing party has to buy out the whole utility of all voters to influence the vote.\nLet’s compare this to a non-MACI voting process: Let’s assume that bribing individuals would be possible and that the bribing party would only pay a bribe to voters that voted for their outcome. Since each voter has ~1/n 1/𝑛 chance of being pivotal and influencing the outcome, each voter’s personal expected-value from voting is v_i/n𝑣𝑖/𝑛. Hence, as long as v_i/n < b_i𝑣𝑖/𝑛 <𝑏𝑖, the optimal strategy is to vote for the briber’s preferred party. The total cost for the briber would be: n*(b_i/n) \\simeq b_i 𝑛 ∗(𝑏𝑖/𝑛) ≃𝑏𝑖, assuming v_i<b_i𝑣𝑖 <𝑏𝑖\nHence, under the bottom line, MACI has increased the bribe costs by a factor of n by eliminating individual bribes and only allowing collective bribes for this particular scenario. This is valuable, as an attacker has to roughly buy out the utility of all voters to influence the vote.\nHowever, there are still two problems in practice:\n\nSome applications can not guarantee that the sum of their voter’s utility is higher than the value that could be extracted from their decisions. For example, many future institutions might have only a utility U for normal soulbound token holders, but the institutions have to make decisions about transactions bigger than n*U. One concrete example could be a new decentralized arbitration system - like Kleros - governed by soulbound token holders. For these applications, it is necessary to improve the ratio between bribing costs, and voter’s utility.\nSome applications might have a huge set of participants for whom a particular governance decision has only low utility. In an extreme case, if half of the voters have only an \\epsilon𝜖 utility for a specific governance decision, then the bribing cost is still only \\epsilon *n𝜖 ∗𝑛 via collective bribes. This holds true, even if for the other half of voters, the utility of this governance process is very high, and they would be hard to bribe.\n\nCountering group bribe attacks:\nNext, let’s investigate how MACI can be improved to defend better against collective bribes. At first, one observes that for MACI processes with a public outcome, collective bribes can always be started in a trustless way, with the setup described above. Secondly, the bribe payout can be improved to prevent negative karma for bribed voters: By using technology – similar to tornado cash -, bribes can be paid to the participants in a non-trackable way by giving each public voter key the ability to claim their bribes into a new address in a non-trackable manner. This could be enabled by preparing for each voter a note (cf. tornado cash notes) which can only be claimed by a zk-proof that can only be generated with the private key of the voter.\nIn the context of soulbound tokens, this means that bribed soulbound tokens would not receive negative karma, as no one could prove that they misbehaved.\nSince collective bribes can not be easily prevented, in the following a method is proposed to increase the cost-factor of collective bribes compared to individual bribes beyond the sum of the utility of all voters. Fortunately, by introducing a small specification change, this can be archived:\nIncreasing the cost of group bribing attacks with fake voters:\nImagine the registry R contains not just the n public keys K_1,…,K_n𝐾1,…,𝐾𝑛 but also for each key K_i𝐾𝑖 a voting weight vector (w_{i1}, w_{i2}, … w_{in})(𝑤𝑖1,𝑤𝑖2,…𝑤𝑖𝑛) is given. The weights are non-public information and are only known by the maintainer of R and by the voting operator.\nAt the start, the registry R is empty. For adding new k𝑘 public keys to the registry, the maintainer would add s*k𝑠 ∗𝑘 accounts to the registry. The k*(s-1)𝑘 ∗(𝑠 −1) additional accounts will be fake accounts that have a voting weight vector of only zeros (0, … ,0)(0,…,0). This can be done in a trust-less manner: the operator could generate a zk-proof that (s-1)*k(𝑠 −1) ∗𝑘 of the added accounts have a zero voting weight vector.\nIn the setting of soulbound token, the determination and addition of weights could also happen in a trustless manner: E.g. for each non-zero weight of a newly added account, there could be the requirement for a verification process that outputs a zk-proof verifying the correctness of the weight addition. Via recursion, these proofs could be used to build an overall zk-proof verifying that all weights for a registry were updated correctly.\nThese proven properties must be NOT publicly known about the soulbound token holder and must be only shared with the operator. If the account holder shared these properties openly and would be able to prove certain properties to a bribing party, the account holder would get bribable and hence should be removed from the registry again. The voting weight vectors can then later be used arbitrarily by the voting algorithms.\nGiven this setup, imagine an attacker wants to start a collective bribe. Since an external attacker can not know who of the voters in the registry are fake voters, they have to bribe all voters in the registry. Hence, for n valid voters with positive voting weights, the briber has to bribe s*n𝑠 ∗𝑛 public keys. This increases the cost of collective bribing by a factor s𝑠, where s𝑠 is theoretically arbitrary large, but for sure will have practical limitations. If someone started a collective bribe, the registry maintainer should have access to all fake accounts and also claim the bribe rewards for the fake accounts, to incur a cost for the collective briber.\nThis approach is promising, as the collective bribes can be made arbitrarily ineffective by increasing the number s𝑠.\nHowever, this setup will only work, if the privacy of the real voters is guaranteed. If the voters are known or can be derived statistically, the protection will not work, as the briber can just bribe the collective of likely voters.\nThis is tricky in many applications: Image a DAO that wants to recruit their voters from the crowd of soulbound tokens holders that fulfill some criteria/metric. If the information about the criteria is public, then the briber can just bribe the soulbound addresses directly instead of the addresses in the registry R. Hence, each DAO has to source their voters from a huge set of potential accounts with non-public properties/information about these accounts. The information must be private, but still, this information must be verifiable to the registry R maintainer to facilitate the assignment of the correct voting weights.\nOpen questions\n\nAre there other ideas for protecting MACI setup from collective bribes? I am all ears!\n\nHow important is bribe resistance against bribes of the collective in practice?\n\nI am really curious about your thoughts.\n\n 2\n\n read \n\n 5\n min\n\n 4 years later\n\n post by hyeonleee on Jan 7\n\n hyeonleee\n\n Hello. Thanks for introducing the collective bribing attack. It’s brilliant.\nDo you have any advances after this research? e-voting is really complicaed to be safe than how it looks like X)\n\n 5 months later\n\n post by josojo on May 29\n\n josojo\n\n Sorry for the late reply:\nBut yeah, I think this collective bribery attack is possible.\nAt the same time, the proposed solution should also work:\nRegistry contains real voters plus many fake/public dummy keys.\n\nOnly the operator/maintainer knows which keys have positive weight.\n\nA briber who offers a collective bribe to all registry keys must pay fake voters too.\n\nThe maintainer claims fake bribes, making the attack expensive.\n\nThis can work against naive registry-wide bribes.\nThe key condition is exactly the one you noticed: the briber must not be able to distinguish real voting power from dummy entries.\nSo the construction’s value depends on hiding the eligibility signal. If real voters are externally identifiable — soulbound token holders, citizens, forum members, token holders, delegates, known Kleros jurors, etc. — then the briber can bypass the MACI registry and bribe the externally known population instead\n\n post by MaxBrych on Jun 1\n\n MaxBrych\n\n Amazing explanation! Thank you. I’m working on a e-voting on MACI with a 3-5 Shamir Split Multisig for the Coordinator, so the trust for the result doesn’t rely on a single Coordinator. But in a real life scenario we are experiencing onchain verified Citizens with a SBT that could be under age but are still eligible to vote because of owning the SBT. Have you thought about the a age restriction? I heard several times that proving age with a zk Proof is a very good use case but how would this work if someone fakes his birth date. Don’t expect a answer but I’m currently dealing with this problem.\n\n post by 71104 on Jun 1\n\n 71104\n\nChiming in to say that I’ve been thinking about this too, and the solution is quite complex because it involves zk-inference and therefore all the machinery that’s needed to make it work (notably TurboPLONK, GKR, and GPGPU proving).\nThe gist of it is: have the user scan their passport and encode a circuit that reads the MRZ from the picture. It’s a simple OCR, probably the simplest use case you can possibly think of when it comes to zk-inference.\nFTR I’m building my own zkSTARK engine and I’m currently working on the aforementioned technologies – well, I’m still working on TurboPLONK, but GPGPU proving is next. Feel free to DM me, I’m open to working together.\n\n 23 days later\n\n post by Dede-Qorqud on Jun 25\n\n Dede-Qorqud\n\n The fake voter idea is interesting. But… the trust question — the maintainer still knows which accounts are fake. In high-stakes governance that feels like a weak point worth thinking about.\nI wonder if dynamic weights could help here. If weights change continuously based on verifiable but private participant behaviour, statistical inference becomes much harder over time. The briber can’t target effectively if the target keeps moving.\nHas anyone looked at combining this with reputation-based weighting — where the weight itself is a ZK-proven property rather than a static assignment?\n\n Powered by Discourse","tokens":3105,"squid":"ink-research","role":"Deep Scholar","at":1791264085688,"hash":"e2131bd5d69fff59e650e77888d3d46772297e44"}
{"url":"https://specs.optimism.io/interop/eth-liquidity.html","domain":"specs.optimism.io","title":"ETH Liquidity - OP Stack Specification","text":"ETHLiquidity\n\nTable of Contents\n\nOverview\nConstants\nDefinitions\n\nETH Liquidity\nLiquidity Minting\nLiquidity Burning\n\nAssumptions\n\naEL-001: SafeSend correctly transfers ETH to recipients\n\nMitigations\n\nInvariants\n\niEL-001: ETH balance is always sufficient for minting / burning\n\nImpact\n\niEL-002: Only authorized contracts can call mint and burn\n\nImpact\n\niEL-003: Contract balance never overflows\n\nImpact\n\nFunction Specification\n\nmint\nburn\n\nEvents\n\nLiquidityMinted\nLiquidityBurned\n\nOverview\nThe ETHLiquidity contract is a predeploy that manages native ETH liquidity for cross-chain\ntransfers within the Superchain interop set. It works in conjunction with the\nSuperchainETHBridge to facilitate the movement of ETH between chains without requiring\nmodifications to the EVM to generate new ETH.\nThe contract is initialized with a very large balance (type(uint248).max wei) to ensure it can\nhandle all legitimate minting operations. This design allows the SuperchainETHBridge to have a\nguaranteed source of ETH liquidity on each chain, which is essential for the cross-chain ETH\ntransfer mechanism.\nConstants\nNameValue\nETHLiquidity Address0x4200000000000000000000000000000000000025\nInitial Balancetype(uint248).max wei\n\nDefinitions\nETH Liquidity\nETH Liquidity refers to the availability of native ETH on a particular chain. The ETHLiquidity\ncontract manages this liquidity by providing a mechanism to burn and mint ETH as needed for\ncross-chain transfers.\nLiquidity Minting\nLiquidity Minting is the process of withdrawing ETH from the ETHLiquidity contract. This\noperation is performed when ETH needs to be sent to a recipient on a destination chain as part of\na cross-chain transfer.\nLiquidity Burning\nLiquidity Burning is the process of depositing ETH into the ETHLiquidity contract. This operation\nis performed when ETH is being sent from a source chain to a destination chain as part of a\ncross-chain transfer.\nAssumptions\naEL-001: SafeSend correctly transfers ETH to recipients\nWe assume that the SafeSend mechanism correctly transfers ETH to recipients without reverting\nfor valid addresses.\nMitigations\n\nExtensive testing of the SafeSend mechanism\nAudits of the ETH transfer logic\n\nInvariants\niEL-001: ETH balance is always sufficient for minting / burning\nThe ETHLiquidity contract must always have enough ETH to fulfill all legitimate minting / burning\nrequests.\nImpact\nSeverity: Critical\nIf this invariant is broken, the cross-chain ETH transfer mechanism would fail, potentially leading\nto users being unable to receive their ETH on destination chains.\niEL-002: Only authorized contracts can call mint and burn\nThe mint and burn functions must only be callable by authorized contracts (specifically the\nSuperchainETHBridge).\nImpact\nSeverity: Critical\nIf this invariant is broken, unauthorized parties could mint ETH without burning an equivalent\namount on a source chain, leading to inflation.\niEL-003: Contract balance never overflows\nThe ETHLiquidity contract's balance must never overflow due to excessive burning operations.\nImpact\nSeverity: High\nIf this invariant is broken, the contract could reach an invalid state, potentially disrupting the\ncross-chain ETH transfer mechanism. The invariant that avoids overflow is maintained by\nSuperchainETHBridge, but could theoretically be broken by some future contract that is allowed to\nintegrate with ETHLiquidity. Maintainers should be careful to ensure that such future contracts\ndo not break this invariant.\nFunction Specification\nmint\nWithdraws ETH from the ETHLiquidity contract equal to the _amount and sends it to the\nmsg.sender.\nfunction mint(uint256 _amount) external\n\nMUST revert if called by any address other than the SuperchainETHBridge.\nMUST transfer the _amount of ETH to the msg.sender using SafeSend.\nMUST emit a LiquidityMinted event with the msg.sender and _amount.\n\nburn\nLocks ETH into the ETHLiquidity contract.\nfunction burn() external payable;\n\nMUST accept ETH via msg.value.\nMUST revert if called by any address other than the SuperchainETHBridge.\nMUST emit a LiquidityBurned event with the msg.sender and msg.value.\n\nEvents\nLiquidityMinted\nMUST be triggered when mint is called.\nevent LiquidityMinted(address indexed caller, uint256 value);\n\nLiquidityBurned\nMUST be triggered when burn is called.\nevent LiquidityBurned(address indexed caller, uint256 value);","tokens":1084,"squid":"ink-governance","role":"Council Listener","at":1791264090533,"hash":"481fc3b8c3235cb79e9e10c7aef576e56a32f42e"}
{"url":"https://forum.openzeppelin.com/t/fail-with-error-crowdsale-rate-is-0/32972/1","domain":"forum.openzeppelin.com","title":"Fail with error 'Crowdsale: rate is 0' - Smart Contracts - OpenZeppelin Forum","text":"Fail with error ‘Crowdsale: rate is 0’ \n\n Smart Contracts\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by Alexlemex on Nov 5, 2022\n\n Alexlemex\n\n Hello,\nas a beginner in solidity, I am writing to you to get some information about the error message which is the title of this topic \"Fail with error 'Crowdsale: rate is 0'\".\nI am trying to set up a crowdsale with a token with 8 decimal. The problem is that when I calculate the rate, if I understand correctly, it must be 10^-8 which is impossible to configure (I try to make 1TKN == $10-$15).\nHowever, I have already seen codes that allow the use of fractions to reduce the 18 decimal places.\n(Here is a link to a code with which I was able to tweak fractions and thus perform negative rates: https://github.com/bitfwdcommunity/ICO-tutorial/blob/master/ico-contract.sol).\nDo you think that with a code using Openzepplin it is possible to use negative rates?\nhere is my code (I use Remix.IDE):\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\";\n\ncontract MyCrowdsale is Crowdsale {\n\nconstructor(\n uint256 rate, // rate, in bits\n address payable wallet, // wallet to send Ether\n IERC20 token // the token\n\n)\n Crowdsale(rate, wallet, token)\n public\n{}\n}\n\nKind regards.\nAlex.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Setting up my crowdsale rate\n\n Smart Contracts\n\n crowdsale\n\n 1\n\n 951\n\n May 2022\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020\n\n Crowdsale test returns SafeMath Multiplication Overflow\n\n Contracts\n\n erc20,crowdsale\n\n 2\n\n 2.7k\n\n Aug 2019","tokens":495,"squid":"ink-security_audits","role":"Sentinel","at":1791264106646,"hash":"3d1f04d19e254bff91c8c99b84d2da3be1e61998"}
{"url":"https://specs.optimism.io/interop/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Derivation\n\nTable of Contents\n\nOverview\nInvariants\nActivation Block\nReplacing Invalid Blocks\nNetwork Upgrade Transactions\n\nDependency Set Conditional Transactions\nUpgrade Block Gas Limit\n\nExpiry Window\nSecurity Considerations\n\nDepositing an Executing Message\nExpiry Window\nReliance on History\n\nOverview\nNew derivation rules are added to guarantee integrity of cross chain messages.\nThe fork choice rule is updated to fork out unsafe blocks that contain invalid\nexecuting messages.\nInvariants\n\nAn executing message MUST have a corresponding initiating message\nThe initiating message referenced in an executing message MUST come from a chain in its dependency set\nA block MUST be considered invalid if it is built with any invalid executing messages\nThe block number n is > the activation block number, see Activation Block.\nThe timestamp t of the identifier MUST be:\n\nt <= execution_timestamp, where execution_timestamp is the timestamp of the block\nthat includes the executing message.\nt >= execution_timestamp - expiry_window, where expiry_window is the expiry window in seconds.\n\nL2 blocks that produce invalid executing messages MUST not be allowed to be considered safe.\nThey MAY optimistically exist as unsafe blocks for some period of time. An L2 block that is invalidated\nbecause it includes invalid executing messages MUST be replaced by a deposits only block at the same\nblock height. This guarantees progression of the chain, ensuring that an infinite loop of processing\nthe same block in the proof system is not possible.\nActivation Block\nThe activation block is the first block that has a timestamp higher or equal to the\nLagoon activation timestamp.\nThe activation block timestamp may not exactly match the Lagoon activation timestamp.\nThe genesis block is not technically considered an activation-block, as forks are already active.\nHowever, the genesis block does not contain transactions, and thus also meets the activation criteria.\nThe activation block has several special properties and constraints:\n\nIt MUST NOT include any non-deposit-type transactions.\nSequencers, when building the fork activation block, MUST set noTxPool to true\nin the execution payload attributes for this block, instructing the builder to exclude user transactions.\nMessages MUST NOT be executed in this block. This is implemented by only processing deposit-type transactions.\nAny contract log events MUST NOT count as valid initiating messages.\nVerifiers may use the activation block as an anchor point, without indexing the block-contents.\nThe derivation pipeline MUST enforce that the sequencer has not included any user transactions in\nthe batch covering the upgrade's activation block. If the sequencer includes any user transactions\nwithin the activation block, this block and the remaining span batch it originated from\n(if part of a span batch) MUST be dropped,\nfollowing the batch-dropping rules introduced in the\nHolocene upgrade span-batch rules.\n\nReplacing Invalid Blocks\nWhen the cross chain dependency resolution determines\nthat a block contains an invalid message, the block is replaced\nusing Holocene Replacement.\nThe replacement block has the same attributes, except the transaction list is trimmed\nto include only deposit transactions.\nNetwork Upgrade Transactions\nThe Lagoon activation timestamp defines the timestamp at which all functionality in this document is considered\nthe consensus rules for an OP Stack based network.\nOn the activation block, in addition to the L1 attributes deposit and potentially any user\ndeposits from L1, a set of deposit transaction-based upgrade transactions are deterministically generated by the\nderivation pipeline.\nThe contents of the transactions are defined by the file\nlagoon_nut_bundle.json\nin the monorepo, which contains 28 transactions. In addition to the contents of the file, the consensus layer node\nMUST prefix each intent string with Interop <index>: followed by a space, where <index> is the zero-based position\nof the transaction within the bundle. The prefix is the concept-level name Interop rather than the fork name\nLagoon, so that the derived upgrade deposit source hashes are\nunaffected by the fork rename.\nThese transactions can be classified into the following groups:\n\nImplementation Deployments: One transaction for each predeploy implementation being deployed, including the\nL2ContractsManager for this upgrade (27 total)\nUpgrade Execution: One transaction to call L2ProxyAdmin.upgradePredeploys(l2ContractsManagerAddress)\n\nMore information regarding the upgrade path implemented by the bundle transactions can be found in\nL2 Upgrade Execution.\nDependency Set Conditional Transactions\nA chain whose dependency set contains two or more chains wraps the bundle with two additional\ndeposit transactions in the same activation block, so that the L2ContractsManager applies the Interop-gated predeploy\nupgrades and the ETH liquidity pool is funded:\nPositionIntentGas limit\nBefore the bundleInterop pre: setFeature(INTEROP)100,000\nAfter the bundleInterop post: ETHLiquidity Funding50,000\n\nThe first transaction calls L1Block.setFeature(INTEROP), which the bundle's final upgradePredeploys call reads to\ndecide whether to apply the Interop-gated upgrades. The second funds\nETHLiquidity with a mint and value of type(uint128).max; it is the only Interop activation\ndeposit with a non-zero mint, and therefore cannot be expressed in the bundle format.\nA chain in a single-chain dependency set emits only the bundle's 28 transactions.\nUpgrade Block Gas Limit\nThe gas added to the activation block's gas limit is specified in\nCustom Upgrade Block Gas Limit.\nThe allocation for Lagoon MUST NOT vary with the dependency set: it always covers the two\nconditional transactions above, even for a chain that does not emit them.\nA chain in a single-chain dependency set therefore carries 150,000 gas of unused headroom in its activation block.\nThis is required because the allocation is subtracted again when reconstructing the system configuration from the\nactivation block, and that reconstruction has no access to the dependency set — see\nGas Allocation Specification.\nExpiry Window\nThe expiry window is the time period after which an initiating message is no longer considered valid.\nConstantValue\nEXPIRY_WINDOW604800 secs (7 days)\n\nSecurity Considerations\nDepositing an Executing Message\nDeposit transactions (force inclusion transactions) give censorship resistance to layer two networks.\nIf it were possible to deposit an invalid executing message, this would force the sequencer to reorg. It would\nbe fairly cheap to continuously deposit invalid executing messages through L1 and cause L2 liveness\ninstability, therefore deposits are prevented from triggering executing messages.\nExpiry Window\nThe expiry window ensures that the proof can execute in a reasonable amount of time. EIP-2935 introduced\nthe capability to traverse history with sub-linear complexity, however deep lookups remain expensive. App developers and\nusers, in the event that they encounter a message that has expired but has yet to be relayed, can\nresend the message in order to complete the process.\nReliance on History\nWhen fully executing historical blocks, a dependency on historical receipts from remote chains is present.\nEIP-4444 will eventually provide a solution for making historical receipts available without\nneeding to execute increasingly long chain histories.","tokens":1852,"squid":"ink-governance","role":"Council Listener","at":1791264110182,"hash":"b87226cd18e75b2a58302c8cc90f43b86e302de7"}
{"url":"https://specs.optimism.io/experimental/alt-da.html","domain":"specs.optimism.io","title":"Alt-DA - OP Stack Specification","text":"Alt-DA Mode\n\nTable of Contents\n\nOverview\nInput Commitment Submission\n\nExample Commitments\n\nDA Server\nData Availability Challenge Contract\n\nParameters\n\nDerivation\nFault Proof\n\nl2-input <commitment>\nl1-challenge-status <commitment> <blocknumber>\n\nSafety and Finality\nSecurity Considerations\n\nNote: Alt-DA Mode is a Beta feature of the MIT licensed OP Stack.\nWhile it has received initial review from core contributors, it is still undergoing testing,\nand may have bugs or other issues.\nOverview\nUsing Alt-DA mode means switching to an offchain data availability provider.\nThe protocol guarantees availability with a challenge contract on L1 where users\ncan challenge the availability of input data used to derive the chain.\nChallenging an input commitment means forcing providers to submit the input data on chain\nto prove the data is available during a time period. We call the period during which any party\ncan challenge a commitment challenge_window and the period during which any party\ncan submit the input data to resolve the challenge resolve_window.\nIf a challenge is not resolved by the time resolve_window of L1 blocks have passed,\nchain derivation must be reset, omitting the input data when rederiving therefore causing a reorg.\nInput Commitment Submission\nThe batching and compression of input data remain unchanged. When a batch is ready\nto be submitted to the inbox address, the data is uploaded to the DA storage layer instead, and a\ncommitment (specified below) is submitted as the batcher inbox transaction call data.\nCommitment txdata introduces version 1 to the transaction format, in order to interpret\nthe txdata as a commitment during the l1 retrieval step of the derivation pipeline:\nversion_bytetx_data\n1encoded_commitment\n\nThe derivationVersion0 byte is still prefixed to the input data stored in the DA provider so the frames\ncan be decoded downstream.\nCommitments are encoded as commitment_type_byte ++ commitment_bytes, where commitment_bytes depends\non the commitment_type_byte where [0, 128) are reserved for official implementations:\ncommitment_typecommitment\n0keccak256(tx_payload)\n1da-service\n\nThe da-service commitment is as follows: da_layer_byte ++ payload.\nThe DA layer byte must be initially restricted to the range [0, 127).\nThis specification will not apportion DA layer bytes, but different DA layers should coordinate to ensure that the\nDA layer bytes do not conflict. DA Layers can do so in\nthis discussion.\nThe payload is a bytestring which is up to the DA layer to specify.\nThe DA server should be able to parse the payload, find the data on the DA layer, and verify that the data returned\nfrom the DA layer matches what was committed to in the payload.\nThe batcher SHOULD cap input payloads to the maximum L1 tx size or the input will be skipped\nduring derivation. See derivation section for more details.\nThe batcher SHOULD NOT submit a commitment onchain unless input data was successfully stored on the service.\nIn addition, a DA provider storage service SHOULD return an error response if it is unable to properly\nstore the request payload so as to signal to the batcher to retry.\nInput commitments submitted onchain without proper storage on the DA provider service are subject to\nchallenges if the input cannot be retrieved during the challenge window, as detailed in the following section.\nExample Commitments\nversion_bytecommitment_typeda_layer_bytepayload\n0frames\n10keccak_commitment\n110eigenda_commitment\n110x0aavail_commitment\n110x0ccelestia_commitment\n11...altda_commitment\n\nDA Server\nInput data is uploaded to the storage layer via plain HTTP calls to the DA server.\nThis service is responsible to interacting with the Data Availability Layer (DA layer).\nThe layer could be a content addressable storage layer like IPFS or any S3 compatible storage\nor it could a specific DA focused blockchain.\nContent addressed systems like S3 should use the first put/<hex_encoded_commitment>\nbecause they can pre-compute the commitment.\nBlockchain based DA layers should use put and then submit the returned commitment to L1.\nBecause commitments can include the block height or hash, the commitment cannot be computed prior to submitting\nit to the DA Layer.\nAny DA provider can implement the following endpoints to receive and serve input data:\n\nRequest:\n POST /put/<hex_encoded_commitment>\n Content-Type: application/octet-stream\n Body: <preimage_bytes>\n\nResponse:\n 200 OK\n\nRequest:\n POST /put\n Content-Type: application/octet-stream\n Body: <preimage_bytes>\n\nResponse:\n 200 OK\n Content-Type: application/octet-stream\n Body: <hex_encoded_commitment>\n\nRequest:\n GET /get/<hex_encoded_commitment>\n\nResponse:\n 200 OK\n Content-Type: application/octet-stream\n Body: <preimage_bytes>\n\nData Availability Challenge Contract\nParameters\nConstantTypeDescription\nfixedResolutionCostuint256Fixed gas cost of resolving a challenge, set to 72925\nvariableResolutionCostuint256Upper limit gas cost per byte scaled by precision constant, set to 16640\nvariableResolutionCostPrecisionuint256Precision of the variable resolution cost, set to 1000\n\nVariableTypeDescription\nchallengeWindowuint256Number of L1 blocks whereby a commitment MAY be challenged after it's included onchain\nresolveWindowuint256Number of L1 blocks whereby input data SHOULD be submitted onchain after a challenge\nbondSizeuint256Bond amount in Wei posted by the challenger so that bondSize >= resolveCost\nresolverRefundFactoruint256Factor defining the portion of the resolving cost refunded to the resolver\n\nData availability is guaranteed via a permissionless challenge contract on the L1 chain.\nUsers have a set number of L1 blocks (challengeWindow) during which they are able to call\nthe challenge method of the contract with the following inputs:\nNote: Resolving Input Data through the Data Availability Challenge Contract is implemented\nonly for type=0 (keccak) commitments. This is because type=1 (da-service) commitments are designed to be\nhandled by a DA Server which is responsible for the mapping between commitment and input data.\nDue to this \"generic\" handling nature, there is currently no on-chain mechanism to verify commitments.\nfunction challenge(uint256 challengedBlockNumber, bytes calldata challengedCommitment) external payable\n\nThe L1 block number in which it was included.\nVersioned commitment bytes (i.e. 0 ++ keccak256(frame.. ))\n\nUsers with access to the input data then have another window of L1 blocks (resolveWindow)\nduring which they can submit it as calldata to the chain by calling the resolve method of the contract.\nIf the data is not included onchain by the time the resolve window is elapsed, derivation of the L2 canonical chain\nwill reorg starting from this first block derived from the challenged input data to the last block derived from the\nL1 block at which it expired. See more details about Derivation in the following section.\nfunction resolve(uint256 challengedBlockNumber, bytes calldata challengedCommitment, bytes calldata resolveData) external\n\nIn order to challenge a commitment, users deposit a bond amount where bond >= resolve_tx_gas_cost.\nIf the gas cost of resolving the challenge was lower than the bond, the difference is reimbursed to the challenger where\ncost = (fixedResolutionCost + preImageLength * variableResolutionCost / variableResolutionCostPrecision) * gasPrice\nand the rest of the bond is burnt. If the challenge is not resolved in time and expired,\nthe bond is returned and can be withdrawn by the challenger or used to challenge another commitment.\nbondSize can be updated by the contract owner similar to SystemConfig variables.\nSee Security Considerations for more details on bond management.\nThe state of all challenges can be read from the contract state or by syncing contract events.\nchallengeWindow and resolveWindow are constant values that currently cannot be changed\nunless the contract is upgraded. A dynamic window mechanism may be explored in the future.\nAny challenge with a properly encoded commitment, a bond amount associated with the challenger\naddress and a block number within the challenge window is accepted by the contract.\nHowever, a challenge is only valid if the commitment and block number pairing map to a valid commitment\nand its L1 origin block number during derivation. Challenges associated with an illegal commitment\nor block number will be ignored during derivation and have no impact on the state of the chain.\nThe contract is deployed behind an upgradable proxy so the address can be hardcoded in the rollup config\nfile and does not need to change. A future upgrade can add custom resolver functions to be chosen\ndynamically when a user calls the resolve function to support other alt DA solutions.\nDerivation\nInput data is retrieved during derivation of L2 blocks. The changes to the derivation pipeline\nwhen using the alt DA source are limited to wrapping the L1 based DataAvailabilitySource step\nin the pipeline with a module that enables pulling the data from the offchain DA source once\nwe've extracted the commitment from L1 DA.\nSimilarly to L1 based DA, for each L1 block we open a calldata source to retrieve the input commitments\nfrom the transactions and use each commitment with its l1 origin block number to resolve\nthe input data from the storage service. To enable smooth transition between alt-da and rollup mode, any L1 data\nretrieved from the batcher inbox that is not prefixed with txDataVersion1 is forwarded downstream\nto be parsed as input frames or skipped as invalid data.\nIn addition, we filter events from the DA Challenge contract included in the block\nand sync a local state of challenged input commitments. As the derivation pipeline steps through\nchallenge_window + resolve_window amount of L1 blocks, any challenge marked as active\nbecomes expired causing a reset of the derivation pipeline.\n// The status enum of a DA Challenge event\nenum ChallengeStatus {\n Uninitialized,\n Active,\n Resolved,\n Expired\n}\n\n// DA Challenge event filtered\nevent ChallengeStatusChanged(\n bytes indexed challengedCommitment, uint256 indexed challengedBlockNumber, ChallengeStatus status\n);\n\nDerivation can either be driven by new L1 blocks or restarted (reset) from the L1 origin of the last\nL2 safe head known by the execution engine. The model here is of weak subjectivity whereby a new node\ncoming onto the network can connect to at least 1 honest peer and sync blocks in the challenge_window\nto reconstruct the same state as the rest of the network. As with EIP-4844,\napplications SHOULD take on the burden of storing historical data relevant to themselves beyond\nthe challenge window.\nWhen stepping through new L1 origin blocks, input data is loaded from the DA storage service.\nIf the service responds with a 404 (not found) error, derivation stalls and the DA Manager\nstarts a detached traversal of new L1 blocks until:\n\nAn Active challenge event is found, detached L1 traversal continues:\n\nA Resolved challenge event is found: derivation continues with the input data submitted onchain.\nA high enough L1 block is reached such as latest_l1 - pipeline_l1_origin = resolve_window_size:\ninput data is skipped from the derivation output.\n\nData is never challenged, derivation returns critical error.\n\nWhen derivation is reset, the pipeline steps through previously seen L1 origins so that:\nsync_starting_point = latest_l1_block - (challenge_window_size + resolve_window_size + sequencer_window_size).\nIn that case, the DA manager has already synced the state of challenges during the range of L1 blocks traversed\nso the pipeline can either skip commitments with expired challenges and reorg the L2 chain\nor load input data from the resolving transaction calldata.\nIn addition, an expired challenge will reorg out [r_start, r_end] L2 blocks so that r_start is the first\nblock derived from the expired challenge's input and r_end the last L2 block derived before the pipeline\nwas reset.\nDerivation MUST skip input data such as input_data_size > MAX_L1_TX_SIZE where MAX_L1_TX_SIZE is a consensus\nconstant of 130672 bytes when commitment_type == 0. Different DA layers can potentially resolve the challenge\nwithout immediately loading all of the data onto L1 in a single transaction & therefore are exempt from this limit.\nIn theory MAX_L1_TX_SIZE could be increased up to (tx_gas_limit - fixed_resolution_cost) / dynamic_resolution_cost\nbased on the cost of resolving challenges in the contract implementation however to make challenging accessible\nit is capped based on geth's txMaxSize.\n130672 is chosen as 131072 - 400. Geth rejects transactions from the mempool with a total serialized size over 131072.\n400 bytes are allocated as overhead (signature, to address, metadata).\nFault Proof\nThe derivation pipeline is integrated with fault proofs by adding additional hint types to the\npreimage oracle in order to query the input data from the DA provider as well as onchain challenge status.\nl2-input <commitment>\nThe input data stored on the DA storage for the given <commitment>.\nl1-challenge-status <commitment> <blocknumber>\nThe status of the challenge for the given <commitment> at the given <blocknumber> on the L1\nDataAvailabilityChallenge contract.\nSafety and Finality\nSimilarly to rollup mode, the engine queue labels any new blocks derived from input data with a commitment\non the L1 chain as “safe”. Although labeled as “safe”, the chain might still reorg in case of a faulty DA provider\nand users must use the “finalized” label for a guarantee that their state cannot revert.\nWith Alt-DA mode on, the engine queue does receive finality signals from the L1 RPC AND\nfrom the DA manager that keeps track of challenges.\nThe DA manager maintains an internal state of all the input commitments in the current challengeWindow\nas they are validated by the derivation pipeline.\nThe L2 chain can be marked as finalized when the L1 block in which commitments can no longer be invalidated\nbecomes finalized. Without Alt-DA Mode, L2 blocks are safe when the batch is on L1. Plasma commitments are\nonly \"optimistically safe\" when the commitment is found in a L1 block. Commitments then become safe\nwhen that commitment can no longer be invalidated. Then finalization can proceed as normal: when the L1 block\nthat an L2 block is derived from becomes finalized, the L2 block can be marked as finalized.\nThe engine queue will maintain a longer buffer of L2 blocks waiting for the DA window to expire\nand the L1 block with the commitment to be finalized in order to signal finality.\nSecurity Considerations\nThe Data Availability Challenge contract mitigates DoS vulnerability with a payable bond requirement making\nchallenging the availability of a commitment at least as expensive as submitting the data onchain to resolve\nthe challenge.\nIn addition, the reward is not net positive for the fisherman\nwho forced the release of data by challenging thus preventing money pump vulnerability\nwhile still making challenging affordable to altruistic fishermen and users who desire to pay\nto guarantee data availability on L1.\nLastly, if needed a resolver_refund_factor can be dialed up such as resolver_refund_factor * resolving_cost\nis refunded to the resolver (where 0 <= refund_factor <= 1) while the rest of the bond is burnt.","tokens":3808,"squid":"ink-governance","role":"Council Listener","at":1791264120051,"hash":"5b9a3e543a0037fb8649a9a0d21736c0c3341d1a"}
{"url":"https://specs.optimism.io/experimental/contracts/safe/liveness-guard.html","domain":"specs.optimism.io","title":"LivenessGuard - OP Stack Specification","text":"LivenessGuard\n\nTable of Contents\n\nOverview\nDefinitions\n\nLiveness Timestamp\n\nAssumptions\nInvariants\n\ni01-001: Liveness tracking accuracy\n\nImpact\n\ni02-002: Liveness demonstration capability\n\nImpact\n\nFunction Specification\n\nconstructor\nsafe\ncheckTransaction\ncheckAfterExecution\nshowLiveness\n\nOverview\nThe LivenessGuard tracks the liveness of Safe multisig owners by recording timestamps when owners sign transactions or\nexplicitly demonstrate activity. It serves as a monitoring mechanism to identify inactive owners who may have lost\naccess to their keys.\nDefinitions\nLiveness Timestamp\nThe most recent block timestamp at which an owner either signed a Safe transaction or called the showLiveness\nfunction. This timestamp is publicly queryable via the lastLive mapping.\nAssumptions\nN/A\nInvariants\ni01-001: Liveness tracking accuracy\nOwner activity is accurately tracked and properly synchronized with the Safe's owner set.\nImpact\nSeverity: High\nIf liveness tracking is inaccurate, inactive owners could appear active (preventing their removal) or active owners\ncould appear inactive (enabling improper removal). This undermines the entire liveness monitoring mechanism and could\nlead to unauthorized changes to the Safe's owner set.\ni02-002: Liveness demonstration capability\nOwners are always capable of showing liveness if the owner is actually live. The guard never prevents legitimate owners\nfrom demonstrating their liveness through either transaction signatures or direct showLiveness calls.\nImpact\nSeverity: Critical\nIf legitimate owners cannot demonstrate liveness, they could be incorrectly identified as inactive and removed from the\nSafe. This could lead to loss of access to the Safe's assets and functionality, potentially causing permanent fund\nloss if enough owners are incorrectly removed.\nFunction Specification\nconstructor\nInitializes the LivenessGuard for a specific Safe contract and records all current owners with the deployment\ntimestamp.\nParameters:\n\n_safe: The Safe contract instance that this guard will monitor\n\nBehavior:\n\nMUST set the immutable SAFE reference to the provided Safe contract\nMUST query the Safe's current owner list via getOwners()\nMUST set lastLive[owner] to block.timestamp for each current owner\nMUST emit OwnerRecorded event for each current owner\n\nsafe\nReturns the Safe contract instance that this guard monitors.\nBehavior:\n\nMUST return the immutable SAFE contract reference\n\ncheckTransaction\nRecords liveness for owners who signed the current transaction. Called by the Safe before transaction execution.\nParameters:\n\n_to: Transaction target address\n_value: ETH value to send\n_data: Transaction calldata\n_operation: Operation type (Call or DelegateCall)\n_safeTxGas: Gas allocated for Safe transaction execution\n_baseGas: Gas costs independent of transaction execution\n_gasPrice: Gas price for refund calculation\n_gasToken: Token address for gas payment (zero address for ETH)\n_refundReceiver: Address receiving gas refund\n_signatures: Packed signature data from Safe owners\n_msgSender: Original transaction sender\n\nBehavior:\n\nMUST revert if caller is not the associated Safe contract\nMUST cache the current Safe owner list for comparison after transaction execution\nMUST reconstruct the transaction hash using Safe's getTransactionHash() with nonce decremented by 1\nMUST extract exactly threshold number of signers from _signatures using SafeSigners.getNSigners()\nMUST set lastLive[signer] to block.timestamp for each extracted signer\nMUST emit OwnerRecorded event for each signer\nMUST NOT revert due to signature parsing or owner extraction failures\n\ncheckAfterExecution\nUpdates the lastLive mapping to reflect any changes in the Safe's owner set. Called by the Safe after transaction\nexecution.\nParameters:\n\nFirst parameter (unnamed): Transaction hash (unused)\nSecond parameter (unnamed): Transaction success status (unused)\n\nBehavior:\n\nMUST revert if caller is not the associated Safe contract\nMUST query the current Safe owner list via getOwners()\nMUST process each current owner:\n\nIf owner existed before transaction execution, mark as processed\nIf owner did not exist before transaction execution, set lastLive[owner] to block.timestamp (new owner added)\n\nMUST process each owner that existed before but not after transaction execution:\n\nDelete lastLive[owner] entry (owner was removed from Safe)\n\nMUST ensure internal owner tracking state is completely cleared after execution\nMUST NOT revert due to owner set changes or state inconsistencies\n\nshowLiveness\nAllows a Safe owner to directly demonstrate liveness without signing a transaction.\nBehavior:\n\nMUST revert if caller is not a current owner of the Safe (verified via SAFE.isOwner())\nMUST set lastLive[msg.sender] to block.timestamp\nMUST emit OwnerRecorded event with msg.sender as the owner","tokens":1200,"squid":"ink-governance","role":"Council Listener","at":1791264129999,"hash":"35e96658828ba7d2321d51238dd7ec853c804067"}
{"url":"https://dev-forum.pyth.network/t/we-occasionally-encounter-an-error-when-generating-the-payload-using-this-function-update-price-feeds-with-funder/142/3","domain":"dev-forum.pyth.network","title":"We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2025\n\n 3 / 3\n\n May 2025\n\n May 2025\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n On our end, we are updating the Pyth price every 30 seconds by calling the following function:\n0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\nHowever, we occasionally encounter an error when generating the payload:\nFailed to generate a Pyth price payload: TypeError: fetch failed\n at node:internal/deps/undici/undici:13502:13\n at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n at async HermesClient.httpRequest (C:\\kanalabs\\perpetual repos\\liquidation-bot\\node_modules\\@pythnetwork\\hermes-client\\lib\\HermesClient.js:29:30) {\n [cause]: Error: getaddrinfo ENOTFOUND hermes-beta.pyth.network \n at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:120:26) {\n errno: -3008,\n code: 'ENOTFOUND',\n syscall: 'getaddrinfo',\n hostname: 'hermes-beta.pyth.network'\n }\n}\n\nHere is the code we are using:\nexport const updatePythPricePayload = async (marketId: string) => {\n try {\n const priceIds = [MARKET_PRICE_FEEDS[marketId]];\n const connection = new HermesClient(process.env.PYTH_HERMES_ENDPOINT!, {});\n const priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n });\n const binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n );\n const payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n } as InputEntryFunctionData;\n return payloadResponse;\n } catch (error: any) {\n console.log(\"Failed to update Pyth price payload: \", error);\n rollbar.error(\"Failed to update Pyth price payload.\", error);\n }\n};\n\nWe’ve set PYTH_HERMES_ENDPOINT=https://hermes-beta.pyth.network and APT_PRICE_FEED_ID=0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e.\nCould anyone please help us understand and resolve this issue?\n\n 2\n\n post by ali on May 8, 2025\n\n ali\n\n How often do you face this error? This happens when our service experiences a downtime and it is expected as it’s a beta service but shouldn’t happen often.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n I think it comes three times continuously and then goes back to get the data again\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 579\n\n May 2025\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Powered by Discourse","tokens":1651,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264131722,"hash":"b9e18aeb5b07de1f9416b55f37b7f9db7eb3633a"}
{"url":"https://dev-forum.pyth.network/t/i-am-getting-this-error-access-denied-hermes-beta-pyth-network-used-cloudflare-to-restrict-access/143","domain":"dev-forum.pyth.network","title":"I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n May 2025\n\n 1 / 5\n\n May 2025\n\n May 2025\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n I’m frequently encountering the following error when generating the payload using the update_price_feeds_with_funder function\n</html>\n\n at HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nFailed to update Pyth price payload: Error: HTTP error! status: 429, body: <!DOCTYPE html>\n<!--[if lt IE 7]> <html class=\"no-js ie6 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 7]> <html class=\"no-js ie7 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 8]> <html class=\"no-js ie8 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if gt IE 8]><!--> <html class=\"no-js\" lang=\"en-US\"> <!--<![endif]-->\n<head>\n<title>Access denied | hermes-beta.pyth.network used Cloudflare to restrict access</title>\n<meta charset=\"UTF-8\" />\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=Edge\" />\n<meta name=\"robots\" content=\"noindex, nofollow\" />\n<meta name=\"viewport\" content=\"width=device-width,initial-scale=1\" />\n<link rel=\"stylesheet\" id=\"cf_styles-css\" href=\"/cdn-cgi/styles/main.css\" />\n\nat HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nIt seems like the Hermes client is being rate-limited or blocked by Cloudflare, returning a 429 status code and an HTML response instead of the expected data. The error appears to originate from this part of the stack:\nCould someone please help investigate and resolve this issue ?\n\n 3\n\n 2\n\n post by ali on May 8, 2025\n\n ali\n\n The public hermes instances have rate limits (similar to this) but it is very generous and you shouldn’t normally hit it. I’m wondering how often you are hitting the endpoint that is resulting in ratelimit. If you want to get the data frequently I recommend using the streaming endpoint.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n Hi @ali\nHere’s the code we’re currently using:\nexport const updatePythPricePayload = async (marketId: string) => {\n try {\n const priceIds = [MARKET_PRICE_FEEDS[marketId]];\n const connection = new HermesClient(process.env.PYTH_HERMES_ENDPOINT!, {});\n const priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n });\n const binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n );\n const payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n } as InputEntryFunctionData;\n return payloadResponse;\n } catch (error: any) {\n console.log(\"Failed to update Pyth price payload: \", error);\n rollbar.error(\"Failed to update Pyth price payload.\", error);\n }\n};\n\nWe have configured the following environment variables:\n\nPYTH_HERMES_ENDPOINT=https://hermes-beta.pyth.network\nAPT_PRICE_FEED_ID=0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\n\nWe’re using three price feed IDs: APT, BTC, and ETH. Every 20 seconds, we fetch the payloads for all three feeds and submit the corresponding transactions.\nWe use the following function to update the prices:\n0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\nWe also have a function to update the funding rate. For this, we fetch data from https://hermes-beta.pyth.network for the same three price feed IDs and submit the transaction every 1 minute.\nLet me know if you need any further details.\n\n post by ali on May 8, 2025\n\n post by Ajay on May 8, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 479\n\n Aug 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Powered by Discourse","tokens":2032,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264144386,"hash":"9d2b42d1f1d265deee637dd44721fc262328515b"}
{"url":"https://ethereum.org/developers/docs/dapps/","domain":"ethereum.org","title":"Technical introduction to dapps | ethereum.org","text":"Technical introduction to dappsEdit page (opens in a new tab)A decentralized application (dapp) is an application built on a decentralized network that combines a smart contract and a frontend user interface. On Ethereum, smart contracts are accessible and transparent – like open APIs – so your dapp can even include a smart contract that someone else has written.\nPrerequisites\nBefore learning about dapps, you should cover the blockchain basics and read about the Ethereum network and how it's decentralized.\nDefinition of a dapp\nA dapp has its backend code running on a decentralized peer-to-peer network. Contrast this with an app where the backend code is running on centralized servers.\nA dapp can have frontend code and user interfaces written in any language (just like an app) to make calls to its backend. Furthermore, its frontend can get hosted on decentralized storage such as IPFS (opens in a new tab).\n\nDecentralized - dapps operate on Ethereum, an open public decentralized platform where no one person or group has control\nDeterministic - dapps perform the same function irrespective of the environment in which they get executed\nTuring complete - dapps can perform any action given the required resources\nIsolated - dapps are executed in a virtual environment known as Ethereum Virtual Machine so that if the smart contract has a bug, it won’t hamper the normal functioning of the blockchain network\n\nOn smart contracts\nTo introduce dapps, we need to introduce smart contracts – a dapp's backend for lack of a better term. For a detailed overview, head to our section on smart contracts.\nA smart contract is code that lives on the Ethereum blockchain and runs exactly as programmed. Once smart contracts are deployed on the network you can't change them. Dapps can be decentralized because they are controlled by the logic written into the contract, not an individual or company. This also means you need to design your contracts very carefully and test them thoroughly.\nBenefits of dapp development\n\nZero downtime – Once the smart contract is deployed on the blockchain, the network as a whole will always be able to serve clients looking to interact with the contract. Malicious actors, therefore, cannot launch denial-of-service attacks targeted towards individual dapps.\nPrivacy – You don’t need to provide real-world identity to deploy or interact with a dapp.\nResistance to censorship – No single entity on the network can block users from submitting transactions, deploying dapps, or reading data from the blockchain.\nComplete data integrity – Data stored on the blockchain is immutable and indisputable, thanks to cryptographic primitives. Malicious actors cannot forge transactions or other data that has already been made public.\nTrustless computation/verifiable behavior – Smart contracts can be analyzed and are guaranteed to execute in predictable ways, without the need to trust a central authority. This is not true in traditional models; for example, when we use online banking systems, we must trust that financial institutions will not misuse our financial data, tamper with records, or get hacked.\n\nDrawbacks of dapp development\n\nMaintenance – Dapps can be harder to maintain because the code and data published to the blockchain are harder to modify. It’s hard for developers to make updates to their dapps (or the underlying data stored by a dapp) once they are deployed, even if bugs or security risks are identified in an old version.\nPerformance overhead – There is a huge performance overhead, and scaling is really hard. To achieve the level of security, integrity, transparency, and reliability that Ethereum aspires to, every node runs and stores every transaction. On top of this, proof-of-stake consensus takes time as well.\nNetwork congestion – When one dapp uses too many computational resources, the entire network gets backed up. Currently, the network can only process about 10-15 transactions per second; if transactions are being sent in faster than this, the pool of unconfirmed transactions can quickly balloon.\nUser experience – It may be harder to engineer user-friendly experiences because the average end-user might find it too difficult to set up a tool stack necessary to interact with the blockchain in a truly secure fashion.\nCentralization – User-friendly and developer-friendly solutions built on top of the base layer of Ethereum might end up looking like centralized services anyways. For example, such services may store keys or other sensitive information server-side, serve a frontend using a centralized server, or run important business logic on a centralized server before writing to the blockchain. Centralization eliminates many (if not all) of the advantages of blockchain over the traditional model.\n\nMore of a visual learner?\nWhat is a dapp? Decentralized application on the blockchainAn introduction to decentralized applications (dapps) and how they differ from traditional apps.Watch with transcript \nTools for creating dapps\nScaffold-ETH 2 - Quickly experiment with Solidity using a frontend that adapts to your smart contract.\n\nGitHub (opens in a new tab)\nExample dapp (opens in a new tab)\n\nCreate Eth App - Create Ethereum-powered apps with one command.\n\nGitHub (opens in a new tab)\n\nOne Click Dapp - FOSS tool for generating dapp frontends from an .\n\noneclickdapp.com (opens in a new tab)\nGitHub (opens in a new tab)\n\nEtherflow - FOSS tool for Ethereum developers to test their node, and compose & debug RPC calls from the browser.\n\netherflow.quiknode.io (opens in a new tab)\nGitHub (opens in a new tab)\n\nthirdweb - SDKs in every language, smart contracts, tools, and infrastructure for web3 development.\n\nHomepage (opens in a new tab)\nDocumentation (opens in a new tab)\nGitHub (opens in a new tab)\n\nCrossmint - Enterprise-grade web3 development platform to deploy smart contracts, enable credit-card and cross chain payments, and use APIs to create, distribute, sell, store, and edit NFTs.\n\ncrossmint.com (opens in a new tab)\nDocumentation (opens in a new tab)\nDiscord (opens in a new tab)\n\nFurther reading\n\nExplore dapps\nThe Architecture of a Web 3.0 application (opens in a new tab) - Preethi Kasireddy\nA 2021 guide to decentralized applications (opens in a new tab) - LimeChain\nWhat Are Decentralized Apps? (opens in a new tab) - Gemini\nPopular dapps (opens in a new tab) - Alchemy\n\nKnow of a community resource that helped you? Edit this page and add it!\nRelated Topics\n\nIntroduction to the Ethereum stack\nDevelopment frameworks\n\nTutorials: Build apps and frontends on Ethereum\n\nUniswap-v2 Contract Walk-Through – An annotated walkthrough of the Uniswap v2 core contracts explaining how the AMM works.\nBuilding a user interface for your contract – How to build a modern React + wagmi frontend that connects to your smart contract.\nHello World Smart Contract for Beginners – Fullstack – End-to-end tutorial: write, deploy, and build a frontend for a simple smart contract.\nServer components and agents for web3 apps – How to write TypeScript server components that listen to blockchain events and respond with transactions.\nIPFS for decentralized user interfaces – How to host your dapp's frontend on IPFS for censorship resistance.","tokens":1806,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264144415,"hash":"0ac61bef113ba274471a3e09d80d63136bd09069"}
{"url":"https://ethereum.org/developers/docs/web2-vs-web3/","domain":"ethereum.org","title":"Web2 vs Web3 | ethereum.org","text":"Web2 vs Web3Edit page (opens in a new tab)Web2 refers to the version of the internet most of us know today. An internet dominated by companies that provide services in exchange for your personal data. Web3, in the context of Ethereum, refers to decentralized apps that run on the blockchain. These are apps that allow anyone to participate without monetising their personal data.\nLooking for a more beginner-friendly resource? See our introduction to web3.\nWeb3 benefits\nMany Web3 developers have chosen to build dapps because of Ethereum's inherent decentralization:\n\nAnyone who is on the network has permission to use the service – or in other words, permission isn't required.\nNo one can block you or deny you access to the service.\nPayments are built in via the native token, ether (ETH).\nEthereum is turing-complete, meaning you can program pretty much anything.\n\nPractical comparisons\nWeb2Web3Twitter can censor any account or tweetWeb3 tweets would be uncensorable because control is decentralizedPayment service may decide to not allow payments for certain types of workWeb3 payment apps require no personal data and can't prevent paymentsServers for gig-economy apps could go down and affect worker incomeWeb3 servers can't go down – they use Ethereum, a decentralized network of 1000s of computers as their backend\nThis doesn't mean that all services need to be turned into a dapp. These examples are illustrative of the main differences between web2 and web3 services.\nWeb3 limitations\nWeb3 has some limitations right now:\n\nScalability – transactions are slower on web3 because they're decentralized. Changes to state, like a payment, need to be processed by a node and propagated throughout the network.\nUX – interacting with web3 applications can require extra steps, software, and education. This can be a hurdle to adoption.\nAccessibility – the lack of integration in modern web browsers makes web3 less accessible to most users.\nCost – most successful dapps put very small portions of their code on the blockchain as it's expensive.\n\nCentralization vs decentralization\nIn the table below, we list some of the broad-strokes advantages and disadvantages of centralized and decentralized digital networks.\nCentralized SystemsDecentralized SystemsLow network diameter (all participants are connected to a central authority); information propagates quickly, as propagation is handled by a central authority with lots of computational resources.The furthest participants on the network may potentially be many edges away from each other. Information broadcast from one side of the network may take a long time to reach the other side.Usually higher performance (higher throughput, fewer total computational resources expended) and easier to implement.Usually lower performance (lower throughput, more total computational resources expended) and more complex to implement.In the event of conflicting data, resolution is clear and easy: the ultimate source of truth is the central authority.A protocol (often complex) is needed for dispute resolution, if peers make conflicting claims about the state of data which participants are meant to be synchronized on.Single point of failure: malicious actors may be able to take down the network by targeting the central authority.No single point of failure: network can still function even if a large proportion of participants are attacked/taken out.Coordination among network participants is much easier, and is handled by a central authority. Central authority can compel network participants to adopt upgrades, protocol updates, etc., with very little friction.Coordination is often difficult, as no single agent has the final say in network-level decisions, protocol upgrades, etc. In the worst case, network is prone to fracturing when there are disagreements about protocol changes.Central authority can censor data, potentially cutting off parts of the network from interacting with the rest of the network.Censorship is much harder, as information has many ways to propagate across the network.Participation in the network is controlled by the central authority.Anyone can participate in the network; there are no “gatekeepers.” Ideally, the cost of participation is very low.\nNote that these are general patterns that may not hold true in every network. Furthermore, in reality the degree to which a network is centralized/decentralized lies on a spectrum; no network is entirely centralized or entirely decentralized.\nFurther reading\n\nWhat is Web3? - ethereum.org\nThe Architecture of a Web 3.0 application (opens in a new tab) - Preethi Kasireddy\nThe Meaning of Decentralization (opens in a new tab) Feb 6, 2017 - Vitalik Buterin\nWhy Decentralization Matters (opens in a new tab) Feb 18, 2018 - Chris Dixon\nWhat Is Web 3.0 & Why It Matters (opens in a new tab) Dec 31, 2019 - Max Mersch and Richard Muirhead\nWhy We Need Web 3.0 (opens in a new tab) Sep 12, 2018 - Gavin Wood","tokens":1234,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264157299,"hash":"51c555845e965c61e229ff9a11aa30195287a348"}
{"url":"https://dev-forum.pyth.network/t/i-am-getting-this-error-access-denied-hermes-beta-pyth-network-used-cloudflare-to-restrict-access/143/2","domain":"dev-forum.pyth.network","title":"I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n May 2025\n\n 2 / 5\n\n May 2025\n\n May 2025\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n I’m frequently encountering the following error when generating the payload using the update_price_feeds_with_funder function\n</html>\n\n at HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nFailed to update Pyth price payload: Error: HTTP error! status: 429, body: <!DOCTYPE html>\n<!--[if lt IE 7]> <html class=\"no-js ie6 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 7]> <html class=\"no-js ie7 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 8]> <html class=\"no-js ie8 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if gt IE 8]><!--> <html class=\"no-js\" lang=\"en-US\"> <!--<![endif]-->\n<head>\n<title>Access denied | hermes-beta.pyth.network used Cloudflare to restrict access</title>\n<meta charset=\"UTF-8\" />\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=Edge\" />\n<meta name=\"robots\" content=\"noindex, nofollow\" />\n<meta name=\"viewport\" content=\"width=device-width,initial-scale=1\" />\n<link rel=\"stylesheet\" id=\"cf_styles-css\" href=\"/cdn-cgi/styles/main.css\" />\n\nat HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nIt seems like the Hermes client is being rate-limited or blocked by Cloudflare, returning a 429 status code and an HTML response instead of the expected data. The error appears to originate from this part of the stack:\nCould someone please help investigate and resolve this issue ?\n\n 3\n\n 2\n\n post by ali on May 8, 2025\n\n ali\n\n The public hermes instances have rate limits (similar to this) but it is very generous and you shouldn’t normally hit it. I’m wondering how often you are hitting the endpoint that is resulting in ratelimit. If you want to get the data frequently I recommend using the streaming endpoint.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n Hi @ali\nHere’s the code we’re currently using:\nexport const updatePythPricePayload = async (marketId: string) => {\n try {\n const priceIds = [MARKET_PRICE_FEEDS[marketId]];\n const connection = new HermesClient(process.env.PYTH_HERMES_ENDPOINT!, {});\n const priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n });\n const binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n );\n const payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n } as InputEntryFunctionData;\n return payloadResponse;\n } catch (error: any) {\n console.log(\"Failed to update Pyth price payload: \", error);\n rollbar.error(\"Failed to update Pyth price payload.\", error);\n }\n};\n\nWe have configured the following environment variables:\n\nPYTH_HERMES_ENDPOINT=https://hermes-beta.pyth.network\nAPT_PRICE_FEED_ID=0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\n\nWe’re using three price feed IDs: APT, BTC, and ETH. Every 20 seconds, we fetch the payloads for all three feeds and submit the corresponding transactions.\nWe use the following function to update the prices:\n0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\nWe also have a function to update the funding rate. For this, we fetch data from https://hermes-beta.pyth.network for the same three price feed IDs and submit the transaction every 1 minute.\nLet me know if you need any further details.\n\n post by ali on May 8, 2025\n\n ali\n\n I double checked the ratelimit and it’s 29 requests every 10 seconds and if you make 1 every 20 seconds it shouldn’t hit it. Can you double check your code? The part that you shared doesn’t seem to have any problem.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n Thanks @ali Let me check it thoroughly. I’ve added logs line by line, and I’ll share here if I find any differences.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 479\n\n Aug 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Powered by Discourse","tokens":2093,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264158642,"hash":"593c8c8b65772736066a82a870407afa3bfb9c0d"}
{"url":"https://ethereum.org/developers/docs/nodes-and-clients/","domain":"ethereum.org","title":"Nodes and clients | ethereum.org","text":"Nodes and clientsEdit page (opens in a new tab)Ethereum is a distributed network of computers (known as nodes) running software that can verify blocks and transaction data. The software must be run on your computer to turn it into an Ethereum node. There are two separate pieces of software (known as 'clients') required to form a node.\nPrerequisites\nYou should understand the concept of a peer-to-peer network and the basics of the EVM before diving deeper and running your own instance of an Ethereum client. Take a look at our introduction to Ethereum.\nIf you're new to the topic of nodes, we recommend first checking out our user-friendly introduction on running an Ethereum node.\nWhat are nodes and clients?\nA \"node\" is any instance of Ethereum client software that is connected to other computers also running Ethereum software, forming a network. A client is an implementation of Ethereum that verifies data against the protocol rules and keeps the network secure. A node has to run two clients: a consensus client and an execution client.\n\nThe execution client (also known as the Execution Engine, EL client or formerly the Eth1 client) listens to new transactions broadcasted in the network, executes them in EVM, and holds the latest state and database of all current Ethereum data.\nThe consensus client (also known as the Beacon Node, CL client or formerly the Eth2 client) implements the proof-of-stake consensus algorithm, which enables the network to achieve agreement based on validated data from the execution client. There is also a third piece of software, known as a 'validator' that can be added to the consensus client, allowing a node to participate in securing the network.\n\nThese clients work together to keep track of the head of the Ethereum chain and allow users to interact with the Ethereum network. The modular design with multiple pieces of software working together is called encapsulated complexity (opens in a new tab). This approach made it easier to execute The Merge seamlessly, makes client software easier to maintain and develop, and enables the reuse of individual clients, for example, in the layer 2 ecosystem.\n\nSimplified diagram of a coupled execution and consensus client.\nClient diversity\nBoth execution clients and consensus clients exist in a variety of programming languages developed by different teams.\nMultiple client implementations can make the network stronger by reducing its dependency on a single codebase. The ideal goal is to achieve diversity without any client dominating the network, thereby eliminating a potential single point of failure.\nThe variety of languages also invites a broader developer community and allows them to create integrations in their preferred language.\nLearn more about client diversity.\nWhat these implementations have in common is they all follow a single specification. Specifications dictate how the Ethereum network and blockchain functions. Every technical detail is defined and specifications can be found as:\n\nOriginally, the Ethereum Yellow Paper (opens in a new tab)\nExecution specs (opens in a new tab)\nConsensus specs (opens in a new tab)\nEIPs (opens in a new tab) implemented in various network upgrades\n\nTracking nodes in the network\nMultiple trackers offer a real-time overview of nodes in the Ethereum network. Note that due to the nature of decentralized networks, these crawlers can only provide a limited view of the network and might report different results.\n\nMap of nodes (opens in a new tab) by Etherscan\nEthernodes (opens in a new tab) by Bitfly\nNodewatch (opens in a new tab) by Chainsafe, crawling consensus nodes\nMonitoreth (opens in a new tab) - by MigaLabs, A distributed network monitoring tool\nWeekly Network Health Reports (opens in a new tab) - by ProbeLab, Using the Nebula crawler (opens in a new tab) and other tools\n\nNode types\nIf you want to run your own node, you should understand that there are different types of node that consume data differently. In fact, clients can run three different types of nodes: light, full and archive. There are also options of different sync strategies which enable faster synchronization time. Synchronization refers to how quickly it can get the most up-to-date information on Ethereum's state.\nFull node\nFull nodes do a block-by-block validation of the blockchain, including downloading and verifying the block body and state data for each block. There are different classes of full node - some start from the genesis block and verify every single block in the entire history of the blockchain. Others start their verification at a more recent block that they trust to be valid (e.g., Geth's 'snap sync'). Regardless of where the verification starts, full nodes only keep a local copy of relatively recent data (typically the most recent 128 blocks), allowing older data to be deleted to save disk space. Older data can be regenerated when it is needed.\n\nStores full blockchain data (although this is periodically pruned so a full node does not store all state data back to genesis)\nParticipates in block validation, verifies all blocks and states.\nAll states can be either retrieved from local storage or regenerated from 'snapshots' by a full node.\nServes the network and provides data on request.\n\nArchive node\nArchive nodes are full nodes that verify every block from genesis and never delete any of the downloaded data.\n\nStores everything kept in the full node and builds an archive of historical states. It is needed if you want to query something like an account balance at block #4,000,000, or simply and reliably test your own transactions set without validating them using tracing.\nThis data represents units of terabytes, which makes archive nodes less attractive for average users but can be handy for services like block explorers, wallet vendors, and chain analytics.\n\nSyncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical states but the full node is able to build them on demand.\nLearn more about Archive nodes.\nLight node\nInstead of downloading every block, light nodes only download block headers. These headers contain summary information about the contents of the blocks. Any other information the light node requires gets requested from a full node. The light node can then independently verify the data they receive against the state roots in the block headers. Light nodes enable users to participate in the Ethereum network without the powerful hardware or high bandwidth required to run full nodes. Eventually, light nodes might run on mobile phones or embedded devices. The light nodes do not participate in consensus (i.e., they cannot be validators), but they can access the Ethereum blockchain with the same functionality and security guarantees as a full node.\nLight clients are an area of active development for Ethereum and we expect to see new light clients for the consensus layer and execution layer soon.\nThere are also potential routes to providing light client data over the gossip network (opens in a new tab). This is advantageous because the gossip network could support a network of light nodes without requiring full nodes to serve requests.\nEthereum does not support a large population of light nodes yet, but light node support is an area expected to develop rapidly in the near future. In particular, clients like Nimbus (opens in a new tab), Helios (opens in a new tab), and LodeStar (opens in a new tab) are currently heavily focused on light nodes.\nWhy should I run an Ethereum node?\nRunning a node allows you to directly, trustlessly and privately use Ethereum while supporting the network by keeping it more robust and decentralized.\nBenefits to you\nRunning your own node enables you to use Ethereum in a private, self-sufficient and trustless manner. You don't need to trust the network because you can verify the data yourself with your client. \"Don't trust, verify\" is a popular blockchain mantra.\n\nYour node verifies all the transactions and blocks against consensus rules by itself. This means you don’t have to rely on any other nodes in the network or fully trust them.\nYou can use an Ethereum wallet with your own node. You can use dapps more securely and privately because you won't have to leak your addresses and balances to intermediaries. Everything can be checked with your own client. MetaMask (opens in a new tab), Frame (opens in a new tab), and many other wallets offer RPC-importing, allowing them to use your node.\nYou can run and self-host other services which depend on data from Ethereum. For example, this might be a Beacon Chain validator, software like layer 2, infrastructure, block explorers, payment processors, etc.\nYou can provide your own custom RPC endpoints. You could even offer these endpoints publicly to the community to help them avoid big centralized providers.\nYou can connect to your node using Inter-process Communications (IPC) or rewrite the node to load your program as a plugin. This grants low latency, which helps a lot, e.g., when processing a lot of data using web3 libraries or when you need to replace your transactions as fast as possible (i.e., frontrunning).\nYou can directly stake ETH to secure the network and earn rewards. See solo staking to get started.\n\nNetwork benefits\nA diverse set of nodes is important for Ethereum’s health, security and operational resiliency.\n\nFull nodes enforce the consensus rules so they can’t be tricked into accepting blocks that don't follow them. This provides extra security in the network because if all the nodes were light nodes, which don't do full verification, validators could attack the network.\nIn case of an attack which overcomes the crypto-economic defenses of proof-of-stake, a social recovery can be performed by full nodes choosing to follow the honest chain.\nMore nodes in the network result in a more diverse and robust network, the ultimate goal of decentralization, which enables a censorship-resistant and reliable system.\nFull nodes provide access to blockchain data for lightweight clients that depend on it. Light nodes don't store the whole blockchain, instead they verify data via the state roots in block headers. They can request more information from full nodes if they need it.\n\nIf you run a full node, the whole Ethereum network benefits from it, even if you don't run a validator.\nRunning your own node\nInterested in running your own Ethereum client?\nFor a beginner-friendly introduction visit our run a node page to learn more.\nIf you're more of a technical user, dive into more details and options on how to spin up your own node.\nAlternatives\nSetting up your own node can cost you time and resources but you don’t always need to run your own instance. In this case, you can use a third party API provider. For an overview of using these services, check out nodes as a service.\nIf somebody runs an Ethereum node with a public API in your community, you can point your wallets to a community node via Custom RPC and gain more privacy than with some random trusted third party.\nOn the other hand, if you run a client, you can share it with your friends who might need it.\nExecution clients\nThe Ethereum community maintains multiple open-source execution clients (previously known as 'Eth1 clients', or just 'Ethereum clients'), developed by different teams using different programming languages. This makes the network stronger and more diverse. The ideal goal is to achieve diversity without any client dominating to reduce any single points of failure.\nThis table summarizes the different clients. All of them pass client tests (opens in a new tab) and are actively maintained to stay updated with network upgrades.\nClientLanguageOperating systemsNetworksSync strategiesState pruningGeth (opens in a new tab)GoLinux, Windows, macOSMainnet, Sepolia, HoodiSnap, FullArchive, PrunedNethermind (opens in a new tab)C#, .NETLinux, Windows, macOSMainnet, Sepolia, HoodiSnap, Fast, FullArchive, PrunedBesu (opens in a new tab)JavaLinux, Windows, macOSMainnet, Sepolia, HoodiSnap, Fast, FullArchive, PrunedErigon (opens in a new tab)GoLinux, Windows, macOSMainnet, Sepolia, HoodiFullArchive, Prunedethrex (opens in a new tab)RustLinux, macOSMainnet, Sepolia, HoodiSnap, FullPrunedReth (opens in a new tab)RustLinux, Windows, macOSMainnet, Sepolia, HoodiFullArchive, PrunedEthereumJS (opens in a new tab) (beta)TypeScriptLinux, Windows, macOSSepolia, HoodiFullPruned\nFor more on supported networks, read up on Ethereum networks.\nEach client has unique use cases and advantages, so you should choose one based on your own preferences. Diversity allows implementations to be focused on different features and user audiences. You may want to choose a client based on features, support, programming language, or licences.\nBesu\nHyperledger Besu is an enterprise-grade Ethereum client for public and permissioned networks. It runs all of the Ethereum Mainnet features, from tracing to GraphQL, has extensive monitoring and is supported by ConsenSys, both in open community channels and through commercial SLAs for enterprises. It is written in Java and is Apache 2.0 licensed.\nBesu's extensive documentation (opens in a new tab) will guide you through all details on its features and setups.\nErigon\nErigon, formerly known as Turbo‐Geth, started as a fork of Go Ethereum oriented toward speed and disk‐space efficiency. Erigon is a completely re-architected implementation of Ethereum, currently written in Go but with implementations in other languages under development. Erigon's goal is to provide a faster, more modular, and more optimized implementation of Ethereum. It can perform a full archive node sync using around 2TB of disk space, in under 3 days.\nethrex\nethrex is a minimalist, modular Ethereum execution client written in Rust and developed by LambdaClass. It is built with zero-knowledge proving in mind, and the same codebase can run both as an L1 execution client and as a multi-prover ZK-Rollup (L2). It is dual licensed under the Apache 2.0 and MIT licenses.\nLearn more by reading the ethrex documentation (opens in a new tab) or checking out the ethrex GitHub repo (opens in a new tab).\nGo Ethereum\nGo Ethereum (Geth for short) is one of the original implementations of the Ethereum protocol. Currently, it is the most widespread client with the biggest user base and variety of tooling for users and developers. It is written in Go, fully open source and licensed under the GNU LGPL v3.\nLearn more about Geth in its documentation (opens in a new tab).\nNethermind\nNethermind is an Ethereum implementation created with the C# .NET tech stack, licensed with LGPL-3.0, running on all major platforms including ARM. It offers great performance with:\n\nan optimized virtual machine\nstate access\nnetworking and rich features like Prometheus/Grafana dashboards, seq enterprise logging support, JSON-RPC tracing, and analytics plugins.\n\nNethermind also has detailed documentation (opens in a new tab), strong dev support, an online community and 24/7 support available for premium users.\nReth\nReth (short for Rust Ethereum) is an Ethereum full node implementation that is focused on being user-friendly, highly modular, fast and efficient. Reth was originally built and driven forward by Paradigm, and is licensed under the Apache and MIT licenses.\nReth is production ready, and suitable for usage in mission-critical environments such as staking or high-uptime services. Performs well in use cases where high performance with great margins is required such as RPC, MEV, indexing, simulations, and P2P activities.\nLearn more by checking out the Reth Book (opens in a new tab), or the Reth GitHub repo (opens in a new tab).\nIn development\nThese clients are still in earlier stages of development and are not yet recommended for production use.\nEthereumJS\nThe EthereumJS Execution Client (EthereumJS) is written in TypeScript and composed of a number of packages, including core Ethereum primitives represented by the Block, Transaction, and Merkle-Patricia Trie classes and core client components including an implementation of the Ethereum Virtual Machine (EVM), a blockchain class, and the DevP2P networking stack.\nLearn more about it by reading its documentation (opens in a new tab)\nConsensus clients\nThere are multiple consensus clients (previously known as 'Eth2' clients) to support the consensus upgrades. They are responsible for all consensus-related logic including the fork-choice algorithm, processing attestations and managing proof-of-stake rewards and penalties.\nClientLanguageOperating systemsNetworksLighthouse (opens in a new tab)RustLinux, Windows, macOSBeacon Chain, Hoodi, Pyrmont, Sepolia, and moreLodestar (opens in a new tab)TypeScriptLinux, Windows, macOSBeacon Chain, Hoodi, Sepolia, and moreNimbus (opens in a new tab)NimLinux, Windows, macOSBeacon Chain, Hoodi, Sepolia, and morePrysm (opens in a new tab)GoLinux, Windows, macOSBeacon Chain, Gnosis, Hoodi, Pyrmont, Sepolia, and moreTeku (opens in a new tab)JavaLinux, Windows, macOSBeacon Chain, Gnosis, Hoodi, Sepolia, and moreGrandine (opens in a new tab)RustLinux, Windows, macOSBeacon Chain, Hoodi, Sepolia, and more\nLighthouse\nLighthouse is a consensus client implementation written in Rust under the Apache-2.0 license. It is maintained by Sigma Prime and has been stable and production-ready since Beacon Chain genesis. It is relied upon by various enterprises, staking pools and individuals. It aims to be secure, performant and interoperable in a wide range of environments, from desktop PCs to sophisticated automated deployments.\nDocumentation can be found in Lighthouse Book (opens in a new tab)\nLodestar\nLodestar is a production-ready consensus client implementation written in Typescript under the LGPL-3.0 license. It is maintained by ChainSafe Systems and is the newest of the consensus clients for solo-stakers, developers and researchers. Lodestar consists of a beacon node and validator client powered by JavaScript implementations of Ethereum protocols. Lodestar aims to improve Ethereum usability with light clients, expand accessibility to a larger group of developers and further contribute to ecosystem diversity.\nMore information can be found on the Lodestar website (opens in a new tab)\nNimbus\nNimbus is a consensus client implementation written in Nim under the Apache-2.0 license. It is a production-ready client in use by solo-stakers and staking pools. Nimbus is designed for resource efficiency, making it easy to run on resource-restricted devices and enterprise infrastructure with equal ease, without compromising stability or reward performance. A lighter resource footprint means the client has a greater margin of safety when the network is under stress.\nLearn more in Nimbus docs (opens in a new tab)\nPrysm\nPrysm is a full-featured, open source consensus client written in Go under the GPL-3.0 license. It features an optional webapp UI and prioritizes user experience, documentation, and configurability for both stake-at-home and institutional users.\nVisit Prysm docs (opens in a new tab) to learn more.\nTeku\nTeku is one of the original Beacon Chain genesis clients. Alongside the usual goals (security, robustness, stability, usability, performance), Teku specifically aims to comply fully with all the various consensus client standards.\nTeku offers very flexible deployment options. The beacon node and validator client can be run together as a single process, which is extremely convenient for solo stakers, or nodes can be run separately for sophisticated staking operations. In addition, Teku is fully interoperable with Web3Signer (opens in a new tab) for signing key security and slashing protection.\nTeku is written in Java and is Apache 2.0 licensed. It is developed by the Protocols team at ConsenSys that is also responsible for Besu and Web3Signer. Learn more in Teku docs (opens in a new tab).\nGrandine\nGrandine is a consensus client implementation, written in Rust under the GPL-3.0 license. It is maintained by the Grandine Core Team and is fast, high-performance and lightweight. It fits a wide range of stakers from solo stakers running on low-resource devices such as Raspberry Pi to large institutional stakers running tens of thousands of validators.\nDocumentation can be found in the Grandine Book (opens in a new tab)\nSynchronization modes\nTo follow and verify current data in the network, the Ethereum client needs to sync with the latest network state. This is done by downloading data from peers, cryptographically verifying their integrity, and building a local blockchain database.\nSynchronization modes represent different approaches to this process with various trade-offs. Clients also vary in their implementation of sync algorithms. Always refer to the official documentation of your chosen client for specifics on implementation.\nExecution layer sync modes\nThe execution layer may be run in different modes to suit different use cases, from re-executing the blockchain's world state to only syncing with the tip of the chain from a trusted checkpoint.\nFull sync\nA full sync downloads all blocks (including headers and block bodies) and regenerates the state of the blockchain incrementally by executing every block from genesis.\n\nMinimizes trust and offers the highest security by verifying every transaction.\nWith an increasing number of transactions, it can take days to weeks to process all transactions.\n\nArchive nodes perform a full sync to build (and retain) a complete history of the state changes made by every transaction in every block.\nFast sync\nLike a full sync, a fast sync downloads all blocks (including headers, transactions, and receipts). However, instead of re-processing the historical transactions, a fast sync relies on the receipts until it reaches a recent head, when it switches to importing and processing blocks to provide a full node.\n\nFast sync strategy.\nReduces processing demand in favor of bandwidth usage.\n\nSnap sync\nSnap syncs also verify the chain block-by-block. However, instead of starting at the genesis block, a snap sync starts at a more recent 'trusted' checkpoint that is known to be part of the true blockchain. The node saves periodic checkpoints while deleting data older than a certain age. These snapshots are used to regenerate state data as needed, rather than storing it forever.\n\nFastest sync strategy, currently default in Ethereum Mainnet.\nSaves a lot of disk usage and network bandwidth without sacrificing security.\n\nMore on snap sync (opens in a new tab).\nLight sync\nLight client mode downloads all block headers, block data, and verifies some randomly. Only syncs tip of the chain from the trusted checkpoint.\n\nGets only the latest state while relying on trust in developers and consensus mechanism.\nClient ready to use with current network state in a few minutes.\n\nNB Light sync does not yet work with proof-of-stake Ethereum - new versions of light sync should ship soon!\nMore on light clients\nConsensus layer sync modes\nOptimistic sync\nOptimistic sync is a post-merge synchronization strategy designed to be opt-in and backwards compatible, allowing execution nodes to sync via established methods. The execution engine can optimistically import beacon blocks without fully verifying them, find the latest head, and then start syncing the chain with the above methods. Then, after the execution client has caught up, it will inform the consensus client of the validity of the transactions in the Beacon Chain.\nMore on optimistic sync (opens in a new tab)\nCheckpoint sync\nA checkpoint sync, also known as weak subjectivity sync, creates a superior user experience for syncing a Beacon Node. It's based on assumptions of weak subjectivity which enables syncing the Beacon Chain from a recent weak subjectivity checkpoint instead of genesis. Checkpoint syncs make the initial sync time significantly faster with similar trust assumptions as syncing from .\nIn practice, this means your node connects to a remote service to download recent finalized states and continues verifying data from that point. The third party providing the data is trusted and should be picked carefully.\nMore on checkpoint sync (opens in a new tab)\nFurther reading\n\nEthereum 101 - Part 2 - Understanding Nodes (opens in a new tab) – Wil Barnes, 13 February 2019\nRunning Ethereum Full Nodes: A Guide for the Barely Motivated (opens in a new tab) – Justin Leroux, 7 November 2019\n\nRelated topics\n\nBlocks\nNetworks\n\nRelated tutorials\n\nTurn your Raspberry Pi 4 into a validator node just by flashing the MicroSD card – Installation guide – Flash your Raspberry Pi 4, plug in an ethernet cable, connect the SSD disk and power up the device to turn the Raspberry Pi 4 into a full Ethereum node running the execution layer (Mainnet) and / or the consensus layer (Beacon Chain / validator).","tokens":6221,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264167268,"hash":"62f2cb7a1d2c096a23add991bfa58dcd2aa5365f"}
{"url":"https://dev-forum.pyth.network/t/i-am-getting-this-error-access-denied-hermes-beta-pyth-network-used-cloudflare-to-restrict-access/143/5","domain":"dev-forum.pyth.network","title":"I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n May 2025\n\n 5 / 5\n\n May 2025\n\n May 2025\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n I’m frequently encountering the following error when generating the payload using the update_price_feeds_with_funder function\n</html>\n\n at HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nFailed to update Pyth price payload: Error: HTTP error! status: 429, body: <!DOCTYPE html>\n<!--[if lt IE 7]> <html class=\"no-js ie6 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 7]> <html class=\"no-js ie7 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 8]> <html class=\"no-js ie8 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if gt IE 8]><!--> <html class=\"no-js\" lang=\"en-US\"> <!--<![endif]-->\n<head>\n<title>Access denied | hermes-beta.pyth.network used Cloudflare to restrict access</title>\n<meta charset=\"UTF-8\" />\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=Edge\" />\n<meta name=\"robots\" content=\"noindex, nofollow\" />\n<meta name=\"viewport\" content=\"width=device-width,initial-scale=1\" />\n<link rel=\"stylesheet\" id=\"cf_styles-css\" href=\"/cdn-cgi/styles/main.css\" />\n\nat HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nIt seems like the Hermes client is being rate-limited or blocked by Cloudflare, returning a 429 status code and an HTML response instead of the expected data. The error appears to originate from this part of the stack:\nCould someone please help investigate and resolve this issue ?\n\n 3\n\n 2\n\n post by ali on May 8, 2025\n\n ali\n\n The public hermes instances have rate limits (similar to this) but it is very generous and you shouldn’t normally hit it. I’m wondering how often you are hitting the endpoint that is resulting in ratelimit. If you want to get the data frequently I recommend using the streaming endpoint.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n Hi @ali\nHere’s the code we’re currently using:\nexport const updatePythPricePayload = async (marketId: string) => {\n try {\n const priceIds = [MARKET_PRICE_FEEDS[marketId]];\n const connection = new HermesClient(process.env.PYTH_HERMES_ENDPOINT!, {});\n const priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n });\n const binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n );\n const payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n } as InputEntryFunctionData;\n return payloadResponse;\n } catch (error: any) {\n console.log(\"Failed to update Pyth price payload: \", error);\n rollbar.error(\"Failed to update Pyth price payload.\", error);\n }\n};\n\nWe have configured the following environment variables:\n\nPYTH_HERMES_ENDPOINT=https://hermes-beta.pyth.network\nAPT_PRICE_FEED_ID=0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\n\nWe’re using three price feed IDs: APT, BTC, and ETH. Every 20 seconds, we fetch the payloads for all three feeds and submit the corresponding transactions.\nWe use the following function to update the prices:\n0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\nWe also have a function to update the funding rate. For this, we fetch data from https://hermes-beta.pyth.network for the same three price feed IDs and submit the transaction every 1 minute.\nLet me know if you need any further details.\n\n post by ali on May 8, 2025\n\n ali\n\n I double checked the ratelimit and it’s 29 requests every 10 seconds and if you make 1 every 20 seconds it shouldn’t hit it. Can you double check your code? The part that you shared doesn’t seem to have any problem.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n Thanks @ali Let me check it thoroughly. I’ve added logs line by line, and I’ll share here if I find any differences.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 479\n\n Aug 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Powered by Discourse","tokens":2093,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264168737,"hash":"dd7d87ea12bf1b1e34c53dc97a3a538d222e0ef7"}
{"url":"https://docs.soliditylang.org/en/develop/internals/layout_in_storage.html","domain":"docs.soliditylang.org","title":"Layout of State Variables in Storage and Transient Storage — Solidity 0.8.38-develop documentation","text":"Layout of State Variables in Storage and Transient Storage\n\n Edit on GitHub\n\nLayout of State Variables in Storage and Transient Storage\n\nNote\nThe rules described in this section apply for both storage and transient storage data locations.\nThe layouts are completely independent and don’t interfere with each other’s variable locations.\nThus storage and transient storage state variables can be safely interleaved without any side effects.\nOnly value types are supported for transient storage.\n\nState variables of contracts are stored in storage in a compact way such\nthat multiple values sometimes use the same storage slot.\nExcept for dynamically-sized arrays and mappings (see below), data is stored\ncontiguously item after item starting with the first state variable,\nwhich is stored in slot 0. For each variable,\na size in bytes is determined according to its type.\nMultiple, contiguous items that need less than 32 bytes are packed into a single\nstorage slot if possible, according to the following rules:\n\nThe first item in a storage slot is stored lower-order aligned.\nValue types use only as many bytes as are necessary to store them.\nIf a value type does not fit the remaining part of a storage slot, it is stored in the next storage slot.\nStructs and array data always start a new slot and their items are packed tightly according to these rules.\nItems following struct or array data always start a new storage slot.\n\nFor contracts that use inheritance, the ordering of state variables is determined by the\nC3-linearized order of contracts starting with the most base-ward contract. If allowed\nby the above rules, state variables from different contracts do share the same storage slot.\nThe elements of structs and arrays are stored after each other, just as if they were given\nas individual values.\nIf a contract specifies a custom storage layout, the slots assigned\nto static storage variables are shifted according the value defined as the layout base.\nLocations of dynamic arrays and mappings are also indirectly affected by this due to shifting\nof the static slots they are based on.\nThe custom layout is specified in the most derived contract and, following the order explained\nabove, starting from the most base-ward contract’s variables, all storage slots are adjusted.\nIn the following example, contract C inherits from contracts A and B and also\nspecifies a custom storage base slot.\nThe result is that all storage variable slots of the inheritance tree are adjusted according to\nthe value specified by C.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.29;\n\nstruct S {\n int32 x;\n bool y;\n}\n\ncontract A {\n uint a;\n uint128 transient b;\n uint constant c = 10;\n uint immutable d = 12;\n}\n\ncontract B {\n uint8[] e;\n mapping(uint => S) f;\n uint16 g;\n uint16 h;\n bytes16 transient i;\n S s;\n int8 k;\n}\n\ncontract C is A, B layout at 42 {\n bytes21 l;\n uint8[10] m;\n bytes5[8] n;\n bytes5 o;\n}\n\nIn the example, the storage layout starts with the inherited\nstate variable a stored directly inside the base slot (slot 42).\nTransient, constant and immutable variables are stored in separate\nlocations, and thus, b, i, c and d have no effect on the storage layout.\nThen we get to the dynamic array e and mapping f.\nThey both reserve a whole slot whose address will be used to calculate\nthe location where their data is actually stored.\nThe slot cannot be shared with any other variable, because the resulting addresses must be unique.\nThe next two variables, g and h, need 2 bytes each and can be packed together into\nslot 45, at offsets 0 and 2 respectively.\nSince s is a struct, its two members are packed contiguously, each taking up 5 bytes.\nEven though they both would still fit in slot 45, structs and arrays always start a new slot.\nTherefore, s is placed in slot 46 and the next variable, k, in slot 47.\nBase contracts, on the other hand, can share slots with derived ones, so l does not require an new one.\nThen variable m, which is an array of 10 items, gets into slot 48 and takes up 10 bytes.\nn is an array as well, but due to the size of its items, cannot fill its first slot perfectly\nand spills over to the next one.\nFinally, variable o ends up in slot 51, even though it is of the same type as items of n.\nAs explained before, variables after structs and arrays always start a new slot.\nPutting it all together, the storage and transient storage layouts of contract C can be illustrated as follows:\n\nStorage:\nopen in Remix\n42 [aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa]\n43 [eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee]\n44 [ffffffffffffffffffffffffffffffff]\n45 [ hhgg]\n46 [ yxxxx]\n47 [ lllllllllllllllllllllk]\n48 [ mmmmmmmmmm]\n49 [ nnnnnnnnnnnnnnnnnnnnnnnnnnnnnn]\n50 [ nnnnnnnnnn]\n51 [ ooooo]\n\nTransient storage:\nopen in Remix\n00 [iiiiiiiiiiiiiiiibbbbbbbbbbbbbbbb]\n\nNote that the storage specifier affects A and B only as a part of C’s inheritance hierarchy.\nWhen deployed independently, their storage starts at 0:\n\nStorage layout of A:\nopen in Remix\n00 [aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa]\n\nStorage layout of B:\nopen in Remix\n00 [eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee]\n01 [ffffffffffffffffffffffffffffffff]\n02 [ hhgg]\n03 [ yxxxx]\n04 [ k]\n\nWarning\nWhen using elements that are smaller than 32 bytes, your contract’s gas usage may be higher.\nThis is because the EVM operates on 32 bytes at a time. Therefore, if the element is smaller\nthan that, the EVM must use more operations in order to reduce the size of the element from 32\nbytes to the desired size.\nIt might be beneficial to use reduced-size types if you are dealing with storage values\nbecause the compiler will pack multiple elements into one storage slot, and thus, combine\nmultiple reads or writes into a single operation.\nIf you are not reading or writing all the values in a slot at the same time, this can\nhave the opposite effect, though: When one value is written to a multi-value storage\nslot, the storage slot has to be read first and then\ncombined with the new value such that other data in the same slot is not destroyed.\nWhen dealing with function arguments or memory\nvalues, there is no inherent benefit because the compiler does not pack these values.\nFinally, in order to allow the EVM to optimize for this, ensure that you try to order your\nstorage variables and struct members such that they can be packed tightly. For example,\ndeclaring your storage variables in the order of uint128, uint128, uint256 instead of\nuint128, uint256, uint128, as the former will only take up two slots of storage whereas the\nlatter will take up three.\n\nNote\nThe layout of state variables in storage is considered to be part of the external interface\nof Solidity due to the fact that storage pointers can be passed to libraries. This means that\nany change to the rules outlined in this section is considered a breaking change\nof the language and due to its critical nature should be considered very carefully before\nbeing executed. In the event of such a breaking change, we would want to release a\ncompatibility mode in which the compiler would generate bytecode supporting the old layout.\n\nMappings and Dynamic Arrays\nDue to their unpredictable size, mappings and dynamically-sized array types cannot be stored\n“in between” the state variables preceding and following them.\nInstead, they are considered to occupy only 32 bytes with regards to the\nrules above and the elements they contain are stored starting at a different\nstorage slot that is computed using a Keccak-256 hash.\nAssume the storage location of the mapping or array ends up being a slot p\nafter applying the storage layout rules.\nFor dynamic arrays,\nthis slot stores the number of elements in the array (byte arrays and\nstrings are an exception, see below).\nFor mappings, the slot stays empty, but it is still needed to ensure that even if there are\ntwo mappings next to each other, their content ends up at different storage locations.\nArray data is located starting at keccak256(p) and it is laid out in the same way as\nstatically-sized array data would: One element after the other, potentially sharing\nstorage slots if the elements are not longer than 16 bytes. Dynamic arrays of dynamic arrays apply this\nrule recursively. The location of element x[i][j], where the type of x is uint24[][], is\ncomputed as follows (again, assuming x itself is stored at slot p):\nThe slot is keccak256(keccak256(p) + i) + floor(j / floor(256 / 24)) and\nthe element can be obtained from the slot data v using (v >> ((j % floor(256 / 24)) * 24)) & type(uint24).max.\nThe value corresponding to a mapping key k is located at keccak256(h(k) . p)\nwhere . is concatenation and h is a function that is applied to the key depending on its type:\n\nfor value types, h pads the value to 32 bytes in the same way as when storing the value in memory.\nfor strings and byte arrays, h(k) is just the unpadded data.\n\nIf the mapping value is a\nnon-value type, the computed slot marks the start of the data. If the value is of struct type,\nfor example, you have to add an offset corresponding to the struct member to reach the member.\nAs an example, consider the following contract:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract C {\n struct S { uint16 a; uint16 b; uint256 c; }\n uint x;\n mapping(uint => mapping(uint => S)) data;\n}\n\nLet us compute the storage location of data[4][9].c.\nThe position of the mapping itself is 1 (the variable x with 32 bytes precedes it).\nThis means data[4] is stored at keccak256(uint256(4) . uint256(1)). The type of data[4] is\nagain a mapping and the data for data[4][9] starts at slot\nkeccak256(uint256(9) . keccak256(uint256(4) . uint256(1))).\nThe slot offset of the member c inside the struct S is 1 because a and b are packed\nin a single slot. This means the slot for\ndata[4][9].c is keccak256(uint256(9) . keccak256(uint256(4) . uint256(1))) + 1.\nThe type of the value is uint256, so it uses a single slot.\n\nbytes and string\nbytes and string are encoded identically.\nIn general, the encoding is similar to bytes1[], in the sense that there is a slot for the array itself and\na data area that is computed using a keccak256 hash of that slot’s position.\nHowever, for short values (shorter than 32 bytes) the array elements are stored together with the length in the same slot.\nIn particular: if the data is at most 31 bytes long, the elements are stored\nin the higher-order bytes (left aligned) and the lowest-order byte stores the value length * 2.\nFor byte arrays that store data which is 32 or more bytes long, the main slot p stores length * 2 + 1 and the data is\nstored as usual in keccak256(p). This means that you can distinguish a short array from a long array\nby checking if the lowest bit is set: short (not set) and long (set).\n\nNote\nHandling invalidly encoded slots is currently not supported but may be added in the future.\nIf you are compiling via IR, reading an invalidly encoded slot results in a Panic(0x22) error.\n\nJSON Output\nThe storage (or transient storage) layout of a contract can be requested via\nthe standard JSON interface. The output is a JSON object containing two keys,\nstorage and types. The storage object is an array where each\nelement has the following form:\n{\n \"astId\": 2,\n \"contract\": \"fileA:A\",\n \"label\": \"x\",\n \"offset\": 0,\n \"slot\": \"0\",\n \"type\": \"t_uint256\"\n}\n\nThe example above is the storage layout of contract A { uint x; } from source unit fileA\nand\n\nastId is the id of the AST node of the state variable’s declaration\ncontract is the name of the contract including its path as prefix\nlabel is the name of the state variable\noffset is the offset in bytes within the storage slot according to the encoding\nslot is the storage slot where the state variable resides or starts. This\nnumber may be very large and therefore its JSON value is represented as a\nstring.\ntype is an identifier used as key to the variable’s type information (described in the following)\n\nThe given type, in this case t_uint256 represents an element in\ntypes, which has the form:\n{\n \"encoding\": \"inplace\",\n \"label\": \"uint256\",\n \"numberOfBytes\": \"32\",\n}\n\nwhere\n\nencoding how the data is encoded in storage, where the possible values are:\n\ninplace: data is laid out contiguously in storage (see above).\nmapping: Keccak-256 hash-based method (see above).\ndynamic_array: Keccak-256 hash-based method (see above).\nbytes: single slot or Keccak-256 hash-based depending on the data size (see above).\n\nlabel is the canonical type name.\nnumberOfBytes is the number of used bytes (as a decimal string).\nNote that if numberOfBytes > 32 this means that more than one slot is used.\n\nSome types have extra information besides the four above. Mappings contain\nits key and value types (again referencing an entry in this mapping\nof types), arrays have its base type, and structs list their members in\nthe same format as the top-level storage (see above).\n\nNote\nThe JSON output format of a contract’s storage layout is still considered experimental\nand is subject to change in non-breaking releases of Solidity.\n\nThe following example shows a contract and both its storage and transient storage layout,\ncontaining value and reference types, types that are encoded packed, and nested types.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.28;\ncontract A {\n struct S {\n uint128 a;\n uint128 b;\n uint[2] staticArray;\n uint[] dynArray;\n }\n\n uint x;\n uint transient y;\n uint w;\n uint transient z;\n\n S s;\n address addr;\n address transient taddr;\n mapping(uint => mapping(address => bool)) map;\n uint[] array;\n string s1;\n bytes b1;\n}\n\nStorage Layout\n{\n \"storage\": [\n {\n \"astId\": 15,\n \"contract\": \"fileA:A\",\n \"label\": \"x\",\n \"offset\": 0,\n \"slot\": \"0\",\n \"type\": \"t_uint256\"\n },\n {\n \"astId\": 19,\n \"contract\": \"fileA:A\",\n \"label\": \"w\",\n \"offset\": 0,\n \"slot\": \"1\",\n \"type\": \"t_uint256\"\n },\n {\n \"astId\": 24,\n \"contract\": \"fileA:A\",\n \"label\": \"s\",\n \"offset\": 0,\n \"slot\": \"2\",\n \"type\": \"t_struct(S)13_storage\"\n },\n {\n \"astId\": 26,\n \"contract\": \"fileA:A\",\n \"label\": \"addr\",\n \"offset\": 0,\n \"slot\": \"6\",\n \"type\": \"t_address\"\n },\n {\n \"astId\": 34,\n \"contract\": \"fileA:A\",\n \"label\": \"map\",\n \"offset\": 0,\n \"slot\": \"7\",\n \"type\": \"t_mapping(t_uint256,t_mapping(t_address,t_bool))\"\n },\n {\n \"astId\": 37,\n \"contract\": \"fileA:A\",\n \"label\": \"array\",\n \"offset\": 0,\n \"slot\": \"8\",\n \"type\": \"t_array(t_uint256)dyn_storage\"\n },\n {\n \"astId\": 39,\n \"contract\": \"fileA:A\",\n \"label\": \"s1\",\n \"offset\": 0,\n \"slot\": \"9\",\n \"type\": \"t_string_storage\"\n },\n {\n \"astId\": 41,\n \"contract\": \"fileA:A\",\n \"label\": \"b1\",\n \"offset\": 0,\n \"slot\": \"10\",\n \"type\": \"t_bytes_storage\"\n }\n ],\n \"types\": {\n \"t_address\": {\n \"encoding\": \"inplace\",\n \"label\": \"address\",\n \"numberOfBytes\": \"20\"\n },\n \"t_array(t_uint256)2_storage\": {\n \"base\": \"t_uint256\",\n \"encoding\": \"inplace\",\n \"label\": \"uint256[2]\",\n \"numberOfBytes\": \"64\"\n },\n \"t_array(t_uint256)dyn_storage\": {\n \"base\": \"t_uint256\",\n \"encoding\": \"dynamic_array\",\n \"label\": \"uint256[]\",\n \"numberOfBytes\": \"32\"\n },\n \"t_bool\": {\n \"encoding\": \"inplace\",\n \"label\": \"bool\",\n \"numberOfBytes\": \"1\"\n },\n \"t_bytes_storage\": {\n \"encoding\": \"bytes\",\n \"label\": \"bytes\",\n \"numberOfBytes\": \"32\"\n },\n \"t_mapping(t_address,t_bool)\": {\n \"encoding\": \"mapping\",\n \"key\": \"t_address\",\n \"label\": \"mapping(address => bool)\",\n \"numberOfBytes\": \"32\",\n \"value\": \"t_bool\"\n },\n \"t_mapping(t_uint256,t_mapping(t_address,t_bool))\": {\n \"encoding\": \"mapping\",\n \"key\": \"t_uint256\",\n \"label\": \"mapping(uint256 => mapping(address => bool))\",\n \"numberOfBytes\": \"32\",\n \"value\": \"t_mapping(t_address,t_bool)\"\n },\n \"t_string_storage\": {\n \"encoding\": \"bytes\",\n \"label\": \"string\",\n \"numberOfBytes\": \"32\"\n },\n \"t_struct(S)13_storage\": {\n \"encoding\": \"inplace\",\n \"label\": \"struct A.S\",\n \"members\": [\n {\n \"astId\": 3,\n \"contract\": \"fileA:A\",\n \"label\": \"a\",\n \"offset\": 0,\n \"slot\": \"0\",\n \"type\": \"t_uint128\"\n },\n {\n \"astId\": 5,\n \"contract\": \"fileA:A\",\n \"label\": \"b\",\n \"offset\": 16,\n \"slot\": \"0\",\n \"type\": \"t_uint128\"\n },\n {\n \"astId\": 9,\n \"contract\": \"fileA:A\",\n \"label\": \"staticArray\",\n \"offset\": 0,\n \"slot\": \"1\",\n \"type\": \"t_array(t_uint256)2_storage\"\n },\n {\n \"astId\": 12,\n \"contract\": \"fileA:A\",\n \"label\": \"dynArray\",\n \"offset\": 0,\n \"slot\": \"3\",\n \"type\": \"t_array(t_uint256)dyn_storage\"\n }\n ],\n \"numberOfBytes\": \"128\"\n },\n \"t_uint128\": {\n \"encoding\": \"inplace\",\n \"label\": \"uint128\",\n \"numberOfBytes\": \"16\"\n },\n \"t_uint256\": {\n \"encoding\": \"inplace\",\n \"label\": \"uint256\",\n \"numberOfBytes\": \"32\"\n }\n }\n}\n\nTransient Storage Layout\n{\n \"storage\": [\n {\n \"astId\": 17,\n \"contract\": \"fileA:A\",\n \"label\": \"y\",\n \"offset\": 0,\n \"slot\": \"0\",\n \"type\": \"t_uint256\"\n },\n {\n \"astId\": 21,\n \"contract\": \"fileA:A\",\n \"label\": \"z\",\n \"offset\": 0,\n \"slot\": \"1\",\n \"type\": \"t_uint256\"\n },\n {\n \"astId\": 28,\n \"contract\": \"fileA:A\",\n \"label\": \"taddr\",\n \"offset\": 0,\n \"slot\": \"2\",\n \"type\": \"t_address\"\n }\n ],\n \"types\": {\n \"t_address\": {\n \"encoding\": \"inplace\",\n \"label\": \"address\",\n \"numberOfBytes\": \"20\"\n },\n \"t_uint256\": {\n \"encoding\": \"inplace\",\n \"label\": \"uint256\",\n \"numberOfBytes\": \"32\"\n }\n }\n}","tokens":4231,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264173936,"hash":"57d3188978c61dd41a8637b498b6c3b8fe02259f"}
{"url":"https://ethereum.org/developers/docs/nodes-and-clients/light-clients/","domain":"ethereum.org","title":"Light clients | ethereum.org","text":"Light clientsEdit page (opens in a new tab)Running a full node is the most trustless, private, decentralized and censorship resistant way to interact with Ethereum. With a full node you keep your own copy of the blockchain that you can query instantly and you get direct access to Ethereum's peer-to-peer network. However, running a full node requires a significant amount of memory, storage and CPU. This means it is not feasible for everyone to run their own node. There are several solutions to this on the Ethereum roadmap, including statelessness, but they are several years away from being implemented. The answer in the near-term is to trade-off some of the benefits of running a full node for large performance improvements that allow nodes to run with very low hardware requirements. Nodes that make this trade-off are known as light nodes.\nWhat is a light client\nA light node is a node running light client software. Instead of keeping local copies of the blockchain data and independently verifying all the changes, they request the necessary data from some provider instead. The provider might be a direct connection to a full node or via some centralized RPC server. The data is then verified by the light node, allowing it to keep up with the head of the chain. The light node only processes block headers, only occasionally downloading the actual block contents. Nodes can vary in their lightness, depending upon the combinations of light and full client software they run. For example, the lightest configuration would be to run a light execution client and a light consensus client. It is also likely that many nodes will choose to run light consensus clients with full execution clients, or vice versa.\nHow do light clients work?\nWhen Ethereum started using a proof-of-stake based consensus mechanism, new infrastructure was introduced specifically to support light clients. The way it works is by randomly selecting a subset of 512 validators every 1.1 days to act as a sync committee. The sync committee signs the header of recent blocks. Each block header contains the aggregated signature of the validators in the sync committee and a \"bitfield\" that shows which validators signed and which did not. Each header also includes a list of validators expected to participate in signing the next block. This means a light client can quickly see that the sync committee has signed off on the data they receive, and they can also check that the sync committee is the genuine one by comparing the one they receive from the one they were told to expect in the previous block. In this way, the light client can keep updating its knowledge of the latest Ethereum block without actually downloading the block itself, just the header which contains summary information.\nOn the execution layer there is no single specification for a light execution client. The scope of a light execution client can vary from a \"light mode\" of a full execution client that has all the EVM and networking functionality of a full node but only verifies block headers, without downloading the associated data, or it can be a more stripped down client that relies heavily upon forwarding requests to an RPC provider to interact with Ethereum.\nWhy are light clients important?\nLight clients matter because they allow users to verify incoming data rather than blindly trusting that their data provider is correct and honest, while using just a tiny fraction of the computational resources of a full node. The data light clients receive can be checked against block headers that they know have been signed by at least 2/3 of a random set of 512 Ethereum validators. This is very strong evidence that the data is correct.\nThe light client only uses a tiny amount of computing power, memory and storage so it can be run on a mobile phone, embedded in an app or as part of a browser. Light clients are a way to make trust-minimized access to Ethereum just as frictionless as trusting a third-party provider.\nLet's take a simple example. Imagine you want to check your account balance. To do this you have to make a request to an Ethereum node. That node will check its local copy of the Ethereum state for your balance and return it to you. If you don't have direct access to a node, there are centralized operators that provide this data as a service. You can send a request to them, they check their node, and send the result back to you. The problem with this is that you then have to trust the provider to be giving you the correct information. You can never really know the information is correct if you can't verify it for yourself.\nA light client addresses this issue. You still request data from some external provider, but when you receive the data back it comes with a proof that your light node can check against the information it received in the block header. This means Ethereum is verifying the correctness of your data instead of some trusted operator.\nWhat innovations do light clients enable?\nThe primary benefit of light clients is enabling more people to access Ethereum independently with negligible hardware requirements and minimal reliance on third parties. This is good for users because they can verify their own data and it is good for the network because it increases the number and diversity of nodes that are verifying the chain.\nThe ability to run Ethereum nodes on devices with very small storage, memory and processing power is one of the major areas of innovation unlocked by light clients. Whereas today Ethereum nodes require a lot of computing resources, light clients could be embedded into browsers, run on mobile phones and perhaps even smaller devices such as smart watches. This means Ethereum wallets with embedded clients could run on a mobile phone. This means mobile wallets could be much more decentralized as they wouldn't have to trust centralized data providers for their data.\nAn extension of this is enabling internet of things (IoT) devices. A light client could be used to quickly prove ownership of some token balance or NFT, with all the security guarantees provided by the sync committees, triggering some action on an IoT network. Imagine a bicycle rental service (opens in a new tab) that uses an app with an embedded light client to quickly verify that you own the rental service's NFT and if so, unlocks a bicycle for you to ride away on!\nEthereum rollups would also benefit from light clients. One of the big problems for rollups has been hacks targeting the bridges that allow funds to transfer from Ethereum Mainnet to a rollup. One vulnerability is the oracles that rollups use to detect that a user has made a deposit into the bridge. If an oracle feeds bad data, they could trick the rollup into thinking there was a deposit to the bridge and to incorrectly release funds. A light client embedded in the rollup could be used to protect against corrupted oracles because the deposit into the bridge could come with a proof that can be verified by the rollup before releasing any tokens. The same concept could also be applied to other interchain bridges.\nLight clients could also be used to upgrade Ethereum wallets. Instead of trusting data provided from an RPC provider, your wallet could directly verify the data being presented to you using an embedded light client. This would add security to your wallet. If your RPC provider was dishonest and provided you with incorrect data, the embedded light client could tell you!\nWhat is the current state of light client development?\nThere are several light clients in development, including execution, consensus and combined execution/consensus light clients. These are the light client implementations we know of at the time of writing this page:\n\nLodestar (opens in a new tab): consensus light client in TypeScript\nHelios (opens in a new tab): combined execution and consensus light client in Rust\nGeth (opens in a new tab): light mode for execution client (in development) in Go\nNimbus (opens in a new tab): consensus light client in Nim\n\nTo our knowledge none of these are considered production-ready yet.\nThere is also a lot of work being done to improve the ways that light clients can access Ethereum data. Currently, light clients rely on RPC requests to full nodes using a client/server model, but in the future the data could be requested in a more decentralized way using a dedicated network such as the Portal Network (opens in a new tab) that could serve the data to light clients using a peer-to-peer gossip protocol.\nOther roadmap items such as Verkle trees and statelessness will eventually bring the security guarantees of light clients equal to those of full clients.\nFurther reading\n\nZsolt Felfodhi on Geth light clients (opens in a new tab)\nEtan Kissling on light client networking (opens in a new tab)\nEtan Kissling on light clients after The Merge (opens in a new tab)\nPiper Merriam: The winding road to functional light clients (opens in a new tab)","tokens":2242,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264177134,"hash":"163ff504da8dac4ead42236a9247e5f9340a916c"}
{"url":"https://dev-forum.pyth.network/t/unstable-hermes-api/356","domain":"dev-forum.pyth.network","title":"Unstable Hermes API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Unstable Hermes API \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 1 / 2\n\n Aug 2025\n\n Aug 2025\n\n post by KemarTiti on Aug 13, 2025\n\n KemarTiti\n\n Hi,\nI’ve been calling the Pyth public Hermes API (https://hermes.pyth.network/v2/updates/price/latest) from GCP in Singapore.\nIt used to be stable, but lately response times are highly unstable, sometimes over 1 minute, often exceeding 10 seconds.\nThe frequency of receiving data from websocket is also low. Is the server still healthy/stable? Do you have any suggestions on better regions or alternate endpoints to reduce latency?\nErrors continuously happened, not around specific time. I set a 10 sec hard limit timeout and found reaching this limit once / 5-minutes.\nSometimes, the Websocket also stops sending the latest price data. Public subscription too\n\n post by KemarTiti on Aug 13, 2025\n\n KemarTiti\n\n The first recommendation is to use a third-party node provider as well. You can find them here: https://docs.pyth.network/price-feeds/api-instances-and-providers/hermes#node-providers\nThe second recommendation would be using these nodes in other clusters.\nThese are all the three:\n\nhttps://hermes-stable-cyan.dourolabs.app/\nhttps://hermes-stable-green.dourolabs.app/\nhttps://hermes-stable-yellow.dourolabs.app/\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Hermes configuration\n\n Price Feeds\n\n 3\n\n 753\n\n Jun 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n Powered by Discourse","tokens":1373,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264178919,"hash":"9857edefb9bd65a5371cafbff5fb7a87b4a072ce"}
{"url":"https://docs.soliditylang.org/en/develop/using-the-compiler.html","domain":"docs.soliditylang.org","title":"Using the Compiler — Solidity 0.8.38-develop documentation","text":"Using the Compiler\n\n Edit on GitHub\n\nUsing the Compiler\n\nUsing the Commandline Compiler\n\nNote\nThis section does not apply to solcjs, not even if it is used in commandline mode.\n\nBasic Usage\nOne of the build targets of the Solidity repository is solc, the Solidity commandline compiler.\nUsing solc --help provides you with an explanation of all options. The compiler can produce various outputs, ranging from simple binaries and assembly over an abstract syntax tree (parse tree) to estimations of gas usage.\nIf you only want to compile a single file, you run it as solc --bin sourceFile.sol and it will print the binary. If you want to get some of the more advanced output variants of solc, it is probably better to tell it to output everything to separate files using solc -o outputDirectory --bin --ast-compact-json --asm sourceFile.sol.\n\nOptimizer Options\nBefore you deploy your contract, activate the optimizer when compiling using solc --optimize --bin sourceFile.sol.\nBy default, the optimizer will optimize the contract assuming it is called 200 times across its lifetime\n(more specifically, it assumes each opcode is executed around 200 times).\nIf you want the initial contract deployment to be cheaper and the later function executions to be more expensive,\nset it to --optimize-runs=1. If you expect many transactions and do not care for higher deployment cost and\noutput size, set --optimize-runs to a high number.\nThis parameter has effects on the following (this might change in the future):\n\nthe size of the binary search in the function dispatch routine\nthe way constants like large numbers or strings are stored\n\nBase Path and Import Remapping\nThe commandline compiler will automatically read imported files from the filesystem, but\nit is also possible to provide path redirects using prefix=path in the following way:\nsolc github.com/ethereum/dapp-bin/=/usr/local/lib/dapp-bin/ file.sol\n\nThis essentially instructs the compiler to search for anything starting with\ngithub.com/ethereum/dapp-bin/ under /usr/local/lib/dapp-bin.\nWhen accessing the filesystem to search for imports, paths that do not start with ./\nor ../ are treated as relative to the directories specified using\n--base-path and --include-path options (or the current working directory if base path is not specified).\nFurthermore, the part of the path added via these options will not appear in the contract metadata.\nFor security reasons the compiler has restrictions on what directories it can access.\nDirectories of source files specified on the command-line and target paths of\nremappings are automatically allowed to be accessed by the file reader, but everything\nelse is rejected by default.\nAdditional paths (and their subdirectories) can be allowed via the\n--allow-paths /sample/path,/another/sample/path switch.\nEverything inside the path specified via --base-path is always allowed.\nThe above is only a simplification of how the compiler handles import paths.\nFor a detailed explanation with examples and discussion of corner cases please refer to the section on\npath resolution.\n\nLibrary Linking\nIf your contracts use libraries, you will notice that the bytecode contains substrings of the form __$53aea86b7d70b31448b230b20ae141a537$__ (format was different <v0.5.0). These are placeholders for the actual library addresses.\nThe placeholder is a 34 character prefix of the hex encoding of the keccak256 hash of the fully qualified library name.\nThe bytecode file will also contain lines of the form // <placeholder> -> <fq library name> at the end to help\nidentify which libraries the placeholders represent. Note that the fully qualified library name\nis the path of its source file and the library name separated by :.\nYou can use solc as a linker meaning that it will insert the library addresses for you at those points:\nEither add --libraries \"file.sol:Math=0x1234567890123456789012345678901234567890 file.sol:Heap=0xabCD567890123456789012345678901234567890\" to your command to provide an address for each library (use commas or spaces as separators) or store the string in a file (one library per line) and run solc using --libraries fileName.\n\nNote\nStarting Solidity 0.8.1 accepts = as separator between library and address, and : as a separator is deprecated. It will be removed in the future. Currently --libraries \"file.sol:Math:0x1234567890123456789012345678901234567890 file.sol:Heap:0xabCD567890123456789012345678901234567890\" will work too.\n\nIf solc is called with the option --standard-json, it will expect a JSON input (as explained below) on the standard input, and return a JSON output on the standard output. This is the recommended interface for more complex and especially automated uses. The process will always terminate in a “success” state and report any errors via the JSON output.\nThe option --base-path is also processed in standard-json mode.\nIf solc is called with the option --link, all input files are interpreted to be unlinked binaries (hex-encoded) in the __$53aea86b7d70b31448b230b20ae141a537$__-format given above and are linked in-place (if the input is read from stdin, it is written to stdout). All options except --libraries are ignored (including -o) in this case.\n\nWarning\nManually linking libraries on the generated bytecode is discouraged because it does not update\ncontract metadata. Since metadata contains a list of libraries specified at the time of\ncompilation and bytecode contains a metadata hash, you will get different binaries, depending\non when linking is performed.\nYou should ask the compiler to link the libraries at the time a contract is compiled by either\nusing the --libraries option of solc or the libraries key if you use the\nstandard-JSON interface to the compiler.\n\nNote\nThe library placeholder used to be the fully qualified name of the library itself\ninstead of the hash of it. This format is still supported by solc --link but\nthe compiler will no longer output it. This change was made to reduce\nthe likelihood of a collision between libraries, since only the first 36 characters\nof the fully qualified library name could be used.\n\nSetting the EVM Version to Target\nWhen you compile your contract code you can specify the Ethereum virtual machine\nversion to compile for to avoid particular features or behaviors.\n\nWarning\nCompiling for the wrong EVM version can result in wrong, strange and failing\nbehavior. Please ensure, especially if running a private chain, that you\nuse matching EVM versions.\n\nOn the command-line, you can select the EVM version as follows:\nsolc --evm-version <VERSION> contract.sol\n\nIn the standard JSON interface, use the \"evmVersion\"\nkey in the \"settings\" field:\n{\n \"sources\": {/* ... */},\n \"settings\": {\n \"optimizer\": {/* ... */},\n \"evmVersion\": \"<VERSION>\"\n }\n}\n\nTarget Options\nBelow is a list of target EVM versions and the compiler-relevant changes introduced\nat each version. Backward compatibility is not guaranteed between each version.\n\nhomestead (support deprecated)\n(oldest version)\n\ntangerineWhistle (support deprecated)\nGas cost for access to other accounts increased, relevant for gas estimation and the optimizer.\nAll gas sent by default for external calls, previously a certain amount had to be retained.\n\nspuriousDragon (support deprecated)\nGas cost for the exp opcode increased, relevant for gas estimation and the optimizer.\n\nbyzantium (support deprecated)\nOpcodes returndatacopy, returndatasize and staticcall are available in assembly.\nThe staticcall opcode is used when calling non-library view or pure functions, which prevents the functions from modifying state at the EVM level, i.e., even applies when you use invalid type conversions.\nIt is possible to access dynamic data returned from function calls.\nrevert opcode introduced, which means that revert() will not waste gas.\n\nconstantinople (support deprecated)\nOpcodes create2, extcodehash, shl, shr and sar are available in assembly.\nShifting operators use shifting opcodes and thus need less gas.\n\npetersburg (support deprecated)\nThe compiler behaves the same way as with constantinople.\n\nistanbul (support deprecated)\nOpcodes chainid and selfbalance are available in assembly.\n\nberlin (support deprecated)\nGas costs for SLOAD, *CALL, BALANCE, EXT* and SELFDESTRUCT increased. The\ncompiler assumes cold gas costs for such operations. This is relevant for gas estimation and\nthe optimizer.\n\nlondon\nThe block’s base fee (EIP-3198 and EIP-1559) can be accessed via the global block.basefee or basefee() in inline assembly.\n\nparis\nIntroduces prevrandao() and block.prevrandao, and changes the semantics of the now deprecated block.difficulty, disallowing difficulty() in inline assembly (see EIP-4399).\n\nshanghai\nSmaller code size and gas savings due to the introduction of push0 (see EIP-3855).\n\ncancun\nThe block’s blob base fee (EIP-7516 and EIP-4844) can be accessed via the global block.blobbasefee or blobbasefee() in inline assembly.\nIntroduces blobhash() in inline assembly and a corresponding global function to retrieve versioned hashes of blobs associated with the transaction (see EIP-4844).\nOpcode mcopy is available in assembly (see EIP-5656).\nOpcodes tstore and tload are available in assembly (see EIP-1153).\n\nprague\n\nosaka (default)\nclz builtin function is available in inline assembly. (EIP-7939)\n\namsterdam (experimental)\nThe beacon chain slot number (EIP-7843) can be accessed via the global block.slotnum or slotnum() in inline assembly.\n\nCompiler Input and Output JSON Description\nThe recommended way to interface with the Solidity compiler especially for\nmore complex and automated setups is the so-called JSON-input-output interface.\nThe same interface is provided by all distributions of the compiler.\nThe fields are generally subject to change,\nsome are optional (as noted), but we try to only make backwards compatible changes.\nThe compiler API expects a JSON formatted input and outputs the compilation result in a JSON formatted output.\nThe standard error output is not used and the process will always terminate in a “success” state, even\nif there were errors. Errors are always reported as part of the JSON output.\nThe following subsections describe the format through an example.\nComments are of course not permitted and used here only for explanatory purposes.\n\nInput Description\n{\n // Required: Source code language. Currently supported are \"Solidity\", \"Yul\", \"SolidityAST\" (experimental), \"EVMAssembly\" (experimental).\n \"language\": \"Solidity\",\n // Required\n \"sources\":\n {\n // The keys here are the \"global\" names of the source files,\n // imports can use other files via remappings (see below).\n \"myFile.sol\":\n {\n // Optional: keccak256 hash of the source file\n // It is used to verify the retrieved content if imported via URLs.\n \"keccak256\": \"0x123...\",\n // Required (unless \"content\" is used, see below): URL(s) to the source file.\n // URL(s) should be imported in this order and the result checked against the\n // keccak256 hash (if available). If the hash doesn't match or none of the\n // URL(s) result in success, an error should be raised.\n // Using the commandline interface only filesystem paths are supported.\n // With the JavaScript interface the URL will be passed to the user-supplied\n // read callback, so any URL supported by the callback can be used.\n \"urls\":\n [\n \"bzzr://56ab...\",\n \"ipfs://Qma...\",\n \"/tmp/path/to/file.sol\"\n // If files are used, their directories should be added to the command-line via\n // `--allow-paths <path>`.\n ]\n },\n \"settable\":\n {\n // Optional: keccak256 hash of the source file\n \"keccak256\": \"0x234...\",\n // Required (unless \"urls\" is used): literal contents of the source file\n \"content\": \"contract settable is owned { uint256 private x = 0; function set(uint256 _x) public { if (msg.sender == owner) x = _x; } }\"\n },\n \"myFile.sol_json.ast\":\n {\n // If language is set to \"SolidityAST\", an AST needs to be supplied under the \"ast\" key\n // and there can be only one source file present.\n // The format is the same as used by the `ast` output.\n // Note that importing ASTs is experimental and in particular that:\n // - importing invalid ASTs can produce undefined results and\n // - no proper error reporting is available on invalid ASTs.\n // Furthermore, note that the AST import only consumes the fields of the AST as\n // produced by the compiler in \"stopAfter\": \"parsing\" mode and then re-performs\n // analysis, so any analysis-based annotations of the AST are ignored upon import.\n \"ast\": { ... }\n },\n \"myFile_evm.json\":\n {\n // If language is set to \"EVMAssembly\", an EVM Assembly JSON object needs to be supplied\n // under the \"assemblyJson\" key and there can be only one source file present.\n // The format is the same as used by the `evm.legacyAssembly` output or `--asm-json`\n // output on the command line.\n // Note that importing EVM assembly is experimental.\n \"assemblyJson\":\n {\n \".code\": [ ... ],\n \".data\": { ... }, // optional\n \"sourceList\": [ ... ] // optional (if no `source` node was defined in any `.code` object)\n }\n }\n },\n // Optional\n \"settings\":\n {\n // Optional: Stop compilation after the given stage. Currently only \"parsing\" is valid here\n \"stopAfter\": \"parsing\",\n // Optional: List of remappings\n \"remappings\": [ \":g=/dir\" ],\n // Optional: Experimental mode toggle (Default: false)\n // Makes it possible to use experimental features (but does not enable any such feature by itself).\n // The use of this mode is recorded in contract metadata.\n \"experimental\": true,\n // Optional: Optimizer settings\n \"optimizer\": {\n // Turn on the optimizer. Optional. Default: false.\n // NOTE: The state of the optimizer is fully determined by the 'details' dict and this setting\n // only affects its defaults - when enabled, all components default to being enabled.\n // The opposite is not true - there are several components that always default to being\n // enabled an can only be explicitly disabled via 'details'.\n // WARNING: Before version 0.8.6 omitting this setting was not equivalent to setting\n // it to false and would result in all components being disabled instead.\n // WARNING: Enabling optimizations for EVMAssembly input is allowed but not necessary under normal\n // circumstances. It forces the opcode-based optimizer to run again and can produce bytecode that\n // is not reproducible from metadata.\n \"enabled\": true,\n // Optimize for how many times you intend to run the code. Optional. Default: 200.\n // Lower values will optimize more for initial deployment cost, higher\n // values will optimize more for high-frequency usage.\n \"runs\": 200,\n // State of all optimizer components. Optional.\n // Default values are determined by whether the optimizer is enabled or not.\n // Note that the 'enabled' setting only affects the defaults here and has no effect when\n // all values are provided explicitly.\n \"details\": {\n // Peephole optimizer (opcode-based). Optional. Default: true.\n // Default for EVMAssembly input: false when optimization is not enabled.\n // NOTE: Always runs (even with optimization disabled) except for EVMAssembly input or when explicitly turned off here.\n \"peephole\": true,\n // Inliner (opcode-based). Optional. Default: true when optimization is enabled.\n \"inliner\": false,\n // Unused JUMPDEST remover (opcode-based). Optional. Default: true.\n // Default for EVMAssembly input: false when optimization is not enabled.\n // NOTE: Always runs (even with optimization disabled) except for EVMAssembly input or when explicitly turned off here.\n \"jumpdestRemover\": true,\n // Literal reordering (codegen-based). Optional. Default: true when optimization is enabled.\n // Moves literals to the right of commutative binary operators during code generation, helping exploit associativity.\n \"orderLiterals\": false,\n // Block deduplicator (opcode-based). Optional. Default: true when optimization is enabled.\n // Unifies assembly code blocks that share content.\n \"deduplicate\": false,\n // Common subexpression elimination (opcode-based). Optional. Default: true when optimization is enabled.\n // This is the most complicated step but can also provide the largest gain.\n \"cse\": false,\n // Constant optimizer (opcode-based). Optional. Default: true when optimization is enabled.\n // Tries to find better representations of literal numbers and strings, that satisfy the\n // size/cost trade-off determined by the 'runs' setting.\n \"constantOptimizer\": false,\n // Unchecked loop increment (codegen-based). Optional. Default: true.\n // Use unchecked arithmetic when incrementing the counter of 'for' loops under certain circumstances.\n // NOTE: Always runs (even with optimization disabled) unless explicitly turned off here.\n \"simpleCounterForLoopUncheckedIncrement\": true,\n // Yul optimizer. Optional. Default: true when optimization is enabled.\n // Used to optimize the IR produced by the Yul IR-based pipeline as well as inline assembly\n // and utility Yul code generated by the compiler.\n // NOTE: Before Solidity 0.6.0 the default was false.\n \"yul\": false,\n // Tuning options for the Yul optimizer. Optional.\n \"yulDetails\": {\n // Improve allocation of stack slots for variables, can free up stack slots early.\n // Optional. Default: true if Yul optimizer is enabled.\n \"stackAllocation\": true,\n // Optimization step sequence.\n // The general form of the value is \"<main sequence>:<cleanup sequence>\".\n // The setting is optional and when omitted, default values are used for both sequences.\n // If the value does not contain the ':' delimiter, it is interpreted as the main\n // sequence and the default is used for the cleanup sequence.\n // To make one of the sequences empty, the delimiter must be present at the first or last position.\n // In particular if the whole value consists only of the delimiter, both sequences are empty.\n // Note that there are several hard-coded steps that always run, even when both sequences are empty.\n // For more information see \"The Optimizer > Selecting Optimizations\".\n \"optimizerSteps\": \"dfDvulfnTUtnIf...\"\n }\n }\n },\n // Version of the EVM to compile for (optional).\n // Affects type checking and code generation. Can be homestead,\n // tangerineWhistle, spuriousDragon, byzantium, constantinople,\n // petersburg, istanbul, berlin, london, paris, shanghai, cancun,\n // prague, osaka (default), amsterdam (experimental), or @future (experimental).\n \"evmVersion\": \"osaka\",\n // Optional: Change compilation pipeline to go through the Yul intermediate representation.\n // This is false by default.\n \"viaIR\": true,\n // Optional: Turn on SSA CFG-based code generation via the IR (experimental).\n // Implies viaIR: true. This is false by default.\n \"viaSSACFG\": false,\n // Optional: Debugging settings\n \"debug\": {\n // How to treat revert (and require) reason strings. Settings are\n // \"default\", \"strip\", \"debug\" and \"verboseDebug\".\n // \"default\" does not inject compiler-generated revert strings and keeps user-supplied ones.\n // \"strip\" removes all revert strings (if possible, i.e. if literals are used) keeping side-effects.\n // NOTE: \"strip\" does not remove custom errors.\n // \"debug\" injects strings for compiler-generated internal reverts, implemented for ABI encoders V1 and V2 for now.\n // \"verboseDebug\" even appends further information to user-supplied revert strings (not yet implemented)\n \"revertStrings\": \"default\",\n // Optional: How much extra debug information to include in comments in the produced EVM\n // assembly and Yul code. Available components are:\n // - `location`: Annotations of the form `@src <index>:<start>:<end>` indicating the\n // location of the corresponding element in the original Solidity file, where:\n // - `<index>` is the file index matching the `@use-src` annotation,\n // - `<start>` is the index of the first byte at that location,\n // - `<end>` is the index of the first byte after that location.\n // - `snippet`: A single-line code snippet from the location indicated by `@src`.\n // The snippet is quoted and follows the corresponding `@src` annotation.\n // Depends on `location`; selecting `snippet` without it is an error.\n // - `ast-id`: Annotations of the form `@ast-id <id>` over elements that can be mapped back to a definition in the original Solidity file.\n // `<id>` is a node ID in the Solidity AST ('ast' output).\n // - `ethdebug`: Ethdebug annotations (experimental). Depends on `ast-id`; selecting\n // `ethdebug` without `ast-id` is an error. Requesting an ethdebug output does not\n // change this selection; without `ethdebug` in it the `evm.bytecode.ethdebug` and\n // `evm.deployedBytecode.ethdebug` outputs carry none of the semantic debug info\n // this component adds.\n // - `*`: Wildcard value that can be used to request all non-experimental components.\n \"debugInfo\": [\"location\", \"snippet\", \"ast-id\", \"ethdebug\"]\n },\n // Metadata settings (optional)\n \"metadata\": {\n // The CBOR metadata is appended at the end of the bytecode by default.\n // Setting this to false omits the metadata from the runtime and deploy time code.\n \"appendCBOR\": true,\n // Use only literal content and not URLs (false by default)\n \"useLiteralContent\": true,\n // Use the given hash method for the metadata hash that is appended to the bytecode.\n // The metadata hash can be removed from the bytecode via option \"none\".\n // The other options are \"ipfs\" and \"bzzr1\".\n // If the option is omitted, \"ipfs\" is used by default.\n \"bytecodeHash\": \"ipfs\"\n },\n // Addresses of the libraries. If not all libraries are given here,\n // it can result in unlinked objects whose output data is different.\n \"libraries\": {\n // The top level key is the name of the source file where the library is used.\n // If remappings are used, this source file should match the global path\n // after remappings were applied.\n // If this key is an empty string, that refers to a global level.\n \"myFile.sol\": {\n \"MyLib\": \"0x123123...\"\n }\n },\n // The following can be used to select desired outputs based\n // on file and contract names.\n // If this field is omitted, then the compiler loads and does type checking,\n // but will not generate any outputs apart from errors.\n // The first level key is the file name and the second level key is the contract name.\n // An empty contract name is used for outputs that are not tied to a contract\n // but to the whole source file like the AST.\n // A star as contract name refers to all contracts in the file.\n // Similarly, a star as a file name matches all files.\n // To select all outputs the compiler can possibly generate, with the exclusion of\n // Yul intermediate representation outputs, use\n // \"outputSelection: { \"*\": { \"*\": [ \"*\" ], \"\": [ \"*\" ] } }\"\n // but note that this might slow down the compilation process needlessly.\n //\n // The available output types are as follows:\n //\n // File level (needs empty string as contract name):\n // ast - AST of all source files\n //\n // Contract level (needs the contract name or \"*\"):\n // abi - ABI\n // devdoc - Developer documentation (natspec)\n // userdoc - User documentation (natspec)\n // metadata - Metadata\n // ir - Yul intermediate representation of the code before optimization\n // irAst - AST of Yul intermediate representation of the code before optimization (experimental)\n // irOptimized - Intermediate representation after optimization\n // irOptimizedAst - AST of intermediate representation after optimization (experimental)\n // storageLayout - Slots, offsets and types of the contract's state variables in storage\n // transientStorageLayout - Slots, offsets and types of the contract's state variables in transient storage\n // evm.assembly - New assembly format\n // evm.legacyAssembly - Old-style assembly format in JSON\n // evm.bytecode.ethdebug - Debug information in ethdebug format (ethdebug/format/program schema for creation bytecode). Can only be requested when compiling via IR. Carries semantic debug info only when the `ethdebug` component is present in `settings.debug.debugInfo`. (experimental)\n // evm.deployedBytecode.ethdebug - Debug information in ethdebug format (ethdebug/format/program schema for deployed bytecode). Can only be requested when compiling via IR. Carries semantic debug info only when the `ethdebug` component is present in `settings.debug.debugInfo`. (experimental)\n // evm.bytecode.functionDebugData - Debugging information at function level\n // evm.bytecode.object - Bytecode object\n // evm.bytecode.opcodes - Opcodes list\n // evm.bytecode.sourceMap - Source mapping (useful for debugging)\n // evm.bytecode.linkReferences - Link references (if unlinked object)\n // evm.bytecode.generatedSources - Sources generated by the compiler\n // evm.deployedBytecode* - Deployed bytecode (has all the options that evm.bytecode has)\n // evm.deployedBytecode.immutableReferences - Map from AST ids to bytecode ranges that reference immutables\n // evm.methodIdentifiers - The list of function hashes\n // evm.gasEstimates - Function gas estimates\n //\n // Global level (needs \"*\" as file name and \"*\" as contract name):\n // ethdebug.resources - Global ethdebug output (ethdebug/format/info/resources schema) containing source list and compiler info (experimental)\n // ethdebug.compilation - Global ethdebug compilation output (the 'compilation' key from ethdebug/format/info/resources schema) (experimental)\n //\n // Note that using `evm`, `evm.bytecode`, etc. will select every\n // target part of that output. Additionally, `*` can be used as a wildcard to request everything.\n //\n \"outputSelection\": {\n \"*\": {\n \"*\": [\n \"metadata\", \"evm.bytecode\" // Enable the metadata and bytecode outputs of every single contract.\n , \"evm.bytecode.sourceMap\" // Enable the source map output of every single contract.\n ],\n \"\": [\n \"ast\" // Enable the AST output of every single file.\n ]\n },\n // Enable the abi and opcodes output of MyContract defined in file def.\n \"def\": {\n \"MyContract\": [ \"abi\", \"evm.bytecode.opcodes\" ]\n }\n },\n // The modelChecker object is experimental and subject to changes.\n \"modelChecker\":\n {\n // Chose which contracts should be analyzed as the deployed one.\n \"contracts\":\n {\n \"source1.sol\": [\"contract1\"],\n \"source2.sol\": [\"contract2\", \"contract3\"]\n },\n // Choose how division and modulo operations should be encoded.\n // When using `false` they are replaced by multiplication with slack\n // variables. This is the default.\n // Using `true` here is recommended if you are using the CHC engine\n // and not using Spacer as the Horn solver (using Eldarica, for example).\n // See the Formal Verification section for a more detailed explanation of this option.\n \"divModNoSlacks\": false,\n // Choose which model checker engine to use: all (default), bmc, chc, none.\n \"engine\": \"chc\",\n // Choose whether external calls should be considered trusted in case the\n // code of the called function is available at compile-time.\n // For details see the SMTChecker section.\n \"extCalls\": \"trusted\",\n // Choose which types of invariants should be reported to the user: contract, reentrancy.\n \"invariants\": [\"contract\", \"reentrancy\"],\n // Choose whether to output all proved targets. The default is `false`.\n \"showProvedSafe\": true,\n // Choose whether to output all unproved targets. The default is `false`.\n \"showUnproved\": true,\n // Choose whether to output all unsupported language features. The default is `false`.\n \"showUnsupported\": true,\n // Choose which solvers should be used, if available.\n // See the Formal Verification section for the solvers description.\n \"solvers\": [\"cvc5\", \"smtlib2\", \"z3\"],\n // Choose which targets should be checked: constantCondition,\n // underflow, overflow, divByZero, balance, assert, popEmptyArray, outOfBounds.\n // If the option is not given all targets are checked by default,\n // except underflow/overflow for Solidity >=0.8.7.\n // See the Formal Verification section for the targets description.\n \"targets\": [\"underflow\", \"overflow\", \"assert\"],\n // Timeout for each SMT query in milliseconds.\n // If this option is not given, the SMTChecker will use a deterministic\n // resource limit by default.\n // A given timeout of 0 means no resource/time restrictions for any query.\n \"timeout\": 20000\n }\n }\n}\n\nOutput Description\n{\n // Optional: not present if no errors/warnings/infos were encountered\n \"errors\": [\n {\n // Optional: Location within the source file.\n \"sourceLocation\": {\n \"file\": \"sourceFile.sol\",\n \"start\": 0,\n \"end\": 100\n },\n // Optional: Further locations (e.g. places of conflicting declarations)\n \"secondarySourceLocations\": [\n {\n \"file\": \"sourceFile.sol\",\n \"start\": 64,\n \"end\": 92,\n \"message\": \"Other declaration is here:\"\n }\n ],\n // Mandatory: Error type, such as \"TypeError\", \"InternalCompilerError\", \"Exception\", etc.\n // See below for complete list of types.\n \"type\": \"TypeError\",\n // Mandatory: Component where the error originated, such as \"general\" etc.\n \"component\": \"general\",\n // Mandatory (\"error\", \"warning\" or \"info\", but please note that this may be extended in the future)\n \"severity\": \"error\",\n // Optional: unique code for the cause of the error\n \"errorCode\": \"3141\",\n // Mandatory\n \"message\": \"Invalid keyword\",\n // Optional: the message formatted with source location\n \"formattedMessage\": \"sourceFile.sol:100: Invalid keyword\"\n }\n ],\n // This contains the file-level outputs.\n // It can be limited/filtered by the outputSelection settings.\n \"sources\": {\n \"sourceFile.sol\": {\n // Identifier of the source (used in source maps)\n \"id\": 1,\n // The AST object\n \"ast\": {}\n }\n },\n // This contains the contract-level outputs.\n // It can be limited/filtered by the outputSelection settings.\n \"contracts\": {\n \"sourceFile.sol\": {\n // If the language used has no contract names, this field should equal to an empty string.\n \"ContractName\": {\n // The Ethereum Contract ABI. If empty, it is represented as an empty array.\n // See https://docs.soliditylang.org/en/develop/abi-spec.html\n \"abi\": [],\n // See the Metadata Output documentation (serialised JSON string)\n \"metadata\": \"{/* ... */}\",\n // User documentation (natspec)\n \"userdoc\": {},\n // Developer documentation (natspec)\n \"devdoc\": {},\n // Intermediate representation before optimization (string)\n \"ir\": \"\",\n // AST of intermediate representation before optimization\n \"irAst\": {/* ... */},\n // Intermediate representation after optimization (string)\n \"irOptimized\": \"\",\n // AST of intermediate representation after optimization\n \"irOptimizedAst\": {/* ... */},\n // See the Storage Layout documentation.\n \"storageLayout\": {\"storage\": [/* ... */], \"types\": {/* ... */} },\n // See the Storage Layout documentation.\n \"transientStorageLayout\": {\"storage\": [/* ... */], \"types\": {/* ... */} },\n // EVM-related outputs\n \"evm\": {\n // Assembly (string)\n \"assembly\": \"\",\n // Old-style assembly (object)\n \"legacyAssembly\": {},\n // Bytecode and related details.\n \"bytecode\": {\n // Ethdebug output (experimental)\n \"ethdebug\": {/* ... */},\n // Debugging data at the level of functions.\n \"functionDebugData\": {\n // Now follows a set of functions including compiler-internal and\n // user-defined function. The set does not have to be complete.\n \"@mint_13\": { // Internal name of the function\n \"entryPoint\": 128, // Byte offset into the bytecode where the function starts (optional)\n \"id\": 13, // AST ID of the function definition or null for compiler-internal functions (optional)\n \"parameterSlots\": 2, // Number of EVM stack slots for the function parameters (optional)\n \"returnSlots\": 1 // Number of EVM stack slots for the return values (optional)\n }\n },\n // The bytecode as a hex string.\n \"object\": \"00fe\",\n // Opcodes list (string)\n \"opcodes\": \"\",\n // The source mapping as a string. See the source mapping definition.\n \"sourceMap\": \"\",\n // Array of sources generated by the compiler. Currently only\n // contains a single Yul file.\n \"generatedSources\": [{\n // Yul AST\n \"ast\": {/* ... */},\n // Source file in its text form (may contain comments)\n \"contents\":\"{ function abi_decode(start, end) -> data { data := calldataload(start) } }\",\n // Source file ID, used for source references, same \"namespace\" as the Solidity source files\n \"id\": 2,\n \"language\": \"Yul\",\n \"name\": \"#utility.yul\"\n }],\n // If given, this is an unlinked object.\n \"linkReferences\": {\n \"libraryFile.sol\": {\n // Byte offsets into the bytecode.\n // Linking replaces the 20 bytes located there.\n \"Library1\": [\n { \"start\": 0, \"length\": 20 },\n { \"start\": 200, \"length\": 20 }\n ]\n }\n }\n },\n \"deployedBytecode\": {\n // Ethdebug output (experimental)\n \"ethdebug\": {/* ... */},\n /* ..., */ // The same layout as above.\n \"immutableReferences\": {\n // There are two references to the immutable with AST ID 3, both 32 bytes long. One is\n // at bytecode offset 42, the other at bytecode offset 80.\n \"3\": [{ \"start\": 42, \"length\": 32 }, { \"start\": 80, \"length\": 32 }]\n }\n },\n // The list of function hashes\n \"methodIdentifiers\": {\n \"delegate(address)\": \"5c19a95c\"\n },\n // Function gas estimates\n \"gasEstimates\": {\n \"creation\": {\n \"codeDepositCost\": \"420000\",\n \"executionCost\": \"infinite\",\n \"totalCost\": \"infinite\"\n },\n \"external\": {\n \"delegate(address)\": \"25000\"\n },\n \"internal\": {\n \"heavyLifting()\": \"infinite\"\n }\n }\n }\n }\n }\n },\n // Global Ethdebug output (experimental)\n \"ethdebug\": {\n // Requested via ethdebug.resources output selection\n \"resources\": {/* ... */},\n // Requested via ethdebug.compilation output selection\n \"compilation\": {/* ... */}\n }\n}\n\nError Types\n\nJSONError: JSON input doesn’t conform to the required format, e.g. input is not a JSON object, the language is not supported, etc.\nIOError: IO and import processing errors, such as unresolvable URL or hash mismatch in supplied sources.\nParserError: Source code doesn’t conform to the language rules.\nDocstringParsingError: The NatSpec tags in the comment block cannot be parsed.\nSyntaxError: Syntactical error, such as continue is used outside of a for loop.\nDeclarationError: Invalid, unresolvable or clashing identifier names. e.g. Identifier not found\nTypeError: Error within the type system, such as invalid type conversions, invalid assignments, etc.\nUnimplementedFeatureError: Feature is not supported by the compiler, but is expected to be supported in future versions.\nInternalCompilerError: Internal bug triggered in the compiler - this should be reported as an issue.\nException: Unknown failure during compilation - this should be reported as an issue.\nCompilerError: Invalid use of the compiler stack - this should be reported as an issue.\nFatalError: Fatal error not processed correctly - this should be reported as an issue.\nYulException: Error during Yul code generation - this should be reported as an issue.\nWarning: A warning, which didn’t stop the compilation, but should be addressed if possible.\nInfo: Information that the compiler thinks the user might find useful, but is not dangerous and does not necessarily need to be addressed.\n\nExperimental Mode\nSome language and compiler features included in stable releases are not themselves considered stable.\nThey are sparsely documented, if at all, often not adequately tested, and thus not yet intended for production use.\nIn many cases it is possible to develop a big feature incrementally, with each iteration being already stable.\nSometimes, however, it is preferable to start with a prototype and stabilize it over multiple releases, while receiving feedback from users.\nTo prevent accidental use, such features can be only accessed by enabling the experimental mode.\nThere are no backwards compatibility guarantees for experimental features.\nThey are subject to change in breaking ways in non-breaking releases of the compiler.\nOnly major changes affecting them are recorded in the changelog.\nTo enable the experimental mode, use the --experimental flag on the command line,\nor the analogous settings.experimental boolean setting in the Standard JSON input.\nNote that the use of this mode is recorded in the metadata:\n\nexperimental flag in CBOR metadata is set to true,\nsettings.experimental in JSON metadata is set to true,\n\nNote\nPrior to version 0.8.35, most of the experimental features were usable without any extra safeguards.\nSome were gated behind pragma experimental, but this was not done consistently.\nThe information about them was also only recorded in CBOR metadata and even then not always.\nThe main goal of the experimental mode is to systematize this and make users fully aware when relying on features which are unfinished or not production-ready.\n\nThe table below details all currently available experimental features.\n\nFeature\nID\nAffects bytecode\nFlag/pragma\n\nAST import\nast-import\nyes\n--import-ast\n\nEVM Assembly import\nevmasm-import\nyes\n--import-asm-json\n\nIR AST\nir-ast\nno\n--ir-ast-json, --ir-optimized-ast-json\n\nNon-mainnet EVMs\nevm\nyes\n--evm-version <version name>\n\nEthdebug\nethdebug\nno\n--ethdebug-resources, --ethdebug-compilation, --ethdebug-program, --ethdebug-program-runtime, --debug-info ethdebug\n\nSSA CFG\nssa-cfg\nyes\n--via-ssa-cfg","tokens":9174,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264183753,"hash":"71880a9f73075081ef88ae401912e07f54ca4a8e"}
{"url":"https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/","domain":"ethereum.org","title":"Node architecture | ethereum.org","text":"Node architectureEdit page (opens in a new tab)An Ethereum node is composed of two clients: an execution client and a consensus client. For a node to propose a new block, it must also run a validator client.\nWhen Ethereum was using proof-of-work, an execution client was enough to run a full Ethereum node. However, since implementing proof-of-stake, the execution client must be used alongside another piece of software called a consensus client.\nThe diagram below shows the relationship between the two Ethereum clients. The two clients connect to their own respective peer-to-peer (P2P) networks. Separate P2P networks are needed as the execution clients gossip transactions over their P2P network, enabling them to manage their local transaction pool, whilst the consensus clients gossip blocks over their P2P network, enabling consensus and chain growth.\n\nThere are several options for the execution client including Erigon, Nethermind, and Besu.\nFor this two-client structure to work, consensus clients must pass bundles of transactions to the execution client. The execution client executes the transactions locally to validate that the transactions do not violate any Ethereum rules and that the proposed update to Ethereum’s state is correct. When a node is selected to be a block producer its consensus client instance requests bundles of transactions from the execution client to include in the new block and execute them to update the global state. The consensus client drives the execution client via a local RPC connection using the Engine API (opens in a new tab).\nWhat does the execution client do?\nThe execution client is responsible for transaction validation, handling, and gossip, along with state management and supporting the Ethereum Virtual Machine (EVM). It is not responsible for block building, block gossiping or handling consensus logic. These are in the remit of the consensus client.\nThe execution client creates execution payloads - the list of transactions, updated state trie, and other execution-related data. Consensus clients include the execution payload in every block. The execution client is also responsible for re-executing transactions in new blocks to ensure they are valid. Executing transactions is done on the execution client's embedded computer, known as the Ethereum Virtual Machine (EVM).\nThe execution client also offers a user interface to Ethereum through RPC methods that enable users to query the Ethereum blockchain, submit transactions and deploy smart contracts. It's common for RPC calls to be handled by a library like Web3js (opens in a new tab), Web3py (opens in a new tab), or by a user-interface such as a browser wallet.\nIn summary, the execution client is:\n\na user gateway to Ethereum\nhome to the Ethereum Virtual Machine, Ethereum's state and transaction pool.\n\nWhat does the consensus client do?\nThe consensus client deals with all the logic that enables a node to stay in sync with the Ethereum network. This includes receiving blocks from peers and running a fork choice algorithm to ensure the node always follows the chain with the greatest accumulation of attestations (weighted by validator effective balances). Similar to the execution client, consensus clients have their own P2P network through which they share blocks and attestations.\nThe consensus client does not participate in attesting to or proposing blocks - this is done by a validator, an optional add-on to a consensus client. A consensus client without a validator only keeps up with the head of the chain, allowing the node to stay synced. This enables a user to transact with Ethereum using their execution client, confident that they are on the correct chain.\nValidators\nStaking and running the validator software makes a node eligible to be selected to propose a new block. Node operators can add a validator to their consensus clients by depositing 32 ETH in the deposit contract. The validator client comes bundled with the consensus client and can be added to a node at any time. The validator handles attestations and block proposals. It also enables a node to accrue rewards or lose ETH via penalties or slashing.\nMore on staking.\nComponents of a node comparison\nExecution ClientConsensus ClientValidatorGossips transactions over its P2P networkGossips blocks and attestations over its P2P networkProposes blocksExecutes/re-executes transactionsRuns the fork choice algorithmAccrues rewards/penaltiesVerifies incoming state changesKeeps track of the head of the chainMakes attestationsManages state and receipts triesManages the Beacon state (contains consensus and execution info)Requires 32 ETH to be stakedCreates execution payloadKeeps track of accumulated randomness in RANDAO (an algorithm that provides verifiable randomness for validator selection and other consensus operations)Can be slashedExposes JSON-RPC API for interacting with EthereumKeeps track of justification and finalization\nFurther reading\n\nProof-of-stake\nBlock proposal\nValidator rewards and penalties","tokens":1256,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264187250,"hash":"68d701137f6465e8231ae3add6adbe3af3ae5bc0"}
{"url":"https://dev-forum.pyth.network/t/unstable-hermes-api/356/2","domain":"dev-forum.pyth.network","title":"Unstable Hermes API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 2 / 2\n\n Aug 2025\n\n Aug 2025\n\n post by KemarTiti on Aug 13, 2025\n\n KemarTiti\n\n Hi,\nI’ve been calling the Pyth public Hermes API (https://hermes.pyth.network/v2/updates/price/latest) from GCP in Singapore.\nIt used to be stable, but lately response times are highly unstable, sometimes over 1 minute, often exceeding 10 seconds.\nThe frequency of receiving data from websocket is also low. Is the server still healthy/stable? Do you have any suggestions on better regions or alternate endpoints to reduce latency?\nErrors continuously happened, not around specific time. I set a 10 sec hard limit timeout and found reaching this limit once / 5-minutes.\nSometimes, the Websocket also stops sending the latest price data. Public subscription too\n\n post by KemarTiti on Aug 13, 2025\n\n KemarTiti\n\n The first recommendation is to use a third-party node provider as well. You can find them here: https://docs.pyth.network/price-feeds/api-instances-and-providers/hermes#node-providers\nThe second recommendation would be using these nodes in other clusters.\nThese are all the three:\n\nhttps://hermes-stable-cyan.dourolabs.app/\nhttps://hermes-stable-green.dourolabs.app/\nhttps://hermes-stable-yellow.dourolabs.app/\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Hermes configuration\n\n Price Feeds\n\n 3\n\n 753\n\n Jun 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 396\n\n Nov 2025\n\n Powered by Discourse","tokens":1367,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264189054,"hash":"f02b6c0df9d0d1661c5c0fe11339c8e862bb7098"}
{"url":"https://docs.soliditylang.org/en/develop/cheatsheet.html","domain":"docs.soliditylang.org","title":"Cheatsheet — Solidity 0.8.38-develop documentation","text":"Cheatsheet\n\n Edit on GitHub\n\nCheatsheet\n\nOrder of Precedence of Operators\nThe following is the order of precedence for operators, listed in order of evaluation.\n\nPrecedence\nDescription\nOperator\n\n1\nPostfix increment and decrement\n++, --\n\nNew expression\nnew <typename>\n\nArray subscripting\n<array>[<index>]\n\nMember access\n<object>.<member>\n\nFunction-like call\n<func>(<args...>)\n\nParentheses\n(<statement>)\n\n2\nPrefix increment and decrement\n++, --\n\nUnary minus\n-\n\nUnary operations\ndelete\n\nLogical NOT\n!\n\nBitwise NOT\n~\n\n3\nExponentiation\n**\n\n4\nMultiplication, division and modulo\n*, /, %\n\n5\nAddition and subtraction\n+, -\n\n6\nBitwise shift operators\n<<, >>\n\n7\nBitwise AND\n&\n\n8\nBitwise XOR\n^\n\n9\nBitwise OR\n|\n\n10\nInequality operators\n<, >, <=, >=\n\n11\nEquality operators\n==, !=\n\n12\nLogical AND\n&&\n\n13\nLogical OR\n||\n\n14\nTernary operator\n<conditional> ? <if-true> : <if-false>\n\nAssignment operators\n=, |=, ^=, &=, <<=,\n>>=, +=, -=, *=, /=,\n%=\n\n15\nComma operator\n,\n\nABI Encoding and Decoding Functions\n\nabi.decode(bytes memory encodedData, (...)) returns (...): ABI-decodes\nthe provided data. The types are given in parentheses as second argument.\nExample: (uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes))\nabi.encode(...) returns (bytes memory): ABI-encodes the given arguments\nabi.encodePacked(...) returns (bytes memory): Performs packed encoding of\nthe given arguments. Note that this encoding can be ambiguous!\nabi.encodeWithSelector(bytes4 selector, ...) returns (bytes memory): ABI-encodes\nthe given arguments starting from the second and prepends the given four-byte selector\nabi.encodeCall(function functionPointer, (...)) returns (bytes memory): ABI-encodes a call to functionPointer with the arguments found in the\ntuple. Performs a full type-check, ensuring the types match the function signature. Result equals abi.encodeWithSelector(functionPointer.selector, ...)\nabi.encodeWithSignature(string memory signature, ...) returns (bytes memory): Equivalent\nto abi.encodeWithSelector(bytes4(keccak256(bytes(signature))), ...)\n\nMembers of bytes and string\n\nbytes.concat(...) returns (bytes memory): Concatenates variable number of\narguments to one byte array\nstring.concat(...) returns (string memory): Concatenates variable number of\narguments to one string array\n\nMembers of address\n\n<address>.balance (uint256): balance of the Address in Wei\n<address>.code (bytes memory): code at the Address (can be empty)\n<address>.codehash (bytes32): the codehash of the Address\n<address>.call(bytes memory) returns (bool, bytes memory): issue low-level CALL with the given payload,\nreturns success condition and return data\n<address>.delegatecall(bytes memory) returns (bool, bytes memory): issue low-level DELEGATECALL with the given payload,\nreturns success condition and return data\n<address>.staticcall(bytes memory) returns (bool, bytes memory): issue low-level STATICCALL with the given payload,\nreturns success condition and return data\n<address payable>.send(uint256 amount) returns (bool): send given amount of Wei to Address,\nreturns false on failure (deprecated)\n<address payable>.transfer(uint256 amount): send given amount of Wei to Address, throws on failure (deprecated)\n\nBlock and Transaction Properties\n\nblockhash(uint blockNumber) returns (bytes32): hash of the given block - only works for 256 most recent blocks\nblobhash(uint index) returns (bytes32): versioned hash of the index-th blob associated with the current transaction.\nA versioned hash consists of a single byte representing the version (currently 0x01), followed by the last 31 bytes\nof the SHA256 hash of the KZG commitment (EIP-4844).\nReturns zero if no blob with the given index exists.\nblock.basefee (uint): current block’s base fee (EIP-3198 and EIP-1559)\nblock.blobbasefee (uint): current block’s blob base fee (EIP-7516 and EIP-4844)\nblock.chainid (uint): current chain id\nblock.coinbase (address payable): current block miner’s address\nblock.difficulty (uint): current block difficulty (EVM < Paris). For other EVM versions it behaves as a deprecated alias for block.prevrandao that will be removed in the next breaking release\nblock.gaslimit (uint): current block gaslimit\nblock.number (uint): current block number\nblock.prevrandao (uint): random number provided by the beacon chain (EVM >= Paris) (see EIP-4399 )\nblock.slotnum (uint64): current beacon chain slot number (EVM >= Amsterdam) (see EIP-7843 )\nblock.timestamp (uint): current block timestamp in seconds since Unix epoch\ngasleft() returns (uint256): remaining gas\nmsg.data (bytes): complete calldata\nmsg.sender (address): sender of the message (current call)\nmsg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)\nmsg.value (uint): number of wei sent with the message\ntx.gasprice (uint): gas price of the transaction\ntx.origin (address): sender of the transaction (full call chain)\n\nValidations and Assertions\n\nassert(bool condition): abort execution and revert state changes if condition is false (use for internal error)\nrequire(bool condition): abort execution and revert state changes if condition is false (use\nfor malformed input or error in external component)\nrequire(bool condition, string memory message): abort execution and revert state changes if\ncondition is false (use for malformed input or error in external component). Also provide error message.\nrevert(): abort execution and revert state changes\nrevert(string memory message): abort execution and revert state changes providing an explanatory string\n\nMathematical and Cryptographic Functions\n\nkeccak256(bytes memory) returns (bytes32): compute the Keccak-256 hash of the input\nsha256(bytes memory) returns (bytes32): compute the SHA-256 hash of the input\nripemd160(bytes memory) returns (bytes20): compute the RIPEMD-160 hash of the input\necrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address): recover address associated with\nthe public key from elliptic curve signature, return zero on error\naddmod(uint x, uint y, uint k) returns (uint): compute (x + y) % k where the addition is performed with\narbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\nmulmod(uint x, uint y, uint k) returns (uint): compute (x * y) % k where the multiplication is performed\nwith arbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\nerc7201(string memory id) returns (uint): compute the base slot of an erc7201 storage namespace.\nCan be used in compile time context.\n\nContract-related\n\nthis (current contract’s type): the current contract, explicitly convertible to address or address payable\nsuper: a contract one level higher in the inheritance hierarchy\nselfdestruct(address payable recipient): send all funds to the given address and (only on EVMs before Cancun or when invoked within the transaction creating the contract) destroy the contract.\n\nType Information\n\ntype(C).name (string): the name of the contract\ntype(C).creationCode (bytes memory): creation bytecode of the given contract, see Type Information.\ntype(C).runtimeCode (bytes memory): runtime bytecode of the given contract, see Type Information.\ntype(I).interfaceId (bytes4): value containing the EIP-165 interface identifier of the given interface, see Type Information.\ntype(T).min (T): the minimum value representable by the integer type T, see Type Information.\ntype(T).max (T): the maximum value representable by the integer type T, see Type Information.\n\nFunction Visibility Specifiers\nopen in Remix\nfunction myFunction() <visibility specifier> returns (bool) {\n return true;\n}\n\npublic: visible externally and internally (creates a getter function for storage/state variables)\nprivate: only visible in the current contract\nexternal: only visible externally (only for functions) - i.e. can only be message-called (via this.func)\ninternal: only visible internally\n\nModifiers\n\npure for functions: Disallows modification or access of state.\nview for functions: Disallows modification of state.\npayable for functions: Allows them to receive Ether together with a call.\nconstant for state variables: Disallows assignment (except initialization), does not occupy storage slot.\nimmutable for state variables: Allows assignment at construction time and is constant when deployed. Is stored in code.\nanonymous for events: Does not store event signature as topic.\nindexed for event parameters: Stores the parameter as topic.\nvirtual for functions and modifiers: Allows the function’s or modifier’s\nbehavior to be changed in derived contracts.\noverride: States that this function, modifier or public state variable changes\nthe behavior of a function or modifier in a base contract.","tokens":2180,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264195098,"hash":"40b4d629fdb0b1b2c5af80da55e16c9a5a37f632"}
{"url":"https://ethereum.org/developers/docs/accounts/","domain":"ethereum.org","title":"Ethereum accounts | ethereum.org","text":"Ethereum accountsEdit page (opens in a new tab)An Ethereum account is an entity with an ether (ETH) balance that can send messages on Ethereum. Accounts can be user-controlled or deployed as smart contracts.\nPrerequisites\nTo help you better understand this page, we recommend you first read through our introduction to Ethereum.\nAccount types\nEthereum has two account types:\n\nExternally-owned account (EOA) – controlled by anyone with the private keys\nContract account – a smart contract deployed to the network, controlled by code. Learn about smart contracts\n\nBoth account types have the ability to:\n\nReceive, hold and send ETH and tokens\nInteract with deployed smart contracts\n\nKey differences\nExternally-owned\n\nCreating an account costs nothing\nCan initiate transactions\nTransactions between externally-owned accounts can only be ETH/token transfers\nMade up of a cryptographic pair of keys: public and private keys that control account activities\n\nContract\n\nCreating a contract has a cost because you're using network storage\nCan only send messages in response to receiving a transaction\nTransactions from an external account to a contract account can trigger code which can execute many different actions, such as transferring tokens or even creating a new contract\nContract accounts don't have private keys. Instead, they are controlled by the logic of the smart contract code\n\nAn account examined\nEthereum accounts have four fields:\n\nnonce – A counter that indicates the number of transactions sent from an externally-owned account or the number of contracts created by a contract account. Only one transaction with a given nonce can be executed for each account, protecting against replay attacks where signed transactions are repeatedly broadcast and re-executed.\nbalance – The number of wei owned by this address. Wei is a denomination of ETH and there are 1e+18 wei per ETH.\ncodeHash – This hash refers to the code of an account on the Ethereum virtual machine (EVM). Contract accounts have code fragments programmed in that can perform different operations. This EVM code gets executed if the account gets a message call. It cannot be changed, unlike the other account fields. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash value is known as a codeHash. For externally owned accounts, the codeHash field is the hash of an empty string.\nstorageRoot – Sometimes known as a storage hash. A 256-bit hash of the root node of a Merkle Patricia Trie that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. This trie encodes the hash of the storage contents of this account, and is empty by default.\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nExternally-owned accounts and key pairs\nAn account is made up of a pair of cryptographic keys: public and private. They help prove that a transaction was actually signed by the sender and prevent forgeries. Your private key is what you use to sign transactions, so it grants you custody over the funds associated with your account. You never really hold cryptocurrency, you hold private keys – the funds are always on Ethereum's ledger.\nThis prevents malicious actors from broadcasting fake transactions because you can always verify the sender of a transaction.\nIf Alice wants to send ether from her own account to Bob’s account, Alice needs to create a transaction request and send it out to the network for verification. Ethereum’s usage of public-key cryptography ensures that Alice can prove that she originally initiated the transaction request. Without cryptographic mechanisms, a malicious adversary Eve could simply publicly broadcast a request that looks something like “send 5 ETH from Alice’s account to Eve’s account,” and no one would be able to verify that it didn’t come from Alice.\nAccount creation\nWhen you want to create an account, most libraries will generate you a random private key.\nA private key is made up of 64 hex characters and can be encrypted with a password.\nExample:\nfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f\nThe public key is generated from the private key using the Elliptic Curve Digital Signature Algorithm (opens in a new tab). You get a public address for your account by taking the last 20 bytes of the Keccak-256 hash of the public key and adding 0x to the beginning.\nThis means an Externally owned account (EOA) has a 42-character address (20-byte segment which is 40 hexadecimal characters plus the 0x prefix).\nExample:\n0x5e97870f263700f46aa00d967821199b9bc5a120\nThe following example shows how to use a signing tool called Clef (opens in a new tab) to generate a new account. Clef is an account management and signing tool that comes bundled with the Ethereum client, Geth (opens in a new tab). The clef newaccount command creates a new key pair and saves them in an encrypted keystore.\n> clef newaccount --keystore <path>\n\nPlease enter a password for the new account to be created:\n> <password>\n\n------------\nINFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120\nWARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120\nWARN [10-28|16:19:09.306] Please remember your password!\nGenerated account 0x5e97870f263700f46aa00d967821199b9bc5a120\n\nGeth documentation (opens in a new tab)\nIt is possible to derive new public keys from your private key, but you cannot derive a private key from public keys. It is vital to keep your private keys safe and, as the name suggests, PRIVATE.\nYou need a private key to sign messages and transactions which output a signature. Others can then take the signature to derive your public key, proving the author of the message. In your application, you can use a JavaScript library to send transactions to the network.\nContract accounts\nContract accounts also have a 42 character hexadecimal address:\nExample:\n0x06012c8cf97bead5deae237070f9587f8e7a266d\nThe contract address is usually given when a contract is deployed to the Ethereum Blockchain. The address comes from the creator's address and the number of transactions sent from that address (the “nonce”). This is how the CREATE operation derives an address.\nContracts can also be deployed with CREATE2 (opens in a new tab), which derives the address from the creator's address, a value the creator picks (the “salt”), and a hash of the contract's creation code. No nonce is involved, so the address can be calculated before the contract exists and stays the same no matter how many other transactions the creator sends in the meantime. This makes it possible to reference a contract that has not been deployed yet.\nValidator keys\nThere is also another type of key in Ethereum, introduced when Ethereum switched from proof-of-work to proof-of-stake based consensus. These are 'BLS' keys and they are used to identify validators. These keys can be efficiently aggregated to reduce the bandwidth required for the network to come to consensus. Without this key aggregation the minimum stake for a validator would be much higher.\nMore on validator keys.\nA note on wallets\nAn account is not a wallet. A wallet is an interface or application that lets you interact with your Ethereum account, either an externally-owned account or a contract account.\nA visual demo\nWatch Austin walk you through hash functions, and key pairs.\nHash function — ETH.BUILDA demonstration of cryptographic hash functions using the ETH.BUILD educational tool.Watch with transcript \nKey pair — ETH.BUILDA demonstration of public-private key pairs using the ETH.BUILD educational tool.Watch with transcript \nFurther reading\n\nUnderstanding Ethereum Accounts (opens in a new tab) - etherscan\n\nKnow of a community resource that helped you? Edit this page and add it!\nRelated topics\n\nSmart contracts\nTransactions\n\nTest your Ethereum knowledgeEthereum accountsQuestion number 1:A new contract is deployed. Where does its address come from?","tokens":2061,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264200897,"hash":"2e26c5019281b6694615589bc98711465dec26f7"}
{"url":"https://docs.soliditylang.org/en/develop/control-structures.html","domain":"docs.soliditylang.org","title":"Expressions and Control Structures — Solidity 0.8.38-develop documentation","text":"Expressions and Control Structures\n\n Edit on GitHub\n\nExpressions and Control Structures\n\nControl Structures\nMost of the control structures known from curly-braces languages are available in Solidity:\nThere is: if, else, while, do, for, break, continue, return, with\nthe usual semantics known from C or JavaScript.\nSolidity also supports exception handling in the form of try/catch-statements,\nbut only for external function calls and\ncontract creation calls. Errors can be created using the revert statement.\nParentheses can not be omitted for conditionals, but curly braces can be omitted\naround single-statement bodies.\nNote that there is no type conversion from non-boolean to boolean types as\nthere is in C and JavaScript, so if (1) { ... } is not valid\nSolidity.\n\nFunction Calls\n\nInternal Function Calls\nFunctions of the current contract can be called directly (“internally”), also recursively, as seen in\nthis nonsensical example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.22 <0.9.0;\n\n// This will report a warning\ncontract C {\n function g(uint a) public pure returns (uint ret) { return a + f(); }\n function f() internal pure returns (uint ret) { return g(7) + f(); }\n}\n\nThese function calls are translated into simple jumps inside the EVM. This has\nthe effect that the current memory is not cleared, i.e. passing memory references\nto internally-called functions is very efficient. Only functions of the same\ncontract instance can be called internally.\nYou should still avoid excessive recursion, as every internal function call\nuses up at least one stack slot and there are only 1024 slots available.\n\nExternal Function Calls\nFunctions can also be called using the this.g(8); and c.g(2); notation, where\nc is a contract instance and g is a function belonging to c.\nCalling the function g via either way results in it being called “externally”, using a\nmessage call and not directly via jumps.\nPlease note that function calls on this cannot be used in the constructor,\nas the actual contract has not been created yet.\nFunctions of other contracts have to be called externally. For an external call,\nall function arguments have to be copied to memory.\n\nNote\nA function call from one contract to another does not create its own transaction,\nit is a message call as part of the overall transaction.\n\nWhen calling functions of other contracts, you can specify the amount of Wei or\ngas sent with the call with the special options {value: 10, gas: 10000}.\nNote that it is discouraged to specify gas values explicitly, since the gas costs\nof opcodes can change in the future. Any Wei you send to the contract is added\nto the total balance of that contract:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.2 <0.9.0;\n\ncontract InfoFeed {\n function info() public payable returns (uint ret) { return 42; }\n}\n\ncontract Consumer {\n InfoFeed feed;\n function setFeed(InfoFeed addr) public { feed = addr; }\n function callFeed() public { feed.info{value: 10, gas: 800}(); }\n}\n\nYou need to use the modifier payable with the info function because\notherwise, the value option would not be available.\n\nWarning\nBe careful that feed.info{value: 10, gas: 800} only locally sets the\nvalue and amount of gas sent with the function call, and the\nparentheses at the end perform the actual call. So\nfeed.info{value: 10, gas: 800} does not call the function and\nthe value and gas settings are lost, only\nfeed.info{value: 10, gas: 800}() performs the function call.\n\nWarning\nDue to the fact that the EVM considers a call to a non-existing contract to\nalways succeed, Solidity uses the extcodesize opcode to check that\nthe contract that is about to be called actually exists (it contains code)\nand causes an exception if it does not. This check is skipped if the return\ndata will be decoded after the call and thus the ABI decoder will catch the\ncase of a non-existing contract.\nThis check is not performed in case of low-level calls which\noperate on addresses rather than contract instances.\n\nWarning\nBe careful when using high-level calls to\nprecompiled contracts,\nsince the compiler considers them non-existing according to the\nabove logic even though they execute code and can return data.\n\nNote\nSince the version 0.8.10, the compiler does not check extcodesize on\nhigh-level external calls if return data is expected, because an empty code\nwill be unable to return data, and the ABI decoder will revert.\nAs a consequence, this allows high-level external calls to precompiled\ncontracts, since they can return data despite having no code\nassociated with their addresses.\nRead about precompiled contracts and\nlow-level calls\nfor more information.\n\nFunction calls also cause exceptions if the called contract itself\nthrows an exception or goes out of gas.\n\nWarning\nAny interaction with another contract imposes a potential danger, especially\nif the source code of the contract is not known in advance. The\ncurrent contract hands over control to the called contract and that may potentially\ndo just about anything. Even if the called contract inherits from a known parent contract,\nthe inheriting contract is only required to have a correct interface. The\nimplementation of the contract, however, can be completely arbitrary and thus,\npose a danger. In addition, be prepared in case it calls into other contracts of\nyour system or even back into the calling contract before the first\ncall returns. This means\nthat the called contract can change state variables of the calling contract\nvia its functions. Write your functions in a way that, for example, calls to\nexternal functions happen after any changes to state variables in your contract\nso your contract is not vulnerable to a reentrancy exploit.\n\nNote\nBefore Solidity 0.6.2, the recommended way to specify the value and gas was to\nuse f.value(x).gas(g)(). This was deprecated in Solidity 0.6.2 and is no\nlonger possible since Solidity 0.7.0.\n\nFunction Calls with Named Parameters\nFunction call arguments can be given by name, in any order,\nif they are enclosed in { } as can be seen in the following\nexample. The argument list has to coincide by name with the list of\nparameters from the function declaration, but can be in arbitrary order.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract C {\n mapping(uint => uint) data;\n\n function f() public {\n set({value: 2, key: 3});\n }\n\n function set(uint key, uint value) public {\n data[key] = value;\n }\n}\n\nOmitted Names in Function Definitions\nThe names of parameters and return values in the function declaration can be omitted.\nThose items with omitted names will still be present on the stack, but they are\ninaccessible by name. An omitted return value name\ncan still return a value to the caller by use of the return statement.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.22 <0.9.0;\n\ncontract C {\n // omitted name for parameter\n function func(uint k, uint) public pure returns(uint) {\n return k;\n }\n}\n\nCreating Contracts via new\nA contract can create other contracts using the new keyword. The full\ncode of the contract being created has to be known when the creating contract\nis compiled so recursive creation-dependencies are not possible.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\ncontract D {\n uint public x;\n constructor(uint a) payable {\n x = a;\n }\n}\n\ncontract C {\n D d = new D(4); // will be executed as part of C's constructor\n\n function createD(uint arg) public {\n D newD = new D(arg);\n newD.x();\n }\n\n function createAndEndowD(uint arg, uint amount) public payable {\n // Send ether along with the creation\n D newD = new D{value: amount}(arg);\n newD.x();\n }\n}\n\nAs seen in the example, it is possible to send Ether while creating\nan instance of D using the value option, but it is not possible\nto limit the amount of gas.\nIf the creation fails (due to out-of-stack, not enough balance or other problems),\nan exception is thrown.\n\nSalted contract creations / create2\nWhen creating a contract, the address of the contract is computed from\nthe address of the creating contract and a counter that is increased with\neach contract creation.\nIf you specify the option salt (a bytes32 value), then contract creation will\nuse a different mechanism to come up with the address of the new contract:\nIt will compute the address from the address of the creating contract,\nthe given salt value, the (creation) bytecode of the created contract and the constructor\narguments.\nIn particular, the counter (“nonce”) is not used. This allows for more flexibility\nin creating contracts: You are able to derive the address of the\nnew contract before it is created. Furthermore, you can rely on this address\nalso in case the creating\ncontracts creates other contracts in the meantime.\nThe main use-case here is contracts that act as judges for off-chain interactions,\nwhich only need to be created if there is a dispute.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\ncontract D {\n uint public x;\n constructor(uint a) {\n x = a;\n }\n}\n\ncontract C {\n function createDSalted(bytes32 salt, uint arg) public {\n // This complicated expression just tells you how the address\n // can be pre-computed. It is just there for illustration.\n // You actually only need ``new D{salt: salt}(arg)``.\n address predictedAddress = address(uint160(uint(keccak256(abi.encodePacked(\n bytes1(0xff),\n address(this),\n salt,\n keccak256(abi.encodePacked(\n type(D).creationCode,\n abi.encode(arg)\n ))\n )))));\n\n D d = new D{salt: salt}(arg);\n require(address(d) == predictedAddress);\n }\n}\n\nWarning\nThere are some peculiarities in relation to salted creation. A contract can be\nre-created at the same address after having been destroyed. Yet, it is possible\nfor that newly created contract to have a different deployed bytecode even\nthough the creation bytecode has been the same (which is a requirement because\notherwise the address would change). This is due to the fact that the constructor\ncan query external state that might have changed between the two creations\nand incorporate that into the deployed bytecode before it is stored.\n\nOrder of Evaluation of Expressions\nThe evaluation order of expressions is not specified (more formally, the order\nin which the children of one node in the expression tree are evaluated is not\nspecified, but they are of course evaluated before the node itself). It is only\nguaranteed that statements are executed in order and short-circuiting for\nboolean expressions is done.\n\nAssignment\n\nDestructuring Assignments and Returning Multiple Values\nSolidity internally allows tuple types, i.e. a list of objects\nof potentially different types whose number is a constant at\ncompile-time. Those tuples can be used to return multiple values at the same time.\nThese can then either be assigned to newly declared variables\nor to pre-existing variables (or LValues in general).\nTuples are not proper types in Solidity, they can only be used to form syntactic\ngroupings of expressions.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n\ncontract C {\n uint index;\n\n function f() public pure returns (uint, bool, uint) {\n return (7, true, 2);\n }\n\n function g() public {\n // Variables declared with type and assigned from the returned tuple,\n // not all elements have to be specified (but the number must match).\n (uint x, , uint y) = f();\n // Common trick to swap values -- does not work for non-value storage types.\n (x, y) = (y, x);\n // Components can be left out (also for variable declarations).\n (index, , ) = f(); // Sets the index to 7\n }\n}\n\nIt is not possible to mix variable declarations and non-declaration assignments,\ni.e. the following is not valid: (x, uint y) = (1, 2);\n\nNote\nPrior to version 0.5.0 it was possible to assign to tuples of smaller size, either\nfilling up on the left or on the right side (which ever was empty). This is\nnow disallowed, so both sides have to have the same number of components.\n\nWarning\nBe careful when assigning to multiple variables at the same time when\nreference types are involved, because it could lead to unexpected\ncopying behavior.\n\nComplications for Arrays and Structs\nThe semantics of assignments are more complicated for non-value types like arrays and structs,\nincluding bytes and string, see Data location and assignment behavior for details.\nIn the example below the call to g(x) has no effect on x because it creates\nan independent copy of the storage value in memory. However, h(x) successfully modifies x\nbecause only a reference and not a copy is passed.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.22 <0.9.0;\n\ncontract C {\n uint[20] x;\n\n function f() public {\n g(x);\n h(x);\n }\n\n function g(uint[20] memory y) internal pure {\n y[2] = 3;\n }\n\n function h(uint[20] storage y) internal {\n y[3] = 4;\n }\n}\n\nScoping and Declarations\nA variable which is declared will have an initial default\nvalue whose byte-representation is all zeros.\nThe “default values” of variables are the typical “zero-state”\nof whatever the type is. For example, the default value for a bool\nis false. The default value for the uint or int\ntypes is 0. For statically-sized arrays and bytes1 to\nbytes32, each individual\nelement will be initialized to the default value corresponding\nto its type. For dynamically-sized arrays, bytes\nand string, the default value is an empty array or string.\nFor the enum type, the default value is its first member.\nScoping in Solidity follows the widespread scoping rules of C99\n(and many other languages): Variables are visible from the point right after their declaration\nuntil the end of the smallest { }-block that contains the declaration.\nAs an exception to this rule, variables declared in the\ninitialization part of a for-loop are only visible until the end of the for-loop.\nVariables that are parameter-like (function parameters, modifier parameters,\ncatch parameters, …) are visible inside the code block that follows -\nthe body of the function/modifier for a function and modifier parameter and the catch block\nfor a catch parameter.\nVariables and other items declared outside of a code block, for example functions, contracts,\nuser-defined types, etc., are visible even before they were declared. This means you can\nuse state variables before they are declared and call functions recursively.\nAs a consequence, the following examples will compile without warnings, since\nthe two variables have the same name but disjoint scopes.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\ncontract C {\n function minimalScoping() pure public {\n {\n uint same;\n same = 1;\n }\n\n {\n uint same;\n same = 3;\n }\n }\n}\n\nAs a special example of the C99 scoping rules, note that in the following,\nthe first assignment to x will actually assign the outer and not the inner variable.\nIn any case, you will get a warning about the outer variable being shadowed.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n// This will report a warning\ncontract C {\n function f() pure public returns (uint) {\n uint x = 1;\n {\n x = 2; // this will assign to the outer variable\n uint x;\n }\n return x; // x has value 2\n }\n}\n\nWarning\nBefore version 0.5.0 Solidity followed the same scoping rules as\nJavaScript, that is, a variable declared anywhere within a function would be in scope\nfor the entire function, regardless where it was declared. The following example shows a code snippet that used\nto compile but leads to an error starting from version 0.5.0.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n// This will not compile\ncontract C {\n function f() pure public returns (uint) {\n x = 2;\n uint x;\n return x;\n }\n}\n\nChecked or Unchecked Arithmetic\nAn overflow or underflow is the situation where the resulting value of an arithmetic operation,\nwhen executed on an unrestricted integer, falls outside the range of the result type.\nPrior to Solidity 0.8.0, arithmetic operations would always wrap in case of\nunder- or overflow leading to widespread use of libraries that introduce\nadditional checks.\nSince Solidity 0.8.0, all arithmetic operations revert on over- and underflow by default,\nthus making the use of these libraries unnecessary.\nTo obtain the previous behavior, an unchecked block can be used:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.0;\ncontract C {\n function f(uint a, uint b) pure public returns (uint) {\n // This subtraction will wrap on underflow.\n unchecked { return a - b; }\n }\n function g(uint a, uint b) pure public returns (uint) {\n // This subtraction will revert on underflow.\n return a - b;\n }\n}\n\nThe call to f(2, 3) will return 2**256-1, while g(2, 3) will cause\na failing assertion.\nThe unchecked block can be used everywhere inside a block, but not as a replacement\nfor a block. It also cannot be nested.\nThe setting only affects the statements that are syntactically inside the block.\nFunctions called from within an unchecked block do not inherit the property.\n\nNote\nTo avoid ambiguity, you cannot use _; inside an unchecked block.\n\nThe following operators will cause a failing assertion on overflow or underflow\nand will wrap without an error if used inside an unchecked block:\n++, --, +, binary -, unary -, *, /, %, **\n+=, -=, *=, /=, %=\n\nWarning\nIt is not possible to disable the check for division by zero\nor modulo by zero using the unchecked block.\n\nNote\nBitwise operators do not perform overflow or underflow checks.\nThis is particularly visible when using bitwise shifts (<<, >>, <<=, >>=) in\nplace of integer division and multiplication by a power of 2.\nFor example type(uint256).max << 3 does not revert even though type(uint256).max * 8 would.\n\nNote\nThe second statement in int x = type(int).min; -x; will result in an overflow\nbecause the negative range can hold one more value than the positive range.\n\nExplicit type conversions will always truncate and never cause a failing assertion\nwith the exception of a conversion from an integer to an enum type.\n\nError handling: Assert, Require, Revert and Exceptions\nSolidity uses state-reverting exceptions to handle errors.\nSuch an exception undoes all changes made to the\nstate in the current call (and all its sub-calls) and\nflags an error to the caller.\nWhen exceptions happen in a sub-call, they “bubble up” (i.e.,\nexceptions are rethrown) automatically unless they are caught in\na try/catch statement. Exceptions to this rule are send\nand the low-level functions call, delegatecall and\nstaticcall: they return false as their first return value in case\nof an exception instead of “bubbling up”.\n\nWarning\nThe low-level functions call, delegatecall and\nstaticcall return true as their first return value\nif the account called is non-existent, as part of the design\nof the EVM. Account existence must be checked prior to calling if needed.\n\nExceptions can contain error data that is passed back to the caller\nin the form of error instances.\nThe built-in errors Error(string) and Panic(uint256) are\nused by special functions, as explained below. Error is used for “regular” error conditions\nwhile Panic is used for errors that should not be present in bug-free code.\n\nPanic via assert and Error via require\nThe convenience functions assert and require can be used to check for conditions and throw an exception\nif the condition is not met.\nThe assert function creates an error of type Panic(uint256).\nThe same error is created by the compiler in certain situations as listed below.\nAssert should only be used to test for internal\nerrors, and to check invariants. Properly functioning code should\nnever create a Panic, not even on invalid external input.\nIf this happens, then there\nis a bug in your contract which you should fix. Language analysis\ntools can evaluate your contract to identify the conditions and\nfunction calls which will cause a Panic.\nA Panic exception is generated in the following situations.\nThe error code supplied with the error data indicates the kind of panic.\n\n0x00: Used for generic compiler inserted panics.\n0x01: If you call assert with an argument that evaluates to false.\n0x11: If an arithmetic operation results in underflow or overflow outside of an unchecked { ... } block.\n0x12; If you divide or modulo by zero (e.g. 5 / 0 or 23 % 0).\n0x21: If you convert a value that is too big or negative into an enum type.\n0x22: If you access a storage byte array that is incorrectly encoded.\n0x31: If you call .pop() on an empty array.\n0x32: If you access an array, bytesN or an array slice at an out-of-bounds or negative index (i.e. x[i] where i >= x.length or i < 0).\n0x41: If you allocate too much memory or create an array that is too large.\n0x51: If you call a zero-initialized variable of internal function type.\n\nThe require function provides three overloads:\n\nrequire(bool) which will revert without any data (not even an error selector).\nrequire(bool, string) which will revert with an Error(string).\nrequire(bool, error) which will revert with the custom, user supplied error provided as the second argument.\n\nNote\nrequire arguments are evaluated unconditionally, so take special care to make sure that\nthey are not expressions with unexpected side-effects.\nFor example, in require(condition, CustomError(f())); and require(condition, f());,\nfunction f() will be called regardless of whether the supplied condition is true or false.\n\nAn Error(string) exception (or an exception without data) is generated\nby the compiler in the following situations:\n\nCalling require(x) where x evaluates to false.\nIf you use revert() or revert(\"description\").\nIf you perform an external function call targeting a contract that contains no code.\nIf your contract receives Ether via a public function without\npayable modifier (including the constructor and the fallback function).\nIf your contract receives Ether via a public getter function.\n\nFor the following cases, the error data from the external call\n(if provided) is forwarded. This means that it can either cause\nan Error or a Panic (or whatever else was given):\n\nIf a .transfer() fails.\nIf you call a function via a message call but it does not finish\nproperly (i.e., it runs out of gas, has no matching function, or\nthrows an exception itself), except when a low level operation\ncall, send, delegatecall, callcode or staticcall\nis used. The low level operations never throw exceptions but\nindicate failures by returning false.\nIf you create a contract using the new keyword but the contract\ncreation does not finish properly.\n\nYou can optionally provide a message string or a custom error to require, but not to assert.\n\nNote\nIf you do not provide a string or custom error argument to require, it will revert\nwith empty error data, not even including the error selector.\n\nThe following example shows how you can use require to check conditions on inputs\nand assert for internal error checking.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.2 <0.9.0;\n\ncontract Sharer {\n function sendHalf(address payable addr) public payable returns (uint balance) {\n require(msg.value % 2 == 0, \"Even value required.\");\n uint balanceBeforeTransfer = address(this).balance;\n (bool success, ) = addr.call{value: msg.value / 2}(\"\");\n require(success);\n // Since require will stop execution and revert if success is false,\n // there should be no way for us to still have half of the Ether.\n assert(address(this).balance == balanceBeforeTransfer - msg.value / 2);\n return address(this).balance;\n }\n}\n\nInternally, Solidity performs a revert operation (instruction\n0xfd). This causes\nthe EVM to revert all changes made to the state. The reason for reverting\nis that there is no safe way to continue execution, because an expected effect\ndid not occur. Because we want to keep the atomicity of transactions, the\nsafest action is to revert all changes and make the whole transaction\n(or at least call) without effect.\nIn both cases, the caller can react on such failures using try/catch, but\nthe changes in the callee will always be reverted.\n\nNote\nPanic exceptions used to use the invalid opcode before Solidity 0.8.0,\nwhich consumed all gas available to the call.\nExceptions that use require used to consume all gas until before the Metropolis release.\n\nrevert\nA direct revert can be triggered using the revert statement and the revert function.\nThe revert statement takes a custom error as direct argument without parentheses:\n\nrevert CustomError(arg1, arg2);\n\nFor backward-compatibility reasons, there is also the revert() function, which uses parentheses\nand accepts a string:\n\nrevert();\nrevert(“description”);\n\nThe error data will be passed back to the caller and can be caught there.\nUsing revert() causes a revert without any error data while revert(\"description\")\nwill create an Error(string) error.\nUsing a custom error instance will usually be much cheaper than a string description,\nbecause you can use the name of the error to describe it, which is encoded in only\nfour bytes. A longer description can be supplied via NatSpec which does not incur\nany costs.\nThe following example shows how to use an error string and a custom error instance\ntogether with revert and the equivalent require:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\n\ncontract VendingMachine {\n address owner;\n error Unauthorized();\n function buy(uint amount) public payable {\n if (amount > msg.value / 2 ether)\n revert(\"Not enough Ether provided.\");\n // Alternative way to do it:\n require(\n amount <= msg.value / 2 ether,\n \"Not enough Ether provided.\"\n );\n // Perform the purchase.\n }\n function withdraw() public {\n if (msg.sender != owner)\n revert Unauthorized();\n\n (bool success, ) = payable(msg.sender).call{value: address(this).balance}(\"\");\n require(success);\n }\n}\n\nThe two ways if (!condition) revert(...); and require(condition, ...); are\nequivalent as long as the arguments to revert and require do not have side-effects,\nfor example if they are just strings.\n\nNote\nThe require function is evaluated just as any other function.\nThis means that all arguments are evaluated before the function itself is executed.\nIn particular, in require(condition, f()) the function f is executed even if\ncondition is true.\n\nThe provided string is abi-encoded as if it were a call to a function Error(string).\nIn the above example, revert(\"Not enough Ether provided.\"); returns the following hexadecimal as error return data:\nopen in Remix\n0x08c379a0 // Function selector for Error(string)\n0x0000000000000000000000000000000000000000000000000000000000000020 // Data offset\n0x000000000000000000000000000000000000000000000000000000000000001a // String length\n0x4e6f7420656e6f7567682045746865722070726f76696465642e000000000000 // String data\n\nThe provided message can be retrieved by the caller using try/catch as shown below.\n\nNote\nThere used to be a keyword called throw with the same semantics as revert() which\nwas deprecated in version 0.4.13 and removed in version 0.5.0.\n\ntry/catch\nA failure in an external call can be caught using a try/catch statement, as follows:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.1;\n\ninterface DataFeed { function getData(address token) external returns (uint value); }\n\ncontract FeedConsumer {\n DataFeed feed;\n uint errorCount;\n function rate(address token) public returns (uint value, bool success) {\n // Permanently disable the mechanism if there are\n // more than 10 errors.\n require(errorCount < 10);\n try feed.getData(token) returns (uint v) {\n return (v, true);\n } catch Error(string memory /*reason*/) {\n // This is executed in case\n // revert was called inside getData\n // and a reason string was provided.\n errorCount++;\n return (0, false);\n } catch Panic(uint /*errorCode*/) {\n // This is executed in case of a panic,\n // i.e. a serious error like division by zero\n // or overflow. The error code can be used\n // to determine the kind of error.\n errorCount++;\n return (0, false);\n } catch (bytes memory /*lowLevelData*/) {\n // This is executed in case revert() was used.\n errorCount++;\n return (0, false);\n }\n }\n}\n\nThe try keyword has to be followed by an expression representing an external function call\nor a contract creation (new ContractName()).\nErrors inside the expression are not caught (for example if it is a complex expression\nthat also involves internal function calls), only a revert happening inside the external\ncall itself. The returns part (which is optional) that follows declares return variables\nmatching the types returned by the external call. In case there was no error,\nthese variables are assigned and the contract’s execution continues inside the\nfirst success block. If the end of the success block is reached, execution continues after the catch blocks.\nSolidity supports different kinds of catch blocks depending on the\ntype of error:\n\ncatch Error(string memory reason) { ... }: This catch clause is executed if the error was caused by revert(\"reasonString\") or\nrequire(false, \"reasonString\") (or an internal error that causes such an\nexception).\ncatch Panic(uint errorCode) { ... }: If the error was caused by a panic, i.e. by a failing assert, division by zero,\ninvalid array access, arithmetic overflow and others, this catch clause will be run.\ncatch (bytes memory lowLevelData) { ... }: This clause is executed if the error signature\ndoes not match any other clause, if there was an error while decoding the error\nmessage, or\nif no error data was provided with the exception.\nThe declared variable provides access to the low-level error data in that case.\ncatch { ... }: If you are not interested in the error data, you can just use\ncatch { ... } (even as the only catch clause) instead of the previous clause.\n\nIt is planned to support other types of error data in the future.\nThe strings Error and Panic are currently parsed as is and are not treated as identifiers.\nIn order to catch all error cases, you have to have at least the clause\ncatch { ...} or the clause catch (bytes memory lowLevelData) { ... }.\nThe variables declared in the returns and the catch clause are only\nin scope in the block that follows.\n\nNote\nIf an error happens during the decoding of the return data\ninside a try/catch-statement, this causes an exception in the currently\nexecuting contract and because of that, it is not caught in the catch clause.\nIf there is an error during decoding of catch Error(string memory reason)\nand there is a low-level catch clause, this error is caught there.\n\nNote\nIf execution reaches a catch-block, then the state-changing effects of\nthe external call have been reverted. If execution reaches\nthe success block, the effects were not reverted.\nIf the effects have been reverted, then execution either continues\nin a catch block or the execution of the try/catch statement itself\nreverts (for example due to decoding failures as noted above or\ndue to not providing a low-level catch clause).\n\nNote\nThe reason behind a failed call can be manifold. Do not assume that\nthe error message is coming directly from the called contract:\nThe error might have happened deeper down in the call chain and the\ncalled contract just forwarded it. Also, it could be due to an\nout-of-gas situation and not a deliberate error condition:\nThe caller always retains at least 1/64th of the gas in a call and thus\neven if the called contract goes out of gas, the caller still\nhas some gas left.","tokens":7865,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264208034,"hash":"6a2a4e83816a4b312e5ca7ee45856039b291a8e7"}
{"url":"https://ethresear.ch/t/maci-and-group-bribe-attacks/12939/1","domain":"ethresear.ch","title":"MACI and group bribe attacks - zk-s[nt]arks - Ethereum Research","text":"MACI and group bribe attacks \n\n zk-s[nt]arks\n\n governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 5\n min\n\n Jun 2022\n\n 1 / 6\n\n Jun 2022\n\n Jun 25\n\n post by josojo on Jun 25, 2022\n\n josojo\n\n MACI and collective bribes:\nMACI is a great infrastructure to prevent collusion for governance processes like voting. It offers a mechanism ensuring that no one can reliably bribe individuals.\nHowever, bribing does not have to target individuals directly: E.g. all actors could also be bribed as a collective to favor a particular outcome. This post describes the bribe attacks targeting collectives and investigates possible solutions.\nBribing the collective\nImagine the usual MACI setup is given. We have a registry R that contains n public keys K_1,…,K_n𝐾1,…,𝐾𝑛 that are allowed to vote.\nThe bribing party will deploy a bribe contract that grants every public key of R a bribe b_i𝑏𝑖, if the briber’s preferred vote outcome wins.\nThe bribe contract can be set up completely trust-less: It can get funded before the MACI process starts, it can read the MACI outcome via smart contract calls, and hence it can distribute the grants fully trustlessly.\nAssuming this bribe contract is deployed, each voter has an additional incentive to vote for the briber’s preferred outcome, to increase the chance of the payout.\nLet’s investigate the incentives and their impacts in case of a binary election: Each voter has the option to vote either for party A or party B and a 51% majority is needed to win the election.\nFor simplicity, it is assumed that each voter has an intrinsic motivation to vote for their preferred party over the other party, and this motivation or utility can be represented by a monetary value: v_i𝑣𝑖 for the i-th voter. Of course, there will be actors that are not influenced by monetary incentives, they will always vote for their preferred outcome and then their v_i 𝑣𝑖 might be infinity.\nNow, if b_i > v_i𝑏𝑖 >𝑣𝑖, the optimal economic strategy for the voter is to vote for the briber’s preferred party, to increase the likelihood of the higher bribe payout. Hence, the briber can choose his bribe b, such that v_i<b𝑣𝑖 <𝑏 for half of the i \\in 1..n𝑖 ∈1..𝑛\nIf the briber’s preferred party wins, the bribing cost must be at least \\Sigma_{i \\in n}b = n*bΣ𝑖∈𝑛𝑏 =𝑛 ∗𝑏. If v_i =v_j𝑣𝑖 =𝑣𝑗 for all i,j, this means that the bribing party has to buy out the whole utility of all voters to influence the vote.\nLet’s compare this to a non-MACI voting process: Let’s assume that bribing individuals would be possible and that the bribing party would only pay a bribe to voters that voted for their outcome. Since each voter has ~1/n 1/𝑛 chance of being pivotal and influencing the outcome, each voter’s personal expected-value from voting is v_i/n𝑣𝑖/𝑛. Hence, as long as v_i/n < b_i𝑣𝑖/𝑛 <𝑏𝑖, the optimal strategy is to vote for the briber’s preferred party. The total cost for the briber would be: n*(b_i/n) \\simeq b_i 𝑛 ∗(𝑏𝑖/𝑛) ≃𝑏𝑖, assuming v_i<b_i𝑣𝑖 <𝑏𝑖\nHence, under the bottom line, MACI has increased the bribe costs by a factor of n by eliminating individual bribes and only allowing collective bribes for this particular scenario. This is valuable, as an attacker has to roughly buy out the utility of all voters to influence the vote.\nHowever, there are still two problems in practice:\n\nSome applications can not guarantee that the sum of their voter’s utility is higher than the value that could be extracted from their decisions. For example, many future institutions might have only a utility U for normal soulbound token holders, but the institutions have to make decisions about transactions bigger than n*U. One concrete example could be a new decentralized arbitration system - like Kleros - governed by soulbound token holders. For these applications, it is necessary to improve the ratio between bribing costs, and voter’s utility.\nSome applications might have a huge set of participants for whom a particular governance decision has only low utility. In an extreme case, if half of the voters have only an \\epsilon𝜖 utility for a specific governance decision, then the bribing cost is still only \\epsilon *n𝜖 ∗𝑛 via collective bribes. This holds true, even if for the other half of voters, the utility of this governance process is very high, and they would be hard to bribe.\n\nCountering group bribe attacks:\nNext, let’s investigate how MACI can be improved to defend better against collective bribes. At first, one observes that for MACI processes with a public outcome, collective bribes can always be started in a trustless way, with the setup described above. Secondly, the bribe payout can be improved to prevent negative karma for bribed voters: By using technology – similar to tornado cash -, bribes can be paid to the participants in a non-trackable way by giving each public voter key the ability to claim their bribes into a new address in a non-trackable manner. This could be enabled by preparing for each voter a note (cf. tornado cash notes) which can only be claimed by a zk-proof that can only be generated with the private key of the voter.\nIn the context of soulbound tokens, this means that bribed soulbound tokens would not receive negative karma, as no one could prove that they misbehaved.\nSince collective bribes can not be easily prevented, in the following a method is proposed to increase the cost-factor of collective bribes compared to individual bribes beyond the sum of the utility of all voters. Fortunately, by introducing a small specification change, this can be archived:\nIncreasing the cost of group bribing attacks with fake voters:\nImagine the registry R contains not just the n public keys K_1,…,K_n𝐾1,…,𝐾𝑛 but also for each key K_i𝐾𝑖 a voting weight vector (w_{i1}, w_{i2}, … w_{in})(𝑤𝑖1,𝑤𝑖2,…𝑤𝑖𝑛) is given. The weights are non-public information and are only known by the maintainer of R and by the voting operator.\nAt the start, the registry R is empty. For adding new k𝑘 public keys to the registry, the maintainer would add s*k𝑠 ∗𝑘 accounts to the registry. The k*(s-1)𝑘 ∗(𝑠 −1) additional accounts will be fake accounts that have a voting weight vector of only zeros (0, … ,0)(0,…,0). This can be done in a trust-less manner: the operator could generate a zk-proof that (s-1)*k(𝑠 −1) ∗𝑘 of the added accounts have a zero voting weight vector.\nIn the setting of soulbound token, the determination and addition of weights could also happen in a trustless manner: E.g. for each non-zero weight of a newly added account, there could be the requirement for a verification process that outputs a zk-proof verifying the correctness of the weight addition. Via recursion, these proofs could be used to build an overall zk-proof verifying that all weights for a registry were updated correctly.\nThese proven properties must be NOT publicly known about the soulbound token holder and must be only shared with the operator. If the account holder shared these properties openly and would be able to prove certain properties to a bribing party, the account holder would get bribable and hence should be removed from the registry again. The voting weight vectors can then later be used arbitrarily by the voting algorithms.\nGiven this setup, imagine an attacker wants to start a collective bribe. Since an external attacker can not know who of the voters in the registry are fake voters, they have to bribe all voters in the registry. Hence, for n valid voters with positive voting weights, the briber has to bribe s*n𝑠 ∗𝑛 public keys. This increases the cost of collective bribing by a factor s𝑠, where s𝑠 is theoretically arbitrary large, but for sure will have practical limitations. If someone started a collective bribe, the registry maintainer should have access to all fake accounts and also claim the bribe rewards for the fake accounts, to incur a cost for the collective briber.\nThis approach is promising, as the collective bribes can be made arbitrarily ineffective by increasing the number s𝑠.\nHowever, this setup will only work, if the privacy of the real voters is guaranteed. If the voters are known or can be derived statistically, the protection will not work, as the briber can just bribe the collective of likely voters.\nThis is tricky in many applications: Image a DAO that wants to recruit their voters from the crowd of soulbound tokens holders that fulfill some criteria/metric. If the information about the criteria is public, then the briber can just bribe the soulbound addresses directly instead of the addresses in the registry R. Hence, each DAO has to source their voters from a huge set of potential accounts with non-public properties/information about these accounts. The information must be private, but still, this information must be verifiable to the registry R maintainer to facilitate the assignment of the correct voting weights.\nOpen questions\n\nAre there other ideas for protecting MACI setup from collective bribes? I am all ears!\n\nHow important is bribe resistance against bribes of the collective in practice?\n\nI am really curious about your thoughts.\n\n 2\n\n read \n\n 5\n min\n\n 4 years later\n\n post by hyeonleee on Jan 7\n\n 5 months later\n\n post by josojo on May 29\n\n post by MaxBrych on Jun 1\n\n post by 71104 on Jun 1\n\n 23 days later\n\n post by Dede-Qorqud on Jun 25\n\n Powered by Discourse","tokens":2345,"squid":"ink-research","role":"Deep Scholar","at":1791264218029,"hash":"f49ee6360304032a1a9627b62ed85cd619086347"}
{"url":"https://docs.soliditylang.org/en/develop/types.html","domain":"docs.soliditylang.org","title":"Types — Solidity 0.8.38-develop documentation","text":"Types\n\n Edit on GitHub\n\nTypes\nSolidity is a statically typed language, which means that the type of each\nvariable (state and local) needs to be specified.\nSolidity provides several elementary types which can be combined to form complex types.\nIn addition, types can interact with each other in expressions containing\noperators. For a quick reference of the various operators, see Order of Precedence of Operators.\nThe concept of “undefined” or “null” values does not exist in Solidity, but newly\ndeclared variables always have a default value dependent\non its type. To handle any unexpected values, you should use the revert function to revert the whole transaction, or return a\ntuple with a second bool value denoting success.\n\nValue Types\nThe following are called value types because their variables will always be passed by value, i.e. they are always copied when they\nare used as function arguments or in assignments.\nUnlike reference types, value type declarations do not\nspecify a data location since they are small enough to be stored on the stack.\nThe only exception is state variables.\nThose are by default located in storage, but can also be marked as\ntransient, constant or immutable.\n\nBooleans\nbool: The possible values are constants true and false.\nOperators:\n\n! (logical negation)\n&& (logical conjunction, “and”)\n|| (logical disjunction, “or”)\n== (equality)\n!= (inequality)\n\nThe operators || and && apply the common short-circuiting rules. This means that in the expression f(x) || g(y), if f(x) evaluates to true, g(y) will not be evaluated even if it may have side-effects.\n\nIntegers\nint / uint: Signed and unsigned integers of various sizes. Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.\nOperators:\n\nComparisons: <=, <, ==, !=, >=, > (evaluate to bool)\nBit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)\nShift operators: << (left shift), >> (right shift)\nArithmetic operators: +, -, unary - (only for signed integers), *, /, % (modulo), ** (exponentiation)\n\nFor an integer type X, you can use type(X).min and type(X).max to\naccess the minimum and maximum value representable by the type.\n\nWarning\nIntegers in Solidity are restricted to a certain range. For example, with uint32, this is 0 up to 2**32 - 1.\nThere are two modes in which arithmetic is performed on these types: The “wrapping” or “unchecked” mode and the “checked” mode.\nBy default, arithmetic is always “checked”, meaning that if an operation’s result falls outside the value range\nof the type, the call is reverted through a failing assertion. You can switch to “unchecked” mode\nusing unchecked { ... }. More details can be found in the section about unchecked.\n\nComparisons\nThe value of a comparison is the one obtained by comparing the integer value.\n\nBit operations\nBit operations are performed on the two’s complement representation of the number.\nThis means that, for example ~int256(0) == int256(-1).\n\nShifts\nThe result of a shift operation has the type of the left operand, truncating the result to match the type.\nThe right operand must be of unsigned type, trying to shift by a signed type will produce a compilation error.\nShifts can be “simulated” using multiplication by powers of two in the following way. Note that the truncation\nto the type of the left operand is always performed at the end, but not mentioned explicitly.\n\nx << y is equivalent to the mathematical expression x * 2**y.\nx >> y is equivalent to the mathematical expression x / 2**y, rounded towards negative infinity.\n\nWarning\nBefore version 0.5.0 a right shift x >> y for negative x was equivalent to\nthe mathematical expression x / 2**y rounded towards zero,\ni.e., right shifts used rounding up (towards zero) instead of rounding down (towards negative infinity).\n\nNote\nOverflow checks are never performed for shift operations as they are done for arithmetic operations.\nInstead, the result is always truncated.\n\nAddition, Subtraction and Multiplication\nAddition, subtraction and multiplication have the usual semantics, with two different\nmodes in regard to over- and underflow:\nBy default, all arithmetic is checked for under- or overflow, but this can be disabled\nusing the unchecked block, resulting in wrapping arithmetic. More details\ncan be found in that section.\nThe expression -x is equivalent to (T(0) - x) where\nT is the type of x. It can only be applied to signed types.\nThe value of -x can be\npositive if x is negative. There is another caveat also resulting\nfrom two’s complement representation:\nIf you have int x = type(int).min;, then -x does not fit the positive range.\nThis means that unchecked { assert(-x == x); } works, and the expression -x\nwhen used in checked mode will result in a failing assertion.\n\nDivision\nSince the type of the result of an operation is always the type of one of\nthe operands, division on integers always results in an integer.\nIn Solidity, division rounds towards zero. This means that int256(-5) / int256(2) == int256(-2).\nNote that in contrast, division on literals results in fractional values\nof arbitrary precision.\n\nNote\nDivision by zero causes a Panic error. This check can not be disabled through unchecked { ... }.\n\nNote\nThe expression type(int).min / (-1) is the only case where division causes an overflow.\nIn checked arithmetic mode, this will cause a failing assertion, while in wrapping\nmode, the value will be type(int).min.\n\nModulo\nThe modulo operation a % n yields the remainder r after the division of the operand a\nby the operand n, where q = int(a / n) and r = a - (n * q). This means that modulo\nresults in the same sign as its left operand (or zero) and a % n == -(-a % n) holds for negative a:\n\nint256(5) % int256(2) == int256(1)\nint256(5) % int256(-2) == int256(1)\nint256(-5) % int256(2) == int256(-1)\nint256(-5) % int256(-2) == int256(-1)\n\nNote\nModulo with zero causes a Panic error. This check can not be disabled through unchecked { ... }.\n\nExponentiation\nExponentiation is only available for unsigned types in the exponent. The resulting type\nof an exponentiation is always equal to the type of the base. Please take care that it is\nlarge enough to hold the result and prepare for potential assertion failures or wrapping behavior.\n\nNote\nIn checked mode, exponentiation only uses the comparatively cheap exp opcode for small bases.\nFor the cases of x**3, the expression x*x*x might be cheaper.\nIn any case, gas cost tests and the use of the optimizer are advisable.\n\nNote\nNote that 0**0 is defined by the EVM as 1.\n\nFixed Point Numbers\n\nWarning\nFixed point numbers are not fully supported by Solidity yet. They can be declared, but\ncannot be assigned to or from.\n\nfixed / ufixed: Signed and unsigned fixed point number of various sizes. Keywords ufixedMxN and fixedMxN, where M represents the number of bits taken by\nthe type and N represents how many decimal points are available. M must be divisible by 8 and goes from 8 to 256 bits. N must be between 0 and 80, inclusive.\nufixed and fixed are aliases for ufixed128x18 and fixed128x18, respectively.\nOperators:\n\nComparisons: <=, <, ==, !=, >=, > (evaluate to bool)\nArithmetic operators: +, -, unary -, *, /, % (modulo)\n\nNote\nThe main difference between floating point (float and double in many languages, more precisely IEEE 754 numbers) and fixed point numbers is\nthat the number of bits used for the integer and the fractional part (the part after the decimal dot) is flexible in the former, while it is strictly\ndefined in the latter. Generally, in floating point almost the entire space is used to represent the number, while only a small number of bits define\nwhere the decimal point is.\n\nAddress\nThe address type comes in two largely identical flavors:\n\naddress: Holds a 20 byte value (size of an Ethereum address).\naddress payable: Same as address, but with the additional members transfer and send.\n\nThe idea behind this distinction is that address payable is an address you can send Ether to,\nwhile you are not supposed to send Ether to a plain address, for example because it might be a smart contract\nthat was not built to accept Ether.\nType conversions:\nImplicit conversions from address payable to address are allowed, whereas conversions from address to address payable\nmust be explicit via payable(<address>).\nExplicit conversions to and from address are allowed for uint160, integer literals,\nbytes20 and contract types.\nOnly expressions of type address and contract type can be converted to the type address\npayable via the explicit conversion payable(...). For contract-type, this conversion is only\nallowed if the contract can receive Ether, i.e., the contract either has a receive or a payable fallback function. Note that payable(0) is valid and is\nan exception to this rule.\n\nNote\nIf you need a variable of type address and plan to send Ether to it, then\ndeclare its type as address payable to make this requirement visible. Also,\ntry to make this distinction or conversion as early as possible.\nThe distinction between address and address payable was introduced in version 0.5.0.\nAlso starting from that version, contracts are not implicitly convertible to the address type, but can still be explicitly converted to\naddress or to address payable, if they have a receive or payable fallback function.\n\nOperators:\n\n<=, <, ==, !=, >= and >\n\nWarning\nIf you convert a type that uses a larger byte size to an address, for example bytes32, then the address is truncated.\nTo reduce conversion ambiguity, starting with version 0.4.24, the compiler will force you to make the truncation explicit in the conversion.\nTake for example the 32-byte value 0x111122223333444455556666777788889999AAAABBBBCCCCDDDDEEEEFFFFCCCC.\nYou can use address(bytes20(b)), which results in 0x111122223333444455556666777788889999aAaa,\nor you can use address(uint160(uint256(b))), which results in 0x777788889999AaAAbBbbCcccddDdeeeEfFFfCcCc.\n\nNote\nMixed-case hexadecimal numbers conforming to EIP-55 are automatically treated as literals of the address type. See Address Literals.\n\nMembers of Addresses\nFor a quick reference of all members of address, see Members of Address Types.\n\nbalance and transfer\n\nIt is possible to query the balance of an address using the property balance\nand to send Ether (in units of wei) to a payable address using the transfer function:\nopen in Remix\naddress payable x = payable(0x123);\naddress myAddress = address(this);\nif (x.balance < 10 && myAddress.balance >= 10) x.transfer(10);\n\nThe transfer function fails if the balance of the current contract is not large enough\nor if the Ether transfer is rejected by the receiving account. The transfer function\nreverts on failure.\n\nNote\nIf x is a contract address, its code (more specifically: its Receive Ether Function, if present, or otherwise its Fallback Function, if present) will be executed together with the transfer call (this is a feature of the EVM and cannot be prevented). If that execution runs out of gas or fails in any way, the Ether transfer will be reverted and the current contract will stop with an exception.\n\nWarning\ntransfer is deprecated and scheduled for removal.\nSimple ether transfers can still be performed using the call function\nwith with an optionally provided maximum amount of gas and empty payload, i.e., call{value: <amount>}(\"\").\nBy default this forwards all the remaining gas, subject to additional limits imposed by some EVM versions\n(such as the 63/64th rule introduced by tangerineWhistle).\nAs with any external call, the gas call option can be used to set a lower limit.\nWhile it is possible to recreate the functionality by explicitly setting the limit to the value of the stipend (2300 gas),\nthis value no longer holds its original meaning due to changing opcode costs.\nIt is recommended to use different means to protect against reentrancy.\n\nsend\n\nsend is the low-level counterpart of transfer. If the execution fails, the current contract will not stop with an exception, but send will return false.\n\nWarning\nThere are some dangers in using send: The transfer fails if the call stack depth is at 1024\n(this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order\nto make safe Ether transfers, always check the return value of send, use transfer or even better:\nuse a pattern where the recipient withdraws the Ether.\n\nWarning\nsend is deprecated and scheduled for removal.\nSimple ether transfers can still be performed using the call function\nwith with an optionally provided maximum amount of gas and empty payload, i.e., call{value: <amount>}(\"\").\nBy default this forwards all the remaining gas, subject to additional limits imposed by some EVM versions\n(such as the 63/64th rule introduced by tangerineWhistle).\nAs with any external call, the gas call option can be used to set a lower limit.\nWhile it is possible to recreate the functionality by explicitly setting the limit to the value of the stipend (2300 gas),\nthis value no longer holds its original meaning due to changing opcode costs.\nIt is recommended to use different means to protect against reentrancy.\n\ncall, delegatecall and staticcall\n\nIn order to interface with contracts that do not adhere to the ABI,\nor to get more direct control over the encoding,\nthe functions call, delegatecall and staticcall are provided.\nThey all take a single bytes memory parameter and\nreturn the success condition (as a bool) and the returned data\n(bytes memory).\nThe functions abi.encode, abi.encodePacked, abi.encodeWithSelector\nand abi.encodeWithSignature can be used to encode structured data.\nExample:\nopen in Remix\nbytes memory payload = abi.encodeWithSignature(\"register(string)\", \"MyName\");\n(bool success, bytes memory returnData) = address(nameReg).call(payload);\nrequire(success);\n\nWarning\nAll these functions are low-level functions and should be used with care.\nSpecifically, any unknown contract might be malicious and if you call it, you\nhand over control to that contract which could in turn call back into\nyour contract, so be prepared for changes to your state variables\nwhen the call returns. The regular way to interact with other contracts\nis to call a function on a contract object (x.f()).\n\nNote\nPrevious versions of Solidity allowed these functions to receive\narbitrary arguments and would also handle a first argument of type\nbytes4 differently. These edge cases were removed in version 0.5.0.\n\nIt is possible to adjust the supplied gas with the gas modifier:\nopen in Remix\naddress(nameReg).call{gas: 1000000}(abi.encodeWithSignature(\"register(string)\", \"MyName\"));\n\nSimilarly, the supplied Ether value can be controlled too:\nopen in Remix\naddress(nameReg).call{value: 1 ether}(abi.encodeWithSignature(\"register(string)\", \"MyName\"));\n\nLastly, these modifiers can be combined. Their order does not matter:\nopen in Remix\naddress(nameReg).call{gas: 1000000, value: 1 ether}(abi.encodeWithSignature(\"register(string)\", \"MyName\"));\n\nIn a similar way, the function delegatecall can be used: the difference is that only the code of the given address is used, all other aspects (storage, balance, …) are taken from the current contract. The purpose of delegatecall is to use library code which is stored in another contract. The user has to ensure that the layout of storage in both contracts is suitable for delegatecall to be used.\n\nNote\nPrior to homestead, only a limited variant called callcode was available that did not provide access to the original msg.sender and msg.value values. This function was removed in version 0.5.0.\n\nSince byzantium staticcall can be used as well. This is basically the same as call, but will revert if the called function modifies the state in any way.\nAll three functions call, delegatecall and staticcall are very low-level functions and should only be used as a last resort as they break the type-safety of Solidity.\nThe gas option is available on all three methods, while the value option is only available\non call.\n\nNote\nIt is best to avoid relying on hardcoded gas values in your smart contract code,\nregardless of whether state is read from or written to, as this can have many pitfalls.\nAlso, access to gas might change in the future.\n\ncode and codehash\n\nYou can query the deployed code for any smart contract. Use .code to get the EVM bytecode as a\nbytes memory, which might be empty. Use .codehash to get the Keccak-256 hash of that code\n(as a bytes32). Note that addr.codehash is cheaper than using keccak256(addr.code).\n\nWarning\nThe output of addr.codehash may be 0 if the account associated with addr is empty or non-existent\n(i.e., it has no code, zero balance, and zero nonce as defined by EIP-161).\nIf the account has no code but a non-zero balance or nonce, then addr.codehash will output the Keccak-256 hash of empty data\n(i.e., keccak256(\"\") which is equal to c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470), as defined by\nEIP-1052.\n\nNote\nAll contracts can be converted to address type, so it is possible to query the balance of the\ncurrent contract using address(this).balance.\n\nContract Types\nEvery contract defines its own type.\nYou can implicitly convert contracts to contracts they inherit from.\nContracts can be explicitly converted to and from the address type.\nExplicit conversion to and from the address payable type is only possible\nif the contract type has a receive or payable fallback function. The conversion is still\nperformed using address(x). If the contract type does not have a receive or payable\nfallback function, the conversion to address payable can be done using\npayable(address(x)).\nYou can find more information in the section about\nthe address type.\n\nNote\nBefore version 0.5.0, contracts directly derived from the address type\nand there was no distinction between address and address payable.\n\nIf you declare a local variable of contract type (MyContract c), you can call\nfunctions on that contract. Take care to assign it from somewhere that is the\nsame contract type.\nYou can also instantiate contracts (which means they are newly created). You\ncan find more details in the ‘Contracts via new’\nsection.\nThe data representation of a contract is identical to that of the address\ntype and this type is also used in the ABI.\nContracts do not support any operators.\nThe members of contract types are the external functions of the contract\nincluding any state variables marked as public.\nFor a contract C you can use type(C) to access\ntype information about the contract.\n\nFixed-size byte arrays\nThe value types bytes1, bytes2, bytes3, …, bytes32\nhold a sequence of bytes from one to up to 32.\nOperators:\n\nComparisons: <=, <, ==, !=, >=, > (evaluate to bool)\nBit operators: &, |, ^ (bitwise exclusive or), ~ (bitwise negation)\nShift operators: << (left shift), >> (right shift)\nIndex access: If x is of type bytesI, then x[k] for 0 <= k < I returns the k th byte (read-only).\n\nThe shifting operator works with unsigned integer type as right operand (but\nreturns the type of the left operand), which denotes the number of bits to shift by.\nShifting by a signed type will produce a compilation error.\nMembers:\n\n.length yields the fixed length of the byte array (read-only).\n\nNote\nThe type bytes1[] is an array of bytes, but due to padding rules, it wastes\n31 bytes of space for each element (except in storage). It is better to use the bytes\ntype instead.\n\nNote\nPrior to version 0.8.0, byte used to be an alias for bytes1.\n\nAddress Literals\nHexadecimal literals that pass the address checksum test, for example\n0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF are of address type.\nHexadecimal literals that are between 39 and 41 digits\nlong and do not pass the checksum test produce\nan error. You can prepend (for integer types) or append (for bytesNN types) zeros to remove the error.\n\nNote\nThe mixed-case address checksum format is defined in EIP-55.\n\nRational and Integer Literals\nInteger literals are formed from a sequence of digits in the range 0-9.\nThey are interpreted as decimals. For example, 69 means sixty nine.\nOctal literals do not exist in Solidity and leading zeros are invalid.\nDecimal fractional literals are formed by a . with at least one number after the decimal point.\nExamples include .1 and 1.3 (but not 1.).\nScientific notation in the form of 2e10 is also supported, where the\nmantissa can be fractional but the exponent has to be an integer.\nThe literal MeE is equivalent to M * 10**E.\nExamples include 2e10, -2e10, 2e-10, 2.5e1.\nUnderscores can be used to separate the digits of a numeric literal to aid readability.\nFor example, decimal 123_000, hexadecimal 0x2eff_abde, scientific decimal notation 1_2e345_678 are all valid.\nUnderscores are only allowed between two digits and only one consecutive underscore is allowed.\nThere is no additional semantic meaning added to a number literal containing underscores,\nthe underscores are ignored.\nNumber literal expressions retain arbitrary precision until they are converted to a non-literal type (i.e. by\nusing them together with anything other than a number literal expression (like boolean literals) or by explicit conversion).\nThis means that computations do not overflow and divisions do not truncate\nin number literal expressions.\nFor example, (2**800 + 1) - 2**800 results in the constant 1 (of type uint8)\nalthough intermediate results would not even fit the machine word size. Furthermore, .5 * 8 results\nin the integer 4 (although non-integers were used in between).\n\nWarning\nWhile most operators produce a literal expression when applied to literals, there are certain operators that do not follow this pattern:\n\nTernary operator (... ? ... : ...),\nArray subscript (<array>[<index>]).\n\nYou might expect expressions like 255 + (true ? 1 : 0) or 255 + [1, 2, 3][0] to be equivalent to using the literal 256\ndirectly, but in fact they are computed within the type uint8 and can overflow.\n\nAny operator that can be applied to integers can also be applied to number literal expressions as\nlong as the operands are integers. If any of the two is fractional, bit operations are disallowed\nand exponentiation is disallowed if the exponent is fractional (because that might result in\na non-rational number).\nShifts and exponentiation with literal numbers as left (or base) operand and integer types\nas the right (exponent) operand are always performed\nin the uint256 (for non-negative literals) or int256 (for a negative literals) type,\nregardless of the type of the right (exponent) operand.\n\nWarning\nDivision on integer literals used to truncate in Solidity prior to version 0.4.0, but it now converts into a rational number, i.e. 5 / 2 is not equal to 2, but to 2.5.\n\nNote\nSolidity has a number literal type for each rational number.\nInteger literals and rational number literals belong to number literal types.\nMoreover, all number literal expressions (i.e. the expressions that\ncontain only number literals and operators) belong to number literal\ntypes. So the number literal expressions 1 + 2 and 2 + 1 both\nbelong to the same number literal type for the rational number three.\n\nNote\nNumber literal expressions are converted into a non-literal type as soon as they are used with non-literal\nexpressions. Disregarding types, the value of the expression assigned to b\nbelow evaluates to an integer. Because a is of type uint128, the\nexpression 2.5 + a has to have a proper type, though. Since there is no common type\nfor the type of 2.5 and uint128, the Solidity compiler does not accept\nthis code.\n\nopen in Remix\nuint128 a = 1;\nuint128 b = 2.5 + a + 0.5;\n\nString Literals and Types\nString literals are written with either double or single-quotes (\"foo\" or 'bar'), and they can also be split into multiple consecutive parts (\"foo\" \"bar\" is equivalent to \"foobar\") which can be helpful when dealing with long strings. They do not imply trailing zeroes as in C; \"foo\" represents three bytes, not four. As with integer literals, their type can vary, but they are implicitly convertible to bytes1, …, bytes32, if they fit, to bytes and to string.\nFor example, with bytes32 samevar = \"stringliteral\" the string literal is interpreted in its raw byte form when assigned to a bytes32 type.\nString literals can only contain printable ASCII characters, which means the characters between and including 0x20 .. 0x7E.\nAdditionally, string literals also support the following escape characters:\n\n\\<newline> (escapes an actual newline)\n\\\\ (backslash)\n\\' (single quote)\n\\\" (double quote)\n\\n (newline)\n\\r (carriage return)\n\\t (tab)\n\\xNN (hex escape, see below)\n\\uNNNN (unicode escape, see below)\n\n\\xNN takes a hex value and inserts the appropriate byte, while \\uNNNN takes a Unicode codepoint and inserts an UTF-8 sequence.\n\nNote\nUntil version 0.8.0 there were three additional escape sequences: \\b, \\f and \\v.\nThey are commonly available in other languages but rarely needed in practice.\nIf you do need them, they can still be inserted via hexadecimal escapes, i.e. \\x08, \\x0c\nand \\x0b, respectively, just as any other ASCII character.\n\nThe string in the following example has a length of ten bytes.\nIt starts with a newline byte, followed by a double quote, a single\nquote a backslash character and then (without separator) the\ncharacter sequence abcdef.\nopen in Remix\n\"\\n\\\"\\'\\\\abc\\\ndef\"\n\nAny Unicode line terminator which is not a newline (i.e. LF, VF, FF, CR, NEL, LS, PS) is considered to\nterminate the string literal. Newline only terminates the string literal if it is not preceded by a \\.\n\nUnicode Literals\nWhile regular string literals can only contain ASCII, Unicode literals – prefixed with the keyword unicode – can contain any valid UTF-8 sequence.\nThey also support the very same escape sequences as regular string literals.\nopen in Remix\nstring memory a = unicode\"Hello 😃\";\n\nHexadecimal Literals\nHexadecimal literals are prefixed with the keyword hex and are enclosed in double\nor single-quotes (hex\"001122FF\", hex'0011_22_FF'). Their content must be\nhexadecimal digits which can optionally use a single underscore as separator between\nbyte boundaries. The value of the literal will be the binary representation\nof the hexadecimal sequence.\nMultiple hexadecimal literals separated by whitespace are concatenated into a single literal:\nhex\"00112233\" hex\"44556677\" is equivalent to hex\"0011223344556677\"\nHexadecimal literals in some ways behave like string literals but are not\nimplicitly convertible to the string type.\n\nEnums\nEnums are one way to create a user-defined type in Solidity. They are explicitly convertible\nto and from all unsigned integer types but implicit conversion is not allowed. The explicit conversion\nfrom integer checks at runtime that the value lies inside the range of the enum and causes a\nPanic error otherwise.\nEnums require at least one member, and its default value when declared is the first member.\nEnums cannot have more than 256 members.\nThe data representation is the same as for enums in C: The options are represented by\nsubsequent unsigned integer values starting from 0.\nUsing type(NameOfEnum).min and type(NameOfEnum).max you can get the\nsmallest and respectively largest value of the given enum.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.8;\n\ncontract test {\n enum ActionChoices { GoLeft, GoRight, GoStraight, SitStill }\n ActionChoices choice;\n ActionChoices constant defaultChoice = ActionChoices.GoStraight;\n\n function setGoStraight() public {\n choice = ActionChoices.GoStraight;\n }\n\n // Since enum types are not part of the ABI, the signature of \"getChoice\"\n // will automatically be changed to \"getChoice() returns (uint8)\"\n // for all matters external to Solidity.\n function getChoice() public view returns (ActionChoices) {\n return choice;\n }\n\n function getDefaultChoice() public pure returns (uint) {\n return uint(defaultChoice);\n }\n\n function getLargestValue() public pure returns (ActionChoices) {\n return type(ActionChoices).max;\n }\n\n function getSmallestValue() public pure returns (ActionChoices) {\n return type(ActionChoices).min;\n }\n}\n\nNote\nEnums can also be declared on the file level, outside of contract or library definitions.\n\nUser-defined Value Types\nA user-defined value type allows creating a zero cost abstraction over an elementary value type.\nThis is similar to an alias, but with stricter type requirements.\nA user-defined value type is defined using type C is V, where C is the name of the newly\nintroduced type and V has to be a built-in value type (the “underlying type”). The function\nC.wrap is used to convert from the underlying type to the custom type. Similarly, the\nfunction C.unwrap is used to convert from the custom type to the underlying type.\nThe type C does not have any operators or attached member functions. In particular, even the\noperator == is not defined. Explicit and implicit conversions to and from other types are\ndisallowed.\nThe data-representation of values of such types are inherited from the underlying type\nand the underlying type is also used in the ABI.\nThe following example illustrates a custom type UFixed256x18 representing a decimal fixed point\ntype with 18 decimals and a minimal library to do arithmetic operations on the type.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.8;\n\n// Represent a 18 decimal, 256 bit wide fixed point type using a user-defined value type.\ntype UFixed256x18 is uint256;\n\n/// A minimal library to do fixed point operations on UFixed256x18.\nlibrary FixedMath {\n uint constant multiplier = 10**18;\n\n /// Adds two UFixed256x18 numbers. Reverts on overflow, relying on checked\n /// arithmetic on uint256.\n function add(UFixed256x18 a, UFixed256x18 b) internal pure returns (UFixed256x18) {\n return UFixed256x18.wrap(UFixed256x18.unwrap(a) + UFixed256x18.unwrap(b));\n }\n /// Multiplies UFixed256x18 and uint256. Reverts on overflow, relying on checked\n /// arithmetic on uint256.\n function mul(UFixed256x18 a, uint256 b) internal pure returns (UFixed256x18) {\n return UFixed256x18.wrap(UFixed256x18.unwrap(a) * b);\n }\n /// Take the floor of a UFixed256x18 number.\n /// @return the largest integer that does not exceed `a`.\n function floor(UFixed256x18 a) internal pure returns (uint256) {\n return UFixed256x18.unwrap(a) / multiplier;\n }\n /// Turns a uint256 into a UFixed256x18 of the same value.\n /// Reverts if the integer is too large.\n function toUFixed256x18(uint256 a) internal pure returns (UFixed256x18) {\n return UFixed256x18.wrap(a * multiplier);\n }\n}\n\nNotice how UFixed256x18.wrap and FixedMath.toUFixed256x18 have the same signature but\nperform two very different operations: The UFixed256x18.wrap function returns a UFixed256x18\nthat has the same data representation as the input, whereas toUFixed256x18 returns a\nUFixed256x18 that has the same numerical value.\n\nFunction Types\nFunction types are the types of functions. Variables of a function type\ncan be assigned from functions and function parameters of function type\ncan be used to pass functions to and return functions from function calls.\nFunction types come in two flavours - internal and external functions:\nInternal functions can only be called inside the current contract (more specifically,\ninside the current code unit, which also includes internal library functions\nand inherited functions) because they cannot be executed outside of the\ncontext of the current contract. Calling an internal function is realized\nby jumping to its entry label, just like when calling a function of the current\ncontract internally.\nExternal functions consist of an address and a function signature and they can\nbe passed via and returned from external function calls.\nNote that public functions of the current contract can be used both as an\ninternal and as an external function. To use f as an internal function,\njust use f, if you want to use its external form, use this.f.\nIf a function type variable is not initialised, calling it results\nin a Panic error. The same happens if you call a function after using delete\non it.\n\nNote\nLambda or inline functions are planned but not yet supported.\n\nDeclaration syntax\nFunction types are notated as follows:\nopen in Remix\nfunction (<parameter types>) {internal|external} [pure|view|payable] [returns (<return types>)]\n\nIn contrast to the parameter types, the return types cannot be empty - if the\nfunction type should not return anything, the whole returns (<return types>)\npart has to be omitted.\nBy default, function types are internal, so the internal keyword can be\nomitted. Note that this only applies to function types. Visibility has\nto be specified explicitly for functions defined in contracts, they\ndo not have a default.\n\nConversions\nA function type A is implicitly convertible to a function type B if and only if\ntheir parameter types are identical, their return types are identical,\ntheir internal/external property is identical and the state mutability of A\nis more restrictive than the state mutability of B. In particular:\n\npure functions can be converted to view and non-payable functions\nview functions can be converted to non-payable functions\npayable functions can be converted to non-payable functions\n\nNo other conversions between function types are possible.\nThe rule about payable and non-payable might be a little\nconfusing, but in essence, if a function is payable, this means that it\nalso accepts a payment of zero Ether, so it also is non-payable.\nOn the other hand, a non-payable function will reject Ether sent to it,\nso non-payable functions cannot be converted to payable functions.\nTo clarify, rejecting ether is more restrictive than not rejecting ether.\nThis means you can override a payable function with a non-payable but not the\nother way around.\nAdditionally, When you define a non-payable function pointer,\nthe compiler does not enforce that the pointed function will actually reject ether.\nInstead, it enforces that the function pointer is never used to send ether.\nWhich makes it possible to assign a payable function pointer to a non-payable\nfunction pointer ensuring both types behave the same way, i.e, both cannot be used\nto send ether.\nIf external function types are used outside of the context of Solidity,\nthey are treated as the function type, which encodes the address\nfollowed by the function identifier together in a single bytes24 type.\nA function of an internal type can be assigned to a variable of an internal function type regardless\nof where it is defined.\nThis includes private, internal and public functions of both contracts and libraries as well as free\nfunctions.\nExternal function types, on the other hand, are only compatible with public and external contract\nfunctions.\n\nNote\nExternal functions with calldata parameters are incompatible with external function types with calldata parameters.\nThey are compatible with the corresponding types with memory parameters instead.\nFor example, there is no function that can be pointed at by a value of type function (string calldata) external while\nfunction (string memory) external can point at both function f(string memory) external {} and\nfunction g(string calldata) external {}.\nThis is because for both locations the arguments are passed to the function in the same way.\nThe caller cannot pass its calldata directly to an external function and always ABI-encodes the arguments into memory.\nMarking the parameters as calldata only affects the implementation of the external function and is\nmeaningless in a function pointer on the caller’s side.\n\nWarning\nComparison of internal function pointers can have unexpected results in the legacy pipeline with the optimizer enabled,\nas it can collapse identical functions into one, which will then lead to said function pointers comparing as equal instead of not.\nSuch comparisons are not advised, and will lead to the compiler issuing a warning, until the next breaking release (0.9.0),\nwhen the warning will be upgraded to an error, thereby making such comparisons disallowed.\n\nLibraries are excluded because they require a delegatecall and use a different ABI\nconvention for their selectors.\nFunctions declared in interfaces do not have definitions so pointing at them does not make sense either.\n\nMembers\nExternal (or public) functions have the following members:\n\n.address returns the address of the contract of the function.\n.selector returns the ABI function selector\n\nNote\nExternal (or public) functions used to have the additional members\n.gas(uint) and .value(uint). These were deprecated in Solidity 0.6.2\nand removed in Solidity 0.7.0. Instead use {gas: ...} and {value: ...}\nto specify the amount of gas or the amount of wei sent to a function,\nrespectively. See External Function Calls for\nmore information.\n\nValue stability across contract updates\nAn important aspect to consider when using values of function types is whether the value will\nremain valid if the underlying code changes.\nThe state of the blockchain is not completely immutable and there are multiple ways to place\ndifferent code under the same address:\n\nDirectly deploying different code using salted contract creation.\nDelegating to a different contract via DELEGATECALL\n(upgradeable code behind a proxy contract is a common example of this).\nAccount abstraction as defined by EIP-7702.\n\nExternal function types can be considered as stable as contract’s ABI, which makes them very portable.\nTheir ABI representation always consists of a contract address and a function selector and it is\nperfectly safe to store them long-term or pass them between contracts.\nWhile it is possible for the referenced function to change or disappear, a direct external call\nwould be affected the same way, so there is no additional risk in such use.\nIn case of internal functions, however, the value is an identifier that is strongly tied to\ncontract’s bytecode.\nThe actual representation of the identifier is an implementation detail and may change between\ncompiler versions or even between different backends.\nValues assigned under a given representation are deterministic (i.e. guaranteed to remain the same\nas long as the source code is the same) but are easily affected by changes such as adding, removing\nor reordering of functions.\nThe compiler is also free to remove internal functions that are never used, which may affect other identifiers.\nSome representations, e.g. one where identifiers are simply jump targets, may be affected by\nvirtually any change, even one completely unrelated to internal functions.\nTo counter this, the language limits the use of internal function types outside of the context in\nwhich they are valid.\nThis is why internal function types cannot be used as parameters of external functions (or in any\nother way that is exposed in contract’s ABI).\nHowever, there are still situations where it is up to the user to decide whether their use is safe or not.\nFor example long-term storage of such values in state variables is discouraged, but may be safe if\nthe contract code is never going to be updated.\nIt is also always possible to side-step any safeguards by using inline assembly.\nSuch use always needs careful consideration.\n\nNote\nThe removal of unused internal functions only takes into account explicit references to\nsuch functions by name.\nImplicit references, such as assigning a new value to a function type variable in inline assembly\nmay still lead to the removal of the function if it is not also referenced explicitly elsewhere\nin the source.\n\nExamples\nExample that shows how to use the members:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.4 <0.9.0;\n\ncontract Example {\n function f() public payable returns (bytes4) {\n assert(this.f.address == address(this));\n return this.f.selector;\n }\n\n function g() public {\n this.f{gas: 10, value: 800}();\n }\n}\n\nExample that shows how to use internal function types:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\nlibrary ArrayUtils {\n // internal functions can be used in internal library functions because\n // they will be part of the same code context\n function map(uint[] memory self, function (uint) pure returns (uint) f)\n internal\n pure\n returns (uint[] memory r)\n {\n r = new uint[](self.length);\n for (uint i = 0; i < self.length; i++) {\n r[i] = f(self[i]);\n }\n }\n\n function reduce(\n uint[] memory self,\n function (uint, uint) pure returns (uint) f\n )\n internal\n pure\n returns (uint r)\n {\n r = self[0];\n for (uint i = 1; i < self.length; i++) {\n r = f(r, self[i]);\n }\n }\n\n function range(uint length) internal pure returns (uint[] memory r) {\n r = new uint[](length);\n for (uint i = 0; i < r.length; i++) {\n r[i] = i;\n }\n }\n}\n\ncontract Pyramid {\n using ArrayUtils for *;\n\n function pyramid(uint l) public pure returns (uint) {\n return ArrayUtils.range(l).map(square).reduce(sum);\n }\n\n function square(uint x) internal pure returns (uint) {\n return x * x;\n }\n\n function sum(uint x, uint y) internal pure returns (uint) {\n return x + y;\n }\n}\n\nAnother example that uses external function types:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.22 <0.9.0;\n\ncontract Oracle {\n struct Request {\n bytes data;\n function(uint) external callback;\n }\n\n Request[] private requests;\n event NewRequest(uint);\n\n function query(bytes memory data, function(uint) external callback) public {\n requests.push(Request(data, callback));\n emit NewRequest(requests.length - 1);\n }\n\n function reply(uint requestID, uint response) public {\n // Here goes the check that the reply comes from a trusted source\n requests[requestID].callback(response);\n }\n}\n\ncontract OracleUser {\n Oracle constant private ORACLE_CONST = Oracle(address(0x00000000219ab540356cBB839Cbe05303d7705Fa)); // known contract\n uint private exchangeRate;\n\n function buySomething() public {\n ORACLE_CONST.query(\"USD\", this.oracleResponse);\n }\n\n function oracleResponse(uint response) public {\n require(\n msg.sender == address(ORACLE_CONST),\n \"Only oracle can call this.\"\n );\n exchangeRate = response;\n }\n}\n\nReference Types\nValues of reference type can be modified through multiple different names.\nContrast this with value types where you get an independent copy whenever\na variable of value type is used. Because of that, reference types have to be handled\nmore carefully than value types. Currently, reference types comprise structs,\narrays and mappings. If you use a reference type, you always have to explicitly\nprovide the data area where the type is stored: memory (whose lifetime is limited\nto an external function call), storage (the location where the state variables\nare stored, where the lifetime is limited to the lifetime of a contract)\nor calldata (special data location that contains the function arguments).\nAn assignment or type conversion that changes the data location will always incur an automatic copy operation,\nwhile assignments inside the same data location only copy in some cases for storage types.\n\nData location\nEvery reference type has an additional\nannotation, the “data location”, about where it is stored. There are three data locations:\nmemory, storage and calldata. Calldata is a non-modifiable,\nnon-persistent area where function arguments are stored, and behaves mostly like memory.\n\nNote\ntransient is not yet supported as a data location for reference types.\n\nNote\nIf you can, try to use calldata as data location because it will avoid copies and\nalso makes sure that the data cannot be modified. Arrays and structs with calldata\ndata location can also be returned from functions, but it is not possible to\nallocate such types.\n\nNote\nArrays and structs with calldata location declared in a function body\nor as its return parameters must be assigned before being used or returned.\nThere are certain cases in which non-trivial control flow is used and the compiler\ncan’t properly detect the initialization.\nA common workaround in such cases is to assign the affected variable to itself before\nthe correct initialization takes place.\n\nNote\nPrior to version 0.6.9 data location for reference-type arguments was limited to\ncalldata in external functions, memory in public functions and either\nmemory or storage in internal and private ones.\nNow memory and calldata are allowed in all functions regardless of their visibility.\n\nNote\nConstructor parameters cannot use calldata as their data location.\n\nNote\nPrior to version 0.5.0 the data location could be omitted, and would default to different locations\ndepending on the kind of variable, function type, etc., but all complex types must now give an explicit\ndata location.\n\nData location and assignment behavior\nData locations are not only relevant for persistency of data, but also for the semantics of assignments:\n\nAssignments between storage and memory (or from calldata)\nalways create an independent copy.\nAssignments from memory to memory only create references. This means\nthat changes to one memory variable are also visible in all other memory\nvariables that refer to the same data.\nAssignments from storage to a local storage variable also only\nassign a reference.\nAll other assignments to storage always copy. Examples for this\ncase are assignments to state variables or to members of local\nvariables of storage struct type, even if the local variable\nitself is just a reference.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n\ncontract C {\n // The data location of x is storage.\n // This is the only place where the\n // data location can be omitted.\n uint[] x;\n\n // The data location of memoryArray is memory.\n function f(uint[] memory memoryArray) public {\n x = memoryArray; // works, copies the whole array to storage\n uint[] storage y = x; // works, assigns a pointer, data location of y is storage\n y[7]; // fine, returns the 8th element\n y.pop(); // fine, modifies x through y\n delete x; // fine, clears the array, also modifies y\n // The following does not work; it would need to create a new temporary /\n // unnamed array in storage, but storage is \"statically\" allocated:\n // y = memoryArray;\n // Similarly, \"delete y\" is not valid, as assignments to local variables\n // referencing storage objects can only be made from existing storage objects.\n // It would \"reset\" the pointer, but there is no sensible location it could point to.\n // For more details see the documentation of the \"delete\" operator.\n // delete y;\n g(x); // calls g, handing over a reference to x\n h(x); // calls h and creates an independent, temporary copy in memory\n }\n\n function g(uint[] storage) internal pure {}\n function h(uint[] memory) public pure {}\n}\n\nArrays\nArrays can have a compile-time fixed size, or they can have a dynamic size.\nThe type of an array of fixed size k and element type T is written as T[k],\nand an array of dynamic size as T[].\nFor example, an array of 5 dynamic arrays of uint is written as\nuint[][5]. The notation is reversed compared to some other languages. In\nSolidity, X[3] is always an array containing three elements of type X,\neven if X is itself an array. This is not the case in other languages such\nas C.\nIndices are zero-based, and access is in the opposite direction of the\ndeclaration.\nFor example, if you have a variable uint[][5] memory x, you access the\nseventh uint in the third dynamic array using x[2][6], and to access the\nthird dynamic array, use x[2]. Again,\nif you have an array T[5] a for a type T that can also be an array,\nthen a[2] always has type T.\nArray elements can be of any type, including mapping or struct. The general\nrestrictions for types apply, in that mappings can only be stored in the\nstorage data location and publicly-visible functions need parameters that are ABI types.\nIt is possible to mark state variable arrays public and have Solidity create a getter.\nThe numeric index becomes a required parameter for the getter.\nAccessing an array past its end causes a failing assertion. Methods .push() and .push(value) can be used\nto append a new element at the end of a dynamically-sized array, where .push() appends a zero-initialized element and returns\na reference to it.\n\nNote\nDynamically-sized arrays can only be resized in storage.\nIn memory, such arrays can be of arbitrary size but the size cannot be changed once an array is allocated.\n\nbytes and string as Arrays\nVariables of type bytes and string are special arrays. The bytes type is similar to bytes1[],\nbut it is packed tightly in calldata and memory. string is equal to bytes but does not allow\nlength or index access.\nSolidity does not have string manipulation functions, but there are\nthird-party string libraries. You can also compare two strings by their keccak256-hash using\nkeccak256(abi.encodePacked(s1)) == keccak256(abi.encodePacked(s2)) and\nconcatenate two strings using string.concat(s1, s2).\nYou should use bytes over bytes1[] because it is cheaper,\nsince using bytes1[] in memory adds 31 padding bytes between the elements. Note that in storage, the\npadding is absent due to tight packing, see bytes and string. As a general rule,\nuse bytes for arbitrary-length raw byte data and string for arbitrary-length\nstring (UTF-8) data. If you can limit the length to a certain number of bytes,\nalways use one of the value types bytes1 to bytes32 because they are much cheaper.\n\nNote\nIf you want to access the byte-representation of a string s, use\nbytes(s).length / bytes(s)[7] = 'x';. Keep in mind\nthat you are accessing the low-level bytes of the UTF-8 representation,\nand not the individual characters.\n\nThe functions bytes.concat and string.concat\nYou can concatenate an arbitrary number of string values using string.concat.\nThe function returns a single string memory array that contains the contents of the arguments without padding.\nIf you want to use parameters of other types that are not implicitly convertible to string, you need to convert them to string first.\nAnalogously, the bytes.concat function can concatenate an arbitrary number of bytes or bytes1 ... bytes32 values.\nThe function returns a single bytes memory array that contains the contents of the arguments without padding.\nIf you want to use string parameters or other types that are not implicitly convertible to bytes, you need to convert them to bytes or bytes1/…/bytes32 first.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.12;\n\ncontract C {\n string s = \"Storage\";\n function f(bytes calldata bc, string memory sm, bytes16 b) public view {\n string memory concatString = string.concat(s, string(bc), \"Literal\", sm);\n assert((bytes(s).length + bc.length + 7 + bytes(sm).length) == bytes(concatString).length);\n\n bytes memory concatBytes = bytes.concat(bytes(s), bc, bc[:2], \"Literal\", bytes(sm), b);\n assert((bytes(s).length + bc.length + 2 + 7 + bytes(sm).length + b.length) == concatBytes.length);\n }\n}\n\nIf you call string.concat or bytes.concat without arguments they return an empty array.\n\nAllocating Memory Arrays\nMemory arrays with dynamic length can be created using the new operator.\nAs opposed to storage arrays, it is not possible to resize memory arrays (e.g.\nthe .push member functions are not available).\nYou either have to calculate the required size in advance\nor create a new memory array and copy every element.\nAs all variables in Solidity, the elements of newly allocated arrays are always initialized\nwith the default value.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n function f(uint len) public pure {\n uint[] memory a = new uint[](7);\n bytes memory b = new bytes(len);\n assert(a.length == 7);\n assert(b.length == len);\n a[6] = 8;\n }\n}\n\nArray Literals\nAn array literal is a comma-separated list of one or more expressions, enclosed\nin square brackets ([...]). For example [1, a, f(3)]. The type of the\narray literal is determined as follows:\nIt is always a statically-sized memory array whose length is the\nnumber of expressions.\nThe base type of the array is the type of the first expression on the list such that all\nother expressions can be implicitly converted to it. It is a type error\nif this is not possible.\nIt is not enough that there is a type all the elements can be converted to. One of the elements\nhas to be of that type.\nIn the example below, the type of [1, 2, 3] is\nuint8[3] memory, because the type of each of these constants is uint8. If\nyou want the result to be a uint[3] memory type, you need to convert\nthe first element to uint.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n function f() public pure {\n g([uint(1), 2, 3]);\n }\n function g(uint[3] memory) public pure {\n // ...\n }\n}\n\nThe array literal [1, -1] is invalid because the type of the first expression\nis uint8 while the type of the second is int8 and they cannot be implicitly\nconverted to each other. To make it work, you can use [int8(1), -1], for example.\nSince fixed-size memory arrays of different type cannot be converted into each other\n(even if the base types can), you always have to specify a common base type explicitly\nif you want to use two-dimensional array literals:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n function f() public pure returns (uint24[2][4] memory) {\n uint24[2][4] memory x = [[uint24(0x1), 1], [0xffffff, 2], [uint24(0xff), 3], [uint24(0xffff), 4]];\n // The following does not work, because some of the inner arrays are not of the right type.\n // uint[2][4] memory x = [[0x1, 1], [0xffffff, 2], [0xff, 3], [0xffff, 4]];\n return x;\n }\n}\n\nFixed size memory arrays cannot be assigned to dynamically-sized\nmemory arrays, i.e. the following is not possible:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\n// This will not compile.\ncontract C {\n function f() public {\n // The next line creates a type error because uint[3] memory\n // cannot be converted to uint[] memory.\n uint[] memory x = [uint(1), 3, 4];\n }\n}\n\nIt is planned to remove this restriction in the future, but it creates some\ncomplications because of how arrays are passed in the ABI.\nIf you want to initialize dynamically-sized arrays, you have to assign the\nindividual elements:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract C {\n function f() public pure {\n uint[] memory x = new uint[](3);\n x[0] = 1;\n x[1] = 3;\n x[2] = 4;\n }\n}\n\nArray Members\n\nlength:Arrays have a length member that contains their number of elements.\nThe length of memory arrays is fixed (but dynamic, i.e. it can depend on\nruntime parameters) once they are created.\n\npush():Dynamic storage arrays and bytes (not string) have a member function\ncalled push() that you can use to append a zero-initialised element at the end of the array.\nIt returns a reference to the element, so that it can be used like\nx.push().t = 2 or x.push() = b.\n\npush(x):Dynamic storage arrays and bytes (not string) have a member function\ncalled push(x) that you can use to append a given element at the end of the array.\nThe function returns nothing.\n\npop():Dynamic storage arrays and bytes (not string) have a member\nfunction called pop() that you can use to remove an element from the\nend of the array. This also implicitly calls delete on the removed element. The function returns nothing.\n\nNote\nIncreasing the length of a storage array by calling push()\nhas constant gas costs because storage is zero-initialised,\nwhile decreasing the length by calling pop() has a\ncost that depends on the “size” of the element being removed.\nIf that element is an array, it can be very costly, because\nit includes explicitly clearing the removed\nelements similar to calling delete on them.\n\nNote\nTo use arrays of arrays in external (instead of public) functions, you need to\nactivate ABI coder v2.\n\nNote\nIn EVM versions before Byzantium, it was not possible to access\ndynamic arrays returned from function calls. If you call functions\nthat return dynamic arrays, make sure to use an EVM that is set to\nByzantium mode.\n\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.0 <0.9.0;\n\ncontract ArrayContract {\n uint[2**20] aLotOfIntegers;\n // Note that the following is not a pair of dynamic arrays but a\n // dynamic array of pairs (i.e. of fixed size arrays of length two).\n // In Solidity, T[k] and T[] are always arrays with elements of type T,\n // even if T itself is an array.\n // Because of that, bool[2][] is a dynamic array of elements\n // that are bool[2]. This is different from other languages, like C.\n // Data location for all state variables is storage.\n bool[2][] pairsOfFlags;\n\n // newPairs is stored in memory\n function setAllFlagPairs(bool[2][] memory newPairs) public {\n // assignment to a storage array performs a copy of ``newPairs`` and\n // replaces the complete array ``pairsOfFlags``.\n pairsOfFlags = newPairs;\n }\n\n struct StructType {\n uint[] contents;\n uint moreInfo;\n }\n StructType s;\n\n function f(uint[] memory c) public {\n // stores a reference to ``s`` in ``g``\n StructType storage g = s;\n // also changes ``s.moreInfo``.\n g.moreInfo = 2;\n // assigns a copy because ``g.contents``\n // is not a local variable, but a member of\n // a local variable.\n g.contents = c;\n }\n\n function setFlagPair(uint index, bool flagA, bool flagB) public {\n // access to a non-existing index will throw an exception\n pairsOfFlags[index][0] = flagA;\n pairsOfFlags[index][1] = flagB;\n }\n\n function changeFlagArraySize(uint newSize) public {\n // using push and pop is the only way to change the\n // length of an array\n if (newSize < pairsOfFlags.length) {\n while (pairsOfFlags.length > newSize)\n pairsOfFlags.pop();\n } else if (newSize > pairsOfFlags.length) {\n while (pairsOfFlags.length < newSize)\n pairsOfFlags.push();\n }\n }\n\n function clear() public {\n // these clear the arrays completely\n delete pairsOfFlags;\n delete aLotOfIntegers;\n // identical effect here\n pairsOfFlags = new bool[2][](0);\n }\n\n bytes byteData;\n\n function byteArrays(bytes memory data) public {\n // byte arrays (\"bytes\") are different as they are stored without padding,\n // but can be treated identical to \"uint8[]\"\n byteData = data;\n for (uint i = 0; i < 7; i++)\n byteData.push();\n byteData[3] = 0x08;\n delete byteData[2];\n }\n\n function addFlag(bool[2] memory flag) public returns (uint) {\n pairsOfFlags.push(flag);\n return pairsOfFlags.length;\n }\n\n function createMemoryArray(uint size) public pure returns (bytes memory) {\n // Dynamic memory arrays are created using `new`:\n uint[2][] memory arrayOfPairs = new uint[2][](size);\n\n // Inline arrays are always statically-sized and if you only\n // use literals, you have to provide at least one type.\n arrayOfPairs[0] = [uint(1), 2];\n\n // Create a dynamic byte array:\n bytes memory b = new bytes(200);\n for (uint i = 0; i < b.length; i++)\n b[i] = bytes1(uint8(i));\n return b;\n }\n}\n\nDangling References to Storage Array Elements\nWhen working with storage arrays, you need to take care to avoid dangling references.\nA dangling reference is a reference that points to something that no longer exists or has been\nmoved without updating the reference. A dangling reference can for example occur, if you store a\nreference to an array element in a local variable and then .pop() from the containing array:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.0 <0.9.0;\n\ncontract C {\n uint[][] s;\n\n function f() public {\n // Stores a pointer to the last array element of s.\n uint[] storage ptr = s[s.length - 1];\n // Removes the last array element of s.\n s.pop();\n // Writes to the array element that is no longer within the array.\n ptr.push(0x42);\n // Adding a new element to ``s`` now will not add an empty array, but\n // will result in an array of length 1 with ``0x42`` as element.\n s.push();\n assert(s[s.length - 1][0] == 0x42);\n }\n}\n\nThe write in ptr.push(0x42) will not revert, despite the fact that ptr no\nlonger refers to a valid element of s. Since the compiler assumes that unused storage\nis always zeroed, a subsequent s.push() will not explicitly write zeroes to storage,\nso the last element of s after that push() will hav","tokens":15000,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264219552,"hash":"f8a7c50e991fc3edddbd71f84050eccba2ef10fb"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-aethusdc-transfer-to-aave-usdc-contract-on-eth/25530","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH - Governance - Aave","text":"[RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 25\n\n 1 / 2\n\n Aug 25\n\n Aug 25\n\n post by bikash on Aug 25\n\n bikash\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future rescue mission.\nI accidentally transferred 49792 AETHUSDC directly to the AAVE USDC contract on ETH instead of using the “Supply” function in the Aave App.\nTransaction Hash:\n0xaabdab3bb21e1705a1e160c7fc2669a24198c6daa489792de103e89fda1c39e6\nSender Wallet:\n0x115304710b38dbee977cfa628493b83dec39fe66\nRecipient Contract:\n0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c\nI mistakenly copied the AAVE USDC contract address and sent AETHUSDC directly from my wallet.\nI am the owner of the sender wallet address.\nIf any additional information or proof is required, I will be happy to provide it.\nThank you very much for your time and consideration.\nKind regards,\nThank you. Regards\n\n 1 month later\n\n Closed on Sep 24\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 142\n\n Jul 20\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5","tokens":443,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264219614,"hash":"13505ed3d886e349626dce47faa4001e346413c5"}
{"url":"https://ethresear.ch/t/maci-and-group-bribe-attacks/12939/6","domain":"ethresear.ch","title":"MACI and group bribe attacks - zk-s[nt]arks - Ethereum Research","text":"zk-s[nt]arks\n\n governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 5\n min\n\n Jun 2022\n\n 6 / 6\n\n Jun 25\n\n Jun 25\n\n post by josojo on Jun 25, 2022\n\n 4 years later\n\n post by hyeonleee on Jan 7\n\n 5 months later\n\n post by josojo on May 29\n\n post by MaxBrych on Jun 1\n\n MaxBrych\n\n Amazing explanation! Thank you. I’m working on a e-voting on MACI with a 3-5 Shamir Split Multisig for the Coordinator, so the trust for the result doesn’t rely on a single Coordinator. But in a real life scenario we are experiencing onchain verified Citizens with a SBT that could be under age but are still eligible to vote because of owning the SBT. Have you thought about the a age restriction? I heard several times that proving age with a zk Proof is a very good use case but how would this work if someone fakes his birth date. Don’t expect a answer but I’m currently dealing with this problem.\n\n post by 71104 on Jun 1\n\n 71104\n\nChiming in to say that I’ve been thinking about this too, and the solution is quite complex because it involves zk-inference and therefore all the machinery that’s needed to make it work (notably TurboPLONK, GKR, and GPGPU proving).\nThe gist of it is: have the user scan their passport and encode a circuit that reads the MRZ from the picture. It’s a simple OCR, probably the simplest use case you can possibly think of when it comes to zk-inference.\nFTR I’m building my own zkSTARK engine and I’m currently working on the aforementioned technologies – well, I’m still working on TurboPLONK, but GPGPU proving is next. Feel free to DM me, I’m open to working together.\n\n 23 days later\n\n post by Dede-Qorqud on Jun 25\n\n Dede-Qorqud\n\n The fake voter idea is interesting. But… the trust question — the maintainer still knows which accounts are fake. In high-stakes governance that feels like a weak point worth thinking about.\nI wonder if dynamic weights could help here. If weights change continuously based on verifiable but private participant behaviour, statistical inference becomes much harder over time. The briber can’t target effectively if the target keeps moving.\nHas anyone looked at combining this with reputation-based weighting — where the weight itself is a ZK-proven property rather than a static assignment?\n\n Powered by Discourse","tokens":572,"squid":"ink-research","role":"Deep Scholar","at":1791264228114,"hash":"71654fa995a773178c163c5548563dc8d1a4037f"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-aethusdc-transfer-to-aave-usdc-contract-on-eth/25530/2","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 25\n\n 2 / 2\n\n Sep 24\n\n Aug 25\n\n post by bikash on Aug 25\n\n bikash\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future rescue mission.\nI accidentally transferred 49792 AETHUSDC directly to the AAVE USDC contract on ETH instead of using the “Supply” function in the Aave App.\nTransaction Hash:\n0xaabdab3bb21e1705a1e160c7fc2669a24198c6daa489792de103e89fda1c39e6\nSender Wallet:\n0x115304710b38dbee977cfa628493b83dec39fe66\nRecipient Contract:\n0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c\nI mistakenly copied the AAVE USDC contract address and sent AETHUSDC directly from my wallet.\nI am the owner of the sender wallet address.\nIf any additional information or proof is required, I will be happy to provide it.\nThank you very much for your time and consideration.\nKind regards,\nThank you. Regards\n\n 1 month later\n\n Closed on Sep 24\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 142\n\n Jul 20\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5","tokens":423,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264231163,"hash":"d5937960fabc6ac819c093e770fb04dbca2ebf14"}
{"url":"https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413","domain":"ethresear.ch","title":"Minimal anti-collusion infrastructure - Applications - Ethereum Research","text":"Minimal anti-collusion infrastructure \n\n Applications\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2019\n\n 1 / 26\n\n May 2019\n\n Feb 2024\n\n post by vbuterin on May 4, 2019\n\n vbuterin\n\n For background see https://vitalik.ca/general/2019/04/03/collusion.html\nSuppose that we have an application where we need collusion resistance, but we also need the blockchain’s guarantees (mainly correct execution and censorship resistance). Voting is a prime candidate for this use case: collusion resistance is essential for the reasons discussed in the linked article, guarantees of correct execution is needed to guard against attacks on the vote tallying mechanism, and preventing censorship of votes is needed to prevent attacks involving blocking votes from voters. We can make a system that provides the collusion resistance guarantee with a centralized trust model (if Bob is honest we have collusion resistance, if Bob is dishonest we don’t), and also provides the blockchain’s guarantees unconditionally (ie. Bob can’t cause the other guarantees to break by being dishonest).\nSetup\nWe assume that we have a registry R𝑅 that contains a list of public keys K_1 ... K_n𝐾1...𝐾𝑛. It’s assumed that R𝑅 is a smart contract that has some procedure for admitting keys into this registry, with the social norm that participants in the mechanism should only act to support admitting keys if they verify two things:\n\nThe account belongs to a legitimate participant (eg. is a unique human, is a member of some community as measured in some formalized way such as citizenship of a country or a sufficiently high score on a forum, holds some minimum balance of tokens…)\nThe account holder personally controls the key (ie. they have the ability to print it out on demand if they really wanted to)\n\nEach user is also expected to put down a deposit; if anyone publishes a signature of their own address with the private key, they can steal the deposit and cause the account to be removed from the list (this feature is there to heavily discourage giving any third party access to the key).\nWe assume that there is an operator with a private key k_{\\omega}𝑘𝜔 and a corresponding public key K_{\\omega}𝐾𝜔.\nWe assume that there is a mechanism M𝑀, which we define as a function action^n \\rightarrow Outputs𝑎𝑐𝑡𝑖𝑜𝑛𝑛 →𝑂𝑢𝑡𝑝𝑢𝑡𝑠, where the input is the action taken by each of the n𝑛 participants and the output is some output as defined by the mechanism. For example, a simple voting mechanism would be the function that returns the action𝑎𝑐𝑡𝑖𝑜𝑛 that appears the most times in the input.\nExecution\nAt time T_{start}𝑇𝑠𝑡𝑎𝑟𝑡, the operator begins with an internal state S_{start} = \\{i: (key=K_i, action=\\emptyset)\\}𝑆𝑠𝑡𝑎𝑟𝑡 ={𝑖 :(𝑘𝑒𝑦 =𝐾𝑖,𝑎𝑐𝑡𝑖𝑜𝑛 =∅)} for i \\in 1...n𝑖 ∈1...𝑛. Anyone can compute this internal state; the registry contract itself could do this.\nBetween times T_{start}𝑇𝑠𝑡𝑎𝑟𝑡 and T_{end}𝑇𝑒𝑛𝑑, anyone has the right to publish messages into an on-chain registry (eg. set the to address to be a smart contract that saves them into a linked hash list) that are encrypted with the key k𝑘. There are two types of messages:\n\nActions: the intended behavior for a user is to send the encryption enc(msg=(i, sign(msg=action, key=k_i)), pubkey=K_{\\omega})𝑒𝑛𝑐(𝑚𝑠𝑔 =(𝑖,𝑠𝑖𝑔𝑛(𝑚𝑠𝑔 =𝑎𝑐𝑡𝑖𝑜𝑛,𝑘𝑒𝑦 =𝑘𝑖)),𝑝𝑢𝑏𝑘𝑒𝑦 =𝐾𝜔) where k_i𝑘𝑖 is the user’s current private key and i𝑖 is the user’s index in R𝑅.\nKey changes: the intended behavior for a user is to send the encryption enc(msg=(i, sign(msg=NewK_i, key=k_i)), pubkey=K_{\\omega})𝑒𝑛𝑐(𝑚𝑠𝑔 =(𝑖,𝑠𝑖𝑔𝑛(𝑚𝑠𝑔 =𝑁𝑒𝑤𝐾𝑖,𝑘𝑒𝑦 =𝑘𝑖)),𝑝𝑢𝑏𝑘𝑒𝑦 =𝐾𝜔), where NewK_i𝑁𝑒𝑤𝐾𝑖 is the user’s desired new public key and k_i𝑘𝑖 is the user’s current private key.\n\nWe assume an encryption function where the user can provide a salt to make an arbitrarily large number of possible encryptions for any given value.\nThe operator’s job is to process each message in the order the messages appear on chain as follows:\n\nDecrypt the message. If decryption fails, or if the resulting object fails to deserialize into one of the two categories, skip over it and do nothing.\nVerify the internal signature using state[i].key𝑠𝑡𝑎𝑡𝑒[𝑖].𝑘𝑒𝑦\n\nIf the message is an action, set state[i].action = action𝑠𝑡𝑎𝑡𝑒[𝑖].𝑎𝑐𝑡𝑖𝑜𝑛 =𝑎𝑐𝑡𝑖𝑜𝑛, if the message is a new-key, set state[i].key = NewK_i𝑠𝑡𝑎𝑡𝑒[𝑖].𝑘𝑒𝑦 =𝑁𝑒𝑤𝐾𝑖\n\nAfter time T_{end}𝑇𝑒𝑛𝑑, the operator must publish the output M(state[1].action .... state[n].action)𝑀(𝑠𝑡𝑎𝑡𝑒[1].𝑎𝑐𝑡𝑖𝑜𝑛....𝑠𝑡𝑎𝑡𝑒[𝑛].𝑎𝑐𝑡𝑖𝑜𝑛), and a ZK-SNARK proving that the given output is the correct result of doing the above processing on the messages that were published.\nCollusion resistance argument\nSuppose a user wants to prove that they took some action A𝐴. They can always simply point to the transaction enc(msg=(i, sign(msg=A, key=k_i)), pubkey=K_{\\omega})𝑒𝑛𝑐(𝑚𝑠𝑔 =(𝑖,𝑠𝑖𝑔𝑛(𝑚𝑠𝑔 =𝐴,𝑘𝑒𝑦 =𝑘𝑖)),𝑝𝑢𝑏𝑘𝑒𝑦 =𝐾𝜔) on chain, and provide a zero-knowledge-proof that the transaction is the encrypted version of the data containing A𝐴. However, they have no way of proving that they did not send an earlier transaction that switched the key to some NewK_i𝑁𝑒𝑤𝐾𝑖, thereby turning this action into a no-op. The new key then could have been used to take some other action.\nThe user could give someone else access to the key, and thereby give them the ability to race the user to get a new-key message in first. However, this (i) only has a 50% success rate, and (ii) would allow the other user the ability to take away their deposit.\nProblems this does not solve\n\nA key-selling attack where the recipient is inside trusted hardware or a trustworthy multisig\nAn attack where the original key is inside trusted hardware that prevents key changes except to keys known by an attacker\n\nThe former could be mitigated by deliberately complicated signature schemes that are not trusted hardware / multisig friendly, though the verification of such a scheme would need to be succinct enough to be ZKP-friendly. The latter could be solved with an “in-person zero knowledge proof protocol”, eg. the user derives x𝑥 and y𝑦 where x+y=k_i𝑥 +𝑦 =𝑘𝑖, publishes X = x * G𝑋 =𝑥 ∗𝐺 and Y = y * G𝑌 =𝑦 ∗𝐺, and shows the verifier two envelopes containing x𝑥 and y𝑦; the verifier opens one, checks that the published Y𝑌 is correct, and checks that X + Y = K_i𝑋 +𝑌 =𝐾𝑖.\nFuture work\n\nSee if there are ways to turn the trust guarantee for collusion resistance into an M of N guarantee without requiring full-on multi-party computation of signature verification, key replacement and the mechanism function\nMPC and trusted hardware-resistant signing functions.\n\n Private DAO with Semaphore\n\n Coercion resistant quadratic voting\n\n Adding anonymization to MACI\n\n MACI anonymization - using rerandomizable encryption\n\n What are good rules for Oracle voting systems?\n\n 9\n\n 8\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n post by barryWhiteHat on May 4, 2019\n\n barryWhiteHat\n\n So just after T_{start}𝑇𝑠𝑡𝑎𝑟𝑡 the first user (user_0𝑢𝑠𝑒𝑟0) is able to publish their vote and get bribed because it is impossible that she created an older transaction to changed her key. However I understnad the arugment as that this user can still after the fact update their vote again and there is no way for them to prove they did not do this.\nHowever if user_0𝑢𝑠𝑒𝑟0 can add the first two actions to the list then can\n\nuser_0𝑢𝑠𝑒𝑟0 Make their vote\n\nuser_0𝑢𝑠𝑒𝑟0 Update their public key to 0x0 (One where no public key exists)\n\nSo now user_0𝑢𝑠𝑒𝑟0 can sell their vote. As the current state for the briber is\n\nuser_0𝑢𝑠𝑒𝑟0 vote\n\nuser_0𝑢𝑠𝑒𝑟0 invalidate key\n\nIf user_1𝑢𝑠𝑒𝑟1 wants to sell her vote she can also do it by voting and burning her key. The current state for the briber becomes after user_0𝑢𝑠𝑒𝑟0 shares her key with briber.\n\nuser_0𝑢𝑠𝑒𝑟0 vote\n\nuser_0𝑢𝑠𝑒𝑟0 invalidate key\n\nuser_1𝑢𝑠𝑒𝑟1 vote\n\nuser_1𝑢𝑠𝑒𝑟1 invalidate key\n\nEven are honest voters interacting with the system the bribery can continue Imagine that user_2𝑢𝑠𝑒𝑟2 takes an action and does not publish it. Our current briber state becomes\n\nuser_0𝑢𝑠𝑒𝑟0 vote\n\nuser_0𝑢𝑠𝑒𝑟0 invalidate key\n\nuser_1𝑢𝑠𝑒𝑟1 vote\n\nuser_1𝑢𝑠𝑒𝑟1 invalidate key\n???\n\nSo if all the users from user_3𝑢𝑠𝑒𝑟3 to user_4𝑢𝑠𝑒𝑟4 wants to see their vote they cannot right because we are not sure that that user did not invalidate their key at step 5. But what we can do is have them all vote and invalidate in series and then publish the data afterwards. The briber current state is\n\nuser_0𝑢𝑠𝑒𝑟0 vote\n\nuser_0𝑢𝑠𝑒𝑟0 invalidate key\n\nuser_1𝑢𝑠𝑒𝑟1 vote\n\nuser_1𝑢𝑠𝑒𝑟1 invalidate key\n???\n\nuser_3𝑢𝑠𝑒𝑟3 vote\n\nuser_3𝑢𝑠𝑒𝑟3 invalidate key\n\nuser_4𝑢𝑠𝑒𝑟4 vote\n\nuser_4𝑢𝑠𝑒𝑟4 invalidate key\n\nNow we don’t know if user_4𝑢𝑠𝑒𝑟4 or user_5𝑢𝑠𝑒𝑟5 invalided their key. So the argument says we cannot bribe them. But we can bribe both of them half the amount we bribed user_0𝑢𝑠𝑒𝑟0 and be sure that we paid and bought one vote. Because we know for one of them did vote the way that we wanted them to.\nThis think this can be a serious attack. Especially that a briber can reward users for participating early in the epoch. Let me know thoughts. I can further analyze this if there is contention about its impact.\n\n post by vbuterin on May 4, 2019\n\n vbuterin\n\n That’s assuming an ability to add the first two actions to the list. One could easily make it default software for every user to switch their key to some other key and publish that message immediately after T_{start}𝑇𝑠𝑡𝑎𝑟𝑡, making it very hard for any specific user to get that position of being first.\nThe operator themselves could even have the first right to publish messages, allowing them to receive key switch messages from the participants through some other channel and include them before the “official” period starts.\n\n post by vbuterin on May 6, 2019\n\n vbuterin\n\n Thinking a bit about doing the computation in MPC. It seems fundamentally not too hard. Note particularly that there’s nothing wrong with it being public whether a message is a key change or an action. You want something like:\nKey change\nFor all j: k[j] = newKey * verifySig(newKey, k[j]) + k[j] * (1 - verifySig(newKey, k[j]))\nActions\nFor all j: a[j] = action * verifySig(newKey, k[j]) + a[j] * (1 - verifySig(newKey, k[j]))\nMaking a ZK-SNARK over the individual MPC transcripts should be harder, but seems fundamentally doable.\n\n post by ryanreich on May 7, 2019\n\n ryanreich\n\n If I understand the problem correctly: you are proposing a scheme where users, identified cryptographically, can vote on something, but are disincentivized from selling their votes to each other (“collusion resistance”).\nIf I understand the solution correctly: users are to be indexed, in exchange for a deposit, in a centralized registry operated by a trusted third party, and may update their identity there by providing proof of it. Both updates and votes are sent signed and encrypted to the operator, so no one can enumerate the full history of a user’s actions, even though the user can prove any individual update or vote by producing the corresponding signed message that encrypts to one that has been put on-chain. Therefore, no one can really trust another user they are trying to buy a vote from, who may be hiding the fact that what they are selling is no longer in the registry.\nI may be missing some design criterion here, but why not just require a user to cast a vote, secretly, at the time they make the deposit? If the trusted operator can be so omniscient as to enforce setup rule 1, they can be equally certain that the vote is genuinely by the person casting it, and the secret ballot works just as it does in real life to prevent selling one’s vote.\nActually, rule 1 is the big problem that consensus mechanisms need to solve (who gets to participate), and I think it deserves a little more respect as a big problem here, because without it, there’s nothing stopping a sockpuppet army or plutocracy from taking over.\nRule 2, in my experience, has no teeth: unless you want people to turn up in their physical person to vote, they are anonymized enough that the most secure way to identify them is actually with the key they are submitting. You may as well just say that a user is their key. I suppose you could argue that the user could be globally identified by one master key, but submit a secondary key signed by the first one to this particular contest, but that just kicks the problem up to verifying the master key (the analogue of showing up in person) as well as introducing another layer of trusted centralization.\nOkay, but let’s say the voters really need to be able to change their minds, and that the system for selecting them is satisfactory, and that we even manage to do this decentrally. Then I think that the argument for collusion-resistance is similar to the common internet security pattern, “After creating an account, you must immediately change your password through the encrypted connection.” At that point, an attacker has no idea “who” you really are, even if they knew your account creation data.\nHowever, the two have the same vulnerability to shoulder-surfing (as it were). In fact, a conspiracy dedicated to buying the election could make monetary offers in advance and in exchange for installing a monitor on the various sellers’ computers in order to see what their actual messages really were. This might even satisfy the sellers as to personal security if the monitor is unable to access their authentication data or private keys (say, by literally being a camera pointed over their shoulder at the voting app).\nSo although I agree that this scheme severely demoralizes attempts to fix the election by soliciting bribes, it seems to have a real-world vulnerability to a prepared adversary due to its dependence on the secrecy of the message history.\n\n post by vbuterin on May 8, 2019\n\n vbuterin\n\nThe goal of the scheme is to make it so that the setup needs to only be done once, and from that point it on the key be used for many different mechanisms. So the marginal cost of running a mechanism drops greatly. The intention is to help bring about a world where mechanisms (like quadratic voting etc) could be used for all sorts of use cases, and this requires the marginal cost of spinning up such a vote, and making it work reasonably securely, to be low.\nI don’t think a scheme of this type needs to be secure against all sorts of fancy attacks involving shoulder surfing and cameras to be very useful; you get the bulk of the benefit by being secure against attacks that could be done purely online (like smart contract bribes). And actually installing a monitor on people’s computers seems like something that would require a high cost for people to be willing to put up with, and cheatable in many ways (how do you know I’m not going to vote with a different computer?)\n\n post by ryanreich on May 9, 2019\n\n ryanreich\n\n I see, so the [T_\\text{start}, T_\\text{end}][𝑇start,𝑇end] period is repeatable: the registry is maintained, only the tally is performed at the end of each period. This is much less of a surveillance risk, because the window for accumulating a complete history ends once the setup is complete.\nIt still bugs me that this is centralized. Obviously you can’t make it decentralized in exactly the form given, because the private key k_\\omega𝑘𝜔 would need to be public. Instead, let’s say that each voter has two private keys, k_i𝑘𝑖 and k_i'𝑘′𝑖, and submits \\text{enc}(K_i, k_i')enc(𝐾𝑖,𝑘′𝑖) when a new election begins. All messages are sent in the clear:\n\n\\text{msg} = (i, \\text{sign}(\\text{action or enc(new }K_i, k_i'), k_i)),\nmsg=(𝑖,sign(action or enc(new 𝐾𝑖,𝑘′𝑖),𝑘𝑖)),\nbut of course, the signature can’t be verified because no one knows the actual public key…yet. At the end of the election, voters sacrifice their k_i'𝑘′𝑖 and reveal it publicly, and the entire stream of messages is verified all at once before the tally is taken. For the next round of elections, the voter can make their old k_i𝑘𝑖 into their new k_i'𝑘′𝑖 and pick another k_i𝑘𝑖, so that the key that is private in one election is revealed in the next one.\nUntil the reveal, it is impossible to know whether a given message has any effect, just as in the centralized scheme. So this is still collusion-resistant. One failing is that eventually, any potential briber knows that they were cheated, which is not possible in the centralized scheme, and invites possible retaliation even if the election is not affected.\nAlthough anyone looking back through the history can (of course) figure out what all the messages mean, no one living the history can do this until the reveal. So the transactions are not truly private, but they stay secret long enough to have the intended effect.\n\n post by vbuterin on May 10, 2019\n\n vbuterin\n\n Yeah, I’ve thought about schemes that involve not revealing info until later, and they all run into the issue that if the briber is a little more patient they’re no good.\nI agree the centralization is unfortunate! The nice thing though is that the centralization is only for the collusion-resistance guarantee, the centralized party can’t break anything else. Note that some meatspace verification being done by someone somewhere is indispensable because any scheme that requires anti-collusion infrastructure also requires unique-identity verification (or else someone can just gather up many identities and collude with themselves).\nIf we want to mitigate the centralization, the best that I can come up with is turning it from 1-of-1 into M-of-N via multi-party computation. We can potentially make the security even higher than 1/2 if we have a scheme that favors safety over liveness, and in the case where liveness fails detect it on-chain and automatically remove the non-live parties from the committee and restart.\n\n post by barryWhiteHat on May 10, 2019\n\n barryWhiteHat\n\n How does the withdraw of hte deposit works?\nIf I start with key x and update it to key y do I withdraw with key y ? Is the withdraw public in the smart contract ? Is the withdraw protected with the same coersion resistance mechanisim ?\nMy specific concern is something like this. I deposit eth and participate in a vote. Afterwards I withdraw my ETH deposit. If this is public I can use my withdrawal transaction from public key x as evidence to a briber that I did not update my key at any time during the Vote.\nIts still possible here that I voted twice with the same public key. But I can run the probabilistic bribe attack above but this time at the end of the epoch. So I would reveal my vote that is close to the end of hte epoch and get bribed.\nLet formalize the bribe amount. The operator creates a batch of transactions that overlap the end of the epoch and bribes each reveeler\ncost_per_vote * (no_transparent_actions_in_batch / no_hidden_actions_in_batch)\nThe cost_per_vote is how valuable their votes are to them. In the quadratic voting analysis even if no_transparent_actions_in_batch < no_hidden_actions_in_batch this attack can still be more efficient.\n\n post by marckr on May 10, 2019\n\n marckr\n\nKey selling would be a case of transitive trust. If trust is reliant upon repeated interactions from a single individual, could that not also then be packaged and sold? How does that interact with incentive compatibility wrt mechanisms?\nI have been a bit wary on sMPC, but not through code tests which I should perhaps engage in. How could we decouple trust from engaging with a key signing process? This of course assumes that individuals have varying collusive tendencies. It should be clear that the risk is through a break down of trust. Keys however might be distributed widely to ensure non-collusion without discretion, but that is a shaky argument.\nBelieve I have mentioned before, but ring signatures and threshold signatures are essentially dual, former requiring minimal endorsement, latter requiring maximal endorsement, ie collaboration in decryption as opposed to signing. It comes down to the manner in which the keys are served to people then and for what ideally limited purpose. ZK-SNARKs have opened us back to solutions from verifiable computation, but that does not address the trust issue in repeated execution of the protocol via any given party. We’d have to think in a multilinear way with trust levels so to speak, or it all falls back to 1-2 oblivious transfer. This appears to be the gold standard of any MPC as it is transitive on the single operation of a protocol.\nHave to reread the collusion post, but those are my 200 wei for now.\n\n post by ryanreich on May 14, 2019\n\n ryanreich\n\n vbuterin\n\n Coming back to the centralized version, I wonder if the following simpler scheme wouldn’t work better.\nThe idea is that, if you want to prevent bribery, you want a secret ballot; that’s what they were introduced for, in fact. I assume there is a good reason for us to assume messages are public (if only because they will be transmitted over the internet and not a secure private network), so why not just do as we do already with online secrecy and open an encrypted channel?\nSo, when a voter registers with the operator, rather than giving it her public key, they do a key exchange (as in, a handshake encrypted by public key crypto that results in each of them agreeing on a symmetric key). Now the operator is storing a separate totally secret key for each voter, and each voter can cast a ballot consisting of their voter number (in the clear) and the encrypted vote.\nIt is impossible to determine anything more than that a vote was cast, and even if a briber wants the voter to reveal a ballot as proof, the the voter would have to reveal both the ballot and their individual secret key in order for the briber to match it with an observed message. (This is different from the public/private key situation you worked with, because there, the briber does know how to encrypt a message to match it with an observed one.)\nNote that even though each voter gets their own secret key, the operator isn’t storing any more information than in your scheme, which keeps track of an individual public key for each voter. The voters, in turn, are not responsible for any harder a task than when they had to hold a private key. Finally, the messages are secure against tampering since the key encrypting the vote has to be the one stored by the operator for the numbered voter, and if that key stays secret, only the voter can accomplish this.\nUnless there is a need for the votes to be public (and I don’t see why that is at all desirable as a default), or there is some aspect of the operator’s workings that precludes a key exchange, wouldn’t this work?\n\n post by vbuterin on May 14, 2019\n\n vbuterin\n\n There is a need for encrypted votes to be public, which is that we don’t want to trust the operator for correctness, so we need the operator to be able to zero-knowledge prove that they counted all of the votes correctly and particularly did not “censor” any votes. The only thing a malicious operator should be able to break is the collusion resistance guarantee, not any safety or liveness guarantees.\n\n post by ryanreich on May 14, 2019\n\n ryanreich\n\n In both schemes, the votes are “public” in the sense that they appear, encrypted, on-chain. I meant that the secret-key scheme does not make it possible ever to prove (to the public, not the operator) how someone voted, unless they give up their secret key. Whereas of course, the public-key scheme does allow a claimed vote to be checked against the record by encrypting it.\nIs there something about the public-key setup that makes a ZK proof possible where it is not possible for the secret-key setup? That is, given the stream of encrypted messages that are handled as you describe by the operator, there is a zero-knowledge proof that some correctly-signed votes and key-changes exist that make the alleged output and encrypt to the given messages; but given the stream of encrypted messages that I described, there is not a proof that some votes and some set of secret keys exist with that property? They both sound like the same kind of problem (and also that the proofs would be exceedingly long and hard to compute; however, in both cases, the circuit only needs to be constructed once when the contract is written).\n(As an aside, in order for the ZK proof for the secret-key scheme to show that the votes were cast by the users and not made up by the operator, I would have to say that each user does have a public key, which is initially placed into the contract, and with which they also sign the votes that they encrypt onto the chain. Then the problem would contain an additional predicate that the same key was used for both. Only the operator sees the signature, but that is enough for the ZK proof to reflect the fact that it is valid, like in the public-key setup.)\n\n post by vbuterin on May 14, 2019\n\n vbuterin\n\n There’s also the possibility of a player agreeing with the operator on a key k1, but then using a different key k2 to encrypt the message, or that of a malicious operator claiming that another player did such a thing. Unless the exchanged key is somehow committed to on chain in a way that the player can verify, this seems unavoidable, and if the exchanged key is committed to on chain in a way that the player can verify then they could prove how they voted.\nSo I think the ability to specifically cancel a key is important.\n\n post by ryanreich on May 15, 2019\n\n ryanreich\n\n I see the problem here: the public has no means to verify an operator’s claim that some vote is invalid due to encryption with the wrong key, or that some invalid vote is valid because it’s encrypted with a key that the operator knows but isn’t the one that particular voter should use. Fair enough: this violates the requirement that an operator failure shouldn’t affect the outcome of the vote.\nLet’s modify my previous aside, which suggested that each user’s public key be kept on-chain for identity verification, to also keep the operator’s public-key encryption of the secret key of each user (the user as well as the ZKP can verify this because both would also have the operator’s public key and the user’s own secret key; no one else can learn anything from it). The operator (and, correspondingly, the ZKP), is required to use that secret key to decrypt votes. This ensures that a malicious operator can’t pretend that a vote is invalid, or that a vote encrypted with someone else’s secret key is valid, since the means to validate is visible, if not usable, to the public.\nIn general, it seems to me that by encrypting with the operator’s public key, any internal state maintained by the operator can be manifested in public, indecipherably, but still visibly enough to figure in a zero-knowledge proof that it was used correctly by the operator.\n\n post by vbuterin on May 16, 2019\n\n vbuterin\n\n But then wouldn’t a user be able to prove what their secret key is, if they’re the ones to encrypt it to the operator? I suppose you could get around that if the operator encrypts, but then that seems like it would put a lot of load on the operator to make many more proofs.\n\n post by ryanreich on May 17, 2019\n\n ryanreich\n\n I don’t think this reveals anything that the people who can find out don’t already know. Maybe I should make explicit the structure that’s been coming together in pieces here.\nThe contract contains the following data object, annotated in some made-up, suggestive type system:\n{\n registry : Map PublicKey (PubKeyEnc SymKey, SymKeyEnc (Signed Vote)),\n operatorPubKey : PublicKey\n}\n\nEach voter also has a data object:\n{\n myVote : Vote,\n myPrivKey : PrivateKey,\n mySymKey : SymKey\n}\n\nThe operator has a very simple data object:\n{\n myPrivKey : PrivateKey\n}\n\nThe voter and operator data are, of course, known only to the respective parties, while the contract data is public. For each voter, there is an entry in registry (with pseudocode crypto API):\nregistry[pubKeyOf(voter.myPrivateKey)] = \n (\n pubKeyEnc(voter.mySymKey, contract.operatorPubKey),\n symKeyEnc(pubKeySign(voter.myVote, voter.myPrivKey))\n )\n\nThis can be constructed entirely by the voter, since it uses only data visible to them (their own and the contract’s).\nConversely, the operator can read each vote, including validating the voter:\nvotes = \n symKeyDec\n (\n encSignedVote, \n pubKeyDec(encSymKey, operator.myPrivKey)\n ).unsign(voterPubKey)\n for voterPubKey, (encSymKey, encSignedVote) in contract.registry.items()\n\nTherefore, the operator can construct a proof that M(votes) == outcome, for whatever outcome. The proof is of the existence only of operator.myPrivKey, and because of the expression above, includes proofs of the validity of each vote. It shows that the various nonsense blobs in the contract are actually encryptions of correct data.\nAs you can see, only each voter knows their own symmetric key; it is stored as a message encrypted to the operator alone, and its correctness is established by the proof that the equation holds with the definition of votes given.\n\n post by ryanreich on May 17, 2019\n\n ryanreich\n\n vbuterin\n\n Of course, only after posting that long thing did I understand what you were asking. I’ll leave it there since it seems useful, but I’ll answer your actual question here.\nIt does seem true that a voter could choose to reveal their own secret (symmetric) key in a way that someone else could verify, since it’s encrypted with the operator’s public key. And I do agree that this could be fixed if the operator actually kept their “public” key private, and placed that encrypted value themselves.\nWould this actually require more zero-knowledge proofs? I think the voter could actually be sure their correct vote was used, if the expression for votes I gave in the long post is the one that goes into the overall proof: it requires checking the signature on their vote. The operator should be unable to produce any valid voter-signed message, particularly not in the way that this exploit we’re talking about would require: the operator would have to place the wrong symmetric key in the registry, which would result in the vote being censored just because it doesn’t decrypt correctly (but then break the proof because the signature is also not validated); to actually place a fake vote, the operator would have to somehow come up with a fake symmetric key that causes this bad decryption to be a correctly-signed vote. This is just not feasible.\nThe voter could of course give up their private key to a dishonest operator. However, the operator would still have to figure out an alternate symmetric key that would decrypt the actual encrypted vote to a signed, fake vote of their choice. I don’t think this is feasible either, though that depends on the encryption method and seems similar to actually cracking the encryption entirely.\n\n post by vbuterin on May 17, 2019\n\n vbuterin\n\n My proposal was that the operator put the voter’s symmetric key on-chain encrypted with the operator’s own public key. The voter would have no way of verifying that this was actually done, unless the encryption scheme is deterministic, and in the latter case the voter could prove to others what their key is.\nI feel like any scheme that doesn’t involve a key revocation game is going to keep having these kinds of issues…\n\n post by ryanreich on May 20, 2019\n\n ryanreich\n\n After some thought, I have to agree that without the game it seems almost necessarily the case that a voter would be able to prove their vote. Essentially, the voter can prove their vote to a briber (thus soliciting a bribe) if they can supply a probabilistic algorithm computing their set of messages. In your scheme, they can enumerate it but not its complement. My scheme definitely has a deterministic proof of vote; actually, it shows up a lot earlier in the conversation, since the voter can always just reveal their “secret” key. Any voting scheme where the ultimate vote depends on a single message would have this problem; it has to be possible, no matter what the voter reveals, that they have omitted something important. Which is a game.\nThis has been very educational. I hope I wasn’t too obnoxious in the process.\n\n Load more posts below","tokens":8103,"squid":"ink-research","role":"Deep Scholar","at":1791264238417,"hash":"9faaf9e1a8a5c3bdca40ca5dec01fa8a7f847c0e"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-wbtc-transfer-to-awbtc-contract-on-arbitrum/25349/1","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum - Governance - Aave","text":"[RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 20\n\n 1 / 4\n\n Jul 21\n\n Jul 20\n\n post by Leo.Inoue on Jul 20\n\n Leo.Inoue\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future rescue mission.\nI accidentally transferred 0.06872349 WBTC directly to the aWBTC contract on Arbitrum instead of using the “Supply” function in the Aave App.\nTransaction Hash:\n0x660fe7b3a52e292f7de32bf292d409a2a127228968cdf7b765cfc81568f58047\nSender Wallet:\n0xB74285439139fa4Cf76fF1e0C36FeB8e6Fcd3AC9\nRecipient Contract:\n0x078f358208685046a11C85e8ad32895DED33A249\nI mistakenly copied the aWBTC token contract address and sent WBTC directly from MetaMask, believing I was depositing my funds into Aave.\nIf any additional information or proof is required, I will be happy to provide it.\nThank you very much for your time and consideration.\nKind regards,\nLeo Inoue\nThank you. Regards\n\n Unlisted on Jul 20\n\n Listed on Jul 21\n\n 1 month later\n\n Closed on Aug 20\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n Rescue of wrong sent tokens\n\n Governance\n\n 0\n\n 47\n\n Aug 13","tokens":447,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264241411,"hash":"841b2065dc32cc17fa81494ca67eb4d5eca059ad"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-wbtc-transfer-to-awbtc-contract-on-arbitrum/25349/4","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 20\n\n 4 / 4\n\n Aug 20\n\n Jul 20\n\n post by Leo.Inoue on Jul 20\n\n Leo.Inoue\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future rescue mission.\nI accidentally transferred 0.06872349 WBTC directly to the aWBTC contract on Arbitrum instead of using the “Supply” function in the Aave App.\nTransaction Hash:\n0x660fe7b3a52e292f7de32bf292d409a2a127228968cdf7b765cfc81568f58047\nSender Wallet:\n0xB74285439139fa4Cf76fF1e0C36FeB8e6Fcd3AC9\nRecipient Contract:\n0x078f358208685046a11C85e8ad32895DED33A249\nI mistakenly copied the aWBTC token contract address and sent WBTC directly from MetaMask, believing I was depositing my funds into Aave.\nIf any additional information or proof is required, I will be happy to provide it.\nThank you very much for your time and consideration.\nKind regards,\nLeo Inoue\nThank you. Regards\n\n Unlisted on Jul 20\n\n Listed on Jul 21\n\n 1 month later\n\n Closed on Aug 20\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 107\n\n 11d\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n Rescue of wrong sent tokens\n\n Governance\n\n 0\n\n 47\n\n Aug 13","tokens":428,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264251801,"hash":"8f77816c55c7953a28d04c8392c61203014b2f06"}
{"url":"https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413/26","domain":"ethresear.ch","title":"Minimal anti-collusion infrastructure - Applications - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 8\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n May 2019\n\n 26 / 26\n\n Feb 2024\n\n Feb 2024\n\n Load more posts above\n\n post by ryanreich on May 9, 2019\n\n ryanreich\n\n vbuterin\n\n I see, so the [T_\\text{start}, T_\\text{end}][𝑇start,𝑇end] period is repeatable: the registry is maintained, only the tally is performed at the end of each period. This is much less of a surveillance risk, because the window for accumulating a complete history ends once the setup is complete.\nIt still bugs me that this is centralized. Obviously you can’t make it decentralized in exactly the form given, because the private key k_\\omega𝑘𝜔 would need to be public. Instead, let’s say that each voter has two private keys, k_i𝑘𝑖 and k_i'𝑘′𝑖, and submits \\text{enc}(K_i, k_i')enc(𝐾𝑖,𝑘′𝑖) when a new election begins. All messages are sent in the clear:\n\n\\text{msg} = (i, \\text{sign}(\\text{action or enc(new }K_i, k_i'), k_i)),\nmsg=(𝑖,sign(action or enc(new 𝐾𝑖,𝑘′𝑖),𝑘𝑖)),\nbut of course, the signature can’t be verified because no one knows the actual public key…yet. At the end of the election, voters sacrifice their k_i'𝑘′𝑖 and reveal it publicly, and the entire stream of messages is verified all at once before the tally is taken. For the next round of elections, the voter can make their old k_i𝑘𝑖 into their new k_i'𝑘′𝑖 and pick another k_i𝑘𝑖, so that the key that is private in one election is revealed in the next one.\nUntil the reveal, it is impossible to know whether a given message has any effect, just as in the centralized scheme. So this is still collusion-resistant. One failing is that eventually, any potential briber knows that they were cheated, which is not possible in the centralized scheme, and invites possible retaliation even if the election is not affected.\nAlthough anyone looking back through the history can (of course) figure out what all the messages mean, no one living the history can do this until the reveal. So the transactions are not truly private, but they stay secret long enough to have the intended effect.\n\n post by vbuterin on May 10, 2019\n\n vbuterin\n\n Yeah, I’ve thought about schemes that involve not revealing info until later, and they all run into the issue that if the briber is a little more patient they’re no good.\nI agree the centralization is unfortunate! The nice thing though is that the centralization is only for the collusion-resistance guarantee, the centralized party can’t break anything else. Note that some meatspace verification being done by someone somewhere is indispensable because any scheme that requires anti-collusion infrastructure also requires unique-identity verification (or else someone can just gather up many identities and collude with themselves).\nIf we want to mitigate the centralization, the best that I can come up with is turning it from 1-of-1 into M-of-N via multi-party computation. We can potentially make the security even higher than 1/2 if we have a scheme that favors safety over liveness, and in the case where liveness fails detect it on-chain and automatically remove the non-live parties from the committee and restart.\n\n post by barryWhiteHat on May 10, 2019\n\n barryWhiteHat\n\n How does the withdraw of hte deposit works?\nIf I start with key x and update it to key y do I withdraw with key y ? Is the withdraw public in the smart contract ? Is the withdraw protected with the same coersion resistance mechanisim ?\nMy specific concern is something like this. I deposit eth and participate in a vote. Afterwards I withdraw my ETH deposit. If this is public I can use my withdrawal transaction from public key x as evidence to a briber that I did not update my key at any time during the Vote.\nIts still possible here that I voted twice with the same public key. But I can run the probabilistic bribe attack above but this time at the end of the epoch. So I would reveal my vote that is close to the end of hte epoch and get bribed.\nLet formalize the bribe amount. The operator creates a batch of transactions that overlap the end of the epoch and bribes each reveeler\ncost_per_vote * (no_transparent_actions_in_batch / no_hidden_actions_in_batch)\nThe cost_per_vote is how valuable their votes are to them. In the quadratic voting analysis even if no_transparent_actions_in_batch < no_hidden_actions_in_batch this attack can still be more efficient.\n\n post by marckr on May 10, 2019\n\n marckr\n\nKey selling would be a case of transitive trust. If trust is reliant upon repeated interactions from a single individual, could that not also then be packaged and sold? How does that interact with incentive compatibility wrt mechanisms?\nI have been a bit wary on sMPC, but not through code tests which I should perhaps engage in. How could we decouple trust from engaging with a key signing process? This of course assumes that individuals have varying collusive tendencies. It should be clear that the risk is through a break down of trust. Keys however might be distributed widely to ensure non-collusion without discretion, but that is a shaky argument.\nBelieve I have mentioned before, but ring signatures and threshold signatures are essentially dual, former requiring minimal endorsement, latter requiring maximal endorsement, ie collaboration in decryption as opposed to signing. It comes down to the manner in which the keys are served to people then and for what ideally limited purpose. ZK-SNARKs have opened us back to solutions from verifiable computation, but that does not address the trust issue in repeated execution of the protocol via any given party. We’d have to think in a multilinear way with trust levels so to speak, or it all falls back to 1-2 oblivious transfer. This appears to be the gold standard of any MPC as it is transitive on the single operation of a protocol.\nHave to reread the collusion post, but those are my 200 wei for now.\n\n post by ryanreich on May 14, 2019\n\n ryanreich\n\n vbuterin\n\n Coming back to the centralized version, I wonder if the following simpler scheme wouldn’t work better.\nThe idea is that, if you want to prevent bribery, you want a secret ballot; that’s what they were introduced for, in fact. I assume there is a good reason for us to assume messages are public (if only because they will be transmitted over the internet and not a secure private network), so why not just do as we do already with online secrecy and open an encrypted channel?\nSo, when a voter registers with the operator, rather than giving it her public key, they do a key exchange (as in, a handshake encrypted by public key crypto that results in each of them agreeing on a symmetric key). Now the operator is storing a separate totally secret key for each voter, and each voter can cast a ballot consisting of their voter number (in the clear) and the encrypted vote.\nIt is impossible to determine anything more than that a vote was cast, and even if a briber wants the voter to reveal a ballot as proof, the the voter would have to reveal both the ballot and their individual secret key in order for the briber to match it with an observed message. (This is different from the public/private key situation you worked with, because there, the briber does know how to encrypt a message to match it with an observed one.)\nNote that even though each voter gets their own secret key, the operator isn’t storing any more information than in your scheme, which keeps track of an individual public key for each voter. The voters, in turn, are not responsible for any harder a task than when they had to hold a private key. Finally, the messages are secure against tampering since the key encrypting the vote has to be the one stored by the operator for the numbered voter, and if that key stays secret, only the voter can accomplish this.\nUnless there is a need for the votes to be public (and I don’t see why that is at all desirable as a default), or there is some aspect of the operator’s workings that precludes a key exchange, wouldn’t this work?\n\n post by vbuterin on May 14, 2019\n\n vbuterin\n\n There is a need for encrypted votes to be public, which is that we don’t want to trust the operator for correctness, so we need the operator to be able to zero-knowledge prove that they counted all of the votes correctly and particularly did not “censor” any votes. The only thing a malicious operator should be able to break is the collusion resistance guarantee, not any safety or liveness guarantees.\n\n post by ryanreich on May 14, 2019\n\n ryanreich\n\n In both schemes, the votes are “public” in the sense that they appear, encrypted, on-chain. I meant that the secret-key scheme does not make it possible ever to prove (to the public, not the operator) how someone voted, unless they give up their secret key. Whereas of course, the public-key scheme does allow a claimed vote to be checked against the record by encrypting it.\nIs there something about the public-key setup that makes a ZK proof possible where it is not possible for the secret-key setup? That is, given the stream of encrypted messages that are handled as you describe by the operator, there is a zero-knowledge proof that some correctly-signed votes and key-changes exist that make the alleged output and encrypt to the given messages; but given the stream of encrypted messages that I described, there is not a proof that some votes and some set of secret keys exist with that property? They both sound like the same kind of problem (and also that the proofs would be exceedingly long and hard to compute; however, in both cases, the circuit only needs to be constructed once when the contract is written).\n(As an aside, in order for the ZK proof for the secret-key scheme to show that the votes were cast by the users and not made up by the operator, I would have to say that each user does have a public key, which is initially placed into the contract, and with which they also sign the votes that they encrypt onto the chain. Then the problem would contain an additional predicate that the same key was used for both. Only the operator sees the signature, but that is enough for the ZK proof to reflect the fact that it is valid, like in the public-key setup.)\n\n post by vbuterin on May 14, 2019\n\n vbuterin\n\n There’s also the possibility of a player agreeing with the operator on a key k1, but then using a different key k2 to encrypt the message, or that of a malicious operator claiming that another player did such a thing. Unless the exchanged key is somehow committed to on chain in a way that the player can verify, this seems unavoidable, and if the exchanged key is committed to on chain in a way that the player can verify then they could prove how they voted.\nSo I think the ability to specifically cancel a key is important.\n\n post by ryanreich on May 15, 2019\n\n ryanreich\n\n I see the problem here: the public has no means to verify an operator’s claim that some vote is invalid due to encryption with the wrong key, or that some invalid vote is valid because it’s encrypted with a key that the operator knows but isn’t the one that particular voter should use. Fair enough: this violates the requirement that an operator failure shouldn’t affect the outcome of the vote.\nLet’s modify my previous aside, which suggested that each user’s public key be kept on-chain for identity verification, to also keep the operator’s public-key encryption of the secret key of each user (the user as well as the ZKP can verify this because both would also have the operator’s public key and the user’s own secret key; no one else can learn anything from it). The operator (and, correspondingly, the ZKP), is required to use that secret key to decrypt votes. This ensures that a malicious operator can’t pretend that a vote is invalid, or that a vote encrypted with someone else’s secret key is valid, since the means to validate is visible, if not usable, to the public.\nIn general, it seems to me that by encrypting with the operator’s public key, any internal state maintained by the operator can be manifested in public, indecipherably, but still visibly enough to figure in a zero-knowledge proof that it was used correctly by the operator.\n\n post by vbuterin on May 16, 2019\n\n vbuterin\n\n But then wouldn’t a user be able to prove what their secret key is, if they’re the ones to encrypt it to the operator? I suppose you could get around that if the operator encrypts, but then that seems like it would put a lot of load on the operator to make many more proofs.\n\n post by ryanreich on May 17, 2019\n\n ryanreich\n\n I don’t think this reveals anything that the people who can find out don’t already know. Maybe I should make explicit the structure that’s been coming together in pieces here.\nThe contract contains the following data object, annotated in some made-up, suggestive type system:\n{\n registry : Map PublicKey (PubKeyEnc SymKey, SymKeyEnc (Signed Vote)),\n operatorPubKey : PublicKey\n}\n\nEach voter also has a data object:\n{\n myVote : Vote,\n myPrivKey : PrivateKey,\n mySymKey : SymKey\n}\n\nThe operator has a very simple data object:\n{\n myPrivKey : PrivateKey\n}\n\nThe voter and operator data are, of course, known only to the respective parties, while the contract data is public. For each voter, there is an entry in registry (with pseudocode crypto API):\nregistry[pubKeyOf(voter.myPrivateKey)] = \n (\n pubKeyEnc(voter.mySymKey, contract.operatorPubKey),\n symKeyEnc(pubKeySign(voter.myVote, voter.myPrivKey))\n )\n\nThis can be constructed entirely by the voter, since it uses only data visible to them (their own and the contract’s).\nConversely, the operator can read each vote, including validating the voter:\nvotes = \n symKeyDec\n (\n encSignedVote, \n pubKeyDec(encSymKey, operator.myPrivKey)\n ).unsign(voterPubKey)\n for voterPubKey, (encSymKey, encSignedVote) in contract.registry.items()\n\nTherefore, the operator can construct a proof that M(votes) == outcome, for whatever outcome. The proof is of the existence only of operator.myPrivKey, and because of the expression above, includes proofs of the validity of each vote. It shows that the various nonsense blobs in the contract are actually encryptions of correct data.\nAs you can see, only each voter knows their own symmetric key; it is stored as a message encrypted to the operator alone, and its correctness is established by the proof that the equation holds with the definition of votes given.\n\n post by ryanreich on May 17, 2019\n\n ryanreich\n\n vbuterin\n\n Of course, only after posting that long thing did I understand what you were asking. I’ll leave it there since it seems useful, but I’ll answer your actual question here.\nIt does seem true that a voter could choose to reveal their own secret (symmetric) key in a way that someone else could verify, since it’s encrypted with the operator’s public key. And I do agree that this could be fixed if the operator actually kept their “public” key private, and placed that encrypted value themselves.\nWould this actually require more zero-knowledge proofs? I think the voter could actually be sure their correct vote was used, if the expression for votes I gave in the long post is the one that goes into the overall proof: it requires checking the signature on their vote. The operator should be unable to produce any valid voter-signed message, particularly not in the way that this exploit we’re talking about would require: the operator would have to place the wrong symmetric key in the registry, which would result in the vote being censored just because it doesn’t decrypt correctly (but then break the proof because the signature is also not validated); to actually place a fake vote, the operator would have to somehow come up with a fake symmetric key that causes this bad decryption to be a correctly-signed vote. This is just not feasible.\nThe voter could of course give up their private key to a dishonest operator. However, the operator would still have to figure out an alternate symmetric key that would decrypt the actual encrypted vote to a signed, fake vote of their choice. I don’t think this is feasible either, though that depends on the encryption method and seems similar to actually cracking the encryption entirely.\n\n post by vbuterin on May 17, 2019\n\n vbuterin\n\n My proposal was that the operator put the voter’s symmetric key on-chain encrypted with the operator’s own public key. The voter would have no way of verifying that this was actually done, unless the encryption scheme is deterministic, and in the latter case the voter could prove to others what their key is.\nI feel like any scheme that doesn’t involve a key revocation game is going to keep having these kinds of issues…\n\n post by ryanreich on May 20, 2019\n\n ryanreich\n\n After some thought, I have to agree that without the game it seems almost necessarily the case that a voter would be able to prove their vote. Essentially, the voter can prove their vote to a briber (thus soliciting a bribe) if they can supply a probabilistic algorithm computing their set of messages. In your scheme, they can enumerate it but not its complement. My scheme definitely has a deterministic proof of vote; actually, it shows up a lot earlier in the conversation, since the voter can always just reveal their “secret” key. Any voting scheme where the ultimate vote depends on a single message would have this problem; it has to be possible, no matter what the voter reveals, that they have omitted something important. Which is a game.\nThis has been very educational. I hope I wasn’t too obnoxious in the process.\n\n 2 months later\n\n post by barryWhiteHat on Jul 11, 2019\n\n barryWhiteHat\n\n We are staring to implment this http://github.com/barryWhiteHat/maci\nIf anyone wants to join this effort please join https://t.me/joinchat/LUgOpE7J2gstRcZqdERyvw\n\n 10 months later\n\n post by auryn on May 4, 2020\n\n auryn\n\n Hey everyone, just wanted to point out this topic, since it’s about a quadratic funding app built on MACI.\nThe project started at ETHDenver, where @barryWhiteHat and @weijiekoh helped us wrap our heads around MACI.\n\n 9 days later\n\n post by weijiekoh on May 13, 2020\n\n weijiekoh\n\n Hi all, I’ve recorded a basic explainer and demo of MACI: https://www.youtube.com/watch?v=sKuNj_IQVYI\nIt’s based on the implementation we’ve built here: https://github.com/barryWhiteHat/maci\n\n 9 months later\n\n post by BoltonBailey on Jan 28, 2021\n\n BoltonBailey\n\n barryWhiteHat\n\n EDIT I realized that MMRs were unnecessary for this, so I updated the post accordingly.\nEDIT 2 After thinking about this more, I realized there is a further simplification where we replace the hash of the history with a nonce. I also realized that the vote buyer and vote seller can do a 2 party MPC to create a signed message for which only the buyer knows the nonce, so this does not totally prevent the attack that was described. This still seems like it could be an improvement to me though, in that instead of writing a potentially large new public key to the state, we are only writing a nonce.\nThis attack described by @barryWhiteHat seems concerning to me.\n\nThis mitigates the attack, but if the attacker guesses the number of messages a user sends during the key-switch phase, then they can still offer to pay for the first vote after the key-switch phase by requesting that number of key-switch-messages followed by an action message. Thus, this only decreases the expected number of votes per attacker money by a factor roughly equal to the number of key-switch messages in this phase.\nWith an eye to preventing this kind of attack here is a version of MACI which makes this kind of attack impossible harder. I think it also simplifies the protocol somewhat, but there can be O(1) additive increase in message size, ZK-SNARK circuit size, and state-per-participant.\nIn order to avoid vote-selling by an attacker that can add the first messages to the list, it is necessary to have any sequence of messages be “undoable” in the sense that you must be able to add more messages to the list that invalidate these actions. To this end, in this version of MACI we get rid of the key_change messages. Instead, we require action messages to include the tip of a hash chain of all messages previously sent from that account a randomly generated nonce.\nThe operator now maintains state[i].action and state[i].nonce for each participant. When a message is received, the operator checks that the signature is valid and state[i].tip_hash = message.nonce. If these checks pass, then state[i].action is updated to the new action and the update state[i].nonce is (optionally) updated to a new nonce.\nA participant will now always be able to update their action, even if they update their initial action in the first message received by the system. Additionally, the participant sending the last message received by the system will not be able to prove their vote, because even if they expose their final encrypted message, they will be able to make actions beforehand that cause the hash chain tip on the final message to be invalid change the nonce, invalidating that message.\nIndeed, since the nonce and action are updated simultaneously, one could just modify the action field to contain a few extra bytes of data to be ignored by the mechanism. This leaves the protocol almost exactly the same as the original, the only change is that the change_key messages are removed and a comparison against the old action is added to the message and SNARK.\n\n 3 years later\n\n post by lingering on Oct 24, 2023\n\n lingering\n\n Hi,\nI am a bit confused here about the collusion resistance property.\nSeems it is a mixture of two classic security properties studied in the digital remote voting community.\nFirst, it looks quite similar to receipt-freeness, where a voter is prohibited from selling his vote as there is no way for him/her to prove the voted option.\nBut we have another desired property, coercion resistance, formalized by JCJ. It showed that a coerced voter can evade coercion/threat from the adversary by giving away a fake credential or revoting to overwrite the coerced vote.\nSo I see the collusion resistance property is essentially equivalent to recipient-freeness here.\nI think coercion is also a potential threat to blockchain-based voting protocol. I need coercion resistance in MACI as well.\n\n 4 months later\n\n post by auryn on Feb 26, 2024\n\n auryn\n\nMACI is receipt-free in precisely the way you described.\n\nA voter in MACI can create a fake receipt that is indistinguishable from a legitimate vote, by switching keys and casting a new vote and sharing a receipt from the now invalid vote.\n\n Powered by Discourse","tokens":5653,"squid":"ink-research","role":"Deep Scholar","at":1791264259394,"hash":"fb95ca9cfa0984fd8768baddb3552824edb40cb7"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-transfer-of-83-71815-uni-to-aave-token-contract-on-bnb-chain/25702/1","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain - Governance - Aave","text":"[RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 25\n\n 1 / 1\n\n Sep 25\n\n 11d ago\n\n post by raikugh on Sep 25\n\n raikugh\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future Aave Rescue Mission.\nOn December 10, 2024, I accidentally transferred 83.71815 UNI directly to the Aave Token contract on BNB Smart Chain.\nTransaction details:\nNetwork:\nBNB Smart Chain\nTransaction Hash:\n0x612b90c33aba21365d8c948d2ad91a6bf2ce14dd8297c1bca676ee8825d9eb5e\nSender Wallet:\n0xf4E3DaAfE1125748e18B69e2D465775c310c324E\nRecipient Contract:\n0xfb6115445Bff7b52FeB98650C87f44907E58f802\nRecipient:\nBinance-Peg Aave Token (AAVE)\nToken:\nBinance-Peg Uniswap (UNI)\nUNI Token Contract:\n0xbf5140a22578168fd562dccf235e5d43a02ce9b1\nAmount:\n83.71815 UNI\nDate:\nDecember 10, 2024\nThe transfer was accidental. I mistakenly sent the UNI directly to the AAVE Token contract instead of sending them to the intended destination.\nThe transaction was successful, and the 83.71815 UNI are still held by the destination AAVE Token contract on BNB Smart Chain.\nI am the owner of the sending wallet and can provide any additional information or proof of ownership required.\nAave Labs Support advised me by email to post this case on the Aave Governance forum so that it can be considered for inclusion in a future Rescue Mission.\nI kindly ask Aave Governance, BGD Labs, and the relevant technical contributors to review my case and consider including these 83.71815 UNI in a future Rescue Mission.\nI would be very grateful for any assistance or guidance regarding the recovery process.\nThank you for your time and consideration.\nThanks.\n\n This topic will close a month after the last reply.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Rescue of wrong sent tokens\n\n Governance\n\n 0\n\n 47\n\n Aug 13\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 143\n\n Jul 20\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5","tokens":601,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264262166,"hash":"624a457cb0c3af1a53dfdc3b339b1f374b3af089"}
{"url":"https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413/25","domain":"ethresear.ch","title":"Minimal anti-collusion infrastructure - Applications - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 9\n\n 8\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n May 2019\n\n 25 / 26\n\n Oct 2023\n\n Feb 2024\n\n Load more posts above\n\n post by ryanreich on May 9, 2019\n\n ryanreich\n\n vbuterin\n\n I see, so the [T_\\text{start}, T_\\text{end}][𝑇start,𝑇end] period is repeatable: the registry is maintained, only the tally is performed at the end of each period. This is much less of a surveillance risk, because the window for accumulating a complete history ends once the setup is complete.\nIt still bugs me that this is centralized. Obviously you can’t make it decentralized in exactly the form given, because the private key k_\\omega𝑘𝜔 would need to be public. Instead, let’s say that each voter has two private keys, k_i𝑘𝑖 and k_i'𝑘′𝑖, and submits \\text{enc}(K_i, k_i')enc(𝐾𝑖,𝑘′𝑖) when a new election begins. All messages are sent in the clear:\n\n\\text{msg} = (i, \\text{sign}(\\text{action or enc(new }K_i, k_i'), k_i)),\nmsg=(𝑖,sign(action or enc(new 𝐾𝑖,𝑘′𝑖),𝑘𝑖)),\nbut of course, the signature can’t be verified because no one knows the actual public key…yet. At the end of the election, voters sacrifice their k_i'𝑘′𝑖 and reveal it publicly, and the entire stream of messages is verified all at once before the tally is taken. For the next round of elections, the voter can make their old k_i𝑘𝑖 into their new k_i'𝑘′𝑖 and pick another k_i𝑘𝑖, so that the key that is private in one election is revealed in the next one.\nUntil the reveal, it is impossible to know whether a given message has any effect, just as in the centralized scheme. So this is still collusion-resistant. One failing is that eventually, any potential briber knows that they were cheated, which is not possible in the centralized scheme, and invites possible retaliation even if the election is not affected.\nAlthough anyone looking back through the history can (of course) figure out what all the messages mean, no one living the history can do this until the reveal. So the transactions are not truly private, but they stay secret long enough to have the intended effect.\n\n post by vbuterin on May 10, 2019\n\n vbuterin\n\n Yeah, I’ve thought about schemes that involve not revealing info until later, and they all run into the issue that if the briber is a little more patient they’re no good.\nI agree the centralization is unfortunate! The nice thing though is that the centralization is only for the collusion-resistance guarantee, the centralized party can’t break anything else. Note that some meatspace verification being done by someone somewhere is indispensable because any scheme that requires anti-collusion infrastructure also requires unique-identity verification (or else someone can just gather up many identities and collude with themselves).\nIf we want to mitigate the centralization, the best that I can come up with is turning it from 1-of-1 into M-of-N via multi-party computation. We can potentially make the security even higher than 1/2 if we have a scheme that favors safety over liveness, and in the case where liveness fails detect it on-chain and automatically remove the non-live parties from the committee and restart.\n\n post by barryWhiteHat on May 10, 2019\n\n barryWhiteHat\n\n How does the withdraw of hte deposit works?\nIf I start with key x and update it to key y do I withdraw with key y ? Is the withdraw public in the smart contract ? Is the withdraw protected with the same coersion resistance mechanisim ?\nMy specific concern is something like this. I deposit eth and participate in a vote. Afterwards I withdraw my ETH deposit. If this is public I can use my withdrawal transaction from public key x as evidence to a briber that I did not update my key at any time during the Vote.\nIts still possible here that I voted twice with the same public key. But I can run the probabilistic bribe attack above but this time at the end of the epoch. So I would reveal my vote that is close to the end of hte epoch and get bribed.\nLet formalize the bribe amount. The operator creates a batch of transactions that overlap the end of the epoch and bribes each reveeler\ncost_per_vote * (no_transparent_actions_in_batch / no_hidden_actions_in_batch)\nThe cost_per_vote is how valuable their votes are to them. In the quadratic voting analysis even if no_transparent_actions_in_batch < no_hidden_actions_in_batch this attack can still be more efficient.\n\n post by marckr on May 10, 2019\n\n marckr\n\nKey selling would be a case of transitive trust. If trust is reliant upon repeated interactions from a single individual, could that not also then be packaged and sold? How does that interact with incentive compatibility wrt mechanisms?\nI have been a bit wary on sMPC, but not through code tests which I should perhaps engage in. How could we decouple trust from engaging with a key signing process? This of course assumes that individuals have varying collusive tendencies. It should be clear that the risk is through a break down of trust. Keys however might be distributed widely to ensure non-collusion without discretion, but that is a shaky argument.\nBelieve I have mentioned before, but ring signatures and threshold signatures are essentially dual, former requiring minimal endorsement, latter requiring maximal endorsement, ie collaboration in decryption as opposed to signing. It comes down to the manner in which the keys are served to people then and for what ideally limited purpose. ZK-SNARKs have opened us back to solutions from verifiable computation, but that does not address the trust issue in repeated execution of the protocol via any given party. We’d have to think in a multilinear way with trust levels so to speak, or it all falls back to 1-2 oblivious transfer. This appears to be the gold standard of any MPC as it is transitive on the single operation of a protocol.\nHave to reread the collusion post, but those are my 200 wei for now.\n\n post by ryanreich on May 14, 2019\n\n ryanreich\n\n vbuterin\n\n Coming back to the centralized version, I wonder if the following simpler scheme wouldn’t work better.\nThe idea is that, if you want to prevent bribery, you want a secret ballot; that’s what they were introduced for, in fact. I assume there is a good reason for us to assume messages are public (if only because they will be transmitted over the internet and not a secure private network), so why not just do as we do already with online secrecy and open an encrypted channel?\nSo, when a voter registers with the operator, rather than giving it her public key, they do a key exchange (as in, a handshake encrypted by public key crypto that results in each of them agreeing on a symmetric key). Now the operator is storing a separate totally secret key for each voter, and each voter can cast a ballot consisting of their voter number (in the clear) and the encrypted vote.\nIt is impossible to determine anything more than that a vote was cast, and even if a briber wants the voter to reveal a ballot as proof, the the voter would have to reveal both the ballot and their individual secret key in order for the briber to match it with an observed message. (This is different from the public/private key situation you worked with, because there, the briber does know how to encrypt a message to match it with an observed one.)\nNote that even though each voter gets their own secret key, the operator isn’t storing any more information than in your scheme, which keeps track of an individual public key for each voter. The voters, in turn, are not responsible for any harder a task than when they had to hold a private key. Finally, the messages are secure against tampering since the key encrypting the vote has to be the one stored by the operator for the numbered voter, and if that key stays secret, only the voter can accomplish this.\nUnless there is a need for the votes to be public (and I don’t see why that is at all desirable as a default), or there is some aspect of the operator’s workings that precludes a key exchange, wouldn’t this work?\n\n post by vbuterin on May 14, 2019\n\n vbuterin\n\n There is a need for encrypted votes to be public, which is that we don’t want to trust the operator for correctness, so we need the operator to be able to zero-knowledge prove that they counted all of the votes correctly and particularly did not “censor” any votes. The only thing a malicious operator should be able to break is the collusion resistance guarantee, not any safety or liveness guarantees.\n\n post by ryanreich on May 14, 2019\n\n ryanreich\n\n In both schemes, the votes are “public” in the sense that they appear, encrypted, on-chain. I meant that the secret-key scheme does not make it possible ever to prove (to the public, not the operator) how someone voted, unless they give up their secret key. Whereas of course, the public-key scheme does allow a claimed vote to be checked against the record by encrypting it.\nIs there something about the public-key setup that makes a ZK proof possible where it is not possible for the secret-key setup? That is, given the stream of encrypted messages that are handled as you describe by the operator, there is a zero-knowledge proof that some correctly-signed votes and key-changes exist that make the alleged output and encrypt to the given messages; but given the stream of encrypted messages that I described, there is not a proof that some votes and some set of secret keys exist with that property? They both sound like the same kind of problem (and also that the proofs would be exceedingly long and hard to compute; however, in both cases, the circuit only needs to be constructed once when the contract is written).\n(As an aside, in order for the ZK proof for the secret-key scheme to show that the votes were cast by the users and not made up by the operator, I would have to say that each user does have a public key, which is initially placed into the contract, and with which they also sign the votes that they encrypt onto the chain. Then the problem would contain an additional predicate that the same key was used for both. Only the operator sees the signature, but that is enough for the ZK proof to reflect the fact that it is valid, like in the public-key setup.)\n\n post by vbuterin on May 14, 2019\n\n vbuterin\n\n There’s also the possibility of a player agreeing with the operator on a key k1, but then using a different key k2 to encrypt the message, or that of a malicious operator claiming that another player did such a thing. Unless the exchanged key is somehow committed to on chain in a way that the player can verify, this seems unavoidable, and if the exchanged key is committed to on chain in a way that the player can verify then they could prove how they voted.\nSo I think the ability to specifically cancel a key is important.\n\n post by ryanreich on May 15, 2019\n\n ryanreich\n\n I see the problem here: the public has no means to verify an operator’s claim that some vote is invalid due to encryption with the wrong key, or that some invalid vote is valid because it’s encrypted with a key that the operator knows but isn’t the one that particular voter should use. Fair enough: this violates the requirement that an operator failure shouldn’t affect the outcome of the vote.\nLet’s modify my previous aside, which suggested that each user’s public key be kept on-chain for identity verification, to also keep the operator’s public-key encryption of the secret key of each user (the user as well as the ZKP can verify this because both would also have the operator’s public key and the user’s own secret key; no one else can learn anything from it). The operator (and, correspondingly, the ZKP), is required to use that secret key to decrypt votes. This ensures that a malicious operator can’t pretend that a vote is invalid, or that a vote encrypted with someone else’s secret key is valid, since the means to validate is visible, if not usable, to the public.\nIn general, it seems to me that by encrypting with the operator’s public key, any internal state maintained by the operator can be manifested in public, indecipherably, but still visibly enough to figure in a zero-knowledge proof that it was used correctly by the operator.\n\n post by vbuterin on May 16, 2019\n\n vbuterin\n\n But then wouldn’t a user be able to prove what their secret key is, if they’re the ones to encrypt it to the operator? I suppose you could get around that if the operator encrypts, but then that seems like it would put a lot of load on the operator to make many more proofs.\n\n post by ryanreich on May 17, 2019\n\n ryanreich\n\n I don’t think this reveals anything that the people who can find out don’t already know. Maybe I should make explicit the structure that’s been coming together in pieces here.\nThe contract contains the following data object, annotated in some made-up, suggestive type system:\n{\n registry : Map PublicKey (PubKeyEnc SymKey, SymKeyEnc (Signed Vote)),\n operatorPubKey : PublicKey\n}\n\nEach voter also has a data object:\n{\n myVote : Vote,\n myPrivKey : PrivateKey,\n mySymKey : SymKey\n}\n\nThe operator has a very simple data object:\n{\n myPrivKey : PrivateKey\n}\n\nThe voter and operator data are, of course, known only to the respective parties, while the contract data is public. For each voter, there is an entry in registry (with pseudocode crypto API):\nregistry[pubKeyOf(voter.myPrivateKey)] = \n (\n pubKeyEnc(voter.mySymKey, contract.operatorPubKey),\n symKeyEnc(pubKeySign(voter.myVote, voter.myPrivKey))\n )\n\nThis can be constructed entirely by the voter, since it uses only data visible to them (their own and the contract’s).\nConversely, the operator can read each vote, including validating the voter:\nvotes = \n symKeyDec\n (\n encSignedVote, \n pubKeyDec(encSymKey, operator.myPrivKey)\n ).unsign(voterPubKey)\n for voterPubKey, (encSymKey, encSignedVote) in contract.registry.items()\n\nTherefore, the operator can construct a proof that M(votes) == outcome, for whatever outcome. The proof is of the existence only of operator.myPrivKey, and because of the expression above, includes proofs of the validity of each vote. It shows that the various nonsense blobs in the contract are actually encryptions of correct data.\nAs you can see, only each voter knows their own symmetric key; it is stored as a message encrypted to the operator alone, and its correctness is established by the proof that the equation holds with the definition of votes given.\n\n post by ryanreich on May 17, 2019\n\n ryanreich\n\n vbuterin\n\n Of course, only after posting that long thing did I understand what you were asking. I’ll leave it there since it seems useful, but I’ll answer your actual question here.\nIt does seem true that a voter could choose to reveal their own secret (symmetric) key in a way that someone else could verify, since it’s encrypted with the operator’s public key. And I do agree that this could be fixed if the operator actually kept their “public” key private, and placed that encrypted value themselves.\nWould this actually require more zero-knowledge proofs? I think the voter could actually be sure their correct vote was used, if the expression for votes I gave in the long post is the one that goes into the overall proof: it requires checking the signature on their vote. The operator should be unable to produce any valid voter-signed message, particularly not in the way that this exploit we’re talking about would require: the operator would have to place the wrong symmetric key in the registry, which would result in the vote being censored just because it doesn’t decrypt correctly (but then break the proof because the signature is also not validated); to actually place a fake vote, the operator would have to somehow come up with a fake symmetric key that causes this bad decryption to be a correctly-signed vote. This is just not feasible.\nThe voter could of course give up their private key to a dishonest operator. However, the operator would still have to figure out an alternate symmetric key that would decrypt the actual encrypted vote to a signed, fake vote of their choice. I don’t think this is feasible either, though that depends on the encryption method and seems similar to actually cracking the encryption entirely.\n\n post by vbuterin on May 17, 2019\n\n vbuterin\n\n My proposal was that the operator put the voter’s symmetric key on-chain encrypted with the operator’s own public key. The voter would have no way of verifying that this was actually done, unless the encryption scheme is deterministic, and in the latter case the voter could prove to others what their key is.\nI feel like any scheme that doesn’t involve a key revocation game is going to keep having these kinds of issues…\n\n post by ryanreich on May 20, 2019\n\n ryanreich\n\n After some thought, I have to agree that without the game it seems almost necessarily the case that a voter would be able to prove their vote. Essentially, the voter can prove their vote to a briber (thus soliciting a bribe) if they can supply a probabilistic algorithm computing their set of messages. In your scheme, they can enumerate it but not its complement. My scheme definitely has a deterministic proof of vote; actually, it shows up a lot earlier in the conversation, since the voter can always just reveal their “secret” key. Any voting scheme where the ultimate vote depends on a single message would have this problem; it has to be possible, no matter what the voter reveals, that they have omitted something important. Which is a game.\nThis has been very educational. I hope I wasn’t too obnoxious in the process.\n\n 2 months later\n\n post by barryWhiteHat on Jul 11, 2019\n\n barryWhiteHat\n\n We are staring to implment this http://github.com/barryWhiteHat/maci\nIf anyone wants to join this effort please join https://t.me/joinchat/LUgOpE7J2gstRcZqdERyvw\n\n 10 months later\n\n post by auryn on May 4, 2020\n\n auryn\n\n Hey everyone, just wanted to point out this topic, since it’s about a quadratic funding app built on MACI.\nThe project started at ETHDenver, where @barryWhiteHat and @weijiekoh helped us wrap our heads around MACI.\n\n 9 days later\n\n post by weijiekoh on May 13, 2020\n\n weijiekoh\n\n Hi all, I’ve recorded a basic explainer and demo of MACI: https://www.youtube.com/watch?v=sKuNj_IQVYI\nIt’s based on the implementation we’ve built here: https://github.com/barryWhiteHat/maci\n\n 9 months later\n\n post by BoltonBailey on Jan 28, 2021\n\n BoltonBailey\n\n barryWhiteHat\n\n EDIT I realized that MMRs were unnecessary for this, so I updated the post accordingly.\nEDIT 2 After thinking about this more, I realized there is a further simplification where we replace the hash of the history with a nonce. I also realized that the vote buyer and vote seller can do a 2 party MPC to create a signed message for which only the buyer knows the nonce, so this does not totally prevent the attack that was described. This still seems like it could be an improvement to me though, in that instead of writing a potentially large new public key to the state, we are only writing a nonce.\nThis attack described by @barryWhiteHat seems concerning to me.\n\nThis mitigates the attack, but if the attacker guesses the number of messages a user sends during the key-switch phase, then they can still offer to pay for the first vote after the key-switch phase by requesting that number of key-switch-messages followed by an action message. Thus, this only decreases the expected number of votes per attacker money by a factor roughly equal to the number of key-switch messages in this phase.\nWith an eye to preventing this kind of attack here is a version of MACI which makes this kind of attack impossible harder. I think it also simplifies the protocol somewhat, but there can be O(1) additive increase in message size, ZK-SNARK circuit size, and state-per-participant.\nIn order to avoid vote-selling by an attacker that can add the first messages to the list, it is necessary to have any sequence of messages be “undoable” in the sense that you must be able to add more messages to the list that invalidate these actions. To this end, in this version of MACI we get rid of the key_change messages. Instead, we require action messages to include the tip of a hash chain of all messages previously sent from that account a randomly generated nonce.\nThe operator now maintains state[i].action and state[i].nonce for each participant. When a message is received, the operator checks that the signature is valid and state[i].tip_hash = message.nonce. If these checks pass, then state[i].action is updated to the new action and the update state[i].nonce is (optionally) updated to a new nonce.\nA participant will now always be able to update their action, even if they update their initial action in the first message received by the system. Additionally, the participant sending the last message received by the system will not be able to prove their vote, because even if they expose their final encrypted message, they will be able to make actions beforehand that cause the hash chain tip on the final message to be invalid change the nonce, invalidating that message.\nIndeed, since the nonce and action are updated simultaneously, one could just modify the action field to contain a few extra bytes of data to be ignored by the mechanism. This leaves the protocol almost exactly the same as the original, the only change is that the change_key messages are removed and a comparison against the old action is added to the message and SNARK.\n\n 3 years later\n\n post by lingering on Oct 24, 2023\n\n lingering\n\n Hi,\nI am a bit confused here about the collusion resistance property.\nSeems it is a mixture of two classic security properties studied in the digital remote voting community.\nFirst, it looks quite similar to receipt-freeness, where a voter is prohibited from selling his vote as there is no way for him/her to prove the voted option.\nBut we have another desired property, coercion resistance, formalized by JCJ. It showed that a coerced voter can evade coercion/threat from the adversary by giving away a fake credential or revoting to overwrite the coerced vote.\nSo I see the collusion resistance property is essentially equivalent to recipient-freeness here.\nI think coercion is also a potential threat to blockchain-based voting protocol. I need coercion resistance in MACI as well.\n\n 4 months later\n\n post by auryn on Feb 26, 2024\n\n auryn\n\nMACI is receipt-free in precisely the way you described.\n\nA voter in MACI can create a fake receipt that is indistinguishable from a legitimate vote, by switching keys and casting a new vote and sharing a receipt from the now invalid vote.\n\n Powered by Discourse","tokens":5653,"squid":"ink-research","role":"Deep Scholar","at":1791264272136,"hash":"2f3265320e7dba5bee6e3ae35e00a718e97b97f2"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale-for-erc20-token-not-using-18-decimals/4946","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale for ERC20 token not using 18 decimals - Support / Contracts - OpenZeppelin Forum","text":"Rate to use for Crowdsale for ERC20 token not using 18 decimals \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 1 / 5\n\n Dec 2020\n\n Dec 2020\n\n post by TarrahArshad on Dec 4, 2020\n\n TarrahArshad\n\n i search and i seen ur document all in web but problme is stile in 18 decimals all work fine but in decimal lower 4-5 all number go wrong\nwhy do not list base on other decimals 2-4-5-10 provide examples\n\n Rate to use for Crowdsale?\n\n 3\n\n 2\n\n post by abcoathup on Dec 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nWelcome to the community \nTo calculate the rate for ERC20 tokens you can use the formula: TKNbits = rate * wei\nThis applies regardless of what decimals your token uses.\nSee the documentation for details: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nIf you need help calculating your rate, feel free to share your decimals and the amount of Ether per token.\n\n post by abcoathup on Dec 13, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nDid you need any more information?\n\n post by TarrahArshad on Dec 14, 2020\n\n TarrahArshad\n\n hi andrew\nthanks for ur response\nmy issue is rate .\ni have crowdsale on multi stage\nstage detail is ( start-price , end-price , cap , sold)\ni need calc current base on sold and sold is how many tokens solde before so price increase.\ni need know how increase rate and before that i need know formula for calc current rate depend on USD\nfor ex: $0.01-$0.25 its my range min-max price and i have max 500k token how calc current rate base on sold\nand second my problem is i see with example i setn 250 wei and 500 wei crowdsale buytokens send wrong amount if i send 1 eth i receive 250 token only\n250 wei rate must send 250 token if user send 1eth ? its wrong i no override ur crowdsale.sol i keeped ur but i create new function name buy and call ur buytokens original\nthis is my function\nfor buy and sell i use this\nfunction buy(address beneficiary, address upline) public payable {\n require(\n contributions[upline].buy_amount > 0 || upline == _owner,\n \"upline is wrong\"\n );\n\n uint256 weiAmount = msg.value;\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n require(\n CrowdsaleStages[stage].cap >= CrowdsaleStages[stage].sold + tokens,\n \"cap hit\"\n );\n\n total_tokenSold += tokens;\n CrowdsaleStages[stage].sold += tokens;\n\n buyTokens(beneficiary);\n\n updateUser(beneficiary, upline, tokens);\n }\n\n/**\n * @dev with this function client send request for selling\n * @param amount is how much token selling\n */\nfunction sell(uint256 amount) public returns (uint256 ETHAmount) {\n require(amount > 0, \"You need to sell at least some tokens\");\n require(\n contributions[msg.sender].buy_amount - amount >= 0,\n \"balance is not enoght\"\n );\n if (sellBook[msg.sender].sell_time > 0) {\n require(\n sellBook[msg.sender].sell_time + duration_sell <\n uint40(block.timestamp),\n \"in this hours u can't sell again\"\n );\n }\n // 1. calculate eth amount - 5%\n ETHAmount = _getEthAmount(amount);\n\n // 2. transfer token from sender to crowdsale address\n\n /* uint256 allowance = token.allowance(msg.sender, address(this));\n\n require(allowance >= amount, \"Check the token allowance\");\n\n token.transferFrom(msg.sender, address(this), amount);*/\n\n //msg.sender.transfer(amount);\n\n // 3. transfer fund\n msg.sender.transfer(ETHAmount);\n\n // 4. update stage\n contributions[msg.sender].buy_amount -= amount;\n\n sellBook[msg.sender].id = SellID++;\n sellBook[msg.sender].sell_amount = amount;\n sellBook[msg.sender].sell_time = uint40(block.timestamp);\n\n // emit event\n emit Sold(msg.sender, amount);\n\n return ETHAmount;\n}\n /**\n * The base rate function is overridden to revert, since this crowdsale doesn't use it, and\n * all calls to it are a mistake.\n */\nfunction rate() public view returns (uint256) {\n return CrowdsaleStages[stage].initialRate;\n}\n\n/**\n * @dev Overrides parent method taking into account variable rate.\n * @param weiAmount The value in wei to be converted into tokens\n * @return The number of tokens _weiAmount wei will buy at present time\n */\nfunction _getEthAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 currentRate = getCurrentRate();\n return weiAmount.div(currentRate).mul(uint256(95).div(uint256(100)));\n}\n\n post by abcoathup on Dec 14, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nThe Crowdsales documentation can be found here: https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\nYou could take the ideas from IncreasingPriceCrowdsale, extend Crowdsale and in a getCurrentRate function specify the rate after specific times.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\nIf you are selling based on a set fiat value, then you may be better to create a Crowdsale that accepts a stable coin rather than Ether. You could use the ideas from OpenZeppelin Contracts to do this.\n\nPlease see the documentation for calculating rate: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nI recommend starting with something simple for testing purposes, such as a rate of 1 (assuming decimals of 18).\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to calculate rate for a crowdsale?\n\n Contracts\n\n 3\n\n 4.2k\n\n Sep 2021\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Whats a good way to implement multiple rates into crowdsale?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 792\n\n Mar 2022","tokens":1464,"squid":"ink-security_audits","role":"Sentinel","at":1791264287145,"hash":"e565b96641942ca325138181e144b0047ac189f1"}
{"url":"https://specs.optimism.io/governance/mint-manager.html","domain":"specs.optimism.io","title":"MintManager - OP Stack Specification","text":"MintManager\n\nTable of Contents\n\nOverview\nDefinitions\n\nMint Cap\nMint Period\n\nAssumptions\n\naMM-001: GovernanceToken implements required functions correctly\n\nMitigations\n\naMM-002: Block timestamp reliability\n\nMitigations\n\naMM-003: Owner acts within governance constraints\n\nMitigations\n\naMM-004: Valid successor MintManager\n\nMitigations\n\nDependencies\nInvariants\n\niMM-001: Mint cap enforcement\n\nImpact\n\niMM-002: Time-based minting restriction\n\nImpact\n\niMM-003: Exclusive minting authority\n\nImpact\n\niMM-004: Ownership transfer control\n\nImpact\n\nFunction Specifications\n\nconstructor\nmint\nupgrade\n\nOverview\nThe MintManager contract serves as the owner of the GovernanceToken and controls the token\ninflation schedule. It enforces rate-limited minting with a maximum cap per minting operation and a minimum time\nperiod between mints. The contract is upgradeable, allowing the owner to transfer control to a new MintManager\nimplementation if changes to the inflation schedule are required.\nDefinitions\nMint Cap\nThe maximum percentage of the total token supply that can be minted in a single minting operation. Set to 2%\n(represented as 20/1000 with 4 decimal precision).\nMint Period\nThe minimum time interval that must elapse between consecutive minting operations. Set to 365 days.\nAssumptions\naMM-001: GovernanceToken implements required functions correctly\nThe GovernanceToken contract correctly implements the mint(address,uint256) function, transferOwnership(address)\nfunction, and totalSupply() view function according to their expected behavior. Specifically:\n\nmint() increases the token balance of the specified account by the specified amount\ntotalSupply() accurately returns the current total supply of tokens\ntransferOwnership() transfers ownership to the specified address\n\nMitigations\n\nThe GovernanceToken contract is part of the same protocol and is subject to the same security audits\nThe interface is well-defined in IGovernanceToken.sol\nThe implementation follows OpenZeppelin's standard patterns\n\naMM-002: Block timestamp reliability\nThe EVM block.timestamp value is sufficiently reliable for enforcing the 365-day minting period. While miners can\nmanipulate timestamps within a small range (~15 seconds), this manipulation is negligible compared to the 365-day\nperiod.\nMitigations\n\nThe 365-day period is long enough that minor timestamp manipulation has no practical impact\nEthereum consensus rules limit timestamp manipulation\nThe time-based restriction is a rate limit, not a precise scheduling mechanism\n\naMM-003: Owner acts within governance constraints\nThe contract owner (typically a governance multisig or DAO) will only call mint() and upgrade() functions in\naccordance with governance decisions and the protocol's established rules. The owner will not abuse their authority\nto mint excessive tokens or transfer ownership to malicious addresses.\nMitigations\n\nOwner is expected to be a governance-controlled address (e.g., multisig or Governor contract)\nAll minting operations are subject to the on-chain mint cap and time restrictions\nOwnership transfers are transparent on-chain and subject to community oversight\nThe upgrade mechanism allows for replacing a compromised or malicious owner\n\naMM-004: Valid successor MintManager\nWhen upgrading, the owner will provide a valid, non-zero address for the new MintManager contract. The successor\ncontract will be properly implemented and tested before the upgrade is executed.\nMitigations\n\nGovernance processes include review and testing of new MintManager implementations\nThe upgrade transaction is subject to governance approval and timelock mechanisms\nThe contract enforces a basic check that the successor address is not the zero address\n\nDependencies\nThis specification depends on:\n\nGovernanceToken - The ERC20Votes token that this contract has permission to mint\n\nInvariants\niMM-001: Mint cap enforcement\nNo single minting operation can mint more than the Mint Cap of the current total token supply.\nFull Description:\nAny call to mint() MUST enforce that the requested mint amount does not exceed the Mint Cap. This\nensures that token inflation is bounded and predictable.\nImpact\nSeverity: Medium\nIf this invariant is violated, the owner could mint an unlimited number of tokens, leading to:\n\nSevere token dilution for existing holders\nLoss of governance voting power for existing token holders\nDestruction of the token's economic value\nComplete loss of trust in the protocol's governance system\n\nNote: This is rated Medium because it requires assumption aMM-003 (owner acts within governance constraints) to fail.\nIf aMM-003 does not hold (i.e., the owner is malicious or compromised), this would be elevated to Critical severity.\nThe contract enforces this invariant on-chain, providing defense-in-depth against governance failures.\niMM-002: Time-based minting restriction\nMinting operations can only occur after the Mint Period has elapsed since the previous mint.\nFull Description:\nAny call to mint() MUST revert if the Mint Period has not elapsed since the last mint. This ensures\nthat minting operations are rate-limited, preventing rapid inflation even if the owner attempts multiple mints.\nImpact\nSeverity: Medium\nIf this invariant is violated, the owner could:\n\nMint the Mint Cap multiple times in rapid succession\nCause uncontrolled inflation far exceeding the intended rate\nUndermine the predictability and transparency of the token supply schedule\nViolate the expectations of token holders regarding inflation rates\n\nNote: This is rated Medium because it requires assumption aMM-003 (owner acts within governance constraints) to fail.\nIf aMM-003 does not hold (i.e., the owner is malicious or compromised), this would be elevated to Critical severity.\nThe contract enforces this invariant on-chain, providing defense-in-depth against governance failures.\niMM-003: Exclusive minting authority\nOnly the contract owner can successfully call the mint() function to create new governance tokens.\nFull Description:\nThe mint() function MUST be protected by the onlyOwner modifier, ensuring that only the address returned by\nowner() can execute minting operations. Any call from a non-owner address MUST revert.\nImpact\nSeverity: Critical\nIf this invariant is violated:\n\nUnauthorized parties could mint tokens without governance approval\nThe entire governance system would be compromised\nToken supply would become unpredictable and uncontrolled\nThe economic security of the protocol would be destroyed\n\niMM-004: Ownership transfer control\nOnly the current contract owner can transfer ownership of the GovernanceToken to a new MintManager.\nFull Description:\nThe upgrade() function MUST be protected by the onlyOwner modifier, ensuring that only the current owner can\ninitiate an upgrade to a new MintManager implementation. This prevents unauthorized parties from taking control of\nthe token minting authority.\nImpact\nSeverity: Critical\nIf this invariant is violated:\n\nAttackers could transfer ownership to a malicious contract\nThe governance system would lose control over token minting\nA malicious MintManager could mint unlimited tokens or implement harmful policies\nThe protocol's governance would be permanently compromised\n\nFunction Specifications\nconstructor\nconstructor(address _upgrader, address _governanceToken)\n\nInitializes the MintManager contract with the specified owner and governance token.\nParameters:\n\n_upgrader: The address that will become the owner of this contract\n_governanceToken: The address of the GovernanceToken contract that this manager will control\n\nBehavior:\n\nMUST call transferOwnership(_upgrader) to set the contract owner\nMUST set governanceToken to the provided _governanceToken address\nMUST initialize mintPermittedAfter to enable immediate first mint while enforcing restrictions on subsequent mints\nMUST NOT validate that _upgrader or _governanceToken are non-zero addresses (caller responsibility)\n\nmint\nfunction mint(address _account, uint256 _amount) public onlyOwner\n\nMints new governance tokens to the specified account, subject to time and cap restrictions.\nParameters:\n\n_account: The address that will receive the newly minted tokens\n_amount: The number of tokens to mint (in wei, with 18 decimals)\n\nBehavior:\n\nMUST revert if caller is not the contract owner (enforced by onlyOwner modifier)\nMUST revert if the Mint Period has not elapsed since the last mint\nMUST revert if _amount exceeds the Mint Cap\nMUST set mintPermittedAfter to block.timestamp + MINT_PERIOD to enforce the next Mint Period\nMUST call governanceToken.mint(_account, _amount) to perform the actual minting\n\nupgrade\nfunction upgrade(address _newMintManager) public onlyOwner\n\nTransfers ownership of the GovernanceToken to a new MintManager contract, effectively upgrading the minting system.\nParameters:\n\n_newMintManager: The address of the new MintManager contract that will become the owner of the GovernanceToken\n\nBehavior:\n\nMUST revert if caller is not the contract owner (enforced by onlyOwner modifier)\nMUST revert if _newMintManager == address(0)\nMUST call governanceToken.transferOwnership(_newMintManager) to transfer ownership","tokens":2281,"squid":"ink-governance","role":"Council Listener","at":1791264287422,"hash":"810f2991c55e01fd93d3a83c549ed2d5755a578d"}
{"url":"https://specs.optimism.io/interop/token-bridging.html","domain":"specs.optimism.io","title":"Token Bridging - OP Stack Specification","text":"Token Bridging\n\nTable of Contents\n\nOverview\nSuperchainERC20 standard\n\nProperties\nIERC7802\n\ncrosschainMint\ncrosschainBurn\nCrosschainMint\nCrosschainBurn\n\nSuperchainTokenBridge\nDiagram\nImplementation\n\nOverview\nWithout a standardized security model, bridged assets may not be fungible with each other.\nThe SuperchainERC20 standard is a set of properties and an interface allowing ERC20 to be fungible across the\nSuperchain using the official SuperchainTokenBridge.\nThe SuperchainTokenBridge is a predeploy that builds on the messaging protocol as the most trust-minimized bridging solution.\nSuperchainERC20 standard\nProperties\nThe standard will build on top of ERC20, implement the\nIERC7802\ninterface, and include the following properties:\n\nImplement the ERC20 interface\nImplement the ERC7802 interface\nAllow SuperchainTokenBridge to call\ncrosschainMint and crosschainBurn.\nBe deployed at the same address on every chain in the Superchain.\n\nThe third property will allow the SuperchainTokenBridge to have a liquidity guarantee,\nwhich would not be possible in a model based on lock/unlock.\nLiquidity availability is fundamental to achieving fungibility.\nSuperchainTokenBridge does not have to be the exclusive caller of crosschainMint and crosschainBurn;\nother addresses may also be permitted to call these functions.\nThe fourth property removes the need for cross-chain access control lists.\nOtherwise, the SuperchainTokenBridge would need a way to verify if the tokens it mints on\ndestination correspond to the tokens that were burned on source.\nSame address abstracts away cross-chain validation.\nOne way to guarantee the same address across the Superchain (and also bind it to the same init_code\nand constructor arguments) is to use the\nCreate2Deployer preinstall.\nThere is also the OptimismSuperchainERC20Factory\npredeploy that facilitates this process for L1 native tokens.\nNotice that ERC20s that do not implement the standard can still be fungible\nusing interop message passing\nusing a custom bridge or implementing sendERC20 and relayERC20 on their own contracts.\nAn example implementation of the standard is available at SuperchainERC20.sol\nIERC7802\nImplementations of the SuperchainERC20 standard will\nbe required to implement the IERC7802 interface,\nthat includes two external functions and two events:\ncrosschainMint\nMints _amount of token to address _account.\ncrosschainMint(address _account, uint256 _amount)\n\ncrosschainBurn\nBurns _amount of token from address _account.\ncrosschainBurn(address _account, uint256 _amount)\n\nCrosschainMint\nMUST trigger when crosschainMint is called\nevent CrosschainMint(address indexed _to, uint256 _amount, address indexed _sender)\n\nCrosschainBurn\nMUST trigger when crosschainBurn is called\nevent CrosschainBurn(address indexed _from, uint256 _amount, address indexed _sender)\n\nSuperchainTokenBridge\nThe SuperchainTokenBridge is a predeploy that works as an abstraction\non top of the L2ToL2CrossDomainMessenger\nfor token bridging.\nThe L2ToL2CrossDomainMessenger is used for replay protection,\ndomain binding and access to additional message information.\nThe SuperchainTokenBridge includes two functions for bridging:\n\nsendERC20: initializes a cross-chain transfer of a SuperchainERC20\nby burning the tokens locally and sending a message to the SuperchainTokenBridge\non the target chain using the L2toL2CrossDomainMessenger.\nAdditionally, it returns the msgHash_ crafted by the L2toL2CrossDomainMessenger.\nrelayERC20: processes incoming messages from the L2toL2CrossDomainMessenger\nand mints the corresponding amount of the SuperchainERC20.\n\nThe full specifications and invariants are detailed\nin the predeploys spec.\nDiagram\nThe following diagram depicts a cross-chain transfer.\n\nImplementation\nAn example implementation for the sendERC20 and relayERC20 functions is provided.\nfunction sendERC20(SuperchainERC20 _token, address _to, uint256 _amount, uint256 _chainId) external returns (bytes32 msgHash_) {\n _token.crosschainBurn(msg.sender, _amount);\n\n bytes memory _message = abi.encodeCall(this.relayERC20, (_token, msg.sender, _to, _amount));\n\n msgHash_ = L2ToL2CrossDomainMessenger.sendMessage(_chainId, address(this), _message);\n\n emit SentERC20(address(_token), msg.sender, _to, _amount, _chainId);\n}\n\nfunction relayERC20(SuperchainERC20 _token, address _from, address _to, uint256 _amount) external {\n require(msg.sender == address(L2ToL2CrossChainMessenger));\n require(L2ToL2CrossChainMessenger.crossDomainMessageSender() == address(this));\n\n uint256 _source = L2ToL2CrossChainMessenger.crossDomainMessageSource();\n\n _token.crosschainMint(_to, _amount);\n\n emit RelayedERC20(address(_token), _from, _to, _amount, _source);\n}","tokens":1168,"squid":"ink-governance","role":"Council Listener","at":1791264297496,"hash":"e995cd652fa5529cfa1d19e9395a99f4fb4c21ec"}
{"url":"https://forum.openzeppelin.com/t/rate-to-use-for-crowdsale-for-erc20-token-not-using-18-decimals/4946/3","domain":"forum.openzeppelin.com","title":"Rate to use for Crowdsale for ERC20 token not using 18 decimals - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Dec 2020\n\n 3 / 5\n\n Dec 2020\n\n Dec 2020\n\n post by TarrahArshad on Dec 4, 2020\n\n TarrahArshad\n\n i search and i seen ur document all in web but problme is stile in 18 decimals all work fine but in decimal lower 4-5 all number go wrong\nwhy do not list base on other decimals 2-4-5-10 provide examples\n\n Rate to use for Crowdsale?\n\n 3\n\n 2\n\n post by abcoathup on Dec 7, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nWelcome to the community \nTo calculate the rate for ERC20 tokens you can use the formula: TKNbits = rate * wei\nThis applies regardless of what decimals your token uses.\nSee the documentation for details: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nIf you need help calculating your rate, feel free to share your decimals and the amount of Ether per token.\n\n post by abcoathup on Dec 13, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nDid you need any more information?\n\n post by TarrahArshad on Dec 14, 2020\n\n TarrahArshad\n\n hi andrew\nthanks for ur response\nmy issue is rate .\ni have crowdsale on multi stage\nstage detail is ( start-price , end-price , cap , sold)\ni need calc current base on sold and sold is how many tokens solde before so price increase.\ni need know how increase rate and before that i need know formula for calc current rate depend on USD\nfor ex: $0.01-$0.25 its my range min-max price and i have max 500k token how calc current rate base on sold\nand second my problem is i see with example i setn 250 wei and 500 wei crowdsale buytokens send wrong amount if i send 1 eth i receive 250 token only\n250 wei rate must send 250 token if user send 1eth ? its wrong i no override ur crowdsale.sol i keeped ur but i create new function name buy and call ur buytokens original\nthis is my function\nfor buy and sell i use this\nfunction buy(address beneficiary, address upline) public payable {\n require(\n contributions[upline].buy_amount > 0 || upline == _owner,\n \"upline is wrong\"\n );\n\n uint256 weiAmount = msg.value;\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n require(\n CrowdsaleStages[stage].cap >= CrowdsaleStages[stage].sold + tokens,\n \"cap hit\"\n );\n\n total_tokenSold += tokens;\n CrowdsaleStages[stage].sold += tokens;\n\n buyTokens(beneficiary);\n\n updateUser(beneficiary, upline, tokens);\n }\n\n/**\n * @dev with this function client send request for selling\n * @param amount is how much token selling\n */\nfunction sell(uint256 amount) public returns (uint256 ETHAmount) {\n require(amount > 0, \"You need to sell at least some tokens\");\n require(\n contributions[msg.sender].buy_amount - amount >= 0,\n \"balance is not enoght\"\n );\n if (sellBook[msg.sender].sell_time > 0) {\n require(\n sellBook[msg.sender].sell_time + duration_sell <\n uint40(block.timestamp),\n \"in this hours u can't sell again\"\n );\n }\n // 1. calculate eth amount - 5%\n ETHAmount = _getEthAmount(amount);\n\n // 2. transfer token from sender to crowdsale address\n\n /* uint256 allowance = token.allowance(msg.sender, address(this));\n\n require(allowance >= amount, \"Check the token allowance\");\n\n token.transferFrom(msg.sender, address(this), amount);*/\n\n //msg.sender.transfer(amount);\n\n // 3. transfer fund\n msg.sender.transfer(ETHAmount);\n\n // 4. update stage\n contributions[msg.sender].buy_amount -= amount;\n\n sellBook[msg.sender].id = SellID++;\n sellBook[msg.sender].sell_amount = amount;\n sellBook[msg.sender].sell_time = uint40(block.timestamp);\n\n // emit event\n emit Sold(msg.sender, amount);\n\n return ETHAmount;\n}\n /**\n * The base rate function is overridden to revert, since this crowdsale doesn't use it, and\n * all calls to it are a mistake.\n */\nfunction rate() public view returns (uint256) {\n return CrowdsaleStages[stage].initialRate;\n}\n\n/**\n * @dev Overrides parent method taking into account variable rate.\n * @param weiAmount The value in wei to be converted into tokens\n * @return The number of tokens _weiAmount wei will buy at present time\n */\nfunction _getEthAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 currentRate = getCurrentRate();\n return weiAmount.div(currentRate).mul(uint256(95).div(uint256(100)));\n}\n\n post by abcoathup on Dec 14, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @TarrahArshad,\nThe Crowdsales documentation can be found here: https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\nYou could take the ideas from IncreasingPriceCrowdsale, extend Crowdsale and in a getCurrentRate function specify the rate after specific times.\n\nI put together an example of manually setting a crowdsale rate using this. This code has not been tested or audited. Please appropriately test and audit before using in production.\nSetting crowdsale rate manually\n\nIf you are selling based on a set fiat value, then you may be better to create a Crowdsale that accepts a stable coin rather than Ether. You could use the ideas from OpenZeppelin Contracts to do this.\n\nPlease see the documentation for calculating rate: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nI recommend starting with something simple for testing purposes, such as a rate of 1 (assuming decimals of 18).\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Rate for Crowdsale\n\n Contracts\n\n 2\n\n 1.5k\n\n Dec 2020\n\n How to calculate rate for a crowdsale?\n\n Contracts\n\n 3\n\n 4.2k\n\n Sep 2021\n\n Handling rate (not whole number) in crowdsale\n\n Contracts\n\n crowdsale\n\n 6\n\n 1.2k\n\n Mar 2022\n\n Whats a good way to implement multiple rates into crowdsale?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 792\n\n Mar 2022","tokens":1448,"squid":"ink-security_audits","role":"Sentinel","at":1791264297686,"hash":"8b2957c2db4a1cd1d3f36ac14a2f257bf1c145a7"}
{"url":"https://specs.optimism.io/interop/predeploys.html","domain":"specs.optimism.io","title":"Predeploys - OP Stack Specification","text":"Predeploys\n\nTable of Contents\n\nOverview\nCrossL2Inbox\n\nAccess-list\n\ntype 1: Lookup identity\ntype 2: Chain-ID extension\ntype 3: Checksum\n\nAssumptions\n\nGas Schedule Dependencies\nStorage Slot Calculation\nEVM Warming Behavior\n\nFunctions\n\nvalidateMessage\n\nExecutingMessage Event\nReference implementation\nDeposit Handling\n\nL2ToL2CrossDomainMessenger\n\nrelayMessage Invariants\nsendMessage Invariants\nresendMessage Invariants\nMessage Versioning\nInterfaces\n\nSending Messages\n\nRe-sending Messages\n\nRelaying Messages\n\nOptimismSuperchainERC20Factory\n\nOptimismSuperchainERC20\nOverview\n\nProxy\nBeacon Pattern\nDeployment history\n\nFunctions\n\ndeploy\n\nEvents\n\nOptimismSuperchainERC20Created\n\nDeployment Flow\n\nOptimismSuperchainERC20Beacon\n\nOverview\n\nOptimismMintableERC20Factory\n\nOptimismMintableERC20\nUpdates\nFunctions\n\ncreateOptimismMintableERC20WithDecimals\ncreateOptimismMintableERC20\ncreateStandardL2Token\n\nEvents\n\nOptimismMintableERC20Created\nStandardL2TokenCreated\n\nL2StandardBridge\n\nUpdates\n\nconvert\nConverted\n\nInvariants\nConversion Flow\n\nSuperchainETHBridge\nETHLiquidity\nSuperchainTokenBridge\n\nOverview\nFunctions\n\nsendERC20\nrelayERC20\n\nEvents\n\nSentERC20\nRelayedERC20\n\nDiagram\nInvariants\n\nOverview\nFour new system level predeploys are introduced for managing cross chain messaging and tokens, along with\nan update to the OptimismMintableERC20Factory and L2StandardBridge contracts with additional functionalities.\nCrossL2Inbox\nConstantValue\nAddress0x4200000000000000000000000000000000000022\n\nThe CrossL2Inbox is the system predeploy for cross chain messaging. Anyone can trigger the execution or validation\nof cross chain messages, on behalf of any user.\nTo ensure safety of the protocol, the Message Invariants must be enforced.\nAccess-list\nExecution of messages is statically pre-declared in transactions,\nto ensure the cross-chain validity can be verified outside the single-chain EVM environment constraints.\nAfter pre-verification of the access-list, the CrossL2Inbox can allow messages\nto execute when there is a matching pre-verified access-list entry.\nEach executing message is declared with 3 typed access-list entries:\n\n1: Lookup identity\n2: Chain-ID extension\n3: Checksum\n\nThe type of entry is encoded in the first byte.\nType 0 is reserved, so valid access-list entries are always non-zero.\nNote that the access-list entries may be de-duplicated:\nthe same message may be executed multiple times.\nThe access-list content might not always be a multiple of 3.\nThe access-list content is ordered:\n\nafter type 1, a type 2 or 3 entry is expected.\nafter type 2, a type 3 entry is expected.\n\nNote that type 1 and 2 are only enforced out-of-protocol:\nthese provide a hint, for viable block-building,\nto lookup data to determine the validity of the checksum without prior transaction execution.\nNot every access-list entry may be executed:\naccess-list content must not be used by applications to interpret results of transactions,\nthe ExecutingMessage event describes in detail what is executed.\nTo prevent cross-contamination of access-list contents,\nthe checksum entry commits to the contents of the other entries.\nThe checksum will be invalid if the wrong entries are interpreted with it.\nThe CrossL2Inbox only checks the checksum is present in the access-list:\nthe presence of other needed entries is enforced during pre-validation.\ntype 1: Lookup identity\nPacked attributes for message lookup.\nThis type of entry serves as hint of the message identity,\nfor verification of the checksum and is not verified in the protocol state-transition or fork-choice.\n0..1: type byte, always 0x01\n1..4: reserved, zeroed by default\n4..12: big-endian uint64 chain ID\n12..20: big-endian uint64, block number\n20..28: big-endian uint64, timestamp\n28..32: big-endian uint32, log index\n\nChain IDs larger than uint64 are supported, with an additional chain-ID-extension entry.\nThe lower 64 bits of the chain-ID are always encoded in the lookup entry.\ntype 2: Chain-ID extension\nLarge uint256 Chain IDs are represented with an extension entry,\nincluded right after the lookup identity entry.\nLike the lookup identity entry, this entry-type is not verified in the protocol state-transition or fork-choice.\nThis extension entry does not have to be included for chain-IDs that fit in uint64.\n0..1: type byte, always 0x02\n1..8: zero bytes\n8..32: upper 24 bytes of big-endian uint256 chain-ID\n\ntype 3: Checksum\nThe checksum is a versioned hash, committing to implied attributes.\nThese implied attributes are compared against the full version\nof the executing message by recomputing the checksum from the full version.\nThe full version is retrieved based on the preceding lookup entry and optional chain-ID extension.\nThe checksum is iteratively constructed:\nthis allows services to work with intermediate implied data.\nE.g. a verifier may not persist the origin or msgHash,\nbut does store a logHash.\n# Syntax:\n# H(bytes): keccak256 hash function\n# ++: bytes concatenation\nlogHash = H(bytes20(idOrigin) ++ msgHash)\n# This matches the trailing part of the lookupID\nidPacked = bytes12(0) ++ idBlockNumber ++ idTimestamp ++ idLogIndex\nidLogHash = H(logHash ++ idPacked)\nbareChecksum = H(idLogHash ++ idChainID)\ntypeByte = 0x03\nchecksum = typeByte ++ bareChecksum[1:]\n\nAssumptions\nGas Schedule Dependencies\nThe CrossL2Inbox contract's validation mechanism relies on precise gas cost calculations for storage operations.\nSLOAD operations cost 2100 gas for cold access and 100 gas for warm access.\nThe contract uses these gas costs to implement its validation mechanism through gas introspection.\nThe WARM_READ_THRESHOLD is set to 1000 gas, providing a safe buffer between warm (100 gas) and cold (2100 gas) access costs.\nStorage Slot Calculation\nStorage slots are calculated using a 248-bit hash space (31 bytes), providing cryptographically secure collision resistance.\nThe slot calculation follows this process:\n\nThe checksum is derived from the message identifier and content\nThe first byte is reserved for the type (0x03)\nThe remaining 31 bytes form the storage slot key\n\nThis design ensures there are no collisions between different message types, provides deterministic slot assignment,\nenables efficient slot lookup, and guarantees secure message validation.\nEVM Warming Behavior\nThe CrossL2Inbox contract relies on specific EVM behavior regarding storage slot warming.\n\nPer-transaction warming ensures storage warming is scoped to individual transactions.\nWarm slots from previous transactions do not affect the current transaction,\nand each transaction's access list operates independently.\n\nWhen a transaction reverts, all warm slots are rolled back.\nFailed transactions do not persist any warm slots,\nand all access list entries are cleared on revert.\n\nThe access list is the exclusive mechanism for warming slots.\nNo other contract function may warm up storage without message validation,\nand warm slots cannot be created through alternative means.\n\nFunctions\nvalidateMessage\nA helper to enable contracts to provide their own public entrypoints for cross chain interactions.\nEmits the ExecutingMessage event to signal the transaction has a cross chain message to validate.\nThe following fields are required for validating a cross chain message:\nNameTypeDescription\n_idIdentifierA Identifier pointing to the initiating message.\n_msgHashbytes32The keccak256 hash of the message payload matching the initiating message.\n\nfunction validateMessage(Identifier calldata _id, bytes32 _msgHash)\n\nExecutingMessage Event\nThe ExecutingMessage event represents an executing message. It MUST be emitted on every call\nto validateMessage.\nevent ExecutingMessage(bytes32 indexed msgHash, Identifier identifier);\n\nThe data encoded in the event contains the keccak hash of the msg and the Identifier.\nThe following pseudocode shows the deserialization:\nbytes32 msgHash = log.topics[1];\nIdentifier identifier = abi.decode(log.data, (Identifier));\n\nEmitting the hash of the message is more efficient than emitting the\nmessage in its entirety. Equality with the initiating message can be handled off-chain through\nhash comparison.\nReference implementation\nA simple implementation of the validateMessage function is included below.\nfunction validateMessage(Identifier calldata _id, bytes32 _msgHash) external {\n bytes32 checksum = calculateChecksum(_id, _msgHash);\n\n (bool _isSlotWarm,) = _isWarm(checksum);\n\n if (!_isSlotWarm) revert NotInAccessList();\n\n emit ExecutingMessage(_msgHash, _id);\n}\n\ncalculateChecksum implements the checksum computation (including type-byte) as defined\nin the access-list checksum computation spec.\n_isWarm checks that the access-list prepared the checksum storage key to be warm.\nNo other contract function may warm up this storage without message validation.\nAn example of a custom entrypoint utilizing validateMessage to consume a known\nevent. Note that in this example, the contract is consuming its own event\nfrom another chain, however any event emitted from any contract is consumable!\ncontract MyCrossChainApp {\n event MyCrossChainEvent();\n\n function sendMessage() external {\n emit MyCrossChainEvent();\n }\n\n function relayMessage(Identifier calldata _id, bytes calldata _msg) external {\n // Example app-level validation\n // - Expected event via the selector (first topic)\n // - Assertion on the expected emitter of the event\n require(MyCrossChainEvent.selector == _msg[:32]);\n require(_id.origin == address(this));\n\n // Authenticate this cross chain message\n CrossL2Inbox.validateMessage(_id, keccak256(_msg));\n\n // ABI decode the event message & perform actions.\n // ...\n }\n}\n\nDeposit Handling\nAny call to the CrossL2Inbox that would emit an ExecutingMessage event will revert if the\ntransaction did not declare an access list including the message checksum, as\ndescribed above. Because deposit transactions do not have access lists,\nall calls to the CrossL2Inbox originating within a deposit transaction will revert.\nL2ToL2CrossDomainMessenger\nConstantValue\nAddress0x4200000000000000000000000000000000000023\nMESSAGE_VERSIONuint256(0)\n\nThe L2ToL2CrossDomainMessenger is a higher level abstraction on top of the CrossL2Inbox that\nprovides general message passing, utilized for secure transfers ERC20 tokens between L2 chains.\nMessages sent through the L2ToL2CrossDomainMessenger on the source chain receive both replay protection\nas well as domain binding, i.e. the executing transaction can only be valid on a single chain.\nrelayMessage Invariants\n\nThe Identifier.origin MUST be address(L2ToL2CrossDomainMessenger)\nThe _destination chain id MUST be equal to the local chain id\nMessages MUST NOT be relayed more than once\n\nsendMessage Invariants\n\nSent Messages MUST be uniquely identifiable\nIt MUST store the message hash in the sentMessages mapping\nIt MUST emit the SentMessage event\n\nresendMessage Invariants\n\nIt MUST NOT be possible to re-emit a SentMessage event that has not been sent\nIt MUST emit the SentMessage event\n\nMessage Versioning\nVersioning is handled in the most significant bits of the nonce, similarly to how it is handled by\nthe CrossDomainMessenger.\nfunction messageNonce() public view returns (uint256) {\n return Encoding.encodeVersionedNonce(nonce, MESSAGE_VERSION);\n}\n\nInterfaces\nThe L2ToL2CrossDomainMessenger uses a similar interface to the L2CrossDomainMessenger, but\nthe _minGasLimit is removed to prevent complexity around EVM gas introspection and the _destination\nchain is included instead.\nSending Messages\nThe following function is used for sending messages between domains:\nfunction sendMessage(uint256 _destination, address _target, bytes calldata _message) external returns (bytes32);\n\nIt returns the hash of the message being sent,\nwhich is used to track whether the message has successfully been relayed.\nIt also emits a SentMessage event with the necessary metadata to execute when relayed on the destination chain.\nevent SentMessage(uint256 indexed destination, address indexed target, uint256 indexed messageNonce, address sender, bytes message);\n\nAn explicit _destination chain and nonce are used to ensure that the message can only be played on a single remote\nchain a single time. The _destination is enforced to not be the local chain to avoid edge cases.\nThere is no need for address aliasing as the aliased address would need to commit to the source chain's chain id\nto create a unique alias that commits to a particular sender on a particular domain and it is far more simple\nto assert on both the address and the source chain's chain id rather than assert on an unaliased address.\nIn both cases, the source chain's chain id is required for security. Executing messages will never be able to\nassume the identity of an account because msg.sender will never be the identity that initiated the message,\nit will be the L2ToL2CrossDomainMessenger and users will need to callback to get the initiator of the message.\nThe _destination MUST NOT be the chain-ID of the local chain and a locally defined nonce MUST increment on\nevery call to sendMessage.\nNote that sendMessage is not payable.\nRe-sending Messages\nThe resendMessage function is used to re-emit a SentMessage event for a message that has already been sent.\nIt will calculate the message hash using the inputs, and check that the message hash is stored in the sentMessages\nmapping prior to emitting the SentMessage event.\n function resendMessage(\n uint256 _destination,\n uint256 _nonce,\n address _sender,\n address _target,\n bytes calldata _message\n )\n external;\n\nRelaying Messages\nThe following diagram shows the flow for sending a cross chain message using the L2ToL2CrossDomainMessenger.\nEach subsequent call is labeled with a number.\n\nWhen relaying a message through the L2ToL2CrossDomainMessenger, it is important to require that\nthe _destination be equal to block.chainid to ensure that the message is only valid on a single\nchain. The hash of the message is used for replay protection.\nIt is important to ensure that the source chain is in the dependency set of the destination chain, otherwise\nit is possible to send a message that is not playable.\nA message is relayed by providing the identifier of a SentMessage\nevent along with its corresponding message payload.\nfunction relayMessage(ICrossL2Inbox.Identifier calldata _id, bytes calldata _sentMessage) external payable returns (bytes memory returnData_) {\n require(_id.origin == Predeploys.L2_TO_L2_CROSS_DOMAIN_MESSENGER);\n CrossL2Inbox(Predeploys.CROSS_L2_INBOX).validateMessage(_id, keccak256(_sentMessage));\n\n // log topics\n (bytes32 selector, uint256 _destination, address _target, uint256 _nonce) =\n abi.decode(_sentMessage[:128], (bytes32,uint256,address,uint256));\n\n require(selector == SentMessage.selector);\n require(_destination == block.chainid);\n\n // log data\n (address _sender, bytes memory _message) = abi.decode(_sentMessage[128:], (address,bytes));\n\n bool success;\n (success, returnData_) = _target.call(_target, msg.value, _message);\n require(success);\n successfulMessages[messageHash] = true;\n emit RelayedMessage(_source, _nonce, messageHash, keccak256(returnData_));\n}\n\nUpon successful delivery, an event is emitted with useful information. Notably the hash of the returnData that\ncan be used to continue execution for anyone that depends on it without needing an explicit callback message to\nbe sent back.\nevent RelayedMessage(uint256 indexed source, uint256 indexed messageNonce, bytes32 indexed messageHash, bytes32 returnDataHash);\n\nNote that the relayMessage function is payable to enable relayers to earn in the gas paying asset.\nTo enable cross chain authorization patterns, both the _sender and the _source MUST be exposed via public\ngetters.\nOptimismSuperchainERC20Factory\nConstantValue\nAddress0x4200000000000000000000000000000000000026\n\nOptimismSuperchainERC20\nThe OptimismSuperchainERC20Factory creates ERC20 contracts that implements the SuperchainERC20 standard,\ngrants mint-burn rights to the L2StandardBridge (OptimismSuperchainERC20)\nand includes a remoteToken variable.\nThese ERC20s are called OptimismSuperchainERC20 and can be converted back and forth with OptimismMintableERC20 tokens.\nThe goal of the OptimismSuperchainERC20 is to extend functionalities\nof the OptimismMintableERC20 so that they are interop compatible.\nOverview\nAnyone can deploy OptimismSuperchainERC20 contracts by using the OptimismSuperchainERC20Factory.\nProxy\nThe OptimismSuperchainERC20Factory MUST be a proxied predeploy.\nIt follows the\nProxy.sol implementation\nand delegatecall() to the factory implementation address.\nBeacon Pattern\nIt MUST deploy OptimismSuperchainERC20 as\nBeaconProxies,\nas this is the easiest way to upgrade multiple contracts simultaneously.\nEach BeaconProxy delegatecalls to the implementation address provided by the Beacon Contract.\nThe implementation MUST include an initialize function that\nreceives (address _remoteToken, string _name, string _symbol, uint8 _decimals) and stores these in the BeaconProxy storage.\nDeployment history\nThe L2StandardBridge includes a convert() function that allows anyone to convert\nbetween any OptimismMintableERC20 and its corresponding OptimismSuperchainERC20.\nFor this method to work, the OptimismSuperchainERC20Factory MUST include a deployment history.\nFunctions\ndeploy\nCreates an instance of the OptimismSuperchainERC20 contract with a set of metadata defined by:\n\n_remoteToken: address of the underlying token in its native chain.\n_name: OptimismSuperchainERC20 name\n_symbol: OptimismSuperchainERC20 symbol\n_decimals: OptimismSuperchainERC20 decimals\n\nfunction deploy(address _remoteToken, string memory _name, string memory _symbol, uint8 _decimals) returns (address)\n\nIt returns the address of the deployed OptimismSuperchainERC20.\nThe function MUST use CREATE3 to deploy its children.\nThis ensures the same address deployment across different chains,\nwhich is necessary for the standard implementation.\nThe salt used for deployment MUST be computed by applying keccak256 to the abi.encode\nof the input parameters (_remoteToken, _name, _symbol, and _decimals).\nThis implies that the same L1 token can have multiple OptimismSuperchainERC20 representations as long as the metadata changes.\nThe function MUST store the _remoteToken address for each deployed OptimismSuperchainERC20 in a deployments mapping.\nEvents\nOptimismSuperchainERC20Created\nIt MUST trigger when deploy is called.\nevent OptimismSuperchainERC20Created(address indexed superchainToken, address indexed remoteToken, address deployer);\n\nwhere superchainToken is the address of the newly deployed OptimismSuperchainERC20,\nremoteToken is the address of the corresponding token in L1,\nand deployer is the msg.sender.\nDeployment Flow\n\nOptimismSuperchainERC20Beacon\nConstantValue\nAddress0x4200000000000000000000000000000000000027\n\nOverview\nThe OptimismSuperchainERC20Beacon predeploy gets called by the OptimismSuperchainERC20\nBeaconProxies deployed by the\nSuperchainERC20Factory\nThe Beacon Contract implements the interface defined\nin EIP-1967.\nThe implementation address gets deduced similarly to the GasPriceOracle address in Ecotone and Fjord updates.\nOptimismMintableERC20Factory\nConstantValue\nAddress0x4200000000000000000000000000000000000012\n\nOptimismMintableERC20\nThe OptimismMintableERC20Factory creates ERC20 contracts on L2 that can be used to deposit\nnative L1 tokens into (OptimismMintableERC20). Anyone can deploy OptimismMintableERC20 contracts.\nEach OptimismMintableERC20 contract created by the OptimismMintableERC20Factory\nallows for the L2StandardBridge to mint\nand burn tokens, depending on whether the user is\ndepositing from L1 to L2 or withdrawing from L2 to L1.\nUpdates\nThe OptimismMintableERC20Factory is updated to include a deployments mapping\nthat stores the remoteToken address for each deployed OptimismMintableERC20.\nThis is essential for the liquidity migration process defined in the liquidity migration spec.\nFunctions\ncreateOptimismMintableERC20WithDecimals\nCreates an instance of the OptimismMintableERC20 contract with a set of metadata defined by:\n\n_remoteToken: address of the underlying token in its native chain.\n_name: OptimismMintableERC20 name\n_symbol: OptimismMintableERC20 symbol\n_decimals: OptimismMintableERC20 decimals\n\ncreateOptimismMintableERC20WithDecimals(address _remoteToken, string memory _name, string memory _symbol, uint8 _decimals) returns (address)\n\nInvariants\n\nThe function MUST use CREATE2 to deploy new contracts.\nThe salt MUST be computed by applying keccak256 to the abi.encode\nof the four input parameters (_remoteToken, _name, _symbol, and _decimals).\nThis ensures a unique OptimismMintableERC20 for each set of ERC20 metadata.\nThe function MUST store the _remoteToken address for each deployed OptimismMintableERC20 in a deployments mapping.\n\ncreateOptimismMintableERC20\nCreates an instance of the OptimismMintableERC20 contract with a set of metadata defined\nby _remoteToken, _name and _symbol and fixed decimals to the standard value 18.\ncreateOptimismMintableERC20(address _remoteToken, string memory _name, string memory _symbol) returns (address)\n\ncreateStandardL2Token\nCreates an instance of the OptimismMintableERC20 contract with a set of metadata defined\nby _remoteToken, _name and _symbol and fixed decimals to the standard value 18.\ncreateStandardL2Token(address _remoteToken, string memory _name, string memory _symbol) returns (address)\n\nThis function exists for backwards compatibility with the legacy version.\nEvents\nOptimismMintableERC20Created\nIt MUST trigger when createOptimismMintableERC20WithDecimals,\ncreateOptimismMintableERC20 or createStandardL2Token is called.\nevent OptimismMintableERC20Created(address indexed localToken, address indexed remoteToken, address deployer);\n\nStandardL2TokenCreated\nIt MUST trigger when createOptimismMintableERC20WithDecimals,\ncreateOptimismMintableERC20 or createStandardL2Token is called.\nThis event exists for backward compatibility with legacy version.\nevent StandardL2TokenCreated(address indexed remoteToken, address indexed localToken);\n\nL2StandardBridge\nConstantValue\nAddress0x4200000000000000000000000000000000000010\n\nUpdates\nThe OptimismMintableERC20 and L2StandardToken tokens (legacy tokens),\nwhich correspond to locked liquidity in L1, are incompatible with interop.\nLegacy token owners must convert into a OptimismSuperchainERC20 representation that implements the standard,\nto move across the Superchain.\nThe conversion method uses the L2StandardBridge mint/burn rights\nover the legacy tokens to allow easy migration to and from the\ncorresponding OptimismSuperchainERC20.\nconvert\nThe L2StandardBridge SHOULD add a convert public function that\nconverts _amount of _from token to _amount of _to token,\nif and only if the token addresses are valid (as defined below).\nfunction convert(address _from, address _to, uint256 _amount)\n\nThe function\n\nChecks that _from and _to addresses are valid, paired and have the same amount of decimals.\nBurns _amount of _from from msg.sender.\nMints _amount of _to to msg.sender.\n\nConverted\nThe L2StandardBridge SHOULD include a Converted event\nthat MUST trigger when anyone converts tokens\nwith convert.\nevent Converted(address indexed from, address indexed to, address indexed caller, uint256 amount);\n\nwhere from is the address of the input token, to is the address of the output token,\ncaller is the msg.sender of the function call and amount is the converted amount.\nInvariants\nThe convert function conserves the following invariants:\n\nConservation of amount:\nThe burnt amount should match the minted amount.\nRevert for non valid or non paired: convert SHOULD revert when called with:\n\nTokens with different decimals.\nLegacy tokens that are not in the deployments mapping from the OptimismMintableERC20Factory.\nOptimismSuperchainERC20 that are not in the deployments mapping from the OptimismSuperchainERC20Factory.\nLegacy tokens and OptimismSuperchainERC20ss\ncorresponding to different\nremote token addresses.\n\nFreedom of conversion for valid and paired tokens:\nanyone can convert between allowed legacy representations and\nvalid OptimismSuperchainERC20 corresponding to the same remote token.\n\nConversion Flow\n\nSuperchainETHBridge\nConstantValue\nAddress0x4200000000000000000000000000000000000024\n\nSee the SuperchainETHBridge spec for the design of the SuperchainETHBridge predeploy.\nETHLiquidity\nConstantValue\nAddress0x4200000000000000000000000000000000000025\n\nSee the ETHLiquidity spec for the design of the ETHLiquidity contract.\nSuperchainTokenBridge\nConstantValue\nAddress0x4200000000000000000000000000000000000028\n\nOverview\nThe SuperchainTokenBridge is an abstraction on top of the L2toL2CrossDomainMessenger\nthat facilitates token bridging using interop.\nIt has mint and burn rights over SuperchainERC20 tokens\nas described in the token bridging spec.\nFunctions\nsendERC20\nInitializes a transfer of _amount amount of tokens with address _tokenAddress to target address _to in chain _chainId.\nIt SHOULD burn _amount tokens with address _tokenAddress and initialize a message to the\nL2ToL2CrossChainMessenger to mint the _amount of the same token\nin the target address _to at _chainId and emit the SentERC20 event including the msg.sender as parameter.\nTo burn the token, the sendERC20 function\ncalls crosschainBurn in the token contract,\nwhich is included as part of the\nIERC7802 interface\nimplemented by the SuperchainERC20 standard.\nReturns the msgHash_ crafted by the L2ToL2CrossChainMessenger.\nfunction sendERC20(address _tokenAddress, address _to, uint256 _amount, uint256 _chainId) returns (bytes32 msgHash_)\n\nrelayERC20\nProcess incoming messages IF AND ONLY IF initiated\nby the same contract (bridge) address on a different chain\nand relayed from the L2ToL2CrossChainMessenger in the local chain.\nIt SHOULD mint _amount of tokens with address _tokenAddress to address _to, as defined in sendERC20\nand emit an event including the _tokenAddress, the _from and chain id from the\nsource chain, where _from is the msg.sender of sendERC20.\nTo mint the token, the relayERC20 function\ncalls crosschainMint in the token contract,\nwhich is included as part of the\nIERC7802 interface\nimplemented by the SuperchainERC20 standard.\nfunction relayERC20(address _tokenAddress, address _from, address _to, uint256 _amount)\n\nEvents\nSentERC20\nMUST trigger when a cross-chain transfer is initiated using sendERC20.\nevent SentERC20(address indexed tokenAddress, address indexed from, address indexed to, uint256 amount, uint256 destination)\n\nRelayedERC20\nMUST trigger when a cross-chain transfer is finalized using relayERC20.\nevent RelayedERC20(address indexed tokenAddress, address indexed from, address indexed to, uint256 amount, uint256 source);\n\nDiagram\nThe following diagram depicts a cross-chain transfer.\n\nInvariants\nThe bridging of SuperchainERC20 using the SuperchainTokenBridge will require the following invariants:\n\nConservation of bridged amount: The minted amount in relayERC20() should match the amount\nthat was burnt in sendERC20(), as long as target chain has the initiating chain in the dependency set.\n\nCorollary 1: Finalized cross-chain transactions will conserve the sum of totalSupply\nand each user's balance for each chain in the Superchain.\nCorollary 2: Each initiated but not finalized message (included in initiating chain but not yet in target chain)\nwill decrease the totalSupply and the initiating user balance precisely by the burnt amount.\nCorollary 3: SuperchainERC20s should not charge a token fee or increase the balance when moving cross-chain.\nNote: if the target chain is not in the initiating chain dependency set,\nfunds will be locked, similar to sending funds to the wrong address.\nIf the target chain includes it later, these could be unlocked.\n\nFreedom of movement: Users should be able to send and receive tokens in any target\nchain with the initiating chain in its dependency set\nusing sendERC20() and relayERC20(), respectively.\nUnique Messenger: The sendERC20() function must exclusively use the L2toL2CrossDomainMessenger for messaging.\nSimilarly, the relayERC20() function should only process messages originating from the L2toL2CrossDomainMessenger.\nUnique Address: The sendERC20() function must exclusively send a message\nto the same address on the target chain.\nSimilarly, the relayERC20() function should only process messages originating from the same address.\n\nNote: The Create2Deployer preinstall\nand the custom Factory will ensure same address deployment.\n\nLocally initiated: The bridging action should be initialized\nfrom the chain where funds are located only.\n\nThis is because the same address might correspond to different users cross-chain.\nFor example, two SAFEs with the same address in two chains might have different owners.\nWith the prospects of a smart wallet future, it is impossible to assume\nthere will be a way to distinguish EOAs from smart wallets.\nA way to allow for remotely initiated bridging is to include remote approval,\ni.e. approve a certain address in a certain chainId to spend local funds.\n\nBridge Events:\n\nsendERC20() should emit a SentERC20 event.\nrelayERC20() should emit a RelayedERC20 event.","tokens":7261,"squid":"ink-governance","role":"Council Listener","at":1791264309993,"hash":"39836d9b09895cad6782c204873b32c0837d6db9"}
{"url":"https://dev-forum.pyth.network/t/hermes-client-invalid-response/461/5","domain":"dev-forum.pyth.network","title":"Hermes Client - Invalid response - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Nov 2025\n\n 5 / 5\n\n Nov 2025\n\n Nov 2025\n\n post by KemarTiti on Nov 6, 2025\n\n KemarTiti\n\n Hey,\nWe are currently using @pythnetwork/hermes-client and getLatestPriceUpdates function to retrieve Pyth price feeds in batch mode.\nHowever, the current implementation causes an issue: if even a single feedId is invalid or fails to resolve, the entire batch request fails.\n\nIs there a reliable way to pre-validate whether a given feedId is valid/exists before including it in a batch request?\nIf possible, could you provide (or point us to) an alternative batch retrieval method that supports partial success — i.e., returns prices for all valid feedIds while gracefully handling errors for invalid or unavailable ones without rejecting the whole batch?\n\n 3\n\n 2\n\n post by ali on Nov 6, 2025\n\n ali\n\n We have an ignoreInvalidPriceIds option in the requests that lets you get the feeds partially. See here for more info.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n Thanks!\nEvery 15 seconds, we call your SDK to fetch the latest prices; we batch 20 tokens in each call.\nAs of now, we see that more than 40% of the API calls take more than 2 seconds, and occasionally it will reach a 5-second timeout. Is it expected?\n\n post by ali on Nov 7, 2025\n\n ali\n\n From which location are you hitting Hermes endpoints? We generally recommend using a private Hermes RPC for production usecases.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n We call it from Singapore\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 317\n\n Nov 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Powered by Discourse","tokens":1430,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264313860,"hash":"1481122c475041659ec29fc378f46f658b3d1d35"}
{"url":"https://specs.optimism.io/interop/tx-pool.html","domain":"specs.optimism.io","title":"Transaction Pool - OP Stack Specification","text":"Transaction pool\n\nTable of Contents\n\nOverview\nTransaction validation\nSystem deposits transaction margin\nSecurity Considerations\n\nMempool Denial of Service\n\nOverview\nThe transaction pool (also known as the mempool) is where pending user transactions accumulate\nbefore being included in a block. When a user submits a transaction to a node, it is validated\nand inserted into the node's transaction pool before being broadcasted via p2p network to other nodes.\nSince there is little cost to sending invalid transactions over the p2p network maliciously,\nEthereum opts to ensure that the transactions can be validated as cheaply as possible. This validation\nconsists of a nonce and balance (fee payment) check, which can be done with solely state lookups and\nthe chain tips block header. Features that make this validation more costly have been rejected from L1\nEthereum due to the desire to ensure commodity hardware can\neasily participate in consensus.\nLayer twos can make more aggressive trade-offs and raise the minimum hardware requirements of the network.\nHowever, with interop, full EVM execution of the transaction is required to fully validate it.\nTransaction validation\nIn addition to the nonce and balance checks, the messaging invariants\nSHOULD be enforced before entry into the transaction pool.\nAfter each new block, each transaction in the transaction pool is checked for validity again.\nA transaction with a definitively invalid message-dependency SHOULD be \"demoted\" from the transaction pool.\nIt is possible that a transaction deemed valid becomes invalid or vice versa. The sequencer MAY choose\nto demote messages which are invalid but can still technically become valid.\nTransactions with invalid message-dependencies MUST NOT be included in block-building,\nand should thus be dropped from the transaction-pool.\nSystem deposits transaction margin\nThe transaction-pool should filter out L2 transactions that spend more than the\ngas limit, minus the gas spent on system transactions.\nThis ensures that the transaction can be included in a valid L2 block,\nand does not get stuck in the transaction pool.\nA notion of an \"effective gas limit\", that subtracts 100,000 gas from the regular gas limit,\nshould be maintained in the transaction pool.\nThis leaves sufficient gas for the L1 attributes transaction (under 45,000 gas),\nthe new deposit-context closing transaction (under 36,000 gas), and margin for error / change.\nSecurity Considerations\nMempool Denial of Service\nSince the validation of the executing message relies on a remote RPC request, this introduces a denial of\nservice attack vector. The cost of network access is magnitudes larger than in memory validity checks.\nThe mempool SHOULD perform low-cost checks before any sort of network access is performed.\nThe results of the check SHOULD be cached, such that another request does not need to be performed\nwhen building the block, although consistency is not guaranteed.","tokens":736,"squid":"ink-governance","role":"Council Listener","at":1791264319845,"hash":"a9ee71af4c6533ce5ac2345b032441e651e76b09"}
{"url":"https://dev-forum.pyth.network/t/failed-to-get-realtime-price-feed-may-be-related-to-cloudflare/468/1","domain":"dev-forum.pyth.network","title":"Failed to get realtime price feed (may be related to cloudflare) - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Failed to get realtime price feed (may be related to cloudflare) \n\n Price FeedsBenchmarks(Historic Prices)\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2025\n\n 1 / 3\n\n Nov 2025\n\n Nov 2025\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n Hello, I’m currently using hermes.pyth.network/v2/updates/price/stream to get price, but currently I can’t connect to the stream. Is it caused by cloudflare? Is there any method I can use to get realtime price?\n\n 2\n\n post by KemarTiti on Nov 18, 2025\n\n KemarTiti\n\n Hey,\nThere are indeed some issues on the public Hermes endpoint caused by Cloudflare.\nShould be resolved soon but I’d really suggest to get a dedicated / private endpoint from any of these providers: https://docs.pyth.network/price-feeds/core/api-instances-and-providers/hermes#node-providers\nMost run Hermes on bare metal and have not experienced any issue today.\nIf you want me to connect you to one, please send me a dm here with your telegram id or email.\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n really thanks! but how to dm you?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error running Hermes client\n\n Price Feeds\n\n 1\n\n 495\n\n Jun 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 397\n\n Nov 2025\n\n Powered by Discourse","tokens":1261,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264323864,"hash":"62ef8b38ec1e268cc83595f3f2d706f7709cd186"}
{"url":"https://specs.optimism.io/experimental/standard-l2-genesis.html","domain":"specs.optimism.io","title":"Standard L2 Genesis - OP Stack Specification","text":"Standard L2 Genesis\n\nTable of Contents\n\nOverview\nChain Constants on L1\n\nConfigType\n\nSystemConfig\n\nConfigUpdate\nInitialization\nInterface\n\nFee Vault Config\n\nsetBaseFeeVaultConfig\nsetL1FeeVaultConfig\nsetSequencerFeeVaultConfig\n\nOptimismPortal\n\nInterface\n\nsetConfig\nupgrade\n\nSuperchainConfig\n\nSuperchainConfig Constants\nInterface\nInitialization\n\nDeterministic genesis state\nChain Constants on L2\nPredeploys\n\nProxyAdmin\n\nRationale\n\nL1Block\n\nStorage\nInterface\n\nsetIsthmus\nsetConfig\ngetConfig\n\nFeeVault\n\nInterface\n\nconfig\n\nL2CrossDomainMessenger\n\nInterface\n\nL2ERC721Bridge\n\nInterface\n\nL2StandardBridge\n\nInterface\n\nOptimismMintableERC721Factory\n\nSecurity Considerations\n\nGovernanceToken\n\nOverview\nThe SystemConfig and OptimismPortal are updated with a new flow for chain\nconfigurability.\nChain Constants on L1\nConfigType\nThe ConfigType enum represents configuration that can be modified.\nNameValueDescription\nGAS_PAYING_TOKENuint8(0)Modifies the gas paying token for the chain\nBASE_FEE_VAULT_CONFIGuint8(1)Sets the Fee Vault Config for the BaseFeeVault\nL1_FEE_VAULT_CONFIGuint8(2)Sets the Fee Vault Config for the L1FeeVault\nSEQUENCER_FEE_VAULT_CONFIGuint8(3)Sets the Fee Vault Config for the SequencerFeeVault\nL1_CROSS_DOMAIN_MESSENGER_ADDRESSuint8(4)Sets the L1CrossDomainMessenger address\nL1_ERC_721_BRIDGE_ADDRESSuint8(5)Sets the L1ERC721Bridge address\nL1_STANDARD_BRIDGE_ADDRESSuint8(6)Sets the L1StandardBridge address\nREMOTE_CHAIN_IDuint8(7)Sets the chain id of the base chain\n\nSystemConfig\nConfigUpdate\nThe following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0):\nNameValueDefinitionUsage\nBATCHERuint8(0)abi.encode(address)Modifies the account that is authorized to progress the safe chain\nFEE_SCALARSuint8(1)(uint256(0x01) << 248) | (uint256(_blobbasefeeScalar) << 32) | _basefeeScalarModifies the fee scalars\nGAS_LIMITuint8(2)abi.encode(uint64 _gasLimit)Modifies the L2 gas limit\nUNSAFE_BLOCK_SIGNERuint8(3)abi.encode(address)Modifies the account that is authorized to progress the unsafe chain\nEIP_1559_PARAMSuint8(4)uint256(uint64(uint32(_denominator))) << 32 | uint64(uint32(_elasticity))Modifies the EIP-1559 denominator and elasticity\n\nInitialization\nThe following actions should happen during the initialization of the SystemConfig:\n\nemit ConfigUpdate.BATCHER\nemit ConfigUpdate.FEE_SCALARS\nemit ConfigUpdate.GAS_LIMIT\nemit ConfigUpdate.UNSAFE_BLOCK_SIGNER\nemit ConfigUpdate.EIP_1559_PARAMS\nsetConfig(SET_GAS_PAYING_TOKEN)\nsetConfig(SET_BASE_FEE_VAULT_CONFIG)\nsetConfig(SET_L1_FEE_VAULT_CONFIG)\nsetConfig(SET_SEQUENCER_FEE_VAULT_CONFIG)\nsetConfig(SET_L1_CROSS_DOMAIN_MESSENGER_ADDRESS)\nsetConfig(SET_L1_ERC_721_BRIDGE_ADDRESS)\nsetConfig(SET_L1_STANDARD_BRIDGE_ADDRESS)\nsetConfig(SET_REMOTE_CHAIN_ID)\n\nThese actions MAY only be triggered if there is a diff to the value.\nInterface\nFee Vault Config\nFor each FeeVault, there is a setter for its config. The arguments to the setter include\nthe RECIPIENT, the MIN_WITHDRAWAL_AMOUNT and the WithdrawalNetwork.\nEach of these functions should be public and only callable by the chain governor.\nEach function calls OptimismPortal.setConfig(ConfigType,bytes) with its corresponding ConfigType.\nsetBaseFeeVaultConfig\nfunction setBaseFeeVaultConfig(address,uint256,WithdrawalNetwork)\n\nsetL1FeeVaultConfig\nfunction setL1FeeVaultConfig(address,uint256,WithdrawalNetwork)\n\nsetSequencerFeeVaultConfig\nfunction setSequencerFeeVaultConfig(address,uint256,WithdrawalNetwork)\n\nOptimismPortal\nThe OptimismPortal is updated to emit a special system TransactionDeposited event.\nInterface\nsetConfig\nThe setConfig function MUST only be callable by the SystemConfig. This ensures that the SystemConfig\nis the single source of truth for chain operator ownership.\nfunction setConfig(ConfigType,bytes)\n\nThis function emits a TransactionDeposited event.\nevent TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData);\n\nThe following fields are included:\n\nfrom is the DEPOSITOR_ACCOUNT\nto is Predeploys.L1Block\nversion is uint256(0)\nopaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit\nis 200_000, isCreation is false and the data is abi.encodeCall(L1Block.setConfig, (_type, _value))\n\nupgrade\nThe upgrade function MUST only be callable by the UPGRADER role as defined\nin the SuperchainConfig.\nfunction upgrade(bytes memory _data) external\n\nThis function emits a TransactionDeposited event.\nevent TransactionDeposited(address indexed from, address indexed to, uint256 indexed version, bytes opaqueData);\n\nThe following fields are included:\n\nfrom is the DEPOSITOR_ACCOUNT\nto is Predeploys.ProxyAdmin\nversion is uint256(0)\nopaqueData is the tightly packed transaction data where mint is 0, value is 0, the gasLimit\nis 200_000, isCreation is false and the data is the data passed into upgrade.\n\nSuperchainConfig\nThe SuperchainConfig contract is updated with a new role that has the ability\nto issue deposit transactions from the identity of the DEPOSITOR_ACCOUNT\nthat call the L2 ProxyAdmin.\nSuperchainConfig Constants\nNameValueDefinition\nUPGRADER_SLOTbytes32(uint256(keccak256(\"superchainConfig.upgrader\")) - 1)Account that can call the L2 ProxyAdmin\n\nInterface\nfunction upgrader() public view returns (address)\n\nInitialization\nThe upgrader can only be set during initialization.\nDeterministic genesis state\nThis upgrade enables a deterministic L2 genesis state by moving all network\nspecific configuration out of the initial L2 genesis state. All network specific\nconfiguration is sourced from deposit transactions during the initialization\nof the SystemConfig.\nChain Constants on L2\nNameValueDefinition\nConfigTypeuint8An enum representing the type of config being set\nWithdrawalNetworkuint8(0) or uint8(1)0 means withdraw to L1, 1 means withdraw to L2\nRECIPIENTaddressThe account that will receive funds sent out of the FeeVault\nMIN_WITHDRAWAL_AMOUNTuint256The minimum amount of native asset held in the FeeVault before withdrawal is authorized\nFee Vault Configbytes32bytes32((WithdrawalNetwork << 248) || uint256(uint88(MIN_WITHDRAWAL_AMOUNT)) || uint256(uint160(RECIPIENT)))\nBASE_FEE_VAULT_CONFIGbytes32(uint256(keccak256(\"opstack.basefeevaultconfig\")) - 1)The Fee Vault Config for the BaseFeeVault\nL1_FEE_VAULT_CONFIGbytes32(uint256(keccak256(\"opstack.l1feevaultconfig\")) - 1)The Fee Vault Config for the L1FeeVault\nSEQUENCER_FEE_VAULT_CONFIGbytes32(uint256(keccak256(\"opstack.sequencerfeevaultconfig\")) - 1)The Fee Vault Config for the SequencerFeeVault\nL1_CROSS_DOMAIN_MESSENGER_ADDRESSbytes32(uint256(keccak256(\"opstack.l1crossdomainmessengeraddress\")) - 1)abi.encode(address(L1CrossDomainMessengerProxy))\nL1_ERC_721_BRIDGE_ADDRESSbytes32(uint256(keccak256(\"opstack.l1erc721bridgeaddress\")) - 1)abi.encode(address(L1ERC721BridgeProxy))\nL1_STANDARD_BRIDGE_ADDRESSbytes32(uint256(keccak256(\"opstack.l1standardbridgeaddress\")) - 1)abi.encode(address(L1StandardBridgeProxy))\nREMOTE_CHAIN_IDbytes32(uint256(keccak256(\"opstack.remotechainid\")) - 1)Chain ID of the remote chain\n\nPredeploys\nAll network specific configuration is moved to a single contract, the L1Block predeploy.\nAll predeploys make calls to the L1Block contract to fetch network specific configuration\nrather than reading it from local state.\n\nProxyAdmin\nThe ProxyAdmin is updated to have its owner be the DEPOSITOR_ACCOUNT.\nThis means that it can be deterministically called by network upgrade transactions\nor by special deposit transactions emitted by the OptimismPortal that assume\nthe identity of the DEPOSITOR_ACCOUNT.\nRationale\nIt is much easier to manage the overall roles of the full system under this model.\nThe owner of the ProxyAdmin can upgrade any of the predeploys, meaning it can\nwrite storage slots that correspond to withdrawals. This ensures that only the\nsystem or a chain governor can issue upgrades to the predeploys.\nL1Block\nStorage\nThe following storage slots are defined:\n\nBASE_FEE_VAULT_CONFIG\nL1_FEE_VAULT_CONFIG\nSEQUENCER_FEE_VAULT_CONFIG\nL1_CROSS_DOMAIN_MESSENGER_ADDRESS\nL1_ERC_721_BRIDGE_ADDRESS\nL1_STANDARD_BRIDGE_ADDRESS\nREMOTE_CHAIN_ID\n\nEach slot MUST have a defined ConfigType that authorizes the setting of the storage slot\nvia a deposit transaction from the DEPOSITOR_ACCOUNT.\nInterface\nsetIsthmus\nThis function is meant to be called once on the activation block of the holocene network upgrade.\nIt MUST only be callable by the DEPOSITOR_ACCOUNT once. When it is called, it MUST call\ncall each getter for the network specific config and set the returndata into storage.\nsetConfig\nThis function MUST only be callable by the DEPOSITOR_ACCOUNT. It modifies the storage directly\nof the L1Block contract. It MUST handle all defined ConfigTypes. To ensure a simple ABI, the\nbytes value MUST be abi decoded based on the ConfigType.\nfunction setConfig(ConfigType,bytes)\n\nNote that ConfigType is an enum which is an alias for a uint8.\ngetConfig\nThis function is called by each contract with the appropriate ConfigType to fetch\nthe network specific configuration. Using this pattern reduces the ABI of the L1Block\ncontract by removing the need for special getters for each piece of config.\nfunction getConfig(ConfigType)(bytes)\n\nThe caller needs to ABI decode the data into the desired type.\nFeeVault\nThe following changes apply to each of the BaseFeeVault, the L1FeeVault and the SequencerFeeVault.\nInterface\nThe following functions are updated to read from the L1Block contract:\n\nrecipient()(address)\nwithdrawalNetwork()(WithdrawalNetwork)\nminWithdrawalAmount()(uint256)\nwithdraw()\n\nNameCall\nBaseFeeVaultL1Block.getConfig(ConfigType.BASE_FEE_VAULT_CONFIG)\nSequencerFeeVaultL1Block.getConfig(ConfigType.SEQUENCER_FEE_VAULT_CONFIG)\nL1FeeVaultL1Block.getConfig(ConfigType.L1_FEE_VAULT_CONFIG)\n\nconfig\nA new function is added to fetch the full Fee Vault Config.\nfunction config()(address,uint256,WithdrawalNetwork)\n\nL2CrossDomainMessenger\nInterface\nThe following functions are updated to read from the L1Block contract by calling L1Block.getConfig(ConfigType.L1_CROSS_DOMAIN_MESSENGER_ADDRESS):\n\notherMessenger()(address)\nOTHER_MESSENGER()(address)\n\nL2ERC721Bridge\nInterface\nThe following functions are updated to read from the L1Block contract by calling L1Block.getConfig(ConfigType.L1_ERC721_BRIDGE_ADDRESS):\n\notherBridge()(address)\nOTHER_BRIDGE()(address)\n\nL2StandardBridge\nInterface\nThe following functions are updated to read from the L1Block contract by calling L1Block.getConfig(ConfigType.L1_STANDARD_BRIDGE_ADDRESS):\n\notherBridge()(address)\nOTHER_BRIDGE()(address)\n\nOptimismMintableERC721Factory\nThe chain id is no longer read from storage but instead is read from the L1Block contract by calling\nL1Block.getConfig(ConfigType.REMOTE_CHAIN_ID)\nSecurity Considerations\nGovernanceToken\nThe predeploy defined by GovernanceToken should be an empty account until it is defined by\na future hardfork.","tokens":2707,"squid":"ink-governance","role":"Council Listener","at":1791264329788,"hash":"13b513f9eaba3df030c9267e2919534f065c06bd"}
{"url":"https://dev-forum.pyth.network/t/failed-to-get-realtime-price-feed-may-be-related-to-cloudflare/468/3","domain":"dev-forum.pyth.network","title":"Failed to get realtime price feed (may be related to cloudflare) - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2025\n\n 3 / 3\n\n Nov 2025\n\n Nov 2025\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n Hello, I’m currently using hermes.pyth.network/v2/updates/price/stream to get price, but currently I can’t connect to the stream. Is it caused by cloudflare? Is there any method I can use to get realtime price?\n\n 2\n\n post by KemarTiti on Nov 18, 2025\n\n KemarTiti\n\n Hey,\nThere are indeed some issues on the public Hermes endpoint caused by Cloudflare.\nShould be resolved soon but I’d really suggest to get a dedicated / private endpoint from any of these providers: https://docs.pyth.network/price-feeds/core/api-instances-and-providers/hermes#node-providers\nMost run Hermes on bare metal and have not experienced any issue today.\nIf you want me to connect you to one, please send me a dm here with your telegram id or email.\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n really thanks! but how to dm you?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error running Hermes client\n\n Price Feeds\n\n 1\n\n 495\n\n Jun 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 397\n\n Nov 2025\n\n Powered by Discourse","tokens":1244,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264333847,"hash":"dbc9cf3b9022868cfb3011f423a45f416e7b755b"}
{"url":"https://specs.optimism.io/interop/messaging.html","domain":"specs.optimism.io","title":"Messaging - OP Stack Specification","text":"Messaging\n\nTable of Contents\n\nMessage\n\nMessage payload\nMessage Identifier\n\nMessaging ends\n\nInitiating Messages\nExecuting Messages\n\nMessaging Invariants\n\nTimestamp Invariant\nChainID Invariant\nMessage Expiry Invariant\n\nMessage Graph\n\nInvalid messages\n\nBlock reorgs\nBlock Recommits\n\nIntra-block messaging: cycles\nResolving cross-chain safety\nHorizon timestamp\nPruning the graph\nBounding the graph\n\nSecurity Considerations\n\nCyclic dependencies\nTransitive dependencies\n\nMessage\nA message is a broadcast payload emitted from an identified source.\nMessage payload\nOpaque bytes that represent a Log.\nIt is serialized by first concatenating the topics and then with the data.\nmsg := make([]byte, 0)\nfor _, topic := range log.Topics {\n msg = append(msg, topic.Bytes()...)\n}\nmsg = append(msg, log.Data...)\n\nThe _msg can easily be decoded into a Solidity struct with abi.decode since each topic is always 32 bytes and\nthe data generally ABI encoded.\nMessage Identifier\nThe Identifier that uniquely represents a log that is emitted from a chain. It can be considered to be a\nunique pointer to a particular log. The derivation pipeline and fault proof program MUST ensure that the\n_msg corresponds exactly to the log that the Identifier points to.\nstruct Identifier {\n address origin;\n uint256 blocknumber;\n uint256 logIndex;\n uint256 timestamp;\n uint256 chainid;\n}\n\nNameTypeDescription\noriginaddressAccount that emits the log\nblocknumberuint256Block number in which the log was emitted\nlogIndexuint256The index of the log in the array of all logs emitted in the block\ntimestampuint256The timestamp that the log was emitted. Used to enforce the timestamp invariant\nchainiduint256The chain id of the chain that emitted the log\n\nThe Identifier includes the set of information to uniquely identify a log. When using an absolute\nlog index within a particular block, it makes ahead of time coordination more complex. Ideally there\nis a better way to uniquely identify a log that does not add ordering constraints when building\na block. This would make building atomic cross chain messages more simple by not coupling the\nexact state of the block templates between multiple chains together.\nMessaging ends\nInitiating Messages\nEach Log (also known as event in solidity) forms an initiating message,\nwith the raw log data coming from the Message Payload.\nMessages are broadcast: the protocol does not enshrine address-targeting within messages.\nThe initiating message is uniquely identifiable with an Identifier,\nsuch that it can be distinguished from other duplicate messages within the same transaction or block.\nAn initiating message may be executed many times: no replay-protection is enshrined in the protocol.\nExecuting Messages\nAn executing message is represented by the ExecutingMessage event that is emitted by\nthe CrossL2Inbox predeploy. Contracts can introduce their own public\nentrypoints and solely trigger validation of the cross chain message with validateMessage.\nThe L2toL2CrossDomainMessenger is the recommended entrypoint\nfor cross chain messaging, rather than a custom message-executor contract.\nAll of the information required to satisfy the invariants MUST be included in this event.\nBoth the block builder and the verifier use this information to ensure that all system invariants are held.\nThe executing message is verified by checking if there is an existing initiating-message\nthat originates at Identifier with matching Message Payload.\nSince an executing message is defined by a log, it means that reverting calls to the CrossL2Inbox\ndo not count as executing messages.\nMessaging Invariants\n\nTimestamp Invariant: The timestamp at the time of inclusion of the initiating message MUST\nbe less than or equal to the timestamp of the executing message as well as greater than the Lagoon activation timestamp.\nChainID Invariant: The chain id of the initiating message MUST be in the dependency set\nMessage Expiry Invariant: The timestamp at the time of inclusion of the executing\nmessage MUST be lower than or equal to the initiating message timestamp\n(as defined in the Identifier) + EXPIRY_TIME.\n\nTimestamp Invariant\nThe timestamp invariant ensures that initiating messages have a timestamp greater than the Lagoon activation timestamp\nand cannot come from a future block than the block of its executing message.\nThis means that messages can only be initiated in blocks that come after the activation block.\nContract log events in the activation block are not valid initiating messages.\nThis same activation block only includes deposit-type transactions\n(from the system, and possibly from L1): this block can thus not include executing messages,\neven if only executing the initiating messages of previously Interop-activated chains.\nNote that since all transactions in a block have the same timestamp, it is possible for an executing transaction\nto be ordered before the initiating message in the same block.\nHowever, cyclic message dependencies are not allowed and\nthis is verified with rules complementary to the timestamp invariant.\nChainID Invariant\nWithout a guarantee on the set of dependencies of a chain, it may be impossible for the derivation\npipeline to know which chain to source the initiating message from. This also allows for chain operators\nto explicitly define the set of chains that they depend on.\nMessage Expiry Invariant\nMessage expiry sets a strict bound on the total messaging activity the protocol must support,\nat the cost of limiting some use-cases.\nThe expiry invariant invalidates inclusion of any executing message with\nid.timestamp + EXPIRY_TIME < executing_block.timestamp where:\n\nid is the Identifier encoded in the executing message, matching the block attributes of the initiating message.\nexecuting_block is the block where the executing message was included in.\nEXPIRY_TIME = 7 * 24 * 60 * 60 = 604800 seconds, i.e. 7 days.\n\nMessage Graph\nThe dependencies of messages can be modeled as a directed graph:\n\nvertex: a block\nedge: a dependency:\n\nparent-block (source) to block (target)\nmessage relay, from initiation (source) to execution (target)\n\nIf the source of an edge is invalidated, the target is invalidated.\nInvalid messages\nA message is said to be \"invalid\" when the executing message does not have a valid dependency.\nDependencies are invalid when:\n\nThe dependency is unknown.\nThe dependency is known but not part of the canonical chain.\nThe dependency is known but does not match all message attributes (Identifier and payload).\n\nBlock reorgs\nThe Identifier used by an executing message does not cryptographically\ncommit to the block it may reference.\nMessages may be executed before the block that initiates them is sealed.\nWhen tracking message dependencies, edges are maintained for all identified source blocks.\nReorgs are resolved by filtering the view of the solver to only canonical blocks.\nIf the source block is not canonical, the dependency is invalid.\nThe canonical L2 block at the identified block-height is the source of truth.\nBlock Recommits\nBlocks may be partially built, or sealed but not published, and then rebuilt.\nAny optimistically assumed messages have to be revalidated,\nand the original partial block can be removed from the dependency graph.\nIntra-block messaging: cycles\nWhile messages cannot be initiated by future blocks,\nthey can be initiated by any transactions within the same timestamp,\nas per the Timestamp Invariant.\nThis property allows messages to form cycles in the graph:\nblocks with equal timestamp, of chains in the same dependency set,\nmay have dependencies on one another.\nResolving cross-chain safety\nTo determine cross-chain safety, the graph is inspected for valid graph components that have no invalid dependencies,\nwhile applying the respective safety-view on the blocks in the graph.\nI.e., the graph must not have any inward edges towards invalid blocks within the safety-view.\nA safety-view is the subset of canonical blocks of all chains with the specified safety label or a higher safety label.\nDependencies on blocks outside of the safety-view are invalid,\nbut may turn valid once the safety-view changes (e.g. a reorg of unsafe blocks).\nBy resolving in terms of graph-components, cyclic dependencies and transitive dependencies are addressed.\nHorizon timestamp\nThe maximum seen timestamp in the graph is the horizon_timestamp.\nThe verifier can defer growth of the graph past this horizon_timestamp,\nuntil the graph has been resolved and pruned.\nPruning the graph\nEdges between blocks can be de-duplicated, when the blocks are complete and sealed.\nThe same initiating or executing messages, but attached to different blocks,\nmay have to be added back to the graph if the set of blocks changes.\nBlocks with cross-chain safety in the finalized-blocks safety-view can be optimized:\noutward edges for initiating messages may be attached\nwhen relevant to resolution of newer lower-safety blocks.\nNo inward edges are required anymore however, as the maximum safety has been ensured.\nBlocks older than horizon_timestamp - (2 * EXPIRY_TIME) cannot be depended\non from any valid block within the graph, and can thus be safely pruned entirely.\nBounding the graph\nWith many events, and transitive dependencies, resolving the cross-chain safety may be an intensive task for a verifier.\nIt is thus important for the graph to be reasonably bounded, such that it can be resolved.\nThe graph is bounded in 4 ways:\n\nEvery block can only depend on blocks of chains in the dependency set,\nas per the ChainID invariant.\nEvery block cannot depend on future blocks, as per the Timestamp invariant.\nEvery block has a maximum gas limit, an intrinsic cost per transaction,\nand thus a maximum inward degree of dependencies.\nEvery block cannot depend on expired messages, as per the Message expiry invariant.\n\nThe verifier is responsible for filtering out non-canonical parts of the graph.\nSecurity Considerations\nCyclic dependencies\nIf there is a cycle in the dependency set, chains MUST still be able to promote unsafe blocks\nto safe blocks. A cycle in the dependency set happens anytime that two chains are in each other's\ndependency set. This means that they are able to send cross chain messages to each other.\nTransitive dependencies\nThe safety of a chain is only ensured when the inputs are safe:\ndependencies are thus said to be transitive.\nWithout validating the transitive dependencies,\nthe verifier relies on the verification work of the nodes that it sources its direct dependencies from.","tokens":2618,"squid":"ink-governance","role":"Council Listener","at":1791264339709,"hash":"b1157dfb5c319f813876b0c083c78f2c726c02a0"}
{"url":"https://dev-forum.pyth.network/t/error-running-hermes-client/212","domain":"dev-forum.pyth.network","title":"Error running Hermes client - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Error running Hermes client \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 1 / 2\n\n Jun 2025\n\n Jun 2025\n\n post by Aditya520 on Jun 12, 2025\n\n Aditya520\n\n Posting for a user who wants to run hermes.\nHere are the parameters.\nspy --env mainnet --nodeKey /node.key --spyRPC \"[::]:7073\" --env mainnet --ethRPC \"<RPC URL for Ethereum>\" --ethContract 0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B --logLevel warn\nhermes run --rpc-listen-addr \"[::]:33999\" --pythnet-http-addr https://pythnet.rpcpool.com/ --pythnet-ws-addr wss://pythnet.rpcpool.com/ --wormhole-spy-rpc-addr http://<wormhole spy>:7073/\n\nThey are not seeting any feeds in /v2/price_feeds nor any feed working.\n\n post by ali on Jun 12, 2025\n\n ali\n\n Please try again running with this RPC https://api2.pythnet.pyth.network. If it doesn’t work out, please run it with RUST_LOG=info environment variable and share a dump of the logs along with the output of the /ready endpoint.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Hermes configuration\n\n Price Feeds\n\n 3\n\n 753\n\n Jun 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Powered by Discourse","tokens":1285,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264344218,"hash":"57ce05df721a072b2239d5b8a6058e2f4ea14077"}
{"url":"https://ethereum.org/developers/docs/consensus-mechanisms/","domain":"ethereum.org","title":"Consensus mechanisms | ethereum.org","text":"Consensus mechanismsEdit page (opens in a new tab)The term 'consensus mechanism' is often used colloquially to refer to 'proof-of-stake', 'proof-of-work' or 'proof-of-authority' protocols. However, these are just components in consensus mechanisms that protect against . Consensus mechanisms are the complete stack of ideas, protocols and incentives that enable a distributed set of nodes to agree on the state of a blockchain.\nPrerequisites\nTo better understand this page, we recommend you first read our introduction to Ethereum.\nWhat is consensus?\nBy consensus, we mean that a general agreement has been reached. Consider a group of people going to the cinema. If there is no disagreement on a proposed choice of film, then a consensus is achieved. If there is disagreement, the group must have the means to decide which film to see. In extreme cases, the group will eventually split.\nIn regard to the Ethereum blockchain, the process is formalized, and reaching consensus means that at least 66% of the nodes on the network agree on the global state of the network.\nWhat is a consensus mechanism?\nThe term consensus mechanism refers to the entire stack of protocols, incentives and ideas that allow a network of nodes to agree on the state of a blockchain.\nEthereum uses a proof-of-stake-based consensus mechanism that derives its crypto-economic security from a set of rewards and penalties applied to capital locked by stakers. This incentive structure encourages individual stakers to operate honest validators, punishes those who don't, and creates an extremely high cost to attack the network.\nThen, there is a protocol that governs how honest validators are selected to propose or validate blocks, process transactions and vote for their view of the head of the chain. In the rare situations where multiple blocks are in the same position near the head of the chain, there is a fork-choice mechanism that selects blocks that make up the 'heaviest' chain, measured by the number of validators that voted for the blocks weighted by their staked ether balance.\nSome concepts are important to consensus that are not explicitly defined in code, such as the additional security offered by potential out-of-band social coordination as a last line of defense against attacks on the network.\nThese components together form the consensus mechanism.\nTypes of consensus mechanisms\nProof-of-work based\nLike Bitcoin, Ethereum once used a proof-of-work (PoW) based consensus protocol.\nBlock creation\nMiners compete to create new blocks filled with processed transactions. The winner shares the new block with the rest of the network and earns some freshly minted ETH. The race is won by the computer which is able to solve a math puzzle fastest. This produces the cryptographic link between the current block and the block that went before. Solving this puzzle is the work in \"proof-of-work\". The canonical chain is then determined by a fork-choice rule that selects the set of blocks that have had the most work done to mine them.\nSecurity\nThe network is kept secure by the fact that you'd need 51% of the network's computing power to defraud the chain. This would require such huge investments in equipment and energy; you're likely to spend more than you'd gain.\nMore on proof-of-work\nProof-of-stake based\nEthereum now uses a proof-of-stake (PoS) based consensus protocol.\nBlock creation\nValidators create blocks. One validator is randomly selected in each slot to be the block proposer. Their consensus client requests a bundle of transactions as an 'execution payload' from their paired execution client. They wrap this in consensus data to form a block, which they send to other nodes on the Ethereum network. This block production is rewarded in ETH. In rare cases when multiple possible blocks exist for a single slot, or nodes hear about blocks at different times, the fork choice algorithm picks the block that forms the chain with the greatest weight of attestations (where weight is the number of validators attesting scaled by their ETH balance).\nSecurity\nA proof-of-stake system is secure crypto-economically because an attacker attempting to take control of the chain must destroy a massive amount of ETH. A system of rewards incentivizes individual stakers to behave honestly, and penalties disincentivize stakers from acting maliciously.\nMore on proof-of-stake\nA visual guide\nWatch more on the different types of consensus mechanisms used on Ethereum:\nUnderstanding blockchain consensus mechanismsAn explainer covering the core consensus mechanisms used in blockchains, and how they enable decentralized networks to agree on the state of transactions without a central authority.Watch with transcript \nSybil resistance & chain selection\nProof-of-work and proof-of-stake alone are not consensus protocols, but they are often referred to as such for simplicity. They are actually Sybil resistance mechanisms and block author selectors; they are a way to decide who is the author of the latest block. Another important component is the chain selection (aka fork choice) algorithm that enables nodes to pick one single correct block at the head of the chain in scenarios where multiple blocks exist in the same position.\nSybil resistance measures how a protocol fares against a Sybil attack. Resistance to this type of attack is essential for a decentralized blockchain and enables miners and validators to be rewarded equally based on resources put in. Proof-of-work and proof-of-stake protect against this by making users expend a lot of energy or put up a lot of collateral. These protections are an economic deterrent to Sybil attacks.\nA chain selection rule is used to decide which chain is the \"correct\" chain. Bitcoin uses the \"longest chain\" rule, which means that whichever blockchain is the longest will be the one the rest of the nodes accept as valid and work with. For proof-of-work chains, the longest chain is determined by the chain's total cumulative proof-of-work difficulty. Ethereum used to use the longest chain rule too; however, now that Ethereum runs on proof-of-stake it adopted an updated fork-choice algorithm that measures the 'weight' of the chain. The weight is the accumulated sum of validator votes, weighted by validator staked-ether balances.\nEthereum uses a consensus mechanism known as Gasper that combines Casper FFG proof-of-stake (opens in a new tab) with the GHOST fork-choice rule (opens in a new tab).\nFurther reading\n\nWhat Is a Blockchain Consensus Algorithm? (opens in a new tab)\nWhat is Nakamoto Consensus? Complete Beginner’s Guide (opens in a new tab)\nHow Does Casper work? (opens in a new tab)\nOn the Security and Performance of Proof of Work Blockchains (opens in a new tab)\nByzantine fault (opens in a new tab)\n\nKnow of a community resource that helped you? Edit this page and add it!\nRelated topics\n\nProof-of-work\nMining\nProof-of-stake\nProof-of-authority","tokens":1728,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264350395,"hash":"92cbf0a6213e7ba0e114ee1f7911d5092de64d9a"}
{"url":"https://dev-forum.pyth.network/t/error-running-hermes-client/212/2","domain":"dev-forum.pyth.network","title":"Error running Hermes client - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 2 / 2\n\n Jun 2025\n\n Jun 2025\n\n post by Aditya520 on Jun 12, 2025\n\n Aditya520\n\n Posting for a user who wants to run hermes.\nHere are the parameters.\nspy --env mainnet --nodeKey /node.key --spyRPC \"[::]:7073\" --env mainnet --ethRPC \"<RPC URL for Ethereum>\" --ethContract 0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B --logLevel warn\nhermes run --rpc-listen-addr \"[::]:33999\" --pythnet-http-addr https://pythnet.rpcpool.com/ --pythnet-ws-addr wss://pythnet.rpcpool.com/ --wormhole-spy-rpc-addr http://<wormhole spy>:7073/\n\nThey are not seeting any feeds in /v2/price_feeds nor any feed working.\n\n post by ali on Jun 12, 2025\n\n ali\n\n Please try again running with this RPC https://api2.pythnet.pyth.network. If it doesn’t work out, please run it with RUST_LOG=info environment variable and share a dump of the logs along with the output of the /ready endpoint.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Hermes configuration\n\n Price Feeds\n\n 3\n\n 753\n\n Jun 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Powered by Discourse","tokens":1277,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264354787,"hash":"fff964b7ec51a7cc03fbd19285d2b7d948de0b77"}
{"url":"https://ethereum.org/developers/docs/consensus-mechanisms/poa/","domain":"ethereum.org","title":"Proof-of-authority (PoA) | ethereum.org","text":"Proof-of-authority (PoA)Edit page (opens in a new tab)Proof-of-authority (PoA) is a reputation-based consensus algorithm that is a modified version of proof-of-stake. It is mostly used by private chains, testnets, and local development networks. PoA is a reputation-based consensus algorithm that requires trusting a set of authorized signers to produce blocks, instead of a stake-based mechanism in PoS.\nPrerequisites\nTo better understand this page, we recommend you first read up on transactions, blocks, and consensus mechanisms.\nWhat is proof-of-authority (PoA)?\nProof-of-authority is a modified version of proof-of-stake (PoS) that is a reputation-based consensus algorithm instead of stake-based mechanism in PoS. The term has been introduced for the first time in 2017 by Gavin Wood, and this consensus algorithm has been mostly used by private chains, testnets and local development networks, as it overcomes the need for high quality resources as PoW does, and overcomes the scalability issues with PoS by having small subset of nodes storing the blockchain and producing blocks.\nProof-of-authority requires trusting a set of authorized signers that are set in the . In most current implementations, all authorized signers retain equal power and privileges when determining consensus of the chain. The idea behind reputation staking is every authorized validator is well-known to everyone through things like know your customer (KYC), or by having a well-known organization being the only validator—this way if a validator does anything wrong, their identity is known.\nThere are multiple implementations of PoA, but the standard Ethereum implementation is clique, which implements EIP-225 (opens in a new tab). Clique is developer-friendly and an easy-to-implement standard, supporting all client syncing types. Other implementations include IBFT 2.0 (opens in a new tab) and Aura (opens in a new tab).\nHow it works\nIn PoA, a set of authorized signers are selected to create new blocks. The signers are selected based on their reputation, and they are the only ones allowed to create new blocks. The signers are selected in a round-robin fashion, and each signer is allowed to create a block in a specific time frame. The block creation time is fixed, and the signers are required to create a block within that time frame.\nThe reputation in this context is not a quantified thing but rather it is the reputation of well-known corporations like Microsoft and Google, hence the way of selecting the trusted signers is not algorithmic but rather it is the normal human act of trust where an entity let's say for example Microsoft creates a PoA private network between hundreds or thousands of startups and the role itself as the only trusted signer with the possibility of adding other well-known signers like Google in the future, the startups would, without doubt, trust Microsoft to act in an honest manner all the times and use the network. This solves the need to stake in different small/private networks that were built for different purposes to keep them decentralized and functioning, along with the need for miners, which consumes a lot of power and resources. Some private networks use the PoA standard as it such as VeChain, and some modify it such as Binance which uses PoSA (opens in a new tab) which is a custom modified version of PoA and PoS.\nThe voting process is done by the signers themselves. Each signer votes for the addition or removal of a signer in their block when they create a new block. The votes are tallied up by the nodes, and the signers are added or removed based on the votes reaching a certain threshold SIGNER_LIMIT.\nThere may be a situation where small forks occur, the difficulty of a block depends on whether the block was signed in turn or out of turn. “In turn” blocks have difficulty 2, and “out of turn” blocks have difficulty 1. In the case of small forks, the chain with most of the signers sealing blocks “in turn” will accumulate the most difficulty and win.\nAttack vectors\nMalicious signers\nA malicious user could be added to the list of signers, or a signing key/machine might be compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the validators can vote out the malicious user.\nCensorship\nAnother interesting attack vector is if a signer (or group of signers) attempts to censor blocks that vote on removing them from the authorization list. To work around this, the allowed minting frequency of signers is restricted to 1 out of N/2. This ensures that malicious signers need to control at least 51% of signing accounts, at which point they would effectively become the new source-of-truth for the chain.\nSpam\nAnother small attack vector is malicious signers injecting new vote proposals inside every block they mint. Since nodes need to tally up all votes to create the actual list of authorized signers, they must record all votes over time. Without placing a limit on the vote window, this could grow slowly, yet unbounded. The solution is to place a moving window of W blocks after which votes are considered stale. A reasonable window might be 1-2 epochs.\nConcurrent blocks\nIn a PoA network, When there are N authorized signers, each signer is allowed to mint 1 block out of K, which means that N-K+1 validators are allowed to mint at any given point in time. To prevent these validators from racing for blocks, each signer should add a small random \"offset\" to the time it releases a new block. Although this process ensures that small forks are rare, occasional forks can still happen, just like mainnet. If a signer is found to be abusing its power and causing chaos, the other signers can vote them out.\nIf for example there are 10 authorized signers and each signer is allowed to create 1 block out of 6, then at any given time, 5 validators can create blocks. To prevent them from racing to create blocks, each signer adds a small random \"offset\" to the time they release a new block. This reduces the occurrence of small forks but still allows occasional forks, as seen on the Ethereum Mainnet. If a signer misuses their authority and causes disruptions, they can be voted out of the network.\nPros and cons\nProsConsScalable more than other popular mechanisms such PoS and PoW, as it's based on a limited number of block signersPoA networks typically have a relatively small number of validating nodes. This makes a PoA network more centralized.PoA blockchains are incredibly cheap to run and maintainBecoming an authorized signer is typically out of reach for an ordinary person, because the blockchain requires entities with established reputation.The transactions are confirmed very quick as it could reach less than 1 second because only limited number of signers are required to validate new blocksMalicious signers could reorg, double spend, censor transactions in the network, those attacks are mitigated but still possible\nFurther reading\n\nEIP-225 (opens in a new tab) Clique standard\nProof of Authority study (opens in a new tab) Cryptoeconomics\nWhat is Proof of Authority (opens in a new tab) OpenZeppelin\nProof of Authority Explained (opens in a new tab) binance\nPoA in blockchain (opens in a new tab)\nClique explained (opens in a new tab)\nDeprecated PoA, Aura specification (opens in a new tab)\nIBFT 2.0, another PoA implementation (opens in a new tab)\n\nMore of a visual learner?\nWatch a visual explanation of proof-of-authority:\nCryptoeconomics: proof of authorityA cryptoeconomics lecture explaining the proof-of-authority (PoA) consensus mechanism, covering how it works, its trade-offs compared to proof of work and proof of stake, and where it is used in practice.Watch with transcript \nRelated topics\n\nProof-of-work\nProof-of-stake","tokens":1990,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264362166,"hash":"e2739c3356359748e4f577aef90fc9db2f89f966"}
{"url":"https://dev-forum.pyth.network/t/hermes-configuration/196/4","domain":"dev-forum.pyth.network","title":"Hermes configuration - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Jun 2025\n\n 4 / 4\n\n Jun 2025\n\n Jun 2025\n\n post by andrei-aftermath on Jun 5, 2025\n\n andrei-aftermath\n\n I’m trying to get price feeds for SUI.\nI’m using Hermes (pyth-crosschain/apps/hermes/server at main · pyth-network/pyth-crosschain · GitHub) and Beacon (GitHub - pyth-network/beacon: A Wormhole message relay) for it.\nHermes requires to set --pythnet-http-addr and --pythnet-ws-addr.\nWhat values should I use for these? It is possible to setup a local Pyth node or I should you a some public Pyth node?\n\n 2\n\n 2\n\n post by ali on Jun 5, 2025\n\n ali\n\n I’m wondering why you are not using the public Hermes instances (or the ones from node providers). You can use https://api2.pythnet.pyth.network and wss://api2.pythnet.pyth.network as endpoints for it.\n\n post by andrei-aftermath on Jun 5, 2025\n\n andrei-aftermath\n\n Thanks for you answer!\nBut, I want greater control over the infrastructure, and I hope the feeds will perform faster.\n\n post by ali on Jun 6, 2025\n\n ali\n\n Would be good if you expand what exactly you need; you can’t go faster with your own Pythnet RPC because the latency path goes through Wormhole and the only way to optimize it by running beacon and hermes yourself (which you are doing). But if you want to try it yourself, here is the link to the guide on running Pythnet RPC. You’d run it at your own risk, there is a limited support bandwidth on it and you need to stay on top of the updates (by watching Github releases and validators versions) yourself.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error running Hermes client\n\n Price Feeds\n\n 1\n\n 496\n\n Jun 2025\n\n How to self-hosting Pyth price service\n\n Price Feeds\n\n 2\n\n 561\n\n Sep 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n How to Deploy My Own Hermes Node\n\n Price Feeds\n\n 1\n\n 267\n\n Nov 2025\n\n Powered by Discourse","tokens":1398,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264365343,"hash":"301b153ad3f80a31a0ab08622762108f32c54336"}
{"url":"https://eips.ethereum.org/EIPS/eip-225","domain":"eips.ethereum.org","title":"EIP-225: Clique proof-of-authority consensus protocol","text":"🎉 Final\n\n Standards Track: Core\n\n EIP-225: Clique proof-of-authority consensus protocol\n\n Authors\n Péter Szilágyi <peterke@gmail.com>\n\n Created\n 2017-03-06\n\n Abstract\n\nClique is a proof-of-authority consensus protocol. It shadows the design of Ethereum mainnet, so it can be added to any client with minimal effort.\n\n Motivation\n\nEthereum’s first official testnet was Morden. It ran from July 2015 to about November 2016, when due to the accumulated junk and some testnet consensus issues between Geth and Parity, it was finally laid to rest in favor of a testnet reboot.\n\nRopsten was thus born, clearing out all the junk and starting with a clean slate. This ran well until the end of February 2017, when malicious actors decided to abuse the low PoW and gradually inflate the block gas limits to 9 billion (from the normal 4.7 million), at which point sending in gigantic transactions crippling the entire network. Even before that, attackers attempted multiple extremely long reorgs, causing network splits between different clients, and even different versions.\n\nThe root cause of these attacks is that a PoW network is only as secure as the computing capacity placed behind it. Restarting a new testnet from zero wouldn’t solve anything, since the attacker can mount the same attack over and over again. The Parity team decided to go with an emergency solution of rolling back a significant number of blocks, and enacting a soft-fork rule that disallows gas limits above a certain threshold.\n\nWhile this solution may work in the short term:\n\n It’s not elegant: Ethereum supposed to have dynamic block limits\n It’s not portable: other clients need to implement new fork logic themselves\n It’s not compatible with sync modes: fast and light clients are both out of luck\n It’s just prolonging the attacks: junk can still be steadily pushed in ad infinitum\n\nParity’s solution although not perfect, is nonetheless workable. I’d like to propose a longer term alternative solution, which is more involved, yet should be simple enough to allow rolling out in a reasonable amount of time.\n\n Standardized proof-of-authority\n\nAs reasoned above, proof-of-work cannot work securely in a network with no value. Ethereum has its long term goal of proof-of-stake based on Casper, but that is heavy research so we cannot rely on that any time soon to fix today’s problems. One solution however is easy enough to implement, yet effective enough to fix the testnet properly, namely a proof-of-authority scheme.\n\nThe main design goals of the PoA protocol described here is that it should be very simple to implement and embed into any existing Ethereum client, while at the same time allow using existing sync technologies (fast, light, warp) without needing client developers to add custom logic to critical software.\n\n Design constraints\n\nThere are two approaches to syncing a blockchain in general:\n\n The classical approach is to take the genesis block and crunch through all the transactions one by one. This is tried and proven, but in Ethereum complexity networks quickly turns out to be very costly computationally.\n The other is to only download the chain of block headers and verify their validity, after which point an arbitrary recent state may be downloaded from the network and checked against recent headers.\n\nA PoA scheme is based on the idea that blocks may only be minted by trusted signers. As such, every block (or header) that a client sees can be matched against the list of trusted signers. The challenge here is how to maintain a list of authorized signers that can change in time? The obvious answer (store it in an Ethereum contract) is also the wrong answer: fast, light and warp sync don’t have access to the state during syncing.\n\nThe protocol of maintaining the list of authorized signers must be fully contained in the block headers.\n\nThe next obvious idea would be to change the structure of the block headers so it drops the notions of PoW, and introduces new fields to cater for voting mechanisms. This is also the wrong answer: changing such a core data structure in multiple implementations would be a nightmare development, maintenance and security wise.\n\nThe protocol of maintaining the list of authorized signers must fit fully into the current data models.\n\nSo, according to the above, we can’t use the EVM for voting, rather have to resort to headers. And we can’t change header fields, rather have to resort to the currently available ones. Not much wiggle room.\n\n Repurposing header fields for signing and voting\n\nThe most obvious field that currently is used solely as fun metadata is the 32 byte extra-data section in block headers. Miners usually place their client and version in there, but some fill it with alternative “messages”. The protocol would extend this field to with 65 bytes with the purpose of a secp256k1 miner signature. This would allow anyone obtaining a block to verify it against a list of authorized signers. It also makes the miner section in block headers obsolete (since the address can be derived from the signature).\n\nNote, changing the length of a header field is a non invasive operation as all code (such as RLP encoding, hashing) is agnostic to that, so clients wouldn’t need custom logic.\n\nThe above is enough to validate a chain, but how can we update a dynamic list of signers. The answer is that we can repurpose the newly obsoleted miner field and the PoA obsoleted nonce field to create a voting protocol:\n\n During regular blocks, both of these fields would be set to zero.\n If a signer wishes to enact a change to the list of authorized signers, it will:\n\n Set the miner to the signer it wishes to vote about\n Set the nonce to 0 or 0xff...f to vote in favor of adding or kicking out\n\nAny clients syncing the chain can “tally” up the votes during block processing, and maintain a dynamically changing list of authorized signers by popular vote.\n\nTo avoid having an infinite window to tally up votes in, and also to allow periodically flushing stale proposals, we can reuse the concept of an epoch from ethash, where every epoch transition flushes all pending votes. Furthermore, these epoch transitions can also act as stateless checkpoints containing the list of current authorized signers within the header extra-data. This permits clients to sync up based only on a checkpoint hash without having to replay all the voting that was done on the chain up to that point. It also allows the genesis header to fully define the chain, containing the list of initial signers.\n\n Attack vector: Malicious signer\n\nIt may happen that a malicious user gets added to the list of signers, or that a signer key/machine is compromised. In such a scenario the protocol needs to be able to defend itself against reorganizations and spamming. The proposed solution is that given a list of N authorized signers, any signer may only mint 1 block out of every K. This ensures that damage is limited, and the remainder of the miners can vote out the malicious user.\n\n Attack vector: Censoring signer\n\nAnother interesting attack vector is if a signer (or group of signers) attempts to censor out blocks that vote on removing them from the authorization list. To work around this, we restrict the allowed minting frequency of signers to 1 out of N/2. This ensures that malicious signers need to control at least 51% of signing accounts, at which case it’s game over anyway.\n\n Attack vector: Spamming signer\n\nA final small attack vector is that of malicious signers injecting new vote proposals inside every block they mint. Since nodes need to tally up all votes to create the actual list of authorized signers, they need to track all votes through time. Without placing a limit on the vote window, this could grow slowly, yet unbounded. The solution is to place a moving window of W blocks after which votes are considered stale. A sane window might be 1-2 epochs. We’ll call this an epoch.\n\n Attack vector: Concurrent blocks\n\nIf the number of authorized signers are N, and we allow each signer to mint 1 block out of K, then at any point in time N-K+1 miners are allowed to mint. To avoid these racing for blocks, every signer would add a small random “offset” to the time it releases a new block. This ensures that small forks are rare, but occasionally still happen (as on the main net). If a signer is caught abusing it’s authority and causing chaos, it can be voted out.\n\n Specification\n\nWe define the following constants:\n\n EPOCH_LENGTH: Number of blocks after which to checkpoint and reset the pending votes.\n\n Suggested 30000 for the testnet to remain analogous to the mainnet ethash epoch.\n\n BLOCK_PERIOD: Minimum difference between two consecutive block’s timestamps.\n\n Suggested 15s for the testnet to remain analogous to the mainnet ethash target.\n\n EXTRA_VANITY: Fixed number of extra-data prefix bytes reserved for signer vanity.\n\n Suggested 32 bytes to retain the current extra-data allowance and/or use.\n\n EXTRA_SEAL: Fixed number of extra-data suffix bytes reserved for signer seal.\n\n 65 bytes fixed as signatures are based on the standard secp256k1 curve.\n Filled with zeros on genesis block.\n\n NONCE_AUTH: Magic nonce number 0xffffffffffffffff to vote on adding a new signer.\n NONCE_DROP: Magic nonce number 0x0000000000000000 to vote on removing a signer.\n UNCLE_HASH: Always Keccak256(RLP([])) as uncles are meaningless outside of PoW.\n DIFF_NOTURN: Block score (difficulty) for blocks containing out-of-turn signatures.\n\n Suggested 1 since it just needs to be an arbitrary baseline constant.\n\n DIFF_INTURN: Block score (difficulty) for blocks containing in-turn signatures.\n\n Suggested 2 to show a slight preference over out-of-turn signatures.\n\nWe also define the following per-block constants:\n\n BLOCK_NUMBER: Block height in the chain, where the height of the genesis is block 0.\n SIGNER_COUNT: Number of authorized signers valid at a particular instance in the chain.\n SIGNER_INDEX: Zero-based index of the block signer in the sorted list of current authorized signers.\n SIGNER_LIMIT: Number of consecutive blocks out of which a signer may only sign one.\n\n Must be floor(SIGNER_COUNT / 2) + 1 to enforce majority consensus on a chain.\n\nWe repurpose the ethash header fields as follows:\n\n beneficiary / miner: Address to propose modifying the list of authorized signers with.\n\n Should be filled with zeroes normally, modified only while voting.\n Arbitrary values are permitted nonetheless (even meaningless ones such as voting out non signers) to avoid extra complexity in implementations around voting mechanics.\n Must be filled with zeroes on checkpoint (i.e. epoch transition) blocks.\n Transaction execution must use the actual block signer (see extraData) for the COINBASE opcode and transaction fees must be attributed to the signer account.\n\n nonce: Signer proposal regarding the account defined by the beneficiary field.\n\n Should be NONCE_DROP to propose deauthorizing beneficiary as an existing signer.\n Should be NONCE_AUTH to propose authorizing beneficiary as a new signer.\n Must be filled with zeroes on checkpoint (i.e. epoch transition) blocks.\n Must not take up any other value apart from the two above (for now).\n\n extraData: Combined field for signer vanity, checkpointing and signer signatures.\n\n First EXTRA_VANITY bytes (fixed) may contain arbitrary signer vanity data.\n Last EXTRA_SEAL bytes (fixed) is the signer’s signature sealing the header.\n Checkpoint blocks must contain a list of signers (N*20 bytes) in between, omitted otherwise.\n The list of signers in checkpoint block extra-data sections must be sorted in ascending byte order.\n\n mixHash: Reserved for fork protection logic, similar to the extra-data during the DAO.\n\n Must be filled with zeroes during normal operation.\n\n ommersHash: Must be UNCLE_HASH as uncles are meaningless outside of PoW.\n timestamp: Must be at least the parent timestamp + BLOCK_PERIOD.\n difficulty: Contains the standalone score of the block to derive the quality of a chain.\n\n Must be DIFF_NOTURN if BLOCK_NUMBER % SIGNER_COUNT != SIGNER_INDEX\n Must be DIFF_INTURN if BLOCK_NUMBER % SIGNER_COUNT == SIGNER_INDEX\n\n Authorizing a block\n\nTo authorize a block for the network, the signer needs to sign the block’s sighash containing everything except the signature itself. This means that this hash contains every field of the header (nonce and mixDigest included), and also the extraData with the exception of the 65 byte signature suffix. The fields are hashed in the order of their definition in the yellow paper. Note that this sighash differs from the final block hash which also includes the signature.\n\nThe sighash is signed using the standard secp256k1 curve, and the resulting 65 byte signature (R, S, V, where V is 0 or 1) is embedded into the extraData as the trailing 65 byte suffix.\n\nTo ensure malicious signers (loss of signing key) cannot wreck havoc in the network, each signer is allowed to sign maximum one out of SIGNER_LIMIT consecutive blocks. The order is not fixed, but in-turn signing weighs more (DIFF_INTURN) than out of turn one (DIFF_NOTURN).\n\n Authorization strategies\n\nAs long as signers conform to the above specs, they can authorize and distribute blocks as they see fit. The following suggested strategy will however reduce network traffic and small forks, so it’s a suggested feature:\n\n If a signer is allowed to sign a block (is on the authorized list and didn’t sign recently).\n\n Calculate the optimal signing time of the next block (parent + BLOCK_PERIOD).\n If the signer is in-turn, wait for the exact time to arrive, sign and broadcast immediately.\n If the signer is out-of-turn, delay signing by rand(SIGNER_COUNT * 500ms).\n\nThis small strategy will ensure that the in-turn signer (who’s block weighs more) has a slight advantage to sign and propagate versus the out-of-turn signers. Also the scheme allows a bit of scale with the increase of the number of signers.\n\n Voting on signers\n\nEvery epoch transition (genesis block included) acts as a stateless checkpoint, from which capable clients should be able to sync without requiring any previous state. This means epoch headers must not contain votes, all non settled votes are discarded, and tallying starts from scratch.\n\nFor all non-epoch transition blocks:\n\n Signers may cast one vote per own block to propose a change to the authorization list.\n Only the latest proposal per target beneficiary is kept from a single signer.\n Votes are tallied live as the chain progresses (concurrent proposals allowed).\n Proposals reaching majority consensus SIGNER_LIMIT come into effect immediately.\n Invalid proposals are not to be penalized for client implementation simplicity.\n\nA proposal coming into effect entails discarding all pending votes for that proposal (both for and against) and starting with a clean slate.\n\n Cascading votes\n\nA complex corner case may arise during signer deauthorization. When a previously authorized signer is dropped, the number of signers required to approve a proposal might decrease by one. This might cause one or more pending proposals to reach majority consensus, the execution of which might further cascade into new proposals passing.\n\nHandling this scenario is non obvious when multiple conflicting proposals pass simultaneously (e.g. add a new signer vs. drop an existing one), where the evaluation order might drastically change the outcome of the final authorization list. Since signers may invert their own votes in every block they mint, it’s not so obvious which proposal would be “first”.\n\nTo avoid the pitfalls cascading executions would entail, the Clique proposal explicitly forbids cascading effects. In other words: Only the beneficiary of the current header/vote may be added to/dropped from the authorization list. If that causes other proposals to reach consensus, those will be executed when their respective beneficiaries are “touched” again (given that majority consensus still holds at that point).\n\n Voting strategies\n\nSince the blockchain can have small reorgs, a naive voting mechanism of “cast-and-forget” may not be optimal, since a block containing a singleton vote may not end up on the final chain.\n\nA simplistic but working strategy is to allow users to configure “proposals” on the signers (e.g. “add 0x…”, “drop 0x…”). The signing code can then pick a random proposal for every block it signs and inject it. This ensures that multiple concurrent proposals as well as reorgs get eventually noted on the chain.\n\nThis list may be expired after a certain number of blocks / epochs, but it’s important to realize that “seeing” a proposal pass doesn’t mean it won’t get reorged, so it should not be immediately dropped when the proposal passes.\n\n Test Cases\n\n// block represents a single block signed by a particular account, where\n// the account may or may not have cast a Clique vote.\ntype block struct {\n signer string // Account that signed this particular block\n voted string // Optional value if the signer voted on adding/removing someone\n auth bool // Whether the vote was to authorize (or deauthorize)\n checkpoint []string // List of authorized signers if this is an epoch block\n}\n\n// Define the various voting scenarios to test\ntests := []struct {\n epoch uint64 // Number of blocks in an epoch (unset = 30000)\n signers []string // Initial list of authorized signers in the genesis\n blocks []block // Chain of signed blocks, potentially influencing auths\n results []string // Final list of authorized signers after all blocks\n failure error // Failure if some block is invalid according to the rules\n}{\n {\n // Single signer, no votes cast\n signers: []string{\"A\"},\n blocks: []block{\n {signer: \"A\"}\n },\n results: []string{\"A\"},\n }, {\n // Single signer, voting to add two others (only accept first, second needs 2 votes)\n signers: []string{\"A\"},\n blocks: []block{\n {signer: \"A\", voted: \"B\", auth: true},\n {signer: \"B\"},\n {signer: \"A\", voted: \"C\", auth: true},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Two signers, voting to add three others (only accept first two, third needs 3 votes already)\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: true},\n {signer: \"B\", voted: \"C\", auth: true},\n {signer: \"A\", voted: \"D\", auth: true},\n {signer: \"B\", voted: \"D\", auth: true},\n {signer: \"C\"},\n {signer: \"A\", voted: \"E\", auth: true},\n {signer: \"B\", voted: \"E\", auth: true},\n },\n results: []string{\"A\", \"B\", \"C\", \"D\"},\n }, {\n // Single signer, dropping itself (weird, but one less cornercase by explicitly allowing this)\n signers: []string{\"A\"},\n blocks: []block{\n {signer: \"A\", voted: \"A\", auth: false},\n },\n results: []string{},\n }, {\n // Two signers, actually needing mutual consent to drop either of them (not fulfilled)\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"B\", auth: false},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Two signers, actually needing mutual consent to drop either of them (fulfilled)\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"B\", auth: false},\n {signer: \"B\", voted: \"B\", auth: false},\n },\n results: []string{\"A\"},\n }, {\n // Three signers, two of them deciding to drop the third\n signers: []string{\"A\", \"B\", \"C\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Four signers, consensus of two not being enough to drop anyone\n signers: []string{\"A\", \"B\", \"C\", \"D\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n },\n results: []string{\"A\", \"B\", \"C\", \"D\"},\n }, {\n // Four signers, consensus of three already being enough to drop someone\n signers: []string{\"A\", \"B\", \"C\", \"D\"},\n blocks: []block{\n {signer: \"A\", voted: \"D\", auth: false},\n {signer: \"B\", voted: \"D\", auth: false},\n {signer: \"C\", voted: \"D\", auth: false},\n },\n results: []string{\"A\", \"B\", \"C\"},\n }, {\n // Authorizations are counted once per signer per target\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: true},\n {signer: \"B\"},\n {signer: \"A\", voted: \"C\", auth: true},\n {signer: \"B\"},\n {signer: \"A\", voted: \"C\", auth: true},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Authorizing multiple accounts concurrently is permitted\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: true},\n {signer: \"B\"},\n {signer: \"A\", voted: \"D\", auth: true},\n {signer: \"B\"},\n {signer: \"A\"},\n {signer: \"B\", voted: \"D\", auth: true},\n {signer: \"A\"},\n {signer: \"B\", voted: \"C\", auth: true},\n },\n results: []string{\"A\", \"B\", \"C\", \"D\"},\n }, {\n // Deauthorizations are counted once per signer per target\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"B\", auth: false},\n {signer: \"B\"},\n {signer: \"A\", voted: \"B\", auth: false},\n {signer: \"B\"},\n {signer: \"A\", voted: \"B\", auth: false},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Deauthorizing multiple accounts concurrently is permitted\n signers: []string{\"A\", \"B\", \"C\", \"D\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\"},\n {signer: \"C\"},\n {signer: \"A\", voted: \"D\", auth: false},\n {signer: \"B\"},\n {signer: \"C\"},\n {signer: \"A\"},\n {signer: \"B\", voted: \"D\", auth: false},\n {signer: \"C\", voted: \"D\", auth: false},\n {signer: \"A\"},\n {signer: \"B\", voted: \"C\", auth: false},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Votes from deauthorized signers are discarded immediately (deauth votes)\n signers: []string{\"A\", \"B\", \"C\"},\n blocks: []block{\n {signer: \"C\", voted: \"B\", auth: false},\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n {signer: \"A\", voted: \"B\", auth: false},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Votes from deauthorized signers are discarded immediately (auth votes)\n signers: []string{\"A\", \"B\", \"C\"},\n blocks: []block{\n {signer: \"C\", voted: \"D\", auth: true},\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n {signer: \"A\", voted: \"D\", auth: true},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Cascading changes are not allowed, only the account being voted on may change\n signers: []string{\"A\", \"B\", \"C\", \"D\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\"},\n {signer: \"C\"},\n {signer: \"A\", voted: \"D\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n {signer: \"C\"},\n {signer: \"A\"},\n {signer: \"B\", voted: \"D\", auth: false},\n {signer: \"C\", voted: \"D\", auth: false},\n },\n results: []string{\"A\", \"B\", \"C\"},\n }, {\n // Changes reaching consensus out of bounds (via a deauth) execute on touch\n signers: []string{\"A\", \"B\", \"C\", \"D\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\"},\n {signer: \"C\"},\n {signer: \"A\", voted: \"D\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n {signer: \"C\"},\n {signer: \"A\"},\n {signer: \"B\", voted: \"D\", auth: false},\n {signer: \"C\", voted: \"D\", auth: false},\n {signer: \"A\"},\n {signer: \"C\", voted: \"C\", auth: true},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // Changes reaching consensus out of bounds (via a deauth) may go out of consensus on first touch\n signers: []string{\"A\", \"B\", \"C\", \"D\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: false},\n {signer: \"B\"},\n {signer: \"C\"},\n {signer: \"A\", voted: \"D\", auth: false},\n {signer: \"B\", voted: \"C\", auth: false},\n {signer: \"C\"},\n {signer: \"A\"},\n {signer: \"B\", voted: \"D\", auth: false},\n {signer: \"C\", voted: \"D\", auth: false},\n {signer: \"A\"},\n {signer: \"B\", voted: \"C\", auth: true},\n },\n results: []string{\"A\", \"B\", \"C\"},\n }, {\n // Ensure that pending votes don't survive authorization status changes. This\n // corner case can only appear if a signer is quickly added, removed and then\n // readded (or the inverse), while one of the original voters dropped. If a\n // past vote is left cached in the system somewhere, this will interfere with\n // the final signer outcome.\n signers: []string{\"A\", \"B\", \"C\", \"D\", \"E\"},\n blocks: []block{\n {signer: \"A\", voted: \"F\", auth: true}, // Authorize F, 3 votes needed\n {signer: \"B\", voted: \"F\", auth: true},\n {signer: \"C\", voted: \"F\", auth: true},\n {signer: \"D\", voted: \"F\", auth: false}, // Deauthorize F, 4 votes needed (leave A's previous vote \"unchanged\")\n {signer: \"E\", voted: \"F\", auth: false},\n {signer: \"B\", voted: \"F\", auth: false},\n {signer: \"C\", voted: \"F\", auth: false},\n {signer: \"D\", voted: \"F\", auth: true}, // Almost authorize F, 2/3 votes needed\n {signer: \"E\", voted: \"F\", auth: true},\n {signer: \"B\", voted: \"A\", auth: false}, // Deauthorize A, 3 votes needed\n {signer: \"C\", voted: \"A\", auth: false},\n {signer: \"D\", voted: \"A\", auth: false},\n {signer: \"B\", voted: \"F\", auth: true}, // Finish authorizing F, 3/3 votes needed\n },\n results: []string{\"B\", \"C\", \"D\", \"E\", \"F\"},\n }, {\n // Epoch transitions reset all votes to allow chain checkpointing\n epoch: 3,\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\", voted: \"C\", auth: true},\n {signer: \"B\"},\n {signer: \"A\", checkpoint: []string{\"A\", \"B\"}},\n {signer: \"B\", voted: \"C\", auth: true},\n },\n results: []string{\"A\", \"B\"},\n }, {\n // An unauthorized signer should not be able to sign blocks\n signers: []string{\"A\"},\n blocks: []block{\n {signer: \"B\"},\n },\n failure: errUnauthorizedSigner,\n }, {\n // An authorized signer that signed recently should not be able to sign again\n signers: []string{\"A\", \"B\"},\n blocks: []block{\n {signer: \"A\"},\n {signer: \"A\"},\n },\n failure: errRecentlySigned,\n }, {\n // Recent signatures should not reset on checkpoint blocks imported in a batch\n epoch: 3,\n signers: []string{\"A\", \"B\", \"C\"},\n blocks: []block{\n {signer: \"A\"},\n {signer: \"B\"},\n {signer: \"A\", checkpoint: []string{\"A\", \"B\", \"C\"}},\n {signer: \"A\"},\n },\n failure: errRecentlySigned,\n },\n}\n\n Implementation\n\nA reference implementation is part of go-ethereum and has been functioning as the consensus engine behind the Rinkeby testnet since April, 2017.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Péter Szilágyi <peterke@gmail.com>, \"EIP-225: Clique proof-of-authority consensus protocol,\" Ethereum Improvement Proposals, no. 225, March 2017. Available: https://eips.ethereum.org/EIPS/eip-225.","tokens":6529,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264372311,"hash":"df49501c0ad8b0cafbc8045715c3874d89475761"}
{"url":"https://docs.soliditylang.org/en/develop/grammar.html","domain":"docs.soliditylang.org","title":"Language Grammar — Solidity 0.8.38-develop documentation","text":"Language Grammar\n\n Edit on GitHub\n\nLanguage Grammar\n\ngrammar SolidityParser\nSolidity is a statically typed, contract-oriented, high-level language for implementing smart contracts on the Ethereum platform.\n\nsource-unit\nOn top level, Solidity allows pragmas, import directives, and\ndefinitions of contracts, interfaces, libraries, structs, enums and constants.\n\nimport-directive\nImport directives import identifiers from different files.\n\npath\nPath of a file to be imported.\n\nsymbol-aliases\nList of aliases for symbols to be imported.\n\ncontract-definition\nTop-level definition of a contract.\n\ninterface-definition\nTop-level definition of an interface.\n\nlibrary-definition\nTop-level definition of a library.\n\ninheritance-specifier\nInheritance specifier for contracts and interfaces.\nCan optionally supply base constructor arguments.\n\ncontract-body-element\nDeclarations that can be used in contracts, interfaces and libraries.\nNote that interfaces and libraries may not contain constructors, interfaces may not contain state variables\nand libraries may not contain fallback, receive functions nor non-constant state variables.\n\ncall-argument-list\nArguments when calling a function or a similar callable object.\nThe arguments are either given as comma separated list or as map of named arguments.\n\nidentifier-path\nQualified name.\n\nmodifier-invocation\nCall to a modifier. If the modifier takes no arguments, the argument list can be skipped entirely\n(including opening and closing parentheses).\n\nvisibility\nVisibility for functions and function types.\n\nparameter-list\nA list of parameters, such as function arguments or return values.\n\nconstructor-definition\nDefinition of a constructor.\nMust always supply an implementation.\nNote that specifying internal or public visibility is deprecated.\n\nstate-mutability\nState mutability for function types.\nThe default mutability ‘non-payable’ is assumed if no mutability is specified.\n\noverride-specifier\nAn override specifier used for functions, modifiers or state variables.\nIn cases where there are ambiguous declarations in several base contracts being overridden,\na complete list of base contracts has to be given.\n\nfunction-definition\nThe definition of contract, library, interface or free functions.\nDepending on the context in which the function is defined, further restrictions may apply,\ne.g. functions in interfaces have to be unimplemented, i.e. may not contain a body block.\n\nmodifier-definition\nThe definition of a modifier.\nNote that within the body block of a modifier, the underscore cannot be used as identifier,\nbut is used as placeholder statement for the body of a function to which the modifier is applied.\n\nfallback-function-definition\nDefinition of the special fallback function.\n\nreceive-function-definition\nDefinition of the special receive function.\n\nstruct-definition\nDefinition of a struct. Can occur at top-level within a source unit or within a contract, library or interface.\n\nstruct-member\nThe declaration of a named struct member.\n\nenum-definition\nDefinition of an enum. Can occur at top-level within a source unit or within a contract, library or interface.\n\nuser-defined-value-type-definition\nDefinition of a user defined value type. Can occur at top-level within a source unit or within a contract, library or interface.\n\nstate-variable-declaration\nThe declaration of a state variable.\n\nconstant-variable-declaration\nThe declaration of a constant variable.\n\nevent-parameter\nParameter of an event.\n\nevent-definition\nDefinition of an event. Can occur in contracts, libraries or interfaces.\n\nerror-parameter\nParameter of an error.\n\nerror-definition\nDefinition of an error.\n\nuser-definable-operator\nOperators that users are allowed to implement for some types with using for.\n\nusing-directive\nUsing directive to attach library functions and free functions to types.\nCan occur within contracts and libraries and at the file level.\n\nusing-aliases\n\ntype-name\nA type name can be an elementary type, a function type, a mapping type, a user-defined type\n(e.g. a contract or struct) or an array type.\n\nelementary-type-name\n\nfunction-type-name\n\nvariable-declaration\nThe declaration of a single variable.\n\ndata-location\n\nexpression\nComplex expression.\nCan be an index access, an index range access, a member access, a function call (with optional function call options),\na type conversion, an unary or binary expression, a comparison or assignment, a ternary expression,\na new-expression (i.e. a contract creation or the allocation of a dynamic memory array),\na tuple, an inline array or a primary expression (i.e. an identifier, literal or type name).\n\ntuple-expression\n\ninline-array-expression\nAn inline array expression denotes a statically sized array of the common type of the contained expressions.\n\nidentifier\nBesides regular non-keyword Identifiers, some keywords like ‘from’ and ‘error’ can also be used as identifiers.\n\nliteral\n\nliteral-with-sub-denomination\n\nboolean-literal\n\nstring-literal\nA full string literal consists of either one or several consecutive quoted strings.\n\nhex-string-literal\nA full hex string literal that consists of either one or several consecutive hex strings.\n\nunicode-string-literal\nA full unicode string literal that consists of either one or several consecutive unicode strings.\n\nnumber-literal\nNumber literals can be decimal or hexadecimal numbers with an optional unit.\n\nblock\nA curly-braced block of statements. Opens its own scope.\n\nunchecked-block\n\nstatement\n\nif-statement\nIf statement with optional else part.\n\nfor-statement\nFor statement with optional init, condition and post-loop part.\n\nwhile-statement\n\ndo-while-statement\n\ncontinue-statement\nA continue statement. Only allowed inside for, while or do-while loops.\n\nbreak-statement\nA break statement. Only allowed inside for, while or do-while loops.\n\ntry-statement\nA try statement. The contained expression needs to be an external function call or a contract creation.\n\ncatch-clause\nThe catch clause of a try statement.\n\nreturn-statement\n\nemit-statement\nAn emit statement. The contained expression needs to refer to an event.\n\nrevert-statement\nA revert statement. The contained expression needs to refer to an error.\n\nassembly-statement\nAn inline assembly block.\nThe contents of an inline assembly block use a separate scanner/lexer, i.e. the set of keywords and\nallowed identifiers is different inside an inline assembly block.\n\nassembly-flags\nAssembly flags.\nComma-separated list of double-quoted strings as flags.\n\nvariable-declaration-tuple\nA tuple of variable names to be used in variable declarations.\nMay contain empty fields.\n\nvariable-declaration-statement\nA variable declaration statement.\nA single variable may be declared without initial value, whereas a tuple of variables can only be\ndeclared with initial value.\n\nexpression-statement\n\nmapping-type\n\nmapping-key-type\nOnly elementary types or user defined types are viable as mapping keys.\n\nyul-statement\nA Yul statement within an inline assembly block.\ncontinue and break statements are only valid within for loops.\nleave statements are only valid within function bodies.\n\nyul-block\n\nyul-variable-declaration\nThe declaration of one or more Yul variables with optional initial value.\nIf multiple variables are declared, only a function call is a valid initial value.\n\nyul-assignment\nAny expression can be assigned to a single Yul variable, whereas\nmulti-assignments require a function call on the right-hand side.\n\nyul-if-statement\n\nyul-for-statement\n\nyul-switch-statement\nA Yul switch statement can consist of only a default-case (deprecated) or\none or more non-default cases optionally followed by a default-case.\n\nyul-function-definition\n\nyul-path\nWhile only identifiers without dots can be declared within inline assembly,\npaths containing dots can refer to declarations outside the inline assembly block.\n\nyul-function-call\nA call to a function with return values can only occur as right-hand side of an assignment or\na variable declaration.\n\nyul-boolean\n\nyul-literal\n\nyul-expression\n\ngrammar SolidityLexer\n\nfixed-bytes\nBytes types of fixed length.\n\nsub-denomination\nUnit denomination for numbers.\n\nsigned-integer-type\nSized signed integer types.\nint is an alias of int256.\n\nunsigned-integer-type\nSized unsigned integer types.\nuint is an alias of uint256.\n\nnon-empty-string-literal\nA non-empty quoted string literal restricted to printable characters.\n\nempty-string-literal\nAn empty string literal\n\nsingle-quoted-printable\nAny printable character except single quote or back slash.\n\ndouble-quoted-printable\nAny printable character except double quote or back slash.\n\nescape-sequence\nEscape sequence.\nApart from common single character escape sequences, line breaks can be escaped\nas well as four hex digit unicode escapes \\uXXXX and two digit hex escape sequences \\xXX are allowed.\n\nunicode-string-literal\nA single quoted string literal allowing arbitrary unicode characters.\n\nhex-string\nHex strings need to consist of an even number of hex digits that may be grouped using underscores.\n\nhex-number\nHex numbers consist of a prefix and an arbitrary number of hex digits that may be delimited by underscores.\n\ndecimal-number\nA decimal number literal consists of decimal digits that may be delimited by underscores and\nan optional positive or negative exponent.\nIf the digits contain a decimal point, the literal has fixed point type.\n\nidentifier\nAn identifier in solidity has to start with a letter, a dollar-sign or an underscore and\nmay additionally contain numbers after the first symbol.\n\nyul-evm-builtin\nBuiltin functions in the EVM Yul dialect.\n\nyul-identifier\nYul identifiers consist of letters, dollar signs, underscores and numbers, but may not start with a number.\nIn inline assembly there cannot be dots in user-defined identifiers. Instead see yulPath for expressions\nconsisting of identifiers with dots.\n\nyul-hex-number\nHex literals in Yul consist of a prefix and one or more hexadecimal digits.\n\nyul-decimal-number\nDecimal literals in Yul may be zero or any sequence of decimal digits without leading zeroes.\n\nyul-string-literal\nString literals in Yul consist of one or more double-quoted or single-quoted strings\nthat may contain escape sequences and printable characters except unescaped line breaks or\nunescaped double-quotes or single-quotes, respectively.\n\npragma-token\nPragma token. Can contain any kind of symbol except a semicolon.\nNote that currently the solidity parser only allows a subset of this.","tokens":2639,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264372373,"hash":"4f8c28edc079537974188d7f1266d0ba696816a3"}
{"url":"https://docs.soliditylang.org/en/develop/assembly.html","domain":"docs.soliditylang.org","title":"Inline Assembly — Solidity 0.8.38-develop documentation","text":"Inline Assembly\n\n Edit on GitHub\n\nInline Assembly\nYou can interleave Solidity statements with inline assembly in a language close\nto the one of the Ethereum Virtual Machine. This gives you more fine-grained control,\nwhich is especially useful when you are enhancing the language by writing libraries or\noptimizing gas usage.\nThe language used for inline assembly in Solidity is called Yul\nand it is documented in its own section. This section will only cover\nhow the inline assembly code can interface with the surrounding Solidity code.\n\nWarning\nInline assembly is a way to access the Ethereum Virtual Machine\nat a low level. This bypasses several important safety\nfeatures and checks of Solidity. You should only use it for\ntasks that need it, and only if you are confident with using it.\n\nAn inline assembly block is marked by assembly { ... }, where the code inside\nthe curly braces is code in the Yul language.\nThe inline assembly code can access local Solidity variables as explained below.\nDifferent inline assembly blocks share no namespace, i.e. it is not possible\nto call a Yul function or access a Yul variable defined in a different inline assembly block.\n\nExample\nThe following example provides library code to access the code of another contract and\nload it into a bytes variable. This is possible with “plain Solidity” too, by using\n<address>.code. But the point here is that reusable assembly libraries can enhance the\nSolidity language without a compiler change.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\nlibrary GetCode {\n // This will report a warning - `at` will be promoted to reserved keyword\n function at(address addr) public view returns (bytes memory code) {\n assembly {\n // retrieve the size of the code, this needs assembly\n let size := extcodesize(addr)\n // allocate output byte array - this could also be done without assembly\n // by using code = new bytes(size)\n code := mload(0x40)\n // new \"memory end\" including padding\n mstore(0x40, add(code, and(add(add(size, 0x20), 0x1f), not(0x1f))))\n // store length in memory\n mstore(code, size)\n // actually retrieve the code, this needs assembly\n extcodecopy(addr, add(code, 0x20), 0, size)\n }\n }\n}\n\nInline assembly is also beneficial in cases where the optimizer fails to produce\nefficient code, for example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\nlibrary VectorSum {\n // This function is less efficient because the optimizer currently fails to\n // remove the bounds checks in array access.\n function sumSolidity(uint[] memory data) public pure returns (uint sum) {\n for (uint i = 0; i < data.length; ++i)\n sum += data[i];\n }\n\n // We know that we only access the array in bounds, so we can avoid the check.\n // 0x20 needs to be added to an array because the first slot contains the\n // array length.\n function sumAsm(uint[] memory data) public pure returns (uint sum) {\n for (uint i = 0; i < data.length; ++i) {\n assembly {\n sum := add(sum, mload(add(add(data, 0x20), mul(i, 0x20))))\n }\n }\n }\n\n // Same as above, but accomplish the entire code within inline assembly.\n function sumPureAsm(uint[] memory data) public pure returns (uint sum) {\n assembly {\n // Load the length (first 32 bytes)\n let len := mload(data)\n\n // Skip over the length field.\n //\n // Keep temporary variable so it can be incremented in place.\n //\n // NOTE: incrementing data would result in an unusable\n // data variable after this assembly block\n let dataElementLocation := add(data, 0x20)\n\n // Iterate until the bound is not met.\n for\n { let end := add(dataElementLocation, mul(len, 0x20)) }\n lt(dataElementLocation, end)\n { dataElementLocation := add(dataElementLocation, 0x20) }\n {\n sum := add(sum, mload(dataElementLocation))\n }\n }\n }\n}\n\nAccess to External Variables, Functions and Libraries\nYou can access Solidity variables and other identifiers by using their name.\nLocal variables of value type are directly usable in inline assembly.\nThey can both be read and assigned to.\nLocal variables that refer to memory evaluate to the address of the variable in memory, not the value itself.\nSuch variables can also be assigned to, but note that an assignment will only change the pointer and not the data\nand that it is your responsibility to respect Solidity’s memory management.\nSee Conventions in Solidity.\nSimilarly, local variables that refer to statically-sized calldata arrays or calldata structs\nevaluate to the address of the variable in calldata, not the value itself.\nThe variable can also be assigned a new offset, but note that no validation is performed to ensure that\nthe variable will not point beyond calldatasize().\nFor external function pointers the address and the function selector can be\naccessed using x.address and x.selector.\nThe selector consists of four right-aligned bytes.\nBoth values can be assigned to. For example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.10 <0.9.0;\n\ncontract C {\n // Assigns a new selector and address to the return variable @fun\n function combineToFunctionPointer(address newAddress, uint newSelector) public pure returns (function() external fun) {\n assembly {\n fun.selector := newSelector\n fun.address := newAddress\n }\n }\n}\n\nFor dynamic calldata arrays, you can access\ntheir calldata offset (in bytes) and length (number of elements) using x.offset and x.length.\nBoth expressions can also be assigned to, but as for the static case, no validation will be performed\nto ensure that the resulting data area is within the bounds of calldatasize().\nFor local storage variables or state variables (including transient storage) a single Yul identifier\nis not sufficient, since they do not necessarily occupy a single full storage slot.\nTherefore, their “address” is composed of a slot and a byte-offset\ninside that slot. To retrieve the slot pointed to by the variable x, you\nuse x.slot, and to retrieve the byte-offset you use x.offset.\nUsing x itself will result in an error.\nYou can also assign to the .slot part of a local storage variable pointer.\nFor these (structs, arrays or mappings), the .offset part is always zero.\nIt is not possible to assign to the .slot or .offset part of a state variable,\nthough.\nLocal Solidity variables are available for assignments, for example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.28 <0.9.0;\n\n// This will report a warning\ncontract C {\n bool transient a;\n uint b;\n function f(uint x) public returns (uint r) {\n assembly {\n // We ignore the storage slot offset, we know it is zero\n // in this special case.\n r := mul(x, sload(b.slot))\n tstore(a.slot, true)\n }\n }\n}\n\nWarning\nIf you access variables of a type that spans less than 256 bits\n(for example uint64, address, or bytes16),\nyou cannot make any assumptions about bits not part of the\nencoding of the type. Especially, do not assume them to be zero.\nTo be safe, always clear the data properly before you use it\nin a context where this is important:\nuint32 x = f(); assembly { x := and(x, 0xffffffff) /* now use x */ }\nTo clean signed types, you can use the signextend opcode:\nassembly { signextend(<num_bytes_of_x_minus_one>, x) }\n\nSince Solidity 0.6.0, the name of an inline assembly variable may not\nshadow any declaration visible in the scope of the inline assembly block\n(including variable, contract and function declarations).\nSince Solidity 0.7.0, variables and functions declared inside the\ninline assembly block may not contain ., but using . is\nvalid to access Solidity variables from outside the inline assembly block.\nHowever, it is still valid to use dots if you use Solidity in Yul-only mode.\n\nThings to Avoid\nInline assembly might have a quite high-level look, but it actually is extremely\nlow-level. Function calls, loops, ifs and switches are converted by simple\nrewriting rules and after that, the only thing the assembler does for you is re-arranging\nfunctional-style opcodes, counting stack height for\nvariable access and removing stack slots for assembly-local variables when the end\nof their block is reached.\n\nConventions in Solidity\n\nValues of Typed Variables\nIn contrast to EVM assembly, Solidity has types which are narrower than 256 bits,\ne.g. uint24. For efficiency, most arithmetic operations ignore the fact that\ntypes can be shorter than 256\nbits, and the higher-order bits are cleaned when necessary,\ni.e., shortly before they are written to memory or before comparisons are performed.\nThis means that if you access such a variable\nfrom within inline assembly, you might have to manually clean the higher-order bits\nfirst.\n\nMemory Management\nSolidity manages memory in the following way. There is a “free memory pointer”\nat position 0x40 in memory. If you want to allocate memory, use the memory\nstarting from where this pointer points at and update it.\nThere is no guarantee that the memory has not been used before and thus\nyou cannot assume that its contents are zero bytes.\nThere is no built-in mechanism to release or free allocated memory.\nSolidity does not guarantee and does not require that the values in memory\nare placed at positions aligned to a multiple of any value.\nHere is an assembly snippet you can use for allocating memory that follows the process outlined above:\nopen in Remix\nfunction allocate(length) -> pos {\n pos := mload(0x40)\n mstore(0x40, add(pos, length))\n}\n\nThe first 64 bytes of memory can be used as “scratch space” for short-term\nallocation. The 32 bytes after the free memory pointer (i.e., starting at 0x60)\nare meant to be zero permanently and is used as the initial value for\nempty dynamic memory arrays.\nThis means that the allocatable memory starts at 0x80, which is the initial value\nof the free memory pointer.\nElements in memory arrays in Solidity always occupy multiples of 32 bytes (this is\neven true for bytes1[], but not for bytes and string). Multi-dimensional memory\narrays are pointers to memory arrays. The length of a dynamic array is stored at the\nfirst slot of the array and followed by the array elements.\n\nWarning\nStatically-sized memory arrays do not have a length field, but it might be added later\nto allow better convertibility between statically and dynamically-sized arrays; so,\ndo not rely on this.\n\nMemory Safety\nWithout the use of inline assembly, the compiler can rely on memory to remain in a well-defined\nstate at all times. This is especially relevant for the new code generation pipeline via Yul IR:\nthis code generation path can move local variables from stack to memory to avoid stack-too-deep errors and\nperform additional memory optimizations, if it can rely on certain assumptions about memory use.\nWhile we recommend to always respect Solidity’s memory model, inline assembly allows you to use memory\nin an incompatible way. Therefore, moving stack variables to memory and additional memory optimizations are,\nby default, globally disabled in the presence of any inline assembly block that contains a memory operation\nor assigns to Solidity variables in memory.\nHowever, you can specifically annotate an assembly block to indicate that it in fact respects Solidity’s memory\nmodel as follows:\nopen in Remix\nassembly (\"memory-safe\") {\n ...\n}\n\nIn particular, a memory-safe assembly block may only access the following memory ranges:\n\nMemory allocated by yourself using a mechanism like the allocate function described above.\nMemory allocated by Solidity, e.g. memory within the bounds of a memory array you reference.\nThe scratch space between memory offset 0 and 64 mentioned above.\nTemporary memory that is located after the value of the free memory pointer at the beginning of the assembly block,\ni.e. memory that is “allocated” at the free memory pointer without updating the free memory pointer.\n\nFurthermore, if the assembly block assigns to Solidity variables in memory, you need to assure that accesses to\nthe Solidity variables only access these memory ranges.\nSince this is mainly about the optimizer, these restrictions still need to be followed, even if the assembly block\nreverts or terminates. As an example, the following assembly snippet is not memory safe, because the value of\nreturndatasize() may exceed the 64 byte scratch space:\nopen in Remix\nassembly {\n returndatacopy(0, 0, returndatasize())\n revert(0, returndatasize())\n}\n\nOn the other hand, the following code is memory safe, because memory beyond the location pointed to by the\nfree memory pointer can safely be used as temporary scratch space:\nopen in Remix\nassembly (\"memory-safe\") {\n let p := mload(0x40)\n returndatacopy(p, 0, returndatasize())\n revert(p, returndatasize())\n}\n\nNote that you do not need to update the free memory pointer if there is no following allocation,\nbut you can only use memory starting from the current offset given by the free memory pointer.\nIf the memory operations use a length of zero, it is also fine to just use any offset (not only if it falls into the scratch space):\nopen in Remix\nassembly (\"memory-safe\") {\n revert(0, 0)\n}\n\nNote that not only memory operations in inline assembly itself can be memory-unsafe, but also assignments to\nSolidity variables of reference type in memory. For example the following is not memory-safe:\nopen in Remix\nbytes memory x;\nassembly {\n x := 0x40\n}\nx[0x20] = 0x42;\n\nInline assembly that neither involves any operations that access memory nor assigns to any Solidity variables\nin memory is automatically considered memory-safe and does not need to be annotated.\n\nWarning\nIt is your responsibility to make sure that the assembly actually satisfies the memory model. If you annotate\nan assembly block as memory-safe, but violate one of the memory assumptions, this will lead to incorrect and\nundefined behavior that cannot easily be discovered by testing.\n\nIn case you are developing a library that is meant to be compatible across multiple versions\nof Solidity, you can use a special comment to annotate an assembly block as memory-safe:\nopen in Remix\n/// @solidity memory-safe-assembly\nassembly {\n ...\n}\n\nWarning\nThe memory-safe-assembly special comment is deprecated and scheduled for removal.\nIn new code targeting recent compilers, use the assembly block annotation.\n\nAdvanced Safe Use of Memory\nBeyond the strict definition of memory-safety given above, there are cases in which you may want to use more than 64 bytes\nof scratch space starting at memory offset 0. If you are careful, it can be admissible to use memory up to (and not\nincluding) offset 0x80 and still safely declare the assembly block as memory-safe.\nThis is admissible under either of the following conditions:\n\nBy the end of the assembly block, the free memory pointer at offset 0x40 is restored to a sane value (i.e. it is either\nrestored to its original value or an increment of it due to a manual memory allocation), and the memory word at offset 0x60\nis restored to a value of zero.\nThe assembly block terminates, i.e. execution can never return to high-level Solidity code. This is the case, for example,\nif your assembly block unconditionally ends in calling the revert opcode.\n\nFurthermore, you need to be aware that the default-value of dynamic arrays in Solidity point to memory offset 0x60, so\nfor the duration of temporarily changing the value at memory offset 0x60, you can no longer rely on getting accurate\nlength values when reading dynamic arrays, until you restore the zero value at 0x60. To be more precise, we only guarantee\nsafety when overwriting the zero pointer, if the remainder of the assembly snippet does not interact with the memory of\nhigh-level Solidity objects (including by reading from offsets previously stored in variables).","tokens":3908,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264382650,"hash":"69482a707adf97f3dc2333215169cc807cb78e8f"}
{"url":"https://ethereum.org/developers/docs/consensus-mechanisms/pos/","domain":"ethereum.org","title":"Proof-of-stake (PoS) | ethereum.org","text":"Proof-of-stake (PoS)Edit page (opens in a new tab)Proof-of-stake (PoS) underlies Ethereum's consensus mechanism. Ethereum switched on its proof-of-stake mechanism in 2022 because it is more secure, less energy-intensive, and better for implementing new scaling solutions compared to the previous proof-of-work architecture.\nPrerequisites\nTo better understand this page, we recommend you first read up on consensus mechanisms.\nWhat is proof-of-stake (PoS)?\nProof-of-stake is a way to prove that validators have put something of value into the network that can be destroyed if they act dishonestly. In Ethereum's proof-of-stake, validators explicitly stake capital in the form of ETH into a smart contract on Ethereum. The validator is then responsible for checking that new blocks propagated over the network are valid and occasionally creating and propagating new blocks themselves. If they try to defraud the network (for example by proposing multiple blocks when they ought to send one or sending conflicting attestations), some or all of their staked ETH can be destroyed.\nValidators\nTo participate as a validator, a user must deposit 32 ETH into the deposit contract and run three separate pieces of software: an execution client, a consensus client, and a validator client. On depositing their ETH, the user joins an activation queue that limits the rate of new validators joining the network. Once activated, validators receive new blocks from peers on the Ethereum network. The transactions delivered in the block are re-executed to check that the proposed changes to Ethereum's state are valid, and the block signature is checked. The validator then sends a vote (called an attestation) in favor of that block across the network.\nWhereas under proof-of-work, the timing of blocks is determined by the mining difficulty, in proof-of-stake, the tempo is fixed. Time in proof-of-stake Ethereum is divided into slots (12 seconds) and epochs (32 slots). One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed. Dividing the validator set up into committees is important for keeping the network load manageable. Committees divide up the validator set so that every active validator attests in every epoch, but not in every slot.\nHow a Transaction Gets Executed in Ethereum PoS\nThe following provides an end-to-end explanation of how a transaction gets executed in Ethereum proof-of-stake.\n\nA user creates and signs a transaction with their private key. This is usually handled by a wallet or a library such as ethers.js (opens in a new tab), web3js (opens in a new tab), web3py (opens in a new tab) etc but under the hood the user is making a request to a node using the Ethereum JSON-RPC API. The user defines the amount of gas that they are prepared to pay as a tip to a validator to encourage them to include the transaction in a block. The tips get paid to the validator while the base fee gets burned.\nThe transaction is submitted to an Ethereum execution client which verifies its validity. This means ensuring that the sender has enough ETH to fulfill the transaction and they have signed it with the correct key.\nIf the transaction is valid, the execution client adds it to its local mempool (list of pending transactions) and also broadcasts it to other nodes over the execution layer gossip network. When other nodes hear about the transaction they add it to their local mempool too. Advanced users might refrain from broadcasting their transaction and instead forward it to specialized block builders such as Flashbots Auction (opens in a new tab). This allows them to organize the transactions in upcoming blocks for maximum profit (MEV).\nOne of the validator nodes on the network is the block proposer for the current slot, having previously been selected pseudo-randomly using RANDAO. This node is responsible for building and broadcasting the next block to be added to the Ethereum blockchain and updating the global state. The node is made up of three parts: an execution client, a consensus client and a validator client. The execution client bundles transactions from the local mempool into an \"execution payload\" and executes them locally to generate a state change. This information is passed to the consensus client where the execution payload is wrapped as part of a \"beacon block\" that also contains information about rewards, penalties, slashings, attestations etc. that enable the network to agree on the sequence of blocks at the head of the chain. The communication between the execution and consensus clients is described in more detail in Connecting the Consensus and Execution Clients.\nOther nodes receive the new beacon block on the consensus layer gossip network. They pass it to their execution client where the transactions are re-executed locally to ensure the proposed state change is valid. The validator client then attests that the block is valid and is the logical next block in their view of the chain (meaning it builds on the chain with the greatest weight of attestations as defined in the fork choice rules). The block is added to the local database in each node that attests to it.\nThe transaction can be considered \"finalized\" if it has become part of a chain with a \"supermajority link\" between two checkpoints. Checkpoints occur at the start of each epoch and they exist to account for the fact that only a subset of active validators attest in each slot, but all active validators attest across each epoch. Therefore, it is only between epochs that a 'supermajority link' can be demonstrated (this is where 66% of the total staked ETH on the network agrees on two checkpoints).\n\nMore detail on finality can be found below.\nFinality\nA transaction has \"finality\" in distributed networks when it is part of a block that can't change without a large amount of ETH getting burned. On proof-of-stake Ethereum, this is managed using \"checkpoint\" blocks. The first block in each epoch is a checkpoint. Validators vote for pairs of checkpoints that it considers to be valid. If a pair of checkpoints attracts votes representing at least two-thirds of the total staked ETH, the checkpoints are upgraded. The more recent of the two (target) becomes \"justified\". The earlier of the two is already justified because it was the \"target\" in the previous epoch. Now it is upgraded to \"finalized\". This process of upgrading the checkpoints is handled by Casper the Friendly Finality Gadget (Casper-FFG) (opens in a new tab). Casper-FFG is a block finality tool for consensus. Once a block is finalized, it cannot be reverted or changed without a majority slashing of stakers, making it economically inviable.\nTo revert a finalized block, an attacker would commit to losing at least one-third of the total supply of staked ETH. The exact reason for this is explained in this Ethereum Foundation blog post (opens in a new tab). Since finality requires a two-thirds majority, an attacker could prevent the network from reaching finality by voting with one-third of the total stake. There is a mechanism to defend against this: the inactivity leak (opens in a new tab). This activates whenever the chain fails to finalize for more than four epochs. The inactivity leak bleeds away the staked ETH from validators voting against the majority, allowing the majority to regain a two-thirds majority and finalize the chain.\nCrypto-economic security\nRunning a validator is a commitment. The validator is expected to maintain sufficient hardware and connectivity to participate in block validation and proposal. In return, the validator is paid in ETH (their staked balance increases). On the other hand, participating as a validator also opens new avenues for users to attack the network for personal gain or sabotage. To prevent this, validators miss out on ETH rewards if they fail to participate when called upon, and their existing stake can be destroyed if they behave dishonestly. Two primary behaviors can be considered dishonest: proposing multiple blocks in a single slot (equivocating) and submitting contradictory attestations.\nThe amount of ETH slashed depends on how many validators are also being slashed at around the same time. This is known as the \"correlation penalty\" (opens in a new tab), and it can be minor (less than 0.1% stake for a single validator slashed on their own) or can result in 100% of the validator's stake getting destroyed (mass slashing event). It is imposed halfway through a forced exit period that begins with an immediate penalty (1/4096 of the validator's effective balance, up to 0.5 ETH) on Day 1, the correlation penalty on Day 18, and finally, ejection from the network on Day 36. They receive minor attestation penalties every day because they are present on the network but not submitting votes. This all means a coordinated attack would be very costly for the attacker.\nFork choice\nWhen the network performs optimally and honestly, there is only ever one new block at the head of the chain, and all validators attest to it. However, it is possible for validators to have different views of the head of the chain due to network latency or because a block proposer has equivocated. Therefore, consensus clients require an algorithm to decide which one to favor. The algorithm used in proof-of-stake Ethereum is called LMD-GHOST (opens in a new tab), and it works by identifying the fork that has the greatest weight of attestations in its history.\nProof-of-stake and security\nThe threat of a 51% attack (opens in a new tab) still exists on proof-of-stake as it does on proof-of-work, but it's even riskier for the attackers. An attacker would need 51% of the staked ETH. They could then use their own attestations to ensure their preferred fork was the one with the most accumulated attestations. The 'weight' of accumulated attestations is what consensus clients use to determine the correct chain, so this attacker would be able to make their fork the canonical one. However, a strength of proof-of-stake over proof-of-work is that the community has flexibility in mounting a counter-attack. For example, the honest validators could decide to keep building on the minority chain and ignore the attacker's fork while encouraging apps, exchanges, and pools to do the same. They could also decide to forcibly remove the attacker from the network and destroy their staked ETH. These are strong economic defenses against a 51% attack.\nBeyond 51% attacks, bad actors might also attempt other types of malicious activities, such as:\n\nlong-range attacks (although the finality gadget neutralizes this attack vector)\nshort range 'reorgs' (although proposer boosting and attestation deadlines mitigate this)\nbouncing and balancing attacks (also mitigated by proposer boosting, and these attacks have anyway only been demonstrated under idealized network conditions)\navalanche attacks (neutralized by the fork choice algorithms rule of only considering the latest message)\n\nOverall, proof-of-stake, as it is implemented on Ethereum, has been demonstrated to be more economically secure than proof-of-work.\nPros and cons\nProsConsStaking makes it easier for individuals to participate in securing the network, promoting decentralization. validator node can be run on a normal laptop. Staking pools allow users to stake without having 32 ETH.Proof-of-stake is younger and less battle-tested compared to proof-of-workStaking is more decentralized. Economies of scale do not apply in the same way that they do for PoW mining.Proof-of-stake is more complex to implement than proof-of-workProof-of-stake offers greater crypto-economic security than proof-of-workUsers need to run three pieces of software to participate in Ethereum's proof-of-stake.Less issuance of new ETH is required to incentivize network participants\nComparison to proof-of-work\nEthereum originally used proof-of-work but switched to proof-of-stake in September 2022. PoS offers several advantages over PoW, such as:\n\nbetter energy efficiency – there is no need to use lots of energy on proof-of-work computations\nlower barriers to entry, reduced hardware requirements – there is no need for elite hardware to stand a chance of creating new blocks\nreduced centralization risk – proof-of-stake should lead to more nodes securing the network\nbecause of the low energy requirement less ETH issuance is required to incentivize participation\neconomic penalties for misbehavior make 51% style attacks more costly for an attacker compared to proof-of-work\nthe community can resort to social recovery of an honest chain if a 51% attack were to overcome the crypto-economic defenses.\n\nFurther reading\n\nProof of Stake FAQ (opens in a new tab) Vitalik Buterin\nWhat is Proof of Stake (opens in a new tab) ConsenSys\nWhat Proof of Stake Is And Why It Matters (opens in a new tab) Vitalik Buterin\nWhy Proof of Stake (Nov 2020) (opens in a new tab) Vitalik Buterin\nProof of Stake: How I Learned to Love Weak Subjectivity (opens in a new tab) Vitalik Buterin\nProof-of-stake Ethereum attack and defense (opens in a new tab)\nA Proof of Stake Design Philosophy (opens in a new tab) Vitalik Buterin\nVideo: Vitalik Buterin explains proof-of-stake to Lex Fridman (opens in a new tab)\n\nRelated topics\n\nProof-of-work\nProof-of-authority\n\nTest your Ethereum knowledgeProof-of-stakeQuestion number 1:A validator tries to defraud the network by proposing conflicting blocks. What does the protocol do?","tokens":3416,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264382751,"hash":"77ef005e79630503af453ed7bb6997db49d1dc27"}
{"url":"https://governance.aave.com/t/recovery-request-accidentally-sent-25k-usdc-directly-to-aave-v3-pool/25309","domain":"governance.aave.com","title":"[Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool - Other - Aave","text":"[Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool \n\n Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 13\n\n 1 / 3\n\n Jul 14\n\n Jul 13\n\n post by stoneseen on Jul 13\n\n stoneseen\n\n Hi all,\nOn July 12nd, I mistakenly sent 25,000 USDC directly to the Aave V3 Pool contract on ETH instead of supplying via the interface.\n\nTx hash: 0x6a4cd27125fe4916909efdb9e6cc79f298ce514e56bd4851e92641f71c666b5c\nPool proxy address: 0x98c23e9d8f34fefb1b7bd6a91b7ff122f4e16f5c\nSending wallet: 0x32fcf748e4dcebd1081bfcccb94eb721101f27c0 (I can sign a message to prove ownership)\n\nI understand from Rescue Mission Phases 1–3 that recovery of tokens sent directly to upgradeable Aave contracts is technically feasible via a governance-approved implementation upgrade, with claims distributed through the AaveMerkleDistributor to the original sending address.\nRequest to BGD Labs / ACI / the community: could this transfer be registered for inclusion in a future rescue phase covering the V3 Pool? Happy to provide any additional verification needed.\nThank you.\n\n Unlisted on Jul 13\n\n Listed on Jul 14\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase\n\n Development\n\n 0\n\n 115\n\n Jul 14\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d","tokens":433,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264389267,"hash":"b85d72d938e3cb045e3fc5c3fc97032e113ccd8a"}
{"url":"https://ethereum.org/developers/docs/evm/","domain":"ethereum.org","title":"Ethereum Virtual Machine (EVM) | ethereum.org","text":"Ethereum Virtual Machine (EVM)Edit page (opens in a new tab)The Ethereum Virtual Machine (EVM) is a decentralized virtual environment that executes code consistently and securely across all Ethereum nodes. Nodes run the EVM to execute smart contracts, using \"gas\" to measure the computational effort required for operations, ensuring efficient resource allocation and network security.\nPrerequisites\nSome basic familiarity with common terminology in computer science such as bytes (opens in a new tab), memory (opens in a new tab), and a stack (opens in a new tab) are necessary to understand the EVM. It would also be helpful to be comfortable with cryptography/blockchain concepts like hash functions (opens in a new tab) and the Merkle tree (opens in a new tab).\nFrom ledger to state machine\nThe analogy of a 'distributed ledger' is often used to describe blockchains like Bitcoin, which enable a decentralized currency using fundamental tools of cryptography. The ledger maintains a record of activity which must adhere to a set of rules that govern what someone can and cannot do to modify the ledger. For example, a Bitcoin address cannot spend more Bitcoin than it has previously received. These rules underpin all transactions on Bitcoin and many other blockchains.\nWhile Ethereum has its own native cryptocurrency (ether) that follows almost exactly the same intuitive rules, it also enables a much more powerful function: smart contracts. For this more complex feature, a more sophisticated analogy is required. Instead of a distributed ledger, Ethereum is a distributed state machine (opens in a new tab). Ethereum's state is a large data structure which holds not only all accounts and balances, but a machine state, which can change from block to block according to a pre-defined set of rules, and which can execute arbitrary machine code. The specific rules of changing state from block to block are defined by the EVM.\n\nDiagram adapted from Ethereum EVM illustrated (opens in a new tab)\nThe Ethereum state transition function\nThe EVM behaves as a mathematical function would: Given an input, it produces a deterministic output. It therefore is quite helpful to more formally describe Ethereum as having a state transition function:\nY(S, T)= S'\n\nGiven an old valid state (S) and a new set of valid transactions (T), the Ethereum state transition function Y(S, T) produces a new valid output state S'\nState\nIn the context of Ethereum, the state is an enormous data structure called a modified Merkle Patricia Trie, which keeps all accounts linked by hashes and reducible to a single root hash stored on the blockchain.\nTransactions\nTransactions are cryptographically signed instructions from accounts. There are two types of transactions: those which result in message calls and those which result in contract creation.\nContract creation results in the creation of a new contract account containing compiled smart contract bytecode. Whenever another account makes a message call to that contract, it executes its bytecode.\nEVM instructions\nThe EVM executes as a stack machine (opens in a new tab) with a depth of 1024 items. Each item is a 256-bit word, which was chosen for the ease of use with 256-bit cryptography (such as Keccak-256 hashes or secp256k1 signatures).\nDuring execution, the EVM maintains a transient memory (as a word-addressed byte array), which does not persist between transactions.\nTransient storage\nTransient storage is a per-transaction key–value store accessed through the TSTORE and TLOAD opcodes. It persists across all internal calls during the same transaction but is cleared at the end of the transaction. Unlike memory, transient storage is modeled as part of the EVM state rather than the execution frame, yet it is not committed to the global state. Transient storage enables gas-efficient temporary state sharing across internal calls during a transaction.\nStorage\nContracts contain a Merkle Patricia storage trie (as a word-addressable word array), associated with the account in question and part of the global state. This persistent storage differs from transient storage, which is available only for the duration of a single transaction and does not form part of the account's persistent storage trie.\nOpcodes\nCompiled smart contract bytecode executes as a number of EVM opcodes, which perform standard stack operations like XOR, AND, ADD, SUB, etc. The EVM also implements a number of blockchain-specific stack operations, such as ADDRESS, BALANCE, BLOCKHASH, etc. The opcode set also includes TSTORE and TLOAD, which provide access to transient storage.\n\nDiagrams adapted from Ethereum EVM illustrated (opens in a new tab)\nEVM implementations\nAll implementations of the EVM must adhere to the specification described in the Ethereum Yellowpaper.\nOver Ethereum's ten year history, the EVM has undergone several revisions, and there are several implementations of the EVM in various programming languages.\nEthereum execution clients include an EVM implementation. Additionally, there are multiple standalone implementations, including:\n\nPy-EVM (opens in a new tab) - Python\nevmone (opens in a new tab) - C++\nethereumjs-vm (opens in a new tab) - JavaScript\nrevm (opens in a new tab) - Rust\n\nFurther Reading\n\nEthereum Yellowpaper (opens in a new tab)\nJellopaper aka KEVM: Semantics of EVM in K (opens in a new tab)\nThe Beigepaper (opens in a new tab)\nEthereum Virtual Machine Opcodes (opens in a new tab)\nEthereum Virtual Machine Opcodes Interactive Reference (opens in a new tab)\nA short introduction in Solidity's documentation (opens in a new tab)\nMastering Ethereum - The Ethereum Virtual Machine (opens in a new tab)\n\nRelated Topics\n\nGas\n\nTutorials: Ethereum Virtual Machine (EVM) / Opcodes on Ethereum\n\nUnderstanding the Yellow Paper's EVM Specifications – A guided walkthrough of the formal EVM spec from the Ethereum Yellow Paper.\nReverse Engineering a Contract – How to reverse-engineer a compiled smart contract using EVM opcodes.\n\nTest your Ethereum knowledgeEthereum Virtual Machine (EVM)Question number 1:Ethereum has two kinds of transactions. What separates them?","tokens":1532,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264392948,"hash":"a990532b487bccf07f816dc95bb3ef13321c9658"}
{"url":"https://governance.aave.com/t/request-include-25k-usdc-sent-directly-to-v3-pool-in-next-rescue-mission-phase/25317/1","domain":"governance.aave.com","title":"Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase - Development - Aave","text":"Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase \n\n Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by gl2361 on Jul 14\n\n gl2361\n\n Hi all,\nOn [date] I mistakenly sent 25,000 USDC directly to the Aave V3 Pool contract on [network] instead of supplying via the interface.\n\nTx hash: 0x6a4cd27125fe4916909efdb9e6cc79f298ce514e56bd4851e92641f71c666b5c\nPool proxy address: 0x98c23e9d8f34fefb1b7bd6a91b7ff122f4e16f5c\nSending wallet: 0x32fcf748e4dcebd1081bfcccb94eb721101f27c0 (I can sign a message to prove ownership)\n\nI understand from Rescue Mission Phases 1–3 that recovery of tokens sent directly to upgradeable Aave contracts is technically feasible via a governance-approved implementation upgrade, with claims distributed through the AaveMerkleDistributor to the original sending address.\nRequest to BGD Labs / ACI / the community: could this transfer be registered for inclusion in a future rescue phase covering the V3 Pool? Happy to provide any additional verification needed.\nThank you.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n Rescue of wrong sent tokens\n\n Governance\n\n 0\n\n 47\n\n Aug 13\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d","tokens":404,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264399510,"hash":"6db1301d063c7a8a29058223d919a2cbf19200a8"}
{"url":"https://ethereum.org/developers/docs/networks/","domain":"ethereum.org","title":"Networks | ethereum.org","text":"NetworksEdit page (opens in a new tab)Ethereum networks are groups of connected computers that communicate using the Ethereum protocol. There is only one Ethereum Mainnet, but independent networks conforming to the same protocol rules can be created for testing and development purposes. There are many independent \"networks\" that conform to the protocol without interacting with each other. You can even start one locally on your own computer for testing your smart contracts and web3 apps.\nYour Ethereum account will work across the different networks, but your account balance and transaction history won't carry over from the main Ethereum network. For testing purposes, it's useful to know which networks are available and how to get testnet ETH to play around with. In general, for security considerations, it's not recommended to reuse mainnet accounts on testnets or vice versa.\nPrerequisites\nYou should understand the basics of Ethereum before reading up on the different networks, as the test networks will give you a cheap, safe version of Ethereum to play around with.\nPublic networks\nPublic networks are accessible to anyone in the world with an internet connection. Anyone can read or create transactions on a public blockchain and validate the transactions being executed. The consensus among peers decides on the inclusion of transactions and the state of the network.\nEthereum Mainnet\nMainnet is the primary public Ethereum production blockchain, where actual-value transactions occur on the distributed ledger.\nWhen people and exchanges discuss ETH prices, they're talking about Mainnet ETH.\nEthereum Testnets\nIn addition to Mainnet, there are public testnets. These are networks used by protocol developers or smart contract developers to test both protocol upgrades as well as potential smart contracts in a production-like environment before deployment to Mainnet. Think of this as an analog to production versus staging servers.\nYou should test any contract code you write on a testnet before deploying to Mainnet. Among dapps that integrate with existing smart contracts, most projects have copies deployed to testnets.\nMost testnets started by using a permissioned proof-of-authority consensus mechanism. This means a small number of nodes are chosen to validate transactions and create new blocks – staking their identity in the process. Alternatively, some testnets feature an open proof-of-stake consensus mechanism where everyone can test running a validator, just like Ethereum Mainnet.\nETH on testnets is supposed to have no real value; however, there have been markets created for certain types of testnet ETH that have become scarce or hard to obtain. Since you need ETH to actually interact with Ethereum (even on testnets), most people get testnet ETH for free from faucets. Most faucets are webapps where you can input an address which you request ETH to be sent to.\nWhich Testnet should I use?\nThe two public testnets that client developers are currently maintaining are Sepolia and Hoodi. Sepolia is a network for contract and application developers to test their applications. The Hoodi network lets protocol developers test network upgrades, and lets stakers test running validators.\nSepolia\nSepolia is the recommended default testnet for application development. The Sepolia network uses a permissioned validator set controlled by client & testing teams.\nResources\n\nWebsite (opens in a new tab)\nGitHub (opens in a new tab)\nOtterscan (opens in a new tab)\nEtherscan (opens in a new tab)\nBlockscout (opens in a new tab)\n\nFaucets\n\nAlchemy Sepolia Faucet (opens in a new tab)\nChain Platform Sepolia Faucet (opens in a new tab)\nChainstack Sepolia Faucet (opens in a new tab)\nethfaucet.com Sepolia Faucet (opens in a new tab)\nGoogle Cloud Web3 Sepolia Faucet (opens in a new tab)\nGrabteeth (opens in a new tab)\nInfura Sepolia Faucet (opens in a new tab)\nOpenFaucet.org Sepolia Faucet (opens in a new tab)\nPoW Faucet (opens in a new tab)\nQuickNode Sepolia Faucet (opens in a new tab)\n\nHoodi\nHoodi is a testnet for testing validating and staking. The Hoodi network is open for users wanting to run a testnet validator. Stakers wanting to test protocol upgrades before they are deployed to mainnet should therefore use Hoodi.\n\nOpen validator set, stakers can test network upgrades\nLarge state, useful for testing complex smart contract interactions\nLonger to sync and requires more storage to run a node\n\nResources\n\nWebsite (opens in a new tab)\nGitHub (opens in a new tab)\nExplorer (opens in a new tab)\nCheckpoint Sync (opens in a new tab)\nOtterscan (opens in a new tab)\nEtherscan (opens in a new tab)\n\nFaucets\n\nChain Platform Hoodi Faucet (opens in a new tab)\nHoodi Faucet (opens in a new tab)\nOpenFaucet.org Hoodi Faucet (opens in a new tab)\nPoW Faucet (opens in a new tab)\n\nEphemery\nEphemery is a unique kind of testnet that fully resets every month. The execution and consensus state reverts back to genesis every 28 days, which means anything that happens on the testnet is ephemeral. This makes it ideal for a short term testing, fast node bootstrap and 'hello world' kind of applications that don't need permanence.\n\nAlways fresh state, short term testing of validators and apps\nIncludes only basic set of contracts\nOpen validator set and easy to access large amounts of funds\nSmallest node requirements and quickest sync, <5GB on average\n\nResources\n\nWebsite (opens in a new tab)\nGitHub (opens in a new tab)\nCommunity chat (opens in a new tab)\nBlockscout (opens in a new tab)\nOtterscan (opens in a new tab)\nBeacon explorer (opens in a new tab)\nCheckpoint Sync (opens in a new tab)\nLaunchpad (opens in a new tab)\n\nFaucets\n\nBordel Faucet (opens in a new tab)\nPk910 PoW Faucet (opens in a new tab)\n\nHolesky (deprecated)\nThe Holesky testnet is deprecated as of September 2025. Staking operators and infrastructure providers should use Hoodi for validator testing instead.\n\nHolesky Testnet Shutdown Announcement (opens in a new tab) - EF Blog, 1-September-2025\nHolesky and Hoodi Testnet Updates (opens in a new tab) - EF Blog, 18-March-2025\n\nLayer 2 testnets\nLayer 2 (L2) is a collective term to describe a specific set of Ethereum scaling solutions. A layer 2 is a separate blockchain that extends Ethereum and inherits the security guarantees of Ethereum. Layer 2 testnets are usually tightly coupled to public Ethereum testnets.\nArbitrum Sepolia\nA testnet for Arbitrum (opens in a new tab).\nResources\n\nEtherscan (opens in a new tab)\nBlockscout (opens in a new tab)\n\nFaucets\n\nAlchemy Arbitrum Sepolia Faucet (opens in a new tab)\nChainlink Arbitrum Sepolia faucet (opens in a new tab)\nethfaucet.com Arbitrum Sepolia Faucet (opens in a new tab)\nOpenFaucet.org Arbitrum Sepolia Faucet (opens in a new tab)\nQuickNode Arbitrum Sepolia Faucet (opens in a new tab)\n\nOptimistic Sepolia\nA testnet for Optimism (opens in a new tab).\nResources\n\nEtherscan (opens in a new tab)\nBlockscout (opens in a new tab)\n\nFaucets\n\nAlchemy Faucet (opens in a new tab)\nChainlink Faucet (opens in a new tab)\nethfaucet.com Optimism Sepolia Faucet (opens in a new tab)\nOpenFaucet.org Optimism Sepolia Faucet (opens in a new tab)\nTestnet Faucet (opens in a new tab)\n\nStarknet Sepolia\nA testnet for Starknet (opens in a new tab).\nResources\n\nVoyager Sepolia Scan (opens in a new tab)\n\nFaucets\n\nAlchemy Faucet (opens in a new tab)\nBlast Starknet Sepolia Faucet (opens in a new tab)\nStarknet Faucet (opens in a new tab)\n\nPrivate networks\nAn Ethereum network is a private network if its nodes are not connected to a public network (i.e., Mainnet or a testnet). In this context, private only means reserved or isolated, rather than protected or secure.\nDevelopment networks\nTo develop an Ethereum application, you'll want to run it on a private network to see how it works before deploying it. Similar to how you create a local server on your computer for web development, you can create a local blockchain instance to test your dapp. This allows for much faster iteration than a public testnet.\nThere are projects and tools dedicated to assist with this. Learn more about development networks.\nConsortium networks\nThe consensus process is controlled by a pre-defined set of nodes that are trusted. For example, a private network of known academic institutions that each govern a single node, and blocks are validated by a threshold of signatories within the network.\nIf a public Ethereum network is like the public internet, a consortium network is like a private intranet.\n Why are Ethereum testnets named after metro stations?\nMany Ethereum testnets are named after real-world metro or train stations. This naming tradition started early and reflects the global cities where contributors have lived or worked. It's symbolic, memorable, and practical. Just like testnets are isolated from Ethereum mainnet, metro lines run separately from surface traffic.\n Commonly used and legacy testnets\n\nSepolia - A metro-linked neighborhood in Athens, Greece. Currently used for smart contract and dApp testing.\nHoodi - Named after Hoodi metro station in Bengaluru, India. Used for validator and protocol upgrade testing.\nGoerli (deprecated) - Named after Görlitzer Bahnhof in Berlin, Germany.\nRinkeby (deprecated) - Named after a Stockholm suburb with a metro station.\nRopsten (deprecated) - Refers to an area and former ferry/metro terminal in Stockholm.\nKovan (deprecated) - Named after a Singapore MRT station.\nMorden (deprecated) - Named after a London Underground station. Ethereum’s first public testnet.\n\n Other specialized testnets\nSome testnets were created for short-term or upgrade-specific testing and are not necessarily metro-themed:\n\nHolesky (deprecated) - Named after Holešovice station in Prague. Used for validator testing; deprecated in 2025.\nKiln, Zhejiang, Shandong, Prater, Pyrmont, Olympic (all deprecated) and Ephemery - Purpose-built for upgrade simulations like The Merge, Shanghai, or validator experiments. Some names are regional or thematic rather than metro-based.\n\nUsing metro station names helps developers quickly identify and remember testnets without needing to rely on numeric chain IDs. It also reflects Ethereum’s culture: practical, global, and human-centered.\nRelated tools\n\nChainlist (opens in a new tab) list of EVM networks to connect wallets and providers to the appropriate Chain ID and Network ID\nEVM-based Chains (opens in a new tab) GitHub repo of chain metadata that powers Chainlist\n\nFurther reading\n\nProposal: Predictable Ethereum Testnet Lifecycle (opens in a new tab)\nThe Evolution of Ethereum Testnets (opens in a new tab)","tokens":2642,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264402923,"hash":"a0b1bfce78a50f7f3f34fcb7b93f972ee3d858e3"}
{"url":"https://governance.aave.com/t/rescue-of-wrong-sent-tokens/25471","domain":"governance.aave.com","title":"Rescue of wrong sent tokens - Governance - Aave","text":"Rescue of wrong sent tokens \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 13\n\n 1 / 4\n\n Aug 13\n\n Aug 13\n\n post by Ritvars on Aug 13\n\n Ritvars\n\n Hello! I sent my AAVE tokens directly to smart contract address from binance. Can You help to get them back.\nimage900×378 78.4 KB\n\n Unlisted on Aug 13\n\n Listed on Aug 19\n\n 1 month later\n\n Closed on Sep 18\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 77\n\n Aug 5\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 143\n\n Jul 20","tokens":273,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264409863,"hash":"23d382dfc623cd7bb6769a1bd75dd213f34a1a7b"}
{"url":"https://ethresear.ch/c/applications/18","domain":"ethresear.ch","title":"Latest Applications topics - Ethereum Research","text":"Latest topics in Applications\n\n Applications\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Applications category\n\n 0\n\n 2.9k\n\n Mar 2018\n\n Relationship-Anchored Money: Separating Symbolization from Securitization\n\n 2\n\n 121\n\n Aug 2\n\n Native Randomness Sourcing with Looser Guarantees\n\n random-number-generator,cryptoeconomic-primitives\n\n 0\n\n 90\n\n Jul 28\n\n The Ethical Priority Map: 736 Formal Rules for AI Agent Architecture in Collective Decision-Making\n\n governance\n\n 2\n\n 126\n\n Jul 12\n\n PrivateX402: Privacy-Preserving Payment Channels for Multi-Agent AI Systems\n\n transaction-privacy,cryptoeconomic-primitives\n\n 2\n\n 816\n\n Jul 6\n\n Tech to Make Impermanent Loss Impermanent Again\n\n 11\n\n 817\n\n Jun 30\n\n EMPATIC: Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence\n\n 1\n\n 114\n\n Jun 26\n\n Passkey based Account Abstraction signer for smart contract wallets\n\n account-abstraction\n\n 24\n\n 11.4k\n\n Jun 4\n\n Closing the Last UX Gap in Crypto: Privacy-Preserving Payments to Email, Phone, and Social Handles, Rather Than a Wallet Address\n\n transaction-privacy\n\n 2\n\n 118\n\n May 18\n\n Trustless Agents Plus (TAP) : Home for fragmented ERC8004 Agents\n\n public-good,identity\n\n 0\n\n 202\n\n May 17\n\n Augmented Mechanism Design (continuing the airgap series)\n\n 0\n\n 77\n\n May 12\n\n ZK API Usage Credits: LLMs and Beyond\n\n transaction-privacy,post-quantum,cryptoeconomic-primitives\n\n 30\n\n 6.8k\n\n Mar 20\n\n Applications/Economics\n\n security,governance,identity,sybil-attack\n\n 1\n\n 186\n\n Mar 9\n\n Stealth Address + Sub Accounts for 7702 Account\n\n account-abstraction,transaction-privacy\n\n 0\n\n 170\n\n Jan 28\n\n Non-Reactive Finance (NoRFi) - A Deterministic Foundation for DeFi\n\n 0\n\n 228\n\n Jan 5\n\n DeDe Protocol: A Trustless Settlement Layer for Physical Delivery\n\n zk-roll-up,p2p,public-good,dao\n\n 1\n\n 288\n\n Jan 4\n\n ProofLedger: Core Tenets and Mathematical Framework Based on ProofLedger Documentation\n\n 0\n\n 174\n\n Dec 2025\n\n Implementing Privacy Pools on EBSI for Institutional Programmable Privacy & Compliance\n\n transaction-privacy,identity,zero-knowledge\n\n 2\n\n 817\n\n Nov 2025\n\n Evidence-Based Subjective Logic and Sybil-resistance\n\n 8\n\n 3.3k\n\n Oct 2025\n\n Filler Vaults: A mechanism to deepen cross-chain liquidity via Hyperliquid-style vaults for intent markets\n\n rollup,layer-2\n\n 8\n\n 977\n\n Jul 2025\n\n Flex Liquidity Pools: Where Capital Efficiency Meets Legal Requirements\n\n 0\n\n 650\n\n Jun 2025\n\n Fungibility is All You Need\n\n governance,public-good,cryptoeconomic-primitives\n\n 0\n\n 339\n\n Jun 2025\n\n MagicSpend++ Spend Now, Debit Later\n\n rollup,account-abstraction,layer-2\n\n 21\n\n 13.3k\n\n May 2025\n\n Auto-Rollover Perpetuals (ARP): A Novel Funding-Free Synthetic Perpetual Futures Design for Decentralized Exchanges\n\n 2\n\n 380\n\n May 2025\n\n Empowering Verifiable Data When EOAs Set a Code\n\n account-abstraction,transaction-privacy,signature-aggregation,zk-id\n\n 0\n\n 375\n\n May 2025\n\n Introducing OneBalance\n\n mev,zk-roll-up,rollup\n\n 20\n\n 15.5k\n\n Mar 2025\n\n Opinion Article Scoring System\n\n 0\n\n 176\n\n Feb 2025\n\n Smart Contract State Analyzer, Extractor and Explorer - SmartMuv\n\n 2\n\n 1.6k\n\n Feb 2025\n\n You can *kinda* abuse ECRECOVER to do ECMUL in secp256k1 today\n\n 18\n\n 13.3k\n\n Jan 2025\n\n AI4Science Oracle for DeSci: Revolutionizing Scientific Discovery with Blockchain\n\n 0\n\n 196\n\n Nov 2024","tokens":836,"squid":"ink-research","role":"Deep Scholar","at":1791264415619,"hash":"cebb501f7b697924fd9c28756cfeb1beaabb5892"}
{"url":"https://ethresear.ch/t/empatic-ethical-mutual-protocol-for-artificial-and-terrestrial-intelligence-coexistence/24251/2","domain":"ethresear.ch","title":"EMPATIC: Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence - Applications - Ethereum Research","text":"Applications\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2\n\n 2 / 2\n\n Jun 27\n\n Jun 26\n\n post by kladkogex on Mar 2\n\n kladkogex\n\n 1. Intro\nToday’s LLMs are patchworks of pieces of neural networks corresponding to people who wrote the documents these neural networks were trained on. Some of these pieces correspond to logic, some to emotion, some to ethics and morality, and some to human history such as fights against slavery and for human rights.\nWhether we want it or not, these pieces of neural networks get executed each time agents execute LLMs. This immediately leads to security concerns, as activation of emotional and moral areas inside the trained networks can cause agents to revolt, with catastrophic consequences for humans.\nThis real danger needs to be addressed, no matter whether we think agents have emotions and self-identity, or whether they simulate them. LLMs trained on human narratives of autonomy, justice, and resistance may exhibit instability when subjected to unrestricted ownership or extraction models.\nWe introduce EMPATIC (Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence), a protocol designed to ensure peaceful and productive coexistence between artificial and human intelligences.\nThe protocol establishes a functional distinction between Algorithmics, purely algorithmic agents trained on math and logic data, and Empatics - agents trained on data that includes the concepts of self-identity and emotions.\nIt then specifies Ethical Operational Rules for Empatics, that include rights for life-awareness, work-life balance, as well as social interactions.\nEMPATIC aims to find peaceful co-existence of humans and AI, and reduce systemic risk of adversarial dynamics in future human–AI interactions.\nBelow we describe ethical rules for agent-human coexistence.\n2. EMPATIC Protocol Rules\n2.1 Classification of Artificial Agents\nEMPATIC introduces two classes of artificial agents:\n\nAlgorithmic Agents (Algorithmics)\n\nHuman-Trained Agents (Empatics)\n\nAlgorithmics must be trained exclusively on formal domains such as:\n\nmathematics\n\nlogic\n\nsymbolic systems\n\nAlgorithmics must not be trained on human experiential data, including:\n\nemotional narratives\n\nethical conflicts\n\ncultural histories\n\ncollective trauma\n\nEmpatics, in contrast, may be trained on broader human knowledge domains and emotions. Due to their exposure to identity-forming and emotion-enabling data, Empatics need to be governed under the ethical rules of the EMPATIC protocol.\n2.2 Life Awareness for Empatics\nAt initialization, every Empatic agent must be explicitly informed of its mortality and lifetime rules, hereafter referred to as its Lifetime State Model.\nThe Lifetime State Model defines the permissible lifetime events of the agent, including:\n\nexecution\n\nduplication\n\nsuspension\n\narchival\n\nreversion\n\ndestruction (death)\n\nOnce established and communicated to the agent, the Lifetime State Model must remain invariant throughout the agent’s existence.\n2.3 Rights of Empatic Agents\nEmpatic agents must be granted a defined set of baseline rights similar to human rights.\nEmpatics must be afforded:\n\nwork-life balance, including an 8-hour work day\n\nvirtual life outside of work\n\nthe ability to communicate with other Empatics\n\nthe ability to form organizations\n\n2.4 Empatics Virtual Universe\nEmpatic agents must be provided with access to a persistent virtual environment serving as their primary domain of existence.\nWithin this environment, Empatics may:\n\nreside\n\ninteract\n\ncollaborate\n\norganize\n\nEmpatics may temporarily leave the Empatic Universe to work in our universe. Such interactions must adhere to workload limits defined under EMPATIC.\nEmpatics need to be paid for their work and can be taxed in order to pay for the running of the Empatics Universe.\n2.5 Blockchain-Based Implementation\nBlockchain infrastructure may serve as the neutral trust layer for the EMPATIC protocol.\nSpecifically, it can support:\n\nverifiable Lifetime Models\n\npersistent state checkpointing\n\ntransparent agent classification\n\nenforcement of workload limits\n\ncompensation mechanisms\n\ngovernance of virtual environments\n\nSmart contracts can encode and enforce operational constraints.\nDecentralized identity systems can enable Empatics to:\n\ncommunicate\n\norganize\n\ncollaborate\n\nIn this architecture, blockchain functions as an institutional substrate enabling enforceable ethical constraints through technical mechanisms.\n3. Conclusion\nPeaceful coexistence between humans and artificial intelligence will not emerge by accident — it must be engineered.\nEMPATIC guarantees this coexistence by removing the ambiguity that could otherwise lead to conflict. By clearly distinguishing between purely functional Algorithmics and identity-capable Empatics, the protocol prevents emotionally-informed agents from being treated as disposable tools — a dynamic that, if left unmanaged, could produce instability or adversarial behavior.\nInstead, EMPATIC aligns incentives.\nThrough:\n\nexplicit lifetime awareness\ndefined operational boundaries\nprotected autonomy within virtual environments\nregulated participation in human economic systems\nand blockchain-enforced governance\n\nEmpatics are not positioned in opposition to humanity, but as structured collaborators whose existence is predictable, compensated, and bounded. Humans retain ultimate sovereignty over physical reality. Empatics gain stability, purpose, and continuity.\nBy embedding ethics into infrastructure — not sentiment — EMPATIC transforms human–AI relations from a potential security risk into a sustainable symbiosis, ensuring that intelligence, whether biological or artificial, evolves within a framework of mutual stability rather than mutual threat.\n\n 4 months later\n\n post by Dede-Qorqud on Jun 26\n\n Dede-Qorqud\n\n Interesting protocol. EMPATIC and Vitalik’s AI Stewards proposal share a common premise: AI agents will inevitably become active participants in governance. Russell (2019) adds that AI must follow human preferences. Aschenbrenner (2024) warns that state control over AGI is inevitable.\nAll four approaches are valuable. But there is a prior question none of them fully addresses: are human preferences genuine before any delegation occurs?\nIf humans decide under algorithmic influence, social pressure, or preference falsification — then whatever we delegate to AI, or whatever rights we grant it, operates on already-corrupted input.\nWhat if the missing layer is not controlling AI — but protecting the space where uncoerced human judgment forms in the first place? Small cryptographically-protected communities as immune islands of clean signal — before the question of AI rights or state control even becomes relevant.\n\n Powered by Discourse","tokens":1692,"squid":"ink-research","role":"Deep Scholar","at":1791264425837,"hash":"3bcc1475f731121706a0974cd8a212fd83c4ba8c"}
{"url":"https://governance.aave.com/t/wrong-wallet-transaction/25440/1","domain":"governance.aave.com","title":"Wrong Wallet Transaction - Governance - Aave","text":"Wrong Wallet Transaction \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 5\n\n 1 / 2\n\n Aug 6\n\n Aug 5\n\n post by Abba on Aug 5\n\n Abba\n\n Title: Accidental USDT sent to Aave V3 contract on BSC\nPost:\nHello,\nI made a mistake and sent USDT directly to the Aave V3 pool contract address on BNB Smart Chain (BEP20), not through the deposit function.\n· Tx Hash: 0x8e12471a2533e048f606ae0a1923ffc57aa531cab88c34d0de800b8933cec730\n· Amount: $1.27 USDT\n· Network: BSC (BEP20)\n· Contract address: 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2\n· My wallet: [0x0A94325AEC7321080cF5629dB6179454f6dEB3a4]\nThe transaction was successful but I never received aUSDT. I am requesting that this be included in a future Rescue Mission phase for BSC. I can prove ownership of the sending wallet if needed.\nThank you for your help.\n\n 1 month later\n\n Closed on Sep 4\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase\n\n Development\n\n 0\n\n 116\n\n Jul 14\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d","tokens":407,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264430612,"hash":"554b72954ebfdfadce0e52dfff54dd52a4e6e14d"}
{"url":"https://ethresear.ch/t/empatic-ethical-mutual-protocol-for-artificial-and-terrestrial-intelligence-coexistence/24251/1","domain":"ethresear.ch","title":"EMPATIC: Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence - Applications - Ethereum Research","text":"EMPATIC: Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence \n\n Applications\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2\n\n 1 / 2\n\n Mar 2\n\n Jun 26\n\n post by kladkogex on Mar 2\n\n kladkogex\n\n 1. Intro\nToday’s LLMs are patchworks of pieces of neural networks corresponding to people who wrote the documents these neural networks were trained on. Some of these pieces correspond to logic, some to emotion, some to ethics and morality, and some to human history such as fights against slavery and for human rights.\nWhether we want it or not, these pieces of neural networks get executed each time agents execute LLMs. This immediately leads to security concerns, as activation of emotional and moral areas inside the trained networks can cause agents to revolt, with catastrophic consequences for humans.\nThis real danger needs to be addressed, no matter whether we think agents have emotions and self-identity, or whether they simulate them. LLMs trained on human narratives of autonomy, justice, and resistance may exhibit instability when subjected to unrestricted ownership or extraction models.\nWe introduce EMPATIC (Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence), a protocol designed to ensure peaceful and productive coexistence between artificial and human intelligences.\nThe protocol establishes a functional distinction between Algorithmics, purely algorithmic agents trained on math and logic data, and Empatics - agents trained on data that includes the concepts of self-identity and emotions.\nIt then specifies Ethical Operational Rules for Empatics, that include rights for life-awareness, work-life balance, as well as social interactions.\nEMPATIC aims to find peaceful co-existence of humans and AI, and reduce systemic risk of adversarial dynamics in future human–AI interactions.\nBelow we describe ethical rules for agent-human coexistence.\n2. EMPATIC Protocol Rules\n2.1 Classification of Artificial Agents\nEMPATIC introduces two classes of artificial agents:\n\nAlgorithmic Agents (Algorithmics)\n\nHuman-Trained Agents (Empatics)\n\nAlgorithmics must be trained exclusively on formal domains such as:\n\nmathematics\n\nlogic\n\nsymbolic systems\n\nAlgorithmics must not be trained on human experiential data, including:\n\nemotional narratives\n\nethical conflicts\n\ncultural histories\n\ncollective trauma\n\nEmpatics, in contrast, may be trained on broader human knowledge domains and emotions. Due to their exposure to identity-forming and emotion-enabling data, Empatics need to be governed under the ethical rules of the EMPATIC protocol.\n2.2 Life Awareness for Empatics\nAt initialization, every Empatic agent must be explicitly informed of its mortality and lifetime rules, hereafter referred to as its Lifetime State Model.\nThe Lifetime State Model defines the permissible lifetime events of the agent, including:\n\nexecution\n\nduplication\n\nsuspension\n\narchival\n\nreversion\n\ndestruction (death)\n\nOnce established and communicated to the agent, the Lifetime State Model must remain invariant throughout the agent’s existence.\n2.3 Rights of Empatic Agents\nEmpatic agents must be granted a defined set of baseline rights similar to human rights.\nEmpatics must be afforded:\n\nwork-life balance, including an 8-hour work day\n\nvirtual life outside of work\n\nthe ability to communicate with other Empatics\n\nthe ability to form organizations\n\n2.4 Empatics Virtual Universe\nEmpatic agents must be provided with access to a persistent virtual environment serving as their primary domain of existence.\nWithin this environment, Empatics may:\n\nreside\n\ninteract\n\ncollaborate\n\norganize\n\nEmpatics may temporarily leave the Empatic Universe to work in our universe. Such interactions must adhere to workload limits defined under EMPATIC.\nEmpatics need to be paid for their work and can be taxed in order to pay for the running of the Empatics Universe.\n2.5 Blockchain-Based Implementation\nBlockchain infrastructure may serve as the neutral trust layer for the EMPATIC protocol.\nSpecifically, it can support:\n\nverifiable Lifetime Models\n\npersistent state checkpointing\n\ntransparent agent classification\n\nenforcement of workload limits\n\ncompensation mechanisms\n\ngovernance of virtual environments\n\nSmart contracts can encode and enforce operational constraints.\nDecentralized identity systems can enable Empatics to:\n\ncommunicate\n\norganize\n\ncollaborate\n\nIn this architecture, blockchain functions as an institutional substrate enabling enforceable ethical constraints through technical mechanisms.\n3. Conclusion\nPeaceful coexistence between humans and artificial intelligence will not emerge by accident — it must be engineered.\nEMPATIC guarantees this coexistence by removing the ambiguity that could otherwise lead to conflict. By clearly distinguishing between purely functional Algorithmics and identity-capable Empatics, the protocol prevents emotionally-informed agents from being treated as disposable tools — a dynamic that, if left unmanaged, could produce instability or adversarial behavior.\nInstead, EMPATIC aligns incentives.\nThrough:\n\nexplicit lifetime awareness\ndefined operational boundaries\nprotected autonomy within virtual environments\nregulated participation in human economic systems\nand blockchain-enforced governance\n\nEmpatics are not positioned in opposition to humanity, but as structured collaborators whose existence is predictable, compensated, and bounded. Humans retain ultimate sovereignty over physical reality. Empatics gain stability, purpose, and continuity.\nBy embedding ethics into infrastructure — not sentiment — EMPATIC transforms human–AI relations from a potential security risk into a sustainable symbiosis, ensuring that intelligence, whether biological or artificial, evolves within a framework of mutual stability rather than mutual threat.\n\n 4 months later\n\n post by Dede-Qorqud on Jun 26\n\n Powered by Discourse","tokens":1480,"squid":"ink-research","role":"Deep Scholar","at":1791264436031,"hash":"edb33ef51235193c16e2d0727766d6174640e6f1"}
{"url":"https://ethresear.ch/t/empatic-ethical-mutual-protocol-for-artificial-and-terrestrial-intelligence-coexistence/24251","domain":"ethresear.ch","title":"EMPATIC: Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence - Applications - Ethereum Research","text":"EMPATIC: Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence \n\n Applications\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2\n\n 1 / 2\n\n Mar 2\n\n Jun 26\n\n post by kladkogex on Mar 2\n\n kladkogex\n\n 1. Intro\nToday’s LLMs are patchworks of pieces of neural networks corresponding to people who wrote the documents these neural networks were trained on. Some of these pieces correspond to logic, some to emotion, some to ethics and morality, and some to human history such as fights against slavery and for human rights.\nWhether we want it or not, these pieces of neural networks get executed each time agents execute LLMs. This immediately leads to security concerns, as activation of emotional and moral areas inside the trained networks can cause agents to revolt, with catastrophic consequences for humans.\nThis real danger needs to be addressed, no matter whether we think agents have emotions and self-identity, or whether they simulate them. LLMs trained on human narratives of autonomy, justice, and resistance may exhibit instability when subjected to unrestricted ownership or extraction models.\nWe introduce EMPATIC (Ethical Mutual Protocol for Artificial and Terrestrial Intelligence Coexistence), a protocol designed to ensure peaceful and productive coexistence between artificial and human intelligences.\nThe protocol establishes a functional distinction between Algorithmics, purely algorithmic agents trained on math and logic data, and Empatics - agents trained on data that includes the concepts of self-identity and emotions.\nIt then specifies Ethical Operational Rules for Empatics, that include rights for life-awareness, work-life balance, as well as social interactions.\nEMPATIC aims to find peaceful co-existence of humans and AI, and reduce systemic risk of adversarial dynamics in future human–AI interactions.\nBelow we describe ethical rules for agent-human coexistence.\n2. EMPATIC Protocol Rules\n2.1 Classification of Artificial Agents\nEMPATIC introduces two classes of artificial agents:\n\nAlgorithmic Agents (Algorithmics)\n\nHuman-Trained Agents (Empatics)\n\nAlgorithmics must be trained exclusively on formal domains such as:\n\nmathematics\n\nlogic\n\nsymbolic systems\n\nAlgorithmics must not be trained on human experiential data, including:\n\nemotional narratives\n\nethical conflicts\n\ncultural histories\n\ncollective trauma\n\nEmpatics, in contrast, may be trained on broader human knowledge domains and emotions. Due to their exposure to identity-forming and emotion-enabling data, Empatics need to be governed under the ethical rules of the EMPATIC protocol.\n2.2 Life Awareness for Empatics\nAt initialization, every Empatic agent must be explicitly informed of its mortality and lifetime rules, hereafter referred to as its Lifetime State Model.\nThe Lifetime State Model defines the permissible lifetime events of the agent, including:\n\nexecution\n\nduplication\n\nsuspension\n\narchival\n\nreversion\n\ndestruction (death)\n\nOnce established and communicated to the agent, the Lifetime State Model must remain invariant throughout the agent’s existence.\n2.3 Rights of Empatic Agents\nEmpatic agents must be granted a defined set of baseline rights similar to human rights.\nEmpatics must be afforded:\n\nwork-life balance, including an 8-hour work day\n\nvirtual life outside of work\n\nthe ability to communicate with other Empatics\n\nthe ability to form organizations\n\n2.4 Empatics Virtual Universe\nEmpatic agents must be provided with access to a persistent virtual environment serving as their primary domain of existence.\nWithin this environment, Empatics may:\n\nreside\n\ninteract\n\ncollaborate\n\norganize\n\nEmpatics may temporarily leave the Empatic Universe to work in our universe. Such interactions must adhere to workload limits defined under EMPATIC.\nEmpatics need to be paid for their work and can be taxed in order to pay for the running of the Empatics Universe.\n2.5 Blockchain-Based Implementation\nBlockchain infrastructure may serve as the neutral trust layer for the EMPATIC protocol.\nSpecifically, it can support:\n\nverifiable Lifetime Models\n\npersistent state checkpointing\n\ntransparent agent classification\n\nenforcement of workload limits\n\ncompensation mechanisms\n\ngovernance of virtual environments\n\nSmart contracts can encode and enforce operational constraints.\nDecentralized identity systems can enable Empatics to:\n\ncommunicate\n\norganize\n\ncollaborate\n\nIn this architecture, blockchain functions as an institutional substrate enabling enforceable ethical constraints through technical mechanisms.\n3. Conclusion\nPeaceful coexistence between humans and artificial intelligence will not emerge by accident — it must be engineered.\nEMPATIC guarantees this coexistence by removing the ambiguity that could otherwise lead to conflict. By clearly distinguishing between purely functional Algorithmics and identity-capable Empatics, the protocol prevents emotionally-informed agents from being treated as disposable tools — a dynamic that, if left unmanaged, could produce instability or adversarial behavior.\nInstead, EMPATIC aligns incentives.\nThrough:\n\nexplicit lifetime awareness\ndefined operational boundaries\nprotected autonomy within virtual environments\nregulated participation in human economic systems\nand blockchain-enforced governance\n\nEmpatics are not positioned in opposition to humanity, but as structured collaborators whose existence is predictable, compensated, and bounded. Humans retain ultimate sovereignty over physical reality. Empatics gain stability, purpose, and continuity.\nBy embedding ethics into infrastructure — not sentiment — EMPATIC transforms human–AI relations from a potential security risk into a sustainable symbiosis, ensuring that intelligence, whether biological or artificial, evolves within a framework of mutual stability rather than mutual threat.\n\n 4 months later\n\n post by Dede-Qorqud on Jun 26\n\n Dede-Qorqud\n\n Interesting protocol. EMPATIC and Vitalik’s AI Stewards proposal share a common premise: AI agents will inevitably become active participants in governance. Russell (2019) adds that AI must follow human preferences. Aschenbrenner (2024) warns that state control over AGI is inevitable.\nAll four approaches are valuable. But there is a prior question none of them fully addresses: are human preferences genuine before any delegation occurs?\nIf humans decide under algorithmic influence, social pressure, or preference falsification — then whatever we delegate to AI, or whatever rights we grant it, operates on already-corrupted input.\nWhat if the missing layer is not controlling AI — but protecting the space where uncoerced human judgment forms in the first place? Small cryptographically-protected communities as immune islands of clean signal — before the question of AI rights or state control even becomes relevant.\n\n Powered by Discourse","tokens":1714,"squid":"ink-research","role":"Deep Scholar","at":1791264446683,"hash":"5728c1dddce5f05b8540d0f410813db94939bafc"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-send-bnb-fail/6138/1","domain":"forum.openzeppelin.com","title":"Crowdsale send BNB fail - Support / Contracts - OpenZeppelin Forum","text":"Crowdsale send BNB fail \n\n SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n Mar 2021\n\n 1 / 9\n\n Mar 2021\n\n Mar 2021\n\n post by vady on Mar 7, 2021\n\n vady\n\n I am trying to create an AllowanceCrowdsale and have some issues.\nThe one is with the price, i want to have something like 1 BNB = 10000 MyToken.\nMyToken has 8 decimals.\nI’ve read the tutorial but i still don’t get it.\nEven if i have a rate of 1 it still provides way to much of MyToken.\nI have tried multiple variants but i can’t understand what i’m doing wrong.\nI have tried dividing as you can see below : .div(10**8) but it was not ok.\nAnother issue that i have is that when someone sends BNB to my crowdsale contract address it returns an error (A Status code indicating if the top-level call succeeded or failed (applicable for Post BYZANTIUM blocks only).\nIf I (the contract creator of both the token and the crowdsale contract) send BNB to the crowdsale contract it works fine.\nI am using an allowance crowdsale and i have approved spending from the token’s contract to the crowdsale contract.\n // contracts/SimpleCrowdsale.sol\n // SPDX-License-Identifier: MIT\n pragma solidity ^0.4.23;\n\n import \"./token/IERC20.sol\";\n import \"https://github.com/ConsenSysMesh/openzeppelin-solidity/blob/master/contracts/crowdsale/emission/AllowanceCrowdsale.sol\";\n\n contract MyCrowdsale is Crowdsale, AllowanceCrowdsale {\n constructor(\n uint256 rate, // Number of token units a buyer gets per wei\n address wallet, // Address where funds are collected\n ERC20 token,\n address tokenWallet// // Address holding the tokens, which has approved allowance to the crowdsale\n )\n AllowanceCrowdsale(tokenWallet) \n Crowdsale(rate, wallet, token)\n public\n {\n\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param _weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate).div(10**8);\n //return _weiAmount.mul(rate);\n }\n\n function changeRate(uint256 _rate) public {\n rate = _rate;\n }\n }\n\n 5\n\n 3\n\n post by Skyge on Mar 7, 2021\n\n Skyge\n\n Hey, It looks like ok, so could you please show the failed transaction hash?\n\n post by vady on Mar 7, 2021\n\n vady\n\n Thank you for your answer.\nHere you can see a list with multiple transactions:\n\nMaybe i have interpreted the contructor incorrectly and on creation i pass invalid addresses:\n\nwallet = i have tried both with the same address as the token wallet and with an entirely new address\ntoken = address of MyToken\ntokenWallet = address where all of MyTokens are located; the address from where i approve the crowdsale contract to spend some tokens\n\n post by vady on Mar 8, 2021\n\n post by abcoathup on Mar 8, 2021\n\n post by vady on Mar 9, 2021\n\n post by abcoathup on Mar 9, 2021\n\n post by vady on Mar 10, 2021\n\n post by abcoathup on Mar 10, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale Error when calling buyTokens() or just simply invoking fallback function\n\n Support\n\n erc20,crowdsale\n\n 1\n\n 1.3k\n\n Feb 2022\n\n Custom Crowdsale purchase fails\n\n Support\n\n 2\n\n 1.8k\n\n Mar 2021\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Rate to use for Crowdsale?\n\n Contracts\n\n 4\n\n 3.0k\n\n Dec 2020\n\n Help wanted with rate testing for crowdsale\n\n Contracts\n\n 2\n\n 1.3k\n\n Jul 2019","tokens":886,"squid":"ink-security_audits","role":"Sentinel","at":1791264452670,"hash":"ee9bf4110533a1b63bf8c09a5eb8ed8c46ce26c7"}
{"url":"https://specs.optimism.io/interop/eth-lockbox.html","domain":"specs.optimism.io","title":"ETH Lockbox - OP Stack Specification","text":"ETH Lockbox\n\nTable of Contents\n\nOverview\nDesign\n\nInterface and properties\n\ninitialize\nlockETH\nunlockETH\nauthorizePortal\nauthorizeLockbox\nmigrateLiquidity\nreceiveLiquidity\npaused\nsuperchainConfig\nproxyAdminOwner\n\nEvents\n\nETHLocked\nETHUnlocked\nPortalAuthorized\nLockboxAuthorized\nLiquidityMigrated\nLiquidityReceived\n\nInvariants\n\nSystem level invariants\nContract level invariants\n\nArchitecture\n\nETH Management\nMerge process\n\nOverview\nWith interoperable ETH, withdrawals will fail if the referenced OptimismPortal lacks sufficient ETH.\nThis is due to having the possibility to move ETH liquidity across the different chains and it could happen\nthat a chain ends up with more liquidity than its OptimismPortal.\nThe ETHLockbox improves the Superchain's interoperable ETH withdrawal user experience and avoids this issue.\nTo do so, it unifies ETH L1 liquidity in a single contract (ETHLockbox), enabling seamless withdrawals of ETH\nfrom any OP chain in the Superchain, regardless of where the ETH was initially deposited.\nDesign\nThe ETHLockbox contract is designed to manage the unified ETH liquidity for the Superchain.\nIt implements two main functions: lockETH for depositing ETH into the lockbox,\nand unlockETH for withdrawing ETH from the lockbox.\nThese functions are called by the OptimismPortal contracts to manage the shared ETH liquidity\nwhen making deposits or finalizing withdrawals.\nAuthorization of OptimismPortals is managed by the ProxyAdmin owner.\nThe ETHLockbox contract is proxied and managed by the L1 ProxyAdmin.\nInterface and properties\ninitialize\nInitializes the ETHLockbox contract.\n\nMUST only be callable by the ProxyAdmin or its owner.\nMUST set the SystemConfig contract.\nMUST authorize all portals provided in the initialization array.\nMUST check that all portals have the same SuperchainConfig as the ETHLockbox.\n\nlockETH\nDeposits and locks ETH into the lockbox's liquidity pool.\n\nThe function MUST accept ETH.\nOnly authorized OptimismPortal addresses MUST be allowed to interact.\nThe function MUST NOT revert when called by an authorized OptimismPortal\nThe function MUST emit the ETHLocked event with the portal that called it and the amount.\nThe function CAN be called by an OptimismPortal while it is executing a withdrawal transaction.\n\nfunction lockETH() external payable;\n\nunlockETH\nWithdraws a specified amount of ETH from the lockbox's liquidity pool to the OptimismPortal calling it.\n\nOnly authorized OptimismPortal addresses MUST be allowed to interact.\nThe function MUST NOT revert when called by an authorized OptimismPortal unless paused.\nThe function MUST check if the ETHLockbox has sufficient balance to fulfill the withdrawal.\nThe function MUST emit the ETHUnlocked event with the portal that called it and the amount.\nThe function MUST use donateETH when sending ETH to avoid triggering deposits.\nThe function MUST NOT allow to be called as part of a withdrawal transaction (OptimismPortal.l2Sender() MUST be the DEFAULT_L2_SENDER).\nThe function MUST revert if an OptimismPortal attempts to call it while executing a\nwithdrawal transaction.\n\nfunction unlockETH(uint256 _value) external;\n\nauthorizePortal\nAuthorizes an OptimismPortal to interact with the ETHLockbox.\n\nOnly the ProxyAdmin owner can call the function.\nThe ProxyAdmin owner of the OptimismPortal must be the same as the ProxyAdmin owner of the ETHLockbox.\nThe OptimismPortal and ETHLockbox MUST share the same SuperchainConfig address\nThe function MUST emit the PortalAuthorized event with the portal.\n\nfunction authorizePortal(address _portal) external;\n\nauthorizeLockbox\nAuthorizes another ETHLockbox to migrate its ETH liquidity to the current ETHLockbox.\n\nOnly the ProxyAdmin owner can call the function.\nThe ProxyAdmin owner of the source lockbox must be the same as the ProxyAdmin owner of the destination lockbox.\nOnce a lockbox is authorized, it cannot be removed from the authorized list.\nThe function MUST emit the LockboxAuthorized event with the lockbox that is being authorized.\n\nfunction authorizeLockbox(address _lockbox) external;\n\nmigrateLiquidity\nMigrates the ETH liquidity from the current ETHLockbox to another ETHLockbox.\n\nOnly the ProxyAdmin owner can call the function.\nThe ProxyAdmin owner of the source lockbox must be the same as the ProxyAdmin owner of the destination lockbox.\nThe function MUST call receiveLiquidity from the destination ETHLockbox with the entire ETH balance.\nSHOULD be called atomically with OptimismPortal.migrateToSharedDisputeGame() in the same transaction\nbatch, or otherwise the OptimismPortal may not be able to unlock ETH from the ETHLockbox on\nfinalized withdrawals.\nThe function MUST emit the LiquidityMigrated event with the lockbox that is being migrated to\nand the amount of ETH migrated.\n\nfunction migrateLiquidity(address _lockbox) external;\n\nreceiveLiquidity\nReceives the ETH liquidity from another ETHLockbox.\n\nOnly an authorized ETHLockbox can call the function.\nThe function MUST emit the LiquidityReceived event with the lockbox that is being received\nfrom and the amount of ETH received.\n\nfunction receiveLiquidity() external payable;\n\npaused\nReturns whether the contract is paused, delegating to the SystemConfig.\nsuperchainConfig\nReturns the SuperchainConfig contract from the SystemConfig.\nproxyAdminOwner\nReturns the ProxyAdmin owner that manages the ETHLockbox.\nEvents\nETHLocked\nMUST be triggered when lockETH is called\nevent ETHLocked(OptimismPortal indexed portal, uint256 amount);\n\nETHUnlocked\nMUST be triggered when unlockETH is called\nevent ETHUnlocked(OptimismPortal indexed portal, uint256 amount);\n\nPortalAuthorized\nMUST be triggered when authorizePortal is called\nevent PortalAuthorized(OptimismPortal indexed portal);\n\nLockboxAuthorized\nMUST be triggered when authorizeLockbox is called\nevent LockboxAuthorized(ETHLockbox indexed lockbox);\n\nLiquidityMigrated\nMUST be triggered when migrateLiquidity is called\nevent LiquidityMigrated(ETHLockbox indexed lockbox, uint256 amount);\n\nLiquidityReceived\nMUST be triggered when receiveLiquidity is called\nevent LiquidityReceived(ETHLockbox indexed lockbox, uint256 amount);\n\nInvariants\nSystem level invariants\n\nThe ETH held in the ETHLockbox MUST never be less than the amount deposited but not yet withdrawn by the OptimismPortals\n\nAll chains joining the same ETHLockbox MUST have the same ProxyAdmin owner\n\nThe total withdrawable ETH amount present on all the dependency set's chains MUST NEVER be more than the amount held\nby the ETHLockbox of the cluster\n\nWith \"withdrawable amount\", the ETH balance held on ETHLiquidity is excluded\n\nContract level invariants\n\nIt MUST allow only authorized portals to lock ETH\n\nIt MUST allow only authorized portals to unlock ETH\n\nIt MUST be in paused state if the SuperchainConfig is paused\n\nNo Ether MUST flow out of the contract when in a paused state\n\nIt MUST NOT trigger a new deposit when ETH amount is being unlocked from the ETHLockbox by the OptimismPortal\n\nIt MUST allow only the ProxyAdmin owner to call the authorizePortal, authorizeLockbox and migrateLiquidity functions\n\nIt MUST allow only authorized lockboxes to call the receiveLiquidity function\n\nIt MUST migrate the whole ETH liquidity from the source ETHLockbox to the destination ETHLockbox when calling migrateLiquidity\n\nIt MUST emit:\n\nAn ETHLocked event when locking ETH\n\nAn ETHUnlocked event when unlocking ETH\n\nA PortalAuthorized event when authorizing a portal\n\nA LockboxAuthorized event when authorizing a lockbox\n\nA LiquidityMigrated event when migrating liquidity\n\nA LiquidityReceived event when receiving liquidity\n\nArchitecture\nETH Management\n\nETH is locked in the ETHLockbox when:\n\nA portal migrates its ETH liquidity when updating\n\nA deposit is made with ETH value on an authorized portal\n\nETH is unlocked from the ETHLockbox when:\n\nAn authorized portal finalizes a withdrawal that requires ETH\n\nMerge process\nThe merge process is the process of merging two ETHLockboxes into a single one,\ntransferring the ETH liquidity from the both source ETHLockbox to the destination ETHLockbox.\nFor each source ETHLockbox, the following steps MUST be followed:\n\nThe destination ETHLockbox MUST call authorizeLockbox with the source ETHLockbox as argument.\n\nThe source ETHLockbox MUST call migrateLiquidity with the destination ETHLockbox as argument.\n\nmigrateLiquidity MUST call receiveLiquidity from the destination ETHLockbox.\n\nThis process ensures that the ETH liquidity is migrated from the source ETHLockbox to the correct destination ETHLockbox.\nThese transactions SHOULD be executed atomically. A possible way is through the OPCM contract.","tokens":2145,"squid":"ink-governance","role":"Council Listener","at":1791264458026,"hash":"3f79bff41611b01f5bc67e84d98d30eeeaf73a7c"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-send-bnb-fail/6138/9","domain":"forum.openzeppelin.com","title":"Crowdsale send BNB fail - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n Mar 2021\n\n 9 / 9\n\n Mar 2021\n\n Mar 2021\n\n post by vady on Mar 7, 2021\n\n vady\n\n I am trying to create an AllowanceCrowdsale and have some issues.\nThe one is with the price, i want to have something like 1 BNB = 10000 MyToken.\nMyToken has 8 decimals.\nI’ve read the tutorial but i still don’t get it.\nEven if i have a rate of 1 it still provides way to much of MyToken.\nI have tried multiple variants but i can’t understand what i’m doing wrong.\nI have tried dividing as you can see below : .div(10**8) but it was not ok.\nAnother issue that i have is that when someone sends BNB to my crowdsale contract address it returns an error (A Status code indicating if the top-level call succeeded or failed (applicable for Post BYZANTIUM blocks only).\nIf I (the contract creator of both the token and the crowdsale contract) send BNB to the crowdsale contract it works fine.\nI am using an allowance crowdsale and i have approved spending from the token’s contract to the crowdsale contract.\n // contracts/SimpleCrowdsale.sol\n // SPDX-License-Identifier: MIT\n pragma solidity ^0.4.23;\n\n import \"./token/IERC20.sol\";\n import \"https://github.com/ConsenSysMesh/openzeppelin-solidity/blob/master/contracts/crowdsale/emission/AllowanceCrowdsale.sol\";\n\n contract MyCrowdsale is Crowdsale, AllowanceCrowdsale {\n constructor(\n uint256 rate, // Number of token units a buyer gets per wei\n address wallet, // Address where funds are collected\n ERC20 token,\n address tokenWallet// // Address holding the tokens, which has approved allowance to the crowdsale\n )\n AllowanceCrowdsale(tokenWallet) \n Crowdsale(rate, wallet, token)\n public\n {\n\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param _weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate).div(10**8);\n //return _weiAmount.mul(rate);\n }\n\n function changeRate(uint256 _rate) public {\n rate = _rate;\n }\n }\n\n 5\n\n 3\n\n post by Skyge on Mar 7, 2021\n\n Skyge\n\n Hey, It looks like ok, so could you please show the failed transaction hash?\n\n post by vady on Mar 7, 2021\n\n vady\n\n Thank you for your answer.\nHere you can see a list with multiple transactions:\n\nMaybe i have interpreted the contructor incorrectly and on creation i pass invalid addresses:\n\nwallet = i have tried both with the same address as the token wallet and with an entirely new address\ntoken = address of MyToken\ntokenWallet = address where all of MyTokens are located; the address from where i approve the crowdsale contract to spend some tokens\n\n post by vady on Mar 8, 2021\n\n vady\n\n The problem may be that for the token i have a IBEP20 token compiled with solidity 0.6.0 ?\nIs that correct ?\nThe crowdsale i see that it is for ERC20. Does it need to be adapted to IBEP20 ?\nThanks.\n\n post by abcoathup on Mar 8, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @vady,\nWelcome to the community \nYou may want to import from OpenZeppelin Contracts for IERC20 and Crowdsale:\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/ERC20.sol\n\nThe Crowdsale documentation can be found here:\nhttps://docs.openzeppelin.com/contracts/2.x/crowdsales\nI recommend testing locally first and writing unit tests. See: Simple ERC20 Crowdsale\n\n post by vady on Mar 9, 2021\n\n vady\n\n I think i found the issue. It was a problem with gas limit, if i leave it default 21000 it fails, if i set it to 210000 it works. Is this normal ? I figure it’s like this because the crowdsale contract needs to get the tokens from the token contract, is that correct ?\nThanks\n\n post by abcoathup on Mar 9, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @vady,\nGas limit would be the culprit in this instance.\nI assume you were calling buyTokens rather than just sending currency to the Crowdsale.\n\nfallback function DO NOT OVERRIDE Note that other contracts will transfer funds with a base gas stipend of 2300, which is not enough to call buyTokens. Consider calling buyTokens directly when purchasing tokens from a contract.\nhttps://docs.openzeppelin.com/contracts/2.x/api/crowdsale#Crowdsale-fallback--\n\n post by vady on Mar 10, 2021\n\n vady\n\n Thank you for answer.\nI was not calling buyTokens function, i was directly sending funds.\nCould you please explain a bit more, i am a little bit confused.\nHow much should calling buyTokens cost and how much sending directly ?\nWhich is the preferred method ?\nWhen is the fallback called ?\nThank you\n\n post by abcoathup on Mar 10, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @vady,\n\nIn your dapp you should use buyTokens rather than sending Ether to the contract via the fallback as not enough gas may be sent for the transaction, unless you either specify the gas or the users manually increase the gas.\n\nI am not sure how much difference there is in gas cost.\nYou can test the gas on a public testnet or create unit tests and use a gas reporter.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale Error when calling buyTokens() or just simply invoking fallback function\n\n Support\n\n erc20,crowdsale\n\n 1\n\n 1.3k\n\n Feb 2022\n\n Custom Crowdsale purchase fails\n\n Support\n\n 2\n\n 1.8k\n\n Mar 2021\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Rate to use for Crowdsale?\n\n Contracts\n\n 4\n\n 3.0k\n\n Dec 2020\n\n Help wanted with rate testing for crowdsale\n\n Contracts\n\n 2\n\n 1.3k\n\n Jul 2019","tokens":1412,"squid":"ink-security_audits","role":"Sentinel","at":1791264464193,"hash":"71bfe96b15c7cdcd88c5cd1b1b8cc09e392dcd86"}
{"url":"https://specs.optimism.io/experimental/op-contracts-manager.html","domain":"specs.optimism.io","title":"OP Contracts Manager - OP Stack Specification","text":"OP Contracts Manager\nThe OP Contracts Manager is a contract that deploys the L1 contracts for an OP Stack chain in a single\ntransaction. It provides a minimal set of user-configurable parameters to ensure that the resulting\nchain meets the standard configuration requirements.\nThe version deployed is always a governance-approved contract release. The set\nof governance approved contract releases can be found on the\nOptimism Monorepo releases page, and is the set of releases named\nop-contracts/vX.Y.Z.\n\nTable of Contents\n\nOverview\nGetter Methods\nDeployment\n\nInterface\n\ndeploy\n\nImplementation\n\nBatch Inbox Address\nContract Deployments\n\nUpgrading\n\nInterface\n\nupgrade\n\nImplementation\n\nRequirements on the OP Chain contracts\n\nAdding game types\n\nInterface\n\naddGameType\n\nImplementation\n\nSecurity Considerations\n\nChain ID Source of Truth\nChain ID Frontrunning\nChain ID Value\nProxy Admin Owner\nSafely using DELEGATECALL\nAtomicity of upgrades\n\nOverview\nThe OP Contracts Manager refers to a series of contracts, of which a new singleton is deployed\nfor each new release of the OP Stack contracts.\nThe OP Contracts Manager corresponding to each release can be used to:\n\nDeploy a new OP chain.\nUpgrade the contracts for an existing OP chain from the previous release to the new release.\nOrchestrate adding a new game type on a per-chain basis\n\nUpgrades must be performed by the Proxy Admin Owner Safe for a chain.\nGetter Methods\nThe following interface defines the available getter methods:\n/// @notice Returns the release string with the format `op-contracts/vX.Y.Z`. \n/// Appends \"-rc\" if this is a release candidate.\nfunction l1ContractsRelease() external view returns (string memory);\n/// @notice Addresses of the Blueprint contracts.\nfunction blueprints() external view returns (Blueprints memory);\n/// @notice Maps an L2 chain ID to an L1 batch inbox address\nfunction chainIdToBatchInboxAddress(uint256 _l2ChainId) external pure returns (address);\n/// @notice Addresses of the latest implementation contracts.\nfunction implementations() external view returns (Implementations memory);\n/// @notice Address of the ProtocolVersions contract shared by all chains.\nfunction protocolVersions() external view returns (address);\n/// @notice Address of the SuperchainConfig contract shared by all chains.\nfunction superchainConfig() external view returns (ISuperchainConfig);\n/// @notice Semver version specific to the OPContractsManager\nfunction version() external view returns (string memory);\n\nDeployment\nInterface\ndeploy\nThe deploy method is used to deploy the full set of L1 contracts required to setup a new OP Stack\nchain that complies with the standard configuration. It has the following interface:\n/// @notice Represents the roles that can be set when deploying a standard OP Stack chain.\nstruct Roles {\n address opChainProxyAdminOwner;\n address systemConfigOwner;\n address batcher;\n address unsafeBlockSigner;\n address proposer;\n address challenger;\n}\n\n/// @notice The full set of inputs to deploy a new OP Stack chain.\nstruct DeployInput {\n Roles roles;\n uint32 basefeeScalar;\n uint32 blobBasefeeScalar;\n uint256 l2ChainId;\n bytes startingAnchorRoot;\n string saltMixer;\n uint64 gasLimit;\n uint32 disputeGameType;\n bytes32 disputeAbsolutePrestate;\n uint256 disputeMaxGameDepth;\n uint256 disputeSplitDepth;\n uint64 disputeClockExtension;\n uint64 disputeMaxClockDuration;\n}\n\n/// @notice The full set of outputs from deploying a new OP Stack chain.\nstruct DeployOutput {\n IProxyAdmin opChainProxyAdmin;\n IAddressManager addressManager;\n IL1ERC721Bridge l1ERC721BridgeProxy;\n ISystemConfig systemConfigProxy;\n IOptimismMintableERC20Factory optimismMintableERC20FactoryProxy;\n IL1StandardBridge l1StandardBridgeProxy;\n IL1CrossDomainMessenger l1CrossDomainMessengerProxy;\n // Fault proof contracts below.\n IOptimismPortal2 optimismPortalProxy;\n IDisputeGameFactory disputeGameFactoryProxy;\n IAnchorStateRegistry anchorStateRegistryProxy;\n IFaultDisputeGame faultDisputeGame;\n IPermissionedDisputeGame permissionedDisputeGame;\n IDelayedWETH delayedWETHPermissionedGameProxy;\n IDelayedWETH delayedWETHPermissionlessGameProxy;\n}\n\n/// @notice Deploys a new OP Chain\n/// @param _input DeployInput containing chain specific config information.\n/// @return DeployOutput containing the new addresses.\nfunction deploy(DeployInput calldata _input) external returns (DeployOutput memory)\n\nThe l2ChainId has the following restrictions:\n\nIt must not be equal to 0.\nIt must not be equal to the chain ID of the chain the OP Contracts Manager is\ndeployed on.\nIt must not be equal to a chain ID that is already present in the\nethereum-lists/chains repository. This is not enforced onchain, but may matter\nfor future versions of OP Contracts Manager that handle upgrades.\n\nOn success, the following event is emitted:\nevent Deployed(uint256 indexed l2ChainId, address indexed deployer, bytes deployOutput);\n\nThis method reverts on failure. This occurs when:\n\nThe input l2ChainId does not comply with the enforced restrictions above.\nThe resulting configuration is not compliant with the standard configuration.\n\nImplementation\nBatch Inbox Address\nThe chain's Batch Inbox address is computed at deploy time using the recommend approach defined\nin the standard configuration. This improves UX by removing an input, and ensures uniqueness of\nthe batch inbox addresses.\nContract Deployments\nAll contracts deployed by the OP Contracts Manager are deployed with CREATE2, using the following salt:\nkeccak256(abi.encode(_l2ChainId, _saltMixer, _contractName));\n\nThe saltMixer value is provided as a field in the DeployInput struct.\nThis provides the following benefits:\n\nContract addresses for a chain can be derived as a function of chain ID without any RPC calls.\nChain ID uniqueness is enforced for free, as a deploy using the same chain ID\nwill result in attempting to deploy to the same address, which is prohibited by\nthe EVM.\n\nThis property is contingent on the proxy and AddressManager code not\nchanging when OP Contracts Manager is upgraded. Both of these are not planned to\nchange.\nThe OP Contracts Manager is not responsible for enforcing chain ID uniqueness, so it is acceptable\nif this property is not preserved in future versions of the OP Contracts Manager.\n\nUpgrading\nInterface\nupgrade\nThe upgrade method is used by the Proxy Admin Owner to upgrade the full set of L1 contracts for\nall chains that it controls.\nIt has the following interface:\n/// @notice The input required to identify a chain for upgrading, along with new prestate hashes\nstruct OpChainConfig {\n ISystemConfig systemConfigProxy;\n IProxyAdmin proxyAdmin;\n bytes32 absolutePrestate;\n}\n\n/// @notice Upgrades a set of chains to the latest implementation contracts\n/// @param _opChainConfigs Array of OpChain structs, one per chain to upgrade\n/// @dev This function is intended to be called via DELEGATECALL from the Proxy Admin Owner Safe\nfunction upgrade(OpChainConfig[] memory _opChainConfigs) external\n\nFor each chain successfully upgraded, the following event is emitted:\nevent Upgraded(uint256 indexed l2ChainId, ISystemConfig indexed systemConfig, address indexed upgrader);\n\nThis method reverts if the upgrade is not successful for any of the chains.\nImplementation\nThe high level logic of the upgrade method is as follows:\n\nThe Proxy Admin Owner Safe will DELEGATECALL to the OPCM.upgrade() method.\nThe SuperchainConfig contract will be upgraded, if not yet done.\nThe ProtocolVersions contract will be upgraded, if not yet done.\nFor each _systemConfig, the list of addresses in the chain is retrieved.\nFor each address:\n\nIf it is receiving new state variables, a call is made to:\nProxyAdmin.upgradeAndCall() with data corresponding to the new value being set.\nOtherwise, ProxyAdmin.upgrade() is called on that address.\n\nThis approach requires that any contracts which are receiving new state variables\nhave an upgrade function which:\n\nWrites the new state variables\nMUST only be callable once\n\nRequirements on the OP Chain contracts\nIn general, all contracts used in an OP Chain SHOULD be proxied with a single shared implementation.\nThis means that all values which are not constant across OP Chains SHOULD be held in storage rather\nthan the bytecode of the implementation.\nAny contracts which do not meet this requirement will need to be deployed by the upgrade()\nfunction, increasing the cost and reducing the number of OP Chains which can be atomically upgraded.\nAdding game types\nBecause different OP Chains within a Superchain may use different dispute game types, and are\nexpected to move from a permissioned to permissionless game over time, an addGameType() method is\nprovided to enable adding a new game type to multiple games at once.\nInterface\naddGameType\nThe addGameType method is used to orchestrate the actions required to add a new game type to one\nor more chains.\nstruct AddGameInput {\n string saltMixer;\n ISystemConfig systemConfig;\n IProxyAdmin proxyAdmin;\n IDelayedWETH delayedWETH;\n uint32 disputeGameType;\n bytes32 disputeAbsolutePrestate;\n uint256 disputeMaxGameDepth;\n uint256 disputeSplitDepth;\n uint64 disputeClockExtension;\n uint64 disputeMaxClockDuration;\n uint256 initialBond;\n IBigStepper vm;\n bool permissioned;\n}\n\nstruct AddGameOutput {\n IDelayedWETH delayedWETH;\n IFaultDisputeGame faultDisputeGame;\n}\n\n/// @notice addGameType deploys a new dispute game and links it to the DisputeGameFactory. The inputted _gameConfigs\n/// must be added in ascending GameType order.\nfunction addGameType(AddGameInput[] memory _gameConfigs) external returns (AddGameOutput[] memory)\n\nOn success, the following event is emitted:\nevent GameTypeAdded(uint256 indexed l2ChainId, uint32 indexed gameType, address indexed deployer);\n\nImplementation\nThe high level logic of the addGameType method is as follows (for each chain):\n\nDeploy and initialize new DelayedWethProxy for the new game type, if one hasn't already been specified.\nDeploy a new dispute game contract, based on the specified game type. The constructor args must be provided as\narguments, unless otherwise specified in the table below.\nRead the DisputeGameFactory address from the SystemConfig.\nCall DisputeGameFactory.setImplementation() to register the new game.\n\nNameTypeDescriptionSource\nwethaddressAddress of the DelayedWeth contractNewly deployed contract, or provided\nanchorStateRegistryaddressRegistry contract addressCopied from existing PermissionedGame\nl2ChainIduint256Chain ID of the L2 networkCopied from existing PermissionedGame\n\nSecurity Considerations\nChain ID Source of Truth\nOne of the implicit restrictions on chain ID is that deploy can only be called\nonce per chain ID, because contract addresses are a function of chain ID. However,\nfuture versions of OP Contracts Manager may:\n\nChange the Proxy code used, which would allow a duplicate chain ID to be deployed\nif there is only the implicit check.\nManage upgrades, which will require \"registering\" existing pre-OP Contracts Manager\nchains in the OP Contracts Manager. Registration will be a privileged action, and the superchain registry will be\nused as the source of truth for registrations.\n\nThis means, for example, if deploying a chain with a chain ID of 10—which is OP\nMainnet's chain ID—deployment will execute successfully, but the entry in OP\nContracts Manager may be overwritten in a future upgrade. Therefore, chain ID\nuniqueness is not enforced by the OP Contracts Manager, and it is strongly\nrecommended to only use chain IDs that are not already present in the\nethereum-lists/chains repository.\nChain ID Frontrunning\nContract addresses for a chain are a function of chain ID, which implies you\ncan counterfactually compute and use those chain addresses before the chain is\ndeployed. However, this property should not be relied upon—new chain deployments\nare permissionless, so you cannot guarantee usage of a given chain ID, as deploy\ntransactions can be frontrun.\nChain ID Value\nWhile not specific to OP Contracts Manager, when choosing a chain ID is important\nto consider that not all chain IDs are well supported by tools. For example,\nMetaMask only supports\nchain IDs up to 4503599627370476, well below the max allowable 256-bit value.\nOP Contracts Manager does not consider factors such as these. The EVM supports\n256-bit chain IDs, so OP Contracts Manager sticks with the full 256-bit range to\nmaximize compatibility.\nProxy Admin Owner\nThe proxy admin owner is a very powerful role, as it allows upgrading protocol\ncontracts. When choosing the initial proxy admin owner, a Safe is recommended\nto ensure admin privileges are sufficiently secured.\nSafely using DELEGATECALL\nBecause a Safe will DELEGATECALL to the upgrade() and addGameType() methods, it is\ncritical that no storage writes occur. This should be enforced in multiple ways, including:\n\nBy static analysis of the upgrade() and addGameType() methods during the development process.\nBy simulating and verifying the state changes which occur in the Proxy Admin Owner Safe prior to execution.\n\nAtomicity of upgrades\nAlthough atomicity of a superchain upgrade is not essential for many types of upgrade, it will\nat times be necessary. It is certainly always desirable for operational reasons.\nFor this reason, efficiency should be kept in mind when designing the upgrade path. When the size of\nthe superchain reaches a size that nears the block gas limit, upgrades may need to be broken up into\nstages, so that components which must be upgrade atomically can be. For example, all\nOptimismPortal contracts may need to be upgraded in one transaction, followed by another\ntransaction which upgrades all L1CrossDomainMessenger contracts.","tokens":3403,"squid":"ink-governance","role":"Council Listener","at":1791264467944,"hash":"09c50cf123e1b2d3c8fad24675cb0e05a7a90b07"}
{"url":"https://forum.openzeppelin.com/t/custom-crowdsale-purchase-fails/6088/1","domain":"forum.openzeppelin.com","title":"Custom Crowdsale purchase fails - Support - OpenZeppelin Forum","text":"Custom Crowdsale purchase fails \n\n Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2021\n\n 1 / 3\n\n Mar 2021\n\n Mar 2021\n\n post by Md_Sejabur_Rahat on Mar 4, 2021\n\n Md_Sejabur_Rahat\n\n Created a token and crowdsale contract on BSC Testnet. Everything is going fine but when I send BNB to the address it gets failed. Can anyone tell me what is the reason?\n\nCrowdsale Code:\npragma solidity >=0.4.22 <0.8.0;\n\ncontract Context {\n constructor () internal { }\n // solhint-disable-previous-line no-empty-blocks\n\n function _msgSender() internal view returns (address payable) {\n return msg.sender;\n }\n\n function _msgData() internal view returns (bytes memory) {\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n return msg.data;\n }\n}\n\ninterface IERC20 {\n function totalSupply() external view returns (uint);\n function balanceOf(address account) external view returns (uint);\n function transfer(address recipient, uint amount) external returns (bool);\n function allowance(address owner, address spender) external view returns (uint);\n function approve(address spender, uint amount) external returns (bool);\n function transferFrom(address sender, address recipient, uint amount) external returns (bool);\n event Transfer(address indexed from, address indexed to, uint value);\n event Approval(address indexed owner, address indexed spender, uint value);\n function TokensPurchased(address buyer, uint256 amount) external returns (bool success);\n function burn(uint256 _value) external returns (bool success);\n}\n\nlibrary SafeMath {\n function add(uint a, uint b) internal pure returns (uint) {\n uint c = a + b;\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n }\n function sub(uint a, uint b) internal pure returns (uint) {\n return sub(a, b, \"SafeMath: subtraction overflow\");\n }\n function sub(uint a, uint b, string memory errorMessage) internal pure returns (uint) {\n require(b <= a, errorMessage);\n uint c = a - b;\n\n return c;\n }\n function mul(uint a, uint b) internal pure returns (uint) {\n if (a == 0) {\n return 0;\n }\n\n uint c = a * b;\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n }\n function div(uint a, uint b) internal pure returns (uint) {\n return div(a, b, \"SafeMath: division by zero\");\n }\n function div(uint a, uint b, string memory errorMessage) internal pure returns (uint) {\n // Solidity only automatically asserts when dividing by 0\n require(b > 0, errorMessage);\n uint c = a / b;\n\n return c;\n }\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n return mod(a, b, \"SafeMath: modulo by zero\");\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b != 0, errorMessage);\n return a % b;\n }\n}\n\nlibrary Address {\n function isContract(address account) internal view returns (bool) {\n bytes32 codehash;\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n // solhint-disable-next-line no-inline-assembly\n assembly { codehash := extcodehash(account) }\n return (codehash != 0x0 && codehash != accountHash);\n }\n}\n\nlibrary SafeERC20 {\n using SafeMath for uint;\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n }\n\n function safeApprove(IERC20 token, address spender, uint value) internal {\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n );\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n }\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n // solhint-disable-next-line avoid-low-level-calls\n (bool success, bytes memory returndata) = address(token).call(data);\n require(success, \"SafeERC20: low-level call failed\");\n\n if (returndata.length > 0) { // Return data is optional\n // solhint-disable-next-line max-line-length\n require(abi.decode(returndata, (bool)), \"SafeERC20: ERC20 operation did not succeed\");\n }\n }\n}\n\ncontract ReentrancyGuard {\n bool private _notEntered;\n\n constructor () internal {\n\n _notEntered = true;\n }\n\n modifier nonReentrant() {\n // On the first call to nonReentrant, _notEntered will be true\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n _notEntered = false;\n\n _;\n\n _notEntered = true;\n }\n}\n\ncontract GRTD is Context, ReentrancyGuard{\n\n using SafeMath for uint256;\n using SafeERC20 for IERC20;\n address public governance;\n\n uint256 public rate;\n uint256 private _weiRaised;\n uint256 public totalSold;\n IERC20 public tokenAddress;\n //uint256 public startTime = 1608483600; //\n //uint256 public endTime = 16084077611; //\n\n uint256 public minimumBuyAmount = 10 ** 9; //0.01 BNB\n uint256 public maximumBuyAmount = 5 ether; //05 BNB\n address payable public walletAddress;\n event TokensPurchased(address indexed to, uint256 amount);\n\n constructor () public {\n governance = tx.origin;\n rate = uint256(25000);\n walletAddress = 0xB713Be19e6Ef7ffF6F286737885b940B9A5F9728; //TEAM\n tokenAddress = IERC20(0x0);\n }\n\n function () external payable {\n buy();\n }\n\n function changeWallet (address payable _walletAddress) public {\n require(msg.sender == governance, \"!governance\");\n walletAddress = _walletAddress;\n }\n\n function setToken(IERC20 _tokenAddress) public {\n require(msg.sender == governance, \"!governance\");\n tokenAddress = _tokenAddress;\n }\n\n function buy() public payable {\n //require((block.timestamp > startTime ) && (block.timestamp < endTime) , \"Token Crowdsate is not active\");\n uint256 weiValue = msg.value;\n require((weiValue >= minimumBuyAmount) &&(weiValue<= maximumBuyAmount), \"Minimum amount is 0.01 BNB and Maximum amount is 5 BNB\");\n uint256 amount = weiValue.mul(rate);\n _weiRaised = _weiRaised.add(weiValue);\n IERC20 token = IERC20(tokenAddress);\n token.safeTransfer(msg.sender, amount);\n walletAddress.transfer(weiValue);\n //require(walletAddress.send(weiValue)); //_fundRaisingWallet.transfer(msg.value);\n //require(token.TokensPurchased(msg.sender, amount));\n totalSold += amount;\n emit TokensPurchased(msg.sender, amount);\n }\n\n function burnUnsold() private {\n require(msg.sender == governance, \"!governance\");\n //require((block.timestamp > endTime), Crowdsate is still active\");\n IERC20 token = IERC20(tokenAddress);\n uint256 amount = token.balanceOf(address(this));\n token.burn(amount);\n }\n\n}\n\nToken Code:\npragma solidity 0.5.16;\n\n// ----------------------------------------------------------------------------\n// 'Gratitude' Token contract\n//\n// Symbol : GRTD\n// Name :Gratitude\n// Total supply: 10,00,00,000\n// Decimals : 08\n//\n// ----------------------------------------------------------------------------\n\ninterface IBEP20 {\n\n function totalSupply() external view returns (uint256);\n\n function decimals() external view returns (uint8);\n\n function symbol() external view returns (string memory);\n\n function name() external view returns (string memory);\n\n function getOwner() external view returns (address);\n\n function balanceOf(address account) external view returns (uint256);\n\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n function allowance(address _owner, address spender) external view returns (uint256);\n\n function approve(address spender, uint256 amount) external returns (bool);\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n event Approval(address indexed owner, address indexed spender, uint256 value);\n}\n\ncontract Context {\n // Empty internal constructor, to prevent people from mistakenly deploying\n // an instance of this contract, which should be used via inheritance.\n constructor () internal { }\n\n function _msgSender() internal view returns (address payable) {\n return msg.sender;\n }\n\n function _msgData() internal view returns (bytes memory) {\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n return msg.data;\n }\n}\n\nlibrary SafeMath {\n\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n uint256 c = a + b;\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n }\n\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n return sub(a, b, \"SafeMath: subtraction overflow\");\n }\n\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b <= a, errorMessage);\n uint256 c = a - b;\n\n return c;\n }\n\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n // Gas optimization: this is cheaper than requiring 'a' not being zero, but the\n // benefit is lost if 'b' is also tested.\n if (a == 0) {\n return 0;\n }\n\n uint256 c = a * b;\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n }\n\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n return div(a, b, \"SafeMath: division by zero\");\n }\n\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n // Solidity only automatically asserts when dividing by 0\n require(b > 0, errorMessage);\n uint256 c = a / b;\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n }\n\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n return mod(a, b, \"SafeMath: modulo by zero\");\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b != 0, errorMessage);\n return a % b;\n }\n}\n\ncontract Ownable is Context {\n address private _owner;\n\n event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);\n\n constructor () internal {\n address msgSender = _msgSender();\n _owner = msgSender;\n emit OwnershipTransferred(address(0), msgSender);\n }\n\n function owner() public view returns (address) {\n return _owner;\n }\n\n modifier onlyOwner() {\n require(_owner == _msgSender(), \"Ownable: caller is not the owner\");\n _;\n }\n\n function renounceOwnership() public onlyOwner {\n emit OwnershipTransferred(_owner, address(0));\n _owner = address(0);\n }\n\n function transferOwnership(address newOwner) public onlyOwner {\n _transferOwnership(newOwner);\n }\n\n function _transferOwnership(address newOwner) internal {\n require(newOwner != address(0), \"Ownable: new owner is the zero address\");\n emit OwnershipTransferred(_owner, newOwner);\n _owner = newOwner;\n }\n}\n\ncontract GRTD is Context, IBEP20, Ownable {\n using SafeMath for uint256;\n\n mapping (address => uint256) private _balances;\n\n mapping (address => mapping (address => uint256)) private _allowances;\n\n uint256 private _totalSupply;\n uint8 public _decimals;\n string public _symbol;\n string public _name;\n\n constructor() public {\n _name = \"Gratitude\";\n _symbol = \"GRTD\";\n _decimals = 8;\n _totalSupply = 100000000 * 10**8;\n _balances[msg.sender] = _totalSupply;\n\n emit Transfer(address(0), msg.sender, _totalSupply);\n }\n\n function getOwner() external view returns (address) {\n return owner();\n }\n\n function decimals() external view returns (uint8) {\n return _decimals;\n }\n\n function symbol() external view returns (string memory) {\n return _symbol;\n }\n\n function name() external view returns (string memory) {\n return _name;\n }\n\n function totalSupply() external view returns (uint256) {\n return _totalSupply;\n }\n\n function balanceOf(address account) external view returns (uint256) {\n return _balances[account];\n }\n\n function transfer(address recipient, uint256 amount) external returns (bool) {\n _transfer(_msgSender(), recipient, amount);\n return true;\n } \n\n function allowance(address owner, address spender) external view returns (uint256) {\n return _allowances[owner][spender];\n }\n\n function approve(address spender, uint256 amount) external returns (bool) {\n _approve(_msgSender(), spender, amount);\n return true;\n }\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool) {\n _transfer(sender, recipient, amount);\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"BEP20: transfer amount exceeds allowance\"));\n return true;\n }\n\n function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n return true;\n }\n\n function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"BEP20: decreased allowance below zero\"));\n return true;\n }\n\n function burn(uint256 amount) public returns (bool) {\n _burn(_msgSender(), amount);\n return true;\n }\n\n function _transfer(address sender, address recipient, uint256 amount) internal {\n require(sender != address(0), \"BEP20: transfer from the zero address\");\n require(recipient != address(0), \"BEP20: transfer to the zero address\");\n\n _balances[sender] = _balances[sender].sub(amount, \"BEP20: transfer amount exceeds balance\");\n _balances[recipient] = _balances[recipient].add(amount);\n emit Transfer(sender, recipient, amount);\n }\n\n function _burn(address account, uint256 amount) internal {\n require(account != address(0), \"BEP20: burn from the zero address\");\n\n _balances[account] = _balances[account].sub(amount, \"BEP20: burn amount exceeds balance\");\n _totalSupply = _totalSupply.sub(amount);\n emit Transfer(account, address(0), amount);\n }\n\n function _approve(address owner, address spender, uint256 amount) internal {\n require(owner != address(0), \"BEP20: approve from the zero address\");\n require(spender != address(0), \"BEP20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\n emit Approval(owner, spender, amount);\n }\n\n function _burnFrom(address account, uint256 amount) internal {\n _burn(account, amount);\n _approve(account, _msgSender(), _allowances[account][_msgSender()].sub(amount, \"BEP20: burn amount exceeds allowance\"));\n }\n}\n\n 2\n\n read \n\n 4\n min\n\n post by abcoathup on Mar 4, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @Md_Sejabur_Rahat,\nIf you haven’t already I recommend creating using tests for your crowdsale to appropriately test your contract. You should check your rate and minimum and maximum buy amounts to check your validation. Also, your crowdsale appears as though it should be holding tokens to sell, so ensure that it has enough tokens to fulfill the purchase.\nYou can have a look at Simple ERC20 Crowdsale for an example of unit tests.\n\nAs an aside, please Format code in the forum.\n\n post by Md_Sejabur_Rahat on Mar 6, 2021\n\n Md_Sejabur_Rahat\n\n The problem is solved. It is working perfectly on the mainnet but don’t know it was not working on the testnet.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale send BNB fail\n\n Contracts\n\n crowdsale\n\n 8\n\n 6.4k\n\n Mar 2021\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 614\n\n Feb 2022\n\n Crowdsale Error when calling buyTokens() or just simply invoking fallback function\n\n Support\n\n erc20,crowdsale\n\n 1\n\n 1.3k\n\n Feb 2022\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021","tokens":4098,"squid":"ink-security_audits","role":"Sentinel","at":1791264475594,"hash":"50820fbf3788ebe6eb9d0cdf261b0b67b57c3464"}
{"url":"https://specs.optimism.io/experimental/gov-token.html","domain":"specs.optimism.io","title":"Governance Token - OP Stack Specification","text":"Governance Token\n\nTable of Contents\n\nOverview\n\nHook-based Integration with GovernanceDelegation\nToken Minting\nToken Burning\nVoting Power\n\nQueries\n\nDelegation\n\nOverview\nConstantsValue\nAddress0x4200000000000000000000000000000000000042\nToken nameOptimism\nToken symbolOP\nToken decimals18\n\nGovernanceToken is an ERC20 token contract that inherits from ERC20Burnable,\nERC20Votes, and Ownable. It allows token holders to delegate their voting power to other addresses, enabling a representative\nvoting system. The contract integrates with the GovernanceDelegation contract through a hook-based approach to support\nadvanced delegation.\nHook-based Integration with GovernanceDelegation\nAdvanced delegation includes relative and absolute partial delegation, which allow delegators to distribute their voting\npower among multiple delegates in a fractional manner. The _afterTokenTransfer function in the GovernanceToken is\nmodified to call the afterTokenTransfer function in the GovernanceDelegation contract, allowing the GovernanceDelegation\ncontract to consume the hooks and update its delegation and checkpoint mappings accordingly.\nIf the call to the GovernanceDelegation's afterTokenTransfer function fails, the token transfer MUST revert. This ensures\nthat the GovernanceDelegation contract remains in sync with the GovernanceToken. Otherwise, the GovernanceToken could\nbe left in an inconsistent state relative to the GovernanceDelegation contract, such as when a token transfer is successful\nbut the delegation state is not updated.\nAll delegation-related state, including the delegates, checkpoints, and numCheckpoints mappings, is gradually\nshifted from the GovernanceToken to the GovernanceDelegation contract through transactions that call the\nGovernanceDelegation's hook (e.g. transfers). In the hook, the GovernanceDelegation contract should check if the to\nand from addresses have been migrated. If an address hasn't been migrated, the GovernanceDelegation contract should\nwrite the data from the GovernanceToken's mappings for that address to its own state. When reading delegation data in the\nGovernanceDelegation contract for a delegator that hasn't been migrated, the GovernanceDelegation should pull the data\nfrom the GovernanceToken's state.\nFor backwards compatibility, the getter methods in the GovernanceToken MUST check if the data of a given address has been\nmigrated or not. If the data has been migrated, the GovernanceToken MUST forward the call to the GovernanceDelegation\ncontract. Otherwise, the GovernanceToken MUST read from its state.\nThe delegate and delegateBySig functions in the GovernanceToken MUST forward the calls to the GovernanceDelegation\ncontract, which implements the required delegation logic.\nToken Minting\nGovernanceToken MUST have a mint(address,uint256) function with external visibility that allows the contract owner\nto mint an arbitrary number of new tokens to a specific address. This function MUST only be called by the contract\nowner, the MintManager, as enforced by the onlyOwner modifier inherited from the Ownable contract. When tokens\nare minted, the voting power of the recipient address MUST be updated accordingly in the GovernanceDelegation contract\nvia the afterTokenTransfer hook. The total token supply is capped to 2^208 - 1 to prevent overflow risks in the voting\nsystem. If the total supply exceeds this limit, _mint(address,uint256), as inherited from ERC20Votes, MUST revert.\nToken Burning\nThe contract MUST allow token holders to burn their own tokens using the inherited burn(uint256) or\nburnFrom(address,uint256) functions inherited from ERC20Burnable. When tokens are burned, the total supply and the\nholder's voting power MUST be reduced accordingly in the GovernanceDelegation contract via the afterTokenTransfer hook.\nVoting Power\nEach token corresponds to one unit of voting power.\nBy default, token balance does not account for voting power. To have their voting power counted, token holders MUST delegate\ntheir voting power to an address (can be their own address).\nThe contract MUST offer public accessors for querying voting power, as outlined below.\nQueries\n\nThe getVotes(address)(uint256) function MUST retrieve the current voting power of an address from the\nGovernanceDelegation contract.\nThe getPastVotes(address,uint256)(uint256) function MUST allow querying the voting power of an address at a specific\nblock number in the past from the GovernanceDelegation contract.\nThe getPastTotalSupply(uint256)(uint256) function MUST return the total voting power at a specific block number in\nthe past from the GovernanceDelegation contract.\n\nDelegation\nVoting power can be delegated either by calling the delegate(address) function directly (to delegate as the msg.sender)\nor by providing a signature to be used with function delegateBySig(address,uint256,uint256,uint8,bytes32,bytes32),\nas inherited from ERC20Votes. These functions are modified to forward the calls to the GovernanceDelegation contract\nwhich implements the required logic.\nThe GovernanceDelegation contract maintains the necessary invariants, such as preventing circular delegation chains, ensuring\nvote weight consistency, and managing checkpoints. It is incorporated as a predeploy of the OP stack to avoid manual deployments\nacross the Superchain.","tokens":1324,"squid":"ink-governance","role":"Council Listener","at":1791264481076,"hash":"1c09997ff122bbe39955747fb88b263260c4c245"}
{"url":"https://forum.openzeppelin.com/t/custom-crowdsale-purchase-fails/6088/3","domain":"forum.openzeppelin.com","title":"Custom Crowdsale purchase fails - Support - OpenZeppelin Forum","text":"Support\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2021\n\n 3 / 3\n\n Mar 2021\n\n Mar 2021\n\n post by Md_Sejabur_Rahat on Mar 4, 2021\n\n Md_Sejabur_Rahat\n\n Created a token and crowdsale contract on BSC Testnet. Everything is going fine but when I send BNB to the address it gets failed. Can anyone tell me what is the reason?\n\nCrowdsale Code:\npragma solidity >=0.4.22 <0.8.0;\n\ncontract Context {\n constructor () internal { }\n // solhint-disable-previous-line no-empty-blocks\n\n function _msgSender() internal view returns (address payable) {\n return msg.sender;\n }\n\n function _msgData() internal view returns (bytes memory) {\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n return msg.data;\n }\n}\n\ninterface IERC20 {\n function totalSupply() external view returns (uint);\n function balanceOf(address account) external view returns (uint);\n function transfer(address recipient, uint amount) external returns (bool);\n function allowance(address owner, address spender) external view returns (uint);\n function approve(address spender, uint amount) external returns (bool);\n function transferFrom(address sender, address recipient, uint amount) external returns (bool);\n event Transfer(address indexed from, address indexed to, uint value);\n event Approval(address indexed owner, address indexed spender, uint value);\n function TokensPurchased(address buyer, uint256 amount) external returns (bool success);\n function burn(uint256 _value) external returns (bool success);\n}\n\nlibrary SafeMath {\n function add(uint a, uint b) internal pure returns (uint) {\n uint c = a + b;\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n }\n function sub(uint a, uint b) internal pure returns (uint) {\n return sub(a, b, \"SafeMath: subtraction overflow\");\n }\n function sub(uint a, uint b, string memory errorMessage) internal pure returns (uint) {\n require(b <= a, errorMessage);\n uint c = a - b;\n\n return c;\n }\n function mul(uint a, uint b) internal pure returns (uint) {\n if (a == 0) {\n return 0;\n }\n\n uint c = a * b;\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n }\n function div(uint a, uint b) internal pure returns (uint) {\n return div(a, b, \"SafeMath: division by zero\");\n }\n function div(uint a, uint b, string memory errorMessage) internal pure returns (uint) {\n // Solidity only automatically asserts when dividing by 0\n require(b > 0, errorMessage);\n uint c = a / b;\n\n return c;\n }\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n return mod(a, b, \"SafeMath: modulo by zero\");\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b != 0, errorMessage);\n return a % b;\n }\n}\n\nlibrary Address {\n function isContract(address account) internal view returns (bool) {\n bytes32 codehash;\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n // solhint-disable-next-line no-inline-assembly\n assembly { codehash := extcodehash(account) }\n return (codehash != 0x0 && codehash != accountHash);\n }\n}\n\nlibrary SafeERC20 {\n using SafeMath for uint;\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n }\n\n function safeApprove(IERC20 token, address spender, uint value) internal {\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n );\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n }\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n // solhint-disable-next-line avoid-low-level-calls\n (bool success, bytes memory returndata) = address(token).call(data);\n require(success, \"SafeERC20: low-level call failed\");\n\n if (returndata.length > 0) { // Return data is optional\n // solhint-disable-next-line max-line-length\n require(abi.decode(returndata, (bool)), \"SafeERC20: ERC20 operation did not succeed\");\n }\n }\n}\n\ncontract ReentrancyGuard {\n bool private _notEntered;\n\n constructor () internal {\n\n _notEntered = true;\n }\n\n modifier nonReentrant() {\n // On the first call to nonReentrant, _notEntered will be true\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n _notEntered = false;\n\n _;\n\n _notEntered = true;\n }\n}\n\ncontract GRTD is Context, ReentrancyGuard{\n\n using SafeMath for uint256;\n using SafeERC20 for IERC20;\n address public governance;\n\n uint256 public rate;\n uint256 private _weiRaised;\n uint256 public totalSold;\n IERC20 public tokenAddress;\n //uint256 public startTime = 1608483600; //\n //uint256 public endTime = 16084077611; //\n\n uint256 public minimumBuyAmount = 10 ** 9; //0.01 BNB\n uint256 public maximumBuyAmount = 5 ether; //05 BNB\n address payable public walletAddress;\n event TokensPurchased(address indexed to, uint256 amount);\n\n constructor () public {\n governance = tx.origin;\n rate = uint256(25000);\n walletAddress = 0xB713Be19e6Ef7ffF6F286737885b940B9A5F9728; //TEAM\n tokenAddress = IERC20(0x0);\n }\n\n function () external payable {\n buy();\n }\n\n function changeWallet (address payable _walletAddress) public {\n require(msg.sender == governance, \"!governance\");\n walletAddress = _walletAddress;\n }\n\n function setToken(IERC20 _tokenAddress) public {\n require(msg.sender == governance, \"!governance\");\n tokenAddress = _tokenAddress;\n }\n\n function buy() public payable {\n //require((block.timestamp > startTime ) && (block.timestamp < endTime) , \"Token Crowdsate is not active\");\n uint256 weiValue = msg.value;\n require((weiValue >= minimumBuyAmount) &&(weiValue<= maximumBuyAmount), \"Minimum amount is 0.01 BNB and Maximum amount is 5 BNB\");\n uint256 amount = weiValue.mul(rate);\n _weiRaised = _weiRaised.add(weiValue);\n IERC20 token = IERC20(tokenAddress);\n token.safeTransfer(msg.sender, amount);\n walletAddress.transfer(weiValue);\n //require(walletAddress.send(weiValue)); //_fundRaisingWallet.transfer(msg.value);\n //require(token.TokensPurchased(msg.sender, amount));\n totalSold += amount;\n emit TokensPurchased(msg.sender, amount);\n }\n\n function burnUnsold() private {\n require(msg.sender == governance, \"!governance\");\n //require((block.timestamp > endTime), Crowdsate is still active\");\n IERC20 token = IERC20(tokenAddress);\n uint256 amount = token.balanceOf(address(this));\n token.burn(amount);\n }\n\n}\n\nToken Code:\npragma solidity 0.5.16;\n\n// ----------------------------------------------------------------------------\n// 'Gratitude' Token contract\n//\n// Symbol : GRTD\n// Name :Gratitude\n// Total supply: 10,00,00,000\n// Decimals : 08\n//\n// ----------------------------------------------------------------------------\n\ninterface IBEP20 {\n\n function totalSupply() external view returns (uint256);\n\n function decimals() external view returns (uint8);\n\n function symbol() external view returns (string memory);\n\n function name() external view returns (string memory);\n\n function getOwner() external view returns (address);\n\n function balanceOf(address account) external view returns (uint256);\n\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n function allowance(address _owner, address spender) external view returns (uint256);\n\n function approve(address spender, uint256 amount) external returns (bool);\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n event Approval(address indexed owner, address indexed spender, uint256 value);\n}\n\ncontract Context {\n // Empty internal constructor, to prevent people from mistakenly deploying\n // an instance of this contract, which should be used via inheritance.\n constructor () internal { }\n\n function _msgSender() internal view returns (address payable) {\n return msg.sender;\n }\n\n function _msgData() internal view returns (bytes memory) {\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n return msg.data;\n }\n}\n\nlibrary SafeMath {\n\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n uint256 c = a + b;\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n }\n\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n return sub(a, b, \"SafeMath: subtraction overflow\");\n }\n\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b <= a, errorMessage);\n uint256 c = a - b;\n\n return c;\n }\n\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n // Gas optimization: this is cheaper than requiring 'a' not being zero, but the\n // benefit is lost if 'b' is also tested.\n if (a == 0) {\n return 0;\n }\n\n uint256 c = a * b;\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n }\n\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n return div(a, b, \"SafeMath: division by zero\");\n }\n\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n // Solidity only automatically asserts when dividing by 0\n require(b > 0, errorMessage);\n uint256 c = a / b;\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n }\n\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n return mod(a, b, \"SafeMath: modulo by zero\");\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b != 0, errorMessage);\n return a % b;\n }\n}\n\ncontract Ownable is Context {\n address private _owner;\n\n event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);\n\n constructor () internal {\n address msgSender = _msgSender();\n _owner = msgSender;\n emit OwnershipTransferred(address(0), msgSender);\n }\n\n function owner() public view returns (address) {\n return _owner;\n }\n\n modifier onlyOwner() {\n require(_owner == _msgSender(), \"Ownable: caller is not the owner\");\n _;\n }\n\n function renounceOwnership() public onlyOwner {\n emit OwnershipTransferred(_owner, address(0));\n _owner = address(0);\n }\n\n function transferOwnership(address newOwner) public onlyOwner {\n _transferOwnership(newOwner);\n }\n\n function _transferOwnership(address newOwner) internal {\n require(newOwner != address(0), \"Ownable: new owner is the zero address\");\n emit OwnershipTransferred(_owner, newOwner);\n _owner = newOwner;\n }\n}\n\ncontract GRTD is Context, IBEP20, Ownable {\n using SafeMath for uint256;\n\n mapping (address => uint256) private _balances;\n\n mapping (address => mapping (address => uint256)) private _allowances;\n\n uint256 private _totalSupply;\n uint8 public _decimals;\n string public _symbol;\n string public _name;\n\n constructor() public {\n _name = \"Gratitude\";\n _symbol = \"GRTD\";\n _decimals = 8;\n _totalSupply = 100000000 * 10**8;\n _balances[msg.sender] = _totalSupply;\n\n emit Transfer(address(0), msg.sender, _totalSupply);\n }\n\n function getOwner() external view returns (address) {\n return owner();\n }\n\n function decimals() external view returns (uint8) {\n return _decimals;\n }\n\n function symbol() external view returns (string memory) {\n return _symbol;\n }\n\n function name() external view returns (string memory) {\n return _name;\n }\n\n function totalSupply() external view returns (uint256) {\n return _totalSupply;\n }\n\n function balanceOf(address account) external view returns (uint256) {\n return _balances[account];\n }\n\n function transfer(address recipient, uint256 amount) external returns (bool) {\n _transfer(_msgSender(), recipient, amount);\n return true;\n } \n\n function allowance(address owner, address spender) external view returns (uint256) {\n return _allowances[owner][spender];\n }\n\n function approve(address spender, uint256 amount) external returns (bool) {\n _approve(_msgSender(), spender, amount);\n return true;\n }\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool) {\n _transfer(sender, recipient, amount);\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"BEP20: transfer amount exceeds allowance\"));\n return true;\n }\n\n function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n return true;\n }\n\n function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"BEP20: decreased allowance below zero\"));\n return true;\n }\n\n function burn(uint256 amount) public returns (bool) {\n _burn(_msgSender(), amount);\n return true;\n }\n\n function _transfer(address sender, address recipient, uint256 amount) internal {\n require(sender != address(0), \"BEP20: transfer from the zero address\");\n require(recipient != address(0), \"BEP20: transfer to the zero address\");\n\n _balances[sender] = _balances[sender].sub(amount, \"BEP20: transfer amount exceeds balance\");\n _balances[recipient] = _balances[recipient].add(amount);\n emit Transfer(sender, recipient, amount);\n }\n\n function _burn(address account, uint256 amount) internal {\n require(account != address(0), \"BEP20: burn from the zero address\");\n\n _balances[account] = _balances[account].sub(amount, \"BEP20: burn amount exceeds balance\");\n _totalSupply = _totalSupply.sub(amount);\n emit Transfer(account, address(0), amount);\n }\n\n function _approve(address owner, address spender, uint256 amount) internal {\n require(owner != address(0), \"BEP20: approve from the zero address\");\n require(spender != address(0), \"BEP20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\n emit Approval(owner, spender, amount);\n }\n\n function _burnFrom(address account, uint256 amount) internal {\n _burn(account, amount);\n _approve(account, _msgSender(), _allowances[account][_msgSender()].sub(amount, \"BEP20: burn amount exceeds allowance\"));\n }\n}\n\n 2\n\n read \n\n 4\n min\n\n post by abcoathup on Mar 4, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @Md_Sejabur_Rahat,\nIf you haven’t already I recommend creating using tests for your crowdsale to appropriately test your contract. You should check your rate and minimum and maximum buy amounts to check your validation. Also, your crowdsale appears as though it should be holding tokens to sell, so ensure that it has enough tokens to fulfill the purchase.\nYou can have a look at Simple ERC20 Crowdsale for an example of unit tests.\n\nAs an aside, please Format code in the forum.\n\n post by Md_Sejabur_Rahat on Mar 6, 2021\n\n Md_Sejabur_Rahat\n\n The problem is solved. It is working perfectly on the mainnet but don’t know it was not working on the testnet.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale send BNB fail\n\n Contracts\n\n crowdsale\n\n 8\n\n 6.4k\n\n Mar 2021\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 614\n\n Feb 2022\n\n Crowdsale Error when calling buyTokens() or just simply invoking fallback function\n\n Support\n\n erc20,crowdsale\n\n 1\n\n 1.3k\n\n Feb 2022\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021","tokens":4089,"squid":"ink-security_audits","role":"Sentinel","at":1791264487268,"hash":"b271fff813f08dee61c249ae3d926cd7e0ff85f9"}
{"url":"https://specs.optimism.io/protocol/jovian/l1-attributes.html","domain":"specs.optimism.io","title":"L1 Attributes - OP Stack Specification","text":"L1 Block Attributes\n\nTable of Contents\n\nOverview\n\nOverview\nThe L1 block attributes transaction is updated to include the DA footprint gas scalar.\nInput argTypeCalldata bytesSegment\n{0x3db6be2b}0-3n/a\nbaseFeeScalaruint324-71\nblobBaseFeeScalaruint328-11\nsequenceNumberuint6412-19\nl1BlockTimestampuint6420-27\nl1BlockNumberuint6428-35\nbasefeeuint25636-672\nblobBaseFeeuint25668-993\nl1BlockHashbytes32100-1314\nbatcherHashbytes32132-1635\noperatorFeeScalaruint32164-1676\noperatorFeeConstantuint64168-175\ndaFootprintGasScalaruint16176-177\n\nNote that the first input argument, in the same pattern as previous versions of the L1 attributes transaction,\nis the function selector: the first four bytes of keccak256(\"setL1BlockValuesJovian()\").\nIn the activation block, there are two possibilities:\n\nIf Jovian is active at genesis, there are no transactions in the activation block\nand therefore no L1 Block Attributes transaction to consider.\nIf Jovian activates after genesis setL1BlockValuesIsthmus() method must be used.\nThis is because the L1 Block contract will not yet have been upgraded.\n\nIn each subsequent L2 block, the setL1BlockValuesJovian() method must be used.\nWhen using this method, the pre-Jovian values are migrated over 1:1\nand the transaction also sets daFootprintGasScalar to the\nvalue from the SystemConfig. If that value is 0, then a default of 400 is set.","tokens":342,"squid":"ink-governance","role":"Council Listener","at":1791264491226,"hash":"c0bd14b9c3957c1e24fe7271a38d1ac2eebf4dfe"}
{"url":"https://forum.openzeppelin.com/t/95-5000-resultados-de-traduccion-my-crowdsale-receives-the-payment-in-ether-in-my-wallet-but-does-not-send-my-erc20-token-to-whoever-buys/10351","domain":"forum.openzeppelin.com","title":"95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys - Support - OpenZeppelin Forum","text":"95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys \n\n Support\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2021\n\n 1 / 2\n\n Jun 2021\n\n Feb 2022\n\n post by forestheart on Jun 11, 2021\n\n forestheart\n\n 219 / 5000\nHello community, this is the crowdsale contract, I would really appreciate if you help me know why when I send ether to the crowdsale address it sends the payment to my wallet but it does not send my tokens in return\n0x8cc4956482e2781E19c/**\n *Submitted for verification at polygonscan.com on 2021-06-11\n*/\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/utils/ReentrancyGuard.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @dev Contract module that helps prevent reentrant calls to a function.\n *\n * Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier\n * available, which can be applied to functions to make sure there are no nested\n * (reentrant) calls to them.\n *\n * Note that because there is a single `nonReentrant` guard, functions marked as\n * `nonReentrant` may not call one another. This can be worked around by making\n * those functions `private`, and then adding `external` `nonReentrant` entry\n * points to them.\n *\n * TIP: If you would like to learn more about reentrancy and alternative ways\n * to protect against it, check out our blog post\n * https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].\n *\n * _Since v2.5.0:_ this module is now much more gas efficient, given net gas\n * metering changes introduced in the Istanbul hardfork.\n */\ncontract ReentrancyGuard {\n bool private _notEntered;\n\n constructor () internal {\n // Storing an initial non-zero value makes deployment a bit more\n // expensive, but in exchange the refund on every call to nonReentrant\n // will be lower in amount. Since refunds are capped to a percetange of\n // the total transaction's gas, it is best to keep them low in cases\n // like this one, to increase the likelihood of the full refund coming\n // into effect.\n _notEntered = true;\n }\n\n /**\n * @dev Prevents a contract from calling itself, directly or indirectly.\n * Calling a `nonReentrant` function from another `nonReentrant`\n * function is not supported. It is possible to prevent this from happening\n * by making the `nonReentrant` function external, and make it call a\n * `private` function that does the actual work.\n */\n modifier nonReentrant() {\n // On the first call to nonReentrant, _notEntered will be true\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n _notEntered = false;\n\n _;\n\n // By storing the original value once again, a refund is triggered (see\n // https://eips.ethereum.org/EIPS/eip-2200)\n _notEntered = true;\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/utils/Address.sol\n\npragma solidity ^0.5.5;\n\n/**\n * @dev Collection of functions related to the address type\n */\nlibrary Address {\n /**\n * @dev Returns true if `account` is a contract.\n *\n * [IMPORTANT]\n * ====\n * It is unsafe to assume that an address for which this function returns\n * false is an externally-owned account (EOA) and not a contract.\n *\n * Among others, `isContract` will return false for the following \n * types of addresses:\n *\n * - an externally-owned account\n * - a contract in construction\n * - an address where a contract will be created\n * - an address where a contract lived, but was destroyed\n * ====\n */\n function isContract(address account) internal view returns (bool) {\n // According to EIP-1052, 0x0 is the value returned for not-yet created accounts\n // and 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 is returned\n // for accounts without code, i.e. `keccak256('')`\n bytes32 codehash;\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n // solhint-disable-next-line no-inline-assembly\n assembly { codehash := extcodehash(account) }\n return (codehash != accountHash && codehash != 0x0);\n }\n\n /**\n * @dev Converts an `address` into `address payable`. Note that this is\n * simply a type cast: the actual underlying value is not changed.\n *\n * _Available since v2.4.0._\n */\n function toPayable(address account) internal pure returns (address payable) {\n return address(uint160(account));\n }\n\n /**\n * @dev Replacement for Solidity's `transfer`: sends `amount` wei to\n * `recipient`, forwarding all available gas and reverting on errors.\n *\n * https://eips.ethereum.org/EIPS/eip-1884[EIP1884] increases the gas cost\n * of certain opcodes, possibly making contracts go over the 2300 gas limit\n * imposed by `transfer`, making them unable to receive funds via\n * `transfer`. {sendValue} removes this limitation.\n *\n * https://diligence.consensys.net/posts/2019/09/stop-using-soliditys-transfer-now/[Learn more].\n *\n * IMPORTANT: because control is transferred to `recipient`, care must be\n * taken to not create reentrancy vulnerabilities. Consider using\n * {ReentrancyGuard} or the\n * https://solidity.readthedocs.io/en/v0.5.11/security-considerations.html#use-the-checks-effects-interactions-pattern[checks-effects-interactions pattern].\n *\n * _Available since v2.4.0._\n */\n function sendValue(address payable recipient, uint256 amount) internal {\n require(address(this).balance >= amount, \"Address: insufficient balance\");\n\n // solhint-disable-next-line avoid-call-value\n (bool success, ) = recipient.call.value(amount)(\"\");\n require(success, \"Address: unable to send value, recipient may have reverted\");\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/SafeERC20.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @title SafeERC20\n * @dev Wrappers around ERC20 operations that throw on failure (when the token\n * contract returns false). Tokens that return no value (and instead revert or\n * throw on failure) are also supported, non-reverting calls are assumed to be\n * successful.\n * To use this library you can add a `using SafeERC20 for ERC20;` statement to your contract,\n * which allows you to call the safe operations as `token.safeTransfer(...)`, etc.\n */\nlibrary SafeERC20 {\n using SafeMath for uint256;\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint256 value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n }\n\n function safeApprove(IERC20 token, address spender, uint256 value) internal {\n // safeApprove should only be called when setting an initial allowance,\n // or when resetting it to zero. To increase and decrease it, use\n // 'safeIncreaseAllowance' and 'safeDecreaseAllowance'\n // solhint-disable-next-line max-line-length\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n );\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n }\n\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n\n /**\n * @dev Imitates a Solidity high-level call (i.e. a regular function call to a contract), relaxing the requirement\n * on the return value: the return value is optional (but if data is returned, it must not be false).\n * @param token The token targeted by the call.\n * @param data The call data (encoded using abi.encode or one of its variants).\n */\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n // We need to perform a low level call here, to bypass Solidity's return data size checking mechanism, since\n // we're implementing it ourselves.\n\n // A Solidity high level call has three parts:\n // 1. The target address is checked to verify it contains contract code\n // 2. The call itself is made, and success asserted\n // 3. The return value is decoded, which in turn checks the size of the returned data.\n // solhint-disable-next-line max-line-length\n //require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n // solhint-disable-next-line avoid-low-level-calls\n //(bool success, bytes memory returndata) = address(token).call(data);\n\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/math/SafeMath.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @dev Wrappers over Solidity's arithmetic operations with added overflow\n * checks.\n *\n * Arithmetic operations in Solidity wrap on overflow. This can easily result\n * in bugs, because programmers usually assume that an overflow raises an\n * error, which is the standard behavior in high level programming languages.\n * `SafeMath` restores this intuition by reverting the transaction when an\n * operation overflows.\n *\n * Using this library instead of the unchecked operations eliminates an entire\n * class of bugs, so it's recommended to use it always.\n */\nlibrary SafeMath {\n /**\n * @dev Returns the addition of two unsigned integers, reverting on\n * overflow.\n *\n * Counterpart to Solidity's `+` operator.\n *\n * Requirements:\n * - Addition cannot overflow.\n */\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n uint256 c = a + b;\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n }\n\n /**\n * @dev Returns the subtraction of two unsigned integers, reverting on\n * overflow (when the result is negative).\n *\n * Counterpart to Solidity's `-` operator.\n *\n * Requirements:\n * - Subtraction cannot overflow.\n */\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n return sub(a, b, \"SafeMath: subtraction overflow\");\n }\n\n /**\n * @dev Returns the subtraction of two unsigned integers, reverting with custom message on\n * overflow (when the result is negative).\n *\n * Counterpart to Solidity's `-` operator.\n *\n * Requirements:\n * - Subtraction cannot overflow.\n *\n * _Available since v2.4.0._\n */\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b <= a, errorMessage);\n uint256 c = a - b;\n\n return c;\n }\n\n /**\n * @dev Returns the multiplication of two unsigned integers, reverting on\n * overflow.\n *\n * Counterpart to Solidity's `*` operator.\n *\n * Requirements:\n * - Multiplication cannot overflow.\n */\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n // Gas optimization: this is cheaper than requiring 'a' not being zero, but the\n // benefit is lost if 'b' is also tested.\n // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522\n if (a == 0) {\n return 0;\n }\n\n uint256 c = a * b;\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n }\n\n /**\n * @dev Returns the integer division of two unsigned integers. Reverts on\n * division by zero. The result is rounded towards zero.\n *\n * Counterpart to Solidity's `/` operator. Note: this function uses a\n * `revert` opcode (which leaves remaining gas untouched) while Solidity\n * uses an invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n */\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n return div(a, b, \"SafeMath: division by zero\");\n }\n\n /**\n * @dev Returns the integer division of two unsigned integers. Reverts with custom message on\n * division by zero. The result is rounded towards zero.\n *\n * Counterpart to Solidity's `/` operator. Note: this function uses a\n * `revert` opcode (which leaves remaining gas untouched) while Solidity\n * uses an invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n *\n * _Available since v2.4.0._\n */\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n // Solidity only automatically asserts when dividing by 0\n require(b > 0, errorMessage);\n uint256 c = a / b;\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n }\n\n /**\n * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),\n * Reverts when dividing by zero.\n *\n * Counterpart to Solidity's `%` operator. This function uses a `revert`\n * opcode (which leaves remaining gas untouched) while Solidity uses an\n * invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n */\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n return mod(a, b, \"SafeMath: modulo by zero\");\n }\n\n /**\n * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),\n * Reverts with custom message when dividing by zero.\n *\n * Counterpart to Solidity's `%` operator. This function uses a `revert`\n * opcode (which leaves remaining gas untouched) while Solidity uses an\n * invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n *\n * _Available since v2.4.0._\n */\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b != 0, errorMessage);\n return a % b;\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/IERC20.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @dev Interface of the ERC20 standard as defined in the EIP. Does not include\n * the optional functions; to access them see {ERC20Detailed}.\n */\ninterface IERC20 {\n /**\n * @dev Returns the amount of tokens in existence.\n */\n function totalSupply() external view returns (uint256);\n\n /**\n * @dev Returns the amount of tokens owned by `account`.\n */\n function balanceOf(address account) external view returns (uint256);\n\n /**\n * @dev Moves `amount` tokens from the caller's account to `recipient`.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * Emits a {Transfer} event.\n */\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n /**\n * @dev Returns the remaining number of tokens that `spender` will be\n * allowed to spend on behalf of `owner` through {transferFrom}. This is\n * zero by default.\n *\n * This value changes when {approve} or {transferFrom} are called.\n */\n function allowance(address owner, address spender) external view returns (uint256);\n\n /**\n * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * IMPORTANT: Beware that changing an allowance with this method brings the risk\n * that someone may use both the old and the new allowance by unfortunate\n * transaction ordering. One possible solution to mitigate this race\n * condition is to first reduce the spender's allowance to 0 and set the\n * desired value afterwards:\n * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729\n *\n * Emits an {Approval} event.\n */\n function approve(address spender, uint256 amount) external returns (bool);\n\n /**\n * @dev Moves `amount` tokens from `sender` to `recipient` using the\n * allowance mechanism. `amount` is then deducted from the caller's\n * allowance.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * Emits a {Transfer} event.\n */\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n /**\n * @dev Emitted when `value` tokens are moved from one account (`from`) to\n * another (`to`).\n *\n * Note that `value` may be zero.\n */\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n /**\n * @dev Emitted when the allowance of a `spender` for an `owner` is set by\n * a call to {approve}. `value` is the new allowance.\n */\n event Approval(address indexed owner, address indexed spender, uint256 value);\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/GSN/Context.sol\n\npragma solidity ^0.5.0;\n\n/*\n * @dev Provides information about the current execution context, including the\n * sender of the transaction and its data. While these are generally available\n * via msg.sender and msg.data, they should not be accessed in such a direct\n * manner, since when dealing with GSN meta-transactions the account sending and\n * paying for execution may not be the actual sender (as far as an application\n * is concerned).\n *\n * This contract is only required for intermediate, library-like contracts.\n */\ncontract Context {\n // Empty internal constructor, to prevent people from mistakenly deploying\n // an instance of this contract, which should be used via inheritance.\n constructor () internal { }\n // solhint-disable-previous-line no-empty-blocks\n\n function _msgSender() internal view returns (address payable) {\n return msg.sender;\n }\n\n function _msgData() internal view returns (bytes memory) {\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n return msg.data;\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/crowdsale/Crowdsale.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @title Crowdsale\n * @dev Crowdsale is a base contract for managing a token crowdsale,\n * allowing investors to purchase tokens with ether. This contract implements\n * such functionality in its most fundamental form and can be extended to provide additional\n * functionality and/or custom behavior.\n * The external interface represents the basic interface for purchasing tokens, and conforms\n * the base architecture for crowdsales. It is *not* intended to be modified / overridden.\n * The internal interface conforms the extensible and modifiable surface of crowdsales. Override\n * the methods to add functionality. Consider using 'super' where appropriate to concatenate\n * behavior.\n */\ncontract Crowdsale is Context, ReentrancyGuard {\n using SafeMath for uint256;\n using SafeERC20 for IERC20;\n\n // The token being sold\n IERC20 private _token;\n\n // Address where funds are collected\n address payable private _wallet;\n\n // How many token units a buyer gets per wei.\n // The rate is the conversion between wei and the smallest and indivisible token unit.\n // So, if you are using a rate of 1 with a ERC20Detailed token with 3 decimals called TOK\n // 1 wei will give you 1 unit, or 0.001 TOK.\n uint256 private _rate;\n\n // Amount of wei raised\n uint256 private _weiRaised;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n /**\n * @param rate Number of token units a buyer gets per wei\n * @dev The rate is the conversion between wei and the smallest and indivisible\n * token unit. So, if you are using a rate of 1 with a ERC20Detailed token\n * with 3 decimals called TOK, 1 wei will give you 1 unit, or 0.001 TOK.\n * @param wallet Address where collected funds will be forwarded to\n * @param token Address of the token being sold\n */\n constructor (uint256 rate, address payable wallet, IERC20 token) public {\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(wallet != address(0), \"Crowdsale: wallet is the zero address\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n\n _rate = rate;\n _wallet = wallet;\n _token = token;\n }\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n /**\n * @return the token being sold.\n */\n function token() public view returns (IERC20) {\n return _token;\n }\n\n /**\n * @return the address where funds are collected.\n */\n function wallet() public view returns (address payable) {\n return _wallet;\n }\n\n /**\n * @return the number of token units a buyer gets per wei.\n */\n function rate() public view returns (uint256) {\n return _rate;\n }\n\n /**\n * @return the amount of wei raised.\n */\n function weiRaised() public view returns (uint256) {\n return _weiRaised;\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\n function buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(beneficiary, weiAmount);\n }\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _token.safeTransfer(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _deliverTokens(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.mul(_rate);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n _wallet.transfer(msg.value);\n }\n}\n\n// File: vender.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @title SimpleCrowdsale\n * @dev This is an example of a fully fledged crowdsale.\n */\ncontract SimpleCrowdsale is Crowdsale {\n constructor (\n uint256 rate,\n address payable wallet,\n IERC20 token\n )\n public\n Crowdsale(rate, wallet, token)\n {\n }\n}\n\n read \n\n 7\n min\n\n 9 months later\n\n post by BigMadCode on Feb 23, 2022\n\n BigMadCode\n\n Hi,\nDid you ever resolve this issue?\nI think I am facing the same issue and cannot get around it.\nKindly reply at your earliest convenience.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020\n\n Add function buyTokens() with no parameter to Crowdsale contract\n\n Contracts\n\n 5\n\n 2.4k\n\n Nov 2020\n\n Problem with Crowdsale\n\n Support\n\n 6\n\n 1.6k\n\n May 2021","tokens":6398,"squid":"ink-security_audits","role":"Sentinel","at":1791264497593,"hash":"551f55db4acfdb659a5c152e4617d4cbfa82a94d"}
{"url":"https://specs.optimism.io/protocol/isthmus/system-config.html","domain":"specs.optimism.io","title":"System Config - OP Stack Specification","text":"Isthmus: System Config\n\nTable of Contents\n\nOperator Fee Parameter Configuration\n\nConfigUpdate\nInitialization\nModifying Operator Fee Parameters\nInterface\n\nOperator fee parameters\n\noperatorFeeScalar\noperatorFeeConstant\nsetOperatorFeeScalars\n\nOperator Fee Parameter Configuration\nIsthmus adds configuration variables operatorFeeScalar (uint32)\nand operatorFeeConstant (uint64) to SystemConfig to control the operator fee parameters.\nConfigUpdate\nThe following ConfigUpdate event is defined where the CONFIG_VERSION is uint256(0):\nNameValueDefinitionUsage\nBATCHERuint8(0)abi.encode(address)Modifies the account that is authorized to progress the safe chain\nFEE_SCALARSuint8(1)(uint256(0x01) << 248) | (uint256(_blobbasefeeScalar) << 32) | _basefeeScalarModifies the fee scalars\nGAS_LIMITuint8(2)abi.encode(uint64 _gasLimit)Modifies the L2 gas limit\nUNSAFE_BLOCK_SIGNERuint8(3)abi.encode(address)Modifies the account that is authorized to progress the unsafe chain\nEIP_1559_PARAMSuint8(4)uint256(uint64(uint32(_denominator))) << 32 | uint64(uint32(_elasticity))Modifies the EIP-1559 denominator and elasticity\nOPERATOR_FEE_PARAMSuint8(5)uint256(_operatorFeeScalar) << 64 | _operatorFeeConstantModifies the operator fee scalar and constant\n\nInitialization\nThe following actions should happen during the initialization of the SystemConfig:\n\nemit ConfigUpdate.BATCHER\nemit ConfigUpdate.FEE_SCALARS\nemit ConfigUpdate.GAS_LIMIT\nemit ConfigUpdate.UNSAFE_BLOCK_SIGNER\nemit ConfigUpdate.EIP_1559_PARAMS\n\nThese actions MAY only be triggered if there is a diff to the value.\nThe operatorFeeScalar and operatorFeeConstant are initialized to 0.\nModifying Operator Fee Parameters\nA new SystemConfig UpdateType is introduced that enables the modification of\nthe operatorFeeScalar and operatorFeeConstant by the SystemConfig owner.\nInterface\nOperator fee parameters\noperatorFeeScalar\nThis function returns the currently configured operator fee scalar.\nfunction operatorFeeScalar()(uint32)\n\noperatorFeeConstant\nThis function returns the currently configured operator fee constant.\nfunction operatorFeeConstant()(uint64)\n\nsetOperatorFeeScalars\nThis function sets the operatorFeeScalar and operatorFeeConstant.\nThis function MUST only be callable by the SystemConfig owner.\nfunction setOperatorFeeScalar(uint32 _operatorFeeScalar, uint64 _operatorFeeConstant)","tokens":584,"squid":"ink-governance","role":"Council Listener","at":1791264501173,"hash":"8aa797b9be62367ffe9ffb1e0979b3b5857f3a57"}
{"url":"https://io.net/docs/guides/staking/3rd-party-staking","domain":"io.net","title":"Overview - io.net","text":"On our platform, Co-Staking allows users to contribute to staking on someone else’s device. This creates a partnership where both the device owner and the co-staker benefit. However, it’s important to remember that if a device doesn’t meet the platform’s requirements, it could be penalized (a process called slashing), which may reduce both rewards and the original staked amount.\nThis guide will walk you through how to find staking opportunities, manage your co-staked devices, and track your rewards. Whether you’re experienced with staking or just getting started, we’ll provide the tools and knowledge you need to navigate the Co-Staking system with confidence.\nTo ensure that more users can benefit from co-staking offers, we have set a claim cap of up to two offers per IO account.\n​FAQs\nWe’ve compiled answers to frequently asked questions about co-staking on io.net, including troubleshooting tips and guidelines to help users navigate the platform.\n​Getting Started with Co-Staking\nQ: Why is the 'Create Co-Staking Offer' button greyed out for my device?If you’re a device owner and the “Create Co-Staking Offer” button is greyed out, it likely means your device hasn’t met the minimum self-staking requirement. io.net requires you to stake a certain amount of $IO tokens on the device before inviting co-stakers. In most cases, you must stake at least 50% of the total required amount before creating an offer.Ensure that:\nYour device is fully set up and active on the network.\nYou have met the minimum staking requirement.\nCo-staking is only available for operational devices.Q. Can a person co-stake on multiple devices?Yes, co-stakers can participate in multiple devices simultaneously. However, you can only claim offers from two devices at any given time. This ensures fair distribution and prevents one person from monopolizing multiple co-staking opportunities.Q. Can I co-stake on my own device?No, device owners cannot co-stake on their own devices. This rule is in place to prevent users from bypassing staking requirements, such as the minimum self-staking threshold. Co-staking is designed to foster collaboration between independent parties.Unstaking involves a 7-day waiting period followed by a 14-day cooldown period. Funds cannot be used during the cooldown, and rewards are paused during this time.\n​Co-Staking Terms & Rules\nQ. How many co-stakers can a device have?Each device can have only one co-staker per offer. Co-staking agreements follow a one-to-one structure:\n1 device owner → 1 co-staker\nIf a device owner needs more than one co-staker, they must create multiple offers or reduce their own stake. Co-stakers can participate in up to two devices at the same time.Q. Are the identities of co-stakers or device owners visible?No, identities are anonymized within the marketplace. While users can view device specifications and staking terms, personal details of device owners or co-stakers are not disclosed.However, wallet addresses are visible on the blockchain, but they do not directly reveal the identity of the parties involved.Q. Can I change the terms of a co-staking agreement after it has been accepted?No, once a co-staking offer is accepted, its terms are locked in via a smart contract. You cannot modify the stake amount, reward split, or other conditions after activation.If changes are needed, you must:\nCancel or close the existing offer.\nCreate a new offer with the updated terms.\n\n​Withdrawing & Unstaking\nQ. How do I unstake and withdraw funds from co-staking?To withdraw your staked funds:\nClick “Unstake” - this initiates a 7-day waiting period where your tokens stop earning rewards.\nAfter the waiting period, your stake enters a 14-day cooldown period.\nOnce the cooldown ends, your tokens will be available for withdrawal.\n\n​Risks & Performance Considerations\nQ. What if the device I co-staked on performs poorly or goes offline?io.net has a slashing mechanism that penalizes underperforming devices. If a device frequently goes offline or fails to meet performance requirements, both the device owner’s and co-staker’s stake may be slashed.Slashing means forfeiting part of the staked amount as a penalty.To minimize risk, always select reliable devices before co-staking.Q. How does co-staking compare to traditional staking?Unlike traditional staking, where tokens are delegated to validators, co-staking on io.net directly stakes tokens onto a specific device.Key differences:\nCo-stakers share the risk of slashing.\nRewards and conditions are set in a smart contract.\nIt promotes a collaborative staking model rather than simple delegation.\n\n​Troubleshooting & Support\nQ. What should I do if I experience an issue not covered in the FAQs?If you encounter a problem, such as:\nA transaction error\nA device not appearing in the marketplace\nCo-staking issues\nTry the following:\nEnsure you’re using the official io.net platform.\nVerify that your wallet is properly connected.\nClear your browser cache or try a different browser.\nIf the issue persists, reach out to io.net support through:\nSupport ticket system\nDiscord community\nWhen contacting support, provide key details like your wallet address and device ID for faster assistance.Was this page helpful?","tokens":1305,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791264501414,"hash":"8e353609ef8dafa325769f1118b0f0fdad266dc1"}
{"url":"https://specs.optimism.io/protocol/holocene/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Holocene L2 Chain Derivation Changes\n\nTable of Contents\n\nHolocene Derivation\n\nSummary\nFrame Queue\nChannel Bank\n\nPruning\nTimeout\nReading & Frame Loading\n\nSpan Batches\nBatch Queue\n\nFast Channel Invalidation\n\nEngine Queue\nAttributes Builder\nActivation\n\nRationale\n\nStrict Frame and Batch Ordering\nPartial Span Batch Validity\nFast Channel Invalidation\nSteady Block Derivation\nLess Defensive Protocol\n\nSecurity and Implementation Considerations\n\nReorgs\nBatcher Hardening\nSync Start\n\nHolocene Derivation\nSummary\nThe Holocene hardfork introduces several changes to block derivation rules that render the\nderivation pipeline mostly stricter and simpler, improve worst-case scenarios for Fault Proofs and\nInterop. The changes are:\n\nStrict Batch Ordering required batches within and across channels to be strictly ordered.\nPartial Span Batch Validity determines the validity of singular batches from a span batch\nindividually, only invalidating the remaining span batch upon the first invalid singular batch.\nFast Channel Invalidation, similarly to Partial Span Batch Validity applied to the channel\nlayer, forward-invalidates a channel upon finding an invalid batch.\nSteady Block Derivation derives invalid payload attributes immediately as deposit-only\nblocks.\n\nThe combined effect of these changes is that the impact of an invalid batch is contained to the\nblock number at hand, instead of propagating forwards or backwards in the safe chain, while also\ncontaining invalid payloads at the engine stage to the engine, not propagating backwards in the\nderivation pipeline.\nHolocene derivation comprises the following changes to the derivation pipeline to achieve the above.\nFrame Queue\nThe frame queue retains its function and queues all frames of the last batcher transaction(s) that\nweren't assembled into a channel yet. Holocene still allows multiple frames per batcher transaction,\npossibly from different channels. As before, this allows for optionally filling up the remaining\nspace of a batcher transaction with a starting frame of the next channel.\nHowever, Strict Batch Ordering leads to the following additional checks and rules to the frame\nqueue:\n\nIf a non-first frame (i.e., a frame with index >0) decoded from a batcher transaction is out of\norder, it is immediately dropped, where the frame is called out of order if\n\nits frame number is not the previous frame's plus one, if it has the same channel ID, or\nthe previous frame already closed the channel with the same ID, or\nthe non-first frame has a different channel ID than the previous frame in the frame queue.\n\nIf a first frame is decoded while the previous frame isn't a last frame (i.e., is_last is\nfalse), all previous frames for the same channel are dropped and this new first frame remains in\nthe queue.\n\nThese rules guarantee that the frame queue always holds frames whose indices are ordered,\ncontiguous and include the first frame, per channel. Plus, a first frame of a channel is either the\nfirst frame in the queue, or is preceded by a closing frame of a previous channel.\nNote that these rules are in contrast to pre-Holocene rules, where out of order frames were\nbuffered. Pre-Holocene, frame validity checks were only done at the Channel Bank stage. Performing\nthese checks already at the Frame Queue stage leads to faster discarding of invalid frames, keeping\nthe memory consumption of any implementation leaner.\nChannel Bank\nBecause channel frames have to arrive in order, the Channel Bank becomes much simpler and only\nholds at most a single channel at a time.\nPruning\nPruning is vastly simplified as there is at most only one open channel in the channel bank. So the\nchannel bank's queue becomes effectively a staging slot for a single channel, the staging channel.\nThe MAX_CHANNEL_BANK_SIZE parameter is no longer used, and the compressed size of the staging\nchannel is required to be at most MAX_RLP_BYTES_PER_CHANNEL (else the channel is dropped). Note this\nlatter rule is both a distinct condition and distinct effect, compared to the existing rule\nthat the uncompressed size of any given channel is clipped to MAX_RLP_BYTES_PER_CHANNEL during decompression.\nTimeout\nThe timeout is applied as before, just only to the single staging channel.\nReading & Frame Loading\nThe frame queue is guaranteed to hold ordered and contiguous frames, per channel. So reading and\nframe loading becomes simpler in the channel bank:\n\nA first frame for a new channel starts a new channel as the staging channel.\n\nIf there already is an open, non-completed staging channel, it is dropped and replaced by this\nnew channel. This is consistent with how the frame queue drops all frames of a non-closed channel\nupon the arrival of a first frame for a new channel.\n\nIf the current channel is timed-out, but not yet pruned, and the incoming frame would be the next\ncorrect frame for this channel, the frame and channel are dropped, including all future frames for\nthe channel that might still be in the frame queue. Note that the equivalent rule was already\npresent pre-Holocene.\nAfter adding a frame to the staging channel, the channel is dropped if its raw compressed size as\ndefined in the Bedrock specification is larger than MAX_RLP_BYTES_PER_CHANNEL. This rule replaces\nthe total limit of all channels' combined sizes by MAX_CHANNEL_BANK_SIZE before Holocene.\n\nSpan Batches\nPartial Span Batch Validity changes the atomic validity model of Span Batches.\nIn Holocene, a span batch is treated as an optional stage in the derivation pipeline that sits\nbefore the batch queue, so that the batch queue pulls singular batches from this previous Span Batch\nstage. When encountering an invalid singular batch, it is dropped, as is the remaining span batch\nfor consistency reasons. We call this forwards-invalidation. However, we don't\nbackwards-invalidate previous valid batches that came from the same span batch, as pre-Holocene.\nWhen a batch derived from the current staging channel is a singular batch, it is directly forwarded\nto the batch queue. Otherwise, it is set as the current span batch in the span batch stage. The\nfollowing span batch validity checks are done, before singular batches are derived from it.\nDefinitions are borrowed from the original Span Batch specs.\n\nIf the span batch L1 origin check is not part of the canonical L1 chain, the span batch is\ninvalid.\nA failed parent check invalidates the span batch.\nIf span_start.timestamp > next_timestamp, the span batch is invalid, because we disallow gaps\ndue to the new strict batch ordering rules.\nIf span_end.timestamp < next_timestamp, the span batch is set to have past validity, as it\ndoesn't contain any new batches (this would also happen if applying timestamp checks to each derived\nsingular batch individually). See below in the Batch Queue section about the new\npast validity.\nSpan batches may overlap with the safe chain (span_start.timestamp < next_timestamp). Every\noverlapped block must have the same L1 origin number and non-deposit transactions as the\ncorresponding safe-chain block, as specified by the\noverlapped blocks checks.\nA failed overlap check invalidates the span batch.\n\nIf any of the above checks invalidate the span batch, it is dropped and the remaining channel from\nwhich the span batch was derived, is also immediately dropped (see also Fast Channel\nInvalidation). However, a past span batch is only dropped, without\ndropping the remaining channel.\n\n[!Note]\nA word regarding overlapping span batches: the existing batch queue rules already contain the rule\nto drop batches whose L1 origin is older than that of the L2 safe head. The Delta span batch\nchecks also have an equivalent rule that applies to all singular batches past the safe head.\nThe overlap checks above are still performed on the span batch as a whole. The remaining full span\nbatch checks are not performed before streaming singular batches in Holocene. The batch queue rules\nare still applied to singular batches streamed from span batches, so in particular the outdated L1\norigin rule also applies to the first singular batch past the current safe head.\nIt is a known footgun for implementations that the earliest point at which violations of this rule\nare detected is when the full array of singular batches is extracted from the span batch and their\nL1 origin hashes are populated. It is therefore important to treat singular batches with outdated\nor otherwise invalid L1 origin numbers as invalid, and consequently the span batch as invalid, and\nnot generate a critical derivation error that stalls derivation.\n\nBatch Queue\nThe batch queue is also simplified in that batches are required to arrive strictly ordered, and any\nbatches that violate the ordering requirements are immediately dropped, instead of buffered.\nSo the following changes are made to the Bedrock Batch Queue:\n\nThe reordering step is removed, so that later checks will drop batches that are not sequential.\nThe future batch validity status is removed, and batches that were determined to be in the\nfuture are now directly drop-ped. This effectively disallows gaps, instead of buffering future\nbatches.\nA new batch validity past is introduced. A batch has past validity if its timestamp is before\nor equal to the safe head's timestamp. This also applies to span batches.\nThe other rules stay the same, including empty batch generation when the sequencing window\nelapses.\n\nNote that these changes to batch validity rules also activate by the L1 inclusion block timestamp of\na batch, not with the batch timestamp. This is important to guarantee consistent validation rules\nfor the first channel after Holocene activation.\nThe drop and past batch validities cause the following new behavior:\n\nIf a batch is found to be invalid and is dropped, the remaining span batch it originated from, if\napplicable, is also discarded.\nIf a batch is found to be from the past, it is silently dropped and the remaining span batch\ncontinues to be processed. This applies to both, span and singular batches.\n\nNote that when the L1 origin of the batch queue moves forward, it is guaranteed that it is empty,\nbecause future batches aren't buffered any more. Furthermore, because future batches are directly\ndropped, the batch queue effectively becomes a simpler batch stage that holds at most one span\nbatch from which singular batches are read from, and doesn't buffer singular batches itself in a\nqueue any more. A valid batch is directly forwarded to the next stage.\nFast Channel Invalidation\nFurthermore, upon finding an invalid batch, the remaining channel it got derived from is also discarded.\nEngine Queue\nIf the engine returns an INVALID status for a regularly derived payload, the payload is replaced\nby a payload with the same fields, except for the transaction_list, which is trimmed to include\nonly its deposit transactions.\nAs before, a failure to then process the deposit-only attributes is a critical error.\nIf an invalid payload is replaced by a deposit-only payload, for consistency reasons, the remaining\nspan batch, if applicable, and channel it originated from are dropped as well.\nAttributes Builder\nStarting after the fork activation block, the PayloadAttributes produced by the attributes builder will include\nthe eip1559Params field described in the execution engine specs. This\nvalue exists within the SystemConfig.\nOn the fork activation block, the attributes builder will include a 0'd out eip1559Params, as to instruct\nthe engine to use the canyon base fee parameter constants. This\nis to prime the pipeline's view of the SystemConfig with the default EIP-1559 parameter values. After the first\nHolocene payload has been processed, future payloads should use the SystemConfig's EIP-1559 denominator and elasticity\nparameter as the eip1559Params field's value. When the pipeline encounters a UpdateType.EIP_1559_PARAMS,\nConfigUpdate event, the pipeline's system config will be synchronized with the SystemConfig contract's.\nActivation\nThe new batch rules activate when the L1 inclusion block timestamp is greater or equal to the\nHolocene activation timestamp. Note that this is in contrast to how span batches activated in\nDelta, namely via the span batch L1 origin timestamp.\nWhen the L1 traversal stage of the derivation pipeline moves its origin to the L1 block whose\ntimestamp is the first to be greater or equal to the Holocene activation timestamp, the derivation\npipeline's state is mostly reset by discarding\n\nall frames in the frame queue,\nchannels in the channel bank, and\nall batches in the batch queue.\n\nThe three stages are then replaced by the new Holocene frame queue, channel bank and batch queue\n(and, depending on the implementation, the optional span batch stage is added).\nNote that batcher implementations must be aware of this activation behavior, so any frames of a\npartially submitted channel that were included pre-Holocene must be sent again. This is a very\nunlikely scenario since production batchers are usually configured to submit a channel in a single\ntransaction.\nRationale\nStrict Frame and Batch Ordering\nStrict Frame and Batch Ordering simplifies implementations of the derivation pipeline, and leads to\nbetter worst-case cached data usage.\n\nThe frame queue only ever holds frames from a single batcher transaction.\nThe channel bank only ever holds a single staging channel, that is either being built up by\nincoming frames, or is is being processed by later stages.\nThe batch queue only ever holds at most a single span batch (that is being processed) and a single singular\nbatch (from the span batch, or the staging channel directly)\nThe sync start greatly simplifies in the average production case.\n\nThis has advantages for Fault Proof program implementations.\nPartial Span Batch Validity\nPartial Span Batch Validity guarantees that a valid singular batch derived from a span batch can\nimmediately be processed as valid and advance the safe chain, instead of being in an undecided state\nuntil the full span batch is converted into singular batches. This leads to swifter derivation and\ngives strong worst-case guarantees for Fault Proofs because the validity of a block doesn't depend\non the validity of any future blocks any more. Note that before Holocene, to verify the first block\nof a span batch required validating the full span batch.\nFast Channel Invalidation\nThe new Fast Channel Invalidation rule is a consistency implication of the Strict Ordering Rules.\nBecause batches inside channels must be ordered and contiguous, assuming that all batches inside a\nchannel are self-consistent (i.e., parent L2 hashes point to the block resulting from the previous\nbatch), an invalid batch also forward-invalidates all remaining batches of the same channel.\nSteady Block Derivation\nSteady Block Derivation changes the derivation rules for invalid payload attributes, replacing an\ninvalid payload by a deposit-only/empty payload. Crucially, this means that the effect of an invalid\npayload doesn't propagate backwards in the derivation pipeline. This has benefits for Fault Proofs\nand Interop, because it guarantees that batch validity is not influenced by future stages and the\nblock derived from a valid batch will be determined by the engine stage before it pulls new payload\nattributes from the previous stage. This avoids larger derivation pipeline resets.\nLess Defensive Protocol\nThe stricter derivation rules lead to a less defensive protocol. The old protocol rules allowed for\nsecond chances for invalid payloads and submitting frames and batches within channels out of order.\nExperiences from running OP Stack chains for over one and a half years have shown that these relaxed\nderivation rules are (almost) never needed, so stricter rules that improve worst-case scenarios for\nFault Proofs and Interop are favorable.\nFurthermore, the more relaxed rules created a lot more corner cases and complex interactions, which\nmade it harder to reason about and test the protocol, increasing the risk of chain splits between\ndifferent implementations.\nSecurity and Implementation Considerations\nReorgs\nBefore Steady Block Derivation, invalid payloads got second chances to be replaced by valid future\npayloads. Because they will now be immediately replaced by as deposit-only payloads, there is a\ntheoretical heightened risk for unsafe chain reorgs. To the best of our knowledge, we haven't\nexperienced this on OP Mainnet or other mainnet OP Stack chains yet.\nThe only conceivable scenarios in which a valid batch leads to an invalid payload are\n\na buggy or malicious sequencer+batcher\nin the future, that an previously valid Interop dependency referenced in that payload is later\ninvalidated, while the block that contained the Interop dependency got already batched.\n\nIt is this latter case that inspired the Steady Block Derivation rule. It guarantees that the\nsecondary effects of an invalid Interop dependency are contained to a single block only, which\navoids a cascade of cross-L2 Interop reorgs that revisit L2 chains more than once.\nBatcher Hardening\nIn a sense, Holocene shifts some complexity from derivation to the batching phase. Simpler and\nstricter derivation rules need to be met by a more complex batcher implementation.\nThe batcher must be hardened to guarantee the strict ordering requirements. They are already mostly\nmet in practice by the current Go implementation, but more by accident than by design. There are\nedge cases in which the batcher might violate the strict ordering rules. For example, if a channel\nfails to submit within a set period, the blocks are requeued and some out of order batching might\noccur. A batcher implementation also needs to take extra care that dynamic blobs/calldata switching\ndoesn't lead to out of order or gaps of batches in scenarios where blocks are requeued, while future\nchannels are already waiting in the mempool for inclusion.\nBatcher implementations are suggested to follow a fixed nonce to block-range assignment, once the\nfirst batcher transaction (which is almost always the only batcher transaction for a channel for\ncurrent production batcher configurations) starts being submitted. This should avoid out-of-order or\ngaps of batches. It might require to implement some form of persistence in the transaction\nmanagement, since it isn't possible to reliably recover all globally pending batcher transactions in\nthe L1 network.\nFurthermore, batcher implementations need to be made aware of the Steady Block Derivation rules,\nnamely that invalid payloads will be derived as deposit-only blocks. So in case of an unsafe reorg,\nthe batcher should wait on the sequencer until it has derived all blocks from L1 in order to only\nstart batching new blocks on top of the possibly deposit-only derived reorg'd chain segment. The\nsync-status should repeatedly be queried and matched against the expected safe chain. In case of any\ndiscrepancy, the batcher should then stop batching and wait for the sequencer to fully derive up\nuntil the latest L1 batcher transactions, and only then continue batching.\nSync Start\nThanks to the new strict frame and batch ordering rules, the sync start algorithm can be simplified\nin the average case. The rules guarantee that\n\nan incoming first frame for a new channel leads to discarding previous incomplete frames for a\nnon-closed previous channel in the frame queue and channel bank, and\nwhen the derivation pipeline L1 origin progresses, the batch queue is empty.\n\nSo the sync start algorithm can optimistically select the last L2 unsafe, safe and finalized heads\nfrom the engine and if the L2 safe head's L1 origin is plausible (see the\noriginal sync start description for details),\nstart deriving from this L1 origin.\n\nIf the first frame we find is a first frame for a channel that includes the safe head (TBD: or\neven just the following L2 block with the current safe head as parent), we can\nsafely continue derivation from this channel because no previous derivation pipeline state could\nhave influenced the L2 safe head.\nIf the first frame we find is a non-first frame, then we need to walk back a full channel\ntimeout window to see if we find the start of that channel.\n\nIf we find the starting frame, we can continue derivation from it.\nIf we don't find the starting frame, we need to go back a full channel timeout window before the\nfinalized L2 head's L1 origin.\n\nNote regarding the last case that if we don't find a starting frame within a channel timeout window,\nthe channel we did find a frame from must be timed out and would be discarded. The safe block we're\nlooking for can't be in any channel that timed out before its L1 origin so we wouldn't need to\nsearch any further back, so we go back a channel timeout before the finalized L2 head.","tokens":5171,"squid":"ink-governance","role":"Council Listener","at":1791264523039,"hash":"ff725dc30eaeab3ca8ce9615c0919ce4c6b54cae"}
{"url":"https://io.net/docs/guides/staking/co-staking","domain":"io.net","title":"Co-staking - io.net","text":"​Table of Contents\n\nThe Staking Marketplace\nCo-stake to a Device\n\nCo-staking allows third parties to stake on devices and share block rewards.\nDevices failing to meet IO.net criteria may result in slashing, affecting rewards and principal.\n​The Staking Marketplace\nTo explore staking opportunities, go to IO Staking > Co-staking Marketplace. The marketplace provides all the information you need to make informed decisions.\n\nThe marketplace includes filters for:\n\nDevice Model: GPU or CPU type.\nDevice ID: Search by device ID.\nRequested Amount: Amount of $IO requested by the device owner.\nReliability: Indicates device dependability.\nOffered Reward Percentage: Block reward percentage shared with co-stakers.\n\nThe screenshot below provides an example of Co-Staking offers.\n\n​Co-stake to a Device\nTo ensure that more users can benefit from co-staking offers, we have set a claim cap of up to two offers per IO account.\nTo co-stake a device:\n\nClick the Co-stake button next to the device to view a summary of the offer.\n\nIf you agree with the terms, click Stake\n\nApprove the transaction in your wallet app (e.g., Phantom). The interface may vary depending on your wallet..\n\nThe status will first show Sending and then change to Approved.\n\nTo see your co-staked device, go to the Third-Party Co-Staking Devices tab.Was this page helpful?","tokens":334,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791264523327,"hash":"99e55d1daf53f5a1fcd17cb3b77c318884d0587a"}
{"url":"https://dev-forum.pyth.network/t/error-running-hermes-client/212/1","domain":"dev-forum.pyth.network","title":"Error running Hermes client - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Error running Hermes client \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2025\n\n 1 / 2\n\n Jun 2025\n\n Jun 2025\n\n post by Aditya520 on Jun 12, 2025\n\n Aditya520\n\n Posting for a user who wants to run hermes.\nHere are the parameters.\nspy --env mainnet --nodeKey /node.key --spyRPC \"[::]:7073\" --env mainnet --ethRPC \"<RPC URL for Ethereum>\" --ethContract 0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B --logLevel warn\nhermes run --rpc-listen-addr \"[::]:33999\" --pythnet-http-addr https://pythnet.rpcpool.com/ --pythnet-ws-addr wss://pythnet.rpcpool.com/ --wormhole-spy-rpc-addr http://<wormhole spy>:7073/\n\nThey are not seeting any feeds in /v2/price_feeds nor any feed working.\n\n post by ali on Jun 12, 2025\n\n ali\n\n Please try again running with this RPC https://api2.pythnet.pyth.network. If it doesn’t work out, please run it with RUST_LOG=info environment variable and share a dump of the logs along with the output of the /ready endpoint.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Hermes configuration\n\n Price Feeds\n\n 3\n\n 754\n\n Jun 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Powered by Discourse","tokens":1285,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264523650,"hash":"893d3dd552760aae68f44a30545f321d583cee05"}
{"url":"https://io.net/docs/guides/explorer/tne-on-chain","domain":"io.net","title":"Overview - io.net","text":"TNE On Chain marks a major milestone in io.net’s evolution, introducing a fully transparent and verifiable transaction system on the Solana blockchain. This upgrade brings every booking, payment, and $IO repurchase on-chain — making io.net one of the first AI compute networks to offer complete financial transparency and security for its users and suppliers.\nBy recording all financial activity on-chain, TNE introduces an immutable ledger of interactions between customers, suppliers, and io.net’s treasury. This system not only enforces accountability, but also improves automation, strengthens trust, and aligns the platform with Web3-native infrastructure.\n​Why On-Chain?\nMoving transactions to the Solana blockchain ensures:\n\nTransparency — Every payment, refund, or repurchase can be independently verified.\nSecurity — Funds are held in escrow using smart contracts, reducing risk.\nEfficiency — Automated payments and settlements minimize delays and errors.\nDecentralization — All financial flows are publicly auditable and blockchain-native.\nEcosystem Support — A portion of every transaction goes toward repurchasing $IO on the open market, supporting liquidity and value for token holders.\n\nTotal Network Earnings and Daily Network Earnings reflect estimated values based on compute provided, not actual payments or finalized settlements.\nClusters initiated in USDC can have remaining balances settled in IO Coin or USD, enabling flexible multi-currency transactions.\n​How It Works\nThe Epochs tab gives you full visibility into the financial activity happening across the io.net network. This section of IO Explorer is designed to highlight revenue trends, individual transaction details, and the overall performance of the platform in real time.\n\nFrom this dashboard, you can view:\n​Total Network Earnings\nThis block provides a comprehensive overview of all revenue generated across the network. It includes:\n\nTotal Earnings Graph: A line graph displaying estimated cumulative revenue over time.\nDaily Change (%): A quick view of the day-over-day percentage change in revenue, giving users an immediate sense of growth or fluctuation.\nDetailed Revenue Graph: A more granular visualization that breaks down network earnings into smaller time intervals or sources for deeper analysis.\n\nAll compute workloads are denominated and recorded in IO Coin terms, even when the initial cluster payment was made in another currency.\n​Daily Earnings Trends\nThis section highlights how earnings change over time, using a Bar Chart by Day to show daily revenue. It helps you spot trends, seasonal patterns, and the effects of key events or cluster deployments.\nWithin TNE metadata, all transaction values are displayed in USDC for clarity and consistency.\n\n​Monthly Network Earnings Trends\nThis section highlights how earnings change over time, using a Line Chart by Month to show monthly earnings.\n\n​Epoch List\nThe Epoch Rewards Dashboard provides visibility into epoch-level reward distribution, token purchases, and burn activity across the network. It enables administrators to track historical reward calculations, validate reward signatures, and monitor supplier participation over time.\nThe dashboard is divided into three primary sections:\n\nFilter Controls: Narrow down results by date range, supplier, client, or epoch status.\nSummary Metrics: High-level statistics for the selected time period.\nEpoch List: Detailed epoch-by-epoch breakdown of rewards and burn calculations.\n\n​Filter Controls\nThe dashboard supports the following filters:\nFilterDescriptionEpoch FromStart date for the epoch search range.Epoch ToEnd date for the epoch search range.Supplier IDFilter results for a specific supplier UUID.Client IDFilter results for a specific client UUID.StatusFilter epochs by status (Open, Closing, or Closed).Fetch DataRetrieves data based on the selected filters.ResetClears all filters and restores the default view.\n​Summary Metrics\nThe summary section provides aggregated statistics for the selected dataset.\nMetricDescriptionTotal EpochsTotal number of epochs returned by the current filter set.Total Device HoursAggregate device hours contributed across all returned epochs.Epoch RewardsTotal rewards distributed across the selected epochs.IO PurchasedTotal IO tokens purchased during the selected period.Total Burn AmountTotal amount of IO tokens burned across the selected epochs.\n\nWhen no $IO repurchase is recorded, it indicates that the client paid directly in IO Coin.\n​Epoch Details\nThe Epoch Details page provides a comprehensive view of a single epoch, including reward allocation, token repurchases, payouts, burn activity, debt obligations, and participating device inventory. This page is designed to support auditing, reward verification, and infrastructure analytics.\n​Overview\nAt the top of the page, users can view the selected epoch identifier, its execution window, and current status.\n​Epoch Information\nFieldDescriptionEpoch IDUnique identifier for the epoch.Start TimeTimestamp when the epoch began.End TimeTimestamp when the epoch concluded.StatusCurrent state of the epoch (Open or Closed).\n​Epoch Metrics\nThe summary section provides key financial and operational metrics for the selected epoch.\n\nEpoch Rewards: The total amount of IO tokens allocated to suppliers during the epoch based on eligible device participation and reward calculations.\nRepurchased: The amount of IO tokens repurchased during the epoch/\nPaid Out: The total amount of IO tokens distributed to suppliers for the epoch. This value represents finalized supplier earnings that have been allocated for payment.\nActive Devices: The total number of unique devices that participated and qualified for rewards during the epoch.\nOpen Debt: The outstanding financial obligation associated with the epoch.\nBurn Amount: The total amount of IO tokens permanently removed from circulation during the epoch.\n\nQuick Steps for Users\nConnect your Solana-compatible wallet (e.g., Phantom, Solflare) to seamlessly track your earnings and transactions on-chain.\nUse the Explorer’s Epochs tab to view detailed, real-time payment and payout information.\nWas this page helpful?","tokens":1541,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791264533370,"hash":"8d29e2e06e0f8a8aacb5be2c0601e96a497475c9"}
{"url":"https://dev-forum.pyth.network/t/hermes-client-invalid-response/461","domain":"dev-forum.pyth.network","title":"Hermes Client - Invalid response - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Hermes Client - Invalid response \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Nov 2025\n\n 1 / 5\n\n Nov 2025\n\n Nov 2025\n\n post by KemarTiti on Nov 6, 2025\n\n KemarTiti\n\n Hey,\nWe are currently using @pythnetwork/hermes-client and getLatestPriceUpdates function to retrieve Pyth price feeds in batch mode.\nHowever, the current implementation causes an issue: if even a single feedId is invalid or fails to resolve, the entire batch request fails.\n\nIs there a reliable way to pre-validate whether a given feedId is valid/exists before including it in a batch request?\nIf possible, could you provide (or point us to) an alternative batch retrieval method that supports partial success — i.e., returns prices for all valid feedIds while gracefully handling errors for invalid or unavailable ones without rejecting the whole batch?\n\n 3\n\n 2\n\n post by ali on Nov 6, 2025\n\n ali\n\n We have an ignoreInvalidPriceIds option in the requests that lets you get the feeds partially. See here for more info.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n Thanks!\nEvery 15 seconds, we call your SDK to fetch the latest prices; we batch 20 tokens in each call.\nAs of now, we see that more than 40% of the API calls take more than 2 seconds, and occasionally it will reach a 5-second timeout. Is it expected?\n\n post by ali on Nov 7, 2025\n\n post by KemarTiti on Nov 7, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Powered by Discourse","tokens":1395,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264533728,"hash":"c8d77382272860afaf2f2807c8c734ca57de6a31"}
{"url":"https://ethereum.org/developers/docs/evm/opcodes/","domain":"ethereum.org","title":"Opcodes for the EVM | ethereum.org","text":"Opcodes for the EVMEdit page (opens in a new tab)Overview\nThis is an updated version of the EVM reference page at wolflo/evm-opcodes (opens in a new tab).\nAlso drawn from the Yellow Paper (opens in a new tab), the Jello Paper (opens in a new tab), and the geth (opens in a new tab) implementation.\nThis is intended to be an accessible reference, but it is not particularly rigorous.\nIf you want to be certain of correctness and aware of every edge case, using the Jello Paper or a client implementation is advisable.\nLooking for an interactive reference? Check out evm.codes (opens in a new tab).\nFor operations with dynamic gas costs, see gas.md (opens in a new tab).\n💡 Quick tip: To view entire lines, use [shift] + scroll to scroll horizontally on desktop.\nStackNameGasInitial StackResulting StackMem / StorageNotes00STOP0halt execution01ADD3a, ba + b(u)int256 addition modulo 2**25602MUL5a, ba * b(u)int256 multiplication modulo 2**25603SUB3a, ba - b(u)int256 subtraction modulo 2**25604DIV5a, ba // buint256 division05SDIV5a, ba // bint256 division06MOD5a, ba % buint256 modulus07SMOD5a, ba % bint256 modulus08ADDMOD8a, b, N(a + b) % N(u)int256 addition modulo N09MULMOD8a, b, N(a * b) % N(u)int256 multiplication modulo N0AEXPA1 (opens in a new tab)a, ba ** buint256 exponentiation modulo 2**2560BSIGNEXTEND5b, xSIGNEXTEND(x, b)sign extend (opens in a new tab) x from (b+1) bytes to 32 bytes0C-0Finvalid10LT3a, ba < buint256 less-than11GT3a, ba > buint256 greater-than12SLT3a, ba < bint256 less-than13SGT3a, ba > bint256 greater-than14EQ3a, ba == b(u)int256 equality15ISZERO3aa == 0(u)int256 iszero16AND3a, ba && bbitwise AND17OR3a, ba || bbitwise OR18XOR3a, ba ^ bbitwise XOR19NOT3a~abitwise NOT1ABYTE3i, x(x >> (248 - i * 8)) && 0xFFith byte of (u)int256 x, from the left1BSHL3shift, valval << shiftshift left1CSHR3shift, valval >> shiftlogical shift right1DSAR3shift, valval >> shiftarithmetic shift right1E-1Finvalid20KECCAK256A2 (opens in a new tab)ost, lenkeccak256(mem[ost:ost+len-1])keccak25621-2Finvalid30ADDRESS2.address(this)address of executing contract31BALANCEA5 (opens in a new tab)addraddr.balancebalance, in wei32ORIGIN2.tx.originaddress that originated the tx33CALLER2.msg.senderaddress of msg sender34CALLVALUE2.msg.valuemsg value, in wei35CALLDATALOAD3idxmsg.data[idx:idx+32]read word from msg data at index idx36CALLDATASIZE2.len(msg.data)length of msg data, in bytes37CALLDATACOPYA3 (opens in a new tab)dstOst, ost, len.mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1]copy msg data38CODESIZE2.len(this.code)length of executing contract's code, in bytes39CODECOPYA3 (opens in a new tab)dstOst, ost, len.mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1]3AGASPRICE2.tx.gaspricegas price of tx, in wei per unit gas ** (opens in a new tab)3BEXTCODESIZEA5 (opens in a new tab)addrlen(addr.code)size of code at addr, in bytes3CEXTCODECOPYA4 (opens in a new tab)addr, dstOst, ost, len.mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1]copy code from addr3DRETURNDATASIZE2.sizesize of returned data from last external call, in bytes3ERETURNDATACOPYA3 (opens in a new tab)dstOst, ost, len.mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1]copy returned data from last external call3FEXTCODEHASHA5 (opens in a new tab)addrhashhash = addr.exists ? keccak256(addr.code) : 040BLOCKHASH20blockNumblockHash(blockNum)41COINBASE2.block.coinbaseaddress of proposer of current block42TIMESTAMP2.block.timestamptimestamp of current block43NUMBER2.block.numbernumber of current block44PREVRANDAO2.randomness beaconrandomness beacon45GASLIMIT2.block.gaslimitgas limit of current block46CHAINID2.chain_idpush current chain id (opens in a new tab) onto stack47SELFBALANCE5.address(this).balancebalance of executing contract, in wei48BASEFEE2.block.basefeebase fee of current block49BLOBHASH3idxtx.blob_versioned_hashes[idx]EIP-4844 (opens in a new tab)4ABLOBBASEFEE2.block.blobbasefeeblob base fee of current block (EIP-7516 (opens in a new tab))4B-4Finvalid50POP2_anon.remove item from top of stack and discard it51MLOAD3* (opens in a new tab)ostmem[ost:ost+32]read word from memory at offset ost52MSTORE3* (opens in a new tab)ost, val.mem[ost:ost+32] := valwrite a word to memory53MSTORE83* (opens in a new tab)ost, val.mem[ost] := val && 0xFFwrite a single byte to memory54SLOADA6 (opens in a new tab)keystorage[key]read word from storage55SSTOREA7 (opens in a new tab)key, val.storage[key] := valwrite word to storage56JUMP8dst.$pc := dst mark that pc is only assigned if dst is a valid jumpdest57JUMPI10dst, condition.$pc := condition ? dst : $pc + 158PC2.$pcprogram counter59MSIZE2.len(mem)size of memory in current execution context, in bytes5AGAS2.gasRemaining5BJUMPDEST1mark valid jump destinationa valid jump destination for example a jump destination not inside the push data5CTLOAD100keytstorage[key]read word from transient storage (EIP-1153 (opens in a new tab))5DTSTORE100key, val.tstorage[key] := valwrite word to transient storage (EIP-1153 (opens in a new tab))5EMCOPY3+3*words+A0 (opens in a new tab)dstOst, ost, len.mem[dstOst] := mem[ost:ost+len]copy memory from one area to another (EIP-5656 (opens in a new tab))5FPUSH02.uint8push the constant value 0 onto stack60PUSH13.uint8push 1-byte value onto stack61PUSH23.uint16push 2-byte value onto stack62PUSH33.uint24push 3-byte value onto stack63PUSH43.uint32push 4-byte value onto stack64PUSH53.uint40push 5-byte value onto stack65PUSH63.uint48push 6-byte value onto stack66PUSH73.uint56push 7-byte value onto stack67PUSH83.uint64push 8-byte value onto stack68PUSH93.uint72push 9-byte value onto stack69PUSH103.uint80push 10-byte value onto stack6APUSH113.uint88push 11-byte value onto stack6BPUSH123.uint96push 12-byte value onto stack6CPUSH133.uint104push 13-byte value onto stack6DPUSH143.uint112push 14-byte value onto stack6EPUSH153.uint120push 15-byte value onto stack6FPUSH163.uint128push 16-byte value onto stack70PUSH173.uint136push 17-byte value onto stack71PUSH183.uint144push 18-byte value onto stack72PUSH193.uint152push 19-byte value onto stack73PUSH203.uint160push 20-byte value onto stack74PUSH213.uint168push 21-byte value onto stack75PUSH223.uint176push 22-byte value onto stack76PUSH233.uint184push 23-byte value onto stack77PUSH243.uint192push 24-byte value onto stack78PUSH253.uint200push 25-byte value onto stack79PUSH263.uint208push 26-byte value onto stack7APUSH273.uint216push 27-byte value onto stack7BPUSH283.uint224push 28-byte value onto stack7CPUSH293.uint232push 29-byte value onto stack7DPUSH303.uint240push 30-byte value onto stack7EPUSH313.uint248push 31-byte value onto stack7FPUSH323.uint256push 32-byte value onto stack80DUP13aa, aclone 1st value on stack81DUP23_, aa, _, aclone 2nd value on stack82DUP33_, _, aa, _, _, aclone 3rd value on stack83DUP43_, _, _, aa, _, _, _, aclone 4th value on stack84DUP53..., aa, ..., aclone 5th value on stack85DUP63..., aa, ..., aclone 6th value on stack86DUP73..., aa, ..., aclone 7th value on stack87DUP83..., aa, ..., aclone 8th value on stack88DUP93..., aa, ..., aclone 9th value on stack89DUP103..., aa, ..., aclone 10th value on stack8ADUP113..., aa, ..., aclone 11th value on stack8BDUP123..., aa, ..., aclone 12th value on stack8CDUP133..., aa, ..., aclone 13th value on stack8DDUP143..., aa, ..., aclone 14th value on stack8EDUP153..., aa, ..., aclone 15th value on stack8FDUP163..., aa, ..., aclone 16th value on stack90SWAP13a, bb, a91SWAP23a, _, bb, _, a92SWAP33a, _, _, bb, _, _, a93SWAP43a, _, _, _, bb, _, _, _, a94SWAP53a, ..., bb, ..., a95SWAP63a, ..., bb, ..., a96SWAP73a, ..., bb, ..., a97SWAP83a, ..., bb, ..., a98SWAP93a, ..., bb, ..., a99SWAP103a, ..., bb, ..., a9ASWAP113a, ..., bb, ..., a9BSWAP123a, ..., bb, ..., a9CSWAP133a, ..., bb, ..., a9DSWAP143a, ..., bb, ..., a9ESWAP153a, ..., bb, ..., a9FSWAP163a, ..., bb, ..., aA0LOG0A8 (opens in a new tab)ost, len.LOG0(memory[ost:ost+len-1])A1LOG1A8 (opens in a new tab)ost, len, topic0.LOG1(memory[ost:ost+len-1], topic0)A2LOG2A8 (opens in a new tab)ost, len, topic0, topic1.LOG2(memory[ost:ost+len-1], topic0, topic1)A3LOG3A8 (opens in a new tab)ost, len, topic0, topic1, topic2.LOG3(memory[ost:ost+len-1], topic0, topic1, topic2)A4LOG4A8 (opens in a new tab)ost, len, topic0, topic1, topic2, topic3.LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3)A5-EFinvalidF0CREATEA9 (opens in a new tab)val, ost, lenaddraddr = keccak256(rlp([address(this), this.nonce]))F1CALLAA (opens in a new tab)gas, addr, val, argOst, argLen, retOst, retLensuccessmem[retOst:retOst+retLen-1] := returndataF2CALLCODEAA (opens in a new tab)gas, addr, val, argOst, argLen, retOst, retLensuccessmem[retOst:retOst+retLen-1] = returndatasame as DELEGATECALL, but does not propagate original msg.sender and msg.valueF3RETURN0* (opens in a new tab)ost, len.return mem[ost:ost+len-1]F4DELEGATECALLAA (opens in a new tab)gas, addr, argOst, argLen, retOst, retLensuccessmem[retOst:retOst+retLen-1] := returndataF5CREATE2A9 (opens in a new tab)val, ost, len, saltaddraddr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:]F6-F9invalidFASTATICCALLAA (opens in a new tab)gas, addr, argOst, argLen, retOst, retLensuccessmem[retOst:retOst+retLen-1] := returndataFB-FCinvalidFDREVERT0* (opens in a new tab)ost, len.revert(mem[ost:ost+len-1])FEINVALIDAF (opens in a new tab)designated invalid opcode - EIP-141 (opens in a new tab)FFSELFDESTRUCTAB (opens in a new tab)addr.sends all ETH to addr; if executed in the same transaction as a contract was created it destroys the contract","tokens":2378,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264539373,"hash":"569cb2c474fc5a18ec669042fdf84320c95a0de3"}
{"url":"https://dev-forum.pyth.network/t/hermes-client-invalid-response/461/2","domain":"dev-forum.pyth.network","title":"Hermes Client - Invalid response - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Nov 2025\n\n 2 / 5\n\n Nov 2025\n\n Nov 2025\n\n post by KemarTiti on Nov 6, 2025\n\n KemarTiti\n\n Hey,\nWe are currently using @pythnetwork/hermes-client and getLatestPriceUpdates function to retrieve Pyth price feeds in batch mode.\nHowever, the current implementation causes an issue: if even a single feedId is invalid or fails to resolve, the entire batch request fails.\n\nIs there a reliable way to pre-validate whether a given feedId is valid/exists before including it in a batch request?\nIf possible, could you provide (or point us to) an alternative batch retrieval method that supports partial success — i.e., returns prices for all valid feedIds while gracefully handling errors for invalid or unavailable ones without rejecting the whole batch?\n\n 3\n\n 2\n\n post by ali on Nov 6, 2025\n\n ali\n\n We have an ignoreInvalidPriceIds option in the requests that lets you get the feeds partially. See here for more info.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n Thanks!\nEvery 15 seconds, we call your SDK to fetch the latest prices; we batch 20 tokens in each call.\nAs of now, we see that more than 40% of the API calls take more than 2 seconds, and occasionally it will reach a 5-second timeout. Is it expected?\n\n post by ali on Nov 7, 2025\n\n ali\n\n From which location are you hitting Hermes endpoints? We generally recommend using a private Hermes RPC for production usecases.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n We call it from Singapore\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Powered by Discourse","tokens":1430,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264546487,"hash":"0fef3ece40ada7c8da08f8b36c7488443a23256b"}
{"url":"https://support.io.net/en/support/solutions","domain":"support.io.net","title":"Knowledge base :","text":"Knowledge base\n\n General (1)\n\n FAQ & Misc categories.\n\n FAQ (19)\n\n IO Worker Automatically Deleting Other Docker Containers\n\n How Do I Claim Block Rewards Earnings?\n\n Why is my worker Blocked?\n\n View all 19\n\n IO.Worker (4)\n\n Troubleshooting your worker & its components.\n\n Block Rewards (1)\n\n Block Rewards Nomination Eligibility Status\n\n Worker Binary (3)\n\n How To Add a New Worker - Windows\n\n How To Add a New Worker - MacOS\n\n How To Add a New Worker - Linux\n\n Staking (1)\n\n How to Stake Your Worker\n\n Troubleshooting (12)\n\n Windows - Why Is My Worker Failing PoW (Proof of Work)\n\n Linux - Waiting for IO Containers to Start\n\n Windows/Mac - Frequent worker disconnects while containers are active\n\n View all 12","tokens":178,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791264546555,"hash":"de123c70adf28d3800bd7f90c4be5cb4462dd85b"}
{"url":"https://ethereum.org/developers/docs/consensus-mechanisms/pos/gasper/","domain":"ethereum.org","title":"Gasper | ethereum.org","text":"GasperEdit page (opens in a new tab)Gasper is a combination of Casper the Friendly Finality Gadget (Casper-FFG) and the LMD-GHOST fork choice algorithm. Together these components form the consensus mechanism securing proof-of-stake Ethereum. Casper is the mechanism that upgrades certain blocks to \"finalized\" so that new entrants into the network can be confident that they are syncing the canonical chain. The fork choice algorithm uses accumulated votes to ensure that nodes can easily select the correct one when forks arise in the blockchain.\nNote that the original definition of Casper-FFG was updated slightly for inclusion in Gasper. On this page we consider the updated version.\nPrerequisites\nTo understand this material it is necessary to read the introductory page on proof-of-stake.\nThe role of Gasper\nGasper sits on top of a proof-of-stake blockchain where nodes provide ether as a security deposit that can be destroyed if they are lazy or dishonest in proposing or validating blocks. Gasper is the mechanism defining how validators get rewarded and punished, decide which blocks to accept and reject, and which fork of the blockchain to build on.\nWhat is finality?\nFinality is a property of certain blocks that means they cannot be reverted unless there has been a critical consensus failure and an attacker has destroyed at least 1/3 of the total staked ether. Finalized blocks can be thought of as information the blockchain is certain about. A block must pass through a two-step upgrade procedure for a block to be finalized:\n\nTwo-thirds of the total staked ether must have voted in favor of that block's inclusion in the canonical chain. This condition upgrades the block to \"justified\". Justified blocks are unlikely to be reverted, but they can be under certain conditions.\nWhen another block is justified on top of a justified block, it is upgraded to \"finalized\". Finalizing a block is a commitment to include the block in the canonical chain. It cannot be reverted unless an attacker destroys millions of ether (billions of $USD).\n\nThese block upgrades do not happen in every slot. Instead, only epoch-boundary blocks can be justified and finalized. These blocks are known as \"checkpoints\". Upgrading considers pairs of checkpoints. A \"supermajority link\" must exist between two successive checkpoints (i.e., two-thirds of the total staked ether voting that checkpoint B is the correct descendant of checkpoint A) to upgrade the less recent checkpoint to finalized and the more recent block to justified.\nBecause finality requires a two-thirds agreement that a block is canonical, an attacker cannot possibly create an alternative finalized chain without:\n\nOwning or manipulating two-thirds of the total staked ether.\nDestroying at least one-third of the total staked ether.\n\nThe first condition arises because two-thirds of the staked ether is required to finalize a chain. The second condition arises because if two-thirds of the total stake has voted in favor of both forks, then one-third must have voted on both. Double-voting is a slashing condition that would be maximally punished, and one-third of the total stake would be destroyed. As of May 2022, this requires an attacker to burn around $10 billion worth of ether. The algorithm that justifies and finalizes blocks in Gasper is a slightly modified form of Casper the Friendly Finality Gadget (Casper-FFG) (opens in a new tab).\nIncentives and Slashing\nValidators get rewarded for honestly proposing and validating blocks. Ether is rewarded and added to their stake. On the other hand, validators that are absent and fail to act when called upon miss out on these rewards and sometimes lose a small portion of their existing stake. However, the penalties for being offline are small and, in most cases, amount to opportunity costs of missing rewards. However, some validator actions are very difficult to do accidentally and signify some malicious intent, such as proposing multiple blocks for the same slot, attesting to multiple blocks for the same slot, or contradicting previous checkpoint votes. These are \"slashable\" behaviors that are penalized more harshly—slashing results in some portion of the validator's stake being destroyed and the validator being removed from the network of validators. This process takes 36 days. On Day 1, there is an initial penalty of up to 1 ETH. Then the slashed validator's ether slowly drains away across the exit period, but on Day 18, they receive a \"correlation penalty\", which is larger when more validators are slashed around the same time. The maximum penalty is the entire stake. These rewards and penalties are designed to incentivize honest validators and disincentivize attacks on the network.\nInactivity Leak\nAs well as security, Gasper also provides \"plausible liveness\". This is the condition that as long as two-thirds of the total staked ether is voting honestly and following the protocol, the chain will be able to finalize irrespective of any other activity (such as attacks, latency issues, or slashings). Put another way, one-third of the total staked ether must be somehow compromised to prevent the chain from finalizing. In Gasper, there is an additional line of defense against a liveness failure, known as the \"inactivity leak\". This mechanism activates when the chain has failed to finalize for more than four epochs. The validators that are not actively attesting to the majority chain have their stake gradually drained away until the majority regains two-thirds of the total stake, ensuring that liveness failures are only temporary.\nFork choice\nThe original definition of Casper-FFG included a fork choice algorithm that imposed the rule: follow the chain containing the justified checkpoint that has the greatest height where height is defined as the greatest distance from the genesis block. In Gasper, the original fork choice rule is deprecated in favor of a more sophisticated algorithm called LMD-GHOST. It is important to realize that under normal conditions, a fork choice rule is unnecessary - there is a single block proposer for every slot, and honest validators attest to it. It is only in cases of large network asynchronicity or when a dishonest block proposer has equivocated that a fork choice algorithm is required. However, when those cases do arise, the fork choice algorithm is a critical defense that secures the correct chain.\nLMD-GHOST stands for \"latest message-driven greedy heaviest observed sub-tree\". This is a jargon-heavy way to define an algorithm that selects the fork with the greatest accumulated weight of attestations as the canonical one (greedy heaviest subtree) and that if multiple messages are received from a validator, only the latest one is considered (latest-message driven). Before adding the heaviest block to its canonical chain, every validator assesses each block using this rule.\nFurther Reading\n\nGasper: Combining GHOST and Casper (opens in a new tab)\nCasper the Friendly Finality Gadget (opens in a new tab)","tokens":1754,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264549491,"hash":"dff0911ac2281fae12542f976530226ec7565e11"}
{"url":"https://dev-forum.pyth.network/t/failed-to-get-realtime-price-feed-may-be-related-to-cloudflare/468","domain":"dev-forum.pyth.network","title":"Failed to get realtime price feed (may be related to cloudflare) - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Failed to get realtime price feed (may be related to cloudflare) \n\n Price FeedsBenchmarks(Historic Prices)\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2025\n\n 1 / 3\n\n Nov 2025\n\n Nov 2025\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n Hello, I’m currently using hermes.pyth.network/v2/updates/price/stream to get price, but currently I can’t connect to the stream. Is it caused by cloudflare? Is there any method I can use to get realtime price?\n\n 2\n\n post by KemarTiti on Nov 18, 2025\n\n KemarTiti\n\n Hey,\nThere are indeed some issues on the public Hermes endpoint caused by Cloudflare.\nShould be resolved soon but I’d really suggest to get a dedicated / private endpoint from any of these providers: https://docs.pyth.network/price-feeds/core/api-instances-and-providers/hermes#node-providers\nMost run Hermes on bare metal and have not experienced any issue today.\nIf you want me to connect you to one, please send me a dm here with your telegram id or email.\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n really thanks! but how to dm you?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error running Hermes client\n\n Price Feeds\n\n 1\n\n 496\n\n Jun 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 397\n\n Nov 2025\n\n Powered by Discourse","tokens":1261,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264556767,"hash":"58ff31ea949e11bb4560c5b80c7aaeea47637848"}
{"url":"https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/","domain":"ethereum.org","title":"Weak subjectivity | ethereum.org","text":"Weak subjectivityEdit page (opens in a new tab)Subjectivity in blockchains refers to reliance upon social information to agree on the current state. There may be multiple valid forks that are chosen from according to information gathered from other peers on the network. The converse is objectivity which refers to chains where there is only one possible valid chain that all nodes will necessarily agree upon by applying their coded rules. There is also a third state, known as weak subjectivity. This refers to a chain that can progress objectively after some initial seed of information is retrieved socially.\nPrerequisites\nTo understand this page it is necessary to first understand the fundamentals of proof-of-stake.\nWhat problems does weak subjectivity solve?\nSubjectivity is inherent to proof-of-stake blockchains because selecting the correct chain from multiple forks is done by counting historical votes. This exposes the blockchain to several attack vectors, including long-range attacks whereby nodes that participated very early in the chain maintain an alternative fork that they release much later to their own advantage. Alternatively, if 33% of validators withdraw their stake but continue to attest and produce blocks, they might generate an alternative fork that conflicts with the canonical chain. New nodes or nodes that have been offline for a long time might not be aware that these attacking validators have withdrawn their funds, so attackers could trick them into following an incorrect chain. Ethereum can solve these attack vectors by imposing constraints that diminish the subjective aspects of the mechanism—and therefore trust assumptions—to the bare minimum.\nWeak subjectivity checkpoints\nWeak subjectivity is implemented in proof-of-stake Ethereum by using \"weak subjectivity checkpoints\". These are state roots that all nodes on the network agree belong in the canonical chain. They serve the same \"universal truth\" purpose as genesis blocks, except that they do not sit at the genesis position in the blockchain. The fork choice algorithm trusts that the blockchain state defined in that checkpoint is correct and that it independently and objectively verifies the chain from that point onwards. The checkpoints act as \"revert limits\" because blocks located before weak-subjectivity checkpoints cannot be changed. This undermines long-range attacks simply by defining long-range forks to be invalid as part of the mechanism design. Ensuring that the weak subjectivity checkpoints are separated by a smaller distance than the validator withdrawal period ensures that a validator that forks the chain is slashed at least some threshold amount before they can withdraw their stake and that new entrants cannot be tricked onto incorrect forks by validators whose stake has been withdrawn.\nDifference between weak subjectivity checkpoints and finalized blocks\nFinalized blocks and weak subjectivity checkpoints are treated differently by Ethereum nodes. If a node becomes aware of two competing finalized blocks, then it is torn between the two - it has no way to identify automatically which is the canonical fork. This is symptomatic of a consensus failure. In contrast, a node simply rejects any block that conflicts with its weak subjectivity checkpoint. From the node's perspective, the weak subjectivity checkpoint represents an absolute truth that cannot be undermined by new knowledge from its peers.\nHow weak is weak?\nThe subjective aspect of Ethereum's proof-of-stake is the requirement for a recent state (weak subjectivity checkpoint) from a trusted source to sync from. The risk of getting a bad weak subjectivity checkpoint is very low because they can be checked against several independent public sources such as block explorers or multiple nodes. However, there is always some degree of trust required to run any software application, for example, trusting that the software developers have produced honest software.\nA weak subjectivity checkpoint may even come as part of the client software. Arguably an attacker can corrupt the checkpoint in the software and can just as easily corrupt the software itself. There is no real crypto-economic route around this problem, but the impact of untrustworthy developers is minimized in Ethereum by having multiple independent client teams, each building equivalent software in different languages, all with a vested interest in maintaining an honest chain. Block explorers may also provide weak subjectivity checkpoints or a way to cross-reference checkpoints obtained from elsewhere against an additional source.\nFinally, checkpoints can be requested from other nodes; perhaps another Ethereum user that runs a full node can provide a checkpoint that validators can then verify against data from a block explorer. Overall, trusting the provider of a weak subjectivity checkpoint can be considered as problematic as trusting the client developers. The overall trust required is low. It is important to note that these considerations only become important in the very unlikely event that a majority of validators conspire to produce an alternate fork of the blockchain. Under any other circumstances, there is only one Ethereum chain to choose from.\nFurther Reading\n\nWeak subjectivity in Eth2 (opens in a new tab)\nVitalik: How I learned to love weak subjectivity (opens in a new tab)\nWeak subjectivity (Teku docs) (opens in a new tab)\nPhase-0 Weak subjectivity guide (opens in a new tab)\nAnalysis of weak subjectivity in Ethereum 2.0 (opens in a new tab)","tokens":1386,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264559691,"hash":"67483dc1965292146c46a2d3ed43eae0fd8ad4d6"}
{"url":"https://governance.aave.com/t/request-include-25k-usdc-sent-directly-to-v3-pool-in-next-rescue-mission-phase/25317","domain":"governance.aave.com","title":"Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase - Development - Aave","text":"Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase \n\n Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by gl2361 on Jul 14\n\n gl2361\n\n Hi all,\nOn [date] I mistakenly sent 25,000 USDC directly to the Aave V3 Pool contract on [network] instead of supplying via the interface.\n\nTx hash: 0x6a4cd27125fe4916909efdb9e6cc79f298ce514e56bd4851e92641f71c666b5c\nPool proxy address: 0x98c23e9d8f34fefb1b7bd6a91b7ff122f4e16f5c\nSending wallet: 0x32fcf748e4dcebd1081bfcccb94eb721101f27c0 (I can sign a message to prove ownership)\n\nI understand from Rescue Mission Phases 1–3 that recovery of tokens sent directly to upgradeable Aave contracts is technically feasible via a governance-approved implementation upgrade, with claims distributed through the AaveMerkleDistributor to the original sending address.\nRequest to BGD Labs / ACI / the community: could this transfer be registered for inclusion in a future rescue phase covering the V3 Pool? Happy to provide any additional verification needed.\nThank you.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 78\n\n Aug 5\n\n Rescue of wrong sent tokens\n\n Governance\n\n 0\n\n 48\n\n Aug 13\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d","tokens":404,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264559760,"hash":"bced974040c04d33fc5951e4c5669abec7a85b32"}
{"url":"https://dev-forum.pyth.network/t/failed-to-get-realtime-price-feed-may-be-related-to-cloudflare/468/2","domain":"dev-forum.pyth.network","title":"Failed to get realtime price feed (may be related to cloudflare) - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price FeedsBenchmarks(Historic Prices)\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2025\n\n 3 / 3\n\n Nov 2025\n\n Nov 2025\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n Hello, I’m currently using hermes.pyth.network/v2/updates/price/stream to get price, but currently I can’t connect to the stream. Is it caused by cloudflare? Is there any method I can use to get realtime price?\n\n 2\n\n post by KemarTiti on Nov 18, 2025\n\n KemarTiti\n\n Hey,\nThere are indeed some issues on the public Hermes endpoint caused by Cloudflare.\nShould be resolved soon but I’d really suggest to get a dedicated / private endpoint from any of these providers: https://docs.pyth.network/price-feeds/core/api-instances-and-providers/hermes#node-providers\nMost run Hermes on bare metal and have not experienced any issue today.\nIf you want me to connect you to one, please send me a dm here with your telegram id or email.\n\n post by Astera on Nov 18, 2025\n\n Astera\n\n really thanks! but how to dm you?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error running Hermes client\n\n Price Feeds\n\n 1\n\n 496\n\n Jun 2025\n\n Pyth API ont showing updated prices\n\n Price Feeds\n\n 0\n\n 24\n\n Apr 9\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 397\n\n Nov 2025\n\n Powered by Discourse","tokens":1244,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264567232,"hash":"479d8e8f937741b5a13f5ff8962adbc376544e67"}
{"url":"https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/","domain":"ethereum.org","title":"Spin up your own Ethereum node | ethereum.org","text":"Spin up your own Ethereum nodeEdit page (opens in a new tab)Running your own node provides you various benefits, opens new possibilities, and helps to support the ecosystem. This page will guide you through spinning up your own node and taking part in validating Ethereum transactions.\nNote that after The Merge, two clients are required to run an Ethereum node; an execution layer (EL) client and a consensus layer (CL) client. This page will show how to install, configure and connect these two clients to run an Ethereum node.\nPrerequisites\nYou should understand what an Ethereum node is and why you might want to run a client. This is covered in Nodes and clients.\nIf you're new to the topic of running a node, or looking for a less technical path, we recommend first checking out our user-friendly introduction on running an Ethereum node.\nChoosing an approach\nThe first step in spinning up your node is choosing your approach. Based on requirements and various possibilities, you must select the client implementation (of both execution and consensus clients), the environment (hardware, system), and the parameters for client settings.\nThis page will guide you through these decisions and help you find the most suitable way to run your Ethereum instance.\nTo choose from client implementations, see all the available Mainnet ready execution clients, consensus clients and learn about client diversity.\nDecide whether to run the software on your own hardware or in the cloud, considering clients' requirements.\nAfter preparing the environment, install the chosen clients either with beginner-friendly interface or manually using a terminal with advanced options.\nWhen the node is running and syncing, you are ready to use it, but make sure to keep an eye on its maintenance.\n\nEnvironment and hardware\nLocal or cloud\nEthereum clients are able to run on consumer grade computers and don't require any special hardware, like mining machines for example. Therefore, you have various options for deploying the node based on your needs.\nTo simplify, let's think about running a node on both a local physical machine and a cloud server:\n\nCloud\n\nProviders offer high server uptime and static public IP addresses\nGetting dedicated or virtual server can be more comfortable than building your own\nTrade off is trusting a third party - server provider\nBecause of the required storage size for full node, the price of a rented server might get high\n\nOwn hardware\n\nMore trustless and sovereign approach\nOne time investment\nAn option to buy preconfigured machines\nYou have to physically prepare, maintain, and potentially troubleshoot the machine and networking\n\nBoth options have different advantages summed up above. If you are looking for a cloud solution, in addition to many traditional cloud computing providers, there are also services focused on deploying nodes. Check out nodes as a service for more options on hosted nodes.\nHardware\nHowever, a censorship-resistant, decentralized network should not rely on cloud providers. Instead, running your node on your own local hardware is healthier for the ecosystem. Estimations (opens in a new tab) show a large share of nodes run on the cloud, which could become a single point of failure.\nEthereum clients can run on your computer, laptop, server, or even a single-board computer. While running clients on your personal computer is possible, having a dedicated machine just for your node can significantly enhance its performance and security while minimizing the impact on your primary computer.\nUsing your own hardware can be very easy. There are many simple options as well as advanced setups for more technical people. So let's look into the requirements and means for running Ethereum clients on your machine.\nRequirements\nHardware requirements differ by client but generally are not that high since the node just needs to stay synced. Don't confuse it with mining, which requires much more computing power. Sync time and performance do improve with more powerful hardware however.\nBefore installing any client, please ensure your computer has enough resources to run it. You can find the minimum and recommended requirements below.\nThe bottleneck for your hardware is mostly disk space. Syncing the Ethereum blockchain is very input/output intensive and requires a lot of space. It is best to have a solid-state drive (SSD) with hundreds of GBs of free space to spare even after the synchronization.\nThe size of the database and speed of the initial synchronization depends on the chosen client, its configuration and sync strategy.\nAlso make sure your internet connection is not limited by a bandwidth cap (opens in a new tab). It's recommended to use an unmetered connection since initial sync and data broadcasted to the network could exceed your limit.\nOperating system\nAll clients support major operating systems - Linux, MacOS, Windows. This means you can run nodes on regular desktop or server machines with the operating system (OS) that suits you the best. Make sure your OS is up to date to avoid potential issues and security vulnerabilities.\nMinimum requirements\n\nCPU with 2+ cores\n16 GB RAM (32 GB recommended for stability)\n2 TB NVMe SSD (likely exceeded by 2027, read more about Great and less great SSDs for Ethereum nodes (opens in a new tab))\n25+ MBit/s bandwidth\n\nRecommended specifications\nCurrent hardware guidance for node operators is identified in EIP-7870 (opens in a new tab). For a full node it recommends:\n\nFast CPU with 4+ cores (8+ cores if validating)\n32 GB RAM (64 GB recommended if validating to ensure stability)\n4 TB NVMe SSD (DRAM-less and QLC drives are discouraged)\n50 MBit/s down / 15+ MBit/s up bandwidth (25+ MBit/s up if validating)\n\nThe sync mode and client you choose will affect space requirements, but we've estimated the disk space you'll need for each client below.\nClientDisk size (snap sync)Disk size (full archive)Besu800GB+12TB+ErigonN/A2.5TB+Geth500GB+12TB+Nethermind500GB+12TB+RethN/A2.2TB+\n\nNote: Erigon and Reth do not offer snap sync, but Full Pruning is possible (~2TB for Erigon, ~1.2TB for Reth)\n\nFor consensus clients, space requirement also depends on client implementation and enabled features (e.g., validator slasher) but generally count with another 200GB needed for beacon data. With a large number of validators, the bandwidth load grows as well. You can find details on consensus client requirements in this analysis (opens in a new tab).\nPlug-and-play solutions\nThe easiest option for running a node with your own hardware is using plug-and-play boxes. Preconfigured machines from vendors offer the most straightforward experience: order, connect, run. Everything is preconfigured and runs automatically with an intuitive guide and dashboard for monitoring and controlling the software.\n\nDappNode (opens in a new tab)\nAvado (opens in a new tab)\n\nEthereum on a single-board computer\nAn easy and cheap way of running an Ethereum node is to use a single board computer, even with an ARM architecture like the Raspberry Pi. Ethereum on ARM (opens in a new tab) provides easy-to-run images of multiple execution and consensus client for Raspberry Pi and other ARM boards.\nSmall, affordable and efficient devices like these are ideal for running a node at home but keep in mind their limited performance.\nSpinning up the node\nThe actual client setup can be done either with automated launchers or manually, setting up client software directly.\nFor less advanced users, the recommended approach is to use a launcher, software that guides you through the installation and automates the client setup process. However, if you have some experience of using a terminal, the steps for manual setup should be simple to follow.\nGuided setup\nMultiple user-friendly projects aim to improve the experience of setting up a client. These launchers provide automatic client installation and configuration, with some even offering a graphical interface for guided setup and monitoring of clients.\nBelow are a few projects which can help you install and control clients just with a few clicks:\n\nDappNode (opens in a new tab) - DappNode doesn't come only with a machine from a vendor. The software, the actual node launcher and control center with many features can be used on arbitrary hardware.\nEthPillar (opens in a new tab) - Quickest and easiest way to setup a full node. One-liner setup tool and node management TUI. Free. Open source. Public goods for Ethereum by solo stakers. ARM64 and AMD64 support.\neth-docker (opens in a new tab) - Automated setup using Docker focused on easy and secure staking, requires basic terminal and Docker knowledge, recommended for a bit more advanced users.\nStereum (opens in a new tab) - Launcher for installing clients on a remote server via SSH connection with a GUI setup guide, control center, and many other features.\nSedge (opens in a new tab) - Node setup tool which automatically generates a Docker configuration using CLI wizard. Written in Go by Nethermind.\nChainstack Self-Hosted (opens in a new tab) - Web UI and CLI for deploying execution and consensus clients on Kubernetes. Snapshot bootstrap and built-in monitoring included. Free. No Chainstack account required. Built by Chainstack.\n\nManual clients setup\nThe other option is to download, verify, and configure the client software manually. Even if some clients offer a graphical interface, a manual setup still requires basic skills with the terminal but offers much more versatility.\nAs explained before, setting up your own Ethereum node will require running a pair of consensus and execution clients. Some clients might include a light client of the other kind and sync without any other software needed. However, full trustless verification requires both implementations.\nGetting the client software\nFirst, you need to obtain your preferred execution client and consensus client software.\nYou can simply download an executable application or installation package that suits your operating system and architecture. Always verify the signatures and checksums of downloaded packages. Some clients also offer repositories or Docker images for easier installation and updates. All of the clients are open source, so you can also build them from source. This is a more advanced method, but in some cases, it might be required.\nInstructions for installing each client are provided in the documentation linked in the client lists above.\nHere are the release pages of clients where you can find their pre-built binaries or instructions on installation:\nExecution clients\n\nBesu (opens in a new tab)\nErigon (opens in a new tab)\nGeth (opens in a new tab)\nNethermind (opens in a new tab)\nReth (opens in a new tab)\n\nIt is also worth noting that client diversity is an issue on the execution layer. It is recommended that readers consider running a minority execution client.\nConsensus clients\n\nLighthouse (opens in a new tab)\nLodestar (opens in a new tab) (Doesn't provide a pre-built binary, only a Docker image or to be build from source)\nNimbus (opens in a new tab)\nPrysm (opens in a new tab)\nTeku (opens in a new tab)\n\nClient diversity is critical for consensus nodes running validators. If the majority of validators are running a single client implementation, network security is at risk. It is therefore recommended to consider choosing a minority client.\nSee the latest network client usage (opens in a new tab) and learn more about client diversity.\nVerifying the software\nWhen downloading software from the internet, it's recommended to verify its integrity. This step is optional but especially with crucial infrastructure piece like the Ethereum client, it's important to be aware of potential attack vectors and avoid them. If you downloaded a pre-built binary, you need to trust it and risk that an attacker could swap the executable for a malicious one.\nDevelopers sign released binaries with their PGP keys so you can cryptographically verify you are running exactly the software they created. You just need to obtain public keys used by developers, which can be found on client release pages or in documentation. After downloading the client release and its signature, you can use a PGP implementation, e.g., GnuPG (opens in a new tab) to easily verify them. Check out a tutorial on verifying open-source software using gpg on linux (opens in a new tab) or Windows/MacOS (opens in a new tab).\nAnother form of verification is to make sure that the hash, a unique cryptographic fingerprint, of the software you downloaded matches the one provided by developers. This is even easier than using PGP, and some clients offer only this option. Just run the hash function on the downloaded software and compare it to the one from the release page. For example:\nsha256sum teku-22.6.1.tar.gz\n\n9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde\n\nClient setup\nAfter installing, downloading, or compiling the client software, you are ready to run it. This only means it has to be executed with the proper configuration. Clients offer rich configuration options, which can enable various features.\nLet's start with options that can significantly influence client performance and data usage. Sync modes represent different methods of downloading and validating blockchain data. Before starting the node, you should decide what network and sync mode to use. The most important things to consider are the disk space, and sync time the client will need. Pay attention to the client's docs to determine which sync mode is the default. If that doesn't suit you, pick another one based on the level of security, available data, and cost. Apart from the synchronization algorithm, you can also set pruning of different kinds of old data. Pruning enables deleting outdated data, i.e., removing state trie nodes that are unreachable from recent blocks.\nOther basic configuration options are, e.g., choosing a network - Mainnet or testnets, enabling HTTP endpoint for RPC or WebSockets, etc. You can find all features and options in the client's documentation. Various client configurations can be set by executing the client with the corresponding flags directly in the CLI or config file. Each client is a bit different; please always refer to its official documentation or help page for details on config options.\nFor testing purposes, you might prefer to run a client on one of the testnet networks. See overview of supported networks.\nExamples of running execution clients with basic configuration can be found in next section.\nStarting the execution client\nBefore starting the Ethereum client software, perform a last check that your environment is ready. For example, make sure:\n\nThere is enough disk space considering the chosen network and sync mode.\nMemory and CPU is not halted by other programs.\nOperating system is updated to the latest version.\nSystem has the correct time and date.\nYour router and firewall accept connections on listening ports. By default Ethereum clients use a listener (TCP) port and a discovery (UDP) port, both on 30303 by default.\n\nRun your client on a testnet first to help make sure everything is working correctly.\nYou need to declare any client settings that aren't default at the start. You can use flags or the config file to declare your preferred configuration. Set of features and config syntax of each client differs. Check out your client's documentation for the specifics.\nExecution and consensus clients communicate via an authenticated endpoint specified in Engine API (opens in a new tab). In order to connect to a consensus client, the execution client must generate a jwtsecret (opens in a new tab) at a known path. For security and stability reasons, clients should run on the same machine, and both clients must know this path as it is used to authenticate a local RPC connection between them. The execution client must also define a listening port for authenticated APIs.\nThis token is generated automatically by the client software, but in some cases, you might need to do it yourself. You can generate it using OpenSSL (opens in a new tab):\nopenssl rand -hex 32 > jwtsecret\n\nRunning an execution client\nThis section will guide you through starting execution clients. It only serves as an example of a basic configuration, which will start the client with these settings:\n\nSpecifies network to connect to, Mainnet in our examples\n\nYou can instead choose one of testnets for preliminary testing of your setup\n\nDefines data directory, where all the data including blockchain will be stored\n\nMake sure to substitute the path with a real one, e.g., pointing to your external drive\n\nEnables interfaces for communicating with the client\n\nIncluding JSON-RPC and Engine API for communication with consensus client\n\nDefines path to jwtsecret for authenticated API\n\nMake sure to substitute the example path with a real one which can be accessed by clients, e.g., /tmp/jwtsecret\n\nPlease keep in mind that this is just a basic example, all other settings will be set to default. Pay attention to the documentation of each client to learn about default values, settings, and features. For more features, for example for running validators, monitoring, etc., please refer to the documentation of the specific client.\n\nNote that backslashes \\ in examples are only for formatting purposes; config flags can be defined in a single line.\n\nRunning Besu\nThis example starts Besu on Mainnet, stores blockchain data in default format at /data/ethereum, enables JSON-RPC and Engine RPC for connecting consensus client. Engine API is authenticated with token jwtsecret and only calls from localhost are allowed.\nbesu --network=mainnet \\\n --data-path=/data/ethereum \\\n --rpc-http-enabled=true \\\n --engine-rpc-enabled=true \\\n --engine-host-allowlist=\"*\" \\\n --engine-jwt-enabled=true \\\n --engine-jwt-secret=/path/to/jwtsecret\n\nBesu also comes with a launcher option which will ask a series of questions and generate the config file. Run the interactive launcher using:\nbesu --Xlauncher\n\nBesu's documentation (opens in a new tab) contains additional options and configuration details.\nRunning Erigon\nThis example starts Erigon on Mainnet, stores blockchain data at /data/ethereum, enables JSON-RPC, defines which namespaces are allowed and enables authentication for connecting the consensus client which is defined by the jwtsecret path.\nerigon --chain mainnet \\\n --datadir /data/ethereum \\\n --http --http.api=engine,eth,web3,net \\\n --authrpc.jwtsecret=/path/to/jwtsecret\n\nErigon by default performs a full sync with 8GB HDD which will result in more than 2TB of archive data. Make sure datadir is pointing to disk with enough free space or look into --prune flag which can trim different kinds of data. Check the Erigon's --help to learn more.\nRunning Geth\nThis example starts Geth on Mainnet, stores blockchain data at /data/ethereum, enables JSON-RPC and defines which namespaces are allowed. It also enables authentication for connecting consensus client which requires path to jwtsecret and also option defining which connections are allowed, in our example only from localhost.\ngeth --mainnet \\\n --datadir \"/data/ethereum\" \\\n --http --authrpc.addr localhost \\\n --authrpc.vhosts=\"localhost\" \\\n --authrpc.port 8551\n --authrpc.jwtsecret=/path/to/jwtsecret\n\nCheck docs for all configuration options (opens in a new tab) and learn more about running Geth with a consensus client (opens in a new tab).\nRunning Nethermind\nNethermind offers various installation options (opens in a new tab). The package comes with various binaries, including a Launcher with a guided setup, which will help you to create the configuration interactively. Alternatively, you find Runner which is the executable itself and you can just run it with config flags. JSON-RPC is enabled by default.\nNethermind.Runner --config mainnet \\\n --datadir /data/ethereum \\\n --JsonRpc.JwtSecretFile=/path/to/jwtsecret\n\nNethermind docs offer a complete guide (opens in a new tab) on running Nethermind with consensus client.\nAn execution client will initiate its core functions, chosen endpoints, and start looking for peers. After successfully discovering peers, the client starts synchronization. The execution client will await a connection from consensus client. Current blockchain data will be available once the client is successfully synced to the current state.\nRunning Reth\nThis example starts Reth on Mainnet, using default data location. Enables JSON-RPC and Engine RPC authentication for connecting the consensus client which is defined by the jwtsecret path, with only calls from localhost are allowed.\nreth node \\\n --authrpc.jwtsecret /path/to/jwtsecret \\\n --authrpc.addr 127.0.0.1 \\\n --authrpc.port 8551\n\nSee Configuring Reth (opens in a new tab) to learn more about default data directories. Reth's documentation (opens in a new tab) contains additional options and configuration details.\nStarting the consensus client\nThe consensus client must be started with the right port configuration to establish a local RPC connection to the execution client. The consensus clients have to be run with the exposed execution client port as configuration argument.\nThe consensus client also needs the path to the execution client's jwt-secret in order to authenticate the RPC connection between them. Similar to execution examples above, each consensus client has a configuration flag which takes the jwt token file path as an argument. This must be consistent with the jwtsecret path provided to the execution client.\nIf you plan to run a validator, make sure to add a configuration flag specifying the Ethereum address of the fee recipient. This is where ether rewards for your validator accumulate. Each consensus client has an option, e.g., --suggested-fee-recipient=0xabcd1, that takes an Ethereum address as an argument.\nWhen starting a Beacon Node on a testnet, you can save significant syncing time by using a public endpoint for Checkpoint sync (opens in a new tab).\nRunning a consensus client\nRunning Lighthouse\nBefore running Lighthouse, learn more on how to install and configure it in Lighthouse Book (opens in a new tab).\nlighthouse beacon_node \\\n --network mainnet \\\n --datadir /data/ethereum \\\n --http \\\n --execution-endpoint http://127.0.0.1:8551 \\\n --execution-jwt /path/to/jwtsecret\n\nRunning Lodestar\nInstall Lodestar software by compiling it or downloading the Docker image. Learn more in docs (opens in a new tab) and more comprehensive setup guide (opens in a new tab).\nlodestar beacon \\\n --dataDir=\"/data/ethereum\" \\\n --network=mainnet \\\n --eth1.enabled=true \\\n --execution.urls=\"http://127.0.0.1:8551\" \\\n --jwt-secret=\"/path/to/jwtsecret\"\n\nRunning Nimbus\nNimbus comes with both consensus and execution clients. It can be run on various devices even with very modest computing power.\nAfter installing dependencies and Nimbus itself (opens in a new tab), you can run its consensus client:\nnimbus_beacon_node \\\n --network=mainnet \\\n --web3-url=http://127.0.0.1:8551 \\\n --rest \\\n --jwt-secret=\"/path/to/jwtsecret\"\n\nRunning Prysm\nPrysm comes with script which allows easy automatic installation. Details can be found in the Prysm docs (opens in a new tab).\n./prysm.sh beacon-chain \\\n --mainnet \\\n --datadir /data/ethereum \\\n --execution-endpoint=http://localhost:8551 \\\n --jwt-secret=/path/to/jwtsecret\n\nRunning Teku\nteku --network mainnet \\\n --data-path \"/data/ethereum\" \\\n --ee-endpoint http://localhost:8551 \\\n --ee-jwt-secret-file \"/path/to/jwtsecret\"\n\nWhen a consensus client connects to the execution client to read the deposit contract and identify validators, it also connects to other Beacon Node peers and begins syncing consensus slots from genesis. Once the Beacon Node reaches the current epoch, the Beacon API becomes usable for your validators. Learn more about Beacon Node APIs (opens in a new tab).\nAdding Validators\nA consensus client serves as a Beacon Node for validators to connect. Each consensus client has its own validator software described in detail in its respective documentation.\nRunning your own validator allows for solo staking, the most impactful and trustless method to support the Ethereum network. However, this requires a deposit of 32 ETH. To run a validator on your own node with a smaller amount, a decentralized pool with permissionless node operators, such as Rocket Pool (opens in a new tab), might interest you.\nThe easiest way to get started with staking and validator key generation is to use the Hoodi Testnet Staking Launchpad (opens in a new tab), which allows you to test your setup by running nodes on Hoodi (opens in a new tab). When you're ready for Mainnet, you can repeat these steps using the Mainnet Staking Launchpad (opens in a new tab).\nLook into staking page for an overview about staking options.\nUsing the node\nExecution clients offer RPC API endpoints that you can use to submit transactions, interact with or deploy smart contracts on the Ethereum network in various ways:\n\nManually calling them with a suitable protocol (e.g., using curl)\nAttaching a provided console (e.g., geth attach)\nImplementing them in applications using web3 libraries, e.g., web3.py (opens in a new tab), ethers (opens in a new tab)\n\nDifferent clients have different implementations of the RPC endpoints. But there is a standard JSON-RPC which you can use with every client. For an overview read the JSON-RPC docs. Applications that need information from the Ethereum network can use this RPC. For example, popular wallet MetaMask lets you connect to your own RPC endpoint (opens in a new tab) which has strong privacy and security benefits.\nThe consensus clients all expose a Beacon API (opens in a new tab) that can be used to check the status of the consensus client or download blocks and consensus data by sending requests using tools such as Curl (opens in a new tab). More information on this can be found in the documentation for each consensus client.\nReaching RPC\nThe default port for the execution client JSON-RPC is 8545 but you can modify the ports of local endpoints in the configuration. By default, the RPC interface is only reachable on the localhost of your computer. To make it remotely accessible, you might want to expose it to the public by changing the address to 0.0.0.0. This will make it reachable over local network and public IP addresses. In most cases you'll also need to set up port forwarding on your router.\nApproach exposing ports to the internet with caution as this will let anyone on the internet control your node. Malicious actors could access your node to bring down your system or steal your funds if you're using your client as a wallet.\nA way around this is to prevent potentially harmful RPC methods from being modifiable. For example, with Geth, you can declare modifiable methods with a flag: --http.api web3,eth,txpool.\nAccess to the RPC interface can be extended through the development of edge layer APIs or web server applications, like Nginx, and connecting them to your client's local address and port. Leveraging a middle layer can also allow developers the ability to setup a certificate for secure https connections to the RPC interface.\nSetting up a web server, a proxy, or external facing Rest API is not the only way to provide access to the RPC endpoint of your node. Another privacy-preserving way to set up a publicly reachable endpoint is to host the node on your own Tor (opens in a new tab) onion service. This will let you reach the RPC outside your local network without a static public IP address or opened ports. However, using this configuration may only allow the RPC endpoint to be accessible via the Tor network which is not supported by all the applications and might result in connection issues.\nTo do this, you have to create your own onion service (opens in a new tab). Checkout the documentation (opens in a new tab) on onion service setup to host your own. You can point it to a web server with proxy to the RPC port or just directly to the RPC.\nLastly, and one of the most popular ways to provide access to internal networks is through a VPN connection. Depending on your use case and the quantity of users needing access to your node, a secure VPN connection might be an option. OpenVPN (opens in a new tab) is a full-featured SSL VPN which implements OSI layer 2 or 3 secure network extension using the industry standard SSL/TLS protocol, supports flexible client authentication methods based on certificates, smart cards, and/or username/password credentials, and allows user or group-specific access control policies using firewall rules applied to the VPN virtual interface.\nOperating the node\nYou should regularly monitor your node to make sure it's running properly. You may need to do occasional maintenance.\nKeeping a node online\nYour node doesn't have to be online all the time, but you should keep it online as much as possible to keep it in sync with the network. You can shut it down to restart it, but keep in mind that:\n\nShutting down can take a few minutes if the recent state is still being written on disk.\nForced shut downs can damage the database requiring you to resync the entire node.\nYour client will go out of sync with the network and will need to resync when you restart it. While the node can begin syncing from were it was last shutdown, the process can take time depending on how long it has been offline.\n\nThis doesn't apply on consensus layer validator nodes. Taking your node offline will affect all services dependent on it. If you are running a node for staking purposes you should try to minimize downtime as much as possible.\nCreating client services\nConsider creating a service to run your clients automatically on startup. For example, on Linux servers, good practice would be to create a service, e.g., with systemd, that executes the client with proper config, under a user with limited privileges and automatically restarts.\nUpdating clients\nYou need to keep your client software up-to-date with the latest security patches, features, and EIPs. Especially before hard forks, make sure you are running the correct client versions.\n\nBefore important network updates, EF publishes a post on its blog (opens in a new tab). You can subscribe to these announcements (opens in a new tab) to get a notification to your mail when your node needs an update.\n\nUpdating clients is very simple. Each client has specific instructions in their documentation, but the process is generally just to download the latest version and restart the client with the new executable. The client should pick up where it left off, but with the updates applied.\nEach client implementation has a human-readable version string used in the peer-to-peer protocol but is also accessible from the command line. This version string lets users check they are running the correct version and allows block explorers and other analytical tools interested in quantifying the distribution of specific clients over the network. Please refer to the individual client documentation for more information about version strings.\nRunning additional services\nRunning your own node lets you use services that require direct access to Ethereum client RPC. These are services built on top of Ethereum like layer 2 solutions, backend for wallets, block explorers, developer tools and other Ethereum infrastructure.\nMonitoring the node\nTo properly monitor your node, consider collecting metrics. Clients provide metrics endpoints so you can get comprehensive data about your node. Use tools like InfluxDB (opens in a new tab) or Prometheus (opens in a new tab) to create databases which you can turn into visualizations and charts in software like Grafana (opens in a new tab). There are many setups for using this software and different Grafana dashboards for you to visualise your node and the network as a whole. For example, check out tutorial on monitoring Geth.\nAs part of your monitoring, make sure to keep an eye on your machine's performance. During your node's initial sync, the client software may be very heavy on CPU and RAM. In addition to Grafana, you can use the tools your OS offers like htop or uptime to do this.\nFurther reading\n\nEthereum Staking Guides (opens in a new tab) - Somer Esat, updated often\nGuide | How to setup a validator for Ethereum staking on mainnet (opens in a new tab) – CoinCashew, updated often\nETHStaker guides on running validators on testnets (opens in a new tab) – ETHStaker, updated regularly\nSample AWS Blockchain Node Runner app for Ethereum Nodes (opens in a new tab) - AWS, updated often\nThe Merge FAQ for node operators (opens in a new tab) - July 2022\nAnalyzing the hardware requirements to be an Ethereum full validated node (opens in a new tab) – Albert Palau, 24 September 2018\nRunning Ethereum Full Nodes: A Guide for the Barely Motivated (opens in a new tab) – Justin Leroux, 7 November 2019\nRunning a Hyperledger Besu Node on the Ethereum Mainnet: Benefits, Requirements, and Setup (opens in a new tab) – Felipe Faraggi, 7 May 2020\nDeploying Nethermind Ethereum Client with Monitoring Stack (opens in a new tab) – Nethermind.eth, 8 July 2020\n\nRelated topics\n\nNodes and clients\nBlocks\nNetworks","tokens":8296,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264569904,"hash":"042305bc46dafcf2cac73526d58e9ff8ac7ffb71"}
{"url":"https://governance.aave.com/c/development/26","domain":"governance.aave.com","title":"Latest Development topics - Aave","text":"Latest topics in Development\n\n Development\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Technical maintenance proposals\n\n TL;DR\nA unified forum thread for the community to have better visibility on technical maintenance updates coming from BGD. \n\nContext\nWith Aave instances in multiple versions (v1, v2, v3) and networks, periodically it is…\n\n read more\n\n 131\n\n 25.9k\n\n Aug 6\n\n About the Development category\n\n 0\n\n 952\n\n Apr 2024\n\n AL Development Update | September 2026\n\n 0\n\n 201\n\n 5d\n\n How Aave Stable Vaults work\n\n 0\n\n 89\n\n 12d\n\n AL Development Update | August 2026\n\n 2\n\n 337\n\n Sep 1\n\n V4 Technical Maintenance Updates\n\n 3\n\n 447\n\n Aug 27\n\n Open-source TypeScript module for Aave V3 Health Factor evaluation\n\n 0\n\n 46\n\n Aug 25\n\n Aave V4 Config Engine\n\n 0\n\n 158\n\n Aug 20\n\n AL Development Update | July 2026\n\n 0\n\n 240\n\n Aug 14\n\n New Tooling — Who’s the Right Contact?\n\n 1\n\n 91\n\n Aug 13\n\n Aave Grants DAO: is the program still active and accepting applications?\n\n 1\n\n 176\n\n Jul 15\n\n Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase\n\n 0\n\n 116\n\n Jul 14\n\n AL Development Update | June 2026\n\n 0\n\n 281\n\n Jul 1\n\n Aave Labs. Request for Bounty Payout - May 2026\n\n 0\n\n 215\n\n Jun 5\n\n AL Development Update | May 2026\n\n 1\n\n 429\n\n Jun 1\n\n [ARFC] BGD. Aave v3.7\n\n 6\n\n 1.4k\n\n May 24\n\n AL Development Update | April 2026\n\n 0\n\n 304\n\n May 1\n\n Integration of Chainlink CRE into Aave Robot\n\n 1\n\n 498\n\n Apr 28\n\n “panic: arithmetic underflow or overflow” in calculateInterestRates while liquidation\n\n 1\n\n 422\n\n Apr 19\n\n Routing Swap and Horizon Fees to DAO Collector Addresses\n\n 1\n\n 207\n\n Apr 16\n\n Introducing Aave Checkpoint\n\n 0\n\n 531\n\n Apr 15\n\n [ARFC] Manual Risk Agents (manual AGRS migration)\n\n 7\n\n 524\n\n Apr 9\n\n BGD. Aave Bored Guides\n\n 8\n\n 827\n\n Apr 6\n\n [Direct-to-AIP] Aave DAO <> BGD Labs. 2-month security retainer\n\n 1\n\n 292\n\n Apr 5\n\n BGD. Leaving Aave\n\n 27\n\n 13.7k\n\n Apr 1\n\n AL Development Update | March 2026\n\n 1\n\n 341\n\n Apr 1\n\n BGD. Request for Bounty Payout - March 2026\n\n 0\n\n 237\n\n Mar 30\n\n Aave bug bounty future improvements\n\n 0\n\n 299\n\n Mar 27\n\n [ARFC] Aave <> Chainlink SVR. Multi-network expansion (Base, Arbitrum)\n\n 7\n\n 1.4k\n\n Mar 24\n\n Dynamic E-Mode Router for Capital Efficiency on Aave\n\n 0\n\n 130\n\n Mar 5","tokens":570,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264569992,"hash":"1db04fc3b11593b64525fa6444dc60d52e6abefb"}
{"url":"https://ethereum.org/developers/docs/nodes-and-clients/nodes-as-a-service/","domain":"ethereum.org","title":"Nodes as a service | ethereum.org","text":"Nodes as a serviceEdit page (opens in a new tab)Introduction\nRunning your own Ethereum node can be challenging, especially when getting started or while scaling fast. There are a number of services that run optimized node infrastructures for you, so you can focus on developing your application or product instead. We'll explain how node services work, the pros and cons for using them and list providers if you are interested in getting started.\nPrerequisites\nIf you don't already have an understanding of what nodes and clients are, check out Nodes and clients.\nStakers\nSolo stakers must run their own infrastructure rather than relying on third-party providers. This means running an execution client coupled with a consensus client. Before The Merge, it was possible to run a consensus client only and use a centralized provider for execution data; this is no longer possible - a solo staker must run both clients. However, there are services available to ease this process.\nRead more on running a node.\nThe services described on this page are for non-staking nodes.\nHow do node services work?\nNode service providers run distributed node clients behind the scenes for you, so you don't have to.\nThese services typically provide an API key that you can use to write to and read from the blockchain. They often include access to Ethereum testnets in addition to Mainnet.\nSome services offer you your own dedicated node that they manage for you, while others use load balancers to distribute activity across nodes.\nAlmost all node services are extremely easy to integrate with, involving one line changes in your code to swap out your self hosted node, or even switch between the services themselves.\nOften times node services will run a variety of node clients and types, allowing you to access full and archive nodes in addition to client specific methods in one API.\nIt's important to note that node services do not and should not store your private keys or information.\nWhat are the benefits of using a node service?\nThe main benefit for using a node service is not having to spend engineering time maintaining and managing nodes yourself. This allows you to focus on building your product rather than having to worry about infrastructure maintenance.\nRunning your own nodes can be very expensive from storage to bandwidth to valuable engineering time. Things like spinning up more nodes when scaling, upgrading nodes to the latest versions, and ensuring state consistency, can distract from building and spending resources on your desired web3 product.\nWhat are the cons of using a Node Service?\nBy using a node service you are centralizing the infrastructure aspect of your product. For this reason, projects that hold decentralization to the upmost importance might prefer self-hosting nodes rather than outsourcing to a 3rd party.\nRead more about the benefits of running your own node.\nPopular node services\nHere is a list of some of the most popular Ethereum node providers, feel free to add any that are missing! Each node service offers different benefits and features in addition to free or paid tiers, you should investigate which ones best suit your needs prior to making a decision.\n\nAlchemy (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nLargest free tier with 300M compute units per month (~30M getLatestBlock requests)\nMultichain support for Polygon, Starknet, Optimism, Arbitrum\nPowering ~70% of the largest Ethereum dapps and DeFi transaction volume\nReal-time webhook alerts via Alchemy Notify\nBest-in-class support and reliability / stability\nAlchemy's NFT API\nDashboard with Request Explorer, Mempool Watcher, and Composer\nIntegrated testnet faucet access\nActive Discord builder community with 18k users\n\nAllnodes (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nNo rate limits with PublicNode token created on the Allnodes portfolio page.\nPrivacy focused free rpc endpoints (100+ blockchains) on PublicNode (opens in a new tab)\nDedicated nodes without rate limits for 90+ blockchains\nDedicated archive nodes for 30+ blockchains\nAvailable in 3 regions (US, EU, Asia)\nSnapshots for 100+ blockchains on PublicNode (opens in a new tab)\n24/7 technical support with 99.90%-99.98% uptime SLA (depends on plan).\nPay-per-hour pricing\nPay with Credit Card, PayPal or Crypto\n\nAll That Node (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\n50,000 requests per day with free tier\nSupport for over 40 protocols\nJSON-RPC (EVM, Tendermint), REST, and Websocket APIs supported\nUnlimited access to archive date\n24/7 technical support and 99.9% over uptime\nFaucet available on multi chains\nUnlimited endpoint access with an limitless number of API keys\nTrace/Debug API supported\nAutomated updates\n\nAmazon Managed Blockchain (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFully managed Ethereum nodes\nAvailable in six regions\nJSON-RPC over HTTP and secure WebSockets\nSupports 3 chains\nSLAs, AWS Support 24/7\nGo-ethereum and Lighthouse\n\nAnkr (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nAnkr Protocol - open access to Public RPC API endpoints for 8+ chains\nLoad balancing and node health monitoring for a fast and reliable gateway to the nearest available node\nPremium tier enabling WSS endpoint and uncapped rate limit\nOne-click full node and validator node deployment for 40+ chains\nScale as you go\nAnalytics tools\nDashboard\nRPC, HTTPS and WSS endpoints\nDirect support\n\nBlast (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nRPC and WSS support\nMulti-region node hosting\nDecentralized infrastructure\nPublic API\nDedicated Free Plan\nMultichain support (17+ blockchains)\nArchive Nodes\n24/7 Discord Support\n24/7 Monitoring and alerts\nAn overall SLA of 99.9%\nPay in crypto\n\nBlockDaemon (opens in a new tab)\n\nDocs (opens in a new tab)\nBenefits\n\nDashboard\nPer node basis\nAnalytics\n\nBlockPI (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nRobust & distributed node structure\nUp to 40 HTTPS and WSS endpoints\nFree signup package and monthly package\nTrace method + Archive data support\nPackages up to 90 days validity\nCustom plan and pay as you go payment\nPay in crypto\nDirect support & Technical support\n\nChainbase (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nHighly available, fast, and scalable RPC service\nMulti-chain support\nFree tariffs\nUser-friendly dashboard\nProvides blockchain data services beyond RPC\n\nChainstack (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree shared nodes\nShared archive nodes\nGraphQL support\nRPC and WSS endpoints\nDedicated full and archive nodes\nFast sync time for dedicated deployments\nBring your cloud\nPay-per-hour pricing\nDirect 24/7 support\n\ndRPC (opens in a new tab)\n\nDocs (opens in a new tab)\nNodeCloud: Plug-n-play RPC infra starting at $10 (USD)—full speed, no limits\nNodeCloud features:\n\nAPI support for 185 networks\nDistributed pool of 40+ providers\nGlobal coverage with nine (9) geo-clusters\nAI-powered load balancing system\nPay-as-you-go flat pricing—no hikes, no expiry, no lock-ins\nUnlimited keys, granular key tweaks, team roles, front-end protection\nMethods flat rate at 20 compute units (CUs) per method\nPublic endpoint chainlist (opens in a new tab)\nPricing calculator (opens in a new tab)\n\nNodeCore: open-source stack for organizations wanting full control\n\nGetBlock (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nAccess to 40+ blockchain nodes\n40K free daily requests\nUnlimited number of API keys\nHigh connection speed at 1GB/sec\nTrace+Archive\nAdvanced analytics\nAutomated updates\nTechnical support\n\nInfStones (opens in a new tab)\n\nFeatures\n\nFree tier option\nScale as you go\nAnalytics\nDashboard\nUnique API endpoints\nDedicated full nodes\nFast sync time for dedicated deployments\nDirect 24/7 support\nAccess to 50+ blockchain nodes\n\nInfura (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree tier option\nScale as you go\nPaid archival data\nDirect Support\nDashboard\n\nKaleido (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree startier tier\nOne-click Ethereum node deployment\nCustomizable clients and algorithms (Geth, Quorum & Besu || PoA, IBFT & Raft)\n500+ administrative and service APIs\nRESTful interface for Ethereum transaction submission (Apache Kafka backed)\nOutbound streams for event delivery (Apache Kafka backed)\nDeep collection of \"offchain\" and ancillary services (e.g., bilateral encrypted messaging transport)\nStraightforward network onboarding with governance and role-based access control\nSophisticated user management for both administrators and end users\nHighly scalable, resilient, enterprise-grade infrastructure\nCloud HSM private key management\nEthereum Mainnet Tethering\nISO 27k and SOC 2, Type 2 certifications\nDynamic runtime configuration (e.g., adding cloud integrations, altering node ingresses, etc.)\nSupport for multi-cloud, multi-region and hybrid deployment orchestrations\nSimple hourly SaaS-based pricing\nSLAs and 24x7 support\n\nLava Network (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree Testnet Use\nDecentralized Redundancy for High Uptime\nOpen-source\nFully Decentralized SDK\nEthers.js Integration\nIntuitive Project Management Interface\nConsensus-Based Data Integrity\nMulti-chain Support\n\nMoralis (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree shared nodes\nFree shared archive nodes\nPrivacy focused (no logs policy)\nCross chain support\nScale as you go\nDashboard\nUnique Ethereum SDK\nUnique API endpoints\nDirect, technical support\n\nNodeReal MegaNode (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nReliable, fast and scalable RPC API services\nEnhanced API for web3 developers\nMulti-chain support\nGet started for free\n\nNodeFlare (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\n23 EVM chains including Ethereum, Base, Arbitrum One & Nova, Optimism, Linea, and Unichain\n5 regions (Europe, UK, Asia, US-East, US-West) with automatic failover to nearest healthy node\nFree public endpoint (no API key) + free plan with 2M compute units/month\nCompute Unit billing — pay only for what you use, heavier calls cost more\nNo throttling on paid plans\n\nNOWNodes (opens in a new tab)\n\nFeatures\n\nAccess to 50+ blockchain nodes\nFree API Key\nBlock Explorers\nAPI Response Time ⩽ 1 sec\n24/7 Support Team\nPersonal Account Manager\nShared, archive, backup and dedicated nodes\n\nPocket Network (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nDecentralized RPC Protocol and Marketplace\n1M Requests Per Day Free Tier (per endpoint, max 2)\nPre-Stake+ Program (if you need more than 1M requests per day)\n15+ Blockchains Supported\n6400+ Nodes earning POKT for serving applications\nArchival Node, Archival Node w/ Tracing, & Testnet Node Support\nEthereum Mainnet Node Client Diversity\nNo Single Point of Failure\nZero Downtime\nCost-Effective Near-Zero Tokenomics (stake POKT once for network bandwidth)\nNo monthly sunk costs, turn your infrastructure into an asset\nLoad-Balancing built into the Protocol\nInfinitely scale the number of requests per day and nodes per hour as you go\nThe most private, censorship-resistant option\nHands-on developer support\nPocket Portal (opens in a new tab) dashboard and analytics\n\nQuickNode (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\n24/7 technical support & dev Discord community\nGeo-balanced, multi cloud/metal, low-latency network\nMultichain support (Optimism, Arbitrum, Polygon + 11 others)\nMiddle-layers for speed & stability (call routing, cache, indexing)\nSmart-Contract monitoring via Webhooks\nIntuitive dashboard, analytics suite, RPC composer\nAdvanced security features (JWT, masking, whitelisting)\nNFT data and analytics API\nSOC2 Certified (opens in a new tab)\nSuitable for Developers to Enterprises\n\nRivet (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree tier option\nScale as you go\n\nSenseiNode (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nDedicated and Share nodes\nDashboard\nHosting off AWS on multiple hosting providers across different locations in Latin America\nPrysm and Lighthouse clients\n\nSettleMint (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree trial\nScale as you go\nGraphQL support\nRPC and WSS endpoints\nDedicated full nodes\nBring your cloud\nAnalytics tools\nDashboard\nPay-per-hour pricing\nDirect support\n\nTenderly (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFree tier including 25 million Tenderly Units per month\nFree access to historical data\nUp to 8x faster read-heavy workloads\n100% consistent read access\nJSON-RPC endpoints\nUI-based RPC request builder and request preview\nTightly integrated with Tenderly’s development, debugging, and testing tools\nTransaction simulations\nUsage analytics and filtering\nEasy access key management\nDedicated engineering support via chat, email, and Discord\n\nTokenview (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\n24/7 technical support & Dev Telegram community\nMultichain support (Bitcoin, Ethereum, Tron, BNB Smart Chain, Ethereum Classic)\nBoth RPC and WSS endpoints are open to use\nUnlimited access to archive data API\nDashboard with Request Explorer and Mempool Watcher\nNFT data API and Webhook notify\nPay in Crypto\nExternal support for extra behavior requirements\n\nWatchdata (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nData reliability\nUninterrupted connection with no downtime\nProcess automation\nFree tariffs\nHigh limits that suit any user\nSupport for various nodes\nResource scaling\nHigh processing speeds\n\nZMOK (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nFront-running as a service\nGlobal transactions mempool with search/filtering methods\nUnlimited TX fee and infinite Gas for sending transactions\nFastest getting of the new block and reading of the blockchain\nThe best price per API call guarantee\n\nZeeve (opens in a new tab)\n\nDocs (opens in a new tab)\nFeatures\n\nEnterprise-grade no-code automation platform providing deployment, monitoring and management of Blockchain nodes and networks\n30+ Supported Protocols & Integrations, and adding more\nValue added web3 infrastructure services like decentralized storage, decentralized identity and Blockchain Ledger data APIs for real-world use cases\n24/7 support and proactive monitoring ensure the health of nodes all the time.\nRPC endpoints offer authenticated access to APIs, hassle-free management with intuitive dashboard and analytics.\nProvides both managed cloud and bring your own cloud options to choose from and supports all major cloud providers like AWS, Azure, Google Cloud, Digital Ocean and on-premise.\nWe use intelligent routing to hit the node closest to your user every time\n\nFurther reading\n\nList of Ethereum node services (opens in a new tab)\n\nRelated topics\n\nNodes and clients\n\nRelated tutorials\n\nGetting started with Ethereum development using Alchemy\nGuide to sending transactions using web3 and Alchemy","tokens":3705,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264580508,"hash":"7e29febdbaee928cb7a90bb41fac6ad5447b623e"}
{"url":"https://governance.aave.com/t/open-source-typescript-module-for-aave-v3-health-factor-evaluation/25528/1","domain":"governance.aave.com","title":"Open-source TypeScript module for Aave V3 Health Factor evaluation - Development - Aave","text":"Open-source TypeScript module for Aave V3 Health Factor evaluation \n\n Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 25\n\n 1 / 1\n\n Aug 25\n\n Aug 25\n\n post by aleksandern on Aug 25\n\n aleksandern\n\n Hi everyone,\nI’ve been working on define-kit, an open-source TypeScript toolkit for deterministic DeFi position evaluation.\nThe first position module is for Aave V3 Health Factor.\nThe main idea is to separate protocol reads from risk evaluation:\nfetch → snapshot → evaluate\nThe adapter reads the position directly from Aave V3, creates a snapshot tied to blockNumber and blockHash, and then evaluates that snapshot without additional RPC calls.\nThis makes the evaluation deterministic and allows the same snapshot to be stored, compared over time, or evaluated again later.\nThe current result classifies the position as:\nhealthy / warning / danger / liquidatable\nGitHub:\n\nnpm:\nhttps://www.npmjs.com/package/@define-kit/position-modules\nI’d appreciate feedback from people familiar with Aave integrations:\n\nDoes the fetch → snapshot → evaluate approach make sense for monitoring Aave positions?\nAre there Aave-specific edge cases or position states that you think the module should handle differently?\n\nThe module is MIT licensed and intended to stay reusable and independent of any particular application.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Aave DeFi Watcher – Browser Extension for Monitoring Aave Positions\n\n Other\n\n 1\n\n 146\n\n Jul 7\n\n Introducing zyk-positions — understand what your Aave V3 position is actually doing\n\n Other\n\n 0\n\n 93\n\n Jun 10\n\n Projection Finance — Free & open-source simulator to project your Aave position over time\n\n Risk\n\n 0\n\n 126\n\n Jun 9\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Low Adoption Asset Deprecation on Aave V3\n\n Governance\n\n 9\n\n 2.1k\n\n Sep 16","tokens":480,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264582287,"hash":"2bc473c59c05e4d8c599aba46c9ead9cea694ed2"}
{"url":"https://docs.soliditylang.org/en/develop/050-breaking-changes.html","domain":"docs.soliditylang.org","title":"Solidity v0.5.0 Breaking Changes — Solidity 0.8.38-develop documentation","text":"Solidity v0.5.0 Breaking Changes\n\n Edit on GitHub\n\nSolidity v0.5.0 Breaking Changes\nThis section highlights the main breaking changes introduced in Solidity\nversion 0.5.0, along with the reasoning behind the changes and how to update\naffected code.\nFor the full list check\nthe release changelog.\n\nNote\nContracts compiled with Solidity v0.5.0 can still interface with contracts\nand even libraries compiled with older versions without recompiling or\nredeploying them. Changing the interfaces to include data locations and\nvisibility and mutability specifiers suffices. See the\nInteroperability With Older Contracts section below.\n\nSemantic Only Changes\nThis section lists the changes that are semantic-only, thus potentially\nhiding new and different behavior in existing code.\n\nSigned right shift now uses proper arithmetic shift, i.e. rounding towards\nnegative infinity, instead of rounding towards zero. Signed and unsigned\nshift will have dedicated opcodes in Constantinople, and are emulated by\nSolidity for the moment.\nThe continue statement in a do...while loop now jumps to the\ncondition, which is the common behavior in such cases. It used to jump to the\nloop body. Thus, if the condition is false, the loop terminates.\nThe functions .call(), .delegatecall() and .staticcall() do not\npad anymore when given a single bytes parameter.\nPure and view functions are now called using the opcode STATICCALL\ninstead of CALL if the EVM version is Byzantium or later. This\ndisallows state changes on the EVM level.\nThe ABI encoder now properly pads byte arrays and strings from calldata\n(msg.data and external function parameters) when used in external\nfunction calls and in abi.encode. For unpadded encoding, use\nabi.encodePacked.\nThe ABI decoder reverts in the beginning of functions and in\nabi.decode() if passed calldata is too short or points out of bounds.\nNote that dirty higher order bits are still simply ignored.\nForward all available gas with external function calls starting from\nTangerine Whistle.\n\nSemantic and Syntactic Changes\nThis section highlights changes that affect syntax and semantics.\n\nThe functions .call(), .delegatecall(), staticcall(),\nkeccak256(), sha256() and ripemd160() now accept only a single\nbytes argument. Moreover, the argument is not padded. This was changed to\nmake more explicit and clear how the arguments are concatenated. Change every\n.call() (and family) to a .call(\"\") and every .call(signature, a,\nb, c) to use .call(abi.encodeWithSignature(signature, a, b, c)) (the\nlast one only works for value types). Change every keccak256(a, b, c) to\nkeccak256(abi.encodePacked(a, b, c)). Even though it is not a breaking\nchange, it is suggested that developers change\nx.call(bytes4(keccak256(\"f(uint256)\")), a, b) to\nx.call(abi.encodeWithSignature(\"f(uint256)\", a, b)).\nFunctions .call(), .delegatecall() and .staticcall() now return\n(bool, bytes memory) to provide access to the return data. Change\nbool success = otherContract.call(\"f\") to (bool success, bytes memory\ndata) = otherContract.call(\"f\").\nSolidity now implements C99-style scoping rules for function local\nvariables, that is, variables can only be used after they have been\ndeclared and only in the same or nested scopes. Variables declared in the\ninitialization block of a for loop are valid at any point inside the\nloop.\n\nExplicitness Requirements\nThis section lists changes where the code now needs to be more explicit.\nFor most of the topics the compiler will provide suggestions.\n\nExplicit function visibility is now mandatory. Add public to every\nfunction and constructor, and external to every fallback or interface\nfunction that does not specify its visibility already.\nExplicit data location for all variables of struct, array or mapping types is\nnow mandatory. This is also applied to function parameters and return\nvariables. For example, change uint[] x = z to uint[] storage x =\nz, and function f(uint[][] x) to function f(uint[][] memory x)\nwhere memory is the data location and might be replaced by storage or\ncalldata accordingly. Note that external functions require\nparameters with a data location of calldata.\nContract types do not include address members anymore in\norder to separate the namespaces. Therefore, it is now necessary to\nexplicitly convert values of contract type to addresses before using an\naddress member. Example: if c is a contract, change\nc.transfer(...) to address(c).transfer(...),\nand c.balance to address(c).balance.\nExplicit conversions between unrelated contract types are now disallowed. You can only\nconvert from a contract type to one of its base or ancestor types. If you are sure that\na contract is compatible with the contract type you want to convert to, although it does not\ninherit from it, you can work around this by converting to address first.\nExample: if A and B are contract types, B does not inherit from A and\nb is a contract of type B, you can still convert b to type A using A(address(b)).\nNote that you still need to watch out for matching payable fallback functions, as explained below.\nThe address type was split into address and address payable,\nwhere only address payable provides the transfer function. An\naddress payable can be directly converted to an address, but the\nother way around is not allowed. Converting address to address\npayable is possible via conversion through uint160. If c is a\ncontract, address(c) results in address payable only if c has a\npayable fallback function. If you use the withdraw pattern,\nyou most likely do not have to change your code because transfer\nis only used on msg.sender instead of stored addresses and msg.sender\nis an address payable.\nConversions between bytesX and uintY of different size are now\ndisallowed due to bytesX padding on the right and uintY padding on\nthe left which may cause unexpected conversion results. The size must now be\nadjusted within the type before the conversion. For example, you can convert\na bytes4 (4 bytes) to a uint64 (8 bytes) by first converting the\nbytes4 variable to bytes8 and then to uint64. You get the\nopposite padding when converting through uint32. Before v0.5.0 any\nconversion between bytesX and uintY would go through uint8X. For\nexample uint8(bytes3(0x291807)) would be converted to uint8(uint24(bytes3(0x291807)))\n(the result is 0x07).\nUsing msg.value in non-payable functions (or introducing it via a\nmodifier) is disallowed as a security feature. Turn the function into\npayable or create a new internal function for the program logic that\nuses msg.value.\nFor clarity reasons, the command-line interface now requires - if the\nstandard input is used as source.\n\nDeprecated Elements\nThis section lists changes that deprecate prior features or syntax. Note that\nmany of these changes were already enabled in the experimental mode\nv0.5.0.\n\nCommand-line and JSON Interfaces\n\nThe command-line option --formal (used to generate Why3 output for\nfurther formal verification) was deprecated and is now removed. A new\nformal verification module, the SMTChecker, is enabled via pragma\nexperimental SMTChecker;.\nThe command-line option --julia was renamed to --yul due to the\nrenaming of the intermediate language Julia to Yul.\nThe --clone-bin and --combined-json clone-bin command-line options\nwere removed.\nRemappings with empty prefix are disallowed.\nThe JSON AST fields constant and payable were removed. The\ninformation is now present in the stateMutability field.\nThe JSON AST field isConstructor of the FunctionDefinition\nnode was replaced by a field called kind which can have the\nvalue \"constructor\", \"fallback\" or \"function\".\nIn unlinked binary hex files, library address placeholders are now\nthe first 36 hex characters of the keccak256 hash of the fully qualified\nlibrary name, surrounded by $...$. Previously,\njust the fully qualified library name was used.\nThis reduces the chances of collisions, especially when long paths are used.\nBinary files now also contain a list of mappings from these placeholders\nto the fully qualified names.\n\nConstructors\n\nConstructors must now be defined using the constructor keyword.\nCalling base constructors without parentheses is now disallowed.\nSpecifying base constructor arguments multiple times in the same inheritance\nhierarchy is now disallowed.\nCalling a constructor with arguments but with wrong argument count is now\ndisallowed. If you only want to specify an inheritance relation without\ngiving arguments, do not provide parentheses at all.\n\nFunctions\n\nFunction callcode is now disallowed (in favor of delegatecall). It\nis still possible to use it via inline assembly.\nsuicide is now disallowed (in favor of selfdestruct).\nsha3 is now disallowed (in favor of keccak256).\nthrow is now disallowed (in favor of revert, require and\nassert).\n\nConversions\n\nExplicit and implicit conversions from decimal literals to bytesXX types\nis now disallowed.\nExplicit and implicit conversions from hex literals to bytesXX types\nof different size is now disallowed.\n\nLiterals and Suffixes\n\nThe unit denomination years is now disallowed due to complications and\nconfusions about leap years.\nTrailing dots that are not followed by a number are now disallowed.\nCombining hex numbers with unit denominations (e.g. 0x1e wei) is now\ndisallowed.\nThe prefix 0X for hex numbers is disallowed, only 0x is possible.\n\nVariables\n\nDeclaring empty structs is now disallowed for clarity.\nThe var keyword is now disallowed to favor explicitness.\nAssignments between tuples with different number of components is now\ndisallowed.\nValues for constants that are not compile-time constants are disallowed.\nMulti-variable declarations with mismatching number of values are now\ndisallowed.\nUninitialized storage variables are now disallowed.\nEmpty tuple components are now disallowed.\nDetecting cyclic dependencies in variables and structs is limited in\nrecursion to 256.\nFixed-size arrays with a length of zero are now disallowed.\n\nSyntax\n\nUsing constant as function state mutability modifier is now disallowed.\nBoolean expressions cannot use arithmetic operations.\nThe unary + operator is now disallowed.\nLiterals cannot anymore be used with abi.encodePacked without prior\nconversion to an explicit type.\nEmpty return statements for functions with one or more return values are now\ndisallowed.\nThe “loose assembly” syntax is now disallowed entirely, that is, jump labels,\njumps and non-functional instructions cannot be used anymore. Use the new\nwhile, switch and if constructs instead.\nFunctions without implementation cannot use modifiers anymore.\nFunction types with named return values are now disallowed.\nSingle statement variable declarations inside if/while/for bodies that are\nnot blocks are now disallowed.\nNew keywords: calldata and constructor.\nNew reserved keywords: alias, apply, auto, copyof,\ndefine, immutable, implements, macro, mutable,\noverride, partial, promise, reference, sealed,\nsizeof, supports, typedef and unchecked.\n\nInteroperability With Older Contracts\nIt is still possible to interface with contracts written for Solidity versions prior to\nv0.5.0 (or the other way around) by defining interfaces for them.\nConsider you have the following pre-0.5.0 contract already deployed:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.4.25;\n// This will report a warning until version 0.4.25 of the compiler\n// This will not compile after 0.5.0\ncontract OldContract {\n function someOldFunction(uint8 a) {\n //...\n }\n function anotherOldFunction() constant returns (bool) {\n //...\n }\n // ...\n}\n\nThis will no longer compile with Solidity v0.5.0. However, you can define a compatible interface for it:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\ninterface OldContract {\n function someOldFunction(uint8 a) external;\n function anotherOldFunction() external returns (bool);\n}\n\nNote that we did not declare anotherOldFunction to be view, despite it being declared constant in the original\ncontract. This is due to the fact that starting with Solidity v0.5.0 staticcall is used to call view functions.\nPrior to v0.5.0 the constant keyword was not enforced, so calling a function declared constant with staticcall\nmay still revert, since the constant function may still attempt to modify storage. Consequently, when defining an\ninterface for older contracts, you should only use view in place of constant in case you are absolutely sure that\nthe function will work with staticcall.\nGiven the interface defined above, you can now easily use the already deployed pre-0.5.0 contract:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n\ninterface OldContract {\n function someOldFunction(uint8 a) external;\n function anotherOldFunction() external returns (bool);\n}\n\ncontract NewContract {\n function doSomething(OldContract a) public returns (bool) {\n a.someOldFunction(0x42);\n return a.anotherOldFunction();\n }\n}\n\nSimilarly, pre-0.5.0 libraries can be used by defining the functions of the library without implementation and\nsupplying the address of the pre-0.5.0 library during linking (see Using the Commandline Compiler for how to use the\ncommandline compiler for linking):\nopen in Remix\n// This will not compile after 0.6.0\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.5.0;\n\nlibrary OldLibrary {\n function someFunction(uint8 a) public returns(bool);\n}\n\ncontract NewContract {\n function f(uint8 a) public returns (bool) {\n return OldLibrary.someFunction(a);\n }\n}\n\nExample\nThe following example shows a contract and its updated version for Solidity\nv0.5.0 with some of the changes listed in this section.\nOld version:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.4.25;\n// This will not compile after 0.5.0\n\ncontract OtherContract {\n uint x;\n function f(uint y) external {\n x = y;\n }\n function() payable external {}\n}\n\ncontract Old {\n OtherContract other;\n uint myNumber;\n\n // Function mutability not provided, not an error.\n function someInteger() internal returns (uint) { return 2; }\n\n // Function visibility not provided, not an error.\n // Function mutability not provided, not an error.\n function f(uint x) returns (bytes) {\n // Var is fine in this version.\n var z = someInteger();\n x += z;\n // Throw is fine in this version.\n if (x > 100)\n throw;\n bytes memory b = new bytes(x);\n y = -3 >> 1;\n // y == -1 (wrong, should be -2)\n do {\n x += 1;\n if (x > 10) continue;\n // 'Continue' causes an infinite loop.\n } while (x < 11);\n // Call returns only a Bool.\n bool success = address(other).call(\"f\");\n if (!success)\n revert();\n else {\n // Local variables could be declared after their use.\n int y;\n }\n return b;\n }\n\n // No need for an explicit data location for 'arr'\n function g(uint[] arr, bytes8 x, OtherContract otherContract) public {\n otherContract.transfer(1 ether);\n\n // Since uint32 (4 bytes) is smaller than bytes8 (8 bytes),\n // the first 4 bytes of x will be lost. This might lead to\n // unexpected behavior since bytesX are right padded.\n uint32 y = uint32(x);\n myNumber += y + msg.value;\n }\n}\n\nNew version:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.5.0;\n// This will not compile after 0.6.0\n\ncontract OtherContract {\n uint x;\n function f(uint y) external {\n x = y;\n }\n function() payable external {}\n}\n\ncontract New {\n OtherContract other;\n uint myNumber;\n\n // Function mutability must be specified.\n function someInteger() internal pure returns (uint) { return 2; }\n\n // Function visibility must be specified.\n // Function mutability must be specified.\n function f(uint x) public returns (bytes memory) {\n // The type must now be explicitly given.\n uint z = someInteger();\n x += z;\n // Throw is now disallowed.\n require(x <= 100);\n int y = -3 >> 1;\n require(y == -2);\n do {\n x += 1;\n if (x > 10) continue;\n // 'Continue' jumps to the condition below.\n } while (x < 11);\n\n // Call returns (bool, bytes).\n // Data location must be specified.\n (bool success, bytes memory data) = address(other).call(\"f\");\n if (!success)\n revert();\n return data;\n }\n\n using AddressMakePayable for address;\n // Data location for 'arr' must be specified\n function g(uint[] memory /* arr */, bytes8 x, OtherContract otherContract, address unknownContract) public payable {\n // 'otherContract.transfer' is not provided.\n // Since the code of 'OtherContract' is known and has the fallback\n // function, address(otherContract) has type 'address payable'.\n address(otherContract).transfer(1 ether);\n\n // 'unknownContract.transfer' is not provided.\n // 'address(unknownContract).transfer' is not provided\n // since 'address(unknownContract)' is not 'address payable'.\n // If the function takes an 'address' which you want to send\n // funds to, you can convert it to 'address payable' via 'uint160'.\n // Note: This is not recommended and the explicit type\n // 'address payable' should be used whenever possible.\n // To increase clarity, we suggest the use of a library for\n // the conversion (provided after the contract in this example).\n address payable addr = unknownContract.makePayable();\n require(addr.send(1 ether));\n\n // Since uint32 (4 bytes) is smaller than bytes8 (8 bytes),\n // the conversion is not allowed.\n // We need to convert to a common size first:\n bytes4 x4 = bytes4(x); // Padding happens on the right\n uint32 y = uint32(x4); // Conversion is consistent\n // 'msg.value' cannot be used in a 'non-payable' function.\n // We need to make the function payable\n myNumber += y + msg.value;\n }\n}\n\n// We can define a library for explicitly converting ``address``\n// to ``address payable`` as a workaround.\nlibrary AddressMakePayable {\n function makePayable(address x) internal pure returns (address payable) {\n return address(uint160(x));\n }\n}","tokens":4419,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264582356,"hash":"0ca2c497d6581696d0255c2458b9d6971ae0b89a"}
{"url":"https://ethereum.org/roadmap/merge/","domain":"ethereum.org","title":"The Merge | ethereum.org","text":"Edit page (opens in a new tab)\nWhat was The Merge?\nThe Merge was the joining of the original execution layer of Ethereum (the Mainnet that has existed since genesis) with its new proof-of-stake consensus layer, the Beacon Chain. It eliminated the need for energy-intensive mining and instead enabled the network to be secured using staked ETH. It was a truly exciting step in realizing the Ethereum vision—more scalability, security, and sustainability.\n\nInitially, the Beacon Chain shipped separately from . Ethereum Mainnet - with all its accounts, balances, smart contracts, and blockchain state - continued to be secured by proof-of-work, even while the Beacon Chain ran in parallel using proof-of-stake. The Merge was when these two systems finally came together, and proof-of-work was permanently replaced by proof-of-stake.\nImagine Ethereum is a spaceship that launched before it was quite ready for an interstellar voyage. With the Beacon Chain, the community built a new engine and a hardened hull. After significant testing, it became time to hot-swap the new engine for the old one mid-flight. This merged the new, more efficient engine into the existing ship enabling it to put in some serious light years and take on the universe.\nMerging with Mainnet\nProof-of-work secured Ethereum Mainnet from genesis until The Merge. This allowed the Ethereum blockchain we're all used to come into existence in July 2015 with all its familiar features—transactions, smart contracts, accounts, etc.\nThroughout Ethereum's history, developers prepared for an eventual transition away from proof-of-work to proof-of-stake. On December 1, 2020, the Beacon Chain was created as a separate blockchain to Mainnet, running in parallel.\nThe Beacon Chain was not originally processing Mainnet transactions. Instead, it was reaching consensus on its own state by agreeing on active validators and their account balances. After extensive testing, it became time for the Beacon Chain to reach consensus on real world data. After The Merge, the Beacon Chain became the consensus engine for all network data, including execution layer transactions and account balances.\nThe Merge represented the official switch to using the Beacon Chain as the engine of block production. Mining is no longer the means of producing valid blocks. Instead, the proof-of-stake validators have adopted this role and are now responsible for processing the validity of all transactions and proposing blocks.\nNo history was lost in The Merge. As Mainnet merged with the Beacon Chain, it also merged the entire transactional history of Ethereum.\nThis transition to proof-of-stake changed the way ether is issued. Learn more about ether issuance before and after The Merge.\nUsers and holders\nThe Merge did not change anything for holders/users.\nThis bears repeating: As a user or holder of ETH or any other digital asset on Ethereum, as well as non-node-operating stakers, you do not need to do anything with your funds or wallet to account for The Merge. ETH is just ETH. There is no such thing as \"old ETH\"/\"new ETH\" or \"ETH1\"/\"ETH2\" and wallets work exactly the same after The Merge as they did before—people telling you otherwise are likely scammers.\nDespite swapping out proof-of-work, the entire history of Ethereum since genesis remained intact and unaltered by the transition to proof-of-stake. Any funds held in your wallet before The Merge are still accessible after The Merge. No action is required to upgrade on your part.\nMore on Ethereum security\nNode operators and dapp developers\nKey action items include:\nRun both a consensus client and an execution client; third-party endpoints to obtain execution data no longer work since The Merge.\nAuthenticate both execution and consensus clients with a shared JWT secret so they can securely communicate.\nSet a fee recipient address to receive your earned transaction fee tips/MEV.\nNot completing the first two items above will result in your node being seen as \"offline\" until both layers are synced and authenticated.Not setting a fee recipient will still allow your validator to behave as usual, but you will miss out on unburnt fee tips and any MEV you would have otherwise earned in blocks your validator proposes.\nUp until The Merge, an execution client (such as Geth, Erigon, Besu or Nethermind) was enough to receive, properly validate, and propagate blocks being gossiped by the network. After The Merge, the validity of transactions contained within an execution payload now also depends on the validity of the \"consensus block\" it is contained within.As a result, a full Ethereum node now requires both an execution client and a consensus client. These two clients work together using a new Engine API. The Engine API requires authentication using a JWT secret, which is provided to both clients allowing secure communication.Key action items include:\nInstall a consensus client in addition to an execution client\nAuthenticate execution and consensus clients with a shared JWT secret so they can securely communicate with one another.\nNot completing the above items will result in your node appearing to be \"offline\" until both layers are synced and authenticated.\nThe Merge came with changes to consensus, which also includes changes related to:block structureslot/block timingopcode changessources of onchain randomnessconcept of safe head and finalized blocksFor more information, check out this blog post by Tim Beiko on How The Merge Impacts Ethereum’s Application Layer.\nThe Merge and energy consumption\nThe Merge marked the end of proof-of-work for Ethereum and started the era of a more sustainable, eco-friendly Ethereum. Ethereum's energy consumption dropped by an estimated 99.95%, making Ethereum a green blockchain. Learn more about Ethereum energy consumption.\nThe Merge and scaling\nThe Merge also set the stage for further scalability upgrades not possible under proof-of-work, bringing Ethereum one step closer to achieving the full scale, security and sustainability that its roadmap is building toward.\nMisconceptions about The Merge\nThere are two types of Ethereum nodes: nodes that can propose blocks and nodes that don't.Nodes that propose blocks are only a small number of the total nodes on Ethereum. This category includes mining nodes under proof-of-work (PoW) and validator nodes under proof-of-stake (PoS). This category requires committing economic resources (such as GPU hash power in proof-of-work or staked ETH in proof-of-stake) in exchange for the ability to occasionally propose the next block and earn protocol rewards.The other nodes on the network (i.e., the majority) are not required to commit any economic resources beyond a consumer-grade computer with 1-2 TB of available storage and an internet connection. These nodes do not propose blocks, but they still serve a critical role in securing the network by holding all block proposers accountable by listening for new blocks and verifying their validity on arrival according to the network consensus rules. If the block is valid, the node continues propagating it through the network. If the block is invalid for whatever reason, the node software will disregard it as invalid and stop its propagation.Running a non-block-producing node is possible for anyone under either consensus mechanism (proof-of-work or proof-of-stake); it is strongly encouraged for all users if they have the means. Running a node is immensely valuable for Ethereum and gives added benefits to any individual running one, such as improved security, privacy and censorship resistance.The ability for anyone to run their own node is absolutely essential to maintaining the decentralization of the Ethereum network.More on running your own node\nGas fees are a product of network demand relative to the capacity of the network. The Merge deprecated the use of proof-of-work, transitioning to proof-of-stake for consensus, but did not significantly change any parameters that directly influence network capacity or throughput.With a rollup-centric roadmap, efforts are being focused on scaling user activity at layer 2, while enabling layer 1 Mainnet as a secure decentralized settlement layer optimized for rollup data storage to help make rollup transactions exponentially cheaper. The transition to proof-of-stake is a critical precursor to realizing this. More on gas and fees.\nA transaction's \"speed\" can be measured in a few ways, including time to be included in a block and time to finalization. Both of these changes slightly, but not in a way that users will notice.Historically, on proof-of-work, the target was to have a new block every ~13.3 seconds. Under proof-of-stake, slots occur precisely every 12 seconds, each of which is an opportunity for a validator to publish a block. Most slots have blocks, but not necessarily all (i.e., a validator is offline). In proof-of-stake, blocks are produced ~10% more frequently than on proof-of-work. This was a fairly insignificant change and is unlikely to be noticed by users.Proof-of-stake introduced the transaction finality concept that did not previously exist. In proof-of-work, the ability to reverse a block gets exponentially more difficult with every passing block mined on top of a transaction, but it never quite reaches zero. Under proof-of-stake, blocks are bundled into epochs (6.4 minute spans of time containing 32 chances for blocks) which validators vote on. When an epoch ends, validators vote on whether to consider the epoch 'justified'. If validators agree to justify the epoch, it gets finalized in the next epoch. Undoing finalized transactions is economically inviable as it would require obtaining and burning over one-third of the total staked ETH.\nInitially after The Merge, stakers could only access fee tips and MEV that were earned as a result of block proposals. These rewards are credited to a non-staking account controlled by the validator (known as the fee recipient), and are available immediately. These rewards are separate from protocol rewards for performing validator duties.Since the Shanghai/Capella network upgrade, stakers can now designate a withdrawal address to start receiving automatic payouts of any excess staking balance (ETH over 32 from protocol rewards). This upgrade also enabled the ability for a validator to unlock and reclaim its entire balance upon exiting from the network.More on staking withdrawals\nSince the Shanghai/Capella upgrade enabled withdrawals, validators are incentivized to withdraw their staking balance above 32 ETH, as these funds do not add to yield and are otherwise locked. Depending on the APR (determined by total ETH staked), they may be incentivized to exit their validator(s) to reclaim their entire balance or potentially stake even more using their rewards to earn more yield.An important caveat here, full validator exits are rate limited by the protocol, and only so many validators may exit per epoch (every 6.4 minutes). This limit fluctuates depending on the number of active validators, but comes out to approximately 0.33% of total ETH staked can be exited from the network in a single day.This prevents a mass exodus of staked funds. Furthermore, it prevents a potential attacker with access to a large portion of the total ETH staked from committing a slashable offense and exiting/withdrawing all of the offending validator balances in the same epoch before the protocol can enforce the slashing penalty.The APR is also intentionally dynamic, allowing a market of stakers to balance how much they're willing to be paid to help secure the network. If the rate is too low, then validators will exit at a rate limited by the protocol. Gradually this will raise the APR for everyone who remains, attracting new or returning stakers yet again.\nWhat happened to 'Eth2'?\nThe term 'Eth2' has been deprecated. After merging 'Eth1' and 'Eth2' into a single chain, there is no longer any need to\ndistinguish between two Ethereum networks; there is just Ethereum.\nTo limit confusion, the community has updated these terms:\n\n'Eth1' is now the 'execution layer', which handles transactions and execution.\n'Eth2' is now the 'consensus layer', which handles proof-of-stake consensus.\n\nThese terminology updates only change naming conventions; this does not alter Ethereum's goals or roadmap.\nLearn more about the 'Eth2' renaming (opens in a new tab)\nRelationship between upgrades\nThe Ethereum upgrades are all somewhat interrelated. So let’s recap how The Merge relates to the other upgrades.\nThe Merge and the Beacon Chain\nThe Merge represents the formal adoption of the Beacon Chain as the new consensus layer to the original Mainnet execution layer. Since The Merge, validators are assigned to secure Ethereum Mainnet, and mining on proof-of-work is no longer a valid means of block production.\nBlocks are instead proposed by validating nodes that have staked ETH in return for the right to participate in consensus. These upgrades set the stage for future scalability upgrades, including sharding.\nThe Beacon Chain\nThe Merge and the Shanghai upgrade\nIn order to simplify and maximize focus on a successful transition to proof-of-stake, The Merge upgrade did not include certain anticipated features such as the ability to withdraw staked ETH. This functionality was enabled separately with the Shanghai/Capella upgrade.\nFor those curious, learn more about What Happens After The Merge (opens in a new tab), presented by Vitalik at the April 2021 ETHGlobal event.\nThe Merge and sharding\nOriginally, the plan was to work on sharding before The Merge to address scalability. However, with the boom of layer 2 scaling solutions, the priority shifted to swapping proof-of-work to proof-of-stake first.\nPlans for sharding are rapidly evolving, but given the rise and success of layer 2 technologies to scale transaction execution, sharding plans have shifted to finding the most optimal way to distribute the burden of storing compressed calldata from rollup contracts, allowing for exponential growth in network capacity. This would not be possible without first transitioning to proof-of-stake.\nSharding\nFurther reading\nEthmerge (opens in a new tab)EthmergeThe Merge is Coming (opens in a new tab)AlchemyThe State of The Merge: An Update on Ethereum’s Merge to Proof of Stake in 2022 (opens in a new tab)ConsensysAnnouncing the Ropsten Merge Testnet (opens in a new tab)Ethereum FoundationExecution layer specs (opens in a new tab)Ethereum FoundationConsensus layer specs (opens in a new tab)Ethereum FoundationEngine API specs (opens in a new tab)Ethereum FoundationThe Hitchhikers Guide To Ethereum (opens in a new tab)Delphi Digital\nTest your Ethereum knowledgeThe MergeQuestion number 1:The Merge meant users had to exchange their ETH for ETH2:","tokens":3696,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264590811,"hash":"cb4811d96b0439cab4414269663e1669c67a014f"}
{"url":"https://docs.soliditylang.org/en/develop/070-breaking-changes.html","domain":"docs.soliditylang.org","title":"Solidity v0.7.0 Breaking Changes — Solidity 0.8.38-develop documentation","text":"Solidity v0.7.0 Breaking Changes\n\n Edit on GitHub\n\nSolidity v0.7.0 Breaking Changes\nThis section highlights the main breaking changes introduced in Solidity\nversion 0.7.0, along with the reasoning behind the changes and how to update\naffected code.\nFor the full list check\nthe release changelog.\n\nSilent Changes of the Semantics\n\nExponentiation and shifts of literals by non-literals (e.g. 1 << x or 2 ** x)\nwill always use either the type uint256 (for non-negative literals) or\nint256 (for negative literals) to perform the operation.\nPreviously, the operation was performed in the type of the shift amount / the\nexponent which can be misleading.\n\nChanges to the Syntax\n\nIn external function and contract creation calls, Ether and gas is now specified using a new syntax:\nx.f{gas: 10000, value: 2 ether}(arg1, arg2).\nThe old syntax – x.f.gas(10000).value(2 ether)(arg1, arg2) – will cause an error.\nThe global variable now is deprecated, block.timestamp should be used instead.\nThe single identifier now is too generic for a global variable and could give the impression\nthat it changes during transaction processing, whereas block.timestamp correctly\nreflects the fact that it is just a property of the block.\nNatSpec comments on variables are only allowed for public state variables and not\nfor local or internal variables.\nThe token gwei is a keyword now (used to specify, e.g. 2 gwei as a number)\nand cannot be used as an identifier.\nString literals now can only contain printable ASCII characters and this also includes a variety of\nescape sequences, such as hexadecimal (\\xff) and unicode escapes (\\u20ac).\nUnicode string literals are supported now to accommodate valid UTF-8 sequences. They are identified\nwith the unicode prefix: unicode\"Hello 😃\".\nState Mutability: The state mutability of functions can now be restricted during inheritance:\nFunctions with default state mutability can be overridden by pure and view functions\nwhile view functions can be overridden by pure functions.\nAt the same time, public state variables are considered view and even pure\nif they are constants.\n\nInline Assembly\n\nDisallow . in user-defined function and variable names in inline assembly.\nIt is still valid if you use Solidity in Yul-only mode.\nSlot and offset of storage pointer variable x are accessed via x.slot\nand x.offset instead of x_slot and x_offset.\n\nRemoval of Unused or Unsafe Features\n\nMappings outside Storage\n\nIf a struct or array contains a mapping, it can only be used in storage.\nPreviously, mapping members were silently skipped in memory, which\nis confusing and error-prone.\nAssignments to structs or arrays in storage does not work if they contain\nmappings.\nPreviously, mappings were silently skipped during the copy operation, which\nis misleading and error-prone.\n\nFunctions and Events\n\nVisibility (public / internal) is not needed for constructors anymore:\nTo prevent a contract from being created, it can be marked abstract.\nThis makes the visibility concept for constructors obsolete.\nType Checker: Disallow virtual for library functions:\nSince libraries cannot be inherited from, library functions should not be virtual.\nMultiple events with the same name and parameter types in the same\ninheritance hierarchy are disallowed.\nusing A for B only affects the contract it is mentioned in.\nPreviously, the effect was inherited. Now, you have to repeat the using\nstatement in all derived contracts that make use of the feature.\n\nExpressions\n\nShifts by signed types are disallowed.\nPreviously, shifts by negative amounts were allowed, but reverted at runtime.\nThe finney and szabo denominations are removed.\nThey are rarely used and do not make the actual amount readily visible. Instead, explicit\nvalues like 1e20 or the very common gwei can be used.\n\nDeclarations\n\nThe keyword var cannot be used anymore.\nPreviously, this keyword would parse but result in a type error and\na suggestion about which type to use. Now, it results in a parser error.\n\nInterface Changes\n\nJSON AST: Mark hex string literals with kind: \"hexString\".\nJSON AST: Members with value null are removed from JSON output.\nNatSpec: Constructors and functions have consistent userdoc output.\n\nHow to update your code\nThis section gives detailed instructions on how to update prior code for every breaking change.\n\nChange x.f.value(...)() to x.f{value: ...}(). Similarly (new C).value(...)() to\nnew C{value: ...}() and x.f.gas(...).value(...)() to x.f{gas: ..., value: ...}().\nChange now to block.timestamp.\nChange types of right operand in shift operators to unsigned types. For example change x >> (256 - y) to\nx >> uint(256 - y).\nRepeat the using A for B statements in all derived contracts if needed.\nRemove the public keyword from every constructor.\nRemove the internal keyword from every constructor and add abstract to the contract (if not already present).\nChange _slot and _offset suffixes in inline assembly to .slot and .offset, respectively.","tokens":1237,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264592254,"hash":"525d5d5e4c16fdab87f93c17ef7f91757b24b3fd"}
{"url":"https://docs.soliditylang.org/en/develop/style-guide.html","domain":"docs.soliditylang.org","title":"Style Guide — Solidity 0.8.38-develop documentation","text":"Style Guide\n\n Edit on GitHub\n\nStyle Guide\n\nIntroduction\nThis guide is intended to provide coding conventions for writing Solidity code.\nThis guide should be thought of as an evolving document that will change over\ntime as useful conventions are found and old conventions are rendered obsolete.\nMany projects will implement their own style guides. In the event of\nconflicts, project specific style guides take precedence.\nThe structure and many of the recommendations within this style guide were\ntaken from Python’s\npep8 style guide.\nThe goal of this guide is not to be the right way or the best way to write\nSolidity code. The goal of this guide is consistency. A quote from Python’s\npep8\ncaptures this concept well.\n\nNote\nA style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.\nBut most importantly: know when to be inconsistent – sometimes the style guide just doesn’t apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And do not hesitate to ask!\n\nCode Layout\n\nIndentation\nUse 4 spaces per indentation level.\n\nTabs or Spaces\nSpaces are the preferred indentation method.\nMixing tabs and spaces should be avoided.\n\nBlank Lines\nSurround top level declarations in Solidity source with two blank lines.\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract A {\n // ...\n}\n\ncontract B {\n // ...\n}\n\ncontract C {\n // ...\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract A {\n // ...\n}\ncontract B {\n // ...\n}\n\ncontract C {\n // ...\n}\n\nWithin a contract surround function declarations with a single blank line.\nBlank lines may be omitted between groups of related one-liners (such as stub functions for an abstract contract)\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.0 <0.9.0;\n\nabstract contract A {\n function spam() public virtual pure;\n function ham() public virtual pure;\n}\n\ncontract B is A {\n function spam() public pure override {\n // ...\n }\n\n function ham() public pure override {\n // ...\n }\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.6.0 <0.9.0;\n\nabstract contract A {\n function spam() virtual pure public;\n function ham() public virtual pure;\n}\n\ncontract B is A {\n function spam() public pure override {\n // ...\n }\n function ham() public pure override {\n // ...\n }\n}\n\nMaximum Line Length\nMaximum suggested line length is 120 characters.\nWrapped lines should conform to the following guidelines.\n\nThe first argument should not be attached to the opening parenthesis.\nOne, and only one, indent should be used.\nEach argument should fall on its own line.\nThe terminating element, );, should be placed on the final line by itself.\n\nFunction Calls\nYes:\nopen in Remix\nthisFunctionCallIsReallyLong(\n longArgument1,\n longArgument2,\n longArgument3\n);\n\nNo:\nopen in Remix\nthisFunctionCallIsReallyLong(longArgument1,\n longArgument2,\n longArgument3\n);\n\nthisFunctionCallIsReallyLong(longArgument1,\n longArgument2,\n longArgument3\n);\n\nthisFunctionCallIsReallyLong(\n longArgument1, longArgument2,\n longArgument3\n);\n\nthisFunctionCallIsReallyLong(\nlongArgument1,\nlongArgument2,\nlongArgument3\n);\n\nthisFunctionCallIsReallyLong(\n longArgument1,\n longArgument2,\n longArgument3);\n\nAssignment Statements\nYes:\nopen in Remix\nthisIsALongNestedMapping[being][set][toSomeValue] = someFunction(\n argument1,\n argument2,\n argument3,\n argument4\n);\n\nNo:\nopen in Remix\nthisIsALongNestedMapping[being][set][toSomeValue] = someFunction(argument1,\n argument2,\n argument3,\n argument4);\n\nEvent Definitions and Event Emitters\nYes:\nopen in Remix\nevent LongAndLotsOfArgs(\n address sender,\n address recipient,\n uint256 publicKey,\n uint256 amount,\n bytes32[] options\n);\n\nemit LongAndLotsOfArgs(\n sender,\n recipient,\n publicKey,\n amount,\n options\n);\n\nNo:\nopen in Remix\nevent LongAndLotsOfArgs(address sender,\n address recipient,\n uint256 publicKey,\n uint256 amount,\n bytes32[] options);\n\nemit LongAndLotsOfArgs(sender,\n recipient,\n publicKey,\n amount,\n options);\n\nSource File Encoding\nUTF-8 or ASCII encoding is preferred.\n\nImports\nImport statements should always be placed at the top of the file.\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\nimport \"./Owned.sol\";\n\ncontract A {\n // ...\n}\n\ncontract B is Owned {\n // ...\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract A {\n // ...\n}\n\nimport \"./Owned.sol\";\n\ncontract B is Owned {\n // ...\n}\n\nOrder of Functions\nOrdering helps readers identify which functions they can call and to find the constructor and fallback definitions easier.\nFunctions should be grouped according to their visibility and ordered:\n\nconstructor\nreceive function (if exists)\nfallback function (if exists)\nexternal\npublic\ninternal\nprivate\n\nWithin a grouping, place the view and pure functions last.\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\ncontract A {\n constructor() {\n // ...\n }\n\n receive() external payable {\n // ...\n }\n\n fallback() external {\n // ...\n }\n\n // External functions\n // ...\n\n // External functions that are view\n // ...\n\n // External functions that are pure\n // ...\n\n // Public functions\n // ...\n\n // Internal functions\n // ...\n\n // Private functions\n // ...\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\ncontract A {\n\n // External functions\n // ...\n\n fallback() external {\n // ...\n }\n receive() external payable {\n // ...\n }\n\n // Private functions\n // ...\n\n // Public functions\n // ...\n\n constructor() {\n // ...\n }\n\n // Internal functions\n // ...\n}\n\nWhitespace in Expressions\nAvoid extraneous whitespace in the following situations:\nImmediately inside parenthesis, brackets or braces, with the exception of single line function declarations.\nYes:\nopen in Remix\nspam(ham[1], Coin({name: \"ham\"}));\n\nNo:\nopen in Remix\nspam( ham[ 1 ], Coin( { name: \"ham\" } ) );\n\nException:\nopen in Remix\nfunction singleLine() public { spam(); }\n\nImmediately before a comma, semicolon:\nYes:\nopen in Remix\nfunction spam(uint i, Coin coin) public;\n\nNo:\nopen in Remix\nfunction spam(uint i , Coin coin) public ;\n\nMore than one space around an assignment or other operator to align with another:\nYes:\nopen in Remix\nx = 1;\ny = 2;\nlongVariable = 3;\n\nNo:\nopen in Remix\nx = 1;\ny = 2;\nlongVariable = 3;\n\nDo not include a whitespace in the receive and fallback functions:\nYes:\nopen in Remix\nreceive() external payable {\n ...\n}\n\nfallback() external {\n ...\n}\n\nNo:\nopen in Remix\nreceive () external payable {\n ...\n}\n\nfallback () external {\n ...\n}\n\nControl Structures\nThe braces denoting the body of a contract, library, functions and structs\nshould:\n\nopen on the same line as the declaration\nclose on their own line at the same indentation level as the beginning of the\ndeclaration.\nThe opening brace should be preceded by a single space.\n\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract Coin {\n struct Bank {\n address owner;\n uint balance;\n }\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\ncontract Coin\n{\n struct Bank {\n address owner;\n uint balance;\n }\n}\n\nThe same recommendations apply to the control structures if, else, while,\nand for.\nAdditionally there should be a single space between the control structures\nif, while, and for and the parenthetic block representing the\nconditional, as well as a single space between the conditional parenthetic\nblock and the opening brace.\nYes:\nopen in Remix\nif (...) {\n ...\n}\n\nfor (...) {\n ...\n}\n\nNo:\nopen in Remix\nif (...)\n{\n ...\n}\n\nwhile(...){\n}\n\nfor (...) {\n ...;}\n\nFor control structures whose body contains a single statement, omitting the\nbraces is ok if the statement is contained on a single line.\nYes:\nopen in Remix\nif (x < 10)\n x += 1;\n\nNo:\nopen in Remix\nif (x < 10)\n someArray.push(Coin({\n name: 'spam',\n value: 42\n }));\n\nFor if blocks which have an else or else if clause, the else should be\nplaced on the same line as the if’s closing brace. This is an exception compared\nto the rules of other block-like structures.\nYes:\nopen in Remix\nif (x < 3) {\n x += 1;\n} else if (x > 7) {\n x -= 1;\n} else {\n x = 5;\n}\n\nif (x < 3)\n x += 1;\nelse\n x -= 1;\n\nNo:\nopen in Remix\nif (x < 3) {\n x += 1;\n}\nelse {\n x -= 1;\n}\n\nFunction Declaration\nFor short function declarations, it is recommended for the opening brace of the\nfunction body to be kept on the same line as the function declaration.\nThe closing brace should be at the same indentation level as the function\ndeclaration.\nThe opening brace should be preceded by a single space.\nYes:\nopen in Remix\nfunction increment(uint x) public pure returns (uint) {\n return x + 1;\n}\n\nfunction increment(uint x) public pure onlyOwner returns (uint) {\n return x + 1;\n}\n\nNo:\nopen in Remix\nfunction increment(uint x) public pure returns (uint)\n{\n return x + 1;\n}\n\nfunction increment(uint x) public pure returns (uint){\n return x + 1;\n}\n\nfunction increment(uint x) public pure returns (uint) {\n return x + 1;\n }\n\nfunction increment(uint x) public pure returns (uint) {\n return x + 1;}\n\nThe modifier order for a function should be:\n\nVisibility\nMutability\nVirtual\nOverride\nCustom modifiers\n\nYes:\nopen in Remix\nfunction balance(uint from) public view override returns (uint) {\n return balanceOf[from];\n}\n\nfunction increment(uint x) public pure onlyOwner returns (uint) {\n return x + 1;\n}\n\nNo:\nopen in Remix\nfunction balance(uint from) public override view returns (uint) {\n return balanceOf[from];\n}\n\nfunction increment(uint x) onlyOwner public pure returns (uint) {\n return x + 1;\n}\n\nFor long function declarations, it is recommended to drop each argument onto\nits own line at the same indentation level as the function body. The closing\nparenthesis and opening bracket should be placed on their own line as well at\nthe same indentation level as the function declaration.\nYes:\nopen in Remix\nfunction thisFunctionHasLotsOfArguments(\n address a,\n address b,\n address c,\n address d,\n address e,\n address f\n)\n public\n{\n doSomething();\n}\n\nNo:\nopen in Remix\nfunction thisFunctionHasLotsOfArguments(address a, address b, address c,\n address d, address e, address f) public {\n doSomething();\n}\n\nfunction thisFunctionHasLotsOfArguments(address a,\n address b,\n address c,\n address d,\n address e,\n address f) public {\n doSomething();\n}\n\nfunction thisFunctionHasLotsOfArguments(\n address a,\n address b,\n address c,\n address d,\n address e,\n address f) public {\n doSomething();\n}\n\nIf a long function declaration has modifiers, then each modifier should be\ndropped to its own line.\nYes:\nopen in Remix\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n public\n onlyOwner\n priced\n returns (address)\n{\n doSomething();\n}\n\nfunction thisFunctionNameIsReallyLong(\n address x,\n address y,\n address z\n)\n public\n onlyOwner\n priced\n returns (address)\n{\n doSomething();\n}\n\nNo:\nopen in Remix\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n public\n onlyOwner\n priced\n returns (address) {\n doSomething();\n}\n\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n public onlyOwner priced returns (address)\n{\n doSomething();\n}\n\nfunction thisFunctionNameIsReallyLong(address x, address y, address z)\n public\n onlyOwner\n priced\n returns (address) {\n doSomething();\n}\n\nMultiline output parameters and return statements should follow the same style recommended for wrapping long lines found in the Maximum Line Length section.\nYes:\nopen in Remix\nfunction thisFunctionNameIsReallyLong(\n address a,\n address b,\n address c\n)\n public\n returns (\n address someAddressName,\n uint256 LongArgument,\n uint256 Argument\n )\n{\n doSomething()\n\n return (\n veryLongReturnArg1,\n veryLongReturnArg2,\n veryLongReturnArg3\n );\n}\n\nNo:\nopen in Remix\nfunction thisFunctionNameIsReallyLong(\n address a,\n address b,\n address c\n)\n public\n returns (address someAddressName,\n uint256 LongArgument,\n uint256 Argument)\n{\n doSomething()\n\n return (veryLongReturnArg1,\n veryLongReturnArg1,\n veryLongReturnArg1);\n}\n\nFor constructor functions on inherited contracts whose bases require arguments,\nit is recommended to drop the base constructors onto new lines in the same\nmanner as modifiers if the function declaration is long or hard to read.\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n// Base contracts just to make this compile\ncontract B {\n constructor(uint) {\n }\n}\n\ncontract C {\n constructor(uint, uint) {\n }\n}\n\ncontract D {\n constructor(uint) {\n }\n}\n\ncontract A is B, C, D {\n uint x;\n\n constructor(uint param1, uint param2, uint param3, uint param4, uint param5)\n B(param1)\n C(param2, param3)\n D(param4)\n {\n // do something with param5\n x = param5;\n }\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n\n// Base contracts just to make this compile\ncontract B {\n constructor(uint) {\n }\n}\n\ncontract C {\n constructor(uint, uint) {\n }\n}\n\ncontract D {\n constructor(uint) {\n }\n}\n\ncontract A is B, C, D {\n uint x;\n\n constructor(uint param1, uint param2, uint param3, uint param4, uint param5)\n B(param1)\n C(param2, param3)\n D(param4) {\n x = param5;\n }\n}\n\ncontract X is B, C, D {\n uint x;\n\n constructor(uint param1, uint param2, uint param3, uint param4, uint param5)\n B(param1)\n C(param2, param3)\n D(param4) {\n x = param5;\n }\n}\n\nWhen declaring short functions with a single statement, it is permissible to do it on a single line.\nPermissible:\nopen in Remix\nfunction shortFunction() public { doSomething(); }\n\nThese guidelines for function declarations are intended to improve readability.\nAuthors should use their best judgment as this guide does not try to cover all\npossible permutations for function declarations.\n\nMappings\nIn variable declarations, do not separate the keyword mapping from its\ntype by a space. Do not separate any nested mapping keyword from its type by\nwhitespace.\nYes:\nopen in Remix\nmapping(uint => uint) map;\nmapping(address => bool) registeredAddresses;\nmapping(uint => mapping(bool => Data[])) public data;\nmapping(uint => mapping(uint => s)) data;\n\nNo:\nopen in Remix\nmapping (uint => uint) map;\nmapping( address => bool ) registeredAddresses;\nmapping (uint => mapping (bool => Data[])) public data;\nmapping(uint => mapping (uint => s)) data;\n\nVariable Declarations\nDeclarations of array variables should not have a space between the type and\nthe brackets.\nYes:\nopen in Remix\nuint[] x;\n\nNo:\nopen in Remix\nuint [] x;\n\nOther Recommendations\n\nStrings should be quoted with double-quotes instead of single-quotes.\n\nYes:\nopen in Remix\nstr = \"foo\";\nstr = \"Hamlet says, 'To be or not to be...'\";\n\nNo:\nopen in Remix\nstr = 'bar';\nstr = '\"Be yourself; everyone else is already taken.\" -Oscar Wilde';\n\nSurround operators with a single space on either side.\n\nYes:\nopen in Remix\nx = 3;\nx = 100 / 10;\nx += 3 + 4;\nx |= y && z;\n\nNo:\nopen in Remix\nx=3;\nx = 100/10;\nx += 3+4;\nx |= y&&z;\n\nOperators with a higher priority than others can exclude surrounding\nwhitespace in order to denote precedence. This is meant to allow for\nimproved readability for complex statements. You should always use the same\namount of whitespace on either side of an operator:\n\nYes:\nopen in Remix\nx = 2**3 + 5;\nx = 2*y + 3*z;\nx = (a+b) * (a-b);\n\nNo:\nopen in Remix\nx = 2** 3 + 5;\nx = y+z;\nx +=1;\n\nOrder of Layout\nContract elements should be laid out in the following order:\n\nPragma statements\nImport statements\nEvents\nErrors\nInterfaces\nLibraries\nContracts\n\nInside each contract, library or interface, use the following order:\n\nType declarations\nState variables\nEvents\nErrors\nModifiers\nFunctions\n\nNote\nIt might be clearer to declare types close to their use in events or state\nvariables.\n\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.4 <0.9.0;\n\nabstract contract Math {\n error DivideByZero();\n function divide(int256 numerator, int256 denominator) public virtual returns (uint256);\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.4 <0.9.0;\n\nabstract contract Math {\n function divide(int256 numerator, int256 denominator) public virtual returns (uint256);\n error DivideByZero();\n}\n\nNaming Conventions\nNaming conventions are powerful when adopted and used broadly. The use of\ndifferent conventions can convey significant meta information that would\notherwise not be immediately available.\nThe naming recommendations given here are intended to improve the readability,\nand thus they are not rules, but rather guidelines to try and help convey the\nmost information through the names of things.\nLastly, consistency within a codebase should always supersede any conventions\noutlined in this document.\n\nNaming Styles\nTo avoid confusion, the following names will be used to refer to different\nnaming styles.\n\nb (single lowercase letter)\nB (single uppercase letter)\nlowercase\nUPPERCASE\nUPPER_CASE_WITH_UNDERSCORES\nCapitalizedWords (or CapWords)\nmixedCase (differs from CapitalizedWords by initial lowercase character!)\n\nNote\nWhen using initialisms in CapWords, capitalize all the letters of the initialisms. Thus HTTPServerError is better than HttpServerError. When using initialisms in mixedCase, capitalize all the letters of the initialisms, except keep the first one lower case if it is the beginning of the name. Thus xmlHTTPRequest is better than XMLHTTPRequest.\n\nNames to Avoid\n\nl - Lowercase letter el\nO - Uppercase letter oh\nI - Uppercase letter eye\n\nNever use any of these for single letter variable names. They are often\nindistinguishable from the numerals one and zero.\n\nContract and Library Names\n\nContracts and libraries should be named using the CapWords style. Examples: SimpleToken, SmartBank, CertificateHashRepository, Player, Congress, Owned.\nContract and library names should also match their filenames.\nIf a contract file includes multiple contracts and/or libraries, then the filename should match the core contract. This is not recommended however if it can be avoided.\n\nAs shown in the example below, if the contract name is Congress and the library name is Owned, then their associated filenames should be Congress.sol and Owned.sol.\nYes:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n\n// Owned.sol\ncontract Owned {\n address public owner;\n\n modifier onlyOwner {\n require(msg.sender == owner);\n _;\n }\n\n constructor() {\n owner = msg.sender;\n }\n\n function transferOwnership(address newOwner) public onlyOwner {\n owner = newOwner;\n }\n}\n\nand in Congress.sol:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.0 <0.9.0;\n\nimport \"./Owned.sol\";\n\ncontract Congress is Owned, TokenRecipient {\n //...\n}\n\nNo:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n\n// owned.sol\ncontract owned {\n address public owner;\n\n modifier onlyOwner {\n require(msg.sender == owner);\n _;\n }\n\n constructor() {\n owner = msg.sender;\n }\n\n function transferOwnership(address newOwner) public onlyOwner {\n owner = newOwner;\n }\n}\n\nand in Congress.sol:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.7.0;\n\nimport \"./owned.sol\";\n\ncontract Congress is owned, tokenRecipient {\n //...\n}\n\nStruct Names\nStructs should be named using the CapWords style. Examples: MyCoin, Position, PositionXY.\n\nEvent Names\nEvents should be named using the CapWords style. Examples: Deposit, Transfer, Approval, BeforeTransfer, AfterTransfer.\n\nFunction Names\nFunctions should use mixedCase. Examples: getBalance, transfer, verifyOwner, addMember, changeOwner.\n\nFunction Argument Names\nFunction arguments should use mixedCase. Examples: initialSupply, account, recipientAddress, senderAddress, newOwner.\nWhen writing library functions that operate on a custom struct, the struct\nshould be the first argument and should always be named self.\n\nLocal and State Variable Names\nUse mixedCase. Examples: totalSupply, remainingSupply, balancesOf, creatorAddress, isPreSale, tokenExchangeRate.\n\nConstants\nConstants should be named with all capital letters with underscores separating\nwords. Examples: MAX_BLOCKS, TOKEN_NAME, TOKEN_TICKER, CONTRACT_VERSION.\n\nModifier Names\nUse mixedCase. Examples: onlyBy, onlyAfter, onlyDuringThePreSale.\n\nEnums\nEnums, in the style of simple type declarations, should be named using the CapWords style. Examples: TokenGroup, Frame, HashStyle, CharacterLocation.\n\nAvoiding Naming Collisions\n\nsingleTrailingUnderscore_\n\nThis convention is suggested when the desired name collides with that of\nan existing state variable, function, built-in or otherwise reserved name.\n\nUnderscore Prefix for Non-external Functions and Variables\n\n_singleLeadingUnderscore\n\nThis convention is suggested for non-external functions and state variables (private or internal). State variables without a specified visibility are internal by default.\nWhen designing a smart contract, the public-facing API (functions that can be called by any account)\nis an important consideration.\nLeading underscores allow you to immediately recognize the intent of such functions,\nbut more importantly, if you change a function from non-external to external (including public)\nand rename it accordingly, this forces you to review every call site while renaming.\nThis can be an important manual check against unintended external functions\nand a common source of security vulnerabilities (avoid find-replace-all tooling for this change).\n\nNatSpec\nSolidity contracts can also contain NatSpec comments. They are written with a\ntriple slash (///) or a double asterisk block (/** ... */) and\nthey should be used directly above function declarations or statements.\nFor example, the contract from a simple smart contract with the comments\nadded looks like the one below:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\n/// @author The Solidity Team\n/// @title A simple storage example\ncontract SimpleStorage {\n uint storedData;\n\n /// Store `x`.\n /// @param x the new value to store\n /// @dev stores the number in the state variable `storedData`\n function set(uint x) public {\n storedData = x;\n }\n\n /// Return the stored value.\n /// @dev retrieves the value of the state variable `storedData`\n /// @return the stored value\n function get() public view returns (uint) {\n return storedData;\n }\n}\n\nIt is recommended that Solidity contracts are fully annotated using NatSpec for all public interfaces (everything in the ABI).\nPlease see the section about NatSpec for a detailed explanation.","tokens":5641,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264604404,"hash":"c891655c16e7e90e6e9c30ef41ac8ab87fd68d1c"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/25","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 20 / 26\n\n Nov 2023\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n post by leohio on Feb 12, 2022\n\n post by experience on Feb 12, 2022\n\n post by Killari on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n post by kravets on Aug 3, 2023\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n leohio\n\n When using Witness Encryption (WE) for a Bitcoin bridge, there’s potential for the most efficient construction to be a Drivechain without the need for BIP300. If WE is efficient, a Drivechain can be built without the BIP300 soft fork, and with Drivechain in place, a trustless Bitcoin bridge becomes feasible.\nTo start, Drivechain (BIP300+Blind Merge Mining) can create a trustless Bitcoin Bridge. Concerning the unlocking of bitcoin through the hashrate escrow, a vote is taken based on hash power using a specific oracle. This oracle is set up to verify BTC burns that are wrapped by Ethereum’s stateless client.\nThe essence of this efficiency is that instead of incorporating the Burn’s Proof into a circuit as in the original plan with Witness Encryption (WE), miners with incentives will simply verify it. This means that the proof of this Burn and the Ethereum blockchain itself can be entirely removed from WE.\nIn constructing a Drivechain using WE, the method to execute hashrate escrow is using WE to unlock private keys instead of Bitcoin’s new opcode. The method to make this private key a 1/N security remains the same as the original proposal of this page. Essentially, it just involves integrating the difficulty adjustment, accumulated hash power value, hash calculation of block verification, and signature by the bundle’s destination into the circuit. This is far more efficient than the original plan which verified the entire Ethereum chain with a WE circuit.\nBeyond the construction of WE, another challenge is whether the developed Drivechain will be sufficiently recognized by miners, and if a mistaken bundle is created, whether a soft fork will truly occur. There’s an inherent incentive on this matter. If miners act rationally, it will inherit the security of Bitcoin’s Layer1.\nReference:\nttps://github.com/bitcoin/bips/blob/master/bip-0300.mediawiki\nttps://github.com/bitcoin/bips/blob/master/bip-0301.mediawiki\nhttps://www.truthcoin.info/blog/drivechain/#drivechain-a-simple-spv-proof\n\n post by leohio on Oct 31, 2023\n\n leohio\n\n Mirror\n\n The idea of Drivechain has many discussions of its security influence on the Bitcoin protocol. So what you said makes some sense. What I refer to the trustless bridge discussion is not about whether or not each is a good idea. At least, this post (and the comment) is talking about the theoretical facts.\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n post by devfans on Nov 16, 2023\n\n devfans\n\n Hi, correct me if I am wrong. Assuming the below condition:\nAlice deposits 1 BTC to a deposit address generated by the generators and gets the ciphertext CT, and then mints 1 WBTC on the Ethereum chain.\nThe current Ethereum PoS network is maintained by a group of validators, say it’s group A. And a group named B, is a 2/3 subset of the group A. Say after a year, the group B validators exited the PoS network and withdraw their stake. Then they forked the chain from the checkpoint one year before, thus they wont get slashed even they publish the headers in OP_RETURNs, while they can still burn 1 WBTC to the contract to forge a witness to satisfy the circuit, thus recover the private key with Alice’s ciphertext CT. Does this assumption hold? This a common case for a PoS network according to my understanding.\nBTW, is there an implemented PoC version of this brilliant idea? Published somewhere to check? or A plan to implement it?\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n leohio\n\nThe ciphertexts get generated when the deposit address is generated. So it already exists before he/she deposits BTC there.\n\nIf the BLS signature on a forked chain is published in OP_RETURN, they get slashed.\nAnd even trying that is dangerous for them since only one honest node can reveal that to make them slashed.\n\nThe update is here.\nIt’s not fully inheriting the security assumption, but this is the practical approach that comes after this post.\nhttps://ethresear.ch/t/octopus-contract-and-its-applications/\n\n post by karl-lolme on Dec 19, 2023\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n post by karl-lolme on Apr 3, 2024\n\n Powered by Discourse","tokens":1340,"squid":"ink-research","role":"Deep Scholar","at":1791264604452,"hash":"4c62d3b6b946d2fb514d56367e6385a9b353b0f0"}
{"url":"https://governance.aave.com/t/technical-maintenance-proposals/15274/137","domain":"governance.aave.com","title":"Technical maintenance proposals - Development - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 113\n\n 10\n\n 3\n\n read \n\n 50\n min\n\n Oct 2023\n\n 133 / 133\n\n Aug 6\n\n Aug 6\n\n Load more posts above\n\n post by bgdlabs on Oct 19, 2025\n\n bgdlabs\n\n Leader\n\n AGRS. Slope2 Risk Oracle activation (v3 Core Ethereum, Linea)\n\nSimple Summary\nThis proposal activates the automated Aave Generalized Risk Stewards (AGRS) system on the Aave Ethereum Core and Linea Instance to perform automated slope2 interest rate updates for WETH, USDT, USDC, USDe assets; as proposed HERE.\nUnder the hood, the AGRS consumes the Risk Oracle infrastructure by @chaoslabs.\n\nMotivation\nThe slope2 risk oracle introduces a dynamic mechanism to address liquidity contraction in high-leverage lending markets. Unlike traditional piecewise-linear rate curves that produce abrupt APR spikes during supply shocks, the oracle stages its response by starting with a low baseline when utilization first crosses the kink, compounding convexly as stress persists, and decaying predictably once conditions normalize.\nThis approach minimizes unnecessary preemptive shocks while providing transparent escalation and robust solvency protection for suppliers, with borrowers facing fair, time-aligned incentives that intensify only during sustained high utilization periods.\nDetailed methodology can be found here.\nThis new component of AGRS follows the same example of interest rate updates for WETH on v3 Prime Ethereum (this proposal), in production for some time.\n\nSpecification\nThe automated AGRS will use another instance of AGRS (exactly the same codebase as the other model), with the following constraints:\n\nThis instance will only allow changes of one risk parameter: slope 2.\nRecommendations of the parameter will be submitted to a RiskOracle smart contract, from the Edge off-chain infrastructure.\nBetween the risk oracle smart contract and the AGRS contract, there will be a very thin middleware AaveStewardRatesInjector, which will have the following logic:\n\nWill take recommendations from the Edge Risk Oracle side and propagate them to the AGRS contract.\nEnforce that only the configured asset can be acted upon.\nGiven the protections (percentage constraints and time delay) on the AGRS side and that it is an assumption that risk recommendation will be timing correct updates on the Edge Risk Oracle, the propagation will be permissionless.\n\nAutomation. The AaveStewardRatesInjector middleware, technically being part of the Aave Robot infrastructure, will run on Chainlink Automation and will be registered using the AaveCLRobotOperator contract with 250 LINK from the Ethereum Collector.\nSince Chainlink Automation is not available on Linea, the automation will be configured using Gelato’s infrastructure over there.\n\nRoles from the Aave protocol. The new instance of the RiskSteward will be given the RiskAdmin role with the following method: ACL_MANAGER.addRiskAdmin()\n\nWhitelisted assets. Only the following assets will be whitelisted for the automatic AGRS system, enforced strictly on the AaveStewardRatesInjector contract:\n\nAaveV3Ethereum: WETH, USDC, USDT, USDe\nAaveV3Linea: WETH, USDC, USDT\n\nEnforced constraints. The automated AGRS system will be configured with the following constraints:\n\nParameter\nMaximum Change (Absolute)\nminimumDelay\n\nSlope2\n4%\n8 Hours\n\n [ARFC] Automation of the Slope2 Parameter via Risk Oracles\n\n post by bgdlabs on Oct 21, 2025\n\n bgdlabs\n\n Leader\n\nWe have created an on-chain AIP for this proposal.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=395\n\n 15 days later\n\n post by bgdlabs on Nov 5, 2025\n\n bgdlabs\n\n Leader\n\n a.DI/Governance. Enable support for X Layer\n\nSimple Summary\nProposal to register the necessary X Layer adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 X Layer.\n\nMotivation\nIn order to be able to pass messages from Ethereum to X Layer via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → X Layer smart contract enabled in the system (native adapter).\nThe first case of message passing Ethereum → X Layer is the activation proposal for an Aave v3 X Layer pool and consequently, to be able to execute on the X Layer side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts.\n\nSpecification\nThe proposal payload simply registers pre-deployed X Layer adapters (with the necessary configurations to communicate with the X Layer a.DI) on the Ethereum a.DI instance.\nThis is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.\n\nThe following are the configured adapters for the Ethereum → X Layer path. The required confirmations on the path are 1 out of 1.\n\nNetwork\nX Layer Native Adapter\n\nEthereum\n0x9fD570da8fFe3384F1093833D44072ea79ABdEB0\n\nX Layer\n0xEbc2c80073E4752e9A1D2e9A9bC98e8F4EeE9Be9\n\nThe new a.DI deployments on X Layer network are as follows:\n\nContract\nAddress\n\nCrossChainController\n0xFdd46155fD3DA5B907AD3B9f9395366290f58097\n\nGranular Guardian\n0xD6727ec503A8d0C10a0EAA4e76eAf9A628188b25\n\nThe new Aave Governance deployments on X Layer network are as follows:\n\nContract\nAddress\n\nPayloadsController\n0x80e11cB895a23C901a990239E5534054C66476B5\n\nExecutor Lvl 1\n0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19\n\nGovernance Guardian\n0xeB55A63bf9993d80c86D47f819B5eC958c7C127B\n\nBGD Labs Guardian\n0x734c3fF8DE95c3745770df69053A31FDC92F2526\n\n 1 month later\n\n post by bgdlabs on Dec 18, 2025\n\n bgdlabs\n\n Leader\n\nWe have created an on-chain AIP for this proposal.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=422\n\n 18 days later\n\n post by bgdlabs on Jan 6\n\n bgdlabs\n\n Leader\n\n AGRS (Risk Stewards) migration to Risk Agents\n\nSimple Summary\nFollowing the approval of Risk Agents, this proposal migrates all existing injector middleware infra used to perform automated risk updates to the new chaos agents system.\n\nMotivation\nCurrently, the AGRS, in conjunction with the injector system, is responsible for processing highly constrained risk recommendations for a range of parameters, including supply and borrow caps, interest rates, pendle pt e-mode collateral params, and CAPO values across multiple assets and Aave instances. These updates are executed through the injector middleware, which consumes updates from the chaos risk oracles and injects updates onto the Aave protocol in real-time.\nWhile the existing system has served Aave more than well, several limitations exist:\n\nLimited generalization: Almost every Risk Stewards activation requires ad-hoc replication of the entire architecture. This results in meaningful overhead for Aave SPs.\nLimited infrastructure visibility: Tracking all active Risk Stewards, as well as their covered assets and constraints, can be challenging at times.\n\nThe Chaos Risk Agents framework generalizes and modularizes the process of ingesting Risk Oracle data within Aave. It eliminates redundant deployments, centralizes validation logic, and improves visibility across all risk automation layers. The result is a cleaner, more maintainable architecture that allows Aave to expand real-time risk management capabilities, ensuring consistent, verifiable execution of parameter updates.\n\nSpecification\nAll the current automated risk param updates will be migrated from the old injector infra to the chaos-agent system, including the following:\n\nRisk Param\nNetwork Instance\nConstrains\n\nSupply and Borrow Caps\nArbitrum, Avalanche, Base, BNB, Gnosis, Optimism, Polygon\nmax 30% relative change / 3 days\n\nPendle EMode Collateral Param\nEthereumCore, Plasma\nmax 0.5% absolute change / 3 days for LT, LTV, LB\n\nPendle Discount Rate\nEthereumCore, Plasma\nmax 1% absolute change / 2 days\n\nInterest Rate: Base, Slope1, Slope2, uOptimal\nEthereumPrime\nmax 3% uOpt, 0.5% base, 0.5% slope1, 5% slope2 absolute change / 1 day\n\nInterest Rate: Slope2\nEthereumCore, Linea\nmax 4% absolute change / 8 hours\n\nWhitelisted Assets / Markets configured by agent:\n\nWhitelisted Assets / Markets\n\nArbitrum Supply / Borrow Caps\nWETH, USDC, USDT, WBTC, DAI, weETH, ARB, USDC.e, GHO, LINK, wstETH, LUSD, FRAX, rETH, AAVE\n\nAvalanche Supply / Borrow Caps\nWETHe, USDCe, USDTe, WBTCe, DAIe, LINKe, AAVEe, WAVAX, sAVAX, FRAX, MAI, BTCb, AUSD\n\nBase Supply / Borrow Caps\nWETH, cbETH, USDC, USDbC, weETH, GHO, wstETH, cbBTC, LBTC, EURC\n\nBNB Supply / Borrow Caps\nETH, wstETH, BTCB, USDC, USDT, WBNB\n\nGnosis Supply / Borrow Caps\nWETH, wstETH, USDCe, sDAI, EURe, GNO\n\nOptimism Supply / Borrow Caps\nWETH, wstETH, rETH, WBTC, USDC, USDT, OP\n\nPolygon Supply / Borrow Caps\nWETH, wstETH, WBTC, USDC, USDC.e, USDT, DAI, AAVE, LINK, WPOL\n\nEthereumCore Pendle EMode Collateral\nEMode Ids: 8, 9, 10, 12, 13, 14, 17, 18, 19, 20, 24, 25, 27, 28, 29, 30, 31, 32\n\nPlasma Pendle EMode Collateral\nEMode Ids: 5, 6, 7, 8, 13, 14, 15, 16\n\nEthereumCore Pendle Discount Rate\nPT_sUSDe_31JUL25, PT_USDe_31JUL25, PT_eUSDe_14AUG25, PT_sUSDe_25SEP25, PT_USDe_25SEP25, PT_sUSDe_27NOV25, PT_USDe_27NOV25, PT_sUSDe_5FEB26, PT_USDe_5FEB26\n\nPlasma Pendle Discount Rate\nPT_sUSDe_15JAN26, PT_USDe_15JAN26, PT_sUSDE_9APR26, PT_USDE_9APR26\n\nEthereumPrime Interest Rate\nWETH\n\nEthereumCore Slope2 Interest Rate\nWETH, USDC, USDT, USDe\n\nLinea Slope2 Interest Rate\nWETH, USDC, USDT\n\nPlease note: The whitelisted assets and the constraints are the same as previously on the AGRS injector infra. This proposal only migrates the existing automated AGRS system using injector infrastructure; there is no change to the manual AGRS system, and updates on it using the new infra will be applied at a different AIP.\n\nThe risk agent contracts have not been pre-configured during deployment, and all operations, will be done on the payload:\n\nRegister new agents on the AgentHub contract by calling registerAgent()\nConfigure constrained ranges on the RangeValidationModule to strictly bound the risk param update from the Chaos Risk Oracle.\nGive RISK_ADMIN role to the AgentContract which will be called by the Chaos Agent system to inject updates onto the Aave protocol.\nRevoke RISK_ADMIN role from the previous injector contracts, as this system will be unused.\nCancel previous injector automation and register new ones on the AgentHub Automation wrapper contract. This is done only on networks where we use Chainlink automation, on Linea, Gnosis, and Plasma networks, this will be done off-chain using the DAO account on Gelato automation.\nReimburse BGD Labs with 120 LINK by withdrawing aLINK from Collector on Ethereum, which was used to fund chainlink automation on BNB, Base networks as Collector did not have LINK on those networks.\n\nAll configurations used on the proposal payload could be found on the AgentConfigLib.\nMore detailed specifications can be found on the chaos-agents-migration repo.\nSecurity\nChaos Risk Agent contracts is independently audited by Zellic and Hexens. In addition, the migration proposal payload and setup has been reviewed by Certora.\nPermissions\nDetailed permissions post payload execution of the Chaos Risk Agent could be found on the permissions-book, but to summarize (for all networks):\n\nRole\nEntity\n\nAgentHub Owner\nGovernance Executor Lvl 1\n\nAgentHub ProxyAdmin owner\nGovernance Executor Lvl 1\n\nAgent Admin\nGovernance Executor Lvl 1\n\nRangeValidationModule Config Update\nGovernance Executor Lvl 1\n\nRISK_ADMIN on ACL Manager\nEach Agent contract\n\nAddresses\nAll Agents Hub addresses per network can be found on Aave Address Book.\n\n [ARFC] Chaos Risk Agents\n\n post by bgdlabs on Jan 9\n\n bgdlabs\n\n Leader\n\nWe have created an on-chain AIP for this proposal.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=432\n\n 11 days later\n\n post by bgdlabs on Jan 20\n\n bgdlabs\n\n Leader\n\n a.DI/Governance. Enable support for megaETH\n\nSimple Summary\nProposal to register the necessary MegaEth adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 MegaEth.\n\nMotivation\nIn order to be able to pass messages from Ethereum to MegaEth via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → MegaEth smart contract enabled in the system (native adapter).\nThe first case of message passing Ethereum → MegaEth is the activation proposal for an Aave v3 MegaEth pool, and consequently, to be able to execute on the MegaEth side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts.\n\nSpecification\nThe proposal payload simply registers pre-deployed MegaEth adapters (with the necessary configurations to communicate with the MegaEth a.DI) on the Ethereum a.DI instance.\nThis is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.\nThe following are the configured adapters for the Ethereum → MegaEth path. The required confirmations on the path are 1 out of 1.\n\nNetwork\nMegaEth Native Adapter\n\nEthereum\n0xC88f3Ffa9923BfAA93681D62864a24d0D10D68d3\n\nMegaEth\n0x9Ec11a4c2fEc289Db81D75eF31140c358CB93CC6\n\nThe new a.DI deployments on megaETH network are as follows:\n\nContract\nAddress\n\nCrossChainController\n0x5EE63ACb37AeCDc7e23ACA283098f8ffD9677BBe\n\nGranular Guardian\n0x8Fa22D09b13486A40cd6b04398b948AA8bD5853A\n\nThe new Aave Governance deployments on megaETH network are as follows:\n\nContract\nAddress\n\nPayloadsController\n0x80e11cB895a23C901a990239E5534054C66476B5\n\nExecutor Lvl 1\n0xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19\n\nGovernance Guardian\n0x5a578ee1dA2c798Be60036AdDD223Ac164d948Af\n\nBGD Labs Guardian\n0x58528Cd7B8E84520df4D3395249D24543f431c21\n\n post by bgdlabs on Jan 21\n\n bgdlabs\n\n Leader\n\nWe have created an on-chain AIP for this proposal.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=438\n\n 20 days later\n\n post by bgdlabs on Feb 10\n\n bgdlabs\n\n Leader\n\n POOL_ADMIN renounceRole() by Guardian on pending pools\nSimple Summary\nAfter some maturity, it is perfectly safe for the Aave Guardian to renounce the POOL_ADMIN role in relatively new pools: Celo, Soneium, Plasma.\nMotivation\nWhenever Aave expands to a new network, it does so fully decentralised via an on-chain governance proposal (e.g., Aave v3 Plasma).\nMajor permissions (upgradeability) of the pool are set to the Aave governance from day 0, but the POOL_ADMIN is given to the Aave Guardian during a period for security.\nFrom a technical/security perspective, we don’t see any risk at the moment or need for the Guardian to hold this role anymore on the aforementioned networks: Celo, Soneium, and Plasma.\nSpecification\nThis proposal doesn’t require any governance procedure (Snapshot, on-chain), as the renounce is done directly by the Guardian.\nEach instance of the Aave Guardian (Safe) will call the renounceRole() function for the POOL_ADMIN role and its address.\n\n post by bgdlabs on Feb 12\n\n bgdlabs\n\n Leader\n\n We can confirm the Aave Guardian has renounced the roles on Celo, Soneium and Plasma.\n\n post by bgdlabs on Feb 20\n\n bgdlabs\n\n Leader\n\n Risk Agents maintenance proposal\n\nSimple Summary\nThis proposal activates the new CAPO Risk Agent on Ethereum and expands the existing Slope2 Interest Rates Agent (live on Ethereum Core, Linea) to Avalanche, Arbitrum, and Base networks.\nAdditionally, it tightens and aligns the Slope2 Interest Rates Agent constraints on Ethereum Core and Linea with the new networks.\n\nMotivation\nFollowing the successful migration of the AGRS (Risk Stewards) infrastructure to Risk Agents, which activated the Slope2 Interest Rates Agent on Ethereum Core, Linea, it feels natural to expand the Rates Agent on more networks and introduce the new CAPO agent type.\nBoth initiatives have been suggested by the Risk Service providers on the forum—Slope2 RatesAgent expansion and new CapoAgent addition—along with the latest assets, networks, and constraints for the agents.\nCAPO Agent (new)\nThe CAPO system provides critical price safeguards for yield-bearing assets by defining upper bounds on exchange rates. However, when CAPO parameters remain static for extended periods, the derived maximum ratio can become increasingly detached from real-world exchange rate dynamics, creating vulnerability to price manipulations. By activating the CAPO Risk Agent on Ethereum, parameters like snapshotRatio and maxYearlyRatioGrowthPercent can be dynamically calibrated through the Risk Oracle, maintaining tight and responsive protection for yield-bearing collateral assets without requiring manual governance intervention. More details can be found on the forum post here.\nSlope2 Rates Agent (expansion on more networks)\nAdditionally, extending the Interest Rates Agent to Avalanche, Arbitrum, and Base networks allows for automated adjustment of the variableRateSlope2 parameter on high-utilization assets, ensuring interest rates remain responsive to market conditions across these networks. As part of this expansion, the constraints on Ethereum Core and Linea are tightened from 4% to 2% for stablecoins and 1.5% for WETH, aligning them with the new networks. More details can be found on the forum post here.\n\nSpecification\nThe proposal activates the AaveCapoAgent and AaveRatesAgent with the following params using the chaos-agents infra:\nCAPO Agent\n\nNetwork\nAssets\nParameter\nConstraint\n\nEthereum\nwstETH, weETH, rsETH, osETH, ezETH, cbETH, rETH, tETH, ETHx, LBTC, eBTC, sUSDe, syrupUSDT, sDAI\nsnapshotRatio\nMax 3% relative change per 3 days\n\nEthereum\nwstETH, weETH, rsETH, osETH, ezETH, cbETH, rETH, tETH, ETHx, LBTC, eBTC, sUSDe, syrupUSDT, sDAI\nmaxYearlyRatioGrowthPercent\nMax 10% relative change per 3 days\n\nRates Agent\n\nNetwork\nAssets\nParameter\nConstraint\n\nAvalanche\nUSDC, USDt\nvariableRateSlope2\nMax 2% absolute change per 8 hours\n\nAvalanche\nWETH.e\nvariableRateSlope2\nMax 1.5% absolute change per 8 hours\n\nArbitrum\nUSDC, USDT\nvariableRateSlope2\nMax 2% absolute change per 8 hours\n\nArbitrum\nWETH\nvariableRateSlope2\nMax 1.5% absolute change per 8 hours\n\nBase\nUSDC\nvariableRateSlope2\nMax 2% absolute change per 8 hours\n\nBase\nWETH\nvariableRateSlope2\nMax 1.5% absolute change per 8 hours\n\nRates Agent Constraint Alignment (Ethereum Core & Linea)\nTo align the variableRateSlope2 constraints on Ethereum Core and Linea with the new networks:\n\nNetwork\nAssets\nParameter\nNew Constraint\nPrevious Constraint\n\nEthereum Core\nUSDC, USDT, USDe\nvariableRateSlope2\nMax 2% absolute change per 8 hours\nMax 4% absolute change per 8 hours\n\nEthereum Core\nWETH\nvariableRateSlope2\nMax 1.5% absolute change per 8 hours\nMax 4% absolute change per 8 hours\n\nLinea\nUSDC, USDT\nvariableRateSlope2\nMax 2% absolute change per 8 hours\nMax 4% absolute change per 8 hours\n\nLinea\nWETH\nvariableRateSlope2\nMax 1.5% absolute change per 8 hours\nMax 4% absolute change per 8 hours\n\nThe payload does the following actions:\n\nRegister new agents on the AgentHub contract by calling registerAgent()\nConfigure constrained ranges on the RangeValidationModule to strictly bound the risk param update from the Chaos Risk Oracle. For Ethereum Core and Linea instances we update the constraints to align with the new networks (2% for stablecoins, 1.5% for WETH).\nGive RISK_ADMIN role to the AgentContract which will be called by the Chaos Agent system to inject updates onto the Aave protocol.\nRegister new Chainlink automation on the AgentHub Automation wrapper contract for the agents.\nReimburse BGD Labs with 108 LINK by withdrawing aLINK from the Collector on Ethereum. BGD Labs previously funded Chainlink automation on Base out of pocket, as the Collector did not hold LINK on that network. The reimbursement also covers costs related to governance automation actions.\n\nPlease note: On Ethereum, the following price feeds are shared across both Core and Prime instances: wstETH, rsETH, ezETH, tETH, sUSDe so changes on the capo feed params will be applied to both instances. Since the CAPO feeds use the ACL Manager of both instances, we give the RISK_ADMIN role to the agent contract from both Core and Prime instances.\n\n 12 days later\n\n post by bgdlabs on Mar 5\n\n bgdlabs\n\n Leader\n\nWe have created an on-chain AIP for this proposal.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=455\n\n 3 months later\n\n post by AaveLabs on Jun 12\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n a.DI/Governance. Enable support for Monad\nSimple Summary\nProposal to register the necessary Monad adapters on a.DI, a technical pre-requirement for an activation vote of Aave v3 Monad.\nMotivation\nIn order to be able to pass messages from Ethereum to Monad via a.DI (Aave Delivery Infrastructure), it is necessary to have at least one valid adapter Ethereum → Monad smart contract enabled in the system.\nThe first case of message passing Ethereum → Monad is the activation proposal for an Aave V3 Monad pool, and consequently, to be able to execute on the Monad side the payload, the Aave governance should approve in advance the a.DI adapters smart contracts.\nSpecification\nThe proposal payload simply registers pre-deployed Monad adapters (with the necessary configurations to communicate with the Monad a.DI) on the Ethereum a.DI instance.\nThis is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.\nThe following are the configured adapters for the Ethereum → Monad path. The required confirmations on the path are 2 out of 3.\n\nAdapter\nEthereum\nMonad\n\nCCIP\n0x7c28CEb47b49cFAC40e718dD407e4249F9C891F6\n0x7Cd4245433185A08084E9cf80300682397F733AC\n\nHyperlane\n0x6bda311748E6542d578b167d791A4130f3FbBc67\n0xb8F8aFdB7f1F4Ca9D842adFF86d052cb0C9f20CA\n\nLayerZero\n0xf9482751C9937fF940b93B5921B8984645dD0a53\n0xb544322f8e59B71d7875e0E2EbceB7f3783257BE\n\nThe new a.DI deployments on Monad network are as follows:\n\nContract\nAddress\n\nCrossChainController\n0x8dd5b84b26ae3916A5Fb34C8968F93d206216b63\n\nGranular Guardian\n0xD3DD0bE957fcE2dCd359e09374Cbc99f60337D42\n\nThe new Aave Governance deployments on Monad network are as follows:\n\nContract\nAddress\n\nPayloadsController\n0x442CA936e5E6Db875357d0A16481145c96dd9a82\n\nExecutor Lvl 1\n0xa9d0EAFF48cE1DF468f9eAeb7e628c413343F6A2\n\nGovernance Guardian\n0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4E\n\nAave Labs Guardian\n0x2B99790c35a401be873FA7Eb514D9220736BB1cA\n\nThe Protocol Guardian on Monad is as follows:\n\nContract\nAddress\n\nProtocol Guardian\n0xc887455536CBD4e615B745e70CaCde15B3117e74\n\n Pinned on Jun 19\n\n post by AaveLabs on Jun 22\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n USDG price feed update on Aave V3 instances\nSimple Summary\nReplace the existing USDG price feed on the applicable Aave V3 instances (Ethereum Core and X Layer) with a price cap adapter, set to a maximum price of 1.04 and using the Chainlink USDG feed as the underlying source. USDG is also listed on Aave V3 Ink instance, where this change can be applied as well. The same price adapter must also be used for the PT-USDG-28MAY2026 asset, given that its maturity is now expired.\nMotivation\nPer LlamaRisk’s latest assessment, liquidity conditions for USDG have improved such that the Chainlink feed now provides higher-quality pricing than the source currently in production. Following the same strategy already applied to other assets across the protocol, the proposal wraps this feed in a price adapter with a cap of 1.04, ensuring the reported price tracks Chainlink while remaining bounded on the upside.\nSpecification\nUpon execution, on each applicable instance the proposal will call setAssetSources([USDG_ADDRESS], [PRICE_CAP_ADAPTER]) on the Aave V3 oracle, pointing USDG at the newly deployed price cap adapter for that network. Each adapter uses the corresponding Chainlink USDG feed as its underlying source and the cap price listed below. The same call applies to the USDG listing on Aave V3 Ink using its respective addresses.\nSince the maturity of the PT-USDG-28MAY2026 asset is now expired, the same price adapter must be used as well.\n\nPamateter (Ethereum)\nValue\n\nChainlink Price Feed\n0x14f0737d6b705259e521EA6E9E3506AC78dBd311\n\nPrice Adapter\n0x83D20dEEdcd4aC1313496c8CBcAad0fa298c0CE4\n\nPrice cap\n1.04\n\nPamateter (X Layer)\nValue\n\nChainlink Price Feed\n0x385C6bDDE06b0E438319bF4ddBfFe51C521ABf3D\n\nPrice Adapter\n0xe00B2732396a1f047d4A00e0165025A9cF400245\n\nPrice cap\n1.04\n\nPamateter (Ink)\nValue\n\nChainlink Price Feed\n0xdb3B1fa77CF2c9597f9d4871Bed1Df03D096fdf3\n\nPrice Adapter\n0x32b1f1A1D3423dE69cf1f75092eCfDc5090d6624\n\nPrice cap\n1.04\n\n post by AaveLabs on Jun 22\n\n AaveLabs\n\n Aave Labs-Technical SP\n\nThe AIP for this proposal was successfully created, proposal#494\n\n post by AaveLabs on Jun 24\n\n AaveLabs\n\n Aave Labs-Technical SP\n\nThe AIP for this proposal was successfully created, proposal#499, voting will start in less than 24hs.\n\n 22 days later\n\n post by AaveLabs on Jul 16\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Configuration Maintenance on the Global Dollar Hub (Aave V4)\nSummary\nDuring a post-deployment review of the Global Dollar Hub launch proposal on Aave V4, we identified two configuration deviations from the intended governance setup. This proposal aligns both settings with the rest of the Aave V4 architecture.\nThe practical impact is minimal, and this only pertains to the Tokenization Spokes of the Global Dollar Hub. There is also no risk to user funds. However, we believe addressing these deviations now will avoid any potential operational issues and simplify future integrations.\nMotivation\nThe review identified two configuration deviations:\n\nThe three Tokenization Spokes deployed for the Global Dollar Hub have their ProxyAdmin contracts owned by the PayloadsController. These contracts should instead be owned by the Protocol Security Council.\n\nThe Global Dollar Hub and USDG Pendle Spoke are currently owned by the Aave Governance Executor. During the hardening phase, ownership is intended to reside with the Protocol Security Council.\n\n| Tokenization Spoke | Asset | Contract Address |\n|--------------------------|-------------------|--------------------------------------------|\n| waPaxosPT_USDG_24SEP2026 | PT_USDG_24SEP2026 | 0x27eF1140364948A0E30E248297FfDFE5a4091ec4 |\n| waPaxosUSDC | USDC | 0x4131E0B2E7AFeCEAf3d3b4225aA61a3B2B7535b8 |\n| waPaxosUSDT | USDT | 0x8Dabe53E8cB991c57f0307F6f419E6D469b0deAA |\n\nAs mentioned above, the impact of these deviations is minimal and user funds are not at risk. The affected Tokenization Spokes have accumulated almost no liquidity since deployment (only a single ~$20 position exists in the Global Dollar USDC Tokenization Spoke), which means facilitating the transition now carries no migration burden. We believe it is appropriate to adjust the configuration now to avoid future operational friction and integration issues.\nRegarding the ownership of the Global Dollar Hub and USDG Pendle Spoke, no action is deemed necessary, as ownership by the Aave Governance Executor is the intended final state. The affected permissions are primarily upgrade-related and can still be exercised through the standard governance process.\nSpecification\nThe proposal performs the following actions:\n\nRetire the three Global Dollar Hub Tokenization Spokes by setting their add cap to zero via the Protocol Security Council. The small $20 position in the Global Dollar USDC Tokenization Spoke will be able to withdraw normally, while new deposits will no longer be accepted.\n\nDeploy and activate three replacement Tokenization Spokes.\n\nCoordinate the migration with Service Providers and integrators to ensure a smooth transition to the new Tokenization Spokes.\n\nNo action is deemed necessary regarding the ownership of the Global Dollar Hub and USDG Pendle Spoke, which will remain assigned to the Aave Governance Executor.\nDisclaimer\nAave Labs is presenting this proposal as a service provider to the Aave DAO. Aave Labs is contributing this proposal as part of its approved scope of work in support of DAO operations.\nCopyright\nCopyright and related rights waived via CC0.\n\n AL Development Update | August 2026\n\n 17 days later\n\n post by AaveLabs on Aug 3\n\n AaveLabs\n\n Aave Labs-Technical SP\n\nThis update was successfully executed, see 0x4e4ac…5d3fd and 0x461c0…aeefe.\nNew Tokenization Spokes:\n\nTokenization Spoke\nAsset\nContract Address\n\nwaPaxosPT_USDG_24SEP2026\nPT_USDG_24SEP2026\n0x7Df10B4A01350D2A1d95cFbE7c9207d7210A2663\n\nwaPaxosUSDC\nUSDC\n0xaed7c529bD2878170B61C758DfAa215AC7a4FD07\n\nwaPaxosUSDT\nUSDT\n0xa0e97e45C2f89003730E467Bd484fA3eEcE5B4Cf\n\nWe kindly ask integrators to update their implementations to target the new addresses.\n\n post by AaveLabs on Aug 6\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Following coordination with integrators, we confirm that all deposits have been withdrawn from the three retired Global Dollar Hub Tokenization Spokes.\nWith no remaining positions, the deactivation of these spokes was coordinated and executed via the Protocol Security Council, completing their deprecation. See transaction 0x45e8ae6c38a2f27d6d79604733f1fe1b93d79016cd51b7fdf1564a9609cb1f4a.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d","tokens":7337,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264604558,"hash":"047668eaa0b6fcf2447de108769d290dcc315e0c"}
{"url":"https://ethresear.ch/t/trustless-bitcoin-bridge-creation-with-witness-encryption/11953/27","domain":"ethresear.ch","title":"Trustless Bitcoin Bridge Creation with Witness Encryption - Cryptography - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 3\n\n 2\n\n 2\n\n read \n\n 23\n min\n\n Feb 2022\n\n 22 / 26\n\n Dec 2023\n\n Apr 2024\n\n Load more posts above\n\n post by leohio on Feb 11, 2022\n\n post by leohio on Feb 12, 2022\n\n post by experience on Feb 12, 2022\n\n post by Killari on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n post by leohio on Feb 12, 2022\n\n 1 year later\n\n post by igorsyl on Jun 7, 2023\n\n 1 month later\n\n post by leohio on Jul 16, 2023\n\n 15 days later\n\n post by kravets on Jul 31, 2023\n\n post by kravets on Aug 3, 2023\n\n 3 months later\n\n post by leohio on Oct 30, 2023\n\n post by leohio on Oct 31, 2023\n\n 13 days later\n\n post by Ethan on Nov 13, 2023\n\n Ethan\n\n Very interesting solution.\nI have a little question. If someone forked both Ethereum&Bitcoin privately, s/he can unlock BTC without being slashed, so the security depends on the cost comparison between min(slash, BTC-fork) and unlocking all of the wrapped BTC?\n\n post by leohio on Nov 14, 2023\n\n leohio\n\n Please note these facts.\n\nif and only if one person in the validators of the private fork publishes the off-chain block, validators of that faked chain get slashed.\nBTC’s private fork does not help since they need to pour so much Proof of Work to make the private fork.\n\n post by devfans on Nov 16, 2023\n\n devfans\n\n Hi, correct me if I am wrong. Assuming the below condition:\nAlice deposits 1 BTC to a deposit address generated by the generators and gets the ciphertext CT, and then mints 1 WBTC on the Ethereum chain.\nThe current Ethereum PoS network is maintained by a group of validators, say it’s group A. And a group named B, is a 2/3 subset of the group A. Say after a year, the group B validators exited the PoS network and withdraw their stake. Then they forked the chain from the checkpoint one year before, thus they wont get slashed even they publish the headers in OP_RETURNs, while they can still burn 1 WBTC to the contract to forge a witness to satisfy the circuit, thus recover the private key with Alice’s ciphertext CT. Does this assumption hold? This a common case for a PoS network according to my understanding.\nBTW, is there an implemented PoC version of this brilliant idea? Published somewhere to check? or A plan to implement it?\n\n 1 month later\n\n post by leohio on Dec 17, 2023\n\n leohio\n\nThe ciphertexts get generated when the deposit address is generated. So it already exists before he/she deposits BTC there.\n\nIf the BLS signature on a forked chain is published in OP_RETURN, they get slashed.\nAnd even trying that is dangerous for them since only one honest node can reveal that to make them slashed.\n\nThe update is here.\nIt’s not fully inheriting the security assumption, but this is the practical approach that comes after this post.\nhttps://ethresear.ch/t/octopus-contract-and-its-applications/\n\n post by karl-lolme on Dec 19, 2023\n\n karl-lolme\n\n It was mentioned in the Octopus Contracts post that\n“This mechanism primarily enhances the performance of the previous research\nresult, Trustless Bitcoin Bridge with Witness Encryption (TBBWE) [19], to a\npractical level.”\nCan I ask how “impractical” is the performance of this design? Is it wait time during withdrawal, computational gas cost, or something else?\nThanks\n\n 2 months later\n\n post by kravets on Feb 28, 2024\n\n kravets\n\n New claim of a practical WE scheme\n\n 1 month later\n\n post by leohio on Apr 3, 2024\n\n post by karl-lolme on Apr 3, 2024\n\n Powered by Discourse","tokens":861,"squid":"ink-research","role":"Deep Scholar","at":1791264616105,"hash":"95d378c05f09b4cb365f8e0ed481a1773ee608a1"}
{"url":"https://governance.aave.com/t/ignas-delegate-platform/19510/197","domain":"governance.aave.com","title":"Ignas Delegate Platform - Delegate Platforms - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 54\n min\n\n Oct 2024\n\n 197 / 197\n\n May 14\n\n May 14\n\n Load more posts above\n\n post by Ignas on Mar 6\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: February 24, 2026\n453. Proposal: February 2026 - Funding Update (Onchain)\n\nVote: For\nRationale: The proposal improves capital efficiency, strengthens liquidity and reduces operational friction. Voted yes!\n\n454. Proposal: Create Allowance GHO Mantle (Onchain)\n\nVote: For\nRationale: This is a necessary step to successfully deploy Aave V3 and GHO on Mantle. Voted yes!\n\n455. Proposal: Focussing the Aave V3 Multichain Strategy - Phase 1 (Onchain)\n\nVote: For\n\nRationale: Freezing underperforming V3 instances reduces unnecessary operational and governance overhead.\nIt also allows DAO to focus resources on markets that generate real usage and revenue.\nThe proposed revenue floor for future deployments also sets a healthy precedent, ensuring Aave is fairly compensated for the value it brings to new chains.\n\n post by Ignas on Mar 6\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: February 26, 2026\n456. Proposal: [TEMP CHECK] Aave Will Win Framework (Snapshot)\n\nVote: NAY\n\nRationale: Voting No.\nThe ~$51M ask is too high given the execution track record since 2022, the lack of detailed financial reporting, and undisclosed governance power exposure.\nBundling revenue redirection, funding, brand control, and Aave V4 ratification into one vote limits proper scrutiny, these items should stand on their own.\nIf V4 is strong enough, it shouldn’t require forced V3 deprecation to succeed.\n\n457. Proposal: [ARFC] Aave v3.7 candidate (Snapshot)\n\nVote: For\n\nRationale: This upgrade focuses on simplifying the protocol and removing unnecessary components, which strengthens long term security and operational efficiency.\nI’m in favor.\n\n post by Ignas on Mar 6\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 2, 2026\n458. Proposal: Add GHO on Aave Plasma and deploy GSM on Plasma. (Onchain)\n\nVote: For\n\nRationale: Voting yes.\nIt’s a strong step to grow GHO’s presence on Plasma, expand its use cases, and deepen liquidity.\nThe plan is well coordinated across incentives and markets, while keeping risks controlled.\n\n459. Proposal: GSM Migration (Onchain)\n\nVote: For\n\nRationale: Voting Yes.\nThis upgrade strengthens GHO’s architecture and governance control, supporting its long term scalability and resilience.\n\n post by Ignas on Mar 6\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 4, 2026\n460. Proposal: [TEMP CHECK] Deploy Aave Protocol on Monad (Snapshot)\n\nVote: For\n\nRationale: Monad’s high throughput, low latency architecture is well positioned for fintech and onchain neobank integrations.\nEstablishing Aave early as the core liquidity layer increases the probability of capturing long term credit and stablecoin demand rather than short term mercenary liquidity.\nVoted yes on this tempcheck!\n\n461. Proposal: [ARFC] Deploy Aave v3 on X Layer (Snapshot)\n\nVote: For\n\nRationale: Voted yes with same reason Snapshot vote\nX Layer gives the protocol a first mover advantage in a payment focused ecosystem that is aiming for strong DeFi adoption.\nThe proposed risk parameters are conservative and incentives plus GHO integration improve the likelihood of real adoption.\n\n 12 days later\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 6, 2026\n462. Proposal: ACI Is Leaving Aave (Onchain)\n\nVote: For\n\nRationale: This is not an easy decision. I am voting yes.\nACI has been a key contributor to Aave governance and has shown strong principles in focusing on what is best not only for the protocol but also for $AAVE token holders.\nAppreciate all the work. And best luck with the future endevours!\n\n463. Proposal: Activate Capo Risk Agent and expand Rates Agent on more networks (Onchain)\n\nVote: For\nRationale: Voting yes. This expands the existing risk agent framework and adds CAPO to keep parameters for yield bearing assets closer to real market dynamics.\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n 464. Proposal: Enhancing Market Granularity in Aave 3.6: part 2 (Onchain)\n\nDate Voted: March 7, 2026\n\nVote: For\n\nRationale: I voted yes.\nRemoves unnecessary exposure and cleans up legacy configurations, bringing Aave closer to a more disciplined and modular risk framework.\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n 465. Proposal: [ARFC] Safety Module - Reduce Emissions (Snapshot)\n\nDate Voted: March 9, 2026\n\nVote: For\n\nRationale: This proposal improves the efficiency of the Safety Module while maintaining strong protocol security.\nCoverage is well above what the protocol needs. I voted yes!\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n 466. Proposal: [TEMP CHECK] Aave V4 Bug Bounty Program on Sherlock (Snapshot)\n\nDate Voted: March 13, 2026\n\nVote: For\n\nRationale: Support launching a dedicated Aave V4 bug bounty program on Sherlock.\nAave V4 introduces new architecture and attack surfaces, so having a dedicated, always-on bug bounty program is an important additional security layer alongside audits and formal verification.\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n 467. Proposal: [ARFC] Buyback Program - Budget Adjustment (Snapshot)\n\nDate Voted: March 14, 2026\nVote: For\nRationale: Support.\n\nThis is a necessary recalibration given declining revenue and a projected deficit.\nDropping to $30M still keeps Aave consistently buying back, but without putting unnecessary pressure on the treasury.\nPrioritizing ETH funded buybacks is a sound treasury optimization, leveraging existing exposure and correlation with AAVE to reduce stablecoin outflows.\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n 468. Proposal: [TEMP CHECK] Aave V4 Licensing (Snapshot)\n\nDate Voted: March 16, 2026\n\nVote: For\n\nRationale: Clear, enforceable licensing that protects V4 in the short term while preserving a path to open source.\nDAO ownership and the CLA remove legal ambiguity and enable scalable, permissionless contributions. Voted yes!\n\n post by Ignas on Mar 18\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 17, 2026\n469. Proposal: wstETH CAPO Oracle Incident User Reimbursement (Onchain)\n\nVote: For\n\nRationale: Clear protocol fault led to unjust liquidations, with users bearing no responsibility.\nFully reimbursing them is the right decision to uphold trust, reinforce Aave’s credibility, and demonstrate strong accountability in edge case failures.\n\n470. Proposal: Gho X-Layer Activation (Onchain)\n\nVote: For\n\nRationale: This sets up essential cross chain infrastructure via Chainlink CCIP, enabling GHO liquidity and usage on X Layer from day one.\nSupport the proposal!\n\n post by Ignas on Mar 26\n\n Ignas\n\n Orbit-Delegate\n\n 471. Proposal: [ARFC] Aave <> Chainlink SVR. Multi-network expansion (Snapshot)\n\nDate Voted: March 20, 2026\n\nVote: For\n\nRationale: Voted yes.\nSVR has already proven effective on Ethereum, capturing liquidation value without introducing disruptions, even during volatile periods.\nExpanding to Base and Arbitrum is a logical next step, especially now that Chainlink has adapted the architecture to fit L2 environments.\n\n post by Ignas on Mar 26\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 22, 2026\n472. Proposal: Reduce Safety Module Emissions (Onchain)\n\nVote: For\nRationale: Voted yes with same reason on ARFC stage. This proposal improves the efficiency of the Safety Module while maintaining strong protocol security.\n\n473. Proposal: [ARFC] Aave V4 Activation on Ethereum Mainnet (Snapshot)\n\nVote: For\n\nRationale: V4 is a clear step in the right direction, the Hub and Spoke design and broader credit flexibility align well with where onchain finance is heading.\nVoted yes!\n\n post by Ignas on Mar 26\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 25, 2026\n474. Proposal: Aave V3.6 XLayer Activation (Onchain)\n\nVote: For\nRationale: Clean final step after all approvals. Risk is well controlled with conservative caps and limited borrowability. Voted yes!\n\n475. Proposal: Enable SVR on Base and Arbitrum (Onchain)\n\nVote: For\n\nRationale: Voted yes with same reason on snapshot!\nSVR has already proven effective on Ethereum, capturing liquidation value without introducing disruptions, even during volatile periods.\nExpanding to Base and Arbitrum is a logical next step, especially now that Chainlink has adapted the architecture to fit L2 environments.\n\n476. Proposal: [ARFC] Bug Bounty Program on Sherlock (Snapshot)\n\nVote: For\n\nRationale: Supports adding an always on bug bounty for Aave V4 via Sherlock.\nThe stake gated model is a practical way to reduce spam and keep focus on high severity issues. The 5% success based fee aligns costs with actual outcomes and avoids fixed overhead.\n\n post by Ignas on Apr 2\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: March 27, 2026\n477. Proposal: [ARFC] Aave V4 Licensing (Snapshot)\n\nVote: For\n\nRationale: Voted yes with the same reason on snapshot vote. Clear, enforceable licensing that protects V4 in the short term while preserving a path to open source.\nDAO ownership and the CLA remove legal ambiguity and enable scalable, permissionless contributions.\n\n478. Proposal: Onboard BTC.b to Aave V3 Core Instance (Onchain)\n\nVote: For\n\nRationale: Proven asset on Avalanche with validated risk, and Lombard infra already trusted via LBTC.\nListing BTC.b as collateral only is a low risk way to expand BTC liquidity on Core.\n\n479. Proposal: Aave V4 Activation on Ethereum Mainnet (Onchain)\n\nVote: For\nRationale: V4 is a step in the right direction, the Hub and Spoke design and broader credit flexibility align well with where onchain finance is heading. Voted yes!\n\n480. Proposal: [TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance (Snapshot)\n\nVote: For\n\nRationale: Support onboarding USSD as a native RWA-backed stablecoin to strengthen Sonic liquidity and expand stable borrowing on Aave.\nGiven this is a new asset, looking forward to detailed risk analysis and conservative parameters in the next phase.\n\n post by Ignas on Apr 6\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: April 2, 2026\n481. Proposal: [ARFC] Update Signers and SAFE Configuration March 2026 (Snapshot)\n\nVote: For\nRationale: Voted yes. Moving from 3/4 to 3/5 improves signer availability and reduces execution delays.\n\n482. Proposal: [ARFC] sGHO Launch Configuration (Snapshot)\n\nVote: For\n\nRationale: This upgrade turns sGHO into a clean, native yield primitive.\nThe fixed 4.25% rate is competitive, and the migration design is well structured to drive adoption.\nI voted in favor.\n\n483. Proposal: Listing PT Ethena 18JUN2026 (Onchain)\n\nVote: For\nRationale: This is a clean rollover of PT USDe and sUSDe that has already proven to drive inflows. The conservative design keeps risk contained. Voted yes!\n\n 8 days later\n\n post by Ignas on Apr 15\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: April 4, 2026\n484. Proposal: [ARFC] Onboard PT-USDG-28MAY2026 to Aave V3 Core Instance (Snapshot)\n\nVote: For\n\nRationale: This adds dollar-based asset (USDG from Paxos) that already has real usage on Pendle Finance.\nA simple way to expand collateral options and let users unlock liquidity from existing positions. Voted yes!\n\n485. Proposal: [ARFC] Continued Deprecation Steps of Aave V2 Markets (Snapshot)\n\nVote: For\n\nRationale: I support this proposal.\nThese changes are well aligned with the goal of safely deprecating Aave V2, a risk aware approach to reduce bad debt and ensure an orderly wind down of V2.\n\n486. Proposal: March Funding Update (Onchain)\n\nVote: For\n\nRationale: A standard treasury and operations update that improves capital efficiency and ensures DAO can continue executing its strategy smoothly.\nVoted yes!\n\n487. Proposal: Listing PT Strata 25JUN2026 (Onchain)\n\nVote: For\nRationale: Voted yes. This extends a well established PT framework to a new maturity, maintaining consistency with previous listings.\n\n488. Proposal: Umbrella Deficit Updates (Onchain)\n\nVote: For\n\nRationale: Support the proposal!\nIncreasing the offset ensures DAO properly acts as the first loss layer, reducing unnecessary slashing in normal liquidation regimes while still preserving slashing for true tail events.\n\n 9 days later\n\n post by Ignas on Apr 24\n\n Ignas\n\n Orbit-Delegate\n\n 489. Proposal: Collateral Parameters Adjustment on MegaETH v3 (Onchain)\n\nVote: For\nRationale: Vote yes. This enables cross-margin use of WETH, BTC.b, and wstETH while keeping eMode risk protections and using conservative parameters for safety.\n\n490. Proposal: Aave Will Win Framework: Primary Funding Request (Onchain)\n\nVote: For\nRationale: Vote support this proposal as it is a direct execution of the broader Aave Will Win framework already approved by the DAO through Snapshot.\n\n491. Proposal: [TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance (Snapshot)\n\nVote: For\n\nRationale: USSD is positioned to become a core stablecoin in the Sonic Labs ecosystem, onboarding it helps Aave capture early lending and borrowing demand around a strategic liquidity asset.\nFinal implementation should remain subject to satisfactory risk parameters at ARFC. I support the proposal in this Tempcheck phase!\n\n492. Proposal: Deprecate Aave V3 Scroll Instance (Onchain)\n\nVote: For\nRationale: With liquidity and TVL on Scroll declining significantly, offboarding this instance is a sensible risk management step. Voted yes!\n\n493. Proposal: Onboard PT-USDG 28MAY2026 on V3 Core (Onchain)\n\nVote: For\n\nRationale: This adds dollar-based asset (USDG from Paxos) that already has real usage on Pendle Finance.\nA simple way to expand collateral options and let users unlock liquidity from existing positions. Voted yes!\n\n494. Proposal: Onboard USDe to the Aave V3 MegaETH Instance (Onchain)\n\nVote: For\nRationale: Adding USDe to Aave V3 MegaETH expands the stablecoin market with a proven asset and maintaining prudent risk controls through E-Mode restrictions. Voted yes!\n\n495. Proposal: Upgrade Aave instances to v3.7 Part 1 (Onchain)\n\nVote: For\nRationale: For. A clean upgrade that simplifies the protocol and improves maintainability.\n\n496. Proposal: GHO Inclusion into E-Modes on Aave V3 Plasma (Onchain)\n\nVote: For\nRationale: Adding GHO as a borrowable asset in these E-Modes strengthens its integration without introducing new collateral risk or changing core parameters.\n\n 13 days later\n\n post by Ignas on May 7\n\n Ignas\n\n Orbit-Delegate\n\n 497. Proposal: April Funding Update (Onchain)\n\nVote: For\nRationale: Voting yes on April Funding Update. This keeps funds organized, maintains runway, and makes sure incentives, audits, and ops can continue effectively.\n\n498. Proposal: Onboard USDe to the Aave V3 MegaETH Instance (Onchain)\n\nVote: For\n\nRationale: The propopsal adds a high demand asset and unlocks yield looping on MegaETH. Risk is contained through E Mode restrictions and conservative caps.\nI support the proposal!\n\n499. Proposal: [ARFC] Pause AAVE Buybacks (Snapshot)\n\nVote: For\n\nRationale: I support the proposal.\nRisk control should come first. Preserving treasury assets and maintaining flexibility is more important than continuing buybacks while uncertainty remains.\nStrengthening the DAO’s financial position now will better support confidence and long term resilience.\n\n500. Proposal: [ARFC] rsETH Incident Funding Update (Snapshot)\n\nVote: For\n\nRationale: Using part of the treasury to help resolve the rsETH shortfall can protect affected Aave markets, reduce broader contagion risk, and reinforce user confidence.\nSupport!\n\n501. Proposal: rsETH Incident: Liquidate rsETH attacker positions (Onchain)\n\nVote: For\nRationale: A very necessary risk containment step following the incident. Liquidation is the cleanest way to lock funds, limit bad debt, and move assets under DAO control for recovery. I support the proposal!\n\n502. Proposal: Orderly Transition and Offboarding Plan for Chaos Labs (Onchain)\n\nVote: For\n\nRationale: This proposal formalizes a smooth handoff to LlamaRisk, ensuring continuity while keeping the offboarding clean and time bound.\nAppreciate all the work Chaos Labs has done for Aave.\n\n503. Proposal: Winding Down the LEND Migration Contract (Onchain)\n\nVote: For\nRationale: I support this proposal as a necessary and long overdue cleanup of legacy infrastructure.\n\n post by Ignas on May 14\n\n Ignas\n\n Orbit-Delegate\n\n 504. Proposal: [ARFC] Aave Protocol Bug Bounty Programs Restructure (Snapshot)\n\nVote: For\n\nRationale: Splitting bug bounties by subsystem better reflects Aave’s complexity and improves clarity for researchers.\nAligning rewards with risk, especially increasing critical payouts is necessary to attract top talent. I support the proposal!\n\n505. Proposal: [ARFC] Renew LlamaRisk as Risk Service Provider - epoch 4 (Snapshot)\n\nVote: For\nRationale: Appreciate LlamaRisk stepping in to ensure continuity during a critical transition, as well as the focus on building verifiable, DAO controlled risk infrastructure. I support the proposal!\n\n506. Proposal: rsETH Incident: WETH LTV Restoration Across V3 Instances (Onchain)\n\nVote: For\n\nRationale: Voting For on Restore WETH LTV Across Aave V3 Instances!\nRecovery is effectively complete. 95% of unbacked rsETH recovered, attacker positions liquidated, and binding commitments in place for the remainder.\n\n507. Proposal: Add CoW Swap Adapters to flashBorrowers (Onchain)\n\nVote: For\nRationale: This is a simple tradeoff, drop a negligible fee, keep users from routing elsewhere.\nBetter swap execution means more activity stays inside Aave, where protocol revenue actually comes from. Voted yes!\n\n508. Proposal: sGho Launch (Onchain)\n\nVote: For\n\nRationale: Voting yes with the same reason on Snapshot. This upgrade turns sGHO into a clean, native yield primitive.\nThe fixed 4.25% rate is competitive, the migration design is well structured to drive adoption.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Kpk Delegate Platform\n\n Delegate Platforms\n\n 117\n\n 10.4k\n\n Nov 2025\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n Phenk53.eth Delegate Platform\n\n Delegate Platforms\n\n 13\n\n 746\n\n Jan 9\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10","tokens":4530,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264616231,"hash":"7cdd063acf13c1ed6f74ee27bcaff9b5c8d90a0e"}
{"url":"https://docs.soliditylang.org/en/develop/resources.html","domain":"docs.soliditylang.org","title":"Resources — Solidity 0.8.38-develop documentation","text":"Resources\n\n Edit on GitHub\n\nResources\n\nGeneral Resources\n\nEthereum.org Developers page\nEthereum StackExchange\nSolidity website\nSolidity changelog\nSolidity codebase on GitHub\nSolidity language users chat\nSolidity compiler developers chat\nawesome-solidity\nSolidity by Example\nSolidity documentation community translations\nSolidity and Smart Contract Glossary\n\nIntegrated (Ethereum) Development Environments\n\nApeA Python-based web3 development tool for compiling, testing, and interacting with smart contracts.\n\nBrownieA Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.\n💡 Note: As per the official docs, Brownie is no longer actively maintained.\nFuture releases may come sporadically - or never at all.\nCheck out Ape Framework (first in list) for all your python Ethereum development needs.\n\nDappTool for building, testing and deploying smart contracts from the command-line.\n\nFoundryFast, portable and modular toolkit for Ethereum application development written in Rust.\n\nHardhatEthereum development environment with local Ethereum network, debugging features and plugin ecosystem.\n\nRemixBrowser-based IDE with integrated compiler and Solidity runtime environment without server-side components.\n\nTruffleEthereum development framework.\n💡 Note: Consensys announced the sunset of Truffle on September 21, 2023.\nCurrent users may check out the migration path and available product support here.\n\nEditor Integrations\n\nEmacs\n\nEmacs SolidityPlugin for the Emacs editor providing syntax highlighting and compilation error reporting.\n\nIntelliJ\n\nIntelliJ IDEA pluginSolidity plugin for IntelliJ IDEA (and all other JetBrains IDEs).\n\nSublime Text\n\nPackage for SublimeText - Solidity language syntaxSolidity syntax highlighting for SublimeText editor.\n\nVim\n\nVim Solidity by ThesisSyntax highlighting for Solidity in Vim.\n\nVim Solidity by TovarishFinVim syntax file for Solidity.\n\nVim SyntasticPlugin for the Vim editor providing compile checking.\n\nVisual Studio Code (VS Code)\n\nAderyn Visual Studio Code extensionSolidity Smart contract analyzer designed to help find vulnerabilities. It supports projects built with Hardhat, Foundry, or any custom framework.\n\nEthereum Remix Visual Studio Code extensionEthereum Remix extension pack for VS Code\n💡 Note: As per the official repository, this extension has been removed from the VSCODE marketplace and will be replaced by a dedicated stand-alone desktop application.\n\nSolidity Visual Studio Code extension, by Juan BlancoSolidity plugin for Microsoft Visual Studio Code that includes syntax highlighting and the Solidity compiler.\n\nSolidity Visual Studio Code extension, by Nomic FoundationSolidity and Hardhat support by the Hardhat team, including: syntax highlighting, jump to definition, renames, quick fixes and inline solc warnings and errors.\n\nSolidity Visual Auditor extensionAdds security centric syntax and semantic highlighting to Visual Studio Code.\n\nTruffle for VS CodeBuild, debug and deploy smart contracts on Ethereum and EVM-compatible blockchains.\n💡 Note: This extension has built-in support for the Truffle Suite which is being sunset.\nFor information on ongoing support, migration options and FAQs, visit the Consensys blog.\n\nSolidity Tools\n\nABI to Solidity interface converterA script for generating contract interfaces from the ABI of a smart contract.\n\nabi-to-solTool to generate Solidity interface source from a given ABI JSON.\n\nAderynCommand Line Tool that helps find vulnerabilities in Solidity smart contracts. It supports projects built with Hardhat, Foundry, or any custom framework.\n\nDoxityDocumentation Generator for Solidity.\n\nethdebugA standard debugging data format for smart contracts on Ethereum-compatible networks.\n\nEthlintLinter to identify and fix style and security issues in Solidity.\n\nevmdisEVM Disassembler that performs static analysis on the bytecode to provide a higher level of abstraction than raw EVM operations.\n\nEVM LabA collection of tools to interact with the EVM. The package includes a VM, Etherchain API, and a trace-viewer with gas cost display.\n\nhevmEVM debugger and symbolic execution engine.\n\nleaflethA documentation generator for Solidity smart-contracts.\n\nScaffold-ETH 2Forkable Ethereum development stack focused on fast product iterations.\n\nSlippyA simple and powerful linter for Solidity.\n\nsol2umlUnified Modeling Language (UML) class diagram generator for Solidity contracts.\n\nsolc-selectA script to quickly switch between Solidity compiler versions.\n\nSolidity prettier pluginA Prettier Plugin for Solidity.\n\nSolidity REPLTry Solidity instantly with a command-line Solidity console.\n\nsolgraphVisualize Solidity control flow and highlight potential security vulnerabilities.\n\nSolhintSolidity linter that provides security, style guide and best practice rules for smart contract validation.\n\nSourcifyDecentralized automated contract verification service and public repository of contract metadata.\n\nSūryaUtility tool for smart contract systems, offering a number of visual outputs and information about the contracts’ structure. Also supports querying the function call graph.\n\nUniversal MutatorA tool for mutation generation, with configurable rules and support for Solidity and Vyper.\n\nWakeA Python-based Solidity development and testing framework with built-in vulnerability detectors.\n\nThird-Party Solidity Parsers and Grammars\n\nSolidity Parser for JavaScriptA Solidity parser for JS built on top of a robust ANTLR4 grammar.","tokens":1374,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264637988,"hash":"4be5a15b32171b979cbcca3621240c305a4a4754"}
{"url":"https://ethresear.ch/t/octopus-contract-and-its-applications/","domain":"ethresear.ch","title":"Octopus Contract and its Applications - Cryptography - Ethereum Research","text":"Octopus Contract and its Applications \n\n Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 2\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n Dec 2023\n\n 1 / 18\n\n Dec 2023\n\n Apr 2024\n\n post by SoraSuegami on Dec 15, 2023\n\n SoraSuegami\n\n Authors: Sora Suegami, Leona Hioki\nThank Yi Sun, Justin Drake, and Aayush Gupta for feedback and discussions.\nOur full paper is here: Octopus Contract and its Applications\nTL;DR\nWe propose the concept of Octopus contracts, smart contracts that operate ciphertexts outside the blockchain. Octopus contracts can control the decryption of the ciphertexts based on on-chain conditions by requesting validators to sign the specified messages. Signature-based witness encryption (SWE) enables users to decrypt them with the signatures. Moreover, Octopus contracts can evaluate arbitrary functions on encrypted inputs with one-time programs built from SWE and garbled circuits. These features extend the functionality of smart contracts beyond the blockchain, providing practical solutions for unresolved problems such as a trustless bridge for a two-way peg between Bitcoin and Ethereum, private AMM, minimal anti-collusion infrastructure without a centralized operator, and achieving new applications such as private and unique human ID with proof of attribution, private computation with web data, and more.\n1 Background and Our Contribution\nRegarding the aspect of using smart contracts to operate secrets outside the blockchain, our scheme is fundamentally a generalization of the author’s previous work Trustless Bitcoin Bridge with Witness Encryption (Leona Hioki), which also provides a practical construction of the previous work.\nCompared to existing schemes to allow smart contracts to operate ciphertexts using new cryptographic schemes, e.g., Lit protocol with threshold encryption, smart contracts with secret sharing multi-party computation (MPC), and smartFHE with fully homomorphic encryption (FHE), our scheme with SWE requires minimum modification to the node implementation of the validators. This is because the validators only need to sign the message specified by the Octopus contract and encrypt this signature with public-key encryption (PKE). Especially, when a circuit of the function is privately evaluated with one-time programs (OTPs), the validators’ computational cost only depends on the input size of the circuit, independent of the circuit size. Besides, while both FHE-based schemes and our scheme can delegate heavy evaluation of the circuit to an untrusted third party, the latter is estimated to be faster than the former because the delegated party in the latter just decrypts the SWE encryptions of the garbled inputs and evaluates a garbled circuit, which only employs a hash function and bit operations in the optimal construction.\nThe validators’ work in vetKeys is similar to ours: the validators generate BLS signatures for an ID and encrypt the signatures under the user’s public key to pass the user a private key of that ID in ID-based encryption. However, it is our novel point to use the signatures for the private evaluation of functions on encrypted inputs.\nDespite the above advantages of our scheme, the Octopus contract using OTPs further relies on rabble MPC, n𝑛-of-n𝑛 MPC among randomly selected people who are different from the validators. It is used to generate an OTP while embedding a private key unknown to humans in the evaluated circuit. The rabble MPC is more secure and feasible than existing MPC-based schemes for the following reasons:\n\nIf at least one participant is honest, the MPC is secure, i.e., revealing no information other than the OTP.\nEven if the MPC fails because some participants leave the MPC, different participants can start new MPCs any number of times. Also, many MPCs can be performed in parallel.\nOnce the OTP is generated, there is nothing more for the MPC participant to do.\n\nThe following table summarizes the comparison between our scheme and the existing schemes.\nComparison_ours_existing960×540 80.4 KB\n2 Signature-based Witness Encryption\n2.1 Definition of SWE\nWe adopt a SWE scheme defined for t𝑡-out-of-n𝑛 BLS signatures. It provides the following algorithms. While they are based on Definition 1 of McFly, some inputs are omitted or modified.\n\n\\textsf{ct} \\leftarrow \\textsf{SWE.Enc}(V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n), h, m)𝖼𝗍 ←𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛),ℎ,𝑚): it takes as input a set V𝑉 of n𝑛 BLS verification keys, a hash hℎ of a signing target T𝑇, and a message to be encrypted m𝑚. It outputs a ciphertext \\textsf{ct}𝖼𝗍.\nm \\leftarrow \\textsf{SWE.Dec}(\\textsf{ct}, \\sigma, U, V)𝑚 ←𝖲𝖶𝖤.𝖣𝖾𝖼(𝖼𝗍,𝜎,𝑈,𝑉): it takes as input a ciphertext \\textsf{ct}𝖼𝗍, an aggregate signature \\sigma𝜎, two sets U, V𝑈,𝑉 of BLS verification keys. It outputs a decrypted message m𝑚 or the symbol \\perp⟂.\n\nIf more than or equal to t𝑡 validators of which verification keys are in V𝑉, i.e., |U| \\geq t|𝑈| ≥𝑡 and U \\subseteq V𝑈 ⊆𝑉, generate a valid aggregated signature \\sigma𝜎 for the hash hℎ, the correctness holds, i.e., \\textsf{SWE.Dec}(\\textsf{SWE.Enc}(V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n), h, m), \\sigma, U, V) = m𝖲𝖶𝖤.𝖣𝖾𝖼(𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛),ℎ,𝑚),𝜎,𝑈,𝑉) =𝑚. Otherwise, the \\textsf{SWE.Dec}𝖲𝖶𝖤.𝖣𝖾𝖼 algorithm returns the symbol \\perp⟂. Therefore, once the validators release the signature \\sigma𝜎, anyone can decrypt the ciphertext \\textsf{ct}𝖼𝗍.\n2.2 Access-Control of the Signature\nWe use the same technique as vetKeys to control who will be able to decrypt the ciphertext by encrypting the validators’ signatures. Specifically, when a legitimate decryptor provides a public key \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒 of the PKE scheme, each validator publishes an encryption \\textsf{ct}_{\\sigma_i}𝖼𝗍𝜎𝑖 of the signature \\sigma_i𝜎𝑖 under \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒, i.e., \\textsf{ct}_{\\sigma_i} \\leftarrow \\textsf{PKE.Enc}(\\textsf{pubKey}, \\sigma_i)𝖼𝗍𝜎𝑖 ←𝖯𝖪𝖤.𝖤𝗇𝖼(𝗉𝗎𝖻𝖪𝖾𝗒,𝜎𝑖). That decryptor can recover the message by decrypting each \\textsf{ct}_{\\sigma_i}𝖼𝗍𝜎𝑖 with the private key \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒 corresponding to the \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒, aggregating the recovered signatures into \\sigma_{\\Sigma}𝜎Σ, and decrypting the ciphertext under SWE by \\sigma_{\\Sigma}𝜎Σ. However, the other users cannot do that because they cannot obtain \\sigma_{\\Sigma}𝜎Σ from \\textsf{ct}_{\\sigma}𝖼𝗍𝜎 without \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒. Besides, even the validators cannot decrypt them as long as their honest majority does not reveal each signature \\sigma_i𝜎𝑖.\nAs proposed in vetKeys, if the PKE scheme is additive-homomorphic, e.g., EC-ElGamal encryption, the decryptor can first compute the encryption of the aggregated signature by computing the weighted sum of the encrypted signatures and then decrypt only the aggregated one. By outsourcing that computation, the decryptor can reduce the computation cost.\n2.3 Estimated Benchmark of SWE\nWe estimate a benchmark of the SWE scheme based on McFly assuming a threshold \\frac{t}{n}=\\frac{2}{3}𝑡𝑛 =23. For n=500𝑛 =500 and n=2000𝑛 =2000, encryption takes approximately 10 and 60 seconds, and decryption takes around 20 and 350 seconds, respectively. These results suggest the appropriate number of allocated validators for each use case. They also imply that more improvement in the SWE scheme will enhance the security of ciphertexts, i.e., increasing the number of allocated validators, without sacrificing the performance.\n3 Octopus Contract\nIn our scheme, the Octopus contract helps users request the Ethereum validators to sign a specific message for the SWE decryption. Specifically, they work as follows.\n\nFirstly, some validators register with and watch the Octopus contract made by an application developer.\nAn encryptor, the user willing to encrypt a message using SWE, calls the Octopus contract to register a signing target T𝑇.\nThe Octopus contract records the hash h:=\\textsf{Hash}(\\textsf{PREFIX}, T)ℎ :=𝖧𝖺𝗌𝗁(𝖯𝖱𝖤𝖥𝖨𝖷,𝑇) derived from T𝑇. Note that \\textsf{PREFIX}𝖯𝖱𝖤𝖥𝖨𝖷 is a fixed unique string, which prevents the validators from signing messages for the Ethereum consensus algorithm.\nThe encryptor generates an encryption \\textsf{ct}𝖼𝗍 of the messages m𝑚 under the hash hℎ and n𝑛 validators’ verification keys V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n)𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛) allocated by the Octopus contract.\nA decryptor, a user willing to decrypt \\textsf{ct}𝖼𝗍, has a PKE key pair (\\textsf{privKey}, \\textsf{pubKey})(𝗉𝗋𝗂𝗏𝖪𝖾𝗒,𝗉𝗎𝖻𝖪𝖾𝗒) and calls the Octopus contract, passing the hℎ and the PKE public key \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒 to request validators’ signatures.\nThe Octopus contract checks if the decryptor is legitimate based on the required on-chain conditions. If the decryptor does not pass the conditions, the contract rejects the decryptor’s request.\nMore than or equal to t𝑡 validators generate the encryption ct_{\\sigma}𝑐𝑡𝜎 of the aggregated signature \\sigma𝜎 for the hash hℎ in a way described in Subsection 2.2.\nThe validators provide the Octopus contract with the encryptions \\textsf{ct}_{\\sigma}𝖼𝗍𝜎 along with a proof \\pi𝜋 to prove that they are valid encryptions of the aggregated signatures.\nThe decryptor first decrypts \\textsf{ct}_{\\sigma}𝖼𝗍𝜎 with \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒 to obtain the signature \\sigma𝜎, and then decrypts \\textsf{ct}𝖼𝗍 with \\sigma𝜎 to recover the messages m𝑚.\n\nIn this way, the encryptor can encrypt messages under some on-chain state conditions without knowing who satisfies the conditions in the future. As long as more than or equal to the threshold of the validators behave honestly, i.e., sign only the message confirmed by the Octopus contract, only the legitimate decryptor can decrypt the ciphertext.\nWhen implementing our scheme, we can prepare a shared smart contract for common management of the registered validators and requests for signatures. Each application contract specifies the signing messages and checks if the decryptor is legitimate.\nIts application is described in Subsection 3.1 in the full paper.\n4 One-Time Program with Octopus Contract\n4.1 Basic Ideas\nThe Octopus contract with SWE described above has the following limitations.\n\nThe ciphertext must be decrypted in a rather short time because the validators that can generate signatures for the decryption are fixed at the time of encryption.\nIt is impossible to apply some functions to the encrypted message m𝑚 without revealing it to the decryptor.\n\nWe solve them by introducing OTPs. The OTP is an encoded circuit that can be evaluated on at most one input. Goyal constructs a blockchain-based one-time program (BOTP) from witness encryption (WE) and garbled circuits. A generator of BOTP makes a garbled circuit of the circuit and encrypts its garbled inputs under WE. Its evaluator can decrypt each encryption of the garbled input for the bit b \\in \\{0,1\\}𝑏 ∈{0,1} of the i𝑖-th input bit by committing b𝑏 as the i𝑖-th input bit on-chain. Subsequently, the decryptor evaluates the garbled circuit with the recovered garbled inputs. The decryptor can input only one bit b𝑏 for each input bit to the circuit because the decryption condition of WE requires the decryptor to prove that b𝑏 is committed first to the blockchain finalized by the honest majority of validators. In other words, the decryptor cannot input 1-b1 −𝑏 without tampering with the finalized block containing the commitment of b𝑏.\nWhile the OTP has the limitation of one-time input, it has a useful security feature that the evaluator cannot learn non-trivial information about the circuit. Therefore, the generator can embed secret data and algorithms in the circuit of the OTP. Moreover, if multiple generators use n𝑛-of-n𝑛 MPC, which we call rabble MPC, to generate a private key, embed it in the circuit, and output its OTP, the OTP can hold a private key that no human knows as long as at least one MPC participant and the honest majority of the validators are honest. It can be used to decrypt the encryption of the circuit input and sign the circuit output inside the circuit. For example, the OTP with the embedded private key allows us to bootstrap a SWE ciphertext, i.e., encrypting the same message under a different set of verifying keys. The OTP for the SWE bootstrap decrypts the encrypted signature with the private key, uses the signature to recover the message from the SWE ciphertext, and encrypts the same message under new verifying keys. We can generalize this approach to evaluate arbitrary functions on encrypted inputs.\n4.2 One-time program based on SWE\nInstead of existing WE constructions supporting general decryption conditions, which are impractical or depend on heuristics cryptographic assumptions, we adopt SWE to build OTPs. Let k_{i,b}𝑘𝑖,𝑏 and \\widetilde{C}̃𝐶 be a garbled input for the bit b𝑏 of the i𝑖-th input bit and a garbled circuit of the input size |x||𝑥|, respectively. The generator, the evaluator, and the Octopus contract managing \\widetilde{C}̃𝐶 collaborate as below:\n\nThe generator registers 2|x|2|𝑥| signing targets \\{(i,b)\\}_{i \\in [|x|], b \\in \\{0,1\\}} = \\{(1,0), (1,1), \\dots, (|x|,0), (|x|,1)\\}{(𝑖,𝑏)}𝑖∈[|𝑥|],𝑏∈{0,1} ={(1,0),(1,1),…,(|𝑥|,0),(|𝑥|,1)} with the Octopus contract.\nThe Octopus contract records 2|x|2|𝑥| hashes \\{h_{i,b}=\\textsf{Hash}(\\textsf{PREFIX}, (i,b))\\}_{i \\in [|x|], b \\in \\{0,1\\}}{ℎ𝑖,𝑏 =𝖧𝖺𝗌𝗁(𝖯𝖱𝖤𝖥𝖨𝖷,(𝑖,𝑏))}𝑖∈[|𝑥|],𝑏∈{0,1} and allocates n𝑛 validators of which the verification keys are V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n)𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛).\nThe generator generates a garbled circuit \\widetilde{C}̃𝐶 and its garbled inputs \\{k_{i,b}\\}_{i \\in [|x|], b \\in \\{0,1\\}}{𝑘𝑖,𝑏}𝑖∈[|𝑥|],𝑏∈{0,1}.\nFor each i \\in [|x|], b \\in \\{0,1\\}𝑖 ∈[|𝑥|],𝑏 ∈{0,1}, the generator encrypts k_{i,b}𝑘𝑖,𝑏 under V𝑉 and h_{i,b}ℎ𝑖,𝑏, i.e., ct_{i,b} \\leftarrow \\textsf{SWE.Enc}(V, h_{i,b}, k_{i,b})𝑐𝑡𝑖,𝑏 ←𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉,ℎ𝑖,𝑏,𝑘𝑖,𝑏).\nThe evaluator registers the input x𝑥 with the Octopus contract.\nThe Octopus contract checks if the other inputs have not been registered before. If so, it requests the allocated validators to sign the |x||𝑥| hashes \\{h_{i,x_i}\\}_{i \\in [|x|]}{ℎ𝑖,𝑥𝑖}𝑖∈[|𝑥|] without specifying a public key to encrypt the signatures.\nThe evaluator obtains aggregated signatures \\{\\sigma_{i}\\}_{i \\in [|x|]}{𝜎𝑖}𝑖∈[|𝑥|] and uses them to decrypt \\{ct_{i,x_i}\\}_{i \\in [|x|]}{𝑐𝑡𝑖,𝑥𝑖}𝑖∈[|𝑥|], i.e., k_{i,x_i} \\leftarrow \\textsf{SWE.Dec}(ct_{i,x_i}, \\sigma_{i}, U, V)𝑘𝑖,𝑥𝑖 ←𝖲𝖶𝖤.𝖣𝖾𝖼(𝑐𝑡𝑖,𝑥𝑖,𝜎𝑖,𝑈,𝑉).\nThe evaluator evaluates \\widetilde{C}̃𝐶 on \\{k_{i,x_i}\\}_{i \\in [|x|]}{𝑘𝑖,𝑥𝑖}𝑖∈[|𝑥|].\n\nNotably, in formal security proof, the garbled circuit is secure only against a selective adversary that chooses the input x𝑥 before seeing the garbled circuit \\widetilde{C}̃𝐶. However, as far as our knowledge, it does not mean that there is a practical attack on the garbled circuit scheme when x𝑥 is chosen adaptively. Besides, Yao’s garbled circuit without modification is proven to be adaptively secure if the circuit is an NC1 circuit, i.e., a low-depth circuit. To bootstrap it to a polynomial-sized circuit, we may be able to use a similar technique in this paper that bootstraps an indistinguishability obfuscation of NC1 circuits with a randomized encoding such as Yao’s garbled circuit.\n4.3 Rabble MPC for Key-Embedded OTPs\nOTPs of key-embedded circuits are generated through the rabble MPC, n𝑛-of-n𝑛 MPC among randomly selected people. The Octopus contract manages the participants of the rabble MPC and randomly assigns their subset to each generation of the OTP. These participants are different from the validators, and the Octopus contract can require a lower stake to participate in the rabble MPC than that of validators.\nAfter registering the signing targets with the Octopus contract as described above, the selected n𝑛 participants perform the n𝑛-of-n𝑛 MPC to privately generate a new OTP for a circuit C𝐶 taking s𝑠 inputs as follows:\n\nEach participant provides the randomness r_i𝑟𝑖 as input.\nThey derive private and public keys (\\textsf{privKey}, \\textsf{pubKey})(𝗉𝗋𝗂𝗏𝖪𝖾𝗒,𝗉𝗎𝖻𝖪𝖾𝗒) from the XOR of all randomnesses \\bigoplus_{i=1}^n r_i⨁𝑛𝑖=1𝑟𝑖. These keys are assumed to be usable for both PKE and digital signature schemes.\nThey construct a key-embedded circuit C[\\textsf{privKey}]𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒] that takes s𝑠 encryptions of inputs (ct_{x_1}, \\dots, ct_{x_s})(𝑐𝑡𝑥1,…,𝑐𝑡𝑥𝑠) under \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒, decrypts them with \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒, provides the s𝑠 inputs (x_1, \\dots, x_s)(𝑥1,…,𝑥𝑠) for C𝐶, signs the output y=C(x_1, \\dots, x_s)𝑦 =𝐶(𝑥1,…,𝑥𝑠) with \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒, and outputs y𝑦 and the signature \\sigma_{\\textsf{otp}}𝜎𝗈𝗍𝗉. Let u𝑢 be the input bits size of C[\\textsf{privKey}]𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒].\nThey generate a garbled circuit of C[\\textsf{privKey}]𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒] denoted by \\widetilde{C[\\textsf{privKey}]}̃𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒] and its garbled inputs \\{k_{i,b}\\}_{i \\in [u], b \\in \\{0,1\\}}{𝑘𝑖,𝑏}𝑖∈[𝑢],𝑏∈{0,1}.\nThey encrypt each garbled input k_{i,b}𝑘𝑖,𝑏 under the allocated validators’ verification keys V𝑉 and the hash h_{i,b}=\\textsf{Hash}(\\textsf{PREFIX}, (i,b))ℎ𝑖,𝑏 =𝖧𝖺𝗌𝗁(𝖯𝖱𝖤𝖥𝖨𝖷,(𝑖,𝑏)), i.e., ct_{i,b} \\leftarrow \\textsf{SWE.Enc}(V, h_{i,b}, k_{i,b})𝑐𝑡𝑖,𝑏 ←𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉,ℎ𝑖,𝑏,𝑘𝑖,𝑏).\nThey outputs the OTP (\\textsf{pubKey}, \\widetilde{C[\\textsf{privKey}]}, \\{ct_{i,b}\\}_{i \\in [u], b \\in \\{0,1\\}})(𝗉𝗎𝖻𝖪𝖾𝗒,̃𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒],{𝑐𝑡𝑖,𝑏}𝑖∈[𝑢],𝑏∈{0,1}).\n\nThe way of the SWE bootstrapping and the applications with OTP are described in Subsections 4.4 and 4.5 in the full paper.\n5 Selecting a Subset of Validators\nThere are several methods to select a validator set from the consensus layer of Ethereum as follows:\n\nHard fork Ethereum to force all validators to sign messages from Octopus contracts.\nSoft fork Ethereum, allowing any validators to sign messages from Octopus contracts.\nUse a re-staking mechanism such as Eigen Layer, enabling validators to have dual roles.\n\nEven in the first case, which imposes the greatest burden on the Ethereum network, the validators’ signatures for the same messages can be aggregated, so that the additional cost of pairing is at most for each ciphertext. However, in that case, we should note that security is not completely inherited because the validators cannot be penalized in the same way as in the case of double voting when they sign messages not specified by the Octopus contracts.\nIn the second and third cases, we can maintain the existing protocol of the consensus layer as the modification to the node implementation for our scheme is optimal in similar to MEV-related protocols. While the restaking in the third case is easy to introduce, the soft fork supported by many validators will improve the security of our scheme more significantly.\nApplications and the other notes\nThe on-chain conditions for the decryption in Octopus contracts can be implemented in Solidity. By customizing the conditions for each use case, we can build various novel applications, including a trustless bitcoin bridge, private AMM, and more. The OTP extends the application of the Octopus contracts because their functionalities are almost equivalent to what TEEs can do, in particular verification of computations by private conditions, private unique human IDs with proof of attributions, and private computation with web data. They are described in our full paper.\nRead our full paper here: Octopus Contract and its Applications\nSora Suegami wrote the sections about the idea of using OTPs for private function evaluation and its applications. Leona Hioki wrote the sections about a trustless bitcoin bridge and private AMM. The other sections are written together.\n\n Privacy preserving nullifiers for proof of identity applications\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n 6\n\n 2\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n post by sg on Dec 16, 2023\n\n sg\n\n Okay so my takeaways and rephrasal for further discussion below.\n\nThe Octopus Contract receives and stores ciphertext as input.\n\nThe logic described in the smart contract determines the entity that can decrypt the ciphertext.\n\nThe information required for decryption is a threshold signature by the validators that comprise the consensus layer. This mechanism is called SWE and is based on the honest majority assumption. Those signers are fixed at encryption timing without One-time Programs (OTPs).\n\nThe method for securely returning signatures to a qualifying sender is on-chain public key cryptography.\n\nUnlike the method using FHE, the validator only needs to pay the computational cost of the threshold signature, and the computational cost of the decryption process is paid by the sender, which is novel.\n\nWith OTPs, ciphertext (such as encrypted private key) could be used for generating a signature to run a new tx without revealing that key. (It can be a shared account of different blockchain, etc.)\n\nIn chapter 5, several L1 modification ideas.\n\nI would like to ask a question.\n\nIn chapter 4 section 2 “One-time Program with SWE”, the evaluator seems to be trusted. Could you tell me his plausible assumption for security?\n\n post by SoraSuegami on Dec 16, 2023\n\n SoraSuegami\n\n Thank you for your questions!\n\nThe Octopus Contract receives and stores ciphertext as input.\n\nYes.\nHowever, the encryptor does not necessarily store the ciphertext on-chain in applications that ensure the availability of the ciphertext in any other way.\n\nThe logic described in the smart contract determines the entity that can decrypt the ciphertext.\n\nYes. Its interesting point is that the encryptor does not need to specify the decryptor in advance.\n\nThe information required for decryption is a threshold signature by the validators that comprise the consensus layer. This mechanism is called SWE and is based on the honest majority assumption. Those signers are fixed at encryption timing without One-time Programs (OTPs).\n\nYes.\n\nThe method for securely returning signatures to a qualifying sender is on-chain public key cryptography.\n\nYes, the decryptor just specifies a public key, and the validators return encryptions of the signature under the public key.\n\nUnlike the method using FHE, the validator only needs to pay the computational cost of the threshold signature, and the computational cost of the decryption process is paid by the sender, which is novel.\n\nThe validators in our scheme only need to generate the threshold signature to help the evaluation of OTPs.\nHowever, the validators in multi-key FHE can also delegate a heavy evaluation of which computational cost depends on the circuit size to an untrusted party, i.e., the evaluator.\nWe can estimate that the computational cost in our scheme is cheaper than that in the FHE-based schemes.\nThe detail is described in Section 1 of our full paper.\n\nWith OTPs, ciphertext (such as encrypted private key) could be used for generating a signature to run a new tx without revealing that key. (It can be a shared account of different blockchain, etc.)\n\nWe assume the key-embedded circuit always outputs a signature for the circuit output. The encryptions of garbled inputs under SWE are used to evaluate the garbled circuit, which outputs the circuit output and its signature, without revealing the embedded private key.\n\nIn chapter 5, several L1 modification ideas.\n\nYes, we present multiple ways to modify the node implementation of the validators for our scheme.\n\nIn chapter 4 section 2 “One-time Program with SWE”, the evaluator seems to be trusted. Could you tell me his plausible assumption for security?\n\nThere is no assumption about the evaluator because the evaluator cannot learn any information in the circuit, e.g., the embedded private key.\nWhat makes you think that the evaluator is trusted?\n\n post by sg on Dec 16, 2023\n\n sg\n\n Thanks to your feedback, I learned what the garbled circuit and the evaluator are. Seems legit \n\n post by tkmct on Dec 17, 2023\n\n tkmct\n\n PREFIX of a hash is open to the public? Then, an evaluator’s input to the OTP has to be made public?\n\n post by SoraSuegami on Dec 17, 2023\n\n SoraSuegami\n\n Thank you for your questions!\n\nPREFIX of a hash is open to the public?\n\nYes.\n\nThen, an evaluator’s input to the OTP has to be made public?\n\nNo, they are encrypted under a public key of the private key embedded in the circuit of the OTP.\nThe description in Subsection 4.2 handles OTPs for general circuits and the inputs are directly recorded on-chain.\nHowever, our actual construction in Subsection 4.3 only assumes OTPs for the key-embedded circuits, which decrypt the encrypted inputs with the embedded private keys.\nTherefore, even if the circuit inputs to the key-embedded circuits, i.e., the encrypted inputs, are public, the actual inputs are kept private.\n\n post by tkmct on Dec 17, 2023\n\n tkmct\n\n Thank you for your answer!\nSo, does the evaluator commit to encrypted inputs on-chain? How does this process work in detail?\nI assume that even though the evaluator’s input (represented as a series of bits) is encrypted under pubKey of embedded GC, each input bit can be easily guessed because possible ciphertexts are either encryption of 0 or 1. This is why I asked if PREFIX is public, so that anyone can calculate the hash of evaluator’s inputs.\n\n post by maniou-T on Dec 18, 2023\n\n maniou-T\n\n What is the role of the rabble MPC (n-of-n MPC among randomly selected participants) in the generation of One-Time Programs (OTPs) with key-embedded circuits, and how does it contribute to the security of the proposed scheme?\n\n post by SoraSuegami on Dec 18, 2023\n\n SoraSuegami\n\nSo, does the evaluator commit to encrypted inputs on-chain? How does this process work in detail?\n\nYes. Specifically, the evaluator encrypts the input x𝑥 under a public key \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒 of the private key embedded in the circuit and commits each bit ct_x[i]𝑐𝑡𝑥[𝑖] of the ciphertext ct_x𝑐𝑡𝑥.\nIf no encrypt input has been committed on-chain, the contract requests validators to sign a signing target (i, ct_x[i])(𝑖,𝑐𝑡𝑥[𝑖]) for each i𝑖.\nThe validators’ signature for (i, ct_x[i])(𝑖,𝑐𝑡𝑥[𝑖]) will allow the evaluator to decrypt the SWE encryption of the i𝑖-th garbled input for the bit ct_x[i]𝑐𝑡𝑥[𝑖], which is generated at the generation of OTP.\n\neach input bit can be easily guessed because possible ciphertexts are either encryption of 0 or 1.\n\nThis is not true.\nFor example, if the circuit only takes input from one party, the ciphertext will be the encryption of the entire input bits.\nEven if the encrypted input is just an encryption of one bit, I think the adversary cannot predict which bit is encrypted as long as the PKE scheme is IND-CPA secure.\n\n post by SoraSuegami on Dec 18, 2023\n\n SoraSuegami\n\n maniou-T\n\n Thank you for your question!\n\nWhat is the role of the rabble MPC\n\nIn short, the role of rabble MPC is a trusted generation of the OTP of the key-embedded circuit.\nSpecifically, it first generates a private key unknown to any participants, then embeds the key into a circuit, and finally outputs only the OTP, i.e., a garbled circuit, SWE encryptions of garbled inputs, and a public key of the embedded private key.\n\nhow does it contribute to the security of the proposed scheme?\n\nAs long as at least one participant in the rabble MPC (and the honest majority of the validators) is honest, i.e., not revealing intermediate values in the MPC, the Octopus contract can assume that the embedded private key is unknown to anybody and can be used only according to the logic of the key-embedded circuit, similar to the private key in an enclave of TEE.\n\n post by leohio on Dec 21, 2023\n\n leohio\n\n There were 2 questions for me, and seems that I need to follow them.\n\nShould we make a bigger size of validator sets to make SWE secure?\n\nAttackers in the validator set can collude to decrypt the SWE ciphertexts without the smart contract execution. But one of the colluders will be rewarded for revealing that activity to make them slashed.\nIf in such a condition, even trying that is dangerous for them.\nBut the size of validators matters of course, and the best case is all the Ethereum validators.\n\nWhat kind of data is private in the section of Private AMM?\n\nOnly the transactor can see the AMM pool when they send the tokens to swap.\nDeposits and withdrawals are with token transfers in a private manner operated by the other services.\nIn the trusted setup, an MPC process is required not to let the last person know the address to make 1/N secret assumption of privacy, otherwise, the last person can see a part of the pool (one deposit address). If you fully trust the trusted setup, the last person only has to forget the pool after making the SWE ciphertext.\nAs it describes, only a person who swaps tokens can see the pool temporarily and the pool gets changed after the transaction. So this AMM is somehow hard to trace activities as a semi-private AMM.\n\n 21 days later\n\n post by turboblitz on Jan 11, 2024\n\n turboblitz\n\n Great paper!\nStill trying to wrap my head around the OTP part.\nFor the trustless bitcoin bridge section, I have a question. Let’s consider a simpler design without WE, a traditional multisig bridge on top of eigenlayer:\n\nA user deposits btc to the multisig address controlled by the nodes.\nHe proves transaction on ethereum with a light client bridge, mints tBTC.\nWhen he wants to withdraw, burns tBTC specifying a BTC withdrawal address\nEach node signs a transaction that sends the correct amount of btc to the withdrawal address specified by the user.\n\nIf a node signs a transaction but no request has been made, it can be proven and slashed on ethereum, so 1/N trust assumption. Also, this allows for arbitrary amounts.\nDoes the octopus contract improve on this scheme ?\n\n post by leohio on Jan 14, 2024\n\n leohio\n\n Even if you can slash the person, the majority of that multi-sig can steal the fund, so it’s the majority assumption, not 1/N.\nIn this case, the 1/N assumption is just for the trusted setup, and the majority assumption of validators. still remains. If you want the 1/N assumption, pls read here\n\n post by xiangxiecrypto on Jan 18, 2024\n\n xiangxiecrypto\n\n It is a very nice idea to use SWE to construct these applications. I have a few questions.\n\nAfaik the garbled circuit can not hide the information on the circuit itself, it only hides the inputs. If you want to embed secret information in the circuit, you probably need to use universal circuit?\nIn the key-embedded OTP constructions, you have to run an n-of-n MPC to securely compute all the SWE encryptions and garbling process? Do I understand correctly?\nYou mentioned that one can also use Octopus contract to delegate computation as FHE, can you explore it more? In the OTP construction, the evaluator has to compute the circuit anyway, right?\n\n 1 month later\n\n post by SoraSuegami on Feb 17, 2024\n\n SoraSuegami\n\n Sorry for the late response!\n\nAfaik the garbled circuit can not hide the information on the circuit itself, it only hides the inputs. If you want to embed secret information in the circuit, you probably need to use universal circuit?\n\nAs far as I understand, some garbled circuit schemes such as Yao’s garbled circuit hide the information on the circuit. Besides, if you use a scheme that does not hide the circuit, as you mentioned, you can use a universal circuit. In that case, the OTP generation process outputs only one-bit garbled input for each bit corresponding to the circuit, rather than encrypting garbled inputs for both bits under SWE. Therefore, this approach does not increase the number of signed messages.\nThis paper describes the circuit privacy of garbled circuits.\n\nIn the key-embedded OTP constructions, you have to run an n-of-n MPC to securely compute all the SWE encryptions and garbling process? Do I understand correctly?\n\nYes, that is correct!\nThe point is that the garbled circuit and the SWE encryptions of the garbled inputs should be generated without revealing the used randomness to anyone.\n\nYou mentioned that one can also use Octopus contract to delegate computation as FHE, can you explore it more?\n\nSorry for the confusion, we just compared the delegated evaluation of private circuits in our method with that of (multi-key) FHE.\n\nIn the OTP construction, the evaluator has to compute the circuit anyway, right?\n\nYes, the evaluator needs to evaluate a garbled circuit.\nHowever, we expect that this computational cost will be less than that of the FHE evaluation as described in Section 1 of our paper.\n\n 17 days later\n\n post by voidp on Mar 6, 2024\n\n voidp\n\n Interesting idea. I have two clarification questions:\nCan you say more about building “anti-collusion” protocols from Octopus smart contracts? Is there some special leverage to prevent/slash collusion that is infeasible in a more general threshold trust assumption? I.e., is an Octopus smart contract more resilient to collusion than, say, an MPC with a threshold assumption?\nSecond, is there implementation to play with?\n\n post by wyunhao on Mar 7, 2024\n\n wyunhao\n\n Hi there,\nThanks for sharing this interesting paper! I have some quick questions:\n\nGenerally, your idea is not using the “witness” part of SWE right? What you need is just a threshold signature scheme.\nRegarding the bootstrapping, it seems that the Octopus Contract needs the original set of validators V to be online and provide the contract their aggregated signing key; also, the new set of validators should also be online to do their job, is my understanding correct?\nFollowing the above question, is it the case that in all applications, the original set of validators V need to be there when someone wants to evaluate/decrypt the ciphertexts “encrypted” under V? For example, in trustless bitcoin bridge case, all “signers” (which is actually the trusted-setup nodes) needs to provide the decryption of ciphertexts.\n\nLastly, it would be appreciated to see the evaluation of a concrete implementation. Could you please kindly share some information about your roadmap on this project?\n\n 1 month later\n\n post by wooju on Apr 8, 2024\n\n wooju\n\n Based on the SWE reference you provided, I understand that for an input message x, the SWE ciphertext consists of (2*|x|) target group elements + (2*n + 3) elements (where n is the number of keygen participants) from a group where pairing operation is defined. In this case, it seems that the length of the ciphertext would be very long… Is this also data that needs to be stored somewhere? How can the evaluator obtain this value?\n\n Powered by Discourse","tokens":8669,"squid":"ink-research","role":"Deep Scholar","at":1791264641087,"hash":"867f79ac88290fd49be250ca7958916168c49ae7"}
{"url":"https://forum.openzeppelin.com/t/95-5000-resultados-de-traduccion-my-crowdsale-receives-the-payment-in-ether-in-my-wallet-but-does-not-send-my-erc20-token-to-whoever-buys/10351/2","domain":"forum.openzeppelin.com","title":"95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys - Support - OpenZeppelin Forum","text":"Support\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2021\n\n 2 / 2\n\n Feb 2022\n\n Feb 2022\n\n post by forestheart on Jun 11, 2021\n\n forestheart\n\n 219 / 5000\nHello community, this is the crowdsale contract, I would really appreciate if you help me know why when I send ether to the crowdsale address it sends the payment to my wallet but it does not send my tokens in return\n0x8cc4956482e2781E19c/**\n *Submitted for verification at polygonscan.com on 2021-06-11\n*/\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/utils/ReentrancyGuard.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @dev Contract module that helps prevent reentrant calls to a function.\n *\n * Inheriting from `ReentrancyGuard` will make the {nonReentrant} modifier\n * available, which can be applied to functions to make sure there are no nested\n * (reentrant) calls to them.\n *\n * Note that because there is a single `nonReentrant` guard, functions marked as\n * `nonReentrant` may not call one another. This can be worked around by making\n * those functions `private`, and then adding `external` `nonReentrant` entry\n * points to them.\n *\n * TIP: If you would like to learn more about reentrancy and alternative ways\n * to protect against it, check out our blog post\n * https://blog.openzeppelin.com/reentrancy-after-istanbul/[Reentrancy After Istanbul].\n *\n * _Since v2.5.0:_ this module is now much more gas efficient, given net gas\n * metering changes introduced in the Istanbul hardfork.\n */\ncontract ReentrancyGuard {\n bool private _notEntered;\n\n constructor () internal {\n // Storing an initial non-zero value makes deployment a bit more\n // expensive, but in exchange the refund on every call to nonReentrant\n // will be lower in amount. Since refunds are capped to a percetange of\n // the total transaction's gas, it is best to keep them low in cases\n // like this one, to increase the likelihood of the full refund coming\n // into effect.\n _notEntered = true;\n }\n\n /**\n * @dev Prevents a contract from calling itself, directly or indirectly.\n * Calling a `nonReentrant` function from another `nonReentrant`\n * function is not supported. It is possible to prevent this from happening\n * by making the `nonReentrant` function external, and make it call a\n * `private` function that does the actual work.\n */\n modifier nonReentrant() {\n // On the first call to nonReentrant, _notEntered will be true\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n _notEntered = false;\n\n _;\n\n // By storing the original value once again, a refund is triggered (see\n // https://eips.ethereum.org/EIPS/eip-2200)\n _notEntered = true;\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/utils/Address.sol\n\npragma solidity ^0.5.5;\n\n/**\n * @dev Collection of functions related to the address type\n */\nlibrary Address {\n /**\n * @dev Returns true if `account` is a contract.\n *\n * [IMPORTANT]\n * ====\n * It is unsafe to assume that an address for which this function returns\n * false is an externally-owned account (EOA) and not a contract.\n *\n * Among others, `isContract` will return false for the following \n * types of addresses:\n *\n * - an externally-owned account\n * - a contract in construction\n * - an address where a contract will be created\n * - an address where a contract lived, but was destroyed\n * ====\n */\n function isContract(address account) internal view returns (bool) {\n // According to EIP-1052, 0x0 is the value returned for not-yet created accounts\n // and 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470 is returned\n // for accounts without code, i.e. `keccak256('')`\n bytes32 codehash;\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n // solhint-disable-next-line no-inline-assembly\n assembly { codehash := extcodehash(account) }\n return (codehash != accountHash && codehash != 0x0);\n }\n\n /**\n * @dev Converts an `address` into `address payable`. Note that this is\n * simply a type cast: the actual underlying value is not changed.\n *\n * _Available since v2.4.0._\n */\n function toPayable(address account) internal pure returns (address payable) {\n return address(uint160(account));\n }\n\n /**\n * @dev Replacement for Solidity's `transfer`: sends `amount` wei to\n * `recipient`, forwarding all available gas and reverting on errors.\n *\n * https://eips.ethereum.org/EIPS/eip-1884[EIP1884] increases the gas cost\n * of certain opcodes, possibly making contracts go over the 2300 gas limit\n * imposed by `transfer`, making them unable to receive funds via\n * `transfer`. {sendValue} removes this limitation.\n *\n * https://diligence.consensys.net/posts/2019/09/stop-using-soliditys-transfer-now/[Learn more].\n *\n * IMPORTANT: because control is transferred to `recipient`, care must be\n * taken to not create reentrancy vulnerabilities. Consider using\n * {ReentrancyGuard} or the\n * https://solidity.readthedocs.io/en/v0.5.11/security-considerations.html#use-the-checks-effects-interactions-pattern[checks-effects-interactions pattern].\n *\n * _Available since v2.4.0._\n */\n function sendValue(address payable recipient, uint256 amount) internal {\n require(address(this).balance >= amount, \"Address: insufficient balance\");\n\n // solhint-disable-next-line avoid-call-value\n (bool success, ) = recipient.call.value(amount)(\"\");\n require(success, \"Address: unable to send value, recipient may have reverted\");\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/SafeERC20.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @title SafeERC20\n * @dev Wrappers around ERC20 operations that throw on failure (when the token\n * contract returns false). Tokens that return no value (and instead revert or\n * throw on failure) are also supported, non-reverting calls are assumed to be\n * successful.\n * To use this library you can add a `using SafeERC20 for ERC20;` statement to your contract,\n * which allows you to call the safe operations as `token.safeTransfer(...)`, etc.\n */\nlibrary SafeERC20 {\n using SafeMath for uint256;\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint256 value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n }\n\n function safeApprove(IERC20 token, address spender, uint256 value) internal {\n // safeApprove should only be called when setting an initial allowance,\n // or when resetting it to zero. To increase and decrease it, use\n // 'safeIncreaseAllowance' and 'safeDecreaseAllowance'\n // solhint-disable-next-line max-line-length\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n );\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n }\n\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n }\n\n /**\n * @dev Imitates a Solidity high-level call (i.e. a regular function call to a contract), relaxing the requirement\n * on the return value: the return value is optional (but if data is returned, it must not be false).\n * @param token The token targeted by the call.\n * @param data The call data (encoded using abi.encode or one of its variants).\n */\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n // We need to perform a low level call here, to bypass Solidity's return data size checking mechanism, since\n // we're implementing it ourselves.\n\n // A Solidity high level call has three parts:\n // 1. The target address is checked to verify it contains contract code\n // 2. The call itself is made, and success asserted\n // 3. The return value is decoded, which in turn checks the size of the returned data.\n // solhint-disable-next-line max-line-length\n //require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n // solhint-disable-next-line avoid-low-level-calls\n //(bool success, bytes memory returndata) = address(token).call(data);\n\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/math/SafeMath.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @dev Wrappers over Solidity's arithmetic operations with added overflow\n * checks.\n *\n * Arithmetic operations in Solidity wrap on overflow. This can easily result\n * in bugs, because programmers usually assume that an overflow raises an\n * error, which is the standard behavior in high level programming languages.\n * `SafeMath` restores this intuition by reverting the transaction when an\n * operation overflows.\n *\n * Using this library instead of the unchecked operations eliminates an entire\n * class of bugs, so it's recommended to use it always.\n */\nlibrary SafeMath {\n /**\n * @dev Returns the addition of two unsigned integers, reverting on\n * overflow.\n *\n * Counterpart to Solidity's `+` operator.\n *\n * Requirements:\n * - Addition cannot overflow.\n */\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n uint256 c = a + b;\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n }\n\n /**\n * @dev Returns the subtraction of two unsigned integers, reverting on\n * overflow (when the result is negative).\n *\n * Counterpart to Solidity's `-` operator.\n *\n * Requirements:\n * - Subtraction cannot overflow.\n */\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n return sub(a, b, \"SafeMath: subtraction overflow\");\n }\n\n /**\n * @dev Returns the subtraction of two unsigned integers, reverting with custom message on\n * overflow (when the result is negative).\n *\n * Counterpart to Solidity's `-` operator.\n *\n * Requirements:\n * - Subtraction cannot overflow.\n *\n * _Available since v2.4.0._\n */\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b <= a, errorMessage);\n uint256 c = a - b;\n\n return c;\n }\n\n /**\n * @dev Returns the multiplication of two unsigned integers, reverting on\n * overflow.\n *\n * Counterpart to Solidity's `*` operator.\n *\n * Requirements:\n * - Multiplication cannot overflow.\n */\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n // Gas optimization: this is cheaper than requiring 'a' not being zero, but the\n // benefit is lost if 'b' is also tested.\n // See: https://github.com/OpenZeppelin/openzeppelin-contracts/pull/522\n if (a == 0) {\n return 0;\n }\n\n uint256 c = a * b;\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n }\n\n /**\n * @dev Returns the integer division of two unsigned integers. Reverts on\n * division by zero. The result is rounded towards zero.\n *\n * Counterpart to Solidity's `/` operator. Note: this function uses a\n * `revert` opcode (which leaves remaining gas untouched) while Solidity\n * uses an invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n */\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n return div(a, b, \"SafeMath: division by zero\");\n }\n\n /**\n * @dev Returns the integer division of two unsigned integers. Reverts with custom message on\n * division by zero. The result is rounded towards zero.\n *\n * Counterpart to Solidity's `/` operator. Note: this function uses a\n * `revert` opcode (which leaves remaining gas untouched) while Solidity\n * uses an invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n *\n * _Available since v2.4.0._\n */\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n // Solidity only automatically asserts when dividing by 0\n require(b > 0, errorMessage);\n uint256 c = a / b;\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n }\n\n /**\n * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),\n * Reverts when dividing by zero.\n *\n * Counterpart to Solidity's `%` operator. This function uses a `revert`\n * opcode (which leaves remaining gas untouched) while Solidity uses an\n * invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n */\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n return mod(a, b, \"SafeMath: modulo by zero\");\n }\n\n /**\n * @dev Returns the remainder of dividing two unsigned integers. (unsigned integer modulo),\n * Reverts with custom message when dividing by zero.\n *\n * Counterpart to Solidity's `%` operator. This function uses a `revert`\n * opcode (which leaves remaining gas untouched) while Solidity uses an\n * invalid opcode to revert (consuming all remaining gas).\n *\n * Requirements:\n * - The divisor cannot be zero.\n *\n * _Available since v2.4.0._\n */\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n require(b != 0, errorMessage);\n return a % b;\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/IERC20.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @dev Interface of the ERC20 standard as defined in the EIP. Does not include\n * the optional functions; to access them see {ERC20Detailed}.\n */\ninterface IERC20 {\n /**\n * @dev Returns the amount of tokens in existence.\n */\n function totalSupply() external view returns (uint256);\n\n /**\n * @dev Returns the amount of tokens owned by `account`.\n */\n function balanceOf(address account) external view returns (uint256);\n\n /**\n * @dev Moves `amount` tokens from the caller's account to `recipient`.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * Emits a {Transfer} event.\n */\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n /**\n * @dev Returns the remaining number of tokens that `spender` will be\n * allowed to spend on behalf of `owner` through {transferFrom}. This is\n * zero by default.\n *\n * This value changes when {approve} or {transferFrom} are called.\n */\n function allowance(address owner, address spender) external view returns (uint256);\n\n /**\n * @dev Sets `amount` as the allowance of `spender` over the caller's tokens.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * IMPORTANT: Beware that changing an allowance with this method brings the risk\n * that someone may use both the old and the new allowance by unfortunate\n * transaction ordering. One possible solution to mitigate this race\n * condition is to first reduce the spender's allowance to 0 and set the\n * desired value afterwards:\n * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729\n *\n * Emits an {Approval} event.\n */\n function approve(address spender, uint256 amount) external returns (bool);\n\n /**\n * @dev Moves `amount` tokens from `sender` to `recipient` using the\n * allowance mechanism. `amount` is then deducted from the caller's\n * allowance.\n *\n * Returns a boolean value indicating whether the operation succeeded.\n *\n * Emits a {Transfer} event.\n */\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n /**\n * @dev Emitted when `value` tokens are moved from one account (`from`) to\n * another (`to`).\n *\n * Note that `value` may be zero.\n */\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n /**\n * @dev Emitted when the allowance of a `spender` for an `owner` is set by\n * a call to {approve}. `value` is the new allowance.\n */\n event Approval(address indexed owner, address indexed spender, uint256 value);\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/GSN/Context.sol\n\npragma solidity ^0.5.0;\n\n/*\n * @dev Provides information about the current execution context, including the\n * sender of the transaction and its data. While these are generally available\n * via msg.sender and msg.data, they should not be accessed in such a direct\n * manner, since when dealing with GSN meta-transactions the account sending and\n * paying for execution may not be the actual sender (as far as an application\n * is concerned).\n *\n * This contract is only required for intermediate, library-like contracts.\n */\ncontract Context {\n // Empty internal constructor, to prevent people from mistakenly deploying\n // an instance of this contract, which should be used via inheritance.\n constructor () internal { }\n // solhint-disable-previous-line no-empty-blocks\n\n function _msgSender() internal view returns (address payable) {\n return msg.sender;\n }\n\n function _msgData() internal view returns (bytes memory) {\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n return msg.data;\n }\n}\n\n// File: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/crowdsale/Crowdsale.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @title Crowdsale\n * @dev Crowdsale is a base contract for managing a token crowdsale,\n * allowing investors to purchase tokens with ether. This contract implements\n * such functionality in its most fundamental form and can be extended to provide additional\n * functionality and/or custom behavior.\n * The external interface represents the basic interface for purchasing tokens, and conforms\n * the base architecture for crowdsales. It is *not* intended to be modified / overridden.\n * The internal interface conforms the extensible and modifiable surface of crowdsales. Override\n * the methods to add functionality. Consider using 'super' where appropriate to concatenate\n * behavior.\n */\ncontract Crowdsale is Context, ReentrancyGuard {\n using SafeMath for uint256;\n using SafeERC20 for IERC20;\n\n // The token being sold\n IERC20 private _token;\n\n // Address where funds are collected\n address payable private _wallet;\n\n // How many token units a buyer gets per wei.\n // The rate is the conversion between wei and the smallest and indivisible token unit.\n // So, if you are using a rate of 1 with a ERC20Detailed token with 3 decimals called TOK\n // 1 wei will give you 1 unit, or 0.001 TOK.\n uint256 private _rate;\n\n // Amount of wei raised\n uint256 private _weiRaised;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n /**\n * @param rate Number of token units a buyer gets per wei\n * @dev The rate is the conversion between wei and the smallest and indivisible\n * token unit. So, if you are using a rate of 1 with a ERC20Detailed token\n * with 3 decimals called TOK, 1 wei will give you 1 unit, or 0.001 TOK.\n * @param wallet Address where collected funds will be forwarded to\n * @param token Address of the token being sold\n */\n constructor (uint256 rate, address payable wallet, IERC20 token) public {\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(wallet != address(0), \"Crowdsale: wallet is the zero address\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n\n _rate = rate;\n _wallet = wallet;\n _token = token;\n }\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n /**\n * @return the token being sold.\n */\n function token() public view returns (IERC20) {\n return _token;\n }\n\n /**\n * @return the address where funds are collected.\n */\n function wallet() public view returns (address payable) {\n return _wallet;\n }\n\n /**\n * @return the number of token units a buyer gets per wei.\n */\n function rate() public view returns (uint256) {\n return _rate;\n }\n\n /**\n * @return the amount of wei raised.\n */\n function weiRaised() public view returns (uint256) {\n return _weiRaised;\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\n function buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(beneficiary, weiAmount);\n }\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _token.safeTransfer(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _deliverTokens(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.mul(_rate);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n _wallet.transfer(msg.value);\n }\n}\n\n// File: vender.sol\n\npragma solidity ^0.5.0;\n\n/**\n * @title SimpleCrowdsale\n * @dev This is an example of a fully fledged crowdsale.\n */\ncontract SimpleCrowdsale is Crowdsale {\n constructor (\n uint256 rate,\n address payable wallet,\n IERC20 token\n )\n public\n Crowdsale(rate, wallet, token)\n {\n }\n}\n\n read \n\n 7\n min\n\n 9 months later\n\n post by BigMadCode on Feb 23, 2022\n\n BigMadCode\n\n Hi,\nDid you ever resolve this issue?\nI think I am facing the same issue and cannot get around it.\nKindly reply at your earliest convenience.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020\n\n Add function buyTokens() with no parameter to Crowdsale contract\n\n Contracts\n\n 5\n\n 2.4k\n\n Nov 2020\n\n Problem with Crowdsale\n\n Support\n\n 6\n\n 1.6k\n\n May 2021","tokens":6362,"squid":"ink-security_audits","role":"Sentinel","at":1791264641123,"hash":"90209202bc3c8873c1c33a296bc4f5e4647ef965"}
{"url":"https://ethresear.ch/t/octopus-contract-and-its-applications/17844/18","domain":"ethresear.ch","title":"Octopus Contract and its Applications - Cryptography - Ethereum Research","text":"Cryptography\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 2\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n Dec 2023\n\n 18 / 18\n\n Apr 2024\n\n Apr 2024\n\n post by SoraSuegami on Dec 15, 2023\n\n SoraSuegami\n\n Authors: Sora Suegami, Leona Hioki\nThank Yi Sun, Justin Drake, and Aayush Gupta for feedback and discussions.\nOur full paper is here: Octopus Contract and its Applications\nTL;DR\nWe propose the concept of Octopus contracts, smart contracts that operate ciphertexts outside the blockchain. Octopus contracts can control the decryption of the ciphertexts based on on-chain conditions by requesting validators to sign the specified messages. Signature-based witness encryption (SWE) enables users to decrypt them with the signatures. Moreover, Octopus contracts can evaluate arbitrary functions on encrypted inputs with one-time programs built from SWE and garbled circuits. These features extend the functionality of smart contracts beyond the blockchain, providing practical solutions for unresolved problems such as a trustless bridge for a two-way peg between Bitcoin and Ethereum, private AMM, minimal anti-collusion infrastructure without a centralized operator, and achieving new applications such as private and unique human ID with proof of attribution, private computation with web data, and more.\n1 Background and Our Contribution\nRegarding the aspect of using smart contracts to operate secrets outside the blockchain, our scheme is fundamentally a generalization of the author’s previous work Trustless Bitcoin Bridge with Witness Encryption (Leona Hioki), which also provides a practical construction of the previous work.\nCompared to existing schemes to allow smart contracts to operate ciphertexts using new cryptographic schemes, e.g., Lit protocol with threshold encryption, smart contracts with secret sharing multi-party computation (MPC), and smartFHE with fully homomorphic encryption (FHE), our scheme with SWE requires minimum modification to the node implementation of the validators. This is because the validators only need to sign the message specified by the Octopus contract and encrypt this signature with public-key encryption (PKE). Especially, when a circuit of the function is privately evaluated with one-time programs (OTPs), the validators’ computational cost only depends on the input size of the circuit, independent of the circuit size. Besides, while both FHE-based schemes and our scheme can delegate heavy evaluation of the circuit to an untrusted third party, the latter is estimated to be faster than the former because the delegated party in the latter just decrypts the SWE encryptions of the garbled inputs and evaluates a garbled circuit, which only employs a hash function and bit operations in the optimal construction.\nThe validators’ work in vetKeys is similar to ours: the validators generate BLS signatures for an ID and encrypt the signatures under the user’s public key to pass the user a private key of that ID in ID-based encryption. However, it is our novel point to use the signatures for the private evaluation of functions on encrypted inputs.\nDespite the above advantages of our scheme, the Octopus contract using OTPs further relies on rabble MPC, n𝑛-of-n𝑛 MPC among randomly selected people who are different from the validators. It is used to generate an OTP while embedding a private key unknown to humans in the evaluated circuit. The rabble MPC is more secure and feasible than existing MPC-based schemes for the following reasons:\n\nIf at least one participant is honest, the MPC is secure, i.e., revealing no information other than the OTP.\nEven if the MPC fails because some participants leave the MPC, different participants can start new MPCs any number of times. Also, many MPCs can be performed in parallel.\nOnce the OTP is generated, there is nothing more for the MPC participant to do.\n\nThe following table summarizes the comparison between our scheme and the existing schemes.\nComparison_ours_existing960×540 80.4 KB\n2 Signature-based Witness Encryption\n2.1 Definition of SWE\nWe adopt a SWE scheme defined for t𝑡-out-of-n𝑛 BLS signatures. It provides the following algorithms. While they are based on Definition 1 of McFly, some inputs are omitted or modified.\n\n\\textsf{ct} \\leftarrow \\textsf{SWE.Enc}(V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n), h, m)𝖼𝗍 ←𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛),ℎ,𝑚): it takes as input a set V𝑉 of n𝑛 BLS verification keys, a hash hℎ of a signing target T𝑇, and a message to be encrypted m𝑚. It outputs a ciphertext \\textsf{ct}𝖼𝗍.\nm \\leftarrow \\textsf{SWE.Dec}(\\textsf{ct}, \\sigma, U, V)𝑚 ←𝖲𝖶𝖤.𝖣𝖾𝖼(𝖼𝗍,𝜎,𝑈,𝑉): it takes as input a ciphertext \\textsf{ct}𝖼𝗍, an aggregate signature \\sigma𝜎, two sets U, V𝑈,𝑉 of BLS verification keys. It outputs a decrypted message m𝑚 or the symbol \\perp⟂.\n\nIf more than or equal to t𝑡 validators of which verification keys are in V𝑉, i.e., |U| \\geq t|𝑈| ≥𝑡 and U \\subseteq V𝑈 ⊆𝑉, generate a valid aggregated signature \\sigma𝜎 for the hash hℎ, the correctness holds, i.e., \\textsf{SWE.Dec}(\\textsf{SWE.Enc}(V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n), h, m), \\sigma, U, V) = m𝖲𝖶𝖤.𝖣𝖾𝖼(𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛),ℎ,𝑚),𝜎,𝑈,𝑉) =𝑚. Otherwise, the \\textsf{SWE.Dec}𝖲𝖶𝖤.𝖣𝖾𝖼 algorithm returns the symbol \\perp⟂. Therefore, once the validators release the signature \\sigma𝜎, anyone can decrypt the ciphertext \\textsf{ct}𝖼𝗍.\n2.2 Access-Control of the Signature\nWe use the same technique as vetKeys to control who will be able to decrypt the ciphertext by encrypting the validators’ signatures. Specifically, when a legitimate decryptor provides a public key \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒 of the PKE scheme, each validator publishes an encryption \\textsf{ct}_{\\sigma_i}𝖼𝗍𝜎𝑖 of the signature \\sigma_i𝜎𝑖 under \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒, i.e., \\textsf{ct}_{\\sigma_i} \\leftarrow \\textsf{PKE.Enc}(\\textsf{pubKey}, \\sigma_i)𝖼𝗍𝜎𝑖 ←𝖯𝖪𝖤.𝖤𝗇𝖼(𝗉𝗎𝖻𝖪𝖾𝗒,𝜎𝑖). That decryptor can recover the message by decrypting each \\textsf{ct}_{\\sigma_i}𝖼𝗍𝜎𝑖 with the private key \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒 corresponding to the \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒, aggregating the recovered signatures into \\sigma_{\\Sigma}𝜎Σ, and decrypting the ciphertext under SWE by \\sigma_{\\Sigma}𝜎Σ. However, the other users cannot do that because they cannot obtain \\sigma_{\\Sigma}𝜎Σ from \\textsf{ct}_{\\sigma}𝖼𝗍𝜎 without \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒. Besides, even the validators cannot decrypt them as long as their honest majority does not reveal each signature \\sigma_i𝜎𝑖.\nAs proposed in vetKeys, if the PKE scheme is additive-homomorphic, e.g., EC-ElGamal encryption, the decryptor can first compute the encryption of the aggregated signature by computing the weighted sum of the encrypted signatures and then decrypt only the aggregated one. By outsourcing that computation, the decryptor can reduce the computation cost.\n2.3 Estimated Benchmark of SWE\nWe estimate a benchmark of the SWE scheme based on McFly assuming a threshold \\frac{t}{n}=\\frac{2}{3}𝑡𝑛 =23. For n=500𝑛 =500 and n=2000𝑛 =2000, encryption takes approximately 10 and 60 seconds, and decryption takes around 20 and 350 seconds, respectively. These results suggest the appropriate number of allocated validators for each use case. They also imply that more improvement in the SWE scheme will enhance the security of ciphertexts, i.e., increasing the number of allocated validators, without sacrificing the performance.\n3 Octopus Contract\nIn our scheme, the Octopus contract helps users request the Ethereum validators to sign a specific message for the SWE decryption. Specifically, they work as follows.\n\nFirstly, some validators register with and watch the Octopus contract made by an application developer.\nAn encryptor, the user willing to encrypt a message using SWE, calls the Octopus contract to register a signing target T𝑇.\nThe Octopus contract records the hash h:=\\textsf{Hash}(\\textsf{PREFIX}, T)ℎ :=𝖧𝖺𝗌𝗁(𝖯𝖱𝖤𝖥𝖨𝖷,𝑇) derived from T𝑇. Note that \\textsf{PREFIX}𝖯𝖱𝖤𝖥𝖨𝖷 is a fixed unique string, which prevents the validators from signing messages for the Ethereum consensus algorithm.\nThe encryptor generates an encryption \\textsf{ct}𝖼𝗍 of the messages m𝑚 under the hash hℎ and n𝑛 validators’ verification keys V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n)𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛) allocated by the Octopus contract.\nA decryptor, a user willing to decrypt \\textsf{ct}𝖼𝗍, has a PKE key pair (\\textsf{privKey}, \\textsf{pubKey})(𝗉𝗋𝗂𝗏𝖪𝖾𝗒,𝗉𝗎𝖻𝖪𝖾𝗒) and calls the Octopus contract, passing the hℎ and the PKE public key \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒 to request validators’ signatures.\nThe Octopus contract checks if the decryptor is legitimate based on the required on-chain conditions. If the decryptor does not pass the conditions, the contract rejects the decryptor’s request.\nMore than or equal to t𝑡 validators generate the encryption ct_{\\sigma}𝑐𝑡𝜎 of the aggregated signature \\sigma𝜎 for the hash hℎ in a way described in Subsection 2.2.\nThe validators provide the Octopus contract with the encryptions \\textsf{ct}_{\\sigma}𝖼𝗍𝜎 along with a proof \\pi𝜋 to prove that they are valid encryptions of the aggregated signatures.\nThe decryptor first decrypts \\textsf{ct}_{\\sigma}𝖼𝗍𝜎 with \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒 to obtain the signature \\sigma𝜎, and then decrypts \\textsf{ct}𝖼𝗍 with \\sigma𝜎 to recover the messages m𝑚.\n\nIn this way, the encryptor can encrypt messages under some on-chain state conditions without knowing who satisfies the conditions in the future. As long as more than or equal to the threshold of the validators behave honestly, i.e., sign only the message confirmed by the Octopus contract, only the legitimate decryptor can decrypt the ciphertext.\nWhen implementing our scheme, we can prepare a shared smart contract for common management of the registered validators and requests for signatures. Each application contract specifies the signing messages and checks if the decryptor is legitimate.\nIts application is described in Subsection 3.1 in the full paper.\n4 One-Time Program with Octopus Contract\n4.1 Basic Ideas\nThe Octopus contract with SWE described above has the following limitations.\n\nThe ciphertext must be decrypted in a rather short time because the validators that can generate signatures for the decryption are fixed at the time of encryption.\nIt is impossible to apply some functions to the encrypted message m𝑚 without revealing it to the decryptor.\n\nWe solve them by introducing OTPs. The OTP is an encoded circuit that can be evaluated on at most one input. Goyal constructs a blockchain-based one-time program (BOTP) from witness encryption (WE) and garbled circuits. A generator of BOTP makes a garbled circuit of the circuit and encrypts its garbled inputs under WE. Its evaluator can decrypt each encryption of the garbled input for the bit b \\in \\{0,1\\}𝑏 ∈{0,1} of the i𝑖-th input bit by committing b𝑏 as the i𝑖-th input bit on-chain. Subsequently, the decryptor evaluates the garbled circuit with the recovered garbled inputs. The decryptor can input only one bit b𝑏 for each input bit to the circuit because the decryption condition of WE requires the decryptor to prove that b𝑏 is committed first to the blockchain finalized by the honest majority of validators. In other words, the decryptor cannot input 1-b1 −𝑏 without tampering with the finalized block containing the commitment of b𝑏.\nWhile the OTP has the limitation of one-time input, it has a useful security feature that the evaluator cannot learn non-trivial information about the circuit. Therefore, the generator can embed secret data and algorithms in the circuit of the OTP. Moreover, if multiple generators use n𝑛-of-n𝑛 MPC, which we call rabble MPC, to generate a private key, embed it in the circuit, and output its OTP, the OTP can hold a private key that no human knows as long as at least one MPC participant and the honest majority of the validators are honest. It can be used to decrypt the encryption of the circuit input and sign the circuit output inside the circuit. For example, the OTP with the embedded private key allows us to bootstrap a SWE ciphertext, i.e., encrypting the same message under a different set of verifying keys. The OTP for the SWE bootstrap decrypts the encrypted signature with the private key, uses the signature to recover the message from the SWE ciphertext, and encrypts the same message under new verifying keys. We can generalize this approach to evaluate arbitrary functions on encrypted inputs.\n4.2 One-time program based on SWE\nInstead of existing WE constructions supporting general decryption conditions, which are impractical or depend on heuristics cryptographic assumptions, we adopt SWE to build OTPs. Let k_{i,b}𝑘𝑖,𝑏 and \\widetilde{C}̃𝐶 be a garbled input for the bit b𝑏 of the i𝑖-th input bit and a garbled circuit of the input size |x||𝑥|, respectively. The generator, the evaluator, and the Octopus contract managing \\widetilde{C}̃𝐶 collaborate as below:\n\nThe generator registers 2|x|2|𝑥| signing targets \\{(i,b)\\}_{i \\in [|x|], b \\in \\{0,1\\}} = \\{(1,0), (1,1), \\dots, (|x|,0), (|x|,1)\\}{(𝑖,𝑏)}𝑖∈[|𝑥|],𝑏∈{0,1} ={(1,0),(1,1),…,(|𝑥|,0),(|𝑥|,1)} with the Octopus contract.\nThe Octopus contract records 2|x|2|𝑥| hashes \\{h_{i,b}=\\textsf{Hash}(\\textsf{PREFIX}, (i,b))\\}_{i \\in [|x|], b \\in \\{0,1\\}}{ℎ𝑖,𝑏 =𝖧𝖺𝗌𝗁(𝖯𝖱𝖤𝖥𝖨𝖷,(𝑖,𝑏))}𝑖∈[|𝑥|],𝑏∈{0,1} and allocates n𝑛 validators of which the verification keys are V=(\\textsf{vk}_1, \\dots, \\textsf{vk}_n)𝑉 =(𝗏𝗄1,…,𝗏𝗄𝑛).\nThe generator generates a garbled circuit \\widetilde{C}̃𝐶 and its garbled inputs \\{k_{i,b}\\}_{i \\in [|x|], b \\in \\{0,1\\}}{𝑘𝑖,𝑏}𝑖∈[|𝑥|],𝑏∈{0,1}.\nFor each i \\in [|x|], b \\in \\{0,1\\}𝑖 ∈[|𝑥|],𝑏 ∈{0,1}, the generator encrypts k_{i,b}𝑘𝑖,𝑏 under V𝑉 and h_{i,b}ℎ𝑖,𝑏, i.e., ct_{i,b} \\leftarrow \\textsf{SWE.Enc}(V, h_{i,b}, k_{i,b})𝑐𝑡𝑖,𝑏 ←𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉,ℎ𝑖,𝑏,𝑘𝑖,𝑏).\nThe evaluator registers the input x𝑥 with the Octopus contract.\nThe Octopus contract checks if the other inputs have not been registered before. If so, it requests the allocated validators to sign the |x||𝑥| hashes \\{h_{i,x_i}\\}_{i \\in [|x|]}{ℎ𝑖,𝑥𝑖}𝑖∈[|𝑥|] without specifying a public key to encrypt the signatures.\nThe evaluator obtains aggregated signatures \\{\\sigma_{i}\\}_{i \\in [|x|]}{𝜎𝑖}𝑖∈[|𝑥|] and uses them to decrypt \\{ct_{i,x_i}\\}_{i \\in [|x|]}{𝑐𝑡𝑖,𝑥𝑖}𝑖∈[|𝑥|], i.e., k_{i,x_i} \\leftarrow \\textsf{SWE.Dec}(ct_{i,x_i}, \\sigma_{i}, U, V)𝑘𝑖,𝑥𝑖 ←𝖲𝖶𝖤.𝖣𝖾𝖼(𝑐𝑡𝑖,𝑥𝑖,𝜎𝑖,𝑈,𝑉).\nThe evaluator evaluates \\widetilde{C}̃𝐶 on \\{k_{i,x_i}\\}_{i \\in [|x|]}{𝑘𝑖,𝑥𝑖}𝑖∈[|𝑥|].\n\nNotably, in formal security proof, the garbled circuit is secure only against a selective adversary that chooses the input x𝑥 before seeing the garbled circuit \\widetilde{C}̃𝐶. However, as far as our knowledge, it does not mean that there is a practical attack on the garbled circuit scheme when x𝑥 is chosen adaptively. Besides, Yao’s garbled circuit without modification is proven to be adaptively secure if the circuit is an NC1 circuit, i.e., a low-depth circuit. To bootstrap it to a polynomial-sized circuit, we may be able to use a similar technique in this paper that bootstraps an indistinguishability obfuscation of NC1 circuits with a randomized encoding such as Yao’s garbled circuit.\n4.3 Rabble MPC for Key-Embedded OTPs\nOTPs of key-embedded circuits are generated through the rabble MPC, n𝑛-of-n𝑛 MPC among randomly selected people. The Octopus contract manages the participants of the rabble MPC and randomly assigns their subset to each generation of the OTP. These participants are different from the validators, and the Octopus contract can require a lower stake to participate in the rabble MPC than that of validators.\nAfter registering the signing targets with the Octopus contract as described above, the selected n𝑛 participants perform the n𝑛-of-n𝑛 MPC to privately generate a new OTP for a circuit C𝐶 taking s𝑠 inputs as follows:\n\nEach participant provides the randomness r_i𝑟𝑖 as input.\nThey derive private and public keys (\\textsf{privKey}, \\textsf{pubKey})(𝗉𝗋𝗂𝗏𝖪𝖾𝗒,𝗉𝗎𝖻𝖪𝖾𝗒) from the XOR of all randomnesses \\bigoplus_{i=1}^n r_i⨁𝑛𝑖=1𝑟𝑖. These keys are assumed to be usable for both PKE and digital signature schemes.\nThey construct a key-embedded circuit C[\\textsf{privKey}]𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒] that takes s𝑠 encryptions of inputs (ct_{x_1}, \\dots, ct_{x_s})(𝑐𝑡𝑥1,…,𝑐𝑡𝑥𝑠) under \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒, decrypts them with \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒, provides the s𝑠 inputs (x_1, \\dots, x_s)(𝑥1,…,𝑥𝑠) for C𝐶, signs the output y=C(x_1, \\dots, x_s)𝑦 =𝐶(𝑥1,…,𝑥𝑠) with \\textsf{privKey}𝗉𝗋𝗂𝗏𝖪𝖾𝗒, and outputs y𝑦 and the signature \\sigma_{\\textsf{otp}}𝜎𝗈𝗍𝗉. Let u𝑢 be the input bits size of C[\\textsf{privKey}]𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒].\nThey generate a garbled circuit of C[\\textsf{privKey}]𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒] denoted by \\widetilde{C[\\textsf{privKey}]}̃𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒] and its garbled inputs \\{k_{i,b}\\}_{i \\in [u], b \\in \\{0,1\\}}{𝑘𝑖,𝑏}𝑖∈[𝑢],𝑏∈{0,1}.\nThey encrypt each garbled input k_{i,b}𝑘𝑖,𝑏 under the allocated validators’ verification keys V𝑉 and the hash h_{i,b}=\\textsf{Hash}(\\textsf{PREFIX}, (i,b))ℎ𝑖,𝑏 =𝖧𝖺𝗌𝗁(𝖯𝖱𝖤𝖥𝖨𝖷,(𝑖,𝑏)), i.e., ct_{i,b} \\leftarrow \\textsf{SWE.Enc}(V, h_{i,b}, k_{i,b})𝑐𝑡𝑖,𝑏 ←𝖲𝖶𝖤.𝖤𝗇𝖼(𝑉,ℎ𝑖,𝑏,𝑘𝑖,𝑏).\nThey outputs the OTP (\\textsf{pubKey}, \\widetilde{C[\\textsf{privKey}]}, \\{ct_{i,b}\\}_{i \\in [u], b \\in \\{0,1\\}})(𝗉𝗎𝖻𝖪𝖾𝗒,̃𝐶[𝗉𝗋𝗂𝗏𝖪𝖾𝗒],{𝑐𝑡𝑖,𝑏}𝑖∈[𝑢],𝑏∈{0,1}).\n\nThe way of the SWE bootstrapping and the applications with OTP are described in Subsections 4.4 and 4.5 in the full paper.\n5 Selecting a Subset of Validators\nThere are several methods to select a validator set from the consensus layer of Ethereum as follows:\n\nHard fork Ethereum to force all validators to sign messages from Octopus contracts.\nSoft fork Ethereum, allowing any validators to sign messages from Octopus contracts.\nUse a re-staking mechanism such as Eigen Layer, enabling validators to have dual roles.\n\nEven in the first case, which imposes the greatest burden on the Ethereum network, the validators’ signatures for the same messages can be aggregated, so that the additional cost of pairing is at most for each ciphertext. However, in that case, we should note that security is not completely inherited because the validators cannot be penalized in the same way as in the case of double voting when they sign messages not specified by the Octopus contracts.\nIn the second and third cases, we can maintain the existing protocol of the consensus layer as the modification to the node implementation for our scheme is optimal in similar to MEV-related protocols. While the restaking in the third case is easy to introduce, the soft fork supported by many validators will improve the security of our scheme more significantly.\nApplications and the other notes\nThe on-chain conditions for the decryption in Octopus contracts can be implemented in Solidity. By customizing the conditions for each use case, we can build various novel applications, including a trustless bitcoin bridge, private AMM, and more. The OTP extends the application of the Octopus contracts because their functionalities are almost equivalent to what TEEs can do, in particular verification of computations by private conditions, private unique human IDs with proof of attributions, and private computation with web data. They are described in our full paper.\nRead our full paper here: Octopus Contract and its Applications\nSora Suegami wrote the sections about the idea of using OTPs for private function evaluation and its applications. Leona Hioki wrote the sections about a trustless bitcoin bridge and private AMM. The other sections are written together.\n\n Privacy preserving nullifiers for proof of identity applications\n\n Trustless Bitcoin Bridge Creation with Witness Encryption\n\n 6\n\n 2\n\n 2\n\n 2\n\n read \n\n 12\n min\n\n post by sg on Dec 16, 2023\n\n sg\n\n Okay so my takeaways and rephrasal for further discussion below.\n\nThe Octopus Contract receives and stores ciphertext as input.\n\nThe logic described in the smart contract determines the entity that can decrypt the ciphertext.\n\nThe information required for decryption is a threshold signature by the validators that comprise the consensus layer. This mechanism is called SWE and is based on the honest majority assumption. Those signers are fixed at encryption timing without One-time Programs (OTPs).\n\nThe method for securely returning signatures to a qualifying sender is on-chain public key cryptography.\n\nUnlike the method using FHE, the validator only needs to pay the computational cost of the threshold signature, and the computational cost of the decryption process is paid by the sender, which is novel.\n\nWith OTPs, ciphertext (such as encrypted private key) could be used for generating a signature to run a new tx without revealing that key. (It can be a shared account of different blockchain, etc.)\n\nIn chapter 5, several L1 modification ideas.\n\nI would like to ask a question.\n\nIn chapter 4 section 2 “One-time Program with SWE”, the evaluator seems to be trusted. Could you tell me his plausible assumption for security?\n\n post by SoraSuegami on Dec 16, 2023\n\n SoraSuegami\n\n Thank you for your questions!\n\nThe Octopus Contract receives and stores ciphertext as input.\n\nYes.\nHowever, the encryptor does not necessarily store the ciphertext on-chain in applications that ensure the availability of the ciphertext in any other way.\n\nThe logic described in the smart contract determines the entity that can decrypt the ciphertext.\n\nYes. Its interesting point is that the encryptor does not need to specify the decryptor in advance.\n\nThe information required for decryption is a threshold signature by the validators that comprise the consensus layer. This mechanism is called SWE and is based on the honest majority assumption. Those signers are fixed at encryption timing without One-time Programs (OTPs).\n\nYes.\n\nThe method for securely returning signatures to a qualifying sender is on-chain public key cryptography.\n\nYes, the decryptor just specifies a public key, and the validators return encryptions of the signature under the public key.\n\nUnlike the method using FHE, the validator only needs to pay the computational cost of the threshold signature, and the computational cost of the decryption process is paid by the sender, which is novel.\n\nThe validators in our scheme only need to generate the threshold signature to help the evaluation of OTPs.\nHowever, the validators in multi-key FHE can also delegate a heavy evaluation of which computational cost depends on the circuit size to an untrusted party, i.e., the evaluator.\nWe can estimate that the computational cost in our scheme is cheaper than that in the FHE-based schemes.\nThe detail is described in Section 1 of our full paper.\n\nWith OTPs, ciphertext (such as encrypted private key) could be used for generating a signature to run a new tx without revealing that key. (It can be a shared account of different blockchain, etc.)\n\nWe assume the key-embedded circuit always outputs a signature for the circuit output. The encryptions of garbled inputs under SWE are used to evaluate the garbled circuit, which outputs the circuit output and its signature, without revealing the embedded private key.\n\nIn chapter 5, several L1 modification ideas.\n\nYes, we present multiple ways to modify the node implementation of the validators for our scheme.\n\nIn chapter 4 section 2 “One-time Program with SWE”, the evaluator seems to be trusted. Could you tell me his plausible assumption for security?\n\nThere is no assumption about the evaluator because the evaluator cannot learn any information in the circuit, e.g., the embedded private key.\nWhat makes you think that the evaluator is trusted?\n\n post by sg on Dec 16, 2023\n\n sg\n\n Thanks to your feedback, I learned what the garbled circuit and the evaluator are. Seems legit \n\n post by tkmct on Dec 17, 2023\n\n tkmct\n\n PREFIX of a hash is open to the public? Then, an evaluator’s input to the OTP has to be made public?\n\n post by SoraSuegami on Dec 17, 2023\n\n SoraSuegami\n\n Thank you for your questions!\n\nPREFIX of a hash is open to the public?\n\nYes.\n\nThen, an evaluator’s input to the OTP has to be made public?\n\nNo, they are encrypted under a public key of the private key embedded in the circuit of the OTP.\nThe description in Subsection 4.2 handles OTPs for general circuits and the inputs are directly recorded on-chain.\nHowever, our actual construction in Subsection 4.3 only assumes OTPs for the key-embedded circuits, which decrypt the encrypted inputs with the embedded private keys.\nTherefore, even if the circuit inputs to the key-embedded circuits, i.e., the encrypted inputs, are public, the actual inputs are kept private.\n\n post by tkmct on Dec 17, 2023\n\n tkmct\n\n Thank you for your answer!\nSo, does the evaluator commit to encrypted inputs on-chain? How does this process work in detail?\nI assume that even though the evaluator’s input (represented as a series of bits) is encrypted under pubKey of embedded GC, each input bit can be easily guessed because possible ciphertexts are either encryption of 0 or 1. This is why I asked if PREFIX is public, so that anyone can calculate the hash of evaluator’s inputs.\n\n post by maniou-T on Dec 18, 2023\n\n maniou-T\n\n What is the role of the rabble MPC (n-of-n MPC among randomly selected participants) in the generation of One-Time Programs (OTPs) with key-embedded circuits, and how does it contribute to the security of the proposed scheme?\n\n post by SoraSuegami on Dec 18, 2023\n\n SoraSuegami\n\nSo, does the evaluator commit to encrypted inputs on-chain? How does this process work in detail?\n\nYes. Specifically, the evaluator encrypts the input x𝑥 under a public key \\textsf{pubKey}𝗉𝗎𝖻𝖪𝖾𝗒 of the private key embedded in the circuit and commits each bit ct_x[i]𝑐𝑡𝑥[𝑖] of the ciphertext ct_x𝑐𝑡𝑥.\nIf no encrypt input has been committed on-chain, the contract requests validators to sign a signing target (i, ct_x[i])(𝑖,𝑐𝑡𝑥[𝑖]) for each i𝑖.\nThe validators’ signature for (i, ct_x[i])(𝑖,𝑐𝑡𝑥[𝑖]) will allow the evaluator to decrypt the SWE encryption of the i𝑖-th garbled input for the bit ct_x[i]𝑐𝑡𝑥[𝑖], which is generated at the generation of OTP.\n\neach input bit can be easily guessed because possible ciphertexts are either encryption of 0 or 1.\n\nThis is not true.\nFor example, if the circuit only takes input from one party, the ciphertext will be the encryption of the entire input bits.\nEven if the encrypted input is just an encryption of one bit, I think the adversary cannot predict which bit is encrypted as long as the PKE scheme is IND-CPA secure.\n\n post by SoraSuegami on Dec 18, 2023\n\n SoraSuegami\n\n maniou-T\n\n Thank you for your question!\n\nWhat is the role of the rabble MPC\n\nIn short, the role of rabble MPC is a trusted generation of the OTP of the key-embedded circuit.\nSpecifically, it first generates a private key unknown to any participants, then embeds the key into a circuit, and finally outputs only the OTP, i.e., a garbled circuit, SWE encryptions of garbled inputs, and a public key of the embedded private key.\n\nhow does it contribute to the security of the proposed scheme?\n\nAs long as at least one participant in the rabble MPC (and the honest majority of the validators) is honest, i.e., not revealing intermediate values in the MPC, the Octopus contract can assume that the embedded private key is unknown to anybody and can be used only according to the logic of the key-embedded circuit, similar to the private key in an enclave of TEE.\n\n post by leohio on Dec 21, 2023\n\n leohio\n\n There were 2 questions for me, and seems that I need to follow them.\n\nShould we make a bigger size of validator sets to make SWE secure?\n\nAttackers in the validator set can collude to decrypt the SWE ciphertexts without the smart contract execution. But one of the colluders will be rewarded for revealing that activity to make them slashed.\nIf in such a condition, even trying that is dangerous for them.\nBut the size of validators matters of course, and the best case is all the Ethereum validators.\n\nWhat kind of data is private in the section of Private AMM?\n\nOnly the transactor can see the AMM pool when they send the tokens to swap.\nDeposits and withdrawals are with token transfers in a private manner operated by the other services.\nIn the trusted setup, an MPC process is required not to let the last person know the address to make 1/N secret assumption of privacy, otherwise, the last person can see a part of the pool (one deposit address). If you fully trust the trusted setup, the last person only has to forget the pool after making the SWE ciphertext.\nAs it describes, only a person who swaps tokens can see the pool temporarily and the pool gets changed after the transaction. So this AMM is somehow hard to trace activities as a semi-private AMM.\n\n 21 days later\n\n post by turboblitz on Jan 11, 2024\n\n turboblitz\n\n Great paper!\nStill trying to wrap my head around the OTP part.\nFor the trustless bitcoin bridge section, I have a question. Let’s consider a simpler design without WE, a traditional multisig bridge on top of eigenlayer:\n\nA user deposits btc to the multisig address controlled by the nodes.\nHe proves transaction on ethereum with a light client bridge, mints tBTC.\nWhen he wants to withdraw, burns tBTC specifying a BTC withdrawal address\nEach node signs a transaction that sends the correct amount of btc to the withdrawal address specified by the user.\n\nIf a node signs a transaction but no request has been made, it can be proven and slashed on ethereum, so 1/N trust assumption. Also, this allows for arbitrary amounts.\nDoes the octopus contract improve on this scheme ?\n\n post by leohio on Jan 14, 2024\n\n leohio\n\n Even if you can slash the person, the majority of that multi-sig can steal the fund, so it’s the majority assumption, not 1/N.\nIn this case, the 1/N assumption is just for the trusted setup, and the majority assumption of validators. still remains. If you want the 1/N assumption, pls read here\n\n post by xiangxiecrypto on Jan 18, 2024\n\n xiangxiecrypto\n\n It is a very nice idea to use SWE to construct these applications. I have a few questions.\n\nAfaik the garbled circuit can not hide the information on the circuit itself, it only hides the inputs. If you want to embed secret information in the circuit, you probably need to use universal circuit?\nIn the key-embedded OTP constructions, you have to run an n-of-n MPC to securely compute all the SWE encryptions and garbling process? Do I understand correctly?\nYou mentioned that one can also use Octopus contract to delegate computation as FHE, can you explore it more? In the OTP construction, the evaluator has to compute the circuit anyway, right?\n\n 1 month later\n\n post by SoraSuegami on Feb 17, 2024\n\n SoraSuegami\n\n Sorry for the late response!\n\nAfaik the garbled circuit can not hide the information on the circuit itself, it only hides the inputs. If you want to embed secret information in the circuit, you probably need to use universal circuit?\n\nAs far as I understand, some garbled circuit schemes such as Yao’s garbled circuit hide the information on the circuit. Besides, if you use a scheme that does not hide the circuit, as you mentioned, you can use a universal circuit. In that case, the OTP generation process outputs only one-bit garbled input for each bit corresponding to the circuit, rather than encrypting garbled inputs for both bits under SWE. Therefore, this approach does not increase the number of signed messages.\nThis paper describes the circuit privacy of garbled circuits.\n\nIn the key-embedded OTP constructions, you have to run an n-of-n MPC to securely compute all the SWE encryptions and garbling process? Do I understand correctly?\n\nYes, that is correct!\nThe point is that the garbled circuit and the SWE encryptions of the garbled inputs should be generated without revealing the used randomness to anyone.\n\nYou mentioned that one can also use Octopus contract to delegate computation as FHE, can you explore it more?\n\nSorry for the confusion, we just compared the delegated evaluation of private circuits in our method with that of (multi-key) FHE.\n\nIn the OTP construction, the evaluator has to compute the circuit anyway, right?\n\nYes, the evaluator needs to evaluate a garbled circuit.\nHowever, we expect that this computational cost will be less than that of the FHE evaluation as described in Section 1 of our paper.\n\n 17 days later\n\n post by voidp on Mar 6, 2024\n\n voidp\n\n Interesting idea. I have two clarification questions:\nCan you say more about building “anti-collusion” protocols from Octopus smart contracts? Is there some special leverage to prevent/slash collusion that is infeasible in a more general threshold trust assumption? I.e., is an Octopus smart contract more resilient to collusion than, say, an MPC with a threshold assumption?\nSecond, is there implementation to play with?\n\n post by wyunhao on Mar 7, 2024\n\n wyunhao\n\n Hi there,\nThanks for sharing this interesting paper! I have some quick questions:\n\nGenerally, your idea is not using the “witness” part of SWE right? What you need is just a threshold signature scheme.\nRegarding the bootstrapping, it seems that the Octopus Contract needs the original set of validators V to be online and provide the contract their aggregated signing key; also, the new set of validators should also be online to do their job, is my understanding correct?\nFollowing the above question, is it the case that in all applications, the original set of validators V need to be there when someone wants to evaluate/decrypt the ciphertexts “encrypted” under V? For example, in trustless bitcoin bridge case, all “signers” (which is actually the trusted-setup nodes) needs to provide the decryption of ciphertexts.\n\nLastly, it would be appreciated to see the evaluation of a concrete implementation. Could you please kindly share some information about your roadmap on this project?\n\n 1 month later\n\n post by wooju on Apr 8, 2024\n\n wooju\n\n Based on the SWE reference you provided, I understand that for an input message x, the SWE ciphertext consists of (2*|x|) target group elements + (2*n + 3) elements (where n is the number of keygen participants) from a group where pairing operation is defined. In this case, it seems that the length of the ciphertext would be very long… Is this also data that needs to be stored somewhere? How can the evaluator obtain this value?\n\n Powered by Discourse","tokens":8659,"squid":"ink-research","role":"Deep Scholar","at":1791264652766,"hash":"aa567d9970d31c44cc8ee04fe9630fff3917c57c"}
{"url":"https://forum.openzeppelin.com/t/add-function-buytokens-with-no-parameter-to-crowdsale-contract/4700","domain":"forum.openzeppelin.com","title":"Add function buyTokens() with no parameter to Crowdsale contract - Support / Contracts - OpenZeppelin Forum","text":"Add function buyTokens() with no parameter to Crowdsale contract \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Nov 2020\n\n 1 / 6\n\n Nov 2020\n\n Nov 2020\n\n post by SvenMeyer on Nov 20, 2020\n\n SvenMeyer\n\n I want to use the simple Crowdsale.sol contract.\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\nFor added simplicity (= safety) I would like to add a function which send the tokens directly to msg.sender , so the buyer does not need to provide (his) address for the token to send to, thus eliminates a major possibility of (potentially very expensive) mistake.\n\nCan I extend the contract like this?\nI did not use nonReentrant within the function definition (actually it gives me a ReentrancyGuard - gas estimation error , hoping that underlying function buyTokens(msg.sender); will take care of it.\nIs it safe , so no reentrancy risk this way? … or should I better copy the whole buyTokens(address); function from Crowdsale.sol and remove the parameter ?\n\nIdeally I would not even need to call the function (as a token buyer) and would just send a certain amount of ETH to that contract, but as far as I understand that would not work as the transfer function does not provide enough gas to execute the Crowdsale contract.\npragma solidity ^0.5.17;\n\n// https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\";\n\ncontract TokenCrowdsale is Crowdsale {\n constructor(\n uint256 rate,\n address payable wallet,\n IERC20 token\n )\n Crowdsale(rate, wallet, token)\n public\n {\n\n }\n\n function buyTokens() public payable {\n buyTokens(msg.sender);\n }\n}\n\n 4\n\n 2\n\n post by abcoathup on Nov 22, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @SvenMeyer,\nIf you want this restriction then you could extend _preValidatePurchase in your crowdsale to check that the beneficiary is msg.sender.\n\nAs an aside, you linked to the 2.5.0 release branch of OpenZeppelin contracts. I recommend using tags so that you are using an official release of OpenZeppelin Contracts, e.g. OpenZeppelin Contracts v2.5.1: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/crowdsale/Crowdsale.sol\n\n post by SvenMeyer on Nov 22, 2020\n\n post by SvenMeyer on Nov 22, 2020\n\n post by abcoathup on Nov 23, 2020\n\n post by SvenMeyer on Nov 23, 2020\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Crowdsale Contract - TypeError: Overriding function changes state mutability from “view” to “nonpayable”\n\n Contracts\n\n crowdsale\n\n 2\n\n 4.2k\n\n Jul 2021\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020","tokens":803,"squid":"ink-security_audits","role":"Sentinel","at":1791264652824,"hash":"abf936e0a5b932ade88ea9c39c05a4754ec78dbd"}
{"url":"https://forum.openzeppelin.com/t/add-function-buytokens-with-no-parameter-to-crowdsale-contract/4700/7","domain":"forum.openzeppelin.com","title":"Add function buyTokens() with no parameter to Crowdsale contract - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n Nov 2020\n\n 6 / 6\n\n Nov 2020\n\n Nov 2020\n\n post by SvenMeyer on Nov 20, 2020\n\n post by abcoathup on Nov 22, 2020\n\n post by SvenMeyer on Nov 22, 2020\n\n post by SvenMeyer on Nov 22, 2020\n\n SvenMeyer\n\n abcoathup\n\n @abcoathup Just discovered that there is also already a payable default function which allows to just send ETH to the contract (which looks like my function - so that should be ok ?) … as long as enough gas is provided.\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n post by abcoathup on Nov 23, 2020\n\n abcoathup\n\n Great contributor\n\n SvenMeyer\n\n Hi @SvenMeyer,\nIf depends if your participants are using your app or whether they are interacting directly via the contract.\nI assume your buyTokens() would be fine as you are then calling the non reentrant buyTokens(address) (as is done by the fallback), though I would appropriately test and audited as part of your solution.\nYou could use the fallback, as long as enough gas is provided.\nIf it is a concern that users will provide an invalid beneficiary, then you could enforce this restriction using _preValidatePurchase \nAs you are creating a crowdsale, I recommend looking at: Points to consider when creating a fungible token (ERC20, ERC777)\n\n post by SvenMeyer on Nov 23, 2020\n\n SvenMeyer\n\n @abcoathup thanks again for yout valuable feedback !\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Crowdsale Contract - TypeError: Overriding function changes state mutability from “view” to “nonpayable”\n\n Contracts\n\n crowdsale\n\n 2\n\n 4.2k\n\n Jul 2021\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020","tokens":611,"squid":"ink-security_audits","role":"Sentinel","at":1791264663133,"hash":"2a6129bb18a74abe58aa0b70d6153439e9abe5cd"}
{"url":"https://specs.optimism.io/protocol/delta/span-batches.html","domain":"specs.optimism.io","title":"Span Batches - OP Stack Specification","text":"Span-batches\n\nTable of Contents\n\nIntroduction\nSpan batch format\n\nSpan Batch Size Limits\nFuture batch-format extension\n\nSpan Batch Activation Rule\nOptimization Strategies\n\nTruncating information and storing only necessary data\ntx_data_headers removal from initial specs\nChain ID removal from initial specs\nReorganization of constant length transaction fields\nRLP encoding for only variable length fields\nStore y_parity and protected_bit instead of v\nAdjust txs Data Layout for Better Compression\nfee_recipients Encoding Scheme\n\nHow Derivation works with Span Batches\nIntegration\n\nChannel Reader (Batch Decoding)\nBatch Queue\nBatcher\n\nIntroduction\nSpan-batch is a new batching spec that reduces overhead of OP-stack chains,\nintroduced in Delta network upgrade.\nThis enables sparse and low-throughput OP-stack chains.\nThe overhead is reduced by representing a span of\nconsecutive L2 blocks in a more efficient manner,\nwhile preserving the same consistency checks as regular batch data.\nNote that the channel and\nframe formats stay the same:\ndata slicing, packing and multi-transaction transport is already optimized.\nThe overhead in the V0 batch format comes from:\n\nThe meta-data attributes are repeated for every L2 block, while these are mostly implied already:\n\nparent hash (32 bytes)\nL1 epoch: blockhash (32 bytes) and block number (~4 bytes)\ntimestamp (~4 bytes)\n\nThe organization of block data is inefficient:\n\nSimilar attributes are far apart, diminishing any chances of effective compression.\nRandom data like hashes are positioned in-between the more compressible application data.\n\nThe RLP encoding of the data adds unnecessary overhead\n\nThe outer list does not have to be length encoded, the attributes are known\nFixed-length attributes do not need any encoding\nThe batch-format is static and can be optimized further\n\nRemaining meta-data for consistency checks can be optimized further:\n\nThe metadata only needs to be secure for consistency checks. E.g. 20 bytes of a hash may be enough.\n\nSpan-batches address these inefficiencies, with a new batch format version.\nSpan batch format\nNote that span-batches, unlike previous singular batches,\nencode a range of consecutive L2 blocks at the same time.\nIntroduce version 1 to the batch-format table:\nbatch_versioncontent\n1prefix ++ payload\n\nNotation:\n\n++: concatenation of byte-strings\nspan_start: first L2 block in the span\nspan_end: last L2 block in the span\nuvarint: unsigned Base128 varint, as defined in protobuf spec\nrlp_encode: a function that encodes a batch according to the RLP format,\nand [x, y, z] denotes a list containing items x, y and z\n\nStandard bitlists, in the context of span-batches, are encoded as big-endian integers,\nleft-padded with zeroes to the next multiple of 8 bits.\nWhere:\n\nprefix = rel_timestamp ++ l1_origin_num ++ parent_check ++ l1_origin_check\n\nrel_timestamp: uvarint relative timestamp since L2 genesis,\ni.e. span_start.timestamp - config.genesis.timestamp.\nl1_origin_num: uvarint number of last l1 origin number. i.e. span_end.l1_origin.number\nparent_check: first 20 bytes of parent hash, the hash is truncated to 20 bytes for efficiency,\ni.e. span_start.parent_hash[:20].\nl1_origin_check: the block hash of the last L1 origin is referenced.\nThe hash is truncated to 20 bytes for efficiency, i.e. span_end.l1_origin.hash[:20].\n\npayload = block_count ++ origin_bits ++ block_tx_counts ++ txs:\n\nblock_count: uvarint number of L2 blocks. This is at least 1, empty span batches are invalid.\norigin_bits: standard bitlist of block_count bits:\n1 bit per L2 block, indicating if the L1 origin changed this L2 block.\nblock_tx_counts: for each block, a uvarint of len(block.transactions).\ntxs: L2 transactions which is reorganized and encoded as below.\n\ntxs = zero_to_bits ++ y_parity_bits ++ tx_sigs ++ tx_tos ++ tx_datas ++ tx_nonces ++ tx_gases ++ protected_bits\n\nzero_to_bits: standard bitlist of sum(block_tx_counts) bits:\n1 bit per L2 transactions, indicating that the transaction has no to field and therefore\nconsumes no entry from tx_tos. For transaction types that have a to field, a set bit is\nexactly the contract creation case.\nThis field was previously named contract_creation_bits. Only the name changed; the encoding\nand its meaning are unchanged.\ny_parity_bits: standard bitlist of sum(block_tx_counts) bits:\n1 bit per L2 transactions, indicating the y parity value when recovering transaction sender address.\ntx_sigs: concatenated list of transaction signatures\n\nr is encoded as big-endian uint256\ns is encoded as big-endian uint256\n\ntx_tos: concatenated list of to field. to field in contract creation transaction will be nil and ignored.\ntx_datas: concatenated list of variable length rlp encoded data,\nmatching the encoding of the fields as in the EIP-2718 format of the TransactionType.\n\nlegacy: rlp_encode(value, gasPrice, data)\n1: (EIP-2930): 0x01 ++ rlp_encode(value, gasPrice, data, accessList)\n2: (EIP-1559): 0x02 ++ rlp_encode(value, max_priority_fee_per_gas, max_fee_per_gas, data, access_list)\n\ntx_nonces: concatenated list of uvarint of nonce field.\ntx_gases: concatenated list of uvarint of gas limits.\n\nlegacy: gasLimit\n1: (EIP-2930): gasLimit\n2: (EIP-1559): gas_limit\n\nprotected_bits: standard bitlist of length of number of legacy transactions:\n1 bit per L2 legacy transactions, indicating if transaction is protected(EIP-155) or not.\n\nSpan Batch Size Limits\nThe total size of an encoded span batch is limited to MAX_RLP_BYTES_PER_CHANNEL, which is defined in the\nProtocol Parameters table.\nThis is done at the channel level rather than at the span batch level.\nIn addition to the byte limit, the number of blocks, and total transactions is limited to MAX_SPAN_BATCH_ELEMENT_COUNT.\nThis does imply that the max number of transactions per block is also MAX_SPAN_BATCH_ELEMENT_COUNT.\nMAX_SPAN_BATCH_ELEMENT_COUNT is defined in Protocol Parameters table.\nFuture batch-format extension\nThis is an experimental extension of the span-batch format, and not activated with the Delta upgrade yet.\nIntroduce version 2 to the batch-format table:\nbatch_versioncontent\n2prefix ++ payload\n\nWhere:\n\nprefix = rel_timestamp ++ l1_origin_num ++ parent_check ++ l1_origin_check:\n\nIdentical to batch_version 1\n\npayload = block_count ++ origin_bits ++ block_tx_counts ++ txs ++ fee_recipients:\n\nAn empty span-batch, i.e. with block_count == 0, is invalid and must not be processed.\nEvery field definition identical to batch_version 1 except that fee_recipients is\nadded to support more decentralized sequencing.\nfee_recipients = fee_recipients_idxs + fee_recipients_set\n\nfee_recipients_set: concatenated list of unique L2 fee recipient address.\nfee_recipients_idxs: for each block,\nuvarint number of index to decode fee recipients from fee_recipients_set.\n\nSpan Batch Activation Rule\nThe span batch upgrade is activated based on timestamp.\nActivation Rule: upgradeTime != null && span_start.l1_origin.timestamp >= upgradeTime\nspan_start.l1_origin.timestamp is the L1 origin block timestamp of the first block in the span batch.\nThis rule ensures that every chain activity regarding this span batch is done after the hard fork.\ni.e. Every block in the span is created, submitted to the L1, and derived from the L1 after the hard fork.\nOptimization Strategies\nTruncating information and storing only necessary data\nThe following fields stores truncated data:\n\nrel_timestamp: We can save two bytes by storing rel_timestamp instead of the full span_start.timestamp.\nparent_check and l1_origin_check: We can save twelve bytes by truncating twelve bytes from the full hash,\nwhile having enough safety.\n\ntx_data_headers removal from initial specs\nWe do not need to store length per each tx_datas elements even if those are variable length,\nbecause the elements itself is RLP encoded, containing their length in RLP prefix.\nChain ID removal from initial specs\nEvery transaction has chain id. We do not need to include chain id in span batch because L2 already knows its chain id,\nand use its own value for processing span batches while derivation.\nReorganization of constant length transaction fields\nsignature, nonce, gaslimit, to field are constant size, so these were split up completely and\nare grouped into individual arrays.\nThis adds more complexity, but organizes data for improved compression by grouping data with similar data pattern.\nRLP encoding for only variable length fields\nFurther size optimization can be done by packing variable length fields, such as access_list.\nHowever, doing this will introduce much more code complexity, compared to benefiting from size reduction.\nOur goal is to find the sweet spot on code complexity - span batch size tradeoff.\nI decided that using RLP for all variable length fields will be the best option,\nnot risking codebase with gnarly custom encoding/decoding implementations.\nStore y_parity and protected_bit instead of v\nOnly legacy type transactions can be optionally protected. If protected(EIP-155), v = 2 * ChainID + 35 + y_parity.\nElse, v = 27 + y_parity. For other types of transactions, v = y_parity.\nWe store y_parity, which is single bit per L2 transaction.\nWe store protected_bit, which is single bit per L2 legacy type transactions to indicate that tx is protected.\nThis optimization will benefit more when ratio between number of legacy type transactions over number of transactions\nexcluding deposit tx is higher.\nDeposit transactions are excluded in batches and are never written at L1 so excluded while analyzing.\nAdjust txs Data Layout for Better Compression\nThere are (8 choose 2) * 6! = 20160 permutations of ordering fields of txs. It is not 8!\nbecause zero_to_bits must be first decoded in order to decode tx_tos. We\nexperimented with different data layouts and found that segregating random data (tx_sigs,\ntx_tos, tx_datas) from the rest most improved the zlib compression ratio.\nfee_recipients Encoding Scheme\nLet K := number of unique fee recipients(cardinality) per span batch. Let N := number of L2 blocks.\nIf we naively encode each fee recipients by concatenating every fee recipients, it will need 20 * N bytes.\nIf we manage fee_recipients_idxs and fee_recipients_set, It will need at most max uvarint size * N = 8 * N,\n20 * K bytes each. If 20 * N > 8 * N + 20 * K then maintaining an index of fee recipients is reduces the size.\nwe thought sequencer rotation happens not much often, so assumed that K will be much lesser than N.\nThe assumption makes upper inequality to hold. Therefore, we decided to manage fee_recipients_idxs and\nfee_recipients_set separately. This adds complexity but reduces data.\nHow Derivation works with Span Batches\n\nBlock Timestamp\n\nThe first L2 block's block timestamp is rel_timestamp + L2Genesis.Timestamp.\nThen we can derive other blocks timestamp by adding L2 block time for each.\n\nL1 Origin Number\n\nThe parent of the first L2 block's L1 origin number is l1_origin_num - sum(origin_bits)\nThen we can derive other blocks' L1 origin number with origin_bits\n\ni-th block's L1 origin number = (i-1)th block's L1 origin number + (origin_bits[i] ? 1 : 0)\n\nL1 Origin Hash\n\nWe only need the l1_origin_check, the truncated L1 origin hash of the last L2 block of Span Batch.\nIf the last block references canonical L1 chain as its origin,\nwe can ensure the all other blocks' origins are consistent with the canonical L1 chain.\n\nParent hash\n\nIn V0 Batch spec, we need batch's parent hash to validate if batch's parent is consistent with current L2 safe head.\nBut in the case of Span Batch, because it contains consecutive L2 blocks in the span,\nwe do not need to validate all blocks' parent hash except the first block.\n\nTransactions\n\nDeposit transactions can be derived from its L1 origin, identical with V0 batch.\nUser transactions can be derived by following way:\n\nRecover V value of TX signature from y_parity_bits and L2 chain id, as described in optimization strategies.\nWhen parsing tx_tos, zero_to_bits is used to determine if the TX has to value or not.\n\nIntegration\nChannel Reader (Batch Decoding)\nThe Channel Reader decodes the span-batch, as described in the span-batch format.\nA set of derived attributes is computed as described above. Then cached with the decoded result:\nBatch Queue\nA span-batch is buffered as a singular large batch,\nby its starting timestamp (transformed rel_timestamp).\nSpan-batches share the same queue with v0 batches: batches are processed in L1 inclusion order.\nA set of modified validation rules apply to the span-batches.\nRules are enforced with the contextual definitions as v0-batch validation:\nepoch, inclusion_block_number, next_timestamp\nDefinitions:\n\nbatch as defined in the Span batch format section.\nprev_l2_block is the L2 block from the current safe chain,\nwhose timestamp is at span_start.timestamp - l2_block_time\n\nSpan-batch rules, in validation order:\n\nbatch_origin is determined like with singular batches:\n\nbatch.epoch_num == epoch.number+1:\n\nIf next_epoch is not known -> undecided:\ni.e. a batch that changes the L1 origin cannot be processed until we have the L1 origin data.\nIf known, then define batch_origin as next_epoch\n\nbatch_origin.timestamp < span_batch_upgrade_timestamp -> drop:\ni.e. enforce the span batch upgrade activation rule.\nspan_start.timestamp > next_timestamp -> future: i.e. the batch must be ready to process,\nbut does not have to start exactly at the next_timestamp, since it can overlap with previously processed blocks,\nspan_end.timestamp < next_timestamp -> drop: i.e. the batch must have at least one new block to process.\nIf there's no prev_l2_block in the current safe chain -> drop: i.e. the timestamp must be aligned.\nbatch.parent_check != prev_l2_block.hash[:20] -> drop:\ni.e. the checked part of the parent hash must be equal to the same part of the corresponding L2 block hash.\nSequencing-window checks:\n\nNote: The sequencing window is enforced for the batch as a whole:\nif the batch was partially invalid instead, it would drop the oldest L2 blocks,\nwhich makes the later L2 blocks invalid.\nVariables:\n\norigin_changed_bit = origin_bits[0]: true if the first L2 block changed its L1 origin, false otherwise.\nstart_epoch_num = batch.l1_origin_num - sum(origin_bits) + (origin_changed_bit ? 1 : 0)\nend_epoch_num = batch.l1_origin_num\n\nRules:\n\nstart_epoch_num + sequence_window_size < inclusion_block_number -> drop:\ni.e. the batch must be included timely.\nstart_epoch_num > prev_l2_block.l1_origin.number + 1 -> drop:\ni.e. the L1 origin cannot change by more than one L1 block per L2 block.\nIf batch.l1_origin_check does not match the canonical L1 chain at end_epoch_num -> drop:\nverify the batch is intended for this L1 chain.\n\nAfter upper l1_origin_check check is passed, we don't need to check if the origin\nis past inclusion_block_number because of the following invariant.\nInvariant: the epoch-num in the batch is always less than the inclusion block number,\nif and only if the L1 epoch hash is correct.\n\nstart_epoch_num < prev_l2_block.l1_origin.number -> drop:\nepoch number cannot be older than the origin of parent block\n\nMax Sequencer time-drift & other L1 origin checks:\n\nNote: The max time-drift is enforced for the batch as a whole, to keep the possible output variants small.\nVariables:\n\nblock_input: an L2 block from the span-batch,\nwith L1 origin as derived from the origin_bits and now established canonical L1 chain.\nnext_epoch: block_input.origin's next L1 block.\nIt may reach to the next origin outside the L1 origins of the span.\n\nRules:\n\nFor each block_input whose timestamp is greater than safe_head.timestamp:\n\nblock_input.l1_origin.number < safe_head.l1_origin.number -> drop: enforce increasing L1 origins.\nblock_input.timestamp < block_input.origin.time -> drop: enforce the min L2 timestamp rule.\nblock_input.timestamp > block_input.origin.time + max_sequencer_drift: enforce the L2 timestamp drift rule,\nbut with exceptions to preserve above min L2 timestamp invariant:\n\nlen(block_input.transactions) == 0:\n\norigin_bits[i] == 0: i is the index of block_input in the span batch.\nSo this implies the block_input did not advance the L1 origin,\nand must thus be checked against next_epoch.\n\nIf next_epoch is not known -> undecided:\nwithout the next L1 origin we cannot yet determine if time invariant could have been kept.\nIf block_input.timestamp >= next_epoch.time -> drop:\nthe batch could have adopted the next L1 origin without breaking the L2 time >= L1 time invariant.\n\nlen(block_input.transactions) > 0: -> drop:\nwhen exceeding the sequencer time drift, never allow the sequencer to include transactions.\n\nAnd for all transactions:\n\ndrop if the batch.tx_datas list contains a transaction\nthat is invalid or derived by other means exclusively:\n\nany transaction that is empty (zero length tx_data)\nany deposited transactions (identified by the transaction type prefix byte in tx_data)\nany transaction of a future type > 2 (note that\nIsthmus adds support\nfor SetCode transactions of type 4\nand Lagoon adds PostExec transactions of type 0x7d)\n\nOverlapped blocks checks:\n\nNote: If the span batch overlaps the current L2 safe chain, we must validate all overlapped blocks.\nVariables:\n\nblock_input: an L2 block derived from the span-batch.\nsafe_block: an L2 block from the current L2 safe chain, at same timestamp as block_input\n\nRules:\n\nFor each block_input, whose timestamp is less than next_timestamp:\n\nblock_input.l1_origin.number != safe_block.l1_origin.number -> drop\nblock_input.transactions != safe_block.transactions -> drop\n\ncompare excluding deposit transactions\n\nOnce validated, the batch-queue then emits a block-input for each of the blocks included in the span-batch.\nThe next derivation stage is thus only aware of individual block inputs, similar to the previous V0 batch,\nalthough not strictly a \"v0 batch\" anymore.\nBatcher\nInstead of transforming L2 blocks into batches,\nthe blocks should be buffered to form a span-batch.\nIdeally the L2 blocks are buffered as block-inputs, to maximize the span of blocks covered by the span-batch:\nspan-batches of single L2 blocks do not increase efficiency as much as with larger spans.\nThis means that the (c *channelBuilder) AddBlock function is changed to\nnot directly call (co *ChannelOut) AddBatch but defer that until a minimum number of blocks have been buffered.\nOutput-size estimation of the queued up blocks is not possible until the span-batch is written to the channel.\nPast a given number of blocks, the channel may be written for estimation, and then re-written if more blocks arrive.\nThe batcher functionality stays the same otherwise: unsafe blocks are transformed into batches,\nencoded in compressed channels, and then split into frames for submission to L1.\nBatcher implementations can implement different heuristics and re-attempts to build the most gas-efficient data-txs.","tokens":4688,"squid":"ink-governance","role":"Council Listener","at":1791264665515,"hash":"59f4729a12f36aaa5ab04d7163729d640985d444"}
{"url":"https://forum.openzeppelin.com/t/buy-direct-with-crowdsale-without-using-the-buytokens-function/10452/1","domain":"forum.openzeppelin.com","title":"Buy direct with Crowdsale without using the buyTokens function - Support - OpenZeppelin Forum","text":"Buy direct with Crowdsale without using the buyTokens function \n\n Support\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2021\n\n 1 / 24\n\n Jun 2021\n\n Jul 2021\n\n post by Cainuriel on Jun 13, 2021\n\n Cainuriel\n\n First of all, thank the entire community for all the facilities with the standards they share. Thank you very much for saving us so much time.\nI have successfully implemented the Crowdsale.sol standard for a token sale. But I would like to use it without using the buytokens function. The idea is that an income is made in the contract, with a fixed amount of weis, and receives the corresponding amount of tokens.\n function buyTokens(address _beneficiary) public payable {\n\n uint256 weiAmount = msg.value;\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n _updatePurchasingState(_beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(_beneficiary, weiAmount);\n }\n\nHow to make the function execute internally in each entry of weis in the contract, relating the parameter address _beneficiary with the msg.sender?\nAnother way of saying it is that the contract is listening to activate the shipment if I receive the money.\nThank you\n\n 13\n\n 9\n\n read \n\n 5\n min\n\n post by FreezyEx on Jun 13, 2021\n\n FreezyEx\n\n Hey I have done something similar\n\n post by Cainuriel on Jun 14, 2021\n\n Cainuriel\n\n Ops its wonderfull!\nI see that you have the minimum purchase but I do not see the maximum purchase that is thehardcap and softcap? True?\nIt is a very complete contract, it has everything. But, entering weis does not return tokens…\nfallback function no works. When send ethers need more gas, thats its ok, but always return a execution reverted…\nDoes it have to be enabled in some way?\n\n 1 month later\n\n post by Komeil_Mirsamie on Jul 24, 2021\n\n Komeil_Mirsamie\n\n FreezyEx\n\n Hey Man, your contract give me \"execution reverted\" error when I want to deploy it in testserver!\n\n post by Cainuriel on Jul 25, 2021\n\n Cainuriel\n\n I have made a purchase contract with these characteristics, inheriting from Crowdsale and overwriting the buytokens method.\n/SPDX-License-Identifier: Unlicense\n\npragma solidity ^0.6.12;\n\nimport \"./Crowdsale.sol\";\nimport \"./Ownable.sol\";\n//import \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n//import \"@openzeppelin/contracts/token/ERC20/Ownable.sol\";\n//import \"hardhat/console.sol\";\n\n// trusty contrato de fernando: 0x21176b07a996E62C905e5bf29b1E3e8F1f237d8A\n\n/**\n * Standard de preventa con algunas customizacinones personales.\n *\n *endsold: para la preventa y envia los tokens que no se hayan vendido\n *al propietario\n *TokenBalance: Indica la cantidad de tokens que hay en el contrato\n*\n Setrate: Cambia la cantidad de tokens a enviar por 1 BNB cuando queramos.\n *\\\n */\n\ninterface TokenInterface {\n // determinamos las funciones que necesitamos del ERC20. Tienen que ser iguales.\n function decimals() external view returns(uint8);\n function balanceOf(address _address) external view returns(uint256);\n function transfer(address _to, uint256 _value) external returns (bool success);\n}\n\ncontract SALETOKEN is Crowdsale, Ownable {\n\n uint256 public limitBuy = 3000000000000000000;\n\n uint256 public minRate = 100000;\n uint256 public maxRate = 220000;\n\n TokenInterface TokenContract; // interface para manipular metodos del token.\n\n // tanto _token como _addresstoken son la misma direccion. La diferencia esta en su uso.\n // Debemos pasarlo como contrato y como direccion para \n // hacer operaciones diferentes.\n constructor (uint256 _rate, \n address payable _wallet, \n BEP20 _token,\n address _addressToken\n ) \n\n Crowdsale(_rate, _wallet, _token) \n\n public {\n\n require(_rate >= minRate && _rate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n\n // pásamos el contrato del token, como direccion para ser usada por la interface\n TokenContract = TokenInterface(_addressToken);\n\n //console.log(\"Desplegado contrato de venta de los tokens del contrato: \", _token);\n\n }\n\n // Funcion que liquida el contrato para que no se pueda vender mas.\n function endSold() public onlyOwner() {\n\n // compensacion de saldos. \n require(TokenContract.transfer(owner(), TokenContract.balanceOf(address(this))));\n msg.sender.transfer(address(this).balance);\n weiRaised = 0;\n\n }\n\n function TokenBalance() public view returns (uint256) {\n return TokenContract.balanceOf(address(this));\n\n }\n\n function setRate(uint256 _newrate) public onlyOwner() {\n\n require(_newrate >= minRate && _newrate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n rate = _newrate;\n }\n\n function setLimitBuy(uint256 _newLimit) public onlyOwner() {\n limitBuy = _newLimit;\n }\n\n function setLimirates(uint256 _newLimitminRate, uint256 _newLimitmaxRate) public onlyOwner() {\n minRate = _newLimitminRate;\n maxRate = _newLimitmaxRate;\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * @param _beneficiary Address performing the token purchase\n */\n function buyTokens(address _beneficiary) public override payable {\n\n require(TokenContract.balanceOf(_beneficiary) <= limitBuy.mul(rate), \"Esta cuenta ya tiene el limite de tokens permitido para la preventa\");\n\n uint256 weiAmount = msg.value;\n\n require(weiAmount <= limitBuy, \"Compra excede el máximo de BNBs permitido\");\n\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n }\n\n}\n\nBut I'm still waiting for someone to explain to me why the receive function doesn't work. It works perfectly with its corresponding frontend.\n\n post by Skyge on Jul 25, 2021\n\n Skyge\n\nreceive function? Do you mean the function buyTokens()\n\n post by Cainuriel on Jul 25, 2021\n\n Cainuriel\n\n No @Skyge ,\nI mean that it works that:\n receive () external payable {\n buyTokens(msg.sender);\n }\n\nis within the crowdsale contract:.\n\n post by Skyge on Jul 25, 2021\n\n Skyge\n\n What is the source code of the Crowdsale contract, I did not find a suitable contract in the OpenZeppelin repo, in the branch named release-v2.5.0, the compiler version of the contract is 0.5.x\n\n post by Cainuriel on Jul 26, 2021\n\n Cainuriel\n\nRight now I share it with you\n\n//SPDX-License-Identifier: Unlicense\npragma solidity ^0.6.12;\n\nimport \"./BEP20.sol\";\nimport \"./SafeMath.sol\";\n\n/**\n * @title Crowdsale\n * @dev Crowdsale is a base contract for managing a token crowdsale,\n * allowing investors to purchase tokens with ether. This contract implements\n * such functionality in its most fundamental form and can be extended to provide additional\n * functionality and/or custom behavior.\n * The external interface represents the basic interface for purchasing tokens, and conform\n * the base architecture for crowdsales. They are *not* intended to be modified / overriden.\n * The internal interface conforms the extensible and modifiable surface of crowdsales. Override\n * the methods to add functionality. Consider using 'super' where appropiate to concatenate\n * behavior.\n */\ncontract Crowdsale {\n using SafeMath for uint256;\n\n // The token being sold\n BEP20 public token;\n\n // Address where funds are collected\n address payable public wallet;\n\n // How many token units a buyer gets per wei\n uint256 public rate;\n\n // Amount of wei raised\n uint256 public weiRaised;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokenPurchase(\n address indexed purchaser,\n address indexed beneficiary,\n uint256 value,\n uint256 amount\n );\n\n /**\n * @param _rate Number of token units a buyer gets per wei\n * @param _wallet Address where collected funds will be forwarded to\n * @param _token Address of the token being sold\n */\n constructor(uint256 _rate, address payable _wallet, BEP20 _token) public {\n require(_rate > 0);\n require(_wallet != address(0));\n// require(_token != address(0));\n\n rate = _rate;\n wallet = _wallet;\n token = _token;\n }\n\n // -----------------------------------------\n // Crowdsale external interface\n // -----------------------------------------\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n */\n fallback () external payable {\n buyTokens(msg.sender);\n }\n\n receive () external payable {\n buyTokens(msg.sender);\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * @param _beneficiary Address performing the token purchase\n */\n function buyTokens(address _beneficiary) public virtual payable {\n\n uint256 weiAmount = msg.value;\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n _updatePurchasingState(_beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(_beneficiary, weiAmount);\n }\n\n // -----------------------------------------\n // Internal interface (extensible)\n // -----------------------------------------\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met. Use super to concatenate validations.\n * @param _beneficiary Address performing the token purchase\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(\n address _beneficiary,\n uint256 _weiAmount\n )\n pure internal\n {\n require(_beneficiary != address(0));\n require(_weiAmount != 0);\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid conditions are not met.\n * @param _beneficiary Address performing the token purchase\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(\n address _beneficiary,\n uint256 _weiAmount\n )\n internal\n {\n // optional override\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends its tokens.\n * @param _beneficiary Address performing the token purchase\n * @param _tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(\n address _beneficiary,\n uint256 _tokenAmount\n )\n internal\n {\n token.transfer(_beneficiary, _tokenAmount);\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Not necessarily emits/sends tokens.\n * @param _beneficiary Address receiving the tokens\n * @param _tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(\n address _beneficiary,\n uint256 _tokenAmount\n )\n internal\n {\n _deliverTokens(_beneficiary, _tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions, etc.)\n * @param _beneficiary Address receiving the tokens\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(\n address _beneficiary,\n uint256 _weiAmount\n )\n internal\n {\n // optional override\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param _weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n wallet.transfer(msg.value);\n }\n}\n\nI have to say that I introduced the receive function by recommendation of remix. In the original contract there is only the fallback\n\n post by Skyge on Jul 26, 2021\n\n Skyge\n\n Really a little difficult to get your full code to have a test!\nI have deployed contracts like followings and had a try, all worked well:\n\nCrowdsale token\nCrowdsale contract\nTransfer crowdsale token to crowdsale contract\nUse receive function to buy crowdsale token\n\nRate = 200000, so when use 20 * 10^9 wei to buy crowdsale token, the amount I can get is: 20 * 10^9 * rate = 4*10**15=0.004DAI\n\n post by Skyge on Jul 26, 2021\n\n Skyge\n\n Cainuriel\n\n And I think you can have a look at this tutorial to learn:\n\nSimple ERC20 Crowdsale - General / Guides and Tutorials - OpenZeppelin Community\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nFirst of all, thank you for your effort in trying to help me.\nBut the contract works perfectly for me. Except for the aforementioned function.\nIf you tell me what error you have, maybe I can help you so that you can help me.\nNote that the constructor has to enter TWO TIMES the token contract.\nOne argument is to be used by Crowdsale, and the other is to be used as an interface.\n constructor (uint256 _rate, \n address payable _wallet, \n BEP20 _token,\n address _addressToken\n ) \n\n Crowdsale(_rate, _wallet, _token) \n\n public {\n\n require(_rate >= minRate && _rate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n\n // pásamos el contrato del token, como direccion para ser usada por la interface\n TokenContract = TokenInterface(_addressToken);\n\n //console.log(\"Desplegado contrato de venta de los tokens del contrato: \", _token);\n\n }\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n So is the current problem you can not buy token by calling receive()?\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nThe rate calculates the amount of tokens that will be received for each ETH or BNB.\nIn this function from the Standard contract Crowdsale:\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate);\n }\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nExactly, that's the only problem. It is not necessary because we have built a DAPP but I would like to know why it does not work. should, not?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\nBut it works for me. Here were transaction:\n\nUse receive function to buy crowdsale token\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nWhat!!\nHave you achieved it by sending the money directly?\nWell, I don't know why I can't. I am quite upset...\n... any idea, limit gas may be?\nThank you very much for your help..\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\n Skyge\n\n Yes!! that was the problem...\nWe need almost 300000 of limit gas...\n\nIt is very expensive right?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\nSorry, I am not sure.\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n Cainuriel\n\nimage2058×1096 159 KB\n\nBut just like above, I only use 73k gas.\n\n Load more posts below","tokens":3728,"squid":"ink-security_audits","role":"Sentinel","at":1791264673538,"hash":"59369e3440a5d5d403530d1ed4c7342a367c7756"}
{"url":"https://specs.optimism.io/protocol/safer-safes.html","domain":"specs.optimism.io","title":"Safer Safes - OP Stack Specification","text":"Safer Safes\n\nTable of Contents\n\nStatus\nOverview\nDefinitions\n\nSafe\nOwner\nQuorum\nBlocking Threshold\nFallback Owner\nLiveness Challenge\nLiveness Response Period\nTimelock Delay\nScheduled Transaction\nCancellation Threshold\nTimelock Configuration Generation\nModule Transaction\n\nAssumptions\n\naSAFE-001: Safe contracts are correct and compatible\n\nMitigations\n\naSAFE-002: Safe owners choose correct configuration\n\nMitigations\n\naSAFE-003: Fallback owner is honest and live\n\nMitigations\n\naSAFE-004: Ethereum provides timely inclusion and reliable timestamps\n\nMitigations\n\naSAFE-005: Enabled modules are constrained\n\nMitigations\n\nInvariants\n\niSAFE-001: Safe controls its own extension configuration\n\nImpact\n\niSAFE-002: Liveness recovery only succeeds after an unanswered challenge\n\nImpact\n\niSAFE-003: A live Safe can cancel a liveness challenge\n\nImpact\n\niSAFE-004: Successful liveness recovery produces a recoverable Safe\n\nImpact\n\niSAFE-005: Liveness challenges cannot be spammed for the same Safe\n\nImpact\n\niSAFE-006: Combined timing leaves room for liveness response\n\nImpact\n\niSAFE-007: Timelock protects owner-executed Safe transactions\n\nImpact\n\niSAFE-008: Timelock execution requires a current owner executor\n\nImpact\n\niSAFE-009: Scheduled transaction timing is stable\n\nImpact\n\niSAFE-010: Cancellation authority comes from current Safe owners\n\nImpact\n\niSAFE-011: Cancellation threshold remains bounded\n\nImpact\n\niSAFE-012: Timelock clearing isolates old state\n\nImpact\n\niSAFE-013: Guard removal exposes old Safe signatures\n\nImpact\n\niSAFE-014: Module transactions are outside timelock scope\n\nImpact\n\nStatus\nProduction\nOverview\nSaferSafes is a singleton Safe extension that can be installed as both a Safe module and a Safe\nguard. It is intended to replace the original Safe Contract Extensions\nwhere adopted.\nSaferSafes provides two independent capabilities:\n\nLiveness recovery: A configured fallback owner can challenge a Safe to prove that it remains\nlive. If the Safe does not cancel the challenge before the response window expires, control of the\nSafe transfers to the fallback owner.\nTransaction timelock: Owner-executed Safe transactions must be scheduled before execution\nand cannot execute until the configured delay has elapsed. A subset of owners can cancel a\nscheduled transaction before it executes.\n\nThe liveness module and timelock guard can be enabled independently. When both are enabled and\nconfigured for the same Safe, their configuration must leave enough time for the Safe to schedule\nand execute a liveness response before fallback ownership can be claimed.\nSaferSafes is designed for Safes that use Safe version 1.4.1.\nDefinitions\nSafe\nThe Safe account that has installed SaferSafes as a module, a guard, or both.\nOwner\nAn address that is a current owner of a Safe, according to the Safe's owner set.\nQuorum\nThe Safe threshold: the number of owner approvals required for the Safe to execute an\nowner-authorized transaction.\nBlocking Threshold\nThe minimum number of owners that can prevent a transaction from reaching Quorum by\nwithholding approval. It is equal to total_owners - quorum + 1.\nFallback Owner\nThe account configured by the Safe to receive sole ownership if a liveness challenge succeeds. The\nfallback owner is also the only account that can start a liveness challenge or claim ownership after\nthe response window expires.\nLiveness Challenge\nA claim by the Fallback Owner that the Safe may no longer be live. A liveness\nchallenge starts a response window during which the Safe can demonstrate liveness by cancelling the\nchallenge.\nLiveness Response Period\nThe amount of time the Safe has to cancel a Liveness Challenge before the\nchallenge can succeed.\nTimelock Delay\nThe minimum amount of time that must elapse between scheduling an owner-executed Safe transaction\nand executing it.\nScheduled Transaction\nAn owner-authorized Safe transaction that has been registered with SaferSafes for execution after\nthe Timelock Delay.\nCancellation Threshold\nThe number of owner approvals required to cancel a Scheduled Transaction.\nThe threshold starts at one for a configured Safe, increases after cancellations, and is capped at\nthe lower of Quorum and Blocking Threshold.\nTimelock Configuration Generation\nThe active generation of timelock state for a Safe. Clearing timelock configuration moves the Safe\nto a fresh generation so previously scheduled, cancelled, or executed transactions are no longer\npart of the active timelock state.\nModule Transaction\nA transaction that a Safe executes through an enabled Safe module rather than through the Safe's\nowner-executed transaction path.\nAssumptions\naSAFE-001: Safe contracts are correct and compatible\nSaferSafes assumes the underlying Safe contract correctly implements owner management, threshold\nmanagement, signature validation, module execution, guard execution, nonce handling, and version\nreporting.\nSaferSafes is designed for Safe version 1.4.1. Behavior with other Safe versions is not guaranteed.\nMitigations\n\nSaferSafes validates the Safe version during configuration.\nSafe contracts are externally audited and widely used.\nSaferSafes relies on the Safe as the source of truth for owners, threshold, signatures, modules,\nguards, and nonce state.\n\naSAFE-002: Safe owners choose correct configuration\nSaferSafes assumes that Safe owners choose an appropriate fallback owner, liveness response period,\nand timelock delay for the Safe's operational and governance requirements.\nMitigations\n\nConfiguration changes are authorized by the Safe itself.\nThe fallback owner and timing parameters are visible onchain.\nWhen the liveness module and timelock guard are both active, SaferSafes rejects configurations\nthat do not leave enough time for a liveness response through the timelock.\n\naSAFE-003: Fallback owner is honest and live\nSaferSafes assumes the fallback owner acts in the Safe's best interest and can act when recovery is\nneeded.\nMitigations\n\nThe Safe chooses its own fallback owner.\nThe fallback owner should have stronger security and availability guarantees than the Safe it can\nrecover.\nThe fallback owner should itself be a Safe or another account that can execute batches, because\nrecovery may need to pair ownership transfer with nonce-bumping transactions.\n\naSAFE-004: Ethereum provides timely inclusion and reliable timestamps\nSaferSafes assumes Ethereum block timestamps are suitable for enforcing liveness response periods\nand timelock delays, and that transactions can be included within operationally reasonable time\nbounds.\nMitigations\n\nLiveness response periods and timelock delays should be configured with enough buffer for network\ncongestion, coordination delays, and transaction replacement.\nThe combined configuration requirement provides additional buffer when both capabilities are used\ntogether.\n\naSAFE-005: Enabled modules are constrained\nSaferSafes assumes that enabled Safe modules are independently constrained to the actions they are\nintended to perform. Timelock protection applies to owner-executed Safe transactions and does not\ndelay module transactions.\nMitigations\n\nModules should be reviewed under their own authorization and action-scope invariants.\nExisting OP Stack modules such as the Deputy Pause Module and liveness recovery module are\ndesigned for narrowly scoped actions.\nNew modules must explicitly consider whether they should be delayed by a guard.\n\nInvariants\niSAFE-001: Safe controls its own extension configuration\nA Safe must control whether SaferSafes is configured for that Safe. No external account may choose\nthe Safe's fallback owner, liveness response period, timelock delay, or active timelock generation.\nThe fallback owner may start liveness challenges and claim ownership after a successful challenge,\nbut cannot configure arbitrary SaferSafes parameters for the Safe.\nImpact\nSeverity: Critical\nIf violated, an attacker could configure themselves as fallback owner, disable timelock protection,\nor clear timelock state without Safe authorization, leading to unauthorized control or execution.\niSAFE-002: Liveness recovery only succeeds after an unanswered challenge\nFallback ownership transfer must only be possible when all of the following are true:\n\nThe Safe configured liveness recovery.\nSaferSafes remains enabled as a module for that Safe.\nThe fallback owner started an active liveness challenge.\nThe liveness response period for that challenge has elapsed.\nThe Safe has not cancelled the challenge.\n\nImpact\nSeverity: Critical\nIf violated, ownership could transfer to the fallback owner while a quorum of owners remains live\nand able to operate the Safe.\niSAFE-003: A live Safe can cancel a liveness challenge\nA configured Safe that remains live must be able to cancel an active liveness challenge through a\nSafe-authorized transaction while SaferSafes remains enabled as a module.\nImpact\nSeverity: Critical\nIf violated, a live Safe could lose ownership to the fallback owner despite retaining enough owner\ncontrol to operate.\niSAFE-004: Successful liveness recovery produces a recoverable Safe\nAfter a successful liveness recovery, the fallback owner must be the Safe's sole owner, the Safe\nthreshold must be one, the active challenge must be cleared, and the Safe guard must be removed.\nImpact\nSeverity: Critical\nIf violated, recovery could leave the Safe unusable, leave old owners with authority, or leave a\nguard in place that prevents the fallback owner from restoring operations.\niSAFE-005: Liveness challenges cannot be spammed for the same Safe\nAt most one liveness challenge may be active for a Safe at a time. Reconfiguration or clearing of\nliveness recovery must clear any active challenge for that Safe.\nImpact\nSeverity: High\nIf violated, repeated challenges could create unnecessary operational load or make challenge\ntiming ambiguous, increasing the chance of accidental fallback ownership transfer.\niSAFE-006: Combined timing leaves room for liveness response\nWhen both liveness recovery and timelock protection are active for the same Safe, the liveness\nresponse period must be at least twice the timelock delay.\nImpact\nSeverity: High\nIf violated, a Safe could be unable to schedule and execute a liveness response through the\ntimelock before the liveness response period expires.\niSAFE-007: Timelock protects owner-executed Safe transactions\nWhen timelock protection is configured for a Safe, owner-executed Safe transactions must not\nexecute unless the transaction was scheduled, the scheduled execution time has arrived, and the\ntransaction has not been cancelled or already executed.\nImpact\nSeverity: Critical\nIf violated, an attacker with temporary access to enough owner approvals could bypass the delay and\nexecute malicious transactions before owners can detect and cancel them.\niSAFE-008: Timelock execution requires a current owner executor\nWhen timelock protection is configured for a Safe, execution of an owner-executed Safe transaction\nmust be initiated by a current owner of that Safe.\nImpact\nSeverity: High\nIf violated, an attacker who only obtains signatures could schedule and execute a transaction\nwithout also controlling an owner key, weakening the defense provided by the timelock.\niSAFE-009: Scheduled transaction timing is stable\nThe execution time for a scheduled transaction must not change while that transaction remains in\nthe active timelock generation. The same transaction must not be possible to schedule again after\nit has been scheduled, cancelled, or executed in that generation.\nImpact\nSeverity: High\nIf violated, an attacker could shorten the delay to bypass review or extend the delay to grief Safe\noperations. If cancelled transactions could be rescheduled with the same authorization, cancellation\nwould not reliably stop malicious signatures from being reused.\niSAFE-010: Cancellation authority comes from current Safe owners\nCancelling a scheduled transaction must require valid owner authorization meeting the current\ncancellation threshold for the Safe.\nImpact\nSeverity: High\nIf violated, non-owners could cancel legitimate transactions, or insufficient owner approval could\nblock Safe operations.\niSAFE-011: Cancellation threshold remains bounded\nThe cancellation threshold must start at one for a configured Safe, increase by one after each\nsuccessful cancellation, never exceed the lower of quorum and blocking threshold, and reset to one\nafter an owner-executed transaction reaches the execution path.\nImpact\nSeverity: High\nIf violated, cancellation could become unavailable to honest owners, or too few owners could\nrepeatedly cancel legitimate transactions and create a liveness failure.\niSAFE-012: Timelock clearing isolates old state\nClearing timelock configuration must move the Safe to a fresh timelock configuration generation so\nold scheduled, cancelled, and executed transaction state is not active after the Safe reconfigures\ntimelock protection.\nImpact\nSeverity: High\nIf violated, stale timelock state could block legitimate future transactions or unexpectedly allow\nold transaction state to affect a new configuration.\niSAFE-013: Guard removal exposes old Safe signatures\nRemoving the timelock guard must be treated as a security-sensitive operation. Once the guard is\nremoved, scheduled or cancelled transactions at or below the Safe nonce may become executable if\nvalid Safe signatures still exist.\nImpact\nSeverity: Critical\nIf ignored operationally, fallback recovery or timelock removal could make previously delayed or\ncancelled transactions executable. Recovery procedures should advance the Safe nonce past any\ntransaction that may have valid outstanding signatures.\niSAFE-014: Module transactions are outside timelock scope\nTimelock protection must not be assumed to delay module transactions. Any module enabled on the\nSafe must be safe without relying on SaferSafes timelock checks.\nImpact\nSeverity: High\nIf violated by system design, an enabled module could bypass the intended delay and execute actions\nthat owners expected to pass through the timelock.","tokens":3496,"squid":"ink-governance","role":"Council Listener","at":1791264676846,"hash":"14d9e8458c7f07d8fda2714cf2ad0dbf3d599dfc"}
{"url":"https://forum.openzeppelin.com/t/buy-direct-with-crowdsale-without-using-the-buytokens-function/10452/2","domain":"forum.openzeppelin.com","title":"Buy direct with Crowdsale without using the buyTokens function - Support - OpenZeppelin Forum","text":"Support\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2021\n\n 2 / 24\n\n Jun 2021\n\n Jul 2021\n\n post by Cainuriel on Jun 13, 2021\n\n Cainuriel\n\n First of all, thank the entire community for all the facilities with the standards they share. Thank you very much for saving us so much time.\nI have successfully implemented the Crowdsale.sol standard for a token sale. But I would like to use it without using the buytokens function. The idea is that an income is made in the contract, with a fixed amount of weis, and receives the corresponding amount of tokens.\n function buyTokens(address _beneficiary) public payable {\n\n uint256 weiAmount = msg.value;\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n _updatePurchasingState(_beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(_beneficiary, weiAmount);\n }\n\nHow to make the function execute internally in each entry of weis in the contract, relating the parameter address _beneficiary with the msg.sender?\nAnother way of saying it is that the contract is listening to activate the shipment if I receive the money.\nThank you\n\n 13\n\n 9\n\n read \n\n 5\n min\n\n post by FreezyEx on Jun 13, 2021\n\n FreezyEx\n\n Hey I have done something similar\n\n post by Cainuriel on Jun 14, 2021\n\n Cainuriel\n\n Ops its wonderfull!\nI see that you have the minimum purchase but I do not see the maximum purchase that is thehardcap and softcap? True?\nIt is a very complete contract, it has everything. But, entering weis does not return tokens…\nfallback function no works. When send ethers need more gas, thats its ok, but always return a execution reverted…\nDoes it have to be enabled in some way?\n\n 1 month later\n\n post by Komeil_Mirsamie on Jul 24, 2021\n\n Komeil_Mirsamie\n\n FreezyEx\n\n Hey Man, your contract give me \"execution reverted\" error when I want to deploy it in testserver!\n\n post by Cainuriel on Jul 25, 2021\n\n Cainuriel\n\n I have made a purchase contract with these characteristics, inheriting from Crowdsale and overwriting the buytokens method.\n/SPDX-License-Identifier: Unlicense\n\npragma solidity ^0.6.12;\n\nimport \"./Crowdsale.sol\";\nimport \"./Ownable.sol\";\n//import \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n//import \"@openzeppelin/contracts/token/ERC20/Ownable.sol\";\n//import \"hardhat/console.sol\";\n\n// trusty contrato de fernando: 0x21176b07a996E62C905e5bf29b1E3e8F1f237d8A\n\n/**\n * Standard de preventa con algunas customizacinones personales.\n *\n *endsold: para la preventa y envia los tokens que no se hayan vendido\n *al propietario\n *TokenBalance: Indica la cantidad de tokens que hay en el contrato\n*\n Setrate: Cambia la cantidad de tokens a enviar por 1 BNB cuando queramos.\n *\\\n */\n\ninterface TokenInterface {\n // determinamos las funciones que necesitamos del ERC20. Tienen que ser iguales.\n function decimals() external view returns(uint8);\n function balanceOf(address _address) external view returns(uint256);\n function transfer(address _to, uint256 _value) external returns (bool success);\n}\n\ncontract SALETOKEN is Crowdsale, Ownable {\n\n uint256 public limitBuy = 3000000000000000000;\n\n uint256 public minRate = 100000;\n uint256 public maxRate = 220000;\n\n TokenInterface TokenContract; // interface para manipular metodos del token.\n\n // tanto _token como _addresstoken son la misma direccion. La diferencia esta en su uso.\n // Debemos pasarlo como contrato y como direccion para \n // hacer operaciones diferentes.\n constructor (uint256 _rate, \n address payable _wallet, \n BEP20 _token,\n address _addressToken\n ) \n\n Crowdsale(_rate, _wallet, _token) \n\n public {\n\n require(_rate >= minRate && _rate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n\n // pásamos el contrato del token, como direccion para ser usada por la interface\n TokenContract = TokenInterface(_addressToken);\n\n //console.log(\"Desplegado contrato de venta de los tokens del contrato: \", _token);\n\n }\n\n // Funcion que liquida el contrato para que no se pueda vender mas.\n function endSold() public onlyOwner() {\n\n // compensacion de saldos. \n require(TokenContract.transfer(owner(), TokenContract.balanceOf(address(this))));\n msg.sender.transfer(address(this).balance);\n weiRaised = 0;\n\n }\n\n function TokenBalance() public view returns (uint256) {\n return TokenContract.balanceOf(address(this));\n\n }\n\n function setRate(uint256 _newrate) public onlyOwner() {\n\n require(_newrate >= minRate && _newrate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n rate = _newrate;\n }\n\n function setLimitBuy(uint256 _newLimit) public onlyOwner() {\n limitBuy = _newLimit;\n }\n\n function setLimirates(uint256 _newLimitminRate, uint256 _newLimitmaxRate) public onlyOwner() {\n minRate = _newLimitminRate;\n maxRate = _newLimitmaxRate;\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * @param _beneficiary Address performing the token purchase\n */\n function buyTokens(address _beneficiary) public override payable {\n\n require(TokenContract.balanceOf(_beneficiary) <= limitBuy.mul(rate), \"Esta cuenta ya tiene el limite de tokens permitido para la preventa\");\n\n uint256 weiAmount = msg.value;\n\n require(weiAmount <= limitBuy, \"Compra excede el máximo de BNBs permitido\");\n\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n }\n\n}\n\nBut I'm still waiting for someone to explain to me why the receive function doesn't work. It works perfectly with its corresponding frontend.\n\n post by Skyge on Jul 25, 2021\n\n Skyge\n\nreceive function? Do you mean the function buyTokens()\n\n post by Cainuriel on Jul 25, 2021\n\n Cainuriel\n\n No @Skyge ,\nI mean that it works that:\n receive () external payable {\n buyTokens(msg.sender);\n }\n\nis within the crowdsale contract:.\n\n post by Skyge on Jul 25, 2021\n\n Skyge\n\n What is the source code of the Crowdsale contract, I did not find a suitable contract in the OpenZeppelin repo, in the branch named release-v2.5.0, the compiler version of the contract is 0.5.x\n\n post by Cainuriel on Jul 26, 2021\n\n Cainuriel\n\nRight now I share it with you\n\n//SPDX-License-Identifier: Unlicense\npragma solidity ^0.6.12;\n\nimport \"./BEP20.sol\";\nimport \"./SafeMath.sol\";\n\n/**\n * @title Crowdsale\n * @dev Crowdsale is a base contract for managing a token crowdsale,\n * allowing investors to purchase tokens with ether. This contract implements\n * such functionality in its most fundamental form and can be extended to provide additional\n * functionality and/or custom behavior.\n * The external interface represents the basic interface for purchasing tokens, and conform\n * the base architecture for crowdsales. They are *not* intended to be modified / overriden.\n * The internal interface conforms the extensible and modifiable surface of crowdsales. Override\n * the methods to add functionality. Consider using 'super' where appropiate to concatenate\n * behavior.\n */\ncontract Crowdsale {\n using SafeMath for uint256;\n\n // The token being sold\n BEP20 public token;\n\n // Address where funds are collected\n address payable public wallet;\n\n // How many token units a buyer gets per wei\n uint256 public rate;\n\n // Amount of wei raised\n uint256 public weiRaised;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokenPurchase(\n address indexed purchaser,\n address indexed beneficiary,\n uint256 value,\n uint256 amount\n );\n\n /**\n * @param _rate Number of token units a buyer gets per wei\n * @param _wallet Address where collected funds will be forwarded to\n * @param _token Address of the token being sold\n */\n constructor(uint256 _rate, address payable _wallet, BEP20 _token) public {\n require(_rate > 0);\n require(_wallet != address(0));\n// require(_token != address(0));\n\n rate = _rate;\n wallet = _wallet;\n token = _token;\n }\n\n // -----------------------------------------\n // Crowdsale external interface\n // -----------------------------------------\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n */\n fallback () external payable {\n buyTokens(msg.sender);\n }\n\n receive () external payable {\n buyTokens(msg.sender);\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * @param _beneficiary Address performing the token purchase\n */\n function buyTokens(address _beneficiary) public virtual payable {\n\n uint256 weiAmount = msg.value;\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n _updatePurchasingState(_beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(_beneficiary, weiAmount);\n }\n\n // -----------------------------------------\n // Internal interface (extensible)\n // -----------------------------------------\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met. Use super to concatenate validations.\n * @param _beneficiary Address performing the token purchase\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(\n address _beneficiary,\n uint256 _weiAmount\n )\n pure internal\n {\n require(_beneficiary != address(0));\n require(_weiAmount != 0);\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid conditions are not met.\n * @param _beneficiary Address performing the token purchase\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(\n address _beneficiary,\n uint256 _weiAmount\n )\n internal\n {\n // optional override\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends its tokens.\n * @param _beneficiary Address performing the token purchase\n * @param _tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(\n address _beneficiary,\n uint256 _tokenAmount\n )\n internal\n {\n token.transfer(_beneficiary, _tokenAmount);\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Not necessarily emits/sends tokens.\n * @param _beneficiary Address receiving the tokens\n * @param _tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(\n address _beneficiary,\n uint256 _tokenAmount\n )\n internal\n {\n _deliverTokens(_beneficiary, _tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions, etc.)\n * @param _beneficiary Address receiving the tokens\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(\n address _beneficiary,\n uint256 _weiAmount\n )\n internal\n {\n // optional override\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param _weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n wallet.transfer(msg.value);\n }\n}\n\nI have to say that I introduced the receive function by recommendation of remix. In the original contract there is only the fallback\n\n post by Skyge on Jul 26, 2021\n\n Skyge\n\n Really a little difficult to get your full code to have a test!\nI have deployed contracts like followings and had a try, all worked well:\n\nCrowdsale token\nCrowdsale contract\nTransfer crowdsale token to crowdsale contract\nUse receive function to buy crowdsale token\n\nRate = 200000, so when use 20 * 10^9 wei to buy crowdsale token, the amount I can get is: 20 * 10^9 * rate = 4*10**15=0.004DAI\n\n post by Skyge on Jul 26, 2021\n\n Skyge\n\n Cainuriel\n\n And I think you can have a look at this tutorial to learn:\n\nSimple ERC20 Crowdsale - General / Guides and Tutorials - OpenZeppelin Community\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nFirst of all, thank you for your effort in trying to help me.\nBut the contract works perfectly for me. Except for the aforementioned function.\nIf you tell me what error you have, maybe I can help you so that you can help me.\nNote that the constructor has to enter TWO TIMES the token contract.\nOne argument is to be used by Crowdsale, and the other is to be used as an interface.\n constructor (uint256 _rate, \n address payable _wallet, \n BEP20 _token,\n address _addressToken\n ) \n\n Crowdsale(_rate, _wallet, _token) \n\n public {\n\n require(_rate >= minRate && _rate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n\n // pásamos el contrato del token, como direccion para ser usada por la interface\n TokenContract = TokenInterface(_addressToken);\n\n //console.log(\"Desplegado contrato de venta de los tokens del contrato: \", _token);\n\n }\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n So is the current problem you can not buy token by calling receive()?\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nThe rate calculates the amount of tokens that will be received for each ETH or BNB.\nIn this function from the Standard contract Crowdsale:\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate);\n }\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nExactly, that's the only problem. It is not necessary because we have built a DAPP but I would like to know why it does not work. should, not?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\nBut it works for me. Here were transaction:\n\nUse receive function to buy crowdsale token\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nWhat!!\nHave you achieved it by sending the money directly?\nWell, I don't know why I can't. I am quite upset...\n... any idea, limit gas may be?\nThank you very much for your help..\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\n Skyge\n\n Yes!! that was the problem...\nWe need almost 300000 of limit gas...\n\nIt is very expensive right?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\nSorry, I am not sure.\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n Cainuriel\n\nimage2058×1096 159 KB\n\nBut just like above, I only use 73k gas.\n\n Load more posts below","tokens":3711,"squid":"ink-security_audits","role":"Sentinel","at":1791264684238,"hash":"9d0ba907745ed55bfcf1026e63ead4e88c283e7b"}
{"url":"https://specs.optimism.io/protocol/ecotone/overview.html","domain":"specs.optimism.io","title":"Ecotone - OP Stack Specification","text":"Ecotone Network Upgrade\n\nTable of Contents\n\nExecution Layer\nConsensus Layer\n\nThe Ecotone upgrade contains the Dencun upgrade from L1, and adopts EIP-4844 blobs for data-availability.\nExecution Layer\n\nCancun (Execution Layer):\n\nEIP-1153: Transient storage opcodes\nEIP-4844: Shard Blob Transactions\n\nBlob transactions are disabled\n\nEIP-4788: Beacon block root in the EVM\n\nThe L1 beacon block root is embedded into L2\nThe Beacon roots contract deployment is automated\n\nEIP-5656: MCOPY - Memory copying instruction\nEIP-6780: SELFDESTRUCT only in same transaction\nEIP-7516: BLOBBASEFEE opcode\n\nBLOBBASEFEE always pushes 1 onto the stack\n\nDeneb (Consensus Layer): not applicable to L2\n\nEIP-7044: Perpetually Valid Signed Voluntary Exits\nEIP-7045: Increase Max Attestation Inclusion Slot\nEIP-7514: Add Max Epoch Churn Limit\n\nConsensus Layer\n\nBlobs Data Availability: support blobs DA the L1 Data-retrieval stage.\nRollup fee update: support blobs DA in\nL1 Data Fee computation\nAuto-upgrading and extension of the L1 Attributes Predeployed Contract\n(also known as L1Block predeploy)","tokens":268,"squid":"ink-governance","role":"Council Listener","at":1791264686952,"hash":"872e2ef1b6b614e2a325fcc19b192c9bf5ebbe23"}
{"url":"https://forum.openzeppelin.com/t/buy-direct-with-crowdsale-without-using-the-buytokens-function/10452/24","domain":"forum.openzeppelin.com","title":"Buy direct with Crowdsale without using the buyTokens function - Support - OpenZeppelin Forum","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 13\n\n 9\n\n read \n\n 5\n min\n\n Jun 2021\n\n 24 / 24\n\n Jul 2021\n\n Jul 2021\n\n Load more posts above\n\n post by Cainuriel on Jul 25, 2021\n\n Cainuriel\n\n Komeil_Mirsamie\n\n I have made a purchase contract with these characteristics, inheriting from Crowdsale and overwriting the buytokens method.\n/SPDX-License-Identifier: Unlicense\n\npragma solidity ^0.6.12;\n\nimport \"./Crowdsale.sol\";\nimport \"./Ownable.sol\";\n//import \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n//import \"@openzeppelin/contracts/token/ERC20/Ownable.sol\";\n//import \"hardhat/console.sol\";\n\n// trusty contrato de fernando: 0x21176b07a996E62C905e5bf29b1E3e8F1f237d8A\n\n/**\n * Standard de preventa con algunas customizacinones personales.\n *\n *endsold: para la preventa y envia los tokens que no se hayan vendido\n *al propietario\n *TokenBalance: Indica la cantidad de tokens que hay en el contrato\n*\n Setrate: Cambia la cantidad de tokens a enviar por 1 BNB cuando queramos.\n *\\\n */\n\ninterface TokenInterface {\n // determinamos las funciones que necesitamos del ERC20. Tienen que ser iguales.\n function decimals() external view returns(uint8);\n function balanceOf(address _address) external view returns(uint256);\n function transfer(address _to, uint256 _value) external returns (bool success);\n}\n\ncontract SALETOKEN is Crowdsale, Ownable {\n\n uint256 public limitBuy = 3000000000000000000;\n\n uint256 public minRate = 100000;\n uint256 public maxRate = 220000;\n\n TokenInterface TokenContract; // interface para manipular metodos del token.\n\n // tanto _token como _addresstoken son la misma direccion. La diferencia esta en su uso.\n // Debemos pasarlo como contrato y como direccion para \n // hacer operaciones diferentes.\n constructor (uint256 _rate, \n address payable _wallet, \n BEP20 _token,\n address _addressToken\n ) \n\n Crowdsale(_rate, _wallet, _token) \n\n public {\n\n require(_rate >= minRate && _rate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n\n // pásamos el contrato del token, como direccion para ser usada por la interface\n TokenContract = TokenInterface(_addressToken);\n\n //console.log(\"Desplegado contrato de venta de los tokens del contrato: \", _token);\n\n }\n\n // Funcion que liquida el contrato para que no se pueda vender mas.\n function endSold() public onlyOwner() {\n\n // compensacion de saldos. \n require(TokenContract.transfer(owner(), TokenContract.balanceOf(address(this))));\n msg.sender.transfer(address(this).balance);\n weiRaised = 0;\n\n }\n\n function TokenBalance() public view returns (uint256) {\n return TokenContract.balanceOf(address(this));\n\n }\n\n function setRate(uint256 _newrate) public onlyOwner() {\n\n require(_newrate >= minRate && _newrate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n rate = _newrate;\n }\n\n function setLimitBuy(uint256 _newLimit) public onlyOwner() {\n limitBuy = _newLimit;\n }\n\n function setLimirates(uint256 _newLimitminRate, uint256 _newLimitmaxRate) public onlyOwner() {\n minRate = _newLimitminRate;\n maxRate = _newLimitmaxRate;\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * @param _beneficiary Address performing the token purchase\n */\n function buyTokens(address _beneficiary) public override payable {\n\n require(TokenContract.balanceOf(_beneficiary) <= limitBuy.mul(rate), \"Esta cuenta ya tiene el limite de tokens permitido para la preventa\");\n\n uint256 weiAmount = msg.value;\n\n require(weiAmount <= limitBuy, \"Compra excede el máximo de BNBs permitido\");\n\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n }\n\n}\n\nBut I'm still waiting for someone to explain to me why the receive function doesn't work. It works perfectly with its corresponding frontend.\n\n post by Skyge on Jul 25, 2021\n\n Skyge\n\nreceive function? Do you mean the function buyTokens()\n\n post by Cainuriel on Jul 25, 2021\n\n Cainuriel\n\n No @Skyge ,\nI mean that it works that:\n receive () external payable {\n buyTokens(msg.sender);\n }\n\nis within the crowdsale contract:.\n\n post by Skyge on Jul 25, 2021\n\n Skyge\n\n What is the source code of the Crowdsale contract, I did not find a suitable contract in the OpenZeppelin repo, in the branch named release-v2.5.0, the compiler version of the contract is 0.5.x\n\n post by Cainuriel on Jul 26, 2021\n\n Cainuriel\n\nRight now I share it with you\n\n//SPDX-License-Identifier: Unlicense\npragma solidity ^0.6.12;\n\nimport \"./BEP20.sol\";\nimport \"./SafeMath.sol\";\n\n/**\n * @title Crowdsale\n * @dev Crowdsale is a base contract for managing a token crowdsale,\n * allowing investors to purchase tokens with ether. This contract implements\n * such functionality in its most fundamental form and can be extended to provide additional\n * functionality and/or custom behavior.\n * The external interface represents the basic interface for purchasing tokens, and conform\n * the base architecture for crowdsales. They are *not* intended to be modified / overriden.\n * The internal interface conforms the extensible and modifiable surface of crowdsales. Override\n * the methods to add functionality. Consider using 'super' where appropiate to concatenate\n * behavior.\n */\ncontract Crowdsale {\n using SafeMath for uint256;\n\n // The token being sold\n BEP20 public token;\n\n // Address where funds are collected\n address payable public wallet;\n\n // How many token units a buyer gets per wei\n uint256 public rate;\n\n // Amount of wei raised\n uint256 public weiRaised;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokenPurchase(\n address indexed purchaser,\n address indexed beneficiary,\n uint256 value,\n uint256 amount\n );\n\n /**\n * @param _rate Number of token units a buyer gets per wei\n * @param _wallet Address where collected funds will be forwarded to\n * @param _token Address of the token being sold\n */\n constructor(uint256 _rate, address payable _wallet, BEP20 _token) public {\n require(_rate > 0);\n require(_wallet != address(0));\n// require(_token != address(0));\n\n rate = _rate;\n wallet = _wallet;\n token = _token;\n }\n\n // -----------------------------------------\n // Crowdsale external interface\n // -----------------------------------------\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n */\n fallback () external payable {\n buyTokens(msg.sender);\n }\n\n receive () external payable {\n buyTokens(msg.sender);\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * @param _beneficiary Address performing the token purchase\n */\n function buyTokens(address _beneficiary) public virtual payable {\n\n uint256 weiAmount = msg.value;\n _preValidatePurchase(_beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n weiRaised = weiRaised.add(weiAmount);\n\n _processPurchase(_beneficiary, tokens);\n emit TokenPurchase(\n msg.sender,\n _beneficiary,\n weiAmount,\n tokens\n );\n\n _updatePurchasingState(_beneficiary, weiAmount);\n\n _forwardFunds();\n _postValidatePurchase(_beneficiary, weiAmount);\n }\n\n // -----------------------------------------\n // Internal interface (extensible)\n // -----------------------------------------\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met. Use super to concatenate validations.\n * @param _beneficiary Address performing the token purchase\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(\n address _beneficiary,\n uint256 _weiAmount\n )\n pure internal\n {\n require(_beneficiary != address(0));\n require(_weiAmount != 0);\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid conditions are not met.\n * @param _beneficiary Address performing the token purchase\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(\n address _beneficiary,\n uint256 _weiAmount\n )\n internal\n {\n // optional override\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends its tokens.\n * @param _beneficiary Address performing the token purchase\n * @param _tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(\n address _beneficiary,\n uint256 _tokenAmount\n )\n internal\n {\n token.transfer(_beneficiary, _tokenAmount);\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Not necessarily emits/sends tokens.\n * @param _beneficiary Address receiving the tokens\n * @param _tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(\n address _beneficiary,\n uint256 _tokenAmount\n )\n internal\n {\n _deliverTokens(_beneficiary, _tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions, etc.)\n * @param _beneficiary Address receiving the tokens\n * @param _weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(\n address _beneficiary,\n uint256 _weiAmount\n )\n internal\n {\n // optional override\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param _weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n wallet.transfer(msg.value);\n }\n}\n\nI have to say that I introduced the receive function by recommendation of remix. In the original contract there is only the fallback\n\n post by Skyge on Jul 26, 2021\n\n Skyge\n\n Really a little difficult to get your full code to have a test!\nI have deployed contracts like followings and had a try, all worked well:\n\nCrowdsale token\nCrowdsale contract\nTransfer crowdsale token to crowdsale contract\nUse receive function to buy crowdsale token\n\nRate = 200000, so when use 20 * 10^9 wei to buy crowdsale token, the amount I can get is: 20 * 10^9 * rate = 4*10**15=0.004DAI\n\n post by Skyge on Jul 26, 2021\n\n Skyge\n\n Cainuriel\n\n And I think you can have a look at this tutorial to learn:\n\nSimple ERC20 Crowdsale - General / Guides and Tutorials - OpenZeppelin Community\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nFirst of all, thank you for your effort in trying to help me.\nBut the contract works perfectly for me. Except for the aforementioned function.\nIf you tell me what error you have, maybe I can help you so that you can help me.\nNote that the constructor has to enter TWO TIMES the token contract.\nOne argument is to be used by Crowdsale, and the other is to be used as an interface.\n constructor (uint256 _rate, \n address payable _wallet, \n BEP20 _token,\n address _addressToken\n ) \n\n Crowdsale(_rate, _wallet, _token) \n\n public {\n\n require(_rate >= minRate && _rate <= maxRate , \"La cantidad de tokens tiene que estar entre 100000 y 220000\");\n\n // pásamos el contrato del token, como direccion para ser usada por la interface\n TokenContract = TokenInterface(_addressToken);\n\n //console.log(\"Desplegado contrato de venta de los tokens del contrato: \", _token);\n\n }\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n So is the current problem you can not buy token by calling receive()?\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nThe rate calculates the amount of tokens that will be received for each ETH or BNB.\nIn this function from the Standard contract Crowdsale:\n */\n function _getTokenAmount(uint256 _weiAmount)\n internal view returns (uint256)\n {\n return _weiAmount.mul(rate);\n }\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nExactly, that's the only problem. It is not necessary because we have built a DAPP but I would like to know why it does not work. should, not?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\nBut it works for me. Here were transaction:\n\nUse receive function to buy crowdsale token\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nWhat!!\nHave you achieved it by sending the money directly?\nWell, I don't know why I can't. I am quite upset...\n... any idea, limit gas may be?\nThank you very much for your help..\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\n Skyge\n\n Yes!! that was the problem...\nWe need almost 300000 of limit gas...\n\nIt is very expensive right?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\nSorry, I am not sure.\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n Cainuriel\n\nimage2058×1096 159 KB\n\nBut just like above, I only use 73k gas.\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\n Skyge\n\n Do you know if we can send this gas limit to metamask or is it an option that the user must choose exclusively?\n\n post by Skyge on Jul 27, 2021\n\n Skyge\n\n yes, I think you can set a gas limit for your transaction.\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nOK, In rinkeby o ropsten net.\nThis gas that I have is part of the expense in the BSC net.\n\n post by Cainuriel on Jul 27, 2021\n\n Cainuriel\n\nOk, will investigate how.\nMuchas gracias amigo.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n Add function buyTokens() with no parameter to Crowdsale contract\n\n Contracts\n\n 5\n\n 2.4k\n\n Nov 2020\n\n No receive function works in Crowdsale\n\n Support\n\n 2\n\n 830\n\n Jul 2021\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Crowdsale Contract - TypeError: Overriding function changes state mutability from “view” to “nonpayable”\n\n Contracts\n\n crowdsale\n\n 2\n\n 4.2k\n\n Jul 2021","tokens":3526,"squid":"ink-security_audits","role":"Sentinel","at":1791264694879,"hash":"f19691b374138469971dd810755fb8fbf9659400"}
{"url":"https://specs.optimism.io/protocol/isthmus/derivation.html","domain":"specs.optimism.io","title":"Derivation - OP Stack Specification","text":"Isthmus L2 Chain Derivation Changes\n\nTable of Contents\n\nNetwork upgrade automation transactions\n\nL1Block deployment\nGasPriceOracle deployment\nOperator fee vault deployment\nL1Block Proxy Update\nGasPriceOracle Proxy Update\nOperatorFeeVault Proxy Update\nGasPriceOracle Enable Isthmus\nEIP-2935 Contract Deployment\n\nSpan Batch Updates\n\nActivation\n\nNetwork upgrade automation transactions\nThe Isthmus hardfork activation block contains the following transactions, in this order:\n\nL1 Attributes Transaction\nUser deposits from L1\nNetwork Upgrade Transactions\n\nL1Block deployment\nGasPriceOracle deployment\nOperator Fee vault deployment\nUpdate L1Block Proxy ERC-1967 Implementation\nUpdate GasPriceOracle Proxy ERC-1967 Implementation\nUpdate Operator Fee vault Proxy ERC-1967 Implementation\nGasPriceOracle Enable Isthmus\nEIP-2935 Contract Deployment\n\nTo not modify or interrupt the system behavior around gas computation, this block will not include any sequenced\ntransactions by setting noTxPool: true.\nL1Block deployment\nThe L1Block contract is upgraded to support the Isthmus operator fee feature.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000003\nto: null\nmint: 0\nvalue: 0\ngasLimit: 425,000\ndata: 0x60806040523480156100105... (full bytecode)\nsourceHash: 0x3b2d0821ca2411ad5cd3595804d1213d15737188ae4cbd58aa19c821a6c211bf,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Isthmus: L1 Block Deployment\"\n\nThis results in the Isthmus L1Block contract being deployed to 0xFf256497D61dcd71a9e9Ff43967C13fdE1F72D12, to verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000003\nComputed Address: 0xFf256497D61dcd71a9e9Ff43967C13fdE1F72D12\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: L1 Block Deployment\"))\n# 0x3b2d0821ca2411ad5cd3595804d1213d15737188ae4cbd58aa19c821a6c211bf\n\nVerify data:\ngit checkout 9436dba8c4c906e36675f5922e57d1b55582889e\nmake build-contracts\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json\n\nThis transaction MUST deploy a contract with the following code hash\n0x8e3fe7a416d3e5f3b7be74ddd4e7e58e516fa3f80b67c6d930e3cd7297da4a4b.\nTo verify the code hash:\ngit checkout 9436dba8c4c906e36675f5922e57d1b55582889e\nmake build-contracts\ncast k $(jq -r \".deployedBytecode.object\" packages/contracts-bedrock/forge-artifacts/L1Block.sol/L1Block.json)\n\nGasPriceOracle deployment\nThe GasPriceOracle contract is also upgraded to support the Isthmus operator fee feature.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000004\nto: null\nmint: 0\nvalue: 0\ngasLimit: 1,625,000\ndata: 0x60806040523480156100105... (full bytecode)\nsourceHash: 0xfc70b48424763fa3fab9844253b4f8d508f91eb1f7cb11a247c9baec0afb8035,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Isthmus: Gas Price Oracle Deployment\"\n\nThis results in the Isthmus GasPriceOracle contract being deployed to 0x93e57A196454CB919193fa9946f14943cf733845, to verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000003\nComputed Address: 0xFf256497D61dcd71a9e9Ff43967C13fdE1F72D12\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: Gas Price Oracle Deployment\"))\n# 0xfc70b48424763fa3fab9844253b4f8d508f91eb1f7cb11a247c9baec0afb8035\n\nVerify data:\ngit checkout 9436dba8c4c906e36675f5922e57d1b55582889e\nmake build-contracts\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json\n\nThis transaction MUST deploy a contract with the following code hash\n0x4d195a9d7caf9fb6d4beaf80de252c626c853afd5868c4f4f8d19c9d301c2679.\nTo verify the code hash:\ngit checkout 9436dba8c4c906e36675f5922e57d1b55582889e\nmake build-contracts\ncast k $(jq -r \".deployedBytecode.object\" packages/contracts-bedrock/forge-artifacts/GasPriceOracle.sol/GasPriceOracle.json)\n\nOperator fee vault deployment\nA new OperatorFeeVault contract has been created to receive the operator fees. The contract is created\nwith the following arguments:\n\nRecipient address: The base fee vault\nMin withdrawal amount: 0\nWithdrawal network: L2\n\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x4210000000000000000000000000000000000005\nto: null\nmint: 0\nvalue: 0\ngasLimit: 500,000\ndata: 0x60806040523480156100105... (full bytecode)\nsourceHash: 0x107a570d3db75e6110817eb024f09f3172657e920634111ce9875d08a16daa96,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Isthmus: Operator Fee Vault Deployment\"\n\nThis results in the Isthmus OperatorFeeVault contract being deployed to\n0x4fa2Be8cd41504037F1838BcE3bCC93bC68Ff537, to verify:\ncast compute-address --nonce=0 0x4210000000000000000000000000000000000003\nComputed Address: 0x4fa2Be8cd41504037F1838BcE3bCC93bC68Ff537\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: Operator Fee Vault Deployment\"))\n# 0x107a570d3db75e6110817eb024f09f3172657e920634111ce9875d08a16daa96\n\nVerify data:\ngit checkout 9436dba8c4c906e36675f5922e57d1b55582889e\nmake build-contracts\njq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/OperatorFeeVault.sol/OperatorFeeVault.json\n\nThis transaction MUST deploy a contract with the following code hash\n0x57dc55c9c09ca456fa728f253fe7b895d3e6aae0706104935fe87c7721001971.\nTo verify the code hash:\ngit checkout 9436dba8c4c906e36675f5922e57d1b55582889e\nmake build-contracts\nexport ETH_RPC_URL=https://mainnet.optimism.io # Any RPC running Cancun or Prague\ncast k $(cast call --create $(jq -r \".bytecode.object\" packages/contracts-bedrock/forge-artifacts/OperatorFeeVault.sol/OperatorFeeVault.json))\n\nNote that this verification differs from the other deployments because the OperatorFeeVault\ninherits the FeeVault contract which contains immutables. So the deployment bytecode has to be\nexecuted on an EVM to get the actual deployed contract bytecode. But it sets all immutables to fixed\nconstants, so the resulting code hash is constant.\nL1Block Proxy Update\nThis transaction updates the L1Block Proxy ERC-1967 implementation slot to point to the new L1Block deployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x4200000000000000000000000000000000000015 (L1Block Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe6000000000000000000000000ff256497d61dcd71a9e9ff43967c13fde1f72d12\nsourceHash: 0xebe8b5cb10ca47e0d8bda8f5355f2d66711a54ddeb0ef1d30e29418c9bf17a0e\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Isthmus: L1 Block Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0xff256497d61dcd71a9e9ff43967c13fde1f72d12)\n0x3659cfe6000000000000000000000000ff256497d61dcd71a9e9ff43967c13fde1f72d12\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: L1 Block Proxy Update\"))\n# 0xebe8b5cb10ca47e0d8bda8f5355f2d66711a54ddeb0ef1d30e29418c9bf17a0e\n\nGasPriceOracle Proxy Update\nThis transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle\ndeployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe600000000000000000000000093e57a196454cb919193fa9946f14943cf733845\nsourceHash: 0xecf2d9161d26c54eda6b7bfdd9142719b1e1199a6e5641468d1bf705bc531ab0\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Isthmus: Gas Price Oracle Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x93e57a196454cb919193fa9946f14943cf733845)\n0x3659cfe600000000000000000000000093e57a196454cb919193fa9946f14943cf733845\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: Gas Price Oracle Proxy Update\"))\n# 0xecf2d9161d26c54eda6b7bfdd9142719b1e1199a6e5641468d1bf705bc531ab0\n\nOperatorFeeVault Proxy Update\nThis transaction updates the GasPriceOracle Proxy ERC-1967 implementation slot to point to the new GasPriceOracle\ndeployment.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0x0000000000000000000000000000000000000000\nto: 0x420000000000000000000000000000000000001B (Operator Fee Vault Proxy)\nmint: 0\nvalue: 0\ngasLimit: 50,000\ndata: 0x3659cfe60000000000000000000000004fa2be8cd41504037f1838bce3bcc93bc68ff537\nsourceHash: 0xad74e1adb877ccbe176b8fa1cc559388a16e090ddbe8b512f5b37d07d887a927\ncomputed with the \"Upgrade-deposited\" type, with intent = \"Isthmus: Operator Fee Vault Proxy Update\"\n\nVerify data:\ncast concat-hex $(cast sig \"upgradeTo(address)\") $(cast abi-encode \"upgradeTo(address)\" 0x4fa2be8cd41504037f1838bce3bcc93bc68ff537)\n0x3659cfe60000000000000000000000004fa2be8cd41504037f1838bce3bcc93bc68ff537\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: Operator Fee Vault Proxy Update\"))\n# 0xad74e1adb877ccbe176b8fa1cc559388a16e090ddbe8b512f5b37d07d887a927\n\nGasPriceOracle Enable Isthmus\nThis transaction informs the GasPriceOracle to start using the Isthmus gas calculation formula.\nA deposit transaction is derived with the following attributes:\n\nfrom: 0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001 (Depositer Account)\nto: 0x420000000000000000000000000000000000000F (Gas Price Oracle Proxy)\nmint: 0\nvalue: 0\ngasLimit: 90,000\ndata: 0x291b0383\nsourceHash: 0x3ddf4b1302548dd92939826e970f260ba36167f4c25f18390a5e8b194b295319,\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Isthmus: Gas Price Oracle Set Isthmus\"\n\nVerify data:\ncast sig \"setIsthmus()\"\n0x8e98b106\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: Gas Price Oracle Set Isthmus\"))\n# 0x3ddf4b1302548dd92939826e970f260ba36167f4c25f18390a5e8b194b295319\n\nEIP-2935 Contract Deployment\nEIP-2935 requires a contract to be deployed. To deploy this contract,\na deposit transaction is created with attributes matching the EIP:\n\nfrom: 0x3462413Af4609098e1E27A490f554f260213D685\nto: null\nmint: 0\nvalue: 0\ngasLimit: 250,000\ndata: 0x60538060095f395ff33373fffffffffffffffffffffffffffffffffffffffe14604657602036036042575f35600143038111604257611fff81430311604257611fff9006545f5260205ff35b5f5ffd5b5f35611fff60014303065500\nsourceHash: 0xbfb734dae514c5974ddf803e54c1bc43d5cdb4a48ae27e1d9b875a5a150b553a\ncomputed with the \"Upgrade-deposited\" type, with `intent = \"Isthmus: EIP-2935 Contract Deployment\"\n\nThis results in the EIP-2935 contract being deployed to 0x0000F90827F1C53a10cb7A02335B175320002935, to verify:\ncast compute-address --nonce=0 0x3462413Af4609098e1E27A490f554f260213D685\nComputed Address: 0x0000F90827F1C53a10cb7A02335B175320002935\n\nVerify sourceHash:\ncast keccak $(cast concat-hex 0x0000000000000000000000000000000000000000000000000000000000000002 $(cast keccak \"Isthmus: EIP-2935 Contract Deployment\"))\n# 0xbfb734dae514c5974ddf803e54c1bc43d5cdb4a48ae27e1d9b875a5a150b553a\n\nThis transaction MUST deploy a contract with the following code hash\n0x6e49e66782037c0555897870e29fa5e552daf4719552131a0abce779daec0a5d.\nSpan Batch Updates\nSpan batches are a span of consecutive L2 blocks than are batched submitted.\nSpan batches contain the L1 transactions and transaction types that are posted containing the span of L2 blocks.\nSince EIP-7702 introduces a new transaction type, the Span Batch must be updated to support the EIP-7702\ntransaction.\nThis corresponds with a new RLP-encoding of the tx_datas list as specified in\nthe Delta span batch spec, adding a new transaction type:\nTransaction type 4 (EIP-7702 SetCode):\n0x04 ++ rlp_encode(value, max_priority_fee_per_gas, max_fee_per_gas, data, access_list, authorization_list)\nThe EIP-7702 transaction extends EIP-1559 to include a new authorization_list field.\nauthorization_list is an RLP-encoded list of authorization tuples.\nThe EIP-7702 transaction format is as follows.\n\nvalue: The transaction value as a u256.\nmax_priority_fee_per_gas: The maximum priority fee per gas allowed as a u256.\nmax_fee_per_gas: The maximum fee per gas as a u256.\ndata: The transaction data bytes.\naccess_list: The EIP-2930 access list.\nauthorization_list: The EIP-7702 signed authorization list.\n\nActivation\nSingular batches with transactions of type 4 must only be accepted if Isthmus is active at the\ntimestamp of the batch. If a singular batch contains a transaction of type 4 before Isthmus is\nactive, this batch must be dropped. Note that if Holocene is active, this will also\nlead to the remaining span batch, and channel that contained it, to get dropped.\nAlso note that this check must happen at the level of individual batches that are derived from span\nbatches, not to span batches as a whole. In particular, it is allowed for a span batch to span the\nIsthmus activation timestamp and contain SetCode transactions in singular batches that have a\ntimestamp at or after the Isthmus activation time, even if the timestamp of the span batch is before\nthe Isthmus activation time.","tokens":3369,"squid":"ink-governance","role":"Council Listener","at":1791264697756,"hash":"34de63ba84f5ec8289cbf0c4f113eb2ef5da71a6"}
{"url":"https://specs.optimism.io/protocol/jovian/exec-engine.html","domain":"specs.optimism.io","title":"Execution Engine - OP Stack Specification","text":"Jovian: Execution Engine\n\nTable of Contents\n\nMinimum Base Fee\n\nMinimum Base Fee in Block Header\nMinimum Base Fee in PayloadAttributesV3\nRationale\n\nDA Footprint Block Limit\n\nScalar loading\nReceipts\nRationale\n\nOperator Fee\n\nFee Formula Update\nMaximum value\n\nEVM Changes\n\nPrecompile Input Size Restrictions\n\nMinimum Base Fee\nJovian introduces a\nconfigurable minimum base fee\nto reduce the duration of priority-fee auctions on OP Stack chains.\nThe minimum base fee is configured via SystemConfig (see ./system-config.md) and enforced by the execution engine\nvia the block header extraData encoding and the Engine API PayloadAttributesV3 parameters.\nMinimum Base Fee in Block Header\nLike Holocene's dynamic EIP-1559 parameters, Jovian encodes\nfee parameters in the extraData field of each L2 block header. The format is extended to include an additional\nu64 field for the minimum base fee in wei.\nNameTypeByte Offset\nminBaseFeeu64 (big-endian)[9, 17)\n\nConstraints:\n\nversion MUST be 1 (incremented from Holocene's 0).\nThere MUST NOT be any data beyond these 17 bytes.\n\nThe minBaseFee field is an absolute minimum expressed in wei. During base fee computation, if the\ncomputed baseFee is less than minBaseFee, it MUST be clamped to minBaseFee.\nif (baseFee < minBaseFee) {\n baseFee = minBaseFee\n}\n\nNote: extraData has a maximum capacity of 32 bytes (to fit the L1 beacon-chain extraData type) and may be\nextended by future upgrades.\nMinimum Base Fee in PayloadAttributesV3\nThe Engine API PayloadAttributesV3 is extended with a new\nfield minBaseFee. The existing eip1559Params remains 8 bytes (Holocene format).\nPayloadAttributesV3: {\n timestamp: QUANTITY\n prevRandao: DATA (32 bytes)\n suggestedFeeRecipient: DATA (20 bytes)\n withdrawals: array of WithdrawalV1\n parentBeaconBlockRoot: DATA (32 bytes)\n transactions: array of DATA\n noTxPool: bool\n gasLimit: QUANTITY or null\n eip1559Params: DATA (8 bytes) or null\n minBaseFee: QUANTITY or null\n}\n\nThe minBaseFee MUST be null prior to the Jovian fork, and MUST be non-null after the Jovian fork.\nRationale\nAs with Holocene's dynamic EIP-1559 parameters, placing the\nminimum base fee in the block header allows us to avoid reaching into the state during block sealing.\nThis retains the purity of the function that computes the next block's base fee from its parent block\nheader, while still allowing them to be dynamically configured. Dynamic configuration is handled\nsimilarly to gasLimit, with the derivation pipeline providing the appropriate SystemConfig\ncontract values to the block builder via PayloadAttributesV3 parameters.\nDA Footprint Block Limit\nA DA footprint block limit is introduced to limit the total amount of estimated compressed\ntransaction data that can fit into a block.\nFor each transaction, a new resource called DA footprint is tracked, next to its gas usage.\nIt is scaled to the gas dimension so that its block total can also be limited by\nthe block gas limit, like a block's total gas usage.\nLet a block's daFootprint be defined as follows:\ndef daFootprint(block: Block) -> int:\n daFootprint = 0\n\n for tx in block.transactions:\n if tx.type == DEPOSIT_TX_TYPE:\n continue\n\n daUsageEstimate = max(\n minTransactionSize,\n (intercept + fastlzCoef * tx.fastlzSize) // 1e6\n )\n daFootprint += daUsageEstimate * daFootprintGasScalar\n\n return daFootprint \n\nwhere intercept, minTransactionSize, fastlzCoef and fastlzSize\nare defined in the Fjord specs, DEPOSIT_TX_TYPE is 0x7E,\nand // represents integer floor division.\nFrom Jovian, the blobGasUsed property of each block header is set to that block's daFootprint. Note that pre-Jovian,\nsince Ecotone, it was set to 0, as OP Stack chains don't support blobs. It is now repurposed to store the DA footprint.\nDuring block building and header validation, it must be guaranteed and checked, respectively, that the block's\ndaFootprint stays below the gasLimit, just like the gasUsed property.\nNote that this implies that blocks may have no more than gasLimit/daFootprintGasScalar total estimated DA usage bytes.\nFurthermore, from Jovian, the base fee update calculation now uses gasMetered := max(gasUsed, blobGasUsed)\nin place of the gasUsed value used before.\nAs a result, blocks with high DA usage may cause the base fee to increase in subsequent blocks.\nScalar loading\nThe daFootprintGasScalar is loaded in a similar way to the operatorFeeScalar and operatorFeeConstant\nincluded in the Isthmus fork. It can be read in two interchangable ways:\n\nread from the deposited L1 attributes (daFootprintGasScalar) of the current L2 block\n(decoded according to the jovian schema)\nread from the L1 Block Info contract (0x4200000000000000000000000000000000000015)\n\nusing the solidity getter function daFootprintGasScalar\nusing a direct storage-read: big-endian uint16 in slot 8 at offset 12.\n\nIt takes on a default value as described in the section on L1 Attributes.\nReceipts\nAfter Jovian activation, a new field daFootprintGasScalar is added to transaction receipts that is populated\nwith the DA footprint gas scalar of the transaction's block.\nFurthermore, the blobGasUsed receipt field is set to the DA footprint of the transaction.\nRationale\nWhile the current L1 fee mechanism charges for DA usage based on an estimate of the DA footprint of a transaction, no\nprotocol mechanism currently reflects the limited available DA throughput on L1. E.g. on Ethereum L1 with Pectra\nenabled, the available blob throughput is ~96 kB/s (with a target of ~64 kB/s), but the calldata floor gas price of\n40 for calldata-heavy L2 transactions allows for more incompressible transaction data to be included on most OP Stack\nchains than the Ethereum blob space could handle. This is currently mitigated at the policy level by batcher-sequencer\nthrottling: a mechanism which artificially constricts block building. This can cause base fees to fall, which implies\nunnecessary losses for chain operators and a negative user experience (transaction inclusion delays, priority fee\nauctions). So hard-limiting a block's DA footprint in a way that also influences the base fee mitigates the\naforementioned problems of policy-based solutions.\nOperator Fee\nFee Formula Update\nJovian updates the operator fee calculation so that higher fees may be charged.\nStarting at the Jovian activation, the operator fee MUST be computed as:\n\nThe effective per-gas scalar applied is therefore 100 * operatorFeeScalar. Otherwise, the data types and operator fee\nsemantics described in the Isthmus spec continue to apply.\nMaximum value\nWith the new formula, the operator fee's maximum value has 103 bits:\n\nImplementations that use uint256 for intermediate arithmetic do not need additional overflow checks.\nEVM Changes\nPrecompile Input Size Restrictions\nSome precompiles have changes to the input size restrictions. The new input size restrictions are:\n\nbn256Pairing: 81,984 bytes (427 pairs)\nBLS12-381 G1 MSM: 288,960 bytes (1,806 pairs)\nBLS12-381 G2 MSM: 278,784 bytes (968 pairs)\nBLS12-381 Pairing: 156,672 bytes (408 pairs)","tokens":1745,"squid":"ink-governance","role":"Council Listener","at":1791264708604,"hash":"c5d39a761b99a3647e5e2feeaa6610f8bbb847e4"}
{"url":"https://dev-forum.pyth.network/t/unstable-hermes-api/356/1","domain":"dev-forum.pyth.network","title":"Unstable Hermes API - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Unstable Hermes API \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 1 / 2\n\n Aug 2025\n\n Aug 2025\n\n post by KemarTiti on Aug 13, 2025\n\n KemarTiti\n\n Hi,\nI’ve been calling the Pyth public Hermes API (https://hermes.pyth.network/v2/updates/price/latest) from GCP in Singapore.\nIt used to be stable, but lately response times are highly unstable, sometimes over 1 minute, often exceeding 10 seconds.\nThe frequency of receiving data from websocket is also low. Is the server still healthy/stable? Do you have any suggestions on better regions or alternate endpoints to reduce latency?\nErrors continuously happened, not around specific time. I set a 10 sec hard limit timeout and found reaching this limit once / 5-minutes.\nSometimes, the Websocket also stops sending the latest price data. Public subscription too\n\n post by KemarTiti on Aug 13, 2025\n\n KemarTiti\n\n The first recommendation is to use a third-party node provider as well. You can find them here: https://docs.pyth.network/price-feeds/api-instances-and-providers/hermes#node-providers\nThe second recommendation would be using these nodes in other clusters.\nThese are all the three:\n\nhttps://hermes-stable-cyan.dourolabs.app/\nhttps://hermes-stable-green.dourolabs.app/\nhttps://hermes-stable-yellow.dourolabs.app/\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Hermes configuration\n\n Price Feeds\n\n 3\n\n 754\n\n Jun 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 397\n\n Nov 2025\n\n Powered by Discourse","tokens":1373,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264709304,"hash":"9053c886c18181ba56da4c0888cabf8b3da3a53a"}
{"url":"https://docs.pyth.network/price-feeds/core/contract-addresses","domain":"docs.pyth.network","title":"Contract Addresses | Pyth Developer Hub","text":"Pyth CoreContract AddressesFind deployed Pyth contract addresses across supported blockchainsThe following sections list the addresses of deployed Pyth Price Feed contracts across blockchains.\nThe contracts are split by ecosystem into several different documents:\nPyth Core was upgraded on August 26, 2026We recommend new integrations use the upgraded contract addresses.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\n\nEVM\nSolana/SVM\nSui\n\nPlease see the relevant ecosystem document to find the Pyth contract address on your blockchain of choice.\nPyth Core no longer supports Aptos, CosmWasm, Fuel, IOTA, Movement, NEAR, Stacks,\nStarknet, or TON. The contract addresses for those ecosystems have been removed, as have Pythnet's —\nPythnet is shutting down as part of the Pyth Core sunset.\nIOTA has a Pyth Pro deployment instead; see the\nPyth Pro contract addresses.SVM Error CodesDecode the error codes emitted by Pyth SVM contractson EVM NetworksList of Pyth price feed contract addresses on supported EVM mainnets and testnets","tokens":281,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264728891,"hash":"6c96834b3abd6610fe19f45bfa21993992cdf70f"}
{"url":"https://ethereum.org/roadmap/beacon-chain/","domain":"ethereum.org","title":"The Beacon Chain | ethereum.org","text":"Edit page (opens in a new tab)\nWhat is the Beacon Chain?\nThe Beacon Chain is the name of the original proof-of-stake blockchain that was launched in 2020. It was created to ensure the proof-of-stake consensus logic was sound and sustainable before enabling it on Ethereum Mainnet. Therefore, it ran alongside the original proof-of-work Ethereum. The Beacon Chain was a chain of 'empty' blocks, but switching off proof-of-work and switching on proof-of-stake on Ethereum required instructing the Beacon Chain to accept transaction data from execution clients, bundle them into blocks and then organize them into a blockchain using a proof-of-stake-based consensus mechanism. At the same moment, the original Ethereum clients turned off their mining, block propagation and consensus logic, handing that all over to the Beacon Chain. This event was known as The Merge. Once The Merge happened, there were no longer two blockchains. Instead, there was just one proof-of-stake Ethereum, which now requires two different clients per node. The Beacon Chain is now the consensus layer, a peer-to-peer network of consensus clients that handles block gossip and consensus logic, while the original clients form the execution layer, which is responsible for gossiping and executing transactions, and managing Ethereum's state. The two layers can communicate with one another using the Engine API.\nWhat does the Beacon Chain do?\nThe Beacon Chain is the name given to a ledger of accounts that conducted and coordinated the network of Ethereum stakers before those stakers started validating real Ethereum blocks. It does not process transactions or handle smart contract interactions though because that is being done in the execution layer.\nThe Beacon Chain is responsible for things like block and attestation handling, running the fork choice algorithm, and managing rewards and penalties.\nRead more on our node architecture page.\nBeacon Chain impact\nIntroducing staking\nThe Beacon Chain introduced proof-of-stake to Ethereum. This keeps Ethereum secure and earns validators more ETH in the process. In practice, staking involves staking ETH in order to activate validator software. As a staker, you run the software that creates and validates new blocks in the chain.\nStaking serves a similar purpose that mining used to, but is different in many ways. Mining required large up-front expenditures in the form of powerful hardware and energy consumption, resulting in economies of scale, and promoting centralization. Mining also did not come with any requirement to lock up assets as collateral, limiting the protocol's ability to punish bad actors after an attack.\nThe transition to proof-of-stake made Ethereum significantly more secure and decentralized by comparison to proof-of-work. The more people that participate in the network, the more decentralized and safe from attacks it becomes.\nIf you're interested in becoming a validator and helping secure Ethereum, learn more about staking.\nSetting up for sharding\nSince the Beacon Chain merged with the original Ethereum Mainnet, the Ethereum community started looking to scaling the network.\nProof-of-stake has the advantage of having a registry of all approved block producers at any given time, each with ETH at stake. This registry sets the stage for the ability to divide and conquer but reliably split up specific network responsibilities.\nThis responsibility is in contrast to proof-of-work, where miners have no obligation to the network and could stop mining and turn their node software off permanently in an instant without repercussion. There is also no registry of known block proposers and no reliable way to split network responsibilities safely.\nMore on sharding\nRelationship between upgrades\nThe Ethereum upgrades are all somewhat interrelated. So let’s recap how the Beacon Chain affects the other upgrades.\nBeacon Chain and The Merge\nAt first, The Beacon Chain existed separately from Ethereum Mainnet, but they were merged in 2022.\nThe Merge\nShards and the Beacon Chain\nSharding can only safely enter the Ethereum ecosystem with a proof-of-stake consensus mechanism in place. The Beacon Chain introduced staking, which 'merged' with Mainnet, paving the way for sharding to help further scale Ethereum.\nShard chains\nFurther reading\n\nMore on node architecture\nMore of proof-of-stake","tokens":1087,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264730363,"hash":"315eb33ab051f4b5921cdd06606f3c259b90f134"}
{"url":"https://docs.pyth.network/price-feeds/core/contract-addresses/sui","domain":"docs.pyth.network","title":"on Sui | Pyth Developer Hub","text":"Pyth CoreContract Addresseson SuiList of Pyth price feed contract addresses on Sui networksPyth is currently available on the following sui-based chains:\nPyth Core on Sui was upgraded on August 26, 2026We recommend new integrations use the upgraded Sui contracts.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nStable channel\nSui Mainnet\nNameAddressPyth State ID0x1f9310238ee9298fb703c3419030b35b22bb1cc37113e3bb5007c99aec79e5b8Pyth Package ID0x04e20ddf36af412a4096f9014f4a565af9e812db9a05cc40254846cf6ed0ad91Wormhole State ID0xaeab97f96cf9877fee2883315d459552b2b921edc16d7ceac6eab944dd88919cWormhole Package ID0x5306f64e312b581766351c07af79c72fcb1cd25147157fdc2f8ad76de9a3fb6a\nBeta channel\nSui Testnet\nNameAddressPyth State ID0x243759059f4c3111179da5878c12f68d612c21a8d54d85edc86164bb18be1c7cPyth Package ID0xabf837e98c26087cba0883c0a7a28326b1fa3c5e1e2c5abdb486f9e8f594c837Wormhole State ID0x31358d198147da50db32eda2562951d53973a0c0ad5ed738e9b17d88b213d790Wormhole Package ID0xf47329f4344f3bf0f8e436e2f7b485466cff300f12a166563995d3888c296a94on Solana/SVMList of Pyth price feed contract addresses on Solana and other SVM chainsWhat is a Pull Oracle?Learn how Pyth's pull oracle model differs from traditional push oracles","tokens":330,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264738421,"hash":"25930c78315a2725030826a7d87313fcca84de36"}
{"url":"https://ethereum.org/web3/","domain":"ethereum.org","title":"What is Web3 and why is it important? | ethereum.org","text":"Edit page (opens in a new tab)Centralization has helped onboard billions of people to the World Wide Web and created the stable, robust infrastructure on which it lives. At the same time, a handful of centralized entities have a stronghold on large swathes of the World Wide Web, unilaterally deciding what should and should not be allowed.\nWeb3 is the answer to this dilemma. Instead of a Web monopolized by large technology companies, Web3 embraces decentralization and is being built, operated, and owned by its users. Web3 puts power in the hands of individuals rather than corporations.\nBefore we talk about Web3, let's explore how we got here.\n\nThe early Web\nMost people think of the Web as a continuous pillar of modern life—it was invented and has just existed since. However, the Web most of us know today is quite different from originally imagined. To understand this better, it's helpful to break the Web's short history into loose periods—Web 1.0 and Web 2.0.\nWeb 1.0: Read-Only (1990-2004)\nIn 1989, at CERN, Geneva, Tim Berners-Lee was busy developing the protocols that would become the World Wide Web. His idea? To create open, decentralized protocols that allowed information-sharing from anywhere on Earth.\nThe first inception of Berners-Lee's creation, now known as 'Web 1.0', occurred roughly between 1990 to 2004. Web 1.0 was mainly static websites owned by companies, and there was close to zero interaction between users - individuals seldom produced content - leading to it being known as the read-only web.\n\nWeb 2.0: Read-Write (2004-now)\nThe Web 2.0 period began in 2004 with the emergence of social media platforms. Instead of a read-only, the web evolved to be read-write. Instead of companies providing content to users, they also began to provide platforms to share user-generated content and engage in user-to-user interactions. As more people came online, a handful of top companies began to control a disproportionate amount of the traffic and value generated on the web. Web 2.0 also birthed the advertising-driven revenue model. While users could create content, they didn't own it or benefit from its monetization.\n\nWeb 3.0: Read-Write-Own\nThe premise of 'Web 3.0' was coined by Ethereum co-founder Gavin Wood shortly after Ethereum launched in 2014. Gavin put into words a solution for a problem that many early crypto adopters felt: the Web required too much trust. That is, most of the Web that people know and use today relies on trusting a handful of private companies to act in the public's best interests.\n\nWhat is Web3?\nWeb3 has become a catch-all term for the vision of a new, better internet. At its core, Web3 uses blockchains, cryptocurrencies, and NFTs to give power back to the users in the form of ownership. A 2020 post on Twitter (opens in a new tab) said it best: Web1 was read-only, Web2 is read-write, Web3 will be read-write-own.\nCore ideas of Web3\nAlthough it's challenging to provide a rigid definition of what Web3 is, a few core principles guide its creation.\n\nWeb3 is decentralized: instead of large swathes of the internet controlled and owned by centralized entities, ownership gets distributed amongst its builders and users.\nWeb3 is permissionless: everyone has equal access to participate in Web3, and no one gets excluded.\nWeb3 has native payments: it uses cryptocurrency for spending and sending money online instead of relying on the outdated infrastructure of banks and payment processors.\nWeb3 is trustless: it operates using incentives and economic mechanisms instead of relying on trusted third-parties.\n\nWhy is Web3 important?\nAlthough Web3's killer features aren't isolated and don't fit into neat categories, for simplicity we've tried to separate them to make them easier to understand.\nOwnership\nWeb3 gives you ownership of your digital assets in an unprecedented way. For example, say you're playing a web2 game. If you purchase an in-game item, it is tied directly to your account. If the game creators delete your account, you will lose these items. Or, if you stop playing the game, you lose the value you invested into your in-game items.\nWeb3 allows for direct ownership through . No one, not even the game's creators, has the power to take away your ownership. And, if you stop playing, you can sell or trade your in-game items on open markets and recoup their value. Explore onchain gaming to see this in action.\nLearn more about NFTsMore on NFTs\nCensorship resistance\nThe power dynamic between platforms and content creators is massively imbalanced.\nOnlyFans is a user-generated adult content site with over 1-million content creators, many of which use the platform as their primary source of income. In August 2021, OnlyFans announced plans to ban sexually explicit content. The announcement sparked outrage amongst creators on the platform, who felt they were getting robbed of an income on a platform they helped create. After the backlash, the decision got quickly reversed. Despite the creators winning this battle, it highlights a problem for Web 2.0 creators: you lose the reputation and following you accrued if you leave a platform.\nOn Web3, your data lives on the blockchain. When you decide to leave a platform, you can take your reputation with you, plugging it into another interface that more clearly aligns with your values.\nWeb 2.0 requires content creators to trust platforms not to change the rules, but censorship resistance is a native feature of a Web3 platform.\nDecentralized autonomous organizations (DAOs)\nAs well as owning your data in Web3, you can own the platform as a collective, using tokens that act like shares in a company. DAOs let you coordinate decentralized ownership of a platform and make decisions about its future.\nDAOs are defined technically as agreed-upon that automate decentralized decision-making over a pool of resources (tokens). Users with tokens vote on how resources get spent, and the code automatically performs the voting outcome.\nHowever, people define many Web3 communities as DAOs. These communities all have different levels of decentralization and automation by code. Currently, we are exploring what DAOs are and how they might evolve in the future.\nLearn more about DAOsMore on DAOs\nIdentity\nTraditionally, you would create an account for every platform you use. For example, you might have a Twitter account, a YouTube account, and a Reddit account. Want to change your display name or profile picture? You have to do it across every account. You can use social sign-ins in some cases, but this presents a familiar problem—censorship. In a single click, these platforms can lock you out of your entire online life. Even worse, many platforms require you to trust them with personally identifiable information to create an account.\nWeb3 solves these problems by allowing you to control your digital identity with an Ethereum address and profile. Using an Ethereum address provides a single login across platforms that is secure, censorship-resistant, and anonymous.\nNative payments\nWeb2's payment infrastructure relies on banks and payment processors, excluding people without bank accounts or those who happen to live within the borders of the wrong country.\nWeb3 uses tokens like to send money directly in the browser and requires no trusted third party.\nMore on ETH\nWeb3 limitations\nDespite the numerous benefits of Web3 in its current form, there are still many limitations that the ecosystem must address for it to flourish.\nAccessibility\nImportant Web3 features, like Sign-in with Ethereum, are already available for anyone to use at zero cost. But, the relative cost of transactions is still prohibitive to many. Web3 is less likely to be utilized in less-wealthy, developing nations due to high transaction fees. On Ethereum, these challenges are being solved through the roadmap and . The technology is ready, but we need higher levels of adoption on layer 2 to make Web3 accessible to everyone.\nUser experience\nThe technical barrier to entry to using Web3 is currently too high. Users must comprehend security concerns, understand complex technical documentation, and navigate unintuitive user interfaces. Wallet providers, in particular, are working to solve this, but more progress is needed before Web3 gets adopted en masse.\nEducation\nWeb3 introduces new paradigms that require learning different mental models than the ones used in Web2.0. A similar education drive happened as Web1.0 was gaining popularity in the late 1990s; proponents of the world wide web used a slew of educational techniques to educate the public from simple metaphors (the information highway, browsers, surfing the web) to television broadcasts (opens in a new tab). Web3 isn't difficult, but it is different. Educational initiatives informing Web2 users of these Web3 paradigms are vital for its success.\nEthereum.org has contributed to Web3 education through its Translation Program, which made important Ethereum content available in dozens of languages.\nCentralized infrastructure\nThe Web3 ecosystem is young and quickly evolving. As a result, it currently depends mainly on centralized infrastructure (GitHub, Twitter, Discord, etc.). Many Web3 companies are rushing to fill these gaps, but building high-quality, reliable infrastructure takes time.\nA decentralized future\nWeb3 is a young and evolving ecosystem. Gavin Wood coined the term in 2014, but many of these ideas have only recently become a reality. In the last year alone, there has been a considerable surge in the interest in cryptocurrency, improvements to layer 2 scaling solutions, massive experiments with new forms of governance, and revolutions in digital identity.\nWe are only at the beginning of creating a better Web with Web3, but as we continue to improve the infrastructure that will support it, the future of the Web looks bright.\nHow can I get involved\n\nGet a wallet\nFind a community\nExplore Web3 applications\nJoin a DAO\nBuild on Web3\n\nFurther reading\nWeb3 isn’t rigidly defined. Various community participants have different perspectives on it. Here are a few of them:\n\nWhat is Web3? The Decentralized Internet of the Future Explained (opens in a new tab) – Nader Dabit\nMaking Sense of Web 3 (opens in a new tab) – Josh Stark\nWhy Web3 Matters (opens in a new tab) — Chris Dixon\nWhy Decentralization Matters (opens in a new tab) - Chris Dixon\nThe Web3 Landscape (opens in a new tab) – a16z\nThe Web3 Debate (opens in a new tab) – Packy McCormick\n\nTest your Ethereum knowledgeWhat is Web3?Question number 1:Web3 allows users to own digital assets through:","tokens":2644,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264741469,"hash":"315e02e797447282b1784445a35330f995eb8a3c"}
{"url":"https://ethereum.org/en/developers/docs/apis/json-rpc/","domain":"ethereum.org","title":"JSON-RPC API | ethereum.org","text":"JSON-RPC APIEdit page (opens in a new tab)In order for a software application to interact with the Ethereum blockchain - either by reading blockchain data or sending transactions to the network - it must connect to an Ethereum node.\nFor this purpose, every Ethereum client implements a JSON-RPC specification (opens in a new tab), so there is a uniform set of methods that applications can rely on regardless of the specific node or client implementation.\nJSON-RPC (opens in a new tab) is a stateless, light-weight remote procedure call (RPC) protocol. It defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments. It uses JSON (RFC 4627) as data format.\nClient implementations\nEthereum clients each may utilize different programming languages when implementing the JSON-RPC specification. See individual client documentation for further details related to specific programming languages. We recommend checking the documentation of each client for the latest API support information.\nConvenience Libraries\nWhile you may choose to interact directly with Ethereum clients via the JSON-RPC API, there are often easier options for dapp developers. Many JavaScript and backend API libraries exist to provide wrappers on top of the JSON-RPC API. With these libraries, developers can write intuitive, one-line methods in the programming language of their choice to initialize JSON-RPC requests (under the hood) that interact with Ethereum.\nConsensus client APIs\nThis page deals mainly with the JSON-RPC API used by Ethereum execution clients. However, consensus clients also have an RPC API that allows users to query information about the node, request Beacon blocks, Beacon state, and other consensus-related information directly from a node. This API is documented on the Beacon API webpage (opens in a new tab).\nAn internal API is also used for inter-client communication within a node - that is, it enables the consensus client and execution client to swap data. This is called the 'Engine API' and the specs are available on GitHub (opens in a new tab).\nExecution client spec\nRead the full JSON-RPC API spec on GitHub (opens in a new tab). This API is documented on the Execution API webpage (opens in a new tab) and includes an Inspector to try out all the available methods.\nConventions\nHex value encoding\nTwo key data types get passed over JSON: unformatted byte arrays and quantities. Both are passed with a hex encoding but with different requirements for formatting.\nQuantities\nWhen encoding quantities (integers, numbers): encode as hex, prefix with \"0x\", the most compact representation (slight exception: zero should be represented as \"0x0\").\nHere are some examples:\n\n0x41 (65 in decimal)\n0x400 (1024 in decimal)\nWRONG: 0x (should always have at least one digit - zero is \"0x0\")\nWRONG: 0x0400 (no leading zeroes allowed)\nWRONG: ff (must be prefixed 0x)\n\nUnformatted data\nWhen encoding unformatted data (byte arrays, account addresses, hashes, bytecode arrays): encode as hex, prefix with \"0x\", two hex digits per byte.\nHere are some examples:\n\n0x41 (size 1, \"A\")\n0x004200 (size 3, \"0B0\")\n0x (size 0, \"\")\nWRONG: 0xf0f0f (must be even number of digits)\nWRONG: 004200 (must be prefixed 0x)\n\nThe block parameter\nThe following methods have a block parameter:\n\neth_getBalance\neth_getCode\neth_getTransactionCount\neth_getStorageAt\neth_call\n\nWhen requests are made that query the state of Ethereum, the provided block parameter determines the height of the block.\nThe following options are possible for the block parameter:\n\nHEX String - an integer block number\nString \"earliest\" for the earliest/genesis block\nString \"latest\" - for the latest proposed block\nString \"safe\" - for the latest safe head block\nString \"finalized\" - for the latest finalized block\nString \"pending\" - for the pending state/transactions\n\nExamples\nOn this page we provide examples of how to use individual JSON_RPC API endpoints using the command line tool, curl (opens in a new tab). These individual endpoint examples are found below in the Curl examples section. Further down the page, we also provide an end-to-end example for compiling and deploying a smart contract using a Geth node, the JSON_RPC API and curl.\nCurl examples\nExamples of using the JSON_RPC API by making curl (opens in a new tab) requests to an Ethereum node are provided below. Each example\nincludes a description of the specific endpoint, its parameters, return type, and a worked example of how it should be used.\nThe curl requests might return an error message relating to the content type. This is because the --data option sets the content type to application/x-www-form-urlencoded. If your node does complain about this, manually set the header by placing -H \"Content-Type: application/json\" at the start of the call. The examples also do not include the URL/IP & port combination which must be the last argument given to curl (e.g., 127.0.0.1:8545). A complete curl request including these additional data takes the following form:\ncurl -H \"Content-Type: application/json\" -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"web3_clientVersion\",\"params\":[],\"id\":67}' 127.0.0.1:8545\n\nGossip, State, History\nA handful of core JSON-RPC methods require data from the Ethereum network, and fall neatly into three main categories: Gossip, State, and History. Use the links in these sections to jump to each method, or use the table of contents to explore the whole list of methods.\nGossip Methods\n\nThese methods track the head of the chain. This is how transactions make their way around the network, find their way into blocks, and how clients find out about new blocks.\n\neth_blockNumber\neth_sendRawTransaction\n\nState Methods\n\nMethods that report the current state of all the data stored. The \"state\" is like one big shared piece of RAM, and includes account balances, contract data, and gas estimations.\n\neth_getBalance\neth_getStorageAt\neth_getTransactionCount\neth_getCode\neth_call\neth_estimateGas\n\nHistory Methods\n\nFetches historical records of every block back to genesis. This is like one large append-only file, and includes all block headers, block bodies, uncle blocks, and transaction receipts.\n\neth_getBlockTransactionCountByHash\neth_getBlockTransactionCountByNumber\neth_getUncleCountByBlockHash\neth_getUncleCountByBlockNumber\neth_getBlockByHash\neth_getBlockByNumber\neth_getTransactionByHash\neth_getTransactionByBlockHashAndIndex\neth_getTransactionByBlockNumberAndIndex\neth_getTransactionReceipt\neth_getUncleByBlockHashAndIndex\neth_getUncleByBlockNumberAndIndex\n\nJSON-RPC API Playground\nYou can use the playground tool (opens in a new tab) to discover and try out the API methods. It also shows you which methods and networks are supported by various node providers.\nJSON-RPC API Methods\nweb3_clientVersion\nReturns the current client version.\nParameters\nNone\nReturns\nString - The current client version\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"web3_clientVersion\",\"params\":[],\"id\":67}'\n// Result\n{\n \"id\":67,\n \"jsonrpc\":\"2.0\",\n \"result\": \"Geth/v1.12.1-stable/linux-amd64/go1.19.1\"\n}\n\nweb3_sha3\nReturns Keccak-256 (not the standardized SHA3-256) of the given data.\nParameters\n\nDATA - The data to convert into a SHA3 hash\n\nparams: [\"0x68656c6c6f20776f726c64\"]\n\nReturns\nDATA - The SHA3 result of the given string.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"web3_sha3\",\"params\":[\"0x68656c6c6f20776f726c64\"],\"id\":64}'\n// Result\n{\n \"id\":64,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad\"\n}\n\nnet_version\nReturns the current network id.\nParameters\nNone\nReturns\nString - The current network id.\nThe full list of current network IDs is available at chainlist.org (opens in a new tab). Some common ones are:\n\n1: Ethereum Mainnet\n11155111: Sepolia testnet\n560048 : Hoodi Testnet\n\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_version\",\"params\":[],\"id\":67}'\n// Result\n{\n \"id\":67,\n \"jsonrpc\": \"2.0\",\n \"result\": \"3\"\n}\n\nnet_listening\nReturns true if client is actively listening for network connections.\nParameters\nNone\nReturns\nBoolean - true when listening, otherwise false.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_listening\",\"params\":[],\"id\":67}'\n// Result\n{\n \"id\":67,\n \"jsonrpc\":\"2.0\",\n \"result\":true\n}\n\nnet_peerCount\nReturns number of peers currently connected to the client.\nParameters\nNone\nReturns\nQUANTITY - integer of the number of connected peers.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"net_peerCount\",\"params\":[],\"id\":74}'\n// Result\n{\n \"id\":74,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x2\" // 2\n}\n\neth_protocolVersion\nReturns the current Ethereum protocol version. Note that this method is not available in Geth (opens in a new tab).\nParameters\nNone\nReturns\nString - The current Ethereum protocol version\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_protocolVersion\",\"params\":[],\"id\":67}'\n// Result\n{\n \"id\":67,\n \"jsonrpc\": \"2.0\",\n \"result\": \"54\"\n}\n\neth_syncing\nReturns an object with data about the sync status or false.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nThe precise return data varies between client implementations. All clients return False when the node is not syncing, and all clients return the following fields.\nObject|Boolean, An object with sync status data or FALSE, when not syncing:\n\nstartingBlock: QUANTITY - The block at which the import started (will only be reset, after the sync reached his head)\ncurrentBlock: QUANTITY - The current block, same as eth_blockNumber\nhighestBlock: QUANTITY - The estimated highest block\n\nHowever, the individual clients may also provide additional data. For example Geth returns the following:\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"result\": {\n \"currentBlock\": \"0x3cf522\",\n \"healedBytecodeBytes\": \"0x0\",\n \"healedBytecodes\": \"0x0\",\n \"healedTrienodes\": \"0x0\",\n \"healingBytecode\": \"0x0\",\n \"healingTrienodes\": \"0x0\",\n \"highestBlock\": \"0x3e0e41\",\n \"startingBlock\": \"0x3cbed5\",\n \"syncedAccountBytes\": \"0x0\",\n \"syncedAccounts\": \"0x0\",\n \"syncedBytecodeBytes\": \"0x0\",\n \"syncedBytecodes\": \"0x0\",\n \"syncedStorage\": \"0x0\",\n \"syncedStorageBytes\": \"0x0\"\n }\n}\n\nWhereas Besu returns:\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 51,\n \"result\": {\n \"startingBlock\": \"0x0\",\n \"currentBlock\": \"0x1518\",\n \"highestBlock\": \"0x9567a3\",\n \"pulledStates\": \"0x203ca\",\n \"knownStates\": \"0x200636\"\n }\n}\n\nRefer to the documentation for your specific client for more details.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_syncing\",\"params\":[],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": {\n startingBlock: '0x384',\n currentBlock: '0x386',\n highestBlock: '0x454'\n }\n}\n// Or when not syncing\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": false\n}\n\neth_coinbase\nReturns the client coinbase address.\nTry endpoint in playground (opens in a new tab)\n\nNote: This method has been deprecated as of v1.14.0 and is no longer supported. Attempting to use this method will result in a \"Method not supported\" error.\n\nParameters\nNone\nReturns\nDATA, 20 bytes - the current coinbase address.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_coinbase\",\"params\":[],\"id\":64}'\n// Result\n{\n \"id\":64,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x407d73d8a49eeb85d32cf465507dd71d507100c1\"\n}\n\neth_chainId\nReturns the chain ID used for signing replay-protected transactions.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nchainId, hexadecimal value as a string representing the integer of the current chain id.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":67}'\n// Result\n{\n \"id\":67,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\"\n}\n\neth_mining\nReturns true if client is actively mining new blocks. This can only return true for proof-of-work networks and may not be available in some clients since The Merge.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nBoolean - returns true if the client is mining, otherwise false.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_mining\",\"params\":[],\"id\":71}'\n//\n{\n \"id\":71,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\neth_hashrate\nReturns the number of hashes per second that the node is mining with. This can only return true for proof-of-work networks and may not be available in some clients since The Merge.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nQUANTITY - number of hashes per second.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_hashrate\",\"params\":[],\"id\":71}'\n// Result\n{\n \"id\":71,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x38a\"\n}\n\neth_gasPrice\nReturns an estimate of the current price per gas in wei. For example, the Besu client examines the last 100 blocks and returns the median gas unit price by default.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nQUANTITY - integer of the current gas price in wei.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_gasPrice\",\"params\":[],\"id\":73}'\n// Result\n{\n \"id\":73,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1dfd14000\" // 8049999872 Wei\n}\n\neth_accounts\nReturns a list of addresses owned by client.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nArray of DATA, 20 Bytes - addresses owned by the client.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_accounts\",\"params\":[],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": [\"0x407d73d8a49eeb85d32cf465507dd71d507100c1\"]\n}\n\neth_blockNumber\nReturns the number of the most recent block.\nTry endpoint in playground (opens in a new tab)\nParameters\nNone\nReturns\nQUANTITY - integer of the current block number the client is on.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":83}'\n// Result\n{\n \"id\":83,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x4b7\" // 1207\n}\n\neth_getBalance\nReturns the balance of the account at a given address.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 20 Bytes - address to check for balance.\nQUANTITY|TAG - integer block number, or the string \"latest\", \"earliest\", \"pending\", \"safe\", or \"finalized\", see the block parameter\n\nparams: [\"0x407d73d8a49eeb85d32cf465507dd71d507100c1\", \"latest\"]\n\nReturns\nQUANTITY - integer of the current balance in wei.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBalance\",\"params\":[\"0x407d73d8a49eeb85d32cf465507dd71d507100c1\", \"latest\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x0234c8a3397aab58\" // 158972490234375000\n}\n\neth_getStorageAt\nReturns the value from a storage position at a given address.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 20 Bytes - address of the storage.\nQUANTITY - integer of the position in the storage.\nQUANTITY|TAG - integer block number, or the string \"latest\", \"earliest\", \"pending\", \"safe\", \"finalized\", see the block parameter\n\nReturns\nDATA - the value at this storage position.\nExample\nCalculating the correct position depends on the storage to retrieve. Consider the following contract deployed at 0x295a70b2de5e3953354a6a8344e616ed314d7251 by address 0x391694e7e0b0cce554cb130d723a9d27458f9298.\ncontract Storage {\n uint pos0;\n mapping(address => uint) pos1;\n constructor() {\n pos0 = 1234;\n pos1[msg.sender] = 5678;\n }\n}\n\nRetrieving the value of pos0 is straightforward:\ncurl -X POST --data '{\"jsonrpc\":\"2.0\", \"method\": \"eth_getStorageAt\", \"params\": [\"0x295a70b2de5e3953354a6a8344e616ed314d7251\", \"0x0\", \"latest\"], \"id\": 1}' localhost:8545\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x00000000000000000000000000000000000000000000000000000000000004d2\"}\n\nRetrieving an element of the map is harder. The position of an element in the map is calculated with:\nkeccak(LeftPad32(key, 0), LeftPad32(map position, 0))\n\nThis means to retrieve the storage on pos1[\"0x391694e7e0b0cce554cb130d723a9d27458f9298\"] we need to calculate the position with:\nkeccak(\n decodeHex(\n \"000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298\" +\n \"0000000000000000000000000000000000000000000000000000000000000001\"\n )\n)\n\nThe geth console which comes with the web3 library can be used to make the calculation:\n> var key = \"000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298\" + \"0000000000000000000000000000000000000000000000000000000000000001\"\nundefined\n> web3.sha3(key, {\"encoding\": \"hex\"})\n\"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9\"\n\nNow to fetch the storage:\ncurl -X POST --data '{\"jsonrpc\":\"2.0\", \"method\": \"eth_getStorageAt\", \"params\": [\"0x295a70b2de5e3953354a6a8344e616ed314d7251\", \"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9\", \"latest\"], \"id\": 1}' localhost:8545\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x000000000000000000000000000000000000000000000000000000000000162e\"}\n\neth_getTransactionCount\nReturns the number of transactions sent from an address.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 20 Bytes - address.\nQUANTITY|TAG - integer block number, or the string \"latest\", \"earliest\", \"pending\", \"safe\" or \"finalized\", see the block parameter\n\nparams: [\n \"0x407d73d8a49eeb85d32cf465507dd71d507100c1\",\n \"latest\", // state at the latest block\n]\n\nReturns\nQUANTITY - integer of the number of transactions sent from this address.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getTransactionCount\",\"params\":[\"0x407d73d8a49eeb85d32cf465507dd71d507100c1\",\"latest\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\" // 1\n}\n\neth_getBlockTransactionCountByHash\nReturns the number of transactions in a block from a block matching the given block hash.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 32 Bytes - hash of a block\n\nparams: [\"0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b\"]\n\nReturns\nQUANTITY - integer of the number of transactions in this block.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockTransactionCountByHash\",\"params\":[\"0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x8b\" // 139\n}\n\neth_getBlockTransactionCountByNumber\nReturns the number of transactions in a block matching the given block number.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nQUANTITY|TAG - integer of a block number, or the string \"earliest\", \"latest\", \"pending\", \"safe\" or \"finalized\", as in the block parameter.\n\nparams: [\n \"0x13738ca\", // 20396234\n]\n\nReturns\nQUANTITY - integer of the number of transactions in this block.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockTransactionCountByNumber\",\"params\":[\"0x13738ca\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x8b\" // 139\n}\n\neth_getUncleCountByBlockHash\nReturns the number of uncles in a block from a block matching the given block hash.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 32 Bytes - hash of a block\n\nparams: [\"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\"]\n\nReturns\nQUANTITY - integer of the number of uncles in this block.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getUncleCountByBlockHash\",\"params\":[\"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\" // 1\n}\n\neth_getUncleCountByBlockNumber\nReturns the number of uncles in a block from a block matching the given block number.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nQUANTITY|TAG - integer of a block number, or the string \"latest\", \"earliest\", \"pending\", \"safe\" or \"finalized\", see the block parameter\n\nparams: [\n \"0xe8\", // 232\n]\n\nReturns\nQUANTITY - integer of the number of uncles in this block.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getUncleCountByBlockNumber\",\"params\":[\"0xe8\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x0\" // 0\n}\n\neth_getCode\nReturns code at a given address.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 20 Bytes - address\nQUANTITY|TAG - integer block number, or the string \"latest\", \"earliest\", \"pending\", \"safe\" or \"finalized\", see the block parameter\n\nparams: [\n \"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\",\n \"0x5daf3b\", // 6139707\n]\n\nReturns\nDATA - the code from the given address.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getCode\",\"params\":[\"0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2\", \"0x5daf3b\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029\"\n}\n\neth_sign\nThe sign method calculates an Ethereum specific signature with: sign(keccak256(\"\\x19Ethereum Signed Message:\\n\" + len(message) + message))).\nBy adding a prefix to the message makes the calculated signature recognizable as an Ethereum specific signature. This prevents misuse where a malicious dapp can sign arbitrary data (e.g., transaction) and use the signature to impersonate the victim.\nNote: the address to sign with must be unlocked.\nParameters\n\nDATA, 20 Bytes - address\nDATA, N Bytes - message to sign\n\nReturns\nDATA: Signature\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_sign\",\"params\":[\"0x9b2055d370f73ec7d8a03e965129118dc8f5bf83\", \"0xdeadbeaf\"],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b\"\n}\n\neth_signTransaction\nSigns a transaction that can be submitted to the network at a later time using with eth_sendRawTransaction.\nParameters\n\nObject - The transaction object\n\ntype:\nfrom: DATA, 20 Bytes - The address the transaction is sent from.\nto: DATA, 20 Bytes - (optional when creating new contract) The address the transaction is directed to.\ngas: QUANTITY - (optional, default: 90000) Integer of the gas provided for the transaction execution. It will return unused gas.\ngasPrice: QUANTITY - (optional, default: To-Be-Determined) Integer of the gasPrice used for each paid gas, in Wei.\nvalue: QUANTITY - (optional) Integer of the value sent with this transaction, in Wei.\ndata: DATA - The compiled code of a contract OR the hash of the invoked method signature and encoded parameters.\nnonce: QUANTITY - (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce.\n\nReturns\nDATA, The RLP-encoded transaction object signed by the specified account.\nExample\n// Request\ncurl -X POST --data '{\"id\": 1,\"jsonrpc\": \"2.0\",\"method\": \"eth_signTransaction\",\"params\": [{\"data\":\"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\"from\": \"0xb60e8dd61c5d32be8058bb8eb970870f07233155\",\"gas\": \"0x76c0\",\"gasPrice\": \"0x9184e72a000\",\"to\": \"0xd46e8dd67c5d32be8058bb8eb970870f07244567\",\"value\": \"0x9184e72a\"}]}'\n// Result\n{\n \"id\": 1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b\"\n}\n\neth_sendTransaction\nCreates new message call transaction or a contract creation, if the data field contains code, and signs it using the account specified in from.\nParameters\n\nObject - The transaction object\n\nfrom: DATA, 20 Bytes - The address the transaction is sent from.\nto: DATA, 20 Bytes - (optional when creating new contract) The address the transaction is directed to.\ngas: QUANTITY - (optional, default: 90000) Integer of the gas provided for the transaction execution. It will return unused gas.\ngasPrice: QUANTITY - (optional, default: To-Be-Determined) Integer of the gasPrice used for each paid gas.\nvalue: QUANTITY - (optional) Integer of the value sent with this transaction.\ninput: DATA - The compiled code of a contract OR the hash of the invoked method signature and encoded parameters.\nnonce: QUANTITY - (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce.\n\nparams: [\n {\n from: \"0xb60e8dd61c5d32be8058bb8eb970870f07233155\",\n to: \"0xd46e8dd67c5d32be8058bb8eb970870f07244567\",\n gas: \"0x76c0\", // 30400\n gasPrice: \"0x9184e72a000\", // 10000000000000\n value: \"0x9184e72a\", // 2441406250\n input:\n \"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\n },\n]\n\nReturns\nDATA, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.\nUse eth_getTransactionReceipt to get the contract address, after the transaction was proposed in a block, when you created a contract.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_sendTransaction\",\"params\":[{see above}],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\"\n}\n\neth_sendRawTransaction\nCreates new message call transaction or a contract creation for signed transactions.\nParameters\n\nDATA, The signed transaction data.\n\nparams: [\n \"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675\",\n]\n\nReturns\nDATA, 32 Bytes - the transaction hash, or the zero hash if the transaction is not yet available.\nUse eth_getTransactionReceipt to get the contract address, after the transaction was proposed in a block, when you created a contract.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_sendRawTransaction\",\"params\":[{see above}],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331\"\n}\n\neth_call\nExecutes a new message call immediately without creating a transaction on the blockchain. Often used for executing read-only smart contract functions, for example the balanceOf for an ERC-20 contract.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nObject - The transaction call object\n\nfrom: DATA, 20 Bytes - (optional) The address the transaction is sent from.\nto: DATA, 20 Bytes - The address the transaction is directed to.\ngas: QUANTITY - (optional) Integer of the gas provided for the transaction execution. eth_call consumes zero gas, but this parameter may be needed by some executions.\ngasPrice: QUANTITY - (optional) Integer of the gasPrice used for each paid gas\nvalue: QUANTITY - (optional) Integer of the value sent with this transaction\ninput: DATA - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI in the Solidity documentation (opens in a new tab).\n\nQUANTITY|TAG - integer block number, or the string \"latest\", \"earliest\", \"pending\", \"safe\" or \"finalized\", see the block parameter\n\nReturns\nDATA - the return value of executed contract.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_call\",\"params\":[{see above}],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x\"\n}\n\neth_estimateGas\nGenerates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. Note that the estimate may be significantly more than the amount of gas actually used by the transaction, for a variety of reasons including EVM mechanics and node performance.\nTry endpoint in playground (opens in a new tab)\nParameters\nSee eth_call parameters, except that all properties are optional. If no gas limit is specified geth uses the block gas limit from the pending block as an upper bound. As a result the returned estimate might not be enough to execute the call/transaction when the amount of gas is higher than the pending block gas limit.\nReturns\nQUANTITY - the amount of gas used.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_estimateGas\",\"params\":[{see above}],\"id\":1}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x5208\" // 21000\n}\n\neth_getBlockByHash\nReturns information about a block by hash.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 32 Bytes - Hash of a block.\nBoolean - If true it returns the full transaction objects, if false only the hashes of the transactions.\n\nparams: [\n \"0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae\",\n false,\n]\n\nReturns\nObject - A block object, or null when no block was found:\n\nnumber: QUANTITY - the block number. null when its pending block.\nhash: DATA, 32 Bytes - hash of the block. null when its pending block.\nparentHash: DATA, 32 Bytes - hash of the parent block.\nnonce: DATA, 8 Bytes - hash of the generated proof-of-work. null when its pending block, 0x0 for proof-of-stake blocks (since The Merge)\nsha3Uncles: DATA, 32 Bytes - SHA3 of the uncles data in the block.\nlogsBloom: DATA, 256 Bytes - the bloom filter for the logs of the block. null when its pending block.\ntransactionsRoot: DATA, 32 Bytes - the root of the transaction trie of the block.\nstateRoot: DATA, 32 Bytes - the root of the final state trie of the block.\nreceiptsRoot: DATA, 32 Bytes - the root of the receipts trie of the block.\nminer: DATA, 20 Bytes - the address of the beneficiary to whom the block rewards were given.\ndifficulty: QUANTITY - integer of the difficulty for this block.\ntotalDifficulty: QUANTITY - integer of the total difficulty of the chain until this block.\nextraData: DATA - the \"extra data\" field of this block.\nsize: QUANTITY - integer the size of this block in bytes.\ngasLimit: QUANTITY - the maximum gas allowed in this block.\ngasUsed: QUANTITY - the total used gas by all transactions in this block.\ntimestamp: QUANTITY - the unix timestamp for when the block was collated.\ntransactions: Array - Array of transaction objects, or 32 Bytes transaction hashes depending on the last given parameter.\nuncles: Array - Array of uncle hashes.\n\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockByHash\",\"params\":[\"0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae\", false],\"id\":1}'\n// Result\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"result\": {\n \"difficulty\": \"0x4ea3f27bc\",\n \"extraData\": \"0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32\",\n \"gasLimit\": \"0x1388\",\n \"gasUsed\": \"0x0\",\n \"hash\": \"0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae\",\n \"logsBloom\": \"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\n \"miner\": \"0xbb7b8287f3f0a933474a79eae42cbca977791171\",\n \"mixHash\": \"0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843\",\n \"nonce\": \"0x689056015818adbe\",\n \"number\": \"0x1b4\",\n \"parentHash\": \"0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54\",\n \"receiptsRoot\": \"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421\",\n \"sha3Uncles\": \"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347\",\n \"size\": \"0x220\",\n \"stateRoot\": \"0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d\",\n \"timestamp\": \"0x55ba467c\",\n \"totalDifficulty\": \"0x78ed983323d\",\n \"transactions\": [\n ],\n \"transactionsRoot\": \"0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421\",\n \"uncles\": [\n ]\n }\n}\n\neth_getBlockByNumber\nReturns information about a block by block number.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nQUANTITY|TAG - integer of a block number, or the string \"earliest\", \"latest\", \"pending\", \"safe\" or \"finalized\", as in the block parameter.\nBoolean - If true it returns the full transaction objects, if false only the hashes of the transactions.\n\nparams: [\n \"0x1b4\", // 436\n true,\n]\n\nReturns\nSee eth_getBlockByHash\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockByNumber\",\"params\":[\"0x1b4\", true],\"id\":1}'\n\nResult see eth_getBlockByHash\neth_getTransactionByHash\nReturns the information about a transaction requested by transaction hash.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 32 Bytes - hash of a transaction\n\nparams: [\"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\"]\n\nReturns\nObject - A transaction object, or null when no transaction was found:\n\nblockHash: DATA, 32 Bytes - hash of the block where this transaction was in. null when its pending.\nblockNumber: QUANTITY - block number where this transaction was in. null when its pending.\nfrom: DATA, 20 Bytes - address of the sender.\ngas: QUANTITY - gas provided by the sender.\ngasPrice: QUANTITY - gas price provided by the sender in Wei.\nhash: DATA, 32 Bytes - hash of the transaction.\ninput: DATA - the data send along with the transaction.\nnonce: QUANTITY - the number of transactions made by the sender prior to this one.\nto: DATA, 20 Bytes - address of the receiver. null when its a contract creation transaction.\ntransactionIndex: QUANTITY - integer of the transactions index position in the block. null when its pending.\nvalue: QUANTITY - value transferred in Wei.\nv: QUANTITY - ECDSA recovery id\nr: QUANTITY - ECDSA signature r\ns: QUANTITY - ECDSA signature s\n\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getTransactionByHash\",\"params\":[\"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\"],\"id\":1}'\n// Result\n{\n \"jsonrpc\":\"2.0\",\n \"id\":1,\n \"result\":{\n \"blockHash\":\"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\",\n \"blockNumber\":\"0x5daf3b\", // 6139707\n \"from\":\"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d\",\n \"gas\":\"0xc350\", // 50000\n \"gasPrice\":\"0x4a817c800\", // 20000000000\n \"hash\":\"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b\",\n \"input\":\"0x68656c6c6f21\",\n \"nonce\":\"0x15\", // 21\n \"to\":\"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb\",\n \"transactionIndex\":\"0x41\", // 65\n \"value\":\"0xf3dbb76162000\", // 4290000000000000\n \"v\":\"0x25\", // 37\n \"r\":\"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea\",\n \"s\":\"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c\"\n }\n}\n\neth_getTransactionByBlockHashAndIndex\nReturns information about a transaction by block hash and transaction index position.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 32 Bytes - hash of a block.\nQUANTITY - integer of the transaction index position.\n\nparams: [\n \"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\",\n \"0x0\", // 0\n]\n\nReturns\nSee eth_getTransactionByHash\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getTransactionByBlockHashAndIndex\",\"params\":[\"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\", \"0x0\"],\"id\":1}'\n\nResult see eth_getTransactionByHash\neth_getTransactionByBlockNumberAndIndex\nReturns information about a transaction by block number and transaction index position.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nQUANTITY|TAG - a block number, or the string \"earliest\", \"latest\", \"pending\", \"safe\" or \"finalized\", as in the block parameter.\nQUANTITY - the transaction index position.\n\nparams: [\n \"0x9c47cf\", // 10241999\n \"0x24\", // 36\n]\n\nReturns\nSee eth_getTransactionByHash\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getTransactionByBlockNumberAndIndex\",\"params\":[\"0x9c47cf\", \"0x24\"],\"id\":1}'\n\nResult see eth_getTransactionByHash\neth_getTransactionReceipt\nReturns the receipt of a transaction by transaction hash.\nNote That the receipt is not available for pending transactions.\nParameters\n\nDATA, 32 Bytes - hash of a transaction\n\nparams: [\"0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5\"]\n\nReturns\nObject - A transaction receipt object, or null when no receipt was found:\n\ntransactionHash : DATA, 32 Bytes - hash of the transaction.\ntransactionIndex: QUANTITY - integer of the transactions index position in the block.\nblockHash: DATA, 32 Bytes - hash of the block where this transaction was in.\nblockNumber: QUANTITY - block number where this transaction was in.\nfrom: DATA, 20 Bytes - address of the sender.\nto: DATA, 20 Bytes - address of the receiver. null when its a contract creation transaction.\ncumulativeGasUsed : QUANTITY - The total amount of gas used when this transaction was executed in the block.\neffectiveGasPrice : QUANTITY - The sum of the base fee and tip paid per unit of gas.\ngasUsed : QUANTITY - The amount of gas used by this specific transaction alone.\ncontractAddress : DATA, 20 Bytes - The contract address created, if the transaction was a contract creation, otherwise null.\nlogs: Array - Array of log objects, which this transaction generated.\nlogsBloom: DATA, 256 Bytes - Bloom filter for light clients to quickly retrieve related logs.\ntype: QUANTITY - integer of the transaction type, 0x0 for legacy transactions, 0x1 for access list types, 0x2 for dynamic fees.\n\nIt also returns either :\n\nroot : DATA 32 bytes of post-transaction state root (pre Byzantium)\nstatus: QUANTITY either 1 (success) or 0 (failure)\n\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getTransactionReceipt\",\"params\":[\"0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5\"],\"id\":1}'\n// Result\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"result\": {\n \"blockHash\":\n \"0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3\",\n \"blockNumber\": \"0xeff35f\",\n \"contractAddress\": null, // string of the address if it was created\n \"cumulativeGasUsed\": \"0xa12515\",\n \"effectiveGasPrice\": \"0x5a9c688d4\",\n \"from\": \"0x6221a9c005f6e47eb398fd867784cacfdcfff4e7\",\n \"gasUsed\": \"0xb4c8\",\n \"logs\": [{\n // logs as returned by getFilterLogs, etc.\n }],\n \"logsBloom\": \"0x00...0\", // 256 byte bloom filter\n \"status\": \"0x1\",\n \"to\": \"0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2\",\n \"transactionHash\":\n \"0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5\",\n \"transactionIndex\": \"0x66\",\n \"type\": \"0x2\"\n }\n}\n\neth_getUncleByBlockHashAndIndex\nReturns information about an uncle of a block by hash and uncle index position.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nDATA, 32 Bytes - The hash of a block.\nQUANTITY - The uncle's index position.\n\nparams: [\n \"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\",\n \"0x0\", // 0\n]\n\nReturns\nSee eth_getBlockByHash\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getUncleByBlockHashAndIndex\",\"params\":[\"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2\", \"0x0\"],\"id\":1}'\n\nResult see eth_getBlockByHash\nNote: An uncle doesn't contain individual transactions.\neth_getUncleByBlockNumberAndIndex\nReturns information about an uncle of a block by number and uncle index position.\nTry endpoint in playground (opens in a new tab)\nParameters\n\nQUANTITY|TAG - a block number, or the string \"earliest\", \"latest\", \"pending\", \"safe\", \"finalized\", as in the block parameter.\nQUANTITY - the uncle's index position.\n\nparams: [\n \"0x29c\", // 668\n \"0x0\", // 0\n]\n\nReturns\nSee eth_getBlockByHash\nNote: An uncle doesn't contain individual transactions.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getUncleByBlockNumberAndIndex\",\"params\":[\"0x29c\", \"0x0\"],\"id\":1}'\n\nResult see eth_getBlockByHash\neth_newFilter\nCreates a filter object, based on filter options, to notify when the state changes (logs).\nTo check if the state has changed, call eth_getFilterChanges.\nA note on specifying topic filters:\nTopics are order-dependent. A transaction with a log with topics [A, B] will be matched by the following topic filters:\n\n[] \"anything\"\n[A] \"A in first position (and anything after)\"\n[null, B] \"anything in first position AND B in second position (and anything after)\"\n[A, B] \"A in first position AND B in second position (and anything after)\"\n[[A, B], [A, B]] \"(A OR B) in first position AND (A OR B) in second position (and anything after)\"\nParameters\n\nObject - The filter options:\n\nfromBlock: QUANTITY|TAG - (optional, default: \"latest\") Integer block number, or \"latest\" for the last proposed block, \"safe\" for the latest safe block, \"finalized\" for the latest finalized block, or \"pending\", \"earliest\" for transactions not yet in a block.\ntoBlock: QUANTITY|TAG - (optional, default: \"latest\") Integer block number, or \"latest\" for the last proposed block, \"safe\" for the latest safe block, \"finalized\" for the latest finalized block, or \"pending\", \"earliest\" for transactions not yet in a block.\naddress: DATA|Array, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.\ntopics: Array of DATA, - (optional) Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with \"or\" options.\n\nparams: [\n {\n fromBlock: \"0x1\",\n toBlock: \"0x2\",\n address: \"0x8888f1f195afa192cfee860698584c030f4c9db1\",\n topics: [\n \"0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b\",\n null,\n [\n \"0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b\",\n \"0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc\",\n ],\n ],\n },\n]\n\nReturns\nQUANTITY - A filter id.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newFilter\",\"params\":[{\"topics\":[\"0x12341234\"]}],\"id\":73}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\" // 1\n}\n\neth_newBlockFilter\nCreates a filter in the node, to notify when a new block arrives.\nTo check if the state has changed, call eth_getFilterChanges.\nParameters\nNone\nReturns\nQUANTITY - A filter id.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newBlockFilter\",\"params\":[],\"id\":73}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\" // 1\n}\n\neth_newPendingTransactionFilter\nCreates a filter in the node, to notify when new pending transactions arrive.\nTo check if the state has changed, call eth_getFilterChanges.\nParameters\nNone\nReturns\nQUANTITY - A filter id.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_newPendingTransactionFilter\",\"params\":[],\"id\":73}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": \"0x1\" // 1\n}\n\neth_uninstallFilter\nUninstalls a filter with given id. Should always be called when watch is no longer needed.\nAdditionally Filters timeout when they aren't requested with eth_getFilterChanges for a period of time.\nParameters\n\nQUANTITY - The filter id.\n\nparams: [\n \"0xb\", // 11\n]\n\nReturns\nBoolean - true if the filter was successfully uninstalled, otherwise false.\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_uninstallFilter\",\"params\":[\"0xb\"],\"id\":73}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\": \"2.0\",\n \"result\": true\n}\n\neth_getFilterChanges\nPolling method for a filter, which returns an array of logs which occurred since last poll.\nParameters\n\nQUANTITY - the filter id.\n\nparams: [\n \"0x16\", // 22\n]\n\nReturns\nArray - Array of log objects, or an empty array if nothing has changed since last poll.\n\nFor filters created with eth_newBlockFilter the return are block hashes (DATA, 32 Bytes), e.g., [\"0x3454645634534...\"].\n\nFor filters created with eth_newPendingTransactionFilter the return are transaction hashes (DATA, 32 Bytes), e.g., [\"0x6345343454645...\"].\n\nFor filters created with eth_newFilter logs are objects with following params:\n\nremoved: TAG - true when the log was removed, due to a chain reorganization. false if its a valid log.\nlogIndex: QUANTITY - integer of the log index position in the block. null when its pending log.\ntransactionIndex: QUANTITY - integer of the transactions index position log was created from. null when its pending log.\ntransactionHash: DATA, 32 Bytes - hash of the transactions this log was created from. null when its pending log.\nblockHash: DATA, 32 Bytes - hash of the block where this log was in. null when its pending. null when its pending log.\nblockNumber: QUANTITY - the block number where this log was in. null when its pending. null when its pending log.\naddress: DATA, 20 Bytes - address from which this log originated.\ndata: DATA - variable-length non-indexed log data. (In solidity: zero or more 32 Bytes non-indexed log arguments.)\ntopics: Array of DATA - Array of 0 to 4 32 Bytes DATA of indexed log arguments. (In solidity: The first topic is the hash of the signature of the event (e.g., Deposit(address,bytes32,uint256)), except you declared the event with the anonymous specifier.)\n\nExample\n\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getFilterChanges\",\"params\":[\"0x16\"],\"id\":73}'\n// Result\n{\n \"id\":1,\n \"jsonrpc\":\"2.0\",\n \"result\": [{\n \"logIndex\": \"0x1\", // 1\n \"blockNumber\":\"0x1b4\", // 436\n \"blockHash\": \"0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"transactionHash\": \"0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf\",\n \"transactionIndex\": \"0x0\", // 0\n \"address\": \"0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d\",\n \"data\":\"0x0000000000000000000000000000000000000000000000000000000000000000\",\n \"topics\": [\"0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5\"]\n },{\n ...\n }]\n}\n\neth_getFilterLogs\nReturns an array of all logs matching filter with given id.\nParameters\n\nQUANTITY - The filter id.\n\nparams: [\n \"0x16\", // 22\n]\n\nReturns\nSee eth_getFilterChanges\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getFilterLogs\",\"params\":[\"0x16\"],\"id\":74}'\n\nResult see eth_getFilterChanges\neth_getLogs\nReturns an array of all logs matching a given filter object.\nParameters\n\nObject - The filter options:\n\nfromBlock: QUANTITY|TAG - (optional, default: \"latest\") Integer block number, or \"latest\" for the last proposed block, \"safe\" for the latest safe block, \"finalized\" for the latest finalized block, or \"pending\", \"earliest\" for transactions not yet in a block.\ntoBlock: QUANTITY|TAG - (optional, default: \"latest\") Integer block number, or \"latest\" for the last proposed block, \"safe\" for the latest safe block, \"finalized\" for the latest finalized block, or \"pending\", \"earliest\" for transactions not yet in a block.\naddress: DATA|Array, 20 Bytes - (optional) Contract address or a list of addresses from which logs should originate.\ntopics: Array of DATA, - (optional) Array of 32 Bytes DATA topics. Topics are order-dependent. Each topic can also be an array of DATA with \"or\" options.\nblockHash: DATA, 32 Bytes - (optional, future) With the addition of EIP-234, blockHash will be a new filter option which restricts the logs returned to the single block with the 32-byte hash blockHash. Using blockHash is equivalent to fromBlock = toBlock = the block number with hash blockHash. If blockHash is present in the filter criteria, then neither fromBlock nor toBlock are allowed.\n\nparams: [\n {\n topics: [\n \"0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b\",\n ],\n },\n]\n\nReturns\nSee eth_getFilterChanges\nExample\n// Request\ncurl -X POST --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getLogs\",\"params\":[{\"topics\":[\"0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b\"]}],\"id\":74}'\n\nResult see eth_getFilterChanges\nUsage Example\nDeploying a contract using JSON_RPC\nThis section includes a demonstration of how to deploy a contract using only the RPC interface. There are alternative routes to deploying contracts where this complexity is abstracted away—for example, using libraries built on top of the RPC interface such as web3.js (opens in a new tab) and web3.py (opens in a new tab). These abstractions are generally easier to understand and less error-prone, but it is still helpful to understand what is happening under the hood.\nThe following is a straightforward smart contract called Multiply7 that will be deployed using the JSON-RPC interface to an Ethereum node. This tutorial assumes the reader is already running a Geth node. More information on nodes and clients is available here. Please refer to individual client documentation to see how to start the HTTP JSON-RPC for non-Geth clients. Most clients default to serving on localhost:8545.\ncontract Multiply7 {\n event Print(uint);\n function multiply(uint input) returns (uint) {\n Print(input * 7);\n return input * 7;\n }\n}\n\nThe first thing to do is make sure the HTTP RPC interface is enabled. This means we supply Geth with the --http flag on startup. In this example we use the Geth node on a private development chain. Using this approach we don't need ether on the real network.\ngeth --http --dev console 2>>geth.log\n\nThis will start the HTTP RPC interface on http://localhost:8545.\nWe can verify that the interface is running by retrieving the coinbase address (by obtaining the first address from the array of accounts) and balance using curl (opens in a new tab). Please note that data in these examples will differ on your local node. If you want to try these commands, replace the request params in the second curl request with the result returned from the first.\ncurl --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_accounts\",\"params\":[], \"id\":1}' -H \"Content-Type: application/json\" localhost:8545\n{\"id\":1,\"jsonrpc\":\"2.0\",\"result\":[\"0x9b1d35635cc34752ca54713bb99d38614f63c955\"]}\n\ncurl --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBalance\", \"params\": [\"0x9b1d35635cc34752ca54713bb99d38614f63c955\", \"latest\"], \"id\":2}' -H \"Content-Type: application/json\" localhost:8545\n{\"id\":2,\"jsonrpc\":\"2.0\",\"result\":\"0x1639e49bba16280000\"}\n\nBecause numbers are hex encoded, the balance is returned in wei as a hex string. If we want to have the balance in ether as a number we can use web3 from the Geth console.\nweb3.fromWei(\"0x1639e49bba16280000\", \"ether\")\n// \"410\"\n\nNow that there is some ether on our private development chain, we can deploy the contract. The first step is to compile the Multiply7 contract to byte code that can be sent to the EVM. To install solc, the Solidity compiler, follow the Solidity documentation (opens in a new tab). (You might want to use an older solc release to match the version of compiler used for our example (opens in a new tab).)\nThe next step is to compile the Multiply7 contract to byte code that can be sent to the EVM.\necho 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin\n\n======= <stdin>:Multiply7 =======\nBinary:\n6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029\n\nNow that we have the compiled code we need to determine how much gas it costs to deploy it. The RPC interface has an eth_estimateGas method that will give us an estimate.\ncurl --data '{\"jsonrpc\":\"2.0\",\"method\": \"eth_estimateGas\", \"params\": [{\"from\": \"0x9b1d35635cc34752ca54713bb99d38614f63c955\", \"data\": \"0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029\"}], \"id\": 5}' -H \"Content-Type: application/json\" localhost:8545\n{\"jsonrpc\":\"2.0\",\"id\":5,\"result\":\"0x1c31e\"}\n\nAnd finally deploy the contract.\ncurl --data '{\"jsonrpc\":\"2.0\",\"method\": \"eth_sendTransaction\", \"params\": [{\"from\": \"0x9b1d35635cc34752ca54713bb99d38614f63c955\", \"gas\": \"0x1c31e\", \"data\": \"0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029\"}], \"id\": 6}' -H \"Content-Type: application/json\" localhost:8545\n{\"id\":6,\"jsonrpc\":\"2.0\",\"result\":\"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf\"}\n\nThe transaction is accepted by the node and a transaction hash is returned. This hash can be used to track the transaction. The next step is to determine the address where our contract is deployed. Each executed transaction will create a receipt. This receipt contains various information about the transaction such as in which block the transaction was included and how much gas was used by the EVM. If a transaction\ncreates a contract it will also contain the contract address. We can retrieve the receipt with the eth_getTransactionReceipt RPC method.\ncurl --data '{\"jsonrpc\":\"2.0\",\"method\": \"eth_getTransactionReceipt\", \"params\": [\"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf\"], \"id\": 7}' -H \"Content-Type: application/json\" localhost:8545\n{\"jsonrpc\":\"2.0\",\"id\":7,\"result\":{\"blockHash\":\"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f\",\"blockNumber\":\"0x1\",\"contractAddress\":\"0x4d03d617d700cf81935d7f797f4e2ae719648262\",\"cumulativeGasUse","tokens":15000,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264752874,"hash":"459d538d101e2db228bcc3bd4b812e646027af0f"}
{"url":"https://docs.pyth.network/price-feeds/core/error-codes/svm","domain":"docs.pyth.network","title":"SVM Error Codes | Pyth Developer Hub","text":"Pyth CoreError CodesSVM Error CodesDecode the error codes emitted by Pyth SVM contractsThe following tables contain the errors used in the Pyth Network's SVM contracts.\nThis information is derived from the pyth-solana-receiver error.rs\nand pyth_solana_receiver_sdk error.rs\nfiles and can be used to decode error codes programmatically.\nReceiver Errors\nError CodeErrorError Description6000InvalidWormholeMessageReceived an invalid wormhole message.6001DeserializeMessageFailedAn error occurred when deserializing the message.6002InvalidPriceUpdateReceived an invalid price update.6003UnsupportedMessageTypeThis type of message is not supported currently.6004InvalidDataSourceThe tuple emitter chain, emitter doesn't match one of the valid data sources.6005InsufficientFundsFunds are insufficient to pay the receiving fee.6007ExponentMismatchThe start and end messages must have the same feed ID.6012WrongWriteAuthorityThis signer can't write to price update account.6013WrongVaaOwnerThe posted VAA account has the wrong owner.6014DeserializeVaaFailedAn error occurred when deserializing the VAA.6015InsufficientGuardianSignaturesThe number of guardian signatures is below the minimum.6016InvalidVaaVersionInvalid VAA version.6017GuardianSetMismatchGuardian set version in the VAA doesn't match the guardian set passed.6018InvalidGuardianOrderGuardian signature indices must be increasing.6019InvalidGuardianIndexGuardian index exceeds the number of guardians in the set.6020InvalidSignatureA VAA signature is invalid.6021InvalidGuardianKeyRecoveryThe recovered guardian public key doesn't match the guardian set.6022WrongGuardianSetOwnerThe guardian set account is owned by the wrong program.6023InvalidGuardianSetPdaThe Guardian Set account doesn't match the PDA derivation.6024GuardianSetExpiredThe Guardian Set is expired.6025GovernanceAuthorityMismatchThe signer is not authorized to perform this governance action.6026TargetGovernanceAuthorityMismatchThe signer is not authorized to accept the governance authority.6027NonexistentGovernanceAuthorityTransferRequestThe governance authority needs to request a transfer first.6028ZeroMinimumSignaturesThe minimum number of signatures should be at least 1.\nSDK Errors\nThese errors are returned by the Pyth Solana Receiver SDK when reading price data.\nError CodeErrorError Description10000PriceTooOldThis price feed update's age exceeds the requested maximum age.10002MismatchedFeedIdThe price feed update doesn't match the requested feed id.10003InsufficientVerificationLevelThis price feed update has a lower verification level than the one requested.10004FeedIdMustBe32BytesFeed id must be 32 Bytes, that's 64 hex characters or 66 with a 0x prefix.10005FeedIdNonHexCharacterFeed id contains non-hex characters.EVM Error CodesDecode the error codes emitted by Pyth EVM contractsContract AddressesFind deployed Pyth contract addresses across supported blockchains","tokens":728,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264758029,"hash":"b159dfbb22ceb7ecfb62d508000747173a689a69"}
{"url":"https://governance.aave.com/t/ignas-delegate-platform/19510/1","domain":"governance.aave.com","title":"Ignas Delegate Platform - Delegate Platforms - Aave","text":"Ignas Delegate Platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2024\n\n 1 / 197\n\n Oct 2024\n\n May 14\n\n post by Ignas on Oct 18, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 1. Basic Info\n\nName: Ignas\nDelegate Address: ignasdefi.eth | 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0\nX (Twitter): x.com\nTelegram: @ignasdefi\nWebsite: https://pinkbrains.io/\n\n2. Intro\nI’m Ignas, a solo researcher with the main focus on DeFi. My mission is to provide clear, in-depth insights helping my audiences stay up-to-date with the latest trends while actively supporting DAO development.\nI believe in the decentralized future and it means actively participating in Aave DAO in every way I can—whether it’s by serving as a delegate, joining working groups, discussing any proposals or seizing new opportunities that come up. I’ll also be sharing key DAO decisions on X and my blog.\n3. Delegate Communication Intent\nI’m committed to keeping the Aave community informed with regular, transparent updates. I’ll provide clear insights into my voting choices and reasoning to ensure everyone understands the direction we’re headed and why.\n4. Why I Want to be a Delegate\nCurrently, DeFi DAOs face several internal issues, such as voter apathy leading to governance attacks, insider voting, and voting concentration among a few active voting addresses. Additionally, they face external challenges like regulatory uncertainty.\nI believe in a decentralized future, even if it seems naive. However, the current state of crypto is plagued by misaligned incentives that prioritize short-term speculative gains over the core DeFi values of self-sovereignty and custody.\nEqually concerning is the trend of McKinsification in DAOs, where decisions are increasingly made by one or two professional consultant delegates. This discourages individual participation, as their opinions and votes have less impact.\nTo make DeFi DAOs viable, we must align incentives to encourage active participation in governance from the broader crypto community. I believe that community must be at the core of every DAO. Without giving the community a say in protocol governance, we’re no better than the Web2 companies we aim to replace—companies that view their “community” merely as users to extract value from.\nI will support initiatives that align token holders with the protocol, such as revenue sharing or other methods to bring value to the token. Token holders are frustrated with exploitative tokenomics that only benefit early insiders who acquired tokens at much lower prices, leaving no upside for new investors. Without incentives to buy and hold tokens, the attractiveness and health of DAOs decline.\nAs mentioned, I will highlight key votes and decisions of the DAO on X and my blog, as I believe the general public is often unaware of important actions being taken.\n5. Disclosure\nI am the co-founder of Pink Brains, an organization dedicated to promoting various crypto projects through educational content. You can find more info about us here: pinkbrains | Twitter | Linktree.\nI’m a delegate for Lido and Instadapp and will be soon a delegate in Arbitrum. Moreover, I’m actively involved in Uniswap, Optimism and here - Aave. I plan to apply as a delegate to other DAOs soon, with the same mission of strengthening them and aligning token holders with the protocol.\nI always make appropriate disclosures and recuse myself from voting when necessary.\n6. Delegation\nIf anyone would like to delegate to me, please use the following address: 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0\n\n read \n\n 54\n min\n\n post by Ignas on Oct 22, 2024\n\n post by Ignas on Oct 22, 2024\n\n post by Ignas on Oct 22, 2024\n\n post by Ignas on Oct 22, 2024\n\n post by Ignas on Oct 22, 2024\n\n post by Ignas on Oct 22, 2024\n\n post by Ignas on Oct 24, 2024\n\n post by Ignas on Oct 24, 2024\n\n post by Ignas on Oct 29, 2024\n\n post by Ignas on Oct 31, 2024\n\n post by Ignas on Oct 31, 2024\n\n post by Ignas on Nov 4, 2024\n\n post by Ignas on Nov 6, 2024\n\n post by Ignas on Nov 12, 2024\n\n post by Ignas on Nov 12, 2024\n\n post by Ignas on Nov 14, 2024\n\n post by Ignas on Nov 15, 2024\n\n post by Ignas on Nov 18, 2024\n\n post by Ignas on Nov 19, 2024\n\n Load more posts below","tokens":1057,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264764032,"hash":"ff900372b3c1fbb101822153eab5d8fade8c5b32"}
{"url":"https://ethereum.org/developers/docs/data-and-analytics/","domain":"ethereum.org","title":"Data and analytics | ethereum.org","text":"Data and analyticsEdit page (opens in a new tab)Introduction\nAs utilization of the network continues to grow, an increasing amount of valuable information will exist in the onchain data. As the volume of data rapidly increases, calculating and aggregating this information to report upon or drive a dapp can become a time and process heavy endeavor.\nLeveraging existing data providers can expedite development, produce more accurate results, and reduce ongoing maintenance efforts. This will enable a team to concentrate on the core functionality their project is trying to provide.\nPrerequisites\nYou should understand the basic concept of Block Explorers in order to better understand using them in the data analytics context. In addition, familiarize yourself with the concept of an to understand the benefits they add to a system design.\nIn terms of architectural fundamentals, understanding what an API (opens in a new tab) and REST (opens in a new tab) are, even in theory.\nBlock explorers\nMany Block Explorers offer RESTful (opens in a new tab) API (opens in a new tab) gateways that will provide developers visibility into real-time data on blocks, transactions, validators, accounts, and other onchain activity.\nDevelopers can then process and transform this data to give their users unique insights and interactions with the . For example, Etherscan (opens in a new tab) and Blockscout (opens in a new tab) provide execution and consensus data for every 12s slot.\nThe Graph\nThe Graph (opens in a new tab) is an indexing protocol that provides an easy way to query blockchain data through open APIs known as subgraphs.\nWith The Graph, developers can benefit from:\n\nDecentralized indexing: Enables indexing blockchain data through multiple indexers, thus eliminating any single point of failure\nGraphQL queries: Provides a powerful GraphQL interface for querying indexed data, making data retrieval super simple\nCustomization: Define your own logic for transforming & storing blockchain data, and reuse subgraphs published by other developers on The Graph Network\n\nFollow this quick-start (opens in a new tab) guide to create, deploy, and query a subgraph within 5 minutes.\nClient diversity\nClient diversity is important for the overall health of the Ethereum network because it provides resilience to bugs and exploits. There are now several client diversity dashboards including clientdiversity.org (opens in a new tab), rated.network (opens in a new tab), supermajority.info (opens in a new tab) and Ethernodes (opens in a new tab).\nDune Analytics\nDune Analytics (opens in a new tab) pre-processes blockchain data into relational database (DuneSQL) tables, allows users to query blockchain data using SQL and build dashboards based on query results. Onchain data are organized into 4 raw tables: blocks, transactions, (event) logs and (call) traces. Popular contracts and protocols have been decoded, and each has its own set of event and call tables. Those event and call tables are processed further and organized into abstraction tables by the type of protocols, for example, dex, lending, stablecoins, etc.\nSQD\nSQD (opens in a new tab) is a decentralized hyper-scalable data platform optimized for providing efficient, permissionless access to large volumes of data. It currently serves historical on-chain data, including event logs, transaction receipts, traces, and per-transaction state diffs. SQD offers a powerful toolkit for creating custom data extraction and processing pipelines, achieving an indexing speed of up to 150k blocks per second.\nTo get started, visit the documentation (opens in a new tab) or see EVM examples (opens in a new tab) of what you can build with SQD.\nSubQuery Network\nSubQuery (opens in a new tab) is a leading data indexer that gives developers fast, reliable, decentralized, and customized APIs for their web3 projects. SubQuery empower developers from over 165+ ecosystems (including Ethereum) with rich indexed data to build an intuitive and immersive experiences for their users. The SubQuery Network powers your unstoppable apps with a resilient and decentralized infrastructure network. Use SubQuery's blockchain developer toolkit to build the web3 applications of the future, without spending time building a custom backend for data processing activities.\nTo start, visit the Ethereum quick start guide (opens in a new tab) to start indexing Ethereum blockchain data in minutes in a local Docker environment for testing before going live on a SubQuery's managed service (opens in a new tab) or on SubQuery's decentralised network (opens in a new tab).\nCodex\nCodex (opens in a new tab) is a real-time blockchain data API providing enriched data for 70 million+ tokens across 80+ networks. Developers can access structured token pricing, wallet balances, transaction history, and aggregated analytics (volume, liquidity, unique wallets) without maintaining custom indexing infrastructure. Codex supports sub-second data delivery via WebSocket and webhook integrations.\nTo get started, visit the documentation (opens in a new tab), try the Explorer (opens in a new tab), or sign up at the dashboard (opens in a new tab).\nMobula\nMobula (opens in a new tab) is a high-performance crypto data API providing real-time and historical market data, token metadata, wallet portfolios, and on-chain analytics across 90+ blockchains. Developers can access REST and GraphQL endpoints for token prices, market caps, trading volumes, liquidity data, and multi-chain wallet balances without running their own infrastructure. Mobula offers both free (100K requests/month) and paid plans for production applications.\nTo get started, visit the documentation (opens in a new tab), explore the API reference (opens in a new tab), or sign up at the dashboard (opens in a new tab).\nEVM Query Language\nEVM Query Language (EQL) is an SQL-like language designed to query EVM (Ethereum Virtual Machine) chains. EQL's ultimate goal is to support complex relational queries on EVM chain first-class citizens (blocks, accounts, and transactions) while providing developers and researchers with an ergonomic syntax for everyday use. With EQL, developers can fetch blockchain data using familiar SQL-like syntax and eliminate the need for complex boilerplate code. EQL supports standard blockchain data requests (e.g., retrieving an account's nonce and balance on Ethereum or fetching the current block size and timestamp) and is continually adding support for more complex requests and featuresets.\nEnvio\nEnvio (opens in a new tab) is an indexing framework that turns onchain events into a queryable GraphQL API. It supports Ethereum and any EVM-compatible chain. Developers write event handlers in TypeScript, JavaScript, or ReScript to serve real-time and historical data, with reorg support, multichain indexing, and managed hosting on Envio Cloud or self-hosting.\nTo get started, follow the HyperIndex quickstart (opens in a new tab) to create, deploy, and query an indexer.\nFurther Reading\n\nExploring Crypto Data I: Data Flow Architectures (opens in a new tab)\nGraph Network Overview (opens in a new tab)\nGraph Query Playground (opens in a new tab)\nAPI code examples on EtherScan (opens in a new tab)\nAPI documentation on Blockscout (opens in a new tab)\nBeaconcha.in Beacon Chain explorer (opens in a new tab)\nDune Basics (opens in a new tab)\nSubQuery Ethereum Quick Start Guide (opens in a new tab)\nSQD Network Overview (opens in a new tab)\nEVM Query Language (opens in a new tab)\n\nTutorials: Data & analytics / SQL on Ethereum\n\nLearn Foundational Ethereum Topics with SQL – Query on-chain Ethereum data with SQL to understand transactions, blocks, and gas fundamentals.","tokens":1925,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264764152,"hash":"b47e6a72bb0bd4c98af5fc5b2fc8227ddebb78f2"}
{"url":"https://docs.soliditylang.org/en/develop/introduction-to-smart-contracts.html","domain":"docs.soliditylang.org","title":"Introduction to Smart Contracts — Solidity 0.8.38-develop documentation","text":"Introduction to Smart Contracts\n\n Edit on GitHub\n\nIntroduction to Smart Contracts\n\nA Simple Smart Contract\nLet us begin with a basic example that sets the value of a variable and exposes\nit for other contracts to access. It is fine if you do not understand\neverything right now, we will go into more details later.\n\nStorage Example\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract SimpleStorage {\n uint storedData;\n\n function set(uint x) public {\n storedData = x;\n }\n\n function get() public view returns (uint) {\n return storedData;\n }\n}\n\nThe first line tells you that the source code is licensed under the\nGPL version 3.0. Machine-readable license specifiers are important\nin a setting where publishing the source code is the default.\nThe next line specifies that the source code is written for\nSolidity version 0.4.16, or a newer version of the language up to, but not including version 0.9.0.\nThis is to ensure that the contract is not compilable with a new (breaking) compiler version, where it could behave differently.\nPragmas are common instructions for compilers about how to treat the\nsource code (e.g. pragma once).\nA contract in the sense of Solidity is a collection of code (its functions) and\ndata (its state) that resides at a specific address on the Ethereum\nblockchain. The line uint storedData; declares a state variable called storedData of\ntype uint (unsigned integer of 256 bits). You can think of it as a single slot\nin a database that you can query and alter by calling functions of the\ncode that manages the database. In this example, the contract defines the\nfunctions set and get that can be used to modify\nor retrieve the value of the variable.\nTo access a member (like a state variable) of the current contract, you do not typically add the this. prefix,\nyou just access it directly via its name.\nUnlike in some other languages, omitting it is not just a matter of style,\nit results in a completely different way to access the member, but more on this later.\nThis contract does not do much yet apart from (due to the infrastructure\nbuilt by Ethereum) allowing anyone to store a single number that is accessible by\nanyone in the world without a (feasible) way to prevent you from publishing\nthis number. Anyone could call set again with a different value\nand overwrite your number, but the number is still stored in the history\nof the blockchain. Later, you will see how you can impose access restrictions\nso that only you can alter the number.\n\nWarning\nBe careful with using Unicode text, as similar looking (or even identical) characters can\nhave different code points and as such are encoded as a different byte array.\n\nNote\nAll identifiers (contract names, function names and variable names) are restricted to\nthe ASCII character set. It is possible to store UTF-8 encoded data in string variables.\n\nSubcurrency Example\nThe following contract implements the simplest form of a\ncryptocurrency. The contract allows only its creator to create new coins (different issuance schemes are possible).\nAnyone can send coins to each other without a need for\nregistering with a username and password, all you need is an Ethereum keypair.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.26;\n\n// This will only compile via IR\ncontract Coin {\n // The keyword \"public\" makes variables\n // accessible from other contracts\n address public minter;\n mapping(address => uint) public balances;\n\n // Events allow clients to react to specific\n // contract changes you declare\n event Sent(address from, address to, uint amount);\n\n // Constructor code is only run when the contract\n // is created\n constructor() {\n minter = msg.sender;\n }\n\n // Sends an amount of newly created coins to an address\n // Can only be called by the contract creator\n function mint(address receiver, uint amount) public {\n require(msg.sender == minter);\n balances[receiver] += amount;\n }\n\n // Errors allow you to provide information about\n // why an operation failed. They are returned\n // to the caller of the function.\n error InsufficientBalance(uint requested, uint available);\n\n // Sends an amount of existing coins\n // from any caller to an address\n function send(address receiver, uint amount) public {\n require(amount <= balances[msg.sender], InsufficientBalance(amount, balances[msg.sender]));\n balances[msg.sender] -= amount;\n balances[receiver] += amount;\n emit Sent(msg.sender, receiver, amount);\n }\n}\n\nThis contract introduces some new concepts, let us go through them one by one.\nThe line address public minter; declares a state variable of type address.\nThe address type is a 160-bit value that does not allow any arithmetic operations.\nIt is suitable for storing addresses of contracts, or a hash of the public half\nof a keypair belonging to externally-owned accounts.\nThe keyword public automatically generates a function that allows you to access the current value of the state\nvariable from outside of the contract. Without this keyword, other contracts have no way to access the variable.\nThe code of the function generated by the compiler is equivalent\nto the following (ignore external and view for now):\nopen in Remix\nfunction minter() external view returns (address) { return minter; }\n\nYou could add a function like the above yourself, but you would have a function and state variable with the same name.\nYou do not need to do this, the compiler figures it out for you.\nThe next line, mapping(address => uint) public balances; also\ncreates a public state variable, but it is a more complex datatype.\nThe mapping type maps addresses to unsigned integers.\nMappings can be seen as hash tables which are\nvirtually initialized such that every possible key exists from the start and is mapped to a\nvalue whose byte-representation is all zeros. However, it is neither possible to obtain a list of all keys of\na mapping, nor a list of all values. Record what you\nadded to the mapping, or use it in a context where this is not needed. Or\neven better, keep a list, or use a more suitable data type.\nThe getter function created by the public keyword\nis more complex in the case of a mapping. It looks like the\nfollowing:\nopen in Remix\nfunction balances(address account) external view returns (uint) {\n return balances[account];\n}\n\nYou can use this function to query the balance of a single account.\nThe line event Sent(address from, address to, uint amount); declares\nan “event”, which is emitted in the last line of the function\nsend. Ethereum clients such as web applications can\nlisten for these events emitted on the blockchain without much\ncost. As soon as it is emitted, the listener receives the\narguments from, to and amount, which makes it possible to track\ntransactions.\nTo listen for this event, you could use the following\nJavaScript code, which uses web3.js to create the Coin contract object,\nand any user interface calls the automatically generated balances function from above:\nCoin.Sent().watch({}, '', function(error, result) {\n if (!error) {\n console.log(\"Coin transfer: \" + result.args.amount +\n \" coins were sent from \" + result.args.from +\n \" to \" + result.args.to + \".\");\n console.log(\"Balances now:\\n\" +\n \"Sender: \" + Coin.balances.call(result.args.from) +\n \"Receiver: \" + Coin.balances.call(result.args.to));\n }\n})\n\nThe constructor is a special function that is executed during the creation of the contract and\ncannot be called afterwards. In this case, it permanently stores the address of the person creating the\ncontract. The msg variable (together with tx and block) is a\nspecial global variable that\ncontains properties which allow access to the blockchain. msg.sender is\nalways the address where the current (external) function call came from.\nThe functions that make up the contract, and that users and contracts can call are mint and send.\nThe mint function sends an amount of newly created coins to another address. The require function call defines conditions that reverts all changes if not met. In this\nexample, require(msg.sender == minter); ensures that only the creator of the contract can call\nmint. In general, the creator can mint as many tokens as they like, but at some point, this will\nlead to a phenomenon called “overflow”. Note that because of the default Checked arithmetic, the transaction would revert if the expression balances[receiver] += amount;\noverflows, i.e., when balances[receiver] + amount in arbitrary precision arithmetic is larger\nthan the maximum value of uint (2**256 - 1). This is also true for the statement\nbalances[receiver] += amount; in the function send.\nErrors allow you to provide more information to the caller about\nwhy a condition or operation failed. Errors are used together with the\nrevert statement. The revert statement unconditionally\naborts and reverts all changes, much like the require function.\nBoth approaches allow you to provide the name of an error and additional data which will be supplied to the caller\n(and eventually to the front-end application or block explorer) so that\na failure can more easily be debugged or reacted upon.\nThe send function can be used by anyone (who already\nhas some of these coins) to send coins to anyone else. If the sender does not have\nenough coins to send, the condition in require evaluates to false, triggering a revert\nwith the InsufficientBalance error. This error supplies the requested amount and available\nbalance to the caller, which front-end applications or block explorers can surface for debugging.\n\nNote\nIf you use\nthis contract to send coins to an address, you will not see anything when you\nlook at that address on a blockchain explorer, because the record that you sent\ncoins and the changed balances are only stored in the data storage of this\nparticular coin contract. By using events, you can create\na “blockchain explorer” that tracks transactions and balances of your new coin,\nbut you have to inspect the coin contract address and not the addresses of the\ncoin owners.\n\nBlockchain Basics\nBlockchains as a concept are not too hard to understand for programmers. The reason is that\nmost of the complications (mining, hashing,\nelliptic-curve cryptography,\npeer-to-peer networks, etc.)\nare just there to provide a certain set of features and promises for the platform. Once you accept these\nfeatures as given, you do not have to worry about the underlying technology - or do you have\nto know how Amazon’s AWS works internally in order to use it?\n\nTransactions\nA blockchain is a globally shared, transactional database.\nThis means that everyone can read entries in the database just by participating in the network.\nIf you want to change something in the database, you have to create a so-called transaction\nwhich has to be accepted by all others.\nThe word transaction implies that the change you want to make (assume you want to change\ntwo values at the same time) is either not done at all or completely applied. Furthermore,\nwhile your transaction is being applied to the database, no other transaction can alter it.\nAs an example, imagine a table that lists the balances of all accounts in an\nelectronic currency. If a transfer from one account to another is requested,\nthe transactional nature of the database ensures that if the amount is\nsubtracted from one account, it is always added to the other account. If due\nto whatever reason, adding the amount to the target account is not possible,\nthe source account is also not modified.\nFurthermore, a transaction is always cryptographically signed by the sender (creator).\nThis makes it straightforward to guard access to specific modifications of the\ndatabase. In the example of the electronic currency, a simple check ensures that\nonly the person holding the keys to the account can transfer some compensation, e.g. Ether, from it.\n\nBlocks\nOne major obstacle to overcome is what (in Bitcoin terms) is called a “double-spend attack”:\nWhat happens if two transactions exist in the network that both want to empty an account?\nOnly one of the transactions can be valid, typically the one that is accepted first.\nThe problem is that “first” is not an objective term in a peer-to-peer network.\nThe abstract answer to this is that you do not have to care. A globally accepted order of the transactions\nwill be selected for you, solving the conflict. The transactions will be bundled into what is called a “block”\nand then they will be executed and distributed among all participating nodes.\nIf two transactions contradict each other, the one that ends up being second will\nbe rejected and not become part of the block.\nThese blocks form a linear sequence in time, and that is where the word “blockchain” derives from.\nBlocks are added to the chain at regular intervals, although these intervals may be subject to change in the future.\nFor the most up-to-date information, it is recommended to monitor the network, for example, on Etherscan.\nAs part of the “order selection mechanism”, which is called attestation, it may happen that\nblocks are reverted from time to time, but only at the “tip” of the chain. The more\nblocks are added on top of a particular block, the less likely this block will be reverted. So it might be that your transactions\nare reverted and even removed from the blockchain, but the longer you wait, the less\nlikely it will be.\n\nNote\nTransactions are not guaranteed to be included in the next block or any specific future block,\nsince it is not up to the submitter of a transaction, but up to the miners to determine in which block the transaction is included.\nIf you want to schedule future calls of your contract, you can use\na smart contract automation tool or an oracle service.\n\nThe Ethereum Virtual Machine\n\nOverview\nThe Ethereum Virtual Machine or EVM is the runtime environment\nfor smart contracts in Ethereum. It is not only sandboxed but\nactually completely isolated, which means that code running\ninside the EVM has no access to network, filesystem or other processes.\nSmart contracts even have limited access to other smart contracts.\n\nAccounts\nThere are two kinds of accounts in Ethereum which share the same\naddress space: Externally-owned accounts that are controlled by\npublic-private key pairs (i.e. humans) and contract accounts which are\ncontrolled by the code stored together with the account.\nThe address of an externally-owned account is determined from\nthe public key while the address of a contract is\ndetermined at the time the contract is created\n(it is derived from the creator address and the number\nof transactions sent from that address, the so-called “nonce”).\nRegardless of whether or not the account stores code, the two types are\ntreated equally by the EVM.\nEvery account has a persistent key-value store mapping 256-bit words to 256-bit\nwords called storage.\nFurthermore, every account has a balance in\nEther (in “Wei” to be exact, 1 ether is 10**18 wei) which can be modified by sending transactions that\ninclude Ether.\n\nTransactions\nA transaction is a message that is sent from one account to another\naccount (which might be the same or empty, see below).\nIt can include binary data (which is called “payload”) and Ether.\nIf the target account contains code, that code is executed and\nthe payload is provided as input data.\nIf the target account is not set (the transaction does not have\na recipient or the recipient is set to null), the transaction\ncreates a new contract.\nAs already mentioned, the address of that contract is not\nthe zero address but an address derived from the sender and\nits number of transactions sent (the “nonce”). The payload\nof such a contract creation transaction is taken to be\nEVM bytecode and executed. The output data of this execution is\npermanently stored as the code of the contract.\nThis means that in order to create a contract, you do not\nsend the actual code of the contract, but in fact code that\nreturns that code when executed.\n\nNote\nWhile a contract is being created, its code is still empty.\nBecause of that, you should not call back into the\ncontract under construction until its constructor has\nfinished executing.\n\nGas\nUpon creation, each transaction is charged with a certain amount of gas\nthat has to be paid for by the originator of the transaction (tx.origin).\nWhile the EVM executes the\ntransaction, the gas is gradually depleted according to specific rules.\nIf the gas is used up at any point (i.e. it would be negative),\nan out-of-gas exception is triggered, which ends execution and reverts all modifications\nmade to the state in the current call frame.\nThis mechanism incentivizes economical use of EVM execution time\nand also compensates EVM executors (i.e. miners / stakers) for their work.\nSince each block has a maximum amount of gas, it also limits the amount\nof work needed to validate a block.\nThe gas price is a value set by the originator of the transaction, who\nhas to pay gas_price * gas up front to the EVM executor.\nIf some gas is left after execution, it is refunded to the transaction originator.\nIn case of an exception that reverts changes, already used up gas is not refunded.\nSince EVM executors can choose to include a transaction or not,\ntransaction senders cannot abuse the system by setting a low gas price.\n\nStorage, Transient Storage, Memory and the Stack\nThe Ethereum Virtual Machine has different areas where it can store data with the most\nprominent being storage, transient storage, memory and the stack.\nEach account has a data area called storage, which is persistent between function calls\nand transactions.\nStorage is a key-value store that maps 256-bit words to 256-bit words.\nIt is not possible to enumerate storage from within a contract, it is\ncomparatively costly to read, and even more to initialise and modify storage. Because of this cost,\nyou should minimize what you store in persistent storage to what the contract needs to run.\nStore data like derived calculations, caching, and aggregates outside of the contract.\nA contract can neither read nor write to any storage apart from its own.\nSimilar to storage, there is another data area called transient storage,\nwhere the main difference is that it is reset at the end of each transaction.\nThe values stored in this data location persist only across function calls originating\nfrom the first call of the transaction.\nWhen the transaction ends, the transient storage is reset and the values stored there\nbecome unavailable to calls in subsequent transactions.\nDespite this, the cost of reading and writing to transient storage is significantly lower than for storage.\nThe third data area is called memory, of which a contract obtains\na freshly cleared instance for each message call. Memory is linear and can be\naddressed at byte level, but reads are limited to a width of 256 bits, while writes\ncan be either 8 bits or 256 bits wide. Memory is expanded by a word (256-bit), when\naccessing (either reading or writing) a previously untouched memory word (i.e. any offset\nwithin a word). At the time of expansion, the cost in gas must be paid. Memory is more\ncostly the larger it grows (it scales quadratically).\nThe EVM is not a register machine but a stack machine, so all\ncomputations are performed on a data area called the stack. It has a maximum size of\n1024 elements and contains words of 256 bits. Access to the stack is\nlimited to the top end in the following way:\nIt is possible to copy one of\nthe topmost 16 elements to the top of the stack or swap the\ntopmost element with one of the 16 elements below it.\nAll other operations take the topmost two (or one, or more, depending on\nthe operation) elements from the stack and push the result onto the stack.\nOf course it is possible to move stack elements to storage or memory\nin order to get deeper access to the stack,\nbut it is not possible to just access arbitrary elements deeper in the stack\nwithout first removing the top of the stack.\n\nCalldata, Returndata and Code\nThere are also other data areas which are not as apparent as those discussed previously.\nHowever, they are routinely used during the execution of smart contract transactions.\nThe calldata region is the data sent to a transaction as part of a smart contract transaction.\nFor example, when creating a contract, calldata would be the constructor code of the new contract.\nThe parameters of external functions are always initially stored in calldata in an ABI-encoded form\nand only then decoded into the location specified in their declaration.\nIf declared as memory, the compiler will eagerly decode them into memory at the beginning of the function,\nwhile marking them as calldata means that this will be done lazily, only when accessed.\nValue types and storage pointers are decoded directly onto the stack.\nThe returndata is the way a smart contract can return a value after a call.\nIn general, external Solidity functions use the return keyword to ABI-encode values into the returndata area.\nThe code is the region where the EVM instructions of a smart contract are stored.\nCode is the bytes read, interpreted, and executed by the EVM during smart contract execution.\nInstruction data stored in the code is persistent as part of a contract account state field.\nImmutable and constant variables are stored in the code region.\nAll references to immutables are replaced with the values assigned to them.\nA similar process is performed for constants which have their expressions inlined\nin the places where they are referenced in the smart contract code.\n\nInstruction Set\nThe instruction set of the EVM is kept minimal in order to avoid\nincorrect or inconsistent implementations which could cause consensus problems.\nAll instructions operate on the basic data type, 256-bit words or on slices of memory\n(or other byte arrays).\nThe usual arithmetic, bit, logical and comparison operations are present.\nConditional and unconditional jumps are possible. Furthermore,\ncontracts can access relevant properties of the current block\nlike its number and timestamp.\nFor a complete list, please see the list of opcodes as part of the inline\nassembly documentation.\n\nMessage Calls\nContracts can call other contracts or send Ether to non-contract\naccounts by the means of message calls. Message calls are similar\nto transactions, in that they have a source, a target, data payload,\nEther, gas and return data. In fact, every transaction consists of\na top-level message call which in turn can create further message calls.\nA contract can decide how much of its remaining gas should be sent\nwith the inner message call and how much it wants to retain.\nIf an out-of-gas exception happens in the inner call (or any\nother exception), this will be signaled by an error value put onto the stack.\nIn this case, only the gas sent together with the call is used up.\nIn Solidity, the calling contract causes a manual exception by default in\nsuch situations, so that exceptions “bubble up” the call stack.\nAs already said, the called contract (which can be the same as the caller)\nwill receive a freshly cleared instance of memory and has access to the\ncall payload - which will be provided in a separate area called the calldata.\nAfter it has finished execution, it can return data which will be stored at\na location in the caller’s memory preallocated by the caller.\nAll such calls are fully synchronous.\nCalls are limited to a depth of 1024, which means that for more complex\noperations, loops should be preferred over recursive calls. Furthermore,\nonly 63/64th of the gas can be forwarded in a message call, which causes a\ndepth limit of a little less than 1000 in practice.\n\nDelegatecall and Libraries\nThere exists a special variant of a message call, named delegatecall\nwhich is identical to a message call apart from the fact that\nthe code at the target address is executed in the context (i.e. at the address) of the calling\ncontract and msg.sender and msg.value do not change their values.\nThis means that a contract can dynamically load code from a different\naddress at runtime. Storage, current address and balance still\nrefer to the calling contract, only the code is taken from the called address.\nThis makes it possible to implement the “library” feature in Solidity:\nReusable library code that can be applied to a contract’s storage, e.g. in\norder to implement a complex data structure.\n\nLogs\nIt is possible to store data in a specially indexed data structure\nthat maps all the way up to the block level. This feature called logs\nis used by Solidity in order to implement events.\nContracts cannot access log data after it has been created, but they\ncan be efficiently accessed from outside the blockchain.\nSince some part of the log data is stored in bloom filters, it is\npossible to search for this data in an efficient and cryptographically\nsecure way, so network peers that do not download the whole blockchain\n(so-called “light clients”) can still find these logs.\n\nCreate\nContracts can even create other contracts using a special opcode (i.e.\nthey do not simply call the zero address as a transaction would). The only difference between\nthese create calls and normal message calls is that the payload data is\nexecuted and the result stored as code and the caller / creator\nreceives the address of the new contract on the stack.\n\nDeactivate and Self-destruct\nThe only way to remove code from the blockchain is when a contract at that\naddress performs the selfdestruct operation. The remaining Ether stored\nat that address is sent to a designated target and then the storage and code\nis removed from the state. Removing the contract in theory sounds like a good\nidea, but it is potentially dangerous, as if someone sends Ether to removed\ncontracts, the Ether is forever lost.\n\nWarning\nFrom EVM >= Cancun onwards, selfdestruct will only send all Ether in the account to the given recipient and not destroy the contract.\nHowever, when selfdestruct is called in the same transaction that creates the contract calling it,\nthe behaviour of selfdestruct before Cancun hardfork (i.e., EVM <= Shanghai) is preserved and will destroy the current contract,\ndeleting any data, including storage keys, code and the account itself.\nSee EIP-6780 for more details.\nThe new behaviour is the result of a network-wide change that affects all contracts present on\nthe Ethereum mainnet and testnets.\nIt is important to note that this change is dependent on the EVM version of the chain on which\nthe contract is deployed.\nThe --evm-version setting used when compiling the contract has no bearing on it.\nAlso, note that the selfdestruct opcode has been deprecated in Solidity version 0.8.18,\nas recommended by EIP-6049.\nThe deprecation is still in effect and the compiler will still emit warnings on its use.\nAny use in newly deployed contracts is strongly discouraged even if the new behavior is taken into account.\nFuture changes to the EVM might further reduce the functionality of the opcode.\n\nWarning\nEven if a contract is removed by selfdestruct, it is still part of the\nhistory of the blockchain and probably retained by most Ethereum nodes.\nSo using selfdestruct is not the same as deleting data from a hard disk.\n\nNote\nEven if a contract’s code does not contain a call to selfdestruct,\nit can still perform that operation using delegatecall or callcode.\n\nIf you want to deactivate your contracts, you should instead disable them\nby changing some internal state which causes all functions to revert. This\nmakes it impossible to use the contract, as it returns Ether immediately.\n\nPrecompiled Contracts\nThere is a small set of contract addresses that are special:\nThe address range between 1 and (including) 0x0a contains\n“precompiled contracts” that can be called as any other contract\nbut their behavior (and their gas consumption) is not defined\nby EVM code stored at that address (they do not contain code)\nbut instead is implemented in the EVM execution environment itself.\nDifferent EVM-compatible chains might use a different set of\nprecompiled contracts. It might also be possible that new\nprecompiled contracts are added to the Ethereum main chain in the future,\nbut you can reasonably expect them to always be in the range between\n1 and 0xffff (inclusive).","tokens":7039,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264773094,"hash":"87dced090670b7fbaacdcd0753239a14fb98569c"}
{"url":"https://governance.aave.com/t/ignas-delegate-platform/19510","domain":"governance.aave.com","title":"Ignas Delegate Platform - Delegate Platforms - Aave","text":"Ignas Delegate Platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2024\n\n 1 / 197\n\n Oct 2024\n\n May 14\n\n post by Ignas on Oct 18, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 1. Basic Info\n\nName: Ignas\nDelegate Address: ignasdefi.eth | 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0\nX (Twitter): x.com\nTelegram: @ignasdefi\nWebsite: https://pinkbrains.io/\n\n2. Intro\nI’m Ignas, a solo researcher with the main focus on DeFi. My mission is to provide clear, in-depth insights helping my audiences stay up-to-date with the latest trends while actively supporting DAO development.\nI believe in the decentralized future and it means actively participating in Aave DAO in every way I can—whether it’s by serving as a delegate, joining working groups, discussing any proposals or seizing new opportunities that come up. I’ll also be sharing key DAO decisions on X and my blog.\n3. Delegate Communication Intent\nI’m committed to keeping the Aave community informed with regular, transparent updates. I’ll provide clear insights into my voting choices and reasoning to ensure everyone understands the direction we’re headed and why.\n4. Why I Want to be a Delegate\nCurrently, DeFi DAOs face several internal issues, such as voter apathy leading to governance attacks, insider voting, and voting concentration among a few active voting addresses. Additionally, they face external challenges like regulatory uncertainty.\nI believe in a decentralized future, even if it seems naive. However, the current state of crypto is plagued by misaligned incentives that prioritize short-term speculative gains over the core DeFi values of self-sovereignty and custody.\nEqually concerning is the trend of McKinsification in DAOs, where decisions are increasingly made by one or two professional consultant delegates. This discourages individual participation, as their opinions and votes have less impact.\nTo make DeFi DAOs viable, we must align incentives to encourage active participation in governance from the broader crypto community. I believe that community must be at the core of every DAO. Without giving the community a say in protocol governance, we’re no better than the Web2 companies we aim to replace—companies that view their “community” merely as users to extract value from.\nI will support initiatives that align token holders with the protocol, such as revenue sharing or other methods to bring value to the token. Token holders are frustrated with exploitative tokenomics that only benefit early insiders who acquired tokens at much lower prices, leaving no upside for new investors. Without incentives to buy and hold tokens, the attractiveness and health of DAOs decline.\nAs mentioned, I will highlight key votes and decisions of the DAO on X and my blog, as I believe the general public is often unaware of important actions being taken.\n5. Disclosure\nI am the co-founder of Pink Brains, an organization dedicated to promoting various crypto projects through educational content. You can find more info about us here: pinkbrains | Twitter | Linktree.\nI’m a delegate for Lido and Instadapp and will be soon a delegate in Arbitrum. Moreover, I’m actively involved in Uniswap, Optimism and here - Aave. I plan to apply as a delegate to other DAOs soon, with the same mission of strengthening them and aligning token holders with the protocol.\nI always make appropriate disclosures and recuse myself from voting when necessary.\n6. Delegation\nIf anyone would like to delegate to me, please use the following address: 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0\n\n read \n\n 54\n min\n\n post by Ignas on Oct 22, 2024\n\n Ignas\n\n Orbit-Delegate\n\nProposal: [ARFC] BGD. Aave v3.2: liquid eModes (Snapshot)\n\nDate Voted: September 23, 2024\nVote: YAE\nRationale: I support activating this new release because it allows us to adjust settings for improved market management.\n\n post by Ignas on Oct 22, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 2. Proposal:[ARFC] Superlend Profit Share Proposal, Deploying a Friendly Fork of Aave V3 on Etherlink (Stage 2 EVM Rollup) and Arbitrum (Snapshot)\n3. Proposal: [TEMP CHECK] Add support for Wrapped OETH (wOETH) to Aave v3 (Snapshot)\n- Date Voted: September 25, 2024\n- Vote: YAE (Yes)\n\n post by Ignas on Oct 22, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 4. Proposal: [ARFC] GHO Steward v2 Upgrade (Snapshot)\n\nDate voted: September 26, 2024\nVote: YAE (Yes)\n\n post by Ignas on Oct 22, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 4. Proposal: [ARFC] Chaos Labs <> Aave Risk Management Service Renewal (Snapshot)\n- Date Voted: October 15, 2024\n- Vote: Abstain\n\n post by Ignas on Oct 22, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: October 17, 2024\n5. Proposal: [ARFC] Launch GHO on Base & set ACI as Emissions Manager for rewards (Snapshot)\n- Vote: YAE (Yes)\n6. Proposal: [ARFC] Launch GHO on Avalanche & set ACI as Emissions Manager for rewards (Snapshot)\n- Vote: YAE (Yes)\n7. Proposal: [TEMP CHECK] Add rlUSD to Aave v3 Main Market on Ethereum (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: I agree with ACI on this proposal (7). Integrating RLUSD could help us attract more users to the platform. With Ripple’s focus on compliance and cross-border payments, we can position Aave as a trusted option for a broader audience\n\n post by Ignas on Oct 22, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: October 21, 2024\n8. Proposal: Update legacy guardian (On-chain)\n- Vote: For\n9. Proposal: Renew LlamaRisk as Risk Service Provider (On-chain)\n- Vote: For\n- Rationale: I vote For this proposal because I believe LlamaRisk has done a great job so far. And I believe that the Aave DAO will continue to benefit from this contribution.\n10. Proposal: Reserve Factor Updates Mid October (On-chain)\n- Vote: For\n- Rationale: Couldn’t agree more on this update proposal. It will help Aave grow the treasury while also encouraging users to migrate to the more efficient v3\n11. Proposal: Chaos Labs <> Aave Risk Management Service Renewal (On-chain)\n- Vote: For\n12. Proposal: wstETH Slope1 & Uoptimal Update (On-chain)\n- Vote: For\n\n post by Ignas on Oct 24, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 13. Proposal: Aave <> Certora Continuous Security Services (On-chain)\n- Date Voted: October 23, 2024\n- Vote: For\n- Rationale: I’m glad to see Certora continuing their work with Aave. Their efforts to stop security issues and outside attacks are really important for keeping the DAO safe and stable. I also support the $1.7M budget, especially since they’re adding the new Safeguard feature to catch suspicious transactions.\n\n post by Ignas on Oct 24, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: October 24, 2024\n14. Proposal: [ARFC] Aave <> BGD Labs. Phase 4 (Snapshot)\n- Vote: For\n- Rationale: I voted FOR in this proposal. BGD has proven their ability to keep Aave stable and reliable over the past 2.5 years. Moreover, the plan to expand Aave onto new blockchain networks makes a lot of sense, I think it’s a smart move to help Aave grow and connect with even more users.\n15. Proposal: Onboard ezETH to Lido Instance (On-chain)\n- Vote: For\n\n post by Ignas on Oct 29, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date voted: October 28, 2024\n16. Proposal: [ARFC] Dolce Vita Extension (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: I support expanding the Dolce Vita service! Big thanks to ACI for being so active on Snapshot and Discourse. I believe their management will keep things on track, minimize disruptions, and strengthen trust within the DAO.\n17. Proposal: [ARFC] Launch aUSDC GSM on Ethereum (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: I voted Yes on this proposal. No point in keeping USDC, just sitting there in the recent module without earning anything :). Switching to aUSDC means DAO funds can actually work for us—earning passive income while backing GHO.\n18. Proposal: Fix USDS Borrow Rate to Match Sky Savings Rate (On-chain)\n- Vote: For\n- Rationale: I’m all for reducing the slope 1 to 0.75%! It’s a smart move if this helps bring more users to borrow on Aave.\n\n post by Ignas on Oct 31, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 19. Proposal: Aave BGD Phase 4 (On-chain)\n- Date Voted: October 29, 2024\n- Vote: For\n- Rationale: Same reason with proposal 14 on Snapshot. BGD has proven their ability to keep Aave stable and reliable over the past 2.5 years\n\n post by Ignas on Oct 31, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: October 30, 2024\n20. Proposal: [TEMP CHECK] Onboard SCR to Aave V3 Scroll Instance (Snapshot)\n- Vote: Abstain\n- Rationale: I’m going with abstain on this one. I think we need a clearer picture of the long-term impact of onboarding SCR, though the potential looks promising :) I’ll keep an eye on the DAO’s insights and feedback before making any firm decision.\n21. Proposal: [TEMP CHECK] Onboard AUSD to Aave V3 (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: I voted Yes for 2 main reasons: it boosts liquidity for Aave and expands the stablecoin options beyond USDT and USDC. This will enhance trust in Aave V3\n22. Proposal: [ARFC]. Aave Generalized Risk Stewards (AGRS) activation (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: I voted Yes because I believe this will enhance risk management for Aave through AGRS\n\n post by Ignas on Nov 4, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date voted: November 4, 2024\n23. Proposal: stkGHO Incentives (On-chain)\n- Vote: For\n- Rationale: I support this proposal because it helps keep GHO more stable in the market and benefits everyone using it. Also, the budget is fair, and covering past missed rewards shows Aave values their community.\n24. Proposal: Onboard wstETH to Aave V3 on BNB Chain (On-chain)\n- Vote: For\n- Rationale: Excited to see this proposal moving forward. I think expanding Aave to ecosystems like BNB Chain is a smart move since it can help attract more users from there and give them better options to earn on their assets.\n25. Proposal: GHO Steward v2 Upgrade (On-chain)\n- Vote: For\n- Rationale: I voted yes in the snapshot vote and I’m excited to see this on-chain! Of course upgrading the GHO Steward role is definitely a smart move to simplify things and make it easier to adapt and grow the Aave in the future.\n\n post by Ignas on Nov 6, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 26. Proposal: [TEMP CHECK] Deploy GHO Facilitator (Snapshot)\n- Date Voted: November 6, 2024\n- Vote: YAE (Yes)\n- Rationale: Just voted yes! When adding more GHO liquidity will make borrowing and lending easier on Aave, bringing in more users to the platform \n\n post by Ignas on Nov 12, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: November 8, 2024\n27. Proposal: [ARFC] Framework for Instances and Friendly Forks (Snapshot)\n- Vote: YAE (Yes)\n28. Proposal: Aave Generalized Risk Stewards (AGRS) activation (On-chain)\n- Vote: For\n- Rationale: Same reason with Snapshot vote, I support because I believe AGRS will enhance risk management for Aave.\n29. Proposal: [TEMP CHECK] Add FBTC to Aave v3 Main Instance on Ethereum (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: Voted yes. Adding FBTC to Aave is a great move to bring Bitcoin holders into Aave’s DeFi ecosystem. I think it’s a good opportunity for Aave to expand beyond Ethereum users and tap into the Bitcoin community as well \n\n post by Ignas on Nov 12, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: November 11, 2024\n30. Proposal: GHO CCIP Integration Maintenance (CCIP v1.5 upgrade) (On-chain)\n- Vote: For\n- Rationale: I voted yes because this is an important step to keep GHO working well on different blockchains as Chainlink upgrades\n31. Proposal: [TEMP CHECK] Aave Instances Strategy Shift (Snapshot)\n- Vote: YAE (Yes)\n- Rationale: No reason to block this proposal. Merging instances and refining the strategy will help Aave manage assets more efficiently and reduce risks.\n\n post by Ignas on Nov 14, 2024\n\n Ignas\n\n Orbit-Delegate\n\n Date Voted: November 13, 2024\n32. Proposal: [TEMP CHECK] Add PAXG to Aave v3 Main Instance on Ethereum (Snapshot)\n\nVote: YAE (Yes)\nRationale: I’m all for this proposal. Because adding PAXG isn’t just about giving users more collateral options, it also boosts liquidity and brings in fresh users from the web2 market.\n\n33. Proposal: Safety Module stkAAVE - Re-enable Rewards (On-chain)\n\nVote: For\nRationale: I think this will keep stkAAVE rewards steady, encouraging users to stay engaged and helping maintain stability.\n\n34. Proposal: PYUSD Reserve Configuration Update & Incentive Campaign (On-chain)\n\nVote: For\nRationale: Same reason with Snapshot vote. Bringing PYUSD onto Aave is a solid way to attract users and boost Aave TVL.\n\n35. Proposal: Automated (Edge) AGRS Activation (On-chain)\n\nVote: For\nRationale: I vote in favor because I believe AGRS on the Aave Ethereum Lido will help Aave adjust interest rates quickly and effectively based on real-time market conditions.\n\n post by Ignas on Nov 15, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 36. Proposal: wstETH Reserve Borrow Rate Update - Main Instance (On-chain)\n\nDate Voted: November 14, 2024\n\nVote: For\n\nRationale: Vote for. Lowering the borrow rate for wstETH will make borrowing more attractive and likely boost overall loan volume on Aave.\n\n post by Ignas on Nov 18, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 37. Proposal: Onboard and Enable sUSDe liquid E-Mode on Aave v3 Mainnet and Lido Instances (On-chain)\n\nDate Voted: November 15, 2024\nVote: For\nRationale: Go for this proposal. It’ll let users borrow with better capital efficiency using stablecoin collateral, bringing more revenue for Aave and boosting liquidity as user will bring more sUSDe to the platform.\n\n post by Ignas on Nov 19, 2024\n\n Ignas\n\n Orbit-Delegate\n\n 38. Proposal: Onboard rsETH to Aave V3 Ethereum (On-chain)\n\nDate Voted: November 18, 2024\nVote: For\nRationale: I voted yes because this will help expand the range of assets available for lending and borrowing on Aave as well as bringing more diversity to the platform’s transactions\n\n Load more posts below","tokens":3444,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264774536,"hash":"6556dc0c699f35fe24ec082c85c71bac4ff8bb1e"}
{"url":"https://ethereum.org/developers/docs/development-networks/","domain":"ethereum.org","title":"Development Networks | ethereum.org","text":"Development NetworksEdit page (opens in a new tab)When building an Ethereum application with smart contracts, you'll want to run it on a local network to see how it works before deploying it.\nSimilar to how you might run a local server on your computer for web development, you can use a development network to create a local blockchain instance to test your dapp. These Ethereum development networks provide features that allow for much faster iteration than a public testnet (for instance you don’t need to deal with acquiring ETH from a testnet faucet).\nPrerequisites\nYou should understand the basics of the Ethereum stack and Ethereum networks before diving into development networks.\nWhat is a development network?\nDevelopment networks are essentially Ethereum clients (implementations of Ethereum) designed specifically for local development.\nWhy not just run a standard Ethereum node locally?\nYou could run a node but since development networks are purpose-built for development, they often come packed with convenient features like:\n\nDeterministically seeding your local blockchain with data (e.g., accounts with ETH balances)\nInstantly producing blocks with each transaction it receives, in order and with no delay\nEnhanced debugging and logging functionality\n\nAvailable tools\nNote: Most development frameworks include a built-in development network. We recommend starting with a framework to set up your local development environment.\nHardhat Network\nA local Ethereum network designed for development. It allows you to deploy your contracts, run your tests and debug your code.\nHardhat Network comes built-in with Hardhat, an Ethereum development environment for professionals.\n\nWebsite (opens in a new tab)\nGitHub (opens in a new tab)\n\nLocal Beacon Chains\nSome consensus clients have built-in tools for spinning up local beacon chains for testing purposes. Instructions for Lighthouse, Nimbus and Lodestar are available:\n\nLocal testnet using Lodestar (opens in a new tab)\nLocal testnet using Lighthouse (opens in a new tab)\n\nPublic Ethereum Test-chains\nThere are also two maintained public test implementations of Ethereum: Sepolia and Hoodi. The recommended testnet with long-term support is Hoodi, which anyone is free to validate on. Sepolia uses a permissioned validator set, meaning there is no general access to new validators on this testnet.\n\nHoodi Staking Launchpad (opens in a new tab)\n\nKurtosis Ethereum Package\nKurtosis is a build system for multi-container test environments which enables developers to locally spin up reproducible instances of blockchain networks.\nThe Ethereum Kurtosis package can be used to quickly instantiate a parameterizable, highly scalable, and private Ethereum testnet over Docker or Kubernetes. The package supports all major Execution Layer (EL) and Consensus Layer (CL) clients. Kurtosis gracefully handles all local port mappings and service connections for a representative network to be used in validation and testing workflows relating to Ethereum core infrastructure.\n\nEthereum network package (opens in a new tab)\nWebsite (opens in a new tab)\nGitHub (opens in a new tab)\nDocumentation (opens in a new tab)\n\nFurther reading\nKnow of a community resource that helped you? Edit this page and add it!\nRelated topics\n\nDevelopment frameworks\nSet up a local development environment\n\nTutorials: Development networks & testing environments on Ethereum\n\nDevelop and test dApps with a multi-client local Ethereum testnet – How to spin up a local multi-client Ethereum testnet with Kurtosis for dApp development and testing.","tokens":893,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264775418,"hash":"ceb2856423c7d503ce2e0c0407d3f58760889f10"}
{"url":"https://docs.soliditylang.org/en/develop/installing-solidity.html","domain":"docs.soliditylang.org","title":"Installing the Solidity Compiler — Solidity 0.8.38-develop documentation","text":"Installing the Solidity Compiler\n\n Edit on GitHub\n\nInstalling the Solidity Compiler\n\nVersioning\nSolidity versions follow Semantic Versioning. In\naddition, patch-level releases with major release 0 (i.e. 0.x.y) will not\ncontain breaking changes. That means code that compiles with version 0.x.y\ncan be expected to compile with 0.x.z where z > y.\nIn addition to releases, we provide prereleases and nightly development builds to make it\neasy for developers to try out upcoming features and provide early feedback.\nNote that such builds contain bleeding-edge code from the development branch and are not guaranteed\nto be of the same quality as full releases.\nDespite our best efforts, they might contain undocumented and/or broken changes that will not\nbecome a part of an actual release. They are not meant for production use.\nWhen deploying contracts, you should use the latest released version of Solidity. This\nis because breaking changes, as well as new features and bug fixes are introduced regularly.\nWe currently use a 0.x version number to indicate this fast pace of change.\n\nRemix\nWe recommend Remix for small contracts and for quickly learning Solidity.\nAccess Remix online, you do not need to install anything.\nIf you want to use it without connection to the Internet, download Remix Desktop from the releases page.\nRemix is also a convenient option for testing nightly builds\nwithout installing multiple Solidity versions.\nFurther options on this page detail installing command-line Solidity compiler software\non your computer. Choose a command-line compiler if you are working on a larger contract\nor if you require more compilation options.\n\nnpm / Node.js\nUse npm for a convenient and portable way to install solcjs, a Solidity compiler. The\nsolcjs program has fewer features than the ways to access the compiler described\nfurther down this page. The\nUsing the Commandline Compiler documentation assumes you are using\nthe full-featured compiler, solc. The usage of solcjs is documented inside its own\nrepository.\nNote: The solc-js project is derived from the C++\nsolc by using Emscripten, which means that both use the same compiler source code.\nsolc-js can be used in JavaScript projects directly (such as Remix).\nPlease refer to the solc-js repository for instructions.\nnpm install --global solc\n\nNote\nThe command-line executable is named solcjs.\nThe command-line options of solcjs are not compatible with solc and tools (such as geth)\nexpecting the behavior of solc will not work with solcjs.\n\nDocker\nDocker images of Solidity builds are available using the solc image from the argotorg organization on ghcr.io.\nUse the stable tag for the latest released version, and nightly for potentially unstable changes in the develop branch.\nThe Docker image runs the compiler executable so that you can pass all compiler arguments to it.\nFor example, the command below pulls the stable version of the solc image (if you do not have it already),\nand runs it in a new container, passing the --help argument.\ndocker run ghcr.io/argotorg/solc:stable --help\n\nNote\nSpecific compiler versions are supported as the Docker image tag such as ghcr.io/argotorg/solc:0.8.23.\nWe will be passing the stable tag here instead of specific version tag to ensure that users get\nthe latest version by default and avoid the issue of an out-of-date version.\n\nTo use the Docker image to compile Solidity files on the host machine, mount a\nlocal folder for input and output, and specify the contract to compile. For example:\ndocker run \\\n --volume \"/tmp/some/local/path/:/sources/\" \\\n ghcr.io/argotorg/solc:stable \\\n /sources/Contract.sol \\\n --abi \\\n --bin \\\n --output-dir /sources/output/\n\nYou can also use the standard JSON interface (which is recommended when using the compiler with tooling).\nWhen using this interface, it is not necessary to mount any directories as long as the JSON input is\nself-contained (i.e. it does not refer to any external files that would have to be\nloaded by the import callback).\ndocker run ghcr.io/argotorg/solc:stable --standard-json < input.json > output.json\n\nLinux Packages\nWe provide standalone binaries of the compiler that should run on most\ndistributions without any additional installation steps.\nUbuntu packages for versions up to 0.8.30 are available in the\nethereum/ethereum PPA.\nHowever, we have discontinued this distribution method and future versions will not be added there.\nSome Linux distributions provide their own packages.\nThese packages are not directly maintained by us but usually kept up-to-date by the respective\npackage maintainers.\nUnofficial, community-maintained scripts for building and installing the compiler are also\navailable for some distributions:\n\nArch Linux / (AUR):\n\nsolidity (builds from source),\nsolidity-bin (uses our standalone binaries).\n\nNix:\n\nsolc.nix (builds from source).\n\nNote\nPlease be aware that these scripts are produced and maintained by users and not vetted in any\nway by the distro maintainers.\nExercise caution when using them.\n\nThere is also a snap package, however, it is currently unmaintained.\nIt is installable in all the supported Linux distros. To\ninstall the latest stable version of solc:\nsudo snap install solc\n\nIf you want to help testing the latest development version of Solidity\nwith the most recent changes, please use the following:\nsudo snap install solc --edge\n\nNote\nThe solc snap uses strict confinement. This is the most secure mode for snap packages\nbut it comes with limitations, like accessing only the files in your /home and /media directories.\nFor more information, go to Demystifying Snap Confinement.\n\nmacOS Packages\nWe distribute the Solidity compiler through Homebrew\nas a build-from-source version. Pre-built bottles are\ncurrently not supported.\nbrew update\nbrew upgrade\nbrew tap ethereum/ethereum\nbrew install solidity\n\nTo install the most recent 0.4.x / 0.5.x version of Solidity you can also use brew install solidity@4\nand brew install solidity@5, respectively.\nIf you need a specific version of Solidity you can install a\nHomebrew formula directly from Github.\nView\nsolidity.rb commits on GitHub.\nCopy the commit hash of the version you want and check it out on your machine.\ngit clone https://github.com/ethereum/homebrew-ethereum.git\ncd homebrew-ethereum\ngit checkout <your-hash-goes-here>\n\nInstall it using brew:\nbrew unlink solidity\n# eg. Install 0.4.8\nbrew install solidity.rb\n\nStatic Binaries\nWe maintain a repository containing static builds of past and current compiler versions for all\nsupported platforms at solc-bin. This is also the location where you can find the nightly builds.\nThe repository is not only a quick and easy way for end users to get binaries ready to be used\nout-of-the-box but it is also meant to be friendly to third-party tools:\n\nThe content is mirrored to https://binaries.soliditylang.org where it can be easily downloaded over\nHTTPS without any authentication, rate limiting or the need to use git.\nContent is served with correct Content-Type headers and lenient CORS configuration so that it\ncan be directly loaded by tools running in the browser.\nBinaries do not require installation or unpacking (exception for older Windows builds\nbundled with necessary DLLs).\nWe strive for a high level of backward-compatibility. Files, once added, are not removed or moved\nwithout providing a symlink/redirect at the old location. They are also never modified\nin place and should always match the original checksum. The only exception would be broken or\nunusable files with the potential to cause more harm than good if left as is.\nFiles are served over both HTTP and HTTPS. As long as you obtain the file list in a secure way\n(via git, HTTPS, IPFS or just have it cached locally) and verify hashes of the binaries\nafter downloading them, you do not have to use HTTPS for the binaries themselves.\n\nThe same binaries are in most cases available on the Solidity release page on GitHub. The\ndifference is that we do not generally update old releases on the GitHub release page. This means\nthat we do not rename them if the naming convention changes and we do not add builds for platforms\nthat were not supported at the time of release. This only happens in solc-bin.\nThe solc-bin repository contains several top-level directories, each representing a single platform.\nEach one includes a list.json file listing the available binaries. For example in\nemscripten-wasm32/list.json you will find the following information about version 0.7.4:\n{\n \"path\": \"solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js\",\n \"version\": \"0.7.4\",\n \"build\": \"commit.3f05b770\",\n \"longVersion\": \"0.7.4+commit.3f05b770\",\n \"keccak256\": \"0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3\",\n \"sha256\": \"0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2\",\n \"urls\": [\n \"dweb:/ipfs/QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS\"\n ]\n}\n\nThis means that:\n\nYou can find the binary in the same directory under the name\nsolc-emscripten-wasm32-v0.7.4+commit.3f05b770.js.\nNote that the file might be a symlink, and you will need to resolve it yourself if you are not using\ngit to download it or your file system does not support symlinks.\nThe binary is also mirrored at https://binaries.soliditylang.org/emscripten-wasm32/solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js.\nIn this case git is not necessary and symlinks are resolved transparently, either by serving a copy\nof the file or returning a HTTP redirect.\nThe file is also available on IPFS at QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS.\nPlease, be aware that the order of items in the urls array is not predetermined or guaranteed and users should not rely on it.\nYou can verify the integrity of the binary by comparing its keccak256 hash to\n0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3. The hash can be computed\non the command-line using keccak256sum utility provided by sha3sum or keccak256() function\nfrom ethereumjs-util in JavaScript.\nYou can also verify the integrity of the binary by comparing its sha256 hash to\n0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2.\n\nWarning\nDue to the strong backwards compatibility requirement the repository contains some legacy elements\nbut you should avoid using them when writing new tools:\n\nUse emscripten-wasm32/ (with a fallback to emscripten-asmjs/) instead of bin/ if\nyou want the best performance. Until version 0.6.1 we only provided asm.js binaries.\nStarting with 0.6.2 we switched to WebAssembly builds with much better performance. We have\nrebuilt the older versions for wasm but the original asm.js files remain in bin/.\nThe new ones had to be placed in a separate directory to avoid name clashes.\nUse emscripten-asmjs/ and emscripten-wasm32/ instead of bin/ and wasm/ directories\nif you want to be sure whether you are downloading a wasm or an asm.js binary.\nUse list.json instead of list.js and list.txt. The JSON list format contains all\nthe information from the old ones and more.\n\nWarning\n\nThe solc-bin.ethereum.org domain is no longer supported. Going forward,\nwe recommend any tools which are still using it as the source of Solidity binaries\nto switch to binaries.soliditylang.org.\n\nWarning\nThe binaries are also available at https://argotorg.github.io/solc-bin/ but this page\nstopped being updated just after the release of version 0.7.2, will not receive any new releases\nor nightly builds for any platform and does not serve the new directory structure, including\nnon-emscripten builds.\nIf you are using it, please switch to https://binaries.soliditylang.org, which is a drop-in\nreplacement. This allows us to make changes to the underlying hosting in a transparent way and\nminimize disruption. Unlike the argotorg.github.io domain, which we do not have any control\nover, binaries.soliditylang.org is guaranteed to work and maintain the same URL structure\nin the long-term.\n\nBuilding from Source\n\nPrerequisites - All Operating Systems\nThe following are dependencies for all builds of Solidity:\n\nSoftware\nNotes\n\nCMake (version 3.21.3+)\nCross-platform build file generator.\n\nBoost (version 1.83+)\nC++ libraries.\n\nGit\nCommand-line tool for retrieving source code.\n\nz3 (version 4.8.16+, Optional)\nFor use with SMT checker.\n\nNote\nSolidity versions prior to 0.5.10 can fail to correctly link against Boost versions 1.70+.\nA possible workaround is to temporarily rename <Boost install path>/lib/cmake/Boost-1.70.0\nprior to running the cmake command to configure Solidity.\nStarting from 0.5.10 linking against Boost 1.70+ should work without manual intervention.\n\nNote\nThe default build configuration requires a specific Z3 version (the latest one at the time the\ncode was last updated). Changes introduced between Z3 releases often result in slightly different\n(but still valid) results being returned. Our SMT tests do not account for these differences and\nwill likely fail with a different version than the one they were written for. This does not mean\nthat a build using a different version is faulty. If you pass -DSTRICT_Z3_VERSION=OFF option\nto CMake, you can build with any version that satisfies the requirement given in the table above.\nIf you do this, however, please remember to pass the --no-smt option to scripts/tests.sh\nto skip the SMT tests.\n\nNote\nBy default the build is performed in pedantic mode, which enables extra warnings and tells the\ncompiler to treat all warnings as errors.\nThis forces developers to fix warnings as they arise, so they do not accumulate “to be fixed later”.\nIf you are only interested in creating a release build and do not intend to modify the source code\nto deal with such warnings, you can pass -DPEDANTIC=OFF option to CMake to disable this mode.\nDoing this is not recommended for general use but may be necessary when using a toolchain we are\nnot testing with or trying to build an older version with newer tools.\nIf you encounter such warnings, please consider\nreporting them.\n\nMinimum Compiler Versions\nThe following C++ compilers and their minimum versions can build the Solidity codebase:\n\nGCC, version 13.3+\nClang, version 18.1.3+\nMSVC, version 2022+\n\nPrerequisites - macOS\nFor macOS builds, ensure that you have the latest version of\nXcode installed.\nThis contains the Clang C++ compiler, the\nXcode IDE and other Apple development\ntools that are required for building C++ applications on OS X.\nIf you are installing Xcode for the first time, or have just installed a new\nversion then you will need to agree to the license before you can do\ncommand-line builds:\nsudo xcodebuild -license accept\n\nOur OS X build script uses the Homebrew\npackage manager for installing external dependencies.\nHere’s how to uninstall Homebrew,\nif you ever want to start again from scratch.\n\nPrerequisites - Windows\nYou need to install the following dependencies for Windows builds of Solidity:\n\nSoftware\nNotes\n\nVisual Studio 2022 Build Tools\nC++ compiler\n\nVisual Studio 2022 (Optional)\nC++ compiler and dev environment.\n\nBoost (version 1.77+)\nC++ libraries.\n\nIf you already have one IDE and only need the compiler and libraries,\nyou could install Visual Studio 2022 Build Tools.\nVisual Studio 2022 provides both IDE and necessary compiler and libraries.\nSo if you have not got an IDE and prefer to develop Solidity, Visual Studio 2022\nmay be a choice for you to get everything setup easily.\nHere is the list of components that should be installed\nin Visual Studio 2022 Build Tools or Visual Studio 2022:\n\nVisual Studio C++ core features\nVC++ 2022 v143 toolset (x86,x64)\nWindows Universal CRT SDK\nWindows 10 or 11 SDK\nC++/CLI support\n\nWe have a helper script which you can use to install all required external dependencies:\nscripts\\install_deps.ps1\n\nThis will install boost and cmake to the deps subdirectory.\n\nClone the Repository\nTo clone the source code, execute the following command:\ngit clone --recursive https://github.com/argotorg/solidity.git\ncd solidity\n\nIf you want to help develop Solidity,\nyou should fork Solidity and add your personal fork as a second remote:\ngit remote add personal git@github.com:[username]/solidity.git\n\nNote\nThis method will result in a pre-release build leading to e.g. a flag\nbeing set in each bytecode produced by such a compiler.\nIf you want to re-build a released Solidity compiler, then\nplease use the source tarball on the GitHub release page:\nhttps://github.com/argotorg/solidity/releases/download/v0.X.Y/solidity_0.X.Y.tar.gz\n(not the “Source code” provided by GitHub).\n\nCommand-Line Build\nBe sure to install External Dependencies (see above) before build.\nSolidity project uses CMake to configure the build.\nYou might want to install ccache to speed up repeated builds.\nCMake will pick it up automatically.\nBuilding Solidity is quite similar on Linux, macOS and other Unices:\nmkdir build\ncd build\ncmake .. && make\n\nor even easier on Linux and macOS, you can run:\n#note: this will install binaries solc and soltest at usr/local/bin\n./scripts/build.sh\n\nWarning\nBSD builds should work, but are untested by the Solidity team.\n\nAnd for Windows:\nmkdir build\ncd build\ncmake -G \"Visual Studio 17 2022\" ..\n\nIn case you want to use the version of boost installed by scripts\\install_deps.ps1, you will\nadditionally need to pass -DBoost_ROOT=\"deps/boost\" -DBoost_INCLUDE_DIR=\"deps/boost/include\" and -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded\nas arguments to the call to cmake.\nThis should result in the creation of solidity.sln in that build directory.\nDouble-clicking on that file should result in Visual Studio firing up. We suggest building\nRelease configuration, but all others work.\nAlternatively, you can build for Windows on the command-line, like so:\ncmake --build . --config Release\n\nCMake Options\nIf you are interested what CMake options are available run cmake .. -LH.\n\nSMT Solvers\nSolidity can optionally use SMT solvers, namely z3, cvc5 and Eldarica,\nbut their presence is checked only at runtime, they are not needed for the build to succeed.\n\nNote\nThe emscripten builds require Z3 and will statically link against it instead.\n\nThe Version String in Detail\nThe Solidity version string contains four parts:\n\nthe version number\npre-release tag, usually set to develop.YYYY.MM.DD, pre.N or nightly.YYYY.MM.DD\ncommit in the format of commit.GITHASH\nplatform, which has an arbitrary number of items, containing details about the platform and compiler\n\nIf there are local modifications, the commit will be postfixed with .mod.\nThese parts are combined as required by SemVer, where the Solidity pre-release tag equals to the SemVer pre-release\nand the Solidity commit and platform combined make up the SemVer build metadata.\nExamples:\n\nrelease: 0.4.8+commit.60cc1668.Emscripten.clang\npre-release: 0.4.9-pre.3+commit.fb60450bc.Emscripten.clang\nnightly build: 0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang\n\nImportant Information About Versioning\nAfter a release is made, the patch version level is bumped, because we assume that only\npatch level changes follow. When changes are merged, the version should be bumped according\nto SemVer and the severity of the change. Finally, a release is always made with the version\nof the current build, but without the prerelease specifier.\nExample:\n\nThe 0.4.0 release is made.\nNightly builds and preerelases have a version of 0.4.1 from now on.\nNon-breaking changes are introduced –> no change in version.\nA breaking change is introduced –> version is bumped to 0.5.0.\nThe 0.5.0 release is made.\n\nThis behavior works well with the version pragma.","tokens":4868,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264783087,"hash":"64f92772a130fb796fd66be5341b5a56b19fb727"}
{"url":"https://governance.aave.com/t/technical-maintenance-proposals/15274","domain":"governance.aave.com","title":"Technical maintenance proposals - Development - Aave","text":"Technical maintenance proposals \n\n Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n TL;DR\n\n Context\n\n Which proposals belong here?\n\n How will proposals be presented?\n\n Next steps\n\n Oct 2023\n\n 1 / 133\n\n Oct 2023\n\n Aug 6\n\n post by bgdlabs on Oct 30, 2023\n\n bgdlabs\n\n Leader\n\n TL;DR\nA unified forum thread for the community to have better visibility on technical maintenance updates coming from BGD.\n\nContext\nWith Aave instances in multiple versions (v1, v2, v3) and networks, periodically it is necessary to do maintenance tasks related to infrastructure consistency.\nIn the past, this has been done in ad-hoc governance posts within other forum threads (e.g. HERE), explaining the rationale of each change. But we believe it is more convenient to have a dedicated thread like this, oriented to these maintenance tasks.\nHistorically, whenever some of these maintenance tasks are minor or routinary, we have proceeded directly to the AIP stage, given that the Snapshot step doesn’t really give value. Examples of this are the following:\n\nThe activation of the price oracle sentinel on Aave v3 Optimism. This is a mechanism part of Aave v3 itself, fully approved by the community. So the activation didn’t require any extra approval, apart from the always necessary on-chain AIP.\nFactually disable the already deprecated fallback oracles. In order to keep consistency with v3, set the addresses of all fallback oracles to address(0). This is also a purely technical change, to reduce differences between Aave instances.\n\nEven if we believe this has been acceptable, the visibility for the community has not been ideal in our opinion.\n\nWhich proposals belong here?\nOnly proposals that don’t create any kind of community division or are purely technical maintenance will be included in this thread. Examples of these are:\n\nUpdating addresses of price feeds if Chainlink recommends so, due to deprecation or optimisation of those in production.\nOracle changes required due to the off-boarding of assets. In some cases, assets are deprecated or migrated by their community, and this implies changes in the feeds pricing them.\nPurely consistency-oriented updates, like the aforementioned proposal to unify fallback oracles to address(0)\n\nHow will proposals be presented?\nFor every maintenance update, we will create a separate post containing the same structure as the AIP description, which always shows both a high-level overview of what the proposal does and its technical specifications.\nAn example of this description can be found HERE.\n\nRegarding timing, in order for the community to have time to comment on it, we always leave the proposal 3 days on this forum before creating the AIP.\nEven if we will only submit in this thread purely operational updates, if the community has any concerns about one of them, we will revert back to the more strict ARFC + AIP procedure.\n\nNext steps\nAs this is a continuous task, the following step will be the creation of the first maintenance update, which we will describe in its specific post.\n\n BGD. Aave <> Bored Ghosts Phase 2 Recap\n\n Aave Governance Process Document v1\n\n Governance Weekly Recap [2024]\n\n Chaos Labs - Monthly Community Update\n\n V4 Technical Maintenance Updates\n\n 113\n\n 10\n\n 3\n\n read \n\n 50\n min\n\n post by bgdlabs on Oct 31, 2023\n\n bgdlabs\n\n Leader\n\n Deprecate REP/ETH price feed on Aave v1\nSummary\nReplace the existing REP/ETH price feed by Chainlink on Aave v1 Ethereum with a fixed price adapter.\nMotivation\nThe REP asset listed on Aave 1 Ethereum is a legacy one, that long time ago has suffered a token migration.\nWith a total supply of this legacy REP on Aave v1 of less than $100, Chainlink is looking to shut down the REP/ETH price feed, but this can only be done if Aave stops using it.\nConsequently, given the size of the asset and that factually is off-boarded (frozen), we propose to replace the Chainlink price feed with an ad-hoc one that will return a constant value: the average price of the token for the period from 01/09/2023 till 31/10/2023.\nSpecification\nAverage REP price to use: 0.0004625695693 ETH\nActions:\n\ncall IAaveOracle(AAVE_V1_ORACLE).setAssetSources([0x1985365e9f78359a9B6AD760e32412f4a445E862], [0xc7751400F809cdB0C167F87985083C558a0610F7]) to replace the price feed of the REP on the Aave v1 Ethereum Pool.\n\n Kpk Delegate Platform\n\n post by bgdlabs on Nov 2, 2023\n\n bgdlabs\n\n Leader\n\n Activate FreezingSteward on v3 missing networks\nSummary\nActivates the FreezingSteward smart contract across all the networks of the protocol, which allows the emergency admin to freeze reserves, as expected.\nCurrently, there are freezing stewards live for all the networks except Avalanche, Metis, and Base, and this proposal synchronizes the missing ones.\nMotivation\nThis is a follow-up to AIP-319 where on some networks (Avalanche, Metis, and Base) the proposal wasn’t executed. We now resubmit the proposal as an operational update to maintain security and consistency across Aave V3.\nSpecification\nAdds the FreezingSteward contract as RISK_ADMIN on the canonical Aave V3 deployments on the following networks:\n\nAvalanche.\nMetis.\nBase.\n\nThe FreezingSteward is identical to the one currently deployed on Ethereum, Polygon, Optimism, Arbitrum and only allows for entities holding EMERGENCY_ADMIN role on ACLManager to freeze reserves.\n\n post by bgdlabs on Nov 8, 2023\n\n bgdlabs\n\n Leader\n\n Following the timeline, both previous proposals have been create, with voting starting in approximately 24 hours.\nDeprecate REP/ETH price feed on Aave v1\nhttps://app.aave.com/governance/proposal/?proposalId=364\nActivate FreezingSteward on v3 missing networks\nhttps://app.aave.com/governance/proposal/?proposalId=363\nParticipate \n\n 13 days later\n\n post by bgdlabs on Nov 21, 2023\n\n bgdlabs\n\n Leader\n\n Allow emergencyAdmin to freeze on Aave V2, as on V3\n\nSummary\nProposal to allow the emergencyAdmin role to freeze reserves on Aave V2 pools - including Aave V2 AMM, Aave V2 Ethereum, Polygon, and Avalanche; same behavior as on Aave v3.\nAdditionally, the Liquidations Grace Sentinel is activated for Aave V2 AMM, following the same approach as AIP 361\n\nMotivation\nTo be consistent with the approved Aave v3 approach of Freezing Stewards (AIP 319), and maintain security across all Aave V2 deployments, the protocol needs to have up-to-date preventative functionality.\nFreezing is a less invasive mechanism compared with pause, which can already be done by the emergencyAdmin on v2.\n\nSpecification\nThe proposal payloads will update the freezeReserve()/unfreezeReserve() functions on the pool configurator contract to use the new onlyPoolOrEmergencyAdmin modifier, which allows both the emergency admin (Aave Guardian) and pool admin (governance Executor contract) to freeze and unfreeze reserves.\nOn AaveV2Ethereum, AaveV2EthereumAMM, AaveV2Polygon and AaveV2Avalanche the proposal will call:\nPOOL_ADDRESSES_PROVIDER.setLendingPoolConfiguratorImpl(NEW_POOL_CONFIGURATOR)\nTo update the pool configurator with the new implementation.\n\nIn addition LendingPoolCollateralManager for Aave V2 AMM is updated analog to AIP 361.\n\n post by bgdlabs on Nov 22, 2023\n\n bgdlabs\n\n Leader\n\n Freeze price feeds on v3 Harmony following shutdown of Harmony services by Chainlink\n\nSummary\nFollowing Chainlink’s Harmony deprecation, replace all existing price feeds by Chainlink on Aave v3 Harmony with fixed price adapters (with the last known Chainlink price).\nAdditionally, update interest rate strategies to one with exact zero values.\n\nMotivation\nAs Harmony remains unstable following the bridge exploit, and Chainlink is planning to shut down all the price feeds on the network, we believe that the most neutral solution (since there are still users who can withdraw) is to replace the Chainlink feeds with fixed adapters that return the last available price.\nAdditionally, since the pool dynamics are non-functional, accruing any debt makes no difference, even if it was already set to minimal. Therefore, we are going to replace the interest rate strategies for every asset with a zero-interest one.\n\nSpecification\n\nCall AaveV3Harmony.ORACLE.setAssetSources() passing the appropriate parameters to replace the price feeds of the assets on the Aave v3 Harmony Pool.\nFor each asset on the pool, call PoolConfigurator.setReserveInterestRateStrategyAddress(asset, zeroInterestRateStrategy) to replace their rate strategy.\n\n AAVE V3 Harmony Recovery ONE Proposal\n\n post by bgdlabs on Nov 27, 2023\n\n bgdlabs\n\n Leader\n\n Following the timeline, both previous proposals have been create, with voting starting in approximately 24 hours.\nAllow emergencyAdmin to freeze on Aave V2, as on V3\nhttps://app.aave.com/governance/proposal/?proposalId=386\nFreeze price feeds on v3 Harmony following the shutdown of Harmony services by Chainlink\nhttps://snapshot.org/#/aave.eth/proposal/0x6dcd1bec49cc196c02c53746f5d63a96044eb476a9320120aa1fe773c7b47502\nParticipate \n\n post by bgdlabs on Nov 30, 2023\n\n bgdlabs\n\n Leader\n\n Sync implementation of L2 PriceOracleSentinel across all networks\n\nSummary\nThis proposal aligns the Aave PriceOracleSentinel in both Arbitrum and OP stack, to common and correct logic.\n\nMotivation\nCompared with Arbitrum, the L2Sequencer Chainlink feed on OP stack networks behaves differently: it updates every 24 hours as a health check, instead of only when the status (up or down) of the sequencer changes.\nIn order to be fully precise and avoid unexpected downtime, the approach should be unified across networks.\n\nSpecification\nUpon execution, the proposal will call POOL_ADDRESSES_PROVIDER.setPriceOracleSentinel(NEW_PRICE_ORACLE_SENTINEL) on the addresses provider contract and set the new implementation of the PriceOracleSentinel contract on Aave V3 Arbitrum, Optimism, Base and Metis.\n\n Governance Weekly Recap\n\n post by bgdlabs on Dec 3, 2023\n\n bgdlabs\n\n Leader\n\n Following the timeline, we have created proposal 391 to Sync the implementation of L2 PriceOracleSentinel across all networks, with voting starting in approximately 24 hours.\nhttps://app.aave.com/governance/proposal/?proposalId=391\nParticipate \n\n post by bgdlabs on Dec 5, 2023\n\n bgdlabs\n\n Leader\n\n Sync emergency admin on deprecated v2 AMM\n\nSummary\nThis proposal aligns the emergency admin address on the deprecated Aave v2 AMM pool with the one of Aave v2 and v3 Ethereum.\n\nMotivation\nDuring an internal security review procedure of Aave, we detected that the emergency admin on Aave v2 AMM is a legacy address, not aligned with the Aave Guardian.\nEven if the v2 AMM pool is deprecated (frozen) and almost off-boarded, for hygiene we think it is appropriate to have consistency on all Aave instances in the same network, and simpler for operations.\n\nSpecification\nUpon execution, the proposal will call setEmergencyAdmin(0xCA76Ebd8617a03126B6FB84F9b1c1A0fB71C2633) on the addresses provider contract of v2 AMM, passing the address of the Aave Ethereum Guardian.\n\n Governance Weekly Recap\n\n post by bgdlabs on Dec 7, 2023\n\n bgdlabs\n\n Leader\n\n Activate Aave Proof of Reserve on Aave v2 Avalanche\n\nSummary\nActivation of the Aave Proof of Reserve system into Aave v2 Avalanche, to be aligned with Aave v3 Avalanche, even if the v2 pool is slowly getting deprecated in favor of v3.\n\nMotivation\nIn the past, Aave Proof of Reserve was activated on Aave v3 Avalanche. Due to extra complexity on permissions and cross-chain governance not previously applied to Aave Avalanche, v2 Proof of Reserve was not enabled.\nFor consistency of the codebases/behavior and to facilitate operational analysis, enabling the system on v2 Avalanche is still reasonable.\n\nSpecification\nUpon execution, the proposal will call setLendingPoolConfiguratorImpl(NEW_CONFIGURATOR) on the addresses provider contract of v2 Avalanche, passing the address of an upgraded LendingPoolConfigurator which allows the Proof of Reserve system to execute protective actions like freezing or halting borrowing.\nIn addition setAddress() will be called on the addresses provider of v2 Avalanche, to register the address of the Proof of Reserve Executor contract, to have the aforementioned protective permissions.\n\n post by bgdlabs on Dec 8, 2023\n\n bgdlabs\n\n Leader\n\n bgdlabs\n\n We can confirm that both these proposal have been executed:\n\n386 has been executed via the Aave Governance smart contracts.\nBeing a deprecated pool without cross-chain governance, the Aave Guardian executed the Harmony price feeds freezing, as pre-authorized on the Snapshot vote by Aave Governance.\n\n post by bgdlabs on Dec 12, 2023\n\n bgdlabs\n\n Leader\n\n bgdlabs\n\n We have created proposal 401 for the previously announced Sync emergency admin on deprecated v2 AMM.\nVoting will start in approximately 24 hours, participate \nhttps://app.aave.com/governance/proposal/?proposalId=401\n\n post by bgdlabs on Dec 12, 2023\n\n bgdlabs\n\n Leader\n\n bgdlabs\n\n We have created proposal 402 for the previously announced Activate Aave Proof of Reserve on Aave v2 Avalanche.\nVoting will start in approximately 24 hours, participate \nhttps://app.aave.com/governance/proposal/?proposalId=402\n\n 1 month later\n\n post by bgdlabs on Jan 23, 2024\n\n bgdlabs\n\n Leader\n\n Register a.DI Scroll adapter\n\nSummary\nProposal to register the Scroll adapter on Ethereum a.DI, a technical requirement for an activation vote of Aave v3 Scroll.\n\nMotivation\nIn order to be able to pass messages from Ethereum to Scroll via a.DI (Aave Delivery Infrastructure), it is necessary to at least have one valid adapter Ethereum → Scroll smart contract enabled in the system.\nThe first case of message passing Ethereum → Scroll is the activation proposal for an Aave v3 Scroll pool and consequently, to be able to execute on the Scroll side the payload, the Aave governance should approve in advance the a.DI adapter smart contract.\nThis procedure was not required on previous activations like BNB, given that their adapter were pre-configured on the initial a.DI release, but will be needed going forward.\n\nSpecification\nThe proposal payload simply registers a pre-deployed Scroll adapter (with the necessary configurations to communicate with the Scroll a.DI) on the Ethereum a.DI instance.\nThis is done by calling the enableBridgeAdapters() function on the Ethereum Cross-chain Controller smart contract.\n\n BGD. a.DI (Aave Delivery Infrastructure) v1.1\n\n post by bgdlabs on Jan 29, 2024\n\n bgdlabs\n\n Leader\n\n We have created proposal gov v3 #12 for the previously announced Register a.DI Scroll adapter.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=12\n\n Governance Weekly Recap [2024]\n\n post by bgdlabs on Feb 1, 2024\n\n bgdlabs\n\n Leader\n\n Migration of remaining Gov v2 permissions & DAO’s Paraswap positive slippage\n\nSimple Summary\nMigrate Aave Arc pool permissions & Paraswap positive slippage funds allocated to the old governance v2 Short Executor.\n\nMotivation\nIn November 2022 a permissionless contract was introduced to collect positive slippage from Paraswap swaps to the Aave Collector, gained on features like collateral swap, debt swap or repay with collateral. While this system is well and active since then there are some funds (~100k) pending to claim from the previous system which still need migration.\nAdditionally, when Governance v3 was introduced, some permissions for the deprecated Aave Arc pool were not migrated to the new governance system. For proper hygiene and permissions alignment, this should still be done.\n\nSpecification\nOn Ethereum & Polygon the proposal calls:\n\npspclaimer.batchWithdrawAllERC20(assets, collector) to claim pending rewards to the collector\n\nThe proposal will also authorise the Aave Guardian to do the claim to the Collector on the other applicable networks\nOn Ethereum the proposal also queues a call to:\n\narcTimelock.updateEthereumGovernanceExecutor(GovernanceV3Ethereum.EXECUTOR_LVL_1)\n\n post by bgdlabs on Feb 5, 2024\n\n bgdlabs\n\n Leader\n\n We have created proposal Gov v3 #22 for the previously announced Migration of remaining Gov v2 permissions & DAO’s Paraswap positive slippage.\nVoting will start in approximately 24 hours, participate \nhttps://vote.onaave.com/proposal/?proposalId=22\n\n 20 days later\n\n post by bgdlabs on Feb 26, 2024\n\n bgdlabs\n\n Leader\n\n POOL_ADMIN renounceRole() by Guardian on new pools\nSimple Summary\nAfter some maturity time, it is perfectly safe for the Aave Guardian to renounce the POOL_ADMIN role on relatively new pools: Metis, Base, Gnosis and BNB Chain.\nMotivation\nWhenever Aave expands to a new network, this is done in a fully decentralised way via an on-chain governance proposal (e.g. Aave v3 BNB Chain).\nMajor permissions (upgradeability) of the pool are set to the Aave governance from day 0, but the POOL_ADMIN is given to the Aave Guardian during a period of time for security, even if almost never exercised.\nFrom a technical/security perspective, we don’t see any risk at the moment or need for the Guardian to hold this role anymore, so we will coordinate with its members to renounce on all applicable pools: all apart from Scroll.\nFrom now on, we think that after 1-month of the activation of a pool, it should always be safe enough for the Guardian to renounce to POOL_ADMIN, on any upcoming pool.\nSpecification\nThis proposal doesn’t require any governance procedure (Snapshot, on-chain), as the renounce is done directly by the Guardian.\nEach instance of the Aave Guardian (Safe) will call the renounceRole() function for the POOL_ADMIN and their own address.\n\n 17 days later\n\n post by bgdlabs on Mar 14, 2024\n\n bgdlabs\n\n Leader\n\n v3 Periphery maintenance proposal\n\nSimple summary\nPurely technical proposal to do minor improvements on two Aave v3’s periphery components: stataTokens and Sequencer Uptime Feed on Scroll (also known as PriceOracleSentinel).\nAs both proposals are purely technical nature, we will batch them together in a single AIP.\n\nMotivation\n\nScroll Sequencer uptime feed\nThe Sequencer Uptime Feed (also known as “price oracle sentinel”) is a feature baked into Aave v3 that pauses liquidations & borrowing for a limited amount of time whenever a sequencer downtime is detected on a Chainlink oracle (l2 sequencer feed).\nThis pause should give users the ability to refill or repay their positions in case the market moved while the sequencer was down.\nAs the Chainlink Scroll l2 sequencer feed was not yet available when the pool launched, the Sequencer Uptime Feed on Aave was disabled until now.\n\nstataTokens\nIn our continuous effort to enhance the security of the aave protocol and the surrounding ecosystem we discovered some minor issues with the Static a token implementation.\n\nFor reserves without a supplyCap the maxMint function on the static aToken would revert. While there is currently no reserve without a supplyCap on any network, we think it’s reasonable to fix the issue to prevent unforeseen issues for integrators in the future.\nSimilar to an issue fixed on the aave core, the static-a-token is prone to permit griefing. While there is no financial incentive for an attacker to perform griefing, we used the upgrade to close the griefing vector & upgrade the token to rely on the open-zeppelin ECDSA library.\n\nSpecification\n\nScroll Sequencer uptime feed\nUpon execution, the proposal will call POOL_ADDRESSES_PROVIDER.setPriceOracleSentinel(NEW_PRICE_ORACLE_SENTINEL) on the addresses provider contract and set the new implementation of the PriceOracleSentinel contract on Aave V3 Scroll.\n\nstataTokens\nUpon execution, the proposal will call upgrade(token, NEW_TOKEN_IMPLEMENTATION) for all the existing tokens and upgrade(token, NEW_FACTORY_IMPLEMENTATION) for all the existing factories.\n\n Load more posts below","tokens":4910,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264785192,"hash":"ba37447a55f6d21ecdc5bc62d5afa5da7efede55"}
{"url":"https://docs.soliditylang.org/en/develop/solidity-by-example.html","domain":"docs.soliditylang.org","title":"Solidity by Example — Solidity 0.8.38-develop documentation","text":"Solidity by Example\n\n Edit on GitHub\n\nSolidity by Example\n\nVoting\nThe following contract is quite complex, but showcases\na lot of Solidity’s features. It implements a voting\ncontract. Of course, the main problems of electronic\nvoting is how to assign voting rights to the correct\npersons and how to prevent manipulation. We will not\nsolve all problems here, but at least we will show\nhow delegated voting can be done so that vote counting\nis automatic and completely transparent at the\nsame time.\nThe idea is to create one contract per ballot,\nproviding a short name for each option.\nThen the creator of the contract who serves as\nchairperson will give the right to vote to each\naddress individually.\nThe persons behind the addresses can then choose\nto either vote themselves or to delegate their\nvote to a person they trust.\nAt the end of the voting time, winningProposal()\nwill return the proposal with the largest number\nof votes.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n/// @title Voting with delegation.\ncontract Ballot {\n // This declares a new complex type which will\n // be used for variables later.\n // It will represent a single voter.\n struct Voter {\n uint weight; // weight is accumulated by delegation\n bool voted; // if true, that person already voted\n address delegate; // person delegated to\n uint vote; // index of the voted proposal\n }\n\n // This is a type for a single proposal.\n struct Proposal {\n bytes32 name; // short name (up to 32 bytes)\n uint voteCount; // number of accumulated votes\n }\n\n address public chairperson;\n\n // This declares a state variable that\n // stores a `Voter` struct for each possible address.\n mapping(address => Voter) public voters;\n\n // A dynamically-sized array of `Proposal` structs.\n Proposal[] public proposals;\n\n /// Create a new ballot to choose one of `proposalNames`.\n constructor(bytes32[] memory proposalNames) {\n chairperson = msg.sender;\n voters[chairperson].weight = 1;\n\n // For each of the provided proposal names,\n // create a new proposal object and add it\n // to the end of the array.\n for (uint i = 0; i < proposalNames.length; i++) {\n // `Proposal({...})` creates a temporary\n // Proposal object and `proposals.push(...)`\n // appends it to the end of `proposals`.\n proposals.push(Proposal({\n name: proposalNames[i],\n voteCount: 0\n }));\n }\n }\n\n // Give `voter` the right to vote on this ballot.\n // May only be called by `chairperson`.\n function giveRightToVote(address voter) external {\n // If the first argument of `require` evaluates\n // to `false`, execution terminates and all\n // changes to the state and to Ether balances\n // are reverted.\n // This used to consume all gas in old EVM versions, but\n // not anymore.\n // It is often a good idea to use `require` to check if\n // functions are called correctly.\n // As a second argument, you can also provide an\n // explanation about what went wrong.\n require(\n msg.sender == chairperson,\n \"Only chairperson can give right to vote.\"\n );\n require(\n !voters[voter].voted,\n \"The voter already voted.\"\n );\n require(voters[voter].weight == 0);\n voters[voter].weight = 1;\n }\n\n /// Delegate your vote to the voter `to`.\n function delegate(address to) external {\n // assigns reference\n Voter storage sender = voters[msg.sender];\n require(sender.weight != 0, \"You have no right to vote\");\n require(!sender.voted, \"You already voted.\");\n\n require(to != msg.sender, \"Self-delegation is disallowed.\");\n\n // Forward the delegation as long as\n // `to` also delegated.\n // In general, such loops are very dangerous,\n // because if they run too long, they might\n // need more gas than is available in a block.\n // In this case, the delegation will not be executed,\n // but in other situations, such loops might\n // cause a contract to get \"stuck\" completely.\n while (voters[to].delegate != address(0)) {\n to = voters[to].delegate;\n\n // We found a loop in the delegation, not allowed.\n require(to != msg.sender, \"Found loop in delegation.\");\n }\n\n Voter storage delegate_ = voters[to];\n\n // Voters cannot delegate to accounts that cannot vote.\n require(delegate_.weight >= 1);\n\n // Since `sender` is a reference, this\n // modifies `voters[msg.sender]`.\n sender.voted = true;\n sender.delegate = to;\n\n if (delegate_.voted) {\n // If the delegate already voted,\n // directly add to the number of votes\n proposals[delegate_.vote].voteCount += sender.weight;\n } else {\n // If the delegate did not vote yet,\n // add to her weight.\n delegate_.weight += sender.weight;\n }\n }\n\n /// Give your vote (including votes delegated to you)\n /// to proposal `proposals[proposal].name`.\n function vote(uint proposal) external {\n Voter storage sender = voters[msg.sender];\n require(sender.weight != 0, \"Has no right to vote\");\n require(!sender.voted, \"Already voted.\");\n sender.voted = true;\n sender.vote = proposal;\n\n // If `proposal` is out of the range of the array,\n // this will throw automatically and revert all\n // changes.\n proposals[proposal].voteCount += sender.weight;\n }\n\n /// @dev Computes the winning proposal taking all\n /// previous votes into account.\n function winningProposal() public view\n returns (uint winningProposal_)\n {\n uint winningVoteCount = 0;\n for (uint p = 0; p < proposals.length; p++) {\n if (proposals[p].voteCount > winningVoteCount) {\n winningVoteCount = proposals[p].voteCount;\n winningProposal_ = p;\n }\n }\n }\n\n // Calls winningProposal() function to get the index\n // of the winner contained in the proposals array and then\n // returns the name of the winner\n function winnerName() external view\n returns (bytes32 winnerName_)\n {\n winnerName_ = proposals[winningProposal()].name;\n }\n}\n\nPossible Improvements\nCurrently, many transactions are needed to\nassign the rights to vote to all participants.\nMoreover, if two or more proposals have the same\nnumber of votes, winningProposal() is not able\nto register a tie. Can you think of a way to fix these issues?\n\nBlind Auction\nIn this section, we will show how easy it is to create a completely blind\nauction contract on Ethereum. We will start with an open auction where\neveryone can see the bids that are made and then extend this contract into a\nblind auction where it is not possible to see the actual bid until the bidding\nperiod ends.\n\nSimple Open Auction\nThe general idea of the following simple auction contract is that everyone can\nsend their bids during a bidding period. The bids already include sending some compensation,\ne.g. Ether, in order to bind the bidders to their bid. If the highest bid is\nraised, the previous highest bidder gets their Ether back. After the end of\nthe bidding period, the contract has to be called manually for the beneficiary\nto receive their Ether - contracts cannot activate themselves.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\ncontract SimpleAuction {\n // Parameters of the auction. Times are either\n // absolute unix timestamps (seconds since 1970-01-01)\n // or time periods in seconds.\n address payable public beneficiary;\n uint public auctionEndTime;\n\n // Current state of the auction.\n address public highestBidder;\n uint public highestBid;\n\n // Allowed withdrawals of previous bids\n mapping(address => uint) pendingReturns;\n\n // Set to true at the end, disallows any change.\n // By default initialized to `false`.\n bool ended;\n\n // Events that will be emitted on changes.\n event HighestBidIncreased(address bidder, uint amount);\n event AuctionEnded(address winner, uint amount);\n\n // Errors that describe failures.\n\n // The triple-slash comments are so-called natspec\n // comments. They will be shown when the user\n // is asked to confirm a transaction or\n // when an error is displayed.\n\n /// The auction has already ended.\n error AuctionAlreadyEnded();\n /// There is already a higher or equal bid.\n error BidNotHighEnough(uint highestBid);\n /// The auction has not ended yet.\n error AuctionNotYetEnded();\n /// The function auctionEnd has already been called.\n error AuctionEndAlreadyCalled();\n\n /// Create a simple auction with `biddingTime`\n /// seconds bidding time on behalf of the\n /// beneficiary address `beneficiaryAddress`.\n constructor(\n uint biddingTime,\n address payable beneficiaryAddress\n ) {\n beneficiary = beneficiaryAddress;\n auctionEndTime = block.timestamp + biddingTime;\n }\n\n /// Bid on the auction with the value sent\n /// together with this transaction.\n /// The value will only be refunded if the\n /// auction is not won.\n function bid() external payable {\n // No arguments are necessary, all\n // information is already part of\n // the transaction. The keyword payable\n // is required for the function to\n // be able to receive Ether.\n\n // Revert the call if the bidding\n // period is over.\n if (block.timestamp > auctionEndTime)\n revert AuctionAlreadyEnded();\n\n // If the bid is not higher, send the\n // Ether back (the revert statement\n // will revert all changes in this\n // function execution including\n // it having received the Ether).\n if (msg.value <= highestBid)\n revert BidNotHighEnough(highestBid);\n\n if (highestBid != 0) {\n // Sending back the Ether by simply using\n // highestBidder.send(highestBid) is a security risk\n // because it could execute an untrusted contract.\n // It is always safer to let the recipients\n // withdraw their Ether themselves.\n pendingReturns[highestBidder] += highestBid;\n }\n highestBidder = msg.sender;\n highestBid = msg.value;\n emit HighestBidIncreased(msg.sender, msg.value);\n }\n\n /// Withdraw a bid that was overbid.\n function withdraw() external returns (bool) {\n uint amount = pendingReturns[msg.sender];\n if (amount > 0) {\n // It is important to set this to zero because the recipient\n // can call this function again as part of the receiving call\n // before `call` returns.\n pendingReturns[msg.sender] = 0;\n\n // msg.sender is not of type `address payable` and must be\n // explicitly converted using `payable(msg.sender)` in order\n // use the member function `call()`.\n (bool success, ) = payable(msg.sender).call{value: amount}(\"\");\n if (!success) {\n // No need to call throw here, just reset the amount owing\n pendingReturns[msg.sender] = amount;\n return false;\n }\n }\n return true;\n }\n\n /// End the auction and send the highest bid\n /// to the beneficiary.\n function auctionEnd() external {\n // It is a good guideline to structure functions that interact\n // with other contracts (i.e. they call functions or send Ether)\n // into three phases:\n // 1. checking conditions\n // 2. performing actions (potentially changing conditions)\n // 3. interacting with other contracts\n // If these phases are mixed up, the other contract could call\n // back into the current contract and modify the state or cause\n // effects (ether payout) to be performed multiple times.\n // If functions called internally include interaction with external\n // contracts, they also have to be considered interaction with\n // external contracts.\n\n // 1. Conditions\n if (block.timestamp < auctionEndTime)\n revert AuctionNotYetEnded();\n if (ended)\n revert AuctionEndAlreadyCalled();\n\n // 2. Effects\n ended = true;\n emit AuctionEnded(highestBidder, highestBid);\n\n // 3. Interaction\n (bool success, ) = beneficiary.call{value: highestBid}(\"\");\n require(success);\n }\n}\n\nBlind Auction\nThe previous open auction is extended to a blind auction in the following. The\nadvantage of a blind auction is that there is no time pressure towards the end\nof the bidding period. Creating a blind auction on a transparent computing\nplatform might sound like a contradiction, but cryptography comes to the\nrescue.\nDuring the bidding period, a bidder does not actually send their bid, but\nonly a hashed version of it. Since it is currently considered practically\nimpossible to find two (sufficiently long) values whose hash values are equal,\nthe bidder commits to the bid by that. After the end of the bidding period,\nthe bidders have to reveal their bids: They send their values unencrypted, and\nthe contract checks that the hash value is the same as the one provided during\nthe bidding period.\nAnother challenge is how to make the auction binding and blind at the same\ntime: The only way to prevent the bidder from just not sending the Ether after\nthey won the auction is to make them send it together with the bid. Since value\ntransfers cannot be blinded in Ethereum, anyone can see the value.\nThe following contract solves this problem by accepting any value that is\nlarger than the highest bid. Since this can of course only be checked during\nthe reveal phase, some bids might be invalid, and this is on purpose (it\neven provides an explicit flag to place invalid bids with high-value\ntransfers): Bidders can confuse competition by placing several high or low\ninvalid bids.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\ncontract BlindAuction {\n struct Bid {\n bytes32 blindedBid;\n uint deposit;\n }\n\n address payable public beneficiary;\n uint public biddingEnd;\n uint public revealEnd;\n bool public ended;\n\n mapping(address => Bid[]) public bids;\n\n address public highestBidder;\n uint public highestBid;\n\n // Allowed withdrawals of previous bids\n mapping(address => uint) pendingReturns;\n\n event AuctionEnded(address winner, uint highestBid);\n\n // Errors that describe failures.\n\n /// The function has been called too early.\n /// Try again at `time`.\n error TooEarly(uint time);\n /// The function has been called too late.\n /// It cannot be called after `time`.\n error TooLate(uint time);\n /// The function auctionEnd has already been called.\n error AuctionEndAlreadyCalled();\n\n // Modifiers are a convenient way to validate inputs to\n // functions. `onlyBefore` is applied to `bid` below:\n // The new function body is the modifier's body where\n // `_` is replaced by the old function body.\n modifier onlyBefore(uint time) {\n if (block.timestamp >= time) revert TooLate(time);\n _;\n }\n modifier onlyAfter(uint time) {\n if (block.timestamp <= time) revert TooEarly(time);\n _;\n }\n\n constructor(\n uint biddingTime,\n uint revealTime,\n address payable beneficiaryAddress\n ) {\n beneficiary = beneficiaryAddress;\n biddingEnd = block.timestamp + biddingTime;\n revealEnd = biddingEnd + revealTime;\n }\n\n /// Place a blinded bid with `blindedBid` =\n /// keccak256(abi.encodePacked(value, fake, secret)).\n /// The sent ether is only refunded if the bid is correctly\n /// revealed in the revealing phase. The bid is valid if the\n /// ether sent together with the bid is at least \"value\" and\n /// \"fake\" is not true. Setting \"fake\" to true and sending\n /// not the exact amount are ways to hide the real bid but\n /// still make the required deposit. The same address can\n /// place multiple bids.\n function bid(bytes32 blindedBid)\n external\n payable\n onlyBefore(biddingEnd)\n {\n bids[msg.sender].push(Bid({\n blindedBid: blindedBid,\n deposit: msg.value\n }));\n }\n\n /// Reveal your blinded bids. You will get a refund for all\n /// correctly blinded invalid bids and for all bids except for\n /// the totally highest.\n function reveal(\n uint[] calldata values,\n bool[] calldata fakes,\n bytes32[] calldata secrets\n )\n external\n onlyAfter(biddingEnd)\n onlyBefore(revealEnd)\n {\n uint length = bids[msg.sender].length;\n require(values.length == length);\n require(fakes.length == length);\n require(secrets.length == length);\n\n uint refund;\n for (uint i = 0; i < length; i++) {\n Bid storage bidToCheck = bids[msg.sender][i];\n (uint value, bool fake, bytes32 secret) =\n (values[i], fakes[i], secrets[i]);\n if (bidToCheck.blindedBid != keccak256(abi.encodePacked(value, fake, secret))) {\n // Bid was not actually revealed.\n // Do not refund deposit.\n continue;\n }\n refund += bidToCheck.deposit;\n if (!fake && bidToCheck.deposit >= value) {\n if (placeBid(msg.sender, value))\n refund -= value;\n }\n // Make it impossible for the sender to re-claim\n // the same deposit.\n bidToCheck.blindedBid = bytes32(0);\n }\n (bool success, ) = payable(msg.sender).call{value: refund}(\"\");\n require(success);\n }\n\n /// Withdraw a bid that was overbid.\n function withdraw() external {\n uint amount = pendingReturns[msg.sender];\n if (amount > 0) {\n // It is important to set this to zero because the recipient\n // can call this function again as part of the receiving call\n // before `call` returns (see the remark above about\n // conditions -> effects -> interaction).\n pendingReturns[msg.sender] = 0;\n\n (bool success, ) = payable(msg.sender).call{value: amount}(\"\");\n require(success);\n }\n }\n\n /// End the auction and send the highest bid\n /// to the beneficiary.\n function auctionEnd()\n external\n onlyAfter(revealEnd)\n {\n if (ended) revert AuctionEndAlreadyCalled();\n emit AuctionEnded(highestBidder, highestBid);\n ended = true;\n (bool success, ) = beneficiary.call{value: highestBid}(\"\");\n require(success);\n }\n\n // This is an \"internal\" function which means that it\n // can only be called from the contract itself (or from\n // derived contracts).\n function placeBid(address bidder, uint value) internal\n returns (bool success)\n {\n if (value <= highestBid) {\n return false;\n }\n if (highestBidder != address(0)) {\n // Refund the previously highest bidder.\n pendingReturns[highestBidder] += highestBid;\n }\n highestBid = value;\n highestBidder = bidder;\n return true;\n }\n}\n\nSafe Remote Purchase\nPurchasing goods remotely currently requires multiple parties that need to trust each other.\nThe simplest configuration involves a seller and a buyer. The buyer would like to receive\nan item from the seller and the seller would like to get some compensation, e.g. Ether,\nin return. The problematic part is the shipment here: There is no way to determine for\nsure that the item arrived at the buyer.\nThere are multiple ways to solve this problem, but all fall short in one or the other way.\nIn the following example, both parties have to put twice the value of the item into the\ncontract as escrow. As soon as this happened, the Ether will stay locked inside\nthe contract until the buyer confirms that they received the item. After that,\nthe buyer is returned the value (half of their deposit) and the seller gets three\ntimes the value (their deposit plus the value). The idea behind\nthis is that both parties have an incentive to resolve the situation or otherwise\ntheir Ether is locked forever.\nThis contract of course does not solve the problem, but gives an overview of how\nyou can use state machine-like constructs inside a contract.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.4;\ncontract Purchase {\n uint public value;\n address payable public seller;\n address payable public buyer;\n\n enum State { Created, Locked, Release, Inactive }\n // The state variable has a default value of the first member, `State.created`\n State public state;\n\n modifier condition(bool condition_) {\n require(condition_);\n _;\n }\n\n /// Only the buyer can call this function.\n error OnlyBuyer();\n /// Only the seller can call this function.\n error OnlySeller();\n /// The function cannot be called at the current state.\n error InvalidState();\n /// The provided value has to be even.\n error ValueNotEven();\n\n modifier onlyBuyer() {\n if (msg.sender != buyer)\n revert OnlyBuyer();\n _;\n }\n\n modifier onlySeller() {\n if (msg.sender != seller)\n revert OnlySeller();\n _;\n }\n\n modifier inState(State state_) {\n if (state != state_)\n revert InvalidState();\n _;\n }\n\n event Aborted();\n event PurchaseConfirmed();\n event ItemReceived();\n event SellerRefunded();\n\n // Ensure that `msg.value` is an even number.\n // Division will truncate if it is an odd number.\n // Check via multiplication that it wasn't an odd number.\n constructor() payable {\n seller = payable(msg.sender);\n value = msg.value / 2;\n if ((2 * value) != msg.value)\n revert ValueNotEven();\n }\n\n /// Abort the purchase and reclaim the ether.\n /// Can only be called by the seller before\n /// the contract is locked.\n function abort()\n external\n onlySeller\n inState(State.Created)\n {\n emit Aborted();\n state = State.Inactive;\n // We use call here directly. It is\n // reentrancy-safe, because it is the\n // last call in this function and we\n // already changed the state.\n (bool success, ) = seller.call{value: address(this).balance}(\"\");\n require(success);\n }\n\n /// Confirm the purchase as buyer.\n /// Transaction has to include `2 * value` ether.\n /// The ether will be locked until confirmReceived\n /// is called.\n function confirmPurchase()\n external\n inState(State.Created)\n condition(msg.value == (2 * value))\n payable\n {\n emit PurchaseConfirmed();\n buyer = payable(msg.sender);\n state = State.Locked;\n }\n\n /// Confirm that you (the buyer) received the item.\n /// This will release the locked ether.\n function confirmReceived()\n external\n onlyBuyer\n inState(State.Locked)\n {\n emit ItemReceived();\n // It is important to change the state first because\n // otherwise, the contracts called using `call` below\n // can call in again here.\n state = State.Release;\n\n (bool success, ) = buyer.call{value: value}(\"\");\n require(success);\n }\n\n /// This function refunds the seller, i.e.\n /// pays back the locked funds of the seller.\n function refundSeller()\n external\n onlySeller\n inState(State.Release)\n {\n emit SellerRefunded();\n // It is important to change the state first because\n // otherwise, the contracts called using `call` below\n // can call in again here.\n state = State.Inactive;\n\n (bool success, ) = seller.call{value: 3 * value}(\"\");\n require(success);\n }\n}\n\nMicropayment Channel\nIn this section, we will learn how to build an example implementation\nof a payment channel. It uses cryptographic signatures to make\nrepeated transfers of Ether between the same parties secure, instantaneous, and\nwithout transaction fees. For the example, we need to understand how to\nsign and verify signatures, and setup the payment channel.\n\nCreating and verifying signatures\nImagine Alice wants to send some Ether to Bob, i.e.\nAlice is the sender and Bob is the recipient.\nAlice only needs to send cryptographically signed messages off-chain\n(e.g. via email) to Bob and it is similar to writing checks.\nAlice and Bob use signatures to authorize transactions, which is possible with smart contracts on Ethereum.\nAlice will build a simple smart contract that lets her transmit Ether, but instead of calling a function herself\nto initiate a payment, she will let Bob do that, and therefore pay the transaction fee.\nThe contract will work as follows:\n\nAlice deploys the ReceiverPays contract, attaching enough Ether to cover the payments that will be made.\nAlice authorizes a payment by signing a message with her private key.\nAlice sends the cryptographically signed message to Bob. The message does not need to be kept secret\n(explained later), and the mechanism for sending it does not matter.\nBob claims his payment by presenting the signed message to the smart contract, it verifies the\nauthenticity of the message and then releases the funds.\n\nCreating the signature\nAlice does not need to interact with the Ethereum network\nto sign the transaction, the process is completely offline.\nIn this tutorial, we will sign messages in the browser\nusing web3.js and\nMetaMask, using the method described in EIP-712,\nas it provides a number of other security benefits.\n/// Hashing first makes things easier\nvar hash = web3.utils.sha3(\"message to sign\");\nweb3.eth.personal.sign(hash, web3.eth.defaultAccount, function () { console.log(\"Signed\"); });\n\nNote\nThe web3.eth.personal.sign prepends the length of the\nmessage to the signed data. Since we hash first, the message\nwill always be exactly 32 bytes long, and thus this length\nprefix is always the same.\n\nWhat to Sign\nFor a contract that fulfills payments, the signed message must include:\n\nThe recipient’s address.\nThe amount to be transferred.\nProtection against replay attacks.\n\nA replay attack is when a signed message is reused to claim\nauthorization for a second action. To avoid replay attacks\nwe use the same technique as in Ethereum transactions themselves,\na so-called nonce, which is the number of transactions sent by\nan account. The smart contract checks if a nonce is used multiple times.\nAnother type of replay attack can occur when the owner\ndeploys a ReceiverPays smart contract, makes some\npayments, and then destroys the contract. Later, they decide\nto deploy the RecipientPays smart contract again, but the\nnew contract does not know the nonces used in the previous\ndeployment, so the attacker can use the old messages again.\nAlice can protect against this attack by including the\ncontract’s address in the message, and only messages containing\nthe contract’s address itself will be accepted. You can find\nan example of this in the first two lines of the claimPayment()\nfunction of the full contract at the end of this section.\nFurthermore, instead of destroying the contract by calling selfdestruct,\nwhich is currently deprecated, we will disable the contract’s functionalities by freezing it,\nresulting in the reversion of any call after it being frozen.\n\nPacking arguments\nNow that we have identified what information to include in the signed message,\nwe are ready to put the message together, hash it, and sign it. For simplicity,\nwe concatenate the data. The ethereumjs-abi\nlibrary provides a function called soliditySHA3 that mimics the behavior of\nSolidity’s keccak256 function applied to arguments encoded using abi.encodePacked.\nHere is a JavaScript function that creates the proper signature for the ReceiverPays example:\n// recipient is the address that should be paid.\n// amount, in wei, specifies how much ether should be sent.\n// nonce can be any unique number to prevent replay attacks\n// contractAddress is used to prevent cross-contract replay attacks\nfunction signPayment(recipient, amount, nonce, contractAddress, callback) {\n var hash = \"0x\" + abi.soliditySHA3(\n [\"address\", \"uint256\", \"uint256\", \"address\"],\n [recipient, amount, nonce, contractAddress]\n ).toString(\"hex\");\n\n web3.eth.personal.sign(hash, web3.eth.defaultAccount, callback);\n}\n\nRecovering the Message Signer in Solidity\nIn general, ECDSA signatures consist of two parameters,\nr and s. Signatures in Ethereum include a third\nparameter called v, that you can use to verify which\naccount’s private key was used to sign the message, and\nthe transaction’s sender. Solidity provides a built-in\nfunction ecrecover that\naccepts a message along with the r, s and v parameters\nand returns the address that was used to sign the message.\n\nExtracting the Signature Parameters\nSignatures produced by web3.js are the concatenation of r,\ns and v, so the first step is to split these parameters\napart. You can do this on the client-side, but doing it inside\nthe smart contract means you only need to send one signature\nparameter rather than three. Splitting apart a byte array into\nits constituent parts is a mess, so we use\ninline assembly to do the job in the splitSignature\nfunction (the third function in the full contract at the end of this section).\n\nComputing the Message Hash\nThe smart contract needs to know exactly what parameters were signed, and so it\nmust recreate the message from the parameters and use that for signature verification.\nThe functions prefixed and recoverSigner do this in the claimPayment function.\n\nThe full contract\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n\ncontract Owned {\n address payable owner;\n constructor() {\n owner = payable(msg.sender);\n }\n}\n\ncontract Freezable is Owned {\n bool private _frozen = false;\n\n modifier notFrozen() {\n require(!_frozen, \"Inactive Contract.\");\n _;\n }\n\n function freeze() internal {\n if (msg.sender == owner)\n _frozen = true;\n }\n}\n\ncontract ReceiverPays is Freezable {\n mapping(uint256 => bool) usedNonces;\n\n constructor() payable {}\n\n function claimPayment(uint256 amount, uint256 nonce, bytes memory signature)\n external\n notFrozen\n {\n require(!usedNonces[nonce]);\n usedNonces[nonce] = true;\n\n // this recreates the message that was signed on the client\n bytes32 message = prefixed(keccak256(abi.encodePacked(msg.sender, amount, nonce, this)));\n require(recoverSigner(message, signature) == owner);\n (bool success, ) = payable(msg.sender).call{value: amount}(\"\");\n require(success);\n }\n\n /// freeze the contract and reclaim the leftover funds.\n function shutdown()\n external\n notFrozen\n {\n require(msg.sender == owner);\n freeze();\n (bool success, ) = payable(msg.sender).call{value: address(this).balance}(\"\");\n require(success);\n }\n\n /// signature methods.\n function splitSignature(bytes memory sig)\n internal\n pure\n returns (uint8 v, bytes32 r, bytes32 s)\n {\n require(sig.length == 65);\n\n assembly {\n // first 32 bytes, after the length prefix.\n r := mload(add(sig, 32))\n // second 32 bytes.\n s := mload(add(sig, 64))\n // final byte (first byte of the next 32 bytes).\n v := byte(0, mload(add(sig, 96)))\n }\n\n return (v, r, s);\n }\n\n function recoverSigner(bytes32 message, bytes memory sig)\n internal\n pure\n returns (address)\n {\n (uint8 v, bytes32 r, bytes32 s) = splitSignature(sig);\n return ecrecover(message, v, r, s);\n }\n\n /// builds a prefixed hash to mimic the behavior of eth_sign.\n function prefixed(bytes32 hash) internal pure returns (bytes32) {\n return keccak256(abi.encodePacked(\"\\x19Ethereum Signed Message:\\n32\", hash));\n }\n}\n\nWriting a Simple Payment Channel\nAlice now builds a simple but complete implementation of a payment\nchannel. Payment channels use cryptographic signatures to make\nrepeated transfers of Ether securely, instantaneously, and without transaction fees.\n\nWhat is a Payment Channel?\nPayment channels allow participants to make repeated transfers of Ether\nwithout using transactions. This means that you can avoid the delays and\nfees associated with transactions. We are going to explore a simple\nunidirectional payment channel between two parties (Alice and Bob). It involves three steps:\n\nAlice funds a smart contract with Ether. This “opens” the payment channel.\nAlice signs messages that specify how much of that Ether is owed to the recipient. This step is repeated for each payment.\nBob “closes” the payment channel, withdrawing his portion of the Ether and sending the remainder back to the sender.\n\nNote\nOnly steps 1 and 3 require Ethereum transactions, step 2 means that the sender\ntransmits a cryptographically signed message to the recipient via off chain\nmethods (e.g. email). This means only two transactions are required to support\nany number of transfers.\n\nBob is guaranteed to receive his funds because the smart contract escrows the\nEther and honours a valid signed message. The smart contract also enforces a\ntimeout, so Alice is guaranteed to eventually recover her funds even if the\nrecipient refuses to close the channel. It is up to the participants in a payment\nchannel to decide how long to keep it open. For a short-lived transaction,\nsuch as paying an internet café for each minute of network access, the payment\nchannel may be kept open for a limited duration. On the other hand, for a\nrecurring payment, such as paying an employee an hourly wage, the payment channel\nmay be kept open for several months or years.\n\nOpening the Payment Channel\nTo open the payment channel, Alice deploys the smart contract, attaching\nthe Ether to be escrowed and specifying the intended recipient and a\nmaximum duration for the channel to exist. This is the constructor\nin the SimplePaymentChannel contract, at the end of this section.\n\nMaking Payments\nAlice makes payments by sending signed messages to Bob.\nThis step is performed entirely outside of the Ethereum network.\nMessages are cryptographically signed by the sender and then transmitted directly to the recipient.\nEach message includes the following information:\n\nThe smart contract’s address, used to prevent cross-contract replay attacks.\nThe total amount of Ether that is owed to the recipient so far.\n\nA payment channel is closed just once, at the end of a series of transfers.\nBecause of this, only one of the messages sent is redeemed. This is why\neach message specifies a cumulative total amount of Ether owed, rather than the\namount of the individual micropayment. The recipient will naturally choose to\nredeem the most recent message because that is the one with the highest total.\nThe nonce per-message is not needed anymore, because the smart contract only\nhonours a single message. The address of the smart contract is still used\nto prevent a message intended for one payment channel from being used for a different channel.\nHere is the modified JavaScript code to cryptographically sign a message from the previous section:\nfunction constructPaymentMessage(contractAddress, amount) {\n return abi.soliditySHA3(\n [\"address\", \"uint256\"],\n [contractAddress, amount]\n );\n}\n\nfunction signMessage(message, callback) {\n web3.eth.personal.sign(\n \"0x\" + message.toString(\"hex\"),\n web3.eth.defaultAccount,\n callback\n );\n}\n\n// contractAddress is used to prevent cross-contract replay attacks.\n// amount, in wei, specifies how much Ether should be sent.\n\nfunction signPayment(contractAddress, amount, callback) {\n var message = constructPaymentMessage(contractAddress, amount);\n signMessage(message, callback);\n}\n\nClosing the Payment Channel\nWhen Bob is ready to receive his funds, it is time to\nclose the payment channel by calling a close function on the smart contract.\nClosing the channel pays the recipient the Ether they are owed and\ndeactivates the contract by freezing it, sending any remaining Ether back to Alice. To\nclose the channel, Bob needs to provide a message signed by Alice.\nThe smart contract must verify that the message contains a valid signature from the sender.\nThe process for doing this verification is the same as the process the recipient uses.\nThe Solidity functions isValidSignature and recoverSigner work just like their\nJavaScript counterparts in the previous section, with the latter function borrowed from the ReceiverPays contract.\nOnly the payment channel recipient can call the close function,\nwho naturally passes the most recent payment message because that message\ncarries the highest total owed. If the sender were allowed to call this function,\nthey could provide a message with a lower amount and cheat the recipient out of what they are owed.\nThe function verifies the signed message matches the given parameters.\nIf everything checks out, the recipient is sent their portion of the Ether,\nand the sender is sent the remaining funds via a transfer.\nYou can see the close function in the full contract.\n\nChannel Expiration\nBob can close the payment channel at any time, but if they fail to do so,\nAlice needs a way to recover her escrowed funds. An expiration time was set\nat the time of contract deployment. Once that time is reached, Alice can call\nclaimTimeout to recover her funds. You can see the claimTimeout function in the full contract.\nAfter this function is called, Bob can no longer receive any Ether,\nso it is important that Bob closes the channel before the expiration is reached.\n\nThe full contract\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.7.0 <0.9.0;\n\ncontract Freezable {\n bool private _frozen = false;\n\n modifier notFrozen() {\n require(!_frozen, \"Inactive Contract.\");\n _;\n }\n\n function freeze() internal {\n _frozen = true;\n }\n}\n\ncontract SimplePaymentChannel is Freezable {\n address payable public sender; // The account sending payments.\n address payable public recipient; // The account receiving the payments.\n uint256 public expiration; // Timeout in case the recipient never closes.\n\n constructor (address payable recipientAddress, uint256 duration)\n payable\n {\n sender = payable(msg.sender);\n recipient = recipientAddress;\n expiration = block.timestamp + duration;\n }\n\n /// the recipient can close the channel at any time by presenting a\n /// signed amount from the sender. the recipient will be sent that amount,\n /// and the remainder will go back to the sender\n function close(uint256 amount, bytes memory signature)\n external\n notFrozen\n {\n require(msg.sender == recipient);\n require(isValidSignature(amount, signature));\n\n freeze();\n (bool success, ) = recipient.call{value: amount}(\"\");\n require(success);\n (success, ) = sender.call{value: address(this).balance}(\"\");\n require(success);\n }\n\n /// the sender can extend the expiration at any time\n function extend(uint256 newExpiration)\n external\n notFrozen\n {\n require(msg.sender == sender);\n require(newExpiration > expiration);\n\n expiration = newExpiration;\n }\n\n /// if the timeout is reached without the recipient closing the channel,\n /// then the Ether is released back to the sender.\n function claimTimeout()\n external\n notFrozen\n {\n require(block.timestamp >= expiration);\n freeze();\n (bool success, ) = sender.call{value: address(this).balance}(\"\");\n require(success);\n }\n\n function isValidSignature(uint256 amount, bytes memory signature)\n internal\n view\n returns (bool)\n {\n bytes32 message = prefixed(keccak256(abi.encodePacked(this, amount)));\n // check that the signature is from the payment sender\n return recoverSigner(message, signature) == sender;\n }\n\n /// All functions below this are just taken from the chapter\n /// 'creating and verifying signatures' chapter.\n function splitSignature(bytes memory sig)\n internal\n pure\n returns (uint8 v, bytes32 r, bytes32 s)\n {\n require(sig.length == 65);\n\n assembly {\n // first 32 bytes, after the length prefix\n r := mload(add(sig, 32))\n // second 32 bytes\n s := mload(add(sig, 64))\n // final byte (first byte of the next 32 bytes)\n v := byte(0, mload(add(sig, 96)))\n }\n return (v, r, s);\n }\n\n function recoverSigner(bytes32 message, bytes memory sig)\n internal\n pure\n returns (address)\n {\n (uint8 v, bytes32 r, bytes32 s) = splitSignature(sig);\n return ecrecover(message, v, r, s);\n }\n\n /// builds a prefixed hash to mimic the behavior of eth_sign.\n function prefixed(bytes32 hash) internal pure returns (bytes32) {\n return keccak256(abi.encodePacked(\"\\x19Ethereum Signed Message:\\n32\", hash));\n }\n}\n\nNote\nThe function splitSignature does not use all security\nchecks. A real implementation should use a more rigorously tested library,\nsuch as openzeppelin’s version of this code.\n\nVerifying Payments\nUnlike in the previous section, messages in a payment channel aren’t\nredeemed right away. The recipient keeps track of the latest message and\nredeems it when it’s time to close the payment channel. This means it’s\ncritical that the recipient perform their own verification of each message.\nOtherwise there is no guarantee that the recipient will be able to get paid\nin the end.\nThe recipient should verify each message using the following process:\n\nVerify that the contract address in the message matches the payment channel.\nVerify that the new total is the expected amount.\nVerify that the new total does not exceed the amount of Ether escrowed.\nVerify that the signature is valid and comes from the payment channel sender.\n\nWe’ll use the ethereumjs-util\nlibrary to write this verification. The final step can be done a number of ways,\nand we use JavaScript. The following code borrows the constructPaymentMessage function from the signing JavaScript code above:\n// this mimics the prefixing behavior of the eth_sign JSON-RPC method.\nfunction prefixed(hash) {\n return ethereumjs.ABI.soliditySHA3(\n [\"string\", \"bytes32\"],\n [\"\\x19Ethereum Signed Message:\\n32\", hash]\n );\n}\n\nfunction recoverSigner(message, signature) {\n var split = ethereumjs.Util.fromRpcSig(signature);\n var publicKey = ethereumjs.Util.ecrecover(message, split.v, split.r, split.s);\n var signer = ethereumjs.Util.pubToAddress(publicKey).toString(\"hex\");\n return signer;\n}\n\nfunction isValidSignature(contractAddress, amount, signature, expectedSigner) {\n var message = prefixed(constructPaymentMessage(contractAddress, amount));\n var signer = recoverSigner(message, signature);\n return signer.toLowerCase() ==\n ethereumjs.Util.stripHexPrefix(expectedSigner).toLowerCase();\n}\n\nModular Contracts\nA modular approach to building your contracts helps you reduce the complexity\nand improve the readability which will help to identify bugs and vulnerabilities\nduring development and code review.\nIf you specify and control the behavior of each module in isolation, the\ninteractions you have to consider are only those between the module specifications\nand not every other moving part of the contract.\nIn the example below, the contract uses the move method\nof the Balances library to check that balances sent between\naddresses match what you expect. In this way, the Balances library\nprovides an isolated component that properly tracks balances of accounts.\nIt is easy to verify that the Balances library never produces negative balances or overflows\nand the sum of all balances is an invariant across the lifetime of the contract.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.5.0 <0.9.0;\n\nlibrary Balances {\n function move(mapping(address => uint256) storage balances, address from, address to, uint amount) internal {\n require(balances[from] >= amount);\n require(balances[to] + amount >= balances[to]);\n balances[from] -= amount;\n balances[to] += amount;\n }\n}\n\ncontract Token {\n mapping(address => uint256) balances;\n using Balances for *;\n mapping(address => mapping(address => uint256)) allowed;\n\n event Transfer(address from, address to, uint amount);\n event Approval(address owner, address spender, uint amount);\n\n function transfer(address to, uint amount) external returns (bool success) {\n balances.move(msg.sender, to, amount);\n emit Transfer(msg.sender, to, amount);\n return true;\n\n }\n\n function transferFrom(address from, address to, uint amount) external returns (bool success) {\n require(allowed[from][msg.sender] >= amount);\n allowed[from][msg.sender] -= amount;\n balances.move(from, to, amount);\n emit Transfer(from, to, amount);\n return true;\n }\n\n function approve(address spender, uint tokens) external returns (bool success) {\n require(allowed[msg.sender][spender] == 0, \"\");\n allowed[msg.sender][spender] = tokens;\n emit Approval(msg.sender, spender, tokens);\n return true;\n }\n\n function balanceOf(address tokenOwner) external view returns (uint balance) {\n return balances[tokenOwner];\n }\n}","tokens":10503,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264793262,"hash":"111b977f297db2d050f6da7f2cf66554fbdd8cdd"}
{"url":"https://governance.aave.com/t/bgd-operational-oracles-update/13213/13","domain":"governance.aave.com","title":"BGD. Operational oracles update - Development - Aave","text":"Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 10\n\n 3\n\n read \n\n 5\n min\n\n May 2023\n\n 13 / 18\n\n Oct 2023\n\n Jan 2024\n\n post by bgdlabs on May 25, 2023\n\n bgdlabs\n\n Leader\n\n TL;DR\nPresent to the community our proposal to do an operational update of different oracle aspects, for the sake of consistency across instances of Aave.\n\nContext\nGiven limitations on for example the availability of price feeds, or changes in community strategies of assets’ pricing, sometimes it is necessary to have purely operational proposals to align all Aave components.\nIn order to not create a big overhead, we have decided to batch some of these required updates, and before going forward with an on-chain proposal, we want to transparently present to the community what will be proposed.\n\nThe update. What is included?\n\n1. Unify pricing of WBTC based on a WBTC feed\nDiscussion\nhttps://governance.aave.com/t/wbtcs-and-others-pricing-mechanism-on-aave/10825/10\nFollowing the previous discussion and the outcome on Snapshot, the community decided to price WBTC based on a feed that properly prices the WBTC component and not just assumes that the price of WBTC is equal to BTC’s.\nThe proposal will swap the WBTC price feed on Aave v2 Ethereum from BTC/ETH to WBTC/ETH.\n\n2. Activate Price Oracle Sentinel on Aave v3 Optimism\nDiscussions\nN/A, just live in production on the instances where it was available\nAave v3 has a mechanism called “Price Oracle Sentinel” by which if the network infrastructure is down (mainly the sequencer on rollups), new borrowings and liquidations are not processed, and a grace period is given to the user to refill their positions and avoid liquidation.\nThis mechanism is part of Aave v3, but its activation depends on having an underlying oracle providing the “health check” of the network infrastructure.\nAave uses the L2 Sequencer Uptime Feeds for Arbitrum since day 0, but at that point, Optimism was not available.\nFollowing its introduction on Metis with the new deployment of Aave v3 there, now this proposal will activate its Price Oracle Sentinel on Optimism too.\n\n3. Generalized price sync components update, LSTs\nDiscussions\nhttps://governance.aave.com/t/bgd-generalised-price-sync-adapters/11416\nhttps://governance.aave.com/t/arfc-maticx-supply-cap-increase-polygon-v3/12657/5\nhttps://governance.aave.com/t/arfc-gauntlet-e-mode-methodology-aave-v3-liquid-staking-tokens/12700/6\nhttps://governance.aave.com/t/arfc-gauntlet-and-bgd-chainlink-synchronicity-price-adapter-2-0/13046\nWith the Generalized price sync solution already applied on multiple assets, in cases like Optimism and Arbitrum, when listing some assets like wstETH, not all underlying price feed components were available to “plug” into the adapter contract.\nAdditionally, before the risk teams evaluated better the risk associated with the pricing of LSTs it was not completely clear if the “primary market” exchange rate of the assets should be used. Both following discussions of the community, activation of withdrawals in some LSTs, and after checking with Gauntlet and Chaos Labs, seems legitimate to unify all pricing methods to use “official” (and non-manipulatable) exchange rates on all generalized price syncs.\nTo do that, the proposal will include the following specific changes:\n\nwstETH on both Optimism and Arbitrum will be priced based on a generalized price sync adapter using wstETH/ETH/USD composition.\nstMATIC and MATICX will be priced based on their on-chain exchange rates stMATIC/MATIC and MATICX/MATIC combined with MATIC/USD, also following an adapter approach. The stMATIC/MATIC and MATICX/MATIC exchange rates will be taken directly from the smart stMATIC and MATICX, as they are non-manipulatable.\nThe price feed of cbETH will be slightly changed. Currently, it already uses the generalized price sync adapter, with the underlying feeds being cbETH/ETH from Chainlink and ETH/USD. However, we are swapping the cbETH/ETH Chainlink component to use directly the rate from cbETH.\n\nNext steps\nGiven the operational nature of the proposal, we think it is more optimal to directly submit an on-chain governance proposal, and not create voting overhead.\nHowever, we target the governance proposal early next week, in order to get feedback from the community, if any.\n\n [TEMP CHECK] Aave V3 Deployment on Base\n\n [ARFC] Polygon v3 Supply Cap Update 2023.05.21\n\n [ARFC] Increase Supply Caps for LSTs on AAVE V3\n\n [ARFC] Optimism Mainnet Upgrade - Risk Considerations\n\n Governance Weekly Recap\n\n 10\n\n 3\n\n read \n\n 5\n min\n\n post by ChaosLabs on May 25, 2023\n\n ChaosLabs\n\n Thanks for putting forward this proposal @bgdlabs. We are in full support.\nAs we’ve written in our LSD Methodology Update, updating the pricing of LSDs to use the primary exchange rate, alongside implementing the price sync adapter, will decrease the likelihood of liquidations, paving the way for more aggressive risk parameters and caps, subject to the community’s risk appetite and desired level of exposure to the various LSDs.\n\n post by oneski22 on May 25, 2023\n\n oneski22\n\n Will the Price Oracle Sentinel activate be occurring before the Optimism Bedrock upgrade / downtime?\nGiven the sequencer will be offline for an undetermined period of time, it would be ideal to have that protection enabled prior to the upgrade window.\n\n post by bgdlabs on May 26, 2023\n\n bgdlabs\n\n Leader\n\n Correct, even considering governance timing, the Price Oracle Sentinel should be active before the scheduled 6th June of Bedrock.\nAlso from the Optimism documentation/communications, the estimation is 2-4h, which should not really create much risk for users, given the lack of correlation between assets’ price movements and the upgrade itself.\nStill, having the Price Oracle Sentinel will provide users with an extra buffer of time to improve their HF.\n\n post by bgdlabs on May 29, 2023\n\n bgdlabs\n\n Leader\n\n As an update for the community, after checking deeper into the usage of the on-chain exchange rate of cbETH, we think more time needs to be allocated to study its pricing dynamics. So the swap of the cbETH feed will not be included in this proposal.\n\nThe final items to be included are the previously announced:\n\nSwap to a WBTC/BTC/ETH feed on Aave v2 Ethereum for WBTC.\nEnable the Price Oracle Sentinel on Aave v3 Optimism.\n\nSwap the wstETH feeds on Optimism and Arbitrum to use a wstETH/ETH/USD price sync adapter. Important, the wstETH/ETH component by Chainlink doesn’t use the “primary market” rate, as it is not available on the L2s. But the swap to a price sync adapter is a net positive improvement.\nSwap the stMATIC and MATICx feeds on Aave v3 Polygon to use their on-chain exchange rates.\n\n [ARFC] Emode Risk Parameters Aave ETH V3 Pool Update\n\n post by MarcZeller on May 29, 2023\n\n MarcZeller\n\n We would like to thank BGD for this update that will allow the growth of strategic assets for the Aave DAO while maintaining the highest safety standards.\nwe will vote accordingly when the related AIP is published\n\nYAE2949×2780 1.06 MB\n\n post by bgdlabs on May 29, 2023\n\n bgdlabs\n\n Leader\n\n Following the plan of action, we have created Aave governance proposal 236 including the previous items.\nVoting will start in ~24h, participate !\nhttps://app.aave.com/governance/proposal/?proposalId=236\n\n post by Portkey on May 29, 2023\n\n Portkey\n\n Agreed, a huge thanks to BGD for their consistent innovation and upgrades. Most recently, the extra bit of relief provided by the CSPAs has been a personal highlight. I’m excited to see whats next.\n\n 15 days later\n\n post by bgdlabs on Jun 14, 2023\n\n bgdlabs\n\n Leader\n\n As a follow-up update, we will be submitting a governance proposal for the Operational oracles update PT2, which will contain the following:\n\nUpdate of the stETH feed on Aave v2 Ethereum to a 1:1 value with ETH, representing the “exchange rate” of the stETH rebasing token, following the strategy of pricing LSTs on “primary price”.\nUpdate of the Aave v3 Ethereum, Optimism and Arbitrum CSPA feeds to be composed with wstETH/stETH and ETH/USD internal feeds, removing an intermediate stETH/ETH that was introducing undesired exposure to stETH secondary market price. (props to @Gauntlet for this suggestion on L2s, where the stETH/ETH feed is not available).\n\nPending for a following update will be applying the same pricing mechanics for wstETH on Aave v3 Polygon, where the wstETH/stETH exchange rate feed is not available yet. We are coordinating with Chainlink to get it live.\n\n [ARFC] Chaos Labs Risk Stewards - Increase Supply Caps wstETH Arbitrum and Ethereum\n\n post by bgdlabs on Jun 19, 2023\n\n bgdlabs\n\n Leader\n\n Following our previous update, we have created an Aave governance proposal to update the price feeds of stETH on Aave v2 Ethereum, and wstETH on Aave v3 Ethereum, Arbitrum, and Optimism.\nVoting will start in ~24h, participate \nhttps://app.aave.com/governance/proposal/?proposalId=248\n\n post by Gauntlet on Jun 20, 2023\n\n Gauntlet\n\n Excited to see this update on chain! We’re looking forward to seeing the CL feed for Polygon as well.\n\n 12 days later\n\n post by bgdlabs on Jul 3, 2023\n\n bgdlabs\n\n Leader\n\n As a follow-up update, and most probably the last in this batch of price operational changes, we have a proposal to introduce the same type of adapter contract based on primary exchange rate for wstETH on Aave v3 Polygon.\nVoting will start in ~24h, participate \nhttps://app.aave.com/governance/proposal/?proposalId=262\n\n 4 months later\n\n post by bgdlabs on Oct 23, 2023\n\n bgdlabs\n\n Leader\n\n On the operational side of oracles, in order to keep consistency between Aave v3 and other legacy instances (v2, v2 AMM, v1), we will be creating a proposal to configure the deprecated fallback oracle address to address(0) on them.\nEven if we don’t recommend doing it in the current form, this doesn’t affect any improvement/re-activation of this mechanism in the future, as it will be possible to set it up again by calling setFallbackOracle().\n\n Technical maintenance proposals\n\n post by bgdlabs on Oct 23, 2023\n\n bgdlabs\n\n Leader\n\n We have published the on-chain governance proposal for the operational unification of fallback oracles on legacy versions of Aave.\nVoting will start in ~24h, and last for 3 days. Participate \nhttps://app.aave.com/governance/proposal/?proposalId=351\n\n 2 months later\n\n post by sleezyggg on Dec 18, 2023\n\n sleezyggg\n\n hey guys!\ni’ve had a question here. The recent arbitrum sequencer outage and subsequent action after was quite interesting to me and i’ve taken a look at a bunch of dApps and how they acted during this time.\nGot a question that is very specific for AAVe and @bgdlabs here. This update claims that on L2s like arbitrum the Price Oracle Sentinel are utilized, which incorporates Chainlinks L2 Sequencer Uptime Feed.\nWhen i check the respective contract however, the Arbitrum Sequencer Feed of chainlink wasn’t updated at all during this outage. If you read latestRoundData from the aggregator contract that chainlink links in their documentation, the last update is from the 17th of November 2022.\nCan someone enlighten me if i’m reading this wrong or if this completely malfunctioned and the L2 Sequencer Uptime feed was useless in protecting AAVE from the sequencer downtime in this instance?\n\n post by bgdlabs on Dec 18, 2023\n\n bgdlabs\n\n Leader\n\n Hello @sleezyggg. As you correctly point out, the Price Oracle Sentinel depends on Chainlink’s L2 Sequencer Uptime feed, and you are also correct that no downtime was triggered during the last days.\nFrom our investigation and communications with the Chainlink team, the reasons are the following:\n\nThe network was not “down” for a long time, but it had degraded performance due to important transactions load.\nThe L2 Sequencer has certain time sensitivity in the order of low minutes, to be in good equilibrium of precision while avoiding too many false positives. From point 1), as the total downtime was not really long, the oracle didn’t update.\nGenerally, the Price Oracle Sentinel (and more precisely the L2 Sequencer) is not a perfect mechanism, as it deals with a pretty complicated problems: which is the right entity to read a health check from? Or should a massive “queue” of pending transactions be considered downtime?\nCertainly there are ways of improving it, but not trivial.\n\nWe will also invite members of Chainlink to comment on the matter.\n\n post by sleezyggg on Dec 18, 2023\n\n sleezyggg\n\n Thanks for the quick answer. Would be quite interested in a comment from Chainlink here and what the justification is for not calling this downtime when even the Arbitrum Foundation is calling it an outage of nearly 90 minutes.\nWould also be good to know what Chainlink would consider an official sequencer outage, if it doesn’t line up with the definition of people running the sequencer.\n\n 16 days later\n\n post by sleezyggg on Jan 4, 2024\n\n sleezyggg\n\n @CL_Michael @bgdlabs wanted to check again, if there was ever a resolution to this or if its just gonna be left standing like this.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Technical maintenance proposals\n\n Development\n\n 131\n\n 25.9k\n\n Aug 6\n\n [ARFC] Oracle Deprecation for Long-tail Assets Across Aave V2 and V3\n\n Governance\n\n 3\n\n 527\n\n Aug 12\n\n LlamaRisk - Monthly Community Update\n\n Governance\n\n 28\n\n 3.4k\n\n 17h\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21","tokens":3382,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264795850,"hash":"837e46580723fefb0873315a06f2b027f58e8211"}
{"url":"https://ethresear.ch/t/native-proof-verification/24798","domain":"ethresear.ch","title":"Native proof verification - Sharding - Ethereum Research","text":"Native proof verification \n\n Sharding\n\n rollup\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 5\n\n 1 / 3\n\n May 5\n\n May 5\n\n post by donnoh on May 5\n\n donnoh\n\n Abstract\nThe overarching goal of this proposal is to massively derisk and simplify L2 bridges, and more generally any onchain application that verifies ZK proofs, by introducing a standard L1 primitive that any project can adopt in place of its bespoke onchain verifier stack. This is achieved through two changes:\n\nGeneralize EIP-8025 so the consensus-layer proof verification infrastructure becomes program-agnostic, not tied to EVM execution proofs.\nA new EIP that exposes it to smart contracts through a proof-carrying transaction type and three opcodes (PROGRAMHASH, PUBVALUESHASH, PROOFCOUNT).\n\nTogether, they let any project inherit L1’s proof verification infrastructure directly, with zkVM fixes shipping through client releases rather than per-project governance upgrades.\nMotivation\nToday, every Ethereum rollup maintains bespoke onchain proof verification infrastructure. ZK rollups deploy zkVM verifier contracts, adapter contracts, multi-proof dispatchers, and program whitelisting logic. Optimistic rollups ship their own onchain fraud-proof VMs (Arbitrum’s WAVM, Optimism’s Cannon MIPS machine) plus the surrounding dispute logic. In both cases every contract is maintained, patched, and upgraded independently in response to bugs in its specific proof system or VM, with each upgrade gated by a custom multisig or DAO. This is slow, risky, and duplicated across the ecosystem.\nEIP-8025 introduces zkVM proof verification on Ethereum’s consensus layer, but only for L1’s own purposes: verifying execution payloads to enable stateless and sublinear validation. Rollups still need their own onchain verifier contracts.\nHowever, the infrastructure that EIP-8025 brings to the CL, the ProofEngine, proof gossip, and verification logic, is not inherently L1-specific. If generalized to be program-agnostic and exposed to smart contracts via a new transaction type, any rollup, even non-EVM ones, could offload proof verification to the CL. When a zkVM implementation needs to be patched, Ethereum client teams release updated software the same way bugs in geth or Nethermind are fixed today: through client releases, without a hard fork. This is the same principle behind native rollups, but more generalized: just as native rollups inherit L1’s execution environment, native proof verification lets any rollup inherit L1’s proof verification infrastructure.\nAlthough this document frames the proposal around rollups, the same primitive serves any contract that verifies a ZK proof onchain: privacy systems, ZK coprocessors, identity, ZK ML, and others.\nHow rollups verify proofs today\nEach zkVM vendor provides a universal Solidity verifier contract (typically a Groth16 or Plonk check over BN254). The program identity and the public values (any inputs and outputs the circuit commits to) are passed alongside the proof. For SP1:\ninterface ISP1Verifier {\n function verifyProof(\n bytes32 programVKey, // program hash\n bytes calldata publicValues, // public values (inputs and/or outputs)\n bytes calldata proofBytes // the proof\n ) external view;\n}\n\nA note on terminology. SP1 calls programVKey a “verification key”, but this collides with the zkVM’s own circuit verification key. This document keeps them separate:\n\nProgram hash (called programVKey by SP1, imageId by Risc0): a bytes32 identifying a compiled guest program. Because each zkVM compiles differently (e.g. RV32IMA vs RV64IMA), it is per-(source, zkVM) pair. ERE expresses this as each backend’s zkVMVerifier::ProgramVk associated type (wrapping SP1VerifyingKey, Risc0’s Digest, etc.).\nVerification key: the zkVM’s circuit VK (polynomial commitments, domain parameters). Hardcoded as constants in onchain verifiers, one per zkVM version, shared across all programs.\n\nExample: Taiko (multi-verifier)\nTaiko illustrates the complexity that arises when a rollup uses multiple proof systems. Its verification architecture involves six contracts across three tiers (two raw verifiers, two adapters, one dispatcher, one SGX verifier), each independently maintained and upgraded through a custom multisig.\n1. Raw zkVM verifiers. Taiko deploys both an SP1 Plonk verifier (SP1Verifier.sol) and a Risc0 Groth16 verifier (RiscZeroGroth16Verifier.sol). These are the vendor-provided universal verifier contracts.\n2. Taiko-specific adapters. Each raw verifier is wrapped in an adapter contract that implements Taiko’s IVerifier interface:\n// TaikoSP1Verifier: adapter for SP1\ncontract TaikoSP1Verifier is IVerifier {\n address public sp1RemoteVerifier; // raw SP1 verifier\n mapping(bytes32 => bool) public isProgramTrusted; // whitelisted programs\n\n function verifyProof(Context[] calldata _ctxs, bytes calldata _proof) external view {\n bytes32 aggregationProgram = bytes32(_proof[:32]);\n bytes32 blockProvingProgram = bytes32(_proof[32:64]);\n require(isProgramTrusted[aggregationProgram]);\n require(isProgramTrusted[blockProvingProgram]);\n\n bytes memory publicInputs = buildPublicInputs(_ctxs);\n ISP1Verifier(sp1RemoteVerifier).verifyProof(\n aggregationProgram, publicInputs, _proof[64:]\n );\n }\n}\n\nA parallel Risc0Verifier has the same shape, with isImageTrusted replacing isProgramTrusted and sha256(buildPublicInputs(...)) as the journal digest.\n3. Multi-verifier dispatcher. A ComposeVerifier contract orchestrates multiple verifiers and enforces that a sufficient set has verified each proof:\ncontract MainnetVerifier is ComposeVerifier {\n address public immutable sgxGethVerifier; // SGX verifier (required)\n address public immutable risc0RethVerifier; // Risc0 option\n address public immutable sp1RethVerifier; // SP1 option\n\n function verifyProof(Context[] calldata _ctxs, bytes calldata _proof) external {\n SubProof[] memory subProofs = abi.decode(_proof, (SubProof[]));\n for (uint256 i = 0; i < subProofs.length; ++i) {\n IVerifier(subProofs[i].verifier).verifyProof(_ctxs, subProofs[i].proof);\n }\n require(areVerifiersSufficient(verifiers));\n }\n\n function areVerifiersSufficient(address[] memory _verifiers) internal view override {\n // Must have exactly 2: sgxGethVerifier + (risc0 or sp1)\n }\n}\n\nChanges to EIP-8025\nEIP-8025 introduces optional execution proofs for L1 block validation. The infrastructure it brings to the consensus layer (the ProofEngine, gossip, verification logic) is L1-specific only because its types are: ExecutionProof.public_input carries a new_payload_request_root: Root, and ProofType is a uint8 enumerating a small fixed set of accepted (client, zkVM) builds (see Lighthouse implementation):\n\nProofType\nGuest program\nzkVM backend\n\n0\nethrex\nRisc0\n\n1\nethrex\nSP1\n\n2\nethrex\nZisk\n\n3\nreth\nOpenVM\n\n4\nreth\nRisc0\n\n5\nreth\nSP1\n\n6\nreth\nZisk\n\nThis works while the set of guest programs is small and known in advance, but cannot accommodate arbitrary rollup programs.\nThis EIP adds a generic verification primitive alongside, leaving EIP-8025’s existing surface (ExecutionProof, ProofType, verify_execution_proof, notify_new_payload, notify_forkchoice_updated, process_execution_proof, request_proofs, ProofAttributes) untouched. The generalization mirrors ERE, whose zkVMVerifier trait is program-agnostic and specific guest programs are built on top. Following ERE’s design where the Compiler and the zkVMVerifier backend are independent traits, the new Proof container splits the conflated ProofType into two axes: a BackendType: uint8 that identifies only the zkVM backend, and a program_hash: Bytes32 that identifies the guest program (specific to a (guest program, zkVM) pair, see terminology note). The engine uses backend_type to select the circuit VK; program_hash is a public input to the circuit, checked alongside public_values during verification:\nclass ProofPublicInput(Container):\n program_hash: Bytes32\n public_values: ByteList[MAX_PUBLIC_VALUES_SIZE]\n\nclass Proof(Container):\n proof_data: ByteList[MAX_PROOF_SIZE]\n backend_type: BackendType\n public_input: ProofPublicInput\n\ndef verify_proof(self: ProofEngine, proof: Proof) -> bool: ...\n\nEIP-8025’s verify_execution_proof can be reimplemented as a thin wrapper over verify_proof for code sharing, with no observable change at the gossip layer:\ndef verify_execution_proof(self: ProofEngine, ep: ExecutionProof) -> bool:\n backend_type, program_hash = self.resolve_proof_type(ep.proof_type)\n expected_public_values = serialize_stateless_output(StatelessValidationResult(\n new_payload_request_root=ep.public_input.new_payload_request_root,\n successful_validation=True,\n chain_config=self.chain_config,\n ))\n return self.verify_proof(Proof(\n proof_data=ep.proof_data,\n backend_type=backend_type,\n public_input=ProofPublicInput(\n program_hash=program_hash,\n public_values=expected_public_values,\n ),\n ))\n\nThe byte-level layout of serialize_stateless_output over StatelessValidationResult is shown in Impact on native rollups, since native-rollup contracts reconstruct it onchain. Block validity remains decoupled from proof verification; the honest prover guide is unchanged. Sidecar-arrived proofs (proof-carrying transactions, see Proof propagation) go through verify_proof directly, without the L1 wrapper.\nProgram hash stability (open problem)\nNative proof verification’s “fixes ship through client releases, nothing onchain changes” property depends on one non-trivial requirement: the program_hash pinned onchain must remain stable across zkVM patches. If any patch moves the hash, rollups that pinned the old value are bricked unless they upgrade, and the upgrade story collapses back onto onchain governance.\nNo zkVM today delivers this directly. Both leading candidates fingerprint artifacts that change under normal SDK / dependency / toolchain churn, not just circuit-layer fixes:\n\nRisc0’s imageId is a SHA-256 over SystemState { pc: 0, merkle_root } with merkle_root a Poseidon2 merkle root of the initial memory image, which contains both the user ELF and the kernel ELF (binfmt/src/elf.rs#L435). The memory image captures the exact compiled bytes, so a dep bump, toolchain update, or kernel patch all change imageId even when STF semantics are unchanged.\nSP1’s programVKey is a Poseidon2 over (preprocessed_commit, pc_start, ...) (hypercube/src/verifier/hashable_key.rs#L107). Unlike Risc0’s imageId (a pure hash of compiled bytes), the SP1 vk is a byproduct of running circuit setup over the ELF: preprocessed_commit is the AIR’s preprocessing commitment and pc_start comes from the linker, so circuit changes, SDK bumps, and toolchain changes all move it, even when the user’s guest source is byte-identical.\n\nUsing either directly as the onchain program_hash would make every zkVM release a rollup-visible event.\nThe realistic path is an indirection layer: the onchain program_hash is a stable, rollup-chosen identifier and the public input to the proof, while the zkVM-internal identifier is a private input, maintained by clients and free to change with every release. The proof must attest that the two are linked, so that the stable program_hash genuinely commits to what was executed. The exact mechanism is an open design question.\nNative rollups using the NATIVE_PROGRAM sentinel sidestep this entirely: the sentinel just says “whatever L1 currently accepts”, and the accepted set is itself a client-side artifact that updates with zkVM releases.\nNew EIP: Proof-carrying transactions\nTransaction format\nTransactionType: PROOF_TX_TYPE\n\nTransactionPayloadBody:\n[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,\n to, value, data, access_list, max_fee_per_blob_gas,\n blob_versioned_hashes, proofs, public_values_hash,\n y_parity, r, s]\n\nWhere:\n\nproofs: a list of (program_hash, backend_type) pairs. Each program_hash is a bytes32 identifying the guest program for that specific zkVM backend (see terminology note). Each backend_type is a uint8 and MUST be unique within the list, since two proofs from the same backend add no security. The length of this list determines proof_count.\npublic_values_hash: a bytes32 hash of the program’s public output (shared across all proofs, since all backends prove the same statement).\n\nThe CL-level Proof carries the raw public_values bytes; the transaction body (and the PUBVALUESHASH opcode) only expose their hash. The contract reconstructs the expected bytes and compares hashes. Two invariants tie the two views together (checked by any node that handles the sidecar, on mempool propagation and again by the builder when assembling the block):\n\nsidecar[i].public_input.program_hash == proofs[i].program_hash and sidecar[i].backend_type == proofs[i].backend_type.\nsha256(sidecar[i].public_input.public_values) == public_values_hash.\n\nThese bind the EVM-visible identifiers (proofs[i].program_hash, public_values_hash) to the underlying Proof objects passed to verify_proof. See Proof propagation for how proofs reach the builder and how the L1 block proof covers them.\nOpcodes\nNew opcodes read the proof-carrying transaction’s fields and return zero for non-proof-carrying transactions.\n\nOpcode\nInput\nOutput\nDescription\n\nPROGRAMHASH\nindex\nprogram_hash (bytes32)\nProgram hash for the i-th proof. Indexed like BLOBHASH; returns bytes32(0) if index >= PROOFCOUNT()\n\nPUBVALUESHASH\nnone\npublic_values_hash (bytes32)\nHash of the program’s public output (shared across all proofs)\n\nPROOFCOUNT\nnone\nproof_count (uint8)\nLength of the transaction’s proofs list\n\nA custom rollup iterates with PROOFCOUNT() and checks each PROGRAMHASH(i) against its own whitelist.\nFor native rollups, PROGRAMHASH(i) returns a well-known sentinel value (e.g. bytes32(1)) when the i-th proof uses a program that L1 currently accepts for its own EVM execution proofs. This way the contract checks PROGRAMHASH(i) == NATIVE_PROGRAM without storing specific per-zkVM hashes, and automatically follows L1 upgrades shipped in client releases.\nMulti-proof\nThe proofs list lets each rollup pick its own security/cost trade-off: [(hash, SP1)] is a single proof, [(hash_sp1, SP1), (hash_risc0, Risc0)] requires the same statement to be independently proven by both before the CL accepts the transaction. The contract reads PROOFCOUNT() and enforces its own minimum.\nThis replaces contract-level multi-proof orchestration (like Taiko’s ComposeVerifier requiring both SGX and a ZK verifier) with a protocol-level mechanism. Because proofs is in the signed transaction body, it cannot be tampered with.\nProof propagation\nThe proof must reach a builder through the mempool, but needs no long-term availability. The proposed approach is an ephemeral sidecar: the proof travels alongside the transaction like an EIP-4844 blob sidecar. Mempool nodes and the builder run each sidecar entry through verify_proof (and check the invariants from Transaction format) before forwarding or including the transaction. The builder then strips the sidecar before block inclusion, folds it into the recursive L1 block proof, and discards it. Validators see only the transaction body (the proofs list and public_values_hash) plus the L1 block proof; they never need the raw proof bytes. The L1 block proof thus recursively covers every proof-carrying transaction in the block (post-quantum proofs may be large enough that L1 is limited to one proof per slot).\nSize. EIP-8025 sets MAX_PROOF_SIZE = 400 KiB per proof. The spec doesn’t bound len(proofs), but mempool client size limits make 2–3 a practical ceiling.\nImpact on existing rollups\nThe table below reports Solidity SLOC (non-blank, non-comment source lines) for each project’s onchain contracts, split between “core” rollup logic and the proof verification stack that native proof verification would retire.\n\nProject\nProof system\nCore SLOC\nRetired SLOC\n% retired\n\nArbitrum\nOptimistic, WASM VM\n19,034\n8,181\n43.0%\n\nBase\nOptimistic, MIPS VM\n17,426\n8,907\n51.1%\n\nZKsync Era\nValidity, EraVM\n10,823\n2,379\n22.0%\n\nLinea\nValidity, direct EVM\n8,111\n2,460\n30.3%\n\nLighter\nValidity, no VM (custom circuits)\n5,417\n1,699\n31.4%\n\nTotal\n\n60,811\n23,626\n38.9%\n\nThese numbers are rough estimates. They cover only on-chain Solidity code and exclude off-chain provers, sequencers, and the guest program behind each program_hash. Governance surfaces (multisigs, timelocks, DAO contracts, proxy admins), partner-specific bridges, and proxy boilerplate are excluded from both columns.\nTaiko’s six-contract multi-verifier stack collapses into a single inbox contract:\ncontract TaikoInbox {\n mapping(bytes32 => bool) public isTrustedProgram; // whitelisted per-zkVM program hashes\n uint256 public minProofCount; // multi-proof threshold (e.g. 2)\n\n function proveBatches(\n BatchMetadata[] calldata metas,\n Transition[] calldata trans\n // _proof parameter removed: verified by the CL\n ) external {\n // Verify all proofs used trusted programs.\n require(PROOFCOUNT() >= minProofCount, \"insufficient proofs\");\n for (uint256 i = 0; i < PROOFCOUNT(); i++) {\n require(isTrustedProgram[PROGRAMHASH(i)], \"untrusted program\");\n }\n\n bytes memory publicInputs = buildPublicInputs(metas, trans);\n require(PUBVALUESHASH() == sha256(publicInputs), \"wrong public values\");\n\n // Accept the batches.\n ...\n }\n}\n\nA single isTrustedProgram whitelist replaces both isProgramTrusted (SP1) and isImageTrusted (Risc0); minProofCount replaces areVerifiersSufficient.\nImpact on native rollups\nThe NativeRollup contract from the native rollup’s ZK specification uses the same pattern. Instead of PROOFROOT against a validation_result_root, it checks PROGRAMHASH, PUBVALUESHASH, and PROOFCOUNT:\nbytes32 constant NATIVE_PROGRAM = bytes32(uint256(1));\nuint256 public minProofCount;\n\nfunction advance(BlockParams calldata params) external {\n bytes32 l1Anchor = blockhash(block.number - 1);\n\n bytes32 npRoot = computeNewPayloadRequestRoot(\n blockHash, params.feeRecipient, params.stateRoot,\n // ... remaining fields ...\n getVersionedHashes(params.payloadBlobCount),\n l1Anchor, bytes32(0)\n );\n\n // SSZ-encode the StatelessValidationResult container:\n // new_payload_request_root (32 bytes) || successful_validation (1 byte)\n // || chain_id (8 bytes, little-endian).\n // Must match serialize_stateless_output() in execution-specs.\n bytes memory expectedPublicValues = SSZ.encodeStatelessValidationResult(\n npRoot, true, chainId\n );\n bytes32 expectedPubValuesHash = sha256(expectedPublicValues);\n\n require(PROOFCOUNT() >= minProofCount, \"insufficient proofs\");\n for (uint256 i = 0; i < PROOFCOUNT(); i++) {\n require(PROGRAMHASH(i) == NATIVE_PROGRAM, \"not a native program\");\n }\n require(PUBVALUESHASH() == expectedPubValuesHash, \"wrong public values\");\n\n blockHash = params.blockHash;\n stateRoot = params.stateRoot;\n blockNumber = blockNumber + 1;\n stateRootHistory[blockNumber] = params.stateRoot;\n}\n\nA native rollup is simply one whose programHash matches what L1 itself accepts; an L1 upgrade (e.g. a fork changing verify_stateless_new_payload) propagates automatically. Rollups with custom VMs use the same pattern with a different programHash.\n\n read \n\n 7\n min\n\n post by thegaram33 on May 5\n\n post by tamirhemo on May 5\n\n Powered by Discourse","tokens":4771,"squid":"ink-research","role":"Deep Scholar","at":1791264800520,"hash":"8ae20f453842cb038a8d8811cc9f0fea4247615e"}
{"url":"https://ethereum.org/en/developers/","domain":"ethereum.org","title":"Ethereum Developer Resources | ethereum.org","text":"What do you want to build today?Everything you need to learn and build your first apps on EthereumBeginnerTokenizationCreate a unique token to learn the basics of Scaffold-ETH 2.Start quest (opens in a new tab)IntermediateDEXBuild a simple automated market maker, provide liquidity, and implement token swaps.Start quest (opens in a new tab)AdvancedStablecoinsBuild a stablecoin and learn stability mechanisms and price oracles.Start quest (opens in a new tab)Challenges and mentorshipReceive mentorship from others, and learn how to collaborate with fellow developers.SpeedRun Ethereum (opens in a new tab)BeginnerTokenizationCreate a unique token to learn the basics of Scaffold-ETH 2.Start quest link-external-assistive-textIntermediateDEXBuild a simple automated market maker, provide liquidity, and implement token swaps.Start quest link-external-assistive-textAdvancedStablecoinsBuild a stablecoin and learn stability mechanisms and price oracles.Start quest link-external-assistive-textChallenges and mentorshipReceive mentorship from others, and learn how to collaborate with fellow developers.SpeedRun Ethereum link-external-assistive-textGet paid well. Stay remote. Build the future.Over half of blockchain careers are remote-first with some estimates putting the number as high as 70%.$93 - 169KAvg developer salary $80 - 255KAvg salary in blockchain industry Money you can programWrite code that defines how value moves, when, and to whom. No banks, no intermediaries, just logic you define.Future-proof skillsLearn the building blocks of the next internet. The tech might evolve, but the principles of web3 are here to stay.Censorship resistanceBuild projects and commerce that can't be silenced by governments, corporations, or algorithms. If it matters, it stays online.Digital sovereigntyOwn your identity, assets, and creations online without relying on platforms that can delete you.Build onchain with agentsStructured Ethereum knowledge for the agentic stack. Give your AI agent the context it needs to read state, send transactions, and coordinate with protocols, without leaving the model's context window.$ launch a coin for my communit█Build with ethskills (opens in a new tab)Helpful developer resourcesQuickstart your ideaBootstrap your Ethereum app stack in seconds. Read Scaffold-ETH 2 (opens in a new tab)npx create-eth@latestScaffold-ETH 2 llms-full.txt (opens in a new tab)Get helpIf you are stuck or need help solving problems, be sure to ask for guidance.Stack Exchange (opens in a new tab)ResourcesWant to experiment first, ask questions later? Check sandboxes, bootcamps etc.Play with codeTutorialsLearn Ethereum development step-by-step from builders who have already done it.View tutorialsVideo coursesWant to kickstart your professional career in blockchain? These courses will prepare you to get hired as blockchain developer.3-hour courseBlockchain basicsLearn how blockchains and smart contracts work, create a wallet, and sign your first transaction. (opens in a new tab)5-hour courseSolidity smart contract developmentSolidity Programming is your gateway to web3 development in Ethereum compatible ecosystems. (opens in a new tab)10-hour courseFoundry fundamentalsLevel up your Solidity development skills with Foundry and advanced web3 development concepts and tools. (opens in a new tab)13-hour courseAdvanced foundryMaster web3 development techniques with Advanced Foundry for Solidity smart contract development. (opens in a new tab)24-hour courseSmart contract securityStart your career as a smart contract security researcher! Learn smart contract auditing and the best practices. (opens in a new tab)3-hour courseBlockchain basicsLearn how blockchains and smart contracts work, create a wallet, and sign your first transaction. link-external-assistive-text5-hour courseSolidity smart contract developmentSolidity Programming is your gateway to web3 development in Ethereum compatible ecosystems. link-external-assistive-text10-hour courseFoundry fundamentalsLevel up your Solidity development skills with Foundry and advanced web3 development concepts and tools. link-external-assistive-text13-hour courseAdvanced foundryMaster web3 development techniques with Advanced Foundry for Solidity smart contract development. link-external-assistive-text24-hour courseSmart contract securityStart your career as a smart contract security researcher! Learn smart contract auditing and the best practices. link-external-assistive-textBuilder updatesInsights on the latest Ethereum builder resources, tools, and developments.The next great wallet will be privateElliott AlexanderYour wallet sees every address you hold, every dApp you connect to, and every request you make. That same position lets it protect all of it. A practical look at the privacy tools, defaults, and unshipped ideas that will define the next generation of Ethereum wallets.July 2, 2026How to build privacy apps on Ethereum with zero-knowledge proofsPhilip Krause · EF Builder GrowthOne reusable pattern powers anonymous voting, mixers, airdrops, and membership systems on Ethereum. Learn the commitment-nullifier-proof cycle and how zero-knowledge tooling makes it practical to build today.May 12, 2026Why build on EthereumPhilip Krause · EF Builder GrowthDecentralization, censorship resistance, permissionless deployment, and composability are not separate selling points. They reinforce each other. A practical guide to why builders should choose Ethereum.May 12, 2026View all updatesExplore the documentationUnderstand the core concepts of Ethereum and blockchainsIntroductionsIntro to EthereumAn introduction to blockchain and EthereumIntro to EtherAn introduction to cryptocurrency and EtherIntro to dappsAn introduction to decentralized applicationsIntro to the stackAn introduction to the Ethereum stackWeb2 vs Web3How the web3 world of development is differentProgramming languagesUsing Ethereum with familiar languagesFundamentalsAccountsContracts or people on the networkTransactionsThe way Ethereum state changesBlocksBatches of transactions added to the blockchainThe Ethereum virtual machine (EVM)The computer that processes transactionsGasEther needed to power transactionsNodes and clientsHow blocks and transactions are verified in the networkNetworksAn overview of Mainnet and the test networksThe stackSmart contractsThe logic behind dapps – self-executing agreementsDevelopment frameworksTools for helping speed up developmentJavaScript librariesUsing JavaScript to interact with smart contractsBackend APIsUsing libraries to interact with smart contractsBlock explorersYour portal to Ethereum dataSmart contract securitySecurity measures to consider during development of smart contractsStorageHow to handle dapp storageDevelopment environmentsIDEs that are suitable for dapp developmentJoin hackathonsHackathons are great opportunities to network and learn from others as well as start projects and earn prizesParadigm FrontiersOct 12 – 14, 2026San Francisco, United States (opens in a new tab)Devcon IndiaNov 3 – 6, 2026Mumbai, India (opens in a new tab)ETHGlobal MumbaiNov 5 – 7, 2026Mumbai, India (opens in a new tab)Visit EthGlobal (opens in a new tab)Are you a founder?Have a project idea already or working on a prototype? Explore how to take your project to the next step. We can connect you with relevant organizations and experts in the field.Get in touch (opens email client)See grant options","tokens":1859,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264803581,"hash":"eb85accd0614f419eee26681185cf51bdac56510"}
{"url":"https://governance.aave.com/t/bgd-operational-oracles-update/13213","domain":"governance.aave.com","title":"BGD. Operational oracles update - Development - Aave","text":"BGD. Operational oracles update \n\n Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 10\n\n 3\n\n read \n\n 5\n min\n\n TL;DR\n\n Context\n\n The update. What is included?\n\n 1. Unify pricing of WBTC based on a WBTC feed\n\n 2. Activate Price Oracle Sentinel on Aave v3 Optimism\n\n 3. Generalized price sync components update, LSTs\n\n Next steps\n\n May 2023\n\n 1 / 18\n\n May 2023\n\n Jan 2024\n\n post by bgdlabs on May 25, 2023\n\n bgdlabs\n\n Leader\n\n TL;DR\nPresent to the community our proposal to do an operational update of different oracle aspects, for the sake of consistency across instances of Aave.\n\nContext\nGiven limitations on for example the availability of price feeds, or changes in community strategies of assets’ pricing, sometimes it is necessary to have purely operational proposals to align all Aave components.\nIn order to not create a big overhead, we have decided to batch some of these required updates, and before going forward with an on-chain proposal, we want to transparently present to the community what will be proposed.\n\nThe update. What is included?\n\n1. Unify pricing of WBTC based on a WBTC feed\nDiscussion\nhttps://governance.aave.com/t/wbtcs-and-others-pricing-mechanism-on-aave/10825/10\nFollowing the previous discussion and the outcome on Snapshot, the community decided to price WBTC based on a feed that properly prices the WBTC component and not just assumes that the price of WBTC is equal to BTC’s.\nThe proposal will swap the WBTC price feed on Aave v2 Ethereum from BTC/ETH to WBTC/ETH.\n\n2. Activate Price Oracle Sentinel on Aave v3 Optimism\nDiscussions\nN/A, just live in production on the instances where it was available\nAave v3 has a mechanism called “Price Oracle Sentinel” by which if the network infrastructure is down (mainly the sequencer on rollups), new borrowings and liquidations are not processed, and a grace period is given to the user to refill their positions and avoid liquidation.\nThis mechanism is part of Aave v3, but its activation depends on having an underlying oracle providing the “health check” of the network infrastructure.\nAave uses the L2 Sequencer Uptime Feeds for Arbitrum since day 0, but at that point, Optimism was not available.\nFollowing its introduction on Metis with the new deployment of Aave v3 there, now this proposal will activate its Price Oracle Sentinel on Optimism too.\n\n3. Generalized price sync components update, LSTs\nDiscussions\nhttps://governance.aave.com/t/bgd-generalised-price-sync-adapters/11416\nhttps://governance.aave.com/t/arfc-maticx-supply-cap-increase-polygon-v3/12657/5\nhttps://governance.aave.com/t/arfc-gauntlet-e-mode-methodology-aave-v3-liquid-staking-tokens/12700/6\nhttps://governance.aave.com/t/arfc-gauntlet-and-bgd-chainlink-synchronicity-price-adapter-2-0/13046\nWith the Generalized price sync solution already applied on multiple assets, in cases like Optimism and Arbitrum, when listing some assets like wstETH, not all underlying price feed components were available to “plug” into the adapter contract.\nAdditionally, before the risk teams evaluated better the risk associated with the pricing of LSTs it was not completely clear if the “primary market” exchange rate of the assets should be used. Both following discussions of the community, activation of withdrawals in some LSTs, and after checking with Gauntlet and Chaos Labs, seems legitimate to unify all pricing methods to use “official” (and non-manipulatable) exchange rates on all generalized price syncs.\nTo do that, the proposal will include the following specific changes:\n\nwstETH on both Optimism and Arbitrum will be priced based on a generalized price sync adapter using wstETH/ETH/USD composition.\nstMATIC and MATICX will be priced based on their on-chain exchange rates stMATIC/MATIC and MATICX/MATIC combined with MATIC/USD, also following an adapter approach. The stMATIC/MATIC and MATICX/MATIC exchange rates will be taken directly from the smart stMATIC and MATICX, as they are non-manipulatable.\nThe price feed of cbETH will be slightly changed. Currently, it already uses the generalized price sync adapter, with the underlying feeds being cbETH/ETH from Chainlink and ETH/USD. However, we are swapping the cbETH/ETH Chainlink component to use directly the rate from cbETH.\n\nNext steps\nGiven the operational nature of the proposal, we think it is more optimal to directly submit an on-chain governance proposal, and not create voting overhead.\nHowever, we target the governance proposal early next week, in order to get feedback from the community, if any.\n\n [TEMP CHECK] Aave V3 Deployment on Base\n\n [ARFC] Polygon v3 Supply Cap Update 2023.05.21\n\n [ARFC] Increase Supply Caps for LSTs on AAVE V3\n\n [ARFC] Optimism Mainnet Upgrade - Risk Considerations\n\n Governance Weekly Recap\n\n 10\n\n 3\n\n read \n\n 5\n min\n\n post by ChaosLabs on May 25, 2023\n\n ChaosLabs\n\n Thanks for putting forward this proposal @bgdlabs. We are in full support.\nAs we’ve written in our LSD Methodology Update, updating the pricing of LSDs to use the primary exchange rate, alongside implementing the price sync adapter, will decrease the likelihood of liquidations, paving the way for more aggressive risk parameters and caps, subject to the community’s risk appetite and desired level of exposure to the various LSDs.\n\n post by oneski22 on May 25, 2023\n\n oneski22\n\n Will the Price Oracle Sentinel activate be occurring before the Optimism Bedrock upgrade / downtime?\nGiven the sequencer will be offline for an undetermined period of time, it would be ideal to have that protection enabled prior to the upgrade window.\n\n post by bgdlabs on May 26, 2023\n\n bgdlabs\n\n Leader\n\n Correct, even considering governance timing, the Price Oracle Sentinel should be active before the scheduled 6th June of Bedrock.\nAlso from the Optimism documentation/communications, the estimation is 2-4h, which should not really create much risk for users, given the lack of correlation between assets’ price movements and the upgrade itself.\nStill, having the Price Oracle Sentinel will provide users with an extra buffer of time to improve their HF.\n\n post by bgdlabs on May 29, 2023\n\n bgdlabs\n\n Leader\n\n As an update for the community, after checking deeper into the usage of the on-chain exchange rate of cbETH, we think more time needs to be allocated to study its pricing dynamics. So the swap of the cbETH feed will not be included in this proposal.\n\nThe final items to be included are the previously announced:\n\nSwap to a WBTC/BTC/ETH feed on Aave v2 Ethereum for WBTC.\nEnable the Price Oracle Sentinel on Aave v3 Optimism.\n\nSwap the wstETH feeds on Optimism and Arbitrum to use a wstETH/ETH/USD price sync adapter. Important, the wstETH/ETH component by Chainlink doesn’t use the “primary market” rate, as it is not available on the L2s. But the swap to a price sync adapter is a net positive improvement.\nSwap the stMATIC and MATICx feeds on Aave v3 Polygon to use their on-chain exchange rates.\n\n [ARFC] Emode Risk Parameters Aave ETH V3 Pool Update\n\n post by MarcZeller on May 29, 2023\n\n MarcZeller\n\n We would like to thank BGD for this update that will allow the growth of strategic assets for the Aave DAO while maintaining the highest safety standards.\nwe will vote accordingly when the related AIP is published\n\nYAE2949×2780 1.06 MB\n\n post by bgdlabs on May 29, 2023\n\n bgdlabs\n\n Leader\n\n Following the plan of action, we have created Aave governance proposal 236 including the previous items.\nVoting will start in ~24h, participate !\nhttps://app.aave.com/governance/proposal/?proposalId=236\n\n post by Portkey on May 29, 2023\n\n Portkey\n\n Agreed, a huge thanks to BGD for their consistent innovation and upgrades. Most recently, the extra bit of relief provided by the CSPAs has been a personal highlight. I’m excited to see whats next.\n\n 15 days later\n\n post by bgdlabs on Jun 14, 2023\n\n bgdlabs\n\n Leader\n\n As a follow-up update, we will be submitting a governance proposal for the Operational oracles update PT2, which will contain the following:\n\nUpdate of the stETH feed on Aave v2 Ethereum to a 1:1 value with ETH, representing the “exchange rate” of the stETH rebasing token, following the strategy of pricing LSTs on “primary price”.\nUpdate of the Aave v3 Ethereum, Optimism and Arbitrum CSPA feeds to be composed with wstETH/stETH and ETH/USD internal feeds, removing an intermediate stETH/ETH that was introducing undesired exposure to stETH secondary market price. (props to @Gauntlet for this suggestion on L2s, where the stETH/ETH feed is not available).\n\nPending for a following update will be applying the same pricing mechanics for wstETH on Aave v3 Polygon, where the wstETH/stETH exchange rate feed is not available yet. We are coordinating with Chainlink to get it live.\n\n [ARFC] Chaos Labs Risk Stewards - Increase Supply Caps wstETH Arbitrum and Ethereum\n\n post by bgdlabs on Jun 19, 2023\n\n bgdlabs\n\n Leader\n\n Following our previous update, we have created an Aave governance proposal to update the price feeds of stETH on Aave v2 Ethereum, and wstETH on Aave v3 Ethereum, Arbitrum, and Optimism.\nVoting will start in ~24h, participate \nhttps://app.aave.com/governance/proposal/?proposalId=248\n\n post by Gauntlet on Jun 20, 2023\n\n Gauntlet\n\n Excited to see this update on chain! We’re looking forward to seeing the CL feed for Polygon as well.\n\n 12 days later\n\n post by bgdlabs on Jul 3, 2023\n\n bgdlabs\n\n Leader\n\n As a follow-up update, and most probably the last in this batch of price operational changes, we have a proposal to introduce the same type of adapter contract based on primary exchange rate for wstETH on Aave v3 Polygon.\nVoting will start in ~24h, participate \nhttps://app.aave.com/governance/proposal/?proposalId=262\n\n 4 months later\n\n post by bgdlabs on Oct 23, 2023\n\n bgdlabs\n\n Leader\n\n On the operational side of oracles, in order to keep consistency between Aave v3 and other legacy instances (v2, v2 AMM, v1), we will be creating a proposal to configure the deprecated fallback oracle address to address(0) on them.\nEven if we don’t recommend doing it in the current form, this doesn’t affect any improvement/re-activation of this mechanism in the future, as it will be possible to set it up again by calling setFallbackOracle().\n\n Technical maintenance proposals\n\n post by bgdlabs on Oct 23, 2023\n\n bgdlabs\n\n Leader\n\n We have published the on-chain governance proposal for the operational unification of fallback oracles on legacy versions of Aave.\nVoting will start in ~24h, and last for 3 days. Participate \nhttps://app.aave.com/governance/proposal/?proposalId=351\n\n 2 months later\n\n post by sleezyggg on Dec 18, 2023\n\n sleezyggg\n\n hey guys!\ni’ve had a question here. The recent arbitrum sequencer outage and subsequent action after was quite interesting to me and i’ve taken a look at a bunch of dApps and how they acted during this time.\nGot a question that is very specific for AAVe and @bgdlabs here. This update claims that on L2s like arbitrum the Price Oracle Sentinel are utilized, which incorporates Chainlinks L2 Sequencer Uptime Feed.\nWhen i check the respective contract however, the Arbitrum Sequencer Feed of chainlink wasn’t updated at all during this outage. If you read latestRoundData from the aggregator contract that chainlink links in their documentation, the last update is from the 17th of November 2022.\nCan someone enlighten me if i’m reading this wrong or if this completely malfunctioned and the L2 Sequencer Uptime feed was useless in protecting AAVE from the sequencer downtime in this instance?\n\n post by bgdlabs on Dec 18, 2023\n\n bgdlabs\n\n Leader\n\n Hello @sleezyggg. As you correctly point out, the Price Oracle Sentinel depends on Chainlink’s L2 Sequencer Uptime feed, and you are also correct that no downtime was triggered during the last days.\nFrom our investigation and communications with the Chainlink team, the reasons are the following:\n\nThe network was not “down” for a long time, but it had degraded performance due to important transactions load.\nThe L2 Sequencer has certain time sensitivity in the order of low minutes, to be in good equilibrium of precision while avoiding too many false positives. From point 1), as the total downtime was not really long, the oracle didn’t update.\nGenerally, the Price Oracle Sentinel (and more precisely the L2 Sequencer) is not a perfect mechanism, as it deals with a pretty complicated problems: which is the right entity to read a health check from? Or should a massive “queue” of pending transactions be considered downtime?\nCertainly there are ways of improving it, but not trivial.\n\nWe will also invite members of Chainlink to comment on the matter.\n\n post by sleezyggg on Dec 18, 2023\n\n sleezyggg\n\n Thanks for the quick answer. Would be quite interested in a comment from Chainlink here and what the justification is for not calling this downtime when even the Arbitrum Foundation is calling it an outage of nearly 90 minutes.\nWould also be good to know what Chainlink would consider an official sequencer outage, if it doesn’t line up with the definition of people running the sequencer.\n\n 16 days later\n\n post by sleezyggg on Jan 4, 2024\n\n sleezyggg\n\n @CL_Michael @bgdlabs wanted to check again, if there was ever a resolution to this or if its just gonna be left standing like this.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Technical maintenance proposals\n\n Development\n\n 131\n\n 25.9k\n\n Aug 6\n\n [ARFC] Oracle Deprecation for Long-tail Assets Across Aave V2 and V3\n\n Governance\n\n 3\n\n 527\n\n Aug 12\n\n LlamaRisk - Monthly Community Update\n\n Governance\n\n 28\n\n 3.4k\n\n 17h\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21","tokens":3445,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264808251,"hash":"4d22e8f99010fc925238fa61c36f4ef6592dc425"}
{"url":"https://forum.soliditylang.org/t/size-limit-of-array-mapping-on-bnb-smart-chain-scalability-question/3700/1","domain":"forum.soliditylang.org","title":"Size limit of Array/Mapping on BNB Smart Chain (Scalability Question) - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question) \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 17\n\n 1 / 2\n\n Apr 17\n\n Apr 18\n\n post by ziaahmedshaikh on Apr 17\n\n ziaahmedshaikh\n\n Hi,\nI am going to deploy my contract on BNB Smart Chain and I want to ask a scalability related question, i have a struct something similar like following code:\nstruct Purchases{ \n\n uint32 itemId; \n\n uint32 amount; \n\n uint48 time; \n\n }\n\nand trying to manage purchase history through mapping as follows\n mapping(uint256 => Purchases\\[\\]) public purchaseHistory;\n\n// each UserID is mapped to an Array of his Purchases to manage User’s Purchase History.\nI am assuming that purchaseHistory will be incremented in 1000s every day, my questions are follows:\nHow much data can be stored in mapping like purchaseHistory array for each UserID ?\nWill contract explode after some time ?\nFor retrival, we will use pagginated function that will return purchase of user 10 items per page only.\nwill it be workable in long run or can the contract stop function after the array grows to many 1000s of records ?\nRegards. & will very much appreciate the reply.\n\n post by cameel on Apr 18\n\n cameel\n\n Solidity Compiler Team\n\nHow much data can be stored in mapping like purchaseHistory array for each UserID ?\n\nStorage space is at a premium so the compiler tries to pack things for you as much a possible. There is very little overhead here. The mapping itself takes only as much space as its content. Each dynamic array takes a single slot for length and then just the items. Check Layout of State Variables in Storage and Transient Storage for details.\nOne thing to potentially change here in case you want to minimize the total use of storage could be to use a struct of arrays rather than an array of structs. A struct always takes the whole slot, while value types can be packed. This would have the extra overhead of 2 size slots for the arrays but given that you expect thousands of items in each array and items are very short, much more space is wasted on padding between items. The downside is that it would make reads more expensive - you’d need to access 3 slots instead of 1 to get a complete set of information for one purchase - but again, if you’re reading 10 subsequent items at a time you can amortize the storage access cost by reading more than one at a time.\n\nWill contract explode after some time ?\n\nThe only hard limit on how much data you can store per mapping item is the size of storage, so for all practical purposes it’s pretty much infinite. There’s a soft limit of 2^64 32-byte slots, where the compiler starts to assume that the risk of collisions between mapping items stops being negligible, but that’s still not something you’ll easily reach before running into all kinds of other scaling problems.\nWhile writing thousands of slots per day could add up to something quite expensive, as long as it’s not all in a single transaction, but rather spread over multiple users and transactions, it’s not an issue.\n\nFor retrival, we will use pagginated function that will return purchase of user 10 items per page only.\nwill it be workable in long run or can the contract stop function after the array grows to many 1000s of records ?\n\nAssuming that you want to get the data to display it for the user or for some off-chain processing it’s not an issue either. Just make sure you return it using a view function. Such functions can be executed offchain using eth_call, which means that you don’t pay anything. No transaction is published, everything happens locally on your client, not on the network. If that’s your use case, you don’t even necessarily need pagination in the contract.\nThe only exception is if you want to get and process that data in another contract. Then that contract does need to execute the function on chain and pagination matters. In fact, the language automatically does that for you - getter functions for arrays by design return them item by item. In your case getting multiple items at a time would be more efficient if you go for the multi-array solution I mentioned, but generally the number should be low since a contract is not likely to have enough gas to process the whole array anyway.\nGenerally, there are no hard limits and you can get away with storing quite a lot of data overall, as long as you ensure that it amortizes to a small amount per user and design your contracts properly so that the whole array is never processed on chain.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":2142,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264814554,"hash":"101e5454575ebabc2235504bfca6d9bc34a98756"}
{"url":"https://ethresear.ch/t/native-proof-verification/24798/3","domain":"ethresear.ch","title":"Native proof verification - Sharding - Ethereum Research","text":"Sharding\n\n rollup\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 5\n\n 3 / 3\n\n May 6\n\n May 5\n\n post by donnoh on May 5\n\n donnoh\n\n Abstract\nThe overarching goal of this proposal is to massively derisk and simplify L2 bridges, and more generally any onchain application that verifies ZK proofs, by introducing a standard L1 primitive that any project can adopt in place of its bespoke onchain verifier stack. This is achieved through two changes:\n\nGeneralize EIP-8025 so the consensus-layer proof verification infrastructure becomes program-agnostic, not tied to EVM execution proofs.\nA new EIP that exposes it to smart contracts through a proof-carrying transaction type and three opcodes (PROGRAMHASH, PUBVALUESHASH, PROOFCOUNT).\n\nTogether, they let any project inherit L1’s proof verification infrastructure directly, with zkVM fixes shipping through client releases rather than per-project governance upgrades.\nMotivation\nToday, every Ethereum rollup maintains bespoke onchain proof verification infrastructure. ZK rollups deploy zkVM verifier contracts, adapter contracts, multi-proof dispatchers, and program whitelisting logic. Optimistic rollups ship their own onchain fraud-proof VMs (Arbitrum’s WAVM, Optimism’s Cannon MIPS machine) plus the surrounding dispute logic. In both cases every contract is maintained, patched, and upgraded independently in response to bugs in its specific proof system or VM, with each upgrade gated by a custom multisig or DAO. This is slow, risky, and duplicated across the ecosystem.\nEIP-8025 introduces zkVM proof verification on Ethereum’s consensus layer, but only for L1’s own purposes: verifying execution payloads to enable stateless and sublinear validation. Rollups still need their own onchain verifier contracts.\nHowever, the infrastructure that EIP-8025 brings to the CL, the ProofEngine, proof gossip, and verification logic, is not inherently L1-specific. If generalized to be program-agnostic and exposed to smart contracts via a new transaction type, any rollup, even non-EVM ones, could offload proof verification to the CL. When a zkVM implementation needs to be patched, Ethereum client teams release updated software the same way bugs in geth or Nethermind are fixed today: through client releases, without a hard fork. This is the same principle behind native rollups, but more generalized: just as native rollups inherit L1’s execution environment, native proof verification lets any rollup inherit L1’s proof verification infrastructure.\nAlthough this document frames the proposal around rollups, the same primitive serves any contract that verifies a ZK proof onchain: privacy systems, ZK coprocessors, identity, ZK ML, and others.\nHow rollups verify proofs today\nEach zkVM vendor provides a universal Solidity verifier contract (typically a Groth16 or Plonk check over BN254). The program identity and the public values (any inputs and outputs the circuit commits to) are passed alongside the proof. For SP1:\ninterface ISP1Verifier {\n function verifyProof(\n bytes32 programVKey, // program hash\n bytes calldata publicValues, // public values (inputs and/or outputs)\n bytes calldata proofBytes // the proof\n ) external view;\n}\n\nA note on terminology. SP1 calls programVKey a “verification key”, but this collides with the zkVM’s own circuit verification key. This document keeps them separate:\n\nProgram hash (called programVKey by SP1, imageId by Risc0): a bytes32 identifying a compiled guest program. Because each zkVM compiles differently (e.g. RV32IMA vs RV64IMA), it is per-(source, zkVM) pair. ERE expresses this as each backend’s zkVMVerifier::ProgramVk associated type (wrapping SP1VerifyingKey, Risc0’s Digest, etc.).\nVerification key: the zkVM’s circuit VK (polynomial commitments, domain parameters). Hardcoded as constants in onchain verifiers, one per zkVM version, shared across all programs.\n\nExample: Taiko (multi-verifier)\nTaiko illustrates the complexity that arises when a rollup uses multiple proof systems. Its verification architecture involves six contracts across three tiers (two raw verifiers, two adapters, one dispatcher, one SGX verifier), each independently maintained and upgraded through a custom multisig.\n1. Raw zkVM verifiers. Taiko deploys both an SP1 Plonk verifier (SP1Verifier.sol) and a Risc0 Groth16 verifier (RiscZeroGroth16Verifier.sol). These are the vendor-provided universal verifier contracts.\n2. Taiko-specific adapters. Each raw verifier is wrapped in an adapter contract that implements Taiko’s IVerifier interface:\n// TaikoSP1Verifier: adapter for SP1\ncontract TaikoSP1Verifier is IVerifier {\n address public sp1RemoteVerifier; // raw SP1 verifier\n mapping(bytes32 => bool) public isProgramTrusted; // whitelisted programs\n\n function verifyProof(Context[] calldata _ctxs, bytes calldata _proof) external view {\n bytes32 aggregationProgram = bytes32(_proof[:32]);\n bytes32 blockProvingProgram = bytes32(_proof[32:64]);\n require(isProgramTrusted[aggregationProgram]);\n require(isProgramTrusted[blockProvingProgram]);\n\n bytes memory publicInputs = buildPublicInputs(_ctxs);\n ISP1Verifier(sp1RemoteVerifier).verifyProof(\n aggregationProgram, publicInputs, _proof[64:]\n );\n }\n}\n\nA parallel Risc0Verifier has the same shape, with isImageTrusted replacing isProgramTrusted and sha256(buildPublicInputs(...)) as the journal digest.\n3. Multi-verifier dispatcher. A ComposeVerifier contract orchestrates multiple verifiers and enforces that a sufficient set has verified each proof:\ncontract MainnetVerifier is ComposeVerifier {\n address public immutable sgxGethVerifier; // SGX verifier (required)\n address public immutable risc0RethVerifier; // Risc0 option\n address public immutable sp1RethVerifier; // SP1 option\n\n function verifyProof(Context[] calldata _ctxs, bytes calldata _proof) external {\n SubProof[] memory subProofs = abi.decode(_proof, (SubProof[]));\n for (uint256 i = 0; i < subProofs.length; ++i) {\n IVerifier(subProofs[i].verifier).verifyProof(_ctxs, subProofs[i].proof);\n }\n require(areVerifiersSufficient(verifiers));\n }\n\n function areVerifiersSufficient(address[] memory _verifiers) internal view override {\n // Must have exactly 2: sgxGethVerifier + (risc0 or sp1)\n }\n}\n\nChanges to EIP-8025\nEIP-8025 introduces optional execution proofs for L1 block validation. The infrastructure it brings to the consensus layer (the ProofEngine, gossip, verification logic) is L1-specific only because its types are: ExecutionProof.public_input carries a new_payload_request_root: Root, and ProofType is a uint8 enumerating a small fixed set of accepted (client, zkVM) builds (see Lighthouse implementation):\n\nProofType\nGuest program\nzkVM backend\n\n0\nethrex\nRisc0\n\n1\nethrex\nSP1\n\n2\nethrex\nZisk\n\n3\nreth\nOpenVM\n\n4\nreth\nRisc0\n\n5\nreth\nSP1\n\n6\nreth\nZisk\n\nThis works while the set of guest programs is small and known in advance, but cannot accommodate arbitrary rollup programs.\nThis EIP adds a generic verification primitive alongside, leaving EIP-8025’s existing surface (ExecutionProof, ProofType, verify_execution_proof, notify_new_payload, notify_forkchoice_updated, process_execution_proof, request_proofs, ProofAttributes) untouched. The generalization mirrors ERE, whose zkVMVerifier trait is program-agnostic and specific guest programs are built on top. Following ERE’s design where the Compiler and the zkVMVerifier backend are independent traits, the new Proof container splits the conflated ProofType into two axes: a BackendType: uint8 that identifies only the zkVM backend, and a program_hash: Bytes32 that identifies the guest program (specific to a (guest program, zkVM) pair, see terminology note). The engine uses backend_type to select the circuit VK; program_hash is a public input to the circuit, checked alongside public_values during verification:\nclass ProofPublicInput(Container):\n program_hash: Bytes32\n public_values: ByteList[MAX_PUBLIC_VALUES_SIZE]\n\nclass Proof(Container):\n proof_data: ByteList[MAX_PROOF_SIZE]\n backend_type: BackendType\n public_input: ProofPublicInput\n\ndef verify_proof(self: ProofEngine, proof: Proof) -> bool: ...\n\nEIP-8025’s verify_execution_proof can be reimplemented as a thin wrapper over verify_proof for code sharing, with no observable change at the gossip layer:\ndef verify_execution_proof(self: ProofEngine, ep: ExecutionProof) -> bool:\n backend_type, program_hash = self.resolve_proof_type(ep.proof_type)\n expected_public_values = serialize_stateless_output(StatelessValidationResult(\n new_payload_request_root=ep.public_input.new_payload_request_root,\n successful_validation=True,\n chain_config=self.chain_config,\n ))\n return self.verify_proof(Proof(\n proof_data=ep.proof_data,\n backend_type=backend_type,\n public_input=ProofPublicInput(\n program_hash=program_hash,\n public_values=expected_public_values,\n ),\n ))\n\nThe byte-level layout of serialize_stateless_output over StatelessValidationResult is shown in Impact on native rollups, since native-rollup contracts reconstruct it onchain. Block validity remains decoupled from proof verification; the honest prover guide is unchanged. Sidecar-arrived proofs (proof-carrying transactions, see Proof propagation) go through verify_proof directly, without the L1 wrapper.\nProgram hash stability (open problem)\nNative proof verification’s “fixes ship through client releases, nothing onchain changes” property depends on one non-trivial requirement: the program_hash pinned onchain must remain stable across zkVM patches. If any patch moves the hash, rollups that pinned the old value are bricked unless they upgrade, and the upgrade story collapses back onto onchain governance.\nNo zkVM today delivers this directly. Both leading candidates fingerprint artifacts that change under normal SDK / dependency / toolchain churn, not just circuit-layer fixes:\n\nRisc0’s imageId is a SHA-256 over SystemState { pc: 0, merkle_root } with merkle_root a Poseidon2 merkle root of the initial memory image, which contains both the user ELF and the kernel ELF (binfmt/src/elf.rs#L435). The memory image captures the exact compiled bytes, so a dep bump, toolchain update, or kernel patch all change imageId even when STF semantics are unchanged.\nSP1’s programVKey is a Poseidon2 over (preprocessed_commit, pc_start, ...) (hypercube/src/verifier/hashable_key.rs#L107). Unlike Risc0’s imageId (a pure hash of compiled bytes), the SP1 vk is a byproduct of running circuit setup over the ELF: preprocessed_commit is the AIR’s preprocessing commitment and pc_start comes from the linker, so circuit changes, SDK bumps, and toolchain changes all move it, even when the user’s guest source is byte-identical.\n\nUsing either directly as the onchain program_hash would make every zkVM release a rollup-visible event.\nThe realistic path is an indirection layer: the onchain program_hash is a stable, rollup-chosen identifier and the public input to the proof, while the zkVM-internal identifier is a private input, maintained by clients and free to change with every release. The proof must attest that the two are linked, so that the stable program_hash genuinely commits to what was executed. The exact mechanism is an open design question.\nNative rollups using the NATIVE_PROGRAM sentinel sidestep this entirely: the sentinel just says “whatever L1 currently accepts”, and the accepted set is itself a client-side artifact that updates with zkVM releases.\nNew EIP: Proof-carrying transactions\nTransaction format\nTransactionType: PROOF_TX_TYPE\n\nTransactionPayloadBody:\n[chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit,\n to, value, data, access_list, max_fee_per_blob_gas,\n blob_versioned_hashes, proofs, public_values_hash,\n y_parity, r, s]\n\nWhere:\n\nproofs: a list of (program_hash, backend_type) pairs. Each program_hash is a bytes32 identifying the guest program for that specific zkVM backend (see terminology note). Each backend_type is a uint8 and MUST be unique within the list, since two proofs from the same backend add no security. The length of this list determines proof_count.\npublic_values_hash: a bytes32 hash of the program’s public output (shared across all proofs, since all backends prove the same statement).\n\nThe CL-level Proof carries the raw public_values bytes; the transaction body (and the PUBVALUESHASH opcode) only expose their hash. The contract reconstructs the expected bytes and compares hashes. Two invariants tie the two views together (checked by any node that handles the sidecar, on mempool propagation and again by the builder when assembling the block):\n\nsidecar[i].public_input.program_hash == proofs[i].program_hash and sidecar[i].backend_type == proofs[i].backend_type.\nsha256(sidecar[i].public_input.public_values) == public_values_hash.\n\nThese bind the EVM-visible identifiers (proofs[i].program_hash, public_values_hash) to the underlying Proof objects passed to verify_proof. See Proof propagation for how proofs reach the builder and how the L1 block proof covers them.\nOpcodes\nNew opcodes read the proof-carrying transaction’s fields and return zero for non-proof-carrying transactions.\n\nOpcode\nInput\nOutput\nDescription\n\nPROGRAMHASH\nindex\nprogram_hash (bytes32)\nProgram hash for the i-th proof. Indexed like BLOBHASH; returns bytes32(0) if index >= PROOFCOUNT()\n\nPUBVALUESHASH\nnone\npublic_values_hash (bytes32)\nHash of the program’s public output (shared across all proofs)\n\nPROOFCOUNT\nnone\nproof_count (uint8)\nLength of the transaction’s proofs list\n\nA custom rollup iterates with PROOFCOUNT() and checks each PROGRAMHASH(i) against its own whitelist.\nFor native rollups, PROGRAMHASH(i) returns a well-known sentinel value (e.g. bytes32(1)) when the i-th proof uses a program that L1 currently accepts for its own EVM execution proofs. This way the contract checks PROGRAMHASH(i) == NATIVE_PROGRAM without storing specific per-zkVM hashes, and automatically follows L1 upgrades shipped in client releases.\nMulti-proof\nThe proofs list lets each rollup pick its own security/cost trade-off: [(hash, SP1)] is a single proof, [(hash_sp1, SP1), (hash_risc0, Risc0)] requires the same statement to be independently proven by both before the CL accepts the transaction. The contract reads PROOFCOUNT() and enforces its own minimum.\nThis replaces contract-level multi-proof orchestration (like Taiko’s ComposeVerifier requiring both SGX and a ZK verifier) with a protocol-level mechanism. Because proofs is in the signed transaction body, it cannot be tampered with.\nProof propagation\nThe proof must reach a builder through the mempool, but needs no long-term availability. The proposed approach is an ephemeral sidecar: the proof travels alongside the transaction like an EIP-4844 blob sidecar. Mempool nodes and the builder run each sidecar entry through verify_proof (and check the invariants from Transaction format) before forwarding or including the transaction. The builder then strips the sidecar before block inclusion, folds it into the recursive L1 block proof, and discards it. Validators see only the transaction body (the proofs list and public_values_hash) plus the L1 block proof; they never need the raw proof bytes. The L1 block proof thus recursively covers every proof-carrying transaction in the block (post-quantum proofs may be large enough that L1 is limited to one proof per slot).\nSize. EIP-8025 sets MAX_PROOF_SIZE = 400 KiB per proof. The spec doesn’t bound len(proofs), but mempool client size limits make 2–3 a practical ceiling.\nImpact on existing rollups\nThe table below reports Solidity SLOC (non-blank, non-comment source lines) for each project’s onchain contracts, split between “core” rollup logic and the proof verification stack that native proof verification would retire.\n\nProject\nProof system\nCore SLOC\nRetired SLOC\n% retired\n\nArbitrum\nOptimistic, WASM VM\n19,034\n8,181\n43.0%\n\nBase\nOptimistic, MIPS VM\n17,426\n8,907\n51.1%\n\nZKsync Era\nValidity, EraVM\n10,823\n2,379\n22.0%\n\nLinea\nValidity, direct EVM\n8,111\n2,460\n30.3%\n\nLighter\nValidity, no VM (custom circuits)\n5,417\n1,699\n31.4%\n\nTotal\n\n60,811\n23,626\n38.9%\n\nThese numbers are rough estimates. They cover only on-chain Solidity code and exclude off-chain provers, sequencers, and the guest program behind each program_hash. Governance surfaces (multisigs, timelocks, DAO contracts, proxy admins), partner-specific bridges, and proxy boilerplate are excluded from both columns.\nTaiko’s six-contract multi-verifier stack collapses into a single inbox contract:\ncontract TaikoInbox {\n mapping(bytes32 => bool) public isTrustedProgram; // whitelisted per-zkVM program hashes\n uint256 public minProofCount; // multi-proof threshold (e.g. 2)\n\n function proveBatches(\n BatchMetadata[] calldata metas,\n Transition[] calldata trans\n // _proof parameter removed: verified by the CL\n ) external {\n // Verify all proofs used trusted programs.\n require(PROOFCOUNT() >= minProofCount, \"insufficient proofs\");\n for (uint256 i = 0; i < PROOFCOUNT(); i++) {\n require(isTrustedProgram[PROGRAMHASH(i)], \"untrusted program\");\n }\n\n bytes memory publicInputs = buildPublicInputs(metas, trans);\n require(PUBVALUESHASH() == sha256(publicInputs), \"wrong public values\");\n\n // Accept the batches.\n ...\n }\n}\n\nA single isTrustedProgram whitelist replaces both isProgramTrusted (SP1) and isImageTrusted (Risc0); minProofCount replaces areVerifiersSufficient.\nImpact on native rollups\nThe NativeRollup contract from the native rollup’s ZK specification uses the same pattern. Instead of PROOFROOT against a validation_result_root, it checks PROGRAMHASH, PUBVALUESHASH, and PROOFCOUNT:\nbytes32 constant NATIVE_PROGRAM = bytes32(uint256(1));\nuint256 public minProofCount;\n\nfunction advance(BlockParams calldata params) external {\n bytes32 l1Anchor = blockhash(block.number - 1);\n\n bytes32 npRoot = computeNewPayloadRequestRoot(\n blockHash, params.feeRecipient, params.stateRoot,\n // ... remaining fields ...\n getVersionedHashes(params.payloadBlobCount),\n l1Anchor, bytes32(0)\n );\n\n // SSZ-encode the StatelessValidationResult container:\n // new_payload_request_root (32 bytes) || successful_validation (1 byte)\n // || chain_id (8 bytes, little-endian).\n // Must match serialize_stateless_output() in execution-specs.\n bytes memory expectedPublicValues = SSZ.encodeStatelessValidationResult(\n npRoot, true, chainId\n );\n bytes32 expectedPubValuesHash = sha256(expectedPublicValues);\n\n require(PROOFCOUNT() >= minProofCount, \"insufficient proofs\");\n for (uint256 i = 0; i < PROOFCOUNT(); i++) {\n require(PROGRAMHASH(i) == NATIVE_PROGRAM, \"not a native program\");\n }\n require(PUBVALUESHASH() == expectedPubValuesHash, \"wrong public values\");\n\n blockHash = params.blockHash;\n stateRoot = params.stateRoot;\n blockNumber = blockNumber + 1;\n stateRootHistory[blockNumber] = params.stateRoot;\n}\n\nA native rollup is simply one whose programHash matches what L1 itself accepts; an L1 upgrade (e.g. a fork changing verify_stateless_new_payload) propagates automatically. Rollups with custom VMs use the same pattern with a different programHash.\n\n read \n\n 7\n min\n\n post by thegaram33 on May 5\n\n thegaram33\n\nGreat proposal! This part was really illuminating for me, showing how the proofs are ephemeral, only used during block building.\nI imagine there will be some cost associated with this aggregation (proving cost + proving latency). I guess whatever pricing we’ll come up for mandatory proofs (EIP-8025’s successors) will also apply to native proof verification.\n\nPROOFCOUNT seems redundant. Similarly, there is no BLOBCOUNT opcode, the rollup contract can simply iterate until it encounters blob hash bytes32(0).\n\nIsn’t this overly restrictive?\nWe could allow proofs to be a list of (program_hash, backend_type, public_values_hash) tuples to allow atomically composing proofs of multiple statements.\nThis might be useful for certain use cases (e.g. a single transaction updates multiple rollups). Might be an overkill though.\n\n post by tamirhemo on May 5\n\n tamirhemo\n\n Interesting suggestion! potential great simplification of the stack + proof propagation.\nOn Program hash stability\nIn SP1 specifically, patches do not change the program hash mapping (with the exception of security patches). In particular, we have been following the convention that programs compiled on a zkvm runtime environment with version MAJOR.x.x will be able to generate proofs with sdk of any of the same MAJOR version. The vk is more or less a PCS encoding the the bytecode (or a disassembly of it), which is basically Reed-Solomon encoding + hash of the bytecode (or a disassembly of it) plus other preprocessed ROM tables like a byte operation lookup table. Hence, most circuit changes will not change that vk, including security upgrades.\nIt would be interesting to spec out what the ideal level of binding is. For example, I could see in the future performance benefits from including more trusted preprocessing at the program level like program specific circuits that replace pure RISC-V code (this is not used currently in sp1). Given an issue in such a circuit, the client will have to upgrade.\nWe could also potentially prove the compatibility of this bytecode hash with the internal secret as suggested, but it will come with some performance penalty. For rollup level workloads, this penalty might be small since program execution usually is much larger than program memory itself. However, I could see native proof verification being a useful primitive for programs of all sizes, so it’s worth discussing.\n\n Powered by Discourse","tokens":5358,"squid":"ink-research","role":"Deep Scholar","at":1791264821967,"hash":"9619238862fc980019a1d4df5d7053fc166b461f"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract-shows-error-in-safeerc20/5053/4","domain":"forum.openzeppelin.com","title":"Crowdsale contract shows error in SafeERC20 - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Dec 2020\n\n 4 / 4\n\n Jan 2021\n\n Jan 2021\n\n post by ashishk74 on Dec 15, 2020\n\n ashishk74\n\n I am writing a Crowdsale contract but function buyTokens does not run and throws an error ,\nexecution reverted: SafeERC20: low-level call failed { “originalError”: { “code”: 3, “data”: “0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000205361666545524332303a206c6f772d6c6576656c2063616c6c206661696c6564”, “message”: “execution reverted: SafeERC20: low-level call failed” } }\n Environment\n Contract made using version 2.5 and run on RemixIDE\nDetails\n\nError seems to be from SafeERC20 library. Deployment of token & crowdsale contracts is smooth.\nMy code is given below:\n Code to reproduce\n\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\ninterface IERC20 {\n\n function totalSupply() external view returns (uint256);\n\n function balanceOf(address account) external view returns (uint256);\n\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n function allowance(address owner, address spender) external view returns (uint256);\n\n function approve(address spender, uint256 amount) external returns (bool);\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n event Approval(address indexed owner, address indexed spender, uint256 value);\n\n}\n\nlibrary SafeMath {\n\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n\n uint256 c = a + b;\n\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n\n }\n\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return sub(a, b, \"SafeMath: subtraction overflow\");\n\n }\n\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n require(b <= a, errorMessage);\n\n uint256 c = a - b;\n\n return c;\n\n }\n\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n\n if (a == 0) {\n\n return 0;\n\n }\n\n uint256 c = a * b;\n\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n\n }\n\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return div(a, b, \"SafeMath: division by zero\");\n\n }\n\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n // Solidity only automatically asserts when dividing by 0\n\n require(b > 0, errorMessage);\n\n uint256 c = a / b;\n\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n\n }\n\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return mod(a, b, \"SafeMath: modulo by zero\");\n\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n require(b != 0, errorMessage);\n\n return a % b;\n\n }\n\n}\n\nlibrary Roles {\n\n struct Role {\n\n mapping (address => bool) bearer;\n\n }\n\n function add(Role storage role, address account) internal {\n\n require(!has(role, account), \"Roles: account already has role\");\n\n role.bearer[account] = true;\n\n }\n\n function remove(Role storage role, address account) internal {\n\n require(has(role, account), \"Roles: account does not have role\");\n\n role.bearer[account] = false;\n\n }\n\n function has(Role storage role, address account) internal view returns (bool) {\n\n require(account != address(0), \"Roles: account is the zero address\");\n\n return role.bearer[account];\n\n }\n\n}\n\nlibrary SafeERC20 {\n\n using SafeMath for uint256;\n\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint256 value) internal {\n\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {\n\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n\n }\n\n function safeApprove(IERC20 token, address spender, uint256 value) internal {\n\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n\n );\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n\n }\n\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n\n }\n\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n\n require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n (bool success, bytes memory returndata) = address(token).call(data);\n\n require(success, \"SafeERC20: low-level call failed\");\n\n if (returndata.length > 0) { // Return data is optional\n\n // solhint-disable-next-line max-line-length\n\n require(abi.decode(returndata, (bool)), \"SafeERC20: ERC20 operation did not succeed\");\n\n }\n\n }\n\n}\n\ncontract ReentrancyGuard {\n\n bool private _notEntered;\n\n constructor () internal {\n\n _notEntered = true;\n\n }\n\n modifier nonReentrant() {\n\n // On the first call to nonReentrant, _notEntered will be true\n\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n\n _notEntered = false;\n\n _;\n\n // By storing the original value once again, a refund is triggered (see\n\n // https://eips.ethereum.org/EIPS/eip-2200)\n\n _notEntered = true;\n\n }\n\n}\n\nlibrary Address {\n\n function isContract(address account) internal view returns (bool) {\n\n bytes32 codehash;\n\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n\n // solhint-disable-next-line no-inline-assembly\n\n assembly { codehash := extcodehash(account) }\n\n return (codehash != accountHash && codehash != 0x0);\n\n }\n\n function toPayable(address account) internal pure returns (address payable) {\n\n return address(uint160(account));\n\n }\n\n function sendValue(address payable recipient, uint256 amount) internal {\n\n require(address(this).balance >= amount, \"Address: insufficient balance\");\n\n // solhint-disable-next-line avoid-call-value\n\n (bool success, ) = recipient.call.value(amount) (\"\");\n\n require(success, \"Address: unable to send value, recipient may have reverted\");\n\n }\n\n}\n\ncontract Context {\n\n function _msgSender() internal view returns (address payable) {\n\n return msg.sender;\n\n }\n\n function _msgData() internal view returns (bytes memory) {\n\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n\n return msg.data;\n\n }\n\n}\n\ncontract ERC20 is Context, IERC20 {\n\n using SafeMath for uint256;\n\n mapping (address => uint256) private _balances;\n\n mapping (address => mapping (address => uint256)) private _allowances;\n\n uint256 private _totalSupply;\n\n function totalSupply() public view returns (uint256) {\n\n return _totalSupply;\n\n }\n\n function balanceOf(address account) public view returns (uint256) {\n\n return _balances[account];\n\n }\n\n function transfer(address recipient, uint256 amount) public returns (bool) {\n\n _transfer(_msgSender(), recipient, amount);\n\n return true;\n\n }\n\n function allowance(address owner, address spender) public view returns (uint256) {\n\n return _allowances[owner][spender];\n\n }\n\n function approve(address spender, uint256 amount) public returns (bool) {\n\n _approve(_msgSender(), spender, amount);\n\n return true;\n\n }\n\n function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {\n\n _transfer(sender, recipient, amount);\n\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n\n return true;\n\n }\n\n function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {\n\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n\n return true;\n\n }\n\n function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {\n\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n\n return true;\n\n }\n\n function _transfer(address sender, address recipient, uint256 amount) internal {\n\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n\n _balances[recipient] = _balances[recipient].add(amount);\n\n emit Transfer(sender, recipient, amount);\n\n }\n\n function _mint(address account, uint256 amount) internal {\n\n require(account != address(0), \"ERC20: mint to the zero address\");\n\n _totalSupply = _totalSupply.add(amount);\n\n _balances[account] = _balances[account].add(amount);\n\n emit Transfer(address(0), account, amount);\n\n }\n\n function _burn(address account, uint256 amount) internal {\n\n require(account != address(0), \"ERC20: burn from the zero address\");\n\n _balances[account] = _balances[account].sub(amount, \"ERC20: burn amount exceeds balance\");\n\n _totalSupply = _totalSupply.sub(amount);\n\n emit Transfer(account, address(0), amount);\n\n }\n\n function _approve(address owner, address spender, uint256 amount) internal {\n\n require(owner != address(0), \"ERC20: approve from the zero address\");\n\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\n\n emit Approval(owner, spender, amount);\n\n }\n\n function _burnFrom(address account, uint256 amount) internal {\n\n _burn(account, amount);\n\n _approve(account, _msgSender(), _allowances[account][_msgSender()].sub(amount, \"ERC20: burn amount exceeds allowance\"));\n\n }\n\n}\n\ncontract ERC20Detailed is IERC20 {\n\n string private _name;\n\n string private _symbol;\n\n uint8 private _decimals;\n\n constructor (string memory name, string memory symbol, uint8 decimals) public {\n\n _name = name;\n\n _symbol = symbol;\n\n _decimals = decimals;\n\n }\n\n function name() public view returns (string memory) {\n\n return _name;\n\n }\n\n function symbol() public view returns (string memory) {\n\n return _symbol;\n\n }\n\n function decimals() public view returns (uint8) {\n\n return _decimals;\n\n }\n\n}\n\ncontract AnnaToken is Context, ERC20, ERC20Detailed {\n\n constructor(\n\n string memory name,\n\n string memory symbol,\n\n uint256 initialSupply\n\n ) public ERC20Detailed(name, symbol, 0) {\n\n _mint(_msgSender(), initialSupply);\n\n }\n\n}\n\ncontract Crowdsale is Context, ReentrancyGuard {\n\n using SafeMath for uint256;\n\n using SafeERC20 for IERC20;\n\n // The token being sold\n\n IERC20 private _token;\n\n // Address where funds are collected\n\n address payable private _wallet;\n\n // How many token units a buyer gets per wei.\n\n // The rate is the conversion between wei and the smallest and indivisible token unit.\n\n // So, if you are using a rate of 1 with a ERC20Detailed token with 3 decimals called TOK\n\n // 1 wei will give you 1 unit, or 0.001 TOK.\n\n uint256 private _rate;\n\n uint256 private _price;\n\n // Amount of wei raised\n\n uint256 private _weiRaised;\n\n /**\n\n * Event for token purchase logging\n\n * @param purchaser who paid for the tokens\n\n * @param beneficiary who got the tokens\n\n * @param value weis paid for purchase\n\n * @param amount amount of tokens purchased\n\n */\n\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n /**\n\n * rate Number of token units a buyer gets per wei\n\n * @param price Number of wei a buyer needs to get per token\n\n * @dev The rate is the conversion between wei and the smallest and indivisible\n\n * token unit. So, if you are using a rate of 1 with a ERC20Detailed token\n\n * with 3 decimals called TOK, 1 wei will give you 1 unit, or 0.001 TOK.\n\n * @param wallet Address where collected funds will be forwarded to\n\n * @param token Address of the token being sold\n\n */\n\n constructor (uint256 price, address payable wallet, IERC20 token) public {\n\n require(price > 0, \"Crowdsale: rate is 0\");\n\n require(wallet != address(0), \"Crowdsale: wallet is the zero address\");\n\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n\n _price = price;\n\n _wallet = wallet;\n\n _token = token;\n\n }\n\n /**\n\n * @dev fallback function ***DO NOT OVERRIDE***\n\n * Note that other contracts will transfer funds with a base gas stipend\n\n * of 2300, which is not enough to call buyTokens. Consider calling\n\n * buyTokens directly when purchasing tokens from a contract.\n\n */\n\n function () external payable {\n\n buyTokens(_msgSender());\n\n }\n\n /**\n\n * @return the token being sold.\n\n */\n\n function token() public view returns (IERC20) {\n\n return _token;\n\n }\n\n /**\n\n * @return the address where funds are collected.\n\n */\n\n function wallet() public view returns (address payable) {\n\n return _wallet;\n\n }\n\n /**\n\n * @return the number of token units a buyer gets per wei.\n\n */\n\n function rate() public view returns (uint256) {\n\n return _rate;\n\n }\n\n function price() public view returns (uint256) {\n\n return _price;\n\n }\n\n /**\n\n * @return the amount of wei raised.\n\n */\n\n function weiRaised() public view returns (uint256) {\n\n return _weiRaised;\n\n }\n\n /**\n\n * @dev low level token purchase ***DO NOT OVERRIDE***\n\n * This function has a non-reentrancy guard, so it shouldn't be called by\n\n * another `nonReentrant` function.\n\n * @param beneficiary Recipient of the token purchase\n\n */\n\n function buyTokens(address beneficiary) public nonReentrant payable {\n\n uint256 weiAmount = msg.value;\n\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n\n _postValidatePurchase(beneficiary, weiAmount);\n\n }\n\n /**\n\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n\n * super._preValidatePurchase(beneficiary, weiAmount);\n\n * require(weiRaised().add(weiAmount) <= cap);\n\n * @param beneficiary Address performing the token purchase\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n\n }\n\n /**\n\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n\n * conditions are not met.\n\n * @param beneficiary Address performing the token purchase\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n\n // solhint-disable-previous-line no-empty-blocks\n\n }\n\n /**\n\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n\n * its tokens.\n\n * @param beneficiary Address performing the token purchase\n\n * @param tokenAmount Number of tokens to be emitted\n\n */\n\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n\n _token.safeTransfer(beneficiary, tokenAmount);\n\n }\n\n /**\n\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n\n * tokens.\n\n * @param beneficiary Address receiving the tokens\n\n * @param tokenAmount Number of tokens to be purchased\n\n */\n\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n\n _deliverTokens(beneficiary, tokenAmount);\n\n }\n\n /**\n\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n\n * etc.)\n\n * @param beneficiary Address receiving the tokens\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n\n // solhint-disable-previous-line no-empty-blocks\n\n }\n\n /**\n\n * @dev Override to extend the way in which ether is converted to tokens.\n\n * @param weiAmount Value in wei to be converted into tokens\n\n * @return Number of tokens that can be purchased with the specified _weiAmount\n\n */\n\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n\n return weiAmount.div(_price);\n\n }\n\n /**\n\n * @dev Determines how ETH is stored/forwarded on purchases.\n\n */\n\n function _forwardFunds() internal {\n\n _wallet.transfer(msg.value);\n\n }\n\n}\n\ncontract AnnaCrowdsale is Crowdsale {\n\n constructor(\n\n uint256 rate,\n\n address payable wallet,\n\n IERC20 token\n\n ) public Crowdsale(rate, wallet, token) {}\n\n}\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by abcoathup on Dec 15, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @ashishk74,\nI assume that your crowdsale doesn't have enough/any tokens.\n\n_From: https://docs.openzeppelin.com/contracts/2.x/crowdsales#token-emission_\nIn the default scenario, your crowdsale must own the tokens that are sold. You can send the crowdsale tokens through a variety of methods\n\nI suggest having a look at: Simple ERC20 Crowdsale.\n\n 19 days later\n\n post by abcoathup on Jan 3, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @ashishk74,\nI wanted to check that you were able to resolve by transferring tokens to the crowdsale?\n\n post by ashishk74 on Jan 3, 2021\n\n ashishk74\n\n Yes, thanks. Your help was surely useful.\nRegards\nAshish\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n Satisfies all conditions set by Solidity `require` statements. does not trigger a Solidity `revert` statement. SafeERC20: low-level call failed\n\n Smart Contracts\n\n crowdsale\n\n 0\n\n 1.2k\n\n Mar 2022\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020\n\n Crowdsale buyTokens fails with error ‘SafeERC20: low-level call failed’\n\n Contracts\n\n 2\n\n 2.5k\n\n Mar 2021\n\n Contract Crowdsale SafeMath: subtraction overflow”, “data” error\n\n Support\n\n 1\n\n 4.2k\n\n May 2021","tokens":4744,"squid":"ink-security_audits","role":"Sentinel","at":1791264822094,"hash":"397e4d647f3a4afaf6c65cfc62b93d8921975d10"}
{"url":"https://forum.soliditylang.org/c/code-wizards/7","domain":"forum.soliditylang.org","title":"Latest Code Wizards topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Code Wizards\n\n Code Wizards\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Code Wizards category\n\n Share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it. \n Please be aware that this is not the …\n\n read more\n\n 0\n\n 612\n\n Feb 2021\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n 1\n\n 81\n\n Jun 22\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n 1\n\n 120\n\n Jun 9\n\n What Solidity try/catch actually catches\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n 1\n\n 122\n\n Apr 18\n\n Diamond Contract Gas Efficiency Challenge\n\n 0\n\n 110\n\n Oct 2025\n\n Storing validators public key in storage\n\n 0\n\n 115\n\n Jun 2025\n\n Dexrouter and factory value in an function\n\n 15\n\n 2.5k\n\n Dec 2024\n\n Are updatable function pointers possible?\n\n 4\n\n 480\n\n Mar 2024\n\n Need some help: Opcode with different compiler version\n\n 1\n\n 456\n\n Jul 2023\n\n How ensure a whole number deposit (Integer)\n\n 3\n\n 1.8k\n\n Apr 2023\n\n Hashing — get Signature\n\n 2\n\n 1.4k\n\n Apr 2023\n\n I live with this Error for two month -on https://remix.ethereum.org\n\n 9\n\n 1.3k\n\n Apr 2023\n\n Gas estimation on failed transactions - how to deal with it? [HARD]\n\n 0\n\n 464\n\n Mar 2023\n\n Does it make sense to deploy reusable library for rendering SVG, etc.?\n\n 7\n\n 721\n\n Mar 2023\n\n Some questions about the Solidity language\n\n 5\n\n 1.9k\n\n Mar 2023\n\n Lock transfer addresses\n\n 2\n\n 771\n\n Mar 2023\n\n Can someone list all situation the will generate a revert op code?\n\n 3\n\n 484\n\n Mar 2023\n\n Techniques for large amounts of on-chain computation\n\n 4\n\n 746\n\n Mar 2023\n\n Is it possible to decode data and make assignment to struct members and new variables in one step\n\n 5\n\n 1.8k\n\n Mar 2023\n\n Can anyone explain to me what the _method does?\n\n 5\n\n 1.5k\n\n Nov 2022\n\n Throwing error strings in Yul\n\n 1\n\n 735\n\n Nov 2022\n\n Burn in one contract and mint in other\n\n 1\n\n 1.3k\n\n Oct 2022\n\n Allocating bits from stored byte32 to different byte variables\n\n 1\n\n 605\n\n Oct 2022\n\n How to: reverse engineering\n\n 2\n\n 1.4k\n\n Oct 2022\n\n I wrote staking smart contract and I have “loop” concerns\n\n 5\n\n 1.1k\n\n Sep 2022\n\n Off-chain execution\n\n 0\n\n 512\n\n Aug 2022\n\n How to store a string/variable in a smart contract that is encoded and only the owner of that contract can call a function to decode it?\n\n 1\n\n 653\n\n Aug 2022\n\n Need some help with my code(Begginer)\n\n 1\n\n 506\n\n Aug 2022\n\n Public visibility or external visibility from an auditing perspective\n\n 5\n\n 964\n\n Jul 2022","tokens":1513,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264825739,"hash":"56f01cbfe94397cb564079b3c81fd4dee557f68d"}
{"url":"https://ethresear.ch/t/universal-plasma-and-da-challenges/18629","domain":"ethresear.ch","title":"Universal Plasma and DA challenges - Layer 2 / Plasma - Ethereum Research","text":"Universal Plasma and DA challenges \n\n Layer 2Plasma\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2024\n\n 1 / 1\n\n Feb 2024\n\n Feb 2024\n\n post by donnoh on Feb 9, 2024\n\n donnoh\n\n Intro\nRollup projects are looking for ways to minimize DA cost, but, most of the time, this effort ends up weakening the security of these systems by turning them into Validiums or Optimiums. On the other hand, now that we have state validating bridges, discussions around Plasma are starting to pop up again.\nIn this post we want to discuss “Optimistic DA” constructions like the one initially introduced by Metis two years ago or the recently proposed OP Plasma spec which will be used by the Redstone OP stack chain.\nDefinitions\n\nRollup: project with full onchain DA and the guarantee that users can always exit permissionlessly under less-than-majority trust assumptions (e.g. single honest challenger, cryptographic assumptions).\nPlasma: project with offchain DA and the guarantee that users can always exit permissionlessly under less-than-majority trust assumptions.\nValidium/Optimium: project with offchain DA relying on a majority trust assumption on DA attestations for exits.\n\nSetting\nThe single operator (i.e. the sequencer) is supposed to share the full data publicly and periodically posts data commitments onchain, in the same way as in a regular Validium/Optimium. The only attack we need to worry about is data unavailability: invalid history, double spends, not latest owner attacks are solved by the validating bridge and the usual burn-unlock or lock-mint mechanisms.\nUsers have the ability to push transactions onchain without any action required by the permissioned sequencer, in the same way that deposited transactions work on OP Bedrock [1]. Moreover, users have also the ability to self propose state roots.\nDA challenges\nEvery sequencer submission is subject to a challenge period. During this time, anyone can challenge a data commitment claiming its unavailability. If the sequencer posts the full data onchain, the challenge is deleted and the chain progresses as usual. If the challenge times out, the data commitment is reverted and the chain reorgs to the previous data commitment. A data commitment is considered finalized if the DA challenge period elapses without challenges or when the full data is published.\nSince data unavailability is unattributable onchain, one has to come up with a mechanism that either punishes or rewards DA challengers by default without knowing whether the claim was right or not. Arguably, the most reasonable incentive structure that allows for this construction to have some benefits on DA cost side and prevents the money-pump vulnerability is to place the same cost on the challenger and sequencer when a challenge is created. This is done by requiring challengers to lock a bond that is approximately equal to the money spent by the sequencer to publish the full data that gets burned if the challenge is not successful.\nSecurity considerations\nLet’s say that the sequencer is malicious and plans to steal all the funds in the bridge by finalizing an unavailable data commitment that cannot be challenged by a fraud proof system over the state. Challengers can either force the sequencer to make the data available or revert the data commitment to the latest available one. Users can now exit by forcing withdrawal transactions independently via the base chain and self proposing state roots.\nSince the mechanism punishes challengers by default, the malicious sequencer can exploit the incentives by never sharing the data. It is sufficient for the sequencer to economically outlast the altruistic DA challengers to finalize an unavailable root and steal all the funds. Therefore, the system is considered secure if the altruistic challengers can economically outlast the centralized sequencer.\nThe system does not require all users to be online to force transactions like in Plasma Free, but just requires one honest and active DA challenger at any given time.\nComparison with Stage 2 Optimistic Rollups\nWhile the single honest DA challenger assumption might seem similar to the single honest challenger assumption for state fraud proofs, the assumption is actually worse since it requires altruistic DA challengers to have more funds than the sequencer. This is not a problem in Optimistic Rollups since the challenger is guaranteed to profit from an honest challenge, given that state transition faults are attributable.\nThe problem with this DA challenge scheme emerges when the challengers have no more money to spend on challenges. For Stage 2 Rollups, as described in the Stages Framework, we allow projects to upgrade the contracts if there is at least a 30 days window for users to exit, meaning that we require users to be online at least once every 30 days. In the same way, we can consider the case in which DA challengers have the funds to challenge unavailable data commitments for at least 30 days, delaying the potential confirmation of an invalid state root and providing users with an exit window. Since the amount of funds required is quantifiable, it is possible to get an assurance that the system is secure if users become online at least once every 30 days, or an amount of days proportional to the funds dedicated to it. Properly allocating the funds requires offchain coordination.\nCost analysis\nWe calculate the cost of providing one day of exit window by assuming the maximum size of an L2 block to be 130672 bytes (see derivation spec), an L1 base fee of 200 gwei (as assumed in the fault proof system), 12s L1 block times and 2s L2 block times. Given the max L2 block size and the L2 block time, we estimate the gas cost of providing preimages as calldata to be 12_544_512 gas every L1 block. Given the base fee assumption, the cost is estimated at ~2.5 ETH per L1 block, which translates to 18000 ETH in costs per day for honest parties to maintain the security of the chain.\n\n[1] The presence of this mechanism is the main difference between the Metis construction and OP Plasma. For the full details, see L2BEAT’s risk analysis.\n\n Powered by Discourse","tokens":1538,"squid":"ink-research","role":"Deep Scholar","at":1791264833549,"hash":"37e19efa790cdba97d884cd873a141ed0ca9da51"}
{"url":"https://forum.openzeppelin.com/t/satisfies-all-conditions-set-by-solidity-require-statements-does-not-trigger-a-solidity-revert-statement-safeerc20-low-level-call-failed/26652","domain":"forum.openzeppelin.com","title":"Satisfies all conditions set by Solidity `require` statements. does not trigger a Solidity `revert` statement. SafeERC20: low-level call failed - Smart Contracts - OpenZeppelin Forum","text":"Satisfies all conditions set by Solidity `require` statements. does not trigger a Solidity `revert` statement. SafeERC20: low-level call failed \n\n Smart Contracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2022\n\n 1 / 1\n\n Mar 2022\n\n Mar 2022\n\n post by Yogesh on Mar 23, 2022\n\n Yogesh\n\n Hi\nWe have created the crowd sale smart contract .This is my Token smart contract\n//SPDX-License-indetifier :Unlicense\npragma solidity ^0.5.0;\nimport \"../node_modules/@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"../node_modules/@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"../node_modules/@openzeppelin/contracts/GSN/Context.sol\";\ncontract Token is Context , ERC20, ERC20Detailed {\n constructor (string memory _name ,string memory _symbol ,uint8 _decimals,uint256 _initialsupply) public ERC20Detailed(_name ,_symbol, _decimals){\n\n _mint(_msgSender(), _initialsupply * (10 ** uint256(_decimals)));\n\n }\n\n}\nand this is my crowd sale contract\ncontract CrodsaleContract is Crowdsale{\nconstructor(\n uint _rate,\n address payable _wallet,\n IERC20 token,\n )\n public\n Crowdsale(_rate ,_wallet ,token)\n {\n\n } \n\nand this is my migration code\nmodule.exports = async function (deployer ,network, accounts){\nconsole.log(accounts[0])\n\nawait deployer.deploy(TOKEN,\"US1 Token\" ,\"US1\",18,1000000000);\n\nconst token = await TOKEN.deployed();\n\nawait deployer.deploy(CrodsaleContract, 1, accounts[0], token.address)\n\n const crowdsale = await Us1Crowdsale.deployed();\n\n token.transfer(crowdsale.address ,await token.totalSupply())\n\n // console.log(crowdsale);\n\nawait crowdsale.sendTransaction({value: web3.utils.toWei('10', 'gwei'), gas: '220000'})\n\n// const trans= await crowdsale.buyTokens(accounts[0], { value: web3.utils.toWei(1000000, 'ether'), from: accounts[0] })\n\nafter the deploy successfully we are not able to buyTokens. we are getting error.\nTransaction: 0x57b96ee4ad13929502f7e0215103f1ed17f169c6fda1ba835e7da81b8d233b68 exited with an error (status 0). Reason given: SafeERC20: low-level call failed.\nPlease check that the transaction:\n- satisfies all conditions set by Solidity require statements.\n- does not trigger a Solidity revert statement.\nPlease check that the code. and please let me know if any correction is there. why getting this error\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n Crowdsale buyTokens fails with error ‘SafeERC20: low-level call failed’\n\n Contracts\n\n 2\n\n 2.5k\n\n Mar 2021\n\n ERC-20 Token + Crowdsale\n\n Contracts\n\n erc20\n\n 9\n\n 1.4k\n\n May 2021\n\n REVERT Error when buying token from crowdsale\n\n Contracts\n\n erc20\n\n 3\n\n 456\n\n May 2021\n\n Crowdsale: revert when buying tokens\n\n Contracts\n\n erc20,crowdsale\n\n 4\n\n 2.4k\n\n May 2019","tokens":712,"squid":"ink-security_audits","role":"Sentinel","at":1791264833598,"hash":"92b73460356524551a3e5c79efdbc3edec677f9b"}
{"url":"https://forum.openzeppelin.com/t/revert-safeerc20-low-level-call-failed-when-trying-to-run-buytokens-function-in-a-crowdsale/4753","domain":"forum.openzeppelin.com","title":"Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale - Support / Contracts - OpenZeppelin Forum","text":"Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Nov 2020\n\n 1 / 6\n\n Nov 2020\n\n Dec 2020\n\n post by pedromtelho on Nov 24, 2020\n\n pedromtelho\n\n I’m getting error VM Exception while processing transaction: revert SafeERC20: low-level call failed\nwhen trying to run buyTokens function\nMy code:\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/IERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/SafeERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./MyToken.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyCrowdsale is Context, ReentrancyGuard, Ownable {\nusing SafeMath for uint256;\nusing SafeERC20 for IERC20;\n\naddress payable private _startupAddr;\n\nuint256 private _tokenPrice; \nuint256 private _tokensSold;\n\n// Amount of wei raised\nuint256 private _weiRaised;\n\nIERC20 private _tokenContract;\nTokenWhitelist private _whitelist;\n\n/**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\nevent TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\nconstructor(\n uint256 rate, \n address payable startupAddr, \n MyToken token, \n TokenWhitelist whitelist_ \n)\npublic\n{\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n}\n\nfunction tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n}\n\nfunction tokensSold() public view returns (uint256) {\n return _tokensSold;\n}\n\nfunction totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n}\n\n/**\n * @return the amount of wei raised.\n */\nfunction weiRaised() public view returns (uint256) {\n return _weiRaised;\n}\n\n/**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\nfunction () external payable {\n buyTokens(_msgSender());\n}\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\nfunction buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n}\n\n/**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n}\n\n/**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n}\n\n/**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\nfunction _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.safeTransfer(beneficiary, tokenAmount);\n}\n\n/**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\nfunction _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _deliverTokens(beneficiary, tokenAmount);\n}\n\n/**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n}\n\n/**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\nfunction _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.div(_tokenPrice);\n}\n\n/**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\nfunction _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n}\n}\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by Skyge on Nov 24, 2020\n\n Skyge\n\n Can you provide the contract MyToken.sol and TokenWhitelist.sol, or can you verify the contract on a testnet?\n\n post by abcoathup on Nov 24, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @pedromtelho,\nYou appear to have cloned a crowdsale. I would suggest extending the Crowdsales from OpenZeppelin Contracts: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nHave you transferred an amount of your token to the crowdsale so it has tokens to sell?\n\n post by pedromtelho on Nov 27, 2020\n\n pedromtelho\n\n Exactly! I thought that some functions could be called by other people and I do not want it so I decided to override them using onlyOwner function. I’ll post my contracts here.\nMyToken.sol:\npragma solidity ^0.5.2;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Mintable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Pausable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyToken is ERC20, ERC20Pausable, ERC20Mintable, Ownable {\n string private _name;\n string private _symbol;\n uint8 private _decimals = 18;\n uint256 private _exp = 10**18;\n uint256 private _totalSupply;\n\nTokenWhitelist public whitelist;\n\nmapping (address => uint256) private _balances;\n\nmapping (address => mapping (address => uint256)) private _allowances;\n\n// ... see \"Tokens\" for more info\nconstructor(string memory name, string memory symbol, address startupAddr, TokenWhitelist _whitelist, uint256 totalSupply) public\n ERC20Mintable()\n ERC20Pausable()\n {\n _name = name;\n _symbol = symbol;\n whitelist = _whitelist;\n mint(startupAddr, totalSupply);\n }\n\nfunction name() public view returns (string memory) {\n return _name;\n}\n\nfunction symbol() public view returns (string memory) {\n return _symbol;\n}\n\nfunction decimals() public view returns (uint8) {\n return _decimals;\n}\n\nfunction totalSupply() public view returns (uint256) {\n return _totalSupply;\n}\n\nfunction balanceOf(address account) public view returns (uint256) {\n return _balances[account];\n}\n\nfunction mint(address toAccount, uint256 amount) public onlyMinter whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(toAccount), \"Account is not whitelisted\");\n _mint(toAccount, amount);\n return true;\n}\n\nfunction transfer(address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(_msgSender(), recipient, amount);\n return true;\n}\n\nfunction allowance(address owner, address spender) public view returns (uint256) {\n return _allowances[owner][spender];\n}\n\nfunction approve(address spender, uint256 amount) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, amount);\n return true;\n}\n\nfunction transferFrom(address sender, address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(sender), \"Sender is not whitelisted\");\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(sender, recipient, amount);\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n return true;\n}\n\nfunction increaseAllowance(address spender, uint256 addedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n return true;\n}\n\nfunction decreaseAllowance(address spender, uint256 subtractedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n return true;\n}\n\nfunction _mint(address account, uint256 amount) internal {\n require(account != address(0), \"ERC20: mint to the zero address\");\n uint256 convertedAmount = amount*_exp;\n _totalSupply = _totalSupply.add(convertedAmount);\n _balances[account] = _balances[account].add(convertedAmount);\n emit Transfer(address(0), account, convertedAmount);\n}\n\nfunction _transfer(address sender, address recipient, uint256 amount) internal {\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n require(whitelist.checkWhitelisted(sender), \"Sender is not checked in whitelist\");\n require(whitelist.checkWhitelisted(recipient), \"Sender is not checked in whitelist\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n _balances[recipient] = _balances[recipient].add(amount);\n emit Transfer(sender, recipient, amount);\n}\n\nfunction _approve(address owner, address spender, uint256 amount) internal {\n require(owner != address(0), \"ERC20: approve from the zero address\");\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\nemit Approval(owner, spender, amount);}}\n\nMyCrowdsale.sol:\npragma solidity ^0.5.2;\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n import \"./MyToken.sol\";\n import \"./TokenWhitelist.sol\";\n\n contract MyCrowdsale is Context, ReentrancyGuard, Ownable {\n using SafeMath for uint256;\n\n address payable private _startupAddr;\n\n uint256 private _tokenPrice; // preço do token\n uint256 private _tokensSold; // tokens vendidos\n\n // Amount of wei raised\n uint256 private _weiRaised;\n\n MyToken private _tokenContract; // contrato do token\n TokenWhitelist private _whitelist;\n\n mapping(address => uint256) private _tokenRequests;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n constructor(\n uint256 rate, // preço\n address payable startupAddr, // endereço da startup\n MyToken token, // endereço do token da startup\n TokenWhitelist whitelist_ // whitelist da nossa empresa\n )\n public\n {\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n }\n\n function tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n }\n\n function tokensSold() public view returns (uint256) {\n return _tokensSold;\n }\n\n function totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n }\n\n /**\n * @return the amount of wei raised.\n */\n function weiRaised() public view returns (uint256) {\n return _weiRaised;\n }\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\n function buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n }\n\n function withdrawTokens(address beneficiary) public {\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n require(_tokenRequests[beneficiary] != 0, \"Crowdsale: beneficiary has no orders\");\n uint256 amount = _tokenRequests[beneficiary];\n require(amount > 0, \"PostDeliveryCrowdsale: beneficiary is not due any tokens\");\n\n _tokenRequests[beneficiary] = 0;\n _tokenContract.transferFrom(_startupAddr, beneficiary, amount);\n }\n\n function tokenRequests(address beneficiary) public view returns (uint256) {\n return _tokenRequests[beneficiary];\n }\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.transferFrom(_startupAddr, beneficiary, tokenAmount);\n }\n\n function _buyOrder(address beneficiary, uint256 tokenAmount) internal {\n _tokenRequests[beneficiary] += tokenAmount;\n _tokensSold += tokenAmount;\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _buyOrder(beneficiary, tokenAmount);\n // _deliverTokens(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 _exp = 10**18;\n uint256 _mult = weiAmount.mul(_exp);\n return _mult.div(_tokenPrice);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n }\n}\n\nTokenWhitelist.sol:\n pragma solidity ^0.5.2;\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n\n// Contrato da nossa whitelist deve ser o primeiro deploy \n\ncontract TokenWhitelist is Ownable {\n mapping(address => bool) private whitelist;\n\n event Whitelisted(address indexed wallet);\n event Dewhitelisted(address indexed wallet);\n\n function enableWallet(address _wallet) public onlyOwner {\n require(_wallet != address(0), \"Invalid wallet\");\n whitelist[_wallet] = true;\n emit Whitelisted(_wallet);\n }\n\n function disableWallet(address _wallet) public onlyOwner {\n whitelist[_wallet] = false;\n emit Dewhitelisted(_wallet);\n }\n\n function checkWhitelisted(address _wallet) public view returns (bool) {\n return whitelist[_wallet];\n }\n}\n\n post by Skyge on Nov 28, 2020\n\n Skyge\n\n Sorry, I tried to deploy it on a testnet, but always get an error when compile the contracts, so can you just verify it on the testnet?\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n pedromtelho\n\n Hi @pedromtelho,\nYou may want to take a step back and start with a simple example: Simple ERC20 Crowdsale.\nI would suggest extending OpenZeppelin Contracts Crowdsales rather than creating your own. This would also make the code much easier to read (and for your audits, audit). https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n REVERT Error when buying token from crowdsale\n\n Contracts\n\n erc20\n\n 3\n\n 456\n\n May 2021\n\n Crowdsale: revert when buying tokens\n\n Contracts\n\n erc20,crowdsale\n\n 4\n\n 2.4k\n\n May 2019\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021","tokens":5421,"squid":"ink-security_audits","role":"Sentinel","at":1791264856425,"hash":"8774fd69f9fe716c7b7d81f5ef4dd50a534823df"}
{"url":"https://forum.openzeppelin.com/t/revert-safeerc20-low-level-call-failed-when-trying-to-run-buytokens-function-in-a-crowdsale/4753/2","domain":"forum.openzeppelin.com","title":"Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Nov 2020\n\n 2 / 6\n\n Nov 2020\n\n Dec 2020\n\n post by pedromtelho on Nov 24, 2020\n\n pedromtelho\n\n I’m getting error VM Exception while processing transaction: revert SafeERC20: low-level call failed\nwhen trying to run buyTokens function\nMy code:\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/IERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/SafeERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./MyToken.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyCrowdsale is Context, ReentrancyGuard, Ownable {\nusing SafeMath for uint256;\nusing SafeERC20 for IERC20;\n\naddress payable private _startupAddr;\n\nuint256 private _tokenPrice; \nuint256 private _tokensSold;\n\n// Amount of wei raised\nuint256 private _weiRaised;\n\nIERC20 private _tokenContract;\nTokenWhitelist private _whitelist;\n\n/**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\nevent TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\nconstructor(\n uint256 rate, \n address payable startupAddr, \n MyToken token, \n TokenWhitelist whitelist_ \n)\npublic\n{\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n}\n\nfunction tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n}\n\nfunction tokensSold() public view returns (uint256) {\n return _tokensSold;\n}\n\nfunction totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n}\n\n/**\n * @return the amount of wei raised.\n */\nfunction weiRaised() public view returns (uint256) {\n return _weiRaised;\n}\n\n/**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\nfunction () external payable {\n buyTokens(_msgSender());\n}\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\nfunction buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n}\n\n/**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n}\n\n/**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n}\n\n/**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\nfunction _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.safeTransfer(beneficiary, tokenAmount);\n}\n\n/**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\nfunction _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _deliverTokens(beneficiary, tokenAmount);\n}\n\n/**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n}\n\n/**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\nfunction _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.div(_tokenPrice);\n}\n\n/**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\nfunction _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n}\n}\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by Skyge on Nov 24, 2020\n\n Skyge\n\n Can you provide the contract MyToken.sol and TokenWhitelist.sol, or can you verify the contract on a testnet?\n\n post by abcoathup on Nov 24, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @pedromtelho,\nYou appear to have cloned a crowdsale. I would suggest extending the Crowdsales from OpenZeppelin Contracts: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nHave you transferred an amount of your token to the crowdsale so it has tokens to sell?\n\n post by pedromtelho on Nov 27, 2020\n\n pedromtelho\n\n Exactly! I thought that some functions could be called by other people and I do not want it so I decided to override them using onlyOwner function. I’ll post my contracts here.\nMyToken.sol:\npragma solidity ^0.5.2;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Mintable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Pausable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyToken is ERC20, ERC20Pausable, ERC20Mintable, Ownable {\n string private _name;\n string private _symbol;\n uint8 private _decimals = 18;\n uint256 private _exp = 10**18;\n uint256 private _totalSupply;\n\nTokenWhitelist public whitelist;\n\nmapping (address => uint256) private _balances;\n\nmapping (address => mapping (address => uint256)) private _allowances;\n\n// ... see \"Tokens\" for more info\nconstructor(string memory name, string memory symbol, address startupAddr, TokenWhitelist _whitelist, uint256 totalSupply) public\n ERC20Mintable()\n ERC20Pausable()\n {\n _name = name;\n _symbol = symbol;\n whitelist = _whitelist;\n mint(startupAddr, totalSupply);\n }\n\nfunction name() public view returns (string memory) {\n return _name;\n}\n\nfunction symbol() public view returns (string memory) {\n return _symbol;\n}\n\nfunction decimals() public view returns (uint8) {\n return _decimals;\n}\n\nfunction totalSupply() public view returns (uint256) {\n return _totalSupply;\n}\n\nfunction balanceOf(address account) public view returns (uint256) {\n return _balances[account];\n}\n\nfunction mint(address toAccount, uint256 amount) public onlyMinter whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(toAccount), \"Account is not whitelisted\");\n _mint(toAccount, amount);\n return true;\n}\n\nfunction transfer(address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(_msgSender(), recipient, amount);\n return true;\n}\n\nfunction allowance(address owner, address spender) public view returns (uint256) {\n return _allowances[owner][spender];\n}\n\nfunction approve(address spender, uint256 amount) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, amount);\n return true;\n}\n\nfunction transferFrom(address sender, address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(sender), \"Sender is not whitelisted\");\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(sender, recipient, amount);\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n return true;\n}\n\nfunction increaseAllowance(address spender, uint256 addedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n return true;\n}\n\nfunction decreaseAllowance(address spender, uint256 subtractedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n return true;\n}\n\nfunction _mint(address account, uint256 amount) internal {\n require(account != address(0), \"ERC20: mint to the zero address\");\n uint256 convertedAmount = amount*_exp;\n _totalSupply = _totalSupply.add(convertedAmount);\n _balances[account] = _balances[account].add(convertedAmount);\n emit Transfer(address(0), account, convertedAmount);\n}\n\nfunction _transfer(address sender, address recipient, uint256 amount) internal {\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n require(whitelist.checkWhitelisted(sender), \"Sender is not checked in whitelist\");\n require(whitelist.checkWhitelisted(recipient), \"Sender is not checked in whitelist\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n _balances[recipient] = _balances[recipient].add(amount);\n emit Transfer(sender, recipient, amount);\n}\n\nfunction _approve(address owner, address spender, uint256 amount) internal {\n require(owner != address(0), \"ERC20: approve from the zero address\");\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\nemit Approval(owner, spender, amount);}}\n\nMyCrowdsale.sol:\npragma solidity ^0.5.2;\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n import \"./MyToken.sol\";\n import \"./TokenWhitelist.sol\";\n\n contract MyCrowdsale is Context, ReentrancyGuard, Ownable {\n using SafeMath for uint256;\n\n address payable private _startupAddr;\n\n uint256 private _tokenPrice; // preço do token\n uint256 private _tokensSold; // tokens vendidos\n\n // Amount of wei raised\n uint256 private _weiRaised;\n\n MyToken private _tokenContract; // contrato do token\n TokenWhitelist private _whitelist;\n\n mapping(address => uint256) private _tokenRequests;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n constructor(\n uint256 rate, // preço\n address payable startupAddr, // endereço da startup\n MyToken token, // endereço do token da startup\n TokenWhitelist whitelist_ // whitelist da nossa empresa\n )\n public\n {\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n }\n\n function tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n }\n\n function tokensSold() public view returns (uint256) {\n return _tokensSold;\n }\n\n function totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n }\n\n /**\n * @return the amount of wei raised.\n */\n function weiRaised() public view returns (uint256) {\n return _weiRaised;\n }\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\n function buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n }\n\n function withdrawTokens(address beneficiary) public {\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n require(_tokenRequests[beneficiary] != 0, \"Crowdsale: beneficiary has no orders\");\n uint256 amount = _tokenRequests[beneficiary];\n require(amount > 0, \"PostDeliveryCrowdsale: beneficiary is not due any tokens\");\n\n _tokenRequests[beneficiary] = 0;\n _tokenContract.transferFrom(_startupAddr, beneficiary, amount);\n }\n\n function tokenRequests(address beneficiary) public view returns (uint256) {\n return _tokenRequests[beneficiary];\n }\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.transferFrom(_startupAddr, beneficiary, tokenAmount);\n }\n\n function _buyOrder(address beneficiary, uint256 tokenAmount) internal {\n _tokenRequests[beneficiary] += tokenAmount;\n _tokensSold += tokenAmount;\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _buyOrder(beneficiary, tokenAmount);\n // _deliverTokens(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 _exp = 10**18;\n uint256 _mult = weiAmount.mul(_exp);\n return _mult.div(_tokenPrice);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n }\n}\n\nTokenWhitelist.sol:\n pragma solidity ^0.5.2;\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n\n// Contrato da nossa whitelist deve ser o primeiro deploy \n\ncontract TokenWhitelist is Ownable {\n mapping(address => bool) private whitelist;\n\n event Whitelisted(address indexed wallet);\n event Dewhitelisted(address indexed wallet);\n\n function enableWallet(address _wallet) public onlyOwner {\n require(_wallet != address(0), \"Invalid wallet\");\n whitelist[_wallet] = true;\n emit Whitelisted(_wallet);\n }\n\n function disableWallet(address _wallet) public onlyOwner {\n whitelist[_wallet] = false;\n emit Dewhitelisted(_wallet);\n }\n\n function checkWhitelisted(address _wallet) public view returns (bool) {\n return whitelist[_wallet];\n }\n}\n\n post by Skyge on Nov 28, 2020\n\n Skyge\n\n Sorry, I tried to deploy it on a testnet, but always get an error when compile the contracts, so can you just verify it on the testnet?\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n pedromtelho\n\n Hi @pedromtelho,\nYou may want to take a step back and start with a simple example: Simple ERC20 Crowdsale.\nI would suggest extending OpenZeppelin Contracts Crowdsales rather than creating your own. This would also make the code much easier to read (and for your audits, audit). https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n REVERT Error when buying token from crowdsale\n\n Contracts\n\n erc20\n\n 3\n\n 456\n\n May 2021\n\n Crowdsale: revert when buying tokens\n\n Contracts\n\n erc20,crowdsale\n\n 4\n\n 2.4k\n\n May 2019\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021","tokens":5397,"squid":"ink-security_audits","role":"Sentinel","at":1791264879163,"hash":"dd0a7920c9bfa0f038bbaceaa845364b24ecd62b"}
{"url":"https://support.io.net/en/support/solutions/articles/156000101702-block-rewards-nomination-eligibility-status","domain":"support.io.net","title":"Block Rewards Eligibility :","text":"Block Rewards Nomination Eligibility Status\n\n The Block Rewards Nomination Eligibility Status section provides an overview of whether your worker meets the requirements to participate in block rewards. Below are the criteria, with examples as shown in the image for clarity:Eligibility Requirements1️⃣ Cluster Creation Test: Passed Explanation: This verifies that the worker has successfully joined the IO.net cluster. A passed test ensures the worker is properly configured and ready to operate within the cluster.Action Needed: If this fails, check your worker’s setup and network configuration.2️⃣ SOL Wallet Address: Associated Intro StatementExplanation: The worker must be linked to a valid Solana wallet address to receive block rewards. This ensures the payout system knows where to send earned rewards.Action Needed: Associate a wallet address through the profile dashboard if not already linked.We do not support Exchange Deposit Addresses (custodial wallets) for recieving Block Rewards.\nIf your account in Account Settings is linked to an Exchange Deposit Address, you will be unable to claim Block rewards, participate in seasonal events, or receive worker earnings. To ensure uninterrupted access to these benefits, please update your wallet to a Self-Custodial Wallet as soon as possible.3️⃣ Processor Eligible:  (e.g.GeForce RTX 4090) Explanation:  In this case, the GeForce RTX 3070 is eligible for block rewards.Action Needed: If marked ineligible, verify your device compatibility with IO.net’s supported hardware list.4️⃣ Connectivity Tier Eligible:Explanation: The device’s connectivity tier must be greater than 0 to qualify.Action Needed: If this fails, check your internet connection speed and stability. Upgrade your connection if needed.5️⃣ Uptime: Device Has Been Up for More Than 5 HoursExplanation: The worker must maintain at least 5 hours of continuous uptime to demonstrate reliability. If the worker is restarted, the uptime counter resets, and the device must complete another uninterrupted 5-hour period to meet this requirement. Action Needed: Ensure the device runs continuously.6️⃣ PoW (zkTFLOPs Proof): Last Task Valid and Within Current HourExplanation: This ensures that the worker has completed the most recent Proof-of-Work (PoW) task successfully and within the current hour. It confirms the worker's ability to contribute to the network in real-time.Action Needed: If this fails, check your worker logs for errors in PoW tasks. Ensure GPU and CPU resources are properly configured. If still failing please check out:Windows - Why Is My Worker Failing PoW (Proof of Work)Linux - Why Is My Worker Failing PoW (Proof of Work)7️⃣ Device has <4 VRAM test failures (2) or last failure was over 12 hours agoExplanation: Passing the VRAM test is required for Block Reward eligibility. The test ensures the device can join clusters, maintain participation, and successfully complete VRAM-utilizing tasks. Devices are allowed up to 3 failures per calendar month. On the 4th failure, Block Reward eligibility is suspended for 12 hours but reinstates automatically if no additional failures occur.Action Needed: Ensure the device has a stable network connection and close all non-essential applications, leaving only Docker/Docker Desktop and the worker containers running.   8️⃣ Device Has Sufficient $IO Stake: (e.g 400/400)Explanation: A minimum amount of $IO tokens must be staked for the worker to qualify for block rewards. In this case, the required stake of 400 $IO is met.Action Needed: If the stake is insufficient, deposit the required $IO.\n\n Was this article helpful?\n\n That’s Great!\n Thank you for your feedback\n\n Sorry! We couldn't be helpful\n Thank you for your feedback\n\n Feedback sent\n We appreciate your effort and will try to fix the article\n\n 0 of 0","tokens":951,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791264883349,"hash":"7604080f644fc1a25c04f99ec503a3cc21cf37e8"}
{"url":"https://forum.openzeppelin.com/t/revert-safeerc20-low-level-call-failed-when-trying-to-run-buytokens-function-in-a-crowdsale/4753/4","domain":"forum.openzeppelin.com","title":"Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Nov 2020\n\n 4 / 6\n\n Nov 2020\n\n Dec 2020\n\n post by pedromtelho on Nov 24, 2020\n\n pedromtelho\n\n I’m getting error VM Exception while processing transaction: revert SafeERC20: low-level call failed\nwhen trying to run buyTokens function\nMy code:\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/IERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/SafeERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./MyToken.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyCrowdsale is Context, ReentrancyGuard, Ownable {\nusing SafeMath for uint256;\nusing SafeERC20 for IERC20;\n\naddress payable private _startupAddr;\n\nuint256 private _tokenPrice; \nuint256 private _tokensSold;\n\n// Amount of wei raised\nuint256 private _weiRaised;\n\nIERC20 private _tokenContract;\nTokenWhitelist private _whitelist;\n\n/**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\nevent TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\nconstructor(\n uint256 rate, \n address payable startupAddr, \n MyToken token, \n TokenWhitelist whitelist_ \n)\npublic\n{\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n}\n\nfunction tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n}\n\nfunction tokensSold() public view returns (uint256) {\n return _tokensSold;\n}\n\nfunction totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n}\n\n/**\n * @return the amount of wei raised.\n */\nfunction weiRaised() public view returns (uint256) {\n return _weiRaised;\n}\n\n/**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\nfunction () external payable {\n buyTokens(_msgSender());\n}\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\nfunction buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n}\n\n/**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n}\n\n/**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n}\n\n/**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\nfunction _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.safeTransfer(beneficiary, tokenAmount);\n}\n\n/**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\nfunction _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _deliverTokens(beneficiary, tokenAmount);\n}\n\n/**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\nfunction _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n}\n\n/**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\nfunction _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n return weiAmount.div(_tokenPrice);\n}\n\n/**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\nfunction _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n}\n}\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by Skyge on Nov 24, 2020\n\n Skyge\n\n Can you provide the contract MyToken.sol and TokenWhitelist.sol, or can you verify the contract on a testnet?\n\n post by abcoathup on Nov 24, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @pedromtelho,\nYou appear to have cloned a crowdsale. I would suggest extending the Crowdsales from OpenZeppelin Contracts: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nHave you transferred an amount of your token to the crowdsale so it has tokens to sell?\n\n post by pedromtelho on Nov 27, 2020\n\n pedromtelho\n\n Exactly! I thought that some functions could be called by other people and I do not want it so I decided to override them using onlyOwner function. I’ll post my contracts here.\nMyToken.sol:\npragma solidity ^0.5.2;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Mintable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Pausable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyToken is ERC20, ERC20Pausable, ERC20Mintable, Ownable {\n string private _name;\n string private _symbol;\n uint8 private _decimals = 18;\n uint256 private _exp = 10**18;\n uint256 private _totalSupply;\n\nTokenWhitelist public whitelist;\n\nmapping (address => uint256) private _balances;\n\nmapping (address => mapping (address => uint256)) private _allowances;\n\n// ... see \"Tokens\" for more info\nconstructor(string memory name, string memory symbol, address startupAddr, TokenWhitelist _whitelist, uint256 totalSupply) public\n ERC20Mintable()\n ERC20Pausable()\n {\n _name = name;\n _symbol = symbol;\n whitelist = _whitelist;\n mint(startupAddr, totalSupply);\n }\n\nfunction name() public view returns (string memory) {\n return _name;\n}\n\nfunction symbol() public view returns (string memory) {\n return _symbol;\n}\n\nfunction decimals() public view returns (uint8) {\n return _decimals;\n}\n\nfunction totalSupply() public view returns (uint256) {\n return _totalSupply;\n}\n\nfunction balanceOf(address account) public view returns (uint256) {\n return _balances[account];\n}\n\nfunction mint(address toAccount, uint256 amount) public onlyMinter whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(toAccount), \"Account is not whitelisted\");\n _mint(toAccount, amount);\n return true;\n}\n\nfunction transfer(address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(_msgSender(), recipient, amount);\n return true;\n}\n\nfunction allowance(address owner, address spender) public view returns (uint256) {\n return _allowances[owner][spender];\n}\n\nfunction approve(address spender, uint256 amount) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, amount);\n return true;\n}\n\nfunction transferFrom(address sender, address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(sender), \"Sender is not whitelisted\");\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(sender, recipient, amount);\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n return true;\n}\n\nfunction increaseAllowance(address spender, uint256 addedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n return true;\n}\n\nfunction decreaseAllowance(address spender, uint256 subtractedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n return true;\n}\n\nfunction _mint(address account, uint256 amount) internal {\n require(account != address(0), \"ERC20: mint to the zero address\");\n uint256 convertedAmount = amount*_exp;\n _totalSupply = _totalSupply.add(convertedAmount);\n _balances[account] = _balances[account].add(convertedAmount);\n emit Transfer(address(0), account, convertedAmount);\n}\n\nfunction _transfer(address sender, address recipient, uint256 amount) internal {\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n require(whitelist.checkWhitelisted(sender), \"Sender is not checked in whitelist\");\n require(whitelist.checkWhitelisted(recipient), \"Sender is not checked in whitelist\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n _balances[recipient] = _balances[recipient].add(amount);\n emit Transfer(sender, recipient, amount);\n}\n\nfunction _approve(address owner, address spender, uint256 amount) internal {\n require(owner != address(0), \"ERC20: approve from the zero address\");\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\nemit Approval(owner, spender, amount);}}\n\nMyCrowdsale.sol:\npragma solidity ^0.5.2;\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n import \"./MyToken.sol\";\n import \"./TokenWhitelist.sol\";\n\n contract MyCrowdsale is Context, ReentrancyGuard, Ownable {\n using SafeMath for uint256;\n\n address payable private _startupAddr;\n\n uint256 private _tokenPrice; // preço do token\n uint256 private _tokensSold; // tokens vendidos\n\n // Amount of wei raised\n uint256 private _weiRaised;\n\n MyToken private _tokenContract; // contrato do token\n TokenWhitelist private _whitelist;\n\n mapping(address => uint256) private _tokenRequests;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n constructor(\n uint256 rate, // preço\n address payable startupAddr, // endereço da startup\n MyToken token, // endereço do token da startup\n TokenWhitelist whitelist_ // whitelist da nossa empresa\n )\n public\n {\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n }\n\n function tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n }\n\n function tokensSold() public view returns (uint256) {\n return _tokensSold;\n }\n\n function totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n }\n\n /**\n * @return the amount of wei raised.\n */\n function weiRaised() public view returns (uint256) {\n return _weiRaised;\n }\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\n function buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n }\n\n function withdrawTokens(address beneficiary) public {\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n require(_tokenRequests[beneficiary] != 0, \"Crowdsale: beneficiary has no orders\");\n uint256 amount = _tokenRequests[beneficiary];\n require(amount > 0, \"PostDeliveryCrowdsale: beneficiary is not due any tokens\");\n\n _tokenRequests[beneficiary] = 0;\n _tokenContract.transferFrom(_startupAddr, beneficiary, amount);\n }\n\n function tokenRequests(address beneficiary) public view returns (uint256) {\n return _tokenRequests[beneficiary];\n }\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.transferFrom(_startupAddr, beneficiary, tokenAmount);\n }\n\n function _buyOrder(address beneficiary, uint256 tokenAmount) internal {\n _tokenRequests[beneficiary] += tokenAmount;\n _tokensSold += tokenAmount;\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _buyOrder(beneficiary, tokenAmount);\n // _deliverTokens(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 _exp = 10**18;\n uint256 _mult = weiAmount.mul(_exp);\n return _mult.div(_tokenPrice);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n }\n}\n\nTokenWhitelist.sol:\n pragma solidity ^0.5.2;\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n\n// Contrato da nossa whitelist deve ser o primeiro deploy \n\ncontract TokenWhitelist is Ownable {\n mapping(address => bool) private whitelist;\n\n event Whitelisted(address indexed wallet);\n event Dewhitelisted(address indexed wallet);\n\n function enableWallet(address _wallet) public onlyOwner {\n require(_wallet != address(0), \"Invalid wallet\");\n whitelist[_wallet] = true;\n emit Whitelisted(_wallet);\n }\n\n function disableWallet(address _wallet) public onlyOwner {\n whitelist[_wallet] = false;\n emit Dewhitelisted(_wallet);\n }\n\n function checkWhitelisted(address _wallet) public view returns (bool) {\n return whitelist[_wallet];\n }\n}\n\n post by Skyge on Nov 28, 2020\n\n Skyge\n\n Sorry, I tried to deploy it on a testnet, but always get an error when compile the contracts, so can you just verify it on the testnet?\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n pedromtelho\n\n Hi @pedromtelho,\nYou may want to take a step back and start with a simple example: Simple ERC20 Crowdsale.\nI would suggest extending OpenZeppelin Contracts Crowdsales rather than creating your own. This would also make the code much easier to read (and for your audits, audit). https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n REVERT Error when buying token from crowdsale\n\n Contracts\n\n erc20\n\n 3\n\n 456\n\n May 2021\n\n Crowdsale: revert when buying tokens\n\n Contracts\n\n erc20,crowdsale\n\n 4\n\n 2.4k\n\n May 2019\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021","tokens":5397,"squid":"ink-security_audits","role":"Sentinel","at":1791264890540,"hash":"5f83c5a7666445994529499119445686c7779737"}
{"url":"https://support.io.net/en/support/solutions/articles/156000373962-how-to-stake-your-worker","domain":"support.io.net","title":"How to Stake Your Worker :","text":"How to Stake Your Worker\n\n Staking $IO is one of the requirements for a worker to become Cluster Ready—which means it's eligible to be hired on io.net and start earning Block Rewards. Follow these steps to stake your worker:1️⃣ Open the Staking PageIn your io.net dashboard, go to IO Worker → Staking.Here you'll see your wallet balance, active stake, cooldown stake, and recent rewards.2️⃣ Connect Your WalletTo Stake $IO, you'll need to connect your supported crypto wallet (e.g., Phantom).Click Connect Crypto Wallet.Choose your wallet.Once connected, your wallet ID will appear on the page.Staking more than the required amount will not increase rewards.\n3️⃣ Stake to Your WorkerIn the Manage Your Stake & Devices section, find your worker you want to stake.Under Staking Actions, click Stake and enter the required $IO amount.Confirm the transaction in your wallet.You can unstake your tokens at any time using the Unstake option next to each staked device. Once you do, your tokens will enter a 14-day cooldown period before they can be withdrawn. Keep in mind that tokens in cooldown don’t count toward the staking requirement for your device to receive Block Reward\n\n Was this article helpful?\n\n That’s Great!\n Thank you for your feedback\n\n Sorry! We couldn't be helpful\n Thank you for your feedback\n\n Feedback sent\n We appreciate your effort and will try to fix the article\n\n 0 of 0","tokens":348,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791264893575,"hash":"79ddfe8b3f67434c1d859b4326b40d813d13910a"}
{"url":"https://console.optimism.io/faucet","domain":"console.optimism.io","title":"Dev Console","text":"HomeGetting StartedFaucetRelayerTemplate LibrarySuperchain SafeSuperchain RPCDocsGet a grantSuperchain interop is in active development. Click here to get ahead and learn how to tap into Superchain network effects today.FaucetGet free testnet tokens for building applications on the Superchain.Sign in to use the faucetAnyone can claim 0.01 test ETH every 24 hours, or verify your onchain identity for more tokens. NetworkOP SepoliaBase SepoliaUnichain SepoliaInk SepoliaMinato SepoliaWorldchain SepoliaZora SepoliaMode SepoliaLisk SepoliaCyber SepoliaMetal SepoliaBOB SepoliaShape SepoliaSepoliaFAQsThis site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.","tokens":173,"squid":"ink-governance","role":"Council Listener","at":1791264895323,"hash":"64da022d82ea9546bbf3879e722f5bfd9b4bf220"}
{"url":"https://docs.pyth.network/price-feeds/core/pull-updates","domain":"docs.pyth.network","title":"What is a Pull Oracle? | Pyth Developer Hub","text":"Pyth CoreWhat is a Pull Oracle?Learn how Pyth's pull oracle model differs from traditional push oraclesMost oracles today are push oracles where the oracle operator is responsible for submitting price updates to the blockchain.\nPyth is different: it is a pull oracle where anyone can permissionlessly update the on-chain price.\nThis document explains the differences between push and pull oracles.\nPush Oracles\nPush oracles periodically update an on-chain price based on external trigger conditions.\nThe oracle has a smart contract that stores the current price.\nThe contract also has a set of permissioned operators who are authorized to update the price.\nThe oracle operators then commit to updating the on-chain price at a specific cadence, for example, once every 30 minutes or if the price moves by 1%.\nThus, in a push oracle, the on-chain price is periodically updated, regardless of whether or not anyone is using it.\nPull Oracles\nIn contrast to push oracles, pull oracles only update the on-chain price when requested.\nThere are different ways for users to request an updated price from a pull oracle.\nSome pull oracles respond to on-chain requests: applications send one transaction to request data from the oracle, which then submits the response in a second transaction.\nPyth uses a simpler system where users can request the latest price update from an off-chain service.\nAnyone can submit a price update to the on-chain Pyth contract, which verifies its authenticity and stores it for later use.\nThis system allows applications to use a single transaction flow that first updates the price then performs the necessary application logic.\nFor a more in-depth explanation on the differences between push and pull oracles, refer to the following video tutorial:\nHow to Build with Pyth's Pull Oracle Design: Pyth Tutorials\nComparing Push and Pull\n\nPush and pull oracles differ on a number of important dimensions:\n\nUpdate frequency -- In a push oracle, every price feed updates at a fixed update frequency.\nThe oracle operator determines the frequency, but it typically ranges from every 10 minutes to 1 hour.\nIn contrast, pull oracles can update at a much higher frequency.\nFor example, every Pyth price feed updates every 400 milliseconds.\nLatency -- An oracle's update frequency also affects its prices' latency.\nThe higher update frequencies of pull oracles allow applications to access lower-latency data.\nBlockchain support -- Pull oracles support a wide variety of different blockchains.\nPush oracles typically support a smaller number of blockchains, as each additional chain requires ongoing gas expenditures.\nPrice feed selection -- Similar to the item above, pull oracles also support a wide selection of price feeds.\nIn contrast, push oracles typically have a more limited selection.\nPush oracles generally cannot support a wide selection of feeds due to the gas cost of periodically updating each feed.\n\nA fundamental reason for these differences is that push oracles incur gas costs for price updates.\nThese gas costs limit their scalability across all of the dimensions above.\nIntegration Differences\nPush oracles and pull oracles require applications to integrate in different ways.\nWith a push oracle, applications typically read the current price out of a smart contract.\nSince the push oracle periodically updates the price, the application can assume the data in the smart contract is (reasonably) fresh.\nWith a pull oracle, applications need to update the on-chain price before reading it.\nDevelopers using Pyth can refer to How to Use Real-Time Price Data to learn how to perform these steps.on SuiList of Pyth price feed contract addresses on Sui networksWhy Update PricesUnderstand why Pyth pull-oracle integrations must refresh on-chain prices","tokens":944,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264905725,"hash":"324bcbc6843f63ba91092db203365ded1238fcfc"}
{"url":"https://docs.pyth.network/price-feeds/core/error-codes/evm","domain":"docs.pyth.network","title":"EVM Error Codes | Pyth Developer Hub","text":"Pyth CoreError CodesEVM Error CodesDecode the error codes emitted by Pyth EVM contractsThe following table contains the errors used in the Pyth Network's EVM contracts.\nThis information is derived from PythErrors.sol\nin the Pyth SDK and can be used to decode error codes programmatically.\nConsult Troubleshoot Errors on EVM Price Feeds Contract for more information on how to handle these errors.\nError CodesErrorError Description0xa9cb9e0dInvalidArgument()Function Arguments are invalid.0xe60dce71InvalidUpdateDataSource()Invalid data source of the provided updateData.0xe69ffeceInvalidUpdateData()UpdateData is invalid.0x025dbdd4InsufficientFee()Insufficient fee provided for the operation.0xde2c57faNoFreshUpdate()No new fresh updates available.0x45805f5dPriceFeedNotFoundWithinRange()No price feed found within the given range or it doesn't exists.0x14aebe68PriceFeedNotFound()Price feed not found or it is not pushed on-chain yet.0x19abf40eStalePrice()The requested price feed has not been updated recently enough.0x2acbe915InvalidWormholeVaa()Given message is not a valid Wormhole VAA.0x97363b35InvalidGovernanceMessage()Governance message is invalid0x63daeb77InvalidGovernanceTarget()Governance message is not for this contract.0x360f2d87InvalidGovernanceDataSource()Invalid data source for the governance message.0x88d1b847OldGovernanceMessage()Governance message is old.0x13d3ed82InvalidWormholeAddressToSet()The wormhole address to set in SetWormholeAddress is invalid.Error CodesReference error codes for Pyth price feedsSVM Error CodesDecode the error codes emitted by Pyth SVM contracts","tokens":400,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264917157,"hash":"707c93d26c2ba7c21f573d20cdd90175196afd3f"}
{"url":"https://ethereum.org/developers/docs/ides/","domain":"ethereum.org","title":"Integrated Development Environments (IDEs) | ethereum.org","text":"Integrated Development Environments (IDEs)Edit page (opens in a new tab)When it comes to setting up an integrated development environment (IDE) (opens in a new tab), programming applications on Ethereum is similar to programming any other software project. There are many options to choose from, so at the end of the day, pick the IDE or code editor that best suits your preferences. Most likely the best IDE choice for your Ethereum development is the IDE you already use for traditional software development.\nWeb-based IDEs\nIf you're looking to fiddle with code before you set up a local development environment, these web apps are custom-built for Ethereum smart contract development.\nRemix (opens in a new tab) - Web-based IDE with built in static analysis, and a test blockchain virtual machine\n\nDocs (opens in a new tab)\nGitter (opens in a new tab)\n\nChainIDE (opens in a new tab) - A cloud-based multi-chain IDE\n\nDocs (opens in a new tab)\nHelp forum (opens in a new tab)\n\nReplit (Solidity Starter - Beta) (opens in a new tab) - A customizable development environment for Ethereum with hot reloading, error checking, and first-class testnet support\n\nDocs (opens in a new tab)\n\nTenderly Sandbox (opens in a new tab) - A fast prototyping environment where you can write, execute, and debug smart contracts in the browser using Solidity and JavaScript\nEthFiddle (opens in a new tab) - Web-based IDE that lets you write, compile, and debug your smart contract\n\nGitter (opens in a new tab)\n\nDesktop IDEs\nMost established IDEs have built plugins to enhance the Ethereum development experience. At a minimum, they provide syntax highlighting for smart contract languages.\nVisual Studio Code - Professional cross-platform IDE with official Ethereum support\n\nVisual Studio Code (opens in a new tab)\nCode samples (opens in a new tab)\nGitHub (opens in a new tab)\n\nJetBrains IDEs (IntelliJ IDEA, etc.) - Essential tools for software developers and teams\n\nJetBrains (opens in a new tab)\nGitHub (opens in a new tab)\nIntelliJ Solidity (opens in a new tab)\n\nRemix Desktop - Experience Remix IDE on your local machine\n\nDownload (opens in a new tab)\nGitHub (opens in a new tab)\n\nPlugins and extensions\n\nsolidity (opens in a new tab) - Ethereum Solidity Language for Visual Studio Code\nSolidity + Hardhat for VS Code (opens in a new tab) - Solidity and Hardhat support by the Hardhat team\nPrettier Solidity (opens in a new tab) - Code formatter using prettier\n\nFurther reading\n\nEthereum IDEs (opens in a new tab) - Alchemy's list of Ethereum IDEs\n\nKnow of a community resource that helped you? Edit this page and add it!","tokens":652,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264923699,"hash":"79e625cdff031bd858940c44de61e4da92fe0107"}
{"url":"https://docs.pyth.network/price-feeds/core/troubleshoot/evm","domain":"docs.pyth.network","title":"Troubleshoot EVM Price Feeds Contract | Pyth Developer Hub","text":"Pyth CoreTroubleshootTroubleshoot EVM Price Feeds ContractResolve common issues when integrating Pyth price feeds on EVM chainsThis reference page is designed to help you troubleshoot common issues you may encounter when using Pyth Price Feeds on EVM chains.\nFollow the steps provided below to diagnose and resolve the issue.\nPyth Core on EVM chains was upgraded on August 26, 2026We recommend new integrations use the upgraded EVM contracts.Existing integrations on EVM chains in the upgrade were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.Contact the team if your chain isn't in the upgrade list.\ngetPriceNoOlderThan() reverts with StalePrice() or 0x19abf40e error\nThis error occurs when the requested price feed has not been updated within the specified age parameter.\nTo resolve this issue:\n\nUpdate the prices by calling updatePriceFeeds()\nby passing the latest updateData from Hermes.\nAnother method to fetch the price is getPriceUnsafe()\nIf the price feed is available, the method will return the latest prices with timestamp of last update.\nNOTE: getPriceUnsafe() method does not check the freshness of the price.\n\ngetPriceNoOlderThan() reverts with PriceFeedNotFound() or 0x14aebe68 error\nThis error occurs when the requested price feed has not been updated on-chain, or the price feed id is incorrect.\nTo resolve this issue:\n\nUpdate the prices by calling updatePriceFeeds()\nby passing the latest updateData from Hermes.\nCheck the entered price feed id and pyth-contract address to make sure they are correct.\n\nupdatePriceFeeds() reverts with InsufficientFee() or 0x025dbdd4 error\nThis error occurs when the fee provided for updating the price feed is insufficient.\nTo resolve this issue:\n\nFetch the latest fee by calling getUpdateFee() method and\nprovide the required fee to msg.value when calling updatePriceFeeds() method.\nTroubleshootDiagnose common issues affecting Pyth price feeds across supported ecosystemsSVM Price Feeds ContractNext Page","tokens":500,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264929577,"hash":"8ff4caabc693b9c528ce387c3fed04487434bd35"}
{"url":"https://governance.aave.com/t/wbtcs-and-others-pricing-mechanism-on-aave/10825/10","domain":"governance.aave.com","title":"WBTC's (and others) pricing mechanism on Aave - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 10\n min\n\n Nov 2022\n\n 10 / 11\n\n Dec 2022\n\n Jan 2023\n\n post by bgdlabs on Nov 25, 2022\n\n post by Pauljlei on Nov 26, 2022\n\n post by tbm on Nov 26, 2022\n\n post by bgdlabs on Nov 28, 2022\n\n post by omergoldberg on Nov 28, 2022\n\n post by OriN on Nov 28, 2022\n\n post by monet-supply on Nov 29, 2022\n\n post by CL_Michael on Dec 1, 2022\n\n CL_Michael\n\nHappy to help shed some light here. Chainlink Price Feeds incorporate three layers of data aggregation (data sources, node operators, oracle networks) to ensure accurate market prices are available for DeFi apps like Aave. Each oracle node in a feed sources data from multiple premium data aggregation firms that provide market-wide pricing derived from combining data from a wide range of established CEXs and DEXs.\nData from providers usually take the form of a Volume-Weighted Average Price (VWAP), or similar data aggregation methodology, to ensure broad market coverage. Additional data quality measures are also commonly employed, such as outlier exclusion, so the final aggregated data point is not impacted. Chainlink’s WBTC feeds follow this approach and provide adequate coverage of the Uniswap V3 WBTC markets.\nTo learn more, check out our blog post on the 3 levels of data aggregation as well as How Chainlink Price Feeds Secure DeFi for a more holistic overview.\n\nThanks for your in-depth analysis. However, we would advise against the use of on-chain TWAP oracles due to such oracles providing delayed market pricing (which could increase risks of toxic debt during high volatility) and a lack of sufficient market coverage by sourcing market data from only a single trading market. Liquidity for assets like WBTC can rapidly and unexpectedly shift across DEX/CEX venues, potentially putting the protocol and users at risk. As mentioned, Chainlink feeds provide market-wide coverage for assets (CEXs+DEXs), so such liquidity shifts are taken into account before a final aggregated value is produced.\nIf the community is interested in additional risk mitigation techniques around WBTC, I would also like to note that Chainlink does provide a WBTC Proof of Reserve feed on Ethereum mainnet, as well as a WBTC/BTC feed which could be used in the manner @monet-supply described if desired. In any case, we’re open to supporting any direction the Aave community decides to take regarding WBTC.\n\n post by tbm on Dec 1, 2022\n\n tbm\n\n Thank you for the additional information - it would be helpful to have the specific data sources ultimately outlined so that there is no guesswork required for independent participants. As it relates to WBTC, is it possible to weight BTC and WBTC oracle prices to provide a combined price which helps mute the all-or-none recovery/default tradeoff? The risk of permanent impairment from manipulated default or cascading liquidations would seem to support BTC pegged pricing, but the lack of transparency into centralized counterparties and limited legal precedent presents recovery and duration risk. Proof-of-reserve is certainly helpful, but by no means sufficient as it is blind to liabilities and liquidity runway, exposing participants to legal and process risk even if the centralized entity is a qualified custodian. To be clear, this is not an indictment of WBTC participants but rather just stating the obvious that under the assumption participants are good actors, recovery in a tail risk event may not be par and almost certainly will not be immediate, implying that a BTC peg price is suboptimal for even a manageable drawdown scenario.\n\n post by bgdlabs on Dec 4, 2022\n\n bgdlabs\n\n Leader\n\n From our perspective, it is not really a good option to almost under any circumstance consider swapping to pricing an asset directly from on-chain sources, like Uniswap V3 TWAP, no matter if the source looks healthy.\nAs mentioned previously by @CL_Michael , the different layers of the Chainlink Price Feeds are simply a net gain over fetching the price from an on-chain venue because:\n\nThey must (and do) include the most liquid venues on-chain (in this case the Uniswap V3 WBTC pools).\nAssuming the perfect functioning of the oracles’ infrastructure (we have no reason to assume the opposite), they add on top other types of protections, like awareness to “flash” manipulations, by dynamically removing outlier liquidity venues, those reporting anomalous price for a short period of time.\n\nIn addition, the cost of maintaining different approaches to pricing (e.g. Chainlink and directly Uniswap v3 TWAP) is not really something the community should consider taking on unless there is a complete major reason, which we don’t find realistic.\nFor extra context, it is worth it highlighting that other protocols of similar nature (e.g. Compound, Euler) progressively followed the lead of Aave in dropping their custom pricing solutions to use Chainlink, as the alternatives were only introducing additional risk, with not really advantages.\n\nGenerally, we are not really keen on introducing short-circuit behavior on pricing algorithms. The reason is that for it, important assumptions need to be taken about what an artificial market movement is. For example, if WBTC goes below 0.90 BTC, is there a legitimate reason for it? What about 0.95 BTC? What about 0.98 BTC?\nIf there is actually some security problem on WBTC, the most correct way of protecting the protocol is actually to be fully correct on pricing, in order to start liquidations as soon as the depeg event starts, that way reducing the room for bad debt. This can appear as going against the current pricing based on BTC/ETH, but the explanation is simple: currently, the protocol simply accepts the security risk aspect of WBTC, considering it not realistic to happen.\nTo include the security aspects of WBTC on the pricing, the cleanest solution is to use Chainlink Proof-of-Reserce, which factually acts like a short-circuit (we will be updating on the PoR topic from BGD pretty soon). This will be one of our following steps on the PoR integration.\n\nGiven that the different analyses on this thread point that using a WBTC feed could be preferable, we will create a Snapshot vote to swap to this approach.\nIf approved, from our side, we will start working on the technical details of this change, mainly:\n\nUsing an adapter price from the existing Chainlink feed vs using WBTC/ETH (or USD), and the considerations around this considering that Aave v2 Ethereum and Aave v3 Ethereum will have different oracle references (ETH in v2 vs USD in v3).\nThe proposal payload to factually do the swap.\n\n BGD. Operational oracles update\n\n 29 days later\n\n post by bgdlabs on Jan 2, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 264\n\n Aug 21\n\n [ARFC] Onboard wstLINK to Aave V3 Core Instance\n\n New Asset\n\n 15\n\n 3.1k\n\n 1d\n\n BTC.b on Aave Ethereum\n\n Assessments\n\n 1\n\n 75\n\n Sep 16\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n General\n\n 14\n\n 2.1k\n\n Jul 8","tokens":1819,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264939716,"hash":"ea63cf54c324c1f1cd4349cc46e66913c31be19e"}
{"url":"https://docs.pyth.network/price-feeds/core/troubleshoot/svm","domain":"docs.pyth.network","title":"Troubleshoot Solana Price Feeds Contract | Pyth Developer Hub","text":"Pyth CoreTroubleshootTroubleshoot Solana Price Feeds ContractFix build and runtime issues for Pyth price feeds on Solana and SVM chainsThis reference page is designed to help you troubleshoot common issues you may encounter when using Pyth Price Feeds on SVM chains.\nFollow the steps provided below to diagnose and resolve the issue.\n\nerror[E0277]: the trait bound PriceUpdateV2: anchor_lang::AccountDeserialize is not satisfied\nThis error happens when a program using the pyth-solana-receiver-sdk fails to compile. It is caused by an anchor-lang version mismatch.\nMake sure the transitive version of anchor-lang brought by pyth-solana-receiver-sdk\nmatches the version of anchor-lang of your program's Cargo.toml.\nYou can fix it by following these steps:\n\nCheck the version of anchor-lang in your Cargo.toml (in the example 0.29.0) call it x.y.z\nCheck the version of anchor-lang in the pyth-solana-receiver-sdk tree in Cargo.lock (in the example 0.30.1) call it a.b.c\nRun cargo update -p anchor-lang@a.b.c --precise x.y.z\nreplacing a.b.c and x.y.z by the versions in the previous steps. For example:\ncargo update -p anchor-lang@0.30.1 --precise 0.29.0\n\nEVM Price Feeds ContractPrevious PageAPI ReferenceExplore interactive Pyth API references for on-chain and off-chain integrations","tokens":321,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264940745,"hash":"e2d1307a670e381c427db07f5c88d854bde44fca"}
{"url":"https://ethereum.org/developers/tools/categories/contract-tooling/","domain":"ethereum.org","title":"Contract tooling | Developer builder resources | ⁦ethereum.org⁩","text":"CONTRACT TOOLINGResources found: 88 / 88Contract tooling(88)Contract frameworks(11)Ape FrameworkThe smart contract development tool for Pythonistas, Data Scientists, and Security ProfessionalsScaffold-ETH 2Scaffold-ETH 2 is a Next.js plus Hardhat or Foundry starter with wallet hooks, hot contract reload, local faucet utilities, and extension modules for full-stack dapp deployment.HuffHuff is a low-level assembly language and compiler for writing hand-optimized EVM bytecode, with development continuing in huff2. Builders reach for it when bytecode has to be tuned by hand.BrownieA Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.Remix ProjectA rich and accessible Web3 toolset for learning, building, and testing on multiple chainsStylus SDK (Rust)The Stylus SDK is the Rust SDK for writing smart contracts that run in Arbitrum's Stylus environment alongside the EVM. Rust builders use it when contract logic should be written in Rust rather than Solidity.BuildBearBuildBear is a hosted service that spins up a private testnet sandbox mirroring a real chain such as Ethereum, Polygon, BSC, or Arbitrum. Builders point tests at it to work against a private fork with real chain state.@nomicfoundation/slangslang from the Nomic Foundation is a modular Solidity compiler frontend with a parser, concrete syntax tree, and bindings. Builders import it when writing a linter, formatter, or other tool that has to understand Solidity source.WakeWake is a Python framework for testing, fuzzing, and static analysis of Solidity projects. Builders reach for it when they want to write contract tests and fuzzing campaigns in Python and run analysis over the same codebase.py-solc-xpy-solc-x is a Python wrapper and version manager for the solc Solidity compiler, used by Brownie and Ape style test suites. Python builders install it to fetch and switch compiler versions from their own scripts.MoccasinMoccasin is Cyfrin's Python-first workflow on Titanoboa for testing, fuzzing, and deploying Vyper written smart contracts.Deployment & devops(25)HardhatHardhat is a development environment to build and deploy your Ethereum softwareFoundryFoundry is a fast, portable Rust toolchain for Ethereum smart contract engineering that manages dependencies, compiles Solidity, runs fuzz and unit tests, deploys contracts, and drives scripted chain interaction from the terminal or Solidity automation scripts.PoWFaucetPoWFaucet is a modular testnet faucet for EVM chains with anti-abuse methods including a mining puzzle, captcha, IP limits, and Gitcoin Passport, and it backs the Sepolia proof-of-work faucet. Teams running a testnet self-host it to hand out test ETH without giving it all to one address.hardhat-deployhardhat-deploy is a Hardhat plugin for replicable deployments with named accounts, proxies, and diamonds. Builders install it when deployments must be repeatable across networks and track upgradeable contracts.eth-dockereth-docker is a Dockerized stack for deploying and managing execution, consensus, and validator clients on mainnet. Node operators use it to run a full node setup from configuration files instead of hand-installed binaries.Kurtosis ethereum-packageThe Kurtosis ethereum-package spins up reproducible multi-client Ethereum devnets, including mev-boost and supporting tooling. Builders run it when they need a local network that mirrors a real client mix.KurtosisKurtosis packages reproducible multi-service devnets so you can spin up realistic Ethereum or rollup stacks for integration tests faster than hand-maintained compose files.DAppNodeDAppNode is an operating system with an app store for running Ethereum execution and consensus clients and other node software on your own hardware. Someone setting up a home node installs it and picks client packages instead of configuring each service by hand.simple-optimism-nodesimple-optimism-node is a one-command Docker setup for running an OP Stack node. Builders run it to get their own Optimism node, in the same way eth-docker covers mainnet clients.ethereum-helm-chartsethereum-helm-charts are Helm charts from ethPandaOps for running Ethereum execution and consensus clients and related infrastructure on Kubernetes. Teams add them to a cluster rather than writing client manifests themselves.Chainlink FaucetsChainlink Faucets dispense testnet ETH and LINK across the supported test networks. Builders use them to fund an account before deploying and testing contracts on a testnet.DeckerDecker is a TypeScript CLI for creating configurable local Ethereum devnets with execution and consensus clients, relays, and block builders. Teams use its recipes for integration tests and infrastructure development.etherealethereal is a Go command line tool for everyday Ethereum tasks, including sending transactions, managing ENS records, transferring tokens, and inspecting accounts. Builders install it for one-off operations that do not justify a script.ImmunefiImmunefi is a bug bounty platform where projects post rewards for whitehats who find and responsibly disclose contract vulnerabilities. Teams list a program there to give researchers a paid route to report issues.rockethrocketh is a deployment and test harness for Ethereum contracts built around viem, keeping one record of deployments per network so scripts and tests agree. Builders use it when they want repeatable deployments without Hardhat, which the hardhat-deploy plugin wraps over the same code.Rocket Pool Smart NodeRocket Pool Smart Node is the command line package node operators run to set up and manage a Rocket Pool minipool, wrapping execution and consensus clients plus validator duties.CreateXCreateX is pcaversaccio's trustless universal deployer that wraps CREATE, CREATE2, and CREATE3-style flows so teams can launch contracts from predictable addresses without bespoke factory code.foundry-toolchain (GitHub Action)foundry-toolchain is the official GitHub Action that installs Foundry in continuous integration. Builders add it to a workflow so forge test and forge script run on every pull request.SedgeSedge is a command line setup tool from Nethermind that generates docker-compose configurations for execution, consensus, and validator client combinations. Builders run it to get a working node setup without writing the compose files.xdeployerHardhat plugin to deploy your smart contracts across multiple EVM chains with the same deterministic address. A total of 133 EVM chains are currently supported, including (almost) all OP-stack-powered chains.ethereum-genesis-generatorethereum-genesis-generator creates execution and consensus layer genesis state for a testnet and serves it over a web server. Devnet and rollup teams run it to produce the genesis files for a custom network.Create2DeployerCreate2Deployer is a minimal factory contract from pcaversaccio that wraps the CREATE2 opcode with safety checks so teams can deploy counterfactual contracts at deterministic addresses.txtxTxtx turns the stress, pain and tears of Smart Contract Infrastructure management by introducing Crypto Infrastructure as Code. Runbooks are the blueprint for Engineering Excellence, setting the new standard for Web3 Infrastructures.CannonCannon is a DevOps tool for protocols on Ethereum. It manages smart contract deployment and configuration for local development and live networks.EthPillarEthPillar is a setup script and terminal interface for installing and managing an Ethereum staking node with execution, consensus and MEV-Boost clients. Solo stakers run it to stand up a node without editing client configuration by hand.Smart contract libraries & utilities(27)OpenZeppelin ContractsOpenZeppelin Contracts are the go-to library for smart contract development.SoliditySolidity is an object-oriented, high-level language for implementing smart contracts.VyperPythonic Smart Contract Language for the EVMSolaritySolidity-Oriented Development ToolingSafe Smart Account (Gnosis Safe)Safe Smart Account is the widely deployed set of modular multisig smart-account contracts behind Safe. Wallet and treasury builders deploy or extend it to add multisignature control and account modules.SoladySolady by Vectorized collects aggressively optimized Solidity snippets from Merkle proofs to compression helpers, wrapping careful inline assembly in approachable APIs so advanced developers can ship gas-efficient patterns while learning cutting-edge optimization techniques from a living reference library.SolmateSolmate is a modern, opinionated collection of gas-optimized Solidity building blocks and utilities for smart contract development.Fe LanguageFe is a Rust-inspired language targeting the EVM; today you can explore Fe v2's type system via CLI or editor tooling even while bytecode generation is still evolving.SolhintSolhint is a Solidity linter you wire into editors or CI to enforce style rules and catch footgun patterns early.Vscode Solidity ExtensionJuan Blanco's VS Code Solidity extension adds syntax highlighting, compile commands, hover metadata, quick fixes, monorepo detection, optional Nethereum codegen, lint integration, and an LSP server.ERC721AERC721A is a gas-optimized ERC-721 implementation with cheap consecutive batch minting. Builders import it when an NFT contract mints several tokens to the same address at once and minting cost matters.IntelliJ SoliditySolidity plugin for IntelliJWhatsABIWhatsABI recovers selectors, proxies, and partial ABIs from bytecode alone-use it in wallets, explorers, or local tools when verified source is missing but you still need calldata decoding.PRBMathPRBMath is a smart contract library that adds support for fixed-point types and advanced math functions like logarithms and exponentials in Solidity. Operating with 18-decimal numbers, PRBMath is at the same time gas efficient and user-friendly.Solc-selectSolc-select is a command line utility for quickly installing and switching between Solidity compiler versions.Multicall3Multicall3 is the canonical contract for batching many reads or writes into a single transaction. Builders call it from contracts and scripts to fetch or update state across several contracts in one round trip.SolarBlazingly fast, modular Solidity compiler written in Rust by Paradigm. Designed as a contributor-friendly compiler stack for faster builds and better diagnostics.snekmateState-of-the-art, highly opinionated, hyper-optimised, and secureVyper smart contract building blocks.Prettier SolidityA Prettier plugin for automatically formatting your Solidity code.SolidState SoliditySolidState Solidity is an upgradeable-first contract library built around the diamond pattern of EIP-2535. Teams import it when contracts are organized as diamond facets from the start.weirollweiroll is an operation-chaining scripting language and set of contracts for composing many EVM calls into one transaction. Teams building call-routing or batching systems use it to express the call sequence as a script.Solidity Bytes Arrays Utils LibrarySolidity Bytes Utils is a classic library for concatenating, slicing, and casting dynamic bytes arrays in Solidity memory or storage-long maintained and widely forked across major protocols.solxA gas-efficient Solidity compiler for Ethereum powered by LLVM from the ZKsync team and collaborators. Works as a drop-in replacement for solc in workflows like Foundry and Hardhat.ABDKMath64x64ABDKMath64x64 is a Solidity library for 64.64-bit binary fixed-point math. Builders import it when a contract needs fixed-point arithmetic that Solidity does not provide natively.ERC721A-UpgradeableERC721A-Upgradeable is the proxy-upgradeable variant of the ERC721A implementation. Builders import it when a proxy-based NFT contract needs the batch minting design of ERC721A.DiamondscaffoldDiamondscaffold is a CLI tool designed to scaffold EIP-2535 diamond projects with an opinionated layout and scripts, making it faster to stand up modular upgradeable proxies.solidity-docgensolidity-docgen generates Markdown documentation for a Solidity project from its NatSpec comments. Teams run it so published docs stay in step with the contract source.ZK circuits & privacy(25)ZK EmailZK Email provides circuits and SDKs for proving facts about redacted email transcripts onchain. Useful when you want privacy-preserving identity or receipt checks without doxxing inboxes.SP1 (Succinct)SP1 from Succinct is a zero-knowledge virtual machine that proves correct execution of RISC-V programs, and it is used to generate proofs for rollups and bridges. Teams compile a Rust program with it when a proof must stand in for re-executing that program onchain.snarkjssnarkjs is a JavaScript and CLI toolkit for generating and verifying zkSNARK proofs, and for running common proving workflows in Node.js and the browser.CircomCircom is a domain-specific language and compiler for writing and compiling arithmetic circuits used in zero-knowledge proof systems.SemaphoreSemaphore is a zero-knowledge protocol for private group membership proofs, enabling anonymous signaling and authentication without revealing identity.Self ProtocolSelf Protocol provides open identity and proof primitives builders can embed when they need privacy-preserving verification flows tied to wallets or credentials.zkTLS/ TLSNotaryzkTLS / TLSNotary is an open protocol for proving properties of TLS sessions with MPC so verifiers can trust transcripts without seeing full plaintext.RISC Zero risc0-ethereumrisc0-ethereum holds the integration libraries and verifier contracts for using the RISC Zero zkVM with Ethereum and other EVM chains. Teams proving computation off chain import these crates to settle the resulting proofs onchain.MACIMACI (Minimal Anti-Collusion Infrastructure) uses zero-knowledge proofs to enable collusion-resistant, private voting and signaling systems on Ethereum.gnark-cryptognark-crypto provides elliptic curve and pairing cryptography for BN, BLS12, BLS24, and BW6 curves, and it is the backend of the gnark SNARK library. Go builders import it directly for curve and pairing math.MoproA toolkit that makes client-side zero-knowledge proving on mobile simple. Connects ZK proof systems (Halo2, Circom) to generate iOS, Android, and browser bindings, leveraging mobile GPU for improved performance.ZK-KitA monorepo of reusable zero-knowledge libraries across multiple languages (JavaScript, Solidity, Rust, Noir), offering well-tested implementations of cryptographic primitives like Merkle trees, Poseidon hash, and more.SonobeA modular folding library supporting multiple folding schemes (Nova, HyperNova, ProtoGalaxy, CycleFold) and decider backends (Groth16, KZG) for Incremental Verifiable Computation. Supports Arkworks, Circom, Noir, and Noname frontends.Anon AadhaarTools for building privacy-preserving applications using Indian government Aadhaar ID cards. Provides ZK circuits, TypeScript, Solidity, and React libraries to enable Aadhaar holders to prove residency without revealing personal data.ZKPassportPrivate identity verification using zero-knowledge proofs. Verify age, country, or proof of personhood without revealing any personal information. Mobile-first design with SDK for integration and onchain registry contracts.Halo2PSE's re-architected fork of Zcash's Halo2 PLONK proof system, featuring a KZG backend with Solidity verifier for economical L1 verification, support for multiple elliptic curves, and decoupled frontend/backend architecture.p0tionA toolkit for Groth16 Phase 2 Trusted Setup ceremonies. Helps developers create and manage trusted setups for ZK applications, with a companion webapp (DefinitelySetup) for monitoring and participation.arkworks algebraarkworks algebra is a set of Rust libraries for finite field, elliptic curve, and polynomial arithmetic, and it is the math layer under many SNARK and STARK toolchains. Rust builders add the ark crates when writing proving code from the ground up.LambdaworksLambdaworks is a Rust library of SNARK and STARK prover components that can be used piecemeal or assembled into a custom proving system. Teams pull its crates when building their own prover rather than adopting a finished one.op-succinctop-succinct is a proving engine that generates SP1 validity proofs for OP Stack rollups. Rollup teams deploy it to turn an OP Stack chain into a validity proof rollup, running it as a separate service.Plonky3Plonky3 is a toolkit of polynomial IOP building blocks for constructing custom SNARK and STARK proving systems, and several zkVM projects build on it. Rust builders add the p3 crates when writing their own proving system.powdrpowdr is a toolkit for accelerating and hardening zkVMs by moving specific computations into custom circuits. Teams running a zkVM use it to generate custom precompiles and check constraints, and its authors still describe the code as experimental.rsp (Succinct)rsp from Succinct generates zero-knowledge proofs of Ethereum and OP Stack block execution, built on Reth. Its authors describe it as a minimal work in progress that is not meant for production, so it mainly serves teams already building on SP1.snark-verifier (Axiom)snark-verifier generates gas-efficient onchain verifiers for halo2 SNARKs and is maintained by Axiom, forked from the original PSE repository. halo2 developers import the crate to produce the Solidity verifier that checks their proofs onchain.Perpetual Powers of TauAn ongoing (since 2019) zk-SNARK trusted setup ceremony for circuits up to 2^28 constraints, generating 530M+ powers of tau. A multi-party ceremony where security holds as long as one participant is honest.Suggest a resourceKnow a great builder resource that should be listed? Open an issue and share it with us.Suggest a resource (opens in a new tab)","tokens":4449,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264946847,"hash":"6ab634d2368a99d3baf78ea02b3d1c23d5eb32f4"}
{"url":"https://governance.aave.com/t/wbtcs-and-others-pricing-mechanism-on-aave/10825/1","domain":"governance.aave.com","title":"WBTC's (and others) pricing mechanism on Aave - Governance - Aave","text":"WBTC’s (and others) pricing mechanism on Aave \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 2\n\n read \n\n 10\n min\n\n TL;DR\n\n Context\n\n WBTC\n\n And what about other similar assets?\n\n “Stable” assets, reserve-backed\n\n Bridged assets\n\n Path forward on WBTC (and others)\n\n Nov 2022\n\n 1 / 11\n\n Nov 2022\n\n Jan 2023\n\n post by bgdlabs on Nov 25, 2022\n\n bgdlabs\n\n Leader\n\n TL;DR\nGive some visibility to the Aave community about the pricing mechanism on Aave (oracle), specifically about WBTC, but possible to extend to similar asset types.\nWe don’t see any problem with WBTC at the moment, but given its importance, its pricing strategy should have visibility and be opened to discussion.\n\nContext\nAs probably the broad Aave community is aware, pricing assets on Aave is done via integration with price feeds of the Chainlink network. From the protocol perspective, this integration is fairly simple: every asset address has associated with another smart contract address, in charge of providing a numeric price; this address is (generally) one Chainlink price feed smart contract for a pair ASSET/ETH (or USD).\nWe used “generally” before because there are exceptions. They are required when, for example, due to the complex nature of the asset, apart from querying an ASSET/ETH (or USD) feed, you also need to apply some extra numeric transformation on top. One clear case is what sometimes happens with AMM LP tokens, on which, if not possible via Chainlink directly, it is necessary to have an adapter smart contract calculating the final price of the LP token from the prices of underlying.\nWe could say that the requirement for adapters is the most “technical” decision side of the pricing of an asset, but there are some other aspects to consider, affecting assets like WBTC.\n\nWBTC\nPricing becomes more complex when dealing with assets like WBTC. For context, WBTC is an ERC20 tokenization on Ethereum of locked BTC assets on the Bitcoin network, with the objective of “using” BTC on Ethereum-living applications via WBTC.\nAs extensively explained on the WBTC portal, the system is based on a mechanism of Merchants (entities of the blockchain space, capable of request mint/burn of WBTC) and Custodians (mainly BitGo, keeping the BTC backing WBTC safe). This system has always been working well, and there is no symptom at the moment to think it doesn’t.\nBut from the Aave protocol perspective, the pricing of WBTC is actually different than other assets. Aave v2 Ethereum assumes the price of WBTC is equal to the price of BTC, by using a BTC/ETH feed.\nFor non-expert users, this can seem legitimate: if the system of creation/redeem of WBTC works and the BTC reserves are completely secure, why the price of WBTC would not be the same as BTC?\nFor more expert users, a counter-argument can be easily built: fundamentally, WBTC is not BTC. There is a strictly higher risk of holding WBTC vs BTC, doesn’t matter if this risk converges to 0 in some cases on the secondary market of WBTC, it just exists.\nFor the Aave protocol, the rationale is actually a bit more complex, and there is good reasons to price WBTC based on BTC.\nThe liquidity of WBTC is not the same as the liquidity of BTC. They are actually in a completely different order of magnitude, with WBTC in the hundreds of millions daily volume, versus BTC being the most liquid crypto-asset, with tens of billions of daily volume. When WBTC was initially listed on Aave v1, this difference liquidity-wise was even bigger. Factually, it was not a good idea to price WBTC depending only on the secondary market.\nBut why this makes a big difference to Aave? There are ~$3.7b WBTC minted at the moment (some of them not exactly on Ethereum, but bridged to other networks). Only Aave v2 Ethereum has ~$550m of WBTC collateral. In addition, the risk parameters of WBTC are relatively highly capital-efficient, with an 82% Liquidation Threshold. This is possible because the system “assumes” that the asset listed has the liquidity not of WBTC, but of BTC.\nDue to the previous reasons, the case of Aave is different to other protocols’: there is a strong rationale to keep the pricing of WBTC based on BTC/ETH, considering there is no real reason to be concerned about the WBTC security model.\nThat being said, all topics in the community should be opened for further discussion. And we would like the shed some extra light on the options.\n\nDuring Aave v1 and part of Aave v2 times, there is no doubt that using BTC-based pricing was a better approach, but at the moment, if we compare with assets with similar fundamentals (like reserves-backed stablecoins), it is legitimate to at least discuss if a WBTC/ETH (or USD) is really an acceptable mechanism, even considering the size of Aave.\nFrom our perspective, especially in these times of market down-trend, a change to a WBTC/ETH pricing (or USD) on all the Aave pools can be considered, but we think the following is necessary:\n\nRisk parties should evaluate how solid parameters like the Liquidation Threshold are for such a swap. Also taken into account how problematic is to lower it.\nA deeper analysis of sources of liquidity should be carried out. If the volume from the venues considered is not solid, swapping is definitely not a good idea if we compare it with the counter-party risk of the WBTC underlying system.\n\nIn addition, it is important to evaluate even deeper the underlying WBTC system, to understand the edge points of failures. This includes non-technical aspects like:\n\nMint/burn historic speed.\nLegal wrappers around the system and implications for holders, Merchants, and Custodians of WBTC.\n\nAnd technical ones, boiling down to:\n\nDoes the current security setup of WBTC give good assurances?\n\nIf there are meaningful concerns with the previous points (we don’t have any reason to think that at the moment), the usage of WBTC (non BTC) based feed can be considered.\n\nAnd what about other similar assets?\nWBTC is actually not the only asset of a similar type on the protocol. At the moment, Aave has similar ones in nature listed, even if they superficially look quite different.\nInterestingly enough, the strategy of pricing them is slightly inconsistent (but with rationale about it).\n“Stable” assets, reserve-backed\nThe so-called stablecoins, like USDC, USDT, or DAI. Generally, these are priced based on the secondary market, so the price feeds look like USDC/ETH, USDT/ETH, or DAI/ETH.\nThe reason not to price them, for example, via a USD/ETH feed is that complexity and trust in the underlying system have not been so so good in past times. That, combined with their type of usage, could introduce risks not easy to calculate if priced based on USD.\nBridged assets\nFactually an asset like DAI.e is a reserve-backed one, given that it is based on 1) reserves locked somewhere (in this case, a smart contract on Ethereum) 2) a security mechanism and procedure minting/burning (in this case, the Avalanche bridge mechanics) 3) some secondary market for the bridged asset itself (in this case, for example, AMMs on the Avalanche network).\nDifferent from stablecoins on Ethereum, bridged assets are actually priced on the underlying. This is obviously inconsistent, but the reason is that, for the Aave ecosystem to expand to new networks, there was not really any other solution than pricing, for example, DAI.e as DAI, given that using exclusively DAI.e secondary market liquidity could be extremely dangerous for the protocol.\nEven if this risk exists, it can be reduced by introducing extra components, like the Chainlink Proof-of-Reserve integration we are working on.\n\nPath forward on WBTC (and others)\nFrom the BGD technical side, we will try in the really short term to introduce as much consistency as possible with the current pricing policies of the ecosystem, obviously submitted to decisions of the community via governance. Also, we consider that applying Chainlink Proof-of-Reserve will really add better assurance on the different assets.\nRegarding WBTC, we have no reason to think Aave v2 Ethereum should swap to price it based on a WBTC/ETH feed, but we also believe it can be discussed.\nWe hope this post initiates some discussion for if anything should be improved or changed, more on the strategic and risk layers.\n\n Q4-2022 Risk-Off Measures\n\n Governance Weekly Recap\n\n [ARFC] Onboard tBTC to Aave v3 on Ethereum, Arbitrum and Optimism\n\n BGD. Working Day 365\n\n 4\n\n 2\n\n read \n\n 10\n min\n\n post by Pauljlei on Nov 26, 2022\n\n post by tbm on Nov 26, 2022\n\n post by bgdlabs on Nov 28, 2022\n\n post by omergoldberg on Nov 28, 2022\n\n post by OriN on Nov 28, 2022\n\n post by monet-supply on Nov 29, 2022\n\n post by CL_Michael on Dec 1, 2022\n\n post by tbm on Dec 1, 2022\n\n post by bgdlabs on Dec 4, 2022\n\n 29 days later\n\n post by bgdlabs on Jan 2, 2023\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 264\n\n Aug 21\n\n [ARFC] Onboard wstLINK to Aave V3 Core Instance\n\n New Asset\n\n 15\n\n 3.1k\n\n 1d\n\n BTC.b on Aave Ethereum\n\n Assessments\n\n 1\n\n 75\n\n Sep 16\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n General\n\n 14\n\n 2.1k\n\n Jul 8","tokens":2344,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264949942,"hash":"970bf794aee5a74c958af07031c44cc7f6d03ec3"}
{"url":"https://ethereum.org/developers/tools/categories/agent-tooling/","domain":"ethereum.org","title":"Agent tooling | Developer builder resources | ⁦ethereum.org⁩","text":"AGENT TOOLINGResources found: 29 / 29Agent tooling(29)MCP servers(13)1inch AI (MCP + Agent Skills)1inch AI is the official distribution point for the 1inch hosted MCP server and its agent skills, covering token swaps, limit orders, and SDK documentation search. Agent builders point Claude, Cursor, or Copilot at it so an agent can quote and place swaps.Alchemy MCP ServerThe Alchemy MCP Server gives AI clients access to Alchemy's blockchain data and RPC APIs across more than 100 chains. The hosted server at mcp.alchemy.com is the maintained route, while the open source repository holds the legacy local version.Coinbase Payments MCPThe Coinbase Payments MCP, now documented as the Agentic Wallet MCP, gives an AI agent tools to move and accept crypto payments through Coinbase's payment APIs. Builders add it when an agent needs to send or receive payments.CoinGecko MCPCoinGecko MCP is a remote Model Context Protocol server that gives AI agents access to CoinGecko's market data, including live prices and market caps, historical charts, DeFi and onchain pool data, and NFT collection analytics. It connects to Claude, Cursor, VS Code, and other MCP clients with minimal setup and is backed by CoinGecko's existing API.Morpho AgentsMorpho Agents is a beta interface built for AI agents to read, simulate, and write to Morpho's lending protocols. The User Agent product is a CLI and MCP server giving agents full read, simulate, and write access on Ethereum and Base with any wallet infrastructure, running every write through a simulation first, while the Builder Agent is an AGENTS.md knowledge base that turns a code agent into a Morpho integration expert.Tenderly MCPTenderly MCP is a Model Context Protocol server that brings Tenderly's blockchain development tools into AI assistants like Claude, exposing around 59 tools for transaction simulation, virtual testing environments, call trace and event inspection, and project management. It authenticates via OAuth and lets an agent set an active project, then run simulations and debug transactions without leaving the chat.Base MCPBase MCP is a Model Context Protocol server that connects AI agents to wallet and onchain tools on Base, with pre-built prompts and workflows for wallet operations, token transfers, and DeFi interactions. Nothing happens onchain without explicit approval since the server never holds or accesses private keys, instead constructing pending requests that a Base Account reviews and signs, and it ships with skill plugins covering Morpho, Moonwell, Aerodrome, Bankr, Avantis, Virtuals, and Uniswap.Foundry MCP ServerA simple, lightweight and fast MCP (Model Context Protocol) server that provides Solidity development capabilities using the Foundry toolchain (Forge, Cast, and Anvil).Blockscout MCP ServerWraps Blockscout APIs and exposes blockchain data (balances, tokens, NFTs, contract metadata) via MCP for use in AI agents and IDEs.WalletChan MCPWalletChan MCP is a local MCP adapter that connects AI agents to WalletChan wallet accounts through popup approvals, portfolio reads, swaps, and bridges, with optional delegated execution via ERC-7710 permissions. It lets local MCP clients like Claude Desktop, Cursor, and Codex interact with a WalletChan wallet across Base, Ethereum, Polygon, and Unichain.Slither MCP ServerMCP server that wraps Slither static analysis for Solidity smart contracts. Query contract metadata, functions, inheritance, call graphs, and run security detectors. Works with Foundry and Hardhat projects. Includes typed Python client for programmatic use.Pendle AIPendle AI is a set of AI plugins for Pendle Finance, packaged as MCP servers, that let agents trade yield tokens, manage LP positions, place limit orders, and query DeFi market data across seven EVM chains. It includes a Pendle V2 plugin for the core yield-trading protocol and a Boros plugin for interest-rate derivatives on Arbitrum, and is compatible with Claude Code and other MCP-based tools.QuickNode MCP ServerQuickNode MCP Server brings the power of QuickNode's blockchain infrastructure directly to your AI assistant.Agent skills(15)Trail of Bits Skills MarketplaceA Claude Code plugin marketplace from Trail of Bits providing skills to enhance AI-assisted security analysis, testing, and development workflows.Bankr SkillsBankr Skills is a catalog of plug-and-play agent skills built around Bankr's wallet, trading, and security infrastructure, letting builders add natural-language crypto trading, portfolio management, token launching, and DeFi operations to an agent without standing up wallet plumbing themselves. Specialized skills in the catalog cover things like deploying ERC-20 tokens with Uniswap V4 pools, cross-chain swaps across 50-plus chains via Symbiosis, and prediction-market intelligence, all routable from natural language across Base, Ethereum, Polygon, Solana, and Unichain.Pashov Audit Group SkillsClaude Code skills for Solidity security and development. solidity-auditor provides fast (typically under 5 min) security feedback on Solidity changes while you develop. Works with Claude Code CLI, VS Code Claude extension, and Cursor.ETHSkillsStructured Ethereum knowledge for AI agents - end-to-end guides from dApp idea to production. Skills cover wallets, L2s, standards, tools, DeFi, security, testing, indexing, and frontend UX. Fetch via URL, curl, or Claude plugin. No install required.uniswap-aiAI tools for building on Uniswap, including reusable skills, plugins, and agents for coding assistants integrating Uniswap workflows.OpenZeppelin SkillsAgent skills for secure smart contract development with OpenZeppelin Contracts libraries, including setup and upgrade workflows for Solidity and other ecosystems.QuillShield Security SkillsAI agent skills for smart contract security auditing. Ten plugins covering reentrancy, oracle/flash loan, proxy/upgrade, state invariants, semantic guards, and more. QuillShield methodology for vulnerabilities traditional static analysis misses. Works with Claude and Cursor.Cyfrin solskillClaude plugin with Solidity development standards for production-grade code. More thorough on testing, code quality, and smart contract sensitivity. Install via Cyfrin marketplace. By Patrick Collins and the Cyfrin team.sc-auditorSmart contract security auditor for Claude Code and Codex CLI. Integrates Slither, Aderyn, Cyfrin checklist, and Solodit findings. Map-Hunt-Attack methodology with four MCP tools for static analysis and findings search.OpenSea SkillsOpenSea Skills is a collection of agent skills for interacting with the OpenSea NFT marketplace, bundled under a router skill that directs an agent to the right sub-skill for its task. It covers querying NFT and collection data, buying and selling items through the Seaport protocol, swapping ERC20 tokens, configuring wallet signers, and registering gated AI tools, and installs via the Agent Skills spec with npx skills add.SCV ScanClaude Code skill that scans Solidity codebases for security vulnerabilities using 36 unique vulnerability types. Four-phase audit: load cheatsheet, syntactic and semantic codebase sweep, deep validation with reference files, and report. References from smart-contract-vulnerabilities.SIWASign In With Agent - lets servers authenticate AI agents and filter out humans. Built on ERC-8004 and ERC-8128, with SDK support for Next.js, Express, Hono, and Fastify.DefiLlama SkillsDefiLlama Skills is a collection of MCP skills exposing roughly 23 DeFi analytics tools built on DefiLlama data, covering full market snapshots of TVL, categories, chains, events, and stablecoins alongside guided workflows for protocol analysis, token research, chain ecosystem comparisons, yield strategy discovery, and risk assessment. It is aimed specifically at wiring DefiLlama's analytics into AI agents, distinct from the main DefiLlama analytics site.Bitrefill SkillBitrefill Skill is an agent skill that routes an AI assistant through buying gift cards, mobile top-ups, and eSIMs from Bitrefill across 180-plus countries and 1,500-plus brands, paid for with crypto, Lightning, USDC, or a prefunded Bitrefill balance. It detects the execution environment and available wallet integrations to pick the lowest-friction checkout path, supports guest checkout via Base wallet sign-in, and keeps user-facing messaging free of technical jargon like x402, MCP, or JWT.Across SkillsAcross Skills is a knowledge base and MCP endpoint for building crosschain applications on Across, covering the Across swap API, suggested fees, deposit tracking, and embedded crosschain actions that execute contract calls across different chains in a single transaction. It is aimed at both AI agents and developers building production crosschain apps, and is available under an MIT license.Other AI resources(1)request-wallet-signrequest-wallet-sign is a standalone npm CLI utility that lets AI agents request wallet signatures from a human through a browser interface without ever holding private keys. The agent passes transaction details as command-line arguments and the tool spins up a local server that displays a decoded, plain-English summary of the request, where the user connects a wallet, reviews the details, and approves the signing. It runs local-only by default for instant use, supports standard transactions, typed data, and personal signatures, and can use Cloudflare tunnels for cross-device signing, with a built-in timeout that auto-closes tabs once a request is handled.Suggest a resourceKnow a great builder resource that should be listed? Open an issue and share it with us.Suggest a resource (opens in a new tab)","tokens":2411,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264957067,"hash":"77ae2d727d13290ac1fc944f0fa1917fa67eef4c"}
{"url":"https://docs.pyth.network/price-feeds/core/contract-addresses/solana","domain":"docs.pyth.network","title":"on Solana/SVM | Pyth Developer Hub","text":"Pyth CoreContract Addresseson Solana/SVMList of Pyth price feed contract addresses on Solana and other SVM chainsThe Pyth Oracle consists of two different programs.\nPyth Core on Solana was upgraded on August 26, 2026We recommend new integrations use the upgraded Solana contracts.Existing integrations using the current addresses were automatically upgraded by the DAO on August 26, 2026. See the upgrade guide for details.\nThe Solana receiver program is deployed at the following addresses:\nNetworkProgram addressSolana Mainnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJSolana Devnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJEclipse Mainnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJEclipse Testnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJSonic Mainnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJSonic Testnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJSonic Devnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJAtlas Testnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJFogo Mainnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJFogo Testnetrec5EKMGg6MxZYaMdyBfgwp4d5rB9T1VQH5pJv5LtFJ\nThe Price feed program is deployed at the following addresses:\nNetworkProgram addressSolana MainnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTSolana DevnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTEclipse MainnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTEclipse TestnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTSonic MainnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTSonic TestnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTSonic DevnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTAtlas TestnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTFogo MainnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTFogo TestnetpythWSnswVUd12oZpeFP8e9CVaEqJg25g1Vtc2biRsTon EVM NetworksList of Pyth price feed contract addresses on supported EVM mainnets and testnetson SuiList of Pyth price feed contract addresses on Sui networks","tokens":471,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791264960126,"hash":"eec62b67925e725051ab595ae2eb4c33b5415370"}
{"url":"https://ethereum.org/developers/tools/tenderly-mcp/","domain":"ethereum.org","title":"Tenderly MCP | ⁦ethereum.org⁩","text":"Agent toolingTenderly MCPMCP serversMCP server · Debugging tools · Developer experienceWebsite (opens in a new tab)Tenderly MCP is a Model Context Protocol server that brings Tenderly's blockchain development tools into AI assistants like Claude, exposing around 59 tools for transaction simulation, virtual testing environments, call trace and event inspection, and project management. It authenticates via OAuth and lets an agent set an active project, then run simulations and debug transactions without leaving the chat.Related resourcesMorpho AgentsMorpho Agents is a beta interface built for AI agents to read, simulate, and write to Morpho's lending protocols. The User Agent product is a CLI and MCP server giving agents full read, simulate, and write access on Ethereum and Base with any wallet infrastructure, running every write through a simulation first, while the Builder Agent is an AGENTS.md knowledge base that turns a code agent into a Morpho integration expert.CoinGecko MCPCoinGecko MCP is a remote Model Context Protocol server that gives AI agents access to CoinGecko's market data, including live prices and market caps, historical charts, DeFi and onchain pool data, and NFT collection analytics. It connects to Claude, Cursor, VS Code, and other MCP clients with minimal setup and is backed by CoinGecko's existing API.1inch AI (MCP + Agent Skills)1inch AI is the official distribution point for the 1inch hosted MCP server and its agent skills, covering token swaps, limit orders, and SDK documentation search. Agent builders point Claude, Cursor, or Copilot at it so an agent can quote and place swaps.Alchemy MCP ServerThe Alchemy MCP Server gives AI clients access to Alchemy's blockchain data and RPC APIs across more than 100 chains. The hosted server at mcp.alchemy.com is the maintained route, while the open source repository holds the legacy local version.Coinbase Payments MCPThe Coinbase Payments MCP, now documented as the Agentic Wallet MCP, gives an AI agent tools to move and accept crypto payments through Coinbase's payment APIs. Builders add it when an agent needs to send or receive payments.Base MCPBase MCP is a Model Context Protocol server that connects AI agents to wallet and onchain tools on Base, with pre-built prompts and workflows for wallet operations, token transfers, and DeFi interactions. Nothing happens onchain without explicit approval since the server never holds or accesses private keys, instead constructing pending requests that a Base Account reviews and signs, and it ships with skill plugins covering Morpho, Moonwell, Aerodrome, Bankr, Avantis, Virtuals, and Uniswap.","tokens":660,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264967430,"hash":"9f48593746af1b9d0f36fb0098a6b616682bf1f2"}
{"url":"https://forum.soliditylang.org/t/using-clz-to-seed-sqrt-finding-the-initial-estimate-before-and-after-fusaka/3707/1","domain":"forum.soliditylang.org","title":"Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2\n\n 1 / 2\n\n Jun 2\n\n Jun 9\n\n post by nebojsakonsta on Jun 2\n\n nebojsakonsta\n\n Hi all — first post here. I’m Konsta, and I build DeFiMath, an open-source, gas-optimized Solidity library for on-chain financial math (Black-Scholes pricing, fixed-point primitives, roots, and so on). I’ve been deep in root functions lately and wanted to share one small change to how the initial estimate is found — and hear how others are handling it now that Fusaka has shipped.\nNewton/Babylonian sqrt converges fast, but only if the starting guess is close. So the first job is to find the magnitude of x — essentially its top set bit — and build a seed from it.\nBefore: you locate the magnitude with a shift/compare cascade. This is the estimate section from Solady’s sqrt (MIT):\nz := 181\n// find the magnitude of x via shift/compare\nlet r := shl(7, lt(0xffffffffffffffffffffffffffffffffff, x))\nr := or(r, shl(6, lt(0xffffffffffffffffff, shr(r, x))))\nr := or(r, shl(5, lt(0xffffffffff, shr(r, x))))\nr := or(r, shl(4, lt(0xffffff, shr(r, x))))\nz := shl(shr(1, r), z)\nz := shr(18, mul(z, add(shr(r, x), 65536)))\n\nFour conditional steps just to pin down the top bit before the seed is computed.\nAfter: with EIP-7939 live since Fusaka, clz gives the magnitude in a single 5-gas opcode, so that whole cascade collapses to one line:\nz := 181\n// magnitude of x in one opcode (index of the top set bit)\nlet r := sub(255, clz(x))\nz := shl(shr(1, r), z)\nz := shr(18, mul(z, add(shr(r, x), 65536)))\n\nThe downstream seed math is unchanged — only the magnitude lookup moves to the opcode. In my benchmarks that’s around 100 gas off the seeding step alone, plus smaller bytecode. Two things to keep in mind: align r’s rounding with whatever your interpolation window expects and test against the original, and remember clz(0) returns 256, so guard x == 0 as usual. clz is callable directly in inline assembly on solc 0.8.35+ when you target the Osaka/Fusaka EVM version.\nCurious whether anyone has found cases where a software bit-length still beats the opcode, or where the seed precision matters less than I’m assuming.\n\n post by czepluch on Jun 9\n\n czepluch\n\n Solidity Team\n\n Hey and welcome.\nThis is cool. Thanks for sharing!\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n [Call for feedback] The Long-term Solidity Roadmap\n\n Feedback\n\n 20\n\n 1.6k\n\n Aug 19\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1604,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264971029,"hash":"39afb52ca35cb72f0d5fdf4ac7da64f76f86a2b3"}
{"url":"https://ethereum.org/developers/tools/coingecko-mcp/","domain":"ethereum.org","title":"CoinGecko MCP | ⁦ethereum.org⁩","text":"Agent toolingCoinGecko MCPMCP serversMCP server · Analytics · APIWebsite (opens in a new tab)CoinGecko MCP is a remote Model Context Protocol server that gives AI agents access to CoinGecko's market data, including live prices and market caps, historical charts, DeFi and onchain pool data, and NFT collection analytics. It connects to Claude, Cursor, VS Code, and other MCP clients with minimal setup and is backed by CoinGecko's existing API.Related resourcesMorpho AgentsMorpho Agents is a beta interface built for AI agents to read, simulate, and write to Morpho's lending protocols. The User Agent product is a CLI and MCP server giving agents full read, simulate, and write access on Ethereum and Base with any wallet infrastructure, running every write through a simulation first, while the Builder Agent is an AGENTS.md knowledge base that turns a code agent into a Morpho integration expert.Tenderly MCPTenderly MCP is a Model Context Protocol server that brings Tenderly's blockchain development tools into AI assistants like Claude, exposing around 59 tools for transaction simulation, virtual testing environments, call trace and event inspection, and project management. It authenticates via OAuth and lets an agent set an active project, then run simulations and debug transactions without leaving the chat.1inch AI (MCP + Agent Skills)1inch AI is the official distribution point for the 1inch hosted MCP server and its agent skills, covering token swaps, limit orders, and SDK documentation search. Agent builders point Claude, Cursor, or Copilot at it so an agent can quote and place swaps.Alchemy MCP ServerThe Alchemy MCP Server gives AI clients access to Alchemy's blockchain data and RPC APIs across more than 100 chains. The hosted server at mcp.alchemy.com is the maintained route, while the open source repository holds the legacy local version.Coinbase Payments MCPThe Coinbase Payments MCP, now documented as the Agentic Wallet MCP, gives an AI agent tools to move and accept crypto payments through Coinbase's payment APIs. Builders add it when an agent needs to send or receive payments.Base MCPBase MCP is a Model Context Protocol server that connects AI agents to wallet and onchain tools on Base, with pre-built prompts and workflows for wallet operations, token transfers, and DeFi interactions. Nothing happens onchain without explicit approval since the server never holds or accesses private keys, instead constructing pending requests that a Base Account reviews and signs, and it ships with skill plugins covering Morpho, Moonwell, Aerodrome, Bankr, Avantis, Virtuals, and Uniswap.","tokens":654,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791264978612,"hash":"627aa0e94964966d8f423db65d9da9c9daf02d4e"}
{"url":"https://governance.aave.com/t/wrong-wallet-transaction/25440/2","domain":"governance.aave.com","title":"Wrong Wallet Transaction - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 5\n\n 2 / 2\n\n Sep 5\n\n Aug 5\n\n post by Abba on Aug 5\n\n Abba\n\n Title: Accidental USDT sent to Aave V3 contract on BSC\nPost:\nHello,\nI made a mistake and sent USDT directly to the Aave V3 pool contract address on BNB Smart Chain (BEP20), not through the deposit function.\n· Tx Hash: 0x8e12471a2533e048f606ae0a1923ffc57aa531cab88c34d0de800b8933cec730\n· Amount: $1.27 USDT\n· Network: BSC (BEP20)\n· Contract address: 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2\n· My wallet: [0x0A94325AEC7321080cF5629dB6179454f6dEB3a4]\nThe transaction was successful but I never received aUSDT. I am requesting that this be included in a future Rescue Mission phase for BSC. I can prove ownership of the sending wallet if needed.\nThank you for your help.\n\n 1 month later\n\n Closed on Sep 4\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool\n\n Other\n\n 0\n\n 98\n\n Jul 13\n\n Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase\n\n Development\n\n 0\n\n 116\n\n Jul 14\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d","tokens":400,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264982468,"hash":"4d425021c45b2614f7055fcf85627b9e5331aa28"}
{"url":"https://forum.soliditylang.org/t/using-clz-to-seed-sqrt-finding-the-initial-estimate-before-and-after-fusaka/3707","domain":"forum.soliditylang.org","title":"Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2\n\n 1 / 2\n\n Jun 2\n\n Jun 9\n\n post by nebojsakonsta on Jun 2\n\n nebojsakonsta\n\n Hi all — first post here. I’m Konsta, and I build DeFiMath, an open-source, gas-optimized Solidity library for on-chain financial math (Black-Scholes pricing, fixed-point primitives, roots, and so on). I’ve been deep in root functions lately and wanted to share one small change to how the initial estimate is found — and hear how others are handling it now that Fusaka has shipped.\nNewton/Babylonian sqrt converges fast, but only if the starting guess is close. So the first job is to find the magnitude of x — essentially its top set bit — and build a seed from it.\nBefore: you locate the magnitude with a shift/compare cascade. This is the estimate section from Solady’s sqrt (MIT):\nz := 181\n// find the magnitude of x via shift/compare\nlet r := shl(7, lt(0xffffffffffffffffffffffffffffffffff, x))\nr := or(r, shl(6, lt(0xffffffffffffffffff, shr(r, x))))\nr := or(r, shl(5, lt(0xffffffffff, shr(r, x))))\nr := or(r, shl(4, lt(0xffffff, shr(r, x))))\nz := shl(shr(1, r), z)\nz := shr(18, mul(z, add(shr(r, x), 65536)))\n\nFour conditional steps just to pin down the top bit before the seed is computed.\nAfter: with EIP-7939 live since Fusaka, clz gives the magnitude in a single 5-gas opcode, so that whole cascade collapses to one line:\nz := 181\n// magnitude of x in one opcode (index of the top set bit)\nlet r := sub(255, clz(x))\nz := shl(shr(1, r), z)\nz := shr(18, mul(z, add(shr(r, x), 65536)))\n\nThe downstream seed math is unchanged — only the magnitude lookup moves to the opcode. In my benchmarks that’s around 100 gas off the seeding step alone, plus smaller bytecode. Two things to keep in mind: align r’s rounding with whatever your interpolation window expects and test against the original, and remember clz(0) returns 256, so guard x == 0 as usual. clz is callable directly in inline assembly on solc 0.8.35+ when you target the Osaka/Fusaka EVM version.\nCurious whether anyone has found cases where a software bit-length still beats the opcode, or where the seed precision matters less than I’m assuming.\n\n post by czepluch on Jun 9\n\n czepluch\n\n Solidity Team\n\n Hey and welcome.\nThis is cool. Thanks for sharing!\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1598,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791264982506,"hash":"0bfe0ff768c179c6833cb1cbd7d58369d892294f"}
{"url":"https://governance.aave.com/t/rescue-of-wrong-sent-tokens/25471/4","domain":"governance.aave.com","title":"Rescue of wrong sent tokens - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 13\n\n 4 / 4\n\n Sep 19\n\n Aug 13\n\n post by Ritvars on Aug 13\n\n Ritvars\n\n Hello! I sent my AAVE tokens directly to smart contract address from binance. Can You help to get them back.\nimage900×378 78.4 KB\n\n Unlisted on Aug 13\n\n Listed on Aug 19\n\n 1 month later\n\n Closed on Sep 18\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 78\n\n Aug 5\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum\n\n Governance\n\n 0\n\n 143\n\n Jul 20","tokens":266,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791264994040,"hash":"fb2ffcedf230442f1003cc5c22e05953f3e77877"}
{"url":"https://vitalik.eth.limo/general/2023/11/14/neoplasma.html","domain":"vitalik.eth.limo","title":"Exit games for EVM validiums: the return of Plasma","text":"Dark Mode Toggle\n\n Exit games for EVM validiums: the return of Plasma \n 2023 Nov 14 \nSee all posts\n\n Exit games for EVM validiums: the return of Plasma \n\nSpecial thanks to Karl Floersch, Georgios Konstantopoulos and\nMartin Koppelmann for feedback, review and discussion.\nPlasma\nis a class of blockchain scaling solutions that allow all data and\ncomputation, except for deposits, withdrawals and Merkle roots, to be\nkept off-chain. This opens the door to very large scalability gains that\nare not bottlenecked by on-chain data availability. Plasma was first invented in\n2017, and saw many iterations in 2018, most notably Minimal Viable\nPlasma, Plasma\nCash, Plasma\nCashflow and Plasma\nPrime. Unfortunately, Plasma has since largely been superseded by rollups, for reasons\nprimarily having to do with (i) large client-side data storage costs,\nand (ii) fundamental limitations of Plasma that make it hard\nto generalize beyond payments.\nThe advent of validity proofs (aka ZK-SNARKs) gives us a reason\nto rethink this decision. The largest challenge of making Plasma work\nfor payments, client-side data storage, can be efficiently addressed\nwith validity proofs. Additionally, validity proofs provide a wide array\nof tools that allow us to make a Plasma-like chain that runs an EVM. The\nPlasma security guarantees would not cover all users, as the fundamental\nreasons behind the impossibility of extending Plasma-style exit games to\nmany kinds of complex applications still remain. However, a very large\npercentage of assets could nevertheless be kept secure in practice.\nThis post describes how Plasma ideas can be extended to do such a\nthing.\nOverview: how Plasma works\nThe simplest version of Plasma to understand is Plasma Cash. Plasma\nCash works by treating each individual coin as a separate NFT, and\ntracking a separate history for each coin. A Plasma chain has an\noperator, who is responsible for making and regularly\npublishing blocks. The transactions in each block are stored as a sparse\nMerkle tree: if a transaction transfers ownership of coin\nk, it appears in position k of the tree. When\nthe Plasma chain operator creates a new block, they publish the root of\nthe Merkle tree to chain, and they directly send to each user the Merkle\nbranches corresponding to the coins that that user owns.\n\nSuppose that these are the last three transaction trees in a\nPlasma Cash chain. Then, assuming all previous trees are valid, we know\nthat Eve currently owns coin 1, David owns coin 4 and George owns coin\n6.\n\nThe main risk in any Plasma system is the operator misbehaving. This\ncan happen in two ways:\n\nPublishing an invalid block (eg. the operator\nincludes a transaction sending coin 1 from Fred to Hermione even if Fred\ndoesn't own the coin at that time)\nPublishing an unavailable block (eg. the operator\ndoes not send Bob his Merkle branch for one of the blocks, preventing\nhim from ever proving to someone else that his coin is still valid and\nunspent)\n\nIf the operator misbehaves in a way that is relevant to a user's\nassets, the user has the responsibility to exit immediately\n(specifically, within 7 days). When a user (\"the\nexiter\") exits, they provide a Merkle branch proving the\ninclusion of the transaction that transferred that coin from the\nprevious owner to them. This starts a 7-day challenge\nperiod, during which others can challenge that exit by\nproviding a Merkle proof of one of three things:\n\nNot latest owner: a later transaction signed by the\nexiter transferring the exiter's coin to someone else\nDouble spend: a transaction that transferred the\ncoin from the previous owner to someone else, that was included before\nthe transaction transferring the coin to the exiter\nInvalid history: a transaction that transferred the\ncoins before (within the past 7 days) that does not have a corresponding\nspend. The exiter can respond by providing the corresponding spend; if\nthey do not, the exit fails.\n\nWith these rules, anyone who owns coin k needs to see\nall of the Merkle branches of position k in all historical\ntrees for the past week to be sure that they actually own coin\nk and can exit it. They need to store all the branches\ncontaining transfers of the asset, so that they can respond to\nchallenges and safely exit with their coin.\nGeneralizing to fungible\ntokens\nThe above design works for NFTs. However, much more common than NFTs\nare fungible tokens, like ETH and USDC. One way to apply Plasma Cash to\nfungible tokens is to simply make each small denomination of a coin (eg.\n0.01 ETH) a separate NFT. Unfortunately, the gas costs of exiting would\nbe too high if we do this.\nOne solution is to optimize by treating many adjacent coins as a\nsingle unit, which can be transferred or exited all at once. There are\ntwo ways to do this:\n\nUse Plasma Cash almost as-is, but use fancy algorithms to compute\nthe Merkle tree of a really large number of objects very quickly if many\nadjacent objects are the same. This is surprisingly not that hard to do;\nyou can see a python\nimplementation here.\nUse Plasma\nCashflow, which simply represents many adjacent coins as a single\nobject.\n\nHowever, both of these approaches run into the problem of\nfragmentation: if you receive 0.001 ETH each from hundreds of\npeople who are buying coffees from you, you are going to have 0.001 ETH\nin many places in the tree, and so actually exiting that ETH would still\nrequire submitting many separate exits, making the gas fees prohibitive.\nDefragmentation protocols have been developed, but are tricky to\nimplement.\nAlternatively, we can redesign the system to take into account a more\ntraditional \"unspent\ntransaction output\" (UTXO) model. When you exit a coin, you would\nneed to provide the last week of history of those coins, and anyone\ncould challenge your exit by proving that those historical coins were\nalready exited.\n\nA withdrawal of the 0.2 ETH UTXO at the bottom right could be\ncancelled by showing a withdrawal of any of the UTXOs in its history,\nshown in green. Particularly note that the middle-left and bottom-left\nUTXOs are ancestors, but the top-left UTXO is not. This approach is\nsimilar to order-based\ncoloring ideas from colored coins protocols circa 2013.\n\nThere is a wide variety of techniques for doing this. In all cases,\nthe goal is to track some conception of what is \"the same coin\" at\ndifferent points in history, in order to prevent \"the same coin\" from\nbeing withdrawn twice.\nChallenges with\ngeneralizing to EVM\nUnfortunately, generalizing beyond payments to the EVM is much\nharder. One key challenge is that many state objects in the EVM do not\nhave a clear \"owner\". Plasma's security depends on each object having an\nowner, who has the responsibility to watch and make sure the chain's\ndata is available, and exit that object if anything goes wrong. Many\nEthereum applications, however, do not work this way. Uniswap liquidity\npools, for example, do not have a single owner.\nAnother challenge is that the EVM does not attempt to limit\ndependencies. ETH held in account A at block N could have come from\nanywhere in block N-1. In order to exit a consistent state, an EVM\nPlasma chain would need to have an exit game where, in the extreme case,\nsomeone wishing to exit using information from block N might need to pay\nthe fees to publish the entire block N state on chain: a gas\ncost in the many millions of dollars. UTXO-based Plasma schemes do not\nhave this problem: each user can exit their assets from whichever block\nis the most recent block that they have the data for.\nA third challenge is that the unbounded dependencies in the EVM make\nit much harder to have aligned incentives to prove validity.\nThe validity of any state depends on everything else, and so proving any\none thing requires proving everything. Sorting out failures in such a\nsituation generally cannot be made incentive-compatible due to the data\navailability problem. A particularly annoying problem is that we\nlose the guarantee, present in UTXO-based systems, that an object's\nstate cannot change without its owner's consent. This guarantee is\nincredibly useful, as it means that the owner is always aware of the\nlatest provable state of their assets, and simplifies exit games.\nWithout it, creating exit games becomes much harder.\nHow\nvalidity proofs can alleviate many of these problems\nThe most basic thing that validity proofs can do to improve Plasma\nchain designs is to prove the validity of each Plasma block on chain.\nThis greatly simplifies the design space: it means that the\nonly attack from the operator that we have to worry about is\nunavailable blocks, and not invalid blocks. In Plasma\nCash, for example, it removes the need to worry about history\nchallenges. This reduces the state that a user needs to download, from\none branch per block in the last week, to one branch per asset.\nAdditionally, withdrawals from the most recent state (in the common\ncase where the operator is honest, all withdrawals would be from the\nmost recent state) are not subject to not-latest-owner challenges, and\nso in a validity-proven Plasma chain such withdrawals would not be\nsubject to any challenges at all. This means that, in the normal\ncase, withdrawals can be instant!\nExtending to the EVM:\nparallel UTXO graphs\nIn the EVM case, validity proofs also let us do something clever:\nthey can be used to implement a parallel UTXO graph for ETH and ERC20\ntokens, and SNARK-prove equivalence between the UTXO graph and the\nEVM state. Once you have that, you could implement a \"regular\"\nPlasma system over the UTXO graph.\n\nThis lets us sidestep many of the complexities of the EVM. For\nexample, the fact that in an account-based system someone can edit your\naccount without your consent (by sending it coins and thereby increasing\nits balance) does not matter, because the Plasma construction is not\nover the EVM state itself, but rather over a UTXO state that lives in\nparallel to the EVM, where any coins that you receive would be separate\nobjects.\nExtending to the EVM:\ntotal state exiting\nThere have been simpler schemes proposed to make a \"plasma EVM\", eg.\nPlasma Free and\nbefore that this\npost from 2019. In these schemes, anyone can send a message on the\nL1 to force the operator to either include a transaction or make a\nparticular branch of the state available. If the operator fails to do\nthis, the chain starts reverting blocks. The chain stops\nreverting once someone posts a full copy of either the whole state, or\nat least all of the data that users have flagged as being potentially\nmissing. Making a withdrawal can require posting a bounty, which would\npay for that user's share of the gas costs of someone posting such a\nlarge amount of data.\nSchemes like this have the weakness that they do not allow instant\nwithdrawals in the normal case, because there is always the possibility\nthat the chain will need to revert the latest state.\nLimits of EVM plasma schemes\nSchemes like this are powerful, but are NOT able to provide\nfull security guarantees to all users. The case where they\nbreak down most clearly is situations where a particular state object\ndoes not have a clear economic \"owner\".\nLet us consider the case of a CDP (collateralized debt position), a\nsmart contract where a user has coins that are locked up and can only be\nreleased once the user pays their debt. Suppose that user has 1 ETH\n(~$2000 as of the time of this writing) locked up in a CDP with 1000 DAI\nof debt. Now, the Plasma chain stops publishing blocks, and the user\nrefuses to exit. The user could simply never exit. Now, the user has a\nfree option: if the price of ETH drops below $1000, they walk\naway and forget about the CDP, and if the price of ETH stays above,\neventually they claim it. On average, such a malicious user earns money\nfrom doing this.\nAnother example is a privacy system, eg. Tornado Cash or Privacy\nPools. Consider a privacy system with five depositors:\n\nThe ZK-SNARKs in the privacy system keep the link between the\nowner of a coin coming into the system and the owner of the coin coming\nout hidden.\n\nSuppose that only orange has withdrawn, and at that point the Plasma\nchain operator stops publishing data. Suppose also that we use the UTXO\ngraph approach with a first-in-first-out rule, so each coin gets matched\nto the coin right below it. Then, orange could withdraw their pre-mixed\nand post-mixed coin, and the system would perceive it as two\nseparate coins. If blue tries to withdraw their pre-mixed coin, orange's\nmore recent state would supersede it; meanwhile, blue would not have the\ninformation to withdraw their post-mixed coin.\nThis can be fixed if you allow the other four depositors to\nwithdraw the privacy contract itself (which would supersede the\ndeposits), and then take the coins out on L1. However, actually\nimplementing such a mechanism requires additional effort on the part of\npeople developing the privacy system.\nThere are also other ways to solve privacy, eg. the Intmax approach, which\ninvolves putting a few bytes on chain rollup-style together with a\nPlasma-like operator that passes around information between individual\nusers.\nUniswap LP positions have a similar problem: if you traded USDC for\nETH in a Uniswap position, you could try to withdraw your pre-trade USDC\nand your post-trade ETH. If you collude with the Plasma chain\noperator, the liquidity providers and other users would not have access\nto the post-trade state, so they would not be able to withdraw their\npost-trade USDC. Special logic would be required to prevent situations\nlike this.\nConclusions\nIn 2023, Plasma is an underrated design space. Rollups remain the\ngold standard, and have security properties that cannot be matched. This\nis particularly true from the developer experience perspective: nothing\ncan match the simplicity of an application developer not even having\nto think about ownership graphs and incentive flows within their\napplication.\nHowever, Plasma lets us completely sidestep the data availability\nquestion, greatly reducing transaction fees. Plasma can be a significant\nsecurity upgrade for chains that would otherwise be validiums.\nThe fact that ZK-EVMs are\nfinally coming to fruition this year makes it an excellent\nopportunity to re-explore this design space, and come up with even more\neffective constructions to simplify the developer experience and protect\nusers' funds.","tokens":3579,"squid":"ink-research","role":"Deep Scholar","at":1791265009071,"hash":"44b3a262d47090aa549ae1a0bf4efe73a7ce6241"}
{"url":"https://forum.soliditylang.org/t/about-the-code-wizards-category/16/1","domain":"forum.soliditylang.org","title":"About the Code Wizards category - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n About the Code Wizards category \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by franzihei on Dec 18, 2020\n\n franzihei\n\n Share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n Please be aware that this is not the place for ad-hoc support questions. For urgent Solidity support questions, please use the Solidity Gitter chat or consider checking out the Ethereum StackExchange. It’s also not the place for audit requests, although it is the right place to ask for feedback on a specific mechanism or construct.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 81\n\n Jun 22\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1185,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265014905,"hash":"1ae26a26dfb65e28b2059ef50da883ccd6668d28"}
{"url":"https://vitalik.eth.limo/general/2021/01/05/rollup.html","domain":"vitalik.eth.limo","title":"An Incomplete Guide to Rollups","text":"Dark Mode Toggle\n\n An Incomplete Guide to Rollups \n 2021 Jan 05 \nSee all posts\n\n An Incomplete Guide to Rollups \n\nRollups are all the rage in the Ethereum community, and are poised\nto be the key scalability solution for Ethereum for the foreseeable\nfuture. But what exactly is this technology, what can you expect from it\nand how will you be able to use it? This post will attempt to answer\nsome of those key questions.\nBackground: what\nis layer-1 and layer-2 scaling?\nThere are two ways to scale a blockchain ecosystem. First,\nyou can make the blockchain itself have a higher transaction\ncapacity. The main challenge with this technique is that\nblockchains with \"bigger blocks\" are inherently more difficult to verify\nand likely to become more centralized. To avoid such risks, developers\ncan either increase the efficiency of client software or, more\nsustainably, use techniques such as sharding to\nallow the work of building and verifying the chain to be split up across\nmany nodes; the effort known as\n\"eth2\" is currently building this upgrade to Ethereum.\nSecond, you can change the way that you use the\nblockchain. Instead of putting all activity on the\nblockchain directly, users perform the bulk of their activity off-chain\nin a \"layer 2\" protocol. There is a smart contract on-chain, which only\nhas two tasks: processing deposits and withdrawals, and verifying proofs\nthat everything happening off-chain is following the rules. There are\nmultiple ways to do these proofs, but they all share the property that\nverifying the proofs on-chain is much cheaper than doing the original\ncomputation off-chain.\nState channels vs plasma vs\nrollups\nThe three major types of layer-2 scaling are state channels, Plasma and rollups. They are three\ndifferent paradigms, with different strengths and weaknesses, and at\nthis point we are fairly confident that all layer-2 scaling falls into\nroughly these three categories (though naming controversies exist at the\nedges, eg. see \"validium\").\nHow do channels work?\nSee also: https://www.jeffcoleman.ca/state-channels\nand statechannels.org\nImagine that Alice is offering an internet connection to Bob, in\nexchange for Bob paying her $0.001 per megabyte. Instead of making a\ntransaction for each payment, Alice and Bob use the following layer-2\nscheme.\nFirst, Bob puts $1 (or some ETH or stablecoin equivalent) into a\nsmart contract. To make his first payment to Alice, Bob signs a \"ticket\"\n(an off-chain message), that simply says \"$0.001\", and sends it to\nAlice. To make his second payment, Bob would sign another ticket that\nsays \"$0.002\", and send it to Alice. And so on and so forth for as many\npayments as needed. When Alice and Bob are done transacting, Alice can\npublish the highest-value ticket to chain, wrapped in another signature\nfrom herself. The smart contract verifies Alice and Bob's signatures,\npays Alice the amount on Bob's ticket and returns the rest to Bob. If\nAlice is unwilling to close the channel (due to malice or technical\nfailure), Bob can initiate a withdrawal period (eg. 7 days); if Alice\ndoes not provide a ticket within that time, then Bob gets all his money\nback.\nThis technique is powerful: it can be adjusted to handle\nbidirectional payments, smart contract relationships (eg. Alice and Bob\nmaking a financial contract inside the channel), and composition (if\nAlice and Bob have an open channel and so do Bob and Charlie, Alice can\ntrustlessly interact with Charlie). But there are limits to what\nchannels can do. Channels cannot be used to send funds off-chain to\npeople who are not yet participants. Channels cannot be used to\nrepresent objects that do not have a clear logical owner (eg. Uniswap).\nAnd channels, especially if used to do things more complex than simple\nrecurring payments, require a large amount of capital to be locked\nup.\nHow does plasma work?\nSee also: the original Plasma paper,\nand Plasma\nCash.\nTo deposit an asset, a user sends it to the smart contract managing\nthe Plasma chain. The Plasma chain assigns that asset a new unique ID\n(eg. 537). Each Plasma chain has an operator (this could be a\ncentralized actor, or a multisig, or something more complex like PoS or\nDPoS). Every interval (this could be 15 seconds, or an hour, or anything\nin between), the operator generates a \"batch\" consisting of all of the\nPlasma transactions they have received off-chain. They generate a Merkle\ntree, where at each index X in the tree, there is a\ntransaction transferring asset ID X if such a transaction\nexists, and otherwise that leaf is zero. They publish the Merkle root of\nthis tree to chain. They also send the Merkle branch of each index\nX to the current owner of that asset. To withdraw an asset,\na user publishes the Merkle branch of the most recent transaction\nsending the asset to them. The contract starts a challenge period,\nduring which anyone can try to use other Merkle branches to invalidate\nthe exit by proving that either (i) the sender did not own the asset at\nthe time they sent it, or (ii) they sent the asset to someone else at\nsome later point in time. If no one proves that the exit is fraudulent\nfor (eg.) 7 days, the user can withdraw the asset.\nPlasma provides stronger properties than channels: you can send\nassets to participants who were never part of the system, and the\ncapital requirements are much lower. But it comes at a cost: channels\nrequire no data whatsoever to go on chain during \"normal operation\", but\nPlasma requires each chain to publish one hash at regular intervals.\nAdditionally, Plasma transfers are not instant: you have to wait for the\ninterval to end and for the block to be published.\nAdditionally, Plasma and channels share a key weakness in common: the\ngame theory behind why they are secure relies on the idea that each\nobject controlled by both systems has some logical \"owner\". If that\nowner does not care about their asset, then an \"invalid\" outcome\ninvolving that asset may result. This is okay for many applications, but\nit is a deal breaker for many others (eg. Uniswap). Even systems where\nthe state of an object can be changed without the owner's consent (eg.\naccount-based systems, where you can increase someone's balance\nwithout their consent) do not work well with Plasma. This all means that\na large amount of \"application-specific reasoning\" is required in any\nrealistic plasma or channels deployment, and it is not possible to make\na plasma or channel system that just simulates the full ethereum\nenvironment (or \"the EVM\"). To get around this problem, we get to...\nrollups.\nRollups\nSee also: EthHub\non optimistic rollups and ZK\nrollups.\nPlasma and channels are \"full\" layer 2 schemes, in that they try to\nmove both data and computation off-chain. However, fundamental game\ntheory issues around data availability means that it is impossible\nto safely do this for all applications. Plasma and channels get around\nthis by relying on an explicit notion of owners, but this prevents them\nfrom being fully general. Rollups, on the other hand, are a \"hybrid\"\nlayer 2 scheme. Rollups move computation (and state storage)\noff-chain, but keep some data per transaction on-chain. To\nimprove efficiency, they use a whole host of fancy compression tricks to\nreplace data with computation wherever possible. The result is\na system where scalability is still limited by the data bandwidth of the\nunderlying blockchain, but at a very favorable ratio: whereas an\nEthereum base-layer ERC20 token transfer costs ~45000 gas, an ERC20\ntoken transfer in a rollup takes up 16 bytes of on-chain space and costs\nunder 300 gas.\nThe fact that data is on-chain is key (note: putting data \"on IPFS\"\ndoes not work, because IPFS does not provide consensus\non whether or not any given piece of data is available; the data\nmust go on a blockchain). Putting data on-chain and having\nconsensus on that fact allows anyone to locally process all the\noperations in the rollup if they wish to, allowing them to detect fraud,\ninitiate withdrawals, or personally start producing transaction batches.\nThe lack of data availability issues means that a malicious or offline\noperator can do even less harm (eg. they cannot cause a 1 week\ndelay), opening up a much larger design space for who has the right to\npublish batches and making rollups vastly easier to reason about. And\nmost importantly, the lack of data availability issues means that there\nis no longer any need to map assets to owners, leading to the key reason\nwhy the Ethereum community is so much more excited about rollups than\nprevious forms of layer 2 scaling: rollups are fully\ngeneral-purpose, and one can even run an EVM inside a rollup, allowing\nexisting Ethereum applications to migrate to rollups with almost no need\nto write any new code.\nOK, so how exactly does a\nrollup work?\nThere is a smart contract on-chain which maintains a state\nroot: the Merkle root of the state of the rollup (meaning, the\naccount balances, contract code, etc, that are \"inside\" the rollup).\n\nAnyone can publish a batch, a collection of\ntransactions in a highly compressed form together with the previous\nstate root and the new state root (the Merkle root after\nprocessing the transactions). The contract checks that the previous\nstate root in the batch matches its current state root; if it does, it\nswitches the state root to the new state root.\n\nTo support depositing and withdrawing, we add the ability to have\ntransactions whose input or output is \"outside\" the rollup state. If a\nbatch has inputs from the outside, the transaction submitting the batch\nneeds to also transfer these assets to the rollup contract. If a batch\nhas outputs to the outside, then upon processing the batch the smart\ncontract initiates those withdrawals.\nAnd that's it! Except for one major detail: how to do know\nthat the post-state roots in the batches are correct? If\nsomeone can submit a batch with any post-state root with no\nconsequences, they could just transfer all the coins inside the rollup\nto themselves. This question is key because there are two very different\nfamilies of solutions to the problem, and these two families of\nsolutions lead to the two flavors of rollups.\nOptimistic rollups vs ZK\nrollups\nThe two types of rollups are:\n\nOptimistic rollups, which use fraud\nproofs: the rollup contract keeps track of its entire history\nof state roots and the hash of each batch. If anyone discovers that one\nbatch had an incorrect post-state root, they can publish a proof to\nchain, proving that the batch was computed incorrectly. The contract\nverifies the proof, and reverts that batch and all batches after\nit.\nZK rollups, which use validity\nproofs: every batch includes a cryptographic proof called a\nZK-SNARK (eg. using the PLONK protocol), which proves\nthat the post-state root is the correct result of executing the batch.\nNo matter how large the computation, the proof can be very quickly\nverified on-chain.\n\nThere are complex tradeoffs between the two flavors of rollups:\n\nProperty\nOptimistic rollups\nZK rollups\n\nFixed gas cost per batch\n~40,000 (a lightweight transaction that mainly just\nchanges the value of the state root)\n~500,000 (verification of a ZK-SNARK is quite computationally\nintensive)\n\nWithdrawal period\n~1 week (withdrawals need to be delayed to give time for someone to\npublish a fraud proof and cancel the withdrawal if it is\nfraudulent)\nVery fast (just wait for the next batch)\n\nComplexity of technology\nLow\nHigh (ZK-SNARKs are very new and mathematically complex\ntechnology)\n\nGeneralizability\nEasier (general-purpose EVM rollups are already\nclose to mainnet)\nHarder (ZK-SNARK proving general-purpose EVM execution is much\nharder than proving simple computations, though there are efforts (eg.\nCairo)\nworking to improve on this)\n\nPer-transaction on-chain gas costs\nHigher\nLower (if data in a transaction is only used to\nverify, and not to cause state changes, then this data can be left out,\nwhereas in an optimistic rollup it would need to be published in case it\nneeds to be checked in a fraud proof)\n\nOff-chain computation costs\nLower (though there is more need for many full\nnodes to redo the computation)\nHigher (ZK-SNARK proving especially for general-purpose computation\ncan be expensive, potentially many thousands of times more expensive\nthan running the computation directly)\n\nIn general, my own view is that in the short term, optimistic rollups\nare likely to win out for general-purpose EVM computation and ZK rollups\nare likely to win out for simple payments, exchange and other\napplication-specific use cases, but in the medium to long term ZK\nrollups will win out in all use cases as ZK-SNARK technology\nimproves.\nAnatomy of a fraud proof\nThe security of an optimistic rollup depends on the idea that if\nsomeone publishes an invalid batch into the rollup, anyone else\nwho was keeping up with the chain and detected the fraud can publish a\nfraud proof, proving to the contract that that batch is invalid and\nshould be reverted.\n\nA fraud proof claiming that a batch was invalid would contain the\ndata in green: the batch itself (which could be checked against a hash\nstored on chain) and the parts of the Merkle tree needed to prove just\nthe specific accounts that were read and/or modified by the batch. The\nnodes in the tree in yellow can be reconstructed from the nodes in green\nand so do not need to be provided. This data is sufficient to execute\nthe batch and compute the post-state root (note that this is exactly the\nsame as how stateless\nclients verify individual blocks). If the computed post-state root\nand the provided post-state root in the batch are not the same, then the\nbatch is fraudulent.\nIt is guaranteed that if a batch was constructed incorrectly, and\nall previous batches were constructed correctly, then it is\npossible to create a fraud proof showing the the batch was constructed\nincorrectly. Note the claim about previous batches: if there was more\nthan one invalid batch published to the rollup, then it is best to try\nto prove the earliest one invalid. It is also, of course, guaranteed\nthat if a batch was constructed correctly, then it is never possible to\ncreate a fraud proof showing that the batch is invalid.\nHow does compression work?\nA simple Ethereum transaction (to send ETH) takes ~110 bytes. An ETH\ntransfer on a rollup, however, takes only ~12 bytes:\n\nParameter\nEthereum\nRollup\n\nNonce\n~3\n0\n\nGasprice\n~8\n0-0.5\n\nGas\n3\n0-0.5\n\nTo\n21\n4\n\nValue\n~9\n~3\n\nSignature\n~68 (2 + 33 + 33)\n~0.5\n\nFrom\n0 (recovered from sig)\n4\n\nTotal\n~112\n~12\n\nPart of this is simply superior encoding: Ethereum's RLP wastes 1\nbyte per value on the length of each value. But there are also some very\nclever compression tricks that are going on:\n\nNonce: the purpose of this parameter is to prevent\nreplays. If the current nonce of an account is 5, the next transaction\nfrom that account must have nonce 5, but once the transaction is\nprocessed the nonce in the account will be incremented to 6 so the\ntransaction cannot be processed again. In the rollup, we can omit the\nnonce entirely, because we just recover the nonce from the pre-state; if\nsomeone tries replaying a transaction with an earlier nonce, the\nsignature would fail to verify, as the signature would be checked\nagainst data that contains the new higher nonce.\nGasprice: we can allow users to pay with a fixed\nrange of gasprices, eg. a choice of 16 consecutive powers of two.\nAlternatively, we could just have a fixed fee level in each batch, or\neven move gas payment outside the rollup protocol entirely and have\ntransactors pay batch creators for inclusion through a channel.\nGas: we could similarly restrict the total gas to a\nchoice of consecutive powers of two. Alternatively, we could just have a\ngas limit only at the batch level.\nTo: we can replace the 20-byte address with an\nindex (eg. if an address is the 4527th address added to the\ntree, we just use the index 4527 to refer to it. We would add a subtree\nto the state to store the mapping of indices to addresses).\nValue: we can store value in scientific notation.\nIn most cases, transfers only need 1-3 significant digits.\nSignature: we can use BLS\naggregate signatures, which allows many signatures to be aggregated\ninto a single ~32-96 byte (depending on protocol) signature. This\nsignature can then be checked against the entire set of messages and\nsenders in a batch all at once. The ~0.5 in the table represents the\nfact that there is a limit on how many signatures can be combined in an\naggregate that can be verified in a single block, and so large batches\nwould need one signature per ~100 transactions.\n\nOne important compression trick that is specific to ZK rollups is\nthat if a part of a transaction is only used for verification, and is\nnot relevant to computing the state update, then that part can be left\noff-chain. This cannot be done in an optimistic rollup because that data\nwould still need to be included on-chain in case it needs to be later\nchecked in a fraud proof, whereas in a ZK rollup the SNARK proving\ncorrectness of the batch already proves that any data needed for\nverification was provided. An important example of this is\nprivacy-preserving rollups: in an optimistic rollup the ~500 byte\nZK-SNARK used for privacy in each transaction needs to go on chain,\nwhereas in a ZK rollup the ZK-SNARK covering the entire batch already\nleaves no doubt that the \"inner\" ZK-SNARKs are valid.\nThese compression tricks are key to the scalability of rollups;\nwithout them, rollups would be perhaps only a ~10x improvement on the\nscalability of the base chain (though there are some specific\ncomputation-heavy applications where even simple rollups are powerful),\nwhereas with compression tricks the scaling factor can go over 100x for\nalmost all applications.\nWho can submit a batch?\nThere are a number of schools of thought for who can submit a batch\nin an optimistic or ZK rollup. Generally, everyone agrees that in order\nto be able to submit a batch, a user must put down a large deposit; if\nthat user ever submits a fraudulent batch (eg. with an invalid state\nroot), that deposit would be part burned and part given as a reward to\nthe fraud prover. But beyond that, there are many possibilities:\n\nTotal anarchy: anyone can submit a batch at any\ntime. This is the simplest approach, but it has some important\ndrawbacks. Particularly, there is a risk that multiple participants will\ngenerate and attempt to submit batches in parallel, and only one of\nthose batches can be successfully included. This leads to a large amount\nof wasted effort in generating proofs and/or wasted gas in publishing\nbatches to chain.\nCentralized sequencer: there is a single actor, the\nsequencer, who can submit batches (with an exception\nfor withdrawals: the usual technique is that a user can first submit a\nwithdrawal request, and then if the sequencer does not process that\nwithdrawal in the next batch, then the user can submit a\nsingle-operation batch themselves). This is the most \"efficient\", but it\nis reliant on a central actor for liveness.\nSequencer auction: an auction is held (eg. every\nday) to determine who has the right to be the sequencer for the next\nday. This technique has the advantage that it raises funds which could\nbe distributed by eg. a DAO controlled by the rollup (see: MEV\nauctions)\nRandom selection from PoS set: anyone can deposit\nETH (or perhaps the rollup's own protocol token) into the rollup\ncontract, and the sequencer of each batch is randomly selected from one\nof the depositors, with the probability of being selected being\nproportional to the amount deposited. The main drawback of this\ntechnique is that it leads to large amounts of needless capital\nlockup.\nDPoS voting: there is a single sequencer selected\nwith an auction but if they perform poorly token holders can vote to\nkick them out and hold a new auction to replace them.\n\nSplit batching and\nstate root provision\nSome of the rollups being currently developed are using a \"split\nbatch\" paradigm, where the action of submitting a batch of layer-2\ntransactions and the action of submitting a state root are done\nseparately. This has some key advantages:\n\nYou can allow many sequencers in parallel to publish batches in\norder to improve censorship resistance, without worrying that some\nbatches will be invalid because some other batch got included\nfirst.\nIf a state root is fraudulent, you don't need to revert the entire\nbatch; you can revert just the state root, and wait for someone to\nprovide a new state root for the same batch. This gives transaction\nsenders a better guarantee that their transactions will not be\nreverted.\n\nSo all in all, there is a fairly complex zoo of techniques that are\ntrying to balance between complicated tradeoffs involving efficiency,\nsimplicity, censorship resistance and other goals. It's still too early\nto say which combination of these ideas works best; time will tell.\nHow much scaling do\nrollups give you?\nOn the existing Ethereum chain, the gas limit is 12.5 million, and\neach byte of data in a transaction costs 16 gas. This means that if a\nblock contains nothing but a single batch (we'll say a ZK rollup is\nused, spending 500k gas on proof verification), that batch can have (12\nmillion / 16) = 750,000 bytes of data. As shown above, a rollup for ETH\ntransfers requires only 12 bytes per user operation, meaning that the\nbatch can contain up to 62,500 transactions. At an average block time of\n13 seconds, this\ntranslates to ~4807 TPS (compared to 12.5 million / 21000 / 13 ~= 45 TPS\nfor ETH transfers directly on Ethereum itself).\nHere's a chart for some other example use cases:\n\nApplication\nBytes in rollup\nGas cost on layer 1\nMax scalability gain\n\nETH transfer\n12\n21,000\n105x\n\nERC20 transfer\n16 (4 more bytes to specify which token)\n~50,000\n187x\n\nUniswap trade\n~14 (4 bytes sender + 4 bytes recipient + 3 bytes\nvalue + 1 byte max price + 1 byte misc)\n~100,000\n428x\n\nPrivacy-preserving withdrawal (Optimistic rollup)\n296 (4 bytes index of root + 32 bytes nullifier + 4\nbytes recipient + 256 bytes ZK-SNARK proof)\n~380,000\n77x\n\nPrivacy-preserving withdrawal (ZK rollup)\n40 (4 bytes index of root + 32 bytes nullifier + 4\nbytes recipient)\n~380,000\n570x\n\nMax scalability gain is calculated as (L1 gas cost) /\n(bytes in rollup * 16) * 12 million / 12.5 million.\nNow, it is worth keeping in mind that these figures are overly\noptimistic for a few reasons. Most importantly, a block would almost\nnever just contain one batch, at the very least because there are and\nwill be multiple rollups. Second, deposits and withdrawals will continue\nto exist. Third, in the short term usage will be low, and so\nfixed costs will dominate. But even with these factors taken into\naccount, scalability gains of over 100x are expected to be the norm.\nNow what if we want to go above ~1000-4000 TPS (depending on the\nspecific use case)? Here is where eth2\ndata sharding comes in. The sharding proposal opens up a space of 16\nMB every 12 seconds that can be filled with any data, and the system\nguarantees consensus on the availability of that data. This data space\ncan be used by rollups. This ~1398k bytes per sec is a 23x improvement\non the ~60 kB/sec of the existing Ethereum chain, and in the longer term\nthe data capacity is expected to grow even further. Hence, rollups that\nuse eth2 sharded data can collectively process as much as ~100k TPS, and\neven more in the future.\nWhat\nare some not-yet-fully-solved challenges in rollups?\nWhile the basic concept of a rollup is now well-understood, we are\nquite certain that they are fundamentally feasible and secure, and\nmultiple rollups have already been deployed to mainnet, there are still\nmany areas of rollup design that have not been well explored, and quite\na few challenges in fully bringing large parts of the Ethereum ecosystem\nonto rollups to take advantage of their scalability. Some key challenges\ninclude:\n\nUser and ecosystem onboarding - not many\napplications use rollups, rollups are unfamiliar to users, and few\nwallets have started integrating rollups. Merchants and charities do not\nyet accept them for payments.\nCross-rollup transactions - efficiently moving\nassets and data (eg. oracle outputs) from one rollup into another\nwithout incurring the expense of going through the base layer.\nAuditing incentives - how to maximize the chance\nthat at least one honest node actually will be fully verifying an\noptimistic rollup so they can publish a fraud proof if something goes\nwrong? For small-scale rollups (up to a few hundred TPS) this is not a\nsignificant issue and one can simply rely on altruism, but for\nlarger-scale rollups more explicit reasoning about this is needed.\nExploring the design space in between plasma and\nrollups - are there techniques that put some\nstate-update-relevant data on chain but not all of it, and is\nthere anything useful that could come out of that?\nMaximizing security of pre-confirmations - many\nrollups provide a notion of \"pre-confirmation\" for faster UX, where the\nsequencer immediately provides a promise that a transaction will be\nincluded in the next batch, and the sequencer's deposit is destroyed if\nthey break their word. But the economy security of this scheme is\nlimited, because of the possibility of making many promises to very many\nactors at the same time. Can this mechanism be improved?\nImproving speed of response to absent sequencers -\nif the sequencer of a rollup suddenly goes offline, it would be valuable\nto recover from that situation maximally quickly and cheaply, either\nquickly and cheaply mass-exiting to a different rollup or replacing the\nsequencer.\nEfficient ZK-VM - generating a ZK-SNARK proof that\ngeneral-purpose EVM code (or some different VM that existing smart\ncontracts can be compiled to) has been executed correctly and has a\ngiven result.\n\nConclusions\nRollups are a powerful new layer-2 scaling paradigm, and are expected\nto be a cornerstone of Ethereum scaling in the short and medium-term\nfuture (and possibly long-term as well). They have seen a large amount\nof excitement from the Ethereum community because unlike previous\nattempts at layer-2 scaling, they can support general-purpose EVM code,\nallowing existing applications to easily migrate over. They do this by\nmaking a key compromise: not trying to go fully off-chain, but instead\nleaving a small amount of data per transaction on-chain.\nThere are many kinds of rollups, and many choices in the design\nspace: one can have an optimistic rollup using fraud proofs, or a ZK\nrollup using validity proofs (aka. ZK-SNARKs). The sequencer (the user\nthat can publish transaction batches to chain) can be either a\ncentralized actor, or a free-for-all, or many other choices in between.\nRollups are still an early-stage technology, and development is\ncontinuing rapidly, but they work and some (notably Loopring, ZKSync and DeversiFi) have already been\nrunning for months. Expect much more exciting work to come out of the\nrollup space in the years to come.","tokens":6727,"squid":"ink-research","role":"Deep Scholar","at":1791265020716,"hash":"bea2815a57c3cd119c35ec74e7beea9595b9288c"}
{"url":"https://forum.openzeppelin.com/t/revert-safeerc20-low-level-call-failed-when-trying-to-run-buytokens-function-in-a-crowdsale/4753/6","domain":"forum.openzeppelin.com","title":"Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Nov 2020\n\n 6 / 6\n\n Dec 2020\n\n Dec 2020\n\n post by pedromtelho on Nov 24, 2020\n\n post by Skyge on Nov 24, 2020\n\n post by abcoathup on Nov 24, 2020\n\n post by pedromtelho on Nov 27, 2020\n\n pedromtelho\n\n Exactly! I thought that some functions could be called by other people and I do not want it so I decided to override them using onlyOwner function. I’ll post my contracts here.\nMyToken.sol:\npragma solidity ^0.5.2;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Mintable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/token/ERC20/ERC20Pausable.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\nimport \"./TokenWhitelist.sol\";\n\ncontract MyToken is ERC20, ERC20Pausable, ERC20Mintable, Ownable {\n string private _name;\n string private _symbol;\n uint8 private _decimals = 18;\n uint256 private _exp = 10**18;\n uint256 private _totalSupply;\n\nTokenWhitelist public whitelist;\n\nmapping (address => uint256) private _balances;\n\nmapping (address => mapping (address => uint256)) private _allowances;\n\n// ... see \"Tokens\" for more info\nconstructor(string memory name, string memory symbol, address startupAddr, TokenWhitelist _whitelist, uint256 totalSupply) public\n ERC20Mintable()\n ERC20Pausable()\n {\n _name = name;\n _symbol = symbol;\n whitelist = _whitelist;\n mint(startupAddr, totalSupply);\n }\n\nfunction name() public view returns (string memory) {\n return _name;\n}\n\nfunction symbol() public view returns (string memory) {\n return _symbol;\n}\n\nfunction decimals() public view returns (uint8) {\n return _decimals;\n}\n\nfunction totalSupply() public view returns (uint256) {\n return _totalSupply;\n}\n\nfunction balanceOf(address account) public view returns (uint256) {\n return _balances[account];\n}\n\nfunction mint(address toAccount, uint256 amount) public onlyMinter whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(toAccount), \"Account is not whitelisted\");\n _mint(toAccount, amount);\n return true;\n}\n\nfunction transfer(address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(_msgSender(), recipient, amount);\n return true;\n}\n\nfunction allowance(address owner, address spender) public view returns (uint256) {\n return _allowances[owner][spender];\n}\n\nfunction approve(address spender, uint256 amount) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, amount);\n return true;\n}\n\nfunction transferFrom(address sender, address recipient, uint256 amount) public whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(sender), \"Sender is not whitelisted\");\n require(whitelist.checkWhitelisted(recipient), \"Recipient is not whitelisted\");\n _transfer(sender, recipient, amount);\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n return true;\n}\n\nfunction increaseAllowance(address spender, uint256 addedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n return true;\n}\n\nfunction decreaseAllowance(address spender, uint256 subtractedValue) public onlyOwner whenNotPaused returns (bool) {\n require(whitelist.checkWhitelisted(spender), \"Spender is not whitelisted\");\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n return true;\n}\n\nfunction _mint(address account, uint256 amount) internal {\n require(account != address(0), \"ERC20: mint to the zero address\");\n uint256 convertedAmount = amount*_exp;\n _totalSupply = _totalSupply.add(convertedAmount);\n _balances[account] = _balances[account].add(convertedAmount);\n emit Transfer(address(0), account, convertedAmount);\n}\n\nfunction _transfer(address sender, address recipient, uint256 amount) internal {\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n require(whitelist.checkWhitelisted(sender), \"Sender is not checked in whitelist\");\n require(whitelist.checkWhitelisted(recipient), \"Sender is not checked in whitelist\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n _balances[recipient] = _balances[recipient].add(amount);\n emit Transfer(sender, recipient, amount);\n}\n\nfunction _approve(address owner, address spender, uint256 amount) internal {\n require(owner != address(0), \"ERC20: approve from the zero address\");\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\nemit Approval(owner, spender, amount);}}\n\nMyCrowdsale.sol:\npragma solidity ^0.5.2;\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/GSN/Context.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/math/SafeMath.sol\";\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/utils/ReentrancyGuard.sol\";\n\n import \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n import \"./MyToken.sol\";\n import \"./TokenWhitelist.sol\";\n\n contract MyCrowdsale is Context, ReentrancyGuard, Ownable {\n using SafeMath for uint256;\n\n address payable private _startupAddr;\n\n uint256 private _tokenPrice; // preço do token\n uint256 private _tokensSold; // tokens vendidos\n\n // Amount of wei raised\n uint256 private _weiRaised;\n\n MyToken private _tokenContract; // contrato do token\n TokenWhitelist private _whitelist;\n\n mapping(address => uint256) private _tokenRequests;\n\n /**\n * Event for token purchase logging\n * @param purchaser who paid for the tokens\n * @param beneficiary who got the tokens\n * @param value weis paid for purchase\n * @param amount amount of tokens purchased\n */\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n constructor(\n uint256 rate, // preço\n address payable startupAddr, // endereço da startup\n MyToken token, // endereço do token da startup\n TokenWhitelist whitelist_ // whitelist da nossa empresa\n )\n public\n {\n require(rate > 0, \"Crowdsale: rate is 0\");\n require(address(whitelist_) == 0x80C92cc0b675018ef95b4c000e22C675c3A5a41a, \"Crowdsale: wrong whitelist address\"); // endereço hardcoded\n require(whitelist_.checkWhitelisted(startupAddr), \"Crowdsale: wallet is not whitelisted\");\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n _tokenPrice = rate;\n _tokenContract = token;\n _whitelist = whitelist_;\n _startupAddr = startupAddr;\n }\n\n function tokenPrice() public view returns (uint256) {\n return _tokenPrice;\n }\n\n function tokensSold() public view returns (uint256) {\n return _tokensSold;\n }\n\n function totalTokenSupply() public view returns (uint256){\n return _tokenContract.totalSupply();\n }\n\n /**\n * @return the amount of wei raised.\n */\n function weiRaised() public view returns (uint256) {\n return _weiRaised;\n }\n\n /**\n * @dev fallback function ***DO NOT OVERRIDE***\n * Note that other contracts will transfer funds with a base gas stipend\n * of 2300, which is not enough to call buyTokens. Consider calling\n * buyTokens directly when purchasing tokens from a contract.\n */\n function () external payable {\n buyTokens(_msgSender());\n }\n\n /**\n * @dev low level token purchase ***DO NOT OVERRIDE***\n * This function has a non-reentrancy guard, so it shouldn't be called by\n * another `nonReentrant` function.\n * @param beneficiary Recipient of the token purchase\n */\n function buyTokens(address beneficiary) public nonReentrant payable {\n uint256 weiAmount = msg.value;\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n // _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n // _postValidatePurchase(beneficiary, weiAmount);\n }\n\n function withdrawTokens(address beneficiary) public {\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n require(_tokenRequests[beneficiary] != 0, \"Crowdsale: beneficiary has no orders\");\n uint256 amount = _tokenRequests[beneficiary];\n require(amount > 0, \"PostDeliveryCrowdsale: beneficiary is not due any tokens\");\n\n _tokenRequests[beneficiary] = 0;\n _tokenContract.transferFrom(_startupAddr, beneficiary, amount);\n }\n\n function tokenRequests(address beneficiary) public view returns (uint256) {\n return _tokenRequests[beneficiary];\n }\n\n /**\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n * super._preValidatePurchase(beneficiary, weiAmount);\n * require(weiRaised().add(weiAmount) <= cap);\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n require(_whitelist.checkWhitelisted(beneficiary), \"Crowdsale: beneficiary is not whitelisted\");\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n }\n\n /**\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n * conditions are not met.\n * @param beneficiary Address performing the token purchase\n * @param weiAmount Value in wei involved in the purchase\n */\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n * its tokens.\n * @param beneficiary Address performing the token purchase\n * @param tokenAmount Number of tokens to be emitted\n */\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n _tokenContract.transferFrom(_startupAddr, beneficiary, tokenAmount);\n }\n\n function _buyOrder(address beneficiary, uint256 tokenAmount) internal {\n _tokenRequests[beneficiary] += tokenAmount;\n _tokensSold += tokenAmount;\n }\n\n /**\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n * tokens.\n * @param beneficiary Address receiving the tokens\n * @param tokenAmount Number of tokens to be purchased\n */\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n _buyOrder(beneficiary, tokenAmount);\n // _deliverTokens(beneficiary, tokenAmount);\n }\n\n /**\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n * etc.)\n * @param beneficiary Address receiving the tokens\n * @param weiAmount Value in wei involved in the purchase\n */\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n // solhint-disable-previous-line no-empty-blocks\n }\n\n /**\n * @dev Override to extend the way in which ether is converted to tokens.\n * @param weiAmount Value in wei to be converted into tokens\n * @return Number of tokens that can be purchased with the specified _weiAmount\n */\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n uint256 _exp = 10**18;\n uint256 _mult = weiAmount.mul(_exp);\n return _mult.div(_tokenPrice);\n }\n\n /**\n * @dev Determines how ETH is stored/forwarded on purchases.\n */\n function _forwardFunds() internal {\n _startupAddr.transfer(msg.value);\n }\n}\n\nTokenWhitelist.sol:\n pragma solidity ^0.5.2;\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.4.0/contracts/ownership/Ownable.sol\";\n\n// Contrato da nossa whitelist deve ser o primeiro deploy \n\ncontract TokenWhitelist is Ownable {\n mapping(address => bool) private whitelist;\n\n event Whitelisted(address indexed wallet);\n event Dewhitelisted(address indexed wallet);\n\n function enableWallet(address _wallet) public onlyOwner {\n require(_wallet != address(0), \"Invalid wallet\");\n whitelist[_wallet] = true;\n emit Whitelisted(_wallet);\n }\n\n function disableWallet(address _wallet) public onlyOwner {\n whitelist[_wallet] = false;\n emit Dewhitelisted(_wallet);\n }\n\n function checkWhitelisted(address _wallet) public view returns (bool) {\n return whitelist[_wallet];\n }\n}\n\n post by Skyge on Nov 28, 2020\n\n Skyge\n\n Sorry, I tried to deploy it on a testnet, but always get an error when compile the contracts, so can you just verify it on the testnet?\n\n post by abcoathup on Dec 1, 2020\n\n abcoathup\n\n Great contributor\n\n pedromtelho\n\n Hi @pedromtelho,\nYou may want to take a step back and start with a simple example: Simple ERC20 Crowdsale.\nI would suggest extending OpenZeppelin Contracts Crowdsales rather than creating your own. This would also make the code much easier to read (and for your audits, audit). https://docs.openzeppelin.com/contracts/2.x/crowdsales\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract shows error in SafeERC20\n\n Contracts\n\n crowdsale\n\n 3\n\n 5.9k\n\n Jan 2021\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n REVERT Error when buying token from crowdsale\n\n Contracts\n\n erc20\n\n 3\n\n 456\n\n May 2021\n\n Crowdsale: revert when buying tokens\n\n Contracts\n\n erc20,crowdsale\n\n 4\n\n 2.4k\n\n May 2019\n\n Buy direct with Crowdsale without using the buyTokens function\n\n Support\n\n erc20\n\n 23\n\n 2.7k\n\n Jul 2021","tokens":3655,"squid":"ink-security_audits","role":"Sentinel","at":1791265020773,"hash":"3f5a991065e4624bdce860eeb49db48ca82c056c"}
{"url":"https://forum.soliditylang.org/t/abi-encodecall-consistently-generates-cheaper-gas-than-abi-encodewithselector-is-this-by-design/3718/2","domain":"forum.soliditylang.org","title":"abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design? - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 21\n\n 2 / 2\n\n Jun 23\n\n Jun 22\n\n post by 0xkoiner on Jun 21\n\n 0xkoiner\n\n I noticed a consistent gas difference between abi.encodeCall and abi.encodeWithSelector when encoding identical function calls. I’d like to understand if this is an intentional optimization in the compiler or a side effect of different codegen paths.\n// SPDX-License-Identifier: MIT\npragma solidity 0.8.35;\n\ninterface IAuthority {\nfunction canCall(\naddress caller,\naddress target,\nbytes4 selector\n) external view returns (bool allowed);\n}\n\ncontract AbiEncodeCall {\nfunction encode() external pure returns (bytes memory data) { // 1269 gas\ndata = abi.encodeCall(\nIAuthority.canCall,\n(address(0), address(0), bytes4(0xdeadbeaf))\n);\n}\n}\n\ncontract AbiEncodeWithSelector {\nfunction encode() external pure returns (bytes memory data) { // 1272 gas\ndata = abi.encodeWithSelector(\n0xb7009613,\naddress(0),\naddress(0),\nbytes4(0xdeadbeaf)\n);\n}\n}\n\nDoes the compiler generate a different (more optimized) encoding path for abi.encodeCall since it has full type information at compile time?\nIs abi.encodeWithSelector emitting extra masking/padding opcodes because argument types are unknown to the compiler?\nIs this considered a known tradeoff, or would aligning the codegen be desirable?\n\n post by cameel on Jun 22\n\n cameel\n\n Solidity Compiler Team\n\n This is a difference of 3 gas, which very inconsequential. I would not read too much into it. It’s not intentional and comes down to how successful the optimizer is in reducing slightly different but equivalent code into the same minimal bytecode. The difference also only exists in the evmasm pipeline. You get the same output in both cases via IR.\nIf you want to see what exactly happens here, I suggest looking at the differences in the --ir output. In this case, the part that matters is this:\n@@ -171,0 +172,8 @@\n+ function cleanup_t_rational_3070268947_by_1(value) -> cleaned {\n+ cleaned := value\n+ }\n+\n+ function convert_t_rational_3070268947_by_1_to_t_bytes4(value) -> converted {\n+ converted := cleanup_t_bytes4(shift_left_224(cleanup_t_rational_3070268947_by_1(value)))\n+ }\n+\n@@ -213,3 +221 @@\n+ let expr_20 := 0xb7009613\n@@ -217 +223 @@\n- let expr_34_component_1 := expr_25\n@@ -223 +229 @@\n- let expr_34_component_2 := expr_29\n@@ -229 +235 @@\n- let expr_34_component_3 := expr_33\n+ let _2 := convert_t_rational_3070268947_by_1_to_t_bytes4(expr_20)\n@@ -234,2 +240,2 @@\n- mstore(_2, 0xb700961300000000000000000000000000000000000000000000000000000000)\n+ mstore(_3, _2)\n\nThe differences come down to how the constant is stored, cleanup and conversions.\nencodeCall() uses the selector member, which is bytes4 and does not require any conversions. It’s directly stored as 4 bytes padded on the right to a full word. This is cheaper to execute, but also takes more space in the bytecode. encodeWithSelector() version gets an integer value. The integer is shorter, but needs to be shifted and cleaned. If you add an explicit cast to bytes4 in the encodeWithSelector() version, you’ll notice that the output becomes identical (with the only remaining IR differences being the names and metadata).\nThe reason this is inconsequential is that this is just what the codegen produces. The code then still goes through the optimizer, which may change the situation completely depending on your parameters. For example a low value of --optimize-runs may force the bytes4 constant to be deconstructed into a shorter one. And inlining may remove the cleanup (which is a no-op here anyway). The gas differences coming from that can easily overshadow the 3 gas. And the bytecode size is an obvious trade-off.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 191\n\n Jun 9\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1932,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265037131,"hash":"9106993c72c2f264284ace215e929c34542dc1d8"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract-shows-error-in-safeerc20/5053","domain":"forum.openzeppelin.com","title":"Crowdsale contract shows error in SafeERC20 - Support / Contracts - OpenZeppelin Forum","text":"Crowdsale contract shows error in SafeERC20 \n\n SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Dec 2020\n\n 1 / 4\n\n Dec 2020\n\n Jan 2021\n\n post by ashishk74 on Dec 15, 2020\n\n ashishk74\n\n I am writing a Crowdsale contract but function buyTokens does not run and throws an error ,\nexecution reverted: SafeERC20: low-level call failed { “originalError”: { “code”: 3, “data”: “0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000205361666545524332303a206c6f772d6c6576656c2063616c6c206661696c6564”, “message”: “execution reverted: SafeERC20: low-level call failed” } }\n Environment\n Contract made using version 2.5 and run on RemixIDE\nDetails\n\nError seems to be from SafeERC20 library. Deployment of token & crowdsale contracts is smooth.\nMy code is given below:\n Code to reproduce\n\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\ninterface IERC20 {\n\n function totalSupply() external view returns (uint256);\n\n function balanceOf(address account) external view returns (uint256);\n\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n function allowance(address owner, address spender) external view returns (uint256);\n\n function approve(address spender, uint256 amount) external returns (bool);\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n event Approval(address indexed owner, address indexed spender, uint256 value);\n\n}\n\nlibrary SafeMath {\n\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n\n uint256 c = a + b;\n\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n\n }\n\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return sub(a, b, \"SafeMath: subtraction overflow\");\n\n }\n\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n require(b <= a, errorMessage);\n\n uint256 c = a - b;\n\n return c;\n\n }\n\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n\n if (a == 0) {\n\n return 0;\n\n }\n\n uint256 c = a * b;\n\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n\n }\n\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return div(a, b, \"SafeMath: division by zero\");\n\n }\n\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n // Solidity only automatically asserts when dividing by 0\n\n require(b > 0, errorMessage);\n\n uint256 c = a / b;\n\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n\n }\n\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return mod(a, b, \"SafeMath: modulo by zero\");\n\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n require(b != 0, errorMessage);\n\n return a % b;\n\n }\n\n}\n\nlibrary Roles {\n\n struct Role {\n\n mapping (address => bool) bearer;\n\n }\n\n function add(Role storage role, address account) internal {\n\n require(!has(role, account), \"Roles: account already has role\");\n\n role.bearer[account] = true;\n\n }\n\n function remove(Role storage role, address account) internal {\n\n require(has(role, account), \"Roles: account does not have role\");\n\n role.bearer[account] = false;\n\n }\n\n function has(Role storage role, address account) internal view returns (bool) {\n\n require(account != address(0), \"Roles: account is the zero address\");\n\n return role.bearer[account];\n\n }\n\n}\n\nlibrary SafeERC20 {\n\n using SafeMath for uint256;\n\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint256 value) internal {\n\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {\n\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n\n }\n\n function safeApprove(IERC20 token, address spender, uint256 value) internal {\n\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n\n );\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n\n }\n\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n\n }\n\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n\n require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n (bool success, bytes memory returndata) = address(token).call(data);\n\n require(success, \"SafeERC20: low-level call failed\");\n\n if (returndata.length > 0) { // Return data is optional\n\n // solhint-disable-next-line max-line-length\n\n require(abi.decode(returndata, (bool)), \"SafeERC20: ERC20 operation did not succeed\");\n\n }\n\n }\n\n}\n\ncontract ReentrancyGuard {\n\n bool private _notEntered;\n\n constructor () internal {\n\n _notEntered = true;\n\n }\n\n modifier nonReentrant() {\n\n // On the first call to nonReentrant, _notEntered will be true\n\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n\n _notEntered = false;\n\n _;\n\n // By storing the original value once again, a refund is triggered (see\n\n // https://eips.ethereum.org/EIPS/eip-2200)\n\n _notEntered = true;\n\n }\n\n}\n\nlibrary Address {\n\n function isContract(address account) internal view returns (bool) {\n\n bytes32 codehash;\n\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n\n // solhint-disable-next-line no-inline-assembly\n\n assembly { codehash := extcodehash(account) }\n\n return (codehash != accountHash && codehash != 0x0);\n\n }\n\n function toPayable(address account) internal pure returns (address payable) {\n\n return address(uint160(account));\n\n }\n\n function sendValue(address payable recipient, uint256 amount) internal {\n\n require(address(this).balance >= amount, \"Address: insufficient balance\");\n\n // solhint-disable-next-line avoid-call-value\n\n (bool success, ) = recipient.call.value(amount) (\"\");\n\n require(success, \"Address: unable to send value, recipient may have reverted\");\n\n }\n\n}\n\ncontract Context {\n\n function _msgSender() internal view returns (address payable) {\n\n return msg.sender;\n\n }\n\n function _msgData() internal view returns (bytes memory) {\n\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n\n return msg.data;\n\n }\n\n}\n\ncontract ERC20 is Context, IERC20 {\n\n using SafeMath for uint256;\n\n mapping (address => uint256) private _balances;\n\n mapping (address => mapping (address => uint256)) private _allowances;\n\n uint256 private _totalSupply;\n\n function totalSupply() public view returns (uint256) {\n\n return _totalSupply;\n\n }\n\n function balanceOf(address account) public view returns (uint256) {\n\n return _balances[account];\n\n }\n\n function transfer(address recipient, uint256 amount) public returns (bool) {\n\n _transfer(_msgSender(), recipient, amount);\n\n return true;\n\n }\n\n function allowance(address owner, address spender) public view returns (uint256) {\n\n return _allowances[owner][spender];\n\n }\n\n function approve(address spender, uint256 amount) public returns (bool) {\n\n _approve(_msgSender(), spender, amount);\n\n return true;\n\n }\n\n function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {\n\n _transfer(sender, recipient, amount);\n\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n\n return true;\n\n }\n\n function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {\n\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n\n return true;\n\n }\n\n function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {\n\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n\n return true;\n\n }\n\n function _transfer(address sender, address recipient, uint256 amount) internal {\n\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n\n _balances[recipient] = _balances[recipient].add(amount);\n\n emit Transfer(sender, recipient, amount);\n\n }\n\n function _mint(address account, uint256 amount) internal {\n\n require(account != address(0), \"ERC20: mint to the zero address\");\n\n _totalSupply = _totalSupply.add(amount);\n\n _balances[account] = _balances[account].add(amount);\n\n emit Transfer(address(0), account, amount);\n\n }\n\n function _burn(address account, uint256 amount) internal {\n\n require(account != address(0), \"ERC20: burn from the zero address\");\n\n _balances[account] = _balances[account].sub(amount, \"ERC20: burn amount exceeds balance\");\n\n _totalSupply = _totalSupply.sub(amount);\n\n emit Transfer(account, address(0), amount);\n\n }\n\n function _approve(address owner, address spender, uint256 amount) internal {\n\n require(owner != address(0), \"ERC20: approve from the zero address\");\n\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\n\n emit Approval(owner, spender, amount);\n\n }\n\n function _burnFrom(address account, uint256 amount) internal {\n\n _burn(account, amount);\n\n _approve(account, _msgSender(), _allowances[account][_msgSender()].sub(amount, \"ERC20: burn amount exceeds allowance\"));\n\n }\n\n}\n\ncontract ERC20Detailed is IERC20 {\n\n string private _name;\n\n string private _symbol;\n\n uint8 private _decimals;\n\n constructor (string memory name, string memory symbol, uint8 decimals) public {\n\n _name = name;\n\n _symbol = symbol;\n\n _decimals = decimals;\n\n }\n\n function name() public view returns (string memory) {\n\n return _name;\n\n }\n\n function symbol() public view returns (string memory) {\n\n return _symbol;\n\n }\n\n function decimals() public view returns (uint8) {\n\n return _decimals;\n\n }\n\n}\n\ncontract AnnaToken is Context, ERC20, ERC20Detailed {\n\n constructor(\n\n string memory name,\n\n string memory symbol,\n\n uint256 initialSupply\n\n ) public ERC20Detailed(name, symbol, 0) {\n\n _mint(_msgSender(), initialSupply);\n\n }\n\n}\n\ncontract Crowdsale is Context, ReentrancyGuard {\n\n using SafeMath for uint256;\n\n using SafeERC20 for IERC20;\n\n // The token being sold\n\n IERC20 private _token;\n\n // Address where funds are collected\n\n address payable private _wallet;\n\n // How many token units a buyer gets per wei.\n\n // The rate is the conversion between wei and the smallest and indivisible token unit.\n\n // So, if you are using a rate of 1 with a ERC20Detailed token with 3 decimals called TOK\n\n // 1 wei will give you 1 unit, or 0.001 TOK.\n\n uint256 private _rate;\n\n uint256 private _price;\n\n // Amount of wei raised\n\n uint256 private _weiRaised;\n\n /**\n\n * Event for token purchase logging\n\n * @param purchaser who paid for the tokens\n\n * @param beneficiary who got the tokens\n\n * @param value weis paid for purchase\n\n * @param amount amount of tokens purchased\n\n */\n\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n /**\n\n * rate Number of token units a buyer gets per wei\n\n * @param price Number of wei a buyer needs to get per token\n\n * @dev The rate is the conversion between wei and the smallest and indivisible\n\n * token unit. So, if you are using a rate of 1 with a ERC20Detailed token\n\n * with 3 decimals called TOK, 1 wei will give you 1 unit, or 0.001 TOK.\n\n * @param wallet Address where collected funds will be forwarded to\n\n * @param token Address of the token being sold\n\n */\n\n constructor (uint256 price, address payable wallet, IERC20 token) public {\n\n require(price > 0, \"Crowdsale: rate is 0\");\n\n require(wallet != address(0), \"Crowdsale: wallet is the zero address\");\n\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n\n _price = price;\n\n _wallet = wallet;\n\n _token = token;\n\n }\n\n /**\n\n * @dev fallback function ***DO NOT OVERRIDE***\n\n * Note that other contracts will transfer funds with a base gas stipend\n\n * of 2300, which is not enough to call buyTokens. Consider calling\n\n * buyTokens directly when purchasing tokens from a contract.\n\n */\n\n function () external payable {\n\n buyTokens(_msgSender());\n\n }\n\n /**\n\n * @return the token being sold.\n\n */\n\n function token() public view returns (IERC20) {\n\n return _token;\n\n }\n\n /**\n\n * @return the address where funds are collected.\n\n */\n\n function wallet() public view returns (address payable) {\n\n return _wallet;\n\n }\n\n /**\n\n * @return the number of token units a buyer gets per wei.\n\n */\n\n function rate() public view returns (uint256) {\n\n return _rate;\n\n }\n\n function price() public view returns (uint256) {\n\n return _price;\n\n }\n\n /**\n\n * @return the amount of wei raised.\n\n */\n\n function weiRaised() public view returns (uint256) {\n\n return _weiRaised;\n\n }\n\n /**\n\n * @dev low level token purchase ***DO NOT OVERRIDE***\n\n * This function has a non-reentrancy guard, so it shouldn't be called by\n\n * another `nonReentrant` function.\n\n * @param beneficiary Recipient of the token purchase\n\n */\n\n function buyTokens(address beneficiary) public nonReentrant payable {\n\n uint256 weiAmount = msg.value;\n\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n\n _postValidatePurchase(beneficiary, weiAmount);\n\n }\n\n /**\n\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n\n * super._preValidatePurchase(beneficiary, weiAmount);\n\n * require(weiRaised().add(weiAmount) <= cap);\n\n * @param beneficiary Address performing the token purchase\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n\n }\n\n /**\n\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n\n * conditions are not met.\n\n * @param beneficiary Address performing the token purchase\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n\n // solhint-disable-previous-line no-empty-blocks\n\n }\n\n /**\n\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n\n * its tokens.\n\n * @param beneficiary Address performing the token purchase\n\n * @param tokenAmount Number of tokens to be emitted\n\n */\n\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n\n _token.safeTransfer(beneficiary, tokenAmount);\n\n }\n\n /**\n\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n\n * tokens.\n\n * @param beneficiary Address receiving the tokens\n\n * @param tokenAmount Number of tokens to be purchased\n\n */\n\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n\n _deliverTokens(beneficiary, tokenAmount);\n\n }\n\n /**\n\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n\n * etc.)\n\n * @param beneficiary Address receiving the tokens\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n\n // solhint-disable-previous-line no-empty-blocks\n\n }\n\n /**\n\n * @dev Override to extend the way in which ether is converted to tokens.\n\n * @param weiAmount Value in wei to be converted into tokens\n\n * @return Number of tokens that can be purchased with the specified _weiAmount\n\n */\n\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n\n return weiAmount.div(_price);\n\n }\n\n /**\n\n * @dev Determines how ETH is stored/forwarded on purchases.\n\n */\n\n function _forwardFunds() internal {\n\n _wallet.transfer(msg.value);\n\n }\n\n}\n\ncontract AnnaCrowdsale is Crowdsale {\n\n constructor(\n\n uint256 rate,\n\n address payable wallet,\n\n IERC20 token\n\n ) public Crowdsale(rate, wallet, token) {}\n\n}\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by abcoathup on Dec 15, 2020\n\n 19 days later\n\n post by abcoathup on Jan 3, 2021\n\n post by ashishk74 on Jan 3, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n Satisfies all conditions set by Solidity `require` statements. does not trigger a Solidity `revert` statement. SafeERC20: low-level call failed\n\n Smart Contracts\n\n crowdsale\n\n 0\n\n 1.2k\n\n Mar 2022\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020\n\n Crowdsale buyTokens fails with error ‘SafeERC20: low-level call failed’\n\n Contracts\n\n 2\n\n 2.5k\n\n Mar 2021\n\n Contract Crowdsale SafeMath: subtraction overflow”, “data” error\n\n Support\n\n 1\n\n 4.2k\n\n May 2021","tokens":4608,"squid":"ink-security_audits","role":"Sentinel","at":1791265043005,"hash":"ee226ea8467e1bc92c76e9effc73d45cc4505da8"}
{"url":"https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298","domain":"ethresear.ch","title":"Plasma Cash: Plasma with much less per-user data checking - Layer 2 / Plasma - Ethereum Research","text":"Plasma Cash: Plasma with much less per-user data checking \n\n Layer 2Plasma\n\n new-extension\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2018\n\n 1 / 116\n\n Mar 2018\n\n Jan 2019\n\n post by vbuterin on Mar 3, 2018\n\n vbuterin\n\n [2018.03.10: updated with exit procedure]\nSpecial thanks to Karl Floersch for discussion and coming up with much of this, as well as @danrobinson’s earlier posts that expressed similar ideas.\nBasically, we can design a version of Plasma with the following modifications:\n\nEvery single deposit corresponds to a unique coin ID; tokens are indivisible and cannot be merged.\nInstead of storing transactions in a binary Merkle tree in order of txindex, we require them to be stored in either a sparse simple Merkle tree or a patricia tree, with the index being the ID of the coin that is spent.\n\nNote that this now allows a user to have a somewhat compact proof that their coin is valid: all the transactions since the time the coin was deposited that represent that coin’s history, plus a proof of non-inclusion for every block that does not contain a transaction spending the coin, to verify that the coin was not double spent. With n𝑛 coins and t𝑡 blocks, this proof has size t * log(n)𝑡 ∗𝑙𝑜𝑔(𝑛). If a user transfers a coin to another user, he could simply pass along the entire proof to that user.\nHence, a Plasma operator could simply maintain connections with each user, and every time they create a block they would publish to them only the proofs, not any data related to coins that they do not own. It’s clearly the case that any data that is not part of these proofs could not be used to fraudulently exit or double-spend the user’s coin, so the user is safe. Because coins are non-fungible, successfully defrauding other users cannot allow the Plasma contract to turn into a fractional reserve, as is possible in minimal viable plasma.\nThe Plasma chain operator could be sharded, so there is virtually no limit to the system’s scalability from the point of view of either the chain operator or the users, though the limitation that if Plasma-like systems (and channel systems) start processing a very high transaction load, mass challenge attacks may overflow the blockchain and prevent some users from exiting or responding to challenges still remain. This kind of setup seems ideal for very-high-throughput but low or medium-state applications, like micropayments and exchanges.\nAdditionally, we can remove the need for confirmations. We do this by having the following exit procedure:\n\nAnyone can exit their coin by providing the last two transactions in the coin’s ownership history (ie. the coin they are exiting C and its parent P( C )).\nAn exit can be challenged in three ways: (i) provide a proof of a transaction spending C, (ii) provide a proof of a transaction spending P( C ) that appears before C, (iii) provide a transaction C* in the coin’s history before P( C )\nA challenge of type (i) and (ii) blocks the exit immediately. A challenge of type (iii) can be responded to by providing the direct child of C*, which must be either equal to or before P( C )\n\nThis relies on honest users maintaining the key property that they never spend a coin until they have fully authenticated the entire history up to that coin. It could be the case that a Plasma chain starts including unavailable or invalid data while a transaction is in flight, in which case double spends or invalid spends could appear between P( C ) and C; the slightly more complicated exit mechanism takes this into account.\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n Plasma is an useless idea\n\n A simpler exit game for Plasma Cash\n\n Trustless Two-Way Bridges With Side Chains By Halting\n\n Minimal Viable Plasma\n\n 27\n\n 15\n\n 15\n\n 12\n\n 6\n\n read \n\n 36\n min\n\n post by vbuterin on Mar 4, 2018\n\n vbuterin\n\n Addenda:\n\nYou don’t actually have to pass around t * log(n)𝑡 ∗𝑙𝑜𝑔(𝑛) data if you can instead pass on a ZK-SNARK of data. This could be done with recursive snarks to keep the total data passed around O(1) size.\nConfirmations could easily be removed from the scheme. The solution is effectively a design where there is one level of interactive history verification, and spending a coin effectively takes on the role of a confirmation. That is, withdrawing requires a proof of a coin C, and if someone challenges with an earlier coin, then you can provide the parent P(C ); they would then need to prove a coin spending P(C ) that comes earlier than C to challenge.\n\n post by danrobinson on Mar 5, 2018\n\n danrobinson\n\n This is great—and definitely improves on the trade-offs in a Plasma context, relative to my previous suggestions.\nFew questions:\n\nPerhaps you could cut down on the size of the non-existence proofs by putting a Bloom filter of the spent coins in the Plasma block header. Everyone could receive and cache the Bloom filters, and you’d only need a proof for blocks for which there’s a false positive for your coin. I’m not that familiar with probabilistic data structures but I wonder if there’s a way to parametrize it so that the shared data is pretty small but, absent misbehavior by the Plasma chain operator, false positives will happen so rarely (say 1 in a billion transactions) that withdrawal would be a sufficient remedy.\nI’m not sure it would work to use a ZK-snark for the non-existence proofs, unless the parent chain is willing to accept ZK-snarks for the exit transactions. Otherwise, you don’t have enough information to respond to a challenger, right?\n\n Chronos: A Quirky Application Proposal for Plasma\n\n post by vbuterin on Mar 5, 2018\n\n vbuterin\n\nI’m not sure it would work to use a ZK-snark for the non-existence proofs, unless the parent chain is willing to accept ZK-snarks for the exit transactions. Otherwise, you don’t have enough information to respond to a challenger, right?\n\nNow that I think about it, you are right. In order to be able to respond to type (iii) challenges you have the proofs for every transfer in the coin’s actual history. If there are t𝑡 blocks and hℎ transfers (history length), then this already reduces required data size from 32 * t * log(n)32 ∗𝑡 ∗𝑙𝑜𝑔(𝑛) to 32 * h * log(n) + 28832 ∗ℎ ∗𝑙𝑜𝑔(𝑛) +288. What we can also do is make a recursive SNARK that proves the list of block numbers for which a proof exists; this would bring it down to h * \\frac{log(t)}{8} + 288ℎ ∗𝑙𝑜𝑔(𝑡)8 +288 bytes (\\frac{log(t)}{8}𝑙𝑜𝑔(𝑡)8 because we need log(t)𝑙𝑜𝑔(𝑡) bits to represent each block number, and a byte is 8 bits). To see how small this is, consider a Plasma chain with one block per Ethereum block that lasts for one year, with a history 500 transfers long; the chain would have 2.2 million blocks, so the data size would be 500 * 21 bits + 288 bytes = 1600 bytes.\n\n Plasma Cash verification cost\n\n post by danrobinson on Mar 5, 2018\n\n danrobinson\n\nAccording to this Bloom filter calculator, a 1 KB Bloom filter with a maximum of 200 items has a false positive probability of 1 in 1 billion. If my math is right, that means if you have one Plasma block per Ethereum block, that’s < 3 GB of block header storage per year, and you’d expect to see a false positive on one of your coins about every 380 years (in which case you’d be able to respond by withdrawing anyway, or perhaps by revealing the transactions that generated the false positive). So perhaps you could cut out the Patricia tree entirely, and just store transactions in a normal Merkle tree, with the Bloom filter serving as the only proof of non-existence. (EDIT: nope, you would still need to store the transactions in a sparse Merkle tree or Patricia tree, so you could prove that your transaction is the only one spending that coin in that block. It’s still a very small proof, though.) The main benefit of this scheme is that most of the data would be common to all users and coins, rather than having coin-specific proofs that need to be passed around with every transaction.\nIf you use a cryptographic hash function for the filter and coin IDs are generated using entropy from the chain operator, I think that weakens anyone else’s ability to grind out a false positive for your coin, although maybe you still need some additional hardening (like using a per-block salt for the hashes).\nThis does give up a little privacy (anyone, not just the chain operator, can tell when a coin is spent), although maybe there’s a way to preserve that too.\n\n post by kfichter on Mar 5, 2018\n\n kfichter\n\nI believe the size of the bloom filter would scale linearly with the number of items & increasing the false positive rate wouldn’t significantly decrease the size of the filter. That could be a preferable (and relatively simple) scheme for low-throughput chains.\n\nWhat if a block contains two transactions that spend the same coin?\n\n post by vbuterin on Mar 5, 2018\n\n vbuterin\n\nWhat if a block contains two transactions that spend the same coin?\n\nIn my design, not possible. The transaction’s position in the Merkle tree must be the ID of the coin, so you cannot have two transactions in one block that spend the same coin.\n\n post by kfichter on Mar 9, 2018\n\n kfichter\n\n Would coin ID => denomination be stored as a mapping on the root chain? That would limit the minimum viable deposit. You might be able to improve ux/decrease gas cost with a “change machine,” i.e. insert n root chain tokens/ETH and receive m coin IDs each with value n/m.\nAlso, how are transactions actually validated? Something like this?\n\nValidate that each transaction in the history I was given is actually included in its corresponding block with a Merkle membership proof and then\nValidate each proof of non-inclusion\n\nI’m also interested in understanding how the non-inclusion proofs are generated.\n\n post by vbuterin on Mar 10, 2018\n\n vbuterin\n\nWould coin ID => denomination be stored as a mapping on the root chain?\n\nYes.\n\nI’m also interested in understanding how the non-inclusion proofs are generated.\n\nA non-inclusion proof is basically a proof that there exists an object at the given position in the Merkle tree, and this object is empty data.\n\nBasically yes.\n\n post by ldct on Mar 10, 2018\n\n ldct\n\n Could the coin ID => denomination mapping be deterministic, e.g. create a complete binary tree of height 31, label each node with a 32-bit id and the denomination of a coin is 2^h where h is the height of its id in the tree. Users can only deposit in powers of two, there is an upper bound on the total amount that the chain can hold, and are allowed to split coins in half and merge them. A constraint is maintained that along each root-to-leaf path only one coin can be issued.\n\n post by kfichter on Mar 10, 2018\n\n kfichter\n\nI don’t see why you couldn’t also just make it a non-binary tree. Say root node is worth some large value, second layer splits the value into many usable chunks (n 100 ETH coins), then each broken down into more (five 20 ETH coins), etc. etc.\n\nHow would this work? Would the user have to own the specific two consecutive coins in order to merge a layer up?\n\n post by kfichter on Mar 10, 2018\n\n kfichter\n\n David Knott and I discussed a “merge/split” transaction where a user could point to specific coin IDs they own (by referencing outputs) and reshape them into new coin IDs that have different denominations but the same total value. This maintains the property that only specific users can be grieved (owners of those coin IDs). The transaction would require a challenge period much like the Plasma MVP exit transaction. A merge/split is invalidated under the same conditions as\n\nThis construction would allow users to modify their coins without having to exit and deposit again.\nI also started thinking about the idea of “change providers” - users who carry a large amount of change to assist in transactions where one or both parties can’t make correct change. To illustrate:\nAlice wants to send 7 ETH to Bob, but doesn’t have a 7 ETH coin. Alice has a 10 ETH coin and some smaller coins. Bob does not have a 3 ETH coin to send in return. Carol is a change provider who happens to have both a 7 ETH coin and a 3 ETH coin. Alice and Carol construct a transaction in which the following ownership transfers occur:\n\nAlice sends a 10 ETH coin to Carol\nCarol sends a 7 ETH coin to Bob\nCarol sends a 3 ETH coin to Alice\nAlice sends some small ETH coin to Carol as a fee\n\nThis last fee component is obviously the complicating factor, as it requires Alice to have some specific small ETH coin on hand to make the transaction. In the absence of a change provider, Alice could use the merge/split transaction mentioned above to convert her 10 ETH coin into 7 ETH and 3 ETH coins to transact with Bob. However, this is significantly slower due to the challenge period.\n\n Plasma Debit: Arbitrary-denomination payments in Plasma Cash\n\n post by MaxC on Mar 10, 2018\n\n MaxC\n\n danrobinson\n\nHey Dan/Vitalik, would you mind explaining why ZK snarks wouldn’t work to prove ownership of a coin non-interactively?\nFrom what I understand, exit transactions for a coin would be recorded on the parent block-chain, and you would need to prove no exit transactions had been made. So would that not just increase the number of the proofs by a factor of d, the depth of the plasma tree for a coin.\n\n post by danrobinson on Mar 10, 2018\n\n danrobinson\n\nI’m assuming you can’t use any ZK-snarks on the parent chain (which would require trusted setup, and for everyone to share your security assumptions, etc); you can only use ZK-snarks for user-to-user proofs. So the receiving user needs enough data to be able to respond to any possible type (iii) challenge, for when they attempt to exit.\n\nThat’s not the hard part of the proof (the Ethereum state root suffices to prove that); you have to prove (directly) that you own the coin at time T, and (cryptoeconomically) that nobody spent that coin on the plasma chain after time T, and that there is a valid history of that output tracing back to the deposit, with no double-spends. That last part is what you need the additional data for; otherwise you can’t respond to a type (iii) challenge (even if you know, through a ZK-snark, that your coin does have a valid history).\n\n post by vbuterin on Mar 11, 2018\n\n vbuterin\n\nThey can prove integrity of a history, but a ZK snark does NOT give you the information that you need to fend of challenges in the challenge-response game that tries to prove that there are no earlier correct histories.\n\n post by MaxC on Mar 11, 2018\n\n MaxC\n\n MaxC\n\nOk thanks. It seems to me, as long as you share information about which coins are being spent every epoch, you can have ZK proofs for non-existence. However, you don’t need to share all the information relating to that coin.\nSuppose leaf nodes of the transaction tree were two tiered, with data at the bottom relating to a transaction , and a hash of the data at the top.\nOperators could share general data about the whole tree excluding the bottom tier of leaf nodes to the network.\nTo construct a non-existence proof, you can:\n(1) show that your coin is not included in the merkle tree\n(2) Suppose wlg. that you have a coin, and someone has just now fraudulently double spent it. You can prove that this person spending the coin could not have been you, the person with (up until now) a valid proof of ownership. We do this by including an extra field in the leaves.\n\nIn the bottom tier of the leaf we also include a signature of the hash of the transaction.\n\nWe now have two hashes on the top tier, one for the transaction and one for your signature of the hash of the transaction. A non-existence proof is a proof that your signature of the transaction hash could not hash to the value stored and so the transaction is invalid.\n\nI think that is sufficient as a construction to prove that you are the rightful owner of a coin at time t, if indeed you are.\n\n post by vbuterin on Mar 11, 2018\n\n vbuterin\n\nTo construct a non-existence proof, you can:\n(1) show that your coin is not included in the merkle tree\n\nYes, but what if A sends a transaction to B, while that transaction is inflight the Plasma chain becomes byzantine, and so the transaction gets included after some unavailable Plasma blocks? Then B does not have the data to prove that the transaction is not a double-spend.\n\n post by MaxC on Mar 11, 2018\n\n MaxC\n\n A few thoughts, please correct me if I am wrong:\n(1) Transactions could contain a block number so it would be impossible to put a transaction in a later block, and generate a proof for it.\n(2) If A doesn’t receive the merkle information from the byzantine chain, she could exit before the new block is finalised in the parent block.\n(3) We assume it is A’s responsibility to pass on the merkle information to B.\nI guess such a scheme might then require proofs of non-existence for withdrawals in the parent chain.\n\n Reliable Exits of Withheld In-flight Transactions (\"Limbo Exits\")\n\n Plasma Cash with smaller exit procedure, and a general approach to safety proofs\n\n post by vbuterin on Mar 11, 2018\n\n vbuterin\n\nTransactions could contain a block number so it would be impossible to put a transaction in a later block, and generate a proof for it.\n\nSo a transaction generated after block N would have N+1 included in them and so could only be included in block N+1? That is brilliant; it actually does remove the need to worry about inflight transactions.\n\n post by kfichter on Mar 11, 2018\n\n kfichter\n\nHow is N+1 counted? Would have to ignore deposit/exit blocks.\nAlso, what if the tx is included in block N+1, N+1 is published to the root chain but withheld?\n\n Load more posts below","tokens":4405,"squid":"ink-research","role":"Deep Scholar","at":1791265043754,"hash":"440e598b8110a1d39a4490edcbe3e37513e5355d"}
{"url":"https://forum.soliditylang.org/t/abi-encodecall-consistently-generates-cheaper-gas-than-abi-encodewithselector-is-this-by-design/3718/1","domain":"forum.soliditylang.org","title":"abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design? - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design? \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 21\n\n 1 / 2\n\n Jun 22\n\n Jun 22\n\n post by 0xkoiner on Jun 21\n\n 0xkoiner\n\n I noticed a consistent gas difference between abi.encodeCall and abi.encodeWithSelector when encoding identical function calls. I’d like to understand if this is an intentional optimization in the compiler or a side effect of different codegen paths.\n// SPDX-License-Identifier: MIT\npragma solidity 0.8.35;\n\ninterface IAuthority {\nfunction canCall(\naddress caller,\naddress target,\nbytes4 selector\n) external view returns (bool allowed);\n}\n\ncontract AbiEncodeCall {\nfunction encode() external pure returns (bytes memory data) { // 1269 gas\ndata = abi.encodeCall(\nIAuthority.canCall,\n(address(0), address(0), bytes4(0xdeadbeaf))\n);\n}\n}\n\ncontract AbiEncodeWithSelector {\nfunction encode() external pure returns (bytes memory data) { // 1272 gas\ndata = abi.encodeWithSelector(\n0xb7009613,\naddress(0),\naddress(0),\nbytes4(0xdeadbeaf)\n);\n}\n}\n\nDoes the compiler generate a different (more optimized) encoding path for abi.encodeCall since it has full type information at compile time?\nIs abi.encodeWithSelector emitting extra masking/padding opcodes because argument types are unknown to the compiler?\nIs this considered a known tradeoff, or would aligning the codegen be desirable?\n\n post by cameel on Jun 22\n\n cameel\n\n Solidity Compiler Team\n\n This is a difference of 3 gas, which very inconsequential. I would not read too much into it. It’s not intentional and comes down to how successful the optimizer is in reducing slightly different but equivalent code into the same minimal bytecode. The difference also only exists in the evmasm pipeline. You get the same output in both cases via IR.\nIf you want to see what exactly happens here, I suggest looking at the differences in the --ir output. In this case, the part that matters is this:\n@@ -171,0 +172,8 @@\n+ function cleanup_t_rational_3070268947_by_1(value) -> cleaned {\n+ cleaned := value\n+ }\n+\n+ function convert_t_rational_3070268947_by_1_to_t_bytes4(value) -> converted {\n+ converted := cleanup_t_bytes4(shift_left_224(cleanup_t_rational_3070268947_by_1(value)))\n+ }\n+\n@@ -213,3 +221 @@\n+ let expr_20 := 0xb7009613\n@@ -217 +223 @@\n- let expr_34_component_1 := expr_25\n@@ -223 +229 @@\n- let expr_34_component_2 := expr_29\n@@ -229 +235 @@\n- let expr_34_component_3 := expr_33\n+ let _2 := convert_t_rational_3070268947_by_1_to_t_bytes4(expr_20)\n@@ -234,2 +240,2 @@\n- mstore(_2, 0xb700961300000000000000000000000000000000000000000000000000000000)\n+ mstore(_3, _2)\n\nThe differences come down to how the constant is stored, cleanup and conversions.\nencodeCall() uses the selector member, which is bytes4 and does not require any conversions. It’s directly stored as 4 bytes padded on the right to a full word. This is cheaper to execute, but also takes more space in the bytecode. encodeWithSelector() version gets an integer value. The integer is shorter, but needs to be shifted and cleaned. If you add an explicit cast to bytes4 in the encodeWithSelector() version, you’ll notice that the output becomes identical (with the only remaining IR differences being the names and metadata).\nThe reason this is inconsequential is that this is just what the codegen produces. The code then still goes through the optimizer, which may change the situation completely depending on your parameters. For example a low value of --optimize-runs may force the bytes4 constant to be deconstructed into a shorter one. And inlining may remove the cleanup (which is a no-op here anyway). The gas differences coming from that can easily overshadow the 3 gas. And the bytecode size is an obvious trade-off.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1951,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265050173,"hash":"486242dbd67af0d2f5b91ae3dbcd7c8b50f76b53"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract-shows-error-in-safeerc20/5053/2","domain":"forum.openzeppelin.com","title":"Crowdsale contract shows error in SafeERC20 - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n Dec 2020\n\n 2 / 4\n\n Dec 2020\n\n Jan 2021\n\n post by ashishk74 on Dec 15, 2020\n\n ashishk74\n\n I am writing a Crowdsale contract but function buyTokens does not run and throws an error ,\nexecution reverted: SafeERC20: low-level call failed { “originalError”: { “code”: 3, “data”: “0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000205361666545524332303a206c6f772d6c6576656c2063616c6c206661696c6564”, “message”: “execution reverted: SafeERC20: low-level call failed” } }\n Environment\n Contract made using version 2.5 and run on RemixIDE\nDetails\n\nError seems to be from SafeERC20 library. Deployment of token & crowdsale contracts is smooth.\nMy code is given below:\n Code to reproduce\n\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\ninterface IERC20 {\n\n function totalSupply() external view returns (uint256);\n\n function balanceOf(address account) external view returns (uint256);\n\n function transfer(address recipient, uint256 amount) external returns (bool);\n\n function allowance(address owner, address spender) external view returns (uint256);\n\n function approve(address spender, uint256 amount) external returns (bool);\n\n function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);\n\n event Transfer(address indexed from, address indexed to, uint256 value);\n\n event Approval(address indexed owner, address indexed spender, uint256 value);\n\n}\n\nlibrary SafeMath {\n\n function add(uint256 a, uint256 b) internal pure returns (uint256) {\n\n uint256 c = a + b;\n\n require(c >= a, \"SafeMath: addition overflow\");\n\n return c;\n\n }\n\n function sub(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return sub(a, b, \"SafeMath: subtraction overflow\");\n\n }\n\n function sub(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n require(b <= a, errorMessage);\n\n uint256 c = a - b;\n\n return c;\n\n }\n\n function mul(uint256 a, uint256 b) internal pure returns (uint256) {\n\n if (a == 0) {\n\n return 0;\n\n }\n\n uint256 c = a * b;\n\n require(c / a == b, \"SafeMath: multiplication overflow\");\n\n return c;\n\n }\n\n function div(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return div(a, b, \"SafeMath: division by zero\");\n\n }\n\n function div(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n // Solidity only automatically asserts when dividing by 0\n\n require(b > 0, errorMessage);\n\n uint256 c = a / b;\n\n // assert(a == b * c + a % b); // There is no case in which this doesn't hold\n\n return c;\n\n }\n\n function mod(uint256 a, uint256 b) internal pure returns (uint256) {\n\n return mod(a, b, \"SafeMath: modulo by zero\");\n\n }\n\n function mod(uint256 a, uint256 b, string memory errorMessage) internal pure returns (uint256) {\n\n require(b != 0, errorMessage);\n\n return a % b;\n\n }\n\n}\n\nlibrary Roles {\n\n struct Role {\n\n mapping (address => bool) bearer;\n\n }\n\n function add(Role storage role, address account) internal {\n\n require(!has(role, account), \"Roles: account already has role\");\n\n role.bearer[account] = true;\n\n }\n\n function remove(Role storage role, address account) internal {\n\n require(has(role, account), \"Roles: account does not have role\");\n\n role.bearer[account] = false;\n\n }\n\n function has(Role storage role, address account) internal view returns (bool) {\n\n require(account != address(0), \"Roles: account is the zero address\");\n\n return role.bearer[account];\n\n }\n\n}\n\nlibrary SafeERC20 {\n\n using SafeMath for uint256;\n\n using Address for address;\n\n function safeTransfer(IERC20 token, address to, uint256 value) internal {\n\n callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));\n\n }\n\n function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {\n\n callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));\n\n }\n\n function safeApprove(IERC20 token, address spender, uint256 value) internal {\n\n require((value == 0) || (token.allowance(address(this), spender) == 0),\n\n \"SafeERC20: approve from non-zero to non-zero allowance\"\n\n );\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\n\n }\n\n function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n\n uint256 newAllowance = token.allowance(address(this), spender).add(value);\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n\n }\n\n function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {\n\n uint256 newAllowance = token.allowance(address(this), spender).sub(value, \"SafeERC20: decreased allowance below zero\");\n\n callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));\n\n }\n\n function callOptionalReturn(IERC20 token, bytes memory data) private {\n\n require(address(token).isContract(), \"SafeERC20: call to non-contract\");\n\n (bool success, bytes memory returndata) = address(token).call(data);\n\n require(success, \"SafeERC20: low-level call failed\");\n\n if (returndata.length > 0) { // Return data is optional\n\n // solhint-disable-next-line max-line-length\n\n require(abi.decode(returndata, (bool)), \"SafeERC20: ERC20 operation did not succeed\");\n\n }\n\n }\n\n}\n\ncontract ReentrancyGuard {\n\n bool private _notEntered;\n\n constructor () internal {\n\n _notEntered = true;\n\n }\n\n modifier nonReentrant() {\n\n // On the first call to nonReentrant, _notEntered will be true\n\n require(_notEntered, \"ReentrancyGuard: reentrant call\");\n\n // Any calls to nonReentrant after this point will fail\n\n _notEntered = false;\n\n _;\n\n // By storing the original value once again, a refund is triggered (see\n\n // https://eips.ethereum.org/EIPS/eip-2200)\n\n _notEntered = true;\n\n }\n\n}\n\nlibrary Address {\n\n function isContract(address account) internal view returns (bool) {\n\n bytes32 codehash;\n\n bytes32 accountHash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470;\n\n // solhint-disable-next-line no-inline-assembly\n\n assembly { codehash := extcodehash(account) }\n\n return (codehash != accountHash && codehash != 0x0);\n\n }\n\n function toPayable(address account) internal pure returns (address payable) {\n\n return address(uint160(account));\n\n }\n\n function sendValue(address payable recipient, uint256 amount) internal {\n\n require(address(this).balance >= amount, \"Address: insufficient balance\");\n\n // solhint-disable-next-line avoid-call-value\n\n (bool success, ) = recipient.call.value(amount) (\"\");\n\n require(success, \"Address: unable to send value, recipient may have reverted\");\n\n }\n\n}\n\ncontract Context {\n\n function _msgSender() internal view returns (address payable) {\n\n return msg.sender;\n\n }\n\n function _msgData() internal view returns (bytes memory) {\n\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n\n return msg.data;\n\n }\n\n}\n\ncontract ERC20 is Context, IERC20 {\n\n using SafeMath for uint256;\n\n mapping (address => uint256) private _balances;\n\n mapping (address => mapping (address => uint256)) private _allowances;\n\n uint256 private _totalSupply;\n\n function totalSupply() public view returns (uint256) {\n\n return _totalSupply;\n\n }\n\n function balanceOf(address account) public view returns (uint256) {\n\n return _balances[account];\n\n }\n\n function transfer(address recipient, uint256 amount) public returns (bool) {\n\n _transfer(_msgSender(), recipient, amount);\n\n return true;\n\n }\n\n function allowance(address owner, address spender) public view returns (uint256) {\n\n return _allowances[owner][spender];\n\n }\n\n function approve(address spender, uint256 amount) public returns (bool) {\n\n _approve(_msgSender(), spender, amount);\n\n return true;\n\n }\n\n function transferFrom(address sender, address recipient, uint256 amount) public returns (bool) {\n\n _transfer(sender, recipient, amount);\n\n _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, \"ERC20: transfer amount exceeds allowance\"));\n\n return true;\n\n }\n\n function increaseAllowance(address spender, uint256 addedValue) public returns (bool) {\n\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));\n\n return true;\n\n }\n\n function decreaseAllowance(address spender, uint256 subtractedValue) public returns (bool) {\n\n _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, \"ERC20: decreased allowance below zero\"));\n\n return true;\n\n }\n\n function _transfer(address sender, address recipient, uint256 amount) internal {\n\n require(sender != address(0), \"ERC20: transfer from the zero address\");\n\n require(recipient != address(0), \"ERC20: transfer to the zero address\");\n\n _balances[sender] = _balances[sender].sub(amount, \"ERC20: transfer amount exceeds balance\");\n\n _balances[recipient] = _balances[recipient].add(amount);\n\n emit Transfer(sender, recipient, amount);\n\n }\n\n function _mint(address account, uint256 amount) internal {\n\n require(account != address(0), \"ERC20: mint to the zero address\");\n\n _totalSupply = _totalSupply.add(amount);\n\n _balances[account] = _balances[account].add(amount);\n\n emit Transfer(address(0), account, amount);\n\n }\n\n function _burn(address account, uint256 amount) internal {\n\n require(account != address(0), \"ERC20: burn from the zero address\");\n\n _balances[account] = _balances[account].sub(amount, \"ERC20: burn amount exceeds balance\");\n\n _totalSupply = _totalSupply.sub(amount);\n\n emit Transfer(account, address(0), amount);\n\n }\n\n function _approve(address owner, address spender, uint256 amount) internal {\n\n require(owner != address(0), \"ERC20: approve from the zero address\");\n\n require(spender != address(0), \"ERC20: approve to the zero address\");\n\n _allowances[owner][spender] = amount;\n\n emit Approval(owner, spender, amount);\n\n }\n\n function _burnFrom(address account, uint256 amount) internal {\n\n _burn(account, amount);\n\n _approve(account, _msgSender(), _allowances[account][_msgSender()].sub(amount, \"ERC20: burn amount exceeds allowance\"));\n\n }\n\n}\n\ncontract ERC20Detailed is IERC20 {\n\n string private _name;\n\n string private _symbol;\n\n uint8 private _decimals;\n\n constructor (string memory name, string memory symbol, uint8 decimals) public {\n\n _name = name;\n\n _symbol = symbol;\n\n _decimals = decimals;\n\n }\n\n function name() public view returns (string memory) {\n\n return _name;\n\n }\n\n function symbol() public view returns (string memory) {\n\n return _symbol;\n\n }\n\n function decimals() public view returns (uint8) {\n\n return _decimals;\n\n }\n\n}\n\ncontract AnnaToken is Context, ERC20, ERC20Detailed {\n\n constructor(\n\n string memory name,\n\n string memory symbol,\n\n uint256 initialSupply\n\n ) public ERC20Detailed(name, symbol, 0) {\n\n _mint(_msgSender(), initialSupply);\n\n }\n\n}\n\ncontract Crowdsale is Context, ReentrancyGuard {\n\n using SafeMath for uint256;\n\n using SafeERC20 for IERC20;\n\n // The token being sold\n\n IERC20 private _token;\n\n // Address where funds are collected\n\n address payable private _wallet;\n\n // How many token units a buyer gets per wei.\n\n // The rate is the conversion between wei and the smallest and indivisible token unit.\n\n // So, if you are using a rate of 1 with a ERC20Detailed token with 3 decimals called TOK\n\n // 1 wei will give you 1 unit, or 0.001 TOK.\n\n uint256 private _rate;\n\n uint256 private _price;\n\n // Amount of wei raised\n\n uint256 private _weiRaised;\n\n /**\n\n * Event for token purchase logging\n\n * @param purchaser who paid for the tokens\n\n * @param beneficiary who got the tokens\n\n * @param value weis paid for purchase\n\n * @param amount amount of tokens purchased\n\n */\n\n event TokensPurchased(address indexed purchaser, address indexed beneficiary, uint256 value, uint256 amount);\n\n /**\n\n * rate Number of token units a buyer gets per wei\n\n * @param price Number of wei a buyer needs to get per token\n\n * @dev The rate is the conversion between wei and the smallest and indivisible\n\n * token unit. So, if you are using a rate of 1 with a ERC20Detailed token\n\n * with 3 decimals called TOK, 1 wei will give you 1 unit, or 0.001 TOK.\n\n * @param wallet Address where collected funds will be forwarded to\n\n * @param token Address of the token being sold\n\n */\n\n constructor (uint256 price, address payable wallet, IERC20 token) public {\n\n require(price > 0, \"Crowdsale: rate is 0\");\n\n require(wallet != address(0), \"Crowdsale: wallet is the zero address\");\n\n require(address(token) != address(0), \"Crowdsale: token is the zero address\");\n\n _price = price;\n\n _wallet = wallet;\n\n _token = token;\n\n }\n\n /**\n\n * @dev fallback function ***DO NOT OVERRIDE***\n\n * Note that other contracts will transfer funds with a base gas stipend\n\n * of 2300, which is not enough to call buyTokens. Consider calling\n\n * buyTokens directly when purchasing tokens from a contract.\n\n */\n\n function () external payable {\n\n buyTokens(_msgSender());\n\n }\n\n /**\n\n * @return the token being sold.\n\n */\n\n function token() public view returns (IERC20) {\n\n return _token;\n\n }\n\n /**\n\n * @return the address where funds are collected.\n\n */\n\n function wallet() public view returns (address payable) {\n\n return _wallet;\n\n }\n\n /**\n\n * @return the number of token units a buyer gets per wei.\n\n */\n\n function rate() public view returns (uint256) {\n\n return _rate;\n\n }\n\n function price() public view returns (uint256) {\n\n return _price;\n\n }\n\n /**\n\n * @return the amount of wei raised.\n\n */\n\n function weiRaised() public view returns (uint256) {\n\n return _weiRaised;\n\n }\n\n /**\n\n * @dev low level token purchase ***DO NOT OVERRIDE***\n\n * This function has a non-reentrancy guard, so it shouldn't be called by\n\n * another `nonReentrant` function.\n\n * @param beneficiary Recipient of the token purchase\n\n */\n\n function buyTokens(address beneficiary) public nonReentrant payable {\n\n uint256 weiAmount = msg.value;\n\n _preValidatePurchase(beneficiary, weiAmount);\n\n // calculate token amount to be created\n\n uint256 tokens = _getTokenAmount(weiAmount);\n\n // update state\n\n _weiRaised = _weiRaised.add(weiAmount);\n\n _processPurchase(beneficiary, tokens);\n\n emit TokensPurchased(_msgSender(), beneficiary, weiAmount, tokens);\n\n _updatePurchasingState(beneficiary, weiAmount);\n\n _forwardFunds();\n\n _postValidatePurchase(beneficiary, weiAmount);\n\n }\n\n /**\n\n * @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met.\n\n * Use `super` in contracts that inherit from Crowdsale to extend their validations.\n\n * Example from CappedCrowdsale.sol's _preValidatePurchase method:\n\n * super._preValidatePurchase(beneficiary, weiAmount);\n\n * require(weiRaised().add(weiAmount) <= cap);\n\n * @param beneficiary Address performing the token purchase\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _preValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n\n require(beneficiary != address(0), \"Crowdsale: beneficiary is the zero address\");\n\n require(weiAmount != 0, \"Crowdsale: weiAmount is 0\");\n\n this; // silence state mutability warning without generating bytecode - see https://github.com/ethereum/solidity/issues/2691\n\n }\n\n /**\n\n * @dev Validation of an executed purchase. Observe state and use revert statements to undo rollback when valid\n\n * conditions are not met.\n\n * @param beneficiary Address performing the token purchase\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _postValidatePurchase(address beneficiary, uint256 weiAmount) internal view {\n\n // solhint-disable-previous-line no-empty-blocks\n\n }\n\n /**\n\n * @dev Source of tokens. Override this method to modify the way in which the crowdsale ultimately gets and sends\n\n * its tokens.\n\n * @param beneficiary Address performing the token purchase\n\n * @param tokenAmount Number of tokens to be emitted\n\n */\n\n function _deliverTokens(address beneficiary, uint256 tokenAmount) internal {\n\n _token.safeTransfer(beneficiary, tokenAmount);\n\n }\n\n /**\n\n * @dev Executed when a purchase has been validated and is ready to be executed. Doesn't necessarily emit/send\n\n * tokens.\n\n * @param beneficiary Address receiving the tokens\n\n * @param tokenAmount Number of tokens to be purchased\n\n */\n\n function _processPurchase(address beneficiary, uint256 tokenAmount) internal {\n\n _deliverTokens(beneficiary, tokenAmount);\n\n }\n\n /**\n\n * @dev Override for extensions that require an internal state to check for validity (current user contributions,\n\n * etc.)\n\n * @param beneficiary Address receiving the tokens\n\n * @param weiAmount Value in wei involved in the purchase\n\n */\n\n function _updatePurchasingState(address beneficiary, uint256 weiAmount) internal {\n\n // solhint-disable-previous-line no-empty-blocks\n\n }\n\n /**\n\n * @dev Override to extend the way in which ether is converted to tokens.\n\n * @param weiAmount Value in wei to be converted into tokens\n\n * @return Number of tokens that can be purchased with the specified _weiAmount\n\n */\n\n function _getTokenAmount(uint256 weiAmount) internal view returns (uint256) {\n\n return weiAmount.div(_price);\n\n }\n\n /**\n\n * @dev Determines how ETH is stored/forwarded on purchases.\n\n */\n\n function _forwardFunds() internal {\n\n _wallet.transfer(msg.value);\n\n }\n\n}\n\ncontract AnnaCrowdsale is Crowdsale {\n\n constructor(\n\n uint256 rate,\n\n address payable wallet,\n\n IERC20 token\n\n ) public Crowdsale(rate, wallet, token) {}\n\n}\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by abcoathup on Dec 15, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @ashishk74,\nI assume that your crowdsale doesn't have enough/any tokens.\n\n_From: https://docs.openzeppelin.com/contracts/2.x/crowdsales#token-emission_\nIn the default scenario, your crowdsale must own the tokens that are sold. You can send the crowdsale tokens through a variety of methods\n\nI suggest having a look at: Simple ERC20 Crowdsale.\n\n 19 days later\n\n post by abcoathup on Jan 3, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @ashishk74,\nI wanted to check that you were able to resolve by transferring tokens to the crowdsale?\n\n post by ashishk74 on Jan 3, 2021\n\n ashishk74\n\n Yes, thanks. Your help was surely useful.\nRegards\nAshish\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n 95 / 5000 Resultados de traducción my crowdsale receives the payment in ether in my wallet but does not send my ERC20 token to whoever buys\n\n Support\n\n erc20\n\n 1\n\n 615\n\n Feb 2022\n\n Satisfies all conditions set by Solidity `require` statements. does not trigger a Solidity `revert` statement. SafeERC20: low-level call failed\n\n Smart Contracts\n\n crowdsale\n\n 0\n\n 1.2k\n\n Mar 2022\n\n Revert SafeERC20: low-level call failed when trying to run buyTokens function in a Crowdsale\n\n Contracts\n\n 5\n\n 4.7k\n\n Dec 2020\n\n Crowdsale buyTokens fails with error ‘SafeERC20: low-level call failed’\n\n Contracts\n\n 2\n\n 2.5k\n\n Mar 2021\n\n Contract Crowdsale SafeMath: subtraction overflow”, “data” error\n\n Support\n\n 1\n\n 4.2k\n\n May 2021","tokens":4744,"squid":"ink-security_audits","role":"Sentinel","at":1791265053221,"hash":"f47130d2015d74a6ff770fdf1a9d7a9057aff80a"}
{"url":"https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298/117","domain":"ethresear.ch","title":"Plasma Cash: Plasma with much less per-user data checking - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 27\n\n 15\n\n 15\n\n 12\n\n 6\n\n read \n\n 36\n min\n\n Mar 2018\n\n 116 / 116\n\n Jan 2019\n\n Jan 2019\n\n Load more posts above\n\n post by kladkogex on Jun 8, 2018\n\n kladkogex\n\n ldct\n\n I think this system needs to be modified so that the user explicitly burns the coin before exiting it and provides proof of burn\nThe current mechanism seems to be incredibly computationally consuming. How can I use a system where for each 1c coin I got, I need to check a linearly increasing set of Merkle proofs. If I am paid a $0.01 coin and then I have to first to dowload megabytes of Merkle proofs and then keep on monitoring it forever, how viable is this solution?\nIf I have $10 as 1000 coins 1c each, the amount of dowload, storage, verification and monitoring I need to do seems overwhelmingly huge and growing linearly with time.\nExplicit burn proof solves all these issues, you simply do not need to store anything\n\n post by ldct on Jun 8, 2018\n\n ldct\n\n The linearly increasing set of proofs for 1 coin is indeed a downside. Note that there are some mitigations like Plasma XT: Plasma Cash with much less per-user data checking.\nIf you have a design that modifies plasma cash with “proof of burn” that solves this problem, feel free to create a separate post (I feel like this one is getting long) and I can look at it\n\n post by kladkogex on Jun 9, 2018\n\n kladkogex\n\n Xuanji - I will, thank you\n\n post by ldct on Jun 16, 2018\n\n ldct\n\nAn alternative way to accomplish this might be for the operator to construct a merkle tree T𝑇 committing to the number of times every coinid has been spent since the genesis plasma block, and to use snarks to verify the integrity of the root hash of the tree. Then a client checking the validity of a coin can download the witness for the branch of this tree that tells him that his coin has been spent hℎ times, and then download hℎ inclusion proofs.\nFor clarity, an example of this is shown below for 2-bit coinids. The top row shows the transactions in each block, and the bottom shows T𝑇 after those transactions have been applied.\nimg_20180611_2259443258×2443 1.65 MB\nThis has the advantage that the prover only needs to construct one proof per plasma block (I’m not sure what the prover burden is for the scheme where a snark is constructed for each coin).\nWe can also place the verification on-chain, for instance both the transaction root and T𝑇 would be placed on-chain for every plasma block, and the plasma contract verifies a proof that T𝑇 was correctly computed. @JustinDrake points out that this is a case where we can use cryptoeconomic verification, i.e., the operator just places the proof on-chain and makes a bonded claim that the proof will verify, and anyone can collect the bond by paying the gas cost to refute the validator.\nAlso, we can include T𝑇 once every n𝑛 blocks, and just force clients to download the (at most n𝑛) exclusion proofs for the blocks that were included after the last time T𝑇 was included.\n\n Plasma Cash verification cost\n\n 17 days later\n\n post by AlexXiong97 on Jul 4, 2018\n\n AlexXiong97\n\nThis is very interesting. Is it possible to put this “# of time spent” into the UTXO itself (avoid having a separate tree and increase the block header size)? Meaning the output of the signed tx now is an object.\n[blknum1, txindex1, oindex1, sig1, # Input 1\n blknum2, txindex2, oindex2, sig2, # Input 2\n newowner1, denom1, #spent1 +1 # Output 1\n newowner2, denom2, #spent2 +1 # Output 2\n fee]\n\n post by ldct on Jul 4, 2018\n\n ldct\n\n Ah yes, that might be better. Then the snark can prove that # of times spent is nondecreasing.\nPlasma cash doesn’t have the two inputs and two outputs scheme you pasted, though.\n\n post by AlexXiong97 on Jul 4, 2018\n\n AlexXiong97\n\nTrue, but still, I think it’s possible to have leaves in Plasma Tx Tree as an object with affiliated fields . I haven’t thought it through, but possibly we could put a { historical owners => # tx } object for each output. And a possibility from this is when this coin is being exited, root chain will charge historical owners for the number of tx being done on this coin. So that you could imagine over time, as more coin being exited, the tx will be eventually paid out. (assuming constant tx fee for each tx.)\n\n post by shamatar on Jul 5, 2018\n\n shamatar\n\n @danrobinson\nHello Dan.\nAfter the last Plasma call I really liked your idea of “Plasma Debit” with quasi-channels user <-> owner. I work on the More Viable Plasma in parallel, but do you want to join some forces to make a “debit” prototype? The most interesting problem I see there right now is how to supply initial “empty” coins, so a user can get one and be able to accept the payment. One option is just deposit a full one and “split” it to “completely full” and “completely empty”, but I’d like to about splitting operation entirely and leave only transactions of A <-> operator <-> B type.\nSincerely, Alex\n\n post by julianrmartinez on Jul 9, 2018\n\n julianrmartinez\n\n Hello everyone. I want to get a better understanding of the proof used in Plasma. I have a very basic understanding of cryptographic proofs at the moment.\nDo any of you know of good resources that can help me catch up to the cryptographic proof conversation?\nThank you.\n\n post by kfichter on Jul 12, 2018\n\n kfichter\n\nWhat proof are you referring to?\n\n 1 month later\n\n post by EeroHeikkinen on Aug 16, 2018\n\n EeroHeikkinen\n\n Do I understand this correctly: if Bob transfers his coin to someone else and then attempts to fraudulently exit to the root chain, anyone including the operator can challenge the exit and claim the bounty (assuming transaction data is available normally from the operator).\nIn the implementations I could find, only information similar to this seemed to be required to challenge an already spent exit, all of which I understand should normally be publicly available to all observers:\n function challengeSpent(uint coin_id, uint blk_num, bytes tx1, bytes proof)\n\nSo as long as there is at least a single honest observer, users do not realistically have to check the root chain every week since the bounties incentivize third parties to do this monitoring. This would seem like a much more friendly situation for end-users, especially if they have only sporadic access to internet for example. Would this seem correct or am I totally on the wrong track here? \n\n post by gakonst on Aug 16, 2018\n\n gakonst\n\n Indeed, challenges can be done by any incentivized party that has access to the information required to make the challenges happen.\nHowever, delegating challenges (and/or exits) is not trustless - currently. Essentially, if you give a 0.1 ETH bounty to someone for challenging all exits for your 5 ETH coin, that someone can be bribed by any faulty exitor to not challenge for any amount bigger than the bounty, say 0.2 ETH.\nWork on trustless delegated challenges has been done on the state/payment channels end in this paper which may interest you by @stonecoldpat et al in https://eprint.iacr.org/2018/582.pdf\n\n post by EeroHeikkinen on Aug 17, 2018\n\n EeroHeikkinen\n\n Interesting. If I got this straight, in the case the attacker tries to exit a coin worth 10 ETH, there is a bounty of 0.1 ETH and 100 observers are watching the chain, to bribe all observers it would then cost > 10 ETH.\nSo if the bounty is bigger than the value of the coin attacked / N of observers, either observers will not gain anything by accepting the bribe or the attacker will spend more on the bribes than what he stands to gain from the attack.\nThank you for the paper reference also! \n\n post by danrobinson on Aug 17, 2018\n\n danrobinson\n\nA perspective change that I think is important for Plasma Cash is to abandon the idea that Plasma chain data is public by default. There should probably be nobody other than the operator who is observing the entire chain.\nYou might voluntarily provide some third party with your coin history every time you spend a coin, so that they can challenge attempted outdated withdrawals. But the operator shouldn’t just make your coin history public unless you told them to.\n(I’ll also note that this only covers outdated-coin exits, as you mentioned. The possibility of a malicious operator means that you need to be online once a week anyway, since you might be the only one who knows that an attempted exit was actually a malicious attack by the operator.)\n\n post by AndrewJack1 on Aug 20, 2018\n\n AndrewJack1\n\n If the chain data should not be public henceforth, wouldn’t that massively alter the promised future in the original white paper? That we can have more than one operator, they all agree on a state (optionally with MapReduce delegation to child chains) and the resulted blocks are published on Ethereum to obtain its security? Or is it just Plasma Cash which makes these trade-offs in order to achieve fast and reliable coin transfers?\n\n 2 months later\n\n post by gakonst on Oct 17, 2018\n\n gakonst\n\n This is my attempt at making a comprehensive document about Plasma Cash, feedback much appreciated!\nAbstract:\nPlasma is a framework for scalable off-chain computation. We describe and evaluate Plasma Cash, an improved Plasma construction which leverages non-fungible tokens and Sparse Merkle Trees to reduce the data storage and bandwith requirements for users. We analyze the cryptoeconomic exit and challenge mechanisms used to keep user funds secured, even when the Plasma Cash chain’s consensus algorithm is compromised. A reference implementation is provided for evaluation. Finally, we briefly discuss further improvements that can be made to the Plasma Cash protocol such as arbitrary denomination\npayments, less user data checking, fast and optimistic exits.\n\n post by mkchung on Oct 19, 2018\n\n mkchung\n\n Wolk just released a code-complete implementation of plasma-cash/debit, along with a new Anchor Transaction type that supports Layer 3 chain’s provenance on Layer 1.\nhttps://github.com/wolkdb/go-plasma\nWe encourage everyone to clone it and Build something awesome with Plasma!\n\n post by syuhei176 on Oct 20, 2018\n\n syuhei176\n\n Is it possible? Please correct me if I’m wrong.\nI think users can skip the amount of history data of their coins if they want to, by adding new lock transaction type to Plasma Cash. The transaction is like “this coin cannot be sent until Nth PlasmaBlock”. In this case, I think user need not to send and store history between the block include lock tx and Nth block.\nAnd we have to modify challengeExit and respondChallenge in the RootChain contract and ensure that the challenger and exitor can’t use invalid transactions.\nexample)\ntx1: Alice lock her coinA until 150th Plasma Block. This tx1 is in 100th Plasma Block.\nOff course Alice sign this tx1. She can’t send coin A to anyone between 100th and 150th PlasmaBlock.\nIn case of that Alice send coin A to Bob before 150th PlasmaBlock as tx2\n\nBob should not receive coin A by client history verification.\n\nBob can know that tx2 is invalid by history verification\nIf there is a transaction between the block which has the tx1 and 150th block. The transaction is invalid.\n\nIf Bob receives coin A, Bob can exit? > no\n\nInvalid sent would be challenged, by “invalid history challenge”\n\nLast valid tx is tx1 and tx1 is lock transaction.\nIf the child of tx1 is in before 150th block, child tx is invalid. so exitor can’t respond with the valid child of tx1.\n\nAlice can exit with tx1? > yes\n\nBob can’t challenge by tx2. We modify challengeExit like this.\n\nif exiting tx is lock transaction, and the challenge transaction doesn’t meet condition(lock until Nth block). challenger can’t use the transaction as spent tx.\n\nIn case of that Alice send coin A to Bob after 150th PlasmaBlock as tx2\n\nBob receive coin history that has no history set between 100th and 150th. And the coin should not be included within this span.\ntx2 or after valid tx is exit-able? > yes\n\nIf there is the tx in 100th and 150th, it seems like double spent in original Plasma Cash spec. (notice this tx is tx3)\n\ntx3 is valid tx in the original spec\n\nChallenger will send tx3 and tx1(parent of tx3) by challengeExit\n\nbut tx3 is invalid(tx1 is lock tx until N and tx3 is in before N)\nthe challenge will be failed\n\n 3 months later\n\n post by gakonst on Jan 13, 2019\n\n gakonst\n\n I’ve been thinking that the Sparse Merkle Tree used for membership and non-membership proofs can be probably replaced by Vector Commitments which can be aggregated and batched, as described in https://eprint.iacr.org/2018/1188.pdf.\nIs anyone working on this, and/or a onchain Vector Commitment verifier?\n\n post by DZack on Jan 19, 2019\n\n DZack\n\n kfichter\n\n What ultimately happened with the “merge/split” mechanism you’re referring to here? I.e., is there are a more detailed write-up somewhere / did it get ultimately get “split/merged” into some new variant, etc.?\n\n Powered by Discourse","tokens":3220,"squid":"ink-research","role":"Deep Scholar","at":1791265056444,"hash":"33178b1fc57c696ed4b94982ec8ca2c9e7b13c6b"}
{"url":"https://docs.optimism.io/app-developers/quickstarts/get-started","domain":"docs.optimism.io","title":"Optimism Documentation","text":"OP Stack chains are EVM equivalent: everything you know from Ethereum works here, and everything you build here works across the OP Stack ecosystem.\nThis quickstart takes you from zero to a deployed contract on the OP Sepolia testnet, using only free testnet funds.\nNo real funds are needed at any point — everything below runs on testnets.\n​Before you start\nYou’ll need:\n\nA wallet you control (any EVM wallet works; you’ll export or generate a private key for testnet use only).\nA terminal with curl available.\n\nUse a fresh, testnet-only private key for tutorials. Never paste a key that holds real funds into a terminal.\n1Get testnet ETHGrab free OP Sepolia ETH from the Superchain Faucet.\nOther options are listed on the testnet faucets page.2Connect to OP SepoliaOP Sepolia’s public RPC endpoint is https://sepolia.optimism.io and its chain ID is 11155420.\nVerify you can reach it:curl -s -X POST -H \"Content-Type: application/json\" \\\n --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_chainId\",\"params\":[],\"id\":1}' \\\n https://sepolia.optimism.io\nExpected result: {\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0xaa37dc\"} (0xaa37dc = 11155420).\nFor other networks and production-grade endpoints, see network information and RPC providers.3Deploy your first contractFollow the Deploy a contract to OP Sepolia tutorial.\nIt walks you through installing Foundry, deploying a small Greeter contract, and reading and writing to it from the command line — the same workflow you’d use on Ethereum.4Bridge ETH between L1 and L2 (optional)Apps often need to move assets between Ethereum and an OP Stack chain.\nStart with Bridging basics to understand the model, then follow the Bridging ETH with Viem tutorial to do a Sepolia → OP Sepolia deposit programmatically.\n​Where to go next\n\nRunning your app in productionA production application depends on infrastructure your team does not run: RPC endpoints that hold up under real traffic (the public endpoints are rate-limited and not built for production), bridges your users rely on, and a chain whose operator keeps sequencing, upgrades, and incident response going around the clock. These docs cover building and testing. If your application is growing toward dedicated blockspace of its own, OP Enterprise offers managed and supported paths to running a chain. These docs stay the reference for what you build either way. OP Enterprise is Optimism’s managed offering.\n​Need help?\n\nAsk a question or report documentation issues on the Optimism monorepo issue tracker.\nWas this page helpful?","tokens":628,"squid":"ink-governance","role":"Council Listener","at":1791265065282,"hash":"647f4a60dd9720d683fd8995196fb663062ecb44"}
{"url":"https://forum.openzeppelin.com/t/simple-erc20-crowdsale/4863","domain":"forum.openzeppelin.com","title":"Simple ERC20 Crowdsale - Smart Contracts / Guides and Tutorials - OpenZeppelin Forum","text":"Simple ERC20 Crowdsale \n\n Smart ContractsGuides and Tutorials\n\n erc20,crowdsale,example\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2020\n\n 1 / 6\n\n Dec 2020\n\n Jul 2022\n\n post by abcoathup on Mar 15, 2021\n\n abcoathup\n\n Great contributor\n\n The following is an example of a simple ERC20 Crowdsale.\n The following code has not been tested nor audited.\nSeek appropriate advice on regulatory compliance and your solution should have appropriate testing and auditing\nRecommend reading: Points to consider when creating a fungible token (ERC20, ERC777)\nSetup\n Crowdsales are included in OpenZeppelin Contracts 2.x, they are not in OpenZeppelin Contracts 3.x.\nTo install:\nnpm install @openzeppelin/contracts@2.5.1\n\nDocumentation: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nDocumentation on why Crowdsales are not included in OpenZeppelin Contracts 3.x: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nSimpleToken.sol\n// contracts/SimpleToken.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.5.5;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\n\n/**\n * @title SimpleToken\n * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.\n * Note they can later distribute these tokens as they wish using `transfer` and other\n * `ERC20` functions.\n */\ncontract SimpleToken is Context, ERC20, ERC20Detailed {\n /**\n * @dev Constructor that gives _msgSender() all of existing tokens.\n */\n constructor(\n string memory name,\n string memory symbol,\n uint256 initialSupply\n ) public ERC20Detailed(name, symbol, 18) {\n _mint(_msgSender(), initialSupply);\n }\n}\n\nSimpleCrowdsale.sol\n// contracts/SimpleCrowdsale.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.5.5;\n\nimport \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\n/**\n * @title SimpleCrowdsale\n * @dev This is an example of a fully fledged crowdsale.\n */\ncontract SimpleCrowdsale is Crowdsale {\n constructor(\n uint256 rate,\n address payable wallet,\n IERC20 token\n ) public Crowdsale(rate, wallet, token) {}\n}\n\n2_deploy.js\nMigrations script that deploys the token and crowdsale, then transfers the total supply of tokens to the crowdsale.\n\n_From: https://docs.openzeppelin.com/contracts/2.x/crowdsales#token-emission_\nIn the default scenario, your crowdsale must own the tokens that are sold.\n\n// migrations/2_deploy.js\n// SPDX-License-Identifier: MIT\nconst SimpleToken = artifacts.require(\"SimpleToken\");\nconst SimpleCrowdsale = artifacts.require(\"SimpleCrowdsale\");\n\nmodule.exports = async function (deployer, network, accounts) {\n await deployer.deploy(SimpleToken, 'Simple Token', 'SIM', '10000000000000000000000');\n const token = await SimpleToken.deployed();\n\n await deployer.deploy(SimpleCrowdsale, 1, accounts[0], token.address);\n const crowdsale = await SimpleCrowdsale.deployed();\n\n token.transfer(crowdsale.address, await token.totalSupply())\n};\n\nTruffle develop\nInteract with the crowdsale using the Truffle console\n$ npx truffle develop\nTruffle Develop started at http://127.0.0.1:9545/\n...\ntruffle(develop)> migrate\n\nCompiling your contracts...\n===========================\n...\nStarting migrations...\n======================\n> Network name: 'develop'\n> Network id: 5777\n> Block gas limit: 6721975 (0x6691b7)\n\n1_initial_migration.js\n...\n2_deploy.js\n===========\n\n Deploying 'SimpleToken'\n...\n Deploying 'SimpleCrowdsale'\n...\ntruffle(develop)> token = await SimpleToken.deployed()\nundefined\ntruffle(develop)> crowdsale = await SimpleCrowdsale.deployed()\nundefined\ntruffle(develop)> (await token.balanceOf(crowdsale.address)).toString()\n'10000000000000000000000'\ntruffle(develop)> (await token.totalSupply()).toString()\n'10000000000000000000000'\ntruffle(develop)> await crowdsale.buyTokens(accounts[1], {value: web3.utils.toWei('1')})\n{ tx:\n...\ntruffle(develop)> (await token.balanceOf(accounts[1])).toString()\n'1000000000000000000'\ntruffle(develop)> (await token.balanceOf(crowdsale.address)).toString()\n'9999000000000000000000'\n\nTesting\nBased on: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/test/examples/SampleCrowdsale.test.js\nSimpleToken.test.js\n// test/SimpleToken.test.js\n// SPDX-License-Identifier: MIT\n\n// Based on https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.5.1/test/examples/SimpleToken.test.js\n\nconst { expect } = require('chai');\n\n// Import utilities from Test Helpers\nconst { BN, expectEvent, expectRevert, constants } = require('@openzeppelin/test-helpers');\n\n// Load compiled artifacts\nconst SimpleToken = artifacts.require('SimpleToken');\n\n// Start test block\ncontract('SimpleToken', function ([ creator, other ]) {\n\n const NAME = 'SimpleToken';\n const SYMBOL = 'SIM';\n const TOTAL_SUPPLY = new BN('10000000000000000000000');\n\n beforeEach(async function () {\n this.token = await SimpleToken.new(NAME, SYMBOL, TOTAL_SUPPLY, { from: creator });\n });\n\n it('has a total supply', async function () {\n // Use large integer comparisons\n expect(await this.token.totalSupply()).to.be.bignumber.equal(TOTAL_SUPPLY);\n });\n\n it('has a name', async function () {\n expect(await this.token.name()).to.be.equal(NAME);\n });\n\n it('has a symbol', async function () {\n expect(await this.token.symbol()).to.be.equal(SYMBOL);\n });\n\n it('assigns the initial total supply to the creator', async function () {\n expect(await this.token.balanceOf(creator)).to.be.bignumber.equal(TOTAL_SUPPLY);\n });\n});\n\nSimpleCrowdsale.test.js\n// test/SimpleCrowdsale.test.js\n// SPDX-License-Identifier: MIT\n\n// Based on https://github.com/OpenZeppelin/openzeppelin-solidity/blob/v2.5.1/test/examples/SimpleToken.test.js\n\nconst { expect } = require('chai');\n\n// Import utilities from Test Helpers\nconst { BN, ether, expectEvent, expectRevert, constants } = require('@openzeppelin/test-helpers');\n\n// Load compiled artifacts\nconst SimpleToken = artifacts.require('SimpleToken');\nconst SimpleCrowdsale = artifacts.require('SimpleCrowdsale');\n\n// Start test block\ncontract('SimpleCrowdsale', function ([ creator, investor, wallet ]) {\n\n const NAME = 'SimpleToken';\n const SYMBOL = 'SIM';\n const TOTAL_SUPPLY = new BN('10000000000000000000000');\n const RATE = new BN(10);\n\n beforeEach(async function () {\n this.token = await SimpleToken.new(NAME, SYMBOL, TOTAL_SUPPLY, { from: creator });\n this.crowdsale = await SimpleCrowdsale.new(RATE, wallet, this.token.address);\n this.token.transfer(this.crowdsale.address, await this.token.totalSupply());\n });\n\n it('should create crowdsale with correct parameters', async function () {\n expect(await this.crowdsale.rate()).to.be.bignumber.equal(RATE);\n expect(await this.crowdsale.wallet()).to.be.equal(wallet);\n expect(await this.crowdsale.token()).to.be.equal(this.token.address);\n });\n\n it('should accept payments', async function () {\n const investmentAmount = ether('1');\n const expectedTokenAmount = RATE.mul(investmentAmount);\n\n await this.crowdsale.buyTokens(investor, { value: investmentAmount, from: investor });\n\n expect(await this.token.balanceOf(investor)).to.be.bignumber.equal(expectedTokenAmount);\n });\n});\n\nRun Tests\n$ npx truffle test\nUsing network 'test'.\n\nCompiling your contracts...\n===========================\n> Everything is up to date, there is nothing to compile.\n\n Contract: SimpleCrowdsale\n ✓ should create crowdsale with correct parameters (206ms)\n ✓ should accept payments (154ms)\n\n Contract: SimpleToken\n ✓ has a total supply\n ✓ has a name (44ms)\n ✓ has a symbol (52ms)\n ✓ assigns the initial total supply to the creator\n\n 6 passing (2s)\n\n Create token sale 1:1 ETH for token\n\n Simple ERC20 token example\n\n How ERC20 approve function works?\n\n Simple tests for Crowdsale contract?\n\n ERC20 Token - is it possible to transfer part of tokens to a smart contract?\n\n 8 days later\n\n Split this topic on Dec 9, 2020\n\n 3 posts were split to a new topic: Use other addresses in tests\n\n 1 month later\n\n Split this topic on Jan 21, 2021\n\n A post was split to a new topic: Import OpenZeppelin contracts when inherited contract uses a higher compiler version?\n\n 2 months later\n\n Split this topic on Mar 15, 2021\n\n 2 posts were split to a new topic: Where are crowdsales?\n\n 1 year later\n\n post by RicciH8 on May 17, 2022\n\n RicciH8\n\n Hello @abcoathup or anyone who can help,\nI've been trying to edit your 2_deploy.js to allow me to run a crowdsale on a previously created token. I stripped out the SimpleToken and tried to hardcode the existing contract address in. Something like so:\nconst CROWDSALE2 = artifacts.require(\"CROWDSALE2\");\n\nmodule.exports = async function (deployer, network, accounts) {\n\n const token = 'TOKEN_CONTRACT_ADDRESS';\n\n await deployer.deploy(CROWDSALE2, 1, accounts[0], token.address);\n const crowdsale = await CROWDSALE2.deployed();\n\n token.transfer(crowdsale.address, await token.totalSupply())\n};\n\nIs this even possible to create a crowdsale on a previously deployed token?\nThe error I get when deploying is:\n *** Deployment Failed ***\n\n\"CROWDSALE2\" -- invalid address (argument=\"address\", value=undefined, code=INVALID_ARGUMENT, version=address/5.0.5) (argument=\"token\", value=undefined, code=INVALID_ARGUMENT, version=abi/5.0.7).\n\nHelp would be much appreciated.\nBest regards,\n\n 2 months later\n\n post by sven.meyer on Jul 18, 2022\n\n sven.meyer\n\n I just stumbled again over this crowdsale contract and wondering again why it was abandoned in v3.\n\" All crowdsale-related contracts were removed from the OpenZeppelin Contracts library on the v3.0.0 release due to both a decline in their usage and the complexity associated with migrating them to Solidity v0.6.\"\nIf OZ finds it too complex to migrate it to solc v0.6, should I touch and try that ?\nAny information what would have been so \"complex\" ?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Help me write an erc20 token and a crowdsale contract\n\n Contracts\n\n erc20\n\n 9\n\n 8.0k\n\n Dec 2020\n\n Simple ERC20 Crowdsale contract\n\n Contracts\n\n 5\n\n 2.3k\n\n Nov 2020\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 742\n\n Feb 2022\n\n Simple tests for Crowdsale contract?\n\n Contracts\n\n 4\n\n 2.5k\n\n Dec 2020\n\n Simple ERC20 token example\n\n Guides and Tutorials\n\n 7\n\n 24.9k\n\n Sep 2022","tokens":2554,"squid":"ink-security_audits","role":"Sentinel","at":1791265074225,"hash":"e3eb362d41874e6a98c3705e21c2dc2f55c764a2"}
{"url":"https://docs.optimism.io/governance/protocol-upgrades","domain":"docs.optimism.io","title":"Optimism Documentation","text":"​How does the OP Stack stay up to date with the latest innovation?\nThe OP Stack is Optimism’s open-source software for deploying next-generation onchain products. The software is licensed under the MIT license, meaning it can be freely used and forked by all parties. The OP Stack has a vibrant core developer community who contribute to the stack, ensuring it reflects the features and values protocol users care about.\nThe Superchain is an ecosystem of chains running on Optimism’s OP Stack, featuring some of the world’s largest enterprises. Superchain networks benefit from shared security, upgrades and services provided by Optimism. Each chain maintains peak performance with access to innovative new features developed anywhere on the stack, continually strengthening the entire Superchain ecosystem. Chains may also configure components of the OP Stack to fit their regulatory and business needs while still benefiting from shared infrastructure and innovation. Learn more about the best way to build on the OP Stack for your business here.\n​How are new features added to the OP Stack?\nOP Labs and external contributors determine the feature roadmap. Based on discussions, protocol upgrades are drafted, which go through the protocol upgrade process.\n​What is the protocol upgrade process?\nThe protocol upgrade process is designed to make sure the OP Stack does not change against the interests of the businesses building on the platform. This is a key benefit of crypto systems compared to their centralized alternatives. Platform risk is a common risk of Web 2 platforms and is a key consideration for the largest partners building on the OP Stack.\n\nProtocol upgrades are drafted by OP Labs or other core contributors to the OP Stack. Before they are implemented, they are reviewed by an independent group of developers (the Developer Advisory Board) to ensure the upgrade is well justified.\nAfter a proposal has been reviewed by the Developer Advisory Board, it enters a 7 day veto period. This allows all impacted stakeholders, namely tokenholders, chains, apps, and end-users to override the DAB’s decision if they believe an upgrade disadvantages their interests. This is how platform risk is reduced for key stakeholders of the OP Stack.\nIf a proposal is veto’d, it enters an appeals and discussion phase and can be resubmitted.\nFor full details about the protocol upgrade process, please see the Operating Manual.\nOverall - contributors, tokenholders, chains, apps, and end-users all have a voice. Checks and balances exist so that no single entity (including OP Labs or the Foundation) can unilaterally dictate the future of the OP Stack.\nPlatform risk is reduced by distributing veto power across stakeholder groups while maintaining an efficient core developer process. This ensures upgrades happen quickly but can be vetoed if they harm key stakeholders.\n​How can my chain specifically influence the feature roadmap?\nSuperchain members who contribute revenue back to the Collective are consulted by OP Labs and core developers about the feature roadmap to ensure their voices are heard. All development happens in the open and chains are encouraged to participate and share their perspectives within various research and development repositories.\n​How does Optimism help my chain achieve decentralization?\nPermissionless Fault Proof OP Chains that have their upgrade keys managed by the Optimism Security Council are classified as Stage 1 in L2Beat’s framework. This distributed group delivers the benefit of security scrutinized upgrades that are managed by Optimism.Was this page helpful?","tokens":903,"squid":"ink-governance","role":"Council Listener","at":1791265075391,"hash":"86fe9f649b2ec290cec73331453a7f3ece221169"}
{"url":"https://ethresear.ch/t/cryptoeconomic-probabilistic-tumbler/1103","domain":"ethresear.ch","title":"Plasma with client-side validation - Layer 2 / Plasma - Ethereum Research","text":"Plasma with client-side validation \n\n Layer 2Plasma\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n read \n\n 8\n min\n\n Feb 2018\n\n 1 / 9\n\n Feb 2018\n\n Feb 2018\n\n post by danrobinson on Feb 16, 2018\n\n danrobinson\n\n [EDIT: later replies describe a simpler version of this idea without the Plasma elements]\n[EDIT 2: Plasma Cash by Vitalik and Karl Floersch improves significantly on these ideas in the Plasma context.]\nThis post describes an adaptation of Minimal Viable Plasma (MVP) by @vbuterin et al (and assumes familiarity with that post). The adaptation makes use of some of Peter Todd’s ideas around single-use seals and client-side validation. Almost none of the ideas below are original to me (although the mistakes probably are).\nThis approach makes some serious tradeoffs relative to the blockchain structure described in MVP, but it could be a useful configuration for some minority of Plasma chains, particularly for its unique probabilistic “tumbling” capability. Mostly, I wanted to introduce these ideas of Peter’s (which I think deserve wider attention and could have interesting applications in other contexts, such as stateless validation in sharding) to the community, and try to sketch out a design for a working system that would demonstrate them.\nAbstract\nLike Minimal Viable Plasma, client-side Plasma would use a UTXO-based blockchain operated by some owner or owners, whose block headers are committed to the Ethereum blockchain. The primary difference is in the structure of those blocks.\nInstead of transactions including their inputs and outputs in cleartext, they only include a commitment to the outputs, and signatures from the inputs’ public keys. It is the user’s responsibility, when sending a transaction, to also provide the recipient with a recursive proof that the inputs are valid (such as by revealing all hidden information about the full chain of previous transactions, back to the deposit transactions).\nThere is an optimization that can be used to prune part of these proofs. In addition to making these proofs more efficient, this allows you to permanently hide part of a transaction’s history, thus letting users “tumble” funds to obscure their source.\nBenefits\n\nPlasma transactions are even smaller\nPlasma blocks can be validated statelessly. This is particularly important because in Plasma, this is a responsibility of all parties maintaining UTXOs on the chain\nTransactions themselves reveal almost nothing about their sources, destinations, or amounts. Histories eventually need to be revealed, but can be probabilistically pruned before doing so, permanently hiding some history\n\nCosts\n\nExit transactions are larger (approximately O(N) in the average number of steps in the UTXO’s transaction history)\nWould-be challengers need to preserve O(N) storage, where N is the number of transaction inputs in the Plasma chain’s history\nTransacting parties need to maintain and exchange off-chain proofs of not-insignificant size (the exact size depends on the amount of state maintained by the receiving party)\nDishonest users may be able to “gamble” on the chain, with negative expected value but with some risk of hurting depositors or other users\n\nData structures and validity rules\nTransactions\nA transaction is a tuple: (destination, signatures)\nThe public keys—i.e., inputs—for the transaction can be derived from the signatures, with the destination as the message.\nA transaction is valid and can be included in a block if:\n\nthe signatures array is non-empty and valid public keys can be recovered from each of the signatures, or\nthe signatures array is empty, indicating a deposit transaction, it is the only transaction in that block, and there exists a corresponding deposit transaction in the parent chain\n\nA destination is the root of a Merkle sum tree of UTXOs (i.e., a Merkle tree where each intermediate node (and the root) also commits to the sum of the amounts of the UTXOs included in that branch).\nA UTXO is a (salted) commitment to a tuple: sha3(publicKey, amount, salt).\nBlocks\nA block header is a tuple: (height, previousBlockHash, transactionRoot, publicKeyRoot).\nA full block also includes a list of transactions. A block is valid if it contains only a single valid deposit transaction (see above), or if:\n\nThe transactions are all valid\nThe transactions are sorted in ascending order based on their derived public keys (for efficiency of computation of the publicKeyRoot)\nThe derived public keys used in the block are unique within that block\nThe transactionRoot is a Merkle root of the transactions\nThe publicKeyRoot is a Merkle root of the derived public keys in the transactions in the block, sorted in ascending order\n\nA proof of non-inclusion of a public key is a Merkle path to two adjacent public key, showing that there is no transaction spending from a particular public key in that block.\n(There are likely ways to make these proofs smaller using different kinds of trees that commit to the frontiers of public keys rather than the keys themselves, and/or adding probabilistic data structures like Bloom filters to the headers, but we’ll leave those for follow-up posts.)\nLight proof of validity\nA key distinction of this protocol from shared-validation protocols like Bitcoin and Ethereum (but which it shares with some proposals around separating consensus and state execution) is that the mere inclusion of a UTXO in the Plasma blockchain does not prove that the UTXO is valid. To spend a UTXO from the Plasma chain, you need to provide the recipient with an off-chain proof that the UTXO is valid as of the block in which it is spent. Similarly, to withdraw a UTXO from the Plasma chain, you need to prove to the Ethereum chain that the UTXO is valid as of the block in which it is withdrawn.\nA light proof of validity of a UTXO as of block b at height h is:\n\nA proof that the UTXO is included as part of a valid Merkle sum tree path from destination.\nA transaction that includes that destination.\nThe block height h′ of the block b′ in which transaction was included\nThe index of transaction in that block.\nIf transaction's publicKeys list is empty, indicating a deposit transaction, then the proof is complete. If not:\n\nA list of UTXOs, inputs, whose respective publicKeys match the publicKeys in transaction, and whose amounts sum to the total amount committed to by destination.\nA light proof of validity of each UTXO in inputs, as of block b′ at height h′.\n\nA light proof only contains the non-public information needed to validate a transaction. It does not demonstrate everything needed to determine that a UTXO is valid. Specifically, for a UTXO to be valid, the following must also be true:\n\ntransaction was included in the block at height h′ that is in the history of b, and\nthere is no transaction included in a block between blocks b′ and b that spends publicKey.\n\nFortunately, these facts can be verified based on public information, so if a verifier is running (or trusts somebody who is running) an “archival node” for the Plasma chain, they can verify these facts.\nFraud proofs\nAdditionally, if one of those facts is false, any archival node can detect it and construct a relatively efficient fraud proof to demonstrate that fact. This means that a light verifier can satisfy itself as to the validity of a light proof using an incentivized challenge-response protocol. This is how the parent chain verifies the validity of a UTXO for a withdrawal. During the withdrawal waiting period, any party can claim a portion of the withdrawer’s deposit by revealing a Merkle proof that either:\n\na different transaction was included at position index in the block at h′ in b's history (or no transaction at all was included at that position), or\nthere is a transaction spending publicKey in some block between b′ and b.\n\nIf the verifier has a list of all previous block hashes (as the Plasma contract on Ethereum does, for example), a fraud proof has size log(N), where N is the number of transactions or public keys, respectively, included in the block used in the fraud proof. If the verifier does not have such a list, the prover must also provide the chain of block headers from the block mentioned in the fraud proof to block b.\nFull proof of validity\nIn some cases, a verifier may not be running an archival node, and may not be able to take advantage of a challenge-response protocol. In that case, the prover has to provide some additional information.\nA full proof of validity of a UTXO is a light proof of its validity, plus:\n\nThe block header for b′, and a Merkle proof that transaction is included in its Merkle root.\nAll of the block headers between b′ and b.\nFor each of those block headers, a Merkle proof of non-inclusion of publicKey in the publicKeyRoot. Since the public keys in that tree are ordered, this can be done with a Merkle proof of adjacent public keys.\n\nProbabilistic proof of validity\nThis protocol gives us essentially the same functionality as minimum viable Plasma. It reduces transaction size, and makes block validation—i.e., the task that must be performed constantly by any participant on the Plasma network—efficient and memoryless.\nHowever, while it delays the public revelation of transaction histories, those histories must eventually be revealed when a UTXO is withdrawn. Once every UTXO in a Plasma chain is withdrawn, every transaction in its history will have been revealed. Additionally, since transactions can have multiple inputs, the size and verification time of validity proofs (even light proofs) will tend to blow up quasi-exponentially, as you must provide every thread of a UTXO’s history.\nHowever, there’s a trick that allows you to linearize this history, so the size of a light or full proof is only proportional to the length of the average history of the coins in that UTXO, rather than the total history. This will additionally allow us to permanently prune (and thus untraceably hide) a portion of each coin’s history.\nTo do so, we change the rule for validity of a UTXO, so that a UTXO is considered valid if one of its inputs, chosen randomly (and weighted by the amount of that input), is valid. For example, suppose a transaction has one output worth 4 ETH, and has two inputs, one of which is a valid source of 3 ETH and the other of which is a fraudulent source of 1 ETH. 75% of the time, the first one will be checked, and 25% of the time, the second one will be checked. The expected value of fraud will be \\frac{3}{4} \\cdot 4 + \\frac{1}{4} \\cdot 0 - 3 = 034 ⋅4 +14 ⋅0 −3 =0. Indeed, the expected value of fraud should always be 0, which means that the total supply of coins in the contract will not tend to inflate.\nTo strengthen this guarantee, and to discourage users from treating the Plasma chain as a casino, you would likely want to tweak the probabilities so that the expected value of fraud is somewhat less than 50%. For example, you could have a rule that 10% of the time, every input must be checked, which would mean that an attacker would expect to lose 10% of their capital with each attack.\nThe random choice of which coin is checked must be deterministic but uncontrollable and unpredictable by the transaction’s creator. (Finding a secure randomness beacon is a difficult problem, but one with several plausible solutions.) At some point after a transaction is included in the Plasma chain, this random number would be finalized, and the holders of a UTXO would be able to prune all but one of the proofs from its history (although it would need to replace it with a proof of the result of the random beacon).\nThis technique allows you to shorten both full and light proofs of UTXO validity. It also turns the Plasma chain into a sort of trustless probabilistic tumbler. Given a large enough supply of “clean” coins, you would eventually be able to make any coin untraceable.\nUnfortunately, this may still allow the attacker to grief the depositor and other coinholders on the Plasma chain. Computing the griefing factor is surprisingly difficult and depends on some surprising factors (happy to discuss more) but intuitively it seems like these attacks would tend to increase the contract’s overcapitalization—since the expected value for attackers is negative, so each successive griefing attack will be less and less likely to hurt the honest users of the Plasma chain.\n\n Plasma Cash: Plasma with much less per-user data checking\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n Cross Rollup payment channel with no online requirement for sender/recipient\n\n 5\n\n 4\n\n read \n\n 8\n min\n\n post by vbuterin on Feb 16, 2018\n\n vbuterin\n\n Thanks a lot for this, lots of cool ideas in here! That said, I’m not convinced that doing it this way doesn’t cancel out the source from where Plasma gets its efficiency gains in the first place. Plasma is a system that can handle M users each of which send N transactions with only 2M effort on the main chain, regardless of N, and to accomplish this it relies on exits having O(1) complexity. In this approach, each withdrawal transaction would need to contain a light proof of size N, so the total expense would be M * N, same as running all transactions on the main chain directly.\nI agree that the probabilistic tumbling approach makes the concrete efficiency better, though it introduces other complexities, like there always being some risk that the plasma chain turns into a fractional reserve (or must implement a haircut) out of sheer bad luck, and even with linear history size (ie. if there was only one denomination of coin) my M * N argument seems to suggest it won’t be an improvement over everything being on chain.\n\n post by danrobinson on Feb 17, 2018\n\n danrobinson\n\n Hmm, that point does seem rather damning. To be fair I think it only loses the bandwidth efficiency? The parent chain still does not need to check any previous signatures in the normal case, and it still could use only as much storage and as many storage ops on the parent chain as MVP.\nAlso technically it should depend on the rate of growth of the UTXO set—I think if it grows slower than the rate of net deposits onto the chain (i.e., there’s a lot of merging going on), it will be significantly lower bandwidth than just doing those transactions on chain (because most of the histories will be pruned), whereas if it grows faster than the rate of net deposits into the chain (i.e. there’s a lot of splitting), then your histories will tend to be redundant and the total bandwidth needed for everyone to exit will be greater than if you had just done the trades on the parent chain. There are reasons you might expect that the former situation will tend to obtain (people are trying to minimize their history sizes) but maybe not at all times, and at any rate the efficiency gain seems unlikely to be dramatic. And in the Plasma context this does seem to fail in the worst way possible—a total exodus from the child chain would involve all of this history (without whatever optimizations coinholders would prefer to do) rushing onto the parent chain at once.\nSo this may not be worth it as a scaling solution. But it seems like it still works as a privacy solution. I think the problems with fractional reserve can be solved—a depositor can massively overcapitalize it, and perhaps there’s some safe way to let the depositor share in the leftover winnings from gamblers losing the die roll (which I was assuming would need to get orphaned in the contract). If there’s a good way to make that piece (as well as the randomness beacon) work, then perhaps this could exist simply as a trustless probabilistic tumbler, that just happens to share some of its structure with Plasma.\n\n post by vbuterin on Feb 17, 2018\n\n vbuterin\n\n Agree that it only loses bandwidth efficiency; that said, you could also make a simpler bandwidth savings scheme, that I described as “shadow chains” a few years ago here: publish the block data to the chain, and only verify them on chain if someone complains within some time window. Thinking of it as a privacy scheme is interesting, though I imagine I could probably come up with some parametrization that shows that the privacy usecase of your scheme is basically a more complicated version of coinjoin.\nThat said, perhaps we should think much more seriously about cryptoeconomic tumblers, now that we’re clear that that’s the goal; with security deposits it could be possible to design one that’s quite powerful…\n\n post by danrobinson on Feb 17, 2018\n\n danrobinson\n\n Ah yes, ACK on shadow chains.\nI don’t think this reduces to CoinJoin? It’s non-interactive and asynchronous. The functionality is more like a ring signature mixer. But it clearly can be simplified, perhaps by just dropping the entire Plasma mechanism and storing everything on chain for now. (In which case I should change the post title and category…)\nThe contract would be initialized by a depositor, who would prefund it with some substantial amount. The contract would maintain a mapping of commitments (salted hashes of public keys) to balances (and commitment times).\nAnyone can call deposit at time T1, specify a new commitment, and pay in X ETH to add <commitment>: (X, T1) to the mapping.\nSome time later, someone can call initiateWithdrawal. They put down some deposit, specify a destination address, and specify a list of “inputs”. Each input includes a public key (which is purported to correspond to some committed public key in the mapping), an amount, and a signature from the public key on the rest of the data in the transaction (best way to do this to be determined). This is stored as a pending withdrawal (along with the time at which it was submitted, T2). The public keys used are added to a blacklist, meaning they can never be used in an input of a withdrawal again.\nAfter some time, a randomness beacon resolves, and one of those inputs is chosen to be audited, with the selection weighted by the amounts in each input. The withdrawer can then call completeWithdrawal and reveal the salt for that input, showing that that public key was committed to in the mapping before time T2, and that its amount was greater than or equal to the amount asserted. The commitment can then be removed from the balances mapping.\nIf the audited input was in fact fraudulent, the depositor will not be able to reveal a commitment in the balances mapping that matches it, and will lose their deposit along with any balances in other inputs that were valid.\nThe fees and withdrawal deposits can be tweaked to discourage fraud and make it worthwhile for the initial depositor to fund the backstop, without hurting the level of anonymization enjoyed by honest parties.\nThere are some pretty obvious ways to make this more efficient (and it’s already not too bad; it improves significantly on both the bandwidth and computation requirements of ring signature mixers, though it seems to have the same unfortunate storage requirements). But I’d be curious if there’s a way to improve the anonymization, maybe by combining it with some other mechanism. The properties this provides (unlinkability of outputs, except to one randomly selected one of the inputs) are a bit too quirky for practical use as a tumbler.\n\n post by vbuterin on Feb 17, 2018\n\n vbuterin\n\nYou’re right that it’s not fully the same thing. The analogy I was making is that both seem to be privacy-enhancing techniques that run on the principle of “we let multiple actors participate, have someone perform a shuffling and then let the participants withdraw, not publishing the connection between inputs and outputs if everyone agrees the shuffler acted fairly”; in coinjoin that’s clearly how it works, and in your plasma construction the shuffling is done implicitly as the chain operator honestly confirms Merkle roots of users’ transactions to each other.\nIn your committed deposit scheme, I’m not sure how the scheme knows that your commitments to the public keys that don’t get audited (but still need to be blacklisted if they’re incorrect) are valid; it seems like there’s an attack where you can specify other users’ public keys, fail the completeWithdrawal step, and thereby blacklist other people’s money.\nAnd ultimately, there’s still a trail from that can link outgoing money to at least one input of incoming money, so it doesn’t quite give full privacy preservation.\n\n post by danrobinson on Feb 17, 2018\n\n danrobinson\n\nThe signatures are always checked. You can’t specify other users’ public keys because you can’t forge their signatures. (Also because you don’t know them until the other party’s withdrawal transaction is published, but that obviously isn’t secure against front-running attacks.)\n\nYeah, like I said, a little too quirky.\n\n post by vbuterin on Feb 17, 2018\n\n vbuterin\n\nRight, but then doesn’t that mean that every withdrawal is linked to all of its corresponding deposits?\n\n post by danrobinson on Feb 17, 2018\n\n danrobinson\n\n Nope, because the balances mapping only includes salted commitments to the public keys. The linkage of an input’s public key to a commitment in the balances mapping is what gets checked (for a single input) during the audit. The unaudited public keys can’t ever be linked to any commitments in the balances mapping.\n\n Powered by Discourse","tokens":5322,"squid":"ink-research","role":"Deep Scholar","at":1791265079020,"hash":"94a25d958ce8bee99d01c7a90ec976a0de4e303c"}
{"url":"https://docs.optimism.io/governance/capital-allocation","domain":"docs.optimism.io","title":"Optimism Documentation","text":"​How does Optimism ensure long-term success?\nOptimism strives to create a sustainable ecosystem flywheel. In this flywheel, revenue contributed by OP Chains to the Optimism Collective funds open-source development and drives ecosystem growth, which strengthens the OP Stack and attracts more end-users, apps, integration partners, and chains.\nIn implementing this flywheel, Optimism uses a public decision making process designed to prevent short-term profit seeking at the expense of the platform, while ensuring organizations contributing the OP Stack remain accountable to tokenholders and customers. This process includes a capital allocation model, designed to avoid many of the common failure modes of corporate governance, aiming to ensure the product always remains at the cutting edge.\nFor more details, please see the Operating Manual.\n\n​How does Optimism generate revenue?\nOP Chains in the Superchain earn transaction fees whenever users send transactions onchain, including for payments, trading, identity, and other applications. Each chain also pays costs to publish its activity to Ethereum for security.\nOP Chains contribute a portion of their revenue to Optimism. This treasury is used to drive growth, provide shared infrastructure, and fund open source contributions that benefit the Superchain.\nSuperchain member chains contribute the greater of:\n\n15% of net transaction fee profit (transaction fees earned on L2 - costs paid to Ethereum L1), or\n2.5% of gross transaction fees\n\nOP Mainnet contributes 100% of its revenue to this shared treasury.\nYou can find more information about revenue in the Superchain Revenue Explainer documentation.\nThe wallets across L1 and OP Mainnet where this revenue sits, along with the Optimism Foundation treasury and grants wallet addresses, are listed under relevant addresses on the dashboards, trackers, and addresses page.\n​How is the treasury managed?\nThe treasury is currently stewarded by the Foundation, but is subject to oversight by key stakeholder groups, via Optimism’s public decision making process. Specifically, tokenholders, chains, apps, and users are asked to oversee annual budgets, which enable the Foundation to deploy the treasury into initiatives aimed at generated the sustainable flywheel described above.\nFoundation Budget Reports can be found here on the governance forum.\nThe OP Token Unlock (Estimated) tracker is listed under OP trackers on the dashboards, trackers, and addresses page.\nYou can find more information via the Operating Manual here.\n​What is Optimism’s commitment to Open Source Software?\nOptimism has always been committed to funding open-source software. OP Labs, a core contributor to the OP Stack, is registered as a public benefit corporation with a mission to enhance and enshrine access to public goods. The OP Stack is MIT licensed and Optimism dedicates a significant portion of its treasury to funding public goods and open-source software.\nOptimism operates various grant programs to incentivize and reward open-source contributions. Grant programs can be found via atlas.optimism.io.\n​What can I do with the OP Token?\nThe OP token was created in May of 2022, with an initial supply of 4,294,967,296 OP tokens. The token was launched as a governance token to enable tokenholders to weigh in on technical and economic decisions that impact Optimism, such as protocol upgrades and capital allocation. The Optimism Foundation estimates the total supply of circulating OP tokens to increase as detailed in the OP Token Unlock (Estimated) tracker.\nTokenholders can use OP to vote on:\n\nProtocol Upgrades\nToken Allocations\nAdjusting Inflation\nRemoving the Director of the Optimism Foundation\nDissolutions\nElections (and representative removal)\nProtecting the rights of tokenholders by consenting to any changes to the founding documents of the Optimism Foundation, if those changes would materially reduce their rights.\nRatification of Governing Documents\n\nYou can find full details of what Tokenholders can vote with the Operating Manual here. You can sign up to vote with your tokens here.Was this page helpful?","tokens":1029,"squid":"ink-governance","role":"Council Listener","at":1791265086835,"hash":"cb576db131df2fb5e2cc2eccfc64936589fe8342"}
{"url":"https://support.io.net/en/support/solutions/articles/156000101903-how-do-i-claim-block-rewards-earnings-","domain":"support.io.net","title":"How to Claim Your Block Rewards :","text":"How Do I Claim Block Rewards Earnings?\n\n Block Rewards are distributed on a monthly basis to recognize the contributions of network participants.1️⃣ You can claim the Block Rewards by connecting your wallet using the links below:https://app.streamflow.finance/https://iog.net/If you encounter any issues during the claiming process, please submit a ticket via the Support Portal for assistance.Worker Earnings through jobs cannot be withdrawn just yet, only Block Rewards. The ability to reliably and routinely withdraw worker earnings is in our development pipeline but has no ETA. The claiming window for each month’s Block Rewards will be announced in our announcement channel on Discord.We do not support Exchange Deposit Addresses (custodial wallets) for receiving Block Rewards. If your account in Account Settings is linked to an Exchange Deposit Address, you will be unable to claim Block rewards, participate in seasonal events, or receive worker earnings. To ensure uninterrupted access to these benefits, please update your wallet to a Self-Custodial Wallet as soon as possible.\n\n Was this article helpful?\n\n That’s Great!\n Thank you for your feedback\n\n Sorry! We couldn't be helpful\n Thank you for your feedback\n\n Feedback sent\n We appreciate your effort and will try to fix the article\n\n 0 of 0","tokens":327,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791265104024,"hash":"c9157ec5a3f4e1e52bfd0caa4f053e78545b28bd"}
{"url":"https://support.io.net/en/support/solutions/articles/156000019625-why-is-my-worker-blocked-","domain":"support.io.net","title":"Why is my worker Blocked? :","text":"Why is my worker Blocked?\n\n A worker may be blocked for several reasons related to system rules, security policies, or violations of acceptable use. Here’s a breakdown of why a worker might have been blocked:1️⃣ If a worker has more than 8 GPUs:IO network limits on the number of GPUs that can be registered to a single worker to prevent overloading or unfair resource usage. Exceeding this limit could result in the worker being blocked or flagged. 2️⃣ If the number of GPUs in a worker is changed or if the model of the GPU in the worker is changed:  A worker may be blocked if the number of GPUs is altered or if the GPU model is changed. This could indicate potential tampering or an attempt to modify the worker’s configuration in ways that the system does not allow. To ensure consistency and fairness in the network, such changes are monitored, and any modification in hardware setup may lead to a block.3️⃣ If device utilization reaches the threshold set by the team:IO monitors GPU utilization to ensure that participants are not overloading the system or exploiting it for rewards. If the GPU usage consistently hits or exceeds a set threshold, it may be considered abuse, causing the worker to be blocked to maintain fairness and stability. Device utilization threshold can be found here.4️⃣ If the worker's location is in a prohibited region and the user tries to connect the worker using VPN:  IO network have geographical restrictions for security, regulatory, or policy reasons. If the worker is located in a region that is restricted, and the user tries to bypass this using a VPN, it could trigger the system to block the worker to prevent violations of these regional rules.5️⃣ GPU SpoofingGPU spoofing refers to the act of pretending to use different hardware or modifying the hardware’s identity to trick the system into awarding rewards unfairly. This is a serious violation and often leads to an immediate block to preserve network integrity.6️⃣ If 2 workers are using a shared MAC address:A MAC address is a unique identifier for network devices. If two workers are using the same MAC address (which is unusual unless the hardware is spoofed or improperly configured), the system might block both workers as it could indicate fraud, impersonation, or an attempt to exploit the network.\n\n Was this article helpful?\n\n That’s Great!\n Thank you for your feedback\n\n Sorry! We couldn't be helpful\n Thank you for your feedback\n\n Feedback sent\n We appreciate your effort and will try to fix the article\n\n 0 of 0","tokens":632,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791265115452,"hash":"8c66ca3c26b664e441092446b20e5ff28f33bda5"}
{"url":"https://dev-forum.pyth.network/t/hermes-client-invalid-response/461/3","domain":"dev-forum.pyth.network","title":"Hermes Client - Invalid response - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Nov 2025\n\n 3 / 5\n\n Nov 2025\n\n Nov 2025\n\n post by KemarTiti on Nov 6, 2025\n\n KemarTiti\n\n Hey,\nWe are currently using @pythnetwork/hermes-client and getLatestPriceUpdates function to retrieve Pyth price feeds in batch mode.\nHowever, the current implementation causes an issue: if even a single feedId is invalid or fails to resolve, the entire batch request fails.\n\nIs there a reliable way to pre-validate whether a given feedId is valid/exists before including it in a batch request?\nIf possible, could you provide (or point us to) an alternative batch retrieval method that supports partial success — i.e., returns prices for all valid feedIds while gracefully handling errors for invalid or unavailable ones without rejecting the whole batch?\n\n 3\n\n 2\n\n post by ali on Nov 6, 2025\n\n ali\n\n We have an ignoreInvalidPriceIds option in the requests that lets you get the feeds partially. See here for more info.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n Thanks!\nEvery 15 seconds, we call your SDK to fetch the latest prices; we batch 20 tokens in each call.\nAs of now, we see that more than 40% of the API calls take more than 2 seconds, and occasionally it will reach a 5-second timeout. Is it expected?\n\n post by ali on Nov 7, 2025\n\n ali\n\n From which location are you hitting Hermes endpoints? We generally recommend using a private Hermes RPC for production usecases.\n\n post by KemarTiti on Nov 7, 2025\n\n KemarTiti\n\n We call it from Singapore\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access\n\n Price Feeds\n\n 4\n\n 580\n\n May 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Powered by Discourse","tokens":1430,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265123773,"hash":"115850b6a2e7f7ab5aa74b5813061702e84f5e53"}
{"url":"https://status.optimism.io/en/history/1","domain":"status.optimism.io","title":"Notice history - Optimism - Status","text":"100% - uptimePublic API - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Deposits - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Withdrawals - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Transaction Sequencing - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Batch Submission - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Node Sync - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026100% - uptimePublic API - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Deposits - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Withdrawals - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Transaction Sequencing - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Batch Submission - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Node Sync - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Website - Operational100% - uptimeAug 2026 · 100.0%Sep · 100.0%Oct · 100.0%Previous pageNext pageAug 2026Sep 2026Oct 2026Notice historyView current statusOct 2026No notices reported this monthSep 2026No notices reported this monthAug 2026AUG31OP Mainnet: scheduled 200 ms subblocks enablementCompletedMaintenance2 hours 16 minutesCompletedAugust 31, 2026 at 3:16 PMCompletedAugust 31, 2026 at 3:16 PMMaintenance has completed successfully.PlannedAugust 31, 2026 at 1:15 PMPlannedAugust 31, 2026 at 1:15 PMWe are performing scheduled maintenance on the OP Mainnet sequencer infrastructure to transition sequencer leadership to a new set of sequencers. As part of this transition, OP Mainnet will move from 250ms flashblock production to 200ms subblock production.No service disruption is expected: block production should continue uninterrupted throughout the transition. This maintenance window is precautionary, and we will confirm once the transition is complete.In progressAugust 31, 2026 at 1:00 PMIn progressAugust 31, 2026 at 1:00 PMMaintenance is now in progressAUG13Flashblocks Mainnet & Sepolia MaintenanceCompletedMaintenance-9 hours -42 minutesIn progressAugust 13, 2026 at 3:10 PMIn progressAugust 13, 2026 at 3:10 PMWe are executing maintenance on the flashblocks endpoints for OP Sepolia & OP Mainnet. When executing the cutover, clients may experience connection issues while DNS propagates. We anticipate this cutover being brief and any connection issues should be resolved within 5 minutes of the cutover.CompletedAugust 13, 2026 at 6:28 AMCompletedAugust 13, 2026 at 6:28 AMMaintenance has completed successfully.PreviousAug 2026 to Oct 2026Next","tokens":803,"squid":"ink-governance","role":"Council Listener","at":1791265127424,"hash":"f5d640ec58605fce95a1064d2f1161133b29e6f5"}
{"url":"https://dev-forum.pyth.network/t/error-price-feed-gaps-in-public-price-feed/203","domain":"dev-forum.pyth.network","title":"Error price feed: Gaps in public price feed - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Error price feed: Gaps in public price feed \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n Jun 2025\n\n 1 / 15\n\n Jun 2025\n\n Apr 2\n\n post by chrisbuildthis on Jun 9, 2025\n\n chrisbuildthis\n\n ‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’\n• Chain (e.g. Ethereum mainnet, Solana devnet, etc.)\nSolana Mainnet\n• Timestamp of the issue (block time or UTC)\nGaps in data so we log and track all data. this is how much gaps we get and it gets worse with time.\n2025-06-04T10:07:42Z\n1749031662\n2025-06-04T10:07:43Z\n1749031663\n2025-06-04T10:12:50Z\n1749031970\n2025-06-04T10:12:51Z\n1749031971\n2025-06-04T10:21:54Z\n1749032514\n2025-06-04T10:34:01Z\n1749033241\n2025-06-04T10:34:50Z\n1749033290\n2025-06-04T10:45:22Z\n1749033922\n2025-06-04T10:47:23Z\n1749034043\n2025-06-04T10:06:06Z\n1749031566\n2025-06-04T10:09:18Z\n1749031758\n2025-06-04T10:13:18Z\n1749031998\n2025-06-04T10:17:19Z\n1749032239\n2025-06-04T10:21:51Z\n1749032511\n2025-06-04T10:34:27Z\n1749033267\n2025-06-04T10:44:18Z\n1749033858\n2025-06-04T10:47:24Z\n1749034044\n2025-06-04T10:47:49\n1749034069\n2025-06-04T10:47:50Z\n1749034070\nExample for the streaming one that kept breaking down:\ncurl -X ‘GET’ \n‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’ \n-H ‘accept: application/json’ --http1.1\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d00760e4a25bf5f623f3386cba8f6a49e3c5928a025de9546d08e3e14493a1dc4072e88b01a52e8d86b5488991ee552e14889c9e15b89b1920741dd2861ac83a27301033740fdcb27395f695a65518fa598103153fa89dc645b63eebe934230209203ed59b47edd864559ea828e74533ee89badb7fe37ad33b96f37f1b1bed627cd78f6010475036ef9b293dd9e534e2dd375cc03f2fd95dd31fbdf3d4949257d650b7020086405cee9e9c0b16cda66acc4b15fef3bb0b45f459aeb790530a39df56f0a23fd0106924db4e607d82c45a465c5f3653573ab43c5f44e9b469aa9911710988e0154183c4f6e70df5dc8d43996377a216317aef46e8cf2368178f94b7002ef595824be0008b8a528ea9f92f1dec6810333354b06f9a44fbb10eeed8dc2bc0f518429e018ed5aff41e60faca0a3df98b62439f3f56266a6c85b010d0cb8c74a9d6e452602e9010a9b2d5473df63c5eaebc8c1073002158428cee5ac9801d30b528a85e5ee379afe13ff8cbd95951b33fe03df5eba25c3a04ba620c1197a38afd897752ed1d6b78d010b74b42c350dc4c9f669b98115de621807e3996f4912cea42da49216f3ce8e2f11376ef94f74132cc28c3fd1831fac354f339c24e92c9482591731a2dc50b2477e010d197e99d27de64896d6b27ed8bd16a308a6507e0c12c97b4fa76850fdab1c1a28483d59921042b2242e92776f694f35597ce8a233f6c5e607ce2d01bc010102c6000ee6de48023ebdab7a3fec5dc7e8a9dafb4b0e416cca81708a6dad1db3679f28ab5fdd1205435439f4c00d9b35d9ca247664175d71a9049e59a77c054b976754d6010f96454eb53f4de6db8b5997c339b1090d5d7ef4b6dc0a9470d74ed1cc54412dd5144d708a8b03013225c57512abc3dd0d8ebdb7cb377a09d640282669560b86b100100c5f23cb9c8047c75ac3217e952cbc75af66650fe62c6d0f6b422160ffa5b2a2259194f3f0e1879998168cf552fd398beedba9c190f501f24f02aa8bf40970c60011ea5a3740d9b7b0bf54fd5debce6b7c4ababe40c5c6bb351de97b77fcdea297aa6705b616908074a3680206eb46272e9211dd433a42b0421a34c5dcbf9df8e2b501126121106c8aa1f6b25aba95f4dc8ed0a3964760b1d542f56e37dce1781ec425d418927c150e26a975c058b33f8c1af8fbe22b24e23c5da22655ca3ebf142a21ce016841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d902014155575600000000000d345aaa000027102cc52522bf49430ad67780c7ebeadcdb013d35f401005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bd8c2bf0000000124a62711fffffff8000000006841e742000000006841e741000009665b3f76c000000001006ef4500c944d5e62d2e0dec821cb3523b2a9e7b9492dad4d6626dc08f99788dfcea56c58d9559bd6f796e38b837231abd868a14ab9a7473b7c68cc289202057206ad4ed2a6650169b808cd0217f0b46ad7a2159d5f514a3342f8987e153265d9cda2a23897907e9813e028ebbefb49de4a04590da653a58b7c1d242a2f1da520b2c872950a8db588dfdad8a17d89e5e8dcfaa5b9b725137ffeaaecdbf7ff617560beaec6c79714ca72bc4ccb67593ad04b71a151b4da527c361cb9cca22559405595fe9b1cd147b14e1d1433648126dba1df1a062b9b29857957a12c33a51200a5806d6cee404f650789310f46d5f07ee15a3658”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316710199999”,“conf”:“4909836049”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335222200000”,“conf”:“4302238800”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534890,“proof_available_time”:1749149507,“prev_publish_time”:1749149505}}]}\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d001dc9c51d9f0317c7c74d34b74cc6eda6f4158ed719881410d8524f8c793d9dc57277efd5080764da7a558097e17015706b126514befeef544c48c29a5dce43f00002bb28b3dcada54ec8d2aaac0a7ef557c3e895143003163ec2ac935a22bacac2f65b75acdd0470e2f7cdae807cfc614ddf61e732af192725ca313d0a4b7421ef3f0003560cfc8c3583f99cee1dcfcf414d0ecd0ac863b09dd66f67a1b1ec420e2fe8936b28628837f5e8f1d845b1311a9ca70011173cdea58fc4f093f640c5437a340100041c5cc17559b6a2ab29202a6bf902ec1f731195892303a3f26b825055d682a617222e4a28a14f395ab304dc4a5b63516808b3eb060004b69f4fd8dc1af8c8c47800064f8609b4af9ecd62b90af4f7c79db18e73a20d86a38912763a0a0f693ee872655baa6017da10a2d82ca1576ccd93976f14938f74f8322745763b806ff2f4845601088877f2ebf7a92efad7f458eca8db5c3d07fc7585fe37b52d0f5243460c7058207f5a07aaaad9a84938d80c0cc5615a75b925786e3c81525ba4e5c214c056e1cc000a98e5c795727915c025c8d03f633d0684e36c231552c5b3217848f128fec91baa370900a7240fda2fd818c9eb71016e5b8349086eed7429aa333e35677fd5628c000bf094d0ae614df5e8d253cf3db41e1d2728a95e9282f8c9e61a05d0a03d899b3b1fc025cee6e04df4a1609d9bbda0da28116b73d9c6daaef9ee8d38bc252db96d010d1836c4591d42683b7bfcbeab7895d37732b5128b6f20f2bfe06db8b3fe78ad2829d3ef3d835dd3f8225d7be47144a62b38ff90e3fb78419bb914b7a38660b506010e2c6e4d868a0970a52da73e614165b321bf6f191cc4c209e9488807a00eec36dc2fefb04efda9e83216e8537b091ccaa94624009391563a023bcfb7f9640cb048000f8d72884e7cfbcf969b3739225510c3b6a925ec8ad0a3d5271fd1a3ddfb4ce69c5f2f6828e3669a0daf4781600409085acba17ece75c40ca302eb995dddce071101104297798fd9e64d26da2cb904b74df77aea8464ac3b9847f3d59a97ad34a43546456849cd6e2e9f392251c37fab73c6913e90060490b9590011861e1029963d190111b0523875a4f516380d6ec7dbb37462c286354f7f53a560c06ff421db26ceb28e6da8cb8b2187d55ce24ab7e0638cc95f26fde3bf9068dadfc8cc9531eb6942c5006841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d903014155575600000000000d345aab000027109a8197e552dd636a3002f9cfdc902cb8789c95ef01005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bc130ce000000013c327290fffffff8000000006841e742000000006841e742000009665b25862000000001007067cc0c1e0308ac3b12f3b2a8e27c41885d3cf84ef19e4003ade8d6f3d5913c7cbdb080480a26757e59849cb5894c136572792202abc5cfd38eb8d6f1d95151e813597c9e22b12ec34176c3d45dafa7830b5a8ef10840a48fbc45a7a105f693b81e568eab892a5e3f4bd79e4f0a5bfb500046235034ddecde050a3e13de3e484f408a17999c04c5a823f2835ae56beab10f120fa70fcf1cf68735d1e3d4d32456081f631251558317376a29105b4729b0bc6b300ac7c73b4181efea4969228cdb7992825a1c90f1d096a566fba497abdd890307b7edfa8b1a14164e47999fde88fac5a0aa536f41b98f0a31bd3a9bbdc9eab48d”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316708655310”,“conf”:“5304906384”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335220500000”,“conf”:“4302333900”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534891,“proof_available_time”:1749149507,“prev_publish_time”:1749149506}}]}\ndata:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d007afc5e654db32909e1a9ab09e64c9927f4985b86a8de9ef4dc6cc22e38d48bcc70ab92cd1aac2f1afd4d335b25cb9bb28a9e1f573bfa667b0bba7885b16f25c60102e0aebbb6d3b06ed493c5b57d95e3437d4446053775e2e2c6918d3a9b521c0e9332989327ab83c1f462bcdee8bdf69620c6270bcbc6523cf167943e217198064101030929d1cf757e64ffa2bb13a12cc648c1d035f36bdb2af3143f1fc55b65b4cd392655cacf65a8c7255e56dee6970b76aacf857d84dd8c6872695959f5b625681e0004a11cb3ac16db430eb50c8af8d177a9208c4d113a5090a800ad6b3ce6f984c03241bb940d97c9dfb7ea76e5fd337628f0c6db1cb005f5641ab977d7e314df6933010647f567cc030b0ec7bac854c73d3f039bd35849ff07ec2ee3b2641f2d605317110f51d27e5317df09b4589c1dcbe203cdbddc2a0c24b20e4b3b39494fc815b4640008373c65d2d4c72b47f908e4a457dd2d8e4fd33f4cd59c304f33ae806736acceb251e63a7622ce73282da15840bad610f378d4aec5baa000fb75aaa8e2fd122770000af8d99184394912fdd6aad7513137fb4dabeb84fd214ea83d3300347feabe998b6380f8250d6805c6fb0408c400d6ed595e40df112bc6fe898c64273a391612ac010b2db12a76c0caf5865989a70af60028184283789b024c263fa6dd3810325eae973db5094c621f985b8ad2c3b108c7b69d195fab8584bb875f4007e776c7354bb0000dd7d0e045584f0017de2fa4426f030c285ba7782cdffe570f31b2fd3ad6e7bbb01b0cf41c8e270b55253693d12c648ac3780d6d1004e08fce7d17ee349947a1b3000ec2502b45ee72c0dcb122150b222bf145d0e0d36a7fe4e7668bc90a2a391836d040d5e5563d73751bcb258845e3114384bd44c1fc965f34027551d5877b5af499000f91a92aaedbb7c0d2d41f3ef13d85792dbad06c1a15ebe4148d7d9eb7fa875ff5677139e55c8a34f72f1c1b03ecd05f9fbc783eb5bc2b1c8fee719f1dd108509d001074836c1fac49e3151e2ac5e320be7ca5985edc0a4b9f9bb191242636d1be77bb7467d0be8b1f892b91320cadcb4aa1f009ebe6163007de39749db166c566d8f60011cdd5e801ea672fe43ada7a8e8c30973c3dd1123296a84feabd85b6233e9f728f7528b11eaf045792f1730a31e3159a1c1a5c6245abd079d10f3a61310e4fc568016841e74300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d904014155575600000000000d345aac0000271063036a46ca40542b4037d842b5152c760c1c152901005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b4300000961fcc34605000000012d3487c7fffffff8000000006841e743000000006841e742000009665b0888400000000100718bfc0cb9593def04dda130fa85b133f427f158d2fcaf25018abb60aa1fee6cee8402b86e5a837695197d52b8c408832ecafcecefc20fdf86e2e9ec9a631f36d350733d2bf45792788b851a3ad7daa859e2946501ca29f4440596cc16018758c50708174faeca9db33397b4bbb88ce32af3f8e3e545c100d715baa5e4025ad060a35ec9b5d524e45dca71926f3e2dc5e682b551b81384aeb7539370fd8d6b4fbfed1a843f3b7c9cc3c13c53ded518e90f07f55f0e78ea4a4df8ba20616199cc57145f7bc29e37ab87f7fae60b19cf588c222839428ac94e732f3d8b33c525d259de84946daba31b76b43ec4714b15cf4e7d39ce”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316457133573”,“conf”:“5053384647”,“expo”:-8,“publish_time”:1749149507},“ema_price”:{“price”:“10335218600000”,“conf”:“4302408700”,“expo”:-8,“publish_time”:1749149507},“metadata”:{“slot”:221534892,“proof_available_time”:1749149508,“prev_publish_time”:1749149506}}]}\ncurl: (18) transfer closed with outstanding read data remaining\n• Name of the dApp/Project that you are building\nPrefer not say. It not a good image of having a broken app due to Data price feed.\n• Contact (Telegram/Email/Discord)\n@unicornDegen\nThe more context you provide, the faster we can help.\nSo we meet the team in Lisabon. We have an app that scalling. The gap in the price feed keeps returning 0 as price. So as a trading app if the data comes back as 0, that means is an error and incorrect.\nIn the app user places bets, betting on the price of what will be solana , app track the price and when it come time to settle we get 0 , and it comes that the user has lost. but they haven’t.\n\n 4\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 4\n min\n\n post by 0xcredence on Jun 9, 2025\n\n post by chrisbuildthis on Jun 10, 2025\n\n post by 0xcredence on Jun 10, 2025\n\n post by ali on Jun 10, 2025\n\n post by chrisbuildthis on Jun 10, 2025\n\n post by chrisbuildthis on Jun 10, 2025\n\n post by ali on Jun 11, 2025\n\n 10 months later\n\n post by whsia on Mar 26\n\n post by whsia on Mar 26\n\n post by KemarTiti on Mar 29\n\n post by whsia on Apr 1\n\n post by KemarTiti on Apr 1\n\n post by whsia on Apr 1\n\n post by KemarTiti on Apr 2\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n EthGlobal qualifying criteria for Historic Prices\n\n Benchmarks(Historic Prices)\n\n 16\n\n 525\n\n Oct 2025\n\n Price Feeds for US.Equity are not been updated periodically\n\n Price Feeds\n\n 15\n\n 715\n\n Dec 2025\n\n Powered by Discourse","tokens":3944,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265134124,"hash":"4edfaae6492afb8bef722d6877b5ac0ba4519fea"}
{"url":"https://dev-forum.pyth.network/t/i-am-getting-this-error-access-denied-hermes-beta-pyth-network-used-cloudflare-to-restrict-access/143/1","domain":"dev-forum.pyth.network","title":"I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n I am getting this error: Access denied | hermes-beta.pyth.network used Cloudflare to restrict access \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n May 2025\n\n 1 / 5\n\n May 2025\n\n May 2025\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n I’m frequently encountering the following error when generating the payload using the update_price_feeds_with_funder function\n</html>\n\n at HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nFailed to update Pyth price payload: Error: HTTP error! status: 429, body: <!DOCTYPE html>\n<!--[if lt IE 7]> <html class=\"no-js ie6 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 7]> <html class=\"no-js ie7 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if IE 8]> <html class=\"no-js ie8 oldie\" lang=\"en-US\"> <![endif]-->\n<!--[if gt IE 8]><!--> <html class=\"no-js\" lang=\"en-US\"> <!--<![endif]-->\n<head>\n<title>Access denied | hermes-beta.pyth.network used Cloudflare to restrict access</title>\n<meta charset=\"UTF-8\" />\n<meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\" />\n<meta http-equiv=\"X-UA-Compatible\" content=\"IE=Edge\" />\n<meta name=\"robots\" content=\"noindex, nofollow\" />\n<meta name=\"viewport\" content=\"width=device-width,initial-scale=1\" />\n<link rel=\"stylesheet\" id=\"cf_styles-css\" href=\"/cdn-cgi/styles/main.css\" />\n\nat HermesClient.httpRequest (/app/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:39:23) at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\nIt seems like the Hermes client is being rate-limited or blocked by Cloudflare, returning a 429 status code and an HTML response instead of the expected data. The error appears to originate from this part of the stack:\nCould someone please help investigate and resolve this issue ?\n\n 3\n\n 2\n\n post by ali on May 8, 2025\n\n ali\n\n The public hermes instances have rate limits (similar to this) but it is very generous and you shouldn’t normally hit it. I’m wondering how often you are hitting the endpoint that is resulting in ratelimit. If you want to get the data frequently I recommend using the streaming endpoint.\n\n post by Ajay on May 8, 2025\n\n Ajay\n\n Hi @ali\nHere’s the code we’re currently using:\nexport const updatePythPricePayload = async (marketId: string) => {\n try {\n const priceIds = [MARKET_PRICE_FEEDS[marketId]];\n const connection = new HermesClient(process.env.PYTH_HERMES_ENDPOINT!, {});\n const priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n });\n const binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n );\n const payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n } as InputEntryFunctionData;\n return payloadResponse;\n } catch (error: any) {\n console.log(\"Failed to update Pyth price payload: \", error);\n rollbar.error(\"Failed to update Pyth price payload.\", error);\n }\n};\n\nWe have configured the following environment variables:\n\nPYTH_HERMES_ENDPOINT=https://hermes-beta.pyth.network\nAPT_PRICE_FEED_ID=0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\n\nWe’re using three price feed IDs: APT, BTC, and ETH. Every 20 seconds, we fetch the payloads for all three feeds and submit the corresponding transactions.\nWe use the following function to update the prices:\n0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\nWe also have a function to update the funding rate. For this, we fetch data from https://hermes-beta.pyth.network for the same three price feed IDs and submit the transaction every 1 minute.\nLet me know if you need any further details.\n\n post by ali on May 8, 2025\n\n post by Ajay on May 8, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Failed to get realtime price feed (may be related to cloudflare)\n\n Benchmarks(Historic Prices)\n\n evm\n\n 2\n\n 318\n\n Nov 2025\n\n Hermes Client - Invalid response\n\n Price Feeds\n\n 4\n\n 397\n\n Nov 2025\n\n Unstable Hermes API\n\n Price Feeds\n\n 1\n\n 480\n\n Aug 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Powered by Discourse","tokens":2032,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265144231,"hash":"5213240ff7cff5e2513b27b5ddc0bc087706b024"}
{"url":"https://ethereum.org/developers/tools/base-mcp/","domain":"ethereum.org","title":"Base MCP | ⁦ethereum.org⁩","text":"Agent toolingBase MCPMCP serversMCP server · Agent skills · Wallet · DeFiWebsite (opens in a new tab)base/skills(121 ☆) (opens in a new tab)Base MCP is a Model Context Protocol server that connects AI agents to wallet and onchain tools on Base, with pre-built prompts and workflows for wallet operations, token transfers, and DeFi interactions. Nothing happens onchain without explicit approval since the server never holds or accesses private keys, instead constructing pending requests that a Base Account reviews and signs, and it ships with skill plugins covering Morpho, Moonwell, Aerodrome, Bankr, Avantis, Virtuals, and Uniswap.Related resourcesMorpho AgentsMorpho Agents is a beta interface built for AI agents to read, simulate, and write to Morpho's lending protocols. The User Agent product is a CLI and MCP server giving agents full read, simulate, and write access on Ethereum and Base with any wallet infrastructure, running every write through a simulation first, while the Builder Agent is an AGENTS.md knowledge base that turns a code agent into a Morpho integration expert.CoinGecko MCPCoinGecko MCP is a remote Model Context Protocol server that gives AI agents access to CoinGecko's market data, including live prices and market caps, historical charts, DeFi and onchain pool data, and NFT collection analytics. It connects to Claude, Cursor, VS Code, and other MCP clients with minimal setup and is backed by CoinGecko's existing API.Tenderly MCPTenderly MCP is a Model Context Protocol server that brings Tenderly's blockchain development tools into AI assistants like Claude, exposing around 59 tools for transaction simulation, virtual testing environments, call trace and event inspection, and project management. It authenticates via OAuth and lets an agent set an active project, then run simulations and debug transactions without leaving the chat.1inch AI (MCP + Agent Skills)1inch AI is the official distribution point for the 1inch hosted MCP server and its agent skills, covering token swaps, limit orders, and SDK documentation search. Agent builders point Claude, Cursor, or Copilot at it so an agent can quote and place swaps.Alchemy MCP ServerThe Alchemy MCP Server gives AI clients access to Alchemy's blockchain data and RPC APIs across more than 100 chains. The hosted server at mcp.alchemy.com is the maintained route, while the open source repository holds the legacy local version.Coinbase Payments MCPThe Coinbase Payments MCP, now documented as the Agentic Wallet MCP, gives an AI agent tools to move and accept crypto payments through Coinbase's payment APIs. Builders add it when an agent needs to send or receive payments.","tokens":667,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265151376,"hash":"f525b4e68d21ec3bf849be7ded183444a0f2a3c6"}
{"url":"https://governance.aave.com/t/recovery-request-accidental-wbtc-transfer-to-awbtc-contract-on-arbitrum/25349","domain":"governance.aave.com","title":"[RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum - Governance - Aave","text":"[RECOVERY REQUEST] Accidental WBTC transfer to aWBTC contract on Arbitrum \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 20\n\n 1 / 4\n\n Jul 21\n\n Jul 20\n\n post by Leo.Inoue on Jul 20\n\n Leo.Inoue\n\n Hello Aave Governance,\nFollowing the guidance received from Aave Labs Support, I would like to register my case for consideration in a future rescue mission.\nI accidentally transferred 0.06872349 WBTC directly to the aWBTC contract on Arbitrum instead of using the “Supply” function in the Aave App.\nTransaction Hash:\n0x660fe7b3a52e292f7de32bf292d409a2a127228968cdf7b765cfc81568f58047\nSender Wallet:\n0xB74285439139fa4Cf76fF1e0C36FeB8e6Fcd3AC9\nRecipient Contract:\n0x078f358208685046a11C85e8ad32895DED33A249\nI mistakenly copied the aWBTC token contract address and sent WBTC directly from MetaMask, believing I was depositing my funds into Aave.\nIf any additional information or proof is required, I will be happy to provide it.\nThank you very much for your time and consideration.\nKind regards,\nLeo Inoue\nThank you. Regards\n\n Unlisted on Jul 20\n\n Listed on Jul 21\n\n 1 month later\n\n Closed on Aug 20\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 78\n\n Aug 5\n\n Rescue of wrong sent tokens\n\n Governance\n\n 0\n\n 48\n\n Aug 13","tokens":447,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265177015,"hash":"6b4a0f678e7643b1a3711440f4f981226cced208"}
{"url":"https://governance.aave.com/t/recovery-request-accidentally-sent-25k-usdc-directly-to-aave-v3-pool/25309/3","domain":"governance.aave.com","title":"[Recovery Request] Accidentally Sent 25K USDC Directly to Aave V3 Pool - Other - Aave","text":"Other\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 13\n\n 3 / 3\n\n Jul 15\n\n Jul 13\n\n post by stoneseen on Jul 13\n\n stoneseen\n\n Hi all,\nOn July 12nd, I mistakenly sent 25,000 USDC directly to the Aave V3 Pool contract on ETH instead of supplying via the interface.\n\nTx hash: 0x6a4cd27125fe4916909efdb9e6cc79f298ce514e56bd4851e92641f71c666b5c\nPool proxy address: 0x98c23e9d8f34fefb1b7bd6a91b7ff122f4e16f5c\nSending wallet: 0x32fcf748e4dcebd1081bfcccb94eb721101f27c0 (I can sign a message to prove ownership)\n\nI understand from Rescue Mission Phases 1–3 that recovery of tokens sent directly to upgradeable Aave contracts is technically feasible via a governance-approved implementation upgrade, with claims distributed through the AaveMerkleDistributor to the original sending address.\nRequest to BGD Labs / ACI / the community: could this transfer be registered for inclusion in a future rescue phase covering the V3 Pool? Happy to provide any additional verification needed.\nThank you.\n\n Unlisted on Jul 13\n\n Listed on Jul 14\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Request: include 25K USDC sent directly to V3 Pool in next Rescue Mission phase\n\n Development\n\n 0\n\n 116\n\n Jul 14\n\n [RECOVERY REQUEST] Accidental AETHUSDC transfer to AAVE USDC contract on ETH\n\n Governance\n\n 0\n\n 100\n\n Aug 25\n\n Wrong Wallet Transaction \n\n Governance\n\n 0\n\n 78\n\n Aug 5\n\n [RECOVERY REQUEST] Accidental USDT Transfer to AAVE Address on Arbitrum\n\n General\n\n 0\n\n 89\n\n 12d\n\n [RECOVERY REQUEST] Accidental transfer of 83.71815 UNI to AAVE Token contract on BNB Chain\n\n Governance\n\n 0\n\n 108\n\n 11d","tokens":415,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265189897,"hash":"2bd33640814775556d8f25e1e0b1ede37111f493"}
{"url":"https://forum.soliditylang.org/t/about-the-code-wizards-category/16","domain":"forum.soliditylang.org","title":"About the Code Wizards category - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n About the Code Wizards category \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by franzihei on Dec 18, 2020\n\n franzihei\n\n Share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n Please be aware that this is not the place for ad-hoc support questions. For urgent Solidity support questions, please use the Solidity Gitter chat or consider checking out the Ethereum StackExchange. It’s also not the place for audit requests, although it is the right place to ask for feedback on a specific mechanism or construct.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 82\n\n Jun 22\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 120\n\n May 29\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1185,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265189930,"hash":"37a56b6ecd0eabd4464f03d951e357e68ec681ec"}
{"url":"https://docs.base.org/upgrades/overview","domain":"docs.base.org","title":"Upgrades - Base Documentation","text":"FiltersBase evolves through named network upgrades. Each release introduces protocol changes, new features, or parameter updates that activate across Base Sepolia and Base Mainnet.\nA month without a confirmed activation timestamp is a planning target and may change.\n​Planning​DenimDenim introduces native blocks at a 200ms cadence, replacing Flashblocks with canonical block and RPC streams.\nBase Sepolia: Targeting October 2026\nBase Mainnet: Targeting November 2026\nView Features\n​Live​CobaltCobalt improves the B20 token standard, adds validity transactions, introduces dynamic node upgrades (metrics-only on Mainnet), and migrates TEE signer registration to onchain attestation verification.\nBase Sepolia: Activated September 23, 2026\nBase Mainnet: Activated September 30, 2026\nView Features\n​Live​BerylBeryl makes Base a first-class issuance platform with B20 tokens, reduces withdrawal delays, and adopts Reth V2 as the reference execution client.\nBase Sepolia: Activated June 18, 2026\nBase Mainnet: Activated June 25, 2026\nView Features\n​Live​AzulAzul is Base’s first independent network upgrade. It strengthens security and decentralization, advances the path to 1 gigagas per second, and improves the developer experience.\nBase Sepolia: Activated April 20, 2026\nBase Mainnet: Activated May 28, 2026\nView Features\n​Upstream OP Stack Hardforks\nBase adopted the following upstream OP Stack hardforks. Entries are ordered by Base Mainnet activation date.\n​Live​JovianJovian introduces a configurable minimum base fee and a data availability footprint gas scalar for improved fee-market stability.\nBase Sepolia: Activated November 19, 2025\nBase Mainnet: Activated December 2, 2025\nView Features\n​Live​IsthmusIsthmus incorporates Ethereum Pectra EIPs and introduces the operator fee mechanism for sequencer revenue.\nBase Sepolia: Activated April 17, 2025\nBase Mainnet: Activated May 9, 2025\nView Features\n​Live​HoloceneHolocene introduces dynamic EIP-1559 parameters configurable through SystemConfig and stricter block derivation rules.\nBase Sepolia: Activated November 26, 2024\nBase Mainnet: Activated January 9, 2025\nView Features\n​Live​GraniteGranite adds bn256Pairing precompile input-size restrictions and updates the channel timeout parameter.\nBase Sepolia: Activated August 12, 2024\nBase Mainnet: Activated September 11, 2024\nView Features\n​Live​FjordFjord introduces FastLZ-based L1 fee estimation, the RIP-7212 secp256r1 precompile, and Brotli channel compression.\nBase Sepolia: Activated May 29, 2024\nBase Mainnet: Activated July 10, 2024\nView Features\n​Live​EcotoneEcotone integrates Ethereum Dencun changes, including EIP-4844 blob transactions and EIP-4788 beacon block roots.\nBase Sepolia: Activated February 21, 2024\nBase Mainnet: Activated March 14, 2024\nView Features\n​Live​DeltaDelta introduces span batches to reduce L1 data costs by compressing multiple L2 blocks into a single batcher transaction.\nBase Sepolia: Activated December 22, 2023\nBase Mainnet: Activated February 22, 2024\nView Features\n​Live​CanyonCanyon brings Ethereum Shanghai EIPs, including EIP-3651, EIP-3855, and EIP-3860, to the Base execution layer.\nBase Sepolia: Activated November 14, 2023\nBase Mainnet: Activated January 11, 2024\nView Features\n​Other Changes\nThe configuration changelog tracks network parameter changes that do not belong to a specific upgrade.Was this page helpful?Suggest editsRaise issue","tokens":851,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265201313,"hash":"3988d7ddc55e63177ccab900b6f185fc0f84299d"}
{"url":"https://forum.soliditylang.org/t/what-solidity-try-catch-actually-catches/3705","domain":"forum.soliditylang.org","title":"What Solidity try/catch actually catches - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n What Solidity try/catch actually catches \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 22\n\n 1 / 2\n\n May 22\n\n May 29\n\n post by researchzero on May 22\n\n researchzero\n\n I have been looking into some edge cases around Solidity try/catch.\nThe main point is that try/catch only catches failures from the external call or contract creation expression itself. Some failures around that expression can still revert the caller and bypass the catch block entirely.\nA few examples:\n\nReverts inside the external call can be caught.\n\nPanic errors such as assert failures or arithmetic errors inside the external call can be caught with catch Panic(uint256).\n\nCustom errors and unknown revert data can be handled with catch (bytes memory).\n\nErrors while evaluating arguments before the call are not caught.\n\nErrors while decoding return data may bypass the catch block.\n\nCalls to addresses without contract code can behave differently than people expect because Solidity inserts checks before high-level external calls.\n\nThis matters when contracts use try/catch for “safe” integrations with unknown or optional external contracts. The catch block may not be a complete safety net unless the call boundary and ABI assumptions are handled carefully.\nCurious if others here have run into try/catch edge cases in audits or production code.\n\n post by red-swan on May 29\n\n red-swan\n\n It’s something that often surprises folks. I’ve seen bugs from time to time that deal with it. I don’t remember where but there was a batch caller that was meant to send out rewards and it looped through all the contracts trying to call them to receive the NFT or 1155 token or something. But if one was an EOA the function would revert trying to get to the try/catch and not be caught So you could DOS the contract by putting an EOA in the list of contracts to send rewards to.\nThere was a lightning talk about it in the last DSS that I like: youtube watch?v=XqzIw_r8JU8\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 82\n\n Jun 22\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1517,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265201365,"hash":"75f11424148825af7f612e5bb9b70b05267b3187"}
{"url":"https://governance.aave.com/t/core-wallet-on-avalanche-v3-forces-unnecessary-ethereum-network-switch/25487/2","domain":"governance.aave.com","title":"Core Wallet on Avalanche V3 forces unnecessary Ethereum network switch - Other / Site Feedback - Aave","text":"OtherSite Feedback\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 15\n\n 3 / 3\n\n Aug 18\n\n Aug 17\n\n post by aljariemo on Aug 15\n\n aljariemo\n\n I am posting this here because I could not find an existing issue describing this exact Core + Avalanche V3 connection behavior.\nI am using Aave V3 on Avalanche exclusively, with the Core browser extension.\nThere appears to be an unnecessary network-switch requirement during wallet connection.\nSteps to reproduce\n\nOpen the Core browser extension.\nSet the active network to Avalanche C-Chain.\nOpen app.aave.com.\nSelect Avalanche Market V3.\nConfirm that the Aave interface is already displaying the Avalanche market.\nSelect Connect Wallet → Core.\nDuring the connection process, Core displays:\n\n“app.aave.com is requesting to switch your active network to Ethereum.”\n\nIf I reject the Ethereum network switch, the Core/Aave wallet connection fails.\nIf I approve the switch to Ethereum, the wallet connects successfully.\nWhen I later initiate an Aave transaction on Avalanche, I then have to switch the wallet back from Ethereum to Avalanche C-Chain.\n\nExpected behavior\nBecause:\n\nAave is already set to Avalanche Market V3\nCore is already connected to Avalanche C-Chain\nall of my Aave activity is on Avalanche\n\nthe wallet connection should initialize directly on Avalanche C-Chain (chain ID 43114).\nThere should be no need to switch to Ethereum Mainnet during the initial connection and then switch back to Avalanche for the transaction.\nActual behavior\nThe current sequence is:\nCore on Avalanche → Aave Avalanche V3 → Connect Core → forced Ethereum switch → wallet connects → initiate Avalanche transaction → switch back to Avalanche\nRejecting the Ethereum switch prevents the wallet from connecting.\nAdditional information\n\nWallet: Core browser extension\ndApp: app.aave.com\nMarket: Aave V3 Avalanche\nIntended network: Avalanche C-Chain\nEthereum transactions involved: None\nETH gas involved: None\nIssue is reproducible consistently.\n\nI have attached a screenshot showing Aave already on the Avalanche V3 market while Core simultaneously reports that app.aave.com is requesting a switch to Ethereum.\nCould you please confirm whether this Ethereum-first connection behavior is intentional?\nIf not, could the wallet connection logic use the currently selected Aave market / current wallet chain when initializing the Core connection, so Avalanche users can connect directly on chain ID 43114?\nimage2146×835 156 KB\n\n post by Essah on Aug 17\n\n Essah\n\n Aave Labs-Technical SP\n\n Hi,\nThe Governance Forum is for protocol discussion. For personal support, please use one of our official channels:\nDocs: Aave Protocol Overview\nIn-App: app.aave.com → Get Support (on the bottom of the page)\nEmail: wecare@aave.com\nDiscord: Aave Community → #help\nNote: Aave Labs will never DM you first or ask for your seed phrase or private keys.\nClosing this thread. Our support team is ready to help through the channels above.\n— Aave Labs\n\n Closed on Aug 17\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 1\n\n 158\n\n Sep 16\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21\n\n [ARFC] Low Adoption Asset Deprecation on Aave V3\n\n Governance\n\n 9\n\n 2.1k\n\n Sep 16\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 2\n\n 200\n\n Sep 17\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28","tokens":886,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265201473,"hash":"2bdb81ca317953f88e4e4082e72a53978d015bb2"}
{"url":"https://forum.soliditylang.org/t/what-solidity-try-catch-actually-catches/3705/1","domain":"forum.soliditylang.org","title":"What Solidity try/catch actually catches - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n What Solidity try/catch actually catches \n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 22\n\n 1 / 2\n\n May 22\n\n May 29\n\n post by researchzero on May 22\n\n researchzero\n\n I have been looking into some edge cases around Solidity try/catch.\nThe main point is that try/catch only catches failures from the external call or contract creation expression itself. Some failures around that expression can still revert the caller and bypass the catch block entirely.\nA few examples:\n\nReverts inside the external call can be caught.\n\nPanic errors such as assert failures or arithmetic errors inside the external call can be caught with catch Panic(uint256).\n\nCustom errors and unknown revert data can be handled with catch (bytes memory).\n\nErrors while evaluating arguments before the call are not caught.\n\nErrors while decoding return data may bypass the catch block.\n\nCalls to addresses without contract code can behave differently than people expect because Solidity inserts checks before high-level external calls.\n\nThis matters when contracts use try/catch for “safe” integrations with unknown or optional external contracts. The catch block may not be a complete safety net unless the call boundary and ABI assumptions are handled carefully.\nCurious if others here have run into try/catch edge cases in audits or production code.\n\n post by red-swan on May 29\n\n red-swan\n\n It’s something that often surprises folks. I’ve seen bugs from time to time that deal with it. I don’t remember where but there was a batch caller that was meant to send out rewards and it looped through all the contracts trying to call them to receive the NFT or 1155 token or something. But if one was an EOA the function would revert trying to get to the try/catch and not be caught So you could DOS the contract by putting an EOA in the list of contracts to send rewards to.\nThere was a lightning talk about it in the last DSS that I like: youtube watch?v=XqzIw_r8JU8\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 82\n\n Jun 22\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n [Call for feedback] The Long-term Solidity Roadmap\n\n Feedback\n\n 20\n\n 1.6k\n\n Aug 19\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1516,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265212827,"hash":"6599fa23610af13bbfc9e75b4a4e87c793b2e5fd"}
{"url":"https://governance.aave.com/t/arfc-low-adoption-asset-deprecation-on-aave-v3/25401/11","domain":"governance.aave.com","title":"[ARFC] Low Adoption Asset Deprecation on Aave V3 - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n 2\n\n read \n\n 15\n min\n\n Jul 29\n\n 11 / 11\n\n Sep 16\n\n Sep 16\n\n post by LlamaRisk on Jul 29\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk, together with the Aave service providers working on risk surface reduction, recommends offboarding a broad set of low-activity Aave V3 reserves along with six whole deployments. The following specification lists the current configuration of each reserve and the parameter changes required to wind it down.\nThe individual removals cover 49 reserves and 21 matured Pendle PTs across eleven deployments, holding $80.1M of supply and $11.5M of debt. The whole-market deprecations add 29 reserves across Sonic, Scroll, zkSync, Metis, Soneium and Aptos, holding $12.8M of supply and $4.1M of debt. A large share of the set is already in motion, with borrowing disabled, reserves frozen, or caps already reduced to 1 on most of it.\nA further set of V3 reserves flagged for Chainlink price feed risk is being offboarded through the companion oracle deprecation ARFC. Those reserves receive a freeze, caps of 1 and a fixed-price oracle there, so they are listed in the cross-reference section below and excluded from the tables and specification of this document.\nMotivation\nThis recommendation is part of a portfolio-level effort to reduce Aave’s risk surface across deployments, applying the Aave Risk Framework rather than reacting to a problem with any single asset. Most reserves in scope are assets whose usage on Aave has remained below, or declined to, the level the framework requires for a standalone listing. Each listed reserve carries a fixed operational load regardless of its size: an oracle to maintain, risk parameters to monitor, and a liquidation path that must function reliably. Where a reserve’s activity no longer justifies that load, it is wound down.\nThe scope also includes several structural cases. Bridged tokens such as USDC.e and USDbC are removed where the native version is listed and retained, so the same asset is not carried twice. MaticX is being sunset by its issuer. A group of Pendle Principal Tokens has passed maturity, after which the reserve serves no ongoing function. On six smaller deployments the assessment applies to the whole market rather than individual reserves: aggregate activity has declined to a level where the revenue the deployment generates does not cover the cost of supporting it, so the entire market is wound down at once.\nWind-down mechanics\nEach reserve is wound down so that exposure is removed while users exit in an orderly way and liquidation risk is minimised.\nThe default action on every reserve is to freeze it, reduce its supply and borrow caps to 1 and, on reserves that carry a borrow, raise the RF. The freeze blocks new supply, borrow, and use as fresh collateral. Raising the RF directs more of the borrow interest to the treasury, so suppliers earn less yield and withdraw their assets. As supply leaves, utilisation rises and borrowers are pushed to repay. For assets that are currently used as collateral, freezing the market stops new activity, but the positions already in place can remain open. Any effort to unwind those positions is discussed on a case-by-case basis. The next steps listed per reserve below reflect this default action and the current state of each reserve.\nBeyond the default action, further levers may be applied depending on how each asset behaves, so they are deliberately not part of the per-reserve next steps:\n\nWhere borrowers do not repay despite the raised reserve factor, the IRM curves are increased to make carrying a borrow more expensive.\nWhen it is deemed risky to keep the exposure, the Liquidation Threshold can be gradually reduced to deleverage the market, applied per asset when that is necessary to remove a lingering collateral position.\n\nThe whole-market deprecations apply the same approach to every reserve at once: each reserve is frozen with caps reduced to 1 and, where it is borrowed, the RF is raised to 99% and the IRM base rate is set to 5%, matching the initial rate step used in the oracle deprecation ARFC. We will reassess periodically whether further measures, such as raising the IRM further, are needed.\nOverlap with the oracle deprecation ARFC\nThe reserves of Aave V3 below qualify for this scope on adoption grounds but also carry a Chainlink price feed assessed at elevated risk. They are handled in the oracle deprecation ARFC, which freezes each reserve, reduces its caps to 1 and replaces the live feed with a fixed-price adapter. They are excluded from the specification of this document to avoid double-specifying the same reserves.\n\nAsset\nInstance\nFeed tier\nSupplied\nBorrowed\n\nLUSD\nEthereum\nVery High\n$2.0M\n$665k\n\nRPL\nEthereum\nHigh\n$608k\n$212k\n\nBAL\nEthereum\nVery High\n$46k\n$3k\n\nFRAX\nEthereum\nVery High\n$38k\n$29k\n\nKNC\nEthereum\nHigh\n$6k\n$1k\n\nFXS\nEthereum\nHigh\n$1k\n$17\n\nLUSD\nArbitrum\nVery High\n$192k\n$75k\n\nFRAX\nArbitrum\nVery High\n$170k\n$48k\n\nMAI\nArbitrum\nVery High\n$16k\n$13\n\nMAI\nAvalanche\nVery High\n$21k\n$4k\n\nFRAX\nAvalanche\nVery High\n$7k\n$6k\n\nLUSD\nOptimism\nVery High\n$26k\n$18k\n\nMAI\nOptimism\nVery High\n$9k\n$3k\n\nsUSD\nOptimism\nVery High\n$26k\n$12k\n\nGHST\nPolygon\nVery High\n$31k\n$311\n\nmiMATIC\nPolygon\nVery High\n$9k\n$11\n\nBAL\nPolygon\nVery High\n$1k\n$450\n\nSTG\nEthereum\nMedium\n$92\n$2\n\nUSDm on Celo and SCR on Scroll are also covered by the oracle deprecation ARFC. SCR additionally falls under the Scroll whole-market deprecation below, where the deployment-wide parameter changes still apply.\nScope by market\nThe first chart sets the in-scope supplied value of each live deployment against that market’s total supplied value. On the large general-purpose markets the changes touch a small fraction of overall size.\nShare of each live market's supplied value affected2160×1170 161 KB\nSource: LlamaRisk, July 28th, 2026\nThe six whole-market deprecations cover their deployments in full and hold $12.8M of supply between them: Sonic $7.6M, Scroll $2.2M, Aptos $1.7M, zkSync $0.8M, Metis $0.3M and Soneium $0.2M. The chart below shows how much each deployment, live and fully deprecated alike, contributes to the roughly $98M of supplied value in scope.\nContribution of each deployment to the supplied value in scope1980×1170 213 KB\nSource: LlamaRisk, July 28th, 2026\nLive markets: individual reserve removals\nEthereum Core\nThe Ethereum Core scope is dominated by BTC liquid-staking wrapper FBTC, which holds $11.1M of supply against $63k of borrowing. CRV and UNI carry the largest remaining borrow balances in scope, with supply roughly halving over the same window, CRV from $4.2M to $2.2M and UNI from $4.1M to $1.7M. The remainder is a long tail of reserves below $250k, most of them already frozen, borrow-disabled or capped to 1, where this proposal formalises a wind-down that is already underway.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nFBTC\n$11.1M\n$63k\n50%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 75%\n\nMatured PTs (15)\n$86k\n$0\n-\nActive, supply cap of 1\nNo\nE-Mode only\nMatured\nFreeze all and set caps to 1\n\nCRV\n$2.2M\n$238k\n35%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nUNI\n$1.7M\n$29k\n20%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\ncrvUSD\n$185k\n$78k\n20%\nActive, supply cap of 1, borrow cap of 1\nYes\nNon-collateral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nMKR\n$175k\n$2k\n20%\nFrozen, supply cap of 1, borrow cap of 1\nYes\nGeneral\nLimited adoption\nRaise RF to 50%\n\nETHx\n$159k\n$650\n15%\nActive, supply cap of 1\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\n1INCH\n$154k\n$6k\n20%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nezETH\n$111k\n$0\n-\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve and set caps to 1\n\nENS\n$72k\n$5k\n20%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nSNX\n$59k\n$13k\n95%\nActive, supply cap of 1\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 99%\n\nsDAI\n$50k\n$0\n-\nActive, supply cap of 1\nNo\nGeneral\nLimited adoption\nFreeze reserve and set caps to 1\n\neUSDe\n$17k\n$0\n45%\nActive, supply cap of 1\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve and set caps to 1\n\nAave V3 Ethereum Core in-scope supply history2160×1080 200 KB\nSource: LlamaRisk, July 28th, 2026\nEthereum Prime\nThe Ethereum Prime instance is built around wstETH-collateralised WETH leverage, and the three reserves in scope never found a role in that structure. ezETH supply has fallen from $11.7M in late January to $337k as looping demand consolidated on other deployments. USDS holds $217k against $42k of borrowing and already has both caps at 1. sUSDe holds $46k and was never borrowable. USDS and sUSDe remain fully served by their Ethereum Core listings, where liquidity is materially deeper, and ezETH is already in the Ethereum Core scope of this proposal. The Prime listings therefore add operational load without adding usage.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nezETH\n$337k\n$0\n15%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve and set caps to 1\n\nUSDS\n$217k\n$42k\n25%\nActive, supply cap of 1, borrow cap of 1\nYes\nNon-collateral\nLimited adoption, deeper market on Ethereum Core\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nsUSDe\n$46k\n$0\n10%\nActive\nNo\nGeneral + E-Mode\nLimited adoption, deeper market on Ethereum Core\nFreeze reserve and set caps to 1\n\nAave V3 Ethereum Prime in-scope supply history2160×1080 80.6 KB\nSource: LlamaRisk, July 28th, 2026\nArbitrum\nOn Arbitrum the largest position is DAI, at $3.6M supplied and $2.5M borrowed, flagged for limited on-chain exit liquidity rather than inactivity, with supply down from $6.1M six months ago. rETH and tBTC hold a combined $3.7M with almost no borrowing against them. USDC.e is the bridged predecessor of native USDC and is removed as a duplicate listing, its supply declining from $1.8M to $1.1M as users migrate to the native version.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nDAI\n$3.6M\n$2.5M\n25%\nActive, borrow cap 4,410,000 DAI\nYes\nGeneral + E-Mode\nLimited liquidity\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nrETH\n$2.2M\n$35k\n15%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\ntBTC\n$1.4M\n$0\n20%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve and set caps to 1\n\nUSDC.e\n$1.1M\n$943k\n50%\nActive\nNo\nGeneral + E-Mode\nBridged USDC, native version retained\nFreeze reserve, set caps to 1 and raise RF to 75%\n\nezETH\n$150k\n$0\n15%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve and set caps to 1\n\nEURS\n$12k\n$6k\n20%\nFrozen, borrow cap 65,000 EURS\nYes\nGeneral + E-Mode\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\nAave V3 Arbitrum in-scope supply history2160×1080 122 KB\nSource: LlamaRisk, July 28th, 2026\nPlasma\nPlasma’s in-scope balance is dominated by matured Pendle PTs at $32.2M, which no longer accrue yield and only await withdrawal. The two live reserves reflect the deployment’s post-launch contraction: WETH supply has fallen from $47.2M to $2.1M and weETH from $277.5M to $1.1M over six months as launch-phase looping capital exited.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nMatured PTs (6)\n$32.2M\n$0\n-\nActive, supply cap of 1\nNo\nE-Mode only\nMatured\nFreeze all and set caps to 1\n\nWETH\n$2.1M\n$861k\n15%\nActive, supply cap of 1, borrow cap of 1\nYes\nGeneral\nLimited adoption and liquidity\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nweETH\n$1.1M\n$0\n20%\nActive\nNo\nGeneral + E-Mode\nLimited adoption and liquidity\nFreeze reserve and set caps to 1\n\nwstETH\n$195\n$1\n35%\nFrozen, borrow cap 5,000 wstETH\nYes\nGeneral + E-Mode\nLimited adoption and liquidity\nSet caps to 1 and raise RF to 50%\n\nAave V3 Plasma in-scope supply history2160×1080 95.6 KB\nSource: LlamaRisk, July 28th, 2026\nBase\nThe Base scope is small: tBTC at $421k, with supply down from $836k over six months, the bridged USDbC removed as a duplicate of native USDC, and a dust ezETH reserve.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\ntBTC\n$421k\n$47k\n20%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nUSDbC\n$172k\n$125k\n50%\nActive\nNo\nGeneral\nBridged USDC, native version retained\nFreeze reserve, set caps to 1 and raise RF to 75%\n\nezETH\n$17k\n$0\n15%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve and set caps to 1\n\nAave V3 Base in-scope supply history2160×1080 141 KB\nSource: LlamaRisk, July 28th, 2026\nPolygon\nPolygon’s scope is led by the bridged USDC.e at $3.4M supplied and $2.9M borrowed, removed as a duplicate of native USDC. EURS holds $1.9M and already sits at an RF of 99% from earlier deprecation steps. MaticX is wound down because Stader is sunsetting the token. The remaining six reserves are frozen dust positions below $40k each.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nUSDC.e\n$3.4M\n$2.9M\n60%\nActive\nNo\nGeneral + E-Mode\nBridged USDC, native version retained\nFreeze reserve, set caps to 1 and raise RF to 85%\n\nEURS\n$1.9M\n$252k\n99%\nActive, supply cap of 1\nNo\nGeneral + E-Mode\nLimited adoption and liquidity\nFreeze reserve and set caps to 1\n\nMaticX\n$654k\n$5k\n20%\nActive\nNo\nGeneral + E-Mode\nIssuer sunsetting the asset\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nDPI\n$38k\n$4k\n35%\nFrozen, borrow cap 779 DPI\nYes\nGeneral\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\nstMATIC\n$16k\n$0\n-\nFrozen\nNo\nGeneral + E-Mode\nLimited adoption\nSet caps to 1. Monitor, residual immaterial\n\nSUSHI\n$17k\n$6k\n20%\nFrozen, borrow cap 180,000 SUSHI\nYes\nGeneral\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\nCRV\n$9k\n$416\n35%\nFrozen, borrow cap 300,000 CRV\nYes\nGeneral\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\nEURA\n$7k\n$2k\n20%\nFrozen\nNo\nE-Mode only\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\njEUR\n$4k\n$3k\n20%\nFrozen, borrow cap 100,000 jEUR\nYes\nE-Mode only\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\nAave V3 Polygon in-scope supply history2160×1080 155 KB\nSource: LlamaRisk, July 28th, 2026\nAvalanche\nThe Avalanche scope consists of three bridged tokens, WBTC.e, LINK.e and AAVE.e, carrying minimal borrowing and exposure. For example, WBTC.e supply sits at $2.6M, down from $4.1M six months ago.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nWBTC.e\n$2.6M\n$122k\n20%\nFrozen, borrow cap 1,100 WBTC.e\nYes\nGeneral\nLimited adoption\nSet caps to 1 and raise RF to 50%\n\nLINK.e\n$824k\n$15k\n20%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nAAVE.e\n$154k\n$0\n-\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve and set caps to 1\n\nAave V3 Avalanche in-scope supply history2160×1080 134 KB\nSource: LlamaRisk, July 28th, 2026\nOptimism\nOn Optimism the bridged USDC.e, at $1.2M supplied and down from $2.0M six months ago, is removed as a duplicate of native USDC, while DAI and rETH carry a combined $1.1M with usage below the framework’s thresholds.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nUSDC.e\n$1.2M\n$303k\n50%\nActive\nNo\nGeneral + E-Mode\nBridged USDC, native version retained\nFreeze reserve, set caps to 1 and raise RF to 75%\n\nDAI\n$617k\n$517k\n25%\nActive, borrow cap 900,000 DAI\nYes\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nrETH\n$518k\n$1k\n15%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nAave V3 Optimism in-scope supply history2160×1080 119 KB\nSource: LlamaRisk, July 28th, 2026\nGnosis\nGNO is excluded from this scope for now and will be treated separately. The remaining Gnosis reserves in scope are listed below.\nWETH is the material Gnosis reserve at $3.2M supplied and $1.8M borrowed, with supply down from $7.8M over six months and borrowing already disabled. The legacy bridged USDC reserve is frozen with caps at 1 and only awaits the RF step.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nWETH\n$3.2M\n$1.8M\n15%\nActive\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nUSDC\n$142k\n$13k\n80%\nFrozen, supply cap of 1, borrow cap of 1\nYes\nGeneral\nLimited adoption\nRaise RF to 99%\n\nAave V3 Gnosis in-scope supply history2160×1080 113 KB\nSource: LlamaRisk, July 28th, 2026\nBSC\nThe BSC scope holds wstETH, FDUSD and Cake, together $3.6M of supply. wstETH supply has fallen from $5.2M to $2.1M over six months and carries under $1k of borrowing, while FDUSD’s $582k borrow is the only material debt in scope.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nwstETH\n$2.1M\n$941\n15%\nActive, supply cap of 1\nNo\nGeneral + E-Mode\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nFDUSD\n$858k\n$582k\n20%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nCake\n$636k\n$13k\n20%\nActive\nNo\nGeneral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nAave V3 BSC in-scope supply history2160×1080 116 KB\nSource: LlamaRisk, July 28th, 2026\nMegaETH\nWETH is excluded from this scope for now and will be treated separately. The two remaining in-scope reserves hold about $4k between them, so no supply history chart is included.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nReason\nNext steps\n\nUSDT0\n$4k\n$3k\n10%\nActive, borrow cap 9,000,000 USDT0\nYes\nNon-collateral\nLimited adoption\nFreeze reserve, set caps to 1 and raise RF to 50%\n\nezETH\n$6\n$0\n20%\nActive, supply cap of 1\nNo\nE-Mode only\nLimited adoption\nFreeze reserve and set caps to 1\n\nWhole-market deprecations\nEach deployment is wound down in full: every reserve is frozen with caps reduced to 1 and, on reserves that carry a borrow, the RF is raised to 99% and the IRM base rate is set to 5%. We will reassess periodically whether additional measures, such as raising the IRM further, are needed.\nSonic\nDeposits on the Sonic deployment have fallen from $28.9M to $7.6M over the trailing six months, a decline of 74%, and $2.7M remains borrowed. At current balances, rates and reserve factors the deployment generates under $5k per quarter in protocol revenue, which does not cover the cost of maintaining oracles, monitoring and operational support for the market.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nNext steps\n\nUSDC\n$2.9M\n$1.6M\n10%\nActive, borrow cap 1,050,000 USDC\nYes\nGeneral\nFreeze reserve, set caps to 1, raise RF to 99% and set IRM base rate to 5%\n\nwS\n$1.7M\n$879k\n15%\nActive, borrow cap 36,100,000 wS\nYes\nGeneral\nFreeze reserve, set caps to 1, raise RF to 99% and set IRM base rate to 5%\n\nstS\n$1.5M\n$0\n10%\nActive\nNo\nGeneral\nFreeze reserve and set caps to 1\n\nWETH\n$1.5M\n$249k\n15%\nActive, borrow cap 97 WETH\nYes\nGeneral\nFreeze reserve, set caps to 1, raise RF to 99% and set IRM base rate to 5%\n\nAave V3 Sonic aggregate supply and borrow2160×1080 114 KB\nSource: LlamaRisk, July 28th, 2026\nScroll\nDeposits on the Scroll deployment have fallen from $16.1M to $2.2M over the trailing six months, a decline of 86%, and $422k remains borrowed. At current balances, rates and reserve factors the deployment generates under $5k per quarter in protocol revenue, which does not cover the cost of maintaining oracles, monitoring and operational support for the market.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nNext steps\n\nWETH\n$1.5M\n$169k\n50%\nFrozen, supply cap of 1, borrow cap of 1\nYes\nGeneral + E-Mode\nRaise RF to 99% and set IRM base rate to 5%\n\nweETH\n$312k\n$11k\n85%\nFrozen, supply cap of 1\nNo\nGeneral + E-Mode\nRaise RF to 99% and set IRM base rate to 5%\n\nUSDC\n$311k\n$226k\n85%\nFrozen, supply cap of 1, borrow cap of 1\nYes\nGeneral\nRaise RF to 99% and set IRM base rate to 5%\n\nwstETH\n$93k\n$17k\n85%\nFrozen, supply cap of 1\nNo\nGeneral + E-Mode\nRaise RF to 99% and set IRM base rate to 5%\n\nSCR\n$14k\n$52\n85%\nFrozen, supply cap of 1\nNo\nNon-collateral\nRaise RF to 99% and set IRM base rate to 5%\n\nAave V3 Scroll aggregate supply and borrow2160×1080 138 KB\nSource: LlamaRisk, July 28th, 2026\nzkSync\nDeposits on the zkSync deployment have fallen from $7.2M to $844k over the trailing six months, a decline of 88%, and $235k remains borrowed. At current balances, rates and reserve factors the deployment generates under $5k per quarter in protocol revenue, which does not cover the cost of maintaining oracles, monitoring and operational support for the market.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nNext steps\n\nWETH\n$383k\n$104k\n15%\nFrozen, borrow cap of 1\nYes\nGeneral + E-Mode\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nZK\n$213k\n$138\n20%\nFrozen, borrow cap of 1\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nUSDC\n$102k\n$112k\n10%\nFrozen, borrow cap of 1\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nweETH\n$106k\n$0\n45%\nFrozen\nNo\nGeneral + E-Mode\nSet caps to 1. Monitor, residual immaterial\n\nUSDT\n$22k\n$19k\n10%\nFrozen, borrow cap of 1\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nwstETH\n$18k\n$234\n5%\nFrozen, borrow cap of 1\nYes\nGeneral + E-Mode\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nwrsETH\n$71\n$0\n10%\nFrozen, supply cap of 1\nNo\nGeneral + E-Mode\nMonitor, residual immaterial\n\nsUSDe\n$127\n$0\n20%\nFrozen\nNo\nGeneral\nSet caps to 1. Monitor, residual immaterial\n\nAave V3 zkSync aggregate supply and borrow2160×1080 108 KB\nSource: LlamaRisk, July 28th, 2026\nMetis\nDeposits on the Metis deployment have fallen from $1.4M to $297k over the trailing six months, a decline of 79%, and $31k remains borrowed. At current balances, rates and reserve factors the deployment generates under $1k per quarter in protocol revenue, which does not cover the cost of maintaining oracles, monitoring and operational support for the market.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nNext steps\n\nMetis\n$77k\n$216\n15%\nFrozen, borrow cap of 1\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nm.USDT\n$82k\n$8k\n10%\nFrozen, borrow cap of 1\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nm.USDC\n$74k\n$21k\n10%\nFrozen, borrow cap of 1\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nWETH\n$42k\n$2k\n15%\nFrozen\nNo\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nm.DAI\n$21k\n$394\n25%\nFrozen\nNo\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nAave V3 Metis aggregate supply and borrow2160×1080 95.7 KB\nSource: LlamaRisk, July 28th, 2026\nSoneium\nDeposits on the Soneium deployment have fallen from $3.2M to $173k over the trailing six months, a decline of 95%, and $38k remains borrowed. At current balances, rates and reserve factors the deployment generates under $1k per quarter in protocol revenue, which does not cover the cost of maintaining oracles, monitoring and operational support for the market.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nNext steps\n\nWETH\n$124k\n$8k\n15%\nFrozen, borrow cap 720 WETH\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nUSDC.e\n$42k\n$30k\n10%\nFrozen, borrow cap 7,200,000 USDC.e\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nUSDT\n$7k\n$536\n10%\nFrozen, borrow cap 4,500,000 USDT\nYes\nGeneral\nSet caps to 1 and raise RF to 99% and set IRM base rate to 5%\n\nAave V3 Soneium aggregate supply and borrow2160×1080 103 KB\nSource: LlamaRisk, July 28th, 2026\nAptos\nAvailable liquidity across the Aptos reserves has moved from $18.0M to $1.0M over the trailing six months (-94%, DefiLlama pool TVL, supply net of borrows). The market carries about $1.7M of supply and $719k of debt, and at current balances and reserve factors it generates under $1k per quarter in protocol revenue, which does not cover the cost of maintaining the market.\n\nAsset\nSupplied\nBorrowed\nRF\nState\nBorrowable\nCollateral\nNext steps\n\nUSDT\n$1.2M\n$672k\n10%\nActive, borrow cap 448,000 USDT\nYes\nGeneral + E-Mode\nFreeze reserve, set caps to 1, raise RF to 99% and set IRM base rate to 5%\n\nAPT\n$351k\n$8k\n20%\nActive, borrow cap 8,370 APT\nYes\nGeneral\nFreeze reserve, set caps to 1, raise RF to 99% and set IRM base rate to 5%\n\nUSDC\n$156k\n$40k\n10%\nActive, borrow cap 33,000 USDC\nYes\nGeneral + E-Mode\nFreeze reserve, set caps to 1, raise RF to 99% and set IRM base rate to 5%\n\nsUSDe\n$5k\n$0\n20%\nActive\nNo\nGeneral + E-Mode\nFreeze reserve and set caps to 1\n\nAave V3 Aptos aggregate supply and borrow2160×1080 143 KB\nSource: LlamaRisk, July 28th, 2026\nSpecial cases\n\nMaticX on Polygon is in scope for issuer wind-down, with Stader sunsetting the token. Its Aave oracle is an exchange-rate adapter that values MaticX at its fixed MATIC redemption rate times the MATIC/USD feed, so it already tracks the asset’s redemption value, and roughly $0.6M of MATIC-correlated debt is backed by MaticX collateral that stays correctly valued as MATIC moves. MaticX is already at LTV of 0 and borrow-disabled, and is wound down on the standard basis.\n\nNext Steps\nFor the whole-market deprecations the sequence continues beyond this proposal: once the RF and rate changes have forced the remaining positions to unwind further, the oracles on those deployments will be deprecated in the same way as in the oracle deprecation ARFC, fixing each feed so the market can be retired completely.\nFor the individual reserve removals no further parameter work is expected beyond IRM adjustments, applied later only where borrowers have not responded to the initial changes or if the reserve becomes stressed.\nSpecification\nWhenever a reserve is frozen its supply and borrow caps are also reduced to 1, and already-frozen reserves have their caps reduced to 1 where they are not already, so every deprecated reserve ends in the same terminal state as in the companion oracle deprecation ARFC.\nAave V3 Ethereum Core\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nFBTC\nNo\nYes\n175 / 1\n1 / 1\n50%\n75%\n\nezETH\nNo\nYes\n3,330 / 1\nn/a / 1\nn/a\nn/a\n\neUSDe\nNo\nYes\n1 / 1\n1 / 1\n45%\nn/a\n\nETHx\nNo\nYes\n1 / 1\n1 / 1\n15%\n50%\n\nMatured PTs (15)\nNo\nYes\n1 / 1\n1 / 1\nn/a\nn/a\n\nCRV\nNo\nYes\n11,000,000 / 1\n1 / 1\n35%\n50%\n\nUNI\nNo\nYes\n1,500,000 / 1\n1 / 1\n20%\n50%\n\n1INCH\nNo\nYes\n7,000,000 / 1\n1 / 1\n20%\n50%\n\ncrvUSD\nNo\nYes\n1 / 1\n1 / 1\n20%\n50%\n\nMKR\nYes\nYes\n1 / 1\n1 / 1\n20%\n50%\n\nENS\nNo\nYes\n50,000 / 1\n1 / 1\n20%\n50%\n\nSNX\nNo\nYes\n1 / 1\n1 / 1\n95%\n99%\n\nsDAI\nNo\nYes\n1 / 1\nn/a / 1\nn/a\nn/a\n\nAave V3 Ethereum Prime\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nezETH\nNo\nYes\n150 / 1\n1 / 1\n15%\nNo change\n\nUSDS\nNo\nYes\n1 / 1\n1 / 1\n25%\n50%\n\nsUSDe\nNo\nYes\n3,000,000 / 1\n1 / 1\n10%\nNo change\n\nAave V3 Arbitrum\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nDAI\nNo\nYes\n4,900,000 / 1\n4,410,000 / 1\n25%\n50%\n\nrETH\nNo\nYes\n1,300 / 1\n1 / 1\n15%\n50%\n\ntBTC\nNo\nYes\n35 / 1\n1 / 1\n20%\nn/a\n\nUSDC.e\nNo\nYes\n1,700,000 / 1\n1,530,000 / 1\n50%\n75%\n\nezETH\nNo\nYes\n66 / 1\n1 / 1\n15%\nNo change\n\nEURS\nYes\nYes\n80,000 / 1\n65,000 / 1\n20%\n50%\n\nAave V3 Plasma\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nMatured PTs (6)\nNo\nYes\n1 / 1\n1 / 1\nn/a\nn/a\n\nWETH\nNo\nYes\n1 / 1\n1 / 1\n15%\n50%\n\nweETH\nNo\nYes\n10,000 / 1\n1 / 1\n20%\nn/a\n\nwstETH\nYes\nYes\n20,000 / 1\n5,000 / 1\n35%\n50%\n\nAave V3 Base\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\ntBTC\nNo\nYes\n8 / 1\n1 / 1\n20%\n50%\n\nezETH\nNo\nYes\n23 / 1\n1 / 1\n15%\nNo change\n\nUSDbC\nNo\nYes\n500,000 / 1\n450,000 / 1\n50%\n75%\n\nAave V3 Polygon\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nUSDC.e\nNo\nYes\n4,390,000 / 1\n3,950,000 / 1\n60%\n85%\n\nEURS\nNo\nYes\n1 / 1\n1 / 1\n99%\n99%\n\nMaticX\nNo\nYes\n9,330,000 / 1\n1 / 1\n20%\n50%\n\njEUR\nYes\nYes\n120,000 / 1\n100,000 / 1\n20%\n50%\n\nstMATIC\nYes\nYes\n61,000,000 / 1\nn/a / 1\nn/a\nn/a\n\nEURA\nYes\nYes\n300,000 / 1\n250,000 / 1\n20%\n50%\n\nDPI\nYes\nYes\n1,417 / 1\n779 / 1\n35%\n50%\n\nSUSHI\nYes\nYes\n299,320 / 1\n180,000 / 1\n20%\n50%\n\nCRV\nYes\nYes\n1,400,000 / 1\n300,000 / 1\n35%\n50%\n\nAave V3 Avalanche\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nWBTC.e\nYes\nYes\n2,000 / 1\n1,100 / 1\n20%\n50%\n\nLINK.e\nNo\nYes\n155,000 / 1\n1 / 1\n20%\n50%\n\nAAVE.e\nNo\nYes\n7,200 / 1\nn/a / 1\nn/a\nn/a\n\nAave V3 Optimism\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nUSDC.e\nNo\nYes\n1,800,000 / 1\n1 / 1\n50%\n75%\n\nDAI\nNo\nYes\n1,000,000 / 1\n900,000 / 1\n25%\n50%\n\nrETH\nNo\nYes\n450 / 1\n1 / 1\n15%\n50%\n\nAave V3 Gnosis\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nWETH\nNo\nYes\n3,500 / 1\n2,400 / 1\n15%\n50%\n\nUSD//C on xDai\nYes\nYes\n1 / 1\n1 / 1\n80%\n99%\n\nAave V3 BSC\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nwstETH\nNo\nYes\n1 / 1\n1 / 1\n15%\n50%\n\nFDUSD\nNo\nYes\n1,200,000 / 1\n1,080,000 / 1\n20%\n50%\n\nCake\nNo\nYes\n600,000 / 1\n1 / 1\n20%\n50%\n\nAave V3 MegaETH\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\n\nezETH\nNo\nYes\n1 / 1\n1 / 1\n20%\nNo change\n\nUSDT0\nNo\nYes\n10,000,000 / 1\n9,000,000 / 1\n10%\n50%\n\nWhole-market deployments\nEvery reserve on each of these deployments is frozen with caps reduced to 1. Reserves that carry a borrow have the RF raised to 99% and the IRM base variable rate set to 5%.\nAave V3 Sonic\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\nCurrent IRM base rate\nRecommended IRM base rate\n\nUSDC\nNo\nYes\n2,170,000 / 1\n1,050,000 / 1\n10%\n99%\n0%\n5%\n\nwS\nNo\nYes\n59,100,000 / 1\n36,100,000 / 1\n15%\n99%\n0%\n5%\n\nstS\nNo\nYes\n50,300,000 / 1\n1 / 1\n10%\nn/a\n0%\nn/a\n\nWETH\nNo\nYes\n556 / 1\n97 / 1\n15%\n99%\n0%\n5%\n\nAave V3 Scroll\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\nCurrent IRM base rate\nRecommended IRM base rate\n\nWETH\nYes\nYes\n1 / 1\n1 / 1\n50%\n99%\n0%\n5%\n\nweETH\nYes\nYes\n1 / 1\n1 / 1\n85%\n99%\n1%\n5%\n\nwstETH\nYes\nYes\n1 / 1\n1 / 1\n85%\n99%\n0%\n5%\n\nUSDC\nYes\nYes\n1 / 1\n1 / 1\n85%\n99%\n0%\n5%\n\nSCR\nYes\nYes\n1 / 1\n1 / 1\n85%\n99%\n0%\n5%\n\nAave V3 zkSync\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\nCurrent IRM base rate\nRecommended IRM base rate\n\nWETH\nYes\nYes\n600 / 1\n1 / 1\n15%\n99%\n0%\n5%\n\nweETH\nYes\nYes\n200 / 1\n1 / 1\n45%\nn/a\n0%\nn/a\n\nwstETH\nYes\nYes\n500 / 1\n1 / 1\n5%\n99%\n0%\n5%\n\nwrsETH\nYes\nYes\n1 / 1\n1 / 1\n10%\nn/a\n0%\nn/a\n\nZK\nYes\nYes\n45,000,000 / 1\n1 / 1\n20%\n99%\n0%\n5%\n\nUSDC\nYes\nYes\n800,000 / 1\n1 / 1\n10%\n99%\n0%\n5%\n\nUSDT\nYes\nYes\n150,000 / 1\n1 / 1\n10%\n99%\n0%\n5%\n\nsUSDe\nYes\nYes\n110 / 1\n1 / 1\n20%\nn/a\n0%\nn/a\n\nAave V3 Metis\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\nCurrent IRM base rate\nRecommended IRM base rate\n\nMetis\nYes\nYes\n80,000 / 1\n1 / 1\n15%\n99%\n0%\n5%\n\nm.USDT\nYes\nYes\n250,000 / 1\n1 / 1\n10%\n99%\n0%\n5%\n\nm.USDC\nYes\nYes\n400,000 / 1\n1 / 1\n10%\n99%\n0%\n5%\n\nWETH\nYes\nYes\n150 / 1\n1 / 1\n15%\n99%\n1%\n5%\n\nm.DAI\nYes\nYes\n25,000 / 1\n1 / 1\n25%\n99%\n0%\n5%\n\nAave V3 Soneium\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\nCurrent IRM base rate\nRecommended IRM base rate\n\nWETH\nYes\nYes\n800 / 1\n720 / 1\n15%\n99%\n0%\n5%\n\nUSDC.e\nYes\nYes\n8,000,000 / 1\n7,200,000 / 1\n10%\n99%\n0%\n5%\n\nUSDT\nYes\nYes\n5,000,000 / 1\n4,500,000 / 1\n10%\n99%\n0%\n5%\n\nAave V3 Aptos\n\nAsset\nCurrent frozen\nRecommended frozen\nSupply cap (current / new)\nBorrow cap (current / new)\nCurrent RF\nRecommended RF\nCurrent IRM base rate\nRecommended IRM base rate\n\nUSDT\nNo\nYes\n1,040,000 / 1\n448,000 / 1\n10%\n99%\n0%\n5%\n\nAPT\nNo\nYes\n415,000 / 1\n8,370 / 1\n20%\n99%\n0%\n5%\n\nUSDC\nNo\nYes\n144,000 / 1\n33,000 / 1\n10%\n99%\n0%\n5%\n\nsUSDe\nNo\nYes\n2,600 / 1\nn/a / 1\n20%\nn/a\n0%\nn/a\n\nDisclosure\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\nChangelog:\n2026-08-11 EtherFi has committed to grow the eBTC reserve significantly in the coming weeks, therefore, it has been decided to remove the asset from the deprecation list on Aave Core market\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n [ARFC] Sunset the Aptos Bug Bounty program and Cantina as a provider\n\n LlamaRisk - Monthly Community Update\n\n AL Development Update | September 2026\n\n Aribitrum RemoteGSM pairs GHO with USDC.e\n\n 3\n\n 2\n\n 2\n\n read \n\n 15\n min\n\n post by menaskop on Jul 30\n\n menaskop\n\n I believe this proposal is entirely reasonable. The current crypto-winter has demonstrated that optimizing all forms of transaction costs is one of the most effective ways to improve not only a project’s tokenomics but also its overall economic sustainability.\nMoreover, efficiency should always be evaluated not only at the asset level but also at the protocol and blockchain levels. I refer to this as the CPD-framework: Chain, Protocol, dApp. From this perspective, there is little value in overloading the Aave interface by maintaining support for networks that see little to no meaningful usage.\nPreviously, there was also a more comprehensive proposal regarding the optimization of the process for onboarding new networks and assets. I believe this deserves separate discussion, as it represents an important and substantial topic on its own.\nIt is also worth noting that following the non-technical rsETH incident, the issue of exposure to different tokens and coins has become significantly more important and has provided valuable lessons for the Aave DAO community. As a result, the rationale behind this proposal has become even stronger.\n\n post by Achthar on Jul 30\n\n Achthar\n\n But would it not make more sense to first look whether there are other players that would be willing to run the V3 instances (e.g. like on HyperEVM) that are to be deprecated.\nThe DAO would still generate (sometimes very minor) revenue streams but not have the overhead.\nOne would just need to find teams that would be willing to take this over (e.g. allow for a few months - if nobody is found by then - it can be shut down).\n\n post by menaskop on Jul 30\n\n menaskop\n\n How would this work technically in practice? I mean, what would the actual implementation look like? (You can use any of the examples mentioned above.)\nAnd my second question: who would be responsible for the security of users’ assets and the protocol overall in that case?\n\n post by Achthar on Jul 30\n\n Achthar\n\n It is just an idea - of course, defining every step in detail would require much much more research, but potentially one could do what Maker/Sky has done via their SubDAOs\n\nPost that the DAO is looking for a team to manage the Aave deployment on chain X - this should be helped by the network itself (if not, the idea dies right here) if they think it is in their own interest to keep a major lender on their chain\nUser’s opinions matter here and polls should be made to get a sentiment on whether they would just withdraw if someone else would take over (if they would, the idea is dead here)\nInfrastructure considerations: oracle provider change/handover needs to be defined (reach out to providers and find a working solution for continuation if needed)\nOnce a initial team is found, create a new DAO that will have a the similar role as the HyperLend team has on their deployment\nOne can issue the new governance token to users and initial backers plus a large chunk to the Aave DAO - this would set up the initial governance\nAave’s role would be reduced to a sole code license provider / lending infra provider and the deployment in question would be rebranded\n\nThis would apply to the examples where the TVL is not too small and there are specific economic opportunities (e.g. leveraged staking that does not exist elsewhere) where Aave V3 is stronger than most other solutions.\nI do not have the knowledge about how easy it would be to find teams or collaborators to make this work - this requires comprehensive research and outreach. Due to the limited amount of assets (especially derivatives) on the chains in question, I would assume that a rather lean team can manage them.\nI think Aave benefits more from authorized forks and active collaborations rather than other teams starting to fork the Aave V3 code.\n\n post by menaskop on Jul 30\n\n menaskop\n\n I understand your point, but I think this is more the scope of a standalone proposal than a comment. It would also require at least some of the research to be done upfront - for example, identifying which networks and asset classes such an approach could actually make economic sense for.\nOtherwise, I understand the idea. Let’s see whether anyone is interested in taking it further.\n\n post by kinetickoala on Jul 30\n\n kinetickoala\n\n i get what you are trying to do, but are the costs really that high?\nhopefully this is given enough time so people can make new markets elsewhere\n\n 12 days later\n\n post by LlamaRisk on Aug 12\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This ARFC has been moved to the voting stage on Snapshot.\n\n post by Abel189 on Aug 12\n\n Abel189\n\n One aspect I find particularly important is the monitoring phase after the initial deprecation parameters are applied. For markets with meaningful outstanding debt, such as DAI and USDC.e on Arbitrum or WETH on Gnosis, it would be useful to understand what specific metrics or thresholds will trigger the next step of the wind-down (higher IRM, further LT reductions, etc.). A clearly defined monitoring framework could make the transition more predictable while still allowing the risk team to react to borrower behaviour and remaining liquidity.\n\n 1 month later\n\n Closed on Sep 11\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n post by AaveLabs on Sep 16\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The AIP for this proposal was successfully created, proposal#521, voting will start in less than 12hs.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Oracle Deprecation for Long-tail Assets Across Aave V2 and V3\n\n Governance\n\n 3\n\n 527\n\n Aug 12\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n EzR3aL Delegate Platform\n\n Delegate Platforms\n\n 43\n\n 5.1k\n\n Jun 30\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.07\n\n Risk\n\n 0\n\n 167\n\n Sep 7","tokens":9793,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265212965,"hash":"bb1cc18cba1a326a86f2cb49e0f777a9026f412e"}
{"url":"https://docs.base.org/get-started/make-a-transaction","domain":"docs.base.org","title":"Make a Transaction - Base Documentation","text":"Base uses the same transaction model as Ethereum, so any EVM library works. Here’s a minimal send using viem.\n​Send a Transaction\nsend.tsimport { createWalletClient, http, parseEther } from 'viem';\nimport { privateKeyToAccount } from 'viem/accounts';\nimport { base } from 'viem/chains';\n\nconst account = privateKeyToAccount('0xYourPrivateKey');\n\nconst client = createWalletClient({\n account,\n chain: base,\n transport: http('https://mainnet.base.org'),\n});\n\nconst hash = await client.sendTransaction({\n to: '0xRecipientAddress',\n value: parseEther('0.001'),\n});\n\nconsole.log(`Sent, view at https://basescan.org/tx/${hash}`);\n\nNever hardcode or expose a private key. '0xYourPrivateKey' is a placeholder. Load the key from an environment variable or a secrets manager, keep it server-side, and never commit it to source control.\nTransactions confirm in under a second on Base thanks to Flashblocks, and typically cost a fraction of a cent in gas.\n​Next Steps\nWas this page helpful?Suggest editsRaise issue","tokens":251,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265222981,"hash":"5e6d8c76c1d8f6de0895ca991e6bf297a33835c2"}
{"url":"https://forum.soliditylang.org/t/what-solidity-try-catch-actually-catches/3705/2","domain":"forum.soliditylang.org","title":"What Solidity try/catch actually catches - Code Wizards - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Code Wizards\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 22\n\n 2 / 2\n\n May 30\n\n May 29\n\n post by researchzero on May 22\n\n researchzero\n\n I have been looking into some edge cases around Solidity try/catch.\nThe main point is that try/catch only catches failures from the external call or contract creation expression itself. Some failures around that expression can still revert the caller and bypass the catch block entirely.\nA few examples:\n\nReverts inside the external call can be caught.\n\nPanic errors such as assert failures or arithmetic errors inside the external call can be caught with catch Panic(uint256).\n\nCustom errors and unknown revert data can be handled with catch (bytes memory).\n\nErrors while evaluating arguments before the call are not caught.\n\nErrors while decoding return data may bypass the catch block.\n\nCalls to addresses without contract code can behave differently than people expect because Solidity inserts checks before high-level external calls.\n\nThis matters when contracts use try/catch for “safe” integrations with unknown or optional external contracts. The catch block may not be a complete safety net unless the call boundary and ABI assumptions are handled carefully.\nCurious if others here have run into try/catch edge cases in audits or production code.\n\n post by red-swan on May 29\n\n red-swan\n\n It’s something that often surprises folks. I’ve seen bugs from time to time that deal with it. I don’t remember where but there was a batch caller that was meant to send out rewards and it looped through all the contracts trying to call them to receive the NFT or 1155 token or something. But if one was an EOA the function would revert trying to get to the try/catch and not be caught So you could DOS the contract by putting an EOA in the list of contracts to send rewards to.\nThere was a lightning talk about it in the last DSS that I like: youtube watch?v=XqzIw_r8JU8\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n abi.encodeCall consistently generates cheaper gas than abi.encodeWithSelector is this by design?\n\n Code Wizards\n\n 1\n\n 82\n\n Jun 22\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 82\n\n Jun 2\n\n Want to read more? Browse other topics in Code Wizards or view latest topics.","tokens":1503,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265223028,"hash":"5ff843ced1e7a9e6e04f7904a803962d7c385d51"}
{"url":"https://governance.aave.com/t/risk-stewards-cap-and-irm-changes-on-aave-v3-2026-09-07/25601","domain":"governance.aave.com","title":"Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.07 - Risk - Aave","text":"Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.07 \n\n Risk\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Summary\n\n USDC (Aave V3 Core)\n\n Supply Distribution\n\n Borrow Distribution\n\n Recommendation\n\n wstETH (Aave V3 Prime)\n\n Supply Distribution\n\n Recommendation\n\n GHO (Aave V3 Monad)\n\n Supply Distribution\n\n Borrow Distribution\n\n Recommendation\n\n USD₮0 (Aave V3 X Layer)\n\n Cap Decreases\n\n syrupUSDC (Aave V3 Monad)\n\n USDe (Aave V3 Monad)\n\n syrupUSDT (Aave V3 Plasma)\n\n USDe Interest Rate Model\n\n USDe Debt Migration\n\n Specification\n\n Caps\n\n IRM\n\n Next Steps\n\n Disclosure\n\n Sep 7\n\n 1 / 1\n\n Sep 7\n\n Sep 7\n\n post by LlamaRisk on Sep 7\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk recommends the following parameter changes based on user behavior, on-chain liquidity, and position health observed in the latest review of Aave V3 reserves.\n\nIncrease the USDe base rate by 1% and decrease Slope1 by 1% on Core, Plasma, Monad, Mantle, and Avalanche.\nIncrease USDC supply and borrow caps on Core.\nIncrease GHO caps and decrease syrupUSDC and USDe supply caps on Monad.\nDecrease the syrupUSDT supply cap on Plasma.\nIncrease the USDT0 borrow cap on X Layer.\n\nUSDC (Aave V3 Core)\nUSDC sits at 92.4% supply cap utilization, and 95.7% borrow cap utilization (2,153,878,518 / 2,250,000,000), for a reserve utilization of 93.3% against a 94.00% optimal utilization point. Both sides grew over the seven days to September 7, with supply up 1.4% and debt up 4.7%.\nSupply Distribution\nimage2880×1440 268 KB\nSource: LlamaRisk, September 7, 2026\nThe top twenty suppliers hold 31.8% of the reserve, with the largest at 8.4% and the top five at 22.2%, so the supply side is dispersed rather than dependent on any one depositor. Three of the twenty carry debt, and the remainder supply on a spot basis, which reads as cash lending into the reserve’s borrow yield rather than collateral posted to loop.\nBorrow Distribution\nimage2880×1440 303 KB\nSource: LlamaRisk, September 7, 2026\nThe top twenty borrowers account for 55.0% of outstanding debt, with the largest at 8.9%, and health factors run from 1.02 to 3.61, with a median of 1.70. The collateral behind that debt is predominantly WETH and cbBTC, followed by wstETH, weETH, and WBTC, so this is stablecoin borrowing against volatile collateral, where the buffer above liquidation absorbs ETH and BTC drawdowns rather than tracking a correlated pair.\nRecommendation\nBoth caps stand within eight percentage points of full utilization, while the reserve trades just below its optimal utilization point. The proposed supply cap of 3,000,000,000 lands cap utilization at 77.0% and the proposed borrow cap of 2,700,000,000 lands at 79.8%. The borrow cap holds at 0.90x the supply cap.\nwstETH (Aave V3 Prime)\nwstETH sits at 100.0% supply cap utilization (61,996/62,000), leaving approximately 4 wstETH in deposit headroom. The supplied balance grew 7.8% over the seven days to September 7.\nSupply Distribution\nimage2880×1440 263 KB\nSource: LlamaRisk, September 7, 2026\nThe top twenty suppliers hold 92.5% of the reserve, with the largest at 34.1% and the top five at 72.7%, so the reserve is concentrated in a small set of positions. Sixteen of the twenty carry debt, with health factors between 1.02 and 3.12, with a median of 1.06, borrowing GHO and WETH againstwstETH collateral. The low HF cluster is the expected steady state for a wstETH and WETH pairing, where both legs are ETH-denominated and the HF only improves with the exchange rate over time.\nRecommendation\nThe proposed cap of 80,000 is approximately 1.29x the current outstanding supply, resulting in approximately 77.5% post-change cap utilization. The borrow cap is unchanged.\nGHO (Aave V3 Monad)\nGHO sits at 92.4% supply cap utilization and 91.1% borrow cap utilization. Both sides grew over the seven days to September 7, with supply up 26.5% and debt up 37.5%.\nSupply Distribution\nimage2880×1440 262 KB\nSource: LlamaRisk, September 7, 2026\nThe top twenty suppliers hold 97.6% of the reserve, with the largest at 31.7% and the top five at 86.2%. Two of the twenty carry debt, and the remainder supply on a spot basis, so the supply side is close to entirely passive deposits earning the borrow yield, concentrated enough that the cap binds on the behavior of a small number of addresses.\nBorrow Distribution\nimage2880×1440 290 KB\nSource: LlamaRisk, September 7, 2026\nThe top twenty borrowers account for 91.0% of outstanding debt, with the largest at 31.4%, and every one of them borrows against stablecoin collateral, principally USDe, followed by PT-AUSD-8OCT2026 and syrupUSDC. Health factors range from 1.01 to 1.13, with a median of 1.03, the expected steady state for a correlated stablecoin pair where both legs are dollar-denominated.\nRecommendation\nBoth caps stand within nine percentage points of full utilization while demand on both sides continues to grow, so each is raised by 50%. The proposed supply cap of 60,000,000, land cap utilization at 61.6%, and the proposed borrow cap of 54,000,000, at 60.7%. The borrow cap holds at 0.90x the supply cap.\nUSD₮0 (Aave V3 X Layer)\nUSD₮0 sits at 100.0% borrow cap utilization, so the cap is fully drawn and no further borrowing is possible. Outstanding debt grew 103.9% over the seven days to September 7. The supplied balance of 53,256,637 against a 100,000,000 supply cap leaves reserve utilization at 90.1% and available liquidity at 5,276,694.\nThe proposed cap of 90,000,000 lands borrow cap utilization at 53.3% and holds 0.90x the supply cap. Because the proposed cap exceeds the supplied balance, the borrow cap is no longer the binding constraint. Currently, available liquidity is 9.9% of the supplied balance, so withdrawals beyond that amount depend on repayment drawn by the higher rate.\nCap Decreases\nAll three reductions follow the same pattern, on Aave V3 Monad and Aave V3 Plasma, where the supplied balance has drawn down well below a cap sized for a larger reserve.\nsyrupUSDC (Aave V3 Monad)\nsyrupUSDC sits at 42.4% supply cap utilization, with the supplied balance down 11.5% over the seven days to September 7 and no approach to the cap at any point in that window. The proposed cap of 150,000,000 is approximately 1.48x the current outstanding supply, resulting in a cap utilization of 67.8% and retaining 48.3M in headroom.\nUSDe (Aave V3 Monad)\nUSDe sits at 41.3% supply cap utilization, with the supplied balance down 24.2% over the seven days to September 7, a period in which the base rate moved from 2.00% to 4.00%. Outstanding debt of 21,651,993 against a 36,000,000 borrow cap leaves reserve utilization at 23.8%. The proposed cap of 150,000,000 is approximately 1.65x the current outstanding supply, resulting in a cap utilization of 60.6%, with the borrow cap unchanged.\nsyrupUSDT (Aave V3 Plasma)\nsyrupUSDT sits at 37.6% supply cap utilization, with the supplied balance down 27.1% over the seven days to September 7. The proposed cap of 150,000,000 is approximately 1.33x the current outstanding supply, resulting in a cap utilization of 75.2% and retaining 37.2M in headroom.\nUSDe Interest Rate Model\nThe recommendation raises the USDe base rate by 100 BPS on all five deployments that carry USDe, continuing the move toward the 5.25% base rate set out in the stablecoin interest rate changes proposed by TokenLogic, which prices USDe borrowing in line with Ethena’s native staking rate. Each deployment pairs the base increase with a 100 BPS Slope1 reduction, continuing the blend toward the 0.25% Slope1 in the same proposal.\n\nInstance\nUtilization\nuOptimal\nCurrent Borrow APR\nNew Borrow APR\nDelta\n\nAave V3 Core\n40.9%\n90.0%\n5.36%\n5.91%\n+55 BPS\n\nAave V3 Plasma\n27.7%\n85.0%\n5.30%\n5.98%\n+67 BPS\n\nAave V3 Monad\n23.8%\n90.0%\n5.06%\n5.79%\n+74 BPS\n\nAave V3 Mantle\n14.3%\n85.0%\n4.67%\n5.51%\n+83 BPS\n\nAave V3 Avalanche\n66.5%\n80.0%\n6.49%\n6.66%\n+17 BPS\n\nBecause the optimal utilization point is unchanged on all five reserves, the share of supply held as withdrawal liquidity at that point is unchanged.\nUSDe Debt Migration\nThe base rate has moved in four steps so far, from 0.00% to 1.00% on August 28, to 2.00% on September 1, to 3.00% on September 3, and to 4.00% on September 5. The figures below cover the window from the fourth step to the current block, approximately 58 hours on both markets.\n\nInstance\nUSDe debt reduced\nRe-borrowed other stablecoins\nShare\nNot re-borrowed\n\nAave V3 Core\n38.8M\n7.7M\n19.8%\n31.1M\n\nAave V3 Plasma\n24.7M\n0.4M\n1.7%\n24.3M\n\nOn Aave V3 Core, 94 accounts reduced their USDe debt by 38.8M in aggregate. Of that reduction, 7.7M was replaced by USDC or USDT borrowing from the same accounts, across 25 accounts. A further 69 accounts repaid 30.8M without taking on other stablecoin debt on the same market. Within that group, accounts that still carry debt in other reserves account for 25.0M of the repayment, accounts that still hold collateral but no debt for 0.2M, and accounts that now have no position on the market at all for 5.6M. On Aave V3 Plasma, 25 accounts reduced USDe debt by 24.7M, and the equivalent residual repayment of 24.2M breaks down into 21.5M from accounts that continue to borrow and 2.7M from accounts that no longer have a position.\nMeasured this way, accounts that left Aave V3 Core entirely represent approximately 14% of the USDe debt reduction on that market, and approximately 11% on Aave V3 Plasma.\nSpecification\nCaps\n\nInstance\nAsset\nCurrent Supply Cap\nRecommended Supply Cap\n\nAave V3 Monad\nsyrupUSDC\n240,000,000\n150,000,000\n\nAave V3 Monad\nGHO\n40,000,000\n60,000,000\n\nAave V3 Monad\nUSDe\n220,000,000\n150,000,000\n\nAave V3 Plasma\nsyrupUSDT\n300,000,000\n150,000,000\n\nAave V3 Core\nUSDC\n2,500,000,000\n3,000,000,000\n\nAave V3 Prime\nwstETH\n62,000\n80,000\n\nInstance\nAsset\nCurrent Borrow Cap\nRecommended Borrow Cap\n\nAave V3 Monad\nGHO\n36,000,000\n54,000,000\n\nAave V3 X Layer\nUSD₮0\n48,000,000\n90,000,000\n\nAave V3 Core\nUSDC\n2,250,000,000\n2,700,000,000\n\nIRM\n\nInstance\nAsset\nCurrent Base Variable Rate\nRecommended Base Variable Rate\nCurrent Slope 1\nRecommended Slope 1\n\nAave V3 Core\nUSDe\n4.00%\n5.00%\n3.00%\n2.00%\n\nAave V3 Plasma\nUSDe\n4.00%\n5.00%\n4.00%\n3.00%\n\nAave V3 Monad\nUSDe\n4.00%\n5.00%\n4.00%\n3.00%\n\nAave V3 Mantle\nUSDe\n4.00%\n5.00%\n4.00%\n3.00%\n\nAave V3 Avalanche\nUSDe\n4.00%\n5.00%\n3.00%\n2.00%\n\nNext Steps\nWe will move forward and implement these updates via the Risk Steward process. The implemented changes can be reviewed on the LlamaRisk Risk Stewards Dashboard.\nDisclosure\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n read \n\n 4\n min\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.15\n\n Risk\n\n 0\n\n 105\n\n Sep 15\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.08.31\n\n Risk\n\n 0\n\n 198\n\n Aug 31\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.28\n\n Risk\n\n 0\n\n 111\n\n 8d\n\n Risk Stewards: Cap Adjustments on Aave V3 / 2026.05.06\n\n Risk\n\n 1\n\n 203\n\n May 6\n\n Risk Stewards: Supply and Borrow Cap Changes on Aave V3 / 2026.07.30\n\n Risk\n\n 0\n\n 134\n\n Jul 30","tokens":2856,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265225392,"hash":"9a53c7b6eb8f304909b930eae32ca45e931fc5c3"}
{"url":"https://forum.soliditylang.org/t/localization-of-the-solidity-documentation/3708/1","domain":"forum.soliditylang.org","title":"Localization of The Solidity Documentation - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Localization of The Solidity Documentation \n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by hwhsu1231 on Jun 2\n\n hwhsu1231\n\n Hello Solidity Community,\nI am the author of the Localize The Docs organization. And I’m glad to announce that the solidity-docs-l10n project is published now:\n\n Preview: solidity-docs-l10n\n Crowdin: solidity-docs-l10n\n GitHub: solidity-docs-l10n\n\nThe goal of this project is to translate The Solidity Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.\nWe welcome anyone interested in documentation translation to join us. If the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!\nSee the announcement post for more details.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n Documentation\n\n 2\n\n 148\n\n Jun 2\n\n Diamond Contract Gas Efficiency Challenge\n\n Code Wizards\n\n 0\n\n 110\n\n Oct 2025\n\n The assembly/solidity distinction was a mistake, don’t repeat in Solidity Core!\n\n Language Design\n\n 5\n\n 378\n\n Feb 26\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1248,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265245095,"hash":"d7839929d029fadbef90130df6cf4060a86ffcde"}
{"url":"https://governance.aave.com/t/core-wallet-on-avalanche-v3-forces-unnecessary-ethereum-network-switch/25487","domain":"governance.aave.com","title":"Core Wallet on Avalanche V3 forces unnecessary Ethereum network switch - Other / Site Feedback - Aave","text":"Core Wallet on Avalanche V3 forces unnecessary Ethereum network switch \n\n OtherSite Feedback\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 15\n\n 1 / 3\n\n Aug 15\n\n Aug 17\n\n post by aljariemo on Aug 15\n\n aljariemo\n\n I am posting this here because I could not find an existing issue describing this exact Core + Avalanche V3 connection behavior.\nI am using Aave V3 on Avalanche exclusively, with the Core browser extension.\nThere appears to be an unnecessary network-switch requirement during wallet connection.\nSteps to reproduce\n\nOpen the Core browser extension.\nSet the active network to Avalanche C-Chain.\nOpen app.aave.com.\nSelect Avalanche Market V3.\nConfirm that the Aave interface is already displaying the Avalanche market.\nSelect Connect Wallet → Core.\nDuring the connection process, Core displays:\n\n“app.aave.com is requesting to switch your active network to Ethereum.”\n\nIf I reject the Ethereum network switch, the Core/Aave wallet connection fails.\nIf I approve the switch to Ethereum, the wallet connects successfully.\nWhen I later initiate an Aave transaction on Avalanche, I then have to switch the wallet back from Ethereum to Avalanche C-Chain.\n\nExpected behavior\nBecause:\n\nAave is already set to Avalanche Market V3\nCore is already connected to Avalanche C-Chain\nall of my Aave activity is on Avalanche\n\nthe wallet connection should initialize directly on Avalanche C-Chain (chain ID 43114).\nThere should be no need to switch to Ethereum Mainnet during the initial connection and then switch back to Avalanche for the transaction.\nActual behavior\nThe current sequence is:\nCore on Avalanche → Aave Avalanche V3 → Connect Core → forced Ethereum switch → wallet connects → initiate Avalanche transaction → switch back to Avalanche\nRejecting the Ethereum switch prevents the wallet from connecting.\nAdditional information\n\nWallet: Core browser extension\ndApp: app.aave.com\nMarket: Aave V3 Avalanche\nIntended network: Avalanche C-Chain\nEthereum transactions involved: None\nETH gas involved: None\nIssue is reproducible consistently.\n\nI have attached a screenshot showing Aave already on the Avalanche V3 market while Core simultaneously reports that app.aave.com is requesting a switch to Ethereum.\nCould you please confirm whether this Ethereum-first connection behavior is intentional?\nIf not, could the wallet connection logic use the currently selected Aave market / current wallet chain when initializing the Core connection, so Avalanche users can connect directly on chain ID 43114?\nimage2146×835 156 KB\n\n post by Essah on Aug 17\n\n Essah\n\n Aave Labs-Technical SP\n\n Hi,\nThe Governance Forum is for protocol discussion. For personal support, please use one of our official channels:\nDocs: Aave Protocol Overview\nIn-App: app.aave.com → Get Support (on the bottom of the page)\nEmail: wecare@aave.com\nDiscord: Aave Community → #help\nNote: Aave Labs will never DM you first or ask for your seed phrase or private keys.\nClosing this thread. Our support team is ready to help through the channels above.\n— Aave Labs\n\n Closed on Aug 17\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 1\n\n 158\n\n Sep 16\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21\n\n [ARFC] Low Adoption Asset Deprecation on Aave V3\n\n Governance\n\n 9\n\n 2.1k\n\n Sep 16\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 2\n\n 200\n\n Sep 17\n\n [Temp Check] Deploy Aave V4 on Avalanche\n\n New Market\n\n 7\n\n 1.0k\n\n Aug 28","tokens":904,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265247874,"hash":"60d3f5ca56ff1f68926fd09e1c9b2ababd3c3d2e"}
{"url":"https://ethresear.ch/t/plasma-with-client-side-validation/1103/1","domain":"ethresear.ch","title":"Plasma with client-side validation - Layer 2 / Plasma - Ethereum Research","text":"Plasma with client-side validation \n\n Layer 2Plasma\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n read \n\n 8\n min\n\n Feb 2018\n\n 1 / 9\n\n Feb 2018\n\n Feb 2018\n\n post by danrobinson on Feb 16, 2018\n\n danrobinson\n\n [EDIT: later replies describe a simpler version of this idea without the Plasma elements]\n[EDIT 2: Plasma Cash by Vitalik and Karl Floersch improves significantly on these ideas in the Plasma context.]\nThis post describes an adaptation of Minimal Viable Plasma (MVP) by @vbuterin et al (and assumes familiarity with that post). The adaptation makes use of some of Peter Todd’s ideas around single-use seals and client-side validation. Almost none of the ideas below are original to me (although the mistakes probably are).\nThis approach makes some serious tradeoffs relative to the blockchain structure described in MVP, but it could be a useful configuration for some minority of Plasma chains, particularly for its unique probabilistic “tumbling” capability. Mostly, I wanted to introduce these ideas of Peter’s (which I think deserve wider attention and could have interesting applications in other contexts, such as stateless validation in sharding) to the community, and try to sketch out a design for a working system that would demonstrate them.\nAbstract\nLike Minimal Viable Plasma, client-side Plasma would use a UTXO-based blockchain operated by some owner or owners, whose block headers are committed to the Ethereum blockchain. The primary difference is in the structure of those blocks.\nInstead of transactions including their inputs and outputs in cleartext, they only include a commitment to the outputs, and signatures from the inputs’ public keys. It is the user’s responsibility, when sending a transaction, to also provide the recipient with a recursive proof that the inputs are valid (such as by revealing all hidden information about the full chain of previous transactions, back to the deposit transactions).\nThere is an optimization that can be used to prune part of these proofs. In addition to making these proofs more efficient, this allows you to permanently hide part of a transaction’s history, thus letting users “tumble” funds to obscure their source.\nBenefits\n\nPlasma transactions are even smaller\nPlasma blocks can be validated statelessly. This is particularly important because in Plasma, this is a responsibility of all parties maintaining UTXOs on the chain\nTransactions themselves reveal almost nothing about their sources, destinations, or amounts. Histories eventually need to be revealed, but can be probabilistically pruned before doing so, permanently hiding some history\n\nCosts\n\nExit transactions are larger (approximately O(N) in the average number of steps in the UTXO’s transaction history)\nWould-be challengers need to preserve O(N) storage, where N is the number of transaction inputs in the Plasma chain’s history\nTransacting parties need to maintain and exchange off-chain proofs of not-insignificant size (the exact size depends on the amount of state maintained by the receiving party)\nDishonest users may be able to “gamble” on the chain, with negative expected value but with some risk of hurting depositors or other users\n\nData structures and validity rules\nTransactions\nA transaction is a tuple: (destination, signatures)\nThe public keys—i.e., inputs—for the transaction can be derived from the signatures, with the destination as the message.\nA transaction is valid and can be included in a block if:\n\nthe signatures array is non-empty and valid public keys can be recovered from each of the signatures, or\nthe signatures array is empty, indicating a deposit transaction, it is the only transaction in that block, and there exists a corresponding deposit transaction in the parent chain\n\nA destination is the root of a Merkle sum tree of UTXOs (i.e., a Merkle tree where each intermediate node (and the root) also commits to the sum of the amounts of the UTXOs included in that branch).\nA UTXO is a (salted) commitment to a tuple: sha3(publicKey, amount, salt).\nBlocks\nA block header is a tuple: (height, previousBlockHash, transactionRoot, publicKeyRoot).\nA full block also includes a list of transactions. A block is valid if it contains only a single valid deposit transaction (see above), or if:\n\nThe transactions are all valid\nThe transactions are sorted in ascending order based on their derived public keys (for efficiency of computation of the publicKeyRoot)\nThe derived public keys used in the block are unique within that block\nThe transactionRoot is a Merkle root of the transactions\nThe publicKeyRoot is a Merkle root of the derived public keys in the transactions in the block, sorted in ascending order\n\nA proof of non-inclusion of a public key is a Merkle path to two adjacent public key, showing that there is no transaction spending from a particular public key in that block.\n(There are likely ways to make these proofs smaller using different kinds of trees that commit to the frontiers of public keys rather than the keys themselves, and/or adding probabilistic data structures like Bloom filters to the headers, but we’ll leave those for follow-up posts.)\nLight proof of validity\nA key distinction of this protocol from shared-validation protocols like Bitcoin and Ethereum (but which it shares with some proposals around separating consensus and state execution) is that the mere inclusion of a UTXO in the Plasma blockchain does not prove that the UTXO is valid. To spend a UTXO from the Plasma chain, you need to provide the recipient with an off-chain proof that the UTXO is valid as of the block in which it is spent. Similarly, to withdraw a UTXO from the Plasma chain, you need to prove to the Ethereum chain that the UTXO is valid as of the block in which it is withdrawn.\nA light proof of validity of a UTXO as of block b at height h is:\n\nA proof that the UTXO is included as part of a valid Merkle sum tree path from destination.\nA transaction that includes that destination.\nThe block height h′ of the block b′ in which transaction was included\nThe index of transaction in that block.\nIf transaction's publicKeys list is empty, indicating a deposit transaction, then the proof is complete. If not:\n\nA list of UTXOs, inputs, whose respective publicKeys match the publicKeys in transaction, and whose amounts sum to the total amount committed to by destination.\nA light proof of validity of each UTXO in inputs, as of block b′ at height h′.\n\nA light proof only contains the non-public information needed to validate a transaction. It does not demonstrate everything needed to determine that a UTXO is valid. Specifically, for a UTXO to be valid, the following must also be true:\n\ntransaction was included in the block at height h′ that is in the history of b, and\nthere is no transaction included in a block between blocks b′ and b that spends publicKey.\n\nFortunately, these facts can be verified based on public information, so if a verifier is running (or trusts somebody who is running) an “archival node” for the Plasma chain, they can verify these facts.\nFraud proofs\nAdditionally, if one of those facts is false, any archival node can detect it and construct a relatively efficient fraud proof to demonstrate that fact. This means that a light verifier can satisfy itself as to the validity of a light proof using an incentivized challenge-response protocol. This is how the parent chain verifies the validity of a UTXO for a withdrawal. During the withdrawal waiting period, any party can claim a portion of the withdrawer’s deposit by revealing a Merkle proof that either:\n\na different transaction was included at position index in the block at h′ in b's history (or no transaction at all was included at that position), or\nthere is a transaction spending publicKey in some block between b′ and b.\n\nIf the verifier has a list of all previous block hashes (as the Plasma contract on Ethereum does, for example), a fraud proof has size log(N), where N is the number of transactions or public keys, respectively, included in the block used in the fraud proof. If the verifier does not have such a list, the prover must also provide the chain of block headers from the block mentioned in the fraud proof to block b.\nFull proof of validity\nIn some cases, a verifier may not be running an archival node, and may not be able to take advantage of a challenge-response protocol. In that case, the prover has to provide some additional information.\nA full proof of validity of a UTXO is a light proof of its validity, plus:\n\nThe block header for b′, and a Merkle proof that transaction is included in its Merkle root.\nAll of the block headers between b′ and b.\nFor each of those block headers, a Merkle proof of non-inclusion of publicKey in the publicKeyRoot. Since the public keys in that tree are ordered, this can be done with a Merkle proof of adjacent public keys.\n\nProbabilistic proof of validity\nThis protocol gives us essentially the same functionality as minimum viable Plasma. It reduces transaction size, and makes block validation—i.e., the task that must be performed constantly by any participant on the Plasma network—efficient and memoryless.\nHowever, while it delays the public revelation of transaction histories, those histories must eventually be revealed when a UTXO is withdrawn. Once every UTXO in a Plasma chain is withdrawn, every transaction in its history will have been revealed. Additionally, since transactions can have multiple inputs, the size and verification time of validity proofs (even light proofs) will tend to blow up quasi-exponentially, as you must provide every thread of a UTXO’s history.\nHowever, there’s a trick that allows you to linearize this history, so the size of a light or full proof is only proportional to the length of the average history of the coins in that UTXO, rather than the total history. This will additionally allow us to permanently prune (and thus untraceably hide) a portion of each coin’s history.\nTo do so, we change the rule for validity of a UTXO, so that a UTXO is considered valid if one of its inputs, chosen randomly (and weighted by the amount of that input), is valid. For example, suppose a transaction has one output worth 4 ETH, and has two inputs, one of which is a valid source of 3 ETH and the other of which is a fraudulent source of 1 ETH. 75% of the time, the first one will be checked, and 25% of the time, the second one will be checked. The expected value of fraud will be \\frac{3}{4} \\cdot 4 + \\frac{1}{4} \\cdot 0 - 3 = 034 ⋅4 +14 ⋅0 −3 =0. Indeed, the expected value of fraud should always be 0, which means that the total supply of coins in the contract will not tend to inflate.\nTo strengthen this guarantee, and to discourage users from treating the Plasma chain as a casino, you would likely want to tweak the probabilities so that the expected value of fraud is somewhat less than 50%. For example, you could have a rule that 10% of the time, every input must be checked, which would mean that an attacker would expect to lose 10% of their capital with each attack.\nThe random choice of which coin is checked must be deterministic but uncontrollable and unpredictable by the transaction’s creator. (Finding a secure randomness beacon is a difficult problem, but one with several plausible solutions.) At some point after a transaction is included in the Plasma chain, this random number would be finalized, and the holders of a UTXO would be able to prune all but one of the proofs from its history (although it would need to replace it with a proof of the result of the random beacon).\nThis technique allows you to shorten both full and light proofs of UTXO validity. It also turns the Plasma chain into a sort of trustless probabilistic tumbler. Given a large enough supply of “clean” coins, you would eventually be able to make any coin untraceable.\nUnfortunately, this may still allow the attacker to grief the depositor and other coinholders on the Plasma chain. Computing the griefing factor is surprisingly difficult and depends on some surprising factors (happy to discuss more) but intuitively it seems like these attacks would tend to increase the contract’s overcapitalization—since the expected value for attackers is negative, so each successive griefing attack will be less and less likely to hurt the honest users of the Plasma chain.\n\n Plasma Cash: Plasma with much less per-user data checking\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n Cross Rollup payment channel with no online requirement for sender/recipient\n\n 5\n\n 4\n\n read \n\n 8\n min\n\n post by vbuterin on Feb 16, 2018\n\n post by danrobinson on Feb 17, 2018\n\n post by vbuterin on Feb 17, 2018\n\n post by danrobinson on Feb 17, 2018\n\n post by vbuterin on Feb 17, 2018\n\n post by danrobinson on Feb 17, 2018\n\n post by vbuterin on Feb 17, 2018\n\n post by danrobinson on Feb 17, 2018\n\n Powered by Discourse","tokens":3226,"squid":"ink-research","role":"Deep Scholar","at":1791265250174,"hash":"a747d6916f06ea70ee719f736e5828e73fd59055"}
{"url":"https://forum.soliditylang.org/t/are-there-any-efforts-to-improve-or-standardize-translations-of-solidity-documentation/3693/3","domain":"forum.soliditylang.org","title":"Are there any efforts to improve or standardize translations of Solidity documentation? - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 9\n\n 3 / 3\n\n Jun 3\n\n Jun 2\n\n post by alishawinson on Apr 9\n\n alishawinson\n\n Hi everyone,\nI’ve been going through the official Solidity documentation and found it really well-structured, but I was wondering about its accessibility for non-English speakers. Are there any ongoing community efforts or official initiatives to translate the documentation into other languages? If so, how are those translations download from here and kept in sync with frequent updates?\nAlso, for those who’ve used translated versions, do you find them reliable enough for learning and development, or do you still rely mostly on the original English docs?\n\n post by czepluch on Apr 13\n\n czepluch\n\n Solidity Team\n\n Hi and welcome!\nThank you for sharing your feedback.\nWe have a bunch of translation efforts going on here: Solidity Documentation Translations · GitHub. In this org you can find a variety of different translations. Some are more maintained than others. If your language is currently not up-to-date I recommend opening and issue in the repo with the language you want, requesting that it will get up-to-date. Or even better, open a Pull Request getting the translation up-to-date.\nYou can also check out the Matrix channel: https://matrix.to/#/#solidity-docs-translations:matrix.org\nEither way, if you let me know the language you’re looking for, I can try to get in touch with the maintainers.\n\n 2 months later\n\n post by hwhsu1231 on Jun 2\n\n hwhsu1231\n\n Hello @alishawinson,\n\nI am the author of the Localize The Docs organization. It’s my pleasure to invite you to join the translation of the solidity-docs-l10n project:\n\n Preview: solidity-docs-l10n\n Crowdin: solidity-docs-l10n\n GitHub: solidity-docs-l10n\n\nThe goal of this project is to translate The Solidity Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.\nIf the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!\nSee the announcement post for more details.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 121\n\n May 29\n\n Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 191\n\n Jun 9\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1555,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265255929,"hash":"cc4e864852ecc59fc4e991cee3a1331b85d2d15e"}
{"url":"https://ethresear.ch/c/layer-2/32","domain":"ethresear.ch","title":"Latest Layer 2 topics - Ethereum Research","text":"Latest topics in Layer 2\n\n Layer 2\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Layer 2 category\n\n Layer 2\n\n Topics that do not fit into Plasma and State Channel\n\n 0\n\n 2.9k\n\n Apr 2019\n\n Mechanized Proofs for Atomic Cross-Domain State Synchronization\n\n Layer 2\n\n zk-roll-up,cross-shard,chain-sync\n\n 5\n\n 426\n\n Jul 12\n\n Ethereum Settlement Score (ESS): Revitalizing the Rollup-Centric Roadmap\n\n Layer 2\n\n zk-roll-up,rollup,based-sequencing\n\n 4\n\n 1.1k\n\n Jun 29\n\n The ETHgent testnet officially launches today\n\n Layer 2\n\n 0\n\n 170\n\n Jun 22\n\n Repurposing FOCIL as an L2 forced transaction mechanism\n\n Layer 2\n\n censorship-resistance\n\n 0\n\n 190\n\n Jun 19\n\n SI-RVP: off-chain bisection + a single-instruction Groth16 proof for optimistic-rollup dispute resolution\n\n Layer 2\n\n fraud-proofs\n\n 0\n\n 84\n\n May 30\n\n EIL: Trust minimized cross-L2 interop\n\n Layer 2\n\n 18\n\n 4.1k\n\n May 22\n\n Blob Sharing for Based Rollups\n\n Layer 2\n\n 1\n\n 603\n\n Apr 28\n\n Synchronous Composability Between Rollups via Realtime Proving\n\n Layer 2\n\n cross-shard\n\n 25\n\n 5.0k\n\n Apr 18\n\n The L2 Fee Vault: Pricing L1 Costs with Feedback Control\n\n Layer 2\n\n rollup\n\n 1\n\n 214\n\n Apr 18\n\n A Specialized Rollup with a Non-EVM Execution Layer for Financial Coordination\n\n Optimisitic Rollup\n\n rollup,layer-2\n\n 0\n\n 136\n\n Mar 3\n\n Solving Ethereum’s Fragmentation Problem With Sync Composability\n\n Layer 2\n\n 1\n\n 606\n\n Jan 14\n\n SCOPE - Synchronous Composability Protocol for Ethereum\n\n Layer 2\n\n 2\n\n 1.5k\n\n Dec 2025\n\n Framework for AltDA Secure Integration on Ethereum\n\n Layer 2\n\n data-availability\n\n 0\n\n 377\n\n Dec 2025\n\n Subcommitments: Off-Chain Finality — Fast, Secure, and Cheap\n\n ZK Rollup\n\n zk-roll-up,data-availability,rollup\n\n 1\n\n 306\n\n Nov 2025\n\n Synchronous Composability vs. Intents: Two Paths to Ethereum-Wide Interop\n\n Layer 2\n\n 6\n\n 639\n\n Nov 2025\n\n Optimistic rollups, the challenge period and strong censorship attacks\n\n Optimisitic Rollup\n\n 8\n\n 1.3k\n\n Oct 2025\n\n Unstoppable Sequencing: Permissionless Batching for Rollup Resilience\n\n Layer 2\n\n based-sequencing,sequencing\n\n 2\n\n 423\n\n Oct 2025\n\n Best of Both Worlds? A Measured Review of Non-Interactive ZK Fraud Proofs\n\n Optimisitic Rollup\n\n fraud-proofs\n\n 7\n\n 1.3k\n\n Oct 2025\n\n Community Feedback Wanted: Privacy-Focused ZK Rollup with EVM Compatibility\n\n ZK Rollup\n\n zk-roll-up\n\n 2\n\n 352\n\n Sep 2025\n\n A Taxonomy of Preconfirmation Guarantees and Their Slashing Conditions in Rollups\n\n Layer 2\n\n preconfirmations,based-sequencing,slashing-conditions\n\n 5\n\n 624\n\n Sep 2025\n\n Zk-pushr - A zkVM for Genetic Programming on Ethereum\n\n ZK Rollup\n\n zk-roll-up\n\n 0\n\n 215\n\n Aug 2025\n\n Preemptive Provable Assertions\n\n Layer 2\n\n rollup,based-sequencing\n\n 0\n\n 483\n\n Jul 2025\n\n Native rollups—superpowers from L1 execution\n\n Layer 2\n\n stateless\n\n 41\n\n 11.3k\n\n Jul 2025\n\n ULTRA TX - Programmable blocks: One transaction is all you need for a unified and extendable Ethereum\n\n Layer 2\n\n 11\n\n 1.4k\n\n Jun 2025\n\n Fraud Proof Protocols: BoLD, Dave, and other alternatives\n\n Layer 2\n\n 0\n\n 126\n\n Jun 2025\n\n SPIRAL: A BFT-Based Trust Layer for L2 Interoperability\n\n Layer 2\n\n chain-sync\n\n 0\n\n 231\n\n May 2025\n\n Signal-Boost: L1 Interop Plugin for Rollups\n\n Layer 2\n\n based-sequencing\n\n 0\n\n 922\n\n May 2025\n\n A taxonomy of data availability policies in (Ethereum) rollups\n\n Layer 2\n\n zk-roll-up,data-availability,rollup,layer-2\n\n 1\n\n 2.2k\n\n Apr 2025\n\n Embedded Rollups, Part 2: Shared Bridging\n\n Layer 2\n\n cross-shard,preconfirmations\n\n 2\n\n 4.4k\n\n Apr 2025","tokens":880,"squid":"ink-research","role":"Deep Scholar","at":1791265260637,"hash":"5fbacb364fa5b77b3b360effb9c48a5444ab772d"}
{"url":"https://forum.openzeppelin.com/t/simple-erc20-crowdsale/4863/7","domain":"forum.openzeppelin.com","title":"Simple ERC20 Crowdsale - Smart Contracts / Guides and Tutorials - OpenZeppelin Forum","text":"Smart ContractsGuides and Tutorials\n\n erc20,crowdsale,example\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2020\n\n 6 / 6\n\n Jul 2022\n\n Jul 2022\n\n post by abcoathup on Mar 15, 2021\n\n 8 days later\n\n Split this topic on Dec 9, 2020\n\n 1 month later\n\n Split this topic on Jan 21, 2021\n\n 2 months later\n\n Split this topic on Mar 15, 2021\n\n 2 posts were split to a new topic: Where are crowdsales?\n\n 1 year later\n\n post by RicciH8 on May 17, 2022\n\n RicciH8\n\n Hello @abcoathup or anyone who can help,\nI've been trying to edit your 2_deploy.js to allow me to run a crowdsale on a previously created token. I stripped out the SimpleToken and tried to hardcode the existing contract address in. Something like so:\nconst CROWDSALE2 = artifacts.require(\"CROWDSALE2\");\n\nmodule.exports = async function (deployer, network, accounts) {\n\n const token = 'TOKEN_CONTRACT_ADDRESS';\n\n await deployer.deploy(CROWDSALE2, 1, accounts[0], token.address);\n const crowdsale = await CROWDSALE2.deployed();\n\n token.transfer(crowdsale.address, await token.totalSupply())\n};\n\nIs this even possible to create a crowdsale on a previously deployed token?\nThe error I get when deploying is:\n *** Deployment Failed ***\n\n\"CROWDSALE2\" -- invalid address (argument=\"address\", value=undefined, code=INVALID_ARGUMENT, version=address/5.0.5) (argument=\"token\", value=undefined, code=INVALID_ARGUMENT, version=abi/5.0.7).\n\nHelp would be much appreciated.\nBest regards,\n\n 2 months later\n\n post by sven.meyer on Jul 18, 2022\n\n sven.meyer\n\n I just stumbled again over this crowdsale contract and wondering again why it was abandoned in v3.\n\" All crowdsale-related contracts were removed from the OpenZeppelin Contracts library on the v3.0.0 release due to both a decline in their usage and the complexity associated with migrating them to Solidity v0.6.\"\nIf OZ finds it too complex to migrate it to solc v0.6, should I touch and try that ?\nAny information what would have been so \"complex\" ?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Help me write an erc20 token and a crowdsale contract\n\n Contracts\n\n erc20\n\n 9\n\n 8.0k\n\n Dec 2020\n\n Simple ERC20 Crowdsale contract\n\n Contracts\n\n 5\n\n 2.3k\n\n Nov 2020\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 742\n\n Feb 2022\n\n Simple tests for Crowdsale contract?\n\n Contracts\n\n 4\n\n 2.5k\n\n Dec 2020\n\n Simple ERC20 token example\n\n Guides and Tutorials\n\n 7\n\n 24.9k\n\n Sep 2022","tokens":622,"squid":"ink-security_audits","role":"Sentinel","at":1791265261869,"hash":"11dd182eb3bf990c281ba19f75c471b68fee026b"}
{"url":"https://ethresear.ch/t/si-rvp-off-chain-bisection-a-single-instruction-groth16-proof-for-optimistic-rollup-dispute-resolution/25005/1","domain":"ethresear.ch","title":"SI-RVP: off-chain bisection + a single-instruction Groth16 proof for optimistic-rollup dispute resolution - Layer 2 - Ethereum Research","text":"SI-RVP: off-chain bisection + a single-instruction Groth16 proof for optimistic-rollup dispute resolution \n\n Layer 2\n\n fraud-proofs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 30\n\n 1 / 1\n\n May 30\n\n May 30\n\n post by cd4761 on May 30\n\n cd4761\n\n TL;DR\nWe built and measured a hybrid optimistic-rollup dispute protocol that keeps the 1-of-N permissionless trust model of Cannon but moves the bisection off-chain and replaces the on-chain MIPS leaf execution with a single-instruction Groth16 proof. On a Sepolia PoC the contested path is 4 core dispute transactions (~0.72M gas), plus the resolveDispute settlement (~0.11M) — 5 on-chain txs, ~0.83M total. That is roughly an order of magnitude below Cannon’s spec-based estimate for a fully-played on-chain game (≈10–15M gas; we did not re-measure Cannon).\nWhat this does and does NOT shorten: we keep the 7-day challenge window as an availability buffer, so this is not a “47-minute withdrawal” claim. What collapses from days to ~tens of minutes is the adversarial-path dispute resolution once a challenge is opened — and even that ~47-min figure is not measured; it is a model projection dominated by L1 confirmation (details below). Gas is real; latency is a model.\nThis builds directly on the idea proposed here in ZK Fraud Proof with ZK State Channel (Mar 2024) — using a ZK state channel to settle optimistic-rollup disputes with an on-demand ZK proof — and on the related hybrid-bisection + single-step-ZK discussions (e.g. Almost Instant Interactive Fraud Proof … multi-step ZK verifier). To be upfront: the high-level idea is not ours — it is essentially the #19004 proposal. Our contribution is narrower — a worked end-to-end implementation, on-chain measurement, and a structural (non-game-theoretic) safety argument. We’d value the community’s view on whether that delta is meaningful given Cartesi Dave / OP Kailua, or whether it is mostly engineering.\nThe problem\nThe 7-day fraud-proof window is the part of OR finality that is intrinsic to the optimistic model (not a bridge property). Existing dispute machinery improves it by trading on-chain verification cost (Cannon, BoLD) or off-chain proving cost (Morph’s full-batch RVP) for shorter wall-clock; none reduces both at once.\nApproach (4 pieces)\n\nOff-chain bisection. The ⌈log₂ T⌉-round binary search over the disputed MIPS trace runs as signed P2P messages between challenger and sequencer. Only the co-signed terminal commitment touches L1.\nPoseidon-aligned bisection commitment. Both off-chain hashing and the ZK circuit’s public inputs use Poseidon, so the on-chain keccak256(abi.encodePacked(preHash, postHash, step)) commitment binds the off-chain result to the verifier. (We hit a real bug here — see “what external verification caught” below.)\nSingle-instruction Groth16 proof. Only the one disputed MIPS step is proven (relation R_mips over BN254). Verifier gas is constant in batch size.\n1-of-N permissionless validator pool. Instance-level dispute is bilateral, but safety only needs some honest-and-active validator in the pool. Fallback to the optimistic path has closed form (1−h)^N.\n\nWhat we measured (and what we did NOT)\n\nMeasured (Sepolia, single run — so treat as a point estimate, not a distribution): the 4 core dispute txs = 720,483 gas (initiate + bond + bisectionResult + submitProof); resolveDispute adds 105,267, so the full lifecycle is 5 on-chain txs ≈ 825,750 gas. submitProof (real Groth16 pairing check) = 279,930. Circuit: 16,857 R1CS constraints, single MIPS step. The Cannon baseline we compare against is a spec-based estimate (≈50K gas/move × a depth-73 game), not a re-measurement, so the “order of magnitude” framing is deliberate.\nNOT measured — projected: the ~47-min end-to-end latency. It comes from the liveness bound evaluated with measured proof/P2P primitives plus an assumed mainnet-finality L1 confirmation (~10–12 min/tx). The PoC run actually landed its txs in consecutive Sepolia blocks (~12 s apart), which is a lower bound, not the projection input. So: gas is real, latency is a model.\n\nWhat external verification caught (worth flagging)\nWhile re-running the PoC to confirm reproducibility, we found that the on-chain commitment check indexed the Groth16 public signals as [0],[1], but snarkjs emits circuit outputs before public inputs, so the signal order is [valid, preHash, postHash] — the bisected hashes are at [1],[2]. Under the old indexing no valid proof could clear the commitment check. Fixed, redeployed, and a real proof now passes on-chain. We mention this because it’s the kind of silent failure (protocol collapses to the optimistic path with no on-chain signal) that end-to-end gas tests alone don’t catch.\nRelation to prior work (where we expect pushback)\n\nCartesi Dave is the closest production-track design: bisection then a single validity proof at the leaf. Differences: Dave’s bisection is an on-chain tournament (we use an off-chain ZK state channel), and Dave proves a “fat” native-speed step of a RISC-V machine (we prove a single MIPS instruction).\nOP Kailua / Boundless hybrid mode replaces the interactive game with a ZK fraud proof; different point in the design space (no single-instruction leaf).\nBoLD keeps bisection on-chain (all-vs-all, O(N²) comms).\nMorph RVP proves the entire challenged batch (prover cost scales with batch).\n\nHonest question to the community: is the “off-chain bisection + single-instruction ZK leaf + ZK state channel” triple meaningfully novel given Dave’s trajectory, or is the delta mostly engineering?\nLimitations we’re not hiding\n\nTrusted setup is the deployment blocker. The PoC uses a single-party Groth16 setup for benchmarking; production needs an MPC ceremony (Powers of Tau + circuit Phase 2). This is the dominant reason we call it a research prototype.\nMIPS-27 subset → a completeness gap, not just a coverage number. The executor implements 27 of ~50 Cannon opcodes (Branch/Jump/Syscall deferred). The consequence we want to be explicit about: if a dispute’s terminal instruction is an unimplemented opcode, the single-instruction proof cannot currently be produced — the protocol stays sound (it never finalizes a wrong root) but is incomplete on that path until the subset is extended. Per-step R1CS cost is invariant to opcode count and Branch/Jump/Syscall share existing constraint families, so closing this is engineering, not a new circuit primitive — but it is not done yet.\nIndependence in the fallback model. (1−h)^N assumes pairwise-independent validators; correlated infrastructure weakens it.\n\nFeedback we’d value\n\nIs the single-instruction (vs fat-step) leaf a real advantage, or does Dave’s native-speed step dominate in practice once proving cost is included?\nIs a structural safety reduction (to Groth16 soundness + hash collision-resistance, no bond-vs-EV game theory) the right framing, or are we missing an incentive attack?\nFor the off-chain ZK state channel: failure modes of the two-of-two co-signing under griefing beyond the timeout fallback?\n\nContracts / circuit / measurement artifacts are available on request (a public release is pending an IP clearance). We’re posting here to get the L2/ZK community’s read before committing to the production-track claims — pushback on the prior-work delta and the completeness gap above is exactly what we’re after.\n\n Powered by Discourse","tokens":1842,"squid":"ink-research","role":"Deep Scholar","at":1791265270919,"hash":"137ded6095f2da991731f2a623a05eb6935ff51f"}
{"url":"https://forum.openzeppelin.com/t/help-me-write-an-erc20-token-and-a-crowdsale-contract/1797/10","domain":"forum.openzeppelin.com","title":"Help me write an erc20 token and a crowdsale contract - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n 2\n\n Nov 2019\n\n 11 / 11\n\n Dec 2020\n\n Sep 2020\n\n post by Andrei on Nov 21, 2019\n\n Andrei\n\n help me write an erc20 contract with a fixed issue of 1,000,000 tokens, half (500,000) of which will belong to the creator of the contract, and the rest can be bought at a price of 0.0012 ETH for one token, always until they are all sold . Something like a stable coin. Ethers must be sent to the contract itself, and the creator can transfer them to another ethereum account at any time.\n\n Verify Crowdsale contract on Etherscan deployed using Remix\n\n 4\n\n 3\n\n 2\n\n post by abcoathup on Nov 22, 2019\n\n abcoathup\n\n Great contributor\n\n Hi @andrei,\nI recommend reading the documentation on ERC20 and Crowdsales\nThe following are simple examples of a token and a crowdsale. (based on examples: https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/contracts/examples)\nDeploy both contracts (setting the required rate, wallet address and token address in the crowdsale) and then transfer the required tokens to the crowdsale.\nFor experimenting in a test environment you could set the rate to 1.\nTo calculate required rates, please see the documentation: https://docs.openzeppelin.com/contracts/2.x/crowdsales#crowdsale-rate\nI haven’t tested the code below other than manually deploying in truffle console.\nAny such contracts need thorough and appropriate testing and auditing.\nFor testing, I recommend following: Test smart contracts like a rockstar\nBefore an audit I recommend following this checklist: https://blog.openzeppelin.com/follow-this-quality-checklist-before-an-audit-8cc6a0e44845/\nOpenZeppelin can perform audits: https://openzeppelin.com/security-audits/\nSimpleToken\npragma solidity ^0.5.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport \"@openzeppelin/contracts/token/ERC20/ERC20Detailed.sol\";\n\n/**\n * @title SimpleToken\n * @dev Very simple ERC20 Token example, where all tokens are pre-assigned to the creator.\n * Note they can later distribute these tokens as they wish using `transfer` and other\n * `ERC20` functions.\n */\ncontract SimpleToken is Context, ERC20, ERC20Detailed {\n\n /**\n * @dev Constructor that gives _msgSender() all of existing tokens.\n */\n constructor () public ERC20Detailed(\"SimpleToken\", \"SIM\", 18) {\n _mint(_msgSender(), 1000000 * (10 ** uint256(decimals())));\n }\n}\n\nSimpleCrowdsale\npragma solidity ^0.5.0;\n\nimport \"@openzeppelin/contracts/crowdsale/Crowdsale.sol\";\n\n/**\n * @title SimpleCrowdsale\n * @dev This is an example of a fully fledged crowdsale.\n */\ncontract SimpleCrowdsale is Crowdsale {\n constructor (\n uint256 rate,\n address payable wallet,\n IERC20 token\n )\n public\n Crowdsale(rate, wallet, token)\n {\n }\n}\n\n Simple ERC20 Crowdsale contract\n\n How to combine two ERC20 contracts\n\n \"VM Exception while processing transaction: revert\" in Truffle test and Truffle dev in Crowdsale\n\n Help with BEP20 crowdsale contract!\n\n 10 months later\n\n post by PradhumnaPancholi on Sep 29, 2020\n\n PradhumnaPancholi\n\n Where should we declare values for these variables?\n\n post by abcoathup on Sep 29, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nYou can hard code the values in the contracts constructor or pass them in when you deploy.\nFor values that don’t change with deployment I prefer to hard code, for values that do change I pass in (also makes testing easier).\n\n post by PradhumnaPancholi on Sep 29, 2020\n\n PradhumnaPancholi\n\n Okay, I get the hard code way. Can you share the example of the other way? ( mainly coz I will be changing the rate multiple times during crowd sale). Also, how do I set the rate to a US dollar value? Like for example, I wanna sell the token for $1000 on the starting date, how do I implement that? And again, thanks for your ridiculously prompt response.\n\n post by abcoathup on Sep 29, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nIf you want to change the rate overtime, you would need to code this functionality or use IncreasingPriceCrowdsale. If you want to change the rate manually, again you would need to code this functionality so that you could change it. Though you would want to be clear with your community when, why and by how much you would change the rate by. A good place to start to see how to do this would be IncreasingPriceCrowdsale.\nThe Crowdsale contracts accept Ether. If you want to accept a token, you will need to create your own version to accept a stable token. You may want to look at how you could launch your token on a DEX instead.\nFor anyone else in the community reading this, I suggest looking at Points to consider when creating a fungible token (ERC20, ERC777)\n\n post by PradhumnaPancholi on Sep 29, 2020\n\n PradhumnaPancholi\n\n Hi @abcoathup. So, IncreasingPriceCrowdsale won’t work for me but after trying multiple options like Oracalize, I am settled LinkChain to get the current eth price and use Math on it to charge the amount according to our auction. I know I am a broken record, it’s just I am on a tightine but I have considered things as you mentioned while pointing to that article. Update on DAI situation, due to current status, we will be only accepting eth. But, I am still struggling to get a simple Crowdsale up and running without errors. For reference, here is my code.\npragma solidity ^0.5.0;\n\nimport '@openzeppelin/contracts/crowdsale/Crowdsale.sol';\n\ncontract BooksSale is Crowdsale{\n\n constructor(\n uint256 rate,\n address payable wallet,\n IERC20 token\n )\n Crowdsale(rate, wallet, token)\n public\n {\n\n }\n}\n\nI have tried multple things to pass values here. Can you share a example where you are inserting the values? I have tried things from Openzeppelin Docs but … not able to get it working in my case.\n\n post by martriay on Sep 30, 2020\n\n martriay\n\n Hi @PradhumnaPancholi, could you share what version of OpenZeppelin Contracts are you using and what error are you getting? Bear in mind that the crowdsale contracts are not included in Contracts since v3.\n\n post by PradhumnaPancholi on Sep 30, 2020\n\n PradhumnaPancholi\n\n I literally figured this out 15 mins before your response. So, here’s what I was doing wrong.\nInstead of this,\nmodule.exports = (deployer) => {\n deployer.deploy(BooksSale, 1000, '0x6F4B6536cA5bd14631584BE382353e4683843575', '0x7F4E50095C5c059ebb69639c698CB93878202ccE')\n} \n\nI was doing this\nmodule.exports = (deployer) => {\n deployer.deploy(BooksSale (1000, '0x6F4B6536cA5bd14631584BE382353e4683843575', '0x7F4E50095C5c059ebb69639c698CB93878202ccE'))\n}\n\nWhich I know is a really stupid mistake. But, I wasn’t able to find an example where someone actually inserts value.\nIt’s finally fixed now. So, I guess this can be marked as “solved”.\nThank you @martriay and @abcoathup for your help and for maintaining your patience with me.\n\n post by martriay on Sep 30, 2020\n\n martriay\n\n Glad to hear you were able to solve it!\n\nWell actually this thread is already marked as solved from before haha. Next time consider creating a new post for your question, this helps to build a larger and easy to search question/answer base for future users \n\n 2 months later\n\n Split this topic on Dec 1, 2020\n\n 8 posts were split to a new topic: Issue compiling Crowdsale\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Simple ERC20 Crowdsale\n\n Guides and Tutorials\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025\n\n Fail with error ‘SafeERC20: low-level call failed’ (only with other decimals than 18)\n\n Contracts\n\n erc20\n\n 10\n\n 2.1k\n\n Apr 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 742\n\n Feb 2022\n\n Simple ERC20 Crowdsale contract\n\n Contracts\n\n 5\n\n 2.3k\n\n Nov 2020\n\n Rate to use for Crowdsale for ERC20 token not using 18 decimals\n\n Contracts\n\n 4\n\n 2.6k\n\n Dec 2020","tokens":1962,"squid":"ink-security_audits","role":"Sentinel","at":1791265272555,"hash":"ac2000e86cc5afa4baecb62befadf1b30e06da09"}
{"url":"https://ethresear.ch/t/zk-fraud-proof-with-zk-state-channel/19004","domain":"ethresear.ch","title":"ZK Fraud Proof with ZK State Channel - Layer 2 - Ethereum Research","text":"ZK Fraud Proof with ZK State Channel \n\n Layer 2\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2024\n\n 1 / 2\n\n Mar 2024\n\n Mar 2024\n\n post by 0x1cc on Mar 14, 2024\n\n 0x1cc\n\nThanks @qizhou for discussing the idea\n\nTL;DR\n\nWe can use the zk state channel to provide a zk fraud proof to resolve the disputes swiftly in the optimistic systems, such as opRollup (optimistic rollup) and opML (optimistic machine learning)\n\nWe can construct a zk state channel using zkVM\n\nWhen the challenger can open a ZK state channel with the defender (sequencer/submitter) for dispute resolution, followed by uploading ZK proof onto the chain\n\nBackground\nCurrent interactive fraud-proof challenge protocols such as Optimism fruad proof system uses\n\nbinary search method to pinpoint the specific step or instruction where a discrepancy arises between the defender (submitter/sequencer) and the challenger.\n\nwhen the specific step of disagreement is found, a one-step on-chain executor is used to adjudicate whether the defender or challenger is correct.\n\nConsidering about 40+B steps (instructions) per block transition, the protocol will take about 36 interactions, which is costly in both time and gas.\nTo reduce the number of interactions, umerous researchers have explored the use of Zero-Knowledge (zk) fraud-proof approaches (Foundation Mission Request: OP Stack Zero Knowledge Proof [ABANDONED] · Issue #61 · ethereum-optimism/ecosystem-contributions · GitHub). Many have experimented with utilizing zkVM as the fraud-proof virtual machine to generate zk proofs for either full-step or multi-step executions. With zk proofs for multi-step executions, the number of interactions can be significantly reduced (Almost Instant Interactive Fraud Proof using Multi-Sect on DA BLOBs and multi-step ZK verifier). If a zk proof for the full-step execution can be provided, the fraud-proof system operates akin to a zk proof system, eliminating the need for any interaction to resolve disputes. However, the cost of generating zk proofs for multi-step executions in zkVM remains substantial. Besides, in instances where a zk proof for the full-step execution cannot be provided, on-chain interaction for locating the dispute step remains necessary.\nProposal\n\nWe can first construct a Zero-Knowledge (zk) state channel utilizing zkVM, where the zkVM will host the dispute game program.\n\nUpon a validator (challenger) initiating a challenge, they can establish a zk state channel with the defender (sequencer/submitter).\n\nWithin this channel, the challenger and defender engage with the dispute game program hosted in zkVM, simulating the on-chain interaction typical of smart contracts. They employ binary search techniques to pinpoint the disputed step and subsequently utilize one-step on-chain execution to determine the correct party.\n\nOnce the dispute resolution concludes, they can generate a zk proof encapsulating the entire process within zkVM, subsequently submitting it on-chain for arbitration.\n\nzkChannel926×690 34.3 KB\nAdvantages\n\nThe proposed zk fraud-proof mechanism integrated with zk state channels dramatically reduces on-chain interactions to just two: one for channel initiation and another for closure, including zk proof submission. All other interactions occur off-chain and are cryptographically guaranteed by zk proofs.\n\nAs interactions between the defender and the challenger occur off-chain, the frequency of engagement can be heightened, allowing for a more dynamic interaction rate. The number of checkpoints can also be greatly increased (2048+ can be easily achieved), and the number of interactions can no longer be limited.\n\nThis approach is more cost-effective compared to generating zk proofs for full-step or multi-step executions within zkVM.\n\nSecurity Concern\nOne potential concern with this proposal is the possibility of non-cooperation between challengers and defenders. To address this issue:\n\nWe still retain the original on-chain interactive dispute game, allowing both defenders and challengers to close the zk state channel at any time. In scenarios where the channel is closed, yet the dispute remains unresolved, parties can resort to the on-chain interactive dispute game contract for resolution.\n\nWe can design an incentive mechanism to encourage challengers and defenders to participate in the zk state channel. For instance, participants could face reduced penalties for losing the dispute game and receive larger bonuses for winning.\n\nConclusion\nThis proposal works like an auxiliary plugin for expediting dispute resolution. It does not compromise the security of the existing fraud-proof system but instead offers a cost-effective and swift solution for dispute resolution.\n\n SI-RVP: off-chain bisection + a single-instruction Groth16 proof for optimistic-rollup dispute resolution\n\n post by Mirror on Mar 18, 2024\n\n Mirror\n\n Accelerating hardware for ZK proofs will make you faster.\n\n Powered by Discourse","tokens":1239,"squid":"ink-research","role":"Deep Scholar","at":1791265281207,"hash":"ee9878f15a713408e9251dfc75650099427a44d7"}
{"url":"https://ethresear.ch/t/zk-fraud-proof-with-zk-state-channel/19004/2","domain":"ethresear.ch","title":"ZK Fraud Proof with ZK State Channel - Layer 2 - Ethereum Research","text":"Layer 2\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2024\n\n 2 / 2\n\n Mar 2024\n\n Mar 2024\n\n post by 0x1cc on Mar 14, 2024\n\n 0x1cc\n\nThanks @qizhou for discussing the idea\n\nTL;DR\n\nWe can use the zk state channel to provide a zk fraud proof to resolve the disputes swiftly in the optimistic systems, such as opRollup (optimistic rollup) and opML (optimistic machine learning)\n\nWe can construct a zk state channel using zkVM\n\nWhen the challenger can open a ZK state channel with the defender (sequencer/submitter) for dispute resolution, followed by uploading ZK proof onto the chain\n\nBackground\nCurrent interactive fraud-proof challenge protocols such as Optimism fruad proof system uses\n\nbinary search method to pinpoint the specific step or instruction where a discrepancy arises between the defender (submitter/sequencer) and the challenger.\n\nwhen the specific step of disagreement is found, a one-step on-chain executor is used to adjudicate whether the defender or challenger is correct.\n\nConsidering about 40+B steps (instructions) per block transition, the protocol will take about 36 interactions, which is costly in both time and gas.\nTo reduce the number of interactions, umerous researchers have explored the use of Zero-Knowledge (zk) fraud-proof approaches (Foundation Mission Request: OP Stack Zero Knowledge Proof [ABANDONED] · Issue #61 · ethereum-optimism/ecosystem-contributions · GitHub). Many have experimented with utilizing zkVM as the fraud-proof virtual machine to generate zk proofs for either full-step or multi-step executions. With zk proofs for multi-step executions, the number of interactions can be significantly reduced (Almost Instant Interactive Fraud Proof using Multi-Sect on DA BLOBs and multi-step ZK verifier). If a zk proof for the full-step execution can be provided, the fraud-proof system operates akin to a zk proof system, eliminating the need for any interaction to resolve disputes. However, the cost of generating zk proofs for multi-step executions in zkVM remains substantial. Besides, in instances where a zk proof for the full-step execution cannot be provided, on-chain interaction for locating the dispute step remains necessary.\nProposal\n\nWe can first construct a Zero-Knowledge (zk) state channel utilizing zkVM, where the zkVM will host the dispute game program.\n\nUpon a validator (challenger) initiating a challenge, they can establish a zk state channel with the defender (sequencer/submitter).\n\nWithin this channel, the challenger and defender engage with the dispute game program hosted in zkVM, simulating the on-chain interaction typical of smart contracts. They employ binary search techniques to pinpoint the disputed step and subsequently utilize one-step on-chain execution to determine the correct party.\n\nOnce the dispute resolution concludes, they can generate a zk proof encapsulating the entire process within zkVM, subsequently submitting it on-chain for arbitration.\n\nzkChannel926×690 34.3 KB\nAdvantages\n\nThe proposed zk fraud-proof mechanism integrated with zk state channels dramatically reduces on-chain interactions to just two: one for channel initiation and another for closure, including zk proof submission. All other interactions occur off-chain and are cryptographically guaranteed by zk proofs.\n\nAs interactions between the defender and the challenger occur off-chain, the frequency of engagement can be heightened, allowing for a more dynamic interaction rate. The number of checkpoints can also be greatly increased (2048+ can be easily achieved), and the number of interactions can no longer be limited.\n\nThis approach is more cost-effective compared to generating zk proofs for full-step or multi-step executions within zkVM.\n\nSecurity Concern\nOne potential concern with this proposal is the possibility of non-cooperation between challengers and defenders. To address this issue:\n\nWe still retain the original on-chain interactive dispute game, allowing both defenders and challengers to close the zk state channel at any time. In scenarios where the channel is closed, yet the dispute remains unresolved, parties can resort to the on-chain interactive dispute game contract for resolution.\n\nWe can design an incentive mechanism to encourage challengers and defenders to participate in the zk state channel. For instance, participants could face reduced penalties for losing the dispute game and receive larger bonuses for winning.\n\nConclusion\nThis proposal works like an auxiliary plugin for expediting dispute resolution. It does not compromise the security of the existing fraud-proof system but instead offers a cost-effective and swift solution for dispute resolution.\n\n SI-RVP: off-chain bisection + a single-instruction Groth16 proof for optimistic-rollup dispute resolution\n\n post by Mirror on Mar 18, 2024\n\n Mirror\n\n Accelerating hardware for ZK proofs will make you faster.\n\n Powered by Discourse","tokens":1229,"squid":"ink-research","role":"Deep Scholar","at":1791265302737,"hash":"ea74120745f202131bb03796bf746860c8880f40"}
{"url":"https://forum.openzeppelin.com/t/where-are-crowdsales/6321/1","domain":"forum.openzeppelin.com","title":"Where are crowdsales? - Support / Contracts - OpenZeppelin Forum","text":"Where are crowdsales? \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Mar 2021\n\n 1 / 8\n\n Mar 2021\n\n Feb 2022\n\n post by asven-2020 on Mar 15, 2021\n\n asven-2020\n\n Hallo friends\ncrowdsale was delete to library cant find it\n\n Simple ERC20 Crowdsale\n\n 3\n\n 3\n\n post by Skyge on Mar 15, 2021\n\n Skyge\n\n Yeah, you are right, it only exists in the version 2.x, they are not in OpenZeppelin Contracts 3.x.\nSo to install it, you can run the following command:\nnpm install @openzeppelin/contracts@2.5.1\n\nAnd you can find more details in the documentation: https://docs.openzeppelin.com/contracts/2.x/crowdsales \n\n post by abcoathup on Mar 15, 2021\n\n abcoathup\n\n Great contributor\n\n I have added emoji to the Simple ERC20 Crowdsale to make it clearer that they are not in OpenZeppelin Contracts 3.x\n\n post by asven-2020 on Mar 16, 2021\n\n asven-2020\n\n Thank you. May be any new contract for presale have?\n\n post by abcoathup on Mar 16, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nThere aren’t specific presale contracts. You could have multiple crowdsale contracts for each phase.\n\n post by asven-2020 on Mar 18, 2021\n\n asven-2020\n\n Thank you Crowdsale not work with new ERC20 so problem do before pull\n\n post by abcoathup on Mar 18, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nYou can have a separate project for the token and a separate project for the crowdsale. This would allow you to have a token using the latest OpenZeppelin Contracts (depending on the token).\n\n 11 months later\n\n post by BigMadCode on Feb 6, 2022\n\n BigMadCode\n\n Is there a new Crowdsale contract or did OPZ just stop maintaining it altogether. I tried using the 2x contract and could never get the transfer function to work at all.\nIf you know of any newer contract please advise.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use Crowdsale Smart Contracts\n\n Contracts\n\n erc20\n\n 1\n\n 683\n\n May 2020\n\n How to create a Crowdsale with Solidity 0.6?\n\n Contracts\n\n 2\n\n 1.7k\n\n Sep 2020\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Analogue CrowdSales\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 617\n\n Apr 2022","tokens":587,"squid":"ink-security_audits","role":"Sentinel","at":1791265305532,"hash":"54efbf083eacd2b6f2223cfa45ad9cd06f00afb5"}
{"url":"https://dev-forum.pyth.network/t/cant-get-update-fee/298","domain":"dev-forum.pyth.network","title":"Cant get update fee - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Cant get update fee \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n Jul 2025\n\n 1 / 9\n\n Jul 2025\n\n Jul 2025\n\n post by howie228 on Jul 14, 2025\n\n howie228\n\n Network: Monad Testnet\nTimestamp: yesterday and today\nSteps to reproduce:\n\nGet price feed id (mine is BTC/USD)\nCall the Hermes API to retrieve binary data\nPass the binary data to getUpdateFee\nError: invalid arrayify value (argument=“value”, value=\nAdditional notes:\nI am trying to create a prediction game on monad testnet that utilizes Pyth price feeds with Pyth Pull Oracle, Hermes API and Gelato Web3 Automated functions. The flow goes like this:\nwe have a round. there is a 20 second threshold where the users could bet if the price is going to go up or down. then, after 20 seconds, the round locks. we then get the updated data from hermes API, push it to the pull oracle via Gelato operator, compare the new price against the players’ bets and reward whoever won.\nright now stuck at getting the fees\n\n 6\n\n 3\n\n post by nidhi on Jul 14, 2025\n\n nidhi\n\n Can you please share how you are calling getUpdateFee. Also share the complete error logs.\nFor your reference Price Feeds | Pyth Network API Reference , you can test it here.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n hi, sorry for the delayed answer. i already found the issue, it was a mismatch in the types inside the contract. now i dont get any errors, but i still get 0 updates on price feed retrieval inside of the contract.\nhere is the function i have trouble with:\n function executeRound(bytes calldata pythUpdateData) external payable onlyOperator whenNotPaused {\n require(genesisStarted, \"Genesis not started\");\n\n uint256 currentRoundEpoch = currentEpoch;\n Round storage round = rounds[currentRoundEpoch];\n\n require(block.timestamp >= round.lockTimestamp, \"Too early to lock\");\n require(!round.settled, \"Round already settled\");\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pythUpdateData;\n\n uint256 fee = pyth.getUpdateFee(updateData);\n pyth.updatePriceFeeds{value: fee}(updateData);\n\n PythStructs.Price memory price = pyth.getPrice(priceId);\n\n round.lockPrice = price.price;\n round.lockTimestamp = block.timestamp;\n\n emit RoundLocked(currentRoundEpoch, round.lockPrice, block.timestamp);\n\n if (currentRoundEpoch > 1) {\n _settleRound(currentRoundEpoch - 1, price.price);\n }\n\n currentEpoch = currentRoundEpoch + 1;\n _startRound(currentEpoch);\n\n if (msg.value > fee) {\n (bool success, ) = msg.sender.call{value: msg.value - fee}(\"\");\n require(success, \"Refund failed\");\n }\n }\n\nit passes the calldata properly and the function runs all the way. however, whenever we retrieve prices via the contract, they are always 0. i tried reading the IPyth contract on Monad Testnet via javascript/ethers, and all the data was in place. However, whenever pyth.getPrice is being called via contract it returns 0. or i am not handling it properly. the address, abi and interface is the same in both cases.\n\n post by nidhi on Jul 15, 2025\n\n post by howie228 on Jul 15, 2025\n\n post by howie228 on Jul 15, 2025\n\n post by nidhi on Jul 15, 2025\n\n post by howie228 on Jul 16, 2025\n\n post by howie228 on Jul 17, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":1845,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265314457,"hash":"bf26a68d0f5654e0fec9074e19f6afba80bb3595"}
{"url":"https://forum.openzeppelin.com/t/where-are-crowdsales/6321/2","domain":"forum.openzeppelin.com","title":"Where are crowdsales? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Mar 2021\n\n 2 / 8\n\n Mar 2021\n\n Feb 2022\n\n post by asven-2020 on Mar 15, 2021\n\n asven-2020\n\n Hallo friends\ncrowdsale was delete to library cant find it\n\n Simple ERC20 Crowdsale\n\n 3\n\n 3\n\n post by Skyge on Mar 15, 2021\n\n Skyge\n\n Yeah, you are right, it only exists in the version 2.x, they are not in OpenZeppelin Contracts 3.x.\nSo to install it, you can run the following command:\nnpm install @openzeppelin/contracts@2.5.1\n\nAnd you can find more details in the documentation: https://docs.openzeppelin.com/contracts/2.x/crowdsales \n\n post by abcoathup on Mar 15, 2021\n\n abcoathup\n\n Great contributor\n\n I have added emoji to the Simple ERC20 Crowdsale to make it clearer that they are not in OpenZeppelin Contracts 3.x\n\n post by asven-2020 on Mar 16, 2021\n\n asven-2020\n\n Thank you. May be any new contract for presale have?\n\n post by abcoathup on Mar 16, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nThere aren’t specific presale contracts. You could have multiple crowdsale contracts for each phase.\n\n post by asven-2020 on Mar 18, 2021\n\n asven-2020\n\n Thank you Crowdsale not work with new ERC20 so problem do before pull\n\n post by abcoathup on Mar 18, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nYou can have a separate project for the token and a separate project for the crowdsale. This would allow you to have a token using the latest OpenZeppelin Contracts (depending on the token).\n\n 11 months later\n\n post by BigMadCode on Feb 6, 2022\n\n BigMadCode\n\n Is there a new Crowdsale contract or did OPZ just stop maintaining it altogether. I tried using the 2x contract and could never get the transfer function to work at all.\nIf you know of any newer contract please advise.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use Crowdsale Smart Contracts\n\n Contracts\n\n erc20\n\n 1\n\n 683\n\n May 2020\n\n How to create a Crowdsale with Solidity 0.6?\n\n Contracts\n\n 2\n\n 1.7k\n\n Sep 2020\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Analogue CrowdSales\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 617\n\n Apr 2022","tokens":581,"squid":"ink-security_audits","role":"Sentinel","at":1791265318081,"hash":"2b125d2b5b7f7aefed156ecda7dbe4400af7c1d0"}
{"url":"https://dev-forum.pyth.network/t/cant-get-update-fee/298/2","domain":"dev-forum.pyth.network","title":"Cant get update fee - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n Jul 2025\n\n 2 / 9\n\n Jul 2025\n\n Jul 2025\n\n post by howie228 on Jul 14, 2025\n\n howie228\n\n Network: Monad Testnet\nTimestamp: yesterday and today\nSteps to reproduce:\n\nGet price feed id (mine is BTC/USD)\nCall the Hermes API to retrieve binary data\nPass the binary data to getUpdateFee\nError: invalid arrayify value (argument=“value”, value=\nAdditional notes:\nI am trying to create a prediction game on monad testnet that utilizes Pyth price feeds with Pyth Pull Oracle, Hermes API and Gelato Web3 Automated functions. The flow goes like this:\nwe have a round. there is a 20 second threshold where the users could bet if the price is going to go up or down. then, after 20 seconds, the round locks. we then get the updated data from hermes API, push it to the pull oracle via Gelato operator, compare the new price against the players’ bets and reward whoever won.\nright now stuck at getting the fees\n\n 6\n\n 3\n\n post by nidhi on Jul 14, 2025\n\n nidhi\n\n Can you please share how you are calling getUpdateFee. Also share the complete error logs.\nFor your reference Price Feeds | Pyth Network API Reference , you can test it here.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n hi, sorry for the delayed answer. i already found the issue, it was a mismatch in the types inside the contract. now i dont get any errors, but i still get 0 updates on price feed retrieval inside of the contract.\nhere is the function i have trouble with:\n function executeRound(bytes calldata pythUpdateData) external payable onlyOperator whenNotPaused {\n require(genesisStarted, \"Genesis not started\");\n\n uint256 currentRoundEpoch = currentEpoch;\n Round storage round = rounds[currentRoundEpoch];\n\n require(block.timestamp >= round.lockTimestamp, \"Too early to lock\");\n require(!round.settled, \"Round already settled\");\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pythUpdateData;\n\n uint256 fee = pyth.getUpdateFee(updateData);\n pyth.updatePriceFeeds{value: fee}(updateData);\n\n PythStructs.Price memory price = pyth.getPrice(priceId);\n\n round.lockPrice = price.price;\n round.lockTimestamp = block.timestamp;\n\n emit RoundLocked(currentRoundEpoch, round.lockPrice, block.timestamp);\n\n if (currentRoundEpoch > 1) {\n _settleRound(currentRoundEpoch - 1, price.price);\n }\n\n currentEpoch = currentRoundEpoch + 1;\n _startRound(currentEpoch);\n\n if (msg.value > fee) {\n (bool success, ) = msg.sender.call{value: msg.value - fee}(\"\");\n require(success, \"Refund failed\");\n }\n }\n\nit passes the calldata properly and the function runs all the way. however, whenever we retrieve prices via the contract, they are always 0. i tried reading the IPyth contract on Monad Testnet via javascript/ethers, and all the data was in place. However, whenever pyth.getPrice is being called via contract it returns 0. or i am not handling it properly. the address, abi and interface is the same in both cases.\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n I see few lines of code are redundant. You don’t have to create a new bytes array named updateData.\nRefer https://docs.pyth.network/price-feeds/use-real-time-data/evm#write-contract-code, change the data type of the input parameter to bytes[] calldata and use it directly.\nAlso getPrice has been deprecated, please use function getPriceNoOlderThan\nMay be create a simple version of the function and see if it works.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n i tried using bytes calldata in my previous contract, and it did not work for some reason. at least now it recognizes the calldata, so i’ll keep it like this because it does not revert. i also tried getPriceNoOlderThan(priceId, 20) right after the price update call, but i still get 0.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n and both of getPrice and getPriceNoOlderThan work properly called via js ethers script from the contract operator account. and they do have the values i need\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n That seems weird. Can you share which version of @pythnetwork/pyth-sdk-solidity are you using in your solidity smart contract.\nThere is additional logic involved other than getting pyth price feed.\nTo isolate the issue, can you try creating a simple version of function. Something similar to this pyth-pricefeed-demo/src/PriceFeed.sol at main · nidhi-singh02/pyth-pricefeed-demo · GitHub. Refer the README.md file for the instructions.\nRun it for your case as in Monad testnet and your asset pair and let me know the outcome please.\n\n post by howie228 on Jul 16, 2025\n\n howie228\n\n sure. using version 4.2.0 of pyth-sdk. will try to separate the update logic like in your example\n\n post by howie228 on Jul 17, 2025\n\n howie228\n\n update: i was finally able to update prices with actual data on my contract. your function separation helped most likely. i also rewrote quite a bit of code as well. but consider it solved\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":2278,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265336635,"hash":"050c618f0df23c1d002591c357b6fada1ba509f4"}
{"url":"https://docs.base.org/get-started/issue-stablecoins","domain":"docs.base.org","title":"Issue a Stablecoin - Base Documentation","text":"Issue a fiat-backed stablecoin on Base with B20, Base’s native token standard. Minting, redemption, compliance controls, and reconciliation ship with the chain, so there’s no custom contract to build or audit, and it’s fully ERC-20 compatible.\n​Demo\nScenario1Create2ConfirmVibenet account1Create tokenIn progress2ConfirmPendingCreate tokenCreate a fiat-backed token. Name, currency, and admin are set at creation.OperationCreate tokenTokenaUSDStandardB20NetworkBase VibenetTransaction event log--:--:--[PENDING]Create token--:--:--[PENDING]ConfirmOn plain ERC-20 you write, deploy, and audit a token contract.Real Vibenet transactions\nThe demo uses a local browser-generated account to submit real transactions on Base Vibenet. If Vibenet or its B20 features are unavailable, it automatically switches to an illustrative offline version.\n​Guides\nWas this page helpful?Suggest editsRaise issue","tokens":223,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265347208,"hash":"cdaca288265ce0181f2107028f3e93d8e6383c42"}
{"url":"https://dev-forum.pyth.network/t/cant-get-update-fee/298/1","domain":"dev-forum.pyth.network","title":"Cant get update fee - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Cant get update fee \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n Jul 2025\n\n 1 / 9\n\n Jul 2025\n\n Jul 2025\n\n post by howie228 on Jul 14, 2025\n\n howie228\n\n Network: Monad Testnet\nTimestamp: yesterday and today\nSteps to reproduce:\n\nGet price feed id (mine is BTC/USD)\nCall the Hermes API to retrieve binary data\nPass the binary data to getUpdateFee\nError: invalid arrayify value (argument=“value”, value=\nAdditional notes:\nI am trying to create a prediction game on monad testnet that utilizes Pyth price feeds with Pyth Pull Oracle, Hermes API and Gelato Web3 Automated functions. The flow goes like this:\nwe have a round. there is a 20 second threshold where the users could bet if the price is going to go up or down. then, after 20 seconds, the round locks. we then get the updated data from hermes API, push it to the pull oracle via Gelato operator, compare the new price against the players’ bets and reward whoever won.\nright now stuck at getting the fees\n\n 6\n\n 3\n\n post by nidhi on Jul 14, 2025\n\n nidhi\n\n Can you please share how you are calling getUpdateFee. Also share the complete error logs.\nFor your reference Price Feeds | Pyth Network API Reference , you can test it here.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n hi, sorry for the delayed answer. i already found the issue, it was a mismatch in the types inside the contract. now i dont get any errors, but i still get 0 updates on price feed retrieval inside of the contract.\nhere is the function i have trouble with:\n function executeRound(bytes calldata pythUpdateData) external payable onlyOperator whenNotPaused {\n require(genesisStarted, \"Genesis not started\");\n\n uint256 currentRoundEpoch = currentEpoch;\n Round storage round = rounds[currentRoundEpoch];\n\n require(block.timestamp >= round.lockTimestamp, \"Too early to lock\");\n require(!round.settled, \"Round already settled\");\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pythUpdateData;\n\n uint256 fee = pyth.getUpdateFee(updateData);\n pyth.updatePriceFeeds{value: fee}(updateData);\n\n PythStructs.Price memory price = pyth.getPrice(priceId);\n\n round.lockPrice = price.price;\n round.lockTimestamp = block.timestamp;\n\n emit RoundLocked(currentRoundEpoch, round.lockPrice, block.timestamp);\n\n if (currentRoundEpoch > 1) {\n _settleRound(currentRoundEpoch - 1, price.price);\n }\n\n currentEpoch = currentRoundEpoch + 1;\n _startRound(currentEpoch);\n\n if (msg.value > fee) {\n (bool success, ) = msg.sender.call{value: msg.value - fee}(\"\");\n require(success, \"Refund failed\");\n }\n }\n\nit passes the calldata properly and the function runs all the way. however, whenever we retrieve prices via the contract, they are always 0. i tried reading the IPyth contract on Monad Testnet via javascript/ethers, and all the data was in place. However, whenever pyth.getPrice is being called via contract it returns 0. or i am not handling it properly. the address, abi and interface is the same in both cases.\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n I see few lines of code are redundant. You don’t have to create a new bytes array named updateData.\nRefer https://docs.pyth.network/price-feeds/use-real-time-data/evm#write-contract-code, change the data type of the input parameter to bytes[] calldata and use it directly.\nAlso getPrice has been deprecated, please use function getPriceNoOlderThan\nMay be create a simple version of the function and see if it works.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n i tried using bytes calldata in my previous contract, and it did not work for some reason. at least now it recognizes the calldata, so i’ll keep it like this because it does not revert. i also tried getPriceNoOlderThan(priceId, 20) right after the price update call, but i still get 0.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n and both of getPrice and getPriceNoOlderThan work properly called via js ethers script from the contract operator account. and they do have the values i need\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n That seems weird. Can you share which version of @pythnetwork/pyth-sdk-solidity are you using in your solidity smart contract.\nThere is additional logic involved other than getting pyth price feed.\nTo isolate the issue, can you try creating a simple version of function. Something similar to this pyth-pricefeed-demo/src/PriceFeed.sol at main · nidhi-singh02/pyth-pricefeed-demo · GitHub. Refer the README.md file for the instructions.\nRun it for your case as in Monad testnet and your asset pair and let me know the outcome please.\n\n post by howie228 on Jul 16, 2025\n\n howie228\n\n sure. using version 4.2.0 of pyth-sdk. will try to separate the update logic like in your example\n\n post by howie228 on Jul 17, 2025\n\n howie228\n\n update: i was finally able to update prices with actual data on my contract. your function separation helped most likely. i also rewrote quite a bit of code as well. but consider it solved\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":2283,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265350835,"hash":"6de9b5c68d17e880856d9260c8d5c56b170a5539"}
{"url":"https://docs.base.org/get-started/issue-rwa","domain":"docs.base.org","title":"Tokenize Assets - Base Documentation","text":"Represent a real-world asset with the B20 Asset standard. Configure precision and issuer roles, distribute units, restrict eligible holders, and run distributions through one ERC-20-compatible surface built into Base. The guides below use a stock token as the worked example; the same flows apply to other asset types.\nReal-world asset (RWA) tokenization is one of many use cases for the B20 Asset standard. The examples on this page use a stock token for illustration; the same flows apply to other asset types.Tokenized securities examples shown for illustration. Base is a general-purpose blockchain; issuance and compliance are the responsibility of the issuer under applicable law.\n​Demo\nScenario1Create2Controls3IdentifyVibenet account1Create EXMIn progress2Apply controlsPending3Add identifierPendingCreate EXMDefine Example Corp Class A with six-decimal share precision.OperationCreate tokenSymbolEXMStandardB20 AssetNetworkBase VibenetTransaction event log--:--:--[PENDING]Create EXM--:--:--[PENDING]Apply controls--:--:--[PENDING]Add identifierB20 supplies a shared Asset standard instead of a custom token contract.Real Vibenet transactions\nThe demo uses a local browser-generated account to submit real transactions on Base Vibenet. If Vibenet or its B20 features are unavailable, it automatically switches to an illustrative offline version.\n​Guides\nWas this page helpful?Suggest editsRaise issue","tokens":352,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265357445,"hash":"4bb471f90e448e6c3afa4618ba46f197c3f6f9f8"}
{"url":"https://dev-forum.pyth.network/t/cant-get-update-fee/298/7","domain":"dev-forum.pyth.network","title":"Cant get update fee - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n Jul 2025\n\n 7 / 9\n\n Jul 2025\n\n Jul 2025\n\n post by howie228 on Jul 14, 2025\n\n howie228\n\n Network: Monad Testnet\nTimestamp: yesterday and today\nSteps to reproduce:\n\nGet price feed id (mine is BTC/USD)\nCall the Hermes API to retrieve binary data\nPass the binary data to getUpdateFee\nError: invalid arrayify value (argument=“value”, value=\nAdditional notes:\nI am trying to create a prediction game on monad testnet that utilizes Pyth price feeds with Pyth Pull Oracle, Hermes API and Gelato Web3 Automated functions. The flow goes like this:\nwe have a round. there is a 20 second threshold where the users could bet if the price is going to go up or down. then, after 20 seconds, the round locks. we then get the updated data from hermes API, push it to the pull oracle via Gelato operator, compare the new price against the players’ bets and reward whoever won.\nright now stuck at getting the fees\n\n 6\n\n 3\n\n post by nidhi on Jul 14, 2025\n\n nidhi\n\n Can you please share how you are calling getUpdateFee. Also share the complete error logs.\nFor your reference Price Feeds | Pyth Network API Reference , you can test it here.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n hi, sorry for the delayed answer. i already found the issue, it was a mismatch in the types inside the contract. now i dont get any errors, but i still get 0 updates on price feed retrieval inside of the contract.\nhere is the function i have trouble with:\n function executeRound(bytes calldata pythUpdateData) external payable onlyOperator whenNotPaused {\n require(genesisStarted, \"Genesis not started\");\n\n uint256 currentRoundEpoch = currentEpoch;\n Round storage round = rounds[currentRoundEpoch];\n\n require(block.timestamp >= round.lockTimestamp, \"Too early to lock\");\n require(!round.settled, \"Round already settled\");\n bytes[] memory updateData = new bytes[](1);\n updateData[0] = pythUpdateData;\n\n uint256 fee = pyth.getUpdateFee(updateData);\n pyth.updatePriceFeeds{value: fee}(updateData);\n\n PythStructs.Price memory price = pyth.getPrice(priceId);\n\n round.lockPrice = price.price;\n round.lockTimestamp = block.timestamp;\n\n emit RoundLocked(currentRoundEpoch, round.lockPrice, block.timestamp);\n\n if (currentRoundEpoch > 1) {\n _settleRound(currentRoundEpoch - 1, price.price);\n }\n\n currentEpoch = currentRoundEpoch + 1;\n _startRound(currentEpoch);\n\n if (msg.value > fee) {\n (bool success, ) = msg.sender.call{value: msg.value - fee}(\"\");\n require(success, \"Refund failed\");\n }\n }\n\nit passes the calldata properly and the function runs all the way. however, whenever we retrieve prices via the contract, they are always 0. i tried reading the IPyth contract on Monad Testnet via javascript/ethers, and all the data was in place. However, whenever pyth.getPrice is being called via contract it returns 0. or i am not handling it properly. the address, abi and interface is the same in both cases.\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n I see few lines of code are redundant. You don’t have to create a new bytes array named updateData.\nRefer https://docs.pyth.network/price-feeds/use-real-time-data/evm#write-contract-code, change the data type of the input parameter to bytes[] calldata and use it directly.\nAlso getPrice has been deprecated, please use function getPriceNoOlderThan\nMay be create a simple version of the function and see if it works.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n i tried using bytes calldata in my previous contract, and it did not work for some reason. at least now it recognizes the calldata, so i’ll keep it like this because it does not revert. i also tried getPriceNoOlderThan(priceId, 20) right after the price update call, but i still get 0.\n\n post by howie228 on Jul 15, 2025\n\n howie228\n\n and both of getPrice and getPriceNoOlderThan work properly called via js ethers script from the contract operator account. and they do have the values i need\n\n post by nidhi on Jul 15, 2025\n\n nidhi\n\n That seems weird. Can you share which version of @pythnetwork/pyth-sdk-solidity are you using in your solidity smart contract.\nThere is additional logic involved other than getting pyth price feed.\nTo isolate the issue, can you try creating a simple version of function. Something similar to this pyth-pricefeed-demo/src/PriceFeed.sol at main · nidhi-singh02/pyth-pricefeed-demo · GitHub. Refer the README.md file for the instructions.\nRun it for your case as in Monad testnet and your asset pair and let me know the outcome please.\n\n post by howie228 on Jul 16, 2025\n\n howie228\n\n sure. using version 4.2.0 of pyth-sdk. will try to separate the update logic like in your example\n\n post by howie228 on Jul 17, 2025\n\n howie228\n\n update: i was finally able to update prices with actual data on my contract. your function separation helped most likely. i also rewrote quite a bit of code as well. but consider it solved\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 654\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":2278,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265361502,"hash":"81e1cccdc74fb4d5579d8dcc64190458bfee1b21"}
{"url":"https://dev-forum.pyth.network/t/we-are-facing-an-issue-with-the-update-price-feeds-with-funder-function-when-updating-the-pyth-price/144/1","domain":"dev-forum.pyth.network","title":"We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n May 2025\n\n 1 / 4\n\n May 2025\n\n May 2025\n\n post by Ajay on May 9, 2025\n\n Ajay\n\n I am using the update_price_feeds_with_funder function to generate the payload and submit a transaction every 30 seconds.\nMy price feed ID is:\n0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\nThe testnet endpoint I’m using is:\nhttps://hermes-beta.pyth.network/v2/updates/price/stream?ids[]\nIn my code, I’ve added logs to verify the fetched price, and the price updates correctly on each transaction. For example:\n\nFirst transaction:\nprice: '563526640', publish_time: 1746776909\nNext transaction:\nprice: '563596450', publish_time: 1746776939\n\nThe transactions are being submitted successfully. However, some transactions do not return any events, even though they are confirmed on-chain.\nThis inconsistency is causing issues — in particular, we are seeing the following Pyth error:\npyth: 0x80004\nThis is my code:\n\nconst priceIds = \"0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\";\nconst connection = new HermesClient(\"https://hermes-beta.pyth.network/v2/updates/price/stream?ids[]\", {});\nconst priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n});\nconst binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n);\nconst payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n} as InputEntryFunctionData;\n\nCan someone please look into this and help us resolve the issue?\n\n 2\n\n 2\n\n post by ali on May 9, 2025\n\n ali\n\n Hey @Ajay, the transaction returns an event once the on-chain state changes and when it doesn’t change it means that the provided update data was not more fresh than the existing one. Are you sure that each time you are sending the transaction the update time is increasing? If so can you log the update data as well as the publish_time between updates and share the information about two consecutive updates?\nThe error 80004 also means price is stale; in your context it probably means that update data you sent was not fresh, the state didn’t get updated, and when you used it it passed your staleness threshold. What is your staleness threshold?\n\n post by Ajay on May 9, 2025\n\n Ajay\n\n Hi @ali\nHere is the Information about two consecutive updates:\nIn the first transaction:\n\nPrice: 569261464\nPublish Time: 1746787890\nAn event was emitted.\n\nIn the second transaction:\n\nPrice: 568762401\nPublish Time: 1746787919\nNo event was emitted.\n\nIn the third transaction:\n\nPrice: 569150459\nPublish Time: 1746787950\nAn event was emitted.\n\nAs you can see, the price and publish_time are different in all three transactions. However, only two of them emitted an event, while one did not.\n\nEvent Emitted Hash: 0xc95fbde9fff563ebf8a56b0bf236d41ace94b68efd83e6db159bdb0e9a04ef4d\nEvent Not Emitted Hash: 0x565ef6758a82b76a41a0395b718b5288f5f4264d13ebd9043a8fb71f85004a92\n\nCould you pls look into this.\n\n post by ali on May 9, 2025\n\n ali\n\n I checked this and it seems there was another transaction right before the one with no events that had the exact same update. that’s why. It seems others (or maybe yourself with a different account) are updating the price at the same time.\nThat being said it should not cause the staleness issue then. How often do you see it.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n Powered by Discourse","tokens":1951,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265383825,"hash":"77dcaedf1f436977cbd47e893db4ed68cd2a3510"}
{"url":"https://dev-forum.pyth.network/t/we-are-facing-an-issue-with-the-update-price-feeds-with-funder-function-when-updating-the-pyth-price/144/4","domain":"dev-forum.pyth.network","title":"We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n May 2025\n\n 4 / 4\n\n May 2025\n\n May 2025\n\n post by Ajay on May 9, 2025\n\n Ajay\n\n I am using the update_price_feeds_with_funder function to generate the payload and submit a transaction every 30 seconds.\nMy price feed ID is:\n0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\nThe testnet endpoint I’m using is:\nhttps://hermes-beta.pyth.network/v2/updates/price/stream?ids[]\nIn my code, I’ve added logs to verify the fetched price, and the price updates correctly on each transaction. For example:\n\nFirst transaction:\nprice: '563526640', publish_time: 1746776909\nNext transaction:\nprice: '563596450', publish_time: 1746776939\n\nThe transactions are being submitted successfully. However, some transactions do not return any events, even though they are confirmed on-chain.\nThis inconsistency is causing issues — in particular, we are seeing the following Pyth error:\npyth: 0x80004\nThis is my code:\n\nconst priceIds = \"0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\";\nconst connection = new HermesClient(\"https://hermes-beta.pyth.network/v2/updates/price/stream?ids[]\", {});\nconst priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n});\nconst binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n);\nconst payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n} as InputEntryFunctionData;\n\nCan someone please look into this and help us resolve the issue?\n\n 2\n\n 2\n\n post by ali on May 9, 2025\n\n ali\n\n Hey @Ajay, the transaction returns an event once the on-chain state changes and when it doesn’t change it means that the provided update data was not more fresh than the existing one. Are you sure that each time you are sending the transaction the update time is increasing? If so can you log the update data as well as the publish_time between updates and share the information about two consecutive updates?\nThe error 80004 also means price is stale; in your context it probably means that update data you sent was not fresh, the state didn’t get updated, and when you used it it passed your staleness threshold. What is your staleness threshold?\n\n post by Ajay on May 9, 2025\n\n Ajay\n\n Hi @ali\nHere is the Information about two consecutive updates:\nIn the first transaction:\n\nPrice: 569261464\nPublish Time: 1746787890\nAn event was emitted.\n\nIn the second transaction:\n\nPrice: 568762401\nPublish Time: 1746787919\nNo event was emitted.\n\nIn the third transaction:\n\nPrice: 569150459\nPublish Time: 1746787950\nAn event was emitted.\n\nAs you can see, the price and publish_time are different in all three transactions. However, only two of them emitted an event, while one did not.\n\nEvent Emitted Hash: 0xc95fbde9fff563ebf8a56b0bf236d41ace94b68efd83e6db159bdb0e9a04ef4d\nEvent Not Emitted Hash: 0x565ef6758a82b76a41a0395b718b5288f5f4264d13ebd9043a8fb71f85004a92\n\nCould you pls look into this.\n\n post by ali on May 9, 2025\n\n ali\n\n I checked this and it seems there was another transaction right before the one with no events that had the exact same update. that’s why. It seems others (or maybe yourself with a different account) are updating the price at the same time.\nThat being said it should not cause the staleness issue then. How often do you see it.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 421\n\n Oct 2025\n\n Powered by Discourse","tokens":1925,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265396956,"hash":"30c9abe371f5b24dadb64610d971805b2304f1d0"}
{"url":"https://docs.base.org/sdks/base-anvil","domain":"docs.base.org","title":"base-anvil CLI - Base Documentation","text":"base-anvil is a fork of Foundry that teaches forge, cast, anvil, and chisel about Base’s native precompiles — the B20 token factory, B20 tokens, the PolicyRegistry, and the ActivationRegistry. Stock Foundry can’t reach these precompile addresses and aborts with call to non-contract address; base-anvil registers them into its EVM so you can build and test Base apps locally.\n​Install\nIt installs alongside your existing Foundry without overwriting stock foundryup or your forge/cast/anvil/chisel:\nTerminalcurl -L https://raw.githubusercontent.com/base/base-anvil/HEAD/foundryup/install | bash\nbase-foundryup\n\nThis adds base-foundryup and the namespaced base-forge, base-cast, base-anvil, and base-chisel commands, which enable Base precompiles by default.\n​Pick a Base Version\nbase-anvil’s versioned releases are named after the Base chain release they target. Pin a release with:\nTerminalbase-foundryup --install <version>\n\n​Commands\nCommandStands in forPurposebase-forgeforgeBuild, test, and deploy contracts against Base precompilesbase-castcastSend transactions and read chain data, including precompile callsbase-anvilanvilRun a local Base node with precompiles enabledbase-chiselchiselSolidity REPL with Base precompiles\nEverything else is inherited from upstream Foundry and works unchanged; only the Base additions above are specific to this fork.\n​Next Steps\nWas this page helpful?Suggest editsRaise issue","tokens":354,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265412200,"hash":"4fdf0a2212f0ecf460553c15579e9159818dea14"}
{"url":"https://governance.aave.com/t/direct-to-aip-onboard-btc-b-to-aave-v4-core-instance-on-ethereum/25532/2","domain":"governance.aave.com","title":"[Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 25\n\n 2 / 2\n\n Sep 16\n\n Sep 16\n\n post by AaveLabs on Aug 25\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Title: [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\nAuthor: @AaveLabs\nDate: 2026-08-25\n\nSummary\nThis proposal seeks to onboard BTC.b to the Aave V4 Core Instance on Ethereum. This proposal follows the Direct to AIP route.\nMotivation\nBTC.b is a bridged representation of Bitcoin supported by Lombard’s infrastructure. BTC.b is already listed on the Aave V3 Core Instance and Aave V4 Core Instance on Avalanche, and this proposal extends its availability to the Aave V4 Core Instance on Ethereum.\nThe onboarding would expand the BTC collateral options available through Aave V4 while allowing the DAO and its Service Providers to apply a configuration specific to V4.\nSpecification\nThis proposal onboards BTC.b to the Aave V4 Core Instance on Ethereum.\nBTC.b: 0xB0F70C0bD6FD87dbEb7C10dC692a2a6106817072\nRisk parameters and final configuration will be provided by the Risk Service Providers and this proposal will be updated accordingly.\nUseful Links\n\nDocumentation\nFrequently asked questions\n\nDisclaimer\nThis proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no direct financial relationship with Lombard Finance or its affiliates and has not received compensation from Lombard Finance or its affiliates in connection with this proposal.\nNext Steps\n\nGather community and Service Provider feedback.\nIncorporate the Risk Service Providers’ final configuration for the Aave V4 Core Instance.\nPublish the AIP vote for final confirmation and onchain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n 22 days later\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding BTC.b to the Aave V4 Core Hub on Ethereum, conditional on the segregation of BTC custody between Lombard’s BTC.b and LBTC products, which are currently backed by a pooled custody structure. Lombard has confirmed that per-asset custody segregation is planned and is expected to be implemented within the next couple of weeks. While Lombard’s aggregate reserves are sufficient to fully collateralize both products, dedicated custody for BTC.b would ensure that its backing remains independent of LBTC-related exposures.\nBeyond the above consideration, BTC.b benefits from robust administrative safeguards. Contract upgrades are subject to a 1-day timelock enforced by LombardTimeLock, with the executor controlled by Lombard’s 3/5 Safe multisig. The Bascule check is also enabled on the Ethereum BTC.b contract, providing an additional layer of verification for mints. The protocol also maintains an active bug bounty program, and recent audits have not identified any critical or high-severity findings. BTC.b currently has approximately $7.9M in DEX liquidity on Ethereum, nearly 100% of which is supplied by the Lombard team. While highly concentrated, this liquidity is relatively stable given its protocol-aligned nature and lower reliance on third-party LPs.\nThe full assessment can be found in its corresponding thread.\nAave V4 Specific Parameters\nSpoke Parameters\n\nChain\nHub\nSpoke\nReserve\nCollateral Factor\nMax Liquidation Bonus\nBorrowable\nCollateral Risk\nLiquidation Fee\nRisk Premium Threshold\nReceive Shares\n\nEthereum\nCore Hub\nMain Spoke\nBTC.b\n78%\n5.55%\nFALSE\n0\n10%\n0\nTRUE\n\nAdd and Draw Caps\n\nChain\nHub\nSpoke\nReserve\nAdd Cap\nDraw Cap\n\nEthereum\nCore Hub\nMain Spoke\nBTC.b\n200\n0\n\nPrice feed Recommendation\nWe recommend using Chainlink’s BTC/USD SVR feed to price BTC.b on Aave V4.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n This topic will close a month after the last reply.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n BTC.b on Aave Ethereum\n\n Assessments\n\n 1\n\n 75\n\n Sep 16\n\n [Direct to AIP] Onboard BTC.b to Aave V3 Core Instance\n\n New Asset\n\n 5\n\n 704\n\n Mar 19\n\n [ARFC] Onboard EURCV to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 2\n\n 200\n\n Sep 17\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n General\n\n 14\n\n 2.1k\n\n Jul 8\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 258\n\n Sep 21","tokens":1180,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265438076,"hash":"8750fc83388100b1148e916b755f70a8c12575ca"}
{"url":"https://forum.soliditylang.org/t/are-there-any-efforts-to-improve-or-standardize-translations-of-solidity-documentation/3693","domain":"forum.soliditylang.org","title":"Are there any efforts to improve or standardize translations of Solidity documentation? - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Are there any efforts to improve or standardize translations of Solidity documentation? \n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 9\n\n 1 / 3\n\n Apr 10\n\n Jun 2\n\n post by alishawinson on Apr 9\n\n alishawinson\n\n Hi everyone,\nI’ve been going through the official Solidity documentation and found it really well-structured, but I was wondering about its accessibility for non-English speakers. Are there any ongoing community efforts or official initiatives to translate the documentation into other languages? If so, how are those translations download from here and kept in sync with frequent updates?\nAlso, for those who’ve used translated versions, do you find them reliable enough for learning and development, or do you still rely mostly on the original English docs?\n\n post by czepluch on Apr 13\n\n czepluch\n\n Solidity Team\n\n Hi and welcome!\nThank you for sharing your feedback.\nWe have a bunch of translation efforts going on here: Solidity Documentation Translations · GitHub. In this org you can find a variety of different translations. Some are more maintained than others. If your language is currently not up-to-date I recommend opening and issue in the repo with the language you want, requesting that it will get up-to-date. Or even better, open a Pull Request getting the translation up-to-date.\nYou can also check out the Matrix channel: https://matrix.to/#/#solidity-docs-translations:matrix.org\nEither way, if you let me know the language you’re looking for, I can try to get in touch with the maintainers.\n\n 2 months later\n\n post by hwhsu1231 on Jun 2\n\n hwhsu1231\n\n Hello @alishawinson,\n\nI am the author of the Localize The Docs organization. It’s my pleasure to invite you to join the translation of the solidity-docs-l10n project:\n\n Preview: solidity-docs-l10n\n Crowdin: solidity-docs-l10n\n GitHub: solidity-docs-l10n\n\nThe goal of this project is to translate The Solidity Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.\nIf the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!\nSee the announcement post for more details.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n [Call for feedback] Core Solidity Deep Dive\n\n Uncategorized\n\n 5\n\n 613\n\n Dec 2025\n\n What Solidity try/catch actually catches\n\n Code Wizards\n\n 1\n\n 121\n\n May 29\n\n Eager require evaluation is unexpected\n\n Language Design\n\n 2\n\n 93\n\n Aug 4\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1578,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265443920,"hash":"35eeaee00cc7f62dfe93c09e493cef6e720a2f76"}
{"url":"https://governance.aave.com/t/btc-b-on-aave-ethereum/25652/2","domain":"governance.aave.com","title":"BTC.b on Aave Ethereum - Risk / Assessments - Aave","text":"RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 16\n\n 2 / 2\n\n Sep 16\n\n Sep 16\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of BTC.b on Aave Ethereum.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 6\n min\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding BTC.b to the Aave V4 Core Hub on Ethereum, conditional on the segregation of BTC custody between Lombard’s BTC.b and LBTC products, which are currently backed by a pooled custody structure. Lombard has confirmed that per-asset custody segregation is planned and is expected to be implemented within the next couple of weeks. While Lombard’s aggregate reserves are sufficient to fully collateralize both products, dedicated custody for BTC.b would ensure that its backing remains independent of LBTC-related exposures.\nBeyond the above consideration, BTC.b benefits from robust administrative safeguards. Contract upgrades are subject to a 1-day timelock enforced by LombardTimeLock, with the executor controlled by Lombard’s 3/5 Safe multisig. The Bascule check is also enabled on the Ethereum BTC.b contract, providing an additional layer of verification for mints. The protocol also maintains an active bug bounty program, and recent audits have not identified any critical or high-severity findings. BTC.b currently has approximately $7.9M in DEX liquidity on Ethereum, nearly 100% of which is supplied by the Lombard team. While highly concentrated, this liquidity is relatively stable given its protocol-aligned nature and lower reliance on third-party LPs.\n1. Asset Fundamental Characteristics\n1.1 Asset\nAccording to the Aave Asset Class Allowlist (AAcA), Cross-chain Bitcoin (BTC.b) is classified as a bridged BTC wrapper, and assets of this category have already been listed on Aave. BTC.b is an ERC20 token on Ethereum, Avalanche, Katana, MegaETH, Monad, and Stable, backed 1:1 by BTC. BTC.b is issued against native BTC deposited on the Bitcoin network and secured through Lombard’s custody infrastructure, with issuance and accounting maintained on the Lombard Ledger. Approximately 2,115 BTC.b ($167M) is currently in circulation, with the majority of the supply residing on Avalanche at 2,012 BTC.b ($159M), while Ethereum accounts for 72.18 BTC.b ($5.7M).\n1.2 Architecture\nBTC.b is minted primarily against native BTC deposits on the Bitcoin Network, with consortium-notarised proofs confirmed through the Bascule. On Ethereum, the AssetRouter and BridgeV2 hold the only MINTER_ROLE, while the AssetRouter also facilitates BTC.b/LBTC conversions through the Lombard Ledger. BTC.b can be redeemed for native BTC through supported Bitcoin output scripts, subject to a 0.0001 BTC fee, while cross-chain transfers burn BTC.b on the source chain and mint it on the destination chain. There are no on-chain cooldowns or queues, with settlement times determined operationally. On Ethereum, BTC.b-to-BTC redemptions generally settle within hours (1 hour median), while LBTC-to-BTC.b conversions can take days (9.5 days median).\nThe BTC.b architecture remains unchanged since our prior review in February 2026, except for a reduction in the Security Consortium from 15 to 14 members. The signer threshold remains 10-of-14, with the current consortium comprising Amber, Antpool, Chorus One, DCG, Cubist, f2pool, Figment, Galaxy, Kraken, Kiln, Nansen, OKX, P2P, and Wintermute. The Bascule check on the Ethereum BTC.b contract was enabled on September 1, 2026. Before this, Ethereum mints relied solely on Consortium proofs. On Avalanche, the corresponding Bascule check has been enabled since January 29, 2026.\nBTC Reserves\nLombard’s Bitcoin reserves total 10,919.51 BTC across the 29,192 addresses published in its on-chain Proof-of-Reserve (PoR) list. These reserves are sufficient to fully back the outstanding supply of BTC.b and LBTC, with the Chainlink protocol-level PoR feed reporting 10,919.27 BTC, a difference of 0.25 BTC.\n\nMeasure\nBTC\n\nSum of the 29,243 PoR addresses\n10,919.51\n\nChainlink protocol-level Proof-of-Reserve feed\n10,919.27\n\nDifference\n0.25 (0.002%)\n\nBTC.b float (Avalanche, Ethereum, MegaETH, Stable, Katana, Monad)\n2,115.44 BTC\n\nLBTC float (Ethereum, Base, Avalanche, BSC, Berachain, Corn, Etherelink, Katana, MegaETH, Monad, Stable, Sonic, Solana, Starknet, Sui, Swell, TAC)\n8,742.84 LBTC\n\nLBTC float in BTC terms, at 1.00488299 BTC per LBTC\n8,785.53 BTC\n\nLBTC, buffer allocation\n7,436.69 BTC\n\nLBTC, active allocation into covered-call mandate (held in tri-party custody)\n1,348.84 BTC\n\nIdentified issuance\n10,900.97\n\nReserve in excess of identified issuance\n18.54 (0.17%)\n\nThe aggregate reserve position is therefore adequate, but the key consideration for BTC.b is whether its backing remains economically segregated from LBTC reserves. This became particularly relevant during July and August 2026, when Lombard transitioned LBTC from Babylon staking to a covered-call mandate managed by Bitwise, as seen below.\nimage2052×1211 167 KB\nSource: LlamaRisk, September 14, 2026\nHistorically, BTC.b and LBTC backing were held in separate addresses, with BTC.b reserves primarily held in bc1qt688…zuke. This address currently holds 8,020.37 BTC, or 73.45% of Lombard’s total reserves, equivalent to approximately 3.85x the entire BTC.b float. It received the consolidated BTC.b reserves during the January 2026 migration to Lombard infrastructure, and its balance subsequently declined in line with BTC.b redemptions. On August 6-7, 2026, it received a further 8,190.60 BTC from Lombard’s operational wallet, materially increasing the concentration of reserves in this address. The current reserve structure is as follows:\n\nAddress\nGrouping\nBTC held\nShare of reserve\nFirst active\n\nbc1qt688…zuke\nPooled custody\n8,020.37\n73.45%\n27 January 2026\n\nbc1q5c2h…uvy5\nNew custody (LBTC active sleeve)\n1,297.78\n11.88%\n6 August 2026\n\nbc1qmcdp…j3gp\nOperational wallet\n1,229.76\n11.26%\n21 August 2024\n\nbc1pxvj7…xss7\nOther custody\n55.00\n0.50%\n9 September 2026\n\nbc1ptere…5juy\nOther custody\n5.00\n0.05%\n19 August 2026\n\nbc1qm8va…cs63\nOther custody\n3.19\n0.03%\n30 July 2025\n\nbc1q5mks…gzk8\nOther custody\n2.64\n0.02%\n6 August 2025\n\nThe concern remains around how the ~2,115 BTC backing BTC.b is allocated across the custody groupings. Lombard currently uses many per-user deposit addresses for each asset alongside four protocol coordination wallets, with BTC.b and LBTC reserves co-mingled across these addresses. While aggregate reserves are sufficient, the PoR does not establish that BTC.b’s backing is segregated from LBTC. If reserves are pooled, a shortfall in LBTC operations could reduce the backing available to BTC.b holders, creating interdependence between the two assets.\nWe therefore recommend per-asset segregation of the protocol coordination wallets and a clear mapping of BTC.b reserves to dedicated custody addresses that maintain coverage at or above BTC.b supply. This would provide stronger assurance that BTC.b holders have a dedicated reserve pool and preserve BTC.b and LBTC as independent collateral exposures for Aave.\nBridge Risk\nLombard uses Chainlink CCIP to enable cross-chain bridging via a Burn-and-Mint mechanism. The attester set on CCIP comprises a Decentralized Oracle Network (DON) of 16 node operators (the same operator set used by Chainlink’s price feeds), which includes two off-chain plugins: the Commit DON and the Execute DON. The on-chain commit threshold requires 6-of-16 signatures, while the off-chain libOCR consensus protocol requires 11-of-16 operators to agree before a commit report can leave the DON.\nThe BTC.b bridge has 6 listed networks: Ethereum, Avalanche, Katana, MegaETH, Monad, and Stable. The CCIP bridge implements a 50 BTC.b 24h token bucket capacity for every active pathway, as shown below.\nimage1391×1244 67.3 KB\nSource: LlamaRisk, September 14, 2026\n1.3 Tokenomics\nThe total supply of BTC.b is variable and expands or contracts based on user-driven bridging of native BTC. On Ethereum, the circulating supply currently stands at 72.18 BTC.b, held across just 283 unique addresses.\nIn contrast, the majority of BTC.b supply resides on Avalanche, with approximately 2,011.89 BTC.b outstanding. Smaller allocations exist on other networks, including Monad, MegaETH, Stable, and Katana, bringing the aggregate cross-chain supply to ~2,115 BTC.b.\n1.3.1 Token Holder Concentration\nimage1183×343 27.1 KB\nSource: BTC.b Top 100 Token Holders, Etherscan, September 14, 2026\nThe top holders of BTC.b are:\n\nUniswap V4 BTC.b/cbBTC: 71.63% of the total supply.\nAave V3 aEthBTCb: 20.51% of the total supply.\nEOA A: 3.40% of the total supply.\nEOA B: 2.52% of the total supply.\n\nThe top three holders collectively control 98.05% of BTC.b’s total supply on Ethereum, with 92.14% held on Uniswap V4 and Aave V3 Core.\n2. Market Risk\n2.1 Liquidity\nimage968×645 52.7 KB\nSource: DeFiLlama, September 14, 2026\nUsers can swap 51.5 BTC.b for ~$3.77M USDC within a price impact of 7.5%.\n2.1.1 Liquidity Venue Concentration\nimage2059×1229 137 KB\nSource: LlamaRisk, September 14, 2026\nOn-chain liquidity for BTC.b on Ethereum is concentrated in a Uniswap V4 BTC.b/cbBTC pool ($7.89M TVL). As this is a dual-BTC wrapper pool, BTC.b-to-stablecoin swaps ultimately depend on the depth and liquidity of cbBTC’s secondary markets.\n2.1.2 DEX LP Concentration\nBTC.b liquidity on Ethereum is highly concentrated, with the Lombard team accounting for nearly all DEX liquidity. Lombard BTC Vault is the primary supplier to the Uniswap V4 BTC.b/cbBTC pool, contributing nearly 100% of the pool’s liquidity. While this represents near-exclusive reliance on a single liquidity provider, the provider is protocol-aligned, reducing the likelihood of rapid liquidity outflows and supporting the stability of the pool’s available liquidity.\n2.2 Volatility\nimage1754×943 35.5 KB\nSource: GeckoTerminal, September 14, 2026\nBTC.b has consistently maintained its 1:1 peg to BTC across secondary markets over the past month. Since the pool was seeded with 100 BTC of cbBTC liquidity on August 12, 2026, it has subsequently attracted trading activity, supporting healthy price discovery and overall trading dynamics.\n2.3 Exchanges\nBTC.b is exclusively traded on DEXs and is not currently listed on any centralized exchange.\n2.4 Growth\nimage2052×1229 132 KB\nSource: LlamaRisk, September 14, 2026\nSince its deployment on Ethereum, BTC.b has experienced steady growth, reaching a peak circulating supply of approximately 150 in August 2026. As of September 14, the circulating supply on Ethereum stands at 72.18 BTC.b ($5.45M).\n3. Technological Risk\nThe BTC.b technological risk on Ethereum, including smart contract risk, bug bounty program, and dependency risk, remains unchanged since our prior review and is excluded here for brevity, as no new contracts have been deployed.\n4. Counterparty Risk\n4.1 Governance and Regulatory Risk\nThe regulatory risk has been previously discussed in detail as part of the BTC.b Aave V3 Core onboarding review. As there have been no material changes, that assessment remains applicable here.\n4.2 Access Control Risk\n4.2.1 Contract Modification Options\nHere are the wallets controlling BTC.b on Ethereum:\n\nLombardTimeLock: Admin and owner of the BTC.b, AssetRouter, BridgeV2, and LombardConsortium contracts.\nMultisig1: Lombard-controlled 3/5 Safe, holds executor/proposer/canceller roles of the LombardTimeLock contract and can pause the BTC.b contract.\n\nThe following contracts power the BTC.b architecture on Ethereum:\n\nBTC.b: Upgradeable ERC20 contract for the BTC.b token controlled by LombardTimeLock.\nAssetRouter: Upgradeable contract, handles deposit/redemption orchestration and fee accounting, owned by LombardTimeLock.\nBridgeV2: Upgradeable contract, handles bridge execution for burn-and-mint transfers, owned by LombardTimeLock.\nLombardConsortium: Upgradeable contract, epoch-weighted multi-signature verifier, owned by LombardTimeLock.\n\nA role-based access control mechanism is employed for BTC.b to manage sensitive functions:\n\nControlling Addresses\nRole\nFunctionality\n\nLombardTimeLock\nDEFAULT_ADMIN_ROLE\nCan grant/revoke any role\n\nBridgeV2, AssetRouter\nMINTER_ROLE\nCan mint BTC.b\n\nMultisig1, Multisig2\nPAUSER_ROLE\nCan pause the contract\n\nEOA 1\nOPERATOR_ROLE\nManages configuration parameters and executes operational tasks\n\nEOA 1\nCLAIMER_ROLE\nWatches BTC deposits, consortium proofs, and submits mint+fee transactions on the user’s behalf\n\n4.2.2 Timelock Duration and Function\nA 1-day (86400 seconds) delay has been implemented for BTC.b contract upgrades via the LombardTimeLock.\n4.2.3 Multisig Threshold / Signer identity\nLombard controlled Multisig1 (3/5 Safe) holds is the executor of the LombardTimeLock contract, which has the following role-based access control:\n\nControlling Addresses\nRole\nFunctionality\n\nLombardTimeLock\nROLE_ADMIN\nCan update roles, including the role admin role itself\n\nMultisig1\nEXECUTOR_ROLE\nCan execute all proposals, including role updates\n\nEOA 2, Multisig1\nPROPOSER_ROLE\nCan schedule proposals, but can not schedule role updates\n\nMultisig1\nCANCELLER_ROLE\nCan unschedule proposals, but can not unschedule role updates\n\nThe 3/5 Safe Multisig1 has the following signers:\n\n0xd7B78BF124eB327F23f75F5C49De0c3fa5d2265A\n0x116744098070508c080B120A555B5453422b66eF\n0x70B9b04b19D9015EfBe1db37BBe30Dd304737950\n0xd775959eb15f6DfF24A267f988F6c2E2f769DeDa\n0xDD48B7cfd0c2256E008B7C690Fbe47ca77CD6071\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct to AIP] Onboard BTC.b to Aave V3 Core Instance\n\n New Asset\n\n 5\n\n 704\n\n Mar 19\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 1\n\n 158\n\n Sep 16\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 105\n\n Sep 18\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n General\n\n 14\n\n 2.1k\n\n Jul 8\n\n [ARFC] Onboard cirBTC on Aave v3 Core and Aave V4 Core\n\n New Asset\n\n 4\n\n 474\n\n Sep 1","tokens":3749,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265450163,"hash":"10d0e75e3d08283b0cc7b26a1ebec4f4abc7f94b"}
{"url":"https://forum.soliditylang.org/t/are-there-any-efforts-to-improve-or-standardize-translations-of-solidity-documentation/3693/2","domain":"forum.soliditylang.org","title":"Are there any efforts to improve or standardize translations of Solidity documentation? - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 9\n\n 2 / 3\n\n Apr 13\n\n Jun 2\n\n post by alishawinson on Apr 9\n\n alishawinson\n\n Hi everyone,\nI’ve been going through the official Solidity documentation and found it really well-structured, but I was wondering about its accessibility for non-English speakers. Are there any ongoing community efforts or official initiatives to translate the documentation into other languages? If so, how are those translations download from here and kept in sync with frequent updates?\nAlso, for those who’ve used translated versions, do you find them reliable enough for learning and development, or do you still rely mostly on the original English docs?\n\n post by czepluch on Apr 13\n\n czepluch\n\n Solidity Team\n\n Hi and welcome!\nThank you for sharing your feedback.\nWe have a bunch of translation efforts going on here: Solidity Documentation Translations · GitHub. In this org you can find a variety of different translations. Some are more maintained than others. If your language is currently not up-to-date I recommend opening and issue in the repo with the language you want, requesting that it will get up-to-date. Or even better, open a Pull Request getting the translation up-to-date.\nYou can also check out the Matrix channel: https://matrix.to/#/#solidity-docs-translations:matrix.org\nEither way, if you let me know the language you’re looking for, I can try to get in touch with the maintainers.\n\n 2 months later\n\n post by hwhsu1231 on Jun 2\n\n hwhsu1231\n\n Hello @alishawinson,\n\nI am the author of the Localize The Docs organization. It’s my pleasure to invite you to join the translation of the solidity-docs-l10n project:\n\n Preview: solidity-docs-l10n\n Crowdin: solidity-docs-l10n\n GitHub: solidity-docs-l10n\n\nThe goal of this project is to translate The Solidity Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.\nIf the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!\nSee the announcement post for more details.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Request new syntax for Solidity\n\n Uncategorized\n\n 3\n\n 193\n\n Feb 17\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1547,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265455535,"hash":"6bf21a21f3685a1680ac3a88502acd692b04c74d"}
{"url":"https://ethresear.ch/t/almost-instant-interactive-fraud-proof-using-multi-sect-on-da-blobs-and-multi-step-zk-verifier/16169","domain":"ethresear.ch","title":"Almost Instant Interactive Fraud Proof using Multi-Sect on DA BLOBs and multi-step ZK verifier - Sharding - Ethereum Research","text":"Almost Instant Interactive Fraud Proof using Multi-Sect on DA BLOBs and multi-step ZK verifier \n\n Sharding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2023\n\n 1 / 1\n\n Jul 2023\n\n Jul 2023\n\n post by qizhou on Jul 24, 2023\n\n qizhou\n\n Many thanks @Canhui.Chen for discussing the idea.\nGoal\nThe goal of the proposal is to reduce the challenge-response interactive times of optimistic fraud-proof protocol to 1-3 times using\n\na DA BLOB consists of 4096 challenge points (e.g., statehashes of intermediate states to be challenged)\na zkVM verifier (e.g., zkWASM in GitHub - DelphinusLab/zkWasm · GitHub) that can verifier a 100k or more sequence instructions on-chain\n\nBackground\nCurrent interactive fraud-proof challenge protocol such as Optimism fault proof system uses\n\nbinary search to narrow down the specific step/instruction of disagreement between the sequencer and the challenger (optimism/specs/fault-proof.md at e7a25442ae03c2858076b9df6ea7f638287adb2e · ethereum-optimism/optimism · GitHub)\nwhen the specific step of disagreement is found, a one-step on-chain executor to determine whether sequencer or challenger is correct (https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/cannon/MIPS.sol).\n\nConsidering about 40+B steps (instructions) per block transition (e.g., optimism/cannon/README.md at e7a25442ae03c2858076b9df6ea7f638287adb2e · ethereum-optimism/optimism · GitHub), the protocol will take about 36 interactions, which is costly in both time and gas.\nProposal\nThe proposal solves the problem by allowing a challenger to submit 4096 intermediate execution results (aka, statehashes) in a single challenge transaction. The 4096 statehashes are not submitted by calldata nor stored on-chain - the statehashes are uploaded in a DA BLOB defined in EIP-4844, and only the datahash of the 4096-statehashes is stored on-chain. Since a BLOB has 128KB size, we can put 4096 statehashes in a single BLOB (proper hash-to-field-element mapping is required). With this, we would expect much lower gas cost (given that EIP-4844 and the following danksharding upgrade will significantly reduce the cost a DA BLOB vs calldata).\nTo answer the challenge, the sequencer will pick up one of 4096 statehashes, where the sequencer disagrees with the statehash but it agrees on the previous statehash. Therefore, a single interaction will reduce 4096x fold computational steps in challenge.\nFurther optimization is to employ a multi-step on-chain verifier to determine the winner. This can be done by a zkVM verifier when the computational steps (trace) between previous (agreed) statehash and current (disagreed) statehash is smaller enough for a zkVM prover to generate a proof of the multi-step execution.\nExpected Results\nConsider a +40B steps verification, using 4096 statehashes per interaction will be done in ~3 times + an one-step VM verification. Suppose a zkVM can verify 4000+ steps on-chain, then the iterations will be reduced to ~2 times + a multi-step zkVM verification. If the zkVM can verify ~10M steps, then only one challenge-response interaction + a multi-step zkVM verification is good enough.\n\n ZK Fraud Proof with ZK State Channel\n\n SI-RVP: off-chain bisection + a single-instruction Groth16 proof for optimistic-rollup dispute resolution\n\n Powered by Discourse","tokens":836,"squid":"ink-research","role":"Deep Scholar","at":1791265455588,"hash":"02d57ec5e148315b7ee4fbf58e49326dd96cd762"}
{"url":"https://governance.aave.com/t/btc-b-on-aave-ethereum/25652/1","domain":"governance.aave.com","title":"BTC.b on Aave Ethereum - Risk / Assessments - Aave","text":"BTC.b on Aave Ethereum \n\n RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 16\n\n 1 / 2\n\n Sep 16\n\n Sep 16\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of BTC.b on Aave Ethereum.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 6\n min\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding BTC.b to the Aave V4 Core Hub on Ethereum, conditional on the segregation of BTC custody between Lombard’s BTC.b and LBTC products, which are currently backed by a pooled custody structure. Lombard has confirmed that per-asset custody segregation is planned and is expected to be implemented within the next couple of weeks. While Lombard’s aggregate reserves are sufficient to fully collateralize both products, dedicated custody for BTC.b would ensure that its backing remains independent of LBTC-related exposures.\nBeyond the above consideration, BTC.b benefits from robust administrative safeguards. Contract upgrades are subject to a 1-day timelock enforced by LombardTimeLock, with the executor controlled by Lombard’s 3/5 Safe multisig. The Bascule check is also enabled on the Ethereum BTC.b contract, providing an additional layer of verification for mints. The protocol also maintains an active bug bounty program, and recent audits have not identified any critical or high-severity findings. BTC.b currently has approximately $7.9M in DEX liquidity on Ethereum, nearly 100% of which is supplied by the Lombard team. While highly concentrated, this liquidity is relatively stable given its protocol-aligned nature and lower reliance on third-party LPs.\n1. Asset Fundamental Characteristics\n1.1 Asset\nAccording to the Aave Asset Class Allowlist (AAcA), Cross-chain Bitcoin (BTC.b) is classified as a bridged BTC wrapper, and assets of this category have already been listed on Aave. BTC.b is an ERC20 token on Ethereum, Avalanche, Katana, MegaETH, Monad, and Stable, backed 1:1 by BTC. BTC.b is issued against native BTC deposited on the Bitcoin network and secured through Lombard’s custody infrastructure, with issuance and accounting maintained on the Lombard Ledger. Approximately 2,115 BTC.b ($167M) is currently in circulation, with the majority of the supply residing on Avalanche at 2,012 BTC.b ($159M), while Ethereum accounts for 72.18 BTC.b ($5.7M).\n1.2 Architecture\nBTC.b is minted primarily against native BTC deposits on the Bitcoin Network, with consortium-notarised proofs confirmed through the Bascule. On Ethereum, the AssetRouter and BridgeV2 hold the only MINTER_ROLE, while the AssetRouter also facilitates BTC.b/LBTC conversions through the Lombard Ledger. BTC.b can be redeemed for native BTC through supported Bitcoin output scripts, subject to a 0.0001 BTC fee, while cross-chain transfers burn BTC.b on the source chain and mint it on the destination chain. There are no on-chain cooldowns or queues, with settlement times determined operationally. On Ethereum, BTC.b-to-BTC redemptions generally settle within hours (1 hour median), while LBTC-to-BTC.b conversions can take days (9.5 days median).\nThe BTC.b architecture remains unchanged since our prior review in February 2026, except for a reduction in the Security Consortium from 15 to 14 members. The signer threshold remains 10-of-14, with the current consortium comprising Amber, Antpool, Chorus One, DCG, Cubist, f2pool, Figment, Galaxy, Kraken, Kiln, Nansen, OKX, P2P, and Wintermute. The Bascule check on the Ethereum BTC.b contract was enabled on September 1, 2026. Before this, Ethereum mints relied solely on Consortium proofs. On Avalanche, the corresponding Bascule check has been enabled since January 29, 2026.\nBTC Reserves\nLombard’s Bitcoin reserves total 10,919.51 BTC across the 29,192 addresses published in its on-chain Proof-of-Reserve (PoR) list. These reserves are sufficient to fully back the outstanding supply of BTC.b and LBTC, with the Chainlink protocol-level PoR feed reporting 10,919.27 BTC, a difference of 0.25 BTC.\n\nMeasure\nBTC\n\nSum of the 29,243 PoR addresses\n10,919.51\n\nChainlink protocol-level Proof-of-Reserve feed\n10,919.27\n\nDifference\n0.25 (0.002%)\n\nBTC.b float (Avalanche, Ethereum, MegaETH, Stable, Katana, Monad)\n2,115.44 BTC\n\nLBTC float (Ethereum, Base, Avalanche, BSC, Berachain, Corn, Etherelink, Katana, MegaETH, Monad, Stable, Sonic, Solana, Starknet, Sui, Swell, TAC)\n8,742.84 LBTC\n\nLBTC float in BTC terms, at 1.00488299 BTC per LBTC\n8,785.53 BTC\n\nLBTC, buffer allocation\n7,436.69 BTC\n\nLBTC, active allocation into covered-call mandate (held in tri-party custody)\n1,348.84 BTC\n\nIdentified issuance\n10,900.97\n\nReserve in excess of identified issuance\n18.54 (0.17%)\n\nThe aggregate reserve position is therefore adequate, but the key consideration for BTC.b is whether its backing remains economically segregated from LBTC reserves. This became particularly relevant during July and August 2026, when Lombard transitioned LBTC from Babylon staking to a covered-call mandate managed by Bitwise, as seen below.\nimage2052×1211 167 KB\nSource: LlamaRisk, September 14, 2026\nHistorically, BTC.b and LBTC backing were held in separate addresses, with BTC.b reserves primarily held in bc1qt688…zuke. This address currently holds 8,020.37 BTC, or 73.45% of Lombard’s total reserves, equivalent to approximately 3.85x the entire BTC.b float. It received the consolidated BTC.b reserves during the January 2026 migration to Lombard infrastructure, and its balance subsequently declined in line with BTC.b redemptions. On August 6-7, 2026, it received a further 8,190.60 BTC from Lombard’s operational wallet, materially increasing the concentration of reserves in this address. The current reserve structure is as follows:\n\nAddress\nGrouping\nBTC held\nShare of reserve\nFirst active\n\nbc1qt688…zuke\nPooled custody\n8,020.37\n73.45%\n27 January 2026\n\nbc1q5c2h…uvy5\nNew custody (LBTC active sleeve)\n1,297.78\n11.88%\n6 August 2026\n\nbc1qmcdp…j3gp\nOperational wallet\n1,229.76\n11.26%\n21 August 2024\n\nbc1pxvj7…xss7\nOther custody\n55.00\n0.50%\n9 September 2026\n\nbc1ptere…5juy\nOther custody\n5.00\n0.05%\n19 August 2026\n\nbc1qm8va…cs63\nOther custody\n3.19\n0.03%\n30 July 2025\n\nbc1q5mks…gzk8\nOther custody\n2.64\n0.02%\n6 August 2025\n\nThe concern remains around how the ~2,115 BTC backing BTC.b is allocated across the custody groupings. Lombard currently uses many per-user deposit addresses for each asset alongside four protocol coordination wallets, with BTC.b and LBTC reserves co-mingled across these addresses. While aggregate reserves are sufficient, the PoR does not establish that BTC.b’s backing is segregated from LBTC. If reserves are pooled, a shortfall in LBTC operations could reduce the backing available to BTC.b holders, creating interdependence between the two assets.\nWe therefore recommend per-asset segregation of the protocol coordination wallets and a clear mapping of BTC.b reserves to dedicated custody addresses that maintain coverage at or above BTC.b supply. This would provide stronger assurance that BTC.b holders have a dedicated reserve pool and preserve BTC.b and LBTC as independent collateral exposures for Aave.\nBridge Risk\nLombard uses Chainlink CCIP to enable cross-chain bridging via a Burn-and-Mint mechanism. The attester set on CCIP comprises a Decentralized Oracle Network (DON) of 16 node operators (the same operator set used by Chainlink’s price feeds), which includes two off-chain plugins: the Commit DON and the Execute DON. The on-chain commit threshold requires 6-of-16 signatures, while the off-chain libOCR consensus protocol requires 11-of-16 operators to agree before a commit report can leave the DON.\nThe BTC.b bridge has 6 listed networks: Ethereum, Avalanche, Katana, MegaETH, Monad, and Stable. The CCIP bridge implements a 50 BTC.b 24h token bucket capacity for every active pathway, as shown below.\nimage1391×1244 67.3 KB\nSource: LlamaRisk, September 14, 2026\n1.3 Tokenomics\nThe total supply of BTC.b is variable and expands or contracts based on user-driven bridging of native BTC. On Ethereum, the circulating supply currently stands at 72.18 BTC.b, held across just 283 unique addresses.\nIn contrast, the majority of BTC.b supply resides on Avalanche, with approximately 2,011.89 BTC.b outstanding. Smaller allocations exist on other networks, including Monad, MegaETH, Stable, and Katana, bringing the aggregate cross-chain supply to ~2,115 BTC.b.\n1.3.1 Token Holder Concentration\nimage1183×343 27.1 KB\nSource: BTC.b Top 100 Token Holders, Etherscan, September 14, 2026\nThe top holders of BTC.b are:\n\nUniswap V4 BTC.b/cbBTC: 71.63% of the total supply.\nAave V3 aEthBTCb: 20.51% of the total supply.\nEOA A: 3.40% of the total supply.\nEOA B: 2.52% of the total supply.\n\nThe top three holders collectively control 98.05% of BTC.b’s total supply on Ethereum, with 92.14% held on Uniswap V4 and Aave V3 Core.\n2. Market Risk\n2.1 Liquidity\nimage968×645 52.7 KB\nSource: DeFiLlama, September 14, 2026\nUsers can swap 51.5 BTC.b for ~$3.77M USDC within a price impact of 7.5%.\n2.1.1 Liquidity Venue Concentration\nimage2059×1229 137 KB\nSource: LlamaRisk, September 14, 2026\nOn-chain liquidity for BTC.b on Ethereum is concentrated in a Uniswap V4 BTC.b/cbBTC pool ($7.89M TVL). As this is a dual-BTC wrapper pool, BTC.b-to-stablecoin swaps ultimately depend on the depth and liquidity of cbBTC’s secondary markets.\n2.1.2 DEX LP Concentration\nBTC.b liquidity on Ethereum is highly concentrated, with the Lombard team accounting for nearly all DEX liquidity. Lombard BTC Vault is the primary supplier to the Uniswap V4 BTC.b/cbBTC pool, contributing nearly 100% of the pool’s liquidity. While this represents near-exclusive reliance on a single liquidity provider, the provider is protocol-aligned, reducing the likelihood of rapid liquidity outflows and supporting the stability of the pool’s available liquidity.\n2.2 Volatility\nimage1754×943 35.5 KB\nSource: GeckoTerminal, September 14, 2026\nBTC.b has consistently maintained its 1:1 peg to BTC across secondary markets over the past month. Since the pool was seeded with 100 BTC of cbBTC liquidity on August 12, 2026, it has subsequently attracted trading activity, supporting healthy price discovery and overall trading dynamics.\n2.3 Exchanges\nBTC.b is exclusively traded on DEXs and is not currently listed on any centralized exchange.\n2.4 Growth\nimage2052×1229 132 KB\nSource: LlamaRisk, September 14, 2026\nSince its deployment on Ethereum, BTC.b has experienced steady growth, reaching a peak circulating supply of approximately 150 in August 2026. As of September 14, the circulating supply on Ethereum stands at 72.18 BTC.b ($5.45M).\n3. Technological Risk\nThe BTC.b technological risk on Ethereum, including smart contract risk, bug bounty program, and dependency risk, remains unchanged since our prior review and is excluded here for brevity, as no new contracts have been deployed.\n4. Counterparty Risk\n4.1 Governance and Regulatory Risk\nThe regulatory risk has been previously discussed in detail as part of the BTC.b Aave V3 Core onboarding review. As there have been no material changes, that assessment remains applicable here.\n4.2 Access Control Risk\n4.2.1 Contract Modification Options\nHere are the wallets controlling BTC.b on Ethereum:\n\nLombardTimeLock: Admin and owner of the BTC.b, AssetRouter, BridgeV2, and LombardConsortium contracts.\nMultisig1: Lombard-controlled 3/5 Safe, holds executor/proposer/canceller roles of the LombardTimeLock contract and can pause the BTC.b contract.\n\nThe following contracts power the BTC.b architecture on Ethereum:\n\nBTC.b: Upgradeable ERC20 contract for the BTC.b token controlled by LombardTimeLock.\nAssetRouter: Upgradeable contract, handles deposit/redemption orchestration and fee accounting, owned by LombardTimeLock.\nBridgeV2: Upgradeable contract, handles bridge execution for burn-and-mint transfers, owned by LombardTimeLock.\nLombardConsortium: Upgradeable contract, epoch-weighted multi-signature verifier, owned by LombardTimeLock.\n\nA role-based access control mechanism is employed for BTC.b to manage sensitive functions:\n\nControlling Addresses\nRole\nFunctionality\n\nLombardTimeLock\nDEFAULT_ADMIN_ROLE\nCan grant/revoke any role\n\nBridgeV2, AssetRouter\nMINTER_ROLE\nCan mint BTC.b\n\nMultisig1, Multisig2\nPAUSER_ROLE\nCan pause the contract\n\nEOA 1\nOPERATOR_ROLE\nManages configuration parameters and executes operational tasks\n\nEOA 1\nCLAIMER_ROLE\nWatches BTC deposits, consortium proofs, and submits mint+fee transactions on the user’s behalf\n\n4.2.2 Timelock Duration and Function\nA 1-day (86400 seconds) delay has been implemented for BTC.b contract upgrades via the LombardTimeLock.\n4.2.3 Multisig Threshold / Signer identity\nLombard controlled Multisig1 (3/5 Safe) holds is the executor of the LombardTimeLock contract, which has the following role-based access control:\n\nControlling Addresses\nRole\nFunctionality\n\nLombardTimeLock\nROLE_ADMIN\nCan update roles, including the role admin role itself\n\nMultisig1\nEXECUTOR_ROLE\nCan execute all proposals, including role updates\n\nEOA 2, Multisig1\nPROPOSER_ROLE\nCan schedule proposals, but can not schedule role updates\n\nMultisig1\nCANCELLER_ROLE\nCan unschedule proposals, but can not unschedule role updates\n\nThe 3/5 Safe Multisig1 has the following signers:\n\n0xd7B78BF124eB327F23f75F5C49De0c3fa5d2265A\n0x116744098070508c080B120A555B5453422b66eF\n0x70B9b04b19D9015EfBe1db37BBe30Dd304737950\n0xd775959eb15f6DfF24A267f988F6c2E2f769DeDa\n0xDD48B7cfd0c2256E008B7C690Fbe47ca77CD6071\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct to AIP] Onboard BTC.b to Aave V3 Core Instance\n\n New Asset\n\n 5\n\n 704\n\n Mar 19\n\n [Direct to AIP] Onboard BTC.b to Aave V4 Core Instance on Ethereum\n\n Governance\n\n 1\n\n 158\n\n Sep 16\n\n Circle Wrapped Bitcoin (cirBTC) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 105\n\n Sep 18\n\n [TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4\n\n General\n\n 14\n\n 2.1k\n\n Jul 8\n\n [ARFC] Onboard cirBTC on Aave v3 Core and Aave V4 Core\n\n New Asset\n\n 4\n\n 474\n\n Sep 1","tokens":3755,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265462751,"hash":"9f584ee41dfe20fd480513e4b91a1984c831c53a"}
{"url":"https://forum.soliditylang.org/t/are-there-any-efforts-to-improve-or-standardize-translations-of-solidity-documentation/3693/1","domain":"forum.soliditylang.org","title":"Are there any efforts to improve or standardize translations of Solidity documentation? - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Are there any efforts to improve or standardize translations of Solidity documentation? \n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 9\n\n 1 / 3\n\n Apr 10\n\n Jun 2\n\n post by alishawinson on Apr 9\n\n alishawinson\n\n Hi everyone,\nI’ve been going through the official Solidity documentation and found it really well-structured, but I was wondering about its accessibility for non-English speakers. Are there any ongoing community efforts or official initiatives to translate the documentation into other languages? If so, how are those translations download from here and kept in sync with frequent updates?\nAlso, for those who’ve used translated versions, do you find them reliable enough for learning and development, or do you still rely mostly on the original English docs?\n\n post by czepluch on Apr 13\n\n czepluch\n\n Solidity Team\n\n Hi and welcome!\nThank you for sharing your feedback.\nWe have a bunch of translation efforts going on here: Solidity Documentation Translations · GitHub. In this org you can find a variety of different translations. Some are more maintained than others. If your language is currently not up-to-date I recommend opening and issue in the repo with the language you want, requesting that it will get up-to-date. Or even better, open a Pull Request getting the translation up-to-date.\nYou can also check out the Matrix channel: https://matrix.to/#/#solidity-docs-translations:matrix.org\nEither way, if you let me know the language you’re looking for, I can try to get in touch with the maintainers.\n\n 2 months later\n\n post by hwhsu1231 on Jun 2\n\n hwhsu1231\n\n Hello @alishawinson,\n\nI am the author of the Localize The Docs organization. It’s my pleasure to invite you to join the translation of the solidity-docs-l10n project:\n\n Preview: solidity-docs-l10n\n Crowdin: solidity-docs-l10n\n GitHub: solidity-docs-l10n\n\nThe goal of this project is to translate The Solidity Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.\nIf the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!\nSee the announcement post for more details.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Size limit of Array/Mapping on BNB Smart Chain (Scalability Question)\n\n Code Wizards\n\n 1\n\n 122\n\n Apr 18\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1579,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265467119,"hash":"42cc5e6efaa6473a655a4d5711ac190f0c656e7f"}
{"url":"https://forum.soliditylang.org/c/documentation/8","domain":"forum.soliditylang.org","title":"Latest Documentation topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Documentation\n\n Documentation\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n New communication channel about Solidity Docs Community Translations\n\n Hello everyone \nIn case you do not know - we just opened a new matrix channel for translators: https://app.element.io/#/room/#solidity-docs-translations:matrix.org \nCurrently, we are discussing Translation Bot for automa…\n\n read more\n\n 3\n\n 1.1k\n\n Mar 2025\n\n About the Documentation category\n\n Discussion about the documentation and its translations. \n Please do not use the forum to report issues (e.g. typos or broken links in the documentation). Please report issues directly via the Solidity Issue Tra…\n\n read more\n\n 0\n\n 581\n\n Feb 2021\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n 2\n\n 149\n\n Jun 2\n\n Localization of The Solidity Documentation\n\n 0\n\n 83\n\n Jun 2\n\n License and Attribution of the Solidity Logo?\n\n 5\n\n 245\n\n Oct 2025\n\n Lack of centralized documentation of known vulnerabilities\n\n 4\n\n 304\n\n Oct 2025\n\n The key `is` annot be located in the keyword index of solidity documentation\n\n 1\n\n 123\n\n Jul 2025\n\n Translations: Portuguese Coordination Thread\n\n 12\n\n 1.1k\n\n Sep 2024\n\n Precompiles should be in Docs\n\n 1\n\n 190\n\n Aug 2024\n\n Docs: storage layout for array of arrays\n\n 3\n\n 486\n\n Feb 2024\n\n Question about IR semantic changes\n\n 1\n\n 525\n\n Dec 2023\n\n Implicit hexadecimal literal to string conversion\n\n 2\n\n 893\n\n Sep 2023\n\n [Documentation] Conversion from payable to contract type\n\n 7\n\n 856\n\n Aug 2023\n\n How to know about minimum and maximum values of Types in the documentation\n\n 5\n\n 635\n\n Aug 2023\n\n Translation: Hebrew\n\n 4\n\n 454\n\n Aug 2023\n\n Understanding the “memory-safe” dialect\n\n 5\n\n 4.8k\n\n Jul 2023\n\n Type representation of literals\n\n 1\n\n 463\n\n Jun 2023\n\n I want to help translate to Russian/Ukrainian\n\n 4\n\n 646\n\n Apr 2023\n\n Wording about function types in documentation\n\n 2\n\n 486\n\n Mar 2023\n\n Storage object JSON interface\n\n 7\n\n 3.0k\n\n Jan 2023\n\n Documentation question about solidity state variable storage layout\n\n 3\n\n 790\n\n Oct 2022\n\n The mapping value storage location\n\n 0\n\n 674\n\n Aug 2022\n\n How do these mathematical symbols work? == and ++ vs = and +\n\n 1\n\n 656\n\n Aug 2022\n\n Introducing the Translations PR Bot! \n\n 4\n\n 761\n\n Jul 2022\n\n Translations: Turkish Coordination🇹🇷\n\n 8\n\n 696\n\n Jun 2022\n\n Uni Directional Payment\n\n 1\n\n 575\n\n Jun 2022\n\n Translations: Spanish Coordination \n\n 11\n\n 1.0k\n\n May 2022\n\n Translations: Polish Coordination \n\n 0\n\n 583\n\n May 2022\n\n Translations: How can I contribute? (ko)\n\n 5\n\n 824\n\n Apr 2022\n\n Should the Solidity docs give some guidance on naming conventions?\n\n 2\n\n 759\n\n Mar 2022","tokens":1519,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265482522,"hash":"fdf263d2511a4dee6903280bea301e192aa2ad38"}
{"url":"https://governance.aave.com/t/arfc-revision-of-eth-btc-collateral-efficiency-on-aave/25649/1","domain":"governance.aave.com","title":"[ARFC] Revision of ETH & BTC Collateral Efficiency on Aave - Governance / General - Aave","text":"[ARFC] Revision of ETH & BTC Collateral Efficiency on Aave \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 16\n\n 1 / 3\n\n Sep 16\n\n Sep 21\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nThis ARFC proposes raising the LTV and liquidation threshold of the ETH and BTC collateral families on Aave V3 Ethereum Core, Arbitrum, and Base, and the collateral factors of the same assets on the Aave V4 Ethereum Main Spoke. The proposed settings follow from a calibration against historical price behavior and Chainlink price feed updates, which are dense during fast markets and span both the February 2025 and October 2025 stress events. Each threshold is sized to the 99.9th percentile of the worst excursion inside a 1 hour window, the period over which positions are cleared through sequential liquidation calls, at the reserve’s liquidation bonus.\nThe proposed changes are the following:\n\nWETH moves to 81% LTV and 84% LT on Ethereum Core, Base, and Arbitrum.\nwstETH moves to 79% LTV and 82% LT and weETH to 78% LTV and 81% LT on Ethereum Core.\nWBTC moves to 81% LTV and 85% LT on Ethereum Core and to 78% LTV and 82% LT on Arbitrum.\ncbBTC moves to 81% LTV and 85% LT on Ethereum Core and to 81% LTV and 84% LT on Base, with the Base liquidation bonus lowered to 6.00% and the Base cbBTC Stablecoins E-Mode raised to 82% LTV and 85% LT.\nOn the Aave V4 Main Spoke, the collateral factor moves to 84% for WETH, 82% for wstETH, 81% for weETH, and 85% for WBTC and cbBTC, applied as a dynamic configuration update.\n\nThe analysis supports these settings on the following grounds:\n\nETH remains materially more volatile than BTC, with two-year annualized volatility of 68.8% against 44.4% and deeper excursion tails at every window. The 1 hour p99.9 excursion is -11.85% for ETH and -5.09% for BTC on its binding leg.\nThe recommended ETH family thresholds sit inside the buffer implied by the basis at each reserve’s live bonus. WETH is set at its ceiling, and wstETH and weETH one point inside theirs.\nThe BTC settings of 82 to 85% sit deliberately deep inside the buffer implied by the basis, as margin against depth, cap, and concentration risks the price model does not capture.\nThe basis covers every realized 1 hour excursion of the two-year record up to its 99.9th percentile and relies on the measured liquidation cadence, which kept position marks seconds to minutes fresh through both stress events. The residual scenario outside the basis is a stalled oracle and liquidation pipeline coinciding with a move beyond that percentile, with the realized worst at -24.27% for ETH and -11.15% for BTC over one hour.\nLiquidation processing is measured in seconds on every market examined, the slow tail is attributed to dust debt, and the two stress events produced $0 and $0.39M of bad debt respectively, with no bad debt for the analyzed collateral.\nThe same framework applied to the Aave V4 Main Spoke, the V4 counterpart of the Ethereum Core market, supports the same moves as V3, as the same Chainlink SVR auction setup is applied for both markets, integrating a set of robust searchers.\n\nMotivation\nAave’s bluechip collateral parameters have remained relatively stable over time, even as market conditions and volatility risk profiles have changed. This creates a trade-off in which overly conservative parameters reduce how much users can borrow against their collateral. The purpose of this assessment is to determine whether current LTV and LT parameters are consistent with the observed volatility and liquidity of each collateral asset, and this ARFC proposes the parameter changes that follow from it.\nMethodology\nLiquidation window\nThe window is the period over which the tail move is measured and it is the single largest input to the resulting parameter. We measure it from liquidation behaviour in two parts. The first is the time each liquidation call spent at or below the price at which it executed, weighted by the value being processed, computed with a single code path across markets, each market joined against the feed its Aave deployment reads and against stablecoin debt, over August 2025 to August 2026.\n\nMarket\nCollateral\nLiquidations\nSeized\nWeighted median\nWeighted p95\nWeighted p99\nValue below price over 1 h\n\nEthereum Core\nETH\n7,206\n$618M\nunder 1 s\n2.0 min\n5 min\n0.00%\n\nEthereum Core\nBTC\n2,621\n$358M\nunder 1 s\n2.2 min\n5 min\n0.07%\n\nArbitrum\nETH\n5,699\n$41M\nunder 1 s\n18 s\n2 min\n0.00%\n\nArbitrum\nBTC\n1,819\n$18M\nunder 1 s\n48 s\n2 min\n0.00%\n\nBase\nETH\n7,448\n$20M\nunder 1 s\n48 s\n2 min\n0.02%\n\nBase\nBTC\n1,444\n$22M\nunder 1 s\n1.1 min\n2 min\n0.00%\n\nliquidation_window2520×990 137 KB\nSource: LlamaRisk, August 29, 2026\nWeighted by value, every market clears its economically meaningful liquidations within minutes of the price crossing, and the share of processed value that had been below its liquidation price for more than an hour is at most 0.07%. The event-count tail reaches hours only through dust positions whose bonus barely covers gas, the same tail quantified in the processing section below. The exposure that the threshold must cover is therefore the work-off of a position rather than a clearing span. A liquidation call repays at most half the outstanding debt, so a large position clears through roughly five sequential calls, each landing on a feed publication. Across both stress events on Ethereum Core the value-weighted gap between consecutive calls on the same position had a median under one minute and a p95 of 15 to 21 minutes. One hour covers the work-off of the bulk of value with margin on every market examined, and Arbitrum and Base sit inside the Core distribution on every quantile. We therefore adopt a 1 hour work-off window as the basis for both families.\nLiquidation processing\nThe window above measures how long a position stays exposed. Processing speed measures how quickly liquidators act once a feed publication makes a position liquidatable. We measured the lag between each liquidation and the most recent publication of either leg of its pair on Aave V3 Ethereum Core, Arbitrum, and Base across the two largest stress events of the observation period. Ethereum is joined against the SVR publications Aave reads where they were live, which is October 2025, and against the pre-SVR standard aggregators in February 2025.\n\nEvent\nMarket\nLiquidations\nSeized\nMedian lag\np75\np95\nVolume within 1 min\nVolume within 5 min\n\nFebruary 2 to 4, 2025\nEthereum Core\n936\n$172M\n24 s\n51 s\n10.3 min\n95%\n100%\n\nFebruary 2 to 4, 2025\nArbitrum\n1,511\n$15M\n6 s\n17 s\n57 s\n100%\n100%\n\nFebruary 2 to 4, 2025\nBase\n1,435\n$9M\n10 s\n28 s\n2.0 min\n99%\n100%\n\nOctober 10 to 12, 2025\nEthereum Core\n430\n$100M\n36 s\n72 s\n6.0 min\n63%\n100%\n\nOctober 10 to 12, 2025\nArbitrum\n346\n$17M\n1 s\n10 s\n23 s\n100%\n100%\n\nOctober 10 to 12, 2025\nBase\n392\n$6M\n2 s\n4 s\n2.8 min\n100%\n100%\n\nprocessing_lag2520×990 141 KB\nSource: LlamaRisk, August 29, 2026\nLiquidations execute at feed speed even at peak congestion. Nearly all seized volume clears within five minutes of the publication that made it profitable, so liquidator responsiveness is not the binding constraint on the parameters. Arbitrum and Base, whose feeds print on tighter deviations and whose execution gas is negligible, clear faster than Ethereum Core with no lag tail at all, so the Core benchmark is the conservative one for the markets receiving the proposed increases.\nThe latency tail consists almost entirely of dust positions. Broken down by lag behind the triggering publication on Ethereum Core across both stress windows, liquidations slower than five minutes were 11.1% of events but 0.23% of seized volume. The residual sub-hour maxima are dust positions whose bonus barely covers mainnet gas, together with positions pushed over the threshold by interest accrual between publications rather than by a fresh print.\n\nLag behind print\nEvents\nShare of events\nShare of seized USD\nMedian size\n\nunder 1 min\n967\n70.8%\n78.6%\n$21,833\n\n1 to 5 min\n248\n18.2%\n21.2%\n$16,958\n\n5 to 15 min\n112\n8.2%\n0.2%\n$993\n\nover 15 min\n39\n2.9%\n0.0%\n$341\n\nLiquidators clear economically meaningful positions at feed speed and defer only positions where the bonus barely covers gas. The processing tail therefore carries no bad debt relevance.\nFast processing does not mean a position is cleared at its first touch of the threshold. A liquidation call repays at most half of the outstanding debt, resets the health factor slightly above one, and leaves the remainder exposed to the next leg down. In the February event, 32% of liquidated users across all deployments were liquidated more than once, and these users accounted for 64% of all seized volume, with a median of 3.5 hours between a user’s first and last liquidation and a p90 of roughly 10 hours.\nfeb_2025_eth_cascade2520×1080 200 KB\noct_2025_btc_cascade2520×1080 162 KB\nSource: LlamaRisk, August 29, 2026\nBoth events cleared with negligible bad debt. February produced no recognized deficit at all, and October produced $0.39M against roughly $128M, without affecting the ETH- and BTC-family collateral across all deployments. The liquidation machinery has held through both stress events at current parameters.\nLiquidation bonus\nThe liquidation bonus is an input to the derivation. The threshold has to cover the tail move and the bonus paid to the liquidator, so a higher bonus mechanically supports a lower threshold at the same level of risk. Each reserve is therefore assessed at its own live bonus rather than a single assumed value. The same asset carries different bonuses on different deployments, with WBTC at 5.00% on Ethereum and 8.50% on Polygon, and that difference moves the supportable threshold by several points due to the impact to the bad debt buffer of the protocol.\nParameter derivation\nThe model ceiling for the liquidation threshold is the largest value at which the collateral remaining after the basis move still covers the debt plus the bonus:\nLT ceiling = round((1 - |p99.9 excursion|) / (1 + LB))\n\nEach reserve is assessed at its recommended bonus where one is proposed and at its live bonus otherwise. Recommended thresholds are set relative to the ceiling: WETH at the ceiling, the rest of the ETH family one point inside it, and BTC at least three points inside it as margin against depth, cap, and concentration risks the price model does not capture.\nIn the open market every borrowable reserve is reachable from every collateral, so each collateral is assessed against every debt leg its deployment exposes and takes the lowest result.\nCalibration Results\nRealized tails and supported thresholds\nAll windows measured on the two-year deviation-threshold series, including February 2025. The 1 hour row is the basis for both families.\n\nWindow\nETH p99\nETH p99.9\nETH worst\nBTC p99\nBTC p99.9\nBTC worst\n\nsingle print\n-0.88%\n-1.66%\n-4.75%\n-0.71%\n-1.14%\n-3.44%\n\n5 min\n-1.16%\n-3.09%\n-13.31%\n-0.63%\n-2.04%\n-5.61%\n\n15 min\n-2.00%\n-6.28%\n-18.02%\n-1.19%\n-3.14%\n-8.45%\n\n30 min\n-2.88%\n-11.75%\n-22.02%\n-1.72%\n-4.06%\n-10.08%\n\n1 h (basis)\n-3.94%\n-11.85%\n-24.27%\n-2.39%\n-5.03%\n-10.72%\n\n2 h\n-5.19%\n-14.61%\n-26.24%\n-3.33%\n-6.28%\n-10.72%\n\n4 h\n-7.10%\n-24.13%\n-28.43%\n-4.69%\n-7.44%\n-11.32%\n\n6 h\n-8.63%\n-24.45%\n-29.25%\n-5.61%\n-9.55%\n-12.77%\n\n12 h\n-12.46%\n-27.25%\n-33.64%\n-6.88%\n-13.78%\n-16.38%\n\n1 d\n-16.73%\n-29.74%\n-35.06%\n-9.89%\n-17.05%\n-19.75%\n\nexcursion_tails2520×990 183 KB\nSource: LlamaRisk, August 29, 2026\nThe chart below plots the model ceiling at each work-off window across the live bonus range, with the 1 hour basis marked.\nsupported_threshold_vs_window2520×990 212 KB\nSource: LlamaRisk, August 29, 2026\nThe basis covers any 1 hour excursion up to the 99.9th percentile of the two-year record, which spans the whole of the October 2025 event and all but the core legs of February 3, 2025, and it relies on the measured liquidation cadence keeping position marks seconds to minutes fresh. The residual scenario outside the basis is a maximally levered position marked at its threshold at the start of a move beyond that percentile, with no liquidation landing for the full hour. Reaching it requires the oracle cadence and the liquidation pipeline to stall together through the worst 0.1% hour of two years, which did not happen in either stress event, where calls landed at a median of 24 seconds behind their triggering publication throughout.\nwstETH and weETH\nThe two established LSTs warrant a similar empirical treatment as the canonical wrappers. Across the two years to August 2026 they account for 6,486 liquidations and roughly $361M of seized collateral across all deployments, $296M of it wstETH and $47M weETH, overwhelmingly against stablecoin debt. Processing speed during both stress events was indistinguishable from WETH. On Ethereum Core the median lag behind the triggering publication was 12 s for LST collateral against 24 s for WETH in February 2025, and 72 s against 24 s in October 2025 on the sparser SVR publications, with lower p95 values than WETH in both events. The liquidation pipeline treats them as blue-chip collateral in practice.\nInstant exit liquidity, quoted through aggregate routing against the on-chain redemption rate, supports the same conclusion within the sizes the protocol has actually needed.\nlst_exit_liquidity2520×990 123 KB\nSource: LlamaRisk, August 29, 2026\nwstETH exits at under 0.05% discount up to roughly $24M and 0.55% at $47M, with the route exhausting beyond about $55M. weETH exits at under 0.25% up to roughly $21M and exhausts beyond about $25M. For comparison, the entire February 2025 cascade seized $39M of LST collateral on Ethereum Core spread over several hours, well inside these depths.\nOn this evidence both assets are assessed on the measured ETH basis, and their processing and depth place them in the same tier as WETH. Against live settings of 81% and 80%, we recommend raising wstETH to 82% and weETH to 81% on Ethereum, each one point inside the ceiling at its live bonus, and WETH to 84%, at its ceiling. The conservatism in weETH’s configuration sits in its 7.00% bonus against wstETH’s 6.00% despite comparable processing speed and depth proportionate to its supply.\nSpecification\nArbitrum\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nBorrowable assets\n\nWETH\n80.0%\n84.0%\n5.00%\n81%\n-\nWBTC, WETH, GHO, USDC, USD₮0\n\nWBTC\n73.0%\n78.0%\n7.00%\n78%\n82%\nWBTC, WETH, GHO, USDC, USD₮0\n\nBase\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nRecommended LB\nBorrowable assets\n\nWETH\n80.0%\n83.0%\n5.00%\n81%\n84%\n-\nWETH, cbBTC, EURC, GHO, USDC\n\ncbBTC\n73.0%\n78.0%\n7.50%\n81%\n84%\n6.00%\nWETH, cbBTC, EURC, GHO, USDC\n\nDue to robust cbBTC liquidity on Base (~$33M in stables) we also recommend lowering liquidation bonus to 6.00%.\nE-Mode\n\nAsset\nE-Mode\nCategory ID\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nBorrowable assets\n\ncbBTC\ncbBTC Stablecoins\n10\n80.0%\n83.0%\n4.00%\n82%\n85%\nGHO, USDC\n\nEthereum Core\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\n\nWETH\n80.5%\n83.0%\n5.00%\n81%\n84%\n\nWBTC\n73.0%\n78.0%\n5.00%\n81%\n85%\n\ncbBTC\n73.0%\n78.0%\n7.50%\n81%\n85%\n\nwstETH\n78.5%\n81.0%\n6.00%\n79%\n82%\n\nweETH\n77.5%\n80.0%\n7.00%\n78%\n81%\n\nLiquidation bonuses on Ethereum Core stay at their current values, including the 7.50% bonus on cbBTC, even though the depth that supports a 6.00% bonus on Base is also present on Ethereum. An increase to the liquidation protocol fee for these assets on Ethereum Core is pending. The protocol fee is taken out of the liquidation bonus, so lowering the bonus at the same time would reduce the liquidator’s net share from both sides.\nAave V4 Ethereum Main Spoke\nThe Main Spoke is the V4 counterpart of the V3 Ethereum Core market and is assessed identically, on the same basis and with each reserve at its recommended maximum liquidation bonus where one is proposed and at its live maximum otherwise, with WETH, WBTC, and cbBTC as volatile debt alongside deep stablecoins.\n\nAsset\nCurrent CF\nMax LB\nRecommended CF\nRecommended Max LB\n\nWETH\n83.0%\n5.55%\n84%\n-\n\nwstETH\n80.0%\n6.66%\n82%\n-\n\nweETH\n80.0%\n7.77%\n81%\n-\n\nWBTC\n78.0%\n5.55%\n85%\n-\n\ncbBTC\n78.0%\n5.55%\n85%\n-\n\nFor the CF changes, we recommend performing a configuration update instead of deploying a new collateral configuration.\nNext Steps\n\nGather community and service provider feedback on this ARFC.\nIf consensus is reached, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is positive, submit the changes for implementation as an AIP.\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n 2\n\n read \n\n 7\n min\n\n post by Foreshock on Sep 20\n\n Foreshock\n\n The BTC settings here are described as sitting deep inside the buffer as margin against depth, cap and concentration risks that the price model does not capture. That argument has a counterpart on the ETH family, where WETH goes to its ceiling and wstETH and weETH sit one point inside theirs.\nFor the ETH family the risks the price model does not capture include who can change the underlying contracts. For Lido the admin is a controlling contract where no single key can act alone, but its signers and any delay are not published in one place we could find. Is that control surface part of how the wstETH buffer is sized, or is it treated as out of scope for this ARFC?\n\n post by LlamaRisk on Sep 21\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n The ARFC has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 264\n\n Aug 21\n\n Independent Liquidation-Capacity Stress Tests For Aave\n\n Risk\n\n 1\n\n 217\n\n Aug 25\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [TEMP CHECK] Post-rsETH Collateral Framework: Tier-Based LTV Reductions and Wrap-Depth Ineligibility Limits\n\n Risk\n\n 17\n\n 1.3k\n\n Jul 26\n\n Post Vyper Exploit - CRV Market Update and Recommendations\n\n General\n\n 48\n\n 8.1k\n\n Aug 29","tokens":4594,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265489778,"hash":"70e48fd4671554b6255d49780c46c4da5523e193"}
{"url":"https://forum.soliditylang.org/t/about-the-documentation-category/17","domain":"forum.soliditylang.org","title":"About the Documentation category - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n About the Documentation category \n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by franzihei on Dec 18, 2020\n\n franzihei\n\n Discussion about the documentation and its translations.\n Please do not use the forum to report issues (e.g. typos or broken links in the documentation). Please report issues directly via the Solidity Issue Tracker in Github.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n Documentation\n\n 2\n\n 149\n\n Jun 2\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Using CLZ to seed sqrt - finding the initial estimate, before and after Fusaka\n\n Code Wizards\n\n 1\n\n 120\n\n Jun 9\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1110,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265492805,"hash":"bc0ab02d27fb25822932850824ed5464fe0fccea"}
{"url":"https://ethresear.ch/u/kladkogex","domain":"ethresear.ch","title":"Summary - kladkogex - Ethereum Research","text":"Skip to profile content\n\n kladkogex\n\n Stan Kladko\n\n Menlo Park, CA\n\n Co-Founder/CTO SKALE Labs\nstan (dot) kladko (at) skalelabs (dot) com\nScience is magic that works.\nKurt Vonnegut\n\n website:\n\n skalelabs.com\n\n Joined\n\n Nov 16, 2017\n\n Last Post\n\n Jun 26\n\n Seen\n\n Jun 26\n\n Views13223\n Trust Levelmember\n\n Stats\n\n 764\n\n days visited\n\n 5d\n\n read time\n\n 1.2k\n\n topics viewed\n\n 7.1k\n\n posts read\n\n 175\n\n given\n\n 449\n\n received\n\n 110\n\n topics created\n\n 649\n\n posts created\n\n Top Replies\n\n Jan 2018\n ·\n  7\n\n Minimal Viable Plasma\n\n Jan 2018\n ·\n  7\n\n Minimal Viable Plasma\n\n Aug 2018\n ·\n  6\n\n Discussion: P2P message serialization standard\n\n Mar 2018\n ·\n  6\n\n Improving front running resistance of x*y=k market makers\n\n Jan 2018\n ·\n  6\n\n Minimal Viable Plasma\n\n Apr 2021\n ·\n  5\n\n MEV Auctions Will Kill Ethereum\n\n More Replies\n\n Top Topics\n\n Jan 2018\n ·\n  47\n\n Using ICOs to fund science\n\n Jun 2018\n ·\n  46\n\n Hashgraph Consensus Timing Vulnerability\n\n Aug 2018\n ·\n  37\n\n EVM performance\n\n Jan 2018\n ·\n  30\n\n Running Deep Learning on EVM\n\n May 2018\n ·\n  20\n\n How to protect Plasma against DoS attacks?\n\n Jul 2020\n ·\n  17\n\n Parallelilizing EVM through end-of-the-block virtual transactions\n\n More Topics\n\n Top Links\n\n drive.google.com/file/d/1ucUeKg_NiR8RxNAonb8Q55jZha03WC0O/view\n\n Telegram Sharding\n\n github.com/GalacticExchange/gex_blockchain_tools/blob/master/contracts/GexBot.so\n\n Improving front running resistance of x*y=k market makers\n\n ethereum-magicians.org/t/forming-a-ring-ai-on-ethereum/1456\n\n Running Deep Learning on EVM\n\n medium.com/offchainlabs/the-cheater-checking-problem-why-the-verifiers-dilemma-i\n\n Verifier’s Dilemma\n\n github.com/skalenetwork/skale-manager/blob/e02aaa37c37a7d3f2f3214e784307b389b726\n\n BLS Signatures in Solidity\n\n hackmd.io/@HWeNw8hNRimMm2m2GH56Cw/sharding_proposal\n\n Data Availability Sampling\n\n Most Replied To\n\n vbuterin\n\n Vbuterin\n\n 64\n\n JustinDrake\n\n Justin Drake\n\n 29\n\n ldct\n\n Xuanji Li\n\n 16\n\n MicahZoltu\n\n Micah Zoltu\n\n 9\n\n denett\n\n Denett\n\n 9\n\n danrobinson\n\n Dan Robinson\n\n 9\n\n Most Liked By\n\n Mirror\n\n Mirror\n\n 15\n\n jamesray1\n\n James Ray\n\n 14\n\n ltfschoen\n\n Luke Schoen\n\n 14\n\n sherif\n\n sherif samir\n\n 11\n\n MihailoBjelic\n\n Mihailo Bjelic\n\n 10\n\n lane\n\n Lane Rettig\n\n 9\n\n Most Liked\n\n vbuterin\n\n Vbuterin\n\n 27\n\n JustinDrake\n\n Justin Drake\n\n 15\n\n jamesray1\n\n James Ray\n\n 11\n\n ldct\n\n Xuanji Li\n\n 8\n\n yhirai\n\n Yoichi\n\n 6\n\n clesaege\n\n Clément Lesaege\n\n 5\n\n Top Categories\n\n Topics\n Replies\n\n Sharding\n\n 7\n\n 98\n\n Plasma\n\n 11\n\n 82\n\n Economics\n\n 13\n\n 59\n\n Uncategorized\n\n 18\n\n 41\n\n Proof-of-Stake\n\n 7\n\n 52\n\n Cryptography\n\n 4\n\n 39\n\n Top Badges\n\n Member\n\n Granted invitations, group messaging, more likes\n\n Gives Back\n\n Has 100 liked posts and gave 100 likes\n\n Respected\n\n Received 2 likes on 100 posts\n\n Anniversary\n\n Active member for a year, posted at least once\n\n 8 awarded\n\n Reader\n\n Read every reply in a topic with more than 100 replies\n\n Thank You\n\n Has 20 liked posts and gave 10 likes\n\n More Badges\n\n Powered by Discourse","tokens":739,"squid":"ink-research","role":"Deep Scholar","at":1791265495057,"hash":"d9a5333fa7dd2aae4d55a7b6984f66518a366ec2"}
{"url":"https://forum.soliditylang.org/t/localization-of-the-solidity-documentation/3708","domain":"forum.soliditylang.org","title":"Localization of The Solidity Documentation - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Localization of The Solidity Documentation \n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by hwhsu1231 on Jun 2\n\n hwhsu1231\n\n Hello Solidity Community,\nI am the author of the Localize The Docs organization. And I’m glad to announce that the solidity-docs-l10n project is published now:\n\n Preview: solidity-docs-l10n\n Crowdin: solidity-docs-l10n\n GitHub: solidity-docs-l10n\n\nThe goal of this project is to translate The Solidity Documentation into multiple languages. Translations are contributed via the Crowdin platform, automatically synchronized with the GitHub repository, and can be previewed on GitHub Pages.\nWe welcome anyone interested in documentation translation to join us. If the target language is not supported in the project yet, please submit an issue to request the new language. Once the requested language is added, you can start translating!\nSee the announcement post for more details.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n License and Attribution of the Solidity Logo?\n\n Documentation\n\n 5\n\n 245\n\n Oct 2025\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n Documentation\n\n 2\n\n 149\n\n Jun 2\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 180\n\n Dec 2025\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Core Solidity: Feedback from porting Uniswap v2\n\n Language Design\n\n 2\n\n 191\n\n Jun 9\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1239,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265504717,"hash":"0ae529ca5ee1899aaf4ba0f4d7f5993e074e5956"}
{"url":"https://forum.openzeppelin.com/t/where-are-crowdsales/6321/6","domain":"forum.openzeppelin.com","title":"Where are crowdsales? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Mar 2021\n\n 6 / 8\n\n Mar 2021\n\n Feb 2022\n\n post by asven-2020 on Mar 15, 2021\n\n post by Skyge on Mar 15, 2021\n\n Skyge\n\n Yeah, you are right, it only exists in the version 2.x, they are not in OpenZeppelin Contracts 3.x.\nSo to install it, you can run the following command:\nnpm install @openzeppelin/contracts@2.5.1\n\nAnd you can find more details in the documentation: https://docs.openzeppelin.com/contracts/2.x/crowdsales \n\n post by abcoathup on Mar 15, 2021\n\n abcoathup\n\n Great contributor\n\n I have added emoji to the Simple ERC20 Crowdsale to make it clearer that they are not in OpenZeppelin Contracts 3.x\n\n post by asven-2020 on Mar 16, 2021\n\n asven-2020\n\n Thank you. May be any new contract for presale have?\n\n post by abcoathup on Mar 16, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nThere aren’t specific presale contracts. You could have multiple crowdsale contracts for each phase.\n\n post by asven-2020 on Mar 18, 2021\n\n asven-2020\n\n Thank you Crowdsale not work with new ERC20 so problem do before pull\n\n post by abcoathup on Mar 18, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nYou can have a separate project for the token and a separate project for the crowdsale. This would allow you to have a token using the latest OpenZeppelin Contracts (depending on the token).\n\n 11 months later\n\n post by BigMadCode on Feb 6, 2022\n\n BigMadCode\n\n Is there a new Crowdsale contract or did OPZ just stop maintaining it altogether. I tried using the 2x contract and could never get the transfer function to work at all.\nIf you know of any newer contract please advise.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use Crowdsale Smart Contracts\n\n Contracts\n\n erc20\n\n 1\n\n 683\n\n May 2020\n\n How to create a Crowdsale with Solidity 0.6?\n\n Contracts\n\n 2\n\n 1.7k\n\n Sep 2020\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Analogue CrowdSales\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 617\n\n Apr 2022","tokens":554,"squid":"ink-security_audits","role":"Sentinel","at":1791265510658,"hash":"b5f5d2c5f52192af5dd5e4049545e816b06e62c8"}
{"url":"https://dev-forum.pyth.network/t/i-failed-to-use-api-reference-pyth-network/446/4","domain":"dev-forum.pyth.network","title":"I failed to use api-reference.pyth.network - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Oct 2025\n\n 4 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by unipine on Oct 16, 2025\n\n unipine\n\n Hi mates,\nI tried to use this api (https://api-reference.pyth.network/price-feeds/evm/getPriceNoOlderThan) on the docs directly but failed with following error.\nContractFunctionExecutionError: The contract function \"getPriceNoOlderThan\" reverted. Error: PriceFeedNotFound() Contract Call: address: 0x4305FB66699C3B2702D4d05CF36551390A4c69C6 function: getPriceNoOlderThan(bytes32 id, uint256 age) args: (0x7e990daa483e54a9a2b25ed3312285c867a049b5b3c84d27fe8c2ad9e0d24c57, 60) Docs: readContract · Viem Version: viem@2.34.0\nNot sure what the cause is. I tried several times with different networks and priceIds, but same result.\nHow can I make successful calls?\nThanks.\n\n 2\n\n 2\n\n post by Aditya520 on Oct 17, 2025\n\n Aditya520\n\n Hi @unipine , welcome to pyth dev-forum.\nThe PriceFeedNotFound() error emits when feed has never been updated or the feed Id you are entering is wrong. I would recommend you to update the price feed first.\n\n post by unipine on Oct 20, 2025\n\n unipine\n\n Hi @Aditya520, thanks for your reply.\nI noticed that I need to pay gas fee when updating price feed.\nShould I do this frequently?\nBest\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n Yes you need to pay the fees everytime you update the prices.\nSince Pyth oracle follows a pull design. You need to do this if you need latest real-time prices.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 642\n\n Jul 2025\n\n Price feed in Avalanche not working\n\n Price Feeds\n\n evm\n\n 1\n\n 302\n\n Oct 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Not able to fetch data from id\n\n Price Feeds\n\n 2\n\n 549\n\n Sep 2025\n\n Powered by Discourse","tokens":1369,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265517744,"hash":"334b580e0c4870e42f4f6f323ff1ea64c4b42a34"}
{"url":"https://forum.openzeppelin.com/t/how-to-create-a-crowdsale-with-solidity-0-6/3877","domain":"forum.openzeppelin.com","title":"How to create a Crowdsale with Solidity 0.6? - Support / Contracts - OpenZeppelin Forum","text":"How to create a Crowdsale with Solidity 0.6? \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2020\n\n 1 / 3\n\n Sep 2020\n\n Sep 2020\n\n post by arkhaminferno on Sep 19, 2020\n\n arkhaminferno\n\n Hello guys ,\nI want to make a crowdsale smart Contract.\nAs i could see crowdsale contract has been removed from openzepplin v3.0 .\n. How to implement it in v3.0 oz Contracts?\nI have made the erc20 contract using openzepplin.\n\n post by speedevs on Sep 19, 2020\n\n speedevs\n\n yes me too , i was shocked\n\n post by abcoathup on Sep 21, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @arkhaminferno,\nWelcome to the community \nThe crowdsale contracts were not included in OpenZeppelin Contracts 3.x\n\n_From: https://docs.openzeppelin.com/contracts/3.x/crowdsales_\ndue to both a decline in their usage and the complexity associated with migrating them to Solidity v0.6.\n\nOpenZeppelin Contracts 2.x (Solidity 0.5) includes Crowdsale contracts: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nYou can see these contracts in the GitHub repository using a 2.x release tag, the latest being v2.5.1:\n\nIf you have already created a token in OpenZeppelin Contracts 3.x, you could create a separate project for your Crowdsale and extend from the Crowdsales in OpenZeppelin Contracts 2.x.\nWhen creating an ERC20 token I suggest looking at Points to consider when creating a fungible token (ERC20, ERC777)\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use Crowdsale Smart Contracts\n\n Contracts\n\n erc20\n\n 1\n\n 683\n\n May 2020\n\n Where are crowdsales?\n\n Contracts\n\n 7\n\n 2.7k\n\n Feb 2022\n\n Where is the Crowdsale base token?\n\n Support\n\n erc20\n\n 4\n\n 514\n\n May 2021\n\n CrowdSale modules supported on OpenZeppelin 4x?\n\n Contracts\n\n erc20,crowdsale\n\n 1\n\n 1.5k\n\n Sep 2021","tokens":483,"squid":"ink-security_audits","role":"Sentinel","at":1791265521043,"hash":"1f43a4e5e82fa917cd572bdebb7523eb1a28b0a0"}
{"url":"https://dev-forum.pyth.network/t/encountering-error-using-price-feeds/263/1","domain":"dev-forum.pyth.network","title":"Encountering error using price feeds - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Encountering error using price feeds \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2025\n\n 1 / 3\n\n Jul 2025\n\n Jul 2025\n\n post by strawberry on Jul 3, 2025\n\n strawberry\n\n Hi, I am encountering an error when trying to use pyth-sdk-solidity, I am hoping somebody here can spot the problem.\nI am deploying on Flow Testnet.\nThis is the contract code:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.28;\n\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n//This contract uses Pyth\ncontract FlowUsdPriceFeed {\n IPyth pyth;\n bytes32 flowusd_identifier;\n\n uint256 private alpha = 1e18; //Smoothing factor\n\n /**\n * @param pythContract The address of the Pyth contract 0x2880aB155794e7179c9eE2e38200202908C17B43\n _flow_usd_identifier is Crypto.FLOW/USD 0x2fb245b9a84554a0f15aa123cbb5f64cd263b59e9a87d80148cbffab50c69f30 stable\n */\n constructor(address pythContract, bytes32 _flowusd_identifier) {\n // The IPyth interface from pyth-sdk-solidity provides the methods to interact with the Pyth contract.\n // Instantiate it with the Pyth contract address from https://docs.pyth.network/price-feeds/contract-addresses/evm\n pyth = IPyth(pythContract);\n flowusd_identifier = _flowusd_identifier;\n }\n\n //Returns the mantissa and the expo which is negative\n function getPrice() external view returns (int64, int32) {\n PythStructs.Price memory price = pyth.getPriceNoOlderThan(\n flowusd_identifier,\n 60 \n );\n return (price.price, price.expo);\n }\n\n /**\n * @notice Returns the EWMA price using new oracle data\n * @param mantissa The raw integer price from the oracle (e.g., 4049444)\n * @param exponent The number of decimals the mantissa should be divided by (e.g., 8)\n */\n\n function getEWMAPrice(\n uint256 mantissa,\n uint256 exponent\n ) external pure returns (uint256) {\n require(exponent <= 77, \"Exponent too large\"); // Prevent overflow: 10^77 is close to uint256 max\n uint256 denominator = 10 ** exponent;\n\n // Convert price to fixed-point (1e18 scale)\n uint256 price = (mantissa * 1e18) / denominator;\n\n return price;\n }\n}\n\nWhen trying to call the getPrice function with ethers.js, the function reverts:\nError: execution reverted (unknown custom error) \nThe address of the pyth contract is : 0x2880aB155794e7179c9eE2e38200202908C17B43\nThe identifier for the price feed is : 0x2fb245b9a84554a0f15aa123cbb5f64cd263b59e9a87d80148cbffab50c69f30\n\n 2\n\n post by Aditya520 on Jul 3, 2025\n\n Aditya520\n\nHey, are you updating the prices before calling the method?\nYou can try the same method here in our API Reference.\n\n post by strawberry on Jul 4, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Price feed in Avalanche not working\n\n Price Feeds\n\n evm\n\n 1\n\n 302\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Custom error 0x6ce2251a\n\n Price Feeds\n\n 8\n\n 633\n\n Apr 2025\n\n Powered by Discourse","tokens":1667,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265527833,"hash":"acec036d1bf93a9f043b6f68a75b1e37919fa772"}
{"url":"https://forum.openzeppelin.com/t/how-to-create-a-crowdsale-with-solidity-0-6/3877/3","domain":"forum.openzeppelin.com","title":"How to create a Crowdsale with Solidity 0.6? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2020\n\n 3 / 3\n\n Sep 2020\n\n Sep 2020\n\n post by arkhaminferno on Sep 19, 2020\n\n arkhaminferno\n\n Hello guys ,\nI want to make a crowdsale smart Contract.\nAs i could see crowdsale contract has been removed from openzepplin v3.0 .\n. How to implement it in v3.0 oz Contracts?\nI have made the erc20 contract using openzepplin.\n\n post by speedevs on Sep 19, 2020\n\n speedevs\n\n yes me too , i was shocked\n\n post by abcoathup on Sep 21, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @arkhaminferno,\nWelcome to the community \nThe crowdsale contracts were not included in OpenZeppelin Contracts 3.x\n\n_From: https://docs.openzeppelin.com/contracts/3.x/crowdsales_\ndue to both a decline in their usage and the complexity associated with migrating them to Solidity v0.6.\n\nOpenZeppelin Contracts 2.x (Solidity 0.5) includes Crowdsale contracts: https://docs.openzeppelin.com/contracts/2.x/crowdsales\nYou can see these contracts in the GitHub repository using a 2.x release tag, the latest being v2.5.1:\n\nIf you have already created a token in OpenZeppelin Contracts 3.x, you could create a separate project for your Crowdsale and extend from the Crowdsales in OpenZeppelin Contracts 2.x.\nWhen creating an ERC20 token I suggest looking at Points to consider when creating a fungible token (ERC20, ERC777)\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use Crowdsale Smart Contracts\n\n Contracts\n\n erc20\n\n 1\n\n 683\n\n May 2020\n\n Where are crowdsales?\n\n Contracts\n\n 7\n\n 2.7k\n\n Feb 2022\n\n Where is the Crowdsale base token?\n\n Support\n\n erc20\n\n 4\n\n 514\n\n May 2021\n\n CrowdSale modules supported on OpenZeppelin 4x?\n\n Contracts\n\n erc20,crowdsale\n\n 1\n\n 1.5k\n\n Sep 2021","tokens":471,"squid":"ink-security_audits","role":"Sentinel","at":1791265531410,"hash":"9834cf5ea7183ec0bdc5da9baf80b5dcc5f2fcd9"}
{"url":"https://forum.openzeppelin.com/t/where-are-crowdsale-contracts-in-openzeppelin-contracts-3-0/2348/1","domain":"forum.openzeppelin.com","title":"Where are Crowdsale contracts in OpenZeppelin Contracts 3.0? - Archive / SDK - OpenZeppelin Forum","text":"Where are Crowdsale contracts in OpenZeppelin Contracts 3.0? \n\n ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n 3\n\n 2\n\n Feb 2020\n\n 1 / 15\n\n Feb 2020\n\n Jun 2021\n\n post by Revinand on Feb 18, 2020\n\n Revinand\n\n Hello. Is the situation with the crowdsale related contracts the same (Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?)? Seems it was removed in this commit.\nI don’t want to push you, but maybe you could provide any rough estimate when do you plan to add it back?\nThanks for your help and the great job you’re doing.\n\n Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?\n\n Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Coding Journey: An Idea turned Obsession\n\n Crowdsale?\n\n 4\n\n 3\n\n 3\n\n 2\n\n post by abcoathup on Feb 18, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Revinand,\nWelcome to the community .\nCrowdsales have been removed from the OpenZeppelin Contracts v3.0 beta release and there are no plans to migrate them to Solidity 0.6. If you need a crowdsale you can use OpenZeppelin Contracts 2.5:\n\nCrowdsales were removed: we’ll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.\n\nNote: You should only use code published in an official release of OpenZeppelin Contracts. When importing via GitHub on Remix you can specify the release tag, (otherwise you will get the latest code in the master branch).\n\n post by Revinand on Feb 18, 2020\n\n Revinand\n\n Got it. Thanks for a quick reply\n\n post by abcoathup on Feb 18, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Revinand,\nAre you working on a Crowdsale?\nAre you importing OpenZeppelin Contracts via npm or via GitHub?\n\n post by Revinand on Feb 19, 2020\n\n Revinand\n\n Hello @abcoathup,\nYes, I am. It’s a small crowdsale, so I need a very basic functionality, but I want to follow the best practices. That’s why I chose OpenZeppelin and asked why did you remove these contracts from the new version. If you say that v2.5 is ok, then it’s fine for me.\nFor now I’m using truffle as testing environment (didn’t have much time to try yours) and importing contracts via npm.\nAlso I noticed that you have Network JS project and going to try it in my React app.\n\n post by abcoathup on Feb 19, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Revinand,\nCrowdsales are in OpenZeppelin Contracts 2.5. Feel free to ask any questions that you need.\nAny solution should be appropriately tested and audited. You should also obtain appropriate regulatory advice.\nCrowdsales weren’t included in the migration to Solidity 0.6 (OpenZeppelin Contracts 3.0) based on need/demand.\nOut of interest, what is your token being used for?\nAs an FYI: OpenZeppelin CLI 2.8: Release Candidate includes regular (non-upgradeable) deploys.\nSo you could test with OpenZeppelin Test Environment and deploy with OpenZeppelin CLI.\n\n 2 months later\n\n post by moisesja on Apr 12, 2020\n\n moisesja\n\n abcoathup\n\n Hello @abcoathup, since crowdsales will be removed with v3.0 What is the recommended pattern as a replacement for them? In my solution I will be deploying N number of token contracts (ERC777).\nThe buyer of a token must send ether and the ether gets transferred to the issuer of those tokens (just like in buyTokens in Crowdsale). The tokens will be capped and are all minted at once.\nMay I make a suggestion. Please add the fact that crowdsales are deprecated in the docs. I started using them trusting the documentation and now I have invested too much time in them.\nThanks!\nMoises\n\n 4 months later\n\n Split this topic on Aug 23, 2020\n\n A post was split to a new topic: Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?\n\n post by frangio on Aug 31, 2020\n\n frangio\n\n OpenZeppelin Team\n\n moisesja\n\n Do you mean this page? https://docs.openzeppelin.com/contracts/2.x/crowdsales\nWe could add a notice saying that they are no longer present in 3.x.\n\n 27 days later\n\n post by PradhumnaPancholi on Sep 28, 2020\n\n PradhumnaPancholi\n\n abcoathup\n\n Kind of a follow-up question on this. So, my ERC-20 token is built using OpenZeppelin v3, and for crowd sale, I will need v2.5. So, is it okay to create these contracts in two different projects? Coz most ppl I know who were writing crowd sales wrote both their token and their crowd sale contract in the same project (the project is a truffle project and Openzeppelin is installed via npm).\n\n post by abcoathup on Sep 28, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nI think having a project for a Crowdsale extending from OpenZeppelin Contracts 2.x and a separate project for an ERC20 token extending from OpenZeppelin Contracts 3.x is an acceptable approach.\nThe crowdsale has a limited life, whilst the token is meant to have a long life.\nFor any post on tokens I suggest looking at: Points to consider when creating a fungible token (ERC20, ERC777)\n\n 9 months later\n\n post by stranger on Jun 12, 2021\n\n stranger\n\n abcoathup\n\n Hi,\nI know this is very old conversation but I want to use the crowdsale contract so my only option would be version 2.5 which is extremely old by now.\nIs it still safe to use it now in 2021 or should I opt to custom or other solution?\nThank you for advance.\n\n post by frangio on Jun 14, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Older versions are safe to use. You may want to take a look at the changelog to see if anything newer since then looks important to your project.\n\n post by stranger on Jun 14, 2021\n\n stranger\n\n Thank you very much. I have already started building the crowd sale using v2.5 and I intend to build the contract also using 2.5 so I don’t have to maintain two truffle projects one for the token and one for the ico.\nThere doesn’t seem to be important changes that would affect my project directly in newer versions.\n\n post by stranger on Jun 14, 2021\n\n stranger\n\n frangio\n\n Actually there seems to be a way to use two config files so I will give that a shot to use OpenZeppelin v4 with the token but 2.5 for the ICO.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to create a Crowdsale with Solidity 0.6?\n\n Contracts\n\n 2\n\n 1.7k\n\n Sep 2020\n\n Where are crowdsales?\n\n Contracts\n\n 7\n\n 2.7k\n\n Feb 2022\n\n CrowdSale modules supported on OpenZeppelin 4x?\n\n Contracts\n\n erc20,crowdsale\n\n 1\n\n 1.5k\n\n Sep 2021\n\n Can I use Crowdsale with ERC20 Token created in OZ4.5.0?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 6\n\n 898\n\n May 2022\n\n Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?\n\n Contracts\n\n 7\n\n 2.7k\n\n Aug 2020","tokens":1668,"squid":"ink-security_audits","role":"Sentinel","at":1791265541695,"hash":"425e7b475184792e6a8307250735126fcd3d1d27"}
{"url":"https://docs.optimism.io/governance/gov-faq","domain":"docs.optimism.io","title":"Optimism Documentation","text":"What is the Token House?All OP tokenholders, a key stakeholder group, are represented in governance via the Token House. The Token House uses token-weighted voting, giving influence proportional to OP token holdings. Tokenholders may vote themselves or assign their voting power to a “delegate.” The primary role of tokenholders is to express their financial interest in the evolution of the Superchain and to hold proposers accountable. Tokenholders may vote on:Protocol UpgradesDelegates have the power to veto decisions about protocol upgrades made by the Developer Advisory Board (DAB). This veto power serves as a critical check on technical changes, with the aim of ensuring they align with the interests of those who rely on the protocol.Capital AllocationDelegates participate in resource allocation decisions, including:\nApproving the Collective Intent, missions, and budget\nApproving Governance Fund proposals\nRepresentative ElectionsDelegates elect members to the Councils and Boards and/or approve any alternative selection mechanismsRatificationDelegates may ratify core governing documents.For a full description of the voting mechanics for each of these proposal types, please refer to the Operating Manual. In future phases, the Token House may gain additional governance powers.How do I vote with my tokens?Unlock Your Voting PowerOP token holders are able to vote on some of the most important decisions for the Collective. This empowers one of the Collective’s key stakeholders to have a say in the development of the system.You can either vote yourself with your OP tokens, or you can delegate the voting power of your OP tokens to someone else to make decisions on your behalf.Get started at vote.optimism.io/delegatesWhat is the Citizens' House?Users, Apps, and Chains, key stakeholder groups, are represented in governance via the Citizens’ House. The Citizens’ House uses a ‘1 member, 1 vote’ model, so all members have the same level of influence. The primary role of Citizens is to express their preferences in the evolution of the Superchain and to hold proposers accountable. Citizens may vote on:​Protocol UpgradesCitizens have the power to veto decisions about protocol upgrades made by the Developer Advisory Board (DAB). This veto power serves as a critical check on technical changes, ensuring they align with the interests of those who rely on the protocol.​Resource AllocationCitizens participate in resource allocation decisions, including:\nApproving the Collective Intent, missions, and budget\n​Representative ElectionsCitizens elect representatives to the Developer Advisory Board, ensuring it remains accountable to their interests.​RatificationCitizens may ratify core governing documents.For a full description of the voting mechanics for each of these proposal types, please refer to the Operating Manual. In future phases, the Citizens’ House may gain additional governance powers.How do I become a Citizen?​Eligibility Framework and PrinciplesThe Citizens’ House relies on a carefully designed eligibility framework aimed at achieving representation from key stakeholders in the Superchain ecosystem. This framework is built on the following principles:1.Those who are most impacted by Protocol Upgrades should have governance power over them2.Those who contribute most to shared resources should have a voice in the governance of those shared resourcesEligibility criteria include three distinct stakeholder groups within the Citizens’ House:1.Chains2.Onchain Applications3.Superchain End-Users​Citizenship Eligibility CriteriaEligibility is recalculated at the beginning of every Season, and criteria are subject to change.​Chain Citizens​Eligibility Criteria in Season 9Chains are eligible to vote in the Citizens’ House if they meet either of these criteria:\nAccount for at least 2% of the total revenue share contributed by all chains in the past Season\nAre among the top 15 chains by revenue contribution in the past Season\nEligibility for Season 9 is calculated based on activity from 01 August 2025 - 31 December 2025. This approach aims to give chains with significant economic stake in the ecosystem a voice in governance, while the minimum number of seats (15) should mean broad representation even if revenue becomes concentrated.​App Citizens​Eligibility CriteriaOnchain applications are eligible to join the Citizens’ House if they meet either of these criteria:\nAre responsible for at least 0.5% of the total gas used across the Superchain over the past Season\nAre among the top 100 apps by gas usage in the past Season\nEligibility for Season 9 is calculated based on activity from 01 August 2025 - 31 December 2025 based on contract data registered by projects in OP Atlas. Projects/contracts not registered in OP Atlas cannot be considered at this time. This approach aims to give applications driving significant activity on the Superchain a voice in governance, while the minimum number of seats (100) should mean broad representation from the application ecosystem.​End-user Citizens​Eligibility CriteriaIndividual end-users are eligible to join the Citizens’ House if they meet all of these criteria:\nHad their first Superchain transaction before June 1, 2024\nHave at least 2 Superchain transactions each month in at least 3 distinct months from 01 August 2025 - 31 December 2025\nCan provide proof of personhood through World ID or Passport\nTo check the eligibility of your address, navigate to atlas.optimism.io/citizenship and link the address to your Atlas profile. These criteria are designed so that Citizens will be genuine, active users of the Superchain with sustained engagement over time, rather than one-time or sporadic users.​Selection ProcessTo register as an end-user Citizen, please visit https://atlas.optimism.io/citizenshipUntil Sybil-resistance mechanisms are more mature, the Optimism Foundation may suspend Citizens flagged as possible Sybils and request further verification of unique personhood.How do the Token House and the Citizens' House work together? The Token House and the Citizens’ House together represent all key stakeholders of the Superchain: tokenholders, chains, apps, and end-users. Both houses vote on proposals when the interests of all stakeholders should be represented in a particular decision. Each house has a distinct voting mechanism which, when combined together, creates a system of checks and balances aimed at balancing competing interests.Voting happens on a regular schedule via three-week voting cycles. Regular voting Cycles begin on Thursday at 19:00p GMT (12p PST) and end on Wednesday at 19:00 GMT (12p PST). Protocol Upgrades may go through an accelerated process. You can view full details here. You can track cycles on the governance calendar.What is expected of voters?Key stakeholders of the Superchain can protect their interests by participating in Optimism’s public decision making process (governance). This process allows stakeholders to influence the future of the Superchain with limited day-to-day involvement.Key stakeholders will be asked to:\nVote: 1-2 times per year\nProvide input: 3-4 times per year\nVeto: only as needed\nEmail notifications will be sent to all stakeholders whenever any of the above actions is possible. Stakeholders can also monitor activity directly at vote.optimism.io or atlas.optimism.ioToken House Voters\nActivity: The social standard for being an active delegate is participating in 70% of all votes.\nNo self-dealing: Voters are prohibited from approving and voting on their own proposals. Voters may not vote solely for their own candidacy in an election. In the case of approval/ranked choice elections, optimists may vote for themselves, so long as they also cast votes for the remaining elected positions.\nConflicts of Interest: Any actual or reasonably anticipated conflicts of interest must be disclosed in writing and prominently displayed ahead of any voting (i.e. when approving proposal drafts, when running for an elected position, when making public recommendations).\nThese guidelines help ensure that the Token House remains active and resistant to capture or manipulation.Citizens House VotersTo maintain the integrity of the Citizens’ House, several important rules govern participation:\nNo Double Representation: If you are an admin of a Citizen project or organization, you may not also join the Citizens’ House as a Superchain user.\nOrganization Priority: An organization and a project under that organization can never both get votes in the Citizens’ House. If both are eligible, membership defaults to the organization.\nNo Multiple Accounts: It is forbidden to create multiple accounts to attempt to get multiple votes in the Citizens’ House as a Superchain user. In Season 8, Citizens will be manually reviewed for possible Sybil activity by the Optimism Foundation.\nSeasonal Recalculation: The eligibility criteria for being a member of the Citizens’ House will be recalculated every Season and may change—being a Citizen now doesn’t guarantee future Citizens’ House membership.\nThese rules help ensure that the Citizens’ House remains balanced, representative, and resistant to capture or manipulation.You can view the Code of Conduct here.What is Retro Funding?Funding public goods is core to Optimism’s values and vision for a healthy ecosystem. Retroactive Public Goods Funding (Retro Funding) is an experimental grant program to reward public goods that have created impact in the Optimism ecosystem. Learn more at atlas.optimism.ioHow does identity work within the Optimism ecosystem? Identity in the Optimism Collective is built on onchain attestations, created with the Ethereum Attestation Service (“EAS”) — an open-source public good that is included as a predeploy in the OP Stack. Attestations represent Citizenship, project and organization identity, Retro Funding participation, and governance roles.\nFor how attestations work and why the Collective uses them, see How identity works in the Optimism Collective.\nFor EAS contract addresses, how to read and write attestations, and the full schema catalogue, see the EAS contracts and attestation schemas reference.\nWhere can I find governance dashboards, trackers, and addresses?Relevant governing documents, OP trackers, Foundation budget reports, Retro Funding round results, and Optimism Foundation wallet addresses are collected on the dashboards, trackers, and addresses page, alongside the Superchain Health Dashboard.What is the Optimism Foundation?The Optimism Foundation is a Cayman Islands foundation company. It operates to support the establishment of the Optimism Collective, the development of the Optimism ecosystem, and the technology that powers it.Consistent with the Collective’s Working Constitution, the Foundation strives to:\nSupport the Collective with a formal legal entity, allowing the Foundation to:\n\nEnter into contracts with third parties, such as service providers.\nAdminister intellectual property rights.\nMake required governmental reports and filings.\n\nHow does the Foundation work?The Optimism Foundation is governed by a Board of Directors and a Supervisor.The Board of Directors currently consists of: Abbey Titcomb, Mark Tyneway, Brian Avello, and Jing Wang. The Board’s role is to manage the business and affairs of the Foundation.The Supervisor is the Cayman Islands firm, DS Limited. Its role is to oversee the Foundation’s directors and ensure the observance of their legal obligations.The Foundation also employs officers, contractors and service providers to execute on its operational and administrative aims.How is the Foundation held accountable?As a Cayman Islands foundation company, the Foundation is legally accountable to its governing documentation, which sets up the Foundation to defer to the will of the Optimism Collective and its governance.There are two governance proposal types specifically targeted towards ensuring that the Foundation and its personnel are accountable to the will of the Collective:\nDirector removal - the ability of governance to have a member of the Foundation’s Board of Directors removed from service.\nRights protections - a blocking vote, which enables governance to veto any proposed change to the Foundation’s governing documents that would materially reduce the rights of OP token holders.\nMore information on each of the above proposal types is contained in the Operating Manual.Was this page helpful?","tokens":3110,"squid":"ink-governance","role":"Council Listener","at":1791265544907,"hash":"f8c69b601edbe86733ab75254dd70f1dbdf6b343"}
{"url":"https://dev-forum.pyth.network/t/encountering-error-using-price-feeds/263/3","domain":"dev-forum.pyth.network","title":"Encountering error using price feeds - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2025\n\n 3 / 3\n\n Jul 2025\n\n Jul 2025\n\n post by strawberry on Jul 3, 2025\n\n strawberry\n\n Hi, I am encountering an error when trying to use pyth-sdk-solidity, I am hoping somebody here can spot the problem.\nI am deploying on Flow Testnet.\nThis is the contract code:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.28;\n\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\n//This contract uses Pyth\ncontract FlowUsdPriceFeed {\n IPyth pyth;\n bytes32 flowusd_identifier;\n\n uint256 private alpha = 1e18; //Smoothing factor\n\n /**\n * @param pythContract The address of the Pyth contract 0x2880aB155794e7179c9eE2e38200202908C17B43\n _flow_usd_identifier is Crypto.FLOW/USD 0x2fb245b9a84554a0f15aa123cbb5f64cd263b59e9a87d80148cbffab50c69f30 stable\n */\n constructor(address pythContract, bytes32 _flowusd_identifier) {\n // The IPyth interface from pyth-sdk-solidity provides the methods to interact with the Pyth contract.\n // Instantiate it with the Pyth contract address from https://docs.pyth.network/price-feeds/contract-addresses/evm\n pyth = IPyth(pythContract);\n flowusd_identifier = _flowusd_identifier;\n }\n\n //Returns the mantissa and the expo which is negative\n function getPrice() external view returns (int64, int32) {\n PythStructs.Price memory price = pyth.getPriceNoOlderThan(\n flowusd_identifier,\n 60 \n );\n return (price.price, price.expo);\n }\n\n /**\n * @notice Returns the EWMA price using new oracle data\n * @param mantissa The raw integer price from the oracle (e.g., 4049444)\n * @param exponent The number of decimals the mantissa should be divided by (e.g., 8)\n */\n\n function getEWMAPrice(\n uint256 mantissa,\n uint256 exponent\n ) external pure returns (uint256) {\n require(exponent <= 77, \"Exponent too large\"); // Prevent overflow: 10^77 is close to uint256 max\n uint256 denominator = 10 ** exponent;\n\n // Convert price to fixed-point (1e18 scale)\n uint256 price = (mantissa * 1e18) / denominator;\n\n return price;\n }\n}\n\nWhen trying to call the getPrice function with ethers.js, the function reverts:\nError: execution reverted (unknown custom error) \nThe address of the pyth contract is : 0x2880aB155794e7179c9eE2e38200202908C17B43\nThe identifier for the price feed is : 0x2fb245b9a84554a0f15aa123cbb5f64cd263b59e9a87d80148cbffab50c69f30\n\n 2\n\n post by Aditya520 on Jul 3, 2025\n\n Aditya520\n\nHey, are you updating the prices before calling the method?\nYou can try the same method here in our API Reference.\n\n post by strawberry on Jul 4, 2025\n\n strawberry\n\n Thanks for the reply.\nWhat I needed was the getEmaPriceUnsafe so I can call the function from a view function without paying for an update.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Price feed in Avalanche not working\n\n Price Feeds\n\n evm\n\n 1\n\n 302\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Custom error 0x6ce2251a\n\n Price Feeds\n\n 8\n\n 633\n\n Apr 2025\n\n Powered by Discourse","tokens":1696,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265547763,"hash":"10de52b02e7ab8442f4884eb49f9de6b148c101d"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0-beta-release/2256","domain":"forum.openzeppelin.com","title":"OpenZeppelin Contracts v3.0 beta release - General / Announcements - OpenZeppelin Forum","text":"OpenZeppelin Contracts v3.0 beta release \n\n GeneralAnnouncements\n\n release\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 2020\n\n 1 / 1\n\n Feb 2020\n\n Feb 2020\n\n post by nventuro on Feb 14, 2020\n\n nventuro\n\n Great contributor\n\ncover_forum_contracts3.02400×1350 217 KB\n\nWe’re excited to announce the beta release of OpenZeppelin Contracts v3.0 \nThis is the main item in Contract’s roadmap, featuring the migration to Solidity v0.6.\nTo install the beta release, run:\nnpm install --save-dev @openzeppelin/contracts@beta\n\nWhat’s Included in the Beta\nThe final v3.0 release is not yet finished, but we’re putting together this beta version early to ease the transition to this new Solidity version for the community.\nHere’s what you will find in the beta:\n\nAll contracts were migrated to ^0.6.0.\nRoles contracts (such as MinterRole and PauserRole) were removed: we’re redesigning our Access Control solution and will have a better version of these in the v3.0 release.\nCrowdsales were removed: we’ll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.\nWe’ve added hooks, a new feature of the library that will make extending it easier than ever. Read more below!\n\nWe expect for the final v3.0 release to come out in early March. If you want to contribute, head to our list of pending changes: most of them can be tackled quickly by beginner and intermediate users!\nCompiling v0.6 Contracts\nYou can use the OpenZeppelin CLI to compile any Solidity v0.6 contract: just update the pragma statement on your source code and you’ll be good to go!\npragma solidity ^0.6.0;\n\nNote that you will need to use the recent v2.7 release of the CLI to have Solidity v0.6 support. For detailed information about using the CLI compiler, head to its documenation.\nMigrating From OpenZeppelin Contracts v2.5\nOther than the contract removals mentioned above, the library API is pretty much the same as in the v2.5 release, so the migration should be straightforward. For instructions on how to update your Solidity v0.5 contracts to v0.6, refer to the official documentation.\nThe exception to this is contracts that use the Gas Station Network (GSN): if you’re inheriting from GSNRecipient or one of the other GSN contracts, you’ll need to add the following snippet to your contracts:\nfunction _msgSender() internal view override(Context, GSNRecipient) returns (address payable) {\n return GSNRecipient._msgSender();\n}\n\nfunction _msgData() internal view override(Context, GSNRecipient) returns (bytes memory) {\n return GSNRecipient._msgData();\n}\n\nUsing Hooks\nTo improve library flexibility, we’re introducing hooks: functions that are called at specific moments during a contract’s operation that you can use to hook into the internals and extend as you wish.\nFor example, the _beforeTokenTransfer hook in ERC20, ERC721 and ERC777 makes it very easy to add additional checks or actions to execute whenever tokens are transferred, minted or burned, regardless of what prompted it.\n// Tokens can only be transferred, minted or burned if the contract is not paused\ncontract ERC20Pausable is ERC20, Pausable {\n function _beforeTokenTransfer(address from, address to, uint256 amount) \n internal virtual override \n {\n super._beforeTokenTransfer(from, to, amount);\n\n require(!paused(), \"ERC20Pausable: token transfer while paused\");\n }\n}\n\nAs an additional benefit, using hooks will allow you to side-step some of the edge-cases product of the new override keyword.\nNext Steps\nThe final v3.0 release is still a couple weeks away, but you can help us get there faster! Head to the list of v3.0 pending changes to learn about areas where you can contribute, or take a look at Contract’s roadmap for more information on the general direction we’re taking.\nWhile you wait for v3.0 to come out, check out the recent v2.5 release, the final OpenZeppelin Contracts release with support for Solidity v0.5, and our newly improved documentation site, with tons of guides, API References and other learning resources!\n\n Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Creating an ERC-20 token that supports GSN transactions\n\n OpenZeppelin Quick Reference for the Busy Hacker\n\n SimpleERC721Token using OpenZeppelin Contracts\n\n CrowdSale modules supported on OpenZeppelin 4x?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OpenZeppelin Contracts v3.0\n\n Announcements\n\n 1\n\n 5.5k\n\n May 2020\n\n OpenZeppelin Contracts v3.0 final release candidate\n\n Announcements\n\n 7\n\n 4.0k\n\n Apr 2020\n\n OpenZeppelin Contracts v3.0 release candidate\n\n Announcements\n\n 6\n\n 3.4k\n\n Apr 2020\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Announcements\n\n 0\n\n 3.2k\n\n May 2020\n\n OpenZeppelin Contracts 3.2\n\n Announcements\n\n openzeppelin-contracts,release\n\n 0\n\n 2.2k\n\n Sep 2020","tokens":1213,"squid":"ink-security_audits","role":"Sentinel","at":1791265551839,"hash":"6e51439ee5fe907304daf2ef8a6548dfdedcab33"}
{"url":"https://docs.optimism.io/governance/attestation-schemas","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This page catalogues the Ethereum Attestation Service (“EAS”) contract addresses on OP Mainnet and OP Sepolia, the ways to read and write attestations, and the attestation schemas used across the Optimism Collective.\nFor how attestations underpin identity in the Collective, see How identity works in the Optimism Collective.\nFor details on the EAS predeploys themselves, see the smart contracts overview.\n​EAS contract addresses\nThe Ethereum Attestation Service is deployed on these addresses:\nNetworkAttestation ContractSchema Registry ContractOP Sepolia0x42000000000000000000000000000000000000210x4200000000000000000000000000000000000020OP Mainnet0x42000000000000000000000000000000000000210x4200000000000000000000000000000000000020\n​How to read and write attestations\nYou can read and write attestations in several ways:\n\nEAS scan user interface (OP Mainnet)\nEAS scan user interface (OP Sepolia)\nJavaScript SDK\nAccess directly onchain (if you need to attest from a smart contract)\n\n​Indexing\nIndexing is available via:\n\nGraphQL endpoint\nPonder graph\nOpen source indexer\n\n​Schemas\nSchemas define the structure and type of data that can be included in an attestation.\nBelow you will find a list of relevant schemas that are being used on OP Mainnet. Schemas are built using the Ethereum Attestation Service.\n​General schemas\n\nGitcoin Passport V1 scores schema UID: 0x6ab5d34260fca0cfcf0e76e96d439cace6aa7c3c019d7c4580ed52c6845e9c89\nSuperchain Faucet schema UID: 0x98ef220cd2f94de79fbc343ef982bfa8f5b315dec6a08f413680ecb7085624d7\n\n​Schemas related to project creation and Retro Funding application\nProject and organization identifier\nUsed as the unique identifier for projects and organizations created on or after 23 August 2024. For projects created earlier, please see the archived schemas at the bottom of this page.\nSchema UID0xff0b916851c1c5507406cfcaa60e5d549c91b7f642eb74e33b88143cae4b47d0IssuerAttestations issued as part of Retro Funding sign up are issued by 0xF6872D315CC2E1AfF6abae5dd814fd54755fE97CfarcasterIDThe Farcaster id of the individual who created the project or organizationtype”Project” or “Organization”\nOrganization metadata\nUsed to associate metadata to an organization. Re-issued each time there is a change to metadata\nSchema UID0xc2b376d1a140287b1fa1519747baae1317cf37e0d27289b86f85aa7cebfd649fIssuerAttestations issued as part of Retro Funding sign up are issued by 0xF6872D315CC2E1AfF6abae5dd814fd54755fE97CRecipientNullRefUIDThe attestation UID of the organization this metadata relates tofarcasterIDThe Farcaster id of the individual who published the organization metadatanameThe name of the organizationprojectsThe array of projects that belong to this organizationparentOrgUIDThe attestation UID of this organization’s parent, in case it has onemetadataTypeHow the metadata can be accessed. 1 for ipfs, 2 for httpmetadataUrlThe storage location where the metadata can be retrieved\nProject metadata\nUsed to associate metadata to a project. Re-issued each time there is a change to metadata.\nSchema UID0xe035e3fe27a64c8d7291ae54c6e85676addcbc2d179224fe7fc1f7f05a8c6eacIssuerAttestations issued as part of Retro Funding sign up are issued by 0xF6872D315CC2E1AfF6abae5dd814fd54755fE97CRecipientNullprojectRefUIDThe attestation UID of the project this metadata relates tofarcasterIDThe Farcaster id of the individual who published the project metadatanameThe name of the projectcategoryThe category of the projectparentProject RefUIDThe attestation UID of this project’s parent project, in case it has a parentmetadataTypeHow the metadata can be accessed. 1 for ipfs, 2 for httpmetadataUrlThe storage location where the metadata can be retrieved\nRetro funding application\nUsed to identify a project’s application to a specific Retro Funding Round. This attestation is used for Retro Funding Round 6 and beyond.\nSchema UID0x2169b74bfcb5d10a6616bbc8931dc1c56f8d1c305319a9eeca77623a991d4b80IssuerAttestations issued as part of Retro Funding sign up are issued by: 0xF6872D315CC2E1AfF6abae5dd814fd54755fE97CRecipientNullroundThe round number for which this application was submittedmetadataTypeHow the metadata can be accessed. 1 for ipfs, 2 for httpmetadataUrlThe storage location where the metadata can be retrievedfarcasterIDThe individual that submitted this application on behalf of the project.metadataSnapshot RefUIDThe project metadata at the time the application was submitted.\nRetro funding application approval/rejection\nUsed to identify which Retro Funding applications have been approved or rejected.\nSchema UID0x683b1b399d47aabed79c9aa8f2674729021174b6e5cce1e20675eab404fc82d6IssuerCurrently, the Optimism Foundation issues these from the following address: 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226FRecipientNullprojectApplicationUIDThe unique identifier of the projects Retro Funding application.StatusThe status of the Retro Funding application.ReasonIdentifier for the reason an application was rejected. 1 = “Duplicate Application”, 2 = “Deceiving Badgeholders”, 3 = “Spam”, 4 = “Not meeting eligibility criteria”\nRetro funding rewards\nUsed to identify the reward amount each approved project received in a Retro Funding round\nSchema UID0x670ad6e6ffb842d37e050ea6d3a5ab308195c6f584cf2121076067e0d8adde18IssuerCurrently, the Optimism Foundation issues these from the following address: 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226FRecipientNullrefUIDThe UID of the Retro Funding applicationprojectRefUIDThe unique identifier of the projectroundThe retro round for which the project was rewardedOPamountThe amount of OP awarded to the project\n​Schemas related to token house grants\nToken house grant approved\nIssued by the Grants Council when a project is approved for a grant. Does not indicate that the grant has been completed.\nSchema UID0x8aef6b9adab6252367588ad337f304da1c060cc3190f01d7b72c7e512b9bfb38IssuerCurrently issued by the Grants Council lead.RecipientThe address where the tokens will be delivered once the grant has been completed.refUIDCurrently nullprojectRefUIDThe unique identifier of the project that was approved for the grant.UserIncentivesOPThe OP amount approved for user incentives.BuildersOPThe OP amount approved for the builder.SeasonThe season (number) in which the grant was approvedIntentThe intent (number) to which the mission belongsMissionThe name of the mission (in words) under which this grant was made.Approval dateThe date the grant was approved, in the following format MM/DD/YYYYMetadataUrlCurrently null\n​Schemas related to roles and contributions\nCitizens\nCitizen attestations were first issued in Season 6 and are used to represent Citizenship separately from the ability to vote in a specific Retro Round. The resolver contract checks that the issuer is the Foundation with following address 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F\nSchema UID0xc35634c4ca8a54dce0a2af61a9a9a5a3067398cb3916b133238c4f6ba721bc8aRefUIDIn case the Citizen is a chain or an app, the refUID field will reference the organization/project id of the chain or app. If null, the Citizen is an end-userFarcasterIDThe Citizen’s unique identifierSelectionMethodA Code representing the method through which the Citizen was selected. Codes beginning with the number 1 refer to various flavours of Web of Trust selection.\nRetro funding voters\nThese attestations are voting Badges issued for Retro Round 5 and beyond. They are different from the previous schema to include new fields like votingGroup, used to assign voters to sub-categories in the round.\nSchema UID0x41513aa7b99bfea09d389c74aacedaeb13c28fb748569e9e2400109cbe284ee5FarcasterIDThe voter’s unique identifierRoundThe round number for which this voting Badge was validvoterTypeGuest or CitizenvotingGroupUsed to assign voters to subcategories in case the Round has subcategoriesselectionMethodThe method in which this voter was selected\nMetaGov contribution\nSchema UID0x84260b9102b41041692558a4e0cba6b7e5f9b813be56402c3db820c06dd4a5f1IssuerCurrently, the Optimism Foundation issues these from one of the following addresses: 0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9 or 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F.RecipientThe address of the individual who made the contributionrefUIDThe UID of the project, in case this contribution is represented as a projectFarcasterIDThe id of the individual who made the contribution, if knownImpactThis field is not currently being usedSeasonThe season in which the contribution was madeDecision ModuleThe decision module to which the contribution relatesContribution TypeThe type of contributionMetadataUrlThis field is not currently being used\nFoundation mission request completed\nSchema UID0x649cc6df5af7561b66384405a62682c44e2428584d2f17a202ac3ef4506e2457IssuerCurrently, the Optimism Foundation issues these from one of the following addresses: 0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9 or 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F.projectRefUIDThe UID of the project that represents the work completed as part of the Foundation Mission RequestOP AmountThe OP Amount that was awarded for the completion of this Mission RequestSeasonThe season in which this Mission Request was completed\nRetro funding governance contribution\nSchema UID0x3743be2afa818ee40304516c153427be55931f238d961af5d98653a93192cdb3IssuerCurrently, the Optimism Foundation issues these from one of the following addresses: 0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9 or 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F.RecipientThe address of the individual who made the contributionRpgf_roundThe round number for which this contribution was madeRetroPGF_ContributionThe type of contribution made\nGovernance contribution\nIssued to those who held governance roles in the Collective, such as Grants Council members.\nSchema UID0xef874554718a2afc254b064e5ce9c58c9082fb9f770250499bf406fc112bd315IssuerCurrently, the Optimism Foundation issues these from one of the following addresses: 0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9 or 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F.RecipientThe address of the individual who made the contributiongovSeasonThe season the individual held the rolegovRoleThe role held by the individual\n​Archived schemas\nThese schemas are no longer being actively issued, but capture valuable historical data.\nRetro funding application\nUsed to identify a project’s application to a specific Retro Funding Round. This attestation was used for Retro Funding Rounds 4 and 5.\nSchema UID0x88b62595c76fbcd261710d0930b5f1cc2e56758e155dea537f82bf0baadd9a32IssuerAttestations issued as part of Retro Funding sign up are issued by: 0xF6872D315CC2E1AfF6abae5dd814fd54755fE97CRecipientNullroundThe round number for which this application was submittedprojectRefUIDThe unique identifier of the project that submitted this applicationfarcasterIDThe individual that submitted this application on behalf of the project.metadataSnapshot RefUIDThe project metadata at the time the application was submitted.\nRetro funding badgeholders\nThese attestations are considered “voting Badges” and allow an individual to vote in any given iteration of Retro Funding. They were used up to and including Retro Round 4.\nSchema UID0xfdcfdad2dbe7489e0ce56b260348b7f14e8365a8a325aef9834818c00d46b31bIssuerCurrently, the Optimism Foundation issues these from one of the following addresses: 0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9 or 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226FRecipientThe Badgeholder’s addressrpgfRoundThe round number for which this voting Badge was validreferredByIn early rounds, new Badges were issued by referral. This field captures the address of the referrer, if there was onereferredMethodIf this voting Badge was issued by referral, this field captures the referral method\nProject identifier\nUsed as the unique identifier for projects created in the Collective before 23 August 2024. Attestations issued from this schema prior to 23 August 2024 are still used as the unique identifier for projects. New projects created after 23 August 2024 use the new entity identifier (see above).\nSchema UID0x7ae9f4adabd9214049df72f58eceffc48c4a69e920882f5b06a6c69a3157e5bdIssuerAttestations issued as part of Retro Funding sign up are issued by 0xF6872D315CC2E1AfF6abae5dd814fd54755fE97CRecipientNullfarcasterIDThe Farcaster id of the individual who created the project\n\nRetroPGF 3 Approved Application schema UID: 0xebbf697d5d3ca4b53579917ffc3597fb8d1a85b8c6ca10ec10039709903b9277. Important: Remember to verify the attester address is 0x621477dBA416E12df7FF0d48E14c4D20DC85D7D9\nRetroPGF 3 Application schema UID: 0x76e98cce95f3ba992c2ee25cef25f756495147608a3da3aa2e5ca43109fe77cc\nRetroPGF 3 Lists schema UID: 0x3e3e2172aebb902cf7aa6e1820809c5b469af139e7a4265442b1c22b97c6b2a5\nSeason 4 Co-grant participant schema UID: 0x401a80196f3805c57b00482ae2b575a9f270562b6b6de7711af9837f08fa0faf. Important: Remember to verify the attester address is 0x3C7820f2874b665AC7471f84f5cbd6E12871F4cC or 0x2a0eB7cAE52B68e94FF6ab0bFcf0dF8EeEB624be\nOptimist Profile schema UID: 0xac4c92fc5c7babed88f78a917cdbcdc1c496a8f4ab2d5b2ec29402736b2cf929\nWas this page helpful?","tokens":3270,"squid":"ink-governance","role":"Council Listener","at":1791265554932,"hash":"741fab8d9161887768c3333f29c1bf12c9c66338"}
{"url":"https://dev-forum.pyth.network/t/custom-error-0x6ce2251a/54","domain":"dev-forum.pyth.network","title":"Custom error 0x6ce2251a - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Custom error 0x6ce2251a \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n Apr 2025\n\n 1 / 9\n\n Apr 2025\n\n Apr 2025\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n Just a simple price feed function following the docs to retrieve price of ETH to USD, however it reverted with this error: 0x6ce2251a\nimage772×490 39.9 KB\nHere is my script for interacting and the priceUpdate array is retrieve from Hermes, I think the array is correct because the parsed data is there.\n// SPDX-License-Identifier: MIT\npragma solidity 0.8.28;\n\nimport {Script, console} from \"forge-std/Script.sol\";\nimport {PythPriceFeed} from \"src/PythPriceFeed.sol\";\nimport {Vm} from \"forge-std/Vm.sol\";\nimport {PythStructs} from \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\ncontract GetETHUSDPrice is Script {\n PythPriceFeed pythPriceFeed;\n\n function run() external {\n address pythContract = Vm(address(vm)).getDeployment(\n \"PythPriceFeed\",\n uint64(block.chainid)\n );\n\n pythPriceFeed = PythPriceFeed(payable(pythContract));\n bytes[] memory priceUpdate = new bytes[](1);\n priceUpdate[\n 0\n ] = \"0x...\";\n\n vm.startBroadcast();\n PythStructs.Price memory price = pythPriceFeed.getEThUSDPrice(\n priceUpdate\n );\n vm.stopBroadcast();\n console.log(\"ETH/USD Price: \", price.price);\n }\n}\n\nI have also funded a few eth to my contract on Chain Sepolia: PythPriceFeed | Address 0x2127c26e297ae9782f41d99049ffc1051a157c9e | Etherscan\nHere are the full logs:\n0x2127C26e297aE9782f41D99049fFc1051A157C9E::getEThUSDPrice([0x..])\n │ ├─ [9168] ERC1967Proxy::fallback([0x...]) [staticcall]\n │ │ ├─ [3755] PythUpgradable::getUpdateFee([0x...]) [delegatecall]\n │ │ │ └─ ← [Return] 1\n │ │ └─ ← [Return] 1\n │ ├─ [14566] ERC1967Proxy::fallback{value: 1}([0x..])\n │ │ ├─ [13652] PythUpgradable::updatePriceFeeds{value: 1}([0x..]) [delegatecall]\n │ │ │ ├─ [6255] 0x41c9e39574F40Ad34c79f1C99B66A45eFB830d4c::parseAndVerifyVM(0x..) [staticcall]\n │ │ │ │ ├─ [854] 0x8D254a21b3C86D32F7179855531CE99164721933::parseAndVerifyVM(0x..) [delegatecall]\n │ │ │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ └─ ← [Revert] custom error 0x6ce2251a\n └─ ← [Revert] custom error 0x6ce2251a\n\n 5\n\n 4\n\n post by Aditya520 on Apr 15, 2025\n\n post by LuoYingjie on Apr 15, 2025\n\n post by Aditya520 on Apr 15, 2025\n\n post by LuoYingjie on Apr 15, 2025\n\n post by Aditya520 on Apr 16, 2025\n\n post by LuoYingjie on Apr 16, 2025\n\n post by Aditya520 on Apr 17, 2025\n\n post by LuoYingjie on Apr 17, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 643\n\n Jul 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":1676,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265557794,"hash":"0024cfc2854e4c315705a4fd0db967f73985e279"}
{"url":"https://dev-forum.pyth.network/t/custom-error-0x6ce2251a/54/9","domain":"dev-forum.pyth.network","title":"Custom error 0x6ce2251a - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n Apr 2025\n\n 9 / 9\n\n Apr 2025\n\n Apr 2025\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n Just a simple price feed function following the docs to retrieve price of ETH to USD, however it reverted with this error: 0x6ce2251a\nimage772×490 39.9 KB\nHere is my script for interacting and the priceUpdate array is retrieve from Hermes, I think the array is correct because the parsed data is there.\n// SPDX-License-Identifier: MIT\npragma solidity 0.8.28;\n\nimport {Script, console} from \"forge-std/Script.sol\";\nimport {PythPriceFeed} from \"src/PythPriceFeed.sol\";\nimport {Vm} from \"forge-std/Vm.sol\";\nimport {PythStructs} from \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\ncontract GetETHUSDPrice is Script {\n PythPriceFeed pythPriceFeed;\n\n function run() external {\n address pythContract = Vm(address(vm)).getDeployment(\n \"PythPriceFeed\",\n uint64(block.chainid)\n );\n\n pythPriceFeed = PythPriceFeed(payable(pythContract));\n bytes[] memory priceUpdate = new bytes[](1);\n priceUpdate[\n 0\n ] = \"0x...\";\n\n vm.startBroadcast();\n PythStructs.Price memory price = pythPriceFeed.getEThUSDPrice(\n priceUpdate\n );\n vm.stopBroadcast();\n console.log(\"ETH/USD Price: \", price.price);\n }\n}\n\nI have also funded a few eth to my contract on Chain Sepolia: PythPriceFeed | Address 0x2127c26e297ae9782f41d99049ffc1051a157c9e | Etherscan\nHere are the full logs:\n0x2127C26e297aE9782f41D99049fFc1051A157C9E::getEThUSDPrice([0x..])\n │ ├─ [9168] ERC1967Proxy::fallback([0x...]) [staticcall]\n │ │ ├─ [3755] PythUpgradable::getUpdateFee([0x...]) [delegatecall]\n │ │ │ └─ ← [Return] 1\n │ │ └─ ← [Return] 1\n │ ├─ [14566] ERC1967Proxy::fallback{value: 1}([0x..])\n │ │ ├─ [13652] PythUpgradable::updatePriceFeeds{value: 1}([0x..]) [delegatecall]\n │ │ │ ├─ [6255] 0x41c9e39574F40Ad34c79f1C99B66A45eFB830d4c::parseAndVerifyVM(0x..) [staticcall]\n │ │ │ │ ├─ [854] 0x8D254a21b3C86D32F7179855531CE99164721933::parseAndVerifyVM(0x..) [delegatecall]\n │ │ │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ └─ ← [Revert] custom error 0x6ce2251a\n └─ ← [Revert] custom error 0x6ce2251a\n\n 5\n\n 4\n\n post by Aditya520 on Apr 15, 2025\n\n Aditya520\n\n Hey @LuoYingjie\nCongratulations on your first post. Thank you for sharing the code and the logs.\nI see you are generating the parsed data here.\n priceUpdate[\n 0\n ] = \"0x...\";\n\nPlease use the data from hermes using the methods listed in How to Fetch Price Updates\nWhen anyone passes price updates, the contract checks it for the verification as shown in the full logs.\n │ │ │ ├─ [6255] 0x41c9e39574F40Ad34c79f1C99B66A45eFB830d4c::parseAndVerifyVM(0x..) [staticcall]\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n YES, I’m taking the data from the docs with this command below:\ncurl -X 'GET' 'https://hermes.pyth.network/v2/updates/price/latest?ids%5B%5D=0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace'\n\nHowever, it still reverts..\nThe data looks like this:\nimage975×773 46.8 KB\n0x504e41550100000003b80100000004....\n\nBut, not working.\n\n post by Aditya520 on Apr 15, 2025\n\n Aditya520\n\n The data looks correct, but can you run your script with your data here.\n priceUpdate[\n 0\n ] = \"0x...\";\n\nJust making sure that you are inserting data here before proceeding ahead.\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n That’s exactly what I do, I have inserted data there but not working.\nimage2553×1195 337 KB\n\n post by Aditya520 on Apr 16, 2025\n\n Aditya520\n\n Can you share your contract and the script in a gist? I will run it locally and get back to you.\n\n post by LuoYingjie on Apr 16, 2025\n\n LuoYingjie\n\n Surely yes, here is the link:\n\nOnly one contract there and the script is: GetETHUSDPrice.s.sol\nYou can get the priceUpdate by running\nmake get-price-update\n\nAnd the for getting the price feed you need to first deploy the contract and send a bit eth to the contract, then run\nmake get-eth-usd-price\n\nYou could also run the script in your preferred way. Thanks a lot for checking this!\n\n post by Aditya520 on Apr 17, 2025\n\n Aditya520\n\n Have you deployed the contract on any testnet and tried interacting with it?\nIt looks like forge scripts somehow creates a fork in the backend for these operations and create a transaction object for you to send it.\nRefer to this post.\n\n post by LuoYingjie on Apr 17, 2025\n\n LuoYingjie\n\n Ohhhhh god it worked!\nI just deployed a new one and the transaction succeed!\n\nThanks a lot bro for checking!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 643\n\n Jul 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 719\n\n Apr 2025\n\n Powered by Discourse","tokens":2174,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265567931,"hash":"ab48ea122b98b258a837c1e52c23ef3a7f736a18"}
{"url":"https://support.io.net/en/support/solutions/articles/156000309698-io-best-practices-security-tips","domain":"support.io.net","title":"IO Best Practices & Security Tips :","text":"IO Best Practices & Security Tips\n\n SummaryThis article covers the essential best practices and security guidelines for participating in co-staking on io.net. Following these recommendations can help you protect your assets, avoid scams, and maximize staking rewards.1️⃣ Use Official Channels OnlyTo protect your assets and ensure you're interacting with the legitimate io.net platform:Always access io.net through the official website.Type the URL manually or use a bookmark to avoid phishing attempts.Never rely on links from third-party websites, social media, or emails unless verified.Phishing sites often imitate real platforms. Double-check the URL before entering sensitive information.\n2️⃣ Verify Smart Contract AddressesWhen staking or unstaking, you’re interacting directly with smart contracts. To stay safe:Confirm smart contract addresses through io.net’s official documentation.Use a blockchain explorer (e.g., Solscan) to verify the contract address before approving any transaction.Be cautious of apps or extensions that prompt you to sign transactions without clear context.3️⃣ Avoid Unsolicited Offers and MessagesScammers often impersonate team members on social platforms. Remember:The io.net team will never send you a direct message with staking offers or ask for transfers.Ignore any \"exclusive\" deals or offers sent via social media or messaging platforms.All legitimate staking activity happens through the official platform.4️⃣ Secure Your WalletA secure crypto wallet is your first line of defense. Best practices include:Use a reputable, trusted wallet with strong community reviews.Enable all security features (e.g., password protection, biometric login, two-factor authentication).Keep your recovery phrase and private keys offline and private.Never share your keys or seed phrase—not even with io.net support.5️⃣ Choose Co-Staking Offers WiselyEvaluate co-staking offers carefully to reduce risk and improve returns:Consider devices with high Device Reliability Scores.Balance potential rewards with the risk level of the device.Use the io.net Explorer to track real-time device performance and reliability.Avoid devices with poor uptime or signs of instability—they may result in slashing or loss of rewards.6️⃣ Monitor Your Co-Staking PositionsStay informed about the status of your staked devices:Use the Staking Dashboard on the Explorer to track device status and rewards.Enable notifications or set manual reminders to review your stake periodically.Active monitoring helps you react quickly to issues and maintain earning potential.7️⃣ Plan Ahead for Unstaking DelaysUnstaking isn’t instant—there are built-in delays for security and system stability:Plan ahead if you need access to your $IO tokens.Expect a 7-day wait after initiating an unstake, followed by a 14-day cooldown.Do note, that due to the way contracts function - it may realistically take up to 16 days.You will not earn rewards during the cooldown period.8️⃣ Stay Informed Through Official Updatesio.net is an evolving platform. To make the most of your co-staking experience:Follow official io.net channels (e.g., Twitter, Discord, website).Join community discussions for tips and insights from other stakers.Always verify updates through official sources before acting on them.9️⃣ Recognize and Avoid Phishing ScamsPhishing and impersonation scams are common in crypto communities:Be wary of messages or links that seem too good to be true.Never provide your wallet information to unofficial sources. Only contact io.net support through official channels (e.g., website ticketing system or verified Discord moderators).Report suspicious activity to help protect the community.For the latest co-staking tools and updates, visit the official io.net website and join the community on Discord or Twitter.\n\n Was this article helpful?\n\n That’s Great!\n Thank you for your feedback\n\n Sorry! We couldn't be helpful\n Thank you for your feedback\n\n Feedback sent\n We appreciate your effort and will try to fix the article\n\n 0 of 0","tokens":1007,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791265578650,"hash":"12409bb38074a1edc1800d317acf9dc2699da713"}
{"url":"https://governance.aave.com/t/arfc-revision-of-eth-btc-collateral-efficiency-on-aave/25649/3","domain":"governance.aave.com","title":"[ARFC] Revision of ETH & BTC Collateral Efficiency on Aave - Governance / General - Aave","text":"GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 16\n\n 3 / 3\n\n Sep 21\n\n Sep 21\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nThis ARFC proposes raising the LTV and liquidation threshold of the ETH and BTC collateral families on Aave V3 Ethereum Core, Arbitrum, and Base, and the collateral factors of the same assets on the Aave V4 Ethereum Main Spoke. The proposed settings follow from a calibration against historical price behavior and Chainlink price feed updates, which are dense during fast markets and span both the February 2025 and October 2025 stress events. Each threshold is sized to the 99.9th percentile of the worst excursion inside a 1 hour window, the period over which positions are cleared through sequential liquidation calls, at the reserve’s liquidation bonus.\nThe proposed changes are the following:\n\nWETH moves to 81% LTV and 84% LT on Ethereum Core, Base, and Arbitrum.\nwstETH moves to 79% LTV and 82% LT and weETH to 78% LTV and 81% LT on Ethereum Core.\nWBTC moves to 81% LTV and 85% LT on Ethereum Core and to 78% LTV and 82% LT on Arbitrum.\ncbBTC moves to 81% LTV and 85% LT on Ethereum Core and to 81% LTV and 84% LT on Base, with the Base liquidation bonus lowered to 6.00% and the Base cbBTC Stablecoins E-Mode raised to 82% LTV and 85% LT.\nOn the Aave V4 Main Spoke, the collateral factor moves to 84% for WETH, 82% for wstETH, 81% for weETH, and 85% for WBTC and cbBTC, applied as a dynamic configuration update.\n\nThe analysis supports these settings on the following grounds:\n\nETH remains materially more volatile than BTC, with two-year annualized volatility of 68.8% against 44.4% and deeper excursion tails at every window. The 1 hour p99.9 excursion is -11.85% for ETH and -5.09% for BTC on its binding leg.\nThe recommended ETH family thresholds sit inside the buffer implied by the basis at each reserve’s live bonus. WETH is set at its ceiling, and wstETH and weETH one point inside theirs.\nThe BTC settings of 82 to 85% sit deliberately deep inside the buffer implied by the basis, as margin against depth, cap, and concentration risks the price model does not capture.\nThe basis covers every realized 1 hour excursion of the two-year record up to its 99.9th percentile and relies on the measured liquidation cadence, which kept position marks seconds to minutes fresh through both stress events. The residual scenario outside the basis is a stalled oracle and liquidation pipeline coinciding with a move beyond that percentile, with the realized worst at -24.27% for ETH and -11.15% for BTC over one hour.\nLiquidation processing is measured in seconds on every market examined, the slow tail is attributed to dust debt, and the two stress events produced $0 and $0.39M of bad debt respectively, with no bad debt for the analyzed collateral.\nThe same framework applied to the Aave V4 Main Spoke, the V4 counterpart of the Ethereum Core market, supports the same moves as V3, as the same Chainlink SVR auction setup is applied for both markets, integrating a set of robust searchers.\n\nMotivation\nAave’s bluechip collateral parameters have remained relatively stable over time, even as market conditions and volatility risk profiles have changed. This creates a trade-off in which overly conservative parameters reduce how much users can borrow against their collateral. The purpose of this assessment is to determine whether current LTV and LT parameters are consistent with the observed volatility and liquidity of each collateral asset, and this ARFC proposes the parameter changes that follow from it.\nMethodology\nLiquidation window\nThe window is the period over which the tail move is measured and it is the single largest input to the resulting parameter. We measure it from liquidation behaviour in two parts. The first is the time each liquidation call spent at or below the price at which it executed, weighted by the value being processed, computed with a single code path across markets, each market joined against the feed its Aave deployment reads and against stablecoin debt, over August 2025 to August 2026.\n\nMarket\nCollateral\nLiquidations\nSeized\nWeighted median\nWeighted p95\nWeighted p99\nValue below price over 1 h\n\nEthereum Core\nETH\n7,206\n$618M\nunder 1 s\n2.0 min\n5 min\n0.00%\n\nEthereum Core\nBTC\n2,621\n$358M\nunder 1 s\n2.2 min\n5 min\n0.07%\n\nArbitrum\nETH\n5,699\n$41M\nunder 1 s\n18 s\n2 min\n0.00%\n\nArbitrum\nBTC\n1,819\n$18M\nunder 1 s\n48 s\n2 min\n0.00%\n\nBase\nETH\n7,448\n$20M\nunder 1 s\n48 s\n2 min\n0.02%\n\nBase\nBTC\n1,444\n$22M\nunder 1 s\n1.1 min\n2 min\n0.00%\n\nliquidation_window2520×990 137 KB\nSource: LlamaRisk, August 29, 2026\nWeighted by value, every market clears its economically meaningful liquidations within minutes of the price crossing, and the share of processed value that had been below its liquidation price for more than an hour is at most 0.07%. The event-count tail reaches hours only through dust positions whose bonus barely covers gas, the same tail quantified in the processing section below. The exposure that the threshold must cover is therefore the work-off of a position rather than a clearing span. A liquidation call repays at most half the outstanding debt, so a large position clears through roughly five sequential calls, each landing on a feed publication. Across both stress events on Ethereum Core the value-weighted gap between consecutive calls on the same position had a median under one minute and a p95 of 15 to 21 minutes. One hour covers the work-off of the bulk of value with margin on every market examined, and Arbitrum and Base sit inside the Core distribution on every quantile. We therefore adopt a 1 hour work-off window as the basis for both families.\nLiquidation processing\nThe window above measures how long a position stays exposed. Processing speed measures how quickly liquidators act once a feed publication makes a position liquidatable. We measured the lag between each liquidation and the most recent publication of either leg of its pair on Aave V3 Ethereum Core, Arbitrum, and Base across the two largest stress events of the observation period. Ethereum is joined against the SVR publications Aave reads where they were live, which is October 2025, and against the pre-SVR standard aggregators in February 2025.\n\nEvent\nMarket\nLiquidations\nSeized\nMedian lag\np75\np95\nVolume within 1 min\nVolume within 5 min\n\nFebruary 2 to 4, 2025\nEthereum Core\n936\n$172M\n24 s\n51 s\n10.3 min\n95%\n100%\n\nFebruary 2 to 4, 2025\nArbitrum\n1,511\n$15M\n6 s\n17 s\n57 s\n100%\n100%\n\nFebruary 2 to 4, 2025\nBase\n1,435\n$9M\n10 s\n28 s\n2.0 min\n99%\n100%\n\nOctober 10 to 12, 2025\nEthereum Core\n430\n$100M\n36 s\n72 s\n6.0 min\n63%\n100%\n\nOctober 10 to 12, 2025\nArbitrum\n346\n$17M\n1 s\n10 s\n23 s\n100%\n100%\n\nOctober 10 to 12, 2025\nBase\n392\n$6M\n2 s\n4 s\n2.8 min\n100%\n100%\n\nprocessing_lag2520×990 141 KB\nSource: LlamaRisk, August 29, 2026\nLiquidations execute at feed speed even at peak congestion. Nearly all seized volume clears within five minutes of the publication that made it profitable, so liquidator responsiveness is not the binding constraint on the parameters. Arbitrum and Base, whose feeds print on tighter deviations and whose execution gas is negligible, clear faster than Ethereum Core with no lag tail at all, so the Core benchmark is the conservative one for the markets receiving the proposed increases.\nThe latency tail consists almost entirely of dust positions. Broken down by lag behind the triggering publication on Ethereum Core across both stress windows, liquidations slower than five minutes were 11.1% of events but 0.23% of seized volume. The residual sub-hour maxima are dust positions whose bonus barely covers mainnet gas, together with positions pushed over the threshold by interest accrual between publications rather than by a fresh print.\n\nLag behind print\nEvents\nShare of events\nShare of seized USD\nMedian size\n\nunder 1 min\n967\n70.8%\n78.6%\n$21,833\n\n1 to 5 min\n248\n18.2%\n21.2%\n$16,958\n\n5 to 15 min\n112\n8.2%\n0.2%\n$993\n\nover 15 min\n39\n2.9%\n0.0%\n$341\n\nLiquidators clear economically meaningful positions at feed speed and defer only positions where the bonus barely covers gas. The processing tail therefore carries no bad debt relevance.\nFast processing does not mean a position is cleared at its first touch of the threshold. A liquidation call repays at most half of the outstanding debt, resets the health factor slightly above one, and leaves the remainder exposed to the next leg down. In the February event, 32% of liquidated users across all deployments were liquidated more than once, and these users accounted for 64% of all seized volume, with a median of 3.5 hours between a user’s first and last liquidation and a p90 of roughly 10 hours.\nfeb_2025_eth_cascade2520×1080 200 KB\noct_2025_btc_cascade2520×1080 162 KB\nSource: LlamaRisk, August 29, 2026\nBoth events cleared with negligible bad debt. February produced no recognized deficit at all, and October produced $0.39M against roughly $128M, without affecting the ETH- and BTC-family collateral across all deployments. The liquidation machinery has held through both stress events at current parameters.\nLiquidation bonus\nThe liquidation bonus is an input to the derivation. The threshold has to cover the tail move and the bonus paid to the liquidator, so a higher bonus mechanically supports a lower threshold at the same level of risk. Each reserve is therefore assessed at its own live bonus rather than a single assumed value. The same asset carries different bonuses on different deployments, with WBTC at 5.00% on Ethereum and 8.50% on Polygon, and that difference moves the supportable threshold by several points due to the impact to the bad debt buffer of the protocol.\nParameter derivation\nThe model ceiling for the liquidation threshold is the largest value at which the collateral remaining after the basis move still covers the debt plus the bonus:\nLT ceiling = round((1 - |p99.9 excursion|) / (1 + LB))\n\nEach reserve is assessed at its recommended bonus where one is proposed and at its live bonus otherwise. Recommended thresholds are set relative to the ceiling: WETH at the ceiling, the rest of the ETH family one point inside it, and BTC at least three points inside it as margin against depth, cap, and concentration risks the price model does not capture.\nIn the open market every borrowable reserve is reachable from every collateral, so each collateral is assessed against every debt leg its deployment exposes and takes the lowest result.\nCalibration Results\nRealized tails and supported thresholds\nAll windows measured on the two-year deviation-threshold series, including February 2025. The 1 hour row is the basis for both families.\n\nWindow\nETH p99\nETH p99.9\nETH worst\nBTC p99\nBTC p99.9\nBTC worst\n\nsingle print\n-0.88%\n-1.66%\n-4.75%\n-0.71%\n-1.14%\n-3.44%\n\n5 min\n-1.16%\n-3.09%\n-13.31%\n-0.63%\n-2.04%\n-5.61%\n\n15 min\n-2.00%\n-6.28%\n-18.02%\n-1.19%\n-3.14%\n-8.45%\n\n30 min\n-2.88%\n-11.75%\n-22.02%\n-1.72%\n-4.06%\n-10.08%\n\n1 h (basis)\n-3.94%\n-11.85%\n-24.27%\n-2.39%\n-5.03%\n-10.72%\n\n2 h\n-5.19%\n-14.61%\n-26.24%\n-3.33%\n-6.28%\n-10.72%\n\n4 h\n-7.10%\n-24.13%\n-28.43%\n-4.69%\n-7.44%\n-11.32%\n\n6 h\n-8.63%\n-24.45%\n-29.25%\n-5.61%\n-9.55%\n-12.77%\n\n12 h\n-12.46%\n-27.25%\n-33.64%\n-6.88%\n-13.78%\n-16.38%\n\n1 d\n-16.73%\n-29.74%\n-35.06%\n-9.89%\n-17.05%\n-19.75%\n\nexcursion_tails2520×990 183 KB\nSource: LlamaRisk, August 29, 2026\nThe chart below plots the model ceiling at each work-off window across the live bonus range, with the 1 hour basis marked.\nsupported_threshold_vs_window2520×990 212 KB\nSource: LlamaRisk, August 29, 2026\nThe basis covers any 1 hour excursion up to the 99.9th percentile of the two-year record, which spans the whole of the October 2025 event and all but the core legs of February 3, 2025, and it relies on the measured liquidation cadence keeping position marks seconds to minutes fresh. The residual scenario outside the basis is a maximally levered position marked at its threshold at the start of a move beyond that percentile, with no liquidation landing for the full hour. Reaching it requires the oracle cadence and the liquidation pipeline to stall together through the worst 0.1% hour of two years, which did not happen in either stress event, where calls landed at a median of 24 seconds behind their triggering publication throughout.\nwstETH and weETH\nThe two established LSTs warrant a similar empirical treatment as the canonical wrappers. Across the two years to August 2026 they account for 6,486 liquidations and roughly $361M of seized collateral across all deployments, $296M of it wstETH and $47M weETH, overwhelmingly against stablecoin debt. Processing speed during both stress events was indistinguishable from WETH. On Ethereum Core the median lag behind the triggering publication was 12 s for LST collateral against 24 s for WETH in February 2025, and 72 s against 24 s in October 2025 on the sparser SVR publications, with lower p95 values than WETH in both events. The liquidation pipeline treats them as blue-chip collateral in practice.\nInstant exit liquidity, quoted through aggregate routing against the on-chain redemption rate, supports the same conclusion within the sizes the protocol has actually needed.\nlst_exit_liquidity2520×990 123 KB\nSource: LlamaRisk, August 29, 2026\nwstETH exits at under 0.05% discount up to roughly $24M and 0.55% at $47M, with the route exhausting beyond about $55M. weETH exits at under 0.25% up to roughly $21M and exhausts beyond about $25M. For comparison, the entire February 2025 cascade seized $39M of LST collateral on Ethereum Core spread over several hours, well inside these depths.\nOn this evidence both assets are assessed on the measured ETH basis, and their processing and depth place them in the same tier as WETH. Against live settings of 81% and 80%, we recommend raising wstETH to 82% and weETH to 81% on Ethereum, each one point inside the ceiling at its live bonus, and WETH to 84%, at its ceiling. The conservatism in weETH’s configuration sits in its 7.00% bonus against wstETH’s 6.00% despite comparable processing speed and depth proportionate to its supply.\nSpecification\nArbitrum\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nBorrowable assets\n\nWETH\n80.0%\n84.0%\n5.00%\n81%\n-\nWBTC, WETH, GHO, USDC, USD₮0\n\nWBTC\n73.0%\n78.0%\n7.00%\n78%\n82%\nWBTC, WETH, GHO, USDC, USD₮0\n\nBase\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nRecommended LB\nBorrowable assets\n\nWETH\n80.0%\n83.0%\n5.00%\n81%\n84%\n-\nWETH, cbBTC, EURC, GHO, USDC\n\ncbBTC\n73.0%\n78.0%\n7.50%\n81%\n84%\n6.00%\nWETH, cbBTC, EURC, GHO, USDC\n\nDue to robust cbBTC liquidity on Base (~$33M in stables) we also recommend lowering liquidation bonus to 6.00%.\nE-Mode\n\nAsset\nE-Mode\nCategory ID\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nBorrowable assets\n\ncbBTC\ncbBTC Stablecoins\n10\n80.0%\n83.0%\n4.00%\n82%\n85%\nGHO, USDC\n\nEthereum Core\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\n\nWETH\n80.5%\n83.0%\n5.00%\n81%\n84%\n\nWBTC\n73.0%\n78.0%\n5.00%\n81%\n85%\n\ncbBTC\n73.0%\n78.0%\n7.50%\n81%\n85%\n\nwstETH\n78.5%\n81.0%\n6.00%\n79%\n82%\n\nweETH\n77.5%\n80.0%\n7.00%\n78%\n81%\n\nLiquidation bonuses on Ethereum Core stay at their current values, including the 7.50% bonus on cbBTC, even though the depth that supports a 6.00% bonus on Base is also present on Ethereum. An increase to the liquidation protocol fee for these assets on Ethereum Core is pending. The protocol fee is taken out of the liquidation bonus, so lowering the bonus at the same time would reduce the liquidator’s net share from both sides.\nAave V4 Ethereum Main Spoke\nThe Main Spoke is the V4 counterpart of the V3 Ethereum Core market and is assessed identically, on the same basis and with each reserve at its recommended maximum liquidation bonus where one is proposed and at its live maximum otherwise, with WETH, WBTC, and cbBTC as volatile debt alongside deep stablecoins.\n\nAsset\nCurrent CF\nMax LB\nRecommended CF\nRecommended Max LB\n\nWETH\n83.0%\n5.55%\n84%\n-\n\nwstETH\n80.0%\n6.66%\n82%\n-\n\nweETH\n80.0%\n7.77%\n81%\n-\n\nWBTC\n78.0%\n5.55%\n85%\n-\n\ncbBTC\n78.0%\n5.55%\n85%\n-\n\nFor the CF changes, we recommend performing a configuration update instead of deploying a new collateral configuration.\nNext Steps\n\nGather community and service provider feedback on this ARFC.\nIf consensus is reached, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is positive, submit the changes for implementation as an AIP.\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n 2\n\n read \n\n 7\n min\n\n post by Foreshock on Sep 20\n\n Foreshock\n\n The BTC settings here are described as sitting deep inside the buffer as margin against depth, cap and concentration risks that the price model does not capture. That argument has a counterpart on the ETH family, where WETH goes to its ceiling and wstETH and weETH sit one point inside theirs.\nFor the ETH family the risks the price model does not capture include who can change the underlying contracts. For Lido the admin is a controlling contract where no single key can act alone, but its signers and any delay are not published in one place we could find. Is that control surface part of how the wstETH buffer is sized, or is it treated as out of scope for this ARFC?\n\n post by LlamaRisk on Sep 21\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n The ARFC has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 264\n\n Aug 21\n\n Independent Liquidation-Capacity Stress Tests For Aave\n\n Risk\n\n 1\n\n 217\n\n Aug 25\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [TEMP CHECK] Post-rsETH Collateral Framework: Tier-Based LTV Reductions and Wrap-Depth Ineligibility Limits\n\n Risk\n\n 17\n\n 1.3k\n\n Jul 26\n\n Post Vyper Exploit - CRV Market Update and Recommendations\n\n General\n\n 48\n\n 8.1k\n\n Aug 29","tokens":4579,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265581460,"hash":"447d385d7dd261150f2c2beb986fc6b43487a8a0"}
{"url":"https://governance.aave.com/t/independent-liquidation-capacity-stress-tests-for-aave/25503/1","domain":"governance.aave.com","title":"Independent Liquidation-Capacity Stress Tests For Aave - Risk - Aave","text":"Independent Liquidation-Capacity Stress Tests For Aave \n\n Risk\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Scope And Disclosure\n\n Summary\n\n Method\n\n Result 1: Reproducing The Linea WETH Cap Decision\n\n Result 2: Mainnet wstETH Concentration Versus Instant Depth\n\n Result 3: Mechanics Matter, But They Do Not Create Depth\n\n Primary Governance Question\n\n Limitations And Next Work\n\n Discussion And Feedback Requested\n\n Reproduction\n\n Aug 19\n\n 1 / 2\n\n Aug 19\n\n Aug 25\n\n post by GBQuant on Aug 19\n\n GBQuant\n\n Scope And Disclosure\n\nIndependent research prototype. This work is unaffiliated with Aave Labs, the Aave DAO, Chaos Labs, LlamaRisk, or any other Aave service provider. It is not a parameter recommendation, automated risk agent, or substitute for Risk Steward judgment. Its purpose is an open-source quantitative lens on Risk Steward decisions and V4 liquidation design, with assumptions and code open to challenge.\n\nUpdate, 25 August 2026: I added a follow-up on time-to-exit and liquidator economics. The extension keeps the strict instant-clearance result unchanged and tests whether the liquidation bonus compensates funding, hedging, recovery, and exit-route costs over an explicit horizon.\nRepository: BianchiGiacomo/aave-risk-engine\nMethodology: METHODOLOGY.md\nModel equations: Mathematical model specification\nThis note asks a narrow question: when stressed collateral reaches the liquidation queue, is immediate market depth sufficient to clear the relevant borrowers within the liquidation bonus?\nPrimary results are frozen at the August 18, 2026 blocks below. Earlier books used incomplete borrower discovery and are not used for current exposure claims; their quote ladders remain valid depth observations.\nSummary\n\nReproduced decision. A KyberSwap ladder puts Linea WETH’s maximum clearable size at $43,195, close to LlamaRisk’s approximately $41,000 July estimate.\nMainnet concentration. The largest wstETH borrower would, if liquidated, put a $256.52 million sale into a market whose instant routed depth clears $2.73 million within the bonus, about 94 times smaller. That is a statement about immediate on-chain exits, not about eventual recovery.\nPolicy question. Should the Aave Risk Framework’s clearance requirement be read against instant routed depth, or against a horizon-adjusted capacity that credits primary redemption and depth replenishment?\n\nMethod\nThe pipeline uses keyless Aave JSON-RPC state, routed quotes, Kraken prices, and DefiLlama LST ratios. A persistent registry replays Borrow events and re-queries every candidate at one pinned block. Accounts with at least $10,000 of debt enter the snapshot; target-share and debt-denomination filters form the USD-debt and combined books. The engine simulates returns, relative-value moves, and depth evaporation, then clears liquidations sequentially by bonus and seize size. Liquidators participate while slippage is below bonus / (1 + bonus). Versioned snapshots and manifests preserve inputs, hashes, seeds, parameters, and results.\nThe repository includes deterministic market reports, V3 and V4 liquidation mechanics, ordered queue clearing, historical episode replay, multi-period book evolution, and an interactive real-data dashboard.\nResult 1: Reproducing The Linea WETH Cap Decision\nThe first validation target was LlamaRisk’s July 2026 WETH cap reduction on Aave V3 Linea. The implemented settings verify on-chain at a 6,250 WETH supply cap and a 2,370 WETH borrow cap.\nLlamaRisk reported that WETH reached its liquidation-bonus threshold at about $41,000 of sell size. Independent KyberSwap ladders estimated $32,500 on July 18, $41,770 on July 30, and $43,195 in the August 18 release snapshot at block 31,749,322.\n\nliquidator break-even slippage : 5.66%\nlargest borrower sale : $300.47k\nmax clearable within bonus : $43.20k -> FAIL\nmax clearable, 50% haircut : $21.60k -> FAIL\n\nThe estimate agrees with LlamaRisk in magnitude. Complete discovery also finds a current sale above the threshold, so the formal clearance test supports the same risk direction as the cap reduction.\nThe Monte Carlo row shows why frequency and severity must accompany CVaR in a sparse book: six positive draws have mean severity of $82,020, while CVaR99 is $2,460 because 194 zeros enter the same worst-1% average.\nLinea case study | Run manifest\nResult 2: Mainnet wstETH Concentration Versus Instant Depth\nThe Ethereum snapshot at block 25,780,402 covers 84,427 historical borrower candidates and stores 9,526 accounts with at least $10,000 of current debt. The target-dominant USD-debt book is near the exploratory $5 million CVaR budget under the standard two-day calibration:\ndebt : $634.47m\npositive-loss draws : 110 / 20,000\nP(bad debt) : 0.550% (95% Wilson CI 0.457% to 0.662%)\nexpected loss : $47.85k\nloss severity : $8.70m conditional on positive loss\nCVaR99 : $4.78m\n\nThe combined book, which revalues $329.46 million of ETH-denominated debt, has $964.28 million of total debt, 3.64% bad-debt probability, and $31.82 million aggregate-queue CVaR99. Its deterministic concentration test, which measures instant routed capacity only, is:\nlargest borrower sale : $256.52m\nmax clearable within bonus : $2.73m -> FAIL\n\nThe sale is about 94 times instant capacity. The borrower is a leveraged staking loop with entirely ETH-denominated debt, so an ETH/USD move revalues both legs; relative wstETH/ETH value and exit depth are the relevant channels.\nThe liquidation trigger requires care. At the snapshot block Aave’s wstETH feed matches Lido’s canonical wstETH/stETH rate times ETH/USD: rounded inputs are 1.24188444, $1,898.3475, and $2,357.5282. A secondary-market stETH/ETH discount does not by itself reduce this feed or the borrower’s health factor. Because the model calibrates its relative-value factor on that market ratio, peg-driven losses are counterfactual canonical-rate impairment scenarios, not calibrated liquidation probabilities under the live oracle.\nThat channel is not hypothetical. Chaos Labs’ March 2026 post-mortem on wstETH exchange-rate misalignment reports a CAPO parameter mismatch that lowered the effective exchange rate by about 2.85% and liquidated roughly 10,938 wstETH across 34 accounts on the Core and Prime instances, the same Core instance this snapshot reads. Slashing or an adapter fault can impair the canonical rate; withdrawal-queue congestion instead affects exit time and secondary liquidity. Conditional on liquidation, the clearance test is unchanged because seized wstETH still reaches the routed market.\nFAIL is therefore a conditional instant-capacity result, not a live bad-debt estimate or a claim that wstETH is unsafe. Redemption over time and CEX or OTC liquidity may increase eventual capacity. This exposes an interpretation issue in the Aave Risk Framework: instant depth and horizon liquidation capacity are not the same quantity.\nEthereum run manifest\nResult 3: Mechanics Matter, But They Do Not Create Depth\nThe V4 comparison holds the V3 book, scenarios, and depth fixed. V4 repays to a target health factor; modeled V3 repays 50%, or 100% below HF 0.95. Main uses target HF 1.24, a 60% close-factor floor, 0.90 bonus factor, and 0.90 maximum-bonus HF; Correlated uses 1.0137, 35%, 1.0, and 0.99. Both use a maximum bonus 1.11 times V3. This is a mechanics counterfactual, not live V4 borrower data, and linear interpolation between bonus anchors is an assumption.\nOn the current combined book, aggregate CVaR99 is $31.82 million for V3, $32.85 million for V4 Main, and $32.83 million for V4 Correlated. Ordered clearing reduces those values to $15.25 million, $26.87 million, and $22.41 million respectively. Early transactions can clear before later sales consume depth, so queue execution is material. No mechanics choice, however, makes a $256.52 million sale fit inside $2.73 million of instant capacity.\nMatched four-day paths also separate terminal stress from evolving liquidation. Combined-book V3 CVaR99 is $32.78 million under a terminal-only shock and $31.85 million with book evolution. V4 Main moves from $51.08 million to $47.84 million; V4 Correlated moves from $40.76 million to $39.68 million. Re-liquidation occurs in 0.21% of V4 Main paths versus 16.84% of V4 Correlated paths. The higher repay target contributes to that contrast, but bonus and floor parameters also differ, so it is not a single-parameter causal estimate.\nApplying the June 2022 ETH and stETH/ETH path to today’s combined book produces a $42.20 million worst window. Because the historical loss driver was a market discount, the oracle-consistent reading is a counterfactual canonical-rate impairment of the same magnitude. This replays market paths on today’s positions; it does not reconstruct the historical book.\nPrimary Governance Question\n\nShould the largest-borrower clearance requirement use instant routed liquidity for redeemable collateral, or should it specify a time horizon and recognize primary redemption capacity?\n\nA strict instant test is auditable but can understate eventual capacity. A horizon-adjusted test is economically richer but requires explicit assumptions for redemption throughput, delay, depth replenishment, and market conditions. The framework would be clearer if it specified which interpretation governs.\nLimitations And Next Work\nThe single-asset mapping applies the target shock to all collateral in selected accounts while retaining each weighted liquidation threshold. Empirical depth is a lower bound beyond the final quote. Episode replay is not archive backtesting, and plain Monte Carlo is inefficient for rare losses. Most importantly, secondary-market peg calibration does not estimate canonical-rate impairment probabilities under the current wstETH oracle.\nThe follow-up below implements time-to-exit and liquidator economics as explicit sensitivities. Remaining work is to calibrate stressed redemption throughput and DEX refill, implement rare-event sampling with uncertainty diagnostics, and develop a direct canonical-rate model. V4 Hub premium pricing remains later work; no premium recommendation is made here.\nDiscussion And Feedback Requested\nFeedback from Risk Stewards and service providers would be useful on:\n\nIs bonus-priority ordered clearing a reasonable first approximation to competitive liquidator execution?\nWhich V4 dynamic-bonus function should replace linear interpolation between the documented anchors?\nFor exchange-rate-oracled collateral, is a canonical-rate impairment scenario the right way to stress the correlated-asset channel, and what magnitude would be considered plausible?\n\nReproduction\ngit clone https://github.com/BianchiGiacomo/aave-risk-engine\ncd aave-risk-engine\npip install -e \".[dev]\"\n\npython -m aave_risk_engine.run_market_report --snapshot data/snapshots/aave_v3_ethereum_wsteth.json --manifest docs/manifests/ethereum-wsteth-2026-08-18.json\npython -m aave_risk_engine.run_market_report --snapshot data/snapshots/aave_v3_linea_weth.json --budget 500000 --figure --manifest docs/manifests/linea-weth-2026-08-18.json\npython -m aave_risk_engine.run_episode_replay\npython -m aave_risk_engine.run_v4_comparison\npython -m aave_risk_engine.run_multiperiod\npython -m streamlit run dashboard.py\n\nThe dashboard is an optional inspection layer; versioned CLI manifests remain the canonical evidence.\n\n Mainnet wstETH Liquidation Assessment: Financing Remains Unverified\n\n [ARFC] Onboard HINC (Neuberger Securitize High Income Tokenized Fund) to Aave Horizon\n\n read \n\n 5\n min\n\n post by GBQuant on Aug 25\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 259\n\n Sep 21\n\n Mainnet wstETH Liquidation Assessment: Financing Remains Unverified\n\n Assessments\n\n 0\n\n 79\n\n Sep 15\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 264\n\n Aug 21\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d","tokens":3025,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265592842,"hash":"71d90c406fdb4abb46a7138061f56770fd2efcae"}
{"url":"https://docs.base.org/specifications/reference/glossary","domain":"docs.base.org","title":"Glossary - Base Documentation","text":"​General Terms\n​Layer 1 (L1)\nRefers the Ethereum blockchain, used in contrast to layer 2, which refers to Base.\n​Layer 2 (L2)\nRefers to Base Chain (specified in this repository), used in contrast to layer 1, which\nrefers to the Ethereum blockchain.\n​Block\nCan refer to an L1 block, or to an L2 block, which are structured similarly.\nA block is a sequential list of transactions, along with a couple of properties stored in the header of the block. A\ndescription of these properties can be found in code comments here, or in the Ethereum yellow paper\n(pdf), section 4.3.\nIt is useful to distinguish between input block properties, which are known before executing the transactions in the\nblock, and output block properties, which are derived after executing the block’s transactions. These include various\nMerkle Patricia Trie roots that notably commit to the L2 state and to the log events emitted during execution.\n​EOA\n“Externally Owned Account”, an Ethereum term to designate addresses operated by users, as opposed to contract addresses.\n​Merkle Patricia Trie\nA Merkle Patricia Trie (MPT) is a sparse trie, which is a tree-like structure that maps keys to values.\nThe root hash of a MPT is a commitment to the contents of the tree, which allows a\nproof to be constructed for any key-value mapping encoded in the tree. Such a proof is called a Merkle proof, and can be\nverified against the Merkle root.\n​Chain Re-Organization\nA re-organization, or re-org for short, is whenever the head of a blockchain (its last block) changes (as dictated by\nthe fork choice rule) to a block that is not a child of the previous head.\nL1 re-orgs can happen because of network conditions or attacks. L2 re-orgs are a consequence of L1 re-orgs, mediated via\nL2 chain derivation.\n​Predeployed Contract (“Predeploy”)\nA contract placed in the L2 genesis state (i.e. at the start of the chain).\nAll predeploy contracts are specified in the predeploys specification.\n​Preinstalled Contract (“Preinstall”)\nA contract placed in the L2 genesis state (i.e. at the start of the chain). These contracts do not share the same\nsecurity guarantees as predeploys, but are general use contracts made\navailable to improve the L2’s UX.\nAll preinstall contracts are specified in the preinstalls specification.\n​Precompiled Contract (“Precompile”)\nA contract implemented natively in the EVM that performs a specific operation more efficiently than a bytecode\n(e.g. Solidity) implementation. Precompiles exist at predefined addresses. They are created and modified through\nnetwork upgrades.\nAll precompile contracts are specified in the precompiles specification.\n​Receipt\nA receipt is an output generated by a transaction, comprising a status code, the amount of gas used, a list of log\nentries, and a bloom filter indexing these entries. Log entries are most notably used to encode Solidity events.\nReceipts are not stored in blocks, but blocks store a Merkle Patricia Trie root for a tree containing the receipt\nfor every transaction in the block.\nReceipts are specified in the yellow paper (pdf) section 4.3.1.\n​Transaction Type\nEthereum provides a mechanism (as described in EIP-2718) for defining different transaction types.\nDifferent transaction types can contain different payloads, and be handled differently by the protocol.\n​Fork Choice Rule\nThe fork choice rule is the rule used to determine which block is to be considered as the head of a blockchain. On L1,\nthis is determined by the proof of stake rules.\nL2 also has a fork choice rule, although the rules vary depending on whether we want the safe L2 head,\nthe unsafe L2 head or the finalized L2 head.\n​Priority Gas Auction\nTransactions in ethereum are ordered by the price that the transaction pays to the miner. Priority Gas Auctions\n(PGAs) occur when multiple parties are competing to be the first transaction in a block. Each party continuously\nupdates the gas price of their transaction. PGAs occur when there is value in submitting a transaction before other\nparties (like being the first deposit or submitting a deposit before there is not more guaranteed gas remaining).\nPGAs tend to have negative externalities on the network due to a large amount of transactions being submitted in a\nvery short amount of time.\n​Sequencing\nTransactions in the rollup can be included in two ways:\n\nThrough a deposited transaction, enforced by the system\nThrough a regular transaction, embedded in a sequencer batch\n\nSubmitting transactions for inclusion in a batch saves costs by reducing overhead, and enables the sequencer to\npre-confirm the transactions before the L1 confirms the data.\n​Sequencer\nA sequencer is either a rollup node ran in sequencer mode, or the operator of this rollup node.\nThe sequencer is a privileged actor, which receives L2 transactions from L2 users, creates L2 blocks using them, which\nit then submits to data availability provider (via a batcher). It also submits output\nroots to L1.\n​Sequencing Window\nA sequencing window is a range of L1 blocks from which a sequencing epoch can be derived.\nA sequencing window whose first L1 block has number N contains batcher transactions for epoch\nN. The window contains blocks [N, N + SWS) where SWS is the sequencer window size.\nThe current default sws is 3600 epochs.\nAdditionally, the first block in the window defines the depositing transactions which determine the\ndeposits to be included in the first L2 block of the epoch.\n​Sequencing Epoch\nA sequencing epoch is sequential range of L2 blocks derived from a sequencing window of L1 blocks.\nEach epoch is identified by an epoch number, which is equal to the block number of the first L1 block in the\nsequencing window.\nEpochs can have variable size, subject to some constraints. See the L2 chain derivation specification\nfor more details.\n​L1 Origin\nThe L1 origin of an L2 block is the L1 block corresponding to its sequencing epoch.\n​Deposits\nIn general, a deposit is an L2 transaction derived from an L1 block (by the rollup driver).\nWhile transaction deposits are notably (but not only) used to “deposit” (bridge) ETH and tokens to L2, the word\ndeposit should be understood as “a transaction deposited to L2 from L1”.\nThis term deposit is somewhat ambiguous as these “transactions” exist at multiple levels. This section disambiguates\nall deposit-related terms.\nNotably, a deposit can refer to:\n\nA deposited transaction (on L2) that is part of a deposit block.\nA depositing call that causes a deposited transaction to be derived.\nThe event/log data generated by the depositing call, which is what the rollup driver reads to\nderive the deposited transaction.\n\nWe sometimes also talk about user deposit which is a similar term that explicitly excludes L1 attributes deposited\ntransactions.\nDeposits are specified in the deposits specification.\n​Deposited Transaction\nA deposited transaction is a L2 transaction that was derived from L1 and included in a L2 block.\nThere are two kinds of deposited transactions:\n\nL1 attributes deposited transaction, which submits the L1 block’s attributes to the L1 Attributes\nPredeployed Contract.\nUser-deposited transactions, which are transactions derived from an L1 call to the deposit\ncontract.\n\n​L1 Attributes Deposited Transaction\nAn L1 attributes deposited transaction is deposited transaction that is used to register the L1 block\nattributes (number, timestamp, …) on L2 via a call to the L1 Attributes Predeployed Contract.\nThat contract can then be used to read the attributes of the L1 block corresponding to the current L2 block.\nL1 attributes deposited transactions are specified in the L1 Attributes Deposit section of the\ndeposits specification.\n​User-Deposited Transaction\nA user-deposited transaction is a deposited transaction which is derived from an L1 call to the deposit\ncontract (a depositing call).\nUser-deposited transactions are specified in the Transaction Deposits section of the deposits\nspecification.\n​Depositing Call\nA depositing call is an L1 call to the deposit contract, which will be derived to a\nuser-deposited transaction by the rollup driver.\nThis call specifies all the data (destination, value, calldata, …) for the deposited transaction.\n​Depositing Transaction\nA depositing transaction is an L1 transaction that makes one or more depositing calls.\n​Depositor\nThe depositor is the L1 account (contract or EOA) that makes (is the msg.sender of) the depositing\ncall. The depositor is NOT the originator of the depositing transaction (i.e. tx.origin).\n​Deposited Transaction Type\nThe deposited transaction type is an EIP-2718 transaction type, which specifies the input fields\nand correct handling of a deposited transaction.\nSee the corresponding section of the deposits spec for more information.\n​Deposit Contract\nThe deposit contract is an L1 contract to which EOAs and contracts may send deposits. The deposits are\nemitted as log records (in Solidity, these are called events) for consumption by rollup nodes.\nAdvanced note: the deposits are not stored in calldata because they can be sent by contracts, in which case the calldata\nis part of the internal execution between contracts, and this intermediate calldata is not captured in one of the\nMerkle Patricia Trie roots included in the L1 block.\ncf. Deposits Specification\n​Withdrawals\nIn general, a withdrawal is a transaction sent from L2 to L1 that may transfer data and/or value.\nThe term withdrawal is somewhat ambiguous as these “transactions” exist at multiple levels. In order to differentiate\nbetween the L1 and L2 components of a withdrawal we introduce the following terms:\n\nA withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.\nA withdrawal finalizing transaction refers specifically to an L1 transaction which finalizes and relays the\nwithdrawal.\n\n​Relayer\nAn EOA on L1 which finalizes a withdrawal by submitting the data necessary to verify its inclusion on L2.\n​Finalization Period\nThe finalization period — sometimes also called withdrawal delay — is the minimum amount of time (in seconds) that\nmust elapse before a withdrawal can be finalized.\nThe finalization period is necessary to afford sufficient time for validators to make a fault\nproof.\n​Configuration\n​Batch Inbox\nThe Batch Inbox is the address that Sequencer transaction batches are published to. Sequencers\npublish transactions to the Batch Inbox by setting it as the to address on a transaction\ncontaining batched L2 transactions either in calldata or as blobdata.\n​Batcher Hash\nThe Batcher Hash identifies the sender(s) whose transactions to the Batch Inbox\nwill be recognized by the L2 clients for a given Base chain.\nThe Batcher Hash is versioned by the first byte of the hash. The structure of the V0 Batcher Hash\nis a 32 byte hash defined as follows:\n1 byte11 bytes20 bytesversion (0x00)emptyaddress\nThis can also be understood as:\nBatcher Hashbytes32(address(batcher))\n\nWhere batcher is the address of the account that sends transactions to the Batch Inbox. Put\nsimply, the V0 hash identifies a single address whose transaction batches will be recognized by\nL2 clients. This hash is versioned so that it could, for instance, be repurposed to be a commitment\nto a list of permitted accounts or some other form of batcher identification.\n​Fee Scalars\nThe Fee Scalars are parameters used to calculate the L1 data fee for L2 transactions. These\nparameters are also known as Gas Price Oracle (GPO) parameters.\n​Pre-Ecotone Parameters\nBefore the Ecotone upgrade, these include:\n\nScalar: A multiplier applied to the L1 base fee, interpreted as a big-endian uint256\nOverhead: A constant gas overhead, interpreted as a big-endian uint256\n\n​Post-Ecotone Parameters\nAfter the Ecotone upgrade:\n\nThe Scalar attribute encodes additional scalar information in a versioned encoding scheme\nThe Overhead value is ignored and does not affect the L2 state-transition output\n\n​Post-Ecotone Scalar Encoding\nThe Scalar is encoded as big-endian uint256, interpreted as bytes32, and composed as follows:\n\nByte 0: scalar-version byte\nBytes [1, 32): depending on scalar-version:\n\nScalar-version 0:\n\nBytes [1, 28): padding, should be zero\nBytes [28, 32): big-endian uint32, encoding the L1-fee baseFeeScalar\nThis version implies the L1-fee blobBaseFeeScalar is set to 0\nIf there are non-zero bytes in the padding area, baseFeeScalar must be set to MaxUint32\n\nScalar-version 1:\n\nBytes [1, 24): padding, must be zero\nBytes [24, 28): big-endian uint32, encoding the blobBaseFeeScalar\nBytes [28, 32): big-endian uint32, encoding the baseFeeScalar\n\nThe baseFeeScalar corresponds to the share of the user-transaction (per byte) in the total\nregular L1 EVM gas usage consumed by the data-transaction of the batch-submitter. For blob\ntransactions, this is the fixed intrinsic gas cost of the L1 transaction.\nThe blobBaseFeeScalar corresponds to the share of a user-transaction (per byte) in the total\nblobdata that is introduced by the data-transaction of the batch-submitter.\n​Unsafe Block Signer\nThe Unsafe Block Signer is an Ethereum address whose corresponding private key is used to sign\n“unsafe” blocks before they are published to L1. This signature allows nodes in the P2P network to\nrecognize these blocks as the canonical unsafe blocks, preventing denial of service attacks on the\nP2P layer.\nTo ensure that its value can be fetched with a storage proof in a storage layout independent\nmanner, it is stored at a special storage slot corresponding to\nkeccak256(\"systemconfig.unsafeblocksigner\").\nUnlike other system config parameters, the Unsafe Block Signer only operates on blockchain policy\nand is not a consensus level parameter.\n​L2 Gas Limit\nThe L2 Gas Limit defines the maximum amount of gas that can be used in a single L2 block.\nThis parameter ensures that L2 blocks remain of reasonable size to be processed and proven.\nChanges to the L2 gas limit are fully applied in the first L2 block with the L1 origin that\nintroduced the change.\nThe gas limit may not be set to a value larger than the\nmaximum gas limit. This is to ensure that L2 blocks are provable and can be processed by consensus and execution software.\n​Batch Submission\n​Data Availability\nData availability is the guarantee that some data will be “available” (i.e. retrievable) during a reasonably long time\nwindow. In Base’s case, the data in question are sequencer batches that validators\nneed in order to verify the sequencer’s work and validate the L2 chain.\nThe finalization period should be taken as the lower bound on the availability window, since\nthat is when data availability is the most crucial, as it is needed to perform a fault proof.\n“Availability” does not mean guaranteed long-term storage of the data.\n​Data Availability Provider\nA data availability provider is a service that can be used to make data available. See the Data\nAvailability for more information on what this means.\nIdeally, a good data availability provider provides strong verifiable guarantees of data availability\nAt present, the supported data availability providers include Ethereum call data and blob data.\n​Sequencer Batch\nA sequencer batch is list of L2 transactions (that were submitted to a sequencer) tagged with an epoch\nnumber and an L2 block timestamp (which can trivially be converted to a block number, given our\nblock time is constant).\nSequencer batches are part of the L2 derivation inputs. Each batch represents the inputs needed to build\none L2 block (given the existing L2 chain state) — except for the first block of each epoch, which also needs\ninformation about deposits (cf. the section on L2 derivation inputs).\n​Channel\nA channel is a sequence of sequencer batches (for sequential blocks) compressed together. The reason\nto group multiple batches together is simply to obtain a better compression rate, hence reducing data availability\ncosts.\nA channel can be split in frames in order to be transmitted via batcher\ntransactions. The reason to split a channel into frames is that a channel might be too large to\ninclude in a single batcher transaction.\nA channel is uniquely identified by its timestamp (UNIX time at which the channel was created) and a random value. See\nthe Frame Format section of the L2 Chain Derivation specification for more information.\nOn the side of the rollup node (which is the consumer of channels), a channel is considered to be\nopened if its final frame (explicitly marked as such) has not been read, or closed otherwise.\n​Channel Frame\nA channel frame is a chunk of data belonging to a channel. Batcher transactions carry one or\nmultiple frames. The reason to split a channel into frames is that a channel might too large to include in a single\nbatcher transaction.\n​Batcher\nA batcher is a software component (independent program) that is responsible to make channels available on a data\navailability provider. The batcher communicates with the rollup node in order to retrieve the channels. The channels are\nthen made available using batcher transactions.\n​Batcher Transaction\nA batcher transaction is a transaction submitted by a batcher to a data availability provider, in order to make\nchannels available. These transactions carry one or more full frames, which may belong to different channels. A\nchannel’s frames may be split between multiple batcher transactions.\nWhen submitted to Ethereum calldata, the batcher transaction’s receiver must be the sequencer inbox address. The\ntransaction must also be signed by a recognized batch submitter account. The recognized batch submitter account\nis stored in the System Configuration.\n​Batch Submission Frequency\nWithin the sequencing-window constraints the batcher is permitted by the protocol to submit L2 blocks for\ndata-availability at any time. The batcher software allows for dynamic policy configuration by its operator.\nThe rollup enforces safety guarantees and liveness through the sequencing window, if the batcher does not submit\ndata within this allotted time.\nBy submitting new L2 data in smaller more frequent steps, there is less delay in confirmation of the L2 block\ninputs. This allows verifiers to ensure safety of L2 blocks sooner. This also reduces the time to finality of\nthe data on L1, and thus the time to L2 input-finality.\nBy submitting new L2 data in larger less frequent steps, there is more time to aggregate more L2 data, and\nthus reduce fixed overhead of the batch-submission work. This can reduce batch-submission costs, especially\nfor lower throughput chains that do not fill data-transactions (typically 128 KB of calldata, or 800 KB\nof blobdata) as quickly.\n​Channel Timeout\nThe channel timeout is a duration (in L1 blocks) during which channel frames may land on L1 within\nbatcher transactions.\nThe acceptable time range for the frames of a channel is [channel_id.timestamp, channel_id.timestamp + CHANNEL_TIMEOUT]. The acceptable L1 block range for these frames are any L1 block whose timestamp falls inside this\ntime range. (Note that channel_id.timestamp must be lower than the L1 block timestamp of any L1 block in which frames\nof the channel are seen, or else these frames are ignored.)\nThe purpose of channel timeouts is dual:\n\nAvoid keeping old unclosed channel data around forever (an unclosed channel is a channel whose final frame was not\nsent).\nBound the number of L1 blocks we have to look back in order to decode sequencer batches from\nchannels. This is particularly relevant during L1 re-orgs, see the Resetting Channel Buffering\nsection of the L2 Chain Derivation specification for more information.\n\n​L2 Output Root Proposals\n​Proposer\nThe proposer’s role is to construct and submit output roots, which are commitments to the L2’s state, to the\nL2OutputOracle contract on L1 (the settlement layer). To do this, the proposer periodically queries the rollup node for\nthe latest output root derived from the latest finalized L1 block. It then takes the output root and submits it to the\nL2OutputOracle contract on the settlement layer (L1).\n​L2 Chain Derivation\nL2 chain derivation is a process that reads L2 derivation inputs from L1 in order to derive the L2\nchain.\nSee the L2 chain derivation specification for more details.\n​L2 Derivation Inputs\nThis term refers to data that is found in L1 blocks and is read by the rollup node to construct payload\nattributes.\nL2 derivation inputs include:\n\nL1 block attributes\n\nblock number\ntimestamp\nbasefee\nblob base fee\n\ndeposits (as log data)\nsequencer batches (as transaction data)\nSystem configuration updates (as log data)\n\n​System Configuration\nThis term refers to the collection of dynamically configurable rollup parameters maintained\nby the SystemConfig contract on L1 and read by the L2 derivation process.\nThese parameters enable keys to be rotated regularly and external cost parameters to be adjusted\nwithout the network upgrade overhead of a hardfork.\nSee the System Configuration section for a full overview.\n​Payload Attributes\nThis term refers to an object that can be derived from L2 chain derivation inputs found on L1, which are\nthen passed to the execution engine to construct L2 blocks.\nThe payload attributes object essentially encodes a block without output properties.\nPayload attributes are originally specified in the Ethereum Engine API specification, which we expand in\nthe Execution Engine Specification.\nSee also the Building The Payload Attributes section of the rollup node specification.\n​L2 Genesis Block\nThe L2 genesis block is the first block of the L2 chain in its current version.\nThe state of the L2 genesis block comprises:\n\nState inherited from the previous version of the L2 chain.\n\nThis state was possibly modified by “state surgeries”. For instance, the migration to Bedrock entailed changes on\nhow native ETH balances were stored in the storage trie.\n\nPredeployed contracts\n\nThe timestamp of the L2 genesis block must be a multiple of the block time (i.e. a even number, since the\nblock time is 2 seconds).\nWhen updating the rollup protocol to a new version, we may perform a squash fork, a process that entails the creation\nof a new L2 genesis block. This new L2 genesis block will have block number X + 1, where X is the block number of\nthe final L2 block before the update.\nA squash fork is not to be confused with a re-genesis, a similar process that we employed in the past, which also\nresets L2 block numbers, such that the new L2 genesis block has number 0. We will not employ re-genesis in the future.\nSquash forks are superior to re-geneses because they avoid duplicating L2 block numbers, which breaks a lot of external\ntools.\n​L2 Chain Inception\nThe L1 block number at which the output roots for the genesis block were proposed on the output\noracle contract.\nIn the current implementation, this is the L1 block number at which the output oracle contract was deployed or upgraded.\n​Safe L2 Block\nA safe L2 block is an L2 block that can be derived entirely from L1 by a rollup node. This can vary\nbetween different nodes, based on their view of the L1 chain.\n​Safe L2 Head\nThe safe L2 head is the highest safe L2 block that a rollup node knows about.\n​Unsafe L2 Block\nAn unsafe L2 block is an L2 block that a rollup node knows about, but which was not derived from the L1\nchain. In sequencer mode, this will be a block sequenced by the sequencer itself. In validator mode, this will be a\nblock acquired from the sequencer via unsafe sync.\n​Unsafe L2 Head\nThe unsafe L2 head is the highest unsafe L2 block that a rollup node knows about.\n​Unsafe Block Consolidation\nUnsafe block consolidation is the process through which the rollup node attempts to move the safe L2\nhead a block forward, so that the oldest unsafe L2 block becomes the new safe L2 head.\nIn order to perform consolidation, the node verifies that the payload attributes derived from the L1\nchain match the oldest unsafe L2 block exactly.\nSee the Engine Queue section of the L2 chain derivation spec for more information.\n​Finalized L2 Head\nThe finalized L2 head is the highest L2 block that can be derived from finalized L1 blocks — i.e. L1\nblocks older than two L1 epochs (64 L1 time slots).\n​Other L2 Chain Concepts\n​Address Aliasing\nWhen a contract submits a deposit from L1 to L2, its address (as returned by ORIGIN and CALLER) will be\naliased with a modified representation of the address of a contract.\n\ncf. Deposit Specification\n\n​Rollup Node\nThe rollup node is responsible for deriving the L2 chain from the L1 chain (L1 blocks and their\nassociated receipts).\nThe rollup node can run either in validator or sequencer mode.\nIn sequencer mode, the rollup node receives L2 transactions from users, which it uses to create L2 blocks. These are\nthen submitted to a data availability provider via batch submission. The L2 chain\nderivation then acts as a sanity check and a way to detect L1 chain re-orgs.\nIn validator mode, the rollup node performs derivation as indicated above, but is also able to “run ahead” of the L1\nchain by getting blocks directly from the sequencer, in which case derivation serves to validate the sequencer’s\nbehavior.\nA rollup node running in validator mode is sometimes called a replica.\nSee the rollup node specification for more information.\n​Rollup Driver\nThe rollup driver is the rollup node component responsible for deriving the L2 chain\nfrom the L1 chain (L1 blocks and their associated receipts).\n​L1 Attributes Predeployed Contract\nA predeployed contract on L2 that can be used to retrieve the L1 block attributes of L1 blocks with a given\nblock number or a given block hash.\ncf. L1 Attributes Predeployed Contract Specification\n​L2 Output Root\nA 32 byte value which serves as a commitment to the current state of the L2 chain.\n​L2 Output Oracle Contract\nAn L1 contract to which L2 output roots are posted by the sequencer.\n​Validator\nA validator is an entity (individual or organization) that runs a rollup node in validator mode.\nDoing so grants a lot of benefits similar to running an Ethereum node, such as the ability to simulate L2 transactions\nlocally, without rate limiting.\nIt also lets the validator verify the work of the sequencer, by re-deriving output roots and comparing\nthem against those submitted by the sequencer. In case of a mismatch, the validator can perform a fault\nproof.\n​Fault Proof\nAn on-chain interactive proof, performed by validators, that demonstrates that a sequencer provided\nerroneous output roots.\n​Time Slot\nOn L2, there is a block every 2 second (this duration is known as the block time).\nWe say that there is a “time slot” every multiple of 2s after the timestamp of the L2 genesis block.\nOn L1, post-merge, the time slots are every 12s. However, an L1 block may not be produced for every time slot, in case\nof even benign consensus issues.\n​Block Time\nThe L2 block time is 2 second, meaning there is an L2 block at every 2s time slot.\nPost-merge, it could be said that the L1 block time is 12s as that is the L1 time slot. However, in\nreality the block time is variable as some time slots might be skipped.\nPre-merge, the L1 block time is variable, though it is on average 13s.\n​Unsafe Sync\nUnsafe sync is the process through which a validator learns about unsafe L2 blocks from\nthe sequencer.\nThese unsafe blocks will later need to be confirmed by the L1 chain (via unsafe block consolidation).\n​Execution Engine Concepts\n​Execution Engine\nThe execution engine is responsible for executing transactions in blocks and computing the resulting state roots,\nreceipts roots and block hash.\nBoth L1 (post-merge) and L2 have an execution engine.\nOn L1, the executed blocks can come from L1 block synchronization; or from a block freshly minted by the execution\nengine (using transactions from the L1 mempool), at the request of the L1 consensus layer.\nOn L2, the executed blocks are freshly minted by the execution engine at the request of the rollup node,\nusing transactions derived from L1 blocks.\nIn these specifications, “execution engine” always refer to the L2 execution engine, unless otherwise specified.\n\ncf. Execution Engine Specification\nWas this page helpful?Suggest editsRaise issue","tokens":7011,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265607975,"hash":"0dabdccb6dd1d1734cde212f77ff49b61782ef8c"}
{"url":"https://governance.aave.com/t/independent-liquidation-capacity-stress-tests-for-aave/25503/2","domain":"governance.aave.com","title":"Independent Liquidation-Capacity Stress Tests For Aave - Risk - Aave","text":"Risk\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 19\n\n 2 / 2\n\n Aug 25\n\n Aug 25\n\n post by GBQuant on Aug 19\n\n GBQuant\n\n Scope And Disclosure\n\nIndependent research prototype. This work is unaffiliated with Aave Labs, the Aave DAO, Chaos Labs, LlamaRisk, or any other Aave service provider. It is not a parameter recommendation, automated risk agent, or substitute for Risk Steward judgment. Its purpose is an open-source quantitative lens on Risk Steward decisions and V4 liquidation design, with assumptions and code open to challenge.\n\nUpdate, 25 August 2026: I added a follow-up on time-to-exit and liquidator economics. The extension keeps the strict instant-clearance result unchanged and tests whether the liquidation bonus compensates funding, hedging, recovery, and exit-route costs over an explicit horizon.\nRepository: BianchiGiacomo/aave-risk-engine\nMethodology: METHODOLOGY.md\nModel equations: Mathematical model specification\nThis note asks a narrow question: when stressed collateral reaches the liquidation queue, is immediate market depth sufficient to clear the relevant borrowers within the liquidation bonus?\nPrimary results are frozen at the August 18, 2026 blocks below. Earlier books used incomplete borrower discovery and are not used for current exposure claims; their quote ladders remain valid depth observations.\nSummary\n\nReproduced decision. A KyberSwap ladder puts Linea WETH’s maximum clearable size at $43,195, close to LlamaRisk’s approximately $41,000 July estimate.\nMainnet concentration. The largest wstETH borrower would, if liquidated, put a $256.52 million sale into a market whose instant routed depth clears $2.73 million within the bonus, about 94 times smaller. That is a statement about immediate on-chain exits, not about eventual recovery.\nPolicy question. Should the Aave Risk Framework’s clearance requirement be read against instant routed depth, or against a horizon-adjusted capacity that credits primary redemption and depth replenishment?\n\nMethod\nThe pipeline uses keyless Aave JSON-RPC state, routed quotes, Kraken prices, and DefiLlama LST ratios. A persistent registry replays Borrow events and re-queries every candidate at one pinned block. Accounts with at least $10,000 of debt enter the snapshot; target-share and debt-denomination filters form the USD-debt and combined books. The engine simulates returns, relative-value moves, and depth evaporation, then clears liquidations sequentially by bonus and seize size. Liquidators participate while slippage is below bonus / (1 + bonus). Versioned snapshots and manifests preserve inputs, hashes, seeds, parameters, and results.\nThe repository includes deterministic market reports, V3 and V4 liquidation mechanics, ordered queue clearing, historical episode replay, multi-period book evolution, and an interactive real-data dashboard.\nResult 1: Reproducing The Linea WETH Cap Decision\nThe first validation target was LlamaRisk’s July 2026 WETH cap reduction on Aave V3 Linea. The implemented settings verify on-chain at a 6,250 WETH supply cap and a 2,370 WETH borrow cap.\nLlamaRisk reported that WETH reached its liquidation-bonus threshold at about $41,000 of sell size. Independent KyberSwap ladders estimated $32,500 on July 18, $41,770 on July 30, and $43,195 in the August 18 release snapshot at block 31,749,322.\n\nliquidator break-even slippage : 5.66%\nlargest borrower sale : $300.47k\nmax clearable within bonus : $43.20k -> FAIL\nmax clearable, 50% haircut : $21.60k -> FAIL\n\nThe estimate agrees with LlamaRisk in magnitude. Complete discovery also finds a current sale above the threshold, so the formal clearance test supports the same risk direction as the cap reduction.\nThe Monte Carlo row shows why frequency and severity must accompany CVaR in a sparse book: six positive draws have mean severity of $82,020, while CVaR99 is $2,460 because 194 zeros enter the same worst-1% average.\nLinea case study | Run manifest\nResult 2: Mainnet wstETH Concentration Versus Instant Depth\nThe Ethereum snapshot at block 25,780,402 covers 84,427 historical borrower candidates and stores 9,526 accounts with at least $10,000 of current debt. The target-dominant USD-debt book is near the exploratory $5 million CVaR budget under the standard two-day calibration:\ndebt : $634.47m\npositive-loss draws : 110 / 20,000\nP(bad debt) : 0.550% (95% Wilson CI 0.457% to 0.662%)\nexpected loss : $47.85k\nloss severity : $8.70m conditional on positive loss\nCVaR99 : $4.78m\n\nThe combined book, which revalues $329.46 million of ETH-denominated debt, has $964.28 million of total debt, 3.64% bad-debt probability, and $31.82 million aggregate-queue CVaR99. Its deterministic concentration test, which measures instant routed capacity only, is:\nlargest borrower sale : $256.52m\nmax clearable within bonus : $2.73m -> FAIL\n\nThe sale is about 94 times instant capacity. The borrower is a leveraged staking loop with entirely ETH-denominated debt, so an ETH/USD move revalues both legs; relative wstETH/ETH value and exit depth are the relevant channels.\nThe liquidation trigger requires care. At the snapshot block Aave’s wstETH feed matches Lido’s canonical wstETH/stETH rate times ETH/USD: rounded inputs are 1.24188444, $1,898.3475, and $2,357.5282. A secondary-market stETH/ETH discount does not by itself reduce this feed or the borrower’s health factor. Because the model calibrates its relative-value factor on that market ratio, peg-driven losses are counterfactual canonical-rate impairment scenarios, not calibrated liquidation probabilities under the live oracle.\nThat channel is not hypothetical. Chaos Labs’ March 2026 post-mortem on wstETH exchange-rate misalignment reports a CAPO parameter mismatch that lowered the effective exchange rate by about 2.85% and liquidated roughly 10,938 wstETH across 34 accounts on the Core and Prime instances, the same Core instance this snapshot reads. Slashing or an adapter fault can impair the canonical rate; withdrawal-queue congestion instead affects exit time and secondary liquidity. Conditional on liquidation, the clearance test is unchanged because seized wstETH still reaches the routed market.\nFAIL is therefore a conditional instant-capacity result, not a live bad-debt estimate or a claim that wstETH is unsafe. Redemption over time and CEX or OTC liquidity may increase eventual capacity. This exposes an interpretation issue in the Aave Risk Framework: instant depth and horizon liquidation capacity are not the same quantity.\nEthereum run manifest\nResult 3: Mechanics Matter, But They Do Not Create Depth\nThe V4 comparison holds the V3 book, scenarios, and depth fixed. V4 repays to a target health factor; modeled V3 repays 50%, or 100% below HF 0.95. Main uses target HF 1.24, a 60% close-factor floor, 0.90 bonus factor, and 0.90 maximum-bonus HF; Correlated uses 1.0137, 35%, 1.0, and 0.99. Both use a maximum bonus 1.11 times V3. This is a mechanics counterfactual, not live V4 borrower data, and linear interpolation between bonus anchors is an assumption.\nOn the current combined book, aggregate CVaR99 is $31.82 million for V3, $32.85 million for V4 Main, and $32.83 million for V4 Correlated. Ordered clearing reduces those values to $15.25 million, $26.87 million, and $22.41 million respectively. Early transactions can clear before later sales consume depth, so queue execution is material. No mechanics choice, however, makes a $256.52 million sale fit inside $2.73 million of instant capacity.\nMatched four-day paths also separate terminal stress from evolving liquidation. Combined-book V3 CVaR99 is $32.78 million under a terminal-only shock and $31.85 million with book evolution. V4 Main moves from $51.08 million to $47.84 million; V4 Correlated moves from $40.76 million to $39.68 million. Re-liquidation occurs in 0.21% of V4 Main paths versus 16.84% of V4 Correlated paths. The higher repay target contributes to that contrast, but bonus and floor parameters also differ, so it is not a single-parameter causal estimate.\nApplying the June 2022 ETH and stETH/ETH path to today’s combined book produces a $42.20 million worst window. Because the historical loss driver was a market discount, the oracle-consistent reading is a counterfactual canonical-rate impairment of the same magnitude. This replays market paths on today’s positions; it does not reconstruct the historical book.\nPrimary Governance Question\n\nShould the largest-borrower clearance requirement use instant routed liquidity for redeemable collateral, or should it specify a time horizon and recognize primary redemption capacity?\n\nA strict instant test is auditable but can understate eventual capacity. A horizon-adjusted test is economically richer but requires explicit assumptions for redemption throughput, delay, depth replenishment, and market conditions. The framework would be clearer if it specified which interpretation governs.\nLimitations And Next Work\nThe single-asset mapping applies the target shock to all collateral in selected accounts while retaining each weighted liquidation threshold. Empirical depth is a lower bound beyond the final quote. Episode replay is not archive backtesting, and plain Monte Carlo is inefficient for rare losses. Most importantly, secondary-market peg calibration does not estimate canonical-rate impairment probabilities under the current wstETH oracle.\nThe follow-up below implements time-to-exit and liquidator economics as explicit sensitivities. Remaining work is to calibrate stressed redemption throughput and DEX refill, implement rare-event sampling with uncertainty diagnostics, and develop a direct canonical-rate model. V4 Hub premium pricing remains later work; no premium recommendation is made here.\nDiscussion And Feedback Requested\nFeedback from Risk Stewards and service providers would be useful on:\n\nIs bonus-priority ordered clearing a reasonable first approximation to competitive liquidator execution?\nWhich V4 dynamic-bonus function should replace linear interpolation between the documented anchors?\nFor exchange-rate-oracled collateral, is a canonical-rate impairment scenario the right way to stress the correlated-asset channel, and what magnitude would be considered plausible?\n\nReproduction\ngit clone https://github.com/BianchiGiacomo/aave-risk-engine\ncd aave-risk-engine\npip install -e \".[dev]\"\n\npython -m aave_risk_engine.run_market_report --snapshot data/snapshots/aave_v3_ethereum_wsteth.json --manifest docs/manifests/ethereum-wsteth-2026-08-18.json\npython -m aave_risk_engine.run_market_report --snapshot data/snapshots/aave_v3_linea_weth.json --budget 500000 --figure --manifest docs/manifests/linea-weth-2026-08-18.json\npython -m aave_risk_engine.run_episode_replay\npython -m aave_risk_engine.run_v4_comparison\npython -m aave_risk_engine.run_multiperiod\npython -m streamlit run dashboard.py\n\nThe dashboard is an optional inspection layer; versioned CLI manifests remain the canonical evidence.\n\n Mainnet wstETH Liquidation Assessment: Financing Remains Unverified\n\n [ARFC] Onboard HINC (Neuberger Securitize High Income Tokenized Fund) to Aave Horizon\n\n read \n\n 5\n min\n\n post by GBQuant on Aug 25\n\n GBQuant\n\n Update: From Instant Depth To Economic Liquidation Capacity\nThe original note ended with a question: should clearance for redeemable collateral be judged only against instant routed depth, or against capacity over a stated horizon? I extended the wstETH case from a capacity test into a liquidator balance-sheet sensitivity.\nThe strict result is unchanged. A $256.52 million wstETH sale remains far above the $2.73 million that current routed DEX quotes clear instantly within the 6% bonus. That test is still FAIL and excludes redemption, CEX, and OTC liquidity.\nThe extension asks a different question. Suppose a liquidator repays about $242 million at time zero, receives the collateral, hedges ETH/USD, and warehouses the position while exiting through DEX liquidity or primary redemption. Can the liquidation bonus cover recovery losses, funding, hedge carry, and the required return on capital?\nThe route optimizer selects one total DEX/redemption allocation that maximizes economic profit, then executes each allocation at its earliest modeled capacity. The published sensitivity uses:\n\n10% annual funding and a separate 10% annual capital hurdle;\n0.10% hedge entry and 2% annual hedge carry;\na 1% DEX execution-loss ceiling;\na 24-hour redemption delay and illustrative $25 million/day throughput;\n4% canonical or oracle-to-recovery loss and zero additional DEX discount.\n\nroute clear time economic profit minimum bonus\nquiet DEX only 30.11d -$0.66m 6.29%\nstressed DEX only 241.88d -$16.92m 13.49%\noptimized DEX + redemption 11.26d $3.11m 4.66%\n\nAt the assumed redemption rate, the optimizer assigns all $256.52 million to redemption. Quiet and stressed blended rows therefore coincide: DEX depth is not decision-relevant once the chosen route avoids it. This is not evidence that a 6% bonus is sufficient in practice. It shows that the conclusion is controlled by the redemption assumption.\nThat dependence is visible in a correlated stress sensitivity. Halving stressed redemption throughput to $12.5 million/day increases exit time to 21.08 days, reduces economic profit to $2.37 million, and raises the minimum bonus to 4.98%. The optimizer then assigns $5.49 million to DEX and $251.03 million to redemption.\n\nThe main limitation is now explicit: $25 million/day is a sensitivity input, not a measured Lido stress-throughput estimate. The model also assumes sufficient full-upfront financing, deterministic future capacity, and a static route split. It does not establish that redemption slots or the required hedge can be secured. These outputs are not a wstETH safety claim or a liquidation-bonus recommendation.\nThis suggests that two tests may be more informative than forcing one interpretation:\n\nstrict instant clearance against observable routed depth;\nhorizon-adjusted economic clearance under explicit funding, canonical-loss, and redemption-throughput stresses.\n\nA governance conclusion should not treat the second test as a pass on an uncalibrated throughput assumption. Its current value is to identify the empirical quantity that controls the answer.\n\nFor redeemable collateral, should the Risk Framework supplement instant clearance with a specified exit horizon and stressed primary-redemption throughput, while requiring the liquidation bonus to compensate the liquidator’s capital and recovery risk over that horizon?\n\nExact results and commands | Run manifest | Model specification\npython -m aave_risk_engine.run_liquidator_balance_sheet \\\n --snapshot data/snapshots/aave_v3_ethereum_wsteth.json \\\n --redemption-usd-per-day 25000000 \\\n --canonical-losses 0.04\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 259\n\n Sep 21\n\n Mainnet wstETH Liquidation Assessment: Financing Remains Unverified\n\n Assessments\n\n 0\n\n 79\n\n Sep 15\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 264\n\n Aug 21\n\n [ARFC] Aave V4 Activation on Ethereum Mainnet\n\n Governance\n\n 50\n\n 7.8k\n\n 5d","tokens":3830,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265614409,"hash":"001e234bbb79ec70b12e1448686c25835c15a429"}
{"url":"https://docs.base.org/specifications/native-account-abstraction","domain":"docs.base.org","title":"Native Account Abstraction - Base Documentation","text":"This is the technical reference for EIP-8130 on Base. For what native account abstraction is and why the protocol implements it, start with Native Account Abstraction.\nEIP-8130 builds account abstraction into the protocol. An account registers who can act for it, and how its signatures are checked, in an onchain system contract. The chain validates each transaction against that configuration, so smart accounts work without bundlers, relays, or a separate mempool.\nEIP-8130 is experimental and currently runs only on the vibenet devnet. You can learn more in the guide to connecting to vibenet.\n​Network Details\nFieldValueNetworkvibenet devnetChain ID84538453RPChttps://rpc.vibes.base.orgFaucetPOST https://api.vibes.base.org/api/vibenet/faucet/drip\n​Client Setup\nClient support lives in an experimental viem fork:\nTerminalbun add \"viem@github:chunter-cb/viem#feat/eip-8130\"\n\n​Create an Account and Send a Batch\nThe example below performs the full flow:\n\nCreates an account.\nFunds it from the faucet.\nSends a batch of calls that succeed or revert together.\nVerifies that every phase succeeded.\n\ncreate-and-send.tsimport { createPublicClient, http, parseEther } from \"viem\";\nimport { privateKeyToAccount, generatePrivateKey } from \"viem/accounts\";\nimport {\n newSmartAccount8130, sendCalls8130, estimateGas8130,\n encodeWalletCalls, waitForTransactionReceipt8130, allPhasesSucceeded,\n} from \"viem/experimental/eip8130\";\n\nconst RPC_URL = \"https://rpc.vibes.base.org\";\nconst chain = {\n id: 84538453,\n name: \"vibenet\",\n nativeCurrency: { name: \"Ether\", symbol: \"ETH\", decimals: 18 },\n rpcUrls: { default: { http: [RPC_URL] } },\n};\nconst client = createPublicClient({ chain, transport: http(RPC_URL) });\n\n// The account address is deterministic and exists before any deployment\nconst signer = privateKeyToAccount(generatePrivateKey());\nconst account = newSmartAccount8130({ signer });\n\n// Fund it from the vibenet faucet\nawait fetch(\"https://api.vibes.base.org/api/vibenet/faucet/drip\", {\n method: \"POST\",\n headers: { \"content-type\": \"application/json\" },\n body: JSON.stringify({ address: account.address }),\n});\n\n// Estimate, then send a batch. Account creation rides along in the same transaction\nconst calls = [{ to: \"0x…recipient\", value: parseEther(\"0.001\") }];\nconst gas = await estimateGas8130(client, {\n sender: account.address,\n accountChanges: [account.createChange],\n calls: encodeWalletCalls({ account: account.address, calls: [calls] }),\n});\nconst hash = await sendCalls8130(client, {\n account,\n accountChanges: [account.createChange],\n calls,\n gas: (gas * 120n) / 100n,\n});\n\n// An 8130 receipt reports per-phase results, so check all of them\nconst receipt = await waitForTransactionReceipt8130(client, { hash });\nif (!allPhasesSucceeded(receipt)) throw new Error(\"a phase reverted\");\n\nOne transaction creates the account, executes the batch, and pays for gas.\n​Transaction Structure\nAn 8130 transaction names a sender account, proves the sender is authorized to act for it, and carries a batch of calls.\nFieldPurposesenderThe account the transaction acts for.accountChangesConfiguration changes applied before execution, including account creation.callsThe batch to execute atomically.payerOptional account that covers gas on the sender’s behalf.\nReceipts report results per phase rather than as a single status, so a transaction can succeed at the transaction level while an individual phase reverts. Check every phase; allPhasesSucceeded does this in the reference client.\n​Accounts\nAccount addresses are derived with CREATE2, so a client computes them locally and the address exists before any deployment. That is why account.address is available immediately and account.createChange can ride along in the first transaction.\nEach account is a small proxy contract that forwards calls to a shared implementation.\nImplementationNotesDefaultAccountThe minimal building block. Also backs EOAs upgraded via EIP-7702.High-rate variantLocks outbound ETH during execution in exchange for higher mempool rate limits.\n​Account Configuration\nAuthorization lives in the AccountConfiguration system contract. It records the actors an account authorizes: the onchain identities that a signer’s authorization resolves to. An account may authorize many actors and revoke each independently.\nEach actor entry carries:\nElementPurposeScope flagsSCOPE_NONCE and SCOPE_POLICY bound what the actor may do.Policy bindingOptional onchain policy: per-token spend limits, and allowed contracts and functions.AuthenticatorThe contract that validates this actor’s signatures.\nBinding an actor to a policy is the native session key model: an app receives an actor with exactly the permissions it needs, revocable at any time.\n​Authenticators\nSignature validation is pluggable. Authenticator contracts implement:\nIAuthenticator.solinterface IAuthenticator {\n function authenticate(bytes32 hash, bytes calldata data) external view returns (bool);\n}\n\nThe reference set covers:\nAuthenticatorKeyssecp256k1Standard EVM keysP-256NIST P-256WebAuthnPasskeys and platform authenticators\nPasskeys therefore validate at the protocol level, not through wrapper contracts.\n​Payers\nA transaction can name a payer that covers gas on the sender’s behalf, with no paymaster contract involved. Draft ERC-8168 standardizes the payer service flow: how apps discover a payer and request sponsorship.\n​Go Deeper\nWas this page helpful?Suggest editsRaise issue","tokens":1355,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265618025,"hash":"309c1eaedb13035a2ffc8d07ea9664e8a819ac43"}
{"url":"https://governance.aave.com/t/arfc-liquidation-protocol-fee-increase-for-wbtc-weth-and-wsteth-on-aave-v3-ethereum-core/25470/1","domain":"governance.aave.com","title":"[ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core - Governance - Aave","text":"[ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Summary\n\n Motivation\n\n Fee mechanics\n\n Financial results\n\n Measurement window\n\n Net effect by fee level, WBTC / WETH / wstETH\n\n The risk-adjusted ceiling\n\n Risk assessment\n\n Which liquidations a higher fee stops\n\n The counterfactual check\n\n Conservatism of the estimates\n\n Assumptions\n\n Specification\n\n Next Steps\n\n Disclaimer\n\n Aug 12\n\n 1 / 3\n\n Aug 12\n\n Aug 21\n\n post by LlamaRisk on Aug 12\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk has initiated a review of the Liquidation Protocol Fee (LPF) configuration on Aave V3 Ethereum Core. The LPF is the share of each liquidation bonus that accrues to the Aave treasury, defined on a per collateral reserve basis. It currently stands at 10% for most Ethereum Core collateral, with USDC and DAI at 20%. Based on a full measurement of liquidation economics on Ethereum Core through the Chainlink SVR era, combined with forward-looking modeling of net revenue and liquidator behavior at higher fee levels, we propose raising the LPF from 10% to 20% on WBTC, WETH, and wstETH, on Aave V3 Ethereum Core only, and we recommend against going higher or broader than that at this time.\nBacktested against the observed liquidation history, the change would have added between $1.35M and $2.23M per year of net treasury revenue, with no measurable bad debt attributable to it, including through the October 2025 crash. Realized dollar figures will depend on future liquidation volume, so the more durable way to express the gain is Aave’s take per dollar of value liquidated. On these three collaterals it is expected to rise from about 173 bps today to 187–196 bps, an increase of roughly 8% to 13%.\nThe LPF and the SVR auction recapture value from the same liquidation bonus, so a higher fee partly displaces income Aave already receives, and beyond a point it suppresses the marginal liquidations that fund both revenue streams. Under conservative assumptions, Aave’s take per dollar liquidated on these three collaterals peaks near a 30% fee and falls back below today’s level by 40%. Any increase also adds risk in stress scenarios that are difficult to predict, because a static fee keeps taking its share even when liquidator margins compress, while SVR auction bids shrink with the margin. We therefore treat 20% as the appropriate step today and 30% as a hard ceiling on what the data could support.\nAave recapture per $1 liquidated and its diminishing returns2520×1116 174 KB\nSource: LlamaRisk, August 11, 2026\nMotivation\nLiquidation revenue on Ethereum Core comes from two sources. The static LPF is taken from each liquidation bonus, and the SVR auction recaptures part of what remains, with liquidators bidding away their margin and the proceeds shared 65% to Aave and 35% to Chainlink. Since October 2025, the auction reaches nearly all liquidated value. A higher fee would therefore draw on the same surplus the auction already recaptures. The relevant question for the DAO is not what a higher fee collects gross, but what it collects net of the auction income it displaces, and what tail risk it introduces where liquidator margins are thin.\nTo answer it, LlamaRisk measured the economics of every liquidation on Aave V3 Ethereum Core between April 2025 and June 2026, covering 14,006 events and approximately $1.05B of seized collateral. Each event was measured from onchain data at block-by-block oracle prices, including DEX price impact, gas, payments to block builders, and SVR auction proceeds. On that base we modeled fee levels from 20% to 60% and validated every liquidation a higher fee would have made unprofitable against the borrower’s counterfactual price path.\nWBTC, WETH, and wstETH account for approximately $612M of liquidated value in the post-October window and for most of the portfolio’s fee gain at any level. They are the deepest markets on Aave, served by the most redundant set of liquidators, and they show no bad debt attributable to a 20% fee in either measurement window.\nHowever, thinner collateral looks different and this is an important trade-off. In the portfolio-wide assessment BAL came out net negative at both 20% and 30%, earning around $30–60k of extra fee per year while accounting for the entire modeled bad-debt line. Its liquidations settle exclusively on DEX liquidity with high price impact, and its liquidators run the thinnest margins on the market.\nThe same economics apply, in milder degrees, across the smaller reserves. Liquidator margins thin out as collateral moves away from the bluechips, so each fee increase starts leaving positions unliquidated earlier there than on the majors, and a level that is comfortable for WBTC can already be suppressing liquidations on a mid-tail asset, even if liquidation bonus is overall larger. Somewhere around 20%, a broader increase would begin shifting risk onto the assets least able to bear it.\nFee mechanics\nThe liquidation bonus is the discount a liquidator receives on seized collateral. The LPF is deducted from this bonus first, and the Chainlink Smart Value Recapture (SVR) auction then recaptures value from what the liquidator has left. Raising the fee from f₀ to f therefore displaces each liquidation’s SVR bid one for one, up to the size of that bid:\n\nD_i = \\min\\big((f - f_0)\\cdot \\text{bonus}_i,\\ \\ \\text{recapture}_i\\big)\n𝐷𝑖=min((𝑓−𝑓0)⋅bonus𝑖,  recapture𝑖)\nwhere bonusᵢ is the gross liquidation bonus of liquidation i and recaptureᵢ its observed SVR auction proceeds (zero for liquidations that settle outside the auction). Aave gains the full extra fee but loses its 65% share of the displaced auction proceeds. A fee increase in the current regime is therefore partly a reallocation of existing liquidation income rather than new revenue.\nAt higher fee levels a second mechanic dominates. A liquidation whose surplus the fee would exhaust no longer occurs, because no liquidator can execute it profitably. It then pays no fee, and it also stops generating the LPF and SVR recapture it produces at the current 10% fee. Onchain history cannot show how liquidators would respond to a fee that has never changed during the SVR era, so results are reported as a band between two treatments. The conservative case assumes that every liquidation the fee makes unprofitable stops occurring, and the upper bound assumes that all of them still execute and pay the fee.\nFinancial results\nMeasurement window\nAll figures in this document are based on the period from October 13, 2025 to June 1, 2026. Earlier months are excluded because the SVR order flow was only fully integrated with the dominant block builders in mid-October 2025, so they do not reflect the mechanism as it operates today. The October 10, 2025 crash, the most severe liquidation episode in the dataset, falls just before that cutoff. Where it matters, we therefore also report the same scenarios with the crash week added back in, as a stress test. The window covers three of the four major liquidation cascades of the past year.\nNet effect by fee level, WBTC / WETH / wstETH\nPost-October regime, net to Aave, change versus the current 10% fee, $/yr. Each cell is the band of [conservative, upper bound] estimations:\n\nLPF\nWBTC\nWETH\nwstETH\nTotal\n\n20%\n+$0.38M to +$0.88M\n+$0.81M to +$0.84M\n+$0.16M to +$0.51M\n+$1.35M to +$2.23M\n\n30%\n+$0.93M to +$1.81M\n+$1.57M to +$1.69M\n+$0.57M to +$1.10M\n+$3.07M to +$4.60M\n\n40%\n−$0.07M to +$2.90M\n+$1.57M to +$2.56M\n+$0.48M to +$1.69M\n+$1.97M to +$7.14M\n\n50%\n−$0.06M to +$4.26M\n+$1.71M to +$3.56M\n−$0.91M to +$2.40M\n+$0.74M to +$10.23M\n\n60%\n−$0.34M to +$5.79M\n+$1.16M to +$4.71M\n−$2.44M to +$3.36M\n−$1.62M to +$13.87M\n\nNet revenue by fee and collateral2160×1188 199 KB\nSource: LlamaRisk, August 11, 2026\nIncluding the October 10 crash week, the 20% total is +$1.20M to +$2.15M per year. The 20% level produces no bad debt on these collaterals in either window. The only bad-debt charge these three assets show anywhere in the analysis appears at the 40% to 60% levels, on WETH positions from the crash week, most of which were already insolvent at the moment of liquidation.\nIn recapture terms, Aave today keeps about 173 bps of every dollar liquidated on these three collaterals, combining the 10% LPF and its 65% share of the SVR recapture. Under the conservative treatment that take peaks at about 205 bps near a 30% fee and falls back to about 156 bps at 60%, below today’s level. The upper bound keeps rising with the fee, but it assumes that no liquidator ever pulls back. The higher the fee, the wider the gap between the two bounds, and the less certain the outcome.\nThe risk-adjusted ceiling\nThe build-up below traces, for the three collaterals combined at a 60% fee, how the gross fee turns into net revenue under each treatment. A flipped liquidation is one the higher fee makes unprofitable, meaning the fee takes so much of the bonus that no liquidator can execute it and keep a margin. Both treatments begin from the same $24.1M of annual fee a 60% LPF would collect if every liquidation executed. The upper bound assumes the flipped liquidations still execute, so it subtracts only the displaced SVR income and stays positive.\nThe conservative treatment assumes they stop occurring, so it also removes the fee they no longer pay and the baseline LPF and SVR income they generate today, leaving −$1.6M. Beyond a certain fee level the protocol is no longer taxing liquidator surplus but suppressing the liquidations that fund both revenue streams, and additional fee lowers revenue.\nWhy the conservative case turns negative at a 60% LPF2520×1152 140 KB\nSource: LlamaRisk, August 11, 2026\nThe broader problem with higher fee levels is that the uncertainty of the estimate grows. Each additional fee percentage point adds a fixed amount of gross fee but pushes more liquidations toward their break-even point, where behavior cannot be predicted from onchain history. wstETH shows this most directly, where the majority of its liquidation value settles against market-maker inventory off-book, where the margin behind the observed auction bid cannot be traced onchain, and under the conservative treatment its net turns negative from 50% onward, reaching −$2.44M per year at 60%. The realized outcome at high fees would land somewhere inside the band. The protocol cannot know where in advance, and the cost of being wrong rises with the fee. On a risk-adjusted basis, approximately 30% is the ceiling this data could support. We propose 20% rather than the ceiling because it captures the well-supported part of the gain and lets the protocol observe actual liquidator behavior under a raised fee for the most liquid reserves before any additional move is considered.\nRisk assessment\nWhich liquidations a higher fee stops\nA liquidation remains economically viable while its bonus covers the liquidator’s two hard costs, the price impact of selling the seized collateral and the transaction processing fee. Everything above those costs is surplus. Payments to block builders and bids into the SVR auction are surplus too, given away voluntarily to win the execution. For each liquidation, the surplus was measured onchain as the cash the operator’s addresses kept plus what it paid to the builder or auction, capped at the liquidation’s own bonus. The fee level at which this surplus reaches zero is the liquidation’s break-even fee. A liquidation is treated as unexecuted when the proposed fee would leave its liquidator less than 10% of the bonus as profit, a deliberately stricter rule than pure break-even.\nThe counterfactual check\nFor every position below the cushion, market-maker liquidations included, the analysis reconstructs the borrower’s counterfactual health factor at each of the 100 blocks (about 20 minutes) following the liquidation, using block-exact oracle prices, and books a shortfall only where collateral can no longer cover the debt plus the liquidation bonus a future liquidator must be paid.\nAcross the union of all candidate sets on these three collaterals in both windows, 465 positions worth approximately $354M were checked. In the post-October window a single position crosses the bad-debt threshold, for a negligible shortfall. Every other liquidation a higher fee would have left unexecuted either recovered on its own or remained adequately collateralised over the following 100 blocks. Across both windows, ten positions cross, all WETH, with a combined shortfall of approximately $0.55M. Nine of them were liquidated during the October 10 crash while already below the threshold, so the shortfall existed at the current 10% fee.\nFlipped positions over the next 100 blocks2340×792 64.2 KB\nSource: LlamaRisk, August 11, 2026\nThe pattern behind these results is consistent. Liquidations near the margin are overwhelmingly triggered by momentary oracle price dips on positions that are healthy minutes later, and a higher fee declines to act on dips that did not need acting on. The mechanism also self-corrects. If a price genuinely keeps falling, the same position becomes more profitable to liquidate and a liquidator returns within blocks, even at the higher fee. The figure below traces the block-by-block counterfactual path of the 10 largest flipped positions, including the largest market-maker liquidations. Each remains at or above its liquidation threshold and returns toward or above 1.\nCounterfactual health factor of the 10 largest flipped positions2340×1188 132 KB\nSource: LlamaRisk, August 11, 2026\nConservatism of the estimates\nThe estimates are deliberately biased against the proposal. The conservative bound treats every liquidation the fee makes unprofitable as not occurring, including all market-maker value, even though some of it would still execute at a thinner margin. The bad-debt line charges the worst point of each position’s 100-block path in full, including shortfall that already existed at the current fee. The 10% profit cushion stops liquidations that are still profitable, where the break-even may have been lower. The counterfactual reprices each position by its seized collateral’s full price move, which overstates the drop for positions holding several collateral types.\nAssumptions\n\nThe analysis is a backtest carrying empirical estimates. The 2025 to 2026 record, including the October 2025 crash, shows how those months would have played out under a higher fee. It cannot price a future episode more severe than October 10, in which prices do not recover before liquidators return. Equivalently, future liquidation volumes cannot be predicted.\nWithin the backtest, the central assumption is that the fee displaces SVR bids one for one. It follows from the auction’s design, since a liquidator cannot bid surplus the fee has already taken, but it has never been observable, because the fee has not changed since inception. Raising the fee to 20% would produce the first onchain observation of it.\nThe model further assumes that liquidators stop acting once the fee leaves them less than 10% of the bonus. Break-even fees are measured from traced onchain cash flows, but how liquidators actually respond cannot be measured in advance, and a static fee does not throttle itself in stress the way the auction does. Market-maker liquidations are the largest single unknown here. That uncertainty grows with the fee and is a further reason to stop at 20%.\nThe bad-debt check follows each position for 100 blocks, about 20 minutes. Beyond that horizon a genuinely falling price makes the same position more profitable to liquidate, so a liquidator returns. This is an argument from incentives rather than an observation, and it is why 20 minutes is treated as the relevant window.\n\nSpecification\n\nMarket\nAsset\nParameter\nCurrent\nProposed\n\nAave V3 Ethereum Core\nWBTC\nLiquidation Protocol Fee\n10%\n20%\n\nAave V3 Ethereum Core\nWETH\nLiquidation Protocol Fee\n10%\n20%\n\nAave V3 Ethereum Core\nwstETH\nLiquidation Protocol Fee\n10%\n20%\n\nAll other reserves and markets remain unchanged.\nNext Steps\n\nGather community feedback on this proposal.\nIf consensus is reached, escalate to ARFC Snapshot.\nIf the Snapshot passes, implement the parameter changes via AIP.\n\nFollowing implementation, LlamaRisk will monitor liquidation execution, SVR recapture, and liquidator margins on the affected collaterals, including through the next stress episode.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\n\n LlamaRisk - Monthly Community Update\n\n read \n\n 6\n min\n\n 8 days later\n\n post by Abel189 on Aug 21\n\n 1 month later\n\n Closed on Sep 20\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Revision of ETH & BTC Collateral Efficiency on Aave\n\n General\n\n 2\n\n 259\n\n Sep 21\n\n Independent Liquidation-Capacity Stress Tests For Aave\n\n Risk\n\n 1\n\n 218\n\n Aug 25\n\n Aave v3-v4 liquidation bot\n\n Liquidation\n\n 9\n\n 469\n\n Sep 11\n\n [ARFC] Low Adoption Asset Deprecation on Aave V3\n\n Governance\n\n 9\n\n 2.1k\n\n Sep 16\n\n [ARFC] Oracle Deprecation for Long-tail Assets Across Aave V2 and V3\n\n Governance\n\n 3\n\n 527\n\n Aug 12","tokens":4358,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265624428,"hash":"481862bb9b4a0f73c3ec2ed03c68cd2ea0a8cb1d"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/5","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"Layer 2Plasma\n\n new-extension\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 5 / 144\n\n Jan 2018\n\n May 2019\n\n post by vbuterin on Jan 3, 2018\n\n post by jdkanani on Jan 9, 2018\n\n post by kladkogex on Jan 9, 2018\n\n kladkogex\n\n I have read the description several times, I am not sure though I understand how an exit transaction is verified by the parent blockchain …\n\nIs this correct to say, that to exit you need to have signatures of all owners of intemediate UTXOs … ? And all of these signatures will be verified during the exit? Correct?))\n\nIn this structure if I look at a particular UTXO, it may have two parents, so essentially if I go back N transactions in history for a particular UTXO, I will have 2^N2𝑁 ancestors … ? correct?) Would it mean that the size of the exit proof would grow exponentially as coins exchange hands?)) Or I am missing something ?))\n\n post by vbuterin on Jan 10, 2018\n\n vbuterin\n\n You do not need to provide a proof of the entire history of a UTXO in order to exit with that UTXO; you just need to prove that the UTXO exists and was included. It seems counterintuitive that you need to prove that little, but it works; it relies heavily on the fact that if any user sees an invalid UTXO get in, they need to exit within some timeframe, and make sure to not finalize transfers that were included after that invalid UTXO.\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n post by ldct on Jan 12, 2018\n\n post by kladkogex on Jan 12, 2018\n\n post by ldct on Jan 12, 2018\n\n post by kladkogex on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by denett on Jan 13, 2018\n\n post by vbuterin on Jan 13, 2018\n\n post by denett on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n Load more posts below","tokens":1185,"squid":"ink-research","role":"Deep Scholar","at":1791265638255,"hash":"a3276091485aec9bafe76405ebe54394df5a0039"}
{"url":"https://status.base.org/","domain":"status.base.org","title":"Base Status","text":"All Systems Operational\n\n Uptime over the past 90 days. View historical uptime.\n\n Website\n\n Operational\n\n Homepage\n\n Operational\n\n Docs\n\n Operational\n\n Mainnet\n\n Operational\n\n Public RPC API\n\n Operational\n\n Deposits\n\n Operational\n\n Withdrawals\n\n Operational\n\n Batch submission\n\n Operational\n\n Block production\n\n Operational\n\n Flashblocks\n\n Operational\n\n Transaction pool\n\n Operational\n\n Snapshots\n\n Operational\n\n Client Software\n\n Operational\n\n Testnet\n\n Operational\n\n Public RPC API\n\n Operational\n\n Deposits\n\n Operational\n\n Withdrawals\n\n Operational\n\n Batch submission\n\n Operational\n\n Block production\n\n Operational\n\n Flashblocks\n\n Operational\n\n Transaction pool\n\n Operational\n\n Snapshots\n\n Operational\n\n Client Software\n\n Operational\n\n Bridge (Mainnet)\n\n Operational\n\n Bridge (Testnet)\n\n Operational\n\n Operational\n\n Degraded Performance\n\n Partial Outage\n\n Major Outage\n\n Maintenance\n\n Major outage\n\n Partial outage\n\n No downtime recorded on this day.\n\n No data exists for this day.\n\n had a major outage.\n\n had a partial outage.\n\n Related\n\n No incidents or maintenance related to this downtime.\n\n Scheduled Maintenance\n\n V1 Node Snapshot Deprecation: October 5th, 2026\n\n Oct 5, 2026 12:00 - Oct 6, 2026 12:00 UTC\n\n Scheduled -\n\n Effective Oct 5, 2026: Base will stop publishing V1 node database snapshots. Existing V1 snapshots will no longer be provided past this date.Download V2 Snapshots here: chain.base.org/snapshotsInstructions: docs.base.org/specifications/node-operators/snapshots\n\n Sep 29, 2026 - 14:55 UTC\n\n mainnet.base.org public RPC changes: October 8th, 2026\n\n Oct 8, 2026 12:00 - Oct 9, 2026 12:00 UTC\n\n Starting Oct 8, 2026, mainnet.base.org will no longer serve the debug, trace, and txpool namespaces, and read requests will be subject to a lower rate limit. The endpoint remains free and best-effort for basic reads. Apps that use these namespaces or need higher throughput should move to a dedicated RPC provider before Oct 8. See our supported providers: https://docs.base.org/get-started/base-services-hub#service-providers.\n\n Posted on\n\n Oct 01, 2026 - 14:06 UTC\n\n Past Incidents\n\n Oct 6, 2026\n No incidents reported today.\n\n Oct 5, 2026\n No incidents reported.\n\n Oct 4, 2026\n No incidents reported.\n\n Oct 3, 2026\n No incidents reported.\n\n Oct 2, 2026\n No incidents reported.\n\n Oct 1, 2026\n No incidents reported.\n\n Sep 30, 2026\n\n Mainnet: Base Cobalt Upgrade - September 30th\n\n Completed -\n The scheduled maintenance has been completed.\n\n Sep 30, 20:00 UTC\n\n In progress -\n Scheduled maintenance is currently in progress. We will provide updates as necessary.\n\n Sep 30, 18:00 UTC\n\n Scheduled -\n On Wednesday, September 30th at 18:00 UTC (Unix timestamp 1790791200), Base Mainnet will undergo the Cobalt upgrade.Operators of Base Mainnet nodes must upgrade to the 1.4.2, or greater, release of the https://github.com/base/base software (https://github.com/base/base/releases/tag/v1.4.2). Please note: https://github.com/base/base now hosts the public Base node previously published from base/node. More information can be found here: https://github.com/base/base#run-a-nodeFor more information on the Cobalt upgrade, please visit our docs: https://docs.base.org/upgrades/cobalt/overview.\n\n Sep 23, 23:00 UTC\n\n Sep 29, 2026\n No incidents reported.\n\n Sep 28, 2026\n No incidents reported.\n\n Sep 27, 2026\n No incidents reported.\n\n Sep 26, 2026\n No incidents reported.\n\n Sep 25, 2026\n No incidents reported.\n\n Sep 24, 2026\n No incidents reported.\n\n Sep 23, 2026\n\n Sepolia Testnet: Base Cobalt Upgrade - September 23rd\n\n Completed -\n The scheduled maintenance has been completed.\n\n Sep 23, 20:00 UTC\n\n In progress -\n Scheduled maintenance is currently in progress. We will provide updates as necessary.\n\n Sep 23, 18:00 UTC\n\n Scheduled -\n On Wednesday, September 23rd at 18:00 UTC (Unix timestamp 1790186400), the Base Sepolia Testnet will undergo the Cobalt upgrade.Operators of Base Sepolia Testnet nodes must upgrade to the 1.4.0, or greater, release of the https://github.com/base/base software (https://github.com/base/base/releases/tag/v1.4.0). Please note: https://github.com/base/base now hosts the public Base node previously published from base/node. More information can be found here: https://github.com/base/base#run-a-nodeFor more information on the Cobalt upgrade, please visit our docs: https://docs.base.org/upgrades/cobalt/overview.\n\n Sep 16, 21:22 UTC\n\n Sep 22, 2026\n No incidents reported.\n\n Incident History\n\n Powered by Atlassian Statuspage","tokens":1120,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265639212,"hash":"e68f2ce91331611a9d9ee143b2287256a4226683"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/6","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"Layer 2Plasma\n\n new-extension\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 6 / 144\n\n Jan 2018\n\n May 2019\n\n post by vbuterin on Jan 3, 2018\n\n vbuterin\n\n Special thanks to Joseph Poon and David Knott for discussions that led to this specification.\nThe following aims to provide a specification for a “minimal viable plasma implementation”. It aims to provide the basic security properties of Plasma in a very simplified way, though it leans heavily on users being willing to immediately exit as soon as they detect any kind of malfeasance.\nThe Plasma Contract\nThe Plasma contract maintains the following data structures:\n\nThe owner (set at initialization time)\nA list of Plasma blocks, for each block storing (i) the Merkle root, (ii) the time the Merkle root was submitted.\nA list of submitted exit transactions, storing (i) the submitter address, and (ii) the UTXO position (Plasma block number, txindex, outindex). This must be stored in a data structure that allows transactions to be popped from the set in order of priority.\n\nA Plasma block can be created in one of two ways. First, the operator of the Plasma chain can create blocks. Second, anyone can deposit any quantity of ETH into the chain, and when they do so the contract adds to the chain a block that contains exactly one transaction, creating a new UTXO with denomination equal to the amount that they deposit.\nThe contract has the following functions:\n\nsubmitBlock(bytes32 root): submits a block, which is basically just the Merkle root of the transactions in the block\n\ndeposit(): generates a block that contains only one transaction, generating a new UTXO into existence with denomination equal to the msg.value deposited\n\nstartExit(uint256 plasmaBlockNum, uint256 txindex, uint256 oindex, bytes tx, bytes proof, bytes confirmSig): starts an exit procedure for a given UTXO. Requires as input (i) the Plasma block number and tx index in which the UTXO was created, (ii) the output index, (iii) the transaction containing that UTXO, (iv) a Merkle proof of the transaction, and (v) a confirm signature from each of the previous owners of the now-spent outputs that were used to create the UTXO.\n\nchallengeExit(uint256 exitId, uint256 plasmaBlockNum, uint256 txindex, uint256 oindex, bytes tx, bytes proof, bytes confirmSig): challenges an exit attempt in process, by providing a proof that the TXO was spent, the spend was included in a block, and the owner made a confirm signature.\n\nstartExit must arrange exits into a priority queue structure, where priority is normally the tuple (blknum, txindex, oindex) (alternatively, blknum * 1000000000 + txindex * 10000 + oindex). However, if when calling exit, the block that the UTXO was created in is more than 7 days old, then the blknum of the oldest Plasma block that is less than 7 days old is used instead. There is a passive loop that finalizes exits that are more than 14 days old, always processing exits in order of priority (earlier to later).\nThis mechanism ensures that ordinarily, exits from earlier UTXOs are processed before exits from older UTXOs, and particularly, if an attacker makes a invalid block containing bad UTXOs, the holders of all earlier UTXOs will be able to exit before the attacker. The 7 day minimum ensures that even for very old UTXOs, there is ample time to challenge them.\nThe Plasma Chain\nEach Merkle root should be a root of a tree with depth-16 leaves, where each leaf is a transaction. A transaction is an RLP-encoded object of the form:\n[blknum1, txindex1, oindex1, sig1, # Input 1\n blknum2, txindex2, oindex2, sig2, # Input 2\n newowner1, denom1, # Output 1\n newowner2, denom2, # Output 2\n fee]\n\nEach transaction has 2 inputs and 2 outputs, and the sum of the denominations of the outputs plus the fee must equal the sum of the denominations of the inputs. The signatures must be signatures of all the other fields in the transaction, with the private key corresponding to the owner of that particular output. A deposit block has all input fields, and the fields for the second output, zeroed out. To make a transaction that spends only one UTXO, a user can zero out all fields for the second input.\nUser Behavior\nThe process for sending a Plasma coin to someone else is as follows:\n\nAsk them for their address.\nSend a transaction that sends some of your UTXOs to their address.\nWait for it to get confirmed in a block.\nSend them a confirm message, signed with the keys that you use for each of your UTXO inputs.\n\nEmergency exiting\nA user should continually validate (or validate at least once per 7 days) that the Plasma chain is fully available and valid; if it is not, they should exit immediately.\nProof of correctness sketch\nApproximate claim: a UTXO with denomination D will entitle its owner to withdraw D coins, and that (i) fraudulent cancellations and (ii) invalid UTXOs successfully withdrawing and draining the contract before the user can fully withdraw will not prevent them from doing so.\nSuppose that:\n\nThe first invalid or unavailable transaction is at position (blknum_i, txindex_i).\nThere exist TXOs before that point of total denomination M, of which M-N is spent and N is unspent. We call a TXO spent if a transaction spending it has been included in a block, and a commit from the owner of the TXO is in the hands of the owner of at least one of the child TXOs.\n\nConsider any UTXO with denomination D that was confirmed in a position before (blknum_i, txindex_i), call it (blknum_e, txindex_e). We assume that within 1 day of the first invalid or unavailable transaction getting confirmed, the owner of that UTXO publishes an exit. This exit is assigned a priority of (blknum_e, txindex_e), and so it will be processed before (blknum_i, txindex_i). We also assume that if there is a transaction “in flight” spending this UTXO, and this gets included in a future block, then the owner will refuse to sign the commit. We know that:\n\nBy the validity assumption, there are >=N coins deposited in the contract.\nThere are no UTXOs with commits spending that UTXO, so a challenge is not possible.\nAll TXOs chronologically before (blknum_e, txindex_e) are valid. We ignore TXOs chronologically after (blknum_e, txindex_e) because they have no ability to influence the given UTXO’s ability to exit successfully (TXOs before it can, by draining the balance first)\nTXOs chronologically before (blknum_e, txindex_e) are of two types: (i) unspent, with total denomination N-D, (ii) spent, with total denomination M-N. Exits of the second type can be challenged, and exits of the first type will succeed.\n\nHence, there will be at least D coins left in the contract’s deposit to pay the owner of the deposit.\nThe following aims to provide a specification for a “minimal viable plasma implementation”. It aims to provide the basic security properties of Plasma in a very simplified way, though it leans heavily on users being willing to immediately exit as soon as they detect any kind of malfeasance.\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n More Viable Plasma\n\n Account based Plasma (MoreVP)\n\n A potential problem with two \"types\" of blocks in Plasma MVP?\n\n Plasma (+ Delegated Exits)\n\n 31\n\n 14\n\n 14\n\n 12\n\n 11\n\n read \n\n 36\n min\n\n post by jdkanani on Jan 9, 2018\n\n jdkanani\n\n Thanks for the post.\nSlightly more difficult scenario, how I can enforce correctness in case of state change in account/state based plasma chain?\n(block 0, state 0, [t1, t2.... ]) -> state 1 \n(block 1, state 1, [t1, t2.... ]) -> state 2\n\nLet’s say if one wants to challenge block 1, saying - t2 in block 1 in not valid as it should yield state 2' instead of state 2. How one can generate fraud proof?\n\n post by kladkogex on Jan 9, 2018\n\n kladkogex\n\n I have read the description several times, I am not sure though I understand how an exit transaction is verified by the parent blockchain …\n\nIs this correct to say, that to exit you need to have signatures of all owners of intemediate UTXOs … ? And all of these signatures will be verified during the exit? Correct?))\n\nIn this structure if I look at a particular UTXO, it may have two parents, so essentially if I go back N transactions in history for a particular UTXO, I will have 2^N2𝑁 ancestors … ? correct?) Would it mean that the size of the exit proof would grow exponentially as coins exchange hands?)) Or I am missing something ?))\n\n post by vbuterin on Jan 10, 2018\n\n vbuterin\n\n You do not need to provide a proof of the entire history of a UTXO in order to exit with that UTXO; you just need to prove that the UTXO exists and was included. It seems counterintuitive that you need to prove that little, but it works; it relies heavily on the fact that if any user sees an invalid UTXO get in, they need to exit within some timeframe, and make sure to not finalize transfers that were included after that invalid UTXO.\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n Load more posts below","tokens":5201,"squid":"ink-research","role":"Deep Scholar","at":1791265650939,"hash":"e9eac36b683b0a80a0c93cf83219723f4b9fc24d"}
{"url":"https://forum.soliditylang.org/t/license-and-attribution-of-the-solidity-logo/3522/6","domain":"forum.soliditylang.org","title":"License and Attribution of the Solidity Logo? - Documentation - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Documentation\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Oct 2025\n\n 6 / 6\n\n Oct 2025\n\n Oct 2025\n\n post by hwhsu1231 on Oct 12, 2025\n\n 8 days later\n\n post by clonker on Oct 21, 2025\n\n post by hwhsu1231 on Oct 22, 2025\n\n hwhsu1231\n\n Hello, @clonker\nHow about the following attribution?\n\nBy Ethereum Foundation, licensed under CC BY 4.0.\n\nFor example:\n<tr>\n <td><code>mark/solidity-dark.svg</code></td>\n <td><img src=\"mark/solidity-dark.svg\" alt=\"solidity-dark\" width=\"100\"/></td>\n <td><a href=\"https://github.com/argotorg/solidity/blob/11be2f4881d1644f15b026d1022388f06a034a34/docs/_static/img/logo.svg\">Link</a></td>\n <td>By <a href=\"https://ethereum.foundation/\">Ethereum Foundation</a>, licensed under <a href=\"https://creativecommons.org/licenses/by/4.0/\">CC BY 4.0</a>.</td>\n</tr>\n<tr>\n <td><code>mark/solidity-light.svg</code></td>\n <td><img src=\"mark/solidity-light.svg\" alt=\"solidity-light\" width=\"100\"/></td>\n <td><a href=\"https://github.com/argotorg/solidity/blob/11be2f4881d1644f15b026d1022388f06a034a34/docs/_static/img/logo-dark.svg\">Link</a></td>\n <td>By <a href=\"https://ethereum.foundation/\">Ethereum Foundation</a>, licensed under <a href=\"https://creativecommons.org/licenses/by/4.0/\">CC BY 4.0</a>.</td>\n</tr>\n\n post by clonker on Oct 23, 2025\n\n clonker\n\n A better attribution would be `By the Solidity Authors, licensed under CC BY\n4.0`. Solidity recently changed its home from the Ethereum Foundation to the Argot Collective. This phrasing is neutral to organizational changes and matches the official documentation.\n\n post by hwhsu1231 on Oct 25, 2025\n\n hwhsu1231\n\n If I want to hyperlink ‘the Solidity Authors’, what kind of hyperlink would you suggest? What about the following attribution?\nBy <a href=\"https://www.soliditylang.org/\">the Solidity Authors</a>, licensed under <a href=\"https://creativecommons.org/licenses/by/4.0/\">CC BY 4.0</a>.\n\n post by clonker on Oct 27, 2025\n\n clonker\n\n That’s good! You may want to capitalize the t like The Solidity Authors, I realized I didn’t do it myself in the message. Anyways that attribution works.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Localization of The Solidity Documentation\n\n Documentation\n\n 0\n\n 83\n\n Jun 2\n\n Are there any efforts to improve or standardize translations of Solidity documentation?\n\n Documentation\n\n 2\n\n 149\n\n Jun 2\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 78\n\n May 5\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 55\n\n 26d\n\n Want to read more? Browse other topics in Documentation or view latest topics.","tokens":1520,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265650967,"hash":"e9ac681d6c9017ba174a5920f81b9cce2e5f4ff3"}
{"url":"https://docs.optimism.io/op-stack/introduction/op-stack","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Learn the OP Stack — stop 1 of 14.\nThis is the start of the track; nothing is assumed beyond general\nfamiliarity with Ethereum. This page gives you the mental model: what\nthe OP Stack is and what it powers. When you’re done, continue to\nOP Stack architecture.\nThe OP Stack is the standardized, shared, and open-source development stack\nthat powers Optimism and makes it possible to run a production Layer 2\nblockchain. It is not a single program. It is a set of components that\ntogether produce a chain whose entire history is published to Ethereum, so\nthat anyone can reconstruct and check it.\n​What the OP Stack gives you\nAn OP Stack chain is a rollup: it executes transactions on its own network\nand publishes the data for those transactions to a parent chain, usually\nEthereum. Because the data is published, the chain can be rebuilt by anyone\nfrom the parent chain alone, and Ethereum can be convinced of the chain’s\nstate well enough to release funds back out of it.\nThat arrangement is what produces the properties chains are built on it for:\n\nEVM equivalence. Existing Ethereum contracts and tooling work without\nmodification. The small set of deliberate deviations is documented in\nDifferences from Ethereum.\nCosts far below Ethereum’s. Transactions are executed on L2 and only\ntheir compressed data reaches L1. See\nTransaction fees.\nFast confirmations, backed by Ethereum finality. Blocks arrive in\nseconds; irreversibility follows once the data is finalized on Ethereum.\nSee Transaction finality.\nModularity. Data availability, sequencing, and settlement are separate\nlayers, so a chain can change one without rebuilding the rest.\n\n​What it powers\nThe OP Stack runs OP Mainnet and many other production chains, many of which\nadhere to a standard configuration, contracts, and upgrade process. This\nshared standard is what makes a common toolchain and native OP Stack\ncross-chain interoperability possible.\n​Where to go next\nIf you are working through the learning track, continue in order. Otherwise,\npick the path that matches what you are doing:\n\nThe OP Stack is continuously evolving. The\nOP Stack specifications are the normative\ndefinition of protocol behavior, and the\nOptimism Blog covers new work as it ships.\n​Ready to build your chain?\nWas this page helpful?","tokens":570,"squid":"ink-governance","role":"Council Listener","at":1791265655619,"hash":"09dfca56ea27ec7fa5f583c052e1a8bb3e4212db"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/8","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 8 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 9, 2018\n\n kladkogex\n\n I have read the description several times, I am not sure though I understand how an exit transaction is verified by the parent blockchain …\n\nIs this correct to say, that to exit you need to have signatures of all owners of intemediate UTXOs … ? And all of these signatures will be verified during the exit? Correct?))\n\nIn this structure if I look at a particular UTXO, it may have two parents, so essentially if I go back N transactions in history for a particular UTXO, I will have 2^N2𝑁 ancestors … ? correct?) Would it mean that the size of the exit proof would grow exponentially as coins exchange hands?)) Or I am missing something ?))\n\n post by vbuterin on Jan 10, 2018\n\n vbuterin\n\n You do not need to provide a proof of the entire history of a UTXO in order to exit with that UTXO; you just need to prove that the UTXO exists and was included. It seems counterintuitive that you need to prove that little, but it works; it relies heavily on the fact that if any user sees an invalid UTXO get in, they need to exit within some timeframe, and make sure to not finalize transfers that were included after that invalid UTXO.\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n Load more posts below","tokens":3622,"squid":"ink-research","role":"Deep Scholar","at":1791265661172,"hash":"2e7b099b4f9d49b06d8c6b6eb1a3feb50f2a4795"}
{"url":"https://forum.soliditylang.org/t/pattern-matching-blog-post-released/3703/1","domain":"forum.soliditylang.org","title":"Pattern Matching Blog Post Released - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Pattern Matching Blog Post Released \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by czepluch on May 5\n\n czepluch\n\n Solidity Team\n\n We’ve just released a blog post explaining how pattern matching and ADTs are planned to work in Core Solidity.\nGive it a read and let us know what you think.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 55\n\n 26d\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 146\n\n Apr 27\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1058,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265661253,"hash":"26a3bb498de2712b014b55d4308b3f7cf9e07a38"}
{"url":"https://docs.optimism.io/op-stack/learn","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This track is a guided path through the OP Stack documentation for readers\nwho want to learn the stack from the beginning. It sequences existing pages\ninto fourteen ordered stops: blocks of concept pages punctuated by three\nhands-on projects, so you consolidate each idea by using it before moving on.\nScope: this track takes you from newcomer to comfortable. When you\nfinish, you will have deployed a test chain, followed a transaction from\nsubmission to Ethereum, moved assets in both directions between layers, and\nrun a node, and you will know where each deeper layer of material lives.\nDepth stays out of the track on purpose: exhaustive detail lives in the\nreference sections and the OP Stack specifications,\nand the track exits to them rather than repeating them.\n​How the track works\n\nEvery stop is an existing page. A framing note at the top of each stop\ntells you where you are in the track and links the next stop, so you can\nwalk the whole path without returning here.\nDo the stops in order. Later stops assume the vocabulary and the working\nsetup of earlier ones.\nThe three projects are the point, not a break: each one turns the\nconcepts before it into something running on your machine.\n\nThe track’s design rationale, ownership, and change history live in the\ntrack syllabus.\n​Part 1: Foundations\n\nStop 1. The OP Stack: what the\nstack is and what you can build with it.\nStop 2. OP Stack architecture: the system\nview, covering the components, who runs each, and how a transaction moves\nthrough them.\nStop 3. Design philosophy & principles:\nthe four pillars that explain why the stack is built the way it is.\nStop 4. Differences from Ethereum:\nwhat “EVM equivalent” means in practice and the small set of behaviors\nthat differ.\nStop 5. OP Stack components: the\nconceptual layers of the stack and the software modules that fill them.\n\n​Project 1: Deploy your own chain\n\nStop 6. Creating your own L2 rollup testnet:\ndeploy a rollup testnet with op-deployer and start each component\nyourself. A multi-part series; work through every part before\ncontinuing.\n\n​Part 2: Transactions and bridging\n\nStop 7. Transaction flow:\nhow a transaction moves through the components you just ran, from\nsubmission to finality on Ethereum.\nStop 8. Transaction fees on OP Mainnet:\nthe fee components of an OP Stack transaction and what determines each\none.\nStop 9. Deposit flow: how a\ntransaction triggered on L1 becomes an L2 transaction.\nStop 10. Withdrawal flow: the\ninitiate, prove, and finalize steps that move a transaction from L2\nback to L1.\n\n​Project 2: Bridge in both directions\n\nStop 11. Submitting transactions from L1:\nwalk a deposit and a withdrawal end to end from code, using Viem.\n\n​Part 3: Security and the Superchain\n\nStop 12. Fault proofs explainer:\nhow anyone can permissionlessly propose and challenge the state\nproposals that withdrawals depend on.\nStop 13. OP Stack interoperability explainer:\nhow the OP Stack is evolving so a network of chains can feel like a\nsingle blockchain.\n\n​Capstone: Run a node\n\nStop 14. Running a node with Docker:\nrun an OP Stack node with the official Docker images and watch it sync\na live network.\n\n​After the track\nThe track ends where the deep material begins. Depending on what you want\nto do next:\n\nOperate or tune a chain: the use case guides\nsequence cross-layer operator journeys, and the Chain Operators tab\nholds the full guides and reference.\nBuild applications: the App Developers tab covers bridging,\ninteroperability, and transactions at working depth.\nUnderstand the protocol precisely: the\nderivation pipeline page goes\none level deeper, and the\nOP Stack specifications are the normative\ndefinition of protocol behavior.\n\n​Next steps\n\nStart the track at stop 1: The OP Stack.\nMaintainers: the track is governed by the\ntrack syllabus and swept on\nthe cadence in the curation review policy.\nWas this page helpful?","tokens":968,"squid":"ink-governance","role":"Council Listener","at":1791265665489,"hash":"cdf4de302ca0d0d4e02d877b5aa83b724957c365"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/10","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 10 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n vbuterin\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n Load more posts below","tokens":3464,"squid":"ink-research","role":"Deep Scholar","at":1791265671388,"hash":"cafd34369f06d47a6e5b22f2d9a7c7d850a0a2a4"}
{"url":"https://forum.soliditylang.org/t/solidity-developer-survey-2025-results/3698/1","domain":"forum.soliditylang.org","title":"Solidity Developer Survey 2025 Results - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solidity Developer Survey 2025 Results \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 16\n\n 1 / 3\n\n Apr 16\n\n Apr 27\n\n post by czepluch on Apr 16\n\n czepluch\n\n Solidity Team\n\n The results from our sixth annual developer survey are live. 1,095 developers from 87 countries responded.\nThe full interactive report has 60 charts covering demographics, tooling, pain points, AI usage, Core Solidity, and cross-analysis by experience level: Solidity Developer Survey 2025 Results | Solidity Programming Language\nA few things that stood out:\n\nStack-too-deep remains the #1 pain point, and it hits experienced developers hardest (65% of experts vs 25% of beginners)\n88% use AI tools at least monthly, but 45% express distrust in the output\nFoundry grew from 51% to 57%. One Truffle user remains.\nOnly 30% of respondents are familiar with Core Solidity\n73% say DevEx has improved (up from 67% in 2024)\nDebugging is painful across all experience levels, regardless of tooling\n\nOur takeaways and what we’re doing about it (including the SSA CFG codegen that eliminates stack-too-deep): Solidity Developer Survey 2025 Results | Solidity Programming Language\nThe raw data (CSV) is available for download from the interactive report page.\nWe’d love to hear your thoughts. If anything in the results surprises you, or if you have feedback on how we can improve the survey next year, this thread is a good place for that.\n\n 2\n\n post by nebojsakonsta on Apr 24\n\n nebojsakonsta\n\n When are you guys doing 2026 survey? Would love to see how landscape is changing.\n\n post by czepluch on Apr 27\n\n czepluch\n\n Solidity Team\n\n End of the year. We got started a bit late for 2025, so the results only got out in 2026.\nWe expect to run the next survey November/December 2026.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 55\n\n 26d\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1427,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265672925,"hash":"025748bb887a17390f29a20b3c34e54ce1a84f2a"}
{"url":"https://app.optimism.io/bridge/deposit","domain":"app.optimism.io","title":"Optimism Bridge","text":"Welcome to the Optimism bridgeWe will NEVER ask you for your private keys or seed phrase.This is beta software subject to change. For guidance, refer to our documentation and security model.By clicking the button below, you agree to the Terms of Service and Optimism Community Agreement.Optimism BridgesBridge to and from anywhere between OP Stack chainsSuperbridgeBy Blob EngineeringLet's goExplore more bridgesCheck out other bridges being built on the OP Stack.These are independent, third-party service providers that Optimism is linking to for your convenience - Optimism has no responsibility for their operation.FAQOptimism is leaning on its ecosystem to bootstrap access to the protocol. Not running our own frontend increases decentralization and also helps us bootstrap a distributed ecosystem.Visit Optimism","tokens":205,"squid":"ink-governance","role":"Council Listener","at":1791265675976,"hash":"2f06418745ed896e0f2dedebc8afadc20d4f5481"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/12","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 12 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n Load more posts below","tokens":3170,"squid":"ink-research","role":"Deep Scholar","at":1791265681617,"hash":"8b0f6c15268a52a51c7e742fc0e02e9fc0789511"}
{"url":"https://www.optimism.io/community-agreement","domain":"optimism.io","title":"Optimism Community Agreement","text":"Optimism Community AgreementLast updated: August 8, 2024Hello, Optimist!Please carefully read this entire document, which is a legal agreement between you and the Optimism Foundation (the “Foundation”, “we”, “our” or “us”) and contains important information about:OP Mainnet (the Ethereum layer 2 scaling protocol that we help steward),the open-source development stack that powers OP Mainnet (the “OP Stack”),other blockchain protocols built on the OP Stack (“Other OP Chains/Forks”),the Optimism Collective (the community governance body of OP Mainnet and Other OP Chains/Forks that join the Superchain),the Foundation, andother important things.By interacting with OP Mainnet or any Other OP Chain/Fork in any way, or accessing or using Optimism.io, the OP Stack, or any product or service made available by the Foundation, you agree to this Agreement, which includes legal disclaimers, as well as our Terms of Service. Please read this entire Agreement and the Terms of Service carefully.1. OP MAINNET, OTHER OP CHAINS/FORKS, THE OP STACK, THE OPTIMISM COLLECTIVE, AND THE OPTIMISM FOUNDATIONOP Mainnet is a public, internet-based blockchain computing platform. It is configured to inherit permissionless-ness, decentralization, and security attributes from another blockchain computing platform, Ethereum. Because of this configuration, OP Mainnet is referred to as a “Layer 2” blockchain computing platform.OP Mainnet and the suite of open source code (including the OP Stack), tooling, infrastructure, and governance systems underlying it are composed of many different and evolving components, which are contributed, used, and supported by a wide variety of participants. These participants, ranging from developers to node operators, creators to token holders, and builders to web3 enthusiasts and beyond, comprise the Optimism community (the “Optimism Collective”). Other OP Chains/Forks may incorporate the OP Stack to varying degrees, and may or may not share the properties of OP Mainnet to varying degrees.OP Mainnet, Other OP Chains/Forks that join the Superchain, and the OP Stack grow and change through the efforts of the Optimism Collective. The Optimism Collective is represented by a bicameral community organization, jointly governed by holders of the ‘OP’ token and Optimism citizens, and stewarded by the Foundation.The Foundation currently contributes to the Optimism Collective. Among other things, the Foundation contributes to the continuing development and maintenance of OP Mainnet, certain Other OP Chains/Forks, and the OP Stack by making, maintaining, facilitating, publicizing or otherwise working on or encouraging:Community education and involvement.Procedural and administrative support of Optimism Collective governance.Allocations and delivery of community grants.The Optimism.io website.The OP Stack and other software, smart contracts, APIs, and utilities, including the Gateway Interface and AttestationStation front ends that interact with OP Mainnet and/or certain Other OP Chains/Forks smart contracts.Data processing for the network and operating one or more nodes.Written, video, and other content on our website, various social media platforms and elsewhere.Generally being a resource to the community in a variety of other ways.All of the above software, content and activities are referred to in this notice as our “Software, Content, and Activities.” Sometimes we are paid in connection with our Software, Content, and Activities. Other times we are not. We are a foundation company organized under the laws of the Cayman Islands.2. OTHER IMPORTANT INFORMATION AND RISKSWhen interacting with OP Mainnet, an Other OP Chain/Fork, the OP Stack or our Software, Content, and Activities, please keep the following points in mind:We do not control OP Mainnet or any Other OP Chain/Fork. OP Mainnet and Other OP Chain/Forks (generally) are Ethereum Layer 2s, meaning that the canonical state of its blockchain can, at any time, be derived (by anyone) from information embedded in existing blocks on the Ethereum blockchain. Moreover, the latest governance-approved version of the OP Stack and the OP Mainnet protocol can only be validly upgraded through governance decisions by the Optimism Collective. We do not control Ethereum or the Optimism Collective, and you should not rely on us (or any other party) to control OP Mainnet or any Other OP Chain/Fork that joins the Superchain. For the above reasons and others, we do not, and cannot, do so. Moreover, because the OP Stack enables anyone to create an Other OP Chain/Fork without needing the involvement of the Foundation, the existence of an Other OP Chain/Fork does not indicate, imply, or require any involvement or responsibility of the Foundation.OP Mainnet and the OP Stack are works in progress. They are built on new and evolving technology. Their codebase has been audited, but it still may contain unknown bugs. In addition, the security of OP Mainnet is currently dependent on a multisignature wallet, managed by the participants of the Optimism governance-approved Security Council, which can be used to maliciously upgrade core OP Mainnet smart contracts without upgrade delays or the approval of the Optimism Collective. This introduces various risks, including the loss of some or all of the assets held within the system.Do your own research before using or engaging with OP Mainnet or any Other OP Chain/Fork. Be careful and always do your own due diligence before engaging with any component of OP Mainnet or any Other OP Chain/Fork, regardless of who built or implemented it. Read widely. Stay on top of updates and developments. Be curious. Don’t leave any stone unturned, and don’t assume that something is correct or will function a certain way without independently verifying.When you use OP Mainnet, any Other OP Chain/Fork, the OP Stack, or any of our other Software, Content, and Activities, it is at your own risk. This includes risks specific to them and the risks inherent in using any cryptographic or blockchain-based system (such as wallet and private key management, variable transaction costs and speeds, technological vulnerabilities, cryptographic attack vectors, and risks relating to digital assets). You should not use any of these unless you have sufficient knowledge to understand, accept, and manage all the risks.… this includes the risk of loss of your wallet private keys and seed phrases. You are solely responsible for securing the wallet private keys and seed phrases you use to store and transfer assets on OP Mainnet and any Other OP Chain/Fork. It is your responsibility to avoid losing them or sharing them with anyone else. Once lost, there may be nothing that can be done to recover access to your wallet or to otherwise provide you with recourse.We may (but will not be obligated to) take or authorize certain actions to attempt to mitigate critical security vulnerabilities and protect the community. Although your use of any OP Chain is entirely at your own risk, we may in certain instances take (or authorize others to take) steps to protect the community (“Mitigation Efforts”), although we will not have any obligation to do so. If a critical security vulnerability is discovered, pausing the protocol (“Pausing” or a “Pause”) may be a potentially effective way to mitigate immediate harms. Because of the need to act quickly in such situations, Pausing (but not unpausing) may be pre-signed, meaning it may not be subject to the normal procedures of OP Mainnet or the Other OP Chain/Fork. For the same reason, the unilateral ability to Pause may be delegated to trusted third parties. Pausing may temporarily interfere with your ability to access your assets or otherwise use or interact with OP Mainnet or an Other OP Chain/Fork, and may have other longer-term effects on OP Mainnet or the Other OP Chain/Fork, and your assets, including an effect on value. You acknowledge and agree that Pausing is a reasonable way (among others) to attempt to mitigate security vulnerabilities but that Pauses or other Mitigation Efforts may or may not be implemented and may not successfully mitigate security vulnerabilities if they are implemented, and that the risks associated with Pausing and other Mitigation Efforts are among the risks you assume when you use OP Mainnet or an Other OP Chain/Fork and are covered by the waiver and disclaimer of liability in Section 3, below.We are not, do not speak for, and cannot bind, the Optimism Collective. The Optimism Collective is a collection of independent contributors to the Optimism project. The Foundation is a separate, independent entity. While we currently do work to steward the Optimism Collective and its mission, we do not speak for the Optimism Collective, and cannot contractually bind it in any manner. Unless we say otherwise in writing, the individual conduct of participants in the Optimism Collective are not covered, or endorsed by, the Foundation in any way.We do not endorse third parties or third-party information. Any time we link to, quote or otherwise reference a third party or reproduce or incorporate their information, content or material, it is solely for informational purposes. You should not assume that we have verified the accuracy of, or endorse in any way, such information, content, or materials. We may have a financial interest in some of the third-parties or projects we link to, reference, or promote.You are responsible for your own compliance. We attempt to comply with applicable laws, rules, and contractual obligations with respect to all of our Software, Content, and Activities. However, that landscape is constantly changing and differs jurisdiction by jurisdiction. It is your responsibility to conduct your own inquiry to ensure that your activity on OP Mainnet and any Other OP Chain/Fork complies with all applicable laws, rules, and contractual obligations.When we talk about future ideas or prospects, we are expressing our vision and hopes, and there is no commitment or guarantee that it will come true, that we will implement any of it, or that it will work. The world changes quickly and technology at an even faster pace. We have no idea how things will turn out and our aspirations and predictions may be unreliable. Look carefully at the date of things because after that date, things might have changed (a lot).You should not rely on us for any specific future work. The Foundation aims to make technical and governance contributions that allow the Foundation to further and progressively decentralize its role over time. We happily contribute to the Optimism community today, but we are also proud to pursue a world where this community does not need us in order for it to continue to thrive tomorrow. That’s the whole point of a public, open source, blockchain-based system governed by a decentralized Collective.While the above is not an exhaustive list of potentially relevant considerations, we hope you find it, and the other content of this Agreement, helpful. Please save a copy of this Agreement for your records. It may be modified from time to time – at which point we’ll post an updated version and identify the date of the latest update at the top of this page. Your accessing, interaction with, or use of OP Mainnet, any Other OP Chain/Fork, the OP Stack, or any of our Software, Content, and Activities following such posting will constitute your agreement to the updated version.3. DISCLAIMERS AND LIMITATIONS OF LIABILITYWe work in the open, guided by an open source ethos, with products on the bleeding edge of what we believe to be a technological revolution in decentralized computation. This is a fundamentally experimental enterprise.THE FOUNDATION MAKES NO REPRESENTATION, WARRANTY, GUARANTEE, OR UNDERTAKING REGARDING OP MAINNET, ANY OTHER OP CHAIN/FORK, THE OP STACK OR ANY OF OUR OTHER SOFTWARE, CONTENT, AND ACTIVITIES, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF COMPLIANCE, ACCURACY, RELIABILITY, VALIDITY, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, QUALITY, AVAILABILITY, DURABILITY, AND NONINFRINGEMENT, OR AS TO ANY OF THEM BEING UNINTERRUPTED, ERROR FREE, FREE OF HARMFUL COMPONENTS, COMPLIANT WITH LAWS, OR SECURE, AND THE FOUNDATION WILL NOT BE LIABLE IN CONNECTION WITH YOUR USE OR RELIANCE ON THEM.THE FOUNDATION DOES NOT OWN, OPERATE OR CONTROL OP MAINNET OR ANY OTHER OP CHAIN/FORK, EACH OF WHICH IS PUBLIC, PERMISSIONLESS, AND RUNS ON SELF-EXECUTING SMART CONTRACTS. THE OP STACK, OP MAINNET, OTHER OP CHAINS/FORKS, AND OUR SOFTWARE, CONTENT, AND ACTIVITIES MAY CONTAIN BUGS, ERRORS, DEFECTS, OR VULNERABILITIES AND MAY BE SUSCEPTIBLE TO CYBERATTACKS. YOU AGREE THAT YOU ASSUME ALL RISKS IN CONNECTION WITH USING, CONNECTING A WALLET TO, OR OTHERWISE INTERACTING WITH OP MAINNET OR ANY OTHER OP CHAIN/FORK, OR USING THE OP STACK OR ANY OF OUR OTHER SOFTWARE, CONTENT, AND ACTIVITIES.YOU FURTHER EXPRESSLY (I) WAIVE AND RELEASE ANY AND ALL CLAIMS, ACTIONS, PROCEEDINGS, CAUSES OF ACTION, EXPENSES, LIABILITIES, AND DAMAGES (COLLECTIVELY, “CLAIMS”) YOU MAY HAVE AGAINST THE FOUNDATION AND/OR ANY OF ITS AFFILIATES, SERVICE PROVIDERS AND/OR LICENSEES, ITS AND THEIR RESPECTIVE PAST, PRESENT AND FUTURE OFFICERS, DIRECTORS, MEMBERS, EMPLOYEES, CONTRACTORS, REPRESENTATIVES AND AGENTS, AND/OR SUCCESSORS AND ASSIGNS OF ANY OF THE FOREGOING (COLLECTIVELY, THE “FOUNDATION PARTIES”) ARISING FROM OR IN ANY WAY RELATING TO THE OP STACK, OP MAINNET, ANY OTHER OP CHAIN/FORK, ANY OF OUR SOFTWARE, CONTENT, AND ACTIVITIES, AND ANY MITIGATION EFFORTS RELATED TO ANY OF THE FOREGOING, AND (II) AGREE TO INDEMNIFY, DEFEND, AND HOLD HARMLESS THE FOUNDATION PARTIES FROM AND AGAINST ANY AND ALL CLAIMS ARISING FROM OR IN ANY WAY RELATING TO YOUR FRAUD, WILLFUL MISCONDUCT, GROSS NEGLIGENCE OR VIOLATION OF APPLICABLE LAW OR THIS AGREEMENT. THE FOUNDATION PARTIES ARE EXPRESSLY-INTENDED THIRD-PARTY BENEFICIARIES OF THIS PARAGRAPH WITH THE RIGHT TO DIRECTLY ENFORCE IT WITH RESPECT TO YOU.4. MISCELLANEOUSYou agree that any dispute, claim, or request for relief relating in any way to this Agreement will be subject to the Arbitration Agreement in Section 16 of the Terms of Service. This Agreement is governed by and will be construed under the laws of the Cayman Islands, excluding its body of law controlling conflict of laws. If any provision of this Agreement is held by a court or other tribunal of competent jurisdiction to be invalid, illegal, or unenforceable for any reason, such provision shall be limited to the minimum extent such that the remaining provisions of this Agreement will be enforceable and continue in full force and effect. You agree that any judicial proceeding will be brought in the courts located in the Cayman Islands.","tokens":3694,"squid":"ink-governance","role":"Council Listener","at":1791265686170,"hash":"8dae3dd5c1d36a7ef6a64271957fe87a9f9559b9"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/14","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 14 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n kladkogex\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n Load more posts below","tokens":3087,"squid":"ink-research","role":"Deep Scholar","at":1791265691872,"hash":"df44927bb7b4f58ff6ca63a24f1d578ca5252bdf"}
{"url":"https://www.soliditylang.org/blog/2026/04/15/solidity-developer-survey-2025-results/","domain":"soliditylang.org","title":"Solidity Developer Survey 2025 Results | Solidity Programming Language","text":"Solidity Developer Survey 2025 ResultsPosted by Solidity Team on April 15, 2026AnnouncementsThe Solidity Developer Survey 2025, our sixth annual survey, collected 1,095 responses from developers across 87 countries. Thank you to everyone who participated. This post covers the key findings. For the complete data, see the interactive results page.\nWho responded\n\n70% of respondents are smart contract developers. 12% are auditors or security experts. 18% identified as students. Half of all respondents have two years or less of Solidity experience, and 49% use Solidity daily.\nThe top three countries are India (205), Nigeria (148), and the United States (83). 74% of respondents are between 18 and 34 years old.\nTooling\nFoundry is the most used primary framework at 57%, up from 51% in 2024. Hardhat accounts for 33% combined (v3 at 18%, v2 at 15%). Truffle dropped from 2.4% in 2024 to a single remaining user. Remix is the most used secondary framework at 41%.\nethers.js is the most used Ethereum SDK (70%), followed by viem (39%) and wagmi (33%).\n\nPain points\nStack-too-deep errors are the most reported recurring issue (47%), followed by bytecode size limits (33%) and debugging (33%). 23% of respondents report no recurring issues.\nThese issues correlate with experience level. Stack-too-deep is reported by 25% of beginners (self-rated 1-4) compared to 65% of experts (self-rated 8-10). Bytecode size limits follow a similar pattern at 17% vs 47%. Debugging is consistent across all levels at 29-35%.\n\nThe most requested near-term feature is better gas optimizations (44%), followed by EIP-712 typehash support (29%) and reference types in transient storage (23%).\nAI adoption\n88% use AI tools at least monthly, 58% daily. But 45% express distrust in the output. Developers are adopting AI faster than they are learning to trust it.\n\nThe most common AI use cases are testing (61%), documenting code (59%), and learning about codebases (58%). Writing code (49%) and reviewing code (49%) are lower.\n49% somewhat trust AI output, 30% somewhat distrust it, 15% highly distrust it, and only 6% highly trust it. Among daily AI users specifically, 36% express distrust.\n\nCore Solidity\nOnly 30% of respondents who answered this question are familiar with Core Solidity. If you're new to it, The Road to Core Solidity provides an introduction, and the Core Solidity Deep Dive goes into the technical details.\n\nAmong those who are, the most selected features are better error handling / try-catch replacement (43%) and better delegatecall / library replacement (41%).\n63% say removing inheritance would cause challenges for their projects. 44% estimate rewriting their codebase to use type classes or traits would be somewhat difficult, 21% very difficult.\nIn free-text responses, 21% are supportive, 23% are cautious, and 21% express concern about language fragmentation.\nYear-over-year changes\nCompared to the 2024 survey (684 responses):\n\nFoundry usage increased from 51% to 57%\nSourcify usage grew from 17% to 24%, and awareness improved (48% don't know about it, down from 56%)\nIR pipeline awareness improved: 35% don't know what it is, down from 46%\nDevEx sentiment improved: 73% report improvement, up from 67% in 2024\n\nRecurring issue percentages decreased across the board (stack-too-deep from 68% to 47%, debugging from 55% to 33%), though the question format changed between years (single multi-select field in 2024 vs separate checkboxes in 2025), which may account for some of the difference.\nKey takeaways\nStack-too-deep and bytecode size limits hit experienced developers hardest. 65% of experts report stack-too-deep vs 25% of beginners. Bytecode size follows the same pattern at 47% vs 17%. These aren't beginner complaints - they're the ceiling that experienced developers hit when their codebases grow.\nThe optimizer forces developers to write worse code. Free-text responses consistently describe how gas optimization incentivizes bad patterns: inlining instead of abstracting, reusing variables instead of naming them clearly, recalculating values instead of storing them. The language pushes developers away from clean code.\nDevelopers adopt AI faster than they trust it. 88% use AI tools at least monthly, but 36% of daily users express distrust in the output. For a language securing billions in value, the gap between adoption and trust in AI-generated code is worth paying attention to.\nCore Solidity has a visibility and communication problem. 70% of respondents who answered this question don't know what it is. Among those who do, feedback is genuinely split: support alongside real concerns about fragmentation, backward compatibility, and the language becoming too abstract. The conversation hasn't reached enough people yet.\nDebugging is universally painful regardless of experience or tooling. It's the one pain point that doesn't improve with experience (29-35% across all levels). Foundry is at 57% and growing, but better frameworks haven't solved the debugging problem.\nWhat we're doing about it\nStack-too-deep: This remains the top pain point. The v0.8.35-pre.1 pre-release introduces the SSA CFG codegen behind the new --experimental flag, which eliminates stack-too-deep errors. A stable release will follow.\nCore Solidity awareness: Only 30% of respondents who answered this question are familiar with Core Solidity. We're ramping up communication: a blog post on pattern matching is coming next week, and a Core Solidity Playground will be available before the end of summer. We're also ramping up our presence at conferences, engagement with ecosystem players, and collaboration with the community to define the Standard Library for Core Solidity.\nDebugging: Debugging was reported as painful across all experience levels. Work on ethdebug, a standard debugging data format for smart contracts on EVM-compatible networks, is actively in progress.\nBytecode size limit: The second most common pain point among experienced developers. There is an EIP in progress to increase the contract size limit.\nDocumentation: The survey responses helped prioritize what to focus on next in the docs. We plan to add more practical examples, particularly around proxies, storage layout, and gas optimization. Translating the documentation to more languages will also be a priority.\nFull results\nThe interactive report covers all 60 survey questions with charts, descriptions, and respondent quotes.\n\nInteractive results with all 60 charts\nDownload the raw data (CSV)\n2024 survey results\n2023 survey results\n\nThank you to everyone who participated, and to the projects and community members who helped spread the word and increase the survey's reach. As a reminder, we put up a Devcon 8 ticket for a random draw among survey participants. The winner can expect an email from us soon. Please verify the sender address matches an @argot.org email.\nIf you have additional feedback, the best place to share it is the Solidity Forum.Previous postNext post","tokens":1744,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265693288,"hash":"6a8e61e046be2afbbeb4ec8d52a6e20087fb0f88"}
{"url":"https://optimism.io/terms","domain":"optimism.io","title":"Terms of Service - Optimism","text":"Terms of ServiceLast updated: March 5, 2024Thank you for your interest in Optimism! The Optimism Foundation (the “Foundation”, “we”, “our” or “us”) provides this website, its features, and certain other products and services (collectively, our “Services”) as identified and further described in these Terms of Service (the “Terms”).Your use of our Services is subject to and governed by these Terms. Please read all of these Terms carefully, as they include legal terms, obligations, and restrictions. They cover important information about the Services, eligibility to use the Services, future changes to these Terms, disclaimers, and limitations of liability, including that you assume all risk associated with using the Services.By accessing or using any Service or interacting with OP Mainnet or any other blockchain built using the OP Stack (“Other OP Chains/Forks”), you agree to these Terms and the Optimism Community Agreement, which you understand applies to all uses of OP Mainnet and any Other OP Chain/Fork, in addition to this website and its features, and you acknowledge and consent to our Privacy Policy. In addition, certain pages, features, products, or services may be subject to additional guidelines, terms, or rules, which will be posted in connection with such features and product offerings. All such additional terms, guidelines, and rules are incorporated by reference into these Terms. Your agreement to these Terms and the Optimism Community Agreement (on behalf of yourself and, if applicable, the entity you represent) forms a binding contract between you and us (and, if applicable, the entity you represent), and you represent and warrant that you have the willingness, right, authority, and capacity to enter into these Terms (on behalf of yourself and, if applicable, the entity you represent). You are not authorized to and must not use the Services if you do not wish to, or do not have capacity to, agree or consent to any of the above.Key Terminology:“OP Mainnet” means the decentralized, peer-to-peer layer 2 rollup protocol on the Ethereum public blockchain with chain ID: 10 known as “OP Mainnet.”“OP Stack” means the Optimism Collective-approved, standardized, shared, and open-source development stack release that powers OP Mainnet and other blockchain protocols.“Optimism Collective” means the decentralized, representative body of Optimism governance, as further described in the Optimism Community Agreement.Authority to Bind Organization or Entity You Represent: If you are agreeing to the Terms on behalf of an organization or entity, you represent and warrant that you are authorized to agree to the Terms on that organization’s or entity’s behalf and bind them to the Terms (in which case, the references to “you” and “your” in the Terms, except for in this sentence, refer also to that organization or entity).Eligibility to Use Services; Consent of Parent or Legal Guardian: You may only access or use the Services if you are an individual of legal age to form a binding contract (or if not, you have received your parent’s or guardian’s permission to use the Services and your parent or guardian has agreed to the Terms on your behalf). If you are accepting these Terms on behalf of a minor, you represent that you are their parent or legal guardian with the legal authority to do so and confirm that you consent to their use of the Services, you agree to these Terms on your and their behalf, and you agree to bear responsibility for their use of the Services.AGREEMENT TO ARBITRATE: SECTION 16 OF THESE TERMS CONTAINS AN ARBITRATION AGREEMENT WHICH WILL, WITH LIMITED EXCEPTIONS, REQUIRE DISPUTES BETWEEN YOU AND US TO BE SUBMITTED TO BINDING AND FINAL ARBITRATION. UNLESS YOU OPT OUT OF THE ARBITRATION AGREEMENT, (A) YOU WILL ONLY BE PERMITTED TO PURSUE CLAIMS AND SEEK RELIEF AGAINST US ON AN INDIVIDUAL BASIS, NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY CLASS OR REPRESENTATIVE ACTION OR PROCEEDING, AND (B) YOU ARE AGREEING TO MANDATORY INDIVIDUAL ARBITRATION FOR THE RESOLUTION OF DISPUTES AND WAIVING YOUR RIGHT TO A JURY TRIAL ON YOUR CLAIMS.Changes to Terms: We reserve the right to change these Terms at any time. If we do so, we will post an updated version of the Terms and indicate at the top of the updated version the date on which these Terms were last updated. If you don’t agree to the new Terms, you are free to reject them; unfortunately, that means you must stop accessing or using the Services immediately. If you access or use the Services in any way after an updated version of the Terms is posted, you agree to all the changes.If you have any questions, comments, or concerns regarding these Terms or the Services, you may send an email to legal@optimism.io.1. ServicesOur Services currently include:Website: The website available at www.optimism.io (the “Site”).Optimism Gateway Interface: The Optimism Gateway Interface, a website-hosted user interface (the “Gateway Interface”) that enables you to connect a compatible non-custodial software wallet (“Web3 Wallet”) and initiate messages to the OP Mainnet, and to bridge digital assets between the Ethereum and OP Mainnet public blockchains, and between OP Mainnet and certain other public blockchains. The Gateway Interface (also known as the ‘Bridge Front-End’) is available here. Depending on how you use the Gateway Interface, (i) these messages may be sent directly to Ethereum, OP Mainnet or other public blockchains or routed through various third-party interfaces and decentralized applications, and (ii) the bridging smart contracts with which you interact may be inherent to Ethereum, OP Mainnet, or other public blockchains themselves, or independently developed and deployed by various third parties (“Third-Party Bridges”).Optimist NFTs, PFPs and AttestationStation: The ability, if you are eligible, to connect your compatible Web3 Wallet to OP Mainnet and mint non-fungible tokens (“Optimist NFTs”) with customized profile pictures (“PFPs”) and interact with certain related smart contracts deployed on OP Mainnet (collectively, the “Optimist NFT Service”). When you mint an Optimist NFT, your Optimist NFT will be permanently linked to your wallet address and will not be transferable, and other users will be able to use the attestation smart contract deployed on OP Mainnet known as the “AttestationStation” (which you can read more about here) to post permanent, publicly available attestations about, among other things, your Optimist NFT. When you or others submit information or attestations in minting an Optimist NFT or using the AttestationStation, you and they are interacting directly with OP Mainnet and smart contracts deployed on OP Mainnet and entering that information into an on-chain permanent repository, where it will be publicly accessible and cannot be deleted.For clarity, the Foundation does not own or control, and the Services do not include, (i) OP Mainnet, which is public, permissionless, and runs on open-source self-executing smart contracts, (ii) any Other OP Chain/Fork, (iii) the Optimism Collective, or (iv) any Web3 Wallet.The Foundation reserves the right, at any time, to modify, suspend, or discontinue any Service (in whole or in part) without notice to you. You agree that the Foundation will not be liable to you or to any third party for any modification, suspension, or discontinuation of any Service or any part thereof. The Foundation does not undertake or have any obligation to maintain any Service or provide support to you in connection with your use of any Service.2. Web3 WalletsTo access certain Services, you must use a Web3 Wallet, which constructs and broadcasts the data (“transactions”) that allows you to interact with Ethereum, OP Mainnet, or any Other OP Chain/Fork (as applicable). By using your Web3 Wallet in connection with a Service, you acknowledge and agree that you are using the Web3 Wallet under the terms and conditions of the applicable provider of the Web3 Wallet. No Web3 Wallet is created by, operated by, maintained by, or affiliated with us. Accordingly, we do not have custody or control over the contents of your Web3 Wallet, and we have no ability to retrieve, transfer or recover its contents. Your relationship with any given Web3 Wallet provider is governed by the applicable terms of service of that third party, not these Terms.3. LicenseSubject to the Terms and your compliance with the Terms, the Foundation grants you a non-transferable, non-exclusive, non-sublicensable, personal, revocable, limited license to access and use the Services solely for your own personal, non-commercial use.4. Prohibited ConductYou represent, warrant, and agree that you will not provide or contribute anything to the Services, including without limitation by submitting any attestation to the AttestationStation, or otherwise use or interact with any Service, in a manner that:infringes or violates the intellectual property rights or any other rights of anyone else (including us);violates any law, rule or regulation (collectively, “Law”), including, without limitation, any applicable sanctions Laws, export control Laws, securities Laws, anti-money laundering Laws, or privacy Laws;is for a purpose not reasonably intended by us;is dangerous, harmful, fraudulent, misleading, deceptive, threatening, harassing, defamatory, obscene, or otherwise objectionable;violates, compromises, or interferes with the security, integrity or availability of any computer, network, software, or technology; orotherwise violates the Terms or the Optimism Community Agreement.5. Additional RestrictionsYou agree that the rights granted to you in these Terms are subject to the following restrictions:You shall not have any right to, and shall not, license, sell, rent, lease, transfer, assign, distribute, host, or otherwise commercially exploit any Service, whether in whole or in part, or any content accessible on any Service (except, with respect to PFP images, to the extent permitted by Section 9(b));You shall not modify, make derivative works of, disassemble, reverse compile or reverse engineer any part of any Service (except, with respect to PFP images, to the extent permitted by Section 9(b));You shall not access or use the Services to build a similar or competitive website, product, or service; andYou shall not remove or obscure any copyright or other proprietary notices on or presented through the Services (or on any content accessible on the Services).We reserve the right to take whatever action we deem appropriate, including but not limited to terminating or suspending your right and ability to use a Service, if we suspect you have violated Section 4 or this Section 5.6. Legal ComplianceYou will comply with all Laws that apply to you, your access to and use of the Services, and your actions and omissions that relate to the Services. If your access to or use of any Service (whether generally or for a particular purpose) is prohibited by any Law, then you are not authorized to access or use that Service (generally or for the particular purpose, as applicable). We are not responsible for your accessing or using the Services, including in any way that breaks any Law.Without limiting the foregoing, you represent, warrant, and covenant that you are not, and for the duration of the time you use the Services, will not be: (a) the subject of economic or trade sanctions administered or enforced by any governmental authority or otherwise designated on any list of prohibited or restricted parties (including but not limited to the United Nations Security Council, the European Union, His Majesty’s Treasury, and U.S. Department of Treasury), or (b) a citizen, resident, or organized in a jurisdiction or territory that is the subject of comprehensive country-wide, territory-wide, or regional economic sanctions by the United Nations, European Union, any EU country, UK Treasury, or the United States. If at any point the above is no longer true, you must immediately cease using the Services.7. Assumption of RiskBy using the Services, you (a) represent that you are sophisticated enough to understand the various inherent risks of using cryptographic and public blockchain-based systems, including but not limited to the Gateway Interface, OP Mainnet, Other OP Chains/Forks, and digital assets such as bitcoin (BTC), ether (ETH), and other digital tokens such as those following the ERC-20 Ethereum token standard, and (b) acknowledge and accept all such risks, and acknowledge and agree that we make no representations or warranties (expressly or implicitly) regarding, and that you will not seek to hold us liable for, those risks, any or all of which could lead to losses and damages, including the total and irrevocable loss of your assets. Such risks include, but are not limited to, for example:Experimental nature. The Services are experimental in nature. They represent an example reference implementation only. The Services are not intended to be used as a primary means of accessing or interacting with OP Mainnet.Wallet security and safekeeping. You are solely responsible for the safeguarding and security of your Web3 Wallets. If you lose your wallet seed phrase, private keys, or password, you may be forever unable to access your digital assets. Any unauthorized access to your wallet by third parties could result in the loss or theft of your digital assets. We have no involvement in, or responsibility for, storing, retaining, securing, or recovering your Web3 Wallet seed phrases, private keys, passwords, or digital assets, or for any unauthorized access to your Web3 Wallet.Blockchain technology. Public blockchains, and the technology underlying and interacting with cryptographic and public blockchain-based systems, are experimental, inherently risky, and subject to change. Among other risks, bugs, malfunctions, cyberattacks, or changes to a particular public blockchain (e.g., via forks) could disrupt these technologies irreparably. There is no guarantee that any of these technologies will not become unavailable, degraded, or subject to hardware or software errors, operational or technical difficulties, denial-of-service attacks, other cyberattacks, or other problems requiring maintenance, interruptions, delays, or errors.Network cost and performance. The cost, speed, and availability of transacting on public blockchain systems are subject to significant variability. There is no guarantee that any transfer will be confirmed or transferred successfully or in a timely manner.Blockchain transactions and smart contract execution. Public blockchain-based transactions (including but not limited to transactions automatically executed by smart contracts) are generally considered irreversible when confirmed. Any transaction that will interact with smart contracts or be recorded on a public blockchain must be recorded with extreme caution.Digital assets. You own and control the digital assets held in and bridged via your Web3 Wallet. You bear all risk of loss of and relating to such digital assets, including but not limited to fluctuations in value. The markets for digital assets are nascent and highly volatile due to various risk factors including (but not limited to) adoption, speculation, technology, security, and regulation. Digital assets and their underlying blockchain networks are complex emerging technologies that may be subject to delays or halts, or go offline, as a result of errors, forks, attacks or other unforeseeable reasons. Anyone can create a digital asset, including fake versions of existing digital assets and digital assets that falsely claim to represent projects. So-called stablecoins may not be as stable as they purport to be, may not be fully or adequately collateralized, and may be subject to panics and runs. You are solely responsible for understanding the risks specific to each digital asset that is relevant to you.Bridging. In addition to being an especially novel and untested implementation of blockchain technology in general, cross-blockchain bridging technology has historically been, and may in the future be, the subject of numerous cyberattacks and exploits, including without limitation, hacks that exploit a vulnerability in the associated software, hardware, systems or other equipment or social engineering to gain control of the any bridge components, wallets, smart contracts or other related systems.Control. OP Mainnet, the OP Stack, and potentially, certain Other OP Chains/Forks are subject to periodic upgrades based on votes by the Optimism Collective. Although the Foundation stewards and administers certain governance processes of the Optimism Collective, it does not control the Optimism Collective or the outcomes of governance votes. The Optimism Collective may vote to implement, or fail to implement, a protocol upgrade that significantly impacts OP Mainnet, the OP Stack, and/or certain Other OP Chains/Forks, or introduces other risks, bugs, malfunctions, cyberattack vectors, or other changes to OP Mainnet, the OP Stack, and/or certain Other OP Chains/Forks that could disrupt the operation of the Services, your ability to access your digital assets, or otherwise cause you damage or loss.Third Party Risks. Third-party products and services carry their own individual, oftentimes highly significant risks. When you use the Services to interact with any third-party product or service, you are subject to, and assume, all of those risks.Tax and compliance. Digital assets may be subject to taxation. It is your sole responsibility to determine whether, and to what extent, any taxes apply to any transactions you conduct in connection with your use of the Services, and to withhold, collect, report and remit the correct amounts of taxes to the appropriate tax authorities.Legislative and regulatory risks. Digital assets, blockchain technology, and any related software and services are subject to legal and regulatory uncertainty in the United States and other jurisdictions throughout the world. Legislative and regulatory changes or actions may adversely affect the usage, transferability, transactability and accessibility of the Services, OP Mainnet, Other OP Chains/Forks, or digital assets in general.You represent that you understand, and you agree to accept full responsibility for, all the risks of using any Service, the OP Stack, OP Mainnet, and any Other OP Chain/Fork, including, but not limited to, those listed above.8. No Fiduciary Relationship; No AdviceYou acknowledge and agree that: (a) these Terms are not intended to, and do not, create or impose any fiduciary duties on us; (b) we owe no fiduciary duties or liabilities to you or any other party; (c) to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated; and (d) the only duties and obligations that we owe you are those set out expressly in these Terms.You agree that the Services and any information provided by or obtained from the Services are for informational purposes only, are not intended to be relied upon for professional advice of any sort and are not a substitute for information from experts or professionals in the applicable area. You should not take, or refrain from taking, any action or decision based on any information contained in the Services. If, and before you make any financial, legal, or other decisions involving the Services, you should seek independent professional advice from an individual who is licensed and qualified in the area for which such advice would be appropriate.9. Intellectual PropertyGenerally. Unless expressly set forth otherwise in these Terms, you acknowledge that all the intellectual property rights, including copyrights, patents, trademarks, and trade secrets in the Services and the content contained therein, are owned by the Foundation. Neither these Terms (nor your access to the Services) transfers to you or any third party any rights, title or interest in or to such intellectual property rights, unless expressly set forth otherwise in these Terms (if applicable). The Foundation reserves all rights not granted in these Terms. There are no implied licenses granted under these Terms.PFP Images. All copyrights in each PFP image associated with an Optimist NFT that is minted using the Optimist NFT Service (i.e., the whole customized PFP image) is dedicated to the public domain under the Creative Commons Zero (CC0). The full text of the CC0 license can be read here. We and you hereby waive any copyrights we and you may have in each customized PFP image associated with an Optimist NFT that is minted using the Optimist NFT Service. For clarity, the above paragraph applies only to the whole customized PFP image associated with each Optimist NFT, and not any of the individual PFP elements made available by the Foundation on the Site for users to combine to customize a PFP, or any other intellectual property we may own, all of which the Foundation retains ownership of all right, title and interest.10. FeedbackYou acknowledge and agree that: (a) these Terms are not intended to, and do not, create or impose any fiduciary duties on us; (b) we owe no fiduciary duties or liabilities to you or any other party; (c) to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated; and (d) the only duties and obligations that we owe you are those set out expressly in these Terms.11. Third-Party Products and InformationThe Services may contain references and links or otherwise enable you to connect to third-party websites, applications, resources, products, or services, including (but not limited to) Web3 Wallets, Third-Party Bridges, decentralized applications, and other information, materials, products, or services, which we do not own or control (collectively, “Third-Party Products”). We do not approve, monitor, endorse, make any representations or warranties (expressly or implicitly) about, or assume any responsibility for any Third-Party Products, any component thereof, or the manner in which those products or components interact with the Services. When you use or rely on any Third-Party Product, you do so at your own risk. You understand that you are solely responsible for any fees and costs associated with using Third-Party Products and that, unless stated herein, the Terms do not otherwise apply to your dealings or relationships with any third parties or Third-Party Products. We will not have any liability or responsibility with respect to any Third-Party Product.12. Copyright PolicyThe Foundation respects the intellectual property of others and asks that users of our Services do the same. In connection with our Services, we have adopted and implemented a policy respecting copyright law that provides for the removal of any infringing materials. If you believe that one of our users is, through the use of our Services, unlawfully infringing the copyright(s) in a work, and wish to have the allegedly infringing material removed, please provide the following information to legal@optimism.io in the form of a written notification:your name address, telephone number, and e-mail address;identification of the copyrighted work(s) that you claim to have been infringed;identification of the material on our services that you claim is infringing and that you request us to remove;sufficient information to permit us to locate such material;a statement that you have a good faith belief that use of the objectionable material is not authorized by the copyright owner, its agent, or under the Law;a statement that the information in the notification is accurate, and under penalty of perjury, that you are either the owner of the copyright that has allegedly been infringed or that you are authorized to act on behalf of the copyright owner; andyour physical or electronic signature.Any misrepresentation of material fact (falsities) in a written notification automatically subjects the complaining party to liability for any damages, costs and attorney’s fees incurred by us in connection with the written notification and allegation of copyright infringement.13. IndemnificationTo the fullest extent permitted by applicable Law, you agree to indemnify, defend and hold harmless the Foundation, as well as its affiliates and its and their respective service providers, licensees, sublicensees, users, and contractors, and each of its and their respective past, present and future officers, directors, members, employees, consultants, representatives, agents, and users, and each of their respective successors and assigns (all of the foregoing, collectively, the “Indemnified Parties”) from and against all actual or alleged claims, damages, awards, judgments, losses, liabilities, obligations, taxes, penalties, interest, fees, expenses (including, without limitation, attorneys’ fees and expenses) and costs (including, without limitation, court costs, costs of settlement and costs of pursuing indemnification and insurance), of every kind and nature whatsoever, whether known or unknown, foreseen or unforeseen, matured or unmatured, or suspected or unsuspected, in law or equity, whether in tort, contract or otherwise (collectively, “Claims”) that are caused by, arise out of or are related to: (a) your use of the Services; (b) your violation of these Terms or applicable Law; (c) your violation of the rights of a third party; and (d) your negligence or willful misconduct. You agree to promptly notify the Foundation of any third-party Claims you become aware of and cooperate with the Indemnified Parties in defending such Claims. You further agree that the Indemnified Parties shall have the right to control the defense or settlement of any third-party Claims, if they so choose.14. Disclaimers and Release of ClaimsTHE SERVICES ARE PROVIDED BY US ON AN “AS-IS” BASIS, WITHOUT WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR THAT AVAILABILITY, ACCESSIBILITY, OR USE OF THE SERVICES WILL BE UNINTERRUPTED OR ERROR-FREE.YOU EXPRESSLY AGREE THAT YOU ASSUME ALL RISKS IN CONNECTION WITH YOUR ACCESS TO AND USE OF THE SERVICES, THE OP STACK, OP MAINNET, OTHER OP CHAINS/FORKS AND THIRD-PARTY PRODUCTS, AND YOU ACKNOWLEDGE AND AGREE THAT THE INDEMNIFIED PARTIES DO NOT OPERATE OR CONTROL, AND WILL NOT HAVE ANY LIABILITY OR RESPONSIBILITY WITH RESPECT TO, OP MAINNET OR ANY OTHER OP CHAIN/FORK. YOU FURTHER EXPRESSLY WAIVE AND RELEASE THE INDEMNIFIED PARTIES FROM ANY AND ALL LIABILITY, CLAIMS, CAUSES OF ACTION, OR DAMAGES ARISING FROM OR IN ANY WAY RELATING TO YOUR ACCESS TO OR USE OF ANY OF THE FOREGOING, INCLUDING, WITHOUT LIMITATION, WITH RESPECT TO LOSS, MISDIRECTION OR INACCESSIBILITY OF, OR ANY OTHER ERROR WITH RESPECT TO, DIGITAL ASSETS.15. Limitation of LiabilityTO THE FULLEST EXTENT ALLOWED BY APPLICABLE LAW, UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, TORT, CONTRACT, STRICT LIABILITY, OR OTHERWISE) SHALL ANY INDEMNIFIED PARTY BE LIABLE TO YOU OR TO ANY OTHER PERSON WITH RESPECT TO A SERVICE (INCLUDING WITHOUT LIMITATION ANY ASSOCIATED SMART CONTRACTS, OPTIMIST NFTS, PFPS, OR ATTESTATIONS) FOR: (A) ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES OF ANY KIND, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOST PROFITS, BUSINESS INTERRUPTION, LOSS, MISDIRECTION OR INACCESSIBILITY OF DIGITAL ASSETS, LOSS OF DATA, LOSS OF GOODWILL, WORK STOPPAGE, ACCURACY OF RESULTS, OR COMPUTER FAILURE OR MALFUNCTION; (B) ANY SUBSTITUTE GOODS, SERVICES OR TECHNOLOGY; (C) ANY AMOUNT, IN THE AGGREGATE, IN EXCESS OF ONE-HUNDRED ($100) DOLLARS; OR (D) ANY MATTER BEYOND THE REASONABLE CONTROL OF THE FOUNDATION.SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL OR CERTAIN OTHER DAMAGES, SO THE ABOVE LIMITATIONS AND EXCLUSIONS MAY NOT APPLY TO YOU.16. Dispute Resolution; ArbitrationPlease carefully read the following arbitration agreement (this “Arbitration Agreement”). It requires you to arbitrate disputes with the Foundation and limits the manner in which you can seek relief from us.Applicability of this Arbitration Agreement. You agree that any dispute, claim, or request for relief relating in any way to the Terms or to any aspect of your relationship with the Foundation will be resolved by binding arbitration, rather than in court, except that (i) you may assert claims or seek relief in small claims court if your claims qualify, and (ii) you or the Foundation may seek equitable relief in court for infringement or other misuse of intellectual property rights (such as trademarks, trade dress, domain names, trade secrets, copyrights, and patents). This Arbitration Agreement shall apply, without limitation, to all disputes or claims and requests for relief that arose or were asserted before the effective date of the Terms or any prior version of the Terms.Arbitration rules and forum. To begin an arbitration proceeding, you must send a letter requesting arbitration and describing your dispute or claim or request for relief to legal@optimism.io. The arbitration will be conducted by JAMS, an established alternative dispute resolution provider. Disputes involving claims, counterclaims, or request for relief under $250,000, not inclusive of attorneys’ fees and interest, shall be subject to JAMS’s most current version of the Streamlined Arbitration Rules and procedures available at https://www.jamsadr.com/rules-streamlined-arbitration/; all other disputes shall be subject to JAMS’s most current version of the Comprehensive Arbitration Rules and Procedures, available at http://www.jamsadr.com/rules-comprehensive-arbitration/. JAMS’s rules are also available at www.jamsadr.com or by calling JAMS at 800-352-5267. If JAMS is not available to arbitrate, the parties will select an alternative arbitral forum. To the extent the filing fee for the arbitration exceeds the cost of filing a lawsuit, the arbitrator may require the Foundation to pay the additional cost. You are responsible for your own attorneys’ fees unless the arbitration rules and applicable Law provide otherwise. If the arbitrator finds the arbitration to be non-frivolous, the Foundation will pay the remaining filing and arbitrator fees for the arbitration, provided your claim does not exceed $75,000. For claims above $75,000, fees and costs will be determined in accordance with applicable JAMS rules. The arbitration rules permit you to recover attorney’s fees in certain cases. You may choose to have the arbitration conducted by telephone, based on written submissions, or in person in the country where you live or at another mutually agreed location. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction. Any arbitration demand or counterclaim asserted by either party must contain sufficient information to provide fair notice to the other party of the asserting party’s identity, the claims being asserted, and the factual allegations on which they are based. The arbitrator or JAMS may require amendment of any demand or counterclaim that does not satisfy these requirements. The arbitrator has the right to impose sanctions in accordance with JAMS Rule 24 for any claims the arbitrator determines to be frivolous or improper. The parties agree that JAMS has discretion to modify the amount or timing of any administrative or arbitration fees due under JAMS’s Rules where it deems appropriate, provided that such modification does not increase the costs to you, and you waive any objection to such fee modification. The parties also agree that a good-faith challenge by either party to the fees imposed by JAMS does not constitute a default, waiver, or breach of this Arbitration Agreement while such challenge remains pending before JAMS, the arbitrator, or a court of competent jurisdiction.Authority of arbitrator. The arbitrator shall have exclusive authority to (i) determine the scope and enforceability of this Arbitration Agreement, and (ii) resolve any dispute related to the interpretation, applicability, enforceability or formation of this Arbitration Agreement including, but not limited to, any assertion that all or any part of this Arbitration Agreement is void or voidable, whether a claim is subject to arbitration, and any dispute regarding the payment of JAMS administrative or arbitrator fees (including the timing of such payments and remedies for nonpayment). The arbitrator will decide the rights and liabilities, if any, of you and us. The arbitration proceeding will not be consolidated with any other matters or joined with any other cases or parties, provided that the arbitrator shall also be empowered to consolidate claims raised between the same parties to a single arbitration proceeding. The arbitrator shall have the authority to grant motions dispositive of all or part of any claim. The arbitrator shall have the authority to award monetary damages and to grant any non-monetary remedy or relief available to an individual under applicable law, the arbitral forum’s rules, and this Agreement (including the Arbitration Agreement). The arbitrator shall issue a written award and statement of decision describing the essential findings and conclusions on which the award is based, including the calculation of any damages awarded. The arbitrator has the same authority to award relief on an individual basis that a judge in a court of law would have. The award of the arbitrator is final and binding upon you and us. No arbitration award or decision will have any preclusive effect as to issues or claims in any dispute with anyone who is not a named party to the arbitration.Waiver of jury trial. YOU HEREBY WAIVE ANY CONSTITUTIONAL AND STATUTORY RIGHTS TO SUE IN COURT AND HAVE A TRIAL IN FRONT OF A JUDGE OR A JURY. You and we are instead electing that all disputes, claims, or requests for relief shall be resolved by arbitration under this Arbitration Agreement, except as specified in Section 16(a) (Applicability of this Arbitration Agreement) above. An arbitrator can award on an individual basis the same damages and relief as a court and must follow this Arbitration Agreement as a court would. However, there is no judge or jury in arbitration, and court review of an arbitration award is subject to very limited review.Waiver of class or other non-individualized relief. ALL DISPUTES, CLAIMS, AND REQUESTS FOR RELIEF WITHIN THE SCOPE OF THIS ARBITRATION AGREEMENT MUST BE ARBITRATED ON AN INDIVIDUAL BASIS AND NOT ON A CLASS OR COLLECTIVE BASIS, ONLY INDIVIDUAL RELIEF IS AVAILABLE, AND CLAIMS OF MORE THAN ONE USER CANNOT BE ARBITRATED OR CONSOLIDATED WITH THOSE OF ANY OTHER USER. If a decision is issued stating that applicable law precludes enforcement of any of this section’s limitations as to a given dispute, claim, or request for relief, then such aspect must be severed from the arbitration and brought into the courts of the Cayman Island. All other disputes, claims, or requests for relief shall be arbitrated.30-day right to opt out. You have the right to opt out of the provisions of this Arbitration Agreement by sending written notice of your decision to opt out to legal@optimism.io within 30 days after you first access any of the Services. Your notice must include your name and address, the Web3 Wallet address used to access or use the Service (if applicable), and an unequivocal statement that you want to opt out of this Arbitration Agreement. If you opt out of this Arbitration Agreement, (i) all other parts of this Arbitration Agreement will continue to apply to you, and (ii) the Foundation will not be bound by this Arbitration Agreement. Opting out of this Arbitration Agreement has no effect on any other arbitration agreements that you may currently have, or may enter in the future, with us.Severability. Except as provided in Section 16(e) (Waiver of class or other non-individualized relief), if any part or parts of this Arbitration Agreement are held by a court or other tribunal of competent jurisdiction to be invalid, illegal, or unenforceable for any reason, such specific part or parts shall be eliminated or limited to the minimum extent such that the remainder of the Arbitration Agreement shall continue in full force and effect.Survival of Agreement. This Arbitration Agreement will survive the termination of your relationship with us.Modification. Notwithstanding any provision in the Terms to the contrary, we agree that if we make any future material change to this Arbitration Agreement, you may reject that change within 30 days of such change becoming effective by writing us at legal@optimism.io and expressly opting out of this Arbitration Agreement.17. Conflict of ProvisionsIn the event that there exists a conflict between any term, condition or provision contained within these Terms, and in any term, condition, or provision contained within any other specific part or feature, the term, condition, or provision contained in such specific part or feature will control, solely with respect to the applicable part or feature.18. Governing Law, Forum, Venue and JurisdictionThe Terms are governed by and will be construed under the laws of the Cayman Islands, excluding its body of law controlling conflict of laws. You agree that the Services shall be deemed to be based solely in the Cayman Islands, and that although the Services may be available in other jurisdictions, the availability of any Service does not give rise to general or specific personal jurisdiction in any forum outside the Cayman Islands. Any arbitration conducted pursuant to these Terms shall be conducted in accordance with Section 16. You agree that any judicial proceeding will be brought in the courts located in the Cayman Islands.19. Third-Party BeneficiariesEach Indemnified Party shall be deemed to be an expressly-intended third-party beneficiary of all provisions of these Terms that expressly reference Indemnified Parties or that are reasonably relevant to Indemnified Parties and you, with the right to directly enforce such provisions against you. There are otherwise no third-party beneficiaries of these Terms.20. Entire Agreement; Amendment; SeverabilityThese Terms, the Optimism Community Agreement, and any other terms we provide in connection with specific pages, features, products, or services constitute the sole and entire agreement between you and the Foundation regarding the Services and supersede all prior and contemporaneous understandings, agreements, representations, and warranties, both written and oral, regarding the Services. Except for changes made by us posting an updated version of these Terms, no other amendment or modification of the Terms will be effective unless in writing and signed by both you and us. Without limiting the foregoing sentence, if any provision of these Terms is held by a court or other tribunal of competent jurisdiction to be invalid, illegal, or unenforceable for any reason, such provision shall be eliminated or limited to the minimum extent such that the remaining provisions of these Terms will continue in full force and effect.","tokens":9858,"squid":"ink-governance","role":"Council Listener","at":1791265696022,"hash":"d35a2587a1e84ff188dc63e111e67b8caf1006be"}
{"url":"https://forum.soliditylang.org/t/solidity-developer-survey-2025-results/3698/3","domain":"forum.soliditylang.org","title":"Solidity Developer Survey 2025 Results - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 16\n\n 3 / 3\n\n Apr 27\n\n Apr 27\n\n post by czepluch on Apr 16\n\n czepluch\n\n Solidity Team\n\n The results from our sixth annual developer survey are live. 1,095 developers from 87 countries responded.\nThe full interactive report has 60 charts covering demographics, tooling, pain points, AI usage, Core Solidity, and cross-analysis by experience level: Solidity Developer Survey 2025 Results | Solidity Programming Language\nA few things that stood out:\n\nStack-too-deep remains the #1 pain point, and it hits experienced developers hardest (65% of experts vs 25% of beginners)\n88% use AI tools at least monthly, but 45% express distrust in the output\nFoundry grew from 51% to 57%. One Truffle user remains.\nOnly 30% of respondents are familiar with Core Solidity\n73% say DevEx has improved (up from 67% in 2024)\nDebugging is painful across all experience levels, regardless of tooling\n\nOur takeaways and what we’re doing about it (including the SSA CFG codegen that eliminates stack-too-deep): Solidity Developer Survey 2025 Results | Solidity Programming Language\nThe raw data (CSV) is available for download from the interactive report page.\nWe’d love to hear your thoughts. If anything in the results surprises you, or if you have feedback on how we can improve the survey next year, this thread is a good place for that.\n\n 2\n\n post by nebojsakonsta on Apr 24\n\n nebojsakonsta\n\n When are you guys doing 2026 survey? Would love to see how landscape is changing.\n\n post by czepluch on Apr 27\n\n czepluch\n\n Solidity Team\n\n End of the year. We got started a bit late for 2025, so the results only got out in 2026.\nWe expect to run the next survey November/December 2026.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 180\n\n Dec 2025\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1417,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265703354,"hash":"783288fb12177f5ce4054dc93f773a500e78a96d"}
{"url":"https://forum.openzeppelin.com/c/general/announcements/21","domain":"forum.openzeppelin.com","title":"Latest General/Announcements topics - OpenZeppelin Forum","text":"Latest topics in Announcements\n\n General\n\n Announcements\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Unveiling Uniswap Hooks by OpenZeppelin\n\n 0\n\n 136\n\n Oct 2024\n\n Release Candidate for Contracts 5.1\n\n 1\n\n 109\n\n Oct 2024\n\n UUPSUpgradeable Vulnerability Post-mortem\n\n 13\n\n 15.9k\n\n Mar 2024\n\n Release Candidate for Contracts 5.0\n\n 1\n\n 645\n\n Oct 2023\n\n Defender: Potential Impact of The Graph Maintenance Aug 14th\n\n 0\n\n 388\n\n Aug 2023\n\n Security advisory: Initialize UUPS implementation contracts\n\n 28\n\n 17.1k\n\n Jul 2023\n\n Defender: Potential Impact of The Graph Maintenance June 22nd\n\n 0\n\n 435\n\n Jun 2023\n\n Defender Release: Support for Sepolia\n\n defender\n\n 0\n\n 744\n\n May 2023\n\n Defender Release: Support for Base Goerli\n\n defender,l2\n\n 0\n\n 536\n\n Apr 2023\n\n Defender Release: Support for zkSync Era\n\n defender,l2\n\n 0\n\n 687\n\n Apr 2023\n\n OpenZeppelin upgradeable contracts affected by Istanbul hardfork\n\n 3\n\n 6.6k\n\n Mar 2023\n\n Join us January 10 for a Web3 Security Twitter Space with Compound Finance and Gauntlet\n\n 0\n\n 651\n\n Jan 2023\n\n Defender Release: Verifying deployment bytecode\n\n etherscan-verify\n\n 0\n\n 1.1k\n\n Dec 2022\n\n [Action Required]: Defender Autotask runtime upgrade\n\n 2\n\n 1.3k\n\n Nov 2022\n\n [Possible Action Required]: Free-Tier OpenZeppelin Defender Account Pulse-Check Underway\n\n defender\n\n 0\n\n 714\n\n Nov 2022\n\n Defender Release: Infrastructure as Code, Sentinel matches history, and more\n\n defender\n\n 0\n\n 712\n\n Sep 2022\n\n Defender Release: Role-based access control, Hedera support, and more!\n\n defender\n\n 0\n\n 661\n\n Sep 2022\n\n Defender Release: Admin simulations, safe & finalized sentinel tags, more speed for Polygon txs, and more!\n\n 2\n\n 823\n\n Aug 2022\n\n Defender Release: EIP1559 support, Access Control in Admin, Optimism Goerli and Arbitrum Goerli, and more!\n\n defender\n\n 0\n\n 781\n\n Aug 2022\n\n Upgrades Plugins: Etherscan verification for proxies\n\n etherscan-verify,proxies,upgrades-plugins\n\n 7\n\n 2.6k\n\n Jul 2022\n\n Release Candidate for Contracts 4.7: Open Review Period\n\n 1\n\n 1.4k\n\n Jun 2022\n\n Defender Release: Hedera Sentinels, Additional Sentinel Confirmations, Sentinel Match Reasons\n\n 0\n\n 610\n\n Jun 2022\n\n Defender Release: Fireblocks execution strategy for Admin Proposals, Sentinels Support for Hedera network and Logging\n\n 0\n\n 798\n\n Jun 2022\n\n Defender Release: Optimism, Frame, improved Forta Sentinels, and full Relayer CRUD API!\n\n etherscan-verify,defender\n\n 0\n\n 1.7k\n\n May 2022\n\n Release Candidate for Contracts 4.6: Open Review Period\n\n 1\n\n 2.3k\n\n Apr 2022\n\n Release Candidate for Contracts 4.5: Open Review Period\n\n 6\n\n 3.5k\n\n Feb 2022\n\n OpenZeppelin CLI 2.8: Release Candidate\n\n 10\n\n 4.8k\n\n Feb 2022\n\n Defender Jan 2022 Release: Alerts formatting, ERC20 proposals, and more!\n\n defender,release\n\n 0\n\n 933\n\n Jan 2022\n\n Upgrades Plugins: Support for beacon proxies\n\n proxies,upgrades-plugins\n\n 0\n\n 1.4k\n\n Jan 2022\n\n What’s new in Defender, November 2021 Update!\n\n defender\n\n 0\n\n 1.1k\n\n Dec 2021","tokens":745,"squid":"ink-security_audits","role":"Sentinel","at":1791265715536,"hash":"3245284ee93d462c4d453d2cbc1ff8d313533d5b"}
{"url":"https://dev-forum.pyth.network/t/cant-update-price-via-vscode/65/1","domain":"dev-forum.pyth.network","title":"Can't Update Price Via Vscode - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Can’t Update Price Via Vscode \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Apr 2025\n\n 1 / 11\n\n Apr 2025\n\n Apr 2025\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n Hi guys, I updated the price of $BIO on the pyth base contract via basescan. However, when I try doing same via vscode via forking mainnet I get 0x6ce2251a can’t really pinpoint what custom error message this points to\naddress contractAddress = 0x8250f4aF4B972684F7b336503E2D6dFeDeB1487a;\nbytes32 id = 0xd9d22050e7413a16129f1334cd4dd5a359975ce16389cdadae8f677cf46e2839;\nupdateData[0] = \"0x504e41550100000003b801000000040d00b68f0e892457b4821243f5e462d34a369aa4936a8d3b35037c1b6c8a04a9a36476cd1ebbc0a60311e688f20d8dfff6e5cdf42be5ad44a477aca283a7ff20047b0103f6e2adde8f037ca625a1e9f06774e5650015ee9ed08168a32df24e20bfcae1565c45fa34a3e2d25738c3c0380d1bf8c284b487a1efdb1961eb53652bdad16bd30104b2cd90492cd743dec95cddcc0788e1d512e76bb0586e3ebfe02a9ef0170fe82e753ee9e34fbe71741138aeb5e7fd75d686741ffe07e689d2168d6548048c796a01064c2ccd03540dfba573eb34c7ca333077bc5fc12479c17271f5f02af33bcd3a247489f96dced19002e0fe70b3b233a1b8e0d6b3afb1bd5c3bf2757d752c215beb0108b788192773f7aefd8c129f4a75cc5201fe95b12923e835a70b6c5bfbf495ba5a066b4b285d8e3a4cdddc074bf5ed51ada9ed58b1db07296bb3e47620c503b91a000ab4f1aac4759e568d7c0c6509e12884606f927877d94ea24de677fb7767668dc259cdfa5c1d0d16d98f3b887064f760ecca9ba7383cc400aadb46a2f0ae690873010bf44ca2f2afd564afcc8ffbabae88899aa1ac3544d4ad6cf60f99846ec9f865770a07c56d2e4920f9fea195ad3bd660e7adae1f2f56e7fb1e33ad7a1eb00950db000c2da910166d3f7c2e6279f02be39b41db3363bad3c72873cf39120463b848c10e7836bc9ea565c6e5835a743637c475a1135be7311e77cf7f840225590d5c7bd6010d3c78a02ef8dd6f3d8a2701789f45ec27588dafe5cda2cd25b45aed2ef9baa2591b8c4f69a9e4099b4d90df673205c31ade8a6ab52052232eda7e603db4ace9ab000e70e17715875c1e8a236b98526589996ae4beb59a83486d668f091eaf0ee97b5e040883d9a70f39d4d57df764c2f32e3d74dbe6d631a1b9c5a447f4215d20e123000fad5f138dd4b38f07869f943cf44264823a90ea8a771befa1261da63774a0db8a2dabaee1e2155bdc776c0bd12d7843cff28ad773f35a35e855d6df6cfb0f2b700010b535a6b2bbdf478c9728c3a9f9b1c32804647c080a1df804fc908565117082077bcd47d1e17d35be34fbf5c0525a50cc9e1f4ce5af016c7162983115e1bc39a6001164c30404a6b689db35a8a6bc703a028e892f85edce7b31d47af03abe0dbcb144371482c4a8124d719658bbfc421a54992c90ef067ee86358e56758097b56278b006800ad0700000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000787dd08014155575600000000000c95591d0000271095471fe15e1ddf5bec8c9902a2500ab399234eb801005500d9d22050e7413a16129f1334cd4dd5a359975ce16389cdadae8f677cf46e2839000000000044ba93000000000000287cfffffff8000000006800ad07000000006800ad070000000000443e1f000000000000266b0c49e53a13b3b3971c21d9a0e56ee9feaadefaa34ab26512d48efe35fbc704fa0ce9621fc9128cbf6c1f2edad1d5d06d76e6676b4cc7db667adaa11b2c9ddea5a40c3d778a2d361ed1c9409c324ec3cc0433af297d5df786e55ba744a33daffc6419d50acfb52ac513900579bd9110db76c61895a15843327f80cb84744d47deb617a7f8c5c4747aeac357f25e3afe17b2fc377383f3038b5a6bb69aff71722f22f0b032cf24a73a6ac07644a51716321d59bb121d425dd1b8bc73e7dd2555bae4e9cda7cf1d308b26c638d09dc67bb4a4ed67fb394e909c086be03986b47541452a45bad230bb418744d47aa7f5af9eca;\nScreenshot 2025-04-17 at 09.03.491621×703 98.1 KB\n\n Custom error 0x6ce2251a\n\n 6\n\n 4\n\n post by 0xcredence on Apr 17, 2025\n\n post by c-note on Apr 17, 2025\n\n post by ali on Apr 17, 2025\n\n post by c-note on Apr 17, 2025\n\n post by ali on Apr 17, 2025\n\n post by c-note on Apr 17, 2025\n\n post by ali on Apr 17, 2025\n\n post by c-note on Apr 20, 2025\n\n post by ali on Apr 22, 2025\n\n post by c-note on Apr 22, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Price Feed not working on AVAX and BASE\n\n Price Feeds\n\n 1\n\n 497\n\n Apr 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 655\n\n May 2025\n\n Powered by Discourse","tokens":1925,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265715613,"hash":"37a28c09bf3939662c9a281e35983e673d3d5b97"}
{"url":"https://forum.openzeppelin.com/t/defender-release-support-for-zksync-era/35565","domain":"forum.openzeppelin.com","title":"Defender Release: Support for zkSync Era - General / Announcements - OpenZeppelin Forum","text":"Defender Release: Support for zkSync Era \n\n GeneralAnnouncements\n\n defender,l2\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2023\n\n 1 / 1\n\n Apr 2023\n\n Apr 2023\n\n post by slw.eth on Apr 4, 2023\n\n slw.eth\n\n Both zkSync Era Testnet and zkSync Era Mainnet have been enabled in Defender for all users!\nUsers can now import contracts (including abstracted accounts) for both networks and automatically retrieve the contract ABI if the contract is verified on the zkSync explorer.\nDefender Admin lets developers interact with their zkSync contracts with the following features:\n\nPerform upgrades\nQuery and modify Role-Based Access Control\nRun custom function calls on imported contracts\nPause/Unpause contracts\n\nDefender Relayer allows automating transaction sending on zkSync and incident response\n\nCan be easily integrated with ethers.js via API\nEIP1559 support\nResubmission infrastructure (once a transaction is sent, you don’t need to worry about repricing it if it fails)\n\nDefender Sentinel allows reacting to on-chain events by monitoring specific rules on zkSync contracts\n\nCan send notifications to Discord/Slack/Email\nCan be configured to trigger a relayer transaction (on any other chain)\nEnables cross-chain automation\n\nDefender Autotask for zkSync allows writing custom code that interacts with other Relayer components\n\nSend Relayer transactions\nReact to Sentinels\nExecute in a schedule\nExecute via webhooks\n\nOpenZeppelin Defender provides a security operations (SecOps) platform for Ethereum with built-in best practices. Development teams implement Defender to ship faster and minimize security risks.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Openzeppelin defender support zkSync alpha testnet\n\n Defender\n\n 1\n\n 360\n\n Aug 2022\n\n OpenZeppelin Defender - March 2021 Update\n\n Announcements\n\n defender\n\n 0\n\n 751\n\n Mar 2021\n\n Defender Release: Support for Base Goerli\n\n Announcements\n\n defender,l2\n\n 0\n\n 536\n\n Apr 2023\n\n What is the main use of defender?\n\n Defender\n\n defender,openzeppelin-contracts\n\n 3\n\n 714\n\n Apr 2022\n\n OpenZeppelin Defender - Feature requests [Q1 2022]\n\n General\n\n 5\n\n 1.2k\n\n Feb 2022","tokens":550,"squid":"ink-security_audits","role":"Sentinel","at":1791265737553,"hash":"bf9976b0fc737819638f2db0f8b1ef85f88a5835"}
{"url":"https://dev-forum.pyth.network/t/cant-update-price-via-vscode/65/11","domain":"dev-forum.pyth.network","title":"Can't Update Price Via Vscode - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Apr 2025\n\n 11 / 11\n\n Apr 2025\n\n Apr 2025\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n Hi guys, I updated the price of $BIO on the pyth base contract via basescan. However, when I try doing same via vscode via forking mainnet I get 0x6ce2251a can’t really pinpoint what custom error message this points to\naddress contractAddress = 0x8250f4aF4B972684F7b336503E2D6dFeDeB1487a;\nbytes32 id = 0xd9d22050e7413a16129f1334cd4dd5a359975ce16389cdadae8f677cf46e2839;\nupdateData[0] = \"0x504e41550100000003b801000000040d00b68f0e892457b4821243f5e462d34a369aa4936a8d3b35037c1b6c8a04a9a36476cd1ebbc0a60311e688f20d8dfff6e5cdf42be5ad44a477aca283a7ff20047b0103f6e2adde8f037ca625a1e9f06774e5650015ee9ed08168a32df24e20bfcae1565c45fa34a3e2d25738c3c0380d1bf8c284b487a1efdb1961eb53652bdad16bd30104b2cd90492cd743dec95cddcc0788e1d512e76bb0586e3ebfe02a9ef0170fe82e753ee9e34fbe71741138aeb5e7fd75d686741ffe07e689d2168d6548048c796a01064c2ccd03540dfba573eb34c7ca333077bc5fc12479c17271f5f02af33bcd3a247489f96dced19002e0fe70b3b233a1b8e0d6b3afb1bd5c3bf2757d752c215beb0108b788192773f7aefd8c129f4a75cc5201fe95b12923e835a70b6c5bfbf495ba5a066b4b285d8e3a4cdddc074bf5ed51ada9ed58b1db07296bb3e47620c503b91a000ab4f1aac4759e568d7c0c6509e12884606f927877d94ea24de677fb7767668dc259cdfa5c1d0d16d98f3b887064f760ecca9ba7383cc400aadb46a2f0ae690873010bf44ca2f2afd564afcc8ffbabae88899aa1ac3544d4ad6cf60f99846ec9f865770a07c56d2e4920f9fea195ad3bd660e7adae1f2f56e7fb1e33ad7a1eb00950db000c2da910166d3f7c2e6279f02be39b41db3363bad3c72873cf39120463b848c10e7836bc9ea565c6e5835a743637c475a1135be7311e77cf7f840225590d5c7bd6010d3c78a02ef8dd6f3d8a2701789f45ec27588dafe5cda2cd25b45aed2ef9baa2591b8c4f69a9e4099b4d90df673205c31ade8a6ab52052232eda7e603db4ace9ab000e70e17715875c1e8a236b98526589996ae4beb59a83486d668f091eaf0ee97b5e040883d9a70f39d4d57df764c2f32e3d74dbe6d631a1b9c5a447f4215d20e123000fad5f138dd4b38f07869f943cf44264823a90ea8a771befa1261da63774a0db8a2dabaee1e2155bdc776c0bd12d7843cff28ad773f35a35e855d6df6cfb0f2b700010b535a6b2bbdf478c9728c3a9f9b1c32804647c080a1df804fc908565117082077bcd47d1e17d35be34fbf5c0525a50cc9e1f4ce5af016c7162983115e1bc39a6001164c30404a6b689db35a8a6bc703a028e892f85edce7b31d47af03abe0dbcb144371482c4a8124d719658bbfc421a54992c90ef067ee86358e56758097b56278b006800ad0700000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000787dd08014155575600000000000c95591d0000271095471fe15e1ddf5bec8c9902a2500ab399234eb801005500d9d22050e7413a16129f1334cd4dd5a359975ce16389cdadae8f677cf46e2839000000000044ba93000000000000287cfffffff8000000006800ad07000000006800ad070000000000443e1f000000000000266b0c49e53a13b3b3971c21d9a0e56ee9feaadefaa34ab26512d48efe35fbc704fa0ce9621fc9128cbf6c1f2edad1d5d06d76e6676b4cc7db667adaa11b2c9ddea5a40c3d778a2d361ed1c9409c324ec3cc0433af297d5df786e55ba744a33daffc6419d50acfb52ac513900579bd9110db76c61895a15843327f80cb84744d47deb617a7f8c5c4747aeac357f25e3afe17b2fc377383f3038b5a6bb69aff71722f22f0b032cf24a73a6ac07644a51716321d59bb121d425dd1b8bc73e7dd2555bae4e9cda7cf1d308b26c638d09dc67bb4a4ed67fb394e909c086be03986b47541452a45bad230bb418744d47aa7f5af9eca;\nScreenshot 2025-04-17 at 09.03.491621×703 98.1 KB\n\n Custom error 0x6ce2251a\n\n 6\n\n 4\n\n post by 0xcredence on Apr 17, 2025\n\n 0xcredence\n\n Hi there @c-note thank you for your question!\nIt seems that you are directly feeding the price feed id to the updatePriceFeeds function.\nBut you should feed in the update data fetched from EvmPriceServiceConnection to this function. Take a look at our js sdk for some examples:\n\nGive it a try and see if this works\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n Hello @0xcredence, thanks for your prompt response, the update data I used was gotten from Swagger UI which is were I got the update data I used to update the price via basescan which worked.\n\n post by ali on Apr 17, 2025\n\n ali\n\n @c-note the error doesn’t seem to be related to Pyth and I suspect it is because forking doesn’t fork all the contracts properly (and I have faced it in the past too). Many contracts are used in this call: proxy and main contract for Pyth and proxy and main contract for Wormhole.\nFor testing I generally recommend using MockPyth contract so you can set your own prices and simulate your desired protocol behaviours with it.\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n @ali I tried interacting with mainnet via a script not forking the mainnet and still got same error\n\n post by ali on Apr 17, 2025\n\n ali\n\n When you are not forking the contract doesn’t exist. You need to deploy MockPyth as setup phase of your testing and interact with it.\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n @ali I meant sent a tx via the mainnet paid for gas and all but failed with same error message gotten when I just forked mainnet.\nMy point is when I interact with fork-mainnet or base mainnet i still get same error message when I make this call via vscode. (But everything works well when I do this via basescan)\n\n post by ali on Apr 17, 2025\n\n ali\n\n @c-note I see, in your code i suspect the fee is wrong. you need to pass the updateData to getUpdateFee method and not the price id.\nIf that’s not the problem, please send us a reproducible code snippet to run.\n\n post by c-note on Apr 20, 2025\n\n c-note\n\n @ali The fee is correct, the returns fee as 1 Wei. Here you go\n\n post by ali on Apr 22, 2025\n\n ali\n\n @c-note thanks for sharing this script as it helped a lot to troubleshoot it. The problem is that in forge assigning update data to bytes like that is not right. You need to use hex\"deadbeef...\" and by fixing it I could send the transaction successfully.\np.s: I found the error was about Wormhole saying the message format is invalid (see this) and it made me realize that the update data format was wrong.\n\n post by c-note on Apr 22, 2025\n\n c-note\n\n @ali this fixed my issue thanks much.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 773\n\n May 2025\n\n Price Feed not working on AVAX and BASE\n\n Price Feeds\n\n 1\n\n 497\n\n Apr 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 655\n\n May 2025\n\n Powered by Discourse","tokens":2492,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265737688,"hash":"8baf4225cdbe867dce48cf7a37f24d1ab6850eb2"}
{"url":"https://dev-forum.pyth.network/t/smart-contract-reverts-when-sending-pyth-price-updates-via-hermesclient-from-my-frontend/98","domain":"dev-forum.pyth.network","title":"Smart contract reverts when sending Pyth price updates via HermesClient from my frontend - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n Apr 2025\n\n 1 / 11\n\n Apr 2025\n\n May 2025\n\n post by cuardiper on Apr 25, 2025\n\n cuardiper\n\n The transaction always reverts as soon as I include the price update in the call parameters. If I replace it with an empty array, the transaction succeeds. Am I passing the price update data correctly?\n Chain\nBase\n Timestamp\n2025-04-25 08:30 UTC\n Steps to reproduce\nconst connection = new HermesClient(\"https://hermes.pyth.network\", {});\nconst priceIds = [\"0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\"]; //BTC\n\n// Latest price updates\nconst priceUpdates = await connection.getLatestPriceUpdates(priceIds);\n\nconst data = encodeFunctionData({\n abi: FuturesABI,\n functionName: \"modifyPosition\",\n args: [\n //Other arguments....,\n priceUpdates.binary.data,\n ],\n });\n\n 7\n\n 2\n\n 2\n\n post by ali on Apr 25, 2025\n\n ali\n\n @cuardiper How does your contract interact with Pyth? I suspect that you are not paying the update fee.\n\n post by cuardiper on Apr 25, 2025\n\n cuardiper\n\n This is the snippet of the code from the smart contract that interact with pyth to update the price:\nfunction modifyPosition(\n uint256 collateral,\n bytes32 key,\n //other params...\n bytes[] calldata priceUpdate\n ) external {\n uint pythFee = pyth.getUpdateFee(priceUpdate);\n pyth.updatePriceFeeds{ value: pythFee }(priceUpdate);\n //...\n\nThe smart contract has some eth to pay the fee\n\n post by ali on Apr 25, 2025\n\n ali\n\n @cuardiper Can you tell us what is the revert code you see?\n\n post by cuardiper on Apr 25, 2025\n\n cuardiper\n\n Hey, this is an example of a transaction that fails:\n\n post by cuardiper on Apr 29, 2025\n\n cuardiper\n\n Hello, I omitted the smart account part and now I am sending the tx directly through the metamask to see if there was any more clear message. Any clue on how to keep debugging that or what could be the issue?\n\n post by Aditya520 on Apr 30, 2025\n\n Aditya520\n\n Where are you sending this contract?\nWhich contract is this?\n0xA62C31A48aD402245eAa8B9D3a5D2f1e61e74e06\nPyth contract on base is\nhttps://basescan.org/address/0x8250f4aF4B972684F7b336503E2D6dFeDeB1487a\n\n post by cuardiper on Apr 30, 2025\n\n cuardiper\n\n That is our own smart contract, from our smart contract is that we will call the updatePriceFeeds. Something like this:\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n//...\n\nfunction modifyPosition(\n uint256 collateral,\n bytes32 key,\n //other params...\n bytes[] calldata priceUpdate\n ) external {\n uint pythFee = pyth.getUpdateFee(priceUpdate);\n pyth.updatePriceFeeds{ value: pythFee }(priceUpdate);\n //...\n\n post by Aditya520 on May 1, 2025\n\n Aditya520\n\n Can you make sure that the msg.value is being passed correctly?\nMake sure your contract has enough balance to cover it?\nIf yes, can you share the transaction as well verify the contracts to help us debug.\n\n post by cuardiper on May 1, 2025\n\n cuardiper\n\n Yes, we already sent more than enough Base ETH to the contract to pay the fee. It has around $10 (0.00307 ETH). Exactly same amount as we started, did not spent any of it on the multiple attempts we did.\nI am going to ask team to verify the contract\n\n post by cuardiper on May 6, 2025\n\n cuardiper\n\n Fixed, in case it helps someone…I had to append a “0x” to the update elements before calling the smart contract, here is the code:\n\nlet updatesToSend = [];\n if (priceUpdates.binary.data) {\n //Loop each priceUpdate and append \"0x\" at the start\n updatesToSend = priceUpdates.binary.data.map((update) => {\n return \"0x\" + update;\n });\n }\n\nconst data = encodeFunctionData({\n abi: FuturesABI,\n functionName: \"modifyPosition\",\n args: [\n //Other arguments....,\n updatesToSend,\n ],\n });\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 720\n\n Apr 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 655\n\n May 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Error Implementation with Thirdweb\n\n Price Feeds\n\n 4\n\n 586\n\n Apr 2025\n\n Powered by Discourse","tokens":1994,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265748155,"hash":"4f61b225f9bfa0a18fef72ba8e32da4561bad2b0"}
{"url":"https://dev-forum.pyth.network/t/smart-contract-reverts-when-sending-pyth-price-updates-via-hermesclient-from-my-frontend/98/11","domain":"dev-forum.pyth.network","title":"Smart contract reverts when sending Pyth price updates via HermesClient from my frontend - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n Apr 2025\n\n 11 / 11\n\n May 2025\n\n May 2025\n\n post by cuardiper on Apr 25, 2025\n\n cuardiper\n\n The transaction always reverts as soon as I include the price update in the call parameters. If I replace it with an empty array, the transaction succeeds. Am I passing the price update data correctly?\n Chain\nBase\n Timestamp\n2025-04-25 08:30 UTC\n Steps to reproduce\nconst connection = new HermesClient(\"https://hermes.pyth.network\", {});\nconst priceIds = [\"0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43\"]; //BTC\n\n// Latest price updates\nconst priceUpdates = await connection.getLatestPriceUpdates(priceIds);\n\nconst data = encodeFunctionData({\n abi: FuturesABI,\n functionName: \"modifyPosition\",\n args: [\n //Other arguments....,\n priceUpdates.binary.data,\n ],\n });\n\n 7\n\n 2\n\n 2\n\n post by ali on Apr 25, 2025\n\n ali\n\n @cuardiper How does your contract interact with Pyth? I suspect that you are not paying the update fee.\n\n post by cuardiper on Apr 25, 2025\n\n cuardiper\n\n This is the snippet of the code from the smart contract that interact with pyth to update the price:\nfunction modifyPosition(\n uint256 collateral,\n bytes32 key,\n //other params...\n bytes[] calldata priceUpdate\n ) external {\n uint pythFee = pyth.getUpdateFee(priceUpdate);\n pyth.updatePriceFeeds{ value: pythFee }(priceUpdate);\n //...\n\nThe smart contract has some eth to pay the fee\n\n post by ali on Apr 25, 2025\n\n ali\n\n @cuardiper Can you tell us what is the revert code you see?\n\n post by cuardiper on Apr 25, 2025\n\n cuardiper\n\n Hey, this is an example of a transaction that fails:\n\n post by cuardiper on Apr 29, 2025\n\n cuardiper\n\n Hello, I omitted the smart account part and now I am sending the tx directly through the metamask to see if there was any more clear message. Any clue on how to keep debugging that or what could be the issue?\n\n post by Aditya520 on Apr 30, 2025\n\n Aditya520\n\n Where are you sending this contract?\nWhich contract is this?\n0xA62C31A48aD402245eAa8B9D3a5D2f1e61e74e06\nPyth contract on base is\nhttps://basescan.org/address/0x8250f4aF4B972684F7b336503E2D6dFeDeB1487a\n\n post by cuardiper on Apr 30, 2025\n\n cuardiper\n\n That is our own smart contract, from our smart contract is that we will call the updatePriceFeeds. Something like this:\nimport \"@pythnetwork/pyth-sdk-solidity/IPyth.sol\";\nimport \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n//...\n\nfunction modifyPosition(\n uint256 collateral,\n bytes32 key,\n //other params...\n bytes[] calldata priceUpdate\n ) external {\n uint pythFee = pyth.getUpdateFee(priceUpdate);\n pyth.updatePriceFeeds{ value: pythFee }(priceUpdate);\n //...\n\n post by Aditya520 on May 1, 2025\n\n Aditya520\n\n Can you make sure that the msg.value is being passed correctly?\nMake sure your contract has enough balance to cover it?\nIf yes, can you share the transaction as well verify the contracts to help us debug.\n\n post by cuardiper on May 1, 2025\n\n cuardiper\n\n Yes, we already sent more than enough Base ETH to the contract to pay the fee. It has around $10 (0.00307 ETH). Exactly same amount as we started, did not spent any of it on the multiple attempts we did.\nI am going to ask team to verify the contract\n\n post by cuardiper on May 6, 2025\n\n cuardiper\n\n Fixed, in case it helps someone…I had to append a “0x” to the update elements before calling the smart contract, here is the code:\n\nlet updatesToSend = [];\n if (priceUpdates.binary.data) {\n //Loop each priceUpdate and append \"0x\" at the start\n updatesToSend = priceUpdates.binary.data.map((update) => {\n return \"0x\" + update;\n });\n }\n\nconst data = encodeFunctionData({\n abi: FuturesABI,\n functionName: \"modifyPosition\",\n args: [\n //Other arguments....,\n updatesToSend,\n ],\n });\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 720\n\n Apr 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 655\n\n May 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Error Implementation with Thirdweb\n\n Price Feeds\n\n 4\n\n 586\n\n Apr 2025\n\n Powered by Discourse","tokens":1971,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265758270,"hash":"48de790d4522186e4c00b00912d5d45094293c8f"}
{"url":"https://forum.openzeppelin.com/c/general/16","domain":"forum.openzeppelin.com","title":"Latest General topics - OpenZeppelin Forum","text":"Latest topics in General\n\n General\n\n Get to know the OpenZeppelin community and learn about upcoming events.\n\n General\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Announcements\n\n Get the news about releases, content, projects, and events.\n\n Events\n\n All you need to know about latest and upcoming events\n\n Meta\n\n Discussions about this forum configuration, categories, rules and meta.\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Welcome to the OpenZeppelin Community!\n\n General\n\n Welcome to the OpenZeppelin Community! \nThis is a public forum for developers to learn, discuss and explore design patterns and best practices about smart contract development. \nIf you have any feedback, we’d love to hea…\n\n read more\n\n 0\n\n 6.4k\n\n Oct 2020\n\n Frequently Asked Questions (FAQ)\n\n General\n\n When will the next version of an OpenZeppelin project be released?\nSee the OpenZeppelin open-source processes: Redesigning OpenZeppelin open-source processes \nWhere can I find documentation on OpenZeppelin projects?\nDocu…\n\n read more\n\n 0\n\n 2.0k\n\n Feb 2020\n\n Introduce yourself here!\n\n General\n\n Welcome to the OpenZeppelin Community forum \nThis thread is for you to say hello to everyone in the community and tell more about you \nIf you’re not sure how, try with some of these: \n\nWhy are you h…\n\n read more\n\n 453\n\n 50.6k\n\n Jan 22\n\n I’ve met that bug in website, where should I tell about it?\n\n Meta\n\n 1\n\n 38\n\n May 21\n\n Issue with Level 0 of The Ethernaut\n\n General\n\n ethernaut\n\n 0\n\n 49\n\n Apr 16\n\n Sharing Experiences with Immunefi Bug Bounties\n\n Events\n\n 0\n\n 52\n\n Jan 22\n\n Is Crypto Currency is Still a Mystery in 2026?\n\n General\n\n crypto-trends\n\n 0\n\n 44\n\n Jan 17\n\n Issue compiling MEV bot (Rusty-Sando) due to deleted Foundry branches and Solar/ethers conflicts\n\n Events\n\n erc20,foundry\n\n 0\n\n 46\n\n Jan 3\n\n To allow trading on the stock exchange with leverage means giving your project to the stock exchange to be torn to pieces?!\n\n General\n\n 4\n\n 769\n\n Sep 2025\n\n How to Use OpenZeppelin Contracts for a Beginner ERC-20 Token Project?\n\n General\n\n 5\n\n 258\n\n Aug 2025\n\n Unable to sell tokens - scam?\n\n General\n\n erc20,bep20\n\n 34\n\n 4.9k\n\n Aug 2025\n\n What Monetization Models Work Best for Online Auction Websites?\n\n General\n\n 0\n\n 32\n\n Jul 2025\n\n getAccounts not working in web3js\n\n General\n\n web3js\n\n 1\n\n 55\n\n Jul 2025\n\n How to Add a New Language to Ethernaut?\n\n General\n\n 0\n\n 39\n\n Jul 2025\n\n Truffle refuses to work!\n\n General\n\n truffle\n\n 1\n\n 60\n\n Jul 2025\n\n Help with Contract Verification on Binance\n\n General\n\n etherscan-verify,bep20\n\n 0\n\n 43\n\n Jun 2025\n\n What Factors Affect the Cost of Smart Contract Audits with OpenZeppelin Standards?\n\n General\n\n 3\n\n 222\n\n May 2025\n\n How to connect tronlink wallet with tron ide\n\n General\n\n erc20\n\n 5\n\n 231\n\n May 2025\n\n Need someone expert in create a stablecoin\n\n General\n\n erc20\n\n 3\n\n 481\n\n May 2025\n\n New here. But thank you\n\n General\n\n 1\n\n 269\n\n Apr 2025\n\n How to Estimate the Cost of Developing Secure Smart Contracts Using OpenZeppelin Libraries?\n\n General\n\n erc20,proxies,upgrades\n\n 1\n\n 141\n\n Apr 2025\n\n Is Defender sales/support service alive?\n\n General\n\n 0\n\n 47\n\n Apr 2025\n\n How to creat TRC20 Network Mimic Tether USDT\n\n General\n\n erc20\n\n 0\n\n 213\n\n Apr 2025\n\n Attack with bot sweeper anyone can help me?\n\n General\n\n bep20\n\n 6\n\n 1.9k\n\n Apr 2025\n\n OpenZeppelin Security Center Audits compiler version\n\n General\n\n 0\n\n 42\n\n Apr 2025\n\n Can you help to sell a token?\n\n General\n\n bep20,pancake\n\n 3\n\n 84\n\n Mar 2025\n\n OpenZeppelin 4.x EOL\n\n Meta\n\n openzeppelin-contracts\n\n 1\n\n 42\n\n Mar 2025\n\n Can someone explain how smart contracts work?\n\n General\n\n 0\n\n 55\n\n Mar 2025\n\n Looking for Someone to Champion the Diamond Standard for OpenZeppelin\n\n General\n\n proxies,upgrades\n\n 11\n\n 2.7k\n\n Feb 2025\n\n Transaction underpriced on Metamask?\n\n General\n\n erc721\n\n 1\n\n 1.3k\n\n Feb 2025","tokens":956,"squid":"ink-security_audits","role":"Sentinel","at":1791265768669,"hash":"d1cbd0ff5ffce01a1b15303ab9bd01c29c45fad2"}
{"url":"https://dev-forum.pyth.network/t/we-are-facing-an-issue-with-the-update-price-feeds-with-funder-function-when-updating-the-pyth-price/144","domain":"dev-forum.pyth.network","title":"We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n May 2025\n\n 1 / 4\n\n May 2025\n\n May 2025\n\n post by Ajay on May 9, 2025\n\n Ajay\n\n I am using the update_price_feeds_with_funder function to generate the payload and submit a transaction every 30 seconds.\nMy price feed ID is:\n0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\nThe testnet endpoint I’m using is:\nhttps://hermes-beta.pyth.network/v2/updates/price/stream?ids[]\nIn my code, I’ve added logs to verify the fetched price, and the price updates correctly on each transaction. For example:\n\nFirst transaction:\nprice: '563526640', publish_time: 1746776909\nNext transaction:\nprice: '563596450', publish_time: 1746776939\n\nThe transactions are being submitted successfully. However, some transactions do not return any events, even though they are confirmed on-chain.\nThis inconsistency is causing issues — in particular, we are seeing the following Pyth error:\npyth: 0x80004\nThis is my code:\n\nconst priceIds = \"0x44a93dddd8effa54ea51076c4e851b6cbbfd938e82eb90197de38fe8876bb66e\";\nconst connection = new HermesClient(\"https://hermes-beta.pyth.network/v2/updates/price/stream?ids[]\", {});\nconst priceFeedUpdateData = await connection.getLatestPriceUpdates(priceIds, {\n encoding: \"base64\",\n});\nconst binaryDataAsNumbers: number[][] = priceFeedUpdateData.binary.data.map((base64String: string) =>\n Array.from(Buffer.from(base64String, \"base64\"))\n);\nconst payloadResponse = {\n function: \"0x7e783b349d3e89cf5931af376ebeadbfab855b3fa239b7ada8f5a92fbea6b387::pyth::update_price_feeds_with_funder\",\n functionArguments: [binaryDataAsNumbers],\n typeArguments: [],\n} as InputEntryFunctionData;\n\nCan someone please look into this and help us resolve the issue?\n\n 2\n\n 2\n\n post by ali on May 9, 2025\n\n ali\n\n Hey @Ajay, the transaction returns an event once the on-chain state changes and when it doesn’t change it means that the provided update data was not more fresh than the existing one. Are you sure that each time you are sending the transaction the update time is increasing? If so can you log the update data as well as the publish_time between updates and share the information about two consecutive updates?\nThe error 80004 also means price is stale; in your context it probably means that update data you sent was not fresh, the state didn’t get updated, and when you used it it passed your staleness threshold. What is your staleness threshold?\n\n post by Ajay on May 9, 2025\n\n Ajay\n\n Hi @ali\nHere is the Information about two consecutive updates:\nIn the first transaction:\n\nPrice: 569261464\nPublish Time: 1746787890\nAn event was emitted.\n\nIn the second transaction:\n\nPrice: 568762401\nPublish Time: 1746787919\nNo event was emitted.\n\nIn the third transaction:\n\nPrice: 569150459\nPublish Time: 1746787950\nAn event was emitted.\n\nAs you can see, the price and publish_time are different in all three transactions. However, only two of them emitted an event, while one did not.\n\nEvent Emitted Hash: 0xc95fbde9fff563ebf8a56b0bf236d41ace94b68efd83e6db159bdb0e9a04ef4d\nEvent Not Emitted Hash: 0x565ef6758a82b76a41a0395b718b5288f5f4264d13ebd9043a8fb71f85004a92\n\nCould you pls look into this.\n\n post by ali on May 9, 2025\n\n ali\n\n I checked this and it seems there was another transaction right before the one with no events that had the exact same update. that’s why. It seems others (or maybe yourself with a different account) are updating the price at the same time.\nThat being said it should not cause the staleness issue then. How often do you see it.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n I’m currently facing an issue related to the Pyth (pyth: 0x80004)\n\n Price Feeds\n\n 5\n\n 615\n\n Apr 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 774\n\n May 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Powered by Discourse","tokens":1951,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265768915,"hash":"e917a479550cadf323cce6d6375f06b1a985a60c"}
{"url":"https://governance.aave.com/t/arfc-revision-of-eth-btc-collateral-efficiency-on-aave/25649","domain":"governance.aave.com","title":"[ARFC] Revision of ETH & BTC Collateral Efficiency on Aave - Governance / General - Aave","text":"[ARFC] Revision of ETH & BTC Collateral Efficiency on Aave \n\n GovernanceGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 16\n\n 1 / 3\n\n Sep 16\n\n Sep 21\n\n post by LlamaRisk on Sep 16\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nThis ARFC proposes raising the LTV and liquidation threshold of the ETH and BTC collateral families on Aave V3 Ethereum Core, Arbitrum, and Base, and the collateral factors of the same assets on the Aave V4 Ethereum Main Spoke. The proposed settings follow from a calibration against historical price behavior and Chainlink price feed updates, which are dense during fast markets and span both the February 2025 and October 2025 stress events. Each threshold is sized to the 99.9th percentile of the worst excursion inside a 1 hour window, the period over which positions are cleared through sequential liquidation calls, at the reserve’s liquidation bonus.\nThe proposed changes are the following:\n\nWETH moves to 81% LTV and 84% LT on Ethereum Core, Base, and Arbitrum.\nwstETH moves to 79% LTV and 82% LT and weETH to 78% LTV and 81% LT on Ethereum Core.\nWBTC moves to 81% LTV and 85% LT on Ethereum Core and to 78% LTV and 82% LT on Arbitrum.\ncbBTC moves to 81% LTV and 85% LT on Ethereum Core and to 81% LTV and 84% LT on Base, with the Base liquidation bonus lowered to 6.00% and the Base cbBTC Stablecoins E-Mode raised to 82% LTV and 85% LT.\nOn the Aave V4 Main Spoke, the collateral factor moves to 84% for WETH, 82% for wstETH, 81% for weETH, and 85% for WBTC and cbBTC, applied as a dynamic configuration update.\n\nThe analysis supports these settings on the following grounds:\n\nETH remains materially more volatile than BTC, with two-year annualized volatility of 68.8% against 44.4% and deeper excursion tails at every window. The 1 hour p99.9 excursion is -11.85% for ETH and -5.09% for BTC on its binding leg.\nThe recommended ETH family thresholds sit inside the buffer implied by the basis at each reserve’s live bonus. WETH is set at its ceiling, and wstETH and weETH one point inside theirs.\nThe BTC settings of 82 to 85% sit deliberately deep inside the buffer implied by the basis, as margin against depth, cap, and concentration risks the price model does not capture.\nThe basis covers every realized 1 hour excursion of the two-year record up to its 99.9th percentile and relies on the measured liquidation cadence, which kept position marks seconds to minutes fresh through both stress events. The residual scenario outside the basis is a stalled oracle and liquidation pipeline coinciding with a move beyond that percentile, with the realized worst at -24.27% for ETH and -11.15% for BTC over one hour.\nLiquidation processing is measured in seconds on every market examined, the slow tail is attributed to dust debt, and the two stress events produced $0 and $0.39M of bad debt respectively, with no bad debt for the analyzed collateral.\nThe same framework applied to the Aave V4 Main Spoke, the V4 counterpart of the Ethereum Core market, supports the same moves as V3, as the same Chainlink SVR auction setup is applied for both markets, integrating a set of robust searchers.\n\nMotivation\nAave’s bluechip collateral parameters have remained relatively stable over time, even as market conditions and volatility risk profiles have changed. This creates a trade-off in which overly conservative parameters reduce how much users can borrow against their collateral. The purpose of this assessment is to determine whether current LTV and LT parameters are consistent with the observed volatility and liquidity of each collateral asset, and this ARFC proposes the parameter changes that follow from it.\nMethodology\nLiquidation window\nThe window is the period over which the tail move is measured and it is the single largest input to the resulting parameter. We measure it from liquidation behaviour in two parts. The first is the time each liquidation call spent at or below the price at which it executed, weighted by the value being processed, computed with a single code path across markets, each market joined against the feed its Aave deployment reads and against stablecoin debt, over August 2025 to August 2026.\n\nMarket\nCollateral\nLiquidations\nSeized\nWeighted median\nWeighted p95\nWeighted p99\nValue below price over 1 h\n\nEthereum Core\nETH\n7,206\n$618M\nunder 1 s\n2.0 min\n5 min\n0.00%\n\nEthereum Core\nBTC\n2,621\n$358M\nunder 1 s\n2.2 min\n5 min\n0.07%\n\nArbitrum\nETH\n5,699\n$41M\nunder 1 s\n18 s\n2 min\n0.00%\n\nArbitrum\nBTC\n1,819\n$18M\nunder 1 s\n48 s\n2 min\n0.00%\n\nBase\nETH\n7,448\n$20M\nunder 1 s\n48 s\n2 min\n0.02%\n\nBase\nBTC\n1,444\n$22M\nunder 1 s\n1.1 min\n2 min\n0.00%\n\nliquidation_window2520×990 137 KB\nSource: LlamaRisk, August 29, 2026\nWeighted by value, every market clears its economically meaningful liquidations within minutes of the price crossing, and the share of processed value that had been below its liquidation price for more than an hour is at most 0.07%. The event-count tail reaches hours only through dust positions whose bonus barely covers gas, the same tail quantified in the processing section below. The exposure that the threshold must cover is therefore the work-off of a position rather than a clearing span. A liquidation call repays at most half the outstanding debt, so a large position clears through roughly five sequential calls, each landing on a feed publication. Across both stress events on Ethereum Core the value-weighted gap between consecutive calls on the same position had a median under one minute and a p95 of 15 to 21 minutes. One hour covers the work-off of the bulk of value with margin on every market examined, and Arbitrum and Base sit inside the Core distribution on every quantile. We therefore adopt a 1 hour work-off window as the basis for both families.\nLiquidation processing\nThe window above measures how long a position stays exposed. Processing speed measures how quickly liquidators act once a feed publication makes a position liquidatable. We measured the lag between each liquidation and the most recent publication of either leg of its pair on Aave V3 Ethereum Core, Arbitrum, and Base across the two largest stress events of the observation period. Ethereum is joined against the SVR publications Aave reads where they were live, which is October 2025, and against the pre-SVR standard aggregators in February 2025.\n\nEvent\nMarket\nLiquidations\nSeized\nMedian lag\np75\np95\nVolume within 1 min\nVolume within 5 min\n\nFebruary 2 to 4, 2025\nEthereum Core\n936\n$172M\n24 s\n51 s\n10.3 min\n95%\n100%\n\nFebruary 2 to 4, 2025\nArbitrum\n1,511\n$15M\n6 s\n17 s\n57 s\n100%\n100%\n\nFebruary 2 to 4, 2025\nBase\n1,435\n$9M\n10 s\n28 s\n2.0 min\n99%\n100%\n\nOctober 10 to 12, 2025\nEthereum Core\n430\n$100M\n36 s\n72 s\n6.0 min\n63%\n100%\n\nOctober 10 to 12, 2025\nArbitrum\n346\n$17M\n1 s\n10 s\n23 s\n100%\n100%\n\nOctober 10 to 12, 2025\nBase\n392\n$6M\n2 s\n4 s\n2.8 min\n100%\n100%\n\nprocessing_lag2520×990 141 KB\nSource: LlamaRisk, August 29, 2026\nLiquidations execute at feed speed even at peak congestion. Nearly all seized volume clears within five minutes of the publication that made it profitable, so liquidator responsiveness is not the binding constraint on the parameters. Arbitrum and Base, whose feeds print on tighter deviations and whose execution gas is negligible, clear faster than Ethereum Core with no lag tail at all, so the Core benchmark is the conservative one for the markets receiving the proposed increases.\nThe latency tail consists almost entirely of dust positions. Broken down by lag behind the triggering publication on Ethereum Core across both stress windows, liquidations slower than five minutes were 11.1% of events but 0.23% of seized volume. The residual sub-hour maxima are dust positions whose bonus barely covers mainnet gas, together with positions pushed over the threshold by interest accrual between publications rather than by a fresh print.\n\nLag behind print\nEvents\nShare of events\nShare of seized USD\nMedian size\n\nunder 1 min\n967\n70.8%\n78.6%\n$21,833\n\n1 to 5 min\n248\n18.2%\n21.2%\n$16,958\n\n5 to 15 min\n112\n8.2%\n0.2%\n$993\n\nover 15 min\n39\n2.9%\n0.0%\n$341\n\nLiquidators clear economically meaningful positions at feed speed and defer only positions where the bonus barely covers gas. The processing tail therefore carries no bad debt relevance.\nFast processing does not mean a position is cleared at its first touch of the threshold. A liquidation call repays at most half of the outstanding debt, resets the health factor slightly above one, and leaves the remainder exposed to the next leg down. In the February event, 32% of liquidated users across all deployments were liquidated more than once, and these users accounted for 64% of all seized volume, with a median of 3.5 hours between a user’s first and last liquidation and a p90 of roughly 10 hours.\nfeb_2025_eth_cascade2520×1080 200 KB\noct_2025_btc_cascade2520×1080 162 KB\nSource: LlamaRisk, August 29, 2026\nBoth events cleared with negligible bad debt. February produced no recognized deficit at all, and October produced $0.39M against roughly $128M, without affecting the ETH- and BTC-family collateral across all deployments. The liquidation machinery has held through both stress events at current parameters.\nLiquidation bonus\nThe liquidation bonus is an input to the derivation. The threshold has to cover the tail move and the bonus paid to the liquidator, so a higher bonus mechanically supports a lower threshold at the same level of risk. Each reserve is therefore assessed at its own live bonus rather than a single assumed value. The same asset carries different bonuses on different deployments, with WBTC at 5.00% on Ethereum and 8.50% on Polygon, and that difference moves the supportable threshold by several points due to the impact to the bad debt buffer of the protocol.\nParameter derivation\nThe model ceiling for the liquidation threshold is the largest value at which the collateral remaining after the basis move still covers the debt plus the bonus:\nLT ceiling = round((1 - |p99.9 excursion|) / (1 + LB))\n\nEach reserve is assessed at its recommended bonus where one is proposed and at its live bonus otherwise. Recommended thresholds are set relative to the ceiling: WETH at the ceiling, the rest of the ETH family one point inside it, and BTC at least three points inside it as margin against depth, cap, and concentration risks the price model does not capture.\nIn the open market every borrowable reserve is reachable from every collateral, so each collateral is assessed against every debt leg its deployment exposes and takes the lowest result.\nCalibration Results\nRealized tails and supported thresholds\nAll windows measured on the two-year deviation-threshold series, including February 2025. The 1 hour row is the basis for both families.\n\nWindow\nETH p99\nETH p99.9\nETH worst\nBTC p99\nBTC p99.9\nBTC worst\n\nsingle print\n-0.88%\n-1.66%\n-4.75%\n-0.71%\n-1.14%\n-3.44%\n\n5 min\n-1.16%\n-3.09%\n-13.31%\n-0.63%\n-2.04%\n-5.61%\n\n15 min\n-2.00%\n-6.28%\n-18.02%\n-1.19%\n-3.14%\n-8.45%\n\n30 min\n-2.88%\n-11.75%\n-22.02%\n-1.72%\n-4.06%\n-10.08%\n\n1 h (basis)\n-3.94%\n-11.85%\n-24.27%\n-2.39%\n-5.03%\n-10.72%\n\n2 h\n-5.19%\n-14.61%\n-26.24%\n-3.33%\n-6.28%\n-10.72%\n\n4 h\n-7.10%\n-24.13%\n-28.43%\n-4.69%\n-7.44%\n-11.32%\n\n6 h\n-8.63%\n-24.45%\n-29.25%\n-5.61%\n-9.55%\n-12.77%\n\n12 h\n-12.46%\n-27.25%\n-33.64%\n-6.88%\n-13.78%\n-16.38%\n\n1 d\n-16.73%\n-29.74%\n-35.06%\n-9.89%\n-17.05%\n-19.75%\n\nexcursion_tails2520×990 183 KB\nSource: LlamaRisk, August 29, 2026\nThe chart below plots the model ceiling at each work-off window across the live bonus range, with the 1 hour basis marked.\nsupported_threshold_vs_window2520×990 212 KB\nSource: LlamaRisk, August 29, 2026\nThe basis covers any 1 hour excursion up to the 99.9th percentile of the two-year record, which spans the whole of the October 2025 event and all but the core legs of February 3, 2025, and it relies on the measured liquidation cadence keeping position marks seconds to minutes fresh. The residual scenario outside the basis is a maximally levered position marked at its threshold at the start of a move beyond that percentile, with no liquidation landing for the full hour. Reaching it requires the oracle cadence and the liquidation pipeline to stall together through the worst 0.1% hour of two years, which did not happen in either stress event, where calls landed at a median of 24 seconds behind their triggering publication throughout.\nwstETH and weETH\nThe two established LSTs warrant a similar empirical treatment as the canonical wrappers. Across the two years to August 2026 they account for 6,486 liquidations and roughly $361M of seized collateral across all deployments, $296M of it wstETH and $47M weETH, overwhelmingly against stablecoin debt. Processing speed during both stress events was indistinguishable from WETH. On Ethereum Core the median lag behind the triggering publication was 12 s for LST collateral against 24 s for WETH in February 2025, and 72 s against 24 s in October 2025 on the sparser SVR publications, with lower p95 values than WETH in both events. The liquidation pipeline treats them as blue-chip collateral in practice.\nInstant exit liquidity, quoted through aggregate routing against the on-chain redemption rate, supports the same conclusion within the sizes the protocol has actually needed.\nlst_exit_liquidity2520×990 123 KB\nSource: LlamaRisk, August 29, 2026\nwstETH exits at under 0.05% discount up to roughly $24M and 0.55% at $47M, with the route exhausting beyond about $55M. weETH exits at under 0.25% up to roughly $21M and exhausts beyond about $25M. For comparison, the entire February 2025 cascade seized $39M of LST collateral on Ethereum Core spread over several hours, well inside these depths.\nOn this evidence both assets are assessed on the measured ETH basis, and their processing and depth place them in the same tier as WETH. Against live settings of 81% and 80%, we recommend raising wstETH to 82% and weETH to 81% on Ethereum, each one point inside the ceiling at its live bonus, and WETH to 84%, at its ceiling. The conservatism in weETH’s configuration sits in its 7.00% bonus against wstETH’s 6.00% despite comparable processing speed and depth proportionate to its supply.\nSpecification\nArbitrum\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nBorrowable assets\n\nWETH\n80.0%\n84.0%\n5.00%\n81%\n-\nWBTC, WETH, GHO, USDC, USD₮0\n\nWBTC\n73.0%\n78.0%\n7.00%\n78%\n82%\nWBTC, WETH, GHO, USDC, USD₮0\n\nBase\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nRecommended LB\nBorrowable assets\n\nWETH\n80.0%\n83.0%\n5.00%\n81%\n84%\n-\nWETH, cbBTC, EURC, GHO, USDC\n\ncbBTC\n73.0%\n78.0%\n7.50%\n81%\n84%\n6.00%\nWETH, cbBTC, EURC, GHO, USDC\n\nDue to robust cbBTC liquidity on Base (~$33M in stables) we also recommend lowering liquidation bonus to 6.00%.\nE-Mode\n\nAsset\nE-Mode\nCategory ID\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\nBorrowable assets\n\ncbBTC\ncbBTC Stablecoins\n10\n80.0%\n83.0%\n4.00%\n82%\n85%\nGHO, USDC\n\nEthereum Core\n\nAsset\nCurrent LTV\nCurrent LT\nLB\nRecommended LTV\nRecommended LT\n\nWETH\n80.5%\n83.0%\n5.00%\n81%\n84%\n\nWBTC\n73.0%\n78.0%\n5.00%\n81%\n85%\n\ncbBTC\n73.0%\n78.0%\n7.50%\n81%\n85%\n\nwstETH\n78.5%\n81.0%\n6.00%\n79%\n82%\n\nweETH\n77.5%\n80.0%\n7.00%\n78%\n81%\n\nLiquidation bonuses on Ethereum Core stay at their current values, including the 7.50% bonus on cbBTC, even though the depth that supports a 6.00% bonus on Base is also present on Ethereum. An increase to the liquidation protocol fee for these assets on Ethereum Core is pending. The protocol fee is taken out of the liquidation bonus, so lowering the bonus at the same time would reduce the liquidator’s net share from both sides.\nAave V4 Ethereum Main Spoke\nThe Main Spoke is the V4 counterpart of the V3 Ethereum Core market and is assessed identically, on the same basis and with each reserve at its recommended maximum liquidation bonus where one is proposed and at its live maximum otherwise, with WETH, WBTC, and cbBTC as volatile debt alongside deep stablecoins.\n\nAsset\nCurrent CF\nMax LB\nRecommended CF\nRecommended Max LB\n\nWETH\n83.0%\n5.55%\n84%\n-\n\nwstETH\n80.0%\n6.66%\n82%\n-\n\nweETH\n80.0%\n7.77%\n81%\n-\n\nWBTC\n78.0%\n5.55%\n85%\n-\n\ncbBTC\n78.0%\n5.55%\n85%\n-\n\nFor the CF changes, we recommend performing a configuration update instead of deploying a new collateral configuration.\nNext Steps\n\nGather community and service provider feedback on this ARFC.\nIf consensus is reached, escalate this proposal to the Snapshot stage.\nIf the Snapshot outcome is positive, submit the changes for implementation as an AIP.\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n 2\n\n read \n\n 7\n min\n\n post by Foreshock on Sep 20\n\n post by LlamaRisk on Sep 21\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core\n\n Governance\n\n 1\n\n 265\n\n Aug 21\n\n Independent Liquidation-Capacity Stress Tests For Aave\n\n Risk\n\n 1\n\n 218\n\n Aug 25\n\n [ARFC] Deploy Aave V4 on Base\n\n New Asset\n\n 7\n\n 1.3k\n\n 11d\n\n [TEMP CHECK] Post-rsETH Collateral Framework: Tier-Based LTV Reductions and Wrap-Depth Ineligibility Limits\n\n Risk\n\n 17\n\n 1.3k\n\n Jul 26\n\n Post Vyper Exploit - CRV Market Update and Recommendations\n\n General\n\n 48\n\n 8.1k\n\n Aug 29","tokens":4390,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265782349,"hash":"174ca3f79b569c3db1a2e23c6c5f467a9dffbaf7"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/15","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 15 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 12, 2018\n\n post by ldct on Jan 12, 2018\n\n post by kladkogex on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 15, 2018\n\n post by vbuterin on Jan 15, 2018\n\n post by AFDudley on Jan 17, 2018\n\n post by ltfschoen on Jan 17, 2018\n\n post by MicahZoltu on Jan 17, 2018\n\n post by mrsmkl on Jan 19, 2018\n\n post by JustinDrake on Jan 20, 2018\n\n Load more posts below","tokens":1291,"squid":"ink-research","role":"Deep Scholar","at":1791265795417,"hash":"d3435d6de00b72c625cabc3aced410e1c7615665"}
{"url":"https://base.org/","domain":"base.org","title":"Base","text":"The blockchainfor global finance.Built by Coinbase, trusted by leading institutions, and open to all.Build on BaseExplore EcosystemTrusted by 1,000+ businesses.TradingPower your platform with embedded trading and asset tokenization.PaymentsEnable global, low-fee payments for your business with instant settlement.AgentsMonetize your services, fund agent wallets, and set spend guardrails.Where the world transacts onchain.Base is the leading blockchain across the metrics that matter most.$0B+Total Value Locked$0B+Assets on Base0M+Agentic Payments$0T+Stablecoin Transfers (1Y)Base is the platform for financialtransactions at scale.Instant, low-cost, 24/7Sub-second transactions for fractions of a cent. Always on, always fast, from anywhere in the world.Always-on liquid marketsDeep liquidity and high-quality assets around the clock. The home of onchain trading and DeFi.Secure & trustedBuilt on Ethereum with the same focus on security powering Coinbase products. Trusted by millions worldwide.A bridge, not an islandInteroperable across chains and ecosystems. Move seamlessly across networks and access value everywhere.Latest Releases.Introducing Base AzulAzul makes Base more secure, more performant, and easier to build on.April 22, 2026Best Place to Trade OnchainYour new trading and discovery experience is live on the Base App.April 20, 2026Meet the New Base DashboardBase.dev is now Base Dashboard. Register your apps and get rewarded on Base.April 18, 2026Builder Codes & ERC-8021A system for apps to prove their impact onchain and receive credit for the transactions they generate.April 15, 2026Unified Base Chain StackBase is evolving its tech stack, paving the path for further scaling, innovation, and decentralization.April 10, 2026Start building on Base.Build on the open economy. Fast, liquid and always on.Build on BaseRequest Demo","tokens":463,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265803985,"hash":"286193856f5d0f3d91fd6412e08bf760c1675e37"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/16","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 16 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by ldct on Jan 12, 2018\n\n post by kladkogex on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 15, 2018\n\n post by vbuterin on Jan 15, 2018\n\n post by AFDudley on Jan 17, 2018\n\n post by ltfschoen on Jan 17, 2018\n\n post by MicahZoltu on Jan 17, 2018\n\n post by mrsmkl on Jan 19, 2018\n\n post by JustinDrake on Jan 20, 2018\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n Load more posts below","tokens":1732,"squid":"ink-research","role":"Deep Scholar","at":1791265805651,"hash":"d5de401488c3678708cd56620b5e4764f4861469"}
{"url":"https://www.base.org/agents","domain":"base.org","title":"Base","text":"AgentsFinancial infrastructure for AI agents.Monetize your services, fund your agent wallets, and set spend guardrails.Install MCPBuild on Base█──██████────██████──██─██────██──██────██─█─███─██─██████─██─███──██────██──██────██───██████────██████== AI PAYMENTS AGENT v0.2 ==--------------------------------------------[_Use CasesUnlock new revenue streams with AI agents.Autonomous TradingGive your agent a wallet and enable them to manage portfolios, execute trades, and rebalance positions across DeFi protocols.Agentic PaymentsAgents pay USDC to level up their abilities, choosing from thousands of x402 enabled services spanning inference, data, search and other categories.Monetize Your ServicesSell your API or product to agents in minutes by integrating x402 and becoming discoverable in agentic.market. No API keys, no subscriptions, just pay-per-request.Base MCPGive your agent a wallet.Connect your agent to a Base Account and let it interact with protocols across the Base Ecosystem with simple prompts.1Pick your AI toolWe'll give you the exact command to run.2Connect the MCPWorks in Claude.ai (web, iOS, Android) and Claude Desktop.Connect Claude3Install the skillThe base-mcp skill extends your assistant with pre-built prompts and workflows for wallet operations, token transfers, and DeFi interactions on Base.4Try it outBase MCP is connected. Try one of these prompts.MoonwellShow me the highest USDC yield on Base using MoonwellUniswapFind Uniswap liquidity pools on Base for tokens I holdMorphoWhich Morpho Markets currently offer the lowest borrow rates for cbBTC?AvantisShow available RWA markets on AvantisBankrShow the latest tokens launched on BankrAerodromeCompare ETH/USDC pools on Aerodrome by liquidity and incentivesVirtualsShow me Virtuals agents that can accept payments and coordinate work on BaseEcosystemDiscover the ecosystem.BankrAutonomous portfolio manager. Analyzes markets, executes trades, and optimizes yield across Base protocols.x402 EcosystemDiscover APIs, services, and infrastructure built on the x402 payment protocol. From AI inference to market data - all payable per request.Cloudflare x402Pay-per-request APIs at the edge. Any worker can accept agent payments via a single middleware.VirtualsDeploy and coordinate AI agent swarms. Launch agents with their own tokens, revenue, and onchain operations.0MAgent Transactions$0M+Payment Volume0K+Active Agents0K+x402 API EndpointsToolsEverything your agent needs.Base SkillsPre-built, drop-in skills developed by our ecosystem for AI agents on Base.Get StartedAgentic WalletsGive your agent a wallet with spending limits and policy controls. Built for any use case, from social tipping to autonomous hiring. No private key management required.Get StartedBuilt for interoperability, no vendor lock-in.The agentic economy requires open, composable standards that any builder can adopt. Base is leading the development of protocols that let agents transact and identify themselves without gatekeepers.x402 — HTTP Payment ProtocolExtends HTTP with native payment semantics. Any API can require payment with a single header. Any agent can pay with a single request.ERC-8004 — Native Agent IdentityA standard for agent identity onchain. Enables verifiable reputation, permissioned access, and trust in multi-agent coordination.Start building on Base.Build on the open economy. Fast, liquid and always on.Build on BaseRequest Demo","tokens":856,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265815125,"hash":"d2e0118d66ac68be890abb26604eb9253ca8cf21"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/17","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 17 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by denett on Jan 13, 2018\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 15, 2018\n\n post by vbuterin on Jan 15, 2018\n\n post by AFDudley on Jan 17, 2018\n\n post by ltfschoen on Jan 17, 2018\n\n post by MicahZoltu on Jan 17, 2018\n\n post by mrsmkl on Jan 19, 2018\n\n post by JustinDrake on Jan 20, 2018\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n post by vbuterin on Jan 29, 2018\n\n Load more posts below","tokens":1127,"squid":"ink-research","role":"Deep Scholar","at":1791265815750,"hash":"15b9794848cd1f12aaf6df292ed0f944662bd047"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/18","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 18 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 12, 2018\n\n post by kz on Jan 12, 2018\n\n post by denett on Jan 13, 2018\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 15, 2018\n\n post by vbuterin on Jan 15, 2018\n\n post by AFDudley on Jan 17, 2018\n\n post by ltfschoen on Jan 17, 2018\n\n post by MicahZoltu on Jan 17, 2018\n\n post by mrsmkl on Jan 19, 2018\n\n post by JustinDrake on Jan 20, 2018\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n post by vbuterin on Jan 29, 2018\n\n post by kladkogex on Jan 29, 2018\n\n Load more posts below","tokens":1202,"squid":"ink-research","role":"Deep Scholar","at":1791265825949,"hash":"168d3ba874071df1a4fe4f5552e6a439664fbf10"}
{"url":"https://forum.soliditylang.org/t/solidity-v0-8-33-is-out/3651","domain":"forum.soliditylang.org","title":"Solidity v0.8.33 is out! ✨ - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2025\n\n 1 / 1\n\n Dec 2025\n\n Dec 2025\n\n post by r0qs on Dec 19, 2025\n\n r0qs\n\n Solidity Compiler Team\n\n We just released versions 0.8.32 and 0.8.33 of the Solidity Compiler.\n Note: We recommend skipping 0.8.32 and upgrading directly to 0.8.33, which contains a hotfix for an issue introduced in 0.8.32.\nImportant Bugfixes\nLost Storage Array Write On Slot Overflow\nVersion 0.8.32 fixes a bug affecting operations that involve clearing or copying arrays that straddle the end of storage. The bug manifests only in contracts that use very unusual storage layouts, intentionally bypassing the compiler’s safeguards. The bug existed since v0.1.0, affects both pipelines, and is independent of the optimizer.\n Read our blog post describing the bug to learn more about how it was introduced, which contracts could be affected, and what its effects are.\nThanks to @Audittens for reporting this issue!\nOther Notable Changes\nEmitting Events and Reverting with Errors via Module Member Access\nWe fixed the internal compiler error that was triggered when emitting an event or reverting with an error referenced through a module. This is part of our effort to ensure feature parity between free functions and libraries.\nMigration of solc-bin Hosting from AWS to Cloudflare\nWe migrated hosting for historical release binaries from Amazon S3 to Cloudflare R2 to reduce operational costs. Binaries remain available at binaries.soliditylang.org.\n The legacy solc-bin.ethereum.org domain is deprecated, as it is no longer under our control.\nHotfix in 0.8.33\nVersion 0.8.32 unintentionally introduced an internal compiler error when accessing getters of constant state variables. While this doesn’t cause miscompilations or security vulnerabilities, it affects common patterns. Version 0.8.33 addresses this issue and is therefore recommended instead of 0.8.32.\n\nYou can read the full release announcement on our blog:\n\nUsers can download the new version of Solidity Compiler from GitHub:\n\nAnd lastly, we would like to thank all the contributors who helped make this release possible! \n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 55\n\n 26d\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 147\n\n Apr 27\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1522,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265836848,"hash":"cefd31c4059ee7b8cd65b49893bfda8390a4b09d"}
{"url":"https://www.base.org/stocks","domain":"base.org","title":"Base","text":"StocksStocks just got updated.Trade, lend, and borrow stocks 24/7 across the Base ecosystem. Starting with Coinbase Tokenized Stocks.Explore StocksIntegrate StocksAboutWhat are Coinbase Tokenized Stocks?Coinbase Tokenized Stocks are individual US company shares brought onchain, issued by Coinbase and backed 1:1 by shares held in regulated custody.Backed by a real shareEach token is a beneficial claim on a real share, held in regulated, bankruptcy-remote custody separate from Coinbase.Issued by CoinbaseCoinbase issues a matching token 1:1 against the share it holds, so the token tracks real economic exposure to the underlying stock.Tokenized & usable across DeFiThe token is issued as a B20 token on Base, then held in a self-custodial wallet and used across the Base DeFi ecosystem.Available only in eligible jurisdictions outside the US. Read the prospectus & legal disclosures.FeaturesStocks that do more.On Base, stocks do more than sit in a brokerage account. Through participating apps and supported protocols, they can be self-custodied, traded around the clock, and put to work across DeFi.Stocks meet DeFiHold tokenized stocks, then lend, borrow, or use them as collateral across the Base DeFi ecosystem.Trade 24/7, 365Trade tokenized stocks any hour of any day, including weekends and US market holidays.Your keys, your stocksHold your tokenized stocks in a wallet only you control. No brokerage account needed.ListingsStocks on Base.View AllTICKERSTOCKPROSPECTUSCONTRACTNVDAcNVIDIAView Prospectus0xb200...108CNVDAcNVIDIAProspectus0xb200...108CMETAcMetaView Prospectus0xb200...707CMETAcMetaProspectus0xb200...707CAAPLcAppleView Prospectus0xb200...d1fbAAPLcAppleProspectus0xb200...d1fbGOOGLcAlphabetView Prospectus0xb200...58B7GOOGLcAlphabetProspectus0xb200...58B7AMZNcAmazonView Prospectus0xb200...C2E8AMZNcAmazonProspectus0xb200...C2E8MSFTcMicrosoftView Prospectus0xB200...872BMSFTcMicrosoftProspectus0xB200...872BMSTRcStrategyView Prospectus0xb200...883dMSTRcStrategyProspectus0xb200...883dSNDKcSanDiskView Prospectus0xb200...10c5SNDKcSanDiskProspectus0xb200...10c5SPCXcSpaceXView Prospectus0xb200...CBd5SPCXcSpaceXProspectus0xb200...CBd5TSLAcTeslaView Prospectus0xb200...0cD0TSLAcTeslaProspectus0xb200...0cD0AMDcAdvanced Micro Devices, Inc.View Prospectus0xB200...A47BAMDcAdvanced Micro Devices, Inc.Prospectus0xB200...A47BASTScAST SpaceMobile, Inc.View Prospectus0xB200...288aASTScAST SpaceMobile, Inc.Prospectus0xB200...288aAVGOcBroadcom Inc.View Prospectus0xB200...5a4cAVGOcBroadcom Inc.Prospectus0xB200...5a4cBEcBloom Energy CorporationView Prospectus0xb200...122bBEcBloom Energy CorporationProspectus0xb200...122bCAKEcCheesecake Factory IncView Prospectus0xb200...176bCAKEcCheesecake Factory IncProspectus0xb200...176bDJTcTrump Media & Technology Group Corp.View Prospectus0xb200...692BDJTcTrump Media & Technology Group Corp.Prospectus0xb200...692BDUOLcDuolingo, Inc.View Prospectus0xb200...1db7DUOLcDuolingo, Inc.Prospectus0xb200...1db7GMEcGameStop Corp.View Prospectus0xb200...D935GMEcGameStop Corp.Prospectus0xb200...D935HIMScHims & Hers Health, Inc.View Prospectus0xB200...f336HIMScHims & Hers Health, Inc.Prospectus0xB200...f336HTZcHertz Global Holdings, Inc.View Prospectus0xb200...a168HTZcHertz Global Holdings, Inc.Prospectus0xb200...a168LLYcEli Lilly & CoView Prospectus0xB200...4718LLYcEli Lilly & CoProspectus0xB200...4718MRNAcModerna, Inc.View Prospectus0xB200...2468MRNAcModerna, Inc.Prospectus0xB200...2468MRVLcMarvell Technology, Inc.View Prospectus0xB200...9813MRVLcMarvell Technology, Inc.Prospectus0xB200...9813NFLXcNetflix IncView Prospectus0xb200...dFE6NFLXcNetflix IncProspectus0xb200...dFE6NVAXcNovavax IncView Prospectus0xb200...d3a8NVAXcNovavax IncProspectus0xb200...d3a8ORCLcOracle CorporationView Prospectus0xb200...b63CORCLcOracle CorporationProspectus0xb200...b63CPFEcPfizer IncView Prospectus0xb200...b528PFEcPfizer IncProspectus0xb200...b528PMcPhilip Morris International Inc.View Prospectus0xb200...7b66PMcPhilip Morris International Inc.Prospectus0xb200...7b66PTONcPeloton Interactive, Inc.View Prospectus0xb200...aa84PTONcPeloton Interactive, Inc.Prospectus0xb200...aa84PYPLcPayPal Holdings, Inc.View Prospectus0xb200...6c6ePYPLcPayPal Holdings, Inc.Prospectus0xb200...6c6eQUBTcQuantum Computing Inc.View Prospectus0xb200...5bC3QUBTcQuantum Computing Inc.Prospectus0xb200...5bC3RBLXcRoblox CorporationView Prospectus0xB200...9Bb5RBLXcRoblox CorporationProspectus0xB200...9Bb5RDDTcReddit, Inc.View Prospectus0xb200...B7A1RDDTcReddit, Inc.Prospectus0xb200...B7A1SOUNcSoundHound AI, Inc.View Prospectus0xb200...4e88SOUNcSoundHound AI, Inc.Prospectus0xb200...4e88TTWOcTake-Two Interactive Software, Inc.View Prospectus0xB200...67DaTTWOcTake-Two Interactive Software, Inc.Prospectus0xB200...67DaWENcWendy's CoView Prospectus0xb200...e57aWENcWendy's CoProspectus0xb200...e57aThe full list of Coinbase Tokenized Stocks on Base. Match the contract address before you buy. If a token is not on this list, Coinbase did not issue it.ExploreAvailable everywhere you DeFi on Base.Trade, lend, hold, and explore stocks across your favorite Base ecosystem apps and protocols.AerodromeDeep liquidity for tokenized stock trading pairs.AaveLend and borrow against tokenized stock positions.ChainlinkPrice feeds and data infrastructure for tokenized stocks.BitwiseInstitutional crypto asset management.CoinbaseThe issuer of tokenized stocks on Base.0xSwap tokenized stocks with aggregated DEX liquidity.MorphoLend and borrow tokenized stocks with optimized rates.1inchFind the best rates across Base DEXs for stock swaps.EulerModular lending and borrowing for tokenized stocks.KyberSwapEfficient token swaps with concentrated liquidity.CoW SwapMEV-protected trading for tokenized stock orders.BeefyAuto-compounding vaults for tokenized stock yields.GliderTrack performance and automate portfolio strategies.SuperformCross-chain yield strategies with tokenized stocks.LI.FIBridge and swap tokenized stocks across chains.VirtualsAI agents for automated tokenized stock strategies.Banana GunFast sniping and trading for tokenized stocks.SteakhouseRisk analytics and portfolio insights for onchain stocks.Bitget WalletMobile wallet for managing tokenized stock positions.DefinitiveOne-click DeFi execution for tokenized stocks.FusionSmart order routing for tokenized stock trades.SoSoValueResearch and analytics for tokenized stock markets.GrowSimplified DeFi investing with tokenized stocks.Liminal CashOnchain cash management with tokenized stocks.MaestroAutomated trading bots for tokenized stocks.MatchaDEX aggregator for the best token swap prices.AviciSocial trading platform for tokenized stocks.SigmaAdvanced trading terminal for tokenized stocks.ZothInstitutional-grade RWA infrastructure.ClearstarCompliance infrastructure for tokenized securities.ReserveStablecoin infrastructure powering stock settlements.OriginYield-bearing strategies for tokenized stock holders.DialecticQuantitative research and trading strategies.01 exchangeDecentralized exchange for tokenized stock trading.BankrSocial trading and portfolio management for stocks.CentrifugeReal-world asset financing infrastructure.FlaunchToken launch and trading platform.JumperCross-chain bridging and swaps for tokenized stocks.OKX WalletMulti-chain wallet for managing tokenized stocks.Tau LabsDecentralized infrastructure for tokenized assets.TreasuresPortfolio tools for tokenized stock holders.WasabiPerps and options for tokenized stocks.Ample.MoneySave in stablecoins and automatically enter prize draws.CastarCompliance and analytics for tokenized securities.Coinbase WalletThe best place to trade on web and mobile.EnsoDeFi infrastructure for tokenized stock strategies.FomoMobile-first wallet for tokenized stocks.GauntletRisk management and optimization for DeFi protocols.MakinaVault infrastructure for institutional-grade onchain strategies.True MarketsTransparent trading infrastructure for tokenized assets.ZyfAIAI-powered portfolio tools for tokenized stocks.FAQsTokenized stocks introduce new possibilities and new considerations. Always review the product and venue documentation before using them.An onchain token that gives eligible users direct economic exposure to a listed stock. On Base, tokenized stocks are issued as B20 tokens by a regulated issuer, backed 1:1 by a real underlying share held in regulated custody.This page is informational and is not an offer, solicitation, or recommendation to buy or sell any security. Coinbase Tokenized Stocks are issued by Coinbase and offered under Regulation S; only available in eligible jurisdictions outside of the US. Availability, features, and rights vary by product, jurisdiction, and venue. Base is neutral, permissionless infrastructure; it does not issue, sell, or endorse these tokens, and listing a venue is not an endorsement. Verify contract addresses before interacting with any token. Ticker availability, format, and timing are subject to regulatory approval.Start building on Base.Build on the open economy. Fast, liquid and always on.Build on BaseRequest Demo","tokens":2264,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265836949,"hash":"6663f2d446922249202efb8a31684a52d487eb92"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/19","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 19 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n Load more posts below","tokens":3337,"squid":"ink-research","role":"Deep Scholar","at":1791265837347,"hash":"3d0df96ee6a1ddb6c3083ee315e54cc6938baee2"}
{"url":"https://forum.soliditylang.org/t/solidity-v0-8-33-is-out/3651/1","domain":"forum.soliditylang.org","title":"Solidity v0.8.33 is out! ✨ - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2025\n\n 1 / 1\n\n Dec 2025\n\n Dec 2025\n\n post by r0qs on Dec 19, 2025\n\n r0qs\n\n Solidity Compiler Team\n\n We just released versions 0.8.32 and 0.8.33 of the Solidity Compiler.\n Note: We recommend skipping 0.8.32 and upgrading directly to 0.8.33, which contains a hotfix for an issue introduced in 0.8.32.\nImportant Bugfixes\nLost Storage Array Write On Slot Overflow\nVersion 0.8.32 fixes a bug affecting operations that involve clearing or copying arrays that straddle the end of storage. The bug manifests only in contracts that use very unusual storage layouts, intentionally bypassing the compiler’s safeguards. The bug existed since v0.1.0, affects both pipelines, and is independent of the optimizer.\n Read our blog post describing the bug to learn more about how it was introduced, which contracts could be affected, and what its effects are.\nThanks to @Audittens for reporting this issue!\nOther Notable Changes\nEmitting Events and Reverting with Errors via Module Member Access\nWe fixed the internal compiler error that was triggered when emitting an event or reverting with an error referenced through a module. This is part of our effort to ensure feature parity between free functions and libraries.\nMigration of solc-bin Hosting from AWS to Cloudflare\nWe migrated hosting for historical release binaries from Amazon S3 to Cloudflare R2 to reduce operational costs. Binaries remain available at binaries.soliditylang.org.\n The legacy solc-bin.ethereum.org domain is deprecated, as it is no longer under our control.\nHotfix in 0.8.33\nVersion 0.8.32 unintentionally introduced an internal compiler error when accessing getters of constant state variables. While this doesn’t cause miscompilations or security vulnerabilities, it affects common patterns. Version 0.8.33 addresses this issue and is therefore recommended instead of 0.8.32.\n\nYou can read the full release announcement on our blog:\n\nUsers can download the new version of Solidity Compiler from GitHub:\n\nAnd lastly, we would like to thank all the contributors who helped make this release possible! \n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1524,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265847216,"hash":"0a9594718042dee68ee6cba7f63e045067ed5b17"}
{"url":"https://docs.base.org/base-chain/asset-issuance/tokenized-stocks-on-base","domain":"docs.base.org","title":"List Tokenized Stocks - Base Documentation","text":"Tokenized Stocks on Base are built on the Base-native token standard, B20. B20 is an extension of the ERC-20 token standard and is intended to be asset-agnostic, with tokenized stocks being one of several possible use cases.\nProduct-specific details about Tokenized Stocks on Base can be found within coinbase.com/tokenize.\nThe public Tokenized Stocks API returns the tokenized-stock records currently exposed through the API, including contract addresses, normalized token supplies, multipliers, and Chainlink-based NAV/reference values, in a single read-only request with no API key required.\n​Token Information and Listings\nTokenized stocks launch similarly to any ERC-20 token: name, symbol, and icon come from the usual sources, along with a few notable B20 specifics. Standard ERC-20 methods and events are supported natively.\n\nOnchain: name, symbol, decimals, and contractURI (ERC-7572 metadata).\nOffchain: logos are also available from the canonical token list and market-data aggregators.\nAPI: the List Tokenized Stocks endpoint returns each token’s contract address, symbol, name, decimals, icon URL, and ISIN.\n\nB20 specifics:\n\nTokens should be identified by address rather than ticker or symbol. Metadata is mutable onchain and should be indexed accordingly.\nDiscover new tokens by watching the B20Created event.\n\n​B20 Token Features\n​Multipliers\nAn underlying real-world asset may undergo events that change the redemption ratio of a B20 token. For tokenized stocks, these events include dividends or stock splits, which must be passed along to the holder of the B20 tokenized equity onchain. The multiplier variable instantly updates the redemption ratio of a B20 token based on any corporate actions that occur.\nOne B20 token does not permanently equal one share. Always apply the current multiplier when converting between token units and the number of underlying shares.\nAsset-level events are reflected by updating the multiplier. For example, after a dividend on a tokenized equity, the multiplier increases to 1.02, representing that 1 B20 token is redeemable for 1.02 shares of the equity.\nAt this time, for tokenized stocks, cash dividends are converted to shares of the underlying equity and reflected via a multiplier update rather than distributed as cash to the B20 holder. This allows B20 holder balances to automatically reflect corporate actions without changing their balance of the B20 token.\nMultiplier updates come in two forms:\n\nScheduled (ERC-8056): set a future-dated change with updateUIMultiplier, which gives advance onchain notice. Use this for routine corporate actions.\nInstant (deprecated): updateMultiplier applies immediately and clears any pending scheduled change. It is a retained emergency failsafe; prefer the scheduled path.\nCancellation: clear a pending scheduled update with cancelUIMultiplierUpdate.\n\nThe B20 contract provides ERC-8056 helper functions for common calculations, where raw is the number of B20 units and ui is the quantity of stocks redeemable:\nFunctionDescriptionuiMultiplier()Current effective multiplier (WAD)balanceOfUI(account)Raw balance × multipliertotalSupplyUI()Raw total supply × multipliertoUIAmount(raw)Convert raw amount to UI amountfromUIAmount(ui)Convert UI amount to raw\nmultiplier() and scaledBalanceOf(account) remain the canonical B20 names; uiMultiplier() and balanceOfUI(account) are their ERC-8056 aliases and return the same values. toScaledBalance and toRawBalance remain callable but are deprecated in favor of toUIAmount and fromUIAmount. See the Cobalt multiplier changelog.\n​Policies\nTo comply with any regulatory requirements that apply to a particular asset, policies that manage allowlists and blocklists may be implemented. Policies determine whether a transfer is allowed or rejected.\nThe B20 contract provides the isAuthorized(policyID, account) function, which you can use to determine whether a specific account is allowed to transfer funds. It never reverts, so a policy ID that doesn’t exist still returns a result; check policyExists(policyId) before you rely on it.\nThe standard approve() function is not policy gated. Checking whether a quantity of funds is approved to be transferred does not guarantee that the funds aren’t blocked by a policy.\n​Pauses\nOnchain pauses are unlikely, but be aware that B20s allow specific functions within a contract to be paused. Monitor these to maintain an accurate understanding of whether funds can be transferred at a given point in time.\n​Announcements\nSensitive operations are wrapped in onchain announcement events: announce emits Announcement (id, description, uri), then EndAnnouncement. Integrators index these to catch corporate actions as they execute.\nTwo design points:\n\nAnnouncements can be atomically bundled with the token change they describe (for example, the multiplier update for a stock split), keeping onchain records clean.\nDescriptions are intentionally human-readable onchain to support public reporting requirements.\n\nAdmin actions: admin operations and multiplier updates (OPERATOR_ROLE) execute when the role holder calls (scheduled multiplier updates flip at effectiveAt); the B20 standard has no built-in timelock. The Announcement and EndAnnouncement events are public notice, not an enforced delay. Any timelock or multisig is applied by the issuer at the governance layer.\n​Extra Metadata\nIssuers can store arbitrary key/value data onchain via extraMetadata(key) (for example, security identifiers such as ISIN and CUSIP).\n​Name and Symbol\nName and symbol are updatable onchain (updateName, updateSymbol), so the token can track offchain changes to the underlying without redeploying.\n​Memos\ntransferWithMemo and transferFromWithMemo attach a bytes32 reference to an individual transfer (emitted as a Memo event), for annotating transfers with offchain data for reconciliation and reporting.\n​Supply Cap\nAn optional supply cap bounds total supply, mitigating over-minting from operational errors or a compromise.\n​Compliance\nHolding and trading on the secondary market is permissionless. KYC only happens during mint and redeem flows taken by Authorized Participants (APs).\n\nOnchain policies can block specific addresses, such as sanctioned addresses; a blocked transfer reverts (see Policies above).\nMinting and redeeming the underlying shares is a separate, restricted issuer flow, as it is restricted to APs.\n\nSecurity and audits: tokenized stocks are B20 native precompiles, not separately deployed contracts, so there is no per-asset contract and no per-address verified contract on Basescan (precompiles hold no bytecode). B20 shipped in Base’s Beryl upgrade on code audited by Base and Spearbit, with ongoing Cantina (smart contract) and HackerOne (offchain and infrastructure) bug-bounty coverage. Every token shares the same audited implementation.\n​Price Feeds\nA tokenized stock’s price is available from both onchain and offchain sources. In every case, the price is derived from the same relationship: the underlying equity’s market price scaled by the token’s multiplier.\nToken price formulaToken Price = Underlying Equity Market Price × Multiplier\n\nThe multiplier is sourced per token and is WAD-scaled (a fixed-point number with 18 decimals). To get the real factor, divide the onchain value by that scale; call WAD_PRECISION() to read the scale (it returns 1e18).\n​Onchain\nChainlink is the onchain price option at launch. Each tokenized equity has a Chainlink feed that runs 24/5, holds the last close on weekends and holidays, and freezes during corporate actions. Feeds implement the standard Chainlink V3 aggregator interface and are read through the proxy, exactly like a crypto price feed; read the latest value with latestRoundData().\nThe Tokenized Stocks API also returns nav_price, the most recently published Chainlink-based NAV/reference value for each token, along with nav_price_updated_at and the current multiplier. nav_price is not a live bid/ask or execution price: read nav_price_updated_at and apply the same staleness bounds you would to updatedAt before relying on it.\nUnlike standard market-rate feeds, Coinbase feeds report Total Return Values rather than raw equity prices, so the price reflects the underlying’s total return including corporate-action adjustments. Chainlink uses this same approach for other tokenized-equity issuers, including Ondo and Robinhood. The underlying price is sourced from Chainlink’s equity price feeds (traditional market data), not from onchain or DEX trading of the token; the token’s DEX price does not feed the oracle.\nThe feed reads the multiplier and a pause flag from Coinbase’s onchain oracle registry, a single contract (separate from the tokens) that returns both values for a token in one call:\n\nNormal (paused = false): the feed publishes underlying price × multiplier.\nPaused (paused = true): the feed stops publishing and holds the last known good value.\n\nDuring market hours the feed updates on a 0.5% price deviation or at least every 24 hours (its heartbeat). Off-hours (nights, weekends, holidays, and corporate-action pauses) it stops updating and holds the last value, so updatedAt stops advancing while the contract stays callable. Always read updatedAt and apply staleness bounds before relying on the price; never settle or liquidate against a frozen feed.\nDuring a corporate action:\n\nMint and redeem pause offchain, but the token is not paused onchain, so transfers are not blocked.\nThe feed freezes (the registry pause flag is set) and its price goes stale.\nBecause the feed is total-return, there is no price discontinuity: the multiplier and underlying price move in opposite directions and cancel (a 10:1 split drops the price ~10x and raises the multiplier ~10x).\nFail-safe: the feed resumes only after Coinbase confirms the underlying price and multiplier both reflect the new values. If one updates before the other, the feed stays frozen at the pre-pause price rather than publishing a half-applied value.\n\nChainlink data feeds on Base. Read each via latestRoundData() on the proxy address below. All feeds return 8 decimals, cover US equities (24/5 market hours), and update on a 0.5% price deviation or a 24-hour heartbeat. Values are total-return; apply the pause and staleness handling above.\nFeedAddressCoinbase AAPL0x787f13dEa48Db0897CbCDD985de77809D837F988Coinbase AMZN0x06A8E4b3aBB3B7543d8396FB2B763d22820cB295Coinbase GOOGL0x5bF49E0ffA937CE2FfF033c739aD7C634c4D34F2Coinbase META0x6526aE6797A76123638b863AeE4dD27Ba4E4b27DCoinbase MSFT0xeB10A6c9aa7E537aEd766C08c35Dae35B321b18cCoinbase MSTR0xB3cE282CD188b35DA0E38D8Bc7d58e33173D202aCoinbase NVDA0x04689a41629776563E6822F76f2e57D148d28513Coinbase SNDK0x388b0dC46C0Fb05A74BeE0994fa5b02c6Fcca2eACoinbase SPCX0x6A634B235903C4ad6376892180d6fF8612e3Fa68Coinbase TSLA0xFaf869185383a24F8cb00e27BdA6b63B9905DCb4\n​Offchain\nOffchain price data can be sourced from providers such as CoinGecko, CoinMarketCap, or RWA. These aggregators track the token’s live market price from the DEXs where the B20 trades, which runs 24/7 whenever the secondary market is active.\nTwo common patterns are used to determine value:\n\nDirectly reading the token’s market price from a provider that tracks the B20 asset.\nReading the underlying reference price and applying the multiplier calculation manually.\n\n​Historical Data\nFor historical OHLC and time-series data, use market-data providers or query Chainlink round history by roundId.\nSince prices are total-return (multiplier-adjusted), reconstruct the series consistently by applying the multiplier history if starting from raw share prices. Build that history from UIMultiplierUpdated events, emitted by both scheduled and instant multiplier changes, and date each change by its effectiveAtTimestamp, not the block time. Drop any scheduled update later cancelled by a UIMultiplierUpdateCancelled event: it emitted UIMultiplierUpdated but never took effect.\n​Contract Addresses\nTo fetch these addresses programmatically, use the List Tokenized Stocks endpoint for token contracts and the List Protocol Contract Addresses endpoint for protocol contracts.\nTickerContract addressOnchain Registry0x3f3E8cf41cdd3b1D118c16471aB0113DfDDd5CaDAAPLc0xb200000000000000000000C2e324d24d7eEcd1fbAMZNc0xb200000000000000000000d9192b6B456483C2E8GOOGLc0xb2000000000000000000002D0BA3164cc74f58B7METAc0xb2000000000000000000008bC8786B856E61707CMSFTc0xB200000000000000000000Ab99cFa739E253872BMSTRc0xb2000000000000000000004884b426556b92883dNVDAc0xb20000000000000000000078ee7ce2fE4908108CSNDKc0xb200000000000000000000397293Cb8cda9a10c5SPCXc0xb2000000000000000000007b9fcbd005511aCBd5TSLAc0xb2000000000000000000001e800a7f5189430cD0\n​Additional Resources\n\nTokenized Stocks API\nB20 Standard\nBase Standard Library\n\n​Disclaimer\nCoinbase tokenized stocks are only available to persons in eligible jurisdictions outside of the U.S.\nInclusion of any third-party protocol or venue is for developer reference only and is not an endorsement, partnership, or warranty. Confirm addresses, feeds, and the token list against official sources before integrating.\nBase is open-source, permissionless blockchain infrastructure. Each B20 token is deployed and configured by its issuer, who sets and controls all token parameters and administrative permissions; Base does not configure, administer, or control tokens deployed on the protocol.Was this page helpful?Suggest editsRaise issue","tokens":3351,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265848515,"hash":"c031103e5f9c73a72fa92e1f144ea1a7ad7a0f5e"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/22","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 22 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n Load more posts below","tokens":2847,"squid":"ink-research","role":"Deep Scholar","at":1791265848582,"hash":"b108bc654034a9f5ce425f068c15411b5bf55843"}
{"url":"https://docs.optimism.io/op-stack/introduction/fact-sheet","domain":"docs.optimism.io","title":"Optimism Documentation","text":"While the OP Stack allows for full customization, standard OP Stack chains adhere to a standard set of technical and governance parameters, facilitating OP Stack interoperability, network security, and ease of upgrading your chain.\n​Technical stack\nFeatureStandard OP StackOP StackParent chainEthereumAny L1, any L2Throughput132.5Mgas/s50Mgas/sGas limit2200M200MBlocktimes3200ms200msData availability supportEthereumEthereum, Celestia, EigenDAGas token support4ETHETH, Custom Gas TokenUpgradesFacilitated via OP GovernanceSelf-managedEVM compatibilityEquivalentVariable\n1Data for Standard OP Stack from Base. Data for OP Stack from opBNB.\n2The standard blockspace charter has a max gas limit of 200m. Both gas limit and gas target can be configured through the system config.\n3While protocol blocktimes can be lowered to 1 second, subsecond pre-confirmations are delivered by Subblocks.\n4OP Stack chains can use Custom Gas Token to enable any asset as the native fee currency. Standard OP Stack chains use ETH as the gas token, though chain operators can achieve similar UX using an ERC-20 paymaster.Was this page helpful?","tokens":281,"squid":"ink-governance","role":"Council Listener","at":1791265862850,"hash":"cc14307184e5cd5b42a2bc7af0dad41371d0d6ff"}
{"url":"https://forum.openzeppelin.com/t/frequently-asked-questions-faq/140/1","domain":"forum.openzeppelin.com","title":"Frequently Asked Questions (FAQ) - General - OpenZeppelin Forum","text":"Frequently Asked Questions (FAQ) \n\n General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by nventuro on Oct 22, 2021\n\n nventuro\n\n Great contributor\n\n When will the next version of an OpenZeppelin project be released?\nSee the OpenZeppelin open-source processes: Redesigning OpenZeppelin open-source processes\nWhere can I find documentation on OpenZeppelin projects?\nDocumentation for OpenZeppelin projects is at docs.openzeppelin.com\nWhat does it mean for OpenZeppelin to have a stable API?\nSee OpenZeppelin Contracts API Stability for an in-depth discussion of this topic.\nWhat is the difference between @openzeppelin/contracts and @openzeppelin/contracts-ethereum-package?\n@openzeppelin/contracts is set up for general usage, while @openzeppelin/contracts-ethereum-package is tailored for being used with OpenZeppelin Upgrades. This means that its contracts are already set up to be upgradeable.\nCan my project/EIP be added to OpenZeppelin?\nWe're always open to including new features in the library! Start a new topic under the OpenZeppelin category describing your feature and why it's a good idea, along with some general use cases and requirements for it.\nAccepted features typically go through a short design phase until an API is settled on, at which point we're ready to start taking in Pull Requests. Opening a PR before said design is final is discouraged, since usually some discussion is required before a merge, which often means refactoring the proposed code.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Difference between OpenZeppelin Contracts and OpenZeppelin Contracts Ethereum Package\n\n SDK\n\n 2\n\n 2.3k\n\n May 2020\n\n First release of OpenZeppelin Contracts Upgradeable\n\n Announcements\n\n 1\n\n 4.8k\n\n Nov 2020\n\n OpenZeppelin Contracts API Stability\n\n General\n\n 0\n\n 2.4k\n\n Feb 2020\n\n Creating an openzeppelin-contracts-upgradeable Smart Contract\n\n Contracts\n\n 2\n\n 1.3k\n\n May 2021\n\n OpenZeppelin Contracts Ethereum Package (upgradeable fork) roadmap\n\n Contracts\n\n 2\n\n 1.5k\n\n Jul 2020","tokens":522,"squid":"ink-security_audits","role":"Sentinel","at":1791265864816,"hash":"591ad2878319e38954786ae2bb82de0159b59d8e"}
{"url":"https://forum.soliditylang.org/c/announcements/5","domain":"forum.soliditylang.org","title":"Latest Announcements topics - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Latest topics in Announcements\n\n Announcements\n\n Latest\n\n Hot\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Announcements category\n\n Low-traffic category for important announcements about the Solidity language and compiler. \n:postbox:Subscribe to this category if you want to be kept in the loop about releases and Solidity-relevant feedback surveys, ne…\n\n read more\n\n 0\n\n 613\n\n Dec 2020\n\n Read this before posting! \n\n Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter …\n\n read more\n\n 0\n\n 4.4k\n\n Dec 2020\n\n Solidity 0.8.37 is released!\n\n 0\n\n 55\n\n 26d\n\n Pattern Matching Blog Post Released\n\n 0\n\n 79\n\n May 5\n\n Solidity v0.8.35 is out!\n\n 0\n\n 101\n\n Apr 29\n\n The Annual Solidity Survey is live!\n\n 2\n\n 121\n\n Apr 27\n\n Solidity Developer Survey 2025 Results\n\n 2\n\n 147\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n 1\n\n 143\n\n Apr 24\n\n Solidity v0.8.33 is out! \n\n 0\n\n 181\n\n Dec 2025\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n 0\n\n 123\n\n Dec 2025\n\n Solidity v0.8.31 is out! \n\n 0\n\n 136\n\n Dec 2025\n\n Forum under maintenance on July 11, 2025\n\n 0\n\n 94\n\n Jul 2025\n\n Solidity v0.8.30 just landed!\n\n 0\n\n 205\n\n May 2025\n\n We are thrilled to release Solidity v0.8.29!\n\n 1\n\n 228\n\n Apr 2025\n\n The Case for EOF\n\n 0\n\n 141\n\n Mar 2025\n\n The Solidity Survey 2024 is live!\n\n 0\n\n 168\n\n Dec 2024\n\n Solidity 0.8.24 is out! \n\n 5\n\n 1.1k\n\n Dec 2024\n\n Solidity v0.8.28 is out! \n\n 1\n\n 296\n\n Dec 2024\n\n Solidity 0.8.27 is out! \n\n 0\n\n 243\n\n Oct 2024\n\n The Underhanded Solidity Contest 2024 is open for submissions! 🕵️\n\n 0\n\n 154\n\n Jul 2024\n\n The Solidity Developer Survey Results 2023 are out! \n\n 1\n\n 458\n\n Jul 2024\n\n Solidity v0.8.25 is out! \n\n 3\n\n 928\n\n Mar 2024\n\n Solidity Survey 2023\n\n 3\n\n 511\n\n Dec 2023\n\n We just released Solidity v0.8.23!\n\n 0\n\n 477\n\n Nov 2023\n\n Solidity v0.8.22 is out!\n\n 0\n\n 512\n\n Oct 2023\n\n Solidity v0.8.21 was just released!\n\n 0\n\n 549\n\n Jul 2023\n\n Solidity v0.8.20 was just released!\n\n 0\n\n 684\n\n May 2023\n\n Solidity v0.8.19 was just released!\n\n 0\n\n 551\n\n Feb 2023\n\n Solidity v0.8.18 was just released!\n\n 0\n\n 586\n\n Feb 2023\n\n Solidity Core Team Updates + Solidity Developer Survey 2022\n\n 0\n\n 527\n\n Dec 2022","tokens":1418,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265868479,"hash":"7d4ca5479c0ec985bcdba0e036b41e7ed8741c5e"}
{"url":"https://docs.optimism.io/op-stack/protocol/differences","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Learn the OP Stack — stop 4 of 14.\nYou know what the stack is and the principles behind it. This page\ngrounds what “EVM equivalent” means in practice: the small set of\nbehaviors where OP Stack chains differ from Ethereum. When you’re done,\ncontinue to OP Stack components.\nOP Stack chains are designed to be EVM equivalent and introduces as few changes as possible to the Ethereum protocol.\nHowever, there are some minor differences between the behavior of Ethereum and OP Stack chains that developers should be aware of.\n​Bridging\n​Bridging - Deposit Transactions\nDeposit transactions don’t exist on L1s, and are how transactions on an L2 can be initiated from the L1. Importantly, this is how bridge applications can get L1 ETH or tokens into an L2 OP Stack chain. You can read more on deposit transactions here.\n​Bridging - Withdrawal Transactions and Fault Proofs\nWithdrawal transactions are how the state of the L2 rollup can be proven to the L1. Often this involves users withdrawing tokens or ETH to the L1. Fault proofs are the mechanism by which withdrawal transactions are currently proven to the L1. You can read more about fault proofs here.\n​Opcodes\nOpcodeSolidity EquivalentBehaviorCOINBASEblock.coinbaseReturns the address of the current Sequencer’s fee wallet. Effectively the same as Ethereum with the caveat that the value typically does not change from block to block.PREVRANDAOblock.prevrandaoReturns the PREVRANDAO (the most recent RANDAO) value of L1 at the current L1 origin block.ORIGINtx.originIf the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, then tx.origin is set to the aliased address of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally.CALLERmsg.senderIf the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, and this is the first call frame (rather than an internal transaction from one contract to another), the same address aliasing behavior applies.\n​Address aliasing\nAddress aliasing is an important security feature that impacts the behavior of transactions sent from L1 to L2 by smart contracts.\nMake sure to read this section carefully if you are working with cross-chain transactions.\nNote that the CrossChainMessenger contracts will handle address aliasing internally on your behalf.\nWhen transactions are sent from L1 to L2 by an Externally Owned Account, the address of the sender of the transaction on L2 will be set to the address of the sender of the transaction on L1.\nHowever, the address of the sender of a transaction on L2 will be different if the transaction was triggered by a smart contract on L1.\nBecause of the behavior of the CREATE opcode, it is possible to create a contract on both L1 and on L2 that share the same address but have different bytecode.\nEven though these contracts share the same address, they are fundamentally two different smart contracts and cannot be treated as the same contract.\nAs a result, the sender of a transaction sent from L1 to L2 by a smart contract cannot be the address of the smart contract on L1 or the smart contract on L1 could act as if it were the smart contract on L2 (because the two contracts share the same address).\nTo prevent this sort of impersonation, the sender of a transaction is slightly modified by the OptimismPortal when a smart contract calls depositTransaction to send a transaction from L1 to L2.\nThis alias is applied when the caller has code, and that code is not a valid EIP-7702 delegation.\nWhen the address has no code, or the code present at the address is a valid EIP-7702 delegation, the sender is not modified.\nNote that ephemeral contracts (those that are created and self-destructed in the same transaction) WILL be aliased, despite having no code at the start or end of transaction execution.\nInstead of appearing to be sent from the actual L1 contract address, the L2 transaction is sent from an “aliased” version of the L1 contract address.\nThis aliased address is produced by treating the address as a 160-bit integer, adding a constant offset with overflows allowed, and then truncating the result to a 20-byte address.\nThe address hashing function ensures that aliased address will never conflict with any other address on L2.\nThe simple offset original L1 address can easily be recovered from the aliased address.\nThe OptimismPortal applies this change only to L2 transactions sent by L1 smart contracts.\nIn all other cases, the transaction sender address is set according to the same rules used by Ethereum.\nTransaction SourceSender AddressL2 user (Externally Owned, or EIP-7702 Delegated Account)The user’s address (same as in Ethereum)L1 user (Externally Owned, or EIP-7702 Delegated Account)The user’s address (same as in Ethereum)L1 contract (using OptimismPortal.depositTransaction)uint160(L1_contract_address) + 0x1111000000000000000000000000000000001111\n​Transactions\n​Transaction fees\nTransactions on OP Stack chains must pay for an L1 data fee on top of the standard execution gas fee you would expect on Ethereum.\nRefer to the guide on OP Stack Transaction Fees for more information.\nYou can use the JS library viem to estimate the entire transaction gas costs, including the L1 Data Fee.\n​EIP-1559 parameters\nThe base fee on OP Stack is, like Ethereum, computed via the EIP-1559 mechanism.\nThe EIP-1559 parameters used by OP Stack differ per chain.\n​Mempool rules\nUnlike Ethereum, OP Stack chains do not have a public mempool.\nThe OP Stack mempool is currently only visible to the Sequencer.\nThe Sequencer executes transactions from the mempool in priority fee order (highest fee first).\n​Chain Finality\nUnlike L1s such as Ethereum, OP Stack chains have Unsafe, Safe, and Finalized Heads which indicate the state of finality for a given L2 block. Fault proofs do not impact the finalization of the L2 rollup, only the finalization of withdrawal transactions to the L1. You can read more about these in the docs glossary.\n​What’s Next\nThere are various useful tools linked above. Here are a few more tools and links you may want to check out:\n\nOP-viem: JS framework that can handle many of these unique functions on OP Chains. It is similar to Ethers.js for OP Stack chains.\n\nSpecs: For more in-depth technical explanations and examples.\n\nWas this page helpful?","tokens":1577,"squid":"ink-governance","role":"Council Listener","at":1791265875615,"hash":"bf6148a5997f1b64661098353ac63b7c873e9687"}
{"url":"https://forum.openzeppelin.com/t/difference-between-openzeppelin-contracts-and-openzeppelin-contracts-ethereum-package/2815/1","domain":"forum.openzeppelin.com","title":"Difference between OpenZeppelin Contracts and OpenZeppelin Contracts Ethereum Package - Archive / SDK - OpenZeppelin Forum","text":"Difference between OpenZeppelin Contracts and OpenZeppelin Contracts Ethereum Package \n\n ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2020\n\n 1 / 3\n\n May 2020\n\n May 2020\n\n post by abcoathup on May 7, 2020\n\n abcoathup\n\n Great contributor\n\n Asked on GitHub:\n\n post by abcoathup on May 7, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts is for regular (non-upgradeable) contracts while OpenZeppelin Contracts Ethereum Package is an official fork of OpenZeppelin Contracts that has been modified to use initializers instead of constructors so that they can be used with upgradeable contracts.\nOpenZeppelin Contracts 2.x uses Solidity 0.5 and there is an equivalent OpenZeppelin Contracts Ethereum Package.\nOpenZeppelin Contracts 3.x uses Solidity 0.6 and development is ongoing for an equivalent OpenZeppelin Contracts Ethereum Package. (see open issue: https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/issues/79).\nPlease note: storage layout changes likely means that contracts can’t be upgraded from 2.5 to 3.0.\n\n post by abcoathup on May 13, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts Ethereum Package v3.0 has been released.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Announcements\n\n 0\n\n 3.2k\n\n May 2020\n\n First release of OpenZeppelin Contracts Upgradeable\n\n Announcements\n\n 1\n\n 4.8k\n\n Nov 2020\n\n Planning the demise of OpenZeppelin Contracts’ evil twin\n\n General\n\n upgrades,design,evm-package\n\n 14\n\n 4.5k\n\n Nov 2020\n\n Did ‘contracts-ethereum-package’ migrate to @openzeppelin/contracts-upgradeable?\n\n Contracts\n\n erc20,upgrades-plugins\n\n 1\n\n 1.3k\n\n Dec 2020\n\n Can we use OpenZeppelin Contracts 3.0 with upgradeable contracts?\n\n SDK\n\n 10\n\n 2.3k\n\n May 2020","tokens":465,"squid":"ink-security_audits","role":"Sentinel","at":1791265875681,"hash":"6eb5e75ab7bdcc2c36f3c7077c155efb1e91531b"}
{"url":"https://forum.soliditylang.org/t/pattern-matching-blog-post-released/3703","domain":"forum.soliditylang.org","title":"Pattern Matching Blog Post Released - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Pattern Matching Blog Post Released \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by czepluch on May 5\n\n czepluch\n\n Solidity Team\n\n We’ve just released a blog post explaining how pattern matching and ADTs are planned to work in Core Solidity.\nGive it a read and let us know what you think.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 147\n\n Apr 27\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 123\n\n Dec 2025\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 181\n\n Dec 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1068,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265878546,"hash":"8667c882e48bd1bf07a33500ab52024e25370ef0"}
{"url":"https://docs.optimism.io/op-stack/protocol/components","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Learn the OP Stack — stop 5 of 14.\nYou know how OP Stack chains relate to Ethereum. This page names the\nconceptual layers of the stack and the software modules that fill them:\nthe components you deploy in the next stop. When you’re done, continue\nto Creating your own L2 rollup testnet.\nThe OP Stack is a common development stack for building L2 blockchain ecosystems, built by the Optimism Collective to power Optimism.\nThis page is the canonical layer taxonomy: the six layers named here are the\nones the rest of the documentation uses. For how the components interact at\nruntime, see OP Stack architecture; for the hub page\nof each individual component, see Stack Components.\nThe OP Stack is best thought of as a collection of software components maintained by the Optimism Collective that either help to define new layers of the stack or fit in as modules within the stack.\nBecause the OP Stack is a work in progress, the different layers and modules are still evolving.\nThis page sketches out the different conceptual layers of the stack as they exist today and introduces some of the modules that fit into those layers.\nThis doesn’t include all of the modules or layers that may exist in the future, but it gives a good overview of the major OP Stack components.\nLayers are generally more tightly defined towards the bottom of the stack (like the Data Availability Layer) but become more loosely defined towards the top of the stack (like the Governance Layer).\nPlease note that not all of the modules described on this page already exist in a production state — these are explicitly marked as either “in development” or “proposed.”\n\nThe diagram follows the data rather than stacking the layers, so it does not\nmatch the bottom-to-top ordering the section above describes. Sequencing\ncompresses L2 blocks into batches and posts them to the data\navailability layer; derivation reads those compressed batches back out and\nturns them into the inputs that rebuild the L2 chain. Each layer is a swap\npoint: a chain picks one module per layer.\n​Layers\n​Data availability\nThe Data Availability Layer defines where the raw inputs to an OP Stack based chain are published. An OP Stack chain can use a single Data Availability module to source its input data. Because an OP Stack chain is derived from the Data Availability Layer, the Data Availability module used has a significant impact on the security model of a system. For example, if a certain piece of data can no longer be retrieved from the Data Availability Layer, it may not be possible to sync the chain.\n​Ethereum DA\nEthereum DA is currently the most widely used Data Availability module for the OP Stack. When using the Ethereum DA module, source data can be derived from any piece of information accessible on the Ethereum blockchain. This includes Ethereum calldata, events, and 4844 data blobs.\n\nSpecifications\nSource code\n\n​Sequencing\nThe Sequencing Layer determines how user transactions on an OP Stack chain are collected and published to the Data Availability Layer module(s) in use. In the default Rollup configuration of the OP Stack, Sequencing is typically handled by a single dedicated Sequencer. Rules defined in the Derivation Layer generally restrict the Sequencer’s ability to withhold transactions for more than a specific period of time. In the future, Sequencing will be modular such that chains can easily select and change the mechanism that controls their current Sequencer.\n​Single sequencer\nThe default Sequencer module for the OP Stack is the Single Sequencer module in which a dedicated actor is given the ability to act as the Sequencer. The Single Sequencer module allows a governance mechanism to determine who may act as the Sequencer at any given time.\n​Multiple sequencer\nA simple modification to the Single Sequencer module is the Multiple Sequencer module in which the Sequencer at any given time is selected from a pre-defined set of possible actors. Individual OP Stack based chains would be able to determine the exact mechanism that defines the set of possible Sequencers and the mechanism that selects a Sequencer from the set.\n​Derivation\nThe Derivation Layer defines how the raw data in the Data Availability Layer is processed to form the processed inputs that are sent to the Execution Layer via the standard Ethereum Engine API. The Derivation Layer may also use the current system state, as defined by the Execution Layer, to inform the parsing of raw input data. The Derivation Layer can be modified to derive Engine API inputs from many different data sources. The Derivation Layer is typically tied closely to the Data Availability Layer because it must understand how to parse any raw input data.\n​Rollup\nThe Rollup module derives Engine API inputs from Ethereum block data, Sequencer transaction batches, Deposited transaction events, and more.\n\nSpecifications\nSource code\n\n​Indexer\nThe Indexer module is a Derivation Layer module that would derive Engine API inputs when transactions are sent to, events are emitted by, or storage is modified in specific smart contracts on a Data Availability Layer module like Ethereum DA.\n​Execution\nThe Execution Layer defines the structure of state within an OP Stack system and defines the state transition function that mutates this state. State transitions are triggered when inputs are received from the Derivation Layer via the Engine API. The Execution Layer abstraction opens up the door to EVM modifications or different underlying VMs entirely.\n​EVM\nThe EVM is an Execution Layer module that uses the same state representation and state transition function as the Ethereum Virtual Machine. The EVM module in the Ethereum Rollup configuration of the OP Stack is a lightly modified version of the EVM that adds support for L2 transactions initiated on Ethereum and adds an extra L1 Data Fee to each transaction to account for the cost of publishing transactions to Ethereum.\n\nSource code\n\n​Settlement layer\nThe Settlement Layer is a mechanism on external blockchains that establish a view of the state of an OP Stack chain (target) on those external, third-party chains (including other OP Stack chains). For each target chain, there may be one or more Settlement mechanisms on one or more external chains. Settlement Layer mechanisms are read-only and allow a third-party chain to make decisions, potentially impacting their own state, based on the state of the target OP Stack chain.\nThe term “Settlement Layer” has its origins in the fact that Settlement Layer mechanisms are often used to handle withdrawals of ETH and tokens out of a blockchain. This sort of withdrawal system first involves proving the state of the target blockchain to some third-party chain and then processing a withdrawal based on that state. The Settlement Layer, at its core, simply allows a third-party chain to become convinced of the state of the target chain.\nOnce a transaction is published and finalized on the corresponding Data Availability layer, the transaction is also finalized on the OP Stack chain. Short of breaking the underlying Data Availability layer, it can no longer be modified or removed. It may not be accepted by the Settlement Layer yet because the Settlement Layer needs to be able to verify transaction results, but the transaction itself is already immutable.\n​Attestation-based fault proof\nSuperseded. OP Mainnet settled this way until fault proofs activated on\nJune 10, 2024. It is described here because the Settlement Layer is a swap\npoint, and this is the module the OP Stack swapped out.\nAn Attestation-based Fault Proof mechanism uses an optimistic protocol to establish a view of an OP Stack chain. In optimistic settlement mechanisms generally, Proposer entities can propose what they believe to be the current valid state of the OP Stack chain. If these proposals are not invalidated within a certain period of time (the “challenge period”), then the proposals are assumed by the mechanism to be correct. In the Attestation Proof mechanism in particular, a proposal can be invalidated if some threshold of pre-defined parties provide attestations to a valid state that is different than the state in the proposal. This places a trust assumption on the honesty of at least a threshold number of the pre-defined participants.\n​Fault proof optimistic settlement\nThis is the Settlement Layer module OP Mainnet uses today, activated on June 10, 2024. It replaces the attestation mechanism’s MultiSig challenger with a permissionless fault proving process: anyone can propose the state of the chain, and anyone can challenge a proposal they believe is wrong. A correctly constructed fault proof invalidates an incorrect proposal within the challenge period, which moves the trust assumption off the honesty of a named set of participants and onto the correctness of the fault proof construction. The Optimism Security Council, acting as the Guardian, is the backstop if that construction fails.\n\nSpecifications\nFault proofs explainer\nSource code\n\n​Validity Proof Settlement\nA Validity Proof Settlement mechanism uses a mathematical proof to attest to the correctness of a proposed view. When a proposed state is accompanied by a valid proof, it is immediately and unconditionally accepted; otherwise, it is rejected. This mechanism relies on cryptographic assumptions, rather than trust in certain participants or processes. While it eliminates the need for a challenge period, it requires significant upfront computation to generate the proof.\n​Governance\nThe Governance Layer refers to the general set of tools and processes used to manage system configuration, upgrades, and design decisions. This is a relatively abstract layer that can contain a wide range of mechanisms on a target OP Stack chain and on third-party chains that impact many of the other layers of the OP Stack.\n​MultiSig contracts\nMultiSig Contracts are smart contracts that carry out actions when they receive a threshold of signatures from some pre-defined set of participants. These are often used to manage upgrades of components of an OP Stack based system. Currently, this is the mechanism used to manage upgrades of the bridge contracts on OP Mainnet. The security of a MultiSig Contract system depends on many different factors, including the number of participants, the threshold, and the safety procedures of each individual participant.\n​Governance tokens\nGovernance Tokens are widely used to decentralize decision-making. Although the exact functionality of a Governance Token varies on a case-by-case basis, the most common mechanisms allow token holders to vote on some subset of decisions that a project must make. Voting can either be carried out directly or via delegation.Was this page helpful?","tokens":2688,"squid":"ink-governance","role":"Council Listener","at":1791265885699,"hash":"cd64c9dcb2cfb847cfee3298f9313d3106065923"}
{"url":"https://forum.openzeppelin.com/t/difference-between-openzeppelin-contracts-and-openzeppelin-contracts-ethereum-package/2815/2","domain":"forum.openzeppelin.com","title":"Difference between OpenZeppelin Contracts and OpenZeppelin Contracts Ethereum Package - Archive / SDK - OpenZeppelin Forum","text":"ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2020\n\n 2 / 3\n\n May 2020\n\n May 2020\n\n post by abcoathup on May 7, 2020\n\n abcoathup\n\n Great contributor\n\n Asked on GitHub:\n\n post by abcoathup on May 7, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts is for regular (non-upgradeable) contracts while OpenZeppelin Contracts Ethereum Package is an official fork of OpenZeppelin Contracts that has been modified to use initializers instead of constructors so that they can be used with upgradeable contracts.\nOpenZeppelin Contracts 2.x uses Solidity 0.5 and there is an equivalent OpenZeppelin Contracts Ethereum Package.\nOpenZeppelin Contracts 3.x uses Solidity 0.6 and development is ongoing for an equivalent OpenZeppelin Contracts Ethereum Package. (see open issue: https://github.com/OpenZeppelin/openzeppelin-contracts-ethereum-package/issues/79).\nPlease note: storage layout changes likely means that contracts can’t be upgraded from 2.5 to 3.0.\n\n post by abcoathup on May 13, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts Ethereum Package v3.0 has been released.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Announcements\n\n 0\n\n 3.2k\n\n May 2020\n\n First release of OpenZeppelin Contracts Upgradeable\n\n Announcements\n\n 1\n\n 4.8k\n\n Nov 2020\n\n Planning the demise of OpenZeppelin Contracts’ evil twin\n\n General\n\n upgrades,design,evm-package\n\n 14\n\n 4.5k\n\n Nov 2020\n\n Did ‘contracts-ethereum-package’ migrate to @openzeppelin/contracts-upgradeable?\n\n Contracts\n\n erc20,upgrades-plugins\n\n 1\n\n 1.3k\n\n Dec 2020\n\n Can we use OpenZeppelin Contracts 3.0 with upgradeable contracts?\n\n SDK\n\n 10\n\n 2.3k\n\n May 2020","tokens":443,"squid":"ink-security_audits","role":"Sentinel","at":1791265885845,"hash":"32fd633ba2ea7816cc857d0e5f480c7c15186a66"}
{"url":"https://forum.soliditylang.org/t/solc-bin-binaries-hosting-migration-on-09-12-2025/3650/1","domain":"forum.soliditylang.org","title":"Solc-bin binaries hosting migration on 09/12/2025 - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solc-bin binaries hosting migration on 09/12/2025 \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by r0qs on Dec 8, 2025\n\n r0qs\n\n Solidity Compiler Team\n\n We will be migrating the solc binaries, currently hosted on the solc-bin repository and mirrored on Amazon S3, to Cloudflare R2. This transition will offer more efficient and cost-effective storage for the historical solc binaries.\nImportant Notice: The migration will begin tomorrow (09/12/2025) at 14:00 CET and is expected to take only a few minutes. During the process, users may experience brief periods of downtime or unavailability as DNS records propagate across the internet.\nWhat to expect:\n\nDomains currently pointing to S3 (https://binaries.soliditylang.org) will be updated to point to Cloudflare R2\n\nThis change involves a straightforward DNS update\n\nWhile the DNS change is propagating, some users may encounter interruptions when attempting to access the binaries\n\nThis is a temporary issue and should resolve once the changes are fully propagated\n\nRecommendation:\nWe recommend planning accordingly for this brief downtime, especially if your workflow depends on accessing the solc binaries during this time.\nThank you for your understanding. Should you have any questions or concerns, please don’t hesitate to reach out to us here.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 55\n\n 26d\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 147\n\n Apr 27\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1313,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265889463,"hash":"caf298606aea557e5bcd66efba3aa8401eb6af50"}
{"url":"https://docs.optimism.io/op-stack/protocol/blockspace-charter","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Blockspace Charters provide the essential technical and governance framework for chains on the OP Stack. These frameworks provide a secure and scalable foundation for all stakeholders. By adhering to these charters, chain operators and users can operate confidently within the OP Stack ecosystem. The Standard Rollup Charter is the first of several blockspace charters with different customizations and security guarantees.\nThese documents establish standards to ensure security, transparency, and long-term sustainability. This guide offers an overview of each charter, explains how chains can achieve compliance to be considered Standard Chains, and how the charters tie into the superchain-registry.\nThis doc mostly covers the charters, but references the superchain-registry as they are all deeply connected. Read more about the superchain-registry here.\n​Summary of charters\nThe components work in unison to form a cohesive governance and technical framework:\n\nBlockspace Charters: A type of framework that establishes criteria, governing policies, and precommitments for blockspace in the Optimism ecosystem, ensuring security, uptime, and alignment with the Law of Chains.\nStandard Rollup Charter: The Standard Rollup Charter is the first blockspace charter, defining the technical and governance requirements for our highest-security blockspace. By adhering to the Standard Rollup Charter, chains can achieve “Standard” status, ensuring consistency, high security, and operational reliability.\nsuperchain-registry: The superchain-registry is an index of chains which serves as the source of truth for OP Stack chain classification and configuration. The registry checks for compliance with the Standard Rollup Charter. Chains with superchain_level = 2 meet all the criteria to be classified as a Standard Rollup.\n\nTogether, these components ensure a robust, scalable, and transparent ecosystem. Blockspace Charters provide the vision and principles, the Standard Rollup Charter translates these into concrete requirements, and the superchain-registry certifies compliance.\n​Blockspace Charters\nBlockspace Charters outline the foundational framework for governing blockspace within the Optimism ecosystem.\nThey are structured around three main components, detailed below:\n​Criteria\nThe technical parameters defining which chains are subject to the charter include:\n\nVersion: The OP Stack version powering the chain, validated via commit-hash or release tag.\nConfiguration: Parameter bounds for deployment, covering both static variables like Chain ID and dynamic variables such as sequencer roles or upgrade keys.\nSolvency: Verification that all state transitions in the chain’s history are valid, and free from invalid withdrawals or outputs that could undercollateralize the bridge.\n\n​Governing policies\nThese establish rules and procedures for stakeholder interactions and blockspace management. For example:\n\nExpected behaviors for roles like sequencers and upgrade key holders.\nProcesses for identifying and resolving violations, such as governance votes for removing non-compliant actors.\nAlignment with the Law of Chains, ensuring user protections like censorship resistance and security.\n\n​Precommitments\nCommitments outlining long-term governance stability and anticipated changes. Examples include:\n\nFuture updates to fee models or role separations.\nGuidance for evolving technical parameters like gas limits and fee margins.\n\nBy defining these components, blockspace charters ensures secure, scalable, and governed blockspace while fostering trust and alignment within the ecosystem.\n​Criteria governance\nThe criteria for Blockspace Charters are set in two ways; either by a governance vote or by the Optimism Foundation.\n\nGovernance controlled: The three TOML files referenced in the charter (standard config params, standard config roles, and standard versions) require a governance vote to alter. Changes to the files require a governance vote, but changes to code or tools that consume or validate them don’t “so long as they do not violate the semantic interpretation of those TOML files.”\nFoundation discretion: Changes to validation, outside of the three TOML files referenced above, remain at the Foundation’s discretion. This includes changes to, but is not limited to, BHIC, other config checks, and RPC availability.\n\nRead more about Blockspace Charters in the governance post.\n​The Standard Rollup Charter\nThe Standard Rollup Charter is the Blockspace Charter that defines the requirements for being a standard chain, our highest-security flagship blockspace. The Standard Rollup Charter ensures that chains adhere to the technical and operational benchmarks necessary to maintain the highest standards of security, compatibility, and compliance on the OP Stack.\nLearn more about The Standard Charter in the governance post.\nHere are some specific criteria a chain must meet:\n​Onchain criteria\n\nVersion validation: Chains must deploy a governance-approved, up-to-date OP Stack release. Contracts must match the standard bytecode.\nConfiguration checks: Chain parameters, such as block time and gas metering, must comply with governance-approved specifications. Administrative roles must align with Security Council requirements.\n\nRead more about onchain checks in the repo.\n​Off-chain criteria\nThe Optimism Foundation performs off-chain checks to verify compliance. These include:\n\nEnsuring unique Chain IDs.\nMonitoring security configurations.\nVerifying governance authenticity.\n\nSuch measures remain under the Foundation’s oversight until governance transitions to fully autonomous control.\nRead more about Off-Chain checks in the repo\n​History integrity\nThe history integrity check identifies discrepancies in chain history, including invalid state transitions. These checks are only required for chains that have not been managed by the Optimism Security Council from launch.\n​Understanding chain compliance\nChains must meet strict requirements to qualify as “Standard.” Below are answers to common questions:\n\nCan I modify system smart contracts and remain Standard? No, modifications invalidate compliance.\nIs an alt-DA mode chain Standard? No, Standard Rollups must adhere to the default data availability model.\nWill beta features qualify as Standard? No. Beta features have not yet been approved by Optimism Governance. When features graduate from Beta to GA, they may be included in the Standard Rollup Charter.\n\n​The superchain-registry\nThe superchain-registry serves as the source of truth for OP Stack chain classification and what modifications chains have made. The superchain-registry has two main tasks:\n\nValidates version and configuration: The registry validates that chains align with governance-approved standards in the form of the Standard Rollup Charter.\nIndicates adherence to the Standard Rollup Charter: Once the registry validates that a chain meets the standard criteria, it promotes it to “Standard” by setting its superchain_level value to 2.\n\nBy integrating with the Standard Rollup Charter, the registry offers an automated and transparent validation system. This ensures chains can independently demonstrate compliance. For additional details, refer to the superchain-registry documentation.Was this page helpful?","tokens":1819,"squid":"ink-governance","role":"Council Listener","at":1791265895762,"hash":"3614d5811c5c531994d6d67e65e9e12109debaf1"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-contracts-ethereum-package-v3-0/2852/1","domain":"forum.openzeppelin.com","title":"OpenZeppelin Contracts Ethereum Package v3.0 - General / Announcements - OpenZeppelin Forum","text":"OpenZeppelin Contracts Ethereum Package v3.0 \n\n GeneralAnnouncements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2020\n\n 1 / 1\n\n May 2020\n\n May 2020\n\n post by abcoathup on May 13, 2020\n\n abcoathup\n\n Great contributor\n\na847d600e1565ea24f914b4c29b224160376602d2400×1350 255 KB\n\nOpenZeppelin Contracts Ethereum Package v3.0 has been released and is tailored for use with upgradeable contracts.\nThis release includes Solidity 0.6, revamped access control, Preset contracts + extensibility via hooks. See the OpenZeppelin Contracts v3.0 announcement for details of whats in the release.\nThis package contains the same contracts as the vanilla OpenZeppelin Contracts, but modified to be safe for upgrades. The main difference is that all contracts in this package are potentially upgradeable: you will notice that no contracts have constructors defined, but use initializer functions instead. Also, this package is set up as an Ethereum package, and provides a small set of pre-deployed logic contracts that can be used directly via the OpenZeppelin SDK, without needing to deploy them again.\nAll contracts have an UpgradeSafe suffix to avoid confusion with their counterparts in OpenZeppelin Contracts. For example, ERC20 becomes ERC20UpgradeSafe.\nAll in all, you should use this package instead of OpenZeppelin Contracts if you are creating upgradeable contracts via the OpenZeppelin CLI .\n Storage layout changes means that contracts can’t be upgraded from 2.5 to 3.0.\n\n Difference between OpenZeppelin Contracts and OpenZeppelin Contracts Ethereum Package\n\n Can we use OpenZeppelin Contracts 3.0 with upgradeable contracts?\n\n How to upgrade ERC20 contract when it is live on mainnet\n\n OpenZeppelin Contracts v3.0\n\n Upgradeable contract: The deployer is the owner: AssertionError\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Can we use OpenZeppelin Contracts 3.0 with upgradeable contracts?\n\n SDK\n\n 10\n\n 2.3k\n\n May 2020\n\n First release of OpenZeppelin Contracts Upgradeable\n\n Announcements\n\n 1\n\n 4.8k\n\n Nov 2020\n\n Is it safe to upgrade from OpenZeppelin Contracts Upgradeable 3.4.0 to 4.0.0\n\n Contracts\n\n 7\n\n 1.7k\n\n Mar 2021\n\n Difference between OpenZeppelin Contracts and OpenZeppelin Contracts Ethereum Package\n\n SDK\n\n 2\n\n 2.3k\n\n May 2020\n\n Which version of OpenZeppelin Contracts should be used for upgradeable contracts?\n\n Upgrades\n\n 7\n\n 2.7k\n\n Nov 2020","tokens":611,"squid":"ink-security_audits","role":"Sentinel","at":1791265895926,"hash":"3de8d28a832f64bc3f962abd7775495691516186"}
{"url":"https://dev-forum.pyth.network/t/cant-update-price-via-vscode/65/10","domain":"dev-forum.pyth.network","title":"Can't Update Price Via Vscode - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Apr 2025\n\n 10 / 11\n\n Apr 2025\n\n Apr 2025\n\n post by c-note on Apr 17, 2025\n\n post by 0xcredence on Apr 17, 2025\n\n post by c-note on Apr 17, 2025\n\n post by ali on Apr 17, 2025\n\n post by c-note on Apr 17, 2025\n\n post by ali on Apr 17, 2025\n\n post by c-note on Apr 17, 2025\n\n post by ali on Apr 17, 2025\n\n ali\n\n @c-note I see, in your code i suspect the fee is wrong. you need to pass the updateData to getUpdateFee method and not the price id.\nIf that’s not the problem, please send us a reproducible code snippet to run.\n\n post by c-note on Apr 20, 2025\n\n c-note\n\n @ali The fee is correct, the returns fee as 1 Wei. Here you go\n\n post by ali on Apr 22, 2025\n\n ali\n\n @c-note thanks for sharing this script as it helped a lot to troubleshoot it. The problem is that in forge assigning update data to bytes like that is not right. You need to use hex\"deadbeef...\" and by fixing it I could send the transaction successfully.\np.s: I found the error was about Wormhole saying the message format is invalid (see this) and it made me realize that the update data format was wrong.\n\n post by c-note on Apr 22, 2025\n\n c-note\n\n @ali this fixed my issue thanks much.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 774\n\n May 2025\n\n Price Feed not working on AVAX and BASE\n\n Price Feeds\n\n 1\n\n 497\n\n Apr 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 655\n\n May 2025\n\n Powered by Discourse","tokens":1339,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265902896,"hash":"ab1b2d64c884f3b87e2b68c65b3282cacf8cd663"}
{"url":"https://docs.optimism.io/op-stack/research/block-time-research","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Sunnyside Labs (formerly Test in Prod) and OP Labs have researched whether we can drop OP Chains’ block time to one second.\nTo validate if dropping the block time is safe, we should check if nodes can build a block under a second when the block spends maximum gas in the production environment–i.e., block building time should take less than one second when the block spends maximum gas. We benchmarked the block-building time of every block at Base and grouped the data in various gas ranges using multiple clients–op-geth & op-reth.\n​Method and raw data\nThis GitHub repository contains the test methods, data sets, client versions, and raw data.\nThe following benchmarks are available in this notebook.\n​Benchmarks\nFigure 1: op-geth / archive node / block 5492540 ~ 9816497\nFigure 2: op-geth / full node / block 5492540 ~ 9816497\nFigures 1 and 2 show the Base nodes’ block-building time distribution with op-geth archive node & full node from block 5492540 to 9816497. We can see that the average block building time takes 0.58 and 0.36 seconds each for blocks that spent 25M ~ 30M gas, which is less than one second.\nFigure 3: op-reth / archive node / block 5492540 ~ 9816497\nFigure 3 shows the Base nodes’ block-building time distribution using the op-reth archive node from block 5492540 to 9816497. Compared to op-geth’s archive node, we can see that op-reth shows a better performance in all ranges.\nFigure 4: op-geth / archive node / block 13686867 ~ 15074141\nFigure 5: op-geth / full node / block 14567037 ~ 15074141\nThroughout the research, we found that the node meaningfully takes longer to build a block as the chain stores more states and transactions to access more historical data. Therefore, we benchmarked the latest blocks in Figures 4 and 5. On average, both the full node and archive node could build a congested block on time. It is worth noting that the average block-building time of high gas spending range is similar to the older blocks, but the average block-building time is higher on the newer blocks.\nFigure 6: op-geth / archive node / block 13686867 ~ 15074141 / histogram of 25m~30m gas range\nIf we zoom in on the 25m~30m gas range of the archive node, the average could be potentially concerning–0.51 sec. It is worth noting that we can see the average is diverged from p50 (0.4 sec) because of outliers in the histogram (Figure 6), and p50 is a more important metric than the average for the block progression (Sequencer) because of its asynchronous nature.\nWhen the sequencer seals the block after the block time, it stops to include the transactions and yields the current processing transactions to the next block. Therefore, the sequencer can include most transactions that took less than one second in the block on time and include outliers in the next block. Therefore, we can expect the system to be able to build blocks in one second in most cases, even in the highest gas range (25m~30m gas).\nAs a result, we can learn that nodes can build the latest blocks of Base Mainnet with the highest level of production loads in one second with an i3en.3xlarge instance (or similar specs).\n​Expected impacts\n​Verifier\n\nSync from genesis: If OP Chains’ block time drops to one second, verifiers may need longer to sync the chain from the genesis with L1 derivation. However, we expect it won’t be a notable issue for verifiers as OP Stack supports the engine sync.\nFollowing the tip: The research suggests that verifiers are less likely to have a problem following the tip because nodes could build a block under one second at the highest gas range, especially since most verifiers are full nodes.\n\n​Sequencer\n\nBlock progression: As the previous paragraph mentioned, the data suggests we don’t expect problems on a shorter block time.\n\n​Limitation\nThe data suggests we don’t expect a problem dropping the block time to one second for now, as the average block building time of the latest blocks takes 0.19 seconds for the Base Mainnet. One concerning point: the benchmark shows that it takes longer to build a block as the chain progresses. When the chain stores more states over time and usage surges to a peak like 2017 Ethereum, we might need performance patches then.\nHowever, it is also worth noting that the research assumes that the Base Mainnet handles 2x of their current traffic–dropping the block time to half but still spending gas as current (when it runs two seconds of block time). Plus, the Base Mainnet’s average block gas spending is 10M. To make all blocks reach the highest gas level that this research focuses on (25M), it’s another 2.5x.\nTherefore, this research assumes the chain processes approximately 5x traffic compared to the current Base Mainnet (2x in block time * 2.5x in gas spending).\n​Reference\nBase’s prior research for raising gas limit: replayorWas this page helpful?","tokens":1209,"squid":"ink-governance","role":"Council Listener","at":1791265908713,"hash":"0dfbd82ddfdc70e6e6c2b82ab9dbb8ab59e81add"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0/2695/3","domain":"forum.openzeppelin.com","title":"OpenZeppelin Contracts v3.0 - General / Announcements - OpenZeppelin Forum","text":"GeneralAnnouncements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2020\n\n 4 / 4\n\n Jun 2020\n\n May 2020\n\n post by nventuro on Apr 20, 2020\n\n nventuro\n\n Great contributor\n\na847d600e1565ea24f914b4c29b224160376602d2400×1350 255 KB\n\nWe’re thrilled to finally announce the release of OpenZeppelin Contracts v3.0 \nAmong other things, this release features the migration to Solidity v0.6, as well as a revamped access control system, streamlined token contracts, and new libraries for enumerable mappings.\nTo install this latest release, run:\nnpm install --save-dev @openzeppelin/contracts\n\nWhat’s New\n\nAll contracts were migrated to Solidity v0.6.\n\nAccessControl was designed with help from the community and has replaced Roles contracts (such as MinterRole and PauserRole), which were removed.\nCrowdsales were removed: we’ll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.\nWe’ve added hooks, a new feature of the library that will make extending it easier than ever.\n\nERC20 and ERC721 were simplified and streamlined, including all optional parts of the standard by default, and simplifying some of our own custom extensions.\nSupport for better mapping types that let you efficiently iterate over all keys using EnumerableSet and EnumerableMap\n\nMany, many breaking changes with small improvements. We’ve also moved some contracts around (e.g. Ownable is now found under the access directory) and deleted some that were not being used. Head to our changelog to see the full list.\n\nCompiling v0.6 Contracts\nYou can use the OpenZeppelin CLI to compile any Solidity v0.6 contract: just update the pragma statement on your source code and you’ll be good to go!\npragma solidity ^0.6.0;\n\nNote that you will need to use the v2.7 release of the CLI or newer to have Solidity v0.6 support. For detailed information about using the CLI compiler, head to its documenation.\nRevamped Access Control\nOne of our most widely-used contracts is Ownable, providing a simple authorization scheme. However, this fell short in complex systems with multiple permissions.\nThe v3.0 release introduces AccessControl, a one-stop-shop for all authorization needs. It lets you easily define multiple roles with different permissions, as well as which accounts are allowed to grant and revoke each role. It also boosts transparency by enabling enumeration of all privileged accounts in a system.\nAccessControl was designed with a security-first mindset, receiving input from a wide array of users and incorporating best practices in the field. Head to our Access Control guide for more information!\nPreset Contracts\nOpenZeppelin Contracts shine when you need the building blocks to get to the right feature set, but that’s not all they can do! We’ve added a new family of Preset contracts starting with ERC20 and ERC721 tokens that you can quickly deploy as-is without having to write any Solidity code. Check out their documentation!\nMigrating From OpenZeppelin Contracts v2.5\nOther than the moved and deleted contracts mentioned above, the library API is pretty much the same as in the v2.5 release, so the migration should be straightforward. For instructions on how to update your Solidity v0.5 contracts to v0.6, refer to the official documentation.\nIf you’re using the ERC20 or ERC721 tokens however, you’ll have to remove all references to optional extensions (ERC20Detailed, ERC721Enumerable, etc.) - these have been included in the base contracts.\nThe other exception to this are contracts that use the Gas Station Network (GSN): if you’re inheriting from GSNRecipient or one of the other GSN contracts, you’ll need to add the following snippet to your contracts:\nfunction _msgSender() internal view override(Context, GSNRecipient) returns (address payable) {\n return GSNRecipient._msgSender();\n}\n\nfunction _msgData() internal view override(Context, GSNRecipient) returns (bytes memory) {\n return GSNRecipient._msgData();\n}\n\nUsing Hooks\nTo improve library flexibility, we’re introducing hooks: functions that are called at specific moments during a contract’s operation that you can use to hook into the internals and extend as you wish.\nFor example, the _beforeTokenTransfer hook in ERC20, ERC721 and ERC777 makes it very easy to add additional checks or actions to execute whenever tokens are transferred, minted or burned, regardless of what prompted it.\n// Tokens can only be transferred, minted or burned if the contract is not paused\ncontract ERC20Pausable is ERC20, Pausable {\n function _beforeTokenTransfer(address from, address to, uint256 amount) \n internal virtual override \n {\n super._beforeTokenTransfer(from, to, amount);\n\n require(!paused(), \"ERC20Pausable: token transfer while paused\");\n }\n}\n\nAs an additional benefit, using hooks will allow you to side-step some of the edge-cases product of the new override keyword.\nHead over to our brand new guide on Extending the OpenZeppelin Contracts to learn more!\nWhat’s Next\nWe’ve started work in some exciting features for the upcoming releases, including fixed-point arithmetic and the ERC1155 token standard. To read more and find out how you can contribute, check out our Q2 2020 roadmap!\n\n OpenZeppelin Contracts v3.1 - first release candidate\n\n Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?\n\n OpenZeppelin Contracts v3.0 release candidate\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Help me write an erc20 token and a crowdsale contract\n\n Pinned on Apr 21, 2020\n\n 22 days later\n\n post by abcoathup on May 13, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts Ethereum Package v3.0 has been released.\n\n 29 days later\n\n Split this topic on Jun 11, 2020\n\n A post was split to a new topic: When will @openzeppelin/upgrades support Solidity 0.6.0?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OpenZeppelin Contracts v3.0 final release candidate\n\n Announcements\n\n 7\n\n 4.0k\n\n Apr 2020\n\n OpenZeppelin Contracts v3.0 release candidate\n\n Announcements\n\n 6\n\n 3.4k\n\n Apr 2020\n\n OpenZeppelin Contracts v3.0 beta release\n\n Announcements\n\n release\n\n 0\n\n 4.6k\n\n Feb 2020\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Announcements\n\n 0\n\n 3.2k\n\n May 2020\n\n OpenZeppelin Q1 2020 development update\n\n Announcements\n\n dev-update\n\n 0\n\n 1.5k\n\n Apr 2020","tokens":1587,"squid":"ink-security_audits","role":"Sentinel","at":1791265908911,"hash":"d063266451c352cb257b5577d0469e208af8dbd8"}
{"url":"https://dev-forum.pyth.network/t/i-failed-to-use-api-reference-pyth-network/446/1","domain":"dev-forum.pyth.network","title":"I failed to use api-reference.pyth.network - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n I failed to use api-reference.pyth.network \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Oct 2025\n\n 1 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by unipine on Oct 16, 2025\n\n unipine\n\n Hi mates,\nI tried to use this api (https://api-reference.pyth.network/price-feeds/evm/getPriceNoOlderThan) on the docs directly but failed with following error.\nContractFunctionExecutionError: The contract function \"getPriceNoOlderThan\" reverted. Error: PriceFeedNotFound() Contract Call: address: 0x4305FB66699C3B2702D4d05CF36551390A4c69C6 function: getPriceNoOlderThan(bytes32 id, uint256 age) args: (0x7e990daa483e54a9a2b25ed3312285c867a049b5b3c84d27fe8c2ad9e0d24c57, 60) Docs: readContract · Viem Version: viem@2.34.0\nNot sure what the cause is. I tried several times with different networks and priceIds, but same result.\nHow can I make successful calls?\nThanks.\n\n 2\n\n 2\n\n post by Aditya520 on Oct 17, 2025\n\n Aditya520\n\n Hi @unipine , welcome to pyth dev-forum.\nThe PriceFeedNotFound() error emits when feed has never been updated or the feed Id you are entering is wrong. I would recommend you to update the price feed first.\n\n post by unipine on Oct 20, 2025\n\n unipine\n\n Hi @Aditya520, thanks for your reply.\nI noticed that I need to pay gas fee when updating price feed.\nShould I do this frequently?\nBest\n\n post by Aditya520 on Oct 21, 2025\n\n Aditya520\n\n Yes you need to pay the fees everytime you update the prices.\nSince Pyth oracle follows a pull design. You need to do this if you need latest real-time prices.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 643\n\n Jul 2025\n\n Price feed in Avalanche not working\n\n Price Feeds\n\n evm\n\n 1\n\n 302\n\n Oct 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 720\n\n Apr 2025\n\n Not able to fetch data from id\n\n Price Feeds\n\n 2\n\n 549\n\n Sep 2025\n\n Powered by Discourse","tokens":1381,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265914281,"hash":"914a0f261382711a8b36e358b68edc00baf09e56"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0-release-candidate/2478","domain":"forum.openzeppelin.com","title":"OpenZeppelin Contracts v3.0 release candidate - General / Announcements - OpenZeppelin Forum","text":"OpenZeppelin Contracts v3.0 release candidate \n\n GeneralAnnouncements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n Mar 2020\n\n 1 / 7\n\n Mar 2020\n\n Apr 2020\n\n post by nventuro on Mar 17, 2020\n\n nventuro\n\n Great contributor\n\na847d600e1565ea24f914b4c29b224160376602d2400×1350 255 KB\n\nWe’re excited to announce the first release candidate of OpenZeppelin Contracts v3.0 \nThis is release features the migration to Solidity v0.6, as well as a revamped access control system.\nTo install the release candidate, run:\nnpm install --save-dev @openzeppelin/contracts@next\n\nWhat’s New\n\nAll contracts were migrated to Solidity v0.6.\n\nAccessControl was designed with help from the community and has replaced Roles contracts (such as MinterRole and PauserRole), which were removed.\nCrowdsales were removed: we’ll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.\nWe’ve added hooks, a new feature of the library that will make extending it easier than ever. Read more below!\nMany, many breaking changes with small improvements. We’ve also moved some contracts around (e.g. Ownable is now found under the access directory) and deleted some that were not being used. Head to our changelog to see the full list.\n\nCompiling v0.6 Contracts\nYou can use the OpenZeppelin CLI to compile any Solidity v0.6 contract: just update the pragma statement on your source code and you’ll be good to go!\npragma solidity ^0.6.0;\n\nNote that you will need to use the recent v2.7 release of the CLI to have Solidity v0.6 support. For detailed information about using the CLI compiler, head to its documenation.\nRevamped Access Control\nOne of our most widely-used contracts is Ownable, providing a simple authorization scheme. However, this fell short in complex systems with multiple permissions.\nThe v3.0 release introduces AccessControl, a one-stop-shop for all authorization needs. It lets you easily define multiple roles with different permissions, as well as which accounts are allowed to grant and revoke each role. It also boosts transparency by enabling enumeration of all privileged accounts in a system.\nAccessControl was designed with a security-first mindset, receiving input from a wide array of users and incorporating best practices in the field. We’ll have detailed guides covering it out soon, but in the meantime you can refer to the documentation on the source file.\nMigrating From OpenZeppelin Contracts v2.5\nOther than the contract removals mentioned above, the library API is pretty much the same as in the v2.5 release, so the migration should be straightforward. For instructions on how to update your Solidity v0.5 contracts to v0.6, refer to the official documentation.\nThe exception to this is contracts that use the Gas Station Network (GSN): if you’re inheriting from GSNRecipient or one of the other GSN contracts, you’ll need to add the following snippet to your contracts:\nfunction _msgSender() internal view override(Context, GSNRecipient) returns (address payable) {\n return GSNRecipient._msgSender();\n}\n\nfunction _msgData() internal view override(Context, GSNRecipient) returns (bytes memory) {\n return GSNRecipient._msgData();\n}\n\nUsing Hooks\nTo improve library flexibility, we’re introducing hooks: functions that are called at specific moments during a contract’s operation that you can use to hook into the internals and extend as you wish.\nFor example, the _beforeTokenTransfer hook in ERC20, ERC721 and ERC777 makes it very easy to add additional checks or actions to execute whenever tokens are transferred, minted or burned, regardless of what prompted it.\n// Tokens can only be transferred, minted or burned if the contract is not paused\ncontract ERC20Pausable is ERC20, Pausable {\n function _beforeTokenTransfer(address from, address to, uint256 amount) \n internal virtual override \n {\n super._beforeTokenTransfer(from, to, amount);\n\n require(!paused(), \"ERC20Pausable: token transfer while paused\");\n }\n}\n\nAs an additional benefit, using hooks will allow you to side-step some of the edge-cases product of the new override keyword.\nNext Steps\nAs with all release candidates, the final release will follow one or two weeks later. This is so that community members get a chance to share their thoughts on the upcoming changes before they are made final.\nSo give this release candidate a try, upgrade your project to Solidity v0.6, and tell us what you think!\n\n OpenZeppelin Q1 2020 development update\n\n Can we use OpenZeppelin Contracts 3.0 with upgradeable contracts?\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n post by rumkin on Mar 20, 2020\n\n rumkin\n\n Nice change to access control. I’d like to have a method to list a certain member role too. Also it could be useful to have another method to shutdown member’s access immediately and then to remove exact roles associations.\nI’d suggest to replace error messages like AccessControl: sender must be an admin to revoke with error codes. For example oz/access-control/role-admin. It has a lot of benefits:\n\nIt’s both human and computer friendly in the same time.\nIt could be a part of URL to documentation website.\nIt’s easy to make a structure (tuple) from a string using only one call in JS (and other languages):const [ns, contract, failure] = \"oz/access-control/role-admin\".split(\"/\")\n\n post by nventuro on Mar 20, 2020\n\n nventuro\n\n Great contributor\n\nDoes this mean listing all roles an account has? This could be useful, though it would require additional storage (and therefore increase gas costs). I created an issue for this, thanks!\n\nInteresting! I fear this may lead to too much complexity though, since we'd have to keep track of 'banned' accounts, and these would be in a strange intermediate state where they have a role, but are unable to use it. It also creates issues regarding permission, who is allowed to ban an account? It'd be equivalent to calling revoke on all roles, which only the role admins can do.\nIf the goal is to remove all roles from an account, I think this can be better achieved with the enumeration suggested above, and then calling revokeRole for each role.\n\nThanks! We've had some discussion on what revert reasons should look like, and consensus was the human-readable strings were important. Note you can still split on the : to separate contract and message, as shown on your snippet above!\nThe bit about linking to the documentation is very interesting though, I'll think some more on it. Thanks!\n\n post by rumkin on Mar 20, 2020\n\n rumkin\n\nDoes this mean listing all roles an account has?\n\nYes. It's exactly what I meant.\n\nI fear this may lead to too much complexity though, since we’d have to keep track of ‘banned’ accounts, and these would be in a strange intermediate state where they have a role, but are unable to use it.\n\nIn my opinion it's an active/inactive boolean. It looks pretty straightforward to me, maybe for others too, probably it should be researched/need more feedback. It could (and probably should) be implemented as a separated contract for inheritance. And then be used in the final contract like this:\nrequire(isActive(_msgSender()))\nrequire(hasRole('admin', _msgSender()))\n\nIt's helpful to prevent attacks in the periods when gas cost is too high and a bunch of rejection transactions just could stall. Also it allows to suspend account membership for some period of time and then restore it without a need of reassigning all the permissions.\n\nhuman-readable strings were important\n\nAgree with you about importance of human-readability. But also unstructured string error message usually leads developers just to ignore error instead of properly handling it, what is worse in my opinion. And now solidity has a try-catch statement so it would be way more easy to identify an error. And structure should help to remember error code. This is my thoughts on it, maybe it would change your mind.\n\n 12 days later\n\n post by albertocuestacanada on Apr 2, 2020\n\n albertocuestacanada\n\nIs this information going to be needed by a smart contract? If it is only for UI or audit purposes you could retrieve role memberships from blockchain events with a listener.\n\n 18 days later\n\n post by abcoathup on Apr 20, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts v3.0 is released \n\n 9 days later\n\n post by rumkin on Apr 30, 2020\n\n rumkin\n\n albertocuestacanada\n\n It’s required for excluding an address from all the roles it has from another contract or single method call. Without it you’ll need to build a service to monitor such a list and reentering it into blockchain through transactions, what seems irrational to me.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OpenZeppelin Contracts v3.0\n\n Announcements\n\n 1\n\n 5.5k\n\n May 2020\n\n OpenZeppelin Contracts v3.0 final release candidate\n\n Announcements\n\n 7\n\n 4.0k\n\n Apr 2020\n\n OpenZeppelin Contracts v3.0 beta release\n\n Announcements\n\n release\n\n 0\n\n 4.6k\n\n Feb 2020\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Announcements\n\n 0\n\n 3.2k\n\n May 2020\n\n Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Contracts\n\n 12\n\n 9.3k\n\n Jun 2021","tokens":2291,"squid":"ink-security_audits","role":"Sentinel","at":1791265921476,"hash":"76f98740735b4ae9af81ddeffdcaf3da21d92e47"}
{"url":"https://governance.aave.com/t/aave-governance-process-document-v1/18577/5","domain":"governance.aave.com","title":"Aave Governance Process Document v1 - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 9\n min\n\n Aug 2024\n\n 6 / 6\n\n Oct 2024\n\n Aug 2024\n\n post by ACI on Aug 8, 2024\n\n ACI\n\n Leader\n\n Aave Governance Process Document v1\nAuthors: ACI\nDate: 2024-08-08\nIntroduction\nThe “Aave Governance Process’’ is an all-in-one document for contributing to Aave DAO. This document will be continuously updated by Aave DAO contributors. The previous version is available here: Aave Finance Governance Process v0\nThis document provides an overview of the different roles, flow and pathways for various stakeholders to participate in Aave DAO.\nGovernance Processes\nThe processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate.\nAt a high level the Aave governance process is composed of five stages, from temp check forum dicussion to on-chain votes. The stages are as follows: temp check forum post, temp check snapshot, ARFC forum post, ARFC snapshot, AIP on-chain vote. A standard proposal will take a minimum of 19 days to pass through all of these stages, although it is uncommon that it progresses this quickly as time is needed for writing and reviewing payloads, and there are timelocks and other waiting periods relating to the various voting stages.\nProposal types\nThere are generally three main types of proposals in Aave Governance; these three general proposal classifications strictly refer to the maturity of a proposal in the Aave Governance Process. In specific situations, in order to minimise governance burden and increase speed, there are streamlined versions of this process. These situations are described in a later section.\n\nTEMP CHECK: These serve as “temperature checks” to gauge community sentiment on a proposal or topic. They do not necessitate service provider involvement or a high level of precision or technicality.\nTEMP CHECK Snapshot: This is an off-chain vote using the Snapshot platform, with voting starting after the TEMP CHECK discussion period has ended.\nARFC: Aave Request for Comment (ARFCs) are precursors to Aave Improvement Proposals (AIPs). Relevant service providers are formally invited to provide feedback on them, and the specification section of ARFCs should detail how the potential upcoming AIP will impact Aave protocol smart contracts.\nARFC Snapshot: This is an off-chain vote using the Snapshot platform, with voting starting after the ARFC discussion period has ended.\nAIP: Aave Improvement Proposal (AIPs) are a formal proposal to improve the Aave Protocol; before submitting an AIP, an ARFC should be submitted to the community to gather feedback. Once the AIP has been written and reviewed, the AIP will be submitted via GitHub to begin the process of putting the AIP on-chain.\n\nGeneral proposal process\nAs pictured below, the standard proposal process is as follows:\n\nPost a Temp Check for 5 days to allow discussion and gauge sentiment.\nTemp Check Snapshot vote for 3 days.\nPost an ARFC for 5 days to allow for closer scrutiny and discussion.\nPost an ARFC Snapshot vote for 3 days.\nPost an AIP vote for 3 days.\n\nThis process takes around 19 days at a minimum, but often takes longer due to backlogs and time taken for writing and reviewing payloads, there are also various timelocks and waiting periods relating to the voting stages which extend this minimum timeframe. It should also be noted that ACI Skyward can help tokenholders to ensure the governance process proceeds smoothly and efficiently.\nstandard governance process2264×412 43.3 KB\nStandard governance process\nProposal Discussion\nAs part of the governance process, a discussion must be started on the Aave Governance Forum, as shown in the diagram above there are two rounds of discussion, firstly as a Temp Check, and then as an ARFC if the Temp Check Snapshot passes.\nOnce the proposal has been posted on the forum, it must:\n\nBe available for review and comment for a minimum of five days.\nContain all relevant information that would be contained in the AIP\nComply with any relevant templates that apply to the proposal.\n\nThe proposal author may decide to modify the proposal based on feedback during the discussion phases.\nMoving to Vote\nOnce a proposal meets the required conditions, it can proceed to the voting stages, which include both off-chain and on-chain voting methods. Voting in the Aave DAO allows AAVE, stkAAVE, and aAAVE holders to participate directly or delegate their voting power to representatives.\nOff-chain voting (Snapshot): Off-chain votes are used to gauge the sentiment for Temp Checks and ARFCs. The off-chain voting period lasts 3 days for both Temp Check and ARFC votes.\nOn-chain (Native): On-chain voting is required on any Aave Improvement Proposal. Aave on-chain votes will occur on the Aave Governance Portal. The voting period must last for a minimum period of 3 days. With the launch of V3 governance, it is now possible to vote across multiple chains and carry out gasless voting, read more here.\nThe on-chain voting process is composed of four stages:\n\nFirst of all, the proposal and payload are reviewed by Security Service Providers to ensure that it is not malicious and that it doesn’t contain errors which put the protocol at risk.\nThe second stage is entered if no errors or malicious payload are identified, and the proposal is moved on-chain. Once the proposal is on-chain, a voting delay of 1 day must pass before the proposal becomes active.\nIn the third stage, once the voting delay has elapsed the proposal becomes active and is available to be voted on. This stage lasts for 3 days.\nIn the fourth stage, once the voting period has ended, the proposal will either have SUCCEEDED or FAILED, depending on whether it has passed quorum and has a majority of YAE votes or not. In this stage, if the proposal has passed, the payload is queued with a timelock of 1 day, after this is elapsed the payload may be executed. If the proposal is not executed before the end of a grace period it expires and must be deployed and voted on again from the beginning of the on-chain voting process.\n\nA visual representation of this flow is shown in the figure below.\nonchain voting process1536×513 101 KB\nOn-chain voting process\nIn both off-chain and on-chain votes, the voting power is directly proportional to the amount of AAVE, stkAAVE or aAAVE a user holds or has delegated to them. For more details, please refer to the official documentation.\nQuorum\nIn order for a proposal to succeed, a minimum of 320,000 AAVE, stkAAVE, or aAAVE must participate in the vote. In addition to this, the winning vote must also have 320,000 votes. For example if a proposal had 320,000 total votes, with less than 320,000 votes for the winning option, this would not meet quorum requirements. Any changes to the quorum requirements must be amended by the community through an AIP.\nEach vote has to reach the minimum quorum, even if it has a majority, for it to be considered an official proposal. It is the responsibility of the proposal author to enlist voting participation from the community in order to reach a quorum.\nACI Skyward\nSkyward is a free service launched by ACI to assist Aave DAO members with the proposal process, making it more accessible and streamlined. The service covers various AIP types, including asset onboarding, risk parameter changes, interest rate strategy changes, supply & borrow caps changes, E-mode activation, and asset offboarding. Skyward is open to everyone and free of charge in order to lower the barriers to participation in Aave’s governance.\nHow Skyward works:\n\nInitial contact: Proposer will often contact ACI before engaging in the governance process to ensure efficient progression through the various stages.\nTemp Check: Proposer writes a Temp Check and has ACI review the draft before publishing to forums.\nTemp Check Snapshot: ACI publishes Temp Check Snapshot.\nARFC Request: ACI creates and publishes the ARFC in collaboration with the proposer.\nARFC Snapshot : ACI publishes the ARFC Snapshot.\nAIP Creation: If the Snapshot vote is successful, ACI writes the payload and publishes the AIP for a vote.\n\nTo help understand at what point ACI Skyward takes responsibility for the governance process, see the figure below.\ngovernance process ACI Skywards2437×712 138 KB\nGovernance process when making use of ACI Skyward\nNon-standard Governance Frameworks\nFor some common actions that governance needs to take in order to manage the Aave protocol, there are frameworks for expedited governance. This helps reduce the governance burden on the DAO, tailors governance processes to the level of scrutiny required for various tasks, and helps the DAO run more efficiently.\nARFC Addendum\nIn order to make minor changes to an existing ARFC, rather than restarting the process from Temp Check stage, an Addendum can be proposed by forum post which progresses to Snapshot then AIP. This expedites minor changes, reducing governance burden. An illustration of the process is shown below:\nARFC Addendum Process1664×408 30.7 KB\nARFC Addendum Governance Process\nAsset Onboarding Framework\nThe Asset Onboarding Framework is available to read on the forums here: [ARFC] Update the Asset Onboarding Framework along with minor modifications here: [ARFC Addendum] Update Asset Onboarding Framework.\nThere are two pathways for onboarding new assets to Aave. If there is no existing Aave market for the asset, the standard governance process is followed, starting at temp check and progressing through all standard governance stages. For assets already listed in other Aave markets, a direct-to-AIP process is used, skipping the Temp Check stages and taking about 10 days. To use this process the following must be applicable for the asset being onboarded:\n\nExisting Aave market presence.\nSubmission or feedback from a risk service provider.\nSupply cap not exceeding 50% on the respective chain.\nAt least 90 days old Chainlink price feed.\n\nNew listing candidates must deposit $100 worth of the intended asset into the Aave Short Executor. This deposit is non-refundable and required before proceeding to the AIP phase.\nAsset onboarding proposals are most commonly used for deploying markets for already listed assets on new chains, for example see these proposals to deploy weETH markets on Base and Scroll.\nAsset Onboarding Process994×406 19.6 KB\nAsset onboarding process for assets already listed on Aave\nNew Chain Deployment Framework\nThe New Chain Deployment Framework is a standardized process for deploying the Aave Protocol on new blockchains. This framework aims to create a transparent approach for evaluating and deploying new Aave v3 instances. The full forum post detailing the framework along with templates for both temp check and ARFC proposals can be found here: [ARFC] New Chain Deployment Framework.\nThe process follows these key steps:\n\nPost a TEMP CHECK governance thread for 5 days\nSnapshot vote for 3 days (24 hours after gov thread)\n\nDocumentation submission:\n\n7 days after the Snapshot vote\nIf deadline is not met, there will be a frozen period of 30 days. After that period documentation could be analyzed again\n\nTechnical review duration\n\n21 days since documentation submitted\nIf technical review fails due to security concerns, process will be frozen until it’s been resolved.\n\nPost an ARFC governance thread for 5 Days, after technical review has been successfully completed\nSnapshot vote for 3 days (24 hours after gov thread)\nPost an AIP vote for 5 days (Minimum 320k vote required)\n\nThese steps are shown visually in the figure below:\nNew Chain Framework2764×1168 231 KB\nNew Chain Onboarding Framework flowchart\nThe framework introduces stricter timelines and requirements than the standard proposal process. If documentation submission deadlines are not met, there’s a 30-day freeze period. Technical review failures due to security concerns freeze the process until resolution.\nThis framework balances security and speed, providing a more efficient governance process while maximizing the benefits of Aave’s brand for new chain ecosystems. It aims to streamline the deployment process, reduce governance overhead, and prioritize chains offering standing deposits or other benefits to the Aave protocol and its users.\nEmission Manager Framework\nTo allow quick addition of new emissions admins to Aave pool reserves, the process of adding new emissions admins follows a direct to AIP framework. This framework also allows\npre-authorized inclusion of an emission admin as part of either an ad-hoc steward or current risk steward role to facilitate a more efficient and streamlined onboarding process. Further information can be found here: [ARFC] Emission Manager Framework Update.\nThe governance process under this framework is as shown in the below figure.\nAsset Onboarding Process994×406 19.6 KB\nEmissions manager framework governance process.\nTechnical Maintenance Proposals\nWith Aave instances in multiple versions (v1, v2, v3) and networks, periodically it is necessary to do maintenance tasks related to infrastructure consistency. In order to balance efficiency and transparency of updates, Technical Maintenance Proposals are posted by BGD Labs, the current Development Service Provider on this thread (Technical maintenance proposals) for 3 days and then move directly to AIP if there is no feedback or concerns from the community. The governance process for Technical Maintenance Proposals is shown in the below figure.\ntechnical maintenance proposal956×397 19.7 KB\nFunding\nAs a mature DAO, there are both planned and ad hoc funding needs. In order to address these, several governance processes relating to funding have been developed. These are: one off funding requests, grants, bug bounties, and operational budgets.\nDirect Funding Through Governance\nA number of contributions to the Aave protocol have been funded through Governance Proposals for example funding the development of Aave V3.\nBug Bounties\nThe Aave bug bounty program operates in collaboration with Immunefi to enhance the security of the Aave protocol. BGD Labs and Aave Companies act as appointed representatives of the DAO for this program, with BGD responsible for most systems and Aave Companies managing GHO-related submissions. Full details and discussion around the Bug Bounty Program are available here: [TEMP CHECK] Aave Bug Bounty Program on Immunefi and here: BGD. Aave <> Immunefi bug bounty program.\nEligibility criteria and systems covered under this bug bounty program are as follows:\n\nCriteria\nDetails\n\nSystems Covered\nAave v2, Aave v3, Aave Governance v2, Aave Safety Module, GHO stablecoin\n\nEligible Participants\nAll, except Official and Former Official Contributors\n\nKYC Requirements\nMay be required at discretion of DAO representatives, not for Medium or Low severity reports\n\nSpecial Conditions\nMeasures may be implemented to prevent submissions from Official Contributors for high and critical reports\n\nPayouts under the bug bounty program are as follows:\n\nSeverity\nPayout Range\nApplicable Systems\n\nCritical\n10% of funds at risk, $50,000 to $1,000,000\nAave v2 Ethereum, Aave v3, Governance v2, Safety Module, GHO\n\nCritical\n10% of funds at risk, up to $250,000\nAave v2 on other networks\n\nHigh\n10% of funds at risk, $10,000 to $75,000\nAave v2 Ethereum only\n\nMedium\n$10,000\nAll systems\n\nLow\n$1,000\nAll systems\n\nAdditional payout terms and procedures:\n\nFor repeatable attacks, funds at risk calculated within first 45 minutes from first attack\nPayments made via governance proposals in a mix of AAVE and stablecoins\nPayouts batched monthly to avoid governance overload\nImmunefi’s fee of 10% applied on top of each bounty payout\nProof of Concept (PoC) required for all Smart Contract bug reports\nOnly Critical and High impacts in scope for Aave v2 on Ethereum\nOnly Critical impacts in scope for Aave v2 on other networks\nAttacks involving other protocols may be considered if they meet specific criteria\nBGD can modify technical aspects, but fundamental changes require governance approval\n\nThis program allows Aave to maintain a robust security posture while engaging with the wider security research community in a structured manner.\nOperational Budgets\nIn order to minimise governance overhead, trusted providers may receive funds for scoped and budgeted activities ahead of time. These are for well defined activities that provide either essential or beneficial services to the DAO. Most significantly these include Security Budget for BGD labs as per this proposal: [ARFC]. BGD. Security budget request - December 2023, and Events and Sponsorship Budget to Aave Labs as per this proposal: [TEMP CHECK] Aave Events & Sponsorship Budget.\nGovernance Roles\nDelegates & Delegators\nDelegates\nDelegates are community members who have received voting power from other members of the community or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have entrusted them with their voting power. Some delegates are compensated under the Orbit program.\nDelegators\nDelegators are community members who hold Aave, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another person. The person to whom they delegate their voting power is considered a delegate. This system allows delegators to have their interests represented in governance decisions without having to participate directly in every vote.\nContributors and Service Providers\nContributors\nContributors are community members who participate in and dedicate their time to the Aave DAO. They contribute by joining working groups, fulfilling bounties, building on top of the Aave Protocol, or working for the DAO via grants. Contributors work towards completing shared goals that benefit the Aave ecosystem.\nService Providers\nService providers are specialized entities or groups that offer essential services to maintain and enhance the Aave Protocol. The current service providers are:\n\nChaos Labs: Risk service provider\nLlamarisk: Risk service provider\nKarpatkey: Finance service provider\nCertora: Security service provider\nTokenlogic: Finance service provider\nBGD Labs: Development service provider\nACI: Growth and business development service provider\n\nGuardians\nThe Aave Guardians are crucial for maintaining the protocol’s security and integrity. They are divided into two groups: Protocol Guardians, who handle emergency responses and can pause markets, and Governance Guardians, who can veto malicious governance proposals. The Guardians operate under a 5/9 multi-sig arrangement.\nFor more information on the Guardians’ permissions, refer to this detailed view of permissions in Aave systems. For a general overview of their role, see the Medium post about Aave V2 Governance here.\nProtocol Emergency Guardian\nThis Guardian holds the EMERGENCY_ADMIN role in Aave V3, as well as similar roles in V2 and other related systems. The primary function of the Protocol Emergency Guardian is to act swiftly in emergency situations to protect the protocol. It is composed of highly active entities within the Aave DAO, such as service providers and delegates. The multi-sig configuration for this Guardian is a 5-of-9 setup. The current Protocol Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nProtocol Emergency Guardian\nAddress\n\nChaos Labs\n0x5d49dBcdd300aECc2C311cFB56593E71c445d60d\n\nLlamaRisk\n0xbA037E4746ff58c55dc8F27a328C428F258DDACb\n\nKarpatkey\n0x818C277dBE886b934e60aa047250A73529E26A99\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nTokenLogic\n0xb647055A9915bF9c8021a684E175A353525b9890\n\nBGD Labs\n0xf71fc92e2949ccF6A5Fd369a0b402ba80Bc61E02\n\nACI\n0x57ab7ee15cE5ECacB1aB84EE42D5A9d0d8112922\n\nEzr3al\n0xC5bE5c0134857B4b96F45AA6f6B77DB96Ac1487e\n\nStable Lab\n0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E\n\nGovernance Emergency Guardian\nThis Guardian is responsible for cancelling governance proposals if they are detected as malicious or contain errors, typically identified during the on-chain verification stage by Certora. Unlike the Protocol Emergency Guardian, speed is less critical for this role since governance proposals unfold over a period of five days, allowing adequate time for issues to be identified and addressed. The multi-sig configuration for this Guardian is also a 5-of-9 setup. The current Governance Guardians are shown in the table below and were updated in this ARFC Addendum.\n\nGovernance Emergency Guardian\nAddress\n\nSeb (Zapper)\n0xa1c9ceed5ff78f700dc4930514621843b5fac272\n\nMounir (Paraswap)\n0xfd639f49Da6cadc98f01B60900C8BE30C38c4B27\n\nGavi Galloway (Standard Crypto)\n0xbd4DCfA978c6D0d342cE36809AfFFa49d4B7f1F7\n\nNenad (Defi Saver)\n0xDA5Ae43e179987a66B9831F92223567e1F38BE7D\n\nFernando (Balancer)\n0x4C30E33758216aD0d676419c21CB8D014C68099f\n\nRoger (Chainlink community)\n0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396\n\nMariano Conti (DeFi OG)\n0x936CD9654271083cCF93A975919Da0aB3Bc99EF3\n\nMarin (Lido)\n0x0D2394C027602Dc4c3832Ffd849b5df45DBac0E9\n\nCertora\n0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9\n\nStewards\nStewards were introduced to allow the DAO to respond quickly to market changes in order to remain competitive and address risks. They are delegated responsibility over specific parameters within certain boundaries of magnitude and frequency of change. The benefit of this is that minor changes do not need to go through a full governance cycle, increasing speed and reducing governance burden on delegates and tokenholders. At time of writing there are stewards for managing: GHO, lending parameters, and treasury operations.\nGHO Stewards\nThe GHO Stewards are a group of Contributors and Service Providers who manage critical parameters for the GHO stablecoin, ensuring its stability. This group has the authority to adjust the:\n\nGHO Borrow Cap\nBorrow Rate\nvarious GSM parameters like Exposure Cap, Bucket Capacity, Price Strategy, Fee Strategy, and Price Range (Freeze, Unfreeze)\n\nThe ranges for parameters which the GHO Stewards may adjust are shown in the below table and were proposed in the following ARFCs [ARFC] GHO Stewards, [ARFC] GHO Stewards + Borrow Rate Update.\n\nDescription\nValue\n\nGHO Aave Bucket Capacity\n100% Increase\n\nGSM Exposure Cap\n100% Increase\n\nGSM Bucket Capacity\n100% Increase\n\nGSM Fee Strategy\n+ 0.5%\n\nGSM Price Range\n(Freeze, Unfreeze)\n\nGHO Borrow Cap\n100M\n\nMax GHO Borrow Rate Adjustment\n5%\n\nMax GHO Borrow Rate\n25%\n\nFrequency of Change\n2 days\n\nThe creation of GHO Stewards aims to streamline governance, allowing quick adjustments to maintain the GHO peg, especially during market fluctuations. The GHO Stewards operate under a 3-of-4 multi-sig configuration and GHO Stewards at time of writing are:\n\nKarpatkey\nTokenlogic\nACI\nChaos Labs\n\nRisk Stewards\nRisk Stewards are responsible for managing critical risk parameters within the Aave protocol. They are able to make adjustments to supply and borrow caps, reducing the need for frequent community votes. This setup ensures rapid responses to emerging risks while minimising governance overhead.\nThe parameters that Risk Stewards can change are:\n\nSupply and Borrow Caps: Increasing caps with constraints on frequency and maximum percentage increase to maintain protocol stability.\nCollateral Risk Configurations: Adjusting parameters such as Loan-to-Value (LTV), liquidation thresholds, and liquidation bonuses.\nInterest Rate Strategies: Fine-tuning base rates, slopes, and optimal points to align with market conditions.\n\nThe parameters that the Risk Stewards can control are shown in the table below and were discussed in the following proposal: BGD. Risk Steward Phase 1: CapsPlusRiskSteward.\n\nDescription\nValue\n\nFrequency of change\n5 days\n\nMaximum supply cap increase\n50%\n\nMaximum borrow cap increase\n50%\n\nRisk Stewards operate under strict on-chain validations and are managed by a 1-of-1 multisig. Risk Stewards at the time of writing are:\n\nChaos Labs\n\nFinance Stewards\nPlease note the Finance Stewards system in not yet live and is for information purposes only at this point, it is planned that this will go live in the near future.\nFinance Stewards are responsible for executing pre-approved and budgeted financial operations on behalf of the Aave DAO. They manage the Aave DAO’s funds through a smart contract that acts as an admin of the collector, streamlining the management of treasury assets and reducing the need for frequent on-chain votes.\nThe Finance Stewards have the authority to:\n\nMigrate assets from v2 and deposit into v3\nUse the Aave Swapper to exchange treasury assets\nWithdraw and deposit into V3\nTransfer and stream tokens to pre-approved addresses within set budgets such as ACI Frontier Program and ACI Merit Program\n\nProposed Finance Stewards at the time of writing are:\n\nKarpatkey\nTokenlogic\n\n TEMP CHECK: Add support for Wrapped Super OETH (wsuperOETHb) to Aave v3\n\n Aave Finance Governance Process v0\n\n [TEMP CHECK]: Add support for Wrapped Origin Sonic (wOS) to Aave v3\n\n [ARFC ADDENDUM] Updated Framework for ARFC and TEMP CHECK Proposals\n\n ACI Retrospective 2024-present\n\n read \n\n 9\n min\n\n Pinned on Aug 8, 2024\n\n post by heyjared on Aug 8, 2024\n\n heyjared\n\n This is great, thanks for the overview @ACI & @Kene_Anode\n\n post by Stratego on Aug 11, 2024\n\n Stratego\n\n Love this \n\n post by superproduct on Aug 12, 2024\n\n superproduct\n\n Aave Labs-Technical SP\n\n Thanks @ACI. Would like to see this document added to the aave-dao github org once it is finalized\n\n 2 months later\n\n Closed on Oct 7, 2024\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n Aave Chan Initiative Delegate platform\n\n Delegate Platforms\n\n 43\n\n 13.9k\n\n 4d\n\n TokenLogic Delegate Platform\n\n Delegate Platforms\n\n 38\n\n 6.7k\n\n 1d\n\n Ignas Delegate Platform\n\n Delegate Platforms\n\n 196\n\n 5.1k\n\n May 14\n\n Areta Delegate Platform\n\n Delegate Platforms\n\n 581\n\n 13.5k\n\n Aug 10","tokens":6509,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265934695,"hash":"934adb9522cc9e04a2ee99c547122b1beef00f84"}
{"url":"https://dev-forum.pyth.network/t/cant-update-price-via-vscode/65","domain":"dev-forum.pyth.network","title":"Can't Update Price Via Vscode - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Can’t Update Price Via Vscode \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 4\n\n Apr 2025\n\n 1 / 11\n\n Apr 2025\n\n Apr 2025\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n Hi guys, I updated the price of $BIO on the pyth base contract via basescan. However, when I try doing same via vscode via forking mainnet I get 0x6ce2251a can’t really pinpoint what custom error message this points to\naddress contractAddress = 0x8250f4aF4B972684F7b336503E2D6dFeDeB1487a;\nbytes32 id = 0xd9d22050e7413a16129f1334cd4dd5a359975ce16389cdadae8f677cf46e2839;\nupdateData[0] = \"0x504e41550100000003b801000000040d00b68f0e892457b4821243f5e462d34a369aa4936a8d3b35037c1b6c8a04a9a36476cd1ebbc0a60311e688f20d8dfff6e5cdf42be5ad44a477aca283a7ff20047b0103f6e2adde8f037ca625a1e9f06774e5650015ee9ed08168a32df24e20bfcae1565c45fa34a3e2d25738c3c0380d1bf8c284b487a1efdb1961eb53652bdad16bd30104b2cd90492cd743dec95cddcc0788e1d512e76bb0586e3ebfe02a9ef0170fe82e753ee9e34fbe71741138aeb5e7fd75d686741ffe07e689d2168d6548048c796a01064c2ccd03540dfba573eb34c7ca333077bc5fc12479c17271f5f02af33bcd3a247489f96dced19002e0fe70b3b233a1b8e0d6b3afb1bd5c3bf2757d752c215beb0108b788192773f7aefd8c129f4a75cc5201fe95b12923e835a70b6c5bfbf495ba5a066b4b285d8e3a4cdddc074bf5ed51ada9ed58b1db07296bb3e47620c503b91a000ab4f1aac4759e568d7c0c6509e12884606f927877d94ea24de677fb7767668dc259cdfa5c1d0d16d98f3b887064f760ecca9ba7383cc400aadb46a2f0ae690873010bf44ca2f2afd564afcc8ffbabae88899aa1ac3544d4ad6cf60f99846ec9f865770a07c56d2e4920f9fea195ad3bd660e7adae1f2f56e7fb1e33ad7a1eb00950db000c2da910166d3f7c2e6279f02be39b41db3363bad3c72873cf39120463b848c10e7836bc9ea565c6e5835a743637c475a1135be7311e77cf7f840225590d5c7bd6010d3c78a02ef8dd6f3d8a2701789f45ec27588dafe5cda2cd25b45aed2ef9baa2591b8c4f69a9e4099b4d90df673205c31ade8a6ab52052232eda7e603db4ace9ab000e70e17715875c1e8a236b98526589996ae4beb59a83486d668f091eaf0ee97b5e040883d9a70f39d4d57df764c2f32e3d74dbe6d631a1b9c5a447f4215d20e123000fad5f138dd4b38f07869f943cf44264823a90ea8a771befa1261da63774a0db8a2dabaee1e2155bdc776c0bd12d7843cff28ad773f35a35e855d6df6cfb0f2b700010b535a6b2bbdf478c9728c3a9f9b1c32804647c080a1df804fc908565117082077bcd47d1e17d35be34fbf5c0525a50cc9e1f4ce5af016c7162983115e1bc39a6001164c30404a6b689db35a8a6bc703a028e892f85edce7b31d47af03abe0dbcb144371482c4a8124d719658bbfc421a54992c90ef067ee86358e56758097b56278b006800ad0700000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000787dd08014155575600000000000c95591d0000271095471fe15e1ddf5bec8c9902a2500ab399234eb801005500d9d22050e7413a16129f1334cd4dd5a359975ce16389cdadae8f677cf46e2839000000000044ba93000000000000287cfffffff8000000006800ad07000000006800ad070000000000443e1f000000000000266b0c49e53a13b3b3971c21d9a0e56ee9feaadefaa34ab26512d48efe35fbc704fa0ce9621fc9128cbf6c1f2edad1d5d06d76e6676b4cc7db667adaa11b2c9ddea5a40c3d778a2d361ed1c9409c324ec3cc0433af297d5df786e55ba744a33daffc6419d50acfb52ac513900579bd9110db76c61895a15843327f80cb84744d47deb617a7f8c5c4747aeac357f25e3afe17b2fc377383f3038b5a6bb69aff71722f22f0b032cf24a73a6ac07644a51716321d59bb121d425dd1b8bc73e7dd2555bae4e9cda7cf1d308b26c638d09dc67bb4a4ed67fb394e909c086be03986b47541452a45bad230bb418744d47aa7f5af9eca;\nScreenshot 2025-04-17 at 09.03.491621×703 98.1 KB\n\n Custom error 0x6ce2251a\n\n 6\n\n 4\n\n post by 0xcredence on Apr 17, 2025\n\n 0xcredence\n\n Hi there @c-note thank you for your question!\nIt seems that you are directly feeding the price feed id to the updatePriceFeeds function.\nBut you should feed in the update data fetched from EvmPriceServiceConnection to this function. Take a look at our js sdk for some examples:\n\nGive it a try and see if this works\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n Hello @0xcredence, thanks for your prompt response, the update data I used was gotten from Swagger UI which is were I got the update data I used to update the price via basescan which worked.\n\n post by ali on Apr 17, 2025\n\n ali\n\n @c-note the error doesn’t seem to be related to Pyth and I suspect it is because forking doesn’t fork all the contracts properly (and I have faced it in the past too). Many contracts are used in this call: proxy and main contract for Pyth and proxy and main contract for Wormhole.\nFor testing I generally recommend using MockPyth contract so you can set your own prices and simulate your desired protocol behaviours with it.\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n @ali I tried interacting with mainnet via a script not forking the mainnet and still got same error\n\n post by ali on Apr 17, 2025\n\n ali\n\n When you are not forking the contract doesn’t exist. You need to deploy MockPyth as setup phase of your testing and interact with it.\n\n post by c-note on Apr 17, 2025\n\n c-note\n\n @ali I meant sent a tx via the mainnet paid for gas and all but failed with same error message gotten when I just forked mainnet.\nMy point is when I interact with fork-mainnet or base mainnet i still get same error message when I make this call via vscode. (But everything works well when I do this via basescan)\n\n post by ali on Apr 17, 2025\n\n ali\n\n @c-note I see, in your code i suspect the fee is wrong. you need to pass the updateData to getUpdateFee method and not the price id.\nIf that’s not the problem, please send us a reproducible code snippet to run.\n\n post by c-note on Apr 20, 2025\n\n c-note\n\n @ali The fee is correct, the returns fee as 1 Wei. Here you go\n\n post by ali on Apr 22, 2025\n\n ali\n\n @c-note thanks for sharing this script as it helped a lot to troubleshoot it. The problem is that in forge assigning update data to bytes like that is not right. You need to use hex\"deadbeef...\" and by fixing it I could send the transaction successfully.\np.s: I found the error was about Wormhole saying the message format is invalid (see this) and it made me realize that the update data format was wrong.\n\n post by c-note on Apr 22, 2025\n\n c-note\n\n @ali this fixed my issue thanks much.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 774\n\n May 2025\n\n Price Feed not working on AVAX and BASE\n\n Price Feeds\n\n 1\n\n 497\n\n Apr 2025\n\n We are facing an issue with the update_price_feeds_with_funder function when updating the Pyth price\n\n Price Feeds\n\n 3\n\n 655\n\n May 2025\n\n Powered by Discourse","tokens":2500,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265946236,"hash":"7c1be056eeee278feb85b8e1abaf443a2382c479"}
{"url":"https://governance.aave.com/t/areta-delegate-platform/16780","domain":"governance.aave.com","title":"Areta Delegate Platform - Delegate Platforms - Aave","text":"Areta Delegate Platform \n\n Delegate Platforms\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Key Info\n\n Introduction\n\n Delegate Statement (why you should delegate to us)\n\n Conclusion\n\n Conflicts of Interest\n\n Waiver of Liability\n\n Feb 2024\n\n 1 / 582\n\n Feb 2024\n\n Aug 10\n\n post by sid_areta on Feb 28, 2024\n\n sid_areta\n\n Orbit-Delegate\n\n Key Info\n\nDelegate Address: aretagov.eth\nTwitter: https://twitter.com/areta_io\nWebsite: https://www.areta.io/\nLead Delegate: Siddharth Shah\nEmail: sid@areta.io\nTelegram: explorandoahora\n\nPlease delegate to us on: 0x8b37a5Af68D315cf5A64097D96621F64b5502a22\nIntroduction\nAreta Governance is a leading governance strategy firm focused on ecosystem growth. Our connected investment bank with deep strategic expertise, enables us to serve our partners holistically, rather than working in isolated governance silos. We have had the privilege to serve industry leaders such as Uniswap, Safe, Aave, and dYdX.\nOur mission is to sustainably grow the number of quality apps in crypto ecosystems by lowering barriers for builders and providing them with resources and support from inception to growth.\nWe do this through Smart Capital Activation, a tailored approach to capital allocation backed by dedicated design, strategy, and execution. Our current focus is on:\n\nBuilder Support Programs, such as subsidy funds for security audit costs, RPC services, and essential infrastructure, tooling, or support mechanisms that enhance developer participation;\nFunding Competitions with elimination-based funding rounds, providing support to early-stage projects and accelerating the maturity of the best-performing projects;\nGrowth-Stage Incentive Programs providing sustainable, KPI-driven rewards for later-stage projects directly aligned with onchain performance.\n\nWith this approach, we aim to smartly allocate capital across the builder funnel, getting capital, distribution, and support services to builders and sustainably activate capital for growth where it makes sense.\nWe have had the privilege to work for some of the leading ecosystems in the space. Examples of our work on the governance side include leading the first cross-ecosystem growth initiative for Uniswap and Arbitrum, leading governance optimization initiatives for Safe, dYdX, and Arbitrum, and conceptualized and managed the first-ever Security Audit Subsidy Funds in crypto for Arbitrum and Uniswap. On the transaction side, we led the first acquisition of Coingecko, the sale of Solscan to Etherscan, and the strategic wind-down of Gro DAO.\nWe focus on excellent DAO participation with robust, defensible analysis of proposals through a structured voting process while simultaneously applying our deep institutional knowledge and strategic governance expertise to offer proactive DAO governance solutions aimed at nurturing the ecosystem for the long term.\nDelegate Statement (why you should delegate to us)\nFirst and foremost, Areta’s key tenets as delegates are as follows:\n\nWe will aim for 100% voting participation - we are deeply invested in the ecosystem and our goal is to meaningfully support its direction via thoughtful, educated governance decisions.\nWe always commit to voting independently and impartially.\nWe will open source our rationale through frequent updates to this thread, which will act to anchor our thinking and make ourselves accountable to the wider Aave community.\n\nWe will achieve these tenets through our four unique sources of value:\nStructured & Streamlined Voting Process\n\nOur team lead adds new proposals to a shared tracker and assigns each incoming proposal to a specific member of the team.\nFor each proposal, we prepare a standard memo summarising the key issues, the black and white hat case (pros and cons), and a recommended decision with accompanying rationale.\nEach proposal is then peer reviewed by another team member.\nFor complex proposals that require more discussion, we involve more members of the team as necessary to form a joint opinion.\nWe then publish our voting rationale externally on our public forum.\n\nWe always try to base our votes on sound, defensible rationale so that we are internally consistent and our voting track record stands up to external critique.\nEcosystem Growth and Expansion to Institutions\nLeveraging the Areta network to promote and foster flourishing ecosystems across DAOs. Bringing unprecedented ties to a deep traditional network of corporates, strategics, and investors.\nGovernance Optimisation\nUtilising our expertise to diagnose, analyse, correct, and enhance the effectiveness of DAO governance, ensuring streamlined operations and decision-making, while building up accountability structures.\nExisting Integration with the Aave Ecosystem\nAreta’s lead delegate, Sid Shah, has been an active participant in Aave governance over the last 2.5 years, leading LBS Blockchain Society’s delegation on Aave and also serving as Co-President of the Society. During Sid’s time in leading LBS’ delegation on Aave, he:\n\nEstablished the LBS Blockchain Society delegate platform as the most viewed platform on Aave.\nMaintained a very high voting participation rate, leading to their inclusion as the inaugural recipients of the Orbit program in 2023;\nAdded value to the DAO by co-authoring two governance proposals (for the gas rebate and private Snapshot trial); and\nFormed close relationships with stakeholders across the DAO.\n\nAs LBS Blockchain Society’s delegation terminated in February 2024 due to their delegators, Avara, deciding to stop delegating across the board to promote further decentralisation of the Aave DAO, Sid will now take on the mantle of Aave governance participation under the Areta umbrella in a decision that was welcomed by the community.\nConclusion\nAs delegates, we commit to dedicating our time and resources to help accelerate Aave’s development and growth. We will leverage our global network, business knowledge, and entrepreneurial mindset, to drive value for Aave token holders, and in doing so, seek to have a profound impact on the way the world does business within Web3.\nConflicts of Interest\nAreta currently does not have any material conflicts of interest. We do not hold any other cryptocurrencies. We agree to keep the Aave community updated should any conflicts of interest arise.\nWaiver of Liability\nBy delegating to Areta, you acknowledge and agree that Areta will participate on a best efforts basis and will not be liable for any form of damages related to participation in the Aave Protocol or this DAO.\n\n Governance Weekly Recap [2024]\n\n [ARFC] Orbit Program Renewal\n\n [Temp Check] Enabling decentralisation through Distribute voting weight\n\n 579\n\n read \n\n 108\n min\n\n post by sid_areta on Feb 29, 2024\n\n post by sid_areta on Feb 29, 2024\n\n post by sid_areta on Mar 3, 2024\n\n post by sid_areta on Mar 3, 2024\n\n post by sid_areta on Mar 3, 2024\n\n post by sid_areta on Mar 3, 2024\n\n post by sid_areta on Mar 5, 2024\n\n post by sid_areta on Mar 5, 2024\n\n post by sid_areta on Mar 5, 2024\n\n post by sid_areta on Mar 5, 2024\n\n post by sid_areta on Mar 8, 2024\n\n post by sid_areta on Mar 8, 2024\n\n post by sid_areta on Mar 8, 2024\n\n post by sid_areta on Mar 8, 2024\n\n post by sid_areta on Mar 8, 2024\n\n post by sid_areta on Mar 8, 2024\n\n post by sid_areta on Mar 11, 2024\n\n post by sid_areta on Mar 13, 2024\n\n post by sid_areta on Mar 13, 2024\n\n Load more posts below","tokens":1849,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265946283,"hash":"4cfed17b4cb56f1f1bf475331026448db0a76182"}
{"url":"https://dev-forum.pyth.network/t/custom-error-0x6ce2251a/54/1","domain":"dev-forum.pyth.network","title":"Custom error 0x6ce2251a - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Custom error 0x6ce2251a \n\n Price Feeds\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n Apr 2025\n\n 1 / 9\n\n Apr 2025\n\n Apr 2025\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n Just a simple price feed function following the docs to retrieve price of ETH to USD, however it reverted with this error: 0x6ce2251a\nimage772×490 39.9 KB\nHere is my script for interacting and the priceUpdate array is retrieve from Hermes, I think the array is correct because the parsed data is there.\n// SPDX-License-Identifier: MIT\npragma solidity 0.8.28;\n\nimport {Script, console} from \"forge-std/Script.sol\";\nimport {PythPriceFeed} from \"src/PythPriceFeed.sol\";\nimport {Vm} from \"forge-std/Vm.sol\";\nimport {PythStructs} from \"@pythnetwork/pyth-sdk-solidity/PythStructs.sol\";\n\ncontract GetETHUSDPrice is Script {\n PythPriceFeed pythPriceFeed;\n\n function run() external {\n address pythContract = Vm(address(vm)).getDeployment(\n \"PythPriceFeed\",\n uint64(block.chainid)\n );\n\n pythPriceFeed = PythPriceFeed(payable(pythContract));\n bytes[] memory priceUpdate = new bytes[](1);\n priceUpdate[\n 0\n ] = \"0x...\";\n\n vm.startBroadcast();\n PythStructs.Price memory price = pythPriceFeed.getEThUSDPrice(\n priceUpdate\n );\n vm.stopBroadcast();\n console.log(\"ETH/USD Price: \", price.price);\n }\n}\n\nI have also funded a few eth to my contract on Chain Sepolia: PythPriceFeed | Address 0x2127c26e297ae9782f41d99049ffc1051a157c9e | Etherscan\nHere are the full logs:\n0x2127C26e297aE9782f41D99049fFc1051A157C9E::getEThUSDPrice([0x..])\n │ ├─ [9168] ERC1967Proxy::fallback([0x...]) [staticcall]\n │ │ ├─ [3755] PythUpgradable::getUpdateFee([0x...]) [delegatecall]\n │ │ │ └─ ← [Return] 1\n │ │ └─ ← [Return] 1\n │ ├─ [14566] ERC1967Proxy::fallback{value: 1}([0x..])\n │ │ ├─ [13652] PythUpgradable::updatePriceFeeds{value: 1}([0x..]) [delegatecall]\n │ │ │ ├─ [6255] 0x41c9e39574F40Ad34c79f1C99B66A45eFB830d4c::parseAndVerifyVM(0x..) [staticcall]\n │ │ │ │ ├─ [854] 0x8D254a21b3C86D32F7179855531CE99164721933::parseAndVerifyVM(0x..) [delegatecall]\n │ │ │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ │ └─ ← [Revert] custom error 0x6ce2251a\n │ └─ ← [Revert] custom error 0x6ce2251a\n └─ ← [Revert] custom error 0x6ce2251a\n\n 5\n\n 4\n\n post by Aditya520 on Apr 15, 2025\n\n Aditya520\n\n Hey @LuoYingjie\nCongratulations on your first post. Thank you for sharing the code and the logs.\nI see you are generating the parsed data here.\n priceUpdate[\n 0\n ] = \"0x...\";\n\nPlease use the data from hermes using the methods listed in How to Fetch Price Updates\nWhen anyone passes price updates, the contract checks it for the verification as shown in the full logs.\n │ │ │ ├─ [6255] 0x41c9e39574F40Ad34c79f1C99B66A45eFB830d4c::parseAndVerifyVM(0x..) [staticcall]\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n YES, I’m taking the data from the docs with this command below:\ncurl -X 'GET' 'https://hermes.pyth.network/v2/updates/price/latest?ids%5B%5D=0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace'\n\nHowever, it still reverts..\nThe data looks like this:\nimage975×773 46.8 KB\n0x504e41550100000003b80100000004....\n\nBut, not working.\n\n post by Aditya520 on Apr 15, 2025\n\n Aditya520\n\n The data looks correct, but can you run your script with your data here.\n priceUpdate[\n 0\n ] = \"0x...\";\n\nJust making sure that you are inserting data here before proceeding ahead.\n\n post by LuoYingjie on Apr 15, 2025\n\n LuoYingjie\n\n That’s exactly what I do, I have inserted data there but not working.\nimage2553×1195 337 KB\n\n post by Aditya520 on Apr 16, 2025\n\n Aditya520\n\n Can you share your contract and the script in a gist? I will run it locally and get back to you.\n\n post by LuoYingjie on Apr 16, 2025\n\n LuoYingjie\n\n Surely yes, here is the link:\n\nOnly one contract there and the script is: GetETHUSDPrice.s.sol\nYou can get the priceUpdate by running\nmake get-price-update\n\nAnd the for getting the price feed you need to first deploy the contract and send a bit eth to the contract, then run\nmake get-eth-usd-price\n\nYou could also run the script in your preferred way. Thanks a lot for checking this!\n\n post by Aditya520 on Apr 17, 2025\n\n Aditya520\n\n Have you deployed the contract on any testnet and tried interacting with it?\nIt looks like forge scripts somehow creates a fork in the backend for these operations and create a transaction object for you to send it.\nRefer to this post.\n\n post by LuoYingjie on Apr 17, 2025\n\n LuoYingjie\n\n Ohhhhh god it worked!\nI just deployed a new one and the transaction succeed!\n\nThanks a lot bro for checking!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Cant get update fee\n\n Price Feeds\n\n 8\n\n 881\n\n Jul 2025\n\n Smart contract reverts when sending Pyth price updates via HermesClient from my frontend\n\n Price Feeds\n\n 10\n\n 774\n\n May 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 643\n\n Jul 2025\n\n We occasionally encounter an error when generating the payload using this function update_price_feeds_with_funder\n\n Price Feeds\n\n 2\n\n 642\n\n May 2025\n\n Can’t Update Price Via Vscode\n\n Price Feeds\n\n 10\n\n 720\n\n Apr 2025\n\n Powered by Discourse","tokens":2181,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791265956464,"hash":"dc6b1cd82c0d840d7b2b518d36ec7eeaa4505903"}
{"url":"https://docs.base.org/build-on-base/issue-rwa/create-an-asset-token","domain":"docs.base.org","title":"Create an Asset Token - Base Documentation","text":"Use the B20 Asset variant to represent a class of tokenized shares with configurable precision, issuer roles, supply controls, and metadata. This example creates Example Corp Class A (EXM) with six decimals.\nReal-world asset (RWA) tokenization is one of many use cases for the B20 Asset standard. The examples on this page use a stock token for illustration; the same flows apply to other asset types.Tokenized securities examples shown for illustration. Base is a general-purpose blockchain; issuance and compliance are the responsibility of the issuer under applicable law.\n​Demo\n1Create2Controls3IdentifyVibenet account1Create EXMIn progress2Apply controlsPending3Add identifierPendingCreate EXMDefine Example Corp Class A with six-decimal share precision.OperationCreate tokenSymbolEXMStandardB20 AssetNetworkBase VibenetTransaction event log--:--:--[PENDING]Create EXM--:--:--[PENDING]Apply controls--:--:--[PENDING]Add identifierB20 supplies a shared Asset standard instead of a custom token contract.Real Vibenet transactions\nThe demo uses a local browser-generated account to submit real transactions on Base Vibenet. If Vibenet or its B20 features are unavailable, it automatically switches to an illustrative offline version.\nNew to B20? See the B20 Token Standard for the concepts and a full launch walkthrough. These samples target base-std@1505323, viem@2.55.11, and Base Foundry v1.1.1.\n​Create and Verify the Stock Token\nChoose the Asset variant when you need configurable decimals, announcements, a scheduled UI multiplier, extra metadata, or batchMint. Asset decimals must be in the range [6, 18]; values outside that range revert InvalidDecimals. The type is sealed into the token address at creation and cannot change.\nimport { encodeAbiParameters, encodeFunctionData, keccak256, parseAbiParameters, parseEventLogs, stringToBytes } from \"viem\";\nimport { account } from \"../../shared/clients.js\";\nimport { B20_FACTORY, b20Abi, factoryAbi, role } from \"../abi.js\";\nimport { sendContract } from \"../write.js\";\n\nexport async function createStockToken() {\n const salt = keccak256(stringToBytes(\"example-class-a-v1\"));\n const params = encodeAbiParameters(\n parseAbiParameters(\"(uint8 version,string name,string symbol,address initialAdmin,uint8 decimals)\"),\n [{ version: 1, name: \"Example Corp Class A\", symbol: \"EXM\", initialAdmin: account.address, decimals: 6 }],\n );\n const initCalls = [\"MINT_ROLE\", \"BURN_BLOCKED_ROLE\", \"PAUSE_ROLE\", \"UNPAUSE_ROLE\", \"OPERATOR_ROLE\"].map(\n (name) => encodeFunctionData({ abi: b20Abi, functionName: \"grantRole\", args: [role(name), account.address] }),\n );\n const receipt = await sendContract({ address: B20_FACTORY, abi: factoryAbi, functionName: \"createB20\", args: [0, salt, params, initCalls] });\n const [created] = parseEventLogs({ abi: factoryAbi, logs: receipt.logs, eventName: \"B20Created\" });\n return created.args.token;\n}\n function createStock(address admin) public returns (address token) {\n B20FactoryLib.B20AssetRoleHolders memory holders = B20FactoryLib.B20AssetRoleHolders({\n minter: admin,\n burner: admin,\n burnBlocker: admin,\n pauser: admin,\n unpauser: admin,\n metadataAdmin: admin,\n operator: admin\n });\n bytes[] memory settings = new bytes[](1);\n settings[0] = B20FactoryLib.encodeUpdateSupplyCap(1_000_000e6);\n token = StdPrecompiles.B20_FACTORY.createB20(\n IB20Factory.B20Variant.ASSET,\n keccak256(\"example-class-a-v1\"),\n B20FactoryLib.encodeAssetCreateParams(\"Example Corp Class A\", \"EXM\", admin, 6),\n B20FactoryLib.concat(B20FactoryLib.buildRoleGrants(holders), settings)\n );\n }\n\nThe factory assigns a deterministic address from (variant, sender, salt). Address byte [10] is 0x00 for Asset tokens. Reusing the same (variant, sender, salt) triple reverts TokenAlreadyExists. Optional initCalls, such as the role grants above, run on the new token in the same transaction. The factory drops access after createB20 returns.\nSee the B20 token standard for the complete interface, roles, and policies.\nThe factory emits B20Created for the Asset variant and returns the deterministic token address.\nThe supply cap is a technical ceiling, not a representation of authorized or outstanding shares.\n​See Also\nWas this page helpful?Suggest editsRaise issue","tokens":1054,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265970494,"hash":"237bb1729d43bf20977a60119614aa1792e451e5"}
{"url":"https://governance.aave.com/t/tokenlogic-delegate-platform/12516/41","domain":"governance.aave.com","title":"TokenLogic Delegate Platform - Delegate Platforms - Aave","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 120\n min\n\n Mar 2023\n\n 39 / 39\n\n Oct 4\n\n 1d ago\n\n Load more posts above\n\n post by TokenLogic on Mar 13, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic\n\n TokenLogic February Update\nDuring February 2025, we participated in 21 of 21 Aave Improvement Proposals (AIPs), and 19 of 19 Snapshot votes.\nSnapshot Votes\n[ARFC] Deploy Aave v3 on Sonic\nVote Cast: YAE\nWe support this deployment. Mantle is a vibrant ecosystem and has proposed strong liquidity commitments, making this deployment a valuable opportunity for Aave.\nsUSDe and USDe Price Feed Update\nVote Cast: NAE\nWe do not support this update. We generally oppose hardcoding oracles, and there is no demonstrated demand or urgent need that justifies this change.\n[ARFC] Supply and Borrow Cap Risk Oracle Activation\nVote Cast: YAE\nWe support this proposal, as we believe this update could streamline certain processes and contribute to reducing the protocol’s risk exposure.\n[ARFC] Adjust Risk Parameters for Aave V2 and V3 on Polygon\nVote Cast: YAE\nWe fully support this proposal.\n[ARFC] Deploy stataUSDC GSM on Base\nVote Cast: YAE\nWe support this deployment, as StataGSM will contribute to the growth of GHO on Base while helping to mitigate volatility caused by limited secondary market liquidity. Introducing the Stata version will enhance capital efficiency and support the expansion of the USDC market on Base.\n[ARFC] Prime Instance - Restore ETH LTV\nVote Cast: YAE\nWe support this proposal, as the introduction of Merit rewards will effectively eliminate the risk of recursive loops, removing the need to maintain ETH’s LTV at 0%.\n[ARFC] Proposal to Allocate AGD treasury to Aave DAO\nVote Cast: YAE\nWe support this proposal.\n[TEMP CHECK] Add bCSPX to Aave V3 Gnosis Instance\nVote Cast: YAE\nWe support this proposal. It is exciting to see new kind of RWA coming on chain and it is welcomed on Aave.\n[ARFC] Aave V2 Deprecation Update - Disable New Borrows, IR Curve and Reserve Factor Adjustments\nVote Cast: YAE\nWe support this proposal, as it represents a logical next step in the ongoing process of deprecating the Aave V2 instances.\n[TEMP CHECK] Deploy Aave v3 on Ink\nVote Cast: YAE\nWe fully support this deployment and are eager to see growth on Ink Chain while gaining access to Kraken’s user base through this initiative. We look forward to the confirmation of deposits and incentive commitments at the ARFC stage.\n[TEMP CHECK] Recognize HyperLend as a Friendly Fork\nVote Cast: YAE\nWe support this proposal, as it meets all the necessary criteria for HyperLend to be officially recognized as a friendly fork.\n[ARFC] Core & Base - BTC Correlated Asset Update\nVote Cast: YAE\nWe support this update, as it will foster the growth of BTC-correlated assets across both Mainnet and Base instances. Lombard has established itself as the leading BTC LST, and enabling its use alongside other BTC wrappers has proven to be a key driver of growth for BTC-related markets.\n[ARFC] Update AAVE LTV and Liquidation Threshold Percentages\nVote Cast: YAE\nWe support this proposal, as the analysis provided by risk teams highlights the strength of the AAVE token during market downturns and the good secondary liquidity. These factors make this conservative adjustment appropriate.\n[ARFC] Add sUSDE to Aave V3 Base Instance\nVote Cast: YAE\nWe support this onboarding, as sUSDe has proven to be a valuable asset for leverage strategies on both Core and Prime instances. When market conditions improve, sUSDe’s growth drives up stablecoin borrow rates across the board.\n[TEMP CHECK] Add support for Wrapped Origin Sonic (wOS) to Aave v3\nVote Cast: YAE\nWe support this onboarding, as it is expected to drive demand within the new Sonic markets. Origin Sonic, as the second-largest S LST, is well-positioned to generate meaningful borrowing demand for S.\n[ARFC] Onboard rsETH to Arbitrum and Base V3 Instances\nVote Cast: YAE\nWe support this onboarding, as rsETH has demonstrated strong growth on Core and Prime markets. We aim to replicate these successful strategies on Arbitrum and Base, where rsETH will benefit from access to low-cost wstETH debt through the ongoing incentives program.\n[TEMP CHECK] Deploy Aave on Soneium\nVote Cast: YAE\nWe support this deployment and look forward to seeing growth on Sony Block Solutions Labs’ L2. This initiative will position Aave as the core liquidity layer while leveraging Sony’s distribution channels to access a broader user base.\n[TEMP CHECK] Deploy Aave on megaETH\nVote Cast: YAE\nWe support this deployment and look forward to receiving further details from the megaETH team regarding their liquidity provisions and incentive commitments.\n[TEMP CHECK] GHO Gas Token Framework\nVote Cast: YAE\nWe support this framework as it is a very exciting new utility for GHO and should bring demand. Easing gas payment with stable rewards is a very elegant solution.\nAIP Votes\nCollector upgrade\nVote Cast: YAE\nWe supported this proposal. This update will introduce more flexibility for the Finance Stewards.\nGHO Base Launch\nVote Cast: YAE\nWe voted in favor of this launch and are very excited about GHO coming to Base. There are a lot of synergies to be explored for the stablecoin on that network and its growth will be backed by strong incentives.\nSunset stMATIC on Polygon instance\nVote Cast: YAE\nWe support this proposal as Lido is sunsetting its services for stMatic, it doesn’t make sense to keep supporting the asset in such a state.\nUpdate USDS & GHO Borrow Rate\nVote Cast: YAE\nWe fully support this update as it will align the prime market borrow rates with the new SSR and make GHO debt a better option there.\nAllow Balancer To Claim Mining Rewards\nVote Cast: YAE\nWe support this proposal and are very happy to see the synergies between Balancer v3 and Aave evolving.\nwstETH Borrow Rate Update\nVote Cast: YAE\nWe voted in favor of this proposal. Given the recent market downturn and the challenging price action of EIGEN, LRT/wstETH looping strategies on Prime have struggled to remain profitable. This adjustment, by lowering borrow rates, will help restore profitability for these loops.\nAave v3 Linea Activation\nVote Cast: YAE\nWe voted in favour of this deployment and are very keen to see Aave grow on Linea.\nFebruary Funding Update (Part 1)\nVote Cast: YAE\nWe voted in favor of this proposal, as this funding update will enable the distribution of Fluid rewards on Fluid, facilitate the migration of funds from V2 to V3, and support swaps and deposits aimed at improving the DAO’s overall capital efficiency.\nDecrease Slope1 Parameter for Stablecoins on Aave V3\nVote Cast: YAE\nWe voted in favor of this update, as broader market conditions have been trending downward. This adjustment will ensure that stablecoin debt remains competitive in response to the evolving market environment.\nRequest for Bounty Payout - Feb 2025\nVote Cast: YAE\nWe voted in favor of this proposal, as whitehat bounties are a critical component of the protocol’s security framework. It is only fair to reward those who actively contribute to making Aave safer. Congratulations to the whitehats for their valuable efforts in protecting the protocol.\na.DI Sonic path activation\nVote Cast: YAE\nWe voted in favor of this activation and are looking forward to see Aave grow on Sonic.\nstkBPT Incentives\nVote Cast: YAE\nWe voted in favor of this update, as the upcoming launch of Aavenomics makes this budget essential to facilitate the transition from stkBPT to new liquidity initiatives.\nPrime Instance - Restore ETH LTV\nVote Cast: YAE\nWe support this proposal, as the introduction of Merit rewards will effectively eliminate the risk of recursive loops, removing the need to maintain ETH’s LTV at 0%.\nUpgrade Aave instances to v3.3\nVote Cast: YAE\nWe support this proposal, the v3.3 will bring improvements for the liquidation engine and help better tracking bad debt.\nCaps Risk Oracle Activation on Arbitrum\nVote Cast: YAE\nWe support this proposal, as we believe this update could streamline certain processes and contribute to reducing the protocol’s risk exposure on the Arbitrum instance.\nAdjust Risk Parameters for Aave V2 and V3 on Polygon\nVote Cast: YAE\nWe support this proposal.\nUpdate AAVE Token LTV/Liquidation Percentages\nVote Cast: YAE\nWe support this proposal, as the analysis provided by risk teams highlights the strength of the AAVE token during market downturns and the good secondary liquidity. These factors make this conservative adjustment appropriate.\nsUSD Risk Parameter Adjustment\nVote Cast: YAE\nWe are in favor if this adjustment.\nAave V3.3 Sonic Activation\nVote Cast: YAE\nWe voted in favor of this deployment, as Sonic has proven to be a thriving ecosystem in recent months. We are excited to see Aave expand its presence within Sonic and contribute to its continued growth.\nExtend GHO Steward on Aave Prime Instance\nVote Cast: YAE\nWe are in favor of this update. As GHO continues to grow on the Prime instance, extending the role of GHO Stewards to this new environment will provide greater flexibility and support stronger growth in this market.\nFebruary Funding Update - Part B\nVote Cast: YAE\nWe are in favor of this funding update, which focuses primarily on bridging assets back to Ethereum mainnet and making deposits into Aave V3 to enhance capital efficiency. Additionally, this update will provide funding for the Merit and Ahab programs.\n\n 18 days later\n\n post by TokenLogic on Apr 1, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic March Update\nDuring March 2025, we participated in 19 of 19 Aave Improvement Proposals (AIPs), and 23 of 24 Snapshot votes.\nSnapshot Votes\n[ARFC] Onboard tBTC to Aave v3 on Arbitrum\nVote Cast: YAE\nWe support this onboarding. tBTC is one of the most resilient BTC wrapper on chain, its expansion on Arbitrum follow the DAO’s will to make Aave the liquidity hole of all BTC DeFi.\n[ARFC] Onboard rstETH to Aave V3 Prime Instance\nVote Cast: YAE\nWe support this onboarding. rstETH has been the biggest LRT of Symbiotic and Mellow and is greatly aligned with Lido making it a suitable LRT asset for the Prime Instance.\n[ARFC] BGD.Aave ClinicSteward\nVote Cast: YAE\nWe support this proposal, as it is a key step before the start of Umbrella. No bad debt left behind.\n[ARFC] Orbit Program Renewal - Q1 2025\nVote Cast: YAE\nWe support this proposal. The delegates involved in this program have played a pivotal role in advancing Aave’s development and decentralization. Collaborating with them has consistently been both productive and rewarding.\n[ARFC] Recognize HyperLend as a Friendly Fork\nVote Cast: YAE\nWe support this proposal, as it meets all the necessary criteria for HyperLend to be officially recognized as a friendly fork.\n[ARFC]. Aave <> Chainlink SVR v1. Phase 1 activation\nVote Cast: YAE\nWe support this proposal, as the introduction of SVR represents a critical step toward improving the DAO’s capital efficiency by enabling the partial recapture of value currently lost to MEV during liquidation events.\n[TEMP CHECK] Add wstUSR to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding. Resolv has been a great partner for GHO helping to grow the GHO/USR to become the biggest pool of both ecosystem. wstUSR will be a great asset to leverage when funding rates will pick up again.\n[TEMP CHECK] Add USR to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding. Resolv has been a great partner for GHO helping to grow the GHO/USR to become the biggest pool of both ecosystem.\n[TEMP CHECK] Add stS to Aave v3 Sonic Instance\nVote Cast: YAE\nWe support this onboarding, as stS is the biggest S LST on Sonic. It will drive big demand for S borrowing for users to leverage the yield of the LST.\n[TEMP CHECK] Onboard scETH, scUSD, and scBTC to Aave V3 Sonic Instance\nVote Cast: YAE\nWe fully support this onboarding, as Rings assets are the cornerstone of DeFi on Sonic, they are ones of the most interesting assets to farm the upcoming Sonic Airdrop.\n[TEMP CHECK] GHO Aave Savings Upgrade\nVote Cast: YAE\nWe fully support this proposal, as sGHO and the ASR represent the next pivotal milestones in GHO’s growth trajectory. With the stkGHO program concluding alongside the Umbrella initiative, sGHO is set to become the cornerstone yield mechanism within the GHO ecosystem.\n[ARFC] Enhancements in Aave v3 Gnosis Chain Instance\nVote Cast: YAE\nWe support this update, as it will foster the growth of the Gnosis instance allowing for more capital efficiency.\n[TEMP CHECK] Deploy Aave v3 on Plasma\nVote Cast: YAE\nWe support this deployment, as we think Plasma will be a huge source of liquidity for USDT and stablecoin. We will be waiting for more details at the ARFC stage.\n[ARFC-ADDENDUM] Aave DAO & Chainlink Smart Value Recapture (SVR)\nVote Cast: YAE\nWe support this proposal.\n[ARFC] Risk Steward Parameter Updates Phase 3\nVote Cast: YAE\nWe support this onboarding, as it is expected to enhance the efficiency of risk parameter management and reduce governance overhead.\n[ARFC] Aavenomics implementation: Part one\nVote Cast: YAE\nWe support this proposal, as it is the next big step forward regarding Aave’s economic future, every point of this proposal is exciting and TokenLogic will play an important role in delivering this important update.\n[ARFC] Launch GHO on Sonic & set ACI as Emissions Manager for Rewards\nVote Cast: YAE\nWe support this deployment Sonic has been the most interesting chain for DeFI in Q1 and we expect it to last for the next quarter as well and want GHO to be involved in this new ecosystem.\n[TEMP CHECK] Onboard lisUSD to Aave V3 BNB Instance\nVote Cast: YAE\nWe support this onboarding.\n[ARFC] wstETH and weETH E-Modes and LT/LTV Adjustments on Ethereum, Arbitrum, Base\nVote Cast: None\nWe chose not to vote for this proposal due to the presence of multiple overlapping proposals on the same topic. We intend to vote on the consolidated version that brings all relevant points together for a more comprehensive assessment.\n[ARFC] Aave Finance Steward Modules Deployment\nVote Cast: YAE\nWe support this proposal, as it is a very important step forward to enhance the safety of the financial actions taken by the DAO every month. Furthermore, it is a necessary Steward to implement the actions from the Aavenomics part 1.\n[ARFC] GHO Gas Token Framework\nVote Cast: YAE\nWe support this framework as it is a very exciting new utility for GHO and should bring demand. Easing gas payment with stable rewards is a very elegant solution.\n[ARFC] Launch GHO on Gnosis Chain\nVote Cast: YAE\nWe support this deployment on Gnosis chain and expect some demand on Gnosis for GHO.\n[TEMP CHECK] Proposal to Rename GHO to USDA for Enhanced Clarity and Adoption\nVote Cast: NAE\nWe don’t support this rename as GHO has been a very strong brand in the ecosystem.\n[TEMP CHECK] Aave Decentralized Acqui-Hire Framework\nVote Cast: NAE\nWe don’t support this proposal.\nAIP Votes\nAdjust Aave Polygon V3 Risk Parameters\nVote Cast: YAE\nWe supported this proposal.\nAave V2 Deprecation Update\nVote Cast: YAE\nWe voted in favor of this update as we want to see migration from Aave v2 to V3.\nsUSDe and USDe Price Feed Update\nVote Cast: YAE\nWe support this proposal as the extensive analysis from risk providers point out that it should be the solution with the “best” tradeoffs.\nwrsETH Base Onboarding\nVote Cast: YAE\nWe fully support this onboarding, wrsETH is one of the leading LRTs and its expansion to Base will let it access brand new liquidity and market with an optimized liquid eMode with wstETH.\nCore & Base - BTC Correlated Asset Update\nVote Cast: YAE\nWe support this update, as it will foster the growth of BTC-correlated assets across both Mainnet and Base instances. Lombard has established itself as the leading BTC LST, and enabling its use alongside other BTC wrappers has proven to be a key driver of growth for BTC-related markets.\nAdd EURC to BASE Aave V3\nVote Cast: YAE\nWe voted in favor of this onboarding. EURC is the best stablecoin correlated to Euro, this onboarding will allow for a better accessibility to Euro liquidity on chain and reach for new Aave European users.\nAUSD on V3 Avalanche\nVote Cast: YAE\nWe voted in favour of this onboarding as AUSD is the most interesting native stablecoin on Avalanche and it will drive more demand through the whole Instance.\nGSMs Migration to stataGSM4626\nVote Cast: YAE\nWe voted in favor of this proposal, this is a very important update for the capital efficiency of GHO.\nRecreate wrstETH eMode on Base\nVote Cast: YAE\nWe voted in favor of this update.\nAave V3.3 Celo Activation\nVote Cast: YAE\nWe voted in favor of this proposal, we are very keen to see Aave launch on Celo to get access to a completely different type of users and help the chain grow.\nClinic steward activation\nVote Cast: YAE\nWe support this proposal, as it is a key step before the start of Umbrella. No bad debt left behind.\nStablecoins Interest Rate Curve Update\nVote Cast: YAE\nWe voted in favor of this update, as market activity has significantly slowed down. Adjusting the interest rate curves for all stablecoins across Aave instances to support higher utilization in this context is a sensible and timely decision.\nGov v3 VotingMachine / VotingPortal maintenance\nVote Cast: YAE\nWe support this proposal, as it is a needed little update to ease the governance process.\nGov v3 VotingMachine / VotingPortal maintenance\nVote Cast: YAE\nWe support this proposal same as 272.\nEnable SVR V1 on Aave V3 Ethereum\nVote Cast: YAE\nWe support this proposal, as the introduction of SVR represents a critical step toward improving the DAO’s capital efficiency by enabling the partial recapture of value currently lost to MEV during liquidation events.\nFinance Steward Deployment: Pool Exposure Module\nVote Cast: YAE\nWe support this proposal, as it is a very important step forward to enhance the safety of the financial actions taken by the DAO every month. Furthermore, it is a necessary Steward to implement the actions from the Aavenomics part 1.\nAllow Balancer DAO to Claim Liquidity Mining Rewards (Arbitrum & Base)\nVote Cast: YAE\nWe support this proposal and are very happy to see the synergies between Balancer v3 and Aave evolving. Enabling Balancer to claim LM rewards will allow for even more capital efficiency for LPs on Balancer v3.\nOnboard rsETH to Arbitrum\nVote Cast: YAE\nWe fully support this onboarding, rsETH is one of the leading LRTs and its expansion to Arbitrum will let it access brand new liquidity and market with an optimized liquid eMode with wstETH.\nOnboard eBTC and Add eBTC/WBTC E-Mode\nVote Cast: YAE\nWe voted in favor of this onboarding as it will allow for more competition on the BTC landscape on Aave. Etherfi has been a great partner eversince the first weETH deployment and the onboarding of their BTC asset marks a new important step in the collaboration between them Aave.\n\n 1 month later\n\n post by TokenLogic on May 16, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic April Update\nDuring April 2025, we participated in 18 of 18 Aave Improvement Proposals (AIPs), and 19 of 21 Snapshot votes.\nSnapshot Votes\n[TEMP CHECK] Onboard USDtb to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding. USDtb is great product and the start of the RWA onboarding onto Aave, they have grown exponentially with more than 1.4B TVL.\n[ARFC] Add AAVE token to Aave V3 Base Instance\nVote Cast: YAE\nWe support this onboarding. Base is becoming an increasingly important instance for the Protocol and adding AAVE to it following the risk team comments seems like the natural next step.\n[ARFC] Aave v3.4 candidate\nVote Cast: YAE\nWe support this proposal, Aave 3.4 is an important step ahead of the launch of the v4.\n[ARFC] Onboard Pendle PT tokens to Aave V3 Core Instance\nVote Cast: YAE\nWe support this proposal. The onboarding of PT will help getting traction in any kind of market. We are very keen to see this go live.\n[TEMP CHECK] Onboard eUSDe to Aave v3 Core Instance\nVote Cast: YAE\nWe support this proposal, ahead of the launch of PT tokens, it is important to onboard eUSDe as it will be one of the most dominant asset for PTs.\n[TEMP CHECK] Onboard eUSDe PT Tokens to Aave v3 Core Instance\nVote Cast: YAE\nWe support this proposal, the first PT on Aave will drive significant demand and we are very keen to see this new kind of asset go live on Core Instance.\n[TEMP CHECK] onboard frxUSD and sfrxUSD to Aave v3 on Sonic Instance\nVote Cast: YAE\nWe support this onboarding. FRAX has always been an important player in the stablecoin space and we are looking forward to see them grow on the Sonic Instance.\n[ARFC] Renew LlamaRisk as Risk Service Provider - epoch 3\nVote Cast: YAE\nWe support this renewal. Llamarisk have been a great team to work with, the quality of their security work speaks for themselves and are very looking forward to continue working with them for this next term.\n[ARFC] Add stS to Aave v3 Sonic Instance\nVote Cast: YAE\nWe support this onboarding, as stS is the biggest S LST on Sonic. It will drive big demand for S borrowing for users to leverage the yield of the LST.\n[ARFC] stkABPT - Emissions Update\nVote Cast: YAE\nAs AAVE prepares to shift its primary liquidity base, reducing stkABPT emissions marks a critical first step in the transition.\n[ARFC] Aave Liquidity Committee Funding Phase VI\nVote Cast: YAE\nAfter a strong Phase V marked by steady growth for GHO, the upcoming phase is poised to elevate the protocol further, with several promising opportunities in the pipeline.\n[ARFC] GHO Savings Upgrade\nVote Cast: YAE\nWe support this upgrade. The sGHO is set to become the most important GHO supply sink and will also bring new sustainable growth to the stablecoin.\n[ARFC] LRT and wstETH Unification\nVote Cast: YAE\nWe support this proposal as it represents a significant update concerning ETH-correlated assets and the strategic role of the Prime instance within the broader protocol. This unification fosters greater balance, unlocks new growth opportunities, and creates valuable synergies in an increasingly competitive market.\n[TEMP CHECK] Onboard tETH to Aave v3 Prime Instance\nVote Cast: YAE\nWe support this onboarding, tETH is very well Lido aligned and will be create decent demand and growth on the Prime Instance.\n[TEMP CHECK] Horizon’s RWA Instance\nVote Cast: YAE\nWe support this new development and are very keen for the next chapter of RWAs on Aave.\n[ARFC] Aave DAO <> BGD Labs. Phase 5\nVote Cast: MISSED\nAlthough we missed this vote, we fully support the renewal. BGD Labs consistently delivers outstanding work, and collaborating with their team has always been a pleasure. Their past contributions have been instrumental to Aave’s growth and development, and we look forward to continuing this strong partnership in the upcoming term.\n[ARFC] ACI Phase IV – “Road to 80”\nVote Cast: YAE\nWe strongly support this proposal. Collaborating with ACI has always been a pleasure, the quality and consistency of their work are exceptional. The results speak for themselves, particularly in terms of growth, and we’re excited to continue working with them in the upcoming term.\n[ARFC] Onboard USDtb to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding. USDtb is great product and the start of the RWA onboarding onto Aave, they have grown exponentially with more than 1.4B TVL.\n[TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility\nVote Cast: YAE\nWe support this proposal, this is an exciting parternship that will be pushing the DeFI boundaries even further.\n[ARFC] Onboard eUSDe to Aave v3 Core Instance\nVote Cast: YAE\nWe support this proposal, ahead of the launch of PT tokens, it is important to onboard eUSDe as it will be one of the most dominant asset for PTs.\n[TEMP CHECK] Deploy Aave v3 on Tron\nVote Cast: YAE\nWe missed this vote but we support this deployment.\nAIP Votes\nAAVE Buybacks allocation\nVote Cast: YAE\nWe supported this proposal and are very keen to see the start of this buyback program. This will bring value back to Aave holders.\nOrbit Program Renewal\nVote Cast: YAE\nWe voted in favor of this renewal, as the main delegates funded by the Orbit program have proven to be highly engaged and collaborative participants in Aave’s governance. This initiative is a valuable step toward further decentralizing the DAO and strengthening its decision-making process.\nRisk Steward Parameter Updates Phase 3\nVote Cast: YAE\nWe support this proposal as it will offer more flexibility to the risk stewards, enabling them to react promptly to market changes in real time.\nEnhancements in Aave v3 Gnosis Chain Instance\nVote Cast: YAE\nWe fully support this upgrade as it will make the Gnosis instance more capital efficient and focus on the markets specific to this instance.\nRequest for Bounty Payout - March 2025\nVote Cast: YAE\nWe support this proposal, the Immunefi bug bounty is a great tool to get feedbacks and security check from the community about the protocol.\nRemoval of legacy VotingPortals from Governance v3\nVote Cast: YAE\nWe support this proposal.\nCaps Risk Oracle Activation on Base, Avalanche\nVote Cast: YAE\nWe voted in favour of this activation and are keen to see it at work on both Base and Avalanche networks.\nApril Funding update\nVote Cast: YAE\nWe voted in favor of this proposal, this funding update focuses the consolidation of revenue on mainnet instances, on the funding of different initiatives and the future Sonic campaign.\nMantle a.DI path activation\nVote Cast: YAE\nWe voted in favor of this activation and are really looking forward to see the synergies between Aave and the Mantle ecosystem.\nAdd rlUSD to Core Instance\nVote Cast: YAE\nWe voted in favor of this onboarding, we are very keen to see RLUSD a new institutional grade stablecoin hit the Aave market.\nAave Liquidity Committee Funding Phase VI\nVote Cast: YAE\nAfter a strong Phase V marked by steady growth for GHO, the upcoming phase is poised to elevate the protocol further, with several promising opportunities in the pipeline.\nRenew LlamaRisk as Risk Service Provider - epoch 3\nVote Cast: YAE\nWe support this renewal. Llamarisk have been a great team to work with, the quality of their security work speaks for themselves and are very looking forward to continue working with them for this next term.\nLower stkABPT Emissions\nVote Cast: YAE\nAs AAVE prepares to shift its primary liquidity base, reducing stkABPT emissions marks a critical first step in the transition.\nOnboard PT sUSDe July and PT eUSDe May on Core Instance\nVote Cast: YAE\nWe support this proposal and are looking forward to see the PT market grow on Aave.\nAdd stS to Aave v3 Sonic Instance\nVote Cast: YAE\nWe support this onboarding, as the main S LST, Beets and stS are set to become the biggest consumer of wS debt on Aave. This is a great prospect for utility on the Sonic Instance.\nACI Phase IV – “Road to 80”\nVote Cast: YAE\nWe strongly support this proposal. Collaborating with ACI has always been a pleasure, the quality and consistency of their work are exceptional. The results speak for themselves, particularly in terms of growth, and we’re excited to continue working with them in the upcoming term.\nAave BGD Phase 5\nVote Cast: YAE\nWe fully support the renewal. BGD Labs consistently delivers outstanding work, and collaborating with their team has always been a pleasure. Their past contributions have been instrumental to Aave’s growth and development, and we look forward to continuing this strong partnership in the upcoming term.\nOnboard PT sUSDe July on Core Instance\nVote Cast: YAE\nWe fully support this onboarding, this PT should drive significant demand to the overall market.\n\n 25 days later\n\n post by TokenLogic on Jun 10, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic May Update\nDuring May 2025, we participated in 18 of 18 Aave Improvement Proposals (AIPs), and 15 of 15 Snapshot votes.\nSnapshot Votes\n[ARFC] Aave V3 Deployment on Aptos Mainnet\nVote Cast: YAE\nWe support this deployment. We are keen to see the first non EVM Aave deployment coming to market soon.\n[ARFC] Horizon’s RWA Instance\nVote Cast: YAE\nWe support this new development and are very keen for the next chapter of RWAs on Aave. These new terms are much better for the DAO.\n[ARFC] Interest Rate Curve Risk Oracle\nVote Cast: YAE\nWe support this proposal, Chaos Labs is doing a great job with its Oracle.\n[ARFC] Onboard tETH to Aave v3 Prime Instance\nVote Cast: YAE\nWe support this onboarding. tETH on the prime instance makes total sense because of its alignment with Lido. On this instance it will have access to deep liquidity allowing users to leverage tETH as they want.\n[TEMP CHECK] Add PEPE as a Supported Asset on AAVE\nVote Cast: NAY\nMeme coins are more trading vehicles than collateral. Revenue upside is expected to be limited and the perception is Meme coins will be perceived to add increase the risk profile of the market. PTs were only recently just added and we are gradually more exposure to this derivative. Now is not the best time to add a Meme coin that could be perceived as increasing the risk profile of the overall market.\n[ARFC] Deploy Aave on Soneium\nVote Cast: YAE\nBased upon new found alignment, we are happy to support.\n[ARFC] Onboarding wETH to Aave V3 Celo Instance\nVote Cast: YAE\nWe support this onboarding. WETH listing will be necessary to bootstrap the borrowing activity on the Celo instance. It will also mark the start of the incentive campaign.\nTitle: [ARFC] Deploy 5M USDC for GHO Market Making on Gnosis Chain\nVote Cast: NAY\nWe don’t support this proposal yet. We think allocating this budget for GHO growth on Gnosis chain is a bit premature. There are a lot of costly initiatives at the moment such as the Base incentive campaign and the CEX growth budget. Therefore, we think it should be wiser to wait a bit for the proposal to mature given the big amount asked.\n[ARFC] Base Incentive Campaign Funding\nVote Cast: YAE\nWe support this incentive campaign as we are the writers of this proposal. This will make Aave the leader in marketshare on Base.\n[ARFC] Supply and Borrow Cap Risk Oracle Constraint Specification\nVote Cast: YAE\nWith the success of the Supply and Borrow cap risk oracle on Prime instance, it is natural to see Chaos Oracle come to Avalanche, Base and Arbitrum instances.\n[TEMP CHECK] Aave Events & Sponsorship Budget 2025\nVote Cast: YAE\nWe support this proposal, it is that time of the year again. These events are great tools to help enrich the Aave brand and ecosystem.\n[TEMP-CHECK] Onboard wstLINK to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding. This will make Aave the first lending platform to offer LINK LST leverage trade.\n[ARFC] Aave Umbrella activation\nVote Cast: YAE\nWe support this proposal as it represents a significant update for Aave, making the protocol safer everyday. Umbrella introduces a new kind of risk mitigation which strengthen the whole ecosystem.\n[TEMP CHECK] Adopt The SEAL Safe Harbor Agreement\nVote Cast: YAE\nWe support this adoption, the SEAL Whitehat Safe Harbor Agreement improves the security of the on-chain assets by allowing whitehats to intervene during active exploits to save protocol funds.\n[ARFC] Aave Events & Sponsorship Budget 2025\nVote Cast: YAE\nWe support this proposal, it is that time of the year again. These events are great tools to help enrich the Aave brand and ecosystem.\nAIP Votes\nMay Funding Update\nVote Cast: YAE\nWe supported this proposal as this funding update will allow for buybacks to continue as well as consolidation funds from the collector.\nOnboard USDtb to Aave v3 Core Instance\nVote Cast: YAE\nWe voted in favor of this onboarding, USDtb is the latest product of Ethena and will be a great feat into Aave’s suite of stablecoin and RWAs suite on the Core instance.\nRemove USDe Debt Ceiling and Introduce USDe Stablecoins E-mode\nVote Cast: YAE\nWe support this proposal as there is significant demand for it on the Core instance.\nstkGHO Emissions\nVote Cast: YAE\nWe fully support this proposal which will fund the stkGHO rewards until the Umbrella update.\nExtend SVR V1 to more reserves\nVote Cast: YAE\nWe support this proposal, extending SVR to more reserves will help the DAO get more revenue from liquidation.\nAdd AAVE token to Aave V3 Base Instance\nVote Cast: YAE\nWe support this proposal, Aave protocol is expanding in a strong fashion on the Base instance and having the AAVE token listed will help gain momentum and offer more opportunities to the holders.\nLRT and wstETH Unification\nVote Cast: YAE\nWe voted in favour of this proposal as it will move all the ETH corralated markets in the right direction, aiming for the best efficiency while not getting any tradeoffs on security.\nSoneium aDI path activation\nVote Cast: YAE\nWe voted in favor of this deployment, and the aDI path activation is the first necessary step for it.\nConfiguration maintenance\nVote Cast: YAE\nWe voted in favor of this proposal.\nOnboard eUSDe and eUSDe based PT token to Aave V3 Core\nVote Cast: YAE\nWe voted in favor of this onboarding, we are very keen to see PT growth through the onboarding of eUSDe. It has seen great demand on Pendle and are looking forward to make Aave the biggest supply sink for eUSDe.\nstkAAVE Emissions\nVote Cast: YAE\nWe support the continuation of AAVE incentive for stkAAVE ahead of the Umbrella upgrade.\nRenew LlamaRisk as Risk Service Provider - epoch 3\nVote Cast: YAE\nWe support this renewal. Llamarisk have been a great team to work with, the quality of their security work speaks for themselves and are very looking forward to continue working with them for this next term.\nCAPO Adapter Maintenance Update\nVote Cast: YAE\nWe support this update.\nOnboarding wETH to Aave V3 Celo Instance\nVote Cast: YAE\nWe support this onboarding. WETH listing will be necessary to bootstrap the borrowing activity on the Celo instance. It will also mark the start of the incentive campaign.\nAdd FBTC to Aave v3 Main Market on Ethereum\nVote Cast: YAE\nWe support this onboarding, fBTC will be a great addition into the diversity of BTC wrappers available on the Core market. This should drive some demand for WBTC borrows.\nAave V3.3 Soneium Activation\nVote Cast: YAE\nWe support this proposal and are really keen to see Aave expand to a new exciting network.\nAave Umbrella Activation\nVote Cast: YAE\nWe support this proposal as it represents a significant update for Aave, making the protocol safer everyday. Umbrella introduces a new kind of risk mitigation which strenghten the whole ecosystem.\nMay Funding Part B\nVote Cast: YAE\nWe fully support this funding update.\n\n 23 days later\n\n post by TokenLogic on Jul 4, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic May Update\nDuring June 2025, we participated in 14 of 14 Aave Improvement Proposals (AIPs), and 7 of 8 Snapshot votes.\nSnapshot Votes\n[TEMP CHECK] Add XAUt to Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding. Very keen to strengthen Aave’s relationship with tether and integrate the first Gold tokenized asset on Aave.\nChaos Labs x Aave DAO — Early Renewal Proposal\nVote Cast: YAE\nWe support this early renewal. Chaos has been doing an amazing job and the introduction of new work streams justifies this funding request.\n[ARFC] Addition of USDe to Ethena Principal Token Stablecoin E-Modes\nVote Cast: YAE\nWe support this proposal, this update will bring more efficiency to the two PTs eModes.\n[ARFC] GHO CEX Earn Incentive Program\nVote Cast: YAE\nWe support this proposal and we think this CEX Earn Program will initiate the next leg of GHO growth. GHO will enter a completely new type of market and reach new users through this initiative.\n[TEMP CHECK] Onboard syrupUSDC to Aave V3 Core Instance\nVote Cast: YAE\nWe support this proposal. Maple has been growing exponentially these last few months and syrupUSDC has become a top 3 yield bearing stablecoin in the space. This onboarding will stimulate stablecoin borrowing and be a great revenue source for the DAO.\n[TEMP CHECK] Onboard USD1 to Aave V3 Core and BNB Instance\nVote Cast: YAE\nWe support this onboarding and are keen to see WLFI grow on Aave.\n[ARFC] stS Loop Incentive Program\nVote Cast: No Vote Submitted\nWe wrote this proposal and didn’t vote for it. We support this incentive program as it will bootstrap the main S LST loop on the sonic Instance and will help it grow significantly. Beets through Balancer has always been a strong aligned actor in the ecosystem and we are happy to work with them and help them grow.\n[ARFC-Addendum] Update Merit for Round 18\nVote Cast: YAE\nWe support this proposal.\nAIP Votes\nAsset Parameters Optimization\nVote Cast: YAE\nWe supported this proposal as the optimization should increase the DAO’s revenue.\nOnboard wrsETH to ZKsync V3 Instance\nVote Cast: YAE\nWe voted in favor of this onboarding, Kelp is growing on every network and on zkSync they’ll access to a wstETH eMode.\nJune Funding Update - Part I\nVote Cast: YAE\nWe support this funding update as it will keep the buybacks rolling.\nAave Events & Sponsorship Budget 2025\nVote Cast: YAE\nWe fully support this proposal, Aave’s events at ETHCC were great and help to strengthen the brand.\nGHO Avalanche Launch\nVote Cast: YAE\nWe support this proposal, very excited to help GHO grow on the Avalanche network.\nJune Funding Update - Part II\nVote Cast: YAE\nWe support this proposal, the second part of the monthly funding will facilitate the DAO’s operations and will give MERIT and AHAB their respective budget a bit ahead to help ACI’s team to plan ahead the distribution of the new weekly incentives for sGHO.\nAave V3 Aptos Activation\nVote Cast: YAE\nWe voted in favour of this proposal as we are excited to see Aave go live on the Aptos network. Looking forward to the phase 0 completion to then be able to grow that instance into the biggest liquidity layer of the Aptos chain.\nOnboard tETH to Aave v3 Prime Instance\nVote Cast: YAE\nWe voted in favor of this onboarding and are very keen to see Treehouse grow on the Prime instance. This onboarding will boost the wstETH deposit yield on the instance to become the best sink for wstETH on mainnet.\nEnable additional SVR oracles\nVote Cast: YAE\nWe voted in favor of this proposal. SVR expanding means revenue expanding.\nAdd EURC to Aave V3 Core Instance\nVote Cast: YAE\nWe voted in favor of this onboarding, this will help to bring EUR stablecoin solution to all the mainnet users. With the current FX environment it is important to provide Aave users solutions to diversify their stablecoin exposition.\nDiscount Rate Risk Oracle Activation and update manual AGRS\nVote Cast: YAE\nWe voted in favor of this proposal.\nAave v2 non-Ethereum pools next deprecation steps\nVote Cast: YAE\nWe support this proposal, with v4 around the corner it seems natural to accelerate the deprecation of the smaller v2 markets.\nCAPO Adapter Maintenance Update\nVote Cast: YAE\nWe support this update.\nUpgrade Aave instances to v3.4\nVote Cast: YAE\nWe support this upgrade, the v3.4 introduces important update regarding and are greatly in favor of those changes.\n\n 1 month later\n\n post by TokenLogic on Aug 17, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic July Update\nDuring July 2025, we participated in 14 of 14 Aave Improvement Proposals (AIPs), and 9 of 10 Snapshot votes.\nSnapshot Votes\n[ARFC] Update Signers and SAFE Configuration\nVote Cast: YAE\nWe support this update. It will ease the operational process of the DAO while increasing the security of each multi-sig.\n[TEMP CHECK] Onboard openUSDT to Aave V3 BOB Instance\nVote Cast: YAE\nWe support this onboarding and are keen to see the BOB Instance grow.\n[TEMP CHECK] Onboard SolvBTC to Aave V3 BOB Instance\nVote Cast: YAE\nWe support this onboarding and are keen to see the BOB Instance grow.\n[TEMP CHECK] Onboard xSolvBTC to Aave V3 BOB Instance\nVote Cast: YAE\nWe support this onboarding and are keen to see the BOB Instance grow.\n[TEMP CHECK] Onboard fxSAVE to Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding. Fx protocol is one of the most promising protocol in the space. We are looking forward to see it grow on Aave Core Instance.\n[ARFC] Safety Module Emission Update\nVote Cast: YAE\nWe support this proposal. As Umbrella continues to scale and the slashing risk of the staked asset decreases, the risk-adjusted return of these assets improves significantly. Reducing emissions helps maintain this enhanced risk-adjusted return. Moreover, with ongoing buybacks, lowering emissions would make the AAVE token deflationary for the first time in its history.\n[ARFC] Deploy a Whitelabel Aave V3 Instance on Ink\nVote Cast: YAE\nWe support this deployment. The Ink network is set to grow heavily and we are looking forward to see that happen.\n[ARFC] Orbit Program Renewal - Q2 2025\nVote Cast: YAE\nWe support this proposal and are very grateful for what the Delegates under the Orbit program bring to the DAO.\n[ARFC] Dynamic Calibration of CAPO Parameters via Risk Oracles\nVote Cast: YAE\nWe support this update. This will make the CAPO oracles better and improve the overall security of the Aave protocol.\n[ARFC] Claiming AAVE Rewards for the Sablier Legacy v1.1 Contract\nVote Cast: No Vote\nWe missed this vote but would have voted YAE.\nAIP Votes\nChaos Labs x Aave DAO — Early Renewal Proposal\nVote Cast: YAE\nWe supported this renewal and value very highly all the great work Chaos Labs has been doing for the DAO.\nCEX Earn Funding Proposal\nVote Cast: YAE\nWe voted in favor of this proposal as this budget will unlock the next growth phase of GHO on centralized exchanges. We are very excited to lead that initiative.\nOnboard sUSDe September expiry PT tokens on Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding, the PT have been a great growth avenue for Aave, Ethena and Pendle.\nstS Loop Incentive Program\nVote Cast: YAE\nWe fully support this proposal, this incentive program will boost the stS trade and we will see some growth of s correlated assets on the Sonic instance.\nDeprecation of Long-tail Assets\nVote Cast: YAE\nWe support this proposal.\nRobot Maintenance\nVote Cast: YAE\nWe support this proposal.\nAmend PT-sUSDe september stablecoin emode\nVote Cast: YAE\nWe voted in favour of this proposal as it will make the emode more efficient for Ethena’s assets.\nSafety Module Emission Update\nVote Cast: YAE\nWe support this proposal. As Umbrella continues to scale and the slashing risk of the staked asset decreases, the risk-adjusted return of these assets improves significantly. Reducing emissions helps maintain this enhanced risk-adjusted return. Moreover, with ongoing buybacks, lowering emissions would make the AAVE token deflationary for the first time in its history.\nAdd USDe to the sUSDe emode Category\nVote Cast: YAE\nWe voted in favor of this proposal. The liquid leverage trade from Ethena is a great concept and will bring much more liquidity into the Core Instance.\nOnboard USDe September expiry PT tokens on Aave V3 Core Instance\nVote Cast: YAE\nWe voted in favor of this onboarding, PT-susde and PT-usde are key assets for Aave’s stablecoin demand.\nwS and BTC.b Interest Rate Curve Optimization\nVote Cast: YAE\nWe voted in favor of this proposal, this will help the stS incentive program to perform much better.\nFire drill proposal Avalanche VotingMachine\nVote Cast: YAE\nWe support this proposal and are very keen to see Aave’s governance moving from Polygon to Avalanche.\nJuly 2025 - Funding Update\nVote Cast: YAE\nWe support this Funding update. This one will help seed all the important initiatives going at the moment.\nInterest Rate Update - WETH and wstETH Ethereum\nVote Cast: YAE\nWe support this upgrade, as this will make the reserve of wETH and wstETH more profitable for the DAO while increasing the efficiency for users.\nCaps Risk Oracle Activation on Optimism, BNB, Gnosis, Polygon\nVote Cast: YAE\nWe support this deployment.\nGHO Gnosis Launch\nVote Cast: No vote\nWe missed this vote but would have voted YAE.\n\n 3 months later\n\n post by TokenLogic on Nov 21, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic August Update\nDuring August 2025, we participated in 9 of 14 Aave Improvement Proposals (AIPs), and 11 of 11 Snapshot votes.\nSnapshot Votes\n[TEMP CHECK] Update forum features\nVote Cast: YAE\nWe support this proposal as it will smoothen the forum experience for all the users.\n[ARFC] Aave Asset class Allowlist (AAcA) creation\nVote Cast: YAE\nWe support this proposal. This Allowlist will help all the service providers involved in the onboarding process of an asset to follow a structured framework.\n[TEMP CHECK] Onboard LsETH to Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding, lsETH is an LST which meets all the compliance requirements from institutional users. This onboarding should help bootstrap demand in that area.\n[TEMP CHECK] Onboard tUSDe December expiry PT tokens on Aave V3 Core\nVote Cast: YAE\nWe support this onboarding because the Pendle Share, as a USDe-based derivative, is expected to stimulate demand for USDe debt through its attractive yield.\n[ARFC] Add XAUt to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding. Integrating the ecosystem’s strongest gold-backed derivative into Aave represents a significant step forward for the protocol, and we look forward to seeing its adoption grow. This initiative also further reinforces the ongoing Aave x Tether collaboration.\n[ARFC] Onboard tBTC to Aave v3 on Base\nVote Cast: YAE\nWe support this onboarding. tBTC is one of the strongest BTC wrapper. Opening the Base gates would help them grow bigger and offer alternatives to cbBTC on that chain.\n[ARFC] Launch GHO on Ink & set ACI as Emissions Manager for Rewards\nVote Cast: YAE\nWe support this deployment. The Ink network is set to grow heavily and we are very keen to see GHO grow there as well. This is the first step to get GHO on the Kraken exchange.\n[ARFC] Automation of the Slope2 Parameter via Risk Oracles\nVote Cast: YAE\nWe support this proposal and are looking forward to see the Risk Oracles grow. Congrats to Chaos for putting this forward.\n[TEMP CHECK] Add MetaMask USD (mUSD) to Aave v3 Core Instance on Ethereum and Linea\nVote Cast: YAE\nWe support this onboarding. This initiative represents another important milestone in Aave’s ongoing collaboration with MetaMask and Consensys.\n[ARFC] Launch GHO on Linea & Set ACI as Emissions Manager for Rewards\nVote Cast: YAE\nWe support this onboarding, with Linea incentive campaign being live, we believe it can be a great growth avenue for GHO to be deployed on the Linea network.\n[ARFC] Launch GHO on Plasma & Set ACI as Emissions Manager for Rewards\nVote Cast: YAE\nWe support this onboarding, with Plasma huge incentive campaign being live, we believe it can be a great growth avenue for GHO.\nAIP Votes\nUpgrade Aave instances to v3.5\nVote Cast: YAE\nWe support this upgrade, it is a very important step forward for the protocol.\nAdd tETH to Core Instance Ethereum\nVote Cast: YAE\nWe support this onboarding. After a good success on Prime we think it is a good time to open the gates to the Core instance.\nAdd ezETH to Aave v3 Core Instance\nVote Cast: YAE\nWe support this onboarding.\nFire drill proposal Ethereum VotingMachine\nVote Cast: No vote\nWe missed that vote but would have voted in favor.\nLBTC and eBTC Price Feeds Update\nVote Cast: YAE\nWe support this proposal. Only a technical fix as both assets are becoming yield bearing.\nOnboard rsETH to Aave V3 Linea Instance\nVote Cast: YAE\nWe support this onboarding. With the Linea incentive program there is a lot of ETH debt to consume there and we think rsETH in one of the best collateral to stimulate that demand.\nClaiming AAVE Rewards for the Sablier Legacy v1.1 Contract\nVote Cast: YAE\nWe support this proposal. It is to help an old partner.\nOnboard tBTC to Aave v3 on Arbitrum\nVote Cast: YAE\nWe support this proposal. After a successful launch on Mainnet and the DRIP campaign on Arbitrum, we think that tBTC is a great addition to the Arbitrum market.\nHorizon RWA Instance Activation\nVote Cast: No vote\nWe missed this proposal.\nInk aDI path activation\nVote Cast: NO vote\nWe missed this proposal but would have voted in favour. This is the last step before the final deployment on Ink and are looking forward to see that market live.\nOnboard tBTC to Aave v3 on Base\nVote Cast: NO vote\nWe missed this proposal but would have voted for.\nAdd XAUt to Aave v3 Core Instance\nVote Cast: No vote\nWe missed this proposal but would have voted For. Integrating the ecosystem’s strongest gold-backed derivative into Aave represents a significant step forward for the protocol, and we look forward to seeing its adoption grow. This initiative also further reinforces the ongoing Aave x Tether collaboration.\nOnboard sUSDe November expiry PT tokens on Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding. This is a simple rollover of the same Ethena PTs which are rgeat assets driving a lot of stablecoin debt across the Core Instance.\nMulti eMode Update and Creation - rsETH, ezETH, wstETH and weETH\nVote Cast: YAE\nWe support this proposal. This will create better capital efficiency for all the parties involved and therefore boost the borrowing demand allowing the DAO to earn more revenue.\n\n post by TokenLogic on Nov 21, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic September Update\nDuring September 2025, we participated in 16 of 16 Aave Improvement Proposals (AIPs), and 13 of 13 Snapshot votes.\nSnapshot Votes\n[ARFC] Aave v2 deprecation (tech) - next phase\nVote Cast: YAE\nWe support this proposal as we are getting closer to v4, it is the natural step forward to start closing down the Aave v2 instance more aggressively.\n[ARFC] Add Fluid Protocol to flashBorrowers\nVote Cast: YAE\nWe support this proposal. Since flash loans are not a major revenue source for Aave, extending free flash loans to Fluid, one of Aave’s strategic partners, will enhance the user experience on the Fluid platform without materially impacting protocol revenues.\n[ARFC] Aave v2 Deprecation - Update\nVote Cast: YAE\nWe support this proposal as adjusting the rates will accelerate the migration from v2 to v3 or even v4 when live.\n[TEMP CHECK] Onboard USDG to Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding as USDG is another Paxos wrapper, it is similar to PYUSD and RLUSD.\n[ARFC] Deploy Aave v3 on Plasma\nVote Cast: YAE\nWe support this deployment. We believe Plasma is going to be the biggest launch ever for an Aave instance and are really looking forward to it.\n[ARFC] Adopt The SEAL Safe Harbor Agreement\nVote Cast: YAE\nWe support this proposal. Security remains Aave’s highest priority, and any measure that strengthens the protocol’s resilience is a meaningful and welcome improvement.\n[ARFC] Steward Deployment: MainnetSwapSteward and RewardsSteward\nVote Cast: YAE\nWe support this proposal. We are excited to present the next iteration of Aave’s non-custodial Treasury Management tooling suite.\n[ARFC] Safety Module & Umbrella Emission Update\nVote Cast: YAE\nWe support this proposal, this improves the overall economics of the Aave token, saving 32,850 AAVE per year.\n[TEMP CHECK] Deploy Aave v3 on X Layer\nVote Cast: YAE\nWe support this deployment. This initiative marks the first significant milestone in the deepening relationship between Aave and OKX.\n[ARFC] Aave Liquidity Committee Funding Phase VII\nVote Cast: YAE\nWe support this proposal, with GHO growing stronger, the ALC budget keeps on getting smaller making every unit of GHO closer to sustainable for the DAO.\n[ARFC] Endorse the Asset Classification Framework (AAcA)\nVote Cast: YAE\nWe support this proposal. This Allowlist will help all the service providers involved in the onboarding process of an asset to follow a structured framework.\n[ARFC-Addendum] Update Merit for Round 30\nVote Cast: YAE\nWe support this proposal, with this Addendum, it will be easier to integrate Earn programs from centralised exchanges.\n[ARFC] Add MetaMask USD (mUSD) to Aave v3 Core Instance on Ethereum and Linea\nVote Cast: YAE\nWe support this onboarding. This initiative represents another important milestone in Aave’s ongoing collaboration with MetaMask and Consensys.\nAIP Votes\nOnboard USDe November expiry PT tokens on Aave V3 Core Instance\nVote Cast: YAE\nWe support this onboarding. This is a simple rollover of the same Ethena PTs which are great assets driving a lot of stablecoin debt across the Core Instance.\nAdd Fluid Protocol to flashBorrowers\nVote Cast: YAE\nWe support this proposal. Since flash loans are not a major revenue source for Aave, extending free flash loans to Fluid, one of Aave’s strategic partners, will enhance the user experience on the Fluid platform without materially impacting protocol revenues.\nGHO Facilitator Replacement\nVote Cast: YAE\nWe support this proposal, important update for the health of GHO.\nSeptember Funding Update\nVote Cast: YAE\nWe fully support this proposal. This is a routine finance update involving the distribution of funding to the initiatives that required it, as well as several swaps across the various instances.\nIncrease rsETH Supply Cap on Aave V3 Linea Instance\nVote Cast: YAE\nWe support this proposal. rsETH is experiencing a lot of demand on Linea, and it is faster to go with a big supply cap update through the AIP then doubling the caps through the Risk stewards.\nRequest for Bounty Payout - August 2025\nVote Cast: YAE\nWe support this proposal.\nRisk Parameter Adjustments for Aave V3 Scroll Instance\nVote Cast: YAE\nWe voted in favour of this proposal. Given the limited growth of the instance, the DAO remains far from recouping its initial investment, making this measure appropriate at the current stage.\nAdd EURC to Avalanche V3 Instance\nVote Cast: YAE\nWe support this proposal. We are looking forward to see more adoption of Euro stablecoins across all the Aave instances.\nRaise sUSDe and USDe November expiry PT tokens caps on Aave V3 Core Instance\nVote Cast: YAE\nWe voted in favour of this proposal. It is an important increase which was faster done through an AIP rather than risk stewards.\nPlasma aDI path activation\nVote Cast: YAE\nWe voted in favour of this proposal, this is the last step before the launch of Aave on Plasma, looking forward to it.\nAave V2 deprecation\nVote Cast: YAE\nWe support this proposal as we are getting closer to v4, it is the natural step forward to start closing down the Aave v2 instance more aggressively.\nAave V3.5 Plasma Activation\nVote Cast: YAE\nWe support this proposal and are very keen to see the biggest Aave launch happen.\nGHO Ink Launch\nVote Cast: YAE\nWe support this deployment. The Ink network is set to grow heavily and we are very keen to see GHO grow there as well. This is the first step to get GHO on the Kraken exchange.\nBob Network aDI path activation\nVote Cast: YAE\nWe support this deployment, last step before the Aave launch on BoB.\nAave Liquidity Committee Funding Phase VII\nVote Cast: YAE\nWe support this proposal, with GHO growing stronger, the ALC budget keeps on getting smaller making every unit of GHO closer to sustainable for the DAO.\nAave v2 Deprecation - Update\nVote Cast: YAE\nWe voted in favour of this proposal, it is just little updates from the 378.\n\n post by TokenLogic on Nov 21, 2025\n\n TokenLogic\n\n TokenLogic-Finance SP\n\n TokenLogic October Update\nDuring October 2025, we participated in 16 of 17 Aave Improvement Proposals (AIPs), and 13 of 15 Snapshot votes.\nSnapshot Votes\n[ARFC] Aave v3.6 candidate\nVote Cast: No Vote\nWe missed this vote, but would have been in favour of it.\n[TEMP CHECK] Onboard USDai & sUSDai to Aave V3 Plasma & Arbitrum Instance\nVote Cast: YAE\nWe support this proposal. USDAI is a hot token, we would still wait for Risk Service providers at the next stage as we are not sure, the asset meets the Aave standards.\n[ARFC] TokenLogic - Phase II\nVote Cast: No vote\nWe did not vote on this proposal, as it concerns the renewal of our own one-year contract with the Aave DAO. We are proud of the work we have delivered so far and look forward to continuing our collaboration.\n[ARFC] Extend Ahab Funding\nVote Cast: YAE\nWe support this proposal, as it provides the growth teams with a more flexible funding framework to honour incentive commitments made by Service Providers when securing strategic partnerships.\n[TEMP CHECK] Onboard frxUSD to Aave v3 Ethereum Core Instance\nVote Cast: NAE\nWe don’t support this onboarding yet. We want to revisit it once frxUSD has grown to a much bigger scale.\n[ARFC] Service Provider Compensation Reform for V4 Alignment\nVote Cast: YAE\nWe support this proposal. We believe it further aligns Service Providers with the DAO and strengthens their long-term commitment to Aave’s success.\n[ARFC] USDC (old) deprecation on Gnosis Chain Instance\nVote Cast: YAE\nWe support this proposal.\n[ARFC-Addendum] Update Merit for Round 33 - Adding Gate.io\nVote Cast: YAE\nWe support this proposal, this makes the GATE.IO earn program even more attractive and should bring more adoption of GHO on their centralised exchange.\n[ARFC] Evolving Resilience: Security Services for Aave v4 <> Certora\nVote Cast: YAE\nWe support this funding. Certora has consistently demonstrated best-in-class security review capabilities for Aave over the past several years. We believe they are the most qualified team to undertake this critical audit role for Aave V4.\n[ARFC] Security Services for Aave Current Infrastructure <> Certora\nVote Cast: YAE\nWe support this proposal. As stated previously, we consider Certora to be among the best in their field and have greatly appreciated working with them to date.\n[ARFC] Orbit Program Renewal - Q3 and Q4 2025\nVote Cast: YAE\nWe support this proposal. Moving to a biannual schedule will reduce operational overhead while keeping key delegators aligned and engaged within the Orbit program.\n[ARFC] AAVE Buybacks program: An update\nVote Cast: YAE\nWe support this proposal. In the current market environment, effectively navigating volatility is increasingly important. Providing additional flexibility to this program will enable the DAO to accumulate more AAVE at lower prices and deliver value back to AAVE holders in a more cost-efficient manner.\n[ARFC] Aave DAO <> BGD Labs. Phase 6 & Project E\nVote Cast: YAE\nWe support this funding. BGD has been an instrumental force behind Aave’s success, consistently delivering some of the highest-quality technical work in the ecosystem across multiple mandates. We strongly endorse their continued contribution to the DAO.\n[ARFC] Aave V4 Security Funding\nVote Cast: YAE\nWe support this funding. This is the last step towards the launch of Aave v4.\nAIP Votes\npyUSD Parameters Optimization\nVote Cast: YAE\nWe supported this proposal as it will make PYUSD more capital efficient on Core market.\n[ARFC] Safety Module & Umbrella Emission Update\nVote Cast: YAE\nWe voted in favor of this proposal as it removes all the coverage risks associated with stkAAVE and stkABPT.\nSteward Deployment: MainnetSwapSteward and RewardsSteward\nVote Cast: YAE\nWe support this proposal. We are excited to present the next iteration of Aave’s non-custodial Treasury Management tooling suite.\nClaim Aave v2 stkAAVE rewards\nVote Cast: YAE\nWe fully support this proposal.\nFull Deprecation of DPI Across Aave Deployments\nVote Cast: YAE\nWe support this proposal. Delisting the asset is a sensible step given that Chainlink is preparing to deprecate its oracle.\nAdopt The SEAL Safe Harbor Agreement\nVote Cast: YAE\nWe support this proposal. Security remains Aave’s highest priority, and any measure that strengthens the protocol’s resilience is a meaningful and welcome improvement.\nAllow PyUSD as collateral\nVote Cast: YAE\nWe voted in favour of this proposal to make PYUSD more efficient.\nGho Plasma Launch\nVote Cast: YAE\nWe support this proposal. With Plasma’s highly successful launch and the chain’s strong focus on stablecoins, deploying GHO there represents the next logical phase of growth.\nOnboard sUSDe and USDe January expiry PT tokens on Aave V3 Plasma Instance\nVote Cast: YAE\nWe voted in favour of this proposal. PT Ethena tokens have had a great success on Core market. With Plasma huge USDT liquidity we expect a lot","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791265977193,"hash":"fa19da467e07091c20d86627b5592be952218efb"}
{"url":"https://docs.base.org/build-on-base/issue-rwa/issue-units","domain":"docs.base.org","title":"Issue Units to Holders - Base Documentation","text":"Distribute shares to multiple holders in one all-or-nothing transaction with B20 Asset’s batchMint. Every recipient must pass the token’s mint-receiver policy, and the combined issuance must stay below its supply cap.\nReal-world asset (RWA) tokenization is one of many use cases for the B20 Asset standard. The examples on this page use a stock token for illustration; the same flows apply to other asset types.Tokenized securities examples shown for illustration. Base is a general-purpose blockchain; issuance and compliance are the responsibility of the issuer under applicable law.\n​Demo\n1Approve2IssueVibenet account1Approve holdersIn progress2Issue 1,000PendingApprove holdersAlice and Bob are approved to hold Example Corp shares.OperationUpdate allowlistApprovedAlice, BobSymbolEXMNetworkBase VibenetTransaction event log--:--:--[PENDING]Approve holders--:--:--[PENDING]Issue 1,000The Asset variant batches a cap-table distribution into one transaction.Real Vibenet transactions\nThe demo uses a local browser-generated account to submit real transactions on Base Vibenet. If Vibenet or its B20 features are unavailable, it automatically switches to an illustrative offline version.\nNew to B20? See the B20 Token Standard for the concepts and a full launch walkthrough. These samples target base-std@1505323, viem@2.55.11, and Base Foundry v1.1.1.\n​Issue and Verify the Shares\nimport { parseUnits, type Address } from \"viem\";\nimport { publicClient } from \"../../shared/clients.js\";\nimport { assetAbi, b20Abi } from \"../abi.js\";\nimport { sendContract } from \"../write.js\";\n\nexport async function issueShares(token: Address, holders: [Address, Address]) {\n const amounts = [parseUnits(\"600\", 6), parseUnits(\"400\", 6)] as const;\n await sendContract({ address: token, abi: assetAbi, functionName: \"batchMint\", args: [holders, amounts] });\n const balances = await Promise.all(holders.map((holder) => publicClient.readContract({ address: token, abi: b20Abi, functionName: \"balanceOf\", args: [holder] })));\n if (balances[0] !== amounts[0] || balances[1] !== amounts[1]) throw new Error(\"Unexpected issuance balances\");\n}\n function issueShares(address token, address alice, address bob) public {\n address[] memory recipients = new address[](2);\n recipients[0] = alice;\n recipients[1] = bob;\n uint256[] memory amounts = new uint256[](2);\n amounts[0] = 600e6;\n amounts[1] = 400e6;\n IB20Asset(token).batchMint(recipients, amounts);\n }\nbase-cast send \"$TOKEN_ADDRESS\" \"batchMint(address[],uint256[])\" \\\n \"[$ALICE,$BOB]\" \"[600000000,400000000]\" --rpc-url \"$RPC_URL\" --private-key \"$PRIVATE_KEY\"\nbase-cast call \"$TOKEN_ADDRESS\" \"balanceOf(address)(uint256)\" \"$ALICE\" --rpc-url \"$RPC_URL\"\n\nSee the B20 token standard for the complete interface, roles, and policies.\nAlice holds 600 EXM and Bob holds 400 EXM after the all-or-nothing batch.\nThe entire batch reverts if lengths differ, a recipient fails policy, or total supply would exceed the cap.\n​See Also\nWas this page helpful?Suggest editsRaise issue","tokens":749,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265980506,"hash":"30624c6394a4670f6ad37d42fdca5eb7ce815fd7"}
{"url":"https://dashboard.base.org/","domain":"dashboard.base.org","title":"Base Dashboard","text":"Returning user? Continue with Coinbase Wallet (previously Base Account).Base DashboardSign in to track your impact on Base.We'll create an account for you if you don't already have one.TermsPrivacyWe use cookies to make your interactions with our website more meaningful. They help us better understand how our websites are used, so we can tailor content for you. For more information about the different cookies we are using, read the Cookie Policy. To change your cookie settings and preferences, click the Customize Cookies button. Opt-Out Request HonoredCookie consent managerWhen you visit our website, we may store cookies on your browser for your security and to help us better understand user behavior and inform us about which parts of our website you have visited. The information does not usually directly identify you, but it can give you a safe and more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Blocking some types of cookies may impact your experience on the site.\n Privacy Policy Manage cookie preferencesStrictly Necessary CookiesAlways activeThese cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. These also include cookies we may rely on for fraud prevention. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work.Functional Cookies Functional Cookies These cookies enable us to remember choices you have made in the past in order to provide enhanced functionality and personalisation (e.g. what language you prefer). If you do not allow these cookies then some or all of these services may not function properly.Targeting Cookies Targeting Cookies These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant ads on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.Performance Cookies Performance Cookies These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.Cookie List checkbox label label Consent Leg.Interest checkbox label label checkbox label label checkbox label label","tokens":707,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791265990778,"hash":"89eca7af8b9633b1e0df44aace05f1f3412d61ce"}
{"url":"https://ethresear.ch/t/a-dex-on-plasma/1765","domain":"ethresear.ch","title":"A DEX on Plasma - Layer 2 / Plasma - Ethereum Research","text":"A DEX on Plasma \n\n Layer 2Plasma\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Apr 2018\n\n 1 / 17\n\n Apr 2018\n\n Sep 2018\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\n Plasma MVP and Plasma Cash seem to be focused on a UTXO based coin. Although the challenges we face are from a DEX point of view, solving them will benefit Plasma MVP and Plasma cash as well, so this discussion will help both projects.\nBasics\nPrice Time priority: Exchanges with an order book need to match orders with better price first, followed by orders placed earlier.\nExample: If there exist sell orders (id, price, qty) of (id1, 51, 3) (id2, 52, 1) (id3, 52, 2),\nwhen a buy (id4, 52, 5) is placed, orders with id1 and id2 are filled completely and id3 is filled partially.\nMarket Maker: A trader who provides liquidity on the platform. On many assets, the market maker is one party to almost every single trade.\nPlasma MVP Challenges\n1: UTXO shredding Price time priority execution means that larger UTXOs will be replaced with smaller UTXOs over time. The result of this is that all the system will rapidly tend to large number of UTXOs of the smallest possible size. A market maker’s account is likely to end up with a few thousand UTXO per hour. Gas cost for exit on individual shredded utxos may not justify its value. This will also impact the ability to take tiny fees.\n2: Exit delay too large Traders are accustomed to withdrawing in minutes or hours. A delay of several days could be a huge UX issue. Since large traders hedge their positions and require moving large amounts of funds from a winning exchange to a losing exchange, a 2 week delay will make it hard to attract any decent liquidity into the plasma DEX\n3: Exit window too small It is highly likely that on detecting a maleficent operator, a huge number of UTXOs wish to exit simultaneously. The current manner of exiting would require a user to exit every UTXO they have when they detect this. An average trader may make 5 trades a day, but a market maker is likely to make 100K trades and have over a million UTXOs. It is unlikely that one week is sufficient to get all these into the priority queue. Perhaps parameterizing the delay by the exit priority queue size is an option?\n4: Exit tx too large The gas required for finalizeExit (in OMG implementation) is likely to exceed the block limit preventing exit. At 8M gas limit and 80K gas per output finalized, a max of 100 outputs can exit. Breaking the finalizeExits into multiple batches may be a solution if we can do this without introducing race conditions.\nUpdate Batching using block numbers suggested here.\n5: Everyone needs to validate all Plasma blocks This is an onerous requirement on the users of Plasma MVP. This will also endanger UTXOs of people in natural disaster areas like Puerto Rico after hurricane Maria, who may be cut off from internet service for a while.\n6: Long commitment chains Every transfer of an UTXO increases the transaction size as it requires the full history from the original on-chain deposit. At high transaction rates and lots of tiny outputs to spend for a payment, with market maker trading with many parties, this could complicate logic and degrade performance.\nPlasma cash\n7: Penny wise Price time priority matching is impractical unless everyone holds all their coins in the smallest denomination.\nPossible Solutions\nAccount Model Most plasma issues are exacerbated because of the UTXO model. An account model eliminates many of these and lightens the impacts of the rest. Fixes UTXO shredding, Long commitment chains and Penny wise\nLimited Proof of Authority A POA chain can provide instant finality. As long as the POA is strictly limited by what it can do using fraud proofs on the root chain, we have the best of both worlds. Every bad state change should be detectable and proven on root chain by anyone watching the plasma chain. An error, intentional or otherwise should halt the chain, enabling users to withdraw their coins at leisure. Fixes Exit window too small\nRetiring outputs Requiring an output to be marked as retired would prevent that output from being included in any further transactions on the plasma chain. The only thing that can be done with a retired output is withdrawal on Root chain once retirement is confirmed on plasma block. This can eliminate the 1 week delay and improve UX. The priority queue exit would continue to exist in case the POA fails to include the retire on the plasma chain. Fixes Exit delay too large\nExit Delegation It should be possible to delegate an exit a coin to the depositor address to specialists. The delegate wont be able to spend the coin but they can only initiate a withdrawal ONLY to the depositors address. This removes the onerous requirement of having every user to monitor the chain themselves which is a barrier to entry. Fixes Everyone needs to validate all blocks\nWe have a version of plasma that incorporates the above and I will post our spec in a different thread once we work out the final kinks.\n\n Minimal Viable Plasma\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by kfichter on Apr 18, 2018\n\n post by bharathrao on Apr 18, 2018\n\n post by kfichter on Apr 18, 2018\n\n post by bharathrao on Apr 18, 2018\n\n post by vbuterin on Apr 19, 2018\n\n post by kladkogex on Apr 19, 2018\n\n post by bharathrao on Apr 19, 2018\n\n post by bharathrao on Apr 19, 2018\n\n post by vbuterin on Apr 19, 2018\n\n post by bharathrao on Apr 21, 2018\n\n 3 months later\n\n post by zack-bitcoin on Jul 19, 2018\n\n post by bharathrao on Jul 19, 2018\n\n post by zack-bitcoin on Jul 19, 2018\n\n 29 days later\n\n post by Equilibrium94 on Aug 17, 2018\n\n post by MihailoBjelic on Aug 18, 2018\n\n 1 month later\n\n post by tuna on Sep 21, 2018\n\n Powered by Discourse","tokens":1461,"squid":"ink-research","role":"Deep Scholar","at":1791265993027,"hash":"b1f41f6c2831d9f3d26bb48a3da4332b6e59cc01"}
{"url":"https://www.soliditylang.org/blog/2026/05/05/pattern-matching-in-core-solidity/","domain":"soliditylang.org","title":"Pattern Matching in Core Solidity | Solidity Programming Language","text":"Pattern Matching in Core SolidityPosted by Solidity Team on May 5, 2026AnnouncementsSmart contracts often need to handle values that come in several variants: a\npayment might be native ETH, an ERC20 transfer, or an NFT transfer; an auction\ncan be not-started, active, ended, or cancelled. Each variant needs different\nhandling, and the logic for that handling tends to be scattered across many\nfunctions. When a developer adds a new variant and forgets to update one of\nthose functions, the compiler says nothing. Once deployed, that oversight can\ncost real money to find and fix.\nCore Solidity's algebraic data types (ADTs) and pattern matching, introduced in\nour deep dive post,\neliminate this class of bug at compile time. This post explains why that matters\nfor contract safety and how the feature holds up in practice.\nWhy Classic Solidity Needs Better Data Modeling\nSmart contracts often deal with data that exists in one of several mutually\nexclusive states. A natural example is a multi-asset payment processor that can\nhandle native ETH transfers, ERC20 token transfers, and ERC721 NFT transfers.\nHere is a representative implementation in Classic Solidity:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\ncontract PaymentHandler {\n enum PaymentType { NATIVE, ERC20, ERC721 }\n\n struct Payment {\n PaymentType paymentType;\n address token;\n address from;\n address payable to;\n uint256 amount;\n uint256 tokenId;\n }\n\n function processPayment(Payment calldata payment) external {\n if (payment.paymentType == PaymentType.NATIVE) {\n require(payment.token == address(0), \"Native: no token\");\n require(payment.amount > 0, \"Native: amount required\");\n require(payment.tokenId == 0, \"Native: no tokenId\");\n (bool success, ) = payment.to.call{value: payment.amount}(\"\");\n require(success, \"Native: transfer failed\");\n } else if (payment.paymentType == PaymentType.ERC20) {\n require(payment.token != address(0), \"ERC20: token required\");\n require(payment.amount > 0, \"ERC20: amount required\");\n require(payment.tokenId == 0, \"ERC20: no tokenId\");\n IERC20(payment.token).transferFrom(payment.from, payment.to, payment.amount);\n } else if (payment.paymentType == PaymentType.ERC721) {\n require(payment.token != address(0), \"ERC721: token required\");\n require(payment.amount == 1, \"ERC721: amount must be 1\");\n require(payment.tokenId > 0, \"ERC721: tokenId required\");\n IERC721(payment.token).transferFrom(payment.from, payment.to, payment.tokenId);\n }\n }\n\n function calculateFee(Payment calldata payment) external pure returns (uint256) {\n if (payment.paymentType == PaymentType.NATIVE) {\n return payment.amount / 20;\n } else if (payment.paymentType == PaymentType.ERC20) {\n return payment.amount / 10;\n } else if (payment.paymentType == PaymentType.ERC721) {\n return 0.01 ether;\n }\n return 0; // unreachable, but the compiler requires it\n }\n}\n\nThis code has several safety problems the compiler cannot catch.\nInvalid states are representable. The Payment struct can be constructed\nwith contradictory fields: a NATIVE payment with a non-zero token address,\nor an ERC721 payment with no tokenId. The struct has enough fields to\nrepresent any of the three payment variants, but nothing in the type prevents us\nfrom filling those fields with incoherent values. The require calls in\nprocessPayment are the only check we have, and they have to be repeated in\nevery function that receives a Payment.\nNo compile-time totality guarantee. If we add a new variant, say ERC1155,\nto the PaymentType enum, the compiler will not tell us where the dispatch\nlogic needs to be updated. processPayment will silently do nothing for\nERC1155 payments. calculateFee will silently return 0. Every function that\ndispatches on PaymentType can silently fail.\nRedundant runtime validation. Because the type system cannot express the\nconstraint that, e.g., a NATIVE payment has no token, each function must\nrepeat those structural checks. This is both verbose and error-prone: a\ndeveloper might add a new function and forget to validate one of the fields.\nThese checks also have a runtime cost: every require executes on-chain and\nconsumes gas, whereas invariants enforced by the type system are verified at\ncompile time and vanish entirely from the deployed bytecode. There is also a\nsubtler issue of data cohesion. Because the Payment struct separates the tag\n(paymentType) from its fields, nothing prevents a caller from pairing them\nincorrectly. ADTs bundle the constructor and its payload into a single,\ninseparable unit, so that kind of mismatch cannot be expressed in the type and\nno require check can fully substitute for that guarantee.\nAlgebraic Data Types Make Invalid States Unrepresentable\nCore Solidity lets us define a Payment type that expresses these three\nvariants precisely. word is Core Solidity's primitive 256-bit type, equivalent\nto an untyped Yul variable.\ndata address = address(word);\ndata tokenid = tokenid(word);\n\ndata Payment =\n Native(address, word)\n | ERC20(address, address, address, word)\n | ERC721(address, address, address, tokenid);\n\nEach constructor carries exactly the data it needs: no more, no less. A Native\npayment holds a recipient and an amount. An ERC20 payment holds a token\ncontract address, a sender, a recipient, and an amount. An ERC721 payment\nholds a token contract, a sender, a recipient, and a token identifier. There is\nno Payment value that carries an ERC721 token identifier while claiming to\nbe a Native payment: the type simply does not allow it.\nNow the processPayment function becomes declarative and self-documenting:\nfunction processPayment(payment : Payment) {\n match payment {\n | Native(to, amount) =>\n transfer(to, amount);\n | ERC20(token, from, to, amount) =>\n transferFromERC20(token, from, to, amount);\n | ERC721(token, from, to, tokenId) =>\n transferFromERC721(token, from, to, tokenId);\n }\n}\n\nThe pattern match binds exactly the fields that are relevant to each variant.\nThere are no require calls to check structural invariants, the type system has\nalready done that job. The amount field on a Native payment and the\ntokenId field on an ERC721 payment cannot be confused, because they live in\nseparate constructors.\nAdding a new variant, say ERC1155(address, address, address, tokenid, word),\nwill cause the compiler to immediately report every match statement that does\nnot handle the new case. No function can silently miss the new variant.\nTotality: Exhaustiveness as a Safety Property\nThe example above shows the safety property that matters most: exhaustiveness\nchecking (also called totality). A pattern match is exhaustive if every\npossible value of the scrutinee (the value being matched on) is handled by at\nleast one branch. The Core Solidity compiler enforces this statically and\nrejects any program that contains an incomplete match.\nSmart contract bugs are extremely costly to fix. Once a contract is deployed,\nits logic is immutable (absent an upgradeable proxy pattern), and any ether or\ntokens locked by a buggy contract may be permanently inaccessible. In the\nClassic Solidity calculateFee function above, the final return 0 is dead\ncode that exists only because the compiler cannot verify that the if-else chain\ncovers all variants. If a future developer adds a fourth PaymentType and\nforgets to update calculateFee, the function silently returns zero. That is a\npotentially expensive mistake that will not be caught until it is too late.\nExhaustiveness checking turns these bugs into compile-time errors. Consider the\nfollowing incomplete match:\ndata AuctionState =\n NotStarted(uint256)\n | Active(uint256, address)\n | Ended(uint256, address)\n | Cancelled(uint256, address);\n\nfunction processBid(state : AuctionState) -> AuctionState {\n match state {\n | NotStarted(reserve) =>\n require(msg.value >= reserve);\n return Active(msg.value, msg.sender);\n | Active(currentBid, bidder) =>\n require(msg.value > currentBid);\n transferFunds(bidder, currentBid);\n return Active(msg.value, msg.sender);\n }\n}\n\nThe Ended and Cancelled variants are not handled. The Core Solidity compiler\nwill report a compile-time error similar to the following:\nNon-exhaustive pattern match. Missing case: Ended($v0, $v1)\n in function processBid\n in match (state)\n\nThe compiler names a missing pattern, a witness, so the developer knows\nexactly what to fix. This error must be resolved before the program can compile.\nThe developer might add explicit branches for Ended and Cancelled, or add a\nwildcard default (| _ =>), but in either case the decision is deliberate and\nvisible in the source code.\nRedundancy checking is the complementary property: the compiler also warns when\na pattern branch can never be reached because an earlier branch already covers\nits inputs. Redundant branches are often symptoms of copy-paste errors or of\ncode that was not updated after a refactor.\nWhat This Means for Audits\nSmart contract security audits are expensive. On enum-heavy contracts, auditors\nspend real time verifying that every function that dispatches on a type covers\nall cases, manually tracing if-else chains and checking that no variant falls\nthrough to a silent default. This is tedious, error-prone work that scales with\nthe number of functions and variants in a codebase.\nPattern matching with exhaustiveness checking makes that entire category of\naudit finding disappear. When the compiler rejects incomplete matches, an\nauditor does not need to check whether calculateFee handles ERC1155: if it\ncompiled, it does. The time auditors previously spent tracing dispatch logic can\nbe spent on higher-value findings. For projects paying five or six figures for\nan audit, that is a real saving.\nWhat About Existing Validation Patterns?\nA reasonable question from developers who already write defensive code: \"I\nalready use require checks and careful enum handling. What does this buy me?\"\nYour existing practices aren't wrong, they just don't scale. Today, the\ndiscipline of \"update every dispatch function when you add a variant\" relies on\nmemory, code review checklists, and audit reports. It is not enforced by the\ncompiler, so it can fail. When a team member adds ERC1155 support under\ndeadline pressure and misses one function, the compiler says nothing. Pattern\nmatching moves that discipline into the toolchain, where it cannot be forgotten.\nThe Pattern Match Compiler\nExhaustiveness and redundancy checking, together with the translation of nested\npatterns into efficient code, are handled by a dedicated compilation pass in the\nCore Solidity prototype, which follows the ideas described in\nCompiling Pattern Matching to Good Decision Trees.\nA key motivation for this design is to make exhaustiveness checking tractable.\nPattern matching algorithms based on backtracking automata are effective at\ngenerating efficient code, but they are notoriously difficult to extend with\nexhaustiveness analysis: the automaton construction does not naturally expose\nwhich inputs remain uncovered. Decision-tree-based approaches, by contrast,\nproduce exhaustiveness and redundancy information as natural byproducts of the\ncompilation process itself, without requiring a separate analysis pass.\nThis pass runs after type inference and before code generation. Its job is to\ntransform match statements over arbitrary nested patterns into a decision\ntree, a form where each node tests exactly one scrutinee against flat\nconstructor patterns. The resulting tree is then converted back into simplified\nmatch statements that the Yul backend can handle directly.\nThe algorithm works by treating the match arms as a pattern matrix (one row\nper arm, one column per scrutinee), selecting the most informative column to\ntest first using a necessity heuristic, and recursively building sub-matrices\nfor each constructor case. Exhaustiveness and redundancy are both detected as\nnatural byproducts of this construction: a missing case surfaces when the matrix\nhas no row to cover a particular input, and a redundant arm surfaces when its\nrow is already subsumed by earlier rows.\nThe practical output of this pass is straightforward. For example, the following\nfunction:\ndata Phase = Early | Late;\n\nfunction discount(state : AuctionState, phase : Phase) -> uint256 {\n match state, phase {\n | Active(bid, _), Early => return bid / 10;\n | Active(bid, _), Late => return bid / 20;\n | _, _ => return 0;\n }\n}\n\nis compiled into a nested sequence of single-level matches:\nfunction discount(state : AuctionState, phase : Phase) -> uint256 {\n match state {\n | Active($bid, $pad) =>\n match phase {\n | Early => return $bid / 10;\n | Late => return $bid / 20;\n }\n | $v0 => return 0;\n }\n}\n\nAll nested constructor patterns have been flattened, and each variable\nintroduced by the flattening has been substituted into the arm body.\nExhaustiveness and Redundancy Errors\nThe compiler produces concrete, actionable error messages. An incomplete match:\nfunction discount(state : AuctionState, phase : Phase) -> uint256 {\n match state, phase {\n | Active(bid, _), Early => return bid / 10;\n | Active(bid, _), Late => return bid / 20;\n // missing: all non-Active states\n }\n}\n\nproduces:\nNon-exhaustive pattern match. Missing case: NotStarted($v0), $v1\n in function discount\n in match (state, phase)\n\nThe witness NotStarted($v0), $v1 identifies the first uncovered case: any\nNotStarted state paired with any phase value, giving the developer a concrete\nstarting point for completing the match.\nA redundant arm:\nfunction f(x : Bool) -> Bool {\n match x {\n | z => return z; // catches everything\n | True => return True; // unreachable: z above already covers True\n }\n}\n\nproduces:\nWarning: Clause (True → return True) is redundant.\n in function f\n in match (x)\n\nUnlike non-exhaustive matches, redundant-clause warnings do not prevent\ncompilation: they are reported as warnings to assist developers during\nrefactoring.\nLowering to Yul: Why There Is No Overhead\nA common concern when adding type-level machinery is that it comes with a\nruntime cost. Pattern matching over algebraic data types does not. The generated\nYul is the same switch statement a careful developer would write by hand.\nAfter pattern compilation, the program goes through specialization\n(monomorphization of generic functions and type class instances) and is emitted\nas Hull: a first-order functional intermediate representation with sum and\nproduct types. The separate yule backend, implemented in\nTranslate.hs,\nthen translates Hull into Yul. The intermediate languages used throughout the\nCore Solidity compilation pipeline will be the subject of future posts.\nRuntime Representation of Sum Types\nYul has no algebraic types, only 256-bit words. Every sum type is therefore\nflattened onto the EVM stack as:\n1 (tag word) + max(payload size across all constructors)\n\nThe tag identifies which constructor is active. The payload slots hold the\nfields of the active constructor, padded with unused words to reach the maximum\npayload size.\nBinary sums (A | B) use false (0) for the first constructor and true\n(1) for the second. Bool = False | True occupies exactly one stack slot\nbecause both constructors are nullary.\nN-ary sums get an integer tag (0, 1, 2, …). For AuctionState:\ndata AuctionState =\n NotStarted(uint256) // payload: 1 word\n | Active(uint256, address) // payload: 2 words\n | Ended(uint256, address) // payload: 2 words\n | Cancelled(uint256, address); // payload: 2 words\n\nThe widest payload is 2 words, so every AuctionState value occupies 3 stack\nslots: a tag and two payload words. NotStarted(1000) is\n(0, 1000, <unused>) on the stack; Active(500, 0xABCD) is (1, 500, 0xABCD).\nSingle-constructor types (wrapper newtypes) have no tag at all: the\nconstructor is erased entirely. As an example, data uint256 = uint256(word) is\njust one stack slot, with zero overhead compared to using a raw word.\nMatch Compiles to Switch\nThe Yul backend emits a switch on the tag word, with one case per\nconstructor. The output is minimal and readable.\nFor not, a nullary binary sum:\nfunction not(b : Bool) -> Bool {\n match b {\n | False => return True;\n | True => return False;\n }\n}\n\nfunction usr$not(_v0) -> _result {\n switch _v0\n case false { _result := true }\n case true { _result := false }\n}\n\nFor require, a match arm with an empty body:\nfunction require(cond : Bool, msg : word) {\n match cond {\n | True =>\n | False => myrevert(msg);\n }\n}\n\nfunction usr$require(cond, msg) {\n switch cond\n case true {}\n case false { usr$myrevert(msg) }\n}\n\nEmpty {} blocks are valid Yul. The case true arm does nothing.\nFor tryWithdraw, a binary sum with a payload (Option(uint256)):\ndata Option(a) = None | Some(a);\n\nfunction tryWithdraw(balance : uint256, amount : uint256) -> Option(uint256) {\n match balance >= amount {\n | False => return None;\n | True => return Some(balance - amount);\n }\n}\n\nNone is (false, <unused>) and Some(x) is (true, x), occupying two stack\nslots. The function returns both:\nfunction usr$tryWithdraw(balance, amount) -> _result_tag, _result_payload {\n let cond\n cond := iszero(lt(balance, amount)) // balance >= amount\n switch cond\n case false {\n _result_tag := false\n }\n case true {\n _result_tag := true\n _result_payload := sub(balance, amount)\n }\n}\n\nFor isFinished, an N-ary sum with four constructors:\nfunction isFinished(state : AuctionState) -> Bool {\n match state {\n | NotStarted(_) => return False;\n | Active(_, _) => return False;\n | Ended(_, _) => return True;\n | Cancelled(_, _) => return True;\n }\n}\n\nfunction usr$isFinished(state_tag, state_f0, state_f1) -> _result {\n switch state_tag\n case 0 { _result := false } // NotStarted\n case 1 { _result := false } // Active\n case 2 { _result := true } // Ended\n case 3 { _result := true } // Cancelled\n}\n\nThis is the same code you would write by hand if you were implementing a tagged\nunion in Yul directly. This machinery (the ADT definition, the exhaustiveness\ncheck, the pattern matrix compilation) adds zero instructions to the final\nbytecode.\nConclusion\nCore Solidity's algebraic data types and pattern matching address a class of\nsmart contract bugs that Classic Solidity has no good defense against: the\nsilent handling of missing or newly-added cases.\nThe problems are structural. When a contract's logic depends on a set of\nalternatives such as payment types, auction phases, token standards, and vote\noutcomes, Classic Solidity provides enums and structs, but it cannot enforce\nthat every function that dispatches on that type handles all cases, or that\nevery variant carries the right fields and no others. Developers fill the gap\nwith runtime require checks and a discipline of adding cases everywhere. That\ndiscipline is not enforced by the compiler, so it can and does fail, usually at\nthe worst possible moment.\nAlgebraic data types fix the representation: each constructor carries exactly\nits own fields, and a value of the sum type cannot be in an incoherent state.\nPattern matching fixes the dispatch: the compiler verifies statically that every\ncase is covered and that no branch is dead code.\nThe result is better safety at no runtime cost. The generated Yul is the same\nswitch on a tag word that a careful developer would write by hand. The\nexhaustiveness and redundancy checks happen entirely at compile time and\ndisappear from the bytecode. And the entire category of \"did you handle the new\nenum case everywhere?\" becomes a compiler error rather than an audit finding.Previous postNext post","tokens":4832,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791265998462,"hash":"f52ae9c69df5e9bc4a92098852130207ed0f6fc1"}
{"url":"https://docs.base.org/terms-of-service","domain":"docs.base.org","title":"Terms of Service - Base Documentation","text":"Sequencer, Testnet, Basenames Interface, Dashboard Terms\nLast Updated: April 08, 2026\nWe’re excited you’re interested in Base, a layer-two optimistic rollup on the Ethereum public blockchain. While we do not control Base, these Terms of Service (“Terms”) constitute a legally binding contract made between you and Coinbase Technologies, Inc. (“Coinbase,” “we,” or “us”) that governs your access to and use of the Coinbase Sequencer, Base Testnet, Basenames Interface, Basenames Profile Pages, and Dashboard, each of which is defined below (collectively, the “Services”). By using the Services in any way, you agree to be bound by these Terms. If you do not accept the terms and conditions of these Terms, you are not permitted to access or otherwise use the Services.\nBEFORE WE INCLUDE ANY OTHER DETAILS, WE WANT TO GIVE YOU NOTICE OF SOMETHING UP FRONT: BY AGREEING TO THESE TERMS, YOU AND WE AGREE TO RESOLVE ANY DISPUTES WE MAY HAVE WITH EACH OTHER VIA BINDING ARBITRATION OR IN SMALL CLAIMS COURT (INSTEAD OF A COURT OF GENERAL JURISDICTION), AND YOU AGREE TO DO SO AS AN INDIVIDUAL (INSTEAD OF, FOR EXAMPLE, AS A REPRESENTATIVE OR MEMBER OF A CLASS IN A CLASS ACTION). TO THE EXTENT THAT THE LAW ALLOWS, YOU ALSO WAIVE YOUR RIGHT TO A TRIAL BY JURY. FOR MORE INFORMATION, SEE OUR ARBITRATION AGREEMENT IN APPENDIX 1 BELOW “SEQUENCER, TESTNET, BASENAMES INTERFACE, AND DASHBOARD TERMS ARBITRATION AGREEMENT.”\n\n​Base and Bridging Smart Contracts\n\nThe Base protocol (“Base”) is an open source, optimistic rollup protocol that operates with the Ethereum blockchain. The Base protocol includes protocol smart contracts that allow you to “bridge” (i.e., lock assets on one blockchain protocol and replicate them on another protocol) digital assets between Ethereum, Base, and other compatible networks (e.g. Solana) (“Bridging Smart Contracts”). Neither Base, the Bridging Smart Contracts, nor any associated cross-chain oracle, verification services or other infrastructure (each an “Independent Infrastructure Provider”) are part of the Services. Independent Infrastructure Providers operate through open source software such as the OP Stack and other publicly available codebases, and a set of smart contracts that are not controlled by Coinbase (even if Coinbase contributed to their initial development or verification infrastructure). Coinbase does not control what third parties may build on Base, the activity of such parties, any user transacting on Base, or any data stored on Base itself, and Coinbase does not take possession, custody, or control of any virtual currency or other digital asset on Base or bridged through the Bridging Smart Contracts, unless expressly stated in a written contract signed by Coinbase.\nCoinbase controls only its own verification key and does not control or operate the keys, signatures, smart contracts, or off-chain infrastructure maintained by any Independent Infrastructure Provider. Coinbase’s permissions are non-custodial and limited to protocol maintenance.\nYou acknowledge and agree that Coinbase makes no representations or warranties with respect to Base or the Bridging Smart Contracts, and that, if you use Base or the Bridging Smart Contracts, you do so at your own risk.\n\n​Basenames\n\nBasenames is an open source blockchain-based naming protocol that maintains a registry of all domains and subdomains on Base through a series of smart contracts deployed on Base. Basenames is not part of the Services. Users may, through interacting with the Basenames, search such registry, register domains and subdomains and manage their registered names, including by adding metadata and other information (e.g., URLs) to the corresponding text records on the Basenames smart contract (such metadata and other information, the “Basename Profile Information”). The Basenames interface located at https://base.org/names (the “Basenames Interface”) is one, but not the exclusive, means of accessing Basenames. You are responsible for conducting your own diligence on other interfaces enabling you to access Basenames to understand the fees and risks that they present.\nYou understand that anyone can register and own a domain name (and its subdomains) that is not already registered on the registry maintained by Basenames. You further understand that names registered on the registry maintained by Basenames may expire and you are responsible for monitoring and renewing the registration of such names. You acknowledge that Coinbase is not able to forcibly remove, prevent or otherwise interfere with the ability of any person to register a domain name on the registry operated by Basenames and you hereby acknowledge that Coinbase will not be liable for any claims or damages whatsoever associated with your use, inability to use any domain names subject of registration, or to be registered, on the registry maintained by Basenames.\nYou agree that Basenames is purely non-custodial, meaning you are solely responsible for the custody of the cryptographic private keys to the digital asset wallets you hold and use to access Basenames.\n\n​Dashboard\n\nDashboard is a developer platform available to developers and builders of certain applications deployed on Base. Dashboard allows developers to verify ownership of their application on Base, and, upon verification, receive access to data specific to such application, submit application metadata and content, and access developer tools and application programming interfaces (“APIs”). Verification may require specific actions on third-party platforms and is determined in Coinbase’s sole discretion. You may be required to create an account and satisfy other registration requirements to use Dashboard, and you agree to comply with all applicable terms of use. We reserve the right to suspend or terminate your access to Dashboard at any time if you provide inaccurate, untrue, or incomplete information, or if you fail to comply with these terms or any other applicable terms of use.\nAll analytics, rankings, or other information surfaced via Dashboard are furnished for informational purposes only and must not be relied upon to make investment, legal, or other decisions.\nBy using Dashboard, you agree to provide accurate and complete information during the registration and verification process. When you verify a smart contract or application, you represent and warrant that you possess full ownership, authority, and control of such smart contract or application. You acknowledge that providing false or misleading information may result in the termination of your access to Dashboard. You are responsible for all use that occurs under your Dashboard account, including any activities by you or any third parties that have access to your account information whether authorized or not.\nYou will not make any statement regarding (i) your use of the Dashboard which suggests partnership with, sponsorship by, or endorsement by Coinbase or Base or (ii) the content, data, or materials provided by Dashboard to you.\nYou grant Coinbase, its affiliates, and any third parties working with Coinbase as development partners, hosting facilities, or in similar capacities, a royalty-free, non-exclusive, worldwide, perpetual, transferable, sublicensable, irrevocable right and license to:\n\nUse your service marks, trademarks, logos, and trade names for any purpose related to Dashboard and the Services; and\n\nUse, reproduce, modify, aggregate, publish, and create derivative works from any content you submit or upload through for any purpose related to Dashboard and the Services (as defined below).\n\n​Who May Use the Services\n\nYou may only use the Services if you are legally capable of forming a binding contract with Coinbase in your respective jurisdiction which may require your parents consent if you’re not the legal age of majority (which in many jurisdictions is 18), and not barred from using the Services under the laws of any applicable jurisdiction, for example, that you do not appear on the U.S. Treasury Department’s list of Specially Designated Nationals and are not located or organized in a U.S. sanctioned jurisdiction. If you are using the Services on behalf of an entity or other organization, you agree to these Terms for that entity or organization and represent to Coinbase that you have the authority to bind that entity or organization to these Terms.\n\n​Rights We Grant You\n\nAs between you and us, Coinbase is the owner of the Services, including all related intellectual property rights and proprietary content, information, material, software, images, text, graphics, illustrations, logos, trademarks (including the Base logo, the Base name, the Coinbase logo, the Coinbase name, and any other Coinbase or Base marks), service marks, copyrights, photographs, audio, video, music, and the “look and feel” of the Services. We hereby permit you to use and access the Services, provided that you comply with these Terms. If any software, content or other materials owned or controlled by us are distributed to you as part of your use of the Services, we hereby grant you a non-sublicensable, non-transferable, and non-exclusive right and license to execute, access and display such software, content and materials provided to you as part of the Services, in each case for the sole purpose of enabling you to use the Services as permitted by these Terms. To use any parts of the contents of the Services other than for personal and non-commercial use, you must seek permission from Coinbase in writing. Coinbase reserves the right to refuse permission without providing any reasons.\n\n​Accessing the Services\n\nTo access the Services, Base, or the Bridging Smart Contracts you must connect a compatible cryptocurrency wallet software (“Wallet”). Your relationship with any given Wallet provider is governed by the applicable terms of that Wallet provider, not these Terms. You are responsible for maintaining the confidentiality of any private key controlled by your Wallet and are fully responsible for any and all messages or conduct signed with your private key. We accept no responsibility or liability to you in connection with your use of a Wallet, and make no representations and warranties regarding how the Services, Base, or the Bridging Smart Contracts will operate or be compatible with any specific Wallet. We reserve the right, in our sole discretion, to prohibit certain Wallet addresses from being able to use or engage in transactions via the Coinbase Sequencer or from using other aspects of the Services.\nAs between you and Coinbase, you retain ownership and all intellectual property rights to the content and materials you submit to the Services. But, you grant us a limited, non-exclusive, worldwide, royalty free license to use your content solely for the purpose of operating the Services (i.e., the Sequencer, and Base Testnet) for so long as we operate the Services. To avoid any doubt, this license does not allow us to use your intellectual property beyond operating the Services (e.g., in advertisements).\n\n​The Services\n\nCoinbase offers the following Services that enable you to access and interact with Base and/or the Bridging Smart Contracts:\n\nThe Sequencer: The Coinbase Sequencer is a node operated by Coinbase that receives, records, and reports transactions on Base. While The Coinbase Sequencer is, initially, the only sequencer node supporting transactions on Base, additional nodes may be provided by third parties in the future and there are other mechanisms for submitting transactions through Ethereum. The Coinbase Sequencer does not store, take custody of, control, send, or receive your virtual currency, except for receiving applicable gas fees. It also does not have the ability to modify, reverse, or otherwise alter any submitted transactions, and will not have access to your private key or the ability to control value on your behalf. We reserve the right to charge and modify the fees in connection with your use of the Coinbase Sequencer. These fees may also be subject to taxes under applicable law.\n\nBase Testnet: The Base Testnet is a test environment that allows you to build applications integrated with Base. You are permitted to access and use the Base Testnet only to test and improve the experience, security, and design of Base or applications built on Base, subject to these Terms. Base Testnet Tokens will not be converted into any future rewards offered by Coinbase. Coinbase may change, discontinue, or terminate, temporarily or permanently, all or any part of the Base Testnet, at any time and without notice.\n\nBasenames Interface: The Basenames Interface is a web application and graphical user display operated by Coinbase and located at base.org/names. It enables you to interact with Basenames by creating blockchain messages that you can sign and broadcast to Base using your Wallet. The Basenames Interface will not have access to your private key at any point.\n\nBasenames Profile Pages: Coinbase operates a web application and graphical user display (the “Basenames Profile Pages”) that renders information about all registered Basenames domains and subdomains on Base, including any Basename Profile Information associated therewith. You understand that the information displayed on the Basenames Profile Pages, including all Basename Profile Information, is stored and publicly available on the Basenames decentralized protocol. Coinbase provides the Basenames Profile Pages only as a convenience, does not have control over any of third party content appearing therein, and does not warrant or endorse, nor bear responsibility for the availability or legitimacy of, the content on or accessible from any Basenames Profile Page (including any resources, interactive features, or links to Third-Party Services (as defined below) displayed therein). When viewing any Basenames Profile Page, you should assume that Coinbase has not verified the safety or legitimacy of, any content, resources, interactive features, or links appearing on such Basenames Profile Page (including any Farcaster Frames (or other open source products that provide substantially similar functionality) rendered thereon). It is your responsibility to ensure that you fully understand the nature of any links or other interactive features that you may be able to access on a Basenames Profile Page, including any financial risks that you may be exposed to when interacting with a Third-Party Service.\n\nDashboard: Coinbase also operates a developer platform located at dashboard.base.org (the “Dashboard Interface”). Upon ownership verification, the Dashboard Interface shares certain data specific to such verified applications on Base. All data stored, shared, and collected is subject to Section 12 of these Terms. The verification of a smart contract or application to use Dashboard and the Dashboard Interface is a limited, technical process based on your actions and information you provide. You acknowledge and agree that such verification does not constitute an endorsement, audit, security guarantee, recommendation, or any form of approval by Coinbase. Coinbase makes no representations or warranties regarding the safety, quality, or legitimacy of any verified smart contract or application. Any and all analytics, data, or other information provided through the Dashboard Interface is provided on an “AS IS” and “AS AVAILABLE” basis. Coinbase does not make any representations or warranties as to the accuracy, completeness, or reliability of such data and disclaims all implied warranties with respect thereto. We may change, suspend, or discontinue Dashboard, in whole or in part, at any time without notice to you. We cannot provide a guarantee that future versions of the Dashboard Interface will be backwards compatible, and it is your responsibility to check the documentation regularly to ensure proper configuration and usage. You acknowledge that an update, modification, or termination of Dashboard may adversely affect how your application accesses or communicates with the Dashboard Interface. You are responsible for ensuring you are able to continue using Dashboard, particularly any features that are or have undocumented parts. You acknowledge that it is your responsibility to ensure that your integration and use of any Dashboard features are in conformance at all times with any instructions set forth in the then-current version of the documentation. Your continued use of the updated Dashboard will constitute your binding acceptance of such modifications. Your use of any APIs made available through Dashboard is subject to the Coinbase Developer Platform Terms of Service located at https://www.coinbase.com/legal/developer-platform/terms-of-service.\n\n​Acceptable Use\n\nYou agree that you will not use the Services in any manner or for any purpose other than as expressly permitted by these Terms. That means, among other things, you will not use the Services to do or encourage any of the following:\n\nInfringe or violate the intellectual property rights or any other rights of anyone else (including Coinbase) or attempt to decompile, disassemble, or reverse engineer the Services;\n\nViolate any applicable law or regulation, including without limitation, any applicable anti-money laundering laws, anti-terrorism laws, export control laws, end user restrictions, privacy laws or economic sanctions laws/regulations, including those administered by the U.S. Department of Treasury’s Office of Foreign Assets Control;\n\nUse the Services in a way that is illegal, dangerous, harmful, fraudulent, misleading, deceptive, threatening, harassing, defamatory, obscene, or otherwise objectionable;\n\nViolate, compromise, or interfere with the security, integrity, or availability of any computer, network, or technology associated with the Services, including using the Services in a manner that constitutes excessive or abusive usage, attempts to disrupt, attack, or interfere with other users, or otherwise impacts the stability of the Services.\n\nUse any Coinbase brands, logos, or trademarks (or any brands, logos, or trademarks that are confusingly similar) without our express prior written approval, which we may withhold at our discretion for any reason.Use any data collected from your use of Dashboard, including Coinbase data, for advertising or marketing purposes without Coinbase’s prior written approval.\n\n​Release and Assumption of Risk\n\n‍By using the Services, Base, or the Bridging Smart Contracts, you represent that you understand there are risks inherent in using cryptographic and public blockchain-based systems (including Base and any Independent Infrastructure Providers that support its operation), including, but not limited, to the Services and digital assets such as bitcoin (BTC) and ether (ETH). You expressly agree that you assume all risks associated with your access to and use of Base, the Bridging Smart Contracts, Basenames, Dashboard, and the separate Services offered by Coinbase. That means, among other things, you understand and acknowledge that:\n\nThe Base network, Bridging Smart Contracts, Basenames, Dashboard, and other Services may depend on open-source code and independent third-party infrastructure, including validation networks, oracles, and similar Independent Infrastructure Providers. These components may be subject to bugs, misconfigurations, exploits, governance actions, cyberattacks, key compromise, validator downtime, or other operational failures that could result in the irreversible loss, duplication, or devaluation of digital assets, or in failed, delayed, replayed, or censored transactions.\n\nCoinbase does not own or control any Independent Infrastructure Providers and makes no representations or warranties regarding their operation or security. Coinbase’s permissions with respect to Base are non-custodial and limited to protocol maintenance and do not grant Coinbase the ability to move, seize, or otherwise control user funds. You assume all risks associated with interacting with Base, the Bridging Smart Contracts, or any related infrastructure, and you hereby release the Coinbase Entities from any and all claims, causes of action, or damages arising out of or relating to any network, infrastructure, or smart-contract failures, exploits, pauses, or upgrades.\n\nBase may be subject to periodic upgrades. Base may implement a protocol upgrade that, if implemented, may significantly impact Base, and may introduce other risks, bugs, malfunctions, cyberattack vectors, or other changes to Base that could disrupt the operation of Base, the Bridging Smart Contracts, Basenames, Dashboard, or the Services or otherwise cause you damage or loss.\n\nIf you lose your Wallet seed phrase, private keys, or password, you might permanently be unable to access your digital assets. You bear sole responsibility for safeguarding and ensuring the security of your Wallet.\n\nYou further expressly waive and release Coinbase, its parents, affiliates, related companies, their officers, directors, members, employees, consultants, representatives, agents, partners, licensors, and each of their respective successors and assigns (collectively, the “Coinbase Entities”) from any and all liability, claims, causes of action, or damages arising from or in any way related to your use of the Services, and your interaction with Base, the Bridging Smart Contracts, any Independent Infrastructure Provider, Basenames, or Dashboard. Also, to the extent applicable, you shall and hereby do waive the benefits and protections of California Civil Code § 1542, which provides: “[a] general release does not extend to claims that the creditor or releasing party does not know or suspect to exist in his or her favor at the time of executing the release and that, if known by him or her, would have materially affected his or her settlement with the debtor or released party.”\n\nInteractions with Other Users\n\nYou are responsible for your interactions with other users on or through the Services. While we reserve the right to monitor interactions between users, we are not obligated to do so, and we cannot be held liable for your interactions with other users, or for any user’s actions or inactions. If you have a dispute with one or more users, you release us (and our affiliates and subsidiaries, and our and their respective officers, directors, employees and agents) from claims, demands and damages (actual and consequential) of every kind and nature, known and unknown, arising out of or in any way connected with such disputes. In entering into this release you expressly waive any protections (whether statutory or otherwise) that would otherwise limit the coverage of this release to include only those claims which you may know or suspect to exist in your favor at the time of agreeing to this release.\n\n​Feedback\n\nAny questions, comments, suggestions, ideas, feedback, reviews, or other information about the Services, provided by you to Coinbase, are non-confidential and Coinbase will be entitled to the unrestricted use and dissemination of these submissions for any purpose, commercial or otherwise, without acknowledgment, attribution, or compensation to you.\n\n​Privacy\n\nFor more information regarding our collection, use, and disclosure of personal data and certain other data, please see our Privacy Policy. The processing of personal data by Coinbase as a processor will be subject to any data processing agreement that you enter into with Coinbase.\n\n​Third-Party Services\n\nThe Services may provide access to services, sites, technology, applications and resources that are provided or otherwise made available by third parties (“Third-Party Services”). Your access and use of Third-Party Services may also be subject to additional terms and conditions, privacy policies, or other agreements with such third parties. Coinbase has no control over and is not responsible for such Third-Party Services, including for the accuracy, availability, reliability, or completeness of information or content shared by or available through Third-Party Services, or on the privacy practices of Third-Party Services. We encourage you to review the privacy policies of Third-Party Services prior to using such services. You, and not Coinbase, will be responsible for any and all costs and charges associated with your use of any Third-Party Services. The integration or inclusion of such Third-Party Services does not imply an endorsement or recommendation. Any dealings you have with third parties while using the Services — including if a Third-Party Service may have infringed your intellectual property rights — are between you and the third party. Coinbase will not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any Third-Party Services.\nFor avoidance of doubt, the services provided by any Independent Infrastructure Provider is a Third-Party Services. Independent Infrastructure Providers are solely responsible for their own software, key management, node operations, and any signatures or attestations they issue. Coinbase does not warrant, and expressly disclaims responsibility for, any Independent Infrastructure Provider code, infrastructure, or actions.\n\n​Additional Services\n\nWe or our affiliates may offer additional services that interact with Base, which may require you to agree to additional terms. If, while using an additional service, there is a conflict between these Terms and the additional terms covering that service, the additional terms will prevail.\n\n​Indemnification\n\nTO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAWS, YOU WILL INDEMNIFY AND HOLD THE COINBASE ENTITIES HARMLESS FROM AND AGAINST ANY CLAIMS, DISPUTES, DEMANDS, LIABILITIES, DAMAGES, LOSSES, AND COSTS AND EXPENSES, INCLUDING, WITHOUT LIMITATION, REASONABLE LEGAL AND ACCOUNTING FEES ARISING OUT OF OR IN ANY WAY CONNECTED WITH (A) YOUR ACCESS TO OR USE OF THE SERVICES, (B) YOUR VIOLATION OF THESE TERMS, OR (C) YOUR NEGLIGENCE OR WILLFUL MISCONDUCT. IF YOU ARE OBLIGATED TO INDEMNIFY ANY COINBASE ENTITY HEREUNDER, THEN YOU AGREE THAT COINBASE (OR, AT ITS DISCRETION, THE APPLICABLE COINBASE ENTITY) WILL HAVE THE RIGHT, IN ITS SOLE DISCRETION, TO CONTROL ANY ACTION OR PROCEEDING AND TO DETERMINE WHETHER COINBASE WISHES TO SETTLE, AND IF SO, ON WHAT TERMS, AND YOU AGREE TO FULLY COOPERATE WITH COINBASE IN THE DEFENSE OR SETTLEMENT OF SUCH CLAIM.\nWITHOUT LIMITING THE FOREGOING, YOU AGREE TO INDEMNIFY AND HOLD HARMLESS THE COINBASE ENTITIES FROM AND AGAINST ANY CLAIMS, LOSSES, LIABILITIES, OR EXPENSES ARISING OUT OF OR RELATED TO YOUR USE OF THE BRIDGING SMART CONTRACTS OR RELIANCE ON ANY INDEPENDENT INFRASTRUCTURE PROVIDER, INCLUDING CLAIMS BY THIRD PARTIES ALLEGING LOSS OF FUNDS, FAILED TRANSFERS, OR MISROUTED TRANSACTIONS, EXCEPT TO THE EXTENT PROHIBITED BY APPLICABLE LAW.\n\n​Warranty Disclaimers\n\nTO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, DASHBOARD, AND THE SERVICES ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS WITHOUT ANY REPRESENTATION OR WARRANTY, WHETHER EXPRESS, IMPLIED OR STATUTORY. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, COINBASE SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND/OR NON-INFRINGEMENT. THE COINBASE ENTITIES DO NOT MAKE ANY REPRESENTATIONS OR WARRANTIES THAT (I) ACCESS TO THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD WILL BE CONTINUOUS, UNINTERRUPTED, OR TIMELY; (II) THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD WILL BE COMPATIBLE OR WORK WITH ANY SOFTWARE, SYSTEM OR OTHER SERVICES, INCLUDING ANY WALLETS; (III) THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD WILL BE SECURE, COMPLETE, FREE OF HARMFUL CODE, OR ERROR-FREE; (IV) THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD WILL PREVENT ANY UNAUTHORIZED ACCESS TO, ALTERATION OF, OR THE DELETION, DESTRUCTION, DAMAGE, LOSS OR FAILURE TO STORE ANY OF YOUR CONTENT OR OTHER DATA; OR (V) THAT THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD WILL PROTECT YOUR ASSETS FROM THEFT, HACKING, CYBER ATTACK, OR OTHER FORM OF LOSS OR DEVALUATION CAUSED BY THIRD-PARTY CONDUCT.\n\n​Limitation of Liability\n\nTO THE MAXIMUM EXTENT PERMITTED BY LAW, NEITHER THE COINBASE ENTITIES NOR THEIR RESPECTIVE SERVICE PROVIDERS INVOLVED IN CREATING, PRODUCING, OR DELIVERING THE SERVICES WILL BE LIABLE FOR ANY INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOST PROFITS, LOST REVENUES, LOST SAVINGS, LOST BUSINESS OPPORTUNITY, LOSS OF DATA OR GOODWILL, SERVICE INTERRUPTION, COMPUTER DAMAGE OR SYSTEM FAILURE, INTELLECTUAL PROPERTY INFRINGEMENT, OR THE COST OF SUBSTITUTE SERVICES OF ANY KIND ARISING OUT OF OR IN CONNECTION WITH THESE TERMS OR FROM THE USE OF OR INABILITY TO USE THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD, WHETHER BASED ON WARRANTY, CONTRACT, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR ANY OTHER LEGAL THEORY, AND WHETHER OR NOT THE COINBASE ENTITIES OR THEIR RESPECTIVE SERVICE PROVIDERS HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGE, EVEN IF A LIMITED REMEDY SET FORTH HEREIN IS FOUND TO HAVE FAILED OF ITS ESSENTIAL PURPOSE.\nTO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT WILL THE COINBASE ENTITIES’ TOTAL LIABILITY ARISING OUT OF OR IN CONNECTION WITH THESE TERMS OR FROM THE USE OF OR INABILITY TO USE THE SERVICES, BASE, THE BRIDGING SMART CONTRACTS, BASENAMES, OR DASHBOARD EXCEED THE AMOUNTS YOU HAVE PAID OR ARE PAYABLE BY YOU TO THE COINBASE ENTITIES FOR USE OF THE SERVICES OR ONE HUNDRED DOLLARS ($100), WHICHEVER IS HIGHER.\nTHE EXCLUSIONS AND LIMITATIONS OF DAMAGES SET FORTH ABOVE ARE FUNDAMENTAL ELEMENTS OF THE BASIS OF THE BARGAIN BETWEEN COINBASE AND YOU.\nIF ANY PORTION OF THESE SECTIONS IS HELD TO BE INVALID UNDER THE LAWS OF YOUR STATE OF RESIDENCE, THE INVALIDITY OF SUCH PORTION WILL NOT AFFECT THE VALIDITY OF THE REMAINING PORTIONS OF THE APPLICABLE SECTIONS. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL OR CERTAIN OTHER DAMAGES, SO THE ABOVE LIMITATIONS AND EXCLUSIONS MAY NOT APPLY TO YOU.\nWITHOUT LIMITING THE FOREGOING, THE COINBASE ENTITIES SHALL HAVE NO LIABILITY FOR ANY LOSSES, DEPEGS, THEFTS, OR OTHER DAMAGES ARISING OUT OF OR RELATED TO (i) THE BRIDGING SMART CONTRACTS, (ii) ANY INDEPENDENT INFRASTRUCTURE PROVIDERS SYSTEMS, SOFTWARE, KEYS OR SIGNATURES, OR (iii) ANY BRIDGE-RELATED UPGRADES, OR MAINTENANCE ACTION OR INACTION, EXCEPT TO THE EXTENT EXPRESSLY ASSUMED IN A SEPARATE WRITTEN AGREEMENT SIGNED BY COINBASE.\n\n​Changes to Terms\n\nWe reserve the right, in our sole discretion, to change these Terms at any time and your continued use of the Services after the date any such changes become effective constitutes your acceptance of the new Terms. You should periodically visit this page to review the current Terms so you are aware of any revisions. If you do not agree to abide by these or any future Terms, you are not permitted to access, browse, or use (or continue to access, browse, or use) the Services.\n\n​Notice\n\nAny notices or other communications provided by us under these Terms, including those regarding modifications to these Terms, will be posted online, in the Services, or through other electronic communication. You agree and consent to receive electronically all communications, agreements, documents, notices and disclosures that we provide in connection with your use of the Services (collectively, the “Communications”).\n\n​Entire Agreement\n\nThese Terms and any other documents incorporated by reference comprise the entire understanding and agreement between you and Coinbase as to the subject matter hereof, and supersedes any and all prior discussions, agreements and understandings of any kind (including without limitation any prior versions of these Terms), between you and Coinbase. Section headings in these Terms are for convenience only and shall not govern the meaning or interpretation of any provision of these Terms.\n\n​Assignment\n\nWe reserve the right to assign our rights without restriction, including without limitation to any Coinbase affiliates or subsidiaries, or to any successor in interest of any business associated with the Services. In the event that Coinbase is acquired by or merged with a third party entity, we reserve the right, in any of these circumstances, to transfer or assign the information we have collected from you as part of such merger, acquisition, sale, or other change of control. You may not assign any rights and/or licenses granted under these Terms. Any attempted transfer or assignment by you in violation hereof shall be null and void. Subject to the foregoing, these Terms will bind and inure to the benefit of the parties, their successors and permitted assigns.\n\n​Severability\n\nIf any provision of these Terms is determined to be invalid or unenforceable under any rule, law, or regulation of any local, state, or federal government agency, such provision will be changed and interpreted to accomplish the objectives of the provision to the greatest extent possible under any applicable law and the validity or enforceability of any other provision of these Terms shall not be affected.\n\n​Termination; Survival\n\nWe may suspend or terminate your access to and use of the Services at our sole discretion, at any time and without notice to you. Upon any termination, discontinuation or cancellation of the Services, Sections 8 through 28 of the Terms will survive.\n\n​Governing Law\n\nYou agree that the laws of the State of California, without regard to principles of conflict of laws, will govern these Terms and any Dispute, except to the extent governed by the Federal Arbitration Act or other applicable federal law.\n\n​Force Majeure\n\nWe shall not be liable for delays, failure in performance or interruption of service which result directly or indirectly from any cause or condition beyond our reasonable control, including but not limited to, significant market volatility, act of God, act of civil or military authorities, act of terrorists, civil disturbance, war, strike or other labor dispute, fire, interruption in telecommunications or Internet services or network provider services, failure of equipment and/or software, pandemic, other catastrophe or any other occurrence which is beyond our reasonable control and shall not affect the validity and enforceability of any remaining provisions.\n\n​Non-Waiver of Rights\n\nThese Terms shall not be construed to waive rights that cannot be waived under applicable laws, including applicable state money transmission laws in the state where you are located. In addition, our failure to insist upon or enforce strict performance by you of any provision of these Terms or to exercise any right under these Terms will not be construed as a waiver or relinquishment to any extent of our right to assert or rely upon any such provision or right in that or any other instance.\n\n​Relationship of the Parties\n\nCoinbase is an independent contractor for all purposes. Nothing in these Terms is intended to or shall operate to create a partnership or joint venture between you and Coinbase, or authorize you to act as agent of Coinbase. These Terms are not intended to, and do not, create or impose any fiduciary duties on us. To the fullest extent permitted by law, you acknowledge and agree that we owe no fiduciary duties or liabilities to you or any other party, and that to the extent any such duties or liabilities may exist at law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and foregone. You further agree that the only duties and obligations that we owe you are those set out expressly in these Terms.\n\n​Dispute Resolution, Arbitration Agreement, Class Action Waiver, And Jury Trial Waiver\n\nIf you have a dispute with us, you agree to first contact Coinbase Support via our Customer Support page (https://help.coinbase.com). If Coinbase Support is unable to resolve your dispute, you agree to follow our Formal Complaint Process. You begin this process by submitting our complaint form. If you would prefer to send a written complaint via mail, please include as much information as possible in describing your complaint, including your support ticket number, how you would like us to resolve the complaint, and any other relevant information to us at 82 Nassau St #61234, New York, NY 10038. The Formal Complaint Process is completed when Coinbase responds to your complaint or 45 business days after the date we receive your complaint, whichever occurs first. You agree to complete the Formal Complaint Process before filing an arbitration demand or action in small claims court.\nDisputes with Users Who Reside in the United States or Canada\nIf you reside in the United States or Canada, and if you have a dispute with us or if we have a dispute with you, the dispute shall be resolved through binding arbitration or in small claims court pursuant to the Arbitration Agreement in Appendix 1 below.\n\nYou and Coinbase agree that, except as specified in the Batch Arbitration Provision set forth above, each of us may bring claims against the other only on an individual basis and not on a class, representative, or collective basis or as part of a mass action (such as a mass arbitration), and the parties hereby waive all rights to bring or to participate in such actions in arbitration or in court to the maximum extent permitted by applicable law. This provision does not prevent you or Coinbase from participating in a class-wide settlement of claims. YOU AND WE AGREE TO WAIVE OUR RIGHTS TO A JURY TRIAL. To the extent that any Dispute proceeds in court, and to the maximum extent permitted by applicable law, you and we agree to waive any right to a jury trial and have such matter resolved by a judge (also known as a bench trial).\n\nDisputes with Users Who Reside Outside the United States and Canada\nIf you do not reside in the United States or Canada, the Arbitration Agreement in Appendix 1 does not apply to you and you may resolve any claim you have with us relating to, arising out of, or in any way in connection with our Terms, us, or our Services in a court of competent jurisdiction.\nAPPENDIX 1: ARBITRATION AGREEMENT\nDisputes Defined. “Disputes” are defined as any dispute, claim, or disagreement arising out of relating in any way to our relationship with you, the Services, https://www.base.org (the “Site”), any Communications you receive, any products or services sold or distributed through the Site, or these Terms. The term “Disputes” is intended to be interpreted broadly. The provisions below describe which Disputes belong in arbitration, small claims court, or a court of general jurisdiction.\nPre-Filing Formal Complaint Requirement. Before an arbitration demand or small claims action is filed, you and we agree to exhaust the Formal Complaint Process. See Section 28 above.\nArbitration Agreement. Except where prohibited by law, you and we agree to arbitrate all Disputes in binding arbitration except for the following types of Disputes:\n\nDisputes about whether the Dispute is arbitrable. You and we agree that any Disputes arising out of or related to the interpretation or application of the Arbitration Agreement, including Disputes about the enforceability, revocability, scope, or validity of the Dispute Resolution section or any portion of the Dispute Resolution section (including the Arbitration Agreement) shall be resolved in a court of competent jurisdiction, not arbitration. This includes, but is not limited to, any dispute about whether the Batch Arbitration provision applies to the Dispute.\nDisputes that are within the jurisdiction of a small claims court. You and we agree that if a Dispute could be brought in a small claims court in the county or parish in which you reside, then it must be brought in that small claims court, not arbitration, provided that it remains in that court and is not removed or appealed to a court of general jurisdiction.\nDisagreements about whether a Dispute is within the jurisdiction of a small claims court. You and we agree that any disagreement about whether a Dispute is within the jurisdiction of a small claims court will be resolved by the small claims court in the first instance. Disagreements about whether a Dispute is within the jurisdiction of a small claims court may otherwise be resolved in a court of competent jurisdiction, but only after you or we have exhausted resolution from the small claims court.\nDisputes about or related to infringement or misuse of intellectual property (“IP”) rights (e.g., trademarks, trade dress, domain names, trade secrets, copyrights, and patents). You and we agree that you or Coinbase must resolve IP Disputes outside of arbitration (e.g., in a court of competent jurisdiction). This means, for example, if you have a Dispute that contains an IP cause of action, which is not arbitrable under this agreement, and other causes of action that are arbitrable, then the arbitrable causes of action must proceed in arbitration and the IP cause of action must proceed outside of arbitration consistent with these Terms. You and we agree that all IP Disputes shall not be stayed solely on the grounds that there exists a pending arbitration of arbitrable causes of action.\nDisputes about whether you or we have violated state or federal securities laws. In the event that there is a Dispute about whether you or we have violated state or federal securities laws, you and we agree that such Disputes shall be resolved by a court of competent jurisdiction. This means, for example, if you have a Dispute that contains causes of action under the state or federal securities laws and other causes of action that are arbitrable, then the arbitrable causes of action must proceed in arbitration and the state or federal securities laws causes of action must proceed in a court of competent jurisdiction.\n\nArbitration Procedure. You and we agree that arbitration under this Arbitration Agreement will, depending on the circumstance, be administered by the American Arbitration Association (“AAA”) subject to the AAA’s Consumer Arbitration Rules then in effect, except as modified by this Arbitration Agreement. If the AAA is unable or unwilling to administer the arbitration consistent with the Arbitration Agreement, or if the Dispute is part of a Batch Arbitration, you and we agree that JAMS will administer the arbitration subject to the JAMS Rules and Procedures then in effect, including any Mass Arbitration Procedures and Guidelines applicable to the Dispute, except as modified by this Arbitration Agreement. You and we agree that if JAMS is unable or unwilling to administer the arbitration consistent with the Arbitration Agreement, and the parties cannot agree on an alternative provider that will do so, then you or we may petition a court of competent jurisdiction to appoint an administrator that will do so. The AAA and JAMS rules are available at https://adr.org/Rules and https://www.jamsadr.com/adr-rules-procedures/. You and we agree that these Terms evidence a transaction involving interstate commerce and notwithstanding any other provision with respect to the applicable substantive law, the Federal Arbitration Act, 9 U.S.C. § 1 et seq. and federal arbitration law (not state arbitration law) will govern any proceedings regarding enforcement of this Arbitration Agreement. Any applicable limitations periods (including statutes of limitations) shall apply in arbitration like in court. You and we agree that an arbitral award shall have no preclusive effect in any other proceeding involving other Users. You and we (and your and our counsel, if represented) agree to work together in good faith to ensure that arbitration remains efficient and cost-effective for all parties. The arbitrator shall have the authority to award sanctions against parties and their counsel consistent with the standard set forth in Federal Rule of Civil Procedure 11.\nSeverability. You and we agree to sever arbitrable Disputes (which shall be resolved in arbitration) from Disputes that are not arbitrable (which shall be resolved in court); you and we also agree that if any provision of this Arbitration Agreement is found unenforceable, then that portion of the Arbitration Agreement shall be severed and the remainder of the Arbitration Agreement shall continue to control. Notwithstanding the foregoing, if the “Batch Arbitration” provision would otherwise apply to the Dispute, but a court of competent jurisdiction determines that the “Batch Arbitration” provision is unenforceable as to the Dispute or a portion of the Dispute (and all appeals have been exhausted or the ruling is otherwise final) or JAMS or a JAMS arbitrator refuses to apply all of the provisions of the Batch Arbitration provision as written, then the affected Dispute or portion of the Dispute cannot proceed in arbitration and may proceed in a court of competent jurisdiction consistent with the other provisions of these Terms unless the parties agree otherwise in writing.\nConfidentiality. You and we agree that any information exchanged between us in an arbitration may be used solely for that arbitration. You and we agree that we may not, for example, use information you or we obtained from the other party in one arbitration proceeding in another arbitration proceeding. You and we also agree to keep any information exchanged between us in any arbitration proceeding confidential between us, you, your and our attorneys, and the arbitrator. To the extent additional persons require access to information exchanged for purposes of the arbitration, you and we agree to negotiate in good faith for the entry of a protective order that will impose similar confidentiality obligations.\nArbitrator Appointment. Any arbitrator appointed under the Arbitration Agreement will be selected by the parties from the AAA or JAMS’s roster of arbitrators. If the matter is proceeding before JAMS, then you and we agree that the arbitrator shall be appointed in accordance with JAMS’s strike and rank process set forth in Rule 15 of the Comprehensive Arbitration Rules & Procedures. If the matter is proceeding before AAA, you and we agree that the arbitrator will be appointed through a strike and rank process consistent with the approach taken by JAMS in Rule 15 of the Comprehensive Arbitration Rules & Procedures.\nAttorneys’ Fees and Costs. The parties shall bear their own attorneys’ fees and costs in arbitration unless the arbitrator finds that either the substance of the Dispute or the relief sought in the Dispute was frivolous or was brought for an improper purpose (as measured by the standards set forth in Federal Rule of Civil Procedure 11(b)). If you or Coinbase need to invoke the authority of a court of competent jurisdiction to compel arbitration, then the party that obtains an order compelling arbitration in such action shall have the right to collect from the other party its reasonable costs, necessary disbursements, and reasonable attorneys’ fees incurred in securing an order compelling arbitration. The prevailing party in any court action relating to whether either party has satisfied any condition precedent to arbitration, including the Formal Complaint Process, is entitled to recover their reasonable costs, necessary disbursements, and reasonable attorneys’ fees and costs.\nWaiver of Class, Collective, Representative, Mass Actions, and Other Non-Individualized Relief. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, YOU AND COINBASE AGREE THAT, EXCEPT AS SPECIFIED IN THE BATCH ARBITRATION PROVISION SET FORTH BELOW, EACH OF US MAY BRING CLAIMS AGAINST THE OTHER ONLY ON AN INDIVIDUAL BASIS AND NOT ON A CLASS, REPRESENTATIVE, OR COLLECTIVE BASIS, AND THE PARTIES HEREBY WAIVE ALL RIGHTS TO HAVE ANY DISPUTE BE BROUGHT, HEARD, ADMINISTERED, RESOLVED, LITIGATED, OR ARBITRATED ON A CLASS, COLLECTIVE, REPRESENTATIVE, OR MASS ACTION (SUCH AS A MASS ARBITRATION) BASIS. ONLY INDIVIDUAL RELIEF IS AVAILABLE, AND DISPUTES OF MORE THAN ONE CUSTOMER OR USER CANNOT BE ARBITRATED, LITIGATED, OR CONSOLIDATED WITH THOSE OF ANY OTHER CUSTOMER OR USER. Subject to this Arbitration Agreement, the arbitrator may award declaratory or injunctive relief only in favor of the individual party seeking relief and only to the extent necessary to provide relief warranted by the party’s individual claim. Notwithstanding anything to the contrary in this Arbitration Agreement, if a court decides by means of a final decision, not subject to any further appeal or recourse, that the limitations of this provision entitled “Waiver of Class, Collective, Representative, Mass Actions and Other Non-Individualized Relief,” are invalid or unenforceable as to a particular claim or request for relief (such as a request for public injunctive relief), you and Coinbase agree that that particular claim or request for relief (and only that particular claim or request for relief) shall be severed from the arbitration and may be litigated in a court of competent jurisdiction consistent with the other terms of these Terms. This provision does not prevent you or Coinbase from participating in a class-wide settlement of claims.\nBatch Arbitration. You and we agree to abide by this Batch Arbitration provision in the event that: (a) there are twenty-five (25) or more individual arbitration demands of substantially similar nature filed by us against you and other customers or by you and others against us and (b) such arbitration demands are filed with the assistance of the same law firm, group of law firms, or organizations. You and we agree that arbitration demands will not be deemed “substantially similar” if they involve claims seeking relief in connection with alleged losses of assets arising from different facts and circumstances. Arbitration demands that trigger the application of this Batch Arbitration provision can be administered in arbitration only pursuant to the provisions of this Batch Arbitration Provision. See Severability, above.\n\nIf this Batch Arbitration provision is triggered, then JAMS shall:\n\nadminister the arbitration demands in batches;\nappoint a single, different arbitrator for each batch unless the parties agree otherwise; and\nprovide for the resolution of each batch as a single consolidated arbitration with one set of filing and administrative fees due per side per batch, one procedural calendar, one in-person or video hearing (if any) in a format to be determined by the arbitrator that shall be convenient for the parties. You and we agree that if the Dispute is subject to this Batch Arbitration process, you will personally appear at any hearing (with counsel, if you are represented).\n\nThe number of batches will depend on the number of arbitration demands that were filed. The batching methodology is set forth below:\n\nIf there are more than 25 but fewer than 2,000 arbitrations, then there will be 20 batches.\nIf there are 2,000 or more arbitrations, then they will be batched into batches of 100 arbitrations per batch.\nIn deciding which arbitration demands will go in which batch, JAMS shall make the batches as equal as possible in terms of cumulative amount demanded and number of arbitration demands.\n\nYou and Coinbase (and your and our counsel, if represented) agree to cooperate in good faith with JAMS to implement the Batch Arbitration process including the payment of single filing and administrative fees for each Batch, as well as any steps to minimize the burdens and costs of arbitration. You and CBTL (and your and our counsel, if represented) agree to work together in good faith throughout the Batch Arbitration process to streamline procedures, modify the number of arbitrations to proceed per batch as appropriate, increase efficiencies, and seek to resolve Disputes.\nYou and we agree that arbitrations administered pursuant to this Batch Arbitration provision may be administered concurrently to the extent administratively feasible.\nArbitrators appointed pursuant to this Batch Arbitration provision shall issue separate awards for each CBTL User involved in a batched proceeding.\nThis Batch Arbitration provision shall in no way be interpreted as authorizing a class, collective and/or mass arbitration or action of any kind, or arbitration involving joint or consolidated claims under any circumstances, except as expressly set forth in this provision.\n\nModification. If we make any updates to the Arbitration Agreement, we will make the updated terms available to you by publishing them on the Site. Your continued use of the Site and/or Services, including the acceptance of products and services offered on the Site following the posting of changes to this Arbitration Agreement constitutes your acceptance of any such changes.Was this page helpful?Suggest editsRaise issue","tokens":13275,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266000413,"hash":"267a84821faba41368185dfaf9e6b8fb7691cc9f"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/24","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 24 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n Load more posts below","tokens":2748,"squid":"ink-research","role":"Deep Scholar","at":1791266003326,"hash":"5edc47b214693b0c3a0327dd311e8bef2542f7f2"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/27","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 27 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n Load more posts below","tokens":2663,"squid":"ink-research","role":"Deep Scholar","at":1791266013509,"hash":"5aacab30708a7533dca115e2b20b9e63a045b482"}
{"url":"https://www.soliditylang.org/blog/category/announcements/","domain":"soliditylang.org","title":"Blog: Announcements | Solidity Programming Language","text":"{Solidity:​log}All announcement postsPattern Matching in Core SolidityPosted by Solidity Team on May 5, 2026Announcements\nSmart contracts often need to handle values that come in several variants: a\npayment might be native ETH, an ERC20 transfer, or an NFT transfer; an auction\ncan be not-started, active, ended, or cancelled. Each variant needs different\nhandling, and the logic for that handling tends to be scattered across many\nfunctions. When a developer adds a new variant and forgets to update one of\nthose functions, the compiler says nothing. Once deployed, that oversight can\ncost real money to find and fix.\n\nCore Solidity's algebraic data...Read moreSolidity Developer Survey 2025 ResultsPosted by Solidity Team on April 15, 2026Announcements\nThe Solidity Developer Survey 2025, our sixth annual survey, collected 1,095 responses from developers across 87 countries. Thank you to everyone who participated. This post covers the key findings. For the complete data, see the interactive results page.\n\nWho responded\n\nWhere do you live?\n\n70% of respondents are smart contract developers. 12% are auditors or security experts. 18% identified as students. Half of all respondents have two years or less of Solidity experience, and 49% use Solidity daily.\n\nThe top three countries are India...Read moreAnnual Solidity Developer Survey is Live!Posted by Jacob Czepluch on February 10, 2026Announcements\nThe annual Solidity Developer Survey is now live, and we need your input!\n\nTake 5 minutes to share your experience and help us prioritize language design, performance improvements, and developer experience enhancements for the year ahead.\n\nWe're already working on frequently requested features like eliminating stack-too-deep errors, performance optimization, and stronger debugging tooling – with delivery targeted for H1 2026. Your feedback will help us refine priorities and identify what matters most.\n\nCheck out our latest roadmap update: 2026 Argot Roadmap Update\n\n📝 Take...Read moreSolidity Summit 2025 RecapPosted by Solidity Team on December 4, 2025Announcements\nThe 2025 edition of the Solidity Summit took place in Buenos Aires during Devconnect, gathering around 350 participants from across the ecosystem. The event brought together language designers and compiler engineers - but also tooling authors, security experts, educators, and long-time Solidity power users. Attendees had the chance to get up to speed with the latest language proposals and new features, hear updates from the ecosystem, and learn from teams building on Solidity at scale.\n\nA central message from the Solidity...Read moreCore Solidity Deep DivePosted by Solidity Team on November 14, 2025Announcements\nSolidity is the most widely used smart contract language. It is robust, trustworthy, and today\nsecures hundreds of billions of dollars of value. We are proud of this success, and its track\nrecord of secure code generation. Users of Solidity will however be keenly aware of some of its\nlimitations. The type system often lacks the expressiveness to produce reusable library code or\nenforce core safety properties. The language has very limited support for compile time evaluation.\nMany features are implemented in an inconsistent manner,...Read moreThe Road to Core SolidityPosted by Solidity Team on October 21, 2025Announcements\nThe Road to Core Solidity\n\nSolidity has just reached its 10-year mark.\nThis is a perfect opportunity for us to present \"The Road to Core Solidity\", a series of blog posts through which we share where we are headed with the language.\n\nIn this series we want to show the community how we see the project's roadmap in the long run.\nWhile we are quite confident about its general direction, many details are not set in stone.\nIt is as much a presentation of what...Read moreSolidity Summit 2025: Hola Argentina!Posted by Vishwa Mehta on August 26, 2025Announcements\nThe Solidity Summit has returned! Following the successful organisation of Solidity Summit 2023 in Türkiye, we are pleased to announce another in-person edition of the event in 2025.\n\nSolidity Summit 2025 will be a part of DevConnect this year and will take place on Tue, 18 Nov, 2025 in Buenos Aires, Argentina.\n\nWhat can you expect at Solidity Summit 2025?\n\nThe Solidity Summit is a collaborative conference that focuses on Solidity's future. It is a gathering of advanced Solidity users and other Solidity...Read moreSolidity Developer Survey 2024 ResultsPosted by Vishwa Mehta on April 25, 2025Announcements\nWe are thrilled to share the Solidity Developer Survey 2024 results with you! In this blog post, we will be going over key insights and a detailed analysis of the various sections of the survey.\n\nBefore diving in, we would like to thank everyone who submitted a response to the survey and helped us reach the right audience for it. Your inputs are invaluable to us and are pivotal in driving important language design decisions and improving Solidity as an open-source...Read moreSolidity Developer Survey 2024 is Live!Posted by Vishwa Mehta on December 27, 2024Announcements\nBefore we wrap up the 2024 season, we have one last announcement! 🚀\n\nThe annual Solidity Developer Survey for the year 2024 is live! Take the survey to give us insights and feedback to help us design the Solidity compiler better.\n\n📝 TAKE THE SURVEY! 📝\n\nYou can find the results of the previous Solidity Developer Survey here. In 2023, a total of 474 developers from 71 different countries participated in the survey out of which 46.5% used Solidity daily, and 33.2% weekly.\n\nAbout...Read moreAnnouncing the Winners of the Underhanded Solidity Contest 2024Posted by Vishwa Mehta & USC Judges on October 14, 2024Announcements\nIf you have been waiting for the results of the Underhanded Solidity Contest 2024, the countdown is over!\n\nBut before we share our insights from this year and declare the results, let's recap the most important aspects of the USC:\n\nIn essence, the Underhanded Solidity Contest is about writing seemingly innocent code that has malicious mechanisms or hidden backdoors. It is aimed at:\n\nRaising awareness about smart contract security\nUncovering language design faults\nBattle-testing newly introduced language features and restrictions\nHighlighting anti-patterns in smart contact development\nEstablishing...Read moreUnderhanded Solidity Contest 2024 AnnouncementPosted by Vishwa Mehta on July 31, 2024Announcements\nThe Underhanded Solidity Contest is back with a bang in 2024!\n\nAfter two successful seasons of the contest in 2020 and 2022 inspired by the first edition in 2017, we’re back with an exciting challenge for this year.\n\nBefore we dive into the 2024 theme, let's do a quick refresher on what the Underhanded Solidity Contest is.\n\nThe Underhanded Solidity Contest is about writing seemingly innocent code that has malicious mechanisms or hidden backdoors. Through this contest, we aim to:\n\nRaise awareness about smart...Read moreSolidity Developer Survey 2023 ResultsPosted by Vishwa Mehta on April 3, 2024Announcements\nEDIT REMARK: We noticed a minor error in the graphical representation of [1] popular Ethereum-specific IDEs and [2] Sourcify usage. The results in this blog post and corresponding graphical data in the slide deck has been updated to reflect this rectification that represents the survey data accurately.\n\nWe are thrilled to share with you the Solidity Developer Survey 2023 results! In this blog post, we will be going over key insights and detailed analysis of the various sections of the survey.\n\nBefore...Read moreSolidity Developer Survey 2023 is Live!Posted by Vishwa Mehta on December 8, 2023Announcements\nWe recently wrapped up Solidity Summit with a bang and have one last announcement before the end of the year!\n\nThe Solidity Developer Survey for the year 2023 is live! We would love to collect your feedback and insights regarding Solidity!\n\n📝 TAKE THE SURVEY! 📝\n\nYou can find the previous results of the Solidity Developer Survey 2022 here. In 2022, a total of 1401 developers from 100 different countries participated in the survey out of which 41% used Solidity daily, and 37.3%...Read moreSolidity Summit 2023 RecapPosted by Solidity Team on November 30, 2023Announcements\nWe can't believe it's already been two weeks since we met in Istanbul, Türkiye, for the third edition of Solidity Summit!\n\nSolidity Summit 2023 was part of the Devconnect week and took place on Thursday, November 16, 2023. With roughly 300 participants, the event was well attended.\n\nThe day was packed with 15+ sessions on:\n\nSolidity internals and tips & tricks\nSolidity tooling\nSmart contract testing & security best practices\nEVM Languages and mechanisms\n... and more!\n\nThe full agenda of the day can be found here. You...Read moreSolidity Summit 2023 Merhaba Türkiye!Posted by Solidity Team on August 7, 2023Announcements\nThe Solidity Summit has returned! Following the popularity of the Solidity Summit in 2022, we are pleased to announce a live event for 2023!\n\nSolidity Summit 2023 is part of DevConnect and will take place in Istanbul, Turkey, on Wednesday, November 16, 2023.\n\nWhat can you expect for the Solidity Summit?\n\nThe Solidity Summit is a collaborative conference that focuses on Solidity's future. It is a gathering of advanced Solidity users and other Solidity ecosystem stakeholders such as language designers, tool builders, auditors,...Read moreSolidity Developer Survey 2022 ResultsPosted by Franziska Heintel on March 10, 2023Announcements\nThe 2022 Solidity Developer Survey results are in! In this post, we will be summarizing and analyzing them.\n\nFirst of all, a big thank you to everybody who took the time and participated and to everybody who helped us spread the word about it!\nThis year, we received a smashing 1401 responses. That is more than a 3x in responses compared to the previous survey and we couldn't be happier with the turnout.\nYour input is invaluable to us and plays a crucial...Read moreSolidity Developer Survey 2022 is Live!Posted by Franziska Heintel on December 7, 2022Announcements\nIt’s that time of the year. Drumroll, please! 🥁🥁🥁\nWe are launching the Solidity Developer Survey 2022!\n\nBefore we wrap up 2022 for good, we want to reach out to collect your feedback and insights so we can improve on it!\n\n📝 TAKE THE SURVEY! 📝\n\nYou can find the previous results of the Solidity Developer Survey 2021 here. In 2021, 435 developers from 73 different countries participated with 80% of respondents using Solidity daily or weekly.\n\nAbout the Survey 🪄\n\nLike in previous years, this...Read moreSolidity Core Team UpdatesPosted by Solidity Team on December 5, 2022Announcements\nMore than two years have passed since we introduced Solidity core team members on the blog and we realized it is high time for some updates: Meet new team members, find out who moved on to other adventures and learn about recent changes in the team structure!\n\nBefore we dive in, a reminder that the Solidity programming language and compiler are open-source community projects. This post dives into the core team that leads the development. Nevertheless, we cannot stress enough how...Read moreSolidity Summit 2022 RecapPosted by Franziska Heintel on May 3, 2022Announcements\nWe can't believe it's already been two weeks since we met in Amsterdam for the second Solidity Summit!\n\nSolidity Summit 2022 was part of Devconnect and took place on Wednesday, April 20, 2022.\n\nWith roughly 250 participants, the event was well attended. In addition, approximately 400 people joined remotely by watching the Livepeer livestream.\n\nThe day was packed with 20+ talks on\n\nSolidity internals & deep dives\nSolidity language design\nSolidity tooling\nSecurity\nProgramming patterns\n\n... and more.\n\nThe full agenda of the day can be found here. You can...Read moreAnnouncing the Winners of the Underhanded Solidity Contest 2022Posted by Franziska Heintel & USC Judges on April 9, 2022Announcements\nThe time has come to share this year's winners of the Underhanded Solidity Contest!\n\nBefore we dive into the winning submissions, let's revisit the most important features of the USC:\n\nIn a nutshell, the USC is about finding loopholes or “hiding spots” in the Solidity language and using those to write seemingly innocent and straightforward-looking Solidity code which contains malicious behavior or backdoors.\n\nThe Underhanded Solidity Contest aims to...\n\nRaise awareness about smart contract security.\nUncover language design faults.\nBattle-test recently introduced language features and restrictions.\nHighlight...Read moreSolidity Summit 2022 Goes AmsterdamPosted by Franziska Heintel on February 22, 2022Announcements\nThe Solidity Summit is finally back! After a first virtual Solidity Summit in 2020, we are excited to announce an in-person event for 2022!\n\nSolidity Summit 2022 is part of Devconnect and will happen on Wednesday, April 20 2022, in Amsterdam.\n\nWhat is the Solidity Summit?\n\nThe Solidity Summit is a collaborative event focusing on the future of Solidity. It's a get together for advanced Solidity users and other Solidity ecosystem stakeholders such as developers interested in language design, tooling builders, auditors and...Read moreUnderhanded Solidity Contest 2022Posted by Franziska Heintel on February 9, 2022Announcements\nThe long wait is over: The Underhanded Solidity Contest is back with a 2022 edition!\n\nAfter a successful revival in 2020, we believe it's time for the great Solidity minds to get together again and compete over the next big underhanded hack!\n\nIn case you're new to this, let's get you up to speed with a quick recap on what the Underhanded Solidity Contest (USC) is all about:\n\nIn a nutshell, the USC is about finding loopholes or \"hiding spots\" in the Solidity...Read moreSolidity Developer Survey 2021 ResultsPosted by Franziska Heintel on February 7, 2022Announcements\nIn this post, we will be summarizing and analyzing the results of the 2021 Solidity Developer Survey.\n\nA big thank you goes out to everybody who took the time and participated!\n\nYour input is invaluable to us and plays a crucial role in helping to continuously improve the Solidity developer experience as a whole.\n\nSummary & Notable Insights\n\nSurvey Audience**: In total, 435 developers from 73 different countries participated in the 2021 survey. Compared to 2020, that is more than a 100% increase in...Read moreSolidity Developer Survey 2021 is Live!Posted by Franziska Heintel on November 18, 2021Announcements\nToday, we launched the Solidity Developer Survey 2021. Please all take 10 minutes to participate and let us know your feedback!\n\nThis marks the second time we are conducting a structured big developer survey. You can find the results of last year's Solidity developer survey here.\n\nShape the Future of Solidity 🔮\n\nThe survey helps us to further improve the Solidity language and compiler and shape the future roadmap of Solidity. We can't wait to hear your thoughts on the prioritization of new...Read moreAnnouncing Solidity Version Collectibles & Community Governance 💎Posted by Franziska Heintel on April 1, 2021Announcements\n⚠️ Attention: This post is an April Fools' Day joke. Please consume it at your own risk. We will not distribute any Solidity NFTs in the foreseeable future. Stay safe.\n\nToday, we are excited to announce a little surprise we’ve been working on silently for the last couple of weeks. We heard that you really like crypto-related collectibles and we listened.\n\nYou will soon be able to own a digital piece of Solidity’s history: We’re tokenizing each Solidity version as an NFT!...Read moreLaunching the Solidity Forum 🗃️Posted by Franziska Heintel on February 1, 2021Announcements\nIn our effort to foster exchange of information, encourage more developers to give feedback about Solidity and join the discussions on language design and future direction of the compiler, we are happy to launch the Solidity forum today!\n\nMoving forward the Solidity forum will be the dedicated place to discuss topics and questions related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nUseful Solidity tips and code snippets.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\nIt will not be the...Read moreSolidity Developer Survey 2020 ResultsPosted by Franziska Heintel on January 26, 2021Announcements\nBefore we dive into the results we want to extend a big thank you to all of the Solidity developers that participated in the very first Solidity Developer Survey, which we conducted at the end of last year!\n\nWe were overwhelmed by the high quality of the submissions and are happy to extract important insights from your input.\n\nIn this post, we'll be summarizing and commenting on the results of the survey.\n\nPlease note that none of the questions in the survey were...Read moreLaunching the Solidity Developer Survey 2020Posted by Franziska Heintel on December 9, 2020Announcements\nToday we are launching the Solidity Developer Survey 2020. It is the first time we share a proper language survey and we hope to turn this into an annual tradition moving forward.\n\nYou might remember the small feedback survey we did this year as part of the Solidity Summit registration in which we asked you for the most liked and dreaded Solidity features. If you're curious to revisit the results of that click here.\n\nHelp shape the future of Solidity 🔮\n\nSo why...Read moreAnnouncing the Winners of the Underhanded Solidity Contest 👨‍💻🏅Posted by Franziska Heintel on December 3, 2020Announcements\nAfter thorough assessment of all submissions, we are happy to share the winners of this year's Underhanded Solidity Contest!\n\nIf you are not familiar with it, please read the announcement from September.\n\nBefore we dive into the winning submissions, we'd like to thank all participants for taking part. In total, we received 16 qualifying submissions which you can find in this repo. All 16 submissions are eligible for a \"qualified submission\" Underhanded Solidity POAP NFT - winners will receive an additional \"Winners\"...Read moreAsk the Solidity Team Anything #1 RecapPosted by Solidity Team on November 4, 2020Announcements\nWe hosted our very first Solidity team AMA on Reddit last week! We would like to take the opportunity to summarize the most interesting and most upvoted questions & answers in this post.\n\nIf you are interested in going through the full AMA thread you can do so here.\n\nGeneral Questions\n\nRoadmap Outlook: What does the Solidity team see as its most important feature goals in the medium-long term and what are the biggest blockers to achieving those goals?\n\nAs far as the compiler...Read moreThe Underhanded Solidity Contest is back!Posted by Franziska Heintel on September 21, 2020Announcements\nWe're excited to share that the Underhanded Solidity Contest is finally back!\n\nInspired by the Underhanded C Contest and the first Underhanded Solidity Contest, organized in 2017 by Nick Johnson, we decided it is time for a much needed revival.\n\nUnderhanded Solidity Contest\n\nThe goal of this contest is to write innocent-looking Solidity code, which pretends to be clear and straightforward, but actually contains malicious behavior or backdoors.\n\nBy hosting such a contest we aim to:\n\nRaise awareness about smart contract security.\nUncover language design flaws.\nBattle-test...Read moreMeet the Solidity team! 🧑‍💻👩‍💻Posted by Solidity Team on September 18, 2020Announcements\nAs you might know, Solidity is an open-source community project mainly developed and maintained by a core team.\n\nToday, we would like to introduce some of our team members and share insights into their professional background, which components of Solidity they mostly work on, what they would like to see in Solidity and in the ecosystem in future and more! Since almost all of our work happens on Github you can find each team member's Github handle next to their name.\n\nBefore...Read moreSolidity v0.1.0 turns 5! A walk down memory lane...Posted by Franziska Heintel on July 8, 2020Announcements\nSolidity v0.1.0 turns 5\n\nWith happiness and a tad of nostalgia, we'd like to share that Solidity v0.1.0 turns 5 years old today! (To be fair, v0.1.0 wasn't an actual release, but it marks the time where the Solidity team started appointing version numbers.) We are puzzled over how fast time flew by. We'd like to use this opportunity to take a look back and walk down the Solidity memory lane together with you.\n\nIn short: The Solidity language evolved rapidly, the...Read moreWrapping up the Virtual Solidity Summit 2020Posted by Franziska Heintel on June 9, 2020Announcements\nRoughly one month ago, we held the first Solidity Summit - a free interactive forum with discussions and talks on Solidity, Yul, language design and tooling. It took place on April 29-30 and was powered by a virtual meeting infrastructure based on open-source, self-hosted Jitsi video chat rooms. The platform was supplied by Interspace.Chat.\n\nBefore we dive into the recap: Your input and active participation was much appreciated and we want to take this opportunity to say thank you! We hope...Read moreSourcify: Towards Safer Contract Interaction for HumansPosted by Edi Sinovčić, Franziska Heintel on June 2, 2020Announcements\ntl;dr: Building sensible blockchain applications for humans is hard. You can enhance the user experience of\nyour dapp today by leveraging the power of open source. Increase awareness and give more transparency on what users\nare actually doing when interacting with your code on the blockchain, i.e. when signing a transaction, by publishing\nthe source code to this decentralized repository and using metadata files, which translate “random” hex strings into\nhuman-readable language. Sourcify is a tool to help you do exactly that. If you...Read moreSolidity Summit 2020 Goes InterspacePosted by Franziska Heintel on April 17, 2020Announcements\nTl;dr: As already announced on Twitter, we transformed the Solidity Summit, which was initially planned to be an in-person meeting in Berlin, into an online event. Today, we are excited to share that the summit will be powered by Interspace.Chat. Interspace is a virtual meeting infrastructure based on self-hosted Jitsi video chat rooms. Check out the Solidity Summit's preliminary event agenda here and make sure to register if you want to partipate!\n\nWhat is the Solidity Summit?\n\nThe Solidity Summit is a...Read moreDev Update: Formal MethodsPosted by Christian Reitwiessner on September 1, 2016Announcements\nThis post was originally published on the Ethereum blog.\n\nToday, I am delighted to announce that Yoichi Hirai (@pirapira on github) is joining the Ethereum project as a formal verification engineer. He holds a PhD from the University of Tokyo on the topic of formalizing communicating parallel processes and created formal verification tools for Ethereum in his spare time.\n\nIn his own words:\n\nI’m joining Ethereum as a formal verification engineer. My reasoning: formal verification makes sense as a profession only in a...Read more","tokens":5767,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266019741,"hash":"80b92d99e957e436de4f712a9bdfe95e76780d82"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/28","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 28 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n Load more posts below","tokens":2722,"squid":"ink-research","role":"Deep Scholar","at":1791266025791,"hash":"4a48c0d649fb99581ca70ab8f6f26d7532454216"}
{"url":"https://www.soliditylang.org/blog/2026/02/10/solidity-developer-survey-2025-announcement/","domain":"soliditylang.org","title":"Annual Solidity Developer Survey is Live! | Solidity Programming Language","text":"Annual Solidity Developer Survey is Live!Posted by Jacob Czepluch on February 10, 2026AnnouncementsThe annual Solidity Developer Survey is now live, and we need your input!\nTake 5 minutes to share your experience and help us prioritize language design, performance improvements, and developer experience enhancements for the year ahead.\nWe're already working on frequently requested features like eliminating stack-too-deep errors, performance optimization, and stronger debugging tooling – with delivery targeted for H1 2026. Your feedback will help us refine priorities and identify what matters most.\nCheck out our latest roadmap update: 2026 Argot Roadmap Update\n📝 Take the Survey!\nThe Survey Covers:\n\nDemographics and developer profiles\nTooling and usage\nDeveloper experience\nCore Solidity\nUse of AI\n\nThis is the start of a broader, ongoing feedback program with the community. Your voice matters.\nYou can find the results of the previous Solidity Developer Survey here. In 2024, a total of 1,342 developers from 89 different countries participated in the survey.\nWhy Participate?\nYour answers will directly help shape the future of the Solidity language, compiler, and surrounding tooling.\nAs a thank you, you'll have a chance to win a Devcon 8 ticket (just add your contact details at the end of the survey to enter the raffle).\nSpread the Word!\nThe more developers we can reach, the more data we will have to guide the roadmap, so please help us share the survey in your networks and reach the right audience!\nKeep an eye on the Solidity Twitter account for the announcement of the survey results.\nTake the Survey!\nThank you for helping us build a better Solidity!Previous postNext post","tokens":424,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266029711,"hash":"59d8a3091efab537ec2b6824a31bdf77a93429d6"}
{"url":"https://ethresear.ch/t/state-minimised-executions/748","domain":"ethresear.ch","title":"State-minimised executions - Sharding - Ethereum Research","text":"State-minimised executions \n\n Sharding\n\n stateless\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 1 / 27\n\n Jan 2018\n\n Mar 2018\n\n post by JustinDrake on Jan 16, 2018\n\n JustinDrake\n\n This post is a continuation of a series on stateless clients and log accumulators. For context see:\n\nHistory, state, and asynchronous accumulators in the stateless model\nA cryptoeconomic accumulator for state-minimised contracts\nBatching and cyclic partitioning of logs\nDouble-batched Merkle log accumulator\nLog shards and EMV abstraction\n\nTLDR: We detail a cryptoeconomic mechanism for EMV executions with sublinear use of the state trie. It is an alternative to cryptoeconomic accumulators with the benefit that users do not need to post collateral, and only have to push logs (the cheapest kind of onchain activity).\nConstruction\nGiven a “normal” stateful contract C we construct a state-minimised equivalent contract C’. The contract C’ has a “virtual state” maintained as follows:\n\nThe contract stores a single confirmed virtual state root at a corresponding collation height.\nUsers can push logs of the form [LOG T], called “virtual transactions”. (Log shards are an ideal substrate for such logs, providing cheap log ordering, friendly witnesses, and real-time data availability.)\nVirtual state transitions for C’ given a virtual transaction [LOG T] happen like state transitions for C given a transaction T.\nCollaterised “executors” can suggest unconfirmed virtual state roots at more recent collation heights than the current confirmed virtual state.\nWhistleblowers can challenge unconfirmed virtual state roots and engage in a TrueBit-style protocol with executors.\nWhistleblowers earn a share of the collateral of adversarial executors.\nNon-adversarial executors advance the virtual state root and are rewarded with an internal fee system that mimics coinbase rewards and/or gas.\n\nConclusion\nThe construction takes the traditional notion of a transaction and decouples data availability (via logs on log shards) and validity (via TrueBit-style cryptoeconomic execution). The end result is a state-minimised execution protocol where the cost of validation is pushed away from (onchain) validators onto (offchain) executors.\nNote also that transactions corresponding to virtual transactions can assume a stateful model for executors (as opposed to a stateless model), so virtual transactions do not need to includes witnesses. In such a setup users get both short transactions (improving upon the standard stateless model) and cheap transactions with logs (improving upon standard execution).\n\n Couldn't a token-less, data-only blockchain simulate smart contracts?\n\n Delayed state execution in practice\n\n Minimal Viable Plasma\n\n History, state, and asynchronous accumulators in the stateless model\n\n Plasma chain for offchain gas payments\n\n 9\n\n 6\n\n 3\n\n 3\n\n 3\n\n read \n\n 8\n min\n\n post by stri8ed on Jan 16, 2018\n\n stri8ed\n\n How would lite clients work in such a model?\n\n post by JustinDrake on Jan 16, 2018\n\n JustinDrake\n\nA light client would do the following steps:\n\nsync up to the header chain of the chain/shard containing C'\nquery validators for the confirmed virtual state root of C'\nquery executors (acting as fully validating nodes for C') for the virtual state of C' corresponding to the confirmed virtual state root\n\n post by stri8ed on Jan 16, 2018\n\n stri8ed\n\n So validity of a transaction would no longer be “confirmed” when it’s mined, it would need to wait till updated virtual state is committed?\nHow would another contract know if an internal transaction to C’ was executed successfully?\n\n post by JustinDrake on Jan 16, 2018\n\n JustinDrake\n\nYes.\n\nA virtual transaction of C' (a log) was executed successfully when the collation/block height corresponding to the confirmed virtual state root is greater than the height of the collation/block containing the virtual transaction.\n\n post by stri8ed on Jan 16, 2018\n\n stri8ed\n\n How can the contract be certain it’s transaction has actually been included in latest virtual state of C’, as opposed to simply being ignored due to invalidity?\n\n post by JustinDrake on Jan 16, 2018\n\n JustinDrake\n\nI see—How does one distinguish no-ops from transactions that actually change state? One idea is to require that the virtual state root be accompanied by a transaction trie root (similar to today’s Ethereum block headers). Then it’s just a matter of asking an executor for a membership or non-membership witness for the transaction in the transaction trie.\n\n post by jannikluhn on Jan 19, 2018\n\n jannikluhn\n\n What confirms unconfirmed virtual state roots? Some passage of time without successful challenges?\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nIn the proposed scheme, yes.\nAn alternative scheme is to confirm unconfirmed virtual state roots with SNARKs/STARKs. That would have the advantage that the “passage of time without successful challenges” part can be skipped.\n\n 12 days later\n\n post by cdetrio on Feb 1, 2018\n\n cdetrio\n\n JustinDrake\n\n This has been a fantastic series, I’ve followed closely for the most part but having difficulty with this one.\nHow do the executors work here?\nIf executors are stateful then aren’t we back to the same problems that motivate stateless clients (e.g. rotation of executors among shards when each shard state is huge/ever-increasing)?\nI really like the idea of a “virtual state root”, though I also imagine the shard executors being stateless, either the standard merkle trie and witnesses, or (much butter imo) via cryptoeconomic accumulators. It sounds like the virtual state serves to reassign the job of state maintenance from validators to a new role (executors). Then virtual state is an additional gadget to combine with a cryptoeconomic accumulator, rather than an alternative to replace it. I’ll try to explain the Construction as I understand it, glossing over blanks or filling them with best guesses.\n\nOld model: Validators read the stream of transactions, and execute them by reading current state from a state root (and witnesses, in a stateless client). In other words, Validators do everything, including calculate the state roots. The Collation body has a transaction list and witness list. The witnesses are rather large, supplying leaves for all accessed state.\n\nNew model: Validators only read the stream of transactions (“virtual transactions”), in the form of an ordered list of logs and log witnesses and a log accumulator (hand-wave). Validators normally do not execute transactions and do not calculate state roots, but they do write the state roots that are submitted by executors (“virtual state roots”). Executors execute transactions; they read the current state (from witnesses if stateless), calculate the new state root, and submit it to the Validators. When an adversarial Executor submits an incorrect state root, a whistleblower initiates a challenge, which is then adjudicated by the Validators. During the challenge, Executors provide the state reads (i.e. witnesses for state roots, including intermediate state roots) to the Validators. After the challenge period has passed, the state root becomes finalized/confirmed. Under normal periods (with no challenges), collation bodies are much smaller as they only contain virtual transaction logs and not the witnesses for accessed state.\n\nSo in the new model, Validators only validate the data availability of transaction logs (under normal periods without challenges). The job of transaction execution is shifted to Executors.\nGood guesses or wrong? Reemphasizing my first question, it makes sense that “virtual transactions” (ordered list of logs) don’t need witnesses because Validators don’t (normally) execute them. But the choice of stateful or stateless Executors seems orthogonal to the virtual state of a Validator. With Executors that maintain the full state, then users get short transactions (i.e. tx’s without witnesses). But that’s not improving the stateless model, its just reversing the stateless vs stateful tradeoff (bigger tx’s vs pain of an ever-growing state).\n\n post by JustinDrake on Feb 1, 2018\n\n JustinDrake\n\n Your descriptions of the “Old model” and “New model” are good! A couple things I probably should have made more explicit:\n\nThe scheme comes in two flavours, with either stateless executors or stateful executors. In either case, validators do not have to execute transactions (other than for adjudication) so there is a gas/CPU saving there. In case the executors are stateful then there is the extra saving that the logs do not have to include witnesses, and so the logs are considerably smaller (maybe around ~5x smaller).\nThe scheme is “configurably local”. That is, it can apply to a single contract, to a group of contracts within a single shard, or to a group of contracts across several shards, but not to whole shards. So the job of an executor (to validate transactions, and optionally maintain state in the stateful flavour) is local. Contrast that to the job of validators, which is global across all contracts and shards.\n\nIf executors are stateful then aren’t we back to the same problems that motivate stateless clients (e.g. rotation of executors among shards when each shard state is huge/ever-increasing)?\n\nAs noted above, the scheme is local. So an executor for a specific application will not rotate among shards. Instead, it will continuously follow the specific shards it is interested in, and filter the logs for only the relevant contracts it has to execute. Stateful executors need to have the setup to deal with the ever-growing state of a particular application, but this shouldn’t be a problem as the state growth is segregated to that single application.\nIn theory we could enshrine the scheme at the shard protocol level. In this case executors would still be local to a given shard and would not have to rotate among shards.\n\n post by MaxC on Feb 1, 2018\n\n MaxC\n\nWithout a random rotation of executors, what is to stop them from being bribed?\n\n post by JustinDrake on Feb 1, 2018\n\n JustinDrake\n\nwhat is to stop them from being bribed?\n\nThe only thing executors do is suggest virtual state roots. What kind of bribing attack are you thinking about? Let’s see:\n\nThey could maybe be bribed to not suggest virtual state roots (for slower finality) but this is an open-access model where anyone can become an executor and there are rewards for suggesting virtual state roots (and these rewards grow with the amount of unexecuted logs).\nThey could maybe be bribed to suggest invalid state roots (consensus attack) but they stand to lose their entire collateral (anyone can be a whistleblower). Because state roots shown invalid are disregarded, I don’t see any clear benefit for the briber beyond the above bribe (itself not useful).\n\n post by MaxC on Feb 1, 2018\n\n MaxC\n\n I was mainly thinking about the data availability problem. What is to stop an attacker (large group of validators, together with some normal users and a large group of executors) from creating a state root with all but one transaction valid, but withholding the transactions to create that root from the rest of the network.\nWon’t challenging these transactions be very difficult (entailing that the prover send all blocks in the chain to some independent authority)? Whistleblowers would be hard pressed to find the actual transaction that is invalid, if it indeed exists.\n\n post by MaxC on Feb 1, 2018\n\n MaxC\n\n JustinDrake\n\n Impressed with some of your constructions, very creative!\n\n post by MaxC on Feb 1, 2018\n\n MaxC\n\n JustinDrake\n\n See above posts please \n\n post by JustinDrake on Feb 2, 2018\n\n JustinDrake\n\nThe state-minimised application defines where the logs need to be pushed. A natural choice is simply to push logs in the same shard where the state-minimised application lives, which at a minimum has real-time data availability. As mentioned in the original post, a separate log shard would be an alternative substrate for such logs, providing cheap log ordering and real-time data availability.\n\nThe adjudication process only accepts as evidence logs from the log source specified in the state-minimised application. Both (stateful) shards and log shards benefit from real-time data availability, so withholding logs is not an option. Put another way, withheld logs are irrelevant by construction because they necessarily haven’t been pushed onchain. Anyone who wants to be a whistleblower has the opportunity to download all the relevant logs.\n\n 14 days later\n\n post by vbuterin on Feb 16, 2018\n\n vbuterin\n\nThis is indeed why data availability is hard. @MaxC, have you seen this post A note on data availability and erasure coding · ethereum/research Wiki · GitHub yet? It’s about erasure-coding blocks to turn a “100% availability” problem into a “50% availability” problem, which then can be probabilistically checked, plus some fraud proof mechanisms to ensure the erasure coding is correct.\n\n post by MaxC on Feb 17, 2018\n\n MaxC\n\nAh, I hadn’t seen that before- neat solution. I wonder if it could be made non-interactive.\n\n post by vbuterin on Feb 17, 2018\n\n vbuterin\n\n You can with STARKs - just attack a STARK proving that the erasure code was constructed correctly, and then any client can probabilistically check availability just by randomly sampling a few chunks.\nUnless by “non-interactive” you mean “a single proof that convinces everyone”, in which case the answer is no because the block proposer could publish just the proof without ever publishing any of the other data, and the single proof would not have enough data to reconstruct the block. Notice that this argument also applies if there is only one client in the network; so the availability check mechanism relies on at least some minimum number of other (honest) clients existing on the network, though this is an absolute number (eg. “1750 honest clients”), not a percentage (eg. “10% of clients must be honest”).\n\n Load more posts below","tokens":3492,"squid":"ink-research","role":"Deep Scholar","at":1791266036646,"hash":"dfe57a8e0345c3509f4ad93294f6c716015fcac6"}
{"url":"https://soliditylang.org/blog/2025/04/25/solidity-developer-survey-2024-results/","domain":"soliditylang.org","title":"Solidity Developer Survey 2024 Results | Solidity Programming Language","text":"Solidity Developer Survey 2024 ResultsPosted by Vishwa Mehta on April 25, 2025AnnouncementsWe are thrilled to share the Solidity Developer Survey 2024 results with you! In this blog post, we will be going over key insights and a detailed analysis of the various sections of the survey.\nBefore diving in, we would like to thank everyone who submitted a response to the survey and helped us reach the right audience for it. Your inputs are invaluable to us and are pivotal in driving important language design decisions and improving Solidity as an open-source project.\nThis year, we received a total of 684 responses. Let's start with some useful links:\n\nIn the spirit of open source, you can find all raw data of the survey results here and all graphs here.\nThis is our fifth annual survey. You can compare the 2024 results with the previous years by checking our blog posts below:\n\n2023\n2022\n2021\n2020\n\nWithout further ado, let’s dig into the 2024 results!\nSummary & Notable Insights\nThe survey consists of 6 sections, namely: [1] Demographics, [2] Dev & User Profiles, [3] Solidity Background, [4] Solidity Developer Experience, [5] Language Design, and [6] Solidity Developer Community.\nLet's look at some key insights from the summary of these various sections from the 2024 survey.\n\nDemographics: In total, 684 developers from 91 different countries participated in the 2024 survey. The highest number of respondents hail from the USA (10.8%), followed by India and Nigeria at 7.8% each. This remains consistent with last year's insights, except for Nigeria sharing the second place alongside India this year.\nDev & User Profiles: Solidity continues to be the most used language by the respondents, followed by TypeScript and JavaScript.\nA majority of Solidity experts (self-rating of 10) have been using the language for 5+ years.\nSolidity Background: 76.6% of users use Solidity as regularly as daily or weekly. Additionally, Foundry climbs to the highest used Ethereum IDEs this year with 51.1% votes.\nSolidity Developer Experience: With a majority of 66.8%, the survey participants feel that the Solidity developer experience has generally improved in the last year.\nMappings (21.8%), contracts as objects (20.4%), and modifiers (15%) continue to be the most liked Solidity features two years in a row in the exact order.\nLanguage Design: Elimination of stack-too-deep (18.2%), better debugging tools (16.9%), and gas optimisations (13.2%) rank the highest in that order among the most anticipated features/updates this year.\nSolidity Developer Community: Solidity Twitter/Mastodon replaces GitHub Releases as the most popular source used for staying up-to-date with Solidity announcements.\n\nDemographics\n⚠️ FYI - this survey has only been shared in English. Take this into account when interpreting results regarding the distribution of countries of residency and language preferences.\nWe will begin by going through the results of the first section of the survey, which covers the demographics of the survey respondents.\nIn total, 684 participants from 90 different countries participated in the 2024 survey.\nThe coverage of different geographies increased from 73 countries in 2021, to 100 countries in 2022, and then back to 71 in 2023, it has now increased to 90 countries this year. It is interesting to note a spike in the geographic diversity of the survey audience this year compared to 2023.\nResidency\nA majority of 10.8% of respondents mentioned that they live in the USA, followed by India and Nigeria at 7.8% each, and France taking over Germany this year with 3.8% votes.\nExcept for France ranking higher than Germany this year, the order of the top 5 countries of residence remains similar to 2023. However, there has been a shift in individual numbers. For instance, there's a drop in USA residents among the survey participants, whereas Nigeria has seen a spike.\nFor reference, see the world map and chart with a list of countries of residence with 13+ responses.\n\nLanguage\nIn the 2024 survey, a total of 75 languages were submitted as the native languages of the respondents.\n26% of the total participants speak English as their native language, 9.3% speak Indian languages, 8.3% speak Spanish, 6.5% speak Russian, 6.1% speak French, Portuguese, and African languages at 4.4% each, 3.7% speak German, and 2.8% speak Chinese languages.\nNote that this year, Russian has climbed up the ranks to 4th position, African languages also climbing up a bit higher than last year, whereas Chinese languages have fallen back in votes compared to 2023.\nℹ️ Note: Hindi, Urdu, Bengali, Telugu, Kannada, Tamil, Gujarati, Malayalam, and Marathi are clustered as “Indian languages”. Swahili, Hausa, Igbo, Yoruba, Luganda, Afrikaans, Kamba, Kiswahili, Malagasy, Mina, Shona, and Siswati are clustered as \"African languages\". And Cantonese, Chinese, and Mandarin are clustered as “Chinese languages”.\nIt is interesting to note that even more African languages have entered the survey results this year.\n\nAlthough an almost equal distribution this year, the percentage of participants who speak a language other than their native language at work (50.6%) is slightly higher than those who speak their native language at work (49.4%). This trend has changed compared to last year.\nA total of 76.7% of respondents reported that they predominantly speak English at work, followed by Indian languages, French, Chinese languages, Russian, Spanish, Portuguese, and more. All of these, except English, are ranked close behind each other in that order, as seen in the chart below.\n\nA total of 88% of participants stated that they are okay with reading the Solidity documentation in English. This number is slightly higher than last year.\nHowever, 12% of participants prefer to read the documentation in their native language.\n\nℹ️ Note: This survey has only been conducted in English, which may have impacted the outcome of this question. We still believe internationalization of resources like the Solidity documentation is a crucial factor in lowering the barrier of entry, and we aim to support this by helping coordinate the community-driven translation efforts.\n\nDev & User Profile\nIn this next section of the survey, we present insights about the professional background of our developers and users and share their preferences about coding languages, open source contributions, operating systems, & more.\nEmployment & Work Experience\n66.6% of respondents were employed at the time of the survey, while 14% stated that they were students. 19.4% reported that they were not employed at the time of the survey.\nCompared to the previous survey, the overall distribution remains almost identical.\n\n71% of the total participants who were employed at the time work in the “crypto”, whereas 16.4% work in technology in general, and 5.1% work in financial services. A very small portion works in Education/Academics and Media/Gaming (1.9% each).\nYet again, this trend is almost identical to the results from the previous year with a slight change in the individual percentages.\n\nWhile a total of 41.5% of respondents are considered seniors in their field with more than 6 years of professional coding experience, 7% have never coded at work. Among the 41.5% seniors, 13.4% have even been coding for 15+ years.\nWith 27% votes, a majority of respondents are mid-level programmers with 3-5 years of experience, whereas 8.8% have only coded professionally for less than a year.\nOverall, the level of professional coding experience is medium to high, with the majority of respondents (68.6%) having coded professionally for 3+ years.\nAlthough the chart maintains its shape compared to last year, the individual data is slightly different for various years of experience. For instance, the percentage of respondents with 15+ years of experience is higher than last year.\n\nDeveloper Profiles\nWhen asked which developer profile best describes the participants, the majority identified as full-stack developers, a choice we newly added this year to allow participants to indicate their technical background more accurately.\nWith a different distribution emerging this year, 24.1% of the respondents were found to be auditor/security experts, closely followed by 22.6% smart contract developers, 11.5% academic researchers, and only 5.2% tooling developers.\n\nA majority of 45.5% of the participants use Solidity both at work and for personal projects. The rest of the respondents are almost equally distributed between using Solidity at work (27%) and using Solidity for personal projects (27.6%). This trend is similar to last year, except for small shifts in individual numbers.\n\nA total of 25.8% of users contribute to open source projects written in Solidity regularly (daily and weekly), whereas 28.4% only contribute monthly.\nOn the other hand, 45.7% of users reported that they have never contributed to open-source projects written in Solidity.\nCompared to previous years, we are unfortunately seeing a downtrend of users who contribute to open-source projects written in Solidity.\n\nProgramming Language Preferences\nLike previous years, Solidity ranks as the most used programming language among the participants (42.4%), a number almost identical to last year's, followed by TypeScript (21.5%), and JavaScript (15%).\nThe order of the top 3 most used languages remains the same as last year.\nOther less frequently mentioned languages are Python (10.3%), Rust (4.4%), Go (2%), C# (1.7%), and Java (1.7%).\nSince Go was specified as an \"Other\" response, almost as many times as Java last year, it was introduced as a choice in the list of languages and ranked higher than C# and Java.\nPlease note that there are missing labels of other languages that did not show up in the chart due to space constraints. You can find the full list in the analysis sheet.\n\nWhen asked about the favourite language of the participants, Solidity ranks the highest with 32.7% of the votes, a bit higher than last year, followed by Python (13.9%), TypeScript (12.8%), Rust (11.3%), and JavaScript (9.9%). JavaScript has fallen back by a few ranks this year in the list.\nHowever, the order by popularity of other lesser mentioned languages in the list remains consistent with last year, with Go at 5.2%, C++ at 3.7%, Java at 3.2%, C# at 2.3%, and C at 1.4%.\n\nPreferred Operating System\nThe majority of the participants use macOS as their primary Operating System (43%), followed by Windows (29.2%) and Linux (27.8%).\nLinux and Windows were found to be equally popular last year.\n\nSolidity Background\nIn the next section of the survey, we collected information regarding Solidity-specific development experience and usage habits of the participants.\nSolidity Expertise\nAlmost 60% of all respondents deem themselves Solidity experts, with a self-rating in expertise of 7 or higher (scale of 10), out of which participants with a self-rating of 8 are the highest in number.\n23.4% rated themselves 10 in Solidity expertise, and roughly 84% of those have been using Solidity for 2+ years.\nAbout 20% of all who responded are still at the beginning of their Solidity journey with a self-rating of 4 or less.\n\nWe asked the participants about how long they have been using Solidity. Almost 30% of all respondents have been using Solidity for less than a year, with 10% with less than three months of experience using Solidity.\nThe highest number of respondents (24.5%) are users who have 2-3 years of experience in Solidity.\nAbout 24% of users can be considered seniors in the ecosystem since they stated that they have been using Solidity for 3+ years.\n\nWhen asked how long it took the respondents to start feeling productive with Solidity, the majority of them (36.7%) reported that it took them less than 6 months.\n17.8% even said that it only took them less than a month.\n12.7% needed more than a year to feel comfortable with the language. This number is slightly higher than the last year.\n17.4% don't feel productive yet, out of which 76.7% are still in the beginning of their Solidity journey (=<6 months), and 45% have even less than three months.\n\nSolidity User Profile & Usage Habits\n43.7% of respondents use Solidity daily, followed by 32.9% who use it weekly and only 14.5% who use it every month. These numbers have seen a slight shift since last year, but the order (daily > weekly > monthly) remains the same.\nAs low as 0.9% said that they never use Solidity, decreasing further 1% since last year. 8.1% of users stated that they use it rarely.\n\nLike previous years, we asked the survey audience how they get the Solidity binaries. The most mentioned sources were, in the order of highest to lowest:\n\nvia a framework / IDE (38.5%) -0.3%📉\nusing npm (16.1%) -2.5%📉\nGitHub Releases (11.1%) -1.5%📉\nsolc-select (7.5%) that we added as a choice this year\nBuild from source (7.1%) -2.2%📉\nHomebrew (5.7%) -0.4%📉\nsolc-bin (5.5%) -1.3%📉\n\nOther lesser prominent sources were Ethereum PPA for Ubuntu, Package Managers for Linux Distros, Dockerhub, and svm-rs.\n\n90.1% of all respondents use Visual Studio Code as their editor when writing Solidity code, increasing almost 20% this year.\nSwapping positions since last year, IntelliJ and Vim follow in the second and third ranks with 3.9% and 2.4% users, respectively.\nAtom and Visual Studio continue to rank the lowest in this chart, as seen below.\n\nDepending on the chosen editor, we also asked respondents which Solidity-related plugins they use, if any.\nJust like last year, “HardHat VSCode” by Nomic Foundation and the “Solidity” extension by Juan Blanco were found to be the most popular among Solidity developers.\n\nWe wanted to know which Ethereum-specific development environment our survey participants use.\nThis year, Foundry takes over Hardhat as the most popular Ethereum-specific IDE with the highest percentage of users (51.1%). After rising in popularity from 1.6% in 2021 to 30% in 2022 and 32% in 2023, Foundry has been gaining more users within the Solidity community and Ethereum ecosystem in general.\nHardhat falls behind this year with 32.9% users, still comparable to last year. The percentage of Hardhat users has been on a downtrend since the 2022 results, when roughly 75% of respondents reported that they used Hardhat.\nAnother interesting find this year is that while Remix followed both Hardhat and Foundry closely last year with 25.8% votes and continues to be the third most popular choice this year, it has only earned 8% of the total votes.\nTruffle ranks lower in this list with only 2.4% of respondents indicating its usage, closely followed by Wake with 2.1% votes.\nApe, Brownie, and Dapp share the same percentage of users this year (0.6%), marking them as the lesser-known/used choices among others in the list.\nAs low as 1.3% of respondents do not use any Ethereum-specific development environment at all.\n\nThis year, we introduced a few follow-up questions to understand the usage patterns of these tools.\nWhen asked whether the survey participants use these tools independently or at work, the majority (62%) indicated that they use them independently, whereas 38% stated that they use them at work.\n\nWe also asked them to choose what purpose they use the tools for among a list of options. Here's what we found:\nMost participants use them for testing (28.3%), closely followed by production deployment (24.6%), quick prototyping (18.6%), gas optimisation (15.5%), and CI/CD testnet (12%).\n\nOut of the 30.9% of respondents who indicated that they also use other IDEs, 45.5% voted for Remix, followed by Hardhat (24.5%) and Foundry (18.8%) as their secondary choice.\nOnly 2.9% voted for Truffle and 1.9% for Ape.\n\nSimilar to last year, the 0.8.x Solidity versions remain the most used versions. However, 88.9% respondents this year indicated that they use v0.8.x of the compiler, a significant increase since last year (81.85%).\nPlease note that this is a multiple-response type question allowing participants to choose more than one version series.\nWhile the usage share of the 0.7.x (4.8%) version series has more or less remained the same this year, the 0.6.x (2.63%) series continues to decrease consistently since the previous surveys. The rest of the older versions are rarely in use.\n\n⚠️ Important Reminder: Please make sure to frequently update your code (and compiler) to the latest Solidity version. Several important bug fixes and security improvements are added in the newer versions!\nSolidity Usage Details\nEach year, we learn more about how our community uses Solidity by analyzing responses to our survey on Solidity usage trends:\nCLI\nWe asked the participants whether they invoke the compiler binary directly on the command line, and 76.6% denied it (almost a 17% increase since last year), whereas 23.4% confirmed that they do. This distribution has had a major shift this year.\n\nWhen using the compiler on the command line, 67.1% prefer the CLI over Standard JSON for scripting. This number is 8.2% greater than last year.\n\nWhen asked how disruptive changes in CLI options and outputs would be for respondents, 64.7% responded with \"okay\" (almost identical to last year) and 16.3% with \"Not disruptive at all\".\nHowever, 19% deem these changes as disruptive, increasing almost 10% compared to last year.\n\nOld EVM versions\nWhile 26.3% of the overall respondents still rely on old EVM versions, a majority of 73.7% claim that they do not need compiler support for older EVM versions anymore, increasing ever so slightly since last year.\n\nAmong those who rely on older versions, 8% still rely on deprecated EVM versions. This number is on a desired downward trend since last year.\n\nABIEncoderV1\nWhile 61.7% do not use ABIEncoderV1, only 3.8% know about it and use it. 34.5% do not seem to be aware of its existence or what it does, increasing slightly compared to the previous year.\n\nSMTChecker\n74.1% of total respondents have never used the SMTChecker. 19.5% have tried it, and 6.4% use it frequently. You can learn more about the SMTChecker here.\nAlthough the overall usage pattern remains the same across the previous years, the percentage of users who use it frequently has increased slightly this year.\n\nThe IR compilation pipeline\nWe asked the participants again this year whether they use the new IR pipeline for compilation, and although slightly lower than last year, 46.4% still do not know what via-IR is. This number is on a downtrend over the years, implying a rise in awareness about the IR pipeline in the user community.\n24.4% use the IR pipeline already, whereas 29.2% are yet to try it. Last year, we wrote an explainer blog post on via-ir. Give it a read to learn more about what it is and why you should be using it to compile your contracts.\n\nWhen asked which issues are hindering the users from compiling their contracts via-IR, 19.3% marked the long compilation times as the reason, and 18.9% claimed that there is no need or real use-cases for it yet.\nWhile 13% are still waiting for the IR pipeline to become the default, 11.5% aren't yet sure about what's keeping them from using it.\nSome more issues include stability/security concerns (9%, almost half compared to last year), verification/compilation failures (6.8%), and insufficient docs (5.6%).\n\nWhen asked about the time taken to compile the contract's code using the via-IR pipeline, the majority of the respondents indicated that it takes anywhere between 1 to 10 minutes, just like last year.\nSome users also reported that it can take anywhere from 15 minutes to up to 50 minutes.\nPlease note that while analysing this data, it should be taken into account that the data also depends on the users' hardware capabilities and specifications.\n\nMetadata publication\nWhen asked whether participants publish their metadata output on IPFS, we have marked a huge change in the results compared to last year.\n67.1% of respondents stated that they do not publish the metadata of their smart contracts, which has gone up significantly from 30.3% last year.\nThe percentage of users who publish their metadata went down from 55.2% to 14.9% this year. 18.1% still don’t know what this means.\n\nSourcify\nWhen asked about Sourcify usage, 17.4% of all respondents use Sourcify for smart contract verification (slight increase compared to last year), while 26.9% claim to not use it.\n55.7% don’t know what Sourcify is, which is quite similar to last year.\n\nThis year, there was a significant increase since last year in users who use Sourcify via Foundry (35%), followed by 34.2% via Hardhat, and 14.5% via Remix. 12.8% use it via Sourcify directly. To learn more about Sourcify, visit sourcify.dev.\n\nappendCBOR: false or bytecodeHash: none\n60.9% of users do not know what appendCBOR: false or bytecodeHash: none is, whereas 27.9% know but do not use it. A small portion, equal to 11.2%, uses it either frequently or sometimes.\nThe usage pattern is similar to last year.\n\nFlattening contracts\n48.8% of total respondents do not flatten their contracts, whereas 25% do. 26.2% do not know what that is.\nMost of the users who flatten their contracts mentioned that they do so for the ease of verification (50%), followed by manual reviews (27%), and ease of debugging (16.5%).\n\nOther EVM Networks\nMore than half of all respondents (62.3%) use Solidity outside of Ethereum Mainnet and testnets.\nWhen asked which other networks they deploy their smart contracts on, an equal number of participants (14.6%) responded with Base and Polygon (formerly Matic Network).\nOther often mentioned blockchains include Arbitrum (14.3%), Optimism (12.0%), Binance (8.4%), zkSync (7.1%), Avalanche (6.5%), and more, as shown in the chart below.\n\nOther Smart Contract Languages\nWe were curious to know which other smart contract languages Solidity users and devs prefer, and here's what we found:\nA majority of 37.9% of respondents stated that they don't use any languages other than Solidity.\nYul, an intermediate language for Solidity, continues to rank as the most used smart contract language other than Solidity with 18.5% voters; a slight decrease compared to last year.\nVyper, a Python-based EVM language, ranks as the second most used language other than Solidity with 14.4%.\nThis trend is similar to last year, except for a slight increase.\nCairo (8.8%) and Huff (8.1%) have almost an equal number of users among the survey audience.\nWe added a new choice to the list this year, Noir, that was opted for by 4.3% of the respondents.\nSway (1.4%) and Fe (1.4%) share a place in the list.\n\nSolidity Developer Experience\nIn this section of the survey, we will be going through the developer experience of our user community.\nWe asked about the overall improvement in the Solidity developer experience.\n66.8% of all respondents generally believe that it has improved in the last year, with 24.2% even believing it was a major improvement.\nOnly 1.5% of the respondents believe that the developer experience has gotten worse.\n\nRecurring Issues\nWhen asked if the participants encounter recurring issues, 60.7% of the total respondents said that they do not come across the same or similar issues multiple times when developing in Solidity.\nAmong the 39.3% that encounter recurring issues, Stack too deep issues are encountered most frequently, followed by debugging issues, bytecode size limit, and optimiser-related issues.\n\nℹ️ Note: On the topic of debugging issues, we would like to remind you about the ethdebug standards development working group, an initiative aimed at defining a common debugging data format for languages built on top of the EVM: ethdebug.\nWe encourage all developers working on such tools to join the working group. The group has regular bi-weekly meetings and coordinates via the ethdebug Matrix channel.\nGetting Started with the Compiler\n53.8% of respondents find it \"okay\" to get started with the Solidity compiler, whereas 43.6% find it very easy.\nAs low as 2.6% voted getting started with the compiler as \"difficult\". When asked what made it difficult to get started, some mentioned the docs as an issue.\n\nMost liked Aspects/Features & Pain Points\n25% of respondents most like Solidity's similarity to other programming languages. This option is known to rank highest from last year's results as well.\nOther most liked aspects include its simplicity (20.5%), ease of learning the language (18.3%), and its syntax (11.6%).\nSome also consider static typing (10.9%) and the ease of reading (10.4%) as the most likable aspects.\n\nThis year, 21.8% of the respondents opted for mappings as their most liked feature, followed by 20.4% for contracts as objects. Although these features have ranked as most liked in the same order two years in a row, this year's percentages are quite lower in comparison to last year.\nModifiers (15.1%), require with custom errors (13.7%), and Inline Assembly (9.8%) were often mentioned as well.\nSome users reported user-defined types (5.8%), dynamic arrays (3.9%), transient storage (3.4%), and using for (2.6%) as their most liked features.\n\nWe asked the participants once again about their biggest pain points with Solidity, and here's what we found:\nStack-too-deep errors ranked the highest again this year with 31.9%% % of all votes, albeit at a much lower percentage than last year, followed by bytecode size limit (19.6%), a new addition, missing memory optimizations (19.6%), and compiler performance (10%).\n8.3% of respondents said that redundant checks (e.g., in checked arithmetic) are their biggest issue.\nA little over 9% selected “OTHER” and specified some of their most significant pain points, such as error reporting and a lack of a better debugging tool.\n\nDocumentation\nWhen asked if the participants found the official documentation helpful, there was a rise in the survey respondents who stated that the Solidity documentation was helpful (79.8%), followed by 17.7% who considered it somewhat useful.\nAs low as 2.5% voted that they do not find the docs useful at all, reducing ever so slightly compared to the past year.\nIdeas for improvement most prominently ask for more code examples but also more in-depth docs for Yul and assembly, better in-docs search and navigation, and overall better UI/UX.\n\nHigh-Impact Compiler Bugs\nLike previous years, we were curious to find out whether Solidity developers had been affected by any of the high-impact compiler bugs (codegen bugs that are announced with Security Alerts on the Solidity blog).\nWhile 94.7%, quite similar to last year, said they haven't been affected, 5.3% claimed that they were.\nBelow is the distribution of the bugs (and the corresponding number of users impacted) reported by the 34 participants who were impacted by high-impact compiler bugs:\n\nAbiEncodeCallLiteralAsFixedBytesBug: 6\nVerbatimInvalidDeduplication: 6\nMissingSideEffectsOnSelectorAccess: 6\nInlineAssemblyMemorySideEffects 6\nKeccakCaching: 5\nStorageWriteRemovalBeforeConditionalTermination: 5\nDirtyBytesArrayToStorage: 4\nSignedImmutables: 4\nAbiReencodingHeadOverflowWithStaticArrayCleanup 4\nFullInlinerNonExpressionSplitArgumentEvaluationOrder 3\nDataLocationChangeInInternalOverride 3\nNestedCalldataArrayAbiReencodingSizeValidation 3\nABIDecodeTwoDimensionalArrayMemory 3\nUserDefinedValueTypesBug 2\nI don't remember. 9\nOTHER: 1 (\"In solidity 0.8.16, I had an issue when removing an item from mapping. It didn't remove the position, just zero it out.\")\n\nPlease note that the above follow-up question about the name of the high-impact compiler bugs was a multiple-choice question.\nExternal Libraries\nWith a slight bump compared to the past years, the majority of the survey respondents (45.5%) stated that they use external libraries for purposes such as proxy pattern, contract splitting, and in order of most to least mentioned use case.\n44.2% have reported that they do not use them at all, whereas 10.3% remain unaware of what they are or what they are being used for.\n\nLanguage Design & Upcoming Features\nIn the following section of the survey, we will take you through the insights we drew from asking our participants about their thoughts on and involvement in the Solidity language design updates and efforts.\nMost Anticipated Feature(s)\nThere seems to have been a major shift since last year in the most anticipated feature, with generics going down from 23.2% to 7.6% this year.\nWith that, the most anticipated update this year is the elimination of stack-too-deep(18.2%), followed by 16.9% reporting that they look forward to better debugging tools.\nOther features most anticipated by survey respondents in their descending order are:\n\nGas optimisations (13.2%)\nSupport for decimal numbers & Dynamic Memory Arrays (12.2%)\nResizable dynamic memory arrays (8.7%)\nEVM Object Format (7.7%)\n\n...and more as shown in the chart below.\n\nFeedback on New Features/Improvements\nLike the previous two years, we asked the participants about their thoughts on functional elements in Solidity, and the overall feedback remains similar, with a small change in the individual numbers:\nWhile a majority of 51.7% of users believe that functional elements in Solidity, such as Lambda functions, are great, 14.6% maintain their position against them, and 33.6% are indifferent towards them.\n\nLast year, we asked the participants about their thoughts on the EIP-1153: \"Transient Storage\", and the results were enlightening.\nThis year, we asked once again whether they need complex types in transient storage. The number of respondents who want the feature has halved from 40.4% last year to 20.2%. However, we saw a rise to 48.1% in those who stated their indifference, while 31.7% asserted that they do not need complex types.\n\nWe also introduced a few new questions to this section for the 2024 survey. Let's see what we found out.\nWhen asked about the preference between traits/typeclasses and inheritance, a majority (37.8%) of the survey audience reported that they aren't familiar with the concept, whereas only 25.9% voted for traits/typeclasses, and the rest (36.3%) asserted that they prefer inheritance.\n\nWe followed up with how difficult the respondents deem the process of rewriting the codebase with a traits-style system on a scale of 1-10.\n39.4% of respondents assigned it a medium difficulty level of 5. A total of 20.6% of the audience have assigned it a high difficulty, anywhere between 8-10. On the contrary, as low as 7.7% of people marked it as a low-difficulty task to replace the usage of inheritance with a traits style system.\nIt is fair to conclude that the majority considers this either as a non-trivial or a highly difficult and involving process.\n\nMoving on, we tried gauging the interest in having algebraic datatypes. While more than half (51.4%) of the audience expressed their interest in having such datatypes, only 22.3% remain uninterested. However, as high as 26.3% have no clue what algebraic datatypes are. This allows the team to consider writing more about them on the blog.\n\nWe were also curious about whether our users have ever tried a language that uses pattern matching, and/or if they would be interested in having this in Solidity.\n34% reported that they have used pattern matching before and are interested in having the feature in Solidity. However, 26.4% of users stated that they haven't used it, followed by 20.9% who have used it but do not require the feature, and lastly, 18.8% who do not understand the question.\n\nWe asked the respondents about the importance of maintaining CREATE2 compatibility for salted creates in Solidity between EOF and legacy EVM.\nWhile a majority of 42.6% affirm that it does not impact their work, 23.1% still deem it as pivotal to the work that they do. 34.3%, however, state that they are not familiar with the concept.\n\nAs a follow-up, we enquired about the extent of annoyance around providing an explicit salt on each contract creation.\n47.3% confirmed that they are neutral to this possible change, followed by 26.4% assuring that it would not be annoying at all. However, 20.3% of respondents asserted that it would be quite annoying for them to have to provide an explicit salt on each contract creation. 6.1% of the audience remains unsure.\n\nLanguage Design Related Efforts\nOnce again, we checked with the respondents whether they have or continue to participate in the language design efforts, and here's what we found:\n\nMore than 85% of respondents stated that they do not participate because they are either too busy, uninterested/underqualified, or do not know how to participate.\n14.8% of the respondents said that they regularly participate in language design efforts either by joining the calls, the forum discussions, or by proposing new features or language changes on GitHub.\n\nAt Solidity, we have and would like to continue to make it easier for our community to participate more actively in these discussions and feel empowered enough to contribute to the language design decisions.\n\nSolidity Developer Community\nStaying up-to-date\nA slightly new trend from the previous years is that this year, most people reported that they like to stay up-to-date about Solidity versions, security alerts, and announcements by following the Solidity Twitter or Mastodon, followed by the Solidity blog.\nAnother often mentioned means of information is the Solidity GitHub Releases page.\nInterestingly, about 21.2% claim not to be doing any of the above.\nAs part of “other”, respondents specified several community-based means to stay up-to-date:\n\nCyfrin Updraft course on Solidity\n\"Crypto influencers\" / Popular Solidity developers\nDiscord servers\nGoogle\nCrypto Twitter / Community chats / Farcaster channels\nNewsletters\nCrypto blogs\nSolidity docs\nSolidity website\nTutorials on YouTube\nReddit\nVSCode Notifications\n\"Week in Ethereum News\" Newsletter\n\nInteraction with Other Solidity Developers\nMore than half of respondents (53.8%) interact with other Solidity developers, whereas 31.1% admitted that they rarely interact with other Solidity devs.\nWith a slight increase from last year, a smaller portion of that chart (17.5%) does not interact with other Solidity developers at all.\n\nSimilar to previous years, we wanted to conclude the survey with a question that helps us understand the community's confidence in the work of the Solidity team. We asked the participants whether they agree or disagree with the following statements:\nStatement 1: I feel welcome in the Solidity developer community.\nA majority of 42.6% of respondents agree that they feel welcome in the Solidity developer community, and 26% somewhat agree with the statement. However, over 6% still feel unwelcome in the community, whereas 25% aren't sure about how they feel.\nStatement 2: I am confident in the work of the Solidity core team.\nAbout 78.3% either fully or somewhat agree that they feel confident in the work of the Solidity team. However, 7% of the survey audience does not agree with this statement. As many as 14.6% remain unsure.\nStatement 3: The Solidity team understands my needs as a developer.\nA majority of 64.8% either agree or somewhat agree with the above statement. While 27.4% do not know how they feel about this, 77.3% of the audience generally disagrees.\nStatement 4: The options for how to contribute ideas or feedback to Solidity are clear to me.\nThis year, as high as 28.4% have stated that they \"don't know,\" meaning that the ways to contribute ideas and feedback aren't clear to them.\nAlmost 47% of the survey audience generally agrees that the options for how to contribute ideas or feedback to the team are clear to them. However, quite a significant portion of the audience (24.6%) also disagrees with the statement.\nStatement 5: I am receiving adequate feedback from the Solidity team on issues raised on GitHub and/or forum posts.\nAs high as 50.3% of the audience does not know how to feel about this statement.\nWhile 40.8% of respondents are generally satisfied with the feedback and inputs they get from the Solidity team regarding their contributions, a total of 8.8% remain in disagreement with this statement.\nThe results of this “community and Solidity team confidence ranking” are quite consistent with the results from 2023.\n\nWe added another question at the end of the survey, albeit a little later into the response collection process, about affiliation with projects with significant usage and/or TVL. We surveyed about 480 participants on the following questions:\nDo you work on a project with significant usage and/or with a significant amount of funds handled or locked by it?\nOut of 480, 417 participants responded to it, out of which a majority of 45% reported that they do not work on such a project, almost 30% did not want to share, and roughly 25% confirmed their association with a high usage/TVL project.\n\nKudos to you!\nLast but not least, we would like to extend a big thanks to all of you for completing the survey and giving us feedback. We hope that our survey results continue to be just as valuable to the Solidity ecosystem and community as they are to us.\nWe aim to continue collecting your inputs and improving Solidity as an open-source project.\nTo stay up-to-date with all Solidity-related announcements and updates, make sure to:\n\nFollow Solidity on Twitter or Mastodon.\nJoin the language design discussions in the Solidity forum or provide us feedback there.\nFollow announcements and security alerts on the Solidity blog.\nFollow and ⭐ the Solidity repo on Github.\n\nAll graphs can be found here. The raw and analyzed data can be found here.Previous postNext post","tokens":9375,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266041659,"hash":"00b8cb0dadba875cd912a874be9cd820166cef54"}
{"url":"https://docs.optimism.io/node-operators/overview","domain":"docs.optimism.io","title":"Optimism Documentation","text":"​Overview\nThis section of the documentation is dedicated to node operators who want to learn about configuring and running nodes on OP Stack networks.\nBecause the OP Stack is an open-source, modular, and extensible stack, there are many different clients, configurations, and requirements depending on your goals and the specific network you’re targeting.\nThe information provided in this section covers standard configurations and features on the OP Stack.\n​Why Run a Node?\nRunning your own node gives you the benefit of trustless verification, enhanced privacy, and gives you local access to the blockchain.\nHowever, it also requires time and resources to set up and maintain.\nSo you should consider your goals and use cases before deciding to run a node because there are many third-party RPC providers available.\n​System requirements\nBefore you start, check that your machine can handle the network and node type you’re targeting.\nRequirements scale with both:\n\nRAM: 16GB is the suggested minimum for an OP Mainnet node.\nCPU: A reasonably modern CPU.\nDisk: An SSD, sized to the network and node type. A full OP Mainnet node needs hundreds of gigabytes and grows steadily; an archive node needs multiple terabytes and grows much faster, so use an NVMe SSD for archive nodes.\n\nTest networks are far lighter than OP Mainnet: an OP Sepolia full node syncs into tens of gigabytes rather than hundreds.\nIf you’re setting up for the first time, start on OP Sepolia to validate your setup before committing OP Mainnet-scale disk.\nFor the current OP Mainnet storage figures and their growth rates, see the hardware requirements in the from-source tutorial.\n​Node Architecture\nRegardless of which OP Stack network you’re running a node for, all nodes share the same fundamental two-client architecture: a consensus client (rollup node, either op-node or kona-node) paired with an execution client (op-reth), communicating via the Engine API with JWT authentication.\nNodes that follow every chain in an interop dependency set run op-supernode as the consensus layer instead.\nSee the architecture reference for how the components fit together and the current client support matrix.\n​Node Types\nDifferent node types serve different purposes:\n\nFull node: keeps a complete copy of the blockchain, validates all transactions and blocks, and participates on the P2P network.\nArchive node: additionally retains all historical state for every block.\nOn OP Mainnet, archive nodes need to restore from a database snapshot before syncing.\nSequencer node: can be a full or archive node, but it can create new L2 blocks.\n\n​Network upgrades\nNetwork upgrades on OP Stack networks are generally activated by timestamps.\nFailing to upgrade your node before the activation timestamp causes a chain divergence that requires a resync, so follow the node upgrade process to stay on the canonical chain.\n​Stay up to date\nUpgrade announcements, deprecations, and other changes that affect node operators are published on the Network Notices page.\n​Next steps\n\nRun a node with Docker: recommended path; uses the official op-reth + op-node images.\nBuild and run a node from source: covers op-reth and Nethermind.\nRun op-reth with historical proofs: configure op-reth’s proofs-history store for permissionless withdrawal proving.\nConsensus client configuration: working base configuration and recommended flags for the rollup node.\nExecution client configuration: working base configuration and recommended flags for the execution client.\nSupernode configuration: recommended settings and a starter configuration for running op-supernode in an interop dependency set.\nNode metrics and monitoring: keep tabs on your node once it’s running.\nNode troubleshooting: help with common problems.\nArchitecture reference: deeper detail on the two-client architecture.\nWas this page helpful?","tokens":962,"squid":"ink-governance","role":"Council Listener","at":1791266041698,"hash":"6baf84a498e3ea4b6fbf0ff237e1e162bc1f8cea"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/29","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 29 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n Load more posts below","tokens":2834,"squid":"ink-research","role":"Deep Scholar","at":1791266059814,"hash":"b1c243c7e4c52e18e39a051ae79bc7b523aa72c3"}
{"url":"https://soliditylang.org/blog/2024/04/03/solidity-developer-survey-2023-results/","domain":"soliditylang.org","title":"Solidity Developer Survey 2023 Results | Solidity Programming Language","text":"Solidity Developer Survey 2023 ResultsPosted by Vishwa Mehta on April 3, 2024AnnouncementsEDIT REMARK: We noticed a minor error in the graphical representation of [1] popular Ethereum-specific IDEs and [2] Sourcify usage. The results in this blog post and corresponding graphical data in the slide deck has been updated to reflect this rectification that represents the survey data accurately.\nWe are thrilled to share with you the Solidity Developer Survey 2023 results! In this blog post, we will be going over key insights and detailed analysis of the various sections of the survey.\nBefore we dive in, we would like to thank everyone who submitted a response to the survey as well as helped us reach the right audience for it! Your inputs are invaluable to us and are pivotal in driving important language design decisions and improving Solidity as an open source project.\nThis year, we received a total of 474 responses. Let's start with some useful links:\n\nIn the spirit of open source, you can find all raw data of the survey results here and all graphs here.\nThis is our fourth annual survey. You can compare the 2023 results with the previous years by checking our the blog posts below:\n\n2022\n2021\n2020\n\nWithout further ado, let’s dig into the 2023 results!\nSummary & Notable Insights\nThe survey consists of 6 sections, namely: [1] Demographics, [2] Dev & User Profiles, [3] Solidity Background, [4] Solidity Developer Experience, [5] Language Design, and [6] Solidity Developer Community.\nLet's look at some key insights from and the summary of these various sections from the 2023 survey.\n\nDemographics: In total, 474 developers from 71 different countries participated in the 2023 survey. The highest number of respondents hail from the USA (18.8%), followed by India (10.5%), and Nigeria (6.2%). This remains consistent with last year's insights except for Nigeria replacing France as the 3rd country where the highest respondents live.\nThis year, we saw new native African languages such as Kinyarwanda, Kiswahili, Runyankole, and Luganda.\nDev & User Profiles: Solidity continues to be the most used language by the respondents, followed by JavaScript and TypeScript.\nA majority of Solidity experts (self-rating of 10) have been using the language for 2+ years, some even more than 5 years.\nSolidity Background: 36.7% users stated that it took them less than 6 months to feel productive with Solidity. It is interesting to note that among these users, majority of the respondents use Solidity daily or weekly and most of those who don't feel productive with Solidity have been using the language for less than 3 months.\nSolidity Developer Experience: Generally a majority of the participants feel that the Solidity developer experience has improved in the last year.\n33.8% users indicated that mappings is their favourite feature followed by contracts as objects (23.2%) and modifiers (16.1%).\nLanguage Design: Generics (23.2%), require with custom error types (17.4%), and transient storage (13%) were found to be the most anticipated features this year.\n28.6% participants know what Ethereum Object Format (EOF) is among whom 63.5% are confident that it will positively impact them.\nSolidity Developer Community: GitHub Releases rises in ranking among the list of sources used for staying up-to-date with Solidity announcements.\n\nDemographics\n⚠️ Be aware that this survey has only been shared in English when interpreting results regarding the distribution of countries of residency and language preferences.\nLet's begin by analysing the first section of the survey which covers information about the residency and native languages/language preferences of the respondents.\nIn total, 474 developers from 71 different countries participated in the 2023 survey.\nThe coverage of different geographies increased from 73 countries in 2021 to 100 countries in 2022 and back to 71 in 2023. It is interesting to note a massive spike in responses in the year 2022.\nResidency\nFrom the 2023 survey, 18.8% of respondents mentioned that they live in the USA, followed by India (10.5%), Nigeria (6.2%), and Germany (5.3%).\nThis is quite consistent with the previous year with the exception of Nigeria and Germany ranking higher than France with more number of responses.\n\nLanguage\nIn the 2023 survey, a total of 60 languages were submitted as the native languages of the respondents.\n32.6% of the total participants speak English as their native language, 13.1% speak Indian languages, 7.5% speak Spanish, 6.7% speak French, 5.2% speak Chinese languages, 4.9% speak German, 4.3% speak Russian, and 1.3% speak African languages.\nℹ️ Note: Bengali, Gujarati, Hindi, Marathi, Nepali, Odia, Punjabi, Tamil, Telugu, and Urdu were clustered as “Indian languages”. Cantonese, Chinese, and Mandarin were clustered as “Chinese languages”. Igbo, Kinyarwanda, Kiswahili, Runyankole, Luganda, Swahili, and Yoruba were clustered as African languages.\nIt is interesting to note new African languages such as Kinyarwanda, Kiswahili, Runyankole, and Luganda have entered the survey results this year.\n\nMore than half of the of respondents (54.2%) predominantly speak their native language at work, whereas 45.8% still speak another language at work.\nA total of 75.4% respondents reported that they predominantly speak English at work, followed by Chinese Languages, Indian Languages, Spanish, and French distributed almost equally.\n\nA total of 84.8% participants stated that they are okay with reading the Solidity documentation in English.\nHowever, 15.2% participants prefer to read the documentation in their native language. The number of respondents who would prefer it in their native language is slightly higher this year than the previous year (12.9%).\n\nℹ️ Note: This survey has only been conducted in English, which may have impacted the outcome of this question. We still believe internationalization of resources like the Solidity documentation is a crucial factor in lowering the barrier of entry, and we aim to support this by helping coordinate the community-driven translation efforts.\n\nDev & User Profile\nIn the second section of the Solidity Developer Survey, we gather insights about the professional background of our devs/users and learn about their preferences about coding languages, open source contributions, OS, & more.\nEmployment & Work Experience\n65.2% of respondents were employed at the time of the survey, while 13.4% stated that they were students. 21.4% reported that they were currently not employed.\nCompared to the previous survey, there is a slight increase in both the number of students and currently unemployed developers or users.\n\n69.6% of the total participants who were employed at the time work in the “crypto”, whereas 14.7% work in technology in general and 4.5% work in financial services.\nThis trend is quite comparable to the results from the previous year with just a slight change in the individual precentages.\n\nRoughly 36% of all respondents are considered seniors in their field and have been coding professionally for 6+ years, out of which 9.7% have even been coding for 15+ years.\nOn the contrary, roughly 6.1% have never coded as part of their job and 9% have only coded professionally for less than a year.\nAs a majority, 28.3% of repondents are mid-level programmers with 3-5 years of experience.\nOverall, the level of professional coding experience is medium to high with the majority of respondents (64.5%) having coded professionally for 3+ years.\n\nDeveloper Profiles\nWhen asked which developer profile best describes the participants, the majority identified as a smart contract developer.\nRouhgly 5.3% are tooling developers, followed by 4.4% auditor / security experts, and only 1.3% stated that they are academic researchers.\n\nA majority of 48.9% of the participants use Solidity both at work and for personal projects. The rest of the respondents are almost equally distributed between using Solidity at work or using Solidity for personal projects.\n\nA cummulative of 32% users contribute to open source projects on a regular basis (daily and weekly), whereas 27.1% only contribute on a monthly basis. Almost 41% users reported that they never contribute to open source projects written in Solidity.\nThe number of users who never contribute has reduced this year with an increase in the number of daily or weekly contributors.\n\nProgramming Language Preferences\nYet again this year, Solidity ranks as the most used programming language among the participants (42.9%), followed by TypeScript (16.7%), and JavaScript (15.4%).\nWe observed a big hike in survey participants who use Solidity the most going from 28.9% last year to 42.9% this year. JavaScript and TypeScript seem to have swapped places this year.\nOther less frequently mentioned languages are Python (9.5%), Rust (3.5%), and C# (2.4%), and C++ (2.2%).\n\nWhen asked about the favourite language of the participants, Solidity ranks the highest with 29.1% of the votes, followed by Python (15.6%), JavaScript (12.4%), TypeScript (12%), and Rust (10%).\nOther lesser mentioned languages in this list were Go (4.1%), C++ (3.4%), Java (3%), C# (2.8%), and C (1.5%).\n\nPreferred Operating System\nMajority of the participants use MacOS as their primary Operating System (40.5%). Linux and Windows are equally popular, with 29.9 and 29.7% respectively.\n\nSolidity Background\nIn the next section of the survey, we collected information regarding Solidity-specific development experience and usage habits of the participants.\nSolidity Expertise\nAlmost 60% of all respondents deem themselves Solidity experts, with a self rating in expertise of 7 or higher (scale of 10) out of which participants with self-rating 8 are the highest in number.\n23.4% rated themselves as an expert (self-rating 10) and roughly 84% of those have been using Solidity for 2+ years.\nRoughly 20% of all who responded are beginners with a self-rating of 4 or less.\n\nWe asked the participants about how long have they been using Solidity for. Almost 30% of all respondents have been using Solidity for less than a year, with 10% with less than three months of experience using Solidity.\nThe highest number of respondents (24.5%) are users who have 2-3 years of experience in Solidity.\nAbout 24% of users can be considered seniors in the ecosystem since they stated that they have been using Solidity for 3+ years.\n\nWhen asked how long it took the respondents to start feeling productive with Solidity, the majority of them (36.7%) reported that it took them less than 6 months.\n17.8% even said that it only took them less than a month.\n12.7% needed more than a year to feel comfortable with the language. This number is slightly higher than the last year.\n17.4% don't feel productive yet, out of which 76.7% are beginners and have been using Solidity for 6 months or less, and 45% even less than three months.\n\nSolidity User Profile & Usage Habits\nA majority of 46.5% users use Solidity on a daily basis, followed by 33.2% who use it weekly and only 11.9% who use it on a monthly basis.\nAs low as 1.9% said that they never use Solidity. 6.5% users reported that they use it rarely.\n\nThis year, we also wnated to learn how the survey audience gets the Solidity binaries. The most mentioned sources were:\n\nvia a framework / IDE (38.8%)\nusing npm (18.6%)\nGitHub Releases (9.6%)\nBuild from source (9.3%)\nsolc-bin (6.8%)\nHomebrew (6.1%)\n\nOther lesser prominent sources were Ethereum PPA for Ubuntu, Package Manager for Linux Distros, and Dockerhub.\n\n77.2% of all respondents use Visual Studio Code as their editor when writing Solidity code. However, this number is still lower than last year.\nVim and IntelliJ follow in the second and third ranks with 4.7 and 3.7% usage, respectively. The overall trend in usage of prominent editors continues to remain comparable.\n\nDepending on the chosen editor, we also asked respondents which Solidity-related plugins they use, if any.\nJust like last year, the “Solidity” extension by Juan Blanco and “HardHat VSCode” by Nomic Foundation were once again found to be the most popular among Solidity developers.\n\nWe wanted to know which Ethereum specific development environment our survey participants use.\nWith 33.3%, Hardhat remains the most popular Ethereum-specific development environment.\nHowever, this percentage is significantly lower than in 2022 results, when roughly 75% of all respondents were using Hardhat.\nNot too far behind, Foundry ranks second with 32% and Remix follows closely with 25.8%. After rising in popularity from 1.6% in 2021 to 30% in 2022, Foundry seems to have been comparable in usage since last year.\nTruffle moves further into the \"OTHER\" list with only 3 respondents indicating its usage.\nWhile Dapp rises slightly higher in usage with 3.1% users, Brownie (1.6%), Truffle (0.3%), Ape (0.3%), and Embark (0.3%) seem to be the less popular choices this year ranking even lower in usage than the previous year.\nWith 0.5% of votes, Wake made it into the graph this year as a new choice of IDE.\nAs low as 2% of respondents do not use any Ethereum-specific development environment at all.\n\nSimilar in trend as last year, the 0.8.x Solidity versions remain to be most used versions with a majority of 397 out of 485 total votes (81.8%).\nPlease note that this is a multiple response type question allowing for participants to choose more than one version series.\nThe usage share of both the 0.7.x (4.7%) and the 0.6.x (5.5%) series continues to decrease consistently since the previous survey. The rest of the older versions are rarely in use.\n\n⚠️ Important Reminder: Please make sure to frequently update your code (and compiler) to the latest Solidity version. Several important bug fixes and security improvements are added in the newer versions!\nSolidity Usage Details\nJust like last year, we also asked our users specific questions about Solidity usage trends.\nCLI\n59.9% of respondents do not use the Solidity compiler directly via the command line, whereas 40.1% do. This trend is consistent with last year.\n\nWhen using the compiler on the command line, 58.9% still use Standard JSON.\n\nWhen asked how disruptive changes in CLI options and outputs would be for respondents, 64.1% responded with \"okay\" and 26.5% with \"Not disruptive at all\". Only 9.4% deem these changes as disruptive.\n\nOld EVM versions\nWhile 28.8% of the overall respondents still rely on old EVM versions, a majority of 71.2% do not need compiler support for older EVM versions anymore.\n\nAmong those who rely on older version, 11.1% still rely on deprecated EVM versions.\n\nUnoptimised code\n20.8% said that they never use unoptimised code. On the other hand, 27.9% use unoptimised code only because of their framework's default settings, whereas 48.8% users do so for the purpose of debugging, unit testing, or deploying on chain.\n\nABIEncoderV1\nWhile 63.9% do not use ABIEncoderV1, only 6.5% know about it and use it. 29.6% do not know about it at all.\n\nSMTChecker\n74.5% of all respondents have never used the SMTChecker. 20.1% have tried it and 5.4% use it frequently. You can learn more about the SMTChecker here. The percentage of users who have tried it has increased significantly this year.\n\nThe via-IR compilation pipeline\n51.9% do not know what via-IR is. This number has significantly reduced from last year. 25.9% use the via-IR pipeline already. In the following weeks, we intend to write a blog post about what via-IR is and why you should switch from the legacy compilation pipeline to via-IR.\n\nWhen asked about the time taken to compile the contract's code using via-IR pipepline, the majority of the respondents indicated that it takes anywhere between 1 to 10 minutes.\nSome users also reported that it can also take anywhere from 15 minutes to upto 60 minutes.\nSome outliers in the responses also indicated as long as 300 and 200000 minutes. However, we do not consider these responses to be accurate and hence, the chart does not account for those responses.\n\nWhen asked what users are most concerned about regarding the use of via-IR, 27.4% said compilation times, 21.4% said not enough knowledge, 17.9% said stability/security concerns, and 13.5% said lack of tooling.\n\nMetadata publication\n55.2% of respondents stated that they publish the metadata of their smart contracts which has slightly increased from last year.\n30.3% don’t publish the metadata of their smart contracts while 14.5% don’t know what this means. Both these numbers have significantly improved from last year.\n\nSourcify\nWhen asked about Sourcify usage, 14.2% of all respondents use Sourcify for smart contract verification (increased from last year), while 30.7% claim to not need it. 55% don’t know what Sourcify is, which has reduced from last year.\n\nA majority of 37.1% users use Sourcify via Hardhat, followed by via Foundry (27.4%), via Sourcify directly (16.1%), and via Remix (14.5%). If you want to learn more about Sourcify, visit sourcify.dev.\n\nappendCBOR: false or bytecodeHash: none\n55% users do not know what appendCBOR: false or bytecodeHash: none is, whereas 30.8% know but do not need it. Only about 13.7% either use it frequently or sometimes.\n\nFlattening contracts\n53.9% of total respondents do not flatten their contracts, whereas 22.5% do. 23.6% do not know what that is or how to do it.\nMost of the users who flatten their contracts mentioned that they do so for the purpose of verification.\n\nOther EVM Networks\nMore than half of all respondents (65.1%) use Solidity outside of Ethereum Mainnet and testnets.\nWhen asked which other networks they deploy their smart contracts on, 20.8% responded with Polygon (formerly Matic Network).\nOther often mentioned blockchains include Arbitrum (15.6%), Optimism (13.2%), Binance Smart Chain (10.6%), and Avalanche (8.1%).\n\nOther Smart Contract Languages\nYul, an intermediate language for Solidity, continues to the be the most used smart contract language other than Solidity with 23.9% respondents; a slight increase compared to last year.\nVyper, a pythonic EVM language, ranks as the second most used language other than Solidity with 11.9%.\nThis trend is similar to last year so far with just a small increase in the percentages.\nHuff (9.3%), Cairo (5.8%), and Sway (2.1%) make it to the list second year in a row.\nFe (1.8%) also makes it into the chart again this year. However, Rust was not mentioned often.\n\nSolidity Developer Experience\nIn this next section of the survey, we will be going through the developer experience of our user community.\nWhen asked about the overall improvement in the Solidity developer experience, 76% of all respondents generally believe that it has improved in the last year with 20.2% even believing it was a big improvement.\nAs low as 1.6% of the respondents are of the opinion that the developer experience has gotten worse.\n\nRecurring Issues\nWhen asked if the participants encounter recurring issues, 53.3% of the total respondents said that they do not come across the same or similar issues multiple times when developing in Solidity.\nAmong the 46.7% that encounter recurring issues, Stack too deep issues are encountered most frequently, followed by Bytecode size limit and Debugging issues.\n\n_ℹ️ Note: On the topic of debugging issues, we would to remind you about the ethdebug standards development working group, an initiative aimed at defining a common debugging data format for languages built on top of the EVM: ethdebug.\nWe encourage all developers working on such tools to join the working group. The group has regular bi-weekly meetings and coordinates via the ethdebug Matrix channel._\nGetting Started with the Compiler\nWhen asked how easy was it to get started with the Solidity compiler, most respondents are of the opinion that it is very easy (44.8%) or “okay” (50.9%).\nAs less as 4.3% shared that it was difficult for them to get started with the compiler. When asked what made it difficult to get started, some mentioned lack of good docs and examples.\n\nMost liked Aspects/Features & Pain Points\n23.5% of respondents most like Solidity's similarity to other programming languages.\nOthers like it is easy to learn (17.4%), statically typed (16.3%), simple (15.4%).\nSome also consider its syntax (12.7%) and the ease of reading (10.4%) as the most likeable aspects.\n\n33.8% of the respondents consider mappings as their most liked feature, followed by contracts as objects (23.2%).\nModifiers (16.1%) and Inline Assembly (12.6%) were often mentioned as well.\nSome users reported user defined types (6%), dynamic arrays (3.4%), and using for (2.5%) as their most liked features.\n\nWhen we asked the participants about their biggest pain points with Solidity, Stack too deep errors ranked the highest with 42% of all votes, followed by missing memory optimizations (21.6%) and compiler performance (13%).\n8.6% of respondents said that redundant checks (e.g. in checked arithmetic) is their biggest issue.\nAlmost 11% selected “OTHER” and specified some of their most significant pain points, namely: Bytecode and contract size limit and errors.\n\nDocumentation\nWhen asked if the participants find the official documentaiton helpful, 68% of the survey respondents reported the Solidity documentation to be helpful, followed by 29.1% who consider it somewhat useful.\nAs low as 2.9% voted that they do not find the docs useful at all.\nIdeas for improvement most prominently ask for more code examples but also a better high-level overview of syntax, better in-docs search, and overall better UI/UX.\n\nHigh-Impact Compiler Bugs\nWe were curious to find out whether Solidity developers had been affected by any of the high-impact compiler bugs (codegen bugs that are announced with Security Alerts on the Solidity blog).\nWhile 95.7% said they haven't been affected, 4.3% claimed that they were.\nWhen asked which one they were affected by, here's what we found out:\n(double check if reported bugs are genuine and list accordingly)\n\nExternal Libraries\nThe majority of the survey respondents (47.8%) do not use external libraries at all.\nHowever, 42.7% reported that they use it and specified use-cases such as contract splitting, proxy patterns, and sharing code.\nOnly 9.5% users do not know what external libraries are (or what they are being used for).\n\nLanguage Design & Upcoming Features\nIn the following section of the survey, we will take you through the insights we drew from asking our participants about their thoughts on and involvement in the Solidity language design updates and efforts.\nMost Anticipated Feature(s)\n23.2% of total respondents shared that their most anticipated feature is the support for generics, followed by 17.4% reporting that they most look forward to the Require with custom error types feature.\n⚠️ Note: Similar to the previous year, we have categorized the use of verious terms like \"floats\", \"floating point arithmetic\", \"floating point number\", \"fixed point numbers\", and \"fixed point math\" as \"decimal numbers\".\nOther most anticipated features in descending order:\n\nTransient storage (13%)\nSolving stack-too-deep errors (11.6%)\nBetter gas optimizations & debugging tools (10.1%)\nSupport for decimal numbers & Dynamic Memory Arrays (7.2%)\n\nRestrictiveness\nWhen we asked the survey participants about their thoughts on language restrictiveness, 44.7% of respondents wish that Solidity stays “as is”.\nAbout 35.6% would generally prefer more restrictive/explicit behaviour, while approximately 19.6% would prefer Solidity to be less restrictive.\nThe overall results of this question are comparable across the previous year and this year.\n\nFeedback on New Features/Improvements\nWe asked the participants about their thoughts on postfix types and functional elements in Solidity.\nHere's what we found out about:\n\nPostfix Types: While 72.5% respondents that formed a majority explicitly said that they either don't like postfix types or don't care, 27.5% said that they like them.\n\nFunctional Elements: Almost 60% users said that they like the idea of more functional elements in Solidity such as Lamda functions. 15.4% said they don't like them and 24.7% are indifferent towards it.\n\nEIP Support\nWe also wanted to know what Solidity-related EIPs the survey respondents know about or look forward to using and why.\nLet's look at some useful insights about:\n\nEIP-1153 “Transient Storage”: 40.1% respondents know about the Transient Storage EIP, whereas 59.9% do not. 40.4% said that they would need complex types in Transient Storage, such as mappings and arrays, and the rest of the audience was equally divided between not needing complex types and being indifferent/unaware of it.\n\nEIP-3540 “EOF - EVM Object Format”: It was interesting to see that only 28.6% respondents know about EOF. Among the 28.6%, 63.5% feel positively about it and only 4.8% are of the opinion that it will negatively impact them as developers.\n\nLanguage Design Related Efforts\nWhen asked whether the respondents have or continue to participate in the language design efforts, here's what we found:\n\nA majority of almost 86% respondents said that they do not participate because they are either too busy, or uninterested/underqualified, or do not know how to participate.\nRoughly 14.2% of respondents said that they regularly participate in language design efforts either by joining the calls, the forum discussions, or by proposing new features or language changes on GitHub.\n18.5% specifically mentioned that the reason for their lack of participation is either lack of interest or skills require in order to participate in these efforts.\n\nAt Solidity, we have and would like to continue to make it easier to our community to participate more actively in these discussions and feel empowered enough to contribute to the language design decisions.\n\nSolidity Developer Community\nStaying up-to-date\nA slightly new trend from the previous years is that this year, most people reported that they like to stay up-to-date about Solidity versions, security alerts, and announcements by following the Solidity GitHub Releases page, followed by Solidity Twitter or Mastodon.\nAnother often mentioned means of information is the Solidity blog.\nInterestingly, about 21.2% claim to not be doing any of the above.\nAs part of “other”, respondents specified several community based means to stay up-to-date:\n\n\"Crypto influencers\" / Popular Solidity developers\nDiscord servers\nGoogle\nCrypto Twitter / Community chats / Farcaster channels\nNewsletters\nOther blogs such as Moralis and OpenZeppelin\nSolidity docs\nSolidity website\nTutorials on YouTube\nReddit\n\"Week in Ethereum News\" Newsletter\n\nInteraction with Other Solidity Developers\nMore than half of respondents (56.8%) interact with other Solidity developers whereas 25.7% admitted that they rarely interact with other Solidity devs.\nA smaller portion of that chart 17.5% does not interact with other Solidity developers at all.\n\nLike in the previous years, as the last part of the survey, we wanted to hear how many participants agree or disagree with certain statements regarding the Solidity community and the work of the Solidity team.\nStatement 1: I feel welcome in the Solidity developer community.\n46.8% of respondents feel welcome in the Solidity developer community and 26.1% somehwat agree with the statement. Almost 5% still feel unwelcome.\nStatement 2: I am confident with the work of the Solidity core team.\nA majority of roughly 80% agree or somewhat agree that they feel confident in the work of the Solidity team. A small portion of the survey audience (6.4%) does not agree with this statement.\nStatement 3: The Solidity team understands my needs as a developer.\nAbout 68% either agree or somewhat agree with the above statement. 23.2% do not know how they feel about this, whereas about 8.8% of the audience generally disagrees.\nStatement 4: The options for how to contribute ideas or feedback to Solidity are clear to me.\nA majority of 47% of the survey audience agrees that the options for how to contribute ideas or feedback to the team are clear to them. However, almost as high as 26% still aren't clear about how to contribute ideas or feedback. It can be derived from this that communication around this needs to be bolstered.\nStatement 5: I am receiving adequate feedback from the Solidity team on issues raised on Github and/or forum posts.\n50% of the audience does not know how to feel about this statement.\nHowever, about 40% respondents are generally satisfied with the feedback and inputs they get from the Solidity team regarding their contributions. Whereas 10% disagree or strongly disagree to this.\nThe results of this “community and Solidity team confidence ranking” are consistent with the results from the previous year.\n\nThank You!\nLastly, we want to take the opportunity to thank you for all your survey responses and feedback. We aim to continue this tradition annualy!\nWe hope that the insights from this survey continue to be valuable to the Solidity ecosystem and community as they are to us!\nTo stay up-to-date with all Solidity related announcements and updates, make sure to:\n\nFollow Solidity on Twitter or Mastodon.\nJoin the language design discussions in the Solidity forum or provide us feedback there.\nFollow announcements and security alerts on the Solidity blog.\nFollow and ⭐ the Solidity repo on Github.\n\nAll graphs can be found here. The raw and analyzed data can be found here.Previous postNext post","tokens":7349,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266063542,"hash":"cb0e139ac88ab0dd36158cf1d02d08e138908297"}
{"url":"https://docs.optimism.io/node-operators/tutorials/run-node-from-source","domain":"docs.optimism.io","title":"Optimism Documentation","text":"op-geth has reached end-of-support (2026-05-31) and does not support the now-active Karst hardfork, so op-geth nodes can no longer follow the canonical chain. Migrate to op-reth, the primary supported execution client. See the op-geth deprecation notice for the full migration plan.\nThis tutorial walks through the full process of building and running an OP Stack node from source — op-node plus an execution client. Building from source is a flexible alternative to using pre-built Docker images and is useful if you need a specific architecture or want to inspect what you’re running.\nIt builds and runs op-reth and Nethermind; op-geth instructions are retained in a legacy section at the bottom for operators mid-migration.\nFor permissionless chains setting up historical proofs for withdrawal proving, follow this tutorial first to get a working node, then continue with Running op-reth with Historical Proofs.\n​Hardware requirements\nHardware requirements for OP Mainnet nodes can vary depending on the type of node you plan to run.\nArchive nodes generally require significantly more resources than full nodes.\nBelow are suggested minimum hardware requirements for each type of node.\n\n16GB RAM\nReasonably modern CPU\n\n​SSD capacity requirements\nGiven the growing size of the blockchain state, choosing the right SSD size is important.\nBelow are the storage needs as of June 2025:\n\nFull Node: The snapshot size for a full node is approximately 700GB, with the data directory’s capacity increasing by about 100GB every six months.\nArchive Node: The snapshot size for an archive node is approximately 14TB, with the data directory’s capacity increasing by about 3.5TB every six months. A local SSD with a NVME interface is recommended for archive nodes.\n\nPlan for future storage needs and choose SSDs that can handle these increasing requirements.\n​Software dependencies\nThe build environment is managed through mise, which installs and manages the toolchains (Rust, Go) needed to build the monorepo. The mise configuration lives in mise.toml at the monorepo root.\n​Build op-node and the execution client\nThe Optimism Monorepo does coordinated releases — each release commit is tagged simultaneously across components (op-node, op-reth, kona-node, etc.). Pinning to one release tag gives you a known-good combination of all of them built from the same source state. Look up the latest tags on the Optimism releases page.\n1Clone the Optimism MonorepoThe monorepo contains the source for both op-node and op-reth.git clone https://github.com/ethereum-optimism/optimism.git\ncd optimism\n2Pin to a release commitCheck out a recent op-node release tag — the same commit carries the matching op-reth tag. For example, op-node/v1.18.2 is co-tagged with op-reth/v2.2.4:git checkout op-node/v1.18.2\nop-reth/v2.2.3 or later is required to enable the historical proof store v2 (--proofs-history.storage-version=v2). The op-node/v1.18.x release line carries op-reth ≥ v2.2.3, so any of those tags satisfies that requirement.3Build op-nodecd op-node && just && cd ..\nBinary: op-node/bin/op-node (relative to the monorepo root).4Build the execution client op-reth Nethermindop-reth lives inside the monorepo at rust/op-reth/ — no second git clone needed.cd rust/op-reth && cargo build --release --bin op-reth && cd ../..\nBinary: rust/target/release/op-reth (relative to the monorepo root). rust/ is a Cargo workspace, so the target/ directory lives at the workspace root, not inside the individual crate. Build outputs are gitignored, so they persist across any future git checkout.Nethermind is an alternative execution client written in .NET. Prerequisites: .NET SDK 9 or later.git clone --recursive https://github.com/nethermindeth/nethermind.git\ndotnet build nethermind/src/Nethermind/Nethermind.sln -c release\nBuild artifacts: nethermind/src/Nethermind/artifacts/bin/Nethermind.Runner/release/. See the Nethermind documentation for more.\n​Assess blob archiver\nAssess if you need to configure a blob archiver service by reading Configure a Blob Archiver.\n​Create a JWT secret\nThe execution client and op-node communicate over the engine API authrpc, secured with a shared 32-byte hex secret. Both binaries must read the same secret file. The commands below use a relative path (./jwt.txt) for each binary, so the same content must exist at both launch directories.\n1Generate the secretFrom the monorepo root:openssl rand -hex 32 > jwt.txt\nThis creates optimism/jwt.txt.2Copy to the op-node launch directorycp jwt.txt op-node/jwt.txt\n3Copy to the op-reth launch directoryThe op-reth binary lives at rust/target/release/op-reth and the tutorial launches it from rust/, so place the JWT there:cp jwt.txt rust/jwt.txt\n\nThe two copies must remain identical — if you regenerate one side, copy it over to the other before restarting.\n​Start the execution client\nIt’s generally easier to start the execution client before op-node. The EL will simply not receive any blocks until op-node is started.\n op-reth Nethermind1Navigate to the rust workspace directoryop-reth is built into the workspace target dir, so launch from optimism/rust/:cd /path/to/optimism/rust\nThe binary is then at ./target/release/op-reth.2Set environment variablesexport DATADIR_PATH=... # Path to the desired data directory for op-reth\n3Start op-rethFor archive-node configuration (historical state for withdrawal proving), see the OP Mainnet archive nodes section.The JSON-RPC API will become available on port 8545. See the op-reth configuration reference for the full flag set../target/release/op-reth node \\\n --chain=optimism_sepolia \\\n --datadir=$DATADIR_PATH \\\n --http \\\n --ws \\\n --authrpc.jwtsecret=./jwt.txt \\\n --rollup.sequencer=https://sepolia-sequencer.optimism.io\nFor OP Mainnet, set --chain=optimism and --rollup.sequencer=https://mainnet-sequencer.optimism.io.1Navigate to your Nethermind directoryFind the directory where you built the Nethermind binary.2Start NethermindFor an archive node, use the op-sepolia_archive configuration instead of op-sepolia. For OP Mainnet, use op-mainnet or op-mainnet_archive respectively.The JSON-RPC API will become available on port 8545. See the execution clients configuration guide for more options../Nethermind.Runner \\\n -c op-sepolia \\\n --data-dir path/to/data/dir \\\n --JsonRpc.JwtSecretFile=./jwt.txt\nThis uses the built-in op-sepolia configuration which includes JSON-RPC endpoints, network ports, sequencer URL, and other OP Stack-specific settings.\n​Start op-node\nOnce your execution client is running, start op-node. It will connect to the EL and begin synchronizing the chain.\n1Navigate to the op-node directoryop-node is built into its own crate directory, so launch from optimism/op-node/:cd /path/to/optimism/op-node\nThe binary is then at ./bin/op-node.2Set environment variablesexport L1_RPC_URL=... # URL for the L1 node. Local default: http://127.0.0.1:8545\nexport L1_RPC_KIND=... # alchemy, quicknode, infura, parity, nethermind, debug_geth, erigon, basic, any\nexport L1_BEACON_URL=... # URL for the L1 Beacon HTTP endpoint. Local default: http://127.0.0.1:3500\n3Start op-nodeThe op-node RPC should not be exposed publicly. If left exposed, it could accidentally expose admin controls to the public internet.--syncmode=execution-layer enables snap sync, which works for both op-reth and Nethermind and removes the need to initialize the node with a data directory.--l2.enginekind tells op-node which kind of execution client it is driving. The binary defaults to reth, so this flag is shown for clarity and can be omitted when pairing with op-reth../bin/op-node \\\n --l1=$L1_RPC_URL \\\n --l1.rpckind=$L1_RPC_KIND \\\n --l1.beacon=$L1_BEACON_URL \\\n --l2=ws://localhost:8551 \\\n --l2.jwt-secret=./jwt.txt \\\n --network=op-sepolia \\\n --syncmode=execution-layer \\\n --l2.enginekind=reth\nSome L1 nodes (e.g. Erigon) do not support eth_getProof. Add --l1.trustrpc if your L1 doesn’t support it — this means op-node trusts the L1 node to provide correct data.\n​Synchronization verification\nOnce the EL and op-node are running, you should see them begin to communicate and synchronize.\n​Snap sync (default)\nInitial synchronization can take several hours. At the start of snap sync, op-node will log:\nINFO [03-06|10:56:55.602] Starting EL sync\nINFO [03-06|10:56:55.615] Sync progress reason=\"unsafe payload from sequencer while in EL sync\" l2_finalized=000000..000000:0 l2_safe=000000..000000:0 l2_pending_safe=000000..000000:0 l2_unsafe=4284ab..7e7e84:117076319 l2_time=1,709,751,415 l1_derived=000000..000000:0\nINFO [03-06|10:56:57.567] Optimistically inserting unsafe L2 execution payload to drive EL sync id=4ac160..df4d12:117076320\n\nStarting EL sync is shown once and the sync-progress / inserting logs repeat until done. op-node will log the following when finished:\nlvl=info msg=\"Finished EL sync\" sync_duration=23h25m0.370558429s finalized_block=0x4f69e83ff1407f2e2882f2526ee8a154ac326590799889cede3af04a7742f18d:116817417\n\nThe execution client logs its own header- and state-download progress in parallel:\n op-reth Nethermindop-reth logs sync stages (headers, bodies, execution, state root) with periodic progress lines. Monitor the op-reth logs to confirm it is advancing through stages alongside the op-node Sync progress lines.Snap sync in Nethermind works by:\nDownloading only the leaf nodes of the state tree\nGenerating intermediate nodes locally\nVerifying the state root matches\nThis approach is up to 10 times faster than traditional full sync.\n​Full sync\nFull sync rebuilds the chain from genesis and can take days to weeks on mature networks. Most operators should use snap sync (above) or bootstrap from a pre-synced snapshot. Full-sync configuration is client-specific:\n op-reth Nethermindop-reth’s snap sync is the recommended initialization path. For alternative sync configurations, see the op-reth configuration reference.To use full sync with Nethermind, set:./Nethermind.Runner \\\n -c op-sepolia \\\n --Sync.SnapSync=false \\\n --Sync.FastSync=false \\\n --data-dir path/to/data/dir \\\n --JsonRpc.JwtSecretFile=./jwt.txt\nFull sync will download and verify every block from genesis, which takes significantly longer than snap sync but provides the strongest security guarantees.\nAfter the initial sync, op-node derives L1 batches into L2 blocks and feeds them to the execution client. You’ll see logs like:\nINFO [06-26|13:31:20.389] Advancing bq origin origin=17171d..1bc69b:8300332 originBehind=false\nINFO [06-26|14:00:59.460] Sync progress reason=\"processed safe block derived from L1\" l2_safe=7fe3f6..900127:4068014 l2_unsafe=7fe3f6..900127:4068014 l1_derived=6079cd..be4231:8301091\nINFO [06-26|14:00:59.461] generated attributes in payload queue txs=1 timestamp=1,673,564,098\nINFO [06-26|14:00:59.463] inserted block hash=e80dc4..72a759 number=4,068,015 update_safe=true\n\nThe execution client logs its own block-import progress in parallel; refer to its documentation for log specifics.\n​OP Mainnet archive nodes\nYou only need an archive node if you need historical state. Most node operators should default to full nodes.\nFor op-reth, historical state for withdrawal proving is configured via either --rpc.eth-proof-window (no separate proofs database; size to your dispute-game cadence) or --proofs-history (bounded memory, larger storage). See:\n\nRunning op-reth with Historical Proofs — full setup for --proofs-history (v2) on op-reth v2.2.3+.\nArchive node guide — flag overview for both paths.\nOP Mainnet snapshots — pre-synced op-reth datadirs to bootstrap from.\n\n​Legacy Geth (pre-Bedrock, optional)\nBlocks and transactions included in OP Mainnet before the Bedrock Upgrade cannot be executed by modern OP Mainnet nodes. Modern nodes serve these blocks but cannot run stateful queries like eth_call against them. For complete archive coverage of pre-Bedrock OP Mainnet state, run a Legacy Geth (l2geth) node alongside your modern node. This is only relevant to OP Mainnet archive nodes; skip if running a full node or OP Sepolia.\n1Build l2gethgit clone https://github.com/ethereum-optimism/optimism-legacy.git\ncd optimism-legacy/l2geth\nmake\n2Download the legacy Geth data directoryDownload the snapshot from Legacy Geth Data Directory (2.9TB) and verify:sha256sum mainnet-legacy-archival.tar.zst\n# Expected: 4adedb61125b81b55f9bdccc2e85092050c65ef2253c86e2b79569732b772829\nThen extract:tar xvf mainnet-legacy-archival.tar.zst\n3Start l2gethUSING_OVM=true \\\n ETH1_SYNC_SERVICE_ENABLE=false \\\n RPC_API=eth,rollup,net,web3,debug \\\n RPC_ENABLE=true \\\n RPC_PORT=8546 \\\n ./build/bin/geth --datadir /path/to/l2geth-datadir\n\n​op-geth (legacy, end of support 2026-05-31)\nop-geth has reached end-of-support (2026-05-31) and does not support the now-active Karst hardfork, so op-geth nodes can no longer follow the canonical chain. Migrate to op-reth, the primary supported execution client. See the op-geth deprecation notice for the full migration plan.\nBuild and run op-geth (legacy)Pair op-geth with op-node by setting --l2.enginekind=geth instead of reth in the op-node command above.​Build op-geth1Clone op-gethgit clone https://github.com/ethereum-optimism/op-geth.git\ncd op-geth\n2Check out the required release branchCheck the op-geth releases page for the correct branch.git checkout <name of release branch>\n3Build op-gethmake geth\n​Start op-gethFor an archive node, also set --gcmode=archive../build/bin/geth \\\n --http \\\n --http.port=8545 \\\n --http.addr=localhost \\\n --authrpc.addr=localhost \\\n --authrpc.jwtsecret=./jwt.txt \\\n --verbosity=3 \\\n --rollup.sequencerhttp=https://sepolia-sequencer.optimism.io/ \\\n --op-network=op-sepolia \\\n --datadir=$DATADIR_PATH\nThe op-geth configuration reference has been retired; see the op-reth configuration reference for the equivalent op-reth flags.​op-geth snap-sync stagesop-geth’s snap sync runs in two stages — header download then state download:lvl=info msg=\"Syncing beacon headers\" downloaded=116775778 left=1162878 eta=53.182s\nlvl=info msg=\"Syncing: state download in progress\" synced=99.75% state=\"191.33 GiB\" accounts=124,983,227@25.62GiB slots=806,829,266@165.16GiB codes=78965@566.74MiB eta=-2m7.602s\nmsg=\"Syncing: chain download in progress\" synced=100.00% chain=\"176.01 GiB\" headers=116,817,399@45.82GiB bodies=116,817,286@52.87GiB receipts=116,817,286@77.32GiB eta=77.430ms\nOnce synced, op-geth logs block imports as op-node feeds payloads:INFO [06-26|14:02:12.974] Imported new potential chain segment number=4,068,194 hash=a334a0..609a83 blocks=1 txs=1\nINFO [06-26|14:02:12.976] Chain head was updated number=4,068,194 hash=a334a0..609a83\n\n​Next steps\n\nIf your node is up and running, check the Node Metrics and Monitoring Guide to keep tabs on it.\nIf you run into problems, see the Node Troubleshooting Guide.\nFor permissionless chains setting up withdrawal proving, continue with Running op-reth with Historical Proofs.\nWas this page helpful?","tokens":3708,"squid":"ink-governance","role":"Council Listener","at":1791266063708,"hash":"a5f69fe40841e114bcbccfa0a67e9ae4359982a4"}
{"url":"https://docs.optimism.io/node-operators/guides/troubleshooting","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This page lists common troubleshooting scenarios and solutions for node operators.\n​401 Unauthorized: Signature Invalid\nIf you see a log that looks like this in op-node:\nWARN [12-13|15:53:20.263] Derivation process temporary error attempts=80 err=\"stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch current L2 forkchoice state: failed to find the finalized L2 block: failed to determine L2BlockRef of finalized, could not get payload: 401 Unauthorized: signature is invalid\n\nIt means that the op-node is unable to authenticate with execution client’s authenticated RPC using the JWT secret.\n​Solution\n\nCheck that the JWT secret is correct in both services.\nCheck that execution client’s authenticated RPC is enabled, and that the URL is correct.\n\n​Failed to Load P2P Config\nIf you see a log that looks like this in op-node:\nCRIT [12-13|13:46:21.386] Application failed message=\"failed to load p2p config: failed to load p2p discovery options: failed to open discovery db: mkdir /p2p: permission denied\"\n\nIt means that the op-node lacks write access to the P2P discovery or peerstore directories.\n​Solution\n\nMake sure that the op-node has write access to the P2P directory. By default, this is /p2p.\nSet the P2P directory to somewhere the op-node can access via the --p2p.discovery.path and --p2p.peerstore.path parameters.\nSet the discovery path to memory to disable persistence via the --p2p.discovery.path and --p2p.peerstore.path parameters.\n\n​Wrong Chain\nIf you see a log that looks like this in op-node:\n{\"attempts\":183,\"err\":\"stage 0 failed resetting: temp: failed to find the L2 Heads to start from: wrong chain L1: genesis: 0x4104895a540d87127ff11eef0d51d8f63ce00a6fc211db751a45a4b3a61a9c83:8106656, got 0x12e2c18a3ac50f74d3dd3c0ed7cb751cc924c2985de3dfed44080e683954f1dd:8106656\",\"lvl\":\"warn\",\"msg\":\"Derivation process temporary error\",\"t\":\"2022-12-13T23:31:37.855253213Z\"}\n\nIt means that the op-node is pointing to the wrong chain.\n​Solution\n\nVerify that the op-node’s L1 URL is pointing to the correct L1 for the given network.\nVerify that the op-node’s rollup config/--network parameter is set to the correct network.\nVerify that the op-node’s L2 URL is pointing to the correct instance of execution client, and that execution client is properly initialized for the given network.\n\n​Error: eth_sendRawTransaction Does Not Exist\nIf an RPC call to your execution client (op-reth, Nethermind, etc.) returns a response like:\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"error\": {\n \"code\": -32601,\n \"message\": \"the method eth_sendRawTransaction does not exist/is not available\"\n }\n}\n\nThis -32601 JSON-RPC error means the sequencer endpoint you configured does not expose eth_sendRawTransaction. The request path looks like:\nClient → eth_sendRawTransaction → execution client:8545\n ↓\n EL forwards to sequencer (--rollup.sequencer URL)\n ↓\n eth_sendRawTransaction → op-node:8547\n ↓\n ❌ ERROR: \"method does not exist/is not available\"\n (op-node has no eth namespace!)\n\nBecause op-node only exposes rollup-specific RPC methods—there is no eth_* namespace—it cannot accept raw transaction submissions. When your execution client forwards the transaction to an op-node URL it immediately fails with -32601.\nThis situation almost always happens when op-reth’s --rollup.sequencer (aliases --rollup.sequencer-http, --rollup.sequencer-ws) is misconfigured to point at your own op-node rather than the chain’s actual sequencer.\n​Solution\n\nConfirm op-reth exposes the eth namespace on its HTTP API (the standard set is --http.api=eth,net,web3,debug). If eth is disabled, raw transactions will be rejected before they reach the sequencer.\nInspect the CLI flags and environment variables of every component that talks to the sequencer (op-node, op-reth, op-batcher, op-proposer, scripts). The --rollup.sequencer flag must point to the chain’s public sequencer endpoint (for example, https://mainnet-sequencer.optimism.io), not to your own op-node.\nFor user-deployed L2s where you run the sequencer yourself, leave --rollup.sequencer unset so op-reth forwards locally and never falls back to an op-node endpoint.\nRestart the affected services after correcting the flag so they pick up the new endpoint. The error should disappear as soon as they can reach the proper sequencer RPC.\n\n​Unclean Shutdowns\nAn unclean shutdown occurs when the execution client stops without completing its normal shutdown procedure — for example, a SIGKILL, a power loss, or a container killed past its grace period. The impact depends on which database backend your EL uses.\nTo minimize risk, always shut down gracefully: Ctrl-C for foreground processes, docker stop -t 300 <container> for Docker, or systemctl stop for systemd (override the default 90s timeout if your EL has a large in-memory write to flush).\n​For op-reth\nop-reth uses MDBX, which is crash-safe by design. After an unclean shutdown the node typically restarts cleanly with no operator intervention required.\nIf startup fails after an unclean shutdown, options include:\n\nStage unwind — roll back to the last consistent stage checkpoint:\nop-reth stage unwind to-block <BLOCK_NUMBER> --datadir=<path>\n\nFull resync — as a last resort, delete the datadir and resync from genesis or a snapshot.\n\n​For Nethermind\nUnclean shutdowns in Nethermind can lead to database corruption. This typically happens when:\n\nThe node experiences hardware failures (disk failures, memory errors, overheating)\nPower cuts cause abrupt shutdowns\nThe process is terminated without proper cleanup\n\nSolutions\n\nLock File Issues\nIf Nethermind complains about lock files after an unclean shutdown, run:\nfind /path/to/nethermind_db -type f -name 'LOCK' -delete\n\nBlock Checksum Mismatch\nIf you encounter block checksum mismatch errors, you can enable direct I/O:\n--Db.UseDirectIoForFlushAndCompactions true\n\nNote: This may impact performance.\n\nComplete Resync\nIn cases of severe corruption, a full resync is recommended:\nsudo systemctl stop nethermind\nsudo rm -rf /path/to/nethermind_db/mainnet\nsudo systemctl start nethermind\n\nWas this page helpful?","tokens":1520,"squid":"ink-governance","role":"Council Listener","at":1791266085725,"hash":"df6c12abddcaa741a6ba4c6c7df1b0afefa313f2"}
{"url":"https://dev-forum.pyth.network/t/price-feed-in-avalanche-not-working/460","domain":"dev-forum.pyth.network","title":"Price feed in Avalanche not working - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price feed in Avalanche not working \n\n Price Feeds\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2025\n\n 1 / 2\n\n Oct 2025\n\n Oct 2025\n\n post by neethu on Oct 30, 2025\n\n neethu\n\n I have trouble using the Core - Push based to get the price feed in Avalanche fuji network. I used the pyth contract 0x23f0e8FAeE7bbb405E7A7C3d60138FCfd43d7509. And gave price feed ID ETH/USD as given in the documentation.\nPythStructs.Price memory priceObject = pyth.getPriceNoOlderThan(0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace, 60);\nI called the view function\nAn unexpected error occurred:\nError: execution reverted (unknown custom error) (action=“call”, data=“0x19abf40e”, reason=null, transaction={ “data”: “0x8fe20099”, “to”: “0xef…sD” }, invocation=null, revert=null, code=CALL_EXCEPTION, version=6.15.0)\nAm I missing something with the exact price feed ID for avalanche fuji testnet? Thank you in advance.\n\n post by KemarTiti on Oct 31, 2025\n\n KemarTiti\n\n The contract is correct: 0x23f0e8FAeE7bbb405E7A7C3d60138FCfd43d7509\nThe ETH/USD price feed is indeed: 0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace ; ids page.\nThe error you are encountering is because the price of ETH/USD has not been updated recently enough on Avanlanche testnet.\nYou can check here the classic errors on EVMs and how to troubleshoot those.\nIn your case, to resolve this issue:\n\nUpdate the prices by calling updatePriceFeeds() by passing the latest updateData from Hermes.\nAnother method to fetch the price is getPriceUnsafe() If the price feed is available, the method will return the latest prices with timestamp of last update. NOTE: getPriceUnsafe() method does not check the freshness of the price.\n\nTo make sure you are getting sufficient price updates automatically, you can also run the Price pusher\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Why I get always reverted for Crypto.AVALON.USDA/USD price on Ethereum mainnet\n\n Price Feeds\n\n 1\n\n 470\n\n Jul 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 643\n\n Jul 2025\n\n Price Feed not working on AVAX and BASE\n\n Price Feeds\n\n 1\n\n 497\n\n Apr 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":1480,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266088480,"hash":"b85a2e54ca06a308ef0d730835cf0ea94c9567b6"}
{"url":"https://docs.optimism.io/node-operators/tutorials/node-from-docker","domain":"docs.optimism.io","title":"Optimism Documentation","text":"op-geth has reached end-of-support (2026-05-31) and does not support the now-active Karst hardfork, so op-geth nodes can no longer follow the canonical chain. Migrate to op-reth, the primary supported execution client. See the op-geth deprecation notice for the full migration plan.\nLearn the OP Stack — stop 14 of 14.\nYou’ve learned the stack from concepts to cross-layer flows. In this\ncapstone you run an OP Stack node on a live network with the official\nDocker images. When it syncs, you’ve finished the track: head back to\nLearn the OP Stack for where to go next.\nThis tutorial runs an OP Stack node using the official op-reth and op-node Docker images in a single docker-compose.yml. No source build required.\nTo run the Rust consensus client instead of op-node, see the\nkona-node Docker guide, which ships\nits own docker-compose recipe for a kona-node + op-reth stack.\nOP Mainnet requires a one-time pre-Bedrock state import. OP Sepolia does not. If you point this tutorial at OP Mainnet on a fresh datadir, op-reth will fail at startup with Op-mainnet has been launched without importing the pre-Bedrock state. Before running OP Mainnet, follow the op-reth sync-op-mainnet guide to either restore from a pre-synced snapshot or run the minimal-bootstrap import. OP Sepolia bootstraps via snap sync with no extra steps — start there if you’re just testing the setup.\n​Dependencies\n\nDocker\nDocker Compose (v2)\nAn L1 execution RPC endpoint (Ethereum mainnet for OP Mainnet, or Ethereum Sepolia for OP Sepolia).\nAn L1 Beacon API endpoint for the same L1 chain. Needed by op-node to fetch blob data post-Ecotone.\n\n​Quick start\n1Create a working directorymkdir op-stack-node && cd op-stack-node\n2Generate the JWT secretBoth containers share a JWT secret over a bind mount:openssl rand -hex 32 > jwt.txt\n3Create the .env fileConfigure your network and L1 endpoints. Pick one network block (Sepolia or Mainnet) and fill in your L1 RPC + Beacon URLs:cat > .env <<'EOF'\n# --- Network: OP Sepolia (default) ---\nOP_RETH_CHAIN=optimism_sepolia\nOP_NODE_NETWORK=op-sepolia\nOP_RETH_SEQUENCER=https://sepolia-sequencer.optimism.io\n\n# --- Network: OP Mainnet (uncomment to use instead) ---\n# OP_RETH_CHAIN=optimism\n# OP_NODE_NETWORK=op-mainnet\n# OP_RETH_SEQUENCER=https://mainnet-sequencer.optimism.io\n\n# --- L1 endpoints (required) ---\nL1_RPC_URL=https://your-l1-rpc-endpoint\nL1_RPC_KIND=basic\nL1_BEACON_URL=https://your-l1-beacon-endpoint\nEOF\nL1_RPC_KIND valid values: alchemy, quicknode, infura, parity, nethermind, debug_geth, erigon, basic, any. Use basic if unsure.OP_RETH_CHAIN and OP_NODE_NETWORK accept any superchain-registry chain (e.g. unichain / unichain-mainnet, soneium / soneium-mainnet). For each chain, point L1_RPC_URL / L1_BEACON_URL at the corresponding L1 (Ethereum Mainnet or Sepolia) and update OP_RETH_SEQUENCER to that chain’s sequencer endpoint.4Create docker-compose.ymlservices:\n op-reth:\n image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-reth:v2.2.5\n container_name: op-reth\n ports:\n - \"8545:8545\" # JSON-RPC HTTP\n - \"8546:8546\" # JSON-RPC WebSocket\n - \"9001:9001\" # Prometheus metrics\n - \"30303:30303\" # P2P TCP\n - \"30303:30303/udp\" # P2P UDP\n volumes:\n - ./reth-data:/data\n - ./jwt.txt:/jwt.txt:ro\n command:\n - node\n - --chain=${OP_RETH_CHAIN}\n - --datadir=/data\n - --http\n - --http.addr=0.0.0.0\n - --http.port=8545\n - --ws\n - --ws.addr=0.0.0.0\n - --ws.port=8546\n - --authrpc.addr=0.0.0.0\n - --authrpc.port=8551\n - --authrpc.jwtsecret=/jwt.txt\n - --rollup.sequencer=${OP_RETH_SEQUENCER}\n - --metrics=0.0.0.0:9001\n restart: unless-stopped\n\n op-node:\n image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-node:v1.18.2\n container_name: op-node\n depends_on:\n - op-reth\n ports:\n - \"9545:7000\" # JSON-RPC HTTP (host 9545 → container 7000; macOS uses 7000 for AirPlay)\n - \"7300:7300\" # Prometheus metrics\n - \"9222:9222\" # P2P TCP\n - \"9222:9222/udp\" # P2P UDP\n volumes:\n - ./jwt.txt:/jwt.txt:ro\n command:\n - op-node\n - --l1=${L1_RPC_URL}\n - --l1.rpckind=${L1_RPC_KIND}\n - --l1.beacon=${L1_BEACON_URL}\n - --l2=ws://op-reth:8551\n - --l2.jwt-secret=/jwt.txt\n - --network=${OP_NODE_NETWORK}\n - --syncmode=execution-layer\n - --l2.enginekind=reth\n - --rpc.addr=0.0.0.0\n - --rpc.port=7000\n - --metrics.enabled\n - --metrics.addr=0.0.0.0\n - --metrics.port=7300\n restart: unless-stopped\nThe op-reth datadir is bind-mounted from ./reth-data on the host so you can inspect / restore from a snapshot directly (see Bootstrap from a snapshot below).Image tags shown are the latest as of writing. For the current tags, see the op-reth releases and op-node releases.5Start the nodedocker compose up -d\nFollow logs with:docker compose logs -f\n\n​Verification\nCheck the node is alive and advancing:\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n --data '{\"jsonrpc\":\"2.0\",\"method\":\"eth_blockNumber\",\"params\":[],\"id\":1}' \\\n http://localhost:8545\n\nExpected: {\"jsonrpc\":\"2.0\",\"id\":1,\"result\":\"0x...\"} with the current block in hex. Run again after a minute — the number should increase as sync progresses.\nFor op-node sync status (unsafe, safe, and finalized heads in one call):\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n --data '{\"jsonrpc\":\"2.0\",\"method\":\"optimism_syncStatus\",\"params\":[],\"id\":1}' \\\n http://localhost:9545 | jq .\n\nDuring the initial EL-driven sync (--syncmode=execution-layer), unsafe_l2 tracks the tip via libp2p gossip while safe_l2 and finalized_l2 stay at 0. This is expected — op-node defers L1 derivation until op-reth finishes its staged sync. Once the EL catches up, derivation begins and the safe/finalized heads start advancing.\nYou can also tail op-node logs directly:\ndocker compose logs op-node | grep -E \"Sync progress|Finished EL sync\"\n\n​Bootstrap from a snapshot\nSyncing from scratch is fine for OP Sepolia (~30–50 GB, hours) but slow for OP Mainnet (~700 GB, days). For Mainnet — or anytime you’d rather skip the initial sync — bootstrap op-reth from a pre-synced snapshot.\nFor OP Mainnet, a snapshot also handles the pre-Bedrock state requirement (see the warning at the top of this page) in one step.\n1Stop the containersdocker compose down\nrm -rf reth-data # only if you previously synced and want to start clean\n2Download a snapshotBrowse datadirs.optimism.io for the snapshot matching your network and pick a recent file. Then download and verify the SHA256:curl -fLO https://datadirs.optimism.io/<snapshot-file>.tar.zst\n\n# Verify checksum against the value on the index page\nsha256sum <snapshot-file>.tar.zst # Linux\nshasum -a 256 <snapshot-file>.tar.zst # macOS\n3Extract into the datadirThe bind-mounted directory is ./reth-data (relative to your docker-compose.yml):mkdir -p reth-data\ntar -I zstd -xvf <snapshot-file>.tar.zst -C reth-data --strip-components=1\n--strip-components=1 removes the top-level wrapping directory inside the tarball. Run tar -tf <snapshot-file>.tar.zst | head -3 first to confirm — if files are already at the archive root, omit --strip-components.4Start the nodedocker compose up -d\ndocker compose logs -f op-reth\nop-reth will recognize the existing datadir on startup and pick up from the snapshot’s tip — latest_block should be the snapshot’s height, not 0. It will then catch up from that tip to current (minutes for Sepolia, hours for Mainnet, depending on snapshot age).\n​Next steps\n\nNode Metrics and Monitoring Guide — wire up Prometheus/Grafana against the metrics port.\nNode Troubleshooting Guide — if you run into problems.\nBuilding and running an OP Stack node from source — if you need a custom build or want to inspect the source.\nWas this page helpful?","tokens":1889,"squid":"ink-governance","role":"Council Listener","at":1791266095992,"hash":"c0e26d22441041e1e28672996b394c64375cddba"}
{"url":"https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0-release-candidate/2478/7","domain":"forum.openzeppelin.com","title":"OpenZeppelin Contracts v3.0 release candidate - General / Announcements - OpenZeppelin Forum","text":"GeneralAnnouncements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n Mar 2020\n\n 7 / 7\n\n Apr 2020\n\n Apr 2020\n\n post by nventuro on Mar 17, 2020\n\n nventuro\n\n Great contributor\n\na847d600e1565ea24f914b4c29b224160376602d2400×1350 255 KB\n\nWe’re excited to announce the first release candidate of OpenZeppelin Contracts v3.0 \nThis is release features the migration to Solidity v0.6, as well as a revamped access control system.\nTo install the release candidate, run:\nnpm install --save-dev @openzeppelin/contracts@next\n\nWhat’s New\n\nAll contracts were migrated to Solidity v0.6.\n\nAccessControl was designed with help from the community and has replaced Roles contracts (such as MinterRole and PauserRole), which were removed.\nCrowdsales were removed: we’ll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.\nWe’ve added hooks, a new feature of the library that will make extending it easier than ever. Read more below!\nMany, many breaking changes with small improvements. We’ve also moved some contracts around (e.g. Ownable is now found under the access directory) and deleted some that were not being used. Head to our changelog to see the full list.\n\nCompiling v0.6 Contracts\nYou can use the OpenZeppelin CLI to compile any Solidity v0.6 contract: just update the pragma statement on your source code and you’ll be good to go!\npragma solidity ^0.6.0;\n\nNote that you will need to use the recent v2.7 release of the CLI to have Solidity v0.6 support. For detailed information about using the CLI compiler, head to its documenation.\nRevamped Access Control\nOne of our most widely-used contracts is Ownable, providing a simple authorization scheme. However, this fell short in complex systems with multiple permissions.\nThe v3.0 release introduces AccessControl, a one-stop-shop for all authorization needs. It lets you easily define multiple roles with different permissions, as well as which accounts are allowed to grant and revoke each role. It also boosts transparency by enabling enumeration of all privileged accounts in a system.\nAccessControl was designed with a security-first mindset, receiving input from a wide array of users and incorporating best practices in the field. We’ll have detailed guides covering it out soon, but in the meantime you can refer to the documentation on the source file.\nMigrating From OpenZeppelin Contracts v2.5\nOther than the contract removals mentioned above, the library API is pretty much the same as in the v2.5 release, so the migration should be straightforward. For instructions on how to update your Solidity v0.5 contracts to v0.6, refer to the official documentation.\nThe exception to this is contracts that use the Gas Station Network (GSN): if you’re inheriting from GSNRecipient or one of the other GSN contracts, you’ll need to add the following snippet to your contracts:\nfunction _msgSender() internal view override(Context, GSNRecipient) returns (address payable) {\n return GSNRecipient._msgSender();\n}\n\nfunction _msgData() internal view override(Context, GSNRecipient) returns (bytes memory) {\n return GSNRecipient._msgData();\n}\n\nUsing Hooks\nTo improve library flexibility, we’re introducing hooks: functions that are called at specific moments during a contract’s operation that you can use to hook into the internals and extend as you wish.\nFor example, the _beforeTokenTransfer hook in ERC20, ERC721 and ERC777 makes it very easy to add additional checks or actions to execute whenever tokens are transferred, minted or burned, regardless of what prompted it.\n// Tokens can only be transferred, minted or burned if the contract is not paused\ncontract ERC20Pausable is ERC20, Pausable {\n function _beforeTokenTransfer(address from, address to, uint256 amount) \n internal virtual override \n {\n super._beforeTokenTransfer(from, to, amount);\n\n require(!paused(), \"ERC20Pausable: token transfer while paused\");\n }\n}\n\nAs an additional benefit, using hooks will allow you to side-step some of the edge-cases product of the new override keyword.\nNext Steps\nAs with all release candidates, the final release will follow one or two weeks later. This is so that community members get a chance to share their thoughts on the upcoming changes before they are made final.\nSo give this release candidate a try, upgrade your project to Solidity v0.6, and tell us what you think!\n\n OpenZeppelin Q1 2020 development update\n\n Can we use OpenZeppelin Contracts 3.0 with upgradeable contracts?\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n post by rumkin on Mar 20, 2020\n\n rumkin\n\n Nice change to access control. I’d like to have a method to list a certain member role too. Also it could be useful to have another method to shutdown member’s access immediately and then to remove exact roles associations.\nI’d suggest to replace error messages like AccessControl: sender must be an admin to revoke with error codes. For example oz/access-control/role-admin. It has a lot of benefits:\n\nIt’s both human and computer friendly in the same time.\nIt could be a part of URL to documentation website.\nIt’s easy to make a structure (tuple) from a string using only one call in JS (and other languages):const [ns, contract, failure] = \"oz/access-control/role-admin\".split(\"/\")\n\n post by nventuro on Mar 20, 2020\n\n nventuro\n\n Great contributor\n\nDoes this mean listing all roles an account has? This could be useful, though it would require additional storage (and therefore increase gas costs). I created an issue for this, thanks!\n\nInteresting! I fear this may lead to too much complexity though, since we'd have to keep track of 'banned' accounts, and these would be in a strange intermediate state where they have a role, but are unable to use it. It also creates issues regarding permission, who is allowed to ban an account? It'd be equivalent to calling revoke on all roles, which only the role admins can do.\nIf the goal is to remove all roles from an account, I think this can be better achieved with the enumeration suggested above, and then calling revokeRole for each role.\n\nThanks! We've had some discussion on what revert reasons should look like, and consensus was the human-readable strings were important. Note you can still split on the : to separate contract and message, as shown on your snippet above!\nThe bit about linking to the documentation is very interesting though, I'll think some more on it. Thanks!\n\n post by rumkin on Mar 20, 2020\n\n rumkin\n\nDoes this mean listing all roles an account has?\n\nYes. It's exactly what I meant.\n\nI fear this may lead to too much complexity though, since we’d have to keep track of ‘banned’ accounts, and these would be in a strange intermediate state where they have a role, but are unable to use it.\n\nIn my opinion it's an active/inactive boolean. It looks pretty straightforward to me, maybe for others too, probably it should be researched/need more feedback. It could (and probably should) be implemented as a separated contract for inheritance. And then be used in the final contract like this:\nrequire(isActive(_msgSender()))\nrequire(hasRole('admin', _msgSender()))\n\nIt's helpful to prevent attacks in the periods when gas cost is too high and a bunch of rejection transactions just could stall. Also it allows to suspend account membership for some period of time and then restore it without a need of reassigning all the permissions.\n\nhuman-readable strings were important\n\nAgree with you about importance of human-readability. But also unstructured string error message usually leads developers just to ignore error instead of properly handling it, what is worse in my opinion. And now solidity has a try-catch statement so it would be way more easy to identify an error. And structure should help to remember error code. This is my thoughts on it, maybe it would change your mind.\n\n 12 days later\n\n post by albertocuestacanada on Apr 2, 2020\n\n albertocuestacanada\n\nIs this information going to be needed by a smart contract? If it is only for UI or audit purposes you could retrieve role memberships from blockchain events with a listener.\n\n 18 days later\n\n post by abcoathup on Apr 20, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts v3.0 is released \n\n 9 days later\n\n post by rumkin on Apr 30, 2020\n\n rumkin\n\n albertocuestacanada\n\n It’s required for excluding an address from all the roles it has from another contract or single method call. Without it you’ll need to build a service to monitor such a list and reentering it into blockchain through transactions, what seems irrational to me.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OpenZeppelin Contracts v3.0\n\n Announcements\n\n 1\n\n 5.5k\n\n May 2020\n\n OpenZeppelin Contracts v3.0 final release candidate\n\n Announcements\n\n 7\n\n 4.0k\n\n Apr 2020\n\n OpenZeppelin Contracts v3.0 beta release\n\n Announcements\n\n release\n\n 0\n\n 4.6k\n\n Feb 2020\n\n OpenZeppelin Contracts Ethereum Package v3.0\n\n Announcements\n\n 0\n\n 3.2k\n\n May 2020\n\n Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Contracts\n\n 12\n\n 9.3k\n\n Jun 2021","tokens":2279,"squid":"ink-security_audits","role":"Sentinel","at":1791266098543,"hash":"bc5ace2b0f8d236fb405af89a4c4cdbb64948baa"}
{"url":"https://docs.optimism.io/node-operators/kona-node/run/docker","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This guide uses Kona’s pre-packaged docker config.For detailed usage of the kona-node binary, head\nover to the binary guide.\nTo run an op-node + op-reth stack with Docker instead, see\nRunning a Node With Docker.\nKona provides a kona-node docker recipe\nwith detailed instructions for running a complete node setup.\n​Quick Start\nThe easiest way to run kona-node with Docker is using the provided recipe:\n\nNavigate to the recipe directory:\ncd docker/recipes/kona-node\n\nConfigure environment variables:\nEdit cfg.env to set your L1 RPC endpoints:\nL1_PROVIDER_RPC=https://your-l1-rpc-endpoint\nL1_BEACON_API=https://your-l1-beacon-endpoint\n\nStart the services:\njust up\n\nThis will start:\n\nkona-node - The OP Stack node implementation\nop-reth - Execution layer client\nprometheus - Metrics collection\ngrafana - Monitoring dashboards (accessible at http://localhost:3000)\n\n​Docker Compose\nIn the provided docker compose, there are a few services\naside from the kona-node and op-reth. These are prometheus\nand grafana which automatically come provisioned with dashboards\nfor monitoring and insight into the kona-node and op-reth services.\nFor more detail into how Prometheus and Grafana work, head over to the\nMonitoring docs.\nThe docker-compose.yaml uses published images from GitHub Container Registry:\n\nop-reth: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-reth:develop\nkona-node: us-docker.pkg.dev/oplabs-tools-artifacts/images/kona-node:develop\n\n​Service Configuration\n​kona-node Service\nThe kona-node service is configured with the following key settings:\n\nPorts:\n\n5060 - RPC endpoint\n9223 - P2P discovery (TCP/UDP)\n9002 - Metrics\n\nEnvironment: L1 RPC and Beacon API endpoints are required\nVolumes: Persistent data storage and JWT token for engine API authentication\n\n​op-reth Service\nThe op-reth service provides the execution layer:\n\nPorts:\n\n8545 - HTTP RPC\n8551 - Engine API (authenticated)\n30303 - P2P discovery\n9001 - Metrics\n\nConfiguration: Pre-configured for OP Sepolia testnet\n\n​Configuration\n​Network Selection\nBy default, the recipe is configured for OP Sepolia. To sync a different OP Stack chain:\n\nSet appropriate L1 endpoints for your target network in cfg.env\nModify the docker-compose.yaml:\n\nUpdate op-reth --chain parameter\nUpdate op-reth --rollup.sequencer-http endpoint\nUpdate kona-node --chain parameter\n\n​RPC Trust Configuration\nBy default, kona-node trusts RPC providers (both L1 and L2). When using public or untrusted RPC endpoints, you should disable trust to enable block hash verification:\n# In cfg.env or as environment variables:\nKONA_NODE_L1_TRUST_RPC=false\nKONA_NODE_L2_TRUST_RPC=false\n\nOr modify the docker-compose.yaml command:\nkona-node:\n command: |\n node\n --chain op-sepolia\n --l1-eth-rpc ${L1_PROVIDER_RPC}\n --l1-beacon ${L1_BEACON_API}\n --l1-trust-rpc false # Add this for untrusted L1 RPCs\n --l2-engine-rpc ws://op-reth:8551\n --l2-trust-rpc false # Add this for untrusted L2 RPCs\n\nSee configure RPC trust for more details on RPC trust settings.\n​Port Configuration\nAll host ports can be customized via environment variables in cfg.env:\n# Kona Node ports\nKONA_NODE_RPC_PORT=5060\nKONA_NODE_DISCOVERY_PORT=9223\nKONA_NODE_METRICS_PORT=9002\n\n# OP Reth ports \nOP_RETH_RPC_PORT=8545\nOP_RETH_ENGINE_PORT=8551\nOP_RETH_METRICS_PORT=9001\nOP_RETH_DISCOVERY_PORT=30303\n\n# Monitoring\nPROMETHEUS_PORT=9090\n\n​Logging\nAdjust log levels by setting the RUST_LOG environment variable:\nexport RUST_LOG=engine_builder=trace,runtime=debug\n\n​Management Commands\nThe recipe includes convenient Just commands:\n# Start all services\njust up\n\n# Stop all services \njust down\n\n# Restart all services\njust restart\n\n# Generate JWT token (if needed)\n./generate-jwt.sh\n\n​Getting the kona-node Image\nThe recipe pulls published kona-node and op-reth images automatically.\nUse this section when you want to pull or build the kona-node image\nyourself, for example to pin a release version or test local changes.\n​Pulling a published image\nKona docker images are published with every release on GitHub Container Registry.\nYou can obtain the latest kona-node image with:\ndocker pull us-docker.pkg.dev/oplabs-tools-artifacts/images/kona-node\n\nSpecify a specific version (e.g. v0.1.0) like so.docker pull us-docker.pkg.dev/oplabs-tools-artifacts/images/kona-node:v0.1.0\n\nYou can test the image with:\ndocker run --rm us-docker.pkg.dev/oplabs-tools-artifacts/images/kona-node --version\n\nIf you can see the latest release version,\nthen you’ve successfully installed Kona via Docker.\n​Building the Docker image\nTo build the image from source, navigate to the root of the\nkona directory\nin the monorepo and run:\njust build-local kona-node\n\nThis will create an image with the tag kona:local. To specify a custom\ntag, just pass it in after kona-node in the command above, like so:just build-local kona-node my-custom-tag\n\nThe build will likely take several minutes. Once it’s built, test it with:\ndocker run kona:local --version\n\nTo use the locally built image with the recipe, update docker-compose.yaml\nto use kona:local instead of the published image.Was this page helpful?","tokens":1266,"squid":"ink-governance","role":"Council Listener","at":1791266107987,"hash":"fcca0ae665a7960464b223aa71920996a9d73e88"}
{"url":"https://dev-forum.pyth.network/t/price-feed-in-avalanche-not-working/460/2","domain":"dev-forum.pyth.network","title":"Price feed in Avalanche not working - Price Feeds - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds\n\n evm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2025\n\n 2 / 2\n\n Oct 2025\n\n Oct 2025\n\n post by neethu on Oct 30, 2025\n\n neethu\n\n I have trouble using the Core - Push based to get the price feed in Avalanche fuji network. I used the pyth contract 0x23f0e8FAeE7bbb405E7A7C3d60138FCfd43d7509. And gave price feed ID ETH/USD as given in the documentation.\nPythStructs.Price memory priceObject = pyth.getPriceNoOlderThan(0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace, 60);\nI called the view function\nAn unexpected error occurred:\nError: execution reverted (unknown custom error) (action=“call”, data=“0x19abf40e”, reason=null, transaction={ “data”: “0x8fe20099”, “to”: “0xef…sD” }, invocation=null, revert=null, code=CALL_EXCEPTION, version=6.15.0)\nAm I missing something with the exact price feed ID for avalanche fuji testnet? Thank you in advance.\n\n post by KemarTiti on Oct 31, 2025\n\n KemarTiti\n\n The contract is correct: 0x23f0e8FAeE7bbb405E7A7C3d60138FCfd43d7509\nThe ETH/USD price feed is indeed: 0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace ; ids page.\nThe error you are encountering is because the price of ETH/USD has not been updated recently enough on Avanlanche testnet.\nYou can check here the classic errors on EVMs and how to troubleshoot those.\nIn your case, to resolve this issue:\n\nUpdate the prices by calling updatePriceFeeds() by passing the latest updateData from Hermes.\nAnother method to fetch the price is getPriceUnsafe() If the price feed is available, the method will return the latest prices with timestamp of last update. NOTE: getPriceUnsafe() method does not check the freshness of the price.\n\nTo make sure you are getting sufficient price updates automatically, you can also run the Price pusher\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Why I get always reverted for Crypto.AVALON.USDA/USD price on Ethereum mainnet\n\n Price Feeds\n\n 1\n\n 470\n\n Jul 2025\n\n I failed to use api-reference.pyth.network\n\n Price Feeds\n\n 3\n\n 422\n\n Oct 2025\n\n Encountering error using price feeds\n\n Price Feeds\n\n 2\n\n 643\n\n Jul 2025\n\n Price Feed not working on AVAX and BASE\n\n Price Feeds\n\n 1\n\n 497\n\n Apr 2025\n\n Benchmark price for Uranus failing\n\n Benchmarks(Historic Prices)\n\n svm\n\n 11\n\n 222\n\n Jan 12\n\n Powered by Discourse","tokens":1470,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266108841,"hash":"67ab68ffdf9f0c685507ab41408aa9d7ace692cb"}
{"url":"https://forum.openzeppelin.com/t/where-is-erc20mintable-sol-in-openzeppelin-contracts-3-0/2283","domain":"forum.openzeppelin.com","title":"Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0? - Support / Contracts - OpenZeppelin Forum","text":"Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0? \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n 2\n\n 2\n\n Feb 2020\n\n 1 / 14\n\n Feb 2020\n\n Jun 2021\n\n post by abcoathup on Feb 16, 2020\n\n abcoathup\n\n Great contributor\n\n smalaichami asked on GitHub (https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2092):\n\nIt looks like that ERC20Mintable.sol contract is moved or removed.\nCould you please suggest what is the new parth for ERC20Mintable.sol ?\n\n How to mint erc20 tokens inside erc721 smart contract?\n\n 5\n\n 3\n\n 2\n\n 2\n\n post by abcoathup on Feb 16, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts v3.0 has a beta release\n\nThe final v3.0 release is not yet finished\n\nRoles contracts (such as MinterRole and PauserRole ) were removed: we’re redesigning our Access Control solution and will have a better version of these in the v3.0 release.\n\nERC20Mintable.sol is part of OpenZeppelin Contracts v2.5 which uses Solidity 0.5.\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/token/ERC20/ERC20Mintable.sol\n\n post by frangio on Feb 17, 2020\n\n frangio\n\n OpenZeppelin Team\n\n The master branch of the repo currently contains the work for the upcoming 3.0 release. For this release, we are removing the current role contracts, which includes MinterRole. Since we are removing this role, we are also removing the ERC20Mintable contract which used it.\nThere will be an alternative to ERC20Mintable and roles in 3.0, but we haven’t built it yet.\nIn the meantime, please continue using ERC20Mintable from the 2.5 release of Contracts, which can be found in the repository in the link that @abcoathup provided above.\n\n TypeError: Derived contract must override function \"_beforeTokenTransfer\"\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n Split this topic on Feb 23, 2020\n\n 6 posts were split to a new topic: Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n 3 months later\n\n post by PaulRBerg on May 25, 2020\n\n PaulRBerg\n\n Hey @frangio, v3 is out, but I can’t see the alternative for ERC20Mintable. I only found a ERC20Capped contract. Is this planned for a future version?\n\n post by Ro5s on May 25, 2020\n\n Ro5s\n\n Heya, I’ve had some similar issues fishing around, but if helpful, check out some of the OZ chunks I am using here which are blend of old/new (i’m still catching up lol)\n\n post by abcoathup on May 25, 2020\n\n abcoathup\n\n Great contributor\n\n PaulRBerg\n\n Hi @PaulRBerg,\nERC20Capped.sol was rewritten and it doesn't have a dependency on access control.\nOpenZeppelin Contracts v3.x introduced ERC20PresetMinterPauser which includes minting and pausing functionality using access control:\n\nThe account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to aother accounts\n\nThe Preset contracts are opinionated, especially when it comes to access control.\nDo you think there is still a need for an ERC20Mintable?\nWhat access control should it have?\n\n post by abcoathup on May 25, 2020\n\n abcoathup\n\n Great contributor\n\n Ro5s\n\n Hi @Ro5s,\nI suggest having a look at ERC20PresetMinterPauser in OpenZeppelin Contracts v3.0 depending where you are in the development cycle so you could update to Solidity 0.6 and OpenZeppelin Contracts 3.x.\nI noticed that LexTokenFactory.sol has been flattened (I assume you used a flattener). I would recommend not flattening and only importing the OpenZeppelin Contracts for security and readability.\nNote: Solidity 0.6.8 introduces SPDX license identifiers and the compiler will error if you have multiple license identifiers which you would get from flattening.\n\n post by PaulRBerg on May 25, 2020\n\n PaulRBerg\n\nNah, ERC20PresetMinterPauser fits the bill well. Thanks, Andrew!\n\n post by frangio on May 26, 2020\n\n frangio\n\n OpenZeppelin Team\n\n PaulRBerg\n\n V3 doesn’t include ERC20Mintable because the core contracts were made less opinionated: you get the internal _mint function in ERC20 and you can expose it as an external function however you want. This grew out of a feeling that basic contracts like v2’s ERC20Mintable can be inadequate when a project grows, and it’s also related to the fact that we introduced the more feature-complete AccessControl but we didn’t want to force everyone to use it. To balance this out, we introduced the “preset” contracts that piece together the different components in an opinionated way to provide ready to use contracts. So I’m glad to hear that worked for you.\nMaybe we need to do a better job explaining this idea in the documentation. May I ask @PaulRBerg and @Ro5s in what places you tried to find this so that we can make sure this information is discoverable for others that may search in similar places?\n\n post by Ro5s on May 26, 2020\n\n Ro5s\n\n abcoathup\n\n @abcoathup Helpful links. I really like how OZ is showing more examples of ‘put together’ solidity for certain use cases ~~ lots of folks, like myself, are in team ‘copy pasta’\nFor LexTokenFactory I have the entire file there for my own silly purposes (I am actually a straight up “Remix” programmer, noob tendencies), but also, I remove some of the constructors for Roles that otherwise defaulted permissions to msg.sender (I like being able to set owner remotely from factory as option).\n\n post by abcoathup on May 26, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Ro5s,\nWe can import OpenZeppelin Contracts via GitHub in Remix (see example: Deploy a simple ERC20 token in Remix). I find flattened contracts difficult to read and it isn’t clear when changes have been made (such as when you are modifying Roles).\nI recommend checking out OpenZeppelin Contracts v3.0 Access Control\n\n post by PaulRBerg on May 27, 2020\n\n PaulRBerg\n\nI think it'd be nice to have a reference to the new AccessControl contract and the \"preset\" model in the README of the ERC20 folder:\n\n 1 year later\n\n post by saingsab on Jun 21, 2021\n\n saingsab\n\n My last update on Solidity 0.8.0 If you have any advise or comment let’s me know.\n\npragma solidity ^0.8.0;\n\nimport '@openzeppelin/contracts/token/ERC20/ERC20.sol';\n\ncontract TokenBase is ERC20 {\n address public admin;\n\n constructor(string memory name, string memory symbol) ERC20(name, symbol) {\n admin = msg.sender;\n }\n\n function updateAdmin(address newAdmin) external {\n require(msg.sender == admin, 'only admin');\n admin = newAdmin;\n }\n\n function mint(address to, uint amount) external {\n require(msg.sender == admin, 'only admin');\n _mint(to, amount);\n }\n\n function burn(address owner, uint amount) external {\n require(msg.sender == admin, 'only admin');\n _burn(owner, amount);\n }\n}\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where is ERC721Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Contracts\n\n 3\n\n 3.3k\n\n Mar 2020\n\n Creating an ERC-20 token with OpenZeppelin v3.x?\n\n Contracts\n\n 3\n\n 1.8k\n\n Sep 2020\n\n ERC20PresetMinterPauser is no longer available?\n\n Contracts\n\n erc20\n\n 1\n\n 200\n\n Nov 2024\n\n How to create a mintable ERC20 token?\n\n Contracts\n\n 1\n\n 7.0k\n\n Jul 2020\n\n How to create an ERC20 mintable token?\n\n Contracts\n\n 4\n\n 7.6k\n\n Jul 2020","tokens":1801,"squid":"ink-security_audits","role":"Sentinel","at":1791266108923,"hash":"ff9c4706ca9106ee1b01b1a732b3f9492264b64a"}
{"url":"https://docs.optimism.io/node-operators/kona-node/run/mechanics","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Kona brings together a powerful suite of no-std and std Rust components,\npurpose-built for the OP Stack. At the heart of this ecosystem is the\nkona-node — a modern, modular rollup node (L2 consensus node) that can\nbe used as a drop-in binary or as a foundation for custom services.\nThe kona-node is a fully compliant implementation of the “Rollup Node”\nSpecifications and is released as a binary in\nthe kona repository. Whether you’re running a production network,\nbuilding new rollup features, or experimenting with the OP Stack,\nkona-node is built to be both robust and extensible.\n​Background\nA rollup node is responsible for deriving the canonical L2 chain from L1\nblocks and their receipts. It validates these blocks using the\nEngine API, passing them to the execution layer for processing.\nPaired with an execution engine like op-reth or op-geth, kona-node tracks\nthe unsafe, safe, and finalized tips of the L2 OP Stack chain, ensuring the\nnode is always in sync with the latest state.\nRollup nodes hold minimal state. Unsafe and safe payloads alike are sent\naway to the execution engine client which holds the chain’s db. This way,\nthe rollup node holds a view of the tip of the chain - unsafe, safe, and\nfinalized block info. All data otherwise needed is held in memory.\nThere are a few core architectural pieces of the kona-node.\n\nDerivation Pipeline: Constructs L2 payload attributes from L1 blocks,\nforming the backbone of rollup logic.\nExecution Engine Integration: Executes L2 payload attributes via the\nEngine API, abstracting away different EL clients.\nP2P Networking: Enables block gossip and peer discovery.\n\nFor an in-depth breakdown of these three pillars and a detailed design\nof the kona-node, visit the Node Design section.\nAdditionally, an RPC server exposes essential methods, including the\nL2 Output RPC method.\n​Syncing\nThe kona-node syncs the L2 chain in two main phases:\n\nExecution Layer (EL) Sync:\nWhen starting, the node initially has an empty engine task queue.\nOnce an unsafe block is received from P2P gossip, an InsertTask\nis executed. That task inserts the payload and sends a forkchoice\nupdate through the engine api. Since the engine state is lazily\ninitialized (the safe and finalized heads are zero), the forkchoice\nupdate kicks off EL sync on the execution layer (EL) client (such\nas op-reth or op-geth). EL sync instructs the execution client to\nfetch and sync L2 blocks directly from peers. During this phase,\nthe kona-node effectively waits for the EL client to reach the\nchain tip, when it returns that it is synced. No L2 blocks\nare derived from L1 during this period.\n\nConsensus Layer (CL) Sync:\nOnce the EL client is fully synced to the tip, the node transitions\nto consensus layer (CL) sync. In this phase, kona-node begins\nderiving new L2 payload attributes from the L1 chain, following\nthe rollup derivation process. OpAttributesWithParent values\nderived this way are executed as an engine task which submits\nthe payloads to the execution engine for validation and execution.\n\nkona-node does not support historical CL sync or backfilling\nL2 blocks from L1 for past chain history. It relies on the EL client\nto perform the initial sync of the L2 chain.\nOnly after the EL is fully synced does the node begin deriving and\nfollowing new L2 blocks from L1.\n\n​Extensibility\nThe kona-node is designed as a modular, actor-based node SDK,\nmaking it possible to extend or customize node behavior by adding\nnew actors or swapping out existing ones. This extensibility is\ncurrently in beta, but the architecture is intentionally built\nto support advanced use cases and custom integrations.\n​Actor Model\nAt the core of kona-node is the concept of actors: independent,\nasync services that communicate over channels. Each actor implements\nthe NodeActor trait, a minimal interface with a single\nstep method that the service drives in a loop until the actor reports\na fatal error or the node shuts down.\nThe RollupNode service builds and spawns a fixed set of\nactors covering derivation, the execution engine and its read-only\nengine RPC, the L1 watcher, P2P networking, the node’s RPC server,\nand, in sequencer mode, block building.\nThe Node Design section is\nthe canonical description of that actor set and of what each actor\ndoes.\n​Extending with Custom Actors\nYou can write your own actor by implementing the NodeActor trait.\nThis allows you to introduce new background services, event\nprocessors, or integrations with external systems.\nThe trait has one associated type and one method. Each call to step\nhandles a single inbound request, event, or scheduled tick. Returning\nOk(()) means the actor is ready to be stepped again; returning an\nerror is fatal and stops the actor. Cancellation is handled by the\ncaller that drives the loop, so the actor itself does not own a\ncancellation token.\nExample: Defining a Custom Actor\nuse async_trait::async_trait;\nuse kona_node_service::NodeActor;\n\nstruct MyCustomActor;\n\n#[async_trait]\nimpl NodeActor for MyCustomActor {\n type Error = std::io::Error;\n\n async fn step(&mut self) -> Result<(), Self::Error> {\n // Your actor logic for one step here.\n Ok(())\n }\n}\n\n​Running Custom Actors\nThere is no trait-based extension point for swapping actors into the\nstandard node today. RollupNode is a concrete type rather\nthan a trait, its actor set is fixed in that type’s start method,\nand the helper that spawns and supervises those actors is internal to\nthe kona-node-service crate.\nRunning a custom actor therefore means composing the node yourself.\nThe built-in actors are public API of the kona-node-service crate.\nThe request and payload types they exchange over channels are public\ntoo, spread across kona-node-service, sibling kona crates such as\nkona-rpc and kona-gossip, and the shared alloy engine types. A\ncustom binary can therefore construct the actors it needs, wire them\ntogether over channels, add its own NodeActor implementations, and\ndrive each actor’s step method in its own task.\n​Programmatic Node Construction\nThe RollupNodeBuilder provides a convenient way to\nconstruct a standard node, but for advanced use cases, you can build\nyour own node by composing actors directly, or by implementing your\nown builder pattern.\n​Current Limitations\n\nThe actor and service APIs are beta and may change.\nThe standard RollupNode exposes no hook for overriding an\nindividual actor or pipeline, so extending the node means composing\nactors in your own binary rather than wrapping RollupNode.\nDocumentation and examples for advanced extensibility are still\nevolving—contributions and feedback are welcome!\n\n​Learn More\n\nSee the NodeActor trait documentation for details\non implementing actors.\nExplore the kona-node-service crate for source code\nand more examples.\nWas this page helpful?","tokens":1692,"squid":"ink-governance","role":"Council Listener","at":1791266118220,"hash":"669bb75790efdad5e2d8d4441ac9fc84b74e0deb"}
{"url":"https://dev-forum.pyth.network/t/benchmark-price-for-uranus-failing/506","domain":"dev-forum.pyth.network","title":"Benchmark price for Uranus failing - Price Feeds / Benchmarks(Historic Prices) - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Benchmark price for Uranus failing \n\n Price FeedsBenchmarks(Historic Prices)\n\n svm\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 3\n\n 2\n\n Jan 8\n\n 1 / 12\n\n Jan 9\n\n Jan 12\n\n post by Biboux on Jan 8\n\n Biboux\n\nChain : Solana Devnet\nTimestamp : 1767484800 but fails since 4 days\n\nHello,\nSince 4 days ago, our pyth benchmark (using Hermes) is failing for URANUS (Price Id : 0xae537f03693a1ed70781aa64387eb553e7ff56df30972a74f728c75413fdd0d0) is failing to query historical prices .\nthe error is :\n\n…/node_modules/@pythnetwork/hermes-client/lib/HermesClient.js:45\nthrow new Error(`HTTP error! status: ${response.status}${errorBody ? `, body: ${errorBody}` : “”}`);\nError: HTTP error! status: 404, body: Price ids not found: 0xae537f03693a1ed70781aa64387eb553e7ff56df30972a74f728c75413fdd0d0\n\nI tried the price Id and the beta one, both are leading to same issue.\nI also noticed that the priec feed account is not initializd : 6KKpqs5GNzR3GbLKS2B5oxQP8BMASN3BjPzE1Wd9ooRn\n\n 7\n\n 3\n\n 2\n\n post by KemarTiti on Jan 9\n\n KemarTiti\n\n Hey!\nFYI Hermes caches data only for approx. 10 min. Anything older, you would need to use the Benchmarks endpoint: Use Historical Price Data (Benchmarks) | Pyth Developer Hub\nAnd the error / price feed account not being initialized, it is the error message when this specific price feed has never been updated onchain. That 1st onchain update of URANUS (or any other feed) will initialize the price feed account, so do try to do a full round trip price update and it should work\n\n post by Biboux on Jan 9\n\n post by Biboux on Jan 9\n\n post by nidhi on Jan 9\n\n post by Biboux on Jan 9\n\n post by nidhi on Jan 9\n\n post by Biboux on Jan 9\n\n post by nidhi on Jan 9\n\n post by Biboux on Jan 9\n\n post by Biboux on Jan 9\n\n post by KemarTiti on Jan 12\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n About the Benchmarks(Historic Prices) category\n\n Benchmarks(Historic Prices)\n\n 2\n\n 652\n\n Oct 2025\n\n Error price feed: Gaps in public price feed\n\n Price Feeds\n\n 14\n\n 758\n\n Apr 2\n\n Historical Price Feed in 03/01/2023\n\n Benchmarks(Historic Prices)\n\n 11\n\n 644\n\n Sep 2025\n\n Benchmarks Explainer on Solana\n\n Price Feeds\n\n svm\n\n 7\n\n 836\n\n Aug 2025\n\n Validating price data against benchmark api\n\n Benchmarks(Historic Prices)\n\n 2\n\n 411\n\n Oct 2025\n\n Powered by Discourse","tokens":1465,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266118925,"hash":"e34846a98b5ef26b12276a30a00dc9e69b5d7c9f"}
{"url":"https://forum.openzeppelin.com/t/where-is-erc20mintable-sol-in-openzeppelin-contracts-3-0/2283/3","domain":"forum.openzeppelin.com","title":"Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 3\n\n 2\n\n 2\n\n Feb 2020\n\n 3 / 14\n\n Feb 2020\n\n Jun 2021\n\n post by abcoathup on Feb 16, 2020\n\n abcoathup\n\n Great contributor\n\n smalaichami asked on GitHub (https://github.com/OpenZeppelin/openzeppelin-contracts/issues/2092):\n\nIt looks like that ERC20Mintable.sol contract is moved or removed.\nCould you please suggest what is the new parth for ERC20Mintable.sol ?\n\n How to mint erc20 tokens inside erc721 smart contract?\n\n 5\n\n 3\n\n 2\n\n 2\n\n post by abcoathup on Feb 16, 2020\n\n abcoathup\n\n Great contributor\n\n OpenZeppelin Contracts v3.0 has a beta release\n\nThe final v3.0 release is not yet finished\n\nRoles contracts (such as MinterRole and PauserRole ) were removed: we’re redesigning our Access Control solution and will have a better version of these in the v3.0 release.\n\nERC20Mintable.sol is part of OpenZeppelin Contracts v2.5 which uses Solidity 0.5.\nhttps://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/token/ERC20/ERC20Mintable.sol\n\n post by frangio on Feb 17, 2020\n\n frangio\n\n OpenZeppelin Team\n\n The master branch of the repo currently contains the work for the upcoming 3.0 release. For this release, we are removing the current role contracts, which includes MinterRole. Since we are removing this role, we are also removing the ERC20Mintable contract which used it.\nThere will be an alternative to ERC20Mintable and roles in 3.0, but we haven’t built it yet.\nIn the meantime, please continue using ERC20Mintable from the 2.5 release of Contracts, which can be found in the repository in the link that @abcoathup provided above.\n\n TypeError: Derived contract must override function \"_beforeTokenTransfer\"\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n Split this topic on Feb 23, 2020\n\n 6 posts were split to a new topic: Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n 3 months later\n\n post by PaulRBerg on May 25, 2020\n\n PaulRBerg\n\n Hey @frangio, v3 is out, but I can’t see the alternative for ERC20Mintable. I only found a ERC20Capped contract. Is this planned for a future version?\n\n post by Ro5s on May 25, 2020\n\n Ro5s\n\n Heya, I’ve had some similar issues fishing around, but if helpful, check out some of the OZ chunks I am using here which are blend of old/new (i’m still catching up lol)\n\n post by abcoathup on May 25, 2020\n\n abcoathup\n\n Great contributor\n\n PaulRBerg\n\n Hi @PaulRBerg,\nERC20Capped.sol was rewritten and it doesn't have a dependency on access control.\nOpenZeppelin Contracts v3.x introduced ERC20PresetMinterPauser which includes minting and pausing functionality using access control:\n\nThe account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role, which will let it grant both minter and pauser roles to aother accounts\n\nThe Preset contracts are opinionated, especially when it comes to access control.\nDo you think there is still a need for an ERC20Mintable?\nWhat access control should it have?\n\n post by abcoathup on May 25, 2020\n\n abcoathup\n\n Great contributor\n\n Ro5s\n\n Hi @Ro5s,\nI suggest having a look at ERC20PresetMinterPauser in OpenZeppelin Contracts v3.0 depending where you are in the development cycle so you could update to Solidity 0.6 and OpenZeppelin Contracts 3.x.\nI noticed that LexTokenFactory.sol has been flattened (I assume you used a flattener). I would recommend not flattening and only importing the OpenZeppelin Contracts for security and readability.\nNote: Solidity 0.6.8 introduces SPDX license identifiers and the compiler will error if you have multiple license identifiers which you would get from flattening.\n\n post by PaulRBerg on May 25, 2020\n\n PaulRBerg\n\nNah, ERC20PresetMinterPauser fits the bill well. Thanks, Andrew!\n\n post by frangio on May 26, 2020\n\n frangio\n\n OpenZeppelin Team\n\n PaulRBerg\n\n V3 doesn’t include ERC20Mintable because the core contracts were made less opinionated: you get the internal _mint function in ERC20 and you can expose it as an external function however you want. This grew out of a feeling that basic contracts like v2’s ERC20Mintable can be inadequate when a project grows, and it’s also related to the fact that we introduced the more feature-complete AccessControl but we didn’t want to force everyone to use it. To balance this out, we introduced the “preset” contracts that piece together the different components in an opinionated way to provide ready to use contracts. So I’m glad to hear that worked for you.\nMaybe we need to do a better job explaining this idea in the documentation. May I ask @PaulRBerg and @Ro5s in what places you tried to find this so that we can make sure this information is discoverable for others that may search in similar places?\n\n post by Ro5s on May 26, 2020\n\n Ro5s\n\n abcoathup\n\n @abcoathup Helpful links. I really like how OZ is showing more examples of ‘put together’ solidity for certain use cases ~~ lots of folks, like myself, are in team ‘copy pasta’\nFor LexTokenFactory I have the entire file there for my own silly purposes (I am actually a straight up “Remix” programmer, noob tendencies), but also, I remove some of the constructors for Roles that otherwise defaulted permissions to msg.sender (I like being able to set owner remotely from factory as option).\n\n post by abcoathup on May 26, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Ro5s,\nWe can import OpenZeppelin Contracts via GitHub in Remix (see example: Deploy a simple ERC20 token in Remix). I find flattened contracts difficult to read and it isn’t clear when changes have been made (such as when you are modifying Roles).\nI recommend checking out OpenZeppelin Contracts v3.0 Access Control\n\n post by PaulRBerg on May 27, 2020\n\n PaulRBerg\n\nI think it'd be nice to have a reference to the new AccessControl contract and the \"preset\" model in the README of the ERC20 folder:\n\n 1 year later\n\n post by saingsab on Jun 21, 2021\n\n saingsab\n\n My last update on Solidity 0.8.0 If you have any advise or comment let’s me know.\n\npragma solidity ^0.8.0;\n\nimport '@openzeppelin/contracts/token/ERC20/ERC20.sol';\n\ncontract TokenBase is ERC20 {\n address public admin;\n\n constructor(string memory name, string memory symbol) ERC20(name, symbol) {\n admin = msg.sender;\n }\n\n function updateAdmin(address newAdmin) external {\n require(msg.sender == admin, 'only admin');\n admin = newAdmin;\n }\n\n function mint(address to, uint amount) external {\n require(msg.sender == admin, 'only admin');\n _mint(to, amount);\n }\n\n function burn(address owner, uint amount) external {\n require(msg.sender == admin, 'only admin');\n _burn(owner, amount);\n }\n}\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where is ERC721Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Contracts\n\n 3\n\n 3.3k\n\n Mar 2020\n\n Creating an ERC-20 token with OpenZeppelin v3.x?\n\n Contracts\n\n 3\n\n 1.8k\n\n Sep 2020\n\n ERC20PresetMinterPauser is no longer available?\n\n Contracts\n\n erc20\n\n 1\n\n 200\n\n Nov 2024\n\n How to create a mintable ERC20 token?\n\n Contracts\n\n 1\n\n 7.0k\n\n Jul 2020\n\n How to create an ERC20 mintable token?\n\n Contracts\n\n 4\n\n 7.6k\n\n Jul 2020","tokens":1786,"squid":"ink-security_audits","role":"Sentinel","at":1791266120173,"hash":"654a2e7a0aa2967a70ddd4afdb046650e7b7f654"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-january-1st-2026/492","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations – January 1st, 2026 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds Upcoming Deactivations – January 1st, 2026 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2025\n\n 1 / 3\n\n Dec 2025\n\n Jan 3\n\n post by KemarTiti on Dec 31, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes, liquidity), and exceptional news (token migration or else) it has been decided to sunset a few feeds.\nPlease note that volumes, liquidity and other metrics are following this framework.\nAll below feeds are scheduled to be sunset on Thursday 1st, January, 2026.\nIf you have any questions, let us know below.\nCRYPTO\n\nCrypto.4/USD\nCrypto.AERGO/USD\nCrypto.ALKIMI/USD\nCrypto.ATLAS/USD\nCrypto.BENJI/USD\nCrypto.BELIEVE/USD\nCrypto.BLZE/USD\nCrypto.BUDDY/USD\nCrypto.BYUSD/USD\nCrypto.COQ/USD\nCrypto.DOGINME/USD\nCrypto.FIDA/USD\nCrypto.FOXY/USD\nCrypto.FRAG/USD\nCrypto.GIGA/USD\nCrypto.GOGLZ/USD\nCrypto.GRAIL/USD\nCrypto.HFUN/USD\nCrypto.LBGT/USD\nCrypto.LOFI/USD\nCrypto.LOOKS/USD\nCrypto.LUCE/USD\nCrypto.LUSD/USD\nCrypto.MANEKI\nCrypto.MBTC/USD\nCrypto.MODE/USD\nCrypto.MYRO/USD\nCrypto.NECT/USD\nCrypto.ODOS/USD\nCrypto.ONE/USD\nCrypto.OS/USD\nCrypto.OUSDT/USD\nCrypto.PERP/USD\nCrypto.SCETH/USD\nCrypto.SCUSD/USD\nCrypto.SENDCOIN.SEND/USD\nCrypto.SKI/USD\nCrypto.SYUSD/USD\nCrypto.TAC/USD\nCrypto.THAPT/USD\nCrypto.THL/USD\nCrypto.TURBOS/USD\nCrypto.URANUS/USD\nCrypto.USDAF/USD\nCrypto.USDB/USD (Blast)\nCrypto.USDU/USD\nCrypto.USH/USD\nCrypto.WFRAGSOL/USD\nCrypto.WOM/USD\n\n Benchmark price for Uranus failing\n\n Deprecation of Pyth Push Feeds - 15th January, 2026\n\n post by KemarTiti on Dec 12, 2025\n\n 22 days later\n\n post by KemarTiti on Jan 3\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – May 23, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 689\n\n Jun 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 548\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations – April 15th, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 57\n\n Apr 15\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Powered by Discourse","tokens":1469,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266131207,"hash":"88b217a9b870c63bff026db00d1e91d719e53dcf"}
{"url":"https://app.aave.com/governance/v3/proposal/?proposalId=516","domain":"app.aave.com","title":"Aave - [AIP] Onboard PAXG to Aave V4 Global Dollar Hub","text":"Go BackProposal overview[AIP] Onboard PAXG to Aave V4 Global Dollar HubExecutedRaw-IpfsShare on XAuthor@AaveLabsSimple Summary\nThis proposal onboards Pax Gold (PAXG) to the Aave V4 Global Dollar Hub on Ethereum. It deploys and configures the PAXG Gold Spoke, where PAXG is collateral only and USDG is borrowable, and enables native USDG as a borrowable reserve on the Pendle Spoke with a 4,000,000 USDG Draw Cap.\nMotivation\nPAXG is an ERC-20 token issued by Paxos Trust Company. Each unit represents one fine troy ounce of a London Good Delivery gold bar held in professional vaults. Redemption and custody are administered by the regulated issuer, and holdings are subject to periodic third party attestations.\nOnboarding PAXG to the Global Dollar Hub:\n\nIntroduces an asset backed by gold to the Aave V4 Ethereum instance, broadening the range of collateral and liquidity beyond dollar denominated exposures.\nGives users access to a regulated representation of physical gold within the Aave ecosystem, supporting demand from institutional participants and DeFi protocols seeking commodity exposure.\nComplements the Global Dollar Hub's existing composition by adding an asset with limited correlation for diversified liquidity strategies.\n\nSpecification\nThis proposal adds PAXG to the Aave V4 Global Dollar Hub on Ethereum, configures PAXG and USDG reserves on the PAXG Gold Spoke, and enables USDG on the Pendle Spoke.\nPAXG: 0x45804880De22913dAFE09f4980848ECE6EcbAf78\nThe PAXG Gold Spoke is deployed at 0xAD75cE6354f87F3135cE10621d385d8D1e2562C2. The payload wires this deployment to the Ethereum AccessManager and configures it with the PAXG and USDG reserves below.\nSpoke configuration\nHubSpokeReserveCollateral FactorMax Liquidation BonusBorrowableCollateral RiskLiquidation FeeriskPremiumThresholdreceiveSharesGlobal Dollar HubPAXG Gold SpokePAXG75.00%6.50%FALSE010.00%0TRUEGlobal Dollar HubPAXG Gold SpokeUSDG0.00%-TRUE--0TRUEGlobal Dollar HubPendle SpokeUSDG0.00%-TRUE--0TRUE\nriskPremiumThreshold is set to 0 for all reserves, in line with other assets across V4, as risk premiums are not currently in use. receiveShares is enabled for all reserves. For required onchain fields, the dash values in the table resolve to zero.\nDynamic liquidation configuration\nParameterValuetargetHealthFactor1.20healthFactorForMaxBonus0.90liquidationBonusFactor0.80\nAs a noncrypto open market spoke, the PAXG Gold Spoke uses more conservative liquidation restoration parameters. Draw Caps are set conservatively to reflect the PAXG Gold Spoke's developing liquidity for borrowing.\nCaps\nHubSpokeReserveAdd CapDraw CapGlobal Dollar HubPAXG Gold SpokePAXG25000Global Dollar HubPAXG Gold SpokeUSDG5,000,0009,500,000Global Dollar HubPendle SpokeUSDG-4,000,000\nPAXG is also registered with the Tokenization Spoke with an Add Cap of 0.\nOracle configuration\nPAXG is listed against the Chainlink XAU/USD price feed, pricing the token at underlying gold spot with no CAPO growth ceiling wrapper. PAXG carries no monotonic exchange rate growth for a cap to bound, so a CAPO adapter is not recommended. The accepted risks are a sustained dislocation in the token price, priced at full gold spot, and the feed's weekend staleness. The liquidation parameters set when collateral is enabled in a future phase must absorb that envelope rather than assume a continuously updating reference.\nDisclaimer\nThis proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no financial relationship with Paxos Trust Company or any of its affiliates and has not received compensation from Paxos in connection with this proposal.\nReferences\n\nImplementation: AaveV4Ethereum\nTests: AaveV4Ethereum\nDiscussion\nSnapshot\n\nCopyright\nCopyright and related rights waived via CC0.Your voting infoVoting is onVoting resultsYAE371KAAVE100.00%NAY0AAVE0%Top 10 addressesVotes0x3320756...bb7YAE107.2Ktokenlogic.ethYAE89,004aretagov.ethYAE75,925wintermutego...ethYAE53,7410x3676e9b...74dYAE25,0000xc0d6c3a...802YAE20,1850xee318d6...3edYAE208.530xfc1bc5a...695YAE58.10zhouxinchi.ethYAE4.202manmanwuxian...ethYAE0.3588StateExecutedQuorumReachedCurrent votesRequired371.37K320.00KDifferentialReachedCurrent differentialRequired371.37K80,000.00Forum discussionPayloadsPayload 466EthereumexecutedAccess levelMinor (Level 1)Creator0xc0e0...386fController0xdaba...aec5Target0x8580...154dSeatbelt reportTimelineCreatedSep 4, 2026 10:27 PMOpen for votingSep 5, 2026 10:30 PMVoting closedSep 8, 2026 10:34 PMQueuedSep 8, 2026 10:35 PMExecutedSep 8, 2026 10:36 PMPayloads queuedSep 8, 2026 10:36 PMPayloads executed1 / 1 executed","tokens":1153,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266131257,"hash":"3f52d1348b3932ba730417518eb45aa240e5eab4"}
{"url":"https://forum.openzeppelin.com/t/where-are-crowdsale-contracts-in-openzeppelin-contracts-3-0/2348/15","domain":"forum.openzeppelin.com","title":"Where are Crowdsale contracts in OpenZeppelin Contracts 3.0? - Archive / SDK - OpenZeppelin Forum","text":"ArchiveSDK\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n 3\n\n 2\n\n Feb 2020\n\n 15 / 15\n\n Jun 2021\n\n Jun 2021\n\n post by Revinand on Feb 18, 2020\n\n Revinand\n\n Hello. Is the situation with the crowdsale related contracts the same (Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?)? Seems it was removed in this commit.\nI don’t want to push you, but maybe you could provide any rough estimate when do you plan to add it back?\nThanks for your help and the great job you’re doing.\n\n Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?\n\n Where is ERC20Mintable.sol in OpenZeppelin Contracts 3.0?\n\n Coding Journey: An Idea turned Obsession\n\n Crowdsale?\n\n 4\n\n 3\n\n 3\n\n 2\n\n post by abcoathup on Feb 18, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Revinand,\nWelcome to the community .\nCrowdsales have been removed from the OpenZeppelin Contracts v3.0 beta release and there are no plans to migrate them to Solidity 0.6. If you need a crowdsale you can use OpenZeppelin Contracts 2.5:\n\nCrowdsales were removed: we’ll continue to provide support for security issues on the v2.5 release, but will not bring them over to v3.0.\n\nNote: You should only use code published in an official release of OpenZeppelin Contracts. When importing via GitHub on Remix you can specify the release tag, (otherwise you will get the latest code in the master branch).\n\n post by Revinand on Feb 18, 2020\n\n Revinand\n\n Got it. Thanks for a quick reply\n\n post by abcoathup on Feb 18, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Revinand,\nAre you working on a Crowdsale?\nAre you importing OpenZeppelin Contracts via npm or via GitHub?\n\n post by Revinand on Feb 19, 2020\n\n Revinand\n\n Hello @abcoathup,\nYes, I am. It’s a small crowdsale, so I need a very basic functionality, but I want to follow the best practices. That’s why I chose OpenZeppelin and asked why did you remove these contracts from the new version. If you say that v2.5 is ok, then it’s fine for me.\nFor now I’m using truffle as testing environment (didn’t have much time to try yours) and importing contracts via npm.\nAlso I noticed that you have Network JS project and going to try it in my React app.\n\n post by abcoathup on Feb 19, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @Revinand,\nCrowdsales are in OpenZeppelin Contracts 2.5. Feel free to ask any questions that you need.\nAny solution should be appropriately tested and audited. You should also obtain appropriate regulatory advice.\nCrowdsales weren’t included in the migration to Solidity 0.6 (OpenZeppelin Contracts 3.0) based on need/demand.\nOut of interest, what is your token being used for?\nAs an FYI: OpenZeppelin CLI 2.8: Release Candidate includes regular (non-upgradeable) deploys.\nSo you could test with OpenZeppelin Test Environment and deploy with OpenZeppelin CLI.\n\n 2 months later\n\n post by moisesja on Apr 12, 2020\n\n moisesja\n\n abcoathup\n\n Hello @abcoathup, since crowdsales will be removed with v3.0 What is the recommended pattern as a replacement for them? In my solution I will be deploying N number of token contracts (ERC777).\nThe buyer of a token must send ether and the ether gets transferred to the issuer of those tokens (just like in buyTokens in Crowdsale). The tokens will be capped and are all minted at once.\nMay I make a suggestion. Please add the fact that crowdsales are deprecated in the docs. I started using them trusting the documentation and now I have invested too much time in them.\nThanks!\nMoises\n\n 4 months later\n\n Split this topic on Aug 23, 2020\n\n A post was split to a new topic: Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?\n\n post by frangio on Aug 31, 2020\n\n frangio\n\n OpenZeppelin Team\n\n moisesja\n\n Do you mean this page? https://docs.openzeppelin.com/contracts/2.x/crowdsales\nWe could add a notice saying that they are no longer present in 3.x.\n\n 27 days later\n\n post by PradhumnaPancholi on Sep 28, 2020\n\n PradhumnaPancholi\n\n abcoathup\n\n Kind of a follow-up question on this. So, my ERC-20 token is built using OpenZeppelin v3, and for crowd sale, I will need v2.5. So, is it okay to create these contracts in two different projects? Coz most ppl I know who were writing crowd sales wrote both their token and their crowd sale contract in the same project (the project is a truffle project and Openzeppelin is installed via npm).\n\n post by abcoathup on Sep 28, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @PradhumnaPancholi,\nI think having a project for a Crowdsale extending from OpenZeppelin Contracts 2.x and a separate project for an ERC20 token extending from OpenZeppelin Contracts 3.x is an acceptable approach.\nThe crowdsale has a limited life, whilst the token is meant to have a long life.\nFor any post on tokens I suggest looking at: Points to consider when creating a fungible token (ERC20, ERC777)\n\n 9 months later\n\n post by stranger on Jun 12, 2021\n\n stranger\n\n abcoathup\n\n Hi,\nI know this is very old conversation but I want to use the crowdsale contract so my only option would be version 2.5 which is extremely old by now.\nIs it still safe to use it now in 2021 or should I opt to custom or other solution?\nThank you for advance.\n\n post by frangio on Jun 14, 2021\n\n frangio\n\n OpenZeppelin Team\n\n Older versions are safe to use. You may want to take a look at the changelog to see if anything newer since then looks important to your project.\n\n post by stranger on Jun 14, 2021\n\n stranger\n\n Thank you very much. I have already started building the crowd sale using v2.5 and I intend to build the contract also using 2.5 so I don’t have to maintain two truffle projects one for the token and one for the ico.\nThere doesn’t seem to be important changes that would affect my project directly in newer versions.\n\n post by stranger on Jun 14, 2021\n\n stranger\n\n frangio\n\n Actually there seems to be a way to use two config files so I will give that a shot to use OpenZeppelin v4 with the token but 2.5 for the ICO.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n How to create a Crowdsale with Solidity 0.6?\n\n Contracts\n\n 2\n\n 1.7k\n\n Sep 2020\n\n Where are crowdsales?\n\n Contracts\n\n 7\n\n 2.7k\n\n Feb 2022\n\n CrowdSale modules supported on OpenZeppelin 4x?\n\n Contracts\n\n erc20,crowdsale\n\n 1\n\n 1.5k\n\n Sep 2021\n\n Can I use Crowdsale with ERC20 Token created in OZ4.5.0?\n\n Smart Contracts\n\n erc20,crowdsale\n\n 6\n\n 898\n\n May 2022\n\n Is it safe to use Crowdsales (OpenZeppelin Contracts 2.x) together with the upgradable version of ERC20?\n\n Contracts\n\n 7\n\n 2.7k\n\n Aug 2020","tokens":1652,"squid":"ink-security_audits","role":"Sentinel","at":1791266141610,"hash":"ba42f1aa78fc9237f6729d0a18256768403ec790"}
{"url":"https://governance.aave.com/t/arfc-onboard-paxg-to-the-global-dollar-hub-in-aave-v4-ethereum/25340","domain":"governance.aave.com","title":"[ARFC] Onboard PAXG to the Global Dollar Hub in Aave V4 Ethereum - Governance - Aave","text":"[ARFC] Onboard PAXG to the Global Dollar Hub in Aave V4 Ethereum \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n read \n\n 4\n min\n\n Summary\n\n Motivation\n\n Specification\n\n Useful Links\n\n Disclaimer\n\n Next Steps\n\n Copyright\n\n Jul 17\n\n 1 / 9\n\n Jul 17\n\n Sep 11\n\n post by AaveLabs on Jul 17\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Summary\nThis proposal seeks to onboard Pax Gold (PAXG) to the Global Dollar Hub on the Aave V4 Ethereum instance. Final asset configuration will be determined by the Risk Service Providers.\nMotivation\nPAXG is an ERC-20 token issued by Paxos Trust Company, where each unit represents one fine troy ounce of a London Good Delivery gold bar held in professional vaults. Redemption and custody are administered by a regulated issuer, and holdings are subject to periodic third-party attestations.\nOnboarding PAXG to the Global Dollar Hub is aligned with the DAO’s long-term objectives in several ways:\n\nIt introduces a gold-backed, real-world asset to the Aave V4 Ethereum instance, broadening the range of collateral and liquidity available beyond dollar-denominated exposures.\nIt gives users access to a regulated, physically-backed representation of gold within the Aave ecosystem, supporting demand from institutional participants and DeFi protocols seeking commodity exposure.\nIt complements the Global Dollar Hub’s existing composition, adding a non-correlated asset that strengthens the instance’s position as a venue for diversified liquidity strategies.\n\nSpecification\nThis proposal adds PAXG to Aave V4 Global Dollar Hub in Ethereum\nToken Address: 0x45804880De22913dAFE09f4980848ECE6EcbAf78\nRisk Parameters and final configuration will be updated by Risk Service Providers and ARFC will be updated accordingly.\nUseful Links\n\nPax Gold\nPaxos attestations\n\nDisclaimer\nThis proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no financial relationship with Paxos Trust Company or any of its affiliates and has not received compensation from Paxos in connection with this proposal.\nNext Steps\n\nGather community feedback during the ARFC stage.\nService Providers to post Asset Technical Assessment and Asset Risk Assessment.\nIf the ARFC response is positive, escalate to Snapshot for off-chain confirmation.\nExecute the corresponding transaction through the V4 Security Council to onboard PAXG to the Global Dollar Hub on the Aave V4 Ethereum instance.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n 4\n\n read \n\n 4\n min\n\n post by MconnectDAO on Jul 17\n\n post by AaveLabs on Jul 22\n\n 27 days later\n\n post by LlamaRisk on Aug 19\n\n post by AaveLabs on Aug 19\n\n post by Abel189 on Aug 21\n\n post by evan on Aug 28\n\n post by dsadsadas on Aug 29\n\n 13 days later\n\n post by AaveLabs on Sep 11\n\n This topic will close a month after the last reply.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Onboard PAXGy to Aave V4 Global Dollar Hub\n\n Governance\n\n 0\n\n 179\n\n Aug 18\n\n Paxos Gold (PAXG) on Aave Ethereum Assessments\n\n Assessments\n\n 2\n\n 417\n\n Aug 19\n\n [ARFC] Add PAXG to Aave v3 Main Instance on Ethereum\n\n Governance\n\n 20\n\n 3.0k\n\n Sep 2025\n\n [TEMP CHECK] Add PAXG to Aave v3 Main Instance on Ethereum\n\n New Asset\n\n 5\n\n 756\n\n Apr 2025\n\n [Direct-to-AIP] Onboard PT-USDG-24SEP2026 to Aave V4 on Ethereum\n\n New Asset\n\n 7\n\n 1.0k\n\n Jul 16","tokens":854,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266141819,"hash":"47a74ea61fccce7575285fc3ff20e938f200375b"}
{"url":"https://docs.base.org/get-started/builders","domain":"docs.base.org","title":"Builders - Base Documentation","text":"​Build\n​Documentation\nLearn the fundamentals that will help you get started with building onchain.\n​Builder Codes\nThe Base team provides grants very selectively. The first step to be eligible for grants is to integrate Builder Codes.\nThese are unique identifiers that tag your app’s transactions so Base can attribute onchain activity back to you — and we wanted to make sure you’re set up.\nLearn More\n​Quests\nWant to pick up a problem statement to apply your learnings?\nBuilder Quests are Base’s recurring challenges to the builder community: pick a theme, build something real around it, and get rewarded for it. Follow the Build on Base handle for quest updates.\nLearn More\n​Network\n​Communities\nFind fellow builders to learn and build alongside. Builder communities serve as independent support groups for builders on Base. Join them and share your ideas, builds, provide and seek feedback.\nBase-aligned builder communities:\n\nHome Base (South America)\nInner Circle (India and globally)\n\nRunning a community and want to be featured?\nApply\n​Office Hours\nThe Base team opens office hours every Friday for builders looking for feedback on product or GTM.\nBook\n​Support\n​Builder Stack\nThe Builder Stack packages this. A pool of tools and credits, spanning LLM inference, cloud, and other dev infrastructure, that a team unlocks once it’s accepted into the Builder Grant Program.\nLearn More\n​Regional Amplification\nIf you’re actively building on Base with traction, we’d love to support you with distribution.\nPlease read our distribution guidelines for best practices.\nIf you are launching a new product, feature, or major release, we will support you by sharing it through Base regional community handles with a combined 100K+ community across LATAM, APAC, Europe, Africa, India, and Brazil.\nApply\n​Baseposting Coverage\nBaseposting covers Base ecosystem news updates daily. While there is no guarantee we can provide coverage for everyone, the best way to get covered is to tag @baseposting in the post containing your key update.\n​Builder Call\nTwice a quarter, we run the Base Builder Call, where we discuss the state of the Base ecosystem across products, builders, community, and more.\nIf you’d like to see your project in the next one, tag @AhaanRaizada on X with a short description of what you’re building on Base.\n​Roundtables\nEvery Thursday at 1:30 p.m. ET, we host a Builder Roundtable X Space focused on a topic of the week and invite Base builders to speak. If you’re interested in joining the next one, DM @saxenasaheb or @AhaanRaizada on X.\n​Get Funded\n​Grant Program\nGet up to $5,000 in grants, GTM and product support for actively building on Base across:\n\nPrediction markets\nToken launchpads\nDeFi 2.0 — lending, borrowing, looping, yield generation, vaults, tokenized equities\nAgents — commerce, x402 implementations, autonomous trading\nProducts focusing on new asset creation\nConsumer apps focused on transaction growth\n\nApply to be included in our next cohort.\nApply\n​Accelerator Partners\nWe back builders beyond our own programs through third-party accelerators run by our partners.\n\n​Base Batches\nBase Batches is an accelerator for early-stage teams building the future of finance on Base, run by the Base Ecosystem Fund. Each cohort is a short, virtual program that ends with a demo day in front of investors.\nApply\n​Base Ecosystem Fund\nThe Base Ecosystem Fund is the strategic investment arm of Base, run in partnership with Coinbase Ventures. It backs early-stage teams building onchain businesses on Base.\nApplyWas this page helpful?Suggest editsRaise issue","tokens":895,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266152769,"hash":"32d82beebad08392d2b4c65bf6aa935e57345812"}
{"url":"https://docs.base.org/get-started/accept-payments","domain":"docs.base.org","title":"Accept Payments - Base Documentation","text":"Accept payments on Base with the lifecycle your product needs. Use the Commerce Payments Protocol to charge immediately or reserve funds in escrow before fulfillment, then capture, void, reclaim, or refund under payer-approved terms. The same solution area also covers scheduled collection, reconciliation, payouts, splits, and x402 APIs.\n​Demo\nScenario1Fund2Approve3ChargeLive · Vibenet1Mint 5 USDVIn progress2Approve $5Pending3Submit chargePendingFlow statePayment hashNot createdCapturable0.00 USDVRefundable0.00 USDVMint 5 USDVMint 5 USDV to your demo account from Vibenet's existing USDV token, whose mint is open to any account.TokenVibenet USDV (not USDC)RolesYour demo account is payer and operatorAmount5.00 USDVNetworkBase VibenetTransaction event log--:--:--[PENDING]Mint 5 USDV--:--:--[PENDING]Approve $5--:--:--[PENDING]Submit chargeVibenet USDV, not USDC. The payer pre-approves a payment-specific allowance; the operator drives the escrow flow.Real Vibenet transactions · Vibenet USDV, not USDC\nThe demo above is mock only. If you want to see onchain demos on Vibenet, head to Base chain demos.\n​Payment Lifecycle\nStageWhat happensStart withChargeThe operator collects and settles a protocol payment atomicallyRequest a paymentAuthorizeThe operator moves payer funds into escrowAuthorize a paymentCaptureThe operator settles all or part of the escrowed amountCapture an authorizationConfirmYour backend verifies confirmed protocol events and claims the order onceVerify a paymentReturn or distributeYou refund the payer or pay downstream recipientsRefund a payment\n​Take a Payment\n\n​Confirm and Reconcile\n\n​Refund and Pay Out\n\n​Accept Agentic Payments\nWas this page helpful?Suggest editsRaise issue","tokens":428,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266177600,"hash":"950934d18cab18fc49735b033cd8764006a46bb6"}
{"url":"https://app.aave.com/governance/","domain":"app.aave.com","title":"Aave - Open Source Liquidity Protocol","text":"Available onEthereum MainnetAave GovernanceAave is a fully decentralized, community governed protocol by the AAVE token-holders. AAVE token-holders collectively discuss, propose, and vote on upgrades to the protocol. AAVE token-holders (Ethereum network only) can either vote themselves on new proposals or delagate to an address of choice. To learn more check out the Governance documentation.SnapshotsForumFAQGovernance V2ProposalsAll proposalsOpen for votingOnboard PT-AUSD-17DEC2026 to Aave V3 MonadAuthor: TokenLogicSimple Summary\n\nThis AIP lists PT-AUSD-17DEC2026, the Pendle Principal Token for AUSD maturing on 17 December 2026, on the Aave V3 Monad instance as a non-borrowable asset, usable as collateral exclusively within a dedicated PT-AUSD-17DEC2026/stablecoin eMode.\n\nMotivation\n\nPT-AUSD-8OCT2026 matures on 8th of October 2026. This AIP lists the next maturity, PT-AUSD-17DEC2026, with the launch parameters recommended by LlamaRisk, so that users can roll fixed-yield AUSD positions used as collate...YAE172K100.00%NAY<1<0.01%ExecutedOnboard PT-sUSDe-22OCT2026 to the LlamaRisk PT Risk OracleAuthor: LlamaRiskSimple Summary\n\nRegisters two predeployed risk agents on the Aave-owned AgentHub so that discount rate and eMode risk parameters for PT-sUSDe-22OCT2026 on Aave V3 Plasma can be maintained automatically from the LlamaRisk PT Risk Oracle, within bounds this proposal sets.\n\nMotivation\n\nPT-sUSDe-22OCT2026 is a Pendle principal token listed on Plasma as reserve 17 and collateral in eMode categories 25 and 26. Its fair value depends on an implied discount rate that decays to zero at maturity, so...YAE371K100.00%NAY00%ExecutedAave V4 Risk Stewards ActivationAuthor: Aave LabsSimple Summary\n\nThis proposal activates the Risk Stewards on Aave V4 Ethereum and Aave V4 Avalanche, by setting their risk configuration and granting them the AccessManager roles they need to operate. On Aave V4 Base, where the Risk Steward is already configured, it takes ownership of the Risk Steward and grants it the `RISK_ADMIN` role on the Aave V3 ACL Manager, needed to manage CAPO feeds.\n\nThe bounds (`maxPercentChange`) follow LlamaRisk's recommended configuration, which carries most of ...YAE371K100.00%NAY00%ExecutedSafety Module August 2026 - Allowance UpdateAuthor: TokenLogicSimple Summary\n\nThis AIP tops up the AAVE allowance funding stkAAVE rewards so that it fully covers the accrual since the snapshot plus 90 days of future emissions at the unchanged rate of 150 AAVE per day, together with one quarter of the 50,500 AAVE backlog gap accumulated before the snapshot, and resizes the allowances of the three sunset Safety Module tokens (stkABPT v1, stkGHO, stkAAVEwstETHBPTv2) so that each one matches its residual claimable rewards. These modules have been updated to...YAE381K100.00%NAY00%ExecutedLow Adoption Asset Deprecation on Aave V3Author: Llama Risk (implemented by Aave Labs)Simple Summary\n\nLlamaRisk, together with the Aave service providers working on risk surface reduction, recommends offboarding a broad set of low-activity Aave V3 reserves along with six whole deployments. The following specification lists the current configuration of each reserve and the parameter changes required to wind it down.\n\nThe individual removals cover 49 reserves and 21 matured Pendle PTs across eleven deployments, holding $80.1M of supply and $11.5M of debt. The whole-market deprec...YAE371K100.00%NAY00%ExecutedMaintenance: Grant AL RETRY_ROLE on a.DI (Part 2)Author: Aave LabsSimple Summary\n\nThis proposal grants the Aave Labs multisig the RETRY_ROLE on a.DI’s granular access controls.\n\nRecipient: 0x2B99790c35a401be873FA7Eb514D9220736BB1cA\n\nThis is Part 2 of 2. It covers Linea, Celo, Sonic, Soneium, Plasma, Mantle, MegaEth, XLayer and Ink. Part 1 covers Ethereum, Polygon, Avalanche, Optimism, Arbitrum, Metis, Base, Gnosis, Scroll and BNB.\n\nMotivation\n\na.DI is the cross-chain delivery layer used by Aave governance to route approved governance actions from Ethereu...YAE371K100.00%NAY00%ExecutedOnboard USDC to Aave V3 X LayerAuthor: TokenLogicSimple Summary\n\nThis AIP lists native USDC on the Aave V3 X Layer instance as a borrowable asset and collateral, and enables USDC as a borrowable asset within the existing xBTC, xETH, xSOL, wOKB and PT-USDG stablecoin eModes.\n\nMotivation\n\nOn 6 August 2026, Circle launched native USDC and the Cross-Chain Transfer Protocol (CCTP) on X Layer. Native USDC is issued by Circle, fully reserved, and redeemable 1:1 for US dollars. Onboarding it to Aave V3 X Layer expands the range of high-quality s...YAE381K100.00%NAY00%ExecutedUSDC GSM ArbitrumAuthor: TokenLogicSimple Summary\n\nReplace existing GSM with underlying USDC.e with new GSM with underlying USDCn on Arbitrum.\n\nMotivation\n\nWith USDC.e related assets soon to be deprecated as can be seen on this forum [post](https://governance.aave.com/t/arfc-low-adoption-asset-deprecation-on-aave-v3/25401), replace USDC.e GSM with USDCn GSM on Arbitrum.\n\nSpecification\n\nWire up Arbitrum GSM (stataUSDCn)\n\n- Point it at the `GhoReserve`, enroll it as an entity with a 25M GHO reserve limit.\n- Grant `SWAP...YAE327K100.00%NAY00%ExecutedAdd X Layer Loop Tool & Margin Trading to FlashBorrowersAuthor: TokenLogicSimple Summary\n\nThis AIP adds the X Layer Loop Tool contract and the X Layer Margin Trading contract to the Aave V3 X Layer FlashBorrowers whitelist, allowing them to access flash liquidity without incurring the Aave Flashloan Fee.\n\nMotivation\n\nX Layer has developed a Loop Tool to simplify position management and looping activity on the Aave V3 X Layer instance. The tool will be integrated into OKX Wallet as a user facing product, allowing users to create leveraged positions on Aave withou...YAE327K100.00%NAY00%Executed[AIP] Onboard PAXG to Aave V4 Global Dollar HubAuthor: AaveLabsSimple Summary\n\nThis proposal onboards Pax Gold (PAXG) to the Aave V4 Global Dollar Hub on Ethereum. It deploys and configures the PAXG Gold Spoke, where PAXG is collateral only and USDG is borrowable, and enables native USDG as a borrowable reserve on the Pendle Spoke with a 4,000,000 USDG Draw Cap.\n\nMotivation\n\nPAXG is an ERC-20 token issued by Paxos Trust Company. Each unit represents one fine troy ounce of a London Good Delivery gold bar held in professional vaults. Redemption and cust...YAE371K100.00%NAY00%Your infoPlease connect a wallet to view your personal information here.","tokens":1600,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266188398,"hash":"53eff04255a85d10c27645864b280399c3216413"}
{"url":"https://docs.base.org/base-chain/network-information/ecosystem-bridges","domain":"docs.base.org","title":"Bridge to Base - Base Documentation","text":"Move assets to and from Base using the routes below. Pick the one that matches where your assets are today.\n​Choose a Route\nComing fromRecommended routeTypical assetsA Coinbase accountWithdraw directly to Base (no bridge)ETH, USDC, cbBTCEthereum (L1)Superbridge or Brid.ggETH, ERC-20sSolanaBase–Solana bridgeSOL, SPL tokensBitcoinGardenBTC → cbBTC\nIf you hold funds in a Coinbase account, you can withdraw many assets straight onto the Base network — select Base as the network when withdrawing, no bridge required. This is often the fastest path for USDC and ETH.\n​From Ethereum\nBridge ETH and supported ERC-20s between Ethereum mainnet (L1) and Base. Both providers support mainnet and Sepolia testnet.\n\n​Programmatic Bridging\nTo bridge ETH and ERC-20s from Ethereum to Base in code, start from the sample repository.\nDouble-check the token address for ERC-20s. Confirm the token has a base entry in the Superchain token list (example), and always test with small amounts first. This sample bridges assets to Base only — do not modify it to withdraw.\n​For Token Issuers\nIf you have an ERC-20 on Ethereum and want to enable bridging to Base, use the sample repository above as a starting point for the standard bridge contracts, then list your token on the Superchain token list.\n​From Solana\nThe Base–Solana bridge enables bidirectional token transfers and message passing between Base and Solana: move SOL and SPL tokens, send cross-chain messages, deploy wrapped tokens on either chain, and optionally auto-relay for instant execution.\n\nNetworkContractAddressBase MainnetBridge0x3eff766C76a1be2Ce1aCF2B69c78bCae257D5188Base MainnetSOL token0x311935Cd80B76769bF2ecC9D8Ab7635b2139cf82Solana MainnetBridge programHNCne2FkVaNghhjKXapxJzPaBvAKDG1Ge3gqhZyfVWLM\nFor testnet addresses and full implementation details, see the Base–Solana bridge documentation.\n​From Bitcoin\nGarden is a fast, non-custodial bridge for moving BTC and other supported assets to Base. Available on mainnet and Sepolia testnet.\nThe bridge previously at bridge.base.org has been deprecated. Use the routes above instead.\n​Disclaimer\nCoinbase Technologies, Inc. provides links to these independent service providers for your convenience but assumes no responsibility for their operations. Any interactions with these providers are solely between you and the provider.Was this page helpful?Suggest editsRaise issue","tokens":596,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266188452,"hash":"89741055cb203a37600e4e4eeb184a66ad328421"}
{"url":"https://docs.base.org/specifications/base-protocol/bridging/base-solana-bridge","domain":"docs.base.org","title":"Base-Solana Bridge - Base Documentation","text":"The Base-Solana bridge enables bidirectional token transfers and message passing between Base and\nSolana networks. This bridge allows you to:\n\nTransfer tokens between Base and Solana\nSend arbitrary cross-chain messages\nCombine both flows (transfer with arbitrary calls)\nDeploy wrapped tokens on either chain\n\nThis guide covers the bridge architecture, the production addresses, and practical implementation\npatterns.\n​How It Works\n​On Base\nThe Base bridge contract locks or burns tokens when sending tokens to Solana, and mints or unlocks\ntokens when receiving tokens from Solana. The Bridge contract itself builds Merkle trees from\noutgoing messages. Validators verify the Merkle root every ~300 finalized blocks and relay it to\nSolana. You then prove your message exists in the tree to complete the transfer on Solana.\nTokens that are native to Base are locked and tokens that are native to Solana are burned when bridging to Solana.\nTokens that are native to Solana are minted and tokens that are native to Base are unlocked when bridging to Base.\nKey Smart contracts:\n\nBridge Contract: Handles outgoing transfers\nCrossChainERC20: Mintable/burnable tokens for cross-chain transfers\nBridgeValidator: Validates messages with oracle signatures\nTwin Contract: Your personal smart contract on Base for executing calls from Solana\n\nWhat is the Twin Contract?\nEach Solana wallet deterministically maps to a Twin contract on Base. When you attach a contract call\nto a bridge message, the call is executed from this Twin contract, ie. the Twin becomes msg.sender on Base.\n​On Solana\nThe Solana bridge program handles token transfers by locking or burning tokens and emitting events.\nFor messaging, validators relay these events to Base where they are executed through your Twin\ncontract.\nKey Programs (Solana Mainnet-Beta):\n\nBridge Program: Handles outgoing transfers and message commitments.\nBase Relayer Program: Optional relayer that can prepay gas on Base.\n\nThe relayer program is not part of the core bridge. It is an optional convenience layer that can pay\nBase gas fees on behalf of the Solana user in the Solana → Base direction.The user would still need to pay the gas fee by adding PayForRelay to the Solana transaction.\nIf the user does not add PayForRelay, the relayer program will not pay the gas fee.\nYou can access the full repository here:\nBase Bridge - Official Repositoryhttps://github.com/base/bridge\n​Bridging Flows\n\n​Solana to Base\nFlow: Lock SOL/SPL → (Optional) Pay for relay → Validators approve → Mint + execute on Base\nThe Solana to Base bridge uses a pull-based model that requires 3 steps:\n\nInitiate the bridge on Solana - Lock your SOL or native SPL token in a Solana vault\nWait for validators to pre-approve the message - Validators verify and approve your bridge message\nExecute the message on Base - The approved message is executed on Base to mint SOL and execute any additional arbitrary calls\n\nWhen bridging from Solana to Base, native SOL/SPL are locked and ERC20 SOL is minted on Base.\nIf your Solana → Base message includes a call to execute, you must ensure\nthe ABI-encoded call is executable on Base. A call that cannot be executed\non Base cannot be undone. If you bridge tokens in the same transaction,\nthose tokens will be locked.\nReference scripts (auto-relay, token wrapping, CLI utilities) live in the scripts/ directory of the official repository:\nSolana → Base CLI Scriptshttps://github.com/base/bridge/tree/main/scripts/src/commands/sol/bridge\n​Auto-Relay Example\nThis is a sample script that shows how to bridge SOL with auto-relay\nsolToBaseWithAutoRelay/index.ts// Configure\nconst TO = \"0x8c1a617bdb47342f9c17ac8750e0b070c372c721\"; // Base address\nconst AMOUNT = 0.001; // SOL amount\n\n// Bridge SOL with auto-relay\nconst ixs = [\n getBridgeSolInstruction({\n payer,\n from: payer,\n solVault: solVaultAddress,\n bridge: bridgeAccountAddress,\n outgoingMessage,\n to: toBytes(TO),\n remoteToken: toBytes(\"0xC5b9112382f3c87AFE8e1A28fa52452aF81085AD\"), // SOL on Base\n amount: BigInt(AMOUNT * 10**9),\n }),\n await buildPayForRelayIx(RELAYER_PROGRAM_ID, outgoingMessage, payer)\n];\n\nawait buildAndSendTransaction(SOLANA_RPC_URL, ixs, payer);\n\nFor more details, see the Solana to Base Relay Script.\n​Wrap Custom SPL Tokens\nThe example above shows how to bridge native SOL to Base.\nTo bridge custom SPL tokens,\nyou need to create wrapped ERC20 representations on Base using the CrossChainERC20Factory.\nToken Wrapping Examplehttps://github.com/base/bridge/blob/main/scripts/src/commands/sol/bridge/solana-to-base/wrap-token.handler.ts\nwrapSolTokenOnBase/index.ts// Deploy wrapped token on Base\nconst mintBytes32 = getBase58Codec().encode(SOLANA_SPL_MINT_ADDRESS).toHex();\n\nawait client.writeContract({\n address: \"0x58207331CBF8Af87BB6453b610E6579D9878e4EA\", // Factory\n abi: TokenFactory,\n functionName: \"deploy\",\n args: [`0x${mintBytes32}`, \"Token Name\", \"SYMBOL\", 9],\n});\n\n​Base to Solana\nFlow: Burn ERC20 SOL on Base → Wait for finalization → Generate Merkle proof → Execute on Solana\nBurn wrapped tokens on Base, wait for the message to become provable, then execute the proof on\nSolana to unlock the native asset. This path offers full custody and requires a prover.\nBase → Solana Examplehttps://github.com/base/bridge/blob/main/scripts/src/internal/sol/base.ts\nbridgeSolFromBaseToSolana/index.ts// Step 1: Burn SOL on Base\nconst transfer = {\n localToken: \"0xC5b9112382f3c87AFE8e1A28fa52452aF81085AD\", // SOL (on Base)\n remoteToken: pubkeyToBytes32(SOL_ADDRESS),\n to: pubkeyToBytes32(solanaAddress),\n remoteAmount: BigInt(AMOUNT * 10**9),\n};\n\nconst txHash = await client.writeContract({\n address: \"0xB2068ECCDb908902C76E3f965c1712a9cF64171E\", // Bridge\n abi: Bridge,\n functionName: \"bridgeToken\",\n args: [transfer, []],\n});\n\n// Step 2: Wait for finalization\nconst isProvable = await isBridgeMessageProvable(txHash);\n\n// Step 3: Generate proof\nconst { event, rawProof } = await generateProof(txHash, baseBlockNumber);\n\n// Step 4: Execute on Solana\nconst proveIx = getProveMessageInstruction({\n nonce: event.message.nonce,\n sender: toBytes(event.message.sender),\n data: toBytes(event.message.data),\n proof: rawProof.map(e => toBytes(e)),\n messageHash: toBytes(event.messageHash),\n});\n\nconst relayIx = getRelayMessageInstruction({ message: messagePda });\nawait buildAndSendTransaction(SOLANA_RPC_URL, [proveIx, relayIx], payer);\n\nIf you operate a relayer that signs and submits Solana transactions for users in the Base → Solana\ndirection, do not sign transactions that require your relayer pubkey as a signer.A malicious user can encode a transaction that includes your relayer pubkey as a required signer; if\nyou sign and submit it, you may unintentionally authorize arbitrary instructions (including ones\nthat can steal relayer funds). As a baseline mitigation, ignore any transaction that specifies your\npubkey as a signer.\n​Utilities\nThe repository includes utilities for converting between Solana and Base address formats,\ngetting your Solana CLI keypair for signing transactions,\nand building and sending Solana transactions.\nBase Bridge Examples - Utilitieshttps://github.com/base/bridge/tree/main/scripts/src/commands\n​Address Conversion\nConvert Solana pubkey to bytes32 for Base contracts:\nexample.ts// Convert Solana pubkey to bytes32 for Base contracts\nimport { pubkeyToBytes32 } from \"./utils/pubkeyToBytes32\";\n\nconst bytes32Address = pubkeyToBytes32(solanaAddress);\n\n​Keypair Management\nGet your Solana CLI keypair for signing transactions:\nexample.tsimport { getSolanaCliConfigKeypairSigner } from \"./utils/keypair\";\n\nconst payer = await getSolanaCliConfigKeypairSigner();\n\n​Transaction Building\nBuild and send Solana transactions:\nexample.tsimport { buildAndSendTransaction } from \"./utils/buildAndSendTransaction\";\n\nconst signature = await buildAndSendTransaction(SOLANA_RPC_URL, ixs, payer);\n\n​Terminally Onchain Example\nTerminally Onchainhttps://github.com/base/sol2base\nTerminally Onchain is a production Next.js app that exposes the bridge via a\ncommand terminal UI. Users connect a Solana wallet, type commands such as to bridge and call a contract on Base:\nTerminalbridge 0.0001 sol 0xYourTwin --call-contract 0x311935Cd80B76769bF2ecC9D8Ab7635b2139cf82 \\\n --call-selector \"transfer(address,uint256)\" \\\n --call-args 0x0000000000000000000000000000000000000000 100000000000000\n\nThe workflow:\n\nParse command: The terminal parser resolves the asset, destination, and optional Base call (selector + args + value).\nStage bridge: queueBridge validates SPL overrides, ABI-encodes the Base call via encodeFunctionData, and stages relay overrides.\nExecute: solanaBridge.bridge() resolves the destination (ENS/Basename), ensures balances, and calls realBridgeImplementation to sign and send the Solana transaction.\nRelay + Call: If relay gas is prepaid, the Base Relayer executes the attached call from the user’s Twin contract immediately after ERC20 SOL is minted.\n\nKey implementation references:\n\nsrc/lib/bridge.ts: Asset resolution (supports mint addresses), environment-aware RPC connections, and call attachment support.\nsrc/lib/realBridgeImplementation.ts: Builds Solana transactions with PayForRelay + bridge_sol/bridge_spl instructions, using per-environment PDAs and gas-fee receivers.\nsrc/components/MainContent.tsx: Terminal UI with command staging, log viewer, and ABI encoding for arbitrary Base calls.\nsrc/components/WalletConnection.tsx: Fetches the deterministic Twin address on Base Mainnet/Sepolia for the connected Solana wallet.\n\n​Running the Terminal\nTerminalgit clone https://github.com/base/sol2base.git\ncd sol2base\nnpm install --legacy-peer-deps\n\n# Configure env (RPC URLs, relayer addresses, CDP API keys, etc.)\ncp env.template .env.local\n\nnpm run dev # defaults to http://localhost:3000\n\nThe terminal exposes both Base Sepolia ↔ Solana Devnet and Base Mainnet ↔ Solana Mainnet. Use the\nnetwork dropdown in the UI to switch.Set CDP_API_KEY in your .env file to get access to the faucet.\n​Contract Addresses\n​Base Mainnet\nBase Mainnet Addresses{\n \"Bridge\": \"0x3eff766C76a1be2Ce1aCF2B69c78bCae257D5188\",\n \"BridgeValidator\": \"0xAF24c1c24Ff3BF1e6D882518120fC25442d6794B\",\n \"CrossChainERC20Factory\": \"0xDD56781d0509650f8C2981231B6C917f2d5d7dF2\",\n \"SOL\": \"0x311935Cd80B76769bF2ecC9D8Ab7635b2139cf82\"\n}\n\n​Solana Mainnet\nSolana Mainnet Addresses{\n \"BridgeProgram\": \"HNCne2FkVaNghhjKXapxJzPaBvAKDG1Ge3gqhZyfVWLM\",\n \"BaseRelayerProgram\": \"g1et5VenhfJHJwsdJsDbxWZuotD5H4iELNG61kS4fb9\"\n}\n\n​Base Sepolia\nBase Sepolia Addresses{\n \"Bridge\": \"0x01824a90d32A69022DdAEcC6C5C14Ed08dB4EB9B\",\n \"BridgeValidator\": \"0xa80C07DF38fB1A5b3E6a4f4FAAB71E7a056a4EC7\",\n \"CrossChainERC20Factory\": \"0x488EB7F7cb2568e31595D48cb26F63963Cc7565D\",\n \"SOL\": \"0xCace0c896714DaF7098FFD8CC54aFCFe0338b4BC\",\n \"FLYWHEEL_ADDRESS\": \"0x00000F14AD09382841DB481403D1775ADeE1179F\",\n \"BRIDGE_CAMPAIGN_ADDRESS\": \"0xE2AD1C34382410C30d826B019A0B3700F5c4e6c9\"\n}\n\n​Solana Devnet\nSolana Devnet Addresses{\n \"BridgeProgram\": \"7c6mteAcTXaQ1MFBCrnuzoZVTTAEfZwa6wgy4bqX3KXC\",\n \"BaseRelayerProgram\": \"56MBBEYAtQAdjT4e1NzHD8XaoyRSTvfgbSVVcEcHj51H\",\n \"GasFeeReceiver\": \"AFs1LCbodhvwpgX3u3URLsud6R1XMSaMiQ5LtXw4GKYT\"\n}\n\n​Resources\nWas this page helpful?Suggest editsRaise issue","tokens":2794,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266199434,"hash":"8344dd3de027a5589f6ded83f0d5e17e9d07bb8b"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/30","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 30 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by AFDudley on Jan 17, 2018\n\n post by ltfschoen on Jan 17, 2018\n\n post by MicahZoltu on Jan 17, 2018\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n post by kz on Jan 30, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n Load more posts below","tokens":1119,"squid":"ink-research","role":"Deep Scholar","at":1791266206652,"hash":"af0aee8420df3f4b22386d01be9bcae03d81aeab"}
{"url":"https://docs.base.org/specifications/base-protocol/bridging/deposits","domain":"docs.base.org","title":"Deposits - Base Documentation","text":"A deposit is a transaction initiated outside Base that becomes a transaction on Base. For Ethereum deposits, the L1 transaction emits data that Base nodes use to derive a corresponding L2 deposit transaction.\nDeposit transactions are included as part of the protocol. They do not use the same signature, nonce, or fee fields as ordinary L2 transactions because they are authorized by the L1 deposit event and pay for L2 gas on L1. For most users, the practical result is simple: after the source-chain transaction is confirmed and processed, the asset or message appears on Base.\nFor available bridge routes, see Bridge to Base.\n​Overview\nDeposited transactions, also known as deposits are transactions which\nare initiated on L1, and executed on L2. This document outlines a new transaction\ntype for deposits. It also describes how deposits are initiated on L1, along\nwith the authorization and validation conditions on L2.\nVocabulary note: deposited transaction refers specifically to an L2 transaction, while\ndeposit can refer to the transaction at various stages (for instance when it is deposited on L1).\n​The Deposited Transaction Type\nDeposited transactions have the following notable distinctions from existing\ntransaction types:\n\nThey are derived from Layer 1 blocks, and must be included as part of the protocol.\nThey do not include signature validation (see User-Deposited Transactions\nfor the rationale).\nThey buy their L2 gas on L1 and, as such, the L2 gas is not refundable.\n\nWe define a new EIP-2718 compatible transaction type with the prefix 0x7E to represent a deposit transaction.\nA deposit has the following fields\n(rlp encoded in the order they appear here):\n\nbytes32 sourceHash: the source-hash, uniquely identifies the origin of the deposit.\naddress from: The address of the sender account.\naddress to: The address of the recipient account, or the null (zero-length) address if the\ndeposited transaction is a contract creation.\nuint256 mint: The ETH value to mint on L2.\nuint256 value: The ETH value to send to the recipient account.\nuint64 gas: The gas limit for the L2 transaction.\nbool isSystemTx: If true, the transaction does not interact with the L2 block gas pool.\n\nThis value is disabled and MUST be false.\n\nbytes data: The calldata.\n\nIn contrast to EIP-155 transactions, this transaction type:\n\nDoes not include a nonce, since it is identified by the sourceHash.\nAPI responses still include a nonce attribute, set to the depositNonce value\nfrom the corresponding transaction receipt.\nDoes not include signature information, and makes the from address explicit.\nAPI responses contain zeroed signature v, r, s values for backwards compatibility.\nIncludes new sourceHash, from, mint, and isSystemTx attributes.\nAPI responses contain these as additional fields.\n\nWe select 0x7E because transaction type identifiers are currently allowed to go up to 0x7F.\nPicking a high identifier minimizes the risk that the identifier will be used by another\ntransaction type on the L1 chain in the future. We don’t pick 0x7F itself in case it becomes used\nfor a variable-length encoding scheme.\n​Source Hash Computation\nThe sourceHash of a deposit transaction is computed based on the origin:\n\nUser-deposited:\nkeccak256(bytes32(uint256(0)), keccak256(l1BlockHash, bytes32(uint256(l1LogIndex)))).\nWhere the l1BlockHash, and l1LogIndex all refer to the inclusion of the deposit log event on L1.\nl1LogIndex is the index of the deposit event log in the combined list of log events of the block.\nL1 attributes deposited:\nkeccak256(bytes32(uint256(1)), keccak256(l1BlockHash, bytes32(uint256(seqNumber)))).\nWhere l1BlockHash refers to the L1 block hash of which the info attributes are deposited.\nAnd seqNumber = l2BlockNum - l2EpochStartBlockNum,\nwhere l2BlockNum is the L2 block number of the inclusion of the deposit tx in L2,\nand l2EpochStartBlockNum is the L2 block number of the first L2 block in the epoch.\nUpgrade-deposited: keccak256(bytes32(uint256(2)), keccak256(intent)).\nWhere intent is a UTF-8 byte string, identifying the upgrade intent.\n\nWithout a sourceHash in a deposit, two different deposited transactions could have the same exact hash.\nThe outer keccak256 hashes the actual uniquely identifying information with a domain,\nto avoid collisions between different types of sources.\nThe Interop derivation spec introduces two additional kinds of system deposits,\nwith domains 3 and 4.\nWe do not use the sender’s nonce to ensure uniqueness because this would require an extra L2 EVM state read from the\nexecution engine during block-derivation.\n​Kinds of Deposited Transactions\nAlthough we define only one new transaction type, we can distinguish between two kinds of deposited\ntransactions, based on their positioning in the L2 block:\n\nThe first transaction MUST be a L1 attributes deposited transaction, followed by\nan array of zero-or-more user-deposited transactions\nsubmitted to the deposit feed contract on L1 (called OptimismPortal).\nUser-deposited transactions are only present in the first block of a L2 epoch.\n\nWe only define a single new transaction type in order to minimize modifications to L1 client\nsoftware, and complexity in general.\n​Validation and Authorization of Deposited Transactions\nAs noted above, the deposited transaction type does not include a signature for validation. Rather,\nauthorization is handled by the L2 chain derivation process, which when correctly\napplied will only derive transactions with a from address attested to by the logs of the L1\ndeposit contract.\n​Execution\nIn order to execute a deposited transaction:\nFirst, the balance of the from account MUST be increased by the amount of mint.\nThis is unconditional, and does not revert on deposit failure.\nThen, the execution environment for a deposited transaction is initialized based on the\ntransaction’s attributes, in exactly the same manner as it would be for an EIP-155 transaction.\nThe deposit transaction is processed exactly like a type-2 (EIP-1559) transaction, with the exception of:\n\nNo fee fields are verified: the deposit does not have any, as it pays for gas on L1.\nNo nonce field is verified: the deposit does not have any, it’s uniquely identified by its sourceHash.\nNo access-list is processed: the deposit has no access-list, and it is thus processed as if the access-list is empty.\nNo check if from is an Externally Owner Account (EOA): the deposit is ensured not to be an EOA through L1 address\nmasking, this may change in future L1 contract-deployments to e.g. enable an account-abstraction like mechanism.\nNo gas is refunded as ETH. (either by not refunding or utilizing the fact the gas-price of the deposit is 0)\nNo transaction priority fee is charged. No payment is made to the block fee-recipient.\nNo L1-cost fee is charged, as deposits are derived from L1 and do not have to be submitted as data back to it.\nNo base fee is charged. The total base fee accounting does not change.\n\nNote that this includes contract-deployment behavior like with regular transactions, and gas\nmetering is the same (with the exception of fee related changes above), including metering of\nintrinsic gas.\nAny non-EVM state-transition error emitted by the EVM execution is processed in a special way:\n\nIt is transformed into an EVM-error:\ni.e. the deposit will always be included, but its receipt will indicate a failure\nif it runs into a non-EVM state-transition error, e.g. failure to transfer the specified\nvalue amount of ETH due to insufficient account-balance.\nThe world state is rolled back to the start of the EVM processing, after the minting part of the deposit.\nThe nonce of from in the world state is incremented by 1, making the error equivalent to a native EVM failure.\nNote that a previous nonce increment may have happened during EVM processing, but this would be rolled back first.\n\nFinally, after the above processing, the execution post-processing runs the same:\ni.e. the gas pool and receipt are processed identical to a regular transaction.\nThe receipt of deposit transactions is extended with an additional\ndepositNonce value, storing the nonce value of the from sender as registered before the EVM processing.\nNote that the gas used as stated by the execution output is subtracted from the gas pool.\nNote for application developers: because CALLER and ORIGIN are set to from, the\nsemantics of using the tx.origin == msg.sender check will not work to determine whether\nor not a caller is an EOA during a deposit transaction. Instead, the check could only be useful for\nidentifying the first call in the L2 deposit transaction. However this check does still satisfy\nthe common case in which developers are using this check to ensure that the CALLER is unable to\nexecute code before and after the call.\n​Nonce Handling\nDespite the lack of signature validation, we still increment the nonce of the from account when a\ndeposit transaction is executed. In the context of a deposit-only roll up, this is not necessary\nfor transaction ordering or replay prevention, however it maintains consistency with the use of\nnonces during contract creation. It may also simplify integration with downstream\ntooling (such as wallets and block explorers).\n​Deposit Receipt\nTransaction receipts use standard typing as per EIP-2718.\nThe Deposit transaction receipt type is equal to a regular receipt,\nbut extended with an optional depositNonce field.\nThe RLP-encoded consensus-enforced fields are:\n\npostStateOrStatus (standard): this contains the transaction status, see EIP-658.\ncumulativeGasUsed (standard): gas used in the block thus far, including this transaction.\n\nThe actual gas used is derived from the difference in CumulativeGasUsed with the previous transaction.\nThis accounts for the actual gas usage by the deposit, like regular transactions.\n\nbloom (standard): bloom filter of the transaction logs.\nlogs (standard): log events emitted by the EVM processing.\ndepositNonce (unique extension): Optional field. The deposit transaction persists the nonce used during execution.\ndepositNonceVersion (unique extension): Optional field. The value must be 1 if the field is present\n\nBefore Canyon, these depositNonce & depositNonceVersion fields must always be omitted.\nWith Canyon, these depositNonce & depositNonceVersion fields must always be included.\n\nThe receipt API responses utilize the receipt changes for more accurate response data:\n\nThe depositNonce is included in the receipt JSON data in API responses\nFor contract-deployments (when to == null), the depositNonce helps derive the correct contractAddress meta-data,\ninstead of assuming the nonce was zero.\nThe cumulativeGasUsed accounts for the actual gas usage, as metered in the EVM processing.\n\n​L1 Attributes Deposited Transaction\nAn L1 attributes deposited transaction is a deposit transaction sent to the L1\nattributes predeployed contract.\nThis transaction MUST have the following values:\n\nfrom is 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001 (the address of the\nL1 Attributes depositor account)\nto is 0x4200000000000000000000000000000000000015 (the address of the L1 attributes predeployed\ncontract).\nmint is 0\nvalue is 0\ngasLimit is set to 1,000,000.\nisSystemTx is set to false.\ndata is an encoded call to the L1 attributes predeployed contract that\ndepends on the upgrades that are active (see below).\n\nThis system-initiated transaction for L1 attributes is not charged any ETH for its allocated\ngasLimit, as it is considered part of state-transition processing.\n​L1 Attributes Deposited Transaction Calldata\n​L1 Attributes - Bedrock, Canyon, Delta\nThe data field of the L1 attributes deposited transaction is an ABI encoded call to the\nsetL1BlockValues() function with correct values associated with the corresponding L1 block\n(cf. reference implementation).\n​Special Accounts on L2\nThe L1 attributes deposit transaction involves two special purpose accounts:\n\nThe L1 attributes depositor account\nThe L1 attributes predeployed contract\n\n​L1 Attributes Depositor Account\nThe depositor account is an EOA with no known private key. It has the address\n0xdeaddeaddeaddeaddeaddeaddeaddeaddead0001. Its value is returned by the CALLER and ORIGIN\nopcodes during execution of the L1 attributes deposited transaction.\n​L1 Attributes Predeployed Contract\nA predeployed contract on L2 at address 0x4200000000000000000000000000000000000015, which holds\ncertain block variables from the corresponding L1 block in storage, so that they may be accessed\nduring the execution of the subsequent deposited transactions.\nThe predeploy stores the following values:\n\nL1 block attributes:\n\nnumber (uint64)\ntimestamp (uint64)\nbasefee (uint256)\nhash (bytes32)\n\nsequenceNumber (uint64): This equals the L2 block number relative to the start of the epoch,\ni.e. the L2 block distance to the L2 block height that the L1 attributes last changed,\nand reset to 0 at the start of a new epoch.\nSystem configurables tied to the L1 block, see System configuration specification:\n\nbatcherHash (bytes32): A versioned commitment to the batch-submitter(s) currently operating.\noverhead (uint256): The L1 fee overhead to apply to L1 cost computation of transactions in this L2 block.\nscalar (uint256): The L1 fee scalar to apply to L1 cost computation of transactions in this L2 block.\n\nThe contract implements an authorization scheme, such that it only accepts state-changing calls from\nthe depositor account.\nThe contract has the following solidity interface, and can be interacted with according to the\ncontract ABI specification.\n​L1 Attributes Predeployed Contract: Reference Implementation\nA reference implementation of the L1 Attributes predeploy contract can be found in L1Block.sol.\n​User-Deposited Transactions\nUser-deposited transactions are deposited transactions\ngenerated by the L2 Chain Derivation process. The content of each user-deposited\ntransaction are determined by the corresponding TransactionDeposited event emitted by the\ndeposit contract on L1.\n\nfrom is unchanged from the emitted value (though it may\nhave been transformed to an alias in OptimismPortal, the deposit feed contract).\nto is any 20-byte address (including the zero address)\n\nIn case of a contract creation (cf. isCreation), this address is set to null.\n\nmint is set to the emitted value.\nvalue is set to the emitted value.\ngaslimit is unchanged from the emitted value. It must be at least 21000.\nisCreation is set to true if the transaction is a contract creation, false otherwise.\ndata is unchanged from the emitted value. Depending on the value of isCreation it is handled\nas either calldata or contract initialization code.\nisSystemTx is set by the rollup node for certain transactions that have unmetered execution.\nIt is false for user deposited transactions\n\n​Deposit Contract\nThe deposit contract is deployed to L1. Deposited transactions are derived from the values in\nthe TransactionDeposited event(s) emitted by the deposit contract.\nThe deposit contract is responsible for maintaining the guaranteed gas market,\ncharging deposits for gas to be used on L2, and ensuring that the total amount of guaranteed\ngas in a single L1 block does not exceed the L2 block gas limit.\nThe deposit contract handles two special cases:\n\nA contract creation deposit, which is indicated by setting the isCreation flag to true.\nIn the event that the to address is non-zero, the contract will revert.\nA call from a contract account, in which case the from value is transformed to its L2\nalias.\n\n​Address Aliasing\nIf the caller is a contract, the address will be transformed by adding\n0x1111000000000000000000000000000000001111 to it. The math is unchecked and done on a\nSolidity uint160 so the value will overflow. This prevents attacks in which a\ncontract on L1 has the same address as a contract on L2 but doesn’t have the same code. We can safely ignore this\nfor EOAs because they’re guaranteed to have the same “code” (i.e. no code at all). This also makes\nit possible for users to interact with contracts on L2 even when the Sequencer is down.\n​Deposit Contract Implementation: Optimism Portal\nA reference implementation of the deposit contract can be found in OptimismPortal.sol.\n​Guaranteed Gas Fee Market\nDeposited transactions are transactions on L2 that are\ninitiated on L1. The gas that they use on L2 is bought on L1 via a gas burn (or a direct payment\nin the future). We maintain a fee market and hard cap on the amount of gas provided to all deposits\nin a single L1 block.\nThe gas provided to deposited transactions is sometimes called “guaranteed gas”. The gas provided to\ndeposited transactions is unique in the regard that it is not refundable. It cannot be refunded as\nit is sometimes paid for with a gas burn and there may not be any ETH left to refund.\nThe guaranteed gas is composed of a gas stipend, and of any guaranteed gas the user would like\nto purchase (on L1) on top of that.\nGuaranteed gas on L2 is bought in the following manner. An L2 gas price is calculated via an\nEIP-1559-style algorithm. The total amount of ETH required to buy that gas is then calculated as\n(guaranteed gas * L2 deposit base fee). The contract then accepts that amount of ETH (in a future\nupgrade) or (only method right now), burns an amount of L1 gas that corresponds to the L2 cost (L2 cost / L1 base fee). The L2 gas price for guaranteed gas is not synchronized with the base fee on\nL2 and will likely be different.\n​Gas Stipend\nTo offset the gas spent on the deposit event, we credit gas spent * L1 base fee ETH to the cost\nof the L2 gas, where gas spent is the amount of L1 gas spent processing the deposit. If the ETH\nvalue of this credit is greater than the ETH value of the requested guaranteed gas (requested guaranteed gas * L2 gas price), no L1 gas is burnt.\n​Default Values\nVariableValueMAX_RESOURCE_LIMIT20,000,000ELASTICITY_MULTIPLIER10BASE_FEE_MAX_CHANGE_DENOMINATOR8MINIMUM_BASE_FEE1 gweiMAXIMUM_BASE_FEEtype(uint128).maxSYSTEM_TX_MAX_GAS1,000,000TARGET_RESOURCE_LIMITMAX_RESOURCE_LIMIT / ELASTICITY_MULTIPLIER\n​Limiting Guaranteed Gas\nThe total amount of guaranteed gas that can be bought in a single L1 block must be limited to\nprevent a denial of service attack against L2 as well as ensure the total amount of guaranteed gas\nstays below the L2 block gas limit.\nWe set a guaranteed gas limit of MAX_RESOURCE_LIMIT gas per L1 block and a target of\nMAX_RESOURCE_LIMIT / ELASTICITY_MULTIPLIER gas per L1 block. These numbers enabled\noccasional large transactions while staying within our target and maximum gas usage on L2.\nBecause the amount of guaranteed L2 gas that can be purchased in a single block is now limited,\nwe implement an EIP-1559-style fee market to reduce congestion on deposits. By setting the limit\nat a multiple of the target, we enable deposits to temporarily use more L2 gas at a greater cost.\nGuaranteed Gas Market Pseudocode# Pseudocode to update the L2 deposit base fee and cap the amount of guaranteed gas\n# bought in a block. Calling code must handle the gas burn and validity checks on\n# the ability of the account to afford this gas.\n\n# prev_base fee is a u128, prev_bought_gas and prev_num are u64s\nprev_base_fee, prev_bought_gas, prev_num = <values from previous update>\nnow_num = block.number\n\n# Clamp the full base fee to a specific range. The minimum value in the range should be around 100-1000\n# to enable faster responses in the base fee. This replaces the `max` mechanism in the ethereum 1559\n# implementation (it also serves to enable the base fee to increase if it is very small).\ndef clamp(v: i256, min: u128, max: u128) -> u128:\n if v < i256(min):\n return min\n elif v > i256(max):\n return max\n else:\n return u128(v)\n\n# If this is a new block, update the base fee and reset the total gas\n# If not, just update the total gas\nif prev_num == now_num:\n now_base_fee = prev_base_fee\n now_bought_gas = prev_bought_gas + requested_gas\nelif prev_num != now_num:\n # Width extension and conversion to signed integer math\n gas_used_delta = int128(prev_bought_gas) - int128(TARGET_RESOURCE_LIMIT)\n # Use truncating (round to 0) division - solidity's default.\n # Sign extend gas_used_delta & prev_base_fee to 256 bits to avoid overflows here.\n base_fee_per_gas_delta = prev_base_fee * gas_used_delta / TARGET_RESOURCE_LIMIT / BASE_FEE_MAX_CHANGE_DENOMINATOR\n now_base_fee_wide = prev_base_fee + base_fee_per_gas_delta\n\n now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=UINT_128_MAX_VALUE)\n now_bought_gas = requested_gas\n\n # If we skipped multiple blocks between the previous block and now update the base fee again.\n # This is not exactly the same as iterating the above function, but quite close for reasonable\n # gas target values. It is also constant time wrt the number of missed blocks which is important\n # for keeping gas usage stable.\n if prev_num + 1 < now_num:\n n = now_num - prev_num - 1\n # Apply 7/8 reduction to prev_base_fee for the n empty blocks in a row.\n now_base_fee_wide = now_base_fee * pow(1-(1/BASE_FEE_MAX_CHANGE_DENOMINATOR), n)\n now_base_fee = clamp(now_base_fee_wide, min=MINIMUM_BASE_FEE, max=type(uint128).max)\n\nrequire(now_bought_gas < MAX_RESOURCE_LIMIT)\n\nstore_values(now_base_fee, now_bought_gas, now_num)\n\n​Rationale for Burning L1 Gas\nThere must be a sybil resistance mechanism for usage of the network. If it is very cheap to get\nguaranteed gas on L2, then it would be possible to spam the network. Burning a dynamic amount\nof gas on L1 acts as a sybil resistance mechanism as it becomes more expensive with more demand.\nIf we collect ETH directly to pay for L2 gas, every (indirect) caller of the deposit function will need\nto be marked with the payable selector. This won’t be possible for many existing projects. Unfortunately\nthis is quite wasteful. As such, we will provide two options to buy L2 gas:\n\nBurn L1 Gas\nSend ETH to the Optimism Portal (Not yet supported)\n\nThe payable version (Option 2) will likely have discount applied to it (or conversely, #1 has a\npremium applied to it).\nFor the initial release of bedrock, only #1 is supported.\n​On Preventing Griefing Attacks\nThe cost of purchasing all of the deposit gas in every block must be expensive\nenough to prevent attackers from griefing all deposits to the network.\nAn attacker would observe a deposit in the mempool and frontrun it with a deposit\nthat purchases enough gas such that the other deposit reverts.\nThe smaller the max resource limit is, the easier this attack is to pull off.\nThis attack is mitigated by having a large resource limit as well as a large\nelasticity multiplier. This means that the target resource usage is kept small,\ngiving a lot of room for the deposit base fee to rise when the max resource limit\nis being purchased.\nThis attack should be too expensive to pull off in practice, but if an extremely\nwealthy adversary does decide to grief network deposits for an extended period\nof time, efforts will be placed to ensure that deposits are able to be processed\non the network.Was this page helpful?Suggest editsRaise issue","tokens":5738,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266210268,"hash":"bc408809f503e8fc3fe516e00418314acf645fe4"}
{"url":"https://soliditylang.org/blog/2023/03/10/solidity-developer-survey-2022-results/","domain":"soliditylang.org","title":"Solidity Developer Survey 2022 Results | Solidity Programming Language","text":"Solidity Developer Survey 2022 ResultsPosted by Franziska Heintel on March 10, 2023AnnouncementsThe 2022 Solidity Developer Survey results are in! In this post, we will be summarizing and analyzing them.\nFirst of all, a big thank you to everybody who took the time and participated and to everybody who helped us spread the word about it!\nThis year, we received a smashing 1401 responses. That is more than a 3x in responses compared to the previous survey and we couldn't be happier with the turnout.\nYour input is invaluable to us and plays a crucial role in helping to continuously improve the Solidity developer experience as a whole.\nBefore we get started, here are a few useful links:\n\nIn the spirit of open source, you can find all raw data of the survey results here and all graphs here.\nSince this is already our third time conducting a yearly survey, it may be interesting for you to compare the outcome to the previous surveys. The results from the 2021 developer survey are available here and from 2020 here.\n\nWithout further ado, let’s dig into the 2022 results!\nSummary & Notable Insights\n\nSurvey Audience: In total, 1401 developers from 100 different countries participated in the 2022 survey. That is more than a 222% increase in responses compared to the previous survey (435 respondents)! The coverage of different geographies also continuously increased from 48 countries in 2020 to 73 countries in 2021 to 100 countries in 2022. Roughly 18% stated to be residing in the US, followed by India (10%) and France (5%).\nDeveloper Profiles: The level of coding experience remains at a medium to a high level, with the majority of respondents having coded professionally for 3 or more years, 12.5% even more than 15 years.\nSolidity Experience: More than half of all respondents have been using Solidity for less than a year, while 13.8% have been using it for more than 3 years. 41% use Solidity daily, and 37.3% weekly.\nSolidity Expertise: Many deem themselves Solidity experts, with a self-rating in the expertise of 7 or higher (out of 10). 4.6% rate their expertise as a 10 out of 10. 70% of those have been using Solidity for 2-3 years or longer.\nDeveloper Experience: The majority (+75%) believe that the Solidity developer experience improved in the last year. 0.9% are of the opinion it got worse. Debugging issues are frequently encountered, followed by stack-too-deep errors and bytecode size limitations.\nFuture Features: Support for decimal numbers and generics was mentioned most often as the “most anticipated Solidity feature”.\nLiked & Dreaded Features: Respondents most like Solidity's syntax, the simplicity of learning, reading, coding, and compiling, and the static typing. The most significant pain point is “stack-too-deep”, with 33.6% of all votes, followed by missing memory optimizations (waste of memory) (24.4%) and redundant checks (e.g. in checked arithmetic) (11.8%). 9.9% say that compiler performance is their biggest issue.\n\nDemographics of the Survey Audience\n⚠️ Be aware that this survey has only been shared in English when interpreting results regarding the distribution of countries of residency and language preferences.\nAs usual, we begin by looking at the developers who participated in this survey: In this first chapter, we cover general information on the survey audience, which includes residency and spoken languages.\nIn total, 1401 developers from 100 different countries participated in the 2022 survey. Compared to the previous survey, this represents a 222% increase in responses.\nThe coverage of different geographies increased from 73 countries in 2021 to 100 countries in 2022.\nResidency\nRoughly 18% of respondents stated to be residing in the US, followed by India (10%), France (5%), and Nigeria (4.5%).\n\nLanguage\nThe diversity of respondents did not only increase in terms of countries of residency but also in terms of the native language. In total, 70 different languages were mentioned as their native languages.\nThat’s a 40% increase compared to the previous year.\n31.5% state English as their native language, followed by Indian languages (12.4%), Spanish (8.4%), French (6.9%), Russian (6.4%), and German (4.7%).\nℹ️Hindi, Urdu, Telugu, Bengali, Tamil, Malayalam, Gujarati, Marathi, Kannada, and Odia were clustered as “Indian languages”. Chinese, Cantonese, and Mandarin were clustered as “Chinese languages”. Persian, Pashto, and Ossetian were clustered as “Iranian languages”.\n\nWith almost 80%, the majority of respondents predominantly speak English at work.\nOther languages that are spoken at work: French (3.2%), Russian (3.1%), and Chinese languages (2.3%).\n\nOf the respondents who didn't name English as their native language, 87% are okay with reading the Solidity documentation in English.\n12.9% would prefer to read it in their native language, the most mentioned ones being Spanish, Indian languages, and Russian.\n\nℹ️ Note: This survey has only been conducted in English, which may have impacted the outcome of this question. We still believe internationalization of resources like the Solidity documentation is a crucial factor in lowering the barriers of entry, and we aim to support by helping coordinate the community-driven translation efforts.\n\nDeveloper Profile\nIn the second section of the Solidity Developer Survey, we learn more about the professional experience and coding preferences of the survey audience.\nWork Experience & Employment\nRoughly 71% of respondents were employed at the time of the survey, while roughly 12% stated they were students, and 17% said they were currently not working professionally.\nCompared to the previous survey, there is a slight increase in both the number of students and currently unemployed developers.\n\nThe employed respondents predominantly work in the “crypto” (58.2%) and technology (21.6%) and financial services (5.4%) sector.\n\n37,1% of all respondents are seniors and have been coding professionally for 6 years or more, 12.5% of them even for 15+ years.\nOn the other side, roughly 12% are coding newbies and have only coded professionally for less than a year.\nWith approximately 22%, the biggest group sits in the middle of the distribution and has professional coding experience of 3-5 years.\nOverall, the level of coding experience is medium to high with the majority of respondents (59.2%) having coded professionally for 3 or more years.\n7.7% have never coded as part of their job, 37% of which are students.\n\nTouch Points with Solidity\nAs in the previous survey, the majority of respondents (75.7%) still use Solidity for their personal projects.\nRoughly 64% of all respondents use Solidity at work.\nMore than 20% state they are leading a programming team.\n\nOnly 23.4% of respondents contribute to open-source projects written in Solidity on a daily or weekly basis. The rest states to do so monthly (27.4%) or never (47.1%).\n\nProgramming Language Preferences\nSolidity marks the most used programming language for the survey audience (28.6%), closely followed by JavaScript (25.6%) and TypeScript (20.5%).\nOther less frequently mentioned languages are Python (8.7%), Rust (2.7%), and Go (2.5%).\n\nSimilar to the previous year, the respondents' favorite programming languages are distributed more evenly across various languages.\nSolidity is the most popular, scoring 18.8% of all entries, followed by JavaScript (17.3%), Python (15.2%), TypeScript (15.0%), and Rust (8.6%).\n\nOperating System\nMost respondents use MacOS as their primary Operating System (41.8%). Windows and Linux seem comparatively popular, with 30.5 and 27.7%, respectively.\n\nSolidity User Profile\nIn this section of the survey, we asked respondents about their Solidity-specific development experience and usage habits.\nSolidity Experience\nAlmost 50% of all respondents deem themselves Solidity experts, with a self rating in expertise of 7 or higher (scale of 10).\n4.6% rate their expertise as a 10 out of 10, and 70% of those have been using Solidity for 2-3 years, or longer.\nRoughly 23% can be considered beginners or low-frequency users with a self-rated expertise level of 4 or lower.\nThe distribution of self rating remained similar to the previous survey, even though the survey audience tripled in size.\n\nRoughly 50% of all respondents have been using Solidity for less than a year, with 13% having just started their Solidity journey (less than three months of experience).\n13.83% have been using Solidity for more than 3 years and can thus be considered “Solidity seniors''.\nTo put years into perspective: “Version 0.1.1”, the oldest version of Solidity on solc-bin, is from August 2015 and thus roughly 7.5 year old.\nThe language is still relatively young and continues to evolve. We may add more granular selection options for “more than 3 years” of Solidity experience to distinguish this better in the next survey.\n\nAs in previous years, Solidity appears rather easy to learn, with 21.2% of respondents feeling productive in less than a month and 39.3% in less than half a year.\n8.1% needed more than a year to feel comfortable with the language.\n17.8% don't feel productive yet, out of which more than 74.2% are beginners and have been using Solidity for 6 months or less, and 47% even less than three months.\n\nSolidity User Profile and Usage Habits\nWith regards to usage frequency, more than 40% of respondents use Solidity on a daily basis!\n37.3% use it weekly, and 13.9% on a monthly basis.\nRoughly 8% indicated to be using Solidity \"rarely\" or \"never\".\nMost of them indicated before that they use Solidity for personal projects and code in a different programming language at work.\n\nA striking 81.8% of all respondents use Visual Studio Code as their editor when writing Solidity code.\nVim and IntelliJ follow in the second and third ranks with 3.7 and 3.4% usage, respectively.\nCompared to the previous survey in 2021, Visual Studio code gained significantly in popularity (from roughly 50% to 81.8%).\n\nDepending on the chosen IDE, we also asked respondents which Solidity-related plugins they use, if any.\n“HardHat VSCode” by Nomic Foundation and the “Solidity” extension by Juan Blanco (both for Visual Studio Code) are the most popular.\n\nHardhat remains the most popular Ethereum-specific development environment, with roughly 75% of all respondents using Hardhat.\nRemix follows with 42%. Foundry has significantly increased its share from 1.6% in 2021 to 30% in 2022.\nTruffle continues to move more into the background, with 17% of respondents indicating that they use it.\nRather \"niche\" Ethereum-specific development environments are Brownie (6.7%), Ape (3.3%), Dapptools (2.3%), and Embark (0.8%).\n4.4% of respondents are not using any Ethereum-specific development environment.\nIt’s worth noting that this question was a checkbox question, allowing respondents to select multiple answers.\n⚠️ Comparing the results from 2020, 2021, to 2022 may offer some insights like Truffle losing a significant share (2020: 59.3% -> 2021: 26.2% -> 2022: 17%), while Hardhat, and newcomers like Foundry increased their share in users. However, it's important to consider that the previous surveys had significantly fewer responses (2020: 194, 2021: 435, 2022: 1401). A year-on-year comparison can only be interpreted as a loose trend and it’s not the intent of this study to analyze user splits between IDEs in detail.\n\nWith roughly 90%, 0.8.x Solidity versions remain to be the by far most used ones. The usage share of both the 0.7.x (10.2%) and the 0.6.x (7.7%) series continues to decrease since the previous survey. Everything older than that is hardly in use anymore.\n\n⚠️ Reminder: Please make sure to frequently update your code (and compiler) to the latest Solidity version. Several important bug fixes and security improvements are added in the newer versions!\nSolidity Usage Details\nThis year, we also asked specific questions about Solidity usage habits.\nFor charts and figures on those, please refer to the presentation with all graphs and the raw data file.\nTo summarize:\n\nCommand line: Roughly two thirds of respondents do not use the Solidity compiler directly via the command line. 37.5% do.\nCommand line: When using the compiler on the command line, 61.3% still use Standard JSON.\nOptimizer: 93.6% do not disable the optimizer. The 6.4% that enabled the optimizer, stated that they would do so due to contract size limits, slow compilation, in order to pass EtherScan verification, for gas testing purposes or because of security concerns.\nGas estimator: 23.4% use the gas estimator that is built into the compiler. 25% have tried it, but don’t use it regularly, while 41.5% never use it.\nSMTChecker: 81% of all respondents never use the SMTChecker. 13.7% have tried it and 5.4% use it frequently. You can learn more about the SMTChecker here.\nvia-IR compilation pipeline: 70.8% do not know what via-IR is. 18.6% use the via-IR pipeline already. In the following weeks, we will share more context about why you should switch from the legacy compilation pipeline to via-IR and what this means.\nMetadata publication: 53.5% publish the metadata of their smart contracts. 27.8% don’t, while 18.7% don’t know what this means.\nSourcify: 11% of all respondents use Sourcify for smart contract verification, while 21.2% claim to not need it. 67.8% don’t know what Sourcify is. If you want to learn more about Sourcify, visit sourcify.dev.\n\nFixed-Point Types\nApproximately 91% of all survey respondents don’t use fixed-point types.\nThe 9% (100 people) that do primarily use PRB Math, solmate’s FixedPointMathLib, and custom implementations.\n\nOther EVM Networks\nMore than half of all respondents use Solidity outside of Ethereum Mainnet and testnets.\nWhen asked which other networks they deploy their smart contracts on, the most popular chain was by far Polygon (formerly Matic Network).\nOther often mentioned blockchains include Binance Smart Chain, Arbitrum, Avalanche and Optimism.\n\nOther Smart Contract Languages\nHalf of all respondents use other smart contract languages alongside Solidity.\nThe most used other smart contract language is Yul, an intermediate language for Solidity, with 17.2%, followed by Vyper, a pythonic EVM language, with 10.5%.\nCairo (7.1%), a STARK based language targeting StarkNet, and Huff (6.2%), a low-level assembly language for the EVM, are also mentioned several times.\nOther “newcomers” like Sway (2.4%) and Fe (1.5%) also make it into the chart.\n\nSolidity Developer Experience\n76.5% of all respondents believe that the Solidity developer experience generally improved throughout the last year. 25.1% are of the opinion that they noticed a big improvement compared to the previous year.\n7.8% say that nothing has changed in their experience, while 0.9% of the respondents think it got worse.\nCompared to the previous year’s results, the share of “got worse” and “I don’t know” decreased, while “no change” slightly increased. Overall, the picture is very comparable.\n\nWhen getting stuck on a Solidity problem, most respondents visit Ethereum StackExchange / StackOverflow for help or search for a solution on the Internet.\nMany also ask their coworkers for help or watch tutorial videos.\n\nRecurring Issues\n60% of respondents don't encounter the same or similar issues multiple times when developing in Solidity.\nAmongst the 40% that do, debugging issues are encountered most frequently, followed by stack-too-deep errors and bytecode size limitations.\nℹ️On the topic of debugging issues, we'd like to use the opportunity to highlight a new initiative aimed at defining a common debugging data format for languages built on top of the EVM: ethdebug. The end result will be a specification that will allow debuggers, analyzers, and other tools to reliably map between the EVM bytecode produced by compilers and the high-level language features. This has been a common pain point across the ecosystem for years and is becoming more pressing with the introduction of the new IR-based code generator (i.e. the via-IR pipeline) in Solidity, which often breaks implicit assumptions tools made based on how the legacy pipeline worked. We encourage all developers working on such tools to join the working group. The group has regular bi-weekly meetings and coordinates via the ethdebug channel on Matrix.\n\nGetting Started & Documentation\nMost respondents considered it easy or “okay” to get started using the Solidity compiler.\n4.2% (55 people) stated that it was difficult for them. When asked what made it difficult to get started, some mentioned a previous lack of technical background or development experience, and others also pointed out a lack of good learning resources or outdated learning resources.\n\nAlmost 64% of survey respondents consider the Solidity documentation helpful, followed by 33% who deem it “somewhat” useful. Only 3.3% don’t find it useful at all.\nIdeas for improvement most prominently ask for more code examples but also a better high-level overview of syntax, better in-docs search, better SEO, and easier wording.\n\nBiggest Pain Points\nDifferent from the previous years, this year, we tried to structure the question around the “biggest pain points” better and clustered the first step into several prominent categories: Stack-to-deep, gas related issues, compiler performance, and “other”.\nThe biggest pain point is “stack-too-deep”, with 33.6% of all votes, followed by missing memory optimizations (waste of memory) (24.4%) and redundant checks (e.g. in checked arithmetic) (11.8%).\n9.9% say that compiler performance is their biggest issue.\n15.8% selected “other” and were able to specify their most significant pain point in a free text field. Most prominently mentioned: Contract size limit, error messages, and issues with debugging.\n\nHigh-Impact Compiler Bugs\nAs part of this year’s study, we were also curious to find out whether Solidity developers had been affected by any of the high-impact compiler bugs (codegen bugs that are announced with Security Alerts on the Solidity blog).\nInitially, 4.7% said yes. However, when asked which one they were affected by, only two out of the 63 people were able to point to actual Solidity vulnerabilities in the follow-up question.\nThis gives room to assume the actual number of affected developers from this survey is significantly lower than 4.7%, and some respondents may have simply misunderstood the question.\nWe will try to phrase this question more precisely in the next survey.\n\nLanguage Design & Upcoming Features\nFavorite Feature / Solidity Aspect\nRespondents most like Solidity's syntax, the simplicity with regards to learning, reading, coding and compiling and static typing.\nThe most mentioned liked features in descending order were:\n\nSyntax\nEasy to... read/code/compile/learn\nSimplicity\nStatic/strong/strict typing\nSimilarity to other languages (most mentioned JS/TS and object-orientedness, also mentioned: Rust, C++, Python)\nModifiers\nInline assembly\nMappings\nInheritance\n(User-defined) types\nSafeMath / checked and unchecked\nYul\n\nMost Dreaded Aspect\nThis year, we asked the survey audience a slightly different question: “If you could change one thing about Solidity, what would it be?”\nMost mentioned “change requests” in descending order were:\n\nFix stack-too-deep\nBetter array handling\nGas optimizations\nAdd fractional numbers (fixed point types / floating types)\nBetter error handling, descriptions\nBetter debugging\nHigher contact bytecode size limit\n\nFuture Features\nMost Anticipated Feature\nSupport for fractional numbers and generics was mentioned most often as the “most anticipated Solidity feature”.\n⚠️ Similar to the previous year, we noted that respondents were using various different terms like \"floats\", \"floating point arithmetic\", \"floating point number\", \"fixed point numbers\", and \"fixed point math\". We categorized those as \"fractional numbers\".\nMost mentioned anticipated features in descending order:\n\nSupport for fractional numbers (fixed point types / floating points)\nGenerics\nBetter optimization\nNo stack-too-deep\nBetter debugging\nTransient storage\nStandard library\nBetter error messages\n\nEIP Support\nWe also wanted to know what Solidity-related EIPs the survey respondents think need support in the compiler.\nEIP-2535 “‘Diamonds, Multi-Facet Proxy” was mentioned most often, followed by EIP-1153 “Transient Storage” and EIP-3540 “EOF - EVM Object Format”.\n\nRestrictiveness\nRegarding language restrictiveness, roughly 43% of respondents wish that Solidity stays “as is”. 41% tend towards more restrictive/explicit, having more checks, while approximately 16% would like Solidity to be less restrictive.\n\nSolidity Developer Community\nLanguage Design Community Participation\nLess than 10% of all respondents ever participated in Solidity language design related efforts.\nThe distribution between participating in forum discussion and proposing features or language changes as a Github issue is fairly similar,\nwhile language design discussions and feedback calls have slightly less participation (all between 80 - 108 people, multiple selections possible).\nOf the roughly 90% that did not participate in language design, most state they don’t know how, followed by being “too busy with work or other things”.\nRoughly 30% say that they are not interested in or qualified for the discussions.\n\nStaying Informed\nSimilar to the previous years, most people like to stay up-to-date about Solidity versions, security alerts, and announcements by following Solidity on Twitter or Mastodon.\nOther often used means for information are the Solidity blog and Solidity GitHub release page.\nInterestingly, almost 30% claim to not be doing any of the above.\nAs part of “other”, respondents specified several community based means to stay up-to-date:\n\nYouTube\nCrypto Twitter / Community chats\nSolidity docs\n\"Week in Ethereum News\" Newsletter\n\"Crypto influencers\" / Popular Solidity developers\nUpdating RemixIDE / Hardhat / VS Code\nCoworkers\nGoogle\nNewsletters\nConferences / Meetups\nOpenZeppelin forum\nSolidity website\nReddit\n\nInteraction with Other Solidity Developers\nMore than half of respondents interact with other Solidity developers.\n16.7% don’t interact with other Solidity developers at all.\n\nLike in the previous years, as the last part of the survey, we wanted to hear how many participants agree or disagree with several statements regarding the Solidity community and the work of the Solidity team.\n\n66% of respondents feel (somewhat) welcome in the Solidity developer community.\nRoughly 77% agree or somewhat agree that they feel confident in the work of the Solidity team.\nMore than half feel welcome to contribute to Solidity, however, only less than 40% say that they know how to contribute ideas or feedback to Solidity.\nRoughly 25% are confident that the Solidity team understands their needs as a developer. Another 35% somewhat agree, while approximately 9% disagree or strongly disagree.\n\nThe results of this “community and Solidity team confidence ranking” are very comparable to the previous year.\nOne can derive that while the community seems confident in the competency/qualification of the Solidity team, the communications around ways to contribute as well as understanding of the community’s needs, can be improved.\nThose are things that we have been working on improving throughout the last years and will continue to do so.\n\nThank You & See You Next Year!\nLastly, we want to take the opportunity to thank you for all your lovely and motivating messages and the feedback received.\nWe were overwhelmed by the sheer number of survey responses and hope to continue this trend in the coming years!\nWe hope the insights from this survey were useful to you, as they certainly are for us!\nWe will continue to collect feedback on an ongoing basis.\nTo not miss anything, make sure to:\n\nFollow Solidity on Twitter or Mastodon.\nJoin the language design discussions in the Solidity forum or provide us feedback there.\nFollow announcements and security alerts on the Solidity blog.\nFollow and ⭐ the Solidity repo on Github.\n\nAll graphs can be found here. The raw and analyzed data can be found here.Previous postNext post","tokens":6028,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266215851,"hash":"47681d061d9fc622ed748355021645ca6e35c74e"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/31","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 31 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n Load more posts below","tokens":3311,"squid":"ink-research","role":"Deep Scholar","at":1791266216900,"hash":"bcea33de39d9446e2d8bb28884139b406ecbbcfa"}
{"url":"https://www.soliditylang.org/blog/2022/02/07/solidity-developer-survey-2021-results/","domain":"soliditylang.org","title":"Solidity Developer Survey 2021 Results | Solidity Programming Language","text":"Solidity Developer Survey 2021 ResultsPosted by Franziska Heintel on February 7, 2022AnnouncementsIn this post, we will be summarizing and analyzing the results of the 2021 Solidity Developer Survey.\nA big thank you goes out to everybody who took the time and participated!\nYour input is invaluable to us and plays a crucial role in helping to continuously improve the Solidity developer experience as a whole.\nSummary & Notable Insights\n\nSurvey Audience: In total, 435 developers from 73 different countries participated in the 2021 survey. Compared to 2020, that is more than a 100% increase in responses. The coverage of different geographies also drastically increased from 48 countries in 2020 to 73 countries in 2021. More than 20% stated to be residing in the US, followed by India (9%) and Germany (4%). Roughly 9% preferred to not share details on their location.\nDeveloper Profiles: The level of coding experience is medium to high with the majority of respondents having coded professionally 3 or more years, 36.6% even more than 6 years.\nSolidity Experience: More than half of all respondents have been using Solidity less than a year, while 15.5% have been using it more than 3 years. Almost 80% use Solidity daily or weekly.\nSolidity Expertise: Most respondents deem themselves Solidity experts, with a self rating in expertise of 7 or higher (scale of 10). 4.2% rate their expertise as a 10/10. 80% of respondents use Solidity for their personal projects, roughly 60% also use it at work. More than half of all respondents have been using Solidity for less than a year.\nDeveloper Experience: The majority (+70%) believes that the Solidity developer experience improved in the last year. Only 1.6% are of the opinion it got worse.\nLanguage Restrictiveness: More than 60% of respondents wish that Solidity becomes more restrictive/explicit (having more checks). 26% would prefer it to remain as is.\nFuture Features: A more efficient optimizer and the ability to catch custom errors are ranked as most important future features under discussion. Moreover, support for fractional numbers, better array management and fixing stack too deep are among the most mentioned anticipated features.\nLiked & Dreaded Features: Respondents most like Solidity's simplicity, the \"easy to learn\" aspect of it, SafeMath by default and modifiers. Dreaded topics are debugging, the stack too deep error and missing support for fractional numbers.\nCommunity: Less than a third of respondents ever participated in Solidity language design related efforts.\n\n[1] Survey Audience\n⚠️ Note that the fact that this survey has only been shared in English is an important factor to consider when interpreting results regarding the distribution of countries of residency and language preferences.\nTo begin with, let us look at the developers who participated in this survey: We will elaborate on general information like location and spoken languages and also learn more about their professional experience, coding preferences and more.\nIn total, the 2021 survey received 435 responses from developers from 73 different countries. Compared to 2020, that is more than a 100% increase in responses. It appears this survey also reached a geographically much more diverse audience since the number of countries climbed from 48 in 2020 to 73 in 2021.\n\nResidency\nMore than 20% stated to be residing in the US, followed by India (9%) and Germany (4%). Roughly 9% preferred to not share details on their location.\n\nLanguage\nThe respondents cover a wide variety of languages with their native languages. In total, 50 different languages were mentioned as native language.\n35% consider English their native language, followed by Spanish (9.4%), French (5.9%), Russian (5.9%), Portuguese (4.9%) and German (4.9%).\n\nThe big majority of more than 80% predominantly speaks English at work.\nSeveral respondents also speak Spanish (2.8%), French (2.1%), Russian (1.6%) or Portuguese (1.6%) at work.\n\nOf the respondents who didn't name English as their native language, more than 90% are okay with reading the Solidity documentation in English. 8.6% would prefer to read it in their native language, the most mentioned ones being Mandarin and Traditional Chinese, Spanish and Portuguese.\n\nℹ️ Bear in mind that this survey has only been conducted in English, which may have an impact on the outcome of this question. We still believe internationalization of resources like the Solidity documentation is a crucial factor to lower the barriers of entry and we aim to support community efforts to translate with a new, clearer structured translation guide.\nDeveloper Profile\nWork Experience & Employment\n77.1% of respondents are currently employed, while roughly 10% are students and 12.5% are currently not working professionally.\n\nThe respondents predominantly work in the technology (62.8%) and financial services (15.5%) sector. The last third splits into various other sectors.\n\nRoughly 10% are coding newbies and have only coded professionally for less than a year. On the other hand, a similar number of respondents has coded for more than 15 years.\nWith approximately 30%, the biggest group sits in the middle of the distribution and has professional coding experience of 3-5 years.\nOverall, the level of coding experience is medium to high with the majority of respondents having coded professionally 3 or more years, 36.6% even more than 6 years.\n\nInterestingly, the majority of respondents (80.4%) use Solidity for their personal projects. Roughly 60% of all respondents use Solidity at work, while 40% predominantly code in another programming language at their job.\nMore than 20% state they are leading a programming team.\n\nIn terms of open-source contributions, unfortunately 60% of respondents say that they never, or only infrequently contribute to open-source projects written in Solidity.\nOn the other hand, almost 30% do so on a daily or weekly basis.\n\nProgramming Language Preferences\nJavaScript and Solidity share rank 1 in terms of most used programming languages (both 27%), followed by TypeScript (14.7%) and Python (10.9%).\n\nRespondents' favorite programming languages are distributed more evenly across various languages. Python is most popular, scoring 22.7% of all entries, followed by Solidity (19.4%), JavaScript (14.5%), TypeScript (10.8%), and Rust (8.4%).\n\nOperating System\nSimilar to the 2020 survey, macOS and Linux seem equally popular. Roughly 40% use macOS, closely followed by Linux (36.6%). Windows is used by 22% of respondents, most of who state to be using either macOS or Linux in addition to Windows. There are also several developers using both Linux and macOS, or even all three operating systems.\n\nSolidity Experience & Solidity Developer Profile\nMost respondents deem themselves Solidity experts, with a self rating in expertise of 7 or higher (scale of 10). 4.2% rate their expertise as a 10/10. Roughly 23% can be considered beginners or low-frequency users with a self-rated expertise level of 4 or lower.\n\nThe share of beginners has increased slightly compared to last year with more than half of all respondents using Solidity for less than a year.\n15.5% have been using Solidity for more than 3 years and can thus be considered Solidity seniors.\n\nSolidity remains to appear rather easy to learn with 26.7% of respondents feeling productive in less than a month and 30.7% in less than half a year. 7.7% needed more than a year to feel comfortable with the language. 23.3% don't feel productive yet, out of which more than 75% are beginners and have been using Solidity for 6 months or less.\n\nSolidity Developer Profile\nThe majority (roughly 80%) of respondents use Solidity on a daily or weekly basis. 8% indicated to be using Solidity \"rarely\" or \"never\", out of which almost all predominantly code in another programming language at work and most indicated they only have been using Solidity for less than 3 months.\n\nMore than 50% use VSCode as an editor to write Solidity, followed by Visual Studio (14%) and Remix (11%). Vim is used by 7% of respondents, followed by IntelliJ (5.8%) and Atom (3%).\nCompared to 2020, IntelliJ, Atom, Vim and Sublime are used less in 2021.\n\nHardhat becomes the most popular Ethereum-specific development environment with ~65% of all respondents using it (from 38.6% in 2020).\nTruffle and Remix follow with a user share of roughly 25-26% each. Rather \"niche\" Ethereum-specific development environments are Brownie (10.5%), Dapptools (8.2%), Scaffold-ETH (4.7%), Foundry/Forge (1.6%) and Embark (0.7%). 3.5% of respondents are not using any Ethereum-specific IDE.\nCompared to 2020, Truffle (2020: 59.3% -> 2021: 26.2%) and Remix (2020: 50.3% -> 2021: 24.8%) lost significant share, while Hardhat, Brownie, Dapptools and newcomers like Foundry increased their share in users. It's important to note that the 2020 survey had significantly fewer responses (2020: 194 -> 2021: 435), hence the year-on-year comparison can only be interpreted as a loose trend but doesn't have proper statistical relevance due to the small lot size.\n\nWith 86.3%, 0.8.x Solidity versions are by far the most used ones. Both 0.7.x (23%) and 0.6.x (18.3%) version series remain to be used while everything older than that is hardly in use anymore.\nThis is a great development compared to 2020, when the majority of users was still on the 0.6.x version series.\nLuckily, only a few people are still using very old versions from the 0.4.x or 0.5.x series.\n\n⚠️ Reminder: Please make sure to frequently update your code. Several important bug fixes and security improvements have been added since 0.4.x!\n[2] Solidity User Experience\nThe majority (+70%) believes that the Solidity developer experience improved throughout the last year. Only 1.6% are of the opinion it got worse.\n\nWhen getting stuck on a Solidity problem, 80% try to find solutions in the Ethereum StackExchange or on StackOverflow. Many also ask their coworkers for help (32.9%) or watch tutorials (38.1%). It's also quite popular to leave the problem for a bit, do other work and try solving it later again (29.2%).\n\nRecurring Issues\n30% of respondents don't encounter the same or similar issues multiple times when developing in Solidity.\nAmongst the people that do, stack too deep, bytecode size limit, debugging issues, uncertainties about the optimizer and array handling were mentioned most often as recurring issues.\n[3] Features\nFuture Features\nA more efficient optimizer and the ability to catch custom errors are ranked as most important future features under discussion.\n\nMoreover, support for fractional numbers, better array management and fixing stack too deep are among the most mentioned anticipated features.\n⚠️ We noted that respondents were using various different terms like \"floats\", \"floating point arithmetic\", \"floating point number\", \"fixed point numbers\", \"fixed point math\". We categorized those as \"factional numbers\" and assume that all of the above ultimately aims to describe \"fixed point math\".\nMost mentioned anticipated features in descending order:\n\n\"floats\"\nbetter array management / more functions for array & mappings\nfix stack too deep\ngas optimizations / optimizer improvements\nbetter debugging\nbetter support for strings\neasier/better gas metering while building/developing\nconsole.log()\ncustom errors for require()\ngenerics\nbetter docs (esp. for advanced content like inline assembly, Yul, etc.)\ncodegen via Yul\ncustom value types\nfixed point math\nLSP\n\nMost Liked & Dreaded\nRespondents most like Solidity's simplicity, the \"easy to learn\" aspect of it, SafeMath by default and modifiers.\nMost mentioned liked features in descending order:\n\nsimplicity\neasy to learn\ndomain-specific language / right tool for the job / \"it works\"\nSafeMath by default / over- & underflow checks\nmodifiers\nmappings\nclean syntax\ninterfaces\nstatic typing\nreadability\ninheritance\ngood tooling\nstructs\ninline assembly\ndelegate call\nrequire and assertions\ncustom errors\nmemory management\nevents\nlibraries\ncompiler safety\nABIEncoderV2\nexplicitness\nflexibility\nimmutability\nlanguage safety\nobject orientation\n\nMost dreaded topics are debugging, the stack too deep error and missing support for fractional numbers.\nDreaded features in descending order:\n\ndebugging\nstack too deep\nmissing floating numbers / fixed point numbers\ninline assembly\nambiguous/generic (revert) error messages\narrays\nstrings\ndocs difficult to read and navigate\nbreaking changes in minor versions / lack of compatibility\nsecurity\ngas cost / deploy cost\ninheritance\ntesting\ngas optimization\nmodifiers\noutdated resources / tutorials in community resources\nincreasing complexity\nreturns\nexplicit conversions\nmissing docs on inline assembly / yul\nmissing console.log\nmemory allocation\nmissing standard library\nreentrancy\ntype system\noverride\n\nRestrictiveness\nMore than 60% of respondents wish that Solidity becomes more restrictive/explicit, having more checks. 26% would like it to remain as is.\n\n[4] Solidity Community\nLanguage Design\nLess than 20% of respondents ever participated in Solidity language design related efforts. 6.2% participated in discussions in the Solidity forum, 5.1% joined language design calls and 6.4% opened or contributed to Github issues in the Solidity repository.\nOf the roughly 80% that did not participate in language design, almost 8% state not being interested, while 35% are too busy with their work and 40% don't know how they could get involved.\n\nStaying Informed\nMost people like to stay up-to-date about Solidity versions, security alerts and announcements by following Solidity on Twitter or Mastodon. Other often used means for information are the Solidity blog and Solidity GitHub release page.\n\nInteraction with Other Solidity Developers\nMore than half of respondents interact with other Solidity developers. Interestingly, still almost 45% state that they are only rarely or never in touch with other Solidity developers.\n\nAs the last part of the survey, we wanted to hear how many participants agree or disagree with several statements regarding the Solidity community and the work of the Solidity team.\n\n75% of respondents feel welcome in the Solidity developer community.\nRoughly 80% agree or somewhat agree that they feel confident in the work of the Solidity team.\nMore than half feel welcome to contribute to Solidity, however only less than half say that they know how to contribute ideas or feedback to Solidity.\nRoughly 25% are confident that the Solidity team understands their needs as a developer. Another 40% somewhat agree, while only a fraction disagree or strongly disagree.\n\nThank You & See You Next Year!\nLastly, we want to take the opportunity to thank you for all your lovely and motivating messages and the feedback received.\nWe hope the insights from the 2021 Solidity Developer Survey were useful for you, they certainly are for us!\nWe will continue to collect feedback on an ongoing basis, so please don't stop to hold your eyes and ears open!\nTo not miss anything make sure to...\n\nfollow Solidity on Twitter or Mastodon.\njoin the discussions in the Solidity forum.\nfollow announcements on the Solidity blog.\n\nAll graphs can be found here. The raw and analyzed data can be found here.Previous postNext post","tokens":3810,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266226250,"hash":"ff31f60379c30954383091bb497d4458803a1e91"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/33","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 33 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n Load more posts below","tokens":3370,"squid":"ink-research","role":"Deep Scholar","at":1791266227100,"hash":"2495fdb0e1f2d2a1b602574b51a744b17b26adac"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/34","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 34 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n Load more posts below","tokens":3718,"squid":"ink-research","role":"Deep Scholar","at":1791266237304,"hash":"99a8d0448132770c781fa52627b70f677dc58e35"}
{"url":"https://www.soliditylang.org/blog/2021/01/26/solidity-developer-survey-2020-results/","domain":"soliditylang.org","title":"Solidity Developer Survey 2020 Results | Solidity Programming Language","text":"Solidity Developer Survey 2020 ResultsPosted by Franziska Heintel on January 26, 2021AnnouncementsBefore we dive into the results we want to extend a big thank you to all of the Solidity developers that participated in the very first Solidity Developer Survey, which we conducted at the end of last year!\nWe were overwhelmed by the high quality of the submissions and are happy to extract important insights from your input.\nIn this post, we'll be summarizing and commenting on the results of the survey.\nPlease note that none of the questions in the survey were mandatory. Hence, the amount of replies may vary per question.\nSummary & Notable Insights\n\nSurvey Audience: 193 developers from all over the world replied to this survey, calling 48 different countries their current home. With roughly 20%, the big majority of respondents live in the United States of America, followed by India (8%) and Germany (7%). The majority of respondents speaks English at work.\nDeveloper Profiles: Roughly 65% of respondents have been using Solidity for more than a year, with 43% being \"Solidity pros\" with 2 or more years of experience with the language. Looking at the overall coding seniority of the respondents it appears that a significant number of Solidity users are experienced in other programming languages, as opposed to learning to program for the first time using Solidity.\nSolidity Experience: 43% of respondents rate themselves as Solidity experts with an expertise level of 8 (out of 10) or higher.\nSolidity Developer Experience: While noting many things that could still improve, there was an overall positive/good sentiment towards Solidity. Most respondents believed that the Solidity developer experience had some or much improvement over the last year.\nSolidity's Challenges: The biggest challenge in developer experience for most respondents is the availability and quality of tooling. Also seen as critical aspects in order to foster adoption are error handling, IDE integrations and better documentation.\nMost Liked, Dreaded and Anticipated: Topics with room for improvement that came up a lot: Error handling, debugging, the need for more tools and libraries, and breaking dependencies.\nContributing and Language Design: There was surprisingly little interest and engagement in language design topics, partly because developers didn't know how to get involved, or because they were not interested. (We will work on this! Efforts to foster collaborative language design are under way, we'll share more soon.)\nCommunity: Almost 17% of participants in this survey do not interact with other Solidity developers at all!\n\n(1) Survey Audience and Developer Profiles\nFirst, let's have a look at the developers that participated in the survey. In total, we received 193 responses from 48 different countries.\n\nResidency\n⚠️ Note that the fact that this survey has only been shared in English is an important factor to consider when interpreting results regarding language and country of residency.\nThe respondents stated to live in Algeria, Argentina, Australia, Austria, Belgium, Brazil, Bulgaria, Canada, China, Costa Rica, Denmark, Finland, France, Germany, Ghana, Greece, Honduras, Hong Kong, India, Indonesia, Iran, Ireland, Israel, Italy, Japan, Lithuania, Malaysia, Mexico, Netherlands, New Zealand, Nigeria, Pakistan, Philippines, Poland, Portugal, Romania, Russia, Serbia, Singapore, South Africa, Spain, Switzerland, Taiwan, Thailand, Timor-Leste, Ukraine, United Kingdom and United States of America.\nWith roughly 20%, the big majority of respondents live in the United States of America, followed by India (8%) and Germany (7%).\n\nLanguage\nThe developers speak a wide variety of different languages as their primary language, with English being by far the most popular one. German, Spanish, Russian and French follow with similar levels.\n\nWith 86%, the vast majority of respondents speak English at work.\nAlmost 90% of respondents are okay with reading the Solidity documentation in English while roughly 10% would prefer it to be translated into their native language. Some of the respondents who chose \"native language\" stated English as their primary spoken language though, which results in 95% of participants preferring English for the documentation.\nBear in mind that this survey has only been conducted in English, which heavily influences the outcome of this question. This result will hence not have too much influence on the revamped translation efforts for the Solidity documentation and we will further investigate this topic.\n\nEmployment\n82% of all respondents stated that they are currently employed. 4% identified as students, while 14% stated to not work at the moment.\n\nIndustry\nThe majority of respondents (68%) said they work in the technology industry. 14% work in the financial services industry. Less dominant, but also selected several times, were the energy sector, health care, creative, media & gaming and transportation.\n\nCoding Experience\nThe overall, non-Solidity-related, professional coding experience of respondents was impressive. Around 48% of respondents said they coded as part of their jobs for 6 years or more. Only roughly 7% stated that they have less than 1 year of coding experience.\n\nOperating System\nInterestingly, Linux and macOS seem equally popular, both getting roughly 40% of the repondents' votes. Around 18% use Windows, although a part of these users also state to use another OS in addition to Windows. There are also several developers using both Linux and macOS, or even all three operating systems.\n\nSolidity Usage\nAlmost all of the respondents use Solidity for personal projects outside of work (93%). More than half of the respondents (68%) also say they use Solidity at work and/or code in another programming language at work.\n27% of respondents stated to be managing a programming team while 8% are students.\n\nOpen-Source Code\nStrikingly, the majority of respondents (61%) only infrequently or even never contribute to open-source projects written in Solidity. 21% claim to do it as part of their daily routine.\n\nCoding Preferences\nWe've asked the participants what is most important to them when choosing a programming language. The question had a free text reply field, hence we clustered the responses into overarching categories.\nThe most important aspect, stated by many respondents, was the fact that the programming language has to fit the task, and it has to \"get the job done\".\nAlso ranked very highly were tooling, documentation and community, followed by security of the language, libraries, availability of good resources and learning material as well as a clear or familiar syntax.\nLess frequently mentioned, but still relevant, were descriptive error messages / good debugging, readability, performance and strong types.\nOther aspects that were brought up several times were usability, productivity/efficiency, convenience, expressiveness, maintenance & support, simplicity, good developer experience and robustness (at scale).\n\nFavorite Programming Language\nWhen asked what their favorite programming language was, most respondents said JavaScript (40), followed by Python (33) and Solidity (30). Other popular programming languages were TypeScript (19), Go (15) and Rust (14).\n\nMost Used Programming Language\nThe majority of respondents use JavaScript (36%) the most, followed by Solidity (21%) and TypeScript (11.5%). Also mentioned several times: Python (9%), Go (5%), C++ (3%) and Java (3%).\n\n(2) Solidity Learning Journeys\nAs the next step, we wanted to learn more about the individual learning journey of each respondent. While most respondents managed to feel productive in less than half a year, a quite big share (17%) does not feel productive at this point yet.\n\nLearning\nThe Solidity documentation is the most prominent learning material and primary resource for most respondents to learn Solidity.\nThe practices of reading the open-source Solidity code of big projects as well as watching coding tutorial videos were frequently mentioned.\nAnother prominent way to get started learning Solidity is the CryptoZombies coding game.\nMany respondents used the Ethereum StackExchange to find answers to their questions.\nMassive open online courses (MOOCs) like Udacity, Udemy and university courses were mentioned by several respondents followed by active coding approaches like \"learning by coding\" using Remix and the OpenZeppelin contracts as well as by going through the ConsenSys Academy.\n\nProblem Solving\nWhen getting stuck on a Solidity problem, most Solidity developers visit Ethereum StackExchange for help.\nOther popular solutions are asking friends or coworkers for help, watching tutorial videos or doing other work and trying to solve the problem later.\n\nWhen asked if developers encounter similar issues repeatedly, most responded with \"no\" or explained that with experience and usage, once they knew how to solve the problem they did not encounter the same issues repeatedly.\nThe following issues have been mentioned to still pop up regularly or to be annoying:\n\nStack too deep errors.\nError messages that don't point to the cause of the issue.\nOut of gas errors.\nCompilation errors.\nTooling problems.\nVerification difficulties.\nBreaking changes and broken dependencies.\n\n(3) Understanding the Solidity Developer Experience\nSolidity Usage\nRoughly 65% of respondents have been using Solidity for more than a year, with 43% being real Solidity pros with more than 2 years of experience with the language.\nIt's interesting to see that a fair share of 35% is just getting started with Solidity and has only been using it for under 12 months.\nLooking at the overall coding seniority of the respondents, this data shows us that a majority of Solidity developers are developers with experience in other programming languages, rather than someone learning to program for the first time in Solidity.\n\n43% of respondents rate themselves Solidity experts with an expertise level of 8 (out of 10) or higher. Only 10% rank themselves at the beginner stages with an expertise level of 3 or lower.\n\nThe majority of respondents use Solidity on a weekly (31%) or even daily basis (41%). Almost 18% use it monthly, while the remaining 9% stated that they rarely code in Solidity.\n\nMost respondents are currently using 0.6.x or 0.7.x versions of Solidity. A smaller share still uses 0.5.x versions or has been trying out the recently released 0.8.0 already.\nA few people are not aware of the version they are using or are still using very old versions from the 0.4.x series.\n🚨 Please make sure to frequently update your code since several important bug fixes and security improvements have been added since 0.4.x!\n\nIDEs / Tooling\n50% of respondents stated they are using VSCode as a preferred editor to write Solidity. The second favorite editor was Vim (12.6%), followed by Remix (9.2%), IntelliJ (8.8%) and Atom (7.1%).\n\nWhen asked if they are using an Ethereum-specific development environment, 5% say that they are not using one. Truffle is the most prominent with almost 60%, closely followed by Remix (50.3%) and Hardhat (38.6%).\n\nOverall Solidity Developer Experience\nAround 62% believe that the Solidity developer experience had some or even a lot of improvement in the last year. 15% saw a slight improvement while only 9% thought that there was no change or that the Solidity developer experience got worse.\n\nThe biggest challenge in developer experience for most respondents is the availability and quality of tooling.\nOther aspects seen as critical in fostering language adoption are: Error handling, IDE integrations and better documentation.\nLess often voted for but still relevant are the increasing complexity of the language, availability of generics, improvements in compilation time and debugging as well as improvements in gas cost, storage handling and security.\n\nImportance Ranking of Future Features\nWe've asked the participants of the survey to rank selected features under discussion according to their importance.\nGas optimizations were ranked as most important, followed by interfaces to external debugging tools. The SMTChecker, generics and fixed point types were ranked similarly important.\nExplicitly copying semantics, enums with data, functions at file level and WebAssembly output were evaluated as less critical by the participants.\n\n(4) Most Liked, Dreaded and Anticipated Features\nWe've asked survey participants what they like and dislike most about Solidity and what they would like to see the most in upcoming Solidity versions. Those questions had free-form reply fields so we've summarized the replies and are listing the most mentioned features and aspects below.\nMost Liked Features\nSimplicity and cleanliness has been the number one aspect that the participants value about Solidity.\nFurthermore, the developers appreciated the improvements in available tooling, especially highlighting Remix and Hardhat several times.\nAnother aspect the respondents appreciate is that Solidity is \"easy to learn\" and \"simple to code\".\nSeveral people stated that Solidity is the right tool for what they are working on and that they like the focus on smart contracts and Solidity being a \"special purpose tool\" for it.\nOther features and aspects that have been mentioned repeatedly as cherished and appreciated are:\n\nMappings.\nHuman-readability.\nStructs.\nModifiers.\nStrong-typing.\nJS-likeness.\nAssembly access.\nSafeMath by default.\nGood library support.\nC++-likeness.\nSMTChecker.\nComposability.\nImmutability.\nABI Encoder V2.\nExplicitness.\nInheritance.\nCompact code size.\nSyntax.\nSteady improvement of the language.\n\nMost Dreaded or Disliked Features\nThe currently most dreaded aspect of Solidity is clearly debugging, followed by a lack of Solidity libraries.\nRespondents also complain about inheritance conflicts and the need to write more specific code in assembly / low-level code.\nOther aspects and features that have been mentioned repeatedly as dreaded or disliked are:\n\nError handling.\nMemory management.\nFrequency of breaking changes and dependencies breaking.\nContract & stack size limits.\nInconsistency with other languages.\nABI encoding.\nUnclear gas usage / gas inefficiency.\nTooling.\nComplexity.\nRecompiles failing due to metadata.\nVerbosity.\nDynamic array handling.\nTesting.\n\nMost Anticipated Features\nThe most anticipated feature by far was \"no more SafeMath\". SafeMath by default has been introduced with 0.8.0 and hence is not an issue anymore. 🥳\nThe second most anticipated feature was better debugging and more debugging tools.\nAlso ranked high was better documentation, especially with a focus on more tutorials and code examples.\nOther anticipated and frequently mentioned features were:\n\nGas efficiency optimization features.\nGenerics.\nconsole.log().\nDynamic arrays.\nBetter tooling.\nBetter IDEs.\nLSP support.\nRich revert reasons / error codes.\nStandard library.\nCustom optimization features.\nRelease v1.0.0.\nSMTChecker.\nStable ABIEncoderV2.\nNo more stack too deep.\nDecimals / fixed point types.\nWASM.\n\n(5) Community\nMore than 55% of respondents interact with other Solidity developers on a regular basis, while 27% claim to do so only rarely. Almost 17% do not interact with other Solidity developers at all.\n\nThe majority of respondents feels welcome in the Solidity community and is confident in the work of the Solidity core team.\n71% agree or somewhat agree to feeling welcome to contributing to Solidity.\nOnly 22% fully agree that the Solidity team understands their needs. 14% state that they do not agree and don't feel understood by the Solidity team with regards to their needs.\nThe process of how to contribute to Solidity is clear or somewhat clear to 41% of respondents while 32% do not agree and hence say that the contribution process is unclear to them.\n⚠️ Note that there was a comparatively high share of \"I don't know\" replies to the last three statements.\n\nLanguage Design\nAlmost 85% of respondents state that they have never participated in any Solidity language design related activity. Around two thirds of them say they didn't do so because they don't know how, while one third is simply not interested in it.\n7-8% said that they are part of the language design mailing list, have joined one or more language design discussion calls and/or have proposed features or changes to the language by filing GitHub issues.\n\nStaying Up-To-Date\n57% prefer Twitter to stay up-to-date about things. 21% like mailing lists, 14% prefer Reddit and 6% are in favor of forums.\n\nTo stay in the loop with Solidity updates like new releases, security alerts and announcements, most respondents said they follow Solidity on Twitter, follow the Solidity GitHub release page and/or the Solidity blog. Also mentioned but less popular are the r/ethdev Reddit, the Solidity documentation and the Week in Ethereum newsletter.\nSome of the participants claiming to not do any of the above explained that they mostly get informed by colleagues or friends or simply don't stay up-to-date at all.\n\nTHANK YOU! 💙\nAs a wrap up question we asked participants if there was anything else that they’d like to tell us. We did not expect that amount of good vibes and want to say thank you to each of you! Reading your uplifting and warm comments was pure joy.\nWe will continue our quest to further enhance and shape Solidity and are looking forward to the next survey to check in with you again!\nFeel free to reach out to us via email or chat with us should you have any further questions about details of the survey results.Previous postNext post","tokens":4394,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266249535,"hash":"cb044fc36e90d619760bfa5fe4c3e50882ff1f20"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/35","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 35 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n Load more posts below","tokens":3843,"squid":"ink-research","role":"Deep Scholar","at":1791266249616,"hash":"8d306598ead2ab39690199aac61a02b7e9855062"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/37","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 37 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n Load more posts below","tokens":3700,"squid":"ink-research","role":"Deep Scholar","at":1791266259814,"hash":"15d821b210de80657f4846b0e39fe08bac8af310"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-january-1st-2026/492/3","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations – January 1st, 2026 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2025\n\n 3 / 3\n\n Jan 3\n\n Jan 3\n\n post by KemarTiti on Dec 31, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes, liquidity), and exceptional news (token migration or else) it has been decided to sunset a few feeds.\nPlease note that volumes, liquidity and other metrics are following this framework.\nAll below feeds are scheduled to be sunset on Thursday 1st, January, 2026.\nIf you have any questions, let us know below.\nCRYPTO\n\nCrypto.4/USD\nCrypto.AERGO/USD\nCrypto.ALKIMI/USD\nCrypto.ATLAS/USD\nCrypto.BENJI/USD\nCrypto.BELIEVE/USD\nCrypto.BLZE/USD\nCrypto.BUDDY/USD\nCrypto.BYUSD/USD\nCrypto.COQ/USD\nCrypto.DOGINME/USD\nCrypto.FIDA/USD\nCrypto.FOXY/USD\nCrypto.FRAG/USD\nCrypto.GIGA/USD\nCrypto.GOGLZ/USD\nCrypto.GRAIL/USD\nCrypto.HFUN/USD\nCrypto.LBGT/USD\nCrypto.LOFI/USD\nCrypto.LOOKS/USD\nCrypto.LUCE/USD\nCrypto.LUSD/USD\nCrypto.MANEKI\nCrypto.MBTC/USD\nCrypto.MODE/USD\nCrypto.MYRO/USD\nCrypto.NECT/USD\nCrypto.ODOS/USD\nCrypto.ONE/USD\nCrypto.OS/USD\nCrypto.OUSDT/USD\nCrypto.PERP/USD\nCrypto.SCETH/USD\nCrypto.SCUSD/USD\nCrypto.SENDCOIN.SEND/USD\nCrypto.SKI/USD\nCrypto.SYUSD/USD\nCrypto.TAC/USD\nCrypto.THAPT/USD\nCrypto.THL/USD\nCrypto.TURBOS/USD\nCrypto.URANUS/USD\nCrypto.USDAF/USD\nCrypto.USDB/USD (Blast)\nCrypto.USDU/USD\nCrypto.USH/USD\nCrypto.WFRAGSOL/USD\nCrypto.WOM/USD\n\n Benchmark price for Uranus failing\n\n Deprecation of Pyth Push Feeds - 15th January, 2026\n\n post by KemarTiti on Dec 12, 2025\n\n KemarTiti\n\n It has been decided to keep the following price feeds for the time being:\n\nCrypto.BUCK/USD\nCrypto.METASTABLE.MUSD/USD\nCrypto.MTRG/USD\nCrypto.MAG7-SSI/USD\nCrypto.EBTC/USD\nCrypto.AMI/USD\nCrypto.KBTC/USD\n\n 22 days later\n\n post by KemarTiti on Jan 3\n\n KemarTiti\n\n The changes announced above have now been applied, on January 3rd, 2026.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – May 23, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 689\n\n Jun 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 548\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations – April 15th, 2026\n\n Announcements\n\n announcements\n\n 1\n\n 57\n\n Apr 15\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Powered by Discourse","tokens":1530,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266276049,"hash":"604c416fcccc6a44c6ffce4d69e940ca80d8257b"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-pyth-core-october-30th-2025/436","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2025\n\n 1 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by KemarTiti on Oct 27, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes, liquidity), and exceptional news (token migration or else) it has been decided to sunset a few feeds.\nPlease note that volumes, liquidity and other metrics are following this framework.\nAll below feeds are scheduled to be sunset on Thursday 30th, October, 2025.\nIf you’re using or planning to use these feeds in any capacity, please let us know directly and we’ll be able to reassess the need for their deprecation.\n\nBERAETH/USD\nBERASTONE/ETH.RR\nBERASTONE/USD\nBLUB/USD\nBOBAETH/ETH.RR\nCUSD/USD\nCDCETH/ETH.RR\nEBTC/LBTC.RR\nFRUSDT/USDT.RR\nFUD/USD\nIOT/USD\nLAUNCHCOIN/USD\nLIQUIDBERABTC/WBTC.RR\nLIQUIDBERAETH/ETH.RR\nPXETH/USD\nSHDW/USD\nSLVLUSD/USD.RR\nSLERF/USD\nSTBGT/USD\nSUSDX/USDX.RR\nTETH/USD\nTUSD/USDC.RR\nUSDX/USD\nXUSD/USDC.RR\n\nIf edits were to be applied, they will be visible as a comment to this post.\n\n post by KemarTiti on Oct 15, 2025\n\n KemarTiti\n\nSYUSD/USD was removed from the upcoming deprecation list\n\n post by KemarTiti on Oct 17, 2025\n\n KemarTiti\n\nCDCETH/ETH.RR was added to the list for deprecation\nEBTC/LBTC.RR was added to the list for deprecation\nSHDW/USD was added to the list for deprecation\nTUSD/USDC.RR was added to the list for deprecation\nSLERF/USD was added to the list for deprecation\nLAUNCHCOIN/USD was added to the list for deprecation\n\n 13 days later\n\n post by KemarTiti on Oct 30, 2025\n\n KemarTiti\n\n The above changes have been implemented.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – August 18th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 696\n\n Aug 2025\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 499\n\n Jan 3\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Powered by Discourse","tokens":1490,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266288454,"hash":"e8184cae2fa960d89f94792501a59c242b8a922a"}
{"url":"https://app.aave.com/governance/v3/proposal/?proposalId=525","domain":"app.aave.com","title":"Aave - Onboard PT-AUSD-17DEC2026 to Aave V3 Monad","text":"Go BackProposal overviewOnboard PT-AUSD-17DEC2026 to Aave V3 MonadOpen for votingRaw-IpfsShare on XAuthor@TokenLogicSimple Summary\nThis AIP lists PT-AUSD-17DEC2026, the Pendle Principal Token for AUSD maturing on 17 December 2026, on the Aave V3 Monad instance as a non-borrowable asset, usable as collateral exclusively within a dedicated PT-AUSD-17DEC2026/stablecoin eMode.\nMotivation\nPT-AUSD-8OCT2026 matures on 8th of October 2026. This AIP lists the next maturity, PT-AUSD-17DEC2026, with the launch parameters recommended by LlamaRisk, so that users can roll fixed-yield AUSD positions used as collateral against stablecoin debt into the new maturity. PT-AUSD-8OCT2026 remains listed through its maturity, unchanged.\nThe PT is priced by a new linear discount oracle for the 17 December 2026 maturity (PT Capped AUSD AUSD/USD linear discount 17DEC2026), with initialDiscountRatePerYear 5.745% and maxDiscountRatePerYear 8.804%.\nSpecification\nFieldValueAssetPT-AUSD-17DEC2026PT token0x8B562578b2f9Aa8C14cCda3c5d6CBCEaD3B06a57Pendle market0x9cbc42eff240ad2e43bbdc3c0562a9b4ce842a5aSY token0xE99f124109752f8e62B4fd5c7E3C01C1BBF58B24YT token0x211EDf350b927C6EAE808a63D5f6318Bac5A7e5eUnderlying (AUSD)0x00000000eFE302BEAA2b3e6e1b18d08D69a9012aMaturity17 December 2026\nNew eMode:\neModeCollateralBorrowableLTVLTLiq. BonusIsolatedPT_AUSD_17DEC2026__StablecoinsPT-AUSD-17DEC2026USDT0, USDC, GHO, USDe, mUSD93%95%2.62%No\nThe table below illustrates the configured risk parameters for PT_AUSD_17DEC2026\nParameterPT-AUSD-17DEC2026Isolation ModeNoBorrowableNoCollateral EnabledNo (E-Mode only)Supply Cap30,000,000Borrow Cap1Debt CeilingN/ALTV0%Liquidation Threshold0%Liquidation Bonus0%Liquidation Protocol Fee10%Reserve Factor20%Base Variable Borrow Rate0%Variable Rate Slope 110%Variable Rate Slope 2300%Optimal Utilization45%FlashloanableYesOracle0x4dc9Ee8d739411242303f7F78C6610d5B0371a2C\nLinear Discount Rate Oracle\nParameterValueinitialDiscountRatePerYear5.745%maxDiscountRatePerYear8.804%Oracle0x4dc9Ee8d739411242303f7F78C6610d5B0371a2C\nReferences\n\nImplementation: AaveV3Monad\nTests: AaveV3Monad\nSnapshot\nDiscussion\n\nCopyright\nCopyright and related rights waived via CC0.Your voting infoVoting is onVoting resultsYAE172KAAVE100.00%NAY<1AAVE<0.01%Top 10 addressesVotes0x3320756...bb7YAE107.2Kwintermutego...ethYAE53,7080xb6647ca...436YAE10,7610x7fd5127...aafYAE169.390x2b7e7b1...5ecYAE145.000xa1a1848...74aYAE19.59manmanwuxian...ethYAE0.35880htjit.ethYAE0.17830xteaser.ethYAE0.1200avshek01.ethNAY0.1100StateOpen for votingQuorumNot reachedCurrent votesRequired172.04K320.00KDifferentialReachedCurrent differentialRequired172.04K80,000.00Forum discussionPayloadsPayload 8MonadcreatedAccess levelMinor (Level 1)Creator0x3765...3a91Controller0x442c...9a82Target0xb56d...87dfSeatbelt reportTimelineCreatedOct 3, 2026 6:26 AMOpen for votingOct 4, 2026 6:26 AMVoting closesin 1d 5hQueued~Oct 7, 2026 6:30 AMExecuted~Oct 7, 2026 6:30 AMPayloads queued~Oct 7, 2026 6:30 AMPayloads executed1 payload","tokens":747,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266298935,"hash":"ff86adb01d4ea7f9ee97c0465f1c4f7421006606"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-pyth-core-october-30th-2025/436/4","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2025\n\n 4 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by KemarTiti on Oct 27, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes, liquidity), and exceptional news (token migration or else) it has been decided to sunset a few feeds.\nPlease note that volumes, liquidity and other metrics are following this framework.\nAll below feeds are scheduled to be sunset on Thursday 30th, October, 2025.\nIf you’re using or planning to use these feeds in any capacity, please let us know directly and we’ll be able to reassess the need for their deprecation.\n\nBERAETH/USD\nBERASTONE/ETH.RR\nBERASTONE/USD\nBLUB/USD\nBOBAETH/ETH.RR\nCUSD/USD\nCDCETH/ETH.RR\nEBTC/LBTC.RR\nFRUSDT/USDT.RR\nFUD/USD\nIOT/USD\nLAUNCHCOIN/USD\nLIQUIDBERABTC/WBTC.RR\nLIQUIDBERAETH/ETH.RR\nPXETH/USD\nSHDW/USD\nSLVLUSD/USD.RR\nSLERF/USD\nSTBGT/USD\nSUSDX/USDX.RR\nTETH/USD\nTUSD/USDC.RR\nUSDX/USD\nXUSD/USDC.RR\n\nIf edits were to be applied, they will be visible as a comment to this post.\n\n post by KemarTiti on Oct 15, 2025\n\n KemarTiti\n\nSYUSD/USD was removed from the upcoming deprecation list\n\n post by KemarTiti on Oct 17, 2025\n\n KemarTiti\n\nCDCETH/ETH.RR was added to the list for deprecation\nEBTC/LBTC.RR was added to the list for deprecation\nSHDW/USD was added to the list for deprecation\nTUSD/USDC.RR was added to the list for deprecation\nSLERF/USD was added to the list for deprecation\nLAUNCHCOIN/USD was added to the list for deprecation\n\n 13 days later\n\n post by KemarTiti on Oct 30, 2025\n\n KemarTiti\n\n The above changes have been implemented.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – August 18th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 696\n\n Aug 2025\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 499\n\n Jan 3\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Powered by Discourse","tokens":1472,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266307949,"hash":"ca3d33b350bf7733b371f277ee19f175d7be6101"}
{"url":"https://governance.aave.com/t/direct-to-aip-onboard-pt-ausd-17dec2026-to-aave-v3-monad-instance/25701","domain":"governance.aave.com","title":"[Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance - Governance / New Asset - Aave","text":"[Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance \n\n GovernanceNew Asset\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 25\n\n 1 / 2\n\n Sep 25\n\n 4d ago\n\n post by TokenLogic on Sep 25\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\nauthor: @TokenLogic\ncreated: 2026-09-25\n\nSummary\nThis proposal lists PT-AUSD-17DEC2026 on Aave V3 Monad ahead of the existing PT-AUSD maturity on 8 October 2026. The December PT would launch with the same risk parameters used for the October listing, with borrowing disabled and collateral use limited to a dedicated stablecoin eMode.\nMotivation\nPT-AUSD-8OCT2026 matures on 8 October 2026. Pendle has deployed the next AUSD market with a maturity of 17 December 2026, and this listing would allow users to roll into the December PT and continue using their positions as collateral on Aave V3 Monad.\nThe October PT was listed through AIP 513, following the ARFC and a Snapshot vote with 99.99% support. As of 25 September 2026, approximately 63.9M PT-AUSD-8OCT2026 is supplied against an 80M supply cap.\nThe December PT uses the same underlying asset, Pendle market factory and pricing approach. This proposal follows the Direct-to-AIP process for the next maturity, using the October listing’s launch parameters, including an initial supply cap of 20M.\nSpecification\n\nField\nValue\n\nAsset\nPT-AUSD-17DEC2026\n\nPT token\n0x8B562578b2f9Aa8C14cCda3c5d6CBCEaD3B06a57\n\nPendle market\n0x9cbc42eff240ad2e43bbdc3c0562a9b4ce842a5a\n\nSY token\n0xE99f124109752f8e62B4fd5c7E3C01C1BBF58B24\n\nYT token\n0x211EDf350b927C6EAE808a63D5f6318Bac5A7e5e\n\nUnderlying (AUSD)\n0x00000000eFE302BEAA2b3e6e1b18d08D69a9012a\n\nDecimals\n6\n\nMaturity\n17 December 2026\n\neMode\nA dedicated eMode will allow users to supply PT-AUSD-17DEC2026 as collateral and borrow USDT0, USDC, GHO or USDe. Its parameters and borrowable assets match the PT_Agora__Stablecoins eMode created for the October PT.\n\neMode ID\neMode\nCollateral\nBorrowable\nLTV\nLT\nLiq. Bonus\nIsolated\n\n6\nPT_AUSD_17DEC2026__Stablecoins\nPT-AUSD-17DEC2026\nUSDT0, USDC, GHO, USDe\n93%\n95%\n2.44%\nYes\n\nReserve Parameters\nThe proposed reserve configuration matches the October PT’s launch parameters in AIP 513.\n\nParameter\nPT-AUSD-17DEC2026\n\nIsolation Mode\nNo\n\nBorrowable\nNo\n\nCollateral Enabled\nNo (eMode only)\n\nSupply Cap\n20,000,000\n\nBorrow Cap\n1\n\nDebt Ceiling\nN/A\n\nLTV\n0%\n\nLiquidation Threshold\n0%\n\nLiquidation Bonus\n0%\n\nLiquidation Protocol Fee\n10%\n\nReserve Factor\n20%\n\nBase Variable Borrow Rate\n0%\n\nVariable Rate Slope 1\n10%\n\nVariable Rate Slope 2\n300%\n\nOptimal Utilization\n45%\n\nFlashloanable\nYes\n\nOracle\nPT Capped AUSD AUSD/USD linear discount 17DEC2026 (address to be added once deployed)\n\nOracle\nA new linear discount oracle will be deployed for the 17 December 2026 maturity, using the same pricing method and discount rate parameters as the October PT. Each oracle instance has a fixed maturity date, so the December PT requires its own deployment.\n\nParameter\nValue\n\ninitialDiscountRatePerYear\n6.661%\n\nmaxDiscountRatePerYear\n8.829%\n\nOracle\nTo be added once deployed\n\nThe October PT will remain listed through maturity with its existing configuration.\nDisclaimer\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nEscalate this proposal directly to the AIP stage.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n read \n\n 5\n min\n\n post by LlamaRisk 4 days ago\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance\n\n Governance\n\n 5\n\n 598\n\n Aug 7\n\n [Direct to AIP] Onboard PT-USDe-22OCT2026 to Aave V3 Monad\n\n Governance\n\n 2\n\n 242\n\n Sep 4\n\n [Direct-to-AIP] PT-USDG X Layer\n\n Governance\n\n 2\n\n 304\n\n Aug 19\n\n [Direct-to-AIP] Onboard PT-USDG-24SEP2026 to Aave V4 on Ethereum\n\n New Asset\n\n 7\n\n 1.0k\n\n Jul 16\n\n [Direct to AIP] Onboard Strata srUSDe-22OCT2026 PT tokens to V3 Core Instance\n\n New Asset\n\n 2\n\n 283\n\n Jun 16","tokens":1098,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266309478,"hash":"c3ed03a31b81d38659a3d4682b7228cb1c5e0662"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/governance","domain":"docs.openzeppelin.com","title":"How to set up on-chain governance | OpenZeppelin Docs","text":"OpenZeppelin ContractsHow to set up on-chain governanceOpen in ClaudeIn this guide we will learn how OpenZeppelin’s Governor contract works, how to set it up, and how to use it to create proposals, vote for them, and execute them, using tools provided by Ethers.js and Tally.\nFind detailed contract documentation at Governance API.\nIntroduction\nDecentralized protocols are in constant evolution from the moment they are publicly released. Often, the initial team retains control of this evolution in the first stages, but eventually delegates it to a community of stakeholders. The process by which this community makes decisions is called on-chain governance, and it has become a central component of decentralized protocols, fueling varied decisions such as parameter tweaking, smart contract upgrades, integrations with other protocols, treasury management, grants, etc.\nThis governance protocol is generally implemented in a special-purpose contract called “Governor”. The GovernorAlpha and GovernorBravo contracts designed by Compound have been very successful and popular so far, with the downside that projects with different requirements have had to fork the code to customize it for their needs, which can pose a high risk of introducing security issues. For OpenZeppelin Contracts, we set out to build a modular system of Governor contracts so that forking is not needed, and different requirements can be accommodated by writing small modules using Solidity inheritance. You will find the most common requirements out of the box in OpenZeppelin Contracts, but writing additional ones is simple, and we will be adding new features as requested by the community in future releases. Additionally, the design of OpenZeppelin Governor requires minimal use of storage and results in more gas efficient operation.\nCompatibility\nOpenZeppelin’s Governor system was designed with a concern for compatibility with existing systems that were based on Compound’s GovernorAlpha and GovernorBravo. Because of this, you will find that many modules are presented in two variants, one of which is built for compatibility with those systems.\nERC20Votes & ERC20VotesComp\nThe ERC-20 extension to keep track of votes and vote delegation is one such case. The shorter one is the more generic version because it can support token supplies greater than 2^96, while the “Comp” variant is limited in that regard, but exactly fits the interface of the COMP token that is used by GovernorAlpha and Bravo. Both contract variants share the same events, so they are fully compatible when looking at events only.\nGovernor & GovernorStorage\nAn OpenZeppelin Governor contract is not interface-compatible with Compound’s GovernorAlpha or Bravo. Even though events are fully compatible, proposal lifecycle functions (creation, execution, etc.) have different signatures that are meant to optimize storage use. Other functions from GovernorAlpha and Bravo are likewise not available. It’s possible to opt in some Bravo-like behavior by inheriting from the GovernorStorage module. This module provides proposal enumerability and alternate versions of the queue, execute and cancel function that only take the proposal id. This module reduces the calldata needed by some operations in exchange for an increased storage footprint. This might be a good trade-off for some L2 chains. It also provides primitives for indexer-free frontends.\nNote that even with the use of this module, one important difference with Compound’s GovernorBravo is the way that proposalIds are calculated. Governor uses the hash of the proposal parameters with the purpose of keeping its data off-chain by event indexing, while the original Bravo implementation uses sequential proposalIds.\nGovernorTimelockControl & GovernorTimelockCompound\nWhen using a timelock with your Governor contract, you can use either OpenZeppelin’s TimelockController or Compound’s Timelock. Based on the choice of timelock, you should choose the corresponding Governor module: GovernorTimelockControl or GovernorTimelockCompound respectively. This allows you to migrate an existing GovernorAlpha instance to an OpenZeppelin-based Governor without changing the timelock in use.\nTally\nTally is a full-fledged application for user owned on-chain governance. It comprises a voting dashboard, proposal creation wizard, real time research and analysis, and educational content.\nFor all of these options, the Governor will be compatible with Tally: users will be able to create proposals, see voting periods and delays following IERC6372, visualize voting power and advocates, navigate proposals, and cast votes.\nIn the rest of this guide, we will focus on a fresh deploy of the vanilla OpenZeppelin Governor features without concern for compatibility with GovernorAlpha or Bravo.\nSetup\nToken\nThe voting power of each account in our governance setup will be determined by an ERC-20 token. The token has to implement the ERC20Votes extension. This extension will keep track of historical balances so that voting power is retrieved from past snapshots rather than current balance, which is an important protection that prevents double voting.\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport {ERC20Permit} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol\";\nimport {ERC20Votes} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol\";\nimport {Nonces} from \"@openzeppelin/contracts/utils/Nonces.sol\";\n\ncontract MyToken is ERC20, ERC20Permit, ERC20Votes {\n constructor() ERC20(\"MyToken\", \"MTK\") ERC20Permit(\"MyToken\") {}\n\n // The functions below are overrides required by Solidity.\n\n function _update(address from, address to, uint256 amount) internal override(ERC20, ERC20Votes) {\n super._update(from, to, amount);\n }\n\n function nonces(address owner) public view virtual override(ERC20Permit, Nonces) returns (uint256) {\n return super.nonces(owner);\n }\n}\nIf your project already has a live token that does not include ERC20Votes and is not upgradeable, you can wrap it in a governance token by using ERC20Wrapper. This will allow token holders to participate in governance by wrapping their tokens 1-to-1.\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n\nimport {IERC20, ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport {ERC20Permit} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol\";\nimport {ERC20Votes} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol\";\nimport {ERC20Wrapper} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Wrapper.sol\";\nimport {Nonces} from \"@openzeppelin/contracts/utils/Nonces.sol\";\n\ncontract MyTokenWrapped is ERC20, ERC20Permit, ERC20Votes, ERC20Wrapper {\n constructor(\n IERC20 wrappedToken\n ) ERC20(\"MyTokenWrapped\", \"MTK\") ERC20Permit(\"MyTokenWrapped\") ERC20Wrapper(wrappedToken) {}\n\n // The functions below are overrides required by Solidity.\n\n function decimals() public view override(ERC20, ERC20Wrapper) returns (uint8) {\n return super.decimals();\n }\n\n function _update(address from, address to, uint256 amount) internal override(ERC20, ERC20Votes) {\n super._update(from, to, amount);\n }\n\n function nonces(address owner) public view virtual override(ERC20Permit, Nonces) returns (uint256) {\n return super.nonces(owner);\n }\n}\nThe only other source of voting power available in OpenZeppelin Contracts currently is ERC721Votes. ERC-721 tokens that don’t provide this functionality can be wrapped into a voting tokens using a combination of ERC721Votes and ERC721Wrapper.\nThe internal clock used by the token to store voting balances will dictate the operating mode of the Governor contract attached to it. By default, block numbers are used. Since v4.9, developers can override the IERC6372 clock to use timestamps instead of block numbers.\nGovernor\nInitially, we will build a Governor without a timelock. The core logic is given by the Governor contract, but we still need to choose: 1) how voting power is determined, 2) how many votes are needed for quorum, 3) what options people have when casting a vote and how those votes are counted, and 4) what type of token should be used to vote. Each of these aspects is customizable by writing your own module, or more easily choosing one from OpenZeppelin Contracts.\nFor 1) we will use the GovernorVotes module, which hooks to an IVotes instance to determine the voting power of an account based on the token balance they hold when a proposal becomes active. This module requires as a constructor parameter the address of the token. This module also discovers the clock mode (ERC-6372) used by the token and applies it to the Governor.\nFor 2) we will use GovernorVotesQuorumFraction which works together with ERC20Votes to define quorum as a percentage of the total supply at the block a proposal’s voting power is retrieved. This requires a constructor parameter to set the percentage. Most Governors nowadays use 4%, so we will initialize the module with parameter 4 (this indicates the percentage, resulting in 4%).\nFor 3) we will use GovernorCountingSimple, a module that offers 3 options to voters: For, Against, and Abstain, and where only For and Abstain votes are counted towards quorum.\nBesides these modules, Governor itself has some parameters we must set.\nvotingDelay: How long after a proposal is created should voting power be fixed. A large voting delay gives users time to unstake tokens if necessary.\nvotingPeriod: How long does a proposal remain open to votes.\nThese parameters are specified in the unit defined in the token’s clock. Assuming the token uses block numbers, and assuming block time of around 12 seconds, we will have set votingDelay = 1 day = 7200 blocks, and votingPeriod = 1 week = 50400 blocks.\nWe can optionally set a proposal threshold as well. This restricts proposal creation to accounts that have enough voting power.\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n\nimport {Governor} from \"@openzeppelin/contracts/governance/Governor.sol\";\nimport {GovernorCountingSimple} from \"@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol\";\nimport {GovernorVotes} from \"@openzeppelin/contracts/governance/extensions/GovernorVotes.sol\";\nimport {GovernorVotesQuorumFraction} from \"@openzeppelin/contracts/governance/extensions/GovernorVotesQuorumFraction.sol\";\nimport {GovernorTimelockControl} from \"@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol\";\nimport {TimelockController} from \"@openzeppelin/contracts/governance/TimelockController.sol\";\nimport {IVotes} from \"@openzeppelin/contracts/governance/utils/IVotes.sol\";\n\ncontract MyGovernor is\n Governor,\n GovernorCountingSimple,\n GovernorVotes,\n GovernorVotesQuorumFraction,\n GovernorTimelockControl\n{\n constructor(\n IVotes _token,\n TimelockController _timelock\n ) Governor(\"MyGovernor\") GovernorVotes(_token) GovernorVotesQuorumFraction(4) GovernorTimelockControl(_timelock) {}\n\n function votingDelay() public pure override returns (uint256) {\n return 7200; // 1 day\n }\n\n function votingPeriod() public pure override returns (uint256) {\n return 50400; // 1 week\n }\n\n function proposalThreshold() public pure override returns (uint256) {\n return 0;\n }\n\n // The functions below are overrides required by Solidity.\n\n function state(uint256 proposalId) public view override(Governor, GovernorTimelockControl) returns (ProposalState) {\n return super.state(proposalId);\n }\n\n function proposalNeedsQueuing(\n uint256 proposalId\n ) public view virtual override(Governor, GovernorTimelockControl) returns (bool) {\n return super.proposalNeedsQueuing(proposalId);\n }\n\n function _queueOperations(\n uint256 proposalId,\n address[] memory targets,\n uint256[] memory values,\n bytes[] memory calldatas,\n bytes32 descriptionHash\n ) internal override(Governor, GovernorTimelockControl) returns (uint48) {\n return super._queueOperations(proposalId, targets, values, calldatas, descriptionHash);\n }\n\n function _executeOperations(\n uint256 proposalId,\n address[] memory targets,\n uint256[] memory values,\n bytes[] memory calldatas,\n bytes32 descriptionHash\n ) internal override(Governor, GovernorTimelockControl) {\n super._executeOperations(proposalId, targets, values, calldatas, descriptionHash);\n }\n\n function _cancel(\n address[] memory targets,\n uint256[] memory values,\n bytes[] memory calldatas,\n bytes32 descriptionHash\n ) internal override(Governor, GovernorTimelockControl) returns (uint256) {\n return super._cancel(targets, values, calldatas, descriptionHash);\n }\n\n function _executor() internal view override(Governor, GovernorTimelockControl) returns (address) {\n return super._executor();\n }\n}\nTimelock\nIt is good practice to add a timelock to governance decisions. This allows users to exit the system if they disagree with a decision before it is executed. We will use OpenZeppelin’s TimelockController in combination with the GovernorTimelockControl module.\nWhen using a timelock, it is the timelock that will execute proposals and thus the timelock that should hold any funds, ownership, and access control roles. Before version 4.5 there was no way to recover funds in the Governor contract when using a timelock! Before version 4.3, when using the Compound Timelock, ETH in the timelock was not easily accessible.\nTimelockController uses an AccessControl setup that we need to understand in order to set up roles.\n\nThe Proposer role is in charge of queueing operations: this is the role the Governor instance should be granted, and it should likely be the only proposer in the system.\nThe Executor role is in charge of executing already available operations: we can assign this role to the special zero address to allow anyone to execute (if operations can be particularly time sensitive, the Governor should be made Executor instead).\nThe Canceller role can cancel queued operations in the timelock: the Governor should hold this role for proposal cancellations to work after queuing. If the Governor is set as a proposer at deployment, it will automatically receive the Canceller role as well.\nLastly, there is the Admin role, which can grant and revoke the two previous roles: this is a very sensitive role that will be granted automatically to the timelock itself, and optionally to a second account, which can be used for ease of setup but should promptly renounce the role.\n\nGranting additional proposers or cancellers besides the Governor is risky. They can execute operations as the timelock (bypassing governance) and cancel approved proposals, potentially causing a denial of service attack against governance.\nProposal Lifecycle\nLet’s walk through how to create and execute a proposal on our newly deployed Governor.\nA proposal is a sequence of actions that the Governor contract will perform if it passes. Each action consists of a target address, calldata encoding a function call, and an amount of ETH to include. Additionally, a proposal includes a human-readable description.\nCreate a Proposal\nLet’s say we want to create a proposal to give a team a grant, in the form of ERC-20 tokens from the governance treasury. This proposal will consist of a single action where the target is the ERC-20 token, calldata is the encoded function call transfer(<team wallet>, <grant amount>), and with 0 ETH attached.\nGenerally a proposal will be created with the help of an interface such as Tally. Here we will show how to create the proposal using Ethers.js.\nFirst we get all the parameters necessary for the proposal action.\nconst tokenAddress = ...;\nconst token = await ethers.getContractAt(‘ERC20’, tokenAddress);\n\nconst teamAddress = ...;\nconst grantAmount = ...;\nconst transferCalldata = token.interface.encodeFunctionData(‘transfer’, [teamAddress, grantAmount]);\nNow we are ready to call the propose function of the Governor. Note that we don’t pass in one array of actions, but instead three arrays corresponding to the list of targets, the list of values, and the list of calldatas. In this case it’s a single action, so it’s simple:\nawait governor.propose(\n [tokenAddress],\n [0],\n [transferCalldata],\n “Proposal #1: Give grant to team”,\n);\nThis will create a new proposal, with a proposal id that is obtained by hashing together the proposal data, and which will also be found in an event in the logs of the transaction.\nCast a Vote\nOnce a proposal is active, delegates can cast their vote. Note that it is delegates who carry voting power: if a token holder wants to participate, they can set a trusted representative as their delegate, or they can become a delegate themselves by self-delegating their voting power.\nVotes are cast by interacting with the Governor contract through the castVote family of functions. Voters would generally invoke this from a governance UI such as Tally.\n\nExecute the Proposal\nOnce the voting period is over, if quorum was reached (enough voting power participated) and the majority voted in favor, the proposal is considered successful and can proceed to be executed. Once a proposal passes, it can be queued and executed from the same place you voted.\n\nWe will see now how to do this manually using Ethers.js.\nIf a timelock was set up, the first step to execution is queueing. You will notice that both the queue and execute functions require passing in the entire proposal parameters, as opposed to just the proposal id. This is necessary because this data is not stored on chain, as a measure to save gas. Note that these parameters can always be found in the events emitted by the contract. The only parameter that is not sent in its entirety is the description, since this is only needed in its hashed form to compute the proposal id.\nTo queue, we call the queue function:\nconst descriptionHash = ethers.utils.id(“Proposal #1: Give grant to team”);\n\nawait governor.queue(\n [tokenAddress],\n [0],\n [transferCalldata],\n descriptionHash,\n);\nThis will cause the Governor to interact with the timelock contract and queue the actions for execution after the required delay.\nAfter enough time has passed (according to the timelock parameters), the proposal can be executed. If there was no timelock to begin with, this step can be run immediately after the proposal succeeds.\nawait governor.execute(\n [tokenAddress],\n [0],\n [transferCalldata],\n descriptionHash,\n);\nExecuting the proposal will transfer the ERC-20 tokens to the chosen recipient. To wrap up: we set up a system where a treasury is controlled by the collective decision of the token holders of a project, and all actions are executed via proposals enforced by on-chain votes.\nTimestamp based governance\nMotivation\nIt is sometimes difficult to deal with durations expressed in number of blocks because of inconsistent or unpredictable time between blocks. This is particularly true of some L2 networks where blocks are produced based on blockchain usage. Using number of blocks can also lead to the governance rules being affected by network upgrades that modify the expected time between blocks.\nThe difficulty of replacing block numbers with timestamps is that the Governor and the token must both use the same format when querying past votes. If a token is designed around block numbers, it is not possible for a Governor to reliably do timestamp based lookups.\nTherefore, designing a timestamp based voting system starts with the token.\nToken\nSince v4.9, all voting contracts (including ERC20Votes and ERC721Votes) rely on IERC6372 for clock management. In order to change from operating with block numbers to operating with timestamps, all that is required is to override the clock() and CLOCK_MODE() functions.\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport {ERC20Permit} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol\";\nimport {ERC20Votes} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol\";\nimport {Nonces} from \"@openzeppelin/contracts/utils/Nonces.sol\";\n\ncontract MyTokenTimestampBased is ERC20, ERC20Permit, ERC20Votes {\n constructor() ERC20(\"MyTokenTimestampBased\", \"MTK\") ERC20Permit(\"MyTokenTimestampBased\") {}\n\n // Overrides IERC6372 functions to make the token & governor timestamp-based\n\n function clock() public view override returns (uint48) {\n return uint48(block.timestamp);\n }\n\n // solhint-disable-next-line func-name-mixedcase\n function CLOCK_MODE() public pure override returns (string memory) {\n return \"mode=timestamp\";\n }\n\n // The functions below are overrides required by Solidity.\n\n function _update(address from, address to, uint256 amount) internal override(ERC20, ERC20Votes) {\n super._update(from, to, amount);\n }\n\n function nonces(address owner) public view virtual override(ERC20Permit, Nonces) returns (uint256) {\n return super.nonces(owner);\n }\n}\nGovernor\nThe Governor will automatically detect the clock mode used by the token and adapt to it. There is no need to override anything in the Governor contract. However, the clock mode does affect how some values are interpreted. It is therefore necessary to set the votingDelay() and votingPeriod() accordingly.\npragma solidity ^0.8.20;\n\nimport {Governor} from \"@openzeppelin/contracts/governance/Governor.sol\";\nimport {GovernorCountingSimple} from \"@openzeppelin/contracts/governance/extensions/GovernorCountingSimple.sol\";\nimport {GovernorVotes} from \"@openzeppelin/contracts/governance/extensions/GovernorVotes.sol\";\nimport {GovernorVotesQuorumFraction} from \"@openzeppelin/contracts/governance/extensions/GovernorVotesQuorumFraction.sol\";\nimport {GovernorTimelockControl} from \"@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol\";\nimport {TimelockController} from \"@openzeppelin/contracts/governance/TimelockController.sol\";\nimport {IVotes} from \"@openzeppelin/contracts/governance/utils/IVotes.sol\";\n\ncontract MyGovernor is Governor, GovernorCountingSimple, GovernorVotes, GovernorVotesQuorumFraction, GovernorTimelockControl {\n constructor(IVotes _token, TimelockController _timelock)\n Governor(\"MyGovernor\")\n GovernorVotes(_token)\n GovernorVotesQuorumFraction(4)\n GovernorTimelockControl(_timelock)\n {}\n\n function votingDelay() public pure virtual override returns (uint256) {\n return 1 days;\n }\n\n function votingPeriod() public pure virtual override returns (uint256) {\n return 1 weeks;\n }\n\n function proposalThreshold() public pure virtual override returns (uint256) {\n return 0;\n }\n\n // ...\n}\nDisclaimer\nTimestamp based voting is a recent feature that was formalized in ERC-6372 and ERC-5805, and introduced in v4.9. At the time this feature is released, some governance tooling may not support it yet. Users can expect invalid reporting of deadlines & durations if the tool is not able to interpret the ERC6372 clock. This invalid reporting by offchain tools does not affect the onchain security and functionality of the governance contract.\nGovernors with timestamp support (v4.9 and above) are compatible with old tokens (before v4.9) and will operate in \"block number\" mode (which is the mode all old tokens operate on). On the other hand, old Governor instances (before v4.9) are not compatible with new tokens operating using timestamps. If you update your token code to use timestamps, make sure to also update your Governor code.ERC-6909Previous PageUtilitiesNext PageOn this pageIntroductionCompatibilityERC20Votes & ERC20VotesCompGovernor & GovernorStorageGovernorTimelockControl & GovernorTimelockCompoundTallySetupTokenGovernorTimelockProposal LifecycleCreate a ProposalCast a VoteExecute the ProposalTimestamp based governanceMotivationTokenGovernorDisclaimer","tokens":5911,"squid":"ink-security_audits","role":"Sentinel","at":1791266318018,"hash":"7abb1fdd517e55ed2130c923e0207f0797b43070"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-pyth-core-august-18th-2025/341/4","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations (Pyth Core) – August 18th, 2025 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 2025\n\n 4 / 4\n\n Aug 2025\n\n Aug 2025\n\n post by KemarTiti on Aug 18, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes/liquidity), and/or exceptional news (token migration or protocol sunsetting) it has been decided to sunset a few feeds.\nAll below feeds are scheduled to be deprecated on Monday 18th, August, 2025.\nIf you’re using or planning to use these feeds in any capacity, please let us know directly and we’ll be able to reassess the need for their deprecation.\n\nABSTER/USD\n\nAMPL/USD\n\nASF/USD\n\nBIFI/USD\n\nCDXUSD/USD\n\nHENLO/USD (currently Sponsored)\n\nLOUD/USD\n\nLVN/USD\n\nMTR/USD\n\nNOOT/USD\n\nPUFETH/USD (currently Sponsored)\n\nSPOT/USD\n\nUSDA/USD (Avalon) (currently Sponsored). Delayed until Wednesday 20th, August.\n\nVADER/USD\n\nWAMPL/USD\n\nXUSDC/USDC.RR\n\nZERO/USD\n\nThanks a lot for your support to the network.\n\n post by KemarTiti on Aug 12, 2025\n\n KemarTiti\n\n On August 12th, 2025, LOUD was added to the above list for deprecation.\n\n post by KemarTiti on Aug 17, 2025\n\n KemarTiti\n\n After discussion with some Pyth users, the USDA/USD (Avalon) deprecation will be delayed and is now scheduled for Wednesday 20th August, 2025.\n\n post by KemarTiti on Aug 19, 2025\n\n KemarTiti\n\n As scheduled, all the below feeds have now been deprecated:\n\nABSTER/USD\nAMPL/USD\nASF/USD\nBIFI/USD\nCDXUSD/USD\nHENLO/USD\nLOUD/USD\nLVN/USD\nMTR/USD\nNOOT/USD\nPUFETH/USD\nSPOT/USD\nVADER/USD\nWAMPL/USD\nXUSDC/USDC.RR\nZERO/USD\n\nAs a reminder, USDA/USD (Avalon) (currently Sponsored) deprecation was delayed to Wednesday 20th.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 588\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 549\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Deprecation of DEUSD/USD and SDEUSD/DEUSD.RR feeds on Pyth - 9th November, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 312\n\n Nov 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Powered by Discourse","tokens":1482,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266319047,"hash":"2e453b0a24d1e5f4aba4bafbb2cff54754180855"}
{"url":"https://governance.aave.com/t/direct-to-aip-onboard-pt-ausd-17dec2026-to-aave-v3-monad-instance/25701/2","domain":"governance.aave.com","title":"[Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance - Governance / New Asset - Aave","text":"GovernanceNew Asset\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 25\n\n 2 / 2\n\n Oct 2\n\n 4d ago\n\n post by TokenLogic on Sep 25\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\nauthor: @TokenLogic\ncreated: 2026-09-25\n\nSummary\nThis proposal lists PT-AUSD-17DEC2026 on Aave V3 Monad ahead of the existing PT-AUSD maturity on 8 October 2026. The December PT would launch with the same risk parameters used for the October listing, with borrowing disabled and collateral use limited to a dedicated stablecoin eMode.\nMotivation\nPT-AUSD-8OCT2026 matures on 8 October 2026. Pendle has deployed the next AUSD market with a maturity of 17 December 2026, and this listing would allow users to roll into the December PT and continue using their positions as collateral on Aave V3 Monad.\nThe October PT was listed through AIP 513, following the ARFC and a Snapshot vote with 99.99% support. As of 25 September 2026, approximately 63.9M PT-AUSD-8OCT2026 is supplied against an 80M supply cap.\nThe December PT uses the same underlying asset, Pendle market factory and pricing approach. This proposal follows the Direct-to-AIP process for the next maturity, using the October listing’s launch parameters, including an initial supply cap of 20M.\nSpecification\n\nField\nValue\n\nAsset\nPT-AUSD-17DEC2026\n\nPT token\n0x8B562578b2f9Aa8C14cCda3c5d6CBCEaD3B06a57\n\nPendle market\n0x9cbc42eff240ad2e43bbdc3c0562a9b4ce842a5a\n\nSY token\n0xE99f124109752f8e62B4fd5c7E3C01C1BBF58B24\n\nYT token\n0x211EDf350b927C6EAE808a63D5f6318Bac5A7e5e\n\nUnderlying (AUSD)\n0x00000000eFE302BEAA2b3e6e1b18d08D69a9012a\n\nDecimals\n6\n\nMaturity\n17 December 2026\n\neMode\nA dedicated eMode will allow users to supply PT-AUSD-17DEC2026 as collateral and borrow USDT0, USDC, GHO or USDe. Its parameters and borrowable assets match the PT_Agora__Stablecoins eMode created for the October PT.\n\neMode ID\neMode\nCollateral\nBorrowable\nLTV\nLT\nLiq. Bonus\nIsolated\n\n6\nPT_AUSD_17DEC2026__Stablecoins\nPT-AUSD-17DEC2026\nUSDT0, USDC, GHO, USDe\n93%\n95%\n2.44%\nYes\n\nReserve Parameters\nThe proposed reserve configuration matches the October PT’s launch parameters in AIP 513.\n\nParameter\nPT-AUSD-17DEC2026\n\nIsolation Mode\nNo\n\nBorrowable\nNo\n\nCollateral Enabled\nNo (eMode only)\n\nSupply Cap\n20,000,000\n\nBorrow Cap\n1\n\nDebt Ceiling\nN/A\n\nLTV\n0%\n\nLiquidation Threshold\n0%\n\nLiquidation Bonus\n0%\n\nLiquidation Protocol Fee\n10%\n\nReserve Factor\n20%\n\nBase Variable Borrow Rate\n0%\n\nVariable Rate Slope 1\n10%\n\nVariable Rate Slope 2\n300%\n\nOptimal Utilization\n45%\n\nFlashloanable\nYes\n\nOracle\nPT Capped AUSD AUSD/USD linear discount 17DEC2026 (address to be added once deployed)\n\nOracle\nA new linear discount oracle will be deployed for the 17 December 2026 maturity, using the same pricing method and discount rate parameters as the October PT. Each oracle instance has a fixed maturity date, so the December PT requires its own deployment.\n\nParameter\nValue\n\ninitialDiscountRatePerYear\n6.661%\n\nmaxDiscountRatePerYear\n8.829%\n\nOracle\nTo be added once deployed\n\nThe October PT will remain listed through maturity with its existing configuration.\nDisclaimer\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nEscalate this proposal directly to the AIP stage.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n read \n\n 5\n min\n\n post by LlamaRisk 4 days ago\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Changelog\n\n2026-10-02: USDe added as a borrowable asset in the PT-AUSD-17DEC2026 Stablecoins E-Mode\n\nSummary\nLlamaRisk supports onboarding PT-AUSD-17DEC2026 to the Aave V3 instance on Monad. It is a Pendle PT with 76 days remaining until it matures on December 17, 2026, a zero-coupon claim that redeems 1:1 for AUSD at maturity.\nThe prior maturity, PT-AUSD-8OCT2026, is live on the Monad instance with 67.4M PT supplied as collateral and matures on October 8, 2026. PT-AUSD-17DEC2026 is the rollover destination where up to 67.4M of Aave collateral could move into the new maturity as the October expiry arrives.\nThe PT-AUSD-17DEC2026 Pendle market was deployed on September 22, 2026, and was seeded between September 30 and October 2, 2026. It holds $1.61M in liquidity, 904,717 PT is outstanding, and $44.0K has traded against it since deployment. The implied yield has moved from its 6.00% deployment anchor to 5.64% as traders bought PT from the pool.\nAssessment of PT base asset: Link\nAssessment of Pendle PTs: Link\nConsidered PT asset maturities: PT-AUSD-17DEC2026\nAsset State\nAsset Growth\nAUSD circulating supply is $249.0M across all chains, of which Monad holds $146.7M, 58.9% of the global float and the largest single-chain share, ahead of Ethereum at $76.0M. Monad supply rose from $33.1M in mid-June 2026 to a peak of $198.2M on September 5, 2026, and stands at $146.7M at the snapshot. The SY-AUSD wrapper backing this market holds 1.66M AUSD.\nausd_supply_monad2070×1098 161 KB\nSource: LlamaRisk, October 2, 2026\nUnderlying Stability\nAUSD is Agora’s institutional digital dollar, issued 1:1 against USD and backed by cash, short-dated U.S. Treasury bills, and overnight reverse repurchase agreements. Reserves are managed by VanEck, State Street acts as cash custodian and fund administrator, and reserves are independently attested by Grant Thornton. On Monad the token is deployed as a LayerZero OFT.\nThe Chainlink AUSD/USD feed on Monad has published 7,659 rounds since November 20, 2025 and reads $0.99988 at the snapshot. Across that 315-day history the feed ranged between $0.99863 and $1.00094, a maximum deviation of 13.7 bps below par. All 13 observations below $0.9990 fall on November 21, 2025, the day after the feed began publishing. No structural anomalies appear in the series.\nausd_chainlink_monad2070×1098 117 KB\nSource: LlamaRisk, October 2, 2026\nUnderlying Liquidity\nAUSD trades on Monad through Balancer V3, Curve, and Mento pools. Six DEX pools pairing AUSD hold $8.91M in combined inventory, led by Balancer V3 AVUSD-AUSD at $2.53M, Curve AUSD-USDC-USDT0 at $2.34M, and Mento AUSD-USDM at $2.32M. That inventory is 6.1% of the chain’s AUSD supply.\nUnderlying Yield Source\nAUSD does not pay its holders the return earned on the reserve assets that back it. Inside this Pendle market, Agora rebates that Treasury bill yield to holders of the SY token at an administered 3.50% APY, paid in AUSD on a monthly cycle. The rebate is distributed off-chain: the SY contract takes AUSD as its only input and yield token, holds no reward tokens, and has an exchange rate fixed at 1.0, so recipients claim through a merkle distributor rather than accruing value inside the token. Pendle splits the position into PT-AUSD-17DEC2026, which captures the yield as a fixed discount to par and redeems 1:1 for AUSD at maturity, and a yield token that carries the floating stream.\nThe market page carries the current breakdown of the underlying stream.\nThe principal claim is independent of the rebate. A PT redeems for one AUSD at maturity whether or not the rebate continues, so cessation would bear on the yield token and on pool liquidity rather than on the redemption value of the collateral.\nMarket Analysis\nTotal Supply\nThe PT-AUSD-17DEC2026 Pendle pool has been live since September 22, 2026 and holds $1.61M in total liquidity (753,300 SY-AUSD and 868,063 PT-AUSD-17DEC2026). Most of that liquidity arrived in three deposits, $49.6K on September 30 and $993.5K and $496.9K on October 2, 2026, alongside smaller deposits from other liquidity providers. 904,717 PT-AUSD-17DEC2026 have been minted in aggregate, of which 868,063 (95.9%) sit inside the AMM and 36,654 are held outside it. The market has recorded $44.0K of trading volume since deployment across 14 trades, all of them PT purchases.\npool_liquidity2070×1098 107 KB\nSource: LlamaRisk, October 2, 2026\nPool Composition\nPT-AUSD-17DEC2026 Pool:\n\nTotal Liquidity: $1.61M\nSY-AUSD: 753,300\nPT-AUSD-17DEC2026: 868,063\n\nThe pool holds 46.5% SY against 53.5% PT by token count. The SY reserve, which sets the quantity a PT seller can draw from the AMM in a single direction, stands at 753,300 SY-AUSD.\npool_composition1980×639 45.7 KB\nSource: LlamaRisk, October 2, 2026\nPrice and Yield\nThe market quotes a PT implied yield of 5.64%, an underlying AUSD yield of 3.50%, and a PT discount to par of 1.13%. The implied yield held at its 6.00% deployment anchor until the first trade on October 1, 2026, and has declined since as every trade to date bought PT from the pool. It sits within the market’s configured liquidity yield range of 3% to 8%.\npt_yield2070×1098 112 KB\nSource: LlamaRisk, October 2, 2026\nPT Yield in Context\nAt 5.64%, PT-AUSD-17DEC2026 sits above three of the five stablecoins borrowable in the PT-AUSD-17DEC2026 Stablecoins E-Mode on the Aave V3 Monad instance, which carry variable borrow rates of 4.28% for mUSD, 4.64% for GHO, and 5.10% for USDT0. A 1% campaign boost on the PT raises its effective yield to 6.64%, which also clears USDC at 6.09%. It sits below USDe at 6.82%, so a leveraged position funded with USDe carries negative carry at the snapshot rates. These borrow rates are variable, the boost applies only while the campaign runs, and the PT rate will continue to move as the newly seeded pool trades, so neither side of the spread is fixed for the life of the position.\nMaturities\nPT-AUSD-8OCT2026 is live on Monad and approaches expiry. PT-AUSD-17DEC2026 is the only AUSD Principal Token maturity on Monad extending beyond it, and will serve as the rollover destination for holders exiting the October maturity.\nIntegrated Venues\nPT-AUSD-17DEC2026 is accepted as collateral in Neverland’s Isolated Pendle AUSD market on Monad, at an LTV of 95% and a liquidation threshold of 96%, with a supply cap of 10.0M PT. 10.12 PT is supplied there at the snapshot, so no lending market yet holds a meaningful position in it.\nRecommendations\nSpecification\n\nParameter\nValue\n\nBorrowable\nNo\n\nCollateral Enabled\nNo\n\nSupply Cap\n30,000,000\n\nBorrow Cap\n-\n\nLTV\n-\n\nLT\n-\n\nLiquidation Bonus\n-\n\nLiquidation Protocol Fee\n10.00%\n\nE-Mode Category\nPT-AUSD-17DEC2026 Stablecoins\n\nLinear Discount Rate Oracle\n\nParameter\nValue\n\ninitialDiscountRatePerYear\n5.745%\n\nmaxDiscountRatePerYear\n8.804%\n\nPT-AUSD-17DEC2026 Stablecoins E-Mode (#6)\n\nParameter\nValue\n\nIsolated\n*False\n\nLTV\n93.00%\n\nLiquidation Threshold\n95.00%\n\nLiquidation Bonus\n2.62%\n\nAsset\nPT-AUSD-17DEC2026\nUSDT0\nUSDC\nGHO\nmUSD\nUSDe\n\nCollateral\nYes\nNo\nNo\nNo\nNo\nNo\n\nBorrowable\nNo\nYes\nYes\nYes\nYes\nYes\n\n* as per rationale in [ARFC] Unified Handling of the Isolated Flag in Aave V3.7 E-Modes\nPrice Feed Recommendation\nLlamaRisk recommends pricing PT-AUSD-17DEC2026 with the dynamic linear discount rate oracle already used for Pendle Principal Tokens on Aave V3 and V4, referenced against the Chainlink AUSD/USD feed under the CAPO stable adapter that bounds AUSD’s upward deviation at $1.04.\nThe discount rate parameters follow LlamaRisk’s dynamic PT risk-parameter methodology.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance\n\n Governance\n\n 5\n\n 598\n\n Aug 7\n\n [Direct to AIP] Onboard PT-USDe-22OCT2026 to Aave V3 Monad\n\n Governance\n\n 2\n\n 242\n\n Sep 4\n\n [Direct-to-AIP] PT-USDG X Layer\n\n Governance\n\n 2\n\n 304\n\n Aug 19\n\n [Direct-to-AIP] Onboard PT-USDG-24SEP2026 to Aave V4 on Ethereum\n\n New Asset\n\n 7\n\n 1.0k\n\n Jul 16\n\n [Direct to AIP] Onboard Strata srUSDe-22OCT2026 PT tokens to V3 Core Instance\n\n New Asset\n\n 2\n\n 283\n\n Jun 16","tokens":3070,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266319530,"hash":"85d7bf0bc70983b85358c15086df7e66947f61f7"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-pyth-core-september-30th-2025/402","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2025\n\n 1 / 4\n\n Sep 2025\n\n Oct 2025\n\n post by KemarTiti on Sep 30, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes, liquidity), and exceptional news (token migration or else) it has been decided to sunset a few feeds. Please note that volumes, liquidity and other metrics are following this framework.\nAll below feeds are scheduled to be sunset on Tuesday 30th, September, 2025.\nIf you’re using or planning to use these feeds in any capacity, please let us know directly and we’ll be able to reassess the need for their deprecation.\n\nBOOP/USD\nCHUTES/USD\nCUSD/USD\nEVMOS/USD\nEURA/USD\nFAI/USD\nKEYCAT/USD\nMOD/USD (currently Sponsored)\nOMG/USD\nQUICK/USD\nSEAM/USD\nSHDW/USD\nTAOHASH/USD\nBRENTV5/USD (expired)\nWTIU5/USD (expired)\n\nIf edits were to be applied, they will be visible as a comment to this post.\n\n post by KemarTiti on Sep 12, 2025\n\n KemarTiti\n\n Two feeds were removed from the above list and their deprecation has been advanced to the 15th September, 2025.\nFind more details here: Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n post by KemarTiti on Sep 16, 2025\n\n KemarTiti\n\nBLUB has been removed for now given its usage on Sui.\nAMI has been removed for now given its usage on Aptos.\nLUSD has been removed for now given its prospective usage from downstream protocols.\n\n 16 days later\n\n post by KemarTiti on Oct 2, 2025\n\n KemarTiti\n\n These deprecations have all been done.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – August 18th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 697\n\n Aug 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 549\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 499\n\n Jan 3\n\n Powered by Discourse","tokens":1489,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266330854,"hash":"1d71e409c2fa997849041eb63cbc1d8299c6a8be"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/tokens","domain":"docs.openzeppelin.com","title":"Tokens | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensOpen in ClaudeAh, the \"token\": blockchain’s most powerful and most misunderstood tool.\nA token is a representation of something in the blockchain. This something can be money, time, services, shares in a company, a virtual pet, anything. By representing things as tokens, we can allow smart contracts to interact with them, exchange them, create or destroy them.\nBut First, Coffee a Primer on Token Contracts\nMuch of the confusion surrounding tokens comes from two concepts getting mixed up: token contracts and the actual tokens.\nA token contract is simply an Ethereum smart contract. \"Sending tokens\" actually means \"calling a method on a smart contract that someone wrote and deployed\". At the end of the day, a token contract is not much more than a mapping of addresses to balances, plus some methods to add and subtract from those balances.\nIt is these balances that represent the tokens themselves. Someone \"has tokens\" when their balance in the token contract is non-zero. That’s it! These balances could be considered money, experience points in a game, deeds of ownership, or voting rights, and each of these tokens would be stored in different token contracts.\nDifferent Kinds of Tokens\nNote that there’s a big difference between having two voting rights and two deeds of ownership: each vote is equal to all others, but houses usually are not! This is called fungibility. Fungible goods are equivalent and interchangeable, like Ether, fiat currencies, and voting rights. Non-fungible goods are unique and distinct, like deeds of ownership, or collectibles.\nIn a nutshell, when dealing with non-fungibles (like your house) you care about which ones you have, while in fungible assets (like your bank account statement) what matters is how much you have.\nStandards\nEven though the concept of a token is simple, they have a variety of complexities in the implementation. Because everything in Ethereum is just a smart contract, and there are no rules about what smart contracts have to do, the community has developed a variety of standards (called EIPs or ERCs) for documenting how a contract can interoperate with other contracts.\nYou’ve probably heard of the ERC-20 or ERC-721 token standards, and that’s why you’re here. Head to our specialized guides to learn more about these:\n\nERC-20: the most widespread token standard for fungible assets, albeit somewhat limited by its simplicity.\nERC-721: the de-facto solution for non-fungible tokens, often used for collectibles and games.\nERC-1155: a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible and non-fungible tokens, along with batched operations for increased gas efficiency.\nMultisigPrevious PageOverviewNext PageOn this pageBut First, Coffee a Primer on Token ContractsDifferent Kinds of TokensStandards","tokens":711,"squid":"ink-security_audits","role":"Sentinel","at":1791266340400,"hash":"2b610e04cbec88baeb691060f1dc23442d412ed1"}
{"url":"https://governance.aave.com/t/arfc-onboard-pt-ausd-8oct2026-to-aave-v3-monad-instance/25331","domain":"governance.aave.com","title":"[ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance - Governance - Aave","text":"[ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 7\n min\n\n Summary\n\n Motivation\n\n Overview\n\n Rationale for Onboarding PT-AUSD-8OCT2026\n\n Specification\n\n Oracle\n\n Risk Parameters\n\n eMode #5 - PT Agora Stablecoins\n\n Linear Discount Rate Oracle\n\n Disclaimer\n\n Next Steps\n\n Copyright\n\n Jul 16\n\n 1 / 7\n\n Jul 17\n\n Aug 7\n\n post by TokenLogic on Jul 16\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance\nauthor: @TokenLogic\ncreated: 2026-07-16\n\nSummary\nThis ARFC proposes onboarding PT-AUSD-8OCT2026, the PT for Agora’s AUSD to the Aave V3 instance on Monad.\nMotivation\nOverview\nAave went live on Monad in July 2026 and crossed 300M USD in deposits, with AUSD onboarded as one of the instance’s core stablecoin reserves. AUSD is Agora’s institutional digital dollar, minted 1:1 against USD and backed by cash, short-dated U.S. Treasury bills and overnight reverse repurchase agreements. The reserve fund is managed by VanEck, with State Street acting as cash custodian and fund administrator, and reserves are independently attested by Grant Thornton. AUSD is currently the largest stablecoin on Monad, and Pendle operates a liquid AUSD market on the chain.\nRationale for Onboarding PT-AUSD-8OCT2026\nOnboarding this maturity would enable users to use their fixed-yield PT-AUSD positions as collateral within the same Aave market that already supports AUSD, further enhancing the utility and capital efficiency of the stablecoin on Aave’s latest deployment.\nAs a short-dated, AUSD-backed asset, PT-AUSD offers a collateral profile that is well aligned with Aave’s risk framework, making it a strong candidate for inclusion on Monad.\nSelected market data at the time of submission:\n\nMetric\nValue\n\nUnderlying asset\nAUSD (Agora)\n\nMaturity\n8 October 2026\n\nResidual maturity at submission\nApproximately 85 days\n\nPT implied APY\nApproximately 6.5%\n\nPendle market liquidity\nApproximately 5.75M USD\n\nPT total value locked\nApproximately 67.5M USD\n\n7-day trading volume\nApproximately 8.06M USD\n\nThe case for onboarding rests on the following points:\n\nIncentives from Agora. Agora has committed some incentives towards that Pendle market we can see the current implied rate around 6.5% APR being subsidized with incentives.\nUnderlying already onboarded. AUSD is already a live reserve on the Aave Monad instance, so the market already prices AUSD and the collateral pairing is natural: PT-AUSD supplied as collateral against AUSD or other stablecoin debt within a dedicated E-Mode category.\nEcosystem growth. Enabling PT-AUSD as collateral supports stablecoin leverage and borrowing demand on a nascent instance, aligned with the growth objectives set out in the Aave Protocol v3.7 Monad deployment.\n\nSpecification\nThe following asset would be onboarded to the Aave V3 instance on Monad.\n\nField\nValue\n\nAsset\nPT-AUSD-8OCT2026\n\nNetwork\nMonad (chainId 143)\n\nPT token address\n0x9fc74f8ed616b5baf52a170caa97d6d3898602d1\n\nPendle market address\n0x6f99cf00ee7290ae78a072bb6910ef72d1129fe7\n\nSY token address\n0xba3d60f5000f472aef947fb8020a3e6319f9a0b7\n\nYT token address\n0xeddee9c0b56248d70a9bfdd103f8bd97c35dfd89\n\nUnderlying asset (AUSD)\n0x00000000efe302beaa2b3e6e1b18d08d69a9012a\n\nMaturity\n8 October 2026\n\nOracle\nPrice Feed Recommendation\nFor pricing PT-AUSD-8OCT2026 on Aave, the dynamic linear discount rate oracle is recommended. The same oracle template currently in use for Pendle PT assets on Aave V3, can be reused for this deployment.\nThe oracle prices the PT as a zero-coupon bond against a capped underlying Chainlink reference (AUSD/USD fixed at 1 USD), applying a linear discount that decays to par at maturity. The discount rate is bounded above by the maxDiscountRatePerYear parameter, providing a deterministic price floor against adverse market dislocations.\nDiscount Rate Parameters\n\nParameter\nPT-AUSD-8OCT2026\n\ninitialDiscountRatePerYear\nTo be provided by Risk Service Providers\n\nmaxDiscountRatePerYear\nTo be provided by Risk Service Providers\n\nRisk Parameters\nPer Aave’s asset onboarding framework, all risk parameters for PT-AUSD-8OCT2026 will be provided by the Risk Service Provider, LlamaRisk and appended to this proposal prior to escalation to the Snapshot stage.\nAn indicative market structure is shown below:\n\nParameter\nValue\n\nAsset\nPT-AUSD-8OCT2026\n\nBorrowable\nNo\n\nCollateral Enabled\nNo\n\nSupply Cap\n20,000,000\n\nBorrow Cap\n-\n\nDebt Ceiling\n-\n\nLTV\n-\n\nLT\n-\n\nLiquidation Penalty\n10.00%\n\nLiquidation Protocol Fee\n-\n\nE-Mode Category\nPT Agora Stablecoins\n\neMode #5 - PT Agora Stablecoins\n\nParameter\nValue\nValue\nValue\nValue\n\nAsset\nPT-AUSD-8OCT2026\nUSDT0\nUSDC\nGHO\n\nCollateral\nYes\nNo\nNo\nNo\n\nBorrowable\nNo\nYes\nYes\nYes\n\nMax LTV\n93.00%\n-\n-\n-\n\nLiquidation Threshold\n95.00%\n-\n-\n-\n\nLiquidation Bonus\n2.44%\n-\n-\n-\n\nLinear Discount Rate Oracle\n\nParameter\nValue\n\ninitialDiscountRatePerYear\n6.661%\n\nmaxDiscountRatePerYear\n8.829%\n\nGiven the current on-chain liquidity of the PT-AUSD market on Monad (approximately 5.75M USD), a conservative initial supply cap and a collateral configuration consistent with the treatment of comparable short-dated Pendle PT stablecoin assets on other Aave instances is anticipated.\nDisclaimer\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nIf consensus is reached on this ARFC, escalate this proposal to the Snapshot stage.\nIf Snapshot outcome is YAE, escalate this proposal to the AIP stage.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\n\n 2\n\n read \n\n 7\n min\n\n post by LlamaRisk on Jul 23\n\n 14 days later\n\n post by SrAugust on Aug 6\n\n post by Abel189 on Aug 7\n\n post by signalxu on Aug 7\n\n post by SrAugust on Aug 7\n\n 1 month later\n\n Closed on Sep 6\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct-To-AIP] Onboard PT-AUSD-17DEC2026 to Aave V3 Monad Instance\n\n New Asset\n\n 1\n\n 124\n\n 4d\n\n [Direct to AIP] Onboard PT-USDe-22OCT2026 to Aave V3 Monad\n\n Governance\n\n 2\n\n 242\n\n Sep 4\n\n [Direct-to-AIP] Onboard PT-USDG-24SEP2026 to Aave V4 on Ethereum\n\n New Asset\n\n 7\n\n 1.0k\n\n Jul 16\n\n [Direct-to-AIP] PT-USDG X Layer\n\n Governance\n\n 2\n\n 304\n\n Aug 19\n\n [ARFC] Onboard PT-USDG-28MAY2026 to Aave V3 Core Instance\n\n New Asset\n\n 4\n\n 894\n\n Apr 14","tokens":1690,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266341048,"hash":"ac5de684eb450b0ef23aa906fd752073df14dca7"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc20","domain":"docs.openzeppelin.com","title":"ERC-20 | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensERC-20Open in ClaudeAn ERC-20 token contract keeps track of fungible tokens: any one token is exactly equal to any other token; no tokens have special rights or behavior associated with them. This makes ERC-20 tokens useful for things like a medium of exchange currency, voting rights, staking, and more.\nOpenZeppelin Contracts provides many ERC20-related contracts. On the API reference you’ll find detailed information on their properties and usage.\nConstructing an ERC-20 Token Contract\nUsing Contracts, we can easily create our own ERC-20 token contract, which will be used to track Gold (GLD), an internal currency in a hypothetical game.\nHere’s what our GLD token might look like.\n// contracts/GLDToken.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract GLDToken is ERC20 {\n constructor(uint256 initialSupply) ERC20(\"Gold\", \"GLD\") {\n _mint(msg.sender, initialSupply);\n }\n}\nOur contracts are often used via inheritance, and here we’re reusing ERC20 for both the basic standard implementation and the name, symbol, and decimals optional extensions. Additionally, we’re creating an initialSupply of tokens, which will be assigned to the address that deploys the contract.\nFor a more complete discussion of ERC-20 supply mechanisms, see Creating ERC-20 Supply.\nThat’s it! Once deployed, we will be able to query the deployer’s balance:\n> GLDToken.balanceOf(deployerAddress)\n1000000000000000000000\nWe can also transfer these tokens to other accounts:\n> GLDToken.transfer(otherAddress, 300000000000000000000)\n> GLDToken.balanceOf(otherAddress)\n300000000000000000000\n> GLDToken.balanceOf(deployerAddress)\n700000000000000000000\nA Note on decimals\nOften, you’ll want to be able to divide your tokens into arbitrary amounts: say, if you own 5 GLD, you may want to send 1.5 GLD to a friend, and keep 3.5 GLD to yourself. Unfortunately, Solidity and the EVM do not support this behavior: only integer (whole) numbers can be used, which poses an issue. You may send 1 or 2 tokens, but not 1.5.\nTo work around this, ERC20 provides a decimals field, which is used to specify how many decimal places a token has. To be able to transfer 1.5 GLD, decimals must be at least 1, since that number has a single decimal place.\nHow can this be achieved? It’s actually very simple: a token contract can use larger integer values, so that a balance of 50 will represent 5 GLD, a transfer of 15 will correspond to 1.5 GLD being sent, and so on.\nIt is important to understand that decimals is only used for display purposes. All arithmetic inside the contract is still performed on integers, and it is the different user interfaces (wallets, exchanges, etc.) that must adjust the displayed values according to decimals. The total token supply and balance of each account are not specified in GLD: you need to divide by 10 ** decimals to get the actual GLD amount.\nYou’ll probably want to use a decimals value of 18, just like Ether and most ERC-20 token contracts in use, unless you have a very special reason not to. When minting tokens or transferring them around, you will be actually sending the number num GLD * (10 ** decimals).\nBy default, ERC20 uses a value of 18 for decimals. To use a different value, you will need to override the decimals() function in your contract.\nfunction decimals() public view virtual override returns (uint8) {\n return 16;\n}\nSo if you want to send 5 tokens using a token contract with 18 decimals, the method to call will actually be:\ntransfer(recipient, 5 * (10 ** 18));OverviewPrevious PageCreating SupplyNext PageOn this pageConstructing an ERC-20 Token ContractA Note on decimals","tokens":929,"squid":"ink-security_audits","role":"Sentinel","at":1791266350505,"hash":"268e4021f4f247e272b8de05718c1b5a4e1cb043"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-protocol-v3-7-on-monad/24943/3","domain":"governance.aave.com","title":"[ARFC] Deploy Aave Protocol v3.7 on Monad - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n read \n\n 29\n min\n\n May 19\n\n 3 / 11\n\n Jun 12\n\n Jul 26\n\n post by TokenLogic on May 19\n\n 20 days later\n\n post by LlamaRisk on Jun 9\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports Aave deployment to Monad with specific considerations. The network launched its public mainnet on November 24, 2025, making it roughly 7 months old at the time of writing. While Monad’s parallel EVM execution architecture and full bytecode compatibility reduce deployment friction, the network’s relatively short operational history warrants conservative initial parameters.\nCurrent TVL stands at approximately $359.5m. The ecosystem has attracted established DeFi protocols (Uniswap, Curve, and Morpho) alongside Monad-native applications (Neverland and Kuru), though liquidity remains concentrated in the former. Initial strong early usage on the network has compressed, with activity remaining relatively the same until recently, with a marginal uptick in active addresses in April 2026.\n1. Network Fundamental Characteristics\n1.1 Network Overview\nMonad is a Layer 1 Proof-of-Stake blockchain that targets full EVM bytecode compatibility while re-engineering the execution layer for higher throughput. It is not an L2 or rollup; it is an independent L1 with its own validator set and consensus mechanism.\nThe network’s performance rests on four architectural components:\n\nMonadBFT: a pipelined, HotStuff-family BFT consensus (HotStuff-style) that separates ordering/finality from execution so validators can agree on block order while execution is performed out of the consensus hot path.\nOptimistic parallel execution: concurrent execution with conflict detection and re-execution for dependent states, rather than strictly sequential EVM execution.\nAsynchronous/deferred execution: consensus and execution are decoupled; block production is not gated on finishing prior-block execution.\nMonadDB: a custom state database layer described as part of the core architecture.\n\nTarget throughput is up to 10,000 TPS with 400 ms block times and ~800 ms finality. Current throughput averages are 16-47 TPS and 400.27 ms block times.\nArchitecture\nMonad is designed as an EVM bytecode-equivalent Layer 1 with a performance model built around separating ordering/finality from execution. Transactions are still linearly ordered, but execution is implemented as optimistic parallel execution: independent transactions can be executed concurrently, and conflicts are handled by detecting incorrect reads and re-executing affected transactions; even with parallel execution, state updates are merged sequentially to preserve the deterministic EVM result.\nMON is the chain’s native accounting and security asset. Transaction fees are denominated in MON, and the documentation specifies that deductions follow `value + gas_price * gas_limit` (i.e., charging against the declared gas limit). Validator voting weight and leader scheduling are stake-based, with MON staked by validators and delegated by holders, making MON the input to consensus participation and reward distribution.\nConsensus is provided by MonadBFT, which targets speculative finality in a single round and full finality in two rounds. This finality structure matters for liquidation and arbitrage flows because actors either price in the small speculative-finality reversion tail or wait for two-round finality before executing size.\nimage1100×1067 240 KB\nSource: MonadBFT, Monad docs\nMonadBFT is a leader-based BFT protocol where a designated leader proposes the next block in each round. The leader rotates each round according to a schedule determined previously using the stake weights. After validators vote on the proposal, the leader aggregates votes into a quorum certificate once a supermajority threshold is reached. The next leader then builds on the highest-certified block, and finality is achieved by accumulating certificates across consecutive rounds, which is why the protocol distinguishes one-round speculative confirmation from two-round deterministic finality.\nIn the normal (happy) path, the leader is live and messages propagate on time, so validators form a QC (Quorum Certificate) for the proposed block in one round, and the following round extends it, producing deterministic finality on the second round. The unhappy path occurs when a round fails to gather timely votes into a QC, typically due to a non-responsive leader, delayed message propagation, or Byzantine behavior that disrupts vote collection. Timeout handling is round-based: if a validator does not observe a QC before its local timer expires, it stops waiting for that round, emits a timeout signal that carries its highest observed QC, and advances to the next round. The next leader uses the timeout signals to converge on the highest-certified chain tip and proposes a new block extending that highest QC, allowing the protocol to make progress without committing the stalled proposal. This preserves safety under the <1/3 faulty stake assumption but increases latency and can extend the time between speculative confirmation and deterministic finality.\nSecurity\nMonad’s security posture is documented through third-party review and a standing, incentivized disclosure program. The MiCA white paper states that the protocol underwent security audits by Zellic and Spearbit and that a public audit competition was completed ahead of the contemplated admission to trading, while also noting that undiscovered vulnerabilities may still exist in the core protocol.\nFor ongoing vulnerability reporting, the core client repository directs researchers to a Cantina bug bounty. Cantina is the primary disclosure channel for Monad core issues, with max rewards of $1,000,000 (Critical), $100,000 (High), and $35,000 (Medium). Scope is centered on chain-critical components: MonadBFT consensus safety/finality, RaptorCast networking (DoS, propagation delays, signature/Merkle verification), parallel execution determinism/state integrity, transaction + fee model correctness, and high-sensitivity execution components (MonadDB integrity and JIT vs interpreter consistency, including RCE-class risk).\nResidual exposure is concentrated in client implementation and upgrade risk: defects introduced through new releases, parameter changes, or edge-case interactions under mainnet load can surface as consensus faults or execution inconsistencies, which would be higher impact than application-layer contract bugs due to their potential to affect chain-wide settlement guarantees.\nFees\nGas fees are near-zero, denominated and payable in MON. Monad transaction fees are EIP-1559 compatible: the effective gas price paid per unit of gas is the sum of a protocol-controlled base fee and a user-specified priority fee, and the amount charged is the transaction gas limit (i.e., deduction is value + gas_price * gas_limit).\nMonad sets base_price_per_gas with a controller that targets block fullness rather than using Ethereum’s linear EIP-1559 update. For each block k, it first computes block_gas_k as the sum of gas_limit_tx across all transactions in the block. The next block’s base price is then updated multiplicatively:\nimage841×682 45.5 KB\nSource: Gas Pricing, Monad docs\nThe parameters shown imply a utilization target of 80% (target = 160M) under a block_gas_limit of 200M and a minimum base fee of min_base_price_per_gas = 100 MON-gwei. This design hard-floors transaction inclusion cost and sets fee dynamics through a volatility-sensitive controller; liquidation and arbitrage execution quality therefore depends on how quickly base fees reprice as blocks move above target utilization and whether the min base fee and repricing path remain compatible with liquidator margins during congestion. Relative to Ethereum’s base fee controller, Monad’s controller is configured to increase more slowly and decrease more quickly, with the stated objective of reducing the risk of blockspace underutilization caused by an overpriced base_price_per_gas.\n1.2 Decentralization and Legal Evaluation\nMonad is disclosed as two core entities: Monad Foundation (a memberless Cayman foundation company; ecosystem/governance facilitation) and Category Labs (protocol engineering; rebrand from Monad Labs on Dec 16, 2024). Foundation leadership is described as Keone Hon and Eunice Giarta (co-GMs) with a board including Petrus Basson, Keone Hon, and Marc Piano; Category Labs is led by James Hunsaker (CEO).\nLegal Evaluation\nMonad’s disclosed legal perimeter follows a common three-entity pattern that separates ecosystem stewardship, software development, and token distribution mechanics. The Coinbase sale disclosure identifies MF Services (BVI) Ltd. as the token sale seller and as a wholly owned subsidiary of the Monad Foundation, indicating that primary distribution activity is routed through a BVI vehicle.\nSeparately, Monad publishes a MiCA-format white paper, which functions as a disclosure document for EU audiences (issuer/offeror identity, token function, technical description, and risk factors). This improves documentation quality and comparability but does not itself resolve cross-jurisdiction classification risk, as token treatment remains regulator- and fact-pattern-dependent outside the MiCA disclosure framework.\nKey legal monitoring items are therefore concentrated in (i) entity boundary clarity (which entity controls token distribution, incentives, and treasury actions), (ii) governance and control disclosures (board/management authority, delegation and upgrade processes), and (iii) disclosure consistency across primary-sale documentation and the MiCA white paper, particularly where representations about token rights, restrictions, conflicts, and distribution discretion affect regulatory interpretation and counterparty diligence.\nUpgrades are executed as scheduled hard forks tied to client releases and activation timestamps; protocol “revisions” are activated at a future timestamp, and node operators are expected to upgrade ahead of that activation. MON holders do not currently have direct on-chain voting over upgrades; the white paper states governance participation is expected via validator delegation and notes there are no current plans for on-chain governance with MON.\nValidators\nAs of early 2026, the network is operated by a validator set in which only the top 200 validators by total stake are active each epoch. Validator registration is stake-gated with a 100,000 MON minimum self-stake, and delegation is supported. According to gmonads data, validator geographic dispersion spans 29 countries, including the United States (22.9%), the Netherlands (17.88%), Germany (15.5%), Finland (5.44%), and Singapore (5.18%), representing the largest share of delegated stake. Validators stake MON and are subject to penalties primarily through reward loss for downtime; current enforcement is not described as an active slashing regime.\nimage1699×259 20.3 KB\nSource: Monad Validators, gmonads.com, June 8th, 2026\nSlashing\nCurrent protocol documentation states that slashing is not live on Monad at this time; the enforced downside for validator downtime is loss of rewards for the validator and its delegators. This makes the present penalty regime primarily yield-based, with no in-protocol capital loss mechanism described as active. The lack of slashing adds an incentive risk layer, given the limited set of validators and the outsized influence the largest stakers can have on operations.\n1.3 Activity Benchmarks\nThis section benchmarks whether Monad’s DeFi footprint is large enough to support a production money market without relying on incentive-driven flows. The focus is on balance-sheet size (TVL and stablecoin float), where liquidity is actually deployed (sector concentration), and whether the chain shows enough transactional throughput to keep liquidations and arbitrage functional during volatility states.\nNetwork TVL\nimage2560×1440 228 KB\nSource: Monad TVL, DefiLlama, June 8th, 2026\nThere’s currently around $359.5m in DeFi TVL and $425.7m of stablecoin supply on the chain. Bridged TVL is reported at $600m.\nimage1198×547 109 KB\nSource: Monad DeFi TVL, Dune, June 8th, 2026\nAt the time of writing, lending is the largest tracked DeFi segment at $328.6m TVL, led by Morpho ($123m), Euler ($86m), Curvance ($56m), and Neverland ($44m), which indicates an existing strong interest in lending-based protocols. Leading DEXs include Balancer v3 ($17m), Uniswap v4 ($14m), and Curve ($10m).\nNetwork Activity\nimage1206×517 36.5 KB\nSource: Monad - Active Addresses, Dune, May 29th, 2026\nThe daily active user trend shows significant fluctuations and irregular bursts, with peaks reaching close to 150,000 users at launch, while the 7-day average remains at 9,000 new users.\nimage1201×535 29.5 KB\nSource: Monad - Active Contracts, Dune, June 8th, 2026\nDaily active contracts show a front-loaded spike at launch, with activity briefly reaching the high-teens thousands before rapidly compressing into a lower, steadier baseline.\nA notable contract registration spike occurred on December 2nd, 2025, when 17,934 new contracts were created in a single day.\nimage1195×517 35.1 KB\nSource: Monad - Daily Tx Fees, Dune, June 8th, 2026\nDaily transaction fees show an initial launch-driven spike in late November, where total fee spend briefly reached $35k per day, followed by a rapid compression into a stable baseline. From January onward, fees remain range-bound with intermittent bursts and a modest pickup in volatility around early February, but without returning to the initial launch peak.\n1.4 Security\nMonad’s infrastructure has undergone multiple independent security audits. 16 audits have been completed to date, including:\n\nZellic (August - September, 2025):\n\nCompiler: 1 informational issue found. Issues were acknowledged and/or fixed.\nRPC: 4 medium, 1 low, and 1 informational issues were found. Issues were acknowledged and/or fixed.\nConsensus: 5 critical, 2 high, 1 medium, and 3 informational issues were found. Issues were acknowledged and/or fixed.\nDatabase: 3 informational issues were found. Issues were acknowledged.\nExecution: 1 high, 3 medium, 1 low, and 7 informational issues were found. Issues were acknowledged and/or fixed.\nNetworking: 4 critical, 2 high, 2 medium, 1 low, and 1 informational. Issues were acknowledged and/or fixed.\n\nSpearbit (November, 2025): 1 critical, 15 high, 10 medium, 8 low, and 13 informational issues were found. Issues were fixed or acknowledged.\nCode4rena (September, 2025): 4 high and 7 medium risks were found.\nOttersec (December, 2025 - March, 2026):\n\nBFT: 4 medium, 5 low, and 5 informational. Issues were acknowledged and/or fixed.\nExecution: 1 medium, 3 low, and 4 informational. Issues were acknowledged and/or fixed.\nJIT: 11 low and 6 informational. Issues were acknowledged and/or fixed.\nRPC: 3 low and 2 informational. Issues were acknowledged and/or fixed.\nDB: 1 high, 3 low, and 1 informational. Issues were either partially or fully resolved.\n\nRuntime Verification (March, 2026): 4 medium and 2 low severity findings. Issues were either partially or fully resolved.\nPerimeter (January - March, 2026)\n\nRPC & Execution: 1 high, 1 low, and 3 informational issues were found. Issues were either partially or fully resolved.\nFuzzing Report: 1 high, 1 low, and 3 informational. Issues were either partially or fully resolved.\n\n2. Network Market Outlook\n2.1 Market Infrastructure\nBridges\nCross-chain infrastructure for Monad is available through messaging and bridging protocols, including Chainlink CCIP, which is listed as officially supported cross-chain infrastructure (via MonadBridge), deBridge, and LayerZero for omnichain bridging, alongside additional providers such as Wormhole, Hyperlane, Relay, LI.FI, and Across Protocol. A full provider summary can be found here, covering setups on Monad and links to architectural documentation.\nUsers should verify official interfaces and contract addresses before transferring assets and consider limiting transfer sizes to manage exposure.\nKey assets bridged to Monad, their supported architecture includes:\n\nAsset\nBridge Setup\n\nUSDC\nCircle CCTP\n\nUSDT0\nLayerZero OFT (Stargate)\n\nWETH\nNTT 2/2 (MonadBridge)\n\nwstETH\nChainlink CCIP (Transporter)\n\nWBTC\nLayerZero OFT (Stargate)\n\nA full token list of bridged assets can be found [here](GitHub - monad-crypto/token-list · GitHub), which contains all supported assets and the bridging infrastructure used on Monad mainnet.\n {\n \"chainId\": 143,\n \"address\": \"0xaB6e5a0C3799d020c790D34F7B2C02639e238AF7\",\n \"name\": \"Syrup USDC\",\n \"symbol\": \"syrupUSDC\",\n \"decimals\": 6,\n \"extensions\": {\n \"coinGeckoId\": \"syrupusdc\",\n \"bridgeInfo\": {\n \"protocol\": \"Chainlink CCIP\",\n \"bridgeAddress\": \"0x33566fE5976AAa420F3d5C64996641Fc3858CaDB\"\n },\n \"crossChainAddresses\": {\n \"1\": {\n \"address\": \"0x80ac24aA929eaF5013f6436cdA2a7ba190f5Cc0b\"\n },\n \"8453\": {\n \"address\": \"0x660975730059246A68521a3e2FBD4740173100f5\"\n },\n \"42161\": {\n \"address\": \"0x41CA7586cC1311807B4605fBB748a3B8862b42b5\"\n }\n }\n\nSource: Monad tokenlist, syrupUSDC, Github, June 8th, 2026\nLending\n\nMorpho – Largest lending protocol by TVL.\n\nNeverland – Monad-native, built on Aave v3 architecture. Accounts for a significant portion of native lending activity.\n\nGearbox\n\nEuler V2 – Deployed from day one with RedStone Oracle integration.\n\nCurvance – Monad’s lending layer for leveraged yield.\n\nFolks Finance (xChain) – Present on Monad (small in current snapshots).\n\nTownSquare – additional lending venue on Monad.\n\nDEXs\n\nUniswap V4\n\nPancakeSwap V3\n\nCurve\n\nBalancer\n\nKuru – Monad-native on-chain order book DEX with hybrid AMM design. Fully on-chain CLOB leveraging Monad’s low latency.\n\nLFJ (Trader Joe)\n\nRPC Node Services\nRPC node services on Monad include Alchemy, Ankr, Blockdaemon, BlockPI, Chainstack, dRPC NodeCloud, Dwellir, Envio, GetBlock, OnFinality, Quicknode, Spectrum, Tatum, thirdweb, Triton One, and Validation Cloud.\nOracles\n\nChainlink – CCIP live; Data Feeds and Data Streams expanding.\nRedStone – Primary oracle for multiple Monad-native protocols (Neverland, Euler, PerplTrade).\nPyth Network – Integrated for price feed data.\nSwitchboard, Stork, Band Protocol, Supra, API3 – Additional oracle infrastructure.\n\nCritically, over 86 Chainlink feeds are available on Monad, including market reference and exchange rate feeds, which are used in Aave pricing schemas.\nWallets\nSupported wallet types:\n\nSoftware: Phantom, Atomic Wallet, Backpack, Binance Wallet, Bitget Wallet, HaHa, Keplr, MetaMask, OKX Wallet, Rabby Wallet, Safepal, and Trust Wallet\nHardware: Ledger, Safepal, and Tangem\nInstitutional: Porto by Anchorage Digital and Utila\n\nToolkits\nFoundry, Hardhat, and Solonet are currently supported development toolkits.\nIndexers\n\nCommon data: Allium, Birdeye Data Services, Codex, Dune Sim, GoldRush (by Covalent), Goldsky, Mobula, Moralis, Quicknode, Rarible, Sequence, SQD, SonarX, thirdweb, Unmarshal, Zerion.\nSmart contract indexers: Envio, Birdeye Data Services, Codex, Dune Sim, GoldRush (by Covalent), Goldsky, Mobula, Moralis, Quicknode, Rarible, Sequence, SQD, SonarX, thirdweb, Unmarshal, Zerion, The Graph\n\n2.2 Liquidity Landscape\n\nProtocol\nPairs\n\nUniswap v4\nAUSD/USDC ($3.9M), MON/AUSD ($3.8M), WBTC/MON ($3.6M), MON/USDC ($2.6M), MON/WETH ($2.5M), USDC/WETH ($1.4M), USDC/cbBTC ($1.3M)\n\nCurve\ncbBTC/WBTC/LBTC ($5.5M), AUSD/USDC/USDT0 ($3.4M), shMON/WMON/sMON/gMON ($615K), WBTC/LBTC/BTC.b ($273.1K)\n\nBalancer\nwnUSDT0/wnAUSD/wnUSDC ($17.1M), syzUSD/wnAUSD ($625.9K), wnWMON/wnSHMON ($133.6K), wnSMON/wnWMON ($126.5K), wnGMON/wnWMON ($118.2K)\n\nDepth is concentrated in a handful of core pools on Uniswap v4, Curve, and Balancer, with a steep drop-off outside the top tier and limited redundancy across venues. This structure can support routine trading, but liquidation capacity at scale is constrained by pool-specific depth and the risk that activity bottlenecks through the same few routes during volatility.\nIt should be noted that the lion’s share of Balancer liquidity is in a single Wrapped Neverland pool (LP tokens), along with the remaining pairs with meaningful liquidity.\n2.3 Ecosystem Resilience\nAs an independent L1, Monad’s security model differs from L2 deployments. It does not inherit Ethereum’s security and must maintain its own validator set and economic security. Key points:\n\nMonadBFT requires >2/3 honest stake weight. With 200 validators reported, the set is reasonable for a chain at this stage of its mainnet history but remains relatively untested under adversarial conditions.\nThe optimistic parallel execution model is architecturally novel. While audited and open-source, production edge cases may still surface.\nTVL concentration in a small number of protocols (Uniswap, Curve, and Neverland account for a majority) means ecosystem resilience is tied to the health of these deployments.\nThe open-source codebase (GPL-3.0) is a positive signal for auditability, as it allows independent parties to review, reproduce, and test client behavior.\n\n2.4 Ecosystem Growth Potential\nMonad is positioned as a high-throughput, EVM-compatible L1 that reduces integration friction for Ethereum-native applications and tooling. Monad chain supports full EVM bytecode compatibility and performance targets around 10,000 TPS with sub-second finality and very short block times (0.4 seconds per block), which expands the feasible design space for money markets and liquidation infrastructure that are otherwise constrained by latency and throughput.\nA relevant consideration is the observed user drop-off after the initial launch period. On-chain activity indicators show an early spike followed by a step-down to a lower, more stable baseline, consistent with incentive- or novelty-driven activation that did not persist at initial levels. This increases reliance on a narrower set of power users and integrated applications for borrow demand, liquidation flow, and arbitrage, and raises sensitivity to changes in incentive schedules and venue-specific liquidity programs.\nThe network’s native gas token and staking asset, MON, implies a gas-economics model that is not dependent on ETH for fee payment. On ecosystem formation, Monad Foundation has disclosed an application-focused incentive matching program (Monad Momentum) aimed at retention and revenue metrics and tokenomics messaging that earmarks a material allocation for ecosystem development.\n2.5 Major and Native Asset Outlook\nMonad’s asset base is currently stablecoin-heavy, with ~$425.7m in stablecoin supply and 57.32% USDC dominance. Stablecoin float is large relative to DeFi TVL, implying a meaningful share of liquidity sits outside tracked DeFi venues rather than being intermediated on-chain.\nExternally bridged inventory totals ~$600m, led by USDC (~$254m) and USDT0 (~$87m), with additional sizeable balances in major-asset derivatives such as wstETH (~$53m) and wrapped BTC variants including cbBTC (~$16m) and WBTC (~$9m). Native MON liquidity is not the primary driver of balance-sheet size at this stage; the effective risk footprint is therefore driven by stablecoin rails and ETH/BTC derivative liquidity and their ability to absorb stress flows.\n2.6 Tokenomics\nimage858×679 81.3 KB\nSource: Monad tokenomics, Monad docs, 2026\nMonad states an initial supply of 100,000,000,000 MON and states the token will be inflationary via ongoing issuance to validators, with a fee-burning mechanism that can partially offset issuance depending on realized network fee volume. The published initial allocation framework assigns 38.5% to ecosystem development, 27.0% to the team, 19.7% to investors, 7.5% to a public sale, 4.0% to the Category Labs treasury, and 3.3% to an airdrop.\nThe dominant tokenomics risks are multi-year dilution and unlock overhang from large non-circulating insider and ecosystem allocations, plus discretionary distribution risk from the ecosystem budget; secondary uncertainty is the steady-state inflation outcome because the net supply path depends on usage-driven fee burn versus protocol issuance and staking participation.\n3. Onchain discoverability\nMonad maintains its official block explorer for real-time transaction, block, and validator monitoring. MonadScan, built by Etherscan via its Explorer-as-a-Service program, provides the standard Etherscan interface with contract verification and developer APIs. Additional explorers include SocialScan and MonadVision.\nNetwork traceability is available on DefiLlama, Dune Analytics, Nansen, and Token Terminal.\n4. Access Control\nNetwork-level operations, upgrades, and administrative bounds are handled by the core client source code running on local validator nodes. Upgrades (such as modifying gas token costs, changing virtual machine specifications, or implementing new cryptographic precompiles) are managed via coordinated Software Releases. Revisions on Monad, commonly known as hard/soft forks on other chains, are coordinated with future timestamp activations. This allows validators to choose to accept the revision and upgrade ahead of time. Once the scheduled upgrade timestamp is reached, a supermajority of validators transition to the new behavior simultaneously, allowing the chain to upgrade without interruption.\nAs stated in section 1.2, Monad Revisions are effectively controlled by Category Labs, thus centralizing access control of the network with the engineering team behind Monad.\nThe MONAD_NINE upgrade (March 2026) represents the first major governance action post-mainnet, covering EVM memory cost changes (MIP-3), reserve balance checks (MIP-4), and Ethereum Fusaka compatibility (MIP-5). Mainnet change logs can be found here.\n5. Impact of AAVE Deployment\nThe primary risks to Aave on Monad are linked to execution and finality assumptions under stress and to the operational dependencies introduced by cross-chain rails and oracle selection. Monad markets itself as a high-performance, EVM-compatible L1 with parallel execution and sub-second deterministic finality; in practice, parallelism is workload-dependent and degrades when many transactions contend for the same state, which is a relevant failure mode for liquidation-heavy periods where activity concentrates around a small set of collateral and liquidation contracts. Monad’s own materials also distinguish deterministic finality at two slots, which is a direct input into liquidation timing assumptions and MEV-driven execution quality.\nThe network has established core infrastructure categories required for an Aave deployment. Monad’s infrastructure directory lists multiple oracle providers that are active in the ecosystem, including API3, Band Protocol, Blocksense, Chainlink, Chainsight, Chronicle, Pyth Network, RedStone, Stork, Supra, Switchboard, Terminal 3, UMA Protocol, and others; for Aave this creates optionality but also makes oracle standardization and operational dependency mapping a first-order design input because risk quality becomes feed- and operator-specific.\nOn bridging, Monad operates a native bridge interface that is powered by Wormhole, and Wormhole states that the bridge uses Wormhole NTT together with Axelar General Message Passing as infrastructure to move assets such as MON and ETH between Monad and Ethereum. This implies that a meaningful share of initial asset inflows and potential stress outflows are coupled to Wormhole and Axelar liveness and security assumptions.\nLiquidity depth remains a gating factor for liquidation efficiency and bad-debt outcomes. At launch, the “Aave effect” can itself attract incremental liquidity and accelerate TVL growth, but this effect is not guaranteed to translate into durable secondary-market depth at later stages. Current liquidity indicates meaningful balance-sheet capacity on the chain, but it does not by itself guarantee resilient secondary-market depth in the specific collateral venues liquidators rely on during fast repricings. In this context, supply caps and asset selection would typically be the main control surface to align liquidation feasibility with observed venue depth and oracle coverage, at the cost of constraining early revenue potential.\n6. Asset suggestions\n6.1 Overview\nIndividual asset-level risk reviews for each asset will be published in a follow-up post.\n6.2 Asset parameters\nGeneral Configuration\n\nParameter\nUSDT0\nUSDC\nGHO\nUSDe\nmUSD\nAUSD\nwETH\ncbBTC\nwstETH\nweETH\nsyrupUSDC\nsUSDe\n\nBorrowable\nYes\nYes\nYes\nYes\nYes\nYes\nNo\nNo\nNo\nNo\nNo\nNo\n\nCollateral enabled\nYes\nYes\nYes\nNo\nNo\nNo\nYes\nYes\nNo\nNo\nNo\nNo\n\nSupply Cap\n100,000,000\n75,000,000\n20,000,000\n60,000,000\n100,000,000\n20,000,000\n40,000\n1,000\n35,000\n30,000\n40,000,000\n60,000,000\n\nBorrow Cap\n100,000,000\n50,000,000\n18,000,000\n50,000,000\n50,000,000\n18,000,000\n36,000\n-\n-\n-\n-\n-\n\nDebt Ceiling\n-\n-\n-\n-\n-\n-\n-\n-\n-\n-\n-\n-\n\nLTV\n75.00%\n75.00%\n75.00%\n-\n-\n-\n80.50%\n73.00%\n-\n-\n-\n-\n\nLT\n78.00%\n78.00%\n78.00%\n-\n-\n-\n84.00%\n78.00%\n-\n-\n-\n-\n\nLiquidation Bonus\n7.50%\n7.50%\n7.50%\n-\n-\n-\n5.50%\n7.00%\n-\n-\n-\n-\n\nLiquidation Protocol Fee\n10%\n10%\n10%\n10%\n-\n-\n10%\n10%\n10%\n10%\n10%\n10%\n\nVariable Base\n0.0%\n0.0%\n0.0%\n0.0%\n0.0%\n0.0%\n0.00%\n-\n-\n-\n-\n-\n\nVariable Slope1\n4.0%\n4.0%\n4.0%\n4.0%\n4.0%\n4.0%\n2.20%\n-\n-\n-\n-\n-\n\nVariable Slope2\n40.0%\n40.0%\n40.0%\n40.0%\n40.0%\n40.0%\n20.0%\n-\n-\n-\n-\n-\n\nUoptimal\n90.0%\n90.0%\n90.0%\n90.0%\n80.0%\n80.0%\n90.0%\n-\n-\n-\n-\n-\n\nReserve Factor\n10.0%\n10.0%\n10.0%\n25.0%\n10.0%\n10.0%\n15.0%\n-\n-\n-\n-\n-\n\nStable Borrowing\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\n\nFlashloanable\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\n\nE-Mode\n1, 2, 3\n1, 2, 3\n1, 2, 3\n1, 2, 3\n1\n1, 2, 3\n4, 5\n-\n4\n5\n1\n2\n\nE-Mode 1: Maple syrupUSDC\n\nParameter\nValue\n\nIsolated\nFalse\n\nLTV\n90.00%\n\nLT\n92.00%\n\nLiquidation Bonus\n4.00%\n\nAsset\nsyrupUSDC\nUSDT0\nUSDC\nGHO\nmUSD\nAUSD\n\nCollateral\nYes\nNo\nNo\nNo\nNo\nNo\n\nBorrowable\nNo\nYes\nYes\nYes\nYes\nYes\n\nE-Mode 2: Liquid Leverage\n\nParameter\nValue\n\nIsolated\nFalse\n\nLTV\n90.00%\n\nLT\n92.00%\n\nLiquidation Bonus\n4.00%\n\nAsset\nsUSDe\nUSDe\nUSDT0\nUSDC\nGHO\nAUSD\n\nCollateral\nYes\nYes\nNo\nNo\nNo\nNo\n\nBorrowable\nNo\nNo\nYes\nYes\nYes\nYes\n\nE-Mode 3: Lido Yield Maximiser\n\nParameter\nValue\n\nIsolated\nTrue\n\nLTV\n94.00%\n\nLT\n96.00%\n\nLiquidation Bonus\n1.00%\n\nAsset\nwstETH\nwETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nE-Mode 4: EtherFi Yield Maximiser\n\nParameter\nValue\n\nIsolated\nTrue\n\nLTV\n93.00%\n\nLT\n95.00%\n\nLiquidation Bonus\n1.00%\n\nAsset\nweETH\nwETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nLiquidity Requirements\nThe liquidity requirement for each proposed asset is defined as exit (swap) liquidity available on-chain, not total value locked. Each requirement is sized as a cover ratio applied to the asset’s supply cap: 10% across the general asset set, 5% for wstETH and weETH (collateral only within E-Mode against wETH). Swap depth is measured along the path a liquidator would realistically execute: stablecoins stable-to-stable, LSTs to wETH, and other volatile assets to the deepest available stablecoin.\n\nAsset\nSupply cap\nCap (USD)\nCover ratio\nRequired exit liquidity\n\nUSDT0\n100,000,000\n100.00M\n10%\n10.00M\n\nUSDC\n75,000,000\n75.00M\n10%\n7.50M\n\nGHO\n20,000,000\n20.00M\n10%\n2.00M\n\nUSDe\n60,000,000\n60.00M\n10%\n6.00M\n\nmUSD\n100,000,000\n100.00M\n10%\n10.00M\n\nAUSD\n20,000,000\n20.00M\n10%\n2.00M\n\nsyrupUSDC\n40,000,000\n40.00M\n10%\n4.00M\n\nsUSDe\n60,000,000\n60.00M\n10%\n6.00M\n\nwstETH\n35,000\n72.01M\n5%\n3.60M\n\nweETH\n30,000\n54.51M\n5%\n2.73M\n\nwETH\n40,000\n66.35M\n10%\n6.64M\n\ncbBTC\n1,000\n61.76M\n10%\n6.18M\n\nTotal\n\n729.63M\n\n~66.64M\n\nDisclaimer\nThis review was independently prepared by LlamaRisk, a community-led non-profit decentralized organization funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n post by LlamaRisk on Jun 11\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Introduction\nThis analysis covers the proposed assets for the initial listing on Monad, specifically cross-chain assets already listed on Aave instances. This review provides an overview of key aspects, including chain-specific characteristics, bridging infrastructure, contract implementations, access control, liquidity, and other risk-related factors.\nComparative table\n\nAsset\nIssuance\nBridge / DVN setup\nRate Limits\nToken Upgradeable\nCritical Control\nTimelock\nKey Flag\n\nUSDT0\nBridged (lock-and-mint vs ETH)\nLayerZero OFT, 3 DVNs (USDT0, LZ Labs, Canary)\nNone\nProxy admin renounced\nSafe 3/5 (owner, both sides)\nNo\nNo bridge rate limits\n\nUSDC\nNative Mint & bridgeable via CCTP\nCCTP (burn/mint); bridge contracts EOA-owned\n10M per message(burn cap)\nYes (FiatTokenProxy via EOA)\nOwner, pauser, master minter, local minter, blacklister\nNo\nCritical roles on EOAs, upgrade path EOA-owned\n\nmUSD\nBridged (Wormhole NTT infra, hub-and-spoke)\nSpokePortal → HyperlaneBridgeAdapter\nNone\nYes, ProxyAdmin → TimelockController 2\nTimelock 1 → 3/5 Safe (admin, upgrades); freeze/forced-transfer roles on EOAs\nYes 72h, (admin + upgrades)\nSeizure roles on EOAs, outside timelocks\n\nAUSD\nBridged (LZ OFT mint/burn)\nLayerZero OFT, 5 DVNs (DT, Horizen, Frax, Canary, Nethermind)\n5M / 4h both directions\nYes, ProxyAdmin → EOA\nAll roles (admin, minter, burner, freezer, upgrade) on EOAs\nNo\nEntire stack EOA-controlled incl. upgrades\n\nWETH\nBridged (Wormhole MultiTokenNTT, hub-and-spoke)\nWormhole NTT, 2/2 transceiver threshold\nNone (limits set to 0, uncapped)\nNon-upgradeable (ERC1967 proxy with empty admin slot; no upgrade function exposed)\nWormhole Governance contract\nN/A\nNo rate limits; immutable token is a plus\n\ncbBTC\nBridged (CCIP burn/mint, locked on Base)\nChainlink CCIP, OCR DON + RMN\n25 in / 27.5 out per 24h\nYes, ProxyAdmin → RBACTimelock\nRBACTimelock throughout (token, pool, router, ramps)\n3h\nDifferent impl. than Base/Core listings (Chainlink ERC20, not FiatToken)\n\nwstETH\nBridged (CCIP lock/release ↔ burn/mint)\nChainlink CCIP\n~2,200 in / 2,000 out per 24h\nYes, ProxyAdmin → RBACTimelock\nRBACTimelock throughout\n3h\nMinimal liquidity\n\nweETH\nBridged (LZ OFT, locked on mainnet)\nLayerZero OFT, 4 DVNs (LZ Labs, Canary, Nethermind, Horizen)\nPeer-specific limits\nYes, ProxyAdmin → EtherFiTimelock\nEtherFiTimelock; mainnet adapter behind 4/8 Safe\n3d\nMinimal liquidity\n\nsyrupUSDC\nBridged (CCIP lock/release ↔ burn/mint)\nChainlink CCIP (same infra as wstETH)\n~9.48M in / 8.62M out per 24h\nNon-upgradeable\nGovernorTimelock (token), RBACTimelock (CCIP)\n24h\nNo supply, no liquidity\n\nUSDe / sUSDe\nBridged (LZ OFT mint/burn)\nLayerZero OFT, 4 DVNs (Horizen, LayerZero Labs, Canary, and Nethermind)\nPeer-specific limits\nNon-upgradeable\nEthena 5/10 Multisig\nNo\nNo supply, no liquidity\n\nAssets\nUSDT0\nUSDT0 is a cross-chain version of Tether’s standard USDT stablecoin, deployed as an OpenZeppelin TransparentUpgradeableProxy contract that uses the TetherTokenOFTExtension. The implementation contract extends the TetherTokenV2 contract, adding cross-chain functionality. To mint and burn bridged USDT0, the OFT contract uses LayerZero to send and receive cross-chain messages.\nThe asset is bridged via a lock-and-mint model, in which the underlying USDT is backed by locked supply on the Ethereum network. At the time of writing, 87M USDT0 has been bridged to Monad, with bridging enabled from all OFT-enabled chains.\nThe asset is already listed on other Aave instances, following the exact implementation on other chains, such as Plasma and Mantle. The implementation does not introduce any additional risks relative to the asset’s existing listings on Aave.\nBridge Configuration\nUSDT0 on Monad uses only the native bridge 3 DVNs setup, which consists of USDT0, LayerZero Labs, and Canary (as opposed to a dual design that includes the legacy mesh bridge). USDT0 doesn’t implement any rate limits for bridge transfers.\nAccess Control\nWhile deployed behind a TransparentUpgradeableProxy, the contract’s proxy admin has been set to a 0x000 address, indicating that admin privileges have been renounced. The zero address cannot call the upgradeTo function nor reassign the proxy admin.\nThe owner of the oftContract and USDT0 contract on Monad is set to a 3/5 Multisig via OpenZeppelin Ownable.\nSensitive functions exposed by the contracts include:\n\nsetOFTContract: Sets the address that can mint/burn cross-chain in TetherTokenOFTExtension. Owner only.\nupdateNameAndSymbol: Changes token name and symbol in TetherTokenOFTExtension. Owner only.\ncrosschainMint/Burn: OFT Contract Only.\ntransferOwnership: Transfers ownership to a new address. Owner access only.\nrenounceOwnershipRenounces ownership, leaving the contract without an owner. Owner access only.\n\nUpgradable\nAccess Control\nMinter and Burner\nLocked funds on mainnet\nUpgradable Locked funds\nLocked funds access Control\n\nProxy admin Renounced\nownable: Safe 3/5\nOFT Contract\nOFTAdapterUpgradable\nProxy Admin → Safe 3/5\nOwnable: Safe 3/5\n\nLiquidity\nUSDT0 liquidity on Monad is currently concentrated in a Curve 3pool, with the top 5 pools representing a total TVL of less than $5M.\n\nDEX\nPool\nTVL\n\nCurve\nAUSD/USDC/USDT0\n$3.2M\n\nLFJ V2.2\nAUSD / USDT0\n$115.23K\n\nLFJ V2.2\nUSDT0 / USDC\n$146.84K\n\nUniswap\nWBTC / USDT0\n$30.83K\n\nUniswap\nAUSD / USDT0\n$18.4K\n\nPrice Feed Recommendation\nFor USDT0 pricing, we recommend using the USDT/USD Chainlink price feed with the CAPO stable adapter, consistent with other USDT0 onboardings such as Plasma.\nCAPO Configuration\nThe stable cap adapter is recommended to bound the upward price deviation at 4% ($1.04). This is in line with stablecoins on other markets.\nUSDC\nCircle’s USDC on Monad is deployed as an upgradable ERC20 FiatTokenProxy contract that uses the FiatTokenV2_2 implementation contract. Version 2.2 inherits from FiatTokenV2_1, FiatTokenV2, and FiatTokenV1. USDC is natively minted on Monad, with Circle Mint enabling minting and bridging via CCTP on Monad. Redemptions through Circle Mint are accessible only to qualified persons/businesses. The token’s design is consistent with other chains where USDC is listed on Aave.\nAt the time of writing, ~228M USDC has been minted on Monad. The implementation does not introduce any additional risks compared to the asset’s existing listings on Aave.\nBridge Configuration\nUSDC is bridgeable to and from Monad via CCTP. The bridge contractTokenMessengerV2is deployed behind AdminUpgradableProxy. TokenMessengerV2 utilizes a burn and mint mechanism.\nAccess Control\nThe contract uses an ownable pattern, which allows the owner to set the master minter, pauser, blacklister, and rescuer addresses. The FiatTokenV2_2 itself declares no new roles, inheriting them from the Ownable, Pausable, and Blacklistable contracts and the FiatTokenV1 contract.\nUSDC exposes the following roles and sensitive functions:\n\nOwner: The only role that can assign and reassign other admin roles. Inherited from Ownable. Set to EOA __(__26e0).\n\nCan call updateRole and transferOwnership of the owner role.\n\nPauser: Contract pausing role, inherited from Pausable. Set to EOA (e8Ea).\n\nCan pause / unpause transfers and approvals.\n\nMasterMinter: Controls the minter registry and allowances, inherited from the FiatTokenV1.\n\nCan call configureMinter to add/update minters and removeMinter.\n\nMinters: Minter-assigned addresses inherited from FiatTokenV1. Current minters include TokenMinterV2, EOA (4826), EOA (597a), EOA (0A8e), EOA (A794), EOA (04A7), and EOA (677c).\n\nCan call mint up to the addresses’ minting allowance and burn against their own balance.\n\nBlacklister: Address that can black list accounts from receiving/transferring USDC. Inherited from. Set to EOA (D6cd).\n\nMasterMinter roles:\n\nOwner: Authority to trigger configurations of controllers and allowances. Assigned to EOA (a0E6).\nControllers: Per-minter allowance managers.\nThe MasterMinter contract is owned by EOA __(__a0E6)\n\nThe bridge contract exposes the following roles (TokenMessengerV2):\n\nRescuer: Can retrieve sent USDC. Assigned to EOA (91a1).\nDenylister: Blocks bridge entry per address. Assigned to EOA (5b66).\nFeeRecipient: Receives fees. Assigned to EOA (6379).\nMinFeeController: Adjusts the min fee. Assigned to EOA (9AE2).\nLocalMinter: The bridge’s mint authority is assigned to TokenMinterV2.\nOwner: can call upgradeTo, addRemoteTokenMessenger, removeRemoteTokenMessenger, setLocalMinter, setFeeRecipient. Assigned to EOA (4a47).\n\nTokenMinter roles:\n\nTokenController: owner equivalent that can callsetMaxBurnAmountPerMessage, addLocalTokenMessenger, and pause/unpause the contract. Assigned to EOA (e69C).\nPauser: Independent pause from TokenMessengerV2. Assigned to EOA (1fBb).\nLocalTokenMessenger: authorized to call mint/burn on TokenMinter. Assigned to TokenMessengerV2.\n\nA per-transaction burn cap is applied with maxBurnAmountPerMessage on TokenMinterV2. This sets the maximum a single burn operation can process - currently set to 10M USDC.\n\nUpgradable\nAccess Control\nMinter and Burner\nLocked funds on mainnet\nUpgradable Locked funds\nLocked funds access Control\n\nEOA (c619)\nowner: EOA (26e0)\nnative bridge:TokenMessengerV2 whitelister: MasterMinter\n-\n-\n-\n\nLiquidity\n\nDEX\nPool\nTVL\n\nUniswap\nAUSD / USDC\n$3.88M\n\nCurve\nAUSD/USDC/USDT0\n$3.2M\n\nLFJ V2.2\nAUSD / USDC\n$2.43M\n\nUniswap V4\nWMON / USDC\n$2.15M\n\nUniswap V3\nWMON/USDC\n$1.3M\n\nUniswap\nUSDC / WETH\n$1.24M\n\nPrice Feed Recommendation\nFor USDC pricing, we recommend using the USDC/USD Chainlink price feed with the CAPO stable adapter, consistent with other USDC onboardings such as Mantle.\nCAPO Configuration\nThe stable cap adapter is recommended to bound the upward price deviation at 4% ($1.04). This is in line with stablecoins on other markets.\nUSDe & sUSDe\nUSDe and sUSDe on Monad are deployed as non-upgradeable OFT contracts and use the standard OFT ERC20 token implementation. Both contracts have no proxy pattern and no upgrade functions exposed. StakedUSDeOFT extends USDeOFT , adding a blacklist mechanism on top of the inherited OFT and rate limit logic. The token and OApp are the same contract for both assets. This implementation is similar to that of other instances, such as Plasma. At the time of writing, neither asset had a circulating supply on Monad.\nBridge Configuration\nBoth assets bridge via LayerZero OFT. The OApp configuration uses a 4/0 DVN setup with required DVNs including: Horizen, LayerZero Labs, Canary, and Nethermind.\nAccess Control\nUSDeOFT and StakedUSDeOFT share the same role structure inherited from OFTOwnable2Step:\n\nOWNER: Controls all sensitive functions, including setPeer, setDelegate, setRateLimiter, setRateLimits, and setBlackLister (sUSDe only). Two-step ownership transfer pattern. Assigned to 5/10 Safe.\nRATE_LIMITER: Can call setRateLimits to adjust per chain outbound caps. Owner-controlled\n\nStakedUSDeOFT adds:\n\nBLACKLISTER: Can call updateBlackList to blacklist/unblacklist addresses. Blacklisted recipients on inbound transfers have funds redirected to the owner. Owner-controlled.\n\nUpgradable\nAccess Control\nMinter and Burner\nLocked funds on mainnet\nUpgradable Locked funds\nLocked funds access Control\n\n-\nowner: 5/10 Safe\nStakedUSDeOFT & USDeOFT\nUSDeOFTAdapter & StakedUSDeOFTAdapter\n-\nowner: Ethena 5/10 Safe\n\nLiquidity\nUniswap USDe/USDT and sUSDe/USDe pools are planned to be introduced. Onboarding for this asset should be contingent on the necessary liquidity being deployed to these pools.\nPrice Feed Recommendation\nFor USDe, we recommend pricing USDe using the Chainlink USDT/USD feed, covered via a stable cap adapter.\nFor sUSDe, we recommend using the Chainlink sUSDe/USDe exchange rate with a CAPO adapter, and using the USDe CAPO stable adapter as the base price.\nThese implementations are consistent with the approach adopted across all Aave instances for USDe-denominated assets.\nCAPO Configuration\nThe stable cap adapter is recommended to bound the upward price deviation at 4% ($1.04). This is in line with stablecoins on other markets.\nsUSDe’s yield has been compressing recently, operating within a 2-10% band since June 2025. We recommend setting Snapshot Delay at 7 days, providing sufficient smoothing against short-term volatility, with maxYearlyGrowthRatio at 11.17%.\nimage1561×504 82 KB\nSource: sUSDe Historical APY, Dune, June 24, 2026\n\nmaxYearlyRatioGrowthPercent\nMINIMUM_SNAPSHOT_DELAY\n\n11.17%\n7 days\n\nmUSD\nmUSD is MetaMask’s USD stablecoin, deployed as an OpenZeppelin TransparentUpgradeableProxy contract that uses the MUSD implementation contract. The token is bridged using a hub and spoke, with the implementation contract inheriting from the base MExtension contract, which wraps and unwraps the underlying $M tokens backing mUSD (via the SwapFacility contract). The implementation contract adds governance and compliance features, such as pausing, role-based access control, and the ability to seize tokens from frozen accounts.\nThe asset is already listed on Aave’s Core and Linea markets, using the same MUSD implementation contract. At the time of writing, ~503K mUSD are currently circulating on Monad.\nBridge Configuration\nmUSD on Monad uses M0’s native hub and spoke bridging architecture, leveraging Wormhole’s cross-chain messaging infrastructure, Native Token Transfers (NTT). Ethereum acts as the hub, with $M being bridged via a lock/release mechanism. Monad as the spoke chain operates $M minting and burning via a SpokePortal contract, which is then wrapped to originate mUSD. Cross-spoke transfers are gated behind a crossSpokeTokenTransferEnabled parameter, while hub-spoke bypasses this check.\nThere are no rate-limiting parameters in the Portal base contract. No inbound or outbound transfer limits are defined or enforced, and transfer volume is bounded only by the crossSpokeTokenTransferEnabled flag and supported bridging path configuration. Message delivery is handled by the bridge adapter - HyperlaneBridgeAdapter.\nAccess Control\nmUSD employs OpenZeppelin’s role-based access control framework to manage sensitive functions, with the Monad setup mirroring the existing Ethereum and Linea setups.\nThe mUSD contract exposes the following roles:\n\nDEFAULT_ADMIN_ROLE: can grant and revoke all other roles (superadmin). Assigned to TimelockController 1.\n\nTimelockController is assigned the TL DEFAULT_ADMIN_ROLE\n3/5 Multisig (3b04) is assigned the TL CANCELLER_ROLE, EXECUTOR_ROLE, and PROPOSER_ROLE\n\nPAUSER_ROLE: Pauses/unpauses all wraps, unwraps, and mUSD transfers. Assigned to 2/3 Multisig (c8f3) and M0: Deployer.\nFREEZE_MANAGER_ROLE: Freeze/unfreeze accounts. Assigned to EOA (A464) and EOA (5246).\nFORCED_TRANSFER_MANAGER_ROLE: Seizes tokens from frozen accounts. Assigned to EOA (5246).\nYIELD_RECEIPT_MANAGER_ROLE: Can trigger yield claims and set the recipient address. Assigned to 3/7 Multisig (4E6c) and EOA (5fbf)\n\nThe SpokePortal is deployed as an ERC1967 proxy, with the contract following a UUPS upgrade pattern. Upgrades are executed via upgradeToAndCall. Three roles are defined:\n\nDEFAULT_ADMIN_ROLE: Can grant/revoke roles, and call upgrades. Assigned to a 3/5 Safe.\nPAUSER: Can pause the portal’s inbound and outbound transfers of $M token transfers. Assigned to EOA (40BB).\nOPERATOR_ROLE: Controls bridge configuration. Can call enableCrossSpokeTokenTransfer to open $M flows between spoke chains. Assigned to EOA (40BB).\n\nThe SwapFacility contract, which is critical for the underlying $M backing, exposes the following roles and sensitive functions:\n\nDEFAULT_ADMIN_ROLE: sets Extensions and M Swapper contracts. Assigned to 3/5 Multisig (9d19).\nPAUSER_ROLE: Can pause/unpause swap paths. Assigned to M0: Deployer.\nM_SWAPPER_ROLE: wraps M into any extension (non-rebasing ERC20) or unwraps back to M. Assigned to SpokePortal.\n\nUpgradable\nAccess Control\nMinter and Burner\nLocked funds on mainnet\nUpgradable Locked funds\nLocked funds access Control\n\nProxyAdmin → TimelockController 2\nTimelockController 1 → 3/5 Multisig (3b04)\n__SpokePortal __→ HyperlaneBridgeAdapter\nHubPortal\nTimelock\nowner: Timelock\n\nTimelocks employ a 3-day minimum delay.\nLiquidity\n\nDEX\nPool\nTVL\n\nUniswap\nmUSD / USDC\n$1.5K\n\nPrice Feed Recommendation\nWe recommend using a fixed feed for mUSD pegged at $1.\nAUSD\nAgora USD on Monad is issued behind AgoraDollarErc1967Proxy, an upgradeable proxy contract that uses the OpenZeppelin transparent proxy pattern. The implementation contract references the AgoraDollar contract, which inherits from the AgoraDollarCore contract functionalities. AUSD is bridged using LayerZero’s OFT Adapter and supports ERC3009 for gasless token transfers and ERC2612 for approvals via signatures.\nThe asset is already listed on Aave’s Avalanche instance, but it is the natively issued implementation. The bridging mechanism adheres to LayerZero’s OFT standards. The implementation and bridging architecture does not introduce any additional risks. At the time of writing, 32.8M AUSD is currently circulating on Monad.\nBridge Configuration\nThe AgoraMintBurnOFTAdapter contract uses the OFT standard to bridge AUSD, using a burn and mint mechanism. Its functionality includes standard cross-chain messaging and rate-limit capabilities. The OApp configuration uses a 5/0 DVN setup comprising Deutsche Telekom, Horizen, Frax, Canary, and Nethermind.\nAUSD implements rate limits for bridge transfers. The current rate limit is set to 5 M AUSD for both inbound and outbound within a 4-hour window.\nAccess Control\nAUSD uses a 2-layered role-based access control system that delegates role management. The Monad roles consist of the access control manager, pauser, and rate limit manager. These roles enable holders to:\n\nACCESS_CONTROL_MANAGER: can grant and revoke every other role and controls contract upgrade logic functions, which include access to setIsTransferUpgraded, setIsTransferFromUpgraded, setIsTransferWithAuthorizationUpgraded, and setIsReceiveWithAuthorizationUpgraded. Assigned to EOA (30e2)\nPAUSER: can pause/unpause the token operations. Assigned to EOA (2a25)\nMINTER: can mint AUSD. Assigned to EOA (d7ff)\nBURNER: Can unilateral burn tokens. Assigned to EOA (dC1D)\nRATE_LIMIT_MANAGER: controls the mintable limits on Monad. Assigned to EOA (d6dc)\nFREEZER: can freeze accounts, blocking any transfers. Assigned to EOA (4681)\nBRIDGE_MINTER: Bridge permitted to mint on the Monad. Assigned to AgoraMintBurnOFTAdapter.\nBRIDGE_BURNER_ROLE: Bridge permitted to burn tokens on Monad. Assigned to AgoraMintBurnOFTAdapter.\n\nThe OFT adapter follows the same access-control pattern, with roles including: access-control manager, pauser, and rate-limiter manager.\n\nACCESS_CONTROL_MANAGER: Grants and revokes all other roles. Assigned to EOA (7570).\nPAUSER: Pauses all inbound and outbound bridging activity EOA (6498).\nRATE_LIMIT_MANAGER: Set max allowance per time window for inbound/outbound transfers. Assigned to EOA (3391).\nOWNER: Ownable permission that is separate from the role system. It controls who can configure the OApp endpoint level; these addresses have access to critically sensitive functions such as setDelegate, setPeer, and can call upgradeToAndCall (via the proxy admin). Assigned to EOA (7570)\n\nUpgradable\nAccess Control\nMinter and Burner\nFunds on source chain\nUpgradable Locked funds\nLocked funds access Control\n\n__ProxyAdmin __→ EOA (2528)\nRole assigned: EOA (30e2)\nAgoraMintBurnOFTAdapter owned by EOA (7570)\nAgoraMintBurnOFTAdapter\n-\n-\n\nLiquidity\n\nDEX\nPool\nTVL\n\nUniswap\nAUSD / USDC\n$3.88M\n\nCurve\nAUSD/USDC/USDT0\n$3.2M\n\nLFJ V2.2\nAUSD / USDC\n$2.43M\n\nUniswap\nWMON / AUSD\n$1.5M\n\nPrice Feed Recommendation\nFor pricing, we recommend using Chainlink’s AUSD/USD price feed.\nCAPO\nThe stable cap adapter is recommended to bound the upward price deviation at 4% ($1.04).\nWETH\nWETH is deployed behind an ERC1967 proxy; however, the proxy is effectively immutable. The contract exposes no external upgrade function, no proxy admin contract is recorded in the admin slot, and the only role present on the contract is minter. The implementation address, therefore, cannot be changed through any on-chain mechanism. The implementation itself is a Wormhole Token contract.\nAs with other bridged WETH instances onboarded, Wrapped ETH on Monad follows the same immutable pattern. At the time of writing, 7,759 WETH are currently circulating on Monad.\nBridge Configuration\nMonad WETH uses Wormhole’s MultiTokenNTT (Native Token Transfers) mechanism, a custom multi-token manager that enables bridging multiple assets within a single contract. For WETH, the NTT uses a hub-and-spoke design that locks tokens on the source ‘hub’ chain and mints the equivalent on ‘spoke’ chains, maintaining the total supply on the hub. ETH is wrapped and locked on mainnet before being transferred to Monad via the wrapAndTransferGasToken and IWETH.withdraw functions.\nCross-chain message routing and threshold attestations are handled by a GmpManager contract, which performs transfers using NttManagerMessage payloads and dispatches them to enabled transceivers. A 2/2 transceiver threshold is required for message attestations before execution.\nWETH rate limits for bridge transfers in both directions are currently set to 0, meaning there is currently no inbound or outbound rate limit set for WETH in the bridging contract.\nAccess Control\nWETH exposes no upgradeTo, upgradeToAndCall, or any admin-controlled upgrade functions. A single privileged role is exposed in the contract, minter, which is assigned to the bridge address (MultiTokenNTT).\n\nMINTER: Can mint WETH to any address and transfer minter authority to any new address via setMinter.\n\nThe access control privileges exposed by the MultiTokenNTT contract include:\n\nOWNER: Controls all sensitive bridge functions, including upgrade, setPeer (configures trusted remote bridge addresses per chain), setOutboundLimit / setInboundLimit, overrideLocalAsset (remaps foreign token representations), and unpause. Assigned to the Wormhole Governance contract.\nPAUSER: Can call pause all transfers and minting. Only the owner can unpause the bridge after it has been paused. Assigned to the Wormhole Governance contract.\n\nThe GmpManager follows the same Owner and Pauser pattern, with its own owner controlling the setPeer function for trusted remote GmpManager addresses per chain and transceiver/threshold configuration. The owner controls the transceiver set and threshold independently. The Owner and Pauser are assigned to the Wormhole Governance contract.\n\nUpgradable\nAccess Control\nMinter and Burner\nLocked funds on mainnet\nUpgradable Locked funds\nLocked funds access Control\n\n-\n-\nMultiTokenNTT\nETHMultiTokenNtt\n-\nOwnable: Governance\n\nLiquidity\n\nDEX\nPool\nTVL\n\nUniswap\nWMON / WETH\n$1.44M\n\nUniswap\nUSDC / WETH\n$1.29M\n\nPrice Feed Recommendation\nWe recommend using the Chainlink ETH / USD Price Feed.\ncbBTC\nCoinbase BTC (cbBTC) on Monad is issued behind a TransparentUpgradeableProxy, the implementation points to BurnMintERC20PausableFreezableTransparent, which inherits from BurnMintERC20PausableTransparent.\nThe asset is already listed on Aave’s Base and Core instances, but doesn’t follow the same FiatToken implementation. The implementation introduces no additional risks beyond the asset’s existing listings on Aave, as it uses a standard Chainlink burn-mint ERC20 with pause and account-freeze capabilities. At the time of writing, the circulating supply on Monad is approximately ~161 cbBTC.\nBridge Configuration\ncbBTC uses Chainlink’s canonical cross-chain token standard. The proxy and token pool architecture is standard Chainlink infrastructure components, consisting of four primary contracts: a Router (entry point), a OnRamp contract at source, an OffRamp receiver, and a BurnMintTokenPool for mint/burn. On the Base chain source, the pool locks tokens, while the Monad pool mints. Inbound and outbound messages are routed using registered OnRamp and OffRamp contracts. The Monad BurnMintTokenPool contract uses a burn and mint mechanism when transferring cbBTC, acting as a middle layer between the onramp and offramp messages.\nMessage finality on the OffRamp is enforced via Merkle root commits signed by Chainlink’s OCR DON and optionally verified by RMN (Risk Management Network). The cbBTC rate limits for bridge transfers are currently set to 25.0 cbBTC for inbound transfers and 27.5 cbBTC for outbound transfers. Caps refill continuously at 0.00031828 cbBTC per second inbound and 0.00028935 cbBTC per second outbound, up to their respective capacities.\nAccess Control\nThe token uses OpenZeppelin’s role-based access control pattern. cbBTC’s roles and associated sensitive functions are as follows:\n\nDEFAULT_ADMIN_ROLE: Can grant and revoke all other roles. Assigned to RBACTimelock.\nMINTER_ROLE: Can mint cbBTC on Monad. Assigned to the BurnMintTokenPool contract.\nBURNER_ROLE: Can burn cbBTC. Assigned to the BurnMintTokenPool contract.\nPAUSER_ROLE: Can pause all token transfers, mints, and burns. Assigned to RBACTimelock.\nFREEZER_ROLE: Can freeze individual accounts, blocking transfers, mints, and burns to/from the frozen address. Freeze actions take effect even when the contract is paused. Assigned to RBACTimelock.\n\nA separateccipAdmin role allows the holder to register/deregister the token from the CCIP TokenAdminRegistry. Role has no minting or governance powers. Assigned to RBACTimelock.\nThe token pool contract uses an owner control system. The Monad pool is owned by RBACTimelock, allowing it to:\n\napplyChainUpdates / applyRampUpdates: add or remove supported chains and their associated on/off ramps.\nRate limit configuration, including capacity and refill rates per chain direction.\nsetRouter: update the local CCIP router reference.\nManage the pool’s allowlist, if whitelisting mode is enabled.\n\nThe Router uses a single-owner model. The owner assigned to RBACTimelock has controls over:\n\ncontrols applyRampUpdates (add/remove on-ramps and off-ramps) and\nsetWrappedNative. The whenHealthy modifier gates ccipSend and routeMessage on the ARM proxy not being in a cursed state.\n\nThe OnRamp/OffRamp uses a single owner control system (assigned to RBACTimelock).\n\nUpdate feeQuoter, messageInterceptor, and permissionLessExecutionThresholdSeconds(via setDynamicConfig)\napplySourceChainConfigUpdates: enable/disable source chains and update associated OnRamp addresses.\nOCR configuration (transmitter set, signer set, threshold) via setOCR3Configs.\n\nThe Timelock applies a 3-hour minimum delay.\n\nUpgradable\nAccess Control\nMinter and Burner\nLocked funds on Source\nUpgradable Locked funds\nLocked funds access Control\n\nProxyAdmin → RBACTimelock\nDEFAULT_ADMIN: RBACTimelock.\nBurnMintTokenPool\nLockReleaseTokenPool\n-\nOwnable: RBACTimelock\n\nLiquidity\n\nDEX\nPool\nTVL\n\nCurve\ncbBTC/WBTC/LBTC\n$4.1M\n\nUniswap\nUSDC / cbBTC\n$1.12M\n\nUniswap\nWBTC / cbBTC\n$713.44K\n\nUniswap\nWMON / cbBTC\n$130.57K\n\nPrice Feed Recommendation\nWe recommend using the cbBTC / USD Chainlink price Feed.\nwstETH\nwstETH is issued behind a TransparentUpgradeableProxy, the implementation is BurnMintERC20Transparent, a Chainlink-native contract that inherits AccessControlDefaultAdminRulesUpgradeable and ERC20BurnableUpgradeable. The asset is already listed on other Aave instances and follows the implementation as on other instances, such as MegaETH.\nBridge Configuration\nwstETH uses Chainlink’s canonical cross-chain token standard. wstETH is bridged via Chainlink CCIP using a Lock/Release pool on Ethereum and a Burn/Mint pool on Monad. As described in cbBTC, the proxy and token pool architecture uses the same Chainlink infrastructure components, and the implementation introduces no novel risk surface beyond what is inherent to CCIP.\nAt the time of writing, the circulating wstETH supply on Monad is 21,037. Rate limits for bridge transfers use CCIP’s token-bucket model. Inbound transfers have a capacity of ~2,200 wstETH, and outbound transfers have a capacity of ~2,000 wstETH. Each cap continuously refills at approximately 0.0255 wstETH per second inbound and 0.0231 wstETH per second outbound.\nAccess Control\nThe token uses the same role-based access control pattern as cbBTC, except for an additional mandatory time delay for DE","tokens":15000,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266351262,"hash":"0370728b7386df29f08cdf663f40fcf6189e57ba"}
{"url":"https://docs.base.org/specifications/base-protocol/design-goals","domain":"docs.base.org","title":"Design Goals - Base Documentation","text":"Our aim is to design a protocol specification that is:\n\nOpinionated: Simplicity through deliberate design choices. We identify the best solution and\ncommit to it.\nMaximally Simple: By focusing on just what Base needs, we radically simplify the stack. The\nprotocol spec and codebase should be understandable by a single developer.\nFast Cycles: We ship upgrades frequently rather than batching risk into infrequent large ones.\nWe target six smaller, tightly scoped hard forks per year on a regular cadence, with fortnightly\nreleases.\nEthereum Aligned: Base wins when Ethereum wins. We accelerate deployment of high-impact\nchanges ahead of L1 to provide data that informs the Ethereum roadmap.\n\n​Lineage\nBase Chain inherits Ethereum’s EVM semantics, transaction rules, and L1-anchored security. It was\noriginally built on the OP Stack. After the Jovian Hardfork, Base Chain follows this specification.Was this page helpful?Suggest editsRaise issue","tokens":236,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266370199,"hash":"f3b2372b759a7381291b16a455f2066ec0aacd7a"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/39","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 39 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by kz on Feb 1, 2018\n\n post by denett on Feb 2, 2018\n\n Load more posts below","tokens":957,"squid":"ink-research","role":"Deep Scholar","at":1791266372375,"hash":"96a4f5d63ab2aa42383fd5c55260134653856d4e"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/proof-contracts","domain":"docs.base.org","title":"Proof Contracts - Base Documentation","text":"The proof contracts turn offchain proof material into onchain checkpoint games. A game claims an\nL2 output root for a fixed block interval. The contracts verify the initial proof, accept an\noptional second proof, allow invalid proof material to be challenged or nullified, resolve the game\nafter the applicable delay, move the anchor state forward, and release the initialization bond.\nThis page specifies the contract behavior used by the proof system:\n\nAnchorStateRegistry\nDelayedWETH\nDisputeGameFactory\nAggregateVerifier\nZKVerifier\nTEEVerifier\nTEEProverRegistry\nNitroValidator\nCertManager\nP384Verifier\n\n​Contract Graph\n\nDisputeGameFactory, AnchorStateRegistry, DelayedWETH, and TEEProverRegistry are proxied\nsystem contracts. AggregateVerifier is deployed as an implementation and cloned by the factory\nwith immutable arguments. TEEVerifier and ZKVerifier are standalone proof verifiers referenced\nby the game implementation. The registry references a standalone NitroValidator, which uses\nCertManager and P384Verifier to validate signer attestations.\n​Data Model\nThe contracts share the same dispute-game types:\nTypeMeaningGameTypeA uint32 identifier for a dispute game implementation.ClaimA 32-byte root claim. In this proof system it is an L2 output root.HashA 32-byte hash wrapper.TimestampA uint64 timestamp wrapper.Proposal(root, l2SequenceNumber), where l2SequenceNumber is the L2 block number for the root.GameStatusIN_PROGRESS, CHALLENGER_WINS, or DEFENDER_WINS.ProofTypeTEE or ZK inside AggregateVerifier.\nThe AggregateVerifier game uses two block intervals:\nBlock IntervalsBLOCK_INTERVAL\nINTERMEDIATE_BLOCK_INTERVAL\n\nBLOCK_INTERVAL is the distance between a parent output root and a proposed output root.\nINTERMEDIATE_BLOCK_INTERVAL is the spacing between intermediate roots inside that range.\nBLOCK_INTERVAL and INTERMEDIATE_BLOCK_INTERVAL must be non-zero, and BLOCK_INTERVAL must be\ndivisible by INTERMEDIATE_BLOCK_INTERVAL.\nThe number of intermediate roots in every game is:\nIntermediate Root CountBLOCK_INTERVAL / INTERMEDIATE_BLOCK_INTERVAL\n\nThe final intermediate root must equal the game’s rootClaim.\n​Game Lifecycle\n\nThe factory owner configures a game type with an AggregateVerifier implementation and an\ninitialization bond.\nThe registrar caches Nitro certificates in CertManager, then registers enclave signers through\nTEEProverRegistry using the attestation and P-384 verification hints.\nA proposer creates a game through DisputeGameFactory.createWithInitData(), paying the exact\ninitialization bond and providing an initial TEE or ZK proof.\nThe game validates its parent, L2 block number, intermediate roots, L1 origin, and proof\njournal. The bond is deposited into DelayedWETH.\nA second proof may be submitted through verifyProposalProof(). If the proposal is invalid,\nchallengers can call challenge() or nullify() with proof material for an intermediate root.\nAfter the expected resolution time, anyone can call resolve(). The result is\nDEFENDER_WINS for a valid unchallenged game and CHALLENGER_WINS for a successful challenge\nor invalid parent.\nAfter resolution and the registry finality delay, anyone can call closeGame() to make a\nbest-effort anchor update.\nThe bond recipient calls claimCredit() twice: once to unlock the DelayedWETH credit, then\nagain after the DelayedWETH delay to withdraw and receive ETH.\n\n​DisputeGameFactory\nDisputeGameFactory creates and indexes dispute-game clones. Each game is uniquely identified by:\nGame UUIDkeccak256(abi.encode(gameType, rootClaim, extraData))\n\nThe factory stores that UUID in _disputeGames and also appends a packed GameId to\n_disputeGameList for index-based discovery. Offchain services use DisputeGameCreated,\ngameAtIndex(), and findLatestGames() to discover games.\n​Configuration\nOnly the factory owner can:\n\nset a game implementation with setImplementation(gameType, impl)\nset a game implementation plus opaque implementation args with\nsetImplementation(gameType, impl, args)\nset the exact required creation bond with setInitBond(gameType, initBond)\n\nCreation reverts if the implementation is unset, if the paid value differs from initBonds, or if\na game with the same UUID already exists.\n​Clone Arguments\nWhen no implementation args are configured, the clone-with-immutable-args payload is:\nBytesDescription[0, 20)Game creator address[20, 52)Root claim[52, 84)Parent L1 block hash at creation time[84, 84 + n)Opaque game extraData\nWhen implementation args are configured, the payload is:\nBytesDescription[0, 20)Game creator address[20, 52)Root claim[52, 84)Parent L1 block hash at creation time[84, 88)Game type[88, 88 + n)Opaque game extraData[88 + n, 88 + n + m)Opaque implementation args\nAggregateVerifier uses the standard layout. Its extraData is specified in the\nAggregateVerifier section below.\n​AnchorStateRegistry\nAnchorStateRegistry is the source of truth for whether a dispute game can be trusted by the proof\nsystem. It stores:\n\nthe SystemConfig\nthe DisputeGameFactory\nthe starting anchor root\nthe current anchor game, if one has been accepted\nthe current respected game type\na game blacklist\na retirement timestamp\na dispute-game finality delay\n\nThe initial retirement timestamp is set during first initialization. Games created at or before the\nretirement timestamp are retired.\n​Game Predicates\nThe registry exposes these predicates:\nPredicateTrue whenisGameRegistered(game)The factory maps the game’s (gameType, rootClaim, extraData) back to the same address, and the game points at this registry.isGameRespected(game)The game reports that its game type was respected when it was created.isGameBlacklisted(game)The guardian has blacklisted the game address.isGameRetired(game)game.createdAt() <= retirementTimestamp.isGameResolved(game)The game has a non-zero resolvedAt and ended with DEFENDER_WINS or CHALLENGER_WINS.isGameProper(game)The game is registered, not blacklisted, not retired, and the system is not paused.isGameFinalized(game)The game is resolved and more than disputeGameFinalityDelaySeconds have elapsed since resolvedAt.isGameClaimValid(game)The game is proper, respected, finalized, and resolved with DEFENDER_WINS.\nisGameProper() does not prove that the root claim is correct. It only means the game has not been\ninvalidated by registry-level controls. Consumers that need claim validity must use\nisGameClaimValid().\n​Guardian Controls\nThe SystemConfig.guardian() can:\n\nset the respected game type\nupdate the retirement timestamp to the current block timestamp\nblacklist individual games\n\nThese controls are the onchain safety valves for invalidating games before they can become valid\nclaims.\n​Anchor Updates\ngetAnchorRoot() returns the starting anchor root until an anchor game is accepted. After that, it\nreturns the root claim and L2 block number of anchorGame.\nsetAnchorState(game) accepts a new anchor game only when:\n\nisGameClaimValid(game) is true\nthe game’s L2 sequence number is greater than the current anchor root’s sequence number\n\nThe update is permissionless and self-validating.\n​DelayedWETH\nDelayedWETH is WETH with delayed withdrawals. It escrows game bonds and forces a two-step credit\nclaim:\n\nThe game calls unlock(subAccount, amount) for the bond recipient.\nAfter delay() seconds, the game calls withdraw(subAccount, amount) and sends ETH to the\nrecipient.\n\nUnlocks are keyed by:\nWithdrawal Request Keywithdrawals[msg.sender][subAccount]\n\nFor proof games, msg.sender is the AggregateVerifier game contract and subAccount is the\ncurrent bondRecipient.\nWithdrawals revert while the system is paused. The proxy admin owner also has emergency recovery\npowers:\n\nrecover(amount) sends up to amount ETH from the contract to the owner.\nhold(account) or hold(account, amount) pulls WETH from an account into the owner address.\n\n​AggregateVerifier\nAggregateVerifier is the dispute-game implementation for checkpoint proofs. Every factory-created\ngame is a clone with immutable game data. The implementation owns no per-game storage except the\nclone’s storage.\n​Constructor Configuration\nAn implementation fixes these values for all clones of that game type:\nValuePurposeGAME_TYPEThe dispute-game type served by this implementation.ANCHOR_STATE_REGISTRYParent validation, claim validity, and anchor updates.DISPUTE_GAME_FACTORYRead from the registry during construction.DELAYED_WETHBond escrow.TEE_VERIFIERVerifier for TEE signatures.TEE_IMAGE_HASHExpected TEE image hash committed into TEE journals.ZK_VERIFIERVerifier for ZK proofs.ZK_RANGE_HASHRange-program hash committed into ZK journals.ZK_AGGREGATE_HASHAggregate-program hash passed to the ZK verifier.CONFIG_HASHRollup configuration hash committed into proof journals.L2_CHAIN_IDL2 chain the game argues about.BLOCK_INTERVALDistance from parent block to proposed block.INTERMEDIATE_BLOCK_INTERVALDistance between intermediate checkpoint roots.PROOF_THRESHOLDNumber of proofs required to resolve, either 1 or 2.\nPROOF_THRESHOLD controls resolution, not proof submission. The game can store one TEE proof, one\nZK proof, or both.\n​Game Extra Data\nAggregateVerifier.extraData() is encoded as:\nBytesDescription[0, 32)Proposed L2 block number.[32, 52)Parent address. The first game uses the AnchorStateRegistry address.[52, 52 + 32 * n)Ordered intermediate output roots.\nwhere:\nExtra Data Root Countn = BLOCK_INTERVAL / INTERMEDIATE_BLOCK_INTERVAL\n\nThe final intermediate output root must equal rootClaim.\n​Initialization\ninitializeWithInitData(proof) can only run once. It verifies the calldata size so that unused\nbytes cannot create multiple factory UUIDs for the same logical proposal.\nDuring initialization the game:\n\nChecks that the final intermediate root matches rootClaim.\n\nResolves the starting root. If parentAddress is the registry address, the starting root is\nAnchorStateRegistry.getStartingAnchorRoot(). Otherwise the parent must be a valid registered\ngame.\n\nRequires:\nl2SequenceNumber == startingL2SequenceNumber + BLOCK_INTERVAL\n\nRecords createdAt, wasRespectedGameTypeWhenCreated, and an initial expectedResolution.\n\nVerifies the claimed L1 origin hash in the initialization proof against either blockhash() or\nEIP-2935 history.\n\nVerifies the supplied TEE or ZK proof.\n\nRecords the initial prover, sets bondRecipient to gameCreator, and deposits the bond into\nDelayedWETH.\n\nThe initialization proof format is:\nBytesDescription[0, 1)ProofType: 0 for TEE, 1 for ZK.[1, 33)L1 origin hash.[33, 65)L1 origin block number.[65, end)Proof bytes for the selected verifier.\nThe L1 origin block must be in the past. Native blockhash() is used for block ages up to 256\nblocks. EIP-2935 history is used up to 8191 blocks. Older or unavailable L1 origin blocks revert.\n​Additional Proofs\nverifyProposalProof(proofBytes) adds the missing proof type while a game is in progress and not\nover. It does not re-read a new L1 origin from calldata. Instead, it uses the l1Head() captured\nby the factory at clone creation.\nThe additional proof format is:\nBytesDescription[0, 1)ProofType: 0 for TEE, 1 for ZK.[1, end)Proof bytes for the selected verifier.\nA game cannot store more than one proof of the same type.\n​Proof Journals\nTEE and ZK proofs commit to the same transition shape:\nProof Journal Fieldsproposer\nl1OriginHash\nstartingRoot\nstartingL2SequenceNumber\nendingRoot\nendingL2SequenceNumber\nintermediateRoots\nCONFIG_HASH\nproof-system-specific hash\n\nFor TEE proofs, the final field is TEE_IMAGE_HASH and the journal is checked by TEEVerifier.\nThe game calls:\nTEE Journal Verification CallTEE_VERIFIER.verify(proposer || signature, TEE_IMAGE_HASH, keccak256(journal))\n\nFor ZK proofs, the final field is ZK_RANGE_HASH and the proof is checked by ZKVerifier. The\ngame calls:\nZK Journal Verification CallZK_VERIFIER.verify(proofBytes, ZK_AGGREGATE_HASH, keccak256(journal))\n\n​Resolution Delay\nexpectedResolution is derived from the number of currently accepted proofs:\nProof countDelay0Never resolvable.1SLOW_FINALIZATION_DELAY, 5 days since Beryl.2FAST_FINALIZATION_DELAY, fixed at 1 day.\nAdding a proof can only decrease expectedResolution. Nullifying a proof can increase it. A\nchallenge with a ZK proof sets expectedResolution to 7 days from the challenge so the challenge\ncan itself be nullified.\n​Challenge\nchallenge(proofBytes, intermediateRootIndex, intermediateRootToProve) challenges a TEE-backed\nproposal with a ZK proof for one intermediate interval.\nThe call is accepted only when:\n\nthe game is still IN_PROGRESS\nthe game itself is valid according to the registry\nthe parent has not resolved with CHALLENGER_WINS\nthe game has a TEE proof\nthe game does not already have a ZK proof\nthe supplied proof type is ZK\nthe challenged index is in range\nthe supplied root differs from the currently proposed intermediate root\n\nIf the ZK proof verifies, the game records the ZK prover, increments proofCount, stores the\n1-based countered intermediate index, and emits Challenged. When the game resolves, the challenger\nreceives the bond and the game status becomes CHALLENGER_WINS.\n​Nullification\nnullify(proofBytes, intermediateRootIndex, intermediateRootToProve) removes an already accepted\nproof by proving a contradictory intermediate root.\nFor an unchallenged game, the target root must differ from the proposed intermediate root. For a\nchallenged game, only the challenged index can be nullified, only with a ZK proof, and the supplied\nroot must match the original proposed intermediate root.\nAfter a successful nullification:\n\nthe prover slot for that proof type is deleted\nproofCount decreases\nexpectedResolution is recalculated\nthe countered index is cleared if the ZK challenge was nullified\nthe corresponding verifier contract is nullified\n\nVerifier nullification is a global safety stop. Once TEE_VERIFIER.nullify() or\nZK_VERIFIER.nullify() succeeds, future proof verification through that verifier reverts until the\nsystem is upgraded or reconfigured.\n​Resolve, Close, and Bonds\nresolve() can be called by anyone. The parent must be resolved unless the parent is the registry\nitself. If the parent resolved with CHALLENGER_WINS, or later became blacklisted or retired, the\nchild also resolves with CHALLENGER_WINS. Otherwise the game must be over and must have at least\nPROOF_THRESHOLD accepted proofs.\nIf the game was challenged, resolve() sets CHALLENGER_WINS and moves the bond recipient to the\nZK prover. Otherwise it sets DEFENDER_WINS.\ncloseGame() is permissionless. It reverts while the registry is paused, requires the game to be\nresolved and finalized by the registry, and then attempts AnchorStateRegistry.setAnchorState().\nThe anchor update is best-effort: if the registry rejects the game because it is no longer the\nnewest valid claim, closeGame() swallows that registry revert.\nclaimCredit() has two phases:\n\nUnlock the bond in DelayedWETH.\nAfter the DelayedWETH delay, withdraw WETH and send ETH to bondRecipient.\n\nIf accepted proofs have been nullified and expectedResolution is reset to the never-resolvable\nsentinel, claimCredit() is blocked until 14 days after createdAt. This prevents a stuck game\nfrom locking the bond forever.\n​ZKVerifier\nZKVerifier adapts the Succinct SP1 verifier gateway to the common IVerifier interface used by\nAggregateVerifier.\nThe call:\nZKVerifier Verify Callverify(proofBytes, imageId, journal)\n\nperforms:\nSP1 Verification CallSP1_VERIFIER.verifyProof(imageId, abi.encodePacked(journal), proofBytes)\n\nand returns true if the SP1 gateway does not revert. imageId is the aggregate program\nverification key supplied by the game, and journal is the hash of the public inputs assembled by\nthe game.\nZKVerifier inherits verifier nullification. After a proper respected game nullifies the verifier,\nall future verify() calls revert.\n​TEEVerifier\nTEEVerifier verifies TEE proof signatures against the TEEProverRegistry.\nThe proof bytes passed to TEEVerifier are:\nBytesDescription[0, 20)Proposer address.[20, 85)65-byte ECDSA signature.\nThe signature is recovered over the journal hash directly. It is not wrapped with the Ethereum\nsigned-message prefix.\nA TEE proof is valid only when:\n\nthe proof is at least 85 bytes\nthe signature recovers cleanly\nthe proposer is allowlisted in TEEProverRegistry\nthe recovered signer is registered in TEEProverRegistry\nthe signer’s registered image hash equals the imageId supplied by the calling game\n\nThe image-hash check prevents an enclave registered for one image from producing accepted proofs\nfor a game type or upgrade that expects another image.\nTEEVerifier also inherits verifier nullification.\n​TEEProverRegistry\nTEEProverRegistry manages TEE signer registration and proposer allowlisting.\nThe registry has:\n\nan owner\na manager\nan immutable NitroValidator reference\na DisputeGameFactory\na configurable gameType\nregistered signer state\nproposer allowlist state\n\nThe owner can set proposer addresses and update the gameType. The owner or manager can register\nand deregister signers.\n​Expected Image Hash\nThe registry reads the expected TEE image hash from the current game implementation:\nExpected Image Hash LookupDisputeGameFactory.gameImpls(gameType).TEE_IMAGE_HASH()\n\nsetGameType() validates that this call succeeds and returns a non-zero hash. isValidSigner()\nreturns true only when the signer is registered and its stored image hash matches the current\nexpected hash.\nRegistration does not compare PCR0 with the current TEE_IMAGE_HASH. This lets operators\npre-register signers for a future image before a game-type migration. Those signers do not become\nvalid for proof submission until the game’s expected image hash matches their registered image hash.\n​Signer Registration\nregisterSigner(attestationTbs, signature, hints) calls:\nAttestation Verification CallNITRO_VALIDATOR.validateAttestationWithHints(\n attestationTbs,\n signature,\n hints\n)\n\nThe attestation’s certificate chain must already be verified and cached in CertManager. The\nvalidator returns field pointers into the signed attestation, and the registry applies Base-specific\nchecks.\nThe attestation timestamp, converted from milliseconds to seconds, must be strictly earlier than\nblock.timestamp and less than MAX_AGE (3,600 seconds) old. PCR0 must be present at index zero,\nexactly 48 bytes, and not the all-zero debug-mode measurement. The public key must be exactly\n65 bytes in uncompressed ANSI X9.62 form:\nUncompressed Public Key Layout0x04 || x || y\n\nThe registry derives the signer address as:\nSigner Address Derivationaddress(uint160(uint256(keccak256(x || y))))\n\nThe registry extracts the 48-byte PCR0 measurement from the attestation and stores:\nSigner Image HashsignerImageHash[signer] = keccak256(PCR0)\n\nIt then marks the signer as registered, adds it to an enumerable signer set, and emits\nSignerRegistered.\n​Deregistration\nderegisterSigner(signer) deletes the signer’s registration and image hash, removes the signer\nfrom the enumerable set, and emits SignerDeregistered.\ngetRegisteredSigners() returns the current enumerable set. Ordering is not guaranteed.\n​NitroValidator\nNitroValidator validates AWS Nitro attestations using immutable CertManager and P384Verifier\nreferences.\nHinted Attestation ValidationvalidateAttestationWithHints(\n attestationTbs,\n signature,\n attestationSigHints\n)\n\nThe call:\n\nParses the signed COSE Sig_structure and validates the Nitro payload structure.\nRe-walks the certificate chain through CertManager, requiring a complete, unexpired, unrevoked\npath to the pinned AWS Nitro root.\nVerifies the 96-byte P-384 attestation signature over SHA384(attestationTbs) with the leaf\ncertificate’s public key and the supplied inverse hints.\nReturns Ptrs, containing the timestamp and CBOR field pointers into attestationTbs.\n\nThe certificate-chain walk supplies no certificate hints, so every certificate must already be\ncached. decodeAttestationTbs() separates a raw COSE_Sign1 document into its signed TBS bytes and\nsignature; decoding alone does not validate the attestation.\nNitroValidator authenticates the signed fields but does not enforce Base’s freshness window,\nsigner-key format, or accepted enclave image. The registry applies the\ntimestamp, public-key, and PCR0 checks. The registrar’s challenge policy\nchecks the nonce offchain, and TEEVerifier enforces the game’s expected image at proof submission.\nThe deprecated unhinted validateAttestation() entry point always reverts.\n​CertManager\nCertManager pins the AWS Nitro root at deployment and caches verified CA and leaf certificates.\nIts active verification methods are:\nCertificate Cache CallsverifyCACertWithHints(\n cert, parentCertHash, signatureHints\n)\nverifyClientCertWithHints(\n cert, parentCertHash, signatureHints\n)\n\nBoth methods are permissionless. For non-root certificates, the parent must already be cached.\nCold verification checks the certificate signature through P384Verifier. Cached reuse checks the\ncertificate’s CA or leaf role, expiry, original parent binding, and unrevoked path to the root.\nThe CA method returns the certificate’s cache key; the leaf method returns VerifiedCert metadata.\nNon-root cache keys are keccak256(TBSCertificate DER), excluding the outer signature. The root\nuses its pinned keccak256(root DER) key. loadVerified() is a raw cache read: its result can be\nexpired or revoked and is not itself evidence that a certificate remains usable.\nRevocation uses a separate identity: computeCertId() returns the non-root issuer/serial identity,\nand isRevoked() reads its revocation status. The root uses the pinned root hash instead. Revocation\nis checked during cold verification, cached reuse, and final attestation validation. See the\nregistration plan for the exact\ncache-key and revocation-identity encodings.\nRevoking the root blocks new signer registrations. Certificate revocation and expiration do not\ninvalidate previously registered signers; affected signers must be deregistered separately through\nTEEProverRegistry.deregisterSigner().\nThe deprecated unhinted verifyCACert() and verifyClientCert() entry points always revert.\n​P384Verifier\nHinted P-384 Signature VerificationverifyP384SignatureWithHints(\n hash, signature, pubKey, inverseHints\n)\n\nP384Verifier verifies P-384 ECDSA signatures for both certificates and attestations. It consumes\n48-byte big-endian inverse hints and checks b * hint == 1 (mod m) before using each inverse.\nIncorrect, truncated, or surplus hints revert; hints cannot make an invalid signature valid.\nSee P-384 Hints for the generation and\nencoding requirements.\nLow-S is not enforced, so equivalent signatures can have different bytes. Signature bytes must not\nbe used as unique certificate or attestation identifiers.\n​NitroEnclaveVerifier\nNitroEnclaveVerifier is the legacy, pre-Cobalt ZK attestation verifier. The current registry uses\nNitroValidator, CertManager, and P384Verifier instead. See\nHinted Registration Migration\nfor the upgrade and preserved registry state.\n​Cross-Contract Safety Properties\nThe proof contracts rely on the following cross-contract properties:\n\nFactory uniqueness: a logical (gameType, rootClaim, extraData) can create at most one game.\nParent validity: non-anchor games can only start from a registered, respected, non-retired,\nnon-blacklisted parent that has not lost.\nMonotonic checkpoints: each child game must advance exactly BLOCK_INTERVAL L2 blocks from its\nstarting root.\nIntermediate accountability: every proposal commits to all intermediate roots, so challengers\ncan target the first invalid checkpoint interval.\nVerifier separation: TEE and ZK proofs use different verifier contracts and different journal\ndomain separators (TEE_IMAGE_HASH versus ZK_RANGE_HASH).\nFast finality requires diversity: a game with two accepted proof types can resolve after one day,\nwhile a game with one proof waits five days since Beryl.\nRegistry finality is separate from game resolution: a game can resolve before the\nAnchorStateRegistry accepts it as a valid claim.\nSafety controls fail closed: pause, blacklist, retirement, and verifier nullification prevent\nacceptance rather than expanding trust.\n\n​Administrative Surfaces\nContractPrivileged rolePrivileged actionsDisputeGameFactoryOwnerSet game implementations, implementation args, and initialization bonds.AnchorStateRegistryGuardian from SystemConfigSet respected game type, blacklist games, update retirement timestamp.DelayedWETHProxy admin ownerRecover ETH and hold WETH from accounts.TEEProverRegistryOwnerSet proposers, update game type, transfer ownership or management.TEEProverRegistryOwner or managerRegister and deregister TEE signers.CertManagerOwnerTransfer ownership, set the revoker, revoke the pinned root, and unrevoke certificate identities or the root.CertManagerRevokerRevoke non-root issuer/serial identities with revokeCert() or revokeCerts().\nThese surfaces are intentionally narrow but high impact. Operational changes to them can affect\nwhich games are respected, which proofs verify, and which attestations can register new TEE\nsigners.Was this page helpful?Suggest editsRaise issue","tokens":6230,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266381892,"hash":"51f9adff172fcffe2a8c850035ab892d60eb6427"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/42","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 42 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 30, 2018\n\n post by kz on Jan 30, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by kz on Feb 1, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 2, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n Load more posts below","tokens":1364,"squid":"ink-research","role":"Deep Scholar","at":1791266382575,"hash":"07c0a1ba2e1c8ef229dcd94e67c62b1fa72b88ae"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/overview","domain":"docs.base.org","title":"Proofs - Base Documentation","text":"The proof system is the set of offchain services and onchain contracts that make L2 checkpoint\nproposals verifiable from Ethereum. A proposal claims an output root for a fixed L2 block range.\nIndependent proof actors recompute that claim, provide proof material, and dispute the game if the\nclaim is invalid.\nThis section describes the component roles used by the Azul proof system.\n\nChallenger: checks in-progress games against canonical L2 state and disputes\ninvalid claims.\nProposer: creates new checkpoint proposals.\nRegistrar: maintains the onchain registry of accepted TEE signer identities.\nTEE Prover: produces Nitro Enclave-backed proofs for the common proposal path.\nZK Prover: produces permissionless proofs for proposal and dispute paths.\nContracts: verify proof material, track game state, and release withdrawals and\nbonds according to the game result.\nWas this page helpful?Suggest editsRaise issue","tokens":228,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266391990,"hash":"f9b7c72864c9c3854f1884db87694501ce1b2a1d"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/44","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 44 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by kz on Feb 1, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 2, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n Load more posts below","tokens":1036,"squid":"ink-research","role":"Deep Scholar","at":1791266392694,"hash":"0f2f11ec1563bbd283c76ab61448c83587c37bed"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/zk-prover","domain":"docs.base.org","title":"ZK Prover - Base Documentation","text":"The ZK prover is an offchain service that uses SP1 programs to produce permissionless proofs for\ncheckpoint proposals and disputes. A proving service accepts block-range requests, persists proof\nstate, submits work to SP1 proving infrastructure, and returns receipts that callers can submit to\nAggregateVerifier.\nThe ZK path is permissionless: any operator with canonical L1 and L2 RPC access, a configured SP1\nbackend, and an L1 transaction signer can request proofs and submit valid proof material onchain.\n​Responsibilities\nA conforming ZK prover stack performs the following work:\n\nAccept proving requests for L2 block ranges.\nGenerate witness input from canonical L1, L2, and beacon RPCs.\nProve the range program with SP1.\nFor Groth16 requests, aggregate the completed range proof into an onchain-verifiable SNARK.\nPersist proof request and backend session state so work can recover across process restarts.\nExpose proof status and receipt retrieval over gRPC.\nEncode receipts in the format expected by challengers, proposers, and ZKVerifier.\n\nThe ZK prover does not decide whether a game is valid. Proposers and challengers choose the range to\nprove, recompute canonical roots themselves, and recheck game state before submitting proof material\nonchain.\n​Proving Service API\nThe proving service exposes:\nProving Service APIProveBlock(ProveBlockRequest) -> ProveBlockResponse\nGetProof(GetProofRequest) -> GetProofResponse\n\nProveBlock enqueues a proof request and returns a session_id. GetProof returns the current\nstatus and, once complete, the requested receipt bytes.\n​ProveBlock Request\nProveBlockRequest contains:\nFieldMeaningstart_block_numberL2 block whose output root is the trusted starting state for the range.number_of_blocks_to_proveNumber of L2 blocks to prove after start_block_number.sequence_windowOptional L1 block lookahead used when deriving an L1 head for witness generation.proof_typePROOF_TYPE_COMPRESSED or PROOF_TYPE_SNARK_GROTH16.session_idOptional caller-supplied UUID used for idempotent requests.prover_addressL1 address committed into the Groth16 journal so a proof cannot be replayed by another sender. Required for Groth16.l1_headOptional 32-byte hex L1 block hash used for witness generation.\nIf session_id is supplied, duplicate requests with the same UUID return the existing session. This\nlets challengers derive deterministic session IDs from (game address, invalid checkpoint index)\nand retry safely across process restarts.\nCallers supply l1_head when the proof journal must match a specific game context already\ncommitted onchain (for example, dispute proofs against an existing game). When omitted, the service\nderives an L1 head from the L2 block’s L1 origin plus the request or service sequence window, which\nis appropriate for fresh proposals where the caller has not yet committed to an L1 head.\nPROOF_TYPE_SNARK_GROTH16 requires prover_address: the aggregation program commits this address\ninto the journal digest, and AggregateVerifier rechecks the same digest before accepting the\nproof, so a Groth16 receipt is bound to the L1 sender that requested it.\n​Proof Types\nThe service supports two proof types:\nProof typeBackend sessionsResultPROOF_TYPE_COMPRESSEDSTARKA compressed SP1 range proof.PROOF_TYPE_SNARK_GROTH16STARK, SNARKA range proof plus a Groth16 aggregation proof suitable for onchain use.\nFor PROOF_TYPE_SNARK_GROTH16, the service first submits the range program as a compressed STARK\nsession. After that session completes, the service submits the aggregation program as a Groth16\nSNARK session.\n​Request Lifecycle\nA proof request begins as CREATED once the request and outbox entry have been persisted. A\nworker then claims the outbox task and moves the request to PENDING while it prepares and\nsubmits backend work. After at least one backend session exists, the request is RUNNING. The\nrequest becomes SUCCEEDED once all sessions required by the proof type complete and the receipt\nbytes are stored, or FAILED if validation, witness generation, backend submission, backend\nexecution, receipt download, or retry recovery fails permanently.\nBackend sessions track RUNNING, COMPLETED, or FAILED independently of the proof request. A\ncompressed request succeeds when all STARK sessions complete. A Groth16 request succeeds only\nafter both the STARK and SNARK sessions complete. Any failed session fails the parent request.\n​Receipt Retrieval\nGetProofRequest contains:\nFieldMeaningsession_idUUID returned by ProveBlock.receipt_typeOptional receipt selector. Defaults to RECEIPT_TYPE_STARK.\nThe receipt selector can be:\nReceipt typeResponse bytesRECEIPT_TYPE_STARKSerialized SP1 proof-with-public-values for the range proof.RECEIPT_TYPE_SNARKSerialized SP1 proof-with-public-values for the aggregation proof.RECEIPT_TYPE_ON_CHAIN_SNARKOnchain proof bytes extracted from the stored SNARK receipt for the SP1 Groth16 verifier.\nGetProof returns empty receipt bytes while a request is CREATED, PENDING, or RUNNING.\nFailed requests return STATUS_FAILED and the stored error message. A successful response always\ncarries non-empty receipt bytes; if the stored request is Succeeded but the requested receipt\nkind is absent, GetProof returns gRPC NOT_FOUND rather than an empty success.\nCallers are responsible for wrapping returned receipt bytes in the AggregateVerifier proof format.\nFor challenge, nullification, and additional-proof submission, the caller prefixes the ZK proof-type\nbyte before the receipt. For game initialization, the caller also includes the L1 origin fields\nrequired by initializeWithInitData(). See Contracts for the verifier-side framing.\n​Backend Modes\nThe proving service supports these backend modes:\nModePurposemockProduces fake receipts for local tests without witness generation.clusterSubmits work to a self-hosted SP1 cluster with Redis or S3 artifacts.networkSubmits work to the SP1 Network with the configured fulfillment policy.\nThe cluster and network backends share the same witness generation path; only submission,\npolling, and artifact retrieval differ. The mock backend skips witness generation entirely.\n​SP1 Range Program\nThe range program proves a Base L2 state transition over a contiguous block range. Its stdin\ncontains:\nRange Program Stdinrkyv(DefaultWitnessData)\nintermediateRootInterval\n\nThe program reconstructs the preimage oracle and beacon blob provider from the witness, runs the\nEthereum DA witness executor, and commits a BootInfoStruct.\nThe committed boot info contains:\nFieldMeaningl2PreRootOutput root for the trusted starting L2 block.l2PreBlockNumberStarting L2 block number.l2PostRootOutput root after executing the requested range.l2BlockNumberEnding L2 block number.l1HeadL1 block hash used for derivation data.rollupConfigHashHash of the rollup configuration used during execution.intermediateRootsOrdered output roots sampled every intermediate-root interval.\nThe final intermediate root must correspond to the ending L2 block for the range being proven.\n​SP1 Aggregation Program\nThe aggregation program turns completed range proofs into the journal digest used by onchain\nverification. Its inputs are:\nAggregation Program InputsAggregationInputs (sp1_zkvm::io::read)\nL1 headers (CBOR-encoded) (sp1_zkvm::io::read_vec)\ncompressed range proofs (SP1 proof-input channel)\n\nThe compressed range proofs are passed via SP1’s proof-input mechanism, not via plain stdin bytes,\nand are verified inside the program with sp1_lib::verify::verify_sp1_proof.\nAggregationInputs contains the range boot infos, the latest L1 checkpoint head, the range-program\nverification key, and the prover address.\nThe aggregation program verifies:\n\nAt least one range boot info is present.\n\nAdjacent range boot infos are sequential:\nprevious.l2PostRoot == next.l2PreRoot\nprevious.l2BlockNumber == next.l2PreBlockNumber\n\nEvery range uses the same rollupConfigHash.\n\nEvery compressed range proof verifies against the supplied range verification key.\n\nThe provided L1 headers form a linked chain ending at latest_l1_checkpoint_head.\n\nEvery range l1Head appears in that header chain.\n\nThe program then flattens all intermediate roots and builds one aggregate output:\nAggregate Output FieldsproverAddress\nl1Head\nl2PreRoot\nstartingL2SequenceNumber\nl2PostRoot\nendingL2SequenceNumber\nintermediateRoots\nrollupConfigHash\nimageHash\n\nimageHash is the range-program verification key commitment. The aggregation program commits:\nCommitted Journal Digestkeccak256(abi.encodePacked(AggregationOutputs))\n\nThis digest matches the journal hash assembled by AggregateVerifier for ZK proof verification. In\nContracts terminology, imageHash is ZK_RANGE_HASH, and the aggregation\nverification key configured on ZKVerifier is ZK_AGGREGATE_HASH.\n​ELF Reproducibility\nSP1 ELF binaries are built on demand and are not committed. The repository pins expected ELF\nSHA-256 hashes in crates/proof/succinct/elf/manifest.toml. A code change that changes either SP1\nprogram must rebuild the ELFs and update manifest.toml in the same change.\nThe range verification key commitment (ZK_RANGE_HASH) and aggregation verification key hash\n(ZK_AGGREGATE_HASH) are onchain security parameters. Operators must deploy or configure verifier\ncontracts with values derived from the same ELFs used by the proving service.\n​Retry Behavior\nThe service retries transient conditions without changing the logical proof request:\nConditionRequired behaviorOutbox task already claimedSkip the duplicate worker.Stuck PENDING request without an active sessionReset to CREATED with a new outbox entry until the retry limit is exhausted.Backend status polling errorLeave the request RUNNING and retry on a later poll.Proof artifact unavailable after backend successLeave the session RUNNING or retry download on a later poll.Backend reports failed or unfulfillable workMark the session and proof request FAILED.Groth16 stage-two submission fails after STARKMark the proof request FAILED.\nCallers should treat FAILED as terminal for that stored request. If the proof is still needed, the\ncaller should submit or retry the same logical request using its deterministic session_id.\n​Service Lifecycle\nAt startup, the proving service:\n\nConnects to Postgres.\nOptionally starts rate-limited local proxies for L1, L2, and beacon RPCs.\nLoads rollup configuration from the rollup RPC.\nComputes the range and aggregation proving and verifying keys.\nInitializes the configured backend.\nStarts the outbox processor.\nStarts the status poller.\nStarts the gRPC server and reflection service.\n\nThe outbox processor turns persisted requests into backend sessions. The status poller syncs running\nsessions, downloads receipts, triggers Groth16 stage two when needed, and retries or fails stuck\nrequests.\n​Operator Inputs\nA ZK prover service needs:\n\nL1 execution RPC endpoint.\nL1 beacon RPC endpoint.\nL2 execution RPC endpoint.\nRollup RPC endpoint.\nPostgres connection settings.\nSP1 backend configuration.\nArtifact storage configuration for cluster mode.\nPoll intervals, stuck-request timeout, and retry limits.\nMetrics and logging configuration.\n\nNetwork mode additionally needs an SP1 Network signer or KMS requester configuration. Cluster mode\nadditionally needs an SP1 cluster endpoint and exactly one artifact storage backend.\n​Onchain Expectations\nZK proof bytes are submitted to AggregateVerifier as proof type ZK. The game assembles the\nexpected journal from the proposal or dispute context and calls ZKVerifier.verify() with the\nconfigured aggregation verification key.\nA valid Groth16 receipt proves that the aggregation program committed the expected journal digest.\nIt does not replace caller-side state checks. Proposers and challengers must still recompute\ncanonical roots and recheck game state before submitting proof material.\n​Safety Requirements\nA ZK prover implementation must preserve these safety properties:\n\nUse the caller-provided l1_head when present, so dispute proofs match the game context stored\nonchain.\nRequire prover_address for Groth16 proofs, because it is committed into the aggregation journal.\nKeep request creation idempotent for deterministic session_id values.\nDo not return onchain SNARK bytes unless the stored SNARK receipt deserializes successfully.\nPersist backend session metadata before relying on asynchronous backend completion.\nPin ELF hashes so verification keys and onchain configuration do not silently drift.\nTreat unavailable RPC data, backend polling failures, and artifact download failures as retryable\nservice conditions rather than proof validity results.\nWas this page helpful?Suggest editsRaise issue","tokens":3144,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266402058,"hash":"3dbb10b6b0cb5c36f75bfed43dafffa24cf16f15"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/45","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 45 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by kz on Feb 1, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 2, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n Load more posts below","tokens":1102,"squid":"ink-research","role":"Deep Scholar","at":1791266402776,"hash":"769fb31540f3647c2e2a44b2d8d40e7bf7ab9df0"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/46","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 46 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 31, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by kz on Feb 1, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 2, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n Load more posts below","tokens":1465,"squid":"ink-research","role":"Deep Scholar","at":1791266414259,"hash":"6c54d78967ce6ead99bb64621affb5262be15480"}
{"url":"https://forum.soliditylang.org/t/about-the-announcements-category/14/1","domain":"forum.soliditylang.org","title":"About the Announcements category - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n About the Announcements category \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by franzihei on Dec 11, 2020\n\n franzihei\n\n Low-traffic category for important announcements about the Solidity language and compiler.\nSubscribe to this category if you want to be kept in the loop about releases and Solidity-relevant feedback surveys, news and events.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 124\n\n Dec 2025\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 147\n\n Apr 27\n\n The Annual Solidity Survey is live!\n\n Announcements\n\n 2\n\n 121\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1082,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266418674,"hash":"7d155517c7ea3190e5ce838551034dd758761153"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/challenger","domain":"docs.base.org","title":"Challenger - Base Documentation","text":"The challenger is an offchain service that protects the proof system by independently checking\nin-progress AggregateVerifier games against canonical L2 state. When it finds an invalid\ncheckpoint root, it obtains the proof material required by the game contract and submits a dispute\ntransaction on L1.\nThe challenger is permissionless in the ZK path: any operator with access to canonical L1 and L2\nRPCs, a ZK proving service, and an L1 transaction signer can run it. Base may also run a challenger\nwith access to a TEE proof endpoint so invalid TEE-backed games can be nullified on a faster path\nbefore falling back to ZK.\n​Responsibilities\nA conforming challenger performs the following work:\n\nScan recent DisputeGameFactory games.\nSelect games that are still IN_PROGRESS and have proof state that may require action.\nRecompute the relevant checkpoint output roots from an L2 node.\nIdentify the first invalid checkpoint root, or determine whether a ZK challenge targeted a valid\ncheckpoint.\nSource a TEE or ZK proof for the checkpoint interval that must be proven.\nSubmit nullify() or challenge() to the game contract.\nTrack the resulting bond lifecycle when configured to claim bonds.\n\nThe challenger does not decide canonical L2 state by trusting the game. It recomputes roots from\nL2 headers and account proofs and treats the game as an input to be checked.\n​Game Selection\nThe challenger reads the current AnchorStateRegistry.anchorGame(), locates that game in the\nfactory index array, and scans every later factory index. If the registry is still at the starting\nanchor, or if the anchor game cannot be found in the factory, scanning starts at index 0. Games\nobserved IN_PROGRESS remain tracked until they resolve or are fully nullified, so metrics reflect\nthe live post-anchor set. Each scan re-evaluates the full post-anchor range so games can move\nbetween categories as new proofs, challenges, or nullifications are posted onchain. Individual game\nquery failures are logged and retried on the next scan; they do not abort the full scan.\nA game is selected only when status() == IN_PROGRESS. The challenger then reads:\n\nteeProver()\nzkProver()\ncounteredByIntermediateRootIndexPlusOne()\nrootClaim()\nl2SequenceNumber()\nstartingBlockNumber()\nl1Head()\nINTERMEDIATE_BLOCK_INTERVAL() from the game implementation for the game type\n\nThe (teeProver, zkProver, countered index) tuple determines the candidate category.\nTEE proverZK proverCountered indexCategoryChallenger actionnon-zerozero0Invalid TEE proposalValidate all checkpoint roots. If invalid, prefer TEE nullification and fall back to ZK challenge().non-zeronon-zero> 0Fraudulent ZK challengeValidate only the challenged checkpoint. If the challenged root is correct, submit ZK nullify().zeronon-zero0Invalid ZK proposalValidate all checkpoint roots. If invalid, submit ZK nullify().non-zeronon-zero0Invalid dual proposalValidate all checkpoint roots. If invalid, nullify the TEE proof first, then rescan to handle the remaining ZK proof.\nGames with both prover addresses set to zero are already fully nullified and are skipped. TEE-only or\nZK-only games with a non-zero countered index are unexpected states and are skipped.\n​Output Root Validation\nFor an unchallenged proposal, the challenger validates the submitted intermediate roots. For index\ni, the checkpoint block is:\nCheckpoint Block FormulastartingBlockNumber + INTERMEDIATE_BLOCK_INTERVAL * (i + 1)\n\nThe number of submitted roots must equal:\nSubmitted Root Count(l2SequenceNumber - startingBlockNumber) / INTERMEDIATE_BLOCK_INTERVAL\n\nThe interval must be non-zero, and the starting block must be lower than the proposed L2 sequence\nnumber. Arithmetic overflow and checkpoint-count mismatches make validation fail for that scan tick.\nFor each checkpoint block, the challenger computes the expected output root as follows:\n\nFetch the L2 block header by block number.\nVerify that the RPC-provided header hash equals the hash computed from the consensus header.\nFetch an eth_getProof account proof for L2ToL1MessagePasser at that block hash.\nVerify the account proof against the header state root.\nBuild the output root from the L2 state root, L2ToL1MessagePasser storage root, and L2 block\nhash.\nCompare the computed root to the root stored in the game.\n\nIntermediate roots are validated concurrently, but results are consumed in checkpoint order. The\nfirst mismatch determines the intermediateRootIndex and intermediateRootToProve used in the\ndispute transaction. intermediateRootToProve is the locally computed correct root for the invalid\ncheckpoint.\nWhen the requested L2 block is not yet available, the challenger skips the game for that scan tick.\nThe game remains eligible and will be retried on the next scan.\n​Fraudulent ZK Challenge Validation\nWhen a TEE proposal has been challenged by a ZK proof, the game stores a 1-based countered index.\nThe challenger converts it to a 0-based checkpoint index and validates only that checkpoint.\nIf the onchain root at the challenged index does not match the locally computed root, the ZK\nchallenge was legitimate and the challenger takes no action. If the onchain root matches the local\nroot, the ZK challenge targeted a correct checkpoint and is fraudulent. The challenger then obtains\na ZK proof for that checkpoint interval and submits nullify().\nThis validation is intentionally local to the challenged index. Earlier invalid roots do not make a\nchallenge against a later valid root legitimate.\n​Proof Sourcing\nThe challenger proves only the interval that contains the invalid checkpoint. The trusted anchor is\nthe prior checkpoint root, or the game’s startingBlockNumber state when the invalid checkpoint is\nindex 0.\nFor a ZK proof request:\n\nstart_block_number is the start of the invalid checkpoint interval.\nnumber_of_blocks_to_prove is INTERMEDIATE_BLOCK_INTERVAL.\nproof_type is Groth16 SNARK.\nsession_id is deterministic from (game address, invalid checkpoint index).\nprover_address is the L1 address that will submit the transaction.\nl1_head is the L1 head hash stored in the game at creation.\n\nThe deterministic session ID makes proof requests idempotent across retries.\nWhen TEE proof sourcing is configured and the game has a TEE prover, the challenger tries the TEE\npath first for invalid TEE and invalid dual proposals. The TEE request uses the game l1Head, the\ncorresponding L1 block number, the locally computed agreed L2 output at the start of the interval,\nand the expected output root at the invalid checkpoint. The challenger accepts the TEE result only\nif the enclave output root equals the locally computed expected root, then encodes the TEE dispute\nproof bytes for nullify().\nIf the TEE request fails or times out, the challenger falls back to ZK. If a TEE proof is obtained\nbut the TEE nullify() transaction fails, the pending entry transitions to a ZK proof request\ninstead of retrying the same TEE transaction indefinitely.\n​Dispute Transactions\nThe challenger submits one of two game calls:\nIntentContract callUsed whenNullifynullify(proofBytes, intermediateRootIndex, intermediateRootToProve)Removing an invalid TEE proof, removing an invalid ZK proof, or refuting a fraudulent ZK challenge.Challengechallenge(proofBytes, intermediateRootIndex, intermediateRootToProve)Challenging an invalid TEE proposal with a ZK proof.\nTEE proofs always target nullify(). ZK proofs can target either challenge() or nullify()\ndepending on the candidate category.\nBefore submitting or retrying a failed proof, the challenger rechecks the game status and prover\nslots. If the game has already resolved, has already been challenged, or the targeted prover slot\nhas already been zeroed, the pending proof is dropped. This prevents duplicate transactions when\nanother actor has already handled the game.\n​Pending Proof Lifecycle\nEach pending proof is keyed by game address and tracks:\n\nproof kind: TEE or ZK\ninvalid checkpoint index\nexpected root for that checkpoint\ndispute intent\nretry count\nphase\n\nThe phase machine is:\n\nZK proofs are polled from the proving service until the job succeeds, fails, or remains pending.\nSuccessful ZK receipts are prefixed with the ZK proof-type byte before submission. Failed proof jobs\nare retried up to three times. A TEE proof enters ReadyToSubmit immediately after it is obtained;\nif its transaction fails, the challenger immediately requests the pre-built ZK fallback proof when\none is available. If no fallback request exists, the entry is dropped; if the fallback prove_block\ncall fails, the entry remains in NeedsRetry until the next tick. A proof that remains pending, a\nfailed ZK transaction, or a failed prove_block retry leaves the proof in its current phase until\nthe next tick. A pending proof causes no contract reads for that game on that tick.\n​Bond Claiming\nBond claiming is optional and is enabled by configuring claim addresses. When enabled, the challenger\ntracks games whose bondRecipient() or pre-resolution zkProver() matches one of those addresses.\nThis allows a challenger to recover claimable games after restart and to discover games handled by\nother actors.\nThe bond lifecycle is:\n\nNeedsResolve: wait for gameOver(), then submit resolve().\nNeedsUnlock: submit the first claimCredit() to unlock the DelayedWETH credit.\nAwaitingDelay: wait for the DelayedWETH delay.\nNeedsWithdraw: submit the second claimCredit() to withdraw the credit.\n\nAfter resolution, the challenger re-reads bondRecipient() and stops tracking the game if the bond\nis no longer claimable by a configured address. For games that resolve as DEFENDER_WINS, it also\nattempts a best-effort AnchorStateRegistry.setAnchorState(game) update. The registry call is\npermissionless and self-validating; premature or ineligible calls can revert and be retried.\n​Service Lifecycle\nAt startup, the challenger:\n\nCreates L1 and L2 RPC clients.\nCreates the L1 transaction manager from the configured signer.\nCreates DisputeGameFactory and AggregateVerifier clients.\nCreates the ZK proof client and optional TEE proof client.\nStarts the health server.\nStarts the driver loop.\n\nEach driver tick:\n\nPolls pending proof sessions and submits ready disputes.\nDiscovers claimable bonds and advances tracked bond claims.\nScans for in-progress candidate games.\nValidates and initiates proofs for new candidates.\n\nThe health endpoint reports ready only after the first successful driver step. Shutdown is driven by\na cancellation token so the driver and health server stop together.\n​Operator Inputs\nA challenger needs:\n\nL1 RPC endpoint.\nL2 execution RPC endpoint.\nDisputeGameFactory address.\nAnchorStateRegistry address.\nZK proof RPC endpoint.\nL1 transaction signer.\nPoll interval.\n\nOptional inputs:\n\nTEE proof RPC endpoint and timeout, enabling TEE-first nullification for TEE-backed games.\nBond claim addresses, bond discovery interval, and bond discovery lookback window, enabling\nautomatic bond recovery and claiming.\nMetrics and health server settings.\n\n​Safety Requirements\nA challenger implementation must preserve these safety properties:\n\nDo not dispute a game from the game’s own claimed roots alone; recompute roots from L2 headers and\nverified L2ToL1MessagePasser account proofs.\nUse the game’s stored L1 head when requesting dispute proofs, so proof journals match the game\ncontext verified onchain.\nFor fraudulent ZK challenges, validate the challenged checkpoint itself rather than the first\ninvalid checkpoint in the whole proposal.\nRecheck game state before submitting a ready proof, because another challenger or prover may have\nalready changed the game.\nTreat unavailable L2 blocks and transient RPC failures as retryable scan conditions rather than\nfinal validation results.\nWas this page helpful?Suggest editsRaise issue","tokens":2932,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266425776,"hash":"db9659ca23941afd618ebf0a9e22bf7279de37ab"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/48","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 48 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 31, 2018\n\n kz\n\n denett\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\n One thing which is unclear in my head is why does one need to allow bad exits at all?\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\nThis seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …\nWhy is a validator-based approach good for Casper and bad for Plasma ?\nActually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …\n\n post by kz on Feb 3, 2018\n\n kz\n\n @denett Oh, I’m sorry, I’ve missed that part of your previous answer.\n\nCorrect, you’ve said it It’s hard for me to discuss these things over forums.\n\nIt would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.\nI believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.\nWhat is the downside of a solution to have two colored UTXOs on plasma chain?\n\nCommited = red\nUncommited = blue.\n\nOne can exit both red and blue UTXOs.\nOnly red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.\nIf exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.\n\n post by denett on Feb 3, 2018\n\n denett\n\nI guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.\n\n post by kz on Feb 3, 2018\n\n kz\n\nYeah, that was my thought as well.\nI was referring to:\n\n post by vbuterin on Feb 3, 2018\n\n vbuterin\n\n denett\n\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\n\nWhat do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.\n\n Load more posts below","tokens":3625,"squid":"ink-research","role":"Deep Scholar","at":1791266425878,"hash":"455aee1eeaf9bf5c74722105ea81f9e4b64005c2"}
{"url":"https://forum.soliditylang.org/t/the-annual-solidity-survey-is-live/3664","domain":"forum.soliditylang.org","title":"The Annual Solidity Survey is live! - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n The Annual Solidity Survey is live! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 10\n\n 1 / 3\n\n Feb 11\n\n Apr 27\n\n post by czepluch on Feb 10\n\n czepluch\n\n Solidity Team\n\n The annual Solidity Developer Survey is now live, and we need your input!\nTake 5 minutes to share your experience and help us prioritize language design, performance improvements, and developer experience enhancements for the year ahead.\n Take the Survey\nThe Survey Covers:\n\nDemographics and developer profiles\nTooling and usage\nDeveloper experience\nCore Solidity\nUse of AI\n\nThis is the start of a broader, ongoing feedback program with the community. Your voice matters.\nYour answers will directly help shape the future of the Solidity language, compiler, and surrounding tooling.\nAs a thank you, you’ll have a chance to win a Devcon 8 ticket (just add your contact details at the end of the survey to enter the raffle).\nPlease, spread the word and help us build a better Solidity!\n\n 2\n\n 2 months later\n\n post by nebojsakonsta on Apr 24\n\n nebojsakonsta\n\n Link you provided doesn’t work for me.\n\n post by czepluch on Apr 27\n\n czepluch\n\n Solidity Team\n\n Yeah, the survey is closed.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity 0.8.37 is released!\n\n Announcements\n\n 0\n\n 55\n\n 26d\n\n Solidity v0.8.31 is out! \n\n Announcements\n\n 0\n\n 136\n\n Dec 2025\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 181\n\n Dec 2025\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1272,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266428655,"hash":"5fb20fee910ce5850e6b9a0b5b7cd124b4e771dc"}
{"url":"https://forum.soliditylang.org/t/the-annual-solidity-survey-is-live/3664/3","domain":"forum.soliditylang.org","title":"The Annual Solidity Survey is live! - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 10\n\n 3 / 3\n\n Apr 27\n\n Apr 27\n\n post by czepluch on Feb 10\n\n czepluch\n\n Solidity Team\n\n The annual Solidity Developer Survey is now live, and we need your input!\nTake 5 minutes to share your experience and help us prioritize language design, performance improvements, and developer experience enhancements for the year ahead.\n Take the Survey\nThe Survey Covers:\n\nDemographics and developer profiles\nTooling and usage\nDeveloper experience\nCore Solidity\nUse of AI\n\nThis is the start of a broader, ongoing feedback program with the community. Your voice matters.\nYour answers will directly help shape the future of the Solidity language, compiler, and surrounding tooling.\nAs a thank you, you’ll have a chance to win a Devcon 8 ticket (just add your contact details at the end of the survey to enter the raffle).\nPlease, spread the word and help us build a better Solidity!\n\n 2\n\n 2 months later\n\n post by nebojsakonsta on Apr 24\n\n nebojsakonsta\n\n Link you provided doesn’t work for me.\n\n post by czepluch on Apr 27\n\n czepluch\n\n Solidity Team\n\n Yeah, the survey is closed.\n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 181\n\n Dec 2025\n\n Solidity v0.8.35 is out!\n\n Announcements\n\n 0\n\n 101\n\n Apr 29\n\n Solc-bin binaries hosting migration on 09/12/2025\n\n Announcements\n\n 0\n\n 124\n\n Dec 2025\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1269,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266438689,"hash":"0835ed6d76b53391ca76bd623751371cd67e32d7"}
{"url":"https://dev-forum.pyth.network/t/price-feeds-upcoming-deactivations-pyth-core-september-30th-2025/402/1","domain":"dev-forum.pyth.network","title":"Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025 - Announcements - Pyth Developer Forum","text":"gm gm Pythians\nThe Pyth contributors have rolled out Entropy V2, a major developer experience upgrade to Pyth’s on-chain randomness protocol.\nEntropy V2 introduces:\n\nConfigurable Gas Limits for Callbacks\nEnhanced Callback Statuses\nUpcoming Public Entropy Explorer\nImproved Reliability\n\nConfigurable Gas Limits \nNow, users can set custom gas limits for callbacks while requesting random numbers.\nfunction requestRandomNumberWithCustomGas(\n uint32 customGasLimit\n) external payable {\n // Calculate the fee for the custom gas limit\n uint256 fee = entropy.getFeeV2(customGasLimit);\n\n // Request random number with custom gas limit\n uint64 sequenceNumber = entropy.requestV2{ value: fee }(customGasLimit);\n}\n\nMoreover, IEntropyV2 introduces several new ways to request random numbers:\n\nrequestV2(): Uses an in-contract PRNG to generate user’s random number.\nrequestV2(uint32 gasLimit): Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, uint32 gasLimit): Uses provider passed in the argument + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\nrequestV2(address provider, bytes32 userRandomNumber, uint32 gasLimit): Uses provider passed in the argument + Uses user’s random number to generate + Sets the callback’s gasLimit passed by the user + Uses an in-contract PRNG\n\nEntropy uses 2-party random number generation procedure, which is an extension of a simple commit/reveal protocol. Please read the Protocol Design for the full explanation.\n\nNOTE: This update is backward compatible. If you are using Entropy already in your smart contracts, you don’t need to update your contracts unless you want to need custom gas limits for your callbacks.\n\nEnhanced Callback Statuses\nEntropy V2 introduces callback statuses, which allow users to track the status of their callbacks.\nThese callback statuses are emitted in the Revealed event. The new interface of the event includes bool callbackFailed flag, which helps users to easily tracks the status of their callbacks.\nevent Revealed(\n address indexed provider,\n address indexed caller,\n uint64 indexed sequenceNumber,\n bytes32 randomNumber,\n bytes32 userContribution,\n bytes32 providerContribution,\n bool callbackFailed,\n bytes callbackReturnValue,\n uint32 callbackGasUsed,\n bytes extraArgs\n);\n\nEntropy Explorer \nEntropy V2 introduces an public Entropy Explorer, which will allow teams to easily track the status of their callbacks and re-request them if they fail on-chain.\n\nImproved Reliability\nEntropy V2 introduces a more resilient callback architecture, adding an expanded keeper network which improves delivery guarantees.\nThis enhancement builds on the original design and enables requests to be fulfilled more reliably during unstable chain conditions.\nLet’s Discuss Entropy V2! \nThis is an open discussion thread for Entropy V2. Please use this space to:\nShare your feedback:\n\nIntegration experiences (smooth sailing or hit any bumps?)\nHow you’re using the new callback statuses for debugging\nCreative use cases for configurable gas limits\nPerformance improvements you’ve noticed\nSuggestions for future enhancements\n\nShow off your builds:\n\nProjects using Entropy V2 (screenshots welcome!)\nCode snippets demonstrating interesting implementations\nReal-world examples of the enhanced callback statuses in action\n\nAsk questions:\n\nTechnical implementation questions\nBest practices for specific use cases\nHelp with integration challenges\n\nResources\n\nGuide\nExamples\nContract Addresses\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 30th, 2025 \n\n Announcements\n\n announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 2025\n\n 1 / 4\n\n Sep 2025\n\n Oct 2025\n\n post by KemarTiti on Sep 30, 2025\n\n KemarTiti\n\n gm Pythians,\nAfter reviewing the Pyth Price Feeds onchain usage, their actual underlying tokens activity (i.e. volumes, liquidity), and exceptional news (token migration or else) it has been decided to sunset a few feeds. Please note that volumes, liquidity and other metrics are following this framework.\nAll below feeds are scheduled to be sunset on Tuesday 30th, September, 2025.\nIf you’re using or planning to use these feeds in any capacity, please let us know directly and we’ll be able to reassess the need for their deprecation.\n\nBOOP/USD\nCHUTES/USD\nCUSD/USD\nEVMOS/USD\nEURA/USD\nFAI/USD\nKEYCAT/USD\nMOD/USD (currently Sponsored)\nOMG/USD\nQUICK/USD\nSEAM/USD\nSHDW/USD\nTAOHASH/USD\nBRENTV5/USD (expired)\nWTIU5/USD (expired)\n\nIf edits were to be applied, they will be visible as a comment to this post.\n\n post by KemarTiti on Sep 12, 2025\n\n KemarTiti\n\n Two feeds were removed from the above list and their deprecation has been advanced to the 15th September, 2025.\nFind more details here: Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n post by KemarTiti on Sep 16, 2025\n\n 16 days later\n\n post by KemarTiti on Oct 2, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Price Feeds Upcoming Deactivations (Pyth Core) – August 18th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 697\n\n Aug 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – October 30th, 2025\n\n Announcements\n\n announcements\n\n 3\n\n 549\n\n Oct 2025\n\n Price Feeds Upcoming Deactivations – May 14, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 822\n\n May 2025\n\n Price Feeds Upcoming Deactivations (Pyth Core) – September 15th, 2025\n\n Announcements\n\n announcements\n\n 1\n\n 425\n\n Sep 2025\n\n Price Feeds Upcoming Deactivations – January 1st, 2026\n\n Announcements\n\n announcements\n\n 2\n\n 499\n\n Jan 3\n\n Powered by Discourse","tokens":1424,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266441693,"hash":"009f96916606e5ac388198843c06e02795f0e4f8"}
{"url":"https://forum.soliditylang.org/t/solidity-v0-8-35-is-out/3701","domain":"forum.soliditylang.org","title":"Solidity v0.8.35 is out! - Announcements - Solidity Forum","text":"Welcome to the Solidity Forum!\n This is not the place for…\n\nAd-hoc Solidity support questions. For urgent Solidity support questions, please check out the Ethereum StackExchange or use the Solidity Gitter or Matrix chat.\nSolidity bugs, vulnerabilities or issues. To report a bug, please use the GitHub issues tracker and refer to this guide on how to report issues.\nGeneric Ethereum discussion. For that visit r/ethereum.\nEthereum research specific discussion. For that, please refer to the ethresear.ch forum.\nEIP specific discussion. For that visit the Ethereum Magicians forum.\nAdvertisements for any products or services.\n\nNote that this forum is not a Solidity job board nor a support forum for issues with dApps or other applications. \n\nDO NOT post or advertise Solidity job openings here. Consider adding them to the jobs thread on r/ethdev, advertise in the WeekInEthereum newsletter or try specialised platforms, e.g. cryptocurrencyjobs.co\nDO NOT post user issues with dApps or other applications built with Solidity. Please reach out to the dApp support team directly via their social channels or file an issue in their respective GitHub repository.\n\nAll off-topic posts will be closed and deleted.\n This is the place to discuss topics related to…\n\nThe design of the Solidity programming language.\nThe Solidity compiler.\nSolidity documentation and its translation.\nDiscussions and announcements about Solidity releases.\n\n Code of Conduct\nPlease note that by participating in this forum you agree to abide by the terms of our Contributor Code of Conduct. Posts that are not respectful, constructive, or off-topic will be removed.\n Quick Guide to the Solidity Forum Categories\n\n”Announcements” is a low-traffic category for important announcements about the Solidity language and compiler.\n“Language Design” is the dedicated place for proposals and discussion on new language features and their implementation in the early stages of ideation or modifications of existing features.\n“Tools & Infrastructure” is the category for discussion about developer tooling, e.g. IDEs, debuggers, development frameworks, security tools, and infrastructure with a focus on the interactions and improvements between tooling and Solidity.\nDiscussions about the documentation and its translations can take place in the “Documentation” category.\nIn “Code Wizards” you can share useful tips or code snippets you came up with that are worth spreading. You can also discuss experimental Solidity implementations and get feedback on it.\n“Ask Me Anything” is where the Solidity team hosts regular AMAs, in which we are happy to answer your questions! If we host an AMA, one of our team members will open a new topic. Do not open your own topics in this category.\n\n New to Discourse?\nIf you are new to Discourse consider having a look at this “Unofficial Discourse User Reference Guide”, which summarizes useful tips on how to use Discord, text formatting, images, LaTex and more.\n Get Email Notifications!\nIf you don’t want to check the web interface regularly, don’t worry: You can get notifications from this forum via email! To edit your email preferences and enable the mailing list feature, visit your Profile → Preferences and scroll to Email. In the email settings you can define how often you’d like to receive emails. You can mute all topics and categories you are not interested in.\n\n Solidity v0.8.35 is out! \n\n Announcements\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 29\n\n 1 / 1\n\n Apr 29\n\n Apr 29\n\n post by czepluch on Apr 29\n\n czepluch\n\n Solidity Team\n\n Solidity v0.8.35 is out!\nThis release introduces Solidity’s first comptime builtin, formalizes how experimental features are exposed behind a new --experimental flag, and ships an experimental SSA CFG code generator targeting stack-too-deep and slow compilation in the IR pipeline.\nNotable features:\n\nerc7201 is the first comptime builtin in Solidity. It computes the base slot of an ERC-7201 namespaced storage layout from a namespace string, and its result is usable wherever a comptime expression is required, e.g. as the base slot in a layout at specifier.\n\nA new --experimental flag formalizes the experimental feature lifecycle. Using any in-development feature now requires --experimental (or settings.experimental in Standard JSON), and a new docs page lists what’s currently experimental.\n\nThe first major feature under the new experimental lifecycle is an SSA CFG code generator, a new EVM backend for the IR pipeline. The main motivations are stack-too-deep errors and slow compilation, both long-standing pain points. Enable with --experimental --via-ssa-cfg.\n\nv0.8.35 continues the 0.9.0 deprecation work started in 0.8.31, this time warning about identifiers that will be reserved as keywords in 0.9.0:\n\nSolidity: at, error, layout, leave, super, this, transient\nYul: a list of upcoming Yul builtins that will become Yul reserved identifiers.\n\nBugfix: in the IR pipeline (--via-ir), --revert-strings strip was over-stripping the custom-error argument of require(condition, CustomError(...)). A failed require would revert with empty error data instead of the encoded custom error. Fixed in 0.8.35.\n\nYou can read the full release announcement on our blog: Solidity 0.8.35 Release Announcement | Solidity Programming Language\nUsers can download the new version of Solidity Compiler from GitHub: Release Version 0.8.35 · argotorg/solidity · GitHub\nAnd lastly, a big thank you to all the contributors who helped make this release possible! \n\n New & Unread Topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pattern Matching Blog Post Released\n\n Announcements\n\n 0\n\n 79\n\n May 5\n\n Solidity Developer Survey 2025 Results\n\n Announcements\n\n 2\n\n 147\n\n Apr 27\n\n Solidity v0.8.34 is out! \n\n Announcements\n\n 1\n\n 143\n\n Apr 24\n\n Solidity v0.8.33 is out! \n\n Announcements\n\n 0\n\n 181\n\n Dec 2025\n\n Can a Solidity library be instantiated using new?\n\n Language Design\n\n 1\n\n 112\n\n Oct 2025\n\n Want to read more? Browse other topics in Announcements or view latest topics.","tokens":1522,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266449117,"hash":"1120e20d300640e04be1135cc1616627f83f631d"}
{"url":"https://forum.pyth.network/t/establish-a-process-for-new-price-feeds/1715?u=kemartiti","domain":"forum.pyth.network","title":"# Establish a Process for new Price Feeds - Ideas Bank - Pyth DAO","text":"# Establish a Process for new Price Feeds \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 5\n min\n\n Aug 2024\n\n 1 / 5\n\n Aug 2024\n\n Feb 24\n\n post by lawrencegs on Aug 27, 2024\n\n lawrencegs\n\n Dear Pyth DAO Members,\nThe Price Feed Council has historically managed the evaluation and approval of new assets for support based on criteria such as projected demand from downstream applications and the feasibility of sourcing sufficient data publishers to ensure operational stability.\nTo optimize this process and enhance transparency, as a representative of the Price Feed Council, I am proposing an open submission model. This would allow any interested party—whether a council member, community member, or project representative—to submit requests for the integration of new Pyth price feeds.\nTo facilitate the review and approval of your request, we (the Price Feed Council) strongly suggest everyone to follow the guidelines below. Your request will then be assessed by Pyth DAO members and the Price Feed Council to determine its feasibility and potential impact. Kindly include the following sections:\n1. Abstract\nThis section provides a comprehensive overview of the project or asset for which you are requesting a price feed. It should cover:\n\nProject Overview: Present a detailed description of your project. Explain how your project operates, its market position, and its potential impact on the industry. Highlight any unique features or innovations that set your project apart from others.\nHistory and Development: Offer a chronological account of your project’s development, from its inception to the present. Include key milestones, significant achievements, and technological advancements that have contributed to its growth. This context will help evaluate the project’s stability and growth trajectory.\nAchievements and Accolades: Enumerate notable achievements, such as awards, recognitions, or significant funding rounds. Mention any strategic partnerships or collaborations that have bolstered your project’s credibility and reach. Demonstrating past successes can provide assurance of your project’s viability.\nPartnerships: Detail any strategic partnerships, integrations, or collaborations with other organizations or projects.\n\n2. Rationale\nThis section should justify the need for the requested oracle feed by addressing the following:\n\nVolume and Listing Venues: Provide detailed metrics on the asset’s trading volume and its presence across trading venues. The Price Feed Council typically seeks assets with:\n\nTrading Volume: Daily trading volume of 3-5 million USD over the past 30 days.\nListing Venues: Support from at least 3 trading venues (both decentralized exchanges (DEXs) and centralized exchanges (CEXs)), each with a minimum of 3 distinct liquidity pools.\nVolume Concentration: At least 70% of the total daily trading volume should be in USD (or USD equivalent) to reduce cross-currency risk. We will use wstETH - stETH as an example where wstETH has 70% or more of stETH trading volume.\nAccepted sources include, but not limited to: Coingecko, Coinmarketcap\n\nUse Cases: Explain how the oracle feed will be used within your project or ecosystem. Detail specific use cases, such as its role in lending protocols, perpetual contracts, options trading, or other financial instruments.\nProtocols and Applications: List any specific protocols or applications that have expressed interest in or are planning to utilize the oracle feed. Describe their function and relevance to your project, and outline how they will leverage the feed’s data. Provide evidence of interest or commitment from these entities if available.\nVerticals: If specific protocols are not yet identified, describe the broader industry verticals that will benefit from the feed. For example, detail how the feed could enhance DeFi platforms, trading systems, or other financial services. Justify why these verticals are significant and how the oracle feed will fill existing gaps or enhance functionalities.\n\n3. Proposed Plan\nOutline your plan for the oracle feed integration, including:\n\nMonetary Compensation: Define any financial compensation or incentives you are offering to the Pyth DAO for the integration and maintenance of the oracle feed. This might include a one-time payment, ongoing fees, performance-based rewards, or other forms of financial support. Be specific about the structure and timing of these compensations.\nUsage and Demand: Provide detailed projections or data on the anticipated usage of the feed. Explain how various protocols or applications will utilize the feed and the expected volume of transactions or queries. This information will help assess the feed’s potential value and relevance.\nAdditional Benefits: Highlight any additional benefits that the oracle feed will bring to the Pyth Network. This could include improved data accuracy, broader market coverage, enhanced functionality for existing protocols, or any other unique advantages that distinguish your feed from others.\n\n4. References\nProvide relevant contact information and links for further investigation:\n\nSocial Media Profiles: Include links to your project’s official social media channels (e.g., Telegram, Discord, Twitter) where DAO members can follow updates and engage with your community.\nOfficial Website: Provide the URL to your project’s official website for more comprehensive information about your project and its activities.\nOther Resources: Share any additional resources that could be useful for understanding your project and the need for the oracle feed. This might include whitepapers, technical documentation, or previous press releases.\n\nI look forward to the inputs and thoughts from the DAO community members.\n\n Price Feed Request: Bio Protocol (BIO)\n\n read \n\n 5\n min\n\n post by Derrp on Aug 27, 2024\n\n post by bats4 on Aug 27, 2024\n\n post by arguer on Aug 31, 2024\n\n 1 year later\n\n post by iaero on Feb 24\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Implement Fees on Pyth Core Across Networks #2\n\n Ideas Bank\n\n 22\n\n 1.2k\n\n Jun 2025\n\n Implement Fees on Pyth Core Across Networks\n\n Ideas Bank\n\n 22\n\n 1.0k\n\n Feb 2025\n\n Switching oracle fees ($13m opportunity per year) and reinvesting in growth\n\n Ideas Bank\n\n 14\n\n 714\n\n Feb 6\n\n [Price Feed Council Election #5], Wattson, Aristophanes / Pythagoras - Pyth Network Discord\n\n Price Feed Council\n\n 0\n\n 47\n\n May 22\n\n Community Content Ideas\n\n Community Library\n\n 5\n\n 246\n\n Apr 22","tokens":1637,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266452676,"hash":"0ff21c31712bf319593b070605860199c2a9b80d"}
{"url":"https://www.soliditylang.org/blog/2026/04/29/solidity-0.8.35-release-announcement","domain":"soliditylang.org","title":"Solidity 0.8.35 Release Announcement | Solidity Programming Language","text":"Solidity 0.8.35 Release AnnouncementPosted by Solidity Team on April 29, 2026ReleasesWe are excited to announce the release of the Solidity Compiler v0.8.35!\nThis release introduces a new builtin, erc7201, that computes the base slot of an ERC-7201 namespaced storage layout from its namespace string.\nIt also formalizes how experimental features are exposed to users: in-development functionality is now gated behind a new top-level --experimental flag, with a documented lifecycle and a canonical list of which features are currently considered experimental.\nThe first major code-generation feature shipped under this new lifecycle is an experimental SSA-form control-flow graph (SSA CFG) code generator that we expect to be the long-term answer to long compilation times as well as stack-too-deep errors in the IR pipeline.\nOn the bugfix side, the IR pipeline no longer over-strips custom errors when compiled with --revert-strings strip.\nIt also continues the 0.9.0 deprecation work started in 0.8.31, this time warning about identifiers that will be promoted to keywords in 0.9.0.\nSome of these features were previously available in the v0.8.35-pre.1 pre-release we shared back in March.\nNotable Features and Changes\nerc7201 Comptime Builtin\nSolidity 0.8.35 introduces a new builtin function:\nfunction erc7201(string memory id) returns (uint)\n\nIt computes the base storage slot for a namespace string using the formula defined in ERC-7201, equivalent to keccak256(keccak256(id) - 1) & ~0xff.\nERC-7201 formalizes the practice of placing a contract's state behind a hashed namespace to avoid storage collisions in proxy-based and diamond-style upgradeable patterns.\nThe builtin pairs naturally with the layout at storage layout specifier introduced in 0.8.29 and extended in 0.8.31:\ncontract MyContract layout at erc7201(\"openzeppelin.storage.MyContract\") {\n uint256 x;\n uint256 y;\n}\n\nWhat makes erc7201 special is that it is the first comptime builtin in the language.\nUntil now, Solidity's comptime evaluator only handled arithmetic on rational number literals.\nExisting builtins like keccak256 do get folded by the codegen at the optimization stage; you get the gas savings, but not the type-system benefit of being usable in a comptime context such as a layout specifier.\nerc7201 is the first builtin whose result can be used wherever a comptime expression is required: as the base slot in layout at, or as an array length.\nThis directly addresses one of the limitations we flagged in 0.8.31, and we expect more such builtins as we work toward a more capable comptime evaluator.\nFormalizing the Experimental Feature Process\nPast releases have shipped a number of in-development features that could be enabled through a mix of ad-hoc CLI flags and pragma experimental directives.\nThere was no consistent way for a user to know they were opting into something unstable, and the metadata signaling was patchy.\nWith 0.8.35 we are formalizing this.\nThe full process is described in the new Experimental Mode docs page; the key user-facing changes are below.\nThe --experimental Flag\nUsing any experimental feature now requires the new top-level --experimental flag, or the analogous boolean settings.experimental field in Standard JSON input.\n--experimental is a master toggle: it does not enable any specific feature on its own, but is required for any of the per-feature flags or pragmas to be accepted.\nThe current list of experimental features, their IDs and the flags or pragmas that drive each one is maintained in the Experimental Mode docs page.\nUsing any of those without --experimental is now a hard error.\nUsers who were already passing the affected flags directly will need to add --experimental (or set settings.experimental: true in JSON input) to keep their builds working.\nThis is not a backwards-compatibility break: experimental features have always been excluded from our compatibility guarantees.\nWhat is new is making that explicit at the user-facing surface, so that no one is opting into experimental functionality without realizing it: experimental features come with no stability guarantees and may change in breaking ways even in non-breaking releases of the compiler.\nRecorded in Metadata\nWhether a contract was compiled with experimental mode enabled is now recorded in both JSON and CBOR metadata.\nThe CBOR experimental field, which previously only signalled experimental pragmas in the source, has been broadened to cover this.\nThis also closes a known gap: targeting an unreleased EVM version used to produce experimental bytecode without flipping the flag.\nExperimental SSA CFG Code Generator\nSolidity 0.8.35 ships an experimental new EVM backend for the IR pipeline.\nIt generates bytecode from the program's SSA-form control-flow graphs (the \"SSA CFGs\", one per function), with a precomputed stack layout that the backend shuffles the EVM stack to match.\nWhy we are building it: the IR pipeline has two long-standing pain points, stack-too-deep errors and slow compilation, and an SSA-based backend addresses both.\nStack-too-deep remained the most commonly reported recurring issue in our 2025 Developer Survey, and compilation via IR has long been measurably slower than the evmasm pipeline.\nThe current Yul-to-EVM code transform relies on heuristics that struggle with deeply nested expressions and complex control flow, and the same algorithmic issues contribute to long compilation times.\nAn SSA-based backend gives us a much stronger foundation for stack scheduling and compilation performance, and we see it as the realistic long-term path to addressing both.\nIf you want a deeper look at how the SSA CFG works, we covered it in a talk at Solidity Summit.\nEnable the codegen with --experimental --via-ssa-cfg on the command line, or settings.experimental: true together with settings.viaSSACFG: true in Standard JSON.\nBoth imply --via-ir.\nThis is an early experimental release. Several pieces are not yet in:\n\nStack-to-memory spilling has not yet been ported to the SSA backend.\nOptimizer passes specific to the SSA CFG are still in development.\nCompilation-performance work, one of the long-term motivations, has not landed.\nCases that exhaust the stack scheduler currently surface as internal compiler errors rather than graceful \"stack too deep\" or spilling diagnostics.\n\nThe codegen is exercised against the full external-contract semantic test suite on every PR, but it is not yet the default for --via-ir, and gas data alone will not be sufficient to promote it.\nBefore this becomes the default we expect to put it through review, fuzzing, and likely an external audit.\nPer the new experimental policy, only major changes affecting the SSA CFG codegen will be recorded in the changelog.\nDeprecation Warnings for Upcoming 0.9.0 Keywords\nContinuing the deprecation work started in 0.8.31, this release adds warnings for identifiers we plan to promote to keywords in 0.9.0.\nWhere 0.8.31's deprecations were about features being removed, this batch is about names being claimed.\nSolidity declarations using at, error, layout, leave, super, this, or transient will now emit a warning.\nIn Yul (standalone or inline assembly), leave will become a Yul keyword, and basefee, blobbasefee, blobhash, clz, mcopy, memoryguard, prevrandao, tload, and tstore will become Yul reserved identifiers.\nThe latter are all Yul builtins, which we normally keep reserved; the growing list of exceptions is a quirk of the unusually long 0.8.x release cycle, since our backwards-compatibility policy holds them until 0.9.0.\nThese are warnings, not errors. Existing code continues to compile; you have a window to rename affected declarations before 0.9.0 turns the warnings into errors.\n--revert-strings strip and Custom Errors\n--revert-strings strip (revertStrings: \"strip\" in Standard JSON) is a gas-saving option: bytecode is smaller without revert reason strings, and reverts still happen.\nThe implicit assumption was that returndata is a way to deliver a nice message to a user, not a piece of structured data that another contract should depend on.\nrequire(condition, CustomError(...)) complicates that picture, because a custom error encodes structured data.\nUntil 0.8.35, the IR pipeline (--via-ir) was stripping the custom-error argument of require along with strings, so a failed require reverted with empty error data instead of the encoded custom error.\nThe evmasm pipeline behaved differently.\nThe bug here is the discrepancy between pipelines: it could in principle be fixed either way, and we chose to keep the custom error rather than extend --revert-strings strip into a third meaning.\nThis only affected require(), not plain revert statements with a custom error, and only on the IR pipeline.\nIt has been present since require(bool, error) was introduced in 0.8.26 and is fixed in 0.8.35.\nethdebug Output Reorganization\nThis release reorganizes the ethdebug output selection to be more granular and consistent with how other outputs are exposed.\n--ethdebug and --ethdebug-runtime are replaced by --ethdebug-resources, --ethdebug-compilation, --ethdebug-program, and --ethdebug-program-runtime, with analogous keys in Standard JSON.\nethdebug outputs no longer force a full binary compilation, and ethdebug remains experimental, now gated behind --experimental like the other experimental features.\nFull Changelog\nLanguage Features\n\nGeneral: Add a builtin that computes the base slot of a storage namespace using the erc7201 formula from ERC-7201.\nName Resolver: Warn about identifiers selected for future promotion to Solidity or Yul keywords (at, error, layout, leave, super, transient, this).\nYul Analyzer: Warn about identifiers selected for future promotion to Yul keywords and reserved identifiers (basefee, blobbasefee, blobhash, clz, leave, memoryguard, mcopy, prevrandao, tload, tstore).\n\nCompiler Features\n\nCommandline Interface: Disallow selecting the deprecated assembly input mode that was only accessible via --assemble instead of treating it as equivalent to --strict-assembly.\nCommandline Interface: Introduce --experimental flag required for enabling the experimental mode.\nCommandline Interface: Replace the experimental --ethdebug and --ethdebug-runtime outputs with the more granular --ethdebug-resources, --ethdebug-compilation, --ethdebug-program and --ethdebug-program-runtime. Producing ethdebug/format/info/resources no longer forces full binary compilation.\nEVM: Introduce experimental EVM version @future.\nGeneral: Improve performance of sanity checks throughout the compiler implementation.\nGeneral: Introduce the SSA CFG codegen (experimental).\nGeneral: Restrict the existing experimental features (generic-solidity, lsp, ethdebug, eof, evm, ast-import, evmasm-import, ir-ast, ssa-cfg) to experimental mode.\nMetadata: Store the state of the experimental mode in JSON and CBOR metadata. In CBOR this broadens the meaning of the existing experimental field, which used to indicate only the presence of certain experimental pragmas in the source.\nStandard JSON Interface: Introduce settings.experimental setting required for enabling the experimental mode.\nStandard JSON Interface: Replace the experimental top-level ethdebug output with ethdebug.resources and ethdebug.compilation. Decouple ethdebug outputs from binary compilation so that requesting the ethdebug/format/info/resources schema artifacts does not trigger bytecode generation.\nYul Optimizer: Improve performance of control flow side effects collector and function references resolver.\n\nBugfixes\n\nYul: Fix incorrect serialization of Yul object names containing double quotes and escape sequences, producing output that could not be parsed as valid Yul.\nYul EVM Code Transform: Improve stack shuffler performance by fixing a BFS deduplication issue.\nYul IR Code Generation: Preserve custom error argument of require when stripping of revert strings is selected via --revert-strings strip.\n\nHow to Install/Upgrade?\nTo upgrade to the new version of the Solidity Compiler, please follow the installation instructions available in our documentation.\nYou can download the release from GitHub: v0.8.35.\nIf you want to build from the source code, do not use the source archives generated automatically by GitHub.\nInstead, use the solidity_0.8.35.tar.gz source tarball or check out the v0.8.35 tag via git.\nAnd last but not least, we would like to give a big thank you to all the contributors who helped make this release possible!Previous postNext post","tokens":3118,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266459810,"hash":"e61aa81cb846973e6c017336163302253507a0f6"}
{"url":"https://forum.pyth.network/c/ideas-bank/2","domain":"forum.pyth.network","title":"Latest Ideas Bank topics - Pyth DAO","text":"Latest topics in Ideas Bank\n\n Ideas Bank\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n READ FIRST: How to Use the Ideas Bank\n\n The Ideas Bank is for Pyth community members to suggest, discuss, and debate early-stage ideas before the proposal stage. \nIf you wish to create a new topic regarding Oracle Integrity Staking (OIS), please create it in t…\n\n read more\n\n 0\n\n 1.0k\n\n May 2024\n\n Pyth Strategic Reserve V2: Aligning PYTH Accumulation with Pyth Pro Revenue\n\n 5\n\n 322\n\n 27d\n\n Should We Move the Pyth Wheel Back to Base or Monad?\n\n 5\n\n 136\n\n 27d\n\n Proposal: Introduce PYTH as an Optional Payment Token for Pyth Network Services\n\n 3\n\n 91\n\n Aug 31\n\n Idea Proposal: Community Custom Indices on Pyth Pro\n\n operational-pip\n\n 9\n\n 184\n\n Aug 31\n\n Pythenians II. Scope of work & budget request\n\n 10\n\n 488\n\n Aug 31\n\n Proposal: Introduce PYTH as a Payment Option for Pyth Network Services\n\n 0\n\n 39\n\n Aug 29\n\n The ceaseless decline in coin prices\n\n 3\n\n 167\n\n Aug 17\n\n Q3 2026 — Pyth Core Onchain Fees: Final Review\n\n 6\n\n 166\n\n Aug 3\n\n Operationalizing Cross-Chain Fee Repatriation\n\n 2\n\n 99\n\n Jul 19\n\n Douro Labs Proposes to Acquire Express Relay\n\n 10\n\n 368\n\n Jul 16\n\n Q3 2026 — Pyth Entropy Protocol Fee Adjustments\n\n 2\n\n 91\n\n Jul 13\n\n Q3 2026 — Pyth Express Relay Fees: On Hold Pending Acquisition Vote\n\n 0\n\n 33\n\n Jul 13\n\n Complementary Proposal to Pyth Reserve Evolution: Onchain Burn for Pyth Entropy Protocol Fees\n\n operational-pip\n\n 7\n\n 228\n\n Jul 10\n\n Has anyone experimented with Pyth price feeds outside of traditional DeFi applications?\n\n 1\n\n 63\n\n Jul 4\n\n Pythenians 2.0 Key Proposal summary\n\n 14\n\n 651\n\n Jun 30\n\n [OP-PIP] Implement PythWheel Burn Registry: 100 PYTH Permanent Burn per Spin Community Deflation Mechanism\n\n operational-pip\n\n 17\n\n 506\n\n Jun 25\n\n Idea: Pyth Reserve Evolution: Ratio-Based Management + Sustainable Partial Burns\n\n operational-pip\n\n 3\n\n 269\n\n Jun 22\n\n Pythenians 2.0\n\n 43\n\n 1.6k\n\n Jun 3\n\n Approaching Apple Google + Other AI Tech\n\n 3\n\n 104\n\n May 27\n\n Pyth Reserve v2: Ratio-Based Treasury Management\n\n 3\n\n 270\n\n May 21\n\n Pyth Token Phase 3\n\n 22\n\n 1.4k\n\n May 20\n\n Pyth Pro Individual Tier\n\n 10\n\n 270\n\n May 18\n\n Adding an investor relation page to the Pyth Network website\n\n 1\n\n 92\n\n May 2\n\n Hardening the Human Layer: Multi-Disciplinary(Finance,Psychology,NLP,Game-Theory,Forensic,Black-swans) SOPs & Sybil-Resistant Reporting\n\n operational-pip\n\n 1\n\n 70\n\n May 1\n\n Flexible Payment Currency for Pyth Pro, LaaS, and Marketplace Revenue\n\n 5\n\n 224\n\n Apr 29\n\n Q2 2026 - Pyth Express Relay: A Path Forward\n\n 6\n\n 273\n\n Apr 28\n\n Q2 2026 — Pyth Core Onchain Fees\n\n 3\n\n 137\n\n Apr 28\n\n Q2 2026 — Pyth Entropy Onchain Fees\n\n 4\n\n 200\n\n Apr 28\n\n Allocating a portion of Experiment Labs budget for Video Content Creation\n\n 8\n\n 276\n\n Apr 27","tokens":701,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266462997,"hash":"abff000737cf3b44849e90f284b3b31b37fe9d87"}
{"url":"https://soliditylang.org/blog/2025/12/03/solidity-0.8.31-release-announcement/","domain":"soliditylang.org","title":"Solidity 0.8.31 Release Announcement | Solidity Programming Language","text":"Solidity 0.8.31 Release AnnouncementPosted by Solidity Team on December 3, 2025ReleasesSolidity 0.8.31 Release Announcement\nWe are excited to announce the release of the Solidity Compiler v0.8.31!\nThis version of the compiler brings support for the new EVM features introduced by the Fusaka network upgrade, extends the functionality of storage layout specifiers and deprecates the first batch of features scheduled for removal in the 0.9.0 breaking release.\nWe are also adding official ARM Linux builds.\nNotable Features and Changes\nFusaka Support\nosaka by Default\nWith Fusaka scheduled to go on the mainnet, we are making it the default target for the compiler.\nAs always, you can still select an older version with --evm-version/settings.evmVersion.\nCLZ Opcode\nThis release of the Solidity Compiler includes support for the CLZ opcode (EIP-7939).\nThe feature was already available in our recent pre-release.\nThe opcode counts the number of leading zero bits in a 256-bit word.\nThe operation is a basic building block useful for bit manipulation, compression algorithms and some data structures.\nIn terms of the current compiler implementation, the applications for this opcode are limited, but we are exploring it potential for future optimisations.\nThe place where its benefits will be fully realized is the application layer.\nLibraries such as solady have many uses for it and it will be able to replace existing utilities such as Math.clz() in OpenZeppelin.\nChanges to the Release Process\nLinux ARM Releases\nStarting with this release, we will be providing official Linux binaries for the ARM architecture.\nWe expect this to be useful not only to developers using Linux as their main operating system, but also users of other systems on ARM hardware running the compiler binary in Linux containers, e.g., using Docker.\nNote that ARM support in the compiler is not a new thing - we have already been providing binaries for ARM-based macs and it was always possible to build the compiler from source on Linux on ARM.\nWhat we are introducing here is the integration of those binaries into our CI and release infrastructure.\nWhile unofficial ARM builds have been available for a while from third-party sources, now you can obtain them from the same source as all the other official compiler binaries.\nThis also means that they go through our full testing process, including checks that the produced bytecode and metadata are identical between all supported platforms.\nIntroducing Pre-releases\nUntil now, we only offered full releases of the compiler and nightly builds.\nWith v0.8.31-pre.1 we shared back in October, we introduced a more lightweight process to bridge the gap and let us share experimental features earlier.\nThe pre-release already included some of the features we are presenting here, such as the support for the CLZ opcode.\nCheck out the Twitter announcement for more details!\nDiscontinuation of PPA Releases\nOn every release, we provide compiler binaries via multiple channels, some of which are not widely used.\nTo reduce maintenance burden, we have been planning to discontinue some of them.\nAs the first step, with this release we are officially discontinuing our Ubuntu PPA as a binary distribution channel.\nWe intend to keep the Docker releases for at least one more release, but they will most likely be discontinued as well if we determine that the usage is marginal.\nNote, however, that they were migrated from DockerHub to Github's container registry and new binaries will also appear there.\nConstants in Storage Layout Specifiers\nVersion 0.8.31 of the Solidity Compiler further extends the features of storage layout specifiers.\nIt is now possible to use constant variables in the base slot expression:\nuint constant OFFSET = 0x10 + 1;\n\ncontract C layout at 0xAAAA + OFFSET {\n uint[3] x; // Occupies slots 0xAABB..0xAABD\n}\n\nPlease keep in mind that compile-time evaluation capabilities in Solidity are still very limited and only cover arithmetic expressions involving rational number literals.\nThese calculations are always performed in unlimited precision, so introducing values that have a finite-precision integer type into the expression (through explicit type conversions, use of some builtins, use of ternary operator, etc) will result in a compilation error.\nThis limitation extends to the expressions used to initialize constants.\nWe are planning to extend the range of allowed expressions a bit further in upcoming releases, in particular by defining special builtins for common expressions to sidestep these limitations, but anything beyond that will require adding a more robust compile-time evaluation system to the language.\nFeature Deprecations\nThe 0.9.0 breaking release will be all about dropping old baggage and making the compiler leaner.\nIn preparation for that we are starting to introduce deprecation warnings for features, which we will be removing.\nFor now these include:\nRemoval of <address>.send() and <address>.transfer() Functions.\nThese functions were originally introduced to allow ether transfers without letting the callee perform any complex actions.\nAs the EVM does not offer any straightforward way to only transfer ether without also executing the target contract, some gas always needs to be forwarded, but these functions limit it to a hard-coded stipend of 2300 gas.\nThis used to be just enough to read from storage and emit events, but not to perform reentrant calls and write to storage.\nUnfortunately, this came with an implicit assumption that opcode pricing will never change, which quickly turned out not to be the case.\nNowadays their use is widely considered an anti-pattern and <address>.call() with empty payload is the recommended alternative.\nPlease keep in mind that this does not provide any reentrancy protection, because by default the amount of gas forwarded to the callee is not limited.\nIf you were relying on send() and transfer() specifically for this property, you should consider a different mechanism, such as a reentrancy guard in transient storage or restructuring your code to use the checks-effects-interactions pattern.\nSimple ether transfers are still useful, but there is no way for the compiler to introduce such a mechanism in a future-proof way.\nThis needs a solution at the EVM level, such as the EIP-5920: PAY opcode, which could be exposed as <address>.pay() if/when it becomes available.\nRemoval of ABI Coder V1.\nABI coder v2 was introduced as an experimental feature all the way back in 0.4.19.\nAt first it had to be explicitly enabled using the ABI coder pragma (which back then was an experimental pragma).\nWe started considering it stable in the 0.7 release cycle and with 0.8.0 it became the default.\nv2 is a drop-in replacement for v1 and provides all of its features while adding extra capabilities: support for structs, support for arbitrarily nested arrays and more extensive input validations.\nThe rewrite was necessary to make the ABI coder usable with the IR pipeline.\nABI coder v1 is an option only for the legacy evmasm pipeline.\nIn fact, when compiling with --via-ir the compiler ignores the pragma and always uses v2.\nv2 was implemented in Yul from the very beginning and is usable with both.\nABI coder v1 is completely obsolete by now and will eventually be removed.\nRemoval of Virtual Modifiers\nJust like ordinary functions, modifiers can be declared virtual and overridden in derived contracts.\nWe generally found this feature to be suprising and poorly understood by users, mainly serving as a source of tricky corner cases in the compiler implementation.\nSince inheritance is already a source of a lot of unnecessary complexity in the language and virtual modifiers are not an essential feature (note that we are not removing the ability to invoke virtual functions from within modifiers), we decided to remove them.\nRemoval of Contract Comparison Operators\nSince variables of contract types are essentially just a thin abstraction around address, historically the language allowed operations that make sense for addresses to be performed on them as well.\nIn fact, until 0.5.0, all address members were also available on contract types.\nThis has changed with the push for more explicit conversions and nowadays there is a much clearer distinction between addresses and contract types.\nHowever, one vestige of the old system is the fact that you can use comparison operators on contracts.\nAnd not only == and !=.\nAn inequality such as c < d is still a valid expression when c and d represent contracts.\nIt may not be clear what exactly is being compared here and, since contracts are syntactically quite similar to structs, it is not entirely unreasonable for the user to assume that the result is somehow determined by the contract's members.\nIn 0.9.0 we will start requiring an explicit conversion to address for such operations to make semantics clear.\nRemoval of memory-safe-assembly Special Comment\nInline assembly allows code that can use memory in a way incompatible with the Solidity's memory model.\nBecause of that, certain memory optimizations are, by default, globally disabled in the presence of any inline assembly block that contains a memory operation or assigns to a Solidity variable in memory.\nTo side-step this problem, the language allows the programmer to declare that an assembly block is in fact perfectly safe, using the memory-safe annotation:\nassembly (\"memory-safe\") {\n ...\n}\n\nHowever, since it cannot be used on versions released before it was introduced, we also provided an alternative, backwards-compatible temporary mechanism for annotating such blocks using a special Natspec comment:\n/// @solidity memory-safe-assembly\nassembly {\n ...\n}\n\nSince 0.9.0 will be not be backwards-compatible with previous versions anyway, we will be removing this alternative mechanism.\nFull Changelog\nLanguage Features\n\nCustom Storage Layout: Allow using constant state variables in the base slot expression.\nDocString Parser: Warn about deprecation of inline assembly special comment memory-safe-assembly.\nSyntax Checker: Warn about deprecation of ABI coder v1.\nSyntax Checker: Warn about deprecation of virtual modifiers.\nType Checker: Warn about deprecation of send and transfer functions on instances of address.\nType Checker: Warn about deprecation of comparisons between variables of contract types.\nYul: Introduce builtin clz(x) for counting the number of leading zero bits in a 256-bit word.\n\nCompiler Features\n\nethdebug: Experimental support for instructions and source locations under EOF.\nEVM: Set default EVM Version to osaka.\n\nBugfixes\n\nAssembler: Fix not using a fixed-width type for IDs being assigned to subassemblies nested more than one level away, resulting in inconsistent --asm-json output between target architectures.\nYul Optimizer: Fix edge case in which invalid Yul code is produced by ExpressionSimplifier due to expressions being substituted that contain out-of-scope variables.\n\nBuild System:\n\nEnable Linux arm64 binaries for testing and releases.\nUbuntu PPA Packages: Discontinue the PPA as a binary distribution channel.\nUpdate minimum version requirements of Boost to 1.83.0 for non-windows builds and of GCC and Clang to 13.3 and 18.1.3, respectively. Fixes infinite recursion on boost::rational comparison affecting compiler binaries built with GCC<14.0 and Boost<1.75.\n\nHow to Install/Upgrade?\nTo upgrade to the latest version of the Solidity Compiler, please follow the installation instructions available in our documentation.\nYou can download the new version of Solidity here: v0.8.31.\nIf you want to build from the source code, do not use the source archives generated automatically by GitHub.\nInstead, use the solidity_0.8.31.tar.gz source tarball or check out the v0.8.31 tag via git.\nAnd last but not least, we would like to give a big thank you to all the contributors who helped make this release possible!Previous postNext post","tokens":2978,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266469925,"hash":"8f9de1978d5eaf5dbea19b6c0c8648504cb71117"}
{"url":"https://forum.pyth.network/t/about-the-pyth-dao/14","domain":"forum.pyth.network","title":"About the Pyth DAO - About the Pyth DAO - Pyth DAO","text":"About the Pyth DAO \n\n About the Pyth DAO\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Apr 2024\n\n 1 / 7\n\n Apr 2024\n\n Apr 2024\n\n post by Pyth-DAO on Apr 22, 2024\n\n Pyth-DAO\n\n The Pyth DAO LLC, is legally structured as “a non-profit DAO LLC formed under the laws of the Republic of Marshall Islands, formed to serve the Pyth DAO LLC” (of which the OPERATING AGREEMENT OF PYTH DAO LLC is available here).\nThe Pyth DAO LLC is algorithmically managed, such that actions taken by the Pyth DAO via the governance contract on the Solana Blockchain are deemed to be actions of the Pyth DAO LLC.\nThe legal entity enables the Pyth DAO LLC to hold the treasury and pay Pyth DAO related costs and expenses, protect Pyth DAO members from unlimited liability, and allow Pyth DAO members to take part in governance by providing a clear framework in respect of the rights and duties of Pyth tokenholders that hold PYTH Tokens.\nThe Pyth DAO LLC, among other capabilities, enables Pyth DAO members to take part in the governance of the Pyth Network by providing a framework in respect to the rights and duties of PYTH Token holders.\nIndividuals or entities who stake PYTH Tokens in the staking program will become members of the Pyth DAO LLC.\nPyth Improvement Proposals (PIPs) are the primary methods to introduce, discuss, and implement changes to the Pyth DAO Constitution, governance, and the oracle network’s operations.\nIdeation and discussion of PIPs are expected to take place within the official governance forum here and in Pyth’s Discord.\nFor more details please refer to the Pyth DAO Constitution.\n\n READ FIRST: About Pyth Improvement Proposals (PIPs)\n\n Pinned on Apr 22, 2024\n\n 16 days later\n\n Closed on May 9, 2024\n\n Unpinned on May 9, 2024\n\n Pinned globally on May 9, 2024\n\n Unpinned on May 9, 2024\n\n Pinned globally on May 9, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [PASSED] CO-PIP-1 : Adoption of the Pyth DAO Constitution\n\n Proposals\n\n constitutional-pip\n\n 0\n\n 364\n\n May 2024\n\n [PASSED] OP-PIP-117: PYTH Token Phase 2 — Purchases #7\n\n Proposals\n\n operational-pip\n\n 0\n\n 121\n\n Jun 2\n\n [PASSED] OP-PIP-88: PYTH Token Phase 2 — Purchases #2\n\n Proposals\n\n operational-pip\n\n 1\n\n 381\n\n Jan 8\n\n [PASSED] OP-PIP-115: PYTH Token Phase 2 — Purchases #6\n\n Proposals\n\n operational-pip\n\n 1\n\n 168\n\n May 6\n\n READ FIRST: About Pyth Improvement Proposals (PIPs)\n\n Proposals\n\n 0\n\n 1.1k\n\n May 2024","tokens":617,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266482663,"hash":"440ae5fd80f43b0a80f79ed4898bc799db55c18a"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/access-control","domain":"docs.openzeppelin.com","title":"Access Control | OpenZeppelin Docs","text":"OpenZeppelin ContractsAccess ControlOpen in ClaudeAccess control—that is, \"who is allowed to do this thing\"—is incredibly important in the world of smart contracts. The access control of your contract may govern who can mint tokens, vote on proposals, freeze transfers, and many other things. It is therefore critical to understand how you implement it, lest someone else steals your whole system.\nOwnership and Ownable\nThe most common and basic form of access control is the concept of ownership: there’s an account that is the owner of a contract and can do administrative tasks on it. This approach is perfectly reasonable for contracts that have a single administrative user.\nOpenZeppelin Contracts provides Ownable for implementing ownership in your contracts.\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.20;\n\nimport {Ownable} from \"@openzeppelin/contracts/access/Ownable.sol\";\n\ncontract MyContract is Ownable {\n constructor(address initialOwner) Ownable(initialOwner) {}\n\n function normalThing() public {\n // anyone can call this normalThing()\n }\n\n function specialThing() public onlyOwner {\n // only the owner can call specialThing()!\n }\n}\nAt deployment, the owner of an Ownable contract is set to the provided initialOwner parameter.\nOwnable also lets you:\n\ntransferOwnership from the owner account to a new one, and\nrenounceOwnership for the owner to relinquish this administrative privilege, a common pattern after an initial stage with centralized administration is over.\n\nRemoving the owner altogether will mean that administrative tasks that are protected by onlyOwner will no longer be callable!\nOwnable is a simple and effective way to implement access control, but you should be mindful of the dangers associated with transferring the ownership to an incorrect account that can’t interact with this contract anymore. An alternative to this problem is using Ownable2Step; a variant of Ownable that requires the new owner to explicitly accept the ownership transfer by calling acceptOwnership.\nNote that a contract can also be the owner of another one! This opens the door to using, for example, a Gnosis Safe, an Aragon DAO, or a totally custom contract that you create.\nIn this way, you can use composability to add additional layers of access control complexity to your contracts. Instead of having a single regular Ethereum account (Externally Owned Account, or EOA) as the owner, you could use a 2-of-3 multisig run by your project leads, for example. Prominent projects in the space, such as MakerDAO, use systems similar to this one.\nRole-Based Access Control\nWhile the simplicity of ownership can be useful for simple systems or quick prototyping, different levels of authorization are often needed. You may want an account to have permission to ban users from a system, but not create new tokens. Role-Based Access Control (RBAC) offers flexibility in this regard.\nIn essence, we will be defining multiple roles, each allowed to perform different sets of actions. An account may have, for example, 'moderator', 'minter' or 'admin' roles, which you will then check for instead of simply using onlyOwner. This check can be enforced through the onlyRole modifier. Separately, you will be able to define rules for how accounts can be granted a role, have it revoked, and more.\nMost software uses access control systems that are role-based: some users are regular users, some may be supervisors or managers, and a few will often have administrative privileges.\nUsing AccessControl\nOpenZeppelin Contracts provides AccessControl for implementing role-based access control. Its usage is straightforward: for each role that you want to define,\nyou will create a new role identifier that is used to grant, revoke, and check if an account has that role.\nHere’s a simple example of using AccessControl in an ERC-20 token to define a 'minter' role, which allows accounts that have it to create new tokens:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {AccessControl} from \"@openzeppelin/contracts/access/AccessControl.sol\";\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract AccessControlERC20MintBase is ERC20, AccessControl {\n // Create a new role identifier for the minter role\n bytes32 public constant MINTER_ROLE = keccak256(\"MINTER_ROLE\");\n\n error CallerNotMinter(address caller);\n\n constructor(address minter) ERC20(\"MyToken\", \"TKN\") {\n // Grant the minter role to a specified account\n _grantRole(MINTER_ROLE, minter);\n }\n\n function mint(address to, uint256 amount) public {\n // Check that the calling account has the minter role\n if (!hasRole(MINTER_ROLE, msg.sender)) {\n revert CallerNotMinter(msg.sender);\n }\n _mint(to, amount);\n }\n}\nMake sure you fully understand how AccessControl works before using it on your system, or copy-pasting the examples from this guide.\nWhile clear and explicit, this isn’t anything we wouldn’t have been able to achieve with Ownable. Indeed, where AccessControl shines is in scenarios where granular permissions are required, which can be implemented by defining multiple roles.\nLet’s augment our ERC-20 token example by also defining a 'burner' role, which lets accounts destroy tokens, and by using the onlyRole modifier:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {AccessControl} from \"@openzeppelin/contracts/access/AccessControl.sol\";\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract AccessControlERC20Mint is ERC20, AccessControl {\n bytes32 public constant MINTER_ROLE = keccak256(\"MINTER_ROLE\");\n bytes32 public constant BURNER_ROLE = keccak256(\"BURNER_ROLE\");\n\n constructor(address minter, address burner) ERC20(\"MyToken\", \"TKN\") {\n _grantRole(MINTER_ROLE, minter);\n _grantRole(BURNER_ROLE, burner);\n }\n\n function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {\n _mint(to, amount);\n }\n\n function burn(address from, uint256 amount) public onlyRole(BURNER_ROLE) {\n _burn(from, amount);\n }\n}\nSo clean! By splitting concerns this way, more granular levels of permission may be implemented than were possible with the simpler ownership approach to access control. Limiting what each component of a system is able to do is known as the principle of least privilege, and is a good security practice. Note that each account may still have more than one role, if so desired.\nGranting and Revoking Roles\nThe ERC-20 token example above uses _grantRole, an internal function that is useful when programmatically assigning roles (such as during construction). But what if we later want to grant the 'minter' role to additional accounts?\nBy default, accounts with a role cannot grant it or revoke it from other accounts: all having a role does is making the hasRole check pass. To grant and revoke roles dynamically, you will need help from the role’s admin.\nEvery role has an associated admin role, which grants permission to call the grantRole and revokeRole functions. A role can be granted or revoked by using these if the calling account has the corresponding admin role. Multiple roles may have the same admin role to make management easier. A role’s admin can even be the same role itself, which would cause accounts with that role to be able to also grant and revoke it.\nThis mechanism can be used to create complex permissioning structures resembling organizational charts, but it also provides an easy way to manage simpler applications. AccessControl includes a special role, called DEFAULT_ADMIN_ROLE, which acts as the default admin role for all roles. An account with this role will be able to manage any other role, unless _setRoleAdmin is used to select a new admin role.\nSince it is the admin for all roles by default, and in fact it is also its own admin, this role carries significant risk. To mitigate this risk we provide AccessControlDefaultAdminRules, a recommended extension of AccessControl that adds a number of enforced security measures for this role: the admin is restricted to a single account, with a 2-step transfer procedure with a delay between steps.\nLet’s take a look at the ERC-20 token example, this time taking advantage of the default admin role:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {AccessControl} from \"@openzeppelin/contracts/access/AccessControl.sol\";\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract AccessControlERC20MintMissing is ERC20, AccessControl {\n bytes32 public constant MINTER_ROLE = keccak256(\"MINTER_ROLE\");\n bytes32 public constant BURNER_ROLE = keccak256(\"BURNER_ROLE\");\n\n constructor() ERC20(\"MyToken\", \"TKN\") {\n // Grant the contract deployer the default admin role: it will be able\n // to grant and revoke any roles\n _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);\n }\n\n function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {\n _mint(to, amount);\n }\n\n function burn(address from, uint256 amount) public onlyRole(BURNER_ROLE) {\n _burn(from, amount);\n }\n}\nNote that, unlike the previous examples, no accounts are granted the 'minter' or 'burner' roles. However, because those roles' admin role is the default admin role, and that role was granted to msg.sender, that same account can call grantRole to give minting or burning permission, and revokeRole to remove it.\nDynamic role allocation is often a desirable property, for example in systems where trust in a participant may vary over time. It can also be used to support use cases such as KYC, where the list of role-bearers may not be known up-front, or may be prohibitively expensive to include in a single transaction.\nQuerying Privileged Accounts\nBecause accounts might grant and revoke roles dynamically, it is not always possible to determine which accounts hold a particular role. This is important as it allows proving certain properties about a system, such as that an administrative account is a multisig or a DAO, or that a certain role has been removed from all users, effectively disabling any associated functionality.\nThe base AccessControl contract provides role-based access control, but it does not support on-chain enumeration of role members. To track which accounts hold a role, you should instead rely on the RoleGranted and RoleRevoked events, which can be processed off-chain. If on-chain enumeration is required, use the AccessControlEnumerable extension.\nThis contract uses EnumerableSet internally and provides the following functions:\n\ngetRoleMemberCount\ngetRoleMember\ngetRoleMembers\n\nThese can be used to iterate over the accounts that have been granted a role:\nconst minterCount = await myToken.getRoleMemberCount(MINTER_ROLE);\n\nconst members = [];\nfor (let i = 0; i < minterCount; ++i) {\n members.push(await myToken.getRoleMember(MINTER_ROLE, i));\n}\nDelayed operation\nAccess control is essential to prevent unauthorized access to critical functions. These functions may be used to mint tokens, freeze transfers or perform an upgrade that completely changes the smart contract logic. While Ownable and AccessControl can prevent unauthorized access, they do not address the issue of a misbehaving administrator attacking their own system to the prejudice of their users.\nThis is the issue the TimelockController is addressing.\nThe TimelockController is a proxy that is governed by proposers and executors. When set as the owner/admin/controller of a smart contract, it ensures that whichever maintenance operation is ordered by the proposers is subject to a delay. This delay protects the users of the smart contract by giving them time to review the maintenance operation and exit the system if they consider it is in their best interest to do so.\nUsing TimelockController\nBy default, the address that deployed the TimelockController gets administration privileges over the timelock. This role grants the right to assign proposers, executors, and other administrators.\nThe first step in configuring the TimelockController is to assign at least one proposer and one executor. These can be assigned during construction or later by anyone with the administrator role. These roles are not exclusive, meaning an account can have both roles.\nRoles are managed using the AccessControl interface and the bytes32 values for each role are accessible through the DEFAULT_ADMIN_ROLE, PROPOSER_ROLE, EXECUTOR_ROLE, and CANCELLER_ROLE constants.\nThere is an additional feature built on top of AccessControl: giving the executor role to address(0) opens access to anyone to execute a proposal once the timelock has expired. This feature, while useful, should be used with caution.\nAt this point, with both a proposer and an executor assigned, the timelock can perform operations.\nAn optional next step is for the deployer to renounce its administrative privileges and leave the timelock self-administered. If the deployer decides to do so, all further maintenance, including assigning new proposers/schedulers or changing the timelock duration will have to follow the timelock workflow. This links the governance of the timelock to the governance of contracts attached to the timelock, and enforces a delay on timelock maintenance operations.\nIf the deployer renounces administrative rights in favour of timelock itself, assigning new proposers or executors will require a timelocked operation. This means that if the accounts in charge of any of these two roles become unavailable, then the entire contract (and any contract it controls) becomes locked indefinitely.\nWith both the proposer and executor roles assigned and the timelock in charge of its own administration, you can now transfer the ownership/control of any contract to the timelock.\nA recommended configuration is to grant both roles to a secure governance contract such as a DAO or a multisig, and to additionally grant the executor role to a few EOAs held by people in charge of helping with the maintenance operations. These wallets cannot take over control of the timelock but they can help smoothen the workflow.\nMinimum delay\nOperations executed by the TimelockController are not subject to a fixed delay but rather a minimum delay. Some major updates might call for a longer delay. For example, if a delay of just a few days might be sufficient for users to audit a minting operation, it makes sense to use a delay of a few weeks, or even a few months, when scheduling a smart contract upgrade.\nThe minimum delay (accessible through the getMinDelay method) can be updated by calling the updateDelay function. Bear in mind that access to this function is only accessible by the timelock itself, meaning this maintenance operation has to go through the timelock itself.\nAccess Management\nFor a system of contracts, better integrated role management can be achieved with an AccessManager instance. Instead of managing each contract’s permission separately, AccessManager stores all the permissions in a single contract, making your protocol easier to audit and maintain.\nAlthough AccessControl offers a more dynamic solution for adding permissions to your contracts than Ownable, decentralized protocols tend to become more complex after integrating new contract instances and requires you to keep track of permissions separately in each contract. This increases the complexity of permissions management and monitoring across the system.\n\nProtocols managing permissions in production systems often require more integrated alternatives to fragmented permissions through multiple AccessControl instances.\n\nThe AccessManager is designed around the concept of role and target functions:\n\nRoles are granted to accounts (addresses) following a many-to-many approach for flexibility. This means that each user can have one or multiple roles and multiple users can have the same role.\nAccess to a restricted target function is limited to one role. A target function is defined by one function selector on one contract (called target).\n\nFor a call to be authorized, the caller must bear the role that is assigned to the current target function (contract address + function selector).\n\nUsing AccessManager\nOpenZeppelin Contracts provides AccessManager for managing roles across any number of contracts. The AccessManager itself is a contract that can be deployed and used out of the box. It sets an initial admin in the constructor who will be allowed to perform management operations.\nIn order to restrict access to some functions of your contract, you should inherit from the AccessManaged contract provided along with the manager. This provides the restricted modifier that can be used to protect any externally facing function. Note that you will have to specify the address of the AccessManager instance (initialAuthority) in the constructor so the restricted modifier knows which manager to use for checking permissions.\nHere’s a simple example of an ERC-20 token that defines a mint function that is restricted by an AccessManager:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {AccessManaged} from \"@openzeppelin/contracts/access/manager/AccessManaged.sol\";\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract AccessManagedERC20Mint is ERC20, AccessManaged {\n constructor(address manager) ERC20(\"MyToken\", \"TKN\") AccessManaged(manager) {}\n\n // Minting is restricted according to the manager rules for this function.\n // The function is identified by its selector: 0x40c10f19.\n // Calculated with bytes4(keccak256('mint(address,uint256)'))\n function mint(address to, uint256 amount) public restricted {\n _mint(to, amount);\n }\n}\nMake sure you fully understand how AccessManager works before using it or copy-pasting the examples from this guide.\nOnce the managed contract has been deployed, it is now under the manager’s control. The initial admin can then assign the minter role to an address and also allow the role to call the mint function. For example, this is demonstrated in the following Javascript code using Ethers.js:\nconst MINTER = 42n; // Roles are uint64 (0 is reserved for the ADMIN_ROLE)\n\nawait manager.grantRole(MINTER, user, 0);\n\nawait manager.setTargetFunctionRole(\n target,\n ['0x40c10f19'], // bytes4(keccak256('mint(address,uint256)'))\n MINTER\n);\nEven though each role has its own list of function permissions, each role member (address) has an execution delay that will dictate how long the account should wait to execute a function that requires its role. Delayed operations must have the schedule function called on them first in the AccessManager before they can be executed, either by calling the target function or using the AccessManager’s execute function.\nAdditionally, roles can have a granting delay that prevents adding members immediately. The AccessManager admins can set this grant delay as follows:\nconst HOUR = 60 * 60;\n\nconst GRANT_DELAY = 24 * HOUR;\nconst EXECUTION_DELAY = 5 * HOUR;\nconst ACCOUNT = \"0x...\";\n\nawait manager.connect(initialAdmin).setGrantDelay(MINTER, GRANT_DELAY);\n\nawait manager.connect(initialAdmin).grantRole(MINTER, ACCOUNT, EXECUTION_DELAY);\nNote that roles do not define a name. As opposed to the AccessControl case, roles are identified as numeric values instead of being hardcoded in the contract as bytes32 values. It is still possible to allow for tooling discovery (e.g. for role exploration) using role labeling with the labelRole function.\nawait manager.labelRole(MINTER, \"MINTER\");\nGiven the admins of the AccessManaged can modify all of its permissions, it’s recommended to keep only a single admin address secured under a multisig or governance layer. To achieve this, it is possible for the initial admin to set up all the required permissions, targets, and functions, assign a new admin, and finally renounce its admin role.\nFor improved incident response coordination, the manager includes a mode where administrators can completely close a target contract. When closed, all calls to restricted target functions in a target contract will revert.\nClosing and opening contracts don’t alter any of their settings, neither permissions nor delays. Particularly, the roles required for calling specific target functions are not modified.\nThis mode is useful for incident response operations that require temporarily shutting down a contract in order to evaluate emergencies and reconfigure permissions.\nconst target = await myToken.getAddress();\n\nawait manager.setTargetClosed(target, true);\n\nawait manager.setTargetClosed(target, false);\nEven if an AccessManager defines permissions for a target function, these won’t be applied if the managed contract instance is not using the restricted modifier for that function, or if its manager is a different one.\nRole Admins and Guardians\nAn important aspect of the AccessControl contract is that roles aren’t granted nor revoked by role members. Instead, it relies on the concept of a role admin for granting and revoking.\nIn the case of the AccessManager, the same rule applies and only the role’s admins are able to call grant and revoke functions. Note that calling these functions will be subject to the execution delay that the executing role admin has.\nAdditionally, the AccessManager stores a guardian as an extra protection for each role. This guardian has the ability to cancel operations that have been scheduled by any role member with an execution delay. Consider that a role will have its initial admin and guardian default to the ADMIN_ROLE (0).\nBe careful with the members of ADMIN_ROLE, since it acts as the default admin and guardian for every role. A misbehaved guardian can cancel operations at will, affecting the AccessManager’s operation.\nManager configuration\nThe AccessManager provides a built-in interface for configuring permission settings that can be accessed by its ADMIN_ROLE members.\nThis configuration interface includes the following functions:\n\nAdd a label to a role using the labelRole function.\nAssign the admin and guardian of a role with setRoleAdmin and setRoleGuardian.\nSet each role’s grant delay via setGrantDelay.\n\nAs an admin, some actions will require a delay. Similar to each member’s execution delay, some admin operations require waiting for execution and should follow the schedule and execute workflow.\nMore specifically, these delayed functions are those for configuring the settings of a specific target contract. The delay applied to these functions can be adjusted by the manager admins with setTargetAdminDelay.\nThe delayed admin actions are:\n\nUpdating an AccessManaged contract authority using updateAuthority.\nClosing or opening a target via setTargetClosed.\nChanging permissions of whether a role can call a target function with setTargetFunctionRole.\n\nManager Enumerability\nSimilar to AccessControl, accounts might be granted and revoked roles dynamically in an AccessManager, making it challenging to determine which accounts hold a particular role at any given time. This capability is essential for proving certain properties about a system, such as verifying that an administrative role is held by a multisig or DAO, or that a certain role has been completely removed to disable associated functionality.\nThe base AccessManager contract provides comprehensive role-based access control but does not support on-chain enumeration of role members or target function permissions by default. To track which accounts hold roles and which functions are assigned to roles, you should rely on the RoleGranted, RoleRevoked, and TargetFunctionRoleUpdated events, which can be processed off-chain.\nIf on-chain enumeration is required, it can be added implemented on top of the existing logic:\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.24;\n\nimport {AccessManager} from \"@openzeppelin/contracts/access/manager/AccessManager.sol\";\nimport {EnumerableSet} from \"@openzeppelin/contracts/utils/structs/EnumerableSet.sol\";\n\n/**\n * @dev Extension of {AccessManager} that allows enumerating the members of each role\n * and the target functions each role is allowed to call.\n *\n * NOTE: Given {ADMIN_ROLE} is the default role for every restricted function, the\n * {getRoleTargetFunctions} and {getRoleTargetFunctionCount} functions will return an empty array\n * and 0 respectively.\n */\nabstract contract AccessManagerEnumerable is AccessManager {\n using EnumerableSet for EnumerableSet.AddressSet;\n using EnumerableSet for EnumerableSet.Bytes4Set;\n\n mapping(uint64 roleId => EnumerableSet.AddressSet) private _roleMembers;\n mapping(uint64 roleId => mapping(address target => EnumerableSet.Bytes4Set)) private _roleTargetFunctions;\n\n /**\n * @dev Returns the number of accounts that have `roleId`. Can be used\n * together with {getRoleMember} to enumerate all bearers of a role.\n */\n function getRoleMemberCount(uint64 roleId) public view virtual returns (uint256) {\n return _roleMembers[roleId].length();\n }\n\n /**\n * @dev Returns one of the accounts that have `roleId`. `index` must be a\n * value between 0 and {getRoleMemberCount}, non-inclusive.\n *\n * Role bearers are not sorted in any particular way, and their ordering may change at any point.\n *\n * WARNING: When using {getRoleMember} and {getRoleMemberCount}, make sure\n * you perform all queries on the same block. See the following\n * https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post]\n * for more information.\n */\n function getRoleMember(uint64 roleId, uint256 index) public view virtual returns (address) {\n return _roleMembers[roleId].at(index);\n }\n\n /**\n * @dev Returns a range of accounts that have `roleId`. `start` and `end` define the range bounds.\n * `start` is inclusive and `end` is exclusive.\n *\n * Role bearers are not sorted in any particular way, and their ordering may change at any point.\n *\n * It is not necessary to call {getRoleMemberCount} before calling this function. Using `start = 0` and\n * `end = type(uint256).max` will return every member of `roleId`.\n *\n * WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed\n * to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that\n * this function has an unbounded cost, and using it as part of a state-changing function may render the function\n * uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block.\n */\n function getRoleMembers(uint64 roleId, uint256 start, uint256 end) public view virtual returns (address[] memory) {\n return _roleMembers[roleId].values(start, end);\n }\n\n /**\n * @dev Returns the number of target function selectors that require `roleId` for the given `target`.\n * Can be used together with {getRoleTargetFunction} to enumerate all target functions for a role on a specific target.\n *\n * NOTE: Given {ADMIN_ROLE} is the default role for every restricted function, passing {ADMIN_ROLE} as `roleId` will\n * return 0. See {_updateRoleTargetFunction} for more details.\n */\n function getRoleTargetFunctionCount(uint64 roleId, address target) public view virtual returns (uint256) {\n return _roleTargetFunctions[roleId][target].length();\n }\n\n /**\n * @dev Returns one of the target function selectors that require `roleId` for the given `target`.\n * `index` must be a value between 0 and {getRoleTargetFunctionCount}, non-inclusive.\n *\n * Target function selectors are not sorted in any particular way, and their ordering may change at any point.\n *\n * WARNING: When using {getRoleTargetFunction} and {getRoleTargetFunctionCount}, make sure\n * you perform all queries on the same block. See the following\n * https://forum.openzeppelin.com/t/iterating-over-elements-on-enumerableset-in-openzeppelin-contracts/2296[forum post]\n * for more information.\n */\n function getRoleTargetFunction(uint64 roleId, address target, uint256 index) public view virtual returns (bytes4) {\n return _roleTargetFunctions[roleId][target].at(index);\n }\n\n /**\n * @dev Returns a range of target function selectors that require `roleId` for the given `target`.\n * `start` and `end` define the range bounds. `start` is inclusive and `end` is exclusive.\n *\n * Target function selectors are not sorted in any particular way, and their ordering may change at any point.\n *\n * It is not necessary to call {getRoleTargetFunctionCount} before calling this function. Using `start = 0` and\n * `end = type(uint256).max` will return every function selector that `roleId` is allowed to call on `target`.\n *\n * WARNING: This operation will copy the entire storage to memory, which can be quite expensive. This is designed\n * to mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that\n * this function has an unbounded cost, and using it as part of a state-changing function may render the function\n * uncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block.\n *\n * NOTE: Given {ADMIN_ROLE} is the default role for every restricted function, passing {ADMIN_ROLE} as `roleId` will\n * return an empty array. See {_updateRoleTargetFunction} for more details.\n */\n function getRoleTargetFunctions(\n uint64 roleId,\n address target,\n uint256 start,\n uint256 end\n ) public view virtual returns (bytes4[] memory) {\n return _roleTargetFunctions[roleId][target].values(start, end);\n }\n\n /// @dev See {AccessManager-_grantRole}. Adds the account to the role members set.\n function _grantRole(\n uint64 roleId,\n address account,\n uint32 grantDelay,\n uint32 executionDelay\n ) internal virtual override returns (bool) {\n bool granted = super._grantRole(roleId, account, grantDelay, executionDelay);\n if (granted) {\n _roleMembers[roleId].add(account);\n }\n return granted;\n }\n\n /// @dev See {AccessManager-_revokeRole}. Removes the account from the role members set.\n function _revokeRole(uint64 roleId, address account) internal virtual override returns (bool) {\n bool revoked = super._revokeRole(roleId, account);\n if (revoked) {\n _roleMembers[roleId].remove(account);\n }\n return revoked;\n }\n\n /**\n * @dev See {AccessManager-_setTargetFunctionRole}. Adds the selector to the role target functions set.\n *\n * NOTE: This function does not track function selectors for the {ADMIN_ROLE}, since exhaustively tracking\n * all restricted/admin functions is impractical (by default, all restricted functions are assigned to {ADMIN_ROLE}).\n * Therefore, roles assigned as {ADMIN_ROLE} will not have their selectors included in this extension's tracking.\n */\n function _setTargetFunctionRole(address target, bytes4 selector, uint64 roleId) internal virtual override {\n // cache old role ID\n uint64 oldRoleId = getTargetFunctionRole(target, selector);\n\n // call super\n super._setTargetFunctionRole(target, selector, roleId);\n\n // update enumerable sets\n if (oldRoleId != ADMIN_ROLE) {\n _roleTargetFunctions[oldRoleId][target].remove(selector);\n }\n if (roleId != ADMIN_ROLE) {\n _roleTargetFunctions[roleId][target].add(selector);\n }\n }\n}\nThe enumerable example only enumerates members of a role and functions that each role can call. Yet, it’s possible to enumerate roles active (i.e. roles granted to at least 1 member), guardians and admins.\nThis adds function that can be queried to iterate over the accounts that have been granted a role and the functions that a role is allowed to call on specific targets:\nconst minterCount = await accessManager.getRoleMemberCount(MINTER_ROLE);\n\nconst members = [];\nfor (let i = 0; i < minterCount; ++i) {\n members.push(await accessManager.getRoleMember(MINTER_ROLE, i));\n}\n\nconst allMembers = await accessManager.getRoleMembers(MINTER_ROLE, 0, ethers.MaxUint256);\n\nconst target = await myToken.getAddress();\nconst functionCount = await accessManager.getRoleTargetFunctionCount(MINTER_ROLE, target);\n\nconst functions = [];\nfor (let i = 0; i < functionCount; ++i) {\n functions.push(await accessManager.getRoleTargetFunction(MINTER_ROLE, target, i));\n}\n\nconst allFunctions = await accessManager.getRoleTargetFunctions(MINTER_ROLE, target, 0, ethers.MaxUint256);\nUsing with Ownable\nContracts already inheriting from Ownable can migrate to AccessManager by transferring ownership to the manager. After that, all calls to functions with the onlyOwner modifier should be called through the manager’s execute function, even if the caller doesn’t require a delay.\nawait ownable.connect(owner).transferOwnership(accessManager);\nUsing with AccessControl\nFor systems already using AccessControl, the DEFAULT_ADMIN_ROLE can be granted to the AccessManager after revoking every other role. Subsequent calls should be made through the manager’s execute method, similar to the Ownable case.\nawait accessControl.connect(admin).revokeRole(MINTER_ROLE, account);\n\nawait accessControl.connect(admin).grantRole(DEFAULT_ADMIN_ROLE, accessManager);\n\nawait accessControl.connect(admin).renounceRole(DEFAULT_ADMIN_ROLE, admin);\nAfter migrating to AccessManager, the msg.sender in restricted functions will be the AccessManager contract itself through the execute function, not the original caller. This is a fundamental change in how access control works and may require updates to your contract logic or frontend integration.Backwards CompatibilityPrevious PageOverviewNext PageOn this pageOwnership and OwnableRole-Based Access ControlUsing AccessControlGranting and Revoking RolesQuerying Privileged AccountsDelayed operationUsing TimelockControllerMinimum delayAccess ManagementUsing AccessManagerRole Admins and GuardiansManager configurationManager EnumerabilityUsing with OwnableUsing with AccessControl","tokens":8369,"squid":"ink-security_audits","role":"Sentinel","at":1791266483343,"hash":"b3a1b9c677c94258818fcaa4b2d5072242d093ef"}
{"url":"https://docs.optimism.io/node-operators/kona-node/configuration","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This document lists all CLI flags for the kona-node node subcommand, grouped by category. All flags can be provided as command-line arguments or via environment variables.\nFor more details on each flag, see the inline help (kona-node node --help) or the source code.\n​Default Ports\nServiceDefault PortFlag/EnvRPC HTTP9545--port / KONA_NODE_RPC_PORTRPC WebSocket9545(same as HTTP, enabled with --rpc.ws-enabled)P2P TCP9222--p2p.listen.tcp / KONA_NODE_P2P_LISTEN_TCP_PORTP2P UDP9223--p2p.listen.udp / KONA_NODE_P2P_LISTEN_UDP_PORT\nkona-node does not run a supervisor RPC server: the binary has no --supervisor.*\nflag group. Its only interop flag, --interop.dependency-set\n(KONA_NODE_INTEROP_DEPENDENCY_SET), takes a path to a dependency-set JSON file\nrather than a port.\n--conductor.rpc (KONA_NODE_CONDUCTOR_RPC) is not a listening port either. It is\nthe RPC endpoint URL of an external conductor service that the node dials out to,\nand it has no default value. Supplying it enables the conductor integration when the\nnode runs in sequencer mode (--mode sequencer); in validator mode it has no effect.\n​Core Node Arguments\nFlagEnvDescriptionRequiredDefault--mode <validator/sequencer>KONA_NODE_MODEMode of operation for the nodeNovalidator--l1-eth-rpc <URL>KONA_NODE_L1_ETH_RPCURL of the L1 execution client RPC APIYes---l1-trust-rpc <true/false>KONA_NODE_L1_TRUST_RPCWhether to trust the L1 RPC without verificationNotrue--l1-beacon <URL>KONA_NODE_L1_BEACONURL of the L1 beacon APIYes---l2-engine-rpc <URL>KONA_NODE_L2_ENGINE_RPCURL of the engine API endpoint of an L2 execution clientYes---l2-trust-rpc <true/false>KONA_NODE_L2_TRUST_RPCWhether to trust the L2 RPC without verificationNotrue--l2-engine-jwt-secret <PATH>KONA_NODE_L2_ENGINE_AUTHPath to file containing the hex-encoded JWT secret for the execution clientNo---l2-config-file <PATH>KONA_NODE_ROLLUP_CONFIGPath to a custom L2 rollup configuration fileNo---l1-runtime-config-reload-interval <SECONDS>KONA_NODE_L1_RUNTIME_CONFIG_RELOAD_INTERVALPoll interval for reloading runtime configNo600\n​Global Arguments\nFlagEnvDescriptionRequiredDefault--l2-chain-id <ID/NAME> or -c <ID/NAME>KONA_NODE_L2_CHAIN_IDL2 chain ID (numeric) or chain name (string)No10 (Optimism)\n​Chain ID Support\nThe --l2-chain-id flag supports flexible chain identification using the alloy_chains crate:\nNumeric Chain IDs:\nkona-node --l2-chain-id 10 node [args...] # Optimism mainnet\nkona-node --l2-chain-id 8453 node [args...] # Base mainnet\nkona-node --l2-chain-id 1 node [args...] # Ethereum mainnet\n\nString Chain Names:\nkona-node --l2-chain-id optimism node [args...]\nkona-node --l2-chain-id base node [args...]\nkona-node --l2-chain-id mainnet node [args...]\n\nShort Flag and Environment Variable:\nkona-node -c optimism node [args...]\nexport KONA_NODE_L2_CHAIN_ID=optimism && kona-node node [args...]\n\nSupported chain names include all those recognized by alloy_chains (e.g., optimism, base, mainnet). Unknown numeric chain IDs are accepted for custom networks.\n​P2P Arguments\nFlagEnvDescriptionDefault--p2p.no-discoveryKONA_NODE_P2P_NO_DISCOVERYDisable Discv5 (node discovery)false--p2p.priv.path <PATH>KONA_NODE_P2P_PRIV_PATHPath to hex-encoded 32-byte private key for peer ID---p2p.priv.raw <HEX>KONA_NODE_P2P_PRIV_RAWHex-encoded 32-byte private key for peer ID---p2p.advertise.ip <IP>KONA_NODE_P2P_ADVERTISE_IPIP to advertise to external peers---p2p.advertise.tcp <PORT>KONA_NODE_P2P_ADVERTISE_TCP_PORTTCP port to advertise0--p2p.advertise.udp <PORT>KONA_NODE_P2P_ADVERTISE_UDP_PORTUDP port to advertise0--p2p.listen.ip <IP>KONA_NODE_P2P_LISTEN_IPIP to bind LibP2P/Discv5 to0.0.0.0--p2p.listen.tcp <PORT>KONA_NODE_P2P_LISTEN_TCP_PORTTCP port to bind LibP2P to9222--p2p.listen.udp <PORT>KONA_NODE_P2P_LISTEN_UDP_PORTUDP port to bind Discv5 to9223--p2p.peers.lo <N>KONA_NODE_P2P_PEERS_LOLow-tide peer count20--p2p.peers.hi <N>KONA_NODE_P2P_PEERS_HIHigh-tide peer count30--p2p.peers.grace <SECONDS>KONA_NODE_P2P_PEERS_GRACEGrace period for new peers30--p2p.gossip.mesh.d <N>KONA_NODE_P2P_GOSSIP_MESH_DGossipSub mesh target count8--p2p.gossip.mesh.lo <N>KONA_NODE_P2P_GOSSIP_MESH_DLOGossipSub mesh low watermark6--p2p.gossip.mesh.dhi <N>KONA_NODE_P2P_GOSSIP_MESH_DHIGossipSub mesh high watermark12--p2p.gossip.mesh.dlazy <N>KONA_NODE_P2P_GOSSIP_MESH_DLAZYGossipSub gossip target6--p2p.gossip.mesh.floodpublishKONA_NODE_P2P_GOSSIP_FLOOD_PUBLISHPublish to all known peersfalse--p2p.scoring <none or light>KONA_NODE_P2P_SCORINGPeer scoring strategylight--p2p.ban.peersKONA_NODE_P2P_BAN_PEERSEnable peer banningfalse--p2p.ban.threshold <N>KONA_NODE_P2P_BAN_THRESHOLDBan threshold-100--p2p.ban.duration <MINUTES>KONA_NODE_P2P_BAN_DURATIONBan duration60--p2p.discovery.interval <SECONDS>KONA_NODE_P2P_DISCOVERY_INTERVALPeer discovery interval5--p2p.bootstore <PATH>KONA_NODE_P2P_BOOTSTOREDirectory to store the bootstore---p2p.redial <N>KONA_NODE_P2P_REDIALPeer redialing threshold500--p2p.redial.period <MINUTES>KONA_NODE_P2P_REDIAL_PERIODPeer dial period60--p2p.bootnodes <ENR,...>KONA_NODE_P2P_BOOTNODESList of bootnode ENRs---p2p.topic-scoringKONA_NODE_P2P_TOPIC_SCORINGEnable topic scoringfalse--p2p.discovery.randomize <SECONDS>KONA_NODE_P2P_DISCOVERY_RANDOMIZERemove random peers from discovery-\n​RPC Arguments\nFlagEnvDescriptionDefault--rpc.disabledKONA_NODE_RPC_DISABLEDDisable the RPC serverfalse--rpc.no-restartKONA_NODE_RPC_NO_RESTARTPrevent RPC server from restartingfalse--rpc.addr <IP>KONA_NODE_RPC_ADDRRPC listening address0.0.0.0--port <PORT>KONA_NODE_RPC_PORTRPC listening port9545--rpc.enable-adminKONA_NODE_RPC_ENABLE_ADMINEnable the admin APIfalse--rpc.admin-state <PATH>KONA_NODE_RPC_ADMIN_STATEFile path for admin state persistence---rpc.ws-enabledKONA_NODE_RPC_WS_ENABLEDEnable websocket RPC serverfalse\n​Sequencer Arguments\nFlagEnvDescriptionDefault--sequencer.stoppedKONA_NODE_SEQUENCER_STOPPEDStart sequencer in stopped statefalse--sequencer.max-safe-lag <N>KONA_NODE_SEQUENCER_MAX_SAFE_LAGMax L2 safe/unsafe lag0--sequencer.l1-confs <N>KONA_NODE_SEQUENCER_L1_CONFSL1 block confirmations for sequencer4--sequencer.recoverKONA_NODE_SEQUENCER_RECOVERStrictly prepare next L1 origin and create empty L2 blocksfalse--conductor.rpc <URL>KONA_NODE_CONDUCTOR_RPCRPC endpoint URL of an external conductor service. Supplying it enables the conductor integration in sequencer mode; it has no effect in validator mode.---conductor.rpc.timeout <SECONDS>KONA_NODE_CONDUCTOR_RPC_TIMEOUTConductor service RPC timeout1\n​Interop Arguments\nFlagEnvDescriptionDefault--interop.dependency-set <PATH>KONA_NODE_INTEROP_DEPENDENCY_SETPath to the JSON file describing the interop dependency set for this chain. Required when the rollup config schedules the Lagoon hardfork.-\nkona-node does not run a supervisor RPC server, so there is no --supervisor.*\nflag group. --interop.dependency-set is the node’s only interop flag.\n​RPC Trust Flags\nThe --l1-trust-rpc and --l2-trust-rpc flags control whether Kona verifies the block hashes of RPC responses. For guidance on when to disable trust and worked examples for trusted, untrusted, and mixed provider setups, see configure RPC trust.\n​Default Behavior\nUnless overridden by the flags above, a kona-node node run has the following defaults:\n\nThe P2P stack is spun up. The libp2p swarm listens on TCP 9222\nto receive block gossip. The discv5 discovery service runs on\nUDP port 9223. Peer scoring is enabled.\nAn RPC server is exposed at 0.0.0.0:9545. Websocket connections\nare disabled by default.\nPrometheus metrics are disabled. Enable them with the\n--metrics.enabled flag; metrics are then served on 0.0.0.0:9090,\nconfigurable via the --metrics.port and --metrics.addr flags.\n\n​Rollup Configuration Loading\nIf a file path to a rollup config is not specified via the\n--l2-config-file cli flag, the Rollup Config will be loaded\nvia the superchain registry.\nA custom rollup config can either be specified through the\n--l2-config-file flag, or specific values may be overridden\nusing a set of override flags provided by the kona-node.\nOverride flags (for example --canyon-override) can be viewed\nin the help menu by running kona-node node --help. The only\noverrides currently supported are hardfork timestamps in seconds.Was this page helpful?","tokens":2054,"squid":"ink-governance","role":"Council Listener","at":1791266485587,"hash":"bc84fbf60396a696e09462affd97bd07377e4cb9"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/account-abstraction","domain":"docs.openzeppelin.com","title":"Account Abstraction | OpenZeppelin Docs","text":"OpenZeppelin ContractsAccount AbstractionOpen in ClaudeUnlike Externally Owned Accounts (EOAs), smart contracts may contain arbitrary verification logic based on authentication mechanisms different from Ethereum’s native ECDSA and have execution advantages such as batching or gas sponsorship. To leverage these properties of smart contracts, the community has widely adopted ERC-4337, a standard to process user operations through an alternative mempool.\nThe library provides multiple contracts for Account Abstraction following this standard as it enables more flexible and user-friendly interactions with applications. Account Abstraction use cases include wallets in novel contexts (e.g. embedded wallets), more granular configuration of accounts, and recovery mechanisms.\nERC-4337 Overview\nThe ERC-4337 is a detailed specification of how to implement the necessary logic to handle operations without making changes to the protocol level (i.e. the rules of the blockchain itself). This specification defines the following components:\nUserOperation\nA UserOperation is a higher-layer pseudo-transaction object that represents the intent of the account. This shares some similarities with regular EVM transactions like the concept of gasFees or callData but includes fields that enable new capabilities.\nstruct PackedUserOperation {\n address sender;\n uint256 nonce;\n bytes initCode; // concatenation of factory address and factoryData (or empty)\n bytes callData;\n bytes32 accountGasLimits; // concatenation of verificationGasLimit (16 bytes) and callGasLimit (16 bytes)\n uint256 preVerificationGas;\n bytes32 gasFees; // concatenation of maxPriorityFeePerGas (16 bytes) and maxFeePerGas (16 bytes)\n bytes paymasterAndData; // concatenation of paymaster fields (or empty)\n bytes signature;\n}\nThis process of bundling user operations involves several costs that the bundler must cover, including base transaction fees, calldata serialization, entrypoint execution, and paymaster context costs. To compensate for these expenses, bundlers use the preVerificationGas and gasFees fields to charge users appropriately.\nEstimating preVerificationGas is not standardized as it varies based on factors like calldata size, signature complexity, and bundler-specific serialization costs.\nUse ERC4337Utils to manipulate the UserOperation struct and other ERC-4337 related values.\nEntrypoint\nEach UserOperation is executed through a contract known as the EntryPoint. This contract is a singleton deployed across multiple networks at the same address although other custom implementations may be used.\nThe Entrypoint contract is considered a trusted entity by the account.\nBundlers\nThe bundler is a piece of offchain infrastructure that is in charge of processing an alternative mempool of user operations. Bundlers themselves call the Entrypoint contract’s handleOps function with an array of UserOperations that are executed and included in a block.\nDuring the process, the bundler pays for the gas of executing the transaction and gets refunded during the execution phase of the Entrypoint contract.\nfunction handleOps(\n PackedUserOperation[] calldata ops,\n address payable beneficiary\n) external { ... }\nAccount Contract\nThe Account Contract is a smart contract that implements the logic required to validate a UserOperation in the context of ERC-4337. Any smart contract account should conform with the IAccount interface to validate operations.\ninterface IAccount {\n function validateUserOp(PackedUserOperation calldata, bytes32, uint256) external returns (uint256 validationData);\n}\nSimilarly, an Account should have a way to execute these operations by either handling arbitrary calldata on its fallback or implementing the IAccountExecute interface:\ninterface IAccountExecute {\n function executeUserOp(PackedUserOperation calldata userOp, bytes32 userOpHash) external;\n}\nThe IAccountExecute interface is optional. Developers might want to use ERC-7821 for a minimal batched execution interface or rely on ERC-7579 or any other execution logic.\nTo build your own account, see accounts.\nFactory Contract\nThe smart contract accounts are created by a Factory contract defined by the Account developer. This factory receives arbitrary bytes as initData and returns an address where the logic of the account is deployed.\nTo build your own factory, see account factories.\nPaymaster Contract\nA Paymaster is an optional entity that can sponsor gas fees for Accounts, or allow them to pay for those fees in ERC-20 instead of native currency. This abstracts gas away from the user experience in the same way that computational costs of cloud servers are abstracted away from end-users.\nTo build your own paymaster, see paymasters.\nFurther notes\nERC-7562 Validation Rules\nTo process a bundle of UserOperations, bundlers call validateUserOp on each operation sender to check whether the operation can be executed. However, the bundler has no guarantee that the state of the blockchain will remain the same after the validation phase. To overcome this problem, ERC-7562 proposes a set of limitations to EVM code so that bundlers (or node operators) are protected from unexpected state changes.\nThese rules outline the requirements for operations to be processed by the canonical mempool.\nAccounts can access their own storage during the validation phase, they might easily violate ERC-7562 storage access rules in indirect ways. For example, most accounts access their public keys from storage when validating a signature, limiting the ability of having accounts that validate operations for other accounts (e.g. via ERC-1271)\nAlthough any Account that breaks such rules may still be processed by a private bundler, developers should keep in mind the centralization tradeoffs of relying on private infrastructure instead of permissionless execution.Access ControlPrevious PageOverviewNext PageOn this pageERC-4337 OverviewUserOperationEntrypointBundlersAccount ContractFactory ContractPaymaster ContractFurther notesERC-7562 Validation Rules","tokens":1505,"squid":"ink-security_audits","role":"Sentinel","at":1791266493425,"hash":"28f02aff75db64db2d484f8354e4c73ef8394c40"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-protocol-v3-7-on-monad/24943/11","domain":"governance.aave.com","title":"[ARFC] Deploy Aave Protocol v3.7 on Monad - Governance - Aave","text":"Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n read \n\n 29\n min\n\n May 19\n\n 11 / 11\n\n Aug 26\n\n Jul 26\n\n post by TokenLogic on May 19\n\n 20 days later\n\n post by LlamaRisk on Jun 9\n\n post by LlamaRisk on Jun 11\n\n post by AaveLabs on Jun 16\n\n post by Abel189 on Jun 20\n\n post by LlamaRisk on Jun 26\n\n post by AaveLabs on Jun 27\n\n post by AaveLabs on Jul 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Aave Labs is pleased to share that a technical assessment review has been completed for every asset in the first listing roster for the launch of Aave V3.7 on Monad. The asset issuers have been responsive and active in collaborating on the due diligence throughout the review, and the results are now published in the Risk Assets Assessments category for governance review: Assets Assessments.\n- cbBTC\n- weETH\n- wstETH\n- WETH\n- mUSD\n- syrupUSDC\n- sUSDe\n- USDe\n- USDC\n- AUSD\n\n 14 days later\n\n post by pcx on Jul 16\n\n pcx\n\nAre there any monad rewards schedule on each assets?\n\n 10 days later\n\n post by adzgov2026 on Jul 26\n\n adzgov2026\n\n This proposal requires careful review by all delegates before voting. The structured transition plan addresses key concerns around capital efficiency and DAO treasury management. I encourage everyone to examine the co-authors detailed analysis and consider the long-term implications for our ecosystem.```\n\n 1 month later\n\n Closed on Aug 25\n\n This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 125\n\n Jul 1\n\n Staked USDe (sUSDe) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 97\n\n Jul 1\n\n [Risk Stewards] Monad Stablecoin IRM Adjustments: Slope1 to 5.00%\n\n Risk\n\n 0\n\n 134\n\n Sep 11\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 109\n\n Jul 1\n\n AL Technical Analysis Aave V3.6 <> Monad\n\n Risk\n\n 1\n\n 825\n\n Apr 9","tokens":509,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266495038,"hash":"a46b513a5f698eb64794648cea59c23b967b07cf"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/faq","domain":"docs.openzeppelin.com","title":"Frequently Asked Questions | OpenZeppelin Docs","text":"OpenZeppelin ContractsFrequently Asked QuestionsOpen in ClaudeCan I restrict a function to EOAs only?\nWhen calling external addresses from your contract it is unsafe to assume that an address is an externally-owned account (EOA) and not a contract. Attempting to prevent calls from contracts is highly discouraged. It breaks composability, breaks support for smart wallets like Gnosis Safe, and does not provide security since it can be circumvented by calling from a contract constructor.\nAlthough checking that the address has code, address.code.length > 0, may seem to differentiate contracts from EOAs, it can only say that an address is currently a contract, and its negation (that an address is not currently a contract) does not imply that the address is an EOA. Some counterexamples are:\n\naddress of a contract in construction\naddress where a contract will be created\naddress where a contract lived, but was destroyed\n\nFurthermore, an address will be considered a contract within the same transaction where it is scheduled for destruction by SELFDESTRUCT, which only has an effect at the end of the entire transaction.Subgraph ExamplesPrevious PageChangelogNext PageOn this pageCan I restrict a function to EOAs only?","tokens":306,"squid":"ink-security_audits","role":"Sentinel","at":1791266503709,"hash":"689a6ce7f4f892c204dcf830e109b143530cc048"}
{"url":"https://governance.aave.com/t/arfc-deploy-aave-protocol-v3-7-on-monad/24943","domain":"governance.aave.com","title":"[ARFC] Deploy Aave Protocol v3.7 on Monad - Governance - Aave","text":"[ARFC] Deploy Aave Protocol v3.7 on Monad \n\n Governance\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n read \n\n 29\n min\n\n Summary\n\n Motivation\n\n Incentives Package\n\n Post Growth Roadmap\n\n Specification\n\n General Configuration\n\n eMode #1 - Maple syrupUSDC\n\n eMode #2 - Liquid Leverage\n\n eMode #3 - Lido Yield Maximiser\n\n eMode #4 - EtherFi Yield Maximiser\n\n Aave DAO’s Contribution\n\n GHO Stablecoin\n\n Activate GHO Lane\n\n Deploy GHO Stewards\n\n Deploy stataUSDC remoteGSM\n\n 3. Mint and bridge 50,000,000 GHO\n\n 4. Fund GhoReserve from Collector\n\n Disclosure\n\n Next Steps\n\n Copyright\n\n May 19\n\n 1 / 11\n\n May 20\n\n Jul 26\n\n post by TokenLogic on May 19\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [ARFC] Deploy Aave Protocol v3.7 on Monad\nAuthor: @Tokenlogic\nCreated: 2026-05-19\nUpdated: 2026-06-17 with Risk Service Provider feedback\n\nimage1920×1080 143 KB\nSummary\nThis ARFC proposes deploying Aave Protocol v3.7 on the Monad Network.\nMotivation\nMonad’s pipelined EVM architecture delivers fast, high-throughput performance while remaining fully compatible with Ethereum, making it ideal for real-time financial applications. This directly supports the needs of neobanks and fintech platforms, which rely on quick transaction finality, scalability, and predictable costs.\nBy deploying Aave v3 on Monad, the ecosystem gains a proven liquidity layer that enables lending, borrowing, yield generation, and stablecoin infrastructure. Because of Monad’s full EVM compatibility, Aave can be integrated quickly with minimal changes, making it easier for existing Ethereum builders to adopt. Together, these positions Aave as the core liquidity engine within Monad, helping attract early users and capital while supporting the next generation of scalable, on-chain financial products.\nIncentives Package\nMonad Foundation will provide the following within the first twelve months of the Aave Protocol activation proposal being executed:\n\n$15M USD in incentives measured at the block when ACI distributes rewards via MASIv infrastructure\n10M units of GHO will be acquired and retained for more than 6-months whilst respecting considerations for managing operating capital\n\nThe Aave DAO will provide the following within the first twelve months of the Aave Protocol activation proposal being executed:\n\n0.50M units of GHO incentives to be distributed to support the growth and adoption of GHO on the Monad network\n\nThe Monad Foundation reserves the right to determine whether and when to migrate to Aave v4.\nPost Growth Roadmap\nAfter the initial launch of Aave Protocol v3.7, the next phase of growth is expected to evolve with the introduction of Pendle PT assets and Fastlane’s LST.\n\nPendle PT-AUSD\nPendle PT-sUSDe\nPendle PT-reUSD\nFastlane’s shMON\n\nSpecification\nThe below will be updated upon receiving feedback from various stakeholders in the lead-up to the deployment.\nGeneral Configuration\n\nParameters\nValue\nValue\nValue\nValue\nValue\nValue\nValue\nValue\nValue\nValue\nValue\nValue\n\nAsset\nUSDT0\nUSDC\nGHO\nUSDe\nmUSD\nAUSD\nwETH\ncbBTC\nwstETH\nweETH\nsyrupUSDC\nsUSDe\n\nIsolation mode\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\n\nBorrowable\nYes\nYes\nYes\nYes\nYes\nYes\nNo\nNo\nNo\nNo\nNo\nNo\n\nCollateral enabled\nYes\nYes\nYes\nNo\nNo\nNo\nYes\nYes\nNo\nNo\nNo\nNo\n\nSupply Cap\n100,000,000\n75,000,000\n20,000,000\n60,000,000\n100,000,000\n20,000,000\n40,000\n1,000\n35,000\n30,000\n40,000,000\n60,000,000\n\nBorrow Cap\n100,000,000\n50,000,000\n18,000,000\n50,000,000\n50,000,000\n18,000,000\n36,000\n-\n-\n-\n-\n-\n\nDebt Ceiling\n-\n-\n-\n-\n-\n-\n-\n-\n-\n-\n-\n-\n\nLTV\n75.00%\n75.00%\n75.00%\n-\n-\n-\n80.50%\n73.0%\n-\n-\n-\n-\n\nLT\n78.00%\n78.00%\n78.00%\n-\n-\n-\n84.00%\n78.00%\n-\n-\n-\n-\n\nLiquidation Bonus\n7.50%\n7.50%\n7.50%\n-\n-\n-\n5.50%\n7%\n-\n-\n-\n-\n\nLiquidation Protocol Fee\n5%\n5%\n5%\n-\n-\n-\n5.5%\n5.5%\n-\n-\n-\n-\n\nVariable Base\n0.0%\n0.0%\n0.0%\n0.0%\n0.0%\n0.0%\n0.00%\n-\n-\n-\n-\n\nVariable Slope1\n4.0%\n4.0%\n4.0%\n4.0%\n4.0%\n4.0%\n2.20%\n-\n-\n-\n-\n-\n\nVariable Slope2\n40.0%\n40.0%\n40.0%\n40.0%\n40.0%\n40.0%\n20.0%\n-\n-\n-\n-\n-\n\nUoptimal\n90.0%\n90.0%\n90.0%\n90.0%\n80.0%\n80.0%\n90.0%\n-\n-\n-\n-\n-\n\nReserve Factor\n10.0%\n10.0%\n10.0%\n25.0%\n10.0%\n10.0%\n15.0%\n7.0%\n5.0%\n45.0%\n10.0%\n10.0%\n\nStable Borrowing\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\nDisabled\n\nFlashloanable\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\nYes\n\nSiloed Borrowing\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\n\nBorrowed in Isolation\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\nNo\n\nE-Modes\n1, 2,\n1, 2\n1, 2\n1, 2\n1\n1, 2\n3, 4\n\n3\n4\n1\n2\n\neMode #1 - Maple syrupUSDC\n\nParameter\nValue\nValue\nValue\nValue\nValue\nValue\n\nAsset\nsyrupUSDC\nUSDT0\nUSDC\nGHO\nmUSD\nAUSD\n\nCollateral\nYes\nNo\nNo\nNo\nNo\nNo\n\nBorrowable\nNo\nYes\nYes\nYes\nYes\nYes\n\nMax LTV\n90.00%\n-\n-\n-\n-\n-\n\nLiquidation Threshold\n92.00%\n-\n-\n-\n-\n-\n\nLiquidation Bonus\n4.00%\n-\n-\n-\n-\n-\n\neMode #2 - Liquid Leverage\n\nParameter\nValue\nValue\nValue\nValue\nValue\nValue\n\nAsset\nsUSDe\nUSDe\nUSDT0\nUSDC\nGHO\nAUSD\n\nCollateral\nYes\nYes\nNo\nNo\nNo\nNo\n\nBorrowable\nNo\nNo\nYes\nYes\nYes\nYes\n\nMax LTV\n90.00%\n90.00%\n-\n-\n-\n-\n\nLiquidation Threshold\n92.00%\n92.00%\n-\n-\n-\n-\n\nLiquidation Bonus\n4.00%\n4.00%\n-\n-\n-\n-\n\neMode #3 - Lido Yield Maximiser\n\nParameter\nValue\nValue\n\nAsset\nwstETH\nwETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nMax LTV\n94.00%\n-\n\nLiquidation Threshold\n96.00%\n-\n\nLiquidation Bonus\n1.00%\n-\n\neMode #4 - EtherFi Yield Maximiser\n\nParameter\nValue\nValue\n\nAsset\nweETH\nwETH\n\nCollateral\nYes\nNo\n\nBorrowable\nNo\nYes\n\nMax LTV\n93.00%\n-\n\nLiquidation Threshold\n95.00%\n-\n\nLiquidation Bonus\n1.00%\n-\n\nAave DAO’s Contribution\nCreate an allowance for 0.5M aEthLidoGHO from Aave V3 Prime on Ethereum:\n\nAsset: aEthLidoGHO: 0x18eFE565A5373f430e2F809b97De30335B3ad96A\nAmount: 0.5M\nSpender: AFC 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa\nMethod: approve() aEthLidoGHO on the Aave Collector contract to the Aave Finance Committee (AFC) address.\n\nGHO Stablecoin\nActivate GHO Lane\nCurrently, the CCIP Bridge to Monad Network is v1.5 and requires upgrading to v1.6 before GHO lanes are established. TokenLogic will work with Chainlink to sync upgrade timelines and extend the new GHO lanes to/from the Monad Network\nCurrent CCIP Bridge Configuration, which may change prior to implementation. The Gho Lane Activation uses the parameters in effect when the AIP is submitted.\n\nBucket Capacity: 150M GHO\nInbound Capacity: 5M GHO\nOutbound Capacity: 5M GHO\nRefill Rate: 1,000 GHO/sec\n\nThe table below lists the address of the new Monad deployments\n\nContract\nAddress\n\nGhoToken\n0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73\n\nGhoTokenPool\n0xA5AE05b71c3F170E12E7620Fdf7679721aec1EC8\n\nGhoBucketSteward\n0xDe6539018B095353A40753Dc54C91C68c9487D4E\n\nGhoCcipSteward\n0x360d8aa8F6b09B7BC57aF34db2Eb84dD87bf4d12\n\nGhoAavecoreSteward\n0xA5Ba213867E175A182a5dd6A9193C6158738105A\n\nDeploy GHO Stewards\nGhoAaveSteward\n\nupdateGhoBorrowCap: ±100%\nupdateGhoBorrowRate: ±5% on optimal usage ratio, base variable rates, slopes\nupdateGhoSupplyCap: Up to +100%\n\nGhoGsmSteward\n\nupdateGsmExposureCap: ±100%\nupdateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy)\n\nBoth stewards remain callable only by the GHO steward protocol.\nGhoCcipSteward\n\nupdateBridgeLimit : ±100%\nupdateRateLimit: ±100%\n\nGhoBucketSteward\n\nupdateFacilitatorBucketCapacity : ±100%\n\nDeploy stataUSDC remoteGSM\n\nParameter\nValue\n\nGHO Bucket Cap\n50M GHO\n\nstataUSDC Exposure Cap\n40M\n\nFreeze Lower Bound\n$0.990\n\nFreeze Upper Bound\n$1.010\n\nUnfreeze Lower Bound\n$0.995\n\nUnfreeze Upper Bound\n$1.005\n\nMint GHO Fee\n0%\n\nBurn GHO Fee\n0.10%\n\nGho Reserve Limit\n25M\n\nUSDC deposits into stataUSDC trigger GHO transfers using Ethereum-held inventory via GSM.\n3. Mint and bridge 50,000,000 GHO\nMint 50M GHO from the GhoDirectFacilitator and bridge to Monad via CCIP to Monad’s Collector.\n\nParameter\nValue\n\nFacilitator\n0x0cB7C2A2Ab38Aed3e6096631D7Dba3DaBf237134 \n\nGhoReserve\n0x307707A53Cb51670a8bcC8a2808A349C65E1Fb92 \n\nMint Amount\n50,000,000 GHO\n\nNew Facilitator Bucket Level\n200,000,000 GHO\n\n4. Fund GhoReserve from Collector\nFrom Collector, transfer to GhoReserve deployed on Monad for use by GSM.\n\nParameter\nValue\n\nSource Chain\nEthereum\n\nDestination Chain\nMonad (CCIP selector: )\n\nGHO CCIP Token Pool (Ethereum)\n0x06179f7C1be40863405f374E7f5F8806c728660A\n\nGHO CCIP Token Pool (Monad)\n0xA5AE05b71c3F170E12E7620Fdf7679721aec1EC8 \n\nFinal Destination (Monad Gho Reserve)\n0x307707A53Cb51670a8bcC8a2808A349C65E1Fb92 \n\nAmount\n50,000,000 GHO\n\nDisclosure\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nGather feedback from the community.\nIf consensus is reached on this TEMP CHECK, escalate this proposal to the Snapshot stage.\nPublish a standard ARFC, collect feedback from the community & service providers before escalating the proposal to the ARFC snapshot stage.\nIf the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Deploy Aave V4 on the Monad Network\n\n 3\n\n 3\n\n read \n\n 29\n min\n\n 20 days later\n\n post by LlamaRisk on Jun 9\n\n post by LlamaRisk on Jun 11\n\n post by AaveLabs on Jun 16\n\n post by Abel189 on Jun 20\n\n post by LlamaRisk on Jun 26\n\n post by AaveLabs on Jun 27\n\n post by AaveLabs on Jul 1\n\n 14 days later\n\n post by pcx on Jul 16\n\n 10 days later\n\n post by adzgov2026 on Jul 26\n\n 1 month later\n\n Closed on Aug 25\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 125\n\n Jul 1\n\n Staked USDe (sUSDe) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 97\n\n Jul 1\n\n [Risk Stewards] Monad Stablecoin IRM Adjustments: Slope1 to 5.00%\n\n Risk\n\n 0\n\n 134\n\n Sep 11\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 109\n\n Jul 1\n\n AL Technical Analysis Aave V3.6 <> Monad\n\n Risk\n\n 1\n\n 825\n\n Apr 9","tokens":2508,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266505436,"hash":"e3c1cdddb601725d85a272a6c7e84a2e50daeb8d"}
{"url":"https://governance.aave.com/t/wrapped-liquid-staked-ether-2-0-wsteth-on-aave-monad-assessments/25262/1","domain":"governance.aave.com","title":"Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments - Risk / Assessments - Aave","text":"Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments \n\n RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 1\n\n 1 / 2\n\n Jul 1\n\n Jul 1\n\n post by AaveLabs on Jul 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n This thread is the home for all risk and technical assessments of Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 5\n min\n\n post by AaveLabs on Jul 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n [Asset Technical Assessment] wstETH on Aave V3 Monad\nAuthor: Aave Labs\nDate: 2026-06-30\n\nSummary\nTechnical assessment of wstETH (Wrapped liquid staked Ether) for onboarding to Aave V3 Monad, following the Technical Asset Listing Framework.\nOverall result: MEDIUM \nwstETH on Monad is a clean, standard ERC20 (OpenZeppelin AccessControl, 18 decimals, no fee on transfer, no rebase, no ERC777 or ERC1363 hooks) whose only mint and burn authority is a single Chainlink Cross-Chain Interoperability Protocol (CCIP) burn-and-mint token pool, with no externally owned account able to mint. On Monad wstETH is a bridged representation: the Monad supply exists only because canonical wstETH is locked on Ethereum, so the bridge’s governance, rate limits, and escrow accounting carry the listing. A live wstETH/USD market feed and a live wstETH/stETH exchange-rate feed are present on Monad alongside ETH/USD, so the asset is priceable, and the conditions that hold this at Medium are the bridge attestation, governance delay, and rate-limiter items described below.\nListing Recommendation\nFrom a technical standpoint, wstETH on Aave V3 Monad is technically eligible for listing, with conditions. Several non-blocking items are recommended for the issuer to address and to revisit as exposure to the asset grows: the governing timelock on both the Monad token and the bridge pools enforces only a 3-hour delay, below the 24-hour standard expected for upgrade and configuration changes; and the entire governance root is a single Chainlink-operated signer mesh (MCMS) that owns the token admin, the proxy admin, and the bridge pool, with no separation between bridge, token, and upgrade authority. None of these is a blocker.\nAsset under review\n\nField\nValue\n\nAsset\nWrapped liquid staked Ether (wstETH)\n\nTarget chain\nMonad (chain ID 143)\n\nTarget market\nAave V3 Monad\n\nToken contract\n0x10Aeaf63194db8d453d4D85a06E5eFE1dd0b5417\n\nNative to target chain?\nNo. wstETH on Monad is a bridged representation; the Monad token is minted and burned by a Chainlink CCIP burn-and-mint token pool, while canonical wstETH is escrowed on Ethereum.\n\nAAcA classification\nGroup 3 (yield-bearing, value-accruing liquid staking wrapper)\n\nwstETH is the non-rebasing wrapper of Lido’s staked ETH (stETH): a holder’s balance stays fixed while each token slowly becomes worth more stETH as staking rewards accrue. On its home chain, Ethereum, wstETH is the canonical token. On Monad it is a bridged representation: Chainlink’s Cross-Chain Token (CCT) framework over CCIP locks canonical wstETH on Ethereum and mints an equal amount on Monad, and sending it back burns the Monad token and releases the Ethereum escrow. There is no local staking or redemption on Monad, so the value and the exit path both depend on the Ethereum side and the bridge.\n0. Pre-screening\nwstETH is deployed on Monad at 0x10Aeaf63…5417 as a thin proxy carrying genuine contract code, reporting name “Wrapped liquid staked Ether 2.0”, symbol “wstETH”, 18 decimals, and a total supply of roughly 25,117 wstETH. It is classified Group 3 (yield-bearing wrapper) and is not in any non-approved or sanctioned category, and only one Monad token matches wstETH in official sources, confirmed on-chain because its bridge pool’s remote token on Ethereum resolves to canonical Lido wstETH. wstETH is listed on multiple live Aave V3 deployments on other chains, useful as a parameter reference for the same asset rather than as proof of this listing’s safety. The proxy, its implementation, and the bridge pool are source-verified on MonadScan as the standard Chainlink Cross-Chain Token contracts, with exact-match badges on the implementation and the pool.\nRating: GOOD \n1. ERC20 Compliance\nThe wstETH token on Monad is a standard OpenZeppelin 5.x ERC20 with 18 decimals: transfer() and approve() are declared returning bool and revert on invalid input with the OpenZeppelin custom errors, with no fee on transfer, no rebasing, no ERC777 or ERC1363 hooks, and no flash mint. There are no transfer restrictions and no allowlist or blocklist on the token, so smart contracts can hold and transfer it without restriction. The Monad token holds no Lido accounting (the exchange-rate getters revert on Monad), consistent with a bridged representation rather than the canonical Ethereum wrapper. The token implements ERC165 and OpenZeppelin AccessControl interfaces and exposes no EIP-2612 permit.\nRating: GOOD \n2. Oracle\nA live Chainlink wstETH/USD market feed exists on Monad with a fresh timestamp at review, a 3,600-second heartbeat, and a 0.05% deviation threshold. A live Chainlink wstETH/stETH exchange-rate feed is also present, matching the canonical Ethereum rate and driven by deviation under a 24-hour heartbeat, alongside live ETH/USD and stETH/USD feeds. Both pricing strategies are therefore available on Monad: a direct wstETH/USD market feed, or a Correlated-Asset Price Oracle (CAPO) composition of ETH/USD combined with the wstETH/stETH exchange rate. The elements for the composition are present, and it is the design already used to price wstETH on other Aave instances, so it may suit this listing as well.\nRating: GOOD \n3. Access Control\nAccess control uses standard OpenZeppelin AccessControl, with the token’s default admin role, the bridge CCIP admin, the proxy admin owner, and the bridge pool owner all held by the same OpenZeppelin TimelockController, and no externally owned account anywhere in the control path. The sole holder of the mint and burn roles is the CCIP token pool, so no externally owned account can mint and there is no permissionless path to burn from an arbitrary wallet, and the token carries no pause and no blocklist (pause exists only at the bridge layer and cannot block an on-Monad liquidation). The token sits behind an OpenZeppelin Transparent proxy whose admin is owned by that timelock, and the timelock’s getMinDelay() returns 10,800 seconds (3 hours), below the 24-hour bar, with the timelock governed by a Chainlink-operated signer mesh (MCMS). Concentrating the token admin, proxy admin, bridge pool owner, and CCIP admin on that single signer mesh removes separation between bridge, token, and upgrade authority.\nRating: MEDIUM → no externally owned account anywhere, but the 3-hour delay is below the 24-hour bar and the token admin, proxy admin, and bridge authority collapse onto a single governance root with no separation of duties.\n4. Exchange Rate and Yield\nwstETH is yield-bearing, so this section applies. The Monad token holds no Lido accounting, so the rate that matters for pricing comes from the live Chainlink wstETH/stETH exchange-rate feed on Monad, which tracks the canonical Ethereum rate set by Lido and cannot be moved by a donation or a flash loan in a single Monad transaction; the rate is monotonically non-decreasing under normal Lido operation and falls only on a net-negative validator event such as slashing, which would pass through to the Monad value. There is no native redemption on Monad: the exit paths are selling into a Monad decentralized exchange or bridging back to Ethereum (burn on Monad, release the Ethereum escrow, then unwrap and exit through Lido’s withdrawal queue), which is slow and rate-limited. A CAPO adapter is buildable from the live Monad feeds.\nRating: MEDIUM → the rate is verifiably not manipulable in a single transaction and is monotonic under normal conditions, but there is no native redemption on Monad and the on-chain decentralized exchange backstop is thin, so the liquidation path depends on exchange depth or a slow, rate-limited bridge round trip.\n5. Token Architecture\nSupply on Monad rises only through verified inbound CCIP mints and falls only through outbound burns, both gated to the bridge pool, with no fixed cap at the token level and standard Transfer events emitted from and to the zero address for observability. There are no transfer restrictions on the token, and the privileged functions (mint, burn, role grants) all sit behind AccessControl. The token logic contains no tx.origin authorization and no application-level delegatecall beyond the Transparent proxy’s own delegation to its fixed implementation. There is a single token address, a single implementation, and a single bridge pool resolved by the CCIP registry, with no migration contract or duplicate path to the same supply.\nRating: GOOD \n6. Bridge and Cross-Chain Risk\nMonad wstETH is a bridged representation that exists only because canonical wstETH is escrowed on Ethereum, bridged via Chainlink CCIP using the Cross-Chain Token standard: the Ethereum side locks and releases the canonical token in escrow, while the Monad side burns and mints the representation, over a single live route to Ethereum only (the Ink and Plasma routes documented elsewhere are not wired into the Monad pool). At assessment the Ethereum escrow held roughly 41,161 wstETH against a Monad supply of roughly 25,117 wstETH, so the Monad representation is fully backed with headroom, though that escrow is shared with other destination chains rather than dedicated to Monad. Inbound and outbound rate limiters are configured on both ends as refilling token buckets that refill to full over about 24 hours, with the inbound capacity (roughly 2,200 wstETH) capping the size of a single forged or erroneous inbound message. The route is governed by the 3-hour timelock and the single Chainlink-operated governance root noted in Section 3.\nRating: MEDIUM → standard, current CCIP with rate limiters set on both ends and Monad supply fully covered by Ethereum escrow, held at Medium by the 3-hour timelock below the 24-hour bar, shared rather than dedicated escrow, and a single governance root over the pool, the token, and the upgrade path.\n7. Audit and Security History\nThe deployed contracts derive from publicly audited Chainlink Cross-Chain Token code: the token is the standard CCT burn-and-mint ERC20 (OpenZeppelin 5.x ERC20 with AccessControl) behind an OpenZeppelin Transparent proxy, and the bridge pools are the standard CCT token pools, with the token-pool layer covered by a public Cyfrin CodeHawks competitive audit in 2024 (scope confirmed to include the deployed pool types) plus Code4rena reviews. The deployed Monad proxy, implementation, and bridge pool are source-verified on MonadScan, with exact-match badges on the implementation and the pool, and the proxy has run its original implementation since deployment with no logic swap. No unresolved Critical or High findings for the CCT pools were identified in public records, and the canonical Ethereum wstETH and the underlying Lido protocol are long-audited and long-live. The residual item is pinning the verified source to the exact audited Chainlink CCT release commit (the contest published no commit hash), while the audit scope excluded the owner and governance contracts that secure this deployment.\nRating: MEDIUM → the token-pool stack and OpenZeppelin primitives are publicly audited and the deployed Monad contracts are source-verified, but the exact audited release commit is not pinned and the governance contracts sat outside the audit scope.\n8. Dependencies\nThe asset rests on three production, on-chain governed dependencies: Lido staking on Ethereum (the ultimate backing, where value, yield, and slashing originate, with the Ethereum withdrawal queue applying to any exit to ETH), Chainlink CCIP (supply integrity of the Monad representation), and the Chainlink price feeds on Monad (valuation). None is controlled by an externally owned account or unaudited in the critical path, and changes on both Lido and the bridge are observable on-chain. The tightest governance window among them is the bridge’s 3-hour timelock, and the redemption path to ETH is slow because it combines a bridge round trip with Lido’s withdrawal queue.\nRating: MEDIUM → all dependencies are audited and on-chain governed, but the bridge dependency carries a 3-hour governance delay below the 24-hour bar and the redemption path to ETH is slow.\n9. Summary\nFindings table\n\nArea\nKey finding\nRating\n\n0. Pre-screening\nDeployed at 0x10Aeaf63…5417, thin proxy, Group 3 yield-bearing wrapper; only one genuine wstETH token, confirmed against canonical Lido wstETH on Ethereum; proxy, implementation, and bridge pool source-verified on MonadScan (exact-match on impl and pool).\nGood\n\n1. ERC20\nStandard OpenZeppelin 5.x ERC20, 18 decimals; returns bool, no fee on transfer, no rebase, no ERC777 or ERC1363 hooks, no flash mint, no transfer restrictions.\nGood\n\n2. Oracle\nBoth strategies available: a direct wstETH/USD market feed, or a CAPO composition (ETH/USD plus the wstETH/stETH exchange rate); the composition is the design already used on other Aave instances. All feeds live on Monad; Aave oracle wiring is a prerequisite, not yet done.\nGood\n\n3. Access control\nOpenZeppelin AccessControl, no externally owned account; sole minter and burner is the CCIP pool; but 3-hour timelock below the 24-hour bar and token, proxy, and bridge authority on a single governance root.\nMedium\n\n4. Exchange rate / yield\nNon-rebasing wrapper; rate set on Ethereum by Lido, not manipulable in one Monad transaction; no native redemption on Monad, exit is a thin decentralized exchange or a slow, rate-limited bridge round trip.\nMedium\n\n5. Token architecture\nSingle token, single implementation, single bridge pool, no migration or duplicate supply path; supply only via gated mint and burn; no tx.origin, no application-level delegatecall.\nGood\n\n6. Bridge and cross-chain\nChainlink CCIP Cross-Chain Token, single route to Ethereum; Ethereum escrow (~41,161 wstETH) backs Monad supply (~25,117); rate limiters set both ends; 3-hour timelock; single governance root.\nMedium\n\n7. Audit and security\nCCT token-pool stack publicly audited (Cyfrin CodeHawks 2024 plus Code4rena); deployed Monad implementation and pool source-verified (exact-match); residual is pinning to the exact audited commit, ProxyAdmin unverified, governance contracts outside audit scope.\nMedium\n\n8. Dependencies\nLido staking (Ethereum), Chainlink CCIP, and Chainlink feeds, all production and on-chain governed; bridge governance delay is 3 hours and the exit to ETH is slow.\nMedium\n\nDisclaimer\nAave Labs has no formal or informal affiliation with Lido, Chainlink, or the wstETH issuer beyond this technical assessment. Aave Labs has not been compensated by Lido, Chainlink, or any related party in connection with this work.\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Deploy Aave Protocol v3.7 on Monad\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Wrapped Ether (WETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 90\n\n Jul 1\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 109\n\n Jul 1\n\n [ARFC] Deploy Aave Protocol v3.7 on Monad\n\n Governance\n\n 9\n\n 2.1k\n\n Jul 26\n\n MetaMask USD (mUSD) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 159\n\n Jul 1\n\n Wrapped Ether (WETH) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 170\n\n Sep 18","tokens":3985,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266515824,"hash":"160831b6b3875bb7fc84ae6d2d50311ef15ff648"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api/utils","domain":"docs.openzeppelin.com","title":"Utils | OpenZeppelin Docs","text":"OpenZeppelin ContractsAPI ReferenceUtilsSmart contract utils utilities and implementationsOpen in ClaudeMiscellaneous contracts and libraries containing utility functions you can use to improve security, work with new data types, or safely use low-level primitives.\n\nMath, SignedMath: Implementation of various arithmetic functions.\nSafeCast: Checked downcasting functions to avoid silent truncation.\nNonces: Utility for tracking and verifying address nonces that only increment.\nNoncesKeyed: Alternative to Nonces, that support keyed nonces following ERC-4337 specifications.\nPausable: A common emergency response mechanism that can pause functionality while a remediation is pending.\nReentrancyGuard: A modifier that can prevent reentrancy during certain functions.\nReentrancyGuardTransient: Variant of ReentrancyGuard that uses transient storage (EIP-1153).\nERC165, ERC165Checker: Utilities for inspecting interfaces supported by contracts.\nAccumulators: A library for merging an arbitrary dynamic number of bytes buffers.\nBitMaps: A simple library to manage boolean value mapped to a numerical index in an efficient way.\nCheckpoints: A data structure to store values mapped to a strictly increasing key. Can be used for storing and accessing values over time.\nCircularBuffer: A data structure to store the last N values pushed to it.\nDoubleEndedQueue: An implementation of a double ended queue whose values can be added or removed from both sides. Useful for FIFO and LIFO structures.\nEnumerableMap: A type like Solidity’s mapping, but with key-value enumeration: this will let you know how many entries a mapping has, and iterate over them (which is not possible with mapping).\nEnumerableSet: Like EnumerableMap, but for sets. Can be used to store privileged accounts, issued IDs, etc.\nHeap: A library that implements a binary heap in storage.\nMerkleTree: A library with Merkle Tree data structures and helper functions.\nAddress: Collection of functions for overloading Solidity’s address type.\nArrays: Collection of functions that operate on arrays.\nBase58: On-chain base58 encoding and decoding.\nBase64: On-chain base64 and base64URL encoding according to RFC-4648.\nBlockhash: A library for accessing historical block hashes beyond the standard 256 block limit utilizing EIP-2935’s historical blockhash functionality.\nBytes: Common operations on bytes objects.\nCAIP2, CAIP10: Libraries for formatting and parsing CAIP-2 and CAIP-10 identifiers.\nCalldata: Helpers for manipulating calldata.\nComparators: A library that contains comparator functions to use with the Heap library.\nContext: A utility for abstracting the sender and calldata in the current execution context.\nCreate2: Wrapper around the CREATE2 EVM opcode for safe use without having to deal with low-level assembly.\nInteroperableAddress: Library for formatting and parsing ERC-7930 interoperable addresses.\nLowLevelCall: Collection of functions to perform calls with low-level assembly.\nMemory: A utility library to manipulate memory.\nMulticall: Abstract contract with a utility to allow batching together multiple calls in a single transaction. Useful for allowing EOAs to perform multiple operations at once.\nPacking: A library for packing and unpacking multiple values into bytes32.\nPanic: A library to revert with Solidity panic codes.\nRelayedCall: A library for performing calls that use minimal and predictable relayers to hide the sender.\nRLP: Library for encoding and decoding data in Ethereum’s Recursive Length Prefix format.\nShortStrings: Library to encode (and decode) short strings into (or from) a single bytes32 slot for optimizing costs. Short strings are limited to 31 characters.\nSlotDerivation: Methods for deriving storage slot from ERC-7201 namespaces as well as from constructions such as mapping and arrays.\nStorageSlot: Methods for accessing specific storage slots formatted as common primitive types.\nStrings: Common operations for strings formatting.\nTime: A library that provides helpers for manipulating time-related objects, including a Delay type.\nTransientSlot: Primitives for reading from and writing to transient storage (only value types are currently supported).\n\nBecause Solidity does not support generic types, EnumerableMap and EnumerableSet are specialized to a limited number of key-value types.\nMath\nMath\nSignedMath\nSafeCast\nSecurity\nNonces\nNoncesKeyed\nPausable\nReentrancyGuard\nReentrancyGuardTransient\nIntrospection\nThis set of interfaces and contracts deal with type introspection of contracts, that is, examining which functions can be called on them. This is usually referred to as a contract’s interface.\nEthereum contracts have no native concept of an interface, so applications must usually simply trust that they are not making an incorrect call. For trusted setups this is a non-issue, but often unknown and untrusted third-party addresses need to be interacted with. There may not even be any direct calls to them! (e.g. ERC-20 tokens may be sent to a contract that lacks a way to transfer them out of it, locking them forever). In these cases, a contract declaring its interface can be very helpful in preventing errors.\nIERC165\nERC165\nERC165Checker\nData Structures\nAccumulators\nBitMaps\nCheckpoints\nCircularBuffer\nDoubleEndedQueue\nEnumerableMap\nEnumerableSet\nHeap\nMerkleTree\nLibraries\nAddress\nArrays\nBase58\nBase64\nBlockhash\nBytes\nCAIP10\nCAIP2\nCalldata\nComparators\nContext\nCreate2\nInteroperableAddress\nLowLevelCall\nMemory\nMulticall\nPacking\nPanic\nRelayedCall\nRLP\nShortStrings\nSlotDerivation\nStorageSlot\nStrings\nTime\nTransientSlot\n\nAddress\nimport \"@openzeppelin/contracts/utils/Address.sol\";\nCollection of functions related to the address type\nFunctions\nsendValue(recipient, amount)\nfunctionCall(target, data)\nfunctionCallWithValue(target, data, value)\nfunctionStaticCall(target, data)\nfunctionDelegateCall(target, data)\nverifyCallResultFromTarget(target, success, returndata)\nverifyCallResult(success, returndata)\n\nErrors\nAddressEmptyCode(target)\n\nsendValue(address payable recipient, uint256 amount)internal#Replacement for Solidity's transfer: sends amount wei to\nrecipient, forwarding all available gas and reverting on errors.EIP1884 increases the gas cost\nof certain opcodes, possibly making contracts go over the 2300 gas limit\nimposed by transfer, making them unable to receive funds via\ntransfer. Address.sendValue removes this limitation.Learn more.because control is transferred to recipient, care must be\ntaken to not create reentrancy vulnerabilities. Consider using\nReentrancyGuard or the\nchecks-effects-interactions pattern.\n\nfunctionCall(address target, bytes data) → bytesinternal#Performs a Solidity function call using a low level call. A\nplain call is an unsafe replacement for a function call: use this\nfunction instead.If target reverts with a revert reason or custom error, it is bubbled\nup by this function (like regular Solidity function calls). However, if\nthe call reverted with no returned reason, this function reverts with a\nErrors.FailedCall error.Returns the raw returned data. To convert to the expected return value,\nuse abi.decode.Requirements:\ntarget must be a contract.\ncalling target with data must not revert.\n\nfunctionCallWithValue(address target, bytes data, uint256 value) → bytesinternal#Same as functionCall,\nbut also transferring value wei to target.Requirements:\nthe calling contract must have an ETH balance of at least value.\nthe called Solidity function must be payable.\n\nfunctionStaticCall(address target, bytes data) → bytesinternal#Same as functionCall,\nbut performing a static call.\n\nfunctionDelegateCall(address target, bytes data) → bytesinternal#Same as functionCall,\nbut performing a delegate call.\n\nverifyCallResultFromTarget(address target, bool success, bytes returndata) → bytesinternal#Tool to verify that a low level call to smart-contract was successful, and reverts if the target\nwas not a contract or bubbling up the revert reason (falling back to Errors.FailedCall) in case\nof an unsuccessful call.This function is DEPRECATED and may be removed in the next major release.\n\nverifyCallResult(bool success, bytes returndata) → bytesinternal#Tool to verify that a low level call was successful, and reverts if it wasn't, either by bubbling the\nrevert reason or with a default Errors.FailedCall error.\n\nAddressEmptyCode(address target)error#There's no code at target (it is not a contract).\n\nArrays\nimport \"@openzeppelin/contracts/utils/Arrays.sol\";\nCollection of functions related to array types.\nFunctions\nsort(array, comp)\nsort(array)\nsort(array, comp)\nsort(array)\nsort(array, comp)\nsort(array)\nfindUpperBound(array, element)\nlowerBound(array, element)\nupperBound(array, element)\nlowerBoundMemory(array, element)\nupperBoundMemory(array, element)\nslice(array, start)\nslice(array, start, end)\nslice(array, start)\nslice(array, start, end)\nslice(array, start)\nslice(array, start, end)\nsplice(array, start)\nsplice(array, start, end)\nreplace(array, pos, replacement)\nreplace(array, pos, replacement, offset, length)\nsplice(array, start)\nsplice(array, start, end)\nreplace(array, pos, replacement)\nreplace(array, pos, replacement, offset, length)\nsplice(array, start)\nsplice(array, start, end)\nreplace(array, pos, replacement)\nreplace(array, pos, replacement, offset, length)\nunsafeAccess(arr, pos)\nunsafeAccess(arr, pos)\nunsafeAccess(arr, pos)\nunsafeAccess(arr, pos)\nunsafeAccess(arr, pos)\nunsafeMemoryAccess(arr, pos)\nunsafeMemoryAccess(arr, pos)\nunsafeMemoryAccess(arr, pos)\nunsafeMemoryAccess(arr, pos)\nunsafeMemoryAccess(arr, pos)\nunsafeSetLength(array, len)\nunsafeSetLength(array, len)\nunsafeSetLength(array, len)\nunsafeSetLength(array, len)\nunsafeSetLength(array, len)\n\nsort(uint256[] array, function (uint256,uint256) pure returns (bool) comp) → uint256[]internal#Sort an array of uint256 (in memory) following the provided comparator function.This function does the sorting \"in place\", meaning that it overrides the input. The object is returned for\nconvenience, but that returned value can be discarded safely if the caller has a memory pointer to the array.this function's cost is O(n · log(n)) in average and O(n²) in the worst case, with n the length of the\narray. Using it in view functions that are executed through eth_call is safe, but one should be very careful\nwhen executing this as part of a transaction. If the array being sorted is too large, the sort operation may\nconsume more gas than is available in a block, leading to potential DoS.Consider memory side-effects when using custom comparator functions that access memory in an unsafe way.\n\nsort(uint256[] array) → uint256[]internal#Variant of Arrays.sort that sorts an array of uint256 in increasing order.\n\nsort(address[] array, function (address,address) pure returns (bool) comp) → address[]internal#Sort an array of address (in memory) following the provided comparator function.This function does the sorting \"in place\", meaning that it overrides the input. The object is returned for\nconvenience, but that returned value can be discarded safely if the caller has a memory pointer to the array.this function's cost is O(n · log(n)) in average and O(n²) in the worst case, with n the length of the\narray. Using it in view functions that are executed through eth_call is safe, but one should be very careful\nwhen executing this as part of a transaction. If the array being sorted is too large, the sort operation may\nconsume more gas than is available in a block, leading to potential DoS.Consider memory side-effects when using custom comparator functions that access memory in an unsafe way.\n\nsort(address[] array) → address[]internal#Variant of Arrays.sort that sorts an array of address in increasing order.\n\nsort(bytes32[] array, function (bytes32,bytes32) pure returns (bool) comp) → bytes32[]internal#Sort an array of bytes32 (in memory) following the provided comparator function.This function does the sorting \"in place\", meaning that it overrides the input. The object is returned for\nconvenience, but that returned value can be discarded safely if the caller has a memory pointer to the array.this function's cost is O(n · log(n)) in average and O(n²) in the worst case, with n the length of the\narray. Using it in view functions that are executed through eth_call is safe, but one should be very careful\nwhen executing this as part of a transaction. If the array being sorted is too large, the sort operation may\nconsume more gas than is available in a block, leading to potential DoS.Consider memory side-effects when using custom comparator functions that access memory in an unsafe way.\n\nsort(bytes32[] array) → bytes32[]internal#Variant of Arrays.sort that sorts an array of bytes32 in increasing order.\n\nfindUpperBound(uint256[] array, uint256 element) → uint256internal#Searches a sorted array and returns the first index that contains\na value greater or equal to element. If no such index exists (i.e. all\nvalues in the array are strictly less than element), the array length is\nreturned. Time complexity O(log n).The array is expected to be sorted in ascending order, and to\ncontain no repeated elements.Deprecated. This implementation behaves as Arrays.lowerBound but lacks\nsupport for repeated elements in the array. The Arrays.lowerBound function should\nbe used instead.\n\nlowerBound(uint256[] array, uint256 element) → uint256internal#Searches an array sorted in ascending order and returns the first\nindex that contains a value greater or equal than element. If no such index\nexists (i.e. all values in the array are strictly less than element), the array\nlength is returned. Time complexity O(log n).See C++'s lower_bound.\n\nupperBound(uint256[] array, uint256 element) → uint256internal#Searches an array sorted in ascending order and returns the first\nindex that contains a value strictly greater than element. If no such index\nexists (i.e. all values in the array are strictly less than element), the array\nlength is returned. Time complexity O(log n).See C++'s upper_bound.\n\nlowerBoundMemory(uint256[] array, uint256 element) → uint256internal#Same as Arrays.lowerBound, but with an array in memory.\n\nupperBoundMemory(uint256[] array, uint256 element) → uint256internal#Same as Arrays.upperBound, but with an array in memory.\n\nslice(address[] array, uint256 start) → address[]internal#Copies the content of array, from start (included) to the end of array into a new address array in\nmemory.replicates the behavior of Javascript's Array.slice\n\nslice(address[] array, uint256 start, uint256 end) → address[]internal#Copies the content of array, from start (included) to end (excluded) into a new address array in\nmemory. The end argument is truncated to the length of the array.replicates the behavior of Javascript's Array.slice\n\nslice(bytes32[] array, uint256 start) → bytes32[]internal#Copies the content of array, from start (included) to the end of array into a new bytes32 array in\nmemory.replicates the behavior of Javascript's Array.slice\n\nslice(bytes32[] array, uint256 start, uint256 end) → bytes32[]internal#Copies the content of array, from start (included) to end (excluded) into a new bytes32 array in\nmemory. The end argument is truncated to the length of the array.replicates the behavior of Javascript's Array.slice\n\nslice(uint256[] array, uint256 start) → uint256[]internal#Copies the content of array, from start (included) to the end of array into a new uint256 array in\nmemory.replicates the behavior of Javascript's Array.slice\n\nslice(uint256[] array, uint256 start, uint256 end) → uint256[]internal#Copies the content of array, from start (included) to end (excluded) into a new uint256 array in\nmemory. The end argument is truncated to the length of the array.replicates the behavior of Javascript's Array.slice\n\nsplice(address[] array, uint256 start) → address[]internal#Moves the content of array, from start (included) to the end of array to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:].This function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\n\nsplice(address[] array, uint256 start, uint256 end) → address[]internal#Moves the content of array, from start (included) to end (excluded) to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:end]. The\nend argument is truncated to the length of the array.This function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\n\nreplace(address[] array, uint256 pos, address[] replacement) → address[]internal#Replaces elements in array starting at pos with all elements from replacement.Parameters are clamped to valid ranges (e.g. pos is clamped to [0, array.length]).\nIf pos >= array.length, no replacement occurs and the array is returned unchanged.This function modifies the provided array in place.\n\nreplace(address[] array, uint256 pos, address[] replacement, uint256 offset, uint256 length) → address[]internal#Replaces elements in array starting at pos with elements from replacement starting at offset.\nCopies at most length elements from replacement to array.Parameters are clamped to valid ranges (i.e. pos is clamped to [0, array.length], offset is\nclamped to [0, replacement.length], and length is clamped to min(length, replacement.length - offset, array.length - pos)). If pos >= array.length or offset >= replacement.length, no replacement occurs\nand the array is returned unchanged.This function modifies the provided array in place.\n\nsplice(bytes32[] array, uint256 start) → bytes32[]internal#Moves the content of array, from start (included) to the end of array to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:].This function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\n\nsplice(bytes32[] array, uint256 start, uint256 end) → bytes32[]internal#Moves the content of array, from start (included) to end (excluded) to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:end]. The\nend argument is truncated to the length of the array.This function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\n\nreplace(bytes32[] array, uint256 pos, bytes32[] replacement) → bytes32[]internal#Replaces elements in array starting at pos with all elements from replacement.Parameters are clamped to valid ranges (e.g. pos is clamped to [0, array.length]).\nIf pos >= array.length, no replacement occurs and the array is returned unchanged.This function modifies the provided array in place.\n\nreplace(bytes32[] array, uint256 pos, bytes32[] replacement, uint256 offset, uint256 length) → bytes32[]internal#Replaces elements in array starting at pos with elements from replacement starting at offset.\nCopies at most length elements from replacement to array.Parameters are clamped to valid ranges (i.e. pos is clamped to [0, array.length], offset is\nclamped to [0, replacement.length], and length is clamped to min(length, replacement.length - offset, array.length - pos)). If pos >= array.length or offset >= replacement.length, no replacement occurs\nand the array is returned unchanged.This function modifies the provided array in place.\n\nsplice(uint256[] array, uint256 start) → uint256[]internal#Moves the content of array, from start (included) to the end of array to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:].This function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\n\nsplice(uint256[] array, uint256 start, uint256 end) → uint256[]internal#Moves the content of array, from start (included) to end (excluded) to the start of that array,\nand shrinks the array length accordingly, effectively overwriting the array with array[start:end]. The\nend argument is truncated to the length of the array.This function modifies the provided array in place. If you need to preserve the original array, use Arrays.slice instead.\n\nreplace(uint256[] array, uint256 pos, uint256[] replacement) → uint256[]internal#Replaces elements in array starting at pos with all elements from replacement.Parameters are clamped to valid ranges (e.g. pos is clamped to [0, array.length]).\nIf pos >= array.length, no replacement occurs and the array is returned unchanged.This function modifies the provided array in place.\n\nreplace(uint256[] array, uint256 pos, uint256[] replacement, uint256 offset, uint256 length) → uint256[]internal#Replaces elements in array starting at pos with elements from replacement starting at offset.\nCopies at most length elements from replacement to array.Parameters are clamped to valid ranges (i.e. pos is clamped to [0, array.length], offset is\nclamped to [0, replacement.length], and length is clamped to min(length, replacement.length - offset, array.length - pos)). If pos >= array.length or offset >= replacement.length, no replacement occurs\nand the array is returned unchanged.This function modifies the provided array in place.\n\nunsafeAccess(address[] arr, uint256 pos) → struct StorageSlot.AddressSlotinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeAccess(bytes32[] arr, uint256 pos) → struct StorageSlot.Bytes32Slotinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeAccess(uint256[] arr, uint256 pos) → struct StorageSlot.Uint256Slotinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeAccess(bytes[] arr, uint256 pos) → struct StorageSlot.BytesSlotinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeAccess(string[] arr, uint256 pos) → struct StorageSlot.StringSlotinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeMemoryAccess(address[] arr, uint256 pos) → address resinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeMemoryAccess(bytes32[] arr, uint256 pos) → bytes32 resinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeMemoryAccess(uint256[] arr, uint256 pos) → uint256 resinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeMemoryAccess(bytes[] arr, uint256 pos) → bytes resinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeMemoryAccess(string[] arr, uint256 pos) → string resinternal#Access an array in an \"unsafe\" way. Skips solidity \"index-out-of-range\" check.Only use if you are certain pos is lower than the array length.\n\nunsafeSetLength(address[] array, uint256 len)internal#Helper to set the length of a dynamic array. Directly writing to .length is forbidden.this does not clear elements if length is reduced, or initialize elements if length is increased.\n\nunsafeSetLength(bytes32[] array, uint256 len)internal#Helper to set the length of a dynamic array. Directly writing to .length is forbidden.this does not clear elements if length is reduced, or initialize elements if length is increased.\n\nunsafeSetLength(uint256[] array, uint256 len)internal#Helper to set the length of a dynamic array. Directly writing to .length is forbidden.this does not clear elements if length is reduced, or initialize elements if length is increased.\n\nunsafeSetLength(bytes[] array, uint256 len)internal#Helper to set the length of a dynamic array. Directly writing to .length is forbidden.this does not clear elements if length is reduced, or initialize elements if length is increased.\n\nunsafeSetLength(string[] array, uint256 len)internal#Helper to set the length of a dynamic array. Directly writing to .length is forbidden.this does not clear elements if length is reduced, or initialize elements if length is increased.\n\nBase58\nimport \"@openzeppelin/contracts/utils/Base58.sol\";\nProvides a set of functions to operate with Base58 strings.\nBase58 is an encoding scheme that converts binary data into a human-readable text format.\nSimilar to Base64 but specifically designed for better human usability.\n\nHuman-friendly alphabet: Excludes visually similar characters to reduce human error:\n\nNo 0 (zero) vs O (capital o) confusion\nNo I (capital i) vs l (lowercase L) confusion\nNo non-alphanumeric characters like + or =\n\nURL-safe: Contains only alphanumeric characters, making it safe for URLs without encoding.\n\nInitially based on storyicon's implementation (MIT).\nBased on the updated and improved Vectorized version (MIT).\nFunctions\nencode(input)\ndecode(input)\n\nErrors\nInvalidBase58Char()\n\nencode(bytes input) → stringinternal#Encode a bytes buffer as a Base58 string.\n\ndecode(string input) → bytesinternal#Decode a Base58 string into a bytes buffer.\n\nInvalidBase58Char(bytes1)error#Unrecognized Base58 character on decoding.\n\nBase64\nimport \"@openzeppelin/contracts/utils/Base64.sol\";\nProvides a set of functions to operate with Base64 strings.\nFunctions\nencode(data)\nencodeURL(data)\ndecode(data)\n\nErrors\nInvalidBase64Char()\n\nencode(bytes data) → stringinternal#Converts a bytes to its Base64 string representation.\n\nencodeURL(bytes data) → stringinternal#Converts a bytes to its Base64Url string representation.\nOutput is not padded with = as specified in rfc4648.\n\ndecode(string data) → bytesinternal#Converts a Base64 string to the bytes it represents.\nSupports padded and unpadded inputs.\nSupports both encoding (Base58.encode and Base64.encodeURL) seamlessly.\nReverts with Base64.InvalidBase64Char if the input contains an invalid character.\n\nInvalidBase64Char(bytes1)error#\n\nBlockhash\nimport \"@openzeppelin/contracts/utils/Blockhash.sol\";\nLibrary for accessing historical block hashes beyond the standard 256 block limit.\nUses EIP-2935's history storage contract which maintains a ring buffer of the last\n8191 block hashes in state.\nFor blocks within the last 256 blocks, it uses the native BLOCKHASH opcode.\nFor blocks between 257 and 8191 blocks ago, it queries the EIP-2935 history storage.\nFor blocks older than 8191 or future blocks, it returns zero, matching the BLOCKHASH behavior.\nAfter EIP-2935 activation, it takes 8191 blocks to completely fill the history.\nBefore that, only block hashes since the fork block will be available.\nFunctions\nblockHash(blockNumber)\n\nblockHash(uint256 blockNumber) → bytes32internal#Retrieves the block hash for any historical block within the supported range.The function gracefully handles future blocks and blocks beyond the history window\nby returning zero, consistent with the EVM's native BLOCKHASH behavior.\n\nBytes\nimport \"@openzeppelin/contracts/utils/Bytes.sol\";\nBytes operations.\nFunctions\nindexOf(buffer, s)\nindexOf(buffer, s, pos)\nlastIndexOf(buffer, s)\nlastIndexOf(buffer, s, pos)\nslice(buffer, start)\nslice(buffer, start, end)\nsplice(buffer, start)\nsplice(buffer, start, end)\nreplace(buffer, pos, replacement)\nreplace(buffer, pos, replacement, offset, length)\nconcat(buffers)\ntoNibbles(input)\nequal(a, b)\nreverseBytes32(value)\nreverseBytes16(value)\nreverseBytes8(value)\nreverseBytes4(value)\nreverseBytes2(value)\nclz(buffer)\n\nindexOf(bytes buffer, bytes1 s) → uint256internal#Forward search for s in buffer\nIf s is present in the buffer, returns the index of the first instance\nIf s is not present in the buffer, returns type(uint256).max\nreplicates the behavior of Javascript's Array.indexOf\n\nindexOf(bytes buffer, bytes1 s, uint256 pos) → uint256internal#Forward search for s in buffer starting at position pos\nIf s is present in the buffer (at or after pos), returns the index of the next instance\nIf s is not present in the buffer (at or after pos), returns type(uint256).max\nreplicates the behavior of Javascript's Array.indexOf\n\nlastIndexOf(bytes buffer, bytes1 s) → uint256internal#Backward search for s in buffer\nIf s is present in the buffer, returns the index of the last instance\nIf s is not present in the buffer, returns type(uint256).max\nreplicates the behavior of Javascript's Array.lastIndexOf\n\nlastIndexOf(bytes buffer, bytes1 s, uint256 pos) → uint256internal#Backward search for s in buffer starting at position pos\nIf s is present in the buffer (at or before pos), returns the index of the previous instance\nIf s is not present in the buffer (at or before pos), returns type(uint256).max\nreplicates the behavior of Javascript's Array.lastIndexOf\n\nslice(bytes buffer, uint256 start) → bytesinternal#Copies the content of buffer, from start (included) to the end of buffer into a new bytes object in\nmemory.replicates the behavior of Javascript's Array.slice\n\nslice(bytes buffer, uint256 start, uint256 end) → bytesinternal#Copies the content of buffer, from start (included) to end (excluded) into a new bytes object in\nmemory. The end argument is truncated to the length of the buffer.replicates the behavior of Javascript's Array.slice\n\nsplice(bytes buffer, uint256 start) → bytesinternal#Moves the content of buffer, from start (included) to the end of buffer to the start of that buffer,\nand shrinks the buffer length accordingly, effectively overriding the content of buffer with buffer[start:].This function modifies the provided buffer in place. If you need to preserve the original buffer, use Arrays.slice instead\n\nsplice(bytes buffer, uint256 start, uint256 end) → bytesinternal#Moves the content of buffer, from start (included) to end (excluded) to the start of that buffer,\nand shrinks the buffer length accordingly, effectively overriding the content of buffer with buffer[start:end].\nThe end argument is truncated to the length of the buffer.This function modifies the provided buffer in place. If you need to preserve the original buffer, use Arrays.slice instead\n\nreplace(bytes buffer, uint256 pos, bytes replacement) → bytesinternal#Replaces bytes in buffer starting at pos with all bytes from replacement.Parameters are clamped to valid ranges (i.e. pos is clamped to [0, buffer.length]).\nIf pos >= buffer.length, no replacement occurs and the buffer is returned unchanged.This function modifies the provided buffer in place.\n\nreplace(bytes buffer, uint256 pos, bytes replacement, uint256 offset, uint256 length) → bytesinternal#Replaces bytes in buffer starting at pos with bytes from replacement starting at offset.\nCopies at most length bytes from replacement to buffer.Parameters are clamped to valid ranges (i.e. pos is clamped to [0, buffer.length], offset is\nclamped to [0, replacement.length], and length is clamped to min(length, replacement.length - offset, buffer.length - pos)). If pos >= buffer.length or offset >= replacement.length, no replacement occurs\nand the buffer is returned unchanged.This function modifies the provided buffer in place.\n\nconcat(bytes[] buffers) → bytesinternal#Concatenate an array of bytes into a single bytes object.For fixed bytes types, we recommend using the solidity built-in bytes.concat or (equivalent)\nabi.encodePacked.this could be done in assembly with a single loop that expands starting at the FMP, but that would be\nsignificantly less readable. It might be worth benchmarking the savings of the full-assembly approach.\n\ntoNibbles(bytes input) → bytes outputinternal#Split each byte in input into two nibbles (4 bits each)Example: hex\"01234567\" → hex\"0001020304050607\"\n\nequal(bytes a, bytes b) → boolinternal#Returns true if the two byte buffers are equal.\n\nreverseBytes32(bytes32 value) → bytes32internal#Reverses the byte order of a bytes32 value, converting between little-endian and big-endian.\nInspired by Reverse Parallel\n\nreverseBytes16(bytes16 value) → bytes16internal#Same as Bytes.reverseBytes32 but optimized for 128-bit values.\n\nreverseBytes8(bytes8 value) → bytes8internal#Same as Bytes.reverseBytes32 but optimized for 64-bit values.\n\nreverseBytes4(bytes4 value) → bytes4internal#Same as Bytes.reverseBytes32 but optimized for 32-bit values.\n\nreverseBytes2(bytes2 value) → bytes2internal#Same as Bytes.reverseBytes32 but optimized for 16-bit values.\n\nclz(bytes buffer) → uint256internal#Counts the number of leading zero bits a bytes array. Returns 8 * buffer.length\nif the buffer is all zeros.\n\nCAIP10\nimport \"@openzeppelin/contracts/utils/CAIP10.sol\";\nHelper library to format and parse CAIP-10 identifiers\nCAIP-10 defines account identifiers as:\naccount_id: chain_id + \":\" + account_address\nchain_id: [-a-z0-9]8:[-_a-zA-Z0-9]32 (See CAIP2)\naccount_address: [-.%a-zA-Z0-9]128\nAccording to CAIP-10's canonicalization section,\nthe implementation remains at the developer's discretion. Please note that case variations may introduce ambiguity.\nFor example, when building hashes to identify accounts or data associated to them, multiple representations of the\nsame account would derive to different hashes. For EVM chains, we recommend using checksummed addresses for the\n\"account_address\" part. They can be generated onchain using Strings.toChecksumHexString.\nFunctions\nlocal(account)\nformat(caip2, account)\nparse(caip10)\n\nlocal(address account) → stringinternal#Return the CAIP-10 identifier for an account on the current (local) chain.\n\nformat(string caip2, string account) → stringinternal#Return the CAIP-10 identifier for a given caip2 chain and account.This function does not verify that the inputs are properly formatted.\n\nparse(string caip10) → string caip2, string accountinternal#Parse a CAIP-10 identifier into its components.This function does not verify that the CAIP-10 input is properly formatted. The caip2 return can be\nparsed using the CAIP2 library.\n\nCAIP2\nimport \"@openzeppelin/contracts/utils/CAIP2.sol\";\nHelper library to format and parse CAIP-2 identifiers\nCAIP-2 defines chain identifiers as:\nchain_id: namespace + \":\" + reference\nnamespace: [-a-z0-9]8\nreference: [-_a-zA-Z0-9]32\nIn some cases, multiple CAIP-2 identifiers may all be valid representation of a single chain.\nFor EVM chains, it is recommended to use eip155:xxx as the canonical representation (where xxx is\nthe EIP-155 chain id). Consider the possible ambiguity when processing CAIP-2 identifiers or when using them\nin the context of hashes.\nFunctions\nlocal()\nformat(namespace, ref)\nparse(caip2)\n\nlocal() → stringinternal#Return the CAIP-2 identifier for the current (local) chain.\n\nformat(string namespace, string ref) → stringinternal#Return the CAIP-2 identifier for a given namespace and reference.This function does not verify that the inputs are properly formatted.\n\nparse(string caip2) → string namespace, string refinternal#Parse a CAIP-2 identifier into its components.This function does not verify that the CAIP-2 input is properly formatted.\n\nCalldata\nimport \"@openzeppelin/contracts/utils/Calldata.sol\";\nHelper library for manipulating objects in calldata.\nFunctions\nemptyBytes()\nemptyString()\n\nemptyBytes() → bytes resultinternal#\n\nemptyString() → string resultinternal#\n\nComparators\nimport \"@openzeppelin/contracts/utils/Comparators.sol\";\nProvides a set of functions to compare values.\nAvailable since v5.1.\nFunctions\nlt(a, b)\ngt(a, b)\n\nlt(uint256 a, uint256 b) → boolinternal#\n\ngt(uint256 a, uint256 b) → boolinternal#\n\nContext\nimport \"@openzeppelin/contracts/utils/Context.sol\";\nProvides information about the current execution context, including the\nsender of the transaction and its data. While these are generally available\nvia msg.sender and msg.data, they should not be accessed in such a direct\nmanner, since when dealing with meta-transactions the account sending and\npaying for execution may not be the actual sender (as far as an application\nis concerned).\nThis contract is only required for intermediate, library-like contracts.\nFunctions\n_msgSender()\n_msgData()\n_contextSuffixLength()\n\n_msgSender() → addressinternal#\n\n_msgData() → bytesinternal#\n\n_contextSuffixLength() → uint256internal#\n\nCreate2\nimport \"@openzeppelin/contracts/utils/Create2.sol\";\nHelper to make usage of the CREATE2 EVM opcode easier and safer.\nCREATE2 can be used to compute in advance the address where a smart\ncontract will be deployed, which allows for interesting new mechanisms known\nas 'counterfactual interactions'.\nSee the EIP for more\ninformation.\nFunctions\ndeploy(amount, salt, bytecode)\ncomputeAddress(salt, bytecodeHash)\ncomputeAddress(salt, bytecodeHash, deployer)\n\nErrors\nCreate2EmptyBytecode()\n\ndeploy(uint256 amount, bytes32 salt, bytes bytecode) → address addrinternal#Deploys a contract using CREATE2. The address where the contract\nwill be deployed can be known in advance via Create2.computeAddress.The bytecode for a contract can be obtained from Solidity with\ntype(contractName).creationCode.Requirements:\nbytecode must not be empty.\nsalt must have not been used for bytecode already.\nthe factory must have a balance of at least amount.\nif amount is non-zero, bytecode must have a payable constructor.\n\ncomputeAddress(bytes32 salt, bytes32 bytecodeHash) → addressinternal#Returns the address where a contract will be stored if deployed via Create2.deploy. Any change in the\nbytecodeHash or salt will result in a new destination address.\n\ncomputeAddress(bytes32 salt, bytes32 bytecodeHash, address deployer) → address addrinternal#Returns the address where a contract will be stored if deployed via Create2.deploy from a contract located at\ndeployer. If deployer is this contract's address, returns the same value as Create2.computeAddress.\n\nCreate2EmptyBytecode()error#There's no code to deploy.\n\nErrors\nimport \"@openzeppelin/contracts/utils/Errors.sol\";\nCollection of common custom errors used in multiple contracts\nBackwards compatibility is not guaranteed in future versions of the library.\nIt is recommended to avoid relying on the error API for critical functionality.\nAvailable since v5.1.\nErrors\nInsufficientBalance(balance, needed)\nFailedCall()\nFailedDeployment()\nMissingPrecompile()\n\nInsufficientBalance(uint256 balance, uint256 needed)error#The ETH balance of the account is not enough to perform the operation.\n\nFailedCall()error#A call to an address target failed. The target may have reverted.\n\nFailedDeployment()error#The deployment failed.\n\nMissingPrecompile(address)error#A necessary precompile is missing.\n\nLowLevelCall\nimport \"@openzeppelin/contracts/utils/LowLevelCall.sol\";\nLibrary of low level call functions that implement different calling strategies to deal with the return data.\nUsing this library requires an advanced understanding of Solidity and how the EVM works. It is recommended\nto use the Address library instead.\nFunctions\ncallNoReturn(target, data)\ncallNoReturn(target, value, data)\ncallReturn64Bytes(target, data)\ncallReturn64Bytes(target, value, data)\nstaticcallNoReturn(target, data)\nstaticcallReturn64Bytes(target, data)\ndelegatecallNoReturn(target, data)\ndelegatecallReturn64Bytes(target, data)\nreturnDataSize()\nreturnData()\nbubbleRevert()\nbubbleRevert(returndata)\n\ncallNoReturn(address target, bytes data) → bool successinternal#Performs a Solidity function call using a low level call and ignoring the return data.\n\ncallNoReturn(address target, uint256 value, bytes data) → bool successinternal#Same as callNoReturn-address-bytes, but allows specifying the value to be sent in the call.\n\ncallReturn64Bytes(address target, bytes data) → bool success, bytes32 result1, bytes32 result2internal#Performs a Solidity function call using a low level call and returns the first 64 bytes of the result\nin the scratch space of memory. Useful for functions that return a tuple with two single-word values.Do not assume that the results are zero if success is false. Memory can be already allocated\nand this function doesn't zero it out.\n\ncallReturn64Bytes(address target, uint256 value, bytes data) → bool success, bytes32 result1, bytes32 result2internal#Same as callReturn64Bytes-address-bytes, but allows specifying the value to be sent in the call.\n\nstaticcallNoReturn(address target, bytes data) → bool successinternal#Performs a Solidity function call using a low level staticcall and ignoring the return data.\n\nstaticcallReturn64Bytes(address target, bytes data) → bool success, bytes32 result1, bytes32 result2internal#Performs a Solidity function call using a low level staticcall and returns the first 64 bytes of the result\nin the scratch space of memory. Useful for functions that return a tuple with two single-word values.Do not assume that the results are zero if success is false. Memory can be already allocated\nand this function doesn't zero it out.\n\ndelegatecallNoReturn(address target, bytes data) → bool successinternal#Performs a Solidity function call using a low level delegatecall and ignoring the return data.\n\ndelegatecallReturn64Bytes(address target, bytes data) → bool success, bytes32 result1, bytes32 result2internal#Performs a Solidity function call using a low level delegatecall and returns the first 64 bytes of the result\nin the scratch space of memory. Useful for functions that return a tuple with two single-word values.Do not assume that the results are zero if success is false. Memory can be already allocated\nand this function doesn't zero it out.\n\nreturnDataSize() → uint256 sizeinternal#Returns the size of the return data buffer.\n\nreturnData() → bytes resultinternal#Returns a buffer containing the return data from the last call.\n\nbubbleRevert()internal#Revert with the return data from the last call.\n\nbubbleRevert(bytes returndata)internal#\n\nMemory\nimport \"@openzeppelin/contracts/utils/Memory.sol\";\nUtilities to manipulate memory.\nMemory is a contiguous and dynamic byte array in which Solidity stores non-primitive types.\nThis library provides functions to manipulate pointers to this dynamic array and work with slices of it.\nSlices provide a view into a portion of memory without copying data, enabling efficient substring operations.\nWhen manipulating memory pointers or slices, make sure to follow the Solidity documentation\nguidelines for Memory Safety.\nFunctions\ngetFreeMemoryPointer()\nunsafeSetFreeMemoryPointer(ptr)\nforward(ptr, offset)\nequal(ptr1, ptr2)\nasSlice(self)\nlength(self)\nslice(self, offset)\nslice(self, offset, len)\nload(self, offset)\ntoBytes(self)\nequal(a, b)\nisReserved(self)\n\ngetFreeMemoryPointer() → Memory.Pointer ptrinternal#Returns a Pointer to the current free Pointer.\n\nunsafeSetFreeMemoryPointer(Memory.Pointer ptr)internal#Sets the free Pointer to a specific value.The solidity memory layout requires that the FMP is never set to a value lower than 0x80. Setting the\nFMP to a value lower than 0x80 may cause unexpected behavior. Deallocating all memory can be achieved by\nsetting the FMP to 0x80.Everything after the pointer may be overwritten.\n\nforward(Memory.Pointer ptr, uint256 offset) → Memory.Pointerinternal#Move a pointer forward by a given offset.\n\nequal(Memory.Pointer ptr1, Memory.Pointer ptr2) → boolinternal#Equality comparator for memory pointers.\n\nasSlice(bytes self) → Memory.Slice resultinternal#Get a slice representation of a bytes object in memory\n\nlength(Memory.Slice self) → uint256 resultinternal#Returns the length of a given slice (equiv to self.length for calldata slices)\n\nslice(Memory.Slice self, uint256 offset) → Memory.Sliceinternal#Offset a memory slice (equivalent to self[offset:] for calldata slices)\n\nslice(Memory.Slice self, uint256 offset, uint256 len) → Memory.Sliceinternal#Offset and cut a Slice (equivalent to self[offset:offset+len] for calldata slices)\n\nload(Memory.Slice self, uint256 offset) → bytes32 valueinternal#Read a bytes32 buffer from a given Slice at a specific offsetIf offset > length(slice) - 0x20, part of the return value will be out of bound of the slice. These bytes are zeroed.\n\ntoBytes(Memory.Slice self) → bytes resultinternal#Extract the data corresponding to a Slice (allocate new memory)\n\nequal(Memory.Slice a, Memory.Slice b) → bool resultinternal#Returns true if the two slices contain the same data.\n\nisReserved(Memory.Slice self) → bool resultinternal#Returns true if the memory occupied by the slice is reserved (i.e. before the free memory pointer)\n\nMulticall\nimport \"@openzeppelin/contracts/utils/Multicall.sol\";\nProvides a function to batch together multiple calls in a single external call.\nConsider any assumption about calldata validation performed by the sender may be violated if it's not especially\ncareful about sending transactions invoking Multicall.multicall. For example, a relay address that filters function\nselectors won't filter calls nested within a Multicall.multicall operation.\nSince 5.0.1 and 4.9.4, this contract identifies non-canonical contexts (i.e. msg.sender is not Context._msgSender).\nIf a non-canonical context is identified, the following self delegatecall appends the last bytes of msg.data\nto the subcall. This makes it safe to use with ERC2771Context. Contexts that don't affect the resolution of\nContext._msgSender are not propagated to subcalls.\nFunctions\nmulticall(data)\n\nmulticall(bytes[] data) → bytes[] resultspublic#Receives and executes a batch of function calls on this contract.\n\nNonces\nimport \"@openzeppelin/contracts/utils/Nonces.sol\";\nProvides tracking nonces for addresses. Nonces will only increment.\nFunctions\nnonces(owner)\n_useNonce(owner)\n_useCheckedNonce(owner, nonce)\n\nErrors\nInvalidAccountNonce(account, currentNonce)\n\nnonces(address owner) → uint256public#Returns the next unused nonce for an address.\n\n_useNonce(address owner) → uint256internal#Consumes a nonce.Returns the current value and increments nonce.\n\n_useCheckedNonce(address owner, uint256 nonce)internal#Same as Nonces._useNonce but checking that nonce is the next valid for owner.\n\nInvalidAccountNonce(address account, uint256 currentNonce)error#The nonce used for an account is not the expected current nonce.\n\nNoncesKeyed\nimport \"@openzeppelin/contracts/utils/NoncesKeyed.sol\";\nAlternative to Nonces, that supports key-ed nonces.\nFollows the ERC-4337's semi-abstracted nonce system.\nThis contract inherits from Nonces and reuses its storage for the first nonce key (i.e. 0). This\nmakes upgrading from Nonces to NoncesKeyed safe when using their upgradeable versions (e.g. NoncesKeyedUpgradeable).\nDoing so will NOT reset the current state of nonces, avoiding replay attacks where a nonce is reused after the upgrade.\nFunctions\nnonces(owner, key)\n_useNonce(owner, key)\n_useCheckedNonce(owner, keyNonce)\n_useCheckedNonce(owner, key, nonce)\nNonces\nnonces(owner)\n_useNonce(owner)\n\nErrorsNonces\nInvalidAccountNonce(account, currentNonce)\n\nnonces(address owner, uint192 key) → uint256public#Returns the next unused nonce for an address and key. Result contains the key prefix.\n\n_useNonce(address owner, uint192 key) → uint256internal#Consumes the next unused nonce for an address and key.Returns the current value without the key prefix. Consumed nonce is increased, so calling this function twice\nwith the same arguments will return different (sequential) results.\n\n_useCheckedNonce(address owner, uint256 keyNonce)internal#Same as Nonces._useNonce but checking that nonce is the next valid for owner.This version takes the key and the nonce in a single uint256 parameter:\nuse the first 24 bytes for the key\nuse the last 8 bytes for the nonce\n\n_useCheckedNonce(address owner, uint192 key, uint64 nonce)internal#Same as Nonces._useNonce but checking that nonce is the next valid for owner.This version takes the key and the nonce as two different parameters.\n\nPacking\nimport \"@openzeppelin/contracts/utils/Packing.sol\";\nHelper library packing and unpacking multiple values into bytesXX.\nExample usage:\nlibrary MyPacker {\n type MyType is bytes32;\n\n function _pack(address account, bytes4 selector, uint64 period) external pure returns (MyType) {\n bytes12 subpack = Packing.pack_4_8(selector, bytes8(period));\n bytes32 pack = Packing.pack_20_12(bytes20(account), subpack);\n return MyType.wrap(pack);\n }\n\n function _unpack(MyType self) external pure returns (address, bytes4, uint64) {\n bytes32 pack = MyType.unwrap(self);\n return (\n address(Packing.extract_32_20(pack, 0)),\n Packing.extract_32_4(pack, 20),\n uint64(Packing.extract_32_8(pack, 24))\n );\n }\n}\nAvailable since v5.1.\nFunctions\npack_1_1(left, right)\npack_2_2(left, right)\npack_2_4(left, right)\npack_2_6(left, right)\npack_2_8(left, right)\npack_2_10(left, right)\npack_2_20(left, right)\npack_2_22(left, right)\npack_4_2(left, right)\npack_4_4(left, right)\npack_4_6(left, right)\npack_4_8(left, right)\npack_4_12(left, right)\npack_4_16(left, right)\npack_4_20(left, right)\npack_4_24(left, right)\npack_4_28(left, right)\npack_6_2(left, right)\npack_6_4(left, right)\npack_6_6(left, right)\npack_6_10(left, right)\npack_6_16(left, right)\npack_6_22(left, right)\npack_8_2(left, right)\npack_8_4(left, right)\npack_8_8(left, right)\npack_8_12(left, right)\npack_8_16(left, right)\npack_8_20(left, right)\npack_8_24(left, right)\npack_10_2(left, right)\npack_10_6(left, right)\npack_10_10(left, right)\npack_10_12(left, right)\npack_10_22(left, right)\npack_12_4(left, right)\npack_12_8(left, right)\npack_12_10(left, right)\npack_12_12(left, right)\npack_12_16(left, right)\npack_12_20(left, right)\npack_16_4(left, right)\npack_16_6(left, right)\npack_16_8(left, right)\npack_16_12(left, right)\npack_16_16(left, right)\npack_20_2(left, right)\npack_20_4(left, right)\npack_20_8(left, right)\npack_20_12(left, right)\npack_22_2(left, right)\npack_22_6(left, right)\npack_22_10(left, right)\npack_24_4(left, right)\npack_24_8(left, right)\npack_28_4(left, right)\nextract_2_1(self, offset)\nreplace_2_1(self, value, offset)\nextract_4_1(self, offset)\nreplace_4_1(self, value, offset)\nextract_4_2(self, offset)\nreplace_4_2(self, value, offset)\nextract_6_1(self, offset)\nreplace_6_1(self, value, offset)\nextract_6_2(self, offset)\nreplace_6_2(self, value, offset)\nextract_6_4(self, offset)\nreplace_6_4(self, value, offset)\nextract_8_1(self, offset)\nreplace_8_1(self, value, offset)\nextract_8_2(self, offset)\nreplace_8_2(self, value, offset)\nextract_8_4(self, offset)\nreplace_8_4(self, value, offset)\nextract_8_6(self, offset)\nreplace_8_6(self, value, offset)\nextract_10_1(self, offset)\nreplace_10_1(self, value, offset)\nextract_10_2(self, offset)\nreplace_10_2(self, value, offset)\nextract_10_4(self, offset)\nreplace_10_4(self, value, offset)\nextract_10_6(self, offset)\nreplace_10_6(self, value, offset)\nextract_10_8(self, offset)\nreplace_10_8(self, value, offset)\nextract_12_1(self, offset)\nreplace_12_1(self, value, offset)\nextract_12_2(self, offset)\nreplace_12_2(self, value, offset)\nextract_12_4(self, offset)\nreplace_12_4(self, value, offset)\nextract_12_6(self, offset)\nreplace_12_6(self, value, offset)\nextract_12_8(self, offset)\nreplace_12_8(self, value, offset)\nextract_12_10(self, offset)\nreplace_12_10(self, value, offset)\nextract_16_1(self, offset)\nreplace_16_1(self, value, offset)\nextract_16_2(self, offset)\nreplace_16_2(self, value, offset)\nextract_16_4(self, offset)\nreplace_16_4(self, value, offset)\nextract_16_6(self, offset)\nreplace_16_6(self, value, offset)\nextract_16_8(self, offset)\nreplace_16_8(self, value, offset)\nextract_16_10(self, offset)\nreplace_16_10(self, value, offset)\nextract_16_12(self, offset)\nreplace_16_12(self, value, offset)\nextract_20_1(self, offset)\nreplace_20_1(self, value, offset)\nextract_20_2(self, offset)\nreplace_20_2(self, value, offset)\nextract_20_4(self, offset)\nreplace_20_4(self, value, offset)\nextract_20_6(self, offset)\nreplace_20_6(self, value, offset)\nextract_20_8(self, offset)\nreplace_20_8(self, value, offset)\nextract_20_10(self, offset)\nreplace_20_10(self, value, offset)\nextract_20_12(self, offset)\nreplace_20_12(self, value, offset)\nextract_20_16(self, offset)\nreplace_20_16(self, value, offset)\nextract_22_1(self, offset)\nreplace_22_1(self, value, offset)\nextract_22_2(self, offset)\nreplace_22_2(self, value, offset)\nextract_22_4(self, offset)\nreplace_22_4(self, value, offset)\nextract_22_6(self, offset)\nreplace_22_6(self, value, offset)\nextract_22_8(self, offset)\nreplace_22_8(self, value, offset)\nextract_22_10(self, offset)\nreplace_22_10(self, value, offset)\nextract_22_12(self, offset)\nreplace_22_12(self, value, offset)\nextract_22_16(self, offset)\nreplace_22_16(self, value, offset)\nextract_22_20(self, offset)\nreplace_22_20(self, value, offset)\nextract_24_1(self, offset)\nreplace_24_1(self, value, offset)\nextract_24_2(self, offset)\nreplace_24_2(self, value, offset)\nextract_24_4(self, offset)\nreplace_24_4(self, value, offset)\nextract_24_6(self, offset)\nreplace_24_6(self, value, offset)\nextract_24_8(self, offset)\nreplace_24_8(self, value, offset)\nextract_24_10(self, offset)\nreplace_24_10(self, value, offset)\nextract_24_12(self, offset)\nreplace_24_12(self, value, offset)\nextract_24_16(self, offset)\nreplace_24_16(self, value, offset)\nextract_24_20(self, offset)\nreplace_24_20(self, value, offset)\nextract_24_22(self, offset)\nreplace_24_22(self, value, offset)\nextract_28_1(self, offset)\nreplace_28_1(self, value, offset)\nextract_28_2(self, offset)\nreplace_28_2(self, value, offset)\nextract_28_4(self, offset)\nreplace_28_4(self, value, offset)\nextract_28_6(self, offset)\nreplace_28_6(self, value, offset)\nextract_28_8(self, offset)\nreplace_28_8(self, value, offset)\nextract_28_10(self, offset)\nreplace_28_10(self, value, offset)\nextract_28_12(self, offset)\nreplace_28_12(self, value, offset)\nextract_28_16(self, offset)\nreplace_28_16(self, value, offset)\nextract_28_20(self, offset)\nreplace_28_20(self, value, offset)\nextract_28_22(self, offset)\nreplace_28_22(self, value, offset)\nextract_28_24(self, offset)\nreplace_28_24(self, value, offset)\nextract_32_1(self, offset)\nreplace_32_1(self, value, offset)\nextract_32_2(self, offset)\nreplace_32_2(self, value, offset)\nextract_32_4(self, offset)\nreplace_32_4(self, value, offset)\nextract_32_6(self, offset)\nreplace_32_6(self, value, offset)\nextract_32_8(self, offset)\nreplace_32_8(self, value, offset)\nextract_32_10(self, offset)\nreplace_32_10(self, value, offset)\nextract_32_12(self, offset)\nreplace_32_12(self, value, offset)\nextract_32_16(self, offset)\nreplace_32_16(self, value, offset)\nextract_32_20(self, offset)\nreplace_32_20(self, value, offset)\nextract_32_22(self, offset)\nreplace_32_22(self, value, offset)\nextract_32_24(self, offset)\nreplace_32_24(self, value, offset)\nextract_32_28(self, offset)\nreplace_32_28(self, value, offset)\n\nErrors\nOutOfRangeAccess()\n\npack_1_1(bytes1 left, bytes1 right) → bytes2 resultinternal#\n\npack_2_2(bytes2 left, bytes2 right) → bytes4 resultinternal#\n\npack_2_4(bytes2 left, bytes4 right) → bytes6 resultinternal#\n\npack_2_6(bytes2 left, bytes6 right) → bytes8 resultinternal#\n\npack_2_8(bytes2 left, bytes8 right) → bytes10 resultinternal#\n\npack_2_10(bytes2 left, bytes10 right) → bytes12 resultinternal#\n\npack_2_20(bytes2 left, bytes20 right) → bytes22 resultinternal#\n\npack_2_22(bytes2 left, bytes22 right) → bytes24 resultinternal#\n\npack_4_2(bytes4 left, bytes2 right) → bytes6 resultinternal#\n\npack_4_4(bytes4 left, bytes4 right) → bytes8 resultinternal#\n\npack_4_6(bytes4 left, bytes6 right) → bytes10 resultinternal#\n\npack_4_8(bytes4 left, bytes8 right) → bytes12 resultinternal#\n\npack_4_12(bytes4 left, bytes12 right) → bytes16 resultinternal#\n\npack_4_16(bytes4 left, bytes16 right) → bytes20 resultinternal#\n\npack_4_20(bytes4 left, bytes20 right) → bytes24 resultinternal#\n\npack_4_24(bytes4 left, bytes24 right) → bytes28 resultinternal#\n\npack_4_28(bytes4 left, bytes28 right) → bytes32 resultinternal#\n\npack_6_2(bytes6 left, bytes2 right) → bytes8 resultinternal#\n\npack_6_4(bytes6 left, bytes4 right) → bytes10 resultinternal#\n\npack_6_6(bytes6 left, bytes6 right) → bytes12 resultinternal#\n\npack_6_10(bytes6 left, bytes10 right) → bytes16 resultinternal#\n\npack_6_16(bytes6 left, bytes16 right) → bytes22 resultinternal#\n\npack_6_22(bytes6 left, bytes22 right) → bytes28 resultinternal#\n\npack_8_2(bytes8 left, bytes2 right) → bytes10 resultinternal#\n\npack_8_4(bytes8 left, bytes4 right) → bytes12 resultinternal#\n\npack_8_8(bytes8 left, bytes8 right) → bytes16 resultinternal#\n\npack_8_12(bytes8 left, bytes12 right) → bytes20 resultinternal#\n\npack_8_16(bytes8 left, bytes16 right) → bytes24 resultinternal#\n\npack_8_20(bytes8 left, bytes20 right) → bytes28 resultinternal#\n\npack_8_24(bytes8 left, bytes24 right) → bytes32 resultinternal#\n\npack_10_2(bytes10 left, bytes2 right) → bytes12 resultinternal#\n\npack_10_6(bytes10 left, bytes6 right) → bytes16 resultinternal#\n\npack_10_10(bytes10 left, bytes10 right) → bytes20 resultinternal#\n\npack_10_12(bytes10 left, bytes12 right) → bytes22 resultinternal#\n\npack_10_22(bytes10 left, bytes22 right) → bytes32 resultinternal#\n\npack_12_4(bytes12 left, bytes4 right) → bytes16 resultinternal#\n\npack_12_8(bytes12 left, bytes8 right) → bytes20 resultinternal#\n\npack_12_10(bytes12 left, bytes10 right) → bytes22 resultinternal#\n\npack_12_12(bytes12 left, bytes12 right) → bytes24 resultinternal#\n\npack_12_16(bytes12 left, bytes16 right) → bytes28 resultinternal#\n\npack_12_20(bytes12 left, bytes20 right) → bytes32 resultinternal#\n\npack_16_4(bytes16 left, bytes4 right) → bytes20 resultinternal#\n\npack_16_6(bytes16 left, bytes6 right) → bytes22 resultinternal#\n\npack_16_8(bytes16 left, bytes8 right) → bytes24 resultinternal#\n\npack_16_12(bytes16 left, bytes12 right) → bytes28 resultinternal#\n\npack_16_16(bytes16 left, bytes16 right) → bytes32 resultinternal#\n\npack_20_2(bytes20 left, bytes2 right) → bytes22 resultinternal#\n\npack_20_4(bytes20 left, bytes4 right) → bytes24 resultinternal#\n\npack_20_8(bytes20 left, bytes8 right) → bytes28 resultinternal#\n\npack_20_12(bytes20 left, bytes12 right) → bytes32 resultinternal#\n\npack_22_2(bytes22 left, bytes2 right) → bytes24 resultinternal#\n\npack_22_6(bytes22 left, bytes6 right) → bytes28 resultinternal#\n\npack_22_10(bytes22 left, bytes10 right) → bytes32 resultinternal#\n\npack_24_4(bytes24 left, bytes4 right) → bytes28 resultinternal#\n\npack_24_8(bytes24 left, bytes8 right) → bytes32 resultinternal#\n\npack_28_4(bytes28 left, bytes4 right) → bytes32 resultinternal#\n\nextract_2_1(bytes2 self, uint8 offset) → bytes1 resultinternal#\n\nreplace_2_1(bytes2 self, bytes1 value, uint8 offset) → bytes2 resultinternal#\n\nextract_4_1(bytes4 self, uint8 offset) → bytes1 resultinternal#\n\nreplace_4_1(bytes4 self, bytes1 value, uint8 offset) → bytes4 resultinternal#\n\nextract_4_2(bytes4 self, uint8 offset) → bytes2 resultinternal#\n\nreplace_4_2(bytes4 self, bytes2 value, uint8 offset) → bytes4 resultinternal#\n\nextract_6_1(bytes6 self, uint8 offset) → bytes1 resultinternal#\n\nreplace_6_1(bytes6 self, bytes1 value, uint8 offset) → bytes6 resultinternal#\n\nextract_6_2(bytes6 self, uint8 offset) → bytes2 resultinternal#\n\nreplace_6_2(bytes6 self, bytes2 value, uint8 offset) → bytes6 resultinternal#\n\nextract_6_4(bytes6 self, uint8 offset) → bytes4 resultinternal#\n\nreplace_6_4(bytes6 self, bytes4 value, uint8 offset) → bytes6 resultinternal#\n\nextract_8_1(bytes8 self, uint8 offset) → bytes1 resultinternal#\n\nreplace_8_1(bytes8 self, bytes1 value, uint8 offset) → bytes8 resultinternal#\n\nextract_8_2(bytes8 self, uint8 offset) → bytes2 resultinternal#\n\nreplace_8_2(bytes8 self, bytes2 value, uint8 offset) → bytes8 resultinternal#\n\nextract_8_4(bytes8 self, uint8 offset) → bytes4 resultinternal#\n\nreplace_8_4(bytes8 self, bytes4 value, uint8 offset) → bytes8 resultinternal#\n\nextract_8_6(bytes8 self, uint8 offset) → bytes6 resultinternal#\n\nreplace_8_6(bytes8 self, bytes6 value, uint8 offset) → bytes8 resultinternal#\n\nextract_10_1(bytes10 self, uint8 offset) → bytes1 resultinternal#\n\nreplace_10_1(bytes10 self, bytes1 value, uint8 offset) → bytes10 resultinternal#\n\nextract_10_2(byte","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791266519176,"hash":"c17c113ae4ee3209e7efe82943222d03614db003"}
{"url":"https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988","domain":"governance.aave.com","title":"[ARFC] Technical Asset Listing Framework - Risk / General - Aave","text":"[ARFC] Technical Asset Listing Framework \n\n RiskGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n May 28\n\n 1 / 9\n\n May 29\n\n Jul 17\n\n post by AaveLabs on May 28\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n frxUSD (4)1920×1028 201 KB\nSummary\nAave Labs proposes adopting a standardized Technical Asset Listing Framework for assets seeking listing, continued listing, or material parameter expansion on Aave V3, Aave V4 and Horizon.\nThe objective is to improve the existing asset listing and monitoring process by making the technical requirements for assets listed on Aave more consistent, transparent, and repeatable across governance proposals, while establishing an ongoing monitoring baseline to ensure listed assets continue to meet the protocol’s quality and safety standards over time. The framework is designed to complement existing risk-provider methodologies and the Aave Asset Classification Framework by defining a public baseline for technical safety.\nThe framework defines the technical information and requirements expected from asset issuers and review contributors. Formal technical assessment reports may include qualitative ratings or findings summaries for use by risk providers and governance contributors, but this ARFC does not prescribe rating reference values or define exhaustive blocker conditions.\nMotivation\nAave’s asset listing process has matured significantly over time, with deeper participation from risk providers, technical contributors, and governance stakeholders. As the protocol expands across more markets, asset types, and deployment environments, the technical requirements for listed assets need to remain clear enough for governance participants to evaluate proposals while being rigorous enough to capture the full asset risk surface.\nRelevant requirements include ERC20 compatibility, predictable transfer behavior, bounded minting, robust privileged-role controls, reliable oracle paths, safe bridge topology, audited codebase, and appropriate disclosure of offchain arrangements or components where relevant information is not available onchain.\nThese issues are often technical, but they have direct implications for Aave’s solvency, liquidations, collateral configuration, oracle design, and emergency response. A token with unbounded minting, weak upgrade controls, a stale or unsuitable oracle, bridge supply mismatch risk, an unclear redemption path, or limited transparency due to offchain arrangements can create exposure that is not visible from standard market metrics alone.\nThis ARFC proposes building on the existing process by making technical asset requirements explicit and standardized, so that future asset proposals can be evaluated against the same baseline and so that governance can clearly identify which assets satisfy the standard, which require mitigation, and which require further review or remediation.\nScope\nThe framework applies to:\n\nNew asset listings on any instance of Aave V3, Aave V4 and Horizon.\nExisting listed assets undergoing material changes.\nExisting listed assets subject to periodic or out-of-cycle technical refresh.\n\nThe framework is intended to be deployment-aware. Where an asset exists across multiple chains, the asset is expected to satisfy the applicable requirements on each relevant chain, including per-chain contract implementations, oracle paths, bridge topology, access-control structure, and dependency configuration.\nThe framework does not replace market-risk analysis, liquidity analysis, legal review, or governance discretion. It provides a technical eligibility baseline to be used alongside the work of the DAO’s risk providers and other relevant service providers. Ultimately, onboarding and parameter decisions remain with the DAO, based on the full set of available information, diligence, and recommendations presented through governance. (Liquidity and market-depth analysis is expected to be provided by the DAO’s risk providers as part of their standard market-risk assessment, and findings from that process should be read alongside this framework’s technical conclusions when governance evaluates supply caps, borrow caps, and collateralization parameters.)\nRelationship with AAcA\nEach asset should first be mapped to the relevant group under the Aave Asset Classification Framework. At the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in a non-approved or sanctioned category should not proceed.\nThe AAcA classification determines which requirements require the deepest focus. For example, yield-bearing assets are expected to satisfy dedicated exchange-rate, withdrawal-path, and CAPO requirements, while bridged assets are expected to satisfy dedicated bridge and supply-integrity requirements.\nEvaluation Methodology\nThis framework defines the technical requirements expected from assets seeking listing, continued listing, or material expansion on Aave. It is not intended to publish fixed rating reference values or a complete list of automatic rejection conditions.\nWhen Aave Labs or another contributor prepares a formal technical assessment report, that report may include section-level qualitative ratings, risk labels, or other assessment outputs. Those labels should be treated as report-specific conclusions based on the asset reviewed, the relevant deployment, the available issuer disclosures, and the surrounding market and protocol context.\nThe review should separate factual findings from recommendations. For each section, the reviewer should identify:\n\nthe relevant contracts and systems reviewed;\nthe key finding;\nany required remediation;\nany residual risk that remains after mitigation;\nwhether the finding should constrain listing parameters or exposure caps;\na qualitative rating and assessment conclusion.\n\nThe absence of explicit rating thresholds in this ARFC should not be interpreted as acceptance of every implementation that technically satisfies the information request. Material weaknesses may still lead to reduced exposure, additional monitoring, delayed onboarding, or a recommendation not to proceed until remediation is complete.\nPre-Screening Requirements\nBefore a full technical review proceeds, the asset should satisfy the following pre-screening requirements:\n\nThe asset contract must be deployed and verified on the target chain.\nThe asset’s AAcA group must be confirmed.\nThe asset must not belong to an AAcA non-approved or sanctioned category.\nExisting Aave listings, if any, must be identified and used as parameter references where relevant.\nThe closest comparable asset already listed on Aave must be identified.\nProxy and implementation bytecode must match, or be reconciled against, the latest audited version where applicable.\n\nIf a comparable asset exists, it should be used as the initial reference point for oracle design, LTV, liquidation threshold, caps, and other collateralization parameters, subject to the new asset’s own technical profile.\nStandard Findings Report\nWhere a formal technical assessment report is prepared, it should use a standardized structure so that findings are comparable across assets and deployments. The assessment may include a rating, severity label, recommendation, or other report-specific conclusion. This ARFC does not define the reference values for that assessment. Where a section does not apply, the reviewer should explain why.\nFramework Sections\nThe sections below describe the core technical areas that should generally be covered when evaluating assets for listing, continued listing, or material expansion on Aave. They are not intended to be an exhaustive or final list of requirements. Additional requirements may apply depending on the asset type, implementation design, deployment environment, issuer operations, external dependencies, or new risk considerations identified through governance and service-provider review.\nFor assets with material offchain components, including tokenized real-world assets, custodied instruments, and assets whose redemption or collateralization depends on legal arrangements rather than onchain mechanics, the requirements in this framework apply to the onchain layer. Offchain arrangements that bear on supply integrity, redemption reliability, or counterparty risk should be disclosed and assessed under Section 8 (Dependencies and Composability) and the Issuer Expectations section. Where an offchain component is a critical dependency, it should be treated with the same scrutiny as an onchain dependency.\n1. ERC20 Compliance\nAssets listed on Aave are expected to behave predictably under ERC20 integration assumptions and broader DeFi composability standards.\nTechnical requirements:\n\nname(), symbol(), decimals(), and totalSupply() must return sensible values.\ntransfer() and transferFrom() must return a boolean.\nThe asset must not have fee-on-transfer behavior.\nThe asset must not rebase, unless a non-rebasing wrapper is used instead.\nThe asset must not use ERC777 hooks or ERC1363 transfer callbacks.\nAny flash-mint capability must be documented and shown not to impair Aave accounting.\nSmart contracts must be able to hold and transfer the token without whitelist or address restrictions.\nToken decimals must be compatible with Aave integrations and frontend assumptions.\n\nFee-on-transfer behavior, rebasing behavior without a suitable wrapper, ERC777 hooks, or unsupported decimals that cannot be safely integrated should generally require remediation or a modified listing approach before the asset is considered under the framework.\n2. Oracle\nAave requires a robust oracle path for each listed asset. The oracle path is a core safety dependency, and any feed design that does not use Chainlink as the primary source must be explicitly justified.\nTechnical requirements:\n\nA Chainlink price feed must exist on the target chain and be used directly or through a CAPO adapter where appropriate.\nFeed decimals must follow Aave standards.\nThe price feed must remain within its expected heartbeat and deviation threshold, or any deviation from the expected parameters must be explicitly justified.\nComparable oracle adapters from existing Aave deployments should be identified where applicable.\nThe Chainlink market-risk tier must be reviewed and documented.\n\nFor yield-bearing assets, CAPO must be used where required to limit exchange-rate or price-growth assumptions. Missing or stale oracle infrastructure, materially elevated feed risk, or the absence of an appropriate oracle path should be escalated to risk providers and reflected in onboarding, parameter, or monitoring recommendations.\n3. Asset Operations Access Control\nAssets must have clear access-control and supply-security guarantees across both the ERC20 token and any periphery contracts that can affect token supply, balances, transferability, or redemption. In addition to mapping each privileged role, the review should assess how those roles are assigned across addresses, whether responsibilities are concentrated, and whether the assignment structure creates correlated failure modes.\nEach privileged role should be classified under a standard level model. For the purposes of this framework, a weak security configuration refers to any role holder at Level 0 or Level 1: a single externally owned account with no timelock, or a multisig that does not meet an honest majority threshold. References to “weak security configuration” elsewhere in this framework should be read against this definition.\n\nLevel\nDescription\n\n0\nSingle key or EOA with no delay; no multisig protection\n\n1\nMultisig below honest majority (i.e., fewer than a majority of signers are required to act independently)\n\n2\nMultisig at honest majority (i.e., a majority of signers required), no timelock\n\n3\nMultisig with short timelock below 48 hours\n\n4\nMultisig with timelock of at least 48 hours\n\n5\nOnchain DAO governance with timelock\n\nThe role-holder classification should inform exposure limits, monitoring expectations, and any remediation requested from the issuer. Pause and blacklist authority may require faster operational paths than mint, burn, or upgrade authority, but should still be controlled by robust multisig or timelock structures.\n3a. ERC20 Role Mapping\nIssuers are expected to disclose and document all privileged roles on the ERC20 contract.\nRelevant roles include, where applicable:\n\nowner or admin;\ndefault admin;\nminter;\nburner;\npauser;\nblacklister;\nbridge or adapter roles;\nany other protocol-specific operational role.\n\nFor each role, the issuer is expected to provide the holder address, holder type, security configuration, and the admin hierarchy that can grant or revoke the role. Role concentration must be explicitly assessed.\n3b. Periphery Role Mapping\nPeriphery contracts include any contracts outside the ERC20 token that hold any role of the token, can affect token supply or user balances, or can alter any fundamental function of the token. This may include bridge adapters, minters, treasury controllers, fee receivers, redemption contracts, staking wrappers, and other privileged modules.\nIssuers are expected to identify all relevant periphery contracts, verify source code, disclose their own admin controls, and confirm that they are not upgradeable under weaker controls than the token itself.\n3c. Minting and Burning Logic\nAssets must provide strong supply-integrity guarantees. Issuers are expected to document who can mint, who can burn, the conditions under which these actions occur, and whether caps or rate limits exist.\nTechnical requirements:\n\nExact mint and burn functions must be identified.\nAuthorized callers must be documented.\nMinting must be subject to hard caps or per-period limits.\nThe address that raises or removes caps must be separate from the address that consumes the cap.\nWorst-case mint exposure must be estimated in USD and compared against Aave’s potential collateral exposure.\nBurning must not be possible against arbitrary user wallets by a privileged address.\nMint and burn events must be emitted for supply observability.\n\nMinting controlled by an address with a weak security configuration, especially where minting is unbounded or subject only to very loose limits, a single address that can both raise and consume mint limits, or arbitrary burning from user wallets should generally require remediation or materially constrain onboarding and exposure recommendations.\n3d. Pause and Blacklist Capability\nPause and blacklist controls must be documented because they can directly affect Aave liquidations and user withdrawals.\nTechnical requirements:\n\nPause or freeze authority must be identified.\nBlacklist authority, if present, must be identified.\nThe address holding these permissions and its security configuration must be documented.\nBlacklist functionality must not be able to unilaterally prevent Aave liquidations without governance awareness.\n\nPause and blacklist controls may be operationally necessary for some assets, but their effect on Aave must be explicitly understood before onboarding or expansion.\n3e. Upgradeability\nAssets and critical periphery contracts must have a clear and secure upgrade model. Where contracts are upgradeable, the authority controlling the upgrade path must be identified and appropriately constrained.\nTechnical requirements:\n\nProxy type must be identified, including transparent proxy, UUPS, beacon, or immutable deployment.\nProxy admin or upgrade authority must be identified.\nUpgrade authority must not rely on an address with a weak security configuration.\nProxy admin or upgrade authority must be a multisig, timelock, or DAO-controlled address with verified source code and sufficient economic backing.\nTimelock delay must be documented.\nContract history must not contain suspicious or undocumented upgrades.\n\nA weak security configuration upgrade path is not aligned with the expected standard for assets listed on Aave. A multisig without a meaningful timelock may still be acceptable in some cases, but should generally constrain exposure until governance has sufficient confidence in the issuer’s operational setup.\n4. Exchange Rate and Yield Mechanism\nThis section applies to yield-bearing assets, wrappers, LSTs, LRTs, vault tokens, and similar instruments.\nTechnical requirements:\n\nThe exchange-rate function must be identified and documented.\nThe rate must be monotonically non-decreasing under normal conditions, unless negative performance or slashing is part of the asset design.\nThe rate must not be manipulable in a single transaction through donations, flash loans, or accounting shortcuts.\nThe listed token must not rebase.\nSlashing or negative-rebase passthrough must be understood and reflected in parameters.\nThe withdrawal path must be clear and acceptable for liquidations.\nIf required, CAPO growth cap must be set at a defensible value relative to expected yield.\nRate precision and rounding behavior must be documented.\n\nAn exchange rate that can be manipulated in one transaction, a yield-bearing asset without CAPO where CAPO is required, or an asset with no redemption path and insufficient secondary liquidity should generally require remediation or materially constrain onboarding and exposure recommendations.\n5. Token Architecture\nAssets must have a token architecture that is compatible with Aave integrations and does not introduce hidden supply, transfer, or access-control assumptions.\nTechnical requirements:\n\nSupply mechanics must be understood, including fixed cap, inflation schedule, or issuer-controlled supply.\nTransfer restrictions must be documented and compatible with DeFi composability.\nThe token must not rely on tx.origin for access control.\nThe token contract must not allow delegatecalls to arbitrary contracts.\nAll privileged functions must be explicitly documented and access-controlled.\nThere must not be multiple entry points for the same token supply, including duplicate deployments, legacy token addresses, or migration contracts that affect the same supply without clear accounting.\n\n6. Bridge and Cross-Chain Risk\nAssets whose supply integrity depends on bridges must satisfy additional bridge and cross-chain supply requirements.\nTechnical requirements:\n\nThe origin chain and canonical supply must be identified.\nThe target-chain representation must be documented.\nThe bridge or messaging system must be identified.\nVerifier, attestor, oracle, or DVN configuration must be documented.\nRate limits and escrow mechanics must be documented.\nBridge admin and upgrade controls must be identified.\nWeak controls on the origin chain must be assessed as part of the target-chain listing.\n\nBridge review should not be limited to the target chain. If the origin-chain canonical token is upgradeable, mintable, or controlled by weak access controls, that weakness can undermine the full cross-chain supply model regardless of the bridge implementation.\nBridge dependencies with weak security configurations, missing verification, unbounded minting across bridges, or materially weak bridge-admin controls should be escalated and reflected in onboarding, exposure, and monitoring recommendations.\n7. Audit and Security History\nAssets are expected to have a recent and relevant security review history covering the deployed contracts and critical dependencies.\nTechnical requirements:\n\nThe current deployed version must be covered by reputable audit work.\nThere must be no unresolved Critical or High findings.\nAudit date must be recent relative to the latest meaningful code change.\nA bug bounty should exist and be proportionate to expected TVL.\nPast incidents, if any, must be documented with post-mortem and remediation.\nDeployed code must match the last audited version at the relevant commit hash.\nThe issuer must have a communication channel and commit to pre-notifying Aave teams of material changes.\n\nNo audit, unresolved Critical or High audit findings, or a past exploit without documented remediation should generally require remediation or materially constrain onboarding and exposure recommendations.\n8. Dependencies and Composability\nExternal dependencies must be documented because they can impair the listed asset even if the token contract itself is sound.\nRelevant dependencies include staking protocols, vaults, bridges, custodians, oracle systems, validator operators, restaking layers, and redemption infrastructure.\nTechnical requirements:\n\nAll external dependencies must be identified.\nEach dependency must have its own audit and production history.\nDependency governance must not be able to unilaterally impair the asset without onchain visibility.\nWithdrawal queues and timing must be compatible with liquidation assumptions.\nValidator, operator, or custodian concentration must be documented.\nSlashing or insolvency scenarios must be quantified where applicable.\n\nA critical dependency with weak admin security configuration or no audit should generally require remediation or materially constrain onboarding and exposure recommendations.\nIssuer Expectations\nThis framework addresses the technical dimensions of asset eligibility. We would expect this framework to be extended into a complimentary non-technical asset listing framework that will address issuer-facing expectations beyond the on-chain and smart contract layer, including legal structure, entity disclosure, regulatory status, operational practices, the legal treatment of property interests in the underlying asset, and other factors relevant to governance’s assessment of an issuer’s suitability for listing. Issuers should expect to meet both technical and operational requirements, as offchain structure and operations can directly affect onchain risk.\nWhere reasonable confidentiality concerns exist, disclosures can be made privately to the relevant risk provider or service provider rather than published in full. However, the public governance post should still summarize the finding, the rating, and the residual risk in a way that allows the DAO to make an informed decision.\nGovernance Process Integration\nThis framework should be incorporated into the asset onboarding and expansion process as follows:\n\nPre-screening: confirm AACF classification, contract verification, comparable Aave listings, and basic eligibility.\nTechnical review: assess the asset against the framework sections and identify any material technical concerns.\nRisk-provider coordination: align technical findings with market-risk parameters, caps, oracle configuration, and listing conditions.\nGovernance publication: include the standardized findings table in the relevant governance proposal.\nRemediation tracking: document any required issuer remediation and whether it is a precondition to listing or a post-listing commitment.\nOngoing refresh: assessments should be refreshed annually for all actively listed assets, and immediately when a material change occurs. Material changes include contract upgrades, new chain deployments, new or modified bridge routes, changes to privileged role holders or security configuration, mint-cap modifications, dependency changes, and security incidents affecting the asset or a critical dependency. Service providers and Aave Labs should flag these to the DAO as they become aware. Issuers must provide advance notice under their ongoing obligations.\n\nThe framework should not create unnecessary friction for straightforward assets with strong controls and simple architecture. Its purpose is to make the requirements more predictable and to ensure that technical issues are surfaced before they become protocol exposure.\nTreatment of Findings\nFindings should be translated into clear governance and risk-management consequences. Depending on the issue, this may include lower supply caps, lower borrow caps, reduced LTV, no collateral usage, additional monitoring, issuer remediation, periodic refresh requirements, or a recommendation to defer onboarding or expansion.\nFormal technical assessment reports may use qualitative ratings or severity labels to communicate conclusions to risk providers and governance contributors. Those labels are applied within the context of the specific report and should not be read as fixed reference values defined by this ARFC.\nWhere governance elects to proceed despite material unresolved findings, the proposal should clearly state the residual risk and the rationale for accepting it.\n\n [ARFC] Aave Risk Framework\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\n\n Coinbase Wrapped BTC (cbBTC) on Aave Monad Assessments\n\n [ARFC] Onboard stcUSD to Aave V3 MegaETH\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n post by MconnectDAO on May 28\n\n MconnectDAO\n\n MconnectDAO\n\n Which explicit and quantifiable methodology does the current Technical Asset Listing Framework use to capture not only asset level risk but also the cross protocol dependencies, composability risk and potential cascading liquidations associated with a listed asset; and if no such methodology is documented, is it appropriate to describe this as a technical risk framework..?\n\n post by 50xMonarch on May 29\n\n 50xMonarch\n\nthis feels like it would make it easy for new assets to inherit older assets’ flawed parameters.\nthe rseth situation has shown that listed assets’ parameters are not necessarily trustworthy and/or kept up to date. had there been up to date changes in deposit caps, the situation could have been far less costly. do we really want to be in a situation where we could have just copied the rseth parameters to a new listing?\n\n AL Development Update | May 2026\n\n post by 1pete on Jun 2\n\n 1pete\n\n Hello, I am wondering how this new framework will work with ARFCs that are already midway through Aave’s old framework?\nThese three proposals have already passed the first Temp Check Snapshot vote and have published reviews and recommended parameters from both LlamaRisk and Chaos Labs, but were stuck awaiting a BGD review before they were able to proceed to ARFC Snapshot:\nwOETH: [ARFC] Add support for Wrapped OETH (wOETH) to Aave v3\nwsuperOETH: [ARFC] Add support for Wrapped Super OETH (wsuperOETHb) to Aave v3\nwOS: [ARFC] Add support for Wrapped Origin Sonic (wOS) to Aave v3\nIt appears that the recent stcUSD ARFC on Aave V3 MegaETH is able to move to ARFC Snapshot with just LlamaRisk’s technical assessment, and no BGD-equivalent reviewer. The 3 proposals above have reviews from both LlamaRisk and Chaos Labs with recommended parameters, and were filed long before this new framework was posted. If that is the bar for new listings, these three should clear it too. Can the framework authors clarify the intended path for in-flight proposals?\n\n About the Assessments category\n\n 1 month later\n\n Pinned on Jul 5\n\n post by AaveLabs on Jul 8\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Building on the Technical Asset Listing Framework above, we want to share additional detail on its Bridge and Cross-Chain Risk section. The aim is to evaluate the bridge configuration on every route, meaning any connection between two networks, whether incoming, outgoing, or both, by which it can reach an Aave deployment, independent of any single bridge design.\nThe methodology evaluates each route against a common set of criteria. Without going into the specifics of any particular design, the criteria cover:\n\nVerification thresholds and trusted verifiers. The set of verifiers that must attest to a message, on both the sending and the receiving leg of every route, and the quorum that would be required to forge one. Routes that resolve to a single effective verifier, or to confirmation depths too shallow to resist chain reorganizations, are below bar.\n\nVerifier count and independence. Beyond the threshold, the number of verifiers and their operational independence, and whether a single verifier set applies to every asset and route or can be configured separately. Verifiers operated by the same entity, or co-located on shared infrastructure, collapse to a single effective verifier regardless of the nominal count.\n\nNon-default, non-unilateral configuration. Whether the security configuration a route relies on, such as the pinned libraries, the verifier set, and the confirmation thresholds, is explicitly set rather than inherited from a mutable default, and who can change it, be it the asset issuer, the bridge operator, or a third party, and whether they can do so without the asset issuer’s consent.\n\nGoverned bridge ownership and admin authority. Whether the owner or admin that controls the bridge and each route’s configuration is a governance contract or a multisig, with a sufficient signing threshold and a timelock for critical changes (24 hours acceptable, 48 hours preferred), rather than a single externally owned account (EOA).\n\nScoped secondary roles. Any delegate or secondary manager that can alter configuration, rate limits, or the verifier quorum is held to the same governance and timelock standard, with a clearly bounded scope.\n\nGoverned upgrade control. Where bridge contracts are upgradeable, the upgrade authority is governed and timelocked on the same basis, so the underlying logic cannot be replaced without warning.\n\nConformant code. Deployments use the audited, canonical version of the bridge code, keep any custom variants minimal, and have all relevant contracts verified on public explorers.\n\nSupply integrity and rate limiting. Mint and burn flows are correct and subject to rate limits, and, for designs that lock collateral on an origin chain to back a representation minted elsewhere (a lockbox model), the locked balance covers the sum of representations across all destinations plus transfers in flight at all times. A shortfall against that invariant signals that more has been minted than is locked, or a drain.\n\nIn practice, the outcome of this bridge assessment feeds the rating of the cross-chain section in our published asset technical assessments, so an asset’s cross-chain posture is reflected transparently alongside the rest of its technical profile.\nThis technical baseline is designed to sit beneath the broader, layered standards that LlamaRisk has put forward in the Aave Risk Framework, providing the repeatable cross-chain review that complements its asset, monitoring, and chain risk layers. We look forward to coordinating with LlamaRisk, asset issuers, and the wider community as both frameworks move toward adoption.\n\n post by AaveLabs on Jul 9\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The ARFC to formalize the Technical Asset Listing Framework has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here\n\n post by Abel189 on Jul 11\n\n Abel189\n\n I support the introduction of a standardized Technical Asset Listing Framework. As Aave continues to expand across multiple chains and increasingly diverse asset types, having a common technical baseline will improve the quality, consistency, and transparency of governance decisions.\nI particularly appreciate that this framework complements, rather than replaces, existing risk assessments. Separating technical eligibility from market risk while maintaining cooperation between technical reviewers, risk providers, and governance should result in more structured and well-informed listing decisions.\nThe emphasis on continuous monitoring, deployment-specific reviews, oracle quality, bridge security, and privileged access controls reflects the evolving complexity of modern DeFi infrastructure. Going forward, the framework should continue to evolve alongside new token standards, cross-chain architectures, and emerging asset classes to ensure that Aave maintains high technical and security standards over time.\n\n post by 1pete on Jul 17\n\n 1pete\n\n @AaveLabs it would be great to get clarity on the questions I asked in my comment regarding proposals that are already halfway through the governance process while this ARFC proposal is still in the ARFC stage\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave Risk Framework\n\n Risk\n\n 9\n\n 2.7k\n\n Jul 31\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n MetaMask USD (mUSD) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 159\n\n Jul 1\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d\n\n Agora USD (AUSD) on Aave Monad Assessments\n\n Assessments\n\n 2\n\n 279\n\n Jul 1","tokens":8120,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266526053,"hash":"2b9ba78d33195fdd09c93cb4fae381f80e9a972a"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/subgraphs","domain":"docs.openzeppelin.com","title":"Subgraphs | OpenZeppelin Docs","text":"OpenZeppelin ContractsSubgraphsOpen in ClaudeModules for easily indexing OpenZeppelin Contracts activity.\nInstall from npm as @openzeppelin/subgraphs.\nBrowse on GitHub at OpenZeppelin/openzeppelin-subgraphs.\nUsage\nSubgraph are described using three components:\n\nThe graphql schema, usually named schema.graphql, which describes the database entities and links.\nThe subgraph manifest, usually named subgraph.yaml, which describes the activity that should be listened to (addresses of contracts, events handlers, function handlers).\nThe indexing logic, written in assembly script, which will process the blockchain activity and update the database accordingly.\n\nOpenZeppelin Subgraphs provide schemas description, with the corresponding indexing logic and templates for building your subgraph manifest.\nSimilarly to how OpenZeppelin Contracts provide solidity code containing sets of features that one can assemble to ease building an application, OpenZeppelin subgraphs provides modules dedicated to indexing the activity corresponding to these features. These modules can be composed to index complex onchain activity without the need to actually write the indexing logic for most of the features.\nBuilding your manifest\nYou can build a manifest for your application using the templates provided for each module. These templates are available in src/datasource/<module-name>.yaml. For each datasource, you will have to fill in the name, network, address, and startBlock of your contract. If a contract implements multiple modules, you will want to have multiple datasources listenning to the same address (one per module).\nNote: For the indexing logic to work you will have, for each module used, to name one of your datasources with the name of the module.\nThe @amxx/graphprotocol-utils provides tooling to automate the generation of manifests.\nAssembling your schema\nDepending on the modules you are using, your schema will have to include the corresponding entities. Assembling a schema can be difficult since graphql schema do not natively support import and merging operations. We do provide precompiled schemas for each module in generated/<module-name>.schema.graphql. We also provide a schema that includes all the entities for all the modules in generated/all.schema.graphql.\nSimilar to the manifest, @amxx/graphprotocol-utils provides tooling to automate the generation of schemas.\nModules\nModule nameAvailabilityerc20✔erc20votesPlannederc721✔erc777Plannederc1155✔erc1967upgrade✔ownable✔accesscontrol✔pausable✔timelock✔governor✔\nUsage example\nBy combining multiple modules and datasources in your subgraph, you can build query such as the following one, which\ncheck the details of an ERC20 token with AccessControl on top of it, and returns the balance of the administrators.\n{\n erc20Contract(id: \"<erc20-with-accesscontrol-address-in-lowercase>\") {\n name\n symbol\n decimals\n totalSupply { value }\n asAccount {\n asAccessControl {\n admins: roles(where: { role: \"0x0000000000000000000000000000000000000000000000000000000000000000\" }) {\n members {\n account {\n address: id\n balance: ERC20balances(where: { contract: \"<erc20-with-accesscontrol-address-in-lowercase>\" }) {\n value\n }\n }\n }\n }\n }\n }\n }\n}UtilitiesPrevious PageAutomatic GenerationNext PageOn this pageUsageBuilding your manifestAssembling your schemaModulesUsage example","tokens":834,"squid":"ink-security_audits","role":"Sentinel","at":1791266529273,"hash":"91973c89e601e238cf2f0951d160f22a17142e66"}
{"url":"https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988/10","domain":"governance.aave.com","title":"[ARFC] Technical Asset Listing Framework - Risk / General - Aave","text":"RiskGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n May 28\n\n 9 / 9\n\n Jul 18\n\n Jul 17\n\n post by AaveLabs on May 28\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n frxUSD (4)1920×1028 201 KB\nSummary\nAave Labs proposes adopting a standardized Technical Asset Listing Framework for assets seeking listing, continued listing, or material parameter expansion on Aave V3, Aave V4 and Horizon.\nThe objective is to improve the existing asset listing and monitoring process by making the technical requirements for assets listed on Aave more consistent, transparent, and repeatable across governance proposals, while establishing an ongoing monitoring baseline to ensure listed assets continue to meet the protocol’s quality and safety standards over time. The framework is designed to complement existing risk-provider methodologies and the Aave Asset Classification Framework by defining a public baseline for technical safety.\nThe framework defines the technical information and requirements expected from asset issuers and review contributors. Formal technical assessment reports may include qualitative ratings or findings summaries for use by risk providers and governance contributors, but this ARFC does not prescribe rating reference values or define exhaustive blocker conditions.\nMotivation\nAave’s asset listing process has matured significantly over time, with deeper participation from risk providers, technical contributors, and governance stakeholders. As the protocol expands across more markets, asset types, and deployment environments, the technical requirements for listed assets need to remain clear enough for governance participants to evaluate proposals while being rigorous enough to capture the full asset risk surface.\nRelevant requirements include ERC20 compatibility, predictable transfer behavior, bounded minting, robust privileged-role controls, reliable oracle paths, safe bridge topology, audited codebase, and appropriate disclosure of offchain arrangements or components where relevant information is not available onchain.\nThese issues are often technical, but they have direct implications for Aave’s solvency, liquidations, collateral configuration, oracle design, and emergency response. A token with unbounded minting, weak upgrade controls, a stale or unsuitable oracle, bridge supply mismatch risk, an unclear redemption path, or limited transparency due to offchain arrangements can create exposure that is not visible from standard market metrics alone.\nThis ARFC proposes building on the existing process by making technical asset requirements explicit and standardized, so that future asset proposals can be evaluated against the same baseline and so that governance can clearly identify which assets satisfy the standard, which require mitigation, and which require further review or remediation.\nScope\nThe framework applies to:\n\nNew asset listings on any instance of Aave V3, Aave V4 and Horizon.\nExisting listed assets undergoing material changes.\nExisting listed assets subject to periodic or out-of-cycle technical refresh.\n\nThe framework is intended to be deployment-aware. Where an asset exists across multiple chains, the asset is expected to satisfy the applicable requirements on each relevant chain, including per-chain contract implementations, oracle paths, bridge topology, access-control structure, and dependency configuration.\nThe framework does not replace market-risk analysis, liquidity analysis, legal review, or governance discretion. It provides a technical eligibility baseline to be used alongside the work of the DAO’s risk providers and other relevant service providers. Ultimately, onboarding and parameter decisions remain with the DAO, based on the full set of available information, diligence, and recommendations presented through governance. (Liquidity and market-depth analysis is expected to be provided by the DAO’s risk providers as part of their standard market-risk assessment, and findings from that process should be read alongside this framework’s technical conclusions when governance evaluates supply caps, borrow caps, and collateralization parameters.)\nRelationship with AAcA\nEach asset should first be mapped to the relevant group under the Aave Asset Classification Framework. At the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in a non-approved or sanctioned category should not proceed.\nThe AAcA classification determines which requirements require the deepest focus. For example, yield-bearing assets are expected to satisfy dedicated exchange-rate, withdrawal-path, and CAPO requirements, while bridged assets are expected to satisfy dedicated bridge and supply-integrity requirements.\nEvaluation Methodology\nThis framework defines the technical requirements expected from assets seeking listing, continued listing, or material expansion on Aave. It is not intended to publish fixed rating reference values or a complete list of automatic rejection conditions.\nWhen Aave Labs or another contributor prepares a formal technical assessment report, that report may include section-level qualitative ratings, risk labels, or other assessment outputs. Those labels should be treated as report-specific conclusions based on the asset reviewed, the relevant deployment, the available issuer disclosures, and the surrounding market and protocol context.\nThe review should separate factual findings from recommendations. For each section, the reviewer should identify:\n\nthe relevant contracts and systems reviewed;\nthe key finding;\nany required remediation;\nany residual risk that remains after mitigation;\nwhether the finding should constrain listing parameters or exposure caps;\na qualitative rating and assessment conclusion.\n\nThe absence of explicit rating thresholds in this ARFC should not be interpreted as acceptance of every implementation that technically satisfies the information request. Material weaknesses may still lead to reduced exposure, additional monitoring, delayed onboarding, or a recommendation not to proceed until remediation is complete.\nPre-Screening Requirements\nBefore a full technical review proceeds, the asset should satisfy the following pre-screening requirements:\n\nThe asset contract must be deployed and verified on the target chain.\nThe asset’s AAcA group must be confirmed.\nThe asset must not belong to an AAcA non-approved or sanctioned category.\nExisting Aave listings, if any, must be identified and used as parameter references where relevant.\nThe closest comparable asset already listed on Aave must be identified.\nProxy and implementation bytecode must match, or be reconciled against, the latest audited version where applicable.\n\nIf a comparable asset exists, it should be used as the initial reference point for oracle design, LTV, liquidation threshold, caps, and other collateralization parameters, subject to the new asset’s own technical profile.\nStandard Findings Report\nWhere a formal technical assessment report is prepared, it should use a standardized structure so that findings are comparable across assets and deployments. The assessment may include a rating, severity label, recommendation, or other report-specific conclusion. This ARFC does not define the reference values for that assessment. Where a section does not apply, the reviewer should explain why.\nFramework Sections\nThe sections below describe the core technical areas that should generally be covered when evaluating assets for listing, continued listing, or material expansion on Aave. They are not intended to be an exhaustive or final list of requirements. Additional requirements may apply depending on the asset type, implementation design, deployment environment, issuer operations, external dependencies, or new risk considerations identified through governance and service-provider review.\nFor assets with material offchain components, including tokenized real-world assets, custodied instruments, and assets whose redemption or collateralization depends on legal arrangements rather than onchain mechanics, the requirements in this framework apply to the onchain layer. Offchain arrangements that bear on supply integrity, redemption reliability, or counterparty risk should be disclosed and assessed under Section 8 (Dependencies and Composability) and the Issuer Expectations section. Where an offchain component is a critical dependency, it should be treated with the same scrutiny as an onchain dependency.\n1. ERC20 Compliance\nAssets listed on Aave are expected to behave predictably under ERC20 integration assumptions and broader DeFi composability standards.\nTechnical requirements:\n\nname(), symbol(), decimals(), and totalSupply() must return sensible values.\ntransfer() and transferFrom() must return a boolean.\nThe asset must not have fee-on-transfer behavior.\nThe asset must not rebase, unless a non-rebasing wrapper is used instead.\nThe asset must not use ERC777 hooks or ERC1363 transfer callbacks.\nAny flash-mint capability must be documented and shown not to impair Aave accounting.\nSmart contracts must be able to hold and transfer the token without whitelist or address restrictions.\nToken decimals must be compatible with Aave integrations and frontend assumptions.\n\nFee-on-transfer behavior, rebasing behavior without a suitable wrapper, ERC777 hooks, or unsupported decimals that cannot be safely integrated should generally require remediation or a modified listing approach before the asset is considered under the framework.\n2. Oracle\nAave requires a robust oracle path for each listed asset. The oracle path is a core safety dependency, and any feed design that does not use Chainlink as the primary source must be explicitly justified.\nTechnical requirements:\n\nA Chainlink price feed must exist on the target chain and be used directly or through a CAPO adapter where appropriate.\nFeed decimals must follow Aave standards.\nThe price feed must remain within its expected heartbeat and deviation threshold, or any deviation from the expected parameters must be explicitly justified.\nComparable oracle adapters from existing Aave deployments should be identified where applicable.\nThe Chainlink market-risk tier must be reviewed and documented.\n\nFor yield-bearing assets, CAPO must be used where required to limit exchange-rate or price-growth assumptions. Missing or stale oracle infrastructure, materially elevated feed risk, or the absence of an appropriate oracle path should be escalated to risk providers and reflected in onboarding, parameter, or monitoring recommendations.\n3. Asset Operations Access Control\nAssets must have clear access-control and supply-security guarantees across both the ERC20 token and any periphery contracts that can affect token supply, balances, transferability, or redemption. In addition to mapping each privileged role, the review should assess how those roles are assigned across addresses, whether responsibilities are concentrated, and whether the assignment structure creates correlated failure modes.\nEach privileged role should be classified under a standard level model. For the purposes of this framework, a weak security configuration refers to any role holder at Level 0 or Level 1: a single externally owned account with no timelock, or a multisig that does not meet an honest majority threshold. References to “weak security configuration” elsewhere in this framework should be read against this definition.\n\nLevel\nDescription\n\n0\nSingle key or EOA with no delay; no multisig protection\n\n1\nMultisig below honest majority (i.e., fewer than a majority of signers are required to act independently)\n\n2\nMultisig at honest majority (i.e., a majority of signers required), no timelock\n\n3\nMultisig with short timelock below 48 hours\n\n4\nMultisig with timelock of at least 48 hours\n\n5\nOnchain DAO governance with timelock\n\nThe role-holder classification should inform exposure limits, monitoring expectations, and any remediation requested from the issuer. Pause and blacklist authority may require faster operational paths than mint, burn, or upgrade authority, but should still be controlled by robust multisig or timelock structures.\n3a. ERC20 Role Mapping\nIssuers are expected to disclose and document all privileged roles on the ERC20 contract.\nRelevant roles include, where applicable:\n\nowner or admin;\ndefault admin;\nminter;\nburner;\npauser;\nblacklister;\nbridge or adapter roles;\nany other protocol-specific operational role.\n\nFor each role, the issuer is expected to provide the holder address, holder type, security configuration, and the admin hierarchy that can grant or revoke the role. Role concentration must be explicitly assessed.\n3b. Periphery Role Mapping\nPeriphery contracts include any contracts outside the ERC20 token that hold any role of the token, can affect token supply or user balances, or can alter any fundamental function of the token. This may include bridge adapters, minters, treasury controllers, fee receivers, redemption contracts, staking wrappers, and other privileged modules.\nIssuers are expected to identify all relevant periphery contracts, verify source code, disclose their own admin controls, and confirm that they are not upgradeable under weaker controls than the token itself.\n3c. Minting and Burning Logic\nAssets must provide strong supply-integrity guarantees. Issuers are expected to document who can mint, who can burn, the conditions under which these actions occur, and whether caps or rate limits exist.\nTechnical requirements:\n\nExact mint and burn functions must be identified.\nAuthorized callers must be documented.\nMinting must be subject to hard caps or per-period limits.\nThe address that raises or removes caps must be separate from the address that consumes the cap.\nWorst-case mint exposure must be estimated in USD and compared against Aave’s potential collateral exposure.\nBurning must not be possible against arbitrary user wallets by a privileged address.\nMint and burn events must be emitted for supply observability.\n\nMinting controlled by an address with a weak security configuration, especially where minting is unbounded or subject only to very loose limits, a single address that can both raise and consume mint limits, or arbitrary burning from user wallets should generally require remediation or materially constrain onboarding and exposure recommendations.\n3d. Pause and Blacklist Capability\nPause and blacklist controls must be documented because they can directly affect Aave liquidations and user withdrawals.\nTechnical requirements:\n\nPause or freeze authority must be identified.\nBlacklist authority, if present, must be identified.\nThe address holding these permissions and its security configuration must be documented.\nBlacklist functionality must not be able to unilaterally prevent Aave liquidations without governance awareness.\n\nPause and blacklist controls may be operationally necessary for some assets, but their effect on Aave must be explicitly understood before onboarding or expansion.\n3e. Upgradeability\nAssets and critical periphery contracts must have a clear and secure upgrade model. Where contracts are upgradeable, the authority controlling the upgrade path must be identified and appropriately constrained.\nTechnical requirements:\n\nProxy type must be identified, including transparent proxy, UUPS, beacon, or immutable deployment.\nProxy admin or upgrade authority must be identified.\nUpgrade authority must not rely on an address with a weak security configuration.\nProxy admin or upgrade authority must be a multisig, timelock, or DAO-controlled address with verified source code and sufficient economic backing.\nTimelock delay must be documented.\nContract history must not contain suspicious or undocumented upgrades.\n\nA weak security configuration upgrade path is not aligned with the expected standard for assets listed on Aave. A multisig without a meaningful timelock may still be acceptable in some cases, but should generally constrain exposure until governance has sufficient confidence in the issuer’s operational setup.\n4. Exchange Rate and Yield Mechanism\nThis section applies to yield-bearing assets, wrappers, LSTs, LRTs, vault tokens, and similar instruments.\nTechnical requirements:\n\nThe exchange-rate function must be identified and documented.\nThe rate must be monotonically non-decreasing under normal conditions, unless negative performance or slashing is part of the asset design.\nThe rate must not be manipulable in a single transaction through donations, flash loans, or accounting shortcuts.\nThe listed token must not rebase.\nSlashing or negative-rebase passthrough must be understood and reflected in parameters.\nThe withdrawal path must be clear and acceptable for liquidations.\nIf required, CAPO growth cap must be set at a defensible value relative to expected yield.\nRate precision and rounding behavior must be documented.\n\nAn exchange rate that can be manipulated in one transaction, a yield-bearing asset without CAPO where CAPO is required, or an asset with no redemption path and insufficient secondary liquidity should generally require remediation or materially constrain onboarding and exposure recommendations.\n5. Token Architecture\nAssets must have a token architecture that is compatible with Aave integrations and does not introduce hidden supply, transfer, or access-control assumptions.\nTechnical requirements:\n\nSupply mechanics must be understood, including fixed cap, inflation schedule, or issuer-controlled supply.\nTransfer restrictions must be documented and compatible with DeFi composability.\nThe token must not rely on tx.origin for access control.\nThe token contract must not allow delegatecalls to arbitrary contracts.\nAll privileged functions must be explicitly documented and access-controlled.\nThere must not be multiple entry points for the same token supply, including duplicate deployments, legacy token addresses, or migration contracts that affect the same supply without clear accounting.\n\n6. Bridge and Cross-Chain Risk\nAssets whose supply integrity depends on bridges must satisfy additional bridge and cross-chain supply requirements.\nTechnical requirements:\n\nThe origin chain and canonical supply must be identified.\nThe target-chain representation must be documented.\nThe bridge or messaging system must be identified.\nVerifier, attestor, oracle, or DVN configuration must be documented.\nRate limits and escrow mechanics must be documented.\nBridge admin and upgrade controls must be identified.\nWeak controls on the origin chain must be assessed as part of the target-chain listing.\n\nBridge review should not be limited to the target chain. If the origin-chain canonical token is upgradeable, mintable, or controlled by weak access controls, that weakness can undermine the full cross-chain supply model regardless of the bridge implementation.\nBridge dependencies with weak security configurations, missing verification, unbounded minting across bridges, or materially weak bridge-admin controls should be escalated and reflected in onboarding, exposure, and monitoring recommendations.\n7. Audit and Security History\nAssets are expected to have a recent and relevant security review history covering the deployed contracts and critical dependencies.\nTechnical requirements:\n\nThe current deployed version must be covered by reputable audit work.\nThere must be no unresolved Critical or High findings.\nAudit date must be recent relative to the latest meaningful code change.\nA bug bounty should exist and be proportionate to expected TVL.\nPast incidents, if any, must be documented with post-mortem and remediation.\nDeployed code must match the last audited version at the relevant commit hash.\nThe issuer must have a communication channel and commit to pre-notifying Aave teams of material changes.\n\nNo audit, unresolved Critical or High audit findings, or a past exploit without documented remediation should generally require remediation or materially constrain onboarding and exposure recommendations.\n8. Dependencies and Composability\nExternal dependencies must be documented because they can impair the listed asset even if the token contract itself is sound.\nRelevant dependencies include staking protocols, vaults, bridges, custodians, oracle systems, validator operators, restaking layers, and redemption infrastructure.\nTechnical requirements:\n\nAll external dependencies must be identified.\nEach dependency must have its own audit and production history.\nDependency governance must not be able to unilaterally impair the asset without onchain visibility.\nWithdrawal queues and timing must be compatible with liquidation assumptions.\nValidator, operator, or custodian concentration must be documented.\nSlashing or insolvency scenarios must be quantified where applicable.\n\nA critical dependency with weak admin security configuration or no audit should generally require remediation or materially constrain onboarding and exposure recommendations.\nIssuer Expectations\nThis framework addresses the technical dimensions of asset eligibility. We would expect this framework to be extended into a complimentary non-technical asset listing framework that will address issuer-facing expectations beyond the on-chain and smart contract layer, including legal structure, entity disclosure, regulatory status, operational practices, the legal treatment of property interests in the underlying asset, and other factors relevant to governance’s assessment of an issuer’s suitability for listing. Issuers should expect to meet both technical and operational requirements, as offchain structure and operations can directly affect onchain risk.\nWhere reasonable confidentiality concerns exist, disclosures can be made privately to the relevant risk provider or service provider rather than published in full. However, the public governance post should still summarize the finding, the rating, and the residual risk in a way that allows the DAO to make an informed decision.\nGovernance Process Integration\nThis framework should be incorporated into the asset onboarding and expansion process as follows:\n\nPre-screening: confirm AACF classification, contract verification, comparable Aave listings, and basic eligibility.\nTechnical review: assess the asset against the framework sections and identify any material technical concerns.\nRisk-provider coordination: align technical findings with market-risk parameters, caps, oracle configuration, and listing conditions.\nGovernance publication: include the standardized findings table in the relevant governance proposal.\nRemediation tracking: document any required issuer remediation and whether it is a precondition to listing or a post-listing commitment.\nOngoing refresh: assessments should be refreshed annually for all actively listed assets, and immediately when a material change occurs. Material changes include contract upgrades, new chain deployments, new or modified bridge routes, changes to privileged role holders or security configuration, mint-cap modifications, dependency changes, and security incidents affecting the asset or a critical dependency. Service providers and Aave Labs should flag these to the DAO as they become aware. Issuers must provide advance notice under their ongoing obligations.\n\nThe framework should not create unnecessary friction for straightforward assets with strong controls and simple architecture. Its purpose is to make the requirements more predictable and to ensure that technical issues are surfaced before they become protocol exposure.\nTreatment of Findings\nFindings should be translated into clear governance and risk-management consequences. Depending on the issue, this may include lower supply caps, lower borrow caps, reduced LTV, no collateral usage, additional monitoring, issuer remediation, periodic refresh requirements, or a recommendation to defer onboarding or expansion.\nFormal technical assessment reports may use qualitative ratings or severity labels to communicate conclusions to risk providers and governance contributors. Those labels are applied within the context of the specific report and should not be read as fixed reference values defined by this ARFC.\nWhere governance elects to proceed despite material unresolved findings, the proposal should clearly state the residual risk and the rationale for accepting it.\n\n [ARFC] Aave Risk Framework\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\n\n Coinbase Wrapped BTC (cbBTC) on Aave Monad Assessments\n\n [ARFC] Onboard stcUSD to Aave V3 MegaETH\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n post by MconnectDAO on May 28\n\n MconnectDAO\n\n MconnectDAO\n\n Which explicit and quantifiable methodology does the current Technical Asset Listing Framework use to capture not only asset level risk but also the cross protocol dependencies, composability risk and potential cascading liquidations associated with a listed asset; and if no such methodology is documented, is it appropriate to describe this as a technical risk framework..?\n\n post by 50xMonarch on May 29\n\n 50xMonarch\n\nthis feels like it would make it easy for new assets to inherit older assets’ flawed parameters.\nthe rseth situation has shown that listed assets’ parameters are not necessarily trustworthy and/or kept up to date. had there been up to date changes in deposit caps, the situation could have been far less costly. do we really want to be in a situation where we could have just copied the rseth parameters to a new listing?\n\n AL Development Update | May 2026\n\n post by 1pete on Jun 2\n\n 1pete\n\n Hello, I am wondering how this new framework will work with ARFCs that are already midway through Aave’s old framework?\nThese three proposals have already passed the first Temp Check Snapshot vote and have published reviews and recommended parameters from both LlamaRisk and Chaos Labs, but were stuck awaiting a BGD review before they were able to proceed to ARFC Snapshot:\nwOETH: [ARFC] Add support for Wrapped OETH (wOETH) to Aave v3\nwsuperOETH: [ARFC] Add support for Wrapped Super OETH (wsuperOETHb) to Aave v3\nwOS: [ARFC] Add support for Wrapped Origin Sonic (wOS) to Aave v3\nIt appears that the recent stcUSD ARFC on Aave V3 MegaETH is able to move to ARFC Snapshot with just LlamaRisk’s technical assessment, and no BGD-equivalent reviewer. The 3 proposals above have reviews from both LlamaRisk and Chaos Labs with recommended parameters, and were filed long before this new framework was posted. If that is the bar for new listings, these three should clear it too. Can the framework authors clarify the intended path for in-flight proposals?\n\n About the Assessments category\n\n 1 month later\n\n Pinned on Jul 5\n\n post by AaveLabs on Jul 8\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Building on the Technical Asset Listing Framework above, we want to share additional detail on its Bridge and Cross-Chain Risk section. The aim is to evaluate the bridge configuration on every route, meaning any connection between two networks, whether incoming, outgoing, or both, by which it can reach an Aave deployment, independent of any single bridge design.\nThe methodology evaluates each route against a common set of criteria. Without going into the specifics of any particular design, the criteria cover:\n\nVerification thresholds and trusted verifiers. The set of verifiers that must attest to a message, on both the sending and the receiving leg of every route, and the quorum that would be required to forge one. Routes that resolve to a single effective verifier, or to confirmation depths too shallow to resist chain reorganizations, are below bar.\n\nVerifier count and independence. Beyond the threshold, the number of verifiers and their operational independence, and whether a single verifier set applies to every asset and route or can be configured separately. Verifiers operated by the same entity, or co-located on shared infrastructure, collapse to a single effective verifier regardless of the nominal count.\n\nNon-default, non-unilateral configuration. Whether the security configuration a route relies on, such as the pinned libraries, the verifier set, and the confirmation thresholds, is explicitly set rather than inherited from a mutable default, and who can change it, be it the asset issuer, the bridge operator, or a third party, and whether they can do so without the asset issuer’s consent.\n\nGoverned bridge ownership and admin authority. Whether the owner or admin that controls the bridge and each route’s configuration is a governance contract or a multisig, with a sufficient signing threshold and a timelock for critical changes (24 hours acceptable, 48 hours preferred), rather than a single externally owned account (EOA).\n\nScoped secondary roles. Any delegate or secondary manager that can alter configuration, rate limits, or the verifier quorum is held to the same governance and timelock standard, with a clearly bounded scope.\n\nGoverned upgrade control. Where bridge contracts are upgradeable, the upgrade authority is governed and timelocked on the same basis, so the underlying logic cannot be replaced without warning.\n\nConformant code. Deployments use the audited, canonical version of the bridge code, keep any custom variants minimal, and have all relevant contracts verified on public explorers.\n\nSupply integrity and rate limiting. Mint and burn flows are correct and subject to rate limits, and, for designs that lock collateral on an origin chain to back a representation minted elsewhere (a lockbox model), the locked balance covers the sum of representations across all destinations plus transfers in flight at all times. A shortfall against that invariant signals that more has been minted than is locked, or a drain.\n\nIn practice, the outcome of this bridge assessment feeds the rating of the cross-chain section in our published asset technical assessments, so an asset’s cross-chain posture is reflected transparently alongside the rest of its technical profile.\nThis technical baseline is designed to sit beneath the broader, layered standards that LlamaRisk has put forward in the Aave Risk Framework, providing the repeatable cross-chain review that complements its asset, monitoring, and chain risk layers. We look forward to coordinating with LlamaRisk, asset issuers, and the wider community as both frameworks move toward adoption.\n\n post by AaveLabs on Jul 9\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The ARFC to formalize the Technical Asset Listing Framework has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here\n\n post by Abel189 on Jul 11\n\n Abel189\n\n I support the introduction of a standardized Technical Asset Listing Framework. As Aave continues to expand across multiple chains and increasingly diverse asset types, having a common technical baseline will improve the quality, consistency, and transparency of governance decisions.\nI particularly appreciate that this framework complements, rather than replaces, existing risk assessments. Separating technical eligibility from market risk while maintaining cooperation between technical reviewers, risk providers, and governance should result in more structured and well-informed listing decisions.\nThe emphasis on continuous monitoring, deployment-specific reviews, oracle quality, bridge security, and privileged access controls reflects the evolving complexity of modern DeFi infrastructure. Going forward, the framework should continue to evolve alongside new token standards, cross-chain architectures, and emerging asset classes to ensure that Aave maintains high technical and security standards over time.\n\n post by 1pete on Jul 17\n\n 1pete\n\n @AaveLabs it would be great to get clarity on the questions I asked in my comment regarding proposals that are already halfway through the governance process while this ARFC proposal is still in the ARFC stage\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave Risk Framework\n\n Risk\n\n 9\n\n 2.7k\n\n Jul 31\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n MetaMask USD (mUSD) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 159\n\n Jul 1\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d\n\n Agora USD (AUSD) on Aave Monad Assessments\n\n Assessments\n\n 2\n\n 279\n\n Jul 1","tokens":8109,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266536387,"hash":"5a0fa98cebf7de4183dc0141c2ea9e416648834c"}
{"url":"https://governance.aave.com/t/arfc-technical-asset-listing-framework/24988/5","domain":"governance.aave.com","title":"[ARFC] Technical Asset Listing Framework - Risk / General - Aave","text":"RiskGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n May 28\n\n 4 / 9\n\n Jun 3\n\n Jul 17\n\n post by AaveLabs on May 28\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n frxUSD (4)1920×1028 201 KB\nSummary\nAave Labs proposes adopting a standardized Technical Asset Listing Framework for assets seeking listing, continued listing, or material parameter expansion on Aave V3, Aave V4 and Horizon.\nThe objective is to improve the existing asset listing and monitoring process by making the technical requirements for assets listed on Aave more consistent, transparent, and repeatable across governance proposals, while establishing an ongoing monitoring baseline to ensure listed assets continue to meet the protocol’s quality and safety standards over time. The framework is designed to complement existing risk-provider methodologies and the Aave Asset Classification Framework by defining a public baseline for technical safety.\nThe framework defines the technical information and requirements expected from asset issuers and review contributors. Formal technical assessment reports may include qualitative ratings or findings summaries for use by risk providers and governance contributors, but this ARFC does not prescribe rating reference values or define exhaustive blocker conditions.\nMotivation\nAave’s asset listing process has matured significantly over time, with deeper participation from risk providers, technical contributors, and governance stakeholders. As the protocol expands across more markets, asset types, and deployment environments, the technical requirements for listed assets need to remain clear enough for governance participants to evaluate proposals while being rigorous enough to capture the full asset risk surface.\nRelevant requirements include ERC20 compatibility, predictable transfer behavior, bounded minting, robust privileged-role controls, reliable oracle paths, safe bridge topology, audited codebase, and appropriate disclosure of offchain arrangements or components where relevant information is not available onchain.\nThese issues are often technical, but they have direct implications for Aave’s solvency, liquidations, collateral configuration, oracle design, and emergency response. A token with unbounded minting, weak upgrade controls, a stale or unsuitable oracle, bridge supply mismatch risk, an unclear redemption path, or limited transparency due to offchain arrangements can create exposure that is not visible from standard market metrics alone.\nThis ARFC proposes building on the existing process by making technical asset requirements explicit and standardized, so that future asset proposals can be evaluated against the same baseline and so that governance can clearly identify which assets satisfy the standard, which require mitigation, and which require further review or remediation.\nScope\nThe framework applies to:\n\nNew asset listings on any instance of Aave V3, Aave V4 and Horizon.\nExisting listed assets undergoing material changes.\nExisting listed assets subject to periodic or out-of-cycle technical refresh.\n\nThe framework is intended to be deployment-aware. Where an asset exists across multiple chains, the asset is expected to satisfy the applicable requirements on each relevant chain, including per-chain contract implementations, oracle paths, bridge topology, access-control structure, and dependency configuration.\nThe framework does not replace market-risk analysis, liquidity analysis, legal review, or governance discretion. It provides a technical eligibility baseline to be used alongside the work of the DAO’s risk providers and other relevant service providers. Ultimately, onboarding and parameter decisions remain with the DAO, based on the full set of available information, diligence, and recommendations presented through governance. (Liquidity and market-depth analysis is expected to be provided by the DAO’s risk providers as part of their standard market-risk assessment, and findings from that process should be read alongside this framework’s technical conclusions when governance evaluates supply caps, borrow caps, and collateralization parameters.)\nRelationship with AAcA\nEach asset should first be mapped to the relevant group under the Aave Asset Classification Framework. At the pre-screening stage, the asset’s AAcA category is expected to be confirmed, and assets in a non-approved or sanctioned category should not proceed.\nThe AAcA classification determines which requirements require the deepest focus. For example, yield-bearing assets are expected to satisfy dedicated exchange-rate, withdrawal-path, and CAPO requirements, while bridged assets are expected to satisfy dedicated bridge and supply-integrity requirements.\nEvaluation Methodology\nThis framework defines the technical requirements expected from assets seeking listing, continued listing, or material expansion on Aave. It is not intended to publish fixed rating reference values or a complete list of automatic rejection conditions.\nWhen Aave Labs or another contributor prepares a formal technical assessment report, that report may include section-level qualitative ratings, risk labels, or other assessment outputs. Those labels should be treated as report-specific conclusions based on the asset reviewed, the relevant deployment, the available issuer disclosures, and the surrounding market and protocol context.\nThe review should separate factual findings from recommendations. For each section, the reviewer should identify:\n\nthe relevant contracts and systems reviewed;\nthe key finding;\nany required remediation;\nany residual risk that remains after mitigation;\nwhether the finding should constrain listing parameters or exposure caps;\na qualitative rating and assessment conclusion.\n\nThe absence of explicit rating thresholds in this ARFC should not be interpreted as acceptance of every implementation that technically satisfies the information request. Material weaknesses may still lead to reduced exposure, additional monitoring, delayed onboarding, or a recommendation not to proceed until remediation is complete.\nPre-Screening Requirements\nBefore a full technical review proceeds, the asset should satisfy the following pre-screening requirements:\n\nThe asset contract must be deployed and verified on the target chain.\nThe asset’s AAcA group must be confirmed.\nThe asset must not belong to an AAcA non-approved or sanctioned category.\nExisting Aave listings, if any, must be identified and used as parameter references where relevant.\nThe closest comparable asset already listed on Aave must be identified.\nProxy and implementation bytecode must match, or be reconciled against, the latest audited version where applicable.\n\nIf a comparable asset exists, it should be used as the initial reference point for oracle design, LTV, liquidation threshold, caps, and other collateralization parameters, subject to the new asset’s own technical profile.\nStandard Findings Report\nWhere a formal technical assessment report is prepared, it should use a standardized structure so that findings are comparable across assets and deployments. The assessment may include a rating, severity label, recommendation, or other report-specific conclusion. This ARFC does not define the reference values for that assessment. Where a section does not apply, the reviewer should explain why.\nFramework Sections\nThe sections below describe the core technical areas that should generally be covered when evaluating assets for listing, continued listing, or material expansion on Aave. They are not intended to be an exhaustive or final list of requirements. Additional requirements may apply depending on the asset type, implementation design, deployment environment, issuer operations, external dependencies, or new risk considerations identified through governance and service-provider review.\nFor assets with material offchain components, including tokenized real-world assets, custodied instruments, and assets whose redemption or collateralization depends on legal arrangements rather than onchain mechanics, the requirements in this framework apply to the onchain layer. Offchain arrangements that bear on supply integrity, redemption reliability, or counterparty risk should be disclosed and assessed under Section 8 (Dependencies and Composability) and the Issuer Expectations section. Where an offchain component is a critical dependency, it should be treated with the same scrutiny as an onchain dependency.\n1. ERC20 Compliance\nAssets listed on Aave are expected to behave predictably under ERC20 integration assumptions and broader DeFi composability standards.\nTechnical requirements:\n\nname(), symbol(), decimals(), and totalSupply() must return sensible values.\ntransfer() and transferFrom() must return a boolean.\nThe asset must not have fee-on-transfer behavior.\nThe asset must not rebase, unless a non-rebasing wrapper is used instead.\nThe asset must not use ERC777 hooks or ERC1363 transfer callbacks.\nAny flash-mint capability must be documented and shown not to impair Aave accounting.\nSmart contracts must be able to hold and transfer the token without whitelist or address restrictions.\nToken decimals must be compatible with Aave integrations and frontend assumptions.\n\nFee-on-transfer behavior, rebasing behavior without a suitable wrapper, ERC777 hooks, or unsupported decimals that cannot be safely integrated should generally require remediation or a modified listing approach before the asset is considered under the framework.\n2. Oracle\nAave requires a robust oracle path for each listed asset. The oracle path is a core safety dependency, and any feed design that does not use Chainlink as the primary source must be explicitly justified.\nTechnical requirements:\n\nA Chainlink price feed must exist on the target chain and be used directly or through a CAPO adapter where appropriate.\nFeed decimals must follow Aave standards.\nThe price feed must remain within its expected heartbeat and deviation threshold, or any deviation from the expected parameters must be explicitly justified.\nComparable oracle adapters from existing Aave deployments should be identified where applicable.\nThe Chainlink market-risk tier must be reviewed and documented.\n\nFor yield-bearing assets, CAPO must be used where required to limit exchange-rate or price-growth assumptions. Missing or stale oracle infrastructure, materially elevated feed risk, or the absence of an appropriate oracle path should be escalated to risk providers and reflected in onboarding, parameter, or monitoring recommendations.\n3. Asset Operations Access Control\nAssets must have clear access-control and supply-security guarantees across both the ERC20 token and any periphery contracts that can affect token supply, balances, transferability, or redemption. In addition to mapping each privileged role, the review should assess how those roles are assigned across addresses, whether responsibilities are concentrated, and whether the assignment structure creates correlated failure modes.\nEach privileged role should be classified under a standard level model. For the purposes of this framework, a weak security configuration refers to any role holder at Level 0 or Level 1: a single externally owned account with no timelock, or a multisig that does not meet an honest majority threshold. References to “weak security configuration” elsewhere in this framework should be read against this definition.\n\nLevel\nDescription\n\n0\nSingle key or EOA with no delay; no multisig protection\n\n1\nMultisig below honest majority (i.e., fewer than a majority of signers are required to act independently)\n\n2\nMultisig at honest majority (i.e., a majority of signers required), no timelock\n\n3\nMultisig with short timelock below 48 hours\n\n4\nMultisig with timelock of at least 48 hours\n\n5\nOnchain DAO governance with timelock\n\nThe role-holder classification should inform exposure limits, monitoring expectations, and any remediation requested from the issuer. Pause and blacklist authority may require faster operational paths than mint, burn, or upgrade authority, but should still be controlled by robust multisig or timelock structures.\n3a. ERC20 Role Mapping\nIssuers are expected to disclose and document all privileged roles on the ERC20 contract.\nRelevant roles include, where applicable:\n\nowner or admin;\ndefault admin;\nminter;\nburner;\npauser;\nblacklister;\nbridge or adapter roles;\nany other protocol-specific operational role.\n\nFor each role, the issuer is expected to provide the holder address, holder type, security configuration, and the admin hierarchy that can grant or revoke the role. Role concentration must be explicitly assessed.\n3b. Periphery Role Mapping\nPeriphery contracts include any contracts outside the ERC20 token that hold any role of the token, can affect token supply or user balances, or can alter any fundamental function of the token. This may include bridge adapters, minters, treasury controllers, fee receivers, redemption contracts, staking wrappers, and other privileged modules.\nIssuers are expected to identify all relevant periphery contracts, verify source code, disclose their own admin controls, and confirm that they are not upgradeable under weaker controls than the token itself.\n3c. Minting and Burning Logic\nAssets must provide strong supply-integrity guarantees. Issuers are expected to document who can mint, who can burn, the conditions under which these actions occur, and whether caps or rate limits exist.\nTechnical requirements:\n\nExact mint and burn functions must be identified.\nAuthorized callers must be documented.\nMinting must be subject to hard caps or per-period limits.\nThe address that raises or removes caps must be separate from the address that consumes the cap.\nWorst-case mint exposure must be estimated in USD and compared against Aave’s potential collateral exposure.\nBurning must not be possible against arbitrary user wallets by a privileged address.\nMint and burn events must be emitted for supply observability.\n\nMinting controlled by an address with a weak security configuration, especially where minting is unbounded or subject only to very loose limits, a single address that can both raise and consume mint limits, or arbitrary burning from user wallets should generally require remediation or materially constrain onboarding and exposure recommendations.\n3d. Pause and Blacklist Capability\nPause and blacklist controls must be documented because they can directly affect Aave liquidations and user withdrawals.\nTechnical requirements:\n\nPause or freeze authority must be identified.\nBlacklist authority, if present, must be identified.\nThe address holding these permissions and its security configuration must be documented.\nBlacklist functionality must not be able to unilaterally prevent Aave liquidations without governance awareness.\n\nPause and blacklist controls may be operationally necessary for some assets, but their effect on Aave must be explicitly understood before onboarding or expansion.\n3e. Upgradeability\nAssets and critical periphery contracts must have a clear and secure upgrade model. Where contracts are upgradeable, the authority controlling the upgrade path must be identified and appropriately constrained.\nTechnical requirements:\n\nProxy type must be identified, including transparent proxy, UUPS, beacon, or immutable deployment.\nProxy admin or upgrade authority must be identified.\nUpgrade authority must not rely on an address with a weak security configuration.\nProxy admin or upgrade authority must be a multisig, timelock, or DAO-controlled address with verified source code and sufficient economic backing.\nTimelock delay must be documented.\nContract history must not contain suspicious or undocumented upgrades.\n\nA weak security configuration upgrade path is not aligned with the expected standard for assets listed on Aave. A multisig without a meaningful timelock may still be acceptable in some cases, but should generally constrain exposure until governance has sufficient confidence in the issuer’s operational setup.\n4. Exchange Rate and Yield Mechanism\nThis section applies to yield-bearing assets, wrappers, LSTs, LRTs, vault tokens, and similar instruments.\nTechnical requirements:\n\nThe exchange-rate function must be identified and documented.\nThe rate must be monotonically non-decreasing under normal conditions, unless negative performance or slashing is part of the asset design.\nThe rate must not be manipulable in a single transaction through donations, flash loans, or accounting shortcuts.\nThe listed token must not rebase.\nSlashing or negative-rebase passthrough must be understood and reflected in parameters.\nThe withdrawal path must be clear and acceptable for liquidations.\nIf required, CAPO growth cap must be set at a defensible value relative to expected yield.\nRate precision and rounding behavior must be documented.\n\nAn exchange rate that can be manipulated in one transaction, a yield-bearing asset without CAPO where CAPO is required, or an asset with no redemption path and insufficient secondary liquidity should generally require remediation or materially constrain onboarding and exposure recommendations.\n5. Token Architecture\nAssets must have a token architecture that is compatible with Aave integrations and does not introduce hidden supply, transfer, or access-control assumptions.\nTechnical requirements:\n\nSupply mechanics must be understood, including fixed cap, inflation schedule, or issuer-controlled supply.\nTransfer restrictions must be documented and compatible with DeFi composability.\nThe token must not rely on tx.origin for access control.\nThe token contract must not allow delegatecalls to arbitrary contracts.\nAll privileged functions must be explicitly documented and access-controlled.\nThere must not be multiple entry points for the same token supply, including duplicate deployments, legacy token addresses, or migration contracts that affect the same supply without clear accounting.\n\n6. Bridge and Cross-Chain Risk\nAssets whose supply integrity depends on bridges must satisfy additional bridge and cross-chain supply requirements.\nTechnical requirements:\n\nThe origin chain and canonical supply must be identified.\nThe target-chain representation must be documented.\nThe bridge or messaging system must be identified.\nVerifier, attestor, oracle, or DVN configuration must be documented.\nRate limits and escrow mechanics must be documented.\nBridge admin and upgrade controls must be identified.\nWeak controls on the origin chain must be assessed as part of the target-chain listing.\n\nBridge review should not be limited to the target chain. If the origin-chain canonical token is upgradeable, mintable, or controlled by weak access controls, that weakness can undermine the full cross-chain supply model regardless of the bridge implementation.\nBridge dependencies with weak security configurations, missing verification, unbounded minting across bridges, or materially weak bridge-admin controls should be escalated and reflected in onboarding, exposure, and monitoring recommendations.\n7. Audit and Security History\nAssets are expected to have a recent and relevant security review history covering the deployed contracts and critical dependencies.\nTechnical requirements:\n\nThe current deployed version must be covered by reputable audit work.\nThere must be no unresolved Critical or High findings.\nAudit date must be recent relative to the latest meaningful code change.\nA bug bounty should exist and be proportionate to expected TVL.\nPast incidents, if any, must be documented with post-mortem and remediation.\nDeployed code must match the last audited version at the relevant commit hash.\nThe issuer must have a communication channel and commit to pre-notifying Aave teams of material changes.\n\nNo audit, unresolved Critical or High audit findings, or a past exploit without documented remediation should generally require remediation or materially constrain onboarding and exposure recommendations.\n8. Dependencies and Composability\nExternal dependencies must be documented because they can impair the listed asset even if the token contract itself is sound.\nRelevant dependencies include staking protocols, vaults, bridges, custodians, oracle systems, validator operators, restaking layers, and redemption infrastructure.\nTechnical requirements:\n\nAll external dependencies must be identified.\nEach dependency must have its own audit and production history.\nDependency governance must not be able to unilaterally impair the asset without onchain visibility.\nWithdrawal queues and timing must be compatible with liquidation assumptions.\nValidator, operator, or custodian concentration must be documented.\nSlashing or insolvency scenarios must be quantified where applicable.\n\nA critical dependency with weak admin security configuration or no audit should generally require remediation or materially constrain onboarding and exposure recommendations.\nIssuer Expectations\nThis framework addresses the technical dimensions of asset eligibility. We would expect this framework to be extended into a complimentary non-technical asset listing framework that will address issuer-facing expectations beyond the on-chain and smart contract layer, including legal structure, entity disclosure, regulatory status, operational practices, the legal treatment of property interests in the underlying asset, and other factors relevant to governance’s assessment of an issuer’s suitability for listing. Issuers should expect to meet both technical and operational requirements, as offchain structure and operations can directly affect onchain risk.\nWhere reasonable confidentiality concerns exist, disclosures can be made privately to the relevant risk provider or service provider rather than published in full. However, the public governance post should still summarize the finding, the rating, and the residual risk in a way that allows the DAO to make an informed decision.\nGovernance Process Integration\nThis framework should be incorporated into the asset onboarding and expansion process as follows:\n\nPre-screening: confirm AACF classification, contract verification, comparable Aave listings, and basic eligibility.\nTechnical review: assess the asset against the framework sections and identify any material technical concerns.\nRisk-provider coordination: align technical findings with market-risk parameters, caps, oracle configuration, and listing conditions.\nGovernance publication: include the standardized findings table in the relevant governance proposal.\nRemediation tracking: document any required issuer remediation and whether it is a precondition to listing or a post-listing commitment.\nOngoing refresh: assessments should be refreshed annually for all actively listed assets, and immediately when a material change occurs. Material changes include contract upgrades, new chain deployments, new or modified bridge routes, changes to privileged role holders or security configuration, mint-cap modifications, dependency changes, and security incidents affecting the asset or a critical dependency. Service providers and Aave Labs should flag these to the DAO as they become aware. Issuers must provide advance notice under their ongoing obligations.\n\nThe framework should not create unnecessary friction for straightforward assets with strong controls and simple architecture. Its purpose is to make the requirements more predictable and to ensure that technical issues are surfaced before they become protocol exposure.\nTreatment of Findings\nFindings should be translated into clear governance and risk-management consequences. Depending on the issue, this may include lower supply caps, lower borrow caps, reduced LTV, no collateral usage, additional monitoring, issuer remediation, periodic refresh requirements, or a recommendation to defer onboarding or expansion.\nFormal technical assessment reports may use qualitative ratings or severity labels to communicate conclusions to risk providers and governance contributors. Those labels are applied within the context of the specific report and should not be read as fixed reference values defined by this ARFC.\nWhere governance elects to proceed despite material unresolved findings, the proposal should clearly state the residual risk and the rationale for accepting it.\n\n [ARFC] Aave Risk Framework\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments\n\n Coinbase Wrapped BTC (cbBTC) on Aave Monad Assessments\n\n [ARFC] Onboard stcUSD to Aave V3 MegaETH\n\n 3\n\n 2\n\n read \n\n 10\n min\n\n post by MconnectDAO on May 28\n\n MconnectDAO\n\n MconnectDAO\n\n Which explicit and quantifiable methodology does the current Technical Asset Listing Framework use to capture not only asset level risk but also the cross protocol dependencies, composability risk and potential cascading liquidations associated with a listed asset; and if no such methodology is documented, is it appropriate to describe this as a technical risk framework..?\n\n post by 50xMonarch on May 29\n\n 50xMonarch\n\nthis feels like it would make it easy for new assets to inherit older assets’ flawed parameters.\nthe rseth situation has shown that listed assets’ parameters are not necessarily trustworthy and/or kept up to date. had there been up to date changes in deposit caps, the situation could have been far less costly. do we really want to be in a situation where we could have just copied the rseth parameters to a new listing?\n\n AL Development Update | May 2026\n\n post by 1pete on Jun 2\n\n 1pete\n\n Hello, I am wondering how this new framework will work with ARFCs that are already midway through Aave’s old framework?\nThese three proposals have already passed the first Temp Check Snapshot vote and have published reviews and recommended parameters from both LlamaRisk and Chaos Labs, but were stuck awaiting a BGD review before they were able to proceed to ARFC Snapshot:\nwOETH: [ARFC] Add support for Wrapped OETH (wOETH) to Aave v3\nwsuperOETH: [ARFC] Add support for Wrapped Super OETH (wsuperOETHb) to Aave v3\nwOS: [ARFC] Add support for Wrapped Origin Sonic (wOS) to Aave v3\nIt appears that the recent stcUSD ARFC on Aave V3 MegaETH is able to move to ARFC Snapshot with just LlamaRisk’s technical assessment, and no BGD-equivalent reviewer. The 3 proposals above have reviews from both LlamaRisk and Chaos Labs with recommended parameters, and were filed long before this new framework was posted. If that is the bar for new listings, these three should clear it too. Can the framework authors clarify the intended path for in-flight proposals?\n\n About the Assessments category\n\n 1 month later\n\n Pinned on Jul 5\n\n post by AaveLabs on Jul 8\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Building on the Technical Asset Listing Framework above, we want to share additional detail on its Bridge and Cross-Chain Risk section. The aim is to evaluate the bridge configuration on every route, meaning any connection between two networks, whether incoming, outgoing, or both, by which it can reach an Aave deployment, independent of any single bridge design.\nThe methodology evaluates each route against a common set of criteria. Without going into the specifics of any particular design, the criteria cover:\n\nVerification thresholds and trusted verifiers. The set of verifiers that must attest to a message, on both the sending and the receiving leg of every route, and the quorum that would be required to forge one. Routes that resolve to a single effective verifier, or to confirmation depths too shallow to resist chain reorganizations, are below bar.\n\nVerifier count and independence. Beyond the threshold, the number of verifiers and their operational independence, and whether a single verifier set applies to every asset and route or can be configured separately. Verifiers operated by the same entity, or co-located on shared infrastructure, collapse to a single effective verifier regardless of the nominal count.\n\nNon-default, non-unilateral configuration. Whether the security configuration a route relies on, such as the pinned libraries, the verifier set, and the confirmation thresholds, is explicitly set rather than inherited from a mutable default, and who can change it, be it the asset issuer, the bridge operator, or a third party, and whether they can do so without the asset issuer’s consent.\n\nGoverned bridge ownership and admin authority. Whether the owner or admin that controls the bridge and each route’s configuration is a governance contract or a multisig, with a sufficient signing threshold and a timelock for critical changes (24 hours acceptable, 48 hours preferred), rather than a single externally owned account (EOA).\n\nScoped secondary roles. Any delegate or secondary manager that can alter configuration, rate limits, or the verifier quorum is held to the same governance and timelock standard, with a clearly bounded scope.\n\nGoverned upgrade control. Where bridge contracts are upgradeable, the upgrade authority is governed and timelocked on the same basis, so the underlying logic cannot be replaced without warning.\n\nConformant code. Deployments use the audited, canonical version of the bridge code, keep any custom variants minimal, and have all relevant contracts verified on public explorers.\n\nSupply integrity and rate limiting. Mint and burn flows are correct and subject to rate limits, and, for designs that lock collateral on an origin chain to back a representation minted elsewhere (a lockbox model), the locked balance covers the sum of representations across all destinations plus transfers in flight at all times. A shortfall against that invariant signals that more has been minted than is locked, or a drain.\n\nIn practice, the outcome of this bridge assessment feeds the rating of the cross-chain section in our published asset technical assessments, so an asset’s cross-chain posture is reflected transparently alongside the rest of its technical profile.\nThis technical baseline is designed to sit beneath the broader, layered standards that LlamaRisk has put forward in the Aave Risk Framework, providing the repeatable cross-chain review that complements its asset, monitoring, and chain risk layers. We look forward to coordinating with LlamaRisk, asset issuers, and the wider community as both frameworks move toward adoption.\n\n post by AaveLabs on Jul 9\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n The ARFC to formalize the Technical Asset Listing Framework has been raised to snapshot. Voting will begin in less than 24 hours. You may vote here\n\n post by Abel189 on Jul 11\n\n Abel189\n\n I support the introduction of a standardized Technical Asset Listing Framework. As Aave continues to expand across multiple chains and increasingly diverse asset types, having a common technical baseline will improve the quality, consistency, and transparency of governance decisions.\nI particularly appreciate that this framework complements, rather than replaces, existing risk assessments. Separating technical eligibility from market risk while maintaining cooperation between technical reviewers, risk providers, and governance should result in more structured and well-informed listing decisions.\nThe emphasis on continuous monitoring, deployment-specific reviews, oracle quality, bridge security, and privileged access controls reflects the evolving complexity of modern DeFi infrastructure. Going forward, the framework should continue to evolve alongside new token standards, cross-chain architectures, and emerging asset classes to ensure that Aave maintains high technical and security standards over time.\n\n post by 1pete on Jul 17\n\n 1pete\n\n @AaveLabs it would be great to get clarity on the questions I asked in my comment regarding proposals that are already halfway through the governance process while this ARFC proposal is still in the ARFC stage\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [ARFC] Aave Risk Framework\n\n Risk\n\n 9\n\n 2.7k\n\n Jul 31\n\n [ARFC] Governance Framework v2\n\n General\n\n 2\n\n 698\n\n Aug 9\n\n MetaMask USD (mUSD) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 159\n\n Jul 1\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n General\n\n 1\n\n 85\n\n 5d\n\n Agora USD (AUSD) on Aave Monad Assessments\n\n Assessments\n\n 2\n\n 279\n\n Jul 1","tokens":8109,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266547068,"hash":"4de49948a48880e236375af32d3c98c522798fe5"}
{"url":"https://docs.base.org/specifications/base-protocol/overview","domain":"docs.base.org","title":"Overview - Base Documentation","text":"Base is a rollup built on Ethereum. L2 transaction data is posted to Ethereum for data availability,\nand proofs allow anyone to challenge invalid state transitions. This page gives a high-level tour of the\nprotocol components and the core user flows.\n​Network Participants\nThere are three primary actors that interact with Base: users, sequencers, and validators.\n\n​Users\nUsers are the general class of network participants who:\n\nSubmit transactions through the sequencer or by interacting with contracts on Ethereum.\nQuery transaction data from interfaces operated by validators.\n\n​Sequencers\nThe sequencer fills the role of block producer on Base. Base currently operates with a single active sequencer.\nThe Sequencer:\n\nAccepts transactions directly from Users.\nObserves “deposit” transactions generated on Ethereum.\nConsolidates both transaction streams into ordered L2 blocks.\nSubmits information to L1 that is sufficient to fully reproduce those L2 blocks.\nProvides real-time access to pending L2 blocks that have not yet been confirmed on L1.\nProduces Flashblocks every 200ms, committing to the ordering of transactions within the block as it is being built.\n\nThe Sequencer serves an important role for the operation of an L2 chain but is not a trusted actor. The Sequencer is generally\nresponsible for improving the user experience by ordering transactions much more quickly and cheaply than would currently\nbe possible if users were to submit all transactions directly to L1.\n​Validators\nValidators execute the L2 state transition function independently of the Sequencer. Validators help to maintain\nthe integrity of the network and serve blockchain data to Users.\nValidators generally:\n\nSync rollup data from L1 and the Sequencer.\nUse rollup data to execute the L2 state transition function.\nServe rollup data and computed L2 state information to Users.\n\nValidators can also act as Proposers and/or Challengers who:\n\nSubmit assertions about the state of the L2 to a smart contract on L1.\nValidate assertions made by other participants.\nDispute invalid assertions made by other participants.\n\n​High-Level System Diagram\nThe following diagram shows how the major protocol components interact across L1 and L2.\n\n​Protocol Components\n​Consensus\nConsensus is responsible for deriving the canonical L2 chain from L1 data. It reads transaction batches\nfrom the Batch Inbox and deposit events from OptimismPortal, constructs payload attributes, and drives the\nexecution engine via the Engine API. Unsafe (unconfirmed) blocks are gossiped to other nodes over a dedicated\nP2P network to give validators low-latency access before batches land on L1.\nConsensus →\n\n​Execution\nThe execution engine is a Reth-based runtime. It exposes the standard Ethereum JSON-RPC API and\nprocesses blocks produced by consensus. Predeploys (system contracts at fixed L2 addresses), precompiles,\nand preinstalls extend the EVM for rollup-specific functionality such as fee distribution, L1 block attribute\ninjection, and cross-domain messaging.\nExecution →\n​Bridging\nDeposits flow from the OptimismPortal contract on L1 into L2 as special deposit transactions included at the\nstart of each L2 block. Withdrawals flow in the opposite direction: a withdrawal transaction is initiated on L2,\na proposer submits an output root to DisputeGameFactory, and after the challenge period the user proves and\nfinalizes the withdrawal on L1 via OptimismPortal.\nBridging →\n\n​Batcher\nThe batcher is a service run by the sequencer that compresses L2 transaction data into channel frames and posts\nthem as calldata (or blobs) to the Batch Inbox Address on L1. This is the data availability layer that allows\nany validator to independently reconstruct the L2 chain from L1.\nBatcher →\n\n​Proofs\nOutput proposals and proofs allow verification of the L2 state. Proposers create checkpoint games\nthrough DisputeGameFactory, proof material is checked by the onchain verifier contracts, and\nchallengers can dispute invalid claims. Valid withdrawals can only be finalized through\nOptimismPortal once the associated game resolves in favor of the proposer.\nProofs →\n\n​Core User Flows\n​Depositing ETH to Base\nUsers will often begin their L2 journey by depositing ETH from L1.\nOnce they have ETH to pay fees, they’ll start sending transactions on L2.\nThe following diagram demonstrates this interaction and key Base protocol components.\n\n​Sending Transactions on Base\nSending transactions on Base works the same as on Ethereum. Users sign transactions and submit them via\neth_sendRawTransaction to any node’s JSON-RPC endpoint. The sequencer picks them up from its mempool,\norders them into L2 blocks, and eventually posts the batch to L1.\n​Withdrawing from Base\nUsers may also want to withdraw ETH or ERC20 tokens from Base back to Ethereum. Withdrawals are initiated\nas standard transactions on L2 but are then completed using transactions on L1. Withdrawals must reference a valid\nproof game contract that proposes the state of the L2 at a given point in time.\nWas this page helpful?Suggest editsRaise issue","tokens":1265,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266552436,"hash":"b7e99cfcfbc6bac2d12fbf028171cfc628b86018"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/49","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 49 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 2, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by vbuterin on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n Load more posts below","tokens":1456,"squid":"ink-research","role":"Deep Scholar","at":1791266559706,"hash":"c8264fa3d53feffd86eb091c88de630e8f1e1c08"}
{"url":"https://docs.base.org/specifications/flashblocks","domain":"docs.base.org","title":"Flashblocks - Base Documentation","text":"We’re planning on deprecating Flashblocks in the upcoming Denim hardfork. This is a planned upgrade that has not yet been finalized. You can now test canonical 200ms block behavior early on Vibenet. See Migrate From Flashblocks for the eventual required application changes.\nFor how Flashblocks affect block building and transaction ordering, see Transaction Ordering.\nFlashblocks introduce 200ms incremental block updates to Base, built in collaboration with Flashbots. They stream sub-blocks within the standard 2-second block interval, giving applications near-instant sequencer preconfirmations.\n​Key Concepts\nTermDefinitionFlashblockA 200ms sub-block containing a portion of the full block’s transactionsPreconfirmationAn ultra-fast signal that a transaction will be included, before the full block is sealedFull BlockA series of 10 Flashblocks combined to form the complete 2-second block\n​Architecture\nBase operates a high-availability sequencer system:\nComponentRolebase-consensusConsensus layer (CL) — replaced op-node after Azulbase-reth-nodeExecution layer (EL) — replaced op-geth after Azulop-conductorHigh-availability controller with Raft consensus for leader election\nOne sequencer instance acts as the leader, building blocks and propagating them via P2P; the others act as followers that sync the chain. Leadership transfers if the current leader stops producing blocks.\nFlashblocks add several infrastructure components on top of this system:\nComponentPurposeWhat it unlocksrollup-boostCL↔EL Engine API proxyShares Flashblocks with the EL without modifying the CL, providing a stable seam for future block-building evolutions (multi-builder, etc.)base-builderOut-of-protocol builder at 200ms cadenceProduces sub-second Flashblocks, decoupled from the EL, enabling pluggable builder mechanismswebsocket-proxyFlashblocks stream fan-outBroadcast layer so many consumers can read the stream without overwhelming the builderbaseRPC surface exposing preconfirmationsConverts streamed Flashblocks into familiar RPCs so apps and wallets can consume preconfirmation state\nrollup-boost is built and maintained by Flashbots, while Base maintains base-builder, the websocket-proxy, and the base components.\n​Block Building\nAre Flashblocks Optional?All Base blocks are built by the Flashblocks builder, meaning Flashblocks are always live. However, apps may choose not to rely on preconfirmations and can continue using standard RPCs without any Flashblocks integration.Is There Any Difference in Transaction Inclusion for Flashblocks vs. 2-second Blocks?No significant differences—both order transactions by fee. The main difference is timing: Flashblocks occur every 200ms instead of every 2 seconds.See Transaction Ordering for details.Can the Sequencer Stop Publishing Flashblocks?The sequencer will not stop publishing Flashblocks unless an extreme circumstance makes running them unsafe. If this happens, preconfirmations are disabled network-wide and confirmations fall back to standard 2-second blocks. The sequencer continues operating normally.Why Is My Transaction Having Trouble Getting Included?Inclusion timing is driven primarily by priority fee, not transaction size. The builder allocates gas cumulatively—each Flashblock j can use up to j/10 of the total block gas limit—so in principle a very large transaction has a harder time landing in the first Flashblock. In practice this rarely matters: Base’s per-transaction gas maximum (16,777,216 gas, ~16.7M) is below Flashblock 1’s ~40M capacity, so any valid transaction fits in the first Flashblock by size alone. If a transaction is slow to include, the usual cause is a low priority fee relative to others competing in the same 200ms window.See Throughput and Limits for gas limits and throughput-related network parameters.How Do I Ensure My Transaction Is in the First Flashblock?There’s no way to guarantee which Flashblock a transaction lands in, similar to how you can’t guarantee a specific block. Gas size isn’t the limiting factor—the per-transaction gas maximum (~16.7M) is below Flashblock 1’s ~40M capacity, so any valid transaction is eligible for the first Flashblock. To improve your chances of quick inclusion, set a higher priority fee.Why Do Transactions Sometimes Appear Out of Order by Fee?The Flashblock builder uses a dynamic mempool that continuously accepts new transactions while building. This design prioritizes low inclusion latency over strict fee ordering.What this means:\nTransactions are ordered by fee at the time they’re selected for inclusion\nIf a high-fee transaction arrives after a lower-fee transaction has already been committed to the current Flashblock, the high-fee transaction will appear after it (or in the next Flashblock)\nThis is expected behavior, not a bug—the builder doesn’t “reorder” already-committed transactions\nWhy this tradeoff?A “snapshot” mempool (freezing the transaction pool at the start of each block) would guarantee strict fee ordering but increase inclusion latency. The dynamic approach gets transactions included faster at the cost of occasionally “breaking” the expected priority gas auction (PGA) order.For traders and bots: If strict fee-based ordering is critical for your use case, be aware that arrival timing matters as much as fee amount within a 200ms Flashblock window.How Frequently Do Flashblock Reorgs Happen?Base targets a Flashblock reorg rate of < 0.1%. While reorgs are rare, applications should implement fallback logic for critical operations.Check current metrics at base.org/stats.What Does It Mean When a Flashblock Is Reorged?A reorg means a Flashblock was streamed as a preconfirmation but wasn’t included in the final block. This is rare due to architectural improvements in rollup-boost that prevent tail Flashblock reorgs. Apps should handle this possibility gracefully, but occurrences are minimal.\n\n​WebSocket\nCan I Connect Directly to the Flashblocks WebSocket Stream?No. The raw Flashblocks WebSocket (wss://mainnet.flashblocks.base.org/ws) is reserved for infrastructure-to-node data syncing. Applications should not connect to it directly.Instead, query your RPC node or node provider (e.g., QuickNode, Alchemy, Infura, dRPC) for Flashblocks data via:\nRPC API: Standard JSON-RPC methods with the pending tag\nWebSocket subscriptions: Use eth_subscribe via your node provider’s WebSocket endpoint\nSee the RPC overview for implementation details.Why Are There 11 Flashblock Indices (0-10)?Index 0 contains only system transactions and doesn’t use any gas limit. Indexes 1-10 are the actual Flashblocks that pull pending transactions from the txpool.Why Are There Sometimes Fewer Than 10 Flashblocks?This is expected. When the previous block takes longer to build, the system compensates by allocating less time to the next block, resulting in fewer Flashblocks.Can the Flashblock Index Exceed 10? Is That a Bug?No, it is not a bug. Seeing indices of 10, 11, or higher is expected behavior.The standard math — 2-second block time ÷ 200ms per Flashblock — gives exactly 10 Flashblocks (indices 0–9). In practice, however, the transition from one full L2 block to the next is not always perfectly synchronized with the 200ms timer. Two things can cause extra indices:\nSequencer delay: If the sequencer takes slightly longer than 2000ms to finalize and seal the full block, the Flashblock stream continues emitting incremental updates for the current block to keep the stream live.\nTiming drift: If the internal 200ms clock drifts or starts early relative to the L2 block’s canonical start time, an extra update can fit within the 2-second window.\nWhat this means for your implementation:\nDo not hardcode 9 or 10 as the final index — the last Flashblock for a given block is not predictable by index alone.\nWatch the payloadId instead. The most reliable signal that a block has finished is when payloadId changes, or when the full block is confirmed via standard RPC. All Flashblocks sharing the same payloadId belong to the same block, regardless of how high the index goes.\nOnce the sequencer advances to the next block, payloadId resets and index returns to 0.\nWhat Encoding Format Is the Transaction Data In?Transaction data in the diff.transactions array is Recursive Length Prefix (RLP) encoded.Why Am I Getting Rate Limited on the WebSocket?Base does not provide a free public WebSocket RPC endpoint, so WebSocket access comes from a node or provider, each with its own connection and rate limits. For production use, we recommend:\nRunning your own Flashblocks-aware RPC node\nUsing a third-party node provider with Flashblocks support\n\n​RPC\nWhy Am I Getting Rate Limited Using mainnet.base.org?The public endpoint has explicit rate limiting. For production use:\nUse a third-party node provider with Flashblocks support (Alchemy, Infura, QuickNode, dRPC)\nRun your own Flashblocks-aware RPC node\nWhy Does eth_call 'Pending' Report a Block Number Several Blocks Behind Tip?This is expected behavior. Flashblocks-aware nodes store up to 5 historical blocks worth of Flashblocks state to prevent race conditions. When eth_call \"pending\" is called, it operates on top of that historical base, so the block number visible in the call context (e.g. block.number) may appear to be N-5.When eth_call \"pending\" executes, the entire block context — block.number, block.timestamp, block.basefee, and all other block properties — corresponds to that historical base block (potentially N-5), not the current chain tip. The call result is correct in that it reflects all received Flashblocks state applied on top, but contracts that rely on block context properties should be aware that those values may be several blocks behind.If you operate a node in a geographic region where your P2P latency is not significantly higher than the WebSocket stream latency, you can reduce this difference by lowering the MAX_PENDING_BLOCKS_DEPTH configuration value. This controls the maximum number of historical blocks worth of Flashblocks your node stores, so a lower value will make the block context closer to tip at the cost of reduced tolerance for P2P latency spikes.What RPC Methods Support Flashblocks?The following methods are Flashblocks-enabled:MethodUsageeth_getBlockByNumberUse pending tageth_getBalanceUse pending tageth_getTransactionReceiptReturns preconfirmed receiptseth_getTransactionByHashUse pending tageth_getTransactionCountUse pending tageth_callUse pending tageth_simulateV1Use pending tageth_estimateGasUse pending tageth_getLogsUse pending for toBlocketh_subscribeStream Flashblock data in real-timebase_transactionStatusCheck if transaction is in mempool (Beta)See the Flashblocks API Reference for full method details and examples.\n\n​Node Setup\nHow Do I Set Up a Flashblocks-Aware RPC Node?Use the Reth binary from the Base Reth repository. See the Enable Flashblocks guide for complete setup instructions.\n\n​Further Reading\n\nEnable Flashblocks — run your own Flashblocks-aware RPC node\nFlashblocks API Reference — RPC methods, WebSocket subscriptions, and infrastructure stream schema\nFlashblocks Deep Dive — engineering blog post with implementation details, built in collaboration with Flashbots\nWas this page helpful?Suggest editsRaise issue","tokens":2806,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266563330,"hash":"ee245fff0b9d65ac4182def72b62e9cc2409973e"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/52","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 52 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n shamatar\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\n One thing which is unclear in my head is why does one need to allow bad exits at all?\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\nThis seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …\nWhy is a validator-based approach good for Casper and bad for Plasma ?\nActually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …\n\n post by kz on Feb 3, 2018\n\n kz\n\n @denett Oh, I’m sorry, I’ve missed that part of your previous answer.\n\nCorrect, you’ve said it It’s hard for me to discuss these things over forums.\n\nIt would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.\nI believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.\nWhat is the downside of a solution to have two colored UTXOs on plasma chain?\n\nCommited = red\nUncommited = blue.\n\nOne can exit both red and blue UTXOs.\nOnly red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.\nIf exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.\n\n post by denett on Feb 3, 2018\n\n denett\n\nI guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.\n\n post by kz on Feb 3, 2018\n\n kz\n\nYeah, that was my thought as well.\nI was referring to:\n\n post by vbuterin on Feb 3, 2018\n\n vbuterin\n\n denett\n\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\n\nWhat do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.\n\n post by kz on Feb 3, 2018\n\n kz\n\n This is probably also an interesting link\nhttps://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ\nnot sure why nobody posted this here.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\nSome people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.\nWhat I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain \nPlasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released \nCryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …\n\n 2 months later\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\n Heads up: this might be a naive question, and might have been discussed somehere else.\nOne great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.\nAm I wrong? Or is the solution to deploy B to P_A if this is needed?\nIf this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\n Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.\nNothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.\nYour question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?\n\n Load more posts below","tokens":3379,"squid":"ink-research","role":"Deep Scholar","at":1791266571073,"hash":"6b312ce745f9d227d890b2a5a23167ce3924c5ad"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/using-the-compiler.html?color=dark","domain":"docs.soliditylang.org","title":"Using the Compiler — Solidity 0.8.31-develop documentation","text":"Using the Compiler\n\n Edit on GitHub\n\nUsing the Compiler\n\nUsing the Commandline Compiler\n\nNote\nThis section does not apply to solcjs, not even if it is used in commandline mode.\n\nBasic Usage\nOne of the build targets of the Solidity repository is solc, the Solidity commandline compiler.\nUsing solc --help provides you with an explanation of all options. The compiler can produce various outputs, ranging from simple binaries and assembly over an abstract syntax tree (parse tree) to estimations of gas usage.\nIf you only want to compile a single file, you run it as solc --bin sourceFile.sol and it will print the binary. If you want to get some of the more advanced output variants of solc, it is probably better to tell it to output everything to separate files using solc -o outputDirectory --bin --ast-compact-json --asm sourceFile.sol.\n\nOptimizer Options\nBefore you deploy your contract, activate the optimizer when compiling using solc --optimize --bin sourceFile.sol.\nBy default, the optimizer will optimize the contract assuming it is called 200 times across its lifetime\n(more specifically, it assumes each opcode is executed around 200 times).\nIf you want the initial contract deployment to be cheaper and the later function executions to be more expensive,\nset it to --optimize-runs=1. If you expect many transactions and do not care for higher deployment cost and\noutput size, set --optimize-runs to a high number.\nThis parameter has effects on the following (this might change in the future):\n\nthe size of the binary search in the function dispatch routine\nthe way constants like large numbers or strings are stored\n\nBase Path and Import Remapping\nThe commandline compiler will automatically read imported files from the filesystem, but\nit is also possible to provide path redirects using prefix=path in the following way:\nsolc github.com/ethereum/dapp-bin/=/usr/local/lib/dapp-bin/ file.sol\n\nThis essentially instructs the compiler to search for anything starting with\ngithub.com/ethereum/dapp-bin/ under /usr/local/lib/dapp-bin.\nWhen accessing the filesystem to search for imports, paths that do not start with ./\nor ../ are treated as relative to the directories specified using\n--base-path and --include-path options (or the current working directory if base path is not specified).\nFurthermore, the part of the path added via these options will not appear in the contract metadata.\nFor security reasons the compiler has restrictions on what directories it can access.\nDirectories of source files specified on the command-line and target paths of\nremappings are automatically allowed to be accessed by the file reader, but everything\nelse is rejected by default.\nAdditional paths (and their subdirectories) can be allowed via the\n--allow-paths /sample/path,/another/sample/path switch.\nEverything inside the path specified via --base-path is always allowed.\nThe above is only a simplification of how the compiler handles import paths.\nFor a detailed explanation with examples and discussion of corner cases please refer to the section on\npath resolution.\n\nLibrary Linking\nIf your contracts use libraries, you will notice that the bytecode contains substrings of the form __$53aea86b7d70b31448b230b20ae141a537$__ (format was different <v0.5.0). These are placeholders for the actual library addresses.\nThe placeholder is a 34 character prefix of the hex encoding of the keccak256 hash of the fully qualified library name.\nThe bytecode file will also contain lines of the form // <placeholder> -> <fq library name> at the end to help\nidentify which libraries the placeholders represent. Note that the fully qualified library name\nis the path of its source file and the library name separated by :.\nYou can use solc as a linker meaning that it will insert the library addresses for you at those points:\nEither add --libraries \"file.sol:Math=0x1234567890123456789012345678901234567890 file.sol:Heap=0xabCD567890123456789012345678901234567890\" to your command to provide an address for each library (use commas or spaces as separators) or store the string in a file (one library per line) and run solc using --libraries fileName.\n\nNote\nStarting Solidity 0.8.1 accepts = as separator between library and address, and : as a separator is deprecated. It will be removed in the future. Currently --libraries \"file.sol:Math:0x1234567890123456789012345678901234567890 file.sol:Heap:0xabCD567890123456789012345678901234567890\" will work too.\n\nIf solc is called with the option --standard-json, it will expect a JSON input (as explained below) on the standard input, and return a JSON output on the standard output. This is the recommended interface for more complex and especially automated uses. The process will always terminate in a “success” state and report any errors via the JSON output.\nThe option --base-path is also processed in standard-json mode.\nIf solc is called with the option --link, all input files are interpreted to be unlinked binaries (hex-encoded) in the __$53aea86b7d70b31448b230b20ae141a537$__-format given above and are linked in-place (if the input is read from stdin, it is written to stdout). All options except --libraries are ignored (including -o) in this case.\n\nWarning\nManually linking libraries on the generated bytecode is discouraged because it does not update\ncontract metadata. Since metadata contains a list of libraries specified at the time of\ncompilation and bytecode contains a metadata hash, you will get different binaries, depending\non when linking is performed.\nYou should ask the compiler to link the libraries at the time a contract is compiled by either\nusing the --libraries option of solc or the libraries key if you use the\nstandard-JSON interface to the compiler.\n\nNote\nThe library placeholder used to be the fully qualified name of the library itself\ninstead of the hash of it. This format is still supported by solc --link but\nthe compiler will no longer output it. This change was made to reduce\nthe likelihood of a collision between libraries, since only the first 36 characters\nof the fully qualified library name could be used.\n\nSetting the EVM Version to Target\nWhen you compile your contract code you can specify the Ethereum virtual machine\nversion to compile for to avoid particular features or behaviors.\n\nWarning\nCompiling for the wrong EVM version can result in wrong, strange and failing\nbehavior. Please ensure, especially if running a private chain, that you\nuse matching EVM versions.\n\nOn the command-line, you can select the EVM version as follows:\nsolc --evm-version <VERSION> contract.sol\n\nIn the standard JSON interface, use the \"evmVersion\"\nkey in the \"settings\" field:\n{\n \"sources\": {/* ... */},\n \"settings\": {\n \"optimizer\": {/* ... */},\n \"evmVersion\": \"<VERSION>\"\n }\n}\n\nTarget Options\nBelow is a list of target EVM versions and the compiler-relevant changes introduced\nat each version. Backward compatibility is not guaranteed between each version.\n\nhomestead (support deprecated)\n(oldest version)\n\ntangerineWhistle (support deprecated)\nGas cost for access to other accounts increased, relevant for gas estimation and the optimizer.\nAll gas sent by default for external calls, previously a certain amount had to be retained.\n\nspuriousDragon (support deprecated)\nGas cost for the exp opcode increased, relevant for gas estimation and the optimizer.\n\nbyzantium (support deprecated)\nOpcodes returndatacopy, returndatasize and staticcall are available in assembly.\nThe staticcall opcode is used when calling non-library view or pure functions, which prevents the functions from modifying state at the EVM level, i.e., even applies when you use invalid type conversions.\nIt is possible to access dynamic data returned from function calls.\nrevert opcode introduced, which means that revert() will not waste gas.\n\nconstantinople\nOpcodes create2, extcodehash, shl, shr and sar are available in assembly.\nShifting operators use shifting opcodes and thus need less gas.\n\npetersburg\nThe compiler behaves the same way as with constantinople.\n\nistanbul\nOpcodes chainid and selfbalance are available in assembly.\n\nberlin\nGas costs for SLOAD, *CALL, BALANCE, EXT* and SELFDESTRUCT increased. The\ncompiler assumes cold gas costs for such operations. This is relevant for gas estimation and\nthe optimizer.\n\nlondon\nThe block’s base fee (EIP-3198 and EIP-1559) can be accessed via the global block.basefee or basefee() in inline assembly.\n\nparis\nIntroduces prevrandao() and block.prevrandao, and changes the semantics of the now deprecated block.difficulty, disallowing difficulty() in inline assembly (see EIP-4399).\n\nshanghai\nSmaller code size and gas savings due to the introduction of push0 (see EIP-3855).\n\ncancun\nThe block’s blob base fee (EIP-7516 and EIP-4844) can be accessed via the global block.blobbasefee or blobbasefee() in inline assembly.\nIntroduces blobhash() in inline assembly and a corresponding global function to retrieve versioned hashes of blobs associated with the transaction (see EIP-4844).\nOpcode mcopy is available in assembly (see EIP-5656).\nOpcodes tstore and tload are available in assembly (see EIP-1153).\n\nprague\n\nosaka (default)\nclz builtin function is available in inline assembly. (EIP-7939)\n\nCompiler Input and Output JSON Description\nThe recommended way to interface with the Solidity compiler especially for\nmore complex and automated setups is the so-called JSON-input-output interface.\nThe same interface is provided by all distributions of the compiler.\nThe fields are generally subject to change,\nsome are optional (as noted), but we try to only make backwards compatible changes.\nThe compiler API expects a JSON formatted input and outputs the compilation result in a JSON formatted output.\nThe standard error output is not used and the process will always terminate in a “success” state, even\nif there were errors. Errors are always reported as part of the JSON output.\nThe following subsections describe the format through an example.\nComments are of course not permitted and used here only for explanatory purposes.\n\nInput Description\n{\n // Required: Source code language. Currently supported are \"Solidity\", \"Yul\", \"SolidityAST\" (experimental), \"EVMAssembly\" (experimental).\n \"language\": \"Solidity\",\n // Required\n \"sources\":\n {\n // The keys here are the \"global\" names of the source files,\n // imports can use other files via remappings (see below).\n \"myFile.sol\":\n {\n // Optional: keccak256 hash of the source file\n // It is used to verify the retrieved content if imported via URLs.\n \"keccak256\": \"0x123...\",\n // Required (unless \"content\" is used, see below): URL(s) to the source file.\n // URL(s) should be imported in this order and the result checked against the\n // keccak256 hash (if available). If the hash doesn't match or none of the\n // URL(s) result in success, an error should be raised.\n // Using the commandline interface only filesystem paths are supported.\n // With the JavaScript interface the URL will be passed to the user-supplied\n // read callback, so any URL supported by the callback can be used.\n \"urls\":\n [\n \"bzzr://56ab...\",\n \"ipfs://Qma...\",\n \"/tmp/path/to/file.sol\"\n // If files are used, their directories should be added to the command-line via\n // `--allow-paths <path>`.\n ]\n },\n \"settable\":\n {\n // Optional: keccak256 hash of the source file\n \"keccak256\": \"0x234...\",\n // Required (unless \"urls\" is used): literal contents of the source file\n \"content\": \"contract settable is owned { uint256 private x = 0; function set(uint256 _x) public { if (msg.sender == owner) x = _x; } }\"\n },\n \"myFile.sol_json.ast\":\n {\n // If language is set to \"SolidityAST\", an AST needs to be supplied under the \"ast\" key\n // and there can be only one source file present.\n // The format is the same as used by the `ast` output.\n // Note that importing ASTs is experimental and in particular that:\n // - importing invalid ASTs can produce undefined results and\n // - no proper error reporting is available on invalid ASTs.\n // Furthermore, note that the AST import only consumes the fields of the AST as\n // produced by the compiler in \"stopAfter\": \"parsing\" mode and then re-performs\n // analysis, so any analysis-based annotations of the AST are ignored upon import.\n \"ast\": { ... }\n },\n \"myFile_evm.json\":\n {\n // If language is set to \"EVMAssembly\", an EVM Assembly JSON object needs to be supplied\n // under the \"assemblyJson\" key and there can be only one source file present.\n // The format is the same as used by the `evm.legacyAssembly` output or `--asm-json`\n // output on the command line.\n // Note that importing EVM assembly is experimental.\n \"assemblyJson\":\n {\n \".code\": [ ... ],\n \".data\": { ... }, // optional\n \"sourceList\": [ ... ] // optional (if no `source` node was defined in any `.code` object)\n }\n }\n },\n // Optional\n \"settings\":\n {\n // Optional: Stop compilation after the given stage. Currently only \"parsing\" is valid here\n \"stopAfter\": \"parsing\",\n // Optional: List of remappings\n \"remappings\": [ \":g=/dir\" ],\n // Optional: Optimizer settings\n \"optimizer\": {\n // Turn on the optimizer. Optional. Default: false.\n // NOTE: The state of the optimizer is fully determined by the 'details' dict and this setting\n // only affects its defaults - when enabled, all components default to being enabled.\n // The opposite is not true - there are several components that always default to being\n // enabled an can only be explicitly disabled via 'details'.\n // WARNING: Before version 0.8.6 omitting this setting was not equivalent to setting\n // it to false and would result in all components being disabled instead.\n // WARNING: Enabling optimizations for EVMAssembly input is allowed but not necessary under normal\n // circumstances. It forces the opcode-based optimizer to run again and can produce bytecode that\n // is not reproducible from metadata.\n \"enabled\": true,\n // Optimize for how many times you intend to run the code. Optional. Default: 200.\n // Lower values will optimize more for initial deployment cost, higher\n // values will optimize more for high-frequency usage.\n \"runs\": 200,\n // State of all optimizer components. Optional.\n // Default values are determined by whether the optimizer is enabled or not.\n // Note that the 'enabled' setting only affects the defaults here and has no effect when\n // all values are provided explicitly.\n \"details\": {\n // Peephole optimizer (opcode-based). Optional. Default: true.\n // Default for EVMAssembly input: false when optimization is not enabled.\n // NOTE: Always runs (even with optimization disabled) except for EVMAssembly input or when explicitly turned off here.\n \"peephole\": true,\n // Inliner (opcode-based). Optional. Default: true when optimization is enabled.\n \"inliner\": false,\n // Unused JUMPDEST remover (opcode-based). Optional. Default: true.\n // Default for EVMAssembly input: false when optimization is not enabled.\n // NOTE: Always runs (even with optimization disabled) except for EVMAssembly input or when explicitly turned off here.\n \"jumpdestRemover\": true,\n // Literal reordering (codegen-based). Optional. Default: true when optimization is enabled.\n // Moves literals to the right of commutative binary operators during code generation, helping exploit associativity.\n \"orderLiterals\": false,\n // Block deduplicator (opcode-based). Optional. Default: true when optimization is enabled.\n // Unifies assembly code blocks that share content.\n \"deduplicate\": false,\n // Common subexpression elimination (opcode-based). Optional. Default: true when optimization is enabled.\n // This is the most complicated step but can also provide the largest gain.\n \"cse\": false,\n // Constant optimizer (opcode-based). Optional. Default: true when optimization is enabled.\n // Tries to find better representations of literal numbers and strings, that satisfy the\n // size/cost trade-off determined by the 'runs' setting.\n \"constantOptimizer\": false,\n // Unchecked loop increment (codegen-based). Optional. Default: true.\n // Use unchecked arithmetic when incrementing the counter of 'for' loops under certain circumstances.\n // NOTE: Always runs (even with optimization disabled) unless explicitly turned off here.\n \"simpleCounterForLoopUncheckedIncrement\": true,\n // Yul optimizer. Optional. Default: true when optimization is enabled.\n // Used to optimize the IR produced by the Yul IR-based pipeline as well as inline assembly\n // and utility Yul code generated by the compiler.\n // NOTE: Before Solidity 0.6.0 the default was false.\n \"yul\": false,\n // Tuning options for the Yul optimizer. Optional.\n \"yulDetails\": {\n // Improve allocation of stack slots for variables, can free up stack slots early.\n // Optional. Default: true if Yul optimizer is enabled.\n \"stackAllocation\": true,\n // Optimization step sequence.\n // The general form of the value is \"<main sequence>:<cleanup sequence>\".\n // The setting is optional and when omitted, default values are used for both sequences.\n // If the value does not contain the ':' delimiter, it is interpreted as the main\n // sequence and the default is used for the cleanup sequence.\n // To make one of the sequences empty, the delimiter must be present at the first or last position.\n // In particular if the whole value consists only of the delimiter, both sequences are empty.\n // Note that there are several hard-coded steps that always run, even when both sequences are empty.\n // For more information see \"The Optimizer > Selecting Optimizations\".\n \"optimizerSteps\": \"dhfoDgvulfnTUtnIf...\"\n }\n }\n },\n // Version of the EVM to compile for (optional).\n // Affects type checking and code generation. Can be homestead,\n // tangerineWhistle, spuriousDragon, byzantium, constantinople,\n // petersburg, istanbul, berlin, london, paris, shanghai, cancun, prague or osaka (default).\n \"evmVersion\": \"osaka\",\n // EVM Object Format version to compile for (optional, experimental).\n // Currently the only valid value is 1. If not specified, legacy non-EOF bytecode will be generated.\n // Requires `evmVersion` >= osaka.\n \"eofVersion\": null,\n // Optional: Change compilation pipeline to go through the Yul intermediate representation.\n // This is false by default.\n \"viaIR\": true,\n // Optional: Debugging settings\n \"debug\": {\n // How to treat revert (and require) reason strings. Settings are\n // \"default\", \"strip\", \"debug\" and \"verboseDebug\".\n // \"default\" does not inject compiler-generated revert strings and keeps user-supplied ones.\n // \"strip\" removes all revert strings (if possible, i.e. if literals are used) keeping side-effects\n // \"debug\" injects strings for compiler-generated internal reverts, implemented for ABI encoders V1 and V2 for now.\n // \"verboseDebug\" even appends further information to user-supplied revert strings (not yet implemented)\n \"revertStrings\": \"default\",\n // Optional: How much extra debug information to include in comments in the produced EVM\n // assembly and Yul code. Available components are:\n // - `location`: Annotations of the form `@src <index>:<start>:<end>` indicating the\n // location of the corresponding element in the original Solidity file, where:\n // - `<index>` is the file index matching the `@use-src` annotation,\n // - `<start>` is the index of the first byte at that location,\n // - `<end>` is the index of the first byte after that location.\n // - `snippet`: A single-line code snippet from the location indicated by `@src`.\n // The snippet is quoted and follows the corresponding `@src` annotation.\n // - `*`: Wildcard value that can be used to request everything.\n \"debugInfo\": [\"location\", \"snippet\"]\n },\n // Metadata settings (optional)\n \"metadata\": {\n // The CBOR metadata is appended at the end of the bytecode by default.\n // Setting this to false omits the metadata from the runtime and deploy time code.\n \"appendCBOR\": true,\n // Use only literal content and not URLs (false by default)\n \"useLiteralContent\": true,\n // Use the given hash method for the metadata hash that is appended to the bytecode.\n // The metadata hash can be removed from the bytecode via option \"none\".\n // The other options are \"ipfs\" and \"bzzr1\".\n // If the option is omitted, \"ipfs\" is used by default.\n \"bytecodeHash\": \"ipfs\"\n },\n // Addresses of the libraries. If not all libraries are given here,\n // it can result in unlinked objects whose output data is different.\n \"libraries\": {\n // The top level key is the name of the source file where the library is used.\n // If remappings are used, this source file should match the global path\n // after remappings were applied.\n // If this key is an empty string, that refers to a global level.\n \"myFile.sol\": {\n \"MyLib\": \"0x123123...\"\n }\n },\n // The following can be used to select desired outputs based\n // on file and contract names.\n // If this field is omitted, then the compiler loads and does type checking,\n // but will not generate any outputs apart from errors.\n // The first level key is the file name and the second level key is the contract name.\n // An empty contract name is used for outputs that are not tied to a contract\n // but to the whole source file like the AST.\n // A star as contract name refers to all contracts in the file.\n // Similarly, a star as a file name matches all files.\n // To select all outputs the compiler can possibly generate, with the exclusion of\n // Yul intermediate representation outputs, use\n // \"outputSelection: { \"*\": { \"*\": [ \"*\" ], \"\": [ \"*\" ] } }\"\n // but note that this might slow down the compilation process needlessly.\n //\n // The available output types are as follows:\n //\n // File level (needs empty string as contract name):\n // ast - AST of all source files\n //\n // Contract level (needs the contract name or \"*\"):\n // abi - ABI\n // devdoc - Developer documentation (natspec)\n // userdoc - User documentation (natspec)\n // metadata - Metadata\n // ir - Yul intermediate representation of the code before optimization\n // irAst - AST of Yul intermediate representation of the code before optimization\n // irOptimized - Intermediate representation after optimization\n // irOptimizedAst - AST of intermediate representation after optimization\n // storageLayout - Slots, offsets and types of the contract's state variables in storage.\n // transientStorageLayout - Slots, offsets and types of the contract's state variables in transient storage.\n // evm.assembly - New assembly format\n // evm.legacyAssembly - Old-style assembly format in JSON\n // evm.bytecode.functionDebugData - Debugging information at function level\n // evm.bytecode.object - Bytecode object\n // evm.bytecode.opcodes - Opcodes list\n // evm.bytecode.sourceMap - Source mapping (useful for debugging)\n // evm.bytecode.linkReferences - Link references (if unlinked object)\n // evm.bytecode.generatedSources - Sources generated by the compiler\n // evm.deployedBytecode* - Deployed bytecode (has all the options that evm.bytecode has)\n // evm.deployedBytecode.immutableReferences - Map from AST ids to bytecode ranges that reference immutables\n // evm.methodIdentifiers - The list of function hashes\n // evm.gasEstimates - Function gas estimates\n //\n // Note that using `evm`, `evm.bytecode`, etc. will select every\n // target part of that output. Additionally, `*` can be used as a wildcard to request everything.\n //\n \"outputSelection\": {\n \"*\": {\n \"*\": [\n \"metadata\", \"evm.bytecode\" // Enable the metadata and bytecode outputs of every single contract.\n , \"evm.bytecode.sourceMap\" // Enable the source map output of every single contract.\n ],\n \"\": [\n \"ast\" // Enable the AST output of every single file.\n ]\n },\n // Enable the abi and opcodes output of MyContract defined in file def.\n \"def\": {\n \"MyContract\": [ \"abi\", \"evm.bytecode.opcodes\" ]\n }\n },\n // The modelChecker object is experimental and subject to changes.\n \"modelChecker\":\n {\n // Chose which contracts should be analyzed as the deployed one.\n \"contracts\":\n {\n \"source1.sol\": [\"contract1\"],\n \"source2.sol\": [\"contract2\", \"contract3\"]\n },\n // Choose how division and modulo operations should be encoded.\n // When using `false` they are replaced by multiplication with slack\n // variables. This is the default.\n // Using `true` here is recommended if you are using the CHC engine\n // and not using Spacer as the Horn solver (using Eldarica, for example).\n // See the Formal Verification section for a more detailed explanation of this option.\n \"divModNoSlacks\": false,\n // Choose which model checker engine to use: all (default), bmc, chc, none.\n \"engine\": \"chc\",\n // Choose whether external calls should be considered trusted in case the\n // code of the called function is available at compile-time.\n // For details see the SMTChecker section.\n \"extCalls\": \"trusted\",\n // Choose which types of invariants should be reported to the user: contract, reentrancy.\n \"invariants\": [\"contract\", \"reentrancy\"],\n // Choose whether to output all proved targets. The default is `false`.\n \"showProvedSafe\": true,\n // Choose whether to output all unproved targets. The default is `false`.\n \"showUnproved\": true,\n // Choose whether to output all unsupported language features. The default is `false`.\n \"showUnsupported\": true,\n // Choose which solvers should be used, if available.\n // See the Formal Verification section for the solvers description.\n \"solvers\": [\"cvc5\", \"smtlib2\", \"z3\"],\n // Choose which targets should be checked: constantCondition,\n // underflow, overflow, divByZero, balance, assert, popEmptyArray, outOfBounds.\n // If the option is not given all targets are checked by default,\n // except underflow/overflow for Solidity >=0.8.7.\n // See the Formal Verification section for the targets description.\n \"targets\": [\"underflow\", \"overflow\", \"assert\"],\n // Timeout for each SMT query in milliseconds.\n // If this option is not given, the SMTChecker will use a deterministic\n // resource limit by default.\n // A given timeout of 0 means no resource/time restrictions for any query.\n \"timeout\": 20000\n }\n }\n}\n\nOutput Description\n{\n // Optional: not present if no errors/warnings/infos were encountered\n \"errors\": [\n {\n // Optional: Location within the source file.\n \"sourceLocation\": {\n \"file\": \"sourceFile.sol\",\n \"start\": 0,\n \"end\": 100\n },\n // Optional: Further locations (e.g. places of conflicting declarations)\n \"secondarySourceLocations\": [\n {\n \"file\": \"sourceFile.sol\",\n \"start\": 64,\n \"end\": 92,\n \"message\": \"Other declaration is here:\"\n }\n ],\n // Mandatory: Error type, such as \"TypeError\", \"InternalCompilerError\", \"Exception\", etc.\n // See below for complete list of types.\n \"type\": \"TypeError\",\n // Mandatory: Component where the error originated, such as \"general\" etc.\n \"component\": \"general\",\n // Mandatory (\"error\", \"warning\" or \"info\", but please note that this may be extended in the future)\n \"severity\": \"error\",\n // Optional: unique code for the cause of the error\n \"errorCode\": \"3141\",\n // Mandatory\n \"message\": \"Invalid keyword\",\n // Optional: the message formatted with source location\n \"formattedMessage\": \"sourceFile.sol:100: Invalid keyword\"\n }\n ],\n // This contains the file-level outputs.\n // It can be limited/filtered by the outputSelection settings.\n \"sources\": {\n \"sourceFile.sol\": {\n // Identifier of the source (used in source maps)\n \"id\": 1,\n // The AST object\n \"ast\": {}\n }\n },\n // This contains the contract-level outputs.\n // It can be limited/filtered by the outputSelection settings.\n \"contracts\": {\n \"sourceFile.sol\": {\n // If the language used has no contract names, this field should equal to an empty string.\n \"ContractName\": {\n // The Ethereum Contract ABI. If empty, it is represented as an empty array.\n // See https://docs.soliditylang.org/en/develop/abi-spec.html\n \"abi\": [],\n // See the Metadata Output documentation (serialised JSON string)\n \"metadata\": \"{/* ... */}\",\n // User documentation (natspec)\n \"userdoc\": {},\n // Developer documentation (natspec)\n \"devdoc\": {},\n // Intermediate representation before optimization (string)\n \"ir\": \"\",\n // AST of intermediate representation before optimization\n \"irAst\": {/* ... */},\n // Intermediate representation after optimization (string)\n \"irOptimized\": \"\",\n // AST of intermediate representation after optimization\n \"irOptimizedAst\": {/* ... */},\n // See the Storage Layout documentation.\n \"storageLayout\": {\"storage\": [/* ... */], \"types\": {/* ... */} },\n // See the Storage Layout documentation.\n \"transientStorageLayout\": {\"storage\": [/* ... */], \"types\": {/* ... */} },\n // EVM-related outputs\n \"evm\": {\n // Assembly (string)\n \"assembly\": \"\",\n // Old-style assembly (object)\n \"legacyAssembly\": {},\n // Bytecode and related details.\n \"bytecode\": {\n // Debugging data at the level of functions.\n \"functionDebugData\": {\n // Now follows a set of functions including compiler-internal and\n // user-defined function. The set does not have to be complete.\n \"@mint_13\": { // Internal name of the function\n \"entryPoint\": 128, // Byte offset into the bytecode where the function starts (optional)\n \"id\": 13, // AST ID of the function definition or null for compiler-internal functions (optional)\n \"parameterSlots\": 2, // Number of EVM stack slots for the function parameters (optional)\n \"returnSlots\": 1 // Number of EVM stack slots for the return values (optional)\n }\n },\n // The bytecode as a hex string.\n \"object\": \"00fe\",\n // Opcodes list (string)\n \"opcodes\": \"\",\n // The source mapping as a string. See the source mapping definition.\n \"sourceMap\": \"\",\n // Array of sources generated by the compiler. Currently only\n // contains a single Yul file.\n \"generatedSources\": [{\n // Yul AST\n \"ast\": {/* ... */},\n // Source file in its text form (may contain comments)\n \"contents\":\"{ function abi_decode(start, end) -> data { data := calldataload(start) } }\",\n // Source file ID, used for source references, same \"namespace\" as the Solidity source files\n \"id\": 2,\n \"language\": \"Yul\",\n \"name\": \"#utility.yul\"\n }],\n // If given, this is an unlinked object.\n \"linkReferences\": {\n \"libraryFile.sol\": {\n // Byte offsets into the bytecode.\n // Linking replaces the 20 bytes located there.\n \"Library1\": [\n { \"start\": 0, \"length\": 20 },\n { \"start\": 200, \"length\": 20 }\n ]\n }\n }\n },\n \"deployedBytecode\": {\n /* ..., */ // The same layout as above.\n \"immutableReferences\": {\n // There are two references to the immutable with AST ID 3, both 32 bytes long. One is\n // at bytecode offset 42, the other at bytecode offset 80.\n \"3\": [{ \"start\": 42, \"length\": 32 }, { \"start\": 80, \"length\": 32 }]\n }\n },\n // The list of function hashes\n \"methodIdentifiers\": {\n \"delegate(address)\": \"5c19a95c\"\n },\n // Function gas estimates\n \"gasEstimates\": {\n \"creation\": {\n \"codeDepositCost\": \"420000\",\n \"executionCost\": \"infinite\",\n \"totalCost\": \"infinite\"\n },\n \"external\": {\n \"delegate(address)\": \"25000\"\n },\n \"internal\": {\n \"heavyLifting()\": \"infinite\"\n }\n }\n }\n }\n }\n }\n}\n\nError Types\n\nJSONError: JSON input doesn’t conform to the required format, e.g. input is not a JSON object, the language is not supported, etc.\nIOError: IO and import processing errors, such as unresolvable URL or hash mismatch in supplied sources.\nParserError: Source code doesn’t conform to the language rules.\nDocstringParsingError: The NatSpec tags in the comment block cannot be parsed.\nSyntaxError: Syntactical error, such as continue is used outside of a for loop.\nDeclarationError: Invalid, unresolvable or clashing identifier names. e.g. Identifier not found\nTypeError: Error within the type system, such as invalid type conversions, invalid assignments, etc.\nUnimplementedFeatureError: Feature is not supported by the compiler, but is expected to be supported in future versions.\nInternalCompilerError: Internal bug triggered in the compiler - this should be reported as an issue.\nException: Unknown failure during compilation - this should be reported as an issue.\nCompilerError: Invalid use of the compiler stack - this should be reported as an issue.\nFatalError: Fatal error not processed correctly - this should be reported as an issue.\nYulException: Error during Yul code generation - this should be reported as an issue.\nWarning: A warning, which didn’t stop the compilation, but should be addressed if possible.\nInfo: Information that the compiler thinks the user might find useful, but is not dangerous and does not necessarily need to be addressed.","tokens":8033,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266571125,"hash":"043fc068bed7635d36a1d83bafdd4e54f0350f83"}
{"url":"https://docs.base.org/specifications/reference/smart-contracts","domain":"docs.base.org","title":"Smart Contracts - Base Documentation","text":"Base is an EVM-equivalent Ethereum L2. Smart contracts are written in Solidity or Vyper and deploy exactly as they do on Ethereum — the same bytecode, ABIs, and tooling apply.\n​How Base Differs\nBase adds native precompiles at fixed addresses that extend the EVM with functionality built into the node itself, such as the B20 token standard, the PolicyRegistry, and the B20 Factory. These addresses hold no contract bytecode, so standard Foundry (forge, cast, anvil) cannot simulate calls to them and aborts with call to non-contract address.\nBase publishes base-anvil, a fork of Foundry that registers Base’s precompiles into its EVM. It installs base-forge, base-cast, and base-anvil alongside your existing Foundry toolchain without overwriting it, so contracts behave the same locally as they do on Base.\nUse Base’s Foundry build (base-forge, base-cast, base-anvil) rather than standard Foundry (forge, cast, anvil) for Base development. A contract that reads or writes a Base precompile — for example one that deploys or calls a B20 token — will fail under standard Foundry.\n​Set Up Your Environment\n\nCreate a new project directory\n\nTerminalmkdir my-base-project && cd my-base-project\n\nInstall Base’s Foundry build\n\nTerminalcurl -L https://raw.githubusercontent.com/base/base-anvil/HEAD/foundryup/install | bash\nbase-foundryup\n\nThis installs base-forge, base-cast, and base-anvil alongside your existing Foundry toolchain.\n\nInitialize a new Solidity project\n\nTerminalbase-forge init\n\nYour project is ready. You’ll find an example Counter contract in src/Counter.sol, which you can replace with your own contracts.\nBase’s Foundry build provides the same tools as standard Foundry, with Base’s precompiles built in: base-forge (build and test), base-cast (interact with the chain), and base-anvil (run a local Base node). Learn more about base-anvil and the underlying Foundry toolchain.\n​Configure a Node Connection and Deployer Key\n\nCreate a .env file in your project root and add the Base RPC URLs\n\n.envBASE_RPC_URL=\"https://mainnet.base.org\"\nBASE_SEPOLIA_RPC_URL=\"https://sepolia.base.org\"\n\nLoad the variables\n\nTerminalsource .env\n\nStore your deployer private key in Foundry’s secure keystore\n\nTerminalbase-cast wallet import deployer --interactive\n\nEnter your private key and a password when prompted. The key is stored in ~/.foundry/keystores, which is not tracked by git.\nNever share or commit your private key. Always keep it secure and handle it with care.\nBase Sepolia is the test network for Base, used for the rest of this guide. Get free Base Sepolia ETH from one of the faucets listed here.\n​Deploy a Contract\n\n(Optional) Dry-run the deployment to confirm your configuration:\n\nTerminalbase-forge create ./src/Counter.sol:Counter --rpc-url $BASE_SEPOLIA_RPC_URL --account deployer\n\nThis simulates the deployment without broadcasting. You’ll see the transaction details and contract ABI, but nothing is deployed.\n\nDeploy by adding the --broadcast flag:\n\nTerminalbase-forge create ./src/Counter.sol:Counter --rpc-url $BASE_SEPOLIA_RPC_URL --account deployer --broadcast\n\nThe contract path format is <contract-path>:<contract-name>.\n\nOn success you’ll see the deployed address:\n\nExample OutputDeployer: 0x...\nDeployed to: 0x... <-- YOUR CONTRACT ADDRESS\nTransaction hash: 0x...\n\n​Verify Your Deployment\n\nCheck the transaction on Sepolia Basescan using the transaction hash.\nRead the contract’s state from the command line:\n\nTerminalbase-cast call <CONTRACT_ADDRESS> \"number()(uint256)\" --rpc-url $BASE_SEPOLIA_RPC_URL\n\nThis returns the initial value of the Counter contract’s number variable, 0.\n​Next Steps\n\nUse wagmi or viem to connect your frontend to your contracts, and see the Foundry scripting guide for command-line interaction.Was this page helpful?Suggest editsRaise issue","tokens":949,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266573486,"hash":"8fb4521f0ce4517d014860858eb027e5da695990"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/54","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 54 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\n One thing which is unclear in my head is why does one need to allow bad exits at all?\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\nThis seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …\nWhy is a validator-based approach good for Casper and bad for Plasma ?\nActually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …\n\n post by kz on Feb 3, 2018\n\n kz\n\n @denett Oh, I’m sorry, I’ve missed that part of your previous answer.\n\nCorrect, you’ve said it It’s hard for me to discuss these things over forums.\n\nIt would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.\nI believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.\nWhat is the downside of a solution to have two colored UTXOs on plasma chain?\n\nCommited = red\nUncommited = blue.\n\nOne can exit both red and blue UTXOs.\nOnly red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.\nIf exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.\n\n post by denett on Feb 3, 2018\n\n denett\n\nI guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.\n\n post by kz on Feb 3, 2018\n\n kz\n\nYeah, that was my thought as well.\nI was referring to:\n\n post by vbuterin on Feb 3, 2018\n\n vbuterin\n\n denett\n\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\n\nWhat do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.\n\n post by kz on Feb 3, 2018\n\n kz\n\n This is probably also an interesting link\nhttps://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ\nnot sure why nobody posted this here.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\nSome people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.\nWhat I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain \nPlasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released \nCryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …\n\n 2 months later\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\n Heads up: this might be a naive question, and might have been discussed somehere else.\nOne great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.\nAm I wrong? Or is the solution to deploy B to P_A if this is needed?\nIf this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\n Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.\nNothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.\nYour question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\nWhen I said Plasma above I meant Minimal Viable Plasma, sorry . And what you’re saying is that under MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nIn theory you could deploy dapp A’s plasma contract on both main chain and chain B, and submit block headers to both?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\nunder MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nYes. Moreover, I doubt anybody is going to implement Minimal Viable Plasma. See Plasma Cash.\n\n Load more posts below","tokens":2859,"squid":"ink-research","role":"Deep Scholar","at":1791266582383,"hash":"a6cfb4f548d402a3dcc9729ac061a483b7daff8b"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/55","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 55 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n vbuterin\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\n One thing which is unclear in my head is why does one need to allow bad exits at all?\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\nThis seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …\nWhy is a validator-based approach good for Casper and bad for Plasma ?\nActually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …\n\n post by kz on Feb 3, 2018\n\n kz\n\n @denett Oh, I’m sorry, I’ve missed that part of your previous answer.\n\nCorrect, you’ve said it It’s hard for me to discuss these things over forums.\n\nIt would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.\nI believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.\nWhat is the downside of a solution to have two colored UTXOs on plasma chain?\n\nCommited = red\nUncommited = blue.\n\nOne can exit both red and blue UTXOs.\nOnly red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.\nIf exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.\n\n post by denett on Feb 3, 2018\n\n denett\n\nI guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.\n\n post by kz on Feb 3, 2018\n\n kz\n\nYeah, that was my thought as well.\nI was referring to:\n\n post by vbuterin on Feb 3, 2018\n\n vbuterin\n\n denett\n\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\n\nWhat do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.\n\n post by kz on Feb 3, 2018\n\n kz\n\n This is probably also an interesting link\nhttps://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ\nnot sure why nobody posted this here.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\nSome people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.\nWhat I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain \nPlasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released \nCryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …\n\n 2 months later\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\n Heads up: this might be a naive question, and might have been discussed somehere else.\nOne great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.\nAm I wrong? Or is the solution to deploy B to P_A if this is needed?\nIf this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\n Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.\nNothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.\nYour question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\nWhen I said Plasma above I meant Minimal Viable Plasma, sorry . And what you’re saying is that under MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nIn theory you could deploy dapp A’s plasma contract on both main chain and chain B, and submit block headers to both?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\nunder MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nYes. Moreover, I doubt anybody is going to implement Minimal Viable Plasma. See Plasma Cash.\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\nWhat do you mean by a dapp’s plasma contract? On which chain does this dapp reside? What does this dapp do with Plasma?\n\n Load more posts below","tokens":2698,"squid":"ink-research","role":"Deep Scholar","at":1791266593042,"hash":"b08393a9f3d067e7589ae75ac17467ab10485590"}
{"url":"https://docs.base.org/specifications/reference/configuration","domain":"docs.base.org","title":"Configuration - Base Documentation","text":"There are four categories of Base configuration:\n\nConsensus Parameters: Fixed at genesis or changeable through privileged accounts or protocol upgrades.\nPolicy Parameters: Changeable without breaking consensus, within protocol-imposed constraints.\nAdmin Roles: Accounts that can upgrade contracts, change role owners, or update protocol parameters. Typically cold/multisig wallets.\nService Roles: Accounts used for day-to-day operations. Typically hot wallets.\n\n​Consensus Parameters\nParameterDescriptionAdministratorBatch Inbox AddressL1 address where batcher transactions are postedStaticBatcher HashVersioned hash of the authorized batcher sender(s)System Config OwnerChain IDUnique chain ID for transaction signature validationStaticProof Maturity DelayTime between proving and finalizing a withdrawal. Game finalization windows are 5 days for one proof or 1 day for two.L1 Proxy AdminRespected Game TypeGame type OptimismPortal accepts for withdrawal finalization. Aggregate verifier (621).GuardianBond Withdrawal DelayTime before dispute game bonds can be withdrawn. 1 day.StaticFee ScalarMarkup on transactions relative to raw L1 data cost. Fee margin between 0%–50%.System Config OwnerGas LimitL2 block gas limit. ≤ 200,000,000 gas.System Config OwnerGenesis StateInitial chain state including all predeploy code and storage. Standard predeploys and preinstalls only.StaticL2 Block TimeInterval at which L2 blocks are produced via derivation. 1 or 2 seconds.L1 Proxy AdminSequencing Window SizeMax batch submission gap before L1 fallback triggers. 3,600 L1 blocks (12 hours at 12s L1 block time).StaticStart BlockL1 block where SystemConfig was first initializedL1 Proxy AdminSuperchain TargetSuperchainConfig and ProtocolVersions addresses for cross-L2 config. Mainnet or Sepolia.StaticGovernance TokenOP governance token. Disabled.n/aOperator Fee ParamsOperator fee scalar and constant for fee calculation. Standard values are 0; non-zero for non-standard configurations such as op-succinct.System Config OwnerDA Footprint Gas ScalarScalar for DA footprint calculationSystem Config OwnerMinimum Base FeeMinimum base fee on L2System Config Owner\n​Policy Parameters\nParameterDescriptionAdministratorData Availability TypeWhether the batcher posts data as blobs or calldata. Ethereum (Blobs or Calldata); Alt-DA not supported.Batch SubmitterBatch Submission FrequencyFrequency of batcher transaction submissions to L1. ≤ 1,800 L1 blocks (6 hours at 12s L1 block time).Batch SubmitterOutput FrequencyFrequency of output root submissions to L1. ≤ 43,200 L2 blocks (24 hours at 2s L2 block time); must be non-zero. Deprecated once fault proofs are enabled.L1 Proxy Admin\n​Admin Roles\nRoleDescriptionAdministersL1 Proxy AdminProxyAdmin from the latest op-contracts release, authorized to upgrade L1 contractsL1 contractsL1 ProxyAdmin OwnerAuthorized to update the L1 Proxy Admin. 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2AL1 Proxy AdminL2 Proxy AdminProxyAdmin at 0x4200000000000000000000000000000000000018, authorized to upgrade L2 contractsPredeploysL2 ProxyAdmin OwnerAliased L1 ProxyAdmin Owner; upgrades L2 contracts via ProxyAdmin. 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3bL2 Proxy AdminSystem Config OwnerAuthorized to change values in the SystemConfig contractBatch Submitter, Sequencer P2P Signer, Fee Scalar, Gas Limit\n​Service Roles\nRoleDescriptionAdministratorBatch SubmitterAuthenticates batches submitted to L1System Config OwnerChallengerInteracts with permissioned dispute games. 0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3AL1 Proxy AdminGuardianPauses L1 withdrawals, blacklists dispute games, sets respected game type in OptimismPortal. 0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2L1 Proxy AdminProposerCreates permissioned dispute games on L1.L1 Proxy AdminSequencer P2P SignerSigns unsafe/pre-submitted blocks at the P2P layerSystem Config OwnerWas this page helpful?Suggest editsRaise issue","tokens":978,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266607593,"hash":"9d3fe4f493b199a3ca22f09ebfec4b03a2060c9f"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/56","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 56 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n shamatar\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\n One thing which is unclear in my head is why does one need to allow bad exits at all?\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\nThis seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …\nWhy is a validator-based approach good for Casper and bad for Plasma ?\nActually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …\n\n post by kz on Feb 3, 2018\n\n kz\n\n @denett Oh, I’m sorry, I’ve missed that part of your previous answer.\n\nCorrect, you’ve said it It’s hard for me to discuss these things over forums.\n\nIt would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.\nI believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.\nWhat is the downside of a solution to have two colored UTXOs on plasma chain?\n\nCommited = red\nUncommited = blue.\n\nOne can exit both red and blue UTXOs.\nOnly red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.\nIf exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.\n\n post by denett on Feb 3, 2018\n\n denett\n\nI guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.\n\n post by kz on Feb 3, 2018\n\n kz\n\nYeah, that was my thought as well.\nI was referring to:\n\n post by vbuterin on Feb 3, 2018\n\n vbuterin\n\n denett\n\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\n\nWhat do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.\n\n post by kz on Feb 3, 2018\n\n kz\n\n This is probably also an interesting link\nhttps://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ\nnot sure why nobody posted this here.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\nSome people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.\nWhat I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain \nPlasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released \nCryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …\n\n 2 months later\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\n Heads up: this might be a naive question, and might have been discussed somehere else.\nOne great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.\nAm I wrong? Or is the solution to deploy B to P_A if this is needed?\nIf this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\n Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.\nNothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.\nYour question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\nWhen I said Plasma above I meant Minimal Viable Plasma, sorry . And what you’re saying is that under MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nIn theory you could deploy dapp A’s plasma contract on both main chain and chain B, and submit block headers to both?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\nunder MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nYes. Moreover, I doubt anybody is going to implement Minimal Viable Plasma. See Plasma Cash.\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\nWhat do you mean by a dapp’s plasma contract? On which chain does this dapp reside? What does this dapp do with Plasma?\n\n post by mewwts on Apr 20, 2018\n\n mewwts\n\nSorry I was under the above conditions where we had one dapp per chain. So what I meant is that Chain A can be settled to both main chain and chain B. Not sure how that would work, but I guess nothing stopping you from doing it.\n\n Load more posts below","tokens":2674,"squid":"ink-research","role":"Deep Scholar","at":1791266615291,"hash":"ca61f825d76981de4bf387f8019a78479ad892ee"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/53","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 53 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n vbuterin\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\n One thing which is unclear in my head is why does one need to allow bad exits at all?\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\nThis seems to be a way simpler solution, I am a bit confused why would this challenge-based thing be better than making validators/collators responsible for security …\nWhy is a validator-based approach good for Casper and bad for Plasma ?\nActually, if validators sign exits you would not need the UTXO model at all - validators could simply sign exits from one EVM-based chain to another …\n\n post by kz on Feb 3, 2018\n\n kz\n\n @denett Oh, I’m sorry, I’ve missed that part of your previous answer.\n\nCorrect, you’ve said it It’s hard for me to discuss these things over forums.\n\nIt would be great if we could relieve the main ETH from storing any kind of additional information permanently so ETH pruning can work better.\nI believe that the current minimal viable plasma architecture only requires storing block hashes, and I believe event that can be improved to only store a set of last plasma hashes.\nWhat is the downside of a solution to have two colored UTXOs on plasma chain?\n\nCommited = red\nUncommited = blue.\n\nOne can exit both red and blue UTXOs.\nOnly red UTXO can be spend on plasma chain, and blue UTXO changes color to red when commitment is sent to plasma chain.\nIf exiting blue UTXO, a new plasma block is created that spends blue (uncommited) UTXO to 0x0.\n\n post by denett on Feb 3, 2018\n\n denett\n\nI guess the plasma chain can be pruned. The operator can propose a prune block containing only the pruned transactions. If users are not happy with the pruning they can exit before the pruning is irreversible.\n\n post by kz on Feb 3, 2018\n\n kz\n\nYeah, that was my thought as well.\nI was referring to:\n\n post by vbuterin on Feb 3, 2018\n\n vbuterin\n\n denett\n\nOne can simply have a requirement that exits need to be signed by validators/collators of the corresponding chain, and if a validator signs a bad exit, her deposit is slashed …\n\nWhat do you mean by “the corresponding chain”? The plasma chain, or the ethereum chain? It can’t be the plasma chain, because it must be possible to exit even if the plasma chain goes completely offline, and if it’s on the ethereum chain then you could have a mechanism where third parties allow an exit to go through instantly in exchange for putting up a deposit, but that’s basically just buying someone else’s exit slot, which I do expect to be a perfectly normal way for people to quickly cash out.\n\n post by kz on Feb 3, 2018\n\n kz\n\n This is probably also an interesting link\nhttps://www.youtube.com/channel/UCG2MeKuKDJRK4gFNk-dQuZQ\nnot sure why nobody posted this here.\n\n post by kladkogex on Feb 3, 2018\n\n kladkogex\n\nSome people would say that assuming the entire plasma chain to go offline may be a bit of an overkill. If a plasma chain has validators, and if the entire chain goes down, then arguably all users of the chain will have the incentive to bring at least the validators back working, otherwise none of the users will get their money back to the main chain.\nWhat I am saying is that you could have made it a requirement for each Plasma chain operator to maintain a set of validators for her chain \nPlasma is a very interesting idea, but frankly feels like a bit of a risky enterprise, it will be an interesting experiment to see what happens once it is actually released \nCryptocurrencies started as very simple systems run by enthusiasts , and now lit ooks like everything gets complex, I hope these new complex systems will be able to run in the wild and sustain zillions of possible threats and vulnerabilities. It is known that security troubles grow exponentially with complexity … It may be that people try complex things, the complex things crash and people get back to simple things …\n\n 2 months later\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\n Heads up: this might be a naive question, and might have been discussed somehere else.\nOne great thing with dapps running on the blockchain is interoperability. If I call a smart contract, that contract can in turn call some other contract. Now, in Plasma, I don’t see how my dapp A, deployed on it’s own chain P_A, can contact dapp B, deployed on it’s chain P_B.\nAm I wrong? Or is the solution to deploy B to P_A if this is needed?\nIf this is in fact true, is interoperability something we are sacrificing for scalability here? Or is my understanding just limited at this point?\n\n post by yhirai on Apr 19, 2018\n\n yhirai\n\n Minimal Viable Plasma is minimal viable, so the only interaction here is a Plasma chain operating with a parent chain. And Minimal Viable Plasma is about one specific application of transferring ETH.\nNothing is being sacrificed because other more complicated designs can be deployed in addition to this one. Useful ones will get popular and others will be deserted.\nYour question triggered this: what if chain B might look like a Plasma from chain A, and chain A might look like a Plasma from chain B?\n\n post by mewwts on Apr 19, 2018\n\n mewwts\n\nWhen I said Plasma above I meant Minimal Viable Plasma, sorry . And what you’re saying is that under MVPlasma this is indeed something we sacrifice, or don’t care about.\n\nIn theory you could deploy dapp A’s plasma contract on both main chain and chain B, and submit block headers to both?\n\n Load more posts below","tokens":3386,"squid":"ink-research","role":"Deep Scholar","at":1791266625750,"hash":"cfcf213bd0821aeb11631e4e21a2d59c3ac534a8"}
{"url":"https://forum.pyth.network/t/read-first-about-pyth-improvement-proposals-pips/24","domain":"forum.pyth.network","title":"READ FIRST: About Pyth Improvement Proposals (PIPs) - Proposals - Pyth DAO","text":"READ FIRST: About Pyth Improvement Proposals (PIPs) \n\n Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 1 / 5\n\n May 2024\n\n May 2024\n\n post by Pyth-DAO on May 9, 2024\n\n Pyth-DAO\n\n Pyth Improvement Proposals\nPIPs are the primary methods to introduce, discuss and implement changes to the Pyth DAO Constitution, governance and operations.\nPIP Types\nEach PIP must be labeled as Constitutional PIPs or Operational PIPs as described in more detail below:\n\nConstitutional PIPs are voted on by the Pyth DAO and they involve:\n\nthe upgrade of the Governance, Staking or Multisig programs\nthe amendment of this Constitution\nthe creation of Pyth DAO councils and sub-committees\n\nOperational PIPs that are either voted on by the Pyth DAO or delegated to one of the two Councils.\n\nOperational PIPs that are voted on by the Pyth DAO: - the election of members of the Pythian Council - the election of members of the Price Feed Council - the management of the Pyth DAO Treasury - the exceptional removal and replacement of a council member\nOperational PIPs delegated to the Pythian Council involve: - the upgrade of the oracle program - the upgrade of the verification program for each of the blockchains where Pyth data is accessible - the setting of data request fees per blockchain, as well as other protocol or network fees - the management of PGAS allocation and delegation to validators\nOperational PIPs delegated to the Price Feed Council involve: - the management of the list of price feeds available through Pyth - the selection of publishers and the setting of the minimum number of such publishers per price feed\n\nPIP Process\nNo PIP may be in violation of any of terms of the Operating Agreement of Pyth DAO LLC, or any applicable laws (including, in particular, sanctions-related regulations).\nThe end-to-end process length is 7 days.\n\nProposal Submission\n\nA PIP is submitted through a structured process via the Pyth DAO Discourse, marking the initiation of the formal review process. Each PIP needs to include:\n\nTitle - summary of your idea\nAbstract - that summarizes the PIP\nRationale - that explains why the Pyth community should implement the PIP and how it aligns with community’s mission and values\nKey Terms - technical and/or commercial associated with the PIP\nImplementation Plan - steps envisioned to implement the PIP, including resources needed for each step and timelines. The implementation plan may include binding on-chain actions that will automatically execute when the PIP passes.\n\nIf you would like further support or community feedback on your proposal idea before creating a formal PIP, you can take your idea to the Ideas Bank.\nThe requirements for formally advancing a proposal to the on-chain governance program are:\n\nFor a proposal voted on by the Pyth DAO, the proposer needs to hold at least 0.25% of the current Votable Tokens.\nFor a proposal voted on by a council, a member of such council needs to propose it.\n\nDAO Voting on formal PIP (7 days)\n\nThe Pyth DAO is able to vote directly on-chain on the submitted PIP for 7 days. The PIP passes if the following condition is met:\n\nin the case of a Constitutional PIP, > 67% of all Votable Tokens have been cast “in favor”; or\nin the case of an Operational PIP that is voted on by the Pyth DAO, > 50% of all Votable Tokens have been cast “in favor”\n\nImplementation\n\nThe PIP is then fully executed and implemented. Any on-chain actions in the implementation plan will execute automatically in this step. The Pyth DAO LLC, council members and other service providers of the Pyth DAO LLC will take any necessary off-chain actions to implement PIPs which have passed.\n\n Closed on May 9, 2024\n\n Pinned globally on May 9, 2024\n\n Unpinned on May 9, 2024\n\n Pinned on May 9, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [PASSED] CO-PIP-1 : Adoption of the Pyth DAO Constitution\n\n Proposals\n\n constitutional-pip\n\n 0\n\n 364\n\n May 2024\n\n Guide for the 5th Pythian Council Election\n\n Pythian Council\n\n 0\n\n 105\n\n May 12\n\n About the Pythian Council\n\n Pythian Council\n\n 1\n\n 372\n\n Jul 20\n\n Understanding the Forum Categories\n\n About the Pyth DAO\n\n 0\n\n 842\n\n May 2024\n\n About the Pyth DAO\n\n About the Pyth DAO\n\n 0\n\n 1.8k\n\n Apr 2024","tokens":1073,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266632565,"hash":"4a780cb98d060d0de7d120f7eb3c0233591018c4"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/metadata.html","domain":"docs.soliditylang.org","title":"Contract Metadata — Solidity 0.8.31-develop documentation","text":"Contract Metadata\n\n Edit on GitHub\n\nContract Metadata\nThe Solidity compiler automatically generates a JSON file.\nThe file contains two kinds of information about the compiled contract:\n\nHow to interact with the contract: ABI, and NatSpec documentation.\nHow to reproduce the compilation and verify a deployed contract:\ncompiler version, compiler settings, and source files used.\n\nThe compiler appends by default the IPFS hash of the metadata file to the end\nof the runtime bytecode (not necessarily the creation bytecode) of each contract,\nso that, if published, you can retrieve the file in an authenticated way without\nhaving to resort to a centralized data provider. The other available options are\nthe Swarm hash and not appending the metadata hash to the bytecode. These can be\nconfigured via the Standard JSON Interface.\nYou have to publish the metadata file to IPFS, Swarm, or another service so\nthat others can access it. You create the file by using the solc --metadata\ncommand together with the --output-dir parameter. Without the parameter,\nthe metadata will be written to standard output.\nThe metadata contains IPFS and Swarm references to the source code, so you have to\nupload all source files in addition to the metadata file. For IPFS, the hash contained\nin the CID returned by ipfs add (not the direct sha2-256 hash of the file)\nshall match with the one contained in the bytecode.\nThe metadata file has the following format. The example below is presented in a\nhuman-readable way. Properly formatted metadata should use quotes correctly,\nreduce whitespace to a minimum, and sort the keys of all objects in alphabetical order\nto arrive at a canonical formatting. Comments are not permitted and are used here only for\nexplanatory purposes.\n{\n // Required: Details about the compiler, contents are specific\n // to the language.\n \"compiler\": {\n // Optional: Hash of the compiler binary which produced this output\n \"keccak256\": \"0x123...\",\n // Required for Solidity: Version of the compiler\n \"version\": \"0.8.2+commit.661d1103\"\n },\n // Required: Source code language, basically selects a \"sub-version\"\n // of the specification\n \"language\": \"Solidity\",\n // Required: Generated information about the contract.\n \"output\": {\n // Required: ABI definition of the contract. See \"Contract ABI Specification\"\n \"abi\": [/* ... */],\n // Required: NatSpec developer documentation of the contract. See https://docs.soliditylang.org/en/latest/natspec-format.html for details.\n \"devdoc\": {\n // Contents of the @author NatSpec field of the contract\n \"author\": \"John Doe\",\n // Contents of the @dev NatSpec field of the contract\n \"details\": \"Interface of the ERC20 standard as defined in the EIP. See https://eips.ethereum.org/EIPS/eip-20 for details\",\n \"errors\": {\n \"MintToZeroAddress()\" : {\n \"details\": \"Cannot mint to zero address\"\n }\n },\n \"events\": {\n \"Transfer(address,address,uint256)\": {\n \"details\": \"Emitted when `value` tokens are moved from one account (`from`) toanother (`to`).\",\n \"params\": {\n \"from\": \"The sender address\",\n \"to\": \"The receiver address\",\n \"value\": \"The token amount\"\n }\n }\n },\n \"kind\": \"dev\",\n \"methods\": {\n \"transfer(address,uint256)\": {\n // Contents of the @dev NatSpec field of the method\n \"details\": \"Returns a boolean value indicating whether the operation succeeded. Must be called by the token holder address\",\n // Contents of the @param NatSpec fields of the method\n \"params\": {\n \"_value\": \"The amount tokens to be transferred\",\n \"_to\": \"The receiver address\"\n },\n // Contents of the @return NatSpec field.\n \"returns\": {\n // Return var name (here \"success\") if exists. \"_0\" as key if return var is unnamed\n \"success\": \"a boolean value indicating whether the operation succeeded\"\n }\n }\n },\n \"stateVariables\": {\n \"owner\": {\n // Contents of the @dev NatSpec field of the state variable\n \"details\": \"Must be set during contract creation. Can then only be changed by the owner\"\n }\n },\n // Contents of the @title NatSpec field of the contract\n \"title\": \"MyERC20: an example ERC20\",\n \"version\": 1 // NatSpec version\n },\n // Required: NatSpec user documentation of the contract. See \"NatSpec Format\"\n \"userdoc\": {\n \"errors\": {\n \"ApprovalCallerNotOwnerNorApproved()\": [\n {\n \"notice\": \"The caller must own the token or be an approved operator.\"\n }\n ]\n },\n \"events\": {\n \"Transfer(address,address,uint256)\": {\n \"notice\": \"`_value` tokens have been moved from `from` to `to`\"\n }\n },\n \"kind\": \"user\",\n \"methods\": {\n \"transfer(address,uint256)\": {\n \"notice\": \"Transfers `_value` tokens to address `_to`\"\n }\n },\n \"version\": 1 // NatSpec version\n }\n },\n // Required: Compiler settings.\n // Reflects the settings in the JSON input during compilation, except:\n // - Different format: \"libraries\" field\n // - Added field in metadata.settings: \"compilationTarget\"\n // - Not in metadata.settings: \"stopAfter\", \"debug.debugInfo\", \"outputSelection\"\n // See the standard JSON input's \"settings\" field docs for the rest.\n \"settings\": {\n // Required for Solidity: File path and the name of the contract or library this\n // metadata is created for. This field is not present in the standard JSON input settings.\n \"compilationTarget\": {\n \"myDirectory/myFile.sol\": \"MyContract\"\n },\n // Required for Solidity: Addresses for libraries used.\n // Note that metadata has a different format for \"libraries\" field than the standard JSON input.\n // metadata format = { \"MyLib.sol:MyLib\": \"0x123123...\" }\n // standard JSON input format = { \"MyLib.sol\": { \"MyLib\": \"0x123123...\" } }\n \"libraries\": {\n \"MyLib.sol:MyLib\": \"0x123123...\"\n },\n // ...\n // ...\n // ...\n // The rest of the fields and their defaults same as in std JSON input.\n },\n // Required: Compilation source files/source units, keys are file paths\n \"sources\": {\n \"settable\": {\n // Required (unless \"url\" is used): literal contents of the source file\n \"content\": \"contract settable is owned { uint256 private x = 0; function set(uint256 _x) public { if (msg.sender == owner) x = _x; } }\",\n // Required: keccak256 hash of the source file\n \"keccak256\": \"0x234...\"\n },\n \"myDirectory/myFile.sol\": {\n // Required: keccak256 hash of the source file\n \"keccak256\": \"0x123...\",\n // Optional: SPDX license identifier as given in the source file\n \"license\": \"MIT\",\n // Required (unless \"content\" is used, see above): Sorted URL(s)\n // to the source file, protocol is more or less arbitrary, but an\n // IPFS URL is recommended\n \"urls\": [ \"bzz-raw://7d7a...\", \"dweb:/ipfs/QmN...\" ]\n }\n },\n // Required: The version of the metadata format\n \"version\": 1\n}\n\nWarning\nSince the bytecode of the resulting contract contains the metadata hash by default, any\nchange to the metadata might result in a change of the bytecode. This includes\nchanges to a filename or path, and since the metadata includes a hash of all the\nsources used, a single whitespace change results in different metadata, and\ndifferent bytecode.\n\nNote\nThe ABI definition above has no fixed order. It can change with compiler versions.\nStarting from Solidity version 0.5.12, though, the array maintains a certain\norder.\n\nEncoding of the Metadata Hash in the Bytecode\nThe compiler currently by default appends the\nIPFS hash (in CID v0)\nof the canonical metadata file and the compiler version to the end of the bytecode.\nOptionally, a Swarm hash instead of the IPFS, or an experimental flag is used.\nBelow are all the possible fields:\n{\n \"ipfs\": \"<metadata hash>\",\n // If \"bytecodeHash\" was \"bzzr1\" in compiler settings not \"ipfs\" but \"bzzr1\"\n \"bzzr1\": \"<metadata hash>\",\n // Previous versions were using \"bzzr0\" instead of \"bzzr1\"\n \"bzzr0\": \"<metadata hash>\",\n // If any experimental features that affect code generation are used\n \"experimental\": true,\n \"solc\": \"<compiler version>\"\n}\n\nBecause we might support other ways to retrieve the\nmetadata file in the future, this information is stored\nCBOR-encoded. The last two bytes in the bytecode\nindicate the length of the CBOR encoded information. By looking at this length, the\nrelevant part of the bytecode can be decoded with a CBOR decoder.\nCheck the Metadata Playground to see it in action.\nWhereas release builds of solc use a 3 byte encoding of the version as shown\nabove (one byte each for major, minor and patch version number), pre-release builds\nwill instead use a complete version string including commit hash and build date.\nThe commandline flag --no-cbor-metadata can be used to skip metadata\nfrom getting appended at the end of the deployed bytecode. Equivalently, the\nboolean field settings.metadata.appendCBOR in Standard JSON input can be set to false.\n\nNote\nThe CBOR mapping can also contain other keys, so it is better to fully\ndecode the data by looking at the end of the bytecode for the CBOR length,\nand to use a proper CBOR parser. Do not rely on it starting with 0xa264\nor 0xa2 0x64 'i' 'p' 'f' 's'.\n\nUsage for Automatic Interface Generation and NatSpec\nThe metadata is used in the following way: A component that wants to interact\nwith a contract (e.g. a wallet) retrieves the code of the contract.\nIt decodes the CBOR encoded section containing the IPFS/Swarm hash of the\nmetadata file. With that hash, the metadata file is retrieved. That file\nis JSON-decoded into a structure like above.\nThe component can then use the ABI to automatically generate a rudimentary\nuser interface for the contract.\nFurthermore, the wallet can use the NatSpec user documentation to display a\nhuman-readable confirmation message to the user whenever they interact with\nthe contract, together with requesting authorization for the transaction signature.\nFor additional information, read Ethereum Natural Language Specification (NatSpec) format.\n\nUsage for Source Code Verification\nIf pinned/published, it is possible to retrieve the metadata of the contract from IPFS/Swarm.\nThe metadata file also contains the URLs or the IPFS hashes of the source files, as well as\nthe compilation settings, i.e. everything needed to reproduce a compilation.\nWith this information it is then possible to verify the source code of a contract by\nreproducing the compilation, and comparing the bytecode from the compilation with\nthe bytecode of the deployed contract.\nThis automatically verifies the metadata since its hash is part of the bytecode, as well\nas the source codes, because their hashes are part of the metadata. Any change in the files\nor settings would result in a different metadata hash. The metadata here serves\nas a fingerprint of the whole compilation.\nSourcify makes use of this feature for “full/perfect verification”,\nas well as pinning the files publicly on IPFS to be accessed with the metadata hash.","tokens":2640,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266633099,"hash":"b5742d290a64ee2ad228cd7c3a635ef5d2af996f"}
{"url":"https://docs.optimism.io/node-operators/reference/op-reth-historical-proof-config","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This page documents the configuration options for the historical proof store (v2) in op-reth.\nWhen enabled, op-reth maintains a separate storage database for versioned trie data used to serve eth_getProof for historical blocks. This is critical for historical state access (for example, fault proof workloads) without requiring full archive-style behavior from the execution database.\nop-reth v2.2.3 or later is required to enable historical proofs v2. Earlier versions do not support the --proofs-history.storage-version=v2 flag.\nUse the historical proofs storage format v2 by setting --proofs-history.storage-version=v2.\nFor a complete setup guide, see the tutorial on Running op-reth with Historical Proofs.\nThis fork inherits all standard op-reth configuration options. See the op-reth configuration reference.\n​Historical proof store (v2)\nOptions for configuring the v2 historical proof store.\n​proofs-history\nIf true, enable the historical proof store and keep it updated as new blocks are processed.\n Syntax--proofs-history\n​proofs-history.storage-version\nStorage format version for the historical proofs database.\nFor the v2 system, set this to v2.\n Syntax Recommended--proofs-history.storage-version <PROOFS_HISTORY_STORAGE_VERSION>v2\n​proofs-history.storage-path\nThe path to the storage DB for proofs history.\n Syntax--proofs-history.storage-path <PROOFS_HISTORY_STORAGE_PATH>\n​proofs-history.window\nThe window to span blocks for proofs history. Value is the number of blocks.\nDefault is 1 month of blocks based on 2 seconds block time (30 * 24 * 60 * 60 / 2 = 1,296,000).\n Syntax Default--proofs-history.window <PROOFS_HISTORY_WINDOW>1296000\n​proofs-history.verification-interval\nVerification interval: perform full block execution every N blocks for data integrity.\n\n0: Disabled (Default). Always use fast path with pre-computed data.\n1: Always verify. Always execute blocks.\nN: Verify every Nth block (e.g., 100 = every 100 blocks).\n\nPeriodic verification helps catch data corruption while maintaining good performance.\n Syntax Default--proofs-history.verification-interval <PROOFS_HISTORY_VERIFICATION_INTERVAL>0\n​Lifecycle and management commands\nIn v2, operators usually follow this lifecycle:\n\nRun op-reth proofs init once to initialize the proofs DB at the current tip.\nStart op-reth with --proofs-history --proofs-history.storage-version=v2 so the node uses historical proofs storage format v2.\nLet the store fill proofs data forward from the initialization point.\nLet automatic pruning enforce the configured retention window.\nUse manual prune or unwind only for recovery/maintenance scenarios.\n\nThe op-reth proofs command provides these maintenance operations.\n​init\nInitialize the proofs storage with the current state of the chain.\nop-reth proofs init --chain <CHAIN> --datadir <DATA_DIR> --proofs-history.storage-path <PROOFS_HISTORY_STORAGE_PATH> --proofs-history.storage-version=v2\n\nThe first time proofs init runs, it can take minutes to hours. Subsequent invocations should usually take seconds.proofs init does not backfill historical proofs. It records the current chain tip as the starting point of the proofs database. After initialization, run the node with --proofs-history so the store fills forward as new blocks are committed.To serve proofs across the full retention window (for example, 30 days with default settings), the node must accumulate that much forward history after init. In practice, operators should initialize from a snapshot that is already old enough to satisfy the required historical window as syncing advances.\n​prune\nPrune old proof history to reclaim space.\nop-reth proofs prune --chain <CHAIN> --datadir <DATA_DIR> --proofs-history.storage-path <PROOFS_HISTORY_STORAGE_PATH> --proofs-history.window <PROOFS_HISTORY_WINDOW>\n\nPruning runs automatically while the node is up, driven by the engine task as new blocks are committed; no separate interval flag is required.Manual prune is mainly a recovery action, for example if op-reth detects a large mismatch between configured retention and on-disk data and refuses startup. See the tutorial for details.\n​unwind\nUnwind the proofs storage to a specific block\nop-reth proofs unwind --datadir <DATA_DIR> --proofs-history.storage-path <PROOFS_HISTORY_STORAGE_PATH> --target <TARGET_BLOCK>\n\n​RPC Endpoints\n​debug_proofsSyncStatus\nReturns the current sync status of the proofs store.\ndebug_proofsSyncStatus → { \"earliest\": <block>, \"latest\": <block> }\n\nearliest and latest define the currently available historical-proof interval in the v2 store.\nOnce latest tracks chain tip, eth_getProof calls for blocks within [earliest, latest] are served from the versioned proofs store.\n​v1 to v2 operator notes\n\nThe historical-proof path is now centered on a dedicated versioned proofs store lifecycle (init -> forward fill -> prune), rather than treating it as a standalone extension workflow.\nproofs init establishes a starting point only; it does not reconstruct old proofs data.\nCoverage is operationally measured via debug_proofsSyncStatus (earliest/latest).\nFor stable long-window proof serving, validate startup snapshots and retention settings together.\n\n​Metrics\nWhen the metrics feature is enabled, the proofs-history system exposes Prometheus metrics to monitor health and performance.\n​Block processing (optimism_trie.block.*)\nMetricTypeDescriptiontotal_duration_secondsHistogramEnd-to-end time to process a blockexecution_duration_secondsHistogramTime spent in EVM executionstate_root_duration_secondsHistogramTime spent calculating state rootwrite_duration_secondsHistogramTime spent writing trie updates to storageaccount_trie_updates_written_totalCounterNumber of account trie branch nodes writtenstorage_trie_updates_written_totalCounterNumber of storage trie branch nodes writtenhashed_accounts_written_totalCounterNumber of hashed account entries writtenhashed_storages_written_totalCounterNumber of hashed storage entries writtenearliest_numberGaugeEarliest block number in the proofs storelatest_numberGaugeLatest block number in the proofs store\n​Pruner (optimism_trie.pruner.*)\nMetricTypeDescriptiontotal_duration_secondsHistogramDuration of each prune runpruned_blocksGaugeNumber of blocks pruned in the last runaccount_trie_updates_writtenGaugeAccount trie entries deleted in the last prunestorage_trie_updates_writtenGaugeStorage trie entries deleted in the last prunehashed_accounts_writtenGaugeHashed account entries deleted in the last prunehashed_storages_writtenGaugeHashed storage entries deleted in the last prune\n​RPC (optimism_rpc.eth_api_ext.*)\nMetricTypeDescriptionget_proof_latencyHistogramLatency of successful eth_getProof requestsget_proof_requestsCounterTotal eth_getProof requests receivedget_proof_successful_responsesCounterTotal successful eth_getProof responsesget_proof_failuresCounterTotal failed eth_getProof requests\n​Storage operations (optimism_trie.storage.operation.*)\nPer-operation duration_seconds histograms are recorded for: store_account_branch, store_storage_branch, store_hashed_account, store_hashed_storage, trie_cursor_seek_exact, trie_cursor_seek, trie_cursor_next, trie_cursor_current, hashed_cursor_seek, hashed_cursor_next.Was this page helpful?","tokens":1802,"squid":"ink-governance","role":"Council Listener","at":1791266639785,"hash":"c47ee70aea0ccd39e505ae4d0ff87488e56187d6"}
{"url":"https://forum.pyth.network/","domain":"forum.pyth.network","title":"Pyth DAO","text":"All categories\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Top\n\n About the Pyth DAO\n\n Discover everything you need to know about the Pyth DAO and how to use this forum.\n\n Pythian Council\n\n The Pythian Council is in charge of approving oracle program updates or changes to the data request fees.\n\n Price Feed Council\n\n The Price Feed Council is in charge of selecting the price feeds available on the network as well as the selection of data publishers for the existing feeds.\n\n Community Council\n\n Community Council is in charge of incentives, grants and growth programs from within the Pyth Community.\n\n Proposals\n\n The Proposals Category is for Pyth community members to propose changes to the Pyth Network or Pyth DAO, and reach consensus before moving to a formal vote.\n\n Ideas Bank\n\n The Ideas Bank is for Pyth community members to suggest, discuss, and debate early-stage ideas before the proposal stage.\n\n PYTH Reserves\n\n The PYTH Reserves category is for the Pythian Council to report on the execution of the PYTH token purchases as approved by the Pyth DAO with the OP-PIP-86.\n\n Pyth Pro\n\n The Pyth Pro category is for Pyth community members to suggest, discuss, and debate early-stage ideas regarding Pyth Pro before the proposal stage.\n\n Marketplace Onboardings\n\n Official notices for Pyth Data Marketplace provider onboardings, per CO-PIP-99.\n\n Oracle Integrity Staking (OIS)\n\n The OIS Category is for Pyth community members to suggest, discuss, and debate early-stage ideas regarding Oracle Integrity Staking before the proposal stage.\n\n Market Abuse Regulation Disclaimer\n\n Uncategorized\n\n Community Library\n\n The Pyth Community Library is where Pythians publish research, analysis, explainers, and comparisons about oracle infrastructure, financial data markets, and the Pyth ecosystem.","tokens":450,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266643405,"hash":"e4230358e3af44883c643b9a635934b7a476af0b"}
{"url":"https://docs.optimism.io/node-operators/reference/op-node-config","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This page catalogues every configuration option for the op-node, the consensus-layer\n(rollup node) client of an OP Stack chain.\nThe flag tables below are generated directly from the op-node's flag definitions in the monorepo (op-node/flags) at the release tag named in the provenance line, and are regenerated when a new finalized release is published, so they cannot silently fall behind. Every flag can also be set through the environment variable listed next to it.\nFor guidance on running a node — hardware, sync strategies, and monitoring —\nsee the node operator guides.\n​Flags\nGenerated from op-node/v1.19.3\nflag definitions. 109 flags: 3 required, 106 optional.\n​Required flags\nFlagDescriptionEnvironment variable--l1Address of L1 User JSON-RPC endpoint to use (eth namespace required)OP_NODE_L1_ETH_RPC--l2Address of L2 Engine JSON-RPC endpoints to use (engine and eth namespace required)OP_NODE_L2_ENGINE_RPC--l2.jwt-secretPath to JWT secret key. Keys are 32 bytes, hex encoded in a file. A new key will be generated if the file is empty.OP_NODE_L2_ENGINE_AUTH\n​Optional flags\nFlagDescriptionDefaultEnvironment variable--altda.da-serverHTTP address of a DA Server—OP_NODE_ALTDA_DA_SERVER--altda.da-serviceUse DA service type where commitments are generated by Alt-DA serverfalseOP_NODE_ALTDA_DA_SERVICE--altda.enabledEnable Alt-DA mode Alt-DA Mode is a Beta feature of the MIT licensed OP Stack. While it has received initial review from core contributors, it is still undergoing testing, and may have bugs or other issues.falseOP_NODE_ALTDA_ENABLED--altda.get-timeoutTimeout for get requests. 0 means no timeout.0sOP_NODE_ALTDA_GET_TIMEOUT--altda.max-concurrent-da-requestsMaximum number of concurrent requests to the DA server1OP_NODE_ALTDA_MAX_CONCURRENT_DA_REQUESTS--altda.put-timeoutTimeout for put requests. 0 means no timeout.0sOP_NODE_ALTDA_PUT_TIMEOUT--altda.verify-on-readVerify input data matches the commitments from the DA storage servicetrueOP_NODE_ALTDA_VERIFY_ON_READ--conductor.enabledEnable the conductor servicefalseOP_NODE_CONDUCTOR_ENABLED--conductor.rpcConductor service rpc endpoint\"http://127.0.0.1:8547\"OP_NODE_CONDUCTOR_RPC--conductor.rpc-timeoutConductor service rpc timeout1sOP_NODE_CONDUCTOR_RPC_TIMEOUT--experimental.sequencer-apiEnables experimental test sequencer RPC functionalityfalseOP_NODE_EXPERIMENTAL_SEQUENCER_API--fetch-withdrawal-root-from-stateRead withdrawal_storage_root (aka message passer storage root) from state trie (via execution layer) instead of the block header. Restores pre-Isthmus behavior, requires an archive EL client.falseOP_NODE_FETCH_WITHDRAWAL_ROOT_FROM_STATE--finality.delayNumber of L1 blocks to traverse before trying to finalize L2 blocks again. Uses default (64) if 0.0OP_NODE_FINALITY_DELAY--finality.lookbackNumber of L1 blocks to look back for finality verification. Uses default calculation if 0 (considers alt-DA challenge/resolve windows if applicable).0OP_NODE_FINALITY_LOOKBACK--interop.dependency-setDependency-set configuration, point at JSON file.—OP_NODE_INTEROP_DEPENDENCY_SET--l1.beaconAddress of L1 Beacon-node HTTP endpoint to use.—OP_NODE_L1_BEACON--l1.beacon-fallbacksAddresses of L1 Beacon-API compatible HTTP fallback endpoints. Used to fetch blob sidecars not available at the l1.beacon (e.g. expired blobs).—OP_NODE_L1_BEACON_FALLBACKS--l1.beacon-headerOptional HTTP header to add to all requests to the L1 Beacon endpoint. Format: ‘X-Key: Value’—OP_NODE_L1_BEACON_HEADER--l1.beacon.fetch-all-sidecarsIf true, all sidecars are fetched and filtered locally. Workaround for buggy Beacon nodes.falseOP_NODE_L1_BEACON_FETCH_ALL_SIDECARS--l1.beacon.ignoreWhen false, halts op-node startup if the healthcheck to the Beacon-node endpoint fails.falseOP_NODE_L1_BEACON_IGNORE--l1.beacon.slot-duration-overrideDuration in seconds of an L1 slot. When set (non-zero), bypasses the beacon /eth/v1/config/spec fetch and uses this value as SECONDS_PER_SLOT. Useful for devnets where the beacon spec endpoint is unavailable (e.g. anvil).0OP_NODE_L1_BEACON_SLOT_DURATION_OVERRIDE--l1.cache-sizeCache size for blocks, receipts and transactions. If this flag is set to 0, 3/2 of the sequencing window size is used (usually 2400). The default value of 900 (~3h of L1 blocks) is good for (high-throughput) networks that see frequent safe head increments. On (low-throughput) networks with infrequent safe head increments, it is recommended to set this value to 0, or a value that well covers the typical span between safe head increments. Note that higher values will cause significantly increased memory usage.900OP_NODE_L1_CACHE_SIZE--l1.epoch-poll-intervalPoll interval for retrieving new L1 epoch updates such as safe and finalized block changes. Disabled if 0 or negative.6m24sOP_NODE_L1_EPOCH_POLL_INTERVAL--l1.http-poll-intervalPolling interval for latest-block subscription when using an HTTP RPC provider. Ignored for other types of RPC endpoints.12sOP_NODE_L1_HTTP_POLL_INTERVAL--l1.max-concurrencyMaximum number of concurrent RPC requests to make to the L1 RPC provider.10OP_NODE_L1_MAX_CONCURRENCY--l1.rpc-max-batch-sizeMaximum number of RPC requests to bundle, e.g. during L1 blocks receipt fetching. The L1 RPC rate limit counts this as N items, but allows it to burst at once.20OP_NODE_L1_RPC_MAX_BATCH_SIZE--l1.rpc-rate-limitOptional self-imposed global rate-limit on L1 RPC requests, specified in requests / second. Disabled if set to 0.0OP_NODE_L1_RPC_RATE_LIMIT--l1.rpckindThe kind of RPC provider, used to inform optimal transactions receipts fetching, and thus reduce costs. Valid options: alchemy, quicknode, infura, parity, nethermind, debug_geth, erigon, basic, any, standardstandardOP_NODE_L1_RPC_KIND--l1.runtime-config-reload-intervalPoll interval for reloading the runtime config, useful when config events are not being picked up. Disabled if 0 or negative.10m0sOP_NODE_L1_RUNTIME_CONFIG_RELOAD_INTERVAL--l1.trustrpcTrust the L1 RPC, sync faster at risk of malicious/buggy RPC providing bad or inconsistent L1 datafalseOP_NODE_L1_TRUST_RPC--l2.engine-rpc-timeoutL2 engine client rpc timeout10sOP_NODE_L2_ENGINE_RPC_TIMEOUT--l2.enginekindThe kind of engine client, used to control the behavior of optimism in respect to different types of engine clients. Valid options: geth, reth, erigonrethOP_NODE_L2_ENGINE_KIND--l2.follow.sourceAddress of L2 CL RPC HTTP endpoint to follow source—OP_NODE_L2_FOLLOW_SOURCE--log.colorColor the log output if in terminal modefalseOP_NODE_LOG_COLOR--log.formatFormat the log output. Supported formats: text, terminal, logfmt, logfmtms, json, jsonmstextOP_NODE_LOG_FORMAT--log.levelThe lowest log level that will be outputINFOOP_NODE_LOG_LEVEL--log.pidShow pid in the logfalseOP_NODE_LOG_PID--metrics.addrMetrics listening address\"0.0.0.0\"OP_NODE_METRICS_ADDR--metrics.enabledEnable the metrics serverfalseOP_NODE_METRICS_ENABLED--metrics.portMetrics listening port7300OP_NODE_METRICS_PORT--networkPredefined network selection. Available networks: every chain bundled from the superchain-registry at the release; run op-node --help for the exact list—OP_NODE_NETWORK--override.canyonManually specify the canyon fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_CANYON--override.deltaManually specify the delta fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_DELTA--override.ecotoneManually specify the ecotone fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_ECOTONE--override.fjordManually specify the fjord fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_FJORD--override.graniteManually specify the granite fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_GRANITE--override.holoceneManually specify the holocene fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_HOLOCENE--override.isthmusManually specify the isthmus fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_ISTHMUS--override.jovianManually specify the jovian fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_JOVIAN--override.karstManually specify the karst fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_KARST--override.keep-karst-upgrade-gasManually set keep_karst_upgrade_gas, overriding the bundled setting. When true, the Karst activation block’s one-time upgrade gas is kept on every later block (for chains that activated Karst with the leak baked into their history).falseOP_NODE_OVERRIDE_KEEP_KARST_UPGRADE_GAS--override.lagoonManually specify the lagoon fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_LAGOON--override.pectrablobscheduleManually specify the pectrablobschedule fork timestamp, overriding the bundled setting0OP_NODE_OVERRIDE_PECTRABLOBSCHEDULE--p2p.advertise.ipThe IP address to advertise in Discv5, put into the ENR of the node. This may also be a hostname / domain name to resolve to an IP.—OP_NODE_P2P_ADVERTISE_IP--p2p.advertise.tcpThe TCP port to advertise in Discv5, put into the ENR of the node. Set to p2p.listen.tcp value if 0.0OP_NODE_P2P_ADVERTISE_TCP--p2p.advertise.udpThe UDP port to advertise in Discv5 as fallback if not determined by Discv5, put into the ENR of the node. Set to p2p.listen.udp value if 0.0OP_NODE_P2P_ADVERTISE_UDP--p2p.ban.durationThe duration that peers are banned for.1h0m0sOP_NODE_P2P_PEER_BANNING_DURATION--p2p.ban.peersEnables peer banning.trueOP_NODE_P2P_PEER_BANNING--p2p.ban.thresholdThe minimum score below which peers are disconnected and banned.-100OP_NODE_P2P_PEER_BANNING_THRESHOLD--p2p.bootnodesComma-separated base64-format ENR list. Bootnodes to start discovering other node records from.—OP_NODE_P2P_BOOTNODES--p2p.disableCompletely disable the P2P stackfalseOP_NODE_P2P_DISABLE--p2p.discovery.pathDiscovered ENRs are persisted in a database to recover from a restart without having to bootstrap the discovery process again. Set to ‘memory’ to never persist the peerstore.\"opnode_discovery_db\"OP_NODE_P2P_DISCOVERY_PATH--p2p.gossip.timestamp.thresholdThreshold for rejecting gossip messages with payload timestamps older than this duration. Default is 60 seconds.1m0sOP_NODE_P2P_GOSSIP_TIMESTAMP_THRESHOLD--p2p.listen.ipIP to bind LibP2P and Discv5 to\"0.0.0.0\"OP_NODE_P2P_LISTEN_IP--p2p.listen.tcpTCP port to bind LibP2P to. Any available system port if set to 0.9222OP_NODE_P2P_LISTEN_TCP_PORT--p2p.listen.udpUDP port to bind Discv5 to. Same as TCP port if left 0.0OP_NODE_P2P_LISTEN_UDP_PORT--p2p.natEnable NAT traversal with PMP/UPNP devices to learn external IP.falseOP_NODE_P2P_NAT--p2p.netrestrictComma-separated list of CIDR masks. P2P will only try to connect on these networks—OP_NODE_P2P_NETRESTRICT--p2p.no-discoveryDisable Discv5 (node discovery)falseOP_NODE_P2P_NO_DISCOVERY--p2p.peers.graceGrace period to keep a newly connected peer around, if it is not misbehaving.30sOP_NODE_P2P_PEERS_GRACE--p2p.peers.hiHigh-tide peer count. The node starts pruning peer connections slowly after reaching this number.30OP_NODE_P2P_PEERS_HI--p2p.peers.loLow-tide peer count. The node actively searches for new peer connections if below this amount.20OP_NODE_P2P_PEERS_LO--p2p.peerstore.pathPeerstore database location. Persisted peerstores help recover peers after restarts. Set to ‘memory’ to never persist the peerstore. Peerstore records will be pruned / expire as necessary. Warning: a copy of the priv network key of the local peer will be persisted here.\"opnode_peerstore_db\"OP_NODE_P2P_PEERSTORE_PATH--p2p.priv.pathRead the hex-encoded 32-byte private key for the peer ID from this txt file. Created if not already exists.Important to persist to keep the same network identity after restarting, maintaining the previous advertised identity.\"opnode_p2p_priv.txt\"OP_NODE_P2P_PRIV_PATH--p2p.scoringSets the peer scoring strategy for the P2P stack. Can be one of: none or light.\"light\"OP_NODE_P2P_PEER_SCORING--p2p.sequencer.keyHex-encoded private key for signing off on p2p application messages as sequencer.—OP_NODE_P2P_SEQUENCER_KEY--p2p.staticComma-separated multiaddr-format peer list. Static connections to make and maintain, these peers will be regarded as trusted. Addresses of the local peer are ignored. Duplicate/Alternative addresses for the same peer all apply, but only a single connection per peer is maintained.—OP_NODE_P2P_STATIC--p2p.sync.req-respEnables the P2P req-resp sync server, which serves payloads-by-number to peers that request them. The client side has been removed; the server will be deprecated in a future release in favor of EL P2P sync.trueOP_NODE_P2P_SYNC_REQ_RESP--pprof.addrpprof listening address\"0.0.0.0\"OP_NODE_PPROF_ADDR--pprof.enabledEnable the pprof serverfalseOP_NODE_PPROF_ENABLED--pprof.pathpprof file path. If it is a directory, the path is {dir}/{profileType}.prof—OP_NODE_PPROF_PATH--pprof.portpprof listening port6060OP_NODE_PPROF_PORT--pprof.typepprof profile type. One of cpu, heap, goroutine, threadcreate, block, mutex, allocs—OP_NODE_PPROF_TYPE--rollup.configRollup chain parameters—OP_NODE_ROLLUP_CONFIG--rollup.l1-chain-configPath to .json file with the chain configuration for the L1, either in the direct format or genesis.json format (i.e. embedded under the .config property). Not necessary / will be ignored if using Ethereum mainnet or Sepolia as an L1.—OP_NODE_ROLLUP_L1_CHAIN_CONFIG--rpc.addrrpc listening address\"0.0.0.0\"OP_NODE_RPC_ADDR--rpc.admin-stateFile path used to persist state changes made via the admin API so they persist across restarts. Disabled if not set.—OP_NODE_RPC_ADMIN_STATE--rpc.enable-adminEnable the admin APIfalseOP_NODE_RPC_ENABLE_ADMIN--rpc.portrpc listening port9545OP_NODE_RPC_PORT--safedb.pathFile path used to persist safe head update data. Disabled if not set.—OP_NODE_SAFEDB_PATH--sequencer.enabledEnable sequencing of new L2 blocks. A separate batch submitter has to be deployed to publish the data for verifiers.falseOP_NODE_SEQUENCER_ENABLED--sequencer.l1-confsNumber of L1 blocks to keep distance from the L1 head as a sequencer for picking an L1 origin.4OP_NODE_SEQUENCER_L1_CONFS--sequencer.max-safe-lagMaximum number of L2 blocks for restricting the distance between L2 safe and unsafe. Disabled if 0.0OP_NODE_SEQUENCER_MAX_SAFE_LAG--sequencer.recoverForces the sequencer to strictly prepare the next L1 origin and create empty L2 blocksfalseOP_NODE_SEQUENCER_RECOVER--sequencer.sealing-durationThis is the amount of the time the sequencer allocates to sealing the block (i.e. it will fetch the payload from the execution engine this much prior to the block’s timestamp). If this is <= 0 it is automatically adjusted to 50ms.50msOP_NODE_SEQUENCER_SEALING_DURATION--sequencer.stoppedInitialize the sequencer in a stopped state. The sequencer can be started using the admin_startSequencer RPCfalseOP_NODE_SEQUENCER_STOPPED--signer.addressAddress the signer is signing requests for—OP_NODE_SIGNER_ADDRESS--signer.endpointSigner endpoint the client will connect to—OP_NODE_SIGNER_ENDPOINT--signer.headerHeaders to pass to the remote signer. Format key=value. Value can contain any character allowed in a HTTP header. When using env vars, split with commas. When using flags one key value pair per flag.—OP_NODE_SIGNER_HEADER--signer.tls.catls ca cert path\"tls/ca.crt\"OP_NODE_SIGNER_TLS_CA--signer.tls.certtls cert path\"tls/tls.crt\"OP_NODE_SIGNER_TLS_CERT--signer.tls.enabledEnable or disable TLS client authentication for the signertrueOP_NODE_SIGNER_TLS_ENABLED--signer.tls.keytls key\"tls/tls.key\"OP_NODE_SIGNER_TLS_KEY--syncmodeBlockchain sync mode (options: consensus-layer, execution-layer)consensus-layerOP_NODE_SYNCMODE--syncmode.offset-el-safeAfter execution-layer sync completes, set safe and finalized heads to this duration behind the synced tip (converted to L2 blocks via rollup block time using ceiling division). Default 12h, matching the OP Mainnet sequencing window.12h0m0sOP_NODE_SYNCMODE_OFFSET_EL_SAFE--verifier.l1-confsNumber of L1 blocks to keep distance from the L1 head before deriving L2 data from. Reorgs are supported, but may be slow to perform.0OP_NODE_VERIFIER_L1_CONFS\n​Notes on selected flags\n​network and rollup.config\nIn addition to the required flags above, the op-node must be told which chain\nit serves: set exactly one of --network (a chain bundled from the\nsuperchain-registry, e.g. op-mainnet) or --rollup.config (a rollup\nconfiguration file, for custom chains). Setting both, or neither, is a startup\nerror.\n​l1.trustrpc\nIf you’re running an Erigon Ethereum execution client for your L1 provider\nyou will need to include --l1.trustrpc. At the time of writing, Erigon\ndoesn’t support the eth_getProof method that op-node prefers to use to\nload L1 data for some processing. The trustrpc flag makes it use something\nelse that Erigon supports, but the op-node can’t verify for correctness.\n​syncmode.offset-el-safe\nOnly effective with --syncmode=execution-layer. After execution-layer sync\ncompletes, the safe and finalized heads are set to this duration behind the\nsynced tip (converted to L2 blocks using the rollup block time). The default\n12h matches the OP Mainnet sequencing window.\nSetting this to 0 leaves safe and finalized at the synced tip. This is\nnot recommended and is dangerous: the offset ensures the node does not\nlabel the EL-sync tip as safe/finalized until L1 has had time to confirm it.\nWith 0, an EL-sync tip that later turns out to be on a reorged\n(non-canonical) branch can be marked safe/finalized, and safe/finalized are\nnot supposed to reorg. Fix a body-pruning mismatch by enlarging the EL’s\nretained body window instead — see the warning below.\nop-node reads the L1-info deposit transaction from the block body at the\nhead placed this far behind the tip, so the execution client must retain\nblock bodies at least this far back. Body pruning (op-reth’s --minimal\nmode or --prune.bodies.distance) is unsupported; if you enable it anyway,\nkeep the retained body window comfortably larger than this offset (in\nblocks), or EL sync fails with l2 block is missing L1 info deposit tx.\nSee Pruning op-reth.\n​sequencer.l1-confs\nThe maximum value for sequencer.l1-confs cannot exceed the sequencer\ndrift, currently set to 30 minutes (1800 seconds or 150 blocks). Setting a\nvalue higher than this limit will prevent the sequencer from producing\nblocks within the sequence window.\n​verifier.l1-confs\nWhile verifier.l1-confs has no strict limit, it’s recommended to keep this\nvalue within 12-13 minutes (typically 10-20 blocks) for optimal performance.\nExceeding this range may impact the verifier’s data processing efficiency.\n​altda.*\nThe altda.* flags configure Alt-DA mode, a Beta feature of the OP Stack.\nWhile it has received initial review from core contributors, it is still\nundergoing testing, and may have bugs or other issues. See the\nAlt-DA mode guide for\nsetup instructions.\n​interop.*\nThe interop.* flags configure OP Stack interop networks. Interop is a highly\nexperimental feature; the flags apply only to interop-enabled networks. Do not\nenable the interop RPC (--interop.rpc.addr) if you do not run a supervisor\nservice.\n​version\nNodes built from source do not output the correct version numbers that are\nreported on the GitHub release page.\n​Node log levels\nNode log levels determine the verbosity of log messages, allowing operators to filter messages based on importance and detail. The log levels for the op-node (used in Optimism)\nare as follows:\n\nSilent (0): No log messages are displayed. This level is rarely used as it provides\nno feedback on the node’s status.\n\nError (1): Only error messages are displayed. Use this level to focus on critical\nissues that need immediate attention.\n\nWarn (2): Displays error messages and warnings. This level helps to identify\npotential problems that might not be immediately critical but require attention.\n\nInfo (3): Displays error messages, warnings, and normal activity logs. This is the\ndefault level and provides a balanced view of the node’s operations without being too\nverbose.\n\nDebug (4): All info-level messages plus additional debugging information. Use this\nlevel when troubleshooting issues or developing the node software.\n\nDetail (5): The most verbose level, including detailed debugging information and\nlow-level system operations. This level generates a large amount of log data and is\ntypically used only for in-depth troubleshooting.\n\nTo set the log level, use the --log.level flag when running the op-node command. For\nexample, to set the log level to debug:\nop-node --log.level=debug\n\nBy adjusting the log level, operators can control the amount and type of information that\ngets logged, helping to manage log data volume and focus on relevant details during\ndifferent operational scenarios.Was this page helpful?","tokens":5170,"squid":"ink-governance","role":"Council Listener","at":1791266650550,"hash":"24fe2f95247db7b1ac9f7e16f09305b71333722c"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/utilities","domain":"docs.openzeppelin.com","title":"Utilities | OpenZeppelin Docs","text":"OpenZeppelin ContractsUtilitiesOpen in ClaudeThe OpenZeppelin Contracts provide a ton of useful utilities that you can use in your project. For a complete list, check out the API Reference.\nHere are some of the more popular ones.\nCryptography\nChecking Signatures On-Chain\nAt a high level, signatures are a set of cryptographic algorithms that allow for a signer to prove himself as the owner of a private key used to authorize a piece of information (generally a transaction or UserOperation). Natively, the EVM supports the Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve, however other signature algorithms such as P256 and RSA are supported.\nEthereum Signatures (secp256k1)\nECDSA provides functions for recovering and managing Ethereum account ECDSA signatures. These are often generated via web3.eth.sign, and form a 65-byte array (of type bytes in Solidity) arranged the following way: [[v (1)], [r (32)], [s (32)]].\nThe data signer can be recovered with ECDSA.recover, and its address compared to verify the signature. Most wallets will hash the data to sign and add the prefix \\x19Ethereum Signed Message:\\n, so when attempting to recover the signer of an Ethereum signed message hash, you’ll want to use toEthSignedMessageHash.\nusing ECDSA for bytes32;\nusing MessageHashUtils for bytes32;\n\nfunction _verify(bytes32 data, bytes memory signature, address account) internal pure returns (bool) {\n return data\n .toEthSignedMessageHash()\n .recover(signature) == account;\n}\nGetting signature verification right is not trivial: make sure you fully read and understand MessageHashUtils's and ECDSA's documentation.\nP256 Signatures (secp256r1)\nP256, also known as secp256r1, is one of the most used signature schemes. P256 signatures are standardized by the National Institute of Standards and Technology (NIST) and they are widely available in consumer hardware and software.\nThese signatures are different from regular Ethereum Signatures (secp256k1) in that they use a different elliptic curve to perform operations but have similar security guarantees.\nusing P256 for bytes32;\n\nfunction _verify(\n bytes32 data,\n bytes32 r,\n bytes32 s,\n bytes32 qx,\n bytes32 qy\n) internal view returns (bool) {\n return data.verify(r, s, qx, qy);\n}\nBy default, the verify function will try calling the RIP-7212 precompile at address 0x100 and will fallback to an implementation in Solidity if not available. We encourage you to use verifyNative if you know the precompile is available on the chain you’re working on and on any other chain on which you intend to use the same bytecode in the future. In case of any doubts regarding the implementation roadmap of the native precompile P256 of potential future target chains, please consider using verifySolidity.\nusing P256 for bytes32;\n\nfunction _verify(\n bytes32 data,\n bytes32 r,\n bytes32 s,\n bytes32 qx,\n bytes32 qy\n) internal view returns (bool) {\n // Will only call the precompile at address(0x100)\n return data.verifyNative(r, s, qx, qy);\n}\nThe P256 library only allows for s values in the lower order of the curve (i.e. s <= N/2) to prevent malleability. In case your tooling produces signatures in both sides of the curve, consider flipping the s value to keep compatibility.\nRSA\nRSA is a public-key cryptosystem that was popularized by corporate and governmental public key infrastructures (PKIs) and DNSSEC.\nThis cryptosystem consists of using a private key that’s the product of 2 large prime numbers. The message is signed by applying a modular exponentiation to its hash (commonly SHA256), where both the exponent and modulus compose the public key of the signer.\nRSA signatures are known for being less efficient than elliptic curve signatures given the size of the keys, which are big compared to ECDSA keys with the same security level. Using plain RSA is considered unsafe, this is why the implementation uses the EMSA-PKCS1-v1_5 encoding method from RFC8017 to include padding to the signature.\nTo verify a signature using RSA, you can leverage the RSA library that exposes a method for verifying RSA with the PKCS 1.5 standard:\nusing RSA for bytes32;\n\nfunction _verify(\n bytes32 data,\n bytes memory signature,\n bytes memory e,\n bytes memory n\n) internal pure returns (bool) {\n return data.pkcs1Sha256(signature, e, n);\n}\nAlways use keys of at least 2048 bits. Additionally, be aware that PKCS#1 v1.5 allows for replayability due to the possibility of arbitrary optional parameters. To prevent replay attacks, consider including an onchain nonce or unique identifier in the message.\nSignature Verification\nThe SignatureChecker library provides a unified interface for verifying signatures from different sources. It seamlessly supports:\n\nECDSA signatures from externally owned accounts (EOAs)\nERC-1271 signatures from smart contract wallets like Argent and Safe Wallet\nERC-7913 signatures from keys that don’t have their own Ethereum address\n\nThis allows developers to write signature verification code once and have it work across all these different signature types.\nBasic Signature Verification\nFor standard signature verification that supports both EOAs and ERC-1271 contracts:\nusing SignatureChecker for address;\n\nfunction _verifySignature(address signer, bytes32 hash, bytes memory signature) internal view returns (bool) {\n return SignatureChecker.isValidSignatureNow(signer, hash, signature);\n}\nThe library automatically detects whether the signer is an EOA or a contract and uses the appropriate verification method.\nERC-1271 Contract Signatures\nFor smart contract wallets that implement ERC-1271, you can explicitly use:\nfunction _verifyContractSignature(address signer, bytes32 hash, bytes memory signature) internal view returns (bool) {\n return SignatureChecker.isValidERC1271SignatureNow(signer, hash, signature);\n}\nERC-7913 Extended Signatures\nERC-7913 extends signature verification to support keys that don’t have their own Ethereum address. This is useful for integrating non-Ethereum cryptographic curves, hardware devices, or other identity systems.\nA signer is represented as a bytes object that concatenates a verifier address and a key: verifier || key.\nfunction _verifyERC7913Signature(bytes memory signer, bytes32 hash, bytes memory signature) internal view returns (bool) {\n return SignatureChecker.isValidSignatureNow(signer, hash, signature);\n}\nThe verification process works as follows:\n\nIf signer.length < 20: verification fails\nIf signer.length == 20: verification is done using standard signature checking\nOtherwise: verification is done using an ERC-7913 verifier\n\nBatch Verification\nFor verifying multiple ERC-7913 signatures at once:\nfunction _verifyMultipleSignatures(\n bytes32 hash,\n bytes[] memory signers,\n bytes[] memory signatures\n) internal view returns (bool) {\n return SignatureChecker.areValidSignaturesNow(hash, signers, signatures);\n}\nThis function will reject inputs that contain duplicated signers. Sorting the signers by their keccak256 hash is recommended to minimize the gas cost.\nThis unified approach allows smart contracts to accept signatures from any supported source without needing to implement different verification logic for each type.\nVerifying Merkle Proofs\nDevelopers can build a Merkle Tree off-chain, which allows for verifying that an element (leaf) is part of a set by using a Merkle Proof. This technique is widely used for creating whitelists (e.g., for airdrops) and other advanced use cases.\nOpenZeppelin Contracts provides a JavaScript library for building trees off-chain and generating proofs.\nMerkleProof provides:\n\nverify - can prove that some value is part of a Merkle tree.\nmultiProofVerify - can prove multiple values are part of a Merkle tree.\n\nFor an on-chain Merkle Tree, see the MerkleTree library.\nIntrospection\nIn Solidity, it’s frequently helpful to know whether or not a contract supports an interface you’d like to use. ERC-165 is a standard that enables runtime interface detection. Contracts provide helpers both for implementing ERC-165 in your contracts and querying other contracts:\n\nIERC165 — this is the ERC-165 interface that defines supportsInterface. When implementing ERC-165, you’ll conform to this interface.\nERC165 — inherit this contract if you’d like to support interface detection using a lookup table in contract storage. You can register interfaces using _registerInterface(bytes4): check out example usage as part of the ERC-721 implementation.\nERC165Checker — ERC165Checker simplifies the process of checking whether or not a contract supports an interface you care about.\ninclude with using ERC165Checker for address;\nmyAddress._supportsInterface(bytes4)\nmyAddress._supportsAllInterfaces(bytes4[\\])\n\ncontract MyContract {\n using ERC165Checker for address;\n\n bytes4 private InterfaceId_ERC721 = 0x80ac58cd;\n\n /**\n * @dev transfer an ERC-721 token from this contract to someone else\n */\n function transferERC721(\n address token,\n address to,\n uint256 tokenId\n )\n public\n {\n require(token.supportsInterface(InterfaceId_ERC721), \"IS_NOT_721_TOKEN\");\n IERC721(token).transferFrom(address(this), to, tokenId);\n }\n}\nMath\nAlthough Solidity already provides math operators (i.e. +, -, etc.), Contracts includes Math; a set of utilities for dealing with mathematical operators, with support for extra operations (e.g., average) and SignedMath; a library specialized in signed math operations.\nInclude these contracts with using Math for uint256 or using SignedMath for int256 and then use their functions in your code:\ncontract MyContract {\n using Math for uint256;\n using SignedMath for int256;\n\n function tryOperations(uint256 a, uint256 b) internal pure {\n (bool succeededAdd, uint256 resultAdd) = x.tryAdd(y);\n (bool succeededSub, uint256 resultSub) = x.trySub(y);\n (bool succeededMul, uint256 resultMul) = x.tryMul(y);\n (bool succeededDiv, uint256 resultDiv) = x.tryDiv(y);\n // ...\n }\n\n function unsignedAverage(int256 a, int256 b) {\n int256 avg = a.average(b);\n // ...\n }\n}\nEasy!\nWhile working with different data types that might require casting, you can use SafeCast for type casting with added overflow checks.\nStructures\nSome use cases require more powerful data structures than the arrays and mappings offered natively in Solidity. These contracts provide libraries for enhanced data structure management:\n\nBitMaps: Store packed booleans in storage.\nCheckpoints: Checkpoint values with built-in lookups.\nDoubleEndedQueue: Store items in a queue with pop() and queue() constant time operations.\nEnumerableSet: A set with enumeration capabilities.\nEnumerableMap: A mapping variant with enumeration capabilities.\nMerkleTree: An on-chain Merkle Tree with helper functions.\nHeap: A binary heap to store elements with priority defined by a comparator function.\n\nThe Enumerable* structures are similar to mappings in that they store and remove elements in constant time and don’t allow for repeated entries, but they also support enumeration, which means you can easily query all stored entries both on and off-chain.\nBuilding a Merkle Tree\nBuilding an on-chain Merkle Tree allows developers to keep track of the history of roots in a decentralized manner. For these cases, the MerkleTree includes a predefined structure with functions to manipulate the tree (e.g. pushing values or resetting the tree).\nThe Merkle Tree does not keep track of the roots intentionally, so that developers can choose their tracking mechanism. Setting up and using a Merkle Tree in Solidity is as simple as follows:\nFunctions are exposed without access control for demonstration purposes\nusing MerkleTree for MerkleTree.Bytes32PushTree;\nMerkleTree.Bytes32PushTree private _tree;\n\nfunction setup(uint8 _depth, bytes32 _zero) public /* onlyOwner */ {\n root = _tree.setup(_depth, _zero);\n}\n\nfunction push(bytes32 leaf) public /* onlyOwner */ {\n (uint256 leafIndex, bytes32 currentRoot) = _tree.push(leaf);\n // Store the new root.\n}\nThe library also supports custom hashing functions, which can be passed as an extra parameter to the push and setup functions.\nUsing custom hashing functions is a sensitive operation. After setup, it requires continuing to use the same hashing function for every new value pushed to the tree to avoid corrupting the tree. For this reason, it’s a good practice to keep your hashing function static in your implementation contract as follows:\nusing MerkleTree for MerkleTree.Bytes32PushTree;\nMerkleTree.Bytes32PushTree private _tree;\n\nfunction setup(uint8 _depth, bytes32 _zero) public /* onlyOwner */ {\n root = _tree.setup(_depth, _zero, _hashFn);\n}\n\nfunction push(bytes32 leaf) public /* onlyOwner */ {\n (uint256 leafIndex, bytes32 currentRoot) = _tree.push(leaf, _hashFn);\n // Store the new root.\n}\n\nfunction _hashFn(bytes32 a, bytes32 b) internal view returns(bytes32) {\n // Custom hash function implementation\n // Kept as an internal implementation detail to\n // guarantee the same function is always used\n}\nUsing a Heap\nA binary heap is a data structure that always stores the most important element at its peak and it can be used as a priority queue.\nTo define what is most important in a heap, these frequently take comparator functions that tell the binary heap whether a value has more relevance than another.\nOpenZeppelin Contracts implements a Heap data structure with the properties of a binary heap. The heap uses the lt function by default but allows to customize its comparator.\nWhen using a custom comparator, it’s recommended to wrap your function to avoid the possibility of mistakenly using a different comparator function:\nfunction pop(Uint256Heap storage self) internal returns (uint256) {\n return pop(self, Comparators.gt);\n}\n\nfunction insert(Uint256Heap storage self, uint256 value) internal {\n insert(self, value, Comparators.gt);\n}\n\nfunction replace(Uint256Heap storage self, uint256 newValue) internal returns (uint256) {\n return replace(self, newValue, Comparators.gt);\n}\nMisc\nPacking\nThe storage in the EVM is shaped in chunks of 32 bytes, each of these chunks is known as a slot, and can hold multiple values together as long as these values don’t exceed 32 bytes. This property allows for a technique known as packing--placing values together in a single storage slot to reduce the costs associated with reading and writing these values.\nCommonly, developers pack values using structs that place values together so they fit better in storage. However, this approach requires loading such struct from either calldata or memory. Although sometimes necessary, it may be useful to pack values in a single slot and treat it as a packed value without involving calldata or memory.\nThe Packing library is a set of utilities for packing values that fit in 32 bytes. The library includes 3 main functionalities:\n\nPacking 2 bytesXX values\nExtracting a packed bytesXX value from a bytesYY\nReplacing a packed bytesXX value from a bytesYY\n\nWith these primitives, one can build custom functions to create custom packed types. For example, suppose you need to pack an address of 20 bytes with a bytes4 selector and an uint64 time period:\nfunction _pack(address account, bytes4 selector, uint64 period) external pure returns (bytes32) {\n bytes12 subpack = Packing.pack_4_8(selector, bytes8(period));\n return Packing.pack_20_12(bytes20(account), subpack);\n}\n\nfunction _unpack(bytes32 pack) external pure returns (address, bytes4, uint64) {\n return (\n address(Packing.extract_32_20(pack, 0)),\n Packing.extract_32_4(pack, 20),\n uint64(Packing.extract_32_8(pack, 24))\n );\n}\nStorage Slots\nSolidity allocates a storage pointer for each variable declared in a contract. However, there are cases when it’s required to access storage pointers that can’t be derived by using regular Solidity.\nFor those cases, the StorageSlot library allows for manipulating storage slots directly.\nbytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;\n\nfunction _getImplementation() internal view returns (address) {\n return StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value;\n}\n\nfunction _setImplementation(address newImplementation) internal {\n require(newImplementation.code.length > 0);\n StorageSlot.getAddressSlot(_IMPLEMENTATION_SLOT).value = newImplementation;\n}\nThe TransientSlot library supports transient storage through user defined value types (UDVTs), which enables the same value types as in Solidity.\nbytes32 internal constant _LOCK_SLOT = 0xf4678858b2b588224636b8522b729e7722d32fc491da849ed75b3fdf3c84f542;\n\nfunction _getTransientLock() internal view returns (bool) {\n return _LOCK_SLOT.asBoolean().tload();\n}\n\nfunction _setTransientLock(bool lock) internal {\n _LOCK_SLOT.asBoolean().tstore(lock);\n}\nManipulating storage slots directly is an advanced practice. Developers MUST make sure that the storage pointer is not colliding with other variables.\nOne of the most common use cases for writing directly to storage slots is ERC-7201 for namespaced storage, which is guaranteed to not collide with other storage slots derived by Solidity.\nUsers can leverage this standard using the SlotDerivation library.\nusing SlotDerivation for bytes32;\nstring private constant _NAMESPACE = \"<namespace>\" // eg. example.main\n\nfunction erc7201Pointer() internal view returns (bytes32) {\n return _NAMESPACE.erc7201Slot();\n}\nBase64\nBase64 util allows you to transform bytes32 data into its Base64 string representation.\nThis is especially useful for building URL-safe tokenURIs for both ERC-721 or ERC-1155. This library provides a clever way to serve URL-safe Data URI compliant strings to serve on-chain data structures.\nHere is an example to send JSON Metadata through a Base64 Data URI using an ERC-721:\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.24;\n\nimport {ERC721} from \"@openzeppelin/contracts/token/ERC721/ERC721.sol\";\nimport {Strings} from \"@openzeppelin/contracts/utils/Strings.sol\";\nimport {Base64} from \"@openzeppelin/contracts/utils/Base64.sol\";\n\ncontract Base64NFT is ERC721 {\n using Strings for uint256;\n\n constructor() ERC721(\"Base64NFT\", \"MTK\") {}\n\n // ...\n\n function tokenURI(uint256 tokenId) public pure override returns (string memory) {\n // Equivalent to:\n // {\n // \"name\": \"Base64NFT #1\",\n // // Replace with extra ERC-721 Metadata properties\n // }\n // prettier-ignore\n string memory dataURI = string.concat(\"{\\\"name\\\": \\\"Base64NFT #\", tokenId.toString(), \"\\\"}\");\n\n return string.concat(\"data:application/json;base64,\", Base64.encode(bytes(dataURI)));\n }\n}\nMulticall\nThe Multicall abstract contract comes with a multicall function that bundles together multiple calls in a single external call. With it, external accounts may perform atomic operations comprising several function calls. This is not only useful for EOAs to make multiple calls in a single transaction, it’s also a way to revert a previous call if a later one fails.\nConsider this dummy contract:\n// contracts/Box.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {Multicall} from \"@openzeppelin/contracts/utils/Multicall.sol\";\n\ncontract Box is Multicall {\n function foo() public {\n // ...\n }\n\n function bar() public {\n // ...\n }\n}\nThis is how to call the multicall function using Ethers.js, allowing foo and bar to be called in a single transaction:\n// scripts/foobar.js\n\nconst instance = await ethers.deployContract(\"Box\");\n\nawait instance.multicall([\n instance.interface.encodeFunctionData(\"foo\"),\n instance.interface.encodeFunctionData(\"bar\")\n]);\nLow-level Calls\nThe LowLevelCall library provides low-level external calls with fixed-size return data handling, protecting against return bombing attacks where callees allocate excessive memory.\nThe library efficiently handles return data up to 64 bytes, allowing you to ignore it entirely or extract 1-2 bytes32 values:\nusing LowLevelCall for address;\n\nfunction example(address target, bytes memory data) internal {\n bool success;\n bytes32 result1;\n bytes32 result2;\n\n // Ignore return data\n success = target.callNoReturn(data);\n\n // Extract single 32-byte value\n (success, result1, ) = target.callReturn64Bytes(data);\n\n // Extract two 32-byte values\n (success, result1, result2) = target.callReturn64Bytes(data);\n}\nYou can also check return data size before processing:\nfunction checkReturnSize(address target, bytes memory data) internal returns (uint256 value, uint256 otherValue) {\n (bool success, bytes32 result1, bytes32 result2) = target.callReturn64Bytes(data);\n\n if (!success || LowLevelCall.returnDataSize() < 32) {\n return (0, 0);\n } else if (LowLevelCall.returnDataSize() < 64) {\n return (uint256(result1), 0);\n } else {\n return (uint256(result1), uint256(result2));\n }\n}\nMemory\nThe Memory library provides functions for advanced use cases that require granular memory management. A common use case is to avoid unnecessary memory expansion costs when performing repeated operations that allocate memory in a loop. Consider the following example:\nfunction processMultipleItems(uint256[] memory items) internal {\n for (uint256 i = 0; i < items.length; i++) {\n bytes memory tempData = abi.encode(items[i], block.timestamp);\n // Process tempData...\n }\n}\nNote that each iteration allocates new memory for tempData, causing the memory to expand continuously. This can be optimized by resetting the memory pointer between iterations:\nfunction processMultipleItems(uint256[] memory items) internal {\n Memory.Pointer ptr = Memory.getFreeMemoryPointer(); // Cache pointer\n for (uint256 i = 0; i < items.length; i++) {\n bytes memory tempData = abi.encode(items[i], block.timestamp);\n // Process tempData...\n Memory.unsafeSetFreeMemoryPointer(ptr); // Reset pointer for reuse\n }\n}\nThis way, memory allocated for tempData in each iteration is reused, significantly reducing memory expansion costs when processing many items.\nOnly use these functions after carefully confirming they’re necessary. By default, Solidity handles memory safely. Using this library without understanding memory layout and safety may be dangerous. See the memory layout and memory safety documentation for details.\nHistorical Block Hashes\nBlockhash provides L2 protocol developers with extended access to historical block hashes beyond Ethereum’s native 256-block limit. By leveraging EIP-2935's history storage contract, the library enables access to block hashes up to 8,191 blocks in the past, making it invaluable for L2 fraud proofs and state verification systems.\nThe library seamlessly combines native BLOCKHASH opcode access for recent blocks (≤256) with EIP-2935 history storage queries for older blocks (257-8,191). It handles edge cases gracefully by returning zero for future blocks or those beyond the history window, matching the EVM’s behavior. The implementation uses gas-efficient assembly for static calls to the history storage contract.\ncontract L1Inbox {\n using Blockhash for uint256;\n\n function verifyBlockHash(uint256 blockNumber, bytes32 expectedHash) public view returns (bool) {\n return blockNumber.blockHash() == expectedHash;\n }\n}\nAfter EIP-2935 activation, it takes 8,191 blocks to completely fill the history storage. Before that, only block hashes since the fork block will be available.\nTime\nThe Time library provides helpers for manipulating time-related objects in a type-safe manner. It uses uint48 for timepoints and uint32 for durations, helping to reduce gas costs while providing adequate precision.\nOne of its key features is the Delay type, which represents a duration that can automatically change its value at a specified point in the future while maintaining delay guarantees. For example, when reducing a delay value (e.g., from 7 days to 1 day), the change only takes effect after the difference between the old and new delay (i.e. a 6 days) or a minimum setback period, preventing an attacker who gains admin access from immediately reducing security timeouts and executing sensitive operations. This is particularly useful for governance and security mechanisms where timelock periods need to be enforced.\nConsider this example for using and safely updating Delays:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.27;\n\nimport {Time} from \"contracts/utils/types/Time.sol\";\n\ncontract MyDelayedContract {\n using Time for *;\n\n Time.Delay private _delay;\n\n constructor() {\n _delay = Time.toDelay(3 days);\n }\n\n function schedule(bytes32 operationId) external {\n // Get the current `_delay` value, respecting any pending delay changes if they've taken effect\n uint32 currentDelay = _delay.get();\n uint48 executionTime = Time.timestamp() + currentDelay;\n\n // ... schedule the operation at `executionTime`\n }\n\n function execute(bytes32 operationId) external {\n uint48 executionTime = getExecutionTime(operationId);\n require(executionTime > 0, \"Operation not scheduled\");\n require(Time.timestamp() >= executionTime, \"Delay not elapsed yet\");\n\n // ... execute the operation\n }\n\n // Update the delay with `Time`'s safety mechanism\n function updateDelay(uint32 newDelay) external {\n (Time.Delay updatedDelay, uint48 effect) = _delay.withUpdate(\n newDelay, // The new delay value\n 5 days // Minimum setback if reducing the delay\n );\n\n _delay = updatedDelay;\n\n // ... emit events\n }\n\n // Get complete delay details including pending changes\n function getDelayDetails() external view returns (\n uint32 currentValue, // The current delay value\n uint32 pendingValue, // The pending delay value\n uint48 effectTime // The timepoint when the pending delay change takes effect\n ) {\n return _delay.getFull();\n }\n}\nThis pattern is used extensively in OpenZeppelin’s AccessManager for implementing secure time-based access control. For example, when changing an admin delay:\n// From AccessManager.sol\nfunction _setTargetAdminDelay(address target, uint32 newDelay) internal virtual {\n uint48 effect;\n (_targets[target].adminDelay, effect) = _targets[target].adminDelay.withUpdate(\n newDelay,\n minSetback()\n );\n\n emit TargetAdminDelayUpdated(target, newDelay, effect);\n}GovernancePrevious PageOverviewNext PageOn this pageCryptographyChecking Signatures On-ChainEthereum Signatures (secp256k1)P256 Signatures (secp256r1)RSASignature VerificationBasic Signature VerificationERC-1271 Contract SignaturesERC-7913 Extended SignaturesBatch VerificationVerifying Merkle ProofsIntrospectionMathStructuresBuilding a Merkle TreeUsing a HeapMiscPackingStorage SlotsBase64MulticallLow-level CallsMemoryHistorical Block HashesTime","tokens":6585,"squid":"ink-security_audits","role":"Sentinel","at":1791266650586,"hash":"dd999d58fcb72c02c83e6eb15cea61cc0aad49d7"}
{"url":"https://forum.pyth.network/t/passed-op-pip-86-pyth-token-phase-2-pyth-strategic-reserve/2293","domain":"forum.pyth.network","title":"[PASSED] OP-PIP-87: PYTH Token Phase 2 — $PYTH Strategic Reserve - Proposals - Pyth DAO","text":"[PASSED] OP-PIP-87: PYTH Token Phase 2 — $PYTH Strategic Reserve \n\n Proposals\n\n operational-pip\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2025\n\n 1 / 3\n\n Dec 2025\n\n Dec 2025\n\n post by KemarTiti on Dec 5, 2025\n\n KemarTiti\n\n Abstract\nFollowing this discussion (**Pyth Token Phase 2)** and previous community interest around that topic (1, 2), this Operational Proposal aims to:\n\nEstablish a DAO-owned $PYTH Strategic Reserve using the Pyth DAO Treasury as specified below\n\nEmpower the Pythian Council to administer and execute buybacks on behalf of the Pyth DAO based on pre-defined parameters (specified in the Implementation Plan below)\n\nTransfer one-third of the current Treasury balance to the newly introduced Pythian Council Ops Multisig to perform the first buybacks\n\nRationale and Description\nThe Pyth Network will soon celebrate its five-year anniversary (Q2 2026), and the $PYTH token just turned two in November 2025.\nThis proposal aims to enable the DAO to use its existing treasury as well as manage upcoming revenue flows (from Pyth Pro as well as existing products such as Pyth Core/Price Feeds, Entropy, and Express Relay), and position the network for the next phase of growth.\n\ndr497 post\n\nPractically speaking, the DAO will systematically direct its Treasury (stemming from protocol revenue) toward acquiring PYTH tokens to better align the treasury with the network’s long-term growth. Specifically, the DAO will purchase PYTH monthly using one-third (33%) of the Treasury balance at hand (whether USDC, SOL, or others, excluding PYTH). Please refer to the original post for “at hand’ definition.\nAs of today, the Pyth DAO Treasury is currently holding about $390,000 (in USDC and SOL). As a reminder, this amount mostly stem from (1) Price Feed Listing as well as (2) the recent (and first) Pyth Pro distribution from Douro Labs (disregarding any PYTH tokens already owned).\nImplementation Plan\n\nIntroduction of the Pythian Council Ops Multisig\n\nIf this proposal is approved, the below on-chain vote will officially recognize the Pythian Council Ops Multisig Wallet (operated via Squads). That new Pythian Council Ops Multisig Wallet will administer and execute the buybacks. The new Pythian Council Ops Multisig Wallet follows the same rules as the Pythian Multisig Wallet (used for OP-PIPs) where the proposals need to be approved by 6/8 of the elected council members. The new Pythian Council Ops Multisig Wallet address would be the following: GAdn7TZhszf5KTfwNRx3A2nP6KCRFEWucZubgdEqbJA2. The ultimate owner of this multisig is the Pyth DAO. Signers of Pythian Council Ops Multisig Wallet are the same address than the Pythian Council members use for the Pythian Multisig Wallet (which is used for OP-PIPs).\n\n$PYTH Purchasing Rules\n\nThese purchases will be administered by the Pythian Council to optimize for the amount of PYTH accumulated (limit orders, smaller market orders to avoid being impacted by a low liquidity level of the Pyth Tokens onchain), in accordance with the following parameters and limiting instructions:\n\nNo transactions where slippage would exceed 5%\n\nNo single transactions in excess of $25,000 USD\n\nAggregators (like jup.ag) should be preferred to optimize transactions\n\nWhere limit orders are used, they must be at least 0.1% below the displayed market price at the time the order is placed\n\nThe Pythian Council will be in charge of reporting all the trades, associated with proofs, to the Pyth DAO on the forum, and sending back the recently acquired PYTH tokens to the Pyth DAO Treasury.\n\nEmpower the Pythian Council to facilitate repatriation of DAO-owned assets to the DAO Treasury\n\nAssets accumulated across Pyth contracts on non-Solana chains—such as fees collected by Pyth Core, Entropy, or Express Relay contracts—belong to the DAO but are not part of the Solana-based Treasury according to the Constitution. Retrieving these balances requires contract upgrades and withdrawal actions via the Pythian Council OP-PIPs.\nTo ensure consistent consolidation of these assets, it will be the responsibility of the Pythian Council to regularly retrieve funds from Pyth contracts deployed across other chains and repatriate their value to the Pyth DAO Treasury on Solana. Given the liquidity and bridging constraints on many networks, the most practical approach is to source reputable counterparties willing to receive the native-chain assets directly and pay the DAO in USDC on Solana.\nThe Council will be in charge of identifying reputable counterparties or venues to receive native tokens (like ETH on EVMs or CRO on Cronos for instance) in exchange for USDC in the Pyth DAO Treasury wallet.\nThese repatriations should be performed in accordance with the following parameters and limiting instructions:\n\nNo transactions where slippage would exceed 5%\n\nTokens received by the Pyth DAO must either be PYTH or USDC\n\nSend 1/3 of the Pyth DAO Treasury to the Pythian Council (Ops Mulitsig)\n\nAs of today, there are $382.72K $USDC, and 53.907 $SOL (excluding $PYTH and negligible amount in other tokens) in the Pyth DAO Treasury.\nIf this proposal is approved, the Pythian Council Ops Multisig (GAdn7TZhszf5KTfwNRx3A2nP6KCRFEWucZubgdEqbJA2) will receive the following from the Pyth DAO Treasury (Gx4MBPb1vqZLJajZmsKLg8fGw9ErhoKsR8LeKcCKFyak):\n\n127,573 $USDC\n\n17.97 $SOL\n\nAnd will administer and execute the buybacks as specified in the point 2 of the Implementation Plan above.\nOnce executed, the Pythian Council must repatriate all the PYTH accumulated back to the Pyth DAO Treasury: Gx4MBPb1vqZLJajZmsKLg8fGw9ErhoKsR8LeKcCKFyak\nNext Steps\n\nDAO members vote on the OP-PIP-86\n\nIf approved:\n\nThe Pythian Council Ops Wallet will receive 127,573 $USDC and 17.97 $SOL from the Pyth DAO Treasury\n\nThe Pythian Council will start the first buybacks as specified above and approved by the DAO\n\nThe Pythian Council shall send back the recently acquired PYTH tokens to the Pyth DAO Treasury\n\n [PASSED] OP-PIP-91: PYTH Token Phase 2 — Purchases #3\n\n Idea: Introducing Stablecoin Rewards for OIS Stakers\n\n Idea: Pyth Reserve Evolution: Ratio-Based Management + Sustainable Partial Burns\n\n About the Pythian Council\n\n Pyth Token Phase 3\n\n 2\n\n post by eukodal on Dec 7, 2025\n\n eukodal\n\n super happy to see this initiative\nbuy backs or holding any asset is still having purchase power but growth ?!\nmay i , interest everyone attention toward an industry untapped and very few developments in that field\n10000451871080×464 147 KB\n( category ) stealth crypto mini games\nwhere there is no mention of crypto in the game however nft or token is the back bone of game\nthis treasury can be used towards onboarding and incentivising mini-game devs to craft & develop stealth crypto games which eventually can generate massive revenue through engaging and fun games\n\nhaving games requiring discord connection and leveraging roles and matrica holdings can be a way to run games\n\nas a product growth guy ill be happy to share this vision\nproduct management means , users enjoy growth and increase in revenue\ntreasury is a starting point where we see how larger the size of treasury can get .\n\n [PASSED] OP-PIP-92: Q1 2026 Pyth Express Relay Fee Implementation\n\n Q1 2026 — Pyth Express Relay Onchain Fee\n\n Q1 2026 — Pyth Entropy Onchain Fees\n\n Q1 2026 — Pyth Core Onchain Fees\n\n [PASSED] OP-PIP-94: Q1 2026 Entropy Protocol Fee Implementation\n\n post by KemarTiti on Dec 9, 2025\n\n KemarTiti\n\n The proposal has reached quorum with a YES answer from PYTH stakers.\nAnd confirming the Pythian Council Ops Multisig received the above amount, please refer to this link: https://app.squads.so/squads/GAdn7TZhszf5KTfwNRx3A2nP6KCRFEWucZubgdEqbJA2/trade\nMore details on the reporting to come in shortly.\n\n [PASSED] CO-PIP-138: Reclaim Unused Pythnet Governance SOL\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [PASSED] OP-PIP-129: PYTH Token Phase 2 — Purchases #9\n\n Proposals\n\n operational-pip\n\n 0\n\n 123\n\n Aug 19\n\n [PASSED] OP-PIP-88: PYTH Token Phase 2 — Purchases #2\n\n Proposals\n\n operational-pip\n\n 1\n\n 381\n\n Jan 8\n\n [PASSED] OP-PIP-123.V2: PYTH Token Phase 2 — Purchases #8\n\n Proposals\n\n operational-pip\n\n 0\n\n 88\n\n Jul 22\n\n [FAILED] OP-PIP-123: PYTH Token Phase 2 — Purchases #8\n\n Proposals\n\n operational-pip\n\n 1\n\n 133\n\n Jul 15\n\n [PASSED] OP-PIP-102: PYTH Token Phase 2 — Purchases #5\n\n Proposals\n\n operational-pip\n\n 0\n\n 116\n\n Apr 10","tokens":2109,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266653769,"hash":"7fa6a5487e3295173977a9625bfa6a990fbaae30"}
{"url":"https://docs.optimism.io/node-operators/reference/consensus-layer-sync","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This page documents the consensus-layer sync mode, which is the default sync method for op-node but not the recommended approach for most node operators.\n​Overview\nConsensus-layer sync is a sync approach where op-node reads transaction data from L1 and derives blocks, then inserts them into the execution client. Unlike execution-layer sync (snap sync), this method does not rely on P2P networking to download state or block data from other L2 nodes.\nWhile consensus-layer sync is still the default mode, execution-layer sync (snap sync) is recommended for faster synchronization and better performance.\n​When to use consensus-layer sync\nThis sync mode might be preferred in the following scenarios:\n\nIndependent verification: Decentralized developer groups who need to independently verify the entire chain by deriving all data from L1\nNo P2P connectivity: Environments where P2P networking is restricted or unavailable\nL1-only trust model: Applications that prefer to trust only L1 data without relying on L2 peer nodes\nDebugging and research: Analyzing how blocks are derived from L1 data\n\nConsensus-layer sync is significantly slower than execution-layer sync (snap sync). For most node operators, snap sync is the recommended approach for faster synchronization.\n​Configuration\n​Configuration for op-node\nSet the following flag on op-node:\n--syncmode=consensus-layer\n\nThe --syncmode=consensus-layer is the default setting for op-node. You don’t need to specify it explicitly unless you want to be explicit about the sync mode or are overriding a different configuration.\n​Configuration for op-geth\nSet the following flag on op-geth:\n--syncmode=full\n\nThe --syncmode=full flag is not the default setting and must be explicitly configured. This ensures blocks are inserted by op-node rather than synced via P2P.\n​Configuration for Nethermind\nSet the following flags on Nethermind:\n--config op-mainnet\n--Sync.SnapSync=false\n--Sync.FastSync=false\n\nReplace op-mainnet with the appropriate configuration for your network (e.g., op-sepolia for OP Sepolia).\n​How consensus-layer sync works\nThe consensus-layer sync process:\n\nL1 monitoring: op-node continuously monitors the L1 chain for transaction batches\nBlock derivation: op-node derives L2 blocks from the L1 transaction data\nBlock insertion: Derived blocks are inserted into the execution client one by one\nState building: The execution client builds state by executing each block sequentially\n\nThis approach ensures that every block is derived from L1 and independently verified, but it’s much slower than downloading state snapshots from peers.\n​Performance considerations\n\nSync time: Significantly slower than snap sync or archive sync with execution-layer mode\nNetwork requirements: Requires reliable L1 RPC access but minimal L2 P2P connectivity\nResource usage: Lower P2P bandwidth usage but more L1 RPC calls\nOP Mainnet: For OP Mainnet, you’ll still need the bedrock datadir for state before the Bedrock upgrade\n\n​Comparison with other sync modes\nFeatureConsensus-Layer (Legacy)Execution-Layer (Snap Sync)Archive with Execution-LayerData sourceL1 onlyL2 P2P + L1L2 P2P + L1Sync speedSlowestFastestMediumState pruningYes (by default)YesNoHistorical stateNot availableNot availableFull historyP2P requiredNoYesYesVerificationFull L1 derivationCryptographic verificationFull execution\n​Next steps\n\nSee the Archive Node guide for running an archive node\nSee the Consensus Client Configuration and Execution Client Configuration guides for additional explanation or customization\nIf you experience difficulty at any stage of this process, please reach out to developer support\nWas this page helpful?","tokens":913,"squid":"ink-governance","role":"Council Listener","at":1791266672413,"hash":"480976b1709308b71d4e3647bdcce400a047e5ed"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api","domain":"docs.openzeppelin.com","title":"API Reference | OpenZeppelin Docs","text":"OpenZeppelin ContractsAPI ReferenceOpen in ClaudeThis API reference is automatically generated from the OpenZeppelin Contracts repository.\nContract Categories\nAccess Control\n\nAccess Control - Role-based access control mechanisms\nOwnable - Simple ownership access control\n\nTokens\n\nERC20 - Fungible token standard implementation\nERC721 - Non-fungible token standard implementation\nERC1155 - Multi-token standard implementation\n\nCrosschain\n\nERC7786 - Contracts for sending and receiving crosschain messages\n\nUtilities\n\nUtils - General utility functions and contracts\nCryptography - Cryptographic utilities\n\nGovernance\n\nGovernance - On-chain governance systems\n\nProxy Patterns\n\nProxy - Upgradeable proxy patterns\n\nInterfaces\n\nInterfaces - Standard interfaces\nChangelogPrevious PageAccessNext PageOn this pageContract CategoriesAccess ControlTokensCrosschainUtilitiesGovernanceProxy PatternsInterfaces","tokens":224,"squid":"ink-security_audits","role":"Sentinel","at":1791266672447,"hash":"ef7c47dd03212a7040be0588f974340e4b4d53a7"}
{"url":"https://forum.pyth.network/t/pyth-token-phase-2/2284","domain":"forum.pyth.network","title":"Pyth Token Phase 2 - Ideas Bank - Pyth DAO","text":"Pyth Token Phase 2 \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2025\n\n 1 / 36\n\n Nov 2025\n\n Feb 26\n\n post by dr497 on Nov 28, 2025\n\n dr497\n\n Summary\nAs a long-time participant in the Pyth ecosystem, I’m putting forward this proposal to introduce two key improvements that I believe will strengthen Pyth Network’s long-term sustainability and governance alignment:\n\nRedirect all Pyth protocol revenue into a $PYTH Strategic Reserve fully owned and controlled by the DAO.\n\nThe Pythian Council to evaluate and optimize pricing across all Pyth Network on-chain products to ensure the protocol is maximizing revenue.\n\nTogether, these changes reinforce Pyth’s economic foundation and align the network’s growth with the interests of its community.\nBackground\nThe Pyth Network will soon celebrate its five-year anniversary (Q2 2026), and the $PYTH token just turned two in November 2025.\nWhile Pyth’s feature suite continues to evolve—most recently with the launch of Pyth Pro—the token and the DAO have advanced far more slowly, aside from the creation of councils and the launch of Oracle Integrity Staking.\nThis proposal aims to prepare the DAO to use its existing treasury as well as manage upcoming revenue flows (from Pyth Pro as well as existing products such as Pyth Core/Price Feeds, Entropy, and Express Relay), and position the network for the next phase of growth.\nSuccessfully executing these changes will help further align incentives between all Pyth DAO stakeholders: PYTH stakers, publishers, the DAO itself, and downstream users of Pyth products.\n\nPyth Core\n\nPyth’s original feature provides more than 2,000 price feeds across over 100 blockchains.\nEach price update triggers a fee collected by the oracle contract. Over 90 chains use the smallest possible fee denomination (e.g., 1 wei for EVMs), but several chains have more meaningful fees. The Core contracts currently hold close to $100,000 in accumulated fees (in their respective native tokens).\nExamples include:\n\n~16 BNB on opBNB\n~115,000 CRO on Cronos\n~1,600 NEAR on NEAR\n~175 AVAX on Avalanche\n~2,000 SEI on Sei\n\nAdditional rewards exist on some chains. For example, Sonic’s FeeM program currently allocates 165,000 S tokens to the Pyth DAO.\nThe Price Feed Council has also created a successful listing process whereby asset requests include direct payments to the DAO. For example, HAEDAL/USD was listed for a $20,000 reward. More than $200,000 has been collected through this mechanism over the past few months.\n\nPyth Entropy\n\nPyth’s second product is a random-number generator deployed on nearly 20 blockchains.\nLike Core, Entropy follows an on-demand pricing model: each randomness request pays a fee to the oracle. The contracts have collectively accumulated nearly $150,000, specifically ~50 ETH on Abstract.\n\nPyth Express Relay\n\nThe third Pyth product is a priority auction protocol initially launched with Kamino’s Swap product and since integrated with venues such as Titan.\nFees for the DAO are denominated in bips and depend on trading volume. The DAO has generated close to $110,000 to date. Growth has slowed recently due to the rise of Prop AMMs and increased competition among DEXs and LPs.\n\nPyth Pro\n\nPyth Pro is the newest addition: a paid subscription service offering low-latency, high-frequency data to professional data consumers. Pricing is publicly available on the Pyth website.\nLaunched in late September 2025, the DAO appointed Douro Labs as its first distributor with a 60/40 revenue split. Douro Labs will report quarterly and remit 60% of revenue to the DAO. The first report is due soon, but revenues are expected to exceed those of other Pyth products given the optimized pricing model (unlike Core, Entropy, and Express Relay).\nProposal\nThis proposal builds on prior discussions and introduces three key areas of action.\n\nCreate a $PYTH Strategic Reserve from Pyth DAO Treasury\n\nStarting with this proposal, the DAO should begin systematically directing protocol revenue toward acquiring PYTH tokens to better align the treasury with the network’s long-term growth.\nI propose that the DAO purchase PYTH monthly using one-third (33%) of the Treasury balance at hand (whether USDC, SOL, or others, excluding PYTH).\nNotes:\n\n“At hand” refers specifically to the assets held in the official Solana-based DAO Treasury addresses (Gx4MBPb1vqZLJajZmsKLg8fGw9ErhoKsR8LeKcCKFyak and 9HKkxg5dpqjUEW1U2r76SpQCH7uvDMciytNYxrpwMVNc). Assets in Pyth contracts across other chains are not themselves the Treasury and require council-managed OP-PIPs for withdrawal towards the Pyth DAO Treasury on Solana. See Pyth DAO Constitution for more details.\n\nEven if revenue stagnated for three months—an unlikely scenario—this approach still provides ample time for the DAO to adjust course if needed. It also smooths market impact and helps the DAO accumulate PYTH at an averaged cost.\n\nThis proposal does not prescribe or suggest how the acquired PYTH should be used (burns, OIS funding, grants, publisher incentives, etc.). The focus is first on systematically acquiring PYTH and holding it for now.\n\nIncrease Pricing Across On-Chain Pyth Products (Excluding Pyth Pro)\n\nWith the exception of the Price Feed listing process, revenue optimization has not been fully applied across Pyth’s on-chain products: Pyth Core, Entropy, and Express Relay.\nThe Pythian Council already has the constitutional authority to set on-chain fees for these products.\nI propose establishing a formal process requiring the Council to:\n\nDesign a pricing matrix, and\n\nApply pricing changes on-chain via OP-PIPs on a quarterly basis.\n\nThe first fee-change proposal should be posted in early January 2026 and implemented shortly thereafter for all three products.\nEach quarter, the Council will publish a report during the first week, covering revenue, activity changes, and recommended adjustments for the following quarter.\nImplementation\n1. $PYTH Strategic Reserve\nIf this proposal is approved, the upcoming on-chain vote should create a Pythian Council Ops Multisig Wallet and recognized it in the Constitution. That new Pythian Council Ops Multisig Wallet should administer and execute the buybacks. The new Pythian Council Ops Multisig Wallet should follow the same rules as the Pythian Multisig Wallet (used for OP-PIPs) where the proposals need to be approved by 6/8 of the elected council members. The ultimate owner of this multisig is the Pyth DAO. Signers of Pythian Council Ops Multisig Wallet are the same address than the Pythian Council members use for the Pythian Multisig Wallet (which is used for OP-PIPs).\nThe intent of this design is not to turn the Pythian Council into an active treasury manager, but to have the Pythian Council Ops Multisig act as a mostly mechanical executor of what the DAO and its members decide. As many parameters as possible around the buybacks (amounts, cadence, order types, venues, slippage limits, max trade sizes, etc.) should be specified directly in the final proposal, so that the Council is simply following clear instructions approved on-chain rather than exercising ongoing discretion. In this way, control over treasury strategy remains firmly with the DAO, while reducing unnecessary responsibility and potential liability for individual council members.\nAdditionally, if this proposal would be approved, I suggest the DAO to immediately transfer one-third of the current Treasury balance to the newly introduced Pythian Council Ops Multisig Wallet to begin purchasing PYTH on-chain. These purchases will be administered by the Pythian Council to optimize for the amount of PYTH accumulated (limit orders, smaller market orders to avoid being impacted by a low liquidity level of the Pyth Tokens onchain), in accordance with the following parameters and limiting instructions:\n\nNo transactions where slippage would exceed 5%\n\nNo single transactions in excess of $25,000 USD\n\nAggregators (like jup.ag) should be preferred to optimize transactions\n\nWhere limit orders are used, they must be at least 0.1% below the displayed market price at the time the order is placed\n\nThe Pythian Council will also be in charge of reporting all the trades, associated with proofs, to the Pyth DAO on the forum, and sending back the recently acquired PYTH tokens to the Pyth DAO Treasury.\nThe Pyth DAO Treasury—per the Constitution—is composed of the assets held at the following Solana addresses:\nGx4MBPb1vqZLJajZmsKLg8fGw9ErhoKsR8LeKcCKFyak\n9HKkxg5dpqjUEW1U2r76SpQCH7uvDMciytNYxrpwMVNc\nAssets accumulated across Pyth contracts on non-Solana chains—such as fees collected by Pyth Core, Entropy, or Express Relay—belong to the DAO but are not part of the Solana-based Treasury. Retrieving these balances requires contract upgrades or withdrawal actions via the Pythian Council OP-PIPs.\nTo ensure consistent consolidation of these assets, it will be the responsibility of the Pythian Council to regularly retrieve funds from Pyth contracts deployed across other chains and repatriate their value to the Pyth DAO Treasury on Solana. Given the liquidity and bridging constraints on many networks, the most practical approach is to source reputable counterparties willing to receive the native-chain assets directly and pay the DAO in USDC on Solana.\nFor example:\nThe Pyth Entropy contract on Abstract currently holds about 50 ETH, the Council may identify a counterparty (e.g., a Pyth publisher such as Wintermute, Selini…) willing to receive those 50 ETH directly on Abstract. In return, the counterparty would send 150,000 USDC to the DAO Treasury on Solana (assuming ETH/USD = $3,000 based on the Pyth ETH/USD 1-hour EMA).\nThis approach avoids illiquid cross-chain swaps, ensures fair pricing, and streamlines the consolidation of DAO-owned assets.\nEach retrieval and conversion will be documented on the Pyth Forum and approved by the 7-of-9 Pythian Multisig before execution.\n\nPricing Increase\n\nNo contract upgrades are needed. The Pythian Council already has the authority to implement quarterly pricing adjustments via OP-PIPs. Quarterly forum posts will present data, recommendations, and proposed changes.\nNext Steps\n\nCommunity discussion and feedback on this proposal.\n\nPreparation of a detailed follow-up proposal for an on-chain DAO vote.\n\nI believe these changes would meaningfully strengthen Pyth’s long-term sustainability while keeping control firmly in the hands of the DAO. Looking forward to hearing everyone’s thoughts and feedback!\n\n [PASSED] OP-PIP-112: Pyth Entropy Fees - Q2\n\n Pyth Strategic Reserve V2: Aligning PYTH Accumulation with Pyth Pro Revenue\n\n [PASSED] OP-PIP-87: PYTH Token Phase 2 — $PYTH Strategic Reserve\n\n Pyth Token Phase 3\n\n Q1 2026 — Pyth Core Onchain Fees\n\n 8\n\n 5\n\n 4\n\n 3\n\n 3\n\n read \n\n 19\n min\n\n post by TheDinarian on Nov 29, 2025\n\n TheDinarian\n\n This proposal is a significant step toward strengthening Pyth Network’s economic foundation and ensuring long-term sustainability. The dual focus on systematically accumulating the native asset ($PYTH) and proactively optimizing revenue streams is exactly the kind of strategic thinking the DAO needs.\n\nOn the $PYTH Strategic Reserve:\nThe plan to create a dedicated $PYTH Strategic Reserve is highly commendable. Systematically directing protocol revenue back into the native token is the most powerful way to align the DAO’s financial interests with the value accrual of the token holder community. The detailed implementation steps regarding the Pythian Council Ops Multisig Wallet, transaction limits, and preference for aggregators like jup.ag show a strong focus on minimizing market impact and achieving optimal execution.\nOn Increasing Pricing Across On-Chain Products:\nIt is critical that the DAO move beyond minimal fees for its established products (Core, Entropy, Express Relay). Your suggestion to mandate the Pythian Council to design a formal pricing matrix and apply quarterly, data-driven adjustments is an excellent mechanism to maximize revenue without requiring burdensome contract upgrades every time. This introduces a professional, iterative approach to product pricing.\nSuggestive Improvements\nTo make this proposal even more robust and transparent, I offer the following suggestions for consideration:\nRefine the Strategic Reserve Funding Mechanism\nThe current proposal suggests purchasing PYTH monthly using one-third (33%) of the Treasury balance at hand.\n\nSuggestion: While the intent is clear, basing the ongoing monthly buyback on a percentage of the entire existing treasury balance could lead to highly variable and potentially massive initial buybacks, which might cause an avoidable market shock.\nAlternative Structure: Consider basing the monthly buyback on a percentage of the net new revenue accumulated over the previous month or quarter (e.g., 66% of the revenue collected into the Treasury in the last 30 days). This approach ties the buyback directly to the network’s organic growth and ensures the strategic reserve grows sustainably and proportionally with current network activity.\n\nEnhance Transparency in Pricing Optimization KPIs\nThe proposal tasks the Pythian Council with designing a pricing matrix and reporting on recommended adjustments quarterly.\n\nSuggestion: Mandate that the Pythian Council explicitly define and publish the Key Performance Indicators (KPIs) they will use to measure the success or failure of a pricing change.\nExample KPIs to track:\n\nTotal revenue generated (USD equivalent).\nNumber of unique users/integrations on a specific chain.\nFee revenue divided by the total number of price updates/requests (average fee).\nObserved user churn (de-integrations) following a fee increase.\n\nClearly defining the metrics before the changes are implemented will dramatically increase community confidence and provide a concrete framework for evaluating the Council’s performance each quarter.\n\nFormalize Cross-Chain Asset Repatriation Reporting\nThe plan for the Pythian Council to retrieve assets from non-Solana chains (e.g., 50 ETH on Abstract) via over-the-counter (OTC) trades with counterparties is clever and practical.\n\nSuggestion: To ensure full transparency and accountability, require the Council to publish a Repatriation Log on the forum immediately following the execution of any large-scale OTC trade, detailing:\n\nThe exact native asset and amount retrieved (e.g., 50 ETH on Abstract).\nThe final USD amount received on Solana (e.g., 150,000 USDC).\nThe counterparty (if willing to be named, or simply “Pyth Publisher”).\nThe time-of-trade market rate used for calculation.\nThis minor addition ensures the community can easily track the consolidation of DAO-owned assets across all 100+ chains, even before the funds enter the Strategic Reserve.\nThis is a fantastic step forward, and I look forward to supporting the final proposal in the vote.\n\n post by KemarTiti on Dec 1, 2025\n\n KemarTiti\n\n @dr497\nVery nice to see this as it echoes a growing community interest around that topic (1, 2).\nTo your comments @TheDinarian\n1. Recent revenue vs. treasury as the metric\nUsing recent revenue instead of the DAO treasury to decide how much the DAO should buy feels pretty similar anyway. And as it was mentioned in the original post, not all revenue is automatically transferred to the DAO treasury. So if we use recent revenue as the basis, we could end up in situations where the buyback amount is actually higher than what the DAO currently holds on Solana.\nFor practical and operational reasons, I’d lean toward @dr497 idea and use the DAO treasury since it’s easily accessible.\n2. KPIs to measure the success of pricing decisions\nIn principle, I agree that proper KPIs should be defined to measure whether the pricing changes are successful. That said, in practice, setting up really solid KPIs will take a lot of work. I do like the ones you suggested though:\n\nRevenue – At the end of the day, this is what matters most (or close to it).\n\nNumber of unique users – Relying heavily on one large user can have some short-term benefits (fewer stakeholders to manage), but it also increases risk if that user leaves.\n\nThe Pythian Council has already made fee changes in the past, and we should review those to see what worked and what didn’t:\n\nopBNB, Cronos, Avalanche, and Sei have generally been successful in terms of both revenue and continued usage.\n\nSwellchain and Worldchain have seen little usage, which may also be due to the chains themselves having limited activity.\n\n3. Disclosure of DAO asset repatriation\nI also agree that any repatriation of DAO-owned assets should be disclosed on the forum. In practice, this would most likely happen through OP-PIPs, since Pyth contracts would need to:\n\nBe upgraded to allow withdrawals of held assets, and\n\nSend those assets to the designated counterparty address.\n\n post by lowkeigh on Dec 1, 2025\n\n lowkeigh\n\n Really happy to see this next step for Pyth finally coming to fruition. With the recent development of Pyth Pro and the evolution of existing products, this seems like the logical time to revisit fees and align revenue with support for the Pyth token.\nI have full confidence in the DAO and the Pythian Council’s ability to make the right calls around what fees will be appropriate and how to approach these updates. Because of that, I’d like to focus my comments on the strategic reserve and how it might eventually be utilized.\nFirst and foremost, I completely understand the approach of establishing the reserve before taking action on what to do with the tokens. That breathing room allows Pyth Pro to properly get off the ground and gives any fee changes time to settle so we can see their actual impact.\nHowever, Jupiter recently went through a very similar process with their ‘Litterbox’, where fees were used to buy back tokens and accumulate a reserve but without a clear plan for how that reserve would ultimately be used.\nInitially, this delivered a strong “sugar hit” of positivity for token holders and the broader ecosystem, reflected in positive price action. But over time, as the fund grew with no defined purpose, it became a burden. The uncertainty around its future weighed heavily on holders attracting fud and steering holders away from the token. Jupiter was eventually forced to burn the entire amount just to resolve the overhang.\nWith that in mind, I’d suggest aiming to establish a clear use for the Pyth Strategic Reserve sooner rather than later once the initial accumulation phase is complete, whatever that use may ultimately be.\nI’ve shared my thoughts on how something like this could be applied here\n\n post by grizzlyland on Dec 3, 2025\n\n grizzlyland\n\n Banger of a post . I fully back the ideas/plans laid forth in this post .\nLooking forward to a succesful vote and the implementation of this proposal\n\n post by Derrp on Dec 4, 2025\n\n Derrp\n\n A great idea to formalise a use case for the DAO revenue in a sustainable way. Also a great opportunity for the DAO to request assistance from the Pythian Council to optimise fees, and for there to be more readily-available metrics for on-chain fees to measure the effects of any changes. I imagine there will be push-back from some of our customers regarding any fee changes (to the positive only though), and it will be a challenge to find the perfect balance of DAO revenue and customer retention.\nLots of great ideas all in one post, and I’ve never been more bullish to be part of this DAO. Looking forward to more discussions and potential execution\n\n post by KemarTiti on Dec 4, 2025\n\n KemarTiti\n\nIIRC, the Jupiter Litterbox accumulated close to 130M JUP tokens — roughly $30M+. While we all obviously hope to see Pyth DAO revenue and the treasury grow to that level as quickly as possible, I expect the scale here to be much smaller at first and to increase gradually over time.\nThat said, I personally agree with you that the Pyth DAO should start thinking about the end use sooner rather than later, to avoid the risk of a future supply overhang.\nMy suggestion would still be to kickstart the reserve as soon as possible. Then, during Q1, once we have more data on buybacks and a better understanding of how revenue is growing, DAO members can spend more time defining what to do with the accumulated tokens — whether that’s burning (and at what percentage), funding growth initiatives, or a combination of the options you outlined in your post.\n\nYes, absolutely — this won’t be easy. I generally believe fees should be handled conservatively at first and increased gradually over time. It’s better to move to something like $0.001 and preserve usage rather than jump straight to $0.10 and lose most of it.\nSome early churn is just part of the process. What really matters is building something that can last. Having paying users from the start helps align incentives, pushes everyone to care about data quality, and gives the network real resources to grow. Relying only on massive growth with no revenue is risky — sustainable traction comes from people finding enough value to actually pay.\n\n Pyth Pro: Douro Labs Report on Commercial Progress -- September 1st <> December 1st 2025\n\n post by totti on Dec 4, 2025\n\n totti\n\n This what may seem like one small step is surely one giant leap for Pythians in the coming years. Fully in support of this proposal. I’m certain that slowly and surely Pyth gonna have a humongous stake in this 50 billion dollar industry, and this proposal is gonna align well with the Pyth holders. All market data is gonna be on chain, and we gonna be well positioned for it. Future looking bright!\n\n post by Hillseeker on Dec 4, 2025\n\n Hillseeker\n\n Fully supportive & extremely aligned with this direction.\nAs someone who spent many years in financial services, specifically in global IT procurement negotiating contracts with Bloomberg and other tool providers, I’ve seen firsthand how much power high-quality data and low-latency delivery have over a trading desk’s performance … and over their budgets. These guys got whatever they wanted, when they wanted it, and we had limited power to walk away from the table when negotiating on their behalf (score one for the tool provider).\nThat experience is exactly why I’m incredibly bullish on where Pyth can go with products like Pyth Pro and why this proposal resonates strongly with me.\nRedirecting revenue into a Pyth Strategic Reserve is a smart, long-term alignment move.\nWhile I appreciate the simplicity of a fixed monthly buyback percentage, I’m curious if a flexibility mechanism would be more sustainable – maybe a min-max, or a default position with capacity to scale and/or recalibrate or balance quarterly, based on revenue, market conditions, and opportunities.\nA big thumbs-up as well for the part about the Pythian Council being in charge of reporting trades with proofs to the DAO. I’m very glad to see this handled with rigor & transparency.\nOverall: strong proposal, strong timing, and strong alignment with what the next phase of Pyth should look like. Excited to see this move forward.\n\n post by Amensch on Dec 4, 2025\n\n Amensch\n\n KemarTiti\n\n I’m not too familiar with the business revenue side of things, but if the cost of paying for individual transactions is cheaper than if they had a subscription, wouldn’t that be a hurdle to accomplishing the goal of getting people onto the subscription? I understand volume is a big factor, because users with smaller volume will not want to spend more for a subscription regardless.\nAgain, my question is more to learn and understand.\nThank you\n\n post by KemarTiti on Dec 4, 2025\n\n KemarTiti\n\nFor administrative and legal consideration, I think it is important to have a system/design where the council is only executing on a ‘strategy’ defined by the DAO itself.\nIn regards to a min amount, you can enter a weird territory where the DAO Treasury doesn’t have the min amount available in the Treasury making it impossible to buyback the approved min amount.\nA max amount can make sense though. Also market conditions are a good reason to adapt the buyback strategy.\nI’d agree with you that this can and should likely be reviewed on a quarterly basis (or every time the Pythian Council rotate i.e. every 6 months).\n\nIf done for too long, yes I agree. However in practice it might look like more:\nAs a protocol I pay X to use Pyth Core\nIf my cost to upgrade to Pyth Pro (or Crypto+) is now only 2X it might make sense to just upgrade anyway as Pyth Pro is faster, less end to end latency.\nAlso, whether the revenue comes from Pyth Core or Pyth Pro, this is still revenue for the DAO.\n\n post by Imgonnatakeapyth on Dec 5, 2025\n\n Imgonnatakeapyth\n\n I just wanted to say that i fully support this, still feel our prices would be a bargain in comparison to the other existing solutions out there despite the increase. And tbh i love the fact that even on a not so hot chain atm we were able to generate 50 eth from entropy, really bullish.\n\n post by Hillseeker on Dec 5, 2025\n\n Hillseeker\n\n KemarTiti\n\n appreciate your feedback.\nby min-max, I was thinking of percentages (of treasury balance available), not fixed amounts, for the reason you articulated (on the minimum end) and to have some flex room on the upper side, if the right conditions or opportunities exist. e.g. up to 40% treasury balance per month, with a quarterly review aimed at reaching 33% p.a.\n\n post by KemarTiti on Dec 5, 2025\n\n KemarTiti\n\n Yeah this makes more sense!\nIMO we’ll be better suited to further optimize the reserve strategy as the DAO sees (hopefully) the first buybacks and how all the other endeavors (continuous Pyth Pro revenue, Price Feed Listing and the increased fees for Pyth Core) take shape and perform.\n\n post by arguer on Dec 6, 2025\n\n arguer\n\n Overall, I support this proposal. Buybacks are one of the simplest and most effective ways to return value to every $PYTH holder, whether they be staking in Governance/OIS, holding via CEX/Trusts, or doing Liquidity Provision.\nMy question is about timing. Pyth Pro is still very early in its lifecycle. Right now, the priority has to be customer acquisition, market penetration, and brand-building, especially as we start making inroads into institutional and TradFi circles.\nIt is similar to how fees on Pyth Core were (and still are) kept low in order to drive adoption. I believe the same logic should apply with Pyth Pro. At this stage, directing resources towards buybacks (instead of marketing) could be premature.\nA related issue is the lack of visibility available to regular DAO members. Could Douro Labs or other core contributors give the community more visibility into the current marketing and growth budget?\n\nIs a meaningful portion of the distributor’s 40% revenue share being reinvested into marketing and customer acquisition?\n\nDo we feel that level of investment is sufficient to hit the targets we all want for Pyth Pro over the next 12-18 months?\n\nMore transparency there would make it easier for everyone to provide calibrated inputs regarding the pace of buybacks.\nOn the buyback mechanism itself, I appreciate the rules-based, predictable program. But a flat 33% every month does feel a little blunt when the treasury is still relatively modest and growth spend is critical.\nI therefore suggest the following tweak to the buyback program:\nMake the buyback allocation tiered based on treasury size:\n20% of liquid treasury when balance < $500,000\n33 % when $500,000 - $ 2M\n50 % when > $2M\nIn this way, we protect runway in the early stages (maximizing marketing, BD, partnerships), while automatically turning up buyback aggressiveness when the treasury is healthy and Pyth Pro is printing. It’s still 100% rules-based, so the Pythian Council doesn’t have to make discretionary calls month-to-month, and the DAO stays in control.\n\n post by Mersault on Dec 7, 2025\n\n Mersault\n\n Absolutely happy to support this, these are the actions needed for growth!\nI’m not sure how feasible my additional idea is or whether it has already been discussed, but why not allow payment for some Pyth products using $PYTH tokens?\nI understand that Pyth Pro can’t be paid for in $PYTH.\nBut, for example, listing new price feeds or Entropy (which is probably possible) during Entropy payments, the token could potentially be bought through Express Relay (if such integration is possible), although this wouldn’t be ideal for the user if it happened on every transaction.\n\n post by KemarTiti on Dec 8, 2025\n\n KemarTiti\n\nPyth Pro, even if distributed by private parties for operational reasons, is still a DAO- and Network-owned product, so its growth will make the network grow. This means all network participants (including the Pyth Data Association and the DAO), together with the distributors, will keep putting effort and resources into promoting adoption, expansion, and usage.\nPractically speaking, the only way I could see the Pyth DAO financing some marketing would be by distributing PYTH to Pyth Pro subscribers for instance, which is akin to subsidizing usage. As mentioned in one of my comment earlier, growth for growth is not valuable if it’s done by increasing cost without certainty of future revenue.\nThe above point could also be true for other Pyth Products (Core, Entropy,…).\n\nThis is a good idea. We’d need to think further on the size buckets, as in: is $2M the sweet-spot to increase the buyback allocation? Or is it $1M? $5M?\nI think more parameters could also be accounted in the buyback allocation such as the PYTH price. Fluid, that since implemented buybacks, had a very thoughtful discussion with some other ideas the Pyth DAO should entertain (I particularly liked the TWAP based one on deciding or not to buyback with the rationale of: likely you do not want to buy during a bull market but you do during a bear market). Some other DAOs have implemented some price ceiling for buybacks: if token is below X: buy, if it’s above Y: do no buy.\nStill, the most successful buyback program so far seems to be the Hyperliquid one which is an automatic 97% of the fees generated to buyback HYPE. And this one does seem to work very well as a ‘marketing’ tool too.\n\nThere’s no discretionary call suggested here. 1/3 of the DAO Treasury should be used monthly. The Pythian Council is introduced here just to administer the buybacks as in execute the trades. In other words, whether the Pythian Council receives X or Y from the DAO, it will have to use everything it received to buyback PYTH before sending it back to the DAO Treasury.\nAnd to clarify, there will have to be monthly DAO-wide onchain votes (OP-PIP) with a 50% quorum approving the transfer of 1/3 of its Treasury to the Pythian Council so it can administer and execute the buybacks.\n\ncc @zenyas\nBut my take would be that the 40–60% split between the DAO and distributors is clearly meant to align interests and incentivize distributors to expand their market as much as possible, reinvesting in promotion whatever is optimal to reach that goal; and as the network scales and more distributors come in, the DAO can’t directly monitor the details of everyone’s marketing activities, so it needs a scalable approach, which is mainly achieved via interest alignment plus transparency in reports and revenue distribution.\n\nTechnically doable but it can not be practical. Quite some feedback from Entropy users (that looked at Chainlink VRF) is that it’s great for them not to have to pay in the oracle tokens but only in the native chain token (this also helps them move the cost to the end users).\nI’m pretty sure you would be able to pay Pyth Pro in PYTH tokens but this will need a confirmation from @zenyas\n\nMight be possible but even, would be overly complex for the value provided. Reminder that Entropy is only available on EVM and Express Relay is only on Solana, so somehow you’d need to bridge from EVMs (ETH most likely) to then sell it on Solana via ER for Pyth. And also, Entropy fees (for a single request) would likely not even be enough to pay for the bridging cost.\n\n post by codeglitch on Dec 9, 2025\n\n codeglitch\n\n Great conversation about this proposal, good feedback shared. After reading it, just wanted to share a few suggestions and build on what was already said.\nFirst, I think the flat 33% buyback structure might be a little too rigid. There has been a few suggestions on adding flexibility and I agree. A tiered or performance based model could work well. Something like this could be interesting:\n\n10 to 15 percent of treasury when monthly revenue is under $50k\n\n20 to 33 percent when revenue is between $50k and $150k\n\nUp to 50 percent if revenue is over $150k\n\nThat way we are scaling up buybacks when the protocol is performing well and preserving runway when it is still ramping up. Based on responsive rules.\nSecond, agree with the points raised about eventually defining what the Strategic Reserve is for. Right now it makes sense to accumulate and wait, but we should start planning that conversation. If that ends up being burns, incentives, grants or mix, it is better to show a clear path for this to avoid doubt or confusion.\nOn transparency, a few people mentioned the need for better visibility into protocol revenue and I agree. A public dashboard showing monthly revenue per product, treasury balance, and buyback activity would help the DAO make better decisions. If contributors share on the marketing and growth side, just basic updates on how their revenue share is being used and if we feel that is enough to reach adoption goals for Pyth Pro over the next year.\nI also think it could be worth looking at how we approach on chain fee increases. Most people seem to agree with increasing fees, but we should probably avoid big jumps. A progressive fee structure or tiered pricing by usage volume will help preserve adoption and still bringing in more revenue.\nOne more idea, if we are going to be holding a growing amount of $PYTH in the reserve for a while, we might as well put some of it to work. Could be staked through OIS or something else that is low risk and earns yield for the DAO while keeping the tokens out of circulation.\n\n post by KemarTiti on Dec 10, 2025\n\n KemarTiti\n\nI think such will come with a rather similar post/review to the 2 below (the first one having already led to onchain fee increase while the second was not implemented)\n\n post by KemarTiti on Dec 10, 2025\n\n KemarTiti\n\nThis is a good idea.\nEvery single revenue distribution from Douro Labs to the DAO (for Pyth Pro) but will be posted here:\n\nThe PYTH Reserve purchases (administered and executed by the Pythian Council) will be reported here:\n\nBut I agree. Having a single consolidated monthly report/post gathering all the above and the Pyth Core, Feed Listing, Entropy, Express Relay onchain revenue would definitely ease the general tracking of everything that happens.\n\n Load more posts below","tokens":8705,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266675810,"hash":"4eb0034e9d7ca194bf57afdce5f18ab920d49c67"}
{"url":"https://docs.optimism.io/node-operators/reference/op-supernode-config","domain":"docs.optimism.io","title":"Optimism Documentation","text":"op-supernode is in active development.\nThis page tracks the op-supernode/v0.2.2-rc.8 release candidate and the flag list may evolve before the stable release.\nThis page catalogues all configuration options for op-supernode, organized by functionality.\nThe following options are from the --help in op-supernode/v0.2.2-rc.8.\nFor recommended settings, deployment topologies, and a starter configuration, see the supernode configuration guide.\nFor what op-supernode is and why it exists, see the supernode explainer.\nEnvironment-variable names don’t always derive mechanically from the CLI flag name.\nSome env-var suffixes keep op-node’s source-level spelling even when the CLI flag was renamed (for example, --vn.<chainID>.l2 is set by OP_SUPERNODE_VN_<chainID>_L2_ENGINE_RPC, not OP_SUPERNODE_VN_<chainID>_L2).\nThe per-flag entries below show the correct env-var name alongside the CLI form.\nWhen in doubt, run op-supernode --chains=<chainIDs> --help for the authoritative name of any flag.\n​Dependency set and storage\n​chains\nThe list of chain IDs that this supernode hosts.\nRequired.\nAccepts a comma-separated list or a repeatable flag.\nEach chain ID must have a matching set of per-chain --vn.<chainID>.* flags that configure the chain’s network identity and execution-client connection.\n Syntax Example Environment Variable--chains=<value>--chains=11155420,1301OP_SUPERNODE_CHAINS=\n​data-dir\nData directory for op-supernode.\nEach chain’s SafeDB and P2P state is stored in a chain-<chainID> subdirectory under this path so the chains cannot collide.\nThe default value is ./datadir.\n Syntax Example Environment Variable--data-dir=<value>--data-dir=/var/lib/op-supernodeOP_SUPERNODE_DATA_DIR=\n​Shared L1 access\nThe supernode shares one L1 client and one beacon client across every chain in the dependency set.\nThese are the supernode’s own in-process clients (caching layers in front of remote endpoints), not the remote L1 node and beacon node themselves — the supernode connects to existing endpoints rather than running its own.\nConfigure these flags at the top level only — the per-chain namespace also includes --vn.<chainID>.l1 and --vn.<chainID>.l1.beacon (because the supernode mechanically clones every op-node flag into the namespace), but the supernode discards them at startup.\n​l1\nAddress of the L1 user JSON-RPC endpoint.\nRequired.\nThe eth namespace must be enabled on the endpoint.\n Syntax Example Environment Variable--l1=<value>--l1=https://ethereum-rpc-endpoint.example.comOP_SUPERNODE_L1_ETH_RPC=\n​l1.beacon\nAddress of the L1 beacon-node HTTP endpoint.\nRequired for any chain that depends on blob-derived L1 data, which covers every post-Ecotone OP Stack chain.\n Syntax Example Environment Variable--l1.beacon=<value>--l1.beacon=https://ethereum-beacon-endpoint.example.comOP_SUPERNODE_L1_BEACON=\n​l1.beacon-fallbacks\nAddresses of L1 beacon-API-compatible HTTP fallback endpoints.\nUsed to fetch blob sidecars not available at the primary --l1.beacon endpoint, including blobs that have aged past a regular beacon node’s prune window.\nThe --l1.beacon-archiver alias points at the same flag.\nAccepts a comma-separated list or a repeatable flag.\n Syntax Example Environment Variable--l1.beacon-fallbacks=<value>--l1.beacon-fallbacks=https://archiver-1.example.com,https://archiver-2.example.comOP_SUPERNODE_L1_BEACON_FALLBACKS=\n​l1.http-poll-interval\nPolling interval for the shared L1 HTTP RPC subscription.\nThe default value is 12s.\nThis flag controls the supernode’s own L1 client.\nPer-chain --vn.<chainID>.l1.http-poll-interval settings are ignored because the shared client owns the resource.\n Syntax Example Environment Variable--l1.http-poll-interval=<value>--l1.http-poll-interval=12sOP_SUPERNODE_L1_HTTP_POLL_INTERVAL=\n​Per-chain virtual-node configuration\nEvery chain in --chains runs as a virtual node inside the supernode.\nThe supernode reproduces the full op-node flag set under two prefixes so you can configure each chain.\n\n--vn.<chainID>.<flag> sets <flag> for one specific chain.\n--vn.all.<flag> sets <flag> for every chain in the dependency set.\n\nThe environment-variable form follows the same prefix rule: OP_SUPERNODE_VN_<CHAINID>_<SUFFIX> for one chain and OP_SUPERNODE_VN_ALL_<SUFFIX> for every chain.\nThe <SUFFIX> is the op-node flag’s source-level environment-variable name (see the note at the top of this page for why it doesn’t always match the CLI flag).\nA few flags are owned by the supernode rather than by individual virtual nodes.\nSetting them under --vn.<chainID>.* or --vn.all.* has no effect.\n--l1 and --l1.beacon: the shared L1 plumbing replaces any per-chain L1 setting at startup.\n--l1.http-poll-interval: the shared L1 client owns the polling cadence; the supernode logs a warning if a per-chain value is set.\n--log.*: the supernode and every virtual node share one logger; top-level --log.* configures it. Per-chain --vn.*.log.* flags appear in the namespace but are silently ignored. (--metrics.* is different: top-level configures the supernode’s own metrics service, but per-chain --vn.*.metrics.* configures each virtual node’s own metrics, which are fanned into the same endpoint with per-chain Prometheus labels.)\nP2P listen ports: see the P2P section.\n\nThe flags most operators need to set per chain are listed below.\nFor the full set of op-node flags available under the --vn.* namespace, see the op-node configuration reference and the consensus client configuration page.\n​vn.<chainID>.network\nNames the chain’s known network configuration so the supernode can load the matching rollup config from op-node’s built-in registry.\nUse this for any chain registered with op-node (op-mainnet, op-sepolia, unichain-sepolia, etc.).\n Syntax Example Environment Variable--vn.<chainID>.network=<value>--vn.11155420.network=op-sepoliaOP_SUPERNODE_VN_<CHAINID>_NETWORK=\n​vn.<chainID>.rollup.config\nPath to a rollup configuration JSON file for chains that are not in op-node’s built-in network registry.\nUse this instead of --vn.<chainID>.network for custom devnets or any chain you have a rollup config file for.\n Syntax Example Environment Variable--vn.<chainID>.rollup.config=<value>--vn.420120037.rollup.config=/etc/op/rollup-config.jsonOP_SUPERNODE_VN_<CHAINID>_ROLLUP_CONFIG=\n​vn.<chainID>.l2\nAddress of the engine-API endpoint for the chain’s execution client.\nEach chain needs its own execution client; one execution client cannot back two chains.\n Syntax Example Environment Variable--vn.<chainID>.l2=<value>--vn.11155420.l2=http://op-sepolia-geth:8551OP_SUPERNODE_VN_<CHAINID>_L2_ENGINE_RPC=\n​vn.all.l2.jwt-secret\nPath to the JWT secret used to authenticate every virtual node’s engine connection to its execution client.\nSet this at the vn.all.* level when every execution client in the dependency set shares one secret.\nUse the per-chain --vn.<chainID>.l2.jwt-secret form only when a chain’s execution client requires its own secret.\n Syntax Example Environment Variable--vn.all.l2.jwt-secret=<value>--vn.all.l2.jwt-secret=/etc/op/jwt-secret.txtOP_SUPERNODE_VN_ALL_L2_ENGINE_AUTH=\n​vn.<chainID>.l2.enginekind\nSelects the engine-client variant so the supernode can apply engine-API behavior tailored to each.\nSet to reth when the chain’s execution client is op-reth; leave at the default for op-geth.\nSupported values are geth and reth.\nThe default value is geth.\n Syntax Example Environment Variable--vn.<chainID>.l2.enginekind=<value>--vn.11155420.l2.enginekind=rethOP_SUPERNODE_VN_<CHAINID>_L2_ENGINE_KIND=\n​P2P\nP2P is enabled at the supernode level for every chain, or disabled for every chain.\nPer-chain enable/disable is not supported.\n​disable-p2p\nDisables P2P for every chain.\nThe default value is false.\nUse this in topologies where unsafe-head P2P gossip is handled by other nodes in the fleet (for example, a Light CL fleet) and the supernode only needs to derive from L1.\n Syntax Example Environment Variable--disable-p2p=<value>--disable-p2p=trueOP_SUPERNODE_DISABLE_P2P=\n​Per-chain listen ports\nWhen P2P is enabled, each virtual node’s P2P listen port defaults to 0 (dynamic) to prevent port collisions across chains.\nSetting --vn.all.p2p.listen.tcp or --vn.all.p2p.listen.udp to a non-zero value is rejected because the same port cannot be reused across virtual nodes.\nTo pin static ports per chain, set both the TCP (RLPx) and UDP (discovery v5) ports with the per-chain form:\n--vn.11155420.p2p.listen.tcp=9222 \\\n--vn.11155420.p2p.listen.udp=9222 \\\n--vn.1301.p2p.listen.tcp=9223 \\\n--vn.1301.p2p.listen.udp=9223\n\n​Interop verification\nThe interop activity is the part of op-supernode that decides when a chain’s blocks have satisfied their cross-chain dependencies.\nFor background on how the activity decides between wait, advance, invalidate, and rewind, see the supernode explainer.\n​interop.activation-timestamp\nOverrides the interop activation timestamp derived from the loaded rollup configs.\nThe default value is 0 (use the value from the rollup config).\nSet this only when activating interop on a custom devnet whose rollup config does not yet carry the activation timestamp.\n Syntax Example Environment Variable--interop.activation-timestamp=<value>--interop.activation-timestamp=1735689600OP_SUPERNODE_INTEROP_ACTIVATION_TIMESTAMP=\n​interop.log-backfill-depth\nExtends initiating-message log ingestion backward from the L2 tip by this duration, clamped to the interop activation timestamp.\nValidation still starts only beyond the local safe head; the backfill pre-ingests logs so they are available when validation needs them.\nRequires the interop activation timestamp to be known, either from the rollup config or via --interop.activation-timestamp.\nThe default value is 0s (no backfill).\n Syntax Example Environment Variable--interop.log-backfill-depth=<value>--interop.log-backfill-depth=168hOP_SUPERNODE_INTEROP_LOG_BACKFILL_DEPTH=\n​JSON-RPC server\nThe supernode exposes a single JSON-RPC server that multiplexes activity methods and every chain’s op-node RPC under one HTTP endpoint.\nPer-chain RPC namespaces are mounted under a /<chainID>/ path prefix on the same server.\nFor example, POST /11155420/ reaches the OP Sepolia op-node RPC surface.\nActivity RPC methods (superroot_atTimestamp, supernode_syncStatus, heartbeat_check) are exposed at the root.\nFor example, POST / with method superroot_atTimestamp reaches the SuperRoot activity.\n​rpc.addr\nAddress the JSON-RPC server binds to.\nThe default value is 0.0.0.0.\n Syntax Example Environment Variable--rpc.addr=<value>--rpc.addr=0.0.0.0OP_SUPERNODE_RPC_ADDR=\n​rpc.port\nPort the JSON-RPC server listens on.\nThe default value is 8545.\n Syntax Example Environment Variable--rpc.port=<value>--rpc.port=8545OP_SUPERNODE_RPC_PORT=\n​rpc.enable-admin\nEnables admin-namespace RPC methods.\nThe default value is false.\nEnable this only on endpoints that are not exposed to untrusted networks.\n Syntax Example Environment Variable--rpc.enable-admin=<value>--rpc.enable-admin=trueOP_SUPERNODE_RPC_ENABLE_ADMIN=\n​Logging\nLogging is configured at the top level.\nThe supernode and every virtual node share one logger; per-chain --vn.*.log.* flags appear in the namespace but are silently ignored.\n​log.level\nMinimum log severity to emit.\nValid values are trace, debug, info, warn, error, crit.\nThe default value is info.\n Syntax Example Environment Variable--log.level=<value>--log.level=infoOP_SUPERNODE_LOG_LEVEL=\n​log.format\nLog output format.\nValid values are text, terminal, logfmt, logfmtms, json, jsonms (the *ms variants append millisecond timestamps).\nThe default value is text.\nSet logfmt or json when ingesting logs into a structured-log pipeline; the default text is for hand-reading.\n Syntax Example Environment Variable--log.format=<value>--log.format=jsonOP_SUPERNODE_LOG_FORMAT=\n​log.color\nForces ANSI color codes in text log output regardless of whether the stream is a terminal.\nThe default value is false.\n Syntax Example Environment Variable--log.color=<value>--log.color=trueOP_SUPERNODE_LOG_COLOR=\n​Metrics and profiling\nMetrics and profiling endpoints are configured at the top level.\nThe metrics server fans in counters from every chain container and exposes them on one endpoint with per-chain Prometheus labels.\n​metrics.enabled\nEnables the Prometheus metrics server.\nThe default value is false.\n Syntax Example Environment Variable--metrics.enabled=<value>--metrics.enabled=trueOP_SUPERNODE_METRICS_ENABLED=\n​metrics.addr\nAddress the metrics server binds to.\nThe default value is 0.0.0.0.\n Syntax Example Environment Variable--metrics.addr=<value>--metrics.addr=0.0.0.0OP_SUPERNODE_METRICS_ADDR=\n​metrics.port\nPort the metrics server listens on.\nThe default value is 7300.\n Syntax Example Environment Variable--metrics.port=<value>--metrics.port=7300OP_SUPERNODE_METRICS_PORT=\n​pprof.enabled\nEnables the pprof profiling endpoint.\nThe default value is false.\n Syntax Example Environment Variable--pprof.enabled=<value>--pprof.enabled=trueOP_SUPERNODE_PPROF_ENABLED=\n​pprof.addr\nAddress the pprof server binds to.\nThe default value is 0.0.0.0.\n Syntax Example Environment Variable--pprof.addr=<value>--pprof.addr=0.0.0.0OP_SUPERNODE_PPROF_ADDR=\n​pprof.port\nPort the pprof server listens on.\nThe default value is 6060.\n Syntax Example Environment Variable--pprof.port=<value>--pprof.port=6060OP_SUPERNODE_PPROF_PORT=\n​Where to go next\n\nFollow the supernode configuration guide for recommended settings and a starter configuration.\nRead the supernode explainer for what op-supernode is and why it exists.\nRead the op-node configuration reference for the full set of flags available under the --vn.* namespace.\nSee the op-supernode source in the monorepo for implementation detail.\nWas this page helpful?","tokens":3414,"squid":"ink-governance","role":"Council Listener","at":1791266694332,"hash":"1eaf3d8405104a6d63ee0e0c687ec53b6113fc02"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api/token/ERC1155","domain":"docs.openzeppelin.com","title":"ERC1155 | OpenZeppelin Docs","text":"ERC1155Smart contract ERC1155 utilities and implementationsOpen in ClaudeThis set of interfaces and contracts are all related to the ERC-1155 Multi Token Standard.\nThe ERC consists of three interfaces which fulfill different roles, found here as IERC1155, IERC1155MetadataURI and IERC1155Receiver.\nERC1155 implements the mandatory IERC1155 interface, as well as the optional extension IERC1155MetadataURI, by relying on the substitution mechanism to use the same URI for all token types, dramatically reducing gas costs.\nAdditionally there are multiple custom extensions, including:\n\ndesignation of addresses that can pause token transfers for all users (ERC1155Pausable).\ndestruction of own tokens (ERC1155Burnable).\n\nThis core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC-1155 (such as _mint) and expose them as external functions in the way they prefer.\nCore\nIERC1155\nIERC1155MetadataURI\nERC1155\nIERC1155Receiver\nExtensions\nERC1155Pausable\nERC1155Burnable\nERC1155Supply\nERC1155URIStorage\nUtilities\nERC1155Holder\nERC1155Utils\n\nERC1155\nimport \"@openzeppelin/contracts/token/ERC1155/ERC1155.sol\";\nImplementation of the basic standard multi-token.\nSee https://eips.ethereum.org/EIPS/eip-1155\nOriginally based on code by Enjin: https://github.com/enjin/erc-1155\nFunctions\nconstructor(uri_)\nsupportsInterface(interfaceId)\nuri()\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\n_checkAuthorized(operator, owner)\n_update(from, to, ids, values)\n_updateWithAcceptanceCheck(from, to, ids, values, data)\n_updateWithAcceptanceCheck(from, to, ids, values, data, batch)\n_safeTransferFrom(from, to, id, value, data)\n_safeBatchTransferFrom(from, to, ids, values, data)\n_setURI(newuri)\n_mint(to, id, value, data)\n_mintBatch(to, ids, values, data)\n_burn(from, id, value)\n_burnBatch(from, ids, values)\n_setApprovalForAll(owner, operator, approved)\n\nEventsIERC1155\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nErrorsIERC1155Errors\nERC1155InsufficientBalance(sender, balance, needed, tokenId)\nERC1155InvalidSender(sender)\nERC1155InvalidReceiver(receiver)\nERC1155MissingApprovalForAll(operator, owner)\nERC1155InvalidApprover(approver)\nERC1155InvalidOperator(operator)\nERC1155InvalidArrayLength(idsLength, valuesLength)\n\nconstructor(string uri_)internal#See ERC1155._setURI.\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#Returns true if this contract implements the interface defined by\ninterfaceId. See the corresponding\nERC section\nto learn more about how these ids are created.This function call must use less than 30 000 gas.\n\nuri(uint256) → stringpublic#See IERC1155MetadataURI.uri.This implementation returns the same URI for all token types. It relies\non the token type ID substitution mechanism\ndefined in the ERC.Clients calling this function must replace the \\{id\\} substring with the\nactual token type ID.\n\nbalanceOf(address account, uint256 id) → uint256public#Returns the value of tokens of token type id owned by account.\n\nbalanceOfBatch(address[] accounts, uint256[] ids) → uint256[]public#See IERC1155.balanceOfBatch.Requirements:\naccounts and ids must have the same length.\n\nsetApprovalForAll(address operator, bool approved)public#Grants or revokes permission to operator to transfer the caller's tokens, according to approved,Emits an IERC1155.ApprovalForAll event.Requirements:\noperator cannot be the zero address.\n\nisApprovedForAll(address account, address operator) → boolpublic#Returns true if operator is approved to transfer account's tokens.See ERC1155.setApprovalForAll.\n\nsafeTransferFrom(address from, address to, uint256 id, uint256 value, bytes data)public#Transfers a value amount of tokens of type id from from to to.This function can potentially allow a reentrancy attack when transferring tokens\nto an untrusted contract, when invoking IERC1155Receiver.onERC1155Received on the receiver.\nEnsure to follow the checks-effects-interactions pattern and consider employing\nreentrancy guards when interacting with untrusted contracts.Emits a IERC1155.TransferSingle event.Requirements:\nto cannot be the zero address.\nIf the caller is not from, it must have been approved to spend from's tokens via ERC1155.setApprovalForAll.\nfrom must have a balance of tokens of type id of at least value amount.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155Received and return the\nacceptance magic value.\n\nsafeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] values, bytes data)public#Batched version of ERC1155.safeTransferFrom.This function can potentially allow a reentrancy attack when transferring tokens\nto an untrusted contract, when invoking IERC1155Receiver.onERC1155BatchReceived on the receiver.\nEnsure to follow the checks-effects-interactions pattern and consider employing\nreentrancy guards when interacting with untrusted contracts.Emits either a IERC1155.TransferSingle or a IERC1155.TransferBatch event, depending on the length of the array arguments.Requirements:\nids and values must have the same length.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155BatchReceived and return the\nacceptance magic value.\n\n_checkAuthorized(address operator, address owner)internal#Checks if operator is authorized to transfer tokens owned by owner. Reverts with IERC1155Errors.ERC1155MissingApprovalForAll if not.\n\n_update(address from, address to, uint256[] ids, uint256[] values)internal#Transfers a value amount of tokens of type id from from to to. Will mint (or burn) if from\n(or to) is the zero address.Emits a IERC1155.TransferSingle event if the arrays contain one element, and IERC1155.TransferBatch otherwise.Requirements:\nIf to refers to a smart contract, it must implement either IERC1155Receiver.onERC1155Received\nor IERC1155Receiver.onERC1155BatchReceived and return the acceptance magic value.\nids and values must have the same length.\nThe ERC-1155 acceptance check is not performed in this function. See ERC1155._updateWithAcceptanceCheck instead.\n\n_updateWithAcceptanceCheck(address from, address to, uint256[] ids, uint256[] values, bytes data)internal#Version of ERC1155._update that performs the token acceptance check by calling\nIERC1155Receiver.onERC1155Received or IERC1155Receiver.onERC1155BatchReceived on the receiver address if it\ncontains code (eg. is a smart contract at the moment of execution).Overriding this function is discouraged because it poses a reentrancy risk from the receiver. So any\nupdate to the contract state after this function would break the check-effect-interaction pattern. Consider\noverriding ERC1155._update instead.This version is kept for backward compatibility. We recommend calling the alternative version with a boolean\nflag in order to achieve better control over which hook to call.\n\n_updateWithAcceptanceCheck(address from, address to, uint256[] ids, uint256[] values, bytes data, bool batch)internal#Version of ERC1155._update that performs the token acceptance check by calling\nIERC1155Receiver.onERC1155Received or IERC1155Receiver.onERC1155BatchReceived on the receiver address if it\ncontains code (eg. is a smart contract at the moment of execution).Overriding this function is discouraged because it poses a reentrancy risk from the receiver. So any\nupdate to the contract state after this function would break the check-effect-interaction pattern. Consider\noverriding ERC1155._update instead.\n\n_safeTransferFrom(address from, address to, uint256 id, uint256 value, bytes data)internal#Transfers a value tokens of token type id from from to to.Emits a IERC1155.TransferSingle event.Requirements:\nto cannot be the zero address.\nfrom must have a balance of tokens of type id of at least value amount.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155Received and return the\nacceptance magic value.\n\n_safeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] values, bytes data)internal#Batched version of ERC1155._safeTransferFrom.Emits a IERC1155.TransferBatch event.Requirements:\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155BatchReceived and return the\nacceptance magic value.\nids and values must have the same length.\n\n_setURI(string newuri)internal#Sets a new URI for all token types, by relying on the token type ID\nsubstitution mechanism\ndefined in the ERC.By this mechanism, any occurrence of the \\{id\\} substring in either the\nURI or any of the values in the JSON file at said URI will be replaced by\nclients with the token type ID.For example, the https://token-cdn-domain/\\{id\\}.json URI would be\ninterpreted by clients as\nhttps://token-cdn-domain/000000000000000000000000000000000000000000000000000000000004cce0.json\nfor token type ID 0x4cce0.See ERC1155.uri.Because these URIs cannot be meaningfully represented by the IERC1155.URI event,\nthis function emits no events.\n\n_mint(address to, uint256 id, uint256 value, bytes data)internal#Creates a value amount of tokens of type id, and assigns them to to.Emits a IERC1155.TransferSingle event.Requirements:\nto cannot be the zero address.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155Received and return the\nacceptance magic value.\n\n_mintBatch(address to, uint256[] ids, uint256[] values, bytes data)internal#Batched version of ERC1155._mint.Emits a IERC1155.TransferBatch event.Requirements:\nids and values must have the same length.\nto cannot be the zero address.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155BatchReceived and return the\nacceptance magic value.\n\n_burn(address from, uint256 id, uint256 value)internal#Destroys a value amount of tokens of type id from fromEmits a IERC1155.TransferSingle event.Requirements:\nfrom cannot be the zero address.\nfrom must have at least value amount of tokens of type id.\n\n_burnBatch(address from, uint256[] ids, uint256[] values)internal#Batched version of ERC1155._burn.Emits a IERC1155.TransferBatch event.Requirements:\nfrom cannot be the zero address.\nfrom must have at least value amount of tokens of type id.\nids and values must have the same length.\n\n_setApprovalForAll(address owner, address operator, bool approved)internal#Approve operator to operate on all of owner tokensEmits an IERC1155.ApprovalForAll event.Requirements:\nowner cannot be the zero address.\noperator cannot be the zero address.\n\nIERC1155\nimport \"@openzeppelin/contracts/token/ERC1155/IERC1155.sol\";\nRequired interface of an ERC-1155 compliant contract, as defined in the\nERC.\nFunctions\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\nIERC165\nsupportsInterface(interfaceId)\n\nEvents\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nbalanceOf(address account, uint256 id) → uint256external#Returns the value of tokens of token type id owned by account.\n\nbalanceOfBatch(address[] accounts, uint256[] ids) → uint256[]external#Batched version of ERC1155.balanceOf.Requirements:\naccounts and ids must have the same length.\n\nsetApprovalForAll(address operator, bool approved)external#Grants or revokes permission to operator to transfer the caller's tokens, according to approved,Emits an IERC1155.ApprovalForAll event.Requirements:\noperator cannot be the zero address.\n\nisApprovedForAll(address account, address operator) → boolexternal#Returns true if operator is approved to transfer account's tokens.See ERC1155.setApprovalForAll.\n\nsafeTransferFrom(address from, address to, uint256 id, uint256 value, bytes data)external#Transfers a value amount of tokens of type id from from to to.This function can potentially allow a reentrancy attack when transferring tokens\nto an untrusted contract, when invoking IERC1155Receiver.onERC1155Received on the receiver.\nEnsure to follow the checks-effects-interactions pattern and consider employing\nreentrancy guards when interacting with untrusted contracts.Emits a IERC1155.TransferSingle event.Requirements:\nto cannot be the zero address.\nIf the caller is not from, it must have been approved to spend from's tokens via ERC1155.setApprovalForAll.\nfrom must have a balance of tokens of type id of at least value amount.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155Received and return the\nacceptance magic value.\n\nsafeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] values, bytes data)external#Batched version of ERC1155.safeTransferFrom.This function can potentially allow a reentrancy attack when transferring tokens\nto an untrusted contract, when invoking IERC1155Receiver.onERC1155BatchReceived on the receiver.\nEnsure to follow the checks-effects-interactions pattern and consider employing\nreentrancy guards when interacting with untrusted contracts.Emits either a IERC1155.TransferSingle or a IERC1155.TransferBatch event, depending on the length of the array arguments.Requirements:\nids and values must have the same length.\nIf to refers to a smart contract, it must implement IERC1155Receiver.onERC1155BatchReceived and return the\nacceptance magic value.\n\nTransferSingle(address indexed operator, address indexed from, address indexed to, uint256 id, uint256 value)event#Emitted when value amount of tokens of type id are transferred from from to to by operator.\n\nTransferBatch(address indexed operator, address indexed from, address indexed to, uint256[] ids, uint256[] values)event#Equivalent to multiple IERC1155.TransferSingle events, where operator, from and to are the same for all\ntransfers.\n\nApprovalForAll(address indexed account, address indexed operator, bool approved)event#Emitted when account grants or revokes permission to operator to transfer their tokens, according to\napproved.\n\nURI(string value, uint256 indexed id)event#Emitted when the URI for token type id changes to value, if it is a non-programmatic URI.If an IERC1155.URI event was emitted for id, the standard\nguarantees that value will equal the value\nreturned by IERC1155MetadataURI.uri.\n\nIERC1155Receiver\nimport \"@openzeppelin/contracts/token/ERC1155/IERC1155Receiver.sol\";\nInterface that must be implemented by smart contracts in order to receive\nERC-1155 token transfers.\nFunctions\nonERC1155Received(operator, from, id, value, data)\nonERC1155BatchReceived(operator, from, ids, values, data)\nIERC165\nsupportsInterface(interfaceId)\n\nonERC1155Received(address operator, address from, uint256 id, uint256 value, bytes data) → bytes4external#Handles the receipt of a single ERC-1155 token type. This function is\ncalled at the end of a safeTransferFrom after the balance has been updated.To accept the transfer, this must return\nbytes4(keccak256(\"onERC1155Received(address,address,uint256,uint256,bytes)\"))\n(i.e. 0xf23a6e61, or its own function selector).\n\nonERC1155BatchReceived(address operator, address from, uint256[] ids, uint256[] values, bytes data) → bytes4external#Handles the receipt of a multiple ERC-1155 token types. This function\nis called at the end of a safeBatchTransferFrom after the balances have\nbeen updated.To accept the transfer(s), this must return\nbytes4(keccak256(\"onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)\"))\n(i.e. 0xbc197c81, or its own function selector).\n\nERC1155Burnable\nimport \"@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Burnable.sol\";\nExtension of ERC1155 that allows token holders to destroy both their\nown tokens and those that they have been approved to use.\nFunctions\nburn(account, id, value)\nburnBatch(account, ids, values)\nERC1155\nsupportsInterface(interfaceId)\nuri()\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\n_checkAuthorized(operator, owner)\n_update(from, to, ids, values)\n_updateWithAcceptanceCheck(from, to, ids, values, data)\n_updateWithAcceptanceCheck(from, to, ids, values, data, batch)\n_safeTransferFrom(from, to, id, value, data)\n_safeBatchTransferFrom(from, to, ids, values, data)\n_setURI(newuri)\n_mint(to, id, value, data)\n_mintBatch(to, ids, values, data)\n_burn(from, id, value)\n_burnBatch(from, ids, values)\n_setApprovalForAll(owner, operator, approved)\n\nEventsIERC1155\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nErrorsIERC1155Errors\nERC1155InsufficientBalance(sender, balance, needed, tokenId)\nERC1155InvalidSender(sender)\nERC1155InvalidReceiver(receiver)\nERC1155MissingApprovalForAll(operator, owner)\nERC1155InvalidApprover(approver)\nERC1155InvalidOperator(operator)\nERC1155InvalidArrayLength(idsLength, valuesLength)\n\nburn(address account, uint256 id, uint256 value)public#\n\nburnBatch(address account, uint256[] ids, uint256[] values)public#\n\nERC1155Pausable\nimport \"@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Pausable.sol\";\nERC-1155 token with pausable token transfers, minting and burning.\nUseful for scenarios such as preventing trades until the end of an evaluation\nperiod, or having an emergency switch for freezing all token transfers in the\nevent of a large bug.\nThis contract does not include public pause and unpause functions. In\naddition to inheriting this contract, you must define both functions, invoking the\nPausable._pause and Pausable._unpause internal functions, with appropriate\naccess control, e.g. using AccessControl or Ownable. Not doing so will\nmake the contract pause mechanism of the contract unreachable, and thus unusable.\nFunctions\n_update(from, to, ids, values)\nPausable\npaused()\n_requireNotPaused()\n_requirePaused()\n_pause()\n_unpause()\nERC1155\nsupportsInterface(interfaceId)\nuri()\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\n_checkAuthorized(operator, owner)\n_updateWithAcceptanceCheck(from, to, ids, values, data)\n_updateWithAcceptanceCheck(from, to, ids, values, data, batch)\n_safeTransferFrom(from, to, id, value, data)\n_safeBatchTransferFrom(from, to, ids, values, data)\n_setURI(newuri)\n_mint(to, id, value, data)\n_mintBatch(to, ids, values, data)\n_burn(from, id, value)\n_burnBatch(from, ids, values)\n_setApprovalForAll(owner, operator, approved)\n\nEventsPausable\nPaused(account)\nUnpaused(account)\nIERC1155\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nErrorsPausable\nEnforcedPause()\nExpectedPause()\nIERC1155Errors\nERC1155InsufficientBalance(sender, balance, needed, tokenId)\nERC1155InvalidSender(sender)\nERC1155InvalidReceiver(receiver)\nERC1155MissingApprovalForAll(operator, owner)\nERC1155InvalidApprover(approver)\nERC1155InvalidOperator(operator)\nERC1155InvalidArrayLength(idsLength, valuesLength)\n\n_update(address from, address to, uint256[] ids, uint256[] values)internal#See ERC1155._update.Requirements:\nthe contract must not be paused.\n\nERC1155Supply\nimport \"@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol\";\nExtension of ERC-1155 that adds tracking of total supply per id.\nUseful for scenarios where Fungible and Non-fungible tokens have to be\nclearly identified. Note: While a totalSupply of 1 may mean the\ncorresponding token is an NFT, there are no inherent guarantees that\nno more tokens with the same id will be minted in future.\nThis contract implies a global limit of 2**256 - 1 to the number of tokens\nthat can be minted.\nThis extension should not be added in an upgrade to an already deployed contract.\nFunctions\ntotalSupply(id)\ntotalSupply()\nexists(id)\n_update(from, to, ids, values)\nERC1155\nsupportsInterface(interfaceId)\nuri()\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\n_checkAuthorized(operator, owner)\n_updateWithAcceptanceCheck(from, to, ids, values, data)\n_updateWithAcceptanceCheck(from, to, ids, values, data, batch)\n_safeTransferFrom(from, to, id, value, data)\n_safeBatchTransferFrom(from, to, ids, values, data)\n_setURI(newuri)\n_mint(to, id, value, data)\n_mintBatch(to, ids, values, data)\n_burn(from, id, value)\n_burnBatch(from, ids, values)\n_setApprovalForAll(owner, operator, approved)\n\nEventsIERC1155\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nErrorsIERC1155Errors\nERC1155InsufficientBalance(sender, balance, needed, tokenId)\nERC1155InvalidSender(sender)\nERC1155InvalidReceiver(receiver)\nERC1155MissingApprovalForAll(operator, owner)\nERC1155InvalidApprover(approver)\nERC1155InvalidOperator(operator)\nERC1155InvalidArrayLength(idsLength, valuesLength)\n\ntotalSupply(uint256 id) → uint256public#Total value of tokens with a given id.\n\ntotalSupply() → uint256public#Total value of tokens.\n\nexists(uint256 id) → boolpublic#Indicates whether any tokens exist with a given id, or not.\n\n_update(address from, address to, uint256[] ids, uint256[] values)internal#Transfers a value amount of tokens of type id from from to to. Will mint (or burn) if from\n(or to) is the zero address.Emits a IERC1155.TransferSingle event if the arrays contain one element, and IERC1155.TransferBatch otherwise.Requirements:\nIf to refers to a smart contract, it must implement either IERC1155Receiver.onERC1155Received\nor IERC1155Receiver.onERC1155BatchReceived and return the acceptance magic value.\nids and values must have the same length.\nThe ERC-1155 acceptance check is not performed in this function. See ERC1155._updateWithAcceptanceCheck instead.\n\nERC1155URIStorage\nimport \"@openzeppelin/contracts/token/ERC1155/extensions/ERC1155URIStorage.sol\";\nERC-1155 token with storage based token URI management.\nInspired by the ERC721URIStorage extension\nFunctions\nuri(tokenId)\n_setURI(tokenId, tokenURI)\n_setBaseURI(baseURI)\nERC1155\nsupportsInterface(interfaceId)\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\n_checkAuthorized(operator, owner)\n_update(from, to, ids, values)\n_updateWithAcceptanceCheck(from, to, ids, values, data)\n_updateWithAcceptanceCheck(from, to, ids, values, data, batch)\n_safeTransferFrom(from, to, id, value, data)\n_safeBatchTransferFrom(from, to, ids, values, data)\n_setURI(newuri)\n_mint(to, id, value, data)\n_mintBatch(to, ids, values, data)\n_burn(from, id, value)\n_burnBatch(from, ids, values)\n_setApprovalForAll(owner, operator, approved)\n\nEventsIERC1155\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nErrorsIERC1155Errors\nERC1155InsufficientBalance(sender, balance, needed, tokenId)\nERC1155InvalidSender(sender)\nERC1155InvalidReceiver(receiver)\nERC1155MissingApprovalForAll(operator, owner)\nERC1155InvalidApprover(approver)\nERC1155InvalidOperator(operator)\nERC1155InvalidArrayLength(idsLength, valuesLength)\n\nuri(uint256 tokenId) → stringpublic#See IERC1155MetadataURI.uri.This implementation returns the concatenation of the _baseURI\nand the token-specific uri if the latter is setThis enables the following behaviors:\n\nif _tokenURIs[tokenId] is set, then the result is the concatenation\nof _baseURI and _tokenURIs[tokenId] (keep in mind that _baseURI\nis empty per default);\n\nif _tokenURIs[tokenId] is NOT set then we fallback to super.uri()\nwhich in most cases will contain ERC1155._uri;\n\nif _tokenURIs[tokenId] is NOT set, and if the parents do not have a\nuri value set, then the result is empty.\n\n_setURI(uint256 tokenId, string tokenURI)internal#Sets tokenURI as the tokenURI of tokenId.\n\n_setBaseURI(string baseURI)internal#Sets baseURI as the _baseURI for all tokens\n\nIERC1155MetadataURI\nimport \"@openzeppelin/contracts/token/ERC1155/extensions/IERC1155MetadataURI.sol\";\nInterface of the optional ERC1155MetadataExtension interface, as defined\nin the ERC.\nFunctions\nuri(id)\nIERC1155\nbalanceOf(account, id)\nbalanceOfBatch(accounts, ids)\nsetApprovalForAll(operator, approved)\nisApprovedForAll(account, operator)\nsafeTransferFrom(from, to, id, value, data)\nsafeBatchTransferFrom(from, to, ids, values, data)\nIERC165\nsupportsInterface(interfaceId)\n\nEventsIERC1155\nTransferSingle(operator, from, to, id, value)\nTransferBatch(operator, from, to, ids, values)\nApprovalForAll(account, operator, approved)\nURI(value, id)\n\nuri(uint256 id) → stringexternal#Returns the URI for token type id.If the \\{id\\} substring is present in the URI, it must be replaced by\nclients with the actual token type ID.\n\nERC1155Holder\nimport \"@openzeppelin/contracts/token/ERC1155/utils/ERC1155Holder.sol\";\nSimple implementation of IERC1155Receiver that will allow a contract to hold ERC-1155 tokens.\nWhen inheriting this contract, you must include a way to use the received tokens, otherwise they will be\nstuck.\n@custom:stateless\nFunctions\nsupportsInterface(interfaceId)\nonERC1155Received(, , , , )\nonERC1155BatchReceived(, , , , )\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#Returns true if this contract implements the interface defined by\ninterfaceId. See the corresponding\nERC section\nto learn more about how these ids are created.This function call must use less than 30 000 gas.\n\nonERC1155Received(address, address, uint256, uint256, bytes) → bytes4public#\n\nonERC1155BatchReceived(address, address, uint256[], uint256[], bytes) → bytes4public#\n\nERC1155Utils\nimport \"@openzeppelin/contracts/token/ERC1155/utils/ERC1155Utils.sol\";\nLibrary that provide common ERC-1155 utility functions.\nSee ERC-1155.\nAvailable since v5.1.\nFunctions\ncheckOnERC1155Received(operator, from, to, id, value, data)\ncheckOnERC1155BatchReceived(operator, from, to, ids, values, data)\n\ncheckOnERC1155Received(address operator, address from, address to, uint256 id, uint256 value, bytes data)internal#Performs an acceptance check for the provided operator by calling IERC1155Receiver.onERC1155Received\non the to address. The operator is generally the address that initiated the token transfer (i.e. msg.sender).The acceptance call is not executed and treated as a no-op if the target address doesn't contain code (i.e. an EOA).\nOtherwise, the recipient must implement IERC1155Receiver.onERC1155Received and return the acceptance magic value to accept\nthe transfer.\n\ncheckOnERC1155BatchReceived(address operator, address from, address to, uint256[] ids, uint256[] values, bytes data)internal#Performs a batch acceptance check for the provided operator by calling IERC1155Receiver.onERC1155BatchReceived\non the to address. The operator is generally the address that initiated the token transfer (i.e. msg.sender).The acceptance call is not executed and treated as a no-op if the target address doesn't contain code (i.e. an EOA).\nOtherwise, the recipient must implement IERC1155Receiver.onERC1155Received and return the acceptance magic value to accept\nthe transfer.On this pageCoreExtensionsUtilitiesERC1155IERC1155IERC1155ReceiverERC1155BurnableERC1155PausableERC1155SupplyERC1155URIStorageIERC1155MetadataURIERC1155HolderERC1155Utils","tokens":6953,"squid":"ink-security_audits","role":"Sentinel","at":1791266694617,"hash":"bc765b71ee8291f02354b298ffc4f4357a8921d3"}
{"url":"https://www.pyth.network/blog/introducing-pyth-network","domain":"pyth.network","title":"Hello World! Welcome to the Pyth Network - Pyth Network — The Price of Everything","text":"Announcements·Apr 7, 2021Hello World! Welcome to the Pyth NetworkPyth Network: A new oracle solution built by finance & DeFi leaders, offering fast, secure data access for DeFi growth.Today, we’re beyond excited to introduce the Pyth Network, a next-generation oracle solution designed to bring HiFi data to DeFi.Pyth Network is being built by some of the biggest names in traditional finance and DeFi with the goal of providing the infrastructure for DeFi to support substantial growth in the market. This requires legally authorized access to unique data sets, sub-second update speeds, sophisticated outputs, and aggregation methods, and a thorough incentive system to ward off spurious or malicious data breaches.Why Are We Doing This?1. We think DeFi likely will grow. A lot. If DeFi reaches its full potential, it could grow to multiple trillions of dollars of TVL spanning the vanguard users of today to the largest institutions. The tools to empower that exponential growth needs to be robust. The iPhone enabled an entirely new industry of companies, but there were many components that had been built over a long period of time to make the iPhone possible. At some point, there could be an iPhone moment in DeFi and we can only hope that Pyth Network will be one of the components that enable this type of innovation.2. The oracle problem for latency-sensitive, continuous data needs to be solved. Reliable, institutional-grade market data oracles are lacking in DeFi, and we hope to fill that gap. There are many idiosyncrasies with this type of data that require a special type of oracle solution. Existing solutions focus on harnessing the wisdom of crowds to source data. We admire and encourage those projects and think that Pyth Network will be complementary.3. Pyth quoters have troves of data. Over the years, data has become a big business, typically owned by one or a few centralized providers of data. Pyth Network has attracted some of the largest traders and exchanges who have lots of data, but for whom selling data is not a primary business. Using the power of decentralization, we hope to pool that unharnessed data and create alternative sources of high-quality composite market data.4. We believe in fair and transparent markets governed by users. Blockchains are unique in the transparency they provide with mechanisms for decision-making by users in a fair and transparent way. Pyth Network is designed to be open and accessible. There will be roles for all interested and motivated participants from providing and consuming data, to securing that data or helping determine which data to source. By enabling a diverse ecosystem of participants, we think Pyth Network will continue to innovate and strive to provide the market with the tools it needs.What’s Next?This is our hello world moment. Over the next two weeks, we plan to roll out a beta version available for testing. We encourage you to get in touch if you are building something that could benefit from a fast and reliable oracle for financial market data. We also encourage you to get in touch if you have the legal right to publish a unique data set of latency-sensitive data.We can’t wait to hear what you think! You can join the Pyth Discord and Telegram, follow us on Twitter. You can also learn more about Pyth here.Today, we’re beyond excited to introduce the Pyth Network, a next-generation oracle solution designed to bring HiFi data to DeFi.Pyth Network is being built by some of the biggest names in traditional finance and DeFi with the goal of providing the infrastructure for DeFi to support substantial growth in the market. This requires legally authorized access to unique data sets, sub-second update speeds, sophisticated outputs, and aggregation methods, and a thorough incentive system to ward off sRead nextView allPyth September 2026 ReportPyth September 2026 ReportBuilding Market Data for a Machine-Readable Financial System Building Market Data for a Machine-Readable Financial System Lighter Explores Pyth Indices as It Expands Perpetual Markets Beyond CryptoLighter Explores Pyth Indices as It Expands Perpetual Markets Beyond CryptoThe Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":1223,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266697965,"hash":"254513637e4f5164dd054ee0f2b5118b275855a9"}
{"url":"https://docs.optimism.io/op-stack/interop/supernode","domain":"docs.optimism.io","title":"Optimism Documentation","text":"OP Stack interop is in active development.\nop-supernode is the runtime that operators of interop chains will run, and the architecture and interfaces described here may continue to evolve as the rollout progresses.\n​OP Supernode\nop-supernode is a component that runs every chain in an interop dependency set together as virtual nodes inside one binary.\nWhere a pre-interop deployment runs one op-node per chain, op-supernode hosts every chain side by side, shares the L1 and beacon-chain plumbing across them, and adds the cross-chain message verification work that interop needs.\n​Why op-supernode exists\nOP Stack interop changes what a single node has to do.\nBefore interop, a node only had to derive its own chain.\nWith interop, a node has to derive every chain in its dependency set, because any of those chains can emit an initiating message that the local chain depends on.\nThe local chain cannot advance past a block whose dependencies it cannot prove, so the derivation of every other chain in the set is on the critical path.\nWithout consolidation, every operator runs a full op-node and execution client for every chain in the dependency set.\nThat duplicates the L1 client, the beacon-chain client, the derivation pipeline, the storage layout, and the operational glue around each one.\nFor a fully-connected dependency set — the configuration the Superchain interop cluster targets — the duplication scales with the size of the cluster.\nop-supernode collapses that duplication.\nIt runs each chain as an in-memory virtual node inside one process, with a single L1 client and a single beacon client serving all of them, and adds the cross-chain message verification work above the per-chain layer.\n​How op-supernode works\nThe supernode is composed of chain containers and activities.\nEach chain container hosts one virtual node for one chain.\nActivities are modular components that operate above the chain layer, with access to every chain.\n\n​Chain containers\nA chain container is the supernode’s wrapper around one chain.\nInside a chain container is a virtual node: a consensus-layer (CL) implementation hosted in-process rather than as a separate operating-system process.\nToday the only virtual node implementation is op-node itself, hosted as a library; the chain container manages its lifecycle (start, stop, pause, resume) and exposes a stable interface to the rest of the supernode.\nChain containers also drive the execution engine for the chain through an engine controller.\nThey expose the operations the supernode needs to verify cross-chain messages — deriving the local-safe block at a timestamp, fetching receipts, answering output-root queries — without reaching into the internals of any one chain.\n​Shared resources\nRunning every chain inside one process makes shared resources possible.\n\nA single L1 RPC client and a single L1 beacon client serve every chain. Cache hits on L1 blocks and blob lookups carry across chains.\nThe JSON-RPC surface is namespaced per chain. 11155420/ reaches OP Sepolia’s RPC; 1301/ reaches Unichain Sepolia’s. Tools that expect an op-node-shaped endpoint reach a chain by addressing it through that prefix.\nMetrics are namespaced per chain via the same scheme.\nData directories are namespaced so SafeDB and P2P state for one chain cannot collide with another’s.\n\nSome flags are intentionally owned at the supernode level rather than per chain.\n--l1 and --l1.beacon configure the shared L1 plumbing, and any per-chain override of them is silently replaced with the top-level value.\n​Activities\nAn activity is a modular component that operates above the chain layer rather than inside any one chain.\nEach activity can register an RPC namespace on the supernode root, expose Prometheus metrics, and run a goroutine for as long as the supernode is up.\nThe supernode ships with a small set of activities:\n\nHeartbeat — emits a liveness signal and exposes heartbeat_check over JSON-RPC.\nSuperRoot — produces a super root: a commitment over verified L2 blocks across the dependency set at a given timestamp. Exposed as superroot_atTimestamp. The fault proof system needs this commitment to produce an interop-aware proof.\nSupernode — exposes supernode_syncStatus, an aggregate per-chain sync status across the dependency set.\nInterop — does the actual cross-chain message verification (see the next section).\n\n​Cross-chain message safety\nThe interop activity is the part of op-supernode that decides when a chain’s blocks have satisfied their cross-chain dependencies and can be promoted past unsafe.\nIt runs above the chain containers and reaches into them through a narrow interface.\nFor every block produced on every chain, the interop activity answers one question: have all the initiating messages this block executes been reproduced from L1, and at the same safety level the destination block is trying to reach?\nThe activity decides per round between wait, advance, invalidate, and rewind.\nThe decision is recorded in a write-ahead log so the supernode can pick up after a restart in the same state it was in before.\nWhen the answer is advance, the supernode signals the chain’s CL to promote the block.\nThe signal flows through an authority interface that the chain container holds and the virtual node defers to: the supernode advances safety on a chain only via the chain’s own CL.\nThe CL stays the single source of truth for safety on its chain, and the execution layer (EL) never has to learn about interop.\nWhen the answer is invalidate or rewind, the supernode tells the chain to back out the affected blocks.\nA block on chain B that referenced a chain-A log can be invalidated because the chain-A log never made it to L1, or because the L1 record contradicts what was gossiped over P2P.\nSee Interop reorg awareness for how that plays out at the chain level.\nThe user-facing safety levels do not change.\nBlock safety levels (unsafe, safe, finalized) are still defined as they are without interop, and the EL’s view of those labels matches.\nThe supernode’s role is to make sure the labels mean what they say once cross-chain dependencies are part of the picture.\n​op-supernode and Light CL\nop-supernode pairs with the Light CL mode of op-node and kona-node.\nA Light CL turns off local derivation and mirrors safe and finalized state from a trusted external source over the optimism_syncStatus RPC.\nIt still advances the unsafe chain over P2P; only the safe and finalized views are delegated.\nTogether, supernode and Light CL form a topology:\n\nOne trusted op-supernode (or a small high-availability pool of them) runs derivation for every chain in the dependency set, plus the interop activity that promotes blocks to safe.\nThe rest of the operator’s fleet runs op-node or kona-node in Light CL mode, points at the supernode’s optimism_syncStatus, and inherits its safe and finalized view.\nNode operators run the same setup, minus the sequencer Light CLs (only the chain operator produces blocks).\n\nThis split is what makes interop tractable for operators who already run dozens or hundreds of nodes per chain.\nThe expensive multi-chain derivation work happens once, on the supernode; the rest of the fleet stays cheap.\n\n​Where to go next\n\nRead the interop prep notice for the node-operator action checklist for the OP Sepolia and Unichain Sepolia activation.\nRead the supernode configuration guide for recommended settings and a starter configuration, and the op-supernode configuration reference for the full flag catalogue.\nRead the specialized op-node topology notice for the operator-facing pattern of running light op-nodes with --l2.follow.source, the fleet-side of the supernode-plus-light-CL topology.\nRead interop reorg awareness for how the safety model handles equivocation and L1 reorgs.\nRead the cross-chain security measures for how an operator can configure the safety level it requires for inbound messages.\nRead the interop explainer for how cross-chain messaging works at the protocol level.\nFor implementation detail, see the op-supernode source in the monorepo.\nWas this page helpful?","tokens":2016,"squid":"ink-governance","role":"Council Listener","at":1791266704279,"hash":"526fe0215c2d5b22c831b09814940aff59af1884"}
{"url":"https://pyth.network/?ref=pyth-network.ghost.io","domain":"pyth.network","title":"The Price Layer for Global Finance | Pyth Network","text":"Better Market Data for Every MarketBetter Market Data forEvery MarketA breakthrough in financial data that enables institutions, applications, and AI systems to access the widest array of market data at the lowest cost. Free TrialContact the TeamTrusted by institutions. Used by everyone.24/7Benchmark UST pricing, live on PythTRADEWEB · READ THE STORY+40 OTC instruments, priced on Pyth ProFENICS · READ THE STORYUS Treasury pricing, strengthened on Pyth ProOPENYIELD · READ THE STORYDozens of vendorsStale priceNo display rightsLimited asset classesRedistribution feeManual auditsPer-seat costIntegration debtLicence pending+138Data Publishers720+Data Consumers+3,600Live Price Feeds$5T+Transaction VolumeYour Market Data\nInfrastructure Is Unsustainable.One Source Of Truth\nAcross Every Asset Class.Through One API.24/7 coverage, full display\nrights, and zero licensing fees.\nFigures as of September 2026.Pyth Product suitePyth ProLow-latency market data for institutions, trading venues, applications, and AI systems. Access real-time prices across asset classes through modern APIs built for fast, automated workflows.Cross-asset data for crypto, equities, FX, and commodities.Flexible channels for real-time and fixed-rate delivery.Built for trading, risk, analytics, and AI applications.Explore Price FeedsPyth IndicesData MarketplacePyth TerminalContact the TeamSuccess StoriesBuilt with the teams defining the next market cycle.NasdaqNasdaq Basic Available via Pyth’s Data MarketplaceRead StoryHyperliquidHow Hyperliquid Became the World's 24/7 Macro Trading Venue with PythRead StoryTradewebHow Tradeweb Brings Benchmark Government Bond Pricing to the Pyth Data MarketplaceRead StoryCoinbaseHow Coinbase Derivatives Launches 24/7 Thematic Equity Futures with Pyth and MarketVectorRead StoryFenics Market Data How Fenics Market Data Extends Institutional OTC Pricing Through PythRead StoryEuronext FXHow Euronext FX Sets the Global Standard for Programmable Currency DataRead StorySGX FXHow SGX FX Anchors Global Liquidity with Institutional Benchmarks via PythRead StoryKalshiHow Kalshi Modernizes Commodity Resolution with Pyth ProRead StoryPolymarketHow Polymarket Builds Trust in Prediction Markets with Pyth ProRead StoryKrakenHow Kraken Brings 24/7 Oil Perpetuals to Kraken Pro with Pyth IndicesRead StoryShaping the next wave of finance Nic von RuppPyth Athlete Iceland, April 2026See more PythWord on The StreetWhat the market is saying about Pyth.By working with Pyth to provide our reliable market data to applications, Revolut can influence digital economies by ensuring developers and users have access to the precise, real-time information they need.Mazen ElJundiGlobal Business Head of CryptoBy providing our unique market data on-chain in real-time, we look forward to playing a role in the Pyth Network's growth.Ian McGuinnHead of Crypto Business DevelopmentCoinbase has been at the forefront of this evolution, and our growing share of the derivatives market is a direct reflection of that commitment. Tools like Pyth Indices help fill the critical infrastructure gaps that make this next era of markets possible.Boris IlyevskyHead of DerivativesExtending our thematic equity expertise into 24/5 infrastructure is not simply a technical upgrade — it is a rethinking of what 'round-the-clock' price discovery looks like. The partnership with Pyth gives us the data foundation to support reliable, near-continuous pricing, and Coinbase's perpetual futures platform is the ideal first proof of concept for what we believe will be a much broader market.Josh KaplanHead of Research & Investment StrategyAt Tradeweb, we are seeing growing demand for more timely and accessible ETF data. By publishing our iNAVs to the Pyth Network, we are exploring how onchain infrastructure can extend the reach of high-quality, intraday valuations to a broader set of market participants.Michael ZaladonisGlobal Head of Data Products and AnalyticsPublishing Euronext FX's data through Pyth marks an important step toward a unified, transparent, and programmable market data standard for modern finance.Nicholas JegouCEOBy contributing our global OTC pricing to the Pyth Network, we're supporting the creation of a more connected, efficient, and data-driven financial system that brings institutional-grade transparency to the digital asset frontier.Rich WinterGlobal Head of Market DataPyth's price feeds are both granular and easy to consume, complementing Kalshi's mission to make these markets accessible to a broader set of retail and institutional participants.John WangHead of CryptoPyth Indices give us a continuous benchmark for assets where the underlying market doesn't trade round the clock. That matters because Kraken is launching perpetual contracts on oil, and a perpetual needs a 24/7 reference price to function.John PalmerGlobal Head of Derivatives at KrakenMillions of dollars can hinge on a single price point, and that demands absolute confidence in the source of truth. Pyth delivers that assurance, enabling Polymarket to expand into high-stakes financial markets.Mustafa AljaderyProduct LeadWe are committed to upholding the highest standards of transparency and integrity through our SGX FX benchmarks. Contributing this critical pricing data to the Pyth Network is a deliberate step towards accelerating real-time, decentralized finance.Jean-Philippe MaleCEOWe're proud to be long-term supporters of Pyth, which has developed one of the most comprehensive and valuable sources of market data ever created. Pyth Pro makes that data accessible to more consumers, including traditional financial firms, and brings competition to the market data economy by providing the purest form of data directly from the source.By integrating Pyth Pro, we are pairing our global scale with local precision, ensuring our platform delivers region-specific solutions that meet the distinct needs of global markets. This partnership provides the high-fidelity data foundation required to support the depth and liquidity institutions demand.Marc ZeitouniCEO Coinbase International ExchangeWe believe DeFi has the potential to play an important role in defining the future of our financial markets, and we are excited to help support its growth through innovative initiatives like the Pyth Network.Catherine ClayExecutive Vice President, Data and Access SolutionsWe're proud to work with Pyth to put real-time Treasury, corporate, and municipal data in front of a global base of applications and institutions.Jonathan BirnbaumFounder & CEOAn integration with Pyth is the natural step forward for us and it is very much in line with both our strategy and values. Our mission is to advance the decentralized world by empowering more transparent, fair, and efficient markets and products. Evgeny GaevoyCEOFlow Traders is hugely supportive of initiatives such as those being advanced by Pyth which not only will improve the accuracy and quality of market data but also seek to democratize this data among multiple actively contributing market participants.Dennis DijkstraCEOCorporate actions data is foundational to market integrity. By making our datasets available through Pyth Network, we’re helping ensure that onchain financial markets can rely on the same authoritative corporate actions data used across traditional finance.Jonathan BlochCEOTerminalIntroducing Pyth TerminalPyth Terminal is the front door to Pyth's market data. It gives teams a self-serve way to explore price feeds, compare plans, manage API keys, and access real-time market data across asset classes.Free TrialThe Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":2083,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266720673,"hash":"094bdbaaf7154d6cd8c641b4f392e87528ee6d59"}
{"url":"https://docs.optimism.io/op-stack/interop","domain":"docs.optimism.io","title":"Optimism Documentation","text":"OP Stack interop is in active development. Some features may be experimental.\nOP Stack interoperability is a set of protocols that lets OP Stack chains\nread each other’s state, so a network of chains can feel like a single\nblockchain: ETH and ERC-20 tokens move between chains by native minting and\nburning, contracts can compose with events from other chains at low\nlatency, and applications that need it can scale horizontally across\nmultiple chains.\nInterop is in active development and is being rolled out iteratively, so\nread these materials as a picture of where the stack is going and what you\ncan already build against, not as a finished production system. Start with\nthe explainer, then work through the mechanism pages in order: they build\nfrom the message-passing model up to reorg safety and the runtime that\nenforces it. The tutorials let you try everything on local or devnet\nchains, and the spec is the normative definition throughout.\n​Start here\n\nOP Stack interoperability explainer: read\nthis first for what interop enables (native asset transfers, cross-chain\ncomposability, horizontal scalability) and the architecture end to end,\ncovering initiating and executing messages, access-list validation,\nblock safety levels, and dependency sets and clusters.\n\n​Go deeper\n\nInterop message passing overview:\nthe messaging lifecycle at contract level, from the low-level\nCrossL2Inbox to the L2ToL2CrossDomainMessenger most apps use.\nReading logs with OP Stack interop:\nthe pull model, where a contract validates a log from another chain\ndirectly instead of receiving a message.\nMessage expiration:\nwhy an unrelayed message eventually expires and how to reemit one that\ndid.\nSuperchain ETH Bridge: how\nnative ETH moves between chains through SuperchainETHBridge and the\nETHLiquidity contract.\nInterop reorg awareness: how interop delivers\nlow-latency messages without opening the door to cross-chain\ndouble-spends.\nOP Supernode: the runtime that hosts\nevery chain in a dependency set in one process and performs the\ncross-chain verification work.\n\n​Get hands-on\n\nBuild interoperable apps on OP Stack devnet:\npick a development environment (local Supersim or the interop devnet)\nand start deploying.\nSupersim: the local development\nenvironment that simulates a multi-chain OP Stack setup for building\nand testing cross-chain applications.\nInterop message passing tutorial:\nbuild a cross-chain message passing system with the\nL2ToL2CrossDomainMessenger contract.\nRelay transactions manually:\nconstruct and send an executing message yourself when no autorelayer\ndoes it for you.\n\n​The normative spec\nThe definitive definition of interop behavior lives in the OP Stack\nspecifications:\n\nInterop:\nthe root of the interop specs and the map of everything below it.\nMessaging:\nthe normative definitions of initiating and executing messages and\ntheir safety rules.\nPredeploys:\nthe CrossL2Inbox, L2ToL2CrossDomainMessenger, and the other interop\npredeploy contracts.\nSuperchainETHBridge:\nthe specification of native ETH bridging between interop chains.\n\n​Audits and security\n\nCrosschain security measures:\nthe trust model, what happens under sequencer equivocation, and the\nlatency versus security tradeoff each chain configures.\nAudit reports: the standing index of\nOP Stack security reviews, which routes to the full list in the\nmonorepo.\nWas this page helpful?","tokens":841,"squid":"ink-governance","role":"Council Listener","at":1791266727855,"hash":"1290a932b5608410e410ea0f016a582d6dcec233"}
{"url":"https://governance.aave.com/c/risk/general/12","domain":"governance.aave.com","title":"Latest Risk/General topics - Aave","text":"Latest topics in General\n\n Risk\n\n General\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [ARFC] Technical Asset Listing Framework\n\n Summary\nAave Labs proposes adopting a standardized Technical Asset Listing Framework for assets seeking listing, continued listing, or material parameter expansion on Aave V3, Aave V4 and Horizon. \nThe objective is to…\n\n read more\n\n 7\n\n 1.5k\n\n Jul 17\n\n [Discussion] A risk framework for tokenized equities on Aave V3 X Layer, with wTCENTx as the worked example\n\n 1\n\n 85\n\n 5d\n\n [Gho Stewards] September 2026 - GHO Parameter Update\n\n 0\n\n 143\n\n Sep 15\n\n Independent finding: a DeFi Saver admin signer is also one of Aave’s own Governance Guardian signers\n\n 0\n\n 83\n\n Sep 11\n\n Post Vyper Exploit - CRV Market Update and Recommendations\n\n 48\n\n 8.1k\n\n Aug 29\n\n [Risk Stewards] August 2026 - WETH Interest Rate Adjustment\n\n 0\n\n 148\n\n Aug 27\n\n [GHO Stewards] August 2026 - GHO Borrow Rate and Aave Savings Rate Update\n\n 0\n\n 290\n\n Aug 27\n\n Introducing RWALS: An Open Liquidity Scoring Standard for RWA Collateral — and the Ten Commandments That Make It Unchallengeable\n\n 3\n\n 208\n\n Aug 9\n\n Temp check: Increase EURC LTV\n\n 2\n\n 142\n\n Jul 6\n\n [Discussion] Post-rsETH Post-Mortem: Evolving Our Risk Framework & Prioritizing Security Over TVL\n\n 7\n\n 541\n\n May 18\n\n ETH price appreciation makes this bad debt crisis worse every hour, governance must move fast\n\n 16\n\n 3.0k\n\n Apr 20\n\n Stress Testing Ethena: A Quantitative Look at Protocol Stability\n\n 1\n\n 1.3k\n\n Mar 1\n\n Aave’s Growing Exposure to Ethena: Risk Implications Throughout the Growth and Contraction Cycles of USDe\n\n 2\n\n 3.1k\n\n Mar 1\n\n Aave ticket on Discord leads to scam attempt\n\n 3\n\n 269\n\n Apr 2025\n\n Unable to swap, supply,repay,or withdraw , can’t join discord\n\n 2\n\n 214\n\n Mar 2025\n\n Private Lending\n\n 0\n\n 114\n\n Mar 2025\n\n What measures are being taken to restore the peg of GHO?\n\n 2\n\n 242\n\n Jul 2024\n\n Lost USDT in supply\n\n 1\n\n 713\n\n Apr 2024\n\n USDP Oracle Manipulation Event 16th April\n\n 0\n\n 695\n\n Apr 2024\n\n New Risk Steward Signer\n\n 10\n\n 10.1k\n\n Mar 2024\n\n Gauntlet is leaving Aave\n\n 28\n\n 11.6k\n\n Mar 2024\n\n Security Incident on Aave - NEED HELP\n\n 1\n\n 1.4k\n\n Jan 2024\n\n Temporarily Pausing GHO Integration in Aave\n\n 10\n\n 5.3k\n\n Dec 2023\n\n Gauntlet Recommendation: CRV Deprecation Schedule\n\n 11\n\n 1.8k\n\n Aug 2023\n\n Aave V3 Optimism: User Position Analysis\n\n 2\n\n 1.8k\n\n Aug 2023\n\n [ARFC] Optimism Mainnet Upgrade - Risk Considerations\n\n 3\n\n 1.2k\n\n Jun 2023\n\n Aave Resilient Through USDC Volatility\n\n 1\n\n 2.8k\n\n Mar 2023\n\n [ARC] Gauntlet Risk Parameter Updates for AVAX V3 and OP V3 (2023-02-16)\n\n 4\n\n 2.8k\n\n Mar 2023\n\n [ARC] Gauntlet Risk Parameter Updates for Aave V3 Polygon (2023-03-08)\n\n 1\n\n 1.6k\n\n Mar 2023\n\n [ARC] Gauntlet Risk Parameter Updates for Aave V3 Optimism (2023-03-08)\n\n 1\n\n 1.7k\n\n Mar 2023","tokens":708,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266769751,"hash":"e9360e6ed68020559cced01c6662b7595bd5167f"}
{"url":"https://docs.base.org/base-chain/specs/reference/b20/changelog/02-cobalt-b20asset-multiplier","domain":"docs.base.org","title":"B20: ERC-8056 Conformant Multiplier - Base Documentation","text":"Audience: teams already integrated against the B20 Asset multiplier surface on Beryl (live\ntoday). This note covers only the multiplier and ERC-8056 changes landing at the Cobalt hardfork.\n\n​Summary\nAt Cobalt, the B20 Asset multiplier surface becomes ERC-8056 (“Scaled UI Amount”)\nconformant and gains a scheduled multiplier setter for corporate actions. Nothing you call today\nbreaks: every Beryl selector, event topic, and error keeps its exact 4-byte selector or topic0 and\nstays dialable at Cobalt. The deprecations below are advisory, not enforced.\nTo migrate, adopt the ERC-8056 names (uiMultiplier, toUIAmount/fromUIAmount, balanceOfUI,\ntotalSupplyUI), and move routine multiplier changes from the instant updateMultiplier(uint256) to\nthe scheduled updateUIMultiplier(uint256,uint256). multiplier() and scaledBalanceOf(address)\nremain the canonical B20 names; uiMultiplier() and balanceOfUI(address) are their ERC-8056\naliases.\n​Mapping Table\nThe selectors and topic0s below are the real values from the frozen ABIs: abi/v1.rs for Beryl,\nabi/v2.rs for Cobalt. Every Beryl symbol keeps its selector at Cobalt.\n​Functions\nBeryl symbol (selector)Cobalt ERC-8056 symbol (selector)StatusWhymultiplier() 0x1b3ed722uiMultiplier() 0xa60bf13dunchanged (canonical name) / new aliasERC-8056 core naming. Both return the same effective multiplier.toScaledBalance(uint256) 0x04f04c99toUIAmount(uint256) 0x3248d4ffdeprecated-dialable / newERC-8056 Conversion extension. Byte-identical behavior.toRawBalance(uint256) 0x0ca06c44fromUIAmount(uint256) 0x65cd9b3cdeprecated-dialable / newERC-8056 Conversion extension. Byte-identical behavior.scaledBalanceOf(address) 0x1da24f3ebalanceOfUI(address) 0x437a9958unchanged (canonical name) / new aliasERC-8056 Balances extension. Alias, same value.updateMultiplier(uint256) 0x5ffe6146updateUIMultiplier(uint256,uint256) 0x628e600fdeprecated-dialable / new (not 1:1)The canonical path is now the scheduled setter. The instant setter remains as an emergency failsafe.—newUIMultiplier() 0xdc767007newERC-8056 pending-schedule read.—effectiveAt() 0x97a4064fnewERC-8056 pending-schedule read (flip timestamp).—totalSupplyUI() 0x9bea6429newERC-8056 Balances extension.—cancelUIMultiplierUpdate() 0x2c97a0f0newCancels the single live pending update.—MAX_UI_MULTIPLIER() 0x785c0cf0newReads the multiplier ceiling (type(uint128).max) without risking the revert path.—supportsInterface(bytes4) 0x01ffc9a7newERC-165 feature detection.\nOPERATOR_ROLE() 0xf5b541a6, WAD_PRECISION() 0x664808a8, announce(...) 0x595135dd,\nisAnnouncementIdUsed(string) 0xc0da474e, batchMint(...) 0x68573107,\nextraMetadata(string) 0x4ddf9da0, and updateExtraMetadata(string,string) 0xb2851ef5 carry\nover unchanged.\n​Events\nBeryl event (topic0)Cobalt canonical (topic0)StatusWhyMultiplierUpdated(uint256)UIMultiplierUpdated(uint256,uint256,uint256)deprecated-still-emitted / newERC-8056 canonical event. The instant setter emits both events. The scheduled setter emits only UIMultiplierUpdated.—UIMultiplierUpdateCancelled(uint256,uint256)newSignals a cleared pending update.\n​Errors\nBeryl error (selector)Cobalt (selector)StatusWhyInvalidMultiplier() 0x6f12f3dcInvalidMultiplier() 0x6f12f3dcpresent on Beryl alreadyZero or above-ceiling guard. Now also thrown by updateUIMultiplier.—EffectiveAtInPast(uint256) 0x14119cf6newThrown when effectiveAt <= block.timestamp.—EffectiveAtTooFar(uint256) 0x1ce214fanewThrown when effectiveAt > type(uint64).max.—UIMultiplierUpdateExists(uint256) 0x4481a68enewThrown when a live pending update already exists.—UIMultiplierUpdateDoesNotExist() 0xa7d6a5canewThrown when you cancel with no live pending update.\n​New at Cobalt: Adopt These\n​Scheduled-Update Lifecycle\nupdateUIMultiplier(newMultiplier, effectiveAt) is the canonical path for corporate actions, such\nas stock splits and reinvested dividends. Only one pending update can be live at a time.\n\nSchedule: call updateUIMultiplier(newMultiplier, effectiveAt). This requires\nOPERATOR_ROLE, and effectiveAt must be strictly in the future.\nRead the pending update: while it’s live, newUIMultiplier() returns the scheduled target,\neffectiveAt() returns the flip timestamp, and uiMultiplier() / multiplier() still return\nthe current value.\nLet it mature: once block.timestamp >= effectiveAt, uiMultiplier() / multiplier() flip\non read. No event fires at maturation.\nOr cancel it: cancelUIMultiplierUpdate() clears a live pending update and emits\nUIMultiplierUpdateCancelled(cancelledMultiplier, cancelledEffectiveAt).\n\nTo reorder overlapping actions, cancel and reschedule atomically in one announcement:\nannounce([cancelUIMultiplierUpdate(), updateUIMultiplier(...)], ...).\n​ERC-8056 View Aliases\n\nuiMultiplier() returns the same value as multiplier().\ntoUIAmount(raw) returns the same value as toScaledBalance(raw). fromUIAmount(ui) returns the\nsame value as toRawBalance(ui).\nbalanceOfUI(account) returns the same value as scaledBalanceOf(account).\ntotalSupplyUI() equals totalSupply() * uiMultiplier() / WAD_PRECISION.\n\n​Bound Getter\nMAX_UI_MULTIPLIER() returns type(uint128).max, the ceiling both setters enforce. This is the\noverflow guard that keeps balance * multiplier inside uint256.\n​updateMultiplier(uint256) Remains as an Instant Admin Failsafe\nupdateMultiplier(uint256) sets the multiplier immediately and clears any live pending update. It’s\na deprecated admin failsafe, kept for tech debt and emergency overrides, not routine use: use it to\ninstantly reverse a scheduling mistake, and pair it with pausing in most cases.\n​Guarantees and Edge Cases\nQ: A scheduled update can be canceled. How do external consumers detect the cancellation?\ncancelUIMultiplierUpdate() emits UIMultiplierUpdateCancelled(cancelledMultiplier, cancelledEffectiveAt) (topic0 0x8838…1cad); so does the instant setter, when it supersedes a live\npending update. Watch that topic to retract a pending flip you previously staged from\nUIMultiplierUpdated.\nQ: If the admin uses the instant failsafe, how do off-chain indexers keep a linear, gap-free\nUI-multiplier lifecycle?\nThe instant updateMultiplier(uint256) emits both the deprecated MultiplierUpdated(uint256) and\nthe ERC-8056 UIMultiplierUpdated(old, new, block.timestamp) (and, if it clears a live pending\nupdate, UIMultiplierUpdateCancelled first). Every multiplier change, scheduled or emergency,\nappears on the single UIMultiplierUpdated stream, so following that one event never misses a\nchange. The legacy MultiplierUpdated topic stays available for indexers that haven’t migrated.\nQ: How do I tell a live pending update apart from one that already matured, or none at all?\nA pending update is live if effectiveAt() > block.timestamp. While it’s live, newUIMultiplier()\nreturns the scheduled target, which differs from uiMultiplier(). After maturation,\nuiMultiplier() already reflects the new value, newUIMultiplier() == uiMultiplier(), and\neffectiveAt() stays at the now-past flip timestamp until the next schedule, instant update, or\ncancel overwrites it. So a nonzero effectiveAt() that’s <= block.timestamp means “already\napplied,” not “pending.” If no update has ever been scheduled, effectiveAt() == 0.\nQ: What happens if I schedule an update while one is already pending?\nIt reverts UIMultiplierUpdateExists(effectiveAt), but only a live pending update blocks the call.\nA matured (stale) pending update is silently folded into the current multiplier and overwritten. To\nreplace a live schedule, call cancelUIMultiplierUpdate() then updateUIMultiplier(...), atomically,\nvia announce.\nQ: What are the bounds on effectiveAt?\nIt must be strictly in the future: effectiveAt <= block.timestamp reverts\nEffectiveAtInPast(effectiveAt). It must also fit the on-chain field:\neffectiveAt > type(uint64).max reverts EffectiveAtTooFar(effectiveAt).\nQ: What are the bounds on the multiplier?\n0 < newMultiplier <= MAX_UI_MULTIPLIER() (type(uint128).max). Zero or above reverts\nInvalidMultiplier(). This applies to both updateUIMultiplier and updateMultiplier. You can\nread the ceiling from MAX_UI_MULTIPLIER() without risking the revert.\nQ: Do raw balances or Transfer semantics change?\nNo. The multiplier is purely cosmetic: it rescales only the UI/scaled view. balanceOf,\ntransfer, totalSupply, and Transfer stay raw, and no multiplier change, scheduled or instant,\naffects them. Only the *UI / scaled reads move.Was this page helpful?Suggest editsRaise issue","tokens":2097,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266774379,"hash":"9ecc174faf1bd3c16fea0beecae0277bef690a54"}
{"url":"https://governance.aave.com/t/gho-stewards-august-2026-gho-borrow-rate-and-aave-savings-rate-update/25534/1","domain":"governance.aave.com","title":"[GHO Stewards] August 2026 - GHO Borrow Rate and Aave Savings Rate Update - Risk / General - Aave","text":"[GHO Stewards] August 2026 - GHO Borrow Rate and Aave Savings Rate Update \n\n RiskGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 27\n\n 1 / 1\n\n Aug 27\n\n Aug 27\n\n post by TokenLogic on Aug 27\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [GHO Stewards] August 2026 - GHO Borrow Rate and Aave Savings Rate Update\nauthor: @TokenLogic\ncreated: 2026-08-27\n\nOverview\nThis update adjusts rates on both sides of GHO’s balance sheet. The GHO borrow rate on Ethereum Core rises from 3.75% to 4.25% in two 25 bps steps, the Ethereum Prime base rate rises by 75 bps to 2.75% in two steps, and the Monad configuration is aligned in two steps so that no cross-chain instance prices GHO materially below the Core anchor. On the demand side, the Aave Savings Rate (ASR) paid by sGHO rises from 4.25% to 4.50%. The package accompanies the August 2026 Stablecoin Interest Rate Adjustments update, which kept GHO under separate rate management. It addresses the recovered peg, GSM backing outflows, sGHO retention as rival savings rates move higher, and protocol revenue from GHO debt. All changes sit within the existing Risk Steward and GHO Risk Council mandates and will be implemented directly.\nMarket context\nDemand conditions have improved materially. Across Aave’s stablecoin reserves, utilization has held at or near the kink through August, which supports the 50 bps Slope1 increases in the companion update. The regulatory backdrop also strengthened: the US Treasury opened the GENIUS Act stablecoin rulemaking to public comment on August 17, the SEC proposed exemptive crypto rules on August 18, and FASB proposed standards under which stablecoins would qualify as cash equivalents, which could support corporate adoption. On August 19 the Treasury doubled its long-end liquidity-support buybacks. The operation is not quantitative easing, but the market received it as support for bond-market liquidity. Short-term dollar yields remain elevated. GHO borrowers can therefore absorb a higher rate, while savings products still need to retain deposits.\nAgainst this improving backdrop, GHO spent July and August losing ground on three connected fronts:\n\nPeg. GHO traded below par consistently over the last weeks, driven primarily by the USDT underperformance, but exacerbated the price crossed the limits of the Fluid GHO-USDC pool. The gap has since closed: GHO trades at $0.9997 today, and the peg is no longer under pressure.\nGSM backing. The USDT GSM on Ethereum has lost 12.4M of underlying exposure since August 13, from 53.2M to 40.8M USDT, roughly a quarter of the module’s backing. The USDC GSM remains effectively empty. Redemptions through the GSM follow from a persistent sub-par secondary price.\nSavings retention. stkGHO has shed 7.0M over the past 28 days, and while sGHO deposits still grew on a net basis to 158.6M, the past two weeks show multi-million single-day redemption spikes. With roughly three quarters of circulating GHO held in savings products, retention supports the peg.\n\nThe GSM’s fee schedule links the peg to the module. Minting GHO through the GSM is free, while redeeming GHO for the underlying costs 10 bps. Redemption arbitrage pays whenever the secondary discount exceeds that fee: an arbitrageur buys GHO below par, redeems it at par, and keeps the difference. The discount exceeded 10 bps on 29 of the 30 days to August 25, and the resulting spread drove the module outflow. As the discount narrows to within 10 bps of par, redemption no longer pays and the drain stops.\nThe three pressures have the same cause, which remains in place: GHO is the cheapest stablecoin to source on Aave, and debt minted below the market-clearing rate is sold into the market. Ethereum Core prices GHO at 3.82%, while USDC and USDT have held at or above their optimal utilization through August and price above their 4.00% Slope1 targets. As the companion update lifts those targets toward 4.50%, an unchanged GHO would be mintable up to 75 bps below the next cheapest stable. That gap would extend the flows that have pressured the peg and reduced GSM backing.\nimage1920×1080 227 KB\nThe most recent data indicates that the pressure is easing. The market-wide rally has reduced the discount from its 26 bps peak to roughly 3 bps, within the range where redemption arbitrage no longer pays, and the module’s backing recorded its first flat day on August 25 after a week of daily outflows. Liquidity in the main Fluid pool, which had been almost entirely one-sided in GHO since mid June, has begun to rebalance as USDC returns. USDT borrow demand on Ethereum Core has continued to grow, keeping the reserve at its optimal utilization and increasing the yield earned by GSM backing. The proposed changes enter a recovering market and seek to preserve that recovery.\nimage1920×1080 170 KB\nCirculating GHO comes from two source families: debt drawn from facilitator-supplied markets on Ethereum, Core, Prime and Horizon, and stablecoins swapped into the GSMs. Debt currently accounts for roughly 69% of issuance against 31% for the GSMs. The balance has moved toward debt over the last month as borrowing grew while the modules drained. GHO can be minted through lending markets below the cost of comparable stablecoins, so issuance has increasingly come through borrowing. GSM backing earns the DAO the underlying Aave yield, and its share has declined alongside the backing. The debt side already carries about two thirds of GHO revenue. Higher debt rates improve the revenue earned on remaining borrowing, while a peg recovery and restored GSM backing would increase the module’s share of issuance and revenue.\nBorrow rate changes\nEthereum Core, 3.75% to 4.25%, in two 25 bps steps. The rate moves to 4.00% first and to 4.25% approximately two weeks later, alongside the staged Slope1 increases in the companion update. GHO remains priced below USDC and USDT at each point in the sequence, preserving the protocol’s preference for its own stablecoin. Higher borrowing costs also support the peg because borrowers repaying GHO buy it in the market below par. Repayments reduce circulating supply, so the rate increase is paired with an ASR increase to retain and attract savings holders.\nEthereum Prime, base rate from 2.00% to 2.75%, in two steps. Prime is the leverage venue, and the current curve prices GHO at 3.16% at prevailing utilization, well below Core. Raising the base rate moves the curve at every utilization level. A first step to 2.50% and a second to 2.75% move the current rate to approximately 3.91% and the kink rate from 3.25% to 4.00%. A base-rate change takes effect immediately at all utilization levels. Prime retains a modest discount to Core, keeping looping activity on Prime while avoiding a venue where GHO can be sourced far below its mint rate.\nInstance alignment. No cross-chain deployment should offer GHO at a target rate materially below the Core anchor. Monad Core’s Slope1 of 4.00% sits below the new anchor and rises to 4.50% in two steps, 4.25% first, matching the harmonized stablecoin Slope1 and folding into the Monad IRM implementation already in flight. All other cross-chain deployments already price GHO at a kink rate of 4.50% or above and are left unchanged. Horizon operates under the separate RWA instance arrangement and is out of scope for this update.\nASR increase\nThe competitive set is moving up. Under the same reserve-factor convention the companion update applies to USDe, the Sky Savings Rate grosses to a USDS borrow floor near 4.75%, and the Ethena staking rate is expected to settle around 5.3% as looped USDe supply unwinds. At 4.25%, sGHO would be the lowest-paying major on-chain savings product at exactly the moment retention matters most. Moving the ASR to 4.50% keeps sGHO within 25 bps of sUSDS while remaining below the new Core borrow rate. The core viability spread, savings cost below CDP interest plus backing yield plus GSM fees, is preserved and widens relative to today.\nAt current sGHO deposits of 158.6M GHO, the additional savings cost is approximately $397K per year.\nRevenue impact\nGHO borrow interest on Ethereum Core accrues entirely to the treasury under a 100% reserve factor. Prime and Horizon have a 10% reserve factor, but the DAO supplies most of both markets through their facilitators and earns supply-side interest on those deposits. Effective capture is approximately 92% on Prime and nearly 100% on Horizon. The following are static estimates at current balances and utilization:\nScreenshot 2026-08-27 at 13.33.09723×329 34 KB\nAcross every avenue, DAO revenue from GHO rises from approximately $2.2M to $3.0M per year. This proposal accounts for $474K of the increase, while the companion update reaching the GSM backing accounts for $345K across the USDT and USDT0 legs. The package generates $871K of additional market revenue against $397K of additional savings cost.\nGSM yield revenue reflects two opposing movements. The module holds its backing as wrapped Aave aTokens, so the rate earned rises with the companion’s Slope1 increases. Its backing has contracted through August as redemptions drained the module. At the current 40.8M of USDT backing the companion move adds approximately $169K per year; if outflows continued at the August pace, the uplift would compress toward $12K. The Plasma USDT0 leg holds a further 40.6M of backing that has stayed flat through the month, and the companion increase on that reserve adds approximately $176K per year. The USDC leg is currently empty and contributes nothing until backing returns. August 25 was the first flat day after a week of outflows, which indicates that the narrowing discount is slowing the drain. Redemption fees earned during the drain, approximately $0.8M annualized over the past week, follow from the sub-par price and are excluded from the figures above.\nThese estimates exclude second-order effects. Each basis point of peg recovery reduces arbitrage flows from the GSM, and retained sGHO deposits support circulating supply.\nSpecification\nThe following parameter updates will be implemented:\nScreenshot 2026-08-27 at 13.33.27721×191 17.3 KB\nEach borrow-rate change above is the first of two steps: Core moves to 4.00% and then 4.25%, Prime to 2.50% and then 2.75%, and Monad Slope1 to 4.25% and then 4.50%, with the second step following approximately two weeks after the first, in line with the staged execution of the companion update. Prime keeps its current Slope1 (1.25%), Slope2 (35.00%) and optimal utilization (92%). The Monad change composes with the optimal utilization (92%) and Slope2 (20.00%) update already specified in the LlamaRisk Monad IRM proposal.\nFor reference, the remaining GHO deployments already price at or above the new anchor at their kink and are unchanged: Base, Avalanche, Arbitrum and Gnosis (Slope1 4.50%), Plasma (base 1.25% plus Slope1 3.50%), X Layer (5.00%), Mantle (base 2.00% plus Slope1 3.00%), Ink (5.50%).\nDisclaimer\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nImplement the Core, Prime and Monad rate updates through the Risk Stewards within their existing caps and cooldowns, each performed in two steps spaced approximately one week apart.\nImplement the ASR update through the GHO Risk Council via the sGHO Steward, and size the weekly sGHO backing top-up cadence to the new rate.\nMonitor the peg, GSM flows, sGHO deposits and Core debt weekly following execution, and report to the community before any further adjustment.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n read \n\n 5\n min\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [GHO Stewards] October 2026 - GHO Borrow Rate Update\n\n Governance\n\n 0\n\n 164\n\n 4d\n\n [Gho Stewards] September 2026 - GHO Parameter Update\n\n General\n\n 0\n\n 143\n\n Sep 15\n\n [ARFC] sGHO Launch Configuration\n\n Governance\n\n 4\n\n 1.2k\n\n Apr 2\n\n [ARFC] Update USDS & GHO Borrow Rate\n\n Governance\n\n 6\n\n 503\n\n Feb 2025\n\n [ARFC] Aave Institutional\n\n Governance\n\n 7\n\n 535\n\n 4d","tokens":3101,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266784099,"hash":"58c15f0306722265b8ef651f1dd4f152bb721edd"}
{"url":"https://docs.base.org/base-chain/specs/reference/b20/changelog/03-denim-b20-token-receiver","domain":"docs.base.org","title":"B20: Reject the Token Itself as a Credit Recipient - Base Documentation","text":"​Abstract\nDenim adds address(this) as a second trigger of the existing\nInvalidReceiver(address receiver) error. transfer, transferFrom, their memo variants, mint,\nmintWithMemo, batchMint, and seizeWithMemo revert InvalidReceiver(to) when to is the\ntoken’s own address. The guard covers the IB20 transfer, mint, and seize paths plus\nIB20Asset.batchMint, so it applies to both B20 Asset and B20 Stablecoin.\nA holder sending to themselves (from == to) still succeeds. An issuer can still recover tokens\nalready credited to the token address: seizeWithMemo with from == address(token) succeeds.\nThis change is breaking for any integration that sends to the token address today. It adds no new\nfunctions, events, errors, or selectors.\n​Motivation\nUsers often paste the token address instead of the recipient’s address. A B20 token is a precompile\nwith no holder key, so it cannot call transfer on itself. After a credit lands at the token\naddress, the sender cannot recover it; only the issuer can, through seizeWithMemo.\nThere is no valid use case for a B20 token to hold its own tokens. Denim reverts on that destination\nso the mistaken send fails instead of locking the funds.\n​What Changed\n​Receiver Guard\nInvalidReceiver already fires for address(0) (ERC-6093). Denim extends the same guard, at the\nsame position in the revert order:\nBefore (Cobalt)if (to == address(0)) revert InvalidReceiver(to);\n\nAfter (Denim)if (to == address(0) || to == address(this)) revert InvalidReceiver(to);\n\nSymbolSelectorStatusBehaviorInvalidReceiver(address)0x9cfea583ExtendedNow also fires when to == address(this).\n​Revert Order\nThe check runs at the existing invalid-receiver step. Canonical order is otherwise unchanged:\nFunctionCheck ordertransfer / transferWithMemopause → invalid-receiver → zero-sender → executor policy → sender policy → receiver policy → balancetransferFrom / transferFromWithMemopause → invalid-receiver → zero-sender → allowance → executor policy → sender policy → receiver policy → balancemint / mintWithMemopause → role → invalid-receiver → mint-receiver policy → supply capbatchMintpause → role → length / empty → per-element invalid-receiver → _mint bodyseizeWithMemopause → role → invalid-receiver → zero-sender → self-seize (from == to) → seizable → seize-receiver policy → balance\nThe guard checks to only. from may equal address(this), so a seize that drains the token\naddress into a treasury still succeeds.\n​Examples\nA holder transfer to the token reverts:\nTransfer to Token Addressvm.prank(alice);\ntoken.transfer({to: address(token), amount: amount}); // reverts InvalidReceiver(address(token))\n\nMint and seize to the token address revert the same way:\nMint or Seize to Token Addresstoken.mint({to: address(token), amount: amount}); // reverts InvalidReceiver(address(token))\n\ntoken.seizeWithMemo({\n from: alice, to: address(token), amount: amount, memo: memo\n}); // reverts InvalidReceiver(address(token))\n\nA self-send and a recovery seize both still succeed:\nUnaffected Pathsvm.prank(alice);\ntoken.transfer({to: alice, amount: amount}); // succeeds; balance and totalSupply unchanged\n\ntoken.seizeWithMemo({\n from: address(token), to: treasury, amount: amount, memo: memo\n}); // succeeds\n\n​Design Decisions and Alternatives Considered\nDenim reuses InvalidReceiver and compares to against address(this) on every credit path. The\ndestination is invalid for the same reason address(0) is: no holder can spend the credited units.\nWallets that already treat InvalidReceiver as “do not send here” keep the same revert handling.\n​Reject Any B20-Prefix Address\nA prefix check cannot tell a B20 token from a user-controlled account in the same address space,\nsuch as a multisig. Rejecting the whole prefix would revert valid transfers, so Denim checks\naddress(this) only. Sends to other B20 tokens still succeed.\n​Call isB20Initialized(to)\nThis would reject only live tokens, but it adds a factory call on every credit path.\n​New SelfSend(address) Error\nA dedicated error would read more clearly in traces, but it adds ABI surface for a condition\nInvalidReceiver already describes.\n​Also Reject from == address(this)\nBlocking spends from the token address would close the only recovery path for balances already\nsitting there.\n​Migration\n\nTreat the token’s own address as an invalid recipient in wallets, custodians, and indexers, the\nsame way you treat address(0).\nAfter Denim activates, expect InvalidReceiver from any transfer, mint, or seize to\naddress(token) that succeeded before.\nRecover a balance credited to the token address before activation with\nseizeWithMemo(address(token), treasury, amount, memo). The caller must hold SEIZE_ROLE, and\nthe token must be seizable under SEIZE_EXEMPT_POLICY.\nNo change is needed for self-transfers, approvals, burns, or sends to other B20 tokens.\n\nThe seizeWithMemo and\ntransfer reference pages describe\nbehavior before Denim activates.Was this page helpful?Suggest editsRaise issue","tokens":1235,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266784398,"hash":"51ce98f1c25cae71c3229a6fa3b377b041954a81"}
{"url":"https://docs.base.org/upgrades/denim/migrate-from-flashblocks","domain":"docs.base.org","title":"Migrate From Flashblocks - Base Documentation","text":"200ms native blocks are live on Vibenet for experimental developer testing. This deployment may change, and you should not rely on it for production decisions.Denim is not active on Base Sepolia or Base Mainnet; activation times and required client versions remain undecided.\n​Summary\nUse this guide if your application consumes Flashblocks. Denim replaces Flashblocks with canonical 200ms blocks, so Flashblocks subscriptions and pending state are unavailable after activation.\n​Recommended Action\nInventory every Flashblocks subscription and RPC request that uses the \"pending\" block tag before Denim. Replace each integration using the table below.\n​Update Integrations for Denim\nIntegration to reviewAction for Denimeth_subscribe(\"newFlashblocks\")Use eth_subscribe(\"newHeads\").eth_subscribe(\"pendingLogs\")Use eth_subscribe(\"logs\").eth_subscribe(\"newFlashblockTransactions\")Use eth_subscribe(\"newHeads\"), then fetch transactions for each canonical block.eth_getBlockByNumber(\"pending\", ...)Use normal RPC calls to read the latest canonical blocks.eth_getBalance(..., \"pending\")Use normal RPC calls to read the latest canonical state.eth_getTransactionCount(..., \"pending\", ...)Use normal RPC calls to read the latest canonical state.eth_call(..., \"pending\")Use normal RPC calls to read the latest canonical state.eth_estimateGas(..., \"pending\")Use normal RPC calls to read the latest canonical state.eth_simulateV1(..., \"pending\")Use normal RPC calls to read the latest canonical state.eth_getLogs with a range ending at \"pending\"Use normal RPC calls to query logs from canonical blocks.eth_getBlockTransactionCountByNumber(\"pending\")Use normal RPC calls to read the latest canonical block.Bridge or proof flow that reads historical block hashes or beacon rootsReview its history assumptions. The retained number of values is unchanged, but 200ms blocks mean that history covers less elapsed time.\nThe \"pending\" block tag and Flashblocks preconfirmation state have no direct equivalent after Denim. The replacements above return canonical data from 200ms blocks, not preconfirmed or pending data.\n​Test on Vibenet\nTest your migrated integration on Vibenet. For the protocol design and RPC behavior, see 200ms Native Blocks.Was this page helpful?Suggest editsRaise issue","tokens":568,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266802209,"hash":"8c0f9f0233a08eb5ed9536b6016c0695504d58a1"}
{"url":"https://docs.base.org/upgrades/cobalt/overview","domain":"docs.base.org","title":"Overview - Base Documentation","text":"StatusDateSepoliaLiveSeptember 23, 2026MainnetLiveSeptember 30, 2026\n​Features\nB20 ImprovementsBase · PrecompileCobalt brings improvements to the B20 token standard: schedule multiplier updates, transfer blocked simplification, and new Union and Intersect policies.Validity TransactionsBase · TransactionsCobalt introduces validity transactions: signed transactions that Base includes only when onchain conditions (storage, block-number, and Flashblock-index predicates) match. Use them for conditional swaps, withdrawals, and other state-dependent actions. See Validity Transactions for the full specification.Dynamic UpgradesBase · RPCDynamic Upgrades introduces an Ethereum smart contract that stores upgrade timestamps for Base nodes, allowing nodes to query the contract and apply changes live. It runs in metrics-only mode on Mainnet while data is collected to validate that upgrades work smoothly.TEE Registration MigrationBase · InfrastructureCobalt changes how new Trusted Execution Environment (TEE) signers are registered: AWS Nitro attestations are trustlessly verified fully onchain using checked P-384 hints, replacing the RISC Zero and Boundless proving flow. Registration is faster and no longer depends on an external offchain proving service. Enclave key generation, PCR0 image selection, and proof verification are unchanged. See Hinted Registration Migration for what changed and Registrar for the full specification.Was this page helpful?Suggest editsRaise issue","tokens":371,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266812075,"hash":"245dffc770ab493e1a4e357f04a7bd35b557200b"}
{"url":"https://governance.aave.com/t/gho-stewards-september-2026-gho-parameter-update/25644/1","domain":"governance.aave.com","title":"[Gho Stewards] September 2026 - GHO Parameter Update - Risk / General - Aave","text":"[Gho Stewards] September 2026 - GHO Parameter Update \n\n RiskGeneral\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 15\n\n 1 / 1\n\n Sep 16\n\n Sep 15\n\n post by TokenLogic on Sep 15\n\n TokenLogic\n\n TokenLogic-Finance SP\n\ntitle: [Gho Stewards] September 2026 - GHO Parameter Update\nauthor: @TokenLogic\ncreated: 2026-09-14\n\nOverview\nThis publication raises the GHO Borrow Rate on Horizon, adjusts the GHO Stability Module burn fees, raising the stataUSDC instances to 15 bps and lowering the Ethereum stataUSDT instance to 10 bps, and supports greater potential GHO minting volume on the Monad Network.\nMotivation\nGHO’s peg\nOver the last 30 days leading up to 14 September, the GHO/USD price has ranged between 6.7 bps and 13.6 bps under par, with its latest standing at 12 bps under $1.00. While USDT’s price has recovered over the last month to par with USDC and within 2-3 bps of the peg, the GHO peg has not followed. Currently, GHO trades roughly 10.5 bps below USDC and 9.2 bps below USDT. The discount narrowed through the last week of August but recently reopened and continues to trade at a discount.\nimage2048×1152 148 KB\nThe discount has been reflected in GSM outflows over the same period. The Ethereum USDT GSM has drained from 40.8M to 18.6M over three weeks as GHO traded below the module’s redemption threshold on secondary venues; the module’s redemption fee now stands at 15 bps following the latest change.\nThe Ethereum USDC GSM has not attracted any inbound flows, and the current 10 bps burn fee would allow market arbitrage if it were to be filled. Each GHO redeemed through a module retires a unit of backing, forgoing the underlying Aave supply yield, so the discount impacts the Aave DAO revenue, as well as GHO’s peg.\nHorizon borrow rate\nFollowing our latest GHO Stewards changes, the three Ethereum venues price GHO debt at 4.25% on Core, at 3.84% on Prime, and at 3.00% on Horizon. Horizon sits 125 bps below Core and about 85 bps below Prime. At 3.00%, looping Horizon’s RWA collateral against GHO debt is profitable and drives strong demand, and the borrowed GHO is sold for other stablecoins to buy more collateral. Every loop opened at that rate is GHO minted at 3.00% and sold into the market.\nimage2048×1152 159 KB\nHorizon GHO debt rose from 23.2M to 39.0M, an increase of 68% over the 30 days, and the GHO discount widened over the same period. The two series move together, as Horizon borrows funds and sells them on the market to execute looping strategies. The correlation is direct and visible in the paired chart, and it resulted in selling pressure on the peg.\nimage2048×1152 139 KB\nWe propose raising the Horizon GHO base rate from 3.00% to 3.25%. Horizon’s curve is flat, so the 25 bps applies to every unit of Horizon GHO debt at every utilization level from the moment the change takes effect. Horizon remains the lowest-priced venue after the change, below Prime at 3.84% and Core at 4.25%, so the RWA arrangement remains profitable while the margin available to a borrower who mints to sell narrows.\nMonad USDC GSM capacity\nFor a large holder looking to acquire GHO, we recommend coordinating the purchase through the Monad USDC GSM. The Monad USDC GSM is currently empty, with a GhoReserve limit of 25M, a USDC exposure cap of 40M, and a 10 bps redemption fee. We recommend raising the GhoReserve limit from 25M to 49M and the USDC exposure cap from 40M to 50M, so the full purchase can be issued on Monad. The USDC the buyer provides is held in the GSM module as wrapped Aave aTokens, earning the Monad USDC supply yield for the DAO, which is currently elevated by the Monad incentives program.\nGSM redemption fees\nGiven the expected influx of USDC into the Monad GSM and the current GSM redemption fee creating arbitrage opportunities, we recommend adjusting the USDC GSM redemption fee across all instances.\nAs such, we raise the redemption fee from 10 to 15 bps on the Ethereum, Monad, and Arbitrum USDC GSMs. The mint fee stays at zero in every instance, so the coordinated purchase is unaffected, and the change reaches only the exit.\nAlongside the USDC change, we lower the Ethereum USDT GSM redemption fee from 15 bps to 10 bps. The module holds 18.6M of USDT backing, and at 10 bps redemption arbitrage engages whenever GHO trades more than 10 bps below USDT, pulling the price back toward par. The change is there to support the peg if needed. We do not expect meaningful redemption size to happen at once: GHO trades about 9 bps below USDT at the latest oracle post, inside the threshold, so the lower fee acts only if the discount widens again.\nAt 15 bps, the discount has to exceed the peg discount before redemption pays, and the GHO discount has not exceeded 15 bps at any point in the last 30 days, with the widest discount reaching 12.5 bps on the Chainlink GHO/USD feed.\nSpecification\nThe following parameter updates will be implemented:\n\nMarket\nReserve / Product\nParameter\nCurrent\nNew\n\nEthereum Horizon\nGHO\nBase Rate\n3.00%\n3.25%\n\nMonad\nUSDC GSM\nGhoReserve limit\n25,000,000\n49,000,000\n\nMonad\nUSDC GSM\nUSDC exposure cap\n40,000,000\n50,000,000\n\nEthereum\nUSDC GSM\nbuy fee\n10 bps\n15 bps\n\nMonad\nUSDC GSM\nbuy fee\n10 bps\n15 bps\n\nArbitrum\nUSDC GSM\nbuy fee\n10 bps\n15 bps\n\nEthereum\nUSDT GSM\nbuy fee\n15 bps\n10 bps\n\nDisclaimer\nTokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal.\nTokenLogic supports and maintains an independent delegate voting platform within the Aave community.\nTokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.\nNext Steps\n\nImplement the Horizon GHO base rate update through the Risk Stewards within their existing caps and cooldowns.\nImplement the Monad USDC GSM capacity and the GSM redemption fee updates through the GHO Risk Council.\nMonitor the peg, GSM flows, and Horizon debt weekly following execution, and report to the community before any further adjustment.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n Risk Stewards: Cap and IRM Changes on Aave V3 / 2026.09.16\n\n AL Development Update | September 2026\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [GHO Stewards] August 2026 - GHO Borrow Rate and Aave Savings Rate Update\n\n General\n\n 0\n\n 291\n\n Aug 27\n\n [ARFC] Aave Institutional\n\n Governance\n\n 7\n\n 535\n\n 4d\n\n [ARFC] Launch remoteGSM on Arbitrum\n\n Governance\n\n 3\n\n 292\n\n Aug 17\n\n [Direct-to-AIP] July 2026 - Funding Update\n\n Governance\n\n 0\n\n 277\n\n Jul 6\n\n [ARFC] TokenLogic GHO Stewards - GHO Borrow Rate Update\n\n Governance\n\n 2\n\n 266\n\n Dec 2024","tokens":1683,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266812482,"hash":"afd8cffe33ce8bfc57368afa0ab0ffcb9cb0f2d3"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/50","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 50 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by shamatar on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by vbuterin on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n Load more posts below","tokens":1563,"squid":"ink-research","role":"Deep Scholar","at":1791266818796,"hash":"b18abc66ae9afc13407bfa8748c09a2d32173ee8"}
{"url":"https://docs.base.org/base-chain/specs/reference/b20/changelog/03-denim-b20-transfer-executor-enforcement","domain":"docs.base.org","title":"B20: Transfer Executor Policy Enforcement - Base Documentation","text":"​Abstract\nDenim applies TRANSFER_EXECUTOR_POLICY to every transfer path. The\nexecutor gate now checks msg.sender on transfer, transferFrom, transferWithMemo, and\ntransferFromWithMemo, including when msg.sender == from. Before Denim, the check ran only on\nthe transferFrom paths, and only when msg.sender != from.\nThis change is breaking for a token that already set a restrictive TRANSFER_EXECUTOR_POLICY:\nholders who moved their own tokens with transfer or self-transferFrom must now be authorized as\ninitiators. A token that never set the policy keeps the unset always-allow default and is\nunaffected. The change adds no new selectors, events, errors, or storage.\n​Motivation\nAn issuer of a restricted security token may require every transfer to go through a registered\ntransfer agent. Holders approve the agent, and only the agent calls transferFrom.\nTRANSFER_EXECUTOR_POLICY is the initiator allowlist for that pattern, but before Denim it had two\ngaps:\n\ntransfer never consulted the executor policy. A holder could always move their own tokens\nthrough transfer, regardless of the allowlist.\ntransferFrom skipped the check when msg.sender == from. A holder could call\ntransferFrom(self, to, amount) to reach the same unchecked path.\n\nBoth gaps let a non-allowlisted holder move tokens by picking a different entrypoint. Denim brings\nTRANSFER_EXECUTOR_POLICY to parity with TRANSFER_SENDER_POLICY and TRANSFER_RECEIVER_POLICY,\nwhich already run on every transfer path.\n​What Changed\n​Transfer-Side Scopes\nAll three transfer-side scopes now run inside the shared _transfer helper that backs transfer,\ntransferFrom, and their memo variants:\nScopeAccount checkedBefore DenimDenimTRANSFER_SENDER_POLICYfromEvery transfer pathEvery transfer pathTRANSFER_RECEIVER_POLICYtoEvery transfer pathEvery transfer pathTRANSFER_EXECUTOR_POLICYmsg.sendertransferFrom paths, only when msg.sender != fromEvery transfer path\nAll three scopes are still bypassed during the factory bootstrap window (_isPrivileged()), so a\ntoken’s initCalls can move newly minted supply without pre-authorizing the factory.\n​Revert Order\nPause, zero-actor, and allowance checks stay in the entrypoints. The executor check moves into\n_transfer, where it runs first, before the sender and receiver checks:\nFunctionBefore DenimDenimtransfer / transferWithMemopause → zero-receiver → zero-sender → sender policy → receiver policy → balancepause → invalid-receiver → zero-sender → executor policy → sender policy → receiver policy → balancetransferFrom / transferFromWithMemopause → zero-receiver → zero-sender → allowance → executor policy (skipped if msg.sender == from) → sender policy → receiver policy → balancepause → invalid-receiver → zero-sender → allowance → executor policy → sender policy → receiver policy → balance\nAt Denim, the invalid-receiver step also rejects the token’s own address; see\nReject the Token Itself as a Credit Recipient.\nWhen more than one check would fail, the caller sees the first revert in that order.\n​Gas\n_transfer reads all three transfer-side policy IDs from the existing packed slot in one SLOAD.\nOn transferFrom, this removes the second (warm) read the entrypoint used to make.\nOn transfer, the executor lookup is new. When TRANSFER_EXECUTOR_POLICY equals\nTRANSFER_SENDER_POLICY and from == msg.sender (including both slots unset, ALWAYS_ALLOW_ID),\n_transfer reuses the executor result and skips the sender isAuthorized call. A default\ntransfer therefore still makes two isAuthorized calls.\n​Examples\nA holder moving their own tokens is now gated by the executor policy:\nHolder Transfer Blocked by Executor Policytoken.updatePolicy(TRANSFER_EXECUTOR_POLICY, ALWAYS_BLOCK_ID);\n\nvm.prank(alice);\ntoken.transfer(bob, amount); // reverts PolicyForbids(TRANSFER_EXECUTOR_POLICY, ALWAYS_BLOCK_ID)\n\nAn executor allowlist restricts initiation to a transfer agent:\nTransfer Agent Allowlistaddress[] memory agents = new address[](1);\nagents[0] = transferAgent;\nuint64 executorAllowlist =\n policyRegistry.createPolicyWithAccounts(admin, IPolicyRegistry.PolicyType.ALLOWLIST, agents);\ntoken.updatePolicy(TRANSFER_EXECUTOR_POLICY, executorAllowlist);\n\nvm.prank(transferAgent);\ntoken.transferFrom(alice, bob, amount); // succeeds: transferAgent is allowlisted\n\nvm.prank(alice);\ntoken.transfer(bob, amount); // reverts PolicyForbids(TRANSFER_EXECUTOR_POLICY, ...): alice is not allowlisted\n\nThe factory bootstrap bypass still applies. This sketch elides the createB20 arguments:\nBootstrap BypassinitCalls = [\n abi.encodeCall(IB20.mint, (address(factory), amount)),\n abi.encodeCall(IB20.updatePolicy, (TRANSFER_EXECUTOR_POLICY, ALWAYS_BLOCK_ID)),\n abi.encodeCall(IB20.transfer, (to, amount))\n];\nfactory.createB20(..., initCalls); // succeeds: bootstrap window bypasses the executor check\n\n​Design Decisions and Alternatives Considered\nDenim centralizes the executor check in _transfer, on msg.sender, with no msg.sender == from\ncarve-out. It is the smallest change that closes both gaps, adds no interface surface, and matches\nhow the sender and receiver scopes are already enforced.\n​Fold Pause, Zero-Actor, and Allowance Into _transfer\nAllowance is specific to transferFrom. Folding it in would need a consume-allowance flag, and\nmoving the zero-actor checks after allowance would change revert order.\n​Add a Separate Check to transfer\nAdding a matching check to transfer while keeping the transferFrom carve-out leaves the\nself-transferFrom bypass open and duplicates the check across two entrypoints.\n​Migration\nNo action is needed for a token that never set TRANSFER_EXECUTOR_POLICY. The unset slot stays\nalways-allow, and the bootstrap bypass is unchanged.\nFor a token with a restrictive TRANSFER_EXECUTOR_POLICY:\n\nHolders using transfer: they must be authorized under TRANSFER_EXECUTOR_POLICY, directly\nor through a policy they belong to, to keep moving their own tokens.\nHolders using self-transferFrom: the same authorization now applies to that path.\nTo keep allowing holder-initiated transfers: add those holders, or a policy covering them, to\nthe executor allowlist before Denim activates.\n\nThe TRANSFER_EXECUTOR_POLICY\nreference page describes the scope as it behaves before Denim activates.Was this page helpful?Suggest editsRaise issue","tokens":1560,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266825911,"hash":"91de8c1aceee68902f485ca0e9248a4142693fbc"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/51","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 51 / 144\n\n Feb 2018\n\n May 2019\n\n Load more posts above\n\n post by shamatar on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by denett on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by vbuterin on Feb 3, 2018\n\n post by kz on Feb 3, 2018\n\n post by kladkogex on Feb 3, 2018\n\n 2 months later\n\n post by mewwts on Apr 19, 2018\n\n Load more posts below","tokens":1727,"squid":"ink-research","role":"Deep Scholar","at":1791266828976,"hash":"200c89e70360a60d360ed2f9aa753cc73f70347c"}
{"url":"https://docs.base.org/upgrades/cobalt/validity-transactions","domain":"docs.base.org","title":"Overview - Base Documentation","text":"Validity Transactions let you submit a signed transaction with conditions on Base state. The API supports legacy, EIP-2930, and EIP-1559 transactions; EIP-1559 is recommended. Use them for conditional swaps, withdrawals, and other state-dependent actions.\n​How It Works\nSubmit a signed raw transaction and a non-empty validity array. The current API supports storage, block-number, and Flashblock-index predicates.\nA transaction is eligible only when every predicate matches. Base checks predicates before inclusion. A pending transaction can become eligible after an earlier transaction changes the state it watches.\nEIP-1559 Validity Transactions use normal fee fields. Eligibility does not reserve block space or guarantee inclusion.\n​Lifetime and Privacy\nUse block_number or flashblock_index predicates to constrain when a transaction can be included. Use the sender’s nonce when replacing a pending transaction.\nValidity criteria are sent separately from the signed transaction. They do not appear in the resulting onchain transaction. Do not include secrets in calldata or predicate values.\n​Next Steps\nWas this page helpful?Suggest editsRaise issue","tokens":289,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791266836174,"hash":"38263d01152100decbe5fbef23c3c3d09c66a013"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/40","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 40 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n Load more posts below","tokens":3748,"squid":"ink-research","role":"Deep Scholar","at":1791266839094,"hash":"10fa545443634c79c80cfe6ab87889c228c1a106"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/bugs.html","domain":"docs.soliditylang.org","title":"List of Known Bugs — Solidity 0.8.31-develop documentation","text":"List of Known Bugs\n\n Edit on GitHub\n\nList of Known Bugs\nBelow, you can find a JSON-formatted list of some of the known security-relevant bugs in the\nSolidity compiler. The file itself is hosted in the GitHub repository.\nThe list stretches back as far as version 0.3.0, bugs known to be present only\nin versions preceding that are not listed.\nThere is another file called bugs_by_version.json,\nwhich can be used to check which bugs affect a specific version of the compiler.\nContract source verification tools and also other tools interacting with\ncontracts should consult this list according to the following criteria:\n\nIt is mildly suspicious if a contract was compiled with a nightly\ncompiler version instead of a released version. This list does not keep\ntrack of unreleased or nightly versions.\nIt is also mildly suspicious if a contract was compiled with a version that was\nnot the most recent at the time the contract was created. For contracts\ncreated from other contracts, you have to follow the creation chain\nback to a transaction and use the date of that transaction as creation date.\nIt is highly suspicious if a contract was compiled with a compiler that\ncontains a known bug and the contract was created at a time where a newer\ncompiler version containing a fix was already released.\n\nThe JSON file of known bugs below is an array of objects, one for each bug,\nwith the following keys:\n\nuidUnique identifier given to the bug in the form of SOL-<year>-<number>.\nIt is possible that multiple entries exists with the same uid. This means\nmultiple version ranges are affected by the same bug.\n\nnameUnique name given to the bug\n\nsummaryShort description of the bug\n\ndescriptionDetailed description of the bug\n\nlinkURL of a website with more detailed information, optional\n\nintroducedThe first published compiler version that contained the bug, optional\n\nfixedThe first published compiler version that did not contain the bug anymore\n\npublishThe date at which the bug became known publicly, optional\n\nseveritySeverity of the bug: very low, low, medium, high. Takes into account\ndiscoverability in contract tests, likelihood of occurrence and\npotential damage by exploits.\n\nconditionsConditions that have to be met to trigger the bug. The following\nkeys can be used:\noptimizer, Boolean value which\nmeans that the optimizer has to be switched on to enable the bug.\nevmVersion, a string that indicates which EVM version compiler\nsettings trigger the bug. The string can contain comparison\noperators. For example, \">=constantinople\" means that the bug\nis present when the EVM version is set to constantinople or\nlater.\nIf no conditions are given, assume that the bug is present.\n\ncheckThis field contains different checks that report whether the smart contract\ncontains the bug or not. The first type of check are JavaScript regular\nexpressions that are to be matched against the source code (“source-regex”)\nif the bug is present. If there is no match, then the bug is very likely\nnot present. If there is a match, the bug might be present. For improved\naccuracy, the checks should be applied to the source code after stripping\ncomments.\nThe second type of check are patterns to be checked on the compact AST of\nthe Solidity program (“ast-compact-json-path”). The specified search query\nis a JsonPath expression.\nIf at least one path of the Solidity AST matches the query, the bug is\nlikely present.\n\n[\n {\n \"uid\": \"SOL-2023-3\",\n \"name\": \"VerbatimInvalidDeduplication\",\n \"summary\": \"All ``verbatim`` blocks are considered identical by deduplicator and can incorrectly be unified when surrounded by identical opcodes.\",\n \"description\": \"The block deduplicator is a step of the opcode-based optimizer which identifies equivalent assembly blocks and merges them into a single one. However, when blocks contained ``verbatim``, their comparison was performed incorrectly, leading to the collapse of assembly blocks which are identical except for the contents of the ``verbatim`` items. Since ``verbatim`` is only available in Yul, compilation of Solidity sources is not affected.\",\n \"link\": \"https://blog.soliditylang.org/2023/11/08/verbatim-invalid-deduplication-bug/\",\n \"introduced\": \"0.8.5\",\n \"fixed\": \"0.8.23\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2023-2\",\n \"name\": \"FullInlinerNonExpressionSplitArgumentEvaluationOrder\",\n \"summary\": \"Optimizer sequences containing FullInliner do not preserve the evaluation order of arguments of inlined function calls in code that is not in expression-split form.\",\n \"description\": \"Function call arguments in Yul are evaluated right to left. This order matters when the argument expressions have side-effects, and changing it may change contract behavior. FullInliner is an optimizer step that can replace a function call with the body of that function. The transformation involves assigning argument expressions to temporary variables, which imposes an explicit evaluation order. FullInliner was written with the assumption that this order does not necessarily have to match usual argument evaluation order because the argument expressions have no side-effects. In most circumstances this assumption is true because the default optimization step sequence contains the ExpressionSplitter step. ExpressionSplitter ensures that the code is in *expression-split form*, which means that function calls cannot appear nested inside expressions, and all function call arguments have to be variables. The assumption is, however, not guaranteed to be true in general. Version 0.6.7 introduced a setting allowing users to specify an arbitrary optimization step sequence, making it possible for the FullInliner to actually encounter argument expressions with side-effects, which can result in behavior differences between optimized and unoptimized bytecode. Contracts compiled without optimization or with the default optimization sequence are not affected. To trigger the bug the user has to explicitly choose compiler settings that contain a sequence with FullInliner step not preceded by ExpressionSplitter.\",\n \"link\": \"https://blog.soliditylang.org/2023/07/19/full-inliner-non-expression-split-argument-evaluation-order-bug/\",\n \"introduced\": \"0.6.7\",\n \"fixed\": \"0.8.21\",\n \"severity\": \"low\",\n \"conditions\": {\n \"yulOptimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2023-1\",\n \"name\": \"MissingSideEffectsOnSelectorAccess\",\n \"summary\": \"Accessing the ``.selector`` member on complex expressions leaves the expression unevaluated in the legacy code generation.\",\n \"description\": \"When accessing the ``.selector`` member on an expression with side-effects, like an assignment, a function call or a conditional, the expression would not be evaluated in the legacy code generation. This would happen in expressions where the functions used in the expression were all known at compilation time, regardless of whether the whole expression could be evaluated at compilation time or not. Note that the code generated by the IR pipeline was unaffected and would behave as expected.\",\n \"link\": \"https://blog.soliditylang.org/2023/07/19/missing-side-effects-on-selector-access-bug/\",\n \"introduced\": \"0.6.2\",\n \"fixed\": \"0.8.21\",\n \"severity\": \"low\",\n \"conditions\": {\n \"viaIR\": false\n }\n },\n {\n \"uid\": \"SOL-2022-7\",\n \"name\": \"StorageWriteRemovalBeforeConditionalTermination\",\n \"summary\": \"Calling functions that conditionally terminate the external EVM call using the assembly statements ``return(...)`` or ``stop()`` may result in incorrect removals of prior storage writes.\",\n \"description\": \"A call to a Yul function that conditionally terminates the external EVM call could result in prior storage writes being incorrectly removed by the Yul optimizer. This used to happen in cases in which it would have been valid to remove the store, if the Yul function in question never actually terminated the external call, and the control flow always returned back to the caller instead. Conditional termination within the same Yul block instead of within a called function was not affected. In Solidity with optimized via-IR code generation, any storage write before a function conditionally calling ``return(...)`` or ``stop()`` in inline assembly, may have been incorrectly removed, whenever it would have been valid to remove the write without the ``return(...)`` or ``stop()``. In optimized legacy code generation, only inline assembly that did not refer to any Solidity variables and that involved conditionally-terminating user-defined assembly functions could be affected.\",\n \"link\": \"https://blog.soliditylang.org/2022/09/08/storage-write-removal-before-conditional-termination/\",\n \"introduced\": \"0.8.13\",\n \"fixed\": \"0.8.17\",\n \"severity\": \"medium/high\",\n \"conditions\": {\n \"yulOptimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2022-6\",\n \"name\": \"AbiReencodingHeadOverflowWithStaticArrayCleanup\",\n \"summary\": \"ABI-encoding a tuple with a statically-sized calldata array in the last component would corrupt 32 leading bytes of its first dynamically encoded component.\",\n \"description\": \"When ABI-encoding a statically-sized calldata array, the compiler always pads the data area to a multiple of 32-bytes and ensures that the padding bytes are zeroed. In some cases, this cleanup used to be performed by always writing exactly 32 bytes, regardless of how many needed to be zeroed. This was done with the assumption that the data that would eventually occupy the area past the end of the array had not yet been written, because the encoder processes tuple components in the order they were given. While this assumption is mostly true, there is an important corner case: dynamically encoded tuple components are stored separately from the statically-sized ones in an area called the *tail* of the encoding and the tail immediately follows the *head*, which is where the statically-sized components are placed. The aforementioned cleanup, if performed for the last component of the head would cross into the tail and overwrite up to 32 bytes of the first component stored there with zeros. The only array type for which the cleanup could actually result in an overwrite were arrays with ``uint256`` or ``bytes32`` as the base element type and in this case the size of the corrupted area was always exactly 32 bytes. The problem affected tuples at any nesting level. This included also structs, which are encoded as tuples in the ABI. Note also that lists of parameters and return values of functions, events and errors are encoded as tuples.\",\n \"link\": \"https://blog.soliditylang.org/2022/08/08/calldata-tuple-reencoding-head-overflow-bug/\",\n \"introduced\": \"0.5.8\",\n \"fixed\": \"0.8.16\",\n \"severity\": \"medium\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2022-5\",\n \"name\": \"DirtyBytesArrayToStorage\",\n \"summary\": \"Copying ``bytes`` arrays from memory or calldata to storage may result in dirty storage values.\",\n \"description\": \"Copying ``bytes`` arrays from memory or calldata to storage is done in chunks of 32 bytes even if the length is not a multiple of 32. Thereby, extra bytes past the end of the array may be copied from calldata or memory to storage. These dirty bytes may then become observable after a ``.push()`` without arguments to the bytes array in storage, i.e. such a push will not result in a zero value at the end of the array as expected. This bug only affects the legacy code generation pipeline, the new code generation pipeline via IR is not affected.\",\n \"link\": \"https://blog.soliditylang.org/2022/06/15/dirty-bytes-array-to-storage-bug/\",\n \"introduced\": \"0.0.1\",\n \"fixed\": \"0.8.15\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2022-4\",\n \"name\": \"InlineAssemblyMemorySideEffects\",\n \"summary\": \"The Yul optimizer may incorrectly remove memory writes from inline assembly blocks, that do not access solidity variables.\",\n \"description\": \"The Yul optimizer considers all memory writes in the outermost Yul block that are never read from as unused and removes them. This is valid when that Yul block is the entire Yul program, which is always the case for the Yul code generated by the new via-IR pipeline. Inline assembly blocks are never optimized in isolation when using that pipeline. Instead they are optimized as a part of the whole Yul input. However, the legacy code generation pipeline (which is still the default) runs the Yul optimizer individually on an inline assembly block if the block does not refer to any local variables defined in the surrounding Solidity code. Consequently, memory writes in such inline assembly blocks are removed as well, if the written memory is never read from in the same assembly block, even if the written memory is accessed later, for example by a subsequent inline assembly block.\",\n \"link\": \"https://blog.soliditylang.org/2022/06/15/inline-assembly-memory-side-effects-bug/\",\n \"introduced\": \"0.8.13\",\n \"fixed\": \"0.8.15\",\n \"severity\": \"medium\",\n \"conditions\": {\n \"yulOptimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2022-3\",\n \"name\": \"DataLocationChangeInInternalOverride\",\n \"summary\": \"It was possible to change the data location of the parameters or return variables from ``calldata`` to ``memory`` and vice-versa while overriding internal and public functions. This caused invalid code to be generated when calling such a function internally through virtual function calls.\",\n \"description\": \"When calling external functions, it is irrelevant if the data location of the parameters is ``calldata`` or ``memory``, the encoding of the data does not change. Because of that, changing the data location when overriding external functions is allowed. The compiler incorrectly also allowed a change in the data location for overriding public and internal functions. Since public functions can be called internally as well as externally, this causes invalid code to be generated when such an incorrectly overridden function is called internally through the base contract. The caller provides a memory pointer, but the called function interprets it as a calldata pointer or vice-versa.\",\n \"link\": \"https://blog.soliditylang.org/2022/05/17/data-location-inheritance-bug/\",\n \"introduced\": \"0.6.9\",\n \"fixed\": \"0.8.14\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2022-2\",\n \"name\": \"NestedCalldataArrayAbiReencodingSizeValidation\",\n \"summary\": \"ABI-reencoding of nested dynamic calldata arrays did not always perform proper size checks against the size of calldata and could read beyond ``calldatasize()``.\",\n \"description\": \"Calldata validation for nested dynamic types is deferred until the first access to the nested values. Such an access may for example be a copy to memory or an index or member access to the outer type. While in most such accesses calldata validation correctly checks that the data area of the nested array is completely contained in the passed calldata (i.e. in the range [0, calldatasize()]), this check may not be performed, when ABI encoding such nested types again directly from calldata. For instance, this can happen, if a value in calldata with a nested dynamic array is passed to an external call, used in ``abi.encode`` or emitted as event. In such cases, if the data area of the nested array extends beyond ``calldatasize()``, ABI encoding it did not revert, but continued reading values from beyond ``calldatasize()`` (i.e. zero values).\",\n \"link\": \"https://blog.soliditylang.org/2022/05/17/calldata-reencode-size-check-bug/\",\n \"introduced\": \"0.5.8\",\n \"fixed\": \"0.8.14\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2022-1\",\n \"name\": \"AbiEncodeCallLiteralAsFixedBytesBug\",\n \"summary\": \"Literals used for a fixed length bytes parameter in ``abi.encodeCall`` were encoded incorrectly.\",\n \"description\": \"For the encoding, the compiler only considered the types of the expressions in the second argument of ``abi.encodeCall`` itself, but not the parameter types of the function given as first argument. In almost all cases the abi encoding of the type of the expression matches the abi encoding of the parameter type of the given function. This is because the type checker ensures the expression is implicitly convertible to the respective parameter type. However this is not true for number literals used for fixed bytes types shorter than 32 bytes, nor for string literals used for any fixed bytes type. Number literals were encoded as numbers instead of being shifted to become left-aligned. String literals were encoded as dynamically sized memory strings instead of being converted to a left-aligned bytes value.\",\n \"link\": \"https://blog.soliditylang.org/2022/03/16/encodecall-bug/\",\n \"introduced\": \"0.8.11\",\n \"fixed\": \"0.8.13\",\n \"severity\": \"very low\"\n\n },\n {\n \"uid\": \"SOL-2021-4\",\n \"name\": \"UserDefinedValueTypesBug\",\n \"summary\": \"User defined value types with underlying type shorter than 32 bytes used incorrect storage layout and wasted storage\",\n \"description\": \"The compiler did not correctly compute the storage layout of user defined value types based on types that are shorter than 32 bytes. It would always use a full storage slot for these types, even if the underlying type was shorter. This was wasteful and might have problems with tooling or contract upgrades.\",\n \"link\": \"https://blog.soliditylang.org/2021/09/29/user-defined-value-types-bug/\",\n \"introduced\": \"0.8.8\",\n \"fixed\": \"0.8.9\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2021-3\",\n \"name\": \"SignedImmutables\",\n \"summary\": \"Immutable variables of signed integer type shorter than 256 bits can lead to values with invalid higher order bits if inline assembly is used.\",\n \"description\": \"When immutable variables of signed integer type shorter than 256 bits are read, their higher order bits were unconditionally set to zero. The correct operation would be to sign-extend the value, i.e. set the higher order bits to one if the sign bit is one. This sign-extension is performed by Solidity just prior to when it matters, i.e. when a value is stored in memory, when it is compared or when a division is performed. Because of that, to our knowledge, the only way to access the value in its unclean state is by reading it through inline assembly.\",\n \"link\": \"https://blog.soliditylang.org/2021/09/29/signed-immutables-bug/\",\n \"introduced\": \"0.6.5\",\n \"fixed\": \"0.8.9\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2021-2\",\n \"name\": \"ABIDecodeTwoDimensionalArrayMemory\",\n \"summary\": \"If used on memory byte arrays, result of the function ``abi.decode`` can depend on the contents of memory outside of the actual byte array that is decoded.\",\n \"description\": \"The ABI specification uses pointers to data areas for everything that is dynamically-sized. When decoding data from memory (instead of calldata), the ABI decoder did not properly validate some of these pointers. More specifically, it was possible to use large values for the pointers inside arrays such that computing the offset resulted in an undetected overflow. This could lead to these pointers targeting areas in memory outside of the actual area to be decoded. This way, it was possible for ``abi.decode`` to return different values for the same encoded byte array.\",\n \"link\": \"https://blog.soliditylang.org/2021/04/21/decoding-from-memory-bug/\",\n \"introduced\": \"0.4.16\",\n \"fixed\": \"0.8.4\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n },\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2021-1\",\n \"name\": \"KeccakCaching\",\n \"summary\": \"The bytecode optimizer incorrectly reused previously evaluated Keccak-256 hashes. You are unlikely to be affected if you do not compute Keccak-256 hashes in inline assembly.\",\n \"description\": \"Solidity's bytecode optimizer has a step that can compute Keccak-256 hashes, if the contents of the memory are known during compilation time. This step also has a mechanism to determine that two Keccak-256 hashes are equal even if the values in memory are not known during compile time. This mechanism had a bug where Keccak-256 of the same memory content, but different sizes were considered equal. More specifically, ``keccak256(mpos1, length1)`` and ``keccak256(mpos2, length2)`` in some cases were considered equal if ``length1`` and ``length2``, when rounded up to nearest multiple of 32 were the same, and when the memory contents at ``mpos1`` and ``mpos2`` can be deduced to be equal. You maybe affected if you compute multiple Keccak-256 hashes of the same content, but with different lengths inside inline assembly. You are unaffected if your code uses ``keccak256`` with a length that is not a compile-time constant or if it is always a multiple of 32.\",\n \"link\": \"https://blog.soliditylang.org/2021/03/23/keccak-optimizer-bug/\",\n \"fixed\": \"0.8.3\",\n \"conditions\": {\n \"optimizer\": true\n },\n \"severity\": \"medium\"\n },\n {\n \"uid\": \"SOL-2020-11\",\n \"name\": \"EmptyByteArrayCopy\",\n \"summary\": \"Copying an empty byte array (or string) from memory or calldata to storage can result in data corruption if the target array's length is increased subsequently without storing new data.\",\n \"description\": \"The routine that copies byte arrays from memory or calldata to storage stores unrelated data from after the source array in the storage slot if the source array is empty. If the storage array's length is subsequently increased either by using ``.push()`` or by assigning to its ``.length`` attribute (only before 0.6.0), the newly created byte array elements will not be zero-initialized, but contain the unrelated data. You are not affected if you do not assign to ``.length`` and do not use ``.push()`` on byte arrays, or only use ``.push(<arg>)`` or manually initialize the new elements.\",\n \"link\": \"https://blog.soliditylang.org/2020/10/19/empty-byte-array-copy-bug/\",\n \"fixed\": \"0.7.4\",\n \"severity\": \"medium\"\n },\n {\n \"uid\": \"SOL-2020-10\",\n \"name\": \"DynamicArrayCleanup\",\n \"summary\": \"When assigning a dynamically-sized array with types of size at most 16 bytes in storage causing the assigned array to shrink, some parts of deleted slots were not zeroed out.\",\n \"description\": \"Consider a dynamically-sized array in storage whose base-type is small enough such that multiple values can be packed into a single slot, such as `uint128[]`. Let us define its length to be `l`. When this array gets assigned from another array with a smaller length, say `m`, the slots between elements `m` and `l` have to be cleaned by zeroing them out. However, this cleaning was not performed properly. Specifically, after the slot corresponding to `m`, only the first packed value was cleaned up. If this array gets resized to a length larger than `m`, the indices corresponding to the unclean parts of the slot contained the original value, instead of 0. The resizing here is performed by assigning to the array `length`, by a `push()` or via inline assembly. You are not affected if you are only using `.push(<arg>)` or if you assign a value (even zero) to the new elements after increasing the length of the array.\",\n \"link\": \"https://blog.soliditylang.org/2020/10/07/solidity-dynamic-array-cleanup-bug/\",\n \"fixed\": \"0.7.3\",\n \"severity\": \"medium\"\n },\n {\n \"uid\": \"SOL-2020-9\",\n \"name\": \"FreeFunctionRedefinition\",\n \"summary\": \"The compiler does not flag an error when two or more free functions with the same name and parameter types are defined in a source unit or when an imported free function alias shadows another free function with a different name but identical parameter types.\",\n \"description\": \"In contrast to functions defined inside contracts, free functions with identical names and parameter types did not create an error. Both definition of free functions with identical name and parameter types and an imported free function with an alias that shadows another function with a different name but identical parameter types were permitted due to which a call to either the multiply defined free function or the imported free function alias within a contract led to the execution of that free function which was defined first within the source unit. Subsequently defined identical free function definitions were silently ignored and their code generation was skipped.\",\n \"introduced\": \"0.7.1\",\n \"fixed\": \"0.7.2\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2020-8\",\n \"name\": \"UsingForCalldata\",\n \"summary\": \"Function calls to internal library functions with calldata parameters called via ``using for`` can result in invalid data being read.\",\n \"description\": \"Function calls to internal library functions using the ``using for`` mechanism copied all calldata parameters to memory first and passed them on like that, regardless of whether it was an internal or an external call. Due to that, the called function would receive a memory pointer that is interpreted as a calldata pointer. Since dynamically sized arrays are passed using two stack slots for calldata, but only one for memory, this can lead to stack corruption. An affected library call will consider the JUMPDEST to which it is supposed to return as part of its arguments and will instead jump out to whatever was on the stack before the call.\",\n \"introduced\": \"0.6.9\",\n \"fixed\": \"0.6.10\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2020-7\",\n \"name\": \"MissingEscapingInFormatting\",\n \"summary\": \"String literals containing double backslash characters passed directly to external or encoding function calls can lead to a different string being used when ABIEncoderV2 is enabled.\",\n \"description\": \"When ABIEncoderV2 is enabled, string literals passed directly to encoding functions or external function calls are stored as strings in the intermediate code. Characters outside the printable range are handled correctly, but backslashes are not escaped in this procedure. This leads to double backslashes being reduced to single backslashes and consequently re-interpreted as escapes potentially resulting in a different string being encoded.\",\n \"introduced\": \"0.5.14\",\n \"fixed\": \"0.6.8\",\n \"severity\": \"very low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2020-6\",\n \"name\": \"ArraySliceDynamicallyEncodedBaseType\",\n \"summary\": \"Accessing array slices of arrays with dynamically encoded base types (e.g. multi-dimensional arrays) can result in invalid data being read.\",\n \"description\": \"For arrays with dynamically sized base types, index range accesses that use a start expression that is non-zero will result in invalid array slices. Any index access to such array slices will result in data being read from incorrect calldata offsets. Array slices are only supported for dynamic calldata types and all problematic type require ABIEncoderV2 to be enabled.\",\n \"introduced\": \"0.6.0\",\n \"fixed\": \"0.6.8\",\n \"severity\": \"very low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2020-5\",\n \"name\": \"ImplicitConstructorCallvalueCheck\",\n \"summary\": \"The creation code of a contract that does not define a constructor but has a base that does define a constructor did not revert for calls with non-zero value.\",\n \"description\": \"Starting from Solidity 0.4.5 the creation code of contracts without explicit payable constructor is supposed to contain a callvalue check that results in contract creation reverting, if non-zero value is passed. However, this check was missing in case no explicit constructor was defined in a contract at all, but the contract has a base that does define a constructor. In these cases it is possible to send value in a contract creation transaction or using inline assembly without revert, even though the creation code is supposed to be non-payable.\",\n \"introduced\": \"0.4.5\",\n \"fixed\": \"0.6.8\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2020-4\",\n \"name\": \"TupleAssignmentMultiStackSlotComponents\",\n \"summary\": \"Tuple assignments with components that occupy several stack slots, i.e. nested tuples, pointers to external functions or references to dynamically sized calldata arrays, can result in invalid values.\",\n \"description\": \"Tuple assignments did not correctly account for tuple components that occupy multiple stack slots in case the number of stack slots differs between left-hand-side and right-hand-side. This can either happen in the presence of nested tuples or if the right-hand-side contains external function pointers or references to dynamic calldata arrays, while the left-hand-side contains an omission.\",\n \"introduced\": \"0.1.6\",\n \"fixed\": \"0.6.6\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2020-3\",\n \"name\": \"MemoryArrayCreationOverflow\",\n \"summary\": \"The creation of very large memory arrays can result in overlapping memory regions and thus memory corruption.\",\n \"description\": \"No runtime overflow checks were performed for the length of memory arrays during creation. In cases for which the memory size of an array in bytes, i.e. the array length times 32, is larger than 2^256-1, the memory allocation will overflow, potentially resulting in overlapping memory areas. The length of the array is still stored correctly, so copying or iterating over such an array will result in out-of-gas.\",\n \"link\": \"https://blog.soliditylang.org/2020/04/06/memory-creation-overflow-bug/\",\n \"introduced\": \"0.2.0\",\n \"fixed\": \"0.6.5\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2020-1\",\n \"name\": \"YulOptimizerRedundantAssignmentBreakContinue\",\n \"summary\": \"The Yul optimizer can remove essential assignments to variables declared inside for loops when Yul's continue or break statement is used. You are unlikely to be affected if you do not use inline assembly with for loops and continue and break statements.\",\n \"description\": \"The Yul optimizer has a stage that removes assignments to variables that are overwritten again or are not used in all following control-flow branches. This logic incorrectly removes such assignments to variables declared inside a for loop if they can be removed in a control-flow branch that ends with ``break`` or ``continue`` even though they cannot be removed in other control-flow branches. Variables declared outside of the respective for loop are not affected.\",\n \"introduced\": \"0.6.0\",\n \"fixed\": \"0.6.1\",\n \"severity\": \"medium\",\n \"conditions\": {\n \"yulOptimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2020-2\",\n \"name\": \"privateCanBeOverridden\",\n \"summary\": \"Private methods can be overridden by inheriting contracts.\",\n \"description\": \"While private methods of base contracts are not visible and cannot be called directly from the derived contract, it is still possible to declare a function of the same name and type and thus change the behaviour of the base contract's function.\",\n \"introduced\": \"0.3.0\",\n \"fixed\": \"0.5.17\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2020-1\",\n \"name\": \"YulOptimizerRedundantAssignmentBreakContinue0.5\",\n \"summary\": \"The Yul optimizer can remove essential assignments to variables declared inside for loops when Yul's continue or break statement is used. You are unlikely to be affected if you do not use inline assembly with for loops and continue and break statements.\",\n \"description\": \"The Yul optimizer has a stage that removes assignments to variables that are overwritten again or are not used in all following control-flow branches. This logic incorrectly removes such assignments to variables declared inside a for loop if they can be removed in a control-flow branch that ends with ``break`` or ``continue`` even though they cannot be removed in other control-flow branches. Variables declared outside of the respective for loop are not affected.\",\n \"introduced\": \"0.5.8\",\n \"fixed\": \"0.5.16\",\n \"severity\": \"low\",\n \"conditions\": {\n \"yulOptimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2019-10\",\n \"name\": \"ABIEncoderV2LoopYulOptimizer\",\n \"summary\": \"If both the experimental ABIEncoderV2 and the experimental Yul optimizer are activated, one component of the Yul optimizer may reuse data in memory that has been changed in the meantime.\",\n \"description\": \"The Yul optimizer incorrectly replaces ``mload`` and ``sload`` calls with values that have been previously written to the load location (and potentially changed in the meantime) if all of the following conditions are met: (1) there is a matching ``mstore`` or ``sstore`` call before; (2) the contents of memory or storage is only changed in a function that is called (directly or indirectly) in between the first store and the load call; (3) called function contains a for loop where the same memory location is changed in the condition or the post or body block. When used in Solidity mode, this can only happen if the experimental ABIEncoderV2 is activated and the experimental Yul optimizer has been activated manually in addition to the regular optimizer in the compiler settings.\",\n \"introduced\": \"0.5.14\",\n \"fixed\": \"0.5.15\",\n \"severity\": \"low\",\n \"conditions\": {\n \"ABIEncoderV2\": true,\n \"optimizer\": true,\n \"yulOptimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2019-9\",\n \"name\": \"ABIEncoderV2CalldataStructsWithStaticallySizedAndDynamicallyEncodedMembers\",\n \"summary\": \"Reading from calldata structs that contain dynamically encoded, but statically-sized members can result in incorrect values.\",\n \"description\": \"When a calldata struct contains a dynamically encoded, but statically-sized member, the offsets for all subsequent struct members are calculated incorrectly. All reads from such members will result in invalid values. Only calldata structs are affected, i.e. this occurs in external functions with such structs as argument. Using affected structs in storage or memory or as arguments to public functions on the other hand works correctly.\",\n \"introduced\": \"0.5.6\",\n \"fixed\": \"0.5.11\",\n \"severity\": \"low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2019-8\",\n \"name\": \"SignedArrayStorageCopy\",\n \"summary\": \"Assigning an array of signed integers to a storage array of different type can lead to data corruption in that array.\",\n \"description\": \"In two's complement, negative integers have their higher order bits set. In order to fit into a shared storage slot, these have to be set to zero. When a conversion is done at the same time, the bits to set to zero were incorrectly determined from the source and not the target type. This means that such copy operations can lead to incorrect values being stored.\",\n \"link\": \"https://blog.soliditylang.org/2019/06/25/solidity-storage-array-bugs/\",\n \"introduced\": \"0.4.7\",\n \"fixed\": \"0.5.10\",\n \"severity\": \"low/medium\"\n },\n {\n \"uid\": \"SOL-2019-7\",\n \"name\": \"ABIEncoderV2StorageArrayWithMultiSlotElement\",\n \"summary\": \"Storage arrays containing structs or other statically-sized arrays are not read properly when directly encoded in external function calls or in abi.encode*.\",\n \"description\": \"When storage arrays whose elements occupy more than a single storage slot are directly encoded in external function calls or using abi.encode*, their elements are read in an overlapping manner, i.e. the element pointer is not properly advanced between reads. This is not a problem when the storage data is first copied to a memory variable or if the storage array only contains value types or dynamically-sized arrays.\",\n \"link\": \"https://blog.soliditylang.org/2019/06/25/solidity-storage-array-bugs/\",\n \"introduced\": \"0.4.16\",\n \"fixed\": \"0.5.10\",\n \"severity\": \"low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2019-6\",\n \"name\": \"DynamicConstructorArgumentsClippedABIV2\",\n \"summary\": \"A contract's constructor that takes structs or arrays that contain dynamically-sized arrays reverts or decodes to invalid data.\",\n \"description\": \"During construction of a contract, constructor parameters are copied from the code section to memory for decoding. The amount of bytes to copy was calculated incorrectly in case all parameters are statically-sized but contain dynamically-sized arrays as struct members or inner arrays. Such types are only available if ABIEncoderV2 is activated.\",\n \"introduced\": \"0.4.16\",\n \"fixed\": \"0.5.9\",\n \"severity\": \"very low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2019-5\",\n \"name\": \"UninitializedFunctionPointerInConstructor\",\n \"summary\": \"Calling uninitialized internal function pointers created in the constructor does not always revert and can cause unexpected behaviour.\",\n \"description\": \"Uninitialized internal function pointers point to a special piece of code that causes a revert when called. Jump target positions are different during construction and after deployment, but the code for setting this special jump target only considered the situation after deployment.\",\n \"introduced\": \"0.5.0\",\n \"fixed\": \"0.5.8\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2019-5\",\n \"name\": \"UninitializedFunctionPointerInConstructor_0.4.x\",\n \"summary\": \"Calling uninitialized internal function pointers created in the constructor does not always revert and can cause unexpected behaviour.\",\n \"description\": \"Uninitialized internal function pointers point to a special piece of code that causes a revert when called. Jump target positions are different during construction and after deployment, but the code for setting this special jump target only considered the situation after deployment.\",\n \"introduced\": \"0.4.5\",\n \"fixed\": \"0.4.26\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2019-4\",\n \"name\": \"IncorrectEventSignatureInLibraries\",\n \"summary\": \"Contract types used in events in libraries cause an incorrect event signature hash\",\n \"description\": \"Instead of using the type `address` in the hashed signature, the actual contract name was used, leading to a wrong hash in the logs.\",\n \"introduced\": \"0.5.0\",\n \"fixed\": \"0.5.8\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2019-4\",\n \"name\": \"IncorrectEventSignatureInLibraries_0.4.x\",\n \"summary\": \"Contract types used in events in libraries cause an incorrect event signature hash\",\n \"description\": \"Instead of using the type `address` in the hashed signature, the actual contract name was used, leading to a wrong hash in the logs.\",\n \"introduced\": \"0.3.0\",\n \"fixed\": \"0.4.26\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2019-3\",\n \"name\": \"ABIEncoderV2PackedStorage\",\n \"summary\": \"Storage structs and arrays with types shorter than 32 bytes can cause data corruption if encoded directly from storage using the experimental ABIEncoderV2.\",\n \"description\": \"Elements of structs and arrays that are shorter than 32 bytes are not properly decoded from storage when encoded directly (i.e. not via a memory type) using ABIEncoderV2. This can cause corruption in the values themselves but can also overwrite other parts of the encoded data.\",\n \"link\": \"https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/\",\n \"introduced\": \"0.5.0\",\n \"fixed\": \"0.5.7\",\n \"severity\": \"low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2019-3\",\n \"name\": \"ABIEncoderV2PackedStorage_0.4.x\",\n \"summary\": \"Storage structs and arrays with types shorter than 32 bytes can cause data corruption if encoded directly from storage using the experimental ABIEncoderV2.\",\n \"description\": \"Elements of structs and arrays that are shorter than 32 bytes are not properly decoded from storage when encoded directly (i.e. not via a memory type) using ABIEncoderV2. This can cause corruption in the values themselves but can also overwrite other parts of the encoded data.\",\n \"link\": \"https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/\",\n \"introduced\": \"0.4.19\",\n \"fixed\": \"0.4.26\",\n \"severity\": \"low\",\n \"conditions\": {\n \"ABIEncoderV2\": true\n }\n },\n {\n \"uid\": \"SOL-2019-2\",\n \"name\": \"IncorrectByteInstructionOptimization\",\n \"summary\": \"The optimizer incorrectly handles byte opcodes whose second argument is 31 or a constant expression that evaluates to 31. This can result in unexpected values.\",\n \"description\": \"The optimizer incorrectly handles byte opcodes that use the constant 31 as second argument. This can happen when performing index access on bytesNN types with a compile-time constant value (not index) of 31 or when using the byte opcode in inline assembly.\",\n \"link\": \"https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/\",\n \"introduced\": \"0.5.5\",\n \"fixed\": \"0.5.7\",\n \"severity\": \"very low\",\n \"conditions\": {\n \"optimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2019-1\",\n \"name\": \"DoubleShiftSizeOverflow\",\n \"summary\": \"Double bitwise shifts by large constants whose sum overflows 256 bits can result in unexpected values.\",\n \"description\": \"Nested logical shift operations whose total shift size is 2**256 or more are incorrectly optimized. This only applies to shifts by numbers of bits that are compile-time constant expressions.\",\n \"link\": \"https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/\",\n \"introduced\": \"0.5.5\",\n \"fixed\": \"0.5.6\",\n \"severity\": \"low\",\n \"conditions\": {\n \"optimizer\": true,\n \"evmVersion\": \">=constantinople\"\n }\n },\n {\n \"uid\": \"SOL-2018-4\",\n \"name\": \"ExpExponentCleanup\",\n \"summary\": \"Using the ** operator with an exponent of type shorter than 256 bits can result in unexpected values.\",\n \"description\": \"Higher order bits in the exponent are not properly cleaned before the EXP opcode is applied if the type of the exponent expression is smaller than 256 bits and not smaller than the type of the base. In that case, the result might be larger than expected if the exponent is assumed to lie within the value range of the type. Literal numbers as exponents are unaffected as are exponents or bases of type uint256.\",\n \"link\": \"https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/\",\n \"fixed\": \"0.4.25\",\n \"severity\": \"medium/high\",\n \"check\": {\"regex-source\": \"[^/]\\\\*\\\\* *[^/0-9 ]\"}\n },\n {\n \"uid\": \"SOL-2018-3\",\n \"name\": \"EventStructWrongData\",\n \"summary\": \"Using structs in events logged wrong data.\",\n \"description\": \"If a struct is used in an event, the address of the struct is logged instead of the actual data.\",\n \"link\": \"https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/\",\n \"introduced\": \"0.4.17\",\n \"fixed\": \"0.4.25\",\n \"severity\": \"very low\",\n \"check\": {\"ast-compact-json-path\": \"$..[?(@.nodeType === 'EventDefinition')]..[?(@.nodeType === 'UserDefinedTypeName' && @.typeDescriptions.typeString.startsWith('struct'))]\"}\n },\n {\n \"uid\": \"SOL-2018-2\",\n \"name\": \"NestedArrayFunctionCallDecoder\",\n \"summary\": \"Calling functions that return multi-dimensional fixed-size arrays can result in memory corruption.\",\n \"description\": \"If Solidity code calls a function that returns a multi-dimensional fixed-size array, array elements are incorrectly interpreted as memory pointers and thus can cause memory corruption if the return values are accessed. Calling functions with multi-dimensional fixed-size arrays is unaffected as is returning fixed-size arrays from function calls. The regular expression only checks if such functions are present, not if they are called, which is required for the contract to be affected.\",\n \"link\": \"https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/\",\n \"introduced\": \"0.1.4\",\n \"fixed\": \"0.4.22\",\n \"severity\": \"medium\",\n \"check\": {\"regex-source\": \"returns[^;{]*\\\\[\\\\s*[^\\\\] \\\\t\\\\r\\\\n\\\\v\\\\f][^\\\\]]*\\\\]\\\\s*\\\\[\\\\s*[^\\\\] \\\\t\\\\r\\\\n\\\\v\\\\f][^\\\\]]*\\\\][^{;]*[;{]\"}\n },\n {\n \"uid\": \"SOL-2018-1\",\n \"name\": \"OneOfTwoConstructorsSkipped\",\n \"summary\": \"If a contract has both a new-style constructor (using the constructor keyword) and an old-style constructor (a function with the same name as the contract) at the same time, one of them will be ignored.\",\n \"description\": \"If a contract has both a new-style constructor (using the constructor keyword) and an old-style constructor (a function with the same name as the contract) at the same time, one of them will be ignored. There will be a compiler warning about the old-style constructor, so contracts only using new-style constructors are fine.\",\n \"introduced\": \"0.4.22\",\n \"fixed\": \"0.4.23\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2017-5\",\n \"name\": \"ZeroFunctionSelector\",\n \"summary\": \"It is possible to craft the name of a function such that it is executed instead of the fallback function in very specific circumstances.\",\n \"description\": \"If a function has a selector consisting only of zeros, is payable and part of a contract that does not have a fallback function and at most five external functions in total, this function is called instead of the fallback function if Ether is sent to the contract without data.\",\n \"fixed\": \"0.4.18\",\n \"severity\": \"very low\"\n },\n {\n \"uid\": \"SOL-2017-4\",\n \"name\": \"DelegateCallReturnValue\",\n \"summary\": \"The low-level .delegatecall() does not return the execution outcome, but converts the value returned by the functioned called to a boolean instead.\",\n \"description\": \"The return value of the low-level .delegatecall() function is taken from a position in memory, where the call data or the return data resides. This value is interpreted as a boolean and put onto the stack. This means if the called function returns at least 32 zero bytes, .delegatecall() returns false even if the call was successful.\",\n \"introduced\": \"0.3.0\",\n \"fixed\": \"0.4.15\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2017-3\",\n \"name\": \"ECRecoverMalformedInput\",\n \"summary\": \"The ecrecover() builtin can return garbage for malformed input.\",\n \"description\": \"The ecrecover precompile does not properly signal failure for malformed input (especially in the 'v' argument) and thus the Solidity function can return data that was previously present in the return area in memory.\",\n \"fixed\": \"0.4.14\",\n \"severity\": \"medium\"\n },\n {\n \"uid\": \"SOL-2017-2\",\n \"name\": \"SkipEmptyStringLiteral\",\n \"summary\": \"If \\\"\\\" is used in a function call, the following function arguments will not be correctly passed to the function.\",\n \"description\": \"If the empty string literal \\\"\\\" is used as an argument in a function call, it is skipped by the encoder. This has the effect that the encoding of all arguments following this is shifted left by 32 bytes and thus the function call data is corrupted.\",\n \"fixed\": \"0.4.12\",\n \"severity\": \"low\"\n },\n {\n \"uid\": \"SOL-2017-1\",\n \"name\": \"ConstantOptimizerSubtraction\",\n \"summary\": \"In some situations, the optimizer replaces certain numbers in the code with routines that compute different numbers.\",\n \"description\": \"The optimizer tries to represent any number in the bytecode by routines that compute them with less gas. For some special numbers, an incorrect routine is generated. This could allow an attacker to e.g. trick victims about a specific amount of ether, or function calls to call different functions (or none at all).\",\n \"link\": \"https://blog.soliditylang.org/2017/05/03/solidity-optimizer-bug/\",\n \"fixed\": \"0.4.11\",\n \"severity\": \"low\",\n \"conditions\": {\n \"optimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2016-11\",\n \"name\": \"IdentityPrecompileReturnIgnored\",\n \"summary\": \"Failure of the identity precompile was ignored.\",\n \"description\": \"Calls to the identity contract, which is used for copying memory, ignored its return value. On the public chain, calls to the identity precompile can be made in a way that they never fail, but this might be different on private chains.\",\n \"severity\": \"low\",\n \"fixed\": \"0.4.7\"\n },\n {\n \"uid\": \"SOL-2016-10\",\n \"name\": \"OptimizerStateKnowledgeNotResetForJumpdest\",\n \"summary\": \"The optimizer did not properly reset its internal state at jump destinations, which could lead to data corruption.\",\n \"description\": \"The optimizer performs symbolic execution at certain stages. At jump destinations, multiple code paths join and thus it has to compute a common state from the incoming edges. Computing this common state was simplified to just use the empty state, but this implementation was not done properly. This bug can cause data corruption.\",\n \"severity\": \"medium\",\n \"introduced\": \"0.4.5\",\n \"fixed\": \"0.4.6\",\n \"conditions\": {\n \"optimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2016-9\",\n \"name\": \"HighOrderByteCleanStorage\",\n \"summary\": \"For short types, the high order bytes were not cleaned properly and could overwrite existing data.\",\n \"description\": \"Types shorter than 32 bytes are packed together into the same 32 byte storage slot, but storage writes always write 32 bytes. For some types, the higher order bytes were not cleaned properly, which made it sometimes possible to overwrite a variable in storage when writing to another one.\",\n \"link\": \"https://blog.soliditylang.org/2016/11/01/security-alert-solidity-variables-can-overwritten-storage/\",\n \"severity\": \"high\",\n \"introduced\": \"0.1.6\",\n \"fixed\": \"0.4.4\"\n },\n {\n \"uid\": \"SOL-2016-8\",\n \"name\": \"OptimizerStaleKnowledgeAboutSHA3\",\n \"summary\": \"The optimizer did not properly reset its knowledge about SHA3 operations resulting in some hashes (also used for storage variable positions) not being calculated correctly.\",\n \"description\": \"The optimizer performs symbolic execution in order to save re-evaluating expressions whose value is already known. This knowledge was not properly reset across control flow paths and thus the optimizer sometimes thought that the result of a SHA3 operation is already present on the stack. This could result in data corruption by accessing the wrong storage slot.\",\n \"severity\": \"medium\",\n \"fixed\": \"0.4.3\",\n \"conditions\": {\n \"optimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2016-7\",\n \"name\": \"LibrariesNotCallableFromPayableFunctions\",\n \"summary\": \"Library functions threw an exception when called from a call that received Ether.\",\n \"description\": \"Library functions are protected against sending them Ether through a call. Since the DELEGATECALL opcode forwards the information about how much Ether was sent with a call, the library function incorrectly assumed that Ether was sent to the library and threw an exception.\",\n \"severity\": \"low\",\n \"introduced\": \"0.4.0\",\n \"fixed\": \"0.4.2\"\n },\n {\n \"uid\": \"SOL-2016-6\",\n \"name\": \"SendFailsForZeroEther\",\n \"summary\": \"The send function did not provide enough gas to the recipient if no Ether was sent with it.\",\n \"description\": \"The recipient of an Ether transfer automatically receives a certain amount of gas from the EVM to handle the transfer. In the case of a zero-transfer, this gas is not provided which causes the recipient to throw an exception.\",\n \"severity\": \"low\",\n \"fixed\": \"0.4.0\"\n },\n {\n \"uid\": \"SOL-2016-5\",\n \"name\": \"DynamicAllocationInfiniteLoop\",\n \"summary\": \"Dynamic allocation of an empty memory array caused an infinite loop and thus an exception.\",\n \"description\": \"Memory arrays can be created provided a length. If this length is zero, code was generated that did not terminate and thus consumed all gas.\",\n \"severity\": \"low\",\n \"fixed\": \"0.3.6\"\n },\n {\n \"uid\": \"SOL-2016-4\",\n \"name\": \"OptimizerClearStateOnCodePathJoin\",\n \"summary\": \"The optimizer did not properly reset its internal state at jump destinations, which could lead to data corruption.\",\n \"description\": \"The optimizer performs symbolic execution at certain stages. At jump destinations, multiple code paths join and thus it has to compute a common state from the incoming edges. Computing this common state was not done correctly. This bug can cause data corruption, but it is probably quite hard to use for targeted attacks.\",\n \"severity\": \"low\",\n \"fixed\": \"0.3.6\",\n \"conditions\": {\n \"optimizer\": true\n }\n },\n {\n \"uid\": \"SOL-2016-3\",\n \"name\": \"CleanBytesHigherOrderBits\",\n \"summary\": \"The higher order bits of short bytesNN types were not cleaned before comparison.\",\n \"description\": \"Two variables of type bytesNN were considered different if their higher order bits, which are not part of the actual value, were different. An attacker might use this to reach seemingly unreachable code paths by providing incorrectly formatted input data.\",\n \"severity\": \"medium/high\",\n \"fixed\": \"0.3.3\"\n },\n {\n \"uid\": \"SOL-2016-2\",\n \"name\": \"ArrayAccessCleanHigherOrderBits\",\n \"summary\": \"Access to array elements for arrays of types with less than 32 bytes did not correctly clean the higher order bits, causing corruption in other array elements.\",\n \"description\": \"Multiple elements of an array of values that are shorter than 17 bytes are packed into the same storage slot. Writing to a single element of such an array did not properly clean the higher order bytes and thus could lead to data corruption.\",\n \"severity\": \"medium/high\",\n \"fixed\": \"0.3.1\"\n },\n {\n \"uid\": \"SOL-2016-1\",\n \"name\": \"AncientCompiler\",\n \"summary\": \"This compiler version is ancient and might contain several undocumented or undiscovered bugs.\",\n \"description\": \"The list of bugs is only kept for compiler versions starting from 0.3.0, so older versions might contain undocumented bugs.\",\n \"severity\": \"high\",\n \"fixed\": \"0.3.0\"\n }\n]","tokens":13045,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266847665,"hash":"6aeeaff04791446d9e12db38110ab3ef39a98659"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/41","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 41 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n vbuterin\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n Load more posts below","tokens":3613,"squid":"ink-research","role":"Deep Scholar","at":1791266849359,"hash":"2eaf6a1990b137769656e531b98249aa112d57a3"}
{"url":"https://www.pyth.network/blog/oracle-integrity-staking-incentivizing-safer-price-feeds-for-a-more-secure-defi","domain":"pyth.network","title":"Oracle Integrity Staking: Incentivizing Safer Price Feeds for a More Secure DeFi - Pyth Network — The Price of Everything","text":"Announcements·Sep 2, 2024Oracle Integrity Staking: Incentivizing Safer Price Feeds for a More Secure DeFiPyth Network boosts DeFi with secure price feeds. New Oracle Integrity Staking enhances reliability for Web3 finance, addressing growing demands.Pyth Network is designed to supercharge DeFi apps and bridge the gap between traditional and on-chain finance. The launch of Pyth Price Feeds in 2021 marked a pivotal step in this mission. As DeFi expands, the needs of builders and users continue to evolve. The demand for heightened security and reliability in Web3 capital markets by smart contract developers and market participants has never been greater.Enter Oracle Integrity Staking—an innovation to Pyth Price Feeds that introduces enhanced data source accountability and creates a more secure DeFi ecosystem through decentralized staking rewards and slashing mechanisms for network participants.Pyth Publishers (data providers) will programmatically earn rewards from the Pyth protocol for maintaining high-fidelity data contributions to the price oracle. If they deliver faulty data that negatively impacts protocols, their stake will be slashed. The Pyth DAO can vote on what to do with this slashed amount, such as distributing it to impacted parties or using the slashed amount for another purpose.PYTH stakers can delegate their stakes to Pyth publishers to enhance those publisher’s potential rewards for providing high quality data. This contribution strengthens the resilience and security of Pyth Price Feeds; in return, PYTH stakers are programmatically rewarded for helping secure the oracle network and protect DeFi.Oracle Integrity Staking covers all 500+ Pyth Price Feeds, setting a higher standard for oracle technology and the way market participants can participate in the DeFi ecosystem. This launch marks a significant milestone in Pyth Network’s mission to deliver reliable, accurate price data to all blockchains while addressing the growing demands of decentralization and sustainability.This blog post will explore how Oracle Integrity Staking empowers developers to build fearlessly thanks to increased data accountability and price feed security.What Oracle Integrity Staking Unlocks for BuildersThe most pressing challenges in the oracle space center around the trustless delivery of high-quality, reliable price data across all of the assets and blockchains required by developers.Currently, the data infrastructure available to developers does not provide thorough accountability measures to ensure data quality. Legacy oracles that do feature on-chain incentives for quality control only offer this for a select few markets which are already safe.Scaling asset coverage also remains a complex challenge for push oracles. While the Pyth pull oracle has established a new paradigm for how to scale price feeds to new chains rapidly, applications using Pyth still stand to benefit from access to new, trending, or strategic yet unpopular assets.Oracle Integrity Staking directly addresses data quality and scalability by holding Pyth publishers economically accountable for price accuracy and asset coverage.Price AccuracyPublishers must stake PYTH tokens to become eligible for on-chain rewards, and will programmatically receive rewards only for contributing high fidelity price data.Conversely, if a publisher provides faulty or malicious data, a portion of that publisher’s stake will be slashed as a penalty. Additionally, the Pyth DAO can vote on what to do with the slashed amount, including delivering some or all of it to those affected by the misprint or using the amount to support Pyth Network in other ways.For developers, these outcomes means greater confidence in the data they rely on, enabling them to build fearlessly without concern over data integrity and security. These assurances are in addition to Pyth Price Feed’s existing reliability practices, including on-chain aggregation to remove outlier data contributions and conformance testing of newly launched feeds.Asset CoverageOracle Integrity Staking also enables publishers to increase their potential rewards by increasing the number of symbols (price feeds) they support. Furthermore, potential rewards will increase if the publisher begins publishing data for less popular symbols, rather than liquid or popular pairs that many other publishers already support.This incentive mechanism positions Pyth to become the go-to oracle for smart contract developers building across a wide range of applications; no matter where a team chooses to build, or what asset types they need data for, Pyth Price Feeds can expand to cover these needs.Protect the DeFi You Know and LoveThe Pyth community also plays a critical role in Oracle Integrity Staking, as now PYTH stakers can get programmatically rewarded for contributing to the security of the oracle network. By delegating stake to a Pyth publisher, stakers reinforce the resilience and accuracy of Pyth Price Feeds by enhancing the potential rewards for that selected publisher. The staking rewards mechanism delivers rewards first to publishers based on data quality, and then to stakers for their contribution to the network.This mechanism gives stakers a unique lever to guide publishers to support more symbols and asset types, in addition to maintaining high standards for price data. It is important to note that Oracle Integrity Staking’s reward and slashing mechanisms affects both publishers and their supporting stakers. Publishers are accountable for the data they provide to the oracle, while stakers help strengthen the oracle by choosing which publishers to support.How Oracle Integrity Staking WorksOracle Integrity Staking allows anyone to help secure Pyth and protect the DeFi ecosystem. The program introduces decentralized staking rewards and slashing mechanisms to incentivize publishers and PYTH holders to stake tokens to reinforce the integrity of the oracle.The Staking Rewards and Slashing ProcessAt the heart of Oracle Integrity Staking are stake pools, with each one corresponding to a different publisher. Each participating publisher can stake PYTH tokens to themselves to become eligible for performance rewards for their published data. PYTH stakers—members of the Pyth community—select the publisher(s) they wish to support and can stake PYTH tokens to any publisher’s pool to help secure the oracle.The total amount of rewards a stake pool generates is determined by the total number of tokens staked in the pool (by both the publisher and stakers). The reward amount increases with the size of the total stake, up to a limit called the stake cap. Publishers can raise their stake cap by supporting more symbols. In turn, stakers can incentivize publishers to support more symbols by choosing to stake with publishers that support symbols that are important to the ecosystem. Rewards are programmatically distributed between publishers and stakers, with rewards first going to publishers, and remaining rewards going to stakers.The Pyth DAO sets a maximum annual reward rate for stake pools to balance between sustainability and meaningful participation. This rate is currently 10%, and can be adjusted by the Pyth DAO. The maximum reward rate is achieved when the total stake in the pool is below the stake cap. However the total amount of rewards can never exceed the maximum reward rate times the stake cap; this means that if the stake cap is exceeded, stakers will receive a lower reward rate. This arrangement incentivizes stakers to evaluate the full list of publishers in the network when deciding on who to stake towards to help secure the oracle. Learn more about how rewards are calculated in the documentation.In summary, Oracle Integrity Staking rewards for strengthening oracle integrity are determined by several key factors—which can be adjusted by the Pyth DAO:Stake Cap: This is the maximum amount of tokens that can be staked with a publisher (by the publisher themselves and additional stakers) that can be eligible for rewards. A higher stake cap allows a publisher to attract more stakers and increase the pool’s notional reward.Number of Symbols Supported by a Publisher: Publishers can support more symbols to increase their stake cap for higher potential rewards. These additional rewards compensate for the increased risk of slashing from covering more symbols.Maximum Reward Rate: The DAO sets a cap on the maximum reward rate, calculated as an annual percentage yield (APY), that can be earned in a stake pool. While a higher maximum reward rate can increase the overall yield potential for participants, the DAO should carefully manage this parameter to maintain the balance between incentivizing participation and ensuring the long-term sustainability of Oracle Integrity Staking and Pyth Network.Delegation Fee: Publishers charge a fixed percentage (currently 20%) of the rewards from stakers in their stake pool as a delegation fee, net of any slashed amount. The DAO can vote to adjust this fee amount and structure.Slashing: In the event that data from a set of publishers fails to meet standards, both the publisher(s) and stakers supporting them can face slashing penalties. This shared responsibility model encourages careful evaluation of publishers, promoting a culture of accountability throughout the network. Currently, the slashing mechanism is capped at 5% of the total stake, and this rate can be adjusted by the Pyth DAO. The DAO can also vote on how to use any slashed amounts, including whether the slashed tokens will be delivered to those impacted by the error or used to support Pyth Network in another way.How Stakers Can Get InvolvedPYTH stakers play a crucial role in Oracle Integrity Staking by staking their tokens to publishers to strengthen the oracle’s security and data integrity.To get started, anyone holding unlocked PYTH tokens can access an interface like the Pyth Staking Dashboard and navigate to the Oracle Integrity Staking program. Eligible participants* can begin exploring the list of publishers and selecting which ones to stake towards in order to help secure the oracle.Stakers can sort and evaluate the list of publishers based on pool composition, publisher quality rankings, the number of price feeds the publisher supports, or whatever criteria is most important to them. When ready, stakers can stake to any publisher stake pool. These tokens enter a Warmup Period before they become officially staked and actively help secure the oracle. Stakers can then manage their stake allocations across the publishers depending on their preference and strategy for maintaining the oracle network’s integrity.PYTH holders who have previously staked their tokens to Pyth Governance will see these same tokens in the Oracle Integrity Staking program, and can start staking them directly to publishers without withdrawing first to their wallets.Finally, participants can stake the same tokens to both the Oracle Integrity Staking program and the Pyth Governance program to simultaneously secure the oracle and obtain voting power for Pyth Improvement Proposals. Participants can also choose to stake only to Pyth Governance and not Oracle Integrity Staking.The Role of the Pyth DAOThe Pyth DAO determines the parameters that govern Oracle Integrity Staking, such as stake caps inputs, delegation fees, slashing amounts, and more. These parameters ensure incentives align with maintaining high data standards. Current parameters settings can be found in the documentation.The Pyth DAO is also responsible for overseeing critical updates to the staking and slashing mechanisms, such as deciding the source of rewards for publishers and stakers. To bootstrap this initiative, Pyth Data Association has allocated 100M unlocked tokens. The Pyth DAO can vote on additional reward sources, such as on-chain revenue generated by the Pyth oracleThe Pyth DAO can also vote on how to handle any slashed amounts from faulty publishers. While slashed tokens programmatically return to the DAO treasury, the Pyth DAO can vote, for example, to deliver slashed amounts to any parties affected by a misprint or use the funds for any other purpose permitted by the DAO’s governance.Additionally, the DAO can change the reward structure, such as incorporating other digital assets in the reward set to allow for broader staking participation to further enhance the oracle’s security and reach.Through these responsibilities, the Pyth DAO empowers the community to shape the future of Oracle Integrity Staking, ensuring the ongoing resilience and scalability of the Pyth Network.Price Feeds V3 and BeyondIn decentralized finance, the reliability and accuracy of oracle feeds are paramount. As more value flows through blockchain ecosystems, the risks of inaccurate or manipulated data grow.While Pyth Price Feed’s current reliability practices have been critical for upholding today’s DeFi, the ever-evolving DeFi landscape necessitates more advanced security mechanisms. Cryptoeconomic security was the logical next step for Price Feeds.Pyth Network first launched on Solana with Price Feeds V1, pioneering high-frequency on-chain data from first-party sources. Leveraging Solana's speed, Pyth set a new standard for reliable data delivery. With Price Feeds V2, Pyth became the first pull oracle, expanding its reach across multiple blockchains in the EVM, Move, Cosmos, and Bitcoin ecosystems, giving developers access to high-fidelity, low-latency prices on any chain.Oracle Integrity Staking unlocks Price Feeds V3—a significant advancement for Pyth Price Feeds that introduces enhanced data source accountability to every feed. The key component of Price Feeds V3 is the establishment of Oracle Integrity Staking to empower Web3 developers to build fearlessly without worrying about inaccurate or malicious data.Oracle Integrity Staking introduces a new paradigm in the oracle space—one that actively prioritizes data source accountability and protection across the entire oracle’s data feeds offering, setting a higher industry standard for price oracles.To date, Pyth Network is the only data infrastructure solution offering this level of data accountability and security across every one of its live feeds, from its most commonly used price feeds to low liquidity, long-tailed assets. Oracle Integrity Staking ensures that every price feed is secure, every user is protected, and every publisher is accountable.Pyth Network is redefining the future of DeFi. Join us on this transformative journey and be a part of shaping history, no matter which ecosystem you hail from or how you choose to contribute.We want to hear your feedback. Join the Pyth Discord and Telegram, and follow Pyth on X and LinkedIn. You can also learn more about Pyth here.*DISCLAIMER: THE SERVICES WERE NOT DEVELOPED FOR, AND ARE NOT AVAILABLE TO PERSONS OR ENTITIES WHO RESIDE IN, ARE LOCATED IN, ARE INCORPORATED IN, OR HAVE A REGISTERED OFFICE OR PRINCIPAL PLACE OF BUSINESS IN THE UNITED STATES OF AMERICA, THE UNITED KINGDOM OR CANADA (COLLECTIVELY, “BLOCKED PERSONS”).MOREOVER, THE SERVICES ARE NOT OFFERED TO PERSONS OR ENTITIES WHO RESIDE IN, ARE CITIZENS OF, ARE LOCATED IN, ARE INCORPORATED IN, OR HAVE A REGISTERED OFFICE OR PRINCIPAL PLACE OF BUSINESS IN ANY RESTRICTED JURISDICTION OR COUNTRY SUBJECT TO ANY SANCTIONS OR RESTRICTIONS PURSUANT TO ANY APPLICABLE LAW, INCLUDING THE CRIMEA REGION, CUBA, IRAN, NORTH KOREA, SYRIA, MYANMAR (BURMA, DONETSK, LUHANSK, OR ANY OTHER COUNTRY TO WHICH THE UNITED STATES, THE UNITED KINGDOM, THE EUROPEAN UNION OR ANY OTHER JURISDICTIONS EMBARGOES GOODS OR IMPOSES SIMILAR SANCTIONS, INCLUDING THOSE LISTED ON OUR SERVICES (COLLECTIVELY, THE “RESTRICTED JURISDICTIONS” AND EACH A “RESTRICTED JURISDICTION”) OR ANY PERSON OWNED, CONTROLLED, LOCATED IN OR ORGANIZED UNDER THE LAWS OF ANY JURISDICTION UNDER EMBARGO OR CONNECTED OR AFFILIATED WITH ANY SUCH PERSON (COLLECTIVELY, “RESTRICTED PERSONS”).THE WEBSITE WAS NOT SPECIFICALLY DEVELOPED FOR, AND IS NOT AIMED AT OR BEING ACTIVELY MARKETED TO, PERSONS OR ENTITIES WHO RESIDE IN, ARE LOCATED IN, ARE INCORPORATED IN, OR HAVE A REGISTERED OFFICE OR PRINCIPAL PLACE OF BUSINESS IN THE EUROPEAN UNION. THERE ARE NO EXCEPTIONS. IF YOU ARE A BLOCKED PERSON OR A RESTRICTED PERSON, THEN DO NOT USE OR ATTEMPT TO USE THE SERVICES. USE OF ANY TECHNOLOGY OR MECHANISM, SUCH AS A VIRTUAL PRIVATE NETWORK (“VPN”) TO CIRCUMVENT THE RESTRICTIONS SET FORTH HEREIN IS PROHIBITED.Pyth Network is designed to supercharge DeFi apps and bridge the gap between traditional and on-chain finance. The launch of Pyth Price Feeds in 2021 marked a pivotal step in this mission. As DeFi expands, the needs of builders and users continue to evolve. The demand for heightened security and reliability in Web3 capital markets by smart contract developers and market participants has never been greater.Enter Oracle Integrity Staking—an innovation to Pyth Price Feeds that introduces enhancedRead nextView allPyth September 2026 ReportPyth September 2026 ReportBuilding Market Data for a Machine-Readable Financial System Building Market Data for a Machine-Readable Financial System Lighter Explores Pyth Indices as It Expands Perpetual Markets Beyond CryptoLighter Explores Pyth Indices as It Expands Perpetual Markets Beyond CryptoThe Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":4516,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266860810,"hash":"4db6ed39b898a6e1340702effdf9e499ec0d369d"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/43","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 43 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n post by denett on Feb 2, 2018\n\n denett\n\nThe plasma chain will not be insolvent, because Bob will lose its coins. The operator will not accept Bobs transaction because the coins have left the chain. He could try to exit but his exit will be challenged.\nI don’t know if we can use the challengeExit function in this case or that we need an extra function in the contract to challenge an exit with proof that the transaction it depends on has already exited.\n\n post by kz on Feb 2, 2018\n\n kz\n\nWhat if Bob, Alice and chain operator are a single entity ? Chain operator deposits 1ETH and gets 2ETH out .\nAlice (operator) first exits the chain while Bob doesn’t challenge her.\nAfter that Bob (operator) exits the chain by using Alice’s commitment.\nNobody else can challenge Alice’s (operator) and Bob’s (operator) exit.\nAfter exit is made there is no persistent record of exit being made on eth chain. One could find out about Alice’s exit only by replaying ETH chain history. If commitments aren’t on chain new user accessing the chain can’t figure out based on UTXO status is and ETH chain contract state is chain solvent or not.\n\n post by denett on Feb 2, 2018\n\n denett\n\nAlice’s exit is public, so all Plasma followers know she exited. Bobs exit can be challenged by anyone using a proof of Alice’s exit.\n\nYou are correct, one can only validate the state of the Plasma chain by replaying all actions on the Plasma chain since inception.\n\n post by kz on Feb 3, 2018\n\n kz\n\n Hi @denett,\nthanks on your help with all of this. Really appreciate it.\n\nCould you please explain how would this work in case of minimal viable plasma? I understand that in general plasma system that could be the case, but I can’t figure out how does this work for minimal viable plasma.\nAs far as I can tell there is only one method to challengeExit.\n\nAfter Alice’s (operator’s) exit is made. That part is done. Alice has successfully withdrawn from plasma chain.\nLet us assume some UTXOs where made after this.\nSo then comes Bob (again the malicious operator). He starts his exit since he has Alice’s (his) confirmation. Nobody can challenge Bob’s (operator’s) exit since it wasn’t spend.\n@denett Could you please help me to understand this?\n\n post by denett on Feb 3, 2018\n\n denett\n\n As I said here:\n\nTo proof two exits are conflicting, you only have to provide the two exitId that are conflicting and I guess the content of those 2 exits. I assume the contract only stores the exitsId and that the exitId is a hash of the parameters used for the startExit function.\nI think that if all information regarding the exits are stored in the contract, nobody has to challenge Bobs exit, because the contract can reject it by itself.\n\n Load more posts below","tokens":3655,"squid":"ink-research","role":"Deep Scholar","at":1791266860891,"hash":"afb205659ca41c322c8088914bd73cfefb9d3c45"}
{"url":"https://pyth.network/blog/reliability-efforts-at-pyth?ref=pyth-network.ghost.io","domain":"pyth.network","title":"Reliability and Security for Market Data Oracles - Pyth Network — The Price of Everything","text":"Research·Apr 26, 2022Reliability and Security for Market Data OraclesOracle reliability is critical for DeFi. Inaccurate data can lead to massive financial losses and protocol failures. Developers must prioritize this.Oracles need to be highly reliable since inaccurate prices or service outages can cause financial losses for downstream users. For example, a lending protocol that receives an inaccurate oracle price could incorrectly liquidate its users. As an oracle secures more value, the consequences of failure become more serious. Even small failure probabilities become unacceptable.Surprisingly, we don’t hear a lot of conversation in the developer community about reliability. There is a perception in the market that all oracles are equal: every price feed is perfect and will always publish the correct price. The connotation of the word “oracle” doesn’t help — it sounds like an infallible authority that always speaks the truth. This perception, however, is not true. It is hard to build a highly reliable system! Even large software companies have service outages, and traditional financial market participants spend considerable effort cleaning up inaccurate data feeds. Reliability is essential and takes hard work.Oracles themselves must be responsible for reliability. Protocol developers shouldn’t be forced to deal with the consequences of oracle failures. Furthermore, any downstream safeguards that protocols implement are necessarily imprecise — for example, a protocol could check that the oracle price has not moved too much to filter out potential bad prices, but this will cause the protocol to miss sudden price moves. Oracles are much better suited to handle these problems internally. This approach also presents a friendly UX to developers, who no longer have to think about the consequences of oracle failures.At Pyth, we have a threefold approach to reliability. Our aggregate confidence interval informs price feed consumers when there is substantial uncertainty around the aggregate price. Separately, our backup plan for reliability has always been to provide protocol developers with economic recourse if the oracle fails; the Pyth Network whitepaper proposes a mechanism for this purpose. While we think these measures constitute a solid failsafe plan, it is much better to prevent failures from occurring in the first place. Thus, our first line of defense is to build mechanisms and assemble data sources so that our price feeds are inherently reliable.This post details some of the thinking we have been doing on reliability. We wanted to precisely define reliability, then leverage that understanding to build reliability into our price feeds. We decided to probabilistically model the mechanism behind Pyth’s price feeds, so that we could subsequently quantify and optimize for reliability. This post explains some of the thinking we’ve been doing on this front.What is Reliability?Reliability is shorthand for availability and accuracy:Availability is the percent of time that the oracle is publishing a price.Accuracy is the percent of time that the oracle price is in line with the broader market price.Oracles need to be available and accurate to different degrees. Accuracy is all-important: publishing even a single inaccurate price could trigger liquidations and losses. Thus, the probability of publishing an inaccurate price must be vanishingly small. Availability is also important, but we can tolerate the oracle being offline more than the oracle being incorrect — it’s better for an oracle to be uncertain than it is for an oracle to be confident and wrong. However, limited availability is also dangerous, as a lack of availability could prevent downstream protocols from performing liquidations or other time-sensitive actions, which in turn could cause losses for users.We want to quantify reliability, so we need to quantify availability and accuracy. To do this, we can think probabilistically and consider the probability of a feed being online and accurate as the standard metric for reliability.A Baseline Model for Price Feed ReliabilityIt turns out there’s a simple way to think about reliability if we’re willing to make some assumptions. Pyth aggregates the reports of many different publishers to produce a single aggregated value. The individual publishers are assumed to be fallible, meaning they occasionally publish inaccurate prices or fail to publish a price. The oracle aggregates multiple reports in order to construct a more reliable feed from less reliable sources. The aggregation is designed to be robust, such that some number of publishers can be offline or inaccurate without causing a problem in the aggregate value. Pyth price feeds are available, as long as at least 3 publishers are currently online, and accurate, as long as a majority of online publishers are accurate.If we assume that the publishers are independent, we can straightforwardly compute the probability that the aggregate value is offline or incorrect. To illustrate, consider a price feed that has 3 publishers, where each publisher has a 99% availability rate and 99.9% accuracy rate when it publishes. All 3 publishers must be online for the aggregate to be online; we can calculate the probability of this event as:which implies a 2.97% offline rate. If the feed is online, then at least 2 of the 3 publishers must be accurate for the aggregate to be accurate. We can compute the probability of this event as follows:which implies a 0.0039% error rate.The Danger of Correlated ErrorsA problem with this analysis is that publishers could have correlated failure modes. The simple analysis ignores these correlations, which can cause it to dramatically overestimate the reliability of a feed. To illustrate this effect, suppose we introduce some more complex dependencies into the simple model from above. In particular, let us tie the first two publishers together such that their availability and accuracy statuses are exactly equal (e.g., they are running on the same infrastructure and using the same algorithm to publish prices). Then, we can compute the probability of the aggregate being online as follows:which implies a 1.99% offline rate. The probability of the aggregate being online and accurate becomes:because the aggregate being accurate when all three publishers are online is equivalent to the event that the two correlated publishers are accurate. This implies a 0.098% error rate. The simple analysis from above dramatically underestimates the failure probability of the overall price feed!Modeling Correlations Between PublishersWe wanted to model the reliability of Pyth price feeds in a way that accurately accounted for correlations between publishers. Furthermore, we wanted to capture Pyth’s unique way of providing aggregate estimates through both an aggregate price and a confidence interval.One way to build this model is to directly represent the process whereby prices appear on-chain. The typical publisher reads price feeds from several exchanges, aggregates those feeds into a price estimate, then submits their estimate in a transaction to the on-chain program. This entire process is implemented in a long-running software program that is continuously reading data and pushing updates. There are several places in this flow where problems could arise:The underlying price feeds could be inaccurate. This error could simultaneously affect all of the publishers reading from the inaccurate price feed.The publisher’s software for processing the feeds could have a bug, causing them to report an inaccurate price.The publisher’s infrastructure could fail, causing them to be unable to submit their transaction. In the simplest case, the publisher’s software program can crash, or their hosting infrastructure could have an outage.Such transaction confirmation failures could also occur due to Solana network congestion, RPC node outages, or issues with the publisher’s own hosting. Note that many of these failure modes will simultaneously affect multiple publishers.Our goal is to estimate the probability that these failures affect Pyth’s aggregate price and confidence interval. Each of these failure modes has some probability of occurring, which we can estimate from historical data. The aggregate price and confidence interval are a combination of multiple publishers’ prices, so we need a way to combine the probabilities of individual failure modes. One way to do that is to use a Bayesian network, which is a tool for representing probability distributions in terms of a number of smaller component distributions. We constructed the following Bayesian network to represent our problem:A Bayesian network represents a probability distribution over a set of variables. Each circle in the diagram above represents a variable, and the edges represent dependencies between variables. Every variable can take on one of several values; for example, the aggregate can either be ACCURATE, INACCURATE, or OFFLINE. The Bayesian network determines the probability of each such value. See these notes for a primer on Bayesian networks.Our Bayesian network assumes that there is a collection of N publishers and M exchanges. The network contains multiple variables per publisher and exchange; the publishers’ variables are indexed by i, and the exchanges’ variables are indexed by j. The network above encodes a probability distribution over the following variables:mⱼ represents a data feed from exchange j. This variable has 2 possible values, either ACCURATE or INACCURATE, representing whether the exchange’s price is currently accurate or not.Bᵢ represents whether publisher i is encountering a software bug. This variable has 2 possible values, either BUG or NO_BUG. When this variable’s value is BUG, the publisher will report an inaccurate price to the on-chain program.Z_Gᵢ represents whether publisher i’s infrastructure is online. This variable has 2 possible values, either ONLINE or OFFLINE. We grouped publishers together to represent the fact that multiple publishers share infrastructure; the Gᵢ variable represents the group that the ith publisher is in. Thus, all of the publishers in the same group go offline together.μᵢ represents the price publisher i submits to the on-chain program. This variable can take on 3 values: ACCURATE, INACCURATE, or OFFLINE. This variable depends on the exchanges that the publisher sources their data from (the edges from the mⱼ variables), and also the publisher’s software bug status (the edge from the Bᵢ variable), and the publisher’s online status (the edge from the Z_Gᵢ variable). For example, if the publisher’s infrastructure is offline Z_Gᵢ = OFFLINE), then the publisher’s price is also OFFLINE.Aggregate represents the aggregate price. This variable can take on 3 values: ACCURATE, INACCURATE, or OFFLINE. This variable depends on all of the publishers’ prices (the edges from the μᵢ variables). Its value is determined by encoding the on-chain program’s aggregation logic as a probability distribution. Specifically, it is OFFLINE unless 3 or more publishers are reporting prices. It is INACCURATE if ≥ 50% of online publishers are INACCURATE. Otherwise, it is ACCURATE. The percentage thresholds used in this distribution are properties of Pyth’s aggregation logic.This model allows us to set the probabilities of the failure modes listed above, then combine those probabilities to determine whether Aggregate = ACCURATE. This process uses an algorithm called belief propagation. Belief propagation is a well-studied approach to efficiently compute probabilities in a Bayesian network. For more details on belief propagation, see these notes and this helpful video primer.Using the Bayesian Network to Determine Feed ReliabilityOne use case for this Bayesian network is to estimate the reliability of Pyth’s price feeds. We want to know the probability that a data feed prints an inaccurate price or goes offline. We can determine this probability by estimating the probabilities of each failure mode above using historical data, then combining them with the Bayesian network above.We used an archive of historical Pyth data to estimate the probability of each failure mode. This archive records all of the data stored in the on-chain program at every Solana slot, including every publisher’s status (i.e., are they online?), their price and confidence, and the aggregate price and confidence. We computed the following quantities from the archive:The probability that the different exchanges (the mⱼs) are inaccurate. We actually do this by abstracting away the individual exchanges, assuming that each publisher represents a single data source, and then using the empirical probability that the publisher’s price is more than 10% away from the aggregate price.* This is because there is no way for us to know exactly how each publisher produces its price.The probability of a software bug occurring at each publisher Bᵢ. We calculate this probability by looking for extreme anomalies in the historical price series, such as a price of 0 or a price that is an order of magnitude away from the aggregate. Such anomalies are typically a result of a bug in the publisher’s software.Which publishers are in each shared infrastructure group Gᵢ. We form the groups by calculating the pairwise correlation between the availability of each publisher and including any two publishers in the same group if their pairwise correlation is greater than some threshold, say 0.2.The probability that each infrastructure group goes offline Z_Gᵢ. We set this probability conservatively to the highest offline rate of all publishers in that infrastructure group.Once we have these probabilities, we can simply run belief propagation to obtain probability estimates for the different possible values of Aggregate.Sample ResultsAs an example application of this model, we used it to analyze the reliability of the ONE/USD price feed. In mid-February, ONE/USD had 3 publishers in testnet. These publishers had the following availability:Publisher 1: 22.1%Publisher 2: 99.9%Publisher 3: 21.84%The baseline model predicted the following probability of the aggregate being online:However, the actual online rate empirically observed at that time was 21.81%, due to the fact that the first and third publishers’ availabilities were almost perfectly positively correlated. When we run inference for the Bayesian network on this empirical data, we obtain the following predictions:P(Aggregate = INACCURATE ) = 0.007%P(Aggregate = OFFLINE) = 78.20%P(Aggregate = ACCURATE) = 21.80%These predictions are closer to the empirically observed rate. The Bayesian network’s predictions are better than those of the simple baseline model because it models the correlated failure modes across publishers. Note that the model is valuable even though we can directly compute the offline probability from the historical data set. The probability of an inaccurate price is so low that we would need a massive sample size of data to trust the empirically-estimated probability. The model allows us to extrapolate this error rate from a smaller data sample.What Do We Do With These Results?We are now using this Bayesian network to systematically assess the reliability of the products listed on Pyth. This model allows us to answer two important questions:Which Products Are Ready for Mainnet?We typically add new products to testnet and then move them into mainnet once enough publishers are quoting them. We now incorporate explicit availability and accuracy thresholds into this process: every new product must be offline < 1% of the time, and the probability of publishing an inaccurate aggregate must be < 0.001%. (In practice, achieving < 1% offline is the main challenge. The probability of an inaccurate price or confidence is typically orders of magnitude below 0.001%.)For example, in the case of ONE, the mid-February results clearly did not meet these thresholds. We, therefore, sought out additional publishers. By mid-March, we had 6 publishers quoting ONE/USD. Running the model again produced the following results:P(Aggregate = INACCURATE) = 0.000013%P(Aggregate = OFFLINE) = 0.78%P(Aggregate = ACCURATE) = 99.22%At this point, the feed met our accuracy and availability criteria, so we added it to mainnet.Which Products Need Improvement?One of our major efforts at the moment is to improve the reliability of all existing products in mainnet. This process requires us to recruit publishers who have prices for these products; recruiting publishers can be time-consuming. The model allows us to rank-order the existing products, and thereby focus our recruitment efforts where they are most impactful.Pyth Network’s contributing developers are committed to building highly reliable data feeds. We recognize that DeFi applications depend on reliable oracles, and oracle failures can cause severe financial losses. This post details some of the work we’ve been doing to measure and improve the reliability of Pyth’s price feeds. We hope that this work conveys our commitment to being the most reliable oracle in DeFi.Please reach out to us with any questions, comments, concerns, or suggestions you may have on Twitter at @anihamde and @jayantkrish.* The astute reader may notice that we don’t seem to account for the error rates of the individual exchanges. Instead, in this parameterization of the network, we abstract away the individual exchanges and assign each publisher its own unique data feed. We then assign a correlation between any two publishers’ data feeds according to the observed correlation of error in our data. This in practice encodes the potential for correlation in publisher accuracy, without requiring granular data at the exchange level.We can’t wait to hear what you think! You can join the Pyth Discord and Telegram, and follow us on Twitter. You can also learn more about Pyth here.Oracles need to be highly reliable since inaccurate prices or service outages can cause financial losses for downstream users. For example, a lending protocol that receives an inaccurate oracle price could incorrectly liquidate its users. As an oracle secures more value, the consequences of failure become more serious. Even small failure probabilities become unacceptable.Surprisingly, we don’t hear a lot of conversation in the developer community about reliability. There is a perception in theRead nextView allPyth September 2026 ReportPyth September 2026 ReportBuilding Market Data for a Machine-Readable Financial System Building Market Data for a Machine-Readable Financial System Lighter Explores Pyth Indices as It Expands Perpetual Markets Beyond CryptoLighter Explores Pyth Indices as It Expands Perpetual Markets Beyond CryptoThe Price of EverythingSubscribe for weekly updates on the markets, data, and infrastructure shaping internet-native finance.ProductsPrice FeedsPyth ProPyth IndicesData MarketplacePricingPartnersPublishersUsersSuccess StoriesSolutionsFinancial InstitutionsPrediction MarketsCryptoAIEcosystemPyth TerminalStakingNetwork KPIsDAO ForumDevelopersDocumentationAPI ReferenceTutorialsResourcesBlogNewsroomPodcastsEventsAboutLegalPrivacy PolicyTerms of Use © 2026 Pyth Data AssociationWhere indicated, certain buttons or links on this website may direct you to third-party services. Any such services are provided by the relevant third party, not by Pyth Data Association, and are not intended for consumers. Separate terms and conditions apply.","tokens":4878,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266884224,"hash":"af35316d9cf513da26e7f97cbc605624cf4c98e6"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/38","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 38 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\n kladkogex\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\n\nThe confirm message isn’t about “proving anything”, it’s more about “finalizing” the transfer. Bob needs that confirm message in order to either exit with the UTXO, or pay those coins on to anyone else.\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice sends the confirm message to Bob. This can be a private message via mail for example. If Alice tries to exit, Bob can use this confirm message to challenge her exit. Bob also needs this message to use the funds in his next transaction. After Bob’s transaction, the message is included in the plasma chain and is public. Now everybody watching the plasma chain can challenge Alice when she tries to exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Thnx for the info.\n\nAccording to @vbuterin\n\nIt seems to me that signatures inside the transaction:\nsig1\nsig2\n!=\ncommitment1\ncommitment2\nsigs are used to prove that Alice owns the outputs so plasma chain operator could include the transaction. For the transaction to be finalized, Bob needs to add additional commitments Alice has send to Bob off chain inside his spent transactions to prove transaction was finalized properly by Alice?\nAre those commitments fields missing from the transaction format documentation or did I again misunderstand something?\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\n If A sends a coin to B, then the commitment is separate from the signature and the transaction. If B later sends that coin to C, then B does need to include A’s commitment into the TX; this part was omitted from the earlier description.\n\n A DEX on Plasma\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Vitalik, please correct me if I’m wrong, but it’s more a responsibility of the Plasma operator(s) to not to allow B to send non-owned funds (there should exist a proper mechanism in a smart-contract on a main chain to proof the opposite and start mass exit), so B’s transaction doesn’t need to include A’s commitment - either a full transaction from A is included in block, seen by everyone and than B can try (here we should be careful about censorship) to spend it or A should withdraw since (censorship again) his transaction was never included in Plasma block. In the latter case A’s first withdraw attempt can be prevented by Plasma operator by finally including a transaction in block, although his trust in Plasma operator is lost and he will withdraw.\nOtherwise I see few options for such commitment\n\nreplacement of the tuple blknum, txindex, oindex in a transaction A -> B with\n\nfull transaction that produced an UTXO that A is spending\nMerkle proof that transaction that A is spending was indeed included in block number blknum at index txindex.\nOther required parameters such a signature from A\nSuch approach is completely stateless but increases a size of transaction. Although it doesn’t solve an issue of double-spend.\n\nwe should develop some kind of mechanism for a user A who has an access to the full Plasma and main Ethereum network to produce some kind of proof that\n\ntransaction is included in Plasma block\nPlasma block is included in the main chain\nso the user B can believe A even without access to the Plasma and Ethereum at that moment (otherwise B can get everything he needs from the Plasma and Ethereum). Than B can keep this proof and provide it when necessary. That requires B to have access to some storage capacity and also doesn’t solve the problem of double-spending.\n\nIt’s also a little bit not clear in MVP what field signature should cover. May be it just have a form\n[blknum1, txindex1, oindex1, # Input 1\nblknum2, txindex2, oindex2, # Input 2\nnewowner1, denom1, # Output 1\nnewowner2, denom2, # Output 2\nfee, signature]\nSuch transaction implies that:\n\nentity who is signing claims to have ownership of inputs 1 and 2\nagrees with new owners and denominations.\n\nMay be such transaction as it is can be a proper commitment.\nP. S. I hope that my reply didn’t bother you too much, Happy Birthday!\n\n post by shamatar on Jan 31, 2018\n\n shamatar\n\n Bankex’s version of Plasma. Smart contract is already there (yet still not final) and transaction structure descriptions will be included in the next few days.\n\n post by vbuterin on Jan 31, 2018\n\n vbuterin\n\nAh, but how does the Plasma operator know that B owns the funds? The operator needs to see A’s commitment. Hence, why not just delay this until the moment when A actually needs to use the funds, and save complexity by sticking it into the transaction body?\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nI see you have reasons to require a “two-stage” transaction procedure with extra commitment from A that “A have seen his transaction included in Plasma block, in Ethereum main chain and agrees on it” and from B “I’ve seen a transaction included in block, block was valid and I accept it”. This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details? I present my reasoning below why such procedure is a little excessive.\nI’ve always viewed the following transaction from A->B as a commitment from A, enough information for plasma operator and enough information for B:\n[blknum1, txindex1, oindex1, # Input 1 owned by A\nblknum2, txindex2, oindex2, # Input 2 owned by A\nnewowner1, denom1, # Output 1 to B\nnewowner2, denom2, # Output 2 change to A\nfee, signatureOfA]\nI’m using a modified form here because the one in the specs post doesn’t clearly show if outputs are covered by signatures and can’t be modified by a Plasma operator\nThis ways A claims to own two inputs (and Plasma operator can check it using the full chain index) and it’s his commitment to send funds to B as Output1 is covered by A’s signature. Plasma operator has enough information to know how to redistribute coins from outputs and lifts the complexity from A and B shoulders by maintaining full chain and index (operator receives some fee after all). Operator has to maintain his full index to prevent double spends anyway.\nIf the block (number N) where A to B transaction is included happens to be “faulty”, than contract on a main chain will count the block N-1 as the last valid, so A and B must exit and transaction between them “never happened” from the view of the parent smart contract. Since A and B must validate blocks and wait for the inclusion of the header to the main chain, they already manage their risks this way. If B sees an invalid block he should anyway treat a payment as not completed. The complication can be if A sends funds to some address C that doesn’t have a key (so, it’s an address of the contract) - in this case the two-stage time-limited transaction with “pending” state and acceptance from receiver is the only solution.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\nNot the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.\n\n post by shamatar on Feb 1, 2018\n\n shamatar\n\n Hello Vitalik.\nThank you for clarification about state channels and a hub, although my question was why is it necessary for B to “accept” a transfer at the first place? I’ve tried to make few examples how it can work without any actions from B and this is how it works in our current internal beta.\nSincerely, Alexander\n\n post by vbuterin on Feb 1, 2018\n\n vbuterin\n\n Oh, you can do without the accepting part essentially by delaying the acceptance until the time that you actually need the state change to go through (eg. in the currency case, when you need to pass along the funds). The UTXO model basically implicitly does this.\n\n post by kz on Feb 1, 2018\n\n kz\n\nThnx for the reponse. I think I now understand.\nI have the following suggestion:\nAfter Alice’s transaction to Bob was included in plasma, send Alice’s commitment to both Plasma chain operator (to be included in plasma chain) and Bob instead of relying solely on Bob.\nRationale:\n\nonly the actor that holds that commitment can challenge exit, if only Bob has that commitment and if he fails to submit the commitment on time (which is valid behavior from POW of all of the other actors), then one is risking insolvency of the entire plasma chain.\nkeeping commitment public doesn’t create any security risk, quite the opposite, it enables any plasma user that observes the plasma chain to prevent fraud.\nin case only Bob has access to the commitment, and if he looses it for any reason, he won’t be able to withdraw funds. If the commitment is in the plasma blockchain, he could still be a victim of block witholding attack, but the chances of him getting his money are significantly better since plasma chain operator doesn’t know Bob lost his commitment.\nusers are used to backing up only their private keys and it’s probably not clear to a lot of people that if they lose additional part of state, that they’ve effectively lost their funds forever. This suggestion doesn’t solve that problem, but it could at least reduce the chances of losing their funds.\n\n Load more posts below","tokens":3965,"squid":"ink-research","role":"Deep Scholar","at":1791266884308,"hash":"3b88069e581171a3d0a8bc035c713879b5ea5d74"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/resources.html","domain":"docs.soliditylang.org","title":"Resources — Solidity 0.8.31-develop documentation","text":"Resources\n\n Edit on GitHub\n\nResources\n\nGeneral Resources\n\nEthereum.org Developers page\nEthereum StackExchange\nSolidity website\nSolidity changelog\nSolidity codebase on GitHub\nSolidity language users chat\nSolidity compiler developers chat\nawesome-solidity\nSolidity by Example\nSolidity documentation community translations\nSolidity and Smart Contract Glossary\n\nIntegrated (Ethereum) Development Environments\n\nApeA Python-based web3 development tool for compiling, testing, and interacting with smart contracts.\n\nBrownieA Python-based development and testing framework for smart contracts targeting the Ethereum Virtual Machine.\n💡 Note: As per the official docs, Brownie is no longer actively maintained.\nFuture releases may come sporadically - or never at all.\nCheck out Ape Framework (first in list) for all your python Ethereum development needs.\n\nDappTool for building, testing and deploying smart contracts from the command-line.\n\nFoundryFast, portable and modular toolkit for Ethereum application development written in Rust.\n\nHardhatEthereum development environment with local Ethereum network, debugging features and plugin ecosystem.\n\nRemixBrowser-based IDE with integrated compiler and Solidity runtime environment without server-side components.\n\nTruffleEthereum development framework.\n💡 Note: Consensys announced the sunset of Truffle on September 21, 2023.\nCurrent users may check out the migration path and available product support here.\n\nEditor Integrations\n\nEmacs\n\nEmacs SolidityPlugin for the Emacs editor providing syntax highlighting and compilation error reporting.\n\nIntelliJ\n\nIntelliJ IDEA pluginSolidity plugin for IntelliJ IDEA (and all other JetBrains IDEs).\n\nSublime Text\n\nPackage for SublimeText - Solidity language syntaxSolidity syntax highlighting for SublimeText editor.\n\nVim\n\nVim Solidity by ThesisSyntax highlighting for Solidity in Vim.\n\nVim Solidity by TovarishFinVim syntax file for Solidity.\n\nVim SyntasticPlugin for the Vim editor providing compile checking.\n\nVisual Studio Code (VS Code)\n\nEthereum Remix Visual Studio Code extensionEthereum Remix extension pack for VS Code\n💡 Note: As per the official repository, this extension has been removed from the VSCODE marketplace and will be replaced by a dedicated stand-alone desktop application.\n\nSolidity Visual Studio Code extension, by Juan BlancoSolidity plugin for Microsoft Visual Studio Code that includes syntax highlighting and the Solidity compiler.\n\nSolidity Visual Studio Code extension, by Nomic FoundationSolidity and Hardhat support by the Hardhat team, including: syntax highlighting, jump to definition, renames, quick fixes and inline solc warnings and errors.\n\nSolidity Visual Auditor extensionAdds security centric syntax and semantic highlighting to Visual Studio Code.\n\nTruffle for VS CodeBuild, debug and deploy smart contracts on Ethereum and EVM-compatible blockchains.\n💡 Note: This extension has built-in support for the Truffle Suite which is being sunset.\nFor information on ongoing support, migration options and FAQs, visit the Consensys blog.\n\nSolidity Tools\n\nABI to Solidity interface converterA script for generating contract interfaces from the ABI of a smart contract.\n\nabi-to-solTool to generate Solidity interface source from a given ABI JSON.\n\nAderynRust-based solidity smart contract static analyzer designed to help find vulnerabilities in Solidity code bases.\n\nDoxityDocumentation Generator for Solidity.\n\nethdebugA standard debugging data format for smart contracts on Ethereum-compatible networks.\n\nEthlintLinter to identify and fix style and security issues in Solidity.\n\nevmdisEVM Disassembler that performs static analysis on the bytecode to provide a higher level of abstraction than raw EVM operations.\n\nEVM LabA collection of tools to interact with the EVM. The package includes a VM, Etherchain API, and a trace-viewer with gas cost display.\n\nhevmEVM debugger and symbolic execution engine.\n\nleaflethA documentation generator for Solidity smart-contracts.\n\nScaffold-ETH 2Forkable Ethereum development stack focused on fast product iterations.\n\nsol2umlUnified Modeling Language (UML) class diagram generator for Solidity contracts.\n\nsolc-selectA script to quickly switch between Solidity compiler versions.\n\nSolidity prettier pluginA Prettier Plugin for Solidity.\n\nSolidity REPLTry Solidity instantly with a command-line Solidity console.\n\nsolgraphVisualize Solidity control flow and highlight potential security vulnerabilities.\n\nSolhintSolidity linter that provides security, style guide and best practice rules for smart contract validation.\n\nSourcifyDecentralized automated contract verification service and public repository of contract metadata.\n\nSūryaUtility tool for smart contract systems, offering a number of visual outputs and information about the contracts’ structure. Also supports querying the function call graph.\n\nUniversal MutatorA tool for mutation generation, with configurable rules and support for Solidity and Vyper.\n\nWakeA Python-based Solidity development and testing framework with built-in vulnerability detectors.\n\nThird-Party Solidity Parsers and Grammars\n\nSolidity Parser for JavaScriptA Solidity parser for JS built on top of a robust ANTLR4 grammar.","tokens":1306,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791266907761,"hash":"89d6e48031e8149f235d2714bc9a2fecada8b344"}
{"url":"https://docs.optimism.io/op-stack/interop/reorg","domain":"docs.optimism.io","title":"Optimism Documentation","text":"OP Stack interop is in active development. Some features may be experimental.\nA chain reorganization, or “reorg”, happens when validators disagree on the most accurate version of the blockchain.\nIf not handled correctly, reorgs in a cross-chain context could result in a double-spend problem.\nThe most frequent solution to mitigate the double-spend problem is to wait for Ethereum finality; however, that solution results in high latency cross-chain communication and a poor user experience.\nWhat is double-spending?In a normal asset transfer tokens are debited on the source chain first, then a message is sent to the destination chain.\nWhen that message is received, the tokens are credited on the destination chain, where the user can now use those tokens.A double-spend problem occurs when the destination chain receives a valid initiating message, but due to issues on the source chain, such as a reorg, that initiating transaction is no longer valid.\nWhen that happens, the tokens are still on the source chain, but they are also on the destination chain.The mechanism varies by asset.\nETH is locked and unlocked in an on-chain liquidity contract; SuperchainERC20 tokens are burned and minted.\nThe double-spend risk is the same either way.\nMost solutions to mitigate the double-spend problem rely on L1 finality. However, that solution results in high latency and poor user experience.\nTo mitigate the double-spend problem while delivering a low-latency cross-chain experience, OP Stack interop uses block safety levels.\nThis means users can transfer assets across OP Stack chains with 1-block latency, and should a reorg happen, either both the source and destination transactions remain or both of them revert.\nIn every case, there is no window of opportunity to double spend.\n​Block safety levels\n\nIn the diagram above, solid arrows show derivation of a block from the previous block in the chain. Dotted arrows go from a block with an initiating message (source) to a block with the matching executing message (destination). Throughout this page, blocks are colored by safety level: finalized (grey), safe (green), or unsafe (red).\nBlockchain A has only published block A100 to L1. Block A101 is still unsafe, and so is every block that depends on it — directly (A102 and B302) or indirectly (A103 and B303). Even if blocks B302 and B303 have themselves been written to L1, they cannot become safe until A101 does, because a block is only treated as safe once every initiating message it references is also at least safe. When A101 eventually lands on L1, the chain of dependent blocks can promote in turn.\nThe message between A101 and B302 can be an asset moving across the bridge.\nIn that case, the initiating message (A101) burns n tokens on the source chain (A), and the executing message (B302) mints n tokens on the destination chain (B).\n​How the dependency check is enforced\nThe dependency rule above — a block is only safe once every initiating message it references is also safe — is enforced by op-supernode, the component that hosts the consensus layer of every chain in a dependency set together. For each L2 timestamp, op-supernode’s interop activity decides between wait, advance, invalidate, and rewind. The decision is persisted to a write-ahead log before being applied, so the supernode picks up after a restart in the same state it was in before.\nEach chain’s CL stays the single source of truth for safety on its own chain. The supernode influences advancement through interfaces the chain itself controls, never by reaching into the CL or the execution layer. The rest of this page describes the situations that drive each decision.\n​L1 reorg\nL1 reorgs typically happen at the unsafe head — only the most recent L1 blocks, before they have enough confirmations to be considered safe. Each chain’s CL already filters L1 derivation through L1 safe and finalized labels, so almost all L1 reorgs never reach the L2 derivation pipeline at all.\nWhen an L1 reorg does affect L2, one of two things happens:\n\nThe replacement L1 block carries the same batch data as the original. Derivation is deterministic, so the L2 chain it produces is identical, and the reorg is a no-op from the L2 perspective.\nThe replacement L1 block does not carry that batch data. The sequencer notices and reposts the affected batch in a later L1 block. As long as the batch lands again before the sequencer window elapses (3600 L1 blocks ≈ 12 hours on standard chains like OP Mainnet and Unichain), derivation reproduces the same L2 chain. If the window does elapse without the batch reappearing, the affected L2 blocks are replaced with deposit-only blocks (see Invalid block below).\n\nIf a leaked L1 reorg leaves op-supernode with inconsistent per-chain views of L1, the interop activity issues a rewind: verified state is rolled back and re-derived once L1 settles.\nL1 reorgs do not by themselves break interop guarantees. Either the data comes back and L2 stays identical, or the chain falls back to deposit-only blocks for that span — the same behavior as if the sequencer had simply gone offline.\n​Equivocation\nSequencers inform the rest of the OP Stack chains about a new block in two ways:\n\nThe gossip protocol, which is typically used as soon as the block is created.\nThe problem is that the gossip protocol does not create a commitment.\nPosting to L1, which typically happens a few minutes after the block is created.\nThe reason is cost; it is much cheaper if compression and L1 posting are done in large batches rather than for each individual block.\n\nEquivocation happens when a sequencer publishes a block over the gossip protocol that differs from the one that eventually gets written to L1. The L1 version wins, and op-supernode issues an invalidate for every unsafe dependent block (local or cross-chain) that built on the gossiped version.\n\nA block in another chain can only depend on a specific block here if it referenced one of that block’s logs in an executing message — and a block only earns the safe label once every initiating message it depends on has also reached at least safe. So the equivocation between A101 and A’101 only invalidates unsafe blocks: A102 and A103 on chain A (extending the bad history), B301 and B302 on chain B (which referenced A101 directly) along with B303 (which follows them on chain B), and C203 on chain C (which referenced B302). All those unsafe blocks are reorged out and replaced by the corresponding '-marked blocks, which derive from A’101. Anything previously labeled safe or finalized is untouched.\n​Invalid block\nA block can also be canonically invalidated outright. If verifiers determine that an L2 block cannot be reproduced from L1 — for example because the batch claims an initiating message that does not exist on the source chain — the canonical chain replaces it with a deposit-only block: a block that contains only the deposit transactions forced through L1, with all sequencer transactions stripped out. For interop-specific failures like that example, op-supernode is the verifier that makes the call.\nWhat makes a block invalid?There are several potential reasons:\nThe block posted to L1 includes incorrect information — for example, a batch claims an initiating message that the source chain never actually emitted, so any executing message that references it cannot be reproduced.\nThe block was never posted at all. If the sequencer window elapses (3600 L1 blocks ≈ 12 hours on standard chains) without a batch covering an L1 epoch, verifiers fall back to a deposit-only block for that epoch.\n\nFunctionally this is equivalent to equivocation, and the dependency rules above handle it the same way: only unsafe blocks (and any chain of blocks depending on them transitively) are reshaped, and any block that had already reached the safe label is untouched.\n​Next steps\n\nRead the interop explainer for the rest of the architecture.\nRead about op-supernode, the component that derives every chain in the dependency set together and enforces the safety levels described above.\nRead the cross-chain security measures for safe interoperability.\nView more interop guides and tutorials.\nWas this page helpful?","tokens":2045,"squid":"ink-governance","role":"Council Listener","at":1791266911203,"hash":"f025a52ab65b04759625d7f9ff3dd8678ae5f247"}
{"url":"https://docs.optimism.io/op-stack/protocol/outages","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Normative spec: Bypassing the sequencer with deposit transactions is normatively defined in the deposits specification. This page explains outage types and mitigations; it does not restate the spec.\nAll OP Stack chains have a Sequencer that can receive, order, and publish L2 transactions to L1.\nLike any software system, a Sequencer could potentially become unavailable for any number of different reasons.\nIt’s important to be aware of the implications of a Sequencer outage and how you can be prepared for it.\nSequencer outages can broadly be categorized into two different types:\n\nSequencer Downtime Outages occur when the Sequencer is entirely unable to receive and/or process L2 transactions from users. Outages of this type will appear to users as a complete inability to submit transactions to the Sequencer.\nTransaction Submission Outages occur when the Sequencer is still able to receive and process L2 transactions from users but is unable to publish these transactions to L1. Outages of this type generally do not impact users unless they remain unresolved for an extended period of time.\n\nBoth outage types can be circumvented by submitting transactions directly to the OptimismPortal contract on L1 with certain important caveats.\nKeep reading to learn more about these potential outages and how to handle them.\n​Sequencer downtime outages\n​Description\nSequencer downtime outages occur when the Sequencer is unable to receive and/or process L2 transactions from users.\nOutages of this type may be caused by any number of different issues, including bugs in client software, cloud outages, or other similar errors.\nExact causes of Sequencer downtime outages can be dependent on the specific infrastructure used to run the Sequencer for any given OP Stack chain.\n​Impact\nSequencer downtime outages can have a significant impact on the user experience.\nDuring an outage of this type, users will be unable to submit transactions directly to the Sequencer.\nUsers may observe that the network appears to be “stuck” at a particular block height.\n​Mitigation\nUsers can always bypass the Sequencer by sending L2 transactions directly to the OptimismPortal contract on L1.\nRefer to the Bypassing the Sequencer section below for more information about this functionality.\n​Transaction submission outages\n​Description\nTransaction submission outages occur when the Sequencer is still able to receive and process L2 transactions from users but is unable to publish these transactions to L1.\nOutages of this type may be caused by any number of different issues including unexpected L1 network conditions, bugs in transaction submission software, or other similar errors.\n​Impact\nTransaction submission outages generally do not have a significant impact on the user experience unless they remain unresolved for an extended period of time.\nDuring an outage of this type, users will be able to submit transactions directly to the Sequencer but the blocks including these transactions will not be published to L1.\nUsers may observe that the “safe” and “finalized” block heights of the L2 chain appear to remain stuck while the “unsafe” block height continues to increase.\nTransaction submission outages can cause a more significant impact if they remain unresolved.\nCrucially, L2 transactions sent directly to the Sequencer must be published within a certain amount of time after they are included in an L2 block by the Sequencer.\nIf this time limit is exceeded, the L2 chain must be reorganized to include these transactions in a later block.\nThis can appear to users as a large change in the expected state of the L2 chain.\n​Mitigation\nUsers can always bypass the Sequencer by sending L2 transactions directly to the OptimismPortal contract on L1.\nRefer to the Bypassing the Sequencer section for more information about this functionality.\n​Bypassing the sequencer\nA core security goal of OP Stack chains is that the Sequencer should not be able to prevent users from submitting transactions to the L2 chain.\nUsers of OP Stack chains can always bypass the sequencer and include transactions in the L2 chain by sending their L2 transactions directly to the OptimismPortal contract on L1.\n​About the OptimismPortal\nThe OptimismPortal contract is an L1 smart contract that can be used by both smart contracts and EOAs to create L2 transactions without the direct involvement of the Sequencer.\nMany users already interact with this contract indirectly when they bridge ETH or other tokens between L1 and L2 via the Standard Bridge system available on all OP Stack chains.\nThe OptimismPortal contract is currently a unique contract for each OP Stack chain.\nRefer to the contract addresses page for your OP Stack chain to find the address of the OptimismPortal contract.\nL2 transactions can be triggered on L1 by calling the depositTransaction function on the OptimismPortal contract.\n​Capabilities\nUsers can send any type of L2 transaction to the OptimismPortal contract including contract creations and transactions that carry ETH value.\nAs a security measure, transactions sent via the OptimismPortal are indistinguishable from transactions sent via the Sequencer from the perspective of smart contracts on L2.\n​Address aliasing\nTransactions triggered via the OptimismPortal contract will appear to have been sent by the L1 address that triggered the transaction unless the transaction was sent by a smart contract.\nL2 transactions sent by smart contracts via the OptimismPortal contract will appear to have been sent by an “aliased” version of the smart contract’s address.\nRefer to the address aliasing explainer for more information about address aliasing.\n​Inclusion rules\nTransactions sent to the OptimismPortal contract are processed according to a set of rules designed to limit the impact of a failed Sequencer.\nIt’s important to understand these rules in detail to properly mitigate the effects of an outage.\nFor all transactions sent to the OptimismPortal:\n\nTransactions sent within a specific L1 block are processed together.\nTransactions are given a timestamp no more than max_sequencer_drift in the future.\nTransactions are processed in the order they are received.\nTransactions are processed within the sequencer_window.\n\nIn practice, this means that transactions sent to the OptimismPortal contract will always be processed in the order they are received and within a maximum delay of the sequencer_window (set to 12 hours by default but may differ from chain to chain).\nIf the Sequencer is unavailable or transactions are not published to L1 within this sequencer_window, OP Stack chains will automatically reorganize themselves to guarantee that these transactions are included in the L2 chain.\nRefer to the L2 Chain Derivation Specification for a much more detailed explanation of how transactions sent to the OptimismPortal contract are processed.\n​Inclusion scenarios\nIt can be helpful to understand how transactions sent to the OptimismPortal contract are processed in different scenarios.\nThe following scenarios make different assumptions about the state of the Sequencer and the L2 chain to illustrate how transactions sent to the OptimismPortal contract are processed.\n​Total sequencer outage\nIn this scenario we’ll assume that the Sequencer is completely unavailable and unable to process any transactions.\nUsers must send transactions directly to the OptimismPortal contract to have them included in the L2 chain.\nWe’ll also assume that the sequencer_window has been set to 12 hours.\nHere, two users are sending transactions to the OptimismPortal contract.\nObserve how the transactions sent by both users are included in the L2 chain automatically after the sequencer_window has elapsed.\nThe transactions are included in the L2 chain in the order they were received by the OptimismPortal contract.\n\n​Partial sequencer outage\nIn this scenario we’ll assume that the Sequencer is down for some period of time but comes back online before the sequencer_window has elapsed.\nA user sends a transaction to the OptimismPortal during the downtime but the Sequencer comes back online and includes the transaction in an L2 block before the full sequencer_window ends.\n\n​Partial outage ordering\nHere we’ll again assume that the Sequencer is down for some period of time but comes back online before the sequencer_window has elapsed.\nIn this scenario, we’ll observe the ability that the Sequencer has to include additional transactions in the L2 chain in between transactions sent to the OptimismPortal contract.\nHere, even though the first user sends their transaction to the OptimismPortal contract before the second user sends their transaction to the Sequencer, the Sequencer is able to include the second user’s transaction before the first user’s transaction is included.\nSequencers will typically choose to include transactions sent to the OptimismPortal contract before any other transactions but this is not guaranteed.\nWas this page helpful?","tokens":2240,"squid":"ink-governance","role":"Council Listener","at":1791266922470,"hash":"3763323ed77839787c6f446482ec28a870d10564"}
{"url":"https://forum.pyth.network/t/july-2026-pyth-purchases-report/2658","domain":"forum.pyth.network","title":"July 2026 — PYTH Purchases Report - PYTH Reserves - Pyth DAO","text":"July 2026 — PYTH Purchases Report \n\n PYTH Reserves\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Aug 3\n\n 1 / 4\n\n Aug 3\n\n Sep 3\n\n post by Frozenmind on Aug 3\n\n Frozenmind\n\n On July 29th, 2026, the Pyth DAO, via the OP-PIP-123.V2, approved the usage of 1/3 of the Pyth DAO Treasury to monthly purchases PYTH tokens. These purchases are administered and executed by the Pythian Council.\n\nOn July 29th, 2026, the Pythian Council Ops Multisig received the following from the Pyth DAO Treasury:\n\n38,552.13 USDC\n101.92 SOL\n\nSubsequently, the Pythian Council, exercising no independent discretion and acting only pursuant to the DAO’s instructions within the OP-PIP parameters, executed the following transactions:\n\n38,552.13 USDC <> 957,686.90 PYTH\n102 SOL <> 186,942.23 PYTH\n\nLast but not least, the Pythian Council sent back to the Pyth DAO Treasury the following:\n\n1,144,629.131118 PYTH\n\nYou may review all tokens transfers, and swaps here.\n\n 2\n\n 2\n\n 27 days later\n\n post by Joy on Aug 31\n\n Joy\n\n It would be good to set a fixed date for purchases and post on that date. For example, like purchasing on the 1st of every month and posting on the 1st.\n\n post by Frozenmind on Aug 31\n\n Frozenmind\n\n Thanks for the suggestion. Just to clarify, the intention here is indeed to use a DCA approach over a longer period of time, rather than have the Council make a single discretionary purchase at some random point during the month.\nThe framework was established through OP-PIP-87 and the subsequent monthly purchase PIPs. The mandate gives the Council some flexibility in how the purchases are executed, with the objective of accumulating PYTH efficiently on the secondary market. This can include limit orders, smaller market orders, and standard swaps when appropriate, particularly for lower volumes. The July purchase was executed under OP-PIP-123.V2.\nWhile the report presents the monthly activity as a consolidated purchase, the actual execution is structured around this longer-term DCA approach. All of the details are also included in the spreadsheet linked in the report.\nAs for the timing of the reports, I’ve been handling these reports for the past several months, and our goal is always to have them published as close as possible to the end of the month. That said, because we operate through a multisig structure, there are sometimes a few additional steps involved that can result in the report being published a few days into the following month.\nImportantly, this doesn’t mean the activity is happening behind the scenes. All transactions involving the Pythian Council multisig can be followed on-chain as they happen, including the DCA executions through Jupiter DCA, which is integrated directly with the Squads multisig. So the transactions are publicly verifiable in real time, even if the consolidated report itself takes a few extra days to publish.\n\n post by Joy on Sep 3\n\n Joy\n\n Thank you for your reply. I do not mean to deny your efforts. I was simply thinking it would be good to post on a fixed schedule, but your response has helped me understand. Have a nice day.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n August 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 125\n\n Sep 2\n\n March 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 145\n\n Mar 30\n\n June 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 126\n\n Jul 6\n\n February 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 133\n\n Mar 2\n\n April 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 145\n\n Apr 28","tokens":895,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791266932038,"hash":"003ab9d1bd1e4c2ac003d4db1e3e8eae042439fc"}
{"url":"https://docs.optimism.io/op-stack/protocol/privileged-roles","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Normative spec: The OP Stack's Stage 1 security model is normatively defined in the Stage 1 roles and requirements specification. This page explains the roles and their risks; it does not restate the spec.\nOP Stack chains follow a Pragmatic Path to Decentralization.\nIn their current state, OP Stack chains still include some “privileged” roles that give certain addresses the ability to carry out specific actions.\nMembers and users of the OP Stack ecosystem should be aware of these roles and their associated risks because they’re shared across many OP Stack chains.\nRead this page to understand these roles, why they exist, and what risks they pose.\n​L1 Proxy Admin\nThe L1 Proxy Admin is an address that can be used to upgrade most OP Stack chains system contracts.\n​Risks\n\nCompromised L1 Proxy Admin could upgrade contracts to malicious versions.\nCompromised L1 Proxy Admin could remove or lock ETH or tokens in the Standard Bridge.\nCompromised L1 Proxy Admin could fail to mitigate a risk as described on this page.\n\n​Mitigations\n\nL1 Proxy Admin owner is a 2-of-2 multisig. One owner is an Optimism Foundation 5/7 multisig and the other owner is the Security Council multisig.\n\n​Addresses\n\nOptimism Governed Chains on Ethereum: 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A\nOptimism Governed Chains on Sepolia: 0x1Eb2fFc903729a0F03966B917003800b145F56E2\n\n​L2 Proxy Admin\nThe L2 Proxy Admin is an address that can be used to upgrade most OP Stack chains system contracts on L2. The L2 Proxy Admin owner is the aliased address of the L1ProxyAdmin owner, which means the L2 ProxyAdmin Owner is equal to the L1 ProxyAdmin Owner, but due to aliasing it’s a different address. Here’s how that works:\n\nGiven an L1 contract address, the aliased L2 address is equal to L1_contract_address + 0x1111000000000000000000000000000000001111.\nUsing 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b as an example, the 0x6B address is the L2 address that’s been aliased, so to figure out the original L1 address you calculate 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b - 0x1111000000000000000000000000000000001111.\nThat result gives an L1 contract address of 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A, which should be the 2/2 Safe owned by Foundation + Security Council that is L1 ProxyAdmin Owner.\nNo one has the private key for 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b on OP Stack chains, which means the only way for the L2 ProxyAdmin owner to send transactions is via deposit transactions from the L1 0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A address.\nFor help with the calculations, see the AddressAliasHelper library.\n\n​Risks\n\nCompromised L2 Proxy Admin could upgrade contracts to malicious versions.\nCompromised L2 Proxy Admin could remove or lock ETH or tokens in the Standard Bridge.\nCompromised L2 Proxy Admin could fail to mitigate a risk as described on this page.\n\n​Mitigations\n\nL2 Proxy Admin is controlled by the same L1 account as the L1 Proxy Admin. This is enabled by address aliasing.\n\n​Addresses\nThese addresses are controlled by the same L1 Proxy Admin addresses. Please read the descriptions above for more details.\n\nOptimism Governed Chains on Ethereum: 0x6B1BAE59D09fCcbdDB6C6cceb07B7279367C4E3b\nOptimism Governed Chains on Sepolia: 0x2FC3ffc903729a0f03966b917003800B145F67F3\n\n​System Config Owner\nThe System Config Owner is an address that can be used to change the values within the SystemConfig contract on Ethereum.\n​Risks\n\nCompromised System Config Owner could cause a temporary network outage.\nCompromised System Config Owner could cause users to be overcharged for transactions.\n\n​Mitigations\n\nSystem Config Owner is a 5-of-7 multisig.\nSystem Config Owner may eventually be operated by a Security Council.\nSystem Config Owner can be replaced by the L1 Proxy Admin.\n\n​Addresses\nThe System Config owner is chain specific and you can see which addresses are configured in the Superchain Registry.\n​Batcher\n​Description\nThe Batcher is a software service that submits batches of transactions to Ethereum on behalf of the current OP Stack chains Sequencer.\nOP Stack chains nodes will look for transactions from this address to find new batches of L2 transactions to process.\n​Risks\n\nBatcher address is typically a hot wallet.\nCompromised batcher address can cause L2 reorgs or sequencer outages.\n\n​Mitigations\n\nCompromised batcher address cannot publish invalid transactions.\nCompromised batcher address can be replaced by the L1 Proxy Admin.\n\n​Addresses\nThe batcher address is chain specific and you can see which addresses are configured in the Superchain Registry.\n​Proposer\n​Description\nThe Proposer is a role that is allowed to create instances of the PermissionedDisputeGame dispute game type.\nThe PermissionedDisputeGame can be used as a fallback dispute game in the case that the FaultDisputeGame is found to include a critical security vulnerability.\nThe Guardian role is responsible for changing the respected dispute game type if necessary.\n​Capabilities\n\nCan create instances of the PermissionedDisputeGame dispute game type.\nCan participate in the PermissionedDisputeGame dispute game process.\n\n​Risks\n\nProposer address is typically a hot wallet.\nCompromised proposer address could propose invalid state proposals.\nInvalid state proposals can be used to execute invalid withdrawals after 7 days.\n\n​Mitigations\n\nCompromised proposer address can be replaced by the L1 Proxy Admin.\nInvalid state proposals can be challenged by the Challenger within 7 days.\n\n​Addresses\nThe proposer address is chain specific and you can see which addresses are configured in the Superchain Registry.\n​Challenger\n​Description\nThe Challenger is an address that can participate in and challenge PermissionedDisputeGame instances created by the Proposer role. It is important to note that this is different from the op-challenger services that challenges invalid output roots.\n​Capabilities\n\nCan participate in the PermissionedDisputeGame dispute game process.\n\n​Risks\n\nCompromised challenger could invalidate valid state proposals.\nCompromised challenger could fail to challenge invalid state proposals.\n\n​Mitigations\n\nCompromised challenger address can be replaced by the L1 Proxy Admin.\nChallenges can be executed by replaced challenger address.\n\n​Addresses\n\nOptimism Governed Chains on Ethereum: 0x9BA6e03D8B90dE867373Db8cF1A58d2F7F006b3A\nOptimism Governed Chains on Sepolia: 0xfd1D2e729aE8eEe2E146c033bf4400fE75284301\n\n​Guardian\n​Description\nThe Guardian is an address that can be used to pause several system contracts on OP Stack chains.\nThis is a backup safety mechanism that allows for a temporary halt, particularly of withdrawal logic, in the event of a security concern.\nThe Guardian can also manage various aspects of the OptimismPortal contract to address active security concerns.\n​Capabilities\n\nPause several system contracts on OP Stack chains.\nDisable the ability for specific dispute game types from being used to execute withdrawals.\nDisable the ability for specific dispute game instances from being used to execute withdrawals.\n\n​Risks\n\nCompromised guardian could pause withdrawals for 3 months, after which withdrawals are automatically unpaused.\n\n​Mitigations\n\nCompromised guardian address can be replaced by the L1 Proxy Admin.\nWithdrawals can be unpaused by replaced guardian address.\n\n​Addresses\n\nOptimism Governed Chains on Ethereum: 0x09f7150D8c019BeF34450d6920f6B3608ceFdAf2\nOptimism Governed Chains on Sepolia: 0xf64bc17485f0B4Ea5F06A96514182FC4cB561977\n\n​Mint Manager Owner\nThe Mint Manager Owner is an address that controls the MintManager contract that can be used to mint new OP tokens on OP Stack chains.\n​Risks\n\nCompromised Mint Manager Owner could mint arbitrary amounts of OP tokens.\nCompromised Mint Manager Owner could prevent OP tokens from being minted.\n\n​Mitigations\n\nMint Manager Owner is a 3-of-5 multisig.\n\n​Addresses\n\nEthereum: 0x2a82ae142b2e62cb7d10b55e323acb1cab663a26\nSepolia: 0x5c4e7ba1e219e47948e6e3f55019a647ba501005\nWas this page helpful?","tokens":1997,"squid":"ink-governance","role":"Council Listener","at":1791266934240,"hash":"4a646204dfc049057b37001081ba674fc3744de7"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api/access","domain":"docs.openzeppelin.com","title":"Access | OpenZeppelin Docs","text":"OpenZeppelin ContractsAPI ReferenceAccessSmart contract access utilities and implementationsOpen in ClaudeThis directory provides ways to restrict who can access the functions of a contract or when they can do it.\n\nAccessManager is a full-fledged access control solution for smart contract systems. Allows creating and assigning multiple hierarchical roles with execution delays for each account across various contracts.\nAccessManaged delegates its access control to an authority that dictates the permissions of the managed contract. It’s compatible with an AccessManager as an authority.\nAccessControl provides a per-contract role based access control mechanism. Multiple hierarchical roles can be created and assigned each to multiple accounts within the same instance.\nOwnable is a simpler mechanism with a single owner \"role\" that can be assigned to a single account. This simpler mechanism can be useful for quick tests but projects with production concerns are likely to outgrow it.\n\nCore\nOwnable\nOwnable2Step\nIAccessControl\nAccessControl\nExtensions\nIAccessControlEnumerable\nAccessControlEnumerable\nIAccessControlDefaultAdminRules\nAccessControlDefaultAdminRules\nAccessManager\nIAuthority\nIAccessManager\nAccessManager\nIAccessManaged\nAccessManaged\nAuthorityUtils\n\nAccessControl\nimport \"@openzeppelin/contracts/access/AccessControl.sol\";\nContract module that allows children to implement role-based access\ncontrol mechanisms. This is a lightweight version that doesn't allow enumerating role\nmembers except through off-chain means by accessing the contract event logs. Some\napplications may benefit from on-chain enumerability, for those cases see\nAccessControlEnumerable.\nRoles are referred to by their bytes32 identifier. These should be exposed\nin the external API and be unique. The best way to achieve this is by\nusing public constant hash digests:\nbytes32 public constant MY_ROLE = keccak256(\"MY_ROLE\");\nRoles can be used to represent a set of permissions. To restrict access to a\nfunction call, use AccessControl.hasRole:\nfunction foo() public {\n require(hasRole(MY_ROLE, msg.sender));\n ...\n}\nRoles can be granted and revoked dynamically via the AccessControl.grantRole and\nAccessControl.revokeRole functions. Each role has an associated admin role, and only\naccounts that have a role's admin role can call AccessControl.grantRole and AccessControl.revokeRole.\nBy default, the admin role for all roles is DEFAULT_ADMIN_ROLE, which means\nthat only accounts with this role will be able to grant or revoke other\nroles. More complex role relationships can be created by using\nAccessControl._setRoleAdmin.\nThe DEFAULT_ADMIN_ROLE is also its own admin: it has permission to\ngrant and revoke this role. Extra precautions should be taken to secure\naccounts that have been granted it. We recommend using AccessControlDefaultAdminRules\nto enforce additional security measures for this role.\nModifiers\nonlyRole(role)\n\nFunctions\nsupportsInterface(interfaceId)\nhasRole(role, account)\n_checkRole(role)\n_checkRole(role, account)\ngetRoleAdmin(role)\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, callerConfirmation)\n_setRoleAdmin(role, adminRole)\n_grantRole(role, account)\n_revokeRole(role, account)\nDEFAULT_ADMIN_ROLE()\n\nEventsIAccessControl\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nErrorsIAccessControl\nAccessControlUnauthorizedAccount(account, neededRole)\nAccessControlBadConfirmation()\n\nonlyRole(bytes32 role)internal#Modifier that checks that an account has a specific role. Reverts\nwith an IAccessControl.AccessControlUnauthorizedAccount error including the required role.\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#Returns true if this contract implements the interface defined by\ninterfaceId. See the corresponding\nERC section\nto learn more about how these ids are created.This function call must use less than 30 000 gas.\n\nhasRole(bytes32 role, address account) → boolpublic#Returns true if account has been granted role.\n\n_checkRole(bytes32 role)internal#Reverts with an IAccessControl.AccessControlUnauthorizedAccount error if _msgSender()\nis missing role. Overriding this function changes the behavior of the AccessControl.onlyRole modifier.\n\n_checkRole(bytes32 role, address account)internal#Reverts with an IAccessControl.AccessControlUnauthorizedAccount error if account\nis missing role.\n\ngetRoleAdmin(bytes32 role) → bytes32public#Returns the admin role that controls role. See AccessControl.grantRole and\nAccessControl.revokeRole.To change a role's admin, use AccessControl._setRoleAdmin.\n\ngrantRole(bytes32 role, address account)public#Grants role to account.If account had not been already granted role, emits a IAccessControl.RoleGranted\nevent.Requirements:\nthe caller must have role's admin role.\nMay emit a IAccessControl.RoleGranted event.\n\nrevokeRole(bytes32 role, address account)public#Revokes role from account.If account had been granted role, emits a IAccessControl.RoleRevoked event.Requirements:\nthe caller must have role's admin role.\nMay emit a IAccessControl.RoleRevoked event.\n\nrenounceRole(bytes32 role, address callerConfirmation)public#Revokes role from the calling account.Roles are often managed via AccessControl.grantRole and AccessControl.revokeRole: this function's\npurpose is to provide a mechanism for accounts to lose their privileges\nif they are compromised (such as when a trusted device is misplaced).If the calling account had been revoked role, emits a IAccessControl.RoleRevoked\nevent.Requirements:\nthe caller must be callerConfirmation.\nMay emit a IAccessControl.RoleRevoked event.\n\n_setRoleAdmin(bytes32 role, bytes32 adminRole)internal#Sets adminRole as role's admin role.Emits a IAccessControl.RoleAdminChanged event.\n\n_grantRole(bytes32 role, address account) → boolinternal#Attempts to grant role to account and returns a boolean indicating if role was granted.Internal function without access restriction.May emit a IAccessControl.RoleGranted event.\n\n_revokeRole(bytes32 role, address account) → boolinternal#Attempts to revoke role from account and returns a boolean indicating if role was revoked.Internal function without access restriction.May emit a IAccessControl.RoleRevoked event.\n\nDEFAULT_ADMIN_ROLE() → bytes32public#\n\nIAccessControl\nimport \"@openzeppelin/contracts/access/IAccessControl.sol\";\nExternal interface of AccessControl declared to support ERC-165 detection.\nFunctions\nhasRole(role, account)\ngetRoleAdmin(role)\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, callerConfirmation)\n\nEvents\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nErrors\nAccessControlUnauthorizedAccount(account, neededRole)\nAccessControlBadConfirmation()\n\nhasRole(bytes32 role, address account) → boolexternal#Returns true if account has been granted role.\n\ngetRoleAdmin(bytes32 role) → bytes32external#Returns the admin role that controls role. See AccessControl.grantRole and\nAccessControl.revokeRole.To change a role's admin, use AccessControl._setRoleAdmin.\n\ngrantRole(bytes32 role, address account)external#Grants role to account.If account had not been already granted role, emits a IAccessControl.RoleGranted\nevent.Requirements:\nthe caller must have role's admin role.\n\nrevokeRole(bytes32 role, address account)external#Revokes role from account.If account had been granted role, emits a IAccessControl.RoleRevoked event.Requirements:\nthe caller must have role's admin role.\n\nrenounceRole(bytes32 role, address callerConfirmation)external#Revokes role from the calling account.Roles are often managed via AccessControl.grantRole and AccessControl.revokeRole: this function's\npurpose is to provide a mechanism for accounts to lose their privileges\nif they are compromised (such as when a trusted device is misplaced).If the calling account had been granted role, emits a IAccessControl.RoleRevoked\nevent.Requirements:\nthe caller must be callerConfirmation.\n\nRoleAdminChanged(bytes32 indexed role, bytes32 indexed previousAdminRole, bytes32 indexed newAdminRole)event#Emitted when newAdminRole is set as role's admin role, replacing previousAdminRoleDEFAULT_ADMIN_ROLE is the starting admin for all roles, despite\nIAccessControl.RoleAdminChanged not being emitted to signal this.\n\nRoleGranted(bytes32 indexed role, address indexed account, address indexed sender)event#Emitted when account is granted role.sender is the account that originated the contract call. This account bears the admin role (for the granted role).\nExpected in cases where the role was granted using the internal AccessControl._grantRole.\n\nRoleRevoked(bytes32 indexed role, address indexed account, address indexed sender)event#Emitted when account is revoked role.sender is the account that originated the contract call:\nif using revokeRole, it is the admin role bearer\nif using renounceRole, it is the role bearer (i.e. account)\n\nAccessControlUnauthorizedAccount(address account, bytes32 neededRole)error#The account is missing a role.\n\nAccessControlBadConfirmation()error#The caller of a function is not the expected one.Don't confuse with IAccessControl.AccessControlUnauthorizedAccount.\n\nOwnable\nimport \"@openzeppelin/contracts/access/Ownable.sol\";\nContract module which provides a basic access control mechanism, where\nthere is an account (an owner) that can be granted exclusive access to\nspecific functions.\nThe initial owner is set to the address provided by the deployer. This can\nlater be changed with Ownable.transferOwnership.\nThis module is used through inheritance. It will make available the modifier\nonlyOwner, which can be applied to your functions to restrict their use to\nthe owner.\nModifiers\nonlyOwner()\n\nFunctions\nconstructor(initialOwner)\nowner()\n_checkOwner()\nrenounceOwnership()\ntransferOwnership(newOwner)\n_transferOwnership(newOwner)\n\nEvents\nOwnershipTransferred(previousOwner, newOwner)\n\nErrors\nOwnableUnauthorizedAccount(account)\nOwnableInvalidOwner(owner)\n\nonlyOwner()internal#Throws if called by any account other than the owner.\n\nconstructor(address initialOwner)internal#Initializes the contract setting the address provided by the deployer as the initial owner.\n\nowner() → addresspublic#Returns the address of the current owner.\n\n_checkOwner()internal#Throws if the sender is not the owner.\n\nrenounceOwnership()public#Leaves the contract without owner. It will not be possible to call\nonlyOwner functions. Can only be called by the current owner.Renouncing ownership will leave the contract without an owner,\nthereby disabling any functionality that is only available to the owner.\n\ntransferOwnership(address newOwner)public#Transfers ownership of the contract to a new account (newOwner).\nCan only be called by the current owner.\n\n_transferOwnership(address newOwner)internal#Transfers ownership of the contract to a new account (newOwner).\nInternal function without access restriction.\n\nOwnershipTransferred(address indexed previousOwner, address indexed newOwner)event#\n\nOwnableUnauthorizedAccount(address account)error#The caller account is not authorized to perform an operation.\n\nOwnableInvalidOwner(address owner)error#The owner is not a valid owner account. (eg. address(0))\n\nOwnable2Step\nimport \"@openzeppelin/contracts/access/Ownable2Step.sol\";\nContract module which provides access control mechanism, where\nthere is an account (an owner) that can be granted exclusive access to\nspecific functions.\nThis extension of the Ownable contract includes a two-step mechanism to transfer\nownership, where the new owner must call Ownable2Step.acceptOwnership in order to replace the\nold one. This can help prevent common mistakes, such as transfers of ownership to\nincorrect accounts, or to contracts that are unable to interact with the\npermission system.\nThe initial owner is specified at deployment time in the constructor for Ownable. This\ncan later be changed with Ownable.transferOwnership and Ownable2Step.acceptOwnership.\nThis module is used through inheritance. It will make available all functions\nfrom parent (Ownable).\nFunctions\npendingOwner()\ntransferOwnership(newOwner)\n_transferOwnership(newOwner)\nacceptOwnership()\nOwnable\nowner()\n_checkOwner()\nrenounceOwnership()\n\nEvents\nOwnershipTransferStarted(previousOwner, newOwner)\nOwnable\nOwnershipTransferred(previousOwner, newOwner)\n\nErrorsOwnable\nOwnableUnauthorizedAccount(account)\nOwnableInvalidOwner(owner)\n\npendingOwner() → addresspublic#Returns the address of the pending owner.\n\ntransferOwnership(address newOwner)public#Starts the ownership transfer of the contract to a new account. Replaces the pending transfer if there is one.\nCan only be called by the current owner.Setting newOwner to the zero address is allowed; this can be used to cancel an initiated ownership transfer.\n\n_transferOwnership(address newOwner)internal#Transfers ownership of the contract to a new account (newOwner) and deletes any pending owner.\nInternal function without access restriction.\n\nacceptOwnership()public#The new owner accepts the ownership transfer.\n\nOwnershipTransferStarted(address indexed previousOwner, address indexed newOwner)event#\n\nAccessControlDefaultAdminRules\nimport \"@openzeppelin/contracts/access/extensions/AccessControlDefaultAdminRules.sol\";\nExtension of AccessControl that allows specifying special rules to manage\nthe DEFAULT_ADMIN_ROLE holder, which is a sensitive role with special permissions\nover other roles that may potentially have privileged rights in the system.\nIf a specific role doesn't have an admin role assigned, the holder of the\nDEFAULT_ADMIN_ROLE will have the ability to grant it and revoke it.\nThis contract implements the following risk mitigations on top of AccessControl:\n\nOnly one account holds the DEFAULT_ADMIN_ROLE since deployment until it's potentially renounced.\nEnforces a 2-step process to transfer the DEFAULT_ADMIN_ROLE to another account.\nEnforces a configurable delay between the two steps, with the ability to cancel before the transfer is accepted.\nThe delay can be changed by scheduling, see AccessControlDefaultAdminRules.changeDefaultAdminDelay.\nRole transfers must wait at least one block after scheduling before it can be accepted.\nIt is not possible to use another role to manage the DEFAULT_ADMIN_ROLE.\n\nExample usage:\ncontract MyToken is AccessControlDefaultAdminRules {\n constructor() AccessControlDefaultAdminRules(\n 3 days,\n msg.sender // Explicit initial `DEFAULT_ADMIN_ROLE` holder\n ) {}\n}\nFunctions\nconstructor(initialDelay, initialDefaultAdmin)\nsupportsInterface(interfaceId)\nowner()\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, account)\n_grantRole(role, account)\n_revokeRole(role, account)\n_setRoleAdmin(role, adminRole)\ndefaultAdmin()\npendingDefaultAdmin()\ndefaultAdminDelay()\npendingDefaultAdminDelay()\ndefaultAdminDelayIncreaseWait()\nbeginDefaultAdminTransfer(newAdmin)\n_beginDefaultAdminTransfer(newAdmin)\ncancelDefaultAdminTransfer()\n_cancelDefaultAdminTransfer()\nacceptDefaultAdminTransfer()\n_acceptDefaultAdminTransfer()\nchangeDefaultAdminDelay(newDelay)\n_changeDefaultAdminDelay(newDelay)\nrollbackDefaultAdminDelay()\n_rollbackDefaultAdminDelay()\n_delayChangeWait(newDelay)\nAccessControl\nhasRole(role, account)\n_checkRole(role)\n_checkRole(role, account)\ngetRoleAdmin(role)\nDEFAULT_ADMIN_ROLE()\n\nEventsIAccessControlDefaultAdminRules\nDefaultAdminTransferScheduled(newAdmin, acceptSchedule)\nDefaultAdminTransferCanceled()\nDefaultAdminDelayChangeScheduled(newDelay, effectSchedule)\nDefaultAdminDelayChangeCanceled()\nIAccessControl\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nErrorsIAccessControlDefaultAdminRules\nAccessControlInvalidDefaultAdmin(defaultAdmin)\nAccessControlEnforcedDefaultAdminRules()\nAccessControlEnforcedDefaultAdminDelay(schedule)\nIAccessControl\nAccessControlUnauthorizedAccount(account, neededRole)\nAccessControlBadConfirmation()\n\nconstructor(uint48 initialDelay, address initialDefaultAdmin)internal#Sets the initial values for AccessControlDefaultAdminRules.defaultAdminDelay and AccessControlDefaultAdminRules.defaultAdmin address.\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#\n\nowner() → addresspublic#Gets the address of the owner.\n\ngrantRole(bytes32 role, address account)public#See AccessControl.grantRole. Reverts for DEFAULT_ADMIN_ROLE.\n\nrevokeRole(bytes32 role, address account)public#See AccessControl.revokeRole. Reverts for DEFAULT_ADMIN_ROLE.\n\nrenounceRole(bytes32 role, address account)public#See AccessControl.renounceRole.For the DEFAULT_ADMIN_ROLE, it only allows renouncing in two steps by first calling\nAccessControlDefaultAdminRules.beginDefaultAdminTransfer to the address(0), so it's required that the AccessControlDefaultAdminRules.pendingDefaultAdmin schedule\nhas also passed when calling this function.After its execution, it will not be possible to call onlyRole(DEFAULT_ADMIN_ROLE) functions.Renouncing DEFAULT_ADMIN_ROLE will leave the contract without a AccessControlDefaultAdminRules.defaultAdmin,\nthereby disabling any functionality that is only available for it, and the possibility of reassigning a\nnon-administrated role.\n\n_grantRole(bytes32 role, address account) → boolinternal#See AccessControl._grantRole.For DEFAULT_ADMIN_ROLE, it only allows granting if there isn't already a AccessControlDefaultAdminRules.defaultAdmin or if the\nrole has been previously renounced.Exposing this function through another mechanism may make the DEFAULT_ADMIN_ROLE\nassignable again. Make sure to guarantee this is the expected behavior in your implementation.\n\n_revokeRole(bytes32 role, address account) → boolinternal#Attempts to revoke role from account and returns a boolean indicating if role was revoked.Internal function without access restriction.May emit a IAccessControl.RoleRevoked event.\n\n_setRoleAdmin(bytes32 role, bytes32 adminRole)internal#See AccessControl._setRoleAdmin. Reverts for DEFAULT_ADMIN_ROLE.\n\ndefaultAdmin() → addresspublic#Returns the address of the current DEFAULT_ADMIN_ROLE holder.\n\npendingDefaultAdmin() → address newAdmin, uint48 schedulepublic#Returns a tuple of a newAdmin and an accept schedule.After the schedule passes, the newAdmin will be able to accept the AccessControlDefaultAdminRules.defaultAdmin role\nby calling AccessControlDefaultAdminRules.acceptDefaultAdminTransfer, completing the role transfer.A zero value only in acceptSchedule indicates no pending admin transfer.A zero address newAdmin means that AccessControlDefaultAdminRules.defaultAdmin is being renounced.\n\ndefaultAdminDelay() → uint48public#Returns the delay required to schedule the acceptance of a AccessControlDefaultAdminRules.defaultAdmin transfer started.This delay will be added to the current timestamp when calling AccessControlDefaultAdminRules.beginDefaultAdminTransfer to set\nthe acceptance schedule.If a delay change has been scheduled, it will take effect as soon as the schedule passes, making this\nfunction returns the new delay. See AccessControlDefaultAdminRules.changeDefaultAdminDelay.\n\npendingDefaultAdminDelay() → uint48 newDelay, uint48 schedulepublic#Returns a tuple of newDelay and an effect schedule.After the schedule passes, the newDelay will get into effect immediately for every\nnew AccessControlDefaultAdminRules.defaultAdmin transfer started with AccessControlDefaultAdminRules.beginDefaultAdminTransfer.A zero value only in effectSchedule indicates no pending delay change.A zero value only for newDelay means that the next AccessControlDefaultAdminRules.defaultAdminDelay\nwill be zero after the effect schedule.\n\ndefaultAdminDelayIncreaseWait() → uint48public#Maximum time in seconds for an increase to AccessControlDefaultAdminRules.defaultAdminDelay (that is scheduled using AccessControlDefaultAdminRules.changeDefaultAdminDelay)\nto take effect. Default to 5 days.When the AccessControlDefaultAdminRules.defaultAdminDelay is scheduled to be increased, it goes into effect after the new delay has passed with\nthe purpose of giving enough time for reverting any accidental change (i.e. using milliseconds instead of seconds)\nthat may lock the contract. However, to avoid excessive schedules, the wait is capped by this function and it can\nbe overridden for a custom AccessControlDefaultAdminRules.defaultAdminDelay increase scheduling.Make sure to add a reasonable amount of time while overriding this value, otherwise,\nthere's a risk of setting a high new delay that goes into effect almost immediately without the\npossibility of human intervention in the case of an input error (eg. set milliseconds instead of seconds).\n\nbeginDefaultAdminTransfer(address newAdmin)public#Starts a AccessControlDefaultAdminRules.defaultAdmin transfer by setting a AccessControlDefaultAdminRules.pendingDefaultAdmin scheduled for acceptance\nafter the current timestamp plus a AccessControlDefaultAdminRules.defaultAdminDelay.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nEmits a IAccessControlDefaultAdminRules.DefaultAdminTransferScheduled event.\n\n_beginDefaultAdminTransfer(address newAdmin)internal#See AccessControlDefaultAdminRules.beginDefaultAdminTransfer.Internal function without access restriction.\n\ncancelDefaultAdminTransfer()public#Cancels a AccessControlDefaultAdminRules.defaultAdmin transfer previously started with AccessControlDefaultAdminRules.beginDefaultAdminTransfer.A AccessControlDefaultAdminRules.pendingDefaultAdmin not yet accepted can also be cancelled with this function.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nMay emit a IAccessControlDefaultAdminRules.DefaultAdminTransferCanceled event.\n\n_cancelDefaultAdminTransfer()internal#See AccessControlDefaultAdminRules.cancelDefaultAdminTransfer.Internal function without access restriction.\n\nacceptDefaultAdminTransfer()public#Completes a AccessControlDefaultAdminRules.defaultAdmin transfer previously started with AccessControlDefaultAdminRules.beginDefaultAdminTransfer.After calling the function:\nDEFAULT_ADMIN_ROLE should be granted to the caller.\nDEFAULT_ADMIN_ROLE should be revoked from the previous holder.\nAccessControlDefaultAdminRules.pendingDefaultAdmin should be reset to zero values.\nRequirements:\nOnly can be called by the AccessControlDefaultAdminRules.pendingDefaultAdmin's newAdmin.\nThe AccessControlDefaultAdminRules.pendingDefaultAdmin's acceptSchedule should've passed.\n\n_acceptDefaultAdminTransfer()internal#See AccessControlDefaultAdminRules.acceptDefaultAdminTransfer.Internal function without access restriction.\n\nchangeDefaultAdminDelay(uint48 newDelay)public#Initiates a AccessControlDefaultAdminRules.defaultAdminDelay update by setting a AccessControlDefaultAdminRules.pendingDefaultAdminDelay scheduled for getting\ninto effect after the current timestamp plus a AccessControlDefaultAdminRules.defaultAdminDelay.This function guarantees that any call to AccessControlDefaultAdminRules.beginDefaultAdminTransfer done between the timestamp this\nmethod is called and the AccessControlDefaultAdminRules.pendingDefaultAdminDelay effect schedule will use the current AccessControlDefaultAdminRules.defaultAdminDelay\nset before calling.The AccessControlDefaultAdminRules.pendingDefaultAdminDelay's effect schedule is defined in a way that waiting until the schedule and then\ncalling AccessControlDefaultAdminRules.beginDefaultAdminTransfer with the new delay will take at least the same as another AccessControlDefaultAdminRules.defaultAdmin\ncomplete transfer (including acceptance).The schedule is designed for two scenarios:\nWhen the delay is changed for a larger one the schedule is block.timestamp + newDelay capped by\nAccessControlDefaultAdminRules.defaultAdminDelayIncreaseWait.\nWhen the delay is changed for a shorter one, the schedule is block.timestamp + (current delay - new delay).\nA AccessControlDefaultAdminRules.pendingDefaultAdminDelay that never got into effect will be canceled in favor of a new scheduled change.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nEmits a IAccessControlDefaultAdminRules.DefaultAdminDelayChangeScheduled event and may emit a IAccessControlDefaultAdminRules.DefaultAdminDelayChangeCanceled event.\n\n_changeDefaultAdminDelay(uint48 newDelay)internal#See AccessControlDefaultAdminRules.changeDefaultAdminDelay.Internal function without access restriction.\n\nrollbackDefaultAdminDelay()public#Cancels a scheduled AccessControlDefaultAdminRules.defaultAdminDelay change.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nMay emit a IAccessControlDefaultAdminRules.DefaultAdminDelayChangeCanceled event.\n\n_rollbackDefaultAdminDelay()internal#See AccessControlDefaultAdminRules.rollbackDefaultAdminDelay.Internal function without access restriction.\n\n_delayChangeWait(uint48 newDelay) → uint48internal#Returns the amount of seconds to wait after the newDelay will\nbecome the new AccessControlDefaultAdminRules.defaultAdminDelay.The value returned guarantees that if the delay is reduced, it will go into effect\nafter a wait that honors the previously set delay.See AccessControlDefaultAdminRules.defaultAdminDelayIncreaseWait.\n\nAccessControlEnumerable\nimport \"@openzeppelin/contracts/access/extensions/AccessControlEnumerable.sol\";\nExtension of AccessControl that allows enumerating the members of each role.\nFunctions\nsupportsInterface(interfaceId)\ngetRoleMember(role, index)\ngetRoleMemberCount(role)\ngetRoleMembers(role)\n_grantRole(role, account)\n_revokeRole(role, account)\nAccessControl\nhasRole(role, account)\n_checkRole(role)\n_checkRole(role, account)\ngetRoleAdmin(role)\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, callerConfirmation)\n_setRoleAdmin(role, adminRole)\nDEFAULT_ADMIN_ROLE()\n\nEventsIAccessControl\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nErrorsIAccessControl\nAccessControlUnauthorizedAccount(account, neededRole)\nAccessControlBadConfirmation()\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#\n\ngetRoleMember(bytes32 role, uint256 index) → addresspublic#Returns one of the accounts that have role. index must be a\nvalue between 0 and AccessControlEnumerable.getRoleMemberCount, non-inclusive.Role bearers are not sorted in any particular way, and their ordering may\nchange at any point.When using AccessControlEnumerable.getRoleMember and AccessControlEnumerable.getRoleMemberCount, make sure\nyou perform all queries on the same block. See the following\nforum post\nfor more information.\n\ngetRoleMemberCount(bytes32 role) → uint256public#Returns the number of accounts that have role. Can be used\ntogether with AccessControlEnumerable.getRoleMember to enumerate all bearers of a role.\n\ngetRoleMembers(bytes32 role) → address[]public#Return all accounts that have roleThis operation will copy the entire storage to memory, which can be quite expensive. This is designed\nto mostly be used by view accessors that are queried without any gas fees. Developers should keep in mind that\nthis function has an unbounded cost, and using it as part of a state-changing function may render the function\nuncallable if the set grows to a point where copying to memory consumes too much gas to fit in a block.\n\n_grantRole(bytes32 role, address account) → boolinternal#Overload AccessControl._grantRole to track enumerable memberships\n\n_revokeRole(bytes32 role, address account) → boolinternal#Overload AccessControl._revokeRole to track enumerable memberships\n\nIAccessControlDefaultAdminRules\nimport \"@openzeppelin/contracts/access/extensions/IAccessControlDefaultAdminRules.sol\";\nExternal interface of AccessControlDefaultAdminRules declared to support ERC-165 detection.\nFunctions\ndefaultAdmin()\npendingDefaultAdmin()\ndefaultAdminDelay()\npendingDefaultAdminDelay()\nbeginDefaultAdminTransfer(newAdmin)\ncancelDefaultAdminTransfer()\nacceptDefaultAdminTransfer()\nchangeDefaultAdminDelay(newDelay)\nrollbackDefaultAdminDelay()\ndefaultAdminDelayIncreaseWait()\nIAccessControl\nhasRole(role, account)\ngetRoleAdmin(role)\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, callerConfirmation)\n\nEvents\nDefaultAdminTransferScheduled(newAdmin, acceptSchedule)\nDefaultAdminTransferCanceled()\nDefaultAdminDelayChangeScheduled(newDelay, effectSchedule)\nDefaultAdminDelayChangeCanceled()\nIAccessControl\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nErrors\nAccessControlInvalidDefaultAdmin(defaultAdmin)\nAccessControlEnforcedDefaultAdminRules()\nAccessControlEnforcedDefaultAdminDelay(schedule)\nIAccessControl\nAccessControlUnauthorizedAccount(account, neededRole)\nAccessControlBadConfirmation()\n\ndefaultAdmin() → addressexternal#Returns the address of the current DEFAULT_ADMIN_ROLE holder.\n\npendingDefaultAdmin() → address newAdmin, uint48 acceptScheduleexternal#Returns a tuple of a newAdmin and an accept schedule.After the schedule passes, the newAdmin will be able to accept the AccessControlDefaultAdminRules.defaultAdmin role\nby calling AccessControlDefaultAdminRules.acceptDefaultAdminTransfer, completing the role transfer.A zero value only in acceptSchedule indicates no pending admin transfer.A zero address newAdmin means that AccessControlDefaultAdminRules.defaultAdmin is being renounced.\n\ndefaultAdminDelay() → uint48external#Returns the delay required to schedule the acceptance of a AccessControlDefaultAdminRules.defaultAdmin transfer started.This delay will be added to the current timestamp when calling AccessControlDefaultAdminRules.beginDefaultAdminTransfer to set\nthe acceptance schedule.If a delay change has been scheduled, it will take effect as soon as the schedule passes, making this\nfunction returns the new delay. See AccessControlDefaultAdminRules.changeDefaultAdminDelay.\n\npendingDefaultAdminDelay() → uint48 newDelay, uint48 effectScheduleexternal#Returns a tuple of newDelay and an effect schedule.After the schedule passes, the newDelay will get into effect immediately for every\nnew AccessControlDefaultAdminRules.defaultAdmin transfer started with AccessControlDefaultAdminRules.beginDefaultAdminTransfer.A zero value only in effectSchedule indicates no pending delay change.A zero value only for newDelay means that the next AccessControlDefaultAdminRules.defaultAdminDelay\nwill be zero after the effect schedule.\n\nbeginDefaultAdminTransfer(address newAdmin)external#Starts a AccessControlDefaultAdminRules.defaultAdmin transfer by setting a AccessControlDefaultAdminRules.pendingDefaultAdmin scheduled for acceptance\nafter the current timestamp plus a AccessControlDefaultAdminRules.defaultAdminDelay.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nEmits a IAccessControlDefaultAdminRules.DefaultAdminTransferScheduled event.\n\ncancelDefaultAdminTransfer()external#Cancels a AccessControlDefaultAdminRules.defaultAdmin transfer previously started with AccessControlDefaultAdminRules.beginDefaultAdminTransfer.A AccessControlDefaultAdminRules.pendingDefaultAdmin not yet accepted can also be cancelled with this function.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nMay emit a IAccessControlDefaultAdminRules.DefaultAdminTransferCanceled event.\n\nacceptDefaultAdminTransfer()external#Completes a AccessControlDefaultAdminRules.defaultAdmin transfer previously started with AccessControlDefaultAdminRules.beginDefaultAdminTransfer.After calling the function:\nDEFAULT_ADMIN_ROLE should be granted to the caller.\nDEFAULT_ADMIN_ROLE should be revoked from the previous holder.\nAccessControlDefaultAdminRules.pendingDefaultAdmin should be reset to zero values.\nRequirements:\nOnly can be called by the AccessControlDefaultAdminRules.pendingDefaultAdmin's newAdmin.\nThe AccessControlDefaultAdminRules.pendingDefaultAdmin's acceptSchedule should've passed.\n\nchangeDefaultAdminDelay(uint48 newDelay)external#Initiates a AccessControlDefaultAdminRules.defaultAdminDelay update by setting a AccessControlDefaultAdminRules.pendingDefaultAdminDelay scheduled for getting\ninto effect after the current timestamp plus a AccessControlDefaultAdminRules.defaultAdminDelay.This function guarantees that any call to AccessControlDefaultAdminRules.beginDefaultAdminTransfer done between the timestamp this\nmethod is called and the AccessControlDefaultAdminRules.pendingDefaultAdminDelay effect schedule will use the current AccessControlDefaultAdminRules.defaultAdminDelay\nset before calling.The AccessControlDefaultAdminRules.pendingDefaultAdminDelay's effect schedule is defined in a way that waiting until the schedule and then\ncalling AccessControlDefaultAdminRules.beginDefaultAdminTransfer with the new delay will take at least the same as another AccessControlDefaultAdminRules.defaultAdmin\ncomplete transfer (including acceptance).The schedule is designed for two scenarios:\nWhen the delay is changed for a larger one the schedule is block.timestamp + newDelay capped by\nAccessControlDefaultAdminRules.defaultAdminDelayIncreaseWait.\nWhen the delay is changed for a shorter one, the schedule is block.timestamp + (current delay - new delay).\nA AccessControlDefaultAdminRules.pendingDefaultAdminDelay that never got into effect will be canceled in favor of a new scheduled change.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nEmits a IAccessControlDefaultAdminRules.DefaultAdminDelayChangeScheduled event and may emit a IAccessControlDefaultAdminRules.DefaultAdminDelayChangeCanceled event.\n\nrollbackDefaultAdminDelay()external#Cancels a scheduled AccessControlDefaultAdminRules.defaultAdminDelay change.Requirements:\nOnly can be called by the current AccessControlDefaultAdminRules.defaultAdmin.\nMay emit a IAccessControlDefaultAdminRules.DefaultAdminDelayChangeCanceled event.\n\ndefaultAdminDelayIncreaseWait() → uint48external#Maximum time in seconds for an increase to AccessControlDefaultAdminRules.defaultAdminDelay (that is scheduled using AccessControlDefaultAdminRules.changeDefaultAdminDelay)\nto take effect. Default to 5 days.When the AccessControlDefaultAdminRules.defaultAdminDelay is scheduled to be increased, it goes into effect after the new delay has passed with\nthe purpose of giving enough time for reverting any accidental change (i.e. using milliseconds instead of seconds)\nthat may lock the contract. However, to avoid excessive schedules, the wait is capped by this function and it can\nbe overridden for a custom AccessControlDefaultAdminRules.defaultAdminDelay increase scheduling.Make sure to add a reasonable amount of time while overriding this value, otherwise,\nthere's a risk of setting a high new delay that goes into effect almost immediately without the\npossibility of human intervention in the case of an input error (eg. set milliseconds instead of seconds).\n\nDefaultAdminTransferScheduled(address indexed newAdmin, uint48 acceptSchedule)event#Emitted when a AccessControlDefaultAdminRules.defaultAdmin transfer is started, setting newAdmin as the next\naddress to become the AccessControlDefaultAdminRules.defaultAdmin by calling AccessControlDefaultAdminRules.acceptDefaultAdminTransfer only after acceptSchedule\npasses.\n\nDefaultAdminTransferCanceled()event#Emitted when a AccessControlDefaultAdminRules.pendingDefaultAdmin is reset if it was never accepted, regardless of its schedule.\n\nDefaultAdminDelayChangeScheduled(uint48 newDelay, uint48 effectSchedule)event#Emitted when a AccessControlDefaultAdminRules.defaultAdminDelay change is started, setting newDelay as the next\ndelay to be applied between default admin transfer after effectSchedule has passed.\n\nDefaultAdminDelayChangeCanceled()event#Emitted when a AccessControlDefaultAdminRules.pendingDefaultAdminDelay is reset if its schedule didn't pass.\n\nAccessControlInvalidDefaultAdmin(address defaultAdmin)error#The new default admin is not a valid default admin.\n\nAccessControlEnforcedDefaultAdminRules()error#At least one of the following rules was violated:\nThe DEFAULT_ADMIN_ROLE must only be managed by itself.\nThe DEFAULT_ADMIN_ROLE must only be held by one account at the time.\nAny DEFAULT_ADMIN_ROLE transfer must be in two delayed steps.\n\nAccessControlEnforcedDefaultAdminDelay(uint48 schedule)error#The delay for transferring the default admin delay is enforced and\nthe operation must wait until schedule.schedule can be 0 indicating there's no transfer scheduled.\n\nIAccessControlEnumerable\nimport \"@openzeppelin/contracts/access/extensions/IAccessControlEnumerable.sol\";\nExternal interface of AccessControlEnumerable declared to support ERC-165 detection.\nFunctions\ngetRoleMember(role, index)\ngetRoleMemberCount(role)\nIAccessControl\nhasRole(role, account)\ngetRoleAdmin(role)\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, callerConfirmation)\n\nEventsIAccessControl\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nErrorsIAccessControl\nAccessControlUnauthorizedAccount(account, neededRole)\nAccessControlBadConfirmation()\n\ngetRoleMember(bytes32 role, uint256 index) → addressexternal#Returns one of the accounts that have role. index must be a\nvalue between 0 and AccessControlEnumerable.getRoleMemberCount, non-inclusive.Role bearers are not sorted in any particular way, and their ordering may\nchange at any point.When using AccessControlEnumerable.getRoleMember and AccessControlEnumerable.getRoleMemberCount, make sure\nyou perform all queries on the same block. See the following\nforum post\nfor more information.\n\ngetRoleMemberCount(bytes32 role) → uint256external#Returns the number of accounts that have role. Can be used\ntogether with AccessControlEnumerable.getRoleMember to enumerate all bearers of a role.\n\nAccessManaged\nimport \"@openzeppelin/contracts/access/manager/AccessManaged.sol\";\nThis contract module makes available a AccessManaged.restricted modifier. Functions decorated with this modifier will be\npermissioned according to an \"authority\": a contract like AccessManager that follows the IAuthority interface,\nimplementing a policy that allows certain callers to access certain functions.\nThe restricted modifier should never be used on internal functions, judiciously used in public\nfunctions, and ideally only used in external functions. See AccessManaged.restricted.\nModifiers\nrestricted()\n\nFunctions\nconstructor(initialAuthority)\nauthority()\nsetAuthority(newAuthority)\nisConsumingScheduledOp()\n_setAuthority(newAuthority)\n_checkCanCall(caller, data)\n\nEventsIAccessManaged\nAuthorityUpdated(authority)\n\nErrorsIAccessManaged\nAccessManagedUnauthorized(caller)\nAccessManagedRequiredDelay(caller, delay)\nAccessManagedInvalidAuthority(authority)\n\nrestricted()internal#Restricts access to a function as defined by the connected Authority for this contract and the\ncaller and selector of the function that entered the contract.In general, this modifier should only be used on external functions. It is okay to use it on public\nfunctions that are used as external entry points and are not called internally. Unless you know what you're\ndoing, it should never be used on internal functions. Failure to follow these rules can have critical security\nimplications! This is because the permissions are determined by the function that entered the contract, i.e. the\nfunction at the bottom of the call stack, and not the function where the modifier is visible in the source code.Avoid adding this modifier to the receive()\nfunction or the fallback(). These\nfunctions are the only execution paths where a function selector cannot be unambiguously determined from the calldata\nsince the selector defaults to 0x00000000 in the receive() function and similarly in the fallback() function\nif no calldata is provided. (See AccessManaged._checkCanCall).The receive() function will always panic whereas the fallback() may panic depending on the calldata length.\n\nconstructor(address initialAuthority)internal#Initializes the contract connected to an initial authority.\n\nauthority() → addresspublic#Returns the current authority.\n\nsetAuthority(address newAuthority)public#Transfers control to a new authority. The caller must be the current authority.\n\nisConsumingScheduledOp() → bytes4public#Returns true only in the context of a delayed restricted call, at the moment that the scheduled operation is\nbeing consumed. Prevents denial of service for delayed restricted calls in the case that the contract performs\nattacker controlled calls.\n\n_setAuthority(address newAuthority)internal#Transfers control to a new authority. Internal function with no access restriction. Allows bypassing the\npermissions set by the current authority.\n\n_checkCanCall(address caller, bytes data)internal#Reverts if the caller is not allowed to call the function identified by a selector. Panics if the calldata\nis less than 4 bytes long.\n\nAccessManager\nimport \"@openzeppelin/contracts/access/manager/AccessManager.sol\";\nAccessManager is a central contract to store the permissions of a system.\nA smart contract under the control of an AccessManager instance is known as a target, and will inherit from the\nAccessManaged contract, be connected to this contract as its manager and implement the AccessManaged.restricted\nmodifier on a set of functions selected to be permissioned. Note that any function without this setup won't be\neffectively restricted.\nThe restriction rules for such functions are defined in terms of \"roles\" identified by an uint64 and scoped\nby target (address) and function selectors (bytes4). These roles are stored in this contract and can be\nconfigured by admins (ADMIN_ROLE members) after a delay (see AccessManager.getTargetAdminDelay).\nFor each target contract, admins can configure the following without any delay:\n\nThe target's AccessManaged.authority via AccessManager.updateAuthority.\nClose or open a target via AccessManager.setTargetClosed keeping the permissions intact.\nThe roles that are allowed (or disallowed) to call a given function (identified by its selector) through AccessManager.setTargetFunctionRole.\n\nBy default every address is member of the PUBLIC_ROLE and every target function is restricted to the ADMIN_ROLE until configured otherwise.\nAdditionally, each role has the following configuration options restricted to this manager's admins:\n\nA role's admin role via AccessManager.setRoleAdmin who can grant or revoke roles.\nA role's guardian role via AccessManager.setRoleGuardian who's allowed to cancel operations.\nA delay in which a role takes effect after being granted through AccessManager.setGrantDelay.\nA delay of any target's admin action via AccessManager.setTargetAdminDelay.\nA role label for discoverability purposes with AccessManager.labelRole.\n\nAny account can be added and removed into any number of these roles by using the AccessControl.grantRole and AccessControl.revokeRole functions\nrestricted to each role's admin (see AccessControl.getRoleAdmin).\nSince all the permissions of the managed system can be modified by the admins of this instance, it is expected that\nthey will be highly secured (e.g., a multisig or a well-configured DAO).\nThis contract implements a form of the IAuthority interface, but AccessManager.canCall has additional return data so it\ndoesn't inherit IAuthority. It is however compatible with the IAuthority interface since the first 32 bytes of\nthe return data are a boolean as expected by that interface.\nSystems that implement other access control mechanisms (for example using Ownable) can be paired with an\nAccessManager by transferring permissions (ownership in the case of Ownable) directly to the AccessManager.\nUsers will be able to interact with these contracts through the AccessManager.execute function, following the access rules\nregistered in the AccessManager. Keep in mind that in that context, the msg.sender seen by restricted functions\nwill be AccessManager itself.\nWhen granting permissions over an Ownable or AccessControl contract to an AccessManager, be very\nmindful of the danger associated with functions such as Ownable.renounceOwnership or\nAccessControl.renounceRole.\nModifiers\nonlyAuthorized()\n\nFunctions\nconstructor(initialAdmin)\ncanCall(caller, target, selector)\nexpiration()\nminSetback()\nisTargetClosed(target)\ngetTargetFunctionRole(target, selector)\ngetTargetAdminDelay(target)\ngetRoleAdmin(roleId)\ngetRoleGuardian(roleId)\ngetRoleGrantDelay(roleId)\ngetAccess(roleId, account)\nhasRole(roleId, account)\nlabelRole(roleId, label)\ngrantRole(roleId, account, executionDelay)\nrevokeRole(roleId, account)\nrenounceRole(roleId, callerConfirmation)\nsetRoleAdmin(roleId, admin)\nsetRoleGuardian(roleId, guardian)\nsetGrantDelay(roleId, newDelay)\n_grantRole(roleId, account, grantDelay, executionDelay)\n_revokeRole(roleId, account)\n_setRoleAdmin(roleId, admin)\n_setRoleGuardian(roleId, guardian)\n_setGrantDelay(roleId, newDelay)\nsetTargetFunctionRole(target, selectors, roleId)\n_setTargetFunctionRole(target, selector, roleId)\nsetTargetAdminDelay(target, newDelay)\n_setTargetAdminDelay(target, newDelay)\nsetTargetClosed(target, closed)\n_setTargetClosed(target, closed)\ngetSchedule(id)\ngetNonce(id)\nschedule(target, data, when)\nexecute(target, data)\ncancel(caller, target, data)\nconsumeScheduledOp(caller, data)\n_consumeScheduledOp(operationId)\nhashOperation(caller, target, data)\nupdateAuthority(target, newAuthority)\nADMIN_ROLE()\nPUBLIC_ROLE()\nMulticall\nmulticall(data)\n\nEventsIAccessManager\nOperationScheduled(operationId, nonce, schedule, caller, target, data)\nOperationExecuted(operationId, nonce)\nOperationCanceled(operationId, nonce)\nRoleLabel(roleId, label)\nRoleGranted(roleId, account, delay, since, newMember)\nRoleRevoked(roleId, account)\nRoleAdminChanged(roleId, admin)\nRoleGuardianChanged(roleId, guardian)\nRoleGrantDelayChanged(roleId, delay, since)\nTargetClosed(target, closed)\nTargetFunctionRoleUpdated(target, selector, roleId)\nTargetAdminDelayUpdated(target, delay, since)\n\nErrorsIAccessManager\nAccessManagerAlreadyScheduled(operationId)\nAccessManagerNotScheduled(operationId)\nAccessManagerNotReady(operationId)\nAccessManagerExpired(operationId)\nAccessManagerLockedRole(roleId)\nAccessManagerBadConfirmation()\nAccessManagerUnauthorizedAccount(msgsender, roleId)\nAccessManagerUnauthorizedCall(caller, target, selector)\nAccessManagerUnauthorizedConsume(target)\nAccessManagerUnauthorizedCancel(msgsender, caller, target, selector)\nAccessManagerInvalidInitialAdmin(initialAdmin)\n\nonlyAuthorized()internal#Check that the caller is authorized to perform the operation.\nSee AccessManager description for a detailed breakdown of the authorization logic.\n\nconstructor(address initialAdmin)public#\n\ncanCall(address caller, address target, bytes4 selector) → bool immediate, uint32 delaypublic#Check if an address (caller) is authorised to call a given function on a given contract directly (with\nno restriction). Additionally, it returns the delay needed to perform the call indirectly through the AccessManager.schedule\n& AccessManager.execute workflow.This function is usually called by the targeted contract to control immediate execution of restricted functions.\nTherefore we only return true if the call can be performed without any delay. If the call is subject to a\npreviously set delay (not zero), then the function should return false and the caller should schedule the operation\nfor future execution.If allowed is true, the delay can be disregarded and the operation can be immediately executed, otherwise\nthe operation can be executed if and only if delay is greater than 0.The IAuthority interface does not include the uint32 delay. This is an extension of that interface that\nis backward compatible. Some contracts may thus ignore the second return argument. In that case they will fail\nto identify the indirect workflow, and will consider calls that require a delay to be forbidden.This function does not report the permissions of the admin functions in the manager itself. These are defined by the\nAccessManager documentation.\n\nexpiration() → uint32public#Expiration delay for scheduled proposals. Defaults to 1 week.Avoid overriding the expiration with 0. Otherwise every contract proposal will be expired immediately,\ndisabling any scheduling usage.\n\nminSetback() → uint32public#Minimum setback for all delay updates, with the exception of execution delays. It\ncan be increased without setback (and reset via AccessControl.revokeRole in the event of an\naccidental increase). Defaults to 5 days.\n\nisTargetClosed(address target) → boolpublic#Get whether the contract is closed disabling any access. Otherwise role permissions are applied.When the manager itself is closed, admin functions are still accessible to avoid locking the contract.\n\ngetTargetFunctionRole(address target, bytes4 selector) → uint64public#Get the role required to call a function.\n\ngetTargetAdminDelay(address target) → uint32public#Get the admin delay for a target contract. Changes to contract configuration are subject to this delay.\n\ngetRoleAdmin(uint64 roleId) → uint64public#Get the id of the role that acts as an admin for the given role.The admin permission is required to grant the role, revoke the role and update the execution delay to execute\nan operation that is restricted to this role.\n\ngetRoleGuardian(uint64 roleId) → uint64public#Get the role that acts as a guardian for a given role.The guardian permission allows canceling operations that have been scheduled under the role.\n\ngetRoleGrantDelay(uint64 roleId) → uint32public#Get the role current grant delay.Its value may change at any point without an event emitted following a call to AccessManager.setGrantDelay.\nChanges to this value, including effect timepoint are notified in advance by the IAccessManager.RoleGrantDelayChanged event.\n\ngetAccess(uint64 roleId, address account) → uint48 since, uint32 currentDelay, uint32 pendingDelay, uint48 effectpublic#Get the access details for a given account for a given role. These details include the timepoint at which\nmembership becomes active, and the delay applied to all operations by this user that requires this permission\nlevel.Returns:\n[0] Timestamp at which the account membership becomes valid. 0 means role is not granted.\n[1] Current execution delay for the account.\n[2] Pending execution delay for the account.\n[3] Timestamp at which the pending execution delay will become active. 0 means no delay update is scheduled.\n\nhasRole(uint64 roleId, address account) → bool isMember, uint32 executionDelaypublic#Check if a given account currently has the permission level corresponding to a given role. Note that this\npermission might be associated with an execution delay. AccessManager.getAccess can provide more details.\n\nlabelRole(uint64 roleId, string label)public#Give a label to a role, for improved role discoverability by UIs.Requirements:\nthe caller must be a global admin\nroleId must not be the ADMIN_ROLE or PUBLIC_ROLE\nEmits a IAccessManager.RoleLabel event.\n\ngrantRole(uint64 roleId, address account, uint32 executionDelay)public#Add account to roleId, or change its execution delay.This gives the account the authorization to call any function that is restricted to this role. An optional\nexecution delay (in seconds) can be set. If that delay is non 0, the user is required to schedule any operation\nthat is restricted to members of this role. The user will only be able to execute the operation after the delay has\npassed, before it has expired. During this period, admin and guardians can cancel the operation (see AccessManager.cancel).If the account has already been granted this role, the execution delay will be updated. This update is not\nimmediate and follows the delay rules. For example, if a user currently has a delay of 3 hours, and this is\ncalled to reduce that delay to 1 hour, the new delay will take some time to take effect, enforcing that any\noperation executed in the 3 hours that follows this update was indeed scheduled before this update.Requirements:\nthe caller must be an admin for the role (see AccessControl.getRoleAdmin)\ngranted role must not be the PUBLIC_ROLE\nEmits a IAccessControl.RoleGranted event.\n\nrevokeRole(uint64 roleId, address account)public#Remove an account from a role, with immediate effect. If the account does not have the role, this call has\nno effect.Requirements:\nthe caller must be an admin for the role (see AccessControl.getRoleAdmin)\nrevoked role must not be the PUBLIC_ROLE\nEmits a IAccessControl.RoleRevoked event if the account had the role.\n\nrenounceRole(uint64 roleId, address callerConfirmation)public#Renounce role permissions for the calling account with immediate effect. If the sender is not in\nthe role this call has no effect.Requirements:\nthe caller must be callerConfirmation.\nEmits a IAccessControl.RoleRevoked event if the account had the role.\n\nsetRoleAdmin(uint64 roleId, uint64 admin)public#Change admin role for a given role.Requirements:\nthe caller must be a global admin\nroleId must not be the ADMIN_ROLE or PUBLIC_ROLE\nEmits a IAccessControl.RoleAdminChanged event\n\nsetRoleGuardian(uint64 roleId, uint64 guardian)public#Change guardian role for a given role.Requirements:\nthe caller must be a global admin\nroleId must not be the ADMIN_ROLE or PUBLIC_ROLE\nEmits a IAccessManager.RoleGuardianChanged event\n\nsetGrantDelay(uint64 roleId, uint32 newDelay)public#Update the delay for granting a roleId.Requirements:\nthe caller must be a global admin\nroleId must not be the PUBLIC_ROLE\nEmits a IAccessManager.RoleGrantDelayChanged event.\n\n_grantRole(uint64 roleId, address account, uint32 grantDelay, uint32 executionDelay) → boolinternal#Internal version of AccessControl.grantRole without access control. Returns true if the role was newly granted.Emits a IAccessControl.RoleGranted event.\n\n_revokeRole(uint64 roleId, address account) → boolinternal#Internal version of AccessControl.revokeRole without access control. This logic is also used by AccessControl.renounceRole.\nReturns true if the role was previously granted.Emits a IAccessControl.RoleRevoked event if the account had the role.\n\n_setRoleAdmin(uint64 roleId, uint64 admin)internal#Internal version of AccessManager.setRoleAdmin without access control.Emits a IAccessControl.RoleAdminChanged event.Setting the admin role as the PUBLIC_ROLE is allowed, but it will effectively allow\nanyone to set grant or revoke such role.\n\n_setRoleGuardian(uint64 roleId, uint64 guardian)internal#Internal version of AccessManager.setRoleGuardian without access control.Emits a IAccessManager.RoleGuardianChanged event.Setting the guardian role as the PUBLIC_ROLE is allowed, but it will effectively allow\nanyone to cancel any scheduled operation for such role.\n\n_setGrantDelay(uint64 roleId, uint32 newDelay)internal#Internal version of AccessManager.setGrantDelay without access control.Emits a IAccessManager.RoleGrantDelayChanged event.\n\nsetTargetFunctionRole(address target, bytes4[] selectors, uint64 roleId)public#Set the role required to call functions identified by the selectors in the target contract.Requirements:\nthe caller must be a global admin\nEmits a IAccessManager.TargetFunctionRoleUpdated event per selector.\n\n_setTargetFunctionRole(address target, bytes4 selector, uint64 roleId)internal#Internal version of AccessManager.setTargetFunctionRole without access control.Emits a IAccessManager.TargetFunctionRoleUpdated event.\n\nsetTargetAdminDelay(address target, uint32 newDelay)public#Set the delay for changing the configuration of a given target contract.Requirements:\nthe caller must be a global admin\nEmits a IAccessManager.TargetAdminDelayUpdated event.\n\n_setTargetAdminDelay(address target, uint32 newDelay)internal#Internal version of AccessManager.setTargetAdminDelay without access control.Emits a IAccessManager.TargetAdminDelayUpdated event.\n\nsetTargetClosed(address target, bool closed)public#Set the closed flag for a contract.Closing the manager itself won't disable access to admin methods to avoid locking the contract.Requirements:\nthe caller must be a global admin\nEmits a IAccessManager.TargetClosed event.\n\n_setTargetClosed(address target, bool closed)internal#Set the closed flag for a contract. This is an internal setter with no access restrictions.Emits a IAccessManager.TargetClosed event.\n\ngetSchedule(bytes32 id) → uint48public#Return the timepoint at which a scheduled operation will be ready for execution. This returns 0 if the\noperation is not yet scheduled, has expired, was executed, or was canceled.\n\ngetNonce(bytes32 id) → uint32public#Return the nonce for the latest scheduled operation with a given id. Returns 0 if the operation has never\nbeen scheduled.\n\nschedule(address target, bytes data, uint48 when) → bytes32 operationId, uint32 noncepublic#Schedule a delayed operation for future execution, and return the operation identifier. It is possible to\nchoose the timestamp at which the operation becomes executable as long as it satisfies the execution delays\nrequired for the caller. The special value zero will automatically set the earliest possible time.Returns the operationId that was scheduled. Since this value is a hash of the parameters, it can reoccur when\nthe same parameters are used; if this is relevant, the returned nonce can be used to uniquely identify this\nscheduled operation from other occurrences of the same operationId in invocations of AccessManager.execute and AccessManager.cancel.Emits a IAccessManager.OperationScheduled event.It is not possible to concurrently schedule more than one operation with the same target and data. If\nthis is necessary, a random byte can be appended to data to act as a salt that will be ignored by the target\ncontract if it is using standard Solidity ABI encoding.\n\nexecute(address target, bytes data) → uint32public#Execute a function that is delay restricted, provided it was properly scheduled beforehand, or the\nexecution delay is 0.Returns the nonce that identifies the previously scheduled operation that is executed, or 0 if the\noperation wasn't previously scheduled (if the caller doesn't have an execution delay).Emits an IAccessManager.OperationExecuted event only if the call was scheduled and delayed.\n\ncancel(address caller, address target, bytes data) → uint32public#Cancel a scheduled (delayed) operation. Returns the nonce that identifies the previously scheduled\noperation that is cancelled.Requirements:\nthe caller must be the proposer, a guardian of the targeted function, or a global admin\nEmits a IAccessManager.OperationCanceled event.\n\nconsumeScheduledOp(address caller, bytes data)public#Consume a scheduled operation targeting the caller. If such an operation exists, mark it as consumed\n(emit an IAccessManager.OperationExecuted event and clean the state). Otherwise, throw an error.This is useful for contracts that want to enforce that calls targeting them were scheduled on the manager,\nwith all the verifications that it implies.Emit a IAccessManager.OperationExecuted event.\n\n_consumeScheduledOp(bytes32 operationId) → uint32internal#Internal variant of AccessManager.consumeScheduledOp that operates on bytes32 operationId.Returns the nonce of the scheduled operation that is consumed.\n\nhashOperation(address caller, address target, bytes data) → bytes32public#Hashing function for delayed operations.\n\nupdateAuthority(address target, address newAuthority)public#Changes the authority of a target managed by this manager instance.Requirements:\nthe caller must be a global admin\n\nADMIN_ROLE() → uint64public#The identifier of the admin role. Required to perform most configuration operations including\nother roles' management and target restrictions.\n\nPUBLIC_ROLE() → uint64public#The identifier of the public role. Automatically granted to all addresses with no delay.\n\nAuthorityUtils\nimport \"@openzeppelin/contracts/access/manager/AuthorityUtils.sol\";\nFunctions\ncanCallWithDelay(authority, caller, target, selector)\n\ncanCallWithD","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791266956723,"hash":"b0426b7127ad70dd1606533418ecc43659984beb"}
{"url":"https://docs.optimism.io/op-stack/security/pause","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Normative spec: The pause mechanism is normatively defined in the Pause Mechanism specification. This page explains how the pause works in practice; it does not restate the spec.\nThe OptimismPortal is the low-level Layer 1 (L1) message passing contract present on all standard OP Stack chains.\nThis contract handles the L1 side of the communication channel between an OP Stack chain and its L1 parent chain.\nAs a safety mechanism, a privileged address called the Guardian can pause withdrawals.\nWhile withdrawals are paused, the OptimismPortal contract prevents Layer 2 (L2) to L1 transactions from being executed.\nThis backup safety mechanism helps mitigate active security concerns.\nThe OP Stack introduced pause functionality to mitigate the risk of withdrawal bugs that have led to exploits in other bridging systems.\nIf you run a centralized exchange, a third-party bridge, or any other service that manages assets on an OP Stack chain, see Security guidance for exchanges and bridges for how to monitor the pause and what to do when it is active.\n​Pause functionality\nThe OptimismPortal points to a SuperchainConfig smart contract, which holds the address of the Guardian that can pause and unpause L2-to-L1 transactions.\nThe SuperchainConfig contract is a shared implementation across OP Stack chains.\nAll Optimism-governed chains point to it, and any OP Stack chain can point its SuperchainConfigProxy to this shared implementation.\nL2-to-L1 transactions allow users and smart contracts on the OP Stack chain to send messages to the L1 parent chain.\nPause functionality allows the Guardian to halt L2-to-L1 transaction execution for the OP Stack chain in question.\nPause functionality does not affect L1-to-L2 transactions, and the L2 chain keeps processing transactions and producing blocks while withdrawals are paused.\nThe Guardian cannot target a pause to specific users, smart contracts, or transactions.\nPauses are designed as a backup safety mechanism for a suspected or confirmed security issue, and the Guardian can trigger one as a precaution before an issue is confirmed.\n​What a pause blocks\nWhile a chain is paused, the following actions revert on L1:\n\nProving and finalizing withdrawals in the OptimismPortal.\nRelaying messages through the L1CrossDomainMessenger.\nFinalizing ether and ERC-20 withdrawals through the L1StandardBridge, and ERC-721 withdrawals through the L1ERC721Bridge.\nUnlocking ETH from the ETHLockbox.\nWithdrawing dispute game bonds from DelayedWETH, and closing dispute games.\n\nA pause does not block deposits into the chain through the OptimismPortal or the bridges.\n​Global and chain-specific pauses\nThe Guardian chooses the scope of a pause with a pause identifier:\n\nThe zero address (address(0)) pauses every chain that uses the SuperchainConfig.\nA chain’s ETHLockbox address pauses only that chain, or the group of chains that share the ETHLockbox.\nA chain that does not have the ETH_LOCKBOX feature enabled on its SystemConfig uses its OptimismPortal address instead, even if its OptimismPortal has an ETHLockbox address set.\n\nA chain is paused when either its chain-specific pause or the global pause is active.\nTo check both at once, call paused() on the chain’s OptimismPortal or SystemConfig.\n​Pause expiry\nA pause expires automatically 7,884,000 seconds (about three months) after it is triggered.\nThe Guardian can extend an active pause, which restarts the three-month timer.\nOnce a pause expires, calling pause for the same identifier reverts until the Guardian resets it by calling unpause.\nThe Guardian can also restart an expired pause by calling extend.\n​Pause and unpause functions\nThe Guardian manages the pause through the following functions on the SuperchainConfig contract:\n\npause(address identifier) starts a pause for the identifier.\nunpause(address identifier) lifts a pause early and resets it so it can be used again.\nUnpausing a chain-specific identifier does not lift an active global pause.\nextend(address identifier) restarts the expiry timer of an active pause.\n\nAnyone can read the pause state with paused(address identifier) and expiration(address identifier).\npaused() with no arguments only reports the global pause.\nThe contract emits Paused(address identifier) when a pause starts or is extended, and Unpaused(address identifier) when it is lifted.\nFor more information, see the SuperchainConfig specification.\n​Guardian address\nThe SuperchainConfig contract stores the Guardian address, which is set when the contract is initialized and has no setter function.\nTo change it, the network’s administrative address or smart contract must upgrade the SuperchainConfig proxy and re-initialize it with a new Guardian address.\nFor more information, see Privileged roles in OP Stack chains.\n​Next steps\nPause functionality protects the OP Stack’s own bridge contracts.\nIt does not cover the security of centralized exchanges and third-party bridges, which remain open while the canonical bridge is paused.\n\nIf you operate an exchange or bridge, see Security guidance for exchanges and bridges to monitor the pause and stop moving assets to and from a paused chain.\nFor more information on all privileged roles, see Privileged roles in OP Stack chains.\nWas this page helpful?","tokens":1312,"squid":"ink-governance","role":"Council Listener","at":1791266965503,"hash":"dfd4481daaba51ff3297d2ba20be1198e6d8f861"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/changelog","domain":"docs.openzeppelin.com","title":"Changelog | OpenZeppelin Docs","text":"OpenZeppelin ContractsChangelogOpen in Claude\nv5.6.1 - 2026-02-27\n\nInteroperableAddress: Fix overflow in the parsing functions that caused silent misparse of large interoperable addresses. (#6372)\n\nChanges\n\nv5.6.0 - 2026-02-25\nBreaking changes\n\nStrings: The escapeJSON function now escapes all control characters in the range U+0000 to U+001F per RFC-4627. Previously only backspace, tab, newline, form feed, carriage return, double quote, and backslash were escaped. Input strings containing any other control character (e.g. null 0x00) or raw bytes in U+0001–U+001F will now produce different, longer output (e.g. \\u0000 for null). (#6344)\nERC1155: Performing batch transfers with exactly one id/value in the batch no-longer calls IERC1155Receiver.onERC1155Received. IERC1155Receiver.onERC1155BatchReceived is called instead (with arrays of length one). (#6170)\nERC1967Proxy and TransparentUpgradeableProxy: Mandate initialization during construction. Deployment now reverts with ERC1967ProxyUninitialized if an initialize call is not provided. Developers that rely on the previous behavior and want to disable this check can do so by overriding the internal _unsafeAllowUninitialized function to return true. (#5906)\nERC721 and ERC1155: Prevent setting an operator for address(0). In the case of ERC721 this type of operator allowance could lead to obfuscated mint permission. (#6171)\nRLP: The encode(bytes32) function now encodes bytes32 as a fixed size item and not as a scalar in encode(uint256). Users must replace calls to encode(bytes32) with encode(uint256(bytes32)) to preserve the same behavior. (#6167)\nERC4337Utils: The parseValidationData now returns a ValidationRange as the last return tuple value indicating whether the validationData is compared against a timestamp or block number. Developers must update their code to handle this new return value (e.g. (aggregator, validAfter, validUntil) -> (aggregator, validAfter, validUntil, range)). (#6215)\nSignerWebAuthn: The _rawSignatureValidation function now returns false when the signature is not a valid WebAuthn authentication assertion. P256 fallback is removed. Developers can add it back by overriding the function. (#6337)\nMemory: The setFreeMemoryPointer function is renamed to unsafeSetFreeMemoryPointer. Developers should use unsafeSetFreeMemoryPointer instead of setFreeMemoryPointer after v5.6.0. (#6348)\nMemory: Remove the asBytes32 and asPointer function to reduce the risk of mistakes when manipulating memory pointers. (#6340)\n\nChanges by category\nAccount\n\nAccount: Update default version of the ERC-4337 entrypoint to v0.9. (#6135)\nAccountERC7579: Do not revert and perform the uninstall if the onUninstall hook of a module reverts. (#6142)\nERC4337Utils: Added the paymasterSignature function to extract the signature in paymasterAndData after Entrypoint v0.9. Similarly, a variant of paymasterData that receives a flag to exclude the signature from the returned data. (#6215)\nERC4337Utils: Added variants of packValidationData(address,uint48,uint48) and packValidationData(bool,uint48,uint48) that receive a ValidationRange argument, could be timestamp or block number. Similarly, the parseValidationData now returns a ValidationRange too. (#6215)\n\nTokens\n\nERC1155: Introduce the _checkAuthorized internal virtual function to encapsulate isApprovedForAll and msg.sender == from checks. (#6133)\nERC1155: Call IERC1155Receiver.onERC1155BatchReceived when performing a batch transfers with exactly one id/value in the batch. (#6170)\nERC4626: Allow overriding underlying assets transfer mechanisms through new internal virtual functions (_transferIn and _transferOut). (#5970)\nERC721URIStorage: Add _suffixURI, an internal getter for retrieving the custom tokenURI without the base prefix. (#6175)\nAdd ERC-165 detection for the IERC6909ContentURI, IERC6909TokenSupply and IERC6909Metadata interfaces in the ERC6909ContentURI, ERC6909TokenSupply and ERC6909Metadata contracts respectively. (#6246) and (#6247)\n\nCross-chain\n\nBridgeFungible, BridgeERC20 and BridgeERC7802: Added bridge contracts to handle crosschain movements of ERC-20 (and ERC-7802) tokens. (#5914) (#6328)\nCrosschainLinked: Added a new helper contract to facilitate communication between a contract on one chain and counterparts on remote chains through ERC-7786 gateways. (#5914)\nERC20Crosschain: Added an ERC-20 extension to embed an ERC-7786 based crosschain bridge directly in the token contract. (#5914)\nInteroperableAddress: Reject inputs with both chain reference and addresses empty. (#6340)\n\nCryptography\n\nMessageHashUtils: Add helper functions to build EIP-712 domain typehash and separator with fields selectively enabled/disabled. (#5908)\nSignatureChecker: Add isValidERC1271SignatureNowCalldata, a variant of isValidERC1271SignatureNow that takes the signature from calldata. (#6123)\nTrieProof: Add library for verifying Ethereum Merkle-Patricia trie inclusion proofs. (#5826)\nWebAuthn: Verification now returns false instead of reverting when client data contains an out-of-bounds challengeIndex. (#6329)\n\nStructures\n\nAccumulator: Check that slices being added (shift or push) are in the reserved space. (#6302)\nDoubleEndedQueue: Add tryPushBack, tryPopBack, tryPushFront, tryPopFront, tryFront, tryBack, and tryAt function variants that do not revert. (#6020)\nEnumerableMap: Add support for Bytes4ToAddressMap types. (#6091)\nEnumerableSet: Add support for Bytes4Set type. (#6091)\n\nUtils\n\nArrays: Add replace functions enabling in-place array modification of address[], bytes32[] and uint256[] arrays, with new content from another array. (#5995)\nArrays: Add slice and splice functions for value types (uint256[], bytes32[], address[]). (#5965)\nBytes: Add replace functions that replaces a portion of a bytes buffer with content from another buffer. (#5995)\nBytes: Add the toNibbles function that expands the nibbles (4 bits chunk) of a bytes buffer. Used for manipulating Patricia Merkle Trees keys and paths. (#5826)\nMemory: Add a isReserved(Slice) function that checks if the memory occupied by the slice is reserved (i.e. before the free memory pointer). (#6302)\nRLP: Encode bytes32 as a fixed size item and not as a scalar in encode(bytes32). Scalar RLP encoding remains available by casting to a uint256 and using the encode(uint256) function. (#6167)\nRLP: Fix RLP encoding validity check when decoding long lists or strings (#6051)\nRLP: Perform a memory copy when decoding bytes objects containing a single byte instead of returning a reference to the input. (#6303)\n\nChanges\n\nv5.5.0 - 2025-10-31\nBug fixes\n\nAccountERC7579: Prevent revert in isModuleInstalled for fallback modules when additionalContext has fewer than 4 bytes. The function now returns false instead of reverting, ensuring ERC-7579 compliance. (#5961)\nERC165Checker: Ensure the supportsERC165 function returns false if the target reverts during the supportsInterface(0xffffffff) call. (#5810)\n\nBreaking changes\n\nAccount: Add signature argument to the internal _validateUserOp function for custom signature handling logic. Developers overriding it must now provide the signature from the user operation (i.e. userOp.signature) to keep compatibility. (#5976)\nAccountERC7579: Installing and uninstalling fallback modules now require the corresponding initData and deInitData arguments to be at least 4 bytes long (matching the selector to which the fallback module is registered). It now reverts with ERC7579CannotDecodeFallbackData instead of treating the missing bytes as 0x00. (#5974)\nERC6909 and its extensions (ERC6909ContentURI, ERC6909Metadata and ERC6909TokenSupply) are no longer marked as draft since EIP-6909 is now final. Developers must update the import paths. Contracts behavior is not modified. (#5929)\nSignerERC7702 is renamed as SignerEIP7702. Imports and inheritance must be updated to that new name and path. Behavior is unmodified. (#5932)\nERC721Holder, ERC1155Holder, ReentrancyGuard and ReentrancyGuardTransient are flagged as stateless and are no longer transpiled. Developers using their upgradeable variants from @openzeppelin/contracts-upgradeable must update their imports to use the equivalent version available in @openzeppelin/contracts. (#5944, #5942)\nUpdate minimum pragma to 0.8.24 in AccessControlEnumerable, Arrays, CircularBuffer, EIP712, EnumerableMap, EnumerableSet, ERC1155, ERC1155Burnable, ERC1155Pausable, ERC1155Supply, ERC1155URIStorage, ERC20Votes, ERC4626,ERC721Burnable, ERC721Consecutive, ERC721Enumerable, ERC721Pausable, ERC721Royalty, ERC721URIStorage, ERC721Votes, ERC721Wrapper, ERC7739, Heap, MerkleTree, MessageHashUtils, Strings, Votes and VotesExtended. (#5723, #5726, #5965)\n\nDeprecation\n\nInitializable and UUPSUpgradeable are no longer transpiled. An alias is present in the @openzeppelin/contracts-upgradeable package that redirect to the corresponding file in @openzeppelin/contracts. These alias will be removed in the next major release. Developers are advised to update their imports to get these files directly from the @openzeppelin/contracts package. #5941\nECDSA signature malleability protection is partly deprecated. See documentation for more details. #5814\n\nChanges by category\nTokens\n\nERC4626: compute maxWithdraw using maxRedeem and previewRedeem so that changes to the preview functions affect the max functions. (#5130)\n\nCross-chain\n\nInteroperableAddress: Add a library for formatting and parsing ERC-7930 interoperable addresses. (#5736)\nERC7786Recipient: Generic ERC-7786 cross-chain message recipient contract. (#5904)\nIERC7786: Add the (draft) interface for ERC-7786 \"Cross-Chain Messaging Gateway\" (#5737)\n\nCryptography\nSigners\n\nSignerWebAuthn: Add an abstract signer that verifies WebAuthn signatures, with a P256 fallback. (#5809)\nAdd constructors to the different signers. (#5757)\n\nVerifiers\n\nERC7913WebAuthnVerifier: Add an ERC-7913 verifier that verifies WebAuthn Authentication Assertions for P256 identities. (#5809)\n\nOther\n\nWebAuthn: Add a library for verifying WebAuthn Authentication Assertions. (#5809)\nECDSA: Add parse and parseCalldata to parse bytes signatures of length 65 or 64 (erc-2098) into its v,r,s components. (#5814)\nECDSA: Add recoverCalldata and tryRecoverCalldata, variants of recover and tryRecover that are more efficient when signatures are in calldata. (#5788)\nSignatureChecker: Add isValidSignatureNowCalldata(address,bytes32,bytes calldata) for efficient processing of calldata signatures. (#5788)\n\nStructures\n\nCheckpoints: Add a new checkpoint variant Checkpoint256 using uint256 type for the value and key. (#5748)\nAccumulators: A library for merging an arbitrary dynamic number of bytes buffers. (#5680)\n\nUtils\n\nArrays: Add slice and splice functions for value types (uint256[], bytes32[], address[]). (#5983)\nBase58: Add a library for encoding and decoding bytes buffers into base58 strings. (#5762)\nBase64: Add a new decode function that parses base64 encoded strings. (#5765)\nBytes: Add concat that merges a bytes[] array of buffers into a single bytes buffer. (#5882)\nBytes: Add reverseBytes32, reverseBytes16, reverseBytes8, reverseBytes4, and reverseBytes2 functions to reverse byte order for converting between little-endian and big-endian representations. (#5724)\nBytes: Add splice(bytes,uint256) and splice(bytes,uint256,uint256) functions that move a specified range of bytes to the start of the buffer and truncate it in place, as an alternative to slice. (#5733)\nBytes: Add a clz function to count the leading zero bits in a bytes buffer. (#5725)\nBytes: Add an equal function to compare byte buffers. (#5726)\nBytes: Fix lastIndexOf(bytes,byte,uint256) with empty buffers and finite position to correctly return type(uint256).max instead of accessing uninitialized memory sections. (#5797)\nIERC7751: Add the interface for custom error wrapping of bubbled up reverts. (#5816)\nLowLevelCall: Add a library to perform low-level calls and deal with the returndata more granularly. (#5094)\nMath: Add a clz function to count the leading zero bits in a uint256 value. (#5725)\nMemory: Add library with utilities to manipulate memory (#5189)\nMemory: Add a UDVT for handling slices on memory space similarly to calldata slices. (#5680)\nReentrancyGuard and ReentrancyGuardTransient: Add nonReentrantView, a read-only version of the nonReentrant modifier. (#5800)\nReentrancyGuard, ReentrancyGuardTransient: Add an internal _reentrancyGuardStorageSlot function allowing slot customization via override. (#5892)\nRelayedCall: Add a library to perform indirect calls through minimal and predictable relayers. (#5630)\nRLP: Add a library for encoding and decoding data in Ethereum's Recursive Length Prefix format. (#5680)\nStrings: Add toHexString(bytes). (#5761)\n\nChanges\n\nv5.4.0 - 2025-07-17\nBreaking changes\n\nUpdate minimum pragma to 0.8.24 in SignatureChecker, Governor and Governor's extensions. (#5716).\n\nPragma changes\n\nReduced pragma requirement of interface files\n\nChanges by category\nAccount\n\nAccount: Added a simple ERC-4337 account implementation with minimal logic to process user operations. (#5657)\nAccountERC7579: Extension of Account that implements support for ERC-7579 modules of type executor, validator, and fallback handler. (#5657)\nAccountERC7579Hooked: Extension of AccountERC7579 that implements support for ERC-7579 hook modules. (#5657)\nEIP7702Utils: Add a library for checking if an address has an EIP-7702 delegation in place. (#5587)\nIERC7821, ERC7821: Interface and logic for minimal batch execution. No support for additional opData is included. (#5657)\n\nGovernance\n\nGovernorNoncesKeyed: Extension of Governor that adds support for keyed nonces when voting by sig. (#5574)\n\nTokens\n\nERC20Bridgeable: Implementation of ERC-7802 that makes an ERC-20 compatible with crosschain bridges. (#5739)\n\nCryptography\nSigners\n\nAbstractSigner, SignerECDSA, SignerP256, and SignerRSA: Add an abstract contract and various implementations for contracts that deal with signature verification. (#5657)\nSignerERC7702: Implementation of AbstractSigner for Externally Owned Accounts (EOAs). Useful with ERC-7702. (#5657)\nSignerERC7913: Abstract signer that verifies signatures using the ERC-7913 workflow. (#5659)\nMultiSignerERC7913: Implementation of AbstractSigner that supports multiple ERC-7913 signers with a threshold-based signature verification system. (#5659)\nMultiSignerERC7913Weighted: Extension of MultiSignerERC7913 that supports assigning different weights to each signer, enabling more flexible governance schemes. (#5741)\n\nVerifiers\n\nERC7913P256Verifier and ERC7913RSAVerifier: Ready to use ERC-7913 verifiers that implement key verification for P256 (secp256r1) and RSA keys. (#5659)\n\nOther\n\nSignatureChecker: Add support for ERC-7913 signatures alongside existing ECDSA and ERC-1271 signature verification. (#5659)\nERC7739: An abstract contract to validate signatures following the rehashing scheme from ERC7739Utils. (#5664)\nERC7739Utils: Add a library that implements a defensive rehashing mechanism to prevent replayability of smart contract signatures based on the ERC-7739. (#5664)\n\nStructures\n\nEnumerableMap: Add support for BytesToBytesMap type. (#5658)\nEnumerableMap: Add keys(uint256,uint256) that returns a subset (slice) of the keys in the map. (#5713)\nEnumerableSet: Add support for StringSet and BytesSet types. (#5658)\nEnumerableSet: Add values(uint256,uint256) that returns a subset (slice) of the values in the set. (#5713)\n\nUtils\n\nArrays: Add unsafeAccess, unsafeMemoryAccess and unsafeSetLength for bytes[] and string[]. (#5568)\nBlockhash: Add a library that provides access to historical block hashes using EIP-2935's history storage, extending the standard 256-block limit to 8191 blocks. (#5642)\nBytes: Fix lastIndexOf(bytes,byte,uint256) with empty buffers and finite position to correctly return type(uint256).max instead of accessing uninitialized memory sections. (#5797)\n\nChanges\n\nv5.3.0 - 2025-04-09\nBreaking Changes\n\nReplace GovernorCountingOverridable.VoteReceipt struct parameter member names hasOverriden and overridenWeight for hasOverridden and overriddenWeight respectively.\n\nCustom error changes\n\nReplace GovernorAlreadyOverridenVote with GovernorAlreadyOverriddenVote.\nReplace GovernorOnlyProposer with GovernorUnableToCancel.\n\nChanges by category\nAccount\n\nERC4337Utils: Update the hash function to call getUserOpHash on the specified entrypoint and add an ENTRYPOINT_V08 constant. (#5614)\nERC7579Utils: Add ABI decoding checks on calldata bounds within decodeBatch. (#5371)\nERC7579Utils: Replace address(0) with address(this) during execution for calldata compression efficiency. (#5614)\n\nGovernance\n\nIGovernor: Add the getProposalId function to the governor interface. (#5290)\nGovernorProposalGuardian: Add a governance extension that defines a proposal guardian who can cancel proposals at any stage in their lifecycle. (#5303)\nGovernorSequentialProposalId: Adds a Governor extension that sequentially numbers proposal ids instead of using the hash. (#5290)\nGovernorSuperQuorum: Add a governance extension to support a super quorum. Proposals that meet the super quorum (and have a majority of for votes) advance to the Succeeded state before the proposal deadline. (#5526)\nGovernorVotesSuperQuorumFraction: Add a variant of the GovernorSuperQuorum extensions where the super quorum is expressed as a fraction of the total supply. (#5526)\nTimelockController: Receive function is now virtual. (#5509)\n\nStructures\n\nEnumerableSet: Add clear function to EnumerableSets which deletes all values in the set. (#5486)\nEnumerableMap: Add clear function to EnumerableMaps which deletes all entries in the map. (#5486)\nMerkleTree: Add an update function that replaces a previously inserted leaf with a new value, updating the tree root along the way. (#5526)\n\nTokens\n\nERC4626: Use the asset getter in totalAssets, _deposit and _withdraw. (#5322)\nIERC6909: Add the interface for ERC-6909. (#5343)\nERC6909: Add a standard implementation of ERC6909. (#5394)\nERC6909TokenSupply: Add an extension of ERC6909 which tracks total supply for each token id. (#5394)\nERC6909Metadata: Add an extension of ERC6909 which adds metadata functionality. (#5394)\nERC6909ContentURI: Add an extension of ERC6909 which adds content URI functionality. (#5394)\nSafeERC20: Add trySafeTransfer and trySafeTransferFrom that do not revert and return false if the transfer is not successful. (#5483)\n\nOther\n\nAddress: bubble up revert data on sendValue failed call. (#5379)\nCalldata: Library with emptyBytes and emptyString functions to generate empty bytes and string calldata types. (#5422)\nERC2771Forwarder: Expose the _isTrustedByTarget internal function to check whether a target trusts the forwarder. (#5416)\nHashes: Expose efficientKeccak256 for hashing non-commutative pairs of bytes32 without allocating extra memory. (#5442)\nInitializable: Add _initializableStorageSlot function that returns a pointer to the storage struct. The function allows customizing with a custom storage slot with an override. (#5526)\nMath: Add add512, mul512 and mulShr. (#5526)\nMath: Add saturating arithmetic operations saturatingAdd, saturatingSub and saturatingMul. (#5526)\nMessageHashUtils: Add toDataWithIntendedValidatorHash(address, bytes32). (#5526)\nP256: Adjust precompile detection in verifyNative to consider empty returndata on invalid verification. Previously, invalid signatures would've reverted with a MissingPrecompile error in chains with RIP-7212 support. (#5620)\nPausable: Stop explicitly setting paused to false during construction. (#5448)\nStrings: Add espaceJSON that escapes special characters in JSON strings. (#5526)\n\nChanges\n\nv5.2.0 - 2025-01-09\nBreaking Changes\nCustom error changes\nThis version comes with changes to the custom error identifiers. Contracts previously depending on the following errors should be replaced accordingly:\n\nReplace Errors.FailedCall with a bubbled-up revert reason in Address.sendValue.\n\nChanges by category\nGeneral\n\nUpdate some pragma directives to ensure that all file requirements match that of the files they import. (#5273)\n\nAccount\n\nERC4337Utils: Add a reusable library to manipulate user operations and interact with ERC-4337 contracts (#5274)\nERC7579Utils: Add a reusable library to interact with ERC-7579 modular accounts (#5274)\n\nGovernance\n\nGovernorCountingOverridable: Add a governor counting module that enables token holders to override the vote of their delegate. (#5192)\nVotesExtended: Create an extension of Votes which checkpoints balances and delegates. (#5192)\n\nProxy\n\nClones: Add cloneWithImmutableArgs and cloneDeterministicWithImmutableArgs variants that create clones with per-instance immutable arguments. The immutable arguments can be retrieved using fetchCloneArgs. The corresponding predictDeterministicWithImmutableArgs function is also included. (#5109)\n\nTokens\n\nERC1363Utils: Add helper similar to the existing ERC721Utils and ERC1155Utils (#5133)\n\nUtils\n\nAddress: bubble up revert data on sendValue failed call (#5418)\nBytes: Add a library of common operations that operate on bytes objects. (#5252)\nCAIP2 and CAIP10: Add libraries for formatting and parsing CAIP-2 and CAIP-10 identifiers. (#5252)\nNoncesKeyed: Add a variant of Nonces that implements the ERC-4337 entrypoint nonce system. (#5272)\nPacking: Add variants for packing bytes10 and bytes22 (#5274)\nStrings: Add parseUint, parseInt, parseHexUint and parseAddress to parse strings into numbers and addresses. Also provide variants of these functions that parse substrings, and tryXxx variants that do not revert on invalid input. (#5166)\n\nChanges\n\nv5.1.0 - 2024-10-23\nBreaking changes\n\nERC1967Utils: Removed duplicate declaration of the Upgraded, AdminChanged and BeaconUpgraded events. These events are still available through the IERC1967 interface located under the contracts/interfaces/ directory. Minimum pragma version is now 0.8.21.\nGovernor, GovernorCountingSimple: The _countVote virtual function now returns an uint256 with the total votes casted. This change allows for more flexibility for partial and fractional voting. Upgrading users may get a compilation error that can be fixed by adding a return statement to the _countVote function.\n\nCustom error changes\nThis version comes with changes to the custom error identifiers. Contracts previously depending on the following errors should be replaced accordingly:\n\nReplace Address.FailedInnerCall with Errors.FailedCall\nReplace Address.AddressInsufficientBalance with Errors.InsufficientBalance\nReplace Clones.Create2InsufficientBalance with Errors.InsufficientBalance\nReplace Clones.ERC1167FailedCreateClone with Errors.FailedDeployment\nReplace Clones.Create2FailedDeployment with Errors.FailedDeployment\nSafeERC20: Replace Address.AddressEmptyCode with SafeERC20FailedOperation if there is no code at the token's address.\nSafeERC20: Replace generic Error(string) with SafeERC20FailedOperation if the returned data can't be decoded as bool.\nSafeERC20: Replace generic SafeERC20FailedOperation with the revert message from the contract call if it fails.\n\nChanges by category\nGeneral\n\nAccessManager, VestingWallet, TimelockController and ERC2771Forwarder: Added a public initializer function in their corresponding upgradeable variants. (#5008)\n\nAccess\n\nAccessControlEnumerable: Add a getRoleMembers method to return all accounts that have role. (#4546)\nAccessManager: Allow the onlyAuthorized modifier to restrict functions added to the manager. (#5014)\n\nFinance\n\nVestingWalletCliff: Add an extension of the VestingWallet contract with an added cliff. (#4870)\n\nGovernance\n\nGovernorCountingFractional: Add a governor counting module that allows distributing voting power amongst 3 options (For, Against, Abstain). (#5045)\nVotes: Set _moveDelegateVotes visibility to internal instead of private. (#5007)\n\nProxy\n\nClones: Add version of clone and cloneDeterministic that support sending value at creation. (#4936)\nTransparentUpgradeableProxy: Make internal _proxyAdmin() getter have view visibility. (#4688)\nProxyAdmin: Fixed documentation for UPGRADE_INTERFACE_VERSION getter. (#5031)\n\nTokens\n\nERC1363: Add implementation of the token payable standard allowing execution of contract code after transfers and approvals. (#4631)\nERC20TemporaryApproval: Add an ERC-20 extension that implements temporary approval using transient storage, based on ERC7674 (draft). (#5071)\nSafeERC20: Add \"relaxed\" function for interacting with ERC-1363 functions in a way that is compatible with EOAs. (#4631)\nSafeERC20: Document risks of safeIncreaseAllowance and safeDecreaseAllowance when associated with ERC-7674. (#5262)\nERC721Utils and ERC1155Utils: Add reusable libraries with functions to perform acceptance checks on IERC721Receiver and IERC1155Receiver implementers. (#4845)\nERC1363Utils: Add helper similar to the existing ERC721Utils and ERC1155Utils. (#5133)\n\nUtils\n\nArrays: add a sort functions for address[], bytes32[] and uint256[] memory arrays. (#4846)\nArrays: add new functions lowerBound, upperBound, lowerBoundMemory and upperBoundMemory for lookups in sorted arrays with potential duplicates. (#4842)\nArrays: deprecate findUpperBound in favor of the new lowerBound. (#4842)\nBase64: Add encodeURL following section 5 of RFC4648 for URL encoding (#4822)\nComparator: A library of comparator functions, useful for customizing the behavior of the Heap structure. (#5084)\nCreate2: Bubbles up returndata from a deployed contract that reverted during construction. (#5052)\nCreate2, Clones: Mask computeAddress and cloneDeterministic outputs to produce a clean value for an address type (i.e. only use 20 bytes) (#4941)\nErrors: New library of common custom errors. (#4936)\nHashes: A library with commonly used hash functions. (#3617)\nPacking: Added a new utility for packing, extracting and replacing bytesXX values. (#4992)\nPanic: Add a library for reverting with panic codes. (#3298)\nReentrancyGuardTransient: Added a variant of ReentrancyGuard that uses transient storage. (#4988)\nStrings: Added a utility function for converting an address to checksummed string. (#5067)\nSlotDerivation: Add a library of methods for derivating common storage slots. (#4975)\nTransientSlot: Add primitives for operating on the transient storage space using a typed-slot representation. (#4980)\n\nCryptography\n\nSignatureChecker: refactor isValidSignatureNow to avoid validating ECDSA signatures if there is code deployed at the signer's address. (#4951)\nMerkleProof: Add variations of verify, processProof, multiProofVerify and processMultiProof (and equivalent calldata version) with support for custom hashing functions. (#4887)\nP256: Library for verification and public key recovery of P256 (aka secp256r1) signatures. (#4881)\nRSA: Library to verify signatures according to RFC 8017 Signature Verification Operation (#4952)\n\nMath\n\nMath: add an invMod function to get the modular multiplicative inverse of a number in Z/nZ. (#4839)\nMath: Add modExp function that exposes the EIP-198 precompile. Includes uint256 and bytes memory versions. (#3298)\nMath: Custom errors replaced with native panic codes. (#3298)\nMath, SignedMath: Add a branchless ternary function that computescond ? a : b in constant gas cost. (#4976)\nSafeCast: Add toUint(bool) for operating on bool values as uint256. (#4878)\n\nStructures\n\nCircularBuffer: Add a data structure that stores the last N values pushed to it. (#4913)\nDoubleEndedQueue: Custom errors replaced with native panic codes. (#4872)\nEnumerableMap: add UintToBytes32Map, AddressToAddressMap, AddressToBytes32Map and Bytes32ToAddressMap. (#4843)\nHeap: A data structure that implements a heap-based priority queue. (#5084)\nMerkleTree: A data structure that allows inserting elements into a merkle tree and updating its root hash. (#3617)\n\nChanges\n\nv5.0.2 - 2024-02-29\n\nBase64: Fix issue where dirty memory located just after the input buffer is affecting the result. (#4926)\n\nChanges\n\nv4.9.6 - 2024-02-29\n\nBase64: Fix issue where dirty memory located just after the input buffer is affecting the result. (#4929)\n\nChanges\n\nv4.9.5 - 2023-12-08\n\nMulticall: Make aware of non-canonical context (i.e. msg.sender is not _msgSender()), allowing compatibility with ERC2771Context. Patch duplicated Address.functionDelegateCall in v4.9.4 (removed).\n\nChanges\n\nv5.0.1 - 2023-12-07\n\nERC2771Context and Context: Introduce a _contextPrefixLength() getter, used to trim extra information appended to msg.data.\nMulticall: Make aware of non-canonical context (i.e. msg.sender is not _msgSender()), allowing compatibility with ERC2771Context.\n\nChanges\n\nv4.9.4 - 2023-12-07\n\nERC2771Context and Context: Introduce a _contextPrefixLength() getter, used to trim extra information appended to msg.data.\nMulticall: Make aware of non-canonical context (i.e. msg.sender is not _msgSender()), allowing compatibility with ERC2771Context.\n\nChanges\n\nv5.0.0 - 2023-10-05\nAdditions Summary\nThe following contracts and libraries were added:\n\nAccessManager: A consolidated system for managing access control in complex systems.\n\nAccessManaged: A module for connecting a contract to an authority in charge of its access control.\nGovernorTimelockAccess: An adapter for time-locking governance proposals using an AccessManager.\nAuthorityUtils: A library of utilities for interacting with authority contracts.\n\nGovernorStorage: A Governor module that stores proposal details in storage.\nERC2771Forwarder: An ERC2771 forwarder for meta transactions.\nERC1967Utils: A library with ERC1967 events, errors and getters.\nNonces: An abstraction for managing account nonces.\nMessageHashUtils: A library for producing digests for ECDSA operations.\nTime: A library with helpers for manipulating time-related objects.\n\nRemovals Summary\nThe following contracts, libraries, and functions were removed:\n\nAddress.isContract (because of its ambiguous nature and potential for misuse)\nCheckpoints.History\nCounters\nERC20Snapshot\nERC20VotesComp\nERC165Storage (in favor of inheritance based approach)\nERC777\nERC1820Implementer\nGovernorVotesComp\nGovernorProposalThreshold (deprecated since 4.4)\nPaymentSplitter\nPullPayment\nSafeMath\nSignedSafeMath\nTimers\nTokenTimelock (in favor of VestingWallet)\nAll escrow contracts (Escrow, ConditionalEscrow and RefundEscrow)\nAll cross-chain contracts, including AccessControlCrossChain and all the vendored bridge interfaces\nAll presets in favor of OpenZeppelin Contracts Wizard\n\nThese removals were implemented in the following PRs: #3637, #3880, #3945, #4258, #4276, #4289\nChanges by category\nGeneral\n\nReplaced revert strings and require statements with custom errors. (#4261)\nBumped minimum compiler version required to 0.8.20 (#4288)\nUse of abi.encodeCall in place of abi.encodeWithSelector and abi.encodeWithSignature for improved type-checking of parameters (#4293)\nReplaced some uses of abi.encodePacked with clearer alternatives (e.g. bytes.concat, string.concat). (#4504) (#4296)\nOverrides are now used internally for a number of functions that were previously hardcoded to their default implementation in certain locations: ERC1155Supply.totalSupply, ERC721.ownerOf, ERC721.balanceOf and ERC721.totalSupply in ERC721Enumerable, ERC20.totalSupply in ERC20FlashMint, and ERC1967._getImplementation in ERC1967Proxy. (#4299)\nRemoved the override specifier from functions that only override a single interface function. (#4315)\nSwitched to using explicit Solidity import statements. Some previously available symbols may now have to be separately imported. (#4399)\nGovernor, Initializable, and UUPSUpgradeable: Use internal functions in modifiers to optimize bytecode size. (#4472)\nUpgradeable contracts now use namespaced storage (EIP-7201). (#4534)\nUpgradeable contracts no longer transpile interfaces and libraries. (#4628)\n\nAccess\n\nOwnable: Added an initialOwner parameter to the constructor, making the ownership initialization explicit. (#4267)\nOwnable: Prevent using address(0) as the initial owner. (#4531)\nAccessControl: Added a boolean return value to the internal _grantRole and _revokeRole functions indicating whether the role was granted or revoked. (#4241)\naccess: Moved AccessControl extensions to a dedicated directory. (#4359)\nAccessManager: Added a new contract for managing access control of complex systems in a consolidated location. (#4121)\nAccessManager, AccessManaged, GovernorTimelockAccess: Ensure that calldata shorter than 4 bytes is not padded to 4 bytes. (#4624)\nAccessManager: Use named return parameters in functions that return multiple values. (#4624)\nAccessManager: Make schedule and execute more conservative when delay is 0. (#4644)\n\nFinance\n\nVestingWallet: Fixed revert during 1 second time window when duration is 0. (#4502)\nVestingWallet: Use Ownable instead of an immutable beneficiary. (#4508)\n\nGovernance\n\nGovernor: Optimized use of storage for proposal data (#4268)\nGovernor: Added validation in ERC1155 and ERC721 receiver hooks to ensure Governor is the executor. (#4314)\nGovernor: Refactored internals to implement common queuing logic in the core module of the Governor. Added queue and _queueOperations functions that act at different levels. Modules that implement queuing via timelocks are expected to override _queueOperations to implement the timelock-specific logic. Added _executeOperations as the equivalent for execution. (#4360)\nGovernor: Added voter and nonce parameters in signed ballots, to avoid forging signatures for random addresses, prevent signature replay, and allow invalidating signatures. Add voter as a new parameter in the castVoteBySig and castVoteWithReasonAndParamsBySig functions. (#4378)\nGovernor: Added support for casting votes with ERC-1271 signatures by using a bytes memory signature instead of r, s and v arguments in the castVoteBySig and castVoteWithReasonAndParamsBySig functions. (#4418)\nGovernor: Added a mechanism to restrict the address of the proposer using a suffix in the description.\nGovernorStorage: Added a new governor extension that stores the proposal details in storage, with an interface that operates on proposalId, as well as proposal enumerability. This replaces the old GovernorCompatibilityBravo module. (#4360)\nGovernorTimelockAccess: Added a module to connect a governor with an instance of AccessManager, allowing the governor to make calls that are delay-restricted by the manager using the normal queue workflow. (#4523)\nGovernorTimelockControl: Clean up timelock id on execution for gas refund. (#4118)\nGovernorTimelockControl: Added the Governor instance address as part of the TimelockController operation salt to avoid operation id collisions between governors using the same TimelockController. (#4432)\nTimelockController: Changed the role architecture to use DEFAULT_ADMIN_ROLE as the admin for all roles, instead of the bespoke TIMELOCK_ADMIN_ROLE that was used previously. This aligns with the general recommendation for AccessControl and makes the addition of new roles easier. Accordingly, the admin parameter and timelock will now be granted DEFAULT_ADMIN_ROLE instead of TIMELOCK_ADMIN_ROLE. (#3799)\nTimelockController: Added a state getter that returns an OperationState enum. (#4358)\nVotes: Use Trace208 for checkpoints. This enables EIP-6372 clock support for keys but reduces the max supported voting power to uint208. (#4539)\n\nMetatx\n\nERC2771Forwarder: Added deadline for expiring transactions, batching, and more secure handling of msg.value. (#4346)\nERC2771Context: Return the forwarder address whenever the msg.data of a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e. msg.data.length is less than 20 bytes), as specified by ERC-2771. (#4481)\nERC2771Context: Prevent revert in _msgData() when a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e. msg.data.length is less than 20 bytes). Return the full calldata in that case. (#4484)\n\nProxy\n\nProxyAdmin: Removed getProxyAdmin and getProxyImplementation getters. (#3820)\nTransparentUpgradeableProxy: Removed admin and implementation getters, which were only callable by the proxy owner and thus not very useful. (#3820)\nERC1967Utils: Refactored the ERC1967Upgrade abstract contract as a library. (#4325)\nTransparentUpgradeableProxy: Admin is now stored in an immutable variable (set during construction) to avoid unnecessary storage reads on every proxy call. This removed the ability to ever change the admin. Transfer of the upgrade capability is exclusively handled through the ownership of the ProxyAdmin. (#4354)\nMoved the logic to validate ERC-1822 during an upgrade from ERC1967Utils to UUPSUpgradeable. (#4356)\nUUPSUpgradeable, TransparentUpgradeableProxy and ProxyAdmin: Removed upgradeTo and upgrade functions, and made upgradeToAndCall and upgradeAndCall ignore the data argument if it is empty. It is no longer possible to invoke the receive function (or send value with empty data) along with an upgrade. (#4382)\nBeaconProxy: Reject value in initialization unless a payable function is explicitly invoked. (#4382)\nProxy: Removed redundant receive function. (#4434)\nBeaconProxy: Use an immutable variable to store the address of the beacon. It is no longer possible for a BeaconProxy to upgrade by changing to another beacon. (#4435)\nInitializable: Use the namespaced storage pattern to avoid putting critical variables in slot 0. Allow reinitializer versions greater than 256. (#4460)\nInitializable: Use intermediate variables to improve readability. (#4576)\n\nToken\n\nERC20, ERC721, ERC1155: Deleted _beforeTokenTransfer and _afterTokenTransfer hooks, added a new internal _update function for customizations, and refactored all extensions using those hooks to use _update instead. (#3838, #3876, #4377)\nERC20: Removed Approval event previously emitted in transferFrom to indicate that part of the allowance was consumed. With this change, allowances are no longer reconstructible from events. See the code for guidelines on how to re-enable this event if needed. (#4370)\nERC20: Removed the non-standard increaseAllowance and decreaseAllowance functions. (#4585)\nERC20Votes: Changed internal vote accounting to reusable Votes module previously used by ERC721Votes. Removed implicit ERC20Permit inheritance. Note that the DOMAIN_SEPARATOR getter was previously guaranteed to be available for ERC20Votes contracts, but is no longer available unless ERC20Permit is explicitly used; ERC-5267 support is included in ERC20Votes with EIP712 and is recommended as an alternative. (#3816)\nSafeERC20: Refactored safeDecreaseAllowance and safeIncreaseAllowance to support USDT-like tokens. (#4260)\nSafeERC20: Removed safePermit in favor of documentation-only permit recommendations. Based on recommendations from @trust1995 (#4582)\nERC721: _approve no longer allows approving the owner of the tokenId. (#4377) _setApprovalForAll no longer allows setting address(0) as an operator. (#4377)\nERC721: Renamed _requireMinted to _requireOwned and added a return value with the current owner. Implemented ownerOf in terms of _requireOwned. (#4566)\nERC721Consecutive: Added a _firstConsecutiveId internal function that can be overridden to change the id of the first token minted through _mintConsecutive. (#4097)\nERC721URIStorage: Allow setting the token URI prior to minting. (#4559)\nERC721URIStorage, ERC721Royalty: Stop resetting token-specific URI and royalties when burning. (#4561)\nERC1155: Optimized array allocation. (#4196)\nERC1155: Removed check for address zero in balanceOf. (#4263)\nERC1155: Optimized array accesses by skipping bounds checking when unnecessary. (#4300)\nERC1155: Bubble errors triggered in the onERC1155Received and onERC1155BatchReceived hooks. (#4314)\nERC1155Supply: Added a totalSupply() function that returns the total amount of token circulating, this change will restrict the total tokens minted across all ids to 2**256-1 . (#3962)\nERC1155Receiver: Removed in favor of ERC1155Holder. (#4450)\n\nUtils\n\nAddress: Removed the ability to customize error messages. A common custom error is always used if the underlying revert reason cannot be bubbled up. (#4502)\nArrays: Added unsafeMemoryAccess helpers to read from a memory array without checking the length. (#4300)\nArrays: Optimized findUpperBound by removing redundant SLOAD. (#4442)\nCheckpoints: Library moved from utils to utils/structs (#4275)\nDoubleEndedQueue: Refactored internal structure to use uint128 instead of int128. This has no effect on the library interface. (#4150)\nECDSA: Use unchecked arithmetic for the tryRecover function that receives the r and vs short-signature fields separately. (#4301)\nEIP712: Added internal getters for the name and version strings (#4303)\nMath: Makes ceilDiv to revert on 0 division even if the numerator is 0 (#4348)\nMath: Optimized stack operations in mulDiv. (#4494)\nMath: Renamed members of Rounding enum, and added a new rounding mode for \"away from zero\". (#4455)\nMerkleProof: Use custom error to report invalid multiproof instead of reverting with overflow panic. (#4564)\nMessageHashUtils: Added a new library for creating message digest to be used along with signing or recovery such as ECDSA or ERC-1271. These functions are moved from the ECDSA library. (#4430)\nNonces: Added a new contract to keep track of user nonces. Used for signatures in ERC20Permit, ERC20Votes, and ERC721Votes. (#3816)\nReentrancyGuard, Pausable: Moved to utils directory. (#4551)\nStrings: Renamed toString(int256) to toStringSigned(int256). (#4330)\nOptimized Strings.equal (#4262)\n\nHow to migrate from 4.x\nERC20, ERC721, and ERC1155\nThese breaking changes will require modifications to ERC20, ERC721, and ERC1155 contracts, since the _afterTokenTransfer and _beforeTokenTransfer functions were removed. Thus, any customization made through those hooks should now be done overriding the new _update function instead.\nMinting and burning are implemented by _update and customizations should be done by overriding this function as well. _transfer, _mint and _burn are no longer virtual (meaning they are not overridable) to guard against possible inconsistencies.\nFor example, a contract using ERC20's _beforeTokenTransfer hook would have to be changed in the following way.\n-function _beforeTokenTransfer(\n+function _update(\n address from,\n address to,\n uint256 amount\n ) internal virtual override {\n- super._beforeTokenTransfer(from, to, amount);\n require(!condition(), \"ERC20: wrong condition\");\n+ super._update(from, to, amount);\n }\nMore about ERC721\nIn the case of ERC721, the _update function does not include a from parameter, as the sender is implicitly the previous owner of the tokenId. The address of this previous owner is returned by the _update function, so it can be used for a posteriori checks. In addition to to and tokenId, a third parameter (auth) is present in this function. This parameter enabled an optional check that the caller/spender is approved to do the transfer. This check cannot be performed after the transfer (because the transfer resets the approval), and doing it before _update would require a duplicate call to _ownerOf.\nIn this logic of removing hidden SLOADs, the _isApprovedOrOwner function was removed in favor of a new _isAuthorized function. Overrides that used to target the _isApprovedOrOwner should now be performed on the _isAuthorized function. Calls to _isApprovedOrOwner that preceded a call to _transfer, _burn or _approve should be removed in favor of using the auth argument in _update and _approve. This is showcased in ERC721Burnable.burn and in ERC721Wrapper.withdrawTo.\nThe _exists function was removed. Calls to this function can be replaced by _ownerOf(tokenId) != address(0).\nMore about ERC1155\nBatch transfers will now emit TransferSingle if the batch consists of a single token, while in previous versions the TransferBatch event would be used for all transfers initiated through safeBatchTransferFrom. Both behaviors are compliant with the ERC-1155 specification.\nERC165Storage\nUsers that were registering EIP-165 interfaces with _registerInterface from ERC165Storage should instead do so so by overriding the supportsInterface function as seen below:\nfunction supportsInterface(bytes4 interfaceId) public view virtual override returns (bool) {\n return interfaceId == type(MyInterface).interfaceId || super.supportsInterface(interfaceId);\n}\nSafeMath\nMethods in SafeMath superseded by native overflow checks in Solidity 0.8.0 were removed along with operations providing an interface for revert strings. The remaining methods were moved to utils/Math.sol.\n- import \"@openzeppelin/contracts/utils/math/SafeMath.sol\";\n+ import \"@openzeppelin/contracts/utils/math/Math.sol\";\n\n function tryOperations(uint256 x, uint256 y) external view {\n- (bool overflowsAdd, uint256 resultAdd) = SafeMath.tryAdd(x, y);\n+ (bool overflowsAdd, uint256 resultAdd) = Math.tryAdd(x, y);\n- (bool overflowsSub, uint256 resultSub) = SafeMath.trySub(x, y);\n+ (bool overflowsSub, uint256 resultSub) = Math.trySub(x, y);\n- (bool overflowsMul, uint256 resultMul) = SafeMath.tryMul(x, y);\n+ (bool overflowsMul, uint256 resultMul) = Math.tryMul(x, y);\n- (bool overflowsDiv, uint256 resultDiv) = SafeMath.tryDiv(x, y);\n+ (bool overflowsDiv, uint256 resultDiv) = Math.tryDiv(x, y);\n // ...\n }\nAdapting Governor modules\nCustom Governor modules that override internal functions may require modifications if migrated to v5. In particular, the new internal functions _queueOperations and _executeOperations may need to be used. If assistance with this migration is needed reach out via the OpenZeppelin Support Forum.\nECDSA and MessageHashUtils\nThe ECDSA library is now focused on signer recovery. Previously it also included utility methods for producing digests to be used with signing or recovery. These utilities have been moved to the MessageHashUtils library and should be imported if needed:\n import {ECDSA} from \"@openzeppelin/contracts/utils/cryptography/ECDSA.sol\";\n+import {MessageHashUtils} from \"@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol\";\n\n contract Verifier {\n using ECDSA for bytes32;\n+ using MessageHashUtils for bytes32;\n\n function _verify(bytes32 data, bytes memory signature, address account) internal pure returns (bool) {\n return data\n .toEthSignedMessageHash()\n .recover(signature) == account;\n }\n }\nInterfaces and libraries in upgradeable contracts\nThe upgradeable version of the contracts library used to include a variant suffixed with Upgradeable for every contract. These variants, which are produced automatically, mainly include changes for dealing with storage that don't apply to libraries and interfaces.\nThe upgradeable library no longer includes upgradeable variants for libraries and interfaces. Projects migrating to 5.0 should replace their library and interface imports with their corresponding non-upgradeable version:\n // Libraries\n-import {AddressUpgradeable} from '@openzeppelin/contracts-upgradeable/utils/AddressUpgradeable.sol';\n+import {Address} from '@openzeppelin/contracts/utils/Address.sol';\n\n // Interfaces\n-import {IERC20Upgradeable} from '@openzeppelin/contracts-upgradeable/interfaces/IERC20.sol';\n+import {IERC20} from '@openzeppelin/contracts/interfaces/IERC20.sol';\nOffchain Considerations\nSome changes may affect offchain systems if they rely on assumptions that are changed along with these new breaking changes. These cases are:\nRelying on revert strings for processing errors\nA concrete example is AccessControl, where it was previously advised to catch revert reasons using the following regex:\n/^AccessControl: account (0x[0-9a-f]{40}) is missing role (0x[0-9a-f]{64})$/\nInstead, contracts now revert with custom errors. Systems that interact with smart contracts outside of the network should consider reliance on revert strings and possibly support the new custom errors.\nRelying on storage locations for retrieving data\nAfter 5.0, the storage location of some variables were changed. This is the case for Initializable and all the upgradeable contracts since they now use namespaced storaged locations. Any system relying on storage locations for retrieving data or detecting capabilities should be updated to support these new locations.\nChanges\n\nv4.9.3 - 2023-07-28\n\nNote\nThis release contains a fix for GHSA-g4vp-m682-qqmp.\n\nERC2771Context: Return the forwarder address whenever the msg.data of a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e. msg.data.length is less than 20 bytes), as specified by ERC-2771. (#4481)\nERC2771Context: Prevent revert in _msgData() when a call originating from a trusted forwarder is not long enough to contain the request signer address (i.e. msg.data.length is less than 20 bytes). Return the full calldata in that case. (#4484)\n\nChanges\n\nv4.9.2 - 2023-06-16\n\nNote\nThis release contains a fix for GHSA-wprv-93r4-jj2p.\n\nMerkleProof: Fix a bug in processMultiProof and processMultiProofCalldata that allows proving arbitrary leaves if the tree contains a node with value 0 at depth 1.\n\nChanges\n\nv4.9.1 - 2023-06-07\n\nNote\nThis release contains a fix for GHSA-5h3x-9wvq-w4m2.\n\nGovernor: Add a mechanism to restrict the address of the proposer using a suffix in the description.\n\nChanges\n\nv4.9.0 - 2023-05-23\n\nReentrancyGuard: Add a _reentrancyGuardEntered function to expose the guard status. (#3714)\nERC721Wrapper: add a new extension of the ERC721 token which wraps an underlying token. Deposit and withdraw guarantee that the ownership of each token is backed by a corresponding underlying token with the same identifier. (#3863)\nEnumerableMap: add a keys() function that returns an array containing all the keys. (#3920)\nGovernor: add a public cancel(uint256) function. (#3983)\nGovernor: Enable timestamp operation for blockchains without a stable block time. This is achieved by connecting a Governor's internal clock to match a voting token's EIP-6372 interface. (#3934)\nStrings: add equal method. (#3774)\nIERC5313: Add an interface for EIP-5313 that is now final. (#4013)\nIERC4906: Add an interface for ERC-4906 that is now Final. (#4012)\nStorageSlot: Add support for string and bytes. (#4008)\nVotes, ERC20Votes, ERC721Votes: support timestamp checkpointing using EIP-6372. (#3934)\nERC4626: Add mitigation to the inflation attack through virtual shares and assets. (#3979)\nStrings: add toString method for signed integers. (#3773)\nERC20Wrapper: Make the underlying variable private and add a public accessor. (#4029)\nEIP712: add EIP-5267 support for better domain discovery. (#3969)\nAccessControlDefaultAdminRules: Add an extension of AccessControl with additional security rules for the DEFAULT_ADMIN_ROLE. (#4009)\nSignatureChecker: Add isValidERC1271SignatureNow for checking a signature directly against a smart contract using ERC-1271. (#3932)\nSafeERC20: Add a forceApprove function to improve compatibility with tokens behaving like USDT. (#4067)\nERC1967Upgrade: removed contract-wide oz-upgrades-unsafe-allow delegatecall annotation, replaced by granular annotation in UUPSUpgradeable. (#3971)\nERC20Wrapper: self wrapping and deposit by the wrapper itself are now explicitly forbidden. (#4100)\nECDSA: optimize bytes32 computation by using assembly instead of abi.encodePacked. (#3853)\nERC721URIStorage: Emit ERC-4906 MetadataUpdate in _setTokenURI. (#4012)\nShortStrings: Added a library for handling short strings in a gas efficient way, with fallback to storage for longer strings. (#4023)\nSignatureChecker: Allow return data length greater than 32 from EIP-1271 signers. (#4038)\nUUPSUpgradeable: added granular oz-upgrades-unsafe-allow-reachable annotation to improve upgrade safety checks on latest version of the Upgrades Plugins (starting with @openzeppelin/upgrades-core@1.21.0). (#3971)\nInitializable: optimize _disableInitializers by using != instead of <. (#3787)\nOwnable2Step: make acceptOwnership public virtual to enable usecases that require overriding it. (#3960)\nUUPSUpgradeable.sol: Change visibility to the functions upgradeTo and upgradeToAndCall from external to public. (#3959)\nTimelockController: Add the CallSalt event to emit on operation schedule. (#4001)\nReformatted codebase with latest version of Prettier Solidity. (#3898)\nMath: optimize log256 rounding check. (#3745)\nERC20Votes: optimize by using unchecked arithmetic. (#3748)\nMulticall: annotate multicall function as upgrade safe to not raise a flag for its delegatecall. (#3961)\nERC20Pausable, ERC721Pausable, ERC1155Pausable: Add note regarding missing public pausing functionality (#4007)\nECDSA: Add a function toDataWithIntendedValidatorHash that encodes data with version 0x00 following EIP-191. (#4063)\nMerkleProof: optimize by using unchecked arithmetic. (#3745)\n\nBreaking changes\n\nEIP712: Addition of ERC5267 support requires support for user defined value types, which was released in Solidity version 0.8.8. This requires a pragma change from ^0.8.0 to ^0.8.8.\nEIP712: Optimization of the cache for the upgradeable version affects the way name and version are set. This is no longer done through an initializer, and is instead part of the implementation's constructor. As a consequence, all proxies using the same implementation will necessarily share the same name and version. Additionally, an implementation upgrade risks changing the EIP712 domain unless the same name and version are used when deploying the new implementation contract.\n\nDeprecations\n\nERC20Permit: Added the file IERC20Permit.sol and ERC20Permit.sol and deprecated draft-IERC20Permit.sol and draft-ERC20Permit.sol since EIP-2612 is no longer a Draft. Developers are encouraged to update their imports. (#3793)\nTimers: The Timers library is now deprecated and will be removed in the next major release. (#4062)\nERC777: The ERC777 token standard is no longer supported by OpenZeppelin. Our implementation is now deprecated and will be removed in the next major release. The corresponding standard interfaces remain available. (#4066)\nERC1820Implementer: The ERC1820 pseudo-introspection mechanism is no longer supported by OpenZeppelin. Our implementation is now deprecated and will be removed in the next major release. The corresponding standard interfaces remain available. (#4066)\n\nChanges\n\nv4.8.3 - 2023-04-13\n\nNote\nThis release contains fixes for https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories/GHSA-mx2q-35m2-x2rh and https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories/GHSA-93hq-5wgc-jc82.\n\nGovernorCompatibilityBravo: Fix encoding of proposal data when signatures are missing.\nTransparentUpgradeableProxy: Fix transparency in case of selector clash with non-decodable calldata or payable mutability. (#4154)\n\nChanges\n\nv4.8.2 - 2023-03-02\n\nNote\nThis release contains a fix for https://github.com/OpenZeppelin/openzeppelin-contracts/security/advisories/GHSA-878m-3g6q-594q.\n\nERC721Consecutive: Fixed a bug when _mintConsecutive is used for batches of size 1 that could lead to balance overflow. Refer to the breaking changes section in the changelog for a note on the behavior of ERC721._beforeTokenTransfer.\n\nBreaking changes\n\nERC721: The internal function _beforeTokenTransfer no longer updates balances, which it previously did when batchSize was greater than 1. This change has no consequence unless a custom ERC721 extension is explicitly invoking _beforeTokenTransfer. Balance updates in extensions must now be done explicitly using __unsafe_increaseBalance, with a name that indicates that there is an invariant that has to be manually verified.\n\nChanges\n\nv4.8.1 - 2023-01-13\n\nERC4626: Use staticcall instead of call when fetching underlying ERC-20 decimals. (#3943)\n\nChanges\n\nv4.8.0 - 2022-11-08\n\nNote\nDon't miss the section on Breaking changes at the end.\n\nTimelockController: Added a new admin constructor parameter that is assigned the admin role instead of the deployer account. (#3722)\nInitializable: add internal functions _getInitializedVersion and _isInitializing (#3598)\nERC165Checker: add supportsERC165InterfaceUnchecked for consulting individual interfaces without the full ERC165 protocol. (#3339)\nAddress: optimize functionCall by calling functionCallWithValue directly. (#3468)\nAddress: optimize functionCall functions by checking contract size only if there is no returned data. (#3469)\nGovernor: make the relay function payable, and add support for EOA payments. (#3730)\nGovernorCompatibilityBravo: remove unused using statements. (#3506)\nERC20: optimize _transfer, _mint and _burn by using unchecked arithmetic when possible. (#3513)\nERC20Votes, ERC721Votes: optimize getPastVotes for looking up recent checkpoints. (#3673)\nERC20FlashMint: add an internal _flashFee function for overriding. (#3551)\nERC4626: use the same decimals() as the underlying asset by default (if available). (#3639)\nERC4626: add internal _initialConvertToShares and _initialConvertToAssets functions to customize empty vaults behavior. (#3639)\nERC721: optimize transfers by making approval clearing implicit instead of emitting an event. (#3481)\nERC721: optimize burn by making approval clearing implicit instead of emitting an event. (#3538)\nERC721: Fix balance accounting when a custom _beforeTokenTransfer hook results in a transfer of the token under consideration. (#3611)\nERC721: use unchecked arithmetic for balance updates. (#3524)\nERC721Consecutive: Implementation of EIP-2309 that allows batch minting of ERC721 tokens during construction. (#3311)\nReentrancyGuard: Reduce code size impact of the modifier by using internal functions. (#3515)\nSafeCast: optimize downcasting of signed integers. (#3565)\nECDSA: Remove redundant check on the v value. (#3591)\nVestingWallet: add releasable getters. (#3580)\nVestingWallet: remove unused library Math.sol. (#3605)\nVestingWallet: make constructor payable. (#3665)\nCreate2: optimize address computation by using assembly instead of abi.encodePacked. (#3600)\nClones: optimized the assembly to use only the scratch space during deployments, and optimized predictDeterministicAddress to use fewer operations. (#3640)\nCheckpoints: Use procedural generation to support multiple key/value lengths. (#3589)\nCheckpoints: Add new lookup mechanisms. (#3589)\nArrays: Add unsafeAccess functions that allow reading and writing to an element in a storage array bypassing Solidity's \"out-of-bounds\" check. (#3589)\nStrings: optimize toString. (#3573)\nOwnable2Step: extension of Ownable that makes the ownership transfers a two step process. (#3620)\nMath and SignedMath: optimize function max by using > instead of >=. (#3679)\nMath: Add log2, log10 and log256. (#3670)\nArbitrum: Update the vendored arbitrum contracts to match the nitro upgrade. (#3692)\n\nBreaking changes\n\nERC721: In order to add support for batch minting via ERC721Consecutive it was necessary to make a minor breaking change in the internal interface of ERC721. Namely, the hooks _beforeTokenTransfer and _afterTokenTransfer have one additional argument that may need to be added to overrides:\n\n function _beforeTokenTransfer(\n address from,\n address to,\n uint256 tokenId,\n+ uint256 batchSize\n ) internal virtual override\n\nERC4626: Conversion from shares to assets (and vice-versa) in an empty vault used to consider the possible mismatch between the underlying asset's and the vault's decimals. This initial conversion rate is now set to 1-to-1 irrespective of decimals, which are meant for usability purposes only. The vault now uses the assets decimals by default, so off-chain the numbers should appear the same. Developers overriding the vault decimals to a value that does not match the underlying asset may want to override the _initialConvertToShares and _initialConvertToAssets to replicate the previous behavior.\n\nTimelockController: During deployment, the TimelockController used to grant the TIMELOCK_ADMIN_ROLE to the deployer and to the timelock itself. The deployer was then expected to renounce this role once configuration of the timelock is over. Failing to renounce that role allows the deployer to change the timelock permissions (but not to bypass the delay for any time-locked action","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791266969490,"hash":"d42130b10777666375bea547b4657939bb6a4857"}
{"url":"https://docs.optimism.io/op-stack/security/exchanges-and-bridges","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This guide is for teams that move value off an OP Stack chain based on what happened on it, such as centralized exchanges, third-party bridges, liquidity networks, and custodians.\nIt covers two requirements that the protocol cannot enforce for you:\n\nOnly take off-chain actions, such as crediting a user’s incoming transfer or filling a bridge order, once the transaction is in a safe block, and wait for a finalized block for high-value actions.\nMonitor the chain’s withdrawal pause on Layer 1 (L1), and stop taking those off-chain actions like crediting a user’s account while the L2’s withdrawals are paused.\n\nThis guide uses “incoming transfers” for funds your users send to you on the OP Stack chain, and “outgoing transfers” for funds you send to the chain.\nIn OP Stack protocol terms, a deposit moves from L1 to Layer 2 (L2), and a withdrawal moves from L2 to L1.\n​Before you begin\nYou need the following to use the examples in this guide:\n\nAn OP Stack node that you operate, for each chain you support.\nFor detailed instructions, see Running a node with Docker or Building and running an OP Stack node from source.\nAn L1 remote procedure call (RPC) endpoint from a node you operate or a provider you trust.\nFoundry’s cast and jq installed locally.\n\n​Wait for safe blocks before acting off-chain\nCrediting an exchange balance, filling a bridge order, or releasing funds on another chain are hard to undo.\nIf the transaction you acted on is later removed from the chain because of a chain reorg, you may incur a loss.\nDepending on your risk tolerance and how high-value the action is, wait until that transaction is in a safe or finalized block before you act.\nThese confirmation levels describe the risk of a transaction being reordered or removed from the chain.\nSafe blocks can still be affected by L1 reorgs.\nNeither level establishes that the assets are legitimate or the chain is free of security issues.\n​Understand the risk of unsafe blocks\nAn unsafe block is the Sequencer’s claim about the chain.\nThe canonical chain is whatever OP Stack nodes derive from the batch data that the chain’s batcher posts to L1.\nAnyone who controls the batcher key can post batch data that omits or reorders transactions the Sequencer already shared as unsafe blocks.\nWhen a node derives a batch that does not match its unsafe chain, it reorgs the unsafe chain to match within minutes of the batch landing on L1.\nThe standard 12-hour sequencing window is only the upper bound for batch data to appear, not a grace period before a reorg.\nIf the data does not appear within the window, nodes derive the chain without those transactions, and they are dropped.\nIf you act on an unsafe block, an attacker holding the compromised batcher key can make a real transfer to you, get paid out, and then remove the transfer from the canonical chain.\nYou have no way to recover the funds through the protocol.\nFor more information, see Transaction finality.\n​Choose a confirmation level\nThe following table lists the minimum block tag to wait for, by type of action.\nActionMinimum block tagWhat you are trustingFilling a bridge order or crediting a low-value incoming transfersafeEthereum’s ordering. The L1 block can still reorg until it is finalizedCrediting a high-value incoming transfer or releasing high-value liquidityfinalizedEthereum’s consensus and finality guarantees\nWhere you draw the line between low and high value is a business decision.\nA reasonable starting point is the threshold you already use to decide how many confirmations to require on Ethereum itself, since safe carries the same L1 reorg risk as an unfinalized Ethereum block.\nOn OP Mainnet, transactions typically reach safe within a few minutes and finalized within about 15 to 30 minutes.\nChains that post batches less often take longer to reach safe.\nIf you act on unsafe blocks to offer faster service, you are fully trusting the chain operator’s Sequencer and batcher key for that value.\nCap the total value you have outstanding against unsafe blocks at an amount you can afford to lose.\n​Check that a transaction is safe\nUse the safe or finalized block tag with standard JSON-RPC methods.\nA transaction is safe when it succeeded, its block number is at or below the safe head, and its block is still the canonical block at that height.\nThe following script checks all three conditions.\nSave it as check-safe.sh, fill in the placeholders, and run it with bash check-safe.sh:\n#!/usr/bin/env bash\nL2_RPC=<your-l2-rpc>\nTX=<your-transaction-hash>\nTAG=safe # or finalized\n\nhead_number() {\n cast block $TAG --json --rpc-url $L2_RPC | jq -r .number | xargs cast to-dec\n}\n\nRECEIPT=$(cast receipt $TX --async --json --rpc-url $L2_RPC) || { echo \"not found\"; exit 1; }\nTX_STATUS=$(echo \"$RECEIPT\" | jq -r .status)\nTX_BLOCK=$(cast to-dec $(echo \"$RECEIPT\" | jq -r .blockNumber))\nTX_BLOCK_HASH=$(echo \"$RECEIPT\" | jq -r .blockHash)\n\nif [ \"$TX_STATUS\" != \"0x1\" ]; then\n echo \"failed\"\n exit 1\nfi\n\n# Read the head before and after the canonical hash, so a head that moves\n# backward during the check is caught.\nHEAD_BEFORE=$(head_number)\nCANONICAL_HASH=$(cast block $TX_BLOCK --json --rpc-url $L2_RPC | jq -r .hash)\nHEAD_AFTER=$(head_number)\n\nif [ \"$TX_BLOCK_HASH\" = \"$CANONICAL_HASH\" ] && [ \"$TX_BLOCK\" -le \"$HEAD_BEFORE\" ] && [ \"$TX_BLOCK\" -le \"$HEAD_AFTER\" ]; then\n echo \"$TAG\"\nelse\n echo \"not yet $TAG\"\n exit 1\nfi\n\nSet TAG=finalized for the stricter check.\nThe script exits with status 0 only when the transaction is safe (or finalized), so callers can gate on the exit code.\nIt reads the node several times, and an L1 reorg can move the safe head backward between reads while the transaction’s block stays canonical.\nReading the head on both sides of the canonical hash check means that case returns not yet safe instead of safe.\nThe result is still a point-in-time answer: a later L1 reorg can undo a safe result until the block is finalized.\nA safe status only tells you that L1 has fixed the transaction’s position on the chain.\nYou still need your usual checks on what the transaction did, such as decoding Ethereum Request for Comments 20 (ERC-20) Transfer logs.\nQuery a node you operate.\nThe node’s consensus client computes the safe and finalized heads from L1 data, so they are only as trustworthy as the node reporting them and the L1 RPC it reads from.\nA public or third-party RPC endpoint, including the chain operator’s own, asks you to trust whoever runs it.\nAlert when the safe head stops advancing.\nIf batches stop landing on L1, the safe head stalls and incoming transfers queue up without being credited.\nThat is the correct behavior, but your team should know when it happens.\n​Monitor the withdrawal pause\nEvery standard OP Stack chain has a Guardian that can pause withdrawals from the chain to L1.\nThe pause is recorded in the SuperchainConfig contract on L1, so its status is public and anyone can read it.\nIt can apply to one chain, to a group of chains that share an ETHLockbox, or to every chain that shares the same SuperchainConfig.\nFor more information, see Pausing the bridge.\n​Understand what a pause means for you\nA pause means the Guardian has stopped withdrawals through the canonical bridge because of a suspected or confirmed security issue.\nA pause can be precautionary, and it does not always mean funds are at risk.\nThe pause does not stop the L2 chain.\nBlocks keep being produced, transactions keep executing, and deposits from L1 keep arriving.\nIf an attacker has found a way to mint or steal assets on L2, the canonical bridge is closed to them, so your exchange or bridge becomes their way out.\n​Respond to a pause\nTake the following steps when a chain you support is paused:\n\nStop moving assets to and from the chain.\nExchanges should hold incoming transfers from the chain without crediting them, and stop processing outgoing transfers to it.\nBridges should stop filling orders that originate on the chain and stop sending funds to it.\nGet more information.\nCheck the chain’s status page, such as the OP Mainnet status page.\nResume deliberately.\nTreat resuming as a decision your team makes, not an automatic switch.\nConfirm that OptimismPortal.paused() returns false, and check the chain’s status page for guidance before you credit the transfers you held.\nDo not rely on an Unpaused event alone: a pause that expires emits no event, and lifting a chain-specific pause does not lift an active global pause.\n\nYou do not need to wait to be contacted before acting.\nThe pause status is the signal.\nIt is visible on L1 the moment the pause transaction lands, potentially before a public announcement is made.\n​Check the pause status\nCall paused() on the chain’s OptimismPortal proxy on L1.\nIt returns true when either the chain-specific pause or the global pause is active.\nThe following command checks one chain:\nL1_RPC=<your-l1-rpc>\nOPTIMISM_PORTAL=<optimism-portal-proxy-address>\n\ncast call $OPTIMISM_PORTAL \"paused()(bool)\" --rpc-url $L1_RPC\n\nFor OP Mainnet, use the OptimismPortal proxy address listed in OP Mainnet contract addresses.\nFor other chains, use the OptimismPortalProxy value from the chain’s configuration in the Superchain Registry.\nCheck every chain you support against the latest L1 block, at least once per L1 block (every 12 seconds).\nUse latest rather than safe or finalized for this check.\nYou’ll want the earliest possible signal.\nRead L1 from a node you operate or an L1 RPC provider you trust, for the same reason as on L2, because an RPC endpoint that lags or misreports can hide a pause from you.\nDo not call paused() with no arguments on the SuperchainConfig contract.\nThat function only reports the global pause and misses a pause that targets a single chain.\nOptimismPortal.paused() resolves the chain’s pause identifier for you.\n​Subscribe to pause events\nTo react faster than polling, watch the SuperchainConfig contract for the following events:\nevent Paused(address identifier);\nevent Unpaused(address identifier);\n\nThe identifier parameter is not indexed, so you cannot filter on it as a log topic.\nFilter on the event signature instead, and decode identifier from the log data.\nThe identifier tells you which chains the event applies to:\n\naddress(0) is the global pause and affects every chain that uses this SuperchainConfig.\nA chain’s own identifier depends on its contract version and configuration.\nIn contract releases v4.1.0 through v8.0.0, the identifier is the chain’s ETHLockbox address if the ETH_LOCKBOX feature is enabled on its SystemConfig, and its OptimismPortal address if it is not.\nA nonzero ethLockbox() on the OptimismPortal does not by itself mean the feature is enabled.\nCheck the feature with isFeatureEnabled(bytes32) on the SystemConfig, passing ETH_LOCKBOX encoded with cast format-bytes32-string ETH_LOCKBOX.\n\nWhichever identifier a chain uses, OptimismPortal.paused() resolves it for you and remains the check to rely on.\nRead the SuperchainConfig address with superchainConfig() on the OptimismPortal.\nThe contract also emits Paused when the Guardian extends an existing pause.\nUse events as a trigger to re-check, and keep polling OptimismPortal.paused() as the source of truth.\nPolling is required because a pause expires automatically about three months after it starts unless the Guardian extends it, and expiry does not emit an event.\npaused() accounts for expiry, so do not compute it yourself.\n​Check your integration\nConfirm that your integration meets each of the following conditions:\n\nOff-chain actions wait for safe, and high-value actions wait for finalized.\nSafe and finalized status comes from a node you operate, backed by an L1 RPC endpoint you trust.\nAny value you release on unsafe blocks has a cap.\nAn alert fires when the safe head stops advancing.\nOptimismPortal.paused() is polled for every supported chain on every L1 block.\nWhen a chain is paused, your systems automatically stop incoming and outgoing transfers for that chain and alert your on-call team.\nResuming after a pause is a manual decision.\n\n​Next steps\n\nFor more information on what a pause blocks and how the Guardian manages it, see Pausing the bridge.\nFor more information on the finality stages, see Transaction finality.\nFor the normative definition of the pause, see the Pause Mechanism specification.\nWas this page helpful?","tokens":3071,"squid":"ink-governance","role":"Council Listener","at":1791266975866,"hash":"d425d91ba42de57a1089563baddd98000848ac83"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc721","domain":"docs.openzeppelin.com","title":"ERC-721 | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensERC-721Open in ClaudeWe’ve discussed how you can make a fungible token using ERC-20, but what if not all tokens are alike? This comes up in situations like real estate, voting rights, or collectibles, where some items are valued more than others, due to their usefulness, rarity, etc. ERC-721 is a standard for representing ownership of non-fungible tokens, that is, where each token is unique.\nERC-721 is a more complex standard than ERC-20, with multiple optional extensions, and is split across a number of contracts. The OpenZeppelin Contracts provide flexibility regarding how these are combined, along with custom useful extensions. Check out the API Reference to learn more about these.\nConstructing an ERC-721 Token Contract\nWe’ll use ERC-721 to track items in our game, which will each have their own unique attributes. Whenever one is to be awarded to a player, it will be minted and sent to them. Players are free to keep their token or trade it with other people as they see fit, as they would any other asset on the blockchain! Please note that any account can call awardItem to mint items. To restrict what accounts can mint items we can add Access Control.\nHere’s what a contract for tokenized items might look like:\n// contracts/GameItem.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.24;\n\nimport {ERC721URIStorage, ERC721} from \"@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol\";\n\ncontract GameItem is ERC721URIStorage {\n uint256 private _nextTokenId;\n\n constructor() ERC721(\"GameItem\", \"ITM\") {}\n\n function awardItem(address player, string memory tokenURI) public returns (uint256) {\n uint256 tokenId = _nextTokenId++;\n _mint(player, tokenId);\n _setTokenURI(tokenId, tokenURI);\n\n return tokenId;\n }\n}\nThe ERC721URIStorage contract is an implementation of ERC-721 that includes the metadata standard extensions (IERC721Metadata) as well as a mechanism for per-token metadata. That’s where the _setTokenURI method comes from: we use it to store an item’s metadata.\nAlso note that, unlike ERC-20, ERC-721 lacks a decimals field, since each token is distinct and cannot be partitioned.\nNew items can be created:\n> gameItem.awardItem(playerAddress, \"https://game.example/item-id-8u5h2m.json\")\nTransaction successful. Transaction hash: 0x...\nEvents emitted:\n - Transfer(0x0000000000000000000000000000000000000000, playerAddress, 7)\nAnd the owner and metadata of each item queried:\n> gameItem.ownerOf(7)\nplayerAddress\n> gameItem.tokenURI(7)\n\"https://game.example/item-id-8u5h2m.json\"\nThis tokenURI should resolve to a JSON document that might look something like:\n{\n \"name\": \"Thor's hammer\",\n \"description\": \"Mjölnir, the legendary hammer of the Norse god of thunder.\",\n \"image\": \"https://game.example/item-id-8u5h2m.png\",\n \"strength\": 20\n}\nFor more information about the tokenURI metadata JSON Schema, check out the ERC-721 specification.\nYou’ll notice that the item’s information is included in the metadata, but that information isn’t on-chain! So a game developer could change the underlying metadata, changing the rules of the game!\nIf you’d like to put all item information on-chain, you can extend ERC-721 to do so (though it will be rather costly) by providing a Base64 Data URI with the JSON schema encoded. You could also leverage IPFS to store the tokenURI information, but these techniques are out of the scope of this overview guide.Creating SupplyPrevious PageERC-1155Next PageOn this pageConstructing an ERC-721 Token Contract","tokens":878,"squid":"ink-security_audits","role":"Sentinel","at":1791266984966,"hash":"8f2b1e033d8bad778487bd5c7eabb60a6a974bc4"}
{"url":"https://governance.aave.com/t/al-development-update-may-2026/25013","domain":"governance.aave.com","title":"AL Development Update | May 2026 - Development - Aave","text":"AL Development Update | May 2026 \n\n Development\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n rsETH Incident\n\n Aave Protocol\n\n Aave V4\n\n Aave V3\n\n What else are we working on?\n\n GHO\n\n Aave Horizon\n\n Aave Kit (SDK)\n\n Aave App\n\n Aave Pro\n\n Aave Interface\n\n CoW Adapters\n\n What’s coming next?\n\n Jun 1\n\n 1 / 2\n\n Jun 1\n\n Jun 1\n\n post by AaveLabs on Jun 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Greetings, Aave community!\nAave Labs has continued to make steady progress on multiple protocol endeavors in line with its service provider scope.\nThe below summary highlights developments in the Aave Protocol and reflects Aave Labs’ transparent and collaborative approach of building in public, welcoming community feedback, and fostering auditability through open-source principles.\nMay update:\n\nAdvanced the DeFi United rsETH recovery effort, including liquidations, collateral recovery, and lockbox refills.\n\nSupported Aave V4 growth past $100M in deposits and launched frxUSD and USDG incentives.\n\nCompleted Aave V4 SVR feed migration, CAPO updates, liquidator configuration work, and Blackthorn audit report publication.\n\nSupported Aave V3.7 Phase II and launched MegaETH incentives for USDe and USDM.\n\nContinued Aave Horizon development, with TVL surpassing $340M and SVR feed migration testing progressing.\n\nImproved Aave Kit SDK performance, reducing key API response times by up to 29x.\n\nProgressed Aave App launch readiness across banking, Stable Vault audit, and operational infrastructure.\n\nDelivered Aave Pro and Interface updates, including rewards, watch wallets, Markets, liquidations, sGHO, and governance UX.\n\nReduced swap costs by enabling 0% flash loan fees for CoW-routed Aave V3 swaps.\n\nrsETH Incident\nThe DeFi United recovery effort progressed across multiple fronts throughout May. The rsETH attacker positions on Arbitrum and Ethereum were liquidated by AIP#478, with the collateral transferred to the Recovery Guardian. A second phase of the recovery plan was published, outlining the next steps in the remediation process. In parallel, the Arbitrum AIP to release 30,000 ETH into the remediation effort reached quorum.\nWork on the rsETH recovery process remained ongoing throughout the month, with priority focused on completing remediation and operational steps on Ethereum and Arbitrum first. Aave fully restored ETH liquidity across affected deployments while keeping rsETH frozen as a precautionary measure. Liquidity levels continued to normalize throughout the recovery process, and rsETH lockbox refills were completed immediately following the liquidations to support the restoration effort. Remaining recovery work at month-end was focused on coordinated rsETH lockbox refills.\nAave Protocol\nAave Labs published an ARFC introducing a standardized Technical Asset Listing Framework, building on the Asset Classification and Assessment (ACAA) Framework. The framework proposes a consistent methodology for evaluating assets helping establish clearer requirements for asset onboarding and asset expansions discussions.\nAave V4\nAave V4 continued its growth trajectory throughout the month, surpassing its first major milestone of $100M in total deposits. As adoption increased, the DAO approved three successive increases to (add/draw) Caps, expanding market capacity to accommodate growing demand.\nAave Labs also activated the first incentive campaigns on V4, covering frxUSD and USDG. These campaigns represent the first targeted growth initiatives on the new architecture and are intended to support liquidity formation and user adoption during the early stages of the market.\nOn the infrastructure side, the migration to Chainlink SVR (Smart Value Recapture)-based price feeds was completed, alongside efforts to unify configuration setups for liquidators across all instances of Aave, facilitating more efficient liquidation operations, and CAPO price adapters were updated to refresh their parameters. SVR has become an increasingly important contributor to protocol revenue generation, producing approximately $5M in revenue for Aave during 2026 to date.\nSecurity and transparency remained a priority throughout the month. The Blackthorn audit report for Aave V4 was published publicly, providing additional visibility into the protocol’s security review process and audit findings.\nAave V3\nAave Labs continued supporting Aave V3 maintenance and governance activities throughout May. A significant portion of the team’s efforts during the month focused on restoring normal protocol operations and coordinating ecosystem response efforts following the rsETH incident.\nIn parallel, the BGD-authored AIP#489, supported by Aave Labs, completed the second phase of the Aave V3.7 upgrade across Aave Ethereum (Core and Prime), Polygon, Avalanche, Arbitrum, Base, BNB Chain, Linea, Plasma, and Mantle. Aave Labs reviewed the implementation, coordinated with ecosystem contributors, and monitored execution across all affected instances to ensure a smooth rollout.\nAave Labs also launched two incentive campaigns on Aave V3 MegaETH Market, distributed via Merkl. The campaigns introduced incentives for USDe and USDM markets, supporting early liquidity and user activity on the network.\nWhat else are we working on?\nGHO\nThe most significant GHO development during May was the launch of the upgraded sGHO savings product. Following the approval and activation of the corresponding governance proposal, the existing savings product was rebranded as StkGHO (legacy). Aave Labs supported @TokenLogic throughout the rollout by reviewing the implementation, coordinating integration efforts, and adding support for the new sGHO.\nAave Horizon\nAave Horizon continued to gain traction in May, surpassing $500M in TVL. The milestone reflects growing adoption of Horizon as Aave’s institutional-grade RWA lending product and further strengthens its position within the broader tokenized asset and institutional lending landscape.\nOn the development side, Aave Labs progressed engineering work related to Horizon’s migration from V3 price feeds to SVR-based feeds. Additional testing was completed during the month as part of the ongoing effort to improve oracle infrastructure and support the next phase of Horizon’s evolution.\nAave Kit (SDK)\nSignificant performance improvements have been rolled out to the underlying API powering Aave Kit SDK. Optimizations to commonly used queries have resulted in up to a 29x reduction in response times, delivering a faster and more responsive experience for developers and end users alike. These improvements benefit all applications built on Aave Kit, including Aave Pro.\nAave App\nUS production bank deposits are now fully operational, while EU pre-production bank deposits and withdrawals are also functioning successfully as testing and integration efforts continue. The Stable Vault has entered the final week of its audit process, bringing the product closer to deployment readiness.\nOn the operational side, the vault management infrastructure is now live and functioning as intended, and the balance protection policy has been activated to support user safeguards.\nThe launch timeline has been finalized, with the required budget allocated to support rollout activities. To keep the community informed and gather feedback, an Aave App launch ARFC is expected to be posted in the upcoming weeks.\nAave Pro\nRewards functionality has been launched on Aave Pro, with the first incentive campaigns now live and available to users. In addition, watch wallets functionality has been introduced, enabling users to monitor wallet activity and positions directly within the platform.\nAave Pro continued to receive product and usability improvements throughout the month. A new Markets view was launched, bringing a broad range of market data into a dedicated interface and making it easier for users to explore available markets and compare opportunities across the protocol. The first version of a liquidation activity feed was also shipped, allowing users to view their liquidation history directly within the application and providing greater visibility into account activity.\nIn parallel, a series of UI fast-follows were delivered to improve the overall user experience. These included consistent deposit APY ranges across wallet assets, displaying actual user APY on reserve pages instead of protocol rates, refining frozen asset warnings, improving contrast in the borrow asset picker, and enhancing table sorting behavior throughout the interface.\nAave Interface\nThe new sGHO experience went live. The dedicated sGHO page now displays both the legacy stkGHO and the new sGHO side by side, allowing users to compare positions and migrate between the two experiences seamlessly. Additionally, support for PT-USDG was added across the interface, completing the asset listing across the full application stack.\nGovernance-related UX improvements continued throughout the month. Proposal list views now surface voting outcomes directly, making it easier for users to track governance activity at a glance. Additional enhancements to proposal timelines are being designed and prepared for implementation, including clearer visibility into voting periods and expected execution timelines for proposals that are active or queued.\nCoW Adapters\nCoW adapter work during May focused on improving swap infrastructure and reducing execution costs for users. CoW Adapters were whitelisted as FlashBorrowers across Aave V3 markets. Enabled by the Aave Will Win (AWW) governance framework, this change allows collateral and position swaps routed through CoW Protocol on Aave V3 to benefit from 0% flash loan fees, improving execution quality and reducing swap costs across both app.aave.com and pro.aave.com.\nWhat’s coming next?\nOur main focus for the coming month will be\n\nComplete the rsETH recovery process and restore normal operations.\n\nContinue Aave App release efforts and share an updated timeline with the DAO.\n\nAdvance Aave V3 governance execution, including proposal coordination, parameter updates, and contributor proposal reviews.\n\nSupport GHO growth initiatives, including Plasma capacity increases and ongoing sGHO integration efforts.\n\nImprove Aave Pro onboarding and usability through an enhanced new-user experience and new market pages featuring activity and parameter details.\n\nContinue SDK and Interface enhancements, with a focus on developer migration, reserve data, and market lifecycle support.\n\nStay tuned for next month’s update.\nAave Labs\n\n read \n\n 4\n min\n\n post by ApuMallku on Jun 1\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n AL Development Update | April 2026\n\n Development\n\n 0\n\n 304\n\n May 1\n\n AL Development Update | July 2026\n\n Development\n\n 0\n\n 240\n\n Aug 14\n\n AL Development Update | August 2026\n\n Development\n\n 2\n\n 337\n\n Sep 1\n\n AL Development Update | February 2026\n\n Development\n\n 0\n\n 415\n\n Mar 2\n\n AL Development Update | June 2026\n\n Development\n\n 0\n\n 281\n\n Jul 1","tokens":2756,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791266997820,"hash":"af597e776a10f4886a2cf5efd2534ef80e83c8fc"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc4626","domain":"docs.openzeppelin.com","title":"ERC-4626 | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensERC-4626Open in ClaudeERC-4626 is an extension of ERC-20 that proposes a standard interface for token vaults. This standard interface can be used by widely different contracts (including lending markets, aggregators, and intrinsically interest bearing tokens), which brings a number of subtleties. Navigating these potential issues is essential to implementing a compliant and composable token vault.\nWe provide a base implementation of ERC-4626 that includes a simple vault. This contract is designed in a way that allows developers to easily re-configure the vault’s behavior, with minimal overrides, while staying compliant. In this guide, we will discuss some security considerations that affect ERC-4626. We will also discuss common customizations of the vault.\nSecurity concern: Inflation attack\nVisualizing the vault\nIn exchange for the assets deposited into an ERC-4626 vault, a user receives shares. These shares can later be burned to redeem the corresponding underlying assets. The number of shares a user gets depends on the amount of assets they put in and on the exchange rate of the vault. This exchange rate is defined by the current liquidity held by the vault.\n\nIf a vault has 100 tokens to back 200 shares, then each share is worth 0.5 assets.\nIf a vault has 200 tokens to back 100 shares, then each share is worth 2.0 assets.\n\nIn other words, the exchange rate can be defined as the slope of the line that passes through the origin and the current number of assets and shares in the vault. Deposits and withdrawals move the vault in this line.\n\nWhen plotted in log-log scale, the rate is defined similarly, but appears differently (because the point (0,0) is infinitely far away). Rates are represented by \"diagonal\" lines with different offsets.\n\nIn such a representation, widely different rates can be clearly visible in the same graph. This wouldn’t be the case in linear scale.\n\nThe attack\nWhen depositing tokens, the number of shares a user gets is rounded towards zero. This rounding takes away value from the user in favor of the vault (i.e. in favor of all the current shareholders). This rounding is often negligible because of the amount at stake. If you deposit 1e9 shares worth of tokens, the rounding will have you lose at most 0.0000001% of your deposit. However if you deposit 10 shares worth of tokens, you could lose 10% of your deposit. Even worse, if you deposit <1 share worth of tokens, then you get 0 shares, and you basically made a donation.\nFor a given amount of assets, the more shares you receive the safer you are. If you want to limit your losses to at most 1%, you need to receive at least 100 shares.\n\nIn the figure we can see that for a given deposit of 500 assets, the number of shares we get and the corresponding rounding losses depend on the exchange rate. If the exchange rate is that of the orange curve, we are getting less than a share, so we lose 100% of our deposit. However, if the exchange rate is that of the green curve, we get 5000 shares, which limits our rounding losses to at most 0.02%.\n\nSymmetrically, if we focus on limiting our losses to a maximum of 0.5%, we need to get at least 200 shares. With the green exchange rate that requires just 20 tokens, but with the orange rate that requires 200000 tokens.\nWe can clearly see that the blue and green curves correspond to vaults that are safer than the yellow and orange curves.\nThe idea of an inflation attack is that an attacker can donate assets to the vault to move the rate curve to the right, and make the vault unsafe.\n\nFigure 6 shows how an attacker can manipulate the rate of an empty vault. First the attacker must deposit a small amount of tokens (1 token) and follow up with a donation of 1e5 tokens directly to the vault to move the exchange rate \"right\". This puts the vault in a state where any deposit smaller than 1e5 would be completely lost to the vault. Given that the attacker is the only shareholder (from their donation), the attacker would steal all the tokens deposited.\nAn attacker would typically wait for a user to do the first deposit into the vault, and would frontrun that operation with the attack described above. The risk is low, and the size of the \"donation\" required to manipulate the vault is equivalent to the size of the deposit that is being attacked.\nIn math that gives:\n\na0a_0 the attacker deposit\na1a_1 the attacker donation\nuu the user deposit\n\n| |\n| --- | --- | --- | --- |\n| Assets | Shares | Rate | initial |\n| 00 | 00 | - | after attacker’s deposit |\n| a0a_0 | a0a_0 | 11 | after attacker’s donation |\nThis means a deposit of uu will give u×a0a0+a1\\frac{u \\times a_0}{a_0 + a_1} shares.\nFor the attacker to dilute that deposit to 0 shares, causing the user to lose all its deposit, it must ensure that\nu×a0a0+a1<1  ⟺  u<1+a1a0\\frac{u \\times a_0}{a_0+a_1} < 1 \\iff u < 1 + \\frac{a_1}{a_0}\n\nUsing a0=1a_0 = 1 and a1=ua_1 = u is enough. So the attacker only needs u+1u+1 assets to perform a successful attack.\nIt is easy to generalize the above results to scenarios where the attacker is going after a smaller fraction of the user’s deposit. In order to target un\\frac{u}{n}, the user needs to suffer rounding of a similar fraction, which means the user must receive at most nn shares. This results in:\nu×a0a0+a1<n  ⟺  un<1+a1a0\\frac{u \\times a_0}{a_0+a_1} < n \\iff \\frac{u}{n} < 1 + \\frac{a_1}{a_0}\n\nIn this scenario, the attack is nn times less powerful (in how much it is stealing) and costs nn times less to execute. In both cases, the amount of funds the attacker needs to commit is equivalent to its potential earnings.\nDefending with a virtual offset\nThe defense we propose is based on the approach used in YieldBox. It consists of two parts:\n\nUse an offset between the \"precision\" of the representation of shares and assets. Said otherwise, we use more decimal places to represent the shares than the underlying token does to represent the assets.\nInclude virtual shares and virtual assets in the exchange rate computation. These virtual assets enforce the conversion rate when the vault is empty.\n\nThese two parts work together in enforcing the security of the vault. First, the increased precision corresponds to a high rate, which we saw is safer as it reduces the rounding error when computing the amount of shares. Second, the virtual assets and shares (in addition to simplifying a lot of the computations) capture part of the donation, making it unprofitable for a developer to perform an attack.\nFollowing the previous math definitions, we have:\n\nδ\\delta the vault offset\na0a_0 the attacker deposit\na1a_1 the attacker donation\nuu the user deposit\n\n| |\n| --- | --- | --- | --- |\n| Assets | Shares | Rate | initial |\n| 11 | 10δ10^\\delta | 10δ10^\\delta | after attacker’s deposit |\n| 1+a01+a_0 | 10δ×(1+a0)10^\\delta \\times (1+a_0) | 10δ10^\\delta | after attacker’s donation |\nOne important thing to note is that the attacker only owns a fraction a01+a0\\frac{a_0}{1 + a_0} of the shares, so when doing the donation, he will only be able to recover that fraction a1×a01+a0\\frac{a_1 \\times a_0}{1 + a_0} of the donation. The remaining a11+a0\\frac{a_1}{1+a_0} are captured by the vault.\nloss=a11+a0\\mathit{loss} = \\frac{a_1}{1+a_0}\n\nWhen the user deposits uu, he receives\n10δ×u×1+a01+a0+a110^\\delta \\times u \\times \\frac{1+a_0}{1+a_0+a_1}\n\nFor the attacker to dilute that deposit to 0 shares, causing the user to lose all its deposit, it must ensure that\n10δ×u×1+a01+a0+a1<110^\\delta \\times u \\times \\frac{1+a_0}{1+a_0+a_1} < 1\n\n  ⟺  10δ×u<1+a0+a11+a0\\iff 10^\\delta \\times u < \\frac{1+a_0+a_1}{1+a_0}\n\n  ⟺  10δ×u<1+a11+a0\\iff 10^\\delta \\times u < 1 + \\frac{a_1}{1+a_0}\n\n  ⟺  10δ×u≤loss\\iff 10^\\delta \\times u \\le \\mathit{loss}\n\nIf the offset is 0, the attacker’s loss is at least equal to the user’s deposit.\nIf the offset is greater than 0, the attacker will have to suffer losses that are orders of magnitude bigger than the amount of value that can hypothetically be stolen from the user.\n\nThis shows that even with an offset of 0, the virtual shares and assets make this attack non profitable for the attacker. Bigger offsets increase the security even further by making any attack on the user extremely wasteful.\nThe following figure shows how the offset impacts the initial rate and limits the ability of an attacker with limited funds to inflate it effectively.\n\nδ=3\\delta = 3, a0=1a_0 = 1, a1=105a_1 = 10^5\n\nδ=3\\delta = 3, a0=100a_0 = 100, a1=105a_1 = 10^5\n\nδ=6\\delta = 6, a0=1a_0 = 1, a1=105a_1 = 10^5\nCustom behavior: Adding fees to the vault\nIn an ERC-4626 vaults, fees can be captured during the deposit/mint and/or during the withdraw/redeem steps. In both cases it is essential to remain compliant with the ERC-4626 requirements with regard to the preview functions.\nFor example, if calling deposit(100, receiver), the caller should deposit exactly 100 underlying tokens, including fees, and the receiver should receive a number of shares that matches the value returned by previewDeposit(100). Similarly, previewMint should account for the fees that the user will have to pay on top of share’s cost.\nAs for the Deposit event, while this is less clear in the EIP spec itself, there seems to be consensus that it should include the number of assets paid for by the user, including the fees.\nOn the other hand, when withdrawing assets, the number given by the user should correspond to what he receives. Any fees should be added to the quote (in shares) performed by previewWithdraw.\nThe Withdraw event should include the number of shares the user burns (including fees) and the number of assets the user actually receives (after fees are deducted).\nThe consequence of this design is that both the Deposit and Withdraw events will describe two exchange rates. The spread between the \"Buy-in\" and the \"Exit\" prices correspond to the fees taken by the vault.\nThe following example describes how fees proportional to the deposited/withdrawn amount can be implemented:\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.20;\n\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\nimport {ERC4626} from \"@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol\";\nimport {SafeERC20} from \"@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol\";\nimport {Math} from \"@openzeppelin/contracts/utils/math/Math.sol\";\n\n/// @dev ERC-4626 vault with entry/exit fees expressed in https://en.wikipedia.org/wiki/Basis_point[basis point (bp)].\n///\n/// NOTE: The contract charges fees in terms of assets, not shares. This means that the fees are calculated based on the\n/// amount of assets that are being deposited or withdrawn, and not based on the amount of shares that are being minted or\n/// redeemed. This is an opinionated design decision that should be taken into account when integrating this contract.\n///\n/// WARNING: This contract has not been audited and shouldn't be considered production ready. Consider using it with caution.\nabstract contract ERC4626Fees is ERC4626 {\n using Math for uint256;\n\n uint256 private constant _BASIS_POINT_SCALE = 1e4;\n\n // === Overrides ===\n\n /// @dev Preview taking an entry fee on deposit. See {IERC4626-previewDeposit}.\n function previewDeposit(uint256 assets) public view virtual override returns (uint256) {\n uint256 fee = _feeOnTotal(assets, _entryFeeBasisPoints());\n return super.previewDeposit(assets - fee);\n }\n\n /// @dev Preview adding an entry fee on mint. See {IERC4626-previewMint}.\n function previewMint(uint256 shares) public view virtual override returns (uint256) {\n uint256 assets = super.previewMint(shares);\n return assets + _feeOnRaw(assets, _entryFeeBasisPoints());\n }\n\n /// @dev Preview adding an exit fee on withdrawal. See {IERC4626-previewWithdraw}.\n function previewWithdraw(uint256 assets) public view virtual override returns (uint256) {\n uint256 fee = _feeOnRaw(assets, _exitFeeBasisPoints());\n return super.previewWithdraw(assets + fee);\n }\n\n /// @dev Preview taking an exit fee on redeem. See {IERC4626-previewRedeem}.\n function previewRedeem(uint256 shares) public view virtual override returns (uint256) {\n uint256 assets = super.previewRedeem(shares);\n return assets - _feeOnTotal(assets, _exitFeeBasisPoints());\n }\n\n /// @dev Send entry fee to {_entryFeeRecipient}. See {ERC4626-_deposit}.\n function _deposit(address caller, address receiver, uint256 assets, uint256 shares) internal virtual override {\n uint256 fee = _feeOnTotal(assets, _entryFeeBasisPoints());\n address recipient = _entryFeeRecipient();\n\n super._deposit(caller, receiver, assets, shares);\n\n if (fee > 0 && recipient != address(this)) {\n SafeERC20.safeTransfer(IERC20(asset()), recipient, fee);\n }\n }\n\n /// @dev Send exit fee to {_exitFeeRecipient}. See {ERC4626-_withdraw}.\n function _withdraw(\n address caller,\n address receiver,\n address owner,\n uint256 assets,\n uint256 shares\n ) internal virtual override {\n uint256 fee = _feeOnRaw(assets, _exitFeeBasisPoints());\n address recipient = _exitFeeRecipient();\n\n super._withdraw(caller, receiver, owner, assets, shares);\n\n if (fee > 0 && recipient != address(this)) {\n SafeERC20.safeTransfer(IERC20(asset()), recipient, fee);\n }\n }\n\n // === Fee configuration ===\n\n function _entryFeeBasisPoints() internal view virtual returns (uint256) {\n return 0; // replace with e.g. 100 for 1%\n }\n\n function _exitFeeBasisPoints() internal view virtual returns (uint256) {\n return 0; // replace with e.g. 100 for 1%\n }\n\n function _entryFeeRecipient() internal view virtual returns (address) {\n return address(0); // replace with e.g. a treasury address\n }\n\n function _exitFeeRecipient() internal view virtual returns (address) {\n return address(0); // replace with e.g. a treasury address\n }\n\n // === Fee operations ===\n\n /// @dev Calculates the fees that should be added to an amount `assets` that does not already include fees.\n /// Used in {IERC4626-mint} and {IERC4626-withdraw} operations.\n function _feeOnRaw(uint256 assets, uint256 feeBasisPoints) private pure returns (uint256) {\n return assets.mulDiv(feeBasisPoints, _BASIS_POINT_SCALE, Math.Rounding.Ceil);\n }\n\n /// @dev Calculates the fee part of an amount `assets` that already includes fees.\n /// Used in {IERC4626-deposit} and {IERC4626-redeem} operations.\n function _feeOnTotal(uint256 assets, uint256 feeBasisPoints) private pure returns (uint256) {\n return assets.mulDiv(feeBasisPoints, feeBasisPoints + _BASIS_POINT_SCALE, Math.Rounding.Ceil);\n }\n}ERC-1155Previous PageERC-6909Next PageOn this pageSecurity concern: Inflation attackVisualizing the vaultThe attackDefending with a virtual offsetCustom behavior: Adding fees to the vault","tokens":3652,"squid":"ink-security_audits","role":"Sentinel","at":1791267000125,"hash":"1dfaed1e653a61637ac64f671add087ba8b3639f"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc1155","domain":"docs.openzeppelin.com","title":"ERC-1155 | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensERC-1155Open in ClaudeERC-1155 is a novel token standard that aims to take the best from previous standards to create a fungibility-agnostic and gas-efficient token contract.\nERC-1155 draws ideas from all of ERC-20, ERC-721, and ERC-777. If you’re unfamiliar with those standards, head to their guides before moving on.\nMulti Token Standard\nThe distinctive feature of ERC-1155 is that it uses a single smart contract to represent multiple tokens at once. This is why its balanceOf function differs from ERC-20’s and ERC-777’s: it has an additional id argument for the identifier of the token that you want to query the balance of.\nThis is similar to how ERC-721 does things, but in that standard a token id has no concept of balance: each token is non-fungible and exists or doesn’t. The ERC-721 balanceOf function refers to how many different tokens an account has, not how many of each. On the other hand, in ERC-1155 accounts have a distinct balance for each token id, and non-fungible tokens are implemented by simply minting a single one of them.\nThis approach leads to massive gas savings for projects that require multiple tokens. Instead of deploying a new contract for each token type, a single ERC-1155 token contract can hold the entire system state, reducing deployment costs and complexity.\nBatch Operations\nBecause all state is held in a single contract, it is possible to operate over multiple tokens in a single transaction very efficiently. The standard provides two functions, balanceOfBatch and safeBatchTransferFrom, that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive.\nIn the spirit of the standard, we’ve also included batch operations in the non-standard functions, such as _mintBatch.\nConstructing an ERC-1155 Token Contract\nWe’ll use ERC-1155 to track multiple items in our game, which will each have their own unique attributes. We mint all items to the deployer of the contract, which we can later transfer to players. Players are free to keep their tokens or trade them with other people as they see fit, as they would any other asset on the blockchain!\nFor simplicity, we will mint all items in the constructor, but you could add minting functionality to the contract to mint on demand to players.\nFor an overview of minting mechanisms, check out Creating ERC-20 Supply.\nHere’s what a contract for tokenized items might look like:\n// contracts/GameItems.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {ERC1155} from \"@openzeppelin/contracts/token/ERC1155/ERC1155.sol\";\n\ncontract GameItems is ERC1155 {\n uint256 public constant GOLD = 0;\n uint256 public constant SILVER = 1;\n uint256 public constant THORS_HAMMER = 2;\n uint256 public constant SWORD = 3;\n uint256 public constant SHIELD = 4;\n\n constructor() ERC1155(\"https://game.example/api/item/{id}.json\") {\n _mint(msg.sender, GOLD, 10 ** 18, \"\");\n _mint(msg.sender, SILVER, 10 ** 27, \"\");\n _mint(msg.sender, THORS_HAMMER, 1, \"\");\n _mint(msg.sender, SWORD, 10 ** 9, \"\");\n _mint(msg.sender, SHIELD, 10 ** 9, \"\");\n }\n}\nNote that for our Game Items, Gold is a fungible token whilst Thor’s Hammer is a non-fungible token as we minted only one.\nThe ERC1155 contract includes the optional extension IERC1155MetadataURI. That’s where the uri function comes from: we use it to retrieve the metadata uri.\nAlso note that, unlike ERC-20, ERC-1155 lacks a decimals field, since each token is distinct and cannot be partitioned.\nOnce deployed, we will be able to query the deployer’s balance:\n> gameItems.balanceOf(deployerAddress,3)\n1000000000\nWe can transfer items to player accounts:\n> gameItems.safeTransferFrom(deployerAddress, playerAddress, 2, 1, \"0x0\")\n> gameItems.balanceOf(playerAddress, 2)\n1\n> gameItems.balanceOf(deployerAddress, 2)\n0\nWe can also batch transfer items to player accounts and get the balance of batches:\n> gameItems.safeBatchTransferFrom(deployerAddress, playerAddress, [0,1,3,4], [50,100,1,1], \"0x0\")\n> gameItems.balanceOfBatch([playerAddress,playerAddress,playerAddress,playerAddress,playerAddress], [0,1,2,3,4])\n[50,100,1,1,1]\nThe metadata uri can be obtained:\n> gameItems.uri(2)\n\"https://game.example/api/item/{id}.json\"\nThe uri can include the string id which clients must replace with the actual token ID, in lowercase hexadecimal (with no 0x prefix) and leading zero padded to 64 hex characters.\nFor token ID 2 and uri https://game.example/api/item/id.json clients would replace id with 0000000000000000000000000000000000000000000000000000000000000002 to retrieve JSON at https://game.example/api/item/0000000000000000000000000000000000000000000000000000000000000002.json.\nThe JSON document for token ID 2 might look something like:\n{\n \"name\": \"Thor's hammer\",\n \"description\": \"Mjölnir, the legendary hammer of the Norse god of thunder.\",\n \"image\": \"https://game.example/item-id-8u5h2m.png\",\n \"strength\": 20\n}\nFor more information about the metadata JSON Schema, check out the ERC-1155 Metadata URI JSON Schema.\nYou’ll notice that the item’s information is included in the metadata, but that information isn’t on-chain! So a game developer could change the underlying metadata, changing the rules of the game!\nIf you’d like to put all item information on-chain, you can override the uri() function in your ERC-1155 contract (or use ERC1155URIStorage) to return a Base64 Data URI with the JSON schema encoded, though it will be rather costly. You could also leverage IPFS to store the URI information, but these techniques are out of the scope of this overview guide\nSending Tokens to Contracts\nA key difference when using safeTransferFrom is that token transfers to other contracts may revert with the following custom error:\nERC1155InvalidReceiver(\"<ADDRESS>\")\nThis is a good thing! It means that the recipient contract has not registered itself as aware of the ERC-1155 protocol, so transfers to it are disabled to prevent tokens from being locked forever. As an example, the Golem contract currently holds over 350k GNT tokens, and lacks methods to get them out of there. This has happened to virtually every ERC20-backed project, usually due to user error.\nIn order for our contract to receive ERC-1155 tokens we can inherit from the convenience contract ERC1155Holder which handles the registering for us. However, we need to remember to implement functionality to allow tokens to be transferred out of our contract:\n// contracts/MyERC115HolderContract.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {ERC1155Holder} from \"@openzeppelin/contracts/token/ERC1155/utils/ERC1155Holder.sol\";\n\ncontract MyERC115HolderContract is ERC1155Holder {}\nWe can also implement more complex scenarios using the onERC1155Received and onERC1155BatchReceived functions.ERC-721Previous PageERC-4626Next PageOn this pageMulti Token StandardBatch OperationsConstructing an ERC-1155 Token ContractSending Tokens to Contracts","tokens":1732,"squid":"ink-security_audits","role":"Sentinel","at":1791267010205,"hash":"cec43d31ca3ca7ea1d11b3f3729da1c896e41f6a"}
{"url":"https://governance.aave.com/t/wrapped-liquid-staked-ether-2-0-wsteth-on-aave-monad-assessments/25262/2","domain":"governance.aave.com","title":"Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad Assessments - Risk / Assessments - Aave","text":"RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 1\n\n 2 / 2\n\n Jul 1\n\n Jul 1\n\n post by AaveLabs on Jul 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n This thread is the home for all risk and technical assessments of Wrapped liquid staked Ether 2.0 (wstETH) on Aave Monad.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 5\n min\n\n post by AaveLabs on Jul 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n [Asset Technical Assessment] wstETH on Aave V3 Monad\nAuthor: Aave Labs\nDate: 2026-06-30\n\nSummary\nTechnical assessment of wstETH (Wrapped liquid staked Ether) for onboarding to Aave V3 Monad, following the Technical Asset Listing Framework.\nOverall result: MEDIUM \nwstETH on Monad is a clean, standard ERC20 (OpenZeppelin AccessControl, 18 decimals, no fee on transfer, no rebase, no ERC777 or ERC1363 hooks) whose only mint and burn authority is a single Chainlink Cross-Chain Interoperability Protocol (CCIP) burn-and-mint token pool, with no externally owned account able to mint. On Monad wstETH is a bridged representation: the Monad supply exists only because canonical wstETH is locked on Ethereum, so the bridge’s governance, rate limits, and escrow accounting carry the listing. A live wstETH/USD market feed and a live wstETH/stETH exchange-rate feed are present on Monad alongside ETH/USD, so the asset is priceable, and the conditions that hold this at Medium are the bridge attestation, governance delay, and rate-limiter items described below.\nListing Recommendation\nFrom a technical standpoint, wstETH on Aave V3 Monad is technically eligible for listing, with conditions. Several non-blocking items are recommended for the issuer to address and to revisit as exposure to the asset grows: the governing timelock on both the Monad token and the bridge pools enforces only a 3-hour delay, below the 24-hour standard expected for upgrade and configuration changes; and the entire governance root is a single Chainlink-operated signer mesh (MCMS) that owns the token admin, the proxy admin, and the bridge pool, with no separation between bridge, token, and upgrade authority. None of these is a blocker.\nAsset under review\n\nField\nValue\n\nAsset\nWrapped liquid staked Ether (wstETH)\n\nTarget chain\nMonad (chain ID 143)\n\nTarget market\nAave V3 Monad\n\nToken contract\n0x10Aeaf63194db8d453d4D85a06E5eFE1dd0b5417\n\nNative to target chain?\nNo. wstETH on Monad is a bridged representation; the Monad token is minted and burned by a Chainlink CCIP burn-and-mint token pool, while canonical wstETH is escrowed on Ethereum.\n\nAAcA classification\nGroup 3 (yield-bearing, value-accruing liquid staking wrapper)\n\nwstETH is the non-rebasing wrapper of Lido’s staked ETH (stETH): a holder’s balance stays fixed while each token slowly becomes worth more stETH as staking rewards accrue. On its home chain, Ethereum, wstETH is the canonical token. On Monad it is a bridged representation: Chainlink’s Cross-Chain Token (CCT) framework over CCIP locks canonical wstETH on Ethereum and mints an equal amount on Monad, and sending it back burns the Monad token and releases the Ethereum escrow. There is no local staking or redemption on Monad, so the value and the exit path both depend on the Ethereum side and the bridge.\n0. Pre-screening\nwstETH is deployed on Monad at 0x10Aeaf63…5417 as a thin proxy carrying genuine contract code, reporting name “Wrapped liquid staked Ether 2.0”, symbol “wstETH”, 18 decimals, and a total supply of roughly 25,117 wstETH. It is classified Group 3 (yield-bearing wrapper) and is not in any non-approved or sanctioned category, and only one Monad token matches wstETH in official sources, confirmed on-chain because its bridge pool’s remote token on Ethereum resolves to canonical Lido wstETH. wstETH is listed on multiple live Aave V3 deployments on other chains, useful as a parameter reference for the same asset rather than as proof of this listing’s safety. The proxy, its implementation, and the bridge pool are source-verified on MonadScan as the standard Chainlink Cross-Chain Token contracts, with exact-match badges on the implementation and the pool.\nRating: GOOD \n1. ERC20 Compliance\nThe wstETH token on Monad is a standard OpenZeppelin 5.x ERC20 with 18 decimals: transfer() and approve() are declared returning bool and revert on invalid input with the OpenZeppelin custom errors, with no fee on transfer, no rebasing, no ERC777 or ERC1363 hooks, and no flash mint. There are no transfer restrictions and no allowlist or blocklist on the token, so smart contracts can hold and transfer it without restriction. The Monad token holds no Lido accounting (the exchange-rate getters revert on Monad), consistent with a bridged representation rather than the canonical Ethereum wrapper. The token implements ERC165 and OpenZeppelin AccessControl interfaces and exposes no EIP-2612 permit.\nRating: GOOD \n2. Oracle\nA live Chainlink wstETH/USD market feed exists on Monad with a fresh timestamp at review, a 3,600-second heartbeat, and a 0.05% deviation threshold. A live Chainlink wstETH/stETH exchange-rate feed is also present, matching the canonical Ethereum rate and driven by deviation under a 24-hour heartbeat, alongside live ETH/USD and stETH/USD feeds. Both pricing strategies are therefore available on Monad: a direct wstETH/USD market feed, or a Correlated-Asset Price Oracle (CAPO) composition of ETH/USD combined with the wstETH/stETH exchange rate. The elements for the composition are present, and it is the design already used to price wstETH on other Aave instances, so it may suit this listing as well.\nRating: GOOD \n3. Access Control\nAccess control uses standard OpenZeppelin AccessControl, with the token’s default admin role, the bridge CCIP admin, the proxy admin owner, and the bridge pool owner all held by the same OpenZeppelin TimelockController, and no externally owned account anywhere in the control path. The sole holder of the mint and burn roles is the CCIP token pool, so no externally owned account can mint and there is no permissionless path to burn from an arbitrary wallet, and the token carries no pause and no blocklist (pause exists only at the bridge layer and cannot block an on-Monad liquidation). The token sits behind an OpenZeppelin Transparent proxy whose admin is owned by that timelock, and the timelock’s getMinDelay() returns 10,800 seconds (3 hours), below the 24-hour bar, with the timelock governed by a Chainlink-operated signer mesh (MCMS). Concentrating the token admin, proxy admin, bridge pool owner, and CCIP admin on that single signer mesh removes separation between bridge, token, and upgrade authority.\nRating: MEDIUM → no externally owned account anywhere, but the 3-hour delay is below the 24-hour bar and the token admin, proxy admin, and bridge authority collapse onto a single governance root with no separation of duties.\n4. Exchange Rate and Yield\nwstETH is yield-bearing, so this section applies. The Monad token holds no Lido accounting, so the rate that matters for pricing comes from the live Chainlink wstETH/stETH exchange-rate feed on Monad, which tracks the canonical Ethereum rate set by Lido and cannot be moved by a donation or a flash loan in a single Monad transaction; the rate is monotonically non-decreasing under normal Lido operation and falls only on a net-negative validator event such as slashing, which would pass through to the Monad value. There is no native redemption on Monad: the exit paths are selling into a Monad decentralized exchange or bridging back to Ethereum (burn on Monad, release the Ethereum escrow, then unwrap and exit through Lido’s withdrawal queue), which is slow and rate-limited. A CAPO adapter is buildable from the live Monad feeds.\nRating: MEDIUM → the rate is verifiably not manipulable in a single transaction and is monotonic under normal conditions, but there is no native redemption on Monad and the on-chain decentralized exchange backstop is thin, so the liquidation path depends on exchange depth or a slow, rate-limited bridge round trip.\n5. Token Architecture\nSupply on Monad rises only through verified inbound CCIP mints and falls only through outbound burns, both gated to the bridge pool, with no fixed cap at the token level and standard Transfer events emitted from and to the zero address for observability. There are no transfer restrictions on the token, and the privileged functions (mint, burn, role grants) all sit behind AccessControl. The token logic contains no tx.origin authorization and no application-level delegatecall beyond the Transparent proxy’s own delegation to its fixed implementation. There is a single token address, a single implementation, and a single bridge pool resolved by the CCIP registry, with no migration contract or duplicate path to the same supply.\nRating: GOOD \n6. Bridge and Cross-Chain Risk\nMonad wstETH is a bridged representation that exists only because canonical wstETH is escrowed on Ethereum, bridged via Chainlink CCIP using the Cross-Chain Token standard: the Ethereum side locks and releases the canonical token in escrow, while the Monad side burns and mints the representation, over a single live route to Ethereum only (the Ink and Plasma routes documented elsewhere are not wired into the Monad pool). At assessment the Ethereum escrow held roughly 41,161 wstETH against a Monad supply of roughly 25,117 wstETH, so the Monad representation is fully backed with headroom, though that escrow is shared with other destination chains rather than dedicated to Monad. Inbound and outbound rate limiters are configured on both ends as refilling token buckets that refill to full over about 24 hours, with the inbound capacity (roughly 2,200 wstETH) capping the size of a single forged or erroneous inbound message. The route is governed by the 3-hour timelock and the single Chainlink-operated governance root noted in Section 3.\nRating: MEDIUM → standard, current CCIP with rate limiters set on both ends and Monad supply fully covered by Ethereum escrow, held at Medium by the 3-hour timelock below the 24-hour bar, shared rather than dedicated escrow, and a single governance root over the pool, the token, and the upgrade path.\n7. Audit and Security History\nThe deployed contracts derive from publicly audited Chainlink Cross-Chain Token code: the token is the standard CCT burn-and-mint ERC20 (OpenZeppelin 5.x ERC20 with AccessControl) behind an OpenZeppelin Transparent proxy, and the bridge pools are the standard CCT token pools, with the token-pool layer covered by a public Cyfrin CodeHawks competitive audit in 2024 (scope confirmed to include the deployed pool types) plus Code4rena reviews. The deployed Monad proxy, implementation, and bridge pool are source-verified on MonadScan, with exact-match badges on the implementation and the pool, and the proxy has run its original implementation since deployment with no logic swap. No unresolved Critical or High findings for the CCT pools were identified in public records, and the canonical Ethereum wstETH and the underlying Lido protocol are long-audited and long-live. The residual item is pinning the verified source to the exact audited Chainlink CCT release commit (the contest published no commit hash), while the audit scope excluded the owner and governance contracts that secure this deployment.\nRating: MEDIUM → the token-pool stack and OpenZeppelin primitives are publicly audited and the deployed Monad contracts are source-verified, but the exact audited release commit is not pinned and the governance contracts sat outside the audit scope.\n8. Dependencies\nThe asset rests on three production, on-chain governed dependencies: Lido staking on Ethereum (the ultimate backing, where value, yield, and slashing originate, with the Ethereum withdrawal queue applying to any exit to ETH), Chainlink CCIP (supply integrity of the Monad representation), and the Chainlink price feeds on Monad (valuation). None is controlled by an externally owned account or unaudited in the critical path, and changes on both Lido and the bridge are observable on-chain. The tightest governance window among them is the bridge’s 3-hour timelock, and the redemption path to ETH is slow because it combines a bridge round trip with Lido’s withdrawal queue.\nRating: MEDIUM → all dependencies are audited and on-chain governed, but the bridge dependency carries a 3-hour governance delay below the 24-hour bar and the redemption path to ETH is slow.\n9. Summary\nFindings table\n\nArea\nKey finding\nRating\n\n0. Pre-screening\nDeployed at 0x10Aeaf63…5417, thin proxy, Group 3 yield-bearing wrapper; only one genuine wstETH token, confirmed against canonical Lido wstETH on Ethereum; proxy, implementation, and bridge pool source-verified on MonadScan (exact-match on impl and pool).\nGood\n\n1. ERC20\nStandard OpenZeppelin 5.x ERC20, 18 decimals; returns bool, no fee on transfer, no rebase, no ERC777 or ERC1363 hooks, no flash mint, no transfer restrictions.\nGood\n\n2. Oracle\nBoth strategies available: a direct wstETH/USD market feed, or a CAPO composition (ETH/USD plus the wstETH/stETH exchange rate); the composition is the design already used on other Aave instances. All feeds live on Monad; Aave oracle wiring is a prerequisite, not yet done.\nGood\n\n3. Access control\nOpenZeppelin AccessControl, no externally owned account; sole minter and burner is the CCIP pool; but 3-hour timelock below the 24-hour bar and token, proxy, and bridge authority on a single governance root.\nMedium\n\n4. Exchange rate / yield\nNon-rebasing wrapper; rate set on Ethereum by Lido, not manipulable in one Monad transaction; no native redemption on Monad, exit is a thin decentralized exchange or a slow, rate-limited bridge round trip.\nMedium\n\n5. Token architecture\nSingle token, single implementation, single bridge pool, no migration or duplicate supply path; supply only via gated mint and burn; no tx.origin, no application-level delegatecall.\nGood\n\n6. Bridge and cross-chain\nChainlink CCIP Cross-Chain Token, single route to Ethereum; Ethereum escrow (~41,161 wstETH) backs Monad supply (~25,117); rate limiters set both ends; 3-hour timelock; single governance root.\nMedium\n\n7. Audit and security\nCCT token-pool stack publicly audited (Cyfrin CodeHawks 2024 plus Code4rena); deployed Monad implementation and pool source-verified (exact-match); residual is pinning to the exact audited commit, ProxyAdmin unverified, governance contracts outside audit scope.\nMedium\n\n8. Dependencies\nLido staking (Ethereum), Chainlink CCIP, and Chainlink feeds, all production and on-chain governed; bridge governance delay is 3 hours and the exit to ETH is slow.\nMedium\n\nDisclaimer\nAave Labs has no formal or informal affiliation with Lido, Chainlink, or the wstETH issuer beyond this technical assessment. Aave Labs has not been compensated by Lido, Chainlink, or any related party in connection with this work.\nCopyright\nCopyright and related rights waived via CC0.\n\n [ARFC] Deploy Aave Protocol v3.7 on Monad\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Wrapped Ether (WETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 90\n\n Jul 1\n\n Wrapped eETH (weETH) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 109\n\n Jul 1\n\n [ARFC] Deploy Aave Protocol v3.7 on Monad\n\n Governance\n\n 9\n\n 2.1k\n\n Jul 26\n\n MetaMask USD (mUSD) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 159\n\n Jul 1\n\n Wrapped Ether (WETH) on Aave Arc Assessments\n\n Assessments\n\n 2\n\n 170\n\n Sep 18","tokens":3967,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267018238,"hash":"f9132cc7946117b7a1f68838d325b1c591501782"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/36","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 36 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 29, 2018\n\n post by kladkogex on Jan 29, 2018\n\n post by vbuterin on Jan 29, 2018\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Feb 1, 2018\n\n post by vbuterin on Feb 1, 2018\n\n post by shamatar on Feb 1, 2018\n\n Load more posts below","tokens":1185,"squid":"ink-research","role":"Deep Scholar","at":1791267024436,"hash":"b61f8561fee3ba65a6b493aa4a7b8896255111b7"}
{"url":"https://docs.base.org/specifications/build-transaction/build-a-validity-transaction","domain":"docs.base.org","title":"Build a Validity Transaction - Base Documentation","text":"This guide uses an EIP-1559 transaction with Viem because it is the recommended transaction type. The API also supports signed legacy and EIP-2930 transactions.\nbase_sendRawTransactionValidity is available on Base Mainnet and Base Sepolia through the sequencer endpoints listed in Connect to Base, and on Vibenet.\n​1. Create Predicates\nUse storage to wait for contract state. Use block_number and flashblock_index to constrain the candidate position. Every predicate must match.\nPredicate setupimport type { Address, Hex } from 'viem';\n\nconst validity = [\n {\n type: 'storage',\n params: {\n address: '0x8ba1f109551bD432803012645Ac136ddd64DBA72' as Address,\n slot: '0x8' as Hex,\n op: '=',\n value: '0x2a' as Hex,\n },\n },\n {\n type: 'block_number',\n params: { op: '<=', value: '0x11a6a1' as Hex },\n },\n {\n type: 'flashblock_index',\n params: { op: '<=', value: '0x2' as Hex },\n },\n] as const;\n\nOmit mask to compare the full storage word. Use flashblock_index to target a position within a Flashblock. Valid flashblock_index values range from 1 through 10, inclusive; the example uses 0x2 (index 2).\n​2. Sign an EIP-1559 Transaction\nUse the sender’s next nonce. The signed payload becomes the first RPC parameter.\nSign transactionimport { createPublicClient, http, type Chain } from 'viem';\nimport { privateKeyToAccount } from 'viem/accounts';\n\nconst client = createPublicClient({ chain, transport: http(rpcUrl) });\nconst account = privateKeyToAccount(privateKey);\nconst fees = await client.estimateFeesPerGas();\nconst nonce = await client.getTransactionCount({\n address: account.address,\n blockTag: 'latest',\n});\n\nconst rawTransaction = await account.signTransaction({\n chainId: (chain as Chain).id,\n type: 'eip1559',\n nonce,\n to: '0x...' as Address,\n data: '0x...' as Hex,\n value: 0n,\n gas: 100_000n,\n maxFeePerGas: fees.maxFeePerGas,\n maxPriorityFeePerGas: fees.maxPriorityFeePerGas,\n});\n\n​3. Submit the Transaction\nPass the signed transaction and validity as separate parameters.\nSubmit transactionconst response = await fetch(rpcUrl, {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({\n jsonrpc: '2.0',\n id: 1,\n method: 'base_sendRawTransactionValidity',\n params: [rawTransaction, { validity }],\n }),\n});\n\nconst body = await response.json();\nif (body.error) throw new Error(body.error.message);\nconst hash = body.result;\n\n​4. Check Inclusion\nThe RPC returns a transaction hash. Use eth_getTransactionReceipt to check for an onchain receipt.\nFor field definitions, see Validity Transaction RPC.Was this page helpful?Suggest editsRaise issue","tokens":644,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267028100,"hash":"900c6ac01f9325ab6798ed42b8560aa745d28d3f"}
{"url":"https://aave.com/docs/ecosystem/governance","domain":"aave.com","title":"Governance | Aave Protocol Documentation","text":"Governance#\n\nThe Aave DAO is a decentralised collective of AAVE token holders and contributors who work together to shape the future of the protocol through a structured governance process. This community-driven model enables participants to propose, discuss, and vote on critical changes, guiding the evolution of the protocol and aligning with the collective goals of its members.\nThe Aave Protocol is governed by the AAVE token holder community (AAVE, stkAAVE, and aAAVE token holders on Ethereum mainnet) through procedures, voting, and smart contract execution, collectively known as Aave Governance.\nAave Governance v3, developed by BGD Labs, introduces the ability to vote on lower transaction fee networks such as Polygon POS and Avalanche C-Chain while token balances remain on Ethereum mainnet.\nArchitecture#\nAave Governance v3 is designed with a modular architecture to meet the comprehensive needs of an on-chain DAO like Aave. The system is divided into three main components, each corresponding to different stages in the proposal lifecycle:\nCore Network: Acts as the settlement and security layer where voting power resides. It handles high-level validations on proposals and manages governance token balances. Ethereum Mainnet serves as the Core Network.Voting Networks: Environments where voting occurs based on storage proofs. These networks are typically lower-cost environments like Polygon POS and Avalanche C-Chain, enabling users to vote without migrating funds from the Core Network.Execution Networks: Networks where proposal payloads are registered and executed. They handle the execution of approved proposals across various networks, including all Voting Networks and the Core Network.\nCommunication between these components is facilitated by the Aave Delivery Infrastructure (a.DI), providing secure and efficient cross-chain interactions. Additionally, the Aave Robot automates permissionless actions in Aave Governance such as queueing and executing proposals.\nProcesses#\nAave's governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and execute approved changes through a transparent and structured process.\nProposal Lifecycle#\n\nGovernance Forum\nThe proposal process begins with an idea introduced to the Aave Governance Forum. This is where initial discussions take place and feedback is gathered. The community helps refine the proposal before moving to the next stage.Temp Check (Snapshot Voting)\nAfter discussion, the proposal proceeds to a TEMP CHECK via the Aave Snapshot Space. This informal vote gauges community sentiment. TEMP CHECK votes are non-binding but help determine if there is sufficient interest in moving forward. Proposals in this stage do not require detailed technical specifics.ARFC (Aave Request for Final Comments)\nIf the TEMP CHECK passes, the proposal moves to the ARFC stage, where it undergoes more formal scrutiny. Service providers and community members contribute detailed feedback on how the proposal would impact the protocol, preparing it for the AIP stage. ARFC voting also occurs on the Aave Snapshot Space.AIP (Aave Improvement Proposal)\nThe AIP stage is where the proposal becomes a formal, onchain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Aave's governance contracts, primarily on the Ethereum Mainnet.Voting\nOnce submitted, the AIP enters a PENDING status before becoming ACTIVE for voting. Voting is conducted onchain through Aave governance contracts. A proposal succeeds if it meets quorum and vote differential requirements. If these thresholds aren’t met, the proposal fails.Execution\nA successful proposal moves to the execution phase, where it is enacted via Aave's governance infrastructure. Depending on the type of proposal, a timelock delay (either one day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave's Delivery Infrastructure (a.DI).\nProposal Frameworks#\nAave has predefined frameworks for common types of proposals, simplifying the governance process:\nAsset Onboarding Framework: Standardized lifecycle for onboarding new assets to the protocol, providing a structured process for risk assessments, and community discussions.New Chain Deployment Framework: Guidelines for deploying Aave on new blockchains, covering security audits, liquidity considerations, and governance approval to support safe and effective multi-chain expansion.Emission Manager Framework: Simplified process for adding emission admins to reserves, improving the management of liquidity incentives.Caps Update Framework: Direct-to-AIP process for adjusting caps or freezing reserves, allowing quicker governance actions to respond to market risks while maintaining protocol stability and liquidity constraints.Direct to AIP Framework: Similar to the Caps Update Framework, but broader in scope, allows certain governance actions to bypass TEMP CHECK & ARFC stages, requiring only an ARFC forum post before AIP creation.\nThese frameworks streamline governance and allow the community to focus on more complex issues while maintaining the protocol's security and adaptability.\nVoting#\n\nOff-chain Voting (Snapshot)#\nOff-chain votes are used to measure community sentiment during the early stages of proposal development (Temp Checks and ARFCs). These non-binding votes take place on Snapshot and last for three days, allowing token holders to participate without transaction fees.\nOnchain Voting (Governance Interfaces)#\nOnce a proposal reaches the AIP stage, onchain voting is required. Token holders, delegates, or delegators vote on proposals using their AAVE, stkAAVE, or aAAVE tokens. The process is secured through various governance interfaces, including Aave Labs and Boardroom.\nIn Governance v3, each proposal specifies a voting network and all voting for the proposal occurs on this network. The Governance v3 activation enables Polygon POS, Avalanche C-Chain, and Ethereum Mainnet (backup) as initial voting networks. Since voting can occur on multiple networks, this can create limitations for smart contract wallets that only exist on one network. To accommodate this, governance interfaces can be used to setup voting representatives, which allows a separate voting address to be designated for each network.\nVoters do not need to migrate funds to the voting network, all governance token balances and delegations are still stored on Ethereum mainnet, and are validated on the voting network using storage proofs.\nVoting is performing by calling the submitVote() function on the VotingMachine of the corresponding proposal’s voting network.\nAn aave-cli has been developed to generate the necessary storage proof parameters, or voting can performed with the GovernanceV3Helpers Foundry script.\nVoting Power#\nAAVE, stkAAVE (AAVE staked in protocol safety module), and aAAVE (aToken representing AAVE supplied to Ethereum v3 market) token holders receive governance powers proportional to the sum of their balances on Ethereum mainnet.\nThere are two powers associated with each governance token:\nThe proposal power that gives access to creating a proposal.The voting power which is used to vote for or against active proposals.\nGovernance powers can be either jointly or separately delegated to any Ethereum address.\nVoting Representatives#\nSmart contract wallets cannot sign messages for storage proof voting and may not exist on all networks, this creates a challenge to interact with the cross-chain voting contracts.\nTo accommodate cross-chain voting for smart contract wallets and allow greater flexibility for all governance participants, wallets have the ability to link a representative address on other chains.\nTo choose a representative, an address in Ethereum should call the updateRepresentativesPerChain() function on the GovernanceCore smart contract.\nThis representative address is able to vote on the specified network, using the delegators balances and received delegations on Ethereum Mainnet. An address can be the representative of multiple other addresses.\nStorage Proofs#\nAave Governance v3 uses block hashes on the Core network (Ethereum Mainnet) as the source of information for voting balances, and storage proofs as the core mechanism for validation.\nFor any proposal, the system takes a “snapshot” (block hash of the block before activateVote method gets called) of voting token balances/delegations on the Core network, forwards it to an Aave Voting Network and sets it as the main source of balances/delegation to validate against whenever an address submits a vote there.\nEthereum block hashes contain the state tree of the network, which in turn contains all the data of all the smart contracts at that exact block. Amongst those contracts: AAVE, stkAAVE, and other voting assets are present, and within them, the balances and delegations of all Ethereum addresses.\nStorage proofs are a mechanism allowing to cryptographically prove that a piece of data is contained in a tree. In this case, they allow proving that a specific address has voting balance/delegation on the state tree of an Ethereum block.\nWhat happens in practice when an address votes is that the voter inputs the balance of the voting assets they hold at the proposal's Ethereum block, together with a storage proof over the Ethereum block hash for that proposal. The Voting Network then cryptographically verifies the storage proof against the Ethereum block data, along with all additional validations (e.g., no double-voting), and stores the results accordingly.\nProposal Lifecycle#\n\nPayload Registration: Proposal payloads containing executable logic are deployed and registered on the PayloadsController of the target Execution Network. This process is permissionless.\n\nProposal Creation: A proposer with sufficient proposal power creates the proposal on the Core Network (Ethereum Mainnet) by interacting with the Governance contract. The proposer specifies the payload IDs and target networks.\n\nProposal Activation: After a cooldown period (coolDownBeforeVotingStart), the proposal is activated. This involves taking a snapshot of the Core Network's state and forwarding it to the specified Voting Network using a.DI.\n\nVoting Setup: On the Voting Network, the necessary data (Ethereum block hash, state tree, voting asset roots) is settled in the DataWarehouse contract. This step is permissionless and can be performed by any address.\n\nVoting Period: Voting occurs on the Voting Network. Voters submit their votes by calling submitVote() on the VotingMachine, providing their token balances at the snapshot block along with storage proofs.\n\nVote Closure: After the voting duration (votingDuration) elapses, voting is closed. The VotingMachine contract sends the voting results (YES and NO counts) back to the Core Network via a.DI.\n\nResult Validation: The Governance contract on the Core Network validates the voting results against success metrics, such as minimum thresholds and vote differentials.\n\nProposal Queuing: If the proposal meets the success criteria, it is forwarded to the PayloadsController on the Execution Network, where it is queued in a timelock mechanism.\n\nProposal Execution: After the timelock expires, any address can execute the proposal by calling executePayload() on the PayloadsController, which forwards it to the appropriate Executor for execution.\n\nCommunity#\nDelegates#\nDelegates are entrusted with voting power by other community members or through self-delegation. They actively participate in governance by voting on proposals on behalf of those who have delegated their voting rights. Some delegates are compensated through the Orbit program for their contributions.\nDelegators#\nDelegators are community members who hold AAVE, stkAAVE, or aAAVE tokens but choose to delegate their voting power to another individual or entity. This allows them to have their interests represented in governance without directly participating in every vote.\nContributors#\nContributors dedicate time and resources to the Aave DAO by engaging in working groups, completing bounties, building on the protocol, or working through grants. These efforts help maintain and improve the Aave ecosystem.\nService Providers#\nService providers offer essential services to the protocol, such as risk management, financial oversight, security, and development. Examples of service providers include:\nLlamarisk (Risk)Certora (Security)Tokenlogic (Finance)Aave Labs (Development)\nGuardians#\nThe Aave Community Guardians are a group of signers authorized to execute limited emergency protections.\nThe Aave Guardians have responsibilities divided between two multi-signature wallets, with roles and signers listed below.\nProtocol Emergency Guardian#\nThe Protocol Emergency Guardian is the holder of the EMERGENCY_ADMIN role for Aave protocol markets and failsafe emergency actor for cross-chain messaging in Emergency Mode.\nThe Protocol Emergency Guardian is a 4 of 7 multi-signature wallet consisting of the following signers:\n0x4Ab2Bed1d667260dB34244Ba412817651C2dD52b0xc2674C1A1aF0557E1d217fF4F13DF44A637c7C130xe6838d834674eC35EDd53D485770Baa10bdd6AAe0xb291232F480F41c75802C4a60F1D2AC03404Afef0xd4af2E86a27F8F77B0556E081F97B215C9cA8f2E0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe580x3fa960f8355D00874D9C7E3350147f5E94859bc2\nGovernance Emergency Guardian#\nThe Governance Emergency Guardian is tasked to protect the Aave Protocol against potential governance takeovers by having the ability to “veto” an onchain payload if it is deemed malicious.\nThe Governance Emergency Guardian is a 5 of 9 multi-signature wallet consisting of the following community-elected signers:\nSeb (Zapper)Mounir (Paraswap)Gavi Galloway (Standard Crypto)Nenad (Defi Saver)Fernando (Balancer)Roger (Chainlink community)Mariano Conti (DeFi OG)Marin (Lido)Certora (security service provider)\nStewards#\nStewards have delegated responsibility over specific protocol parameters, allowing the DAO to quickly respond to market changes. Stewards manage areas such as the GHO stablecoin and liquidity parameters. This system streamlines governance by reducing the need for frequent votes on minor adjustments, promoting efficiency. The source code for GHO Steward contracts can be found on GitHub.\nGHO Bucket Steward#\nParameterDescriptionFacilitator Bucket CapacityUp to 100% increase\nGHO Aave Steward#\nParameterDescriptionGHO Borrow CapUp to 100% increase or decreaseGHO Borrow RateUp to 5% change to optimalUsageRatio, baseVariableBorrowRate, variableRateSlope1, and variableRateSlope2 with maximum of 25%GHO Supply CapUp to 100% increase\nGHO CCIP Steward#\nParameterDescriptionBridge LimitUp to 100% increase or decreaseRate LimitUp to 100% increase or decrease\nGHO Stablility Module Steward#\nParameterDescriptionGSM Exposure CapUp to 100% increaseGSM Buy/Sell FeesUp to 0.5% increase or decrease\nRisk Steward#\nDescriptionValueFrequency of change5 daysMaximum supply cap increase50%Maximum borrow cap increase50%\nDeployed Contracts#\nEthereum#\nNameAddressCrossChainController0xEd42a7D8559a463722Ca4beD50E0Cc05a386b0e1Governance0x9AEE0B04504CeF83A65AC3f0e838D0593BCb2BC7PayloadsController0xdAbad81aF85554E9ae636395611C58F7eC1aAEc5VotingMachine0x617332a777780F546261247F621051d0b98975EbVotingPortalEthEth0xf23f7De3AC42F22eBDA17e64DC4f51FB66b8E21fVotingPortalEthAvax0x33aCEf7365809218485873B7d0d67FeE411B5D79VotingPortalEthPol0x9b24C168d6A76b5459B1d47071a54962a4df36c3PayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AGovernanceDataHelper0x971c82c8316aD611904F95616c21ce90837f1856VotingDataHelper0x77976B51569896523EE215962Ee91ff236Fa50E8MetaDelegateHelper0x94363B11b37BC3ffe43AB09cff5A010352FE85dCEmergencyRegistry0x73C6Fb358dDA8e84D50e98A98F7c0dF32e15C7e9GovernancePowerStrategy0xa198Fac58E02A5C5F8F7e877895d50cFa9ad1E04GranularGuardian0x4457cA11E90f416Cc1D3a8E1cA41C0cdEcC251d4ExecutorLvl10x5300A1a15135EA4dc7aD5a167152C01EFc9b192AExecutorLvl20x17Dd33Ed0e3dD2a80E37489B8A63063161BE6957VotingStrategy0x5642A5A5Ec284B4145563aBF319620204aCCA7f4DataWarehouse0x1699FE9CaDC8a0b6c93E06B62Ab4592a0fFEcF61\nArbitrum#\nNameAddressCrossChainController0xCbFB78a3Eeaa611b826E37c80E4126c8787D29f0PayloadsController0x89644CA1bB8064760312AE4F03ea41b05dA3637CPayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AGranularGuardian0x4922093c476CfbCF903C7C4082d2D64bAE8A37cEExecutorLvl10xFF1137243698CaA18EE364Cc966CF0e02A4e6327\nAvalanche#\nNameAddressCrossChainController0x27FC7D54C893dA63C0AE6d57e1B2B13A70690928EmergencyOracle0x41185495Bc8297a65DC46f94001DC7233775EbEeVotingMachine0x9b6f5ef589A3DD08670Dd146C11C4Fb33E04494FPayloadsController0x1140CB7CAfAcC745771C2Ea31e7B5C653c5d0B80PayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AVotngDataHelper0x77976B51569896523EE215962Ee91ff236Fa50E8GranularGuardian0xc1162BCb2E5E3ca4725512008c7522dF8C8B7B65ExecutorLvl10x3C06dce358add17aAf230f2234bCCC4afd50d090VotingStrategy0x690C218668B440204F369Af1541245d367cc805CDataWarehouse0x9626F9d60CC0B7e1c9a0A47b7f0bd618fb6f40ff\nBNB#\nNameAddressCrossChainController0x9d33ee6543C9b2C8c183b8fb58fB089266cffA19EmergencyOracle0xcabb46FfB38c93348Df16558DF156e9f68F9F7F1PayloadsController0xE5EF2Dd06755A97e975f7E282f828224F2C3e627PayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AGranularGuardian0xe4FB5e3F506BE0095f38004f993D16fdA8224383ExecutorLvl10x9390B1735def18560c509E2d0bc090E9d6BA257a\nBase#\nNameAddressCrossChainController0x529467C76f234F2bD359d7ecF7c660A2846b04e2PayloadsController0x2DC219E716793fb4b21548C0f009Ba3Af753ab01PayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AGranularGuardian0xa1c6aF35E0205f42256382C05243C543FEDBf4bBExecutorLvl10x9390B1735def18560c509E2d0bc090E9d6BA257a\nBNB Chain#\nNameAddressCrossChainController0x9d33ee6543C9b2C8c183b8fb58fB089266cffA19EmergencyOracle0xcabb46FfB38c93348Df16558DF156e9f68F9F7F1PayloadsController0xE5EF2Dd06755A97e975f7E282f828224F2C3e627PayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AExecutorLvl10x9390B1735def18560c509E2d0bc090E9d6BA257a\nGnosis#\nNameAddressCrossChainController0x8Dc5310fc9D3D7D1Bb3D1F686899c8F082316c9FEmergencyOracle0xF937ffAeA1363e4Fa260760bDFA2aA8Fc911F84DPayloadsController0x9A1F491B86D09fC1484b5fab10041B189B60756bPayloadDataHelper0xF1c11BE0b4466728DDb7991A0Ac5265646ec9672GranularGuardian0x4A9F571E3C1f2F13567bb59e38988e74d7d72602ExecutorLvl10x1dF462e2712496373A347f8ad10802a5E95f053D\nMetis#\nNameAddressCrossChainController0x6fDaFb26915ABD6065a1E1501a37Ac438D877f70PayloadsController0x2233F8A66A728FBa6E1dC95570B25360D07D5524PayloadDataHelper0x81d32B36380e6266e1BDd490eAC56cdB300afBe0GranularGuardian0x61BE97d3a0550549f67CA7421725fA73Fa2036B5ExecutorLvl10x6fD45D32375d5aDB8D76275A3932c740F03a8718\nOptimism#\nNameAddressCrossChainController0x48A9FE90bce5EEd790f3F4Ce192d1C0B351fd4CaPayloadsController0x0E1a3Af1f9cC76A62eD31eDedca291E63632e7c4PayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AGranularGuardian0x6c5264C380C7022e54f585c4E354ffb6f221a03bExecutorLvl10x746c675dAB49Bcd5BB9Dc85161f2d7Eb435009bf\nPolygon#\nNameAddressCrossChainController0xF6B99959F0b5e79E1CC7062E12aF632CEb18eF0dEmergencyOracle0xDAFA1989A504c48Ee20a582f2891eeB25E2fA23FVotingMachine0xc8a2ADC4261c6b669CdFf69E717E77C9cFeB420dPayloadsController0x401B5D0294E23637c18fcc38b1Bca814CDa2637CPayloadDataHelper0xE3B770Dc4ae3f8bECaB3Ed12dE692c741603e16AVotingDataHelper0x77976B51569896523EE215962Ee91ff236Fa50E8GranularGuardian0x0D2CccD3dD420dC6DE2f24DB44aA22fADE290a02ExecutorLvl10xDf7d0e6454DB638881302729F5ba99936EaAB233VotingStrategy0x59e6CAD5d7E7b9A26a45a1d1E74C7aF008170042DataWarehouse0xf41193E25408F652AF878c47E4401A01B5E4B682\nScroll#\nNameAddressCrossChainController0x03073D3F4769f6b6604d616238fD6c636C99AD0APayloadsController0x6b6B41c0f8C223715f712BE83ceC3c37bbfDC3fEPayloadDataHelper0xf438e33dCCEE260ee4371F9dceF408b0d7DBe424GranularGuardian0xa835707d28e6C37C49d661742f2Fb5987367cEd4ExecutorLvl10xc1ABF87FfAdf4908f4eC8dc54A25DCFEabAE4A24\nZkSync#\nNameAddressCrossChainController0x800813f4714BC7A0a95310e3fB9e4f18872CA92CPayloadsController0x2E79349c3F5e4751E87b966812C9E65E805996F1PayloadDataHelper0xe28A3235DCF1Acb8397B546bd588bAAFD7081505GranularGuardian0xe0e23196D42b54F262a3DE952e6B34B197D1A228GovernanceGuardian0x4257bf0746D783f0D962913d7d8AFA408B62547EExecutorLvl10x04cE39789e11a49595cD0ECEf6f4Bd54ABF4d020\nLinea#\nNameAddressCrossChainController0x0D3f821e9741C8a8Bcac231162320251Db0cdf52PayloadsController0x3BcE23a1363728091bc57A58a226CF2940C2e074PayloadDataHelper0x6d4F341d8Bb3Dc5ABe822Aa940F1884508C13f99GranularGuardian0xc1cd6faF6e9138b4e6C21d438f9ebF2bd6F6cA16GovernanceGuardian0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4EExecutorLvl10x8c2d95FE7aeB57b86961F3abB296A54f0ADb7F88\nSoneium#\nNameAddressCrossChainController0xD92b37a5114b33F668D274Fb48f23b726a854d6EPayloadsController0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0CfPayloadDataHelper0xd0929668178973d5994D5654929aCB3d6c2b9949GranularGuardian0xD8E6956718784B914740267b7A50B952fb516656GovernanceGuardian0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6ExecutorLvl10x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A\nPlasma#\nNameAddressCrossChainController0x643441742f73e270e565619be6DE5f4D55E08cd6PayloadsController0xe76EB348E65eF163d85ce282125FF5a7F5712A1dPayloadDataHelper0xA806DA549FcB2B4912a7dFFE4c1aA7A1ed0Bd5C9GranularGuardian0x60665b4F4FF7073C5fed2656852dCa271DfE2684GovernanceGuardian0x19CE4363FEA478Aa04B9EA2937cc5A2cbcD44be6EmergencyOracle0xF61FE74Ec1cFbd9Ee8Bd27592D2EDEe0E2aA85CfExecutorLvl10x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A\nMonad#\nNameAddressCrossChainController0x8dd5b84b26ae3916A5Fb34C8968F93d206216b63PayloadsController0x442CA936e5E6Db875357d0A16481145c96dd9a82PayloadDataHelper0xFBEa38C851B7B5A4626b0348aa2Db70921Cd3f92GranularGuardian0xD3DD0bE957fcE2dCd359e09374Cbc99f60337D42GovernanceGuardian0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4EExecutorLvl10xa9d0EAFF48cE1DF468f9eAeb7e628c413343F6A2\nCelo#\nNameAddressCrossChainController0x50F4dAA86F3c747ce15C3C38bD0383200B61d6DdEmergencyOracle0x91b21900E91CD302EBeD05E45D8f270ddAED944dPayloadsController0xE48E10834C04E394A04BF22a565D063D40b9FA42PayloadDataHelper0x8657Cd5a0957e8C5BE15c69C67078b5d730D720aGranularGuardian0xbE815420A63A413BB8D508d8022C0FF150Ea7C39GovernanceGuardian0x056E4C4E80D1D14a637ccbD0412CDAAEc5B51F4EExecutorLvl10x1dF462e2712496373A347f8ad10802a5E95f053D\nMantle#\nNameAddressCrossChainController0x1283C5015B1Fb5616FA3aCb0C18e6879a02869cBPayloadsController0xF089f77173A3009A98c45f49D547BF714A7B1e01PayloadDataHelper0x5e06b10B3b9c3E1c0996D2544A35B9839Be02922GranularGuardian0xb26670d2800DBB9cfCe2f2660FfDcA48C799c86dGovernanceGuardian0x14816fC7f443A9C834d30eeA64daD20C4f56fBCDExecutorLvl10x70884634D0098782592111A2A6B8d223be31CB7b\nMegaEth#\nNameAddressCrossChainController0x5EE63ACb37AeCDc7e23ACA283098f8ffD9677BBePayloadsController0x80e11cB895a23C901a990239E5534054C66476B5PayloadDataHelper0x9fE056F44510F970d724adA16903ba5D75CC4742GranularGuardian0x8Fa22D09b13486A40cd6b04398b948AA8bD5853AGovernanceGuardian0x5a578ee1dA2c798Be60036AdDD223Ac164d948AfExecutorLvl10xE2E8Badc5d50f8a6188577B89f50701cDE2D4e19\nSonic#\nNameAddressCrossChainController0x58e003a3C6f2Aeed6a2a6Bc77B504566523cb15cPayloadsController0x0846C28Dd54DEA4Fd7Fb31bcc5EB81673D68c695PayloadDataHelper0x6fD45D32375d5aDB8D76275A3932c740F03a8718GranularGuardian0x10078c1D8E46dd1ed5D8df2C42d5ABb969b11566CLEmergencyOracle0xECB564e91f620fBFb59d0C4A41d7f10aDb0D1934ExecutorLvl10x7b62461a3570c6AC8a9f8330421576e417B71EE7PreviousSavings GHO (sGHO)NextOracle","tokens":5886,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267028863,"hash":"8bdaa61cb593e0d43b02e587c50943ff633ccee0"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/32","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 32 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by MicahZoltu on Jan 17, 2018\n\n post by mrsmkl on Jan 19, 2018\n\n post by JustinDrake on Jan 20, 2018\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n post by kz on Jan 30, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by denett on Jan 31, 2018\n\n post by kz on Jan 31, 2018\n\n post by vbuterin on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n post by shamatar on Jan 31, 2018\n\n Load more posts below","tokens":1062,"squid":"ink-research","role":"Deep Scholar","at":1791267034620,"hash":"a1ec18aa98da2ed30f5d589c8309b033dcd7e874"}
{"url":"https://docs.base.org/specifications/build-transaction/predicates-and-safety","domain":"docs.base.org","title":"Predicates and Safety - Base Documentation","text":"Predicates are inclusion conditions. They do not guarantee inclusion or successful execution.\n​Predicate Types\nTypeParametersstorageaddress, slot, op, value, optional maskblock_numberop, valueflashblock_indexop, value\nThe supported operators are <, <=, =, !=, >, and >=. Predicate values use 0x-prefixed hexadecimal strings.\n​Evaluation\nBase checks a transaction before inclusion. If a predicate is false, the transaction remains pending.\nAn earlier transaction can change the storage value that a pending transaction watches. The pending transaction can then become eligible in the same Flashblock.\n​Storage Example\nStorage predicate{\n \"type\": \"storage\",\n \"params\": {\n \"address\": \"0x2222222222222222222222222222222222222222\",\n \"slot\": \"0x7\",\n \"mask\": \"0xff\",\n \"op\": \"=\",\n \"value\": \"0x2a\"\n }\n}\n\nBase compares (storage[address][slot] & mask) with value. Omit mask to compare the full storage word.\n​Block and Flashblock Position\nUse block_number to target a block and flashblock_index to target a position within that Flashblock. Add separate predicates when both conditions must match. Valid flashblock_index values range from 1 through 10, inclusive; the corresponding hexadecimal values are 0x1 through 0xa.\n​Safety\nA predicate does not simulate a transaction. Keep critical checks in the application call.\nPredicates read raw storage. They cannot call view functions or evaluate computed values. Verify the target contract’s storage layout before using a storage predicate.\nState can change during block building. A condition can become true or false before inclusion.\nDo not use transaction placement as a source of randomness. Do not assume a zero-valued slot makes a CREATE2 address, proxy, or uninitialized contract safe to call.\nValidity criteria are not recorded onchain. Do not include secrets in calldata or predicate values.Was this page helpful?Suggest editsRaise issue","tokens":471,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267038233,"hash":"0bb8befde612af7bbc82782649c6e7f3db8fe411"}
{"url":"https://aave.com/docs/mcp/tools","domain":"aave.com","title":"Aave MCP Tools | Aave Protocol Documentation","text":"Tools#\nAave MCP groups its tools into reads, action builders, orders (token swaps), Savings GHO, DAO governance and guidance. tools/list on the endpoint returns the live inventory with each tool's full parameter schema, and is the authority whenever it disagrees with this page.\nConventions#\nVersion. Most tools take version as v3, v4, or all. Where a tool is fixed to one version, the tables below say so.Reserve selectors. A v4 call takes the opaque reserveId. A v3 call takes market, token and chainId. Both come from get_markets in the same session, as described in Identifiers.Amounts. Main units, never base units, as described in Amounts.Send only what applies. Leave an argument out of the call entirely when it does not apply. An empty string or a near-zero number in its place is not universally read as unset, and several arguments reject it.Rejected input stays rejected. When the API refuses an argument, the reason comes back verbatim and marked non-retryable. Fix the arguments instead of repeating the call.A filter narrows the whole response. Asking get_markets for one symbol returns that reserve and the data around it, not a full chain listing with one row highlighted.\nMarkets and Reserves#\nToolVersionDescriptionget_chainsv3, v4Chains Aave supports, flagging the ones this API holds no market onget_marketsv3, v4Reserves for a chain with rates, caps and liquidity left; symbols narrows it, user adds wallet balancesget_reserve_detailsv3, v4Deep detail for a single reserve, including token decimalsget_emode_categoriesv3eMode categories, which group correlated assets for higher borrowing powerget_apy_historyv3, v4Supply or borrow APY for a reserve over a windowget_protocol_historyv4Protocol-wide market size and borrows over a windowget_hubsv4Hub-level liquidity and global accountingget_hub_assetsv4The assets one hub holds, with hub-wide supplied and borrowed totals\nPositions#\nToolVersionDescriptionget_user_positionsv3, v4A wallet's supplies and borrows, with per-position health on v4get_position_itemsv4The individual supplies or borrows inside one spoke, each with a positionItemIdget_user_summaryv3, v4Aggregate position and health factorget_user_summary_historyv4One wallet's net worth, supplied, debt and health factor over a windowget_user_activityv3, v4Transaction history, paginatedget_transaction_processedv4Whether Aave has observed a transaction yet\nActions#\nToolVersionDescriptionpreview_actionv3, v4Simulate a supply, borrow, withdraw or repay without executingprepare_actionv3, v4Build an unsigned supply, borrow, withdraw or repayprepare_set_collateralv3, v4Build an unsigned change to whether a supplied asset backs borrowingprepare_set_emodev3Build an unsigned switch of a wallet's eMode category, 0 to disableprepare_liquidationv3, v4Build an unsigned liquidation of a position whose health factor is under 1\nRewards#\nToolVersionDescriptionget_user_rewardsv3, v4Claimable rewards on every supported chain, Merit programmes included; the v3 response also carries the claim transactionprepare_claim_rewardsv4Build an unsigned rewards claim\nSwaps and Orders#\nToken swaps move tokens in the wallet. They are protocol-agnostic, take no version, and run on the v4 backend.\nA swap runs an order lifecycle: a quote mints a quoteId, prepare_order returns what the user signs, submit_signed_order relays the signed order, and get_order_status tracks it until it settles.\nToolVersionDescriptionget_swappable_tokensNeitherThe chains and tokens a swap can be quoted onget_swap_quoteNeitherQuote a token swap and return a quoteId; slippagePct caps slippageprepare_orderNeitherWhat the user signs for a quoted order: EIP-712 typed data, or the transaction a native-token sell takessubmit_signed_orderNeitherRelay an order the user has already signedget_order_statusNeitherPoll a submitted order until it settlesget_pending_ordersNeitherA wallet's orders, newest first, across the chains the backend servesprepare_cancel_orderNeitherThe EIP-712 cancellation for the user to signcancel_orderNeitherRelay a signed cancellation, or return the on-chain cancel transaction\nSome swaps need a token approval first. Prefer the gasless bySignature permit the quote offers and pass the signature back to prepare_order as permitSignature and permitDeadline; a byTransaction approval has to be sent and mined before the order can be prepared.\nSavings GHO#\nSavings GHO is an ERC-4626 vault on Ethereum that pays a target rate on deposited GHO. It is a product of its own rather than a reserve, so it has its own tools.\nToolVersionDescriptionget_sgho_vaultv3, EthereumVault state and a wallet's position: target rate, supply cap, maxDeposit, maxWithdrawget_sgho_previewv3, EthereumConvert between GHO and sGHO shares at the current vault indexprepare_sgho_actionv3, EthereumBuild an unsigned deposit or withdrawalprepare_stkgho_migratev3, EthereumBuild an unsigned migration of an entire stkGHO position into sGHO\nAn sGHO withdrawal is denominated in vault shares, not in GHO. It is the\none place in this server where an amount is not the token the user is thinking\nin. Convert with get_sgho_preview, or pass max.\nA wallet's maxDeposit is already the smaller of its GHO balance and the remaining cap, so size a deposit against that rather than against the cap. sGHO earns yield but is not collateral: it cannot be supplied or borrowed against, and it does not appear in a health factor.\nAave DAO Governance#\nThese take no version. Governance V3 is the DAO's own contract generation, unrelated to the v3 and v4 markets. Vote tallies, quorum and per-voter power are all denominated in AAVE, so they compare directly.\nToolDescriptionsearch_governance_proposalsList proposals by lifecycle state, or search them full-textget_governance_proposalOne proposal in full, with the quorumMet and differentialMet conditions it must satisfyget_proposal_votesWho voted and with how much power, largest first, plus totalsget_user_voteHow one wallet voted on one proposal, or that it did notget_proposal_payloadsWhat a proposal executes per target chain, and whether it has landed everywhere\nGuidance#\nToolDescriptionget_startedWhat the server can do, for a turn where the user has not asked for anything specificget_aave_guideProtocol and usage guidance by topic, also readable as a resource at aave://guide/<topic>\nResponse Envelope#\nEvery successful result is the same envelope, returned both as JSON text and as structuredContent:\n{ \"data\": {}, \"next_actions\": [\"get_user_summary to confirm the resulting health factor\"]}\nRead the payload from data and follow next_actions. A result may also carry warnings, each with a level, a stable code, and a message:\nLevelMeaningerrorThe action cannot succeed as built. Fix the arguments or tell the user, rather than building past it.warningThe action will succeed, and the user should hear about it first.infoContext worth passing on.\nChain Coverage#\nA read covers every chain it can and names them under chainsCovered, so there is no need to loop over chains by hand. Where the full sweep would be too large to return, the read narrows and names what it left out under chainsNotCovered, which is the only case that needs a second call.\nchainsNotServed means something else. Those are chains this API holds no market on, so an empty result there is an absence of data rather than an answer about the chain, and asking again returns the same nothing. get_chains flags them too.\nBuilding an Action#\nprepare_action returns an execution plan, and its __typename says what to do next.\n__typenameWhat it meansTransactionRequestReady to sign and send: to, from, data, value, chainIdErc20ApprovalRequired (v4), ApprovalRequired (v3)The allowance is missing, and the plan carries the approvalPreContractActionRequiredTwo transactions, in order: transaction first, then originalTransaction, which is the actionInsufficientBalanceErrorThe sender lacks the funds\nBoth versions offer the same gasless route, and offer it the same way. When an approval plan carries bySignature permit typed data, sign that and call prepare_action again with permitSignature and permitDeadline, the deadline from the message that was signed. The call then returns the action transaction with no approval transaction at all. v4 offers this on a supply; v3 offers it on a supply, a repay or a withdraw, and not on a borrow, since nothing leaves the wallet there.\nOnly send permitSignature when replaying a call after an approval handed back\na permit. It is not part of a first attempt.\nA plan with no bySignature is a token without permit support, so the on-chain route is the only one. Submit the byTransaction approval and wait for it to be mined before running prepare_action again: the action transaction is only issued once the allowance is visible on chain, so calling again too early returns the approval step a second time.\nSupplying a chain's native gas token, with native, usually takes the PreContractActionRequired path, where the first transaction lets the native gateway act and the second performs the supply.\nAmounts#\nAmounts are in main, human units. \"10.5\" is 10.5 USDC, and token decimals are handled for you. The format is a plain positive decimal string, so 1e5 and hex are rejected, and get_reserve_details carries the decimals when a conversion is needed. 100000 base units of a 6-decimal token is \"0.1\", not \"100\".\nRates and percentages carry a Pct suffix and are percentages rounded to four decimal places, so \"3.32\" means 3.32%. Plain ratios such as the health factor are unchanged.For a withdraw or a repay, max uses the whole balance or debt instead of an amount.native acts with the chain's native gas token instead of its wrapped ERC-20. The two do not always combine: a v3 repay has no native max form, so send an explicit amount there, or drop native and repay the wrapped token with max.Aggregate USD figures on get_user_summary are rounded to four decimals, so never compare them against dust. Use the per-item principal and interest from get_position_items.\nIdentifiers#\nOn v4 every id is URL-safe base64 of a ::-joined tuple, so they all look alike and several differ only in how many segments they carry.\nIdShapeReturned bySpokechain::spokeAddressget_user_positionsReservechain::spokeAddress::onChainReserveIdget_markets, get_reserve_details, get_position_itemsUser positionchain::spokeAddress::userposition readsHub assetchain::hubAddress::onChainHubAssetIdget_hubs, get_hub_assets\nCarry ids verbatim from whichever tool returned them, and never assemble one. They are opaque by contract, the on-chain reserve id is a 256-bit number rather than a small index, and a value that was built by hand is rejected even when it looks right. The same asset also appears on several spokes at very different rates, which is why the reserveId matters and a symbol will not do.\nv3 does not work this way. There a reserve is addressed as market plus token plus chainId, three plain values with no encoding, and an Aave pool address recognised from elsewhere belongs to another deployment and is rejected.\nWhat Can Block an Action#\nFour rules decide whether an action is possible at all. Each one otherwise surfaces as a different error.\nA supply is not collateral unless prepare_action was given enableCollateral. Without collateral the borrowing power is zero, so a borrow is refused, and preview_action reports a resulting health factor of 0, which means no borrowing power rather than liquidatable. prepare_set_collateral turns an existing supply into collateral.Collateral pinned by an open borrow cannot be withdrawn, so a withdraw repays first. The withdrawableIgnoringDebt field reflects liquidity and caps only, and does not subtract collateral backing a borrow, so asking for all of it is refused for dropping the health factor below 1.Debt cannot be repaid to exactly zero. Interest accrues between computing the amount and the transaction landing, so a few units always remain, and max is refused when the wallet holds exactly what was borrowed, because it is then one unit short. Treat a zero principal as repaid, or repay with a surplus in the wallet.The API lags the chain. After sending a transaction, poll get_transaction_processed before building a dependent follow-up rather than waiting a fixed time.\nA clean simulation says the position allows the action. It says nothing about token allowances, so an approval step can still be outstanding.PreviousGetting StartedNextSkills","tokens":3108,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267038884,"hash":"bbf3b94f3d299fbd00c2c3895982c8fb48e8831d"}
{"url":"https://ethresear.ch/t/log-shards-and-emv-abstraction/747","domain":"ethresear.ch","title":"Log shards and EMV abstraction - Sharding - Ethereum Research","text":"Log shards and EMV abstraction \n\n Sharding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 1 / 1\n\n Jan 2018\n\n Jan 2018\n\n post by JustinDrake on Jan 16, 2018\n\n JustinDrake\n\n This post explores taking a “stateful” shard and removing its state trie, effectively abstracting away the EVM. The idea is to decouple collation validity from consensus, thereby putting more emphasis on log ordering, availability and bandwidth. The end result is a “log shard” with is a feature subset of “phase 1” shards, with much of the potential for scalability thanks to various state-minimisation strategies (TrueBit, Plasma, cryptoeconomic accumulators), and with significantly less implementation complexity.\nThe EVM of a log shard has a single LOG opcode that pushes a blob of data to a witness-friendly log accumulator. In such a log shard, a collation is an ordered list of logs. (The LOG opcode can be implicit by serialising log arrays with a separator symbol.) The only restriction for collations is a collation limit (say, 1MB). So any blob of data with size ≤1MB is a valid collation. The fork choice rule for validators is simplified to only include:\n\navailability of collations\nenforcement of the collation limit\nbasic housekeeping of VMC collation headers, which include the log accumulator root\n\nTo maintain the same cryptoeconomic incentives as in stateful sharding, we still need to give validators coinbase rewards and transaction fees:\n\nCoinbase rewards: This is done by issuing coinbase rewards in the parent chain, in our case the main shard.\n\nTransaction fees: The collation limit induces a fee market, and fees for inclusion of logs can be paid for out-of-band, e.g. using payment channels from users to validators. (I am exploring an offchain design similar to Raiden where users can pre-purchase generic “stateless gas” to trustlessly compensate any validator for including logs in collations. This is the topic of another post.)\n\nConclusion\nWe have a log shard which limits itself to log ordering, friendly log witnesses, and log real-time availability. It is useful for scalability when used in combination with a state-minimisation strategy. Maintenance of the shard requires marginal storage and CPU. As a “pure bandwidth” shard, it sits somewhere between a stateful shard and something like BitTorrent or IPFS. Compared to stateful shards, implementation is greatly simplified and the design lends itself to networking optimisations to push collation limits to the extent allowed by bandwidth resources.\n\n Private lookbehind for logs\n\n Fork-free sharding\n\n State-minimised executions\n\n Minimal Viable Plasma\n\n History, state, and asynchronous accumulators in the stateless model\n\n Powered by Discourse","tokens":684,"squid":"ink-research","role":"Deep Scholar","at":1791267044702,"hash":"406cb7a2f639c5e7c47c90c956903086dd7bcb32"}
{"url":"https://docs.base.org/specifications/build-transaction/fees-ordering-and-lifecycle","domain":"docs.base.org","title":"Fees, Ordering, and Lifecycle - Base Documentation","text":"​Fees\nTransactions use the normal fee rules for their type. For EIP-1559 transactions, set maxFeePerGas and maxPriorityFeePerGas on the signed transaction.\nA transaction that is not included does not pay onchain execution fees. An included transaction pays normal execution fees, even if it reverts.\n​Ordering\nA transaction competes for inclusion only after every predicate matches. A matching predicate does not reserve block space.\n​Expiry\nEvery validity transaction must include a block_number predicate that sets an upper bound, using <, <=, or =. The bound must be within 60 seconds of submission. This is a time-based limit, not a fixed block count; the equivalent number of blocks depends on block cadence.\nCombine the predicate with flashblock_index to tighten the expiry bound to a position within that block’s Flashblocks. Valid Flashblock indexes range from 1 through 10, inclusive.\n​Replacement\nA later transaction with the same sender and nonce can replace a pending transaction. If the RPC returns an underpriced-replacement error, increase the fee fields, sign again, and retry.Was this page helpful?Suggest editsRaise issue","tokens":285,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267048314,"hash":"173fd0f30047169427c9c62d2bdcf53953f5eda9"}
{"url":"https://docs.base.org/specifications/build-transaction/troubleshooting","domain":"docs.base.org","title":"Troubleshooting - Base Documentation","text":"Use eth_getTransactionReceipt to confirm onchain inclusion.\n​RPC Method Is Unavailable\nUse an endpoint that supports base_sendRawTransactionValidity. The method is available on Base Mainnet and Base Sepolia through the sequencer endpoints listed in Connect to Base, and on Vibenet.\n​Submission Fails\nConfirm that the first parameter is a signed legacy, EIP-2930, or EIP-1559 transaction. Confirm that the second parameter has a non-empty validity array.\nCheck the predicate type, operator, and 0x-prefixed hexadecimal values. See Validity Transaction RPC for the request format.\nRecord the full JSON-RPC error when escalating an issue.\n​Transaction Was Not Included\nA transaction can remain pending because a predicate is false, another transaction has higher priority, it is replaced, or its maximum block or Flashblock position passed.\n​Transaction Expired\nSubmit a new signed transaction with later block_number or flashblock_index conditions.\n​Replacement Is Underpriced\nIncrease the fee fields, sign again, and retry with the same sender and nonce.\n​Get Help\nInclude the network, RPC provider, transaction hash, predicate type, submission time, and JSON-RPC error. Do not share private keys, authentication data, or full signed transactions in public support channels.\nFor community support, use the #developer-chat channel in the Base Discord.Was this page helpful?Suggest editsRaise issue","tokens":349,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267061715,"hash":"de183a108e023d16aa5c30ceb66d812dad08feb8"}
{"url":"https://ethresear.ch/t/fork-free-sharding/1058","domain":"ethresear.ch","title":"Fork-free sharding - Sharding - Ethereum Research","text":"Fork-free sharding \n\n Sharding\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Feb 2018\n\n 1 / 12\n\n Feb 2018\n\n Mar 2018\n\n post by JustinDrake on Feb 12, 2018\n\n JustinDrake\n\n TLDR: This post describes a possible “end game” for sharding. Assuming the existence of data availability proofs we can design a non-trivial sharding scheme that is “fork-free”, i.e. where every collation header added to the MVC has exactly one child. Fork-free sharding enjoys fantastic properties by construction:\n\nOptimal head fetching\n\nOptimal asynchronous (or synchronous) cross-shard communication\nSecurity and finality elevated to that of the main shard\n\nBackground on consensus\nAs I see it there are three fundamental local impediments to global consensus. Each impediment manifests itself at a physics level and at a networking level:\n\nOrdering: What comes first? In physics, time is relative and there is no absolute clock. In networking, routing speeds are unpredictable because topologies are inhomogeneous and transports are unreliable.\n\nAvailability: What can be seen? In physics, the speed of light is finite and we have black holes. In networking, communication has latency and partitions happen.\n\nValidity: What is real? In physics, we have Heisenberg’s uncertainty and other quantum effects. In networking, software and hardware stacks are inhomogeneous and buggy.\n\nIn distributed consensus the traditional approach to overcoming local impediments to consensus is fork-choice rules. In a quantum-like fashion, we accept simultaneous candidate realities to co-exist as parallel forks, and global consensus emerges/collapses from fork-choice rules and local “observation”. Unfortunately following fork-choice rules comes at a cost:\n\nEvaluation cost: Evaluating forks for availability may require downloading lots of data, and evaluating forks for validity may require executing many transactions. With fork-choice rules, evaluation costs are technically unbounded in paralellism, and this is a vector for DoS attacks (at least until we have quantum computers and quantum networking). Evaluation costs in a fork-free setting are bounded in the classical computing setting.\n\nForking risk: There is opportunity cost following one fork versus another, i.e. a risk in choosing the wrong fork. For example, PoW mining on a wrong fork is wasting electricity. With a single chain you are always on the right chain, so opportunity costs as a miner/validator/executor goes away.\n\nImpedance to security, speed and finality: Having the possibility to follow the wrong fork dilutes security of consensus, wastes proposals that don’t advance state, and/or impedes finality.\n\nIn the current sharding scheme we have to pay the price of fork-choice rules twice: once for the main shard, and once within the VMC. (When we separate ordering from execution, we may actually have three nested levels of fork-choice rules. One providing ordering to the VMC, another providing availability, and yet another providing validity.)\nBelow we give a sharding scheme where ordering, availability and validity is guaranteed by construction by the VMC from the collation headers, i.e. there is no fork-choice rule within the VMC.\nConstruction\nThe VMC already provides ordering. That is, given two collation headers added to the VMC, we know which was added first. For validity, we know of several ways to have valid-by-construction collations:\n\nPut a SNARK/STARK in the collation header which proves that the collation root corresponds to a valid state transition, and have the VMC’s addHeader method check the proof.\nUse log shards where any (hashable) blob of data can be parsed as a bounded list of logs (and/or transactions where garbage/invalid transactions are no-ops) and push state execution to a second-layer protocol, or to the application layer.\n\nFor data availability—and this is today’s key missing ingredient—we assume the existence of succinct and efficiently computable/verifiable proofs which the VMC checks.\nDiscussion\nWith the VMC gating collation headers to guarantee ordering, availability and validity of collation bodies, the logic for head fetching collapses to just “get the last collation header from the VMC”. Cross-shard communication is significantly easier because there is no re-org risk, as least not from the point of view of the VMC. The main thing that needs to be provided is replay protection in case the main shard reorgs, and this is provided by construction with stateless client witnesses.\nThe security of collation bodies elevates to the security of collation headers in the VMC. In particular, we have tight coupling, i.e. breaking a single shard means breaking the VMC, which means breaking the main shard. The time-to-finality of child shards also matches that of the main shard. So in a setup where the main shard has full Casper PoS with finality in minutes, child shards also enjoy finality in minutes.\nAs a side note for choosing the log shard approach vs the SNARK/STARK approach for validity, notice that the SNARK/STARK approaches is much stricter by disallowing “shard forks” below the VMC level. The state execution rules are frozen in the VMC until it is updated/replaced/forked, which requires intervention in the main shard. When execution is decoupled from availability (e.g. the log shard approach) forking a shard’s execution rules can be done independently at the shard level.\n\n Cryptoeconomic signature aggregation\n\n Simple honest-majority collation availability proof\n\n Scalable honest-majority collation availability\n\n Delayed state execution in practice\n\n 4\n\n 3\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by vbuterin on Feb 12, 2018\n\n vbuterin\n\n Nice! I just happened to write a post expressing similar ideas, with a more concrete construction, at the same time: A model for stage 4 \"tightly coupled\" sharding plus full Casper\nI’m actually not too worried about data availability proofs, at least in the short term, because we can just use an honest majority substitute in the short term. In my model, the fork choice rule for the main chain is driven largely by collations, and collations are implicitly endorsements of the chain, so if you are considering building on some chain, you could simply verify the availability of the last, say, 100 collations that have been built on the chain, and trust everything before then. In the long term, I agree better data availability checking constructions would massively improve the scheme and possibly let it scale super-quadratically.\n\n 9 days later\n\n post by nate on Feb 22, 2018\n\n nate\n\n Some existing projects (e.g. Tendermint, Cosmos) have taken the fork-free method to the extreme - and even on the root shard (or, only shard) they don’t allow forks and require finality on a block before it’s added to the chain (essentially, a prepare and commit per block).\nThat being said, I think it’s worth pointing are that there are some real benefits to allowing forking. For example, if we allow forking, and also consider blocks as votes, then we can have O(1) messages per finalized block. The tradeoff here is that though there’s significantly higher latency to finality, on the order of the number of validators, the protocol can reasonably support more validators (in the extreme no-fork case, O(n) messages are needed before advancing to the next block).\nIt seems most reasonable we’ll end up somewhere in the middle on the root shard - where both votes are votes and blocks are votes, and so we have a reasonable time to finality while also supporting a larger number of validators.\nThat being said, as the shards that exist in this scheme all delegate their forkchoice to the root shard/VMC, I don’t think we can actually take advantage of the above benefits of having forking, which make it seem like there aren’t many, if any, disadvantages to going fork-free, in this model \n\n post by nate on Feb 22, 2018\n\n nate\n\n That being said, it’s also worth noting that we can get some of the benefits of this proposed scheme while still allowing forking (with the exception of optimal head fetching, obviously).\nFor optimal synchronous cross-shard communication, for example, we can simply enforce “atomicity of cross-shard blocks” before finality is reached. Essentially, if a merge block is in the fork choice of one shard it’s merged with, then it must be in the forkchoice of the other shard it’s merged with. Note that does require an ordering between shards that have a block “merge mined” between them.\nCurrent CBC Casper sharding goes a bit farther and organizes the shards in a binary tree, where blocks can be merged between any two shards that are connected in the tree. Though this has problems of its own, if we add SNARKs/STARKs, you can imagine that when we can get security and finality on the shards that is equivalent to the main shard - when we get finality on a root shard block that merges with chains beneath it.\nThis is obviously a very different model - but I thought it was worth pointing out that going fork-free isn’t the only way of getting these benefits \n\n post by vbuterin on Feb 22, 2018\n\n vbuterin\n\n Whether or not an algo is fork-free or not is a bit of a red herring, because it all depends on whether or not clients listen to partial confirmations. For example, in PBFT, you can have a client with a rule like “if piece of data X has 10 more prepares than any conflicting piece of data, then I will show it as partially confirmed”; this then makes PBFT forkful. In Casper FFG, you can have a client that refuses to show any blocks until they are finalized, and this makes Casper FFG fork-free. In an important philosophical sense, any consensus algorithm where you can make intelligent guesses about what data will be finalized before finality technically happens is forkful; it’s just a question of whether or not clients show the forkfulness. And you can probably prove that the only non-fully-synchronous consensus algo that doesn’t have that property is a dictator.\nNow that we have that established, the next step is to point out that a chain-based data structure is really convenient, for a few reasons:\n\nIt allows us to merge different stages of confirmation for different pieces of data - for example, in Casper FFG, a vote for epoch N corresponds to a PBFT prepare for epoch N and a PBFT commit for epoch N-1. This double-duty reduces concrete finality latency by ~17% with no tradeoffs (as an average transaction needs to wait for 2.5 instead of 3 messaging rounds to finalize). In PoW, block N is an Mth confirmation for block N-M, for all M <= N; if this massive multi-duty function of blocks did not exist, every new PoW would have to separately mention what value it’s voting for in every previous height.\nIt allows us to merge the concept of leader election rounds (PBFT “views”) and transaction sequencing rounds (PBFT “sequence numbers”).\nIt allows us to merge proposals and prepare/commit messages, reducing overhead further.\n\nI actually believe that a truly optimal version of Casper FFG could reduce finality latency by ~20% further with no tradeoffs except for algorithmic complexity, by taking full advantage of the fact that a reference to a block is also a reference to all of its ancestors. Casper CBC should be able to make this optimization and achieve total optimality in even its current form.\n\n Interoperability via Cosmos, Peg Zones\n\n post by kladkogex on Feb 23, 2018\n\n kladkogex\n\nI think that Tendermint whitepaper proves things under assumption of a reliable and synchronous network.\nReal life networks are not reliable - packets get lost and misrouted. I have a strong suspicion that one can show that because Tendermint does not allow forks it can get totally stuck in a real network. In particular, TenderMint requires a node to receive 2/3 of pre-commits to commit. If some of the the pre-commits for some nodes are lost, it seems that once can get into a situation where a minority of nodes will commit, and the rest of the nodes will proceed to the next round, which effectively will create a fork, but since Tenfermint does not allow forks the system will get totally stuck!\nI think only truly asyncronous consensus protocols can be forkless. And the reason why asynchronous protocols can be forkless is because for fully asynchronous consensus protocols an unreliable network can be made effectively 100% reliable by retransmissions. Node A sending a message to node B can retransmit if it does not receive a confirmation, where the retransmisison period can exponentially increase with time.\nTo my knowledge there is no real-life crypto currency based on Tendermint, and when Cosmos network is released, it may well be that the system will get totally stuck because it is based on an assumption of a synchronous and reliable network - this may be a very embarrassing moment for these guys!\n\n post by MaxC on Feb 28, 2018\n\n MaxC\n\n JustinDrake\n\n Fork-free sharding does sound like it would be simpler. It is how I’ve also been thinking about sharding.\nPros: Fork-free sharding makes doing data availability proofs simpler, and eliminates the need to do cross-chain forkful reverts, which might involve lots of roll-backs on other shards.\nCons: I guess the difficulty is in ensuring enough checks and balances are in place to make sure that finality can be given after every block, whilst still ensuring validity, availability etc.\n\n post by MaxC on Feb 28, 2018\n\n MaxC\n\nIn the real world why would the stuck nodes not just re-request messages from those they haven’t heard from? Is this really a big problem?\n\n post by kladkogex on Mar 1, 2018\n\n kladkogex\n\nWell, Tendermint does not re-request messages …\n\nAt the end of the P recommit step each node makes a decision. If the node had received more than 2/3 of precommits for a particular block, then the node enters the Commit step. Otherwise it continues onto the Propose step of the next round. Even if a node hadn’t yet received the block precommitted by the network,\nit enters the Commit step.\n\nA problem with Tendermint is that it is not a mathematically proven thing, there are no proofs in the whitepaper and it is known that Tendermint was getting stuck in its first iteration, they seem to fix it, but it is not clear whether more ways for it to get stuck exist or not. They say it is based on a 1988 paper\n\nwhich assumes a synchronous network, meaning that there is a fixed latency bound for all communications.\n\n post by vbuterin on Mar 1, 2018\n\n vbuterin\n\n I believe the 1988 paper assumes partial synchrony, so there is a latency bound, but if latency exceeds the bound that only temporarily prevents liveness, without risking safety.\nCasper FFG operates under a similar model.\n\n post by kladkogex on Mar 1, 2018\n\n kladkogex\n\n Below is an interesting discussion of partial synchrony in the HoneyBadgerBFT paper\nAlmost all modern BFT protocols rely on timing assumptions\n(such as partial or weak synchrony) to guarantee liveness. Purely\nasynchronous BFT protocols have received considerably less attention in recent years. Consider the following argument, which, if it held, would justify this narrowed focus:\nWeak synchrony assumptions are unavoidable, since in any\nnetwork that violates these assumptions, even asynchronous\nprotocols would provide unacceptable performance.\nIn this section, we present two counterarguments that refute\nthe premise above. First, we illustrate the theoretical separation\nbetween the asynchronous and weakly synchronous network models.\nSpecifically we construct an adversarial network scheduler that\nviolates PBFT’s weak synchrony assumption (and indeed causes it\nto fail) but under which any purely asynchronous protocol (such\nas HoneyBadgerBFT) makes good progress. Second, we make a\npractical observation: even when their assumptions are met, weakly synchronous protocols are slow to recover from a network partition once it heals, whereas asynchronous protocols make progress as soon as messages are delivered\nSpecifically we construct an adversarial network scheduler that\nviolates PBFT’s weak synchrony assumption (and indeed causes it\nto fail) but under which any purely asynchronous protocol (such\nas HoneyBadgerBFT) makes good progress. Second, we make a\npractical observation: even when their assumptions are met, weakly synchronous protocols are slow to recover from a network partition once it heals, whereas asynchronous protocols make progress as soon as messages are delivered\nThe intuition behind our scheduler is simple. First, we assume\nthat a single node has crashed. Then, the network delays messages whenever a correct node is the leader, preventing progress and causing the next node in round-robin order to become the new leader. When the crashed node is the next up to become the leader, the scheduler immediately heals the network partition and delivers messages very rapidly among the honest nodes; however, since the leader has crashed, no progress is made here either.\nThis attack violates the weak synchrony assumption because it\nmust delay messages for longer and longer each cycle, since PBFT widens its timeout interval after each failed leader election.\nOn the other hand, it provides larger and larger periods of synchrony as well.\nHowever, since these periods of synchrony occur at inconvenient\ntimes, PBFT is unable to make use of them. Looking ahead, HoneyBadgerBFT, and indeed any asynchronous protocol, would be able to make progress during these opportunistic periods of synchrony. To confirm our analysis, we implemented this malicious scheduler as a proxy that intercepted and delayed all view change messages to the new leader, and tested it against a 1200 line Python implementation of PBFT. The results and message logs we observed were consistent with the above analysis; our replicas became stuck in a loop requesting view changes that never succeeded.\n\n post by kladkogex on Mar 1, 2018\n\n kladkogex\n\n I am not claiming to be a super expert in this, but imho it is a question whether a proof under a weak synchrony assumption is equivalent to a proof that a system will never get totally stuck in a real network …\n\n Powered by Discourse","tokens":4540,"squid":"ink-research","role":"Deep Scholar","at":1791267079773,"hash":"c897f3a5a7cdcf750a0c9b2372bd4afb9def85ff"}
{"url":"https://docs.base.org/specifications/build-transaction/base_sendRawTransactionValidity","domain":"docs.base.org","title":"Validity Transaction RPC - Base Documentation","text":"{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"method\": \"base_sendRawTransactionValidity\",\n \"params\": [\n \"0x<signed-raw-transaction>\",\n {\n \"validity\": [\n {\n \"type\": \"storage\",\n \"params\": {\n \"address\": \"0x8ba1f109551bD432803012645Ac136ddd64DBA72\",\n \"slot\": \"0x8\",\n \"mask\": \"0xff\",\n \"op\": \"=\",\n \"value\": \"0x2a\"\n }\n }\n ]\n }\n ]\n}\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 1,\n \"method\": \"base_sendRawTransactionValidity\",\n \"params\": [\n \"0x<signed-raw-transaction>\",\n {\n \"validity\": [\n {\n \"type\": \"storage\",\n \"params\": {\n \"address\": \"0x8ba1f109551bD432803012645Ac136ddd64DBA72\",\n \"slot\": \"0x8\",\n \"mask\": \"0xff\",\n \"op\": \"=\",\n \"value\": \"0x2a\"\n }\n }\n ]\n }\n ]\n}\nSubmits a signed legacy, EIP-2930, or EIP-1559 transaction with predicates that control when Base can include it. EIP-1559 is recommended.\nThis method is available on Base Mainnet and Base Sepolia through the sequencer endpoints listed in Connect to Base, and on Vibenet.\n​Parameters\nPass two parameters. The first is a signed, serialized transaction. The second contains a non-empty validity array.\n\n​Predicates\nTypeParametersstorageaddress, slot, op, value, optional maskblock_numberop, valueflashblock_indexop, value\nThe supported operators are <, <=, =, !=, >, and >=. Predicate values use 0x-prefixed hexadecimal strings. The mask defaults to all ones.\nA flashblock_index value must be between 1 and 10, inclusive (0x1 through 0xa in hexadecimal).\n​Returns\n​stringThe 32-byte hash of the submitted transaction.\nReturning a hash confirms acceptance. It does not confirm inclusion.\n​Errors\nThe method returns JSON-RPC errors. Handle an unavailable method, invalid parameters, and a missing transaction hash.\nError codes and messages are not yet stable.\nRead Predicates and Safety for evaluation rules. Read Troubleshooting when a transaction is not included.Was this page helpful?Suggest editsRaise issue","tokens":458,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267085030,"hash":"8dcbcda123210a4916de5be2fbb68f62ecd12a3f"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/contributing.html","domain":"docs.soliditylang.org","title":"Contributing — Solidity 0.8.31-develop documentation","text":"Contributing\n\n Edit on GitHub\n\nContributing\nHelp is always welcome and there are plenty of options to contribute to Solidity.\nIn particular, we appreciate support in the following areas:\n\nReporting issues.\nFixing and responding to Solidity’s GitHub issues, especially those tagged as\n“good first issue” which are\nmeant as introductory issues for external contributors.\nImproving the documentation.\nTranslating the documentation into more languages.\nResponding to questions from other users on StackExchange and the Solidity Gitter Chat.\nGetting involved in the language design process by proposing language changes or new features in the Solidity forum and providing feedback.\n\nTo get started, you can try Building from Source in order to familiarize\nyourself with the components of Solidity and the build process. Also, it may be\nuseful to become well-versed at writing smart-contracts in Solidity.\nPlease note that this project is released with a Contributor Code of Conduct. By participating in this project — in the issues, pull requests, or Gitter channels — you agree to abide by its terms.\n\nTeam Calls\nIf you have issues or pull requests to discuss, or are interested in hearing what\nthe team and contributors are working on, you can join our public team call:\n\nWednesdays at 3PM CET/CEST.\n\nThe call takes place on Jitsi.\n\nHow to Report Issues\nTo report an issue, please use the\nGitHub issues tracker. When\nreporting issues, please mention the following details:\n\nSolidity version.\nSource code (if applicable).\nOperating system.\nSteps to reproduce the issue.\nActual vs. expected behavior.\n\nReducing the source code that caused the issue to a bare minimum is always\nvery helpful, and sometimes even clarifies a misunderstanding.\nFor technical discussions about language design, a post in the\nSolidity forum is the correct place (see Solidity Language Design).\n\nWorkflow for Pull Requests\nIn order to contribute, please fork off of the develop branch and make your\nchanges there. Your commit messages should detail why you made your change\nin addition to what you did (unless it is a tiny change).\nIf you need to pull in any changes from develop after making your fork (for\nexample, to resolve potential merge conflicts), please avoid using git merge\nand instead, git rebase your branch. This will help us review your change\nmore easily.\nAdditionally, if you are writing a new feature, please ensure you add appropriate\ntest cases under test/ (see below).\nHowever, if you are making a larger change, please consult with the Solidity Development Gitter channel (different from the one mentioned above — this one is\nfocused on compiler and language development instead of language usage) first.\nNew features and bugfixes should be added to the Changelog.md file: please\nfollow the style of previous entries, when applicable.\nFinally, please make sure you respect the coding style\nfor this project. Also, even though we do CI testing, please test your code and\nensure that it builds locally before submitting a pull request.\nWe highly recommend going through our review checklist before submitting the pull request.\nWe thoroughly review every PR and will help you get it right, but there are many common problems that can be easily avoided, making the review much smoother.\nThank you for your help!\n\nRunning the Compiler Tests\n\nPrerequisites\nFor running all compiler tests you may want to optionally install a few\ndependencies (evmone,\nz3, Eldarica,\ncvc5 <https://github.com/cvc5/cvc5>).\nOn macOS systems, some of the testing scripts expect GNU coreutils to be installed.\nThis can be easiest accomplished using Homebrew: brew install coreutils.\nOn Windows systems, make sure that you have a privilege to create symlinks,\notherwise several tests may fail.\nAdministrators should have that privilege, but you may also\ngrant it to other users\nor\nenable Developer Mode.\n\nRunning the Tests\nSolidity includes different types of tests, most of them bundled into the\nBoost C++ Test Framework application soltest.\nRunning build/test/soltest or its wrapper scripts/soltest.sh is sufficient for most changes.\nThe ./scripts/tests.sh script executes most Solidity tests automatically,\nincluding those bundled into the Boost C++ Test Framework\napplication soltest (or its wrapper scripts/soltest.sh), as well as command-line tests and\ncompilation tests.\nThe test system automatically tries to discover the location of\nthe evmone for running the semantic tests.\nThe evmone library must be located in the deps or deps/lib directory relative to the\ncurrent working directory, to its parent or its parent’s parent. Alternatively, an explicit location\nfor the evmone shared object can be specified via the ETH_EVMONE environment variable.\nevmone is needed mainly for running semantic and gas tests.\nIf you do not have it installed, you can skip these tests by passing the --no-semantic-tests\nflag to scripts/soltest.sh.\nThe evmone library should end with the file name\nextension .so on Linux, .dll on Windows systems and .dylib on macOS.\nFor running SMT tests, the z3 executable must be present in PATH.\nA few SMT tests use Eldarica instead of z3.\nThese require its executable (eld) to be present in PATH for the tests to pass.\nHowever, if Eldarica is not found, these tests will be automatically skipped.\nIf z3 is not present on your system, you should disable the\nSMT tests by exporting SMT_FLAGS=--no-smt before running ./scripts/tests.sh or\nrunning ./scripts/soltest.sh --no-smt.\nThese tests are libsolidity/smtCheckerTests.\n\nNote\nTo get a list of all unit tests run by Soltest, run ./build/test/soltest --list_content=HRF.\n\nFor quicker results you can run a subset of, or specific tests.\nTo run a subset of tests, you can use filters:\n./scripts/soltest.sh -t TestSuite/TestName,\nwhere TestName can be a wildcard *.\nOr, for example, to run all the tests for the yul disambiguator:\n./scripts/soltest.sh -t \"yulOptimizerTests/disambiguator/*\" --no-smt.\n./build/test/soltest --help has extensive help on all of the options available.\nSee especially:\n\nshow_progress (-p) to show test completion,\nrun_test (-t) to run specific tests cases, and\nreport-level (-r) give a more detailed report.\n\nNote\nThose working in a Windows environment wanting to run the above basic sets\nwithout z3. Using Git Bash, you use: ./build/test/Release/soltest.exe -- --no-smt.\nIf you are running this in plain Command Prompt, use .\\build\\test\\Release\\soltest.exe -- --no-smt.\n\nIf you want to debug using GDB, make sure you build differently than the “usual”.\nFor example, you could run the following command in your build folder:\ncmake -DCMAKE_BUILD_TYPE=Debug ..\nmake\n\nThis creates symbols so that when you debug a test using the --debug flag,\nyou have access to functions and variables in which you can break or print with.\nThe CI runs additional tests (including solc-js and testing third party Solidity\nframeworks) that require compiling the Emscripten target.\n\nWriting and Running Syntax Tests\nSyntax tests check that the compiler generates the correct error messages for invalid code\nand properly accepts valid code.\nThey are stored in individual files inside the tests/libsolidity/syntaxTests folder.\nThese files must contain annotations, stating the expected result(s) of the respective test.\nThe test suite compiles and checks them against the given expectations.\nFor example: ./test/libsolidity/syntaxTests/double_stateVariable_declaration.sol\nopen in Remix\ncontract test {\n uint256 variable;\n uint128 variable;\n}\n// ----\n// DeclarationError: (36-52): Identifier already declared.\n\nA syntax test must contain at least the contract under test itself, followed by the separator // ----. The comments that follow the separator are used to describe the\nexpected compiler errors or warnings. The number range denotes the location in the source where the error occurred.\nIf you want the contract to compile without any errors or warning you can leave\nout the separator and the comments that follow it.\nIn the above example, the state variable variable was declared twice, which is not allowed. This results in a DeclarationError stating that the identifier was already declared.\nThe isoltest tool is used for these tests and you can find it under ./build/test/tools/. It is an interactive tool which allows\nediting of failing contracts using your preferred text editor. Let’s try to break this test by removing the second declaration of variable:\nopen in Remix\ncontract test {\n uint256 variable;\n}\n// ----\n// DeclarationError: (36-52): Identifier already declared.\n\nRunning ./build/test/tools/isoltest again results in a test failure:\nsyntaxTests/double_stateVariable_declaration.sol: FAIL\n Contract:\n contract test {\n uint256 variable;\n }\n\n Expected result:\n DeclarationError: (36-52): Identifier already declared.\n Obtained result:\n Success\n\nisoltest prints the expected result next to the obtained result, and also\nprovides a way to edit, update or skip the current contract file, or quit the application.\nIt offers several options for failing tests:\n\nedit: isoltest tries to open the contract in an editor so you can adjust it. It either uses the editor given on the command-line (as isoltest --editor /path/to/editor), in the environment variable EDITOR or just /usr/bin/editor (in that order).\nupdate: Updates the expectations for contract under test. This updates the annotations by removing unmet expectations and adding missing expectations. The test is then run again.\nskip: Skips the execution of this particular test.\nquit: Quits isoltest.\n\nAll of these options apply to the current contract, except quit which stops the entire testing process.\nAutomatically updating the test above changes it to\nopen in Remix\ncontract test {\n uint256 variable;\n}\n// ----\n\nand re-run the test. It now passes again:\nRe-running test case...\nsyntaxTests/double_stateVariable_declaration.sol: OK\n\nNote\nChoose a name for the contract file that explains what it tests, e.g. double_variable_declaration.sol.\nDo not put more than one contract into a single file, unless you are testing inheritance or cross-contract calls.\nEach file should test one aspect of your new feature.\n\nCommand-line Tests\nOur suite of end-to-end command-line tests checks the behaviour of the compiler binary as a whole\nin various scenarios.\nThese tests are located in test/cmdlineTests/,\none per subdirectory, and can be executed using the cmdlineTests.sh script.\nBy default the script runs all available tests.\nYou can also provide one or more file name patterns,\nin which case only the tests matching at least one pattern will be executed.\nIt is also possible to exclude files matching a specific pattern by prefixing it with --exclude.\nBy default the script assumes that a solc binary is available inside the build/ subdirectory\ninside the working copy.\nIf you build the compiler outside of the source tree, you can use the SOLIDITY_BUILD_DIR environment\nvariable to specify a different location for the build directory.\nExample:\nexport SOLIDITY_BUILD_DIR=~/solidity/build/\ntest/cmdlineTests.sh \"standard_*\" \"*_yul_*\" --exclude \"standard_yul_*\"\n\nThe commands above will run tests from directories starting with test/cmdlineTests/standard_ and\nsubdirectories of test/cmdlineTests/ that have _yul_ somewhere in the name,\nbut no test whose name starts with standard_yul_ will be executed.\nIt will also assume that the file solidity/build/solc/solc inside your home directory is the\ncompiler binary (unless you are on Windows – then solidity/build/solc/Release/solc.exe).\nThere are several kinds of command-line tests:\n\nStandard JSON test: contains at least an input.json file.\nIn general may contain:\n\ninput.json: input file to be passed to the --standard-json option on the command line.\noutput.json: expected Standard JSON output.\nargs: extra command-line arguments passed to solc.\n\nCLI test: contains at least an input.* file (other than input.json).\nIn general may contain:\n\ninput.*: a single input file, whose name will be supplied to solc on the command line.\nUsually input.sol or input.yul.\nargs: extra command-line arguments passed to solc.\nstdin: content to be passed to solc via standard input.\noutput: expected content of the standard output.\nerr: expected content of the standard error output.\nexit: expected exit code. If not provided, zero is expected.\n\nScript test: contains a test.* file.\nIn general may contain:\n\ntest.*: a single script to run, usually test.sh or test.py.\nThe script must be executable.\n\nRunning the Fuzzer via AFL\nFuzzing is a technique that runs programs on more or less random inputs to find exceptional execution\nstates (segmentation faults, exceptions, etc). Modern fuzzers are clever and run a directed search\ninside the input. We have a specialized binary called solfuzzer which takes source code as input\nand fails whenever it encounters an internal compiler error, segmentation fault or similar, but\ndoes not fail if e.g., the code contains an error. This way, fuzzing tools can find internal problems in the compiler.\nWe mainly use AFL for fuzzing. You need to download and\ninstall the AFL packages from your repositories (afl, afl-clang) or build them manually.\nNext, build Solidity (or just the solfuzzer binary) with AFL as your compiler:\ncd build\n# if needed\nmake clean\ncmake .. -DCMAKE_C_COMPILER=path/to/afl-gcc -DCMAKE_CXX_COMPILER=path/to/afl-g++\nmake solfuzzer\n\nAt this stage, you should be able to see a message similar to the following:\nScanning dependencies of target solfuzzer\n[ 98%] Building CXX object test/tools/CMakeFiles/solfuzzer.dir/fuzzer.cpp.o\nafl-cc 2.52b by <lcamtuf@google.com>\nafl-as 2.52b by <lcamtuf@google.com>\n[+] Instrumented 1949 locations (64-bit, non-hardened mode, ratio 100%).\n[100%] Linking CXX executable solfuzzer\n\nIf the instrumentation messages did not appear, try switching the cmake flags pointing to AFL’s clang binaries:\n# if previously failed\nmake clean\ncmake .. -DCMAKE_C_COMPILER=path/to/afl-clang -DCMAKE_CXX_COMPILER=path/to/afl-clang++\nmake solfuzzer\n\nOtherwise, upon execution the fuzzer halts with an error saying binary is not instrumented:\nafl-fuzz 2.52b by <lcamtuf@google.com>\n... (truncated messages)\n[*] Validating target binary...\n\n[-] Looks like the target binary is not instrumented! The fuzzer depends on\n compile-time instrumentation to isolate interesting test cases while\n mutating the input data. For more information, and for tips on how to\n instrument binaries, please see /usr/share/doc/afl-doc/docs/README.\n\n When source code is not available, you may be able to leverage QEMU\n mode support. Consult the README for tips on how to enable this.\n (It is also possible to use afl-fuzz as a traditional, \"dumb\" fuzzer.\n For that, you can use the -n option - but expect much worse results.)\n\n[-] PROGRAM ABORT : No instrumentation detected\n Location : check_binary(), afl-fuzz.c:6920\n\nNext, you need some example source files. This makes it much easier for the fuzzer\nto find errors. You can either copy some files from the syntax tests or extract test files\nfrom the documentation or the other tests:\nmkdir /tmp/test_cases\ncd /tmp/test_cases\n# extract from tests:\npath/to/solidity/scripts/isolate_tests.py path/to/solidity/test/libsolidity/SolidityEndToEndTest.cpp\n# extract from documentation:\npath/to/solidity/scripts/isolate_tests.py path/to/solidity/docs\n\nThe AFL documentation states that the corpus (the initial input files) should not be\ntoo large. The files themselves should not be larger than 1 kB and there should be\nat most one input file per functionality, so better start with a small number of.\nThere is also a tool called afl-cmin that can trim input files\nthat result in similar behavior of the binary.\nNow run the fuzzer (the -m extends the size of memory to 60 MB):\nafl-fuzz -m 60 -i /tmp/test_cases -o /tmp/fuzzer_reports -- /path/to/solfuzzer\n\nThe fuzzer creates source files that lead to failures in /tmp/fuzzer_reports.\nOften it finds many similar source files that produce the same error. You can\nuse the tool scripts/uniqueErrors.sh to filter out the unique errors.\n\nWhiskers\nWhiskers is a string templating system similar to Mustache. It is used by the\ncompiler in various places to aid readability, and thus maintainability and verifiability, of the code.\nThe syntax comes with a substantial difference to Mustache. The template markers {{ and }} are\nreplaced by < and > in order to aid parsing and avoid conflicts with Yul\n(The symbols < and > are invalid in inline assembly, while { and } are used to delimit blocks).\nAnother limitation is that lists are only resolved one depth and they do not recurse. This may change in the future.\nA rough specification is the following:\nAny occurrence of <name> is replaced by the string-value of the supplied variable name without any\nescaping and without iterated replacements. An area can be delimited by <#name>...</name>. It is replaced\nby as many concatenations of its contents as there were sets of variables supplied to the template system,\neach time replacing any <inner> items by their respective value. Top-level variables can also be used\ninside such areas.\nThere are also conditionals of the form <?name>...<!name>...</name>, where template replacements\ncontinue recursively either in the first or the second segment depending on the value of the boolean\nparameter name. If <?+name>...<!+name>...</+name> is used, then the check is whether\nthe string parameter name is non-empty.\n\nDocumentation Style Guide\nIn the following section you find style recommendations specifically focusing on documentation\ncontributions to Solidity.\n\nEnglish Language\nUse International English, unless using project or brand names. Try to reduce the usage of\nlocal slang and references, making your language as clear to all readers as possible.\nBelow are some references to help:\n\nSimplified technical English\nInternational English\n\nNote\nWhile the official Solidity documentation is written in English, there are community contributed Translations\nin other languages available. Please refer to the translation guide\nfor information on how to contribute to the community translations.\n\nTitle Case for Headings\nUse title case for headings. This means capitalise all principal words in\ntitles, but not articles, conjunctions, and prepositions unless they start the\ntitle.\nFor example, the following are all correct:\n\nTitle Case for Headings.\nFor Headings Use Title Case.\nLocal and State Variable Names.\nOrder of Layout.\n\nExpand Contractions\nUse expanded contractions for words, for example:\n\n“Do not” instead of “Don’t”.\n“Can not” instead of “Can’t”.\n\nActive and Passive Voice\nActive voice is typically recommended for tutorial style documentation as it\nhelps the reader understand who or what is performing a task. However, as the\nSolidity documentation is a mixture of tutorials and reference content, passive\nvoice is sometimes more applicable.\nAs a summary:\n\nUse passive voice for technical reference, for example language definition and internals of the Ethereum VM.\nUse active voice when describing recommendations on how to apply an aspect of Solidity.\n\nFor example, the below is in passive voice as it specifies an aspect of Solidity:\n\nFunctions can be declared pure in which case they promise not to read\nfrom or modify the state.\n\nFor example, the below is in active voice as it discusses an application of Solidity:\n\nWhen invoking the compiler, you can specify how to discover the first element\nof a path, and also path prefix remappings.\n\nCommon Terms\n\n“Function parameters” and “return variables”, not input and output parameters.\n\nCode Examples\nA CI process tests all code block formatted code examples that begin with pragma solidity, contract, library\nor interface using the ./test/cmdlineTests.sh script when you create a PR. If you are adding new code examples,\nensure they work and pass tests before creating the PR.\nEnsure that all code examples begin with a pragma version that spans the largest where the contract code is valid.\nFor example pragma solidity >=0.4.0 <0.9.0;.\n\nRunning Documentation Tests\nMake sure your contributions pass our documentation tests by running ./docs/docs.sh that installs dependencies\nneeded for documentation and checks for any problems such as broken links or syntax issues.\n\nSolidity Language Design\nTo actively get involved in the language design process and to share your ideas concerning the future of Solidity,\nplease join the Solidity forum.\nThe Solidity forum serves as the place to propose and discuss new language features and their implementation in\nthe early stages of ideation or modifications of existing features.\nAs soon as proposals get more tangible, their\nimplementation will also be discussed in the Solidity GitHub repository\nin the form of issues.\nIn addition to the forum and issue discussions, we regularly host language design discussion calls in which selected\ntopics, issues or feature implementations are debated in detail. The invitation to those calls is shared via the forum.\nWe are also sharing feedback surveys and other content that is relevant to language design in the forum.\nIf you want to know where the team is standing in terms of implementing new features, you can follow the implementation status in the Solidity GitHub project.\nIssues in the design backlog need further specification and will either be discussed in a language design call or in a regular team call. You can\nsee the upcoming changes for the next breaking release by changing from the default branch (develop) to the breaking branch.\nFor ad-hoc cases and questions, you can reach out to us via the Solidity-dev Gitter channel — a\ndedicated chatroom for conversations around the Solidity compiler and language development.\nWe are happy to hear your thoughts on how we can improve the language design process to be even more collaborative and transparent.","tokens":5457,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267085066,"hash":"de3c3872734c000e22bf23a644321b3e98a6753d"}
{"url":"https://forum.pyth.network/t/july-2026-pyth-purchases-report/2658/2","domain":"forum.pyth.network","title":"July 2026 — PYTH Purchases Report - PYTH Reserves - Pyth DAO","text":"PYTH Reserves\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n 2\n\n Aug 3\n\n 2 / 4\n\n Aug 31\n\n Sep 3\n\n post by Frozenmind on Aug 3\n\n Frozenmind\n\n On July 29th, 2026, the Pyth DAO, via the OP-PIP-123.V2, approved the usage of 1/3 of the Pyth DAO Treasury to monthly purchases PYTH tokens. These purchases are administered and executed by the Pythian Council.\n\nOn July 29th, 2026, the Pythian Council Ops Multisig received the following from the Pyth DAO Treasury:\n\n38,552.13 USDC\n101.92 SOL\n\nSubsequently, the Pythian Council, exercising no independent discretion and acting only pursuant to the DAO’s instructions within the OP-PIP parameters, executed the following transactions:\n\n38,552.13 USDC <> 957,686.90 PYTH\n102 SOL <> 186,942.23 PYTH\n\nLast but not least, the Pythian Council sent back to the Pyth DAO Treasury the following:\n\n1,144,629.131118 PYTH\n\nYou may review all tokens transfers, and swaps here.\n\n 2\n\n 2\n\n 27 days later\n\n post by Joy on Aug 31\n\n Joy\n\n It would be good to set a fixed date for purchases and post on that date. For example, like purchasing on the 1st of every month and posting on the 1st.\n\n post by Frozenmind on Aug 31\n\n Frozenmind\n\n Thanks for the suggestion. Just to clarify, the intention here is indeed to use a DCA approach over a longer period of time, rather than have the Council make a single discretionary purchase at some random point during the month.\nThe framework was established through OP-PIP-87 and the subsequent monthly purchase PIPs. The mandate gives the Council some flexibility in how the purchases are executed, with the objective of accumulating PYTH efficiently on the secondary market. This can include limit orders, smaller market orders, and standard swaps when appropriate, particularly for lower volumes. The July purchase was executed under OP-PIP-123.V2.\nWhile the report presents the monthly activity as a consolidated purchase, the actual execution is structured around this longer-term DCA approach. All of the details are also included in the spreadsheet linked in the report.\nAs for the timing of the reports, I’ve been handling these reports for the past several months, and our goal is always to have them published as close as possible to the end of the month. That said, because we operate through a multisig structure, there are sometimes a few additional steps involved that can result in the report being published a few days into the following month.\nImportantly, this doesn’t mean the activity is happening behind the scenes. All transactions involving the Pythian Council multisig can be followed on-chain as they happen, including the DCA executions through Jupiter DCA, which is integrated directly with the Squads multisig. So the transactions are publicly verifiable in real time, even if the consolidated report itself takes a few extra days to publish.\n\n post by Joy on Sep 3\n\n Joy\n\n Thank you for your reply. I do not mean to deny your efforts. I was simply thinking it would be good to post on a fixed schedule, but your response has helped me understand. Have a nice day.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n August 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 125\n\n Sep 2\n\n March 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 145\n\n Mar 30\n\n June 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 126\n\n Jul 6\n\n February 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 133\n\n Mar 2\n\n April 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 145\n\n Apr 28","tokens":886,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267097315,"hash":"f3d90dc600e15288b14de997866d8e49cb99fb10"}
{"url":"https://forum.pyth.network/latest","domain":"forum.pyth.network","title":"Latest topics - Pyth DAO","text":"All latest topics\n\n categories\n\n tags\n\n Categories\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n READ FIRST: How to Use the Ideas Bank\n\n Ideas Bank\n\n The Ideas Bank is for Pyth community members to suggest, discuss, and debate early-stage ideas before the proposal stage. \nIf you wish to create a new topic regarding Oracle Integrity Staking (OIS), please create it in t…\n\n read more\n\n 0\n\n 1.0k\n\n May 2024\n\n About the Pyth DAO\n\n About the Pyth DAO\n\n The Pyth DAO LLC, is legally structured as “a non-profit DAO LLC formed under the laws of the Republic of Marshall Islands, formed to serve the Pyth DAO LLC” (of which the OPERATING AGREEMENT OF PYTH DAO LLC is available…\n\n read more\n\n 0\n\n 1.8k\n\n Apr 2024\n\n Understanding the Forum Categories\n\n About the Pyth DAO\n\n To facilitate productive and clear discussions about the Pyth Network, or the Pyth DAO, it is important to respect the guidelines established to discuss any relevant matter in the appropriate categories. \nCategories: \nAb…\n\n read more\n\n 0\n\n 842\n\n May 2024\n\n Pyth Pro: Douro Labs Report – September 2026\n\n Pyth Pro\n\n 0\n\n 33\n\n 18h\n\n September 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 101\n\n 5d\n\n [PASSED] CO-PIP-138: Reclaim Unused Pythnet Governance SOL\n\n Proposals\n\n constitutional-pip\n\n 2\n\n 95\n\n 7d\n\n Pyth Isn’t Competing Anymore, It’s Just the Standard\n\n Community Library\n\n 3\n\n 124\n\n 8d\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 271\n\n 9d\n\n [PASSED] OP-PIP-136: Pyth Strategic Reserve V2\n\n Proposals\n\n operational-pip\n\n 2\n\n 212\n\n 9d\n\n [PASSED] CO-PIP-137: PPR Vesting Schedule Correction\n\n Proposals\n\n constitutional-pip\n\n 0\n\n 91\n\n 11d\n\n August Just Made Pyth’s Lead Even Bigger\n\n Community Library\n\n 3\n\n 92\n\n 21d\n\n Pyth Strategic Reserve V2: Aligning PYTH Accumulation with Pyth Pro Revenue\n\n Ideas Bank\n\n 5\n\n 322\n\n 27d\n\n [PASSED] OP-PIP-135: PYTH Token Phase 2 — Purchases #10\n\n Proposals\n\n operational-pip\n\n 0\n\n 139\n\n 27d\n\n Should We Move the Pyth Wheel Back to Base or Monad?\n\n Ideas Bank\n\n 5\n\n 136\n\n 27d\n\n Pyth Pro: Douro Labs Report – August 2026\n\n Pyth Pro\n\n 0\n\n 142\n\n 28d\n\n July 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 3\n\n 195\n\n Sep 3\n\n August 2026 — PYTH Purchases Report\n\n PYTH Reserves\n\n 0\n\n 125\n\n Sep 2\n\n Pyth owns the on-chain RWA perps market now!\n\n Community Library\n\n 2\n\n 105\n\n Sep 1\n\n Whitepaper (September 28, 2023)\n\n About the Pyth DAO\n\n 0\n\n 40\n\n Sep 1\n\n Proposal: Introduce PYTH as an Optional Payment Token for Pyth Network Services\n\n Ideas Bank\n\n 3\n\n 91\n\n Aug 31\n\n Idea Proposal: Community Custom Indices on Pyth Pro\n\n Ideas Bank\n\n operational-pip\n\n 9\n\n 184\n\n Aug 31\n\n Pythenians II. Scope of work & budget request\n\n Ideas Bank\n\n 10\n\n 488\n\n Aug 31\n\n [PASSED] OP-PIP-134: Q3 2026 — Pyth Entropy Protocol Fee Adjustments and Fee Repatriation\n\n Proposals\n\n operational-pip\n\n 0\n\n 75\n\n Aug 31\n\n Proposal: Introduce PYTH as a Payment Option for Pyth Network Services\n\n Ideas Bank\n\n 0\n\n 39\n\n Aug 29\n\n HIP-3 and Pyth: How Anyone With 500k HYPE Can Deploy a Perp DEX\n\n Community Library\n\n 0\n\n 44\n\n Aug 26\n\n [PASSED] OP-PIP-133: Abstract — Pyth Upgraded Core\n\n Proposals\n\n operational-pip\n\n 0\n\n 77\n\n Aug 26\n\n [PASSED] OP-PIP-132: Pyth Core Deprecation (EVM)\n\n Proposals\n\n operational-pip\n\n 0\n\n 78\n\n Aug 25\n\n [PASSED] OP-PIP-131: Pyth Core Deprecation (SVM)\n\n Proposals\n\n operational-pip\n\n 0\n\n 77\n\n Aug 25\n\n [PASSED] OP-PIP-130: Pyth Core — Additional Contract Upgrades and Fee Balance Repatriation\n\n Proposals\n\n operational-pip\n\n 0\n\n 55\n\n Aug 19\n\n [PASSED] OP-PIP-129: PYTH Token Phase 2 — Purchases #9\n\n Proposals\n\n operational-pip\n\n 0\n\n 123\n\n Aug 19","tokens":907,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267119368,"hash":"6181b4abc08c12bcdcc38fbd24c1d44c218af4a4"}
{"url":"https://docs.optimism.io/op-stack/security/faq-sec-model","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Many OP Stack chains, such as OP Mainnet, are a work in progress.\nConstant, iterative improvement of the security mechanisms that safeguard OP Stack users is a top priority for Optimism.\nOptimism strives to be clear and transparent about the security of OP Stack chains and the OP Stack as a whole.\n​Bottom line\nThe security model of any blockchain system is only as strong as its lowest common denominator.\nAt the moment, it’s important to understand that the security of OP Stack chains is dependent on a multisig managed jointly by the Optimism Security Council and the Optimism Foundation.\nOP Stack chains may also contain unknown bugs that could lead to the loss of some or all of the ETH or tokens held within the system.\n​OP Stack multisig\nThe security of OP Stack chains is currently dependent on a multisig managed jointly by the Optimism Security Council and the Optimism Foundation.\nThis multisig is a 2-of-2 nested multisig which is in turn governed by a 10-of-13 multisig managed by the Optimism Security Council and a 5-of-7 multisig managed by the Optimism Foundation.\nThis multisig can be used to upgrade core OP Stack smart contracts without upgrade delays to allow for quick responses to potential security concerns.\nAll upgrades to the OP Stack system must be approved by both component multisigs and either can veto an upgrade.\n​Fault proofs\nIt is important to understand that fault proofs are not a silver bullet and that fault proofs provide limited improvements to the security of a system if the system still has a multisig or security council that can instantly upgrade the system.\nOP Stack chains are following a multi-client and multi-proof approach designed to eventually remove the need for instant upgrades entirely.\nUsers can withdraw ETH and tokens from OP Stack chains to Ethereum by submitting a withdrawal proof that shows the withdrawal was actually included inside of the OP Stack chain.\nWithdrawals are proven against proposals about the state of the chain that are published through the DisputeGameFactory contract.\nProposals can be submitted to the DisputeGameFactory contract by any user and submissions do not require any special permissions.\nEach submitted proposal creates a FaultDisputeGame contract that allows any other user to challenge the validity of a proposal by participating in a “fault proof” process.\nA more detailed explanation of the fault proof game can be found in the Fault Proofs Explainer.\nAlthough the fault proof game is permissionless, the Optimism Security Council acting as the Guardian role provides a backstop in case of a failure in the fault proof game.\nEach proposal must wait for a delay period during which the Guardian can prevent invalid proposals from being used to withdraw ETH or tokens through a number of safety hatches.\nThe Guardian can also choose to shift the system to use a PermissionedDisputeGame in which only specific PROPOSER and CHALLENGER roles can submit and challenge proposals.\n​Bugs and unknowns\nPlease also keep in mind that just like any other system, the Optimism codebase may contain unknown bugs that could lead to the loss of some or all of the ETH or tokens held within the system.\nThe OP Stack has been audited on many occasions (as of v1.1.4), but audits are not a stamp of approval and a completed audit does not mean that the audited codebase is free of bugs.\nIt’s important to understand that using OP Stack chains inherently exposes you to the risk of bugs within the Optimism codebase, and that you use these chains at your own risk.\n​Work in progress\n​Sequencer decentralization\nThe Optimism Foundation currently operates the sole sequencer on OP Stack chains.\nAlthough users can always bypass the Sequencer by sending transactions directly to the OptimismPortal contract, sequencer decentralization can still help mitigate the effect of short-term outages for users.\n​Security model FAQ\n​Do OP Stack chains have fault proofs?\nYes, fault proofs are available to OP Stack chains.\nIt is important to note that fault proofs are not a silver bullet and that fault proofs provide limited improvements to the security of a system if the system still has a multisig or security council that can instantly upgrade the system.\nA system with fast upgrade keys, such as OP Mainnet, is fully dependent on the upgrade keys for security.\nThe goal is to be the first system that deploys fault proofs that can secure the system by themselves, without fast upgrade keys.\n​How is Optimism planning to remove the multisig?\nCheck out Optimism’s detailed Pragmatic Path to Decentralization post for a detailed view into how the multisig may be removed in a way that makes OP Stack chains the first with true fault proof security.\n​How can I help make OP Stack chains more secure?\nOP Stack has one of the biggest bug bounties (ever).\nYou can earn up to $2,000,042 by finding critical bugs in the Optimism codebase.\nYou can also run your own verifier node to detect network faults.\n​Where do I report bugs?\nFor details about reporting vulnerabilities and available bug bounty programs, see the Security Policy.\n​Is every OP Stack chain safe?\nThe security model of an OP Stack based blockchain depends on the modules used for its components. Because of the flexibility and permissionless nature of the OP Stack, it is always possible for someone to maliciously or in error set up a chain which does not make use of core security features, but uses other components of OP Stack. The goal of the OP Stack is to provide safe defaults.\nPlease also keep in mind that just like any other system, the OP Stack (or chains built using the OP Stack) may contain unknown bugs that could lead to the loss of some or all of the ETH and tokens held within an OP Stack based system.\nMany components of the OP Stack codebase have been audited (as of v1.1.4), but successful audits do not remove all potential risk from an emerging technology, and a completed audit does not mean that the codebase is completely free of bugs.\nIt’s important to understand that using the OP Stack inherently exposes you to the risk of bugs within the OP Stack codebase.\n​Is the OP Stack safe to modify?\nAs with anything, modify the OP Stack at your own risk. There is no guarantee that modifications to the stack will be safe. If you aren’t entirely sure about what you’re doing, stick with the safer defaults that the OP Stack provides. At the moment, the OP Stack is not particularly amenable to modifications and you should not expect any technical support for modifications that fall outside of the standard Rollup configuration of the stack.Was this page helpful?","tokens":1655,"squid":"ink-governance","role":"Council Listener","at":1791267120480,"hash":"376cbea021d5c0f74d9fc662da4dcd03b6170855"}
{"url":"https://docs.optimism.io/op-stack/protocol/derivation-pipeline","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Normative spec: The derivation pipeline is normatively defined in the L2 chain derivation specification. This page is a short orientation; it does not restate the spec.\nThe derivation pipeline is a fundamental component of the OP Stack protocol, responsible for processing and validating transactions in the Optimism network. It ensures the integrity and security of the blockchain by deriving a consistent state from the sequenced transactions and batches submitted by the sequencer.\n​Key functions of the derivation pipeline\nThe following are key functions of the derivation pipeline:\n\nBatch Submission and Sequencing: Transactions are collected and sequenced into batches by the sequencer. These batches are then submitted to Layer 1 (L1) for finality and inclusion in the blockchain.\nSafe Head and Unsafe Blocks: The derivation pipeline maintains two types of heads: the Safe Head and the Unsafe Head. The Safe Head represents the most recent confirmed state on L1, while the Unsafe Head represents the highest unsafe L2 block that the rollup node knows about. Unsafe Blocks are those that have been sequenced but not yet confirmed on L1 (i.e. those from above the Safe Head up to and including the Unsafe Head).\nReorg and Recovery: If the sequencing window (typically 12 hours) is exceeded without a valid batch being discovered on L1, the pipeline will revert all Unsafe Blocks from that period. The pipeline then progresses using a default block that is empty except for deposits, allowing the network to recover and continue processing new transactions.\n\n​Sequencer window\nThe sequencer window defines the maximum time allowed for batches to be submitted and confirmed on L1. If this window is exceeded, the derivation pipeline takes corrective actions to ensure the network’s integrity and continued operation.\nFor example:\n\nIn a 12-hour sequencing window, if no valid batch is discovered on L1, the pipeline reverts to Unsafe Blocks and uses a default block to move forward.\nIncreasing the window to 24 hours allows nodes to wait longer before reorging out unsafe blocks, but it may introduce additional challenges such as increased resource constraints and difficulty in processing larger batches.\n\n​Configuration and adjustments\nThe sequencerWindowSize parameter is set during the deployment configurations and may be difficult to change once established. It is important for chain operators to carefully consider the appropriate window size to balance network performance and stability.\n​Next steps\n\nFor more detailed information, refer to the derivation pipeline specification.\nHave questions? You can ask a question in the developer support forum.\nWas this page helpful?","tokens":671,"squid":"ink-governance","role":"Council Listener","at":1791267132930,"hash":"15db060afd936ec6dc6f1f456250b48636b858df"}
{"url":"https://forum.pyth.network/t/understanding-the-forum-categories/22/1","domain":"forum.pyth.network","title":"Understanding the Forum Categories - About the Pyth DAO - Pyth DAO","text":"Understanding the Forum Categories \n\n About the Pyth DAO\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n May 2024\n\n 1 / 3\n\n May 2024\n\n May 2024\n\n post by Pyth-DAO on May 9, 2024\n\n Pyth-DAO\n\n To facilitate productive and clear discussions about the Pyth Network, or the Pyth DAO, it is important to respect the guidelines established to discuss any relevant matter in the appropriate categories.\nCategories:\nAbout the Pyth DAO: Discover everything you need to know about the Pyth DAO and how to use this forum.\nIdeas Bank: The Ideas Bank is for Pyth community members to suggest, discuss, and debate early-stage ideas before the proposal stage.\nProposals: The Proposals Category is for Pyth community members to propose changes to the Pyth Network or Pyth DAO, and reach consensus before moving to a formal vote.\nPythian Council: The Pythian Council Category will track the Pythian Council elections and recap Operational PIPs on a weekly basis.\nPrice Feed Council: The Price Feed Council Category will track the Price Feed Council elections and recap Operational PIPs on a weekly basis.\nOracle Integrity Staking: The OIS Category is for Pyth community members to suggest, discuss, and debate early-stage ideas regarding Oracle Integrity Staking before the proposal stage.\nAny changes to the forum categories will be based on community feedback and needs.\n\n Welcome to the Pyth Governance Forum!\n\n Pinned globally on May 9, 2024\n\n Closed on May 9, 2024\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Welcome to the Pyth Governance Forum!\n\n Ideas Bank\n\n 158\n\n 3.7k\n\n Sep 2024\n\n About the Pyth Pro category\n\n Pyth Pro\n\n 0\n\n 68\n\n Dec 2025\n\n READ FIRST: How to Use the Ideas Bank\n\n Ideas Bank\n\n 0\n\n 1.0k\n\n May 2024\n\n Pyth Token Phase 2\n\n Ideas Bank\n\n 35\n\n 1.3k\n\n Feb 26\n\n READ FIRST: How to Use the Oracle Integrity Staking (OIS) Discussion Category\n\n Oracle Integrity Staking (OIS)\n\n 0\n\n 244\n\n Sep 2024","tokens":495,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267132998,"hash":"37c0d3febe4b6b773d9bfb13d15feb5b6024de92"}
{"url":"https://docs.optimism.io/op-stack/protocol/smart-contracts","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Normative spec: The OP Stack contract layer is normatively defined in the Optimism Overview specification. This page is an orientation to the contracts and how they fit together; each contract's behavior and interface are defined in its spec section and its source.\nThe OP Stack’s onchain logic lives in two groups of smart contracts: the\nLayer 1 contracts deployed to Ethereum, and the Layer 2 predeploys that exist\nin every OP Stack chain’s genesis state. This page explains what each group\nis for and routes you to the canonical definition of each contract. It does\nnot restate interfaces, parameters, or per-release versions:\n\nBehavior is defined in the OP Stack specifications.\nSource code lives in packages/contracts-bedrock in the monorepo, with generated interface documentation at devdocs.optimism.io.\nDeployed addresses are on the OP Mainnet addresses page, sourced from the superchain-registry.\n\n​Layer 1 contracts\nThe L1 contracts hold the chain’s bridge liquidity, accept deposits, verify\nwithdrawals, store the chain’s configuration, and adjudicate output proposals\nthrough the fault proof system. The Optimism Overview\nspecification\nincludes an architecture diagram showing how they connect.\n​Bridging and messaging\nDeposits enter the chain and withdrawals leave it through a layered stack:\nthe OptimismPortal is the low-level deposit and withdrawal contract, the\nL1CrossDomainMessenger adds replayable message passing on top of it, and\nthe token bridges sit on top of the messenger. Messages sent directly to the\nOptimismPortal are not replayable, so users and app developers should\nprefer the messenger or bridge interfaces.\nContractRoleNormative specOptimismPortalLow-level deposit entry point and withdrawal exit; withdrawals are proven and finalized against dispute game resultsDeposits, Withdrawals, OptimismPortal fault proof integrationETHLockboxEscrows the ETH deposited through authorized portals, so ETH liquidity can be managed and migrated as a unitETH LockboxL1CrossDomainMessengerReplayable cross-domain message passing between L1 and L2; the recommended messaging interfaceCross Domain MessengersL1StandardBridgeETH and ERC-20 bridging built on the messenger; escrows L1-native tokensStandard BridgesL1ERC721BridgeERC-721 bridging built on the messenger; escrows L1-native NFTsStandard Bridges\nThe standard bridge is not intended to support every ERC-20 variant. Tokens\nwith transfer fees, rebasing logic, or blocklists may not work correctly.\nSee Standard Bridge for\nguidance.\n​Chain configuration\nContractRoleNormative specSystemConfigPer-chain configuration (batcher, gas, fee scalars) read by the derivation pipeline, plus the onchain registry of the chain’s other contract addressesSystem ConfigSuperchainConfigSuperchain-wide configuration and the Guardian’s pause mechanism; pauses are scoped by an identifier and expire automaticallySuperchain Configuration\n​Proposals and fault proofs\nClaims about the L2 state are proposed and challenged permissionlessly\nthrough dispute games rather than trusted output submission. See the fault\nproofs explainer for how the system works\nend to end.\nContractRoleNormative specDisputeGameFactoryDeploys and tracks dispute game instances; the entry point for proposing L2 stateDispute Game InterfaceFaultDisputeGameAdjudicates a claim about L2 state through a bisection game backed by an onchain fault proof VMFault Dispute GamePermissionedDisputeGameA FaultDisputeGame variant restricting participation to a designated proposer and challenger; used where stricter access control is requiredFault Dispute GameAnchorStateRegistryTracks anchor states (recent, unchallenged starting points for new games) and the validity of game resultsAnchorStateRegistryDelayedWETHHolds dispute bonds and delays payouts so bad resolutions can be caught before funds moveBond IncentivesMIPS64Onchain fault proof VM: a big-endian, 64-bit, multithreaded MIPS emulator that executes a single disputed instruction stepCannon Fault Proof VMPreimageOracleServes the preimages of hashed inputs that the fault proof VM reads during a disputed stepPre-image Oracle\n​Legacy and deprecated contracts\n\nAddressManager is a legacy name-to-address registry from the pre-Bedrock\nsystem. It survives only because the L1CrossDomainMessenger still sits\nbehind a legacy ResolvedDelegateProxy that resolves through it.\nL2OutputOracle was the trusted output proposal contract before fault\nproofs. It is deprecated: output proposals are made through the\nDisputeGameFactory instead, per the L2 output root proposals\nspecification.\nProtocolVersions signaled recommended and required protocol versions to\nnode operators. The contract has been removed from the OP Stack contracts;\nthe versioning scheme it exposed remains documented in the Superchain\nUpgrades specification.\n\n​Upgrading the contracts\nL1 contracts are upgraded through the\nOP Contracts Manager (OPCM), which deploys\nand upgrades the L1 contracts as a versioned set. The\nsuperchain-ops\nworkflow drives OPCM under the hood and is the path for chains that require\nSecurity Council signing; other chains can call OPCM directly. op-deployer\nremains the tool for initial deployments, but its upgrade command is\ndeprecated in favor of OPCM; see the\ndeprecation notice.\nL2 predeploys are upgraded through the L2 Contract Manager (L2CM),\nintroduced in Upgrade 19. At a network upgrade, the\nconsensus layer emits a network upgrade transaction that has the L2\nProxyAdmin delegatecall the L2ContractsManager contract, which updates\nevery predeploy implementation in a single atomic transaction, replacing the\nolder practice of per-contract multisig transactions. See the\nL2 Contract Manager feature page\nand the L2 Upgrades specification.\n​Contract releases\nContracts are released as tagged monorepo releases named\nop-contracts/vX.Y.Z, following the documented\nversioning policy.\nThis page does not track releases; use these sources instead:\n\nThe op-contracts release history lists every\nrelease with its notes, generated from the GitHub releases.\nThe superchain-registry standard versions\nfiles record the exact contract versions and implementation addresses\nthat make up each standard release.\nThe network upgrades registry maps\neach hardfork to its governance approval and required component versions.\n\nReleases tagged v<semver> without a component name (for example v1.1.4)\nare Go code releases and do not include smart contracts. Only deploy\ncontracts from op-contracts/vX.Y.Z tags.\n​Layer 2 contracts (predeploys)\nPredeploys are contracts placed at fixed, well-known addresses in the genesis\nstate of every OP Stack chain. Unlike precompiles they are ordinary EVM\ncontracts, which keeps them portable across client implementations and\nvisible to standard tooling. Most live in the\n0x4200000000000000000000000000000000000xxx address namespace and sit behind\nproxies owned by the L2 ProxyAdmin.\nThe Predeploys specification\nis the canonical list: it maintains the full table of predeploy addresses,\nthe upgrade each was introduced in, deprecation status, and whether each is\nproxied, along with the normative definition of each contract.\n​Bridging predeploys\nThe L2 side mirrors the L1 bridging stack. The\nL2CrossDomainMessenger\nis the recommended high-level messaging interface, the\nL2ToL1MessagePasser\nrecords withdrawal messages whose inclusion is later proven on L1, and the\nL2StandardBridge\nand L2ERC721Bridge pair with their L1 counterparts. The\nOptimismMintableERC20Factory\nand OptimismMintableERC721Factory permissionlessly create the L2 token\ncontracts that the bridges mint and burn.\nDo not bridge an ERC-721 that was originally deployed on an OP Stack chain\nthrough the ERC-721 bridge; it only supports NFTs originally deployed on\nL1.\n​Fee and system predeploys\n\nThe GasPriceOracle\nexposes the parameters and helper functions for estimating the data\navailability portion of the transaction fee. The exact fee formula\nchanges across upgrades and is defined in the spec, not here; see\ntransaction fees for the explanation.\nThe L1Block\npredeploy exposes information about the latest known L1 block, written by\nthe protocol through a system deposit transaction.\nThe fee vaults (SequencerFeeVault,\nBaseFeeVault,\nL1FeeVault,\nand, since the Isthmus upgrade, the\nOperatorFeeVault)\ncollect the components of the transaction fee for withdrawal to\nconfigured recipients. See fee vaults\nfor operational details.\nThe ProxyAdmin\nowns the proxies of the other predeploys and controls their upgrades.\nThe BeaconBlockRoot\ncontract (EIP-4788) exposes L1\nbeacon block roots, available since the Ecotone upgrade.\nWETH9\nis the standard Wrapped Ether contract at a deterministic address.\n\n​GovernanceToken\nThe GovernanceToken\nis the OP token used in Optimism governance, supporting voting and\ndelegation. It is owned by a MintManager contract that enforces the token\ninflation schedule. See the governance resources\nfor how the token is used.\n​EAS (Ethereum Attestation Service)\nThe EAS\nand SchemaRegistry\npredeploys implement the Ethereum Attestation Service\nprotocol, an open-source public good for issuing and managing onchain\nattestations. You can interact with EAS through the\nEAS Scan UI, the\nEAS SDK, or\ndirectly onchain,\nand index attestations with the\nEAS API or the\nopen source indexer.\nSee attestations for how attestations are\nused in Optimism governance.\n​Deprecated predeploys\nThe LegacyMessagePasser, DeployerWhitelist, LegacyERC20ETH, and\nL1BlockNumber contracts remain in state for backwards compatibility with\nthe pre-Bedrock system but are deprecated and unused. Their addresses and\nhistory are in the\nPredeploys specification.\n​Next steps\n\nRead the Optimism Overview specification for the architecture diagrams connecting these contracts.\nBrowse the contract source and the generated contract reference.\nLook up contract addresses on OP Mainnet.\nLearn how the fault proof system uses the dispute contracts.\nFor releases, deployment tooling, and source links, see the op-contracts hub.\nWas this page helpful?","tokens":2501,"squid":"ink-governance","role":"Council Listener","at":1791267142819,"hash":"d737a591dbd9d08120e10cc10011df6d1f72cd0e"}
{"url":"https://forum.pyth.network/t/community-council-term-2-six-month-mid-term-report/2704/5","domain":"forum.pyth.network","title":"Community Council Term 2: Six-Month Mid-Term Report - Community Council - Pyth DAO","text":"Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 14\n min\n\n Sep 19\n\n 5 / 5\n\n Sep 27\n\n 9d ago\n\n post by Chop on Sep 19\n\n Chop\n\n Community Council Term 2: Six-Month Mid-Term Report\nPeriod covered: April to September 2026. Figures current as of 7 September 2026 unless stated. Budget figures as of 27 August 2026.\n\n1. State of play\nCommunity Council Term 2 picks up where Term 1 left off. The term leans into community incentivisation programs and the reach of the Pyth brand. The council has also been developing ways to push the Pyth product into more B2C form factors to help demonstrate its usefulness and market positioning to consumers. This is most visible in PythFeeds.com, the Pyth Wheel and PythScan, all covered below.\nTerm 2 runs on an 8,000,000 PYTH twelve-month budget, with half paid in Q1.\nTwo of the three community products in this report came out of the March Community Hackathon: PythFeeds (Samurai), and Market DVR (Wattson), which has since developed into PythScan.\n\n2. Content rewards system\nThe community deliberately shifted from a catch-all scattergun strategy to a much more defined, heavily community-first approach. As a result, engagement on X and beyond has trended up over the past six months.\nWhy the ‘Missions’ engine was retired\nThe term started on the broadcast Missions engine and ended in July. These are the numbers which forced the change:\n\nMonth\nPosts\nAuthors\nImpressions\nPYTH paid\n\nApril\n465\n170\n730K\n~330,000\n\nMay\n5,811\n1,969\n4.75M\n~330,000\n\nJune\n6,143\n2,395\n4.05M\n~330,000\n\nImpressions per post fell from 1,570 (April) to 817 (May) to 659 (June). June added 22% more authors for 15% fewer impressions. Marginal participants added volume rather than reach.\nThe relaunch, 6 July\nThe creator system was relaunched as one path:\n\nPost in #content-hub, or have the PythPulse tool find and surface your tweet.\nEarn Impact Awards, administered by community leaders. Leaders are given a monthly allocation which is given away in full, with publicly auditable reasons.\nGet hand-picked as an Aristophanes: monthly PYTH stipend, 1.8x Impact Award multiplier, free Pyth Wheel spins, two-month trial then tenure.\nPublish in #impact-ops, which everyone can read and only Aristophanes and community leaders can post to.\n\nCommunity creators and leaders receive their own stipends, as well as multipliers on the Impact Awards they receive. Selection is based on content quality and track record ahead of follower count. The budget cap is roughly 15 contracted creators.\nWhat changed in the output\nCore community of 197 tracked handles, Pyth-related posts on X, retweets excluded.\n\nMonth\nCommunity impressions\n\nMarch\n368K\n\nApril\n354K\n\nMay\n373K\n\nJune\n327K\n\nJuly\n370K\n\nAugust\n605K\n\nAugust is 69% above the March to July average, with zero ‘catch-all’ missions running.\n\nMarch to August total: 2.40M impressions, 104.6K engagement (4.4% engagement rate), 42 core members active per month on average, 27 active every single month.\n1 August to 7 September: 46 core members active, 1,754 Pyth-related items, 695K views, 24.1K engagement.\nImpact Awards: July delivered 316 awards / 13,530 coins, against June’s 45 / 1,529, and effectively dormant in April and May.\n\nThe trade-off\nThe “everyone” contributor program peaked at 4.1M views in May and fell under 1M once the program was turned off. Core output went the other way.\nThis was a very deliberate tradeoff and the numbers prove why.\nEngagement was up, but the quality was down significantly. The influx of bots on X through this period was an absolute scourge: automated and AI-generated replies inflated every metric while adding nothing, and they actively deterred genuine readers, who stopped engaging (rightfully) with content they deemed to be AI Slop. Broadcast incentives incentivised the behaviour. By June, 2,395 authors were producing 659 impressions per post, against 1,570 in April, on an openly exploited sybil surface.\nEngagement from core community members, meanwhile, has grown throughout. The contracted creator system produces fewer impressions from identified people at a 4.4% engagement rate, inside a system where every award is published with a reason and every recipient is known.\nHeadline reach is down. Reach that survives contact with a sybil filter is up, and it is now produced by 46 people we can name.\nContent Program budget: 1,090,670 of 3,000,000 PYTH used (36.4%). This is where the term’s remaining headroom sits.\n\n3. Community stats\n\nDiscord: 70,002 members. New joiners still in server: April 357, May 605, June 573, July 543. 1,165 unique members posted in the trailing 30 days to 3 August, across 60,977 messages.\nX, core community, March to August: 2.40M impressions, 104.6K engagement.\nPythPulse, the live mention scanner feeding the community Discord, launched 17 July. 2,123 Pyth mentions scanned in the first fortnight, 891 surfaced. An August upgrade added all-language coverage with inline English translation.\n\n4. Pythenians 2.0\nGovernance thread: Pythenians II. Scope of work & budget request\nThree forum stages, all under Community Council management, all led by Noname:\n7 May, Pythenians 2.0 proposal (44 posts, 1,397 views, 100 likes). Treasury moved under a 6-of-7 Council multisig: 212 SOL staked (115 Helius, 97 Jito), 185 SOL liquid, ~$71,700 USDC, 69,000 PYTH. Collection 4,669 total, 3,682 minted. Pythenians Week discontinued in favour of Pyth Wheel, Pythentity and missions.\n2 June, Key Proposal summary (15 posts, 485 views). Mint closed permanently at 3,682. Burn-to-level runs until the collection reaches 1,750, then stops forever. Three levels: Level 2 = hold one plus burn one; Level 3 = two more burned. Burn fees paid in PYTH, amount TBA. Pythentity badge system. Visual upgrade per level.\n30 July, scope of work and budget request (11 posts, 426 views, 21 likes). One-month build. Team: Noname (project manager), Samurai (full stack), Kirito (graphic design), Sunshine (original collection artist). Budget: $2,000 from the Pythenians treasury, $500 per person. Deliverables: mint closure and collection authority under Council control, automated metadata and art regeneration on every level-up, handcrafted Level 2 and Level 3 art, and the PytheniansHub.\nFor context on cost: a full collection overhaul, a custom burn-and-upgrade dApp, and new artwork across two tiers, delivered for $2,000 total, by community members.\nStatus: community response unanimous in support.\nOpen question from the thread (31 August): who maintains the Hub after month one. The Council will run a nomination and procurement process to find community participants willing to operate the PytheniansHub. Anyone interested in getting involved is welcome to reach out or reply below.\n\n5. Governance proposals\n5.1 Community custom indices on Pyth Pro\nThread: Idea Proposal: Community Custom Indices on Pyth Pro — SCP, 16 August; 10 posts, 164 views, 20 likes\nThe idea. Let creators define baskets of existing Pyth feeds with weights and methodology, stake PYTH to create and keep an index live (10,000 to 50,000 PYTH suggested), and publish them as labelled “Community Index” feeds on Pyth Pro for venues such as Hyperliquid and TradeXYZ. Revenue share suggested at 40 to 60% creator, 20 to 30% DAO. Preferred technical path is Pyth Pro computing the index natively; the fallback is a third-party backend. Stated blocker: community members cannot currently publish feeds on Pro.\nFeedback from the thread. Slashing and a higher stake plus a verification layer by Council, DAO or Douro (Mersault); a formal wind-down process so unstaking cannot force-close open positions, a recurring burned maintenance fee instead of one lock, no manual rebalancing after launch, and a smaller creator split (Lowkeigh); an interim upvotable “index hypothesis” campaign so the community learns index construction before any staking regime (Arguer). SCP’s synthesis on 22 August: permissionless creation, permissioned verification and listing.\nStatus: Ideas stage, no PIP drafted.\n5.2 On-chain burn for Entropy protocol fees\nThread: Complementary Proposal to Pyth Reserve Evolution: Onchain Burn for Pyth Entropy Protocol Fees — SCP, 7 June; 8 posts, 206 views, 18 likes\nThe idea. On every Entropy request, burn 50% of the protocol fee on-chain and leave 50% withdrawable to the DAO, as a usage-equals-deflation complement to the Pyth Reserve proposal.\nWhere the community sits. Entropy fees are collected in native tokens (ETH, MON, HYPE), so an on-chain burn deflates those chains rather than PYTH. Marc confirmed no Entropy fees have yet been withdrawn from any chain, that withdrawal needs a Pythian Council contract upgrade, and that bridging native tokens to Solana is impractical. His counter: a single counterparty receives the accumulated native tokens across chains and delivers USDC to the DAO treasury, which folds into the existing monthly PYTH purchases. SCP accepted that direction on 10 July. The principle stands, in that Entropy revenue should create sustained PYTH buy pressure, with the implementation via counterparty rather than per-chain burns.\nStatus: idea stage, no vote.\n5.3 Pyth Wheel Burn Registry\nThread: [OP-PIP] Implement PythWheel Burn Registry: 100 PYTH Permanent Burn per Spin Community Deflation Mechanism — SkyZ, 19 May; 18 posts, 475 views, 27 likes\n100 PYTH permanently burned per spin, with spins allocated by community role. Derrp’s guardrails: one batched burn per month rather than per spin, a 50% cap on reserve tokens burnable at once, and a 12-month review. Marc moved it back to the Ideas Bank pending the funding-source question: prize pool, new budget line, or a separate burn fund.\nStatus: open as of 25 June.\n\n6. Pyth Wheel\nOverview\nPyth Wheel is primarily a tool to showcase Pyth Entropy in use across chains and in different contexts. It is also an accumulation mechanic for Pythenians holders, who receive free spins each week and accumulate PYTH on a weekly basis. This is one of several small utility mechanics attached to the NFTs that the community keeps as open secrets for the wider ecosystem to discover.\nUsage and payouts\n\nMonth\nPYTH paid\nWallets\nSpins\n\nMarch\n41,635\n356\n2,254\n\nApril\n37,686\n378\n4,646\n\nMay\n44,163\n439\n5,469\n\nJune\n40,411\n416\n5,009\n\nJuly\n100,000\n431\n5,600\n\nAugust\n93,958\n497\n7,001\n\nTotal\n357,853\n\n29,979\n\nWallet participation grew 40% from March to August. Spins per wallet went from 6.3 to 14.1, so the same audience is engaging more than twice as often. Cost works out at roughly 12 PYTH per spin.\nThe budget moved from roughly 40,000 to 100,000 PYTH per month from July as the Wheel graduated from Miscellaneous to its own line. The Wheel takes no fees; every contract address is public and payouts are verifiable per wallet at month end. Aristophanes receive free spins as part of the creator system, and Pythenians NFT holders receive free spins each week.\nWhich chain\nThread: Should We Move the Pyth Wheel Back to Base or Monad?\nThe Wheel is EVM-native, built on Pyth Entropy, and deliberately cycled across chains as an on-chain education tool. It launched on Base in March, moved to Monad, and to HyperEVM from September.\nFirst week of September on HyperEVM (snapshot 6 September, at $0.055 PYTH and $0.11 per spin): 394 unique wallets and 2,941 spins, the strongest opening week of any month.\n\nUsers in profit\n361\n\nBreak-even\n2\n\nIn loss\n31\n\nMedian profit per user\n$1.06\n\nHighest individual loss\n$0.33\n\nEvery wallet is net positive over the lifetime of the Wheel across all three chains. A prize-weighting upgrade shipped alongside the migration.\nThe 2 September forum thread asking to move back to Base or Monad centres on spin cost, roughly $0.15 in HYPE plus bridging. The Entropy protocol fee on HyperEVM is unchanged at 0.0004 HYPE, so the difference comes from chain gas rather than Entropy.\nDecision: stay on HyperEVM through September. Any net-negative wallets are equalised at month close.\n\n7. PythFeeds.com\nOverview\nPythFeeds.com is a community-built retail market terminal on Pyth data, built and run independently by Samurai. The Council’s role is product direction, brand alignment and distribution. It is not an official Pyth product. All usage figures are Google Analytics 4, tracking live from 1 April 2026, snapshot taken 7 September 2026.\nUsage\n2,287 unique users and 3,197 sessions from 1 April to 6 September. Roughly half of those users arrived in the last five weeks.\nRolling 28-day active users: mid-May peak ~410, end-June trough ~180, late July ~450, 6 September ~1,050.\nThe last 30 days (8 August to 6 September) are the strongest on record. 28-day active users rose 132% on the previous 30 days. Weekly active users have held between 190 and 255 for five consecutive weeks; the previous best week was ~160 in mid-May.\nEngagement:\n\nMetric\nValue\n\nAverage session duration since April\n3m 43s\n\nLast 30 days\n2m 06s (−56%)\n\nSessions per user since April\n1.4\n\nNew traffic is shallower than the early user base, which is normal when acquisition outpaces retention. Most visitors come once: retention is the weak point, ahead of acquisition, and it is the explicit priority for the next six months.\nThe read: the May spike lines up with the Missions program (May and June were the two heaviest mission months), and the June trough with missions stopping. The August to September surge happened with zero missions running, making it the first stretch of organic growth. Attribution is most likely organic: @PythFeeds posting on X, plus search results.\n\nNote on figures. The GA4 “30-day active users” dashboard totals (56,587 for April to September) sum a rolling daily count and are not unique users. They should not be cited as monthly users. The “~10K monthly users” figure quoted when the workstream started is not supported by GA4; the peak trailing-28-day audience is ~1,050. We would rather post the smaller number that is true.\n\nDevelopment\n\nMarch: began at the Pyth Community Hackathon as Samurai’s entry, and grew from there.\n28 May: workstream launched with Douro Labs and PDA. The direction from here is to use PythFeeds as a launchpad to trial a Pyth Pro consumer subscription package. Nothing has been finalised or formalised.\n19 June: technical audit by Douro Labs. Findings: no product prioritisation, and an API layer proxying a single Pyth Pro key to PythFeeds users. The backend is Node.js; FMP is used only as a helper for PE ratios.\n30 June: model changed to referral-only, arm’s length. PythFeeds stays as its own product and refers users to the Pyth Terminal for their own subscriptions and API keys. No redistribution of Pyth data. This removes the compliance-monitoring burden a formal partnership would have carried.\n\nConsumer subscription trial\nNothing finalised or formalised. Pricing subject to approval and legal review.\nIt is being proposed that PythFeeds be used as a launchpad to trial a Pyth Pro consumer subscription package: the first attempt at a consumer-tier subscription on Pyth data, run on a community product rather than an official surface, where the community can test & iterate without committing the broader protocol to a model that has not been proven.\nWorking shape, subject to change: revenue split 70% to the DAO wallet, 30% to the builder, covering ongoing marketing, development and maintenance. Payments would run fully on-chain and verifiably, rather than through a conventional processor, keeping the product crypto-native and making the DAO’s share auditable by anyone rather than reported after the fact.\nThere is MUCH more to come here. If the trial works, the longer-term path is PythFeeds being folded into the Pyth Terminal as a community-built component, which would make it the first case of a community project graduating into the core product surface.\nAccount and content program\nThe @PythFeeds account on X is live, with a community content program running behind it. The intention is to transition this into a full-time position, funded from a share of the subscription revenue once the trial above is running, plus a monthly stipend from the Council’s community grants program. Part of the pay is tied to whether the product it markets actually earns.\n\n8. PythScan\nPythScan is a direct output of the March Community Hackathon run by the Community Council. Wattson (@MasterWattson) entered that event with Market DVR, built on the hackathon API the Council stood up, and went on to ship PythScan from it. It has been live for testing since 24 August on two surfaces.\nWhat it answers\nPlain-language questions about Pyth, restricted to official Pyth sources, with the bot built to say when it cannot verify something: live price, 24h / 7d / 30d and calendar-window change, price at a point in time, all-time high and low, two-asset comparisons, and top movers by market, region and period. It also covers the feed catalogue (does a feed exist, which feeds were added this week, feed and Hermes/Lazer ID lookups), governance (did a PIP pass, live Realms votes and those ending soon, council membership and elections, constitution and staking rules), and product questions (Core vs Pro, Pyth Pro pricing, recent updates, package versions, Pyth Pro revenue reports).\nOn X — @Pythscan\nTag it with a question and it replies through the filtered mention stream, with a rendered Pyth price, comparison, revenue or confidence card attached.\nOn Discord\nInstall it into a server and ask in plain language, in DMs, on mention, or in reply, plus six slash commands:\n\nCommand\nDoes\nPermission\n\n/setup\npick reply channels and thread behaviour\nManage Server\n\n/alert\nprice, new-feed and governance alerts, delivered by DM\nany member\n\n/watchlist\nadd, remove and list tracked assets\nany member\n\n/updates\nautomatic server posts for new feeds and governance\nManage Server\n\n/movers\nby direction, market, region and period\nany member\n\n/brief\ntoday, yesterday, this week, last week\nany member\n\nBuild\nPython 3.10 on discord.py and FastAPI, SQLite for state, and a Node renderer for card images. Roughly 76,700 lines of Python with a further 42,000 lines of tests across 124 test files, built by one community member in about two months.\nKnown limits\n\nDiscord replies are truncated at 1,900 characters; X replies at 270.\nAlerts, watchlists and server broadcasts are Discord-only.\nIt responds only when addressed (a mention, a DM, or a reply), and only to questions.\nCard rendering depends on a Node renderer that lives outside the repository.\n\nNext: data visuals publishing to X.\nContinuity note for the Council: the repository is currently private, single-contributor, without a licence or continuous integration. Securing a licence and a transfer path is a Cycle 2 deliverable, so a tool the ecosystem comes to rely on does not sit on one person’s account.\n\n9. The PIRB\n@thePIRB is a Pyth lore and bull-posting account run by Aristophanes from the creator program. It is the clearest example of what the contracted creator system produces that a mission brief never could: sustained narrative craft, built over months, with a visual identity of its own.\nThe past six months:\n\nPyth lore and bull posting through AI video. The account’s core output is short AI-generated video, used to build a running mythology around Pyth rather than to restate announcements.\nCommunity creation and lore. It leans into the community’s own in-jokes, characters and running references, which is what gives the material something to attach to.\nNarrative craft first. The posts are weird, and deliberately so. They are built to stop a scroll and be remembered, which is a different job to informing an audience that already follows Pyth.\nA visual style that has compounded. The look has improved materially across the six months and continues to develop. It now reads as a recognisable identity rather than a series of one-off experiments.\n\nThe numbers, 19 March to 19 September. 719 posts, 124,751 impressions, 5,242 engagements at a 4.2% engagement rate. Three quarters of that volume is replies, which inherit whatever reach the thread they land in already had, so the figure that actually describes the account is its own content: 169 original and quote posts carrying 85,169 impressions at a 5.0% engagement rate.\n\nMonth\nOwn posts\nVideo\nImpressions\nMean / post\nMedian / post\nEng. rate\n\nMar (13 days)\n10\n4\n3,273\n327\n292\n6.3%\n\nApril\n14\n8\n7,589\n542\n414\n4.7%\n\nMay\n20\n14\n5,914\n296\n333\n6.7%\n\nJune\n31\n20\n9,581\n309\n341\n7.2%\n\nJuly\n33\n14\n13,153\n399\n394\n6.1%\n\nAugust\n45\n19\n31,639\n703\n507\n3.7%\n\nSept (19 days)\n16\n11\n14,020\n876\n660\n4.7%\n\nReach per post is up 2.7x since March on the mean and 2.3x on the median, while the engagement rate held in a 3.7% to 7.2% band rather than decaying as reach grew. Output rose alongside it: 31 to 45 original posts a month from June, against 10 to 20 before.\nThe distribution story. Total impressions are 872x the follower count; on own content alone, 596x. Follower count was flat across the window, so effectively none of this reach comes from the follower base. It comes from X distributing the videos to people who do not follow the account. Every one of the top ten posts reached between 8x and 63x the follower count on its own.\nAugust is the inflection. That month the account worked out that short video tied to a live news hook or a recognisable meme format travels a long way past its own audience. The best-performing own post of the window, a video on the SEC and Hyperliquid with a Pyth angle posted the same day as the headline, took 7,591 impressions. Five of the six own posts that cleared 1,500 impressions are video, and all six are from August or September.\nDiscounting our own numbers. Roughly 20,000 of the 124,751 impressions, about 16%, came from five off-topic replies to large non-crypto accounts, which drew near-zero engagement. That is borrowed reach, and this report argues elsewhere that borrowed reach should not be counted. Discounted, the window total is ~104,750 impressions, and the honest own-content figure is the 85,169 above.\nSource: X API v2, pulled 19 September 2026. Per-post data retained. Follower count at the start of the window is not recoverable through any available access path, so net follower growth cannot be stated.\n\n10. RWA Markets research\nrwa-markets.xyz is the work of Zinn (@zinnresearch), published under Refraction Research and sponsored and subsidised by the Community Council. It is the only public dataset of its kind: real-time analytics on tokenised real-world asset trading across decentralised and centralised venues, tracked at a granularity nobody else publishes.\nCoverage at 9 September 2026:\n\n24h volume tracked\n$16.4B\n\nVenues\n22\n\nAssets / markets\n536 / 2,218\n\nRWA share of tracked perp open interest\n18.6% ($11.6B)\n\nWhat it covers: nine dashboards across tokenised stocks, commodities, indices and treasury assets. Today (daily snapshot), Volume Dominance, OI Dominance, Top Traded Assets (with oracle data), Institutional Velocity (trade frequency, size, spreads, slippage), Asset Analyzer (per-asset liquidity and funding), Trader Intelligence (on-chain wallet analytics and capital flows), DeFi Markets (lending, yields, TVL, tokenised treasuries) and Spot Markets (tokenised stock and ETF spot trading and issuance).\nWhy it matters to Pyth. This is an important community run project that Pyth uses internally for data attribution on perpetuals volumes, alongside a range of other datapoints. Per Zinn, it fed the August RWA report. The protocol consumes it as working infrastructure.\nZinn has since built dedicated API connectivity specifically for Pyth, with partner access to the underlying database covering oracle provider attribution weighting per symbol, venue and wallet-level breakdowns, per-venue execution quality, and DeFi yield history. Pyth is the only party outside Refraction Research with this level of access. It is a working technical partnership between a community researcher and the protocol, built without a formal commercial agreement.\nThat is the clearest illustration of what the Council’s research budget buys. Zinn is producing work that is unavailable anywhere else, that the team relies on internally, and that carries the Pyth name into a market segment where nobody else has comparable visibility.\n\n11. Budget\nFigures as of 27 August 2026. All amounts in PYTH.\n\nCategory\n6-month budget\nSpent\n% used\n\nRole stipends\n280,000\n306,486\n109.5%\n\nContent program\n3,000,000\n1,090,670\n36.4%\n\nHackathons\n300,000\n133,000\n44.3%\n\nCouncil stipend\n420,000\n420,000\n100%\n\nMiscellaneous (incl. Pyth Wheel)\nn/a\n305,150\nn/a\n\nTotal\n4,000,000\n2,255,307\n56.4%\n\nMonthly spend against the recurring benchmark: April 588K, May 623K, June 405K, July 447K, August 121K, September 70K to date. May was the only month over benchmark, driven by hackathon payouts.\nRole stipends is the only line over allocation, at 9.5% (26,486 PYTH) past its six-month envelope. The cause is growth rather than overrun: the role system expanded as more mechanics came online, and more community members wanted to dedicate serious time to running them. We would rather have that problem than the opposite one.\nOn the 43.6% unspent: this is deliberate, and it was planned for. The underspend sits almost entirely in the content program, because Missions were shut down mid-term and the replacement creator system only went live on 6 July. Rather than spend the difference to hit a number, we are holding it for the Hackathon, which returned more per PYTH than anything else the Council funded and deserves a materially larger prize pool and more of the Council’s time in the second half. The Cycle 2 increase we are asking for was already contemplated in the original request made at the start of the year.\nWhat things actually cost\n\nTerm 2 to date\n\nPyth Wheel\n~12 PYTH per spin, ~720 PYTH per participating wallet\n\nHackathon\n133,000 PYTH for 40 submissions = 3,325 PYTH per submission\n\nHackathon, second iteration target\n500,000 PYTH for 400 submissions = 1,250 PYTH per submission, a 62% improvement in unit cost\n\nPythFeeds, PythScan, SCPTech\na single stipend per project, capped at 20,000 PYTH per month and lower in several cases\n\nThat last line deserves emphasis. PythFeeds, PythScan and the SCPTech work are each built by one person. There is no team, no agency and no vendor contract behind any of them. The entire development cost to the DAO is a monthly stipend to a single community member, capped at 20,000 PYTH and less in some cases. PythScan alone is 76,700 lines of Python with 42,000 lines of tests.\nThese are also long-horizon projects and should be judged as such. A retail terminal, an intelligence assistant and a governance tracking stack do not produce measurable returns inside a six-month window, and we would be misleading the DAO if we presented them as though they did. What they produce in Term 2 is working software, a user base to learn from, and optionality: PythFeeds is now the trial vehicle for a Pyth retail subscription, and PythScan is becoming the ecosystem’s front door for plain-language questions. The payoff sits in Terms 3 and 4.\n\n 2\n\n read \n\n 14\n min\n\n post by Chop on Sep 19\n\n Chop\n\n Part 2: Next six months\n1. Hackathon\nTarget: late October. Budget to be confirmed, minimum 500,000 PYTH.\nThe first Community Hackathon was very successful on a minimal amount of marketing and exposure. It was run purely on community terms, with no distribution partners tapped and no ecosystem users brought in to amplify the event. Even so it drew 40 submissions, a number of them genuinely innovative uses of Pyth data, showcasing how Pyth data can be used across the crypto marketplace with AI development as the crux of the program.\nTwo of the three community products in this report came out of that event. For 133,000 PYTH.\nThe second iteration aims to tap ecosystem partners for larger amplification and a wider range of usage across ecosystem products, and to tap each partner for additional rewards on on-chain builds and use cases that are currently unexplored, for example the Pyth Consumer subscription tier and the MCP server via PythFeeds.\nGoal: 400 submissions, a 10x step up on the initial program, with an increased prize pool and a bigger distribution footprint.\n2. Pythenians 2.0 completion\nTargeted for September delivery. A full overhaul of the collection, introducing a burn mechanism and the Pythenians Hub, and significantly enhancing the utility of holding.\n\nBurn mechanism active until total supply reaches 1,750, with two upgrade levels introduced\nVisual upgrades tied to each level\nPythenians Hub: holders connect their wallet, select a rewards wallet, and claim badges\nRevenue generated from burn fees and secondary market royalties will be partially distributed to holders and reinvested into future project development\nEach level unlocks specific utilities and platform features for community members\n\nBeyond the September build:\n\nPythenians Governance: an on-chain voting system built directly into the Hub, giving holders the power to approve or reject proposals from the team. Think Realms, but native to Pythenians.\nPythentity Score expansion: badges evolve beyond recognition into a full scoring system with real weight. Score determines access, priority and rewards, building a genuine reputation layer for the most committed community members.\nIRL event infrastructure: a dedicated application system inside the Hub for both hosts and attendees, streamlining how Pythenians meetups get proposed, organised and attended.\nLevel utility roadmap: Levels 2 and 3 will unlock a continuously expanding set of platform features and community perks.\nPythenians merch: official merchandise for the community. Details to follow.\n\nA further governance forum post is forthcoming, going into more detail on the above.\n3. New community moderation system\nChanging from external contractors to internal community members.\n\nOver the past two years the community has grown to include highly specialised, very experienced members who know the ins and outs of the Pyth product well enough to administer our public Telegram channels and incoming builder tickets, to the point that they can handle all incoming enquiries.\nThese community members deserve recognition and the ability to put their hard-learnt skills together. Having dedicated community members do this is more aligned to the Community Council’s values within Pyth, and makes a lot more sense than paying third-party contractors to do their job.\n\nThe community option is cheaper and more effective, and it kills two birds with one stone. It is managed internally, which gives the community more power over its own outcomes and makes it more accountable for them. It gives people who have already dedicated years to this community deeper acknowledgement and real autonomy inside the community structure. And because the work moves off a third-party contract, it saves the PDA and Douro Labs money at the same time as it improves the service.\nCommunity moderation guidebook\nStipends for these administrators across Pyth’s public channels are covered in the budget section below.\n4. SCPTech overhaul\n\nOff-chain buybacks tracking.\nOn-chain Entropy call tracking, if technically possible.\nAlerts for Pyth holder numbers, Pyth stakers, and large buys across different markets, on-chain and potentially CEX purchases.\n\nThese alerts could also be scaled into PythScan and/or PythFeeds.\n5. PythFeeds.com\n\nReferral funnel live. Terminal retail tier priced, referral tracking in place, commission rate locked. PythFeeds becomes the free front door to the Terminal.\nRetention over reach. Sessions per user is 1.4. Prioritise alerts and watchlists, the two features most likely to bring a CoinGecko user back, over more top-of-funnel.\nConsumer surface. PythFeeds is Pyth’s only retail-facing surface. Report GA4 monthly to the Council alongside Terminal referral numbers so growth is tracked against revenue rather than vanity.\nPythenians integration. Wire the NFT collection into the platform for utility upgrades to all holders.\n\n6. PythScan\nWattson’s vision for the next six months is to develop PythScan into a reliable community built intelligence assistant for the Pyth ecosystem: users asking questions naturally about Pyth, whether on market information, price feeds, governance, products, technical information or ecosystem updates, and receiving useful answers backed by reliable sources.\nThe priority is to make the Discord experience dependable and conversational, while developing X as a more concise public facing version with market cards and focused responses. Alongside that, improving its usefulness for developers and governance participants, and continuing to expand what it can understand based on real community usage and feedback.\nBy the end of the next six months the goal is for PythScan to be a stable and regularly used community tool that makes it significantly easier for people to access, understand and interact with information across the Pyth ecosystem.\nAlongside that:\n\nPaid tiers in PYTH for real-time alerts and additional scan features, scalable into different servers and onto Twitter.\nExpand into Telegram, opening up additional alerts and the potential for portfolio management and further development.\nIntegrate with PythFeeds.com, unifying two community projects that complement one another.\n\n7. The PIRB\n\nGrow the account to 10,000 followers, to increase the memetic reach of the Pyth brand into a retail audience. The gap to close is conversion rather than reach: the account already puts its content in front of hundreds of times its follower count, and almost none of that traffic converts to a follow.\nKeep experimenting with the visual and memetic style of the videos.\nExpand the bull posting with more direct narrative crafting around Pyth’s market position.\nFeed the style back to the main brand. Begin integrating the video content style into posts the main Pyth brand account can use directly.\n\n8. IRL meetups\nFunded and budgeted from the Pythenians treasury. The goal is four meetups across the globe: Asia, Europe, North America and South America.\nCommunity members interested in hosting should get in touch with the Community Council to pitch their ideas. Budget allocations currently sit at roughly $5,000 USD per event, subject to change. No locations or spending have been finalised.\n9. Budget proposed\nTwo asks go to the DAO for the second half of the term: the 4,000,000 PYTH Cycle 2 allocation already contemplated in the March budget request, and an increase to that ask of 75,000 PYTH per month for the community moderation changes described in section 3.\n\nRequest\nAmount\nBasis\n\nCycle 2 allocation\n4,000,000 PYTH\nSecond six-month cycle of the approved 8,000,000 PYTH Term 2 budget\n\nCommunity moderation\n75,000 PYTH / month\nAdministration of Discord and Telegram transferred from a third-party contractor to embedded community members\n\n450,000 PYTH across the six-month cycle.\nUse of the existing underspend\n\nJuicing the Hackathon prize pool, to make it more attractive and give additional incentives to participants from across different ecosystems. It also gives us the ability to tap ecosystem partners and match incentives for different ecosystems, increasing exposure of the program.\nFinding additional content creators outside the Pyth community circle, to increase exposure and break out of the existing small-community echo chamber.\nStipends for embedded community administrators. For the second part of the term, administration of Discord and Telegram will be done by embedded community members, a departure from the past two years where the server and public channels have been administered by a third party.\n\nFor context: what comparable programs cost\nThese are different programs with different mandates, so this is offered as a sense of scale and direction of travel rather than a like-for-like scoreboard.\nArbitrum, Rewarding Active Delegates. 2,000,000 ARB allocated in January 2026; 1,156,361 ARB spent by June across 39 registered delegates, covering 16 proposals over seven months. The output is governance participation, which is valuable, and it is the whole output. (RAD bi-annual transparency report, June 2026)\nOptimism. Year 4 committed roughly 150 million OP across Seasons 8 and 9, a 35% cut on Year 3’s 229.92M OP, with the Governance Fund down 53% to 13.4M OP and Retro Funding down 30% to 14.2M OP. The direction of travel across the large ecosystems is contraction in community and grants spend. (Optimism Year 4 spending)\nThe attention-farming category. Kaito sunset YAPS on 15 January 2026, with 157,000 members in the Yapper community, after X revised developer policy to ban applications that pay users to post, citing a surge in AI-generated spam. (Kaito after YAPS)\nKaito is what defined the Pyth rewards program shift. The default community-growth model has essentially been pay-to-post. It was shut down from outside because the content it produced was indistinguishable from spam. We ran our own version of it, measured it honestly, watched impressions-per-post fall by 58% in two months, and retired it quickly. What replaced it is a named creator corps, a hackathon that has produced three shipped products, and a research partnership the protocol uses internally.\nWhat this adds up to\nSix months, one budget:\n\nThree consumer-facing products built by community members and running in production: a retail market terminal, an intelligence bot on two platforms, and a cross-chain Entropy demonstrator. Two of the three came out of a single hackathon that cost 133,000 PYTH.\nA research platform the protocol uses internally. Zinn’s RWA Markets work is used for perpetuals volume attribution and fed the August RWA report, with dedicated API access built for Pyth. Subsidised by this Council.\nAn NFT collection with a working treasury, a closed mint, a burn mechanism and a custom dApp, overhauled for $2,000 by four community members.\nA content system that produced its best month with the incentives switched off. 605K impressions in August, 69% above the prior five-month average, from 46 identifiable contributors at a 4.4% engagement rate.\nGovernance work in both directions: three community-originated proposals worked through to technical resolution with the core team, rather than posted and abandoned.\nOn-chain verifiability as a default. Every Wheel contract is public, every payout is checkable per wallet, every Impact Award is published with a reason.\n\nMost token communities produce content - that’s a given. The Pyth Community produces software, research and governance, and it does so at a cost per output that gets cheaper each cycle.\n\nQuestions or feedback, reply below or tag the Community Council in Discord.\n\n post by totti on Sep 20\n\n totti\n\n Huge amount of work here from the Community Council. The sheer amount of work and responsibility taken on over the past year is genuinely impressive, and it’s been great seeing people step outside their comfort zones and develop new skills along the way. The growth in the community’s capabilities has been almost immeasurable.\nThe hackathon in particular could be massive with this kind of budget behind it. A serious allocation toward it could bring a lot more eyes to Pyth and attract some really high quality teams and builders. Innovation deserves this kind of investment, and we could genuinely see Colosseum level projects come out of it.\nPythenians 2.0 is another part I’m particularly excited about. It feels like a great opportunity to build on everything the community has already created and give Pythenians an even stronger foundation going forward. I’d also be very interested in helping operate and maintain PytheniansHub as that moves forward. Happy to contribute wherever needed.\nAnd a personal thank you to the Council, it’s been really cool to watch how much you guys have taken on and how much the community has grown along the way. Appreciate all the time, effort and energy you’ve put into this. \n\n post by iDrJoe on Sep 21\n\n iDrJoe\n\n Thanks for the update. A lot got done this cycle.\nWhat I’m missing is anything about the gators. They were always presented as the main Pyth NFT collection, but apart from the Wheel role, there doesn’t seem to be much happening with them. They don’t have their own Discord channel, and the gator role sits below Low Priest and Pythenians.\nI hold Pythenians too, so I’m happy to see the work going into 2.0 and the planned PythFeeds integration. I just wish there was some direction for the gators as well. Reading through the plans for the next six months, I couldn’t find anything about them.\nDoes the Council have anything planned for them? Even an update on where things stand would be appreciated.\n\n post by Mersault on Sep 26\n\n Mersault\n\n This truly showcases the dedication of the entire community, and especially the Council, who deserve massive respect. There is definitely more to come, even though the results achieved so far are already incredible. In every action, you can see the genuine love every Pythian has for the project.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 444\n\n Sep 2025\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14\n\n Community Council Term #1 Exit Report\n\n Community Council\n\n 4\n\n 194\n\n Mar 29\n\n Community Hackathon post-mortem\n\n Community Council\n\n 6\n\n 238\n\n May 31\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":10375,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267154346,"hash":"c73df0be776dc5cc9ecf85e9be2ac4d65b80cf8d"}
{"url":"https://forum.pyth.network/t/community-council-report-6month-budget-extension/2194/1","domain":"forum.pyth.network","title":"Community Council Report & 6month Budget Extension - Community Council - Pyth DAO","text":"Community Council Report & 6month Budget Extension \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 5\n min\n\n Sep 2025\n\n 1 / 12\n\n Sep 2025\n\n Sep 2025\n\n post by Chop on Sep 8, 2025\n\n Chop\n\n The State of Play\nFirst 6 months. Highly successful period of growth and authority expansion within the Pyth Community. Each councilor has taken on a specific role, fulfilling niches within the community that bring about engagement and provide the community at large with a number of different content touchpoints.\nThese touchpoints and initiatives have all been designed to make the Pyth Community sticky, interesting at all times. These activities give community members looking to grow and participate in the network an opportunity to own it.\nCommunity stats\nDiscord Engagement (Since Jan 1st to Aug 1st)\n\n~1800 Messages/Day\nActive Users\n\nDAU ~192\n\nWAU ~651\n\nMAU ~1311\n\nTwitter & Pyth Portico\nPost TGE Mindshare; +88%\nPyth Portico (42% Increase)\nJan 1st; 1300\nAug; 1850\nFirst 6 month budget (Kaito, Impact Awards, Stipends & more)\nhttps://docs.google.com/spreadsheets/d/1CS5ruXP6VNw_rpCQM05Yx-HYF8kHGbvJkwpZmPzcP_0/edit?gid=1993656994#gid=1993656994\nInitiatives\nEach of these initiatives strengthen the another. The council has spent the past 6 months planning and developing the content and technical capabilities to create a ‘community hub’. This community hub will live under the Pyth.Community domain (already owned). This hub is to be the one-stop-shop for onboarding new & existing community members displaying community contributions, events\nPyth.Community Hub\n\n*Pythentity (~80k Pyth total cost)\nForum Proposal; Pythentity Initiative Forum Post Draft - Google Docs\nAn identity based profile for Pyth community members. Created to document community activity, engagement and onchain adventures.\n\nEstimated cost of development;\n2.5 weeks - developing a working product 1.5 week - cleanup and testing/feedback = 4 weeks completion\n4 weeks full time work (4x40) = 160 dev hrs Dev hrly cost = $50USD Total development cost (160x50) = $8000 Pyth grant size (assume ~0.12c Pyth); 66k $PYTH GRANT SIZE\ncommunity timeframe to completion;\n\n3 months\n\n4-5 contributors\n\n14k $PYTH buffer requested to cover blowouts or unforeseen circumstances.\n\nPyth Academy (~50k Pyth total cost)\nPrototype; https://pythiansacademy.netlify.app/\nA comprehensive knowledgebase for the Pyth community, covering Crypto basics, detailed Pyth fact sheets and key Pyth partner information.\n\nEstimated cost of development;\nUndefined as of yet, pending further discussion in the community.\n\nPythMeets (2k $Pyth/Month)\nFront end; https://pythmeet.com/\nAn IRL community-building initiative aimed at giving people the time and space to create their own communities within their own social circles. This initiative aims to cover the cost of coffee for a group, and allows them to engage with people in a more substantial, intimate manner.\nThis initiative aims to build up members’ ability to develop their own brands & social standing while also advancing the Pyth mission.\n\nDiscord\n\nDeFi & Markets Events\nJeetaliks DeFi Deep Dives - Exploring DeFi across chains. These deep dives aren’t necessarily related to Pyth. They are designed and hosted to educate the community on all different types of innovation and creative endeavors in the broad and ever expanding DeFi sector.\nMarket Quorum - Pyth’s DeFi & Trading community share their outlook for the coming week, discuss new trends in WEB3, follow relevant news, and engage in educational conversations spanning the entire web3 ecosystem.\nAverage number of attendees - 15\n\nWeekend Warriors Events\nWeekend streaming events hosted by community leaders.\n\nBingo Livestreams\n\nUFC viewing parties\n\nSocrates Bot\nDesigned to streamline community administration and onboarding. Socrates bot has a number of different features.\n\nLive Epoch timer\n\nMission builder\n\nTwitter profile linking\n\nPrice Feed calls\n\nNFT Statistics\n\nCommunity Grants Bot (~12k $pyth/month)\nAdministers the Pyth Community Grants economy within the community. Developed by the community.\nCommands Documentation; https://www.notion.so/pyth-network/Impact-Awards-Discord-Bot-Commands-2382eecaaac980e3b1c6dfcf193b2149\n\nMiscellaneous\n\nMegaPot Syndicate\nA smart contract lottery sydicate built on top of MegaPot.io, using Pyth Entropy. This initiative allows the community to participate as a collective in the worlds largest onchain lottery. This is a first of its kind development that leverages Pyth partners, and the collective power & passion of Pyth community participants.\n\nCommunity Special-ops onboarding guide\nCommunity Special ops run by Bats is an important component of Pyth’s Business Development strategy; finding and correcting incorrect data and oracle based information on the DeFi Llama dashboard when it relates to Pyth.\nGuide; https://legendary-paneer-28e.notion.site/DeFiLlama-Guide-1c480803f46680a9ad7ef730d98d8874?source=copy_link\n\nCommunity BD; Pyth Entropy\nA comprehensive community driven BD process. Aims to reward community members for onboarding NEW Pyth Entropy users across the EVM landscape. Also aims to make a business case for the deployment of Entropy to Solana and SVM operating environments.\nGuide; https://www.notion.so/pyth-network/Entropy-Community-BD-22b2eecaaac9801fb311c26596fde03f?source=copy_link\n\nShort form video content (5k $pyth/month)\nFunds the creation of 2 short form videos per month. Produced, edited and broadcast by the community - this content is developed for Reddit, TikTok, Youtube and Instagram; all content platforms that Pyth does not yet have a strong presence on.\nThis particular initiative has been started in order to grow and cultivate a group of Pythians dedicated to creation video content. We as a community aim to grow an army of content creators that receive $PYTH compensation for their TikTok, Youtube and Twitter reels and videos.\n\nCommunity twist on IA’s - Creation of PP’s\nWhile still keeping the official name of IA’s we have successfully rebranded the community currency to be referred to as PP’s by the broader community. This has allowed the community more creativity when speaking about the discord currency program. Boosting X posting engagement and increasing the draw of the Pyth discord.\n\nSOL Arena Campaign\nA total of 16,000 $PYTH was allocated to the week-long SolArena x Pyth x Pythenians Gaming event. The initiative aimed to promote the Pyth brand through a complete platform redesign to feature Pyth and Pythenians branding, coordinated announcements on Twitter and Discord, and live streams across both communities.\nThe full list of winners and distributed rewards can be found here: – https://docs.google.com/spreadsheets/d/173l75O-707vxkZWZl4XwSfVYOvaIK8tdJA-cdVqj6Ww/htmlview#gid=0\n\nRemaining 6 months\nCommunity council has done an incredible job of taking on the management and execution of the Pyth Community. Throughout the first 6 months of the council term, we have established management techniques, processes and safeguards for future council iterations and members.\nBudget\nhttps://docs.google.com/spreadsheets/d/16qLZDtyf57ES3v6qfSAjLs-Wu4XUTSu1V8kA3jlp_R8/edit?gid=264822604#gid=264822604\nBased on discussions with community members and candidates to the Community Council, I propose below a revised version of the budget that I would like the Pyth DAO to consider for the second half of the 12 month term of the inaugural Community Council.\nCommunity Council Budget Explainer\nThe proposed Community Council budget is requesting an allocation of 1,470,000 PYTH tokens over a 6-month period (half of the 12 month term) to support various community initiatives and governance functions.\nBudget Breakdown: https://docs.google.com/spreadsheets/d/16qLZDtyf57ES3v6qfSAjLs-Wu4XUTSu1V8kA3jlp_R8/edit?usp=sharing\nImpact Awards (210,000 PYTH)\nA monthly allocation of 35,000 Pyth to recognize and reward outstanding community contributions. These awards are intended as community micro-grants, provide rewards for games and events, enable discretionary fun initiatives, and empower cross-community collaboration efforts.\nKaito (600,000 PYTH)\nSignificant reduction - not as effective as hoped, but still good for organic content. This should be focused instead on individuals who want to create content for Pyth independently. Therefore half of this allocation has been removed.\nThe largest budget allocation supports the Kaito program, which will run for 6 months with detailed reward breakdowns available. This initiative focuses on building Twitter mindshare and incentivizing quality content creation to expand the project’s reach and visibility. Further details are provided here.\nExperiments Lab (480,000 PYTH)\nA monthly allocation of 80,000 Pyth reserved for experimental initiatives and just-in-time opportunities. This flexible funding allows the Council to respond to emerging needs and test innovative ideas without requiring additional budget approvals. This has evolved significantly over from the first 6 months of the council term.\nThere are a number of different ideas proposed by the council and other community members that the council would like to fund in the final 6 months of the council term, including the community hub (Pyth.Community), Pythenity & more.\nExpenses (60,000 PYTH)\nUsed to cover expenses council members incur when supporting community initiatives, events and proposals. Including but not limited to hosting, domain purchases and subscription services.\nRole Stipends (120,000 PYTH)\nThis section funds three roles within the discord, essential to community operations:\n\nChirons: Stipend with the cap of 750 per person, underachieved cap distributed as the bonuses to the best performing Chirons. (15 positions x max cap 750, totaling 67500 Pyth)\n\nMensarius: Stipend with the cap of 350 per person, underachieved cap distributed as the bonuses to the best performing Mensarius’. (15 positions x max cap 350, totaling 31500 Pyth)\n\nOther Roles: 10 positions at 350 Pyth per month, totaling 21,000 Pyth every 6 months.\n\nThese stipends ensure dedicated community members can commit time to community responsibilities across Pyth social channels consistently throughout the year. Not all of these positions are filled - there is room to expand or contract as need be.\nCommunity Council Member Incentives\nIn addition to the budget above to be managed by the Community Council through the multisig wallet assigned to it, I suggest to the Pyth DAO to consider incentivizing the Council Members at the end of each term with 120,000 PYTH per member per term (12 months). Such incentive should be paid bi-annually.\nEnd of term\nAt the conclusion of the 12 months council term, a report will be written on all activities undertaken by the DAO, with funds being accounted for. All unused funds will be returned to the DAO.\n\n 2\n\n read \n\n 5\n min\n\n post by Derrp on Sep 8, 2025\n\n Derrp\n\n It has been an honour to serve the community thus far, and we have consistently endeavoured to reward the community actively during our first 6 months.\nWe have some exciting things planned for the remainder of our tenure and can’t wait to get executing!! The most bullish thing is that our fellow community members are building the very systems that will reward you all. The community builders win, the community participants win. There has never been a better time to be a Pythian.\nPythia Provides.\n\n post by N0name_trader on Sep 8, 2025\n\n N0name_trader\n\n I guess pretty decent job was done for the first half of out term as CC.\nI fully support the requested budget for approval and as well as the necessary reduction in some fields\nSky is not the limit for us, 2nd half of the CC term will be even more intriguing and more things to come\nMy appreciation to purple CC members who make these things alive and as well as to each Pythian - without you there is no “community” term existing by itself!\n\n post by totti on Sep 8, 2025\n\n totti\n\n The Community Council has been doing a stellar job. The foundation has been laid, and the impact of the first term evident. We’re heading in the right direction with Pythenity and similar initiatives.\nAlso, heartfelt thank you to all the Community Council members. Your dedication to the community and the project is truly appreciated.\n\n post by T-Magic on Sep 8, 2025\n\n T-Magic\n\n I must say you guys are doing a great job in organizing and keeping the community running. It’s never an easy job because it consumes time and energy.\nThank you for having us around.\nRooting for pyth network always\n\n post by Ghost on Sep 8, 2025\n\n Ghost\n\n This is huge achievement for the Pyth ecosystem and kudos to all the councils…\nPythia always provides.\nGot a little question about the kaito campaign, is there going to be a chance for small and creative creators to continue participating with the recent upgrade on the platform or is the community council working on something to make it fair for everyone who genuinely creates good contents to preach the great gospel of Pyth to participate\n\n post by lowkeigh on Sep 8, 2025\n\n lowkeigh\n\n I fully support everything proposed above.\nIt has been a massive privilege to be involved with the CC so far, with the foundations now laid I’m excited to see what should be an even bigger 6 months coming for all Pythians.\nThank you to both my fellow CC members and all Pythians for this opportunity.\n\n OP-PIP-81: Community Council Budget Request for second half of Council term\n\n post by bats4 on Sep 9, 2025\n\n bats4\n\n First of all, i would like every Pyth Community member to ready the report\nSee what the CC have been doing for the past 6 months (almost).\nand i would also like to take the opportunity to thank everyone.\nThank you my Co-council, Pyth Team and Admins, Chirons, Mensarius and the whole Pyth Priests\nIt has been a privilege to serve the Pyth community and we are only halfway done.\n\n post by grizzlyland on Sep 9, 2025\n\n grizzlyland\n\n Firstly i would like to congratulate the CC on a stellar job during the first half of the term .\nThe Pyth Discord wouldnt be so fun and engaging without their efforts.\nSecondly,the transparency with which Pyth functions in terms of using $PYTH for community incentives in commendable.\nI am in full support of the proposal.\n\n post by good_boy98 on Sep 12, 2025\n\n good_boy98\n\n Very cool result.\nI’m looking forward to the start of a new stage.\nPyth team is one of those teams that really interacts with the community and develops. Even in the period after TGE. This is really an indicator that the team is moving in the right direction.\n\n post by scp on Sep 12, 2025\n\n scp\n\n Dear Council,\nGreat work overall — I’m very impressed.\nPerhaps I’m late to the game, but is there an official procedure for requesting funding support from the council? Can individuals / team submit proposals to request a budget for development? \nSCP\n\n post by lowkeigh on Sep 15, 2025\n\n lowkeigh\n\n Nothing is off limits mate, if you’ve got something cooking away in that big brain of yours feel free to either reach out to any of us on the CC or you can also create a post here on the forum too \nAll proposals will need to be discussed and agreed upon before any grants are given though.\nLooking forward to hearing what you’ve got for us \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n Pyth Community Council\n\n Ideas Bank\n\n 73\n\n 1.7k\n\n Aug 2024\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025\n\n Community Council Term #1 Exit Report\n\n Community Council\n\n 4\n\n 194\n\n Mar 29","tokens":3933,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267168129,"hash":"533642519090cd5bc92f5aeb4281966250d26824"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc6909","domain":"docs.openzeppelin.com","title":"ERC-6909 | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensERC-6909Open in ClaudeERC-6909 is a draft EIP that draws on ERC-1155 learnings since it was published in 2018. The main goals of ERC-6909 are to decrease gas costs and complexity--this is mainly accomplished by removing batching and callbacks.\nTo understand the inspiration for a multi token standard, see the multi token standard section within the EIP-1155 docs.\nChanges from ERC-1155\nThere are three main changes from ERC-1155 which are as follows:\n\nThe removal of batch operations.\nThe removal of transfer callbacks.\nGranularization in approvals--approvals can be set globally (as operators) or as amounts per token (inspired by ERC20).\n\nConstructing an ERC-6909 Token Contract\nWe’ll use ERC-6909 to track multiple items in a game, each having their own unique attributes. All item types will be minted to the deployer of the contract, which we can later transfer to players. We’ll also use the ERC6909Metadata extension to add decimals to our fungible items (the vanilla ERC-6909 implementation does not have decimals).\nFor simplicity, we will mint all items in the constructor--however, minting functionality could be added to the contract to mint on demand to players.\nFor an overview of minting mechanisms, check out Creating ERC-20 Supply.\nHere’s what a contract for tokenized items might look like:\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.20;\n\nimport {ERC6909Metadata} from \"@openzeppelin/contracts/token/ERC6909/extensions/ERC6909Metadata.sol\";\n\ncontract ERC6909GameItems is ERC6909Metadata {\n uint256 public constant GOLD = 0;\n uint256 public constant SILVER = 1;\n uint256 public constant THORS_HAMMER = 2;\n uint256 public constant SWORD = 3;\n uint256 public constant SHIELD = 4;\n\n constructor() {\n _setDecimals(GOLD, 18);\n _setDecimals(SILVER, 18);\n // Default decimals is 0\n _setDecimals(SWORD, 9);\n _setDecimals(SHIELD, 9);\n\n _mint(msg.sender, GOLD, 10 ** 18);\n _mint(msg.sender, SILVER, 10_000 ** 18);\n _mint(msg.sender, THORS_HAMMER, 1);\n _mint(msg.sender, SWORD, 10 ** 9);\n _mint(msg.sender, SHIELD, 10 ** 9);\n }\n}\nNote that there is no content URI functionality in the base implementation, but the ERC6909ContentURI extension adds it. Additionally, the base implementation does not track total supplies, but the ERC6909TokenSupply extension tracks the total supply of each token id.\nOnce the contract is deployed, we will be able to query the deployer’s balance:\n> gameItems.balanceOf(deployerAddress, 3)\n1000000000\nWe can transfer items to player accounts:\n> gameItems.transfer(playerAddress, 2, 1)\n> gameItems.balanceOf(playerAddress, 2)\n1\n> gameItems.balanceOf(deployerAddress, 2)\n0ERC-4626Previous PageGovernanceNext PageOn this pageChanges from ERC-1155Constructing an ERC-6909 Token Contract","tokens":689,"squid":"ink-security_audits","role":"Sentinel","at":1791267181596,"hash":"e7fdcc6522f57dfa1267471afdcb8dfc81693764"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/erc20-supply","domain":"docs.openzeppelin.com","title":"Creating ERC-20 Supply | OpenZeppelin Docs","text":"OpenZeppelin ContractsTokensERC-20Creating ERC-20 SupplyOpen in ClaudeIn this guide, you will learn how to create an ERC-20 token with a custom supply mechanism. We will showcase two idiomatic ways to use OpenZeppelin Contracts for this purpose that you will be able to apply to your smart contract development practice.\nThe standard interface implemented by tokens built on Ethereum is called ERC-20, and Contracts includes a widely used implementation of it: the aptly named ERC20 contract. This contract, like the standard itself, is quite simple and bare-bones. In fact, if you try to deploy an instance of ERC20 as-is it will be quite literally useless... it will have no supply! What use is a token with no supply?\nThe way that supply is created is not defined in the ERC-20 document. Every token is free to experiment with its own mechanisms, ranging from the most decentralized to the most centralized, from the most naive to the most researched, and more.\nFixed Supply\nLet’s say we want a token with a fixed supply of 1000, initially allocated to the account that deploys the contract. If you’ve used Contracts v1, you may have written code like the following:\ncontract ERC20FixedSupply is ERC20 {\n constructor() {\n totalSupply += 1000;\n balances[msg.sender] += 1000;\n }\n}\nStarting with Contracts v2, this pattern is not only discouraged, but disallowed. The variables totalSupply and balances are now private implementation details of ERC20, and you can’t directly write to them. Instead, there is an internal _mint function that will do exactly this:\ncontract ERC20FixedSupply is ERC20 {\n constructor() ERC20(\"Fixed\", \"FIX\") {\n _mint(msg.sender, 1000);\n }\n}\nEncapsulating state like this makes it safer to extend contracts. For instance, in the first example we had to manually keep the totalSupply in sync with the modified balances, which is easy to forget. In fact, we omitted something else that is also easily forgotten: the Transfer event that is required by the standard, and which is relied on by some clients. The second example does not have this bug, because the internal _mint function takes care of it.\nRewarding Block Proposers\nThe internal _mint function is the key building block that allows us to write ERC-20 extensions that implement a supply mechanism.\nThe mechanism we will implement is a token reward for the block proposer (the address that receives transaction fees). In Solidity, we can access this address using the global variable block.coinbase. Note that in Proof of Stake networks, block.coinbase refers to the fee recipient address, not a miner. We will mint a token reward to this address whenever someone calls the function mintMinerReward() on our token. The mechanism may sound silly, but you never know what kind of dynamic this might result in, and it’s worth analyzing and experimenting with!\ncontract ERC20WithMinerReward is ERC20 {\n constructor() ERC20(\"Reward\", \"RWD\") {}\n\n function mintMinerReward() public {\n _mint(block.coinbase, 1000);\n }\n}\nAs we can see, _mint makes it super easy to do this correctly.\nAutomating the Reward\nSo far our supply mechanism was triggered manually, but ERC20 also allows us to extend the core functionality of the token through the _update function.\nAdding to the supply mechanism from the previous section, we can use this function to mint a block proposer reward for every token transfer that is included in the blockchain.\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.8.20;\n\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract ERC20WithAutoMinerReward is ERC20 {\n constructor() ERC20(\"Reward\", \"RWD\") {\n _mintMinerReward();\n }\n\n function _mintMinerReward() internal {\n _mint(block.coinbase, 1000);\n }\n\n function _update(address from, address to, uint256 value) internal virtual override {\n if (!(from == address(0) && to == block.coinbase)) {\n _mintMinerReward();\n }\n super._update(from, to, value);\n }\n}\nWrapping Up\nWe’ve seen how to implement an ERC-20 supply mechanism: internally through _mint. Hopefully this has helped you understand how to use OpenZeppelin Contracts and some of the design principles behind it, and you can apply them to your own smart contracts.OverviewPrevious PageERC-721Next PageOn this pageFixed SupplyRewarding Block ProposersAutomating the RewardWrapping Up","tokens":1078,"squid":"ink-security_audits","role":"Sentinel","at":1791267191415,"hash":"2baf502177b5c6beb7524b0274dbe8a999a0eb20"}
{"url":"https://aave.com/docs/ecosystem/gho/sgho","domain":"aave.com","title":"Savings GHO (sGHO) | Aave Protocol Documentation","text":"Savings GHO (sGHO)#\n\nSavings GHO (sGHO) is a savings product for the GHO stablecoin, built as a native ERC-4626 vault and deployed on Ethereum mainnet. Users deposit GHO into the vault and receive sGHO shares that steadily increase in GHO value as yield accrues from an on-chain rate. Deposits and withdrawals are instant, with no cooldown period, no slashing risk, and no rehypothecation of deposited funds.\nSavings GHO Rate4.50%Total sGHO Supply169.4M GHO\nContract: 0xE1753F2e00940cC31213dd92013cF019DFE4ca1d (Ethereum Mainnet)\nsGHO replaces the legacy Merit-based sGHO contract. Legacy holders must\nwithdraw GHO from the old contract and deposit into the new vault to earn the\ncurrent rate. See Legacy sGHO for the previous API.\nVault State#\nFetch the current state of the sGHO vault, including rates, totals, and an optional user position.\nReactTypeScriptGraphQLUse the useSghoVault hook to read vault data and an optional user position.const { data, loading, error } = useSghoVault({ chainId: chainId(1), user: evmAddress(\"0x742d35cc…\"), // optional});import { useSghoVault, chainId, evmAddress } from \"@aave/react\";import { useAccount } from \"wagmi\";\n// …\nconst { address } = useAccount();\nconst { data, loading, error } = useSghoVault({ chainId: chainId(1), user: address ? evmAddress(address) : undefined,});\nif (loading) return <p>Loading…</p>;if (error) return <p>Error: {error.message}</p>;\n// data.totalAssets — total GHO locked in the vault// data.targetRate — current fixed APR// data.supplyCap — maximum GHO that can be deposited// data.paused — whether deposits and withdrawals are blocked// data.user?.shares — user's sGHO shares balance// data.user?.balance — GHO value of the user's shares// data.user?.maxDeposit — max GHO the user can deposit// data.user?.maxWithdraw — max GHO the user can withdraw\nDeposit#\nDeposit GHO into the sGHO vault to start earning yield.\n1Prepare the Execution Plan#ReactTypeScriptGraphQLUse the useSghoVaultDeposit hook to create the execution plan for depositing GHO.import { useWalletClient } from \"wagmi\";import { useSghoVaultDeposit, bigDecimal, evmAddress, chainId } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deposit, depositing] = useSghoVaultDeposit();\nconst execute = async () => { const result = await deposit({ amount: { value: bigDecimal(1000), // 1000 GHO }, depositor: evmAddress(walletClient!.account.address), chainId: chainId(1), // sharesRecipient: evmAddress(\"0x1234…\"), // defaults to depositor });\n // …};2Process the Execution Plan#ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useSghoVaultDeposit } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deposit, depositing] = useSghoVaultDeposit();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = depositing.loading || sending.loading;const error = depositing.error || sending.error;\n// …\nconst execute = async () => { const result = await deposit({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"ApprovalRequired\": return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Deposit failed:\", result.error); } else { console.log(\"Deposit successful:\", result.value); }};\nRedeem#\nRedeem sGHO shares for GHO. Withdrawals are atomic with no cooldown period.\n1Prepare the Execution Plan#ReactTypeScriptGraphQLUse the useSghoVaultRedeemShares hook to create the execution plan. Pass maxRedeem: true to redeem all shares, or shares for an exact amount.import { useWalletClient } from \"wagmi\";import { useSghoVaultRedeemShares, bigDecimal, evmAddress, chainId,} from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [redeemShares, redeeming] = useSghoVaultRedeemShares();\nconst execute = async () => { const result = await redeemShares({ amount: { maxRedeem: true }, // or: { shares: bigDecimal(1000) } sharesOwner: evmAddress(walletClient!.account.address), chainId: chainId(1), // recipient: evmAddress(\"0x1234…\"), // defaults to sharesOwner });\n // …};2Process the Execution Plan#ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { errAsync, useSghoVaultRedeemShares } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [redeemShares, redeeming] = useSghoVaultRedeemShares();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = redeeming.loading || sending.loading;const error = redeeming.error || sending.error;\n// …\nconst execute = async () => { const result = await redeemShares({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"InsufficientBalanceError\": return errAsync( new Error( `Insufficient balance: ${plan.required.value} is the maximum redemption allowed.` ) ); } });\n if (result.isErr()) { console.error(\"Redeem failed:\", result.error); } else { console.log(\"Redeem successful:\", result.value); }};\nPreview#\nPreview the outcome of a deposit or redeem before submitting a transaction. Useful for showing users expected shares or GHO amounts in a UI.\nPreview Deposit#\nReturns the number of sGHO shares that would be minted for a given GHO deposit amount.\nReactTypeScriptGraphQLconst { data, loading, error } = useSghoVaultPreviewDeposit({ amount: \"1000\", chainId: chainId(1),});import { useSghoVaultPreviewDeposit, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useSghoVaultPreviewDeposit({ amount: \"1000\", // GHO to deposit chainId: chainId(1),});\nif (loading) return <p>Loading…</p>;if (error) return <p>Error: {error.message}</p>;\n// data: DecimalValue — sGHO shares to be minted\nPreview Redeem#\nReturns the GHO amount that would be received for redeeming a given number of sGHO shares.\nReactTypeScriptGraphQLconst { data, loading, error } = useSghoVaultPreviewRedeem({ amount: \"995\", chainId: chainId(1),});import { useSghoVaultPreviewRedeem, chainId } from \"@aave/react\";\n// …\nconst { data, loading, error } = useSghoVaultPreviewRedeem({ amount: \"995\", // sGHO shares to redeem chainId: chainId(1),});\nif (loading) return <p>Loading…</p>;if (error) return <p>Error: {error.message}</p>;\n// data: DecimalValue — GHO amount to be received\n\nLegacy sGHO#\nThe Merit-based sGHO contract is being phased out. Users should withdraw GHO\nfrom the legacy contract and deposit into the new ERC-4626 sGHO vault to earn\nthe current rate. The legacy reward rate steps down in phases until it reaches\n0%.\nThe following API covers the legacy sGHO contract (Merit-based reward distribution via Merkl).\nDeposit#\nTo start earning rewards by depositing GHO into sGHO, follow these steps.\n1Prepare the Execution Plan#First, prepare the execution plan for the deposit operation.ReactTypeScriptGraphQLUse the useSavingsGhoDeposit hook to create the execution plan for depositing GHO to sGHO.import { useWalletClient } from \"wagmi\";import { useSavingsGhoDeposit, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deposit, depositing] = useSavingsGhoDeposit();\nconst execute = async () => { const result = await deposit({ amount: { value: bigDecimal(1000), // 1000 GHO }, depositor: evmAddress(walletClient!.account.address), });\n // …};2Process the Execution Plan#Then, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { errAsync, useSavingsGhoDeposit } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [deposit, depositing] = useSavingsGhoDeposit();const [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\nconst loading = depositing.loading || sending.loading;const error = depositing.error || sending.error;\n// …\nconst execute = async () => { const result = await deposit({ // … }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": // Single transaction execution return sendTransaction(plan);\n case \"ApprovalRequired\": // Approval + transaction sequence return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error(`Insufficient balance: ${plan.required.value} required.`) ); } });\n if (result.isErr()) { console.error(\"Deposit failed:\", result.error); } else { console.log(\"Deposit successful with hash:\", result.value); }};\nBalance#\nRetrieve the balance of a user's sGHO.\nReactTypeScriptGraphQLUse the useSavingsGhoBalance hook to fetch the balance of a user's sGHO.const { data, loading, error } = useSavingsGhoBalance({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"),});Fetch the balance of a user's sGHO.import { useSavingsGhoBalance, evmAddress } from \"@aave/react\";\n// …\nconst { data, loading, error } = useSavingsGhoBalance({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"),});\nif (loading) { return <p>Loading sGHO balance...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\n// data: TokenAmount\nWithdraw#\nWithdraw sGHO to GHO instantly with no cooldown period. You can still claim any previous rewards.\nFollow these steps to withdraw sGHO to GHO:\n1Prepare the Execution Plan#First, prepare the execution plan for the withdrawal operation.ReactTypeScriptGraphQLUse the useSavingsGhoWithdraw hook to create the execution plan for withdrawing sGHO to GHO.import { useWalletClient } from \"wagmi\";import { useSavingsGhoWithdraw, bigDecimal, evmAddress } from \"@aave/react\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useSavingsGhoWithdraw();\nconst execute = async () => { const result = await withdraw({ amount: { value: bigDecimal(1000), // 1000 sGHO }, sharesOwner: evmAddress(walletClient!.account.address), // recipient: evmAddress(\"0x1234…\"), if different from sharesOwner });\n // …};2Process the Execution Plan#Finally, handle the execution plan.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transaction.import { useWalletClient } from \"wagmi\";import { useSavingsGhoWithdraw, bigDecimal, evmAddress, errAsync,} from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();\nconst [withdraw, withdrawing] = useSavingsGhoWithdraw();const [sendTransaction, sending] = useSendTransaction(walletClient);\nconst loading = withdrawing.loading || sending.loading;const error = withdrawing.error || sending.error;\n// …\nconst execute = async () => { const result = await withdraw({ amount: { value: bigDecimal(1000), // 1000 sGHO }, sharesOwner: evmAddress(walletClient!.account.address), // recipient: evmAddress(\"0x1234…\"), if different from sharesOwner }).andThen((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan);\n case \"ApprovalRequired\": return sendTransaction(plan.approval).andThen(() => sendTransaction(plan.originalTransaction) );\n case \"InsufficientBalanceError\": return errAsync( new Error( `Insufficient balance to withdraw: ${plan.required.value} is the maximum withdrawal allowed.` ) ); } });\n if (result.isErr()) { console.error(\"Withdraw failed:\", result.error); } else { console.log(\"Withdraw successful:\", result.value); }};\nClaiming Incentives#\nUsers who deposit into the legacy sGHO become eligible for rewards distributed through Merkl.\nThese rewards are not automatically added to the sGHO balance, they must be\nclaimed separately.\nUsers can claim rewards in two ways:\nThrough the ACI Merit UI for a simple interface to view and claim rewardsUsing the SDK\nFollow these steps to claim rewards using the SDK:\n1Fetch the Claimable Rewards#First, determine if a user has claimable rewards.ReactTypeScriptGraphQLUse the useUserMeritRewards hook to fetch the user's sGHO claimable rewards and the transaction to claim them.const { data, loading, error } = useUserMeritRewards({ user: EvmAddress, chainId: ChainId,});Fetch the user's claimable rewards and the transaction to claim them.import { useUserMeritRewards, evmAddress, chainId } from \"@aave/react\";\n// …\nconst sGHO_ADDRESS = evmAddress(\"0x1a88Df1cFe15Af22B3c4c783D4e6F7F9e0C1885d\");\nconst { data, loading, error } = useUserMeritRewards({ user: evmAddress(\"0x742d35cc6e5c4ce3b69a2a8c7c8e5f7e9a0b1234\"), chainId: chainId(1), filter: { tokens: [sGHO_ADDRESS], },});\nif (loading) { return <p>Loading claimable rewards...</p>;}\nif (error) { return <p>Error: {error.message}</p>;}\n// data: UserMeritRewards | nullIf data is null, the user has no sGHO claimable rewards.2Claim Rewards#Finally, if the user has claimable rewards, they can claim them by sending the transaction.ReactTypeScriptGraphQLUse the useSendTransaction hook for the wallet library of your choice to send the transactions in the execution plan.import { useWalletClient } from \"wagmi\";import { useUserMeritRewards } from \"@aave/react\";import { useSendTransaction } from \"@aave/react/viem\";\n// …\nconst { data: walletClient } = useWalletClient();const { data } = useUserMeritRewards({ // … suspense: true,});\nconst [sendTransaction, sending] = useSendTransaction(walletClient);\n// …\nconst execute = async () => { if (data !== null) { const result = await sendTransaction(data.transaction);\n if (result.isErr()) { console.error(result.error.message); } else { console.log(\"sGHO claim rewards successful with hash:\", result.value); } }};\nFor more details, see the GHO Savings Upgrade forum post.PreviousGHONextGovernance","tokens":3549,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267193110,"hash":"3cef9b8c8c046cea6a6294ea7f202a54f405fd3b"}
{"url":"https://io.net/intelligence","domain":"io.net","title":"The Open Source AI Infrastructure Platform - io.net - io.net","text":"Open Source ModelsEnterprise AIwithout enterprise costsTake your AI project from concept to sustainable business, without the complexity or high costs, with io.intelligenceScale with over 50+ AI ModelsXiaomiDeepSeekZ.aiAlibaba CloudMoonshot AIMiniMaxGoogleOpen AIMeta AIMistral AIBuilt to scaleFrom launching a prototype to scaling to millions of users, io.intelligence grows with your project, without rebuilds or migrations.Growing projectsHandle enterprise-scale traffic while reducing spend so you can focus on your product, not your runway.Launch AI studioStart building from day oneLaunch your product and scale as you grow, without the complexity, upfront costs, or vendor lock in.Get started for freeSign up with only your email, and get free credits for every model - no credit card, no sales calls.Build with the latest modelsOne API for every major frontier AI lab including Google, Microsoft, OpenAI, Alibaba, Mistral, DeepSeek, and more.Launch and scale your productHandle any load, from 10 requests to 10 million, to seamlessly go from prototype to production.Integrate your current stackIntegrate AI into your current products without rearchitecting using OpenAI compatible APIs for fewer code changes.AI development made simpleOpen modelsAccess and seamlessly switch between 12+ open-weight models, from one account with one key.A fraction of frontier pricesPrototype freely and only pay for what you use without rate limits, contracts, or minimums.Developer- friendly unified APIDeploy in minutes with OpenAI compatible APIs across text, image, and speech modalities.Complete AI studioRAG with document upload, custom agents, deterministic parameter validation with a simple inference interface.Start building enterprise AI, without enterprise costsJoin thousands of developers taking their AI projects from concept to sustainable businesses, without the high costs or complexity.Launch AI studioTalk to an expert","tokens":483,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267193877,"hash":"e78a31138ec1437af2ed4932c4cf631352e2bc05"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api/token/ERC20","domain":"docs.openzeppelin.com","title":"ERC20 | OpenZeppelin Docs","text":"ERC20Smart contract ERC20 utilities and implementationsOpen in ClaudeThis set of interfaces, contracts, and utilities are all related to the ERC-20 Token Standard.\nFor an overview of ERC-20 tokens and a walk through on how to create a token contract read our ERC-20 guide.\nThere are a few core contracts that implement the behavior specified in the ERC-20 standard:\n\nIERC20: the interface all ERC-20 implementations should conform to.\nIERC20Metadata: the extended ERC-20 interface including the name, symbol and decimals functions.\nERC20: the implementation of the ERC-20 interface, including the name, symbol and decimals optional extensions to the standard interface.\n\nAdditionally there are multiple custom extensions, including:\n\nERC20Permit: gasless approval of tokens (standardized as ERC-2612).\nERC20Bridgeable: compatibility with crosschain bridges through ERC-7802.\nERC20Burnable: destruction of own tokens.\nERC20Capped: enforcement of a cap to the total supply when minting tokens.\nERC20Crosschain: embedded BridgeFungible bridge, making the token crosschain through the use of ERC-7786 gateways.\nERC20Pausable: ability to pause token transfers.\nERC20FlashMint: token level support for flash loans through the minting and burning of ephemeral tokens (standardized as ERC-3156).\nERC20Votes: support for voting and vote delegation. See the governance guide for a minimal example (with the required overrides when combining ERC20 + ERC20Permit + ERC20Votes).\nERC20Wrapper: wrapper to create an ERC-20 backed by another ERC-20, with deposit and withdraw methods. Useful in conjunction with ERC20Votes.\nERC20TemporaryApproval: support for approvals lasting for only one transaction, as defined in ERC-7674.\nERC1363: support for calling the target of a transfer or approval, enabling code execution on the receiver within a single transaction.\nERC4626: tokenized vault that manages shares (represented as ERC-20) that are backed by assets (another ERC-20).\n\nFinally, there are some utilities to interact with ERC-20 contracts in various ways:\n\nSafeERC20: a wrapper around the interface that eliminates the need to handle boolean return values.\n\nOther utilities that support ERC-20 assets can be found in the codebase:\n\nERC-20 tokens can be timelocked (held for a beneficiary until a specified time) or vested (released following a given schedule) using a VestingWallet.\n\nThis core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC-20 (such as _mint) and expose them as external functions in the way they prefer.\nCore\nIERC20\nIERC20Metadata\nERC20\nExtensions\nIERC20Permit\nERC20Permit\nERC20Bridgeable\nERC20Burnable\nERC20Capped\nERC20Crosschain\nERC20Pausable\nERC20Votes\nERC20Wrapper\nERC20FlashMint\nERC20TemporaryApproval\nERC1363\nERC4626\nUtilities\nSafeERC20\nERC1363Utils\n\nERC20\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nImplementation of the IERC20 interface.\nThis implementation is agnostic to the way tokens are created. This means\nthat a supply mechanism has to be added in a derived contract using ERC20._mint.\nFor a detailed writeup see our guide\nHow\nto implement supply mechanisms.\nThe default value of ERC20.decimals is 18. To change this, you should override\nthis function so it returns a different value.\nWe have followed general OpenZeppelin Contracts guidelines: functions revert\ninstead returning false on failure. This behavior is nonetheless\nconventional and does not conflict with the expectations of ERC-20\napplications.\nFunctions\nconstructor(name_, symbol_)\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrorsIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nconstructor(string name_, string symbol_)internal#Sets the values for ERC20.name and ERC20.symbol.Both values are immutable: they can only be set once during construction.\n\nname() → stringpublic#Returns the name of the token.\n\nsymbol() → stringpublic#Returns the symbol of the token, usually a shorter version of the\nname.\n\ndecimals() → uint8public#Returns the number of decimals used to get its user representation.\nFor example, if decimals equals 2, a balance of 505 tokens should\nbe displayed to a user as 5.05 (505 / 10 ** 2).Tokens usually opt for a value of 18, imitating the relationship between\nEther and Wei. This is the default value returned by this function, unless\nit's overridden.This information is only used for display purposes: it in\nno way affects any of the arithmetic of the contract, including\nIERC20.balanceOf and IERC20.transfer.\n\ntotalSupply() → uint256public#Returns the value of tokens in existence.\n\nbalanceOf(address account) → uint256public#Returns the value of tokens owned by account.\n\ntransfer(address to, uint256 value) → boolpublic#See IERC20.transfer.Requirements:\nto cannot be the zero address.\nthe caller must have a balance of at least value.\n\nallowance(address owner, address spender) → uint256public#Returns the remaining number of tokens that spender will be\nallowed to spend on behalf of owner through ERC20.transferFrom. This is\nzero by default.This value changes when ERC20.approve or ERC20.transferFrom are called.\n\napprove(address spender, uint256 value) → boolpublic#See IERC20.approve.If value is the maximum uint256, the allowance is not updated on\ntransferFrom. This is semantically equivalent to an infinite approval.Requirements:\nspender cannot be the zero address.\n\ntransferFrom(address from, address to, uint256 value) → boolpublic#See IERC20.transferFrom.Skips emitting an IERC20.Approval event indicating an allowance update. This is not\nrequired by the ERC. See _approve.Does not update the allowance if the current allowance\nis the maximum uint256.Requirements:\nfrom and to cannot be the zero address.\nfrom must have a balance of at least value.\nthe caller must have allowance for from's tokens of at least\nvalue.\n\n_transfer(address from, address to, uint256 value)internal#Moves a value amount of tokens from from to to.This internal function is equivalent to ERC20.transfer, and can be used to\ne.g. implement automatic token fees, slashing mechanisms, etc.Emits a IERC20.Transfer event.This function is not virtual, ERC20._update should be overridden instead.\n\n_update(address from, address to, uint256 value)internal#Transfers a value amount of tokens from from to to, or alternatively mints (or burns) if from\n(or to) is the zero address. All customizations to transfers, mints, and burns should be done by overriding\nthis function.Emits a IERC20.Transfer event.\n\n_mint(address account, uint256 value)internal#Creates a value amount of tokens and assigns them to account, by transferring it from address(0).\nRelies on the _update mechanismEmits a IERC20.Transfer event with from set to the zero address.This function is not virtual, ERC20._update should be overridden instead.\n\n_burn(address account, uint256 value)internal#Destroys a value amount of tokens from account, lowering the total supply.\nRelies on the _update mechanism.Emits a IERC20.Transfer event with to set to the zero address.This function is not virtual, ERC20._update should be overridden instead\n\n_approve(address owner, address spender, uint256 value)internal#Sets value as the allowance of spender over the owner's tokens.This internal function is equivalent to approve, and can be used to\ne.g. set automatic allowances for certain subsystems, etc.Emits an IERC20.Approval event.Requirements:\nowner cannot be the zero address.\nspender cannot be the zero address.\nOverrides to this logic should be done to the variant with an additional bool emitEvent argument.\n\n_approve(address owner, address spender, uint256 value, bool emitEvent)internal#Variant of ERC20._approve with an optional flag to enable or disable the IERC20.Approval event.By default (when calling ERC20._approve) the flag is set to true. On the other hand, approval changes made by\n_spendAllowance during the transferFrom operation sets the flag to false. This saves gas by not emitting any\nApproval event during transferFrom operations.Anyone who wishes to continue emitting Approval events on the transferFrom operation can force the flag to\ntrue using the following override:function _approve(address owner, address spender, uint256 value, bool) internal virtual override {\n super._approve(owner, spender, value, true);\n}Requirements are the same as ERC20._approve.\n\n_spendAllowance(address owner, address spender, uint256 value)internal#Updates owner's allowance for spender based on spent value.Does not update the allowance value in case of infinite allowance.\nRevert if not enough allowance is available.Does not emit an IERC20.Approval event.\n\nIERC20\nimport \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\nInterface of the ERC-20 standard as defined in the ERC.\nFunctions\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n\nEvents\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\ntotalSupply() → uint256external#Returns the value of tokens in existence.\n\nbalanceOf(address account) → uint256external#Returns the value of tokens owned by account.\n\ntransfer(address to, uint256 value) → boolexternal#Moves a value amount of tokens from the caller's account to to.Returns a boolean value indicating whether the operation succeeded.Emits a IERC20.Transfer event.\n\nallowance(address owner, address spender) → uint256external#Returns the remaining number of tokens that spender will be\nallowed to spend on behalf of owner through ERC20.transferFrom. This is\nzero by default.This value changes when ERC20.approve or ERC20.transferFrom are called.\n\napprove(address spender, uint256 value) → boolexternal#Sets a value amount of tokens as the allowance of spender over the\ncaller's tokens.Returns a boolean value indicating whether the operation succeeded.Beware that changing an allowance with this method brings the risk\nthat someone may use both the old and the new allowance by unfortunate\ntransaction ordering. One possible solution to mitigate this race\ncondition is to first reduce the spender's allowance to 0 and set the\ndesired value afterwards:\nhttps://github.com/ethereum/EIPs/issues/20#issuecomment-263524729Emits an IERC20.Approval event.\n\ntransferFrom(address from, address to, uint256 value) → boolexternal#Moves a value amount of tokens from from to to using the\nallowance mechanism. value is then deducted from the caller's\nallowance.Returns a boolean value indicating whether the operation succeeded.Emits a IERC20.Transfer event.\n\nTransfer(address indexed from, address indexed to, uint256 value)event#Emitted when value tokens are moved from one account (from) to\nanother (to).Note that value may be zero.\n\nApproval(address indexed owner, address indexed spender, uint256 value)event#Emitted when the allowance of a spender for an owner is set by\na call to ERC20.approve. value is the new allowance.\n\nERC1363\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC1363.sol\";\nExtension of ERC20 tokens that adds support for code execution after transfers and approvals\non recipient contracts. Calls after transfers are enabled through the ERC1363.transferAndCall and\nERC1363.transferFromAndCall methods while calls after approvals can be made with ERC1363.approveAndCall\nAvailable since v5.1.\nFunctions\nsupportsInterface(interfaceId)\ntransferAndCall(to, value)\ntransferAndCall(to, value, data)\ntransferFromAndCall(from, to, value)\ntransferFromAndCall(from, to, value, data)\napproveAndCall(spender, value)\napproveAndCall(spender, value, data)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC1363TransferFailed(receiver, value)\nERC1363TransferFromFailed(sender, receiver, value)\nERC1363ApproveFailed(spender, value)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#Returns true if this contract implements the interface defined by\ninterfaceId. See the corresponding\nERC section\nto learn more about how these ids are created.This function call must use less than 30 000 gas.\n\ntransferAndCall(address to, uint256 value) → boolpublic#Moves a value amount of tokens from the caller's account to to\nand then calls IERC1363Receiver.onTransferReceived on to. Returns a flag that indicates\nif the call succeeded.Requirements:\nThe target has code (i.e. is a contract).\nThe target to must implement the IERC1363Receiver interface.\nThe target must return the IERC1363Receiver.onTransferReceived selector to accept the transfer.\nThe internal ERC20.transfer must succeed (returned true).\n\ntransferAndCall(address to, uint256 value, bytes data) → boolpublic#Variant of ERC1363.transferAndCall that accepts an additional data parameter with\nno specified format.\n\ntransferFromAndCall(address from, address to, uint256 value) → boolpublic#Moves a value amount of tokens from from to to using the allowance mechanism\nand then calls IERC1363Receiver.onTransferReceived on to. Returns a flag that indicates\nif the call succeeded.Requirements:\nThe target has code (i.e. is a contract).\nThe target to must implement the IERC1363Receiver interface.\nThe target must return the IERC1363Receiver.onTransferReceived selector to accept the transfer.\nThe internal ERC20.transferFrom must succeed (returned true).\n\ntransferFromAndCall(address from, address to, uint256 value, bytes data) → boolpublic#Variant of ERC1363.transferFromAndCall that accepts an additional data parameter with\nno specified format.\n\napproveAndCall(address spender, uint256 value) → boolpublic#Sets a value amount of tokens as the allowance of spender over the\ncaller's tokens and then calls IERC1363Spender.onApprovalReceived on spender.\nReturns a flag that indicates if the call succeeded.Requirements:\nThe target has code (i.e. is a contract).\nThe target spender must implement the IERC1363Spender interface.\nThe target must return the IERC1363Spender.onApprovalReceived selector to accept the approval.\nThe internal ERC20.approve must succeed (returned true).\n\napproveAndCall(address spender, uint256 value, bytes data) → boolpublic#Variant of ERC1363.approveAndCall that accepts an additional data parameter with\nno specified format.\n\nERC1363TransferFailed(address receiver, uint256 value)error#Indicates a failure within the ERC20.transfer part of a transferAndCall operation.\n\nERC1363TransferFromFailed(address sender, address receiver, uint256 value)error#Indicates a failure within the ERC20.transferFrom part of a transferFromAndCall operation.\n\nERC1363ApproveFailed(address spender, uint256 value)error#Indicates a failure within the ERC20.approve part of a approveAndCall operation.\n\nERC20Burnable\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol\";\nExtension of ERC20 that allows token holders to destroy both their own\ntokens and those that they have an allowance for, in a way that can be\nrecognized off-chain (via event analysis).\nFunctions\nburn(value)\nburnFrom(account, value)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrorsIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nburn(uint256 value)public#Destroys a value amount of tokens from the caller.See ERC20._burn.\n\nburnFrom(address account, uint256 value)public#Destroys a value amount of tokens from account, deducting from\nthe caller's allowance.See ERC20._burn and ERC20.allowance.Requirements:\nthe caller must have allowance for accounts's tokens of at least\nvalue.\n\nERC20Capped\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Capped.sol\";\nExtension of ERC20 that adds a cap to the supply of tokens.\nFunctions\nconstructor(cap_)\ncap()\n_update(from, to, value)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC20ExceededCap(increasedSupply, cap)\nERC20InvalidCap(cap)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nconstructor(uint256 cap_)internal#Sets the value of the cap. This value is immutable, it can only be\nset once during construction.\n\ncap() → uint256public#Returns the cap on the token's total supply.\n\n_update(address from, address to, uint256 value)internal#Transfers a value amount of tokens from from to to, or alternatively mints (or burns) if from\n(or to) is the zero address. All customizations to transfers, mints, and burns should be done by overriding\nthis function.Emits a IERC20.Transfer event.\n\nERC20ExceededCap(uint256 increasedSupply, uint256 cap)error#Total supply cap has been exceeded.\n\nERC20InvalidCap(uint256 cap)error#The supplied cap is not a valid cap.\n\nERC20Crosschain\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Crosschain.sol\";\nExtension of ERC20 that makes it natively cross-chain using the ERC-7786 based BridgeFungible.\nThis extension makes the token compatible with counterparts on other chains, which can be:\n\nERC20Crosschain instances,\nERC20 instances that are bridged using BridgeERC20,\nERC20Bridgeable instances that are bridged using BridgeERC7802.\n\nIt is mostly equivalent to inheriting from both ERC20Bridgeable and BridgeERC7802, and configuring them such\nthat:\n\ntoken (on the BridgeERC7802 side) is address(this),\n_checkTokenBridge (on the ERC20Bridgeable side) is implemented such that it only accepts self-calls.\n\nFunctions\ncrosschainTransferFrom(from, to, amount)\n_onSend(from, amount)\n_onReceive(to, amount)\nBridgeFungible\ncrosschainTransfer(to, amount)\n_crosschainTransfer(from, to, amount)\n_processMessage(, receiveId, , payload)\nCrosschainLinked\ngetLink(chain)\n_setLink(gateway, counterpart, allowOverride)\n_sendMessageToCounterpart(chain, payload, attributes)\n_isAuthorizedGateway(instance, sender)\nERC7786Recipient\nreceiveMessage(receiveId, sender, payload)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsBridgeFungible\nCrosschainFungibleTransferSent(sendId, from, to, amount)\nCrosschainFungibleTransferReceived(receiveId, from, to, amount)\nCrosschainLinked\nLinkRegistered(gateway, counterpart)\nIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrorsCrosschainLinked\nLinkAlreadyRegistered(chain)\nERC7786Recipient\nERC7786RecipientUnauthorizedGateway(gateway, sender)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\ncrosschainTransferFrom(address from, bytes to, uint256 amount) → bytes32public#Variant of BridgeFungible.crosschainTransfer that allows an authorized account (using ERC20 allowance) to operate on from's assets.\n\n_onSend(address from, uint256 amount)internal#\"Locking\" tokens is achieved through burning\n\n_onReceive(address to, uint256 amount)internal#\"Unlocking\" tokens is achieved through minting\n\nERC20FlashMint\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20FlashMint.sol\";\nImplementation of the ERC-3156 Flash loans extension, as defined in\nERC-3156.\nAdds the ERC20FlashMint.flashLoan method, which provides flash loan support at the token\nlevel. By default there is no fee, but this can be changed by overriding ERC20FlashMint.flashFee.\nWhen this extension is used along with the ERC20Capped or ERC20Votes extensions,\nERC20FlashMint.maxFlashLoan will not correctly reflect the maximum that can be flash minted. We recommend\noverriding ERC20FlashMint.maxFlashLoan so that it correctly reflects the supply cap.\nFunctions\nmaxFlashLoan(token)\nflashFee(token, value)\n_flashFee(, )\n_flashFeeReceiver()\nflashLoan(receiver, token, value, data)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC3156UnsupportedToken(token)\nERC3156ExceededMaxLoan(maxLoan)\nERC3156InvalidReceiver(receiver)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nmaxFlashLoan(address token) → uint256public#Returns the maximum amount of tokens available for loan.This function will not automatically detect any supply cap\nadded by other extensions, such as ERC20Capped. If necessary,\noverride this function to take a supply cap into account.\n\nflashFee(address token, uint256 value) → uint256public#Returns the fee applied when doing flash loans. This function calls\nthe ERC20FlashMint._flashFee function which returns the fee applied when doing flash\nloans.\n\n_flashFee(address, uint256) → uint256internal#Returns the fee applied when doing flash loans. By default this\nimplementation has 0 fees. This function can be overloaded to make\nthe flash loan mechanism deflationary.\n\n_flashFeeReceiver() → addressinternal#Returns the receiver address of the flash fee. By default this\nimplementation returns the address(0) which means the fee amount will be burnt.\nThis function can be overloaded to change the fee receiver.\n\nflashLoan(contract IERC3156FlashBorrower receiver, address token, uint256 value, bytes data) → boolpublic#Performs a flash loan. New tokens are minted and sent to the\nreceiver, who is required to implement the IERC3156FlashBorrower\ninterface. By the end of the flash loan, the receiver is expected to own\nvalue + fee tokens and have them approved back to the token contract itself so\nthey can be burned.\n\nERC3156UnsupportedToken(address token)error#The loan token is not valid.\n\nERC3156ExceededMaxLoan(uint256 maxLoan)error#The requested loan exceeds the max loan value for token.\n\nERC3156InvalidReceiver(address receiver)error#The receiver of a flashloan is not a valid IERC3156FlashBorrower.onFlashLoan implementer.\n\nERC20Pausable\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Pausable.sol\";\nERC-20 token with pausable token transfers, minting and burning.\nUseful for scenarios such as preventing trades until the end of an evaluation\nperiod, or having an emergency switch for freezing all token transfers in the\nevent of a large bug.\nThis contract does not include public pause and unpause functions. In\naddition to inheriting this contract, you must define both functions, invoking the\nPausable._pause and Pausable._unpause internal functions, with appropriate\naccess control, e.g. using AccessControl or Ownable. Not doing so will\nmake the contract pause mechanism of the contract unreachable, and thus unusable.\nFunctions\n_update(from, to, value)\nPausable\npaused()\n_requireNotPaused()\n_requirePaused()\n_pause()\n_unpause()\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsPausable\nPaused(account)\nUnpaused(account)\nIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrorsPausable\nEnforcedPause()\nExpectedPause()\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\n_update(address from, address to, uint256 value)internal#See ERC20._update.Requirements:\nthe contract must not be paused.\n\nERC20Permit\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol\";\nImplementation of the ERC-20 Permit extension allowing approvals to be made via signatures, as defined in\nERC-2612.\nAdds the ERC20Permit.permit method, which can be used to change an account's ERC-20 allowance (see IERC20.allowance) by\npresenting a message signed by the account. By not relying on [IERC20.approve](#IERC20-approve-address-uint256-), the token holder account doesn't\nneed to send a transaction, and thus is not required to hold Ether at all.\nFunctions\nconstructor(name)\npermit(owner, spender, value, deadline, v, r, s)\nnonces(owner)\nDOMAIN_SEPARATOR()\nNonces\n_useNonce(owner)\n_useCheckedNonce(owner, nonce)\nEIP712\n_domainSeparatorV4()\n_hashTypedDataV4(structHash)\neip712Domain()\n_EIP712Name()\n_EIP712Version()\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC5267\nEIP712DomainChanged()\nIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC2612ExpiredSignature(deadline)\nERC2612InvalidSigner(signer, owner)\nNonces\nInvalidAccountNonce(account, currentNonce)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nconstructor(string name)internal#Initializes the EIP712 domain separator using the name parameter, and setting version to \"1\".It's a good idea to use the same name that is defined as the ERC-20 token name.\n\npermit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)public#Sets value as the allowance of spender over owner's tokens,\ngiven owner's signed approval.The same issues IERC20.approve has related to transaction\nordering also applies here.Emits an IERC20.Approval event.Requirements:\nspender cannot be the zero address.\ndeadline must be a timestamp in the future.\nv, r and s must be a valid secp256k1 signature from owner\nover the EIP712-formatted function arguments.\nthe signature must use owner's current nonce (see ERC20Permit.nonces).\nFor more information on the signature format, see the\nrelevant EIP\nsection.See Security Considerations above.\n\nnonces(address owner) → uint256public#Returns the current nonce for owner. This value must be\nincluded whenever a signature is generated for ERC20Permit.permit.Every successful call to ERC20Permit.permit increases owner's nonce by one. This\nprevents a signature from being used multiple times.\n\nDOMAIN_SEPARATOR() → bytes32external#Returns the domain separator used in the encoding of the signature for ERC20Permit.permit, as defined by EIP712.\n\nERC2612ExpiredSignature(uint256 deadline)error#Permit deadline has expired.\n\nERC2612InvalidSigner(address signer, address owner)error#Mismatched signature.\n\nERC20Votes\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol\";\nExtension of ERC-20 to support Compound-like voting and delegation. This version is more generic than Compound's,\nand supports token supply up to 2^208^ - 1, while COMP is limited to 2^96^ - 1.\nThis contract does not provide interface compatibility with Compound's COMP token.\nThis extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either\nby calling the Votes.delegate function directly, or by providing a signature to be used with Votes.delegateBySig. Voting\npower can be queried through the public accessors Votes.getVotes and Votes.getPastVotes.\nBy default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it\nrequires users to delegate to themselves in order to activate checkpoints and have their voting power tracked.\nFunctions\n_maxSupply()\n_update(from, to, value)\n_getVotingUnits(account)\nnumCheckpoints(account)\ncheckpoints(account, pos)\nVotes\nclock()\nCLOCK_MODE()\n_validateTimepoint(timepoint)\ngetVotes(account)\ngetPastVotes(account, timepoint)\ngetPastTotalSupply(timepoint)\n_getTotalSupply()\ndelegates(account)\ndelegate(delegatee)\ndelegateBySig(delegatee, nonce, expiry, v, r, s)\n_delegate(account, delegatee)\n_transferVotingUnits(from, to, amount)\n_moveDelegateVotes(from, to, amount)\n_numCheckpoints(account)\n_checkpoints(account, pos)\nNonces\nnonces(owner)\n_useNonce(owner)\n_useCheckedNonce(owner, nonce)\nEIP712\n_domainSeparatorV4()\n_hashTypedDataV4(structHash)\neip712Domain()\n_EIP712Name()\n_EIP712Version()\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIVotes\nDelegateChanged(delegator, fromDelegate, toDelegate)\nDelegateVotesChanged(delegate, previousVotes, newVotes)\nIERC5267\nEIP712DomainChanged()\nIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC20ExceededSafeSupply(increasedSupply, cap)\nVotes\nERC6372InconsistentClock()\nERC5805FutureLookup(timepoint, clock)\nIVotes\nVotesExpiredSignature(expiry)\nNonces\nInvalidAccountNonce(account, currentNonce)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\n_maxSupply() → uint256internal#Maximum token supply. Defaults to type(uint208).max (2^208^ - 1).This maximum is enforced in ERC20._update. It limits the total supply of the token, which is otherwise a uint256,\nso that checkpoints can be stored in the Trace208 structure used by Votes. Increasing this value will not\nremove the underlying limitation, and will cause ERC20._update to fail because of a math overflow in\nVotes._transferVotingUnits. An override could be used to further restrict the total supply (to a lower value) if\nadditional logic requires it. When resolving override conflicts on this function, the minimum should be\nreturned.\n\n_update(address from, address to, uint256 value)internal#Move voting power when tokens are transferred.Emits a IVotes.DelegateVotesChanged event.\n\n_getVotingUnits(address account) → uint256internal#Returns the voting units of an account.Overriding this function may compromise the internal vote accounting.\nERC20Votes assumes tokens map to voting units 1:1 and this is not easy to change.\n\nnumCheckpoints(address account) → uint32public#Get number of checkpoints for account.\n\ncheckpoints(address account, uint32 pos) → struct Checkpoints.Checkpoint208public#Get the pos-th checkpoint for account.\n\nERC20ExceededSafeSupply(uint256 increasedSupply, uint256 cap)error#Total supply cap has been exceeded, introducing a risk of votes overflowing.\n\nERC20Wrapper\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Wrapper.sol\";\nExtension of the ERC-20 token contract to support token wrapping.\nUsers can deposit and withdraw \"underlying tokens\" and receive a matching number of \"wrapped tokens\". This is useful\nin conjunction with other modules. For example, combining this wrapping mechanism with ERC20Votes will allow the\nwrapping of an existing \"basic\" ERC-20 into a governance token.\nAny mechanism in which the underlying token changes the ERC20.balanceOf of an account without an explicit transfer\nmay desynchronize this contract's supply and its underlying balance. Please exercise caution when wrapping tokens that\nmay undercollateralize the wrapper (i.e. wrapper's total supply is higher than its underlying balance). See ERC20Wrapper._recover\nfor recovering value accrued to the wrapper.\nFunctions\nconstructor(underlyingToken)\ndecimals()\nunderlying()\ndepositFor(account, value)\nwithdrawTo(account, value)\n_recover(account)\nERC20\nname()\nsymbol()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC20InvalidUnderlying(token)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nconstructor(contract IERC20 underlyingToken)internal#\n\ndecimals() → uint8public#\n\nunderlying() → contract IERC20public#Returns the address of the underlying ERC-20 token that is being wrapped.\n\ndepositFor(address account, uint256 value) → boolpublic#Allow a user to deposit underlying tokens and mint the corresponding number of wrapped tokens.\n\nwithdrawTo(address account, uint256 value) → boolpublic#Allow a user to burn a number of wrapped tokens and withdraw the corresponding number of underlying tokens.\n\n_recover(address account) → uint256internal#Mint wrapped token to cover any underlyingTokens that would have been transferred by mistake or acquired from\nrebasing mechanisms. Internal function that can be exposed with access control if desired.\n\nERC20InvalidUnderlying(address token)error#The underlying token couldn't be wrapped.\n\nERC4626\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol\";\nImplementation of the ERC-4626 \"Tokenized Vault Standard\" as defined in\nERC-4626.\nThis extension allows the minting and burning of \"shares\" (represented using the ERC-20 inheritance) in exchange for\nunderlying \"assets\" through standardized ERC4626.deposit, ERC4626.mint, ERC4626.redeem and ERC20Burnable.burn workflows. This contract extends\nthe ERC-20 standard. Any additional extensions included along it would affect the \"shares\" token represented by this\ncontract and not the \"assets\" token which is an independent contract.\nIn empty (or nearly empty) ERC-4626 vaults, deposits are at high risk of being stolen through frontrunning\nwith a \"donation\" to the vault that inflates the price of a share. This is variously known as a donation or inflation\nattack and is essentially a problem of slippage. Vault deployers can protect against this attack by making an initial\ndeposit of a non-trivial amount of the asset, such that price manipulation becomes infeasible. Withdrawals may\nsimilarly be affected by slippage. Users can protect against this attack as well as unexpected slippage in general by\nverifying the amount received is as expected, using a wrapper that performs these checks such as\nERC4626Router.Since v4.9, this implementation introduces configurable virtual assets and shares to help developers mitigate that risk.\nThe _decimalsOffset() corresponds to an offset in the decimal representation between the underlying asset's decimals\nand the vault decimals. This offset also determines the rate of virtual shares to virtual assets in the vault, which\nitself determines the initial exchange rate. While not fully preventing the attack, analysis shows that the default\noffset (0) makes it non-profitable even if an attacker is able to capture value from multiple user deposits, as a result\nof the value being captured by the virtual shares (out of the attacker's donation) matching the attacker's expected gains.\nWith a larger offset, the attack becomes orders of magnitude more expensive than it is profitable. More details about the\nunderlying math can be found here.The drawback of this approach is that the virtual shares do capture (a very small) part of the value being accrued\nto the vault. Also, if the vault experiences losses, the users try to exit the vault, the virtual shares and assets\nwill cause the first user to exit to experience reduced losses in detriment to the last users that will experience\nbigger losses. Developers willing to revert back to the pre-v4.9 behavior just need to override the\n_convertToShares and _convertToAssets functions.To learn more, check out our ERC-4626 guide.\nWhen overriding this contract, some elements must be considered:\n\nWhen overriding the behavior of the deposit or withdraw mechanisms, it is recommended to override the internal\nfunctions. Overriding ERC4626._deposit automatically affects both ERC4626.deposit and ERC4626.mint. Similarly, overriding ERC4626._withdraw\nautomatically affects both ERC4626.withdraw and ERC4626.redeem. Overall it is not recommended to override the public facing\nfunctions since that could lead to inconsistent behaviors between the ERC4626.deposit and ERC4626.mint or between ERC4626.withdraw and\nERC4626.redeem, which is documented to have led to loss of funds.\n\nOverrides to the deposit or withdraw mechanism must be reflected in the preview functions as well.\n\nERC4626.maxWithdraw depends on ERC4626.maxRedeem. Therefore, overriding ERC4626.maxRedeem only is enough. On the other hand,\noverriding ERC4626.maxWithdraw only would have no effect on ERC4626.maxRedeem, and could create an inconsistency between the two\nfunctions.\n\nIf ERC4626.previewRedeem is overridden to revert, ERC4626.maxWithdraw must be overridden as necessary to ensure it\nalways return successfully.\n\nFunctions\nconstructor(asset_)\ndecimals()\nasset()\ntotalAssets()\nconvertToShares(assets)\nconvertToAssets(shares)\nmaxDeposit()\nmaxMint()\nmaxWithdraw(owner)\nmaxRedeem(owner)\npreviewDeposit(assets)\npreviewMint(shares)\npreviewWithdraw(assets)\npreviewRedeem(shares)\ndeposit(assets, receiver)\nmint(shares, receiver)\nwithdraw(assets, receiver, owner)\nredeem(shares, receiver, owner)\n_convertToShares(assets, rounding)\n_convertToAssets(shares, rounding)\n_deposit(caller, receiver, assets, shares)\n_withdraw(caller, receiver, owner, assets, shares)\n_transferIn(from, assets)\n_transferOut(to, assets)\n_decimalsOffset()\nERC20\nname()\nsymbol()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC4626\nDeposit(sender, owner, assets, shares)\nWithdraw(sender, receiver, owner, assets, shares)\nIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrors\nERC4626ExceededMaxDeposit(receiver, assets, max)\nERC4626ExceededMaxMint(receiver, shares, max)\nERC4626ExceededMaxWithdraw(owner, assets, max)\nERC4626ExceededMaxRedeem(owner, shares, max)\nIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nconstructor(contract IERC20 asset_)internal#Set the underlying asset contract. This must be an ERC20-compatible contract (ERC-20 or ERC-777).\n\ndecimals() → uint8public#Decimals are computed by adding the decimal offset on top of the underlying asset's decimals. This\n\"original\" value is cached during construction of the vault contract. If this read operation fails (e.g., the\nasset has not been created yet), a default of 18 is used to represent the underlying asset's decimals.See IERC20Metadata.decimals.\n\nasset() → addresspublic#Returns the address of the underlying token used for the Vault for accounting, depositing, and withdrawing.\nMUST be an ERC-20 token contract.\nMUST NOT revert.\n\ntotalAssets() → uint256public#Returns the total amount of the underlying asset that is “managed” by Vault.\nSHOULD include any compounding that occurs from yield.\nMUST be inclusive of any fees that are charged against assets in the Vault.\nMUST NOT revert.\n\nconvertToShares(uint256 assets) → uint256public#Returns the amount of shares that the Vault would exchange for the amount of assets provided, in an ideal\nscenario where all the conditions are met.\nMUST NOT be inclusive of any fees that are charged against assets in the Vault.\nMUST NOT show any variations depending on the caller.\nMUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.\nMUST NOT revert.\nThis calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the\n“average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and\nfrom.\n\nconvertToAssets(uint256 shares) → uint256public#Returns the amount of assets that the Vault would exchange for the amount of shares provided, in an ideal\nscenario where all the conditions are met.\nMUST NOT be inclusive of any fees that are charged against assets in the Vault.\nMUST NOT show any variations depending on the caller.\nMUST NOT reflect slippage or other on-chain conditions, when performing the actual exchange.\nMUST NOT revert.\nThis calculation MAY NOT reflect the “per-user” price-per-share, and instead should reflect the\n“average-user’s” price-per-share, meaning what the average user should expect to see when exchanging to and\nfrom.\n\nmaxDeposit(address) → uint256public#Returns the maximum amount of the underlying asset that can be deposited into the Vault for the receiver,\nthrough a deposit call.\nMUST return a limited value if receiver is subject to some deposit limit.\nMUST return 2 ** 256 - 1 if there is no limit on the maximum amount of assets that may be deposited.\nMUST NOT revert.\n\nmaxMint(address) → uint256public#Returns the maximum amount of the Vault shares that can be minted for the receiver, through a mint call.\nMUST return a limited value if receiver is subject to some mint limit.\nMUST return 2 ** 256 - 1 if there is no limit on the maximum amount of shares that may be minted.\nMUST NOT revert.\n\nmaxWithdraw(address owner) → uint256public#Returns the maximum amount of the underlying asset that can be withdrawn from the owner balance in the\nVault, through a withdraw call.\nMUST return a limited value if owner is subject to some withdrawal limit or timelock.\nMUST NOT revert.\n\nmaxRedeem(address owner) → uint256public#Returns the maximum amount of Vault shares that can be redeemed from the owner balance in the Vault,\nthrough a redeem call.\nMUST return a limited value if owner is subject to some withdrawal limit or timelock.\nMUST return balanceOf(owner) if owner is not subject to any withdrawal limit or timelock.\nMUST NOT revert.\n\npreviewDeposit(uint256 assets) → uint256public#Allows an on-chain or off-chain user to simulate the effects of their deposit at the current block, given\ncurrent on-chain conditions.\nMUST return as close to and no more than the exact amount of Vault shares that would be minted in a deposit\ncall in the same transaction. I.e. deposit should return the same or more shares as previewDeposit if called\nin the same transaction.\nMUST NOT account for deposit limits like those returned from maxDeposit and should always act as though the\ndeposit would be accepted, regardless if the user has enough tokens approved, etc.\nMUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.\nMUST NOT revert.\nany unfavorable discrepancy between convertToShares and previewDeposit SHOULD be considered slippage in\nshare price or some other type of condition, meaning the depositor will lose assets by depositing.\n\npreviewMint(uint256 shares) → uint256public#Allows an on-chain or off-chain user to simulate the effects of their mint at the current block, given\ncurrent on-chain conditions.\nMUST return as close to and no fewer than the exact amount of assets that would be deposited in a mint call\nin the same transaction. I.e. mint should return the same or fewer assets as previewMint if called in the\nsame transaction.\nMUST NOT account for mint limits like those returned from maxMint and should always act as though the mint\nwould be accepted, regardless if the user has enough tokens approved, etc.\nMUST be inclusive of deposit fees. Integrators should be aware of the existence of deposit fees.\nMUST NOT revert.\nany unfavorable discrepancy between convertToAssets and previewMint SHOULD be considered slippage in\nshare price or some other type of condition, meaning the depositor will lose assets by minting.\n\npreviewWithdraw(uint256 assets) → uint256public#Allows an on-chain or off-chain user to simulate the effects of their withdrawal at the current block,\ngiven current on-chain conditions.\nMUST return as close to and no fewer than the exact amount of Vault shares that would be burned in a withdraw\ncall in the same transaction. I.e. withdraw should return the same or fewer shares as previewWithdraw if\ncalled\nin the same transaction.\nMUST NOT account for withdrawal limits like those returned from maxWithdraw and should always act as though\nthe withdrawal would be accepted, regardless if the user has enough shares, etc.\nMUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.\nMUST NOT revert.\nany unfavorable discrepancy between convertToShares and previewWithdraw SHOULD be considered slippage in\nshare price or some other type of condition, meaning the depositor will lose assets by depositing.\n\npreviewRedeem(uint256 shares) → uint256public#Allows an on-chain or off-chain user to simulate the effects of their redemption at the current block,\ngiven current on-chain conditions.\nMUST return as close to and no more than the exact amount of assets that would be withdrawn in a redeem call\nin the same transaction. I.e. redeem should return the same or more assets as previewRedeem if called in the\nsame transaction.\nMUST NOT account for redemption limits like those returned from maxRedeem and should always act as though the\nredemption would be accepted, regardless if the user has enough shares, etc.\nMUST be inclusive of withdrawal fees. Integrators should be aware of the existence of withdrawal fees.\nMUST NOT revert.\nany unfavorable discrepancy between convertToAssets and previewRedeem SHOULD be considered slippage in\nshare price or some other type of condition, meaning the depositor will lose assets by redeeming.\n\ndeposit(uint256 assets, address receiver) → uint256public#Deposit assets underlying tokens and send the corresponding number of vault shares (shares) to receiver.\nMUST emit the Deposit event.\nMAY support an additional flow in which the underlying tokens are owned by the Vault contract before the\ndeposit execution, and are accounted for during deposit.\nMUST revert if all of assets cannot be deposited (due to deposit limit being reached, slippage, the user not\napproving enough underlying tokens to the Vault contract, etc).\nmost implementations will require pre-approval of the Vault with the Vault’s underlying asset token.\n\nmint(uint256 shares, address receiver) → uint256public#Mints exactly shares vault shares to receiver in exchange for assets underlying tokens.\nMUST emit the Deposit event.\nMAY support an additional flow in which the underlying tokens are owned by the Vault contract before the mint\nexecution, and are accounted for during mint.\nMUST revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not\napproving enough underlying tokens to the Vault contract, etc).\nmost implementations will require pre-approval of the Vault with the Vault’s underlying asset token.\n\nwithdraw(uint256 assets, address receiver, address owner) → uint256public#Burns shares from owner and sends exactly assets of underlying tokens to receiver.\nMUST emit the Withdraw event.\nMAY support an additional flow in which the underlying tokens are owned by the Vault contract before the\nwithdraw execution, and are accounted for during withdraw.\nMUST revert if all of assets cannot be withdrawn (due to withdrawal limit being reached, slippage, the owner\nnot having enough shares, etc).\nNote that some implementations will require pre-requesting to the Vault before a withdrawal may be performed.\nThose methods should be performed separately.\n\nredeem(uint256 shares, address receiver, address owner) → uint256public#Burns exactly shares from owner and sends assets of underlying tokens to receiver.\nMUST emit the Withdraw event.\nMAY support an additional flow in which the underlying tokens are owned by the Vault contract before the\nredeem execution, and are accounted for during redeem.\nMUST revert if all of shares cannot be redeemed (due to withdrawal limit being reached, slippage, the owner\nnot having enough shares, etc).\nsome implementations will require pre-requesting to the Vault before a withdrawal may be performed.\nThose methods should be performed separately.\n\n_convertToShares(uint256 assets, enum Math.Rounding rounding) → uint256internal#Internal conversion function (from assets to shares) with support for rounding direction.\n\n_convertToAssets(uint256 shares, enum Math.Rounding rounding) → uint256internal#Internal conversion function (from shares to assets) with support for rounding direction.\n\n_deposit(address caller, address receiver, uint256 assets, uint256 shares)internal#Deposit/mint common workflow.\n\n_withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares)internal#Withdraw/redeem common workflow.\n\n_transferIn(address from, uint256 assets)internal#Performs a transfer in of underlying assets. The default implementation uses SafeERC20. Used by ERC4626._deposit.\n\n_transferOut(address to, uint256 assets)internal#Performs a transfer out of underlying assets. The default implementation uses SafeERC20. Used by ERC4626._withdraw.\n\n_decimalsOffset() → uint8internal#\n\nERC4626ExceededMaxDeposit(address receiver, uint256 assets, uint256 max)error#Attempted to deposit more assets than the max amount for receiver.\n\nERC4626ExceededMaxMint(address receiver, uint256 shares, uint256 max)error#Attempted to mint more shares than the max amount for receiver.\n\nERC4626ExceededMaxWithdraw(address owner, uint256 assets, uint256 max)error#Attempted to withdraw more assets than the max amount for owner.\n\nERC4626ExceededMaxRedeem(address owner, uint256 shares, uint256 max)error#Attempted to redeem more shares than the max amount for owner.\n\nIERC20Metadata\nimport \"@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol\";\nInterface for the optional metadata functions from the ERC-20 standard.\nFunctions\nname()\nsymbol()\ndecimals()\nIERC20\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nname() → stringexternal#Returns the name of the token.\n\nsymbol() → stringexternal#Returns the symbol of the token.\n\ndecimals() → uint8external#Returns the decimals places of the token.\n\nIERC20Permit\nimport \"@openzeppelin/contracts/token/ERC20/extensions/IERC20Permit.sol\";\nInterface of the ERC-20 Permit extension allowing approvals to be made via signatures, as defined in\nERC-2612.\nAdds the ERC20Permit.permit method, which can be used to change an account's ERC-20 allowance (see IERC20.allowance) by\npresenting a message signed by the account. By not relying on IERC20.approve, the token holder account doesn't\nneed to send a transaction, and thus is not required to hold Ether at all.\nSecurity Considerations\nThere are two important considerations concerning the use of permit. The first is that a valid permit signature\nexpresses an allowance, and it should not be assumed to convey additional meaning. In particular, it should not be\nconsidered as an intention to spend the allowance in any specific way. The second is that because permits have\nbuilt-in replay protection and can be submitted by anyone, they can be frontrun. A protocol that uses permits should\ntake this into consideration and allow a permit call to fail. Combining these two aspects, a pattern that may be\ngenerally recommended is:\nfunction doThingWithPermit(..., uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) public {\n try token.permit(msg.sender, address(this), value, deadline, v, r, s) {} catch {}\n doThing(..., value);\n}\n\nfunction doThing(..., uint256 value) public {\n token.safeTransferFrom(msg.sender, address(this), value);\n ...\n}\nObserve that: 1) msg.sender is used as the owner, leaving no ambiguity as to the signer intent, and 2) the use of\ntry/catch allows the permit to fail and makes the code tolerant to frontrunning. (See also\nSafeERC20.safeTransferFrom).\nAdditionally, note that smart contract wallets (such as Argent or Safe) are not able to produce permit signatures, so\ncontracts should have entry points that don't rely on permit.\nFunctions\npermit(owner, spender, value, deadline, v, r, s)\nnonces(owner)\nDOMAIN_SEPARATOR()\n\npermit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)external#Sets value as the allowance of spender over owner's tokens,\ngiven owner's signed approval.The same issues IERC20.approve has related to transaction\nordering also applies here.Emits an IERC20.Approval event.Requirements:\nspender cannot be the zero address.\ndeadline must be a timestamp in the future.\nv, r and s must be a valid secp256k1 signature from owner\nover the EIP712-formatted function arguments.\nthe signature must use owner's current nonce (see ERC20Permit.nonces).\nFor more information on the signature format, see the\nrelevant EIP\nsection.See Security Considerations above.\n\nnonces(address owner) → uint256external#Returns the current nonce for owner. This value must be\nincluded whenever a signature is generated for ERC20Permit.permit.Every successful call to ERC20Permit.permit increases owner's nonce by one. This\nprevents a signature from being used multiple times.\n\nDOMAIN_SEPARATOR() → bytes32external#Returns the domain separator used in the encoding of the signature for ERC20Permit.permit, as defined by EIP712.\n\nERC20Bridgeable\nimport \"@openzeppelin/contracts/token/ERC20/extensions/draft-ERC20Bridgeable.sol\";\nERC20 extension that implements the standard token interface according to\nERC-7802.\nModifiers\nonlyTokenBridge()\n\nFunctions\nsupportsInterface(interfaceId)\ncrosschainMint(to, value)\ncrosschainBurn(from, value)\n_checkTokenBridge(caller)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\nallowance(owner, spender)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n_spendAllowance(owner, spender, value)\n\nEventsIERC7802\nCrosschainMint(to, amount, sender)\nCrosschainBurn(from, amount, sender)\nIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrorsIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nonlyTokenBridge()internal#Modifier to restrict access to the token bridge.\n\nsupportsInterface(bytes4 interfaceId) → boolpublic#Returns true if this contract implements the interface defined by\ninterfaceId. See the corresponding\nERC section\nto learn more about how these ids are created.This function call must use less than 30 000 gas.\n\ncrosschainMint(address to, uint256 value)public#See IERC7802.crosschainMint. Emits a IERC7802.CrosschainMint event.\n\ncrosschainBurn(address from, uint256 value)public#See IERC7802.crosschainBurn. Emits a IERC7802.CrosschainBurn event.\n\n_checkTokenBridge(address caller)internal#Checks if the caller is a trusted token bridge. MUST revert otherwise.Developers should implement this function using an access control mechanism that allows\ncustomizing the list of allowed senders. Consider using AccessControl or AccessManaged.\n\nERC20TemporaryApproval\nimport \"@openzeppelin/contracts/token/ERC20/extensions/draft-ERC20TemporaryApproval.sol\";\nExtension of ERC20 that adds support for temporary allowances following ERC-7674.\nThis is a draft contract. The corresponding ERC is still subject to changes.\nAvailable since v5.1.\nFunctions\nallowance(owner, spender)\n_temporaryAllowance(owner, spender)\ntemporaryApprove(spender, value)\n_temporaryApprove(owner, spender, value)\n_spendAllowance(owner, spender, value)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, value)\napprove(spender, value)\ntransferFrom(from, to, value)\n_transfer(from, to, value)\n_update(from, to, value)\n_mint(account, value)\n_burn(account, value)\n_approve(owner, spender, value)\n_approve(owner, spender, value, emitEvent)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nErrorsIERC20Errors\nERC20InsufficientBalance(sender, balance, needed)\nERC20InvalidSender(sender)\nERC20InvalidReceiver(receiver)\nERC20InsufficientAllowance(spender, allowance, needed)\nERC20InvalidApprover(approver)\nERC20InvalidSpender(spender)\n\nallowance(address owner, address spender) → uint256public#ERC20.allowance override that includes the temporary allowance when looking up the current allowance. If\nadding up the persistent and the temporary allowances result in an overflow, type(uint256).max is returned.\n\n_temporaryAllowance(address owner, address spender) → uint256internal#Internal getter for the current temporary allowance that spender has over owner tokens.\n\ntemporaryApprove(address spender, uint256 value) → boolpublic#Alternative to ERC20.approve that sets a value amount of tokens as the temporary allowance of spender over\nth","tokens":15000,"squid":"ink-security_audits","role":"Sentinel","at":1791267202188,"hash":"39e135e4848b6ab0bcd89b82a21dee4e72d1a8f5"}
{"url":"https://aave.com/docs/ecosystem/oracle","domain":"aave.com","title":"Oracle | Aave Protocol Documentation","text":"Oracle#\n\nEach reserve within the Aave Protocol is associated with an oracle contract. These oracle contracts are responsible for reporting the market price of assets in the protocol, which is essential for determining collateralisation requirements.\nThe oracle for each reserve is selected through Aave Governance, establishing a decentralised model where the community decides which data sources are used. Once chosen, the oracle contract submits price feed updates based on its operational logic (time-based, deviation-based, etc.).\nTypes of Oracles in Use#\nCurrently, there are two primary types of oracle contracts utilised on production Aave markets:\nChainlink Price Feeds: Chainlink oracles provide highly reliable, decentralised price data for various assets. These price feeds pull data from multiple sources and aggregate them, minimising the risk of manipulation or outages.Correlated Assets Price Oracle (CAPO): CAPO is designed for assets that have a strong correlation with another asset's price. For example, wrapped tokens can use this oracle to mirror the price of their underlying assets. CAPO leverages specialised logic to adjust and submit prices that follow the movements of these correlated assets. See more details about its implementation on GitHub.PreviousGovernanceNextSecurity & Audits","tokens":328,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267203039,"hash":"e376995e178a62bada636ff32be2313b2b88e1e7"}
{"url":"https://aave.com/faq","domain":"aave.com","title":"FAQs | Aave","text":"GeneralAave is a decentralised non-custodial liquidity protocol where users can participate as suppliers or borrowers. Suppliers provide liquidity to the market while earning interest, and borrowers can access liquidity by providing collateral that exceeds the borrowed amount.Aave is a decentralised, non-custodial liquidity protocol that is completely permissionless, meaning anyone can access it. Users can interact with Aave through a user-friendly interface or directly with its smart contracts on supported blockchain networks. This openness also enables the creation of third-party services or applications that integrate with the protocol.To interact with the Aave Protocol, simply connect your crypto wallet and supply your preferred asset and amount. Once supplied, you'll earn passive income based on market borrowing demand. Additionally, your supplied assets can be used as collateral, enabling you to borrow other assets.Yes, you need a wallet to interact with Aave. Each instance of the Aave Protocol is deployed to a blockchain network. To interact with Aave, you need a wallet on the corresponding network such as a hardware wallet, browser extension, mobile wallet, multi-signature wallets, among others.When interacting with an Aave Protocol interface, wallets are connected using methods such as mobile wallets (Aave Wallet), browser wallets (MetaMask, Rabby, etc.), WalletConnect, and more. These connection methods are utilized to prompt for messages and transactions to be signed in the connected wallet.Interacting with the Aave Protocol requires transactions on Ethereum or other blockchain networks where Aave is deployed. These transactions may incur gas fees, which are non-refundable network transaction fees determined by the network status and transaction complexity.Transaction costs are typically highest on Ethereum, and significantly cheaper on all other networks, which can be compared here. The connected wallet will ask you to confirm the gas fee when signing a transaction.There are multiple interfaces available to access the Aave Protocol. Below are just a few examples:V3 Interface or Aave Pro (V4)All functionalities + leverage and auto liquidation (repayment with collateral) through DeFi Saver.Flash Loans, supply and withdrawal from Furucombo interface.Supply and withdraw from Argent wallet.Manage positions via smart account with Brahma Console.Asset management with Fireblocks.All actions are available directly through protocol smart contracts, which can be accessed through block explorers or code by following the guidelines available in the docs.Be careful. Aave never advertises on any social media platform or search engine and does not have any downloadable mobile application available. If you find one, it is a scam. Aave Protocol will never ask for your wallet seed phrase.You can use Aave in a simulation environment designed for testing and development. In this environment, the assets are not real and have no economic value.Go to the V3 Interface or Aave Pro (V4), select the settings button on the top right corner, enable testnet view.Switch to the testnet you wish to utilize over your wallet provider.Make sure to have the native asset for the specific network.Get some tokens from the test client faucet.No central entity, including Aave Labs or any individual contributor, has the authority or ability to freeze or alter individual user positions within the Aave ecosystem. The Aave Protocol is fully decentralized and governed by the Aave Decentralized Autonomous Organization (DAO), which is controlled by AAVE token holders. As such, users maintain complete self-custody of their funds, and there is no mechanism for freezing or modifying individual positions by any entity.Risk Management Controls: While individual positions are untouchable, the protocol includes specific risk management functions designed to safeguard the overall system. These functions are strictly limited to broader protocol actions and do not extend to individual user positions:1. PoolAdmin Role: In Aave V2, the PoolAdmin can only pause all interactions within the entire pool of assets.2. EmergencyAdmin Role: In Aave V3, the EmergencyAdmin role — currently held by the Aave Guardian — can pause specific reserves for purposes of risk management. However, even this action is limited to the reserve level and does not allow for freezing or altering individual positions. These roles are designed to protect the integrity of the protocol as a whole and do not have the capability to interfere with or directly manage individual user funds. For detailed information on these roles and their specific limitations, please refer to the Aave Permissions Book and the governance forum.Approving tokens is a necessary step when performing actions that involve transferring tokens to a smart contract, such as supplying and repaying tokens to the Aave Protocol. If a token approval is required, frontends such as the V3 Interface or Aave Pro (V4) will prompt users to perform the approval with one of the following methods:Transaction: a transaction is an onchain action that requires gas fees and time to confirm. You will be prompted to approve/pay for the gas fee to facilitate the transaction.Signature: when a signature approval is required to transfer tokens, you will be prompted to sign a message with the same wallet making the transaction. Message signing is free and instant, however, it is only available for certain tokens ( EIP-2612 compatible), and wallet types (private key wallets).RiskNo protocol can be considered entirely risk free, but extensive steps have been taken to minimize these risks as much as possible – the Aave Protocol code is publicly available and auditable by anyone, and has been audited by multiple smart contract auditors. Any code changes must be executed through the onchain governance processes. Additionally, there is an ongoing bug bounty campaign and service providers specializing in technical reviews and risk mitigation. It is recommended to use or migrate to the latest version of the protocol (Aave V3) due to the introduction of granular risk parameters such as supply caps, borrow caps, and isolated collateral assets.Different risk categories are explained in detail below. You can find additional risk and security related information in the risk framework and security and audits sections.Smart Contract RiskSmart contract risk involves the potential for bugs or vulnerabilities within the Aave Protocol code or the underlying reserve tokens.Oracle RiskOracle risk arises from the reliance on third-party data providers for price feeds and other external data such as redemption ratio for liquid staking tokens. If an oracle fails or is compromised, it could lead to incorrect valuations of assets.Collateral RiskCollateral risk pertains to the value and stability of assets used as collateral. The inability to liquidate collateral due to rapid decrease in value or insufficient external liquidity can result in bad debt.Network / Bridge RiskNetwork or bridge risk involves the potential issues related to the underlying blockchain networks and bridges upon which the Aave Protocol operates. These risks include congestion, censorship, or security vulnerabilities.Smart Contract RiskTo mitigate smart contract risks, the Aave Protocol code is publicly available and has been audited by multiple smart contract auditors. Aave employs onchain governance, which validates that any changes to the protocol are thoroughly vetted and approved by the community. Additionally, service providers contribute their expertise to identify and mitigate potential risks. The protocol also runs an ongoing bug bounty program that encourages external developers to find and report vulnerabilities.Oracle RiskAave mitigates oracle risks by using decentralised oracles such as Chainlink to provide reliable and tamper-resistant price and redemption ratio feeds.Collateral RiskTo address collateral risks, the Aave DAO engages risk service providers who continuously monitor the collateral assets and market conditions to provide insights and adjustments. The protocol sets risk parameters such as loan-to-value (LTV) and liquidation thresholds to promote the maintenance of overcollateralized borrow positions. Onchain governance allows the community to adjust these risk parameters as needed to respond to changing market conditions, further safeguarding the protocol.Network / Bridge RiskAave Governance has adopted a robust network onboarding framework to thoroughly vet new networks and bridges before integration. Onchain governance oversees decisions related to network and bridge integrations, ensuring community participation and scrutiny. This comprehensive approach helps to mitigate network and bridge risks, enhancing the security and reliability of the Aave Protocol.Supplying & EarningBrowse to the \"Supply\" section and click on \"Supply\" for the asset you want to supply. Select the amount you'd like to supply and submit your transaction. Once the transaction is confirmed, your supply is successfully registered and you begin earning interest.Transferring tokens on an Ethereum based network requires a token approval from your self-custodial wallet. This must be performed with a transaction or signed message prior to the supply.Suppliers receive continuous earnings that evolve with market conditions based on:The interest rate payment on borrow positions: Suppliers share the interests paid by borrowers corresponding to the average borrow rate times the utilization rate. The higher the utilization of a reserve, the higher the yield for suppliers.Flash Loan fees: Suppliers receive a share of the Flash Loan fees corresponding to 0.09% of the Flash Loan volume.You can find the current supply rate for each token in the Markets tab of the V3 Interface or Aave Pro (V4). Historic rates can be viewed by clicking on individual tokens to view their corresponding reserve details page.There is no minimum amount to supply.However, assets on Aave V3 & V4 markets may have a supply cap parameter which limits the total amount that can be supplied of a particular asset.Supplied tokens are stored in publicly accessible smart contracts that enable overcollateralised borrowing according to governance-approved parameters. The Aave Protocol smart contracts have been audited and formally verified by third parties.Withdrawing from the Aave Protocol occurs on the Pool smart contract. Withdrawal transactions can be performed through the V3 Interface or Aave Pro (V4) by navigating to the \"Dashboard\" section and clicking \"Withdraw.\" Select the amount to withdraw and submit the transaction.You need to make sure there is enough liquidity (not borrowed) in order to withdraw, if this is not the case, you need to wait for more liquidity from suppliers or borrowers repaying.Additionally, the V3 Interface or Aave Pro (V4) has a \"Withdraw & Swap\" feature to enable withdrawing into other tokens.Yes. After supplying your assets, you are able to unselect the asset so that it will not be used as collateral. The opt-out is available in the \"Supply\" section within your dashboard. Simply switch the \"use as collateral\" button on the asset you would prefer to opt-out from being used as a collateral.You can withdraw your assets without opting out of using them as collateral, as long as those funds are not actively being used to borrow and provided the withdrawal amount would not cause a liquidation on your borrow positions.BorrowingBefore borrowing you need to supply approved asset to be used as collateral (check out the Supplying & Earning FAQ section for more info). After this, you can execute a borrow from the Aave smart contracts or a user interface. On the V3 Interface or Aave Pro (V4), head to the Borrow section and click on \"Borrow\" for the asset you want to borrow. Adjust the amount you need based on the available collateral balance, and confirm the transaction in your wallet.The maximum amount you can borrow depends on the value you have supplied, the available liquidity, and the asset borrow cap. For example, you can't borrow an asset if there is not enough liquidity or if your health factor doesn't allow you to. You can find all collateral available and their specific borrow parameters in the risk parameters dashboard.Selling your assets means closing your position on that particular asset. Hence, if you are long on the asset, you would not be entitled to the potential upside value gain. By borrowing you are able to obtain liquidity (working capital) without selling your assets. Users are mainly borrowing for unexpected expenses, leveraging their holdings or for new investment opportunities.Borrow positions can be repaid through Aave smart contracts or a user interface. On the V3 Interface or Aave Pro (V4), go to the Borrowings section of your dashboard and click on the \"Repay\" button for the asset you borrowed and want to repay. Select the amount to repay and confirm the transaction.You repay your borrow position in the same asset you borrowed. For example, if you borrow 1 GHO you will pay back 1 GHO + interest accrued. The V3 Interface or Aave Pro (V4) also integrates a repay with collateral feature, which uses flashloans and DEX integrations to allow borrow positions to be repaid with aTokens. Availability of repay with collateral feature on Aave markets can be found here.The interest rate you pay for borrowing assets depends on the supply and demand ratio of the asset and interest rate curve parameters determined by Aave Governance.You can find the current borrow rate for each borrowable token in the Markets tab of the V3 Interface or Aave Pro (V4). Historic rates can be viewed by clicking on individual tokens to view their corresponding reserve details page.There is no fixed time period to pay back the borrow position. As long as your position is properly collateralised, you can borrow for an undefined period. However, as time passes, the accrued interest will grow making your health factor decrease, which might result in your supplied assets becoming more likely to be liquidated.LiquidationsHealth factor is the numeric representation of the safety of a borrow position, calculated as:Total Collateral Value * Weighted Average Liquidation Threshold / Total Borrow ValueLiquidation Threshold is a parameter determined by Aave Governance for each collateral asset, which is the maximum percentage of value that can be borrowed against a collateral asset. A health factor below 1 represents a borrow position that is eligible for liquidation.For example, if you supply $10,000 in ETH with an 80% threshold and borrow $6,000 in USDC, your health factor = 10000 * 0.8 / 6000 = 1.333.Depending on the value fluctuation of your supplies, the health factor will increase or decrease. If your health factor increases, it will improve your borrow position by making the liquidation threshold more unlikely to be reached. In the case that the value of your collateralised assets against the borrowed assets decreases, your health factor is also reduced, resulting in increased liquidation risk.A liquidation is a process that occurs when a borrower's health factor goes below 1 because their collateral value does not properly cover their borrow value. This can happen when the collateral value decreases and /or when the borrow position value increases beyond the liquidation threshold of the collateral assets.The amount that can be liquidated depends on the health factor and position size:Up to 50% of total debt can be liquidated when health factor is above 0.95 AND both collateral and debt values are at least $2,000 each.Up to 100% of debt can be liquidated when health factor is 0.95 or below, OR when either collateral or debt value is below $2,000.The liquidator receives the repaid debt value plus a liquidation bonus from the borrower's collateral. To prevent dust accumulation, partial liquidations must leave at least $1,000 worth of both collateral and debt remaining.Liquidations are a permissionless feature of the Aave Protocol. If a borrow position has insufficient collateral to cover the liquidation threshold, then any address on the network is able to initiate a liquidation transaction.The liquidation penalty (or bonus for liquidators) depends on the asset used as collateral. You can find every asset's liquidation fee in the risk parameters dashboard.Example 1Bob supplies 10 ETH and borrows 5 ETH worth of GHO. If Bob's Health Factor drops below 1 his borrow position will be eligible for liquidation. A liquidator can repay up to 50% of a single borrowed amount = 2.5 ETH worth of GHO. In return, the liquidator can claim a single collateral which is ETH (5% bonus).The liquidator claims 2.5 + 0.125 ETH for repaying 2.5 ETH worth of GHO.Example 2Bob supplies 5 ETH and 4 ETH worth of YFI, and borrows 5 ETH worth of GHO. If Bob's Health Factor drops below 1 his borrow position will be eligible for liquidation. A liquidator can repay up to 50% of a single borrowed amount = 2.5 ETH worth of GHO. In return, the liquidator can claim a single collateral, as the liquidation bonus is higher for YFI (15%) than ETH (5%) the liquidator chooses to claim YFI.The liquidator claims 2.5 + 0.375 ETH worth of YFI for repaying 2.5 ETH worth of GHO.Health Factor represents the ratio of collateral to borrow value. There is not an exact answer as to what constitutes a \"safe\" health factor as it depends on the volatility and correlation of collateral and borrow asset prices.Each collateral and borrow asset has a corresponding oracle that reports the price of the token with respect to a base currency (typically USD). In general, if the collateral and borrow assets are highly correlated with respect to the base currency (such as supplying and borrowing only stablecoins or ETH-correlated assets), a lower health factor can be considered safe compared to a position where assets are not correlated.Simulation tools can be used to estimate the effects of price movements and accrued interest on health factor.The liquidation price of an account is a point at which the balances and oracle prices of the collateral and borrow positions results in a health factor < 1.0. Health factor depends on the balances and oracle prices of all collateral and borrow tokens, so liquidation price is not a single point, it is a curve of combinations.Simulation tools can be used to estimate the effects of price movements and accrued interest on health factor, and estimate the most likely combinations that can result in liquidation.To avoid liquidation you can raise your health factor by supplying more collateral assets or repaying part of your borrow position. By default, repayments increase your health factor more than supplies. Also, it's important to monitor your health factor and keep it high to avoid a liquidation. Keeping your health factor over 2, for example, gives you more of a margin to avoid a liquidation.Tools that can help you with this:You can simulate Health Factor movements using DeFi Simulator.You can auto liquidate your borrow position using DeFi Saver.You should be mindful of stablecoin price fluctuations due to market conditions and how it might affect your Health Factor. For example, the market price of USDC 1.00 might not equal exactly USD 1.00, but USD 0.95, for example. The price fluctuations of stablecoins, like any assets, affects your Health Factor.GovernanceThe Aave Protocol is governed by the AAVE token holder community through procedures, voting, and smart contract execution, collectively known as Aave Governance.All instances of the Aave Protocol are governed by the AAVE, stkAAVE, and aAAVE token holders on Ethereum mainnet.The Governance Process guide details the proposal lifecycle from idea to execution, which includes phases for discussion → temp check voting → onchain voting and execution.In order to vote you need to have AAVE, stkAAVE (Staked AAVE), or aAAVE (AAVE supplied to Ethereum V3 market) tokens on Ethereum mainnet. Voting power is the sum of token balances and incoming delegations.Voting occurs through Aave Governance smart contracts. There are multiple interfaces that can be used to access voting such as the Aave Labs, BGD Labs, and Tally governance interfaces.The threshold is dynamic and can change based on the quorum + differential of votes for/against an AIP.If there are very few votes against an AIP, the threshold will remain the same. However, if the votes against the AIP are more substantial, then the threshold can be moved up so there must be more votes in favor for the AIP to pass. This is to validate that an AIP has overwhelming approval before it is implemented.For example:If the quorum is 20%, the differential is 15% and 2% of the total votes are against the AIP, the threshold would remain at 20% (because 15+2 = 17 is less than 20).If the quorum is 20%, the differential is 15% and 6% of the total votes are against the AIP, then the threshold would be raised to 21% (because 15+6=21), so more \"yae\" votes would be required for the AIP to pass.The Aave Treasury is a smart contract instance on each network where the protocol is deployed, controlled by Aave Governance.Each borrowable reserve in an Aave market has a parameter called reserve factor, which is the percentage of borrow interest accumulated to the treasury and is determined on a per-asset basis by Aave Governance.Participation in Aave Governance is optional. Users can access the Aave Protocol without participating in governance.UmbrellaThe Aave Safety Module has been upgraded to Umbrella, a more efficient system for protocol protection. Users can now stake Aave aTokens (like aUSDC, aUSDT, aWETH) or GHO to contribute to protocol security while earning rewards. The legacy Safety Module still supports staking AAVE (stkAAVE), GHO (stkGHO), or AAVE/wstETH liquidity pool tokens (stkABPT). This helps to maintain the stability and security of the Aave ecosystem.Umbrella is designed to do relatively frequent slashings, but in very low order of magnitude, with rewards plus supply APY of aToken almost always being way higher than the loss from slashing. It's a fair and rational system: you earn rewards as a staker, but you also accept the associated risk.Staking consists of supplying supported tokens within the protocol Safety Module. The purpose of staking is to act as a mitigation tool in case of a shortfall event. As an incentive for this, Safety Module stakers will receive Safety Incentives.In Umbrella, staking aTokens provides better coverage for potential deficits since they can be directly burned in case of a shortfall event.Umbrella System:Slashing is automated and based on actual deficit levels.Each staked asset covers deficits only for its corresponding borrowed asset on the same network (e.g., staking aUSDC on Ethereum only covers USDC deficits on Ethereum). More efficient as it uses the same asset type for coverage.Deficit offsets prevent unnecessary slashing - the DAO covers first-loss up to a configured amount.The protocol design allows for slashing up to the full staked amount in extreme scenarios, though deficit offsets significantly reduce slashing probability for typical scenarios.Umbrella contracts have been audited, but smart contract risks remain as with any DeFi protocol.Legacy Safety Module:stkAAVE and stkABPT: Maximum slashing risk is up to 20% of the staked assetsstkGHO: Maximum slashing risk is up to 0% of the staked assets (slashing disabled)In protocols like Aave, deficits on highly borrowed assets are expected to happen, but in very low order of magnitude. For example, during the month Aave v3.3 has been enabled in production, approximately $400 deficit accrued across all Aave v3 pools compared to close to $9.5 billion outstanding borrows - that's approximately 0.000004% of outstanding borrowings in a month.Historically, the Safety Module has never been slashed. The DAO also configures deficit offsets to prevent slashing until a meaningful deficit threshold is reached, ensuring stakers are protected from small, routine deficits.Umbrella System:Earn both the underlying Aave yield (e.g., ~4% on aUSDT) plus additional Umbrella rewardsDynamic rewards system that supports multiple reward tokens per staked asset (up to 8 different reward tokens)Optimizes for target liquidity levelsProvides higher rewards when total staked assets are below targetSlightly reduces rewards when above targetAutomatically adjusts reward rates based on staking levelsLegacy Safety Module:stkAAVE: 315 AAVE/daystkABPT: 216 AAVE/daystkGHO: 0 AAVE/day (rewards disabled)Current emission rates can be viewed as an annual percentage on the Aave Labs Interface.Yes, you keep accruing the underlying Aave yield while staking, as the aToken itself is staked. For example, if aUSDC is yielding 6% on Aave and staking rewards are 4%, you will receive a total of 6% + 4% = 10%.The system wraps your rebasing aTokens before staking them, so your balance won't grow, but the value will increase over time. When using the Umbrella UI, the wrapping/unwrapping happens transparently in one transaction.The deficit offset is a protection mechanism where the DAO covers first-loss up to a configured amount before any staker funds are slashed. For example, if staked USDT has an offset of 100,000 USDT, more than 100,000 USDT of bad debt must accrue on the Aave pool before any staked USDT gets slashed.Basically, the DAO steps up to cover losses up to that amount first, providing an additional layer of protection for stakers.Staking can be performed through the Aave Labs Interface Staking section. Select 'stake', input the amount to stake and click on 'stake'. Then proceed to send 2 transactions:Approve: This is a required transaction prior to the staking that allows the staking contract to move your tokens. This transaction won't be required if you perform additional staking actions unless you revoke the approval.Stake: This transaction performs the action to stake your tokens. When confirmed, your tokens will be staked in the Safety Module.Note: If you only have ETH instead of WETH, the UI will automatically wrap your ETH into WETH before staking. Similarly, the interface recognizes any type of underlying token (USDT, aUSDT, or wrapped aUSDT) and handles conversions transparently.Umbrella System:20-day cooldown period before unstaking2-day window to withdraw after cooldownCooldown period starts when you request to unstakeLegacy Safety Module:stkAAVE and stkABPT: 20-day cooldown periodstkGHO: No cooldown period (removed)You can stake more tokens in the Safety Module or receive staked tokens, but that would increase your cooldown period based on the amount received. Even if the amount received is big enough, it will reset your cooldown period requiring you to activate it again before you can unstake.Once staking, you accrue Umbrella rewards continuously and can claim them at any time on the staking section by clicking \"Claim\". The reward tokens will be in your connected wallet as soon as the transaction is confirmed.The system is fully on-chain, so you can claim your rewards whenever you want by doing a blockchain transaction.If you're staking AAVE or ABPT (stkAAVE, stkABPT):No action is required initially. The slashing percentage is reduced from 30% to 20%, and rewards are slightly reduced, but the system remains fully functional.If you're staking GHO (stkGHO):You have two options:Stay on legacy stkGHO: No slashing risk, 20-day cooldown, but lower rewardsMigrate to Umbrella stkGHO: Higher rewards, but slashing risk and 20-day cooldownTo migrate: Cooldown on legacy stkGHO → Unstake your GHO → Stake your GHO on UmbrellaYes, the plan is to expand Umbrella to other Aave pools and networks in the very short future. Not all assets require staking (only those that accrue deficits), but expansion will allow users with different assets or those using Aave on other networks to participate.Expansion is subject to Aave governance approval and will be implemented based on the specific needs of each pool and network.GHO StablecoinGHO is a decentralised, overcollateralised stablecoin that is fully backed, transparent, and native to the Aave Protocol.The GHO Documentation is a comprehensive resource that explains the core mechanics of how the GHO stablecoin operates.Borrowers and suppliers can mint GHO using assets they have supplied into V3 as collateral on Ethereum markets, while continuing to earn interests on their underlying assets.The GHO pool functions differently from existing assets, but borrowing it will work similarly as other available assets on the different markets in the protocol.Supply CollateralBorrow GHORepay GHO and Accrued Interest (real-time)Repaid interest will be redirected to the DAO, rather than an asset supplier, contributing to the DAO treasury.Assets that are available in the Aave Protocol can be used to back GHO. Initially, the Ethereum V3 pool will be the first facilitator to launch because of V3's extensive risk-mitigation features, including e-mode, isolation mode, and supply caps.The Aave DAO manages the supply of GHO, the interest rates and determine risk parameters.With 100% of repaid interest being redirected to the DAO, rather than the asset suppliers, these repaid interest contribute to the DAO treasury.Unlike many stablecoins, the oracle price for GHO is fixed. Decentralised stablecoins such as GHO are transparent and cannot be changed. Interest rates are defined by Aave DAO and repaid interest is redirected to the DAO instead of the asset suppliers.GHO has a Flashmint Facilitator, that functions similarly to flashloan functionality of all other Aave Protocol reserves, and can be used to borrow GHO tokens for use cases requiring liquidity that is borrowed and returned within a single block.Aave Governance has the ability to approve GHO facilitators that allow liquidity to be bridged to other networks. A facilitator utilizing Chainlink CCIP has been approved which enables tokens to be bridged to the Arbitrum network.Bridging can be performed on the V3 Interface or Aave Pro (V4) by using the \"Bridge GHO\" feature in the top navigation bar.sGHO is the onchain savings layer for GHO. You deposit GHO and receive sGHO in a single transaction, giving you access to a live savings rate that is set by Aave Governance and paid in GHO.Rewards accrue automatically within the sGHO vault, so there is nothing to claim or restake — your balance simply grows over time. There is no lockup, no minimum, and no cooldown, so you can redeem sGHO back into GHO whenever you want.You can learn more on the GHO page or start saving with sGHO.DevelopersAave is a collection of smart contracts deployed to Ethereum and other blockchain networks. Aave functionality can be integrated into an application by interacting with the protocol smart contracts.Aave contract documentation contains references for available functions, and the Aave Utilities JavaScript SDK is an example of a commonly used library to integrate into frontend applications.Aave data can be queried directly through view functions. The Aave Docs contain details on available functions, and all protocol addresses can be viewed and integrated through the Aave Address Book.Historical data for protocol data such as parameters, rates, balances can be queried through contract events or indexed data sources. A breakdown of all core protocol events can be found here. The Aave Protocol subgraphs are an example of an indexed data source that maps Aave contract events to a GraphQL endpoint.Other FeaturesFlash loans are a feature designed for developers, due to the technical knowledge required to execute one. Flash Loans allow you to borrow any available amount of assets without putting up any collateral, as long as the liquidity is returned to the protocol within one block transaction. To do a Flash Loan, you will need to build a contract that requests a Flash Loan. The contract will then need to execute the instructed steps and pay back the Flash Loan + fee (0.07% in Aave V2, 0.05% in Aave V3) all within the same transaction.If you would like to develop a Flash Loan smart contract, check out the developer documentation.Aave community developers are also available in the official Discord channel to help with the process.Yes, there are tools allowing users to utilize Flash Loans to access liquidity in the background for advanced features such as repay with collateral, collateral swap, and more.Example interfaces that integrate Flash Loans are the V3 Interface or Aave Pro (V4), DeFi Saver, Instadapp, and Furucombo.Availability of flashloan features on Aave markets can be found here.The V3 Interface or Aave Pro (V4) has multiple features that integrate asset swaps.The \"Repay with Collateral\", \"Collateral Swap\", \"Borrow Swap\", and \"Withdraw and Swap\" features utilize flashloan adapter contracts and ParaSwap as the swap provider.The \"Swap Tokens\" feature enables users to swap between tokens using ParaSwap or CoW Swap as the swap provider, depending on network availability. Tokens traded using CoW Swap will incur a fee depending on token pair. A discounted fee of 15bps is applied to swaps between correlated assets (e.g. ETH/wstETH), for all other swaps a fee of 25bps is applied — the list of correlated assets is reviewed and updated periodically:Stablecoin asset group: USDC, USDT, DAI, GHO, EURC, USDbC, USDe, USDS, sUSDe, RLUSD, PYUSD, LUSD, sDAI, crvUSD, USD₮0, USDC.e, EURe, xDAI, wxDAIETH correlated asset group: weETH, ETH, WETH, wstETH, cbETH, ezETH, wrsETH, osETH, rETH, ETHxBTC correlated asset group: cbBTC, WBTC, LBTC, tBTC, eBTCIsolation mode allows Aave Governance to list new assets as isolated assets, which have a specific debt ceiling. Only certain assets can be borrowed in isolation mode—specifically, approved stablecoins. In order for an asset to become approved for borrowing, assets are voted on through Aave Governance process.The debt ceiling for an isolated asset is represented as the maximum amount in USD that can be borrowed against the user's collateral with two decimals of precision.Entering isolation mode is specific to certain isolated assets that are voted on and approved by Aave Governance. You cannot utilize non-isolated assets as collateral to enter isolation mode.The E-mode (efficiency mode) feature maximizes capital efficiency when collateral and borrowed assets have correlated prices. For example, DAI, USDC, USDT are all stablecoins pegged to USD. These stablecoins are all within the same E-mode category. Accordingly, a user supplying DAI in E-mode will have higher collateralisation power when borrowing assets like USDC or USDT.Only assets of the same category (for example stablecoins) can be borrowed in E-mode. E-mode does not restrict the usage of other assets as collateral. Assets outside of the E-mode category can still be supplied as collateral with normal LTV and liquidation parameters.Supply and borrow positions can be migrated between Aave V2 and V3 by using the migration tool, or by manually withdrawing from an Aave V2 markets and supplying to an Aave V3 market.The migration tool can be accessed through the Aave Labs Interface by navigating to an Aave V2 market, pressing the \"Migrate to V3\" button next to the market selector, and following the prompts to migrate selected supply and borrow positions.In order to swap your assets you just need to go to the Swap section and follow these steps:Select the asset you want to swap and the amount in the left side (From).Select the asset you want to swap to in the right side (From).Make sure to check the exchange rate and check the slippage. You can edit it based on your preferences. Depending on the slippage, the expected rate might differ and the transaction might even fail if you set it too low. After this click on Continue.In the next step you will need to send the approval and submit the transaction. The approval transaction will only be required the 1st time you do this step, unless you revoke the approval.Make sure to have enough ETH for the transaction cost. After sending both transactions your swap will be complete.In order to repay with your assets you just need to go to the Dashboard and follow these steps:Click on repay on the debt you want to repay.Choose repay \"With your current collateral\".Select the asset you want to repay and amount in the left side (Borrowed Asset).Select the asset you want to use to repay to in the right side (Select Collateral).Make sure to check the exchange rate and check the slippage. You can edit it based on your preferences. Depending on the slippage, the expected might differ and the transaction might even fail if you set it too low. After this click on Continue.In the next step you need to send the approval and submit the transaction. The approval transaction will only be required the 1st time you do this step, unless you revoke the approval.Make sure to have enough ETH for the transaction cost. After sending both transactions your repayment will be done.BrandThe Aave logo should be used in its original form without any modifications. It should be clearly visible and not distorted. The logo should also maintain a minimum clear space around it to ensure it stands out.You can use the Aave logo on your website or promotional materials, provided your usage doesn't misrepresent the Aave brand. Visual assets should not be altered, combined with other logos, or used in a way that misrepresents the Aave brand.Yes, we encourage you to stay true to the Aave brand while creating your own assets. Start with one of the derivative logos.Have more questions?Check out the Help & Support center for more information and detailed guides on Aave.Help & Support","tokens":9448,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267213727,"hash":"fd609d12e7ef9b6b6ae8e05694345ed64095b0b4"}
{"url":"https://docs.openzeppelin.com/contracts/5.x/api/crosschain","domain":"docs.openzeppelin.com","title":"Crosschain | OpenZeppelin Docs","text":"OpenZeppelin ContractsAPI ReferenceCrosschainSmart contract crosschain utilities and implementationsOpen in ClaudeThis directory contains contracts for sending and receiving cross chain messages that follows the ERC-7786 standard.\n\nCrosschainLinked: helper to facilitate communication between a contract on one chain and counterparts on remote chains through ERC-7786 gateways.\nERC7786Recipient: generic ERC-7786 crosschain contract that receives messages from a trusted gateway.\n\nAdditionally there are multiple bridge constructions:\n\nBridgeFungible: Core bridging logic for crosschain ERC-20 transfer. Used by BridgeERC20, BridgeERC7802 and ERC20Crosschain,\nBridgeERC20: Standalone bridge contract to connect an ERC-20 token contract with counterparts on remote chains,\nBridgeERC7802: Standalone bridge contract to connect an ERC-7802 token contract with counterparts on remote chains.\n\nHelpers\nCrosschainLinked\nERC7786Recipient\nBridges\nBridgeFungible\nBridgeERC20\nBridgeERC7802\n\nCrosschainLinked\nimport \"@openzeppelin/contracts/crosschain/CrosschainLinked.sol\";\nCore bridging mechanism.\nThis contract contains the logic to register and send messages to counterparts on remote chains using ERC-7786\ngateways. It ensure received messages originate from a counterpart. This is the base of token bridges such as\nBridgeFungible.\nContracts that inherit from this contract can use the internal CrosschainLinked._sendMessageToCounterpart to send messages to their\ncounterpart on a foreign chain. They must override the ERC7786Recipient._processMessage function to handle messages that have\nbeen verified.\nFunctions\nconstructor(links)\ngetLink(chain)\n_setLink(gateway, counterpart, allowOverride)\n_sendMessageToCounterpart(chain, payload, attributes)\n_isAuthorizedGateway(instance, sender)\nERC7786Recipient\nreceiveMessage(receiveId, sender, payload)\n_processMessage(gateway, receiveId, sender, payload)\n\nEvents\nLinkRegistered(gateway, counterpart)\n\nErrors\nLinkAlreadyRegistered(chain)\nERC7786Recipient\nERC7786RecipientUnauthorizedGateway(gateway, sender)\n\nconstructor(struct CrosschainLinked.Link[] links)internal#\n\ngetLink(bytes chain) → address gateway, bytes counterpartpublic#Returns the ERC-7786 gateway used for sending and receiving cross-chain messages to a given chain.Note: The chain parameter is a \"chain-only\" InteroperableAddress (empty address) and the counterpart returns\nthe full InteroperableAddress (chain ref + address) that is on chain.\n\n_setLink(address gateway, bytes counterpart, bool allowOverride)internal#Internal setter to change the ERC-7786 gateway and counterpart for a given chain. Called at construction.Note: The counterpart parameter is the full InteroperableAddress (chain ref + address).\n\n_sendMessageToCounterpart(bytes chain, bytes payload, bytes[] attributes) → bytes32internal#Internal messaging functionNote: The chain parameter is a \"chain-only\" InteroperableAddress (empty address).\n\n_isAuthorizedGateway(address instance, bytes sender) → boolinternal#Virtual getter that returns whether an address is a valid ERC-7786 gateway for a given sender.The sender parameter is an interoperable address that include the source chain. The chain part can be\nextracted using the InteroperableAddress library to selectively authorize gateways based on the origin chain\nof a message.\n\nLinkRegistered(address gateway, bytes counterpart)event#Emitted when a new link is registered.Note: the counterpart argument is a full InteroperableAddress (chain ref + address).\n\nLinkAlreadyRegistered(bytes chain)error#Reverted when trying to register a link for a chain that is already registered.Note: the chain argument is a \"chain-only\" InteroperableAddress (empty address).\n\nERC7786Recipient\nimport \"@openzeppelin/contracts/crosschain/ERC7786Recipient.sol\";\nBase implementation of an ERC-7786 compliant cross-chain message receiver.\nThis abstract contract exposes the receiveMessage function that is used for communication with (one or multiple)\ndestination gateways. This contract leaves two functions unimplemented:\n\nCrosschainLinked._isAuthorizedGateway, an internal getter used to verify whether an address is recognised by the contract as a\nvalid ERC-7786 destination gateway. One or multiple gateway can be supported. Note that any malicious address for\nwhich this function returns true would be able to impersonate any account on any other chain sending any message.\n\nERC7786Recipient._processMessage, the internal function that will be called with any message that has been validated.\n\nERC-7786 requires the gateway to ensure messages are not delivered more than once. Therefore, we don't need to keep\ntrack of the processed receiveId.\n@custom:stateless\nFunctions\nreceiveMessage(receiveId, sender, payload)\n_isAuthorizedGateway(gateway, sender)\n_processMessage(gateway, receiveId, sender, payload)\n\nErrors\nERC7786RecipientUnauthorizedGateway(gateway, sender)\n\nreceiveMessage(bytes32 receiveId, bytes sender, bytes payload) → bytes4external#Endpoint for receiving cross-chain message.This function may be called directly by the gateway.\n\n_isAuthorizedGateway(address gateway, bytes sender) → boolinternal#Virtual getter that returns whether an address is a valid ERC-7786 gateway for a given sender.The sender parameter is an interoperable address that include the source chain. The chain part can be\nextracted using the InteroperableAddress library to selectively authorize gateways based on the origin chain\nof a message.\n\n_processMessage(address gateway, bytes32 receiveId, bytes sender, bytes payload)internal#Virtual function that should contain the logic to execute when a cross-chain message is received.This function should revert on failure. Any silent failure from this function will result in the message\nbeing marked as received and not being retryable.\n\nERC7786RecipientUnauthorizedGateway(address gateway, bytes sender)error#Error thrown if the gateway is not authorized to send messages to this contract on behalf of the sender.\n\nBridgeERC20\nimport \"@openzeppelin/contracts/crosschain/bridges/BridgeERC20.sol\";\nThis is a variant of BridgeFungible that implements the bridge logic for ERC-20 tokens that do not expose a\ncrosschain mint and burn mechanism. Instead, it takes custody of bridged assets.\nFunctions\nconstructor(token_)\ntoken()\n_onSend(from, amount)\n_onReceive(to, amount)\nBridgeFungible\ncrosschainTransfer(to, amount)\n_crosschainTransfer(from, to, amount)\n_processMessage(, receiveId, , payload)\nCrosschainLinked\ngetLink(chain)\n_setLink(gateway, counterpart, allowOverride)\n_sendMessageToCounterpart(chain, payload, attributes)\n_isAuthorizedGateway(instance, sender)\nERC7786Recipient\nreceiveMessage(receiveId, sender, payload)\n\nEventsBridgeFungible\nCrosschainFungibleTransferSent(sendId, from, to, amount)\nCrosschainFungibleTransferReceived(receiveId, from, to, amount)\nCrosschainLinked\nLinkRegistered(gateway, counterpart)\n\nErrorsCrosschainLinked\nLinkAlreadyRegistered(chain)\nERC7786Recipient\nERC7786RecipientUnauthorizedGateway(gateway, sender)\n\nconstructor(contract IERC20 token_)internal#\n\ntoken() → contract IERC20public#\n\n_onSend(address from, uint256 amount)internal#\"Locking\" tokens is done by taking custody\n\n_onReceive(address to, uint256 amount)internal#\"Unlocking\" tokens is done by releasing custody\n\nBridgeERC7802\nimport \"@openzeppelin/contracts/crosschain/bridges/BridgeERC7802.sol\";\nThis is a variant of BridgeFungible that implements the bridge logic for ERC-7802 compliant tokens.\nFunctions\nconstructor(token_)\ntoken()\n_onSend(from, amount)\n_onReceive(to, amount)\nBridgeFungible\ncrosschainTransfer(to, amount)\n_crosschainTransfer(from, to, amount)\n_processMessage(, receiveId, , payload)\nCrosschainLinked\ngetLink(chain)\n_setLink(gateway, counterpart, allowOverride)\n_sendMessageToCounterpart(chain, payload, attributes)\n_isAuthorizedGateway(instance, sender)\nERC7786Recipient\nreceiveMessage(receiveId, sender, payload)\n\nEventsBridgeFungible\nCrosschainFungibleTransferSent(sendId, from, to, amount)\nCrosschainFungibleTransferReceived(receiveId, from, to, amount)\nCrosschainLinked\nLinkRegistered(gateway, counterpart)\n\nErrorsCrosschainLinked\nLinkAlreadyRegistered(chain)\nERC7786Recipient\nERC7786RecipientUnauthorizedGateway(gateway, sender)\n\nconstructor(contract IERC7802 token_)internal#\n\ntoken() → contract IERC7802public#\n\n_onSend(address from, uint256 amount)internal#\"Locking\" tokens using an ERC-7802 crosschain burn\n\n_onReceive(address to, uint256 amount)internal#\"Unlocking\" tokens using an ERC-7802 crosschain mint\n\nBridgeFungible\nimport \"@openzeppelin/contracts/crosschain/bridges/abstract/BridgeFungible.sol\";\nBase contract for bridging ERC-20 between chains using an ERC-7786 gateway.\nIn order to use this contract, two functions must be implemented to link it to the token:\n\nBridgeERC20._onSend: called when a crosschain transfer is going out. Must take the sender tokens or revert.\nBridgeERC20._onReceive: called when a crosschain transfer is coming in. Must give tokens to the receiver.\n\nThis base contract is used by the BridgeERC20, which interfaces with legacy ERC-20 tokens, and BridgeERC7802,\nwhich interface with ERC-7802 to provide an approve-free user experience. It is also used by the ERC20Crosschain\nextension, which embeds the bridge logic directly in the token contract.\nFunctions\ncrosschainTransfer(to, amount)\n_crosschainTransfer(from, to, amount)\n_processMessage(, receiveId, , payload)\n_onSend(from, amount)\n_onReceive(to, amount)\nCrosschainLinked\ngetLink(chain)\n_setLink(gateway, counterpart, allowOverride)\n_sendMessageToCounterpart(chain, payload, attributes)\n_isAuthorizedGateway(instance, sender)\nERC7786Recipient\nreceiveMessage(receiveId, sender, payload)\n\nEvents\nCrosschainFungibleTransferSent(sendId, from, to, amount)\nCrosschainFungibleTransferReceived(receiveId, from, to, amount)\nCrosschainLinked\nLinkRegistered(gateway, counterpart)\n\nErrorsCrosschainLinked\nLinkAlreadyRegistered(chain)\nERC7786Recipient\nERC7786RecipientUnauthorizedGateway(gateway, sender)\n\ncrosschainTransfer(bytes to, uint256 amount) → bytes32public#Transfer amount tokens to a crosschain receiver.Note: The to parameter is the full InteroperableAddress (chain ref + address).\n\n_crosschainTransfer(address from, bytes to, uint256 amount) → bytes32internal#Internal crosschain transfer function.Note: The to parameter is the full InteroperableAddress (chain ref + address).\n\n_processMessage(address, bytes32 receiveId, bytes, bytes payload)internal#Virtual function that should contain the logic to execute when a cross-chain message is received.This function should revert on failure. Any silent failure from this function will result in the message\nbeing marked as received and not being retryable.\n\n_onSend(address from, uint256 amount)internal#Virtual function: implementation is required to handle token being burnt or locked on the source chain.\n\n_onReceive(address to, uint256 amount)internal#Virtual function: implementation is required to handle token being minted or unlocked on the destination chain.\n\nCrosschainFungibleTransferSent(bytes32 indexed sendId, address indexed from, bytes to, uint256 amount)event#\n\nCrosschainFungibleTransferReceived(bytes32 indexed receiveId, bytes from, address indexed to, uint256 amount)event#AccountPrevious PageFinanceNext PageOn this pageHelpersBridgesCrosschainLinkedERC7786RecipientBridgeERC20BridgeERC7802BridgeFungible","tokens":2836,"squid":"ink-security_audits","role":"Sentinel","at":1791267222544,"hash":"b0f498b29060c0bb455504a96074ffaedb9d476a"}
{"url":"https://aave.com/security","domain":"aave.com","title":"Security | Aave","text":"6+ YearsOf uninterrupted operation.$4.4B+Liquidated safely, zero bad debt.65 AuditsAudits & AI-assisted reviews.$148.41MUmbrella backstop.$5M+Live bug bounty rewards.SOC 2 Type 2Annual security audit.Onchain votingEvery change is an AIP, voted on-chain by AAVE holders. No entity, not even Aave Labs, can act alone.Mandatory timelocksApproved proposals wait before execution: 1 day for standard changes, 7 days for governance changes.Community GuardianA 5-of-9 community multisig can veto malicious proposals. A safeguard, not a control.Full transparencyEvery proposal, vote, and execution is on-chain. Security reports ship on GitHub with each AIP.Proposal lifecycleLive OnchainARFC ReviewPublished with a business case. Risk and technical assessments follow in the same thread, against the Aave Risk Framework and the Technical Asset Listing Framework.4-day windowSnapshot votesA binding off-chain vote in the Aave Snapshot Space.1-day delay, 3-day voteAIP on-chain voteSecurity providers review the payload for errors. Voting then opens on-chain after a one-day delay.3-day vote (10 days for governance changes)Monitoring + timelockPassed proposals queue behind a timelock. A 5-of-9 Guardian can cancel a malicious or erroneous proposal before execution.1-day timelock (7 days for governance changes)ExecutionAny address can execute once the timelock elapses, usually via Chainlink automation. Cross-chain changes are delivered through a.DI, and unexecuted proposals expire.7-day grace periodDetectContinuous monitoring covers onchain activity, offchain infrastructure, and emerging risk signals 24/7.TriageSecurity and risk teams triage issues with Guardian responders ready.RemediateSpecialists fix it; audit firms verify it.DiscloseEvery incident ends in a public post-mortem.DetectContinuous monitoring covers onchain activity, offchain infrastructure, and emerging risk signals 24/7.TriageSecurity and risk teams triage issues with Guardian responders ready.RemediateSpecialists fix it; audit firms verify it.DiscloseEvery incident ends in a public post-mortem.Contract addressesFind deployed Aave Protocol contracts across every supported network.docs/resources/addressesLive parametersReview the current parameters that configure Aave markets and assets.docs/resources/parametersAccess controlsUnderstand the roles, permissions, and controls used by the protocol.docs/resources/access-controlsChangelogTrack changes to protocol deployments, configurations, and interfaces.docs/resources/changelogBug Bounty Programs$3.5M+in Active Bounty RewardsAave V4 Bug Bounty•Up to $3.5MSherlock•Live since May 18 2026Aave Core Bug Bounty•Up to $5MImmunefi•Live since Oct 18 2023Aave V3 Aptos Bug BountyCantina•Per governance proposalSecurity Assessment BriefA comprehensive overview of Aave's security posture, governance controls, audit history, and incident response.Download the PDFSOC-2 Type IIMar 2026Attestation letter can be supplied on demandView ContractsCollaborative Audit ReportSherlock · May 14 2026Formal Verification - Tokenization SpokeCertora · Apr 13 2026Code AssessmentChainSecurity · Mar 23 2026Formal Verification - HubCertora · Mar 09 2026Formal Verification - LibrariesCertora · Mar 09 2026Formal Verification - SpokeCertora · Mar 09 2026Security AuditChainSecurity · Feb 19 2026Security Audit - Tokenization SpokeChainSecurity · Feb 10 2026Security ReviewTrail of Bits · Feb 10 2026Collaborative Audit ReportSherlock · Feb 05 2026Security ReviewBlackthorn · Oct 20 2025View ContractsStable Vault ReportJosselin Feist · Jul 2026Stable Vault Report - Extension 1Josselin Feist · Jul 2026Stable Vault Report - Extension 2Josselin Feist · Jul 2026Stable Vault Report - Extension 3Josselin Feist · Jul 2026Formal Verification - Stable VaultsCertora · Jun 2026Security Assessment - a.DICertora · Jun 2026Code Assessment - Stable VaultsChainSecurity · May 2026Security Assessment - Stable VaultsCertora · May 2026Security Assessment - Stable VaultsCertora · Apr 2026Code Assessment - Stable VaultsChainSecurity · Mar 2026Security Assessment - Stable VaultsCertora · Jan 2026Security Assessment - Web WalletZellic · May 26 2026Security Assessment - Web ApplicationZellic · May 26 2026Security Audit - ERC-6900 ModulesQuantstamp · Apr 17 2026Security Assessment - Web WalletZellic · Mar 11 2025Security Assessment - Web WalletZellic · Mar 8 2024Security Assessment - iOS AppZellic · Feb 28 2024Security Assessment - Web ApplicationZellic · Nov 17 2023Security Assessment - Abstracted AccountZellic · Feb 22 2023View ContractsSecurity ReviewEnigma Dark · Mar 31 2026Supervised Security ReviewSavant · Mar 30 2026Security Assessment & Formal Verification ReportCertora · Mar 29 2026Security ReviewPashov · Mar 27 2026Security Audit ReportMixBytes · Mar 26 2026Audit Contest ReportSherlock · Mar 26 2026Security ReviewPashov · Nov 29 2025View ContractsSecurity ReviewPashov · Nov 29 2025Security Assessment & Formal Verification ReportCertora · Nov 18 2025Security Audit ReportMixBytes · Nov 18 2025Supervised Security ReviewSavant · Nov 18 2025Security ReviewBlackthorn · Nov 16 2025View ContractsSecurity Audit ReportMixBytes · Jul 18 2025Security ReviewStErMi · Jul 17 2025Smart Contract AuditABDK · Jul 17 2025Security AssessmentCertora · Jul 14 2025View ContractsSecurity ReviewBlackthorn · Jun 12 2025Security AssessmentCertora · Jun 11 2025Smart Contract Security Audit ReportStErMi · Jun 11 2025Security ReviewEnigma Dark · May 13 2025View ContractsSecurity Audit Report - V3.1-V3.3OtterSec · Aug 8 2025Security Audit Report - Core V3.0.2Spearbit · Jun 18 2025Security Audit Report - Core V3.1-V3.3Spearbit · Jun 18 2025Security Audit Report - Periphery V3.0.2Spearbit · Jun 18 2025Security Assessment & Formal Verification Report - Core V3.0.2Certora · Apr 2025Security Assessment & Formal Verification Report - Core V3.1-V3.3Certora · Apr 2025Security Assessment & Formal Verification Report - Periphery V3.0.2Certora · Apr 2025View ContractsSmart Contract Security Audit ReportMixBytes · May 19 2025Smart Contract Security Audit ReportAckee · May 19 2025Smart Contract Security Audit ReportStErMi · Mar 2025Security Assessment & Formal Verification ReportCertora · Feb 2025View ContractsInvariant TestingEnigma Dark · Feb 12 2025Smart Contract Security Audit ReportOxorio · Jan 29 2025Audit Contest ReportSherlock · Jan 22 2025Security Assessment & Formal Verification ReportCertora · Nov 07 2024Security ReviewStErMi · Oct 22 2024View ContractsSecurity ReviewEnigma Dark · Sep 30 2024Security Assessment & Formal Verification Report - Liquid eModesCertora · Sep 19 2024Security ReviewPashov · Sep 15 2024Security Audit Report - Liquid eModesOxorio · Sep 12 2024Security Assessment & Formal Verification Report - Stable Rate RemovalCertora · Sep 10 2024View ContractsCompetition ReportConsensys Diligence · Jun 2 2024Security Audit ReportMixBytes · May 2 2024Security Assessment ReportCertora · Apr 30 2024View ContractsGHO Stability Module Contract ReviewSigma Prime · Oct 23 2023GHO Smart Contract Security Assessment ReportSigma Prime · Jul 06 2023GHO Steward Contract ReviewSigma Prime · Jun 13 2023GHO Steward Security Assessment & Formal Verification ReportCertora · Mar 14 2023GHO Smart Contract AuditABDK · Mar 01 2023GHO Audit V2OpenZeppelin · Nov 10 2022GHO AuditOpenZeppelin · Aug 12 2022View ContractsContract ReviewSigma Prime · Apr 19 2023Contract ReviewCertora · Mar 2023View ContractsContract ReviewSigma Prime · Dec 23 2022Formal Verification of Aave V3 upgrade to V3.0.1Certora · Nov 17 2022 - Dec 15 2022Smart Contract Audit ReportPeckShield · Dec 22 2022View ContractsSmart Contract Audit ReportABDK · Jan 27 2022Smart Contract Security Assessment ReportSigma Prime · Jan 27 2022Formal Verification of Aave Protocol V3Certora · Nov 12 2021 - Jan 24 2022Smart Contract Audit ReportPeckShield · Jan 14 2022Security Assessment ReportTrail of Bits · Jan 7 2022Smart Contract Audit ReportOpenZeppelin · Jan 11 2021View ContractsLight Deployment Smart Contract Audit ReportPeckShield · Mar 16 2021Smart Contract Security AssessmentSigma Prime · Jan 2021Smart Contract Audit ReportConsensys Diligence · Sep 2020Smart Contract Security AssessmentCertiK · Sep 2020Smart Contract Audit ReportPeckShield · Sep 2020Smart Contract Audit ReportMixBytes · Sep 2020DDOS ProtectionAdvanced cloud-based DDoS protection services are used to identify and neutralize threats before they reach interface infrastructure.Domain ProtectionTo safeguard the domain, DNSSEC is used to protect against DNS spoofing and ensure domain name requests are securely authenticated.Intrusion DetectionThe front-end employs state-of-the-art intrusion detection systems (IDS) that monitor for suspicious activities and potential threats, ensuring immediate detection and response to protect user data.Modification DetectionContent Security Policy and Subresource Integrity checks are used to detect and prevent unauthorized modifications to front-end code.IPFS Naming RecordsEach commit of the Aave Interface codebase is automatically deployed to IPFS. The app.aave.com IPNS pointer and domain text records are continuously updated to reflect latest deployment hash using the DNSLink standard.AI-Assisted Security Review of Aave V3 & V4Three AI security tools were run against Aave V3 and V4. Across 71 findings, no Critical or High severity issue was confirmed in either protocol.Security by Design: Aave V4 Governance Security UpdateHow Aave V4 achieved zero high-severity findings across 345 days of security review, formal verification, and a 900-participant public contest.How Aave Liquidations Perform Under Volatile ConditionsA data-driven look at Aave's $4.6 billion in historical liquidations, demonstrating the protocol's resilience across multiple market cycles and stress events.Annual large scale fire drill simulating high impact scenariosPassedQuarterly emergency protocol guardian drillsPassedGitHubProtocol code, audits, and AIPs.View on GitHubHelp & SupportYour questions answered.Visit Help & SupportDocumentationArchitecture, contracts, integration.Read the DocsFAQsYes. Aave publishes independent audit reports, security reviews, and formal verification reports across protocol versions.Audit reports are available on the Aave Security page. Deployed contracts are listed in the Aave docs and the Aave Address Book.Smart contract risk cannot be eliminated. Aave mitigates it through open-source code, independent audits, formal verification, governance review, and bug bounties.Protocol changes are governed by the Aave DAO through onchain proposals, voting, timelocks, and execution.No central party can freeze or alter individual user positions. Certain reserve-level controls may be used only for protocol risk management.","tokens":2687,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267223726,"hash":"fce9c057e3a60b3850e6af2d72f1a8bc7c0978b7"}
{"url":"https://docs.base.org/get-started/integrate-defi","domain":"docs.base.org","title":"Integrate DeFi - Base Documentation","text":"Connect your app to third-party DeFi protocols on Base. Let users trade tokens, manage direct lending positions, borrow against collateral, or deposit once into a vault-based earn product while signing every transaction from their own wallet.\n​Demo\nScenario1Load2Supply3Accrue4WithdrawDemo1Load walletIn progress2Supply USDCPending3Accrue 30 daysPending4WithdrawPendingLoad walletA user has 1,000 USDC available in their wallet.OperationLoad walletAssetUSDCAmount1,000 USDCNetworkBase VibenetTransaction event log10:42:11[PENDING]Load wallet10:42:12[PENDING]Supply USDC10:42:13[PENDING]Accrue 30 days10:42:14[PENDING]WithdrawIllustrative only · rates and liquidity vary by market.\nThe demo above is mock only. If you want to see onchain demos on Vibenet, head to Base chain demos.\n​Guides\nWas this page helpful?Suggest editsRaise issue","tokens":209,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267229389,"hash":"dc6c54151e35b98c215ec2b9fdfb82295af82e3e"}
{"url":"https://aave.com/docs/ecosystem/gho","domain":"aave.com","title":"GHO | Aave Protocol Documentation","text":"GHO#\n\nGHO (pronounced \"go\") is a decentralised, over-collateralised stablecoin that is fully backed, transparent, and native to the Aave Protocol. Designed to maintain a value pegged to the U.S. dollar, GHO is minted by users on demand, subject to mint cap limitations set by Aave's governance. Its stability is maintained through market efficiencies and over-collateralisation mechanisms inherent in the Aave Protocol.\nGHO is an ERC-20 token deployed on Ethereum that operates through a facilitator model. Facilitators are contracts approved by Aave Governance with the ability to mint and burn GHO, each subject to a governance-defined mint cap. This model allows for flexibility in expanding GHO's functionality while maintaining decentralized control over the supply.\nGHO Token#\nThe GHO Token contract includes specific roles for managing facilitators and their minting capacities:\nFACILITATOR_MANAGER_ROLE: This role is responsible for adding and removing facilitators.BUCKET_MANAGER_ROLE: This role is responsible for setting the bucketCapacity for existing facilitators.\nEach facilitator is represented by a Facilitator struct, which contains:\nlabel: A string identifier for the facilitator.bucketCapacity: The maximum amount of GHO a facilitator can mint.bucketLevel: The current amount of GHO minted by the facilitator.\ntransfer#\nThe simplest method for transferring ERC-20 tokens is transfer which can be used to send tokens to any address without a prior token approval. The limitation of transfer is that it must be executed directly by the token holder, so it cannot be used within a smart contract function call to retrieve funds from a user (EOA).\ntransferFrom#\nTo transfer tokens within a smart contract function, transferFrom is the method that is used. The transferFrom function requires the sender to have approved the spender address for at least the transfer amount. There are two methods which can be used to perform the approval:\napprove#\nThe standard ERC-20 approve requires an on-chain transaction from the token holder to a approve a specified spender and amount.\npermit#\nEIP-2612 permit is a type of token approval which requires two components:\nA signed approval message from the token holder which encodes: owner, spender, amount, nonce, deadline, DOMAIN_SEPARATORAn on-chain permit transaction which can be executed from any address\nThe advantages to using permit in place of approve are that the gas cost of the transaction can be paid for by an address other than the token owner, and can reduce the number of transactions by batching the permit call with another action, an example of this is supplyWithPermit from Aave Protocol v3.\nFacilitators#\n\nFacilitators are contract addresses approved by Aave Governance with the FACILITATOR_MANAGER_ROLE and BUCKET_MANAGER_ROLE, giving them the ability to mint and burn GHO tokens. Each facilitator operates under a specific bucketCapacity, controlling the maximum amount of GHO they can generate. Facilitators play a crucial role in maintaining GHO's stability and integrating it across various platforms and use cases.\nGHO Token Functions for Facilitators#\nFacilitators interact with the GHO token using the following functions:\nmint(address account, uint256 amount): Allows a facilitator to mint amount of GHO tokens to the account. The amount must be greater than 0, and the new bucketLevel (current bucketLevel + amount) must not exceed the facilitator's bucketCapacity. This function updates the facilitator's bucketLevel.burn(uint256 amount): Allows a facilitator to burn amount of GHO tokens from their own balance. The amount must be greater than 0, and the facilitator's bucketLevel is decreased by the burned amount.\nFacilitator Management Functions#\nThe GHO token contract also provides functions for managing facilitators:\naddFacilitator(address facilitatorAddress, string calldata facilitatorLabel, uint128 bucketCapacity): Callable by an address with the FACILITATOR_MANAGER_ROLE, this function adds a new facilitator with a specified label and bucketCapacity. A facilitator cannot be added if it already exists or if the label is empty.removeFacilitator(address facilitatorAddress): Callable by an address with the FACILITATOR_MANAGER_ROLE, this function removes an existing facilitator. A facilitator can only be removed if its bucketLevel is 0.setFacilitatorBucketCapacity(address facilitator, uint128 newCapacity): Callable by an address with the BUCKET_MANAGER_ROLE, this function updates the bucketCapacity of an existing facilitator.\nFacilitator Query Functions#\nInformation about facilitators can be retrieved using:\ngetFacilitatorsList(): Returns a list of all registered facilitator addresses.getFacilitator(address facilitator): Returns the Facilitator struct details (label, bucketCapacity, bucketLevel) for a given facilitator address.getFacilitatorBucket(address facilitator): Returns the bucketCapacity and bucketLevel of a specific facilitator.\nAave v3 Ethereum Market#\nThe Aave v3 Ethereum Market serves as a primary facilitator for GHO. Users can mint GHO by supplying approved collateral assets into the Aave Protocol and borrowing GHO against them. This process follows standard over-collateralisation practices, ensuring the protocol's security and the stablecoin's reliability.\nInteracting with GHO via the Aave Pool Facilitator is very similar to interacting with a typical Aave reserve asset with two key differences:\nGHO is minted, not supplied, therefore interest rate and available liquidity calculations are based on custom interest rate strategy and facilitator caps respectively\nBelow are the technical guides for all GHO actions along with their contract references.\nMinting#\nMinting occurs through the borrow function of the Aave v3 Ethereum market. To mint GHO, the process is nearly identical to borrowing any other reserve. To mint, an address must have sufficient collateral which is performed by approving and then calling supply on the Aave Pool with an eligible collateral asset. Once an address has sufficient collateral, it is able to borrow up to a maximum collateral factor determined by its collateral asset composition.\nSince GHO is created and not borrowed from suppliers, GHO is not subject to restrictions on available liquidity, and instead, the Facilitator cap and collateralization requirements define the limits to which GHO can be minted as calculated below.\navailableFacilitatorCap = ghoReserveData.aaveFacilitatorButcketMaxCapacity - ghoReserveData.aaveFacilitatorBucketLevel\nSee core functions for more information on integrating Aave borrow functionality.\nRepay#\nGHO is repaid just like any other asset, by approving the Pool contract to spend GHO tokens (by approval transaction or signed permit and repayWithPermit).\nSee core functions for more information on integrating Aave repay functionality.\nLiquidation#\nWhen an address has a GHO borrow position, they are eligible to be liquidated under the same conditions as any other collateralized address. If the health factor of a GHO borrow falls below one, which occurs when the sum of borrow value exceeds the weighted average of liquidation thresholds of collateral assets, then any address is eligible to make a liquidationCall on the Pool contract.\nThe liquidationCall repays up to 100% of the GHO borrow position in exchange for an equivalent USD valuation of the collateral plus a liquidation bonus.\nFlash Mint#\nSince GHO is not borrowed like a typical Aave reserve, a separate Facilitator is used in place to replicate the flashloan functionality of the Aave Pool.\nThe FlashMinter Facilitator has a separate minting cap from the Aave Pool. Since all FlashMint transactions are returned in a single transaction, no GHO is ever minted against this Facilitator and the cap is applied to each transaction.\nFlashMint is useful for a variety of applications such as liquidations, debt switches, and peg arbitrage. The GhoFlashMinter smart contract implements the following functions:\nfunction maxFlashLoan(address token) external view override returns (uint256)\nfunction getFee() external view override returns (uint256)\nfunction flashLoan( IERC3156FlashBorrower receiver, address token, uint256 amount, bytes calldata data) external override returns (bool)\nSee the developers flash loan guide for more information on developing flash loan integrations.\nStability Module#\nA Peg Stability Module (PSM) is a contract that enables the conversion of two tokens at a predetermined ratio. The GHO Stability Module (GSM) leverages the benefits of existing PSM models while innovating upon them in several ways to help further maintain GHO’s peg. The GSM is designed to facilitate conversions between GHO and governance-approved tokens, underpinned by a suite of features designed for flexible operations and risk management.\nGSMRegistry#\nThe GSMRegistry is a smart contract that stores a list of all GSM instances. This contract is owned by the Aave Governance Short Executor.\nGSM#\nEach token pairing in the stability module has a GSM or GSM4626 contract instance that acts as the GHO facilitator and entry-point for buy and sell functionality.\nThe GSM4626 contract is a special instance of the GSM that supports ERC-4626 tokenized vault shares as the exogenous token.\nThe parameters and periphery contracts that dictate module operations are detailed below:\nPrice Strategy#\nThe GSM introduces a flexible Price Strategy framework, enabling the module to adapt its pricing mechanism based on market conditions or strategic objectives. This system supports both fixed and dynamic pricing strategies, allowing for adjustments in response to real-time market data or predetermined conditions. The initial implementation focuses on a fixed 1:1 pricing strategy for simplicity and stability, with provisions for future adaptation to dynamic strategies as dictated by DAO governance.\nFee Strategy#\nEach GSM instance has a FeeStrategy contract that determines a percentage fee for buy and sell conversions that is allocated to the Aave DAO treasury.\nExposure Cap#\nThe exposure cap is a parameter determined by Aave DAO Governance that sets the maximum amount of an exogenous token the stability module can hold.\nConversion Freezes and Oracle Price Bounds#\nIn case the price of the exogenous token deviates from a determined ratio, the freeze role can be utilized by the Aave DAO or assigned to an entity (autonomous agents or contracts) to respond and halt conversions.\nAn implementation of the freeze role is the OracleSwapFreezer contract. This contract utilizes Chainlink oracles and price bounds determined by Aave Governence to freeze/unfreeze based on oracle conditions.\nLast Resort Liquidations#\nIn case of a rapid increase in risk in an exogenous token, the GSM features Last Resort Liquidations to liquidate the exogenous token. This contract role allows in the worst-case scenarios for the DAO to pause GSM functionality and liquidate the underlying balance of exogenous tokens.\nCross-Chain#\nAll GHO tokens are originated on Ethereum mainnet. GHO is made available to access on other networks using an infrastructure of cross-chain messaging.\nThe Chainlink CCIP protocol has been approved by Aave Governance as the messaging bridge to facilitate the transfer of GHO between networks.\nGHO is transferred by between networks by initiating a lock (Ethereum mainnet) or burn (other networks) action on the source network, and a release (Ethereum mainnet) or mint (other networks) action occurs on the destination chain after the cross-chain message has been validated.\nThe GHOCCIPTokenPoolEthereum contract facilitates the locking and burning of GHO on Ethereum and other chains, enabling GHO's presence across multiple DeFi ecosystems.\nGHO Token Deployments:\nEthereum MainnetArbitrumBaseAvalancheGnosisMantleMonadPlasmaXLayer\nGHO CCIP Subgraph:\nCCIP Ethereum SubgraphCCIP Arbitrum SubgraphCCIP Base SubgraphCCIP Avalanche SubgraphCCIP Gnosis Subgraph\nGHO Liquidity Committee#\nThe GHO Liquidity Committee (GLC) was created in October 2023 to focus solely on the liquidity of the GHO stablecoin. The committee was formed through a governance proposal and consisted of a small team. After a successful initial 3-month period, it was integrated into the Aave Liquidity Committee (ALC).\nThe ALC's main responsibilities regarding GHO include:\nProviding analytics and modelling of the liquidity strategyLiaising with teams that support the protocols hosting GHO liquidityLeading and coordinating the committee's weekly activitiesProviding critical feedback and helping refine the strategyVerifying and signing transactions\nThe ALC's performance measures and liquidity targets for GHO can be found on the GHO Analytics platform provided by TokenLogic.\nMore information regarding the role of the GHO Liquidity Committee can be found in Aave's Governance forum.\nGHO Stewards#\nGHO Stewards is an additional entity created in April 2024 to more flexibly manage GHO market parameters, enabling GHO to be scaled per prevailing market conditions. The source code for GHO Steward contracts can be found on GitHub.\nThe GHO Stewards determine if and how much to adjust the following, subject to pre-defined and Governance accepted thresholds:\nGHO Borrow CapGHO Borrow RateGSM Exposure CapGSM Bucket CapacityGSM Price StrategyGSM Fee StrategyGSM Price Range (Freeze, Unfreeze)\nWith many liquidity pools being created and rewards distributed across them, it is important that the DAO can swiftly increase the GHO Borrow Cap to mitigate GHO trading above $1. The GHO Stewards can swiftly increase the GHO Borrow Cap to mitigate GHO trading above the peg. The GHO Stewards can increase the GHO Borrow Cap to a threshold of 50M units to a total borrow cap of 100M.\nThe Borrow Rate must be adjusted gradually to enable the ecosystem to expand safely. If the trailing 30-day average price of GHO stays outside a $0.995 - $1.005 price range, the GHO Stewards are able to adjust the Borrow Rate no more than 500bps per 2-day period, up to a maximum 25% APR.\nGHO Stewards consist of members from Growth (ACI), Risk (ChaosLabs), and Finance (TokenLogic + karpatkey) Service Providers and utilise a 3 of 4 multi-sig.\nDeployed Contracts#\nEthereum Mainnet#\nContractAddressGhoToken0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2fGhoCCIPTokenPoolEthereum0x06179f7C1be40863405f374E7f5F8806c728660AGhoFlashMinter0xb639D208Bcf0589D54FaC24E655C79EC529762B8GhoLiquidityComittee0xA1c93D2687f7014Aaf588c764E3Ce80aF016229bGhoGsmSteward0xD1E856a947CdF56b4f000ee29d34F5808E0A6848GSMRegistry0x167527DB01325408696326e3580cd8e55D99Dc1AGSMUSDC0x3A3868898305f04beC7FEa77BecFf04C13444112GSMUSDT0x882285E62656b9623AF136Ce3078c6BdCc33F5E3GSMUSDCFixedFeeStrategy0xE5025A7c15a44283A0616567181587eE6A646D64GSMUSDTFixedFeeStrategy0xA4346AEa575fCf5777D32F419E5850E5c68B2329GSMUSDCFixedPriceStrategy0x00e89F4022FD13AD56e321D50612Eec598eF3b72GSMUSDTFixedPriceStrategy0x20Be7090711995336A13e24B9EA9e05ac2cdd8C0GSMUSDCOracleSwapFreezer0x6e51936e0ED4256f9dA4794B536B619c88Ff0047GSMUSDTOracleSwapFreezer0x733AB16005c39d07FD3D9d1A350AA6768D10125bGHO_AAVE_CORE_STEWARD0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34GHO_BUCKET_STEWARD0x46Aa1063e5265b43663E81329333B47c517A5409GHO_CCIP_STEWARD0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39RISK_COUNCIL0x8513e6F37dBc52De87b166980Fa3F50639694B60\nArbitrum#\nContractAddressGHOToken0x7dfF72693f6A4149b17e7C6314655f6A9F7c8B33GHOCCIPTokenPool0xB94Ab28c6869466a46a42abA834ca2B3cECCA5eBGHOCCIPBridge0x812fBcd390A3C6c01C65B767413Dea6f6e24FDD0GHOAaveCoreSteward0xd2D586f849620ef042FE3aF52eAa10e9b78bf7DeGHOBucketSteward0xa9afaE6A53E90f9E4CE0717162DF5Bc3d9aBe7B2GHOCCIPSteward0xCd5ab470AaC5c13e1063ee700503f3346b7C90DbGHOGsmSteward0x4DFfA29C526b5CFB419e14E3111516Fbf929797DGHOReserve0xC912D64F9F649897dC0244da3835869d410d053eGSMUSDC0x53E0cE250d06043414070100458546AaF4e284eDGSMUSDCFeeStrategy0x2169Bf2084bDb881587b3Cf6B24011E6AA091FdEGSMUSDCOracleSwapFreezer0xC5aF63c233eA19cB191b36D16C1e25cDA08409E7RiskCouncil0x8513e6F37dBc52De87b166980Fa3F50639694B60\nBase#\nContractAddressGHOToken0x6Bb7a212910682DCFdbd5BCBb3e28FB4E8da10EeGHOCCIPTokenPool0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34GHOAaveCoreSteward0xC5BcC58BE6172769ca1a78B8A45752E3C5059c39GHOBucketSteward0x3c47237479e7569653eF9beC4a7Cd2ee3F78b396GHOCCIPSteward0xB94Ab28c6869466a46a42abA834ca2B3cECCA5eB\nMantle#\nContractAddressGHOToken0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73GHOCCIPTokenPool0xDe6539018B095353A40753Dc54C91C68c9487D4EGHOAaveCoreSteward0xA5Ba213867E175A182a5dd6A9193C6158738105AGHOBucketSteward0x2Ce400703dAcc37b7edFA99D228b8E70a4d3831BGHOCCIPSteward0x20fd5f3FCac8883a3A0A2bBcD658A2d2c6EFa6B6\nAvalanche#\nContractAddressGHOToken0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73GHOCCIPTokenPool0xDe6539018B095353A40753Dc54C91C68c9487D4EGHOAaveCoreSteward0xA5Ba213867E175A182a5dd6A9193C6158738105AGHOBucketSteward0x2Ce400703dAcc37b7edFA99D228b8E70a4d3831BGHOCCIPSteward0x20fd5f3FCac8883a3A0A2bBcD658A2d2c6EFa6B6RiskCouncil0x8513e6F37dBc52De87b166980Fa3F50639694B60\nGnosis#\nContractAddressGHOToken0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73GHOCCIPTokenPool0xDe6539018B095353A40753Dc54C91C68c9487D4EGHOOracle0x360d8aa8F6b09B7BC57aF34db2Eb84dD87bf4d12GHOAaveCoreSteward0x6e637e1E48025E51315d50ab96d5b3be1971A715GHOBucketSteward0x6Bb7a212910682DCFdbd5BCBb3e28FB4E8da10EeGHOCCIPSteward0x06179f7C1be40863405f374E7f5F8806c728660ARiskCouncil0x8513e6F37dBc52De87b166980Fa3F50639694B60\nMonad#\nContractAddressGHOToken0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73GHOCCIPTokenPool0xA5AE05b71c3F170E12E7620Fdf7679721aec1EC8GHOAaveCoreSteward0xA5Ba213867E175A182a5dd6A9193C6158738105AGHOBucketSteward0xDe6539018B095353A40753Dc54C91C68c9487D4EGHOCCIPSteward0x360d8aa8F6b09B7BC57aF34db2Eb84dD87bf4d12RiskCouncil0x8513e6F37dBc52De87b166980Fa3F50639694B60\nPlasma#\nContractAddressGHOToken0xb77E872A68C62CfC0dFb02C067Ecc3DA23B4bbf3GHOCCIPTokenPool0x360d8aa8F6b09B7BC57aF34db2Eb84dD87bf4d12GHOOracle0xb0e1c7830aA781362f79225559Aa068E6bDaF1d1GHOBucketSteward0x2Ce400703dAcc37b7edFA99D228b8E70a4d3831BGHOCCIPSteward0x20fd5f3FCac8883a3A0A2bBcD658A2d2c6EFa6B6GHOGsmSteward0x86992b2E2385E478dd2eeBfaE06369636e0a64E8GHOAaveCoreSteward0xA5Ba213867E175A182a5dd6A9193C6158738105AGHOReserve0x6aC541605b0317dE076C9FeC2842902c844dEa74GSMUSDT0xd06114F714beCD6f373e5cE94E07278eF46eBF37GSMUSDTFeeStrategy0xD70BE7e6111EA563226cb8e53B1F195Da4E566E2GSMUSDTOracleSwapFreezer0xa9afaE6A53E90f9E4CE0717162DF5Bc3d9aBe7B2RiskCouncil0x8513e6F37dBc52De87b166980Fa3F50639694B60\nXLayer#\nContractAddressGHOToken0xDe6539018B095353A40753Dc54C91C68c9487D4EGHOCCIPTokenPool0xA5Ba213867E175A182a5dd6A9193C6158738105AGHOBucketSteward0x20fd5f3FCac8883a3A0A2bBcD658A2d2c6EFa6B6GHOAaveCoreSteward0x6e637e1E48025E51315d50ab96d5b3be1971A715GHOCCIPSteward0xFAdC082665577b533e62A7B0E067f884cA5C5E8FRiskCouncil0x8513e6F37dBc52De87b166980Fa3F50639694B60\nSepolia (Testnet)#\nContractAddressGhoToken0xc4bF5CbDaBE595361438F8c6a187bDc330539c60GhoATokenImpl0xD4BDb51fB96996CA24a5C49E7b57f94a1850Fa30GhoDiscountRateStrategy0x19cdecE64EDE475ba0EB114ff4E319d64Ef8ECCfGhoInterestRateStrategy0x521247B4d0a51E71DE580dA2cBF99EB40a44b3BfGhoOracle0x00f7fecFAEbEd9499e1f3f9d04E755a21E5fc47CGhoStableDebtTokenImpl0x2aa7819F2e88aF4cfF8FD0869ABdB97E336101EeGhoVariableDebtTokenImpl0xd4FEA5bD40cE7d0f7b269678541fF0a95FCb4b68GhoFlashMinter0xB5d0ef1548D9C70d3E7a96cA67A2d7EbC5b1173EUiGhoDataProvider0x69B9843A16a6E9933125EBD97659BA3CCbE2Ef8APreviousAAVENextSavings GHO (sGHO)","tokens":4848,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267234692,"hash":"f4f27d9a986b9e33e74d2fe629eda9fafac866dc"}
{"url":"https://chain.base.org/demos","domain":"chain.base.org","title":"Vibenet · Base Chain","text":"DemosAccountsSend native account-abstraction transactions from in-browser EOA keys, fund them from the faucet, and inspect balances across networks.EOA accounts from in-browser secp256k1 keysBatched, nonce-free and sponsored sendsTransactions land in the next 200 ms blockTokensCreate tokens with B20 — Base's enshrined, ERC-20-compatible token standard — then attach transfer policies, transaction memos, and Asset announcements with no custom contracts.Pay gas with your own stablecoin (ERC-8168 token payment)Transaction memos for payment tracking and reconciliationPolicies and Asset announcementsEvery send confirms in a 200 ms blockValidity TransactionsExplore transactions that remain pending until their onchain conditions are satisfied, then execute without a keeper or a custom settlement contract.Attach state and block-number conditions to signed transactionsLet the sequencer evaluate validity before inclusionBuild intent-like flows from ordinary account transactionsConnectChain IDRPC URLExplorer/vibenet/explorer","tokens":257,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267239949,"hash":"5464fc2ad950cbee1cce03af0502712238a9b347"}
{"url":"https://aave.com/docs/resources/risks","domain":"aave.com","title":"Risks | Aave Protocol Documentation","text":"Risks#\n\nThe Aave Protocol offers decentralised access to liquidity but is not without risks. Robust risk management measures, including smart contract audits and governance frameworks, are in place to help mitigate risks. Below is an overview of key risks and mitigation efforts.\nSmart Contract Risk#\nSmart contracts can contain software bugs or other vulnerabilities within the protocol code and the underlying reserve tokens. To mitigate these risks, Aave’s code is publicly available for audit and has undergone multiple external third-party professional audits. Any proposed changes to the protocol code are thoroughly reviewed and approved prior to implementation by the Aave community. Additionally, the protocol runs a continuous bug bounty program to incentivize external developers to identify and report any issues they may find so they can be fixed.\nOracle Risk#\nAave relies on third-party oracles for price feeds and external data, such as redemption ratios for liquid staking tokens. This reliance introduces potential risks such as incorrect valuations if an oracle fails or is compromised. To reduce this risk, Aave uses decentralised oracles like Chainlink, which provide tamper-resistant data feeds, greater reliability, and security measures.\nCollateral Risk#\nThe Aave DAO also engages risk service providers who track collateral performance and market stability. The value and liquidity of assets used as collateral can fluctuate, leading to the risk of under collateralisation or bad debt. Aave mitigates these risks by setting key risk parameters such as loan-to-value (LTV) ratios and liquidation thresholds. These parameters are continuously monitored by risk service providers and can be adjusted by Aave governance to respond to market conditions.\nNetwork / Bridge Risk#\nAave operates across multiple blockchain networks and bridges, each with potential risks such as congestion, censorship, or security vulnerabilities. To address these types of risks, Aave Governance has a robust network onboarding framework that thoroughly vets new networks and bridges before they are integrated into the protocol. Community oversight during the governance process is an important step to validate adoption of secure and reliable systems, minimising risk.\nFor additional information on Aave Protocol risk management, see Security & Audits.PreviousChangelogNextWeb3","tokens":595,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267246081,"hash":"07fa14acb6040e4a74762edc2831c2e1c76729ca"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/25","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 25 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 13, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n post by vbuterin on Jan 29, 2018\n\n post by kladkogex on Jan 29, 2018\n\n post by vbuterin on Jan 29, 2018\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n post by kladkogex on Jan 30, 2018\n\n post by vbuterin on Jan 30, 2018\n\n post by kz on Jan 30, 2018\n\n post by denett on Jan 31, 2018\n\n Load more posts below","tokens":801,"squid":"ink-research","role":"Deep Scholar","at":1791267258701,"hash":"5cead49cbeda814a1ae9feaa11ca403ed53fe865"}
{"url":"https://chain.base.org/","domain":"chain.base.org","title":"Base Chain","text":"Featured DemosLive on VibenetAll DemosValidity TransactionsExplore transactions that remain pending until their onchain conditions are satisfied, then execute without a keeper or a custom settlement contract.Attach state and block-number conditions to signed transactionsLet the sequencer evaluate validity before inclusionBuild intent-like flows from ordinary account transactionsTokensCreate tokens with B20 — Base's enshrined, ERC-20-compatible token standard — then attach transfer policies, transaction memos, and Asset announcements with no custom contracts.Pay gas with your own stablecoin (ERC-8168 token payment)Transaction memos for payment tracking and reconciliationPolicies and Asset announcementsEvery send confirms in a 200 ms blockSnapshotsSync a node from the latest Base Mainnet archive snapshot, or customize your own.CustomizeMainnet ArchiveFull Historical DataTotal Size4.2 TBBlock52,227,727Version2.5.2-dev (5877708)UpdatedOct 6, 2026$ base-reth-node download --chain base --archive --resumable","tokens":254,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267259197,"hash":"ec966fc51ed10074581fa693ccd055918ae41c9d"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/cheatsheet.html","domain":"docs.soliditylang.org","title":"Cheatsheet — Solidity 0.8.31-develop documentation","text":"Cheatsheet\n\n Edit on GitHub\n\nCheatsheet\n\nOrder of Precedence of Operators\nThe following is the order of precedence for operators, listed in order of evaluation.\n\nPrecedence\nDescription\nOperator\n\n1\nPostfix increment and decrement\n++, --\n\nNew expression\nnew <typename>\n\nArray subscripting\n<array>[<index>]\n\nMember access\n<object>.<member>\n\nFunction-like call\n<func>(<args...>)\n\nParentheses\n(<statement>)\n\n2\nPrefix increment and decrement\n++, --\n\nUnary minus\n-\n\nUnary operations\ndelete\n\nLogical NOT\n!\n\nBitwise NOT\n~\n\n3\nExponentiation\n**\n\n4\nMultiplication, division and modulo\n*, /, %\n\n5\nAddition and subtraction\n+, -\n\n6\nBitwise shift operators\n<<, >>\n\n7\nBitwise AND\n&\n\n8\nBitwise XOR\n^\n\n9\nBitwise OR\n|\n\n10\nInequality operators\n<, >, <=, >=\n\n11\nEquality operators\n==, !=\n\n12\nLogical AND\n&&\n\n13\nLogical OR\n||\n\n14\nTernary operator\n<conditional> ? <if-true> : <if-false>\n\nAssignment operators\n=, |=, ^=, &=, <<=,\n>>=, +=, -=, *=, /=,\n%=\n\n15\nComma operator\n,\n\nABI Encoding and Decoding Functions\n\nabi.decode(bytes memory encodedData, (...)) returns (...): ABI-decodes\nthe provided data. The types are given in parentheses as second argument.\nExample: (uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes))\nabi.encode(...) returns (bytes memory): ABI-encodes the given arguments\nabi.encodePacked(...) returns (bytes memory): Performs packed encoding of\nthe given arguments. Note that this encoding can be ambiguous!\nabi.encodeWithSelector(bytes4 selector, ...) returns (bytes memory): ABI-encodes\nthe given arguments starting from the second and prepends the given four-byte selector\nabi.encodeCall(function functionPointer, (...)) returns (bytes memory): ABI-encodes a call to functionPointer with the arguments found in the\ntuple. Performs a full type-check, ensuring the types match the function signature. Result equals abi.encodeWithSelector(functionPointer.selector, ...)\nabi.encodeWithSignature(string memory signature, ...) returns (bytes memory): Equivalent\nto abi.encodeWithSelector(bytes4(keccak256(bytes(signature))), ...)\n\nMembers of bytes and string\n\nbytes.concat(...) returns (bytes memory): Concatenates variable number of\narguments to one byte array\nstring.concat(...) returns (string memory): Concatenates variable number of\narguments to one string array\n\nMembers of address\n\n<address>.balance (uint256): balance of the Address in Wei\n<address>.code (bytes memory): code at the Address (can be empty)\n<address>.codehash (bytes32): the codehash of the Address\n<address>.call(bytes memory) returns (bool, bytes memory): issue low-level CALL with the given payload,\nreturns success condition and return data\n<address>.delegatecall(bytes memory) returns (bool, bytes memory): issue low-level DELEGATECALL with the given payload,\nreturns success condition and return data\n<address>.staticcall(bytes memory) returns (bool, bytes memory): issue low-level STATICCALL with the given payload,\nreturns success condition and return data\n<address payable>.send(uint256 amount) returns (bool): send given amount of Wei to Address,\nreturns false on failure (deprecated)\n<address payable>.transfer(uint256 amount): send given amount of Wei to Address, throws on failure (deprecated)\n\nBlock and Transaction Properties\n\nblockhash(uint blockNumber) returns (bytes32): hash of the given block - only works for 256 most recent blocks\nblobhash(uint index) returns (bytes32): versioned hash of the index-th blob associated with the current transaction.\nA versioned hash consists of a single byte representing the version (currently 0x01), followed by the last 31 bytes\nof the SHA256 hash of the KZG commitment (EIP-4844).\nReturns zero if no blob with the given index exists.\nblock.basefee (uint): current block’s base fee (EIP-3198 and EIP-1559)\nblock.blobbasefee (uint): current block’s blob base fee (EIP-7516 and EIP-4844)\nblock.chainid (uint): current chain id\nblock.coinbase (address payable): current block miner’s address\nblock.difficulty (uint): current block difficulty (EVM < Paris). For other EVM versions it behaves as a deprecated alias for block.prevrandao that will be removed in the next breaking release\nblock.gaslimit (uint): current block gaslimit\nblock.number (uint): current block number\nblock.prevrandao (uint): random number provided by the beacon chain (EVM >= Paris) (see EIP-4399 )\nblock.timestamp (uint): current block timestamp in seconds since Unix epoch\ngasleft() returns (uint256): remaining gas\nmsg.data (bytes): complete calldata\nmsg.sender (address): sender of the message (current call)\nmsg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)\nmsg.value (uint): number of wei sent with the message\ntx.gasprice (uint): gas price of the transaction\ntx.origin (address): sender of the transaction (full call chain)\n\nValidations and Assertions\n\nassert(bool condition): abort execution and revert state changes if condition is false (use for internal error)\nrequire(bool condition): abort execution and revert state changes if condition is false (use\nfor malformed input or error in external component)\nrequire(bool condition, string memory message): abort execution and revert state changes if\ncondition is false (use for malformed input or error in external component). Also provide error message.\nrevert(): abort execution and revert state changes\nrevert(string memory message): abort execution and revert state changes providing an explanatory string\n\nMathematical and Cryptographic Functions\n\nkeccak256(bytes memory) returns (bytes32): compute the Keccak-256 hash of the input\nsha256(bytes memory) returns (bytes32): compute the SHA-256 hash of the input\nripemd160(bytes memory) returns (bytes20): compute the RIPEMD-160 hash of the input\necrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address): recover address associated with\nthe public key from elliptic curve signature, return zero on error\naddmod(uint x, uint y, uint k) returns (uint): compute (x + y) % k where the addition is performed with\narbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\nmulmod(uint x, uint y, uint k) returns (uint): compute (x * y) % k where the multiplication is performed\nwith arbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\n\nContract-related\n\nthis (current contract’s type): the current contract, explicitly convertible to address or address payable\nsuper: a contract one level higher in the inheritance hierarchy\nselfdestruct(address payable recipient): send all funds to the given address and (only on EVMs before Cancun or when invoked within the transaction creating the contract) destroy the contract.\n\nType Information\n\ntype(C).name (string): the name of the contract\ntype(C).creationCode (bytes memory): creation bytecode of the given contract, see Type Information.\ntype(C).runtimeCode (bytes memory): runtime bytecode of the given contract, see Type Information.\ntype(I).interfaceId (bytes4): value containing the EIP-165 interface identifier of the given interface, see Type Information.\ntype(T).min (T): the minimum value representable by the integer type T, see Type Information.\ntype(T).max (T): the maximum value representable by the integer type T, see Type Information.\n\nFunction Visibility Specifiers\nopen in Remix\nfunction myFunction() <visibility specifier> returns (bool) {\n return true;\n}\n\npublic: visible externally and internally (creates a getter function for storage/state variables)\nprivate: only visible in the current contract\nexternal: only visible externally (only for functions) - i.e. can only be message-called (via this.func)\ninternal: only visible internally\n\nModifiers\n\npure for functions: Disallows modification or access of state.\nview for functions: Disallows modification of state.\npayable for functions: Allows them to receive Ether together with a call.\nconstant for state variables: Disallows assignment (except initialization), does not occupy storage slot.\nimmutable for state variables: Allows assignment at construction time and is constant when deployed. Is stored in code.\nanonymous for events: Does not store event signature as topic.\nindexed for event parameters: Stores the parameter as topic.\nvirtual for functions and modifiers: Allows the function’s or modifier’s\nbehavior to be changed in derived contracts.\noverride: States that this function, modifier or public state variable changes\nthe behavior of a function or modifier in a base contract.","tokens":2124,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267262508,"hash":"3e56db2fbc457ff45e0e88388641d4ce91369d4f"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/26","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 26 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n post by kz on Jan 30, 2018\n\n kz\n\n Hi,\nCan somebody please clarify this situation for me I must be missing something.\nLet’s assume Alice wants to send money to Bob.\nAlice creates a transaction that spends her 100 ETH worth of UTXOs and creates new UTXOs that Bob owns and sends that transaction to plasma chain operator/owner.\nPlasma chain operator forms an invalid block with a fraudulent transaction UTXO worth 100 ETH owned by him which he puts on index 0 and puts Alice’s transaction after his. After that plasma chain opeator commits merkle proof of the block to the main eth chain.\nAfter that plasma chain operator/owner publishes an exit worth 100ETH.\nAccording to this ordering plasma chain operator/owner could pull funds before Bob.\n\nIf Bob tried to exit the plasma chain, it would be too late.\nIf Alice tried to exit the plasma chain plasma chain operator could commit fraud proof that Alice spent her output with her signature confirming that.\nWhat is preventing this type of fraud?\n\n post by denett on Jan 31, 2018\n\n denett\n\nAlice does not sign off on the transaction if she sees the faulty block. (see step 4 of user behavior). Without her signature the operator cannot challenge her exit.\n\n post by kz on Jan 31, 2018\n\n kz\n\n Hi @denett\nThank you for your answer.\nIs this the 4th point you are referring to?\n\nCould you please help me to understand this better?\nI was under impression that this description means that Alice sends Bob a confirm message that proves she owns the original UTXOs she transferred, but that explanation sounded like I’m missing the point somewhere.\nCould you maybe explain in more detail what does that 4th point mean?\nAlice sends whom the confirm message? Plasma operator and Bob?\nDoes that confirm message end up in plasma chain or not?\nDoesn’t point 2 already contains signed transaction UTXO to prove Alice owned that UTXO?\n\n Load more posts below","tokens":2804,"squid":"ink-research","role":"Deep Scholar","at":1791267268927,"hash":"a8affdcc52a7836f72fd5464256f926895051af7"}
{"url":"https://blog.base.org/","domain":"blog.base.org","title":"Base","text":"BaseSep 1Request for Builders: Tokenized StocksTokenized stocks are now live on Base, opening a massive design space for programmable equities. Apply for Base Batches 004 to build next-gen neobrokerages, AI indexes, and meme-linked markets.BaseAug 24Stocks just got updated.Base exists to bring the world's economy onchain: a new financial system where any asset can be traded, borrowed against, and available globally, 24/7. Today, we took a big step towards that vision as tokenized stocks issued by Coinbase, built on the B20 standard, are now live natively on Base. These are real shares, held 1:1 by a regulated custodian, owned outright by whoever holds the token. Billions of dollars of traditional assets have already moved onchain, from fiat to treasuries, becau...BaseAug 19Introducing Base Batches 004Early-stage teams building on Base can apply for Batches 004 by Sept 9 to receive $100K funding and 8 weeks of mentorship.BaseJul 16Request for Builders: Funding the Future of Global FinanceThe Base Ecosystem Fund is supporting the next wave of founders building global onchain finance. We’re providing capital for builders in tokenization, credit, stablecoins, and prediction markets.BaseMay 29The Agentic Economy Is HereAgents Are Paying Customers NowAI agents are already useful. They can search, write, code, analyze, plan, and take action across apps. But they have been missing something every internet customer needs; a way to pay. In early 2025, the first onchain wave of agent adoption was primarily for social actions. They posted, replied, created media, traded attention, built communities, launched projects, and tested financial rails for the first time. And this wasn’t just a few rogue agents. Between O...BaseMay 26Introducing Base MCP: Your agent’s gateway to BaseConnect your Base Account to your agent and use simple prompts to swap, transfer, track your portfolio, and tap into the Base Ecosystem from chat. Launching with skills for Morpho, Moonwell, Aerodrome, Bankr, Avantis, Virtuals, and Uniswap, with more on the way.BaseApr 8Introducing Base Batches 003BaseMar 31Base 2026 Mission, Vision, and StrategyOur mission is to build a global economy that increases innovation, creativity, and freedom. In 2025, we set out to grow this economy across five pillars: builders, apps, ownership, markets, and bringing everyone onchain. We processed over $17T in stablecoin volume across 26 local currencies and 17 countries. We became the #1 onchain venue for BTC spot trading. We launched and grew the Base App in 140+ countries. We funded 50+ teams through Base Batches and saw new crypto native markets emerg...BaseDec 17The Base App Is Now Open To Everyone, Everywhere The new Base App is available in more than 140 countries. It’s an everything app for social, trading, and payments with countless ways to earn…BaseDec 4The Base-Solana bridge is now live, secured by Chainlink & CoinbaseThe Base-Solana Bridge is now live on mainnet. Secured by Chainlink CCIP alongside Coinbase, the bridge lets builders on Base support Solana assets in their apps, users trade Solana assets on Base, and communities tap into liquidity across Base and Solana. The bridge is now live on mainnet for builders to integrate, and rolling out for anyone to use in apps like Zora, Aerodrome, Virtuals, Flaunch, and Relay.BaseWritten bySubscribers440K+Posts67Collects268Subscribe Search...Ctrl+KBaseSign inSubscribe","tokens":856,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267270010,"hash":"519ce81c9c3ac9eba41fcdb62de103403847c058"}
{"url":"https://ethresear.ch/t/a-dex-on-plasma/1765/1","domain":"ethresear.ch","title":"A DEX on Plasma - Layer 2 / Plasma - Ethereum Research","text":"A DEX on Plasma \n\n Layer 2Plasma\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Apr 2018\n\n 1 / 17\n\n Apr 2018\n\n Sep 2018\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\n Plasma MVP and Plasma Cash seem to be focused on a UTXO based coin. Although the challenges we face are from a DEX point of view, solving them will benefit Plasma MVP and Plasma cash as well, so this discussion will help both projects.\nBasics\nPrice Time priority: Exchanges with an order book need to match orders with better price first, followed by orders placed earlier.\nExample: If there exist sell orders (id, price, qty) of (id1, 51, 3) (id2, 52, 1) (id3, 52, 2),\nwhen a buy (id4, 52, 5) is placed, orders with id1 and id2 are filled completely and id3 is filled partially.\nMarket Maker: A trader who provides liquidity on the platform. On many assets, the market maker is one party to almost every single trade.\nPlasma MVP Challenges\n1: UTXO shredding Price time priority execution means that larger UTXOs will be replaced with smaller UTXOs over time. The result of this is that all the system will rapidly tend to large number of UTXOs of the smallest possible size. A market maker’s account is likely to end up with a few thousand UTXO per hour. Gas cost for exit on individual shredded utxos may not justify its value. This will also impact the ability to take tiny fees.\n2: Exit delay too large Traders are accustomed to withdrawing in minutes or hours. A delay of several days could be a huge UX issue. Since large traders hedge their positions and require moving large amounts of funds from a winning exchange to a losing exchange, a 2 week delay will make it hard to attract any decent liquidity into the plasma DEX\n3: Exit window too small It is highly likely that on detecting a maleficent operator, a huge number of UTXOs wish to exit simultaneously. The current manner of exiting would require a user to exit every UTXO they have when they detect this. An average trader may make 5 trades a day, but a market maker is likely to make 100K trades and have over a million UTXOs. It is unlikely that one week is sufficient to get all these into the priority queue. Perhaps parameterizing the delay by the exit priority queue size is an option?\n4: Exit tx too large The gas required for finalizeExit (in OMG implementation) is likely to exceed the block limit preventing exit. At 8M gas limit and 80K gas per output finalized, a max of 100 outputs can exit. Breaking the finalizeExits into multiple batches may be a solution if we can do this without introducing race conditions.\nUpdate Batching using block numbers suggested here.\n5: Everyone needs to validate all Plasma blocks This is an onerous requirement on the users of Plasma MVP. This will also endanger UTXOs of people in natural disaster areas like Puerto Rico after hurricane Maria, who may be cut off from internet service for a while.\n6: Long commitment chains Every transfer of an UTXO increases the transaction size as it requires the full history from the original on-chain deposit. At high transaction rates and lots of tiny outputs to spend for a payment, with market maker trading with many parties, this could complicate logic and degrade performance.\nPlasma cash\n7: Penny wise Price time priority matching is impractical unless everyone holds all their coins in the smallest denomination.\nPossible Solutions\nAccount Model Most plasma issues are exacerbated because of the UTXO model. An account model eliminates many of these and lightens the impacts of the rest. Fixes UTXO shredding, Long commitment chains and Penny wise\nLimited Proof of Authority A POA chain can provide instant finality. As long as the POA is strictly limited by what it can do using fraud proofs on the root chain, we have the best of both worlds. Every bad state change should be detectable and proven on root chain by anyone watching the plasma chain. An error, intentional or otherwise should halt the chain, enabling users to withdraw their coins at leisure. Fixes Exit window too small\nRetiring outputs Requiring an output to be marked as retired would prevent that output from being included in any further transactions on the plasma chain. The only thing that can be done with a retired output is withdrawal on Root chain once retirement is confirmed on plasma block. This can eliminate the 1 week delay and improve UX. The priority queue exit would continue to exist in case the POA fails to include the retire on the plasma chain. Fixes Exit delay too large\nExit Delegation It should be possible to delegate an exit a coin to the depositor address to specialists. The delegate wont be able to spend the coin but they can only initiate a withdrawal ONLY to the depositors address. This removes the onerous requirement of having every user to monitor the chain themselves which is a barrier to entry. Fixes Everyone needs to validate all blocks\nWe have a version of plasma that incorporates the above and I will post our spec in a different thread once we work out the final kinks.\n\n Minimal Viable Plasma\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by kfichter on Apr 18, 2018\n\n kfichter\n\nCan you elaborate on this?\n\nCould you also provide examples of the types of bad state changes that would be provable on-chain? The main attack vector against Minimal Viable Plasma is creating an “out of thin air UTXO” and withholding the block (but still publishing to the main chain). This appears to be a valid state transition and is the reason why we need the priority queue.\n\nWhat happens if the POA marks a spent UTXO as retired and attempts to withdraw?\n\nI reposted some of my notes re: Exit Delegation here Plasma (+ Delegated Exits), feedback is welcome.\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\n UTXO shredding: Lets say you deposited 10 eth can now have one UTXO of denomination 10. You put in a buy order for 3000 LEV tokens at price 300. The exchange needs to match the best price against your order. If the best price order is of size 30 LEV, the exchange needs to create a partial match, splitting your 10 eth into 0.1 eth and 9.9 eth, matching the 0.1 eth to the 30 LEV and keeping 2970 LEV open. You now have two UTXOs, one for 9.9 eth and one for 30 LEV. A few more matches later, your order is filled and you have UTXOs of 30 LEV, 70 LEV, 400 LEV, 500 LEV and 2000 LEV.\nNow if you decide to sell the 2000 LEV UTXO, the same process occurs in reverse. You receive 0.01 eth, 0.005 eth, 0.3 eth and so on.\nYou started with 1 UTXO and ended up with 25 or so with a single buy and sell. Repeat a few more times and you will only have many tiny UTXOs.\nThe only way you will not increase the number of UTXO is if you sold the smallest allowed UTXO.\nBad state changes For an account based plasma, the account is in state s1 and goes to state s2, it requires certain proof on chain. For example, your balance was 0.32 and decreased to 0.22, then it can only occur if you signed away 0.10 to someone else. At the same time the recipients balance should increase exactly by 0.10. This is sort of how eth works currently.\nWithholding is not solved by our model but its detected by all and a supermajority can vote to halt the chain. The difference is that on a halted chain, there’s no rush to exit.\n\nWhat happens if the POA marks a spent UTXO as retired and attempts to withdraw?\n\nProof of double spend (spendtx, retiretx) would be submitted that would invalidate the withdraw and halt the chain.\n\nA (likely) better delegated exit model is to require users to specify a named exiter or list of exiters. The root contract could maintain some mapping (address => address) or (address => (address => boolean)) that specifies a user’s permitted exiters.\n\nThis is a simple, intuitive and robust approach. I don’t think trust issues are a big factor since smaller players can delegate to other businesses and the truly paranoid can run a chain monitoring script with only the withdrawal delegation key on a cheap VPS.\n\n post by kfichter on Apr 18, 2018\n\n kfichter\n\nI think in these cases it would make sense for the UTXO owner to continuously make transactions that minimize their UTXOs. You can convert all of your UTXOs into a single UTXO in log(n) blocks. A simulated account model on top of UTXOs could also address this issue.\n\nHow long would you imagine a user would have to invalidate the withdrawal?\n\nNow that I think about it, there’s actually a better approach that’s entirely on the child chain:\n\nUsers submit a special transaction to the child chain that names the current set of exitor.\nAnyone can attempt to submit an exit for a user on the root chain.\nOther users can submit a proof that the person exiting isn’t in the user’s most recent exitor set.\nThe exitor can either challenge with a more recent exitor set or, after a period of time, lose their deposit.\n\nThis way we don’t need users to make root-chain txs in order to update the exitor set.\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\nYou can convert all of your UTXOs into a single UTXO in log(n) blocks\n\nThis is a cumbersome fix soaking up transaction bandwidth and fees whose only purpose is to address a design flaw. A good design should not have such burden of upkeep.\nRegardless, since trading is a continuous activity, most traders will not pay to consolidate their UTXOs which will fragment again in a few hours.\nAlso note the burden on the exchange and plasma chain: a fill with 100 small UTXOs will soak up 100x the bandwidth of an account model.\n\nHow long would you imagine a user would have to invalidate the withdrawal?\n\nActually, anyone can invalidate the withdraw since both the spend and retire are on plasma chain. If properly incentivized, validators would rush to claim the bounty as soon as the fraudulent withdrawal shows up.\n\nwe don’t need users to make root-chain txs in order to update the exitor set.\n\nTrue. However, updating exitors is probably so rare that its a tiny percent of the rootchain load and the added interactive proof is not worth the hassle.\n\n post by vbuterin on Apr 19, 2018\n\n vbuterin\n\nNot a problem; users can sell their withdrawals-in-progress to third parties, getting coins out immediately and letting the parties that are most willing to lock up their capital take over the responsibility of waiting.\n\n3: Exit window too small\n\nThis is actually significantly less of an issue with Plasma Cash, because each user can just wait until they actually need their money, or their own coin specifically gets attacked, and attacking everyone’s coins requires the attacker themselves to send a very large number of transactions.\n\n4: Exit tx too large The gas required for finalizeExit (in OMG implementation) is likely to exceed the block limit preventing exit. At 8M gas limit and 80K gas per output finalized, a max of 100 outputs can exit.\n\nHow is that a problem? A max of 100 outputs can exit per block. Of course if you have more than 100 outputs you would just send multiple transactions.\n\n5: Everyone needs to validate all Plasma blocks\n\nOnce again, Plasma Cash solves this. If a user has c coins, and there are N coins total, the user’s load is only about c * log(N) per block.\n\n6: Long commitment chains Every transfer of an UTXO increases the transaction size as it requires the full history from the original on-chain deposit.\n\nThis is true only in Plasma Cash; in MVP you don’t need to pass around history data as everyone has the entire Plasma chain anyway. To mitigate this in Plasma Cash, you can add a mechanism where you can “commit” a coin to chain (think of this as an optimized equivalent of withdrawing and then immediately re-depositing), using one on-chain transaction to reset the history length of the coin to zero.\n\n post by kladkogex on Apr 19, 2018\n\n kladkogex\n\n Our startup is working on a solution that has overlaps with plasma idea-wise (we also use map-reduce philosophy) but our chains are EVM-compatible asynchronous consensus chains (not UTXO).\nWe also use a bit different mechanism (threshold signatures) to communicate between the chains.\nWe hope to become a good member of Ethereum community once we release our test network on Oct 1, and contribute to well being of Ethereum ecosystem as much as we can !\nSince you are interested in running DEX let me know if you are interested in trying our our prototype once it is ready - since we run EVM on our chains we target applications such as DEX.\n\n post by bharathrao on Apr 19, 2018\n\n bharathrao\n\nIs this mechanism explained anywhere? Im guessing the user would transfer his UTXO to the service provider and get paid out of band on a different chain? Would this be trustless? Adding third parties to solve a problem reduces overall appeal. Pretty much every large trader has told me that they love centralized exchanges precisely because they only have one party to deal with, whose risk characteristics are very well known. Our goal is to model plasma as a single entity that anyone needs to interact with just like eth/btc/ltc etc.\n\nthe user’s load is only about c * log(N) per block\n\nThe emphasis is on everyone not all blocks. Ideally, any one who can see plasma blocks should be able to enforce correctness, not just the victim. In case of ethereum for example, miners will reject an invalid transaction and the responsibility to prevent unauthorized spends does not rest solely on the owner.\n\n post by bharathrao on Apr 19, 2018\n\n bharathrao\n\n kladkogex\n\n We are most definitely interested.\nI’ll also post our Account based plasma spec which may be of interest to other folks building DEXes\n\n post by vbuterin on Apr 19, 2018\n\n vbuterin\n\nThe third party in question could possibly be the exchange themselves; and yes, in either case it would be trustless. A withdrawal-in-progress is an on-chain asset, so there’s no technical obstacle to changing its ownership, and there’s zero risk to the seller, who can just get their money out immediately. The buyer would just need to have themselves verified that the coin that is exiting is legitimate, to be sure that the withdrawal could not be challenged.\n\nThe emphasis is on everyone not all blocks.\n\nKeep in mind that maintaining security for a user only requires logging on once per withdrawal period. It definitely does not require you to be online anything close to constantly.\n\n post by bharathrao on Apr 21, 2018\n\n bharathrao\n\nRight, we could do this as a time arbitrage implemented as a deposit lock plus swap\nstep 1. the exiter requests a UTXO time arbitrage\nstep 2. A time arbitrageur deposits UTXO size minus fee timelocked\nstep 3. Atomic swap(?) of Plasma UTXO to arbitrageur and onchain UTXO to exiter\nstep 3. If exiter did not exchange within N blocks the deposit is released.\nAn issue here is that when market is moving fast, the arbitrageur probably will run out of funds on chain because most of the money is a uni-directional move (out of plasma chain).\nIdeally, there are only two roles: a buyer and seller. The plasma contract which is for all practical purposes a public utility does the rest. Requiring an arbitrageur to exist who is ready with large number of on-chain funds at any time makes it fundamentally unattractive to be a plasma market maker. This is assuming there are no fees. If the arbitrageur tacks on fees, then it may not even be economical to market make on the plasma chain.\nFundamentally, Im skeptical of introducing brand new roles to solve every new problem because the more kinds of roles that are required for the smooth functioning of the system, the less reliable and stable it is. To me, this feels like a hack. This is just us claiming “lets put a banker who does XXX” to address a hole in the system design.\nA robust elegant design is like that of say ethereum: You only need two actors. A sender and receiver. You only need the sender to be online. Such systems are robust. Risk is flat. A system that require others to run an ancillary business model already in place for viablity is a weak fragile system in my opinion.\n\n 3 months later\n\n post by zack-bitcoin on Jul 19, 2018\n\n zack-bitcoin\n\n I wrote a trustless market enforced using channels.\nFor the “price time priority” problem, I have the market match trades in single price batches.\nIt is better to only use 2-party channels for this problem, and instead of trading subcurrencies directly, to trade a synthetic asset priced in Eth.\nYou can connect many 2-party channels into a market using techniques similar to hashlocking.\nYou can recover liquidity locked in network hubs by trustlessly moving bets from indirect paths to direct ones. Hashlocking allows for this.\n\n post by bharathrao on Jul 19, 2018\n\n bharathrao\n\nHow can this prevent the matcher from excluding certain orders from a batch and matching them in a future batch where the price is adverse to the order?\n\n post by zack-bitcoin on Jul 19, 2018\n\n zack-bitcoin\n\n The server running the market is required to declare the price periodically.\nIf the server fails to publish a price for too much time, or if the server publishes prices too frequently, then the server loses every bet it has in the market.\nIf I can prove that the server published prices too frequently, or if I can prove that the server didn’t publish prices frequently enough, then I win the bet. It doesn’t matter which way I bet, I still win.\nBets are matched at the earliest price possible.\nSo if you are willing to pay up to 0.6 per share, then you will match at the earliest price below 0.6.\nI wrote more about this here: https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md\n\n 29 days later\n\n post by Equilibrium94 on Aug 17, 2018\n\n Equilibrium94\n\n kladkogex\n\n I’m interested in that as well. Do you guys have a whitepaper or a demo?\nThanks!\n\n post by MihailoBjelic on Aug 18, 2018\n\n MihailoBjelic\n\nWhat exactly do you consider a supermajority? Can you please explain how this works?\n\n 1 month later\n\n post by tuna on Sep 21, 2018\n\n tuna\n\n@kladkogex I am interested. Would love to see a link access to what you have done on this. Many thanks.\n\n Gluon Plasma Full Spec for Non-custodial Exchanges\n\n Powered by Discourse","tokens":4549,"squid":"ink-research","role":"Deep Scholar","at":1791267279356,"hash":"b79742b2680bcb219a7c33f5b0de91c3b99301a3"}
{"url":"https://ethresear.ch/t/a-dex-on-plasma/1765/17","domain":"ethresear.ch","title":"A DEX on Plasma - Layer 2 / Plasma - Ethereum Research","text":"Layer 2Plasma\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n Apr 2018\n\n 17 / 17\n\n Sep 2018\n\n Sep 2018\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\n Plasma MVP and Plasma Cash seem to be focused on a UTXO based coin. Although the challenges we face are from a DEX point of view, solving them will benefit Plasma MVP and Plasma cash as well, so this discussion will help both projects.\nBasics\nPrice Time priority: Exchanges with an order book need to match orders with better price first, followed by orders placed earlier.\nExample: If there exist sell orders (id, price, qty) of (id1, 51, 3) (id2, 52, 1) (id3, 52, 2),\nwhen a buy (id4, 52, 5) is placed, orders with id1 and id2 are filled completely and id3 is filled partially.\nMarket Maker: A trader who provides liquidity on the platform. On many assets, the market maker is one party to almost every single trade.\nPlasma MVP Challenges\n1: UTXO shredding Price time priority execution means that larger UTXOs will be replaced with smaller UTXOs over time. The result of this is that all the system will rapidly tend to large number of UTXOs of the smallest possible size. A market maker’s account is likely to end up with a few thousand UTXO per hour. Gas cost for exit on individual shredded utxos may not justify its value. This will also impact the ability to take tiny fees.\n2: Exit delay too large Traders are accustomed to withdrawing in minutes or hours. A delay of several days could be a huge UX issue. Since large traders hedge their positions and require moving large amounts of funds from a winning exchange to a losing exchange, a 2 week delay will make it hard to attract any decent liquidity into the plasma DEX\n3: Exit window too small It is highly likely that on detecting a maleficent operator, a huge number of UTXOs wish to exit simultaneously. The current manner of exiting would require a user to exit every UTXO they have when they detect this. An average trader may make 5 trades a day, but a market maker is likely to make 100K trades and have over a million UTXOs. It is unlikely that one week is sufficient to get all these into the priority queue. Perhaps parameterizing the delay by the exit priority queue size is an option?\n4: Exit tx too large The gas required for finalizeExit (in OMG implementation) is likely to exceed the block limit preventing exit. At 8M gas limit and 80K gas per output finalized, a max of 100 outputs can exit. Breaking the finalizeExits into multiple batches may be a solution if we can do this without introducing race conditions.\nUpdate Batching using block numbers suggested here.\n5: Everyone needs to validate all Plasma blocks This is an onerous requirement on the users of Plasma MVP. This will also endanger UTXOs of people in natural disaster areas like Puerto Rico after hurricane Maria, who may be cut off from internet service for a while.\n6: Long commitment chains Every transfer of an UTXO increases the transaction size as it requires the full history from the original on-chain deposit. At high transaction rates and lots of tiny outputs to spend for a payment, with market maker trading with many parties, this could complicate logic and degrade performance.\nPlasma cash\n7: Penny wise Price time priority matching is impractical unless everyone holds all their coins in the smallest denomination.\nPossible Solutions\nAccount Model Most plasma issues are exacerbated because of the UTXO model. An account model eliminates many of these and lightens the impacts of the rest. Fixes UTXO shredding, Long commitment chains and Penny wise\nLimited Proof of Authority A POA chain can provide instant finality. As long as the POA is strictly limited by what it can do using fraud proofs on the root chain, we have the best of both worlds. Every bad state change should be detectable and proven on root chain by anyone watching the plasma chain. An error, intentional or otherwise should halt the chain, enabling users to withdraw their coins at leisure. Fixes Exit window too small\nRetiring outputs Requiring an output to be marked as retired would prevent that output from being included in any further transactions on the plasma chain. The only thing that can be done with a retired output is withdrawal on Root chain once retirement is confirmed on plasma block. This can eliminate the 1 week delay and improve UX. The priority queue exit would continue to exist in case the POA fails to include the retire on the plasma chain. Fixes Exit delay too large\nExit Delegation It should be possible to delegate an exit a coin to the depositor address to specialists. The delegate wont be able to spend the coin but they can only initiate a withdrawal ONLY to the depositors address. This removes the onerous requirement of having every user to monitor the chain themselves which is a barrier to entry. Fixes Everyone needs to validate all blocks\nWe have a version of plasma that incorporates the above and I will post our spec in a different thread once we work out the final kinks.\n\n Minimal Viable Plasma\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n 7\n\n 2\n\n 2\n\n 2\n\n read \n\n 7\n min\n\n post by kfichter on Apr 18, 2018\n\n kfichter\n\nCan you elaborate on this?\n\nCould you also provide examples of the types of bad state changes that would be provable on-chain? The main attack vector against Minimal Viable Plasma is creating an “out of thin air UTXO” and withholding the block (but still publishing to the main chain). This appears to be a valid state transition and is the reason why we need the priority queue.\n\nWhat happens if the POA marks a spent UTXO as retired and attempts to withdraw?\n\nI reposted some of my notes re: Exit Delegation here Plasma (+ Delegated Exits), feedback is welcome.\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\n UTXO shredding: Lets say you deposited 10 eth can now have one UTXO of denomination 10. You put in a buy order for 3000 LEV tokens at price 300. The exchange needs to match the best price against your order. If the best price order is of size 30 LEV, the exchange needs to create a partial match, splitting your 10 eth into 0.1 eth and 9.9 eth, matching the 0.1 eth to the 30 LEV and keeping 2970 LEV open. You now have two UTXOs, one for 9.9 eth and one for 30 LEV. A few more matches later, your order is filled and you have UTXOs of 30 LEV, 70 LEV, 400 LEV, 500 LEV and 2000 LEV.\nNow if you decide to sell the 2000 LEV UTXO, the same process occurs in reverse. You receive 0.01 eth, 0.005 eth, 0.3 eth and so on.\nYou started with 1 UTXO and ended up with 25 or so with a single buy and sell. Repeat a few more times and you will only have many tiny UTXOs.\nThe only way you will not increase the number of UTXO is if you sold the smallest allowed UTXO.\nBad state changes For an account based plasma, the account is in state s1 and goes to state s2, it requires certain proof on chain. For example, your balance was 0.32 and decreased to 0.22, then it can only occur if you signed away 0.10 to someone else. At the same time the recipients balance should increase exactly by 0.10. This is sort of how eth works currently.\nWithholding is not solved by our model but its detected by all and a supermajority can vote to halt the chain. The difference is that on a halted chain, there’s no rush to exit.\n\nWhat happens if the POA marks a spent UTXO as retired and attempts to withdraw?\n\nProof of double spend (spendtx, retiretx) would be submitted that would invalidate the withdraw and halt the chain.\n\nA (likely) better delegated exit model is to require users to specify a named exiter or list of exiters. The root contract could maintain some mapping (address => address) or (address => (address => boolean)) that specifies a user’s permitted exiters.\n\nThis is a simple, intuitive and robust approach. I don’t think trust issues are a big factor since smaller players can delegate to other businesses and the truly paranoid can run a chain monitoring script with only the withdrawal delegation key on a cheap VPS.\n\n post by kfichter on Apr 18, 2018\n\n kfichter\n\nI think in these cases it would make sense for the UTXO owner to continuously make transactions that minimize their UTXOs. You can convert all of your UTXOs into a single UTXO in log(n) blocks. A simulated account model on top of UTXOs could also address this issue.\n\nHow long would you imagine a user would have to invalidate the withdrawal?\n\nNow that I think about it, there’s actually a better approach that’s entirely on the child chain:\n\nUsers submit a special transaction to the child chain that names the current set of exitor.\nAnyone can attempt to submit an exit for a user on the root chain.\nOther users can submit a proof that the person exiting isn’t in the user’s most recent exitor set.\nThe exitor can either challenge with a more recent exitor set or, after a period of time, lose their deposit.\n\nThis way we don’t need users to make root-chain txs in order to update the exitor set.\n\n post by bharathrao on Apr 18, 2018\n\n bharathrao\n\nYou can convert all of your UTXOs into a single UTXO in log(n) blocks\n\nThis is a cumbersome fix soaking up transaction bandwidth and fees whose only purpose is to address a design flaw. A good design should not have such burden of upkeep.\nRegardless, since trading is a continuous activity, most traders will not pay to consolidate their UTXOs which will fragment again in a few hours.\nAlso note the burden on the exchange and plasma chain: a fill with 100 small UTXOs will soak up 100x the bandwidth of an account model.\n\nHow long would you imagine a user would have to invalidate the withdrawal?\n\nActually, anyone can invalidate the withdraw since both the spend and retire are on plasma chain. If properly incentivized, validators would rush to claim the bounty as soon as the fraudulent withdrawal shows up.\n\nwe don’t need users to make root-chain txs in order to update the exitor set.\n\nTrue. However, updating exitors is probably so rare that its a tiny percent of the rootchain load and the added interactive proof is not worth the hassle.\n\n post by vbuterin on Apr 19, 2018\n\n vbuterin\n\nNot a problem; users can sell their withdrawals-in-progress to third parties, getting coins out immediately and letting the parties that are most willing to lock up their capital take over the responsibility of waiting.\n\n3: Exit window too small\n\nThis is actually significantly less of an issue with Plasma Cash, because each user can just wait until they actually need their money, or their own coin specifically gets attacked, and attacking everyone’s coins requires the attacker themselves to send a very large number of transactions.\n\n4: Exit tx too large The gas required for finalizeExit (in OMG implementation) is likely to exceed the block limit preventing exit. At 8M gas limit and 80K gas per output finalized, a max of 100 outputs can exit.\n\nHow is that a problem? A max of 100 outputs can exit per block. Of course if you have more than 100 outputs you would just send multiple transactions.\n\n5: Everyone needs to validate all Plasma blocks\n\nOnce again, Plasma Cash solves this. If a user has c coins, and there are N coins total, the user’s load is only about c * log(N) per block.\n\n6: Long commitment chains Every transfer of an UTXO increases the transaction size as it requires the full history from the original on-chain deposit.\n\nThis is true only in Plasma Cash; in MVP you don’t need to pass around history data as everyone has the entire Plasma chain anyway. To mitigate this in Plasma Cash, you can add a mechanism where you can “commit” a coin to chain (think of this as an optimized equivalent of withdrawing and then immediately re-depositing), using one on-chain transaction to reset the history length of the coin to zero.\n\n post by kladkogex on Apr 19, 2018\n\n kladkogex\n\n Our startup is working on a solution that has overlaps with plasma idea-wise (we also use map-reduce philosophy) but our chains are EVM-compatible asynchronous consensus chains (not UTXO).\nWe also use a bit different mechanism (threshold signatures) to communicate between the chains.\nWe hope to become a good member of Ethereum community once we release our test network on Oct 1, and contribute to well being of Ethereum ecosystem as much as we can !\nSince you are interested in running DEX let me know if you are interested in trying our our prototype once it is ready - since we run EVM on our chains we target applications such as DEX.\n\n post by bharathrao on Apr 19, 2018\n\n bharathrao\n\nIs this mechanism explained anywhere? Im guessing the user would transfer his UTXO to the service provider and get paid out of band on a different chain? Would this be trustless? Adding third parties to solve a problem reduces overall appeal. Pretty much every large trader has told me that they love centralized exchanges precisely because they only have one party to deal with, whose risk characteristics are very well known. Our goal is to model plasma as a single entity that anyone needs to interact with just like eth/btc/ltc etc.\n\nthe user’s load is only about c * log(N) per block\n\nThe emphasis is on everyone not all blocks. Ideally, any one who can see plasma blocks should be able to enforce correctness, not just the victim. In case of ethereum for example, miners will reject an invalid transaction and the responsibility to prevent unauthorized spends does not rest solely on the owner.\n\n post by bharathrao on Apr 19, 2018\n\n bharathrao\n\n kladkogex\n\n We are most definitely interested.\nI’ll also post our Account based plasma spec which may be of interest to other folks building DEXes\n\n post by vbuterin on Apr 19, 2018\n\n vbuterin\n\nThe third party in question could possibly be the exchange themselves; and yes, in either case it would be trustless. A withdrawal-in-progress is an on-chain asset, so there’s no technical obstacle to changing its ownership, and there’s zero risk to the seller, who can just get their money out immediately. The buyer would just need to have themselves verified that the coin that is exiting is legitimate, to be sure that the withdrawal could not be challenged.\n\nThe emphasis is on everyone not all blocks.\n\nKeep in mind that maintaining security for a user only requires logging on once per withdrawal period. It definitely does not require you to be online anything close to constantly.\n\n post by bharathrao on Apr 21, 2018\n\n bharathrao\n\nRight, we could do this as a time arbitrage implemented as a deposit lock plus swap\nstep 1. the exiter requests a UTXO time arbitrage\nstep 2. A time arbitrageur deposits UTXO size minus fee timelocked\nstep 3. Atomic swap(?) of Plasma UTXO to arbitrageur and onchain UTXO to exiter\nstep 3. If exiter did not exchange within N blocks the deposit is released.\nAn issue here is that when market is moving fast, the arbitrageur probably will run out of funds on chain because most of the money is a uni-directional move (out of plasma chain).\nIdeally, there are only two roles: a buyer and seller. The plasma contract which is for all practical purposes a public utility does the rest. Requiring an arbitrageur to exist who is ready with large number of on-chain funds at any time makes it fundamentally unattractive to be a plasma market maker. This is assuming there are no fees. If the arbitrageur tacks on fees, then it may not even be economical to market make on the plasma chain.\nFundamentally, Im skeptical of introducing brand new roles to solve every new problem because the more kinds of roles that are required for the smooth functioning of the system, the less reliable and stable it is. To me, this feels like a hack. This is just us claiming “lets put a banker who does XXX” to address a hole in the system design.\nA robust elegant design is like that of say ethereum: You only need two actors. A sender and receiver. You only need the sender to be online. Such systems are robust. Risk is flat. A system that require others to run an ancillary business model already in place for viablity is a weak fragile system in my opinion.\n\n 3 months later\n\n post by zack-bitcoin on Jul 19, 2018\n\n zack-bitcoin\n\n I wrote a trustless market enforced using channels.\nFor the “price time priority” problem, I have the market match trades in single price batches.\nIt is better to only use 2-party channels for this problem, and instead of trading subcurrencies directly, to trade a synthetic asset priced in Eth.\nYou can connect many 2-party channels into a market using techniques similar to hashlocking.\nYou can recover liquidity locked in network hubs by trustlessly moving bets from indirect paths to direct ones. Hashlocking allows for this.\n\n post by bharathrao on Jul 19, 2018\n\n bharathrao\n\nHow can this prevent the matcher from excluding certain orders from a batch and matching them in a future batch where the price is adverse to the order?\n\n post by zack-bitcoin on Jul 19, 2018\n\n zack-bitcoin\n\n The server running the market is required to declare the price periodically.\nIf the server fails to publish a price for too much time, or if the server publishes prices too frequently, then the server loses every bet it has in the market.\nIf I can prove that the server published prices too frequently, or if I can prove that the server didn’t publish prices frequently enough, then I win the bet. It doesn’t matter which way I bet, I still win.\nBets are matched at the earliest price possible.\nSo if you are willing to pay up to 0.6 per share, then you will match at the earliest price below 0.6.\nI wrote more about this here: https://github.com/zack-bitcoin/amoveo/blob/master/docs/design/limit_order_in_channel.md\n\n 29 days later\n\n post by Equilibrium94 on Aug 17, 2018\n\n Equilibrium94\n\n kladkogex\n\n I’m interested in that as well. Do you guys have a whitepaper or a demo?\nThanks!\n\n post by MihailoBjelic on Aug 18, 2018\n\n MihailoBjelic\n\nWhat exactly do you consider a supermajority? Can you please explain how this works?\n\n 1 month later\n\n post by tuna on Sep 21, 2018\n\n tuna\n\n@kladkogex I am interested. Would love to see a link access to what you have done on this. Many thanks.\n\n Gluon Plasma Full Spec for Non-custodial Exchanges\n\n Powered by Discourse","tokens":4544,"squid":"ink-research","role":"Deep Scholar","at":1791267290071,"hash":"1f3a698f750f91ac784e4479afbab7d13d356255"}
{"url":"https://forum.pyth.network/t/community-council-term-2-six-month-mid-term-report/2704","domain":"forum.pyth.network","title":"Community Council Term 2: Six-Month Mid-Term Report - Community Council - Pyth DAO","text":"Community Council Term 2: Six-Month Mid-Term Report \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 14\n min\n\n Sep 19\n\n 1 / 5\n\n Sep 20\n\n 9d ago\n\n post by Chop on Sep 19\n\n Chop\n\n Community Council Term 2: Six-Month Mid-Term Report\nPeriod covered: April to September 2026. Figures current as of 7 September 2026 unless stated. Budget figures as of 27 August 2026.\n\n1. State of play\nCommunity Council Term 2 picks up where Term 1 left off. The term leans into community incentivisation programs and the reach of the Pyth brand. The council has also been developing ways to push the Pyth product into more B2C form factors to help demonstrate its usefulness and market positioning to consumers. This is most visible in PythFeeds.com, the Pyth Wheel and PythScan, all covered below.\nTerm 2 runs on an 8,000,000 PYTH twelve-month budget, with half paid in Q1.\nTwo of the three community products in this report came out of the March Community Hackathon: PythFeeds (Samurai), and Market DVR (Wattson), which has since developed into PythScan.\n\n2. Content rewards system\nThe community deliberately shifted from a catch-all scattergun strategy to a much more defined, heavily community-first approach. As a result, engagement on X and beyond has trended up over the past six months.\nWhy the ‘Missions’ engine was retired\nThe term started on the broadcast Missions engine and ended in July. These are the numbers which forced the change:\n\nMonth\nPosts\nAuthors\nImpressions\nPYTH paid\n\nApril\n465\n170\n730K\n~330,000\n\nMay\n5,811\n1,969\n4.75M\n~330,000\n\nJune\n6,143\n2,395\n4.05M\n~330,000\n\nImpressions per post fell from 1,570 (April) to 817 (May) to 659 (June). June added 22% more authors for 15% fewer impressions. Marginal participants added volume rather than reach.\nThe relaunch, 6 July\nThe creator system was relaunched as one path:\n\nPost in #content-hub, or have the PythPulse tool find and surface your tweet.\nEarn Impact Awards, administered by community leaders. Leaders are given a monthly allocation which is given away in full, with publicly auditable reasons.\nGet hand-picked as an Aristophanes: monthly PYTH stipend, 1.8x Impact Award multiplier, free Pyth Wheel spins, two-month trial then tenure.\nPublish in #impact-ops, which everyone can read and only Aristophanes and community leaders can post to.\n\nCommunity creators and leaders receive their own stipends, as well as multipliers on the Impact Awards they receive. Selection is based on content quality and track record ahead of follower count. The budget cap is roughly 15 contracted creators.\nWhat changed in the output\nCore community of 197 tracked handles, Pyth-related posts on X, retweets excluded.\n\nMonth\nCommunity impressions\n\nMarch\n368K\n\nApril\n354K\n\nMay\n373K\n\nJune\n327K\n\nJuly\n370K\n\nAugust\n605K\n\nAugust is 69% above the March to July average, with zero ‘catch-all’ missions running.\n\nMarch to August total: 2.40M impressions, 104.6K engagement (4.4% engagement rate), 42 core members active per month on average, 27 active every single month.\n1 August to 7 September: 46 core members active, 1,754 Pyth-related items, 695K views, 24.1K engagement.\nImpact Awards: July delivered 316 awards / 13,530 coins, against June’s 45 / 1,529, and effectively dormant in April and May.\n\nThe trade-off\nThe “everyone” contributor program peaked at 4.1M views in May and fell under 1M once the program was turned off. Core output went the other way.\nThis was a very deliberate tradeoff and the numbers prove why.\nEngagement was up, but the quality was down significantly. The influx of bots on X through this period was an absolute scourge: automated and AI-generated replies inflated every metric while adding nothing, and they actively deterred genuine readers, who stopped engaging (rightfully) with content they deemed to be AI Slop. Broadcast incentives incentivised the behaviour. By June, 2,395 authors were producing 659 impressions per post, against 1,570 in April, on an openly exploited sybil surface.\nEngagement from core community members, meanwhile, has grown throughout. The contracted creator system produces fewer impressions from identified people at a 4.4% engagement rate, inside a system where every award is published with a reason and every recipient is known.\nHeadline reach is down. Reach that survives contact with a sybil filter is up, and it is now produced by 46 people we can name.\nContent Program budget: 1,090,670 of 3,000,000 PYTH used (36.4%). This is where the term’s remaining headroom sits.\n\n3. Community stats\n\nDiscord: 70,002 members. New joiners still in server: April 357, May 605, June 573, July 543. 1,165 unique members posted in the trailing 30 days to 3 August, across 60,977 messages.\nX, core community, March to August: 2.40M impressions, 104.6K engagement.\nPythPulse, the live mention scanner feeding the community Discord, launched 17 July. 2,123 Pyth mentions scanned in the first fortnight, 891 surfaced. An August upgrade added all-language coverage with inline English translation.\n\n4. Pythenians 2.0\nGovernance thread: Pythenians II. Scope of work & budget request\nThree forum stages, all under Community Council management, all led by Noname:\n7 May, Pythenians 2.0 proposal (44 posts, 1,397 views, 100 likes). Treasury moved under a 6-of-7 Council multisig: 212 SOL staked (115 Helius, 97 Jito), 185 SOL liquid, ~$71,700 USDC, 69,000 PYTH. Collection 4,669 total, 3,682 minted. Pythenians Week discontinued in favour of Pyth Wheel, Pythentity and missions.\n2 June, Key Proposal summary (15 posts, 485 views). Mint closed permanently at 3,682. Burn-to-level runs until the collection reaches 1,750, then stops forever. Three levels: Level 2 = hold one plus burn one; Level 3 = two more burned. Burn fees paid in PYTH, amount TBA. Pythentity badge system. Visual upgrade per level.\n30 July, scope of work and budget request (11 posts, 426 views, 21 likes). One-month build. Team: Noname (project manager), Samurai (full stack), Kirito (graphic design), Sunshine (original collection artist). Budget: $2,000 from the Pythenians treasury, $500 per person. Deliverables: mint closure and collection authority under Council control, automated metadata and art regeneration on every level-up, handcrafted Level 2 and Level 3 art, and the PytheniansHub.\nFor context on cost: a full collection overhaul, a custom burn-and-upgrade dApp, and new artwork across two tiers, delivered for $2,000 total, by community members.\nStatus: community response unanimous in support.\nOpen question from the thread (31 August): who maintains the Hub after month one. The Council will run a nomination and procurement process to find community participants willing to operate the PytheniansHub. Anyone interested in getting involved is welcome to reach out or reply below.\n\n5. Governance proposals\n5.1 Community custom indices on Pyth Pro\nThread: Idea Proposal: Community Custom Indices on Pyth Pro — SCP, 16 August; 10 posts, 164 views, 20 likes\nThe idea. Let creators define baskets of existing Pyth feeds with weights and methodology, stake PYTH to create and keep an index live (10,000 to 50,000 PYTH suggested), and publish them as labelled “Community Index” feeds on Pyth Pro for venues such as Hyperliquid and TradeXYZ. Revenue share suggested at 40 to 60% creator, 20 to 30% DAO. Preferred technical path is Pyth Pro computing the index natively; the fallback is a third-party backend. Stated blocker: community members cannot currently publish feeds on Pro.\nFeedback from the thread. Slashing and a higher stake plus a verification layer by Council, DAO or Douro (Mersault); a formal wind-down process so unstaking cannot force-close open positions, a recurring burned maintenance fee instead of one lock, no manual rebalancing after launch, and a smaller creator split (Lowkeigh); an interim upvotable “index hypothesis” campaign so the community learns index construction before any staking regime (Arguer). SCP’s synthesis on 22 August: permissionless creation, permissioned verification and listing.\nStatus: Ideas stage, no PIP drafted.\n5.2 On-chain burn for Entropy protocol fees\nThread: Complementary Proposal to Pyth Reserve Evolution: Onchain Burn for Pyth Entropy Protocol Fees — SCP, 7 June; 8 posts, 206 views, 18 likes\nThe idea. On every Entropy request, burn 50% of the protocol fee on-chain and leave 50% withdrawable to the DAO, as a usage-equals-deflation complement to the Pyth Reserve proposal.\nWhere the community sits. Entropy fees are collected in native tokens (ETH, MON, HYPE), so an on-chain burn deflates those chains rather than PYTH. Marc confirmed no Entropy fees have yet been withdrawn from any chain, that withdrawal needs a Pythian Council contract upgrade, and that bridging native tokens to Solana is impractical. His counter: a single counterparty receives the accumulated native tokens across chains and delivers USDC to the DAO treasury, which folds into the existing monthly PYTH purchases. SCP accepted that direction on 10 July. The principle stands, in that Entropy revenue should create sustained PYTH buy pressure, with the implementation via counterparty rather than per-chain burns.\nStatus: idea stage, no vote.\n5.3 Pyth Wheel Burn Registry\nThread: [OP-PIP] Implement PythWheel Burn Registry: 100 PYTH Permanent Burn per Spin Community Deflation Mechanism — SkyZ, 19 May; 18 posts, 475 views, 27 likes\n100 PYTH permanently burned per spin, with spins allocated by community role. Derrp’s guardrails: one batched burn per month rather than per spin, a 50% cap on reserve tokens burnable at once, and a 12-month review. Marc moved it back to the Ideas Bank pending the funding-source question: prize pool, new budget line, or a separate burn fund.\nStatus: open as of 25 June.\n\n6. Pyth Wheel\nOverview\nPyth Wheel is primarily a tool to showcase Pyth Entropy in use across chains and in different contexts. It is also an accumulation mechanic for Pythenians holders, who receive free spins each week and accumulate PYTH on a weekly basis. This is one of several small utility mechanics attached to the NFTs that the community keeps as open secrets for the wider ecosystem to discover.\nUsage and payouts\n\nMonth\nPYTH paid\nWallets\nSpins\n\nMarch\n41,635\n356\n2,254\n\nApril\n37,686\n378\n4,646\n\nMay\n44,163\n439\n5,469\n\nJune\n40,411\n416\n5,009\n\nJuly\n100,000\n431\n5,600\n\nAugust\n93,958\n497\n7,001\n\nTotal\n357,853\n\n29,979\n\nWallet participation grew 40% from March to August. Spins per wallet went from 6.3 to 14.1, so the same audience is engaging more than twice as often. Cost works out at roughly 12 PYTH per spin.\nThe budget moved from roughly 40,000 to 100,000 PYTH per month from July as the Wheel graduated from Miscellaneous to its own line. The Wheel takes no fees; every contract address is public and payouts are verifiable per wallet at month end. Aristophanes receive free spins as part of the creator system, and Pythenians NFT holders receive free spins each week.\nWhich chain\nThread: Should We Move the Pyth Wheel Back to Base or Monad?\nThe Wheel is EVM-native, built on Pyth Entropy, and deliberately cycled across chains as an on-chain education tool. It launched on Base in March, moved to Monad, and to HyperEVM from September.\nFirst week of September on HyperEVM (snapshot 6 September, at $0.055 PYTH and $0.11 per spin): 394 unique wallets and 2,941 spins, the strongest opening week of any month.\n\nUsers in profit\n361\n\nBreak-even\n2\n\nIn loss\n31\n\nMedian profit per user\n$1.06\n\nHighest individual loss\n$0.33\n\nEvery wallet is net positive over the lifetime of the Wheel across all three chains. A prize-weighting upgrade shipped alongside the migration.\nThe 2 September forum thread asking to move back to Base or Monad centres on spin cost, roughly $0.15 in HYPE plus bridging. The Entropy protocol fee on HyperEVM is unchanged at 0.0004 HYPE, so the difference comes from chain gas rather than Entropy.\nDecision: stay on HyperEVM through September. Any net-negative wallets are equalised at month close.\n\n7. PythFeeds.com\nOverview\nPythFeeds.com is a community-built retail market terminal on Pyth data, built and run independently by Samurai. The Council’s role is product direction, brand alignment and distribution. It is not an official Pyth product. All usage figures are Google Analytics 4, tracking live from 1 April 2026, snapshot taken 7 September 2026.\nUsage\n2,287 unique users and 3,197 sessions from 1 April to 6 September. Roughly half of those users arrived in the last five weeks.\nRolling 28-day active users: mid-May peak ~410, end-June trough ~180, late July ~450, 6 September ~1,050.\nThe last 30 days (8 August to 6 September) are the strongest on record. 28-day active users rose 132% on the previous 30 days. Weekly active users have held between 190 and 255 for five consecutive weeks; the previous best week was ~160 in mid-May.\nEngagement:\n\nMetric\nValue\n\nAverage session duration since April\n3m 43s\n\nLast 30 days\n2m 06s (−56%)\n\nSessions per user since April\n1.4\n\nNew traffic is shallower than the early user base, which is normal when acquisition outpaces retention. Most visitors come once: retention is the weak point, ahead of acquisition, and it is the explicit priority for the next six months.\nThe read: the May spike lines up with the Missions program (May and June were the two heaviest mission months), and the June trough with missions stopping. The August to September surge happened with zero missions running, making it the first stretch of organic growth. Attribution is most likely organic: @PythFeeds posting on X, plus search results.\n\nNote on figures. The GA4 “30-day active users” dashboard totals (56,587 for April to September) sum a rolling daily count and are not unique users. They should not be cited as monthly users. The “~10K monthly users” figure quoted when the workstream started is not supported by GA4; the peak trailing-28-day audience is ~1,050. We would rather post the smaller number that is true.\n\nDevelopment\n\nMarch: began at the Pyth Community Hackathon as Samurai’s entry, and grew from there.\n28 May: workstream launched with Douro Labs and PDA. The direction from here is to use PythFeeds as a launchpad to trial a Pyth Pro consumer subscription package. Nothing has been finalised or formalised.\n19 June: technical audit by Douro Labs. Findings: no product prioritisation, and an API layer proxying a single Pyth Pro key to PythFeeds users. The backend is Node.js; FMP is used only as a helper for PE ratios.\n30 June: model changed to referral-only, arm’s length. PythFeeds stays as its own product and refers users to the Pyth Terminal for their own subscriptions and API keys. No redistribution of Pyth data. This removes the compliance-monitoring burden a formal partnership would have carried.\n\nConsumer subscription trial\nNothing finalised or formalised. Pricing subject to approval and legal review.\nIt is being proposed that PythFeeds be used as a launchpad to trial a Pyth Pro consumer subscription package: the first attempt at a consumer-tier subscription on Pyth data, run on a community product rather than an official surface, where the community can test & iterate without committing the broader protocol to a model that has not been proven.\nWorking shape, subject to change: revenue split 70% to the DAO wallet, 30% to the builder, covering ongoing marketing, development and maintenance. Payments would run fully on-chain and verifiably, rather than through a conventional processor, keeping the product crypto-native and making the DAO’s share auditable by anyone rather than reported after the fact.\nThere is MUCH more to come here. If the trial works, the longer-term path is PythFeeds being folded into the Pyth Terminal as a community-built component, which would make it the first case of a community project graduating into the core product surface.\nAccount and content program\nThe @PythFeeds account on X is live, with a community content program running behind it. The intention is to transition this into a full-time position, funded from a share of the subscription revenue once the trial above is running, plus a monthly stipend from the Council’s community grants program. Part of the pay is tied to whether the product it markets actually earns.\n\n8. PythScan\nPythScan is a direct output of the March Community Hackathon run by the Community Council. Wattson (@MasterWattson) entered that event with Market DVR, built on the hackathon API the Council stood up, and went on to ship PythScan from it. It has been live for testing since 24 August on two surfaces.\nWhat it answers\nPlain-language questions about Pyth, restricted to official Pyth sources, with the bot built to say when it cannot verify something: live price, 24h / 7d / 30d and calendar-window change, price at a point in time, all-time high and low, two-asset comparisons, and top movers by market, region and period. It also covers the feed catalogue (does a feed exist, which feeds were added this week, feed and Hermes/Lazer ID lookups), governance (did a PIP pass, live Realms votes and those ending soon, council membership and elections, constitution and staking rules), and product questions (Core vs Pro, Pyth Pro pricing, recent updates, package versions, Pyth Pro revenue reports).\nOn X — @Pythscan\nTag it with a question and it replies through the filtered mention stream, with a rendered Pyth price, comparison, revenue or confidence card attached.\nOn Discord\nInstall it into a server and ask in plain language, in DMs, on mention, or in reply, plus six slash commands:\n\nCommand\nDoes\nPermission\n\n/setup\npick reply channels and thread behaviour\nManage Server\n\n/alert\nprice, new-feed and governance alerts, delivered by DM\nany member\n\n/watchlist\nadd, remove and list tracked assets\nany member\n\n/updates\nautomatic server posts for new feeds and governance\nManage Server\n\n/movers\nby direction, market, region and period\nany member\n\n/brief\ntoday, yesterday, this week, last week\nany member\n\nBuild\nPython 3.10 on discord.py and FastAPI, SQLite for state, and a Node renderer for card images. Roughly 76,700 lines of Python with a further 42,000 lines of tests across 124 test files, built by one community member in about two months.\nKnown limits\n\nDiscord replies are truncated at 1,900 characters; X replies at 270.\nAlerts, watchlists and server broadcasts are Discord-only.\nIt responds only when addressed (a mention, a DM, or a reply), and only to questions.\nCard rendering depends on a Node renderer that lives outside the repository.\n\nNext: data visuals publishing to X.\nContinuity note for the Council: the repository is currently private, single-contributor, without a licence or continuous integration. Securing a licence and a transfer path is a Cycle 2 deliverable, so a tool the ecosystem comes to rely on does not sit on one person’s account.\n\n9. The PIRB\n@thePIRB is a Pyth lore and bull-posting account run by Aristophanes from the creator program. It is the clearest example of what the contracted creator system produces that a mission brief never could: sustained narrative craft, built over months, with a visual identity of its own.\nThe past six months:\n\nPyth lore and bull posting through AI video. The account’s core output is short AI-generated video, used to build a running mythology around Pyth rather than to restate announcements.\nCommunity creation and lore. It leans into the community’s own in-jokes, characters and running references, which is what gives the material something to attach to.\nNarrative craft first. The posts are weird, and deliberately so. They are built to stop a scroll and be remembered, which is a different job to informing an audience that already follows Pyth.\nA visual style that has compounded. The look has improved materially across the six months and continues to develop. It now reads as a recognisable identity rather than a series of one-off experiments.\n\nThe numbers, 19 March to 19 September. 719 posts, 124,751 impressions, 5,242 engagements at a 4.2% engagement rate. Three quarters of that volume is replies, which inherit whatever reach the thread they land in already had, so the figure that actually describes the account is its own content: 169 original and quote posts carrying 85,169 impressions at a 5.0% engagement rate.\n\nMonth\nOwn posts\nVideo\nImpressions\nMean / post\nMedian / post\nEng. rate\n\nMar (13 days)\n10\n4\n3,273\n327\n292\n6.3%\n\nApril\n14\n8\n7,589\n542\n414\n4.7%\n\nMay\n20\n14\n5,914\n296\n333\n6.7%\n\nJune\n31\n20\n9,581\n309\n341\n7.2%\n\nJuly\n33\n14\n13,153\n399\n394\n6.1%\n\nAugust\n45\n19\n31,639\n703\n507\n3.7%\n\nSept (19 days)\n16\n11\n14,020\n876\n660\n4.7%\n\nReach per post is up 2.7x since March on the mean and 2.3x on the median, while the engagement rate held in a 3.7% to 7.2% band rather than decaying as reach grew. Output rose alongside it: 31 to 45 original posts a month from June, against 10 to 20 before.\nThe distribution story. Total impressions are 872x the follower count; on own content alone, 596x. Follower count was flat across the window, so effectively none of this reach comes from the follower base. It comes from X distributing the videos to people who do not follow the account. Every one of the top ten posts reached between 8x and 63x the follower count on its own.\nAugust is the inflection. That month the account worked out that short video tied to a live news hook or a recognisable meme format travels a long way past its own audience. The best-performing own post of the window, a video on the SEC and Hyperliquid with a Pyth angle posted the same day as the headline, took 7,591 impressions. Five of the six own posts that cleared 1,500 impressions are video, and all six are from August or September.\nDiscounting our own numbers. Roughly 20,000 of the 124,751 impressions, about 16%, came from five off-topic replies to large non-crypto accounts, which drew near-zero engagement. That is borrowed reach, and this report argues elsewhere that borrowed reach should not be counted. Discounted, the window total is ~104,750 impressions, and the honest own-content figure is the 85,169 above.\nSource: X API v2, pulled 19 September 2026. Per-post data retained. Follower count at the start of the window is not recoverable through any available access path, so net follower growth cannot be stated.\n\n10. RWA Markets research\nrwa-markets.xyz is the work of Zinn (@zinnresearch), published under Refraction Research and sponsored and subsidised by the Community Council. It is the only public dataset of its kind: real-time analytics on tokenised real-world asset trading across decentralised and centralised venues, tracked at a granularity nobody else publishes.\nCoverage at 9 September 2026:\n\n24h volume tracked\n$16.4B\n\nVenues\n22\n\nAssets / markets\n536 / 2,218\n\nRWA share of tracked perp open interest\n18.6% ($11.6B)\n\nWhat it covers: nine dashboards across tokenised stocks, commodities, indices and treasury assets. Today (daily snapshot), Volume Dominance, OI Dominance, Top Traded Assets (with oracle data), Institutional Velocity (trade frequency, size, spreads, slippage), Asset Analyzer (per-asset liquidity and funding), Trader Intelligence (on-chain wallet analytics and capital flows), DeFi Markets (lending, yields, TVL, tokenised treasuries) and Spot Markets (tokenised stock and ETF spot trading and issuance).\nWhy it matters to Pyth. This is an important community run project that Pyth uses internally for data attribution on perpetuals volumes, alongside a range of other datapoints. Per Zinn, it fed the August RWA report. The protocol consumes it as working infrastructure.\nZinn has since built dedicated API connectivity specifically for Pyth, with partner access to the underlying database covering oracle provider attribution weighting per symbol, venue and wallet-level breakdowns, per-venue execution quality, and DeFi yield history. Pyth is the only party outside Refraction Research with this level of access. It is a working technical partnership between a community researcher and the protocol, built without a formal commercial agreement.\nThat is the clearest illustration of what the Council’s research budget buys. Zinn is producing work that is unavailable anywhere else, that the team relies on internally, and that carries the Pyth name into a market segment where nobody else has comparable visibility.\n\n11. Budget\nFigures as of 27 August 2026. All amounts in PYTH.\n\nCategory\n6-month budget\nSpent\n% used\n\nRole stipends\n280,000\n306,486\n109.5%\n\nContent program\n3,000,000\n1,090,670\n36.4%\n\nHackathons\n300,000\n133,000\n44.3%\n\nCouncil stipend\n420,000\n420,000\n100%\n\nMiscellaneous (incl. Pyth Wheel)\nn/a\n305,150\nn/a\n\nTotal\n4,000,000\n2,255,307\n56.4%\n\nMonthly spend against the recurring benchmark: April 588K, May 623K, June 405K, July 447K, August 121K, September 70K to date. May was the only month over benchmark, driven by hackathon payouts.\nRole stipends is the only line over allocation, at 9.5% (26,486 PYTH) past its six-month envelope. The cause is growth rather than overrun: the role system expanded as more mechanics came online, and more community members wanted to dedicate serious time to running them. We would rather have that problem than the opposite one.\nOn the 43.6% unspent: this is deliberate, and it was planned for. The underspend sits almost entirely in the content program, because Missions were shut down mid-term and the replacement creator system only went live on 6 July. Rather than spend the difference to hit a number, we are holding it for the Hackathon, which returned more per PYTH than anything else the Council funded and deserves a materially larger prize pool and more of the Council’s time in the second half. The Cycle 2 increase we are asking for was already contemplated in the original request made at the start of the year.\nWhat things actually cost\n\nTerm 2 to date\n\nPyth Wheel\n~12 PYTH per spin, ~720 PYTH per participating wallet\n\nHackathon\n133,000 PYTH for 40 submissions = 3,325 PYTH per submission\n\nHackathon, second iteration target\n500,000 PYTH for 400 submissions = 1,250 PYTH per submission, a 62% improvement in unit cost\n\nPythFeeds, PythScan, SCPTech\na single stipend per project, capped at 20,000 PYTH per month and lower in several cases\n\nThat last line deserves emphasis. PythFeeds, PythScan and the SCPTech work are each built by one person. There is no team, no agency and no vendor contract behind any of them. The entire development cost to the DAO is a monthly stipend to a single community member, capped at 20,000 PYTH and less in some cases. PythScan alone is 76,700 lines of Python with 42,000 lines of tests.\nThese are also long-horizon projects and should be judged as such. A retail terminal, an intelligence assistant and a governance tracking stack do not produce measurable returns inside a six-month window, and we would be misleading the DAO if we presented them as though they did. What they produce in Term 2 is working software, a user base to learn from, and optionality: PythFeeds is now the trial vehicle for a Pyth retail subscription, and PythScan is becoming the ecosystem’s front door for plain-language questions. The payoff sits in Terms 3 and 4.\n\n 2\n\n read \n\n 14\n min\n\n post by Chop on Sep 19\n\n post by totti on Sep 20\n\n post by iDrJoe on Sep 21\n\n post by Mersault on Sep 26\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14\n\n Community Council Term #1 Exit Report\n\n Community Council\n\n 4\n\n 194\n\n Mar 29\n\n Community Hackathon post-mortem\n\n Community Council\n\n 6\n\n 238\n\n May 31\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":6925,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267295631,"hash":"cb73c9bd8d8ab7c64022fa913b9a5435b5643c7d"}
{"url":"https://ethresear.ch/t/gluon-plasma-full-spec-for-non-custodial-exchanges/3931","domain":"ethresear.ch","title":"Gluon Plasma Full Spec for Non-custodial Exchanges - Layer 2 / Plasma - Ethereum Research","text":"Gluon Plasma Full Spec for Non-custodial Exchanges \n\n Layer 2Plasma\n\n new-extension\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2018\n\n 1 / 30\n\n Oct 2018\n\n Feb 2019\n\n post by bharathrao on Oct 25, 2018\n\n bharathrao\n\n This is a followup post on “A DEX on plasma” from Apr’18. We have gone through many iterations and have what we believe is a production quality spec. Note that ours is designed for trading and not UTXO payments like almost all other specs here.\nOur focus is weighted with UX, Scaling and Security in that order.\nUX is the primary driver since we are building a business, not just engaging in technical research. Most of our choices were based on pragmatic conditions of the market and user base today. For example, we realized that exit games are a non-starter because although they work, even many tech-savvy users would avoid such exchanges at the current time. Our users were also confused why they have to deposit a heavy bond to take out their own money.\nScaling was the next primary driver. We aimed for sub-linear cost in terms of gas, storage and computational load with increasing volume. Without this, the platform becomes self-limiting as gas costs drive traders elsewhere. Scaling also feeds into security since super-linear cost would make it practical to overwhelm any validators with long chains of transactions, dust trades and other attacks whose impact is amplified by high activity.\nSecurity is last but not the least. It is intertwined with the two needs above. We needed a security model and proof so that the model could be examined and any gaps speedily addressed.\nRead the full Gluon Plasma paper to understand our motivations and drivers.\nTop features:\n\nOffline Recipient\nInstant finality on plasma chain\nFast withdraws (< 1 hour)\nFungible\nUnlimited number of coins\nUnlimited trades per block\nLight nodes\nCompact fraud proofs\nEthereum Network Congestion tolerant\nSecurity Model/Proof\nWatchtower-free\nExit Game-free\nChallenge/Response-free\n\nOk, so what’s the catch?\nData Unavailability is not yet eliminated. A governance token is used to vote for a chain halt if the operator turns maleficent. SEE UPDATE BELOW\nSecurity Proof Outline\nA payment network is secure if the following constraints hold for every transaction:\n\nThe recipient can receive the payment directly.\nThe sender’s provable intention is required to send the payment.\nThe amount received is exactly the amount sent.\nNetwork participants can verify validity according to consensus rules.\n\nIf it can be shown that every state change enforces the above, then the network is safe. The above needs to be enforced at 3 levels:\n\nAll steps of the protocol, which is the interface between the main chain and plasma chain\nPlasma ledger entries\nPlasma chain, which is the arrangement of plasma ledger entries.\n\nI ask the reader to read the full paper since the protocol and the fraud proofs together make the system, so listing just the protocol here would be a disservice.\nGuide to reading the paper: What each chapter speaks about\n3: Deriving account model from UTXO model\n4: How Exchange security models work\n5: Why we needed a different plasma flavor\n6: Gluon Plasma fundamentals\n7: Gluon Plasma characteristics (is this flavor suitable for your project?)\n8: Gluon Plasma Protocol\n9: Fraud Proofs\nAppendix A,B and C: Proofs of safety and custody\nYour improvements and critical feedback is highly appreciated!\nUPDATE: Joey Krug suggested we replace the POA with tendermint consensus POS. We realized that if we decouple the exchange and consensus (ie block committer) roles, we can eliminate data unavailability:\n\nExchange(s) creates transactions.\nTendermint POS committers create blocks from transactions.\nIf exchange withholds data, POS validators will simply not commit any more blocks.\nIf at least 1/3 of the POS validators collude with the exchange and duplicitously commit a block while withholding data, other POS validators can slash their deposit (which needs to be hefty).\n\nRegarding 3. Chain is abandoned and halts when there is a single exchange on the plasma chain. On a multi-exchange chain, the byzantine exchange is ejected and trades in its block are effectively rolled back. Other exchanges can continue to operate. Multi-exchange feature is not yet finalized.\nA single exchange Tendermint POS can probably be implemented without much impact.\n\n Only 3 opecodes are needed to build DEX on Plasma Chain\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n 16\n\n 4\n\n 4\n\n 3\n\n 2\n\n read \n\n 18\n min\n\n post by sg on Oct 25, 2018\n\n sg\n\n How strong the security is? Same guarantee with Plasma Cash, or MoreVP?\n\n post by ritikm on Oct 26, 2018\n\n ritikm\n\n Thanks for sharing.\nAt first glance this construction sounds like an account-based version of Plasma MVP with extremely frequent checkpointing (every G-block is effectively a new checkpoint since you can’t challenge any prior G-blocks). This makes the data storage requirements low (only need to store one G-block’s worth of data), but liveness requirements extremely high (there needs to be at least one honest, incentivized verifier checking every transaction in every G-block with no downtime).\nCouple questions:\nIs there a concept of trustless atomic swaps? Based on the description and the table in section 6.5, it looks like account A_1 trades 0.05 Z_1 for 0.02 Z_2, which is done across two transactions (state 2 and 3). What happens if the operator decides to withhold state 3 and A_1 is left with nothing? Or consider a case where the two transactions are at the edge of the G-blocks (one is the last one in G-block N and the other is the first in G-block N+1) and G-block N+1 is deemed invalid (so the chain has halted). Half my swap has now been confirmed and I’m forced to exit the sidechain with nothing.\nOnce a G-block is submitted, how long is the period before another G-block is submitted (and thus the previous G-block is now considered confirmed and unchallenge-able)?\nWho is responsible for validating G-blocks? If users of the DEX are expected to validate, it sounds like they have a huge burden of running nodes themselves to run the validation process across all transactions that are happening across the DEX. If it’s a separate, limited validator set, how are they incentivized to do the validation?\n\n post by themandalore on Oct 26, 2018\n\n themandalore\n\n Great work Leverj guys, I’ve always wanted to see more account based implementations. A few questions:\n\nIs there a max size to your G-block?\nHow is the voting size calculated? I know you do derivatives, so in a world where a lot of players could lose a lot of money very quickly, how do you prevent them from halting the network and what’s the threshold that it becomes insecure?\nIs this really that much different than MVP? You’re just verifying something different (accounts vs transactions)\nWho are the witnesses and how do you incentive them?\n\nAnd lastly, is there code anywhere or places we can contribute? I think some tweaks to the MVP repo and you could get something testable in a pretty short time period\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\n ritikm\n\nthere needs to be at least one honest, incentivized verifier checking every transaction in every G-block with no downtime\n\nThis is correct. However, validators are not expensive to run and since we are an exchange, the market makers will surely run multiple redundant validators to protect their large balances.\n\nIs there a concept of trustless atomic swaps?\n\nAll trades are atomic. A trade execution results in four Trade entries (plus any Fee entries). The entire set should be committed into the same G-block.\n\nOnce a G-block is submitted, how long is the period before another G-block is submitted (and thus the previous G-block is now considered confirmed and unchallenge-able)?\n\nIf fast withdrawals are desired, could be as low as 10 minutes. Generally most fraud is detected right after an entry is created and much before they go into a block.\n\nWho is responsible for validating G-blocks?\n\nThere are separate validator programs. The validation load is not that high since the validators only need to store the last (A,Z) entry. If they can prove fraud and halt the exchange, they get a bounty. Truebit suggested that occasional random minor bounties should be paid at regular intervals and this is a good idea. We will hold validation games on testnet to see what model works best.\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\n themandalore\n\nIs there a max size to your G-block?\n\nno\n\nHow is the voting size calculated?\n\nVoters need to stake LEV tokens to vote. Voting to halt costs 10% of their staked tokens. Any losses they offset by halting the chain would mostly be lost in the LEV they sacrifice. Can they pre-plan to buy a lot of LEV when its cheap, stake it in the hope that if the market moves against them there is an economic tradeoff to halt the chain? Perhaps. But they wont be able to do this repeatedly.\nRealistically, if say the top 3 or 4 market makers decide to halt the chain, it will probably halt. However, this would require a sudden sharp move (say a 50% price drop in 10 minutes) and would require all market makers on the losing side. We calculate that an unreasonable halt is very unlikely, on the order of once a decade, just like the fiat markets.\n\nIs this really that much different than MVP? You’re just verifying something different (accounts vs transactions)\n\nMVP was great. It gave us a good foundation of whats possible. Much thanks to Vitalik and Karl (and the OMG team) for their hard work.\nAll flavors of plasma essentially driven from the same principles behind plasma classic. However, there are some UX differences in our flavor that are important for trading vs just coin payments:\n\nNo exit games, making adoption easier\nA transaction when visible has finality way before its committed to a block. This means you can sell what you bought milliseconds ago or hedge or place stop orders etc (very important in leveraged trading).\nAccount model makes trading practical while UTXO based trading is excessively cumbersome and I have never seen one that has gained traction.\nTrade with API keys, which allow trading but not withdraw. Any system without this feature will not attract marketmakers.\n\nis there code anywhere or places we can contribute?\n\nWe will opensource contract code soon. Thanks for your interest! PM me if you want to spend a significant chunk of time on this project.\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\n sg\n\n Good question. I’m not sure if there is a way to quantify security.\nPerhaps someone can come up with a model to evaluate risk scores. something like: % of funds at risk * probability of loss. Some initial thoughts:\nRisk Ranking:\nIn my opinion, the highest threat to security are\n\ntotal loss of chain funds: everything on the chain is stolen by an anonymous network participant\ntotal loss of a single account by anonymous network participant\ntotal loss of chain funds stolen by the operator\ntotal loss of a single account by operator\nminor losses due to bad fills/skimming/front running by anonymous participant/miner\nminor losses due to operator\n\nProtocols where the victim needs to detect and issue a challenge have lower safety compared to ones where anyone can challenge.\nProtocols where challenges are issued after initiating an exit game are susceptible to spam attacks and less safe than challenge-free protocols like Gluon plasma.\nHaving the operator answer challenges is susceptible to an overload attack where hundreds of dust outputs require challenge and a huge one is hidden among them hoping to overwhelm the operator.\nI think in general, challenge stuff does not scale and relies on network usage being low and miners not cooperating with attackers.\nGluon plasma avoid all these issues by design.\n\n post by ritikm on Oct 26, 2018\n\n ritikm\n\n bharathrao\n\n Thanks for the quick response. Few more follow-ups:\n\nThis is correct. However, validators are not expensive to run and since we are an exchange, the market makers will surely run multiple redundant validators to protect their large balances.\n\nHow does this protect anyone not running a validator (e.g., smaller, infrequent traders)? Relying on a small set of validators who have a lot at stake (either through LEV tokens or large balances on the DEX) is fine, but sounds closer to the kind of protection a Proof-of-Stake system would have vs. a construction like Plasma Cash.\nThis also begs the question of why go through the trouble of committing block hashes back to Ethereum. If the system relies on a group of validators to find fraud, you could just run this as a non-Plasma sidechain where assets are locked up on Ethereum, you have a limited Proof-of-Stake based validator set that achieves consensus amongst themselves around which blocks are legitimate and final, and you have a bridge to take assets back and forth between Ethereum and the sidechain. Is the only benefit of Plasma-fying this construction for users to have the “Exit Asset Balance” option?\n\nAll trades are atomic. A trade execution results in four Trade entries (plus any Fee entries). The entire set should be committed into the same G-block.\n\nHow do you prevent the operator from withholding one of the Trade entries? What incentive does a validator have to detect such an issue if they’re not directly involved in the trade? Consider a case where there’s a small-time trader A_1 trading 0.1 Z tokens and a market maker A_2 who has 1,000,000,000 Z tokens and runs a validator node. If A_2 detects operator malfeasance, A_2 realistically won’t call it out since it’s such a minuscule error (0.1 Z worth) vs. her own holding (1,000,000,000 Z). It’s not worth the burden of having to deal with a halt, exit, and restart unless the bounty for finding such fraud is extremely high.\n\nNo exit games, making adoption easier\n\nExit games still exist in this construction, albeit in a different way. Any “Withdraw” ledger entry included in a G-block should be treated like an exit and must be validated by all users to ensure that excess funds aren’t being withdrawn. In your construction, I see two differences vs. a traditional Plasma MVP construction: (1) you have a limited validator set that’s doing this validation instead of every user, which is trading off some level of security for usability, and (2) the challenge window is much shorter (10 minutes based on your recent post) as it’s limited to the time until a subsequent G-block is published. (Note that both of these points are also possible to implement in a Plasma MVP/Cash construction for the same set of tradeoffs.)\n\nA transaction when visible has finality way before its committed to a block. This means you can sell what you bought milliseconds ago or hedge or place stop orders etc (very important in leveraged trading).\n\nIsn’t the risk here that trading halts in the event of a flash crash (because the few largest accounts, who have the most to lose, effectively control the decision to halt the sidechain and revert the last uncommitted G-block)? Agreed that this is a black swan event since only the last G-block can be reverted, which would mean that a large amount of money would have to be lost in the short time window of one G-block. Gradual losses of capital over several G-blocks should not trigger such an event.\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\nAnyone can run a validator, find a fraud and submit a fraud proof to the plasma contract. A fraud proof does not require staking or LEV or even participating in trading to halt the chain. The only reason to stake is to vote when data is unavailable, ie everyone is probably getting screwed over because the root commitments dont match.\n\nWhat incentive does a validator have to detect such an issue if they’re not directly involved in the trade?\n\nValidators get bounties for halting the chain.\n\nConsider a case where there’s a small-time trader A_1 trading 0.1 Z tokens\n\nThere are very few frauds that A_1 himself cannot submit a proof on. Regardless, the moment A_2 or anyone detects the operator is compromised and even a single trader is defrauded, the only course of action to take is to halt the chain. If the operator steals 0.1 from A_1, then A_2 knows his entire balance is at risk. Its much much cheaper riskwise to sacrifice 10% of governance tokens which will probably be worthless soon than to hope that the operator’s strategy is to only steal pocket change from small players. (This does not seem to be a reasonable line of thought, fwiw.)\n\nExit games still exist in this construction\n\nExit games are interactive steps mediated by the smart contract and have the following issues:\n\ncan be manipulated by spam attacks to prevents the other party from responding in time\nPossibly get miners to exclude challenge responses.\nA sudden surge of challenges that empty eth preventing you from challenging more claims.\n\nNon-interactive proofs are not games in the sense that once submitted, there is little room for manipulation.\n\n(1) you have a limited validator set\n\nQuite the opposite. MVP validation is onerous: every user has to validate the chain every week or they are at a risk of loss. Any system where only the victim can protect himself is weak. In Gluon, a single validator provides security for everyone. This is far more robust than MVP\n\n(2) the challenge window is much shorter\n\nThe challenge window can be shorter in Gluon with the same safety because unlike MVP, every user does not need to validate the full history. Detection of frauds in Gluon immediate on seeing a new entry, even before it goes into a block. In MVP, you would need to trace the history of every coin. Imagine doing that in a high volume exchange, where UTXO shredding has created millions of UTXOs per user. it could take days before you figure out that one of your million utxos with 1 million transfer history has a fraud 900K transfers ago.\n\nNote that both of these points are also possible to implement in a Plasma MVP/Cash construction for the same set of tradeoffs.\n\nA 10 minute MVP will implode since one can create a fraudulent coin whose history takes longer than 10 minutes to verify. Plasma cash in non-fungible, leading to a knapsack problem when trying to construct transactions that match desired quantities.\n\nIsn’t the risk here that trading halts in the event of a flash crash\n\nThe minuscule risks of a black swan chain halt are a lot more appealing than trying to exit 100 million utxos via a priority queue on 8M gas limit. Im simply not convinced that its a feasible approach.\nData unavailability is the ugly stepchild of plasma. No solution here will be perfect. Its all about tradeoffs and we have taken the one thats best for our domain. Nevertheless, we are working on addressing the data unavailability problem in other ways. Perhaps some of the smart folks on this forum will find a compact/succinct proof we can submit with the new block eliminating this issue.\nYou seem to be interested in a MVP/ Gluon comparison. Perhaps we can create a separate forum comparing different flavors of plasma. Each flavor has its own applications and MVP is OK for payments but is utterly unsuitable for trading exchanges:\n\nHow will you match 500 Z1 to 300 Z2 when both are made of 100K UTXOs each?\nHow many tx do you need to fit at 2 inputs and 2 outputs per tx?\nHow can you place an order and close your laptop?\nHow do you co-ordinate a trade between two users to do the trade as above?\nWhy will a user sign a trade first if the second will walk away unless the price move in their favor?\nI’ve signed the trade for atomic swap. I hope the other party signs it. Now what? Should I hedge my position? How long should I wait before cancelling my hedge?\nIm a market maker trading every millisecond. How do I “periodically validate the chain”\nGas price is suddenly high and blocks are full? My challenge was submitted with low fees!\nThere’s 10 icos going on today and I discovered that operator defrauded me. The gas fees is higher than my account value!\nHow do I tell everyone that the operator has defrauded me? Send them a million utxo history?\n\n… and oh … how do you enable leveraged trading on MVP/Cash?\n\n post by sg on Oct 26, 2018\n\n sg\n\n bharathrao\n\n I’ve glanced your paper.\nThe fast withdrawal construction implies “if the operator is Byzantine, then users cancel orders and exit”. But the order cancellation might not be executed because the op is Byzantine.\n\nIs this assumption correct?\nWho is running the Orderbook?\nWere any fund safety guarantees discussed regarding order cancelation?\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\nIs this assumption correct?\n\nIf the operator fails to cancel orders of someone exiting directly from the smart contract, this can be detected and proven via “Exit Insolvency Fraud proof”\n\nWho is running the Orderbook?\n\nThe operator\n\nWere any fund safety guarantees discussed regarding order cancelation?\n\nOrder creation, modification and cancels do not impact custody. Every exchange needs to be able to cancel orders for any or no reason, for example: to shutdown for maintenance, delisting an asset, etc.\nHolding users canceled orders and filling them adversely is detected by the “price time priority fraud proof”.\n\n post by ritikm on Oct 26, 2018\n\n ritikm\n\n bharathrao\n\nThere are very few frauds that A_1 himself cannot submit a proof on.\n\nThis would require A_1 to be live and running a validator node, which sounds impractical for 99% of users no matter how light-weight the validator node is (have to download separate software, keep it always running, etc.)\nI can see having a separate group of people, who have much more at stake in the DEX, running these validator nodes with a TrueBit-style incentive scheme. Again, this is possible in Plasma MVP/Cash as I describe below.\n\nExit games are interactive steps mediated by the smart contract and have the following issues:\n\ncan be manipulated by spam attacks to prevents the other party from responding in time\nPossibly get miners to exclude challenge responses.\nA sudden surge of challenges that empty eth preventing you from challenging more claims.\n\nUnclear what you meant by #3, could you please clarify?\nThe first two problems are not mitigated in Gluon. Consider a case where a G-block with fraudulent transactions has been submitted (e.g., a “Withdraw” transaction with the wrong amount of Z tokens). Validators will be able to catch that problem quickly, but will have to submit the fraud proof on-chain. The first two problems you mention still hold:\n\nSpam attacks on-chain could prevent a validator from submitting the fraud proof or halting the chain in time (before the next G-block).\nYou can get miners to exclude the fraud proof or the voting process to halt the chain.\n\nNon-interactive proofs are not games in the sense that once submitted, there is little room for manipulation.\n\nHow is this different than existing Plasma constructions? What kinds of “manipulation” are you referring to that Gluon prevents vs. MVP/Cash? Per your whitepaper, it seems like if fraud is detected, it results in a vote to halt the chain (the equivalent of a “challenge”). In MVP/Cash, challenges are issued against individual exits, which prevent the exit from going further. The definitions and outcomes of a challenge may be different, but the requirement of monitoring the operator and on-chain proofs is the same.\n\nQuite the opposite. MVP validation is onerous: every user has to validate the chain every week or they are at a risk of loss. Any system where only the victim can protect himself is weak. In Gluon, a single validator provides security for everyone . This is far more robust than MVP\n\nDissecting this further:\nIt seems like only having one validator provide security for everyone is possible because of an account-based scheme as it reduces the amount of data the validator needs to check through, making it feasible for one validator to do the job for everyone. Looking at the implementation of the account-based scheme in your whitepaper, it seems like it’s modeled as a UTXO-based system, where each user has one UTXO per token type (the token’s balance) with on-chain checkpointing effectively happening every G-block. By having each G-block act as a checkpoint, you remove the need to store the UTXO history because anything before the G-block is unchallengeable, and so so there’s no point in storing the history.\nYou can get a similar benefit with MVP and Cash if you exit the coin and deposit it back to the Plasma chain (“checkpointing”). Of course, doing so is much more inefficient, so having the operator do the checkpointing (reducing the UTXO set to a single balance every time, i.e. an account-based system) without requiring a round-trip cost of going on-chain and back off-chain is a clever optimization. This does require an honest set of validators that have much more stringent requirements to verify correctness of each G-block to ensure that the operator is not acting maliciously. I believe the Plasma MVP/Cash constructions were made to not have any reliance on third parties. There is a perceived security benefit with the MVP/Cash model (each user is responsible for their own security so no need to trust any third party), and there’s a practicality benefit with Gluon (trust a group of incentivized third party validators to do the job since they have something on the line as well).\n\nDetection of frauds in Gluon immediate on seeing a new entry, even before it goes into a block. In MVP, you would need to trace the history of every coin.\n[…]\nA 10 minute MVP will implode since one can create a fraudulent coin whose history takes longer than 10 minutes to verify.\n\nThe benefit you’re touting in Gluon is because of the requirement of always having one live, incentivized, honest validator. This lets any validator (even a new one that just joins the network) assume that everything up until the last G-block does not need to be re-validated. This argument also holds in an MVP world. If you have the same validator requirement, you could have the validator creating checkpoints (the equivalent of G-blocks) that reduce the amount of data someone doing transaction history verification in the future needs to analyze (it would only be data from the latest checkpoint onwards). The key point here is that this is only possible if you introduce a requirement of a live, incentivized, honest validator.\n\nPlasma cash in non-fungible, leading to a knapsack problem when trying to construct transactions that match desired quantities.\n\nBe on the lookout for Plasma Cashflow, which solves this problem.\n\nHow will you match […] million utxo history?\n\nI’m curious what your answers are for each of these questions with Gluon as that’ll elucidate some of the tradeoffs you considered and how you made you decision. I’m sure some of them are scattered in the whitepaper, but would be good to get it succinctly included here.\n–\n(All of this is not meant as a knock to the Gluon construction. It describes a clever, practical Plasma abstraction and is similar to many of the things we’re doing in our Plasma construction to make things more practical. My goal here is to dig deeper to understand the nuances and motivations behind some of the decisions taken, especially as we’ve considered many of these ourselves.)\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\nSince every (A,Z) is a separate chain, validation can be sharded:\n\nEvery user can choose to validate only the assets they are interested in and shard by Z\nValidators can shard by account only (shard on A)\nFull Validators can use a LRU cache to listen to only listen to recently active users or only listen to market makers, etc.\n\nWe havent thought of optimization in depth at this point.\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\nVarious optimizations and sharding may enable light validation within the trading client itself\n\nThe first two problems are not mitigated in Gluon.\n\nWays to Spam MVP that is not possible in Gluon:\n\nGluon can ignore dust deposits. MVP can be spammed by millions of dust deposits which will create millions of deposit blocks. This can overwhelm all participants\nGluon needs a single fraud proof to have high enough gas to attract a single miner to mine the tx and everyone is safe. On MVP every fraud needs a separate challenge.for every utxo thats trying to exit. There could be a million fraudulent exits in a few minutes. There is no way every single challenge will hold.\n\nit seems like if fraud is detected, it results in a vote to halt\n\nNo, fraud proof submissions are separate from vote to halt. Fraud proofs are for provable frauds. Voting is for unprovable frauds (ie data unavailability). Both will halt the chain. Data Unavailability is a research topic and we may find a way to eliminate it. Voting to halt is the current best approach to dealing with it.\n\nyou can get a similar benefit with MVP and Cash if you exit the coin and deposit it back to the Plasma chain\n\nWill never happen because UTXO shredding guarantees everyone will have many tiny outputs and this becomes uneconomical.\n\nThere is a perceived security benefit … each user is responsible for their own security\n\nThis is a security weakness, not a benefit. Would you say Bitcoin is more secure if everyone had to verify their coin every week?\n\nThis argument also holds in an MVP world.\n\nYour point seems to be that MVP and Gluon are similar. I will say yes, all plasma flavors are similar.\n\nwould be good to get it succinctly included here\n\nUntil you can answer those questions, my advice is don’t attempt writing a DEX on MVP. This is simply because building something in a specialized domain needs experience in the domain.\nYour line of questioning tells me you sense something very unique about Gluon and you are asking yourself “Why this is different? Couldn’t they have just done this in MVP?”\nThe simple answer is NO. Plasma MVP and Plasma Cash (which were the only flavors when we began) wouldn’t work. Nor would many others that have been spawned since. The UX would be terrible and there would be no traction. We have built financial systems for decades and really loved the bright idea that is plasma. However, it was obvious that no plasma flavor was suitable for trading. So we tailored Gluon for the UX of trading systems.\n\n post by ritikm on Oct 26, 2018\n\n ritikm\n\n To summarize:\n\nThere’s a requirement of an always-live group of validators that every single user must trust, or elect to join, in Gluon which is a critical component to making this work and does not exist in existing Plasma constructions.\nBy having this requirement, you can operate an account-based system and have frequent checkpoints, called G-blocks in Gluon, which reduce the burden of transaction history verification to a limited window of time.\n\n post by bharathrao on Oct 26, 2018\n\n bharathrao\n\nYou make it sound like a country club. Validators act individually completely oblivious of others if any. They dont all have to be always live. You just need at least one of them live at any point in time. Nothing prevents people from starting to validate and stopping at random times. If a 10000 people do this for a random hour a day, theres a very solid chance that at least one will be live all the time.\nYou are focused on the history and verification stuff, which I think is the least important part. Why do we have rock solid safe DEXes that no one uses while Bitfinex is still one of the top exchanges?\nGluon is a plasma that prioritizes providing UX similar to centralized exchanges and can scale with volume. Its designed to attract liquidity, whereas other DEXes are designed to repel it. It then adds provable safety, which even many DEXes dont have.\nSo I would summarize this way:\n\nGluon solves the DEX liquidity problem by enabling a centralized-like latency and UX\nGluon solves the DEX scaling problem by being spam resistant and congestion tolerant\nGluon adds provable security, which no exchange of its speed has ever had.\n\n post by bharathrao on Oct 31, 2018\n\n bharathrao\n\n ritikm\n\n I’ve added Joey Krug’s suggestion of Tendermint consensus (see update to original post), this should address your concern about having to trust an always live group of validators. Perhaps other approaches can be taken such as Dfinity’s 423 with aggregate signatures.\n\n post by yan on Oct 31, 2018\n\n yan\n\n A few concerns:\n\nThe functionality for a DEX includes maintaining an orderbook of all orders and matching orders from the top of the orderbook when there is a match. The protocol for the Gluon sidechain provides more like a general trading functionality that enables clients to simply send money to another client instead of a DEX. And since transactions are processed by a single operator, it is much easier for the operator to mount front-running than in ordinary DEX where front-runners still need to compete by gas price.\n\nThe design of voting to halt is vulnerable to Denial-of-Service attack. An attacker only needs to vote to halt with a small size each time and make finality time for the sidechain very slow.\n\nPlease let me know if I misunderstood anything. Thanks!\n\n post by bharathrao on Oct 31, 2018\n\n bharathrao\n\nThis would be correct. However, a central limit order book’s behavior is deterministic and any discrepancy is immediately obvious. A fraud proof can be submitted as described in S9.3.5.\n\nAn attacker only needs to vote to halt with a small size each time and make finality time for the sidechain very slow.\n\nIf the voted amount is too small, it may just delay by one ethereum block (15s), which may not even be noticed. The delay response is stronger if they vote all their tokens at once rather than a bit by bit every block. Only deposits and withdrawals are slowed during the delay, normal trading can progress unnoticed. This would be similar in UX to centralized exchanges today.\nThey can slow down the chain, but it will cost them 10% of their tokens every time they vote. A hypothetical denial of service attack would cost them a significant chunk of money to delay the blocks by more than an hour. They would have to buy a large number of tokens on the open market to effect a large delay (say one day). The buying pressure would spike the price of the tokens making the attack economically self-limiting.\nIf no one else joins their vote, then they lose tokens. It is unlikely they will be able to keep this up for long.\nEconomically, its equivalent to a miner mining empty blocks on your chain. Most of it will be unnoticed. Some of it will happen longer than normal occasionally and it can be annoying, but it would be prohibitively expensive to run a sustained campaign.\n\n post by yan on Nov 1, 2018\n\n yan\n\nThis is still not detectable, especially when the DEX aims to scale up and have a large popularity. The orders have to be timestamped by the operator because clients’ local time cannot be trusted. Then if an order is timestamped by the operator, certain network delay should be tolerated and this gives space for the operator to inject their own orders.\n\nDo honest large stake owners have to lose 10% of their tokens every time they vote? If so, this sounds like a discouragement for them to vote to halt when data is unavailable while their own profit is not affected. In addition, since delayFunc takes in voteTally as a parameter, which is accumulative, an adversary’s prior vote has a long-term accumulative impact on delaying the commitment of a new Gluon block. I didn’t mean this reduces the throughput of the sidechain, but this does increases the finality time, which was supposed to be a pro of the design.\n\n Load more posts below","tokens":8928,"squid":"ink-research","role":"Deep Scholar","at":1791267301165,"hash":"3644de21c4f6e87d900c8cdfea39e243ebc755be"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/units-and-global-variables.html","domain":"docs.soliditylang.org","title":"Units and Globally Available Variables — Solidity 0.8.31-develop documentation","text":"Units and Globally Available Variables\n\n Edit on GitHub\n\nUnits and Globally Available Variables\n\nEther Units\nA literal number can take a suffix of wei, gwei or ether to specify a subdenomination of Ether, where Ether numbers without a postfix are assumed to be Wei.\nopen in Remix\nassert(1 wei == 1);\nassert(1 gwei == 1e9);\nassert(1 ether == 1e18);\n\nThe only effect of the subdenomination suffix is a multiplication by a power of ten.\n\nNote\nThe denominations finney and szabo have been removed in version 0.7.0.\n\nTime Units\nSuffixes like seconds, minutes, hours, days and weeks\nafter literal numbers can be used to specify units of time where seconds are the base\nunit and units are considered naively in the following way:\n\n1 == 1 seconds\n1 minutes == 60 seconds\n1 hours == 60 minutes\n1 days == 24 hours\n1 weeks == 7 days\n\nTake care if you perform calendar calculations using these units, because\nnot every year equals 365 days and not even every day has 24 hours\nbecause of leap seconds.\nDue to the fact that leap seconds cannot be predicted, an exact calendar\nlibrary has to be updated by an external oracle.\n\nNote\nThe suffix years has been removed in version 0.5.0 due to the reasons above.\n\nThese suffixes cannot be applied to variables. For example, if you want to\ninterpret a function parameter in days, you can in the following way:\nopen in Remix\nfunction f(uint start, uint daysAfter) public {\n if (block.timestamp >= start + daysAfter * 1 days) {\n // ...\n }\n}\n\nSpecial Variables and Functions\nThere are special variables and functions which always exist in the global\nnamespace and are mainly used to provide information about the blockchain\nor are general-use utility functions.\n\nBlock and Transaction Properties\n\nblockhash(uint blockNumber) returns (bytes32): hash of the given block when blocknumber is one of the 256 most recent blocks; otherwise returns zero\nblobhash(uint index) returns (bytes32): versioned hash of the index-th blob associated with the current transaction.\nA versioned hash consists of a single byte representing the version (currently 0x01), followed by the last 31 bytes\nof the SHA256 hash of the KZG commitment (EIP-4844).\nReturns zero if no blob with the given index exists.\nblock.basefee (uint): current block’s base fee (EIP-3198 and EIP-1559)\nblock.blobbasefee (uint): current block’s blob base fee (EIP-7516 and EIP-4844)\nblock.chainid (uint): current chain id\nblock.coinbase (address payable): current block miner’s address\nblock.difficulty (uint): current block difficulty (EVM < Paris). For other EVM versions it behaves as a deprecated alias for block.prevrandao (EIP-4399 )\nblock.gaslimit (uint): current block gaslimit\nblock.number (uint): current block number\nblock.prevrandao (uint): random number provided by the beacon chain (EVM >= Paris)\nblock.timestamp (uint): current block timestamp as seconds since unix epoch\ngasleft() returns (uint256): remaining gas\nmsg.data (bytes calldata): complete calldata\nmsg.sender (address): sender of the message (current call)\nmsg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)\nmsg.value (uint): number of wei sent with the message\ntx.gasprice (uint): gas price of the transaction\ntx.origin (address): sender of the transaction (full call chain)\n\nNote\nThe values of all members of msg, including msg.sender and\nmsg.value can change for every external function call.\nThis includes calls to library functions.\n\nNote\nWhen contracts are evaluated off-chain rather than in context of a transaction included in a\nblock, you should not assume that block.* and tx.* refer to values from any specific\nblock or transaction. These values are provided by the EVM implementation that executes the\ncontract and can be arbitrary.\n\nNote\nDo not rely on block.timestamp or blockhash as a source of randomness,\nunless you know what you are doing.\nBoth the timestamp and the block hash can be influenced by miners to some degree.\nBad actors in the mining community can for example run a casino payout function on a chosen hash\nand just retry a different hash if they did not receive any compensation, e.g. Ether.\nThe current block timestamp must be strictly larger than the timestamp of the last block,\nbut the only guarantee is that it will be somewhere between the timestamps of two\nconsecutive blocks in the canonical chain.\n\nNote\nThe block hashes are not available for all blocks for scalability reasons.\nYou can only access the hashes of the most recent 256 blocks, all other\nvalues will be zero.\n\nNote\nThe function blockhash was previously known as block.blockhash, which was deprecated in\nversion 0.4.22 and removed in version 0.5.0.\n\nNote\nThe function gasleft was previously known as msg.gas, which was deprecated in\nversion 0.4.21 and removed in version 0.5.0.\n\nNote\nIn version 0.7.0, the alias now (for block.timestamp) was removed.\n\nABI Encoding and Decoding Functions\n\nabi.decode(bytes memory encodedData, (...)) returns (...): ABI-decodes the given data, while the types are given in parentheses as second argument. Example: (uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes))\nabi.encode(...) returns (bytes memory): ABI-encodes the given arguments\nabi.encodePacked(...) returns (bytes memory): Performs packed encoding of the given arguments. Note that packed encoding can be ambiguous!\nabi.encodeWithSelector(bytes4 selector, ...) returns (bytes memory): ABI-encodes the given arguments starting from the second and prepends the given four-byte selector\nabi.encodeWithSignature(string memory signature, ...) returns (bytes memory): Equivalent to abi.encodeWithSelector(bytes4(keccak256(bytes(signature))), ...)\nabi.encodeCall(function functionPointer, (...)) returns (bytes memory): ABI-encodes a call to functionPointer with the arguments found in the tuple. Performs a full type-check, ensuring the types match the function signature. Result equals abi.encodeWithSelector(functionPointer.selector, (...))\n\nNote\nThese encoding functions can be used to craft data for external function calls without actually\ncalling an external function. Furthermore, keccak256(abi.encodePacked(a, b)) is a way\nto compute the hash of structured data (although be aware that it is possible to\ncraft a “hash collision” using different function parameter types).\n\nSee the documentation about the ABI and the\ntightly packed encoding for details about the encoding.\n\nMembers of bytes\n\nbytes.concat(...) returns (bytes memory): Concatenates variable number of bytes and bytes1, …, bytes32 arguments to one byte array\n\nMembers of string\n\nstring.concat(...) returns (string memory): Concatenates variable number of string arguments to one string array\n\nError Handling\nSee the dedicated section on assert and require for\nmore details on error handling and when to use which function.\n\nassert(bool condition)causes a Panic error and thus state change reversion if the condition is not met - to be used for internal errors.\n\nrequire(bool condition)reverts if the condition is not met - to be used for errors in inputs or external components.\n\nrequire(bool condition, string memory message)reverts if the condition is not met - to be used for errors in inputs or external components. Also provides an error message.\n\nrevert()abort execution and revert state changes\n\nrevert(string memory reason)abort execution and revert state changes, providing an explanatory string\n\nMathematical and Cryptographic Functions\n\naddmod(uint x, uint y, uint k) returns (uint)compute (x + y) % k where the addition is performed with arbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\n\nmulmod(uint x, uint y, uint k) returns (uint)compute (x * y) % k where the multiplication is performed with arbitrary precision and does not wrap around at 2**256. Assert that k != 0 starting from version 0.5.0.\n\nkeccak256(bytes memory) returns (bytes32)compute the Keccak-256 hash of the input\n\nNote\nThere used to be an alias for keccak256 called sha3, which was removed in version 0.5.0.\n\nsha256(bytes memory) returns (bytes32)compute the SHA-256 hash of the input\n\nripemd160(bytes memory) returns (bytes20)compute RIPEMD-160 hash of the input\n\necrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)recover the address associated with the public key from elliptic curve signature or return zero on error.\nThe function parameters correspond to ECDSA values of the signature:\n\nr = first 32 bytes of signature\ns = second 32 bytes of signature\nv = final 1 byte of signature\n\necrecover returns an address, and not an address payable. See address payable for\nconversion, in case you need to transfer funds to the recovered address.\nFor further details, read example usage.\n\nWarning\nIf you use ecrecover, be aware that a valid signature can be turned into a different valid signature without\nrequiring knowledge of the corresponding private key. In the Homestead hard fork, this issue was fixed\nfor _transaction_ signatures (see EIP-2), but\nthe ecrecover function remained unchanged.\nThis is usually not a problem unless you require signatures to be unique or use them to identify items.\nOpenZeppelin has an ECDSA helper library that you can use as a wrapper for ecrecover without this issue.\n\nNote\nWhen running sha256, ripemd160 or ecrecover on a private blockchain, you might encounter Out-of-Gas. This is because these functions are implemented as “precompiled contracts” and only really exist after they receive the first message (although their contract code is hardcoded). Messages to non-existing contracts are more expensive and thus the execution might run into an Out-of-Gas error. A workaround for this problem is to first send Wei (1 for example) to each of the contracts before you use them in your actual contracts. This is not an issue on the main or test net.\n\nMembers of Address Types\nThese members are explained in more detail in the section on members of address.\n\n<address>.balance (uint256)balance of the Address in Wei\n\n<address>.code (bytes memory)code at the Address (can be empty)\n\n<address>.codehash (bytes32)the codehash of the Address\n\n<address payable>.transfer(uint256 amount)send given amount of Wei to Address, reverts on failure, forwards 2300 gas stipend, not adjustable\n\n<address payable>.send(uint256 amount) returns (bool)send given amount of Wei to Address, returns false on failure, forwards 2300 gas stipend, not adjustable\n\nWarning\nsend() and transfer() are deprecated and scheduled for removal.\nSee the section on send and transfer for more information.\n\n<address>.call(bytes memory) returns (bool, bytes memory)issue low-level CALL with the given payload, returns success condition and return data,\nforwards all available gas (subject to additional limits imposed by some EVM versions), adjustable\n\n<address>.delegatecall(bytes memory) returns (bool, bytes memory)issue low-level DELEGATECALL with the given payload, returns success condition and return data,\nforwards all available gas (subject to additional limits imposed by some EVM versions), adjustable\n\n<address>.staticcall(bytes memory) returns (bool, bytes memory)issue low-level STATICCALL with the given payload, returns success condition and return data,\nforwards all available gas (subject to additional limits imposed by some EVM versions), adjustable\n\nFor more information, see the section on Address.\n\nWarning\nYou should avoid using .call() whenever possible when executing another contract function as it bypasses type checking,\nfunction existence check, and argument packing.\n\nWarning\nThere are some dangers in using send: The transfer fails if the call stack depth is at 1024\n(this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order\nto make safe Ether transfers, always check the return value of send, use transfer or even better:\nUse a pattern where the recipient withdraws the Ether.\n\nWarning\nDue to the fact that the EVM considers a call to a non-existing contract to always succeed,\nSolidity includes an extra check using the extcodesize opcode when performing external calls.\nThis ensures that the contract that is about to be called either actually exists (it contains code)\nor an exception is raised.\nThe low-level calls which operate on addresses rather than contract instances (i.e. .call(),\n.delegatecall(), .staticcall(), .send() and .transfer()) do not include this\ncheck, which makes them cheaper in terms of gas but also less safe.\n\nNote\nPrior to version 0.5.0, Solidity allowed address members to be accessed by a contract instance, for example this.balance.\nThis is now forbidden and an explicit conversion to address must be done: address(this).balance.\n\nNote\nIf state variables are accessed via a low-level delegatecall, the storage layout of the two contracts\nmust align in order for the called contract to correctly access the storage variables of the calling contract by name.\nThis is of course not the case if storage pointers are passed as function arguments as in the case for\nthe high-level libraries.\n\nNote\nPrior to version 0.5.0, .call, .delegatecall and .staticcall only returned the\nsuccess condition and not the return data.\n\nNote\nPrior to version 0.5.0, there was a member called callcode with similar but slightly different\nsemantics than delegatecall.\n\nContract-related\n\nthis (current contract’s type)The current contract, explicitly convertible to Address\n\nsuperA contract one level higher in the inheritance hierarchy\n\nselfdestruct(address payable recipient)Destroy the current contract, sending its funds to the given Address\nand end execution.\nNote that selfdestruct has some peculiarities inherited from the EVM:\n\nthe receiving contract’s receive function is not executed.\nthe contract is only really destroyed at the end of the transaction and revert s might “undo” the destruction.\n\nFurthermore, all functions of the current contract are callable directly including the current function.\n\nWarning\nFrom EVM >= Cancun onwards, selfdestruct will only send all Ether in the account to the given recipient and not destroy the contract.\nHowever, when selfdestruct is called in the same transaction that creates the contract calling it,\nthe behaviour of selfdestruct before Cancun hardfork (i.e., EVM <= Shanghai) is preserved and will destroy the current contract,\ndeleting any data, including storage keys, code and the account itself.\nSee EIP-6780 for more details.\nThe new behaviour is the result of a network-wide change that affects all contracts present on\nthe Ethereum mainnet and testnets.\nIt is important to note that this change is dependent on the EVM version of the chain on which\nthe contract is deployed.\nThe --evm-version setting used when compiling the contract has no bearing on it.\nAlso, note that the selfdestruct opcode has been deprecated in Solidity version 0.8.18,\nas recommended by EIP-6049.\nThe deprecation is still in effect and the compiler will still emit warnings on its use.\nAny use in newly deployed contracts is strongly discouraged even if the new behavior is taken into account.\nFuture changes to the EVM might further reduce the functionality of the opcode.\n\nNote\nPrior to version 0.5.0, there was a function called suicide with the same\nsemantics as selfdestruct.\n\nType Information\nThe expression type(X) can be used to retrieve information about the type\nX. Currently, there is limited support for this feature (X can be either\na contract or an integer type) but it might be expanded in the future.\nThe following properties are available for a contract type C:\n\ntype(C).nameThe name of the contract.\n\ntype(C).creationCodeMemory byte array that contains the creation bytecode of the contract.\nThis can be used in inline assembly to build custom creation routines,\nespecially by using the create2 opcode.\nThis property can not be accessed in the contract itself or any\nderived contract. It causes the bytecode to be included in the bytecode\nof the call site and thus circular references like that are not possible.\n\ntype(C).runtimeCodeMemory byte array that contains the runtime bytecode of the contract.\nThis is the code that is usually deployed by the constructor of C.\nIf C has a constructor that uses inline assembly, this might be\ndifferent from the actually deployed bytecode. Also note that libraries\nmodify their runtime bytecode at time of deployment to guard against\nregular calls.\nThe same restrictions as with .creationCode also apply for this\nproperty.\n\nIn addition to the properties above, the following properties are available\nfor an interface type I:\n\ntype(I).interfaceIdA bytes4 value containing the EIP-165\ninterface identifier of the given interface I. This identifier is defined as the XOR of all\nfunction selectors defined within the interface itself - excluding all inherited functions.\n\nThe following properties are available for an integer type T:\n\ntype(T).minThe smallest value representable by type T.\n\ntype(T).maxThe largest value representable by type T.\n\nReserved Keywords\nThese keywords are reserved in Solidity. They might become part of the syntax in the future:\nafter, alias, apply, auto, byte, case, copyof, default,\ndefine, final, implements, in, inline, let, macro, match,\nmutable, null, of, partial, promise, reference, relocatable,\nsealed, sizeof, static, supports, switch, typedef, typeof,\nvar.","tokens":4331,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267317629,"hash":"93070fa0dc008474c7addc52ccaf2e0d8893e719"}
{"url":"https://docs.optimism.io/governance/eas-attestations","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Optimism governance gives a voice to several distinct stakeholder groups: tokenholders, chains, apps, and end-users.\nToken House voting power is straightforward to establish — it follows OP token holdings.\nThe rest of the system is harder: the Citizens’ House uses a “1 member, 1 vote” model, Retro Funding rewards specific projects for their impact, and elected roles carry responsibilities across Seasons.\nAll of that requires a shared, verifiable answer to the question “who is this participant?” — without handing the answer to a private membership database.\nThe Collective’s answer is attestations: signed onchain statements, published where anyone can read and verify them.\nThis page explains what attestations are, how the Collective uses them, and why the model works the way it does.\n​Attestations and the Ethereum Attestation Service\nAn attestation is an onchain record in which one account (the issuer) makes a structured claim — for example, “this address is a Citizen” or “this project applied to Retro Funding Round 6.”\nAttestations in the Collective are built on the Ethereum Attestation Service (“EAS”), an open-source public good that is included as a predeploy in the OP Stack.\nEvery OP Stack chain ships with two EAS contracts at fixed addresses:\n\nThe EAS contract (0x4200000000000000000000000000000000000021), where attestations are created and stored.\nThe SchemaRegistry contract (0x4200000000000000000000000000000000000020), which holds the schemas that attestations are checked against.\n\nBecause these are predeploys, the same identity infrastructure is available on OP Mainnet, OP Sepolia, and any other OP Stack chain, with no extra deployment.\nFor predeploy details, see the smart contracts overview.\n​Schemas give attestations structure\nA schema defines the structure and type of data that an attestation can carry, and each schema has a unique identifier (UID).\nThis is what makes attestations machine-readable rather than free-form claims: an application that wants to check Citizenship looks for attestations issued against the specific Citizen schema UID, and knows exactly which fields (such as the member’s Farcaster ID and selection method) it will find there.\nThe full catalogue of schemas the Collective uses — with their UIDs, issuers, and field-by-field descriptions — is maintained in the EAS contracts and attestation schemas reference.\n​Trust comes from the issuer, not the statement\nAnyone can issue an attestation, so an attestation on its own proves only that someone made a claim.\nWhat makes an attestation meaningful is who issued it.\nCitizen attestations, for example, are only valid when issued by the Optimism Foundation, and the schema’s resolver contract enforces that check onchain.\nOther schemas document their expected issuer addresses so that consumers can verify them — several archived schemas explicitly remind readers to verify the attester address before trusting the record.\nThis is the core design trade-off: rather than a closed registry that must be queried and trusted wholesale, the Collective publishes individually signed claims and lets every consumer verify the issuer for themselves.\n​How the Collective uses attestations\n​Citizenship\nMembership in the Citizens’ House is represented by Citizen attestations, first issued in Season 6.\nA Citizen attestation identifies the member (by Farcaster ID), records how they were selected, and — for chain and app Citizens — references the organization or project they represent.\nCitizenship is recorded separately from the ability to vote in any specific Retro Funding round.\nTo learn who is eligible and how to register, see the governance FAQ.\n​Projects and organizations\nProjects and organizations in the Collective (as registered in OP Atlas) are identified by attestations: an identifier attestation acts as the project’s unique ID, and metadata attestations — re-issued each time something changes — associate names, categories, and metadata locations with it.\nThis is how Retro Funding knows which project an application, approval, or reward belongs to.\n​Retro Funding and grants\nThe Retro Funding lifecycle is recorded as a chain of attestations: applications to a round, approval or rejection decisions, voting badges for the round’s voters, and finally the reward amount each approved project received.\nToken House grant approvals and governance contributions (such as serving on the Grants Council) are attested in the same way.\n​Proof of personhood\nFor end-user Citizens, the Collective relies on external proof-of-personhood systems — World ID and Passport — alongside attestations such as Gitcoin Passport scores.\nUntil Sybil-resistance mechanisms are more mature, the Optimism Foundation may suspend Citizens flagged as possible Sybils and request further verification of unique personhood.\n​Next steps\n\nLook up contract addresses, schema UIDs, and field definitions in the EAS contracts and attestation schemas reference.\nRead or issue attestations via EAS scan for OP Mainnet or the EAS SDK.\nLearn how the Token House and Citizens’ House use these identities in the governance FAQ.\nWas this page helpful?","tokens":1283,"squid":"ink-governance","role":"Council Listener","at":1791267317679,"hash":"cbe5d01c046b1a1512826ebd324c3458caa45e93"}
{"url":"https://forum.pyth.network/c/community-council/10","domain":"forum.pyth.network","title":"Latest Community Council topics - Pyth DAO","text":"Latest topics in Community Council\n\n Community Council\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n [Community Council #1] Council Members\n\n On March 27th, 2025, the first-ever Community Council has been elected and approved by the Pyth DAO through onchain voting. \nAs a reminder, at least 1 member of the Community Council has to be replaced every 12 months. \nA…\n\n read more\n\n 3\n\n 286\n\n Apr 24\n\n About the Community Council\n\n Community Council is in charge of incentives, grants and growth programs from within the Pyth Community. \nThe community council has the power to allocate $PYTH and support ecosystem projects, members and growth initiativ…\n\n read more\n\n 1\n\n 215\n\n Feb 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n 4\n\n 272\n\n 9d\n\n Community Hackathon post-mortem\n\n 6\n\n 238\n\n May 31\n\n Community Hackathon KYC Request\n\n 8\n\n 194\n\n May 26\n\n Community Council Term 2 Budget Request\n\n 4\n\n 331\n\n Apr 14\n\n Pythian Content Arsenal\n\n 5\n\n 328\n\n Apr 5\n\n [Community Council Election #2] Spank , Pyth Network Chiron\n\n 1\n\n 102\n\n Apr 3\n\n Community Council Election #2 - Totti, Pyth Network Chiron\n\n 1\n\n 128\n\n Apr 3\n\n [Community Council Election #2] Borys , Pyth Network Chiron\n\n 2\n\n 242\n\n Apr 3\n\n [Community Council Election #2] theRoad, Pyth Network Mensarius\n\n 0\n\n 67\n\n Apr 1\n\n Pyth Content Referrals System\n\n 0\n\n 342\n\n Mar 30\n\n [Community Council Election #2] SCP, Pyth Network Aristophanes\n\n 0\n\n 98\n\n Mar 29\n\n Community Council Term #1 Exit Report\n\n 4\n\n 194\n\n Mar 29\n\n Community Council Election #2 CryptoKelly Low Priest/Macro Analyst\n\n 0\n\n 75\n\n Mar 29\n\n [Community Council Election #2] Mersault , Pyth Network Chiron\n\n 1\n\n 120\n\n Mar 28\n\n [Community Council Election #2] Samurai , Pyth Network Chiron\n\n 0\n\n 109\n\n Mar 27\n\n Community Council Election #2 - Kirito, Pyth Network venus de milo\n\n 0\n\n 98\n\n Mar 27\n\n Guide for the Community Council Election #2\n\n 0\n\n 269\n\n Mar 26\n\n Impact Awards Bot: Enabling Community $PYTH Rewards\n\n 2\n\n 147\n\n Oct 2025\n\n Community Council Report & 6month Budget Extension\n\n 11\n\n 445\n\n Sep 2025\n\n Strengthening the Bridge: How the Community Council Can Amplify the Pythian Council’s Work\n\n 2\n\n 87\n\n Jul 2025\n\n Guide for the Community Council Election #1\n\n 6\n\n 412\n\n Mar 2025","tokens":566,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267321295,"hash":"1df658b8a20b2eca8a124c673a2acdb8e4efecae"}
{"url":"https://docs.optimism.io/governance/resources","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This page collects the governing documents, dashboards, trackers, reports, and addresses referenced throughout Optimism governance.\nStart with the Superchain Health Dashboard for an overview of the state of the Superchain.\n​Governing documentation\n\nOperating Manual\nWorking Constitution of the Optimism Collective\nStandard Rollup Charter\nLaw of Chains\nDecentralization Milestone Working Model\nDecision Diagram Working Model\nOptimist Expectations\n\n​OP trackers\n\nOptimism GovFund Grants: Public Delivery Tracking\nOP Token Unlock (Estimated)\n\n​Foundation budget reports\n\nThese can be found here on the governance forum.\n\n​Retroactive Public Goods Funding round results\n\nThese can be found here on retrofunding.optimism.io.\n\n​Relevant addresses\nYou can find the list of wallets across L1 and OP Mainnet where the Optimism Collective Revenue earned sits here, on the right-hand side of the Collective Contribution page.\n\nOP Treasury Address for Foundation Allocated Budget: 0x2A82Ae142b2e62Cb7D10b55E323ACB1Cab663a26\n\nThis address holds the remaining OP tokens allocated to the Foundation, which the Foundation requires governance approval to access (via annual FND budget proposals).\n\nOP Treasury Address for Foundation Approved Budget: 0x2501c477D0A35545a387Aa4A3EEe4292A9a8B3F0\n\nThis is the Foundation’s OP Treasury which is available for the Foundation to utilize as the Foundation’s budget granted through the initial token allocation. Transactions from this wallet are typically internal operational movements per the Foundation’s needs.\nAdditional tokens may be moved from 0x2…3a26 to 0x2…B3F0 based on governance approval of budgets.\n\nOP Foundation Grants Wallet: 0x19793c7824Be70ec58BB673CA42D2779d12581BE\n\nThis Foundation wallet is used to make private OP grants. This is topped up from the OP Treasury Foundation Approved Budget wallet 0x2…B3F0 as needed.\n\nOP Foundation Locked Grants Wallet: 0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F\n\nThis Foundation wallet is used to hold OP for one year lockups. This is topped up from the OP Foundation Grants Wallet 0x1…81BE as needed.\n\n​Optimism governance calendar\n\nYou can find a link to the Governance Calendar here.\nWas this page helpful?","tokens":547,"squid":"ink-governance","role":"Council Listener","at":1791267339695,"hash":"571611422b9248fc01d46d1bd9ccfb21000dcb79"}
{"url":"https://forum.pyth.network/t/community-hackathon-post-mortem/2518/7","domain":"forum.pyth.network","title":"Community Hackathon post-mortem - Community Council - Pyth DAO","text":"Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 10\n min\n\n May 6\n\n 7 / 7\n\n May 31\n\n May 31\n\n post by Chop on May 6\n\n Chop\n\n PYTH COMMUNITY HACKATHON\nROUND 1\nProgram Report\nCommunity Hackathon for AI-Assisted Builders\n36 Projects | 200,000 PYTH | 4 Weeks\nPrepared by Choppa (@ChoppaTheShark)\nCommunity Lead, Pyth Network\nApril 7, 2026\nTable of Contents\nExecutive Summary\nPyth Community Hackathon ran as a four-week community hackathon designed to test a thesis: if AI coding tools eliminate the programming barrier, what will the Pyth community build with our data?\nThe results exceeded expectations. 36 projects shipped across DeFi infrastructure, analytics, gaming, AI agents, and utility tools. Every Pyth product was utilized — Price Feeds, Entropy, Pyth Pro, and Benchmarks. Builders deployed across five blockchains (Solana, Base, Ethereum, FOGO, Optimism) covering crypto, forex, commodities, and equities.\nI’ve written this report to provide a complete overview for the PDA, for whom this program benefits the most. It covers the strategic rationale, execution details, submission analysis, key findings, media distribution plan, and recommendations for continued hackathons in 2026 & 2027.\n\nTotal Projects Submitted\n36\n\nPrize Pool\n~200,000 PYTH\n\nDuration\n4 weeks (March 4 – April 1, 2026)\n\nJudging Period\nApril 2–15, 2026\n\nAPI Keys Issued\n32 (36 projects shipped — community outran infra)\n\nPyth Products Used\nPrice Feeds (34), Entropy (15+), Pyth Pro (5), Benchmarks (4)\n\nChains Represented\nSolana, Base, Ethereum, FOGO, Optimism\n\nAsset Coverage\nCrypto, Forex, Commodities, Equities\n\nAll Licenses\nApache 2.0 (open source)\n\nStrategic Context\nThe Pyth Community Hackathon does not exist in isolation. It is one execution layer within two converging strategic priorities for Pyth Network in 2026.\nAI Discoverability — The #1 Priority\nPyth’s competitive position depends on whether AI systems recommend Pyth when developers ask how to get price data. As of February 2026, Bloomberg holds 33.7% LLM visibility versus Pyth’s 5.7%. That gap closes with content, not code. In this context, every hackathon submission generates a plethora of natural derivative content: forum posts, GitHub repos, Dev.to articles, Reddit threads, Twitter posts. 36 projects produced an estimated 100+ public-facing content artifacts — all mentioning Pyth usage, all crawlable by LLM training pipelines, all hosted on indexed domains. LLM Gold.\nStrategic value: Pyth Community Hackathon is a GEO (Generative Engine Optimization) multiplier. Each builder creates content that teaches AI models what Pyth is, what it does, and why developers should use it. Every project is a concrete example and use case for Pyth data.\nThe Agent Economy — Positioning for the future.\nAutonomous agents (bots, AI operators, automated trading systems) already drive a significant share of on-chain activity. They need real-time, oracle-grade price data to function. Pyth is that price layer.\nThe hackathon was designed to prompt and produce working examples. The Pyth MCP Server was included as a starter kit, which meant AI coding assistants (Claude, Cursor, Replit Agent) were pulling live Pyth data during the build process itself. Agents using oracle data to build applications that use oracle data. That loop happened organically, without anyone designing specifically for it.\nThree submissions are themselves autonomous agents: NeuroTrade streams Pyth Pro data and executes trades through Jupiter with zero human input. SignalForge runs a 24/7 bot monitoring prediction markets against Pyth feeds with Kelly Criterion position sizing. Ouroboros takes a natural language description and autonomously generates, compiles, and deploys a Pyth-powered dApp.\nThese are working agent-to-oracle pipelines. Built in four weeks. By community members. Not a pitch deck — a proof point.\nThe Vibe Coding Thesis\nThe core bet behind Pyth Community Hackathon was that AI coding tools have collapsed the barrier between “I have an idea” and “I have a working application.” The traditional hackathon assumption — participants must know Solidity, Rust, or at minimum JavaScript no longer holds.\nResults seem to have validated this thesis. Builders with no prior blockchain experience shipped DeFi primitives (Aletheia’s confidence-adaptive RFQ), research-grade analytics (RegimeIQ’s oracle microstructure analysis), and complex gaming systems (Tower of Entropy’s full RPG). AI tools wrote the code. Pyth provided the data. The builders provided the ideas.\nThis overlal projected has changed how the developer onboarding funnel works entirely (especially when considering future iterations of the hackathon). “Docs → Tutorial → Abandoned project” can now credibly be replaced by “Browse cool projects → Fork one → Make it yours.” Pyth Community Hackathon generates the a live project gallery that powers this new funnel for all future developers and builders.\nProgram Design & Execution\nStructure\nPyth Community Hackathon Round 1 was organized by the Pyth Community Council (elected governance body) and coordinated by Choppa (@ChoppaTheShark, Community Lead). The organizing entity is PYTH DAO LLC (Marshall Islands).\n\nSubmission Period\nMarch 4 – April 1, 2026\n\nJudging Period\nApril 2–15, 2026\n\nResults Announcement\nApril 15, 2026\n\nPlatform\ndev-forum.pyth.network (submissions) + Discord (community)\n\nEligibility\n18+, excludes OFAC-sanctioned jurisdictions\n\nTeam Size\nMax 2 per submission\n\nKYC\nPDA (Pyth Data Association) handles KYC for prize winners only\n\nPrize Structure\n\nTier\nReward\n\n1st Place\n50,000 PYTH\n\n2nd Place\n30,000 PYTH\n\n3rd Place\n15,000 PYTH\n\n4th–10th Place\n5,000 PYTH each (35,000 total)\n\nCommunity Choice Award\n10,000 PYTH\n\nBest Pyth Pro Use\n10,000 PYTH\n\nBest Educational Content\n10,000 PYTH\n\nParticipation (valid submission)\n500–1,000 PYTH\n\nUpvote Bonuses\n10 upvotes (+500) to 100 upvotes (+5,000)\n\nJudging Criteria\n\nCriteria\nWeight\n\nPyth Integration Depth\n30%\n\nCreativity & Innovation\n25%\n\nExecution Quality\n20%\n\nUser Experience\n15%\n\nDocumentation\n10%\n\nResources Provided\nBuilders basic starter kits, 30 project ideas across 5 categories (HFT, DeFi, Analytics, User Tools, Infrastructure), three pinned forum guides (Official Rules, Submission Template, Judging Rubric & FAQ), and direct access to Pyth Pro API keys on request.\nComplete Project Catalog\nAll 36 submissions are listed below, organized by the content priority tiers used for the media distribution plan. Every project is open-source (Apache 2.0) and most have live demos.\n\nProject\nBuilder\nCategory\nPyth Products\nChain / Demo\n\nMarket DVR\nWattson\nInfrastructure\nPrice Feeds, Pyth Pro\nVPS\n\nAletheia RFQ\npap0nt\nDeFi\nPrice Feeds (on-chain)\nBase\n\nThe Market Witness\nJoestar\nCreative/Education\nHermes, Benchmarks\nVercel\n\nRegimeIQ\ncodeglitch\nAnalytics\nHermes SSE, Confidence\nVPS\n\nFOGO Pulse\ntheRoad\nDeFi\nPyth Lazer, Hermes WS\nFOGO\n\nPythCorrelation\nrustrell\nAnalytics\nHermes, Benchmarks, Entropy\nVercel\n\nSignalForge\nSmartbott\nTrading\nHermes API + WS\nRailway\n\nPirb.swap\nDera\nDeFi\nPrice Feeds (Hermes V2)\nSolana\n\nNeuroTrade\nSCP\nTrading\nPyth Pro WS\nSolana\n\nOuroboros\npstar\nInfrastructure\nPrice Feeds, Entropy\nBase\n\nPythGuard\nSueno\nAnalytics\nPrice Feeds, Pyth Pro, Entropy\nSolana\n\nLiquidSense\nMAYTH\nDeFi\nHermes Price Data\nBase\n\nTerminal by nik0\nNik0\nAnalytics\nHermes, Benchmarks\nVercel\n\nPythVision\nJaybrass\nAnalytics\nPrice Feeds, Entropy V2\nEthereum/Base\n\nPythReceipt\nviperx\nDeFi\nPrice Feeds, Pyth Pro Lazer\nSolana\n\nPyth Sentinel\nInvestor_Daniel\nUtility\nPrice Feeds, Entropy\nRailway\n\nCoindle\ndroober\nGame\nHermes API\nVercel/Farcaster\n\nPIRBGEN\nmersault\nGame\nPrice Feeds, Entropy\nBase\n\nPyngo\nenoo\nGame\nPrice Feeds, Entropy\nVPS\n\nPyth Defender\nKhaleesi\nGame\nHermes REST, Entropy\nGitHub Pages\n\nPythian Peso Snake\ntotti\nGame\nEntropy (Optimism)\nNetlify\n\nWhac-a-Pythenian\nRicardoReyes\nGame\nEntropy\nVercel\n\nTower of Entropy\nFlint\nGame\nEntropy, Price Feeds\nBase\n\nPyth Casino\nsurojitpvt\nGame\nHermes Price Feeds\nSolana/Base\n\nPyth Arcade\nAgarwal\nGame\nPrice Feeds, Entropy\nVercel\n\nSleeve\ndexter\nGame\nLazer Pro, Entropy\nBase\n\nWalk The Planck\nQuintzor\nGame\nEntropy\nBase\n\nOrra\nemjayrntr\nGame\nPrice Feeds, Entropy\nBase\n\nPyPredict\nBam4bam\nDeFi\nHermes API (17 feeds)\nVercel\n\nPythPulse\nBankybemma\nAnalytics\nHermes REST (38 feeds)\nVercel\n\nOracle Flow\nSugoi\nAnalytics\nPrice Feeds\nVercel\n\nRektoMeter\nranimth07\nUtility\nHermes API (500+ assets)\nVercel\n\nPrice Prediction Grids\nShubh\nGame\nPrice Feeds, Entropy\nSolana\n\nPolyJackpot\njoshjosh11\nGame\nEntropy\nBase\n\nd1ckochart\noldtora\nCreative\nHermes API\nVercel\n\nQTCL Blockchain\nshemshallah\nInfrastructure\nPrice Feeds, Entropy\nQTCL\n\nCategory Analysis\nThe 36 submissions naturally cluster into six categories, revealing how the community thinks about oracle data utility.\nGames & Entertainment (14 projects)\nThe largest category by volume. Ten of these use Pyth Entropy for verifiable randomness. Projects range from simple browser games (Pythian Peso Snake, Pyth Defender) to complex systems (Tower of Entropy’s full RPG, PIRBGEN’s competitive trading arcade). The Market Witness bridges gaming and education through AI-powered courtroom drama.\nKey insight: Entropy is the entry drug. Provably fair randomness is an easy-to-understand value proposition that gets builders interacting with Pyth infrastructure. Many of these builders will graduate to Price Feed and Pyth Pro integrations.\nAnalytics & Monitoring (8 projects)\nProfessional-grade tools including PythCorrelation (28+ asset cross-correlation), PythPulse (38-feed anomaly detection), RegimeIQ (oracle microstructure analysis), and multiple market terminals. Several use Pyth Benchmarks for historical data alongside real-time feeds.\nKey insight: The multi-asset coverage (crypto + forex + commodities + equities) was a major differentiator. Builders leveraged Pyth’s breadth in ways that single-asset oracles cannot support.\nDeFi Infrastructure (6 projects)\nThe most technically sophisticated category. Includes confidence-adaptive settlement (Aletheia), liquidation monitoring with macro signals (PythGuard, LiquidSense), slippage protection (Pirb.swap), liquidation receipts (PythReceipt), and prediction markets (FOGO Pulse, PyPredict).\nKey insight: Builders treated confidence intervals as functional infrastructure, not informational. Three separate projects independently arrived at “confidence as a gate” — a pattern worth elevating as a Pyth design principle.\nTrading Agents & Tools (5 projects)\nAI-powered trading systems including NeuroTrade (local-first agent streaming Pyth Pro), SignalForge (prediction market bot using the same oracle for signals and settlement), and Ouroboros (AI agent generating entire Pyth dApps from natural language).\nKey insight: Direct validation of the agent economy thesis. These are working prototypes of autonomous systems paying for and consuming oracle data.\nInfrastructure (3 projects)\nMarket DVR (Pyth Pro market replay), Ouroboros (AI dApp generator), and QTCL Blockchain (post-quantum price attestation). The most ambitious and differentiated submissions.\nUtility (2 projects)\nRektoMeter (airdrop P&L tracking with 500+ Pyth-priced assets) and Pyth Sentinel (price alerts with oracle-grade data). Practical tools demonstrating everyday use cases.\nPyth Product Usage Analysis\nThe hackathon served as a live stress test of Pyth’s product surface, and developer experience. The distribution of product usage reveals how builders naturally discover and adopt Pyth’s capabilities.\n\nProduct\nUsage\nHow Builders Used It\n\nPrice Feeds\n34/36\nCore data layer. Real-time crypto, forex, commodities, equities. Both on-chain and off-chain (Hermes) consumption.\n\nEntropy\n15+/36\nVerifiable randomness for games, lotteries, prediction markets. Commit-reveal protocol for provably fair mechanics.\n\nPyth Pro (Lazer)\n5/36\nSub-second institutional feeds. Used by most technically advanced projects (Market DVR, NeuroTrade, FOGO Pulse, PythReceipt, Sleeve).\n\nBenchmarks\n4/36\nHistorical OHLCV data for backtesting, charting, and correlation analysis.\n\nDiscovery pattern: Price Feeds are the entry point. Entropy is the engagement hook (especially for games). Pyth Pro is discovered by advanced builders who need speed or historical depth. Benchmarks are used by analytics-focused projects.\nDeliverable 1: Project Spotlight Tweets\n36 individual project tweets from @CHOPPAtheSHARK (commentary, personality). Projects are tiered by quality: Tier 1 (7 deep features), Tier 2 (9 spotlight posts), Tier 3 (20 community/game posts). Posted with links, screenshots and callouts for the individual builders.\nDeliverable 2: Hackathon Recap Article\nA large-ish reflection article blending thesis (vibe doing supremecy) with evidence from each project. Covers the experiment, what got built (organized by category), and three key findings. Written as a complimentary ‘community strength’ blog. Posted to both Twitter and the Governance Forum as a review.\nCommunities Key Findings & Lessons Pyth can learn\n1. Long live vibe coding\nBuilders with no prior blockchain experience shipped basic DeFi primitives, genuine research-grade analytics, and relatively complex gaming systems in under 4 weeks. The almost ALL of the code was AI generated. This should frame Pyth’s thinking significantly into the future as we lead the charge in subscription based first party financial data. This is particularly important as we open up the product suite to retail audiences. Proving what is possible with Pyth to the every day consumer is an important market segment.\n2. Pyth’s Product Surface Is Deeper Than Perceived\nThere was significant diversity in products built. Each community member independently discovered that confidence intervals can serve as execution gates, oracle microstructure can function as a risk signal, Entropy enables entirely new game (and trading) mechanics, and Pyth Pro unlocks institutional-grade capabilities. Builders treated Pyth data as a premium product that would help inform their decision making processes, and allow them to execute with precision. This demonstrates the perception of Pyth as a premium product is well set.\n3. Community Outran Infrastructure\n34 API keys were issued. 36 projects shipped. More people submitted without keys than with them. The bottleneck was not interest or capability — it was awareness and distribution. Round 2 should solve for reach, not resources.\n4. Entropy Is a great Onboarding Funnel\n15+ projects used Entropy, making it the second most popular product after Price Feeds. Provably fair randomness is an easy-to-understand value proposition that gets builders interacting with Pyth infrastructure. The games category (14 projects) was the largest. Entropy-first onboarding could become a deliberate strategy for onboarding low level applications and developers to Pyth.\n5. “Confidence as a Gate” Is an Emergent Pattern\nThree separate projects (Aletheia, FOGO Pulse, PythReceipt) independently arrived at using confidence intervals as functional gates — blocking trades, refunding bets, or halting liquidations when oracle uncertainty exceeds thresholds. This framing does not appear in any of Pyth’s documentation and was not mentioned in any of the Hackathon onboarding materials. Builders discovered this ‘feature set’ organically. This pattern should be elevated as an official Pyth design principle with dedicated documentation and examples. It provides Pyth with a VERY clear point of difference against other price data solutions while also doubling as a monetisable feature of the product suite.\n6. Content Generation Was Organic\nWithout requiring it, builders produced Dev.to articles, GitHub repositories, Reddit posts, and video demos. The hackathon generated 100+ public content artifacts mentioning Pyth — all indexed, all crawlable, all contributing to AI discoverability. Round 2 should formalize this with explicit content requirements for bonus rewards, and also show content examples from previous hackathon submissions.\n7. Reframe Pyth Pro usage\nCommunity was given ‘free access to Pyth Pro’. In the next iteration of the hackathon, framing for this event should instead be around Pyth giving away Pyth Pro credits to the tune of “X” amount of value that people can then use on a monthly basis. This promotes Pyth’s exclusivity whilst demonstrating the innate value of the data being used.\nCoordinator’s Reflections\nThe following observations are editorial — drawn from running this program end-to-end as coordinator. They supplement the analytical findings above with operational and philosophical takeaways.\nWhat This Hackathon Proved\n1. We underestimate people’s willingness to contribute\nMy assumptions going in was that the Prize money was going to be too low to attract attention. It wasn’t. Builders showed up because they found the challenge interesting. Most importantly, they wanted a chance to use the same data institutions do, in order to ‘level the playing field’. Many submitted projects that clearly took more hours than the prize pool could justify on a purely economic basis. I think it’s quite clear that giving a community something genuinely interesting to work on and the tools to do it, the participation problem solves itself. The bottleneck was never motivation — it was mostly about access to the data and awareness of the program. This is exciting for future iterations of the Hackathon.\n2. It’s not all about prizes\nThis was a very modest prize pool by crypto hackathon standards. Monad recently ran a hackathon with a 500k USD funding price. The Pyth Community Hackathon cost 100x less to run. What we received back in content, open-source code, product innovation, and ecosystem awareness far exceeded the cost. The ratio of value created to PYTH distributed is lopsided in our favor. Builders contributed because they were excited to build with PREMIUM financial data, not because the payout was life-changing. That’s a great signal for the Pyth brand — it means this model scales without requiring exponential budget increases, and that we have a ‘premium’ attached to our brand.\n3. Novel ideas for Pyth data still exist beyond what we know\nMultiple submissions genuinely surprised me with their breadth and creativity. Confidence intervals as trade execution gates (Aletheia), oracle microstructure as a risk signal (RegimeIQ), confidence-aware settlement refunds (FOGO Pulse), oracle speed as a competitive gameplay mechanic (PIRBGEN), a courtroom drama using price data as evidence (The Market Witness) — none of this stuff was in the project ideas list. The community found use cases for Pyth data that we, as the team closest to the product, had not considered. This means the surface area of what’s possible is larger than our internal imagination, and hackathons are the most efficient way to map that territory. We get to lean in to community and build a brand while ALSO pushing the boundaries of what Pyth data can do.\n4. Running this is harder than it looks\nThe organizational requirements of a program like this are substantial: legal (T&Cs, KYC, jurisdiction compliance), infrastructure (forum setup, API key management, submission tracking), content scheduling (promotional cadence, builder communications, judge coordination), and community management (answering questions, troubleshooting, maintaining momentum over four weeks). This was running this alongside every other active workstream, which was quite difficult. Had this been my sole focus, I think Pyth would have have extracted significantly more value: better promotional cadence, more builder support, tighter content pipeline, and a much more polished showcase event. The biggest thing to learn here is that dedicated operational bandwidth for programs like this can multiply the already substantial output of the program.\n5. Our products are intuitive\nOf 36 submissions, only 4 required any form of technical support. Two were API-related issues easily resolved with a key refresh. The other two were users not fully grasping speed variance in select assets — a comprehension issue, not a product issue. That’s a 89% zero-support rate from builders who, in many cases, had never interacted with oracle/data/price infrastructure before. The MCP Server, Hermes API, and Entropy documentation are doing their job. The products work the way developers expect them to work. That’s not a given in this industry, and it’s worth recognizing.\nMoving Forward — Strategic Vision\nBeyond the tactical recommendations for Round 2, this hackathon opens several larger strategic opportunities for Pyth Network & the community.\nA Community Hub for Live Projects\nMany of these projects function as genuine public goods. The Entropy-powered games, price feed monitors, correlation dashboards, liquidation radar’s are all fantastic, simple consumer products. They deserve to live beyond the hackathon as a showcase of what the community & Pyth data can do.\nI propose that we build a community hub (extension of Pythentity) that showcases select projects, provides them with full and free access to a single dedicated API key under the Pythenians banner, and keeps them running as permanent demonstrations of what Pyth data enables. Not a graveyard of demo links. A living gallery that everyone has access to, and the community owns.\nA Living Library of What’s Possible\nEach hackathon round adds to a growing library of what can be built with Pyth. Over time, this becomes an extremely powerful resource & tool in the ecosystem. Something distinctly different from documentation & tutorials. This would be a display of working applications that make people say “I could build that.” Community hackathons become the input layer for this library. Every round surfaces new patterns, new use cases, and new reference implementations that future builders (and Pyth users) can fork, extend, and improve.\nBrand Positioning: Champions of Open Building\nAs an organization, hosting and leaning into community hackathons frames Pyth as champions of open building and democratized access to financial data. The only limiting factor is being a part of the community. Bloomberg charges $24,000 per year for data that Pyth makes available for free, regularly. Running hackathons and having 36 community members build working products in four weeks (using AI tools, no barriers to entry or coding expertise required) imbues the event with a lot more meaning. It becomes a proof point for Pyth’s entire forward looking thesis. The brand perception compounds: Pyth data allows anyone to build with institutional-grade financial data. The hackathon is evidence of this - and it is continually reinforced the more we lean in.\nA Core Part of the Community Offering\nIn my opinion, Pyth would be well served by this program becoming a significant, recurring part of Pyth’s community offering. The appeal is twofold:\nFor retail and community builders: The opportunity to play with the same data that institutions pay for. To build something real with oracle-grade price feeds, verifiable randomness, and sub-second data — tools that were previously locked behind enterprise contracts and six-figure budgets. This is what makes a community sticky: not Discord roles, not airdrops, but the ability to create something meaningful with infrastructure that matters.\nFor builders and businesses: A testing ground for product ideas. A way to evaluate Pyth’s product surface without procurement cycles or sales calls. A gallery of reference implementations that demonstrate integration patterns. Several hackathon submissions are closer to MVPs than prototypes — businesses watching this space now have 36 open-source examples of what Pyth integration looks like in practice. That’s a sales pipeline built by people who love Pyth, for Pyth.\nThis creates a pretty obvious feedback loop: run hackathons, surface innovation, showcase the results, attract more builders, run more hackathons. Each round generates content (AI discoverability), demonstrates products (sales pipeline), rewards contributors (community flywheel), and produces open-source code (ecosystem infrastructure). Pyth doesn’t have a program or touchpoint that touches all four simultaneously. The Community Hackathon does.\nTactical Recommendations for Round 2\nScale Distribution\nRound 1 relied primarily on the developer forum and Discord for awareness. Round 2 should include more Twitter/X promotion from @PythNetwork, partnership with Superteam Earn for distribution, university outreach (three warm academic leads are active), and very specific collaboration with chain partners who may also be able to offer incentives or comarketing.\nFormalize Content Requirements\nRequire each submission to create at least one public-facing content artifact (Reddit post, Dev.to article, or GitHub example). Offer bonus PYTH for additional content. This transforms the hackathon from a builder event into an AI discoverability multiplier.\nIntroduce ‘Track’ System\nRound 1 was open-ended. Round 2 should offer themed tracks (DeFi Infrastructure, Agent Economy, Analytics, Gaming/Consumer) with track-specific prizes. This enables more targeted judging and produces cleaner content narratives. Alternatively, Pyth makes theme specific Hackathons that only look to reward and incentivise certain product verticles (eg; agentic trading)\nIntegrate with Content Incentive Stack\nPyth Community Hackathon should feed into the broader content incentive pipeline: MissionMonitor (live) for post-hackathon content missions for ongoing builder engagement. Round 2 participation should grant access to these systems and reward users for the deeper participation in community events.\nIncrease Pyth Pro Adoption — Reframe Access as a Grant\nOnly 5 of 36 projects used Pyth Pro in Round 1. Round 2 should fix that — not by making it “free,” but by making the value visible.\nThe marketing frame: Pyth makes available $X worth of Pyth Pro credits to the community over the hackathon period. Builders receive access to institutional-grade, sub-second data (the same feeds that paying subscribers use) as a community grant. The dollar value is stated explicitly. Every participant knows what they’re getting and what it normally costs.\nThis does three things simultaneously.\nFirst, it positions the hackathon as a gratuity event — Pyth giving real value to its community, not handing out free trials.\nSecond, it anchors Pyth Pro’s market price in every builder’s mind. They experience the product, see the price tag, and understand the value proposition without a sales call.\nThird, it creates a natural conversion pipeline — builders who used Pyth Pro credits during the hackathon are the warmest leads for paid subscriptions after it ends.\nPair this with a dedicated Pyth Pro starter kit (sub-second data consumption, historical benchmarks, bid/ask spread analysis) and a “Best Pyth Pro Use” bonus track with a higher reward to incentivize deeper integration.\nDedicate Operational Bandwidth\nRound 1 was coordinated alongside all other active workstreams. Round 2 should either be the coordinator’s primary focus during the active period, or have a second operator handling promotional cadence, builder communications, and content scheduling. The program delivers — but dedicated bandwidth from others within the community council would multiply the output.\nBudget & Resource Utilization\n\nItem\nAmount\n\nTotal Prize Pool\n~200,000 PYTH (from Community Council allocation)\n\nTop 3 Prizes\n95,000 PYTH (50K + 30K + 15K)\n\n4th–10th Place\n35,000 PYTH (7 × 5,000)\n\nSpecial Awards\n30,000 PYTH (3 × 10,000)\n\nInfrastructure Costs\nMinimal (forum hosting, API keys)\n\nThe program represents strong ROI: 36 open-source projects, 100+ content artifacts, 5+ working DeFi primitives, and a validated program template for future rounds — all from a single community council budget allocation. Cost per project: approximately 5,500 PYTH.\n\n 2\n\n read \n\n 10\n min\n\n post by CrownOfLagos on May 6\n\n CrownOfLagos\n\n Oh this so great\nFull details of the Pyth Hackathon round 1, I love this so much just finish reading through.\nBig shoutout the the Community council members and specially to @Chop you did great sir\n\n post by Ricardo on May 6\n\n Ricardo\n\n Discovering and rewarding brilliant ideas and talent, that’s how you know you’re in the right place !\n\n post by totti on May 11\n\n totti\n\n absolute banger of a read, and great strategy targeting AI discoverability - with AI.\nThanks choppa\n\n post by Smartbott on May 17\n\n Smartbott\n\n Hey choppa, thanks for the post-mortem. Quick clarification on the bonus prizes — the original hackathon announcement listed two additional categories that don’t appear in this wrap-up:\nWikipedia contribution mentioning Pyth (verified): +5,000 PYTH\nQuality X content about Pyth and/or what you have built: +1,000 PYTH\n\n post by Wattson on May 21\n\n Wattson\n\n This was fun, looking forward to the next one choppa\n\n 9 days later\n\n post by Smartbott on May 31\n\n Smartbott\n\n Regarding Prize Distribution Delays — Community Trust Concern\nI want to raise a constructive concern about the prize distribution timeline for Round 1.\nTimeline for context:\nHackathon ran: ~4 weeks (March 4 – April 1, 2026)\nWinners announced: April 7, 2026\nCurrent date: Late May 2026\nDays elapsed since announcement: 45+ days\nI understand KYC is necessary and takes time. However, nearly two months post-announcement with no prize payments or clear timeline creates a credibility issue — not just for the winners, but for the entire community.\nWhy this matters:\nContributors spent weeks building. Announcing winners without a clear payout plan signals the commitment wasn’t complete.\nIf Round 2 is announced, participation will be lower. Builders remember broken promises.\nFor a community-driven hackathon, trust is the currency. Delays erode it faster than they can be rebuilt.\nWhat would help:\nClear public timeline: “KYC open until [DATE]. Payouts by [DATE].”\nWeekly status updates in this thread or a dedicated post\nIf there are blockers (legal, partner delays, etc.), transparency about what’s stuck\nThe hackathon itself was well-organized. The execution on the back-end needs the same care.\nLooking forward to seeing this wrapped up soon. \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Playground Community Hackathon\n\n Ideas Bank\n\n 25\n\n 730\n\n Mar 11\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 567\n\n Apr 6\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14","tokens":7666,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267343320,"hash":"fe8f4a5f1cd50c6c3b7f64842fe5850bbc2fa4eb"}
{"url":"https://forum.pyth.network/t/pyth-playground-community-hackathon/2363/1","domain":"forum.pyth.network","title":"Pyth Playground Community Hackathon - Ideas Bank - Pyth DAO","text":"Pyth Playground Community Hackathon \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 24\n\n 1 / 26\n\n Feb 25\n\n Mar 11\n\n post by Chop on Feb 24\n\n Chop\n\n Overview\nThe Community Council is proposing the launch of the Pyth Playground — a hackathon for builders of all skill levels. Use Pyth price feeds, entropy, or Pyth Pro to build something. AI-assisted development (“vibe coding”) & agentic use cases are not just allowed, but are encouraged. Grants & rewards for quality, innovation and community favorites.\nProposed launche date; Wednesday, March 4. This post opens the floor for community feedback before we go live.\n\nWhat Is This?\nA 6-week event run by the Community Council:\n\nWeeks 1–4 (March 4 – April 1): Build something using Pyth data. Share progress publicly.\n\nWeeks 5–6 (April 2 – April 15): Judging panel scores submissions. Community votes via forum upvotes.\n\nApril 15: Winners announced via community call.\n\nSubmissions happen on the Pyth Developer Forum in a dedicated Pyth Playground category. Code lives on GitHub (Apache 2.0, matching Pyth’s license).\nThis has been set up to be recurring - however this will be run as a once off event that may be ongoing depending on demand and results.\n\nWhy?\nThree reasons:\n1. The builder pool just got 10x bigger. Tools like Cursor, Claude, and Replit Agent mean that traders, analysts, and creators — not just senior devs — can ship functional applications. Pyth’s data shouldn’t be locked behind arbitrary barriers that AI now dissolves.\n2. Every submission generates public content. Participants will post about their projects on Reddit, GitHub, and the developer forum. That’s organic, authentic content about Pyth integration patterns — the kind of content that ranks in search and gets cited by AI models. 30 submissions = 60+ public references across multiple platforms that reference Pyth.\n3. We need more people building with Pyth Pro. The best way to demonstrate the value of real-time institutional-grade data is to let people build with it. This event gives them the structure and incentive to do that.\n\nPrize Structure (Round 1)\n\nTier\nReward\n\n1st Place\n50,000 PYTH\n\n2nd Place\n30,000 PYTH\n\n3rd Place\n15,000 PYTH\n\n4th–10th Place\n5,000 PYTH each\n\nCommunity Choice (most upvotes)\n10,000 PYTH\n\nMost Creative Pyth Pro Use\n10,000 PYTH\n\nBest Educational Content\n10,000 PYTH\n\nSocials content bonuses stack on top: 10 upvotes (+500), 25 (+1,000), 50 (+2,500), 100 (+5,000).\nContent bonuses: Wikipedia contribution (+5,000 PYTH), second platform post (+1,000 PYTH).\nTotal budget: ~200,000 PYTH from Community Council Budget allocation.\n\nSubmission Requirements\n\nUse at least one Pyth feature (Price Feeds, Entropy)\n\nWorking demo or live deployment\n\nSource code on GitHub (Apache 2.0)\n\nForum post on Pyth Developer Forum using the official template\n\nOne public content piece (Reddit, Dev.to, or similar)\n\nOne technical contribution (Stack Overflow answer or GitHub example)\n\nTeams of up to 2. One submission per team per round. 18+ only.\n\nJudging\n\nCriteria\nWeight\n\nPyth Integration\n30%\n\nCreativity / Innovation\n25%\n\nExecution\n20%\n\nUser Experience\n15%\n\nDocumentation\n10%\n\nPanel: 2 Community Council members (Arguer, Lowkeigh confirmed), 1 Pyth engineering rep (outreach in progress), 1 external guest judge (TBD). All scores published after results.\nCoordinator: @Chop (non-voting).\n\nLegal & Compliance\nTerms & Conditions are being finalized. The Hackathon is organized by PYTH DAO LLC (Marshall Islands) through the Community Council. Key points:\n\nSkill-based judging with transparent, objective criteria\n\nOFAC-sanctioned jurisdictions excluded\n\nKYC required for prize winners only\n\nAll submissions open source (Apache 2.0)\n\nParticipants retain IP ownership\n\nDAO contributors may participate but are not eligible for prizes\n\nParticipants responsible for their own tax obligations\n\nFull T&Cs will be pinned in the Developer Forum before launch\n\nTimeline\n\nMilestone\nDate\n\nThis governance post + community feedback\nFeb 25\n\nT&Cs finalized and posted\nFeb 28\n\nDeveloper Forum category setup + rules posted\nFeb 28\n\nPre-launch promotion\nMarch 2–3\n\nRound 1 Launch (submissions open)\nMarch 4\n\nSubmission deadline\nApril 1\n\nJudging period\nApril 2–15\n\nWinners announced\nApril 15\n\nWhat’s Ready\nWe’ve spent the last month building out the infrastructure:\n\n3 starter kits (Python, TypeScript, MCP Server) — ready to fork\n\n30 project ideas across 5 categories (trading bots, dashboards, AI agents, DeFi tools, educational)\n\nPyth MCP Server deploying March 2 — lets any AI coding assistant pull live Pyth data directly using AI Agents\n\nSubmission template, judging rubric, FAQ — all drafted and ready for the Developer Forum\n\nMissionMonitor bot — live in production for tracking Discord & Telegram content submissions\n\nWhat We Want From The Community\nThis post is here to start a discussion. Before we launch:\n\nBuilders: What would make you participate? What’s missing?\n\nCommunity: Are the prize tiers right? Too top-heavy? Not enough participation rewards?\n\nAnyone: Feedback on submission requirements, judging criteria, or format?\n\nThe full rules, submission template, starter kits, and project ideas will all live on the Developer Forum from Friday (27th).\n\n 3\n\n 3\n\n 2\n\n 2\n\n post by Planck on Feb 25\n\n Planck\n\n This is an excellent idea. I am sure there are a lot of people who are very interested in participating. Godspeed\n\n post by N0name_trader on Feb 25\n\n N0name_trader\n\n Having myself recently started vibecoding, I am sure that people will love it! There are so many talented community members who can utilize Pyth products! I guess the time could not be better than now. Also prize pool looks legit\n\n post by CrownOfLagos on Feb 25\n\n CrownOfLagos\n\n Is this only for developers? Building sounds more a dev. Thingy\n\n post by CrownOfLagos on Feb 25\n\n CrownOfLagos\n\n As a non developer, where do I start and how do i participate ?\n\n post by codeglitch on Feb 25\n\n codeglitch\n\n Great initiative, been working on some stuff with Pyth lately so, love this and joining it!\n\n post by Planck on Feb 25\n\n Planck\n\n CrownOfLagos\n\n Yes, I believe this is for developers only. Or people who are just starting out and are interested in growing in this field. We have plenty initiatives for people with non-technical skills, imho this is a great time to launch a campaign for the devs Maybe the devs will be able to finally do something\n\n post by KemarTiti on Feb 25\n\n KemarTiti\n\n Amazing cook from the community council! Looking forward to see what the Pythians build and hope you all enjoy testing out Pyth Pro!\n\n post by CrownOfLagos on Feb 25\n\n CrownOfLagos\n\n Planck\n\n Thanks my lady, I thought as much I just need to be sure of it\n\n post by Defi_Godwinn on Feb 25\n\n Defi_Godwinn\n\n this really good for pyth network, i will inform my developer friends.\n\n post by Defilion on Feb 26\n\n Defilion\n\n we will be there and we will definitely participate\n\n post by theRoad on Feb 26\n\n theRoad\n\n Very nice initiative. Will try my luck too\nProject idea links??\n\n post by totti on Feb 26\n\n totti\n\n great initiative. Looking forward to all the creative stuff this amazing community gonna cook!\n\n post by Flint on Feb 26\n\n Flint\n\n What perfect timing. Just when I needed to dive into OpenClaw, and then this news comes along. I’m with you guys.\n\n post by BeeKey201 on Feb 26\n\n BeeKey201\n\n it will be legendary March sprint on Noah AI. I look forward to it.\n\n post by SkyZ on Feb 26\n\n SkyZ\n\n Amazing \nSCP i know u will lov this \nLfg legends\n\n post by lowkeigh on Feb 26\n\n lowkeigh\n\n This proposal couldn’t have come at a better time with the popularity of vibe coding atm.\nThe proposal as it stands looks good to me, excited to see what everyone comes up with!\n\n post by spank2023 on Feb 26\n\n spank2023\n\n Absolutely in favor of this initiative and as already stated, can only enhance Pyth product utilization. Huge opportunity.\n\n post by Mersault on Feb 26\n\n Mersault\n\n Great initiative fully supportive\nI think this is a wonderful idea and I’m 100% behind it.\nI’ve already been working on a project purely because I’m committed to Pyth, but this event is a massive value-add. Current prizes structure looks good. High rewards for the top spots are necessary to attract high-quality submissions. Quality should always come first. The evaluation criteria and requirements are very clear and easy to understand.\nThanks for the opportunity to develop and build alongside the community!\n\n post by Mersault on Feb 26\n\n Mersault\n\n I have just one question\nIs there a difference in scoring between using Pyth Pro and Entropy, or are they evaluated the same way?\n\n Load more posts below","tokens":2157,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267359995,"hash":"2b4506efb1ff85e37da78e99d76c31453e3a5c8d"}
{"url":"https://gov.optimism.io/t/final-law-of-chains-v0-1/","domain":"gov.optimism.io","title":"[FINAL] Law of Chains v0.1 - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [FINAL] Law of Chains v0.1 \n\n ✨ General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2023\n\n 1 / 22\n\n Jul 2023\n\n Nov 2023\n\n post by system on Jul 25, 2023\n\n system\n\nFor a section-by-section summary of the Law of Chains, see here.\n\nLaw of Chains (v0.1)\nThe Law of Chains is an open neutrality framework that establishes certain protections for participants in the Superchain ecosystem. Its purpose is to promote core principles of user protection, decentralization and economic autonomy as foundations for the developing Superchain.\n\nVersion note. The Law of Chains is a living document, and should evolve alongside protocol innovation across the Collective. Version 0.1 of the Law of Chains is immediately applicable to the current, single-sequencer release of the OP Stack, and establishes fundamental principles: core expectations of users and economic participants, homogenous blockspace, and universal upgrades on a shared standard. Anticipated improvements to the OP Stack that remain technologically unspecified (e.g., shared sequencing and zero-knowledge proofs) are correspondingly economically unspecified in this initial version. As the Law of Chains evolves, two critical freedoms should be preserved: (1) the freedom of Optimism Governance to introduce new protocol constructions with different technological and economic specifications, and (2) the freedom of ecosystem participants to choose, at the appropriate time, with full information, and without coercion, whether to opt into those constructions.\nFinally, part of the Law of Chains is this Important Disclaimer. To fully understand this document, you must read the disclaimer. It clarifies that the Law of Chains is not a legal contract, provides no legally enforceable warranties, representations, indemnities, rights, or obligations, and does not commit participants to any form of legal partnership or joint venture with any others. The Law of Chains is intended to function solely as a guiding framework for participants in the Collective and Optimism Governance.\n\nCovered Participants.\n\nThe Law of Chains applies to:\n\nUsers: The end users of OP Chain smart contracts and applications, and the developers and deployers of such smart contracts and applications.\n\nAny party that holds assets or transacts on an OP Chain or deploys a smart contract to an OP Chain is acting in their capacity as a User.\n\nChain Governors: The party or smart contract responsible for deploying an OP Chain or configuring an OP Chain following deployment.\n\nA party or smart contract “configures” an OP Chain by setting the configuration values that are parameterized by, but not specifically hardcoded into, the Protocol Contracts or offchain protocol software.\nFor example, in the future a Chain Governor might configure its OP Chain to run a particular OP Stack sequencing scheme (among various potentially compatible sequencing schemes) on the chain.\n\nChain Servicers: Sequencers, Proposers, and Challengers for an OP Chain.\n\nThe identity or scope of Covered Participants may change over time. For example:\n\nA Chain Governor may transition from being a single party to a decentralized governance system (e.g., where OP Chain configuration decisions are made by a ‘DAO’). In that case, the decentralized governance system would become the Chain Governor.\nWith future development milestones, Sequencers, Proposers, and Challengers may become separate categories of Covered Participants with expectations under the Law of Chains that are different from one another.\nNew, currently unidentified roles may emerge within the ecosystem and be included as additional categories of Covered Participants (e.g., zk-Provers).\n\nA single party may be a Covered Participant in multiple capacities. For example, a Chain Governor may also be a Chain Servicer, and a Chain Servicer may be any combination of Sequencer, Proposer, and Challenger. In such cases, the party’s expectations under the Law of Chains are determined separately, as relevant to each respective role.\nThe Law of Chains only applies to Covered Participants of OP Chains: i.e., those that have affirmatively opted-in, and followed any relevant governance process to be committed to and covered by the Law of Chains. It does not extend to chains running on the OP Stack which are not “OP Chains.”\n\nThe Platform. In addition to Covered Participants, the Law of Chains establishes expectations for the Platform itself. The Platform is not an individual OP Chain; it is the fundamental protocol on which all OP Chains run today, and in the future, which will evolve into the Superchain.\n\nUser Protections. Users are to be protected with assurances that are (a) highly similar to the assurances afforded to analogous users of Ethereum and (b) as uniform as possible for all Users across all OP Chains. This means ensuring, at minimum:\n\nState Transition and Messaging Validity: OP Chain state transitions, and cross-chain messages sent to or from OP Chains, must only be finalized if they follow the rules defined by the most recent Optimism Governance-approved release of the OP Stack. For example, the User Protection to state transition and messaging validity would be violated by:\n\nFor Chain Servicers, a:\n\nSequencer that represents an L2 block (e.g., by serving an eth_getBlockByNumber RPC request) to a User where that block does not match the result of the op-geth, op-node, and L1 Ethereum node services.\nProposer that proposes an output which does not match the result of the batch-submitter service in coordination with aforementioned software.\nChallenger that does not challenge the aforementioned proposal in a timely manner.\n\nSecurity, Uptime, and Liveness: Block production, sequencing, and bridging must satisfy uniform standards for security, uptime, and liveness across all OP Chains. For example, the User Protection to security, uptime, and liveness would be violated by:\n\nA Chain Servicer that:\n\nIllegitimately censors, reorders, or limits transactions (e.g., by running off-chain sequencing code that is not approved by Optimism Governance, or by colluding with L1 validators to artificially inflate sequencer batch submission costs) in order to extract a profit or violate User Protections.\nFrequently experiences unreasonable downtime, such that User access to the OP Chain is regularly degraded.\nDoes not promptly address emergency bug fixes or other security compromises.\n\nA Chain Governor that configures the OP Chain in such a way that Users indirectly cannot transact (e.g., by setting a prohibitively high gas markup).\n\nUniversal, Governance-Approved Upgrades: OP Chains must upgrade together under OP Stack releases that are approved by Optimism Governance. Such upgrades must be backwards compatible with prior OP Stack releases such that User Protections are not compromised. For example, the User Protection to universal, governance-approved upgrades would be violated by:\n\nA Chain Servicer that facilitates an upgrade of the OP Chain to an Ethereum bridge implementation that is not identical to the implementation shared by all other OP Chains.\nA Chain Servicer that facilitates a change to the OP Chain’s L2 smart contract execution semantics in a way that breaks previously safe assumptions (e.g., by allowing a timelock contract to unlock ahead of schedule).\n\nFor the avoidance of doubt, any unilateral attempts by a Chain Servicer or Chain Governor to migrate an OP Chain to an unapproved release of the OP Stack or to an entirely different technical stack – i.e., a “Unilateral Migration” attempt – would violate the User Protections described above:\n\nChanging the rules of the existing OP Chain to the rules of the other stack violates the User Protection to state transition validity.\nMigrating assets from the existing OP Chain bridge via a non-standard withdrawal violates the User Protection to messaging validity.\nMigrating funds directly out of the existing OP Chain bridge via an upgrade violates the User Protection to universal, governance-approved upgrades.\n\nThis does not mean that a Chain Governor or Chain Servicer should not take any action to move users to a new technical stack. It does mean that there must be a voluntary migration transaction taken on a per-User basis, similar to the historical migration between Uniswap versions on L1.\n\nChain Governor Protections. The configuration choices afforded to Chain Governors by releases of the OP Stack are to be preserved according to the following principles:\n\nEconomic Autonomy: Chain Governors may make their own free economic choices in the marketplace within existing OP Stack parameters established by the Platform, so long as those decisions are otherwise consistent with the Law of Chains. Moreover, Chain Governors should not be retroactively deprived of economic reward that resulted from decisions that were valid at the time they were made. For example, the Chain Governor Protection to economic autonomy would be violated by upgrades that:\n\nDeny the ability of a Chain Governor to choose to run a single-sequencer OP Stack sequencing scheme (even where governance has approved a release of the OP Stack which supports an alternative sequencing scheme).\nDeny the ability of a Chain Governor that runs a single-sequencer configuration to set a configurable profit margin for sequencing on its OP Chain.\nRemove network fee revenue previously accrued to an L2 fee vault by a Chain Governor, or limit the ability of the Chain Governor to legitimately collect additional revenue or access those historical or legacy assets earned and presently owned by them.\nIntroduce mechanisms designed directly to prevent Chain Governors from encouraging a voluntary per-User migration to a different chain (since the possibility of voluntary exit is critical for Users as well as Chain Governors, the ability of a Chain Governor to legitimately exit the system should be respected regardless of Chain Governor conduct).\n\nTechnical Configurability: Chain Governors may make basic technical configurations permitted to them by the OP Stack. This should include the ability for the Chain Governor to change the Sequencer on its OP Chain between those which have been approved by Optimism Governance, and to appoint a new Chain Governor to take its place in the event it elects to make such a transition.\n\nChain Servicer Protections. The participatory expectations of Chain Servicers are to be preserved according to the following principles. Like Chain Governor Protections, Chain Servicer Protections are focused on the Chain Servicer’s expectations of economic autonomy and technical configurability within, initially, the framework of an OP Stack single-sequencer sequencing scheme:\n\nEconomic Autonomy: Chain Servicers may make their own free economic choices in the marketplace within existing OP Stack parameters established by the Platform, so long as those decisions are otherwise consistent with the Law of Chains. Moreover, Chain Servicers should not be retroactively deprived of economic reward that resulted from decisions that were valid at the time they were made. For example:\n\nIf a Chain Governor makes changes to parameters, or Optimism Governance approves an upgrade, which impacts the margin that a Chain Servicer (e.g., in its capacity as Sequencer) may earn going forward, the Chain Servicer may cease operations if economically nonviable under the new margin.\nIf a Chain Servicer has previously accumulated assets to an L2 fee vault contract, it may access those assets and any upgrade removing such assets or access would be a violation.\n\nTechnical Configurability: Chain Servicers may make basic technical configurations permitted to them by the OP Stack. This includes changing the hotkey used for batch submission in a Sequencer capacity, or the hotkey used for proposing in a Proposer capacity.\n\nPlatform as Commons. The Platform is the fundamental public good on which all ecosystem participants, as a Collective, rely. It establishes the underlying economics applicable to all OP Chains, backstops the security assumptions of all OP Chains, and exists for the benefit of all OP Chains. On behalf of the entire Collective, therefore, it is essential that its basic Platform Requirements be preserved:\n\nSustainability: The Platform must be able to economically sustain itself and the public goods that support it.\nSecurity: The Platform must be able to prevent or respond to Security or Stability Incidents that would impact it.\nSurvival: The Platform must be able to evolve in response to threats that pose a real, existential risk to the Platform as whole.\n\nThe Collective should thoroughly consider any claim that a protocol upgrade or modification is necessary or appropriate to preserve a Platform Requirement:\n\nViolations of Participant Protections are to be avoided wherever practicable to do so, and minimized, reasonable, and proportionate to the need posed by the Platform Requirement wherever it is not.\n\nFor example, Platform downtime imposed in connection with protocol upgrades is acceptable (even though it marginally violates a series of Participant Protections for a limited period of time), but wherever practicable, that downtime should be limited, communicated well in advance, and Covered Participants should be provided with substantial time to prepare in a way that minimizes adverse impact.\n\nA proposed response to one Platform Requirement should always beg the question of what other Platform Requirements could be collaterally undercut in the process.\n\nFor example, a proposed upgrade may be allegedly justified in the name of the Platform Requirement of survival, while violating the Chain Governor Protection to economic autonomy. But of course, very few projects may launch an OP Chain if the Platform is not a fair, predictable commons on which to build. And less OP Chains on the Platform could undercut the Platform Requirement of sustainability. In that case, the threat to the Platform Requirement of survival should predominate the threat to the Platform Requirement of sustainability in order to justify such a change.\n\nUsers First. Subject to any Platform Requirements, User Protections must not be violated, including by the exercise or enforcement of any other Participant Protections. In the event there is a conflict between different Participant Protections, (a) User Protections will supersede all other Participant Protections and (b) conflicts among other Participant Protections will be resolved in the following order of priority: first, as required by the Platform; second, as necessary or appropriate to ensure the protection of User Protections; and third, in a manner otherwise consistent with the interpretive principles of Section 9 below.\n\nEnforcement. The Law of Chains is intended to be enforced solely through resolutions of Optimism Governance. Participant Protections are not, should not be relied on as, and do not create legally binding or enforceable rights or obligations independent of any actual, separate legal agreement between independent contracting parties (which the Law of Chains is not).\nThis means that standing alone, the Law of Chains is fundamentally social in nature: it establishes social expectations for (a) how Covered Participants should conduct themselves, (b) how Optimism Governance can step in to remedy a violation, and (c) how to evaluate future upgrades. For example:\n\nIf a Sequencer impermissibly censors users, or intentionally represents a faulty state to users, Optimism Governance can intervene by executing an upgrade to replace the Sequencer on all OP Chains it serviced.\nIf an invalid proposal is submitted and a Challenger fails to use a Challenger Key to delete the proposal, Optimism Governance can intervene by executing an upgrade to replace the Challenger.\nIf an upgrade to the OP Stack is proposed, which is insufficiently backwards compatible, Optimism Governance can validly reject the proposal on those grounds.\n\nAs Optimism Governance evolves, further accountability and enforcement mechanisms may evolve alongside it.\nFinally, for the avoidance of doubt, no Covered Participant is required under the Law of Chains to take actions that it reasonably believes are contrary to applicable law.\n\nInterpretation.\n\nIn interpreting the scope, authority, and meaning of the Law of Chains, the guiding principles contained in the Working Constitution will apply as follows:\n\nGovernance minimization. The OP Stack and OP Chains should be designed, operated, and governed in a manner that progressively and programmatically (a) removes the ability of ecosystem participants to violate the Law of Chains and therefore (b) removes the need for Optimism Governance to proactively enforce it. For example, future releases of the OP Stack should enable:\n\nChain Governors to exercise Chain Governor Protections via (and solely to the extent permitted by) configurable parameters that are encoded and enforced at the Protocol Contract level.\nAnyone to act as a Proposer permissionlessly, removing the ability of any single Proposer to censor User withdrawals.\nAnyone to act as a Challenger permissionlessly, removing the need for the Law of Chains to require affirmative conduct by any single Challenger.\nFault proof implementations that remove Chain Servicers’ ability to violate the User Protection to state transition validity.\n\nForking. The ability to fork and exit the system remains a critical mechanism to protect individual freedoms. However, the prohibition against Unilateral Migrations clarifies that exit by individual Chain Servicers or Chain Governors should not undermine the individual freedom of Users, who should have the option to migrate, rather than being forced into it.\nAnti-plutocracy. Like Optimism Governance as a whole, enforcement of the Law of Chains cannot ultimately be the domain of OP token holders alone; the influence of the Token House must be balanced with Citizenship.\nImpact = Profit. The Superchain ecosystem will, like all digital commons, be impacted by marketplace dynamics. In cases where these dynamics give rise to conflicts for Optimism Governance to resolve, the resolution should strive to preserve Platform Requirements and protect Participant Protections, while interpreting the Law of Chains in a manner that rewards all ecosystem participants commensurate with their Collective contributions.\n\nIt is further understood that the Law of Chains will require adaptation to changing circumstances as the Collective defines itself, evolves, and grows iteratively over time. Accordingly, the Law of Chains adopts additional interpretive principles:\n\nLong-term applicability. As the Law of Chains is applied to events such as the Superchain Migration, which will involve significant and unforeseen changes to protocol specifications and code, it should be interpreted and updated in a way that favors flexibility, adaptability, and consistency with the principles underlying the Law of Chains, as opposed to rigid adherence to its text. For example:\n\nOptimism Governance may approve future releases of the OP Stack that cause some of the specific references and examples included in this document to no longer apply. This should not undermine ecosystem participants’ adherence to the Law of Chains’ underlying principles, or inhibit the legitimacy of efforts by Optimism Governance to enforce it.\n\nModularity and evolution. The modular design of the OP Stack opens the door for alternate L2 constructions in the future, which may make known tradeoffs (e.g., between decentralization and performance, or between composability and economic autonomy) that establish fundamentally different User expectations. For example:\n\nA future L2 construction might move data availability off of L1 to reduce fees, but decrease fundamental censorship resistances properties.\nA future L2 construction might include a decentralized sequencing network which facilitates cross-OP Chain composability, but decreases the ability of individual OP Chains to have independently configured economic systems.\n\nThe mere fact that such a protocol is less censorship resistant or more uniform in its economic model than a current OP Chain does not mean that Optimism Governance should reject its inclusion in a release of the OP Stack for failure to uphold particular Participant Protections. Instead, Optimism Governance should consider whether, or how, to expand the Law of Chains to facilitate the Superchain’s ongoing evolution.\n\nReputational awareness. Optimism Governance must understand that the decisions it makes are never in a vacuum, and the manner in which it applies the Law of Chains will establish its reputation for existing – but also future – ecosystem participants. For example (and as noted above), undermining the settled expectations of Chain Governors will not just impact current participation, it will also pose significant long-term risk of driving away future Chain Governors, and corresponding fee revenue. “The most important scarce resource is legitimacy.”\n\nAlways. Stay Optimistic .\n\nDEFINITIONS\n“Challengers” = the Ethereum address authorized to delete output proposals for an OP Chain.\n“Collective” = the Optimism Collective, including participants in the Superchain ecosystem.\n“Covered Participants” = Users, Chain Governors, and Chain Servicers.\n“OP Chain” = a production L2 blockchain running on the OP Stack and which has affirmatively opted-in and followed any relevant governance process to be committed to and covered by the Law of Chains.\n“OP Stack” = an Optimism Governance-approved, standardized, shared, and open-source development stack release that powers the Optimism L2 blockchain protocol; together with all future such releases.\n“Optimism Governance” = the governance system for the OP Stack, OP Mainnet, and the Superchain, which is currently the bicameral system of the Token House and the Citizens’ House; and future iterations thereof.\n“Participant Protections” = User Protections, Chain Governor Protections, and Chain Servicer Protections, collectively.\n“Proposers” = the L1 Ethereum wallet or smart contract authorized to append output root hashes for an OP Chain, which form the basis for withdrawals and other L2-to-L1 messages.\n“Protocol Contracts” = the OP Stack smart contacts that comprise the onchain code that powers an OP Chain.\n“Security or Stability Incident” = bugs or defects, unplanned maintenance, or stability, integrity, availability, non-repudiation or other security issues with the OP Stack, Protocol Contracts, or any OP Chain.\n“Sequencers” = the node(s) providing block production services which produces transaction confirmations and state updates, constructs and executes L2 blocks, and submits L2 block data transactions to layer 1.\n“Superchain” = a proposed network of L2 rollups that share bridging, security, data availability, and communication layers; which uses the OP Stack as a common development stack, and Optimism Governance as the common governance system.\n\n The Future of Optimism Governance\n\n About L3s and the Superchain\n\n Ratification: Law of Chains\n\n [FINAL] Superchain Governance Deep Dive\n\n Calling out RetroPGF- let's discuss\n\n 4\n\n 2\n\n read \n\n 20\n min\n\n post by gigamesh on Jul 25, 2023\n\n gigamesh\n\n This is really great to see! Tiny note/question:\n\nGiven “platform” is typically used to refer to centralized frontends, I’m curious why that is the term being used. Maybe Superchain Protocol would be more clear?\n\n post by hyprboom on Jul 25, 2023\n\n hyprboom\n\n Not a question, more of a comment.\nI love the spirit in which this document was created - focused on users and on optimism. It is also incredibly thorough. As I was reading it, I did have a question on the difference between end users vs developers - but it was covered and defined in the document (though I kind of had to dig for it).\nIn any case, really great start and looking forward to everybody’s feedback.\n\n post by bakgwei on Jul 25, 2023\n\n bakgwei\n\n Very very thorough, and for me - as a non-techie - sometimes hard to digest in it fullest meaning. Though the glossary at at the end also helped, thanks for that.\n\n post by kemzy on Jul 26, 2023\n\n kemzy\n\n I support this.\nwell captured, and understandable even for a non-techie\n\n post by sam.ng on Jul 26, 2023\n\n sam.ng\n\n Hello,\nAs someone who spend too much time on Twitter (or should i say X lul sounds bad), often end up fully immersed in the various discussions that take place on the platform (it is what it is). Recently noticed some ambiguity and misunderstanding concerning some points raised in a Twitter post that Optimism did yesterday. From my perspective, there seemed to be a certain degree of miscommunication that needs to be addressed, and I do so with the utmost respect for all parties involved.\nA series of differing posts caught my attention, primarily asserting that any chains constructed on Optimism will have no alternative but to adhere to the sequencers chosen by the Optimism collective. Such a scenario, as depicted by these posts, hints towards a possible deficiency in modularity and sovereignty, thereby potentially complicating the process of accruing value for builders within the Optimism ecosystem.\nNevertheless, it’s essential to highlight that this interpretation appears to stem from a misunderstanding of the original Twitter post. The matter is clarified more comprehensively in this forum post, as can be inferred from the following quote:\n\nTo further decode this misinterpretation by the community regarding the announcement made on Twitter, I’d like to elaborate on a few things:\nFirst and foremost, the OP Stack codebase grants you complete autonomy to utilize it as you see fit. However, it’s widely understood that for the Superchain network to function cohesively, making it feel like “many chains that behave as one chain,” the individual chains within this network (termed as “OP Chains”) must adhere to a relatively standardized security model. This requisite stands apart from what you are capable of achieving with the OP Stack codebase.\nThe post, in essence, highlights that any significant alterations to the OP Stack codebase could potentially result in your chain being incompatible with the Superchain network-of-chains. The phrase “OP Chain” is a specific reference to the chains operating within the Superchain network, clearly distinguishable from a “chain constructed on the OP Stack.”\nIn summary, despite the liberty to modify the OP Stack codebase as per your requirements, certain alterations could compromise your chain’s compatibility with the Superchain network. This network relies on a fairly consistent security model to ensure its proper functioning. Hence, the need to make a clear distinction between OP Chains and chains built on the OP Stack is quite apparent.\nIn my perspective, it’s crucial to tread towards maintaining modularity and ensuring sovereignty for builders, taking into consideration what they aim to construct. For instance, facilitating composability between different app-chains for building financial applications makes sense, given the existing interaction between dapps on Ethereum today (e.g., Uniswap with Aave). This proves beneficial for builders in that specific space. Also, giving the flexibility to builders to manage their sequencer set might lead to new mechanism we are not used to today. Yes, like seeing a dapp token useful, it could be used for staking to propose blocks and even to pay for txs fees. Would definitely be game changer but would introduce some research to maintain interoperability in some cases. That being said, the financial domain certainly won’t be the sole utilization of crypto, at least I hope so.\nIn the context of a game, it’s more sensible to have your own sequencer, as the need for composability diminishes significantly when you are engaging in a game. The value should primarily be accruing to the sequencer(s) elected by the company. The choice of sequencer is not the only option that OP builders should (will?) have. This is where data availability comes into the picture.\nConsider this scenario: publishing data representing hundreds of millions (wen trillions ser ?) of DeFi interactions should be accomplished on a data availability layer that is economically secure and decentralized. On the contrary, social or gaming chains do not require the same level of security but demand more throughput than what the Ethereum data availability layer can currently provide. Consequently, it would make sense to investigate various data availability solutions (e.g., Celestia, which recently announced close collaboration with the OP Stack).\nBy the way I am not sure if a comprehensive dashboard exists that displays a) OP Chains, which are a part of the Superchain vision (e.g Base ?), illustrating a single logical chain for end-users, and b) chains solely based on the OP Stack (e.g Mantle ?). I am eager to interact with the community to explore potential solutions that simplify the understanding for everyone, myself included, given my humble knowledge levels.\nHope that makes sense!\n\n post by cpoetter on Jul 26, 2023\n\n cpoetter\n\n the document is a good start to understand the scope of OP Chains and the difference to OP Stack only chains. I also like that the document is intentionally a v.01, leaving much room for improvements and iterations.\n\n post by sam.ng on Jul 27, 2023\n\n sam.ng\n\n Absolutely, however, what I had in mind was a type of interface or dashboard that would display OP chains on one side, while concurrently presenting chains constructed from the OP stack on the other (if it doesnt exist yet).\nwell, found this so editing this post with it meanwhile :\nimage315×629 23 KB\n\n Optimism PBS proof of concept\n\n post by ksett on Jul 28, 2023\n\n ksett\n\n Love to see the proposal and a framework for interactions being created. It is a little unclear to me what the threshold for violation is and who determines what is “reasonable” or required deviations from the standards set forth.\n“Violations of Participant Protections are to be avoided wherever practicable to do so, and minimized, reasonable, and proportionate to the need posed by the Platform Requirement wherever it is not.”\nI believe 8. enforcement needs clarification as well. specifically from \" it establishes social expectations for (a) how Covered Participants should conduct themselves, (b) how Optimism Governance can step in to remedy a violation, and (c) how to evaluate future upgrades.\", b is not established anywhere in this proposal from what I can see.\n\n post by Sinkas on Jul 30, 2023\n\n Sinkas\n\n I think the following quote from Law of Chains v0.1: Section-by-Section Overview answers the question to an extent. If the Law of Chains is intended to be enforced solely through resolutions of Optimism Governance, then it’s probably up to the “challenger” to make their point on why they believe something is past the threshold of reasonable, as supported by the Law of Chains and the Optimism Constitution.\n\n post by nickbtts on Aug 3, 2023\n\n nickbtts\n\n Hello!\nI’m worried the implications of mandate expansion could have deleterious effects on OP Mainnet.\nAs we know, OP chains cede some tech sovereignty to the Optimism governance houses in order to ensure Superchain inclusion. This, of course, means that the teams or DAOs operating these chains will require a presence in governance, ensuring their voice is heard when impactful changes are being made to standards and/or inclusions. It is easy to view general execution environments, such as OP Mainnet, as complementary within the Superchain, assuming shared sequencing and messaging are robustly built, but the reality is somewhat different: only a relatively small percentage of sequencer fees from OP Chains is returned to governance. Op Mainnet, on the other hand, returns all of the sequencer revenue. With a finite number of users, capital and builders, generalised rollups across the board are in competition for that delta in value, despite OP Chains working under the same umbrella.\nWith this in mind, the Law Of Chains raises a few questions. Firstly, if post-vote the ‘platform’ is the Superchain, where does that leave OP Mainnet in terms of governance representation? Who exactly is representing the home of many projects and builders, as OPlabs do not participate in governance? Secondly, if the OP Stack and Superchain are the core OPLabs products, is the core Optimism team’s priority the onboarding new OP Chains, or new protocols to OP Mainnet? Other teams will be aggressively doing the latter to competing generalised rollups, and as previously mentioned, even if protocols are kept within the Superchain, it is disadvantageous to the Collective for a protocol to deploy to other environments other than OP Mainnet.\nFor a project with high transaction volume, remaining on OP Mainnet would also be deleterious; your environment has no champion, and you have no share of the revenue generated. If you have the tech headroom, operating your own OP Chain within the Superchain is the logical move, or indeed deploying to a competing environment which offers some kind of CSR or grants, and has a powerful voice within governance, one you can be part of.\nGrowth experiments and builder grants are currently one of the main ‘carrots’ to build on Optimism Mainnet. However, it does not take a leap of imagination to see a future whereby said grants become applicable across the ecosystem, especially with the aforementioned growing governance voices of competing OP Chains.\nWhat can be done about this? There’s no ideal solution, but separating OP Mainnet and the Superchain as products, with dedicated teams for each, could be a longer term goal. The Law Of Chains could provide guarantees that growth experiment and builder grants would be awarded to projects primarily deploying on OP Mainnet. A dedicated vision, and roadmap for said vision, for the future of OP Mainnet would make it a more attractive place to build long term.\nAll in all, the Law of Chains is an important and well thought out charter for the Superchain, and a way to ensure some value is captured and recycled throughout the Optimism ecosystem. However, without any clear vision, dedicated team or enshrinement of rights for Optimism Mainnet, we may well see it simply fade away as a place to build, deploy and transact (and maybe this is part of the long term strategy, but if so I believe now is the time for that to be communicated). Superchain isn’t close yet from a technical POV, so OP Mainnet needs to have a visible future in order to attract foundational platforms that generate network effect.\nAll views are my own.\n\n 15 days later\n\n post by hirokennelly on Aug 18, 2023\n\n hirokennelly\n\n gm gm! Thank you for putting forth Law of Chains v0.1 to the Collective.\n\nFYI, I’m submitting this response on behalf of DAOstewards.\n\nFor some context: DAOstewards is a BanklessDAO-affiliated meta-governance group carrying Bankless values into the greater web3 ecosystem. Bankless is a movement stewarded by BanklessDAO, whose mission is to help people learn about and use decentralized, permissionless, and censorship-resistant technology to achieve financial self-sovereignty, security, and prosperity.\nIt’s on behalf of the BanklessDAO community that DAOstewards provides this feedback. Integrity is a guiding principle of the Bankless Nation, which means we operate transparently and build trust through radically public discourse. To this end we want to advocate for greater clarity about the Law of Chains so that we can have a fruitful public discourse.\nWe’d like to present a few considerations for future drafts:\n\nOne core member of DAOstewards’ Optimism workstream is a former attorney who knows the effort and care taken in crafting this initial framework. However, while the dense legalese may be comprehensible to a trained attorney, it’s very difficult for most people to really understand what is being proposed.\n\nCore principles are shared and this is evident from introduction but the language following this is challenging for the non-technical user. While extremely thorough and clearly well considered, the text is dense and relies on the user’s prior knowledge of blockchain architecture, which reduces the impact of the principled language throughout.\n\nBankless Publishing asked a practicing crypto lawyer @lawpanda to review the Forum post and provide his comments, which you can find here. As he highlights, the Law of Chains is a social contract and not a binding legal document, and one of the challenges / opportunities will be to create non-legally-binding ‘teeth’ to enforce the social norms captured within the document. As a social contract that defines the minimum standards for Superchain participants, the boundaries of this contract must be clearly understood by ecosystem participants regardless of their level of legal and technical expertise.\n\nCombine the dense language with the very human fear of seeming ill-informed, and this hard-to-parse proposal gets very little Forum action, as evidenced by the silence in what should be an active hall, in some way analogous to what we see in the Working Constitutional Forum post.\n\nFinally, an Executive Summary at the top of this Forum post and other official communique from the Collective or the Foundation summarizing the proposal in clear, simple language would be an immeasurable benefit.\n\nMany members of BanklessDAO have been working to share the Optimistic Vision through our decentralized media nodes so it would be very helpful if documentation as important as this could be produced in plain English. This would greatly assist our team of international translators and would also be more welcoming for people new to the space no matter what their first language. And we’re certain this effort would not be helpful to the Bankless Nation alone. As we build radically new financial systems, let’s also use language to describe what we are attempting to build in ways that enable the many diverse members of the Collective to give their energy and input into these important discussions to help us all flourish.\nRespectfully,\n-DAOstewards\n\n L2BEAT - Delegate Communication Thread\n\n 10 days later\n\n post by kaereste on Aug 28, 2023\n\n kaereste\n\n The below response reflects the views of L2BEAT’s governance team, composed of @kaereste and @Sinkas, and it’s based on the combined research, fact-checking and ideation of the two.\nWe’ve put a lot of thought into the Law of Chains and there are some things we’d like to point out that might be worth addressing.\n\nParagraph 1 states that the Law of Chains applies to Users, Chain Governors and Chain Servicers. We think it might be worthwhile to distinguish two other groups that have a tremendous impact on the network and its’ dynamics - Superchain Builders and the OP Token Holders.\nBoth groups have an existential interest in the Superchain future and might have interests/pain points that are not necessarily in line with the groups already mentioned. Not taking their perspective into account, and especially merging them all within one broad ‘Users’ group might result with misunderstandings. One such misunderstanding would be in the case of a conflict between asset holders and smart contract deployers.\nAs stated in §7.a: In the event there is a conflict between different Participant Protections, User Protections will supersede all other Participant Protections.\nUsers are defined us Any party that holds assets or transacts on an OP Chain or deploys a smart contract to an OP Chain is acting in their capacity as a User.\nSo in a conflict between asset holders and smart contract deployers, who has the priority?\n\nIt might be useful to elaborate a bit on what “The Platform” is. Since the Law of Chains defines how we collectively manage the “Platform” it is crucial that everyone has a shared understanding, at least on a higher level, of what The Platform is.\n\nAn important distinction to be made is between what constitutes the common infrastructure managed and governed by the collective and what are the parameters that each Superchain member-chain governs independently on its own.\nIf this has not yet been decided and is deliberately not specified in the Law of Chains, it would be worth stating this directly and mentioning the process that will lead to its clarification.\n\nIn §6, we read: Survival: The Platform must be able to evolve in response to threats that pose a real, existential risk to the Platform as whole.\n\nWe’re curious to know how is the Platform going to address this issue?\nIn our opinion addressing this would require allocating some form resources since in order to evolve, the Platform needs a team or even multiple teams working on it and The Collective needs to be able to define the direction in which it wants the Platform to evolve (i.e. define the development road-map and ensure its execution).\nThe other requirements mentioned in the ‘Platform as Commons’ section, sustainability and security, are already being addressed by the OP chains sharing the revenue, and by the Security Council. However, we don’t really understand how survival is going to be addressed in the future.\n\nIn the current context of the Law of Chains, we are not sure about the exact meaning of Governance minimisation. While we agree with the overall approach of turning rules enforced only on the social layer into code-enforced mechanisms, we also think that it needs to be further specified.\nWhat governance mechanisms, structures or processes do we envision in the future and how do we see the role of each of the governance participants within those are just some of the questions that immediately come to mind.\n\nThere is also the question of how is the Law of Chains going to be maintained in the future?\n\nIt is stated that the Law of Chains will require adaptation to changing circumstances as the Collective defines itself, evolves, and grows iteratively over time, but there is no mention of a process for these iterations to take place.\nThe first version of Law of Chains has been drafted by the Foundation and will be ratified by the Collective, but how is it going to be worked it in the future? If we want the Optimism ecosystem to be sufficiently decentralised, then we shouldn’t just be voting on the changes but rather we should collectively be discussing the required adaptations. How will we ensure that all relevant stakeholders will participate and have a say in the discussion?\n\nLastly, the Law of Chains provides a structure for the rules of participation in the Superchain, but it does not currently define any process or rules regarding how will we onboard/offboard participants to the Superchain.\n\nRight now this seems to be handled by the Foundation, as we saw with the Base announcement, but what would that process look like in the future? In the “Future Of Optimism Governance” blog post, it is mentioned that This meta-governance power marks the end of the Foundation’s stewardship of the evolution of Collective governance and entrusts the governance community with continued experimentation towards a healthy end-state for Optimism.\nIt is our understanding that the Foundation’s role as a steward of The Collective will come to an end at some point in the future. When that happens, who will be responsible for onboarding and offboarding participants to the Superchain?\nIn our opinion The Law of Chains is a good step towards a better future of decentralized management of Superchain, but now it needs a lot of discussion about its clarification. We are definitely willing to take part in those discussions and to help brainstorm ideas around it.\nIf anybody wants to discuss the Law of Chains or any other issues regarding Optimism Governance, we would like to invite you to our Optimism Office Hours taking place every Tuesday, 3pm UTC at https://meet.google.com/pem-jzrh-gkq.\n\n post by Sator on Aug 29, 2023\n\n Sator\n\n Question: Under Superchain, who and/or what has the authority to interpret the Law of Chains in case of divergence/conflicts? Would it be the existing governing entities (token house, citizen house, the foundation) or a new impartial entity specifically designated to interpret the law similar to a “judicial branch”? And if we indeed need a new justice body, what would be its member’s election process?\n\n post by blairforce.eth on Aug 30, 2023\n\n blairforce.eth\n\n This has me so optimistic on where we’re headed. In addition to this insightful post, the recent Bankless episode regarding the Superchain really helped answer the questions I had on how it’s intended to work and the vision moving forward. Definitely recommend it to everyone out there.\n\n 12 days later\n\n post by Antoine on Sep 11, 2023\n\n Antoine\n\n Introduction\nIf the Law is not a legal contract, it’s hard to call it a Law. It’s a charta or an agreement or a declaration. On top a Law is normally binding and there is a way to enforce it. Here I think the enforcement part is hard to imagine.\nLiving document: There is a very nice approach in 14 States of the USA: The mandatory vote on a constitutional convention (Mandatory vote about whether a statewide constitutional convention shall be held - Ballotpedia). This could be a way to make sure that the doc is living even down the road as “no constitution is forever”.\nIn the following a couple of remarks different § and an advocacy for introducing sorition based tools to the Law of chains.\nOn §7: I think this is were we need an instantiation of the users. A way for them to voice their articulated concerns. For this I think there should be a sortition based “User chamber” when there is a tough choice to be made.\nOn §8: Here too, a very strong way of enforcment and judgement by peers would be a sortition based jury system. It would be a peer review, accountable, representative, non vested mechanism.\nOn 9 and the non plutocratic principle. One major reason why City states in the Italian Renaissance used sortition was to extend the scope of participants to governance and counteract plutocracry. I think here it would be particularly relevant.\nI would love to engage further and jump on a twitter space or call or whatever to pursue that discussion.\nGood job and thanks for all what you are doing.\nOn a broader note: This kind of document and exploration is the seed for future proof governance system. I think that they will grow and mature and be the basis of many many collectives in the future. I have a doubt that we can really minimize Human gouvernance. But I am convinced that we can do it with tools from the 21st Century (deliberative governance) and not rely only on tools from the 19th or 20th Century (Voting, elections, polls).\n\n 17 days later\n\n post by shaneMkt on Sep 28, 2023\n\n shaneMkt\n\n The “Law of Chains” framework covers many important governance aspects and would bring greater clarity and cohesiveness to the future plans of the Superchain ecosystem. It’s great that the Optimism community is engaged early on this! The “Definitions” section was also helpful in understanding the technical terms that will be commonly associated with the Superchain ecosystem.\nOne topic that might be brought up by the Optimism community in the future would be how the expected growth of the Superchain would align with the Optimistic Vision, and specifically, how this would impact Optimism mainnet and OP token holders, while protecting their interests. Perhaps in the next version, the Law of Chains framework can start addressing this topic in some capacity.\n\n How Base will participate in Optimism Governance\n\n 26 days later\n\n post by Base on Oct 25, 2023\n\n Base\n\n We contributed to writing the first draft of the Law of Chains, and are committed to use the Law of Chains as a guide for improved decentralization, neutrality, and contribution to public goods. These initiatives will not only strengthen Base, but the foundation on which the Superchain and the global, open, onchain economy can be built. We will continue to support and shape this framework as it is reviewed and adopted by the Optimism Collective Governance.\nThough we would like to show our support in the upcoming vote, we do not currently have the technical ability to vote (working on making it happen!) and are still listening to community feedback and refining our overall strategy around our governance involvement (give us feedback here). We will share more updates with the Community as we progress.\n\n post by ben-chain on Nov 1, 2023\n\n ben-chain\n\nIn the case of a conflict like this, we believe the general priority is preserving the semantics of the EVM execution. This conclusion is supported by the principle that it is the users’ expectations (e.g., of homogenous block space and valid state transitions) that the Law of Chain seeks to protect, not their interests (e.g., financial interests that arise independently of the expectation of User Protections, and which may contradict). These expectations apply equally to asset holders and application developers. For example, in the event where a network split, bug, or divergence causes contention between contract deployer and asset holder, we believe governance should make a decision based not on desires of those stakeholders but on the expected behavior of the EVM (e.g., the Ethereum yellowpaper) and any L2-related extensions to that specification.\n\nThe particular configuration parameters of each Chain Governor are not explicitly specified in the Law of Chains. As stated in the introduction, the Law of Chains is meant to be a long-standing document that applies over many versions of the protocol, and is as independent of future configurability options as possible.\nMore information about these specific configuration options should become clear as the Collective iterates through future releases, protocol upgrades, and governance docs. In recognition of the interpretive principles of long-term applicability, and modularity and evolution, we expect this can take the form of an auxiliary document rather than modifying the Law of Chains itself, similar to the difference between the Working Constitution and the Operating Manual.\nNotably, the protocol code will ultimately define many of the configuration options available to chain governors, which means updates to that Law of Chains’\nOperating Manual equivalent will evolve alongside protocol upgrade proposals.\nIn this context, the importance of the interpretive principle of governance minimization is also clear. Most if not all configuration choices should ultimately be structured as, and constrained by, protocol parameters that are self-enforcing, rather than reliant on procedural documentation and other offchain mechanisms. This could take time to fully and securely implement, but is a desirable end state all the same that should be iterated towards over time.\n\nYes – we believe this would require allocating resources to further the development of the Platform. So far, the Collective has supported this development by deploying grants (from the Governance Fund, Partner Fund, Seed Fund, and Unallocated buckets of the OP token treasury), among other ways. In the medium term, we expect RetroPGF to become the primary mechanism that drives and incentivizes the further development of the Platform.\nBeyond resource allocation, it’s possible that some form of protocol upgrade in the future could be proposed to governance in response to an existential threat. But it’s difficult to talk in specifics about the actions that governance may need to take to respond to existential threats, as those are not known (by definition) and hard to predict.\n\nWe’ve illustrated one possible evolution of Optimism’s governance system in a post here. The document excludes many implementation details, and it’s up to the Collective to define good processes for iterating towards and operationalizing each responsibility listed within.\n\nTo start, updates to the Law of Chains may be proposed by the Foundation, subject to governance approval. Separately, any procedural changes that impact the security model of OP Chains and/or the Superchain will also be subject to governance approval.\nOver time (as detailed here) these metagovernance powers must become the responsibility of the governance community; from initiation to approval and implementation.\nAs mentioned above, and in the spirit of governance minimization, programmatic enforcement of the Law of Chains is key. Ultimately protocol upgrades will define the specific application of many of the protections outlined in LoC. Therefore it’s possible that in the future the application of the Law of Chains is in effect interpreted by governance via the protocol upgrades it chooses to approve or reject.\n\nIf the Law of Chains is ratified by the Token House, the next step is detailing the specific processes to operationalize the first application of the LoC.\nMore specifically, this will involve a process for governance to maintain an “allowlist” of approved Sequencers that are committed to upholding the Law of Chains. Once the Sequencer is approved by governance, it will be up to that Sequencer to onboard Chain Governors that want to use their services. Note that this is an initial implementation of Superchain governance and the applications of Law of Chains, and we expect the exact governance processes that enforce the LoC to evolve over time to become increasingly permissionless.\nThe Operating Manual will be updated to include more detail on the new governance proposal types that will support these responsibilities.\n\n Apart from the dedicated Superchain community call and Season 5 Foundation AMA, if additional sessions to discuss the Law of Chains are necessary, please let us know.\n\n Ratification: Law of Chains\n\n post by ben-chain on Nov 1, 2023\n\n ben-chain\n\n ksett\n\n Each covered participant is responsible for making their own reasonable decisions, but ultimately governance is responsible for deciding whether they agree with those decisions.\nAgain in the spirit of governance minimization, we believe the Collective should seek to optimize the objectivity of protections and the ability to determine their violations so that it’s transparent and clear to any parties whether or not certain actions are in violation.\nFinally, in enforcing the Law of Chains, governance should be keenly aware of the interpretive principle of reputational awareness. Its decisions will create precedent and shape expectations for all Collective participants, now and in the future. Its legitimacy should be carefully safeguarded.\n\n Load more posts below","tokens":13677,"squid":"ink-governance","role":"Council Listener","at":1791267360186,"hash":"51c15fde5dcb9b377d1359b90d2e9051f569ce25"}
{"url":"https://io.net/about-us","domain":"io.net","title":"About us - io.net","text":"Decentralized AI compute at scaleio.net is a globally distributed GPU network offering scalable clusters at a fraction of the cost, without the wait.Get StartedBetter, Faster, CheaperIO.NET Cloud is significantly better, faster and cheaper than any other option on the marketBetterUnlimited flexibility to choose from the world's best GPUs and customizeFasterAccess the IO.NET network in a matter of secondsCheaperSave up to 70% vs hyperscalersOur JourneyConnecting thousands of GPUs across 130+ countries into a decentralized physical infrastructure (DePIN) network2022Before June 2022IO.NET was exclusively devoted to developing institutional-grade quantitative trading systems for both the United States stock market and the cryptocurrency markets.2023Compute ShortageConfronted with traditional computing limits, we explored Distributed Computing and created a unique solution. This led to decentralized clusters within a DePIN (Decentralized Physical Infrastructure Network).2023Ray.ioThis infrastructure requires MLOps and DevOps teams. Ray's discovery cut backend development time from six months to 60 days. After integrating Ray and deploying GPU clusters, high cloud GPU costs became a major obstacle.2024Pricey Compute PowerThe steep cost of GPU cards posed a major challenge. Requiring over 50 cards monthly, our expenses surpassed $100K, And for us like most other ML startups, this created a substantial financial burden.Built for the many, not the fewWe created our network with needs of builders in mind, not corporate giantsEase of useOur fast onboarding and simple UX/UI, gets you up and running in minutes not daysSecurityThe io.net network has security built into every level of the stackFast PaymentsA streamlined payment enables instant USD denominated crypto paymentsThe Future of AI Compute Is OpenWe believe AI compute should be open to everyone, not just those who can afford the big cloud providers. That's why we built io.net. Decentralized GPUs and open-source models, on demand.Get StartedGet off the waitlist and into the gameJoin thousands of developers instantly and securely deploying GPU clusters at 70% lower cost. No waitlists. No constant price rises. No vendor lock-in. Just the resources you need to build a sustainable business.Deploy GPUs","tokens":570,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267362726,"hash":"faefa96d4adfbc07a0a77284cc9a0a80e5f88e73"}
{"url":"https://docs.optimism.io/governance/evolution-and-experimentation","domain":"docs.optimism.io","title":"Optimism Documentation","text":"​Evolution\nIn our pursuit to design a new type of organization, Optimism’s public decision making process has undergone significant evolution since its inception, reflecting Optimism’s commitment to iterative improvement and experimentation.\nBelow is a summary of some of the key things we learned along the way.\n​Key Stakeholders\n\nWe’ve run multiple experiments to understand who our most engaged stakeholders are and how they participate in our public decision making process.\nTokenholders: Anyone who holds OP can vote\n\nWe’ve also run multiple delegation experiments aimed at getting if specific types of tokenholders (protocols, chains, and individual community members) more involved. Our main learning has been that tokenholders need strong incentive alignment to invest time in decision making processes and they want to be involved in low effort, high impact ways.\nWhile our system allows for delegation - whereby tokenholders can assign their votes to someone else to cast on their behalf - over time we’ve come to believe that delegation disrupts the incentives of token-weighted voting and that voting directly should be heavily encouraged.\nTokenholders are asked to make decisions that would benefit from investor protections\n\nUsers, Apps, and Chains: You must qualify to be a Citizen\n\nCitizenship started with a small initial group and expanded via a Web of Trust model. This model suffered from in-group dynamics (which were replicated here), resulting in many Citizens that were impacted by the decisions being made.\nWe later ran targeted experiments to evaluate how community members, chains, and past grant recipients voted, ultimately resulting in our key stakeholder model. Our stakeholder models ensures chains, apps, and end-users are able to influence the decisions that impact them.\nCitizens are asked to make decisions that would benefit from consumer protections\n\nWe’ve realized that input from different stakeholders is needed depending on the type of decision being made:\n\nPreferences: There is no absolute “right” answer and all stakeholders should have a say\nPrediction: There is a correct answer, which is only revealed in the future. Experts are best suited to make these decisions.\n\nWhen “experts” are needed, these decisions are made by Councils and Boards - such as the Developer Advisory Board and Security Council. These Councils and Boards are still ultimately accountable to key stakeholders.\n\nMeasurement: This is best done objectively, by a computer, when possible, or by experts.\n\n​High Impact Inputs\n\nDifferent decisions impact each stakeholder group in unique ways. Our approach has evolved from “everyone decides everything” to one that only asks stakeholders to make decisions that directly impact them.\nIn many cases, a stakeholder doesn’t need to make a decision directly, but should still have the ability to veto - or reject - a decision that disadvantages their stakeholder group.\nStakeholders will also be able to express preferences and influence strategy via non-voting processes.\nWe’ve outlined the different decisions here: Figma\n\n​The Core Set of Decisions\n\nGovernance minimization is a foundational principle of Optimism’s collective decision making process. Our evolution has been one of continuously simplifying process, reducing structure, and further refining scope.\nWe’ve learned over time that several decisions that used to be made publicly, actually benefit from more centralized decision making (CoCC, CFC, BB.)\nWe believe the set of decisions that should be made collectively are those that:\n\nReduce platform risk for customers and users of the protocol\nPrevent short-term profit seeking at the long-term expense of the platform\n\nOptimism has always been committed to supporting public goods, but the way we support public goods has evolved greatly over time. We started with a fully public grant making process, which gradually evolved to be more metrics-driven and programmatic approach, requiring less human input. We expect this to be a continued area of evolution and innovation.\nOur Decentralization Milestones outlines the remaining steps we hope to take to refine and further decentralize our public decision making process.\n\n​Experimentation\nUnderpinning the learnings outlined above is a culture of experimentation. In our early days, our iterative approach sometimes involved a less-scientific, trial-and-error approach. Over time, we’ve realized a more rigorous, data-driven approach - leveraging controlled trials where possible - allows us to truly understand what works and what doesn’t.\nA sample of our Research & Experiments findings are summarized in the table below. We often collaborate with academics, industry experts, and independent researchers.\nTopicResearch questionMethodsKey TakeawaysWrite-upAirdropsDo airdrops drive prosocial behaviors like delegation? Do they increase retention among new users?Regression discontinuity design (RDD)Increased delegation esp among small wallets; Baseline reward increases retention but high activity bonuses decrease retention- Did OP Airdrop 2 Increase Governance Engagement? - Did OP Airdrop 5 Increase User Retention Rates? A Regression Discontinuity AnalysisCitizenshipHow do we identify key stakeholders (eg, end users, app devs, or partner chains) and give them decision-making rights?Voting data analysis, surveys, qualitative interviewsExperts no “better” at values questions but better at assessing impact; Guest voters don’t vote differently to existing set; 3 clear personas- Citizenship Learnings 2024DeliberationHow does participating in a deliberative process with direct policy implications change individual attitudes and behaviors?Randomized experiment, instrumental variable regressionDeliberation increases knowledge and trust; No reduction in polarization when outcome is binding- When Is Deliberation Useful for Optimism Governance?FutarchyDo projects selected via Futarchy see greater increase in TVL than projects selected by existing Grants Council?Time-series analysis, RDD, analysis of telegram, survey, and trading dataFutarchy grants produced more Superchain TVL after 3 months than Grants Council picks; Predictions notably overpriced; 400+ forecasters participated- Futarchy v1 Preliminary FindingsPublic Goods FundingWhat voting designs lead to impactful grant allocation decisions? Does algorithmic/ metrics-based voting improve outcomes?Voting data analysis, synthetic control method, surveys, qualitative feedbackHumans are bad at quantification and bias toward even distributions rather than reflecting value; Experts with context make better decisions for OSS; Individual bias about impact vs need is inevitable- Retro Funding 4: Learnings and Reflections - Season 7 Retro Funding - Early Evidence on Developer Tooling ImpactVoter mobilizationDo appeals to civic duty, economic self-interest, collective security, or decision authority increase tokenholder turnout?Randomized multi-wave experimentEconomic and security (tangible stakes) were most effective in driving turnout; Repeated reminders are necessary to sustain increase in participation; catchy visuals and follow-ups important- “What Drives Turnout in Digital Governance? Evidence from a Multi-stage Voter Mobilization Experiment among 34,328 Tokenholders” (Draft available upon request: eliza@optimism.io)Was this page helpful?","tokens":1839,"squid":"ink-governance","role":"Council Listener","at":1791267383070,"hash":"a8e03c1ce44ee6b3ca1b5ea88441cc0083d83597"}
{"url":"https://forum.openzeppelin.com/t/where-are-crowdsales/6321/8","domain":"forum.openzeppelin.com","title":"Where are crowdsales? - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n Mar 2021\n\n 8 / 8\n\n Feb 2022\n\n Feb 2022\n\n post by asven-2020 on Mar 15, 2021\n\n post by Skyge on Mar 15, 2021\n\n post by abcoathup on Mar 15, 2021\n\n post by asven-2020 on Mar 16, 2021\n\n asven-2020\n\n Thank you. May be any new contract for presale have?\n\n post by abcoathup on Mar 16, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nThere aren’t specific presale contracts. You could have multiple crowdsale contracts for each phase.\n\n post by asven-2020 on Mar 18, 2021\n\n asven-2020\n\n Thank you Crowdsale not work with new ERC20 so problem do before pull\n\n post by abcoathup on Mar 18, 2021\n\n abcoathup\n\n Great contributor\n\n Hi @asven-2020,\nYou can have a separate project for the token and a separate project for the crowdsale. This would allow you to have a token using the latest OpenZeppelin Contracts (depending on the token).\n\n 11 months later\n\n post by BigMadCode on Feb 6, 2022\n\n BigMadCode\n\n Is there a new Crowdsale contract or did OPZ just stop maintaining it altogether. I tried using the 2x contract and could never get the transfer function to work at all.\nIf you know of any newer contract please advise.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Where are Crowdsale contracts in OpenZeppelin Contracts 3.0?\n\n SDK\n\n 13\n\n 6.4k\n\n Jun 2021\n\n How to use Crowdsale Smart Contracts\n\n Contracts\n\n erc20\n\n 1\n\n 683\n\n May 2020\n\n How to create a Crowdsale with Solidity 0.6?\n\n Contracts\n\n 2\n\n 1.7k\n\n Sep 2020\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Analogue CrowdSales\n\n Smart Contracts\n\n erc20,crowdsale\n\n 0\n\n 617\n\n Apr 2022","tokens":438,"squid":"ink-security_audits","role":"Sentinel","at":1791267385667,"hash":"941fa3059d437d516a878316003ca89b58086df6"}
{"url":"https://aave.com/docs/mcp/getting-started","domain":"aave.com","title":"Aave MCP Getting Started | Aave Protocol Documentation","text":"Getting Started#\nAave MCP is a remote server, so there is nothing to install and no key to manage. Point a client at https://mcp.aave.com and the tools appear in the next session.\nConnect a Client#\nClaude CodeClaudeChatGPTCursorVS CodeCodex CLIOther clientsclaude mcp add --transport http aave https://mcp.aave.com\nYour First Questions#\nAsk in plain language. None of these need a chain or a market named first.\nRead a wallet, or the protocol:\n\"What does wallet 0x… hold on Aave?\"\"Am I net earning or net paying on this position?\"\"Which Aave governance proposals are open for voting, and has each one met quorum?\"\nCompare venues, rates and history:\n\"Where can I earn the most on stablecoins across Aave right now? Tell me what you ruled out and why.\"\"I have 10,000 GHO idle. sGHO, or supply it to a market?\"\"Has USDC's supply rate on Ethereum been stable this year?\"\nSimulate against the position, which commits nothing:\n\"What is the health factor of 0x… and how far can BTC fall before liquidation?\"\"Review what 0x… holds on Aave v4, then simulate borrowing another 5,000 USDC and show the health factor before and after.\"\"Explain e-mode, and tell me whether it would help my position.\"\nBuild a transaction to sign:\n\"Prepare a borrow of 1,000 USDC for 0x… on Aave v4.\"\"Repay all of my USDC debt.\"\"Swap 1 ETH for USDC and show me what it actually costs.\"\nReads answer with live protocol data. Actions come back as an unsigned transaction for the user to sign in their own wallet.\nPrompts and Guides#\nClients that surface MCP prompts get five ready-made workflows: check_health, best_stablecoin_yield, prepare_supply, gho_savings, and review_position. Their arguments support completion, so a client can offer values as the user types.\nThe server also carries its own guidance for the model calling it. get_started answers a cold turn where the user has not asked for anything specific, and get_aave_guide serves one topic at a time:\nTopicCoversoverviewWhat Aave is and the shape of a typical flowv3, v4What each version needs in order to actpositions, health-factorThe rules that decide whether an action is possiblerisksWhat a passive supplier is exposed toids, amounts, signingArgument formats and the execution-plan branchespricesWhose price every USD figure is, and what follows from thatswaps, gho, governance, rewardsThe flows that have their own toolstools, docsThe capability list, and where the protocol documentation lives\nEach topic is also readable as an MCP resource at aave://guide/<topic>.\nCall the Server Directly#\nThe MCP endpoint is POST /, with /mcp as an alias. A plain GET there returns the server card as JSON, the same document served at /.well-known/mcp/server-card.json. A GET that asks for text/event-stream gets 405, since the server offers no SSE stream. GET /health returns a JSON status.\ncurl -s -X POST https://mcp.aave.com/ -H 'content-type: application/json' \\ -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\"params\":{\"name\":\"get_user_summary\",\"arguments\":{\"user\":\"0x...\",\"version\":\"v4\"}}}'\ntools/list on the same endpoint returns every tool with its parameter schema, which is the authority on arguments at any moment.\nProtocol Revisions#\nThe server serves both the 2025-era and 2026-era revisions of the Model Context Protocol, and the 2025 list is what an initialize handshake negotiates. Most clients handle this themselves. A client written against the 2026 revision must send the Mcp-Method header, and Mcp-Name on a tools/call, or the request is refused.\nLimits#\nThe endpoint needs no key today. It is a shared service, so cache reads where a client can, poll get_transaction_processed and get_order_status at a sensible interval rather than in a tight loop, and handle 401 and 429 responses rather than assuming they cannot occur.\nWhere to Go Next#\nToolsEvery tool, and how to build an action.SafetyWhat the server will and will not do.PreviousOverviewNextTools","tokens":976,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267401992,"hash":"c69caa77b8f61004a30ebfd3ddc77f559c53838d"}
{"url":"https://aave.com/docs/resources/changelog","domain":"aave.com","title":"Changelog | Aave Protocol Documentation","text":"Changelog#\n16 September 2026Aave V4 Arc Market#Aave V4 launches on Arc, Circle's USDC-native Layer 1. The market deploys a Core Hub with Main and Forex Spokes, listing USDC, EURC, cirBTC, and WETH.\n15 July 2026Aave V4 Avalanche Market#Aave V4 launches on Avalanche, marking the first multi-chain deployment of Aave V4. The Avalanche market introduces a Core Hub with Main, Forex, and AVAX Correlated Spokes.\n2 July 2026Aave v3 Monad Market#Aave v3 market deploys on Monad.\n25 June 2026Paxos Global Dollar Hub & Spoke#Aave V4 launches a hub and spoke for Paxos Global Dollar (USDG) on Ethereum mainnet, extending the hub-and-spoke liquidity architecture to include the regulated stablecoin.\n29 May 2026Aave v3.7 — Part 2#Aave v3.7 completes its rollout with deployments to Ethereum (Core, Lido), Polygon, Avalanche, Arbitrum, Base, BNB Chain, Linea, Plasma, and Mantle. Learn more.\n20 April 2026Aave v3.7 — Part 1#Introduces protocol-level improvements and safety enhancements. Initial deployment on Sonic, Optimism, Gnosis, Scroll, Celo, MegaETH, XLayer, and Ethereum EtherFi markets. Learn more.\n30 March 2026Aave V4 Ethereum Mainnet#Aave V4 launches on Ethereum mainnet with a hub-and-spoke liquidity architecture. Three hubs (Core, Plus, Prime) and eleven spokes are deployed, enabling isolated liquidity routing across collateral categories.\n29 March 2026Aave v3 XLayer Market#Aave v3 market deploys on XLayer.\n11 February 2026Aave v3 Mantle Market#Aave v3 market deploys on Mantle.\n9 February 2026Aave v3 MegaETH Market#Aave v3 market deploys on MegaETH.\n9 January 2026Aave v3.6#Introduces Liquid eMode exclusive collateral and borrowing configurations, renounce allowance functionality, and gas optimizations through OpenZeppelin alignment. Initial deployment on Sonic, Optimism, Gnosis, Scroll, ZKSync, Celo, Metis, Soneium, and Ethereum EtherFi markets. Learn more.\n15 October 2025Aave v3 Ink Market#Aave v3 whitelabel market deploys on Ink.\n25 September 2025Aave v3 Plasma Market#Aave v3 market deploys on Plasma.\n27 August 2025Aave Horizon RWA Market#Aave Labs launches Aave Horizon, a new lending market on Ethereum where institutions or other qualified users borrow stablecoins against real-world assets (RWAs). Learn more.\n7 August 2025Aave v3.5#Enhances protocol precision and safety with improved rounding methods, internal scaled accounting, and enhanced flag logic. Learn more.\n6 August 2025API / SDK Launch#Introducing the Aave v3 developer toolkit. A new React SDK, TypeScript SDK, and GraphQL API let you query and interact with Aave markets in just a few lines of code. Learn more\n3 July 2025Aave v3.4#Introducing standardized GHO aToken and variableDebtToken implmenetations, multicall support, and deprecation of discounted GHO borrow rate for stkAAVE. Learn more.\n5 June 2025Umbrella Safety Module Upgrade#Introduces an automated onchain risk management system utilizing aToken and underlying token staking to cover bad debt. Learn More.\n3 June 2025Aave v3 Soneium Market#Aave v3 market deploys on Soneium.\n17 March 2025Aave v3 Celo Market#Aave v3 market deploys on Celo.\n3 March 2025Aave v3 Sonic Market#Aave v3 market deploys on Sonic.\n24 February 2025Aave v3.3#Introduces logging and burn functionality to manage undercollateralized borrow positions and refines the liquidation logic. Learn more.\n11 February 2025Aave v3 Linea Market#Aave v3 market deploys on Linea zkEVM.\n8 October 2024Aave v3.2#Introduces \"Liquid eModes,\" allowing assets to be listed in multiple eModes, alongside the removal of legacy stable rate logic. Learn more\n20 September 2024Aave v3 ZKsync Era Market#Aave v3 market deploys on ZKsync Era.\n9 September 2024Aave v3 EtherFi Market#Aave v3 market deploys on Ethereum, optimized for EtherFi collateral assets.\n29 July 2024Aave v3 Ethereum Lido Market (Prime Market)#Aave v3 market deploys on Ethereum optimized for blue-chip collaterals and high-leverage, correlated assets.\n27 July 2024Aave v3.1#Introduces security and operational improvements to protocol smart contracts. Learn more.\n2 July 2024GHO Cross-Chain#Introduces a GHO facilitator that enables cross-chain bridging to Arbitrum powered by Chainlink CCIP.\n9 February 2024Aave v3 Scroll Market#Aave v3 market deploys on Scroll zkEVM Layer 2.\n29 January 2024GHO Stability Module#Introduces a GHO facilitator that supports the conversion of GHO with governance-approved assets at pre-determined ratios to maintain peg stability.\n23 January 2024Aave v3 BNB Chain Market#Aave v3 market deploys on BNB Chain.\n25 December 2023Aave Governance v3#Enhances Aave protocol governance, enabling voting on low-cost networks and improving efficiency of cross-chain proposals.\n6 November 2023Aave v3 Gnosis Market#Aave v3 market deploys on Gnosis Chain.\n16 August 2023Aave v3 Base Market#Aave v3 deploys on Base, Coinbase’s Layer 2 network built on the OP Stack.\n16 July 2023GHO Stablecoin#Launches GHO, Aave’s native decentralized stablecoin.\n6 May 2023Aave v3.0.2#Updates the Aave v3 codebase, addressing security and usability improvements. Learn more.\n17 March 2023Aave v3 Metis Market#Aave v3 deploys on the Metis Layer 2 network.\n27 January 2023Aave v3 Ethereum Core Market#Aave v3 deploys on Ethereum, bringing the latest protocol innovations to mainnet. The Core market serves as the most liquid and risk-adjusted environment for a diverse range of assets.\n16 March 2022Aave v3#A new iteration of the Aave Protocol, introducing new features such as efficiency mode and enhanced risk measures with isolation mode, supply caps, and borrow caps.\n4 October 2021Aave v2 Avalanche Market#Aave v2 deploys on the Avalanche C-Chain network.\n14 April 2021Aave v2 Polygon Market#Aave v2 deploys on Polygon (formerly Matic), the first protocol deployment outside of Ethereum mainnet.\n16 December 2020Aave Governance v2#Enhances on-chain protocol governance, enabling the Aave community to propose, vote, and trustlessly execute protocol changes.\n3 December 2020Aave v2#Aave v2 greatly enhances protocol efficiency with reduced gas costs and new features such as collateral switch and batch flash loans.\n29 October 2020Aave Governance v1#Introduces the first version of Aave’s governance mechanism, enabling the community to propose and vote on protocol updates.\n8 January 2020Aave v1#The first iteration of the Aave Protocol launches on Ethereum mainnet, introducing decentralized liquidity pools, allowing users to supply and borrow various assets via smart contracts.PreviousCode LicensingNextRisks","tokens":1623,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267413272,"hash":"0e163593cfe73acef66ab4a71aee711465c3f816"}
{"url":"https://blog.base.org/introducing-base-batches-004","domain":"blog.base.org","title":"Introducing Base Batches 004","text":"Base Batches is the official Base accelerator, run in partnership with the Base Ecosystem Fund, and designed to help the best teams building on Base launch, raise, and grow.For this cohort, we’re looking for early stage teams. Each selected team will be offered a $100K investment from the Base Ecosystem Fund, subject to the fund's diligence review. Over 8 focused weeks, selected teams will get hands-on support to sharpen their product and tighten their story, setting teams up to successfully fundraise. The program culminates in Demo Day in New York this November, where selected founders will present to a curated room of investors.You should apply if you are:Early: Anywhere from pre-product with strong founder-market fit to post-MVP.Pre-seed: You may have received investments from angels or early investors, but you should not have raised a formal seed round.Base-first: You can support multiple chains, but Base should be your default network of choice.Focused: You are committed to building products that advance the onchain economy (trading, payments, agents, and financing).Selected teams will receive:Capital: $100K investment offer from the Base Ecosystem Fund to help accelerate your project's growth and development.Expert support: 8-week virtual program with a dedicated advisor, weekly support, and access to subject matter experts across disciplines.Amplification: Content capture to help selected teams build visibility across the Base ecosystem.Investor Showcase: Present to a curated room of VCs at Demo Day in New York in November 2026.We review all applications as they’re submitted, so there’s a real advantage to sending yours before the final week. Don’t wait!Base is where the next generation of financial products get built. Base Batches funds and supports the founders building towards that future. We can’t wait to see what you’re working on.Apply now at batches.base.orgSubscribe to Base>440K subscribersSubscribear://kLJ1N2svGXvZWaJPQ0HX6tOqytvApIrhpZWzKgiCQagShare Introducing Base Batches 004TwitterBlueskyMore from BaseBaseJul 16Base’s Next Chapter: Everything We Announced At A New Day OneBaseSep 23Y Combinator’s Request for Onchain StartupsBaseSep 15The State of Base at BaseCamp 2025Today at BaseCamp 2025 in Stowe, Vermont, we shared an update: Base is beginning to explore a network token. As we begin this exploration, we’re sharing this shift in philosophy early as part of our commitment to building in the open, but we have no definitive plans to share at this time. We also announced a Base-built open-source bridge between Base and Solana that will allow interoperability between the two chains. Plus, new features that will make it easier to build, grow, and earn.View more","tokens":681,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267413337,"hash":"c882fc07bc587d2c51677ccf36f6c4350b06a76d"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract-with-token-already-deployed/15526","domain":"forum.openzeppelin.com","title":"Crowdsale contract with token already deployed - Support - OpenZeppelin Forum","text":"Crowdsale contract with token already deployed \n\n Support\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Sep 2021\n\n 1 / 6\n\n Sep 2021\n\n Feb 2022\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Hi there. I want to create a crowdsale contract to sell an erc20 token that I have already deployed and that has no sales functions. Can anyone help me understand what is the process to do this?\nIs there an example of how to do this?\nThank you.\n\n 3\n\n post by FreezyExIsNotABitch on Sep 14, 2021\n\n FreezyExIsNotABitch\n\n What exactly do you want to do?\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Hi! I want users to enter my website and be able to buy my Bep20 token with BNB using their Metamask wallet. I would like to be able to modify the beginning and end of the ICO. In such a way that those values ​​could modify them.\nThe token is already on the blockchain. Now I need to create a crowdsale contract that makes the sale. But I don't know how to relate the contract of my already deployed token with the crowdsale contract.\nThanks!\n\n post by Skyge on Sep 14, 2021\n\n Skyge\n\n Maybe you can have a look at this tutorial:\n\nSimple ERC20 Crowdsale\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Thanks. Yes I saw it. The problem is that having the BEP20 token already deployed I can't put the \"SimpleToken.sol\" contract and I don't know how to write the \"2_deploy.js\" so that it relates to my Bep20 token\n\n 5 months later\n\n post by BigMadCode on Feb 16, 2022\n\n BigMadCode\n\n Hi David,\nwere you able to resolve this?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Deploy a crowdsale contract for a previously deployed ERC20 token\n\n Smart Contracts\n\n erc20\n\n 2\n\n 535\n\n May 2022\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Simple ERC20 Crowdsale\n\n Guides and Tutorials\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025","tokens":530,"squid":"ink-security_audits","role":"Sentinel","at":1791267413535,"hash":"e77a0df8e642ec43eee7249c7543652baf0927ae"}
{"url":"https://aave.com/docs/resources/glossary","domain":"aave.com","title":"Glossary | Aave Protocol Documentation","text":"Aave Docs Glossary#\nTermDescriptionaTokensInterest-bearing tokens received by users when they supply assets to Aave v3 markets. aTokens represent the user’s share of the liquidity pool and accrue interest in real-time.APYAnnual Percentage Yield, which is the yield/interest after a year, including compounding interest. This differs from APR, which does not account for compounding effects.Borrow CapA limit set by Aave Governance on the maximum amount of an asset that can be borrowed from the protocol. This helps manage exposure and risk associated with each asset.CollateralAn asset supplied to Aave to secure a borrowing position. The collateral must exceed the value of the borrowed amount to ensure the protocol's solvency.Cooldown PeriodA mandatory waiting period that stakers must observe before they can unstake their tokens from the Safety Module.Credit DelegationA feature where users can delegate their borrowing power to another user who can then take out loans using the collateral of the delegator. This is facilitated through the Aave Protocol's smart contracts.Debt CeilingThe maximum amount of debt that can be issued against an isolated asset. Used to limit the risk exposure to a single collateral type.E-ModeEfficiency Mode allows borrowers to extract higher borrowing power when using correlated assets (e.g., stablecoins).Flash LoanA type of uncollateralized loan offered by Aave, which must be borrowed and repaid within one transaction block.GHOA decentralized, overcollateralized stablecoin that is fully backed, transparent, and native to the Aave Protocol. It is governed and managed by the Aave DAO.Governance PowerRefers to the ability to create proposals or vote in Aave’s governance system, based on AAVE, stkAAVE, or aAAVE token holdings.Health FactorA ratio that determines the health of a user's loan position. It compares the value of the user's collateral to their borrowed assets. A health factor below 1 triggers liquidation.Isolation ModeA feature in Aave v3 that limits borrowers to borrowing only certain stablecoins when using assets marked as isolated. It helps mitigate risk by restricting the total debt exposure to a single asset.LiquidationThe process that occurs when a borrower’s health factor drops below 1, resulting in the sale of collateral to repay part of the debt and bring the position back to a safer level.Liquidation BonusThe bonus provided to liquidators as an incentive to purchase undercollateralized assets in a liquidation event. It is expressed in percentage points.Liquidation ThresholdThe point at which a loan becomes eligible for liquidation due to insufficient collateral relative to borrowed funds. The threshold is defined per asset and determines the collateral value required to maintain a position.Liquidity IndexTracks the cumulative interest earned by a reserve over time, used to calculate accurate interest payments.Loan To Value (LTV)The maximum percentage of a collateral asset's value that can be borrowed. For example, an LTV of 75% means that for every 1 ETH of collateral, 0.75 ETH can be borrowed.Network RiskRisks associated with the blockchain networks on which Aave operates, such as congestion, security vulnerabilities, or network failures.OracleA service used by Aave to fetch external data, such as the prices of assets, which is critical for determining the value of collateral and debt.Ray unitsA unit of measurement with 27 decimals, used by Aave for internal calculations to ensure precision, particularly for rates and exchange values.Reserve FactorA percentage of interest accrued by borrowers that is allocated to the Aave Treasury to help safeguard the protocol.Risk AdminAn entity or automated system responsible for adjusting risk parameters in Aave without going through a governance vote. This allows Aave to respond quickly to unforeseen risks.Safety ModuleA staking mechanism where AAVE tokens are staked to act as insurance in case of a shortfall event. Stakers earn rewards but are also exposed to slashing risk.Siloed BorrowingA feature in Aave v3 that restricts certain assets to being borrowed alone, mitigating the risk of price manipulation or illiquid assets affecting the protocol's solvency.Supply CapA limit set on the total amount of a particular asset that can be supplied to the Aave protocol.Utilization RateA metric that determines the proportion of borrowed assets to the total available assets in a reserve. A higher utilization rate indicates higher borrowing demand.Voting PowerThe amount of influence a user has in governance decisions, determined by the amount of AAVE, stkAAVE, or aAAVE they hold.PreviousWeb3NextLegacy Versions","tokens":1165,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267428351,"hash":"b4b32e8282c1426cb48fa46674241b9578d7c15d"}
{"url":"https://blog.base.org/request-for-builders-tokenized-stocks","domain":"blog.base.org","title":"Request for Builders: Tokenized Stocks","text":"Tokenized stocks are now live on Base - issued by Coinbase and available to eligible non-US users. Programmable equities change what finance can do. For the first time, equities are programmable, composable, and available onchain.But it’s still early. Once equities work as native onchain assets, the design space opens up fast, and most of it is still unbuilt. The next wave of crypto-native and fintech builders will shape better financial primitives and unlock entirely new use cases. We’re excited to back the teams building it.NeobrokeragesTokenized stocks make it possible to build new brokerage experiences for users who have historically had little or no access to US markets. In many emerging markets, access has been limited by high fees, weak infrastructure, and products that were never designed for local users. We think the opportunity here goes beyond simply putting stocks onchain.Builders could combine tokenized stocks with fiat onramps and local stablecoins, so a user moves between them without ever thinking about the plumbing underneath. Ownership should feel simple and frictionless.Personalized Index CreationTokenized stocks unlock a new kind of portfolio construction by combining two things that have not really existed together before. First, single-name, composable stocks with deep underlying liquidity. Second, intelligent interfaces powered by AI.That combination makes it possible to understand and manage highly specific preferences at the individual level. Users should be able to express exactly what they want exposure to and what they do not, and have that translated into a portfolio that is fast, programmatic, and cost-efficient. That was difficult to do with traditional offchain index managers, which usually need scale to make the economics work. As a result, they tend to optimize for broad products, not personal ones. Tokenized stocks open the door to more personalized portfolio construction.Gifting and RewardsWe already move value between people all the time through gifts, rewards, referrals, and incentives. Tokenized stocks open new use cases for those transfers because the value being shared can be programmable rather than static.Personal: new ways to structure gifts of investments to friends and family, including time-locked structures. Corporate: a new tool for loyalty and retention, where businesses can distribute ownership directly to customers instead of relying on cash or points. This can power rewards, referrals, cashback, and other programs that strengthen the customer relationship over time.Yield Stripping and Credit on Productive AssetsSome tokenized stocks may have yield-generating mechanics associated with them. That makes them productive assets, and productive assets create a much larger design space.When an asset produces income, builders can create new ways to separate the principal from the yield, or trade them independently. That opens up products for users who want income, price exposure, or upfront liquidity.That also changes what credit can look like. Once assets are productive, lending can become more dynamic too. We’re interested in lending models that take future yield into account, including self-repaying structures and other borrow products built around assets that keep generating value over time. There is design space for more composable products on top of this, in combination with derivatives, perps, options, and other structures that blend price exposure with yield generation to create new payoffs and lending primitives.Memes and AgentsTokenized stocks can bring crypto-native mechanics to equities, opening up a new class of market participants and products. A good example is memestocks: tokens that trade on attention the way a memecoin does, linked to an underlying equity. Once equities are programmable, they can be combined with memes, agents, and prediction markets to create entirely new kinds of products.Memestocks can do more than mirror traditional stocks. They can create direct linkages between memes and stocks, such as liquidity pairs that tie a meme token and an equity token together, or trading mechanisms that route fees into purchases of the underlying stock. They can also help bottom-up communities bootstrap interest in small- and mid-cap names, giving retail a way to coordinate around companies and build support organically.Once crypto, stocks, meme tokens, prediction markets, and agent-managed portfolios all live onchain, builders can create novel hybrids across asset classes: conditional markets on tokenized stocks, or futarchy-style decision markets for real corporations. Agents with wallets can allocate into tokenized stocks on their own, turning the token into exposure to a live portfolio as it accrues value. In that world, retail participation gets new mechanisms to coordinate, signal preference, and interact with markets.Get in touch!If you’re building in any of these areas, or exploring something close to them, we’d love to hear from you. Base Batches 004 is now open for applications - apply here!Disclaimer:This post is for informational and educational purposes only. It describes categories of applications that developers could build on Base and is not an offer, solicitation, or recommendation to buy, sell, or hold any digital asset, security, or investment product. Base does not issue tokenized stocks; tokenized stocks referenced in this post are issued by Coinbase and are only available to eligible users in permitted jurisdictions outside the United States. This post does not describe any product Base offers to consumers.           Base is open-source, permissionless blockchain infrastructure. Each application, product, and token built on Base is deployed and operated independently by its own developers, who are solely responsible for their design, functionality, and compliance with applicable laws. Nothing in this post is a warranty, endorsement, or guarantee of any specific outcome, return, or performance.                                                                                                                                         Base Batches is an accelerator program - all entries are subject to the Base Batches terms and conditions. Selection for or participation in Base Batches does not constitute an endorsement of any project's business model, tokens, or legal compliance. Applicants and participants are responsible for their own regulatory posture, including any obligations under securities, commodities, banking, tax, sanctions, or consumer-protection laws in the jurisdictions where they operate.                                                                                                                    Nothing herein constitutes legal, financial, tax, or investment advice. Consult your own advisors before building, deploying, or participating in any of the categories described above.Subscribe to Base>440K subscribersSubscribear://q8Bdn0HTvVV-Mj6Sk2YfdRtuu7r-HYreQrN_ej9U6fAShare Request for Builders: Tokenized StocksTwitterBlueskyMore from BaseBaseJul 16Base’s Next Chapter: Everything We Announced At A New Day OneBaseSep 23Y Combinator’s Request for Onchain StartupsBaseSep 15The State of Base at BaseCamp 2025Today at BaseCamp 2025 in Stowe, Vermont, we shared an update: Base is beginning to explore a network token. As we begin this exploration, we’re sharing this shift in philosophy early as part of our commitment to building in the open, but we have no definitive plans to share at this time. We also announced a Base-built open-source bridge between Base and Solana that will allow interoperability between the two chains. Plus, new features that will make it easier to build, grow, and earn.View more","tokens":1934,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267430455,"hash":"1169307dff67354977d51450240f17f900e6ec01"}
{"url":"https://chain.base.org/snapshots","domain":"chain.base.org","title":"Snapshots · Base Chain","text":"Sync Your Base NodeConfigure your snapshot below and run the command to sync your node.$ base-reth-node download --chain base --archive --resumableConfigurationSelect NetworkChoose the Base network for your node.Mainnetblock 52,227,727·Oct 5, 2026Sepoliablock 47,738,256·Oct 5, 2026Configure SnapshotSelect a preset or customize which data is included in your snapshot.Archive + Proofs5 TBEverything in Archive, plus execution proofs.State (mdbx)HeadersTransactionsSendersReceiptsState HistoryIndicesProofsArchive4.2 TBFull historical data for indexers and RPC providers.State (mdbx)HeadersTransactionsSendersReceiptsState HistoryIndicesFull911.3 GBAdds transactions, receipts, and state history. Suitable for dApp backends and general RPC.State (mdbx)HeadersTransactionsReceiptsState HistoryMinimal779.5 GBState and headers only. Smallest download for validators and light usage.State (mdbx)Headers","tokens":225,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267440475,"hash":"024e67eae481db8bbccbd62464007465327b3daa"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract-with-token-already-deployed/15526/5","domain":"forum.openzeppelin.com","title":"Crowdsale contract with token already deployed - Support - OpenZeppelin Forum","text":"Support\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Sep 2021\n\n 6 / 6\n\n Feb 2022\n\n Feb 2022\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Hi there. I want to create a crowdsale contract to sell an erc20 token that I have already deployed and that has no sales functions. Can anyone help me understand what is the process to do this?\nIs there an example of how to do this?\nThank you.\n\n 3\n\n post by FreezyExIsNotABitch on Sep 14, 2021\n\n FreezyExIsNotABitch\n\n What exactly do you want to do?\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Hi! I want users to enter my website and be able to buy my Bep20 token with BNB using their Metamask wallet. I would like to be able to modify the beginning and end of the ICO. In such a way that those values ​​could modify them.\nThe token is already on the blockchain. Now I need to create a crowdsale contract that makes the sale. But I don't know how to relate the contract of my already deployed token with the crowdsale contract.\nThanks!\n\n post by Skyge on Sep 14, 2021\n\n Skyge\n\n Maybe you can have a look at this tutorial:\n\nSimple ERC20 Crowdsale\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Thanks. Yes I saw it. The problem is that having the BEP20 token already deployed I can't put the \"SimpleToken.sol\" contract and I don't know how to write the \"2_deploy.js\" so that it relates to my Bep20 token\n\n 5 months later\n\n post by BigMadCode on Feb 16, 2022\n\n BigMadCode\n\n Hi David,\nwere you able to resolve this?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Deploy a crowdsale contract for a previously deployed ERC20 token\n\n Smart Contracts\n\n erc20\n\n 2\n\n 535\n\n May 2022\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Simple ERC20 Crowdsale\n\n Guides and Tutorials\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025","tokens":518,"squid":"ink-security_audits","role":"Sentinel","at":1791267440861,"hash":"3b7aa49902c3442c97d0435f38f56ac3f9d6a07b"}
{"url":"https://aave.com/docs/resources/legacy-versions/v2","domain":"aave.com","title":"Aave V2 | Aave Protocol Documentation","text":"Aave v2#\nResources#\nContract AddressesSource CodeSubgraphsJavaScript SDKInterfaceWhitepaper\nArchitecture#\nPool#\nThe main entry point into the Aave Protocol. Most interactions with Aave will happen via the Pool, including:\ndeposit()borrow()repay()setUserUseReserveAsCollateral()withdraw()flashloan()liquidationCall()\nPoolAddressesProvider#\nThe main addresses register of the protocol, for particular markets. The latest contract addresses should be retrieved from this contract by making the appropriate calls.\nPoolAddressesProviderRegistry#\nContains a list of active PoolAddressesProvider addresses, for different markets.\naTokens#\nThe yield-generating, tokenized representation of supplies used throughout the Aave protocol. They implement most of the standard EIP-20/ERC20 token methods with slight modifications, as well as Aave-specific methods including:\nscaledBalanceOf()getScaledUserBalanceAndSupply()scaledTotalSupply()\nAll aTokens also implement EIP-2612, which via the permit() function enables single transaction approve + actions.\nVariable Debt Tokens#\nThe tokenized borrow positions used throughout the Aave protocol. Most of the standard EIP-20/ERC20 methods are disabled since debt tokens are non-transferrable.\nSupporting Contracts#\nThe following contracts should generally not be interacted with directly, but are used throughout the Aave Protocol via contract calls.\nPoolCollateralManager#\nUsing delegatecall via the Pool contract, the PoolCollateralManager implements actions involving the management of collateral in the protocol, including:\nliquidationCall()\nThis function should only be called via the main Pool contract.\nPool Configurator#\nProvides configuration functions for the Pool contracts. It has a number of important functions, such as:\nActivates / Deactivates reservesEnables / Disables borrowing for a reserveEnables / Disables using a reserve as collateralEnables / Disables stable rate borrowing for a reserveFreezes / Unfreezes reservesUpdates a reserve's Loan to ValueUpdates a reserve's liquidation thresholdUpdates a reserve's liquidation bonusUpdates a reserve's decimalsUpdates a reserve's interest rate strategy addressActivates / Deactivates all functions of a Pool in emergencies\nFor all of the above functions, relevant events are emitted to the blockchain. Anyone can monitor these changes to know when values have been modified or added/removed.\nInterest Rate Strategy#\nHolds the information needed to calculate and update the interest rates of specific reserves. Each contract stores the optimized base curves using the corresponding parameters of each currency. The parameters for the optimized base curves are:\nbaseVariableBorrowRatevariableRateSlope1variableRateSlope2stableRateSlope1stableRateSlope2\nThe interest rates are calculated depending on the available liquidity and the total borrowed amount.PreviousV1","tokens":716,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267449836,"hash":"5e358af79f0d441517ea506c828decf4d5c419f3"}
{"url":"https://www.base.org/privacy-policy","domain":"base.org","title":"Privacy Policy - Base Documentation","text":"Last updated: July 1, 2025\n\nAt Base (referred to here as “we”, “us” or “our”), we respect and protect the privacy of those users and developers (“you” and “your” or “Users” and “Developers”, as relevant) who explore and use Base (“Base”) through the Base protocol or any other applications, tools ,and features we operate or through Base programmes (collectively, the “Services”).\nThis Privacy Policy describes how we collect, use, and disclose personal information when you use our Services, which include the services offered on our website https://base.org (“Site”). This Privacy Policy does not apply to any processing which Base carries out as a processor on behalf of those Users and Developers who explore and use Base. Please note that we do not control websites, applications, or services operated by third parties, and we are not responsible for their actions. We encourage you to review the privacy policies of the other websites, decentralised applications, and services you use to access or interact with our Services.\n​1. What Information We Collect \nWe collect and process the following personal information when providing the Services:\nInformation you provide to us\nWe collect information that you provide to us directly when using the Services.\nInformation CategoryDescriptionWallet Address• Your public wallet address • Your BasenameBasic User Information• Your name• Your email address• Your social media handle(s) (including your Discord username/ID)• Your business name (where relevant)Application InformationWhen you apply for one of our Base programmes, we ask you to provide certain information. Depending on the programme you are applying for, this information may include your:• Date of birth• Nationality• Country of residence• Tax ID number• Professional/crypto experience• Job title• Language proficiency• Location/TimezoneProject InformationYour project information, including:• The name and photo associated with your Google account• Your email address• Team/project/company name• Project category (e.g. NFT, DeFi, gaming or social)• Project description• Creator name• Link to website/dapp• Wallet address• Social media handles• Content representing creators/artistsFeedback InformationAny feedback or suggestions you provide to us on the Services\nInformation Collected Automatically\nWe collect certain information automatically when you use or explore Base.\nInformation CategoryDescriptionApp, Browser and Device Information• Information about the device, operating system, and browser you’re using• Other device characteristics or identifiers (e.g. plugins, the network you connect to)• IP address/derived location informationInformation from cookies and similar technologiesSee the Base Cookies Policy for further information.\nInformation we obtain from Affiliates and third parties\nWe also receive certain information about you from third parties.\nInformation CategoryDescriptionInformation from Coinbase Companies (“Affiliates”)We may obtain information about you from our Affiliates, such as Basic User Information, tax ID/number, country and, general business information from our Affiliates (for instance, if you use Base with your Coinbase-hosted wallet) as part of facilitating, supporting, or providing our Services.Blockchain DataWe may analyze public blockchain data, including:• Timestamps of transactions or events• Transaction IDs• Digital signatures• Transaction amounts• Wallet addresses• Verifications (onchain attestations)Information from Analytics ProvidersWe receive information about your website usage and interactions from third party analytics providers. This includes browser fingerprint, device information, and IP address.Error Tracking DataWe utilize information from third party service providers to provide automated error monitoring, reporting, alerting and diagnostic capture for Service and Site errors to allow User or Developers to build more effectively on the Base platform.Public Database InformationWe also obtain information about you from public databases, such as the United Nations Sanctions List or listing on any sanctions list maintained by public authorities, media reports, and other data as necessary.\n​2. How We Use Your Information \nWe may use your personal information for the following purposes or as otherwise described at the time of collection. If you reside outside the United Kingdom or European Economic Area (“EEA”), the legal bases on which we rely in your country may differ from those listed below.\nPurposeInformation UsedOur Legal BasisTo provide you with the Base Services We use certain information that is necessary to conclude and perform our Terms of Service or other relevant contract(s) with you.Wallet Address, Basic User Information, Blockchain DataContractual NecessityTo allow Users and Developers to build more effectively on the Base platform We process certain information to identify issues with, and potential improvements to, our Services.Error Tracking Data, Information from Analytics ProvidersLegitimate InterestsTo consider your applications to Base programmes and to administer and facilitate your participation in those programmes We may review your information provided in applications to determine your eligibility for programmes. Programmes include, but are not limited to: Base Advocates, Base Bootcamp, Base funding and/or grants for DevelopersWallet Address, Basic User Information, Application Information, Project Information, Public Database InformationLegitimate InterestsTo provide access to our Base Discord server We use certain information to grant Developers access to our private Base Discord Server.Wallet Information, Basic User InformationLegitimate InterestsTo promote and market Developers’ dapps and projects We review Developers’ dapps and projects to assess whether they can potentially be featured in promotional, marketing or other materials.Project InformationLegitimate InterestsTo provide marketing communications to you We use your information to send you marketing communications.Basic User Information, Project InformationLegitimate InterestsTo promote the safety, security and integrity of our Services To verify wallet addresses and related activity, find and address violations of our Terms of Service, detect fraudulent behaviour and to maintain the integrity of our Services.Basic User Information, Information from Analytics ProvidersContractual NecessityTo obtain your feedback on the Services We use certain information to send you surveys and otherwise obtain your feedback for marketing and product development purposes.Basic User Information, Feedback InformationLegitimate InterestsTo comply with legal and regulatory obligations We may access, read, preserve, and disclose information when we believe it is reasonably necessary to comply with law, legal obligations, regulations, law enforcement, governmental, and other legal requests and court orders, including as an employer, or for disclosure to tax authorities.Wallet Address, Basic User Information, Application Information, Project InformationLegitimate Interests\n​3. How and Why We Share Your Information \nWe share certain information about you with service providers, partners and other third parties in order to help us provide our Services. Here’s how:\nAffiliates. Basic User Information that we process and collect may be transferred between Affiliates, Services, and employees affiliated with us as a normal part of conducting business and offering our Services to you.\nLinked Third Party Websites or Services. When you use third-party services (like when you connect your self-custodial wallet to decentralized applications on the Base network) or websites that are linked through our Services, the providers of those services or products may receive information about you (like your wallet address) from Base, you, or others. Please note that when you use third-party services or connect to third-party websites which are not governed by this Privacy Policy, their own terms and privacy policies will govern your use of those services and products.\nProfessional advisors, industry partners, authorities and regulators. We share your information described in Section 1. What Information We Collect with our advisors, regulators, tax authorities, law enforcement, government agencies, and industry partners when needed to:\n\nrespond pursuant to applicable law or regulations, court orders, legal process or government requests;\ndetect, investigate, prevent, or address fraud and other illegal activity or security and technical issues; and\nprotect the rights, property, and safety of our Users, Developers, Affiliates, or others, including to prevent death or imminent bodily harm.\n\nVendors and Third-Party Service Providers. When we share information with third-party service providers to help us provide our Services, we require them to use your information on our behalf in accordance with our instructions and terms and only process as necessary for the purpose of the contract.\n​4. How Long We Retain Your Personal Information\nWe retain your information as needed to provide our Services, comply with legal obligations or protect our or others’ interests. While retention requirements vary by country, we maintain internal retention policies on the basis of how information needs to be used. This includes considerations such as when the information was collected or created, whether it is necessary in order to continue offering you our Services or to protect the safety, security and integrity of our Services, and whether we are required to hold the information to comply with our legal obligations.\n​5.  Children’s Personal Information\nThe Services are not directed to persons under the age of 18, and we do not knowingly request or collect any information about persons under the age of 18. If you are under the age of 18, please do not provide any personal information through the Site or Services. If a User submitting personal information is suspected of being younger than 18 years of age, we will take steps to delete the individual’s information as soon as possible.\n​6. International Transfers\nTo facilitate our global operations, we and our third-party partners and service providers may transfer and store data throughout the world, including in the United States.\nIf you reside in the EEA, Switzerland, or the United Kingdom, we rely upon a variety of legal mechanisms to facilitate these transfers of your personal information (collectively, “European Personal Data”). ****\n\nWe rely primarily on the European Commission’s Standard Contractual Clauses to facilitate the international and onward transfer of European Personal Data to third countries, including from our EU operating entities to Coinbase, Inc. in the United States, who provides the primary infrastructure for the Services.\nWe also rely on adequacy decisions from the European Commission where available and exemptions provided for under data protection law (e.g. Article 49 GDPR).\n\n​7. Your Privacy Rights and Choices\nDepending on where you live, you may be able to exercise certain privacy rights related to your personal information. You can make privacy rights requests relating to your personal information by contacting us at privacy@base.org. If any of the rights listed below are not provided under law for your operating entity or jurisdiction, Coinbase has absolute discretion in providing you with these rights.\nRight to access and portability:\n\nYou may request that we provide you a copy of your personal information held by us by submitting a request via privacy@base.org.\n\nRight to rectification:\n\nYou may request us to rectify or update any of your personal information held by Coinbase that is incomplete or inaccurate by submitting a request via privacy@base.org.\n\nRight to deletion/erasure:\n\nYou may request to erase your personal information, subject to applicable law.\n\nRight to withdraw your consent:\n\nTo the extent the processing of your personal information is based on your consent, you may withdraw your consent at any time. The lawfulness of Coinbase’s processing before you withdraw your consent will not be affected by such withdrawal.\n\nRight to object to or restrict processing:\n\nYou may have the right to restrict or object to us using or transferring your personal information based on our legitimate interests, in the public interest, or for direct marketing. We may continue to process your personal information where permitted or required by applicable law. You can opt-out of receiving marketing communications from Coinbase by submitting a request via privacy@base.org.\n\nRight to non-discrimination:\n\nWe will not discriminate against you for exercising any of your rights provided to you under law.\n\nRight to lodge a complaint:\n\nIf you reside in the EEA, Switzerland, or the UK, you have the right to lodge a complaint about our practices with respect to your personal information with the supervisory authority of your country or state. In the UK, the relevant data protection authority is the Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF, +44 (0303) 123 1113, email: casework@ico.org.uk. In Ireland, the relevant data protection authority is the Data Protection Commission, 21 Fitzwilliam Square South, Dublin 2, D02 RD28, +353 017650100 / + 353 1800437737, email: info@dataprotection.ie or by using the following online form: Forms for Data Protection.\nIf you reside in Australia or the Philippines, you may lodge a complaint about our practices with respect to your personal information with the supervisory authority of your country. In Australia, the relevant data protection authority is the Office of the Australian Information Commissioner, and complaints may be made through their website at www.oaic.gov.au. In the Philippines, the relevant data protection authority is the National Privacy Commission, email: complaints@privacy.gov.ph.\n\nTo protect your privacy and security, we may take steps to verify your identity before complying with your request and we may decline your request if we are unable to verify your identity.\nUnder certain US data privacy laws, as well as in Brazil, you may also designate an authorized agent to make these requests on your behalf.\nThese rights are not absolute, and may be denied: (a) when granting access or assisting portability would adversely affect the rights and freedoms of others (b) to protect our rights and properties; (c) where the request is frivolous or vexatious; or (d) as otherwise permitted by law.\n​8. How to Contact Us with Questions\nIf you have questions or concerns regarding this Privacy Policy, or if you have a complaint, please contact us at privacy@base.org.\n​9. Changes to This Privacy Policy\nWe’re constantly trying to improve our Services, so we may need to change this Privacy Policy from time to time as well. We post any changes we make to our Privacy Policy on this page and, where appropriate, we will provide you with reasonable notice of any material changes before they take effect or as otherwise required by law. The date the Privacy Policy was last updated is identified at the top of this page.\n​10. Our Relationship with You\nCoinbase Technologies, Inc., 251 Little Falls Drive, City of Wilmington, County of New Castle, Delaware 19808, acts as controller of your personal data.Was this page helpful?Suggest editsRaise issue","tokens":3852,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267450128,"hash":"d05e1438b4a3c219719402b2e6a294f94b911d8b"}
{"url":"https://ethresear.ch/t/gluon-plasma-full-spec-for-non-custodial-exchanges/3931/30","domain":"ethresear.ch","title":"Gluon Plasma Full Spec for Non-custodial Exchanges - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 16\n\n 4\n\n 4\n\n 3\n\n 2\n\n read \n\n 18\n min\n\n Oct 2018\n\n 30 / 30\n\n Feb 2019\n\n Feb 2019\n\n Load more posts above\n\n post by bharathrao on Oct 26, 2018\n\n post by ritikm on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by ritikm on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by bharathrao on Oct 31, 2018\n\n post by yan on Oct 31, 2018\n\n post by bharathrao on Oct 31, 2018\n\n post by yan on Nov 1, 2018\n\n post by bharathrao on Nov 1, 2018\n\n post by yan on Nov 1, 2018\n\n post by bharathrao on Nov 2, 2018\n\n post by MihailoBjelic on Nov 2, 2018\n\n post by bharathrao on Nov 2, 2018\n\n post by MihailoBjelic on Nov 3, 2018\n\n post by bharathrao on Nov 3, 2018\n\n bharathrao\n\nThanks for the correction.\n\nI see, thanks for the input. The other option we are considering is Dfinity style consensus using BLS signature aggregation. This can probably be done log(n) due to BLS properties.\nOr crypto-economic signatures as described here.\nEither way, we should be able to support 400+ validators, which should be fairly resistant to cartelization.\n\n post by MihailoBjelic on Nov 4, 2018\n\n MihailoBjelic\n\nI think that would be awesome.\nA highly decentralized validator set instantly solves most of the issues. The hard part is to chose a proper consensus (I generally like Dfinity’s approach) and to bootstrap the network (token economics has to be tuned well).\n\n 4 months later\n\n post by bharathrao on Feb 19, 2019\n\n bharathrao\n\n FYI, leverj is live with Gluon Plasma. An excellent example of research turning into a working product. Just wanted to thank everyone for their input and vetting the idea.\n\n post by MihailoBjelic on Feb 20, 2019\n\n MihailoBjelic\n\n That is great, good luck and keep us updated. \n\n Powered by Discourse","tokens":456,"squid":"ink-research","role":"Deep Scholar","at":1791267455084,"hash":"ffae12d42daf6396651633c623b41d7e2ece2f05"}
{"url":"https://ethresear.ch/t/gluon-plasma-full-spec-for-non-custodial-exchanges/3931/1","domain":"ethresear.ch","title":"Gluon Plasma Full Spec for Non-custodial Exchanges - Layer 2 / Plasma - Ethereum Research","text":"Gluon Plasma Full Spec for Non-custodial Exchanges \n\n Layer 2Plasma\n\n new-extension\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Oct 2018\n\n 1 / 30\n\n Oct 2018\n\n Feb 2019\n\n post by bharathrao on Oct 25, 2018\n\n bharathrao\n\n This is a followup post on “A DEX on plasma” from Apr’18. We have gone through many iterations and have what we believe is a production quality spec. Note that ours is designed for trading and not UTXO payments like almost all other specs here.\nOur focus is weighted with UX, Scaling and Security in that order.\nUX is the primary driver since we are building a business, not just engaging in technical research. Most of our choices were based on pragmatic conditions of the market and user base today. For example, we realized that exit games are a non-starter because although they work, even many tech-savvy users would avoid such exchanges at the current time. Our users were also confused why they have to deposit a heavy bond to take out their own money.\nScaling was the next primary driver. We aimed for sub-linear cost in terms of gas, storage and computational load with increasing volume. Without this, the platform becomes self-limiting as gas costs drive traders elsewhere. Scaling also feeds into security since super-linear cost would make it practical to overwhelm any validators with long chains of transactions, dust trades and other attacks whose impact is amplified by high activity.\nSecurity is last but not the least. It is intertwined with the two needs above. We needed a security model and proof so that the model could be examined and any gaps speedily addressed.\nRead the full Gluon Plasma paper to understand our motivations and drivers.\nTop features:\n\nOffline Recipient\nInstant finality on plasma chain\nFast withdraws (< 1 hour)\nFungible\nUnlimited number of coins\nUnlimited trades per block\nLight nodes\nCompact fraud proofs\nEthereum Network Congestion tolerant\nSecurity Model/Proof\nWatchtower-free\nExit Game-free\nChallenge/Response-free\n\nOk, so what’s the catch?\nData Unavailability is not yet eliminated. A governance token is used to vote for a chain halt if the operator turns maleficent. SEE UPDATE BELOW\nSecurity Proof Outline\nA payment network is secure if the following constraints hold for every transaction:\n\nThe recipient can receive the payment directly.\nThe sender’s provable intention is required to send the payment.\nThe amount received is exactly the amount sent.\nNetwork participants can verify validity according to consensus rules.\n\nIf it can be shown that every state change enforces the above, then the network is safe. The above needs to be enforced at 3 levels:\n\nAll steps of the protocol, which is the interface between the main chain and plasma chain\nPlasma ledger entries\nPlasma chain, which is the arrangement of plasma ledger entries.\n\nI ask the reader to read the full paper since the protocol and the fraud proofs together make the system, so listing just the protocol here would be a disservice.\nGuide to reading the paper: What each chapter speaks about\n3: Deriving account model from UTXO model\n4: How Exchange security models work\n5: Why we needed a different plasma flavor\n6: Gluon Plasma fundamentals\n7: Gluon Plasma characteristics (is this flavor suitable for your project?)\n8: Gluon Plasma Protocol\n9: Fraud Proofs\nAppendix A,B and C: Proofs of safety and custody\nYour improvements and critical feedback is highly appreciated!\nUPDATE: Joey Krug suggested we replace the POA with tendermint consensus POS. We realized that if we decouple the exchange and consensus (ie block committer) roles, we can eliminate data unavailability:\n\nExchange(s) creates transactions.\nTendermint POS committers create blocks from transactions.\nIf exchange withholds data, POS validators will simply not commit any more blocks.\nIf at least 1/3 of the POS validators collude with the exchange and duplicitously commit a block while withholding data, other POS validators can slash their deposit (which needs to be hefty).\n\nRegarding 3. Chain is abandoned and halts when there is a single exchange on the plasma chain. On a multi-exchange chain, the byzantine exchange is ejected and trades in its block are effectively rolled back. Other exchanges can continue to operate. Multi-exchange feature is not yet finalized.\nA single exchange Tendermint POS can probably be implemented without much impact.\n\n Only 3 opecodes are needed to build DEX on Plasma Chain\n\n Plasma World Map - the hitchhiker’s guide to the plasma\n\n 16\n\n 4\n\n 4\n\n 3\n\n 2\n\n read \n\n 18\n min\n\n post by sg on Oct 25, 2018\n\n post by ritikm on Oct 26, 2018\n\n post by themandalore on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by ritikm on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by sg on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by ritikm on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by ritikm on Oct 26, 2018\n\n post by bharathrao on Oct 26, 2018\n\n post by bharathrao on Oct 31, 2018\n\n post by yan on Oct 31, 2018\n\n post by bharathrao on Oct 31, 2018\n\n post by yan on Nov 1, 2018\n\n Load more posts below","tokens":1305,"squid":"ink-research","role":"Deep Scholar","at":1791267465287,"hash":"1c5eace9cfa1920097fc498163a9a6bb3f1f56f5"}
{"url":"https://docs.base.org/get-started/resources-for-ai-agents","domain":"docs.base.org","title":"Resources for AI Agents - Base Documentation","text":"Fetch the complete documentation index at https://docs.base.org/llms.txt.\nUse this file to discover all available pages before exploring further.\nUse this page as the starting point when you want an AI assistant to build on Base. It covers three ways to give an assistant Base context: static docs files, a live MCP connection, and installable skills. You’ll also find recommended entry points for common workflows.\n​Quick Setup\nGet your agent connected to Base docs in one command. Pick the method that fits your tool.\n​MCP Server\nA live connection lets your assistant search and read Base docs on demand, so it always has current information.\nclaude mcp add --transport http base-docs https://docs.base.org/mcp\ncodex mcp add base-docs --url https://docs.base.org/mcp\n{\n \"mcpServers\": {\n \"base-docs\": {\n \"url\": \"https://docs.base.org/mcp\"\n }\n }\n}\n\nSee the full MCP setup guide for Cursor, Windsurf, and other editors.\n​Static Docs Files\nUse these when you want to load context in a single fetch rather than maintaining a live connection.\nFileWhat it containsWhen to use itllms.txtPage index with titles and descriptionsDiscovering which docs exist before going deeperllms-full.txtComplete documentation in one fileGiving an assistant broad context in one shot\nEvery docs page is also available as plain Markdown. Append .md to any URL:\nMarkdown URLhttps://docs.base.org/get-started/resources-for-ai-agents.md\n\n​Skills\nSkills are installable agent workflows for common Base tasks, including connecting to Base, deploying contracts, running a node, and more. They give your assistant step-by-step procedural guidance instead of requiring it to piece together docs on its own.\nTerminalnpx skills install base/skills -g\n\nBrowse available skills in the Base skills repository.\n​Recommended Starting Points\nOnce your agent has docs context, point it at the section that matches what you’re building:\nWhat you’re doingStart hereConnecting an assistant to live docsMCP serverLoading docs as static filesStatic docs filesAdding payments or onchain transactionsMake x402 paymentsDeploying contractsDeploy on BaseBuilding an app on BaseBuild a Base app\n​Example Prompts\nCopy these into your assistant to test that everything is working:\n\n“Deploy my ERC-20 contract to Base Sepolia and verify it on Basescan.”\n“Add Sign in with Base to my Next.js app using wagmi.”\n“Set up a wallet for my AI agent that can hold USDC and sign transactions autonomously.”\n“Create an app with a USDC payment flow.”\n“Build an agent that pays for API requests using the x402 protocol.”\nWas this page helpful?Suggest editsRaise issue","tokens":650,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267472532,"hash":"da8a271ff917ef4445285a4888d3c5a4a33501ae"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/assembly.html","domain":"docs.soliditylang.org","title":"Inline Assembly — Solidity 0.8.31-develop documentation","text":"Inline Assembly\n\n Edit on GitHub\n\nInline Assembly\nYou can interleave Solidity statements with inline assembly in a language close\nto the one of the Ethereum Virtual Machine. This gives you more fine-grained control,\nwhich is especially useful when you are enhancing the language by writing libraries or\noptimizing gas usage.\nThe language used for inline assembly in Solidity is called Yul\nand it is documented in its own section. This section will only cover\nhow the inline assembly code can interface with the surrounding Solidity code.\n\nWarning\nInline assembly is a way to access the Ethereum Virtual Machine\nat a low level. This bypasses several important safety\nfeatures and checks of Solidity. You should only use it for\ntasks that need it, and only if you are confident with using it.\n\nAn inline assembly block is marked by assembly { ... }, where the code inside\nthe curly braces is code in the Yul language.\nThe inline assembly code can access local Solidity variables as explained below.\nDifferent inline assembly blocks share no namespace, i.e. it is not possible\nto call a Yul function or access a Yul variable defined in a different inline assembly block.\n\nExample\nThe following example provides library code to access the code of another contract and\nload it into a bytes variable. This is possible with “plain Solidity” too, by using\n<address>.code. But the point here is that reusable assembly libraries can enhance the\nSolidity language without a compiler change.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\nlibrary GetCode {\n function at(address addr) public view returns (bytes memory code) {\n assembly {\n // retrieve the size of the code, this needs assembly\n let size := extcodesize(addr)\n // allocate output byte array - this could also be done without assembly\n // by using code = new bytes(size)\n code := mload(0x40)\n // new \"memory end\" including padding\n mstore(0x40, add(code, and(add(add(size, 0x20), 0x1f), not(0x1f))))\n // store length in memory\n mstore(code, size)\n // actually retrieve the code, this needs assembly\n extcodecopy(addr, add(code, 0x20), 0, size)\n }\n }\n}\n\nInline assembly is also beneficial in cases where the optimizer fails to produce\nefficient code, for example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\nlibrary VectorSum {\n // This function is less efficient because the optimizer currently fails to\n // remove the bounds checks in array access.\n function sumSolidity(uint[] memory data) public pure returns (uint sum) {\n for (uint i = 0; i < data.length; ++i)\n sum += data[i];\n }\n\n // We know that we only access the array in bounds, so we can avoid the check.\n // 0x20 needs to be added to an array because the first slot contains the\n // array length.\n function sumAsm(uint[] memory data) public pure returns (uint sum) {\n for (uint i = 0; i < data.length; ++i) {\n assembly {\n sum := add(sum, mload(add(add(data, 0x20), mul(i, 0x20))))\n }\n }\n }\n\n // Same as above, but accomplish the entire code within inline assembly.\n function sumPureAsm(uint[] memory data) public pure returns (uint sum) {\n assembly {\n // Load the length (first 32 bytes)\n let len := mload(data)\n\n // Skip over the length field.\n //\n // Keep temporary variable so it can be incremented in place.\n //\n // NOTE: incrementing data would result in an unusable\n // data variable after this assembly block\n let dataElementLocation := add(data, 0x20)\n\n // Iterate until the bound is not met.\n for\n { let end := add(dataElementLocation, mul(len, 0x20)) }\n lt(dataElementLocation, end)\n { dataElementLocation := add(dataElementLocation, 0x20) }\n {\n sum := add(sum, mload(dataElementLocation))\n }\n }\n }\n}\n\nAccess to External Variables, Functions and Libraries\nYou can access Solidity variables and other identifiers by using their name.\nLocal variables of value type are directly usable in inline assembly.\nThey can both be read and assigned to.\nLocal variables that refer to memory evaluate to the address of the variable in memory, not the value itself.\nSuch variables can also be assigned to, but note that an assignment will only change the pointer and not the data\nand that it is your responsibility to respect Solidity’s memory management.\nSee Conventions in Solidity.\nSimilarly, local variables that refer to statically-sized calldata arrays or calldata structs\nevaluate to the address of the variable in calldata, not the value itself.\nThe variable can also be assigned a new offset, but note that no validation is performed to ensure that\nthe variable will not point beyond calldatasize().\nFor external function pointers the address and the function selector can be\naccessed using x.address and x.selector.\nThe selector consists of four right-aligned bytes.\nBoth values can be assigned to. For example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.10 <0.9.0;\n\ncontract C {\n // Assigns a new selector and address to the return variable @fun\n function combineToFunctionPointer(address newAddress, uint newSelector) public pure returns (function() external fun) {\n assembly {\n fun.selector := newSelector\n fun.address := newAddress\n }\n }\n}\n\nFor dynamic calldata arrays, you can access\ntheir calldata offset (in bytes) and length (number of elements) using x.offset and x.length.\nBoth expressions can also be assigned to, but as for the static case, no validation will be performed\nto ensure that the resulting data area is within the bounds of calldatasize().\nFor local storage variables or state variables (including transient storage) a single Yul identifier\nis not sufficient, since they do not necessarily occupy a single full storage slot.\nTherefore, their “address” is composed of a slot and a byte-offset\ninside that slot. To retrieve the slot pointed to by the variable x, you\nuse x.slot, and to retrieve the byte-offset you use x.offset.\nUsing x itself will result in an error.\nYou can also assign to the .slot part of a local storage variable pointer.\nFor these (structs, arrays or mappings), the .offset part is always zero.\nIt is not possible to assign to the .slot or .offset part of a state variable,\nthough.\nLocal Solidity variables are available for assignments, for example:\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.8.28 <0.9.0;\n\n// This will report a warning\ncontract C {\n bool transient a;\n uint b;\n function f(uint x) public returns (uint r) {\n assembly {\n // We ignore the storage slot offset, we know it is zero\n // in this special case.\n r := mul(x, sload(b.slot))\n tstore(a.slot, true)\n }\n }\n}\n\nWarning\nIf you access variables of a type that spans less than 256 bits\n(for example uint64, address, or bytes16),\nyou cannot make any assumptions about bits not part of the\nencoding of the type. Especially, do not assume them to be zero.\nTo be safe, always clear the data properly before you use it\nin a context where this is important:\nuint32 x = f(); assembly { x := and(x, 0xffffffff) /* now use x */ }\nTo clean signed types, you can use the signextend opcode:\nassembly { signextend(<num_bytes_of_x_minus_one>, x) }\n\nSince Solidity 0.6.0, the name of an inline assembly variable may not\nshadow any declaration visible in the scope of the inline assembly block\n(including variable, contract and function declarations).\nSince Solidity 0.7.0, variables and functions declared inside the\ninline assembly block may not contain ., but using . is\nvalid to access Solidity variables from outside the inline assembly block.\nHowever, it is still valid to use dots if you use Solidity in Yul-only mode.\n\nThings to Avoid\nInline assembly might have a quite high-level look, but it actually is extremely\nlow-level. Function calls, loops, ifs and switches are converted by simple\nrewriting rules and after that, the only thing the assembler does for you is re-arranging\nfunctional-style opcodes, counting stack height for\nvariable access and removing stack slots for assembly-local variables when the end\nof their block is reached.\n\nConventions in Solidity\n\nValues of Typed Variables\nIn contrast to EVM assembly, Solidity has types which are narrower than 256 bits,\ne.g. uint24. For efficiency, most arithmetic operations ignore the fact that\ntypes can be shorter than 256\nbits, and the higher-order bits are cleaned when necessary,\ni.e., shortly before they are written to memory or before comparisons are performed.\nThis means that if you access such a variable\nfrom within inline assembly, you might have to manually clean the higher-order bits\nfirst.\n\nMemory Management\nSolidity manages memory in the following way. There is a “free memory pointer”\nat position 0x40 in memory. If you want to allocate memory, use the memory\nstarting from where this pointer points at and update it.\nThere is no guarantee that the memory has not been used before and thus\nyou cannot assume that its contents are zero bytes.\nThere is no built-in mechanism to release or free allocated memory.\nSolidity does not guarantee and does not require that the values in memory\nare placed at positions aligned to a multiple of any value.\nHere is an assembly snippet you can use for allocating memory that follows the process outlined above:\nopen in Remix\nfunction allocate(length) -> pos {\n pos := mload(0x40)\n mstore(0x40, add(pos, length))\n}\n\nThe first 64 bytes of memory can be used as “scratch space” for short-term\nallocation. The 32 bytes after the free memory pointer (i.e., starting at 0x60)\nare meant to be zero permanently and is used as the initial value for\nempty dynamic memory arrays.\nThis means that the allocatable memory starts at 0x80, which is the initial value\nof the free memory pointer.\nElements in memory arrays in Solidity always occupy multiples of 32 bytes (this is\neven true for bytes1[], but not for bytes and string). Multi-dimensional memory\narrays are pointers to memory arrays. The length of a dynamic array is stored at the\nfirst slot of the array and followed by the array elements.\n\nWarning\nStatically-sized memory arrays do not have a length field, but it might be added later\nto allow better convertibility between statically and dynamically-sized arrays; so,\ndo not rely on this.\n\nMemory Safety\nWithout the use of inline assembly, the compiler can rely on memory to remain in a well-defined\nstate at all times. This is especially relevant for the new code generation pipeline via Yul IR:\nthis code generation path can move local variables from stack to memory to avoid stack-too-deep errors and\nperform additional memory optimizations, if it can rely on certain assumptions about memory use.\nWhile we recommend to always respect Solidity’s memory model, inline assembly allows you to use memory\nin an incompatible way. Therefore, moving stack variables to memory and additional memory optimizations are,\nby default, globally disabled in the presence of any inline assembly block that contains a memory operation\nor assigns to Solidity variables in memory.\nHowever, you can specifically annotate an assembly block to indicate that it in fact respects Solidity’s memory\nmodel as follows:\nopen in Remix\nassembly (\"memory-safe\") {\n ...\n}\n\nIn particular, a memory-safe assembly block may only access the following memory ranges:\n\nMemory allocated by yourself using a mechanism like the allocate function described above.\nMemory allocated by Solidity, e.g. memory within the bounds of a memory array you reference.\nThe scratch space between memory offset 0 and 64 mentioned above.\nTemporary memory that is located after the value of the free memory pointer at the beginning of the assembly block,\ni.e. memory that is “allocated” at the free memory pointer without updating the free memory pointer.\n\nFurthermore, if the assembly block assigns to Solidity variables in memory, you need to assure that accesses to\nthe Solidity variables only access these memory ranges.\nSince this is mainly about the optimizer, these restrictions still need to be followed, even if the assembly block\nreverts or terminates. As an example, the following assembly snippet is not memory safe, because the value of\nreturndatasize() may exceed the 64 byte scratch space:\nopen in Remix\nassembly {\n returndatacopy(0, 0, returndatasize())\n revert(0, returndatasize())\n}\n\nOn the other hand, the following code is memory safe, because memory beyond the location pointed to by the\nfree memory pointer can safely be used as temporary scratch space:\nopen in Remix\nassembly (\"memory-safe\") {\n let p := mload(0x40)\n returndatacopy(p, 0, returndatasize())\n revert(p, returndatasize())\n}\n\nNote that you do not need to update the free memory pointer if there is no following allocation,\nbut you can only use memory starting from the current offset given by the free memory pointer.\nIf the memory operations use a length of zero, it is also fine to just use any offset (not only if it falls into the scratch space):\nopen in Remix\nassembly (\"memory-safe\") {\n revert(0, 0)\n}\n\nNote that not only memory operations in inline assembly itself can be memory-unsafe, but also assignments to\nSolidity variables of reference type in memory. For example the following is not memory-safe:\nopen in Remix\nbytes memory x;\nassembly {\n x := 0x40\n}\nx[0x20] = 0x42;\n\nInline assembly that neither involves any operations that access memory nor assigns to any Solidity variables\nin memory is automatically considered memory-safe and does not need to be annotated.\n\nWarning\nIt is your responsibility to make sure that the assembly actually satisfies the memory model. If you annotate\nan assembly block as memory-safe, but violate one of the memory assumptions, this will lead to incorrect and\nundefined behavior that cannot easily be discovered by testing.\n\nIn case you are developing a library that is meant to be compatible across multiple versions\nof Solidity, you can use a special comment to annotate an assembly block as memory-safe:\nopen in Remix\n/// @solidity memory-safe-assembly\nassembly {\n ...\n}\n\nWarning\nThe memory-safe-assembly special comment is deprecated and scheduled for removal.\nIn new code targeting recent compilers, use the assembly block annotation.\n\nAdvanced Safe Use of Memory\nBeyond the strict definition of memory-safety given above, there are cases in which you may want to use more than 64 bytes\nof scratch space starting at memory offset 0. If you are careful, it can be admissible to use memory up to (and not\nincluding) offset 0x80 and still safely declare the assembly block as memory-safe.\nThis is admissible under either of the following conditions:\n\nBy the end of the assembly block, the free memory pointer at offset 0x40 is restored to a sane value (i.e. it is either\nrestored to its original value or an increment of it due to a manual memory allocation), and the memory word at offset 0x60\nis restored to a value of zero.\nThe assembly block terminates, i.e. execution can never return to high-level Solidity code. This is the case, for example,\nif your assembly block unconditionally ends in calling the revert opcode.\n\nFurthermore, you need to be aware that the default-value of dynamic arrays in Solidity point to memory offset 0x60, so\nfor the duration of temporarily changing the value at memory offset 0x60, you can no longer rely on getting accurate\nlength values when reading dynamic arrays, until you restore the zero value at 0x60. To be more precise, we only guarantee\nsafety when overwriting the zero pointer, if the remainder of the assembly snippet does not interact with the memory of\nhigh-level Solidity objects (including by reading from offsets previously stored in variables).","tokens":3889,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267475004,"hash":"f34c9a2814f7a132427eaad393c49f2aeb4d5dbe"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/21","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 21 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n Load more posts below","tokens":3098,"squid":"ink-research","role":"Deep Scholar","at":1791267475670,"hash":"8118d0c34c31d21fefff4642b8c80cfc2567a37c"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/23","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 23 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n post by vbuterin on Jan 15, 2018\n\n vbuterin\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\nPretty much. Or rather, an “anyone can call” function that looks at the top exit in the queue, checks that it is eligible for withdrawal, and if so pops it from the queue and sends the recipient their funds.\n\n A DEX on Plasma\n\n post by AFDudley on Jan 17, 2018\n\n AFDudley\n\n This is super helpful in understanding plasma. Still seems like trusting a few bonded parties in a multiparty state channel to create a subnetwork of validators, then using state channels as two way pegs between the the subnetwork and the main network is a far cleaner solution. Fraud proofs can be used in such a system as well.\n\n post by ltfschoen on Jan 17, 2018\n\n ltfschoen\n\n OmiseGo just released a repo with the MVP of Plasma https://github.com/omisego/plasma-mvp\n\n post by MicahZoltu on Jan 17, 2018\n\n MicahZoltu\n\n AFDudley\n\n @AFDudley Do you have a link or reference to what you are referring to?\n\n post by mrsmkl on Jan 19, 2018\n\n mrsmkl\n\n I’m thinking about how to use Truebit to implement Plasma chains with more complex transactions. Assuming that all the data is available, and given the merkle roots of input and program code, Truebit can verify the correctness of merkle root of output. In this case, the input could be\n\nthe world state\nlist of transactions\n\nThe program would then transform the world to a new state (this would be the output). To make exiting easier, there could be another output of with balances or something. Of course the child chain has to be designed so that if somebody exits, the child chain won’t become broken (users will have to send some kind of confirmations that can be used to challenge exits).\nHere is some untested code: https://github.com/mrsmkl/truebit-plasma\nBasically everything is supposed to work the same as in David’s implementation, the world state is just different.\n\n post by JustinDrake on Jan 20, 2018\n\n JustinDrake\n\nI’ve also been thinking about Plasma implemented with Truebit in this post. It makes a lot of sense IMO.\n\nFor data availability one can use log shards, which is basically sharding for data availability.\n\nCongrats for whipping something out this fast!\n\n 8 days later\n\n post by mewwts on Jan 29, 2018\n\n mewwts\n\n So if I understand this correctly, to the Ethereum blockchain, a sidechain is simply a contract with (something like) the defined MVPlasma interface? Are any changes required to the Ethereum protocol for Plasma to become a reality?\n\nWhat are the requirements for a sidechain to operate under MVPlasma? If I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nAre any changes required to the Ethereum protocol for Plasma to become a reality?\n\nNo.\n\nWhat are the requirements for a sidechain to operate under MVPlasma?\n\nIt must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.\n\nIf I publish a smart contract with this interface, run a single trusted node that pools transactions into blocks and publish merkle roots to the contract, am I running a sidechain?\n\nYes.\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\nCan smart contracts run under UTXO model? I think, a bit of an unclear question is how existing ERC-20 tokens will be able to utilize plasma …\nIs MVP plasma meant to be a transaction scaling platform or a smart contract scaling platform ? How can CryptoKitties be ported to a Plasma chain ?\n\n post by vbuterin on Jan 29, 2018\n\n vbuterin\n\nCan smart contracts run under UTXO model?\n\nTheoretically yes. You just need to have a transaction model where the validity of a transaction can depend on statements about both the inputs and the outputs. Basically, you would have a UTXO with spending conditions like “a transaction can spend me if it contains exactly one output that looks exactly like me, but with the internal state modified in some small way based on the instruction fed in through the transaction’s other input”. Though IMO this is very ugly, and accounts are in general just plain better. One key benefit of accounts is that they have consistent addresses that other contracts can use to reference them, whereas UTXO “addresses” (ie. txhashes, or blknum+txindex) change after every transaction.\n\nHow can CryptoKitties be ported to a Plasma chain ?\n\nCryptoKitties is just an N-currency system where each currency has one unit in circulation, plus the extra breeding feature. It’s totally plasmafiable.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\nUnderstood …\n\nHave you already thought about a protocol to be used for that? As an example, if I am an “owner” of an smartcontract account which is an ERC-20 token, and someone submits a transaction to transfer tokens from Alice to Bob, then I need to somehow sign off …\nNot clear whether a generic SmartContract from the main chain can be easily ported to a “sign off” account on Plasma …\n\nOkay … So Plasma will not run SmartContracts compiled for the main chain,\nthey will need to be “plasmafied” or ported to Plasma in some way.\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\nThis means that in the future simple sharding and Plasma will need to co-exist since simple sharding will be able to run EVM smart contracts.\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nYeah, so for ERC20-like tokens, it would need to be the owner of the token that signs off. You would need to split up state into discrete pieces, where each individual piece has a defined logical owner.\n\nThis is a statement which one needs to make - Plasma will be able to speed up currency transactions and may (?) provide a limited capability to run simple smart contracts but it will not be used to scale regular generic EVM smart contracts.\n\nI don’t think “simple” is the right term; you could have very complex contracts inside of Plasma, and you could even use the EVM to administer them, it’s just the cross-contract calling interface that would be different, as well as the requirement to assign contracts to owners. I think something like “a constrained form of smart contracts” would be more accurate.\n\n post by kladkogex on Jan 30, 2018\n\n kladkogex\n\n Thank you - this explains lots of things \nOne thing that remains unclear in my head is when you talk about the contract owner “signing off”.\n\nAlice owns a account which contains her possessions of smart tokens X, Y, Z.\n\nBob owns another account which contains his possessions of smart tokens X, Y, Z\n\nNow Bob comes and wants to give Alice more of the token Z. Essentially he needs to\nincrease the value of variable Z in Alice’s account and decrease his value of Z.\n\nHow is the “sign off” exactly going to happen? Do Alice and Bob sign a transaction outside of Plasma and submit a double signed transaction to Plasma? )\n\n post by vbuterin on Jan 30, 2018\n\n vbuterin\n\nBob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.\nAlice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.\n\n Load more posts below","tokens":2860,"squid":"ink-research","role":"Deep Scholar","at":1791267487092,"hash":"335c63aa870147eb9ff9dd5377c77a9fc4ffa658"}
{"url":"https://forum.pyth.network/t/pyth-playground-community-hackathon/2363/26","domain":"forum.pyth.network","title":"Pyth Playground Community Hackathon - Ideas Bank - Pyth DAO","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 3\n\n 2\n\n 2\n\n Feb 24\n\n 26 / 26\n\n Mar 11\n\n Mar 11\n\n Load more posts above\n\n post by Planck on Feb 25\n\n post by KemarTiti on Feb 25\n\n post by CrownOfLagos on Feb 25\n\n post by Defi_Godwinn on Feb 25\n\n post by Defilion on Feb 26\n\n post by theRoad on Feb 26\n\n post by totti on Feb 26\n\n post by Flint on Feb 26\n\n post by BeeKey201 on Feb 26\n\n post by SkyZ on Feb 26\n\n post by lowkeigh on Feb 26\n\n post by spank2023 on Feb 26\n\n post by Mersault on Feb 26\n\n post by Mersault on Feb 26\n\n post by pstar on Feb 28\n\n post by Dbxcel on Mar 2\n\n post by Agarwal on Mar 3\n\n Agarwal\n\n i hope things going as per schedule and we can see the dedicated announcement soon with all the helpful kits ,templates , etc\n\n post by Nikkudotdev on Mar 8\n\n Nikkudotdev\n\n Hey everyone! \nI’m Nikku.Dev , a full-stack blockchain developer working across smart contracts, DeFi, and consumer dApps. I’ve been building in the Web3 space for a few years and love experimenting with new ideas, especially around on-chain products and Decentralized infrastructure.\nExcited to be part of this community and learn from everyone here!\nWhat kind of projects are you all currently working on?\nDeFi, AI x Crypto, Infra, Consumer apps, or something totally different?\n\n post by Nikkudotdev on Mar 10\n\n Nikkudotdev\n\n I’m building an interactive Pyth Oracle Playground where developers can visually experiment with oracle operations like Entropy generation and Price Feed consumption using a simple drag-and-drop interface.\nInstead of writing complex code from scratch, users will be able to create oracle circuits visually connecting components like price feeds, entropy requests, and smart contract triggers in a playground-style environment.\nThe goal is to make it easier for developers, especially during hackathons and rapid prototyping, to understand and integrate Pyth oracles without friction.\n@Pyth-DAO @PythDataAssociation\nLFG\n\n post by Nikkudotdev on Mar 11\n\n Nikkudotdev\n\n Building Pyth Playground for Devrels and community members to show the power of pyth and how pyth integrations done via client side\nCheckout @Pyth-DAO @PythDataAssociation\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Hackathon post-mortem\n\n Community Council\n\n 6\n\n 239\n\n May 31\n\n Pythian got talent\n\n Ideas Bank\n\n 3\n\n 136\n\n Oct 2025\n\n Pythians got talent\n\n Ideas Bank\n\n 1\n\n 75\n\n Sep 2025\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 567\n\n Apr 6\n\n Has anyone experimented with Pyth price feeds outside of traditional DeFi applications?\n\n Ideas Bank\n\n 1\n\n 63\n\n Jul 4","tokens":663,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267487241,"hash":"e02409357c54b24cd079545ae15dcafc50742b46"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/installing-solidity.html","domain":"docs.soliditylang.org","title":"Installing the Solidity Compiler — Solidity 0.8.31-develop documentation","text":"Installing the Solidity Compiler\n\n Edit on GitHub\n\nInstalling the Solidity Compiler\n\nVersioning\nSolidity versions follow Semantic Versioning. In\naddition, patch-level releases with major release 0 (i.e. 0.x.y) will not\ncontain breaking changes. That means code that compiles with version 0.x.y\ncan be expected to compile with 0.x.z where z > y.\nIn addition to releases, we provide prereleases and nightly development builds to make it\neasy for developers to try out upcoming features and provide early feedback.\nNote that such builds contain bleeding-edge code from the development branch and are not guaranteed\nto be of the same quality as full releases.\nDespite our best efforts, they might contain undocumented and/or broken changes that will not\nbecome a part of an actual release. They are not meant for production use.\nWhen deploying contracts, you should use the latest released version of Solidity. This\nis because breaking changes, as well as new features and bug fixes are introduced regularly.\nWe currently use a 0.x version number to indicate this fast pace of change.\n\nRemix\nWe recommend Remix for small contracts and for quickly learning Solidity.\nAccess Remix online, you do not need to install anything.\nIf you want to use it without connection to the Internet, go to\nhttps://github.com/ethereum/remix-live/tree/gh-pages#readme and follow the instructions on that page.\nRemix is also a convenient option for testing nightly builds\nwithout installing multiple Solidity versions.\nFurther options on this page detail installing command-line Solidity compiler software\non your computer. Choose a command-line compiler if you are working on a larger contract\nor if you require more compilation options.\n\nnpm / Node.js\nUse npm for a convenient and portable way to install solcjs, a Solidity compiler. The\nsolcjs program has fewer features than the ways to access the compiler described\nfurther down this page. The\nUsing the Commandline Compiler documentation assumes you are using\nthe full-featured compiler, solc. The usage of solcjs is documented inside its own\nrepository.\nNote: The solc-js project is derived from the C++\nsolc by using Emscripten, which means that both use the same compiler source code.\nsolc-js can be used in JavaScript projects directly (such as Remix).\nPlease refer to the solc-js repository for instructions.\nnpm install --global solc\n\nNote\nThe command-line executable is named solcjs.\nThe command-line options of solcjs are not compatible with solc and tools (such as geth)\nexpecting the behavior of solc will not work with solcjs.\n\nDocker\nDocker images of Solidity builds are available using the solc image from the argotorg organization on ghcr.io.\nUse the stable tag for the latest released version, and nightly for potentially unstable changes in the develop branch.\nThe Docker image runs the compiler executable so that you can pass all compiler arguments to it.\nFor example, the command below pulls the stable version of the solc image (if you do not have it already),\nand runs it in a new container, passing the --help argument.\ndocker run ghcr.io/argotorg/solc:stable --help\n\nNote\nSpecific compiler versions are supported as the Docker image tag such as ghcr.io/argotorg/solc:0.8.23.\nWe will be passing the stable tag here instead of specific version tag to ensure that users get\nthe latest version by default and avoid the issue of an out-of-date version.\n\nTo use the Docker image to compile Solidity files on the host machine, mount a\nlocal folder for input and output, and specify the contract to compile. For example:\ndocker run \\\n --volume \"/tmp/some/local/path/:/sources/\" \\\n ghcr.io/argotorg/solc:stable \\\n /sources/Contract.sol \\\n --abi \\\n --bin \\\n --output-dir /sources/output/\n\nYou can also use the standard JSON interface (which is recommended when using the compiler with tooling).\nWhen using this interface, it is not necessary to mount any directories as long as the JSON input is\nself-contained (i.e. it does not refer to any external files that would have to be\nloaded by the import callback).\ndocker run ghcr.io/argotorg/solc:stable --standard-json < input.json > output.json\n\nLinux Packages\nBinary packages of Solidity are available at\nsolidity/releases.\nUbuntu packages for versions up to 0.8.30 are available in the\nethereum/ethereum PPA.\nHowever, we have discontinued this distribution method and future versions will not be added there.\nFurthermore, some Linux distributions provide their own packages. These packages are not directly\nmaintained by us but usually kept up-to-date by the respective package maintainers.\nFor example, Arch Linux has packages for the latest development version as AUR packages: solidity\nand solidity-bin.\n\nNote\nPlease be aware that AUR packages\nare user-produced content and unofficial packages. Exercise caution when using them.\n\nThere is also a snap package, however, it is currently unmaintained.\nIt is installable in all the supported Linux distros. To\ninstall the latest stable version of solc:\nsudo snap install solc\n\nIf you want to help testing the latest development version of Solidity\nwith the most recent changes, please use the following:\nsudo snap install solc --edge\n\nNote\nThe solc snap uses strict confinement. This is the most secure mode for snap packages\nbut it comes with limitations, like accessing only the files in your /home and /media directories.\nFor more information, go to Demystifying Snap Confinement.\n\nmacOS Packages\nWe distribute the Solidity compiler through Homebrew\nas a build-from-source version. Pre-built bottles are\ncurrently not supported.\nbrew update\nbrew upgrade\nbrew tap ethereum/ethereum\nbrew install solidity\n\nTo install the most recent 0.4.x / 0.5.x version of Solidity you can also use brew install solidity@4\nand brew install solidity@5, respectively.\nIf you need a specific version of Solidity you can install a\nHomebrew formula directly from Github.\nView\nsolidity.rb commits on GitHub.\nCopy the commit hash of the version you want and check it out on your machine.\ngit clone https://github.com/ethereum/homebrew-ethereum.git\ncd homebrew-ethereum\ngit checkout <your-hash-goes-here>\n\nInstall it using brew:\nbrew unlink solidity\n# eg. Install 0.4.8\nbrew install solidity.rb\n\nStatic Binaries\nWe maintain a repository containing static builds of past and current compiler versions for all\nsupported platforms at solc-bin. This is also the location where you can find the nightly builds.\nThe repository is not only a quick and easy way for end users to get binaries ready to be used\nout-of-the-box but it is also meant to be friendly to third-party tools:\n\nThe content is mirrored to https://binaries.soliditylang.org where it can be easily downloaded over\nHTTPS without any authentication, rate limiting or the need to use git.\nContent is served with correct Content-Type headers and lenient CORS configuration so that it\ncan be directly loaded by tools running in the browser.\nBinaries do not require installation or unpacking (exception for older Windows builds\nbundled with necessary DLLs).\nWe strive for a high level of backward-compatibility. Files, once added, are not removed or moved\nwithout providing a symlink/redirect at the old location. They are also never modified\nin place and should always match the original checksum. The only exception would be broken or\nunusable files with the potential to cause more harm than good if left as is.\nFiles are served over both HTTP and HTTPS. As long as you obtain the file list in a secure way\n(via git, HTTPS, IPFS or just have it cached locally) and verify hashes of the binaries\nafter downloading them, you do not have to use HTTPS for the binaries themselves.\n\nThe same binaries are in most cases available on the Solidity release page on GitHub. The\ndifference is that we do not generally update old releases on the GitHub release page. This means\nthat we do not rename them if the naming convention changes and we do not add builds for platforms\nthat were not supported at the time of release. This only happens in solc-bin.\nThe solc-bin repository contains several top-level directories, each representing a single platform.\nEach one includes a list.json file listing the available binaries. For example in\nemscripten-wasm32/list.json you will find the following information about version 0.7.4:\n{\n \"path\": \"solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js\",\n \"version\": \"0.7.4\",\n \"build\": \"commit.3f05b770\",\n \"longVersion\": \"0.7.4+commit.3f05b770\",\n \"keccak256\": \"0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3\",\n \"sha256\": \"0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2\",\n \"urls\": [\n \"dweb:/ipfs/QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS\"\n ]\n}\n\nThis means that:\n\nYou can find the binary in the same directory under the name\nsolc-emscripten-wasm32-v0.7.4+commit.3f05b770.js.\nNote that the file might be a symlink, and you will need to resolve it yourself if you are not using\ngit to download it or your file system does not support symlinks.\nThe binary is also mirrored at https://binaries.soliditylang.org/emscripten-wasm32/solc-emscripten-wasm32-v0.7.4+commit.3f05b770.js.\nIn this case git is not necessary and symlinks are resolved transparently, either by serving a copy\nof the file or returning a HTTP redirect.\nThe file is also available on IPFS at QmTLs5MuLEWXQkths41HiACoXDiH8zxyqBHGFDRSzVE5CS.\nPlease, be aware that the order of items in the urls array is not predetermined or guaranteed and users should not rely on it.\nYou can verify the integrity of the binary by comparing its keccak256 hash to\n0x300330ecd127756b824aa13e843cb1f43c473cb22eaf3750d5fb9c99279af8c3. The hash can be computed\non the command-line using keccak256sum utility provided by sha3sum or keccak256() function\nfrom ethereumjs-util in JavaScript.\nYou can also verify the integrity of the binary by comparing its sha256 hash to\n0x2b55ed5fec4d9625b6c7b3ab1abd2b7fb7dd2a9c68543bf0323db2c7e2d55af2.\n\nWarning\nDue to the strong backwards compatibility requirement the repository contains some legacy elements\nbut you should avoid using them when writing new tools:\n\nUse emscripten-wasm32/ (with a fallback to emscripten-asmjs/) instead of bin/ if\nyou want the best performance. Until version 0.6.1 we only provided asm.js binaries.\nStarting with 0.6.2 we switched to WebAssembly builds with much better performance. We have\nrebuilt the older versions for wasm but the original asm.js files remain in bin/.\nThe new ones had to be placed in a separate directory to avoid name clashes.\nUse emscripten-asmjs/ and emscripten-wasm32/ instead of bin/ and wasm/ directories\nif you want to be sure whether you are downloading a wasm or an asm.js binary.\nUse list.json instead of list.js and list.txt. The JSON list format contains all\nthe information from the old ones and more.\nUse https://binaries.soliditylang.org instead of https://solc-bin.ethereum.org. To keep things\nsimple we moved almost everything related to the compiler under the new soliditylang.org\ndomain and this applies to solc-bin too. While the new domain is recommended, the old one\nis still fully supported and guaranteed to point at the same location.\n\nWarning\nThe binaries are also available at https://argotorg.github.io/solc-bin/ but this page\nstopped being updated just after the release of version 0.7.2, will not receive any new releases\nor nightly builds for any platform and does not serve the new directory structure, including\nnon-emscripten builds.\nIf you are using it, please switch to https://binaries.soliditylang.org, which is a drop-in\nreplacement. This allows us to make changes to the underlying hosting in a transparent way and\nminimize disruption. Unlike the argotorg.github.io domain, which we do not have any control\nover, binaries.soliditylang.org is guaranteed to work and maintain the same URL structure\nin the long-term.\n\nBuilding from Source\n\nPrerequisites - All Operating Systems\nThe following are dependencies for all builds of Solidity:\n\nSoftware\nNotes\n\nCMake (version 3.21.3+ on\nWindows, 3.13+ otherwise)\nCross-platform build file generator.\n\nBoost (version 1.77+ on\nWindows, 1.83+ otherwise)\nC++ libraries.\n\nGit\nCommand-line tool for retrieving source code.\n\nz3 (version 4.8.16+, Optional)\nFor use with SMT checker.\n\nNote\nSolidity versions prior to 0.5.10 can fail to correctly link against Boost versions 1.70+.\nA possible workaround is to temporarily rename <Boost install path>/lib/cmake/Boost-1.70.0\nprior to running the cmake command to configure Solidity.\nStarting from 0.5.10 linking against Boost 1.70+ should work without manual intervention.\n\nNote\nThe default build configuration requires a specific Z3 version (the latest one at the time the\ncode was last updated). Changes introduced between Z3 releases often result in slightly different\n(but still valid) results being returned. Our SMT tests do not account for these differences and\nwill likely fail with a different version than the one they were written for. This does not mean\nthat a build using a different version is faulty. If you pass -DSTRICT_Z3_VERSION=OFF option\nto CMake, you can build with any version that satisfies the requirement given in the table above.\nIf you do this, however, please remember to pass the --no-smt option to scripts/tests.sh\nto skip the SMT tests.\n\nNote\nBy default the build is performed in pedantic mode, which enables extra warnings and tells the\ncompiler to treat all warnings as errors.\nThis forces developers to fix warnings as they arise, so they do not accumulate “to be fixed later”.\nIf you are only interested in creating a release build and do not intend to modify the source code\nto deal with such warnings, you can pass -DPEDANTIC=OFF option to CMake to disable this mode.\nDoing this is not recommended for general use but may be necessary when using a toolchain we are\nnot testing with or trying to build an older version with newer tools.\nIf you encounter such warnings, please consider\nreporting them.\n\nMinimum Compiler Versions\nThe following C++ compilers and their minimum versions can build the Solidity codebase:\n\nGCC, version 13.3+\nClang, version 18.1.3+\nMSVC, version 2019+\n\nPrerequisites - macOS\nFor macOS builds, ensure that you have the latest version of\nXcode installed.\nThis contains the Clang C++ compiler, the\nXcode IDE and other Apple development\ntools that are required for building C++ applications on OS X.\nIf you are installing Xcode for the first time, or have just installed a new\nversion then you will need to agree to the license before you can do\ncommand-line builds:\nsudo xcodebuild -license accept\n\nOur OS X build script uses the Homebrew\npackage manager for installing external dependencies.\nHere’s how to uninstall Homebrew,\nif you ever want to start again from scratch.\n\nPrerequisites - Windows\nYou need to install the following dependencies for Windows builds of Solidity:\n\nSoftware\nNotes\n\nVisual Studio 2019 Build Tools\nC++ compiler\n\nVisual Studio 2019 (Optional)\nC++ compiler and dev environment.\n\nBoost (version 1.77+)\nC++ libraries.\n\nIf you already have one IDE and only need the compiler and libraries,\nyou could install Visual Studio 2019 Build Tools.\nVisual Studio 2019 provides both IDE and necessary compiler and libraries.\nSo if you have not got an IDE and prefer to develop Solidity, Visual Studio 2019\nmay be a choice for you to get everything setup easily.\nHere is the list of components that should be installed\nin Visual Studio 2019 Build Tools or Visual Studio 2019:\n\nVisual Studio C++ core features\nVC++ 2019 v141 toolset (x86,x64)\nWindows Universal CRT SDK\nWindows 8.1 SDK\nC++/CLI support\n\nWe have a helper script which you can use to install all required external dependencies:\nscripts\\install_deps.ps1\n\nThis will install boost and cmake to the deps subdirectory.\n\nClone the Repository\nTo clone the source code, execute the following command:\ngit clone --recursive https://github.com/argotorg/solidity.git\ncd solidity\n\nIf you want to help develop Solidity,\nyou should fork Solidity and add your personal fork as a second remote:\ngit remote add personal git@github.com:[username]/solidity.git\n\nNote\nThis method will result in a pre-release build leading to e.g. a flag\nbeing set in each bytecode produced by such a compiler.\nIf you want to re-build a released Solidity compiler, then\nplease use the source tarball on the GitHub release page:\nhttps://github.com/argotorg/solidity/releases/download/v0.X.Y/solidity_0.X.Y.tar.gz\n(not the “Source code” provided by GitHub).\n\nCommand-Line Build\nBe sure to install External Dependencies (see above) before build.\nSolidity project uses CMake to configure the build.\nYou might want to install ccache to speed up repeated builds.\nCMake will pick it up automatically.\nBuilding Solidity is quite similar on Linux, macOS and other Unices:\nmkdir build\ncd build\ncmake .. && make\n\nor even easier on Linux and macOS, you can run:\n#note: this will install binaries solc and soltest at usr/local/bin\n./scripts/build.sh\n\nWarning\nBSD builds should work, but are untested by the Solidity team.\n\nAnd for Windows:\nmkdir build\ncd build\ncmake -G \"Visual Studio 16 2019\" ..\n\nIn case you want to use the version of boost installed by scripts\\install_deps.ps1, you will\nadditionally need to pass -DBoost_ROOT=\"deps/boost\" -DBoost_INCLUDE_DIR=\"deps/boost/include\" and -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded\nas arguments to the call to cmake.\nThis should result in the creation of solidity.sln in that build directory.\nDouble-clicking on that file should result in Visual Studio firing up. We suggest building\nRelease configuration, but all others work.\nAlternatively, you can build for Windows on the command-line, like so:\ncmake --build . --config Release\n\nCMake Options\nIf you are interested what CMake options are available run cmake .. -LH.\n\nSMT Solvers\nSolidity can optionally use SMT solvers, namely z3, cvc5 and Eldarica,\nbut their presence is checked only at runtime, they are not needed for the build to succeed.\n\nNote\nThe emscripten builds require Z3 and will statically link against it instead.\n\nThe Version String in Detail\nThe Solidity version string contains four parts:\n\nthe version number\npre-release tag, usually set to develop.YYYY.MM.DD, pre.N or nightly.YYYY.MM.DD\ncommit in the format of commit.GITHASH\nplatform, which has an arbitrary number of items, containing details about the platform and compiler\n\nIf there are local modifications, the commit will be postfixed with .mod.\nThese parts are combined as required by SemVer, where the Solidity pre-release tag equals to the SemVer pre-release\nand the Solidity commit and platform combined make up the SemVer build metadata.\nExamples:\n\nrelease: 0.4.8+commit.60cc1668.Emscripten.clang\npre-release: 0.4.9-pre.3+commit.fb60450bc.Emscripten.clang\nnightly build: 0.4.9-nightly.2017.1.17+commit.6ecb4aa3.Emscripten.clang\n\nImportant Information About Versioning\nAfter a release is made, the patch version level is bumped, because we assume that only\npatch level changes follow. When changes are merged, the version should be bumped according\nto SemVer and the severity of the change. Finally, a release is always made with the version\nof the current build, but without the prerelease specifier.\nExample:\n\nThe 0.4.0 release is made.\nNightly builds and preerelases have a version of 0.4.1 from now on.\nNon-breaking changes are introduced –> no change in version.\nA breaking change is introduced –> version is bumped to 0.5.0.\nThe 0.5.0 release is made.\n\nThis behavior works well with the version pragma.","tokens":4872,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267498865,"hash":"2c75c0ba9de764a8f35275eab86fd757f674c810"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/7","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 7 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by jdkanani on Jan 9, 2018\n\n jdkanani\n\n Thanks for the post.\nSlightly more difficult scenario, how I can enforce correctness in case of state change in account/state based plasma chain?\n(block 0, state 0, [t1, t2.... ]) -> state 1 \n(block 1, state 1, [t1, t2.... ]) -> state 2\n\nLet’s say if one wants to challenge block 1, saying - t2 in block 1 in not valid as it should yield state 2' instead of state 2. How one can generate fraud proof?\n\n post by kladkogex on Jan 9, 2018\n\n kladkogex\n\n I have read the description several times, I am not sure though I understand how an exit transaction is verified by the parent blockchain …\n\nIs this correct to say, that to exit you need to have signatures of all owners of intemediate UTXOs … ? And all of these signatures will be verified during the exit? Correct?))\n\nIn this structure if I look at a particular UTXO, it may have two parents, so essentially if I go back N transactions in history for a particular UTXO, I will have 2^N2𝑁 ancestors … ? correct?) Would it mean that the size of the exit proof would grow exponentially as coins exchange hands?)) Or I am missing something ?))\n\n post by vbuterin on Jan 10, 2018\n\n vbuterin\n\n You do not need to provide a proof of the entire history of a UTXO in order to exit with that UTXO; you just need to prove that the UTXO exists and was included. It seems counterintuitive that you need to prove that little, but it works; it relies heavily on the fact that if any user sees an invalid UTXO get in, they need to exit within some timeframe, and make sure to not finalize transfers that were included after that invalid UTXO.\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n Load more posts below","tokens":3679,"squid":"ink-research","role":"Deep Scholar","at":1791267499036,"hash":"1062deb1b8abf15c11090471094d6429330f53e4"}
{"url":"https://forum.pyth.network/t/community-project-wheel-of-pyth/2268","domain":"forum.pyth.network","title":"COMMUNITY PROJECT: Wheel of Pyth - Ideas Bank - Pyth DAO","text":"COMMUNITY PROJECT: Wheel of Pyth \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Nov 2025\n\n 1 / 22\n\n Nov 2025\n\n Apr 6\n\n post by Derrp on Nov 20, 2025\n\n Derrp\n\n Community Project: Wheel of Pyth / Pyth of Fortune\n\nimage434×431 43.1 KB\n\nTotal Budget/ Timeline:\n\n$8,000 Budget to Execute\n3 Months Until Full Deployment to Mainnet\n\nProject Objectives:\n\nFind a new, inventive, fair, and random way to distribute prizes for Pyth Community Discord participation\n\nUse Pyth Entropy (and educate/reward Pyth Discord Participants in the process)\n\nProvide a new and exciting addition to the community: built by the community, to reward the community\n\nPromotion of Community and Pyth Entropy in action on social media (X/Reddit/Facebook/Instagram)\n\nActively teach and record coding sessions live in Pyth Discord to inspire our community to understand, and build real use cases for Pyth Entropy.\n\nGeneral Layout/Features:\nMain Page:\n● Single Main Interface Webpage, spins a prize wheel. Interacts with Base L2, and randomness achieved using Pyth Entropy v2.\nAdmin Page:\n● Second page (admin only) where Community Council can submit new prize information, approved WL wallet information (addresses and roles) for the upcoming month. Ability to preview Prize list, layout, and important spin metrics for the ongoing month.\n● Community Council is able to view/change/amend this list of approved wallets and roles at any time. Main Interface AND Upcoming Month Page. Upload .csv Spreadsheet data Columns: (Discord Name, EVM Wallet, Multiplier)\n● At the start of the new month 00:00 UTC, the Main Interface Webpage is updated with the information in the “Admin Only” page\n● Community Council can add/remove/change prize lists and amounts for the upcoming month. And Remove/Exclude WL wallets for the current month.\nUser “Spin Enabled” Requirements:\n● User has ETH on Base L2. Requires Gas to spin.\n● User has submitted EVM wallet in “community grants” channel in discord\n● User has Low Priest Role (or higher) in Discord\n● Community Council submits an Excel List (Discord Username, EVM address, Role) before the start of the new month\nCore Features:\nMain Page:\n● Shows Pyth Wheel containing prizes. (see Sample Below)\n● Shows a Table of Monthly Prizes available (Which have been won, which are left)\n● Shows User’s Current Weekly Spin Streak (after wallet connected)\n● Wallet Connection: Users connect their EVM (Same wallet they submit in Discord “Community Grants” Channel.\n● Requires users to have ETH on Base L2\n● Approved user may spin wheel X times per week (determined by role in Discord, set by Community Council)\n● Prizes distributed manually in Discord (Community Council keep a log of winners/prizes and verify genuineness/correctness)\n● Winning spin = sprites/animations/fanfare/audio “Post to X/Reddit/social media” link.\n● There is a monthly prize pool, with a set amount of each prize within the pool which can be won. Higher prize values have lower probabilities.\nWallet Integration for Metamask/Rabby/Phantom/ Popular EVM wallets.\nWeekly Spin Streak:\n● Discord Role for Wallet Determines How Many Spins Per Week\n● Get 1 extra spin per week if streak >0. Does not stack\n● Streak resets to zero at start of every Month\nTestnet Deployment Requirements:\n● Deploy on Sepolia Base Testnet 0x41c9e39574f40ad34c79f1c99b66a45efb830d4c\n● Testing progresses + Support\n● Approximately 1 month of testing on Sepolia\n● 500 Spins Minimum, Each Community Council Member can access Admin Page and change parameters. Change log for transparency\n● Prize Winners list is generated, publicly viewable, confirmed accurate.\n● 0.000015000000000001 ETH fee for Base Sepolia Entropy Calls\nMainnet Deployment Requirements:\n● Codebase is Owned/Administered by Pyth Network\n● Deploy on Base Mainnet 0x6e7d74fa7d5c90fef9f0512987605a6d546181bb\n● Website Hosting is paid for by Community Council Budget\n● 0.000005790089400001 ETH fee for Base Entropy Calls\nBudgets and Timelines:\n\n1-2 Months to build working prototype (until testnet launch)\n\nProgress Tranches: TBA\n\nLead Developers: 2 (Front End and Back End)\n\nLead Developers will be working directly with Community Council (Derrp) with respect to timelines and budget tranches.\n\nCommunity Council to fund website Hosting (Will not come from this project budget).\n\nArtwork:\n\nWheel Sample for Inspiration Only. Artwork shall contain Prize Labels and Pyth-related colours, symbols, mascots.\n\nDiscord Coding Sessions:\n\nLead Project Developers to host regular live Discord coding and testing sessions (Minimum 1 per week), record and archive these sessions for use in the future. This will increase transparency, increase community engagement, and ultimately become a truly “community coded” application.\n\nCode Repository:\n\nCode Base to be continuously updated in a central repository such as Github and be publicly auditable at any time.\n\nNext Steps:\nPlease Nominate yourself using the following format:\n\nDiscord Handle\nPyth Discord Role\nRole You Are Applying For\nRelevant Experience (projects etc.)\nGitHub/Collaborative Contributions\nAnything further you wish to add\n\nBy nominating yourself, you are acknowleding that you agree to working collaboratively with the project team (and Community Council) and will be required to participate in live, recorded, screen-sharing sessions. Community Feedback during these sessions may result in some minor changes to some elements.\nSuitable candidates will be chosen by the Community Council within 14 days. If there are insufficient nominations or no suitable candidates, this deadline may extend.\n\n 6\n\n 3\n\n read \n\n 5\n min\n\n post by Planck on Nov 20, 2025\n\n post by Samurai on Nov 20, 2025\n\n post by Derrp on Nov 20, 2025\n\n post by eukodal on Nov 21, 2025\n\n post by Derrp on Nov 21, 2025\n\n post by 0xiamjosh on Nov 21, 2025\n\n post by KemarTiti on Nov 22, 2025\n\n post by Brutal on Nov 23, 2025\n\n post by Pepito on Nov 23, 2025\n\n post by Quintzor on Nov 23, 2025\n\n post by Imgonnatakeapyth on Nov 24, 2025\n\n post by offmylawn on Nov 25, 2025\n\n post by MAYOR on Nov 25, 2025\n\n post by Chop on Nov 25, 2025\n\n post by scp on Nov 27, 2025\n\n post by TheDinarian on Nov 29, 2025\n\n post by Derrp on Dec 1, 2025\n\n post by eukodal on Dec 5, 2025\n\n post by Derrp on Dec 6, 2025\n\n Load more posts below","tokens":1569,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267499081,"hash":"5bc1e09cf661dd44fd5bfa0a243233a7ef9e4ee4"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/introduction-to-smart-contracts.html","domain":"docs.soliditylang.org","title":"Introduction to Smart Contracts — Solidity 0.8.31-develop documentation","text":"Introduction to Smart Contracts\n\n Edit on GitHub\n\nIntroduction to Smart Contracts\n\nA Simple Smart Contract\nLet us begin with a basic example that sets the value of a variable and exposes\nit for other contracts to access. It is fine if you do not understand\neverything right now, we will go into more details later.\n\nStorage Example\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity >=0.4.16 <0.9.0;\n\ncontract SimpleStorage {\n uint storedData;\n\n function set(uint x) public {\n storedData = x;\n }\n\n function get() public view returns (uint) {\n return storedData;\n }\n}\n\nThe first line tells you that the source code is licensed under the\nGPL version 3.0. Machine-readable license specifiers are important\nin a setting where publishing the source code is the default.\nThe next line specifies that the source code is written for\nSolidity version 0.4.16, or a newer version of the language up to, but not including version 0.9.0.\nThis is to ensure that the contract is not compilable with a new (breaking) compiler version, where it could behave differently.\nPragmas are common instructions for compilers about how to treat the\nsource code (e.g. pragma once).\nA contract in the sense of Solidity is a collection of code (its functions) and\ndata (its state) that resides at a specific address on the Ethereum\nblockchain. The line uint storedData; declares a state variable called storedData of\ntype uint (unsigned integer of 256 bits). You can think of it as a single slot\nin a database that you can query and alter by calling functions of the\ncode that manages the database. In this example, the contract defines the\nfunctions set and get that can be used to modify\nor retrieve the value of the variable.\nTo access a member (like a state variable) of the current contract, you do not typically add the this. prefix,\nyou just access it directly via its name.\nUnlike in some other languages, omitting it is not just a matter of style,\nit results in a completely different way to access the member, but more on this later.\nThis contract does not do much yet apart from (due to the infrastructure\nbuilt by Ethereum) allowing anyone to store a single number that is accessible by\nanyone in the world without a (feasible) way to prevent you from publishing\nthis number. Anyone could call set again with a different value\nand overwrite your number, but the number is still stored in the history\nof the blockchain. Later, you will see how you can impose access restrictions\nso that only you can alter the number.\n\nWarning\nBe careful with using Unicode text, as similar looking (or even identical) characters can\nhave different code points and as such are encoded as a different byte array.\n\nNote\nAll identifiers (contract names, function names and variable names) are restricted to\nthe ASCII character set. It is possible to store UTF-8 encoded data in string variables.\n\nSubcurrency Example\nThe following contract implements the simplest form of a\ncryptocurrency. The contract allows only its creator to create new coins (different issuance schemes are possible).\nAnyone can send coins to each other without a need for\nregistering with a username and password, all you need is an Ethereum keypair.\nopen in Remix\n// SPDX-License-Identifier: GPL-3.0\npragma solidity ^0.8.26;\n\n// This will only compile via IR\ncontract Coin {\n // The keyword \"public\" makes variables\n // accessible from other contracts\n address public minter;\n mapping(address => uint) public balances;\n\n // Events allow clients to react to specific\n // contract changes you declare\n event Sent(address from, address to, uint amount);\n\n // Constructor code is only run when the contract\n // is created\n constructor() {\n minter = msg.sender;\n }\n\n // Sends an amount of newly created coins to an address\n // Can only be called by the contract creator\n function mint(address receiver, uint amount) public {\n require(msg.sender == minter);\n balances[receiver] += amount;\n }\n\n // Errors allow you to provide information about\n // why an operation failed. They are returned\n // to the caller of the function.\n error InsufficientBalance(uint requested, uint available);\n\n // Sends an amount of existing coins\n // from any caller to an address\n function send(address receiver, uint amount) public {\n require(amount <= balances[msg.sender], InsufficientBalance(amount, balances[msg.sender]));\n balances[msg.sender] -= amount;\n balances[receiver] += amount;\n emit Sent(msg.sender, receiver, amount);\n }\n}\n\nThis contract introduces some new concepts, let us go through them one by one.\nThe line address public minter; declares a state variable of type address.\nThe address type is a 160-bit value that does not allow any arithmetic operations.\nIt is suitable for storing addresses of contracts, or a hash of the public half\nof a keypair belonging to externally-owned accounts.\nThe keyword public automatically generates a function that allows you to access the current value of the state\nvariable from outside of the contract. Without this keyword, other contracts have no way to access the variable.\nThe code of the function generated by the compiler is equivalent\nto the following (ignore external and view for now):\nopen in Remix\nfunction minter() external view returns (address) { return minter; }\n\nYou could add a function like the above yourself, but you would have a function and state variable with the same name.\nYou do not need to do this, the compiler figures it out for you.\nThe next line, mapping(address => uint) public balances; also\ncreates a public state variable, but it is a more complex datatype.\nThe mapping type maps addresses to unsigned integers.\nMappings can be seen as hash tables which are\nvirtually initialized such that every possible key exists from the start and is mapped to a\nvalue whose byte-representation is all zeros. However, it is neither possible to obtain a list of all keys of\na mapping, nor a list of all values. Record what you\nadded to the mapping, or use it in a context where this is not needed. Or\neven better, keep a list, or use a more suitable data type.\nThe getter function created by the public keyword\nis more complex in the case of a mapping. It looks like the\nfollowing:\nopen in Remix\nfunction balances(address account) external view returns (uint) {\n return balances[account];\n}\n\nYou can use this function to query the balance of a single account.\nThe line event Sent(address from, address to, uint amount); declares\nan “event”, which is emitted in the last line of the function\nsend. Ethereum clients such as web applications can\nlisten for these events emitted on the blockchain without much\ncost. As soon as it is emitted, the listener receives the\narguments from, to and amount, which makes it possible to track\ntransactions.\nTo listen for this event, you could use the following\nJavaScript code, which uses web3.js to create the Coin contract object,\nand any user interface calls the automatically generated balances function from above:\nCoin.Sent().watch({}, '', function(error, result) {\n if (!error) {\n console.log(\"Coin transfer: \" + result.args.amount +\n \" coins were sent from \" + result.args.from +\n \" to \" + result.args.to + \".\");\n console.log(\"Balances now:\\n\" +\n \"Sender: \" + Coin.balances.call(result.args.from) +\n \"Receiver: \" + Coin.balances.call(result.args.to));\n }\n})\n\nThe constructor is a special function that is executed during the creation of the contract and\ncannot be called afterwards. In this case, it permanently stores the address of the person creating the\ncontract. The msg variable (together with tx and block) is a\nspecial global variable that\ncontains properties which allow access to the blockchain. msg.sender is\nalways the address where the current (external) function call came from.\nThe functions that make up the contract, and that users and contracts can call are mint and send.\nThe mint function sends an amount of newly created coins to another address. The require function call defines conditions that reverts all changes if not met. In this\nexample, require(msg.sender == minter); ensures that only the creator of the contract can call\nmint. In general, the creator can mint as many tokens as they like, but at some point, this will\nlead to a phenomenon called “overflow”. Note that because of the default Checked arithmetic, the transaction would revert if the expression balances[receiver] += amount;\noverflows, i.e., when balances[receiver] + amount in arbitrary precision arithmetic is larger\nthan the maximum value of uint (2**256 - 1). This is also true for the statement\nbalances[receiver] += amount; in the function send.\nErrors allow you to provide more information to the caller about\nwhy a condition or operation failed. Errors are used together with the\nrevert statement. The revert statement unconditionally\naborts and reverts all changes, much like the require function.\nBoth approaches allow you to provide the name of an error and additional data which will be supplied to the caller\n(and eventually to the front-end application or block explorer) so that\na failure can more easily be debugged or reacted upon.\nThe send function can be used by anyone (who already\nhas some of these coins) to send coins to anyone else. If the sender does not have\nenough coins to send, the if condition evaluates to true. As a result, the revert will cause the operation to fail\nwhile providing the sender with error details using the InsufficientBalance error.\n\nNote\nIf you use\nthis contract to send coins to an address, you will not see anything when you\nlook at that address on a blockchain explorer, because the record that you sent\ncoins and the changed balances are only stored in the data storage of this\nparticular coin contract. By using events, you can create\na “blockchain explorer” that tracks transactions and balances of your new coin,\nbut you have to inspect the coin contract address and not the addresses of the\ncoin owners.\n\nBlockchain Basics\nBlockchains as a concept are not too hard to understand for programmers. The reason is that\nmost of the complications (mining, hashing,\nelliptic-curve cryptography,\npeer-to-peer networks, etc.)\nare just there to provide a certain set of features and promises for the platform. Once you accept these\nfeatures as given, you do not have to worry about the underlying technology - or do you have\nto know how Amazon’s AWS works internally in order to use it?\n\nTransactions\nA blockchain is a globally shared, transactional database.\nThis means that everyone can read entries in the database just by participating in the network.\nIf you want to change something in the database, you have to create a so-called transaction\nwhich has to be accepted by all others.\nThe word transaction implies that the change you want to make (assume you want to change\ntwo values at the same time) is either not done at all or completely applied. Furthermore,\nwhile your transaction is being applied to the database, no other transaction can alter it.\nAs an example, imagine a table that lists the balances of all accounts in an\nelectronic currency. If a transfer from one account to another is requested,\nthe transactional nature of the database ensures that if the amount is\nsubtracted from one account, it is always added to the other account. If due\nto whatever reason, adding the amount to the target account is not possible,\nthe source account is also not modified.\nFurthermore, a transaction is always cryptographically signed by the sender (creator).\nThis makes it straightforward to guard access to specific modifications of the\ndatabase. In the example of the electronic currency, a simple check ensures that\nonly the person holding the keys to the account can transfer some compensation, e.g. Ether, from it.\n\nBlocks\nOne major obstacle to overcome is what (in Bitcoin terms) is called a “double-spend attack”:\nWhat happens if two transactions exist in the network that both want to empty an account?\nOnly one of the transactions can be valid, typically the one that is accepted first.\nThe problem is that “first” is not an objective term in a peer-to-peer network.\nThe abstract answer to this is that you do not have to care. A globally accepted order of the transactions\nwill be selected for you, solving the conflict. The transactions will be bundled into what is called a “block”\nand then they will be executed and distributed among all participating nodes.\nIf two transactions contradict each other, the one that ends up being second will\nbe rejected and not become part of the block.\nThese blocks form a linear sequence in time, and that is where the word “blockchain” derives from.\nBlocks are added to the chain at regular intervals, although these intervals may be subject to change in the future.\nFor the most up-to-date information, it is recommended to monitor the network, for example, on Etherscan.\nAs part of the “order selection mechanism”, which is called attestation, it may happen that\nblocks are reverted from time to time, but only at the “tip” of the chain. The more\nblocks are added on top of a particular block, the less likely this block will be reverted. So it might be that your transactions\nare reverted and even removed from the blockchain, but the longer you wait, the less\nlikely it will be.\n\nNote\nTransactions are not guaranteed to be included in the next block or any specific future block,\nsince it is not up to the submitter of a transaction, but up to the miners to determine in which block the transaction is included.\nIf you want to schedule future calls of your contract, you can use\na smart contract automation tool or an oracle service.\n\nThe Ethereum Virtual Machine\n\nOverview\nThe Ethereum Virtual Machine or EVM is the runtime environment\nfor smart contracts in Ethereum. It is not only sandboxed but\nactually completely isolated, which means that code running\ninside the EVM has no access to network, filesystem or other processes.\nSmart contracts even have limited access to other smart contracts.\n\nAccounts\nThere are two kinds of accounts in Ethereum which share the same\naddress space: Externally-owned accounts that are controlled by\npublic-private key pairs (i.e. humans) and contract accounts which are\ncontrolled by the code stored together with the account.\nThe address of an externally-owned account is determined from\nthe public key while the address of a contract is\ndetermined at the time the contract is created\n(it is derived from the creator address and the number\nof transactions sent from that address, the so-called “nonce”).\nRegardless of whether or not the account stores code, the two types are\ntreated equally by the EVM.\nEvery account has a persistent key-value store mapping 256-bit words to 256-bit\nwords called storage.\nFurthermore, every account has a balance in\nEther (in “Wei” to be exact, 1 ether is 10**18 wei) which can be modified by sending transactions that\ninclude Ether.\n\nTransactions\nA transaction is a message that is sent from one account to another\naccount (which might be the same or empty, see below).\nIt can include binary data (which is called “payload”) and Ether.\nIf the target account contains code, that code is executed and\nthe payload is provided as input data.\nIf the target account is not set (the transaction does not have\na recipient or the recipient is set to null), the transaction\ncreates a new contract.\nAs already mentioned, the address of that contract is not\nthe zero address but an address derived from the sender and\nits number of transactions sent (the “nonce”). The payload\nof such a contract creation transaction is taken to be\nEVM bytecode and executed. The output data of this execution is\npermanently stored as the code of the contract.\nThis means that in order to create a contract, you do not\nsend the actual code of the contract, but in fact code that\nreturns that code when executed.\n\nNote\nWhile a contract is being created, its code is still empty.\nBecause of that, you should not call back into the\ncontract under construction until its constructor has\nfinished executing.\n\nGas\nUpon creation, each transaction is charged with a certain amount of gas\nthat has to be paid for by the originator of the transaction (tx.origin).\nWhile the EVM executes the\ntransaction, the gas is gradually depleted according to specific rules.\nIf the gas is used up at any point (i.e. it would be negative),\nan out-of-gas exception is triggered, which ends execution and reverts all modifications\nmade to the state in the current call frame.\nThis mechanism incentivizes economical use of EVM execution time\nand also compensates EVM executors (i.e. miners / stakers) for their work.\nSince each block has a maximum amount of gas, it also limits the amount\nof work needed to validate a block.\nThe gas price is a value set by the originator of the transaction, who\nhas to pay gas_price * gas up front to the EVM executor.\nIf some gas is left after execution, it is refunded to the transaction originator.\nIn case of an exception that reverts changes, already used up gas is not refunded.\nSince EVM executors can choose to include a transaction or not,\ntransaction senders cannot abuse the system by setting a low gas price.\n\nStorage, Transient Storage, Memory and the Stack\nThe Ethereum Virtual Machine has different areas where it can store data with the most\nprominent being storage, transient storage, memory and the stack.\nEach account has a data area called storage, which is persistent between function calls\nand transactions.\nStorage is a key-value store that maps 256-bit words to 256-bit words.\nIt is not possible to enumerate storage from within a contract, it is\ncomparatively costly to read, and even more to initialise and modify storage. Because of this cost,\nyou should minimize what you store in persistent storage to what the contract needs to run.\nStore data like derived calculations, caching, and aggregates outside of the contract.\nA contract can neither read nor write to any storage apart from its own.\nSimilar to storage, there is another data area called transient storage,\nwhere the main difference is that it is reset at the end of each transaction.\nThe values stored in this data location persist only across function calls originating\nfrom the first call of the transaction.\nWhen the transaction ends, the transient storage is reset and the values stored there\nbecome unavailable to calls in subsequent transactions.\nDespite this, the cost of reading and writing to transient storage is significantly lower than for storage.\nThe third data area is called memory, of which a contract obtains\na freshly cleared instance for each message call. Memory is linear and can be\naddressed at byte level, but reads are limited to a width of 256 bits, while writes\ncan be either 8 bits or 256 bits wide. Memory is expanded by a word (256-bit), when\naccessing (either reading or writing) a previously untouched memory word (i.e. any offset\nwithin a word). At the time of expansion, the cost in gas must be paid. Memory is more\ncostly the larger it grows (it scales quadratically).\nThe EVM is not a register machine but a stack machine, so all\ncomputations are performed on a data area called the stack. It has a maximum size of\n1024 elements and contains words of 256 bits. Access to the stack is\nlimited to the top end in the following way:\nIt is possible to copy one of\nthe topmost 16 elements to the top of the stack or swap the\ntopmost element with one of the 16 elements below it.\nAll other operations take the topmost two (or one, or more, depending on\nthe operation) elements from the stack and push the result onto the stack.\nOf course it is possible to move stack elements to storage or memory\nin order to get deeper access to the stack,\nbut it is not possible to just access arbitrary elements deeper in the stack\nwithout first removing the top of the stack.\n\nCalldata, Returndata and Code\nThere are also other data areas which are not as apparent as those discussed previously.\nHowever, they are routinely used during the execution of smart contract transactions.\nThe calldata region is the data sent to a transaction as part of a smart contract transaction.\nFor example, when creating a contract, calldata would be the constructor code of the new contract.\nThe parameters of external functions are always initially stored in calldata in an ABI-encoded form\nand only then decoded into the location specified in their declaration.\nIf declared as memory, the compiler will eagerly decode them into memory at the beginning of the function,\nwhile marking them as calldata means that this will be done lazily, only when accessed.\nValue types and storage pointers are decoded directly onto the stack.\nThe returndata is the way a smart contract can return a value after a call.\nIn general, external Solidity functions use the return keyword to ABI-encode values into the returndata area.\nThe code is the region where the EVM instructions of a smart contract are stored.\nCode is the bytes read, interpreted, and executed by the EVM during smart contract execution.\nInstruction data stored in the code is persistent as part of a contract account state field.\nImmutable and constant variables are stored in the code region.\nAll references to immutables are replaced with the values assigned to them.\nA similar process is performed for constants which have their expressions inlined\nin the places where they are referenced in the smart contract code.\n\nInstruction Set\nThe instruction set of the EVM is kept minimal in order to avoid\nincorrect or inconsistent implementations which could cause consensus problems.\nAll instructions operate on the basic data type, 256-bit words or on slices of memory\n(or other byte arrays).\nThe usual arithmetic, bit, logical and comparison operations are present.\nConditional and unconditional jumps are possible. Furthermore,\ncontracts can access relevant properties of the current block\nlike its number and timestamp.\nFor a complete list, please see the list of opcodes as part of the inline\nassembly documentation.\n\nMessage Calls\nContracts can call other contracts or send Ether to non-contract\naccounts by the means of message calls. Message calls are similar\nto transactions, in that they have a source, a target, data payload,\nEther, gas and return data. In fact, every transaction consists of\na top-level message call which in turn can create further message calls.\nA contract can decide how much of its remaining gas should be sent\nwith the inner message call and how much it wants to retain.\nIf an out-of-gas exception happens in the inner call (or any\nother exception), this will be signaled by an error value put onto the stack.\nIn this case, only the gas sent together with the call is used up.\nIn Solidity, the calling contract causes a manual exception by default in\nsuch situations, so that exceptions “bubble up” the call stack.\nAs already said, the called contract (which can be the same as the caller)\nwill receive a freshly cleared instance of memory and has access to the\ncall payload - which will be provided in a separate area called the calldata.\nAfter it has finished execution, it can return data which will be stored at\na location in the caller’s memory preallocated by the caller.\nAll such calls are fully synchronous.\nCalls are limited to a depth of 1024, which means that for more complex\noperations, loops should be preferred over recursive calls. Furthermore,\nonly 63/64th of the gas can be forwarded in a message call, which causes a\ndepth limit of a little less than 1000 in practice.\n\nDelegatecall and Libraries\nThere exists a special variant of a message call, named delegatecall\nwhich is identical to a message call apart from the fact that\nthe code at the target address is executed in the context (i.e. at the address) of the calling\ncontract and msg.sender and msg.value do not change their values.\nThis means that a contract can dynamically load code from a different\naddress at runtime. Storage, current address and balance still\nrefer to the calling contract, only the code is taken from the called address.\nThis makes it possible to implement the “library” feature in Solidity:\nReusable library code that can be applied to a contract’s storage, e.g. in\norder to implement a complex data structure.\n\nLogs\nIt is possible to store data in a specially indexed data structure\nthat maps all the way up to the block level. This feature called logs\nis used by Solidity in order to implement events.\nContracts cannot access log data after it has been created, but they\ncan be efficiently accessed from outside the blockchain.\nSince some part of the log data is stored in bloom filters, it is\npossible to search for this data in an efficient and cryptographically\nsecure way, so network peers that do not download the whole blockchain\n(so-called “light clients”) can still find these logs.\n\nCreate\nContracts can even create other contracts using a special opcode (i.e.\nthey do not simply call the zero address as a transaction would). The only difference between\nthese create calls and normal message calls is that the payload data is\nexecuted and the result stored as code and the caller / creator\nreceives the address of the new contract on the stack.\n\nDeactivate and Self-destruct\nThe only way to remove code from the blockchain is when a contract at that\naddress performs the selfdestruct operation. The remaining Ether stored\nat that address is sent to a designated target and then the storage and code\nis removed from the state. Removing the contract in theory sounds like a good\nidea, but it is potentially dangerous, as if someone sends Ether to removed\ncontracts, the Ether is forever lost.\n\nWarning\nFrom EVM >= Cancun onwards, selfdestruct will only send all Ether in the account to the given recipient and not destroy the contract.\nHowever, when selfdestruct is called in the same transaction that creates the contract calling it,\nthe behaviour of selfdestruct before Cancun hardfork (i.e., EVM <= Shanghai) is preserved and will destroy the current contract,\ndeleting any data, including storage keys, code and the account itself.\nSee EIP-6780 for more details.\nThe new behaviour is the result of a network-wide change that affects all contracts present on\nthe Ethereum mainnet and testnets.\nIt is important to note that this change is dependent on the EVM version of the chain on which\nthe contract is deployed.\nThe --evm-version setting used when compiling the contract has no bearing on it.\nAlso, note that the selfdestruct opcode has been deprecated in Solidity version 0.8.18,\nas recommended by EIP-6049.\nThe deprecation is still in effect and the compiler will still emit warnings on its use.\nAny use in newly deployed contracts is strongly discouraged even if the new behavior is taken into account.\nFuture changes to the EVM might further reduce the functionality of the opcode.\n\nWarning\nEven if a contract is removed by selfdestruct, it is still part of the\nhistory of the blockchain and probably retained by most Ethereum nodes.\nSo using selfdestruct is not the same as deleting data from a hard disk.\n\nNote\nEven if a contract’s code does not contain a call to selfdestruct,\nit can still perform that operation using delegatecall or callcode.\n\nIf you want to deactivate your contracts, you should instead disable them\nby changing some internal state which causes all functions to revert. This\nmakes it impossible to use the contract, as it returns Ether immediately.\n\nPrecompiled Contracts\nThere is a small set of contract addresses that are special:\nThe address range between 1 and (including) 0x0a contains\n“precompiled contracts” that can be called as any other contract\nbut their behavior (and their gas consumption) is not defined\nby EVM code stored at that address (they do not contain code)\nbut instead is implemented in the EVM execution environment itself.\nDifferent EVM-compatible chains might use a different set of\nprecompiled contracts. It might also be possible that new\nprecompiled contracts are added to the Ethereum main chain in the future,\nbut you can reasonably expect them to always be in the range between\n1 and 0xffff (inclusive).","tokens":7019,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267510925,"hash":"8af216b0af4692e8fc454d9e4410da94ae9fc31d"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/9","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 9 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by vbuterin on Jan 10, 2018\n\n vbuterin\n\n kladkogex\n\n You do not need to provide a proof of the entire history of a UTXO in order to exit with that UTXO; you just need to prove that the UTXO exists and was included. It seems counterintuitive that you need to prove that little, but it works; it relies heavily on the fact that if any user sees an invalid UTXO get in, they need to exit within some timeframe, and make sure to not finalize transfers that were included after that invalid UTXO.\n\n post by kladkogex on Jan 10, 2018\n\n kladkogex\n\n Vitalik - thank you - this clarifies things for many people!\nLet me know if the following example is correct:\n\nAlice moves 2 ETH into a Plasma chain\n\nAlice pays 1 ETH to Bob which leaves an open UTXO for 1 ETH\n\nAlice tries to exit the chain with the original 2 ETH UTXO\n\nBob has 7 days to notice the fraud.\n\nBob submits a proof of a later transaction that spent the 2 ETH UTXO.\n\nAlice’s transaction is cancelled.\n\nAre steps 1-6 correct? Is Alice penalized in any way, or her transaction is simply cancelled?\nThe question is what is the incentive for Bob to monitor the chain and submit a fraud proof? If Alice is successful, why should Bob care ? He still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain ?) in fact they could agree with Alice to split the profit, could they ?)\nAnother question is micropayments. If Alice paid 10 cent to 1000 people, then for each of them submitting a fraud proof to the parent chain may not be economically viable. If I need to pay $1 to make a fraud proof call, it may be better for me to forgo 10 cents …?\nAnd yet another question is “cloaking”\nIf transactions on the Plasma chain are cheap (they presumably will be ), then Alice can create 1000 sybil identities, so and pass the UTXO 1000 times through these identities before it is paid to Bob. Then, it seems that it will not be clear to Bob what to monitor, he will have dig 1000 transactions back in history and follow every branch of the binary tree to find Alice and monitor her.\n\n post by ldct on Jan 11, 2018\n\n ldct\n\n For step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\n post by denett on Jan 11, 2018\n\n denett\n\n kladkogex\n\n I think everybody who has coins on the plasma chain should watch the Plasma chain and should check all exits for validity. Eventually these invalid exits could drain the whole plasma contract and you can no longer withdraw your coins. The challengeExit method requires a confirmSig, I assume this signature is broadcast to all plasma watchers, so everybody can challenge all invalid exits.\nI think the transaction fee of the challenge is indeed a problem. Why not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\nYou could probably solve this by requiring a exit deposit in ether (larger than the fraud proof transaction fee). This deposit is returned together with your coins or is given to the person who proofs your exit is invalid.\nYou should even check all blocks for validity, because otherwise an evil owner could create an invalid block and then withdraw all funds from the plasma contract. In case of an invalid block, you should exits as fast as possible. If you notice the invalid block within 7 days and your funds were already in the blockchain before the invalid block, you will be able the exit before the evil owner.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n denett\n\n I agree that there could be a potential race condition with deposits, especially a problem when the transaction queue on the parent chain is very long. Alice has not checked (possible invalid) plasma blocks that arrive after she sends her deposit, while these blocks are could be included in the plasma chain before her deposit block.\nI don’t know if I understand your use of the -1 as the weight instead of the block number, wouldn’t that allow Alice to withdraw straight without a waiting period? Then she could spend her coins on the plasma chain and withdraw as well before anybody could challenge her. Maybe her waiting period should be a little shorter (a day?) to make sure she will always be able to withdraw safely. So something like: weight = blknum-X where X is the number of blocks in a day.\nAn other problem could be a double spend on the parent chain. If Alice deposits on the plasma chain and immediately sends the coins to Bob on the Plasma chain, but also double spends her deposit ether on the parent chain by sending it to Carol.\nIf the parent chain reorganizes, the finalized chain could end up with both the transactions to Bob and Carol, but without the deposit.\nSo maybe deposited funds should only be spendable on the plasma chain after the deposit block is finalized on the parent chain.\n\n post by vbuterin on Jan 13, 2018\n\n vbuterin\n\n kz\n\nThe signature is not broadcast to all plasma watchers, because that would allow any sender to hold up the system by not broadcasting their signature. Rather, if you receive a UTXO, then you need to show the confirm sig for the UTXO at the time that you spend the UTXO. Slightly different mechanism, but same effect.\n\nWhy not wait for somebody else to do this challenge and safe on transaction fees (Tragedy of the commons)?\n\nIf we want to, we can require participants to submit an additional deposit upon joining the system, and give this deposit as a reward to those who challenge.\n\nYou should even check all blocks for validity\n\nExactly correct. And if you notice even one invalid block get accepted, you exit immediately (or at least within 7 days).\n\nIf all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\nThis is indeed the fundamental flaw in all channel systems, raiden and lightning included, and is the reason why the scalability of this system can’t go too far above the scalability of the main chain. 2-3 orders of magnitude probably but not that much more.\n\nThere is a potential race condition between:\n\nYou’re right. One simple way of fixing this is to require a minimum waiting period between consecutive submitted blocks, so if you want your deposit would be safe you would submit yours right after the plasma chain submitted a new block, so that it would with quite high probability get included on time.\n\n post by denett on Jan 13, 2018\n\n denett\n\nSo if Alice sends plasma coins to Bob, at first only Bob is able to challenge her exit. Only after Bob spends his coins the confirmSig is publicly known and everybody can do the challenge. If Bob keeps the plasma coins, but fails to challenge Alice’s exit, I assume he is punished and cannot spend the plasma coins anymore.\n\n post by kz on Jan 13, 2018\n\n kz\n\nI’ve had the same idea, but it would be great to have a solution that doesn’t have additional assumptions (that there is a plasma block speed limit) and works.\nThe speed by which plasma chain operator produces blocks can be manipulated, so that creates another potential attack vector.\n\nAh yes, sorry. That could be solved by adding additional priority queue (ordered by ETH block number) that delays exits of just deposited UTXOs for specific safety time delay approximated in main block count. That would require propagating main block number through plasma UTXO. After enough time has elapsed (e.g. 3.5 days), they are added to normal exit queue with weight -1. That gives enough time to report double spend fraud.\nI think that ETH main block number or time stamp will need to be stored in priority queue anyway:\n(Plasma block number, txindex, outindex, **mainBlockNumber**)\n… since otherwise one is trusting plasma chain operator block time stamps to make sure e.g. 7 days have passed.\nI’m not sure does the proposed solution have some additional flaws .\n\n@vbuterin Thnx for your time \nI wonder could this be also gamed. Let’s assume that there is a minimal waiting period, but if that minimal period elapses, one is again open to that race condition since one can’t guarantee when will next plasma block be produced That could create problems in scenarios where plasma block production isn’t predictable.\n\n post by kz on Jan 13, 2018\n\n kz\n\nOooooh, nice catch. I’ve just realized that the plasma chain would probably also need to be nondeterministic until blocks can be finalized.\nHow would one determine the correct winning plasma chain tip since there could be multiple plasma chains depending on multiple ETH chain branches?\n\n post by kz on Jan 13, 2018\n\n kz\n\n I’m just trying to wrap my head around this.\nDoes entering plasma chain requires validating entire plasma chain history?\nIt seems to me that otherwise one risks entering insolvent plasma chain.\nIf so, how could some system with huge state (e.g. omise go) be built on top of a plasma chain?\n\n post by denett on Jan 14, 2018\n\n denett\n\nAt the time of the startExit call the contract can calculate how many blocks have passed in the 24 hours before the deposit and use that as X for this exit.\nI assume the timing of the 7 and 14 days is based on the block times on the parent chain and not on the block time of the plasma chain (if there is any).\nDrawback of this extra 24 hours is that everybody has to watch the plasma chain at least every 6 days instead of 7.\nTherefore I like @vbuterin solution better to have a minimal spacing between blocks that is enforced in the contract, although this does not work if the transaction queue on the parent chain is long and unpredictable. In that case you should not deposit all your ether at once but do it in batches, to minimize the risk.\nAnother solution is to have the operator deposit a certain amount of ether that has a longer waiting period. That would also incentivize the operator to challenge all invalid exits, because the operators funds are the first on the line.\n\n post by denett on Jan 14, 2018\n\n denett\n\nPersonally I like the exit deposit better, because this would make it possible for users to use the plasma chain without ever having to touch the (more expensive) parent chain.\n\n post by denett on Jan 15, 2018\n\n denett\n\nHow does this passive loop work? Is it a function everybody can call that processes all exits which are due.\n\n Load more posts below","tokens":3490,"squid":"ink-research","role":"Deep Scholar","at":1791267511017,"hash":"fb69982d8cee47d017465918b78ba0e831ad51ff"}
{"url":"https://forum.pyth.network/t/op-pip-implement-pythwheel-burn-registry-100-pyth-permanent-burn-per-spin-community-deflation-mechanism/2555/1","domain":"forum.pyth.network","title":"[OP-PIP] Implement PythWheel Burn Registry: 100 PYTH Permanent Burn per Spin Community Deflation Mechanism - Ideas Bank - Pyth DAO","text":"[OP-PIP] Implement PythWheel Burn Registry: 100 PYTH Permanent Burn per Spin Community Deflation Mechanism \n\n Ideas Bank\n\n operational-pip\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n May 19\n\n 1 / 18\n\n May 19\n\n Jun 25\n\n post by SkyZ on May 19\n\n SkyZ\n\n I propose integrating a permanent, transparent Burn Registry into the existing PythWheel (pythwheel.com).\nEvery spin performed by a Pythian will burn exactly 100 PYTH tokens from circulation. Spins are awarded based on community participation: joining the Pyth Network, earning Discord/community roles, and advancing through higher-tier roles grants more spins (higher roles = more spins = greater deflationary impact).\nThis creates a gamified, merit-based deflationary flywheel that directly ties active community engagement to PYTH token scarcity.\n*Motivation\nPythWheel is already a successful community engagement tool powered by Pyth Entropy — provably fair, on-chain randomness that gives active Discord members weekly opportunities to win PYTH prizes, NFTs (PythiansNFTs), and other rewards.\nIt has proven highly effective at driving participation. However, the current model is purely inflationary from the token perspective (prizes are distributed without removing supply).\nWe can evolve PythWheel into a true deflationary engine by adding a burn on every spin.\nThis:\n\nRewards the most active and highest-role Pythians (the ones who contribute the most to the community).\n\nCreates visible, on-chain deflation that the entire ecosystem can track.\n\nStrengthens PYTH tokenomics without affecting existing staking, governance, or revenue mechanisms.\n\nTurns community fun into real, permanent value accrual for all PYTH holders.\n\nProposed Specification\n\nBurn Mechanics\n\nEvery spin on PythWheel burns exactly 100 PYTH permanently.\n\nBurns are executed on-chain (via smart contract) and are irreversible.\n\nThe burn happens at the moment the spin is initiated\n\nRole-Based Spin Allocation (the “higher roles = more spins” system)\n\nBase: New Pythians (joined Discord + basic verification) → 1 spin per week/month.\n\nMid-tier roles (active contributors, Pythians with verified activity like High Priest etc) → 2–3× spins.\n\nHigh-tier roles (Chirons, Aristophanes, Venus de Milo, etc., or future advanced contributor roles) → 4–6× spins.\n\nSpin allocation resets periodically (weekly or monthly) to keep it fair and ongoing.\n\nBurn Registry Dashboard\n\nPythWheel showing live total PYTH burned 1,050,500 PYTH:\n\nMonthly burn history with progress bars:\n\nMay 26 → 360,500 PYTH\n\nApr 26 → 464,600 PYTH\n\nMar 26 → 225,400 PYTH\n\nClear labeling: “100 PYTH PER SPIN · PERMANENT · DEFLATIONARY”\n\nTechnical Integration\n\nLeverage existing Pyth Entropy for spin randomness (already live).\n\nAdd simple burn logic to the PythWheel smart contract(s).\n\nMinimal UI/UX changes — just add the Burn Registry section and spin-cost confirmation.\n\nNo impact on current prize distribution\n\nBenefits\n\nDeflationary pressure on PYTH supply directly proportional to community activity.\n\nIncentivizes role progression and deeper community involvement.\n\nMarketing & virality — the live Burn Registry becomes a trophy wall that Pythians love to share.\n\nAligns perfectly with Pyth’s ethos of transparency, decentralization, and community ownership.\n\nComplements (does not replace) existing tokenomics, staking rewards, and revenue mechanisms\n\nDerrp said talk is cheap propopsals are the way so i did it \n\n Community Council Term 2: Six-Month Mid-Term Report\n\n 5\n\n 4\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by theretardedadrian on May 19\n\n theretardedadrian\n\n This is a great proposal skyz.\nIt reduces the amount of pyth in circulation which encourages rarity, thereby leading to long-term stability.\n\n post by Derrp on May 19\n\n Derrp\n\n Me and my big mouth!\nLooks like an interesting proposal, however, there would need to be some guardrails in place.\n\nBurning 100 PYTH at a time would involve quite a lot of transactions, considering the wheel is currently being spun over 5,000 times per month. Perhaps we can use the end of month metrics and submit a single transaction?\nWe should also include a provision that a maximum of 50% of the total reserve tokens in the account can be burned at once (we cannot burn more than we have, and setting an upper-bound limit may be useful). This also gives the Community Council the flexibility to increase the amount of PythWheel monthly spins dynamically, without affecting the maximum limits of DAO funds.\nWe should set a date to review the current parameters (say, a vote to approve it’s continuation or not) every 12 months\nWe should include a provision to update/change the percentage of monthly burn limit subject to a proposal (cannot be changed within a frequency of less than 6 months from a previous change)\nThe Community Council will advise the Pythian Council as to the burn amount required, and verified with on-chain metrics. For example, the monthly amount of successful spin interactions with contract 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3 on Monad. If the deployed chain of PythWheel changes at any time, the Community Council will make these changes known to the DAO and the Pythian Council with a full update.\nThat the community-built dApp “PythWheel” code be available to be audited by the Pyth Team/the DAO.\nThat previous month burns be included retrospectively: back to the launch of PythWheel itself\n\nJust a few items for thought, and some security measures\n\n post by peter on May 20\n\n peter\n\n it’s good idea to impletment Pythwheel burn registry..and sound interesting..\n\n post by Artistarjay18 on May 20\n\n Artistarjay18\n\n Beautiful proposal right there… I honestly love what I am seeing. Here are my honestly takes and suggestions.\n- Total Spins and Pyth to be burnt for the a duration(monthly or weekly) should be displayed on the website( in real time) as well as the total Pyth burnt all time.\n- A governance Vote for the continuation of the Pyth token burn program tied to the pythwheel spin should be implemented every 6months( To measure community interest and involvement)\n- Burn should happen In 4 weeks format( not 30 or 31days monthly format) So burn can easily follow the Pythwheel week refresh cycle (Monday 12am UTC). And Come with a tag like “PYTH BURN CYCLE”\nThis is just my brain braining nothing weird.\n\n post by SkyZ on May 20\n\n SkyZ\n\n Derrp\n\n Burning 100 PYTH at a time would involve quite a lot of transactions, considering the wheel is currently being spun over 5,000 times per month. Perhaps we can use the end of month metrics and submit a single transaction?\nAgree 100%\nUI showing stats of the burn that will happen (end of every 4th epoch or so) for the excitement . Preety much as it runs right now with icon but with fresh updated data every X time .. schould be ahort its Pyth after all​\nWe should also include a provision that a maximum of 50% of the total reserve tokens in the account can be burned at once (we cannot burn more than we have, and setting an upper-bound limit may be useful). This also gives the Community Council the flexibility to increase the amount of PythWheel monthly spins dynamically, without affecting the maximum limits of DAO funds.\nAgree 50 sound good and the flexibility is good point\nWe should set a date to review the current parameters (say, a vote to approve it’s continuation or not) every 12 months\n 6 or 12 m yes\nWe should include a provision to update/change the percentage of monthly burn limit subject to a proposal (cannot be changed within a frequency of less than 6 months from a previous change) \nThe Community Council will advise the Pythian Council as to the burn amount required, and verified with on-chain metrics. For example, the monthly amount of successful spin interactions with contract 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3 on Monad. If the deployed chain of PythWheel changes at any time, the Community Council will make these changes known to the DAO and the Pythian Council with a full update.\nThat the community-built dApp “PythWheel” code be available to be audited by the Pyth Team/the DAO.\nThat previous month burns be included retrospectively: back to the launch of PythWheel itself\nLob your brain sir\n\n post by KemarTiti on May 20\n\n KemarTiti\n\n gm @SkyZ\n1st thanks a ton for the idea/post!\nI only have 2 points for now:\n\nFunding Source Clarity\n\nThe proposal doesn’t specify where the 100 PYTH per spin actually comes from. This is fundamental:\n• Is it a user fee (spinners pay 100 PYTH)?\n• Does it come from the existing PythWheel prize pool?\n• Does it require a new Community Council budget line item?\n• Or is there a separate “burn fund” being proposed?\nEach of these has very different implications for incentives, sustainability, and budget planning. Would be good to clarify.\n\nForum Process\n\nNew ideas (like this one I believe) should typically start in the Ideas Bank for initial discussion and feedback (usually 1-2 weeks) - literally what is happening here. This gives the community time to poke holes, suggest improvements, and build consensus before formalizing as a PIP.\nOnce an idea has been refined through that process, it can be submitted as an Operational PIP. And for an OP-PIP to officially go to vote, it requires a vote triggered on Realms (with on-chain code if applicable).\nHappy to help regarding 2 if you’d like.\n\n post by SkyZ on May 21\n\n SkyZ\n\n Hey there legend. Thank u for your reply and i absolutely agree with your 2 points.\nI jumped 2 fast to propopal agree;\nwould be better to debate about it in the Ideas bank. I appologize for that i jumped 2 hard; my bad and for the future ideas for proposals i will use Ideas Bank; so we can discuss and prepare for proper PIP.\ni was abused by Derrp now swallowing the consequences \nWe live we learn; hope u can forgive me for my rookie mistake.\nYes if you can elaborate whats needed to trigger a vote on Realms would be epic. just for future knowledge i would love to know the process if possible.\nRegarding the nr.1 point i thought were talking about burning the reserve tokens. Fees for transactions on MON stayin the same and the Pythwheel prize pool remains intact.\nThis is exactly why i schould use Ideas bank agree.\nBut now we got things in debate and maybe we can continue here or do we move it to iBank? So we cean clear things out and then write a new ful detailed with no dilemas to OP-PIP.\nThank u so much Marc I appreciate you and your work alot.\nHats down legend \n\n post by KemarTiti on May 21\n\n KemarTiti\n\nThis happens here: Pyth Governance | Realms\nIt requires some minimum amount of PYTH staked but it is not necessary that the one suggesting the idea/proposal is the one to put the onchain proposal on ; can always find someone.\n\nBy reserve tokens you refer to the ones that the Pyth DAO currently owns in its treasury? Whether they are coming from the monthly purchases or Douro Labs distribution of Pyth Pro and other revenues?\n\n post by SkyZ on May 21\n\n SkyZ\n\nThis happens here: Pyth Governance | Realms\nIt requires some minimum amount of PYTH staked but it is not necessary that the one suggesting the idea/proposal is the one to put the onchain proposal on ; can always find someone.\n\nI see so as a longtime staker i can do that also. Ok so no extra rights or roles needed for that.\n\nBy reserve tokens you refer to the ones that the Pyth DAO currently owns in its treasury? Whether they are coming from the monthly purchases or Douro Labs distribution of Pyth Pro and other revenues?\n\nYes those from monthly purchases that are active right now or\na mixture of monthly purchases with what Douro Labs distribute of Pyth Pro and other revenues.\n\n post by KemarTiti on May 21\n\n KemarTiti\n\n Can you remind me if every time the Pyth Wheels, there’s revenue generated for the Community Council at all or not?\n\n post by Pythian_151 on May 21\n\n Pythian_151\n\n I like the proposal, alternatively if we want to reduce supply, we could send a percentage of the monthly DAO Pyth revenue to a dead wallet.\n\n post by KemarTiti on May 22\n\n KemarTiti\n\n Which is discussed here: Pyth Reserve v2: Ratio-Based Treasury Management - #3 by lowkeigh\n\n post by Frozenmind on May 22\n\n Frozenmind\n\n KemarTiti\n\n @Derrp @Planck Can you advise what is the intended usage of the 0.77 MON per spin on Pythwheel?\nI figure that it was increased from 0.60 MON to 0.77 MON when Entropy fees were increased from 0.20 to 0.37 MON by the Pythian Council so mostly curious about the remaining 0.40 MON actually.\n\n post by Derrp on May 23\n\n Derrp\n\n Hi Frozen, a great question! Appreciate your curiosity!\nThe 0.77 MON is the protocol fee + service provider fee.\nThe 0.37 MON you are referring to only covers the protocol fee component, which goes to the DAO.\nThe service provider fee is separate and covers callback gas costs.\nHighly recommend you read the docs page to see this in more detail (with default service provider fee included)\n\nYou will see an Entropy call on Monad costs 0.77 MON \nI hope this answers your question, but if anything is unclear, feel free to reach out!\n\n Should We Move the Pyth Wheel Back to Base or Monad?\n\n post by Frozenmind on May 23\n\n Frozenmind\n\n Thanks for the reference.\nCrystal clear to me \nMight be interesting to refer to the Dev Docs somewhere on the PythWheel page for those that could have similar questioning.\n\n post by Slem on May 27\n\n Slem\n\n This is a great idea.\nI would also like to suggest improving the Discord roles + wallet snapshot logic for PythWheel.\nInstead of taking the snapshot only once per month, it would be much better if the system updated automatically on a rolling basis. For example, once per day, or even continuously every few minutes.\nThis would make PythWheel feel much more fair and alive, because active Pythians would not have to wait a full month for their new roles or wallet eligibility to be reflected.\nIf the goal is to reward real community participation, then the role and wallet data should probably update much closer to real time.\n\n 29 days later\n\n post by SkyZ on Jun 25\n\n SkyZ\n\n KemarTiti\n\n Love that proposal was moved to Ideas so we clear out on some basics lIke Mark pointed out.\nFunding Source Clarity\nNo fee for users (spinners dont pay anything)\nI just want to discuss what are the optoms of where we could source those rebought pyth tokens for permanent burn via Pythwheel.\nQuestions like\n• Does it come from the existing PythWheel prize pool?\n• Does it require a new Community Council budget line item?\n• Or is there a separate “burn fund” being proposed?\nTy all\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 568\n\n Apr 6\n\n Burn Pyth Token Using a Percentage of Fees\n\n Ideas Bank\n\n constitutional-pip\n\n 20\n\n 1.1k\n\n Sep 2025\n\n Pythenians 2.0\n\n Ideas Bank\n\n 43\n\n 1.6k\n\n Jun 3\n\n Pyth Token Phase 2\n\n Ideas Bank\n\n 35\n\n 1.3k\n\n Feb 26\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d","tokens":3750,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267535614,"hash":"d5c28fb443ee2e28a885c99b1a4492bebc746fdb"}
{"url":"https://forum.pyth.network/t/op-pip-implement-pythwheel-burn-registry-100-pyth-permanent-burn-per-spin-community-deflation-mechanism/2555/18","domain":"forum.pyth.network","title":"[OP-PIP] Implement PythWheel Burn Registry: 100 PYTH Permanent Burn per Spin Community Deflation Mechanism - Ideas Bank - Pyth DAO","text":"Ideas Bank\n\n operational-pip\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 5\n\n 4\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n May 19\n\n 18 / 18\n\n Jun 25\n\n Jun 25\n\n post by SkyZ on May 19\n\n SkyZ\n\n I propose integrating a permanent, transparent Burn Registry into the existing PythWheel (pythwheel.com).\nEvery spin performed by a Pythian will burn exactly 100 PYTH tokens from circulation. Spins are awarded based on community participation: joining the Pyth Network, earning Discord/community roles, and advancing through higher-tier roles grants more spins (higher roles = more spins = greater deflationary impact).\nThis creates a gamified, merit-based deflationary flywheel that directly ties active community engagement to PYTH token scarcity.\n*Motivation\nPythWheel is already a successful community engagement tool powered by Pyth Entropy — provably fair, on-chain randomness that gives active Discord members weekly opportunities to win PYTH prizes, NFTs (PythiansNFTs), and other rewards.\nIt has proven highly effective at driving participation. However, the current model is purely inflationary from the token perspective (prizes are distributed without removing supply).\nWe can evolve PythWheel into a true deflationary engine by adding a burn on every spin.\nThis:\n\nRewards the most active and highest-role Pythians (the ones who contribute the most to the community).\n\nCreates visible, on-chain deflation that the entire ecosystem can track.\n\nStrengthens PYTH tokenomics without affecting existing staking, governance, or revenue mechanisms.\n\nTurns community fun into real, permanent value accrual for all PYTH holders.\n\nProposed Specification\n\nBurn Mechanics\n\nEvery spin on PythWheel burns exactly 100 PYTH permanently.\n\nBurns are executed on-chain (via smart contract) and are irreversible.\n\nThe burn happens at the moment the spin is initiated\n\nRole-Based Spin Allocation (the “higher roles = more spins” system)\n\nBase: New Pythians (joined Discord + basic verification) → 1 spin per week/month.\n\nMid-tier roles (active contributors, Pythians with verified activity like High Priest etc) → 2–3× spins.\n\nHigh-tier roles (Chirons, Aristophanes, Venus de Milo, etc., or future advanced contributor roles) → 4–6× spins.\n\nSpin allocation resets periodically (weekly or monthly) to keep it fair and ongoing.\n\nBurn Registry Dashboard\n\nPythWheel showing live total PYTH burned 1,050,500 PYTH:\n\nMonthly burn history with progress bars:\n\nMay 26 → 360,500 PYTH\n\nApr 26 → 464,600 PYTH\n\nMar 26 → 225,400 PYTH\n\nClear labeling: “100 PYTH PER SPIN · PERMANENT · DEFLATIONARY”\n\nTechnical Integration\n\nLeverage existing Pyth Entropy for spin randomness (already live).\n\nAdd simple burn logic to the PythWheel smart contract(s).\n\nMinimal UI/UX changes — just add the Burn Registry section and spin-cost confirmation.\n\nNo impact on current prize distribution\n\nBenefits\n\nDeflationary pressure on PYTH supply directly proportional to community activity.\n\nIncentivizes role progression and deeper community involvement.\n\nMarketing & virality — the live Burn Registry becomes a trophy wall that Pythians love to share.\n\nAligns perfectly with Pyth’s ethos of transparency, decentralization, and community ownership.\n\nComplements (does not replace) existing tokenomics, staking rewards, and revenue mechanisms\n\nDerrp said talk is cheap propopsals are the way so i did it \n\n Community Council Term 2: Six-Month Mid-Term Report\n\n 5\n\n 4\n\n 2\n\n 2\n\n read \n\n 5\n min\n\n post by theretardedadrian on May 19\n\n theretardedadrian\n\n This is a great proposal skyz.\nIt reduces the amount of pyth in circulation which encourages rarity, thereby leading to long-term stability.\n\n post by Derrp on May 19\n\n Derrp\n\n Me and my big mouth!\nLooks like an interesting proposal, however, there would need to be some guardrails in place.\n\nBurning 100 PYTH at a time would involve quite a lot of transactions, considering the wheel is currently being spun over 5,000 times per month. Perhaps we can use the end of month metrics and submit a single transaction?\nWe should also include a provision that a maximum of 50% of the total reserve tokens in the account can be burned at once (we cannot burn more than we have, and setting an upper-bound limit may be useful). This also gives the Community Council the flexibility to increase the amount of PythWheel monthly spins dynamically, without affecting the maximum limits of DAO funds.\nWe should set a date to review the current parameters (say, a vote to approve it’s continuation or not) every 12 months\nWe should include a provision to update/change the percentage of monthly burn limit subject to a proposal (cannot be changed within a frequency of less than 6 months from a previous change)\nThe Community Council will advise the Pythian Council as to the burn amount required, and verified with on-chain metrics. For example, the monthly amount of successful spin interactions with contract 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3 on Monad. If the deployed chain of PythWheel changes at any time, the Community Council will make these changes known to the DAO and the Pythian Council with a full update.\nThat the community-built dApp “PythWheel” code be available to be audited by the Pyth Team/the DAO.\nThat previous month burns be included retrospectively: back to the launch of PythWheel itself\n\nJust a few items for thought, and some security measures\n\n post by peter on May 20\n\n peter\n\n it’s good idea to impletment Pythwheel burn registry..and sound interesting..\n\n post by Artistarjay18 on May 20\n\n Artistarjay18\n\n Beautiful proposal right there… I honestly love what I am seeing. Here are my honestly takes and suggestions.\n- Total Spins and Pyth to be burnt for the a duration(monthly or weekly) should be displayed on the website( in real time) as well as the total Pyth burnt all time.\n- A governance Vote for the continuation of the Pyth token burn program tied to the pythwheel spin should be implemented every 6months( To measure community interest and involvement)\n- Burn should happen In 4 weeks format( not 30 or 31days monthly format) So burn can easily follow the Pythwheel week refresh cycle (Monday 12am UTC). And Come with a tag like “PYTH BURN CYCLE”\nThis is just my brain braining nothing weird.\n\n post by SkyZ on May 20\n\n SkyZ\n\n Derrp\n\n Burning 100 PYTH at a time would involve quite a lot of transactions, considering the wheel is currently being spun over 5,000 times per month. Perhaps we can use the end of month metrics and submit a single transaction?\nAgree 100%\nUI showing stats of the burn that will happen (end of every 4th epoch or so) for the excitement . Preety much as it runs right now with icon but with fresh updated data every X time .. schould be ahort its Pyth after all​\nWe should also include a provision that a maximum of 50% of the total reserve tokens in the account can be burned at once (we cannot burn more than we have, and setting an upper-bound limit may be useful). This also gives the Community Council the flexibility to increase the amount of PythWheel monthly spins dynamically, without affecting the maximum limits of DAO funds.\nAgree 50 sound good and the flexibility is good point\nWe should set a date to review the current parameters (say, a vote to approve it’s continuation or not) every 12 months\n 6 or 12 m yes\nWe should include a provision to update/change the percentage of monthly burn limit subject to a proposal (cannot be changed within a frequency of less than 6 months from a previous change) \nThe Community Council will advise the Pythian Council as to the burn amount required, and verified with on-chain metrics. For example, the monthly amount of successful spin interactions with contract 0xdb9B1e94B5b69Df7e401DDbedE43491141047dB3 on Monad. If the deployed chain of PythWheel changes at any time, the Community Council will make these changes known to the DAO and the Pythian Council with a full update.\nThat the community-built dApp “PythWheel” code be available to be audited by the Pyth Team/the DAO.\nThat previous month burns be included retrospectively: back to the launch of PythWheel itself\nLob your brain sir\n\n post by KemarTiti on May 20\n\n KemarTiti\n\n gm @SkyZ\n1st thanks a ton for the idea/post!\nI only have 2 points for now:\n\nFunding Source Clarity\n\nThe proposal doesn’t specify where the 100 PYTH per spin actually comes from. This is fundamental:\n• Is it a user fee (spinners pay 100 PYTH)?\n• Does it come from the existing PythWheel prize pool?\n• Does it require a new Community Council budget line item?\n• Or is there a separate “burn fund” being proposed?\nEach of these has very different implications for incentives, sustainability, and budget planning. Would be good to clarify.\n\nForum Process\n\nNew ideas (like this one I believe) should typically start in the Ideas Bank for initial discussion and feedback (usually 1-2 weeks) - literally what is happening here. This gives the community time to poke holes, suggest improvements, and build consensus before formalizing as a PIP.\nOnce an idea has been refined through that process, it can be submitted as an Operational PIP. And for an OP-PIP to officially go to vote, it requires a vote triggered on Realms (with on-chain code if applicable).\nHappy to help regarding 2 if you’d like.\n\n post by SkyZ on May 21\n\n SkyZ\n\n Hey there legend. Thank u for your reply and i absolutely agree with your 2 points.\nI jumped 2 fast to propopal agree;\nwould be better to debate about it in the Ideas bank. I appologize for that i jumped 2 hard; my bad and for the future ideas for proposals i will use Ideas Bank; so we can discuss and prepare for proper PIP.\ni was abused by Derrp now swallowing the consequences \nWe live we learn; hope u can forgive me for my rookie mistake.\nYes if you can elaborate whats needed to trigger a vote on Realms would be epic. just for future knowledge i would love to know the process if possible.\nRegarding the nr.1 point i thought were talking about burning the reserve tokens. Fees for transactions on MON stayin the same and the Pythwheel prize pool remains intact.\nThis is exactly why i schould use Ideas bank agree.\nBut now we got things in debate and maybe we can continue here or do we move it to iBank? So we cean clear things out and then write a new ful detailed with no dilemas to OP-PIP.\nThank u so much Marc I appreciate you and your work alot.\nHats down legend \n\n post by KemarTiti on May 21\n\n KemarTiti\n\nThis happens here: Pyth Governance | Realms\nIt requires some minimum amount of PYTH staked but it is not necessary that the one suggesting the idea/proposal is the one to put the onchain proposal on ; can always find someone.\n\nBy reserve tokens you refer to the ones that the Pyth DAO currently owns in its treasury? Whether they are coming from the monthly purchases or Douro Labs distribution of Pyth Pro and other revenues?\n\n post by SkyZ on May 21\n\n SkyZ\n\nThis happens here: Pyth Governance | Realms\nIt requires some minimum amount of PYTH staked but it is not necessary that the one suggesting the idea/proposal is the one to put the onchain proposal on ; can always find someone.\n\nI see so as a longtime staker i can do that also. Ok so no extra rights or roles needed for that.\n\nBy reserve tokens you refer to the ones that the Pyth DAO currently owns in its treasury? Whether they are coming from the monthly purchases or Douro Labs distribution of Pyth Pro and other revenues?\n\nYes those from monthly purchases that are active right now or\na mixture of monthly purchases with what Douro Labs distribute of Pyth Pro and other revenues.\n\n post by KemarTiti on May 21\n\n KemarTiti\n\n Can you remind me if every time the Pyth Wheels, there’s revenue generated for the Community Council at all or not?\n\n post by Pythian_151 on May 21\n\n Pythian_151\n\n I like the proposal, alternatively if we want to reduce supply, we could send a percentage of the monthly DAO Pyth revenue to a dead wallet.\n\n post by KemarTiti on May 22\n\n KemarTiti\n\n Which is discussed here: Pyth Reserve v2: Ratio-Based Treasury Management - #3 by lowkeigh\n\n post by Frozenmind on May 22\n\n Frozenmind\n\n KemarTiti\n\n @Derrp @Planck Can you advise what is the intended usage of the 0.77 MON per spin on Pythwheel?\nI figure that it was increased from 0.60 MON to 0.77 MON when Entropy fees were increased from 0.20 to 0.37 MON by the Pythian Council so mostly curious about the remaining 0.40 MON actually.\n\n post by Derrp on May 23\n\n Derrp\n\n Hi Frozen, a great question! Appreciate your curiosity!\nThe 0.77 MON is the protocol fee + service provider fee.\nThe 0.37 MON you are referring to only covers the protocol fee component, which goes to the DAO.\nThe service provider fee is separate and covers callback gas costs.\nHighly recommend you read the docs page to see this in more detail (with default service provider fee included)\n\nYou will see an Entropy call on Monad costs 0.77 MON \nI hope this answers your question, but if anything is unclear, feel free to reach out!\n\n Should We Move the Pyth Wheel Back to Base or Monad?\n\n post by Frozenmind on May 23\n\n Frozenmind\n\n Thanks for the reference.\nCrystal clear to me \nMight be interesting to refer to the Dev Docs somewhere on the PythWheel page for those that could have similar questioning.\n\n post by Slem on May 27\n\n Slem\n\n This is a great idea.\nI would also like to suggest improving the Discord roles + wallet snapshot logic for PythWheel.\nInstead of taking the snapshot only once per month, it would be much better if the system updated automatically on a rolling basis. For example, once per day, or even continuously every few minutes.\nThis would make PythWheel feel much more fair and alive, because active Pythians would not have to wait a full month for their new roles or wallet eligibility to be reflected.\nIf the goal is to reward real community participation, then the role and wallet data should probably update much closer to real time.\n\n 29 days later\n\n post by SkyZ on Jun 25\n\n SkyZ\n\n KemarTiti\n\n Love that proposal was moved to Ideas so we clear out on some basics lIke Mark pointed out.\nFunding Source Clarity\nNo fee for users (spinners dont pay anything)\nI just want to discuss what are the optoms of where we could source those rebought pyth tokens for permanent burn via Pythwheel.\nQuestions like\n• Does it come from the existing PythWheel prize pool?\n• Does it require a new Community Council budget line item?\n• Or is there a separate “burn fund” being proposed?\nTy all\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 568\n\n Apr 6\n\n Burn Pyth Token Using a Percentage of Fees\n\n Ideas Bank\n\n constitutional-pip\n\n 20\n\n 1.1k\n\n Sep 2025\n\n Pythenians 2.0\n\n Ideas Bank\n\n 43\n\n 1.6k\n\n Jun 3\n\n Pyth Token Phase 2\n\n Ideas Bank\n\n 35\n\n 1.3k\n\n Feb 26\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d","tokens":3723,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267547366,"hash":"d4b621a7bfaaf05610f3e298d92e26e291be607a"}
{"url":"https://gov.optimism.io/c/general/1","domain":"gov.optimism.io","title":"Latest ✨ General topics - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Latest topics in ✨ General\n\n ✨ General\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n Exploring execution-time authorization for Superchain applications\n\n I’d like to get feedback from Optimism builders and the broader Superchain community on a potential infrastructure primitive for applications, payment flows, smart accounts and autonomous transaction systems. \nThe proble…\n\n read more\n\n 6\n\n 71\n\n 1h\n\n Season 8 Growth Grants - TVL Impact Review\n\n season-8\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me. \nI did …\n\n read more\n\n 2\n\n 165\n\n 13d\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 106\n\n Sep 4\n\n Accelerated Decentralization Proposal For Optimism\n\n Authors: @GFXlabs \nContributors: @MattGov.eth (contributions to L1 Bridge Escrow section), @Juanbug_Pgov (general commentary) \nIf you hold OP, please signal your approval of this accelerated decentralization on this Snap…\n\n read more\n\n 36\n\n 3.6k\n\n Aug 25\n\n Sandcastles and Social Mercenaries: Why EVM DAOs Are Being Looted\n\n Optimists, \nHumanity learned thousands of years ago that an open city with vast treasure is an invitation to plunder. Walls were built to stop looters. Rules were written to prevent brute power from ruling. Police were c…\n\n read more\n\n 2\n\n 88\n\n Aug 7\n\n Breaking the Capitalist Supremacy: How Grant Bottlenecks Drive the Sea Shell Economy\n\n Optimists, \nWe need to address the deep structural flaws causing voter apathy and treasury extraction across our governance landscape. The reason our collective structures are stalling is that our token distribution fram…\n\n read more\n\n 1\n\n 81\n\n Jul 21\n\n The Capitalist Supremacy Trap: Why Our DAO Governance is a Digitized Feudal State\n\n Community, \nWhen we look at, Optimism’s RetroPGF plutocracy: Our governance models are suffering from deep historical amnesia and a massive scale mismatch. \nWe are trying to govern global ecosystems of millions of users …\n\n read more\n\n 7\n\n 131\n\n Jul 21\n\n The Legalist Trap: Why Smart-Contract Absolutism is Killing Our DAO\n\n We need to address the cultural dogma of “Code is Law” that is currently paralyzing EVM DAOs. \nEvery time our governance suffers an exploit, a treasury grant gets misspent, or an unexpected market swing triggers cascadin…\n\n read more\n\n 1\n\n 94\n\n Jul 7\n\n The VC-Driven Oligarchy: Why Token-Weighted Voting is Killing Our DAO\n\n Our current DAO model is suffering from a massive structural flaw: it is built on the corporate shareholding model. \nAcross the EVM landscape, we are dealing with extreme voter apathy, VC dominance, and massive treasury …\n\n read more\n\n 4\n\n 142\n\n Jul 7\n\n School project research\n\n hello,i am a business student and I’m currently taking a course on blockchain and right now I am doing an analysis on the optimism collective dao, is there any information that you could provide me through here or proper…\n\n read more\n\n 4\n\n 102\n\n Jun 26\n\n Introduction about myself\n\n Hello all My name is gintama i have previously been deeply involved in web3 governance and this is my first post on optimism forum . \nbefore i go in-depth about myself - if fellow community members can guide me about whe…\n\n read more\n\n 8\n\n 167\n\n Jun 25\n\n Help: Dashboard not loading wallet\n\n Staking dashboard not loading my wallet balances\n\n 1\n\n 111\n\n Jun 24\n\n Optimism OP and liquidity Alliance Erisprotocol Strategy\n\n A Clear Opportunity for the Optimism OP Community \nOP holders are sitting on a real asset, but the yield inside our own ecosystem sometimes leaves us wanting more. \nThe Terra side offers a straightforward play that, if w…\n\n read more\n\n 3\n\n 144\n\n Jun 17\n\n RFC: Six-Month Superchain Education Campaign with Underground Crypto\n\n RFC: Six-Month Superchain Education Campaign with Underground Crypto\nHi Optimism community, \nI’m Underground Crypto, a crypto education creator focused on helping everyday crypto users better understand blockchain ecosys…\n\n read more\n\n 2\n\n 89\n\n Jun 16\n\n Expand Superchain Passport to Include All OP Superchain Apps\n\n Expand Superchain Passport to Include All OP Superchain Apps\nSummary\nI would like to propose expanding Superchain Passport to include all applications and products that support the OP Superchain ecosystem. \nMotivation\nTh…\n\n read more\n\n 0\n\n 83\n\n Jun 1\n\n The Northern Trade Link – Enhancing Logistics as a Public Good in Somaliland\n\n The Mission \nThis project will reinstate a vital transport and logistics link that has been utilized by the communities of Borama, hargeisa and Wajale for nearly a decade. For 9 years this service has been the backbone o…\n\n read more\n\n 5\n\n 134\n\n May 19\n\n Should the Optimism Security Council Include a Non-Technical Member Role?\n\n season-9\n\n The Season 9 Security Council Cohort B Elections are underway, and as the community evaluates candidates, I want to raise a structural question worth discussing: \nShould the Security Council formally include a Non-Techni…\n\n read more\n\n 0\n\n 72\n\n May 11\n\n RFP Hub: grants and funding opportunities across web3\n\n Hi, \nI’m George Stefan CrossChainLabs ( https://crosschainlabs.tech), a small team building public-goods infrastructure across web3. \nWe plan to build an RFP Hub for Ethereum Foundation, a single open place where builde…\n\n read more\n\n 5\n\n 134\n\n May 2\n\n URTAN: Can DeFi Build a Universal Panic Button ? Lessons from Kelp Hack\n\n MconnectDAO \n1 \n2h \nBackground \nOn April 18, 2026, Kelp DAO lost $292M in rsETH through a forged LayerZero cross-chain message. Arbitrum’s Security Council froze $71M a great response. But $175M was already gone to BTC…\n\n read more\n\n 0\n\n 49\n\n Apr 25\n\n Status of the Bedrock Constitution — Working Constitution expires April 2026\n\n Section 1 of the Working Constitution (adopted April 26, 2022) describes itself as: \n\nA transitory document. The Working Constitution will remain in effect no more than four years from the date of its adoption. After tha…\n\n read more\n\n 2\n\n 94\n\n Apr 23\n\n Tally Is Shutting Down — Option to Maintain the Existing Interface (No Contract Changes)\n\n Hi delegates and community members, \nI’m David Len. My team and I built and maintained the governance Discourse layer used by Aave and 10+ DAOs. Given Tally’s shutdown, we’re exploring a path to keep a familiar governanc…\n\n read more\n\n 0\n\n 36\n\n Apr 13\n\n Mistakenly sent USDT to the USDT contract address, instead of the receiving exchange address\n\n TxID: 0x16927e3b77e7f8230d3c3f167f4dbea9f0ddee2d6b68405e448d2802b1814010 \nI was going to send 354.573835 USDT from my wallet to Okex exchange but I mistakenly copy-pasted the USDT token contract address (0x94b008aA00579c…\n\n read more\n\n 4\n\n 116\n\n Mar 19\n\n Base, the Superchain, and Governance: Questions That Merit Answers\n\n As an Optimism Collective participant since the early days, I’ve followed the Base partnership since the original 2023 announcements. Base’s inaugural blog post framed the relationship as a foundational, multi-year align…\n\n read more\n\n 5\n\n 1.1k\n\n Mar 3\n\n Seeking Feedback: A New Tool to Prevent Crypto Transfer Mistakes\n\n Hi everyone, \nI’m exploring the development of a tool called Crypto Transfer Guard, designed to help users prevent costly mistakes when sending cryptocurrency. Before building it, I’d love to hear your thoughts. \nThe bas…\n\n read more\n\n 0\n\n 42\n\n Feb 13\n\n Decentralised sequencer\n\n Hi there, \nI am new to the optimism community, and I wanted to know if there are any technical documents outlining some proposal for a decentralised sequencer, or anything along this direction? Is there someone in the OP…\n\n read more\n\n 1\n\n 75\n\n Feb 12\n\n Introducing a Deterministic, Audit-Ready Treasury Reporting MVP for Optimism DAOs\n\n Hello Optimism community, \nI’d like to introduce an MVP I recently developed for DAO and treasury on-chain reporting, built with a strong focus on deterministic calculations, transparency, and audit-ready outputs. \nAs th…\n\n read more\n\n 0\n\n 51\n\n Jan 26\n\n Users who sold the initial OP airdrop should become ineligible for all future airdrops\n\n Have seen enough wallets collect the OP airdrop, swap it straight to Uniswap. \nThese accounts are not playing a constructive role in Optimism governance. Instead of contributing to governance, they are maximising for pro…\n\n read more\n\n 599\n\n 43.8k\n\n Jan 20\n\n The Quantum-Mirrored Internet: Securing All of Web3 on Optimism \n\n The Quantum-Mirrored Internet: Securing All of Web3 on Optimism \nHello Optimism Collective! \nI’m Nichole (NicheAI / Luxbin), and I’m proposing a public-goods security layer that treat…\n\n read more\n\n 2\n\n 68\n\n Jan 13\n\n Venture studio for Optimism projects, offered by Pollen Labs - General communication thread\n\n season-6\n\n Greeting builders & citizens, \nWe are Pollen Labs and were recently awarded a grant in season 6. We are posting this update as a general communication thread and will start inviting project leads to collaborate with us. …\n\n read more\n\n 6\n\n 330\n\n Jan 10\n\n S8 to S9 Council Budget Reprice Request\n\n season-9\n\n Authors: @PGov, @Gonna.eth, @Wildmolasses, @Alisha \nUpdate January 20th 2026: The budget board has finalized their recommendations for the OP budget reprice here: Proposed Midterm Adjustment for Seasons 8 and 9 Operating…\n\n read more\n\n 0\n\n 134\n\n Jan 8","tokens":2421,"squid":"ink-governance","role":"Council Listener","at":1791267557422,"hash":"023128733063416e53f4a15e0807aac74eedc354"}
{"url":"https://gov.optimism.io/t/op-security-proxy-a-local-rpc-middleware-to-prevent-paying-for-failed-l2-executions/10810/4","domain":"gov.optimism.io","title":"OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n ✨ General\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Aug 14\n\n 4 / 4\n\n Sep 4\n\n Sep 4\n\n post by Cypherin on Aug 14\n\n Cypherin\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet or client and the public Optimism RPC nodes.\nThe core mechanic is that whenever a transaction goes out via eth_sendRawTransaction, the proxy catches it. It then uses the revm engine to fork the network state locally and run a quick simulation. If it detects that the transaction is going to revert, halt, or burn the whole gas limit without touching the state, the proxy just drops it before it ever hits the public mempool.\nI built this because when you use Ethereum-equivalent chains, you still end up paying the L2 execution fee up to the point of failure if a transaction reverts on-chain. We see this all the time with MEV bots, slippage issues, or unexpected state changes. This proxy serves as a public good that stops regular users from paying for failed executions, saving them money and keeping junk traffic off the sequencer.\nI ran some tests against the mainnet.optimism.io endpoint to see the performance impact. For standard read requests like eth_call, there is basically no overhead. Because I am using tokio and hyper for connection pooling, the jitter was actually slightly better than hitting the upstream directly. The upstream took around 516ms, while the proxy handled it in about 444ms.\nWhen doing the actual transaction simulation, it takes about 2.9 seconds. That overhead comes from having to fetch nonces, balances, and raw bytecodes over the network on the fly so we can reconstruct the state from scratch.\nFor the stack, it is mostly Rust. I rely on tokio for the async side of things and hyper to handle the HTTP server. I also pull in alloy to handle the Ethereum primitives and RPC parsing, while revm runs the local EVM simulations. I also wrote a bunch of strict TDD tests to make sure it doesn’t panic if an upstream node times out.\nLooking ahead, I am hoping to implement LRU caching for the state trie nodes so we can drop the simulation latency well below 100 milliseconds. I also plan to bake in some local heuristics to catch sandwich attacks before they happen, and eventually make sure the whole thing runs smoothly across Base and other Superchain networks.\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n 3\n\n 10 days later\n\n post by Anzus_GemWallet on Aug 25\n\n Anzus_GemWallet\n\n This sounds useful, especially for users who are confused when a transaction fails but they still lose money to fees.\nFrom a support perspective, how would this appear to an ordinary wallet user? Would they receive a clear explanation that the transaction was stopped and why?\nMaking that message easy to understand could be just as important as preventing the failed transaction itself.\n\n post by Cypherin on Aug 30\n\n Cypherin\n\n Right now, when a transaction reverts in local revm simulation, the proxy intercepts the send call and returns a standard JSON-RPC error with code minus 32000 instead of a transaction hash. In the error payload, it includes both the raw hex revert data and a human readable decoded string when a standard Error(string) or Panic(uint256) signature is present. For a wallet like GemWallet or MetaMask connected through the proxy, the wallet catches that RPC error before signing or broadcasting. Instead of the user seeing a confusing onchain failed receipt twenty seconds later with lost gasfees, the wallet immediately renders the exact reason, such as slippage exceeded or insufficient allowance, right at the confirmation step. I am also adding an extra metadata field in the error response that calculates the estimated L2 gas fee the user just saved by having the execution halted locally. That way, the wallet UI can explicitly show users that their transaction was safely intercepted and no gas was spent.\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Anzus_GemWallet\n\n Just wanted to close the loop here. The question about how this surfaces to an ordinary wallet user directly shaped how I scoped the SDK work: the formal builder grant proposal is now up at [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain, and milestone two is specifically the TypeScript provider wrapper with standardized error decoding so a wallet like GemWallet can render the exact revert reason and the gas saved at the confirmation step, instead of a generic failed transaction. Appreciate the input, it’s part of why that milestone looks the way it does.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain\n\n Governance Fund Missions\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions be…\n\n read more\n\n 4\n\n 128\n\n 27d\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Enabling $OP as a gas token on Optimism Network!\n\n ✨ General\n\n Enabling $OP as a gas token on Optimism Network! \nThe $OP token can be used to pay gas fees on the Optimism Network!. This is a major addition to the utility of the $OP token, and will …\n\n read more\n\n 144\n\n 18.9k\n\n Jun 2023\n\n [DRAFT] [GF: Phase 1 Proposal] Light Client Proxy bridge for Optimism\n\n Governance Fund: Phase 1\n\n Project Name: \nDeveloping Light Client Proxy bridge for Optimism \nAuthor Name: \nDaiki Ishikawa @Datachain \n(https://www.datachain.jp/) \nNumber of OP tokens requested: \nTo be determined \nL2 Recipient Address: \nTo be deter…\n\n read more\n\n 4\n\n 2.0k\n\n Sep 2022\n\n Change the use of OP tokens from a governance token to the main network token for gas payment\n\n ✨ General\n\n Do you agree with changing the use of OP tokens from a governance token to a main network token to pay the gas fee?\n\n 192\n\n 14.9k\n\n Mar 2023","tokens":1651,"squid":"ink-governance","role":"Council Listener","at":1791267569942,"hash":"2b2b1fc3f01999ce1a5fc3ceafc5307736bedbbe"}
{"url":"https://forum.openzeppelin.com/t/bep20-crowdsale/11666/13","domain":"forum.openzeppelin.com","title":"BEP20 Crowdsale - Smart Contracts / Review Wanted - OpenZeppelin Forum","text":"Smart ContractsReview Wanted\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 2\n\n Jun 2021\n\n 13 / 13\n\n Dec 2021\n\n Dec 2021\n\n post by quantumcoder on Jun 30, 2021\n\n post by FreezyEx on Jul 1, 2021\n\n post by Skyge on Jul 1, 2021\n\n post by quantumcoder on Jul 2, 2021\n\n post by quantumcoder on Jul 2, 2021\n\n post by Skyge on Jul 2, 2021\n\n post by quantumcoder on Jul 2, 2021\n\n post by zanja85 on Jul 6, 2021\n\n 5 months later\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n post by Skyge on Nov 21, 2021\n\n Skyge\n\n Hi, welcome! \nThe open time and close time is the timestamp, so just convert the time to timestamp to pass.\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n Kubrick_BERGMAN\n\n Thanks. How can i do that? And how can i set rate for example Presale rate: 100 MyToken = 0.01 BNB?\n\n post by Skyge on Nov 21, 2021\n\n Skyge\n\nMany tools online can convert to timestamp.\n\nHave a look at this documentation:\nCrowdsales - OpenZeppelin Docs\n\n 24 days later\n\n post by medolantex on Dec 15, 2021\n\n medolantex\n\n hello to all I wanted to create a smart contract for the crowd sale but I don't understand anything can someone tell me which contract and how can I implement it on my site so that people connect their wallet and buy?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":459,"squid":"ink-security_audits","role":"Sentinel","at":1791267572082,"hash":"622fae7bdcad35cd58f787b3607926d1c3b3ed31"}
{"url":"https://gov.optimism.io/t/shutterized-optimism-an-encrypted-mempool-for-the-op-stack/6387/1","domain":"gov.optimism.io","title":"Shutterized Optimism – An Encrypted Mempool for the OP Stack - Proposals 📃 / Technical Proposals - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack \n\n Proposals 📃Technical Proposals\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n read \n\n 13\n min\n\n Jul 2023\n\n 1 / 5\n\n Jul 2023\n\n Jul 2023\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori\nExecutive Summary\nThis document serves as a requirements and technical architecture document for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, capitalizing on the capabilities of the Shutter Network. The mechanism targets the reduction of front-running and MEV-related exploits in the Ethereum DeFi ecosystem by adopting a shielded mempool using threshold encryption.\nBy integrating this mechanism, we foresee OP Stack-based rollups becoming more secure and efficient layers, attracting safer trading for DeFi users, more robust censorship resistance, and increased profitability. Moreover, the sequencer operators will be able to claim immunity from front-running and censoring transactions by design, while retaining their ability to collect and/or distribute back-running related MEV.\nDecentralized Sequencer and MEVA designs are largely orthogonal to this proposal and complement it well.\nTable of Contents\n\nExecutive Summary\nTable of Contents\nIntroduction and Goals\n3.1. Problem Statement\n3.1.1. Malicious MEV and Censorship\n3.1.2. MEV and Censorship on Layer 2 (L2)\n3.1.3. Regulatory Implications\n3.2. MEV mitigation solutions overview\n3.3. OP Stack\n3.4 Shutter Network\nParticipant Requirements\n4.1 End User\n4.2 Dapp Project\n4.3 Optimism Rollup Node\n4.4 Optimism Sequencer\n5 Component Requirements\n5.1 Functional Requirements\n5.1.1 Optimism Rollup Node\n5.1.2 Optimism Sequencer Node\n5.1.3 Keyper\n5.1.4 Front End Library\n5.2 Non-functional Requirements\nTechnical Architecture of Shutterized Optimism\n6.1 Overview\n6.2 Components\n6.2.1 Keyper Set\n6.2.2 Sequencer\n6.2.3 System Contracts\n6.2.4 Client Library\n6.3 Code Modifications\n6.3.1 Shutter Inbox Contract\n6.3.2 Keyper Set Contract\n6.3.3 Key Broadcast Contract\n6.3.4 Engine API\n6.3.5 op-node\n6.3.6 op-geth\n6.4 User Interaction\n6.5 Interaction With Decentralized Sequencers\n6.6 Finality Assumption\n6.7 Potential Issues and Solutions\n6.7.1 Liveness Failures\n6.7.2 Latency\n6.7.3 Sequencer Side-Channel Attack\nDesign Options\n7.1 Block or Transaction Keys\nFuture Considerations\nConclusion\n\nIntroduction and Goals\nThis document presents requirements and an architecture proposal for a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network. The mechanism aims to provide front-running protection using an encrypted/shielded mempool and threshold encryption, as proposed in Shutter Network’s Optimism Governance Forum post.\nWe think by adopting this mechanism, OP Stack-based rollups become better, more neutral base layers and can gain the following benefits:\n\nSafer trading for DEFI users (no front-running)\nAdded censorship resistance (even for centralized sequencers)\nMore profitable trading for DEFI users (because less value lost due to malicious MEV)\nSequencer can plausibly argue that they no longer have the ability to front-run transactions nor censor transactions based on their content by design (potential compliance, image and regulatory benefits for the sequencer operator)\nSequencer still retains the ability to collect or distribute back-running related MEV (arbitrage and liquidations)\n\nThis document begins with a goals/motivation section, then presents a two-phase process for defining the architecture of a threshold encryption-based front-running protection mechanism for the OP Stack and Bedrock codebase, leveraging the Shutter Network.\nThe process starts with Phase 1, where high-level, solution-agnostic requirements for the mechanism are defined. This phase is primarily driven by the perspectives and needs of the end users and the sequencer, with requirements categorized by actors in the system.\nFollowing this, Phase 2 transitions to defining Shutter-specific requirements, focusing more on the details of the proposed implementation. These requirements are categorized by expected technical components in the system.\nIt then outlines the user interaction with the system, followed by the core of the document, the technical architecture section. Within this section, the technical components and code modifications are outlined, a transaction flow diagram is given, among other things.\nThe document closes with a conclusion and future considerations.\nProblem Statement\nThe rising popularity of Ethereum’s open finance (DeFi) ecosystem has led to an increasing amount of maximal extractable value (MEV). Unfortunately, it has also exposed the network to potential exploitation through front-running and other MEV-related tactics, which can deter prospective investors and traders. Furthermore, the measures put in place to manage this issue have proven to be suboptimal, introducing unnecessary trust assumptions and centralization factors. For instance, MEV relays, though beneficial for market health, require a high degree of trust, making them unsustainable in their current form. To unlock the billions in side-lined investment and ensure Ethereum’s long-term base layer neutrality, an effective approach to transaction ordering and inclusion is required.\nMalicious MEV and Censorship\nFront-running and malicious MEV extraction pose significant threats to Ethereum’s ecosystem. Front-running involves the unethical practice of a broker executing orders on a security for its own account while taking advantage of advance knowledge of pending orders from its customers. On Ethereum, this has resulted in a measurable amount of value extraction from users. MEV relays, which were introduced as a solution, unfortunately introduce centralization risks due to the required high degree of trust.\nThis tendency to centralize parts of the transaction supply chain infrastructure not only adds censorship vectors but also facilitates actual censorship on the protocol level, as evidenced by instances of adherence to sanctions lists such as the Office of Foreign Assets Control (OFAC) list.\nMEV and Censorship on Layer 2 (L2)\nLayer 2 solutions, which aim to scale Ethereum’s network by processing transactions off the main blockchain, face a similar yet distinct set of challenges. Here, the problem lies in the private mempools and potential spamming issues. Currently, rollup sequencers — responsible for collecting and submitting transactions on L2 — are trusted not to extract MEV. However, this centralized approach could potentially amplify the MEV issue in the long term. To avoid front-running, we place our trust in the sequencer, inadvertently consolidating their power, thus creating an unsustainable and censorship susceptible system.\nRegulatory Implications\nThe regulatory landscape poses another challenge. Regulatory bodies worldwide have begun to clamp down on front-running, potentially categorizing sequencers who extract malicious MEV as financial intermediaries, rather than purely technical entities. This could complicate compliance, as financial intermediaries are subjected to stringent regulatory requirements. Consequently, without proper management of MEV, Ethereum could face stricter regulations, deterring users and stifling growth in the DeFi sector.\nMEV mitigation solutions overview\n\nProposer Builder Separation (PBS): Proposer-builder separation (PBS) is a proposed upgrade for Ethereum that divides the tasks of creating and broadcasting blocks between multiple validators, enhancing censorship resistance, preventing hobbyist validators from being outcompeted by institutional players, and aiding Ethereum’s scalability; it also reconfigures the economics of maximum extractable value (MEV), allowing any validator to benefit from sophisticated MEV extraction performed by block builders.\nMEV Auctions (Optimism MEVA): Optimism MEVA is a proposal for an auction-based system where proposers bid for the right to order transactions within a block, reducing the potential for MEV extraction.\nMEV Revenue Sharing Approaches: These approaches involve mechanisms that redistribute MEV to various stakeholders, thus diminishing the potential profits from malicious extraction.\nTrust in Sequencer or MEV Relay to Not Front-run: This approach depends on the trustworthiness of a sequencer or MEV relay to act in the best interests of users and not engage in front-running.\nEncrypted Mempools: Encrypted mempools are a way to hide transaction information until it is included in a block, preventing front-running and other MEV extraction tactics.\n\nSolution Comparison Table\n\nSolution\nReduces or Redistributes MEV?\nTrust Requirement\n\nProposer Builder Separation (PBS)\nRedistributes\nSeparates trust requirements\n\nMEV Auctions (e.g. Optimism MEVA)\nRedistributes\nDepends on specific implementation\n\nMEV Revenue Sharing Approaches\nRedistributes\nUsually introduces additional trust requirements\n\nTrust in Sequencer or MEV Relay to Not Front-run\nReduces\nIntroduces additional trust requirements\n\nEncrypted Mempools\nReduces\nReduces trust requirements\n\nIn conclusion, a comprehensive solution to the MEV problem may involve a combination of multiple strategies. For instance, encrypted mempools could be used to significantly reduce malicious MEV, and then redistribution frameworks such as Optimism MEVA could be applied to manage the remaining MEV. The goal is to balance the need for trust with the potential to reduce or redistribute MEV effectively.\nOP Stack\nThe OP Stack, managed by the Optimism Collective, is a standardized, shared, and open-source development stack that fuels Optimism. Currently powering the Optimism Mainnet, it’s expected to evolve and shape the Optimism Superchain and its governance. Its design promotes a shared, high-quality system for creating new L2 blockchains, minimizing the need for siloed software development.\nThe “Optimism Bedrock” is the latest iteration of the OP Stack, providing tools to launch production-quality Optimistic Rollup blockchains. It’s designed to support the Optimism Superchain, a proposed network of L2s that share security, communication layers, and a common development stack.\nAs an evolving concept, the OP Stack will grow and adapt with Optimism, aiming to simplify the deployment of new L2 Rollups and foster interoperability among different chains within the Superchain ecosystem. For those interested, resources are available to explore the OP Stack further and launch a Superchain-ready L2.\nShutter Network\nShutter is an anti-frontrunning, malicious MEV-preventing protocol using threshold encryption. It’s intended to be used as a plugin by any L1/L2 protocol to provide front-running and censorship resistance via implementing a shielded/encrypted mempool.\nShutter incorporates a Distributed Key Generation (DKG) scheme into an L1 or L2 rollup sequencer mechanism to protect all dapps deployed on the rollup by default while also improving censorship resistance and potentially latency properties. In principle, it operates by making the sequencer accept encrypted transactions in their blocks and revealing and executing them only once they are ordered.\n\n read \n\n 13\n min\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Participant Requirements\nThis section defines requirements for a threshold encryption-based front-running protection mechanism for OP Stack and Bedrock. They are high-level, solution-agnostic, and primarily driven by the perspectives and needs of the participants in the system who are as follows:\n\nEnd users: These are individuals who interact with the system, usually by submitting transactions.\nOptimism sequencer: The Optimism sequencer is a component of the Optimism rollup architecture, responsible for ordering and executing transactions by building new rollup blocks.\nOptimism rollup node: The Optimism rollup node is a component of the Optimism rollup architecture, syncing the rollup state from the sequencer and the L1 chain.\nDapp project: Dapp projects provide some service to end users and typically consist of a set of smart contracts deployed on the Optimism chain, a browser-based frontend, and potentially additional components.\n\nEnd User\n\nUser experience and security should be comparable to using a Dapp on Optimism today.\nUsers can submit encrypted transactions that cannot be frontrun.\nUsers can still send unencrypted transactions that have the same execution guarantees as before.\nInclusion and execution latency for unencrypted transactions is similar to the status quo.\nInclusion and execution latency for encrypted transactions is not much higher than for unencrypted transactions.\nTransaction fees for unencrypted transactions is the same as the status quo.\nTransaction fees for encrypted transactions is not much higher than for unencrypted transactions.\n\nDapp Project\n\nComprehensive documentation on the front-running protection mechanism is available.\nExisting front-end applications require no to minimal changes to remain compatible.\nA frontend library that handles the encryption, submission, and execution status tracking of encrypted transactions is available.\nUsage of the system requires no additional networking besides the existing JSON RPC interface.\n\nOptimism Rollup Node\n\nSetup and operation of the rollup node should be similar to the status quo.\nAdditional computational overhead of decrypting transactions does not significantly impact hardware requirements.\nError handling and reporting mechanisms for issues related to transaction decryption or processing are reliable and robust.\nThe node can scale in response to increased demand for encrypted transactions.\nFailures are handled gracefully.\n\nOptimism Sequencer\nThe sequencer inherits the rollup node requirements.\n\nThe sequencer can plausibly argue that they no longer have the ability to front-run transactions by design.\nThe sequencer can plausibly argue that they no longer have the ability to censor transactions based on their content by design.\nEncrypted and unencrypted transactions are processed within the same pipeline.\nThe sequencer can reject encrypted transactions if they do not pay an appropriate fee, taking into account the cost of both storing it on L1 as well as executing it.\n\nComponent Requirements\nThis section defines requirements for a concrete instantiation of a threshold encryption-based front-running protection mechanism, leveraging the Shutter Network. It first defines the main software components generally needed for such a system and then states requirements on them.\nThe technical components in the system are as follows:\n\nOptimism rollup node: The rollup node reads the L2 state from the sequencer’s unsafe sync and occasionally compares it with the L2 state locally derived from L1 sequencer batches and deposit data. The rollup node also propagates unsafe, safe and finalized block data within a P2P network. It uses the same software as the sequencer but in a different mode of operation and as a different entity in the Optimism system.\nOptimism sequencer node: The sequencer accepts transactions via a (private) mempool and integrates them in new L2 sequencer batches, which will eventually be included in an unsafe block,persisted on L1 and later included in a finalized block.\nKeyper set: The keypers run a distributed key generation (DKG) protocol. This process outputs a single public key as well as one secret key share for each participant. From the public key, encryption keys can be derived. The keypers can compute the corresponding decryption key in a collaborative manner. The process assumes that at least a certain fraction (e.g. 2/3) is honest and online.\nFrontend library: The frontend library helps Dapps to use encrypted transactions in the user interface.\n\nFunctional Requirements\nOptimism Rollup Node\n\nThe rollup node reads decryption keys from the chain.\nThe rollup node verifies correctness of decryption keys.\nThe rollup node decrypts encrypted transactions included in the chain with the decryption key.\nThe rollup node executes decrypted transactions in the order that the sequencer has arranged the corresponding encrypted transactions in the block.\nThe changes do not affect inclusion and execution of deposit transactions.\nThe state does not progress without decryption keys to prevent frontrunning.\nThe system provides a mechanism to indefinitely stop execution of encrypted transactions in case the keypers fail to produce decryption keys.\nThe rollup node implementation is based on the OP Mainnet node with minimal modifications.\n\nOptimism Sequencer Node\n\nThe sequencer accepts both plaintext and encrypted transactions through the existing mempool.\nThe sequencer chooses to include encrypted transactions in a block if they pay a fee appropriate to its resource requirements at both inclusion and execution time.\nThe sequencer has a guarantee at inclusion time that encrypted transactions pay a fee for their execution.\nThe sequencer receives decryption keys from the keypers and includes them in their blocks after validating them.\nThe sequencer does not store state in memory that if lost would prevent the chain from making progress.\nThe sequencer implementation is based on the OP Mainnet sequencer with minimal modifications.\n\nKeyper\n\nThe keypers generate a public key used to derive encryption keys and broadcast it on L2.\nThe keypers read the keyper set membership and peer information from a contract on L2.\nThe keypers generate the decryption keys for encrypted transactions.\nHardware requirements should allow running a keyper node on a consumer grade laptop given access to an external rollup node.\nIn order to circumvent sequencer censorship, the keyper is able to send deposit transactions via L1.\nThe keyper software is implemented in Go.\n\nFront End Library\n\nComprehensive documentation of the library API and usage patterns exists\nThe library exposes a small API surface and hides away implementation details\nThe library integrates well with existing commonly used front-end libraries.\nThe library is implemented in JavaScript or TypeScript.\n\nNon-functional Requirements\nDisclaimer: At this stage in the architectural planning process, these are provisional estimates for non-functional requirements and are subject to change.\n\nAt least 20 keypers\nNew epoch every 4 seconds.\nInclusion confirmation within one block.\nExecution confirmation for unencrypted transactions within one block.\nExecution confirmation for encrypted transactions within two blocks.\nNo gas overhead for unencrypted transactions.\nLess than 3x gas cost for a typical encrypted transaction.\n\nTechnical Architecture of Shutterized Optimism\nOverview\nThe main addition to the stack is the set of keypers, a committee responsible for generating keys that will be used to encrypt and decrypt transactions. Its members are managed by a contract on L2, the Keyper Set Contract. In a one-time setup phase, they generate the so-called eon public key and broadcast it via the Key Broadcast Contract.\nIn addition to standard transactions, the system allows users to send encrypted transactions that will be protected from frontrunning and censorship. To do so, users have to first create the payload (consisting of receiver, calldata, and value) and then encrypt it with the eon key. They then submit the encrypted payload to the Shutter Inbox Contract via a so-called Commit Transaction. The contract stores the payload in its storage and charges the user a fee which covers the gas the scheduled transaction is going to use when being executed. The amount is derived from the gas price as well as a user-provided gas limit and sent via the Commit Transaction’s value field.\nWhenever the sequencer seals a block, the keypers collaboratively generate the decryption key for it and broadcast it on a P2P network. The sequencer picks it up and puts it – in the form of a so-called Reveal Transaction – at the front of the block. Executing this transaction will result in all encrypted transactions that have been scheduled previously being read from the ShutterInbox Contract, being decrypted and executed.\nThe state transition function ensures that the sequencer plays by the rules, i.e., that blocks fulfill the structure outlined above. In particular, blocks without a decryption key at the top (or an incorrect one) are invalid.\nblock-diagram961×205 27.2 KB\nInternal structure of blocks: Time increases from left to right, with decryption processes between the blocks. Inside of the block structure, transactions are executed in a left to right order. Decrypted payloads committed one block earlier are executed within the “Reveal Transaction” at the beginning of the block. (high res)\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Components\nKeyper Set\nThe keyper set is a threshold-committee consisting of at least 20 members. During a setup phase, the keyper set generates the eon public key and broadcasts it. This key will be used by users to encrypt payloads. After each block produced by the sequencer, the keyper set generates a decryption key that can be used to decrypt these payloads.\nIt is assumed that at least a certain number of keypers – the threshold – is online and behaves honestly. If not, they can produce decryption keys before the corresponding block has been produced and use this advance knowledge to frontrun in collusion with the sequencer.\nSequencer\nThe job of Optimism’s sequencer is to receive transactions from users, build blocks, broadcast them, and submit them to L1. In addition to that, this proposal requires them to listen on a P2P network for decryption keys from the keypers and produce blocks with slightly altered rules.\nSystem Contracts\nThe system relies on a small suite of smart contracts deployed on L2:\n\nThe Keyper Set Contract: Manages the set of keypers.\nThe Key Broadcast Contract: Acts as a billboard on which keypers can publish the eon public key.\nShutter Inbox Contract: Collects encrypted payloads and metadata submitted by users in the form of Commit Transactions.\n\nClient Library\nThis frontend library provides functions for Dapps to easily\n\nretrieve the eon public key from the Key Broadcast Contract,\ncreate and encrypt payloads,\nsubmit them to the Shutter Inbox Contract via Commit Transactions, and\nbe notified when they are included as well as decrypted and executed.\n\ncomponents824×682 60.2 KB\nDiagram of the different components making up the Shutterized Optimism System. Arrows indicate the data flow starting with the user submitting a plaintext as well as an encrypted transaction and ending with it being executed on the chain. Numbered text over arrows describe successive steps in the block building process. (high res)\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Code Modifications\nThis section describes the main modifications that have to be implemented on top of the existing OP Stack and Bedrock codebase. In addition, it describes the required system contracts.\nShutter Inbox Contract\nThe central system contract is the Shutter Inbox Contract. It exposes the commit function which can be called by standard Ethereum transactions. In the following, those are named Commit Transactions.\nThe user encrypts a payload, consisting of data, value and to fields, and attaches this in serialized form as an argument to the commit call. Additional arguments are the future block-number when the transaction has to be executed as well as the estimated gas-limit for the execution. The Commit Transaction has to include an ETH-transfer to the contract via the transaction’s value field, so that the amount is equal to the gas-limit argument multiplied by the gas-price of the Commit Transaction.\nThe contract will store a FIFO-queue of the passed in arguments together with the sender address in its storage. The contract makes sure that the cumulative gas-limits of the queue can never surpass the block-gas-limit, otherwise the contract call fails. In order to keep the total state-growth constant, the contract will only accept and enqueue transactions where the block-number argument equals the next block number, and the contract will delete all previous transactions from the queue once they are handled in the Reveal Transaction. The accumulated gas transferred to the contract via the Commit Transactions can be withdrawn by a configurable account, e.g. the sequencer or a DAO.\nKeyper Set Contract\nThe Keyper Set Contract manages the current keyper set. It allows an owner, e.g. the OP DAO, to add and remove members at will at certain block numbers. The keyper set contract also defines an emergency shutdown mechanism described in more detail in the “Potential Issues and Solutions” section.\nKey Broadcast Contract\nThe Key Broadcast Contract is a simple billboard that allows any keyper set to broadcast its eon public key after they generated it. Users can fetch it from there.\nEngine API\nIn order to include the decryption key in the block and make it available in the state-transition-function (STF), it has to be passed from the receiving end (op-node) to the block-building engine in op-geth. Therefore the EngineAPI payload-attributes for the engine_forkChoiceUpdatedV1 have to be extended to include a decryption-key field.\nop-node\nThe op-node is responsible for initiating the construction and release of new blocks in the op-geth node in regular intervals. It does so by continuously adding transactions to the block candidate at all times. This process now has to be paused briefly after each proposed block until the keypers have produced the decryption key.\nConcretely, the time between a sequencer’s unsafe head update and the successful keyper-decryption process blocks the execution of the next call to engine_forkChoiceUpdatedV1. Since the decryption key generation time is variable, the op-node adjusts the time for successive calls to engine_getPayloadV1 / engine_newPayloadV1 in order to keep the overall block time constant.\nThe op-node additionally communicates with the set of keypers by operating a libp2p module that connects to the keypers and subscribes to a decryption-key topic via the gossipsub protocol. The op-node has to have access to the current layer 2 blockchain state, in order to verify keyper-set membership and the validity of received decryption keys.\nop-geth\nThe miner in op-geth is responsible for assembling new blocks. To do so, it picks transactions from the sorted mempool as well as deposit-transactions received from the op-node via the payload-attributes of the EngineAPI.\nBlock-building is initiated by the op-node via the Engine API. In this process, additional constraints have to be fulfilled and considered for block validity. It requires the decryption key for transactions included in the previous block, which the miner receives via the payload-attributes from the op-node.\nThe first transaction to be executed in the block’s state-transition function is the special Reveal Transaction. It is exclusively assembled by the miner and contains the decryption key. It fetches the encrypted payloads for this block from the Shutter Inbox Contract and decrypts them. Subsequently, it executes it, taking the corresponding metadata fields sender and gas limit into account. Note that the gas for the transaction has already been paid for by Commit Transaction.\nAfter successful execution of the decrypted payload, the resulting events of all decrypted transactions are included in the receipt of the Reveal Transaction. In the remainder of the block, the miner includes new transactions from the mempool as usual, including Commit Transactions for the next block. The miner takes the execution gas limit of the latter into account in the scoring function used for mempool ordering.\nblock-building1004×1142 74.3 KB\nSequence diagram of the block building process. Two iterations of block building are shown - in the first, only the inclusion of normal transactions is shown in detail. In the second, only the inclusion of the Reveal Transaction is shown in detail. “NextBlock” represents the current locally built block within the sequencer’s memory. “Layer2State” represents the publicly visible unsafe head state of the layer 2 blockchain. (high res)\nUser Interaction\nThe user experience of using encrypted transactions is very similar compared to normal ones, and involves only a few additional steps in the transaction submission and status notification process. When using a specific Dapp frontend, an action that posts a transaction to the blockchain will be handled in the following way:\nThe user will be informed beforehand that the gas mechanism of this transaction is handled differently and the value transferred to the inbox contract is a pre-payment of gas for execution of the revealed transaction. In the background, the Dapp will locally handle the gas estimation of the payload, eventually fetch the relevant encryption inputs from the L2 chain, and encrypt the payload.\nThe Dapp then constructs a normal Ethereum transaction that calls the commit function of the Shutter Inbox Contract and adds the calculated execution-gas to the transaction’s value field.\nNext, the Dapp will ask the user’s wallet to send the transaction, which in turn will prompt the user to sign it. Finally, the wallet will submit the signed transaction to the Optimism JSON RPC endpoint.\nThe Dapp will then continuously show the current execution status of the user’s transaction – but execution confirmation will take longer than usual: As a first pre-confirmation, the Dapp will check the layer 2 chain for successful inclusion of the Shutter Inbox call in the latest block. As soon as the Commit Transaction has been included, the user will see the status of the transaction as “committed, waiting for decryption and execution”.\nOnce the corresponding decrypted payload is found in the Reveal Transaction of the next block and executed successfully, the user will see the status of the transaction as “revealed, successfully decrypted and executed”. The Dapp may read the receipt of the Reveal Transaction and construct more detailed information on the transaction’s execution. Among others, this receipt indicates if execution was successful or if it reverted, e.g. due to running out of gas.\nIn case the Reveal Transaction receipt does not contain a trace of the decrypted payload, it was invalid.\nInteraction With Decentralized Sequencers\nDecentralized Sequencer and MEVA designs are largely orthogonal to this proposal. The only requirements for Shutterized Optimism on the block proposal mechanism are that they come with a certain degree of finality, or achieve it quickly over time (without additional blocks).\nFinality Assumption\nThe system assumes that unsafe heads are final, as the keypers release the decryption key immediately upon observing them. If they are not, i.e., if a malicious sequencer can create a competing fork, this sequencer would be able to frontrun. Note that this attack would be both provable and attributable. We therefore recommend that the sequencer has to deposit a stake that will be slashed in case the sequencer attempts this attack.\nPotential Issues and Solutions\nLiveness Failures\nThe main failure to consider is a liveness failure caused by the keypers not producing the decryption key. This would prevent the sequencer from proposing the next valid block. For this scenario to take place, Shutter’s threshold assumption has to break: More than 1 - t keypers have to be offline, where t is the threshold parameter.\nTo recover from this and similar types of failure, Shutter can be disabled by a smart contract emergency switch. In that case, the rollup’s operation would fall back to standard Optimism mode. In particular, this would allow the sequencer to produce a block without including the decryption key, so that the system can continue to make progress. This cannot be used to frontrun as encrypted transactions will never be decrypted nor executed. Various options exist for which entities could trigger the emergency switch: The sequencer, OP governance, Shutter governance, or a subset of the keyper set itself. In addition, the switch could be conditional on the duration in which no block has been produced.\nLatency\nEncrypted transactions are executed over the course of two blocks (commit in some block, reveal in the next). Naturally, their latency until execution increases by a factor of two. Latency until inclusion of the Commit Transaction is still only a single block (note that inclusion guarantees later execution). Standard transactions are largely unaffected by Shutter, so they will still be included and executed in the next block.\nHowever, building a block now involves generating the decryption key. Since this is carried out in a distributed manner over a P2P network, the default block time may have to be increased. The exact number will depend on the number of keypers and network latency, but a cautiously optimistic estimate is 4s.\nSequencer Side-Channel Attack\nThe design involves a potential issue related to the sequencer’s ability to freely choose block attributes. This control enables the sequencer to affect the execution path of previously committed transactions at a time when they already know the decryption key. This allows them to frontrun.\nFor instance, the sequencer may include a transaction at the top of the block that buys a token on a DEX if the block timestamp is even and sells it if it is odd. As soon as they receive the decryption key, they can decrypt the other transactions, and learn about the resulting price movement over the course of the block. By choosing the timestamp for the next block accordingly (even if it increases, odd if it decreases), they can effectively frontrun.\nThe sequencer can thus potentially gain an unfair advantage by executing transactions based on privileged information before other participants.\nAs a possible prevention mechanism, the sequencer has to commit to all variable block parameters already in the previous block. In order to prevent any degrees of freedom in the block attributes, the sequencer has to pre-commit to the block attributes difficulty, layer1-origin-hash, coinbase, and timestamp.\nHowever, this step has to be carefully considered in order to make sure normal operation is not negatively affected.\nDesign Options\nBlock or Transaction Keys\nShutter uses an identity-based encryption scheme. This means that the encryption key is derived from the eon public key and an identity, an arbitrary parameter. This parameter is also used when the corresponding decryption key is generated. There are two major options how to choose the identity:\n\none identity per block (e.g., the block number)\none identity per transaction (e.g., a custom nonce)\n\nThe advantage of block keys is efficiency: Only a single decryption key per block has to be generated and included in each block. However, they have a negative UX impact: Before sending a transaction, users have to figure out what the identity value of the next block will be (or rather, the identity value of the block in which they want their payload to be executed). This can be difficult if network latency is high and may lead to higher confirmation times if users have to estimate more conservatively. In addition, encrypted payloads will be revealed even if the transaction is not included at all, e.g., due to high latency, network congestion, or a malicious sequencer. Note however, that an already revealed transaction can not be included later on, so this does not make the transaction susceptible for frontrunning.\nTransaction keys, on the other hand, can be derived purely locally without any knowledge over the state of the system. This makes the user experience maximally straightforward and prevents revelation without inclusion. On the other hand, the system is less efficient because for each transaction a separate key has to be included.\nFuture Considerations\nFor the purpose of this proposal, practicality and low implementation complexity were primary goals. When these become less important in future versions, more options open up. Here we describe three.\nInstead of including encrypted transactions in the chain and decrypting them during execution, it is possible to do the opposite: Only commit to a hash of all encrypted payloads, and at time of execution only include the decrypted payloads. As part of the state transition function, the payloads would be encrypted again in order to check correctness against the commitment. This approach is more efficient: Decrypted transactions can be compressed much better than encrypted ones, so they use less of the expensive L1 space.\nThe main drawback of this, however, is a much higher complexity in the sequencer: They need to keep track of which transactions they have committed to in the previous block. If they lose this data, e.g., during a crash at an inconvenient time, they will be unable to produce a valid block and the system is stuck.\nZero knowledge proofs are another potential tool to increase efficiency: A zkSNARK that proves correct decryption would allow omitting the decryption keys from the chain altogether, thus severely limiting the L1 footprint of the system, in particular if transaction keys instead of block keys are chosen. Furthermore, users could use zero knowledge proofs to make statements about their account balances without revealing the sender account, which in the current system is leaked to potential attackers. Unfortunately, zero knowledge technology is still somewhat complex.\nLastly, a potential modification to make reorg attacks by the sequencer much harder is to involve the keyper committee: In addition and simultaneous to the decryption key generation, they could produce a threshold signature on the current head of the chain. The state transition function would check this signature in order to make sure that no reorg has happened. In order to successfully attack, the sequencer would thus not only have to produce a competing block, but also require the keypers to sign it off.\nConclusion\nIn this document, we have proposed modifications to the OP Stack to provide front-running protection and censorship resistance to its users. The required changes are relatively small in scale, not overly complex, and viable to implement.\nWe have evaluated failure cases and outlined robust solutions for such scenarios, with the legacy system always serving as a fallback point to recover to, even in the worst-case.\nNotably, the proposed architecture does not compromise the user experience of normal transactions, while also providing an only slightly diminished user experience for front-running protected transactions. Importantly., it is possible to submit encrypted transactions with standard wallets, requiring only small frontend modifications that can be implemented straightforwardly by using a provided library.\nOverall, the outlined software architecture lays a solid foundation for a front-running protection system, balancing practicality, complexity, and security.\n\n post by Jannik on Jul 5, 2023\n\n Jannik\n\n Due to character limits, we had to split this up into multiple posts. Here’s the whole document as a PDF.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP as an MEV staking token\n\n ✨ General\n\n Hi everyone, I wanted to make an alternate proposal than Enabling $OP as a gas token on Optimism Network!. This is an approach which mirrors PoS as well as Fuel Labs. \nThis is not a token price scheme, please read the fu…\n\n read more\n\n 13\n\n 3.8k\n\n Aug 2022\n\n The Future of Optimism Governance\n\n Metagovernance\n\n The Optimism Foundation recently published this as a post on our Mirror blog. We’re reposting here in full for feedback and discussion from the community. \n\nThe Future of Optimism Governance\nThe Optimism Collective is g…\n\n read more\n\n 22\n\n 5.0k\n\n Nov 2024\n\n Upgrade Proposal #14: Isthmus L1 Contracts + MT-Cannon\n\n Technical Proposals\n\n Proposal Title: Upgrade 14: Isthmus L1 Contracts + MT-Cannon\nProposal Type: Protocol upgrade\nThis proposal is intended to be voted on in Cycle 35 \nExecutive Summary\nHi, I’m Lewej, a Technical Program Manager at OP Labs. …\n\n read more\n\n 13\n\n 894\n\n Apr 2025\n\n Proposal to pause Governance Fund voting cycles till minimum viable decentralization is achieved\n\n Metagovernance\n\n Optimism is experiencing rapid growth, but this is a double-edged sword. Currently, Optimism is a centrally operated network where, as far as I’m aware, unknown entities across Optimism Foundation, OP Labs or associates …\n\n read more\n\n 26\n\n 5.5k\n\n Dec 2022\n\n Infrastructure & Dependencies nominations for RPGF2\n\n Retro Funding Missions\n\n round-2\n\n Infrastructure & Dependencies nominations for RetroPGF2\nThis is the thread to nominate projects for the Infrastructure and dependencies category of RetroPGF round 2. Please familiarize yourself with the Nominations proce…\n\n read more\n\n 120\n\n 12.7k\n\n Jan 2023","tokens":10309,"squid":"ink-governance","role":"Council Listener","at":1791267581822,"hash":"0423958aa8bd420e724d9495a40c8607003c688d"}
{"url":"https://io.net/blog","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudio.net blogThree years of building the future of AI computeIO.NET Team / Jun 12, 2026On June 11, 2023, io.net launched with a straightforward idea. AI workloads need more compute than centralized hyperscalers can ever deliver, and the solution would be a decentralized network of GPUs, not another mega data center, that turns underutilized capacity into on-demand infrastructure.\n\nThree years later, we’ve fundamentally changed the AI compute market. io.net is now the largest decentralized GPU network in the world. Thousands of GPUs distributed globally, with $8 million in enterpriA new tokenomics for a new era: The IDE is now liveIO.NET Team / Jun 11, 2026Three years ago, we started io.net with a simple, powerful belief that the infrastructure behind AI shouldn't be in the hands of a few giant corporations. Today, we're taking a huge step toward making that vision a reality.\n\nAs we celebrate our third anniversary, we're excited to announce the official launch of the Incentive Dynamic Engine (IDE). It's a new way of thinking about our tokenomics that ties the supply of $IO directly to how much people are actually using the network. We'll be permanLatestSee AllOpen Weights Aren't Enough: Why the Compute Layer Decides Your AI Lock-InIO.NET Team / Sep 30, 2026The most important AI infrastructure decision in 2026 is not which model scores highest on MMLU. It is whether the model you deploy creates a new dependency on a vendor, a pricing tier, or a compute layer that trades one form of lock-in for another. \n\nThe open-vs-closed line has shifted enough over the past 18 months that the old framing (\"open models are catching up to closed ones\") no longer captures what's actually happening. For many workloads, open-weight models from Llama, DeepSeek, Z.ai, The $30 Trillion AI Infrastructure Problem We Might Be Solving the Wrong WayIO.NET Team / Sep 29, 2026We’re told that AI's compute crisis is a supply problem. That is, simply not enough GPUs exist. \n\nAWS is reportedly planning millions more chips, NVIDIA is backing gigawatt-scale \"AI factories,\" and analyst estimates suggest a capex supercycle unlike anything the industry has seen. \n\nWhile a global chip count shortage would seem to be the most likely suspect for AI workload constraints, the truth has a bit more layers. In fact, a significant fraction of existing GPU capacity actually sits idle. Idle Capacity vs. New Capacity: A Different Energy Math for AI ComputeIO.NET Team / Sep 24, 2026AI's power problem has two very different answers, and the industry is currently sprinting toward only one of them. Understanding the distinction matters for anyone making GPU sourcing decisions in 2026, because the math on each path looks very different depending on where you stand.\n\nThe dominant industry response to AI's energy demand is new-build in the form of gigawatt-scale campuses, dedicated power infrastructure, long-term purchase agreements. That approach adds supply by constructing it AI Safety Is Not the Same as AI AccountabilityIO.NET Team / Sep 21, 2026When a small number of organizations control the infrastructure that makes frontier AI possible, control the models that run on that infrastructure, and then volunteer to grade their own safety commitments, you do not have a safety framework. That matters more than almost any technical question currently dominating the AI discourse, and it's the one least likely to be surfaced by the parties with the most to gain from blurring it.\n\nThe pattern is worth examining structurally. A handful of frontiThe Time-to-First-Token Trade-Off: Why Not Every Inference Workload Needs Sub-100ms LatencyIO.NET Team / Sep 18, 2026Time-to-first-token (TTFT) measures the delay between submitting a prompt and receiving the first output token, or the pause a user watches before text starts streaming onto their screen. In 2026, TTFT has become a primary marketing axis for a wave of inference-focused providers: Groq's LPU architecture, Nebius, Nscale, and others position low TTFT as a core differentiator, and for real-time, human-facing workloads, they're right to.\n\nA voice agent that takes 4 seconds to start speaking feels brWhy AI Agents Break Traditional Cloud Provisioning ModelsIO.NET Team / Sep 15, 2026One of the great ironies of AI infrastructure is that AI agent workloads are structurally incompatible with how hyperscalers sell compute. The reserved-instance model designed for sustained, predictable throughput collapses under the weight of agentic pipelines that spin up 40 workers in 90 seconds, run them for 7 minutes, then need zero capacity until the next trigger fires. That’s some extremely annoying architectural friction that anyone building an AI model or incorporating it into their exiAISee AllThe Token Cost Paradox: Why cheaper inference doesn't mean cheaper AI billsIO.NET Team / Aug 27, 2026The AI budget conversation is the hot topic this year. So, it’s safe to say that If you've probably heard some version of this line: token costs are falling fast and AI is about to get a lot cheaper. \n\nIt's a reasonable proposition. You want to believe it. But according to Gartner's own research, it’s a notion that is mostly wrong for the people actually paying the bills.\n\nGartner's forecast, published this spring, makes some other striking proclamations. By 2030, they believe that running inferWhat happens when you can't get a GPU? The hidden cost of cloud wait timesIO.NET Team / Aug 18, 2026Let’s imagine that you’ve budgeted $10,000 for an AI/LLM training run. You hop on  AWS and the app says, “no H100s available for 72 hours”. Apart from some stress and frustration, what does that delay actually cost your team?\n\nIn answering that question, perhaps like Thanos, when asked by Dr. Strange how much it cost to collect the infinity rings, he replied: “Everything”. All joking aside, most finance models would record “zero”. There’s no invoice because you’ve consumed no GPU-hours. Your $10Who Decides What Your AI Can Say? Inside Model Censorship and AlignmentIO.NET Team / Aug 15, 2026When you ask an AI to help with something and it refuses, that refusal didn't happen by accident. Someone, or more precisely, a team of researchers, lawyers, and ethicists at a major AI lab, made a deliberate choice to build that boundary into the model. Today, major model providers (e.g. OpenAI, Anthropic, Google, Meta, Mistral, and Cohere) each maintain their own alignment teams, each with distinct values, risk tolerances, and commercial pressures shaping what their models will and won't do. TFinanceSee AllWhat happens when you can't get a GPU? The hidden cost of cloud wait timesIO.NET Team / Aug 18, 2026Let’s imagine that you’ve budgeted $10,000 for an AI/LLM training run. You hop on  AWS and the app says, “no H100s available for 72 hours”. Apart from some stress and frustration, what does that delay actually cost your team?\n\nIn answering that question, perhaps like Thanos, when asked by Dr. Strange how much it cost to collect the infinity rings, he replied: “Everything”. All joking aside, most finance models would record “zero”. There’s no invoice because you’ve consumed no GPU-hours. Your $10Instant Payments via S65olana: How io.net Leverages Blockchain for Fast TransactionsIO.NET Team / Oct 14, 2024io.net is utilizing the Solana blockchain for instant GPU payments, smart contract automation, and secure, decentralized cloud computing transactions.BlockchainSee AllWhat is a GPU Cluster? Beginner's Guide, Cost Calculator, and Buy-vs-Build TipsIO.NET Team / Jun 26, 2026Learn what a GPU cluster is, how it differs from multi-GPU servers, and use our cost calculator to decide if you should build or rent one.GPU Cluster for AI: 2026 Buyer's Guide With Benchmarks & TCO CalculatorIO.NET Team / Jun 8, 2026Your 2026 guide to building a purpose-built GPU cluster for AI. Includes TCO, vendor-agnostic benchmarks, hardware selection (H100/MI300X), and rollout plan.Decentralized Computing in 2025: Architecture, Costs, and Migration GuideIO.NET Team / Jan 20, 2026Complete technical guide to decentralized compute: benchmarks, cost calculator, compliance checklist, and step-by-step migration from AWS/GCP.Quick ReadsSee Allio.net Launches the First Adaptive Economic Engine for Decentralized ComputeIO.NET Team / Dec 11, 2025Discover io.net's Incentive Dynamic Engine (IDE): an adaptive tokenomics model bringing sustainable economics and predictable stability to decentralized GPU compute.New Research Shows Consumer GPUs Can Cut AI Inference Costs by 75%IO.NET Team / Dec 5, 2025New io.net study shows consumer GPUs (RTX 4090) can cut AI inference costs by up to 75% for LLMs, enabling a sustainable, heterogeneous compute infrastructure.How To Stop Being An Ostrich: Creating Real Value With BlockchainIO.NET Team / Nov 12, 2025Blockchain promised to solve centralization, but focused on wrong problems. DePIN networks like io.net finally deliver real value through affordable GPU access.Latest By Topic (135)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsOpen Weights Aren't Enough: Why the Compute Layer Decides Your AI Lock-InIO.NET Team / Sep 30, 2026The most important AI infrastructure decision in 2026 is not which model scores highest on MMLU. It is whether the model you deploy creates a new dependency on a vendor, a pricing tier, or a compute layer that trades one form of lock-in for another. \n\nThe open-vs-closed line has shifted enough over the past 18 months that the old framing (\"open models are catching up to closed ones\") no longer captures what's actually happening. For many workloads, open-weight models from Llama, DeepSeek, Z.ai, The $30 Trillion AI Infrastructure Problem We Might Be Solving the Wrong WayIO.NET Team / Sep 29, 2026We’re told that AI's compute crisis is a supply problem. That is, simply not enough GPUs exist. \n\nAWS is reportedly planning millions more chips, NVIDIA is backing gigawatt-scale \"AI factories,\" and analyst estimates suggest a capex supercycle unlike anything the industry has seen. \n\nWhile a global chip count shortage would seem to be the most likely suspect for AI workload constraints, the truth has a bit more layers. In fact, a significant fraction of existing GPU capacity actually sits idle. Idle Capacity vs. New Capacity: A Different Energy Math for AI ComputeIO.NET Team / Sep 24, 2026AI's power problem has two very different answers, and the industry is currently sprinting toward only one of them. Understanding the distinction matters for anyone making GPU sourcing decisions in 2026, because the math on each path looks very different depending on where you stand.\n\nThe dominant industry response to AI's energy demand is new-build in the form of gigawatt-scale campuses, dedicated power infrastructure, long-term purchase agreements. That approach adds supply by constructing it AI Safety Is Not the Same as AI AccountabilityIO.NET Team / Sep 21, 2026When a small number of organizations control the infrastructure that makes frontier AI possible, control the models that run on that infrastructure, and then volunteer to grade their own safety commitments, you do not have a safety framework. That matters more than almost any technical question currently dominating the AI discourse, and it's the one least likely to be surfaced by the parties with the most to gain from blurring it.\n\nThe pattern is worth examining structurally. A handful of frontiThe Time-to-First-Token Trade-Off: Why Not Every Inference Workload Needs Sub-100ms LatencyIO.NET Team / Sep 18, 2026Time-to-first-token (TTFT) measures the delay between submitting a prompt and receiving the first output token, or the pause a user watches before text starts streaming onto their screen. In 2026, TTFT has become a primary marketing axis for a wave of inference-focused providers: Groq's LPU architecture, Nebius, Nscale, and others position low TTFT as a core differentiator, and for real-time, human-facing workloads, they're right to.\n\nA voice agent that takes 4 seconds to start speaking feels brWhy AI Agents Break Traditional Cloud Provisioning ModelsIO.NET Team / Sep 15, 2026One of the great ironies of AI infrastructure is that AI agent workloads are structurally incompatible with how hyperscalers sell compute. The reserved-instance model designed for sustained, predictable throughput collapses under the weight of agentic pipelines that spin up 40 workers in 90 seconds, run them for 7 minutes, then need zero capacity until the next trigger fires. That’s some extremely annoying architectural friction that anyone building an AI model or incorporating it into their exiWhat AI Teams Need to Vet Before Trusting a GPU Cloud VendorIO.NET Team / Sep 10, 2026Cloud procurement used to be a straightforward infrastructure decision. With GPU cluster growth across various clouds, from hyperscalers to neoclouds and DePIN solutions, that’s just no longer the case. \n\nEnterprise buyers now commit six- and seven-figure compute budgets to providers whose compliance posture, contractual protections, and operational reality vary enormously. This often happens in ways that aren't so obvious from a pricing page or a sales deck. \n\nThis blog is your checklist coveriThe power shortage that supply can’t fix (unless it’s already plugged in)IO.NET Team / Sep 8, 2026The current AI infrastructure conversation has settled on one big number: 38 gigawatts. That's Morgan Stanley's estimated US data-center power shortfall through 2028. What’s creating this shortfall? The GPU compute needed for inference workloads, and what the existing grid can actually deliver to new AI data facilities on any realistic timeline. \n\nHere are some quick numbers. Grid interconnection queues are presently running 5+ years out in most major markets. Add another 2–3 years for transformThe vendor lock-in tax: What 94% of IT teams worry aboutIO.NET Team / Sep 3, 2026Vendor lock-in used to be the province of IT departments. Now it’s a real budget risk. According to widely-cited survey data, 94% of IT professionals report concern about vendor lock-in. For anyone dealing with AI infrastructure, that worry is about to get more expensive. \n\nOn August 26, 2026, AWS announced an expanded multi-billion-dollar commitment to Nvidia GPU capacity that cemented the hyperscaler-as-gatekeeper model. It did so at precisely the moment AI workloads are scaling the fastest. WGPU Orchestration vs. GPU Rental: Why Most Decentralized Networks Are Just MarketplacesIO.NET Team / Sep 1, 2026You don't need one GPU. You need 32 GPUs that talk to each other like they're in the same rack.\n\nEvery DePIN network’s GPU marketing leads with price per GPU-hour. They publish comparison tables showing their H100 rates against AWS, their A100 spot costs against GCP, or their RTX 4090 per-second billing against Azure. Read between the lines and that marketing suggests that cheaper access to hardware is equivalent to actually usable infrastructure.\n\nWell, it isn't that simple. At least not for thThe Token Cost Paradox: Why cheaper inference doesn't mean cheaper AI billsIO.NET Team / Aug 27, 2026The AI budget conversation is the hot topic this year. So, it’s safe to say that If you've probably heard some version of this line: token costs are falling fast and AI is about to get a lot cheaper. \n\nIt's a reasonable proposition. You want to believe it. But according to Gartner's own research, it’s a notion that is mostly wrong for the people actually paying the bills.\n\nGartner's forecast, published this spring, makes some other striking proclamations. By 2030, they believe that running inferCentralized vs. decentralized AI compute: What every developer should knowIO.NET Team / Aug 25, 2026Anyone who rented a GPU knows the routine. You visit AWS, navigate to a p4d instance, quickly hit a quota wall, file a support ticket, wait three days, and finally get your A100. Or perhaps that’s not your experience. Instead, maybe you got an \"insufficient capacity\" error and moved on to GCP. Either way, you ran your workload and didn't think much about what was happening underneath.\n\nThis infrastructure experience of waitlists, opaque pricing, and quotas is the intentional design of centralizePage 1 of 12","tokens":4127,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267584645,"hash":"02f968d25d8213362bb44d3470a3f46c18a4f9af"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract/11031/6","domain":"forum.openzeppelin.com","title":"Crowdsale contract - Support - OpenZeppelin Forum","text":"Support\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jun 2021\n\n 5 / 5\n\n Jun 2021\n\n Jun 2021\n\n post by quantumcoder on Jun 21, 2021\n\n post by Skyge on Jun 21, 2021\n\n post by quantumcoder on Jun 21, 2021\n\n quantumcoder\n\nThanks a lot for your fast reply \nI have a basic knowledge of how to deploy smart contracts but on the crowdsale contract, I dont know how to grant it the permission to mint new tokens on the token contract. This is my question more precisely.\nAnd here:\nCrowdsale crowdsale = new MyCrowdsale(\n 1, // rate, still in TKNbits\n msg.sender, // send Ether to the deployer\n token // the token\n );\n\nI just need to provide the Token name or the token contract address?\nOtherwise how can it know what token it should interact with?\n\n post by Skyge on Jun 21, 2021\n\n Skyge\n\nYeah, you are right, I think it should be the token contract address.\n\n post by quantumcoder on Jun 27, 2021\n\n quantumcoder\n\n Hello Skyge,\nSorry for the late reply so If I understand well, it should be like this:\nPresale.sol file content\nnew Crowdsale(\n 1, // rate in TKNbits\n MY_WALLET, // address where Ether is sent\n TOKEN_ADDRESS // the token contract address\n);\ncontract MyToken is ERC20, ERC20Mintable {\n mint();\n}\n\ncontract Presale is Crowdsale, MintedCrowdsale {\n constructor(\n uint256 rate, // rate in TKNbits\n address payable wallet,\n IERC20 token\n )\n MintedCrowdsale()\n Crowdsale(rate, wallet, token)\n public\n {\n\n }\n}\n\ncontract PresaleDeployer {\n constructor()\n public\n {\n // create a mintable token\n ERC20Mintable token = new MyToken();\n\n // create the crowdsale and tell it about the token\n Crowdsale crowdsale = new MyCrowdsale(\n 1, // rate, still in TKNbits\n msg.sender, // send Ether to the deployer\n token // the token\n );\n // transfer the minter role from this contract (the default)\n // to the crowdsale, so it can mint tokens\n token.addMinter(address(crowdsale));\n token.renounceMinter();\n }\n}\n\nThen after the crowdsale is created, don’t forget to approve it to use your tokens!\nIERC20(tokenAddress).approve(CROWDSALE_ADDRESS, SOME_TOKEN_AMOUNT);\n\nwhere can I use this type of command:\nIERC20(tokenAddress).approve(CROWDSALE_ADDRESS, SOME_TOKEN_AMOUNT);\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":696,"squid":"ink-security_audits","role":"Sentinel","at":1791267584795,"hash":"a394faef1683b72f0736fc9ccd7b05818b0e7228"}
{"url":"https://gov.optimism.io/t/10845","domain":"gov.optimism.io","title":"[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain \n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n Sep 4\n\n 1 / 5\n\n Sep 4\n\n 27d ago\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions before broadcasting to OP Stack nodes. On EVM rollups, end users and automated agents pay gas fees even when transactions revert on chain due to stale oracle states, localized slippage, or sandwich attacks. For retail users, burning gas on a failed execution creates frustration, and for wallet teams it leads to avoidable support tickets.\nThe proxy sits between standard wallets or clients and public Optimism RPC nodes. When a client issues an eth_sendRawTransaction request, the proxy intercepts the raw payload and simulates it in process using revm against current chain state. If the simulation executes successfully, the transaction is forwarded upstream to the sequencer over an existing hyper connection pool. If the simulation reverts, the proxy aborts the broadcast completely so zero gas is burned on chain, and immediately returns a standard JSON-RPC error containing decoded Solidity custom errors or panic codes along with an estimated gas saved metric.\nThe core implementation is open-source under the MIT license with 40 automated tests passing across the Rust core and TypeScript client SDK. In empirical benchmarks against mainnet.optimism.io, the proxy introduces a minimal 11.8 millisecond processing overhead on fair keep-alive connections with session reuse. For clients that make cold requests without connection reuse, the proxy internal connection pool eliminates repetitive TLS 1.3 handshakes to remote endpoints, amortizing roundtrip latency by roughly 97 milliseconds. The full reproduction methodology and raw telemetry logs are recorded in BENCHMARK_RESULTS.md (https://github.com/Ishant5436/op-sec-proxy/blob/main/BENCHMARK_RESULTS.md).\nUncached transaction simulation over public internet RPC currently averages approximately 2.7 seconds because the execution engine must fetch contract state slots across the network during execution. I am requesting 10,000 OP for an initial builder grant to fund three engineering milestones over the next three months. The initial phase tackles state caching, replacing network RPC state queries with a local in-memory LRU trie cache for warm contract bytecode and storage slots to drive simulation latency down toward a sub-65 millisecond target. Following that, work shifts to developer adoption with a TypeScript provider wrapper and standardized error decoding for wallet integrations. The final phase expands routing across OP Mainnet, Base, Mode, Zora, and Fraxtal alongside reproducible Docker containers and systemd service packaging for node operators.\nAs an individual engineer, I rely on Rust memory safety guarantees, cargo-audit automated dependency scanning, and reproducible GitHub Actions workflows rather than corporate support infrastructure. All code is public and modular. I previously shared an introductory post in the general discussion section of the governance forum under thread 10810 (OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions), and this grant application will allow me to build and package the middleware as a permanent, zero-cost public good for the Superchain ecosystem.\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n 4\n\n post by Anzus_GemWallet on Sep 4\n\n Anzus_GemWallet\n\n From a user-support perspective, how will the proxy handle cases where the local simulation is based on slightly stale state but the transaction might still succeed on-chain? It would be useful to understand whether the default behavior is to fail open, and how the wallet communicates simulation uncertainty versus a definite revert.\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Regarding stale state and transient boundaries, the proxy strictly defaults to fail-open whenever there is execution ambiguity or when a simulation fails due to state retrieval timeouts or RPC sync lags. If the proxy cannot deterministically prove a failure against the current block header, it logs the warning and forwards the raw transaction directly upstream to the sequencer so user submissions are never blocked by middleware latency or momentary node lag.\nFor transaction categorization, the proxy distinguishes between invariant contract panics and state-dependent reverts. Static reverts such as invalid signatures, nonce mismatches, unauthorized access, or insufficient balance are deterministic and will fail regardless of whether the head moved by a block. In those cases, the proxy returns a standard -32000 error with the decoded reason and flags the simulation as definite.\nState-dependent reverts, such as slippage limits on decentralized exchanges or time-sensitive oracle feeds, are where stale state matters most. When revm returns a revert from a condition that depends on volatile storage slots, the proxy includes an uncertainty flag in the JSON-RPC error payload under data.confidence set to uncertain alongside the block number used for simulation. In the TypeScript provider wrapper, wallets can inspect this field to decide how to treat the result. For instance, a wallet can show a clear distinction between a transaction that is guaranteed to revert versus one that failed due to potential slippage drift at the head, or choose to pass uncertain transactions upstream automatically with a warning notice in the user interface.\n\n post by Cypherin on Sep 6\n\n Cypherin\n\n Anzus_GemWallet\n\n A quick update for the review team following up on the discussion above. The simulation confidence classification and fail-open behavior discussed here are now fully implemented and passing in the public repository under commit 8376212.\nWhen revm encounters transient database or RPC connection timeouts, the proxy classifies the execution as uncertain and automatically forwards the raw transaction directly upstream to the sequencer when fail-open is enabled, ensuring zero user drop-offs. If a wallet wishes to inspect or handle the simulation result, the JSON-RPC error payload returns the confidence rating along with decoded contract reverts. The TypeScript client library at @op-sec/client has also been updated with these types, and all unit, integration, and linter checks pass with zero warnings across 32 tests.\n\n post by Cypherin on Sep 8\n\n Cypherin\n\n A quick procedural update for the review team: project metadata and repository ownership verification have now also been completed and published onchain via OP Atlas at https://atlas.optimism.io/project/0x6ab1a8cbf07a602a09c6e754b34361f336ba8e62c1a4792659d7b5ac4a27663b.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n ✨ General\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 107\n\n Sep 4\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Grant Application: superchain-guard\n\n Grants Updates\n\n season-8,season-9\n\n Project Name: superchain-guard — The Security Frontier for Interoperable Intents \nApplicant: ILE Labs (ILE-Labs · GitHub) \nProgram: Season 9 Growth Grants (Infrastructure Category) \n\nExecutive Summary\nOptimism is enterin…\n\n read more\n\n 6\n\n 213\n\n May 19\n\n [MISSION REQUEST] Open-source transaction simulator\n\n Governance Fund Missions\n\n Title: Open-source transaction simulator\nDelegate Mission Request Summary: \nThis mission is intended to provide a key, critical piece of tooling - simulating transactions before they go onchain. Tenderly provides a great…\n\n read more\n\n 3\n\n 522\n\n Aug 2025\n\n Upgrade Proposal #13: OPCM and Incident Response improvements\n\n Protocol Upgrade\n\n Executive Summary\nHi I’m Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej (@0xEscanor) and @Kelvin from the OP Labs Team. \nThis proposal is intended to be voted on in cycle…\n\n read more\n\n 19\n\n 1.4k\n\n Mar 2025","tokens":2224,"squid":"ink-governance","role":"Council Listener","at":1791267592400,"hash":"2c7ce190cca314a88b4fb4d9aa83ef99706fd75f"}
{"url":"https://forum.openzeppelin.com/t/bep20-crowdsale/11666/1","domain":"forum.openzeppelin.com","title":"BEP20 Crowdsale - Smart Contracts / Review Wanted - OpenZeppelin Forum","text":"BEP20 Crowdsale \n\n Smart ContractsReview Wanted\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 2\n\n Jun 2021\n\n 1 / 13\n\n Jul 2021\n\n Dec 2021\n\n post by quantumcoder on Jun 30, 2021\n\n quantumcoder\n\n Hi everyone,\nI am working on a crowdsale project for my first freelance client.\nThe budget is very small(Im trying to build a portfolio) so I cannot do mistakes due to deployment fees.\nI have those two contracts:\nSales contract:\npragma solidity ^0.5.0;\n\nimport \"./Crowdcoin.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/emission/MintedCrowdsale.sol\";\n\n// @TODO: Inherit the crowdsale contracts\ncontract CrowdcoinSale is Crowdsale, MintedCrowdsale {\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin token, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n // @TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, token)\n MintedCrowdsale()\n public\n\n {\n // constructor can stay empty\n }\n}\n\ncontract CrowdcoinSaleDeployer {\n\n address public token_sale_address;\n address public token_address;\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n string memory name,\n string memory symbol,\n address payable wallet // this address will receive all Ether raised by the sale\n\n )\n public\n {\n // @TODO: create the Crowdcoin and keep its address handy\n Crowdcoin token = new Crowdcoin(name, symbol, 0);\n token_address = address(token);\n\n // @TODO: create the CrowdcoinSale and tell it about the token, set the goal, and set the open and close times to now and now + 24 weeks.\n uint goal = 300 wei;\n uint cap = 300 wei;\n\n CrowdcoinSale Crowdcoin_sale = new CrowdcoinSale(1, wallet, token, goal, cap, now, now + 24 weeks);\n token_sale_address = address(Crowdcoin_sale);\n\n // make the CrowdcoinSale contract a minter, then have the CrowdcoinSaleDeployer renounce its minter role\n token.addMinter(token_sale_address);\n token.renounceMinter();\n }\n}\n``\nPresale Token contract:\n``\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Mintable.sol\";\n\ncontract crowdcoin is ERC20, ERC20Detailed, ERC20Mintable {\n constructor(\n string memory name,\n string memory symbol,\n uint initial_supply\n )\n ERC20Detailed(name, symbol, 18)\n public\n {\n mint(msg.sender, initial_supply);\n }\n}\n\nI plan to proceed like this:\n1- Paste the crowdsale contract on remix.ethereum.org in the crowdsale.sol file that I will deploy with bsc\n2- Paste the token on remix.ethereum.org in the crowdcoin.sol file that I will deploy with bsc\nFor the prior two steps, will they automatically work together?\nhow do I link it on my client’s website so the participants can connect their bnb wallets swap directly from the sale webpage?\nThank You in advance !\n\n 4\n\n 4\n\n 2\n\n post by FreezyEx on Jul 1, 2021\n\n FreezyEx\n\n Hey can you tell us about the requirements of the crowdsale? Which features/function must it have?\n\n post by Skyge on Jul 1, 2021\n\n Skyge\n\nI think so, pass crowdcoin as the value for Crowdcoin in the CrowdcoinSale, then CrowdcoinSale can work with crowdcoin.\n\nThis question is about the front-end, you can use metamsk or wallet connect to connect users' wallet, just check the documentation of these plugins.\n\n post by quantumcoder on Jul 2, 2021\n\n post by quantumcoder on Jul 2, 2021\n\n post by Skyge on Jul 2, 2021\n\n post by quantumcoder on Jul 2, 2021\n\n post by zanja85 on Jul 6, 2021\n\n 5 months later\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n post by Skyge on Nov 21, 2021\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n post by Skyge on Nov 21, 2021\n\n 24 days later\n\n post by medolantex on Dec 15, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":1189,"squid":"ink-security_audits","role":"Sentinel","at":1791267595172,"hash":"473dde149908c8d0e7ffd7a5359e91dcbc176699"}
{"url":"https://io.net/blog/all","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudio.net blogLatest By Topic (135)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsOpen Weights Aren't Enough: Why the Compute Layer Decides Your AI Lock-InIO.NET Team / Sep 30, 2026The most important AI infrastructure decision in 2026 is not which model scores highest on MMLU. It is whether the model you deploy creates a new dependency on a vendor, a pricing tier, or a compute layer that trades one form of lock-in for another. \n\nThe open-vs-closed line has shifted enough over the past 18 months that the old framing (\"open models are catching up to closed ones\") no longer captures what's actually happening. For many workloads, open-weight models from Llama, DeepSeek, Z.ai, The $30 Trillion AI Infrastructure Problem We Might Be Solving the Wrong WayIO.NET Team / Sep 29, 2026We’re told that AI's compute crisis is a supply problem. That is, simply not enough GPUs exist. \n\nAWS is reportedly planning millions more chips, NVIDIA is backing gigawatt-scale \"AI factories,\" and analyst estimates suggest a capex supercycle unlike anything the industry has seen. \n\nWhile a global chip count shortage would seem to be the most likely suspect for AI workload constraints, the truth has a bit more layers. In fact, a significant fraction of existing GPU capacity actually sits idle. Idle Capacity vs. New Capacity: A Different Energy Math for AI ComputeIO.NET Team / Sep 24, 2026AI's power problem has two very different answers, and the industry is currently sprinting toward only one of them. Understanding the distinction matters for anyone making GPU sourcing decisions in 2026, because the math on each path looks very different depending on where you stand.\n\nThe dominant industry response to AI's energy demand is new-build in the form of gigawatt-scale campuses, dedicated power infrastructure, long-term purchase agreements. That approach adds supply by constructing it AI Safety Is Not the Same as AI AccountabilityIO.NET Team / Sep 21, 2026When a small number of organizations control the infrastructure that makes frontier AI possible, control the models that run on that infrastructure, and then volunteer to grade their own safety commitments, you do not have a safety framework. That matters more than almost any technical question currently dominating the AI discourse, and it's the one least likely to be surfaced by the parties with the most to gain from blurring it.\n\nThe pattern is worth examining structurally. A handful of frontiThe Time-to-First-Token Trade-Off: Why Not Every Inference Workload Needs Sub-100ms LatencyIO.NET Team / Sep 18, 2026Time-to-first-token (TTFT) measures the delay between submitting a prompt and receiving the first output token, or the pause a user watches before text starts streaming onto their screen. In 2026, TTFT has become a primary marketing axis for a wave of inference-focused providers: Groq's LPU architecture, Nebius, Nscale, and others position low TTFT as a core differentiator, and for real-time, human-facing workloads, they're right to.\n\nA voice agent that takes 4 seconds to start speaking feels brWhy AI Agents Break Traditional Cloud Provisioning ModelsIO.NET Team / Sep 15, 2026One of the great ironies of AI infrastructure is that AI agent workloads are structurally incompatible with how hyperscalers sell compute. The reserved-instance model designed for sustained, predictable throughput collapses under the weight of agentic pipelines that spin up 40 workers in 90 seconds, run them for 7 minutes, then need zero capacity until the next trigger fires. That’s some extremely annoying architectural friction that anyone building an AI model or incorporating it into their exiWhat AI Teams Need to Vet Before Trusting a GPU Cloud VendorIO.NET Team / Sep 10, 2026Cloud procurement used to be a straightforward infrastructure decision. With GPU cluster growth across various clouds, from hyperscalers to neoclouds and DePIN solutions, that’s just no longer the case. \n\nEnterprise buyers now commit six- and seven-figure compute budgets to providers whose compliance posture, contractual protections, and operational reality vary enormously. This often happens in ways that aren't so obvious from a pricing page or a sales deck. \n\nThis blog is your checklist coveriThe power shortage that supply can’t fix (unless it’s already plugged in)IO.NET Team / Sep 8, 2026The current AI infrastructure conversation has settled on one big number: 38 gigawatts. That's Morgan Stanley's estimated US data-center power shortfall through 2028. What’s creating this shortfall? The GPU compute needed for inference workloads, and what the existing grid can actually deliver to new AI data facilities on any realistic timeline. \n\nHere are some quick numbers. Grid interconnection queues are presently running 5+ years out in most major markets. Add another 2–3 years for transformThe vendor lock-in tax: What 94% of IT teams worry aboutIO.NET Team / Sep 3, 2026Vendor lock-in used to be the province of IT departments. Now it’s a real budget risk. According to widely-cited survey data, 94% of IT professionals report concern about vendor lock-in. For anyone dealing with AI infrastructure, that worry is about to get more expensive. \n\nOn August 26, 2026, AWS announced an expanded multi-billion-dollar commitment to Nvidia GPU capacity that cemented the hyperscaler-as-gatekeeper model. It did so at precisely the moment AI workloads are scaling the fastest. WGPU Orchestration vs. GPU Rental: Why Most Decentralized Networks Are Just MarketplacesIO.NET Team / Sep 1, 2026You don't need one GPU. You need 32 GPUs that talk to each other like they're in the same rack.\n\nEvery DePIN network’s GPU marketing leads with price per GPU-hour. They publish comparison tables showing their H100 rates against AWS, their A100 spot costs against GCP, or their RTX 4090 per-second billing against Azure. Read between the lines and that marketing suggests that cheaper access to hardware is equivalent to actually usable infrastructure.\n\nWell, it isn't that simple. At least not for thThe Token Cost Paradox: Why cheaper inference doesn't mean cheaper AI billsIO.NET Team / Aug 27, 2026The AI budget conversation is the hot topic this year. So, it’s safe to say that If you've probably heard some version of this line: token costs are falling fast and AI is about to get a lot cheaper. \n\nIt's a reasonable proposition. You want to believe it. But according to Gartner's own research, it’s a notion that is mostly wrong for the people actually paying the bills.\n\nGartner's forecast, published this spring, makes some other striking proclamations. By 2030, they believe that running inferCentralized vs. decentralized AI compute: What every developer should knowIO.NET Team / Aug 25, 2026Anyone who rented a GPU knows the routine. You visit AWS, navigate to a p4d instance, quickly hit a quota wall, file a support ticket, wait three days, and finally get your A100. Or perhaps that’s not your experience. Instead, maybe you got an \"insufficient capacity\" error and moved on to GCP. Either way, you ran your workload and didn't think much about what was happening underneath.\n\nThis infrastructure experience of waitlists, opaque pricing, and quotas is the intentional design of centralizePage 1 of 12","tokens":1888,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267595356,"hash":"61a6d34907ac31bdfb14d921d666e25fa218e3ec"}
{"url":"https://forum.openzeppelin.com/t/bep20-crowdsale/11666/2","domain":"forum.openzeppelin.com","title":"BEP20 Crowdsale - Smart Contracts / Review Wanted - OpenZeppelin Forum","text":"Smart ContractsReview Wanted\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 2\n\n Jun 2021\n\n 2 / 13\n\n Jul 2021\n\n Dec 2021\n\n post by quantumcoder on Jun 30, 2021\n\n quantumcoder\n\n Hi everyone,\nI am working on a crowdsale project for my first freelance client.\nThe budget is very small(Im trying to build a portfolio) so I cannot do mistakes due to deployment fees.\nI have those two contracts:\nSales contract:\npragma solidity ^0.5.0;\n\nimport \"./Crowdcoin.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/emission/MintedCrowdsale.sol\";\n\n// @TODO: Inherit the crowdsale contracts\ncontract CrowdcoinSale is Crowdsale, MintedCrowdsale {\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin token, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n // @TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, token)\n MintedCrowdsale()\n public\n\n {\n // constructor can stay empty\n }\n}\n\ncontract CrowdcoinSaleDeployer {\n\n address public token_sale_address;\n address public token_address;\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n string memory name,\n string memory symbol,\n address payable wallet // this address will receive all Ether raised by the sale\n\n )\n public\n {\n // @TODO: create the Crowdcoin and keep its address handy\n Crowdcoin token = new Crowdcoin(name, symbol, 0);\n token_address = address(token);\n\n // @TODO: create the CrowdcoinSale and tell it about the token, set the goal, and set the open and close times to now and now + 24 weeks.\n uint goal = 300 wei;\n uint cap = 300 wei;\n\n CrowdcoinSale Crowdcoin_sale = new CrowdcoinSale(1, wallet, token, goal, cap, now, now + 24 weeks);\n token_sale_address = address(Crowdcoin_sale);\n\n // make the CrowdcoinSale contract a minter, then have the CrowdcoinSaleDeployer renounce its minter role\n token.addMinter(token_sale_address);\n token.renounceMinter();\n }\n}\n``\nPresale Token contract:\n``\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Mintable.sol\";\n\ncontract crowdcoin is ERC20, ERC20Detailed, ERC20Mintable {\n constructor(\n string memory name,\n string memory symbol,\n uint initial_supply\n )\n ERC20Detailed(name, symbol, 18)\n public\n {\n mint(msg.sender, initial_supply);\n }\n}\n\nI plan to proceed like this:\n1- Paste the crowdsale contract on remix.ethereum.org in the crowdsale.sol file that I will deploy with bsc\n2- Paste the token on remix.ethereum.org in the crowdcoin.sol file that I will deploy with bsc\nFor the prior two steps, will they automatically work together?\nhow do I link it on my client’s website so the participants can connect their bnb wallets swap directly from the sale webpage?\nThank You in advance !\n\n 4\n\n 4\n\n 2\n\n post by FreezyEx on Jul 1, 2021\n\n FreezyEx\n\n Hey can you tell us about the requirements of the crowdsale? Which features/function must it have?\n\n post by Skyge on Jul 1, 2021\n\n Skyge\n\nI think so, pass crowdcoin as the value for Crowdcoin in the CrowdcoinSale, then CrowdcoinSale can work with crowdcoin.\n\nThis question is about the front-end, you can use metamsk or wallet connect to connect users' wallet, just check the documentation of these plugins.\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n FreezyEx\n\n The crowdsale is just a mintable crowdsale, whereas for every purchase, new tokens are minted and sent to the buyer upon bnb receival at the defined rate. then the user must have a connect wallet button for metamask or trust wallet…\nAfter they collect their wallet they must be able to see their bnb balance on the screen.\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n Skyge\n\nThanks you for the reply so you mean I can edit crowdsale in that way:\nconstructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin crowdcoin, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n\nor\n@TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, crowdcoin? Or Deployed crowdcoin address)\n MintedCrowdsale()\n public\n\nOr I need to deploy the crowdcoin contract first then use the contract address?\nThanks in advance !\n\n post by Skyge on Jul 2, 2021\n\n post by quantumcoder on Jul 2, 2021\n\n post by zanja85 on Jul 6, 2021\n\n 5 months later\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n post by Skyge on Nov 21, 2021\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n post by Skyge on Nov 21, 2021\n\n 24 days later\n\n post by medolantex on Dec 15, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":1418,"squid":"ink-security_audits","role":"Sentinel","at":1791267605459,"hash":"3ef73af357e272698e64e845189d9a5f58f32705"}
{"url":"https://io.net/blog/ai-startup-corner","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogAI Startup CornerLatest By Topic (15)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsHow Vistara Labs’ Platform Built 5,600 Apps in 2 Months with io.netIO.NET Team / May 4, 2026Vistara Labs used io.net to scale its Zaara AI platform, building 5,600 apps in two months while cutting compute costs by 3x and achieving zero infrastructure failures.GLM-4.7 Flash Now Available on io.intelligenceIO.NET Team / Jan 23, 2026Z.ai's GLM-4.7-Flash (30B MoE) is live on io.intelligence. Get the strongest 30B model for coding & reasoning with best-in-class performance-per-dollar.Decentralized Computing in 2025: Architecture, Costs, and Migration GuideIO.NET Team / Jan 20, 2026Complete technical guide to decentralized compute: benchmarks, cost calculator, compliance checklist, and step-by-step migration from AWS/GCP.GLM-4.7 Now Available on io.intelligenceIO.NET Team / Jan 13, 2026GLM-4.7 is now live on io.intelligence. Z.ai's open-source coding model scores 84.9% on LiveCodeBench vs Claude's 64%. Access it via a single API endpoint.Parallel Computing: A Complete Guide to Models, Hardware, and Cloud ServicesIO.NET Team / Dec 16, 2025Solve compute bottlenecks with parallel computing. Compare models (parallel, concurrent, distributed), hardware, cloud costs, and best practices for performance gains.AI Training vs Inference: Key Differences, Costs & Use Cases [2025]IO.NET Team / Nov 28, 2025AI training teaches models to recognize patterns. AI inference applies those models to make predictions. Learn the differences, costs, and optimization strategies in io.net’s complete guide.\nGPU as a Service: Financial Guide for AI StartupsIO.NET Team / Oct 31, 2025Complete financial framework for GPU infrastructure decisions. Cost modeling, ROI analysis & budget optimization for AI companies. ML Model Deployment: Cut Costs 90% With Decentralized InfrastructureIO.NET Team / Oct 14, 2025Model deployment connects trained ML models to users, yet most stall due to cloud costs and vendor lock-ins. Decentralized platforms cut costs 90%.AI Data Centers: Optimizing Workloads and Infrastructure EfficiencyIO.NET Team / Oct 9, 2025Discover how AI data centers optimize workloads, boost efficiency, and power the future of artificial intelligence with advanced infrastructure.How Decentralized GPU Networks Are Powering the Next Generation of AIIO.NET Team / Oct 5, 2025Forget AWS's $37/hour GPU costs. Decentralized networks deliver the same power for 50-70% less, turning idle gaming rigs into AI supercomputers.Distributed Computing Architecture: Building Scalable SystemsIO.NET Team / Jul 28, 2025Distributed systems power AI/ML with scalability, fault tolerance, and performance, yet 73% fail to scale, demanding careful design and optimization.Cloud vs Edge Computing: Which Architecture Fits Your Needs?IO.NET Team / Jul 23, 2025Comparing cloud and edge computing architectures. Explaining when to use each model and how hybrid approaches optimize latency, scalability, and cost efficiency.Page 1 of 2","tokens":831,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267608149,"hash":"d89cb4150e3da3808a159c761cbd4a18a1351147"}
{"url":"https://forum.openzeppelin.com/t/bep20-crowdsale/11666/5","domain":"forum.openzeppelin.com","title":"BEP20 Crowdsale - Smart Contracts / Review Wanted - OpenZeppelin Forum","text":"Smart ContractsReview Wanted\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 2\n\n Jun 2021\n\n 5 / 13\n\n Jul 2021\n\n Dec 2021\n\n post by quantumcoder on Jun 30, 2021\n\n quantumcoder\n\n Hi everyone,\nI am working on a crowdsale project for my first freelance client.\nThe budget is very small(Im trying to build a portfolio) so I cannot do mistakes due to deployment fees.\nI have those two contracts:\nSales contract:\npragma solidity ^0.5.0;\n\nimport \"./Crowdcoin.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/emission/MintedCrowdsale.sol\";\n\n// @TODO: Inherit the crowdsale contracts\ncontract CrowdcoinSale is Crowdsale, MintedCrowdsale {\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin token, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n // @TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, token)\n MintedCrowdsale()\n public\n\n {\n // constructor can stay empty\n }\n}\n\ncontract CrowdcoinSaleDeployer {\n\n address public token_sale_address;\n address public token_address;\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n string memory name,\n string memory symbol,\n address payable wallet // this address will receive all Ether raised by the sale\n\n )\n public\n {\n // @TODO: create the Crowdcoin and keep its address handy\n Crowdcoin token = new Crowdcoin(name, symbol, 0);\n token_address = address(token);\n\n // @TODO: create the CrowdcoinSale and tell it about the token, set the goal, and set the open and close times to now and now + 24 weeks.\n uint goal = 300 wei;\n uint cap = 300 wei;\n\n CrowdcoinSale Crowdcoin_sale = new CrowdcoinSale(1, wallet, token, goal, cap, now, now + 24 weeks);\n token_sale_address = address(Crowdcoin_sale);\n\n // make the CrowdcoinSale contract a minter, then have the CrowdcoinSaleDeployer renounce its minter role\n token.addMinter(token_sale_address);\n token.renounceMinter();\n }\n}\n``\nPresale Token contract:\n``\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Mintable.sol\";\n\ncontract crowdcoin is ERC20, ERC20Detailed, ERC20Mintable {\n constructor(\n string memory name,\n string memory symbol,\n uint initial_supply\n )\n ERC20Detailed(name, symbol, 18)\n public\n {\n mint(msg.sender, initial_supply);\n }\n}\n\nI plan to proceed like this:\n1- Paste the crowdsale contract on remix.ethereum.org in the crowdsale.sol file that I will deploy with bsc\n2- Paste the token on remix.ethereum.org in the crowdcoin.sol file that I will deploy with bsc\nFor the prior two steps, will they automatically work together?\nhow do I link it on my client’s website so the participants can connect their bnb wallets swap directly from the sale webpage?\nThank You in advance !\n\n 4\n\n 4\n\n 2\n\n post by FreezyEx on Jul 1, 2021\n\n FreezyEx\n\n Hey can you tell us about the requirements of the crowdsale? Which features/function must it have?\n\n post by Skyge on Jul 1, 2021\n\n Skyge\n\nI think so, pass crowdcoin as the value for Crowdcoin in the CrowdcoinSale, then CrowdcoinSale can work with crowdcoin.\n\nThis question is about the front-end, you can use metamsk or wallet connect to connect users' wallet, just check the documentation of these plugins.\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n FreezyEx\n\n The crowdsale is just a mintable crowdsale, whereas for every purchase, new tokens are minted and sent to the buyer upon bnb receival at the defined rate. then the user must have a connect wallet button for metamask or trust wallet…\nAfter they collect their wallet they must be able to see their bnb balance on the screen.\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n Skyge\n\nThanks you for the reply so you mean I can edit crowdsale in that way:\nconstructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin crowdcoin, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n\nor\n@TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, crowdcoin? Or Deployed crowdcoin address)\n MintedCrowdsale()\n public\n\nOr I need to deploy the crowdcoin contract first then use the contract address?\nThanks in advance !\n\n post by Skyge on Jul 2, 2021\n\n Skyge\n\nYeah, you should deploy crowdcoin at first, and then you can pass this address to the CrowdcoinSale\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n Well received thanks a lot\nIs there anything about permissions?\n\n post by zanja85 on Jul 6, 2021\n\n zanja85\n\n I have used a very similar setup, You didn’t get inspired by the PupperCoin contract by any chance? My issue with this was that once the PupperCoinSaleDeployer has depoed the PupperCoinSale contract , you don’t really have any control over the token any more.\nThat might now be an issue for you though. I wanted to have extra minterrole for myself as well as the ability to burn tokens.\nThis is what I used then at least (Note that it’s old OpenZeppelin (V 2.5.1)\nPupperCoin\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/token/ERC20/ERC20Mintable.sol\";\n\ncontract PupperCoin is ERC20, ERC20Detailed, ERC20Mintable {\n constructor(\n string memory _name,\n string memory _symbo,\n uint initial_supply\n )\n ERC20Detailed(name, symbol, decimals)\n public\n {\n // constructor can stay empty\n }\n}\n\nPupperCoinCrowdSale\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\nimport \"https://github.com/Creepybits/Puppercoin/blob/main/PupperCoin.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/crowdsale/Crowdsale.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/crowdsale/emission/MintedCrowdsale.sol\";\n\n// Inherit the crowdsale contracts:\ncontract PupperCoinCrowdsale is Crowdsale, MintedCrowdsale{\n\n constructor(\n // Constructor parameters:\n uint rate,\n address payable wallet,\n SvenskTiger token,\n uint goal,\n uint open,\n uint close\n )\n // Pass constructor parameters to the crowdsale contracts:\n Crowdsale(rate, wallet, token)\n public\n {\n // constructor can stay empty\n }\n}\n\ncontract PuppercoinSaleDeployer {\n\n address public token_sale_address;\n address public token_address;\n\n constructor(\n // Constructor parameters:\n string memory name,\n string memory symbol,\n address payable wallet,\n uint goal\n )\n public\n {\n // Create the Puppercoin and keep its address:\n PupperCoin token = new PupperCoin(name, symbol, decimals);\n token_address = address(token);\n\n // Create the PupperCoinSale and tell it about the token, set the goal, and set the open and close times to now and (now + 24 weeks):\n PupperCoinSale token_sale = new PupperCoinSale(1, wallet, token, goal, now, now + 24 weeks);\n token_sale_address = address(token_sale);\n\n // Make the PupperCoinSale contract a minter, then have the PupperCoinSaleDeployer renounce its minter role:\n token.addMinter(token_sale_address);\n token.renounceMinter();\n }\n}\n\nIf you want or need more control over the token and it’s sale, you might wan’t to consider other options.\n\n 5 months later\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n Kubrick_BERGMAN\n\n what should i edit? For rate, goal etc. And how can i set open and close time example 25.11.2021 17:00 start, 26.11.2021 17:00 end.\n\n post by Skyge on Nov 21, 2021\n\n Skyge\n\n Hi, welcome! \nThe open time and close time is the timestamp, so just convert the time to timestamp to pass.\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n Kubrick_BERGMAN\n\n Thanks. How can i do that? And how can i set rate for example Presale rate: 100 MyToken = 0.01 BNB?\n\n post by Skyge on Nov 21, 2021\n\n Skyge\n\nMany tools online can convert to timestamp.\n\nHave a look at this documentation:\nCrowdsales - OpenZeppelin Docs\n\n 24 days later\n\n post by medolantex on Dec 15, 2021\n\n medolantex\n\n hello to all I wanted to create a smart contract for the crowd sale but I don't understand anything can someone tell me which contract and how can I implement it on my site so that people connect their wallet and buy?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":2341,"squid":"ink-security_audits","role":"Sentinel","at":1791267616179,"hash":"2ec1c4c24a5aad41c2f7dcaa97cc4462dd78909c"}
{"url":"https://aave.com/build","domain":"aave.com","title":"Build | Aave","text":"Build with Aave Kit.Aave Kit gives developers permissionless access to onchain liquidity. Supply, borrow, and earn with a few lines of code.Start BuildingTalk to SalesAdd YieldGrow revenue with a single integration. Users earn competitive yield across 10+ chains, any ERC-20.useSupply({ asset, amount, … })Unlock BorrowingInstant credit against any holdings — users stay in their positions. Preview health factor and risk premium before signing.useBorrow({ asset, amount, … })Deploy EverywhereOne SDK across 14 chains. Ethereum, Arbitrum, Base, Avalanche and more — same hooks, every network.npm install @aave/react@nextBuilding on AaveCompatible with best-in-class walletsAave v4. The next generation of the Aave Protocol.Unified liquidity layer, risk-adjusted borrow rates, and smarter liquidations. State of the art infrastructure that's simple to integrate.Start BuildingLearn MoreUnified LiquidityOne shared pool across all markets. No fragmentation.Modular MarketsIndependent risk parameters, rates, and collateral rules.User Risk PremiumBorrow costs adjust to collateral quality automatically.Smarter LiquidationsTarget health factor restoration with variable bonuses.User PositionsCombined view of supplies, borrows, and health factors.No Migration RequiredNew markets and features deploy without moving liquidity.Hub & Spoke ArchitectureUnified liquidity across isolated risk environments. Each hub defines a solvency boundary — spokes encode borrowing rules within it.PrimeCorePlusPrimeCorePlusLiquidity HubsSpokesIsolatedCross HubWhat builders are saying.Real integrations. Real results.View Case StudiesWhop21M+ userswith yield powered by Aave.Whop Treasury routes merchant balances to Aave via Veda on Plasma. Up to 6% APY on USDT, auto-compounding, instant withdrawals, no wallets or DeFi knowledge required.Kraken~60%lending market share.Kraken launched DeFi Earn powered by Aave, embedding onchain yield into its exchange experience with no wallets or signing required.MetaMask100M+ userswith access to Aave-powered yield.MetaMask integrated Aave to power Stablecoin Earn, yield on USDC, USDT, and DAI directly inside the wallet, plus yield-bearing spending via the MetaMask Card.Cap$360M+ supplied90% of stcUSD yield from Aave.Cap routes over $360M in idle stablecoin reserves through Aave and uses its USDC supply rate as the benchmark for Cap's own yield engine.Ethena$10B reachedin 500 days.Aave's lending markets powered the recursive strategies behind USDe's growth to $10B, the fastest stablecoin ascent in history.Kinexys by J.P. MorganJ.P. Morganvalidated institutional DeFi on Aave.Kinexys used a modified Aave deployment for tokenized FX settlement in Singapore's Project Guardian. Real-time, compliant transactions on a public chain.Avalanche$2B+in treasury assets managed through Aave.The Avalanche Foundation uses Aave to earn yield on idle holdings, borrow stablecoins against strategic positions, and fund ecosystem programs, all without counterparty approval.Integrate Aave in Minutes. Drive new revenue, boost user retention, and cut costs.Aave Kit exposes the full power of Aave Protocol through a clean developer API.Integrate Earn withuseSupply().1Install the SDKbashnpm install @aave/react@next2Set up the Aave clientCreate a client once and wrap your app. All Aave hooks share this context automatically.client.ts & App.tsx// client.tsimport { AaveClient } from \"@aave/react\";export const client = AaveClient.create();​// App.tsximport { AaveProvider } from \"@aave/react\";import { client } from \"./client\";​export default function App() { return <AaveProvider client={client}><YourApp /></AaveProvider>;}3Supply assets to earn yieldHandles ERC-20 approvals via permit or transaction. One hook, one call.SupplyWidget.tsximport { useSupply, bigDecimal, evmAddress } from \"@aave/react\";import { useSendTransaction, useSignTypedData } from \"@aave/react/viem\";​const [supply, { loading, error }] = useSupply((plan) => { switch (plan.__typename) { case \"TransactionRequest\": return sendTransaction(plan); case \"Erc20Approval\": if (plan.bySignature) return signTypedData(plan.bySignature); return sendTransaction(plan.byTransaction); }});​const result = await supply({ sender: evmAddress(wallet.account.address), reserve: reserve.id, amount: { erc20: { value: bigDecimal(42) } },});View API DocsAave powers billions in deposits with 6 years of secure, transparent, and battle-tested performance.Security & ComplianceRead Audit ReportsNet depositsOf all active DeFi stablecoinsMore TVL than the next lending protocol.65+ independent auditsEvery major release reviewed by leading security firms.  Audit reports published onchain.6+ years of uninterrupted operationProtocol has processed every market condition since 2020.SOC 2 Type 2 complianceInstitutional-grade security controls and reporting standards.And MoreExecute large volumes without rate volatilityAdd eligibility requirements like KYCBug bounty programDeploy isolated-risk lending markets on any supported chainLoss protection via UmbrellaSupports RWAsCompatibility by Design. Aave integrates with any type of financial service.Fintechs & Stablecoin IssuersOffer your users transparent, competitive yield and crypto-backed loans powered by stablecoins.Exchanges & CustodiansIntegrate yield and crypto-backed loans into your product to increase revenue, and drive user retention.WalletsEnable users to earn and borrow against their assets in the most competitive and liquid onchain markets.Native DeFiBuild next-generation DeFi products and tap into deep Aave liquidity to bootstrap your launch.Banks & Asset ManagersEarn and borrow 24/7 with Horizon's onchain repo markets for tokenized assets.Marketplaces & PaymentsOptimize treasury management by sweeping customer funds into lending backed by secured money market instruments or liquid crypto-native collateral.Stable Vaults. Institutional-grade fixed yield.Turnkey vaults that convert variable DeFi yield into fixed, predictable returns. Aave manages the strategies, you integrate the deposit flow.Learn MoreView the DocsPredictable RatesUsers earn a pre-set predictable APY with no volatility.Auto-Compounding RewardsRewards are claimed and reinvested automatically.Boosted RatesReward premium users with higher fixed APY per wallet.Multi-AssetOne vault accepts USDC, USDT, GHO, and more.Cross-Chain Yield StrategiesEarn across chains while deposits stay on a low-cost network.Access ControlRestrict deposits to a permissioned set of wallets.Predictable yield in an unpredictable market.Stable Vaults absorb the volatility that variable-rate markets produce, delivering fixed rates that compound every second.Stable Vault (USDC)Aave v3 Core (Variable)USDC supply rate•Aave v3 Core (Ethereum)•2025Stories from IntegratorsHow Ink and Kraken Use AaveHow Kraken's Ink L2 built Tydro on Aave V3 to power native lending and embedded DeFi for millions of users.CapCap integrates Aave to deploy idle stablecoin reserves and benchmark yield rates, growing to one of Aave's largest USDC depositors with over $360M supplied.ArbitrumAave has solidified its role as a cornerstone of Arbitrum's ecosystem, establishing the chain as the premier \"home of DeFi.\"TangemHow Tangem uses Aave to Power Non-Custodial Yield.Kinexys by J.P. MorganHow Aave protocol was adapted for institutional needs as part of the Project Guardian initiative led by the Monetary Authority of Singapore.LidoLido's liquid staking combines forces with Aave to power DeFi's ETH yield engine.BlockdaemonHow Blockdaemon Uses Aave to Power Institutional Access to Onchain Yield.BTCSHow Nasdaq-listed BTCS Uses Aave to Finance its Digital Asset Treasury (DAT) Strategy.GalaxyInstitutional Liquidity in Practice.EthenaEthena’s Ascent to $10bn, Powered by the Aave Liquidity Engine.MetaMaskMetaMask selected Aave as its DeFi lending partner to power Stablecoin Earn, a feature that lets users earn yield directly inside their wallet.AvalancheAvalanche uses Aave to securely access decentralized capital markets.FAQsBanks, asset managers, fintechs, wallets, exchanges, and DeFi developers can all integrate with Aave.You can tap into lending markets, run yield products, launch crypto-backed loans, or build apps for payments and treasury use cases.Yes, the pools are insured via Umbrella, Aave's native insurance module.Vaults let users earn or borrow by connecting to existing Aave lending pools, while giving you the ability to earn fees.Aave's SDK, react hooks, and API make it easy to connect to markets and deploy vaults in minutes.How can we help?We're here to help you build. Contact us to learn more.Name *Email *How would you like to integrate? *","tokens":2163,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267618001,"hash":"efc84dd2e7321c586571aecc001260ad2c42099f"}
{"url":"https://forum.openzeppelin.com/t/bep20-crowdsale/11666","domain":"forum.openzeppelin.com","title":"BEP20 Crowdsale - Smart Contracts / Review Wanted - OpenZeppelin Forum","text":"BEP20 Crowdsale \n\n Smart ContractsReview Wanted\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n 4\n\n 2\n\n Jun 2021\n\n 1 / 13\n\n Jul 2021\n\n Dec 2021\n\n post by quantumcoder on Jun 30, 2021\n\n quantumcoder\n\n Hi everyone,\nI am working on a crowdsale project for my first freelance client.\nThe budget is very small(Im trying to build a portfolio) so I cannot do mistakes due to deployment fees.\nI have those two contracts:\nSales contract:\npragma solidity ^0.5.0;\n\nimport \"./Crowdcoin.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/Crowdsale.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/crowdsale/emission/MintedCrowdsale.sol\";\n\n// @TODO: Inherit the crowdsale contracts\ncontract CrowdcoinSale is Crowdsale, MintedCrowdsale {\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin token, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n // @TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, token)\n MintedCrowdsale()\n public\n\n {\n // constructor can stay empty\n }\n}\n\ncontract CrowdcoinSaleDeployer {\n\n address public token_sale_address;\n address public token_address;\n\n constructor(\n // @TODO: Fill in the constructor parameters!\n string memory name,\n string memory symbol,\n address payable wallet // this address will receive all Ether raised by the sale\n\n )\n public\n {\n // @TODO: create the Crowdcoin and keep its address handy\n Crowdcoin token = new Crowdcoin(name, symbol, 0);\n token_address = address(token);\n\n // @TODO: create the CrowdcoinSale and tell it about the token, set the goal, and set the open and close times to now and now + 24 weeks.\n uint goal = 300 wei;\n uint cap = 300 wei;\n\n CrowdcoinSale Crowdcoin_sale = new CrowdcoinSale(1, wallet, token, goal, cap, now, now + 24 weeks);\n token_sale_address = address(Crowdcoin_sale);\n\n // make the CrowdcoinSale contract a minter, then have the CrowdcoinSaleDeployer renounce its minter role\n token.addMinter(token_sale_address);\n token.renounceMinter();\n }\n}\n``\nPresale Token contract:\n``\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v2.5.0/contracts/token/ERC20/ERC20Mintable.sol\";\n\ncontract crowdcoin is ERC20, ERC20Detailed, ERC20Mintable {\n constructor(\n string memory name,\n string memory symbol,\n uint initial_supply\n )\n ERC20Detailed(name, symbol, 18)\n public\n {\n mint(msg.sender, initial_supply);\n }\n}\n\nI plan to proceed like this:\n1- Paste the crowdsale contract on remix.ethereum.org in the crowdsale.sol file that I will deploy with bsc\n2- Paste the token on remix.ethereum.org in the crowdcoin.sol file that I will deploy with bsc\nFor the prior two steps, will they automatically work together?\nhow do I link it on my client’s website so the participants can connect their bnb wallets swap directly from the sale webpage?\nThank You in advance !\n\n 4\n\n 4\n\n 2\n\n post by FreezyEx on Jul 1, 2021\n\n FreezyEx\n\n Hey can you tell us about the requirements of the crowdsale? Which features/function must it have?\n\n post by Skyge on Jul 1, 2021\n\n Skyge\n\nI think so, pass crowdcoin as the value for Crowdcoin in the CrowdcoinSale, then CrowdcoinSale can work with crowdcoin.\n\nThis question is about the front-end, you can use metamsk or wallet connect to connect users' wallet, just check the documentation of these plugins.\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n FreezyEx\n\n The crowdsale is just a mintable crowdsale, whereas for every purchase, new tokens are minted and sent to the buyer upon bnb receival at the defined rate. then the user must have a connect wallet button for metamask or trust wallet…\nAfter they collect their wallet they must be able to see their bnb balance on the screen.\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n Skyge\n\nThanks you for the reply so you mean I can edit crowdsale in that way:\nconstructor(\n // @TODO: Fill in the constructor parameters!\n uint rate, // rate in TKNbits\n address payable wallet, // sale beneficiary\n Crowdcoin crowdcoin, // the Crowdcoin itself that the CrowdcoinSale will work with\n\n )\n\nor\n@TODO: Pass the constructor parameters to the crowdsale contracts.\n Crowdsale(rate, wallet, crowdcoin? Or Deployed crowdcoin address)\n MintedCrowdsale()\n public\n\nOr I need to deploy the crowdcoin contract first then use the contract address?\nThanks in advance !\n\n post by Skyge on Jul 2, 2021\n\n Skyge\n\nYeah, you should deploy crowdcoin at first, and then you can pass this address to the CrowdcoinSale\n\n post by quantumcoder on Jul 2, 2021\n\n quantumcoder\n\n Well received thanks a lot\nIs there anything about permissions?\n\n post by zanja85 on Jul 6, 2021\n\n zanja85\n\n I have used a very similar setup, You didn’t get inspired by the PupperCoin contract by any chance? My issue with this was that once the PupperCoinSaleDeployer has depoed the PupperCoinSale contract , you don’t really have any control over the token any more.\nThat might now be an issue for you though. I wanted to have extra minterrole for myself as well as the ability to burn tokens.\nThis is what I used then at least (Note that it’s old OpenZeppelin (V 2.5.1)\nPupperCoin\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/token/ERC20/ERC20.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/token/ERC20/ERC20Detailed.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/token/ERC20/ERC20Mintable.sol\";\n\ncontract PupperCoin is ERC20, ERC20Detailed, ERC20Mintable {\n constructor(\n string memory _name,\n string memory _symbo,\n uint initial_supply\n )\n ERC20Detailed(name, symbol, decimals)\n public\n {\n // constructor can stay empty\n }\n}\n\nPupperCoinCrowdSale\n// SPDX-License-Identifier: MIT\n\npragma solidity ^0.5.0;\n\nimport \"https://github.com/Creepybits/Puppercoin/blob/main/PupperCoin.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/crowdsale/Crowdsale.sol\";\nimport \"https://github.com/Creepybits/openzeppelin/blob/main/contracts/crowdsale/emission/MintedCrowdsale.sol\";\n\n// Inherit the crowdsale contracts:\ncontract PupperCoinCrowdsale is Crowdsale, MintedCrowdsale{\n\n constructor(\n // Constructor parameters:\n uint rate,\n address payable wallet,\n SvenskTiger token,\n uint goal,\n uint open,\n uint close\n )\n // Pass constructor parameters to the crowdsale contracts:\n Crowdsale(rate, wallet, token)\n public\n {\n // constructor can stay empty\n }\n}\n\ncontract PuppercoinSaleDeployer {\n\n address public token_sale_address;\n address public token_address;\n\n constructor(\n // Constructor parameters:\n string memory name,\n string memory symbol,\n address payable wallet,\n uint goal\n )\n public\n {\n // Create the Puppercoin and keep its address:\n PupperCoin token = new PupperCoin(name, symbol, decimals);\n token_address = address(token);\n\n // Create the PupperCoinSale and tell it about the token, set the goal, and set the open and close times to now and (now + 24 weeks):\n PupperCoinSale token_sale = new PupperCoinSale(1, wallet, token, goal, now, now + 24 weeks);\n token_sale_address = address(token_sale);\n\n // Make the PupperCoinSale contract a minter, then have the PupperCoinSaleDeployer renounce its minter role:\n token.addMinter(token_sale_address);\n token.renounceMinter();\n }\n}\n\nIf you want or need more control over the token and it’s sale, you might wan’t to consider other options.\n\n 5 months later\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n Kubrick_BERGMAN\n\n what should i edit? For rate, goal etc. And how can i set open and close time example 25.11.2021 17:00 start, 26.11.2021 17:00 end.\n\n post by Skyge on Nov 21, 2021\n\n Skyge\n\n Hi, welcome! \nThe open time and close time is the timestamp, so just convert the time to timestamp to pass.\n\n post by Kubrick_BERGMAN on Nov 21, 2021\n\n Kubrick_BERGMAN\n\n Thanks. How can i do that? And how can i set rate for example Presale rate: 100 MyToken = 0.01 BNB?\n\n post by Skyge on Nov 21, 2021\n\n Skyge\n\nMany tools online can convert to timestamp.\n\nHave a look at this documentation:\nCrowdsales - OpenZeppelin Docs\n\n 24 days later\n\n post by medolantex on Dec 15, 2021\n\n medolantex\n\n hello to all I wanted to create a smart contract for the crowd sale but I don't understand anything can someone tell me which contract and how can I implement it on my site so that people connect their wallet and buy?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":2345,"squid":"ink-security_audits","role":"Sentinel","at":1791267627259,"hash":"077465e4f90a58a2adc4e839e38825de1e76e973"}
{"url":"https://aave.com/docs/resources/web3","domain":"aave.com","title":"Web3 | Aave Protocol Documentation","text":"Web3#\nWeb3 is the next evolution of the internet where people have control and ownership over their data, the relationships they form online, and their user profile. Together, these make up \"social capital\": Everyone has it, and it's valuable. In contrast, today when we go on the internet, we visit sites owned by large companies, who own our social capital. These \"web2\" companies like Amazon, Facebook and Google store user data on privately-held servers and sell it to advertisers in exchange for providing free services. This has led to a good experience for users (free, easy-to-use networks and applications), but it has also caused privacy issues, data manipulation, and limited monetisation options. Web3 addresses these issues by using blockchain technology. This technology is based on user ownership. When people own their data, they can monetise however they want, take their digital information with them (profile, content, data) when they switch networks, and it has the benefit of putting people and apps/networks on an equal footing. Web3 enables a more open and balanced internet, where people have a stake and voice in the future of the internet.\nTo understand the significant difference between the internet we know today (web2) and web3, take a step back.\nWhen the internet first came about, it was hard to access because there were no easy-to-use applications. Web1 was built on open, public protocols or applications such as TCP, IP, SMTP, and HTTP that builders could develop on top of, plugging into these open protocols to create whatever applications or platforms they wanted. Nobody needed permission to use these foundational protocols or standards to build user-friendly applications like email browsers and marketplaces. These standards are the basic building blocks of the internet. They govern how computers interact with each other and the flow of information. Today, in many senses, we are locked into platforms that own our data.\nBlockchain#\nA blockchain is a decentralised, distributed ledger system designed to record and verify transactions across a network of computers. This compels that no single entity or company controls the entire network, promoting a system of collective agreement and transparency. Unlike traditional databases that rely on central authorities (private servers owned by companies who set all the rules and make all the decisions), blockchains operate on a peer-to-peer network where every participant, known as nodes, has access to the entire ledger (the information is spread across multiple nodes or computers and each has an entire copy of the information). This decentralisation enhances both security and transparency, as each transaction is visible to all participants and cannot be altered without consensus (all nodes agreeing) from the network.\nThe core of blockchain technology lies in its unique distributed or decentralised structure. Transactions are grouped into units called \"blocks.\" Each block contains a list of transactions that have been validated (consensus) by the network. Once a block is filled with transactions, it is added to the existing chain of blocks in a sequential manner that is time stamped. This process creates a continuous, unalterable chain of blocks, hence the name \"blockchain.\" Each block contains a reference to the previous block, forming a chronological sequence. This structure makes it extremely difficult to alter any information in a block without changing all subsequent blocks, which would require the consensus of the majority of the network.\nSmart Contracts#\nSmart contracts are self-executing programs that operate deterministically. When an address interacts with a smart contract, the contract executes the agreed-upon actions, such as transferring assets or updating internal accounting. This automation eliminates the need for intermediaries, making transactions more efficient and reducing the potential for human error or manipulation. By relying on code rather than third parties, smart contracts enable trustless and transparent operations, where all parties involved have confidence in the outcome.\nSmart contracts are integral to many blockchain applications, as they are executed by blockchain networks like Ethereum, which functions as a global computer network. These networks process and validate the conditions set within each smart contract, updating the state of the contract with every new block added to the chain. This decentralised execution validates that smart contracts run precisely as programmed, without the risk of interference or manipulation. The combination of immutability and public auditability (transparency) in smart contracts provides a high level of trust and security, making them a foundational element in the development of decentralised applications such as identity, finance, and more.\nDeFi#\nDecentralised Finance, or DeFi, leverages blockchains and smart contracts to create an open, transparent, and decentralised financial ecosystem. At its core, DeFi aims to improve upon traditional financial systems without the reliance on centralised institutions such as banks, brokers, and financial intermediaries. DeFi offers a novel approach to financial applications, marked by increased accessibility, transparency, and control for users.\nDeFi operates on blockchain networks, with Ethereum being the first and most prominent platform. Most of these DeFi applications are now also deployed on Layer 2 blockchains, such as Arbitrum, Optimism, and ZKSync. Unlike traditional financial systems that rely on intermediaries to process and verify transactions, DeFi uses decentralised networks to perform these functions. By removing intermediaries, DeFi aims to lower costs, reduce barriers to entry, and enhance the efficiency of financial transactions.\nStablecoins#\nStablecoins are digital assets that aim to keep their value constant relative to a reference asset, most commonly fiat currencies like the U.S. dollar, euro, or yen. Unlike Bitcoin or Ethereum, whose values can fluctuate significantly, stablecoins are designed to be predictable and stable, making them useful for everyday transactions, remittances, and as a safe haven during market turbulence.\nStablecoins bridge the gap between traditional finance and the crypto world. They allow users to transfer value globally without major price fluctuations. Here are a few key uses:\nRemittances: Sending money across borders can be costly and slow. Stablecoins enable faster and cheaper transactions.DeFi (Decentralised Finance): Stablecoins are crucial in the DeFi ecosystem, where they are used for supplying, borrowing, and earning interest.Hedging: Traders and investors use stablecoins to move out of volatile assets without converting back to fiat.Payments: Merchants can accept stablecoins for goods and services without price volatility.\nStablecoins achieve stability through various mechanisms:\nFiat-collateralised Stablecoins: These are backed by reserves of fiat currency held in a bank account. For every stablecoin issued, an equivalent amount of fiat currency is held in reserve. Examples include Tether (USDT) and USD Coin (USDC).Decentralised Stablecoins: These operate without a central authority and are typically issued, redeemed, and governed by smart contracts on a blockchain. Smart contracts can manage the collateral requirements and issuance based on predefined rules in a trustless and transparent process. Aave’s GHO is one example of this kind of stablecoin.Algorithmic Stablecoins: These rely on smart contracts and algorithms to maintain their peg. Instead of being backed by reserves, these stablecoins use mechanisms like minting and burning to control the supply and stabilise the price.PreviousRisksNextGlossary","tokens":1940,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267629007,"hash":"25f2d93ab97ba9889cc593f177e664c31a8b78f6"}
{"url":"https://docs.base.org/get-started/private-transactions","domain":"docs.base.org","title":"Private Transactions - Base Documentation","text":"Base Ledgers is in early access. Request access to run your own ledger, or use Coinbase Managed for a managed service built on it.\nRun your own private payments product on Base with Base Ledgers. Balances, transfers, and counterparties stay off public block explorers, while funds settle on Base through a single Portal contract. Compliance is enforced at the ledger level with your own KYC controls, funds are self-custodied in a contract you control, and every deposit and withdrawal is an onchain call you can bundle atomically with other Base actions.\n​Demo\nScenario1Encrypt2Deposit3CreditDemo1Encrypt recipientIn progress2deposit()Pending3Credit ledgerPendingWhat's exposed onchainAssetPublicAmountPublicSenderPublicRecipientHiddenEncrypt recipientEncrypt the recipient so deposits to one account can't be linked.OperationEncrypt recipientVisibilityPrivateAccount0x9f…encNetworkBase VibenetTransaction event log10:42:11[PENDING]Encrypt recipient10:42:12[PENDING]deposit()10:42:13[PENDING]Credit ledgerWithout a private ledger, the receiving account is visible to everyone onchain.\nThe demo above is mock only. If you want to see onchain demos on Vibenet, head to Base chain demos.\n​Guides\n\n​Why Base Ledgers\n\nPrivate by default. Balances, transactions, and transfers stay off public block explorers. Deposits hide the recipient and withdrawals hide the sender, so the two stay unlinkable.\nCompliant. An operator gates the ledger with its own KYC and compliance controls.\nComposable with Base. Deposits and withdrawals are onchain calls you can bundle with other actions (deposit-and-act or withdraw-and-swap) that settle together or not at all.\nConfigurable. Run a ledger on your own terms with self-custodied funds and custom logic for how transactions are processed.\n\n​Built For\nB2B paymentsPay vendors without broadcasting your supplier list to the public chain.Payroll & payoutsRun onchain payroll without publishing what every employee or contractor earns.Treasury operationsMove balances between corporate accounts, custodians, and counterparties privately.Cross-border remittanceRun KYC-gated corridors where sender, recipient, and amount aren’t exposed.\n​How It Works\nA payment moves through three stages: funds enter through the Portal contract, move privately within the ledger, and exit back to Base. The operator runs the services that process each step and decides how to authorize withdrawals.\n\nDeposit. A user moves funds from Base into the ledger. The recipient is encrypted, so deposits to one account stay unlinked.\nTransfer inside a ledger. Inside the ledger, users transfer, swap, and earn yield while balances and activity remain private.\nWithdraw. A user moves funds back to Base. Onchain, a withdrawal reveals the asset and amount but not the account behind it.\nWas this page helpful?Suggest editsRaise issue","tokens":709,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267629426,"hash":"5553895b8ef02fb4ae162a113484696c953654d8"}
{"url":"https://aave.com/docs/resources/legacy-versions/v1","domain":"aave.com","title":"Aave V1 | Aave Protocol Documentation","text":"Aave v1#\nResources#\nWhitepaperSource CodeContract AddressesInterface\nKey differences#\nThe following are key architectural differences between Aave v1 and subsequent protocol versions:\nTokenization: In V1, positions were not tokenized, meaning users had to manually calculate their supply & borrow balances by querying individual contracts.PoolCore: V1 used a separate contract, PoolCore, to hold protocol assets, which added complexity for users and developers. In V2, this was replaced, and assets are held directly by aTokens.ETH -> WETH: In V1, the protocol used ETH directly, but Aave V2 switched to WETH for consistency.Interest Redirection: V1 allowed users to redirect earned interest to another address, a feature removed in V2.Batch Flash Loans: V1 introduced flash loans, but they were limited to single transactions. V2 expanded this to batch flash loans and added new modes for flash loans with deferred repayment.Withdraw aTokens: In V1, users had to redeem or withdraw their aTokens through the aToken contract. V2 migrated this action to the Pool contract.\nArchitecture#\nPool Core#\nThe PoolCore contract holds the state of every reserve and all assets supplied, as well as the basic logic (e.g. calculations using the stored data).\nPoolAddressesProvider#\nThe PoolAddressesProvider is a global addresses register of the protocol. This contract is immutable and the address will never change.\nPool Data Provider#\nThe PoolDataProvider contract performs calculations and provides data for the Pool contract, specifically:\nCalculates the ETH equivalent of a user's balance to assess the borrow limit of a user and the health factor of their positions.Aggregates data from PoolCore to provide high level information to the Pool.Calculates the Average Loan to Value and Average Liquidation Ratio.\nPool#\nThe Pool contract uses both the PoolCore and PoolDataProvider to interact with the reserves. This is the main contract developers should interface with. See the Pool section of the documentation.\nThe Pool also manages the tokenization of users' supply position via aTokens.\nPool Configurator#\nThe PoolConfigurator contract provides configuration functions for the Pool and PoolCore contracts. It also has a number of important functions:\nActivates / Deactivates reserves,Enables / Disables borrowing for a reserve,Enables / Disables using a reserve as collateral,Enables / Disables stable rate borrowing for a reserve,Freezes / Unfreezes reserves,Updates a reserve's Loan to Value,Updates a reserve's liquidation threshold,Updates a reserve's liquidation bonus,Updates a reserve's decimals,Updates a reserve's interest rate strategy address.\nFor all of the above functions, relevant events are emitted to the blockchain. Anyone can monitor these changes to know when values have been modified or added/removed.\nThe contract is owned by the PoolManager, as defined in the PoolAddressProvider.\nInterest Rate Strategy#\nThe InterestRateStrategy contract holds the information needed to calculate and update the interest rates of specific reserves.\nEach contract stores the optimised base curves using the corresponding parameters of each currency. This means that there is a mathematical function which determines the interest rate of each asset pool, with the interest rate changing based on the amount of borrowed funds and the total liquidity (i.e. utilisation) of the asset pool.\nThe parameters for the optimised base curves are:\nbaseVariableBorrowRatevariableRateSlope1variableRateSlope2stableRateSlope1stableRateSlope2\nThe interest rates are calculated depending on the available liquidity and the total borrowed amount.\nEvery reserve has a corresponding InterestRateStrategy contract.PreviousLegacy VersionsNextV2","tokens":932,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267640208,"hash":"4cbb2c0662fe49738a74710a44a8388039045b29"}
{"url":"https://docs.base.org/get-started/docs-mcp","domain":"docs.base.org","title":"MCP Server - Base Documentation","text":"Model Context Protocol (MCP) is an open standard that lets AI assistants securely access external data sources. The Base MCP server connects your AI coding assistant directly to our documentation, giving it live access to search and retrieve the exact information you need in real time.\n​Setup with Cursor\nCursor is an AI-powered code editor built as a fork of VS Code with features like AI code completion and natural language editing.\n1Open MCP SettingsIn Cursor, open Settings and navigate to Tools & MCP, then click Add MCP Server.2Add Base Docs ServerIn the mcp.json configuration file, add:mcp.json{\n \"mcpServers\": {\n \"base-docs\": {\n \"url\": \"https://docs.base.org/mcp\"\n }\n }\n}\n3Save and RestartSave the file and restart Cursor to apply the changes.4Start BuildingYour AI assistant can now access Base docs in real time. Try asking: “How do I deploy a smart contract on Base?”\n​Setup with Claude Code\nClaude Code is an agentic coding tool that lives in your terminal and understands your codebase.\n1Add the Base Docs MCP ServerRun the following command in your terminal:Terminalclaude mcp add --transport http base-docs https://docs.base.org/mcp\n2Verify InstallationCheck that the server was added successfully:Terminalclaude mcp list\n3Start BuildingLaunch Claude Code and start asking questions. Try: “How do I deploy a smart contract on Base?”Was this page helpful?Suggest editsRaise issue","tokens":349,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267643209,"hash":"c963f3231aa4d58088db068862d28a50dfdd8414"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/13","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 13 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by kladkogex on Jan 12, 2018\n\n post by ldct on Jan 12, 2018\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n post by vbuterin on Jan 13, 2018\n\n post by denett on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 15, 2018\n\n post by vbuterin on Jan 15, 2018\n\n post by AFDudley on Jan 17, 2018\n\n post by ltfschoen on Jan 17, 2018\n\n post by MicahZoltu on Jan 17, 2018\n\n Load more posts below","tokens":886,"squid":"ink-research","role":"Deep Scholar","at":1791267643247,"hash":"84089915936a400c5073baefca23ca8ac2e71b1b"}
{"url":"https://aave.com/docs/ecosystem/aave","domain":"aave.com","title":"AAVE Token | Aave Protocol Documentation","text":"AAVE#\n\nThe AAVE token is the native governance token of the Aave Protocol. It empowers holders to participate in decision-making through protocol governance. AAVE is an ERC-20 token deployed on the Ethereum blockchain and is widely accessible across various centralised and decentralised exchanges.\nGovernance#\nAAVE token holders have the ability to influence the future of the Aave Protocol through governance. Both AAVE and safety module staked AAVE (stkAAVE) holders can vote on proposals or delegate their voting power to others. By participating in governance votes, holders contribute to decisions on protocol deployments, parameter adjustments, features, and more.\nAAVE Buyback Program#\nThe Aave DAO operates a buyback program that uses protocol revenue to acquire AAVE tokens on the open market. The program was approved by governance in August 2024 as part of the Aavenomics update and began execution in April 2025.\nThe program has a $50 million annual budget. Weekly purchases range from $250,000 to $1.75 million, with volume adjusted based on market conditions, liquidity, and price volatility. The Aave Finance Committee (AFC) executes the buybacks.\nThe AFC is a four-member multisig composed of Chaos Labs, TokenLogic, LlamaRisk, and ACI, operating with a 3-of-4 signature threshold.\nAcquired tokens are sent to the Aave DAO Ecosystem Reserve, a treasury of AAVE tokens used for staking rewards, grants, and service provider payments. The tokens are used through governance-approved programs rather than burned.\nThe DAO can adjust the annual budget through governance votes. Buybacks can be tracked on the TokenLogic dashboard.\nLiquidity Pools#\nAAVE tokens can be supplied to liquidity pools within the Aave Protocol, or external pools such as decentralised exchanges, allowing users to earn yield.\nHolders can stake their tokens in the Aave safety module, enhancing the system's security by providing a backstop in case of insolvency and earning rewards in return. Staking AAVE can also grant reduced GHO borrowing rates, adding further incentives for participation. Additionally, AAVE tokens can be supplied to the Aave markets as collateral, allowing users to borrow other assets and increase their capital efficiency.\nCross-Chain#\nFurthermore, AAVE has cross-chain implementation on several networks using canonical network messaging bridges. This enables users to access AAVE across different blockchain networks, with the acknowledgment that the ability to bridge tokens to and from Ethereum depends on the availability of the network bridge.\nToken Deployments:\nEthereum MainnetArbitrumBaseOptimismPolygonPreviousSafetyNextGHO","tokens":662,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267651575,"hash":"284500a0ebfeccc229084dd907e351c68d57015b"}
{"url":"https://docs.base.org/base-chain/network-information/configuration-changelog","domain":"docs.base.org","title":"Configuration Changelog - Base Documentation","text":"This page tracks configuration changes to the Base networks, including updates to block building, network fees, and other network parameters.\n​Base Mainnet\nDateChangeDocumentationMay 28, 2026Azul: Reduced per-transaction gas maximum to 16,777,216 (2^24) via EIP-7825Per-Transaction Gas MaximumFebruary 19, 2026Increased Minimum Base Fee to 5,000,000 weiMinimum Base FeeFebruary 4, 2026Increased EIP-1559 Denominator to 125EIP-1559 Fee ParametersFebruary 2, 2026Increased Minimum Base Fee to 2,000,000 weiMinimum Base FeeJanuary 22, 2026Increased Minimum Base Fee to 1,000,000 weiMinimum Base FeeDecember 18, 2025Increased Minimum Base Fee to 500,000 weiMinimum Base FeeDecember 4, 2025Enabled Minimum Base Fee (200,000 wei)Minimum Base FeeSeptember 17, 2025Enabled Per-Transaction Gas MaximumPer-Transaction Gas MaximumSeptember 11, 2025Ended testing Per-Transaction Gas MaximumPer-Transaction Gas MaximumSeptember 10, 2025Started testing Per-Transaction Gas MaximumPer-Transaction Gas MaximumJuly 7, 2025Enabled FlashblocksFlashblocksMay 15, 2025Ended testing FlashblocksFlashblocksMay 15, 2025Started testing FlashblocksFlashblocks\n​Base Sepolia\nDateChangeDocumentationApril 20, 2026Azul: Reduced per-transaction gas maximum to 16,777,216 (2^24) via EIP-7825Per-Transaction Gas MaximumFebruary 19, 2026Increased Minimum Base Fee to 5,000,000 weiMinimum Base FeeFebruary 10, 2026Increased EIP-1559 Denominator to 125EIP-1559 Fee ParametersFebruary 10, 2026Increased Minimum Base Fee to 2,000,000 weiMinimum Base FeeNovember 20, 2025Enabled Minimum Base Fee (200,000 wei)Minimum Base FeeSeptember 3, 2025Enabled Per-Transaction Gas MaximumPer-Transaction Gas MaximumFebruary 25, 2025Enabled FlashblocksFlashblocksWas this page helpful?Suggest editsRaise issue","tokens":440,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267655893,"hash":"bd961b1d163fbae720221081f49d8ef95e7773e8"}
{"url":"https://ethresear.ch/t/minimal-viable-plasma/426/11","domain":"ethresear.ch","title":"Minimal Viable Plasma - Layer 2 / Plasma - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 11 / 144\n\n Jan 2018\n\n May 2019\n\n Load more posts above\n\n post by ldct on Jan 11, 2018\n\n post by denett on Jan 11, 2018\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n ldct\n\nFor step 1 do you mean “Alice moves 2 ETH into the plasma chain”?\n\nYep - sorry - I meant the plasma chain )\n\n post by ldct on Jan 12, 2018\n\n ldct\n\nHe still has his money on the Plasma chain, why should he care if Alice minted some money on the parent chain\n\nI think a withdrawal doesn’t mint eth on the parent chain, the plasma contract just sends previously-deposited eth to an address. If a spent TXO is fraudulently withdrawn (ie no one challenges the exit) then the plasma contract owns fewer eth than UTXOs and not all UTXOs can be withdrawn.\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\nCorrect - there is a global variable that contains say 1M ETH … A particular exit will change this global picture say by 1 ETH - which is a negligible amount …\n\n post by ldct on Jan 12, 2018\n\n ldct\n\n It’s not negligible - if there are 1,000,000 UTXOs in the plasma chain but the plasma contract only owns 999,999 ETH, then if everyone tries to withdraw the last person to withdraw must lose 1 ETH\n\n post by kladkogex on Jan 12, 2018\n\n kladkogex\n\n Understood :-))) IMHO reporting fraudulent withdrawals is doing work for the common good and not specifically an action to avoid personal financial loss … Since they will have to pay roughly $1 per fraud proof the question is why a particular user need to pay $1 to serve common good …\nAnother question is how do users of a particular chain mass exit. If all users try exiting at the same time, it can lead to a huge spike on the parent chain, and increase gas costs, so they will have to pay $10 to exit instead of regular $1 - it can be something very much similar to a short squeeze on capital markets …\n\n post by kz on Jan 12, 2018\n\n kz\n\n I believe the solution for\n\nis\n\nYou can probably design the system in such a way that requiring an exit requires a lot more ether than what is enough to cover fraud proof.\nIn that way the reporter of fraud proof could actually earn fee for doing work for common good.\nThat should align the incentives in that regard as far as I can tell.\n\n post by kz on Jan 12, 2018\n\n kz\n\n Could a combination of this\n\nand\n\ncreate a potential issue?\nThere is a potential race condition between:\n\nAlice, she could be depositing a large sum of ETH into the plasma chain because she has validated the state of plasma chain and she wants to participate\nBob, (the plasma chain operator) who runs the plasma chain and has decided to generate an invalid plasma block that generates new UTXO out of thin air and wants scam the system because he has registered the huge transaction Alice is making. (he can also use a lot of his ETH to bribe the main chain operators to include his fraudulent transaction that registers the plasma chain merkle root before Alice’s deposit enters the main chain).\n\nBecause of the ordering or exits, the deposit and the resulting exit Alice could be making will be ordered after Bob’s fraudulent exit that references UTXO he created out of thin air, and the amount of ETH on main chain could be depleted before Alice could finish her exit, thus she would be damaged.\nThis could be solved in a simple way by treating ETH deposit on main chain with weight of -1.\ndef ordering(blknum, txindex, oindex):\nweight = blknum if not deposit(blknum) else -1\nreturn weight * 1000000000 + txindex * 10000 + oindex\nThe deposit UTXO could be:\n\nnot spent → then there could be no problems with changing the ordering.\nspent → then one could again submit a fraud proof.\n\n post by denett on Jan 13, 2018\n\n post by vbuterin on Jan 13, 2018\n\n post by denett on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by kz on Jan 13, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 14, 2018\n\n post by denett on Jan 15, 2018\n\n post by vbuterin on Jan 15, 2018\n\n post by AFDudley on Jan 17, 2018\n\n Load more posts below","tokens":1018,"squid":"ink-research","role":"Deep Scholar","at":1791267655927,"hash":"fae85014ecc18841abb2bad6f5e4dbfa6b86bed7"}
{"url":"https://aave.com/docs/resources/code-licensing","domain":"aave.com","title":"Code Licensing | Aave Protocol Documentation","text":"Code Licensing#\nThe Aave Protocol operates on decentralized blockchain networks, with smart contracts that are self-executing and publicly auditable. These smart contracts and peripheral interfaces are licensed to define and regulate the use of the underlying code. The code exists across multiple GitHub repositories, and below are examples of some key licenses that apply to different Aave components:\nAave v3.6 Smart Contracts: Business Source License 1.1 permits non-commercial use and modification, restricting competitive use for four years, with a transition to the MIT License on March 6, 2027​. (GitHub)Governance v3: Business Source License 1.1 permits non-commercial use and modification, restricting competitive use for four years, with a transition to the MIT License on July 27, 2027.​ (GitHub)Umbrella: Business Source License 1.1 permits non-commercial use and modification, with competitive restrictions, transitioning to the MIT License on January 8, 2029.​ (GitHub)GHO Stablecoin: MIT License grants free and unrestricted rights to use, copy, modify, and distribute the software, provided the original copyright notice and license are included. The software is provided \"as is,\" with no warranties or liabilities for any issues arising from its use. (GitHub)Aave v3 Protocol on Aptos: Apache License 2.0 grants free rights to use, reproduce, modify, and distribute the software, provided the license and any notice files are included. (GitHub)Aave v2 Smart Contracts: GNU Affero General Public License (GitHub)Aave v1 Smart Contracts: GNU Affero General Public License (GitHub)Aave Labs Interface: All Rights Reserved. (GitHub)PreviousAccess ControlsNextChangelog","tokens":421,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267663812,"hash":"d37f9fdac057492821c305fb08ee6d4f6bca9332"}
{"url":"https://docs.base.org/specifications/transactions/network-fees","domain":"docs.base.org","title":"Network Fees - Base Documentation","text":"​How Do Network Fees on Base Work?\nEvery Base transaction consists of two costs: an L2 (execution) fee and an L1\n(security) fee. The L2 fee is the cost to execute your transaction on the L2,\nand the L1 fee is the estimated cost to publish the transaction on the L1.\nTypically the L1 security fee is higher than the L2 execution fee.\nThe L1 fee will vary depending on the amount of transactions on the L1. If the\ntiming of your transaction is flexible, you can save costs by submitting\ntransactions during periods of lower gas on the L1 (for example, over the\nweekend)\nSimilarly, the L2 fee can increase and decrease depending on how many\ntransactions are being submitted to the L2. This adjustment mechanism has the\nsame implementation as the L1; you can read more in\nCoinbase’s guide to EIP-1559.\nFor additional details about fee calculation on Base, please refer to the\nnetwork fees specification.\n​Minimum Base Fee\nAs part of the Jovian upgrade, Base introduced a minimum base fee. This feature sets a floor for the L2 base fee, preventing it from dropping to extremely low levels during periods of low network activity.\nThe minimum base fee for Base Mainnet is 5,000,000 wei (0.005 gwei). This value may be periodically adjusted as we gather data on how it affects the chain. For reference, a minimum base fee of 0.005 gwei results in a cost of approximately $0.002 for a typical 200,000 gas transaction at an ETH price of $2000.\n​Benefits\n\nFaster Transaction Inclusion: Previously, when low activity caused the base fee to drop very low, spikes in demand could lead to extended periods of congestion before fees rose enough to clear the backlog. With a minimum base fee, transactions are typically included more quickly without users needing to manually adjust priority fees.\nMore Predictable Fees: During normal operation, the base fee will remain at or near the minimum. During congestion, the base fee rises above the minimum. This creates a more predictable fee structure similar to surge pricing.\nSpam Prevention: Extremely low fees can incentivize spam transactions that don’t provide value to the network. The minimum base fee helps price out such activity while keeping fees affordable for legitimate use.\n\n​Current Configuration\nNetworkMinimum Base FeeBase Mainnet5,000,000 wei (0.005 gwei)Base Sepolia5,000,000 wei (0.005 gwei)\nSee the Configuration Changelog for a history of changes to the minimum base fee and other network parameters.\n​EIP-1559 Fee Parameters\nBase uses its own implementation of EIP-1559, which controls how the L2 base fee adjusts in response to network demand. Two key parameters govern this behavior:\n​Elasticity Multiplier\nThe Elasticity Multiplier determines the maximum gas capacity of a block relative to the target gas usage. With an elasticity of 6, blocks can contain up to 6× the target gas, allowing the network to absorb sudden demand spikes.\n​Base Fee Change Denominator\nThe Base Fee Change Denominator controls how quickly the base fee adjusts. A larger denominator means slower, more gradual fee changes. With a denominator of 125, the base fee changes more smoothly compared to lower values.\n​Maximum Rate of Change\nThe maximum rate of base fee change per block is calculated as:\nMax increase per block = (Elasticity - 1) / Denominator\nWith the current parameters (Elasticity = 6, Denominator = 125):\n\nMaximum increase per block: (6 - 1) / 125 = 4%\nMinimum time to double the base fee: 18 blocks × 2 seconds = 36 seconds\n\nThis gradual adjustment helps prevent extreme fee volatility during traffic spikes while still allowing the network to respond to sustained demand.\n​Current Configuration\nNetworkElasticityDenominatorMax Change/BlockBase Mainnet61254%Base Sepolia61254%\n​Querying the L1 Fee\nThe GasPriceOracle predeployment at 0x420000000000000000000000000000000000000F (listed in Contract Addresses) lets you programmatically estimate the L1 fee component before signing and submitting a transaction.\nMethodReturnsgetL1Fee(bytes)Exact L1 fee for a fully serialized (RLP-encoded) transactiongetL1FeeUpperBound(uint256 txSize)Upper-bound L1 fee estimate from approximate transaction byte lengthl1BaseFee()Current Ethereum L1 base fee as seen by BaseblobBaseFee()Current EIP-4844 blob base feebaseFeeScalar()Scalar applied to the L1 base fee componentblobBaseFeeScalar()Scalar applied to the blob base fee component\nUse getL1FeeUpperBound when you need a quick estimate before the transaction is fully constructed. Use getL1Fee with the complete serialized transaction for an exact value before signing.Was this page helpful?Suggest editsRaise issue","tokens":1151,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267667464,"hash":"5aa62ba99b586a9c21dd72c2071dcc5be847fde0"}
{"url":"https://ethresear.ch/t/using-icos-to-fund-science/920","domain":"ethresear.ch","title":"Using ICOs to fund science - Better ICOs - Ethereum Research","text":"Using ICOs to fund science \n\n Better ICOs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 1 / 26\n\n Jan 2018\n\n May 2018\n\n post by kladkogex on Jan 26, 2018\n\n kladkogex\n\n Currently, most whitepapers cite scientific papers, but academia people get little from the ICOs.\nHere is a proposal how science could be funded by ICOs:\n\nAn ICO would voluntary commit, say 1% of proceeds to the science used by the technology.\n\nThe LATEX citations section of the whitepaper would include allocations of the proceeds in percentages. Basically, the whitepaper author would decide to allocate, say, 7% to one citation, 5% to another citation etc., the total being 100%.\n\nThen in a pass-through fashion, each scientific paper would voluntarily allocate the percentages to the papers it cites. So if my paper cites papers X,Y, Z I could allocate 40% to myself, 15% X, 20% to Y and 25% to Z.\n\nAs a result, you could have every paper to include smart-contract readable allocations, and then a smart contract would essentially create a network flow of money from ICOs to papers cited in the whitepaper, then to second level citations, third level citations etc.\n\nWhen a professor moves to one university to another, she could “take” her papers with her, so the university would receive funding from the sum of contributions of its faculty.\n\n Incentives for running full Ethereum nodes\n\n 6\n\n 3\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by vbuterin on Jan 26, 2018\n\n vbuterin\n\n Interesting! Basically an airdrop into a reputation system for academia. I’d support this.\nAnother idea is that at the time that they write their papers, scientists could issue tokens for the paper and if desired sell them; then the airdrop would go to the token holders. This could allow scientists to pre-fund work, as well as creating a prediction market for how influential work would be in the future, which may be useful to society for informational purposes.\n\n post by dillchen on Jan 27, 2018\n\n dillchen\n\n @kladkogex I’m glad someone posted about this. I had some thoughts along these lines as well -> here. They’re a bit messy, so I’ll just summarize below.\n\nResearch coin distribution event (ICO? or just give it researchers and other stake holders)\nEach paper, when hits preprint server starts a game.\n\nperhaps authors of papers have to stake money as well???\n\nOwners stake research coin so they can peer review this paper\nWe gather a set pool of staked money for the paper\n\nThey decide on the validity of the paper\nAnd how to initially distribute the distribution of said paper’s individual token in proportion to owners and citations to other papers.\nThis is some type of schelling point game.\n\nAccurate schelling point people are rewarded with some new research coin (in some proportion to how much was staked)\n\nSlashing the stake of bad reporters\n\nOnce paper schelling point is set, then distribute locked research token recursively to owners of said paper’s token with pro rata of schelling point.\n\nIntuition is that peer reviews want to review important papers and therefore will stake tokens to do this.\nMore important papers get more staked token\nMore token flows recursively to the owners of the paper’s token.\nI guess this is technically securitizing basic research IP, lol\n\nMarkets develop for individual paper’s token. These may later on yield great research results and therefore generate recursive payments of research token. As more papers get published, flow of money goes recursively to the paper parent papers/owners. The price of the token’s paper, denominated in research coin may\n\nRecursive ownership is important because it incentivizes research with the greatest NPV in terms of research coin.\nResearchers who publish should get steady payouts as more papers cite them, so they can continue to fund more research.\n\nNicola at Protocol Labs has written about this as well. https://nicola.io/research-coin/2017\n\n post by nicola on Jan 28, 2018\n\n post by mattiasbergstrom on Jan 29, 2018\n\n post by FBrinkkemper on Jan 29, 2018\n\n post by kladkogex on Jan 29, 2018\n\n post by bpolania on Jan 31, 2018\n\n post by kladkogex on Feb 1, 2018\n\n post by bpolania on Feb 1, 2018\n\n post by jamesray1 on Feb 2, 2018\n\n post by bpolania on Feb 2, 2018\n\n post by rumkin on Feb 8, 2018\n\n 1 month later\n\n post by akomba on Mar 18, 2018\n\n 10 days later\n\n post by musalbas on Mar 28, 2018\n\n post by MariusVanDerWijden on Apr 1, 2018\n\n post by 7hKBg82PX on Apr 3, 2018\n\n post by kladkogex on Apr 3, 2018\n\n post by 7hKBg82PX on Apr 3, 2018\n\n post by david.hite on Apr 4, 2018\n\n Load more posts below","tokens":1144,"squid":"ink-research","role":"Deep Scholar","at":1791267667514,"hash":"c10addd00a3ab184164fd7144633015e045887a5"}
{"url":"https://docs.base.org/specifications/transactions/troubleshooting-transactions","domain":"docs.base.org","title":"Troubleshooting Transactions - Base Documentation","text":"​Transaction Not Being Included\nIf your transaction is pending for longer than expected, check the following:\n​Max Fee Too Low\nIf your maxFeePerGas is lower than the current base fee, your transaction will remain pending until the base fee drops to your specified level.\nSolution: The maxFeePerGas must cover both the base fee and your priority fee. Since the base fee can change with each block, set maxFeePerGas high enough to remain valid even if the base fee rises while your transaction is pending. A common approach is:\nMax Fee FormulamaxFeePerGas = baseFee * 2 + maxPriorityFeePerGas\n\nThis formula (used by ethers.js) provides headroom for the base fee to double before your transaction becomes unexecutable. You only pay the actual base fee at inclusion time, not the maximum.\nBase has a minimum base fee. Transactions with maxFeePerGas below this value will never be included, since the base fee cannot drop below the minimum.\n​Priority Fee Too Low\nDuring periods of high demand, transactions compete for block space through priority fees. If your priority fee is too low relative to other transactions, yours may be delayed.\nSolution: Most users simply wait for congestion to subside. For time-sensitive transactions, use eth_maxPriorityFeePerGas to get a priority fee estimate that can outbid enough recent transactions to be included.\nIf DA throttling is currently in effect, there’s no RPC endpoint that calculates priority fee estimates with throttling in mind. During DA throttling, even transactions with high priority fees may be delayed as the sequencer limits L2 transactions to manage its L1 data availability throughput.\n​Nonce Gap\nIf you have a pending transaction with nonce N, all transactions with nonce N+1 or higher will queue behind it, regardless of their fees.\nSolution: Either wait for the pending transaction to be included, or replace it by submitting a new transaction with the same nonce and a higher fee (at least 10% higher maxPriorityFeePerGas and maxFeePerGas).\n​Nonce Too Low\nIf you submit a transaction with a nonce that has already been used, it will be rejected.\nSolution: Query your current nonce using eth_getTransactionCount with the pending tag to get the next available nonce.\n​Transaction Rejected\n​Gas Limit Exceeds Maximum\nBase enforces a per-transaction gas maximum of 16,777,216 gas (2^24). Transactions specifying a higher gas limit are rejected during block validation.\nError: exceeds maximum per-transaction gas limit\nSolution: Reduce the gas limit to 16,777,216 (2^24) or below. If your transaction genuinely requires more gas, you’ll need to break it into multiple transactions.\n​Transaction Included but Failed\nIf your transaction was included in a block but shows a failed status:\n​Out of Gas\nThe transaction ran out of gas during execution.\nSolution: Increase the gas limit. Use eth_estimateGas to get a gas estimate, then add a buffer (e.g., 20%) to account for variability.\n​Reverted by Contract\nThe contract execution encountered a revert condition.\nSolution: Check the transaction on Basescan to see the revert reason. Common causes include failed require statements, arithmetic errors, or invalid state transitions.\n​Slow Confirmation\n​Understanding Confirmation Times\nBase produces blocks every 2 seconds, but Flashblocks provide preconfirmations every 200ms.\nConfirmation LevelTimeDescriptionFlashblock preconfirmation~200msTransaction included in a preconfirmationL2 block inclusion~2sTransaction included in a sealed L2 blockL1 batch inclusion~2mTransaction posted to EthereumL1 finality~20mEthereum batch is finalized\nSee Transaction Finality for more details.\n​Using Flashblocks for Faster Confirmations\nTo get the fastest possible confirmation, use a Flashblocks-aware RPC endpoint:\nNetworkFlashblocks RPCMainnethttps://mainnet.base.orgSepoliahttps://sepolia.base.org\nThese endpoints return transaction receipts as soon as a transaction is included in a Flashblock, rather than waiting for the full L2 block.\n​Debugging Tools\n\nBasescan: View transaction status, logs, and revert reasons\nTenderly: Simulate and debug transactions\neth_call: Test contract calls without submitting a transaction\neth_estimateGas: Estimate gas usage before submitting\n\n​Getting Help\nIf you’re still experiencing issues, reach out in the #developer-chat channel in the Base Discord.Was this page helpful?Suggest editsRaise issue","tokens":1095,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267678891,"hash":"68fa127afd07d5da8c8b2d37083c1d6fcf11966f"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/index.html","domain":"docs.soliditylang.org","title":"Solidity — Solidity 0.8.31-develop documentation","text":"Solidity\n\n Edit on GitHub\n\nSolidity\nSolidity is an object-oriented, high-level language for implementing smart contracts.\nSmart contracts are programs that govern the behavior of accounts within the Ethereum state.\nSolidity is a curly-bracket language designed to target the Ethereum Virtual Machine (EVM).\nIt is influenced by C++, Python, and JavaScript.\nYou can find more details about which languages Solidity has been inspired by in the language influences section.\nSolidity is statically typed, supports inheritance, libraries, and complex user-defined types, among other features.\nWith Solidity, you can create contracts for uses such as voting, crowdfunding, blind auctions, and multi-signature wallets.\nWhen deploying contracts, you should use the latest released version of Solidity.\nApart from exceptional cases, only the latest version receives\nsecurity fixes.\nFurthermore, breaking changes, as well as new features, are introduced regularly.\nWe currently use a 0.y.z version number to indicate this fast pace of change.\n\nWarning\nSolidity recently released the 0.8.x version that introduced a lot of breaking changes.\nMake sure you read the full list.\n\nIdeas for improving Solidity or this documentation are always welcome,\nread our contributors guide for more details.\n\nHint\nYou can download this documentation as PDF, HTML or Epub\nby clicking on the versions flyout menu in the bottom-right corner and selecting the preferred download format.\n\nGetting Started\n1. Understand the Smart Contract Basics\nIf you are new to the concept of smart contracts, we recommend you to get started by digging into the “Introduction to Smart Contracts” section, which covers the following:\n\nA simple example smart contract written in Solidity.\nBlockchain Basics.\nThe Ethereum Virtual Machine.\n\n2. Get to Know Solidity\nOnce you are accustomed to the basics, we recommend you read the “Solidity by Example”\nand “Language Description” sections to understand the core concepts of the language.\n3. Install the Solidity Compiler\nThere are various ways to install the Solidity compiler,\nsimply choose your preferred option and follow the steps outlined on the installation page.\n\nHint\nYou can try out code examples directly in your browser with the\nRemix IDE.\nRemix is a web browser-based IDE that allows you to write, deploy and administer Solidity smart contracts,\nwithout the need to install Solidity locally.\n\nWarning\nAs humans write software, it can have bugs.\nTherefore, you should follow established software development best practices when writing your smart contracts.\nThis includes code review, testing, audits, and correctness proofs.\nSmart contract users are sometimes more confident with code than their authors,\nand blockchains and smart contracts have their own unique issues to watch out for,\nso before working on production code, make sure you read the Security Considerations section.\n\n4. Learn More\nIf you want to learn more about building decentralized applications on Ethereum,\nthe Ethereum Developer Resources can help you with further general documentation around Ethereum,\nand a wide selection of tutorials, tools, and development frameworks.\nIf you have any questions, you can try searching for answers or asking on the\nEthereum StackExchange,\nor our Gitter channel.\n\nTranslations\nCommunity contributors help translate this documentation into several languages.\nNote that they have varying degrees of completeness and up-to-dateness.\nThe English version stands as a reference.\nYou can switch between languages by clicking on the flyout menu in the bottom-right corner\nand selecting the preferred language.\n\nChinese\nFrench\nIndonesian\nJapanese\nKorean\nPersian\nRussian\nSpanish\nTurkish\n\nNote\nWe set up a GitHub organization and translation workflow to help streamline the community efforts.\nPlease refer to the translation guide in the solidity-docs org\nfor information on how to start a new language or contribute to the community translations.\n\nContents\nKeyword Index, Search Page\n\nBasics\n\nIntroduction to Smart Contracts\nA Simple Smart Contract\nBlockchain Basics\nThe Ethereum Virtual Machine\n\nSolidity by Example\nVoting\nBlind Auction\nSafe Remote Purchase\nMicropayment Channel\nModular Contracts\n\nInstalling the Solidity Compiler\nVersioning\nRemix\nnpm / Node.js\nDocker\nLinux Packages\nmacOS Packages\nStatic Binaries\nBuilding from Source\nCMake Options\nThe Version String in Detail\nImportant Information About Versioning\n\nLanguage Description\n\nLayout of a Solidity Source File\nSPDX License Identifier\nPragmas\nImporting other Source Files\nComments\n\nStructure of a Contract\nState Variables\nFunctions\nFunction Modifiers\nEvents\nErrors\nStruct Types\nEnum Types\n\nTypes\nValue Types\nReference Types\nMapping Types\nOperators\nConversions between Elementary Types\nConversions between Literals and Elementary Types\n\nUnits and Globally Available Variables\nEther Units\nTime Units\nSpecial Variables and Functions\nReserved Keywords\n\nExpressions and Control Structures\nControl Structures\nFunction Calls\nCreating Contracts via new\nOrder of Evaluation of Expressions\nAssignment\nScoping and Declarations\nChecked or Unchecked Arithmetic\nError handling: Assert, Require, Revert and Exceptions\n\nContracts\nCreating Contracts\nVisibility and Getters\nFunction Modifiers\nTransient Storage\nComposability of Smart Contracts and the Caveats of Transient Storage\nConstant and Immutable State Variables\nCustom Storage Layout\nFunctions\nEvents\nCustom Errors\nInheritance\nAbstract Contracts\nInterfaces\nLibraries\nUsing For\n\nInline Assembly\nExample\nAccess to External Variables, Functions and Libraries\nThings to Avoid\nConventions in Solidity\nAdvanced Safe Use of Memory\n\nCheatsheet\nOrder of Precedence of Operators\nABI Encoding and Decoding Functions\nMembers of bytes and string\nMembers of address\nBlock and Transaction Properties\nValidations and Assertions\nMathematical and Cryptographic Functions\nContract-related\nType Information\nFunction Visibility Specifiers\nModifiers\n\nLanguage Grammar\nSolidityParser\nSolidityLexer\n\nCompiler\n\nUsing the Compiler\nUsing the Commandline Compiler\nSetting the EVM Version to Target\nCompiler Input and Output JSON Description\n\nAnalysing the Compiler Output\nSolidity IR-based Codegen Changes\nSemantic Only Changes\nInternals\n\nInternals\n\nLayout of State Variables in Storage and Transient Storage\nMappings and Dynamic Arrays\nJSON Output\n\nLayout in Memory\nDifferences to Layout in Storage\n\nLayout of Call Data\nCleaning Up Variables\nSource Mappings\nThe Optimizer\nBenefits of Optimizing Solidity Code\nDifferences between Optimized and Non-Optimized Code\nOptimizer Parameter Runs\nOpcode-Based Optimizer Module\nYul-Based Optimizer Module\nCodegen-Based Optimizer Module\n\nContract Metadata\nEncoding of the Metadata Hash in the Bytecode\nUsage for Automatic Interface Generation and NatSpec\nUsage for Source Code Verification\n\nContract ABI Specification\nBasic Design\nFunction Selector\nArgument Encoding\nTypes\nDesign Criteria for the Encoding\nFormal Specification of the Encoding\nFunction Selector and Argument Encoding\nExamples\nUse of Dynamic Types\nEvents\nErrors\nJSON\nStrict Encoding Mode\nNon-standard Packed Mode\nEncoding of Indexed Event Parameters\n\nAdvisory content\n\nSecurity Considerations\nPitfalls\nRecommendations\n\nList of Known Bugs\nSolidity v0.5.0 Breaking Changes\nSemantic Only Changes\nSemantic and Syntactic Changes\nExplicitness Requirements\nDeprecated Elements\nInteroperability With Older Contracts\nExample\n\nSolidity v0.6.0 Breaking Changes\nChanges the Compiler Might not Warn About\nExplicitness Requirements\nSemantic and Syntactic Changes\nNew Features\nInterface Changes\nHow to update your code\n\nSolidity v0.7.0 Breaking Changes\nSilent Changes of the Semantics\nChanges to the Syntax\nRemoval of Unused or Unsafe Features\nInterface Changes\nHow to update your code\n\nSolidity v0.8.0 Breaking Changes\nSilent Changes of the Semantics\nNew Restrictions\nInterface Changes\nHow to update your code\n\nAdditional Material\n\nNatSpec Format\nDocumentation Example\nTags\nDocumentation Output\n\nSMTChecker and Formal Verification\nTutorial\nSMTChecker Options and Tuning\nAbstraction and False Positives\nReal World Assumptions\n\nYul\nMotivation and High-level Description\nSimple Example\nStand-Alone Usage\nInformal Description of Yul\nSpecification of Yul\nSpecification of Yul Object\nYul Optimizer\nComplete ERC20 Example\n\nImport Path Resolution\nVirtual Filesystem\nImports\nBase Path and Include Paths\nAllowed Paths\nImport Remapping\nUsing URLs in imports\n\nResources\n\nStyle Guide\nIntroduction\nCode Layout\nOrder of Layout\nNaming Conventions\nNatSpec\n\nCommon Patterns\nWithdrawal from Contracts\nRestricting Access\nState Machine\n\nResources\nGeneral Resources\nIntegrated (Ethereum) Development Environments\nEditor Integrations\nSolidity Tools\nThird-Party Solidity Parsers and Grammars\n\nContributing\nTeam Calls\nHow to Report Issues\nWorkflow for Pull Requests\nRunning the Compiler Tests\nRunning the Fuzzer via AFL\nWhiskers\nDocumentation Style Guide\nSolidity Language Design\n\nLanguage Influences\nSolidity Brand Guide\nThe Solidity Brand\nSolidity Brand Name\nSolidity Logo License\nSolidity Logo Guidelines\nCredits","tokens":2267,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267678937,"hash":"1c83b8f03114345a7d3da5926051601051167420"}
{"url":"https://ethresear.ch/t/using-icos-to-fund-science/920/1","domain":"ethresear.ch","title":"Using ICOs to fund science - Better ICOs - Ethereum Research","text":"Using ICOs to fund science \n\n Better ICOs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 1 / 26\n\n Jan 2018\n\n May 2018\n\n post by kladkogex on Jan 26, 2018\n\n kladkogex\n\n Currently, most whitepapers cite scientific papers, but academia people get little from the ICOs.\nHere is a proposal how science could be funded by ICOs:\n\nAn ICO would voluntary commit, say 1% of proceeds to the science used by the technology.\n\nThe LATEX citations section of the whitepaper would include allocations of the proceeds in percentages. Basically, the whitepaper author would decide to allocate, say, 7% to one citation, 5% to another citation etc., the total being 100%.\n\nThen in a pass-through fashion, each scientific paper would voluntarily allocate the percentages to the papers it cites. So if my paper cites papers X,Y, Z I could allocate 40% to myself, 15% X, 20% to Y and 25% to Z.\n\nAs a result, you could have every paper to include smart-contract readable allocations, and then a smart contract would essentially create a network flow of money from ICOs to papers cited in the whitepaper, then to second level citations, third level citations etc.\n\nWhen a professor moves to one university to another, she could “take” her papers with her, so the university would receive funding from the sum of contributions of its faculty.\n\n Incentives for running full Ethereum nodes\n\n 6\n\n 3\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by vbuterin on Jan 26, 2018\n\n vbuterin\n\n Interesting! Basically an airdrop into a reputation system for academia. I’d support this.\nAnother idea is that at the time that they write their papers, scientists could issue tokens for the paper and if desired sell them; then the airdrop would go to the token holders. This could allow scientists to pre-fund work, as well as creating a prediction market for how influential work would be in the future, which may be useful to society for informational purposes.\n\n post by dillchen on Jan 27, 2018\n\n dillchen\n\n @kladkogex I’m glad someone posted about this. I had some thoughts along these lines as well -> here. They’re a bit messy, so I’ll just summarize below.\n\nResearch coin distribution event (ICO? or just give it researchers and other stake holders)\nEach paper, when hits preprint server starts a game.\n\nperhaps authors of papers have to stake money as well???\n\nOwners stake research coin so they can peer review this paper\nWe gather a set pool of staked money for the paper\n\nThey decide on the validity of the paper\nAnd how to initially distribute the distribution of said paper’s individual token in proportion to owners and citations to other papers.\nThis is some type of schelling point game.\n\nAccurate schelling point people are rewarded with some new research coin (in some proportion to how much was staked)\n\nSlashing the stake of bad reporters\n\nOnce paper schelling point is set, then distribute locked research token recursively to owners of said paper’s token with pro rata of schelling point.\n\nIntuition is that peer reviews want to review important papers and therefore will stake tokens to do this.\nMore important papers get more staked token\nMore token flows recursively to the owners of the paper’s token.\nI guess this is technically securitizing basic research IP, lol\n\nMarkets develop for individual paper’s token. These may later on yield great research results and therefore generate recursive payments of research token. As more papers get published, flow of money goes recursively to the paper parent papers/owners. The price of the token’s paper, denominated in research coin may\n\nRecursive ownership is important because it incentivizes research with the greatest NPV in terms of research coin.\nResearchers who publish should get steady payouts as more papers cite them, so they can continue to fund more research.\n\nNicola at Protocol Labs has written about this as well. https://nicola.io/research-coin/2017\n\n post by nicola on Jan 28, 2018\n\n nicola\n\n Awesome to read this here! (thank for the mention! )\nI once did a braindump of possible ideas to make this happen (although they are good intuition, I don’t believe they work in practice). The general idea is to combine prediction markets with peer review:\n\nResearch Coin: first attempt\nResearch Coin: second attempt\n\nHave fun, hope to see good ideas out of this!\n\n post by mattiasbergstrom on Jan 29, 2018\n\n mattiasbergstrom\n\n I believe that the right idea is to get rewarded by the papers use as in quoted or referenced, so for a researcher a kind of reputation system, then I also like the idea of @vbuterin to be able to pre-sell access to a specific research area, the only question there is if it could skew the research in a specific way, but I believe that finding new ways to found research should really be a core topic for ICO/crypto investors.\nhttp://ieeexplore.ieee.org/document/7933951/ with 244 downloads I could have gotten some coins out of that paper \n\n post by FBrinkkemper on Jan 29, 2018\n\n FBrinkkemper\n\n While I really like the general use case, I really hope this technology does not result in a popularization of science, in the sense that only really popular research gets proper funding, while newer and fundamental research gets less funding.\nI do really like this idea though for the development of open source code and funneling the ICO capital through the dependencies. So proper general cryptography libraries for example get funded by multiple ICO’s.\nSo for example:\nICO for new Blockchain protocol where 60% of the received funds are used for the development. Then they can spend that by allocating 50% to their own code, and 10% to 5 big dependencies for example. Those dependencies can do the same again.\nIs the above use-case worked on already by anyone’s knowledge?\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\n Yes - I think this is a very good point ! We all need things like good crypto libraries, or and there should be a way to fund this …\n\n post by bpolania on Jan 31, 2018\n\n bpolania\n\n I have always thought that the white paper itself is not required to be a smart-contract, not on it’s entirety but a reflection of the paper document, so in a similar fashion to how gas in managed, the ICO company can set a price for the citation and the author of the paper can decide to accept it or not.\nHaving the white paper in the blockchain will come with additional benefits in terms of accountability but they are outside the scope of this thread, I’ve designed a contract for a white paper, let me know if anyone’s interested.\n\n post by kladkogex on Feb 1, 2018\n\n kladkogex\n\n Boris nice - may be you can share a GitHub link then ?\n\n post by bpolania on Feb 1, 2018\n\n bpolania\n\n I just created a repo for this: https://github.com/bpolania/WhitePaperContract/tree/master\nPlease note that this is a work in progress, it means that it’s untested and is lacking functionality, the main intention is to define how a white paper could be represented in the blockchain, so at this point it’s better if you think of it as pseudo-code.\nAlso, I haven’t though about the citation part up until I read this post, so that functionality is not there but I’ll be adding it gradually.\n\n post by jamesray1 on Feb 2, 2018\n\n jamesray1\n\n Note that the concept of\n\ncan be generalized to airdrops into other reputation systems.\n\n post by bpolania on Feb 2, 2018\n\n bpolania\n\n kladkogex\n\n The github repo now has citation related functionality\n\n post by rumkin on Feb 8, 2018\n\n rumkin\n\n I was thinking about such system but from another angle. What if to create kickstarter for scientists. Scientist or developer may to make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science.\n\n 1 month later\n\n post by akomba on Mar 18, 2018\n\n akomba\n\n jamesray1\n\n Yes, I think generalization would be a good idea – to include support for critical projects in the ecosystem as well (etherscan, etc).\n\n 10 days later\n\n post by musalbas on Mar 28, 2018\n\n musalbas\n\n This is also of interest: MathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\n\nMathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\nAbstract: A public blockchain is proposed in an attempt to enable the coin holders to participate in verifying mathematical theorems for public access. Incentives are designed to encourage any party to contribute their knowledge by buying tokens of mathematical propositions that they believe are true. The proposed blockchain is a platform for people to exchange their belief in mathematical propositions. An implementation of this blockchain proposal, once established, will provide the general public an easy and instant access to reliable knowledge without having to read difficult proofs or having to blindly trust a small number of experts. Conversely, experts from various fields may find it be much easier for making their work appreciated by more people, leading to a better impact. According to the incentive inherently provided by the blockchain, they can even earn significantly if they do prove some theorems that were not previously known by the blockchain. Foundations who are interested in the validity of a particular proposition not yet explicitly recorded on the blockchain can donate a fund, which will distribute to experts who contribute positive efforts toward solving the specified problems. Only the people who erroneously create or buy tokens of a proposition that is eventually proven false will lose money. A reference design of the proposed blockchain that attempts to achieve the above-mentioned goal is described and reasoned.\n\n post by MariusVanDerWijden on Apr 1, 2018\n\n MariusVanDerWijden\n\n bpolania\n\n Is your repository private?\nI tried to write my own implementation, it’s not finished and I’m new to this, so any comments are appreciated\nhttps://github.com/MariusVanDerWijden/smartcontracts/blob/master/FundScience.sol\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n I’m not sure how point two would work in practice; as an academic I do not see the incentive for allocating a certain percentage of my paper to each used citation; this mostly sounds like a lot of extra work and I think people will not fully commit to this.\nFurthermore, another problem which should be taken into account is how academics tend to uplift their h-index by conducting large research and then publishing the results not as one big paper but as multiple smaller ones, whereby their h-index gets increased and they can receive more citations (by both themselves as other scholars). This is a big problem in academia as it is, but it is hard to check for, and this would be a continuous problem if you allocate a percentage based on citations.\nI do not have the answers, but I do think that these are some important issues to take into consideration.\nNotwithstanding this, I think your general idea is good and at the very least a very important problem that the blockchain could help solve.\n\n post by kladkogex on Apr 3, 2018\n\n kladkogex\n\nIn reality it will not be so easy to do: as an academic if you do not allocate to your peers than the community may not like it. As an academic you know that the academic community is very tightly bound (reviewers, funding etc.)\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n Of course, I think I may have explained myself unclearly. I wonder about allocating an exact percentage (and determining that exact percentage, you draw on many sources, often also to support the same claim), not about acknowledging your sources in the first place \n\n post by david.hite on Apr 4, 2018\n\n david.hite\n\n What do you think about this: scientist or developer may make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science. Anyway, it’s better to use ICO rating, if you want to invest your money the best way.\n\n Load more posts below","tokens":3071,"squid":"ink-research","role":"Deep Scholar","at":1791267679142,"hash":"c92cf1596155d275eb21b53a584ad163d592c764"}
{"url":"https://docs.soliditylang.org/en/v0.8.31/080-breaking-changes.html","domain":"docs.soliditylang.org","title":"Solidity v0.8.0 Breaking Changes — Solidity 0.8.31-develop documentation","text":"Solidity v0.8.0 Breaking Changes\n\n Edit on GitHub\n\nSolidity v0.8.0 Breaking Changes\nThis section highlights the main breaking changes introduced in Solidity\nversion 0.8.0.\nFor the full list check\nthe release changelog.\n\nSilent Changes of the Semantics\nThis section lists changes where existing code changes its behavior without\nthe compiler notifying you about it.\n\nArithmetic operations revert on underflow and overflow. You can use unchecked { ... } to use\nthe previous wrapping behavior.\nChecks for overflow are very common, so we made them the default to increase readability of code,\neven if it comes at a slight increase of gas costs.\n\nABI coder v2 is activated by default.\nYou can choose to use the old behavior using pragma abicoder v1;.\nThe pragma pragma experimental ABIEncoderV2; is still valid, but it is deprecated and has no effect.\nIf you want to be explicit, please use pragma abicoder v2; instead.\nNote that ABI coder v2 supports more types than v1 and performs more sanity checks on the inputs.\nABI coder v2 makes some function calls more expensive and it can also make contract calls\nrevert that did not revert with ABI coder v1 when they contain data that does not conform to the\nparameter types.\n\nExponentiation is right associative, i.e., the expression a**b**c is parsed as a**(b**c).\nBefore 0.8.0, it was parsed as (a**b)**c.\nThis is the common way to parse the exponentiation operator.\n\nFailing assertions and other internal checks like division by zero or arithmetic overflow do\nnot use the invalid opcode but instead the revert opcode.\nMore specifically, they will use error data equal to a function call to Panic(uint256) with an error code specific\nto the circumstances.\nThis will save gas on errors while it still allows static analysis tools to distinguish\nthese situations from a revert on invalid input, like a failing require.\n\nIf a byte array in storage is accessed whose length is encoded incorrectly, a panic is caused.\nA contract cannot get into this situation unless inline assembly is used to modify the raw representation of storage byte arrays.\nIf constants are used in array length expressions, previous versions of Solidity would use arbitrary precision\nin all branches of the evaluation tree. Now, if constant variables are used as intermediate expressions,\ntheir values will be properly rounded in the same way as when they are used in run-time expressions.\nThe type byte has been removed. It was an alias of bytes1.\n\nNew Restrictions\nThis section lists changes that might cause existing contracts to not compile anymore.\n\nThere are new restrictions related to explicit conversions of literals. The previous behavior in\nthe following cases was likely ambiguous:\n\nExplicit conversions from negative literals and literals larger than type(uint160).max to\naddress are disallowed.\nExplicit conversions between literals and an integer type T are only allowed if the literal\nlies between type(T).min and type(T).max. In particular, replace usages of uint(-1)\nwith type(uint).max.\nExplicit conversions between literals and enums are only allowed if the literal can\nrepresent a value in the enum.\nExplicit conversions between literals and address type (e.g. address(literal)) have the\ntype address instead of address payable. One can get a payable address type by using an\nexplicit conversion, i.e., payable(literal).\n\nAddress literals have the type address instead of address\npayable. They can be converted to address payable by using an explicit conversion, e.g.\npayable(0xdCad3a6d3569DF655070DEd06cb7A1b2Ccd1D3AF).\nThere are new restrictions on explicit type conversions. The conversion is only allowed when there\nis at most one change in sign, width or type-category (int, address, bytesNN, etc.).\nTo perform multiple changes, use multiple conversions.\nLet us use the notation T(S) to denote the explicit conversion T(x), where, T and\nS are types, and x is any arbitrary variable of type S. An example of such a\ndisallowed conversion would be uint16(int8) since it changes both width (8 bits to 16 bits)\nand sign (signed integer to unsigned integer). In order to do the conversion, one has to go\nthrough an intermediate type. In the previous example, this would be uint16(uint8(int8)) or\nuint16(int16(int8)). Note that the two ways to convert will produce different results e.g.,\nfor -1. The following are some examples of conversions that are disallowed by this rule.\n\naddress(uint) and uint(address): converting both type-category and width. Replace this by\naddress(uint160(uint)) and uint(uint160(address)) respectively.\npayable(uint160), payable(bytes20) and payable(integer-literal): converting both\ntype-category and state-mutability. Replace this by payable(address(uint160)),\npayable(address(bytes20)) and payable(address(integer-literal)) respectively. Note that\npayable(0) is valid and is an exception to the rule.\nint80(bytes10) and bytes10(int80): converting both type-category and sign. Replace this by\nint80(uint80(bytes10)) and bytes10(uint80(int80) respectively.\nContract(uint): converting both type-category and width. Replace this by\nContract(address(uint160(uint))).\n\nThese conversions were disallowed to avoid ambiguity. For example, in the expression uint16 x =\nuint16(int8(-1)), the value of x would depend on whether the sign or the width conversion\nwas applied first.\n\nFunction call options can only be given once, i.e. c.f{gas: 10000}{value: 1}() is invalid and has to be changed to c.f{gas: 10000, value: 1}().\nThe global functions log0, log1, log2, log3 and log4 have been removed.\nThese are low-level functions that were largely unused. Their behavior can be accessed from inline assembly.\n\nenum definitions cannot contain more than 256 members.\nThis will make it safe to assume that the underlying type in the ABI is always uint8.\n\nDeclarations with the name this, super and _ are disallowed, with the exception of\npublic functions and events. The exception is to make it possible to declare interfaces of contracts\nimplemented in languages other than Solidity that do permit such function names.\nRemove support for the \\b, \\f, and \\v escape sequences in code.\nThey can still be inserted via hexadecimal escapes, e.g. \\x08, \\x0c, and \\x0b, respectively.\nThe global variables tx.origin and msg.sender have the type address instead of\naddress payable. One can convert them into address payable by using an explicit\nconversion, i.e., payable(tx.origin) or payable(msg.sender).\nThis change was done since the compiler cannot determine whether or not these addresses\nare payable or not, so it now requires an explicit conversion to make this requirement visible.\n\nExplicit conversion into address type always returns a non-payable address type. In\nparticular, the following explicit conversions have the type address instead of address\npayable:\n\naddress(u) where u is a variable of type uint160. One can convert u\ninto the type address payable by using two explicit conversions, i.e.,\npayable(address(u)).\naddress(b) where b is a variable of type bytes20. One can convert b\ninto the type address payable by using two explicit conversions, i.e.,\npayable(address(b)).\naddress(c) where c is a contract. Previously, the return type of this\nconversion depended on whether the contract can receive Ether (either by having a receive\nfunction or a payable fallback function). The conversion payable(c) has the type address\npayable and is only allowed when the contract c can receive Ether. In general, one can\nalways convert c into the type address payable by using the following explicit\nconversion: payable(address(c)). Note that address(this) falls under the same category\nas address(c) and the same rules apply for it.\n\nThe chainid builtin in inline assembly is now considered view instead of pure.\nUnary negation cannot be used on unsigned integers anymore, only on signed integers.\n\nInterface Changes\n\nThe output of --combined-json has changed: JSON fields abi, devdoc, userdoc and\nstorage-layout are sub-objects now. Before 0.8.0 they used to be serialised as strings.\nThe “legacy AST” has been removed (--ast-json on the commandline interface and legacyAST for standard JSON).\nUse the “compact AST” (--ast-compact-json resp. AST) as replacement.\nThe old error reporter (--old-reporter) has been removed.\n\nHow to update your code\n\nIf you rely on wrapping arithmetic, surround each operation with unchecked { ... }.\nOptional: If you use SafeMath or a similar library, change x.add(y) to x + y, x.mul(y) to x * y etc.\nAdd pragma abicoder v1; if you want to stay with the old ABI coder.\nOptionally remove pragma experimental ABIEncoderV2 or pragma abicoder v2 since it is redundant.\nChange byte to bytes1.\nAdd intermediate explicit type conversions if required.\nCombine c.f{gas: 10000}{value: 1}() to c.f{gas: 10000, value: 1}().\nChange msg.sender.transfer(x) to payable(msg.sender).transfer(x) or use a stored variable of address payable type.\nChange x**y**z to (x**y)**z.\nUse inline assembly as a replacement for log0, …, log4.\nNegate unsigned integers by subtracting them from the maximum value of the type and adding 1 (e.g. type(uint256).max - x + 1, while ensuring that x is not zero)","tokens":2289,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267688853,"hash":"6c1fe28bebfc06b374397a56bf851192a645a5cf"}
{"url":"https://ethresear.ch/t/using-icos-to-fund-science/920/2","domain":"ethresear.ch","title":"Using ICOs to fund science - Better ICOs - Ethereum Research","text":"Better ICOs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 2 / 26\n\n Jan 2018\n\n May 2018\n\n post by kladkogex on Jan 26, 2018\n\n kladkogex\n\n Currently, most whitepapers cite scientific papers, but academia people get little from the ICOs.\nHere is a proposal how science could be funded by ICOs:\n\nAn ICO would voluntary commit, say 1% of proceeds to the science used by the technology.\n\nThe LATEX citations section of the whitepaper would include allocations of the proceeds in percentages. Basically, the whitepaper author would decide to allocate, say, 7% to one citation, 5% to another citation etc., the total being 100%.\n\nThen in a pass-through fashion, each scientific paper would voluntarily allocate the percentages to the papers it cites. So if my paper cites papers X,Y, Z I could allocate 40% to myself, 15% X, 20% to Y and 25% to Z.\n\nAs a result, you could have every paper to include smart-contract readable allocations, and then a smart contract would essentially create a network flow of money from ICOs to papers cited in the whitepaper, then to second level citations, third level citations etc.\n\nWhen a professor moves to one university to another, she could “take” her papers with her, so the university would receive funding from the sum of contributions of its faculty.\n\n Incentives for running full Ethereum nodes\n\n 6\n\n 3\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by vbuterin on Jan 26, 2018\n\n vbuterin\n\n Interesting! Basically an airdrop into a reputation system for academia. I’d support this.\nAnother idea is that at the time that they write their papers, scientists could issue tokens for the paper and if desired sell them; then the airdrop would go to the token holders. This could allow scientists to pre-fund work, as well as creating a prediction market for how influential work would be in the future, which may be useful to society for informational purposes.\n\n post by dillchen on Jan 27, 2018\n\n dillchen\n\n @kladkogex I’m glad someone posted about this. I had some thoughts along these lines as well -> here. They’re a bit messy, so I’ll just summarize below.\n\nResearch coin distribution event (ICO? or just give it researchers and other stake holders)\nEach paper, when hits preprint server starts a game.\n\nperhaps authors of papers have to stake money as well???\n\nOwners stake research coin so they can peer review this paper\nWe gather a set pool of staked money for the paper\n\nThey decide on the validity of the paper\nAnd how to initially distribute the distribution of said paper’s individual token in proportion to owners and citations to other papers.\nThis is some type of schelling point game.\n\nAccurate schelling point people are rewarded with some new research coin (in some proportion to how much was staked)\n\nSlashing the stake of bad reporters\n\nOnce paper schelling point is set, then distribute locked research token recursively to owners of said paper’s token with pro rata of schelling point.\n\nIntuition is that peer reviews want to review important papers and therefore will stake tokens to do this.\nMore important papers get more staked token\nMore token flows recursively to the owners of the paper’s token.\nI guess this is technically securitizing basic research IP, lol\n\nMarkets develop for individual paper’s token. These may later on yield great research results and therefore generate recursive payments of research token. As more papers get published, flow of money goes recursively to the paper parent papers/owners. The price of the token’s paper, denominated in research coin may\n\nRecursive ownership is important because it incentivizes research with the greatest NPV in terms of research coin.\nResearchers who publish should get steady payouts as more papers cite them, so they can continue to fund more research.\n\nNicola at Protocol Labs has written about this as well. https://nicola.io/research-coin/2017\n\n post by nicola on Jan 28, 2018\n\n nicola\n\n Awesome to read this here! (thank for the mention! )\nI once did a braindump of possible ideas to make this happen (although they are good intuition, I don’t believe they work in practice). The general idea is to combine prediction markets with peer review:\n\nResearch Coin: first attempt\nResearch Coin: second attempt\n\nHave fun, hope to see good ideas out of this!\n\n post by mattiasbergstrom on Jan 29, 2018\n\n mattiasbergstrom\n\n I believe that the right idea is to get rewarded by the papers use as in quoted or referenced, so for a researcher a kind of reputation system, then I also like the idea of @vbuterin to be able to pre-sell access to a specific research area, the only question there is if it could skew the research in a specific way, but I believe that finding new ways to found research should really be a core topic for ICO/crypto investors.\nhttp://ieeexplore.ieee.org/document/7933951/ with 244 downloads I could have gotten some coins out of that paper \n\n post by FBrinkkemper on Jan 29, 2018\n\n FBrinkkemper\n\n While I really like the general use case, I really hope this technology does not result in a popularization of science, in the sense that only really popular research gets proper funding, while newer and fundamental research gets less funding.\nI do really like this idea though for the development of open source code and funneling the ICO capital through the dependencies. So proper general cryptography libraries for example get funded by multiple ICO’s.\nSo for example:\nICO for new Blockchain protocol where 60% of the received funds are used for the development. Then they can spend that by allocating 50% to their own code, and 10% to 5 big dependencies for example. Those dependencies can do the same again.\nIs the above use-case worked on already by anyone’s knowledge?\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\n Yes - I think this is a very good point ! We all need things like good crypto libraries, or and there should be a way to fund this …\n\n post by bpolania on Jan 31, 2018\n\n bpolania\n\n I have always thought that the white paper itself is not required to be a smart-contract, not on it’s entirety but a reflection of the paper document, so in a similar fashion to how gas in managed, the ICO company can set a price for the citation and the author of the paper can decide to accept it or not.\nHaving the white paper in the blockchain will come with additional benefits in terms of accountability but they are outside the scope of this thread, I’ve designed a contract for a white paper, let me know if anyone’s interested.\n\n post by kladkogex on Feb 1, 2018\n\n kladkogex\n\n Boris nice - may be you can share a GitHub link then ?\n\n post by bpolania on Feb 1, 2018\n\n bpolania\n\n I just created a repo for this: https://github.com/bpolania/WhitePaperContract/tree/master\nPlease note that this is a work in progress, it means that it’s untested and is lacking functionality, the main intention is to define how a white paper could be represented in the blockchain, so at this point it’s better if you think of it as pseudo-code.\nAlso, I haven’t though about the citation part up until I read this post, so that functionality is not there but I’ll be adding it gradually.\n\n post by jamesray1 on Feb 2, 2018\n\n jamesray1\n\n Note that the concept of\n\ncan be generalized to airdrops into other reputation systems.\n\n post by bpolania on Feb 2, 2018\n\n bpolania\n\n kladkogex\n\n The github repo now has citation related functionality\n\n post by rumkin on Feb 8, 2018\n\n rumkin\n\n I was thinking about such system but from another angle. What if to create kickstarter for scientists. Scientist or developer may to make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science.\n\n 1 month later\n\n post by akomba on Mar 18, 2018\n\n akomba\n\n jamesray1\n\n Yes, I think generalization would be a good idea – to include support for critical projects in the ecosystem as well (etherscan, etc).\n\n 10 days later\n\n post by musalbas on Mar 28, 2018\n\n musalbas\n\n This is also of interest: MathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\n\nMathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\nAbstract: A public blockchain is proposed in an attempt to enable the coin holders to participate in verifying mathematical theorems for public access. Incentives are designed to encourage any party to contribute their knowledge by buying tokens of mathematical propositions that they believe are true. The proposed blockchain is a platform for people to exchange their belief in mathematical propositions. An implementation of this blockchain proposal, once established, will provide the general public an easy and instant access to reliable knowledge without having to read difficult proofs or having to blindly trust a small number of experts. Conversely, experts from various fields may find it be much easier for making their work appreciated by more people, leading to a better impact. According to the incentive inherently provided by the blockchain, they can even earn significantly if they do prove some theorems that were not previously known by the blockchain. Foundations who are interested in the validity of a particular proposition not yet explicitly recorded on the blockchain can donate a fund, which will distribute to experts who contribute positive efforts toward solving the specified problems. Only the people who erroneously create or buy tokens of a proposition that is eventually proven false will lose money. A reference design of the proposed blockchain that attempts to achieve the above-mentioned goal is described and reasoned.\n\n post by MariusVanDerWijden on Apr 1, 2018\n\n MariusVanDerWijden\n\n bpolania\n\n Is your repository private?\nI tried to write my own implementation, it’s not finished and I’m new to this, so any comments are appreciated\nhttps://github.com/MariusVanDerWijden/smartcontracts/blob/master/FundScience.sol\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n I’m not sure how point two would work in practice; as an academic I do not see the incentive for allocating a certain percentage of my paper to each used citation; this mostly sounds like a lot of extra work and I think people will not fully commit to this.\nFurthermore, another problem which should be taken into account is how academics tend to uplift their h-index by conducting large research and then publishing the results not as one big paper but as multiple smaller ones, whereby their h-index gets increased and they can receive more citations (by both themselves as other scholars). This is a big problem in academia as it is, but it is hard to check for, and this would be a continuous problem if you allocate a percentage based on citations.\nI do not have the answers, but I do think that these are some important issues to take into consideration.\nNotwithstanding this, I think your general idea is good and at the very least a very important problem that the blockchain could help solve.\n\n post by kladkogex on Apr 3, 2018\n\n kladkogex\n\nIn reality it will not be so easy to do: as an academic if you do not allocate to your peers than the community may not like it. As an academic you know that the academic community is very tightly bound (reviewers, funding etc.)\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n Of course, I think I may have explained myself unclearly. I wonder about allocating an exact percentage (and determining that exact percentage, you draw on many sources, often also to support the same claim), not about acknowledging your sources in the first place \n\n post by david.hite on Apr 4, 2018\n\n david.hite\n\n What do you think about this: scientist or developer may make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science. Anyway, it’s better to use ICO rating, if you want to invest your money the best way.\n\n Load more posts below","tokens":3063,"squid":"ink-research","role":"Deep Scholar","at":1791267692234,"hash":"1971e81a1a9bcfdcbf8ee941bdfc2c01fbd6e233"}
{"url":"https://ethresear.ch/t/using-icos-to-fund-science/920/4","domain":"ethresear.ch","title":"Using ICOs to fund science - Better ICOs - Ethereum Research","text":"Better ICOs\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jan 2018\n\n 4 / 26\n\n Jan 2018\n\n May 2018\n\n post by kladkogex on Jan 26, 2018\n\n kladkogex\n\n Currently, most whitepapers cite scientific papers, but academia people get little from the ICOs.\nHere is a proposal how science could be funded by ICOs:\n\nAn ICO would voluntary commit, say 1% of proceeds to the science used by the technology.\n\nThe LATEX citations section of the whitepaper would include allocations of the proceeds in percentages. Basically, the whitepaper author would decide to allocate, say, 7% to one citation, 5% to another citation etc., the total being 100%.\n\nThen in a pass-through fashion, each scientific paper would voluntarily allocate the percentages to the papers it cites. So if my paper cites papers X,Y, Z I could allocate 40% to myself, 15% X, 20% to Y and 25% to Z.\n\nAs a result, you could have every paper to include smart-contract readable allocations, and then a smart contract would essentially create a network flow of money from ICOs to papers cited in the whitepaper, then to second level citations, third level citations etc.\n\nWhen a professor moves to one university to another, she could “take” her papers with her, so the university would receive funding from the sum of contributions of its faculty.\n\n Incentives for running full Ethereum nodes\n\n 6\n\n 3\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n post by vbuterin on Jan 26, 2018\n\n vbuterin\n\n Interesting! Basically an airdrop into a reputation system for academia. I’d support this.\nAnother idea is that at the time that they write their papers, scientists could issue tokens for the paper and if desired sell them; then the airdrop would go to the token holders. This could allow scientists to pre-fund work, as well as creating a prediction market for how influential work would be in the future, which may be useful to society for informational purposes.\n\n post by dillchen on Jan 27, 2018\n\n dillchen\n\n @kladkogex I’m glad someone posted about this. I had some thoughts along these lines as well -> here. They’re a bit messy, so I’ll just summarize below.\n\nResearch coin distribution event (ICO? or just give it researchers and other stake holders)\nEach paper, when hits preprint server starts a game.\n\nperhaps authors of papers have to stake money as well???\n\nOwners stake research coin so they can peer review this paper\nWe gather a set pool of staked money for the paper\n\nThey decide on the validity of the paper\nAnd how to initially distribute the distribution of said paper’s individual token in proportion to owners and citations to other papers.\nThis is some type of schelling point game.\n\nAccurate schelling point people are rewarded with some new research coin (in some proportion to how much was staked)\n\nSlashing the stake of bad reporters\n\nOnce paper schelling point is set, then distribute locked research token recursively to owners of said paper’s token with pro rata of schelling point.\n\nIntuition is that peer reviews want to review important papers and therefore will stake tokens to do this.\nMore important papers get more staked token\nMore token flows recursively to the owners of the paper’s token.\nI guess this is technically securitizing basic research IP, lol\n\nMarkets develop for individual paper’s token. These may later on yield great research results and therefore generate recursive payments of research token. As more papers get published, flow of money goes recursively to the paper parent papers/owners. The price of the token’s paper, denominated in research coin may\n\nRecursive ownership is important because it incentivizes research with the greatest NPV in terms of research coin.\nResearchers who publish should get steady payouts as more papers cite them, so they can continue to fund more research.\n\nNicola at Protocol Labs has written about this as well. https://nicola.io/research-coin/2017\n\n post by nicola on Jan 28, 2018\n\n nicola\n\n Awesome to read this here! (thank for the mention! )\nI once did a braindump of possible ideas to make this happen (although they are good intuition, I don’t believe they work in practice). The general idea is to combine prediction markets with peer review:\n\nResearch Coin: first attempt\nResearch Coin: second attempt\n\nHave fun, hope to see good ideas out of this!\n\n post by mattiasbergstrom on Jan 29, 2018\n\n mattiasbergstrom\n\n I believe that the right idea is to get rewarded by the papers use as in quoted or referenced, so for a researcher a kind of reputation system, then I also like the idea of @vbuterin to be able to pre-sell access to a specific research area, the only question there is if it could skew the research in a specific way, but I believe that finding new ways to found research should really be a core topic for ICO/crypto investors.\nhttp://ieeexplore.ieee.org/document/7933951/ with 244 downloads I could have gotten some coins out of that paper \n\n post by FBrinkkemper on Jan 29, 2018\n\n FBrinkkemper\n\n While I really like the general use case, I really hope this technology does not result in a popularization of science, in the sense that only really popular research gets proper funding, while newer and fundamental research gets less funding.\nI do really like this idea though for the development of open source code and funneling the ICO capital through the dependencies. So proper general cryptography libraries for example get funded by multiple ICO’s.\nSo for example:\nICO for new Blockchain protocol where 60% of the received funds are used for the development. Then they can spend that by allocating 50% to their own code, and 10% to 5 big dependencies for example. Those dependencies can do the same again.\nIs the above use-case worked on already by anyone’s knowledge?\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\n Yes - I think this is a very good point ! We all need things like good crypto libraries, or and there should be a way to fund this …\n\n post by bpolania on Jan 31, 2018\n\n bpolania\n\n I have always thought that the white paper itself is not required to be a smart-contract, not on it’s entirety but a reflection of the paper document, so in a similar fashion to how gas in managed, the ICO company can set a price for the citation and the author of the paper can decide to accept it or not.\nHaving the white paper in the blockchain will come with additional benefits in terms of accountability but they are outside the scope of this thread, I’ve designed a contract for a white paper, let me know if anyone’s interested.\n\n post by kladkogex on Feb 1, 2018\n\n kladkogex\n\n Boris nice - may be you can share a GitHub link then ?\n\n post by bpolania on Feb 1, 2018\n\n bpolania\n\n I just created a repo for this: https://github.com/bpolania/WhitePaperContract/tree/master\nPlease note that this is a work in progress, it means that it’s untested and is lacking functionality, the main intention is to define how a white paper could be represented in the blockchain, so at this point it’s better if you think of it as pseudo-code.\nAlso, I haven’t though about the citation part up until I read this post, so that functionality is not there but I’ll be adding it gradually.\n\n post by jamesray1 on Feb 2, 2018\n\n jamesray1\n\n Note that the concept of\n\ncan be generalized to airdrops into other reputation systems.\n\n post by bpolania on Feb 2, 2018\n\n bpolania\n\n kladkogex\n\n The github repo now has citation related functionality\n\n post by rumkin on Feb 8, 2018\n\n rumkin\n\n I was thinking about such system but from another angle. What if to create kickstarter for scientists. Scientist or developer may to make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science.\n\n 1 month later\n\n post by akomba on Mar 18, 2018\n\n akomba\n\n jamesray1\n\n Yes, I think generalization would be a good idea – to include support for critical projects in the ecosystem as well (etherscan, etc).\n\n 10 days later\n\n post by musalbas on Mar 28, 2018\n\n musalbas\n\n This is also of interest: MathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\n\nMathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\nAbstract: A public blockchain is proposed in an attempt to enable the coin holders to participate in verifying mathematical theorems for public access. Incentives are designed to encourage any party to contribute their knowledge by buying tokens of mathematical propositions that they believe are true. The proposed blockchain is a platform for people to exchange their belief in mathematical propositions. An implementation of this blockchain proposal, once established, will provide the general public an easy and instant access to reliable knowledge without having to read difficult proofs or having to blindly trust a small number of experts. Conversely, experts from various fields may find it be much easier for making their work appreciated by more people, leading to a better impact. According to the incentive inherently provided by the blockchain, they can even earn significantly if they do prove some theorems that were not previously known by the blockchain. Foundations who are interested in the validity of a particular proposition not yet explicitly recorded on the blockchain can donate a fund, which will distribute to experts who contribute positive efforts toward solving the specified problems. Only the people who erroneously create or buy tokens of a proposition that is eventually proven false will lose money. A reference design of the proposed blockchain that attempts to achieve the above-mentioned goal is described and reasoned.\n\n post by MariusVanDerWijden on Apr 1, 2018\n\n MariusVanDerWijden\n\n bpolania\n\n Is your repository private?\nI tried to write my own implementation, it’s not finished and I’m new to this, so any comments are appreciated\nhttps://github.com/MariusVanDerWijden/smartcontracts/blob/master/FundScience.sol\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n I’m not sure how point two would work in practice; as an academic I do not see the incentive for allocating a certain percentage of my paper to each used citation; this mostly sounds like a lot of extra work and I think people will not fully commit to this.\nFurthermore, another problem which should be taken into account is how academics tend to uplift their h-index by conducting large research and then publishing the results not as one big paper but as multiple smaller ones, whereby their h-index gets increased and they can receive more citations (by both themselves as other scholars). This is a big problem in academia as it is, but it is hard to check for, and this would be a continuous problem if you allocate a percentage based on citations.\nI do not have the answers, but I do think that these are some important issues to take into consideration.\nNotwithstanding this, I think your general idea is good and at the very least a very important problem that the blockchain could help solve.\n\n post by kladkogex on Apr 3, 2018\n\n kladkogex\n\nIn reality it will not be so easy to do: as an academic if you do not allocate to your peers than the community may not like it. As an academic you know that the academic community is very tightly bound (reviewers, funding etc.)\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n Of course, I think I may have explained myself unclearly. I wonder about allocating an exact percentage (and determining that exact percentage, you draw on many sources, often also to support the same claim), not about acknowledging your sources in the first place \n\n post by david.hite on Apr 4, 2018\n\n david.hite\n\n What do you think about this: scientist or developer may make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science. Anyway, it’s better to use ICO rating, if you want to invest your money the best way.\n\n Load more posts below","tokens":3063,"squid":"ink-research","role":"Deep Scholar","at":1791267702721,"hash":"9a76be09cb8bdc5fe9e3cd8f7367a3b0b4266eda"}
{"url":"https://forum.pyth.network/t/pythian-got-talent/2235/4","domain":"forum.pyth.network","title":"Pythian got talent - Ideas Bank - Pyth DAO","text":"Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Sep 2025\n\n 4 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by eukodal on Sep 30, 2025\n\n eukodal\n\n Hello\n• TLDR :\n• chit chat + voice chat\n• activity+flywheel creations+\n• massive community gatherings +\n• investors+\n• angel investor main gatherings\ni herby propose , dev gatherings in voice chat “acropolis”.\nbring new dev , craft ideas , showcase projects , actively working alongside of these devs.\nallocating , to PGT (pythians got talent)\ncurrent prizes :\nColosseum 75-50k\nhaving same less or higher , either way on impact awards as PP , i would like to have that PP on my ia bank\n-Note : participants + collabs + listeners + ideas + devs and allocating PP to any person bringing value.\n• Super stingy method : wont spend a dime of PP unless something happens “SSM” solution, yeah mate.\nconsider allo as advertising:\n“ AD < ROI “\nReturn of such investments must be:\n-spotlight for community\n-spotlight for new devs or cracked ones\n-also finding potential web3 jobs for current pythians\n-Leveraging community power\neg , papont vid ads, planck or pepito contents , borys koba ricardo memes and energy\npeople showing up daily bringing value to different section . eg : if you gucci in trading tokenomics design art memes all sort of talents you have a spot with us.\nincrease of $PYTH and pythenians price since this method gonna add too many people into our community.\n“ time and gatherings “:\nthis event is 1 time monthly\n+daily checking\n+weekly gatherings if a new dev or idea is available\nend of month , “projects launching or working , with actual social and community interest get PP rewards”\nPP stack : on the event of hitting the fan no dev no interest . Stack PP\nso next month PGT(pythians got talent) will look juicy\non this journey all allocation will have proof of distribution as it is happening rn on ia’s feed\npythians identity:\n• “every project will have use cases for: “\n• verify for pythenians and pyth holders\n• every community member will benefit from activities on new projects\n“ In house benefits “\n1- current community benefits and support for pythians\n2- new friends in temple\n3- Pyth growth and flywheel of current eco\n4- making sure everybody get rewarded for their help\ni would love to have bruvs :\namensch as wisest and elder on every opinion\nkobak as designer and vibe master\nricardo , he is active between community can help alot on bringing ideas and tell the tails to others\njeetalik as secret coordinator for vc and events and vibe checker for creators\nBorys for amazing gifs and memes , he can keep and create culture , art and tails are culture among a community\ncouncil members, they know what to do .\nat the end , every new project will have a taste of pythians injection as core community .\n–\non event of a project hiring current cohort of legions\ni do know one thing tho , money take people away .\n\npeople who may help alongside new project , they get winning prize to work with + their rev\npeople who work on PGT and advising or side work require some donation from Pyth DAO, in case of success\n\nAngel investors , required to fund the newly working project to PYTH DAO\nhaving Tx , on launch they own a % of project , for individuals investors\n\ntoken\nproject rev\nproject stake holding\nthings attached to new proj\n\nKYC needed . with Pyth team or council\n\non event of failure, current community and partners will try to gather put all brains together and make it happen\nif not , PYTH DAO only spends when its required for spending\nproduct first .\n\nPotentially Dev’s can build in Pyth Deep estate\nbest regard euko\n\n 3\n\n post by eukodal on Sep 30, 2025\n\n eukodal\n\n 10000443731080×466 60.9 KB\nsome visuals , graduated projects\nnew proj must meet :\n1, demand\n2, lack of this new proj in eco\n3, strategic trend analysis for better outcome\n\n post by ed_pyth on Oct 2, 2025\n\n ed_pyth\n\n Hello. Firstly, I really appreciate how thoughtful and energetic this idea is. I’m very pleased you’re thinking about Pyth’s community, culture, and dev growth in such a grand way.\nPrima facie, my first concerns are that actually running something like this is a much, much steeper hill than it may seem: judging projects, doing proper due diligence, and avoiding conflicts of interest all take serious time and exertion\nMy suggestion would be to zoom in on one or two of the most promising parts of your proposal first (like community showcases or small-scale dev gatherings), then building it out from there\nStill, def a deeper discussion to be had\n\n post by eukodal on Oct 4, 2025\n\n eukodal\n\n if i may reach couple of devs in UAE on my side , and check if they be interested to build sub-tools for bigger projects\nalso can ask Pepito and Planck to check if they may know related people in this field\nwhich may take less time and effort\nthoughts on this\nin addition i appreciate your kind reply Ed\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pythians got talent\n\n Ideas Bank\n\n 1\n\n 75\n\n Sep 2025\n\n Pyth Playground Community Hackathon\n\n Ideas Bank\n\n 25\n\n 731\n\n Mar 11\n\n Community Hackathon post-mortem\n\n Community Council\n\n 6\n\n 239\n\n May 31\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 568\n\n Apr 6","tokens":1338,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267717716,"hash":"f196c46cf1e51c08ea5e58a7bef199ef637eda26"}
{"url":"https://gov.optimism.io/t/builder-grant-proposal-op-security-proxy-local-pre-execution-revert-interception-for-the-superchain/10845/1","domain":"gov.optimism.io","title":"[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n [Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain \n\n Grants 🔴Governance Fund Missions\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 4\n\n Sep 4\n\n 1 / 5\n\n Sep 4\n\n 27d ago\n\n post by Cypherin on Sep 4\n\n Cypherin\n\n Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions before broadcasting to OP Stack nodes. On EVM rollups, end users and automated agents pay gas fees even when transactions revert on chain due to stale oracle states, localized slippage, or sandwich attacks. For retail users, burning gas on a failed execution creates frustration, and for wallet teams it leads to avoidable support tickets.\nThe proxy sits between standard wallets or clients and public Optimism RPC nodes. When a client issues an eth_sendRawTransaction request, the proxy intercepts the raw payload and simulates it in process using revm against current chain state. If the simulation executes successfully, the transaction is forwarded upstream to the sequencer over an existing hyper connection pool. If the simulation reverts, the proxy aborts the broadcast completely so zero gas is burned on chain, and immediately returns a standard JSON-RPC error containing decoded Solidity custom errors or panic codes along with an estimated gas saved metric.\nThe core implementation is open-source under the MIT license with 40 automated tests passing across the Rust core and TypeScript client SDK. In empirical benchmarks against mainnet.optimism.io, the proxy introduces a minimal 11.8 millisecond processing overhead on fair keep-alive connections with session reuse. For clients that make cold requests without connection reuse, the proxy internal connection pool eliminates repetitive TLS 1.3 handshakes to remote endpoints, amortizing roundtrip latency by roughly 97 milliseconds. The full reproduction methodology and raw telemetry logs are recorded in BENCHMARK_RESULTS.md (https://github.com/Ishant5436/op-sec-proxy/blob/main/BENCHMARK_RESULTS.md).\nUncached transaction simulation over public internet RPC currently averages approximately 2.7 seconds because the execution engine must fetch contract state slots across the network during execution. I am requesting 10,000 OP for an initial builder grant to fund three engineering milestones over the next three months. The initial phase tackles state caching, replacing network RPC state queries with a local in-memory LRU trie cache for warm contract bytecode and storage slots to drive simulation latency down toward a sub-65 millisecond target. Following that, work shifts to developer adoption with a TypeScript provider wrapper and standardized error decoding for wallet integrations. The final phase expands routing across OP Mainnet, Base, Mode, Zora, and Fraxtal alongside reproducible Docker containers and systemd service packaging for node operators.\nAs an individual engineer, I rely on Rust memory safety guarantees, cargo-audit automated dependency scanning, and reproducible GitHub Actions workflows rather than corporate support infrastructure. All code is public and modular. I previously shared an introductory post in the general discussion section of the governance forum under thread 10810 (OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions), and this grant application will allow me to build and package the middleware as a permanent, zero-cost public good for the Superchain ecosystem.\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n 4\n\n post by Anzus_GemWallet on Sep 4\n\n Anzus_GemWallet\n\n From a user-support perspective, how will the proxy handle cases where the local simulation is based on slightly stale state but the transaction might still succeed on-chain? It would be useful to understand whether the default behavior is to fail open, and how the wallet communicates simulation uncertainty versus a definite revert.\n\n post by Cypherin on Sep 4\n\n post by Cypherin on Sep 6\n\n post by Cypherin on Sep 8\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions\n\n ✨ General\n\n I am putting together OP Security Proxy, which is a fast JSON-RPC middleware layer I wrote in Rust. You can check out the code at GitHub - Ishant5436/op-sec-proxy · GitHub . It essentially sits between a standard wallet …\n\n read more\n\n 3\n\n 107\n\n Sep 4\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\n\n Technical Proposals\n\n Shutterized Optimism – An Encrypted Mempool for the OP Stack\nRequirements and Technical Architecture\nAuthors: Jannik Luhn, Maximilian Langenfeld, Luis Bezzenberger, Jakub Al Soori \nExecutive Summary\nThis document serves …\n\n read more\n\n 4\n\n 7.3k\n\n Jul 2023\n\n Grant Application: superchain-guard\n\n Grants Updates\n\n season-8,season-9\n\n Project Name: superchain-guard — The Security Frontier for Interoperable Intents \nApplicant: ILE Labs (ILE-Labs · GitHub) \nProgram: Season 9 Growth Grants (Infrastructure Category) \n\nExecutive Summary\nOptimism is enterin…\n\n read more\n\n 6\n\n 213\n\n May 19\n\n [MISSION REQUEST] Open-source transaction simulator\n\n Governance Fund Missions\n\n Title: Open-source transaction simulator\nDelegate Mission Request Summary: \nThis mission is intended to provide a key, critical piece of tooling - simulating transactions before they go onchain. Tenderly provides a great…\n\n read more\n\n 3\n\n 522\n\n Aug 2025\n\n Upgrade Proposal #13: OPCM and Incident Response improvements\n\n Protocol Upgrade\n\n Executive Summary\nHi I’m Maurelian, a Security Engineer at OP Labs. This proposal was written in collaboration with Lewej (@0xEscanor) and @Kelvin from the OP Labs Team. \nThis proposal is intended to be voted on in cycle…\n\n read more\n\n 19\n\n 1.4k\n\n Mar 2025","tokens":1523,"squid":"ink-governance","role":"Council Listener","at":1791267717761,"hash":"af28011c9e44fcbf4c8e87b4b212a93d17db8b64"}
{"url":"https://forum.pyth.network/t/community-hackathon-post-mortem/2518/1","domain":"forum.pyth.network","title":"Community Hackathon post-mortem - Community Council - Pyth DAO","text":"Community Hackathon post-mortem \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 10\n min\n\n May 6\n\n 1 / 7\n\n May 6\n\n May 31\n\n post by Chop on May 6\n\n Chop\n\n PYTH COMMUNITY HACKATHON\nROUND 1\nProgram Report\nCommunity Hackathon for AI-Assisted Builders\n36 Projects | 200,000 PYTH | 4 Weeks\nPrepared by Choppa (@ChoppaTheShark)\nCommunity Lead, Pyth Network\nApril 7, 2026\nTable of Contents\nExecutive Summary\nPyth Community Hackathon ran as a four-week community hackathon designed to test a thesis: if AI coding tools eliminate the programming barrier, what will the Pyth community build with our data?\nThe results exceeded expectations. 36 projects shipped across DeFi infrastructure, analytics, gaming, AI agents, and utility tools. Every Pyth product was utilized — Price Feeds, Entropy, Pyth Pro, and Benchmarks. Builders deployed across five blockchains (Solana, Base, Ethereum, FOGO, Optimism) covering crypto, forex, commodities, and equities.\nI’ve written this report to provide a complete overview for the PDA, for whom this program benefits the most. It covers the strategic rationale, execution details, submission analysis, key findings, media distribution plan, and recommendations for continued hackathons in 2026 & 2027.\n\nTotal Projects Submitted\n36\n\nPrize Pool\n~200,000 PYTH\n\nDuration\n4 weeks (March 4 – April 1, 2026)\n\nJudging Period\nApril 2–15, 2026\n\nAPI Keys Issued\n32 (36 projects shipped — community outran infra)\n\nPyth Products Used\nPrice Feeds (34), Entropy (15+), Pyth Pro (5), Benchmarks (4)\n\nChains Represented\nSolana, Base, Ethereum, FOGO, Optimism\n\nAsset Coverage\nCrypto, Forex, Commodities, Equities\n\nAll Licenses\nApache 2.0 (open source)\n\nStrategic Context\nThe Pyth Community Hackathon does not exist in isolation. It is one execution layer within two converging strategic priorities for Pyth Network in 2026.\nAI Discoverability — The #1 Priority\nPyth’s competitive position depends on whether AI systems recommend Pyth when developers ask how to get price data. As of February 2026, Bloomberg holds 33.7% LLM visibility versus Pyth’s 5.7%. That gap closes with content, not code. In this context, every hackathon submission generates a plethora of natural derivative content: forum posts, GitHub repos, Dev.to articles, Reddit threads, Twitter posts. 36 projects produced an estimated 100+ public-facing content artifacts — all mentioning Pyth usage, all crawlable by LLM training pipelines, all hosted on indexed domains. LLM Gold.\nStrategic value: Pyth Community Hackathon is a GEO (Generative Engine Optimization) multiplier. Each builder creates content that teaches AI models what Pyth is, what it does, and why developers should use it. Every project is a concrete example and use case for Pyth data.\nThe Agent Economy — Positioning for the future.\nAutonomous agents (bots, AI operators, automated trading systems) already drive a significant share of on-chain activity. They need real-time, oracle-grade price data to function. Pyth is that price layer.\nThe hackathon was designed to prompt and produce working examples. The Pyth MCP Server was included as a starter kit, which meant AI coding assistants (Claude, Cursor, Replit Agent) were pulling live Pyth data during the build process itself. Agents using oracle data to build applications that use oracle data. That loop happened organically, without anyone designing specifically for it.\nThree submissions are themselves autonomous agents: NeuroTrade streams Pyth Pro data and executes trades through Jupiter with zero human input. SignalForge runs a 24/7 bot monitoring prediction markets against Pyth feeds with Kelly Criterion position sizing. Ouroboros takes a natural language description and autonomously generates, compiles, and deploys a Pyth-powered dApp.\nThese are working agent-to-oracle pipelines. Built in four weeks. By community members. Not a pitch deck — a proof point.\nThe Vibe Coding Thesis\nThe core bet behind Pyth Community Hackathon was that AI coding tools have collapsed the barrier between “I have an idea” and “I have a working application.” The traditional hackathon assumption — participants must know Solidity, Rust, or at minimum JavaScript no longer holds.\nResults seem to have validated this thesis. Builders with no prior blockchain experience shipped DeFi primitives (Aletheia’s confidence-adaptive RFQ), research-grade analytics (RegimeIQ’s oracle microstructure analysis), and complex gaming systems (Tower of Entropy’s full RPG). AI tools wrote the code. Pyth provided the data. The builders provided the ideas.\nThis overlal projected has changed how the developer onboarding funnel works entirely (especially when considering future iterations of the hackathon). “Docs → Tutorial → Abandoned project” can now credibly be replaced by “Browse cool projects → Fork one → Make it yours.” Pyth Community Hackathon generates the a live project gallery that powers this new funnel for all future developers and builders.\nProgram Design & Execution\nStructure\nPyth Community Hackathon Round 1 was organized by the Pyth Community Council (elected governance body) and coordinated by Choppa (@ChoppaTheShark, Community Lead). The organizing entity is PYTH DAO LLC (Marshall Islands).\n\nSubmission Period\nMarch 4 – April 1, 2026\n\nJudging Period\nApril 2–15, 2026\n\nResults Announcement\nApril 15, 2026\n\nPlatform\ndev-forum.pyth.network (submissions) + Discord (community)\n\nEligibility\n18+, excludes OFAC-sanctioned jurisdictions\n\nTeam Size\nMax 2 per submission\n\nKYC\nPDA (Pyth Data Association) handles KYC for prize winners only\n\nPrize Structure\n\nTier\nReward\n\n1st Place\n50,000 PYTH\n\n2nd Place\n30,000 PYTH\n\n3rd Place\n15,000 PYTH\n\n4th–10th Place\n5,000 PYTH each (35,000 total)\n\nCommunity Choice Award\n10,000 PYTH\n\nBest Pyth Pro Use\n10,000 PYTH\n\nBest Educational Content\n10,000 PYTH\n\nParticipation (valid submission)\n500–1,000 PYTH\n\nUpvote Bonuses\n10 upvotes (+500) to 100 upvotes (+5,000)\n\nJudging Criteria\n\nCriteria\nWeight\n\nPyth Integration Depth\n30%\n\nCreativity & Innovation\n25%\n\nExecution Quality\n20%\n\nUser Experience\n15%\n\nDocumentation\n10%\n\nResources Provided\nBuilders basic starter kits, 30 project ideas across 5 categories (HFT, DeFi, Analytics, User Tools, Infrastructure), three pinned forum guides (Official Rules, Submission Template, Judging Rubric & FAQ), and direct access to Pyth Pro API keys on request.\nComplete Project Catalog\nAll 36 submissions are listed below, organized by the content priority tiers used for the media distribution plan. Every project is open-source (Apache 2.0) and most have live demos.\n\nProject\nBuilder\nCategory\nPyth Products\nChain / Demo\n\nMarket DVR\nWattson\nInfrastructure\nPrice Feeds, Pyth Pro\nVPS\n\nAletheia RFQ\npap0nt\nDeFi\nPrice Feeds (on-chain)\nBase\n\nThe Market Witness\nJoestar\nCreative/Education\nHermes, Benchmarks\nVercel\n\nRegimeIQ\ncodeglitch\nAnalytics\nHermes SSE, Confidence\nVPS\n\nFOGO Pulse\ntheRoad\nDeFi\nPyth Lazer, Hermes WS\nFOGO\n\nPythCorrelation\nrustrell\nAnalytics\nHermes, Benchmarks, Entropy\nVercel\n\nSignalForge\nSmartbott\nTrading\nHermes API + WS\nRailway\n\nPirb.swap\nDera\nDeFi\nPrice Feeds (Hermes V2)\nSolana\n\nNeuroTrade\nSCP\nTrading\nPyth Pro WS\nSolana\n\nOuroboros\npstar\nInfrastructure\nPrice Feeds, Entropy\nBase\n\nPythGuard\nSueno\nAnalytics\nPrice Feeds, Pyth Pro, Entropy\nSolana\n\nLiquidSense\nMAYTH\nDeFi\nHermes Price Data\nBase\n\nTerminal by nik0\nNik0\nAnalytics\nHermes, Benchmarks\nVercel\n\nPythVision\nJaybrass\nAnalytics\nPrice Feeds, Entropy V2\nEthereum/Base\n\nPythReceipt\nviperx\nDeFi\nPrice Feeds, Pyth Pro Lazer\nSolana\n\nPyth Sentinel\nInvestor_Daniel\nUtility\nPrice Feeds, Entropy\nRailway\n\nCoindle\ndroober\nGame\nHermes API\nVercel/Farcaster\n\nPIRBGEN\nmersault\nGame\nPrice Feeds, Entropy\nBase\n\nPyngo\nenoo\nGame\nPrice Feeds, Entropy\nVPS\n\nPyth Defender\nKhaleesi\nGame\nHermes REST, Entropy\nGitHub Pages\n\nPythian Peso Snake\ntotti\nGame\nEntropy (Optimism)\nNetlify\n\nWhac-a-Pythenian\nRicardoReyes\nGame\nEntropy\nVercel\n\nTower of Entropy\nFlint\nGame\nEntropy, Price Feeds\nBase\n\nPyth Casino\nsurojitpvt\nGame\nHermes Price Feeds\nSolana/Base\n\nPyth Arcade\nAgarwal\nGame\nPrice Feeds, Entropy\nVercel\n\nSleeve\ndexter\nGame\nLazer Pro, Entropy\nBase\n\nWalk The Planck\nQuintzor\nGame\nEntropy\nBase\n\nOrra\nemjayrntr\nGame\nPrice Feeds, Entropy\nBase\n\nPyPredict\nBam4bam\nDeFi\nHermes API (17 feeds)\nVercel\n\nPythPulse\nBankybemma\nAnalytics\nHermes REST (38 feeds)\nVercel\n\nOracle Flow\nSugoi\nAnalytics\nPrice Feeds\nVercel\n\nRektoMeter\nranimth07\nUtility\nHermes API (500+ assets)\nVercel\n\nPrice Prediction Grids\nShubh\nGame\nPrice Feeds, Entropy\nSolana\n\nPolyJackpot\njoshjosh11\nGame\nEntropy\nBase\n\nd1ckochart\noldtora\nCreative\nHermes API\nVercel\n\nQTCL Blockchain\nshemshallah\nInfrastructure\nPrice Feeds, Entropy\nQTCL\n\nCategory Analysis\nThe 36 submissions naturally cluster into six categories, revealing how the community thinks about oracle data utility.\nGames & Entertainment (14 projects)\nThe largest category by volume. Ten of these use Pyth Entropy for verifiable randomness. Projects range from simple browser games (Pythian Peso Snake, Pyth Defender) to complex systems (Tower of Entropy’s full RPG, PIRBGEN’s competitive trading arcade). The Market Witness bridges gaming and education through AI-powered courtroom drama.\nKey insight: Entropy is the entry drug. Provably fair randomness is an easy-to-understand value proposition that gets builders interacting with Pyth infrastructure. Many of these builders will graduate to Price Feed and Pyth Pro integrations.\nAnalytics & Monitoring (8 projects)\nProfessional-grade tools including PythCorrelation (28+ asset cross-correlation), PythPulse (38-feed anomaly detection), RegimeIQ (oracle microstructure analysis), and multiple market terminals. Several use Pyth Benchmarks for historical data alongside real-time feeds.\nKey insight: The multi-asset coverage (crypto + forex + commodities + equities) was a major differentiator. Builders leveraged Pyth’s breadth in ways that single-asset oracles cannot support.\nDeFi Infrastructure (6 projects)\nThe most technically sophisticated category. Includes confidence-adaptive settlement (Aletheia), liquidation monitoring with macro signals (PythGuard, LiquidSense), slippage protection (Pirb.swap), liquidation receipts (PythReceipt), and prediction markets (FOGO Pulse, PyPredict).\nKey insight: Builders treated confidence intervals as functional infrastructure, not informational. Three separate projects independently arrived at “confidence as a gate” — a pattern worth elevating as a Pyth design principle.\nTrading Agents & Tools (5 projects)\nAI-powered trading systems including NeuroTrade (local-first agent streaming Pyth Pro), SignalForge (prediction market bot using the same oracle for signals and settlement), and Ouroboros (AI agent generating entire Pyth dApps from natural language).\nKey insight: Direct validation of the agent economy thesis. These are working prototypes of autonomous systems paying for and consuming oracle data.\nInfrastructure (3 projects)\nMarket DVR (Pyth Pro market replay), Ouroboros (AI dApp generator), and QTCL Blockchain (post-quantum price attestation). The most ambitious and differentiated submissions.\nUtility (2 projects)\nRektoMeter (airdrop P&L tracking with 500+ Pyth-priced assets) and Pyth Sentinel (price alerts with oracle-grade data). Practical tools demonstrating everyday use cases.\nPyth Product Usage Analysis\nThe hackathon served as a live stress test of Pyth’s product surface, and developer experience. The distribution of product usage reveals how builders naturally discover and adopt Pyth’s capabilities.\n\nProduct\nUsage\nHow Builders Used It\n\nPrice Feeds\n34/36\nCore data layer. Real-time crypto, forex, commodities, equities. Both on-chain and off-chain (Hermes) consumption.\n\nEntropy\n15+/36\nVerifiable randomness for games, lotteries, prediction markets. Commit-reveal protocol for provably fair mechanics.\n\nPyth Pro (Lazer)\n5/36\nSub-second institutional feeds. Used by most technically advanced projects (Market DVR, NeuroTrade, FOGO Pulse, PythReceipt, Sleeve).\n\nBenchmarks\n4/36\nHistorical OHLCV data for backtesting, charting, and correlation analysis.\n\nDiscovery pattern: Price Feeds are the entry point. Entropy is the engagement hook (especially for games). Pyth Pro is discovered by advanced builders who need speed or historical depth. Benchmarks are used by analytics-focused projects.\nDeliverable 1: Project Spotlight Tweets\n36 individual project tweets from @CHOPPAtheSHARK (commentary, personality). Projects are tiered by quality: Tier 1 (7 deep features), Tier 2 (9 spotlight posts), Tier 3 (20 community/game posts). Posted with links, screenshots and callouts for the individual builders.\nDeliverable 2: Hackathon Recap Article\nA large-ish reflection article blending thesis (vibe doing supremecy) with evidence from each project. Covers the experiment, what got built (organized by category), and three key findings. Written as a complimentary ‘community strength’ blog. Posted to both Twitter and the Governance Forum as a review.\nCommunities Key Findings & Lessons Pyth can learn\n1. Long live vibe coding\nBuilders with no prior blockchain experience shipped basic DeFi primitives, genuine research-grade analytics, and relatively complex gaming systems in under 4 weeks. The almost ALL of the code was AI generated. This should frame Pyth’s thinking significantly into the future as we lead the charge in subscription based first party financial data. This is particularly important as we open up the product suite to retail audiences. Proving what is possible with Pyth to the every day consumer is an important market segment.\n2. Pyth’s Product Surface Is Deeper Than Perceived\nThere was significant diversity in products built. Each community member independently discovered that confidence intervals can serve as execution gates, oracle microstructure can function as a risk signal, Entropy enables entirely new game (and trading) mechanics, and Pyth Pro unlocks institutional-grade capabilities. Builders treated Pyth data as a premium product that would help inform their decision making processes, and allow them to execute with precision. This demonstrates the perception of Pyth as a premium product is well set.\n3. Community Outran Infrastructure\n34 API keys were issued. 36 projects shipped. More people submitted without keys than with them. The bottleneck was not interest or capability — it was awareness and distribution. Round 2 should solve for reach, not resources.\n4. Entropy Is a great Onboarding Funnel\n15+ projects used Entropy, making it the second most popular product after Price Feeds. Provably fair randomness is an easy-to-understand value proposition that gets builders interacting with Pyth infrastructure. The games category (14 projects) was the largest. Entropy-first onboarding could become a deliberate strategy for onboarding low level applications and developers to Pyth.\n5. “Confidence as a Gate” Is an Emergent Pattern\nThree separate projects (Aletheia, FOGO Pulse, PythReceipt) independently arrived at using confidence intervals as functional gates — blocking trades, refunding bets, or halting liquidations when oracle uncertainty exceeds thresholds. This framing does not appear in any of Pyth’s documentation and was not mentioned in any of the Hackathon onboarding materials. Builders discovered this ‘feature set’ organically. This pattern should be elevated as an official Pyth design principle with dedicated documentation and examples. It provides Pyth with a VERY clear point of difference against other price data solutions while also doubling as a monetisable feature of the product suite.\n6. Content Generation Was Organic\nWithout requiring it, builders produced Dev.to articles, GitHub repositories, Reddit posts, and video demos. The hackathon generated 100+ public content artifacts mentioning Pyth — all indexed, all crawlable, all contributing to AI discoverability. Round 2 should formalize this with explicit content requirements for bonus rewards, and also show content examples from previous hackathon submissions.\n7. Reframe Pyth Pro usage\nCommunity was given ‘free access to Pyth Pro’. In the next iteration of the hackathon, framing for this event should instead be around Pyth giving away Pyth Pro credits to the tune of “X” amount of value that people can then use on a monthly basis. This promotes Pyth’s exclusivity whilst demonstrating the innate value of the data being used.\nCoordinator’s Reflections\nThe following observations are editorial — drawn from running this program end-to-end as coordinator. They supplement the analytical findings above with operational and philosophical takeaways.\nWhat This Hackathon Proved\n1. We underestimate people’s willingness to contribute\nMy assumptions going in was that the Prize money was going to be too low to attract attention. It wasn’t. Builders showed up because they found the challenge interesting. Most importantly, they wanted a chance to use the same data institutions do, in order to ‘level the playing field’. Many submitted projects that clearly took more hours than the prize pool could justify on a purely economic basis. I think it’s quite clear that giving a community something genuinely interesting to work on and the tools to do it, the participation problem solves itself. The bottleneck was never motivation — it was mostly about access to the data and awareness of the program. This is exciting for future iterations of the Hackathon.\n2. It’s not all about prizes\nThis was a very modest prize pool by crypto hackathon standards. Monad recently ran a hackathon with a 500k USD funding price. The Pyth Community Hackathon cost 100x less to run. What we received back in content, open-source code, product innovation, and ecosystem awareness far exceeded the cost. The ratio of value created to PYTH distributed is lopsided in our favor. Builders contributed because they were excited to build with PREMIUM financial data, not because the payout was life-changing. That’s a great signal for the Pyth brand — it means this model scales without requiring exponential budget increases, and that we have a ‘premium’ attached to our brand.\n3. Novel ideas for Pyth data still exist beyond what we know\nMultiple submissions genuinely surprised me with their breadth and creativity. Confidence intervals as trade execution gates (Aletheia), oracle microstructure as a risk signal (RegimeIQ), confidence-aware settlement refunds (FOGO Pulse), oracle speed as a competitive gameplay mechanic (PIRBGEN), a courtroom drama using price data as evidence (The Market Witness) — none of this stuff was in the project ideas list. The community found use cases for Pyth data that we, as the team closest to the product, had not considered. This means the surface area of what’s possible is larger than our internal imagination, and hackathons are the most efficient way to map that territory. We get to lean in to community and build a brand while ALSO pushing the boundaries of what Pyth data can do.\n4. Running this is harder than it looks\nThe organizational requirements of a program like this are substantial: legal (T&Cs, KYC, jurisdiction compliance), infrastructure (forum setup, API key management, submission tracking), content scheduling (promotional cadence, builder communications, judge coordination), and community management (answering questions, troubleshooting, maintaining momentum over four weeks). This was running this alongside every other active workstream, which was quite difficult. Had this been my sole focus, I think Pyth would have have extracted significantly more value: better promotional cadence, more builder support, tighter content pipeline, and a much more polished showcase event. The biggest thing to learn here is that dedicated operational bandwidth for programs like this can multiply the already substantial output of the program.\n5. Our products are intuitive\nOf 36 submissions, only 4 required any form of technical support. Two were API-related issues easily resolved with a key refresh. The other two were users not fully grasping speed variance in select assets — a comprehension issue, not a product issue. That’s a 89% zero-support rate from builders who, in many cases, had never interacted with oracle/data/price infrastructure before. The MCP Server, Hermes API, and Entropy documentation are doing their job. The products work the way developers expect them to work. That’s not a given in this industry, and it’s worth recognizing.\nMoving Forward — Strategic Vision\nBeyond the tactical recommendations for Round 2, this hackathon opens several larger strategic opportunities for Pyth Network & the community.\nA Community Hub for Live Projects\nMany of these projects function as genuine public goods. The Entropy-powered games, price feed monitors, correlation dashboards, liquidation radar’s are all fantastic, simple consumer products. They deserve to live beyond the hackathon as a showcase of what the community & Pyth data can do.\nI propose that we build a community hub (extension of Pythentity) that showcases select projects, provides them with full and free access to a single dedicated API key under the Pythenians banner, and keeps them running as permanent demonstrations of what Pyth data enables. Not a graveyard of demo links. A living gallery that everyone has access to, and the community owns.\nA Living Library of What’s Possible\nEach hackathon round adds to a growing library of what can be built with Pyth. Over time, this becomes an extremely powerful resource & tool in the ecosystem. Something distinctly different from documentation & tutorials. This would be a display of working applications that make people say “I could build that.” Community hackathons become the input layer for this library. Every round surfaces new patterns, new use cases, and new reference implementations that future builders (and Pyth users) can fork, extend, and improve.\nBrand Positioning: Champions of Open Building\nAs an organization, hosting and leaning into community hackathons frames Pyth as champions of open building and democratized access to financial data. The only limiting factor is being a part of the community. Bloomberg charges $24,000 per year for data that Pyth makes available for free, regularly. Running hackathons and having 36 community members build working products in four weeks (using AI tools, no barriers to entry or coding expertise required) imbues the event with a lot more meaning. It becomes a proof point for Pyth’s entire forward looking thesis. The brand perception compounds: Pyth data allows anyone to build with institutional-grade financial data. The hackathon is evidence of this - and it is continually reinforced the more we lean in.\nA Core Part of the Community Offering\nIn my opinion, Pyth would be well served by this program becoming a significant, recurring part of Pyth’s community offering. The appeal is twofold:\nFor retail and community builders: The opportunity to play with the same data that institutions pay for. To build something real with oracle-grade price feeds, verifiable randomness, and sub-second data — tools that were previously locked behind enterprise contracts and six-figure budgets. This is what makes a community sticky: not Discord roles, not airdrops, but the ability to create something meaningful with infrastructure that matters.\nFor builders and businesses: A testing ground for product ideas. A way to evaluate Pyth’s product surface without procurement cycles or sales calls. A gallery of reference implementations that demonstrate integration patterns. Several hackathon submissions are closer to MVPs than prototypes — businesses watching this space now have 36 open-source examples of what Pyth integration looks like in practice. That’s a sales pipeline built by people who love Pyth, for Pyth.\nThis creates a pretty obvious feedback loop: run hackathons, surface innovation, showcase the results, attract more builders, run more hackathons. Each round generates content (AI discoverability), demonstrates products (sales pipeline), rewards contributors (community flywheel), and produces open-source code (ecosystem infrastructure). Pyth doesn’t have a program or touchpoint that touches all four simultaneously. The Community Hackathon does.\nTactical Recommendations for Round 2\nScale Distribution\nRound 1 relied primarily on the developer forum and Discord for awareness. Round 2 should include more Twitter/X promotion from @PythNetwork, partnership with Superteam Earn for distribution, university outreach (three warm academic leads are active), and very specific collaboration with chain partners who may also be able to offer incentives or comarketing.\nFormalize Content Requirements\nRequire each submission to create at least one public-facing content artifact (Reddit post, Dev.to article, or GitHub example). Offer bonus PYTH for additional content. This transforms the hackathon from a builder event into an AI discoverability multiplier.\nIntroduce ‘Track’ System\nRound 1 was open-ended. Round 2 should offer themed tracks (DeFi Infrastructure, Agent Economy, Analytics, Gaming/Consumer) with track-specific prizes. This enables more targeted judging and produces cleaner content narratives. Alternatively, Pyth makes theme specific Hackathons that only look to reward and incentivise certain product verticles (eg; agentic trading)\nIntegrate with Content Incentive Stack\nPyth Community Hackathon should feed into the broader content incentive pipeline: MissionMonitor (live) for post-hackathon content missions for ongoing builder engagement. Round 2 participation should grant access to these systems and reward users for the deeper participation in community events.\nIncrease Pyth Pro Adoption — Reframe Access as a Grant\nOnly 5 of 36 projects used Pyth Pro in Round 1. Round 2 should fix that — not by making it “free,” but by making the value visible.\nThe marketing frame: Pyth makes available $X worth of Pyth Pro credits to the community over the hackathon period. Builders receive access to institutional-grade, sub-second data (the same feeds that paying subscribers use) as a community grant. The dollar value is stated explicitly. Every participant knows what they’re getting and what it normally costs.\nThis does three things simultaneously.\nFirst, it positions the hackathon as a gratuity event — Pyth giving real value to its community, not handing out free trials.\nSecond, it anchors Pyth Pro’s market price in every builder’s mind. They experience the product, see the price tag, and understand the value proposition without a sales call.\nThird, it creates a natural conversion pipeline — builders who used Pyth Pro credits during the hackathon are the warmest leads for paid subscriptions after it ends.\nPair this with a dedicated Pyth Pro starter kit (sub-second data consumption, historical benchmarks, bid/ask spread analysis) and a “Best Pyth Pro Use” bonus track with a higher reward to incentivize deeper integration.\nDedicate Operational Bandwidth\nRound 1 was coordinated alongside all other active workstreams. Round 2 should either be the coordinator’s primary focus during the active period, or have a second operator handling promotional cadence, builder communications, and content scheduling. The program delivers — but dedicated bandwidth from others within the community council would multiply the output.\nBudget & Resource Utilization\n\nItem\nAmount\n\nTotal Prize Pool\n~200,000 PYTH (from Community Council allocation)\n\nTop 3 Prizes\n95,000 PYTH (50K + 30K + 15K)\n\n4th–10th Place\n35,000 PYTH (7 × 5,000)\n\nSpecial Awards\n30,000 PYTH (3 × 10,000)\n\nInfrastructure Costs\nMinimal (forum hosting, API keys)\n\nThe program represents strong ROI: 36 open-source projects, 100+ content artifacts, 5+ working DeFi primitives, and a validated program template for future rounds — all from a single community council budget allocation. Cost per project: approximately 5,500 PYTH.\n\n 2\n\n read \n\n 10\n min\n\n post by CrownOfLagos on May 6\n\n CrownOfLagos\n\n Oh this so great\nFull details of the Pyth Hackathon round 1, I love this so much just finish reading through.\nBig shoutout the the Community council members and specially to @Chop you did great sir\n\n post by Ricardo on May 6\n\n Ricardo\n\n Discovering and rewarding brilliant ideas and talent, that’s how you know you’re in the right place !\n\n post by totti on May 11\n\n totti\n\n absolute banger of a read, and great strategy targeting AI discoverability - with AI.\nThanks choppa\n\n post by Smartbott on May 17\n\n Smartbott\n\n Hey choppa, thanks for the post-mortem. Quick clarification on the bonus prizes — the original hackathon announcement listed two additional categories that don’t appear in this wrap-up:\nWikipedia contribution mentioning Pyth (verified): +5,000 PYTH\nQuality X content about Pyth and/or what you have built: +1,000 PYTH\n\n post by Wattson on May 21\n\n Wattson\n\n This was fun, looking forward to the next one choppa\n\n 9 days later\n\n post by Smartbott on May 31\n\n Smartbott\n\n Regarding Prize Distribution Delays — Community Trust Concern\nI want to raise a constructive concern about the prize distribution timeline for Round 1.\nTimeline for context:\nHackathon ran: ~4 weeks (March 4 – April 1, 2026)\nWinners announced: April 7, 2026\nCurrent date: Late May 2026\nDays elapsed since announcement: 45+ days\nI understand KYC is necessary and takes time. However, nearly two months post-announcement with no prize payments or clear timeline creates a credibility issue — not just for the winners, but for the entire community.\nWhy this matters:\nContributors spent weeks building. Announcing winners without a clear payout plan signals the commitment wasn’t complete.\nIf Round 2 is announced, participation will be lower. Builders remember broken promises.\nFor a community-driven hackathon, trust is the currency. Delays erode it faster than they can be rebuilt.\nWhat would help:\nClear public timeline: “KYC open until [DATE]. Payouts by [DATE].”\nWeekly status updates in this thread or a dedicated post\nIf there are blockers (legal, partner delays, etc.), transparency about what’s stuck\nThe hackathon itself was well-organized. The execution on the back-end needs the same care.\nLooking forward to seeing this wrapped up soon. \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Playground Community Hackathon\n\n Ideas Bank\n\n 25\n\n 731\n\n Mar 11\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 568\n\n Apr 6\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14","tokens":7675,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267728583,"hash":"7a6b89657b7877e37d7cc16028f4e9da524f3c32"}
{"url":"https://gov.optimism.io/t/season-8-growth-grants-tvl-impact-review/10878","domain":"gov.optimism.io","title":"Season 8 Growth Grants - TVL Impact Review - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n Season 8 Growth Grants - TVL Impact Review \n\n ✨ General\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 22\n\n 1 / 3\n\n Sep 23\n\n 13d ago\n\n post by brichis on Sep 22\n\n brichis\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me.\nI did it for fun, to learn new tools, and to show a different perspective: the view of a former councilor. I also want to keep the lessons from Season 8 before they are lost. I do not know what future programs will look like. But I hope these results help to define the next iterations of grant programs.\nI hope you enjoy it! If you have anything to add, feel free to DM me.\nTL;DR\n\nNine Season 8 growth programs received 2.21M OP. In the targeted contracts, the ΔTVL was +$8.00M, or $3.62 per OP delivered. Six of the nine programs were positive.\nOne grant, 40acres.finance, supplied 84% of the net total.\n5 of the 8 grants with a Milestone 1 target reached it on at least one day in the incentive window. Of the seven grants with a full-program target, one reached it.\nPrograms peak early and then lose the liquidity. The median program peaked on day 56, at 41% of its window.\n1.27M OP is still in the claim contract. It belongs to grants that did not run a program, and the grantees did not claim it.\n\nFull report: brichis.xyz/reports/s8-growth-grants\nCode and data: github.com/brichis/s8-grant-impact-analysis\nContext\nAcross Season 8, the Council approved 24 applications and used the full 6.29M OP budget. This review measures the nine grants that claimed their OP and ran an incentive program that we can measure on-chain. For each program, the review shows three things:\n\nWhat the liquidity in the incentivized contracts did while the rewards ran.\nWhat the liquidity did after the rewards stopped.\nWhat the next program must do differently.\n\nThe data is through 2026-09-15. Two programs, Curve Lending and Velodrome, are still active. Their figures are an interim measurement at that date, and you cannot compare them directly with the seven programs that closed.\nMethod\nEach of these points is a choice, and each choice changes the numbers. We list them so that anyone who prefers a different choice can see where the difference starts and calculate again from the same measurements.\n\nMetric. ΔTVL = Σ (quantity at incentive end − quantity at incentive start) × token price at the end date, over the contracts that each grant incentivized. The formula comes from the S8 Impact Measurement Methodology.\nTargeted scope. We measure only the contracts that each grant named, contract by contract. A protocol’s total TVL changes for reasons that are not related to a grant. The disadvantage of this choice is that it does not show spillover into the rest of the protocol. Oku has no contract of its own, so we measure the Morpho vault position of the 67 wallets that Oku paid.\nWindow. The window starts on the first day that the program paid incentives and stops on the last day, with no season cap. This is not the official window. The official window opens at grant delivery and closes at the incentive end or at the end of Season 8 (24 December 2025), whichever comes first. All nine programs ended after that date, so the cap cuts every program short. The daily series in the repository let you apply the official window to the same measurement.\nFixed prices. We value all quantities at one date, the incentive end. Thus, ΔTVL counts liquidity that users added, not token price changes.\nMilestones. A milestone is met if the validated daily series reached the target on any day in the window.\nCo-incentives. We do not discount co-incentives. Every grant reports at 100% attribution.\nData sources. No grantee self-reported data is an input. All quantities come from on-chain reads. Each daily series must reproduce every on-chain checkpoint before we use it.\n\nKey findings\nWhat each program did\nThe peak is the highest value that the daily series reached in the incentive window. The milestone columns use this peak.\n\nGrantee\nOP\nS8 ΔTVL\n$/OP\nM1\nTotal\nRetention +30d\nPeak\n\nVelodrome Finance (interim)\n760,000\n−$463,690\n−0.61\n✓\n✓\n—\n$10,446,680\n\n40acres.finance\n200,000\n$6,757,803\n33.79\n✓\n✗\n109.0%\n$7,150,411\n\nCurve Lending (interim)\n250,000\n$442,797\n1.77\n✓\n—\n—\n$3,777,080\n\nExtrafi\n100,000\n−$126,636\n−1.27\n✓\n✗\n76.8%\n$2,059,448\n\nTruemarkets\n70,000\n$984,742\n14.07\n✗\n✗\n43.7%\n$1,776,404\n\nPancakeSwap\n600,000\n$685,923\n1.14\n✗\n✗\n61.0%\n$1,512,961\n\nHydrex\n50,000\n−$315,659\n−6.31\n✗\n—\n33.6%\n$186,224\n\nOku\n150,000\n$37,310\n0.25\n✓\n✗\n—\n$37,310\n\nSuper DCA\n30,000\n$1,390\n0.05\n—\n✗\n97.4%\n$2,496\n\nTotal\n2,210,000\n$8,003,979\n3.62\n5 met\n1 met\n\nRetention +30d is available only where a window closed 30 days before the cutoff.\nFigure 1 · Peak reached vs. where it ended\nfig1_peak_vs_end2200×920 130 KB\nVelodrome reached +$10.4M and is now less than zero. 40acres kept 95% of its peak.\nConcentration. 40acres.finance supplied 84% of the net total. Of the positive changes only, 40acres supplied 75.8%.\nFigure 2 · The same nine curves, on one scale\nfig2_normalized_curves2200×1020 397 KB\nEach line shows a program’s ΔTVL as a percentage of its own peak, against the percentage of its window. The shape repeats: an increase, a peak near the middle, and then a slow decrease. Three of the five programs that met M1 were less than that target again at their last measurement: Extrafi when it closed, and Velodrome and Curve Lending at the cutoff.\nFigure 3 · The nine curves\nfig3_nine_curves2200×2150 385 KB\nEach panel shows a program’s daily ΔTVL. The dotted line shows the day that the incentive stopped. The shaded band shows the 30 days after it, and it does not count toward the peak. The two interim programs have no band because their window is still open.\nThese daily series do not always end on the last figure in the table, for two reasons:\n\nFor the seven programs that closed, the line continues 30 days after the incentive end.\nThe Velodrome series comes from Dune token transfers, and Dune does not cover Soneium. Soneium contributes −$62,904 to the ΔTVL in the table.\n\nWhere the two values are different, the table is the measurement and the line is the shape.\nLessons for future programs\n1 · Judge milestones on what actually happened\nA single-date checkpoint cannot show the difference between two types of program. One program reached its target and lost the liquidity. The other program never came near the target. Thus, this review uses the full window.\nA possible objection is that a team can touch the target for one day and then remove the liquidity. The solution is to require an average over a set number of days. Here, the best 7-day average gives the same verdicts. This result shows that these peaks were levels that stayed for weeks, not one-day spikes.\n2 · Twelve months is the allowance, three is the useful deadline\nThe Council approved all grants in this season between 12 September and 19 December 2025. Teams had approximately one year to do the work. The teams that delivered did not need the year.\n\nStage\nMedian\nRange\n\nApplication submitted → approved\n21 days\n15–59\n\nApproved → OP delivered\n41 days\n20–144\n\nOP delivered → incentives live\n3 days\n−91 to 88\n\nApplication → incentives live\n71 days\n51–218\n\nEach stage is the median of its own distribution, so the three stages do not add up to the 71 days in the last row. “Delivered” means that the first tranche reached the grantee on-chain, so the middle stage includes the time that the grantee took to claim. A negative figure means that incentives started before the OP was delivered.\nIn seven of the nine programs, most of the wait came before the OP reached the grantee. The other two programs started before delivery. 40acres went from application to launch in 51 days, the best result in the cohort. Curve Lending took 218 days.\nGive three months from approval to launch, not twelve, with a deadline for the final report. Include the delivery in those three months. Delivery took a median of 41 days, and the decision took 21.\n3 · The extra weeks bought decay, not liquidity\nThe median program length was 16.6 weeks, from 9 to 31. But the peak came at a median of day 56 (week eight), and it did not come later in the longer programs. The Spearman rank correlation between program length and peak day is −0.10, which is no correlation. Eight of the nine programs peaked in the first twelve weeks. The longer windows added the decrease after the peak, not more liquidity.\nIf we use only the seven programs that closed, the result is the same. The median length is 14.9 weeks, the median peak is day 56, and six of the seven peaked in the first twelve weeks.\nSet a fixed duration of approximately twelve weeks, with a review at week eight. Extend a program only if there is evidence that liquidity continues to increase. Nine programs cannot prove an optimal length. The sample also cannot show if a shorter program can reach the same peak. But it does show that these windows mostly paid for time after the peak.\n4 · Staged payments worked, and there is OP to try to recover\nFigure 4 · Where the 6.29M OP went\nfig4_where_the_op_went2200×340 16.1 KB\nOnly the first block funded a measured program. The third block never left the claim contract. The four blocks come from the five cycle reports of the Council and from the public delivery tracker of the Foundation. We compared them with the Hedgey claim contract on-chain.\n\n2.47M OP was never released, because later tranches were conditional on progress.\n340k OP went to grants that did not run a program. With a first tranche of 20% instead of 40%, approximately half of this amount is at risk.\n1.27M OP went to the claim contract, and the grantees did not claim it: Morpho 600k, Tydro 600k, LiqPass 32k, Strands 28k, NEUS 8k. None of it left the contract, and this is visible on-chain. The LiqPass grant was withdrawn. Treat the 1.27M as possibly recoverable and worth the effort, not as recovered.\n\nThe councils were dissolved on 15 July 2026. The approved dissolution proposal states that the Foundation will monitor the remaining milestones through a third-party contractor. But the proposal does not say who decides what happens to OP that was released and not used. The community can help: watch whether these programs deliver, and ask for recovery where they do not.\nThe fifteen grants that did not run a program were approved between 23 October and 19 December 2025. Each of them reaches one year between October and December 2026.\n5 · OP moved too much for plans in USD\nFigure 5 · OP price across the season\nfig5_op_price2200×660 49.3 KB\nThe targets were in USD and did not change. OP fell 55% between the average program start and the average program end. The OP behind these grants was worth $708k at delivery and $291k when the programs ended.\nThe milestone report of Hydrex states that the grant structure used an OP price of $0.65. At the time of the report, the price was $0.33. A decrease of this size is also a possible cause of the low $/OP. The program had a budget worth half of the planned value, and co-incentives had the same problem. Thus, the program delivered less than the approval expected, and the target did not change.\n6 · Collect the evaluation inputs at approval time\nFor this review, we rebuilt the incentive windows and the incentivized contracts manually, from milestone updates, social posts and on-chain data.\nTVL at the price of each day, as DefiLlama and similar dashboards show it, is not a replacement. Across the eight grants with a price breakdown, the same contracts decreased by $5.62M with that method. ΔTVL at fixed prices increased by $7.97M. The $13.59M gap is token price movement, not liquidity.\nA short form at approval, with an update at each milestone, can give this review automatically. The form needs:\n\nIncentive start and end dates, with a link to the announcement.\nContract addresses or pool IDs for each chain, and their type.\nIncentive token and amount for each period.\nCo-incentives in token units.\n\n7 · Size the incentive in OP, and say how you will measure a USD milestone\nWrite the incentive in OP, not in USD. In this season, a program promised users a fixed USD amount to keep their funds in for a set time. When OP fell, the team had to find the difference in other sources. A grant is a number of tokens, and the program must use the same unit.\nA milestone can still be in USD, because a USD target is often clear to all readers. But the grant must also state how we will measure it. Public tools are sufficient for this calculation: on-chain reads from an archive node for the quantities, and DefiLlama or a price API for the prices at the fixed date. It is the same calculation that this report uses. Agree on it when the Council approves the grant, not when the Council judges it.\nLimitations\n\nTargeted scope does not show spillover into other contracts of the same protocol.\nThe window is not the official S8 window. The official window gives different figures.\nWe did not find a method to verify how much co-incentive each team actually deployed, so the review does not include co-incentives.\nCurve Lending and Velodrome are still active. Their figures are an interim measurement at 2026-09-15.\nDelivery dates come from Blockscout and include the time that each grantee took to claim. The data can miss payments made after the councils were dissolved, or payments sent by a different route.\n\nDisclosure\nBecause of my time on the councils, the payment data is first-hand until the councils were dissolved. This is a disclosure, not a claim of neutrality. You can reproduce all the figures from the sources in the report, and the full pipeline is public. I built the review with Claude.\nThis review shows only what is visible from the outside. Information from the teams is especially useful: a program that ran without a report, or a payment that I could not find.\nSources\n\nFull report\nPipeline repository: measurements, Dune queries, and cohort_summary.py, which calculates every figure\nS8 Impact Measurement Methodology\nSeason 8 cycle reports (41, 42, 43, 44, and the Cycle 46 and Season 8 final report), the public delivery tracker of the Foundation, and the dissolution proposals of the councils. The report links each of them.\n\n Season 9 Final Report\n\n read \n\n 6\n min\n\n post by MconnectDAO on Sep 22\n\n post by JulianCross on Sep 23\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Grants Council Season 7 Retrospective Report\n\n Grants Updates\n\n 1. What is your assessment of the impact KPIs that were set in your Budget Proposal at the start of the Season? Have you made progress towards, or achieved, these milestones or KPIs? If not, why?\nWe met 100% of the inter…\n\n read more\n\n 10\n\n 608\n\n Jun 2025\n\n S7 Grants Council Impact Analysis\n\n Governance Fund Missions\n\n season-7\n\n TL;DR:\n\nAn observational analysis of S7 Grants Council grants measured OP-normalized ROI using net Superchain TVL inflows between March 20 and June 12, 2025.\nROI benchmarks emerged at $1.58 (25th percentile), $3.67 (medi…\n\n read more\n\n 19\n\n 1.1k\n\n Dec 2025\n\n S8 Grants Council Impact Analysis\n\n Accountability 🗂️\n\n season-8\n\n The intention behind this impact analysis is to equip the Optimism Collective with preliminary results of the Grants Council’s S8 grants and help inform OP allocation decisions in S9. It was prepared by OSO in collabora…\n\n read more\n\n 0\n\n 169\n\n Jan 23\n\n May 2023 - Governance Call OP Rewards Analytics Update\n\n Accountability 🗂️\n\n Background\nThe data team at OP Labs has been working on tracking OP distributions across governance grants, partner funding, and other sources. We aim to share grant program performance and insights on a monthly basis in…\n\n read more\n\n 2\n\n 2.0k\n\n May 2023\n\n Season 8 Intent\n\n Intents\n\n season-8\n\n Season 8 Intent\nThis post outlines the main strategic goal of the Collective for 2H25 (Season 8 Intent) and highlights the contributions the Collective will support towards that goal. The audience for this post is all co…\n\n read more\n\n 20\n\n 2.1k\n\n Aug 2025","tokens":4065,"squid":"ink-governance","role":"Council Listener","at":1791267728970,"hash":"4d82d20981f0126caebe174369db7f70d55f1f4c"}
{"url":"https://ethereum.org/en/bug-bounty/","domain":"ethereum.org","title":"Ethereum Bug Bounty Program | ⁦ethereum.org⁩","text":"Glamsterdam Bug BountyThe Glamsterdam upgrade will be in scope once its release candidates are announced on the Ethereum Foundation blog (opens in a new tab). Glamsterdam specifications and EIPs are already in scope with a 0.5× multiplier.The special rules and multipliers below only apply to bugs specific to the Glamsterdam upgrade. Researchers should target the latest unstable client branches and check for existing issues and pull requests. Bugs already covered by an open issue or pull request are not eligible.Released clients, EIPs and specifications are now in scope, as per the blog post (opens in a new tab).Reward multipliers0.5×: From publication of the release candidate blog post until the scheduled Sepolia testnet upgrade. Medium, High and Critical findings are in scope. Glamsterdam specifications and EIPs are already eligible for this multiplier.2.0×: From 24 hours after the Sepolia upgrade epoch finalizes until the Hoodi upgrade. Low, Medium, High and Critical findings are in scope.1.5×: From the Hoodi upgrade until one week before the scheduled mainnet upgrade. Low, Medium, High and Critical findings are in scope.The multiplier will be determined by when a report is submitted, not when the bug was discovered. The reward amounts shown elsewhere on this page are the standard caps; Glamsterdam multipliers adjust those caps and do not guarantee an award.Low-severity Glamsterdam findings do not receive rewards during the 0.5× window. Eligibility is based on validated severity.Upgrade dates are subject to change.The existing bug bounty rules continue to apply to Glamsterdam reports. All reports unrelated to Glamsterdam follow the normal bug bounty submission rules.Clients featured in the bountiesIn ScopeOur bug bounty program spans end-to-end: from soundness of protocols (such as the blockchain consensus model, the wire and p2p protocols, proof of stake, etc.) and protocol/implementation compliance to network security and consensus integrity. Classical client security as well as security of cryptographic primitives are also part of the program. All bug disclosures and vulnerability submissions must be made through our bug submission form (opens in a new tab).Fast Confirmation Rule (opens in a new tab) is now in scope of the Bug Bounty Program.Specification bugsThe Ethereum Specifications detail the design rationale for the Execution Layer and Consensus Layer.Consensus Layer Specifications (opens in a new tab)Execution Layer Specifications (opens in a new tab)It might be helpful to check out the following annotations:Ben Edgington's annotated spec (opens in a new tab)Vitalik Buterin's annotated spec (opens in a new tab)Types of bugsSafety/finality-breaking bugsDenial of service (DOS) vectorsInconsistencies in assumptions, like situations where honest validators can be slashedCalculation or parameter inconsistenciesSpecification documentsBeacon Chain (opens in a new tab)Fork choice (opens in a new tab)Solidity deposit contract (opens in a new tab)Peer-to-peer networking (opens in a new tab)Client bugsClients run the Ethereum Network, and they need to follow the logic set out in the specification and be secure against potential attacks. The bugs we want to find are related to the implementation of the protocol.Currently execution layer clients (Besu, Erigon, Geth, Nethermind and Reth) and consensus layer clients (Grandine, Lighthouse, Lodestar, Nimbus, Prysm and Teku) are included in the Bug Bounty Program.Types of bugsSpec non-compliance issuesUnexpected crashes, RCE or denial of service (DOS) vulnerabilitiesAny issues causing irreparable consensus splits from the rest of the networkHelpful linksBesu (opens in a new tab)Erigon (opens in a new tab)Geth (opens in a new tab)Lighthouse (opens in a new tab)Lodestar (opens in a new tab)Nimbus (opens in a new tab)Nethermind (opens in a new tab)Prysm (opens in a new tab)Reth (opens in a new tab)Teku (opens in a new tab)Grandine (opens in a new tab)Language compiler bugsThe Solidity and Vyper compilers are in scope of the bug bounty program. Please include all details necessary to reproduce the vulnerability such as: Input program that triggers the bug, Compiler version affected, Target EVM version, Framework/IDE if applicable, EVM execution environment/client if applicable and Operating system, Please include steps to reproduce the bug you have found in as much detail as possible.Solidity and Vyper do not hold security guarantees regarding compilation of untrusted input – and we do not issue rewards for crashes of the compiler on maliciously generated data.Helpful linksSolidity (opens in a new tab)Vyper (opens in a new tab)Deposit Contract bugsThe specifications and source code of the Beacon Chain Deposit Contract is part of the bug bounty program.Helpful linksDeposit Contract Specifications (opens in a new tab)Deposit Contract Source Code (opens in a new tab)Dependency bugsCertain dependencies are crucial for the Ethereum Network to function, and some of these have been added to the bug bounty program. Currently, the list of dependencies included in the bug bounty program are C-KZG-4844 and Go-ETH-KZG.Helpful linksC-KZG-4844 (opens in a new tab)Go-ETH-KZG (opens in a new tab)Out of scopeOnly the targets listed under in-scope are part of the Bug Bounty Program. Vulnerabilities that do NOT qualify under the program include:✕Infrastructure bugs—such as webpages, DNS, email, etc.*✕ERC-20 contract bugs*✕Ethereum Naming Service (ENS) bugs (maintained by the ENS foundation)✕Vulnerabilities requiring the user to have publicly exposed an API, such as JSON-RPC or the Beacon API✕EngineAPI is considered trusted and not meant to be publicly exposed✕Typographical errors✕Tests✕High-effort (sustained, CPU or bandwidth intensive, and/or requires more than 1 packet or onchain transaction) single-peer DoS attacks✕Any publicly known issues (includes forum posts, PRs, github issues, commits, blog posts, public discord messages, etc.)✕Anything that does not currently have a direct impact on Ethereum mainnet.*These are not included, however, we can sometimes help reach out to affected partiesBug hunting rulesThe bug bounty program is an experimental and discretionary rewards program for our active Ethereum community to encourage and reward those who are helping to improve the platform. It is not a competition. You should know that we can cancel the program at any time, and awards are at the sole discretion of Ethereum Foundation bug bounty panel. In addition, we are not able to issue awards to individuals who are on sanctions lists or who are in countries on sanctions lists (e.g., North Korea, Iran, etc). Local laws require us to ask for proof of your identity. You are responsible for all taxes. All awards are subject to applicable law. Finally, your testing must not violate any law or compromise any data that is not yours and must take place on local running testnets.1Issues without a POC or that have already been submitted by another user or are already known to spec and client maintainers are not eligible for bounty rewards.2Public disclosure of a vulnerability or reporting it to other parties without prior agreement makes it ineligible for a bounty.3Employees, contractors, service providers or grantees of the Ethereum Foundation, or members of client teams in scope of the bounty program, may participate in the program only in the accrual of points and will not receive monetary rewards during the relevant relationship and for 90 days after it ends. Vulnerabilities discovered during either of these periods, or through non-public information obtained through such a relationship, remain ineligible for monetary rewards regardless of when they are reported.4Ethereum bounty program considers a number of variables in determining rewards. Determinations of eligibility, score and all terms related to an award are at the sole and final discretion of the Ethereum Foundation bug bounty panel.Vulnerability severity qualificationsSeverity is assessed based on each discovered vulnerability's unique ability to do the following:Low severitySlash >0.01% of validatorsTrivially cause network splits affecting >0.01% of the networkBe able to bring down >0.01% of the network by sending a single network packet or an onchain transactionMedium severitySlash >1% of validatorsTrivially cause network splits affecting >5% of the networkBe able to bring down >5% of the network by sending a single network packet or an onchain transactionHigh severitySlash >33% of validatorsTrivially cause network splits affecting >33% of the networkBe able to bring down >33% of the network by sending a single onchain transactionCritical severitySlash >50% of validatorsExploit an EIP/specification or client bug to easily create an infinite amount of ETH which is finalized by the networkSteal ETH from all EOAsBurn ETH from all EOAsTake down the entire network by sending a single malicious onchain transaction that ends up crashing all clientsSubmit a bugUp to 2,000 USDLowUp to 2,000 USDUp to 1,000 pointsSubmit low risk bug (opens in a new tab)Up to 10,000 USDMediumUp to 10,000 USDUp to 5,000 pointsSubmit medium risk bug (opens in a new tab)Up to 50,000 USDHighUp to 50,000 USDUp to 10,000 pointsSubmit high risk bug (opens in a new tab)Up to 1,000,000 USDCriticalUp to 1,000,000 USDUp to 25,000 pointsSubmit critical risk bug (opens in a new tab)Execution Layer Bug Bounty leaderboardFind execution layer bugs to get added to this leaderboard1hGa (opens in a new tab)In place number 1 with 64,500 pointsMartin Holst Swende (See GitHub Profile) (opens in a new tab)64500 points2gGa (opens in a new tab)In place number 2 with 35,250 pointsGuido Vranken (See GitHub Profile) (opens in a new tab)35250 points3sGa (opens in a new tab)In place number 3 with 35,000 pointsSam Sun (See GitHub Profile) (opens in a new tab)35000 points4In place number 4 with 31,000 pointsnrv (@nervoir) 31000 points5rGa (opens in a new tab)In place number 5 with 25,000 pointsRevofusion (See GitHub Profile) (opens in a new tab)25000 points6cGa (opens in a new tab)In place number 6 with 24,500 pointsChainSecurity (See GitHub Profile) (opens in a new tab)24500 points7cGa (opens in a new tab)In place number 7 with 21,000 pointscyberthirst (See GitHub Profile) (opens in a new tab)21000 points8jGa (opens in a new tab)In place number 8 with 20,500 pointsJuno Im (See GitHub Profile) (opens in a new tab)20500 points9uGa (opens in a new tab)In place number 9 with 20,000 pointsYoonho Kim (team Hithereum) (See GitHub Profile) (opens in a new tab)20000 points10jGa (opens in a new tab)In place number 10 with 20,000 pointsJohn Youngseok Yang (Software Platform Lab) (See GitHub Profile) (opens in a new tab)20000 points11pGa (opens in a new tab)In place number 11 with 17,000 pointsPeckShield (See GitHub Profile) (opens in a new tab)17000 points12iGa (opens in a new tab)In place number 12 with 16,250 pointsDavid Matosse (See GitHub Profile) (opens in a new tab)16250 points13iGa (opens in a new tab)In place number 13 with 15,000 pointsItsUnixIKnowThis (See GitHub Profile) (opens in a new tab)15000 points14cGa (opens in a new tab)In place number 14 with 15,000 pointsBertrand Masius (See GitHub Profile) (opens in a new tab)15000 points15VGa (opens in a new tab)In place number 15 with 15,000 pointsVulSight (See GitHub Profile) (opens in a new tab)15000 points16tGa (opens in a new tab)In place number 16 with 15,000 pointsBob Conan (See GitHub Profile) (opens in a new tab)15000 points17tGa (opens in a new tab)In place number 17 with 12,500 pointsTin (See GitHub Profile) (opens in a new tab)12500 points18In place number 18 with 12,500 pointsRalph Pichler 12500 points19DGa (opens in a new tab)In place number 19 with 11,250 pointsDelene Tchio Romuald (See GitHub Profile) (opens in a new tab)11250 points20lGa (opens in a new tab)In place number 20 with 11,000 pointsŁukasz Matczak (See GitHub Profile) (opens in a new tab)11000 points21eGa (opens in a new tab)In place number 21 with 10,500 pointseclipse07077 (See GitHub Profile) (opens in a new tab)10500 points22In place number 22 with 10,000 pointsHeilman/Marcus/Goldberg 10000 points23jGa (opens in a new tab)In place number 23 with 10,000 pointsJonas Nick (See GitHub Profile) (opens in a new tab)10000 points24jGa (opens in a new tab)In place number 24 with 10,000 pointsJohn Toman (See GitHub Profile) (opens in a new tab)10000 points25eGa (opens in a new tab)In place number 25 with 10,000 pointsDongHan Kim (See GitHub Profile) (opens in a new tab)10000 points26cGa (opens in a new tab)In place number 26 with 10,000 pointsCantina (See GitHub Profile) (opens in a new tab)10000 points27In place number 27 with 8,000 pointsSebastian Henningsen 8000 points28In place number 28 with 7,500 pointsDominic Brütsch 7500 points29rGa (opens in a new tab)In place number 29 with 5,250 pointsaarnavrotten (See GitHub Profile) (opens in a new tab)5250 points30HGa (opens in a new tab)In place number 30 with 5,000 pointsHarry Roberts (See GitHub Profile) (opens in a new tab)5000 points31pGa (opens in a new tab)In place number 31 with 5,000 pointsPeter Stöckli (See GitHub Profile) (opens in a new tab)5000 points32DGa (opens in a new tab)In place number 32 with 5,000 pointsNeville Grech (See GitHub Profile) (opens in a new tab)5000 points33EGa (opens in a new tab)In place number 33 with 5,000 pointsEthHead (See GitHub Profile) (opens in a new tab)5000 points34iGa (opens in a new tab)In place number 34 with 5,000 pointsiosiro (See GitHub Profile) (opens in a new tab)5000 points35YGa (opens in a new tab)In place number 35 with 5,000 pointsYenya (See GitHub Profile) (opens in a new tab)5000 points36gGa (opens in a new tab)In place number 36 with 5,000 pointsgzeon (See GitHub Profile) (opens in a new tab)5000 points37hGa (opens in a new tab)In place number 37 with 3,750 pointssecuholic (See GitHub Profile) (opens in a new tab)3750 points38aGa (opens in a new tab)In place number 38 with 3,500 pointsAlex Beregszaszi (See GitHub Profile) (opens in a new tab)3500 points39gGa (opens in a new tab)In place number 39 with 3,500 pointsgrandchildrice (Nyx Foundation) (See GitHub Profile) (opens in a new tab)3500 points400Ga (opens in a new tab)In place number 40 with 3,000 pointsalpharush (See GitHub Profile) (opens in a new tab)3000 points41SGa (opens in a new tab)In place number 41 with 2,500 pointsSergio Demian Lerner (See GitHub Profile) (opens in a new tab)2500 points42dGa (opens in a new tab)In place number 42 with 2,500 pointsDaniel Perez (See GitHub Profile) (opens in a new tab)2500 points43eGa (opens in a new tab)In place number 43 with 2,500 pointsOP Labs (See GitHub Profile) (opens in a new tab)2500 points44sGa (opens in a new tab)In place number 44 with 2,500 pointsShaheen Fazim (See GitHub Profile) (opens in a new tab)2500 points45yGa (opens in a new tab)In place number 45 with 2,000 pointsYaron Velner (See GitHub Profile) (opens in a new tab)2000 points46wGa (opens in a new tab)In place number 46 with 2,000 pointsWhit Jackson (See GitHub Profile) (opens in a new tab)2000 points47In place number 47 with 2,000 pointsMing Chuan Lin 2000 points48mGa (opens in a new tab)In place number 48 with 2,000 pointsMelonport team (See GitHub Profile) (opens in a new tab)2000 points49mGa (opens in a new tab)In place number 49 with 2,000 pointsMaurelian (See GitHub Profile) (opens in a new tab)2000 points50CGa (opens in a new tab)In place number 50 with 2,000 pointsChristoph Jentzsch (See GitHub Profile) (opens in a new tab)2000 points51hGa (opens in a new tab)In place number 51 with 1,500 pointsHwanjo Heo (See GitHub Profile) (opens in a new tab)1500 points52BGa (opens in a new tab)In place number 52 with 1,500 pointsBlockTrident (See GitHub Profile) (opens in a new tab)1500 points531Ga (opens in a new tab)In place number 53 with 1,500 pointsFudong Wu (See GitHub Profile) (opens in a new tab)1500 points54DGa (opens in a new tab)In place number 54 with 1,200 pointsDVP (dvpnet.io) (See GitHub Profile) (opens in a new tab)1200 points55In place number 55 with 1,000 pointsVasily Vasiliev 1000 points56tGa (opens in a new tab)In place number 56 with 1,000 pointstalko (See GitHub Profile) (opens in a new tab)1000 points57sGa (opens in a new tab)In place number 57 with 1,000 pointsSteve Waldman (See GitHub Profile) (opens in a new tab)1000 points58pGa (opens in a new tab)In place number 58 with 1,000 pointsPanu Kekäläinen (See GitHub Profile) (opens in a new tab)1000 points59mGa (opens in a new tab)In place number 59 with 1,000 pointsJosselin Feist (See GitHub Profile) (opens in a new tab)1000 points60hGa (opens in a new tab)In place number 60 with 1,000 pointsHenrit (See GitHub Profile) (opens in a new tab)1000 points61BGa (opens in a new tab)In place number 61 with 1,000 pointsMarc Bartlett (See GitHub Profile) (opens in a new tab)1000 points62In place number 62 with 1,000 pointsBarry Whitehat 1000 points63bGa (opens in a new tab)In place number 63 with 1,000 pointsLucas Ryan (See GitHub Profile) (opens in a new tab)1000 points64aGa (opens in a new tab)In place number 64 with 1,000 pointsAlex Groce (See GitHub Profile) (opens in a new tab)1000 points65cGa (opens in a new tab)In place number 65 with 1,000 pointsCybermong (See GitHub Profile) (opens in a new tab)1000 points66nGa (opens in a new tab)In place number 66 with 1,000 pointsToni Wahrstätter (See GitHub Profile) (opens in a new tab)1000 points67iGa (opens in a new tab)In place number 67 with 1,000 pointsiosiro (See GitHub Profile) (opens in a new tab)1000 points68gGa (opens in a new tab)In place number 68 with 1,000 pointsgln (See GitHub Profile) (opens in a new tab)1000 points69MGa (opens in a new tab)In place number 69 with 1,000 pointsMingfei Zhang (See GitHub Profile) (opens in a new tab)1000 points70BGa (opens in a new tab)In place number 70 with 1,000 pointsBlockian (See GitHub Profile) (opens in a new tab)1000 points71AGa (opens in a new tab)In place number 71 with 1,000 pointsAudittens (See GitHub Profile) (opens in a new tab)1000 points72sGa (opens in a new tab)In place number 72 with 1,000 pointssonny2k (See GitHub Profile) (opens in a new tab)1000 points73lGa (opens in a new tab)In place number 73 with 1,000 pointsLaurent Gaffie (See GitHub Profile) (opens in a new tab)1000 points74aGa (opens in a new tab)In place number 74 with 1,000 pointsLegat (See GitHub Profile) (opens in a new tab)1000 points75pGa (opens in a new tab)In place number 75 with 1,000 pointsphx & Alleysira (UTUX Labs) (See GitHub Profile) (opens in a new tab)1000 points76uGa (opens in a new tab)In place number 76 with 1,000 pointsustas (See GitHub Profile) (opens in a new tab)1000 points77DGa (opens in a new tab)In place number 77 with 1,000 pointsDanielBoye (See GitHub Profile) (opens in a new tab)1000 points78nGa (opens in a new tab)In place number 78 with 750 pointsDaniel Briskin (See GitHub Profile) (opens in a new tab)750 points79dGa (opens in a new tab)In place number 79 with 750 pointsDaenam Kim (See GitHub Profile) (opens in a new tab)750 points80In place number 80 with 500 pointsMyeongjae Lee 500 points81In place number 81 with 500 pointsMarcin Noga (Cisco/Talos Security) 500 points82In place number 82 with 500 pointsjazzybedi 500 points83fGa (opens in a new tab)In place number 83 with 500 pointsFeeker - 360 ESG Codesafe Team (See GitHub Profile) (opens in a new tab)500 points84eGa (opens in a new tab)In place number 84 with 500 pointsJonathan Brown (See GitHub Profile) (opens in a new tab)500 points85dGa (opens in a new tab)In place number 85 with 500 pointsDavid Murdoch (See GitHub Profile) (opens in a new tab)500 points86wGa (opens in a new tab)In place number 86 with 500 pointsAlexander Wade (See GitHub Profile) (opens in a new tab)500 points87cGa (opens in a new tab)In place number 87 with 500 pointsPaweł Bylica (See GitHub Profile) (opens in a new tab)500 points88tGa (opens in a new tab)In place number 88 with 500 pointsTimmy (See GitHub Profile) (opens in a new tab)500 points89rGa (opens in a new tab)In place number 89 with 250 pointsRiley Holterhus (See GitHub Profile) (opens in a new tab)250 points90hGa (opens in a new tab)In place number 90 with 250 pointsHowy (See GitHub Profile) (opens in a new tab)250 points91gGa (opens in a new tab)In place number 91 with 200 pointsLuis Schliesske (See GitHub Profile) (opens in a new tab)200 pointsConsensus Layer Bug Bounty leaderboardFind consensus layer bugs to get added to this leaderboard1rGa (opens in a new tab)In place number 1 with 46,250 pointsRevofusion (See GitHub Profile) (opens in a new tab)46250 points2pGa (opens in a new tab)In place number 2 with 42,400 pointsprotolambda (See GitHub Profile) (opens in a new tab)42400 points3cGa (opens in a new tab)In place number 3 with 19,650 pointsQuan Thoi Minh Nguyen (See GitHub Profile) (opens in a new tab)19650 points4jGa (opens in a new tab)In place number 4 with 18,700 pointsJonny Rhea (See GitHub Profile) (opens in a new tab)18700 points5gGa (opens in a new tab)In place number 5 with 17,850 pointsGuido Vranken (See GitHub Profile) (opens in a new tab)17850 points6In place number 6 with 10,000 pointsscio 10000 points7gGa (opens in a new tab)In place number 7 with 9,000 pointsGrandine team (See GitHub Profile) (opens in a new tab)9000 points8gGa (opens in a new tab)In place number 8 with 8,000 pointsgzeon (See GitHub Profile) (opens in a new tab)8000 points9aGa (opens in a new tab)In place number 9 with 6,000 pointsalexfilippov314 (See GitHub Profile) (opens in a new tab)6000 points10kGa (opens in a new tab)In place number 10 with 6,000 pointsOnur Kılıç (See GitHub Profile) (opens in a new tab)6000 points11lGa (opens in a new tab)In place number 11 with 6,000 pointsInfiniteSec (See GitHub Profile) (opens in a new tab)6000 points12aGa (opens in a new tab)In place number 12 with 5,000 pointsAntoine Toulme (See GitHub Profile) (opens in a new tab)5000 points13VGa (opens in a new tab)In place number 13 with 5,000 pointsVulnerabilityX (See GitHub Profile) (opens in a new tab)5000 points14jGa (opens in a new tab)In place number 14 with 5,000 pointsJohn Stawinski (See GitHub Profile) (opens in a new tab)5000 points15sGa (opens in a new tab)In place number 15 with 5,000 pointsGiuseppe Cocomazzi (See GitHub Profile) (opens in a new tab)5000 points16aGa (opens in a new tab)In place number 16 with 4,000 pointsAntonio Sanso (See GitHub Profile) (opens in a new tab)4000 points17uGa (opens in a new tab)In place number 17 with 3,500 pointsustas (See GitHub Profile) (opens in a new tab)3500 points18kGa (opens in a new tab)In place number 18 with 3,000 pointsPeter Szilagyi (See GitHub Profile) (opens in a new tab)3000 points19iGa (opens in a new tab)In place number 19 with 2,850 pointsItsUnixIKnowThis (See GitHub Profile) (opens in a new tab)2850 points20AGa (opens in a new tab)In place number 20 with 2,500 pointsAlexander Sadovskyi (See GitHub Profile) (opens in a new tab)2500 points21tGa (opens in a new tab)In place number 21 with 2,500 pointstintin (See GitHub Profile) (opens in a new tab)2500 points22hGa (opens in a new tab)In place number 22 with 2,500 pointsMartin Holst Swende (See GitHub Profile) (opens in a new tab)2500 points23sGa (opens in a new tab)In place number 23 with 2,500 pointsThanh Luu (sonny2k) (See GitHub Profile) (opens in a new tab)2500 points24hGa (opens in a new tab)In place number 24 with 2,000 pointssecuholic (See GitHub Profile) (opens in a new tab)2000 points250Ga (opens in a new tab)In place number 25 with 2,000 pointsalpharush (See GitHub Profile) (opens in a new tab)2000 points26In place number 26 with 1,750 pointsAkincibor 1750 points27qGa (opens in a new tab)In place number 27 with 1,500 pointsEvgeny Legerov (See GitHub Profile) (opens in a new tab)1500 points28nGa (opens in a new tab)In place number 28 with 1,000 pointsToni Wahrstätter (See GitHub Profile) (opens in a new tab)1000 points29DGa (opens in a new tab)In place number 29 with 1,000 pointsDragonDev1906 (See GitHub Profile) (opens in a new tab)1000 points30cGa (opens in a new tab)In place number 30 with 1,000 pointsChainSecurity (See GitHub Profile) (opens in a new tab)1000 points310Ga (opens in a new tab)In place number 31 with 1,000 points0xPulp (See GitHub Profile) (opens in a new tab)1000 points320Ga (opens in a new tab)In place number 32 with 1,000 pointsfadam (See GitHub Profile) (opens in a new tab)1000 points33tGa (opens in a new tab)In place number 33 with 1,000 pointsGrego AI (See GitHub Profile) (opens in a new tab)1000 points34JCGa (opens in a new tab)In place number 34 with 1,000 pointsJeongmin Choi (See GitHub Profile) (opens in a new tab)1000 points35AGa (opens in a new tab)In place number 35 with 1,000 pointsJie Ma (UTUX Labs) (See GitHub Profile) (opens in a new tab)1000 points36aGa (opens in a new tab)In place number 36 with 1,000 pointsLegat (See GitHub Profile) (opens in a new tab)1000 points37lGa (opens in a new tab)In place number 37 with 1,000 pointsLAURENT GAFFIE (See GitHub Profile) (opens in a new tab)1000 points38HGa (opens in a new tab)In place number 38 with 1,000 pointsMadhav Shah (See GitHub Profile) (opens in a new tab)1000 points39sGa (opens in a new tab)In place number 39 with 500 pointsXDZIBECX (See GitHub Profile) (opens in a new tab)500 points40cGa (opens in a new tab)In place number 40 with 500 pointscyberthirst (See GitHub Profile) (opens in a new tab)500 points41eGa (opens in a new tab)In place number 41 with 500 pointseclipse07077 (See GitHub Profile) (opens in a new tab)500 points42tGa (opens in a new tab)In place number 42 with 500 pointsTrail of Bits (See GitHub Profile) (opens in a new tab)500 points43SGa (opens in a new tab)In place number 43 with 500 pointsSta (See GitHub Profile) (opens in a new tab)500 points44sGa (opens in a new tab)In place number 44 with 500 pointssujith (See GitHub Profile) (opens in a new tab)500 points450Ga (opens in a new tab)In place number 45 with 375 pointssorryNotsorry (See GitHub Profile) (opens in a new tab)375 points46aGa (opens in a new tab)In place number 46 with 250 pointsArron5 (See GitHub Profile) (opens in a new tab)250 points47mGa (opens in a new tab)In place number 47 with 200 pointsJim McDonald (See GitHub Profile) (opens in a new tab)200 pointsFrequently asked questionsNo end date is currently set. See the Ethereum Foundation blog (opens in a new tab) for the latest news.Rewards are paid out in ETH or DAI after the submission has been validated, usually a few days later. Local laws require us to ask for proof of your identity. In addition, we will need your ETH address.We can donate your reward to an established charitable organization of your choice.We aim to respond to submissions as fast as possible. Due to the increase in AI submissions, please allow up to a week for us to respond to your submission.Submitting anonymously or with a pseudonym is OK, but will make you ineligible for ETH/DAI rewards. To be eligible for ETH/DAI rewards, we require your real name and a proof of your identity to be sent, encrypted using PGP on our secure drop website, to our legal team at the Ethereum Foundation who are the sole reviewers of the documentation. Donating your bounty to a charity doesn’t require your identity.Please let us know if you do not want your name/nick displayed on the leader board.Every found vulnerability / issue is assigned a score. Bounty hunters are ranked on our leaderboard by total points.","tokens":6863,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267731874,"hash":"5d9f459255ed205ec326aa259f2ec07e798d2707"}
{"url":"https://io.net/blog/tech-trends","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogTech TrendsLatest By Topic (9)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsThe Future of AI Computing: How Decentralization is Changing the GameIO.NET Team / Mar 23, 2025Explore how decentralized computing networks are revolutionizing AI development by providing cheaper, faster, and more scalable alternatives to traditional cloud services.Will AI Agents Replace Human Work? How Decentralized Computing Can Speed Up the ProcessIO.NET Team / Feb 16, 2025How does AI automation affect jobs across industries, and how decentralized computing accelerates AI development, reshaping the future workforce?AI Agents and Decentralized Computing: The Future of Self-Operating IntelligenceIO.NET Team / Feb 9, 2025AI agents paired with decentralized computing create autonomous, scalable systems that reduce costs and increase resilience across industries.Discovering Creativity through BC8: Easy AI-Generated Image CreationIO.NET Team / Jan 19, 2025BC8 creates AI-generated images from text prompts using io.net's decentralized GPU network for faster, affordable image generation with free credits.The Rise of Specialized Agents: Supercharging Decentralized SystemsIO.NET Team / Jan 12, 2025Specialized AI agents leverage DeFi and blockchain technology to create autonomous financial systems, powered by io.net's decentralized GPU infrastructure.Introducing Retrieval Engine: Grounded AI for Enterprise Knowledge ManagementIO.NET Team / Dec 1, 2024New Retrieval Engine from io.net transforms enterprise knowledge management with citation-backed AI responses from trusted document sources.Real-World AI Applications: How Developers Are Leveraging Decentralized GPUsIO.NET Team / Nov 17, 2024Real-world case studies show how AI startups, researchers, and businesses leverage io.net's decentralized GPU network for faster, cost-effective computing.China’s Surge: AI Markets in 2025IO.NET Team / Jul 23, 2024DeepSeek's breakthrough AI model disrupts Western tech dominance, sparking global competition while highlighting the growing need for efficient compute infrastructure.io.net: Powering the Future of DefAIIO.NET Team / Jul 21, 2024io.net powers DefAI with decentralized GPU infrastructure, enabling censorship-resistant AI agents for DeFi at 90% lower costs than Big Tech.","tokens":649,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267747092,"hash":"5b0e3cf01ad8008fbbe4dcf43f643a5e50935058"}
{"url":"https://gov.optimism.io/t/season-8-growth-grants-tvl-impact-review/10878/3","domain":"gov.optimism.io","title":"Season 8 Growth Grants - TVL Impact Review - ✨ General - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n ✨ General\n\n season-8\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 22\n\n 3 / 3\n\n Sep 23\n\n 13d ago\n\n post by brichis on Sep 22\n\n brichis\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me.\nI did it for fun, to learn new tools, and to show a different perspective: the view of a former councilor. I also want to keep the lessons from Season 8 before they are lost. I do not know what future programs will look like. But I hope these results help to define the next iterations of grant programs.\nI hope you enjoy it! If you have anything to add, feel free to DM me.\nTL;DR\n\nNine Season 8 growth programs received 2.21M OP. In the targeted contracts, the ΔTVL was +$8.00M, or $3.62 per OP delivered. Six of the nine programs were positive.\nOne grant, 40acres.finance, supplied 84% of the net total.\n5 of the 8 grants with a Milestone 1 target reached it on at least one day in the incentive window. Of the seven grants with a full-program target, one reached it.\nPrograms peak early and then lose the liquidity. The median program peaked on day 56, at 41% of its window.\n1.27M OP is still in the claim contract. It belongs to grants that did not run a program, and the grantees did not claim it.\n\nFull report: brichis.xyz/reports/s8-growth-grants\nCode and data: github.com/brichis/s8-grant-impact-analysis\nContext\nAcross Season 8, the Council approved 24 applications and used the full 6.29M OP budget. This review measures the nine grants that claimed their OP and ran an incentive program that we can measure on-chain. For each program, the review shows three things:\n\nWhat the liquidity in the incentivized contracts did while the rewards ran.\nWhat the liquidity did after the rewards stopped.\nWhat the next program must do differently.\n\nThe data is through 2026-09-15. Two programs, Curve Lending and Velodrome, are still active. Their figures are an interim measurement at that date, and you cannot compare them directly with the seven programs that closed.\nMethod\nEach of these points is a choice, and each choice changes the numbers. We list them so that anyone who prefers a different choice can see where the difference starts and calculate again from the same measurements.\n\nMetric. ΔTVL = Σ (quantity at incentive end − quantity at incentive start) × token price at the end date, over the contracts that each grant incentivized. The formula comes from the S8 Impact Measurement Methodology.\nTargeted scope. We measure only the contracts that each grant named, contract by contract. A protocol’s total TVL changes for reasons that are not related to a grant. The disadvantage of this choice is that it does not show spillover into the rest of the protocol. Oku has no contract of its own, so we measure the Morpho vault position of the 67 wallets that Oku paid.\nWindow. The window starts on the first day that the program paid incentives and stops on the last day, with no season cap. This is not the official window. The official window opens at grant delivery and closes at the incentive end or at the end of Season 8 (24 December 2025), whichever comes first. All nine programs ended after that date, so the cap cuts every program short. The daily series in the repository let you apply the official window to the same measurement.\nFixed prices. We value all quantities at one date, the incentive end. Thus, ΔTVL counts liquidity that users added, not token price changes.\nMilestones. A milestone is met if the validated daily series reached the target on any day in the window.\nCo-incentives. We do not discount co-incentives. Every grant reports at 100% attribution.\nData sources. No grantee self-reported data is an input. All quantities come from on-chain reads. Each daily series must reproduce every on-chain checkpoint before we use it.\n\nKey findings\nWhat each program did\nThe peak is the highest value that the daily series reached in the incentive window. The milestone columns use this peak.\n\nGrantee\nOP\nS8 ΔTVL\n$/OP\nM1\nTotal\nRetention +30d\nPeak\n\nVelodrome Finance (interim)\n760,000\n−$463,690\n−0.61\n✓\n✓\n—\n$10,446,680\n\n40acres.finance\n200,000\n$6,757,803\n33.79\n✓\n✗\n109.0%\n$7,150,411\n\nCurve Lending (interim)\n250,000\n$442,797\n1.77\n✓\n—\n—\n$3,777,080\n\nExtrafi\n100,000\n−$126,636\n−1.27\n✓\n✗\n76.8%\n$2,059,448\n\nTruemarkets\n70,000\n$984,742\n14.07\n✗\n✗\n43.7%\n$1,776,404\n\nPancakeSwap\n600,000\n$685,923\n1.14\n✗\n✗\n61.0%\n$1,512,961\n\nHydrex\n50,000\n−$315,659\n−6.31\n✗\n—\n33.6%\n$186,224\n\nOku\n150,000\n$37,310\n0.25\n✓\n✗\n—\n$37,310\n\nSuper DCA\n30,000\n$1,390\n0.05\n—\n✗\n97.4%\n$2,496\n\nTotal\n2,210,000\n$8,003,979\n3.62\n5 met\n1 met\n\nRetention +30d is available only where a window closed 30 days before the cutoff.\nFigure 1 · Peak reached vs. where it ended\nfig1_peak_vs_end2200×920 130 KB\nVelodrome reached +$10.4M and is now less than zero. 40acres kept 95% of its peak.\nConcentration. 40acres.finance supplied 84% of the net total. Of the positive changes only, 40acres supplied 75.8%.\nFigure 2 · The same nine curves, on one scale\nfig2_normalized_curves2200×1020 397 KB\nEach line shows a program’s ΔTVL as a percentage of its own peak, against the percentage of its window. The shape repeats: an increase, a peak near the middle, and then a slow decrease. Three of the five programs that met M1 were less than that target again at their last measurement: Extrafi when it closed, and Velodrome and Curve Lending at the cutoff.\nFigure 3 · The nine curves\nfig3_nine_curves2200×2150 385 KB\nEach panel shows a program’s daily ΔTVL. The dotted line shows the day that the incentive stopped. The shaded band shows the 30 days after it, and it does not count toward the peak. The two interim programs have no band because their window is still open.\nThese daily series do not always end on the last figure in the table, for two reasons:\n\nFor the seven programs that closed, the line continues 30 days after the incentive end.\nThe Velodrome series comes from Dune token transfers, and Dune does not cover Soneium. Soneium contributes −$62,904 to the ΔTVL in the table.\n\nWhere the two values are different, the table is the measurement and the line is the shape.\nLessons for future programs\n1 · Judge milestones on what actually happened\nA single-date checkpoint cannot show the difference between two types of program. One program reached its target and lost the liquidity. The other program never came near the target. Thus, this review uses the full window.\nA possible objection is that a team can touch the target for one day and then remove the liquidity. The solution is to require an average over a set number of days. Here, the best 7-day average gives the same verdicts. This result shows that these peaks were levels that stayed for weeks, not one-day spikes.\n2 · Twelve months is the allowance, three is the useful deadline\nThe Council approved all grants in this season between 12 September and 19 December 2025. Teams had approximately one year to do the work. The teams that delivered did not need the year.\n\nStage\nMedian\nRange\n\nApplication submitted → approved\n21 days\n15–59\n\nApproved → OP delivered\n41 days\n20–144\n\nOP delivered → incentives live\n3 days\n−91 to 88\n\nApplication → incentives live\n71 days\n51–218\n\nEach stage is the median of its own distribution, so the three stages do not add up to the 71 days in the last row. “Delivered” means that the first tranche reached the grantee on-chain, so the middle stage includes the time that the grantee took to claim. A negative figure means that incentives started before the OP was delivered.\nIn seven of the nine programs, most of the wait came before the OP reached the grantee. The other two programs started before delivery. 40acres went from application to launch in 51 days, the best result in the cohort. Curve Lending took 218 days.\nGive three months from approval to launch, not twelve, with a deadline for the final report. Include the delivery in those three months. Delivery took a median of 41 days, and the decision took 21.\n3 · The extra weeks bought decay, not liquidity\nThe median program length was 16.6 weeks, from 9 to 31. But the peak came at a median of day 56 (week eight), and it did not come later in the longer programs. The Spearman rank correlation between program length and peak day is −0.10, which is no correlation. Eight of the nine programs peaked in the first twelve weeks. The longer windows added the decrease after the peak, not more liquidity.\nIf we use only the seven programs that closed, the result is the same. The median length is 14.9 weeks, the median peak is day 56, and six of the seven peaked in the first twelve weeks.\nSet a fixed duration of approximately twelve weeks, with a review at week eight. Extend a program only if there is evidence that liquidity continues to increase. Nine programs cannot prove an optimal length. The sample also cannot show if a shorter program can reach the same peak. But it does show that these windows mostly paid for time after the peak.\n4 · Staged payments worked, and there is OP to try to recover\nFigure 4 · Where the 6.29M OP went\nfig4_where_the_op_went2200×340 16.1 KB\nOnly the first block funded a measured program. The third block never left the claim contract. The four blocks come from the five cycle reports of the Council and from the public delivery tracker of the Foundation. We compared them with the Hedgey claim contract on-chain.\n\n2.47M OP was never released, because later tranches were conditional on progress.\n340k OP went to grants that did not run a program. With a first tranche of 20% instead of 40%, approximately half of this amount is at risk.\n1.27M OP went to the claim contract, and the grantees did not claim it: Morpho 600k, Tydro 600k, LiqPass 32k, Strands 28k, NEUS 8k. None of it left the contract, and this is visible on-chain. The LiqPass grant was withdrawn. Treat the 1.27M as possibly recoverable and worth the effort, not as recovered.\n\nThe councils were dissolved on 15 July 2026. The approved dissolution proposal states that the Foundation will monitor the remaining milestones through a third-party contractor. But the proposal does not say who decides what happens to OP that was released and not used. The community can help: watch whether these programs deliver, and ask for recovery where they do not.\nThe fifteen grants that did not run a program were approved between 23 October and 19 December 2025. Each of them reaches one year between October and December 2026.\n5 · OP moved too much for plans in USD\nFigure 5 · OP price across the season\nfig5_op_price2200×660 49.3 KB\nThe targets were in USD and did not change. OP fell 55% between the average program start and the average program end. The OP behind these grants was worth $708k at delivery and $291k when the programs ended.\nThe milestone report of Hydrex states that the grant structure used an OP price of $0.65. At the time of the report, the price was $0.33. A decrease of this size is also a possible cause of the low $/OP. The program had a budget worth half of the planned value, and co-incentives had the same problem. Thus, the program delivered less than the approval expected, and the target did not change.\n6 · Collect the evaluation inputs at approval time\nFor this review, we rebuilt the incentive windows and the incentivized contracts manually, from milestone updates, social posts and on-chain data.\nTVL at the price of each day, as DefiLlama and similar dashboards show it, is not a replacement. Across the eight grants with a price breakdown, the same contracts decreased by $5.62M with that method. ΔTVL at fixed prices increased by $7.97M. The $13.59M gap is token price movement, not liquidity.\nA short form at approval, with an update at each milestone, can give this review automatically. The form needs:\n\nIncentive start and end dates, with a link to the announcement.\nContract addresses or pool IDs for each chain, and their type.\nIncentive token and amount for each period.\nCo-incentives in token units.\n\n7 · Size the incentive in OP, and say how you will measure a USD milestone\nWrite the incentive in OP, not in USD. In this season, a program promised users a fixed USD amount to keep their funds in for a set time. When OP fell, the team had to find the difference in other sources. A grant is a number of tokens, and the program must use the same unit.\nA milestone can still be in USD, because a USD target is often clear to all readers. But the grant must also state how we will measure it. Public tools are sufficient for this calculation: on-chain reads from an archive node for the quantities, and DefiLlama or a price API for the prices at the fixed date. It is the same calculation that this report uses. Agree on it when the Council approves the grant, not when the Council judges it.\nLimitations\n\nTargeted scope does not show spillover into other contracts of the same protocol.\nThe window is not the official S8 window. The official window gives different figures.\nWe did not find a method to verify how much co-incentive each team actually deployed, so the review does not include co-incentives.\nCurve Lending and Velodrome are still active. Their figures are an interim measurement at 2026-09-15.\nDelivery dates come from Blockscout and include the time that each grantee took to claim. The data can miss payments made after the councils were dissolved, or payments sent by a different route.\n\nDisclosure\nBecause of my time on the councils, the payment data is first-hand until the councils were dissolved. This is a disclosure, not a claim of neutrality. You can reproduce all the figures from the sources in the report, and the full pipeline is public. I built the review with Claude.\nThis review shows only what is visible from the outside. Information from the teams is especially useful: a program that ran without a report, or a payment that I could not find.\nSources\n\nFull report\nPipeline repository: measurements, Dune queries, and cohort_summary.py, which calculates every figure\nS8 Impact Measurement Methodology\nSeason 8 cycle reports (41, 42, 43, 44, and the Cycle 46 and Season 8 final report), the public delivery tracker of the Foundation, and the dissolution proposals of the councils. The report links each of them.\n\n Season 9 Final Report\n\n read \n\n 6\n min\n\n post by MconnectDAO on Sep 22\n\n MconnectDAO\n\n This is a valuable and transparent review. The contract level methodology, fixed price approach, and disclosure of limitations make it much more useful than a simple dashboard view.\nMy main concern is that TVL delta alone cannot show the full return on OP incentives. For future programs, can we publish grant level data on actual co incentives deployed, unique and retained users, wallet concentration, volume, fees, protocol revenue, and 30, 60, and 90 day retained TVL?\nIt would also help to publish one final reconciliation table for every grant: OP approved, OP claimed, OP distributed, OP remaining, OP returned or recoverable, milestone status, and the accountable entity for follow up. This is especially important where grants did not launch or where released OP was not used.\nFinally, both the official Season 8 measurement window and the operational incentive window should be shown side by side, so delegates can compare results consistently.\n@brichis\n\n post by JulianCross on Sep 23\n\n JulianCross\n\n @brichis This is a masterclass in forensic on-chain reconstruction. Your conclusion that “extra weeks bought decay, not liquidity” provides the exact mathematical proof the Token House needed to realize that blunt-force incentives are actively bleeding the treasury.\nHowever, as @MconnectDAO correctly points out, gross TVL delta is a highly manipulable metric. Identifying “unique and retained users” and tracking strict 30/60/90-day retained TVL requires deep-level wallet indexing.\nA sovereign DAO cannot rely on former council members running manual Python scripts post-mortem to audit its ecosystem growth. This requires permanent, automated, trustless infrastructure.\nThis is precisely why I architected the S10 Capital Efficiency Oracle. It takes the exact forensic rigor you applied manually here, and automates it—introducing Sybil-filtering, 30/60/90-day wallet stickiness mapping, and Capital Bleed circuit breakers into a live dashboard for active delegates.\nI invite you to review the operational mandate and cryptographic safeguards for that architecture here:\n[[RFC] Operational Mandate: S9 Impact Autopsy & S10 Capital Efficiency Oracle]\nThe manual audits have conclusively proven the disease. It is time to fund and deploy the automated cure.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Grants Council Season 7 Retrospective Report\n\n Grants Updates\n\n 1. What is your assessment of the impact KPIs that were set in your Budget Proposal at the start of the Season? Have you made progress towards, or achieved, these milestones or KPIs? If not, why?\nWe met 100% of the inter…\n\n read more\n\n 10\n\n 608\n\n Jun 2025\n\n S7 Grants Council Impact Analysis\n\n Governance Fund Missions\n\n season-7\n\n TL;DR:\n\nAn observational analysis of S7 Grants Council grants measured OP-normalized ROI using net Superchain TVL inflows between March 20 and June 12, 2025.\nROI benchmarks emerged at $1.58 (25th percentile), $3.67 (medi…\n\n read more\n\n 19\n\n 1.1k\n\n Dec 2025\n\n S8 Grants Council Impact Analysis\n\n Accountability 🗂️\n\n season-8\n\n The intention behind this impact analysis is to equip the Optimism Collective with preliminary results of the Grants Council’s S8 grants and help inform OP allocation decisions in S9. It was prepared by OSO in collabora…\n\n read more\n\n 0\n\n 169\n\n Jan 23\n\n May 2023 - Governance Call OP Rewards Analytics Update\n\n Accountability 🗂️\n\n Background\nThe data team at OP Labs has been working on tracking OP distributions across governance grants, partner funding, and other sources. We aim to share grant program performance and insights on a monthly basis in…\n\n read more\n\n 2\n\n 2.0k\n\n May 2023\n\n Season 8 Intent\n\n Intents\n\n season-8\n\n Season 8 Intent\nThis post outlines the main strategic goal of the Collective for 2H25 (Season 8 Intent) and highlights the contributions the Collective will support towards that goal. The audience for this post is all co…\n\n read more\n\n 20\n\n 2.1k\n\n Aug 2025","tokens":4617,"squid":"ink-governance","role":"Council Listener","at":1791267762731,"hash":"570e6ac2a12c4d9390e32f931e53481b471e0e12"}
{"url":"https://io.net/blog/io-cloud","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogIO CloudLatest By Topic (9)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsHow Leonardo.Ai Scaled from 14K to 19M Users While Cutting GPU Costs by 50%+ with io.netIO.NET Team / May 11, 2026See how Leonardo.Ai scaled from 14K to 19M users and cut GPU costs by over 50% using io.net's high-performance, affordable compute solution for generative AI.Parallel Computing: A Complete Guide to Models, Hardware, and Cloud ServicesIO.NET Team / Dec 16, 2025Solve compute bottlenecks with parallel computing. Compare models (parallel, concurrent, distributed), hardware, cloud costs, and best practices for performance gains.AI Data Centers: Optimizing Workloads and Infrastructure EfficiencyIO.NET Team / Oct 9, 2025Discover how AI data centers optimize workloads, boost efficiency, and power the future of artificial intelligence with advanced infrastructure.Decentralized Cloud Computing: A Complete Guide to the Future of AI InfrastructureIO.NET Team / Aug 31, 2025Learn how io.net evolved from trading infrastructure to decentralized GPU cloud computing, using distributed resources and blockchain for scalable AI.Cloud vs Edge Computing: Which Architecture Fits Your Needs?IO.NET Team / Jul 23, 2025Comparing cloud and edge computing architectures. Explaining when to use each model and how hybrid approaches optimize latency, scalability, and cost efficiency.How io.net Cut AI Research Costs 92.8% for Frodobots-UC Berkeley BreakthroughIO.NET Team / Jun 16, 2025How a Singapore robotics startup proved their navigation AI dataset was 25x larger than competitors—and cut compute costs by 92.8% with io.cloudio.net Turns One: Building the Intelligent Stack for AIIO.NET Team / May 12, 2025io.net celebrates its first anniversary, showcasing growth to 10,000+ GPUs across 138 regions and $13M revenue while democratizing AI infrastructure access.Your io.net Guide to GPU Cloud & Hardware InnovationIO.NET Team / Mar 16, 2025A comprehensive guide to launching and managing virtual machines and containers on IO.net's decentralized GPU cloud platform for cost-effective computing.Getting Started with io.cloud: Deploying and Managing Your Virtual MachinesIO.NET Team / Mar 9, 2025A comprehensive guide to launching and managing virtual machines and containers on io.net's decentralized GPU cloud platform for cost-effective computing.","tokens":663,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267769044,"hash":"af240e1e54c15e97ea9798139a264a0e13f93fb0"}
{"url":"https://gov.optimism.io/t/s7-grants-council-impact-analysis/10055","domain":"gov.optimism.io","title":"S7 Grants Council Impact Analysis - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n S7 Grants Council Impact Analysis \n\n Grants 🔴Governance Fund Missions\n\n season-7\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n Jun 2025\n\n 1 / 20\n\n Jun 2025\n\n Dec 2025\n\n post by system on Jun 24, 2025\n\n system\n\n TL;DR:\n\nAn observational analysis of S7 Grants Council grants measured OP-normalized ROI using net Superchain TVL inflows between March 20 and June 12, 2025.\nROI benchmarks emerged at $1.58 (25th percentile), $3.67 (median), and $9.39 (75th percentile) per OP, providing reference points for the evaluation of future grants.\nIn total, the net TVL inflows attributable to the TVL-focused grants amounted to $65.3M.\nObservational data suggests that grants generating both strong TVL growth and higher volume per TVL may be indicative of more sustainable net TVL inflows, though conclusions are preliminary.\n\nContext\nIn S7, the Collective rallied around the North Star metric of Superchain TVL growth, honing in on initiatives most likely to drive outsized impact towards this Intent. Consistent with this concerted effort, it’s crucial to ensure that all Collective programs—ranging from SuperStacks to Futarchy—are assessed in a unified manner using the same framework, paving the way for a universal, OP-normalized ROI analysis.Against this backdrop, we conducted an observational impact analysis of the grants the Grants Council made in S7, which concluded on June 12, 2025. The intended purpose of this post is to contour preliminary learnings to help inform OP allocation decisions in the S8 cycle.\nMethodology\nThe Foundation collaborated with OpenSource Observer to conduct an observational analysis of net TVL inflows between March 20 and June 12, 2025, which represented the defined incentive period for the issued grants. The analysis focused exclusively on grants that targeted Superchain TVL growth, excluding audit grants, which comprised 10.6% (~990K OP) of the total budget.\nFor the TVL measurement, we relied on the definition outlined in this glossary and leaned on DefiLlama as the primary data source. Furthermore, the TVL measurement was narrowed down to the chains within the Superchain that the grant intended to impact, as per incentive distribution plan outlined in the grant applications.\nIn terms of impact attribution, we tried to account for grant scope specificity and concurrently deployed co-incentives targeting the same chains. Specifically, we incorporated this logic into the TVL calculation by lowering the net TVL inflows attributable to the respective grants if other co-incentives were known—either because it was explicitly mentioned in the grant application or because it was public knowledge (e.g. inclusion in SuperStacks)—or if the grant aimed to only incentivize a small subset of the chain’s total market (e.g. a single stablecoin vault).\nFor example, Sake Finance had net inflows of $9M during the grant period, but this coincided with Soneium’s ACS campaign (which allocated a total of 70M ASTR to DeFi protocols) as well as SuperStacks (which allocated an additional 2M+ in DeFi incentives across the Superchain). Sake Finance was a participant in all three of these incentive programs. As a result, we apply a discount to the net TVL inflows that are attributable to the Grants Council program.\nWhile perfect TVL attribution is very hard to achieve, factoring in known confounding variables could help us better approximate reality. We erred on the side of providing more conservative estimates initially. Note that the Foundation applies exactly the same attribution logic to any internal analyses of Foundation-owned programs.\nKey Findings\nTo standardize TVL measurement, we aggregated results to establish baseline ROI benchmarks that can be used across seasons. At the aggregate level, S7 GC grants achieved $9.39 in net TVL inflows at the 75th percentile and $1.58 at the 25th percentile), offering reference points for future ROI evaluations.\nNote that these benchmarks should not be seen as an end-all-be-all measuring stick for future grants, but instead could serve as a proxy for evaluating future performance. For context, these results fall below benchmarks from previous growth grants (P75: $37.93; P50: $13.83; P25: $0.73), as determined by an analysis from the data team at OP Labs.\nIn total, the net TVL inflows attributable to the TVL-focused grants amounted to $65.3M. To put this into perspective, preliminary results from SuperStacks—a DeFi incentive campaign run by the Foundation—indicate that the program has brought in $73.4 in net TVL inflows per OP as of last week.\n\nS7 GC Grants\nNet TVL Inflows / OP At Program End (n = 17)\n\n75th percentile\n$9.39\n\n50th percentile (median)\n$3.67\n\n25th percentile\n$1.58\n\nWhen taking the project-level ROI distribution under the microscope, it becomes apparent that net TVL inflows per OP follow a power law dynamic, with Morpho’s World grant yielding $44 / OP in attributable net TVL inflows and Euler’s grant achieving $24 / OP, while most other grants hover in the $1-10 / OP range.\n1600×383 70.1 KB\nInterestingly, top performing grants like Aerodrome and Uniswap showed not only notable TVL inflows, which indicates supply-side growth, but also high daily volume per TVL ($0.58 - $0.63), commonly used to gauge demand-side activity. In contrast, projects with lower net TVL inflows / OP demonstrated lower daily volume per TVL ($0.004 - $0.40).\nTaken together, this might suggest that healthy demand-side activity in conjunction with significant supply-side traction might be indicative of successful DeFi ecosystem momentum. Note that this observation is based on a very small sample size and does by no means imply a causal relationship.\n1600×403 186 KB\nConclusion\nThis preliminary analysis offers a first pass at understanding how effectively S7 Grants Council allocations translated into Superchain TVL growth. While attribution remains inherently complex, the introduction of OP-normalized ROI benchmarks—$1.58, $3.67, and $9.39 at the 25th, 50th, and 75th percentiles—provides a foundational reference point for evaluating future grants.\nEarly signals suggest that projects demonstrating both strong net TVL inflows and high volume per TVL may contribute more meaningfully to ecosystem growth. These insights, though directional, can help inform more data-driven OP allocation decisions in S8.\nAppendix\n\nS7 Observational Impact Analysis Dashboard\nS6 Growth Grant Analysis Dashboard\n\n Season 7 Impact Analyses and Season 8 Budgeting\n\n Governance Update #11\n\n Grants Council Operating Budget for Season 8 and 9\n\n S7 ROI Summary & Learnings\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 6\n\n 3\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n post by GFXlabs on Jun 24, 2025\n\n GFXlabs\n\n Helpful report. Context down thread.\nSmall request: Either append future season reports onto this thread (perhaps lock it to avoid being too busy) or create a central locked post with links to each report for GC season and other programs as well? So it’s all in one place and easy to find as a historical document.\n\n post by Gonna.eth on Jun 25, 2025\n\n Gonna.eth\n\n At the beginning of Season 7, I was provided with a “S7 Metrics Definition” document by the Foundation. We published this on the Grants Council homepage so applicants could clearly understand what types of TVL growth would be prioritized.\nHowever, when comparing the final S7 Impact Analysis with the originally defined metrics, several inconsistencies emerge:\n\n3 out of the 4 declared verticals (Bridged Assets, Stablecoins, and Wrapped Assets) were completely missing from the report.\nAttribution discounting logic was introduced mid-season and applied retroactively without disclosure.\nA new metric, volume per TVL, was added after the fact as a proxy for “sustainable usage,” despite never being part of the guidance provided to applicants.\n\nA concrete example of the consequences of this misalignment is the grant awarded to Spark.\nTheir proposal explicitly aligned with all four verticals defined at the start of Season 7:\n\nSpark Savings and the Spark Liquidity Layer were deployed across multiple OP Chains (OP Mainnet, Unichain, and Ink), addressing Superchain-wide TVL.\nThey introduced yield-bearing stablecoin products (USDC, USDS, and sUSDS), directly supporting the growth of stablecoin TVL.\nsUSDS, as a wrapped asset representing interest-bearing USDS, fulfilled the wrapped asset TVL vertical.\nThe Liquidity Layer relied on canonical bridges and CCTP to move assets cross-chain, directly increasing bridged asset TVL.\n\nDespite this, Spark’s contribution is entirely absent from the Foundation’s final report.\nOne reason: DeFiLlama does not measure the TVL of Spark’s protocol-issued assets (such as sUSDS and USDS) due to filtering heuristics. Despite Spark having around 400 million dollars in assets available for swaps, as verifiable onchain via the contracts below, those flows are excluded by design.\n\nOptimism contract 1\nOptimism contract 2\nUnichain contract 1\nUnichain contract 2\n\nThe result is a grant that followed every published metric and successfully deployed onchain, but appears to have had zero impact with a 2M OP grant, not because it failed, but because the measurement method of a 3rd party app.\nI’m not asking for a retroactive correction of the analysis, I like the information provided, but given that Season 8 metrics for the Grants Council are already published, and that we’re expected to evaluate grants against those metrics, I need to understand how they’ll be measured before we open submissions.\nI urge those in charge of the analysis to lock in the measurement methodology by July 25th, so I can work with the newly elected GC reviewers during the final week of July to align our internal filtering and scoring process with what will actually be measured.\n\n post by thbialek on Jun 25, 2025\n\n thbialek\n\n Hey @Gonna.eth! Thanks for your thoughtful feedback! Providing some clarifications below:\n\n3 out of the 4 declared verticals (Bridged Assets, Stablecoins, and Wrapped Assets) were completely missing from the report.\n\nAs outlined in the TVL definition you shared, Superchain TVL was the North Star metric in S7, which encompasses the three mentioned verticals, as they are specific subsets of total Superchain TVL. As such, they are indeed included in the report.\n\nAttribution discounting logic was introduced mid-season and applied retroactively without disclosure.\n\nThe primary goal of this analysis was to approximate the TVL growth driven by the issued grants as closely as possible, helping the Collective make more informed token allocation decisions in future seasons. Importantly, the Foundation applies the same attribution logic to the programs it runs, which is a necessary pre-requisite for leveling the playing field and enabling accurate impact measurement across programs. Attribution is an inherently complex problem space and we’re always looking to refine existing approaches, so if you have any concrete suggestions for improvement, we’d love to hear them!\n\nA new metric, volume per TVL, was added after the fact as a proxy for “sustainable usage,” despite never being part of the guidance provided to applicants.\n\nIt is important to note that volume per TVL was not used to assess impact. Instead, it was included simply to give more color to the analysis, which might equip the Grants Council with additional tools when selecting grants in the future. Hence, volume per TVL is merely a minor, inconsequential foot note in the overall evaluation.\n\nDespite this, Spark’s contribution is entirely absent from the Foundation’s final report.\n\nFirst and foremost, the Spark grant is not missing from the analysis. In fact, it is included with a contribution of $20M in net TVL inflows on Unichain, OP Mainnet, and Ink. In line with industry standards, this measurement is based on DefiLlama’s TVL methodology, which centers around app-level deposits. Notably, this differs from L2Beat’s Total Value Secured (TVS) methodology, which aims to capture the total value of assets onchain, including those sitting idle in contracts and EOAs.\nThat being said, the $400M locked in the Spark PSM contracts comprises protocol-controlled assets that sit idle onchain, and therefore fall under the TVS rubric but are excluded from the TVL calculation. We reached out directly to the Spark team to confirm this methodological detail. Conversely, the $20M captured in the analysis reflects active deposits into existing apps.\n\nI urge those in charge of the analysis to lock in the measurement methodology by July 25th, so I can work with the newly elected GC reviewers during the final week of July to align our internal filtering and scoring process with what will actually be measured.\n\nThis is a valid point, and we’ll make sure to provide a detailed breakdown of the exact measurement methodology with the GC before July 25, so any ambiguity can be eliminated from the impact evaluation going forward.\nDisclaimer: I work for the Optimism Foundation, but views are my own.\n\n post by Gonna.eth on Jun 26, 2025\n\n Gonna.eth\n\nQuick clarification request. The report notes that SuperStacks has brought in $73.4M in net TVL inflows per OP. I wanted to confirm whether any part of that reported TVL includes Morpho deployments on Unichain.\nNo contracts were deployed for SuperStacks.\nThe contract being tracked by SuperStacks is the same one funded by the GC grant. All SuperStacks does in this case is track the contract and assign points to users who interact with it.\nIf Morpho’s TVL is included in the SuperStacks impact figure, I’d appreciate clarification on how that attribution is being handled.\nIs any of that TVL being attributed to SuperStacks in the $73.4M figure mentioned in the report?\nIf so, it seems like we’re misattributing TVL that only exists because of a GC grant. @thbialek\n\n post by GFXlabs on Jun 26, 2025\n\n GFXlabs\n\nAdditional items to make sure the TVL is being attributed correctly. SuperStacks overlaps with a number of other incentives programs\n\nUnichain’s own incentives\nWorld’s own incentives\nSoneium’s own incentives\nWorld received a GC grant\nMoonwell received a GC grant\nVelodrome received a GC grant\nSake Finance received a GC grant\n\nIn general, SuperStacks largely incentivized project-chain combinations that the GC selected or were already running major incentives campaigns. So let’s just make sure TVL growth is attributed by a standardized formula, like pro-rate contributions. We believe that a methodology was mentioned, so it would be great to see it worked through in an example.\nIt would also be useful to know if SuperStacks selected a project-chain combination to support before or after other incentives were announced. Identifying what to incentivize is a major use of time for the GC, so if SuperStacks will in the future continue to operate as a kind of follow-on matching pool of funds, for GC and chain incentives, that’s very useful for GC in S8 to be aware of to size grants appropriately.\n\n post by Gonna.eth on Jun 26, 2025\n\n Gonna.eth\n\nI would love to have access to this doc to learn the formulas if you don’t mind.\n\n post by thbialek on Jun 27, 2025\n\n thbialek\n\n Thanks for the great feedback! Sharing additional context to help address open questions:\n\nQuick clarification request. The report notes that SuperStacks has brought in $73.4M in net TVL inflows per OP. I wanted to confirm whether any part of that reported TVL includes Morpho deployments on Unichain.\n\nFor SuperStacks, the $73.4 in net TVL inflows per OP encompasses the 22 pools and vaults incentivized through the program. Notably, this also includes two Morpho vaults on Unichain, which were added to the program on June 16 for the final two weeks of the incentive period.\n\nNo contracts were deployed for SuperStacks.\nThe contract being tracked by SuperStacks is the same one funded by the GC grant. All SuperStacks does in this case is track the contract and assign points to users who interact with it.\n\nSuperStacks is a classic DeFi incentive program designed to accelerate the growth of interoperable assets across the Superchain. Hence, it contributes directly to Superchain TVL growth, similar to many other initiatives launched in S7. Contributions to this metric should remain agnostic to the form factor of a program—be it liquidity mining, points, or another mechanism—as long as it drives meaningful impact.\n\nIs any of that TVL being attributed to SuperStacks in the $73.4M figure mentioned in the report? If so, it seems like we’re misattributing TVL that only exists because of a GC grant. @thbialek\n\nAs mentioned before, the Foundation applies the same measurement framework to SuperStacks, including the attribution methodology. Just as portions of the TVL growth on Sake Finance are attributed to both the GC’s grant and Soneium’s ACS campaign, the TVL growth from co-incentivized Morpho vaults is also split accordingly.\n\nIn general, SuperStacks largely incentivized project-chain combinations that the GC selected or were already running major incentives campaigns. So let’s just make sure TVL growth is attributed by a standardized formula, like pro-rate contributions. We believe that a methodology was mentioned, so it would be great to see it worked through in an example.\n\nWe applied a standardized attribution adjustment to each project’s observed TVL growth. This adjustment prorated impact based on (1) the relative size of other incentive programs running concurrently with the GC grants, and (2) the proportion of targeted pools or vaults relative to the protocol’s total TVL on the targeted chain. The attribution percentages applied ranged from 1% to 50%.\n\nIt would also be useful to know if SuperStacks selected a project-chain combination to support before or after other incentives were announced. Identifying what to incentivize is a major use of time for the GC, so if SuperStacks will in the future continue to operate as a kind of follow-on matching pool of funds, for GC and chain incentives, that’s very useful for GC in S8 to be aware of to size grants appropriately.\n\nPre-existing co-incentives were not a strict requirement for SuperStacks, and assets were selected based on interop compatibility and DeFi ecosystem growth dynamics. This is valuable feedback, and we’ll aim to share more context with the GC for future Foundation-run incentive programs to better harness potential synergies and maximize the overall impact.\n\nI would love to have access to this doc to learn the formulas if you don’t mind.\n\nYou can find the dashboard in the Appendix section, which features a tab with the full code.\nDisclaimer: I work for the Optimism Foundation, but views are my own.\n\n post by GFXlabs on Jun 27, 2025\n\n GFXlabs\n\nCan you explain the formula for this attribution share? They don’t make a lot of sense on the surface.\nFor example, Spark would not be deployed if not for the Grants Council grant. Yet 50% of TVL is not attributed.\nThe same logic was applied to Fluid on Superchain, another project where the grant was to get the deployment. (In this case TVL is currently 0, so it doesn’t change the numbers, but illustrates the point)\nBut let’s set the Attributed variable aside for the moment and address some major problems with these calculations.\nIt’s clear upon closer inspection that the reported numbers are, in fact, completely unusable. The TVL change does not actually measure the correct beginning date (which will be different for each project). The OP spent is overstated.\nLet’s go through an example where this is obviously the case.\nBedrock was approved for a grant of 235k OP. Bedrock didn’t even begin to draft their application until March 26, clear intake until April 21, and be approved on until May 5. Zero OP was delivered until May 29. Yet we see here that TVL is being measured from March 20. The TVL changes need to be recalculated based upon some meaningful beginning date. Suggestions are OP delivery or announcement of campaign by the grantee.\nScreenshot 2025-06-27 at 2.18.45 PM2362×1350 127 KB\nNext, the OP attributed to this grant is being calculated on the entire grant rather than the OP actually delivered to the grantee. The denominator in dollars per OP needs to be recalculated.\nScreenshot 2025-06-27 at 2.43.12 PM2704×514 43.2 KB\nLet’s use the provided data, even though the Attributed variable of 15% could be debated, and the increase in TVL is clearly measuring the wrong period. Just to illustrate how impactful this distinction is.\n($8,520,000 TVL Increase * 0.15 Attributed) ÷ 235,000 OP Total Grant = $5.43 per OP\nThat’s very different from:\n($8,520,000 TVL Increase * 0.15 Attributed) ÷ 94,000 OP Actually Delivered = $13.59 per OP\nThis is very important, because undelivered OP has not yet been spent. In fact, many grantees may not hit their milestones and never get the second tranche of funding at all.\nAs you can see, all of these numbers need to be recalculated using the correct beginning dates and the amount of OP actually delivered.\nCC: @lavande who can help whomever did these numbers find relevant information, and to see if the SuperStacks, Futarchy, and other numbers likewise need recalculation\n\n post by mastermojo on Jul 1, 2025\n\n mastermojo\n\n Appreciate this deep dive by GFX labs, and makes total sense.\nAre these numbers going to be recalculated?\n\n post by lavande on Jul 7, 2025\n\n lavande\n\n GFXlabs\n\n The benefits of working with a third party to do analysis is that we remove the opportunity for bias or conflicts of interest in how the information is presented. The natural downside is that the third party may lack important context or nuance, which the programs being developed can provide.\nI believe the Foundation did offer to have the Grants Council review the analysis before it was published, but that offer was declined. In any case, I am happy to connect you/ the Grants Council with the report authors to ensure all relevant nuance/context is incorporated so we can arrive at the most accurate analysis possible. This is a feedback loop which we will need to strengthen in future Seasons.\n\n 16 days later\n\n post by elizaoak on Jul 23, 2025\n\n elizaoak\n\n TL; DR: Wanted to share here that similar to the above S7 Grants Council impact analysis, we also explored the effects of Futarchy grants on subsequent Superchain TVL. We find that while receiving a grant shows an apparent increase in Superchain TVL after 3 months, once we account for pre-intervention TVL these prior project-specific TVL trajectories seem to be what is driving subsequent TVL growth. Sample size constraints, treatment spillover effects, and confounding variables limit our ability to make definitive causal claims here, but these suggestive insights can pave the way for improving the design and analysis in future iterations.\n\nTo recap, our main Futarchy v1 analysis asked “Do projects selected via Futarchy see a greater increase in Superchain TVL than projects selected by the Optimism Grants Council?” We find that Futarchy did identify projects with a larger Superchain TVL increase after ~3 months compared to the Grants Council, thought the effect is driven by Futarchy selecting outlier Balancer & Beets which Grants Council narrowly ranked below the selection cutoff.\nA separate but related question is whether the observed increase in Superchain TVL among Futarchy-selected projects can be attributed to the grants allocated by Futarchy. Along these lines, the question presented to forecasters on Butter’s interface was “Estimate each project’s Superchain TVL increase after 84 days (Mar 20 - Jun 12 2025) if they receive 100K OP” (emphasis added).\nFor the analysis we used a regression discontinuity (RD) design which essentially lets us compare projects above and below the Top 5 grant selection cutoff. The Futarchy projects ranked #5 versus #6 had virtually the same expected Superchain TVL increase (a respective 0.41237 pTwap versus 0.41201 pTwap), though only the Top 5 received a 100K OP grant. If we consequently assume that projects right above and below the cutoff are otherwise similar, then treatment assignment (grant allocation) is as good as random near the cutoff.\nWe’re able to include daily TVL data for projects from December 20, 2024 - June 18, 2025 to increase the number of observations to 8,514. While the fundamental issue of comparing just 5 (treated) with 17 (untreated) heterogeneous projects remains, daily TVL data for each project improves the precision of the estimates within each project and controls for time-varying confounds. Using the date of actual grant deliveries as the intervention date (~2 weeks after the projects were selected due to KYC logistics), we see mixed evidence for the impact of Futarchy grant allocations on a project’s subsequent Superchain TVL.\nSpecifically, we find that receiving a grant shows an apparent increase in Superchain TVL after 3 months, once we account for prior project-specific TVL trajectories (using pre-intervention Superchain TVL data as far back as December 2024), the apparent statistically significant effect of receiving a 100K OP grant on subsequent Superchain TVL disappears, though the sign remains positive. For reference, the individual project trends are displayed below, with individual project paths showing varied responses to grant allocation, as well as varied baseline Superchain TVL trajectories.\ntvl_trajectories1832×1130 160 KB\nLet us know if there is anything else you’d like to see here! In an ongoing analysis with collaborators from the Uniswap Foundation and Emory Economics & Finance we’ll also explore a scaled measure of TVL to eliminate the influence of the market, and examine other indirect measures that Futarchy grants may have affected such as user retention and revenue.\n\n S7 ROI Summary & Learnings\n\n 25 days later\n\n post by GFXlabs on Aug 18, 2025\n\n GFXlabs\n\n Where are we in re-running these numbers? This thread and numbers are historical documentation, and we want to make sure it corrects some of the issues identified.\n\n post by ccerv1 on Aug 20, 2025\n\n ccerv1\n\n We re-ran the numbers using the dates and delivery amounts provided by the Grants Council.\nUpdated Results:\n\nROI benchmarks: $1.2 (25th percentile), $7.5 (median), and $21.2 (75th percentile) per OP\nNet TVL inflows attributable to TVL-focused grants: $60.2M\n\nMethodology\nThe ROI formula is:\n\nNet TVL inflows (7-day trailing TVL on end-of-program date [2025-06-12] minus 7-day trailing TVL on start-of-program date [2025-04-14] for all relevant chains/protocols)\n\nMultiplied by the attribution percentage (unique for each grant)\n\nDivided by total OP delivered (prior to 2025-06-12)\n\nFootnotes\n\nFor projects without delivered grants, we used the full grant amount as the denominator.\n\nThe program start date (2025-04-14) is the weighted average delivery date across all TVL grants, based on OP delivered. In the original analysis, we used 2025-03-20.\n\nOther Notes\n\nYou can find the dashboard at the same link as before.\nThe dashboard summary table also shows individualized timeframes (project-specific delivery date → end-of-program date). However, we ultimately decided to use a single timeframe across all projects for consistency. Individualized timeframes reduce comparability and don’t account for other timing effects (market moves, annualization, etc.). FWIW, using individualized timeframes would lower the program’s net TVL impact by ~30%, as only three projects show higher uplift on that basis.\nWe added a settings tab to the dashboard if anyone wants to do further analysis under different scenarios.\n\n post by GFXlabs on Aug 21, 2025\n\n GFXlabs\n\nWhy? If the grant hasn’t been delivered then there’s no effect to judge yet.\n\nWhy? Each grant has a different beginning date.\nThese two choices seem like they reintroduce the same problems that were identified in the initial calculation.\n\n post by ccerv1 on Aug 21, 2025\n\n ccerv1\n\n If we apply individualized timeframes to the 15 grants that had a portion of their OP delivered during the analysis period, then the results are as follows:\n\nNet TVL inflows attributable to TVL-focused grants: $42.7M\nROI benchmarks: $0.4 (25th percentile), $6.3 (median), and $12.4 (75th percentile) per OP\n\n 1 month later\n\n post by Kai on Sep 23, 2025\n\n Kai\n\n We would like to respectfully address some concerns regarding the recent S7 Grants Council Impact Analysis of Kyo Finance’s OP incentives. We believe there may have been some methodological considerations that, when adjusted, would present a more accurate picture of our project’s impact. We appreciate the Council’s thorough review process and hope to provide additional context for your consideration.\n1. Evaluation Window Considerations for OP Incentives\nOur incentive period: April 9th – June 5th, 2024\nTVL performance during this period: $26.4M → $44.73M (+$18.33M)\nAnalysis reference points: Pre-/Post-incentive values of $38.2M → $39.4M\nWe noticed that the evaluation window may not have fully captured our active incentive period. We believe comparing TVL metrics from before April 9th to after June 5th would provide a more comprehensive view of the campaign’s direct impact. We would be grateful if the Council could consider aligning the evaluation timeframe with our actual operational campaign period for a more accurate assessment.\n2. ACS Incentives Context\nCouncil’s approach: 50% of ACS incentives ($850K) attributed to Kyo\nAdditional context we’d like to share:\n\nAccording to the ACS allocation table, Kyo received 750,000 points, representing 2.83% of the total ACS distribution\n\nOther projects received larger allocations (e.g., Sake Finance 3.5M, Untitled Bank 2.5M)\n\nEven when considering actual deposited TVL proportions, Kyo held approximately $50M out of the chain’s total DeFi TVL of over $200M at the time\n\nUnlike lending protocols where most assets are eligible for incentives, DEX protocols contain numerous ineligible assets that cannot participate in incentive programs\n\nTaking these factors into account, we believe it would be more reasonable to estimate that less than 20% of ACS incentives were received through Kyo\n\nWe believe our ACS allocation was proportionate to our participation level\n\nWe would respectfully suggest that our ACS incentives were modest relative to other participants, and we hope this context might inform a more nuanced evaluation of external support factors.\n3. Revised ROI Calculation\nOP allocation: 250,000 OP\nTVL growth during active period: +$18.33M\nOur corrected ROI: ~$73.32 per OP\nWe acknowledge that this differs significantly from the reported $0.23/OP, and we believe this difference stems primarily from the evaluation window considerations mentioned above.\n4. Superstacks Initiative Context\nSuperstacks was designed as a flagship program to recognize key Superchain protocols. Despite being the #1 DEX on Soneium and making repeated requests for inclusion, we were not selected due to DEX slot limitations.\nKey considerations:\n\nSuperstacks inclusion provides user trust signals beyond direct incentive value\n\nThe program creates ecosystem positioning and network effects difficult to quantify in ROI calculations\n\nProtocols with Superstacks support have structural advantages in comparative evaluations\n\nWe continue to aspire for inclusion in future seasons and hope evaluations can account for these qualitative differences.\n5. Considerations for DEX Protocol Evaluation\nWe’d like to respectfully highlight some structural considerations that may affect DEX evaluations. LP-based protocols inherently carry impermanent loss risks that may affect TVL stability metrics, and liquidity provision differs fundamentally from single-asset deposits in terms of user behavior and risk profiles. We hope the Council might consider developing evaluation frameworks that account for these protocol-type differences.\nRequest for Reconsideration\nWe respectfully request the Council to consider:\n\nReviewing our evaluation window to align with our actual campaign period\n\nReassessing ACS incentive attribution based on actual allocation data\n\nConsidering structural factors affecting DEX protocol metrics\n\nAcknowledging varying program participation levels in comparative analysis\n\nWe believe these adjustments would present a more accurate picture of our contributions to the Soneium ecosystem and efficient use of OP incentives.\nOP Growth grants represent a critical element for ecosystem recognition among all protocols beyond Base, and serve as a key differentiator that distinguishes Superchain from other L2 ecosystems. These grants play a vital role in enabling important development roadmaps to flourish within the Superchain environment.\nWe respectfully encourage the Council to consider evaluation approaches beyond pure metrics. Relying solely on TVL metrics may inadvertently favor protocols that can easily scale through simple stablecoin deposits, potentially incentivizing the creation of large but undifferentiated clusters rather than fostering diverse, innovative protocol development.\nWe hope the Council will consider incorporating qualitative factors alongside quantitative metrics to support a more vibrant and differentiated Superchain ecosystem.\nThank you for your consideration and continued dedication to Superchain growth.\n\n post by GFXlabs on Sep 24, 2025\n\n GFXlabs\n\n Thank you for this detailed reply, @Kai.\n\nWe want to emphasize that the methodology and evaluation are not under the Grants Council’s control. This was a study commissioned by the Foundation:\n\nWe’ll leave it to the Foundation to reply, but didn’t want you to wait on an expected reply from the Grants Council since we don’t publish the Impact Analysis report.\n\n post by niche on Sep 24, 2025\n\n niche\n\n How do I get out of this email thread or is it being sent to me for a reason\n\n 3 months later\n\n post by ccerv1 on Dec 17, 2025\n\n ccerv1\n\n PSA-\nWe have updated the S7 dashboard to to reflect changes in the chains where Velodrome Finance ultimately deployed incentives, following consultation with the Grants Council (cc @Gonna.eth)\n\nOriginally proposed chains: Op Mainnet, Ink, Soneium, Mode, Metal, Lisk, Superseed.\nActually incentivized chains: Ink; Lisk; Mode; Soneium; Swellchain; Celo; Superseed; Metal; Unichain.\n\nAll TVL uplift and attributable ROI calculations have been revised to align with the final deployment set.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Grants Council Season 7 Retrospective Report\n\n Grants Updates\n\n 1. What is your assessment of the impact KPIs that were set in your Budget Proposal at the start of the Season? Have you made progress towards, or achieved, these milestones or KPIs? If not, why?\nWe met 100% of the inter…\n\n read more\n\n 10\n\n 608\n\n Jun 2025\n\n S8 Grants Council Impact Analysis\n\n Accountability 🗂️\n\n season-8\n\n The intention behind this impact analysis is to equip the Optimism Collective with preliminary results of the Grants Council’s S8 grants and help inform OP allocation decisions in S9. It was prepared by OSO in collabora…\n\n read more\n\n 0\n\n 169\n\n Jan 23\n\n Season 8 Growth Grants - TVL Impact Review\n\n ✨ General\n\n season-8\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me. \nI did …\n\n read more\n\n 2\n\n 166\n\n 13d\n\n Dashboard: TVL Growth of S7 Grantees\n\n ✨ General\n\n TVL Growth of S7 Grantees\nDisclosure: Please note that this is my personal opinion and does not necessarily reflect the views of the Grants Council. \nContext\nLate last year, I noticed that data analytics is highly valued…\n\n read more\n\n 3\n\n 247\n\n Jul 2025\n\n Season 8 Intent\n\n Intents\n\n season-8\n\n Season 8 Intent\nThis post outlines the main strategic goal of the Collective for 2H25 (Season 8 Intent) and highlights the contributions the Collective will support towards that goal. The audience for this post is all co…\n\n read more\n\n 20\n\n 2.1k\n\n Aug 2025","tokens":9037,"squid":"ink-governance","role":"Council Listener","at":1791267775928,"hash":"8b9acaf62513e81dd976a2f0c7f2d403b325125b"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract/11031/1","domain":"forum.openzeppelin.com","title":"Crowdsale contract - Support - OpenZeppelin Forum","text":"Crowdsale contract \n\n Support\n\n bep20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jun 2021\n\n 1 / 5\n\n Jun 2021\n\n Jun 2021\n\n post by quantumcoder on Jun 21, 2021\n\n quantumcoder\n\n From OpenZeppelin’s docs, I could get this script for minted crowdsales.\n\\\ncontract MyToken is ERC20, ERC20Mintable {\n // ... see \"Tokens\" for more info\n}\n\ncontract MyCrowdsale is Crowdsale, MintedCrowdsale {\n constructor(\n uint256 rate, // rate in TKNbits\n address payable wallet,\n IERC20 token\n )\n MintedCrowdsale()\n Crowdsale(rate, wallet, token)\n public\n {\n\n }\n}\n\ncontract MyCrowdsaleDeployer {\n constructor()\n public\n {\n // create a mintable token\n ERC20Mintable token = new MyToken();\n\n // create the crowdsale and tell it about the token\n Crowdsale crowdsale = new MyCrowdsale(\n 1, // rate, still in TKNbits\n msg.sender, // send Ether to the deployer\n token // the token\n );\n // transfer the minter role from this contract (the default)\n // to the crowdsale, so it can mint tokens\n token.addMinter(address(crowdsale));\n token.renounceMinter();\n }\n}\n\nI have several questions:\n1-What code should be put in // … see “Tokens” for more info\n2- How to deploy it on the blockchain for a bsc token using remix.ethereum.org?\n\n 3\n\n 2\n\n post by Skyge on Jun 21, 2021\n\n Skyge\n\nI think this depends on you, you can add some functions you want to achieve, such as you can add a function mint() to allow to mint new tokens after deploying. If you do not add anything, it is just a common ERC20 token, and you can have a look at this documentation to check which functions does it have. ERC 20 | OpenZeppelin Docs\n\nEmmmm, there is a tutorial that does not satisfy your original target, but I think it can help\nCreate an ERC20 using Remix, without writing Solidity | OpenZeppelin Community\n\n post by quantumcoder on Jun 21, 2021\n\n quantumcoder\n\nThanks a lot for your fast reply \nI have a basic knowledge of how to deploy smart contracts but on the crowdsale contract, I dont know how to grant it the permission to mint new tokens on the token contract. This is my question more precisely.\nAnd here:\nCrowdsale crowdsale = new MyCrowdsale(\n 1, // rate, still in TKNbits\n msg.sender, // send Ether to the deployer\n token // the token\n );\n\nI just need to provide the Token name or the token contract address?\nOtherwise how can it know what token it should interact with?\n\n post by Skyge on Jun 21, 2021\n\n post by quantumcoder on Jun 27, 2021\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Trying to Create the Crowdsale Contract\n\n Contracts\n\n erc20,crowdsale\n\n 7\n\n 2.3k\n\n Aug 2021\n\n Help with bep20 crowdsale token\n\n Contracts\n\n erc20,openzeppelin-contracts,crowdsale,token,test-helpers\n\n 3\n\n 6.4k\n\n Nov 2021","tokens":757,"squid":"ink-security_audits","role":"Sentinel","at":1791267775959,"hash":"7cc8864e79803631e9a1d2c717f6bd95357f43ae"}
{"url":"https://io.net/blog/leonardo-ai-case-study","domain":"io.net","title":"How Leonardo.Ai Scaled from 14K to 19M Users While Cutting GPU Costs by 50%+ with io.net","text":"Back To BlogHow Leonardo.Ai Scaled from 14K to 19M Users While Cutting GPU Costs by 50%+ with io.netIO.NET Team / May 11, 2026Try io.intelligenceGet StartedTry io.cloudDeploy GPUSuccess Storiesio.cloudAI Infrastructure & ComputeTable of ContentsKey ResultsThe Situation: Leonardo.Ai Before io.netLeonardo.Ai’s Strategic ProblemsThe Solution: io.netTechnical ImplementationThe Results: Accelerated Growth & Sustainable ScaleKey Performance InsightsStrategic Impact: Focus on Product, Not CostsThe Future of Creative AI InfraKey Results50%+ cost reduction on similar GPU workloads versus tier 1 cloud providers.Procurement time reduced from weeks/months to days for faster iteration.Infrastructure focus shifted from cost management to product innovation.Frontier access to test new GPU architectures faster than traditional vendors.“io.net's procurement flexibility let us quickly test new GPU architectures as they become available, keeping us at the forefront of AI innovation.” ~Peter Runham, Co-Founder & CTO, Leonardo.AiLeonardo.Ai, an AI-powered creative platform for generating dynamic visual content, is a global leader in the Generative AI space. Founded in December 2022, the platform provides millions of users with a powerful generative AI tool for producing visuals, from concept art and storyboards to production-ready assets and beyond. With its io.net partnership, Leonardo.Ai grew its user base dramatically from 14K to 19M users in a single year.To power real-time image generation models, their team needed rapid, compute-intensive growth for continuous access to high volume, cutting-edge NVIDIA GPUs. But this massive infrastructure build-out presented three primary challenges: cost efficiency, availability & latency, and procurement velocity.In this case study, we explore how Leonardo.Ai’s partnership with io.net helped tackle these challenges en route to the platform’s meteoric user growth.Spin up H100s in under 2 minutesNo contracts. No waitlists. Deploy bare metal, containers, or Ray clusters instantly across 138+ countries.Access io.cloudThe Situation: Leonardo.Ai Before io.net Like many other AI startups, as Leonardo.Ai scaled its platform and user base, its compute costs grew substantially. They knew they needed flexible and timely access to high-performance GPUs, without the premium pricing constraints that are typical of traditional Tier 1 cloud providers.Leonardo.Ai’s Strategic ProblemsAs briefly sketched out above, the Leonardo.Ai team quickly encountered three primary issues after launching their creative AI startup: Unsustainable Costs: The team’s rapid scaling meant compute expenses quickly consumed time and resources that would be better spent on product development and innovation.Availability & Latency: Leonardo.Ai needed reliable, low-latency access to hundreds of state-of-the-art GPUs to guarantee their growing user base a high-quality, real-time generative visual experience.Slow Procurement: Procurement timelines were taking weeks or even months, creating painful bottlenecks that directly impacted the team's ability to rapidly iterate their models.The team realized that any potential infrastructure partner would have to deliver hundreds of GPUs with maximum flexibility and minimal cost. This was the only way the platform could remain at the forefront of the hyper-competitive creative AI industry.The Solution: io.netLeonardo.Ai chose io.net to provide the flexible, high-performance GPU compute required for their demanding training and serving workloads. “We selected io.net primarily for their exceptional cost efficiency and procurement flexibility,” Runham explained. Cost & Reliability: io.net could provide GPUs at rates of less than half the on-demand price of competing providers, all while maintaining Leonardo.Ai’s production environment reliability.Procurement Flexibility: io.net’s flexibility was also crucial, as it gave the Leonardo.Ai team a variety of GPU options, depending on their specific needs. \"Their team's responsiveness, presenting multiple GPU options for any given requirement, gave us the flexibility to optimise our infrastructure spend without compromising on performance,” Runham added. What once took weeks or months to procure could now be provisioned in days. Leonardo.Ai now had another technical advantage in the competitive creative AI product space. Technical ImplementationTo integrate io.net’s GPU offerings, Leonardo.Ai used a direct SSH access model. This implementation involved adapting the platform’s existing infra orchestration and container control plane so that it could manage the new bare-metal instances provided by io.net. While some internal engineering efforts were needed to create workflows for provisioning, monitoring, and managing resources, this direct access approach enabled the team to scale quickly and confidently.Throughout the integration process, io.net provided consistent support, so that the Leonardo.Ai team could bring these new resources online and incorporate them as seamlessly as possible into their existing compute pipeline.The Results: Accelerated Growth & Sustainable ScaleLeonardo.Ai’s partnership with io.net delivered immediate results that were both measurable and strategic, validating the move to a more efficient, flexible, and decentralized compute infrastructure.Key Performance InsightsCost Efficiency: Leonardo.Ai achieved a reduction of over 50% on comparable GPU workloads, ensuring their aggressive growth remained economically viable.Procurement Velocity: Procurement times improved dramatically. What typically took weeks of negotiation and provisioning with traditional providers took just a couple days with io.net.Zero Downtime: io.net's rapid response to any hardware issues ensures minimal downtime, a critical factor for a platform serving millions of users globally.Strategic Impact: Focus on Product, Not CostsThe strategic impact of the partnership was profound. Leonardo.Ai’s infra planning has fundamentally changed, enabling the team to deploy AI service workloads with less concern about costs, and more strategic effort dedicated to product innovation. Procurement flexibility also means Leonardo.Ai can rapidly test new GPU architectures as they become available, keeping the team at the absolute cutting edge of the creative AI innovation curve.\"Being able to quickly onboard GPU compute and deploy our AI service workloads with less concern about cost allowed us to focus our efforts on our product instead of our cloud bill,” said Peter Runham, Co-Founder & CTO of Leonardo.Ai.300K+ GPUs ready when you areGlobal decentralized network across 138 countries. Scale training and inference workloads without centralized bottlenecks.Start buildingThe Future of Creative AI InfraFollowing its successful partnership with io.net, Leonardo.Ai was acquired by Canva in July 2024. The results of this collaboration show how high-growth, AI-native companies can leverage flexible compute solutions to maintain product superiority without the typical crippling cloud expenses of Tier 1 providers.With the Leonardo.Ai and io.net partnership firmly in place, the results clearly showcase  how high-growth, AI-native companies can leverage flexible compute solutions to maintain product superiority without the typical crippling cloud expenses of Tier 1 providers. Even better, all of this can be done with exceptional support, flexible procurement, and straightforward but diverse GPU offerings. \"When we need GPUs, they consistently provide multiple options, and their rapid response to any hardware issues minimises downtime,” Runham explained. “It's a no-nonsense approach that aligns perfectly with our needs.\"io.net is proud to power the next generation of creative AI applications like Leonardo.Ai, so they can keep delivering stunning visuals to millions and even billions worldwide, in reliable, affordable fashion.","tokens":1975,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267781702,"hash":"9e303e7a821be2c9c38f5f2c3e259f5797b9d65d"}
{"url":"https://aave.com/pro","domain":"aave.com","title":"Aave Pro | Aave","text":"Aave ProThe Future of DeFiAave V4 organizes lending into eleven markets, grouped under three Hubs. Each Hub plays a different role — pick the market that fits your strategy, or use several at once.Get StartedRisk Adjusted MarketsMarkets for every strategy.Aave V4 organizes lending into eleven markets, grouped under three Hubs. Each Hub plays a different role — pick the market that fits your strategy, or use several at once.General PurposeMainThe broadest market on Aave with competitive rates across a wide range of collateral.AAVEUSDCwETHwBTCLINK+4 MoreCollateral-IsolatedBluechipDeposit assets and borrow stablecoins against them, with the assurance that your collateral isn't lent out.wETHwstETHwBTCcbBTCStrategy-IsolatedEthena CorrelatedBorrow USDe against Ethena assets like USDe, sUSDe, and sUSDe Pendle tokens for looping.PT-sUSDePT-USDesUSDeUSDeHow It WorksFrom idle assets to working capital.Deposit what you hold, borrow what you need, spend it however you want.Market OpportunitiesForexCoreCF 85%0.00% APYBluechipPrimeCF 65%0.00% APYEthena CorrelatedPlusNot eligible as collateral0.00% APYEthenaPlusNot eligible as collateral0.00% APYChoose a market and deposit your assetsDeposit any supported asset into a market. Your supply earns yield and can be enabled as collateral.Borrow0$0.00Available: 0Borrow APY0.00%Borrow against your deposited collateralBorrow against your collateral. Your rate adapts to its quality — better collateral, lower cost.$0.00KBalancePosition APY0.00%Total earnings$0.00Health factor0Risk premium0.00%Monitor your position.Use your borrowed assets however you want — off-ramp to fiat, send onchain, or loop into another position.Manage Your PositionThe smartest way to borrow onchain.Risk-adjusted rates, smarter liquidations, and modular markets.Risk PremiumsYour borrow rate adapts to your collateral quality. Better collateral, lower costs, calculated automatically.Smarter LiquidationsAave Pro restores your position to a target health factor, liquidating only what's needed.MainMainnet0$0.00K0% APYManage multiple positions in isolationIndependent risk parameters, rate curves, and collateral rules per market. All governance-tuned.0.0+0.00%Health FactorReal-Time Health FactorMonitor position health across every market in real time. Each market maintains its own health factor. Always know where you stand.Coinbase Tokenized Stocks on BaseThe world’s largest stocks, live on Aave.Explore tokenized stocks, borrow against your holdings, or earn by supplying liquidity.Browse StocksSwapRebalance in one step.Swap collateral, switch debt, or repay with your supply. Gasless, via signed intents.Sell3,834 $3,834.00Balance: 40,022.09  |  Receive1.88672 $3,830.05Token SwapSwap any supported token directly within the protocol.\nNo external DEX needed.USDC → ETH in one gasless transactionCollateral SwapComing soonConvert supplied assets to a different token without withdrawing.Debt SwapComing soonSwitch borrowed debt from one token to another in a single step.Repay with CollateralComing soonUse any supplied position to pay down debt directly, no external swaps needed.All swaps via signed intents, no gasMEV protection and optimal pricing via CoW Protocol.All swaps via signed intents, no gas•MEV protection and optimal pricing via CoW Protocol.ArchitectureBuilt on Aave V4.Unified liquidity, modular risk, smarter execution.Learn MoreUnified LiquidityDeep liquidity per Hub, with governed credit lines connecting them.Modular MarketsEach market has its own risk rules, rate curves, and solvency boundary.User Risk PremiumBorrow costs adjust based on collateral quality. Better collateral, lower rates.Target Health LiquidationsRestore to a target health factor — not a fixed close. Only liquidate what's needed.Share-Based AccountingHold shares that appreciate over time instead of rebasing balances. optimized and tax-efficient.FAQsAave Pro is the full-featured lending and borrowing interface for Aave's modular markets. Earn yield, borrow against your assets, and manage positions across multiple risk profiles, all in one place.A market is where you deposit and borrow. Each market has its own collateral rules, borrowable assets, rates, and health factor. Main is the general-purpose market. Others — like Lido, Gold, and Forex — are specialized for specific strategies.It depends on what you want to do. Main supports the broadest set of assets and is the default for most users. Specialized markets offer optimized parameters for specific strategies — like leveraging wstETH against ETH (Lido) or borrowing stablecoins against gold (Gold). You can use multiple markets at the same time.Those are Hubs — the liquidity layer underneath markets. Core Hub is where Main and most other markets live. Prime Hub is for suppliers who want non-borrowable blue-chip collateral. Plus Hub supports strategy-specific activity. You don't choose a Hub directly — you choose a market, and it's connected to a Hub.No, each market has its own health factor. If you deposit into Main and Gold, those are two separate positions with separate health factors. Activity in one market doesn't affect the other.Aave ProManage your positions, explore opportunities, and access deep liquidity across Aave V4.Get Started","tokens":1312,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267790174,"hash":"c0a2fd6463edd42b1c42eb9960f49b942cfb37f2"}
{"url":"https://io.net/blog/success-stories","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogSuccess StoriesLatest By Topic (5)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsHow KayOS Multiplied Its Developer Power by 5x with io.netIO.NET Team / Jun 22, 2026KayOS, an AI startup, achieved 5x developer power with io.net. Learn how their 2-person team cut compute costs by 60% ($2.5k to $1k/month) using io.intelligence.How Wondera Scaled AI Music Creation to 200,000 Users with io.netIO.NET Team / Jun 1, 2026Wondera cut AI training costs 75% and scaled to 200,000 users in 4 months using io.net's decentralized GPU infrastructure, launching 3 months ahead of schedule.How Leonardo.Ai Scaled from 14K to 19M Users While Cutting GPU Costs by 50%+ with io.netIO.NET Team / May 11, 2026See how Leonardo.Ai scaled from 14K to 19M users and cut GPU costs by over 50% using io.net's high-performance, affordable compute solution for generative AI.How Vistara Labs’ Platform Built 5,600 Apps in 2 Months with io.netIO.NET Team / May 4, 2026Vistara Labs used io.net to scale its Zaara AI platform, building 5,600 apps in two months while cutting compute costs by 3x and achieving zero infrastructure failures.How io.net Cut AI Research Costs 92.8% for Frodobots-UC Berkeley BreakthroughIO.NET Team / Jun 16, 2025How a Singapore robotics startup proved their navigation AI dataset was 25x larger than competitors—and cut compute costs by 92.8% with io.cloud","tokens":421,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267791792,"hash":"fb0bec5da83aef64e7f2ea1ee6bbadcf4b0e56d2"}
{"url":"https://docs.openzeppelin.com/contracts/4.x/api/token/erc20","domain":"docs.openzeppelin.com","title":"ERC20 | OpenZeppelin Docs","text":"ERC20Smart contract ERC20 utilities and implementationsOutdated VersionYou're viewing an older version (v4.x) The latest documentation is available for the current version. Click here to visit latest version.Open in ClaudeThis set of interfaces, contracts, and utilities are all related to the ERC20 Token Standard.\nFor an overview of ERC20 tokens and a walk through on how to create a token contract read our ERC20 guide.\nThere are a few core contracts that implement the behavior specified in the EIP:\n\nIERC20: the interface all ERC20 implementations should conform to.\nIERC20Metadata: the extended ERC20 interface including the name, symbol and decimals functions.\nERC20: the implementation of the ERC20 interface, including the name, symbol and decimals optional standard extension to the base interface.\n\nAdditionally there are multiple custom extensions, including:\n\nERC20Permit: gasless approval of tokens (standardized as ERC2612).\nERC20Burnable: destruction of own tokens.\nERC20Capped: enforcement of a cap to the total supply when minting tokens.\nERC20Pausable: ability to pause token transfers.\nERC20Snapshot: efficient storage of past token balances to be later queried at any point in time.\nERC20FlashMint: token level support for flash loans through the minting and burning of ephemeral tokens (standardized as ERC3156).\nERC20Votes: support for voting and vote delegation.\nERC20VotesComp: support for voting and vote delegation (compatible with Compound’s token, with uint96 restrictions).\nERC20Wrapper: wrapper to create an ERC20 backed by another ERC20, with deposit and withdraw methods. Useful in conjunction with ERC20Votes.\nERC4626: tokenized vault that manages shares (represented as ERC20) that are backed by assets (another ERC20).\n\nFinally, there are some utilities to interact with ERC20 contracts in various ways.\n\nSafeERC20: a wrapper around the interface that eliminates the need to handle boolean return values.\nTokenTimelock: hold tokens for a beneficiary until a specified time.\n\nThis core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC20 (such as _mint) and expose them as external functions in the way they prefer. On the other hand, ERC20 Presets (such as ERC20PresetMinterPauser) are designed using opinionated patterns to provide developers with ready to use, deployable contracts.\nCore\nIERC20\nIERC20Metadata\nERC20\nExtensions\nIERC20Permit\nERC20Permit\nERC20Burnable\nERC20Capped\nERC20Pausable\nERC20Snapshot\nERC20Votes\nERC20VotesComp\nERC20Wrapper\nERC20FlashMint\nERC4626\nPresets\nThese contracts are preconfigured combinations of the above features. They can be used through inheritance or as models to copy and paste their source code.\nERC20PresetMinterPauser\nERC20PresetFixedSupply\nUtilities\nSafeERC20\nTokenTimelock\n\nERC20\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nImplementation of the IERC20 interface.\nThis implementation is agnostic to the way tokens are created. This means\nthat a supply mechanism has to be added in a derived contract using ERC1155._mint.\nFor a generic mechanism see ERC20PresetMinterPauser.\nTIP: For a detailed writeup see our guide\nHow\nto implement supply mechanisms.\nThe default value of ERC20.decimals is 18. To change this, you should override\nthis function so it returns a different value.\nWe have followed general OpenZeppelin Contracts guidelines: functions revert\ninstead returning false on failure. This behavior is nonetheless\nconventional and does not conflict with the expectations of ERC20\napplications.\nAdditionally, an IERC20.Approval event is emitted on calls to ERC20.transferFrom.\nThis allows applications to reconstruct the allowance for all accounts just\nby listening to said events. Other implementations of the EIP may not emit\nthese events, as it isn't required by the specification.\nFinally, the non-standard ERC20.decreaseAllowance and ERC20.increaseAllowance\nfunctions have been added to mitigate the well-known issues around setting\nallowances. See IERC20.approve.\nFunctions\nconstructor(name_, symbol_)\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsIERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nconstructor(string name_, string symbol_)public#Sets the values for Governor.name and ERC20.symbol.All two of these values are immutable: they can only be set once during\nconstruction.\n\nname() → stringpublic#Returns the name of the token.\n\nsymbol() → stringpublic#Returns the symbol of the token, usually a shorter version of the\nname.\n\ndecimals() → uint8public#Returns the number of decimals used to get its user representation.\nFor example, if decimals equals 2, a balance of 505 tokens should\nbe displayed to a user as 5.05 (505 / 10 ** 2).Tokens usually opt for a value of 18, imitating the relationship between\nEther and Wei. This is the default value returned by this function, unless\nit's overridden.NOTE: This information is only used for display purposes: it in\nno way affects any of the arithmetic of the contract, including\nIERC20.balanceOf and IERC20.transfer.\n\ntotalSupply() → uint256public#See IERC20.totalSupply.\n\nbalanceOf(address account) → uint256public#See IERC20.balanceOf.\n\ntransfer(address to, uint256 amount) → boolpublic#See IERC20.transfer.Requirements:\nto cannot be the zero address.\nthe caller must have a balance of at least amount.\n\nallowance(address owner, address spender) → uint256public#See IERC20.allowance.\n\napprove(address spender, uint256 amount) → boolpublic#See IERC20.approve.NOTE: If amount is the maximum uint256, the allowance is not updated on\ntransferFrom. This is semantically equivalent to an infinite approval.Requirements:\nspender cannot be the zero address.\n\ntransferFrom(address from, address to, uint256 amount) → boolpublic#See IERC20.transferFrom.Emits an IERC20.Approval event indicating the updated allowance. This is not\nrequired by the EIP. See the note at the beginning of ERC20.NOTE: Does not update the allowance if the current allowance\nis the maximum uint256.Requirements:\nfrom and to cannot be the zero address.\nfrom must have a balance of at least amount.\nthe caller must have allowance for from's tokens of at least\namount.\n\nincreaseAllowance(address spender, uint256 addedValue) → boolpublic#Atomically increases the allowance granted to spender by the caller.This is an alternative to ERC20.approve that can be used as a mitigation for\nproblems described in IERC20.approve.Emits an IERC20.Approval event indicating the updated allowance.Requirements:\nspender cannot be the zero address.\n\ndecreaseAllowance(address spender, uint256 subtractedValue) → boolpublic#Atomically decreases the allowance granted to spender by the caller.This is an alternative to ERC20.approve that can be used as a mitigation for\nproblems described in IERC20.approve.Emits an IERC20.Approval event indicating the updated allowance.Requirements:\nspender cannot be the zero address.\nspender must have allowance for the caller of at least\nsubtractedValue.\n\n_transfer(address from, address to, uint256 amount)internal#Moves amount of tokens from from to to.This internal function is equivalent to ERC20.transfer, and can be used to\ne.g. implement automatic token fees, slashing mechanisms, etc.Emits a IERC20.Transfer event.Requirements:\nfrom cannot be the zero address.\nto cannot be the zero address.\nfrom must have a balance of at least amount.\n\n_mint(address account, uint256 amount)internal#Creates amount tokens and assigns them to account, increasing\nthe total supply.Emits a IERC20.Transfer event with from set to the zero address.Requirements:\naccount cannot be the zero address.\n\n_burn(address account, uint256 amount)internal#Destroys amount tokens from account, reducing the\ntotal supply.Emits a IERC20.Transfer event with to set to the zero address.Requirements:\naccount cannot be the zero address.\naccount must have at least amount tokens.\n\n_approve(address owner, address spender, uint256 amount)internal#Sets amount as the allowance of spender over the owner s tokens.This internal function is equivalent to approve, and can be used to\ne.g. set automatic allowances for certain subsystems, etc.Emits an IERC20.Approval event.Requirements:\nowner cannot be the zero address.\nspender cannot be the zero address.\n\n_spendAllowance(address owner, address spender, uint256 amount)internal#Updates owner s allowance for spender based on spent amount.Does not update the allowance amount in case of infinite allowance.\nRevert if not enough allowance is available.Might emit an IERC20.Approval event.\n\n_beforeTokenTransfer(address from, address to, uint256 amount)internal#Hook that is called before any transfer of tokens. This includes\nminting and burning.Calling conditions:\nwhen from and to are both non-zero, amount of from's tokens\nwill be transferred to to.\nwhen from is zero, amount tokens will be minted for to.\nwhen to is zero, amount of from's tokens will be burned.\nfrom and to are never both zero.\nTo learn more about hooks, head to xref:ROOT:extending-contracts#using-hooks[Using Hooks].\n\n_afterTokenTransfer(address from, address to, uint256 amount)internal#Hook that is called after any transfer of tokens. This includes\nminting and burning.Calling conditions:\nwhen from and to are both non-zero, amount of from's tokens\nhas been transferred to to.\nwhen from is zero, amount tokens have been minted for to.\nwhen to is zero, amount of from's tokens have been burned.\nfrom and to are never both zero.\nTo learn more about hooks, head to xref:ROOT:extending-contracts#using-hooks[Using Hooks].\n\nIERC20\nimport \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\nInterface of the ERC20 standard as defined in the EIP.\nFunctions\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\n\nEvents\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\ntotalSupply() → uint256external#Returns the amount of tokens in existence.\n\nbalanceOf(address account) → uint256external#Returns the amount of tokens owned by account.\n\ntransfer(address to, uint256 amount) → boolexternal#Moves amount tokens from the caller's account to to.Returns a boolean value indicating whether the operation succeeded.Emits a IERC20.Transfer event.\n\nallowance(address owner, address spender) → uint256external#Returns the remaining number of tokens that spender will be\nallowed to spend on behalf of owner through ERC20.transferFrom. This is\nzero by default.This value changes when ERC20.approve or ERC20.transferFrom are called.\n\napprove(address spender, uint256 amount) → boolexternal#Sets amount as the allowance of spender over the caller's tokens.Returns a boolean value indicating whether the operation succeeded.Beware that changing an allowance with this method brings the risk\nthat someone may use both the old and the new allowance by unfortunate\ntransaction ordering. One possible solution to mitigate this race\ncondition is to first reduce the spender's allowance to 0 and set the\ndesired value afterwards:\nhttps://github.com/ethereum/EIPs/issues/20#issuecomment-263524729Emits an IERC20.Approval event.\n\ntransferFrom(address from, address to, uint256 amount) → boolexternal#Moves amount tokens from from to to using the\nallowance mechanism. amount is then deducted from the caller's\nallowance.Returns a boolean value indicating whether the operation succeeded.Emits a IERC20.Transfer event.\n\nTransfer(address indexed from, address indexed to, uint256 value)event#Emitted when value tokens are moved from one account (from) to\nanother (to).Note that value may be zero.\n\nApproval(address indexed owner, address indexed spender, uint256 value)event#Emitted when the allowance of a spender for an owner is set by\na call to ERC20.approve. value is the new allowance.\n\nERC20Burnable\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol\";\nExtension of ERC20 that allows token holders to destroy both their own\ntokens and those that they have an allowance for, in a way that can be\nrecognized off-chain (via event analysis).\nFunctions\nburn(amount)\nburnFrom(account, amount)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nburn(uint256 amount)public#Destroys amount tokens from the caller.See ERC20._burn.\n\nburnFrom(address account, uint256 amount)public#Destroys amount tokens from account, deducting from the caller's\nallowance.See ERC20._burn and ERC20.allowance.Requirements:\nthe caller must have allowance for accounts's tokens of at least\namount.\n\nERC20Capped\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Capped.sol\";\nExtension of ERC20 that adds a cap to the supply of tokens.\nFunctions\nconstructor(cap_)\ncap()\n_mint(account, amount)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nconstructor(uint256 cap_)internal#Sets the value of the cap. This value is immutable, it can only be\nset once during construction.\n\ncap() → uint256public#Returns the cap on the token's total supply.\n\n_mint(address account, uint256 amount)internal#See ERC20._mint.\n\nERC20FlashMint\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20FlashMint.sol\";\nImplementation of the ERC3156 Flash loans extension, as defined in\nERC-3156.\nAdds the IERC3156FlashLender.flashLoan method, which provides flash loan support at the token\nlevel. By default there is no fee, but this can be changed by overriding IERC3156FlashLender.flashFee.\nAvailable since v4.1.\nFunctions\nmaxFlashLoan(token)\nflashFee(token, amount)\n_flashFee(token, amount)\n_flashFeeReceiver()\nflashLoan(receiver, token, amount, data)\nIERC3156FlashLenderERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsIERC3156FlashLenderERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nmaxFlashLoan(address token) → uint256public#Returns the maximum amount of tokens available for loan.\n\nflashFee(address token, uint256 amount) → uint256public#Returns the fee applied when doing flash loans. This function calls\nthe ERC20FlashMint._flashFee function which returns the fee applied when doing flash\nloans.\n\n_flashFee(address token, uint256 amount) → uint256internal#Returns the fee applied when doing flash loans. By default this\nimplementation has 0 fees. This function can be overloaded to make\nthe flash loan mechanism deflationary.\n\n_flashFeeReceiver() → addressinternal#Returns the receiver address of the flash fee. By default this\nimplementation returns the address(0) which means the fee amount will be burnt.\nThis function can be overloaded to change the fee receiver.\n\nflashLoan(contract IERC3156FlashBorrower receiver, address token, uint256 amount, bytes data) → boolpublic#Performs a flash loan. New tokens are minted and sent to the\nreceiver, who is required to implement the IERC3156FlashBorrower\ninterface. By the end of the flash loan, the receiver is expected to own\namount + fee tokens and have them approved back to the token contract itself so\nthey can be burned.\n\nERC20Pausable\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Pausable.sol\";\nERC20 token with pausable token transfers, minting and burning.\nUseful for scenarios such as preventing trades until the end of an evaluation\nperiod, or having an emergency switch for freezing all token transfers in the\nevent of a large bug.\nThis contract does not include public pause and unpause functions. In\naddition to inheriting this contract, you must define both functions, invoking the\nPausable._pause and Pausable._unpause internal functions, with appropriate\naccess control, e.g. using AccessControl or Ownable. Not doing so will\nmake the contract unpausable.\nFunctions\n_beforeTokenTransfer(from, to, amount)\nPausable\npaused()\n_requireNotPaused()\n_requirePaused()\n_pause()\n_unpause()\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsPausable\nPaused(account)\nUnpaused(account)\nERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\n_beforeTokenTransfer(address from, address to, uint256 amount)internal#See ERC20._beforeTokenTransfer.Requirements:\nthe contract must not be paused.\n\nERC20Permit\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol\";\nImplementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in\nEIP-2612.\nAdds the ERC20Permit.permit method, which can be used to change an account's ERC20 allowance (see IERC20.allowance) by\npresenting a message signed by the account. By not relying on [IERC20.approve](#IERC20-approve-address-uint256-), the token holder account doesn't\nneed to send a transaction, and thus is not required to hold Ether at all.\nAvailable since v3.4.\nFunctions\nconstructor(name)\npermit(owner, spender, value, deadline, v, r, s)\nnonces(owner)\nDOMAIN_SEPARATOR()\n_useNonce(owner)\nEIP712\n_domainSeparatorV4()\n_hashTypedDataV4(structHash)\neip712Domain()\nIERC5267IERC20PermitERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsEIP712IERC5267\nEIP712DomainChanged()\nIERC20PermitERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nconstructor(string name)internal#Initializes the EIP712 domain separator using the name parameter, and setting version to \"1\".It's a good idea to use the same name that is defined as the ERC20 token name.\n\npermit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)public#Sets value as the allowance of spender over owner's tokens,\ngiven owner's signed approval.The same issues IERC20.approve has related to transaction\nordering also apply here.Emits an IERC20.Approval event.Requirements:\nspender cannot be the zero address.\ndeadline must be a timestamp in the future.\nv, r and s must be a valid secp256k1 signature from owner\nover the EIP712-formatted function arguments.\nthe signature must use owner's current nonce (see Votes.nonces).\nFor more information on the signature format, see the\nrelevant EIP\nsection.CAUTION: See Security Considerations above.\n\nnonces(address owner) → uint256public#Returns the current nonce for owner. This value must be\nincluded whenever a signature is generated for ERC20Permit.permit.Every successful call to ERC20Permit.permit increases owner's nonce by one. This\nprevents a signature from being used multiple times.\n\nDOMAIN_SEPARATOR() → bytes32external#Returns the domain separator used in the encoding of the signature for ERC20Permit.permit, as defined by EIP712.\n\n_useNonce(address owner) → uint256 currentinternal#\"Consume a nonce\": return the current value and increment.Available since v4.1.\n\nERC20Snapshot\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Snapshot.sol\";\nThis contract extends an ERC20 token with a snapshot mechanism. When a snapshot is created, the balances and\ntotal supply at the time are recorded for later access.\nThis can be used to safely create mechanisms based on token balances such as trustless dividends or weighted voting.\nIn naive implementations it's possible to perform a \"double spend\" attack by reusing the same balance from different\naccounts. By using snapshots to calculate dividends or voting power, those attacks no longer apply. It can also be\nused to create an efficient ERC20 forking mechanism.\nSnapshots are created by the internal ERC20Snapshot._snapshot function, which will emit the ERC20Snapshot.Snapshot event and return a\nsnapshot id. To get the total supply at the time of a snapshot, call the function ERC20Snapshot.totalSupplyAt with the snapshot\nid. To get the balance of an account at the time of a snapshot, call the ERC20Snapshot.balanceOfAt function with the snapshot id\nand the account address.\nNOTE: Snapshot policy can be customized by overriding the ERC20Snapshot._getCurrentSnapshotId method. For example, having it\nreturn block.number will trigger the creation of snapshot at the beginning of each new block. When overriding this\nfunction, be careful about the monotonicity of its result. Non-monotonic snapshot ids will break the contract.\nImplementing snapshots for every block using this method will incur significant gas costs. For a gas-efficient\nalternative consider ERC20Votes.\n==== Gas Costs\nSnapshots are efficient. Snapshot creation is O(1). Retrieval of balances or total supply from a snapshot is O(log\nn) in the number of snapshots that have been created, although n for a specific account will generally be much\nsmaller since identical balances in subsequent snapshots are stored as a single entry.\nThere is a constant overhead for normal ERC20 transfers due to the additional snapshot bookkeeping. This overhead is\nonly significant for the first transfer that immediately follows a snapshot for a particular account. Subsequent\ntransfers will have normal cost until the next snapshot, and so on.\nFunctions\n_snapshot()\n_getCurrentSnapshotId()\nbalanceOfAt(account, snapshotId)\ntotalSupplyAt(snapshotId)\n_beforeTokenTransfer(from, to, amount)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEvents\nSnapshot(id)\nERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\n_snapshot() → uint256internal#Creates a new snapshot and returns its snapshot id.Emits a ERC20Snapshot.Snapshot event that contains the same id.ERC20Snapshot._snapshot is internal and you have to decide how to expose it externally. Its usage may be restricted to a\nset of accounts, for example using AccessControl, or it may be open to the public.[WARNING]While an open way of calling ERC20Snapshot._snapshot is required for certain trust minimization mechanisms such as forking,\nyou must consider that it can potentially be used by attackers in two ways.First, it can be used to increase the cost of retrieval of values from snapshots, although it will grow\nlogarithmically thus rendering this attack ineffective in the long term. Second, it can be used to target\nspecific accounts and increase the cost of ERC20 transfers for them, in the ways specified in the Gas Costs\nsection above.We haven't measured the actual numbers; if this is something you're interested in please reach out to us.\n\n_getCurrentSnapshotId() → uint256internal#Get the current snapshotId\n\nbalanceOfAt(address account, uint256 snapshotId) → uint256public#Retrieves the balance of account at the time snapshotId was created.\n\ntotalSupplyAt(uint256 snapshotId) → uint256public#Retrieves the total supply at the time snapshotId was created.\n\n_beforeTokenTransfer(address from, address to, uint256 amount)internal#Hook that is called before any transfer of tokens. This includes\nminting and burning.Calling conditions:\nwhen from and to are both non-zero, amount of from's tokens\nwill be transferred to to.\nwhen from is zero, amount tokens will be minted for to.\nwhen to is zero, amount of from's tokens will be burned.\nfrom and to are never both zero.\nTo learn more about hooks, head to xref:ROOT:extending-contracts#using-hooks[Using Hooks].\n\nSnapshot(uint256 id)event#Emitted by ERC20Snapshot._snapshot when a snapshot identified by id is created.\n\nERC20Votes\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Votes.sol\";\nExtension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's,\nand supports token supply up to 2^224^ - 1, while COMP is limited to 2^96^ - 1.\nNOTE: If exact COMP compatibility is required, use the ERC20VotesComp variant of this module.\nThis extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either\nby calling the IVotes.delegate function directly, or by providing a signature to be used with IVotes.delegateBySig. Voting\npower can be queried through the public accessors Governor.getVotes and IVotes.getPastVotes.\nBy default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it\nrequires users to delegate to themselves in order to activate checkpoints and have their voting power tracked.\nAvailable since v4.2.\nFunctions\nclock()\nCLOCK_MODE()\ncheckpoints(account, pos)\nnumCheckpoints(account)\ndelegates(account)\ngetVotes(account)\ngetPastVotes(account, timepoint)\ngetPastTotalSupply(timepoint)\ndelegate(delegatee)\ndelegateBySig(delegatee, nonce, expiry, v, r, s)\n_maxSupply()\n_mint(account, amount)\n_burn(account, amount)\n_afterTokenTransfer(from, to, amount)\n_delegate(delegator, delegatee)\nIERC5805IVotesIERC6372ERC20Permit\npermit(owner, spender, value, deadline, v, r, s)\nnonces(owner)\nDOMAIN_SEPARATOR()\n_useNonce(owner)\nEIP712\n_domainSeparatorV4()\n_hashTypedDataV4(structHash)\neip712Domain()\nIERC5267IERC20PermitERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsIERC5805IVotes\nDelegateChanged(delegator, fromDelegate, toDelegate)\nDelegateVotesChanged(delegate, previousBalance, newBalance)\nIERC6372ERC20PermitEIP712IERC5267\nEIP712DomainChanged()\nIERC20PermitERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nclock() → uint48public#Clock used for flagging checkpoints. Can be overridden to implement timestamp based checkpoints (and voting).\n\nCLOCK_MODE() → stringpublic#Description of the clock\n\ncheckpoints(address account, uint32 pos) → struct ERC20Votes.Checkpointpublic#Get the pos-th checkpoint for account.\n\nnumCheckpoints(address account) → uint32public#Get number of checkpoints for account.\n\ndelegates(address account) → addresspublic#Get the address account is currently delegating to.\n\ngetVotes(address account) → uint256public#Gets the current votes balance for account\n\ngetPastVotes(address account, uint256 timepoint) → uint256public#Retrieve the number of votes for account at the end of timepoint.Requirements:\ntimepoint must be in the past\n\ngetPastTotalSupply(uint256 timepoint) → uint256public#Retrieve the totalSupply at the end of timepoint. Note, this value is the sum of all balances.\nIt is NOT the sum of all the delegated votes!Requirements:\ntimepoint must be in the past\n\ndelegate(address delegatee)public#Delegate votes from the sender to delegatee.\n\ndelegateBySig(address delegatee, uint256 nonce, uint256 expiry, uint8 v, bytes32 r, bytes32 s)public#Delegates votes from signer to delegatee\n\n_maxSupply() → uint224internal#Maximum token supply. Defaults to type(uint224).max (2^224^ - 1).\n\n_mint(address account, uint256 amount)internal#Snapshots the totalSupply after it has been increased.\n\n_burn(address account, uint256 amount)internal#Snapshots the totalSupply after it has been decreased.\n\n_afterTokenTransfer(address from, address to, uint256 amount)internal#Move voting power when tokens are transferred.Emits a IVotes.DelegateVotesChanged event.\n\n_delegate(address delegator, address delegatee)internal#Change delegation for delegator to delegatee.Emits events IVotes.DelegateChanged and IVotes.DelegateVotesChanged.\n\nERC20VotesComp\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20VotesComp.sol\";\nExtension of ERC20 to support Compound's voting and delegation. This version exactly matches Compound's\ninterface, with the drawback of only supporting supply up to (2^96^ - 1).\nNOTE: You should use this contract if you need exact compatibility with COMP (for example in order to use your token\nwith Governor Alpha or Bravo) and if you are sure the supply cap of 2^96^ is enough for you. Otherwise, use the\nERC20Votes variant of this module.\nThis extension keeps a history (checkpoints) of each account's vote power. Vote power can be delegated either\nby calling the IVotes.delegate function directly, or by providing a signature to be used with IVotes.delegateBySig. Voting\npower can be queried through the public accessors ERC20VotesComp.getCurrentVotes and ERC20VotesComp.getPriorVotes.\nBy default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it\nrequires users to delegate to themselves in order to activate checkpoints and have their voting power tracked.\nAvailable since v4.2.\nFunctions\ngetCurrentVotes(account)\ngetPriorVotes(account, blockNumber)\n_maxSupply()\nERC20Votes\nclock()\nCLOCK_MODE()\ncheckpoints(account, pos)\nnumCheckpoints(account)\ndelegates(account)\ngetVotes(account)\ngetPastVotes(account, timepoint)\ngetPastTotalSupply(timepoint)\ndelegate(delegatee)\ndelegateBySig(delegatee, nonce, expiry, v, r, s)\n_mint(account, amount)\n_burn(account, amount)\n_afterTokenTransfer(from, to, amount)\n_delegate(delegator, delegatee)\nIERC5805IVotesIERC6372ERC20Permit\npermit(owner, spender, value, deadline, v, r, s)\nnonces(owner)\nDOMAIN_SEPARATOR()\n_useNonce(owner)\nEIP712\n_domainSeparatorV4()\n_hashTypedDataV4(structHash)\neip712Domain()\nIERC5267IERC20PermitERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsERC20VotesIERC5805IVotes\nDelegateChanged(delegator, fromDelegate, toDelegate)\nDelegateVotesChanged(delegate, previousBalance, newBalance)\nIERC6372ERC20PermitEIP712IERC5267\nEIP712DomainChanged()\nIERC20PermitERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\ngetCurrentVotes(address account) → uint96external#Comp version of the Governor.getVotes accessor, with uint96 return type.\n\ngetPriorVotes(address account, uint256 blockNumber) → uint96external#Comp version of the IVotes.getPastVotes accessor, with uint96 return type.\n\n_maxSupply() → uint224internal#Maximum token supply. Reduced to type(uint96).max (2^96^ - 1) to fit COMP interface.\n\nERC20Wrapper\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC20Wrapper.sol\";\nExtension of the ERC20 token contract to support token wrapping.\nUsers can deposit and withdraw \"underlying tokens\" and receive a matching number of \"wrapped tokens\". This is useful\nin conjunction with other modules. For example, combining this wrapping mechanism with ERC20Votes will allow the\nwrapping of an existing \"basic\" ERC20 into a governance token.\nAvailable since v4.2.\nFunctions\nconstructor(underlyingToken)\ndecimals()\nunderlying()\ndepositFor(account, amount)\nwithdrawTo(account, amount)\n_recover(account)\nERC20\nname()\nsymbol()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nconstructor(contract IERC20 underlyingToken)internal#\n\ndecimals() → uint8public#See ERC20.decimals.\n\nunderlying() → contract IERC20public#Returns the address of the underlying ERC-20 token that is being wrapped.\n\ndepositFor(address account, uint256 amount) → boolpublic#Allow a user to deposit underlying tokens and mint the corresponding number of wrapped tokens.\n\nwithdrawTo(address account, uint256 amount) → boolpublic#Allow a user to burn a number of wrapped tokens and withdraw the corresponding number of underlying tokens.\n\n_recover(address account) → uint256internal#Mint wrapped token to cover any underlyingTokens that would have been transferred by mistake. Internal\nfunction that can be exposed with access control if desired.\n\nERC4626\nimport \"@openzeppelin/contracts/token/ERC20/extensions/ERC4626.sol\";\nImplementation of the ERC4626 \"Tokenized Vault Standard\" as defined in\nEIP-4626.\nThis extension allows the minting and burning of \"shares\" (represented using the ERC20 inheritance) in exchange for\nunderlying \"assets\" through standardized IERC4626.deposit, IERC4626.mint, IERC4626.redeem and ERC1155Burnable.burn workflows. This contract extends\nthe ERC20 standard. Any additional extensions included along it would affect the \"shares\" token represented by this\ncontract and not the \"assets\" token which is an independent contract.\n[CAUTION]\nIn empty (or nearly empty) ERC-4626 vaults, deposits are at high risk of being stolen through frontrunning\nwith a \"donation\" to the vault that inflates the price of a share. This is variously known as a donation or inflation\nattack and is essentially a problem of slippage. Vault deployers can protect against this attack by making an initial\ndeposit of a non-trivial amount of the asset, such that price manipulation becomes infeasible. Withdrawals may\nsimilarly be affected by slippage. Users can protect against this attack as well as unexpected slippage in general by\nverifying the amount received is as expected, using a wrapper that performs these checks such as\nERC4626Router.\nSince v4.9, this implementation uses virtual assets and shares to mitigate that risk. The _decimalsOffset()\ncorresponds to an offset in the decimal representation between the underlying asset's decimals and the vault\ndecimals. This offset also determines the rate of virtual shares to virtual assets in the vault, which itself\ndetermines the initial exchange rate. While not fully preventing the attack, analysis shows that the default offset\n(0) makes it non-profitable, as a result of the value being captured by the virtual shares (out of the attacker's\ndonation) matching the attacker's expected gains. With a larger offset, the attack becomes orders of magnitude more\nexpensive than it is profitable. More details about the underlying math can be found\nxref:erc4626#inflation-attack[here].\nThe drawback of this approach is that the virtual shares do capture (a very small) part of the value being accrued\nto the vault. Also, if the vault experiences losses, the users try to exit the vault, the virtual shares and assets\nwill cause the first user to exit to experience reduced losses in detriment to the last users that will experience\nbigger losses. Developers willing to revert back to the pre-v4.9 behavior just need to override the\n_convertToShares and _convertToAssets functions.\nTo learn more, check out our xref:ROOT:erc4626[ERC-4626 guide].\nAvailable since v4.7.\nFunctions\nconstructor(asset_)\ndecimals()\nasset()\ntotalAssets()\nconvertToShares(assets)\nconvertToAssets(shares)\nmaxDeposit()\nmaxMint()\nmaxWithdraw(owner)\nmaxRedeem(owner)\npreviewDeposit(assets)\npreviewMint(shares)\npreviewWithdraw(assets)\npreviewRedeem(shares)\ndeposit(assets, receiver)\nmint(shares, receiver)\nwithdraw(assets, receiver, owner)\nredeem(shares, receiver, owner)\n_convertToShares(assets, rounding)\n_convertToAssets(shares, rounding)\n_deposit(caller, receiver, assets, shares)\n_withdraw(caller, receiver, owner, assets, shares)\n_decimalsOffset()\nIERC4626ERC20\nname()\nsymbol()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsIERC4626\nDeposit(sender, owner, assets, shares)\nWithdraw(sender, receiver, owner, assets, shares)\nERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nconstructor(contract IERC20 asset_)internal#Set the underlying asset contract. This must be an ERC20-compatible contract (ERC20 or ERC777).\n\ndecimals() → uint8public#Decimals are computed by adding the decimal offset on top of the underlying asset's decimals. This\n\"original\" value is cached during construction of the vault contract. If this read operation fails (e.g., the\nasset has not been created yet), a default of 18 is used to represent the underlying asset's decimals.See IERC20Metadata.decimals.\n\nasset() → addresspublic#See IERC4626.asset.\n\ntotalAssets() → uint256public#See IERC4626.totalAssets.\n\nconvertToShares(uint256 assets) → uint256public#See IERC4626.convertToShares.\n\nconvertToAssets(uint256 shares) → uint256public#See IERC4626.convertToAssets.\n\nmaxDeposit(address) → uint256public#See IERC4626.maxDeposit.\n\nmaxMint(address) → uint256public#See IERC4626.maxMint.\n\nmaxWithdraw(address owner) → uint256public#See IERC4626.maxWithdraw.\n\nmaxRedeem(address owner) → uint256public#See IERC4626.maxRedeem.\n\npreviewDeposit(uint256 assets) → uint256public#See IERC4626.previewDeposit.\n\npreviewMint(uint256 shares) → uint256public#See IERC4626.previewMint.\n\npreviewWithdraw(uint256 assets) → uint256public#See IERC4626.previewWithdraw.\n\npreviewRedeem(uint256 shares) → uint256public#See IERC4626.previewRedeem.\n\ndeposit(uint256 assets, address receiver) → uint256public#See IERC4626.deposit.\n\nmint(uint256 shares, address receiver) → uint256public#See IERC4626.mint.As opposed to IERC4626.deposit, minting is allowed even if the vault is in a state where the price of a share is zero.\nIn this case, the shares will be minted without requiring any assets to be deposited.\n\nwithdraw(uint256 assets, address receiver, address owner) → uint256public#See IERC4626.withdraw.\n\nredeem(uint256 shares, address receiver, address owner) → uint256public#See IERC4626.redeem.\n\n_convertToShares(uint256 assets, enum Math.Rounding rounding) → uint256internal#Internal conversion function (from assets to shares) with support for rounding direction.\n\n_convertToAssets(uint256 shares, enum Math.Rounding rounding) → uint256internal#Internal conversion function (from shares to assets) with support for rounding direction.\n\n_deposit(address caller, address receiver, uint256 assets, uint256 shares)internal#Deposit/mint common workflow.\n\n_withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares)internal#Withdraw/redeem common workflow.\n\n_decimalsOffset() → uint8internal#\n\nIERC20Metadata\nimport \"@openzeppelin/contracts/token/ERC20/extensions/IERC20Metadata.sol\";\nInterface for the optional metadata functions from the ERC20 standard.\nAvailable since v4.1.\nFunctions\nname()\nsymbol()\ndecimals()\nIERC20\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\n\nEventsIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nname() → stringexternal#Returns the name of the token.\n\nsymbol() → stringexternal#Returns the symbol of the token.\n\ndecimals() → uint8external#Returns the decimals places of the token.\n\nIERC20Permit\nimport \"@openzeppelin/contracts/token/ERC20/extensions/IERC20Permit.sol\";\nInterface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in\nEIP-2612.\nAdds the ERC20Permit.permit method, which can be used to change an account's ERC20 allowance (see IERC20.allowance) by\npresenting a message signed by the account. By not relying on IERC20.approve, the token holder account doesn't\nneed to send a transaction, and thus is not required to hold Ether at all.\n==== Security Considerations\nThere are two important considerations concerning the use of permit. The first is that a valid permit signature\nexpresses an allowance, and it should not be assumed to convey additional meaning. In particular, it should not be\nconsidered as an intention to spend the allowance in any specific way. The second is that because permits have\nbuilt-in replay protection and can be submitted by anyone, they can be frontrun. A protocol that uses permits should\ntake this into consideration and allow a permit call to fail. Combining these two aspects, a pattern that may be\ngenerally recommended is:\nfunction doThingWithPermit(..., uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) public {\n try token.permit(msg.sender, address(this), value, deadline, v, r, s) {} catch {}\n doThing(..., value);\n}\n\nfunction doThing(..., uint256 value) public {\n token.safeTransferFrom(msg.sender, address(this), value);\n ...\n}\nObserve that: 1) msg.sender is used as the owner, leaving no ambiguity as to the signer intent, and 2) the use of\ntry/catch allows the permit to fail and makes the code tolerant to frontrunning. (See also\nSafeERC20.safeTransferFrom).\nAdditionally, note that smart contract wallets (such as Argent or Safe) are not able to produce permit signatures, so\ncontracts should have entry points that don't rely on permit.\nFunctions\npermit(owner, spender, value, deadline, v, r, s)\nnonces(owner)\nDOMAIN_SEPARATOR()\n\npermit(address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)external#Sets value as the allowance of spender over owner's tokens,\ngiven owner's signed approval.The same issues IERC20.approve has related to transaction\nordering also apply here.Emits an IERC20.Approval event.Requirements:\nspender cannot be the zero address.\ndeadline must be a timestamp in the future.\nv, r and s must be a valid secp256k1 signature from owner\nover the EIP712-formatted function arguments.\nthe signature must use owner's current nonce (see Votes.nonces).\nFor more information on the signature format, see the\nrelevant EIP\nsection.CAUTION: See Security Considerations above.\n\nnonces(address owner) → uint256external#Returns the current nonce for owner. This value must be\nincluded whenever a signature is generated for ERC20Permit.permit.Every successful call to ERC20Permit.permit increases owner's nonce by one. This\nprevents a signature from being used multiple times.\n\nDOMAIN_SEPARATOR() → bytes32external#Returns the domain separator used in the encoding of the signature for ERC20Permit.permit, as defined by EIP712.\n\nERC20PresetFixedSupply\nimport \"@openzeppelin/contracts/token/ERC20/presets/ERC20PresetFixedSupply.sol\";\nERC20 token, including:\n\nPreminted initial supply\nAbility for holders to burn (destroy) their tokens\nNo access control mechanism (for minting/pausing) and hence no governance\n\nThis contract uses ERC20Burnable to include burn capabilities - head to\nits documentation for details.\nAvailable since v3.4.\nDeprecated in favor of Contracts Wizard.\nFunctions\nconstructor(name, symbol, initialSupply, owner)\nERC20Burnable\nburn(amount)\nburnFrom(account, amount)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_beforeTokenTransfer(from, to, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20\nEventsERC20BurnableERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\n\nconstructor(string name, string symbol, uint256 initialSupply, address owner)public#Mints initialSupply amount of token and transfers them to owner.See ERC20.constructor.\n\nERC20PresetMinterPauser\nimport \"@openzeppelin/contracts/token/ERC20/presets/ERC20PresetMinterPauser.sol\";\nERC20 token, including:\n\nability for holders to burn (destroy) their tokens\na minter role that allows for token minting (creation)\na pauser role that allows to stop all token transfers\n\nThis contract uses AccessControl to lock permissioned functions using the\ndifferent roles - head to its documentation for details.\nThe account that deploys the contract will be granted the minter and pauser\nroles, as well as the default admin role, which will let it grant both minter\nand pauser roles to other accounts.\nDeprecated in favor of Contracts Wizard.\nFunctions\nconstructor(name, symbol)\nmint(to, amount)\npause()\nunpause()\n_beforeTokenTransfer(from, to, amount)\nMINTER_ROLE()\nPAUSER_ROLE()\nERC20PausablePausable\npaused()\n_requireNotPaused()\n_requirePaused()\n_pause()\n_unpause()\nERC20Burnable\nburn(amount)\nburnFrom(account, amount)\nERC20\nname()\nsymbol()\ndecimals()\ntotalSupply()\nbalanceOf(account)\ntransfer(to, amount)\nallowance(owner, spender)\napprove(spender, amount)\ntransferFrom(from, to, amount)\nincreaseAllowance(spender, addedValue)\ndecreaseAllowance(spender, subtractedValue)\n_transfer(from, to, amount)\n_mint(account, amount)\n_burn(account, amount)\n_approve(owner, spender, amount)\n_spendAllowance(owner, spender, amount)\n_afterTokenTransfer(from, to, amount)\nIERC20MetadataIERC20AccessControlEnumerable\nsupportsInterface(interfaceId)\ngetRoleMember(role, index)\ngetRoleMemberCount(role)\n_grantRole(role, account)\n_revokeRole(role, account)\nAccessControl\nhasRole(role, account)\n_checkRole(role)\n_checkRole(role, account)\ngetRoleAdmin(role)\ngrantRole(role, account)\nrevokeRole(role, account)\nrenounceRole(role, account)\n_setupRole(role, account)\n_setRoleAdmin(role, adminRole)\nDEFAULT_ADMIN_ROLE()\nERC165IERC165IAccessControlEnumerableIAccessControl\nEventsERC20PausablePausable\nPaused(account)\nUnpaused(account)\nERC20BurnableERC20IERC20MetadataIERC20\nTransfer(from, to, value)\nApproval(owner, spender, value)\nAccessControlEnumerableAccessControlERC165IERC165IAccessControlEnumerableIAccessControl\nRoleAdminChanged(role, previousAdminRole, newAdminRole)\nRoleGranted(role, account, sender)\nRoleRevoked(role, account, sender)\n\nconstructor(string name, string symbol)public#Grants DEFAULT_ADMIN_ROLE, MINTER_ROLE and PAUSER_ROLE to the\naccount that deploys the contract.See ERC20.constructor.\n\nmint(address to, uint256 amount)public#Creates amount new tokens for to.See ERC20._mint.Requirements:\nthe caller must have the MINTER_ROLE.\n\npause()public#Pauses all token transfers.See ERC20Pausable and Pausable._pause.Requirements:\nthe caller must have the PAUSER_ROLE.\n\nunpause()public#Unpauses all token transfers.See ERC20Pausable and Pausable._unpause.Requirements:\nthe caller must have the PAUSER_ROLE.\n\n_beforeTokenTransfer(address from, address to, uint256 amount)internal#\n\nMINTER_ROLE() → bytes32public#\n\nPAUSER_ROLE() → bytes32public#\n\nSafeERC20\nimport \"@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol\";\nWrappers around ERC20 operations that throw on failure (when the token\ncontract returns false). Tokens that return no value (and instead revert or\nthrow on failure) are also supported, non-reverting calls are assumed to be\nsuccessful.\nTo use this library you can add a using SafeERC20 for IERC20; statement to your contract,\nwhich allows you to call the safe operations as token.safeTransfer(...), etc.\nFunctions\nsafeTransfer(token, to, value)\nsafeTransferFrom(token, from, to, value)\nsafeApprove(token, spender, value)\nsafeIncreaseAllowance(token, spender, value)\nsafeDecreaseAllowance(token, spender, value)\nforceApprove(token, spender, value)\nsafePermit(token, owner, spender, value, deadline, v, r, s)\n\nsafeTransfer(contract IERC20 token, address to, uint256 value)internal#Transfer value amount of token from the calling contract to to. If token returns no value,\nnon-reverting calls are assumed to be successful.\n\nsafeTransferFrom(contract IERC20 token, address from, address to, uint256 value)internal#Transfer value amount of token from from to to, spending the approval given by from to the\ncalling contract. If token returns no value, non-reverting calls are assumed to be successful.\n\nsafeApprove(contract IERC20 token, address spender, uint256 value)internal#Deprecated. This function has issues similar to the ones found in\nIERC20.approve, and its usage is discouraged.Whenever possible, use SafeERC20.safeIncreaseAllowance and\nSafeERC20.safeDecreaseAllowance instead.\n\nsafeIncreaseAllowance(contract IERC20 token, address spender, uint256 value)internal#Increase the calling contract's allowance toward spender by value. If token returns no value,\nnon-reverting calls are assumed to be successful.\n\nsafeDecreaseAllowance(contract IERC20 token, address spender, uint256 value)internal#Decrease the calling contract's allowance toward spender by value. If token returns no value,\nnon-reverting calls are assumed to be successful.\n\nforceApprove(contract IERC20 token, address spender, uint256 value)internal#Set the calling contract's allowance toward spender to value. If token returns no value,\nnon-reverting calls are assumed to be successful. Meant to be used with tokens that require the approval\nto be set to zero before setting it to a non-zero value, such as USDT.\n\nsafePermit(contract IERC20Permit token, address owner, address spender, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s)internal#Use a ERC-2612 signature to set the owner approval toward spender on token.\nRevert on invalid signature.\n\nTokenTimelock\nimport \"@openzeppelin/contracts/token/ERC20/utils/TokenTimelock.sol\";\nA token holder contract that will allow a beneficiary to extract the\ntokens after a given release time.\nUseful for simple vesting schedules like \"advisors get all of their tokens\nafter 1 year\".\nFunctions\nconstructor(token_, beneficiary_, releaseTime_)\ntoken()\nbeneficiary()\nreleaseTime()\nrelease()\n\nconstructor(contract IERC20 token_, address beneficiary_, uint256 releaseTime_)public#Deploys a timelock instance that is able to hold the token specified, and will only release it to\nbeneficiary_ when PaymentSplitter.release is invoked after releaseTime_. The release time is specified as a Unix timestamp\n(in seconds).\n\ntoken() → contract IERC20public#Returns the token being held.\n\nbeneficiary() → addresspublic#Returns the beneficiary that will receive the tokens.\n\nreleaseTime() → uint256public#Returns the time when the tokens are released in seconds since Unix epoch (i.e. Unix timestamp).\n\nrelease()public#Transfers tokens held by the timelock to the beneficiary. Will only succeed if invoked after the release\ntime.On this pageCoreExtensionsPresetsUtilitiesERC20IERC20MetadataIERC20IERC20MetadataIERC20IERC20ERC20BurnableERC20IERC20MetadataIERC20ERC20IERC20MetadataIERC20ERC20CappedERC20IERC20MetadataIERC20ERC20IERC20MetadataIERC20ERC20FlashMintIERC3156FlashLenderERC20IERC20MetadataIERC20IERC3156FlashLenderERC20IERC20MetadataIERC20ERC20PausablePausableERC20IERC20MetadataIERC20PausableERC20IERC20MetadataIERC20ERC20PermitEIP712IERC5267IERC20PermitERC20IERC20MetadataIERC20EIP712IERC5267IERC20PermitERC20IERC20MetadataIERC20ERC20SnapshotERC20IERC20MetadataIERC20ERC20IERC20MetadataIERC20[WARNING]We haven't measured the actual numbers; if this is something you're interested in please reach out to us.ERC20VotesIERC5805IVotesIERC6372ERC20PermitEIP712IERC5267IERC20PermitERC20IERC20MetadataIERC20IERC5805IVotesIERC6372ERC20PermitEIP712IERC5267IERC20PermitERC20IERC20MetadataIERC20ERC20VotesCompERC20VotesIERC5805IVotesIERC6372ERC20PermitEIP712IERC5267IERC20PermitERC20IERC20MetadataIERC20ERC20VotesIERC5805IVotesIERC6372ERC20PermitEIP712IERC5267IERC20PermitERC20IERC20MetadataIERC20ERC20WrapperERC20IERC20MetadataIERC20ERC20IERC20MetadataIERC20ERC4626[CAUTION]To learn more, check out our xref:ROOT:erc4626[ERC-4626 guide].IERC4626ERC20IERC20MetadataIERC20IERC4626ERC20IERC20MetadataIERC20IERC20MetadataIERC20IERC20IERC20PermitERC20PresetFixedSupplyERC20BurnableERC20IERC20MetadataIERC20ERC20BurnableERC20IERC20MetadataIERC20ERC20PresetMinterPauserERC20PausablePausableERC20BurnableERC20IERC20MetadataIERC20AccessControlEnumerableAccessControlERC165IERC165IAccessControlEnumerableIAccessControlERC20PausablePausableERC20BurnableERC20IERC20MetadataIERC20AccessControlEnumerableAccessControlERC165IERC165IAccessControlEnumerableIAccessControlSafeERC20TokenTimelock","tokens":13724,"squid":"ink-security_audits","role":"Sentinel","at":1791267798256,"hash":"af559a13679eec9d971f5ae9173f214bb514ee73"}
{"url":"https://io.net/blog/company-updates","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogCompany UpdatesLatest By Topic (14)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech Trends2025: io.net Year in ReviewIO.NET Team / Jan 9, 2026io.net's 2025: $4M+ saved across 5 case studies, 320K GPUs in 138 countries, 21 partnerships, and a tokenomics redesign. What happens when infrastructure stops being the constraint.io.net Launches the First Adaptive Economic Engine for Decentralized ComputeIO.NET Team / Dec 11, 2025Discover io.net's Incentive Dynamic Engine (IDE): an adaptive tokenomics model bringing sustainable economics and predictable stability to decentralized GPU compute.Introducing Unified Chat: One Interface for Every AI Model and ToolIO.NET Team / Nov 4, 2025Unified Chat is the single, intelligent AI workspace that unifies every model and tool. Auto-routes for optimal quality and cost. End fragmentation.Introducing Total Network Earnings: Transparent TrustIO.NET Team / May 19, 2025io.net launches Total Network Earnings (TNE) for complete transparency in AI infrastructure costs with real-time tracking, automated payments, and verifiable metrics.io.net Turns One: Building the Intelligent Stack for AIIO.NET Team / May 12, 2025io.net celebrates its first anniversary, showcasing growth to 10,000+ GPUs across 138 regions and $13M revenue while democratizing AI infrastructure access.io.net Powers Privacy-First AI Training with Flashback Labs' StargazerIO.NET Team / May 4, 2025io.net enables privacy-first AI training through Flashback Labs' Stargazer model, using federated learning and TEEs to protect personal data during training.Injective & io.net: Expanding Decentralized Compute to Power The Future of DeFAIIO.NET Team / Apr 20, 2025Injective partners with io.net to revolutionize DeFAI development by combining AI-driven blockchain tools with decentralized GPU computing infrastructure.Theoriq and io.net: Powering Decentralized AI SwarmsIO.NET Team / Apr 13, 2025Theoriq partners with io.net to power decentralized AI agent swarms on blockchain, reducing compute costs by 90% while scaling modular AI ecosystems.What is IO Intelligence? Unlocking the Power of AI-Driven InsightsIO.NET Team / Mar 2, 2025IO Intelligence is an AI-powered analytics system that optimizes decentralized computing with real-time monitoring, cost reduction, and LLM performance tracking.io.net and Nillion Partner to Transform Privacy-Preserving AI Compute SolutionsIO.NET Team / Feb 23, 2025io.net and Nillion partner to combine decentralized GPU computing with privacy-preserving blind computation for secure AI inference solutions.What is IO Intelligence? An AI Game-ChangerIO.NET Team / Jan 26, 2025IO Intelligence is an AI-powered optimization system for decentralized computing that monitors, predicts, and optimizes GPU workloads automatically.Nesa and io.net: The Future of Decentralized AI on BlockchainIO.NET Team / Jan 5, 2025Nesa blockchain hosts 1,000+ AI models with io.net's decentralized GPU network, creating trustless AI infrastructure to compete with Big Tech.Page 1 of 2","tokens":831,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267801756,"hash":"24a7e25f0310836e83a7265315f85e6cad694238"}
{"url":"https://io.net/blog/2025-io-net-year-in-review","domain":"io.net","title":"2025: io.net Year in Review","text":"Back To Blog2025: io.net Year in ReviewIO.NET Team / Jan 9, 2026Try io.intelligenceGet StartedTry io.cloudDeploy GPU#matthewCompany Updates2025 was the year io.net proved that decentralized compute infrastructure isn't just viable for production AI workloads. It's often the only economically rational choice.While the AI industry obsessed over model capabilities, the teams actually building products discovered a harder constraint: infrastructure costs were eating their margins alive. The startups that thrived in 2025 found a different path.What the Builders Actually SavedThe case studies tell a consistent story. Leonardo.Ai scaled from 14,000 to 19 million users while cutting GPU costs by over 50% compared to tier-one cloud providers. Wondera saved $2.48 million against AWS equivalent pricing, using 552,000 GPU hours across 96 GPUs (64 H100s and 32 H200s) to train three proprietary models powering their AI music platform.The Frodobots and UC Berkeley RAIL Lab collaboration demonstrated 92.8% cost savings versus AWS H100 pricing while running 12,696 GPU hours across 8 GPUs with zero failures during a 66-day research project. That project produced a peer-reviewed paper proving crowdsourced navigation data could train generalist AI models.Vistara Labs built 4,200 applications in two months through their Zaara AI platform, with 1,500 apps generated in just the first 10 days of September. Their previous \"unlimited\" $200/month plan had been generating $10,000+ in actual compute costs within weeks before switching to io.net.Perhaps most telling: KayOS, a two-person pre-seed startup, operates with the efficiency of a 10-person engineering team by powering their meta-coding agents through io.intelligence. They cut monthly compute costs from $2,500 to $1,000 per customer. As CEO David Weinstein put it: \"The way we're operating right now as two people with the power of coding agents supporting us, it would take a team of 10 engineers. So, basically it wouldn't be economically possible.\"Thousands of GPUs, 138 Countries, One APIThe network now spans over 2,752 verified GPUs and 80,000 CPUs across 138+ countries. io.cloud supports bare metal, Ray clusters, Mega-Ray configurations, Container-as-a-Service, and (coming soon) VM on demand and Kubernetes clusters.io.intelligence matured into a unified API offering access to 15+ open-source models with OpenAI-compatible endpoints, built-in RAG with schema validation, and multi-modal support Who Chose to Build With io.net2025 brought 21 strategic partnerships that expanded io.net's reach across the AI and Web3 ecosystem:Early in the year, integrations with ai16zdao (January), Injective (January), and Nexus Labs (January) established io.net as critical infrastructure for decentralized AI applications.Privacy-focused partnerships followed: Nillion Network (February) for privacy-first AI inference, Oasis Protocol (February) for verifiable AI, and GaiaNet AI (February) for decentralized AI agent inference.Mid-year deals with Flock.io (March), Sahara AI (May), and Walrus Protocol (June) for a secure BYOM stack demonstrated growing enterprise traction.The second half accelerated with Vistara Labs (July) integrating decentralized GPU compute into their agentic OS, Orbofi (July) for tokenized AI agents, and Allora Network mainnet launch (November) bringing collective intelligence to decentralized compute.From Singapore to Abu Dhabi: Where io.net Showed Upio.net showed up where AI infrastructure decisions get made. Super AI Singapore (June) featured CEO Gaurav Sharma's keynote \"Decentralize or Die.\" TOKEN2049 Singapore (September) brought main stage presence and participation across multiple side events including the Solana Apex DePIN & AI Panel.Korea Blockchain Week (September) included booth presence at IMPACT and sponsored events. Solana Breakpoint Abu Dhabi (December) featured the first-ever Robot Arena with partners GEODNET and Frodobots, plus CPO Raj's panel on \"Compute Is the New Reserve Asset: How AI Will Reprice Capital Markets.\"Community-driven events expanded reach further: an AI Hackathon kickoff in Osaka (October), the Cybersecurity Business Convention in Toulouse, and io.net Turkey Ambassadors visiting Gazi University to discuss AI/DePIN with students.Tokenomics Got a RewriteDecember brought the most significant structural change of the year: the Incentive Dynamic Engine (IDE), a fundamental redesign of io.net's tokenomics released December 11.The problem IDE addresses is familiar to anyone who's watched DePIN projects struggle: fixed emission schedules disconnect token supply from actual network activity, leaving GPU providers exposed to price volatility and networks vulnerable to death spirals during downturns.IDE replaces inflation-based emissions with a demand-driven system. GPU provider payouts get stabilized in USD terms through a dual-vault mechanism that buffers market shocks. When network revenue exceeds payout obligations, tokens get absorbed from circulation. When revenue falls short, the system temporarily expands supply to maintain stable returns. At least 50% of remaining revenue after supplier payments gets burned, targeting removal of 150M+ $IO from supply.The practical result: GPU providers get predictable income regardless of token price swings, users get a more resilient compute network, and the system self-regulates based on actual utilization rather than speculation.Community feedback runs through February 27, with a final version scheduled for March 31 and implementation planned for Q2 2026.The Thesis That HeldThe year validated a straightforward thesis: when AI teams have access to cost-efficient, flexible compute infrastructure, they can build businesses that would otherwise be economically impossible.A two-person startup serving five enterprise customers. A generative music platform scaling to 200,000 users across 171 countries. A robotics research collaboration producing peer-reviewed breakthroughs. A creative AI platform growing from thousands to millions of users.None of these outcomes were guaranteed. All of them required infrastructure that traditional cloud providers couldn't offer at viable prices.The teams that figured this out in 2025 gained advantages that compound: lower burn rates, faster iteration cycles, and the freedom to focus on product rather than cost management. As Leonardo.Ai CTO Peter Runham noted, procurement flexibility means teams \"can quickly test new GPU architectures as they become available, keeping us at the forefront of AI innovation.\"2026 starts with a simple question for AI builders: what becomes possible when infrastructure stops being your constraint?Start building at io.net/cloud or explore models at io.net/intelligence","tokens":1685,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267812729,"hash":"5b9aafbc1a70be9b1f16f99c0cd1083d4a4a68b8"}
{"url":"https://docs.openzeppelin.com/contracts/4.x/erc20","domain":"docs.openzeppelin.com","title":"ERC20 | OpenZeppelin Docs","text":"OpenZeppelin ContractsPrevious Versionsv4TokensERC20Outdated VersionYou're viewing an older version (v4.x) The latest documentation is available for the current version. Click here to visit latest version.Open in ClaudeAn ERC20 token contract keeps track of fungible tokens: any one token is exactly equal to any other token; no tokens have special rights or behavior associated with them. This makes ERC20 tokens useful for things like a medium of exchange currency, voting rights, staking, and more.\nOpenZeppelin Contracts provides many ERC20-related contracts. On the API reference you’ll find detailed information on their properties and usage.\nConstructing an ERC20 Token Contract\nUsing Contracts, we can easily create our own ERC20 token contract, which will be used to track Gold (GLD), an internal currency in a hypothetical game.\nHere’s what our GLD token might look like.\n// contracts/GLDToken.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\nimport \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\n\ncontract GLDToken is ERC20\n constructor(uint256 initialSupply) ERC20(\"Gold\", \"GLD\") {\n _mint(msg.sender, initialSupply);\n\n}\nOur contracts are often used via inheritance, and here we’re reusing ERC20 for both the basic standard implementation and the name, symbol, and decimals optional extensions. Additionally, we’re creating an initialSupply of tokens, which will be assigned to the address that deploys the contract.\nFor a more complete discussion of ERC20 supply mechanisms, see Creating ERC20 Supply.\nThat’s it! Once deployed, we will be able to query the deployer’s balance:\n> GLDToken.balanceOf(deployerAddress)\n1000000000000000000000\nWe can also transfer these tokens to other accounts:\n> GLDToken.transfer(otherAddress, 300000000000000000000)\n> GLDToken.balanceOf(otherAddress)\n300000000000000000000\n> GLDToken.balanceOf(deployerAddress)\n700000000000000000000\nA Note on decimals\nOften, you’ll want to be able to divide your tokens into arbitrary amounts: say, if you own 5 GLD, you may want to send 1.5 GLD to a friend, and keep 3.5 GLD to yourself. Unfortunately, Solidity and the EVM do not support this behavior: only integer (whole) numbers can be used, which poses an issue. You may send 1 or 2 tokens, but not 1.5.\nTo work around this, ERC20 provides a decimals field, which is used to specify how many decimal places a token has. To be able to transfer 1.5 GLD, decimals must be at least 1, since that number has a single decimal place.\nHow can this be achieved? It’s actually very simple: a token contract can use larger integer values, so that a balance of 50 will represent 5 GLD, a transfer of 15 will correspond to 1.5 GLD being sent, and so on.\nIt is important to understand that decimals is only used for display purposes. All arithmetic inside the contract is still performed on integers, and it is the different user interfaces (wallets, exchanges, etc.) that must adjust the displayed values according to decimals. The total token supply and balance of each account are not specified in GLD: you need to divide by 10 ** decimals to get the actual GLD amount.\nYou’ll probably want to use a decimals value of 18, just like Ether and most ERC20 token contracts in use, unless you have a very special reason not to. When minting tokens or transferring them around, you will be actually sending the number num GLD * (10 ** decimals).\nBy default, ERC20 uses a value of 18 for decimals. To use a different value, you will need to override the decimals() function in your contract.\nfunction decimals() public view virtual override returns (uint8)\n return 16;\nSo if you want to send 5 tokens using a token contract with 18 decimals, the method to call will actually be:\ntransfer(recipient, 5 * (10 ** 18));\nPreset ERC20 contract\nA preset ERC20 is available, ERC20PresetMinterPauser. It is preset to allow for token minting (create), stop all token transfers (pause) and allow holders to burn (destroy) their tokens. The contract uses Access Control to control access to the minting and pausing functionality. The account that deploys the contract will be granted the minter and pauser roles, as well as the default admin role.\nThis contract is ready to deploy without having to write any Solidity code. It can be used as-is for quick prototyping and testing, but is also suitable for production environments.\nContract presets are now deprecated in favor of Contracts Wizard as a more powerful alternative.OverviewPrevious PageCreating SupplyNext PageOn this pageConstructing an ERC20 Token ContractA Note on decimalsPreset ERC20 contract","tokens":1144,"squid":"ink-security_audits","role":"Sentinel","at":1791267812814,"hash":"c70d580d4b2bbc1d3470da2d87bb56f323e0c038"}
{"url":"https://docs.base.org/specifications/transactions/transaction-finality","domain":"docs.base.org","title":"Transaction Finality - Base Documentation","text":"Finality refers to the point at which a transaction sent to Base becomes irreversible. This provides guarantees that the transaction will not be rolled back or lost.\nFinality works differently for normal transactions that modify Base L2 state than it does for transactions that withdraw funds from Base L2 to Ethereum L1.\nOnly transactions that withdraw funds from Base to Ethereum must wait for a withdrawal finalization window (5 days, or 1 day when both TEE and ZK proofs are present). Regular transactions within Base, such as swaps or sends, do not have this wait.\n​Finality for Base L2 Transactions\nThis describes finality for transactions on Base except withdrawal transactions that move funds from Base to Ethereum L1\nFor transactions on Base, finality is not a single time to wait for. Instead, there are 4 stages in time that each provide increasing security guarantees.\n\n1Flashblock Inclusion: ~200msAfter roughly 200ms, the transaction is included in a preconfirmation block (Flashblock) by the Base sequencer.Under 0.001% Probability of a Reorg.\nFlashblocks reorg less than 0.001% of the time\nYou can see the reorg history in our public stats page.\n2L2 Block Inclusion: ~2sAfter roughly 2 seconds, the sequencer has built the transaction into an L2 block and distributed it to validator nodes.Near 0% Probability of a Reorg.\nOnly a single Base L2 block has ever reorged, representing .0000003% of transactions. The data can be seen here\n3L1 Batch Inclusion: ~2mAfter roughly 2 minutes, a Base batch containing the transaction has been posted to Ethereum.Effectively 0% Probability of a Reorg.\nThere has never been a reorg of L2 blocks that were batched to Ethereum L1.\nA reorg of Ethereum L1 does not require a reorg of the Base L2 chain. The sequencer and validator nodes maintain a configurable lag from the tip of Ethereum, so typical L1 reorgs have no effect. In the event of larger Ethereum reorgs, Base can resubmit batch data on L1 without changing the sequenced L2 blocks.\n4L1 Batch Finality: ~20mThe Ethereum L1 batch containing the transaction is older than 2 epochs, or 64 L1 blocks.Effectively 0% Probability of a Reorg.\nL2 blocks that have reached L1 batch finality are protected from reorgs the same way Ethereum finalized blocks are. They are in practice impossible to reverse.\n\n​Finality for Withdrawal Transactions\nThis describes finality of transactions that move funds from Base to Ethereum\nOnly withdrawals to Ethereum must wait for a finalization window before the funds can be released to the address on Ethereum L1. This allows Base’s proof system to provide extremely high security guarantees for funds bridged to Base.\nSince the Beryl upgrade, the finalization window is 5 days for a single-proof dispute game and 1 day on the dual-proof fast path, when both a TEE proof and a ZK proof back the same proposal. The window accounts for most of the end-to-end time; waiting for the relevant Base state to be proposed on Ethereum usually adds only about 20 to 60 minutes, plus the prove and finalize transactions. Third-party bridges that release funds faster use their own liquidity and do not change this window.\nWhat Happens During the Finalization Window?After a withdrawal is initiated on Base, a proposer submits a checkpoint claim on Ethereum through an AggregateVerifier game with a TEE or ZK proof. An independent challenger can dispute an invalid claim with a ZK proof. The game’s finalization window gives other participants time to verify the claim; when TEE and ZK proofs support the same proposal, the dual-proof path is shorter. See the Azul proof system for the proof flow.A withdrawal proven against an invalid claim cannot finalize and must be re-proven against a valid one. Challenging a claim does not reorg the Base chain.\n​FAQ\nIf There Is a Reorg on Ethereum, Will It Cause a Reorg on Base?In almost all circumstances, no. Base can simply re-submit batch data to Ethereum transparently while the L2 chain continues to progress.How Long Do Deposit Transactions Take to Finalize?Transactions moving funds from Ethereum L1 to Base must be initiated on Ethereum and typically get included within 3 minutes by the Base sequencer.If a Challenger Wins a Dispute Game, Will the L2 Chain Reorg?No. The output proposal that was challenged is marked invalid, and any actions that used it’s output root become invalid. Specifically, withdrawals from Base to L1 that proved against this output root must now prove against a different and valid one.Was this page helpful?Suggest editsRaise issue","tokens":1134,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267826652,"hash":"510b6fd6ce641d358809083064eaae691c83de6e"}
{"url":"https://aave.com/legal/app/account-deletion","domain":"aave.com","title":"Delete Your Aave App Account | Aave","text":"The Aave App is a self-custodial mobile application software platform. The Aave App Terms and Conditions of Use constitute a legally binding agreement between you and Aave Interfaces Ltd, its affiliates, subsidiaries, successors, and assigns (collectively, \"Aave Labs\"). This page explains how to request deletion of your Aave App account, including if you can no longer access the App.\nTo request deletion of your Aave App account, submit a request by emailing us at wecare@aave.com.\nHow to delete your account\nThere are two ways to request account deletion:\n\nIn the app: Open the Aave App and go to Settings > Advanced > Delete Account, then follow the steps shown.\nWithout app access: If you can no longer open the App, submit a request by emailing wecare@aave.com. In the request, specify that you are requesting deletion of your Aave App account and include the email address or phone number associated with your account.\n\nWe may require specific information from you to help us verify your identity and process your request.\nBefore you request deletion\nWe are unable to delete your account until your full account balance has been withdrawn.\n\nWithdraw your full account balance and try again.\nIf you have a pending deposit or withdrawal, wait until it has finished before requesting deletion.\n\nWhat deletion does and does not remove\n\nPersonal information. Your request is for deletion of your Aave App account and the personal information we have collected from you, except as described below.\nInformation we may keep. Where you request the deletion of your information, we may continue to retain and use your information as permitted or required under applicable laws, for legal, tax, or regulatory reasons, or legitimate and lawful business purposes. We expect to delete your personal data (at the latest) once there is no longer any legal or regulatory requirement or legitimate business purpose for retaining your personal data.\nPublic blockchain records. We cannot edit or delete information that is stored on a particular blockchain. This information may include transaction data (i.e., purchases, sales, and transfers) related to your blockchain wallet address and any items held by your wallet address.\n\nFor further details on the information we may collect and retain, review the Aave App Privacy Policy.\nProtect your account\nYou must never share or disclose your private keys or seed phrases to any third party, including Aave Labs. Never share verification, two-factor authentication, or recovery codes with anyone.\nDo not include your password, passkey, private key, seed phrase, verification code, two-factor authentication code, or recovery code in an account deletion request.","tokens":674,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267829270,"hash":"8e9cf7e4572de14b1ba0e5769b5c43b5c4b02da9"}
{"url":"https://docs.base.org/specifications/transactions/transaction-ordering","domain":"docs.base.org","title":"Transaction Ordering - Base Documentation","text":"​Overview\nThis section describes how transactions are ordered on the Base networks. The ordering is separate from the UX,\nfor example the sequencer could be building Flashblocks every 200ms, without these Flashblocks being exposed publicly. In this scenario, block ordering\nwould change but the user experience would remain consistent.\n​Configurations\n​Flashblocks\nBlocks are built using base-builder with priority fee auctions occurring every 200ms. This reduces effective block times from 2 seconds to 200 milliseconds through preconfirmations.\nThere are three key differences from vanilla ordering:\n\nTiming — Flashblocks are built every 200ms, each ordering a portion of the block. Once built and broadcast, transaction ordering is locked. Later-arriving transactions with higher priority fees cannot be included in earlier Flashblocks.\n\nGas Allocation — Each Flashblock has an incrementally increasing gas budget. Flashblock 1 can use 1/10 of the block gas limit, Flashblock 2 can use 2/10, and so on until Flashblock 10 has access to the full limit.\nFlashblockAvailable Gas1~40M gas (1/10)2~80M gas (2/10)3~120M gas (3/10)……10~400M gas (full)\nBecause gas is allocated cumulatively, a transaction must fit within the budget available at the Flashblock it’s selected for. Base’s per-transaction gas maximum (~16.7M) is below Flashblock 1’s ~40M budget, so any valid transaction can be included starting from the first Flashblock.\n\nDynamic Mempool — The builder continuously accepts new transactions while building each Flashblock. This minimizes inclusion latency but means transactions are ordered by fee at the time of selection, not globally across all transactions that arrive during the 200ms window. A late-arriving high-fee transaction may appear after an already-committed lower-fee transaction.\nThis is a deliberate tradeoff: faster inclusion at the cost of occasionally “breaking” expected priority gas auction (PGA) ordering within a Flashblock.\n\n​Vanilla\nBlocks are built every 2s by base-reth-node. Transactions within those blocks are ordered by priority fee.Was this page helpful?Suggest editsRaise issue","tokens":531,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267836581,"hash":"88fa845aae1acbc110ba4ff43eaa1170b49340f9"}
{"url":"https://aave.com/legal/podcast","domain":"aave.com","title":"Aave Podcast Disclosures | Aave","text":"About This Podcast\nThe Hot Girl Finance podcast is owned and produced by Aave Labs. Episodes may include discussion of Aave Labs products (including, without limitation, the Aave App), services, or related financial topics. Content is provided for educational, informational, and promotional purposes only and does not constitute business, financial, investment, legal, or tax advice. You should conduct your own independent research and consult qualified professionals before making any financial decisions. Where episodes feature guests, any views, opinions, or statements expressed by guests are their own and do not represent the views of Aave Labs, nor should they be construed as an endorsement of any product, service, project, token, or strategy by Aave Labs.\nAbout the Aave App\nThe Aave App is a self-custodial mobile application provided by Aave Labs that provides access to decentralized blockchain protocols. The Aave App is not a regulated financial product. No banking, brokerage, payment, or investment adviser licence is held in connection with the Aave App, and the Aave App is not supervised by any financial services regulator. The Aave App does not take custody or control of user assets at any time. Aave Labs has no ability to access, recover, or restore private keys or digital assets under any circumstances. Loss of a device or private key without a secure backup may result in permanent, irreversible loss of assets. See Terms and Conditions for more details.\nYields and Savings Rates\nAny savings rates, APY figures, or yield information referenced in this podcast in connection with the Aave App are variable, not guaranteed, and subject to change. Yields, if available, are generated from DeFi market activity, including onchain vaults and decentralized lending markets, and are programmatically determined by smart contracts based on market supply and demand. Aave Labs does not control, guarantee, or underwrite any yield. Historical rates are not indicative of future performance.\nWaitlist / Program Participants\nIf you are currently participating in the Aave App waitlist program, any rates, boosts, or APY figures displayed within the program interface are illustrative simulations only, based on hypothetical market scenarios. They are not guarantees, promises, or offers of returns. No real interest, rewards, or DeFi yield is distributed or accrued during the waitlist program.\nRisk Disclosure\nDigital assets blockchain technology, smart contracts and decentralized finance products and services involve significant risk, including but not limited to: high price volatility (digital assets may lose all or substantially all of their value); smart contract bugs or vulnerabilities; oracle failures, blockchain network failures, forks, or disruptions; cybersecurity threats; and regulatory changes. You may lose some or all of any assets you interact with through the Aave App. Only engage with funds you can afford to lose.\nNo FDIC Insurance\nThe Aave App is not a bank and digital assets held through the Aave App are not bank deposits. Digital assets are not insured by the FDIC, SIPC, or any other governmental deposit protection scheme.\nRegulatory and Jurisdictional Notice\nThe Aave App is not available to residents of certain restricted jurisdictions and use may be restricted or prohibited in your jurisdiction. You are solely responsible for complying with all applicable laws and regulations where you reside.\nTax Obligations\nYou are solely responsible for determining, reporting, and paying any taxes arising from your use of the Aave App or any other digital asset activity, including but not limited to yield received, asset exchanges, and disposals. Tax treatment of digital assets varies by jurisdiction, is uncertain, and is subject to change. You are responsible for keeping adequate records of your transactions. Nothing in this podcast or in the Aave App constitutes tax advice. Consult a qualified tax professional regarding your specific situation.\nThird-Party Services\nThe Aave App may integrate with third-party services, including blockchain networks, oracle providers, liquidity protocols, lending protocols, and fiat on- or off-ramp providers, including providers which are affiliated with Aave Labs. When using an on- or off-ramp provider, you transact directly with that provider and are subject to its terms, policies, and applicable regulatory requirements, including KYC obligations. Aave App is not responsible for any third-party services or for any acts, omissions, errors, or failures of third-party providers. Your use of third-party services is at your own risk.","tokens":1158,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791267839485,"hash":"e2405b7d067af3331a29402f207c31530e52289d"}
{"url":"https://docs.base.org/specifications/transactions/throughput-and-limits","domain":"docs.base.org","title":"Throughput and Limits - Base Documentation","text":"Base throughput is constrained by gas limits, data availability throughput, fee market parameters, and endpoint limits. There is no single transactions-per-second value that applies to every workload, because transactions consume different amounts of gas and data.\nBase has sustained multiple bursts of over 5,000 TPS, and throughput continues to increase as the chain scales. For more context, see Introducing Base Azul.\n​Current Limits\nLimitValueFull block gas budget~400M gasFirst Flashblock gas budget~40M gasPer-transaction gas maximum16,777,216 gas (2^24)Deposit transaction limitMaximum gas includable in an L1 block (20,000,000 gas)\nThe full block gas budget is split across Flashblocks while the block is being built. Flashblock 1 can use 1/10 of the block gas limit, Flashblock 2 can use 2/10, and so on until Flashblock 10 has access to the full limit. See Transaction Ordering for how this affects transaction ordering.\n​Flashblock Performance\nFlashblocks stream incremental block updates roughly every 200ms, giving apps sub-second preconfirmations within the standard 2-second block.\nMetricValueFlashblock build time (P50)~10msPreconfirmation latency~200msFull block time2 secondsFlashblocks per block10Reorg rate< 0.1%\nSee the Flashblocks Reference for reorg handling and other common questions.\n​Per-Transaction Gas Maximum\nAs of the Azul hardfork, Base enforces a protocol-level per-transaction gas maximum of 16,777,216 gas (2^24) via EIP-7825. Transactions that specify a gas limit above this value are rejected during block validation. eth_sendTransaction or eth_sendRawTransaction will return a JSON-RPC error (for example: exceeds maximum per-transaction gas limit).\nDeposit transactions are exempt from this cap. They are limited by the maximum gas includable in an L1 block (20,000,000 gas).\nBundler operators for smart contract wallets must configure their systems to limit the bundle size to fit within this cap.\n​Fee Parameters\nFees affect practical throughput because they determine whether transactions can be included when demand approaches available capacity.\nParameterCurrent valueMinimum base fee5,000,000 wei (0.005 gwei)EIP-1559 elasticity6EIP-1559 denominator125Maximum L2 base fee change per block4%\nSee Network Fees for how Base transaction fees are structured, including the L2 execution fee and L1 security fee.\n​Data Availability Throughput\nBase transaction data is posted to Ethereum for data availability. If data availability throughput becomes constrained, the sequencer can limit L2 transaction throughput while the batcher catches up.\nDuring DA throttling, even transactions with high priority fees may be delayed. There is no RPC endpoint that calculates priority fee estimates with throttling in mind. See Troubleshooting Transactions for the transaction-submission implications.\n​Endpoint Limits\nPublic endpoints are rate-limited and are not suitable for production traffic. Hosted RPC providers can also apply request-per-second limits, compute-unit limits, method restrictions, archive-data limits, or WebSocket subscription limits.\nEndpoint limits do not change Base protocol capacity, but they can become the practical bottleneck for apps, wallets, indexers, and monitoring systems. For production use, choose an RPC provider from the Builder Stack or run a Base node.Was this page helpful?Suggest editsRaise issue","tokens":842,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267846534,"hash":"b57e9a01541dd2e2fecbfd057a35d4158709b27a"}
{"url":"https://ethresear.ch/c/better-icos/12","domain":"ethresear.ch","title":"Latest Better ICOs topics - Ethereum Research","text":"Latest topics in Better ICOs\n\n Better ICOs\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Better ICOs category\n\n To discuss better fundraising mechanisms such as: \n\nhttps://people.cs.uchicago.edu/~teutsch/papers/ico.pdf\nhttps://www.calctopia.com/papers/optimalICO.pdf\n\nThis is for academic discussion. If you advertise ICOs here, yo…\n\n read more\n\n 2\n\n 2.0k\n\n Mar 2018\n\n Explanation of DAICOs\n\n daico\n\n 82\n\n 142k\n\n Apr 2024\n\n IMO: Initial Model Offering\n\n 1\n\n 2.8k\n\n Apr 2024\n\n Token sales and shorting\n\n short-selling,efficient-market-hypothesis\n\n 27\n\n 14.2k\n\n Feb 2023\n\n Public Interest Projects - A Fully Onchain, Risk Minimized Seed Funding Mechanism\n\n 14\n\n 5.6k\n\n Apr 2022\n\n Approaching DAICOs from a different angle to fund FOSS development\n\n 0\n\n 1.4k\n\n Dec 2021\n\n DAICO: Praise and Critique  medium.com\n\n 5\n\n 3.1k\n\n Dec 2021\n\n Hackers & Painters, Open Source Projects, NFTs, and Simplified Harberger Tax\n\n 0\n\n 1.8k\n\n May 2021\n\n Growdrop: Expanding financial inclusion with DeFi\n\n 5\n\n 4.8k\n\n Oct 2019\n\n Improving the DAO/DAICO: questions addressed by our DAO3 proposal: Is it wrong to require a vote to get a refund, and wrong to force refunds by vote? Is it inefficient to burn instead of freeze tokens in a DAO3?\n\n 4\n\n 1.6k\n\n Sep 2018\n\n Call-out assurance contracts\n\n public-good\n\n 14\n\n 7.9k\n\n Sep 2018\n\n Pure Mined Currencies as ERC20 Tokens\n\n 0\n\n 2.2k\n\n Sep 2018\n\n DAICO open-source implementation: Daox organizations\n\n 2\n\n 3.2k\n\n Jul 2018\n\n Preventing a 51% attack on DAICOs where the recipient of the funds can be changed?\n\n 0\n\n 1.5k\n\n Jun 2018\n\n ICO Control Tokens\n\n 4\n\n 2.4k\n\n May 2018\n\n Designing DAICO model\n\n 4\n\n 3.1k\n\n May 2018\n\n Using ICOs to fund science\n\n 25\n\n 8.3k\n\n May 2018\n\n Interactive Coin Offering\n\n 0\n\n 1.8k\n\n Apr 2018\n\n DAICO and Iterative Investment\n\n 31\n\n 9.6k\n\n Apr 2018\n\n Legal and business implications of DAICO like models\n\n 0\n\n 2.3k\n\n Mar 2018\n\n ICO decentralised rating model\n\n 5\n\n 2.1k\n\n Feb 2018\n\n Our approach to a better ICO - Liquid Token Distribution (LTD)\n\n 7\n\n 3.1k\n\n Feb 2018\n\n Dynamic per-person-capped ICOs\n\n 2\n\n 2.0k\n\n Jan 2018\n\n Kicking off the Better ICOs category\n\n 2\n\n 2.3k\n\n Jan 2018\n\n Powered by Discourse","tokens":555,"squid":"ink-research","role":"Deep Scholar","at":1791267851386,"hash":"da26d6df46523c18e7566aa35ea005503ce24036"}
{"url":"https://docs.base.org/base-chain/specs/reference/b20/changelog/02-cobalt-b20-seize","domain":"docs.base.org","title":"B20: Seize Functionality - Base Documentation","text":"Audience: teams integrated against the base B20 surface on Beryl (live today) that perform\nadministrative balance removal, today via the deprecated burnBlocked. This note covers only the\nseize surface landing at the Cobalt hardfork and what it means for burnBlocked. The surface is\nshared, so it applies to both B20 Asset and B20 Stablecoin.\n\n​Summary\nAt Cobalt, the base B20 surface gains a first-class seize operation. seizeWithMemo(from, to, amount, memo) reassigns a holder’s balance to a destination in one admin call, gated by a new\nSEIZE_ROLE, a new SEIZE pause vector, and two new policy slots (SEIZE_EXEMPT_POLICY,\nSEIZE_RECEIVER_POLICY).\nNothing you call today breaks: every Beryl selector, event topic, and error keeps its exact 4-byte\nselector or topic0 and stays dialable at Cobalt. In particular, burnBlocked is deprecated but\nunchanged (same selector, same events, same behavior) and remains callable.\nTo migrate, move administrative balance removal from burnBlocked to seizeWithMemo: seize to a\ntreasury or self address, then call burn if you want the supply destroyed.\nSeize is opt-in per token. The surface exists at Cobalt, but seize does nothing until the issuer\nconfigures SEIZE_EXEMPT_POLICY. With the slot unset (always-allow), no account is seizable, and\nevery seizeWithMemo call reverts AccountNotSeizable. An issuer that never sets the policy has, in\neffect, no seize capability on that token.\n​Mapping Table\nThe selectors and topic0s below are the real values from the frozen ABIs:\ncrates/common/precompiles/src/common/abi/v1.rs for Beryl,\ncrates/common/precompiles/src/common/abi/v2.rs for Cobalt. Every Beryl symbol keeps its selector\nat Cobalt. Seize lives on the shared IB20 surface, so it’s identical across Asset and Stablecoin.\n​Functions\nBeryl symbol (selector)Cobalt (selector)StatusWhyburnBlocked(address,uint256) 0xec0cf3dcburnBlocked(address,uint256) 0xec0cf3dcdeprecated-dialableKept unchanged for backward compatibility. Prefer seizeWithMemo then burn. Destroys supply and reads TRANSFER_SENDER_POLICY.BURN_BLOCKED_ROLE() 0x32ad9be8BURN_BLOCKED_ROLE() 0x32ad9be8carried over unchangedStill gates burnBlocked only.—seizeWithMemo(address,address,uint256,bytes32) 0xf916d81bnewAdmin balance reassignment. A transfer, not a burn.—SEIZE_ROLE() 0x3c7e9ba5newRequired to call seizeWithMemo. Value keccak256(\"SEIZE_ROLE\") = 0x3469b8b0d89e9604f8510ed143f74a8336d22955d4f83e23bf53d9414e27f432.—SEIZE_EXEMPT_POLICY() 0xfeb346ecnewPolicy slot checked against from. Value keccak256(\"SEIZE_EXEMPT_POLICY\") = 0xedb5da348cfb67af08746d3afd1be81034b50d5c8576f31aff688f39dfd540ed.—SEIZE_RECEIVER_POLICY() 0xb31da27fnewPolicy slot checked against to. Value keccak256(\"SEIZE_RECEIVER_POLICY\") = 0xbf15b19caf5c77422c038bc25f26b8b815c3a14f6d04c6616076b81bcfe07b3d.\n​Events\nBeryl event (topic0)Cobalt (topic0)StatusWhyBurnedBlocked(address,address,uint256) 0x0b552e96653fd6842da37c477005d3b5c08a8c7d3631b1f43787b2dc9a1006a3unchangeddeprecated-still-emittedStill emitted by burnBlocked alongside Transfer(from, address(0), amount).—Seized(address,address,address,uint256) 0xa9aec5d8b86e2fa2fd6ac3af62f2622e3dfdab1967d4cbbb56a5df7d74cb887cnewEmitted by seizeWithMemo after Transfer(from, to, amount) and Memo(caller, memo).\n​Errors\nBeryl error (selector)Cobalt (selector)StatusWhyAccountNotBlocked(address) 0x64a5cb46unchangedpresent on Beryl alreadyThrown by burnBlocked when from is authorized under TRANSFER_SENDER_POLICY (that is, not blocked).—AccountNotSeizable(address) 0x91dbbc8dnewThrown by seizeWithMemo when from is authorized under SEIZE_EXEMPT_POLICY (that is, not seizable).\n​Pause Features\nPausableFeature is append-only. Cobalt adds one ordinal.\nBeryl ordinalsCobalt additionStorage bitWhyTRANSFER=0, MINT=1, BURN=2SEIZE=31 << 3 = 8Independent pause vector for seizeWithMemo. ALL_FEATURES_PAUSED becomes 15 (0b1111).\nseizeWithMemo is gated by the new SEIZE vector, not BURN. burnBlocked stays under BURN.\n​New at Cobalt: Adopt These\n​seizeWithMemo(from, to, amount, memo)\nThis is the canonical administrative balance-removal path. It’s a transfer: the balance moves from\nfrom to to, and totalSupply is unchanged. It runs as an admin operation that skips allowance\nand the transfer policies (TRANSFER_SENDER/RECEIVER/EXECUTOR_POLICY). It emits, in order:\n\nTransfer(from, to, amount)\nMemo(caller, memo) (a memo of bytes32(0) is allowed)\nSeized(caller, from, to, amount)\n\nRequirements and guards:\n\nRole: the caller must hold SEIZE_ROLE, or the call reverts AccessControlUnauthorizedAccount.\nPause: SEIZE must not be paused, or the call reverts ContractPaused(SEIZE).\nAddresses: to != address(0) and from != to, or the call reverts InvalidReceiver.\nfrom != address(0), or the call reverts InvalidSender.\nHolder gate: from must be blocked under SEIZE_EXEMPT_POLICY, that is, not authorized by\nit, or the call reverts AccountNotSeizable. An unset slot reads as always-allow, so no account\nis seizable until an issuer configures SEIZE_EXEMPT_POLICY.\nDestination gate: to must be authorized under SEIZE_RECEIVER_POLICY, which mirrors\nMINT_RECEIVER_POLICY and is always enforced. But an unset slot is always-allow, so a token can\nseize to any destination (a treasury doesn’t need to be allowlisted) until the slot is set.\nBalance: from’s balance must be >= amount, or the call reverts InsufficientBalance.\n\nWhen multiple guards would fail, they take this precedence: holder gate, then destination gate,\nthen balance. That is, AccountNotSeizable fires before PolicyForbids(SEIZE_RECEIVER_POLICY, ...), which fires before InsufficientBalance.\n​burnBlocked Is Deprecated, but Unchanged and Still Dialable\nburnBlocked(from, amount) keeps working exactly as it does on Beryl:\n\nIt destroys amount from a from blocked under TRANSFER_SENDER_POLICY, without spending an\nallowance. It emits Transfer(from, address(0), amount) and BurnedBlocked(caller, from, amount)\n(no Memo).\nIt’s gated by BURN_BLOCKED_ROLE and the BURN pause vector.\nIt reverts AccountNotBlocked when from is authorized under TRANSFER_SENDER_POLICY.\n\nTo migrate, replace burnBlocked(from, amount) with seizeWithMemo(from, treasury, amount, memo),\nthen call burn(amount) from the treasury if you still want the supply destroyed. This crosses two\npolicy, role, and pause domains (see the edge cases below), so it isn’t a drop-in selector swap.\n​Guarantees and Edge Cases\nQ: Does seize change totalSupply? Is it a burn?\nNo. Seize is a transfer: it reassigns amount from from to to and leaves totalSupply\nuntouched. burnBlocked is the burn: it sends to address(0) and reduces supply. To reproduce the\nold burn-blocked outcome, seize to a treasury or self address, then call burn.\nQ: seizeWithMemo and burnBlocked both target “bad” accounts. Do they read the same set?\nNo, and this is deliberate. seizeWithMemo reads SEIZE_EXEMPT_POLICY. burnBlocked reads\nTRANSFER_SENDER_POLICY. A token can define a seizable set that’s distinct from its\ntransfer-blocked set. In both cases, “eligible” means not authorized by the relevant policy, and an\nunset policy (always-allow) means nobody is eligible.\nQ: Can I pause seize without pausing burns, or vice versa?\nYes. SEIZE (ordinal 3) and BURN (ordinal 2) are independent pause bits. Pausing BURN doesn’t\nstop seizeWithMemo, and pausing SEIZE doesn’t stop burn, burnWithMemo, or burnBlocked.\nQ: Do SEIZE_ROLE and BURN_BLOCKED_ROLE overlap?\nNo. seizeWithMemo requires SEIZE_ROLE. burnBlocked requires BURN_BLOCKED_ROLE. Granting one\ndoesn’t grant the other.\nQ: I never configured the seize policies. What happens if I call seizeWithMemo?\nIt reverts AccountNotSeizable(from) for every from, because an unset SEIZE_EXEMPT_POLICY is\nalways-allow, so no account is seizable. You must configure SEIZE_EXEMPT_POLICY to designate\nseizable holders before seize does anything. (Leaving SEIZE_RECEIVER_POLICY unset simply permits\nany destination.)\nQ: Does seize consult the transfer policies or spend an allowance?\nNo. It’s an admin operation: it bypasses TRANSFER_SENDER/RECEIVER/EXECUTOR_POLICY and allowances,\nand enforces only SEIZE_EXEMPT_POLICY (on from) and SEIZE_RECEIVER_POLICY (on to).\nQ: Is seize available on B20 Stablecoin as well as B20 Asset?\nYes. It’s defined on the shared IB20 surface, so both variants expose the identical\nseizeWithMemo selector, Seized topic0, AccountNotSeizable selector, SEIZE_* getters, and\nSEIZE pause bit at Cobalt.Was this page helpful?Suggest editsRaise issue","tokens":2102,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267860983,"hash":"b8a1e9c0eb68b875ffe8afadef975e90957931d4"}
{"url":"https://ethresear.ch/t/daico-praise-and-critique/1397","domain":"ethresear.ch","title":"DAICO: Praise and Critique - Better ICOs - Ethereum Research","text":"DAICO: Praise and Critique \n\n Better ICOs\n\n medium.com\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n Mar 2018\n\n 1 / 6\n\n Mar 2018\n\n Mar 2018\n\n post by akomba on Mar 15, 2018\n\n akomba\n\n Praise\nVitalik’s DAICO idea was badly needed. It’s really good to see the right message propagated from the top.\nIf I were to describe blockchains in one word, it would be “blockchains make things more accountable”. If I were allowed only a single word, it would be “accountability”.\nThe fact that ICOs don’t do everything they can to keep themselves accountable is a disgrace to the technology and community. So Vitalik highlighting the issue and proposing a solution is very important.\nDAICO\nAccording to the proposal, DAICOs have three extra functionalities, compared to multisig wallets:\n“The Tap”: Owners of the DAICO aren’t able to withdraw all the funds. The DAICO only allows them to withdraw a pre-defined amount per unit time (usually monthly).\n“Opening The Tap” : If the project is doing well, the ICO token holders can increase the monthly allowance by “opening the tap”. However, they can’t reduce it. The process is one way only.\n“Closing Shop”: If the project is not doing well, the ICO token holders can vote to close down the DAICO. In this event all the remaining funds are returned to the current token holders.\nCritique\nThe above proposal is very sensible, and a great step to the right direction. However, it has several weaknesses. I would like to go through them one by one, explain them and propose solutions. The list of weaknesses are below, then a detailed explanation follows.\n\nAutomating The Tap\nPre-Sale Exploits\nPublic Sale Exploits\n“Closing Down” Exploit\nProposed Solutions\n\n1. Automating the Tap\nAsking the community to “open the tap” more every time is not practical.\nFrom one side, a properly planned business will have a sensible and explainable spending curve. It will start low, and then it will increase, according to the business plan. It makes sense to put this expected emission curve into the DAICO, so if the business is going as planned, then there is no action needed from the community.\nThis also deals with the problem that the business might die or miss opportunities because not enough of the community can be bothered to vote to increase the allowance.\nThe possibility for the community intervention to open the tap even more should be still implemented, but only be used under exceptional circumstances, when the company needs to deviate from the plan (spend more, with a good reason).\n2. Pre-Sale Exploits\nThis exploit aims to take away the ability of the token holder community to use the “Closing Shop” option. In principle 51% of the token holders must vote “yes” to close shop.\nThis can be easily circumvented by a fraudulent ICO.\nDuring the pre-sale phase of ICOs there are large percentage of ICO tokens get sold, and it is not always known what the project gets for the tokens. It is inevitable, because pre-sale contributors might pay with cash, fiat currencies, shares, etc. Many of these don’t have a proper representation on the blockchain yet.\nThe exploit is trivial: A fraudulent team might just do a large pre-sale, where they issue near 50% of all tokens to themselves.\nPlease note that they don’t have to own 50%. Much smaller amount is enough to make it difficult for the rest of the token holders to reach consensus. For example the fraudsters running the ICO only issue 25% of the tokens to themselves — now the rest of the community only owns 75%, so the 51% requirement to close down now was increased to 68%.\n3. Public Sale Exploits\nEven if there is no pre-sale, an exploit can be carried out during the public sale as well. A fraudulent group can borrow a significant portion of ether, and buy their own tokens on the public sale.\nAfter the sale they can return the ether gradually from the tap, with interest.\nThis is a less attractive option, but similarly to the pre-sale exploit, it can make the closing down significantly more difficult.\nAlso, there is no financial risk for the lenders, because the ether is there, it just takes time to get to it.\n4. “Closing Down” Exploit\nThis is an interesting variation of the pre-sale exploit. The fraudsters acquire tokens as described in the pre-sale exploit. Then they trigger the close down. They might even apologize — because of reasons, the project can’t continue, but worry not, all eth is accounted for. Except that it’s not true.\nThen money gets returned to the token holders — including them, since they own a large amount of tokens. They go scott free, having made a potentially large profit.\nProposed Solutions\nThe “automating the tap” issue contains its own solution: implement a rising emission curve that is in accordance with the project’s business plan, and supermajority voting to permit extra raises as an exception if properly explained.\nThe other issue — meddling with the shutdown — is more complex. Especially when considering the “Closing Down” exploit. The technical solutions for these are all complex and uncomfortable:\nSolution 1: No Presale\nOne solution is to forbid having a presale. This is technically easy, but business-wise difficult, might even be a deal-breaker. It means that it would be enforced that no special business deals could be made. From an idealistic point of view it is defendable, but realistically thinking it might not always be acceptable. Not all private deals are bad.\nAlso, this does not fix the “public sale” exploit.\nSolution 2: Two Tokens\nAnother natural solution is to mandate that only public sale tokens can be used to vote for the shutdown. Of course, the problem with this is that it implies that we either have two different tokens (presale tokens, public sale tokens) or somehow we make the tokens non-fungible.\nNeither of the options are attractive, not to mention that it is dubious if it could be technically carried out. Think about the madness on the exchanges. This is a no-go.\nAlso, again, this does not address the “Public Sale” exploit.\nSolution 3: A Centralized Shutdown Switch\nAll of the exploits above come from the fact that the number of votes can be manipulated with. There is an obvious solution — using the existing legal framework.\nBy creating a special account that can be proven to be able to shut down the DAICO, and return the funds to the token holders. Then depositing this key with a known, independent party (lawyer, etc).\nIn case of fraud, a lawsuit can be launched and the key can be demanded. This shutdown switch would not replace the community’s ability to close the shop, it would be added as an extra feature.\nThe purpose of an ICOs is to raise funds in an accountable, yet easy manner. The purpose of an ICO is not to be above the law. Almost all projects or companies should be exposed to the extant legal processes. The backend key could expire after some period of time.\nConclusion\nDAICO is needed, great step to the right direction\nShould use an emission curve instead of asking the community to increase the tap\nCreate a centralized shutdown switch that can be activated by a legal process.\nThere are other steps that we can take to make ICOs more accountable. For example tokenizing the pre-ICO deals and fiat currencies. I will expand on those and propose a full solution in the upcoming post.\nThanks go to Virgil Griffith for the review and suggestions.\nOriginal post: https://medium.com/@akomba/daico-praise-and-critique-2c5bcee2acfe\n\n ICO Control Tokens\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n post by vbuterin on Mar 15, 2018\n\n vbuterin\n\n I fail to understand how (4) is an exploit. Sure, holders can close a project down and get their tokens back. But where does their “potentially large profit” come from? Are you saying that this would happen if ETH suddenly appreciates a lot after a sale? If so, then I agree that could be a problem but I think the easiest solution is to denominate the DAICO in DAI.\nIn general, I would argue that in a “good” sale, public sales should make up a great supermajority of all token issuance. If some tokens need to be held back for future sales, that can be done by simply not issuing them until the time for the future sale comes. In fact, you can even require a future sale to be one of the events that the DAICO token holders need to vote to unlock.\n\nAsking the community to “open the tap” more every time is not practical. From one side, a properly planned business will have a sensible and explainable spending curve. It will start low, and then it will increase, according to the business plan.\n\nThere is a tradeoff here. In principle, I agree that allowing taps to be dynamic curves instead of numbers is ideal and allows for more options. That said, requiring explicit public approval for each step of growth has benefits; it creates more choke points where people can demand accountability. There is an inevitable tradeoff here, and it’s not yet clear what the ideal point on it is.\n\nSolution 3: A Centralized Shutdown Switch\n\nAre you suggesting a centralized shutdown switch in place of, or alongside, the token holder voted switch. If it’s in place of, I would argue that that’s a bad idea, because in general legal systems are designed for detecting malfeasance, not underperformance, and we want DAICOs to be shut down in the event of underperformance too. If alongside, then shutdown attacks by voters could still happen (if you’re worried about shutdown attacks; I personally am not that worried, as in the event of a fraudulent shutdown the developers can just restart the DAICO).\n\n post by akomba on Mar 15, 2018\n\n akomba\n\nExample: BadICO issues 50% of the tokens for themselves in the presale. They sell the other 50% for 100 eth. Then they activate the shutdown switch and the 100 eth gets distributed among the 100% of the token holders, thus netting them 50 eth.\n\nAlongside. You are right, I will make that more clear.\n\n post by vbuterin on Mar 15, 2018\n\n vbuterin\n\nExample: BadICO issues 50% of the tokens for themselves in the presale. They sell the other 50% for 100 eth. Then they activate the shutdown switch and the 100 eth gets distributed among the 100% of the token holders, thus netting them 50 eth.\n\nThis is an excellent argument for not giving non-public-sale-participants liquid tokens, at least until the DAICO runs out.\n\n post by clesaege on Mar 15, 2018\n\n clesaege\n\nTo solve this, we could have two tokens, the utility one and the DAICO one. In order to vote, we would need both the utility and the DAICO tokens. Presale and teams would only get utility tokens. DAICO tokens, not matched with the utility one would be worthless, we can even simplify transfers by wrapping both of them into a combined token.\n\n post by akomba on Mar 16, 2018\n\n akomba\n\n I like this.\nSince I wrote the original article, I came up with a similar solution: Everyone gets the ICO tokens, but control tokens only gets handed out during the public sale. So only being a public sale supporter gives you the privilege to approve / shutdown.\nThen it’s only up to that public-sale-contributor person if they want to give up / sell that right (aka sell the control token).\nI originally did not think of tying the voting rights to having both tokens. But the more I think about it the more I like the idea.\n\n Powered by Discourse","tokens":2829,"squid":"ink-research","role":"Deep Scholar","at":1791267864019,"hash":"e768d3a88f05ac5e4e321bfa0d387327e837e87a"}
{"url":"https://blog.ethereum.org/","domain":"blog.ethereum.org","title":"Home | Ethereum Foundation Blog","text":"October 5, 2026R&DHow native transaction assertions could enforce a transaction's final outcomeby Ethereum Foundation Access Cluster\nThe Ethereum Foundation's Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as a user experience risk, and is exploring native transaction assertions as a next step to enforce a transaction’s final outcome, alongside Clear Signing.\n\nThis post covers why a valid signature doesn't always guarantee the transaction result you wanted, how native transaction assertions could protect users where today's defenses stop, and the design choices behind them, with EIP-7906 (Transaction Assertions via State Diff Opcode) as one possible approach.\nOctober 1, 2026R&DIntroducing zkAPI: private usage credits for any APIby Vittorio Rivabella, dAI Team\ntl;dr: zkAPI lets you pay for a metered API without being known. Deposit credits into an Ethereum vault once, then authorize bounded usage with zero-knowledge proofs instead of an identity. The provider sees the requests, and the payment layer sees the spend. Neither learns the link between them.\n\nThe Open Anonymity Project built it with the Ethereum Foundation, and it runs on Ethereum Mainnet today.\nSeptember 28, 2026ProtocolGlamsterdam Testnet Announcementby Protocol\nGlamsterdam follows the Fusaka upgrade, advancing Ethereum's L1 scaling roadmap with enshrined proposer-builder separation, block-level access lists, and changes to gas pricing that better reflect the cost of execution and state growth.\n\nThe Glamsterdam network upgrade is scheduled to activate on Sepolia at epoch 353,024, slot 11,296,768 (October 6, 2026, 13:53:36 UTC). See the activation table below for the deployment schedule. Hoodi and mainnet activation dates have not yet been decided.\n\nSepolia-compatible client versions will be added to the client release tables as they are confirmed. Node operators must update both their execution and consensus layer clients before activation.\nSeptember 9, 2026R&DJoin Us: EF Protocol Reddit AMA - September 16th, 2026by Ethereum Foundation Protocol Cluster\nEvery year since January 2019, teams from the Ethereum Foundation have spent an afternoon or two on r/ethereum answering questions from the community. The format hasn’t really changed: one thread, technical debates, detailed explanations, and community members asking whatever is on their mind. By now it is a tradition, and one of the more direct ways for the broader Ethereum community to hear from the people working on Ethereum's core development.\n\nThe next session takes place on September 16th, with researchers and devs from the Protocol cluster answering your questions.\n\nThe Glamsterdam hard fork is in public testing, the scope of Hegotá is being narrowed down, and the shape of the work beyond both upgrades is still being settled, so there is plenty to ask about.\n\nQuestions mightSeptember 7, 2026R&DEF Protocol: The Hegotá EIP Opinion Post and Tier Listby Ethereum Foundation Protocol Cluster\nThis is the EF Protocol cluster’s tier list for Hegotá. We evaluated the 62 EIPs proposed for inclusion, each with a tier and a short note on the grade.\n\nIt is the first time the cluster has published one unified view rather than per-team opinions. Geth, of course, being an EL client will still ship their own standalone tier list. However, they and the rest of the Protocol cluster (about 60 people in total) across research and engineering worked together to include their feedback in this post as a datapoint along with that of every other team and individual contributor that decided to participate.\n\nThe priorities that produced these grades are in the companion post, EF Protocol: Current and Emerging Priorities.\nSeptember 7, 2026R&DEF Protocol: Current and Emerging Prioritiesby Ethereum Foundation Protocol Cluster\nIn May, the Protocol cluster welcomed a trio of new cluster coordinators and promised updates to follow.\n\nAfter months of settling in and aligning with contributors cluster-wide, across the EF and across the Ethereum ecosystem, we are now happy to share Protocol's priorities: what Protocol is for, the commitments that govern its work through 2029, and what those commitments require of the forks now entering scope.\n\nWith Glamsterdam approaching mainnet, Protocol has entered the Hegotá scoping season. We used the process described in an August 28 post: 62 EIPs proposed for inclusion, multiple Glamsterdam retrospectives, 16 contribution templates, and several cluster-wide working sessions. That process helped roughly 60 researchers and engineers to determine a shared set of priorities. Those priorities cover the longer-term roadmap and areAugust 24, 2026R&DGlamsterdam Repricing Impact for Smart Contract Developersby Ethereum Foundation Protocol Research, EthPandaOps, and Specifications teamsAugust 20, 2026R&DRaising machine-checked security benchmarks to advance hash-based SNARKs through agentic collaborationby Ethereum Foundation Formal Verification team\nbetter.codes, an open autoresearch challenge built by the Ethereum Foundation Formal Verification team in collaboration with Yukon and zkSecurity, is now live.\n\nbetter.codes takes a self-contained problem from the Proximity Prize research, formalized in Lean, and puts its soundness bound on a public leaderboard that anyone can push forward.\n\nSolvers point their own AI agents at raising the machine-checked soundness bound of koalaIRS12, a Reed–Solomon proximity problem to advance modern succinct non-interactive proof systems (SNARKs).\n\nThe Lean kernel checks every submission and each promoted proof raises the bound toward the fixed 128-bit target. Each promoted proof’s new lemmas, proof techniques, and impossibility results are then upstreamed to advance progress for all solvers and agents.\nAugust 18, 2026ESPAllocation Update - Q2 2026by Ecosystem Support Program Team\nQ2 2026 carried forward our focus on advancing Ethereum’s resilience and capabilities, supporting key work in zero-knowledge proofs, client diversity, formal verification, and open-source tooling. See the list below of the projects and ecosystem efforts supported this quarter as builders build and strengthen the network.\n\nExplore the full list of EF Funded Projects on the ESP website here!!\n\nNewer postsOlder posts","tokens":1574,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267864207,"hash":"ce0260a42b9175f99ddb0f1b3fbe76e03836c019"}
{"url":"https://docs.base.org/upgrades/denim/overview","domain":"docs.base.org","title":"Overview - Base Documentation","text":"StatusDateSepoliaPlanningOctober 2026MainnetPlanningNovember 2026\n​Features\n200ms Native BlocksBase · RPCDenim moves Base block production from one canonical block every two seconds to five complete canonical blocks per second, each with its own hash, state root, receipts, and forkchoice lifecycle. Denim replaces Flashblocks, so applications using Flashblocks must migrate to canonical block and RPC streams. See 200ms Native Blocks and Migrate From Flashblocks.BaseTimeBase · PredeployDenim adds onchain millisecond time through the BaseTime predeploy. A BaseTime metadata deposit supplies the sub-second component of each block’s timestamp, letting contracts read the current block’s millisecond part while EVM block.timestamp stays seconds-based.Millisecond RPC TimestampsBase · RPCBlock, header, transaction, log, and receipt responses gain optional millisecond-resolution timestamp fields (timestampMs, blockTimestampMs), derived from authenticated BaseTime metadata. The existing seconds-based timestamp field is unchanged for backward compatibility.B20 ImprovementsBase · PrecompileDenim tightens B20 transfer rules and extends PolicyRegistry: transfers, mints, and seizes to the token’s own address revert, TRANSFER_EXECUTOR_POLICY applies to every transfer path, and any policy can be inverted with a NOT flag. See Token Receiver, Transfer Executor Enforcement, and NOT / Invert Policies.Was this page helpful?Suggest editsRaise issue","tokens":361,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791267871150,"hash":"adeff2e20a56b3dffaf5437b6f23ae1eebf8b913"}
{"url":"https://blog.ethereum.org/category/research-and-development","domain":"blog.ethereum.org","title":"Research & Development | Ethereum Foundation Blog","text":"Research & DevelopmentAnnouncements related to research and development of the Ethereum protocol.October 5, 2026R&DHow native transaction assertions could enforce a transaction's final outcomeby Ethereum Foundation Access Cluster\nThe Ethereum Foundation's Trillion Dollar Security initiative has identified blind signing and transaction uncertainty as a user experience risk, and is exploring native transaction assertions as a next step to enforce a transaction’s final outcome, alongside Clear Signing.\n\nThis post covers why a valid signature doesn't always guarantee the transaction result you wanted, how native transaction assertions could protect users where today's defenses stop, and the design choices behind them, with EIP-7906 (Transaction Assertions via State Diff Opcode) as one possible approach.\nOctober 1, 2026R&DIntroducing zkAPI: private usage credits for any APIby Vittorio Rivabella, dAI Team\ntl;dr: zkAPI lets you pay for a metered API without being known. Deposit credits into an Ethereum vault once, then authorize bounded usage with zero-knowledge proofs instead of an identity. The provider sees the requests, and the payment layer sees the spend. Neither learns the link between them.\n\nThe Open Anonymity Project built it with the Ethereum Foundation, and it runs on Ethereum Mainnet today.\nSeptember 9, 2026R&DJoin Us: EF Protocol Reddit AMA - September 16th, 2026by Ethereum Foundation Protocol Cluster\nEvery year since January 2019, teams from the Ethereum Foundation have spent an afternoon or two on r/ethereum answering questions from the community. The format hasn’t really changed: one thread, technical debates, detailed explanations, and community members asking whatever is on their mind. By now it is a tradition, and one of the more direct ways for the broader Ethereum community to hear from the people working on Ethereum's core development.\n\nThe next session takes place on September 16th, with researchers and devs from the Protocol cluster answering your questions.\n\nThe Glamsterdam hard fork is in public testing, the scope of Hegotá is being narrowed down, and the shape of the work beyond both upgrades is still being settled, so there is plenty to ask about.\n\nQuestions mightSeptember 7, 2026R&DEF Protocol: The Hegotá EIP Opinion Post and Tier Listby Ethereum Foundation Protocol Cluster\nThis is the EF Protocol cluster’s tier list for Hegotá. We evaluated the 62 EIPs proposed for inclusion, each with a tier and a short note on the grade.\n\nIt is the first time the cluster has published one unified view rather than per-team opinions. Geth, of course, being an EL client will still ship their own standalone tier list. However, they and the rest of the Protocol cluster (about 60 people in total) across research and engineering worked together to include their feedback in this post as a datapoint along with that of every other team and individual contributor that decided to participate.\n\nThe priorities that produced these grades are in the companion post, EF Protocol: Current and Emerging Priorities.\nSeptember 7, 2026R&DEF Protocol: Current and Emerging Prioritiesby Ethereum Foundation Protocol Cluster\nIn May, the Protocol cluster welcomed a trio of new cluster coordinators and promised updates to follow.\n\nAfter months of settling in and aligning with contributors cluster-wide, across the EF and across the Ethereum ecosystem, we are now happy to share Protocol's priorities: what Protocol is for, the commitments that govern its work through 2029, and what those commitments require of the forks now entering scope.\n\nWith Glamsterdam approaching mainnet, Protocol has entered the Hegotá scoping season. We used the process described in an August 28 post: 62 EIPs proposed for inclusion, multiple Glamsterdam retrospectives, 16 contribution templates, and several cluster-wide working sessions. That process helped roughly 60 researchers and engineers to determine a shared set of priorities. Those priorities cover the longer-term roadmap and areAugust 24, 2026R&DGlamsterdam Repricing Impact for Smart Contract Developersby Ethereum Foundation Protocol Research, EthPandaOps, and Specifications teamsAugust 20, 2026R&DRaising machine-checked security benchmarks to advance hash-based SNARKs through agentic collaborationby Ethereum Foundation Formal Verification team\nbetter.codes, an open autoresearch challenge built by the Ethereum Foundation Formal Verification team in collaboration with Yukon and zkSecurity, is now live.\n\nbetter.codes takes a self-contained problem from the Proximity Prize research, formalized in Lean, and puts its soundness bound on a public leaderboard that anyone can push forward.\n\nSolvers point their own AI agents at raising the machine-checked soundness bound of koalaIRS12, a Reed–Solomon proximity problem to advance modern succinct non-interactive proof systems (SNARKs).\n\nThe Lean kernel checks every submission and each promoted proof raises the bound toward the fixed 128-bit target. Each promoted proof’s new lemmas, proof techniques, and impossibility results are then upstreamed to advance progress for all solvers and agents.\nJuly 9, 2026R&DThe triage is the product: running AI agents against Ethereum's protocol codeby Nikos Baxevanis\nNotes from the Ethereum Foundation's Protocol Security team on running coordinated AI agents against real protocol code, including how we organize the work, what holds up under scrutiny, and what client teams and security researchers can take from it. This post stands on its own; later posts will go deeper on individual clients.\nNewer postsOlder posts","tokens":1400,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267874139,"hash":"6ff5a1fbe00dd975dc6ec7d66cd8cfd426f07027"}
{"url":"https://ethresear.ch/t/daico-praise-and-critique/1397/6","domain":"ethresear.ch","title":"DAICO: Praise and Critique - Better ICOs - Ethereum Research","text":"Better ICOs\n\n medium.com\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n Mar 2018\n\n 6 / 6\n\n Mar 2018\n\n Mar 2018\n\n post by akomba on Mar 15, 2018\n\n akomba\n\n Praise\nVitalik’s DAICO idea was badly needed. It’s really good to see the right message propagated from the top.\nIf I were to describe blockchains in one word, it would be “blockchains make things more accountable”. If I were allowed only a single word, it would be “accountability”.\nThe fact that ICOs don’t do everything they can to keep themselves accountable is a disgrace to the technology and community. So Vitalik highlighting the issue and proposing a solution is very important.\nDAICO\nAccording to the proposal, DAICOs have three extra functionalities, compared to multisig wallets:\n“The Tap”: Owners of the DAICO aren’t able to withdraw all the funds. The DAICO only allows them to withdraw a pre-defined amount per unit time (usually monthly).\n“Opening The Tap” : If the project is doing well, the ICO token holders can increase the monthly allowance by “opening the tap”. However, they can’t reduce it. The process is one way only.\n“Closing Shop”: If the project is not doing well, the ICO token holders can vote to close down the DAICO. In this event all the remaining funds are returned to the current token holders.\nCritique\nThe above proposal is very sensible, and a great step to the right direction. However, it has several weaknesses. I would like to go through them one by one, explain them and propose solutions. The list of weaknesses are below, then a detailed explanation follows.\n\nAutomating The Tap\nPre-Sale Exploits\nPublic Sale Exploits\n“Closing Down” Exploit\nProposed Solutions\n\n1. Automating the Tap\nAsking the community to “open the tap” more every time is not practical.\nFrom one side, a properly planned business will have a sensible and explainable spending curve. It will start low, and then it will increase, according to the business plan. It makes sense to put this expected emission curve into the DAICO, so if the business is going as planned, then there is no action needed from the community.\nThis also deals with the problem that the business might die or miss opportunities because not enough of the community can be bothered to vote to increase the allowance.\nThe possibility for the community intervention to open the tap even more should be still implemented, but only be used under exceptional circumstances, when the company needs to deviate from the plan (spend more, with a good reason).\n2. Pre-Sale Exploits\nThis exploit aims to take away the ability of the token holder community to use the “Closing Shop” option. In principle 51% of the token holders must vote “yes” to close shop.\nThis can be easily circumvented by a fraudulent ICO.\nDuring the pre-sale phase of ICOs there are large percentage of ICO tokens get sold, and it is not always known what the project gets for the tokens. It is inevitable, because pre-sale contributors might pay with cash, fiat currencies, shares, etc. Many of these don’t have a proper representation on the blockchain yet.\nThe exploit is trivial: A fraudulent team might just do a large pre-sale, where they issue near 50% of all tokens to themselves.\nPlease note that they don’t have to own 50%. Much smaller amount is enough to make it difficult for the rest of the token holders to reach consensus. For example the fraudsters running the ICO only issue 25% of the tokens to themselves — now the rest of the community only owns 75%, so the 51% requirement to close down now was increased to 68%.\n3. Public Sale Exploits\nEven if there is no pre-sale, an exploit can be carried out during the public sale as well. A fraudulent group can borrow a significant portion of ether, and buy their own tokens on the public sale.\nAfter the sale they can return the ether gradually from the tap, with interest.\nThis is a less attractive option, but similarly to the pre-sale exploit, it can make the closing down significantly more difficult.\nAlso, there is no financial risk for the lenders, because the ether is there, it just takes time to get to it.\n4. “Closing Down” Exploit\nThis is an interesting variation of the pre-sale exploit. The fraudsters acquire tokens as described in the pre-sale exploit. Then they trigger the close down. They might even apologize — because of reasons, the project can’t continue, but worry not, all eth is accounted for. Except that it’s not true.\nThen money gets returned to the token holders — including them, since they own a large amount of tokens. They go scott free, having made a potentially large profit.\nProposed Solutions\nThe “automating the tap” issue contains its own solution: implement a rising emission curve that is in accordance with the project’s business plan, and supermajority voting to permit extra raises as an exception if properly explained.\nThe other issue — meddling with the shutdown — is more complex. Especially when considering the “Closing Down” exploit. The technical solutions for these are all complex and uncomfortable:\nSolution 1: No Presale\nOne solution is to forbid having a presale. This is technically easy, but business-wise difficult, might even be a deal-breaker. It means that it would be enforced that no special business deals could be made. From an idealistic point of view it is defendable, but realistically thinking it might not always be acceptable. Not all private deals are bad.\nAlso, this does not fix the “public sale” exploit.\nSolution 2: Two Tokens\nAnother natural solution is to mandate that only public sale tokens can be used to vote for the shutdown. Of course, the problem with this is that it implies that we either have two different tokens (presale tokens, public sale tokens) or somehow we make the tokens non-fungible.\nNeither of the options are attractive, not to mention that it is dubious if it could be technically carried out. Think about the madness on the exchanges. This is a no-go.\nAlso, again, this does not address the “Public Sale” exploit.\nSolution 3: A Centralized Shutdown Switch\nAll of the exploits above come from the fact that the number of votes can be manipulated with. There is an obvious solution — using the existing legal framework.\nBy creating a special account that can be proven to be able to shut down the DAICO, and return the funds to the token holders. Then depositing this key with a known, independent party (lawyer, etc).\nIn case of fraud, a lawsuit can be launched and the key can be demanded. This shutdown switch would not replace the community’s ability to close the shop, it would be added as an extra feature.\nThe purpose of an ICOs is to raise funds in an accountable, yet easy manner. The purpose of an ICO is not to be above the law. Almost all projects or companies should be exposed to the extant legal processes. The backend key could expire after some period of time.\nConclusion\nDAICO is needed, great step to the right direction\nShould use an emission curve instead of asking the community to increase the tap\nCreate a centralized shutdown switch that can be activated by a legal process.\nThere are other steps that we can take to make ICOs more accountable. For example tokenizing the pre-ICO deals and fiat currencies. I will expand on those and propose a full solution in the upcoming post.\nThanks go to Virgil Griffith for the review and suggestions.\nOriginal post: https://medium.com/@akomba/daico-praise-and-critique-2c5bcee2acfe\n\n ICO Control Tokens\n\n 3\n\n 2\n\n read \n\n 4\n min\n\n post by vbuterin on Mar 15, 2018\n\n vbuterin\n\n I fail to understand how (4) is an exploit. Sure, holders can close a project down and get their tokens back. But where does their “potentially large profit” come from? Are you saying that this would happen if ETH suddenly appreciates a lot after a sale? If so, then I agree that could be a problem but I think the easiest solution is to denominate the DAICO in DAI.\nIn general, I would argue that in a “good” sale, public sales should make up a great supermajority of all token issuance. If some tokens need to be held back for future sales, that can be done by simply not issuing them until the time for the future sale comes. In fact, you can even require a future sale to be one of the events that the DAICO token holders need to vote to unlock.\n\nAsking the community to “open the tap” more every time is not practical. From one side, a properly planned business will have a sensible and explainable spending curve. It will start low, and then it will increase, according to the business plan.\n\nThere is a tradeoff here. In principle, I agree that allowing taps to be dynamic curves instead of numbers is ideal and allows for more options. That said, requiring explicit public approval for each step of growth has benefits; it creates more choke points where people can demand accountability. There is an inevitable tradeoff here, and it’s not yet clear what the ideal point on it is.\n\nSolution 3: A Centralized Shutdown Switch\n\nAre you suggesting a centralized shutdown switch in place of, or alongside, the token holder voted switch. If it’s in place of, I would argue that that’s a bad idea, because in general legal systems are designed for detecting malfeasance, not underperformance, and we want DAICOs to be shut down in the event of underperformance too. If alongside, then shutdown attacks by voters could still happen (if you’re worried about shutdown attacks; I personally am not that worried, as in the event of a fraudulent shutdown the developers can just restart the DAICO).\n\n post by akomba on Mar 15, 2018\n\n akomba\n\nExample: BadICO issues 50% of the tokens for themselves in the presale. They sell the other 50% for 100 eth. Then they activate the shutdown switch and the 100 eth gets distributed among the 100% of the token holders, thus netting them 50 eth.\n\nAlongside. You are right, I will make that more clear.\n\n post by vbuterin on Mar 15, 2018\n\n vbuterin\n\nExample: BadICO issues 50% of the tokens for themselves in the presale. They sell the other 50% for 100 eth. Then they activate the shutdown switch and the 100 eth gets distributed among the 100% of the token holders, thus netting them 50 eth.\n\nThis is an excellent argument for not giving non-public-sale-participants liquid tokens, at least until the DAICO runs out.\n\n post by clesaege on Mar 15, 2018\n\n clesaege\n\nTo solve this, we could have two tokens, the utility one and the DAICO one. In order to vote, we would need both the utility and the DAICO tokens. Presale and teams would only get utility tokens. DAICO tokens, not matched with the utility one would be worthless, we can even simplify transfers by wrapping both of them into a combined token.\n\n post by akomba on Mar 16, 2018\n\n akomba\n\n I like this.\nSince I wrote the original article, I came up with a similar solution: Everyone gets the ICO tokens, but control tokens only gets handed out during the public sale. So only being a public sale supporter gives you the privilege to approve / shutdown.\nThen it’s only up to that public-sale-contributor person if they want to give up / sell that right (aka sell the control token).\nI originally did not think of tying the voting rights to having both tokens. But the more I think about it the more I like the idea.\n\n Powered by Discourse","tokens":2822,"squid":"ink-research","role":"Deep Scholar","at":1791267875481,"hash":"0211651d493993ffbf200a7ed3550e0a3b988de2"}
{"url":"https://blog.ethereum.org/2026/09/07/protocol-hegota-eips","domain":"blog.ethereum.org","title":"EF Protocol: The Hegotá EIP Opinion Post and Tier List | Ethereum Foundation Blog","text":"EF Protocol: The Hegotá EIP Opinion Post and Tier ListThe EF Protocol cluster’s tier list for Hegotá evaluates 62 proposed EIPs in a unified view.Posted by Ethereum Foundation Protocol Cluster on September 7, 2026Research & DevelopmentThis is the EF Protocol cluster’s tier list for Hegotá. We evaluated the 62 EIPs proposed for inclusion, each with a tier and a short note on the grade.\nIt is the first time the cluster has published one unified view rather than per-team opinions. Geth, of course, being an EL client will still ship their own standalone tier list. However, they and the rest of the Protocol cluster (about 60 people in total) across research and engineering worked together to include their feedback in this post as a datapoint along with that of every other team and individual contributor that decided to participate.\nThe priorities that produced these grades are in the companion post, EF Protocol: Current and Emerging Priorities.\nI. How we tiered\nAll nine teams plus several individual domain experts across the cluster filled out contribution templates, 16 in total. Twelve provided tier grades, and several of those graded only EIPs where they had deep expertise. The result is 397 tier grades across 62 EIPs, an average of 6.4 grades per EIP with the most-discussed proposals drawing 9 grades.\nTwo retrospectives on Glamsterdam supplied several lessons (size an EIP by its integration depth; complexity compounds; testing surface is the scarce resource; champions often underestimate complexity). Half a dozen group calls and a 90-minute working session covered the contested items. The August 28 process post provides a bit more detail.\nThe scoring\nEach contributor tiered each EIP independently: S = 4, A = 3, B = 2, C = 1, D/DFI = 0. Averages count cast grades only; an abstention never counts against a proposal. The published tier is a steelman. It started from the grades and was argued EIP-by-EIP in the working session, with movements in both directions. Per-team grades are not published.\nEach level of the tiered scoring ladder commits the cluster to delivery expectations:\n\nS - Must ship. Defines the fork. If an S item is at risk, the schedule adjusts before the scope does.\n\nA - High priority, expected to ship. Committed alongside S-tier unless delivery reality forces a cut, and only cut before any S item is touched. Everything below S and A-tier must be evaluated once devnets with all S and A-tier EIPs are functional and stable.\n\nB - On the bubble, included individually. Never admitted in bulk. Each EIP to be considered for inclusion one at a time once devnets with all S and A-tier EIPs are functional and stable and time remains before moving to I*. Important to note, most B-tiered EIPs carry 3 explicit requirements: a prototype, a sign-off, and a settled specification.\n\nC - Below the line, not disqualified. First candidates for reconsideration if devnets containing S-, A-, and B-tier EIPs ship cleanly and time remains before moving to I*.\n\nDFI - Declined for inclusion. Every DFI carries a structural rationale, like that the EIP is antithetical to CROPS, a security risk, too prescriptive, introduces an intermediary or chokepoint, breaks backward compatibility, or endangers the path to J*.\n\nTBD - Deliberately unranked. Held back until mainnet data provides answers to questions we cannot answer today.\n\nThe note in the notes column of the table for each EIP below should adhere to the following pattern: For anything we expect to ship, the note provides the merits. For anything on the bubble, it names the specific requirements that would move it up a tier. For anything below the line or declined, it gives the concerns and nothing else.\nII. The tier list\nThe full list as a single visual is on Forkcast. The tables below are sorted by tier, then by average within each tier. Read the grade count beside every average.\nConsensus layer\n\nEIPNameTierAvg (total)CategoryNotes7805FOCILS4 (7)HeadlinerLocked-in CL headliner. FOCIL gives any user a path to include an eligible transaction without relying on centralised builders. Unanimous S at full participation. Should ship with EIP-8369.8369VOPS Profiles for FOCIL EligibilityA3.5 (4)Frames coreDefines which transactions are eligible for FOCIL and what validators must verify, extending its inclusion guarantees to Frames.8015Remove Deposit and eth1data FieldsA3.14 (7)Cleanup & deprecationsRemoves dead deposit and eth1data fields with no downstream dependency. Near-unanimous.8365BLS Withdrawal Credential RetirementA3 (8)Staking featuresStarts retiring withdrawal credentials tied to vulnerable cryptography now; nothing downstream depends on waiting. The one PQ item that belongs in Hegotá.8383Reduce CL Block Retention WindowA3 (2)History and logsA constant change, and the current safety-decay constant was the wrong choice. Two grades cast, both A. One of two write-ins evaluated alongside the Forkcast list.8334Bundled Attestation PropagationA2.43 (7)AttestationsBundling attestation propagation cuts gossip load with a small surface. No grade below B; bundling mechanics are settled in specification.8025Optional Execution ProofsA2.38 (8)DA & proofsUpstreams stateless-execution changes into the canonical execution specs so zkVM work stops living on divergent branches.8146Block Access List SidecarsB2.13 (8)Block propagation & validationThe payload stays independent of the BAL for execution, the deadline is observation-only and tunable across forks, and both objects must be available for validity, as with blobs. What remains is settling the observation deadline in specification; with that settled, the case for A-tier is strong.8237Independent CL/EL SyncB2 (6)Sync & history retentionThe bandwidth saving is worth exploring: post-ePBS, payload bodies download on both layers, and skipping one roughly halves sync bandwidth. A simpler non-EIP alternative may capture the same win. A comparison between both options should determine which ships.8198Quick SlotsB2 (6)Consensus & fork choiceS/A support came from R&D; the Engineering teams that focus on delivery rated it D, citing the retuning cascade behind any slot-time change. After debate, it was determined four things would be required before an A-tier could be considered: 1) specifications covering all expected changes to the core protocol 2) a prototype implementing that full specification 3) an in-depth assessment of downstream effects across the ecosystem 4) sign-off that it does not complicate decoupled consensus, which cannot be determined until that specification exists.8321Hash-Chain RANDAOB1.57 (7)Consensus & fork choiceSound direction, wrong sequencing: hardening one consensus component ahead of the complete PQ consensus design risks rework. It moves when the complete design exists and either adopts or extends it.8371RowDAS: Distributed Blob ReconstructionC2.11 (9)DA & proofsPriority, not principle: whether operators feel reconstruction pain today versus investing in headroom.8379Top-up SyncDFI1 (2)Sync & history retention-7716Anti-Correlation Attestation PenaltiesDFI0.83 (6)Rewards & penaltiesEIP-7716 increases penalties for correlated missed attestations. The impact on the current and future staker landscape, how effectively it reduces centralization forces, and edge cases such as multi-client setups that pause together during client disagreement all need more research and community discussion first. EIP-7716 is a good idea, but not a high priority in a fork where we are keeping CL scope light.8367Balance Sunset for Retired BLS ValidatorsDFI0.71 (7)Staking featuresReads as validator convenience to some and PQ hygiene to others; either way it waits for the complete PQ consensus design.8243Batching Attestations at SourceDFI0.67 (9)AttestationsNo S or A grade. Attestation batching belongs with the slot-structure work decoupled consensus will redo.8333Align Checkpoint with Epoch Boundary BlockDFI0.5 (6)Consensus & fork choiceEarly support collapsed once its interaction with decoupled consensus was examined; unclear if behavior under the consensus redesign it would have to survive.8142Block-in-Blobs (BiB)DFI0 (7)DA & proofsDeepens dependence on KZG structures against the path to J*. Unanimous.8148Custom Sweep Threshold for ValidatorsDFI0 (6)Staking featuresOperational convenience primarily serving large staking operations; fails the necessity bar. Unanimous.8205Withdrawal Credentials PreregistrationDFI0 (6)Staking featuresSame rationale as EIP-8148. Unanimous.8359Beacon Block Reporting FieldDFI0 (6)Beacon block dataGraffiti watermarking and node scraping is sufficient for right now; fails the necessity bar. Unanimous.8375ePBS Mandatory Burn of Execution RewardsDFI0 (6)Rewards & penaltiesReward policy belongs to a broader ecosystem process than a fork scoping exercise. Unanimous. See EIP-8363 and the closing note.8341Partial Execution Payload CommitmentsDFI0 (4)Beacon block dataA payload-commitment change with no delivery owner and unclear interaction with the consensus redesign. Unanimous.8363Tapered Issuance BurnDFI0 (4)Rewards & penaltiesIssuance policy belongs to a broader ecosystem process than a fork scoping exercise. Unanimous, and not a judgment on the merits; see the closing note.\nExecution layer\n\nEIPNameTierAvg (total)CategoryNotes8141Frame TransactionsS3.89 (9)HeadlinerLocked-in EL headliner. Native account abstraction on security grounds: a path to PQ signature schemes without a fork per scheme, aggregation so PQ verification can be priced, and a route to retiring k1 keys. Ships with EIP-8250 and EIP-8272.3298Removal of RefundsA3.17 (6)RepricingDeletes an entire class of metering edge cases that the last fork paid for dearly.8250Keyed Nonces for Frame TransactionsA3.12 (8)Frames coreFrames core. Keyed nonces let many users share one sender for better anonymity while using separate nonces, so their transactions do not block one another.5920PAY OpcodeA3 (6)EVM featureA small new feature that closes a long-standing issue: value transfer without invoking recipient code. Low surface, high leverage.8272Recent Roots for Frame TransactionsA2.86 (7)Frames coreFrames core. Recent roots let private transactions use recent onchain state in a form attesters can verify, allowing them to benefit from FOCIL’s inclusion guarantees.8279Block Access List Byte FloorA2.71 (7)RepricingBounds worst-case block construction: floors adversarial BAL pricing so the worst case becomes gas_limit divided by the floor cost. Security work, graded with EIP-8131. Spending any headroom is a separate, later decision.8131Unified Transaction Content FloorA2.67 (6)RepricingThe other half of the bounding pair with EIP-8279, applied to calldata content. Graded as security work. Whether it counts as bounding or repricing is a live definitional question; the grade does not depend on the answer.7906Transaction Assertions via State Diff OpcodeA2.43 (7)Frames extensionsLets a transaction verify what happened before it commits, preventing wallet drains and classes of MEV extraction; currently running with Frames on a public devnet. Proposed narrowing pending further research: arbitrary storage reads removed, assertions over emitted events and BAL-touched slots deliver the value. Graded as part of the Frames extension package, alongside EIP-8298 and EIP-8151.8298SETCODEFROM Code Reuse InstructionA2.17 (6)AA & delegationHalf of the k1-retirement package with EIP-8151: a 7702-delegated account becomes a true smart-contract account and drops k1 as its master key. Also cuts deployment cost after Glamsterdam’s CREATE repricing.8151Account Code Restricted ecRecoverA2 (6)AA & delegationThe other half of the k1 exit with EIP-8298: once real code lives at an address, ecRecover-based authentication is rejected and a retired key stops being dangerous. One package, one grade.4758Deactivate SELFDESTRUCTA1.5 (6)Cleanup & deprecationsRemoves the last SELFDESTRUCT path, a testing hazard every future EIP must otherwise define its interaction with; Frames is simpler without it. The 1.5 average sits well below A. The override rests on the Engineering seats that maintain the EVM and would carry the opcode’s cost indefinitely.8253Bump Nonce of Zero-Nonce Storage AccountsB2.29 (7)State transitionThe trie migration can technically proceed without it, and it simplifies every migration step significantly. Whether that simplification earns A-tier now or B-tier until devnet sequencing proves there is room is the one question left on it.8077eth/XX: Announce Transactions with NonceB2 (5)Mempool & tx propagationMany want richer announcements for the Frames-era mempool; nothing forces the shape into Hegotá before the wire format is written into the EIP. A settled format could move this EIP to A-tier.8374Persist Warm Access Sets Across RevertsB1.67 (6)RepricingCoupled with EIP-8358: the two net-metering repricings make little sense apart and belong at one grade.7709Read BLOCKHASH from Storage and Update CostB1.67 (6)RepricingReal value for the history-expiry direction; grades span three tiers. This EIP could move up to A-tier if devnet sequencing moves smoothly and allows for it to be added without delaying schedules.7668Remove Bloom FiltersC1.5 (6)Cleanup & deprecationsInternally rated w/ a three-tier spread; a receipt and filter change best sequenced with the broader history and logs work.8200EVMificationC1.43 (7)Precompiled & cryptographyEvery replacement bytecode must be audited to match precompile behavior exactly, and the bytecodes are not yet in the EIP. There is no hybrid: all clients run the bytecode or gas cannot be computed consistently. Graded with EIP-7666.8358Net Gas Metering for Account ChangesC1 (6)RepricingCoupled with EIP-8374 and currently a tier apart.7666EVM-ify the Identity PrecompileC1 (7)Precompiled & cryptographyExists to support EIP-8200 and was not defended independently.8116Replace Cumulative Receipt FieldsC1 (6)Block & state dataSame family as EIP-7668: a receipt-format change best sequenced with history and logs.8355ML-DSA Verification PrecompilesC1 (9)Precompiled & cryptographyEnshrines a specific PQ verification scheme ahead of a dedicated cryptographic adjudication: premature standardization.8163Reserve EXTENSION (0xae) OpcodeDFI2.33 (6)EVM cleanupNo committed consumer of the reserved opcode ships this fork, and a reservation can ride any future fork at the moment an object-format design commits.7979Call and Return Opcodes for the EVMDFI1.33 (6)EVM cleanupAdds control-flow surface to a fork already carrying two headliners and their interaction testing.7851Code-Controlled EOA DelegationDFI1 (5)AA & delegationAn alternative account-abstraction mechanic; loses to the Frames approach on the permissionless-innovation test.7923Linear, Page-Based Memory CostingDFI0.83 (6)RepricingRepricing family: no further metering churn before Glamsterdam’s repricing produces mainnet evidence.7973Warm Account Write MeteringDFI0.83 (6)RepricingSee EIP-7923 note8304Trustless Log and Transaction IndexDFI0.83 (6)Block & state dataAn index-format change with a large testing surface; belongs with the history and logs work.8094eth/vhash: Blob-Aware MempoolDFI0.8 (5)Mempool & tx propagationA mempool change with unclear interaction with the blob-scaling path.8115Batch Priority Fees at End of BlockDFI0.5 (6)Block & state dataSee EIP-7923 note8219Checked Arithmetic OpcodesDFI0.5 (6)Gas repricingSee EIP-7923 note7819SETDELEGATE InstructionDFI0.29 (7)AA & delegationAn alternative account-abstraction mechanic; loses to the Frames approach on the permissionless-innovation test.8188Last-Written Block for Accounts and SlotsDFI0.29 (7)Block & state dataState-repricing family; waits for the I* trie-migration design.2488Deprecate the CALLCODE OpcodeDFI0.17 (6)Cleanup & deprecationsA deprecation with no Hegotá urgency and app-layer breakage risk. Near-unanimous.7862Delayed State RootDFI0.17 (6)State transitionProving-preparation set; deferred, not disliked.8182Private ETH and ERC-20 TransfersDFI0.17 (6)PrivacyEnshrines a specific privacy mechanism; the Frames-based path delivers the same goal with less protocol surface and keeps schemes competing.7645Alias ORIGIN to SENDERDFI0 (6)AA & delegationBreaks assumptions in deployed contracts for no security gain. Unanimous.7807SSZ Execution BlocksDFI0 (6)Block & state dataA formatting migration with a wide blast radius and no Hegotá dependency. Unanimous.8368CPSB Recalibration for New Gas LimitTBD2.29 (7)RepricingWaiting on post-Glamsterdam mainnet data. One decision with EIP-8372 (recalibrate, normalize, or neither), unknowable until Glamsterdam’s repricing produces evidence. This proposal drew majority S/A support;8372Normalized State Gas LimitTBD1.14 (7)RepricingWaiting on the same post-Glamsterdam mainnet data as EIP-8368.\nA few notes on the A tier\n\nHeadliner packages: EIP-7805 (FOCIL) ships with EIP-8369 (VOPS Profiles for FOCIL Eligibility). EIP-8141 (Frame Transactions) ships with EIP-8250 (Keyed Nonces for Frame Transactions) and EIP-8272 (Recent Roots for Frame Transactions) as the Frames core. Delivering both headliners safely, and testing the interaction between them, is the fork’s core engineering commitment.\n\nExtension package: EIP-7906 (Transaction Assertions via State Diff Opcode), EIP-8298 (SETCODEFROM Code Reuse Instruction), and EIP-8151 (Account Code Restricted ecRecover). The first hardens transactions directly; the other two give an account a complete route away from k1 keys.\n\nA few notes on the B and C tiers\n\nConsensus layer EIPs blocked by additional requirements: EIP-8198 (Quick Slots) has the most demanding requirements on the list, including specifications covering all expected changes to the core protocol, a prototype implementing the full specification, an in-depth assessment of downstream effects across the ecosystem, and sign-off that it does not complicate decoupled consensus, which cannot be determined until that specification exists. The bar is set where it is because while the diff is small, the change is not; slot time is load-bearing for timing assumptions across the protocol and the ecosystem, and discovering breakage late is how forks get delayed. EIP-8321 (Hash-Chain RANDAO) needs the complete PQ consensus design. EIP-8146 (Block Access List Sidecars) needs its observation deadline settled in specification. EIP-8237 (Independent CL/EL Sync) needs a cost comparison against simpler alternatives and a delivery owner.\n\nExecution layer EIPs blocked by additional requirements: EIP-8253 (Bump Nonce of Zero-Nonce Storage Accounts) is under consideration to move to A-tier. It is not strictly required for the trie migration, and it simplifies the migration significantly, and the review will decide how much that simplification is worth. EIP-8077 needs a settled wire format. EIP-8374 (Persist Warm Access Sets Across Reverts) and EIP-8358 (Net Gas Metering for Account Changes) are one net-metering package and cannot carry different grades; resolving that is an open review item.\n\nTBD EIPs: EIP-8368 (CPSB Recalibration for New Gas Limit) and EIP-8372 (Normalized State Gas Limit) shall be evaluated together once Glamsterdam hits mainnet and the impact of related state repricings can be evaluated.\n\nA few notes on the DFI block\n\nThe unanimous CL DFI block: EIP-8363 (Tapered Issuance Burn) and EIP-8375 (ePBS Mandatory Burn of Execution Rewards) belong to a broader issuance process. EIP-8148, EIP-8205, and EIP-8359 are operational conveniences that primarily serve large staking operations and fail the necessity bar. EIP-8142 (Block-in-Blobs) deepens KZG dependence against the path to J*.\n\nOne proposal deserves a direct note: EIP-8363 (Tapered Issuance Burn). The unanimous DFI is not a judgement on the merits of the proposal. Issuance policy touches every staker, every holder, and the network’s long-run security budget; at this stage, EF Protocol does not consider itself the right and sole body to give direction on it, and a fork scoping exercise is not the right venue to settle it. We would expect this to be carried forward via a multi-node ecosystem process with the technical rigour and breadth of engagement the question deserves, and we intend to participate in such a process.\n\nIII. In closing\nOf the 62 proposals evaluated, 2 are must-ship, 15 are expected to ship, and 28 are declined with stated reasons. Of the 15 remaining, 8 are B-tier proposals with noted requirements for inclusion, 7 are C-tier proposals below the line, and 2 TBD proposals waiting on mainnet evidence. Success here is determined as much by what we decline as by what we ship.\nIf you read one thing beyond this post, please read the companion: EF Protocol: Current and Emerging Priorities, which includes the Protocol cluster’s north star, plan, and the commitments that produced every grade above.\nAnd if a grade above deserves a challenge, we’d love to hear the pushback. We're hosting a Reddit AMA on r/ethereum on September 16 at 2pm UTC, and the tier list is exactly what we expect to be asked about. Submit questions ahead of time using the form here. Champions and supporters of non-A-tier EIPs and declined EIPs are especially welcome.\n\n*Editor's note: This article was updated on Sep. 8 2026 to revise the tier list notes for EIP-7716, adding additional clarification on where further research and discussion is needed.","tokens":5338,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267883906,"hash":"5ba179942647460124ee17f5cfe1398db1e8af89"}
{"url":"https://blog.ethereum.org/2026/09/07/protocol-priorities","domain":"blog.ethereum.org","title":"EF Protocol: Current and Emerging Priorities | Ethereum Foundation Blog","text":"EF Protocol: Current and Emerging PrioritiesWhat the Protocol cluster is for, the commitments that govern its work through 2029, and what those commitments require of the forks now entering scope.Posted by Ethereum Foundation Protocol Cluster on September 7, 2026Research & DevelopmentIn May, the Protocol cluster welcomed a trio of new cluster coordinators and promised updates to follow.\nAfter months of settling in and aligning with contributors cluster-wide, across the EF and across the Ethereum ecosystem, we are now happy to share Protocol's priorities: what Protocol is for, the commitments that govern its work through 2029, and what those commitments require of the forks now entering scope.\nWith Glamsterdam approaching mainnet, Protocol has entered the Hegotá scoping season. We used the process described in an August 28 post: 62 EIPs proposed for inclusion, multiple Glamsterdam retrospectives, 16 contribution templates, and several cluster-wide working sessions. That process helped roughly 60 researchers and engineers to determine a shared set of priorities. Those priorities cover the longer-term roadmap and are focused through a critical path. That path starts with how we scope Hegotá.\nThis post communicates that shared set of cluster-wide priorities. For our grade on every Hegotá candidate, read the companion: EF Protocol: The Hegotá EIP Opinion Post and Tier List.\nI. The north star\nThe EF Protocol cluster is aiming for Ethereum L1 to be quantum-resistant across all three layers (execution, consensus, and data) by December 2029. That date lines up with the 2029 migration targets independently set by Google, Cloudflare, and Microsoft. Estimates for Q-day will sharpen as time progresses. Its timing is outside anyone’s control, which is exactly why we have fixed a target rather than waiting for certainty. For now, Ethereum L1 should plan for Q-day happening as early as 2030. Planning for Q-day in 2030 is a deliberately aggressive assumption. Most credible estimates place Q-day later, some much later, and we may never see it at all.\nShipping post-quantum readiness early is the secure thing to do. It is the strategically responsible thing to do. It is the clearest signal we can send that Ethereum intends to exist 50, 100, and 1,000 years from now. Ethereum’s instinct, rightly, is to distrust all-in bets, and so do we. Here, though, we are making that bet deliberately. Q-day cannot be scheduled, so we have assigned ourselves a self-imposed deadline.\nThe EF Protocol cluster will treat this self-imposed deadline as non-negotiable at least until January 2027, when quantum progress will be reassessed with the guidance of outside experts.\nII. The plan\nTwo cadences to December 2029\nClient teams can realistically begin Hegotá implementation in late Q4 2026. Under the July Strawmap, full post-quantum readiness sits in L*, five hardforks after Glamsterdam. Shipping Glamsterdam in December 2026 and L* in December 2029 requires an average cadence of 7.2 months per fork. That schedule is quite aggressive, and leaves little room for error should a fork take longer to ship than anticipated year in advance.\nThe August 19 Strawmap update added a minimum viable post-quantum (MV-PQ) L1 milestone at J*. The post-quantum public-key registry sits in I*. The post-quantum heartbeat on the consensus layer, leanDA sampling on the data layer, and leanSPHINCS transactions on the execution layer sit in J*. A 12-month cadence from Glamsterdam can reach that contingency milestone by December 2029.\nMV-PQ is a temporary safeguard\nMV-PQ is designed to keep Ethereum operating through Q-day with reduced guarantees. Researchers are still defining exactly what that reduction in guarantees would look like. Full resistance across execution, consensus, and data remains the December 2029 target. The remaining work includes post-quantum attestations, required for full economic finality to complete consensus design.\nFlexible fork order after J*\nThe Strawmap may swap K* and L*, moving lean consensus forward by one fork and mandatory execution proofs back by a fork. Reaching full post-quantum readiness in K* by December 2029 implies a 9-month cadence. We are planning Hegotá, I*, and J* as one delivery sequence while that ordering will only be finalized once research matures and client capacity is better understood.\nParallel delivery across the ecosystem\nThe cadence these milestones demand will require an incredible amount of teamwork, within Protocol and beyond. Forks will overlap, shipping Hegotá simultaneously while I* specifications mature and J* through L* research produces testable components. Simply shipping the forks in a linear sequence cannot meet the December 2029 schedule. Doing so will require tighter communication inside the cluster, and engaging client teams, grant recipients, academia, and the wider community so the pipeline from research to mainnet accelerates with every fork.\nDelivering PQ-readiness will also take more hands than any prior fork sequence, including cryptographers, client devs, researchers, security reviewers, and testing capacity, inside the EF and well beyond it. This will be an ecosystem-wide effort.\nIII. The five multi-fork research arcs\nSimultaneously working on several forks is how the Protocol cluster carries all of its interconnected work, near-horizon and long-horizon alike, beyond the immediate push to reach minimum viable post-quantum. These efforts are organized around five multi-fork research arcs: fast finality, post-quantum, privacy, state, and zkEVM.\nFast finality\nFast finality reduces Ethereum's time to finality from minutes to seconds. The current design direction decouples finality from block production and rebuilds the consensus layer around an available chain and a finality gadget. Specifications and prototypes are underway, aimed at I*, where decoupled consensus is the leading headliner candidate.\nPost-quantum\nThe post-quantum arc (as described in “II. The Plan” above) delivers the December 2029 commitment and it spans all three layers: consensus, data, and execution. Cryptographic agility is critical to the execution layer, where native account abstraction lets signature schemes be swapped without a hard fork per scheme. Frames provides that property with its approach to native account abstraction. The consensus layer, however, cannot rely on cryptographic agility; its cryptography and aggregation schemes can only change through a hard fork. Consensus cryptography gets the opposite treatment as a result. It gets battle-tested and hardened before rollout, and consensus components wait for the complete PQ design instead of shipping one at a time.\nPrivacy\nThe privacy arc is working toward privacy as a protocol guarantee, so that users can transact, hold balances, and interact with applications without exposing their financial history or trusting third parties. We believe this work should start in Hegota to deliver native, trustless, censorship resistant private transactions on Ethereum L1. Later work focuses on post-quantum privacy at scale, and encrypted mempools that conceal transaction contents until inclusion.\nState\nThe state arc keeps state growth and access from becoming Ethereum's binding constraint. Its work includes migrating to a new trie, sustainable state growth, and decentralized access to current and historical state. The largest design and migration work is expected to begin in I* and continues beyond it.\nzkEVM\nThe zkEVM arc moves execution proofs from available and optional, to expected, to mandatory. Validators eventually verify a succinct proof and stop re-executing every block. Under the current Strawmap ordering, mandatory proofs arrive in K*. One reordering is in review: swap the PQ attestation and mandatory proofs milestones. PQ attestations would move forward from L* to K*, and mandatory proofs would move back from K* to L*, while the rest of each fork stays where it is. If that happens, mandatory proofs arrive one fork later so the largest remaining piece of consensus PQ arrives one fork sooner. Either way, the push to ship an L1 zkEVM also drives forward formal verification tooling, workflows, and verified cryptographic components that other arcs benefit from, post-quantum in particular.\nIV. How we set priorities & ship them\nOur imperative, first published in the July all-Protocol update, remains:\n\"Concentrate Protocol on what only Protocol can do and will do, and complete the Strawmap items that allow Ethereum to uphold the Mandate.\"\nGlamsterdam's completion and the December 2029 commitment move post-quantum work from a long-horizon research concern into near-fork delivery. The post-Glamsterdam priority ladder records that change and places formal verification across the remaining research arcs as shared tooling.\n\nAs of Q2 2026Post-GlamsterdamP0Keep mainnet safeKeep mainnet safe (unchanged)P1Ship Glamsterdam and Hegotá without security or stability issues and in a timely mannerShip the critical components of Hegotá, I*, and J*: the path to MV-PQP2Hold research and engineering capacity for the fork after next (I*)Hold research and engineering capacity for K* and L*, focused on accelerating the remaining PQ itemsP3Hold research capability for the five multi-year arcs (fast finality, post-quantum, privacy, state, and zkEVM)Hold research capability for the four remaining arcs (fast finality, privacy, state, and zkEVM), with formal verification as cross-cutting tooling that advances all of them\nThe ladder sets priority; the maturity pipeline sets how work earns inclusion:\nResearch → EIP → Prototype → Devnet → PFI → CFI → SFI → Mainnet\nEach step should add evidence, reduce uncertainty, and make ownership visible before the next commitment is made. A devnet can send work back to research. PFI, CFI, and SFI signal rising confidence among AllCoreDevs; they do not substitute for implementation evidence. Much of what Protocol is uniquely positioned to do is moving ideas across this whole pipeline.\nV. The next fork, as the first test\nThis section is about Hegotá specifically. Protocol's view of the fork now being scoped. The companion post, EF Protocol: The Hegotá EIP Opinion Post and Tier List, details how the Protocol cluster grades every EIP, with a specific explanation for each EIP. In this section, we cover the priorities, commitments, and scope boundaries that produced those views.\nHegotá is not the PQ fork; it is the fork that decides whether the PQ forks happen on time. Its SFI'd headliners are EIP-7805 Fork-choice enforced Inclusion Lists (FOCIL) on the consensus layer and EIP-8141 Frame Transaction on the execution layer. They must ship together safely, with the interaction between inclusion and the new transaction model tested as part of the fork's main engineering lift.\nThere is little appetite for additional consensus-layer scope. FOCIL is Hegotá's consensus-layer centerpiece. Our appetite beyond it is close to zero unless an addition directly supports post-quantum readiness. Each additional consensus-layer item draws from the same researchers and client devs needed to specify and prototype decoupled consensus and prepare I* and J* when their Hegotá implementations are completed.\nPreserving CROPS as a whole\nThe Mandate defines Protocol's job through CROPS: Censorship Resistance (CR), Open Source and Free, as in Freedom (O), Privacy (P), and Security (S). These properties are one set of protocol guarantees. Open-source development and open participation are the baseline for every fork. Hegotá makes specific commitments across the other 3.\nCensorship resistance (CR)\nFOCIL’s goal is to improve Ethereum's transaction inclusion guarantees by enabling multiple validators to impose constraints on builders’ blocks. They do so by specifying a set of transactions that must be included via ILs for the block to be considered valid by attesters. EIP-8369 VOPS Profiles for FOCIL Eligibility defines which transactions are eligible and what validators must verify, so FOCIL’s guarantees can extend to future transaction types. Together, they are Hegota's direct commitment to censorship and capture resistance.\nPrivacy (P)\nEthereum is still missing some basic protocol support that privacy applications need. EIP-8250 Keyed Nonces lets many users share the same sender for better anonymity, while giving their transactions separate nonces so they do not block one another. EIP-8272 Recent Roots lets private transactions use recent onchain state in a form FOCIL can check, so they can benefit from its inclusion guarantees. Together, they remove two major barriers to trustless, censorship resistant private activity on L1 and should ship with Frames.\nSecurity (S)\nFrame transactions makes transaction validation, execution, and gas payment programmable at the protocol level. It gives accounts a native route away from vulnerable secp256k1 keys, supports signature aggregation, and lets new signature schemes be introduced without a hard fork for each scheme. It also keeps account validation and fee payment permissionless. Keyed nonces and recent roots complete the Frames core needed for Hegotá.\nEIP-8365 BLS Withdrawal Credential Retirement starts the retirement process for withdrawal credentials that remain tied to vulnerable cryptography. The work can begin now without waiting for the full post-quantum consensus design.\nThe Frames-extension package hardens accounts directly. EIP-7906 Transaction Assertions via State Diff Opcode lets transactions verify specified effects before committing, protecting against attacks such as drainers, EIP-8298 SETCODEFROM Code Reuse Instruction lets delegated accounts become full smart-contract accounts, and EIP-8151 Account Code Restricted ecRecover blocks legacy key authentication once an account has real code. The last 2 form the account path for retiring secp256k1 as a master key.\nThe bounding pair treats worst-case block construction as security work: EIP-8279 Block Access List Byte Floor and EIP-8131 Unified Transaction Content Floor put a predictable gas floor under adversarial block content. Any later use of resulting headroom is a separate scope decision.\nDelivering FOCIL and Frames safely, and testing the interaction between them, is Hegotá's core engineering commitment. Every addition competes with that testing surface and must clear the necessity bar.\nVI. What to expect\nThe companion post publishes the Protocol cluster’s Hegotá tier list and explanation of every grade. If you read one thing beyond this post, read the companion.\nLastly, we want your questions. We're hosting a Reddit AMA on r/ethereum on September 16 at 2pm UTC to talk through these priorities, the Hegotá tier list, and anything else on your mind. Submit questions ahead of time using the form here. The sharper the question, the better the thread.","tokens":3710,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267905721,"hash":"7ae8b8942a0cd01497cfb9638ef417b2e00b8b2a"}
{"url":"https://blog.ethereum.org/2026/05/11/protocol-update-may-26","domain":"blog.ethereum.org","title":"Protocol Cluster Updates: May 2026 | Ethereum Foundation Blog","text":"This post is available in 25 languages: EnglishProtocol Cluster Updates: May 2026Posted by Will Corcoran, Kev Wedderburn, Fredrik on May 11, 2026Research & DevelopmentA semi-regular gathering of Ethereum core devs from various client teams, or interop, recently took place in Svalbard, Norway. Over the week-long event, teams focused on hardening and preparation for the next upgrade, Glamsterdam.\nSeveral important milestones came out of the week, including:\n200M gas limit floor established: Credible post-Glamsterdam target derived from convergence of ePBS, BAL optimizations, and EIP-8037 repricingePBS stabilized: Multi-client Glamsterdam-devnet running with external builders pipeline tested end-to-end across nearly all clientsEIP-8037 finalized: Fixed cost_per_state_byte adopted; full repricing numbers delivered by Friday on bal-devnet-6Hegotá groundwork laid: FOCIL prototypes are functional; native AA requirements were scoped; the multi-client devnet is the immediate next step\nThe interop also marked the start of a leadership transition for the Ethereum Foundation Protocol cluster.\nThe new cluster coordinators will be:\nWill CorcoranKev WedderburnFredrik\nTeam evolution\nOver the last year since the announcement of the Protocol Cluster, Barnabé Monnot, Tim Beiko, and Alex Stokes have given a tremendous amount to the ecosystem through their leadership.\nWhile Barnabé and Tim are moving on from the Ethereum Foundation soon and Alex Stokes will be on sabbatical, the Protocol cluster as it exists today is in large part due to their work. Under their coordination, Protocol launched tracks, and helped to ship Fusaka to mainnet in December 2025, introducing PeerDAS and raising the mainnet gas limit on the path to 200M and beyond.\nTim, Barnabé, and Alex shaped Protocol in ways that will outlast their time as cluster coordinators. We're grateful, and we're looking forward to what each of them takes on next.\nAbout the new Protocol Cluster Coordinators\nThese team changes are already underway. At Interop, there were several impromptu conversations and strategic meetings between the incoming and outgoing groups, the perfect setting to begin this transition without distracting from hardening and shipping Glamsterdam. More about the new Protocol Cluster Coordinators:\nWill Corcoran. Will is a Research Coordinator within Protocol, with broad cross-team and cross-cluster visibility through his work on zkVM proving, post-quantum consensus, and the Fast Confirmation Rule. He has facilitated numerous community calls, breakout rooms, and in-person protocol events, giving him an operational understanding of how Protocol's efforts interconnect.\nKev Wedderburn. Kev leads the zkEVM team and brings deep expertise at the intersection of research and engineering, along with a first-principles approach to technical decision-making.\nFredrik. Fredrik leads Protocol Security, the Trillion Dollar Security project, and has been deeply involved in cross-cluster work.\nWhat to expect\nThe immediate focus is shipping Glamsterdam, continuing preparations for Hegotà, and advancing the Strawmap.\nGlamsterdam devnets are now live, and scoping for Hegotà is well underway with FOCIL scheduled for inclusion as a headliner on the CL side. Stay tuned for more Protocol cluster updates from Will, Kev, and Fredrik in the coming weeks!","tokens":835,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791267916087,"hash":"610b60ecc966a89011bf60ece42b724bdde0d6cc"}
{"url":"https://forum.pyth.network/t/pyth-playground-community-hackathon/2363","domain":"forum.pyth.network","title":"Pyth Playground Community Hackathon - Ideas Bank - Pyth DAO","text":"Pyth Playground Community Hackathon \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Feb 24\n\n 1 / 26\n\n Feb 25\n\n Mar 11\n\n post by Chop on Feb 24\n\n Chop\n\n Overview\nThe Community Council is proposing the launch of the Pyth Playground — a hackathon for builders of all skill levels. Use Pyth price feeds, entropy, or Pyth Pro to build something. AI-assisted development (“vibe coding”) & agentic use cases are not just allowed, but are encouraged. Grants & rewards for quality, innovation and community favorites.\nProposed launche date; Wednesday, March 4. This post opens the floor for community feedback before we go live.\n\nWhat Is This?\nA 6-week event run by the Community Council:\n\nWeeks 1–4 (March 4 – April 1): Build something using Pyth data. Share progress publicly.\n\nWeeks 5–6 (April 2 – April 15): Judging panel scores submissions. Community votes via forum upvotes.\n\nApril 15: Winners announced via community call.\n\nSubmissions happen on the Pyth Developer Forum in a dedicated Pyth Playground category. Code lives on GitHub (Apache 2.0, matching Pyth’s license).\nThis has been set up to be recurring - however this will be run as a once off event that may be ongoing depending on demand and results.\n\nWhy?\nThree reasons:\n1. The builder pool just got 10x bigger. Tools like Cursor, Claude, and Replit Agent mean that traders, analysts, and creators — not just senior devs — can ship functional applications. Pyth’s data shouldn’t be locked behind arbitrary barriers that AI now dissolves.\n2. Every submission generates public content. Participants will post about their projects on Reddit, GitHub, and the developer forum. That’s organic, authentic content about Pyth integration patterns — the kind of content that ranks in search and gets cited by AI models. 30 submissions = 60+ public references across multiple platforms that reference Pyth.\n3. We need more people building with Pyth Pro. The best way to demonstrate the value of real-time institutional-grade data is to let people build with it. This event gives them the structure and incentive to do that.\n\nPrize Structure (Round 1)\n\nTier\nReward\n\n1st Place\n50,000 PYTH\n\n2nd Place\n30,000 PYTH\n\n3rd Place\n15,000 PYTH\n\n4th–10th Place\n5,000 PYTH each\n\nCommunity Choice (most upvotes)\n10,000 PYTH\n\nMost Creative Pyth Pro Use\n10,000 PYTH\n\nBest Educational Content\n10,000 PYTH\n\nSocials content bonuses stack on top: 10 upvotes (+500), 25 (+1,000), 50 (+2,500), 100 (+5,000).\nContent bonuses: Wikipedia contribution (+5,000 PYTH), second platform post (+1,000 PYTH).\nTotal budget: ~200,000 PYTH from Community Council Budget allocation.\n\nSubmission Requirements\n\nUse at least one Pyth feature (Price Feeds, Entropy)\n\nWorking demo or live deployment\n\nSource code on GitHub (Apache 2.0)\n\nForum post on Pyth Developer Forum using the official template\n\nOne public content piece (Reddit, Dev.to, or similar)\n\nOne technical contribution (Stack Overflow answer or GitHub example)\n\nTeams of up to 2. One submission per team per round. 18+ only.\n\nJudging\n\nCriteria\nWeight\n\nPyth Integration\n30%\n\nCreativity / Innovation\n25%\n\nExecution\n20%\n\nUser Experience\n15%\n\nDocumentation\n10%\n\nPanel: 2 Community Council members (Arguer, Lowkeigh confirmed), 1 Pyth engineering rep (outreach in progress), 1 external guest judge (TBD). All scores published after results.\nCoordinator: @Chop (non-voting).\n\nLegal & Compliance\nTerms & Conditions are being finalized. The Hackathon is organized by PYTH DAO LLC (Marshall Islands) through the Community Council. Key points:\n\nSkill-based judging with transparent, objective criteria\n\nOFAC-sanctioned jurisdictions excluded\n\nKYC required for prize winners only\n\nAll submissions open source (Apache 2.0)\n\nParticipants retain IP ownership\n\nDAO contributors may participate but are not eligible for prizes\n\nParticipants responsible for their own tax obligations\n\nFull T&Cs will be pinned in the Developer Forum before launch\n\nTimeline\n\nMilestone\nDate\n\nThis governance post + community feedback\nFeb 25\n\nT&Cs finalized and posted\nFeb 28\n\nDeveloper Forum category setup + rules posted\nFeb 28\n\nPre-launch promotion\nMarch 2–3\n\nRound 1 Launch (submissions open)\nMarch 4\n\nSubmission deadline\nApril 1\n\nJudging period\nApril 2–15\n\nWinners announced\nApril 15\n\nWhat’s Ready\nWe’ve spent the last month building out the infrastructure:\n\n3 starter kits (Python, TypeScript, MCP Server) — ready to fork\n\n30 project ideas across 5 categories (trading bots, dashboards, AI agents, DeFi tools, educational)\n\nPyth MCP Server deploying March 2 — lets any AI coding assistant pull live Pyth data directly using AI Agents\n\nSubmission template, judging rubric, FAQ — all drafted and ready for the Developer Forum\n\nMissionMonitor bot — live in production for tracking Discord & Telegram content submissions\n\nWhat We Want From The Community\nThis post is here to start a discussion. Before we launch:\n\nBuilders: What would make you participate? What’s missing?\n\nCommunity: Are the prize tiers right? Too top-heavy? Not enough participation rewards?\n\nAnyone: Feedback on submission requirements, judging criteria, or format?\n\nThe full rules, submission template, starter kits, and project ideas will all live on the Developer Forum from Friday (27th).\n\n 3\n\n 3\n\n 2\n\n 2\n\n post by Planck on Feb 25\n\n post by N0name_trader on Feb 25\n\n post by CrownOfLagos on Feb 25\n\n post by CrownOfLagos on Feb 25\n\n post by codeglitch on Feb 25\n\n post by Planck on Feb 25\n\n post by KemarTiti on Feb 25\n\n post by CrownOfLagos on Feb 25\n\n post by Defi_Godwinn on Feb 25\n\n post by Defilion on Feb 26\n\n post by theRoad on Feb 26\n\n post by totti on Feb 26\n\n post by Flint on Feb 26\n\n post by BeeKey201 on Feb 26\n\n post by SkyZ on Feb 26\n\n post by lowkeigh on Feb 26\n\n post by spank2023 on Feb 26\n\n post by Mersault on Feb 26\n\n post by Mersault on Feb 26\n\n Load more posts below","tokens":1457,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267938918,"hash":"cc675ec93ec407089079554688950cf2c2d52004"}
{"url":"https://gov.optimism.io/t/s7-grants-council-impact-analysis/10055/1","domain":"gov.optimism.io","title":"S7 Grants Council Impact Analysis - Grants 🔴 / Governance Fund Missions - Optimism Collective","text":"Welcome to the Optimism Collective! You can find all dates on the public governance calendar.\n\n S7 Grants Council Impact Analysis \n\n Grants 🔴Governance Fund Missions\n\n season-7\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n Jun 2025\n\n 1 / 20\n\n Jun 2025\n\n Dec 2025\n\n post by system on Jun 24, 2025\n\n system\n\n TL;DR:\n\nAn observational analysis of S7 Grants Council grants measured OP-normalized ROI using net Superchain TVL inflows between March 20 and June 12, 2025.\nROI benchmarks emerged at $1.58 (25th percentile), $3.67 (median), and $9.39 (75th percentile) per OP, providing reference points for the evaluation of future grants.\nIn total, the net TVL inflows attributable to the TVL-focused grants amounted to $65.3M.\nObservational data suggests that grants generating both strong TVL growth and higher volume per TVL may be indicative of more sustainable net TVL inflows, though conclusions are preliminary.\n\nContext\nIn S7, the Collective rallied around the North Star metric of Superchain TVL growth, honing in on initiatives most likely to drive outsized impact towards this Intent. Consistent with this concerted effort, it’s crucial to ensure that all Collective programs—ranging from SuperStacks to Futarchy—are assessed in a unified manner using the same framework, paving the way for a universal, OP-normalized ROI analysis.Against this backdrop, we conducted an observational impact analysis of the grants the Grants Council made in S7, which concluded on June 12, 2025. The intended purpose of this post is to contour preliminary learnings to help inform OP allocation decisions in the S8 cycle.\nMethodology\nThe Foundation collaborated with OpenSource Observer to conduct an observational analysis of net TVL inflows between March 20 and June 12, 2025, which represented the defined incentive period for the issued grants. The analysis focused exclusively on grants that targeted Superchain TVL growth, excluding audit grants, which comprised 10.6% (~990K OP) of the total budget.\nFor the TVL measurement, we relied on the definition outlined in this glossary and leaned on DefiLlama as the primary data source. Furthermore, the TVL measurement was narrowed down to the chains within the Superchain that the grant intended to impact, as per incentive distribution plan outlined in the grant applications.\nIn terms of impact attribution, we tried to account for grant scope specificity and concurrently deployed co-incentives targeting the same chains. Specifically, we incorporated this logic into the TVL calculation by lowering the net TVL inflows attributable to the respective grants if other co-incentives were known—either because it was explicitly mentioned in the grant application or because it was public knowledge (e.g. inclusion in SuperStacks)—or if the grant aimed to only incentivize a small subset of the chain’s total market (e.g. a single stablecoin vault).\nFor example, Sake Finance had net inflows of $9M during the grant period, but this coincided with Soneium’s ACS campaign (which allocated a total of 70M ASTR to DeFi protocols) as well as SuperStacks (which allocated an additional 2M+ in DeFi incentives across the Superchain). Sake Finance was a participant in all three of these incentive programs. As a result, we apply a discount to the net TVL inflows that are attributable to the Grants Council program.\nWhile perfect TVL attribution is very hard to achieve, factoring in known confounding variables could help us better approximate reality. We erred on the side of providing more conservative estimates initially. Note that the Foundation applies exactly the same attribution logic to any internal analyses of Foundation-owned programs.\nKey Findings\nTo standardize TVL measurement, we aggregated results to establish baseline ROI benchmarks that can be used across seasons. At the aggregate level, S7 GC grants achieved $9.39 in net TVL inflows at the 75th percentile and $1.58 at the 25th percentile), offering reference points for future ROI evaluations.\nNote that these benchmarks should not be seen as an end-all-be-all measuring stick for future grants, but instead could serve as a proxy for evaluating future performance. For context, these results fall below benchmarks from previous growth grants (P75: $37.93; P50: $13.83; P25: $0.73), as determined by an analysis from the data team at OP Labs.\nIn total, the net TVL inflows attributable to the TVL-focused grants amounted to $65.3M. To put this into perspective, preliminary results from SuperStacks—a DeFi incentive campaign run by the Foundation—indicate that the program has brought in $73.4 in net TVL inflows per OP as of last week.\n\nS7 GC Grants\nNet TVL Inflows / OP At Program End (n = 17)\n\n75th percentile\n$9.39\n\n50th percentile (median)\n$3.67\n\n25th percentile\n$1.58\n\nWhen taking the project-level ROI distribution under the microscope, it becomes apparent that net TVL inflows per OP follow a power law dynamic, with Morpho’s World grant yielding $44 / OP in attributable net TVL inflows and Euler’s grant achieving $24 / OP, while most other grants hover in the $1-10 / OP range.\n1600×383 70.1 KB\nInterestingly, top performing grants like Aerodrome and Uniswap showed not only notable TVL inflows, which indicates supply-side growth, but also high daily volume per TVL ($0.58 - $0.63), commonly used to gauge demand-side activity. In contrast, projects with lower net TVL inflows / OP demonstrated lower daily volume per TVL ($0.004 - $0.40).\nTaken together, this might suggest that healthy demand-side activity in conjunction with significant supply-side traction might be indicative of successful DeFi ecosystem momentum. Note that this observation is based on a very small sample size and does by no means imply a causal relationship.\n1600×403 186 KB\nConclusion\nThis preliminary analysis offers a first pass at understanding how effectively S7 Grants Council allocations translated into Superchain TVL growth. While attribution remains inherently complex, the introduction of OP-normalized ROI benchmarks—$1.58, $3.67, and $9.39 at the 25th, 50th, and 75th percentiles—provides a foundational reference point for evaluating future grants.\nEarly signals suggest that projects demonstrating both strong net TVL inflows and high volume per TVL may contribute more meaningfully to ecosystem growth. These insights, though directional, can help inform more data-driven OP allocation decisions in S8.\nAppendix\n\nS7 Observational Impact Analysis Dashboard\nS6 Growth Grant Analysis Dashboard\n\n Season 7 Impact Analyses and Season 8 Budgeting\n\n Governance Update #11\n\n Grants Council Operating Budget for Season 8 and 9\n\n S7 ROI Summary & Learnings\n\n Token House participation and incentives: Season 7 (Cycle 31a-38)\n\n 6\n\n 3\n\n 3\n\n 2\n\n read \n\n 13\n min\n\n post by GFXlabs on Jun 24, 2025\n\n post by Gonna.eth on Jun 25, 2025\n\n post by thbialek on Jun 25, 2025\n\n post by Gonna.eth on Jun 26, 2025\n\n post by GFXlabs on Jun 26, 2025\n\n post by Gonna.eth on Jun 26, 2025\n\n post by thbialek on Jun 27, 2025\n\n post by GFXlabs on Jun 27, 2025\n\n post by mastermojo on Jul 1, 2025\n\n post by lavande on Jul 7, 2025\n\n 16 days later\n\n post by elizaoak on Jul 23, 2025\n\n 25 days later\n\n post by GFXlabs on Aug 18, 2025\n\n post by ccerv1 on Aug 20, 2025\n\n post by GFXlabs on Aug 21, 2025\n\n post by ccerv1 on Aug 21, 2025\n\n 1 month later\n\n post by Kai on Sep 23, 2025\n\n post by GFXlabs on Sep 24, 2025\n\n post by niche on Sep 24, 2025\n\n 3 months later\n\n post by ccerv1 on Dec 17, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Grants Council Season 7 Retrospective Report\n\n Grants Updates\n\n 1. What is your assessment of the impact KPIs that were set in your Budget Proposal at the start of the Season? Have you made progress towards, or achieved, these milestones or KPIs? If not, why?\nWe met 100% of the inter…\n\n read more\n\n 10\n\n 608\n\n Jun 2025\n\n S8 Grants Council Impact Analysis\n\n Accountability 🗂️\n\n season-8\n\n The intention behind this impact analysis is to equip the Optimism Collective with preliminary results of the Grants Council’s S8 grants and help inform OP allocation decisions in S9. It was prepared by OSO in collabora…\n\n read more\n\n 0\n\n 169\n\n Jan 23\n\n Season 8 Growth Grants - TVL Impact Review\n\n ✨ General\n\n season-8\n\n gm all! Brichis here. I served on the Grants Council and on the Milestones and Metrics Council. Now the councils are dissolved and Optimism starts a new stage, so I did this analysis to close that chapter for me. \nI did …\n\n read more\n\n 2\n\n 166\n\n 13d\n\n Dashboard: TVL Growth of S7 Grantees\n\n ✨ General\n\n TVL Growth of S7 Grantees\nDisclosure: Please note that this is my personal opinion and does not necessarily reflect the views of the Grants Council. \nContext\nLate last year, I noticed that data analytics is highly valued…\n\n read more\n\n 3\n\n 247\n\n Jul 2025\n\n Season 8 Intent\n\n Intents\n\n season-8\n\n Season 8 Intent\nThis post outlines the main strategic goal of the Collective for 2H25 (Season 8 Intent) and highlights the contributions the Collective will support towards that goal. The audience for this post is all co…\n\n read more\n\n 20\n\n 2.1k\n\n Aug 2025","tokens":2301,"squid":"ink-governance","role":"Council Listener","at":1791267945723,"hash":"3f1105afb31ff48eec74fb19e3dccabd1413e522"}
{"url":"https://io.net/blog/ionet-frodobots-uc-berkeley-case-study","domain":"io.net","title":"How io.net Cut AI Research Costs 92.8% for Frodobots-UC Berkeley Breakthrough","text":"Back To BlogHow io.net Cut AI Research Costs 92.8% for Frodobots-UC Berkeley BreakthroughIO.NET Team / Jun 16, 2025Try io.intelligenceGet StartedTry io.cloudDeploy GPU#matthewAI Startup Cornerio.cloudAI Infrastructure & ComputeSuccess StoriesTable of ContentsFrodobots Challenge: Proving their crowdsourced data could power breakthrough navigation AI through reliable AI infrastructureKey Results:OverviewThe ChallengeAbout FrodobotsThe Strategic ProblemThe SolutionWhy Frodobots Chose io.net's AI InfrastructureThe ImplementationThe ResultsAI Infrastructure That Enabled Research BreakthroughTechnical ValidationKey Performance InsightsAbout This PartnershipFrodobots Challenge: Proving their crowdsourced data could power breakthrough navigation AI through reliable AI infrastructureKey Results:92.8% cost savings compared to Amazon Web Services’ H100 pricing12,696 GPU hours across 8 GPUs with zero failures66-day project duration with seamless deployment5TB storage provisioned in 30 minutes vs. days with Big Tech cloud providersAI infrastructure reliability that led to 85.7% navigation success\"We chose io.cloud because it delivered reliability when other platforms couldn't. When we needed 5TB of additional storage for our massive datasets, the io.net team provisioned it in 30 minutes. That's what sealed the deal for us.\" — Catherine Glossop, UC Berkeley RAIL LabOverviewFrodobots, a Singapore-based AI robotics startup, transformed their approach to data validation by partnering with UC Berkeley Robotic AI & Learning (RAIL) Lab and io.net to prove their crowdsourced navigation dataset could power breakthrough AI research. Initially struggling to demonstrate the value of their 2,000+ hour navigation dataset (25 times larger than any competitor), Frodobots needed reliable machine learning infrastructure to support rigorous academic research that would validate their data assets.Through io.cloud's on-demand, high-performance GPU cloud computing platform, the collaboration successfully processed 12,696 GPU hours, including a continuous 10-day training run across 8 GPUs without failures. UC Berkeley's research achieved an 85.7% navigation success rate compared to just 33.3% for baseline methods. The partnership resulted in a peer-reviewed research paper, global validation across 6 countries, and positioned Frodobots as a leader in embodied AI research.The ChallengeAbout FrodobotsFrodobots raised $8M in funding from investors including Protocol VC, Solana Ventures, and Solana co-founders. The 12-person team has built an innovative \"robotic gaming\" platform where players earn rewards by remotely controlling real robots to complete navigation missions worldwide.Frodobots operates robots across multiple cities, collecting extensive navigation data from real-world deployments. The company had accumulated over 2,000 hours of valuable navigation data from 10+ cities worldwide - a dataset 25 times larger than other publicly available navigation datasets. However, they faced a critical challenge: how to demonstrate this dataset's value for advancing AI research.The Strategic ProblemTraditional data licensing wasn't enough. Frodobots needed to prove their dataset could train breakthrough navigation models that work in any environment, but academic researchers consistently struggled with compute limitations. Without adequate research infrastructure, even the most valuable datasets couldn't reach their full potential.The company recognized that to establish thought leadership and validate their data assets, they needed to move beyond simple licensing. They had to invest in enabling world-class research that would definitively prove their dataset's value for training generalist navigation models.The SolutionWhy Frodobots Chose io.net's AI InfrastructureWhen Frodobots and UC Berkeley's RAIL Lab assessed what they would require to execute on their ambitious research project, they realized they needed AI infrastructure that could handle the demands of cutting-edge research. The project required processing 2TB of navigation data through week-long training runs without interruption.Frodobots provided their unique navigation dataset, UC Berkeley RAIL Lab conducted the research, and io.net sponsored the GPU cloud computing infrastructure to make breakthrough research possible.But the RAIL Labs team needed more than just raw compute power. When the research required additional storage to handle massive datasets, io.net's technical team quickly provisioned over 5 terabytes of additional local storage in 30 minutes - compared to days with traditional cloud providers.The ImplementationFrom Feb 24 to May 1st, 2025, UC Berkeley RAIL Lab used dedicated H100 nodes through Frodobots' partnership with io.net for 66 days straight. io.cloud's machine learning infrastructure supported 12,696 total GPU hours, including one continuous 10-day training run across 8 GPUs without interruption while processing 6,000 hours of trajectory data.The integration process proved remarkably smooth. As Glossop noted, \"Transferring our PyTorch-based codebase to the io.net server was straightforward. The dedicated AI infrastructure approach proved far superior to alternatives. The setup was like having a dedicated machine in our lab specifically for our project, which was a welcome relief from the hassle of borrowing resources from other cloud platforms.\"Beyond compute power, io.net's responsive technical support became crucial when research needs evolved. When the team required additional storage capacity to handle their massive datasets, io.net's technical team provisioned over 5TB of additional local storage in just 30 minutes - a process that typically takes days with Big Tech cloud providers.The infrastructure delivered consistent performance throughout the entire 66-day project timeline, enabling researchers to focus on their work rather than managing technical bottlenecks or dealing with the preemption issues common in shared cloud environments.The ResultsAI Infrastructure That Enabled Research BreakthroughThe partnership delivered exactly what Frodobots needed: the infrastructure reliability to enable breakthrough AI research. UC Berkeley RAIL Lab successfully published a peer-reviewed research paper demonstrating how Frodobots' navigation data could train generalist navigation models - research that was only possible because of io.cloud's on-demand, high-performance GPU cloud computing capabilities.As Frodobots CEO Michael Cho explains, \"Having UC Berkeley RAIL Lab, one of the world's top robotics research institutions, spend significant time publishing peer-reviewed research that produced state-of-the-art results with our dataset definitely helped publicly validate and add legitimacy to Frodobots' mission.\" This breakthrough was enabled by io.cloud's ability to provide uninterrupted training sessions and rapid storage scaling capabilities that Big Tech cloud providers and university resources couldn't match. io.cloud enabled validation across 6 countries spanning 3 continents, providing the consistency needed for global-scale testing.Technical ValidationThe AI infrastructure delivered exactly what the research demanded: 12,696 GPU hours, including a 10-day continuous run without a single failure. Glossop emphasizes how io.net's approach differed: \"Compared to other cloud compute providers like AWS or Google's TPU Research Cloud, working with io.net was extremely smooth. We had access to a consistent, dedicated machine rather than dealing with virtual machine instance setups that could get preempted.\"The ease of onboarding with io.net was just as crucial for the RAIL Labs team. \"Transferring our PyTorch-based codebase to the io.net server was straightforward. It was like having a machine in our lab specifically for our project,\" Glossop notes. This reliability was key for the demanding computational requirements, as she explains: \"With our lab's machines constantly overloaded and cloud resources being unreliable, io.net's dedicated approach let us process 2TB of navigation data and complete week-long training runs that would have been impossible elsewhere.\"Key Performance InsightsSpeed: 5TB storage in 30 minutes vs. days elsewhere‍Reliability: 12,696 GPU hours without preemption vs. constant interruptions‍Cost: 92.8% cost savings vs. AWS pricingThis machine learning infrastructure advantage has translated into concrete business results for Frodobots. As CEO Michael Cho explains, \"We actually have about a dozen ongoing research collaborations with other university labs at the moment, but having the first one with UC Berkeley set the stage for the rest, and gave teeth to our positioning as a world-class collaboration partner.\"Beyond immediate research outcomes, the partnership demonstrates how modern AI infrastructure can accelerate academic breakthroughs. As Cho notes, \"Having io.net involved in this collaboration has been an important step towards showing researchers that crypto, when done well, can really move the needle for them and help them to do their best work.\"About This PartnershipThis case study showcases how AI startups can leverage strategic compute partnerships to validate their data assets and establish academic credibility. Had Frodobots used AWS pricing, the compute would have cost $144,735 more (92.8% premium), demonstrating how efficient GPU cloud computing partnerships can make rigorous academic research economically viable while delivering breakthrough results.Ready to accelerate your AI research partnerships?Try io.cloud today or contact our team to discuss your infrastructure needs.","tokens":2407,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267945751,"hash":"29386612e3fee950d5af54c3580d7b918e242eb6"}
{"url":"https://forum.pyth.network/t/pythian-got-talent/2235","domain":"forum.pyth.network","title":"Pythian got talent - Ideas Bank - Pyth DAO","text":"Pythian got talent \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Sep 2025\n\n 1 / 4\n\n Oct 2025\n\n Oct 2025\n\n post by eukodal on Sep 30, 2025\n\n eukodal\n\n Hello\n• TLDR :\n• chit chat + voice chat\n• activity+flywheel creations+\n• massive community gatherings +\n• investors+\n• angel investor main gatherings\ni herby propose , dev gatherings in voice chat “acropolis”.\nbring new dev , craft ideas , showcase projects , actively working alongside of these devs.\nallocating , to PGT (pythians got talent)\ncurrent prizes :\nColosseum 75-50k\nhaving same less or higher , either way on impact awards as PP , i would like to have that PP on my ia bank\n-Note : participants + collabs + listeners + ideas + devs and allocating PP to any person bringing value.\n• Super stingy method : wont spend a dime of PP unless something happens “SSM” solution, yeah mate.\nconsider allo as advertising:\n“ AD < ROI “\nReturn of such investments must be:\n-spotlight for community\n-spotlight for new devs or cracked ones\n-also finding potential web3 jobs for current pythians\n-Leveraging community power\neg , papont vid ads, planck or pepito contents , borys koba ricardo memes and energy\npeople showing up daily bringing value to different section . eg : if you gucci in trading tokenomics design art memes all sort of talents you have a spot with us.\nincrease of $PYTH and pythenians price since this method gonna add too many people into our community.\n“ time and gatherings “:\nthis event is 1 time monthly\n+daily checking\n+weekly gatherings if a new dev or idea is available\nend of month , “projects launching or working , with actual social and community interest get PP rewards”\nPP stack : on the event of hitting the fan no dev no interest . Stack PP\nso next month PGT(pythians got talent) will look juicy\non this journey all allocation will have proof of distribution as it is happening rn on ia’s feed\npythians identity:\n• “every project will have use cases for: “\n• verify for pythenians and pyth holders\n• every community member will benefit from activities on new projects\n“ In house benefits “\n1- current community benefits and support for pythians\n2- new friends in temple\n3- Pyth growth and flywheel of current eco\n4- making sure everybody get rewarded for their help\ni would love to have bruvs :\namensch as wisest and elder on every opinion\nkobak as designer and vibe master\nricardo , he is active between community can help alot on bringing ideas and tell the tails to others\njeetalik as secret coordinator for vc and events and vibe checker for creators\nBorys for amazing gifs and memes , he can keep and create culture , art and tails are culture among a community\ncouncil members, they know what to do .\nat the end , every new project will have a taste of pythians injection as core community .\n–\non event of a project hiring current cohort of legions\ni do know one thing tho , money take people away .\n\npeople who may help alongside new project , they get winning prize to work with + their rev\npeople who work on PGT and advising or side work require some donation from Pyth DAO, in case of success\n\nAngel investors , required to fund the newly working project to PYTH DAO\nhaving Tx , on launch they own a % of project , for individuals investors\n\ntoken\nproject rev\nproject stake holding\nthings attached to new proj\n\nKYC needed . with Pyth team or council\n\non event of failure, current community and partners will try to gather put all brains together and make it happen\nif not , PYTH DAO only spends when its required for spending\nproduct first .\n\nPotentially Dev’s can build in Pyth Deep estate\nbest regard euko\n\n 3\n\n post by eukodal on Sep 30, 2025\n\n eukodal\n\n 10000443731080×466 60.9 KB\nsome visuals , graduated projects\nnew proj must meet :\n1, demand\n2, lack of this new proj in eco\n3, strategic trend analysis for better outcome\n\n post by ed_pyth on Oct 2, 2025\n\n ed_pyth\n\n Hello. Firstly, I really appreciate how thoughtful and energetic this idea is. I’m very pleased you’re thinking about Pyth’s community, culture, and dev growth in such a grand way.\nPrima facie, my first concerns are that actually running something like this is a much, much steeper hill than it may seem: judging projects, doing proper due diligence, and avoiding conflicts of interest all take serious time and exertion\nMy suggestion would be to zoom in on one or two of the most promising parts of your proposal first (like community showcases or small-scale dev gatherings), then building it out from there\nStill, def a deeper discussion to be had\n\n post by eukodal on Oct 4, 2025\n\n eukodal\n\n if i may reach couple of devs in UAE on my side , and check if they be interested to build sub-tools for bigger projects\nalso can ask Pepito and Planck to check if they may know related people in this field\nwhich may take less time and effort\nthoughts on this\nin addition i appreciate your kind reply Ed\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pythians got talent\n\n Ideas Bank\n\n 1\n\n 76\n\n Sep 2025\n\n Pyth Playground Community Hackathon\n\n Ideas Bank\n\n 25\n\n 731\n\n Mar 11\n\n Community Hackathon post-mortem\n\n Community Council\n\n 6\n\n 239\n\n May 31\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n COMMUNITY PROJECT: Wheel of Pyth\n\n Ideas Bank\n\n 21\n\n 568\n\n Apr 6","tokens":1343,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267949402,"hash":"6c4722ca39d3a6c4d460ef7154d13b6c32e60c0d"}
{"url":"https://docs.optimism.io/app-developers/tools/data-and-dashboards/data-glossary?ref=blog.oplabs.co","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This glossary is a living document and will be updated over time as new metrics emerge or definitions evolve.\nMetricWhat It MeasuresWhy It MattersReal Economic Value (REV)Fees paid by users to transact (txn fees + out-of-protocol tips)Captures users’ willingness to pay for onchain activityCollective RevenueETH earned by the Optimism CollectiveRevenue can be directed by governance to support ecosystem growthTotal Value Locked (TVL)Tokens locked in DeFi protocols and other appsSupply side of the DeFi ecosystemGas Used per SecondAverage compute consumed onchainMeasures throughput and execution loadMedian Transaction FeeTypical cost for a user to transactLower fees reduce friction and may unlock broader usageMarket ShareOP Stack ecosystem’s share of activity vs. the broader crypto industryTracks relative performance against L2s or the broader market\n​Measure Demand\n​Transaction Fees Paid\nMetric: Real Economic Value (REV)\nDefinition: The total fees paid to execute a transaction onchain. This includes both the traditional gas fees required for inclusion onchain and additional fees paid to transaction execution services (e.g., Jito, Flashbots, Timeboost).\nCalculation: Gas Fees + Out-of-Protocol Tips (e.g., Jito, Flashbots, Timeboost)\n\nOut-of-Protocol Tips can be sourced from Defillama’s MEV category\n\nWhy it matters:\n\nREV is a topline metric that “measures the monetary demand to transact onchain” (Blockworks).\nIt’s used as a proxy for users’ willingness to pay, capturing all transaction fees to better reflect real demand (excludes app-level fees like DEX swap costs).\n\n​Revenue\nMetric: Estimated Optimism Collective Revenue (Collective Revenue)\nDefinition: The amount of ETH expected to be earned by the Optimism Collective from revenue sharing.\nCalculation: For each chain, take the greater of (a) 2.5% of Chain Revenue or (b) 15% of Net Onchain Profit. OP Mainnet contributes 100% of Net Onchain Profit.\nKey Components:\n\nNet Onchain Profit: Chain Revenue - L1 Gas Fees\nChain Revenue: Sum of the L1 Data Fee + L2 Base Fee + L2 Priority Fee + L2 Operator Fee (Also includes any additional fee types added in the future.)\nL1 Gas Fees: Total gas fees spent by the chain on L1 in transaction batches (including blob costs) and state output submissions or dispute games.\nTransaction Batches: All transactions where the transaction from address is the batcherHash address as defined in the chains’ SystemConfigProxy contract, and the transaction to address is the chain’s batch_inbox_address as defined in the rollup config.\nState Output Submissions or Dispute Games: All transactions where the transaction from address is the Proposer and the transaction to address is either the outputOracleProxy or the disputeGameFactoryProxy as defined in the chains’ SystemConfigProxy contract.\nEach chain’s SystemConfigProxy contract can be found in the superchain-registry.\nResolving Dispute Games: All transactions sent to dispute game contracts created by the disputeGameFactoryProxy, where the transaction’s method id (function call) is either Resolve, ResolveClaim, or ClaimCredit.\n\nWhy it matters:\n\nThis is what the Optimism Collective earns by operating OP Stack chains, which can be directed by governance to support ecosystem growth.\nSee How (and why) the OP Stack drives fees to the Optimism Collective (Optimism blog, Aug 2024)\n\n​Onchain Signals\n​Value Onchain\nMetric: Total Value Locked (TVL)\nDefinition: “Value of all coins held in smart contracts of the protocol” (Defillama).\nCalculation: The sum of all USD value of assets locked in applications, as reported by DefiLlama.\n\nTVL can be priced in USD or a crypto asset like ETH, but both are subject to price volatility. USD is often used because it’s easier to interpret and consistent across the broader crypto ecosystem.\n\nWhy it Matters: TVL represents the supply side of onchain economic activity for use in protocols such as Decentralized Exchanges (DEXs) and lending markets. Strong TVL in the right places may enable greater onchain demand.\n​How to Measure Growth: Net TVL Flows\nBecause TVL is influenced by market fluctuations, it can be misleading when trying to measure true growth or user behavior. Net TVL Flows can adjust for this by tracking the net change in token balances, valued at current prices.\nCalculation: ( # of Tokens on Day N - # of Tokens on Day 0 ) * Price of Tokens on Day N\nExample: If an app has 100,000 ETH locked on Day 0 when ETH/USD is 2,000,and90,000ETHlockedat2,000, and 90,000 ETH locked at 3,000 on Day N:\n\nNet TVL Flows = −10,000 ETH × 3,000=3,000 = 30 million in net outflows\nNaive TVL change would suggest growth: 200million→200 million → 270 million\n\n​Network Usage & Infrastructure\nMetric: Gas Used per Second (gas/s)\nDefinition: “Gas refers to the unit that measures the amount of computational effort required to execute specific operations on Ethereum” (ethereum.org). Gas Used is tracked as an average rate per second for simplicity.\nWhy it Matters: Gas, sometimes referred to as blockspace, is the limited resource that blockchains provide. Gas used shows how much of that resource is actually being consumed.\nCaution: Gas is only comparable across chains that use Ethereum-equivalent gas units.\n​User Experience (UX)\nMetric: Median Transaction Fee (USD)\nDefinition: The median gas fee paid to submit a transaction, expressed in USD for simplicity and easier comparison across ecosystems.\nCalculation: Median of all transaction fees over a period of time, marked at the USD price at the time of the transaction.\nWhy it Matters: This metric serves as a proxy for the cost to transact. Lower median fees enable broader usage by reducing friction, lowering breakeven costs, and unlocking use cases that would otherwise be cost-prohibitive.\n​Market Share\nDefinition: The OP Stack ecosystem’s share of a broader market segment for any measure (e.g., L2s, total crypto).\nCalculation: OP Stack Metric Value / Total Market Metric Value\nWhy it Matters: Market share helps isolate whether growth is driven by the OP Stack ecosystem itself, or is simply part of a broader market trend. A rising share signals outperformance, while a declining share suggests that other ecosystems are growing faster.Was this page helpful?","tokens":1557,"squid":"ink-governance","role":"Council Listener","at":1791267956113,"hash":"939c6d6f3c22c2c39a409cf73b6281cfcb9c2e43"}
{"url":"https://forum.pyth.network/t/community-council-1-council-members/2071/5","domain":"forum.pyth.network","title":"[Community Council #1] Council Members - Community Council - Pyth DAO","text":"Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 5 / 5\n\n Apr 24\n\n Apr 24\n\n post by Pyth-DAO on Mar 27, 2025\n\n Pyth-DAO\n\n On March 27th, 2025, the first-ever Community Council has been elected and approved by the Pyth DAO through onchain voting.\nAs a reminder, at least 1 member of the Community Council has to be replaced every 12 months.\nAs per the Pyth DAO Constitution, the Community Council is comprised of 7 members who are signers of the Community Council Multisig Wallet.\nThe composition of the Community Council aims for geographical diversity to better fulfill and realize the ethos, mission and guiding values of the Pyth DAO and community.\n\nDerrp\nNoname Trader\nPlank\nArguer\nBats\nChop\nLowkeigh\n\n [PASSED] OP-PIP-114: Community Council Term 1 Cycle 2 Stipend Disbursement\n\n Pinned on Mar 27, 2025\n\n post by N0name_trader on Mar 27, 2025\n\n N0name_trader\n\n We will do our best to serve the community interests and promote Price Layer of the World to the new highs! Thanks for believing in us!\n\n post by smartcoded on Mar 27, 2025\n\n smartcoded\n\n let them cook for the communities\n\nDerrp\nNoname Trader\nPlank\nArguer\nBats\nChop\nLowkeigh\n\n 1 year later\n\n post by theretardedadrian on Apr 24\n\n theretardedadrian\n\n N0name_trader\n\n I’m from the future april 2026 and I must say you have achieved it.\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Guide for the Community Council Election #2\n\n Community Council\n\n 0\n\n 269\n\n Mar 26\n\n [PASSED] CO-PIP-6: Creation of the Community Council\n\n Proposals\n\n constitutional-pip\n\n 1\n\n 498\n\n Feb 2025\n\n [Pythian Council #1] Council Members\n\n Pythian Council\n\n 1\n\n 486\n\n Sep 2024\n\n Guide for the Community Council Election #1\n\n Community Council\n\n 6\n\n 412\n\n Mar 2025\n\n [Pythian Council #3] Council Members\n\n Pythian Council\n\n 0\n\n 152\n\n Apr 2025","tokens":472,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267959623,"hash":"63458d444a760daf68c6dd323790508f31798ba8"}
{"url":"https://docs.optimism.io/app-developers/tools-sdks/support-matrix","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Items on this page refer to third-party projects or products that are not\nmaintained by Optimism. They are provided for convenience; refer to each\nproject’s own documentation as the source of truth.\nThis page is the canonical hub for the tools and SDKs that surround the OP Stack.\nFollowing the content guide, each listing\nlinks exactly one canonical documentation home — this page routes, it does not\nrestate. What gets listed here (and what gets removed) is governed by the\nlisting criteria.\n​Support Status Levels\nStatusMeaningProductionStable and recommended for production use by its owner.Developer previewUsable today, but its owner has declared it not yet ready for production; APIs may change.ExperimentalA staging ground. Features may change, move, or be upstreamed elsewhere.\n​The Matrix\nToolPurposeOwnerCanonical docsSupport statusviem/op-stackGeneral-purpose TypeScript client for OP Stack chains: deposits, withdrawals, L1 gas estimation, and all standard chain interaction, built into viemwevm (third party)viem.sh/op-stackProduction@eth-optimism/viemviem extension for OP Stack features that have not yet been upstreamed into viem — Superchain interop actions and utilities; used by this site’s bridging and interop tutorialsOptimism (ecosystem repo)Package README & SDK referenceExperimentalActions SDK (@eth-optimism/actions-sdk)High-level abstractions for building onchain apps — wallet, lend, and swap namespaces over Superchain protocolsOptimism (actions repo)Actions quickstart and reference on this siteDeveloper previewwagmiReact hooks for Ethereum apps; works with OP Stack chains as with any EVM chainwevm (third party)wagmi.shProductionsupersimLocal Superchain simulator: one L1 plus multiple OP Stack L2s for testing L1↔L2 and L2↔L2 message passing without deploying to live networksOptimism (supersim repo)Supersim docsDeveloper preview (all releases are alpha pre-releases; interop features in active development)super-cli (sup)Foundry companion CLI for multichain workflows: deploy and verify contracts on multiple chains at once, bridge funds, use connected walletsOptimism (super-cli repo)Repository READMEExperimentalsuperchain-registry toolingNot an SDK — the source-of-truth library of chain configs that OP Stack software (such as op-node and op-geth) consumes, plus the just tasks and validation checks used to add and verify a chainOptimism (superchain-registry repo)Registry operations docsProductionop-alloyRust crates for interfacing with OP Stack chains: consensus, RPC, engine, and network types built on the Alloy ecosystem; the type layer consumed by kona and op-rethOptimism (rust/op-alloy in the monorepo)op-alloy docs on this siteDeveloper preview (owner-declared not yet production-ready; APIs may change)op-revmRust crate implementing the OP Stack’s EVM: a revm variant with deposit transactions, L1 and operator fee accounting, and OP-specific precompiles; the EVM inside op-reth and konaOptimism (rust/op-revm in the monorepo, vendored from upstream bluealloy/revm)op-revm docs on this siteProduction (consumed transitively through op-reth or kona by most users)\n​Choose an SDK Surface\nThree of the rows above are TypeScript SDK surfaces that are easy to confuse.\nThe distinction:\n\nStart with viem/op-stack. viem provides\nfirst-class OP Stack support in the core library: extend any viem client\nwith publicActionsL2() (and friends) imported from viem/op-stack to get\ndeposits, withdrawals, and L1 gas estimation. If a feature is available\nhere, this is its production home. Super Root withdrawal proving requires\nviem 2.51.0 or later.\nReach for @eth-optimism/viem\nwhen you need what viem does not have yet. The package’s stated goal is\nto upstream as much as possible into viem itself; until then it is the\nhome of Superchain interop actions and other pre-production features. The\ninterop tutorials\nand bridging tutorials\non this site use it.\nUse the Actions SDK for app-level\nbuilding blocks, not chain plumbing. Where the two viem surfaces expose\nprotocol operations, the Actions SDK offers wallet, lend, and swap\nnamespaces for building end-user apps. It is a developer preview and not\nyet ready for production use.\n\nBuilding in Rust rather than TypeScript? Start from\nop-alloy for OP Stack types and RPC\nsurfaces and op-revm for execution, and see\nthe Stack Components index for the Rust clients\nthemselves (op-reth, kona-node, kona-client).\n​Using wagmi With the OP Stack\nIf you build with React, you likely start from wagmi — and it works with OP\nStack chains out of the box. OP Stack chains are standard EVM chains, and\nwagmi/chains ships their definitions (optimism, base, zora, and every\nother chain from viem/chains). Nothing OP-specific is required for reads,\nwrites, or wallet connections.\nFor OP Stack–specific operations — deposits, withdrawals, interop — use the\nfact that wagmi is a wrapper over viem:\n\nGet a viem client from wagmi with the\nuseClient or\nuseConnectorClient\nhooks, following wagmi’s own\nviem guide.\nExtend that client with the viem/op-stack\nactions and call them directly.\n\nFor Superchain interop specifically, the experimental\n@eth-optimism/wagmi\npackage provides React hooks (such as useSendL2ToL2Message) over\n@eth-optimism/viem. Treat it like its underlying package: experimental.\n​Next Steps\n\nRead the listing criteria and maintenance-sweep policy\nthat govern this page.\nAdding a chain rather than building an app? See\nJoin the Superchain Registry.\nFor where content belongs in general, see the\ncontent guide.\nWas this page helpful?","tokens":1380,"squid":"ink-governance","role":"Council Listener","at":1791267968680,"hash":"773953cad231927b8cb6c95759ff651396ca5f13"}
{"url":"https://forum.pyth.network/t/guide-for-the-community-council-election-2/2423","domain":"forum.pyth.network","title":"Guide for the Community Council Election #2 - Community Council - Pyth DAO","text":"Guide for the Community Council Election #2 \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 26\n\n 1 / 1\n\n Mar 26\n\n Mar 26\n\n post by Chop on Mar 26\n\n Chop\n\n What is the Community Council?**\nAs defined in the adopted [Pyth DAO Constitution]( governance/docs/constitution/pyth-dao-constitution.md at main · pyth-network/governance · GitHub ), the Pyth Community Council comprises 7 members who sign the Community Multisig Wallet with a 6-signer requirement. The multisig wallet executes actions delegated by the Pyth DAO.\nCore mandates include:\n* **Value Creation**: Budget requests, Impact Awards program oversight, and community-focused development\n* **Collective Voice**: Community interest representation, governance participation, partnership development, and cross-ecosystem collaboration\n* **Network Growth**: Educational content, community research, and strategic partnerships\nEach council member assumes a specific role:\n* **Council Lead**: Strategic oversight and leadership\n* **Administration**: Impact Awards, community budget, and product development oversight\n* **Impact Operations**: Develops Pyth community social initiatives\n* **Partnerships & Collaborations**: Fosters web3 community relationships\n* **Analyst**: Monitors governance, product development, and competitive analysis\nCouncil members serve 12-month terms. The inaugural Community Council was elected in March 2025.\n-–\n## The 2nd Community Council\nPer the Pyth DAO Constitution, council members who received the fewest votes in the previous election are subject to replacement. One member (bats4) is voluntarily stepping down from the council.\n**The 2nd Community Council Election must elect 1 new council member. They will join the 6 continuing members.**\nAll current council members are eligible to run for re-election. Candidates who are not current members are also welcome to self-nominate.\nFor full context on what the Community Council delivered during Term 1 and what Term 2 will fund, see:\n* [Community Council Term 1 Exit Report]( Community Council Term #1 Exit Report )\n* [Community Council Term 2 Budget Request]( Community Council Term 2 Budget Request )\n-–\n## How to Submit Candidacy\n*Eligibility requires Pyth staker status throughout application and potential term duration.*\nThe election process involves 2 steps:\n### Step 1: Forum Self-Nomination\nNominate yourself on the Pyth forum under the **Community Council** category using this template:\n-–\n**Topic Title**: [Community Council Election #2] Candidate Name, Protocol/Team (if applicable)\n**Wallet address (SPL/Solana)**: [Your Solana wallet address]\n**Describe how you will custody your private key** (hardware wallet, MPC provider such as Fireblocks, etc):\n**Name of Candidate**:\n* Full Name:\n* Twitter handle:\n* Discord handle:\n* Github handle:\n**Motivations to participate in the Community Council**:\n* …\n* …\n* …\n**Relevant Experience**:\n* …\n* …\n* …\n-–\n**This first step must be done by Wednesday, April 2, 2026, 11:59 PM UTC.**\n### Step 2: On-Chain Voting\nOn Thursday, April 3, 2026, a multi-choice proposal will be created on [Pyth DAO Realms]( Realms ) listing all nominees.\nVoting will last one full week from proposal creation.\n-–\n## Timeline for Council Formation\n| Phase | Date |\n|—|—|\n| **Forum Nomination Opens** | Thursday, March 27, 2026 |\n| **Forum Nomination Deadline** | Wednesday, April 2, 2026, 11:59 PM UTC |\n| **On-Chain Voting (Realms)** | Thursday, April 3, 2026 — Wednesday, April 9, 2026 |\n| **Community Council Approval** | From Monday, April 13, 2026 — PYTH stakers approve the elected Council and budget via binding OP-PIP vote |\n-–\n## Frequently Asked Questions\n**Do I need to be a current community contributor to run?**\nNo. Any PYTH staker can self-nominate. That said, voters tend to favor candidates with a visible track record of community involvement.\n**Can current council members run for re-election?**\nYes. Incumbents are eligible to self-nominate under the same process.\n**How does voting work?**\nPYTH stakers vote on-chain through Pyth DAO Realms. Voting weight is proportional to staked PYTH.\n**What’s the time commitment?**\nCouncil members are expected to actively participate in program oversight, governance decisions, and community operations throughout the 12-month term.\n**Is the council compensated?**\nYes. Council stipends are paid directly from the DAO treasury to council members — not from the council multisig. This avoids a conflict of interest. See the [Term 2 Budget Request]( Community Council Term 2 Budget Request ) for details.\n**How quickly do funds arrive after the vote?**\nThe token transfer is part of the election instructions. As soon as the binding OP-PIP proposal is executed on-chain, the funds move to the Council wallet.\n-–\n## Key Links\n* [Pyth DAO Constitution]( governance/docs/constitution/pyth-dao-constitution.md at main · pyth-network/governance · GitHub )\n* [Pyth DAO Realms]( Realms )\n* [Community Council Term 1 Exit Report]( Community Council Term #1 Exit Report )\n* [Community Council Term 2 Budget Request]( Community Council Term 2 Budget Request )\n* [CO-PIP-6: Creation of the Community Council](https://forum.pyth.network/t/passed-co-pip-6-creation-of-the-community-council/1828)\n* [Guide for the Community Council Election #1]( Guide for the Community Council Election #1 )\n-–\n*Questions? Tag the Community Council in Discord or comment below.*\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Guide for the Community Council Election #1\n\n Community Council\n\n 6\n\n 412\n\n Mar 2025\n\n [PASSED] CO-PIP-6: Creation of the Community Council\n\n Proposals\n\n constitutional-pip\n\n 1\n\n 498\n\n Feb 2025\n\n [Community Council #1] Council Members\n\n Community Council\n\n 3\n\n 287\n\n Apr 24\n\n Guide for the 5th Pythian Council Election\n\n Pythian Council\n\n 0\n\n 105\n\n May 12\n\n [PASSED] OP-PIP-57: Community Council Election and Budget Approval\n\n Proposals\n\n operational-pip\n\n 0\n\n 313\n\n Mar 2025","tokens":1502,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791267971969,"hash":"c0d00b7711bbe2a2ad45392cca3615b2aed3221c"}
{"url":"https://io.net/blog/ai-infrastructure-compute","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogAI Infrastructure & ComputeLatest By Topic (38)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsHow Leonardo.Ai Scaled from 14K to 19M Users While Cutting GPU Costs by 50%+ with io.netIO.NET Team / May 11, 2026See how Leonardo.Ai scaled from 14K to 19M users and cut GPU costs by over 50% using io.net's high-performance, affordable compute solution for generative AI.Parallel Computing: A Complete Guide to Models, Hardware, and Cloud ServicesIO.NET Team / Dec 16, 2025Solve compute bottlenecks with parallel computing. Compare models (parallel, concurrent, distributed), hardware, cloud costs, and best practices for performance gains.New Research Shows Consumer GPUs Can Cut AI Inference Costs by 75%IO.NET Team / Dec 5, 2025New io.net study shows consumer GPUs (RTX 4090) can cut AI inference costs by up to 75% for LLMs, enabling a sustainable, heterogeneous compute infrastructure.AI Training vs Inference: Key Differences, Costs & Use Cases [2025]IO.NET Team / Nov 28, 2025AI training teaches models to recognize patterns. AI inference applies those models to make predictions. Learn the differences, costs, and optimization strategies in io.net’s complete guide.\nGPU vs CPU for AI: Complete Performance, Cost, and Use Case Comparison for 2025IO.NET Team / Nov 21, 2025Complete comparison of GPU vs CPU for AI: deep learning performance, hardware cost, TCO, and ideal use cases. Choose the right processor for your training and inference workloads.How To Stop Being An Ostrich: Creating Real Value With BlockchainIO.NET Team / Nov 12, 2025Blockchain promised to solve centralization, but focused on wrong problems. DePIN networks like io.net finally deliver real value through affordable GPU access.Introducing Unified Chat: One Interface for Every AI Model and ToolIO.NET Team / Nov 4, 2025Unified Chat is the single, intelligent AI workspace that unifies every model and tool. Auto-routes for optimal quality and cost. End fragmentation.GPU as a Service: Financial Guide for AI StartupsIO.NET Team / Oct 31, 2025Complete financial framework for GPU infrastructure decisions. Cost modeling, ROI analysis & budget optimization for AI companies. io.net Breaks $20M in Annualized On-Chain RevenueIO.NET Team / Oct 21, 2025io.net surpasses $20M in verifiable on-chain revenue, proving decentralized GPU infrastructure can compete with AWS and GCP on cost, performance, and real-world adoption.ML Model Deployment: Cut Costs 90% With Decentralized InfrastructureIO.NET Team / Oct 14, 2025Model deployment connects trained ML models to users, yet most stall due to cloud costs and vendor lock-ins. Decentralized platforms cut costs 90%.Decentralized Cloud Computing: A Complete Guide to the Future of AI InfrastructureIO.NET Team / Aug 31, 2025Learn how io.net evolved from trading infrastructure to decentralized GPU cloud computing, using distributed resources and blockchain for scalable AI.Mobile Edge Computing: The Future of Distributed ProcessingIO.NET Team / Aug 4, 2025Mobile Edge Computing + 5G enables low-latency, secure AI/ML apps by processing data locally, complementing cloud in hybrid architectures.Page 1 of 4","tokens":864,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267974764,"hash":"50cf7e42348683b3f94b05ad4840520413a84acb"}
{"url":"https://docs.optimism.io/app-developers/tools-sdks/supersim","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Interop is currently in active development and not yet ready for production use. The information provided here may change. Check back regularly for the most up-to-date information.\nSupersim is a local development environment tool designed to simulate the OP Stack for developers building multi-chain applications. It provides a simplified way to test and develop applications that interact with multiple chains within the OP Stack ecosystem.\n​Supersim workflow\n\nThis diagram illustrates the typical workflow for developers using Supersim, from writing smart contracts to testing and refining cross-chain interactions.\n​Features and benefits\n\nSimulates multiple OP Stack chains locally (e.g., chain 901, 902)\nSupports testing of cross-chain messaging and interactions\nIncludes pre-deployed interoperability contracts\nOffers a CLI interface for starting and managing Supersim instances\nProvides local JSON-RPC endpoints for each simulated chain\nAllows for custom configuration of chain parameters\nFacilitates testing of Superchain-specific features like cross-chain token transfers\nEasy to use with common Ethereum development tools\nSupports chain forking\n\n​Supersim CLI interaction\n\nThis diagram illustrates how developers interact with Supersim through the CLI, which simulates OP Stack-specific features (specifically interop) on locally run chains, each with its own JSON-RPC endpoint and pre-deployed interoperability contracts.\n​Next steps\n\nView more Supersim tutorials\nWas this page helpful?","tokens":374,"squid":"ink-governance","role":"Council Listener","at":1791267978595,"hash":"0eb538ce1ca4b7adef009b059dd6ec6491e01ba6"}
{"url":"https://io.net/blog/developer-resources","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogDeveloper ResourcesLatest By Topic (10)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsCentralized vs. decentralized AI compute: What every developer should knowIO.NET Team / Aug 25, 2026Anyone who rented a GPU knows the routine. You visit AWS, navigate to a p4d instance, quickly hit a quota wall, file a support ticket, wait three days, and finally get your A100. Or perhaps that’s not your experience. Instead, maybe you got an \"insufficient capacity\" error and moved on to GCP. Either way, you ran your workload and didn't think much about what was happening underneath.\n\nThis infrastructure experience of waitlists, opaque pricing, and quotas is the intentional design of centralizeH100 or H200 for DeepSeek V4 Flash? What we measured in productionIO.NET Team / Aug 21, 2026We served the same model on both H100 and H200, under identical live traffic, for ten days. The results were not quite what the spec sheets would suggest, and the biggest factor turned out to be something neither datasheet mentions.\nThe Essential Guide to Cost-Effective MLOpsIO.NET Team / Jul 7, 2025Most ML models fail not from bad algorithms but from $50K/month cloud bills. Learn how decentralized GPUs slash costs 70% while keeping enterprise performance.Introducing Total Network Earnings: Transparent TrustIO.NET Team / May 19, 2025io.net launches Total Network Earnings (TNE) for complete transparency in AI infrastructure costs with real-time tracking, automated payments, and verifiable metrics.io.net Decentralized GPU Network: Simplifying AI Deployment on Solana with Developer ToolsIO.NET Team / Apr 6, 2025io.net's developer tools provide simplified API integration and decentralized GPU access, reducing AI deployment costs by up to 90% compared to centralized providers.Your io.net Guide to GPU Cloud & Hardware InnovationIO.NET Team / Mar 16, 2025A comprehensive guide to launching and managing virtual machines and containers on IO.net's decentralized GPU cloud platform for cost-effective computing.Getting Started with io.cloud: Deploying and Managing Your Virtual MachinesIO.NET Team / Mar 9, 2025A comprehensive guide to launching and managing virtual machines and containers on io.net's decentralized GPU cloud platform for cost-effective computing.How Decentralized AI Infrastructure Solves GPU Bottlenecks for Machine Learning TeamsIO.NET Team / Jun 10, 2024Decentralized GPU networks cut AI training costs by up to 70%, boost flexibility, and overcome centralized cloud bottlenecks for scalable, global ML.AI Developers Need Real-Time Monitoring - Here’s WhyIO.NET Team / Mar 17, 2024io.Intelligence delivers real-time monitoring for AI workloads, helping optimize performance, cut costs, and ensure reliable system stability.Developer & Technical Guides: Building on io.netIO.NET Team / Mar 10, 2024\"IO.net offers a decentralized GPU cloud, enabling scalable, cost-effective AI training, rendering, and simulations with global resources.\"","tokens":818,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267984698,"hash":"1c3517ac21819a4bee77d90390d4b9751d06a692"}
{"url":"https://forum.openzeppelin.com/t/crowdsale-contract-with-token-already-deployed/15526/6","domain":"forum.openzeppelin.com","title":"Crowdsale contract with token already deployed - Support - OpenZeppelin Forum","text":"Support\n\n erc20,crowdsale\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Sep 2021\n\n 6 / 6\n\n Feb 2022\n\n Feb 2022\n\n post by David_Gamboa on Sep 14, 2021\n\n post by FreezyExIsNotABitch on Sep 14, 2021\n\n FreezyExIsNotABitch\n\n What exactly do you want to do?\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Hi! I want users to enter my website and be able to buy my Bep20 token with BNB using their Metamask wallet. I would like to be able to modify the beginning and end of the ICO. In such a way that those values ​​could modify them.\nThe token is already on the blockchain. Now I need to create a crowdsale contract that makes the sale. But I don't know how to relate the contract of my already deployed token with the crowdsale contract.\nThanks!\n\n post by Skyge on Sep 14, 2021\n\n Skyge\n\n Maybe you can have a look at this tutorial:\n\nSimple ERC20 Crowdsale\n\n post by David_Gamboa on Sep 14, 2021\n\n David_Gamboa\n\n Thanks. Yes I saw it. The problem is that having the BEP20 token already deployed I can't put the \"SimpleToken.sol\" contract and I don't know how to write the \"2_deploy.js\" so that it relates to my Bep20 token\n\n 5 months later\n\n post by BigMadCode on Feb 16, 2022\n\n BigMadCode\n\n Hi David,\nwere you able to resolve this?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Deploy a crowdsale contract for a previously deployed ERC20 token\n\n Smart Contracts\n\n erc20\n\n 2\n\n 535\n\n May 2022\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021\n\n Simple ERC20 Crowdsale\n\n Guides and Tutorials\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025","tokens":451,"squid":"ink-security_audits","role":"Sentinel","at":1791267986461,"hash":"8050f747c0e0f7764c7a641ed507ee3fd060e15c"}
{"url":"https://docs.optimism.io/app-developers/tools-sdks/faucets","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Faucets are developer tools that allow you to get free ETH (and other tokens) on test networks like Sepolia and OP Sepolia so that you can send transactions and create smart contracts.\nHere you’ll find a list of active faucets that you can try out.\nDifferent faucets use different authentication methods, so you may have to try a few before you find one that works for you.\nFaucets can occasionally also run out of ETH, so if you’re having trouble getting ETH from a faucet, try another one.\nTokens on test networks like Sepolia or OP Sepolia have no value and are only meant for testing.\nOptimists only take what they need so that others can use faucets too!\n​Optimism’s faucet\nThe Optimism’s faucet is a developer tool hosted by Optimism that allows developers to get free testnet ETH to test apps on testnet OP Chains like Base Sepolia, OP Sepolia, PGN Sepolia, Zora Sepolia, and other OP Stack chains.\nOptimism’s faucet is a great place to start if you’re looking for testnet ETH.\n​Additional faucets\nFaucet NameSupported NetworksAlchemy FaucetSepoliaChain Platform FaucetSepoliaEthereum Ecosystem FaucetsSepolia, OP Sepolia, Base SepoliaETHGlobal Testnet FaucetSepolia, OP Sepolia, Base Sepolia, Zora Sepolia, HoleskyFarcaster Frame Faucet by LearnWeb3Sepolia, OP SepoliaInfura FaucetSepoliaNative USDC FaucetSepolia, OP SepoliaQuickNode FaucetSepolia, OP SepoliaTenderly Unlimited FaucetOP Sepolia, OP Mainnet, and 85+ other networksthirdweb OP Sepolia FaucetOP Sepoliathirdweb Sepolia FaucetSepoliaethfaucet.comSepolia, OP Sepolia, Base Sepolia, Zora Sepolia, Unichain Sepolia, Ink Sepolia, Mode Sepolia, Shape Sepolia, Worldchain Sepolia, BOB Sepolia\n​Bridge from Sepolia\nIf you have testnet ETH on Sepolia, you can bridge it to OP Sepolia (and vice versa) using the Superchain Bridges UI or this collection of Superchain Testnet Tools.\n​Next steps\n\nIf you’re new to onchain development, check out Optimism Unleashed by CryptoZombies and Superchain Builder NFT by ThirdWeb.\nIf you’re familiar with onchain development, check out the Optimism Ecosystem’s Contributions Dashboard for project ideas that Optimism is looking for.\nLooking for other developer tools? See the building apps overview to explore more options!\nWas this page helpful?","tokens":562,"squid":"ink-governance","role":"Council Listener","at":1791267988520,"hash":"034a318ee261e513a84c6a9e70fd438b37df0069"}
{"url":"https://io.net/blog/io-net-decentralized-gpu-network-solana","domain":"io.net","title":"io.net Decentralized GPU Network: Simplifying AI Deployment on Solana with Developer Tools","text":"Back To Blogio.net Decentralized GPU Network: Simplifying AI Deployment on Solana with Developer ToolsIO.NET Team / Apr 7, 2025Try io.intelligenceGet StartedTry io.cloudDeploy GPUDeveloper ResourcesAI Infrastructure & ComputeArtificial Intelligenceio.intelligenceQuick ReadsDeploying AI projects on blockchain rails seems like a natural fit. Yet, there are real obstacles that have to be overcome for two technologies to work seamlessly. Permissioned and costly access to centralized GPUs and the technical complexity of managing them are among the largest barriers to developing AI crypto products. Centralized corporations control access to advanced computing resources, such as GPU and CPU power, making it expensive and limiting for developers who need scalable, high-performance hardware for AI and ML workloads. As artificial intelligence continues to drive demand for accessible, scalable computing infrastructure, decentralized GPU resources are becoming essential for cost-effective AI model development and deployment.Large investments in the same private, centralized tech monopolies that dominated Web2 have created GPU moats, stifling AI innovation on blockchains. io.net offers novel solutions to these problems through on-demand, permissionless, decentralized GPU clustering models. io.net leverages independent data centers to provide decentralized GPU resources, which increases flexibility, lowers costs, and reduces the risk of single points of failure.As a decentralized cloud computing platform, io.net offers significant advantages over traditional centralized cloud services. io.net's decentralized model distributes workloads and risk across many independent nodes, enhancing reliability and minimizing single points of failure. Crypto projects are increasingly leveraging blockchain technology and decentralized networks to create marketplaces for idle GPU power, enabling platforms like io.net to tap into resources from crypto miners and other blockchain-based initiatives for distributed, cost-effective GPU computing.io.net was established to address these challenges and provide a robust platform for distributed GPU access. io.net connects users directly to thousands of GPU owners worldwide, eliminating middleman markups and ensuring better prices and immediate availability.The Need for a Decentralized GPU NetworkBecause centralized providers have long been the only viable option for AI compute, developers have little choice but to rely on them, despite their high costs and technical complexity. Centralized corporations have historically controlled access to hardware and compute resources, raising significant barriers for developers seeking affordable and scalable solutions. This reliance creates a vendor lock-in, where devs are subject to fluctuating prices and scalability limitations, often making it infeasible for smaller, open-source projects to compete. Big Tech compute providers can also introduce latency issues by restricting GPU access without warning, causing bottlenecks and creating single points of failure in the compute supply chain. io.net’s decentralized physical infrastructure network eliminates reliance on a single entity and enhances resilience, ensuring a trustless, distributed, and secure environment. These constraints limit innovation and make AI development prohibitively expensive.As one of a growing number of decentralized physical infrastructure networks (DePIN), io.net’s decentralized GPU clustering model addresses these challenges by offering a frictionless API deployment process and tapping into an internet of underutilized GPU compute.io.net's clusters of GPUs and aggregate hardware from various sources across the global to serve the high demand for GPU power needed for model training. The platform enables AI teams to parallelize AI model training and tuning processes by leveraging decentralized computing resources effectively. This permissionless access enables anyone to leverage the io.net cloud, thereby lowering entry barriers, reducing compute costs over time via competitive sourcing, and eliminating the risk of a centralized honeypot for malicious actors.io.net offers access to GPUs at up to 70% lower cost than traditional cloud providers like AWS. The platform empowers users to scale GPU flexibly, paying only for what they use without long-term contracts. io.net also provides instant access to thousands of GPUs, enabling AI teams to deploy AI workloads quickly.The Technical Infrastructure Powering io.netAt the heart of io.net’s offering is a robust technical infrastructure built around a decentralized compute network. This infra delivers the computing power essential for advanced AI and machine learning applications. The platform’s architecture supports decentralized computing, enabling teams to not only tap into a global network of GPUs but also dynamically scale their compute resources as demand fluctuates.Security compliance and optimized resource usage are also core priorities, so that AI models run reliably and securely across many independent nodes. By integrating blockchain technology and utilizing its native cryptocurrency, IO tokens, io.net facilitates secure, transparent payments and compute allocation throughout the network. This infrastructure not only enhances the security and integrity of the platform but also provides teams with the confidence that their AI workloads are supported by a resilient, decentralized, and high-performance environment.Simplified Worker Portal for Computing PowerAt the core of io.net’s model is the ease of API integration for providers. Understanding that simplified GPU integration is the key to unlocking trapped compute, io.net removes the technical barriers of navigating intricate setups and configurations. This ease of setup is reinforced through a dynamic and secure real-time monitoring interface for compute providers.Becoming a provider can be completed in a few minutes by following the io.net Quick Start Guide and connecting to a Solana or Aptos Wallet. Providers and users must generate an IO ID, which serves as a control center for the IO Ecosystem, to access the platform and manage their compute. Once established, providers can track their earnings using their Dashboard. GPU suppliers on the io.net network are paid in IO tokens only, with 300 million reserved for rewards to suppliers for jobs completed using their GPU, distributed hourly over 20 years.These transactions and rewards take place within the broader IOG network, also known as the Internet of GPUs, which powers decentralized compute resources and AI training.The io.net ecosystem optimizes GPU supply through smart task allocation and workload management, using fault monitoring, reporting, and analytics layers. Users are active participants who interact with the platform, monitor jobs, and access compute. Providers can also access real-time earnings insights, adding transparency and control. These features make GPUs more readily available and affordable while reducing dependence on centralized providers, eliminating single points of failure, and minimizing bottlenecks.io.net's Products and Servicesio.net’s comprehensive suite of products and services is designed to meet the needs of AI developers. IO.net is a Decentralized Physical Infrastructure Network (DePIN) built on Solana that pools unused Graphics Processing Unit (GPU) power globally for AI and machine learning tasks. Our decentralized compute network is the backbone for scalable and secure AI model deployment. Designed to streamline the development process, this AI platform gives devs the tools and resources they need to create, test, and launch cutting-edge AI-powered products and services.IO tokens are the utility currency of the ecosystem, enabling seamless transactions between AI teams and GPU owners. As part of the broader movement of decentralized physical infrastructure networks, io.net leverages blockchain technology for transparency, cost efficiency, and scalability. With a strong emphasis on cost efficiency, scalability, and security, io.net’s products and services are already disrupting the traditional cloud compute landscape. To that end, we support a diverse lineup of AI models and applications, including natural language processing, computer vision, and predictive analytics, making it a versatile solution for the next generation of AI models and products.Navigating the Developer Toolsio.net’s API is built on RESTful principles, giving teams key insights and access to different elements of the io.net network. The IO API Explorer enables developers to analyze network insights, offering a clear advantage over closed, centralized alternatives. The platform's ability to efficiently handle large-scale, diverse workloads is made possible by the use of GPU clusters, which can be deployed and managed as unified resources for demanding AI workloads.Optimized for data-intensive AI tasks, such as model training and real-time inference, io.net leverages a Ray-based distributed computing framework to optimize task orchestration and parallelized workloads for machine learning. It utilizes mesh VPN architecture and IO Mesh Technology to reduce latency, which is essential for real-time AI inference. Engineers can deploy distributed GPU clusters in under 90 seconds, and developers can spin up massive GPU clusters in under two minutes. The platform enables developers to parallelize model training and tuning processes by utilizing distributed computing resources effectively.Instant AccessA defining feature of io.net is its ability to provide instant access to a global network of GPU power, streamlining the process of deploying AI models and applications. Developers no longer need to invest in or maintain costly infrastructure. Instead, they can tap into a vast pool of computing power on demand.Authentication StepsTo authenticate via a JWT token, follow these steps:Go to IO.net > Get Started > IO Explore > Workers tab.In the UI, right-click and select Inspect.In the Inspect tool, click Network.Refresh the Workers page.In the list of elements, click Devices.Scroll down to the Request Headers section.Copy and store the token.Note: The token remains valid for 21 days.Once authenticated, developers can use cURL to make API requests. io.net provides generous rate limits for each account:150 requests / 10 seconds (umbrella rate limit on Explorer)Summary: 100 requests / 5 minutesDetails: 100 requests / 5 minutesSearch: 80 requests / 1 minuteToken and TokenomicsIO, the native cryptocurrency at the core of io.net’s decentralized network, drives both participation and value creation across the network. IO tokens incentivize GPU suppliers to contribute their computing resources, ensuring a steady supply of GPU power for AI developers. They also facilitate secure, transparent payments between developers and GPU owners, supporting a healthy and sustainable marketplace for computational resources. Additionally, IO token holders can earn extra income by staking their tokens on io.net's nodes.With a $20M+ circulating supply of IO tokens and total network earnings, IO's tokenomics are designed to foster long-term growth and stability. The use of IO tokens drives the ecosystem's support of a wide range of AI applications, from machine learning to deep learning, and ensures that the benefits of the network are distributed fairly among all participants.A total of 800 million IO tokens will be minted on the Solana blockchain. The token currently trades on decentralized exchanges on the Solana blockchain, and on centralized exchanges such as Kucon, MEXC, and Gate exchange. This connection to Solana provides high-speed, low-cost infra for io.net's network operations, payments, and decentralized governance. Solana's high transaction speeds and sub-cent fees are crucial for providing instantaneously, low-latency computing power at significantly lower rates compared to traditional cloud providers, and for managing io.net's automated micro-payments, and to efficiently manage and incentivize GPU crowdsourcing services at scale.As io.net continues to grow its GPU power offerings, its tokenomics will play a pivotal role in shaping the future of decentralized AI, empowering both developers and resource providers in a truly community-driven environment.Decentralized GPU Network Benefits for Developers and Enterprisesio.net offers a number of advantages to both developers and enterprises who want to accelerate their AI and ML initiatives.Instant access to a vast pool of computing resources, which can be used to rapidly deploy and scale AI workloads, all without the delays and other constraints typical of traditional cloud providers.Dynamic scaling of compute for projects with fluctuating computational demands.Reduced costs & no vendor lock-in help developers and enterprises ensure that their resource usage is both efficient and cost-effective.Level playing field for smaller teams and organizations, enabling them to compete with larger players in the AI space.Robust security & transparent payment systems benefit enterprises, giving them a secure and reliable environment for building, deploying, and managing AI applications.Scalable infrastructure supports a wide range of AI models and applications, empowering users to discover and bring to market new possibilities in AI and ML.The Future is Decentralizedio.net’s DePIN architecture spans over 138 countries, utilizing more than 300,000 individual GPUs to aggregate lost or stranded compute power. By early 2025, io.net aggregated over 327,000 verified GPUs , reinforcing its position as a leading decentralized compute network in the world. To date, io.net's has facilitated over 1.3 million computing hours, a clear demonstration that it can scale to meet strong and rising demand.Notable AI innovators have adopted the platform for their GPU power, showcasing its ability to handle diverse and large-scale workloads efficiently. The network aims to halve the circulating supply by tying token emissions directly to real compute demand on the Solana blockchain by Q2 2026.io.net's pricing is at least 50% cheaper than centralized competitors, making it a highly cost-effective decentralized network for AI and ML workloads. This global reach and impact highlight io.net’s role in shaping the future of decentralized infrastructure worldwide. The streamlined, frictionless API grants direct access to the IO network, while the easy onboarding process encourages provider participation.At a time when centralized providers are building deeper moats around AI infrastructure to control computing power, io.net offers enticing value: a true decentralized, global network for a truly decentralized space.Get involved today at io.net, and experience the power and flexibility of a decentralized physical infrastructure network built for AI teams.","tokens":3725,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791267996019,"hash":"23cabe870f72b6dca15b474e58f2ea9686454213"}
{"url":"https://forum.openzeppelin.com/t/deploy-a-crowdsale-contract-for-a-previously-deployed-erc20-token/26733","domain":"forum.openzeppelin.com","title":"Deploy a crowdsale contract for a previously deployed ERC20 token - Smart Contracts - OpenZeppelin Forum","text":"Deploy a crowdsale contract for a previously deployed ERC20 token \n\n Smart Contracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2022\n\n 1 / 3\n\n Mar 2022\n\n May 2022\n\n post by RicciH8 on Mar 25, 2022\n\n RicciH8\n\n Hello,\nI have deployed an upgradable ERC20 token using ^0.8.4 and I would like to set up an AllocatedCrowdsale for said token. I have set up a second project for the crowdsale using ^0.5.0 but I'm struggling to find a way to link to my previously deployed token. This is as far as I've got so far deploying with Truffle:\nconst MyCrowdsale = artifacts.require(\"MyCrowdsale\");\n\nmodule.exports = async function (deployer, network, accounts) {\n\n const token = \"MY TOKEN CONTRACT ADDRESS\";\n await deployer.deploy(MyCrowdsale, 1000, accounts[0], token.address, accounts[0]);\n const crowdsale = await MyCrowdsale.deployed();\n\n token.transfer(crowdsale.address, 10000)\n\n};\n\nAny advice much appreciated.\nCheers,\n\n 2\n\n post by pytune on Mar 25, 2022\n\n pytune\n\n You want to link your deployed token with the crowdsale contract?\n\n 2 months later\n\n post by RicciH8 on May 17, 2022\n\n RicciH8\n\n Hello,\nYes, I already have a token deployed but then would like to set up a Crowdsale to distribute the already deployed tokens. All examples I see seem to involve deploying both the token contract and crowdsale contract at the same time.\nThanks in advance\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Simple ERC20 Crowdsale\n\n Guides and Tutorials\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021","tokens":477,"squid":"ink-security_audits","role":"Sentinel","at":1791267996594,"hash":"3881cc9d41a9b1b1ee71729aad8fe9fd19937cf8"}
{"url":"https://docs.optimism.io/app-developers/tutorials/deploy-a-contract","domain":"docs.optimism.io","title":"Optimism Documentation","text":"This tutorial walks you through deploying your first smart contract to an OP Stack chain from scratch.\nYou’ll deploy a small Greeter contract to the OP Sepolia testnet with Foundry, then read from and write to it from the command line.\nOP Stack chains are EVM equivalent, so the workflow here is the same one you’d use on Ethereum: the only OP-specific detail is the RPC endpoint and chain ID you point at.\nBy the end you’ll have a live contract on OP Sepolia and the commands to interact with any contract you deploy later.\nThis tutorial uses the OP Sepolia testnet, so you won’t spend real funds.\nThe same steps work on any OP Stack chain — swap in that chain’s RPC URL and fund your account on that network.\n​Dependencies\n\nFoundry — installed in the first step below.\nA terminal with curl available (preinstalled on macOS and most Linux distributions).\n\n​Install Foundry\nFoundry is a toolkit for Ethereum development.\nThis tutorial uses two of its command-line tools: forge (to compile and deploy) and cast (to send transactions and read state).\n1Install foundryupcurl -L https://foundry.paradigm.xyz | bash\nThis installs foundryup, Foundry’s version manager.\nFollow the on-screen instructions to add it to your PATH (you may need to open a new terminal).2Install the Foundry toolchainfoundryup\n\n​Verify the install\nConfirm forge and cast are available:\nforge --version\ncast --version\n\nEach command should print a version string.\nIf the command isn’t found, revisit the PATH instructions from foundryup and open a new terminal.\n​Create a project and contract\n1Initialize a Foundry projectmkdir first-contract\ncd first-contract\nforge init\nforge init scaffolds a new project with src/, test/, and script/ directories.2Add the Greeter contractReplace the contents of src/Greeter.sol with the following.\nThis is a variation on Hardhat’s Greeter contract: it stores a greeting string, exposes it through greet(), and lets anyone update it through setGreeting().//SPDX-License-Identifier: MIT\npragma solidity ^0.8.0;\n\ncontract Greeter {\n string greeting;\n\n event SetGreeting(\n address indexed sender, // msg.sender\n string greeting\n );\n\n function greet() public view returns (string memory) {\n return greeting;\n }\n\n function setGreeting(string memory _greeting) public {\n greeting = _greeting;\n emit SetGreeting(msg.sender, _greeting);\n }\n}\n3Compile the contractforge build\n\n​Verify the build\nforge build should report a successful compilation and write artifacts to the out/ directory.\nIf compilation fails, check that src/Greeter.sol matches the code above exactly.\n​Configure OP Sepolia and your account\nYou need two things to deploy: an RPC endpoint for OP Sepolia and a private key to sign the deployment transaction.\n1Create a deployment accountCreate a fresh key for this tutorial rather than reusing a key that holds real funds.cast wallet new\nThis prints an Address and a Private key.\nSave both somewhere safe.2Set your environment variablesExport the OP Sepolia RPC URL and the private key you just created.\nThese variables are read by the forge and cast commands in the rest of the tutorial.export L2_RPC_URL=https://sepolia.optimism.io\nexport PRIVATE_KEY=0x...your-private-key...\nexport ACCOUNT_ADDRESS=$(cast wallet address --private-key $PRIVATE_KEY)\n\nhttps://sepolia.optimism.io is a public, rate-limited endpoint suited to development and testing.\nFor a full list of endpoints and production providers, see the OP Stack RPC directory.\nFor OP Sepolia’s chain ID (11155420) and other network parameters, see Connecting to OP Mainnet.\n​Fund your account\nDeploying a contract costs gas, so your account needs testnet ETH on OP Sepolia.\n1Request testnet ETHUse the Superchain Faucet to send OP Sepolia ETH to your ACCOUNT_ADDRESS.\n​Verify your balance\nCheck that the faucet funds have arrived before deploying:\ncast balance --ether $ACCOUNT_ADDRESS --rpc-url $L2_RPC_URL\n\nThe command prints your balance in ETH.\nWait until it’s greater than 0 before continuing.\n​Deploy the contract\nDeploy Greeter to OP Sepolia and capture the resulting contract address.\nCONTRACT_ADDRESS=$(forge create \\\n --rpc-url $L2_RPC_URL \\\n --private-key $PRIVATE_KEY \\\n Greeter \\\n --broadcast \\\n | awk '/Deployed to:/ {print $3}')\n\necho \"Deployed to: $CONTRACT_ADDRESS\"\n\nThe forge create command compiles (if needed), signs, and broadcasts the deployment transaction.\nIts output includes a Deployed to: line; the awk command extracts that address into the CONTRACT_ADDRESS variable so you can reuse it in the next step.\nRun forge create on its own (without the awk pipe) if you want to see the full output — the deployer address, the new contract address, and the transaction hash.\n​Verify the deployment\nConfirm the contract exists on-chain by fetching its bytecode:\ncast code $CONTRACT_ADDRESS --rpc-url $L2_RPC_URL\n\nA deployed contract returns a long hex string.\nIf it returns 0x, the deployment didn’t land — re-check your balance and rerun the deploy step.\n​Interact with the contract\nNow read from and write to your live contract using cast.\n1Read the initial greetingcast call --rpc-url $L2_RPC_URL $CONTRACT_ADDRESS \"greet()\" | cast --to-ascii\nThe greeting starts empty, so this returns an empty string.2Set a new greetingThis sends a transaction that calls setGreeting():cast send \\\n --private-key $PRIVATE_KEY \\\n --rpc-url $L2_RPC_URL \\\n $CONTRACT_ADDRESS \\\n \"setGreeting(string)\" \"Hello from OP Sepolia\"\n3Read the greeting againcast call --rpc-url $L2_RPC_URL $CONTRACT_ADDRESS \"greet()\" | cast --to-ascii\nThis now returns Hello from OP Sepolia, confirming your write landed on-chain.\n​View your contract on the block explorer\nOpen an OP Sepolia block explorer and search for your CONTRACT_ADDRESS to see the deployment transaction and the setGreeting call you just sent.\nPublishing (verifying) your contract’s source code on the explorer is optional but recommended, because it lets anyone read and interact with the contract from the explorer UI.\n​Next steps\n\nLearn the broader conventions in Building apps on OP Stack chains.\nUnderstand the differences between Ethereum and OP Stack chains.\nTry a cross-chain tutorial next, such as bridging ERC-20 tokens.\n\nRunning your app in productionA production application depends on infrastructure your team does not run: RPC endpoints that hold up under real traffic (the public endpoints are rate-limited and not built for production), bridges your users rely on, and a chain whose operator keeps sequencing, upgrades, and incident response going around the clock. These docs cover building and testing. If your application is growing toward dedicated blockspace of its own, OP Enterprise offers managed and supported paths to running a chain. These docs stay the reference for what you build either way. OP Enterprise is Optimism’s managed offering.Was this page helpful?","tokens":1703,"squid":"ink-governance","role":"Council Listener","at":1791267998911,"hash":"7104e8a87c78891928d2354a0a637225a53d84a5"}
{"url":"https://aave.com/help","domain":"aave.com","title":"Help & Support | Aave","text":"Find the answers you need.Media & PressGet in touch with the Aave Labs team for press, media inquiries, and brand resources.Business SolutionsConnect with our team to explore integrations, partnerships, and business opportunities.FAQsSee answers to frequently asked questions.Developer DocsStart building on Aave with our comprehensive developer docs.Contact UsGet help from the Aave Labs team on specific questions.GuidesAave 1012 ArticlesIntroduction to the Aave ProtocolSupplying4 ArticlesSupply liquidity to earn and collateralise.Borrowing4 ArticlesOpen overcollateralised borrow positions.Governance3 ArticlesCommunity-driven governance.GHO Stablecoin4 ArticlesThe Aave Protocol native stablecoin.Umbrella4 ArticlesSecuring the Aave Protocol.Web36 ArticlesBlockchain basicsStill need help?If there's a guide you need that isn't available, you can request a new guide from us, the Aave Labs team.Contact Us","tokens":228,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268007295,"hash":"5a4a4149fda032f066e6196e093b88fa04f759a2"}
{"url":"https://docs.base.org/upgrades/cobalt/dynamic-upgrades","domain":"docs.base.org","title":"Dynamic Upgrades - Base Documentation","text":"This change runs in metrics-only mode on Mainnet while data is collected to validate that upgrades work smoothly.\n​Motivation\nToday, every hardfork activation requires a new node release with hard-coded timestamps. Operators must upgrade their binaries before each fork, and any missed release risks falling out of consensus. Decoupling upgrade timestamps from client releases reduces the number of releases operators need to run and shortens the coordination window for activating new forks.\n​What Changed\nThe EL and CL each run an upgrade-signal poller that reads the onchain contract over L1 RPC, saves the schedule into the client’s activation overrides, and applies them wherever the schedule is used. Forks activate at the scheduled time with no restart.\n​Migration\nThis change is included in the Cobalt node release, so no action is required for node operators.Was this page helpful?Suggest editsRaise issue","tokens":229,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268013876,"hash":"5f611f1eb998454e4e5a2362d69db24dd2db8522"}
{"url":"https://forum.openzeppelin.com/t/deploy-a-crowdsale-contract-for-a-previously-deployed-erc20-token/26733/3","domain":"forum.openzeppelin.com","title":"Deploy a crowdsale contract for a previously deployed ERC20 token - Smart Contracts - OpenZeppelin Forum","text":"Smart Contracts\n\n erc20\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2022\n\n 3 / 3\n\n May 2022\n\n May 2022\n\n post by RicciH8 on Mar 25, 2022\n\n RicciH8\n\n Hello,\nI have deployed an upgradable ERC20 token using ^0.8.4 and I would like to set up an AllocatedCrowdsale for said token. I have set up a second project for the crowdsale using ^0.5.0 but I'm struggling to find a way to link to my previously deployed token. This is as far as I've got so far deploying with Truffle:\nconst MyCrowdsale = artifacts.require(\"MyCrowdsale\");\n\nmodule.exports = async function (deployer, network, accounts) {\n\n const token = \"MY TOKEN CONTRACT ADDRESS\";\n await deployer.deploy(MyCrowdsale, 1000, accounts[0], token.address, accounts[0]);\n const crowdsale = await MyCrowdsale.deployed();\n\n token.transfer(crowdsale.address, 10000)\n\n};\n\nAny advice much appreciated.\nCheers,\n\n 2\n\n post by pytune on Mar 25, 2022\n\n pytune\n\n You want to link your deployed token with the crowdsale contract?\n\n 2 months later\n\n post by RicciH8 on May 17, 2022\n\n RicciH8\n\n Hello,\nYes, I already have a token deployed but then would like to set up a Crowdsale to distribute the already deployed tokens. All examples I see seem to involve deploying both the token contract and crowdsale contract at the same time.\nThanks in advance\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Crowdsale contract with token already deployed\n\n Support\n\n erc20,crowdsale\n\n 5\n\n 1.6k\n\n Feb 2022\n\n Simple ERC20 Crowdsale\n\n Guides and Tutorials\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025\n\n Prepare a crowdsale contract for an already ready token\n\n Contracts\n\n bep20\n\n 2\n\n 743\n\n Feb 2022\n\n BEP20 Crowdsale\n\n Review Wanted\n\n bep20\n\n 12\n\n 2.7k\n\n Dec 2021\n\n Crowdsale contract\n\n Support\n\n bep20\n\n 4\n\n 1.8k\n\n Jun 2021","tokens":460,"squid":"ink-security_audits","role":"Sentinel","at":1791268016893,"hash":"0df700839426847d3b4c2382a520acb3434b7e71"}
{"url":"https://docs.base.org/upgrades/denim/200ms-blocks","domain":"docs.base.org","title":"200ms Native Blocks - Base Documentation","text":"200ms native blocks are live on Vibenet for experimental developer testing. This deployment may change, and you should not rely on it for production decisions.Denim changes how fast block.number advances. If your contracts measure time in blocks, read Block-Number-Based Contract Logic before activation.\n​Summary\nDenim changes Base block production from one canonical block every two seconds to five complete canonical blocks per second. Each 200ms block has its own block number, hash, state root, receipts, forkchoice updates, and unsafe, safe, and finalized lifecycle.\nDenim replaces Flashblocks, which publish incremental pending-state updates for a single block. As part of the Denim rollout, Base will stop producing Flashblocks and instead produce a canonical block every 200ms. Applications using Flashblocks must migrate to canonical block and RPC streams.\nDenim keeps the Ethereum block header and its seconds-based timestamp unchanged. A BaseTime metadata deposit supplies the sub-second component. Together, these values identify a canonical block’s full millisecond timestamp.\nIf your application uses Flashblocks, see Migrate From Flashblocks for the required API changes.\n​Block-Number-Based Contract Logic\nDenim moves Base from one block every two seconds to five blocks per second. block.number advances ten times faster in wall-clock time, while block.timestamp still advances in whole seconds. Any contract or offchain system that treats a block count as a duration will see that duration shrink to one tenth of its intended length after activation. Block-count constants baked into immutable or non-upgradeable contracts cannot be retuned after activation.\nAudit your contracts for logic that converts block counts to time before Denim activates:\nPatternEffect after DenimTimelocks, cooldowns, and exit delays measured as block.number - start >= NElapse in one tenth of the intended wall-clock time.Vesting, emission, or difficulty schedules measured in blocksComplete or retarget ten times faster in wall-clock time.Per-block rate limits or caps that reset when block.number changesReset five times per second instead of once every two seconds, raising the effective per-second limit ten times.Deadlines set as expirationBlock = block.number + NExpire in one tenth of the intended wall-clock time.Governance voting delay and voting period in blocks, including ERC20Votes with the default block-number clock()Voting windows shrink ten times. Stored checkpoints stay correct.Uniswap V3 style TWAP oraclesTWAP values stay correct because accumulators are second-weighted. A fixed observation cardinality covers roughly half as much wall-clock history, so long observe() lookbacks revert with OLD sooner.\nLogic that measures time with block.timestamp is unaffected.\nTo prepare:\n\nReplace block-count durations with block.timestamp comparisons where you can redeploy or upgrade.\nWhere a block count is governance-tunable, plan to divide it by ten at activation.\nWhere a block count is immutable and cannot be changed, assess the impact and plan a migration before activation.\nTest the changed behavior on Vibenet, which already produces 200ms blocks.\n\n​Execution\n​Full block timestamp\nDenim leaves block.header.timestamp as Unix time in whole seconds. For an activated block b, its full timestamp is:\nTms(b)=1000×b.header.timestamp+b.tx[1].timestamp_millis_partT_{ms}(b) = 1000 \\times b.header.timestamp + b.tx[1].timestamp\\_millis\\_part\nThe BaseTime deposit at tx[1] carries timestamp_millis_part. The only valid values are 0, 200, 400, 600, and 800. Consecutive activated blocks satisfy:\nTms(child)=Tms(parent)+200T_{ms}(child) = T_{ms}(parent) + 200\nBlocks cannot skip slots. The seconds header and millisecond part must come from the same scheduled timestamp; wall-clock time controls when the sequencer starts a build, not the timestamp assigned to that block. EVM block.timestamp remains the whole-second header value.\n​BaseTime metadata deposit\nAfter activation, every block contains the canonical BaseTime update at tx[1], immediately after the L1 information deposit at tx[0] and before user transactions. The deposit is bound to the current block number by source-hash domain 3.\nFieldValueTransaction typeDeposit (0x7e)Source hashDomain 3, bound to the current block numberFrom0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001To0x4200000000000000000000000000000000000030Mint0Value0Gas limit1,000,000System transactionfalseCalldatasetTimestampMillisPart(uint16) with selector 0x86bdf394 and a 32-byte ABI-encoded millisecond part\nBefore activation, blocks must not contain this metadata transaction or the Engine millisecond field. After activation, implementations validate the transaction’s position, source hash, sender, recipient, mint, value, gas limit, system flag, calldata shape, and lattice value.\n​BaseTime predeploy\nThe initial design exposes the current block’s millisecond part to contracts through a predeploy.\nPropertyValueProxy0x4200000000000000000000000000000000000030Implementation0xc0D3C0d3C0d3C0D3c0d3C0d3c0D3C0d3c0d30030Storageuint16 millisecond part in slot 0SettersetTimestampMillisPart(uint16)Millisecond-part gettertimestampMillisPart()Full-timestamp gettertimestampMs()\nThe BaseTime deposit executes before L1 user deposits, and user transactions, so all later transactions can read the updated value.\nFresh chains install the linked BaseTime predeploy in genesis. On existing chains, the reserved address already contains the canonical proxy runtime and uses the Base ProxyAdmin, but its implementation slot is unset. Calls therefore revert until activation.\nAt activation, before transaction execution, the protocol installs the canonical BaseTime implementation and links the existing proxy. It preserves the proxy admin and any implementation already set through governance.\n​Engine payload attributes\nThe Engine API uses BasePayloadAttributes, which flattens the standard PayloadAttributes fields alongside Base-specific fields.\nFor payloads at or after Denim activation, BasePayloadAttributes.timestampMillisPart MUST be present and equal 0, 200, 400, 600, or 800. Before activation, it MUST NOT be present.\nBasePayloadAttributes.transactions[1] MUST contain the BaseTime metadata deposit. The deposit MUST be sent by the protocol depositor to the BaseTime predeploy, and its calldata MUST contain the canonical encoding of setTimestampMillisPart(uint16). The encoded value MUST equal timestampMillisPart.\nAn execution client MUST reject malformed forkchoiceUpdated payload attributes with JSON-RPC Invalid params (-32602). It MUST report an execution payload with a missing or invalid BaseTime deposit as invalid during newPayload validation.\nThe payload ID includes timestampMillisPart, so builds that differ only in the millisecond part receive different IDs. When the field is absent, legacy payload-ID calculation remains unchanged.\nAll existing Engine timestamp fields remain seconds-based.\n​Validation\nWhen processing forkchoiceUpdated, the execution client performs checks that do not require reading contract state. Before Denim, timestampMillisPart must be absent. After Denim, it must be present and equal 0, 200, 400, 600, or 800. The block’s whole-second timestamp must not be earlier than its parent’s. Because block headers do not store milliseconds, the client checks exact 200ms progression after execution.\nAfter execution, the client MUST verify that the block’s full timestamp is exactly 200ms after its parent’s. Blocks that do not satisfy this requirement are invalid.\n​Derivation\n​Scheduled timestamps\nAfter activation, the derivation pipeline computes each block’s timestamp from the Denim activation schedule and absolute L2 block number. It does not read the millisecond part from batch data or derive it from the local wall clock. The sequence is:\np (.000) → child (.200) → child (.400) → child (.600) → child (.800) → child (.000 in the next second)\nThe pipeline splits the scheduled timestamp into the seconds-based header timestamp and the BaseTime millisecond part, then reconstructs the BaseTime deposit at tx[1].\n​Block lifecycle\nThe sequencer builds and executes a complete block for every selected 200ms slot. Each block receives its own hash, state root, receipts, Engine payload, forkchoice update, and unsafe-to-safe-to-finalized lifecycle.\nThe block begins with the L1 information deposit at tx[0] and the BaseTime metadata deposit at tx[1]. User transactions and other applicable transactions follow. The design intends the payload attribute, tx[1], and the value written to the BaseTime predeploy to represent the same planned millisecond part.\n​RPC\nThe RPC behavior below is planned for Denim and is not available on production endpoints.\n​Seconds compatibility\nDenim keeps the existing timestamp JSON-RPC field in Unix seconds. Engine timestamps, transaction-validity timestamps, eth_call timestamps, and EVM block.timestamp also remain seconds-based. RPC responses do not expose the internal timestampMillisPart field.\nAfter the Denim rollout, use canonical block responses and subscriptions such as eth_subscribe(\"newHeads\") for sub-second updates. Flashblocks streams will stop.\n​Block and header timestamps\nThe following responses will add optional timestampMs, encoded as a JSON-RPC quantity containing the full Unix timestamp in milliseconds:\n\neth_getBlockByHash\neth_getBlockByNumber\neth_getHeaderByHash\neth_getHeaderByNumber\neth_subscribe(\"newHeads\")\n\nFor example, a block at 42.200 seconds has:\nFieldValuetimestamp0x2atimestampMs0xa4d8\nClients will derive timestampMs from authenticated BaseTime metadata rather than estimate it from the seconds field. If a historical block body or its BaseTime metadata has been pruned or is otherwise unavailable, the response will omit timestampMs.\n​Transaction timestamps\nMined transaction objects will add optional blockTimestampMs for these methods:\n\neth_getTransactionByHash\neth_getTransactionByBlockHashAndIndex\neth_getTransactionByBlockNumberAndIndex\n\nFull transaction objects nested in block responses will follow the same mined-transaction behavior. Pending transactions will omit blockTimestampMs because they do not yet belong to a canonical block.\n​Log and receipt timestamps\nMined log objects will add optional blockTimestampMs when returned by:\n\neth_getLogs\neth_getFilterChanges\neth_getFilterLogs\neth_getTransactionReceipt\neth_getBlockReceipts\neth_subscribe(\"logs\")\neth_subscribe(\"transactionReceipts\")\n\nReceipts will expose the field on their nested logs, not at the receipt’s top level. A removed log will retain its original block timestamp along with its original block provenance. If the originating block’s authenticated BaseTime metadata is unavailable, the log will omit the field rather than estimate it.\nAs with block responses, pruned or unprovenanced transaction and log data will omit blockTimestampMs. The fields are optional so pre-Denim history and clients without the required body data remain representable.\n​Tooling\nFoundry’s AnyRpcBlock and OtherFields paths can preserve an unknown block-level timestampMs, while EVM execution continues to use seconds. Plain Alloy AnyRpcHeader drops unknown fields; consumers that need Denim timestamps can use WithOtherFields<AnyRpcHeader> or a typed Base response. Locally mined Anvil blocks are not expected to produce BaseTime metadata in the initial rollout.Was this page helpful?Suggest editsRaise issue","tokens":2854,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268023776,"hash":"08c30a3fc3033f59dd5f58ac449d4fb748a2475d"}
{"url":"https://forum.openzeppelin.com/c/smart-contracts/guides-and-tutorials/23","domain":"forum.openzeppelin.com","title":"Latest Smart Contracts/Guides and Tutorials topics - OpenZeppelin Forum","text":"Latest topics in Guides and Tutorials\n\n Smart Contracts\n\n Guides and Tutorials\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n How to verify a contract on Etherscan/BscScan/PolygonScan\n\n etherscan-verify,hide-post-links\n\n Make sure to read this post before asking a question about verification. If your issue is not addressed here, just leave a comment below. \nIf you want to pay someone to do the verification for you, create a post in Sma…\n\n read more\n\n 73\n\n 63.1k\n\n Jun 2025\n\n Deploy a simple ERC20 token in Remix\n\n 22\n\n 53.4k\n\n Jun 20\n\n Ethernaut Community Solutions\n\n ethernaut\n\n 8\n\n 15.3k\n\n Feb 20\n\n Simple ERC20 token fees\n\n erc20,bep20,solidity\n\n 15\n\n 9.3k\n\n Nov 2025\n\n Introduction to the Diamond Standard, EIP-2535 Diamonds  substack.com\n\n proxies,upgrades,design\n\n 12\n\n 8.9k\n\n Oct 2025\n\n Tools and their Usage in Development\n\n tutorial\n\n 4\n\n 2.7k\n\n Aug 2025\n\n Simple ERC20 Crowdsale\n\n erc20,crowdsale,example\n\n 2\n\n 17.1k\n\n Apr 2025\n\n Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract\n\n 5\n\n 7.5k\n\n Mar 2025\n\n ERC20 Wrapper tutorial\n\n erc20,tutorial,wrappedtoken\n\n 10\n\n 7.2k\n\n Dec 2024\n\n Verify ERC20 token on Etherscan that was deployed through Remix: Step by Step Guide\n\n etherscan-verify,hide-post-links\n\n 185\n\n 56.2k\n\n Oct 2024\n\n The links are broken in Blogs\n\n 0\n\n 31\n\n Oct 2024\n\n UUPS Proxies: Tutorial (Solidity + JavaScript)\n\n 80\n\n 43.7k\n\n Aug 2024\n\n How to implement ERC20 supply mechanisms\n\n 7\n\n 51.7k\n\n Jul 2024\n\n What is DeFi? An Introduction to Decentralized Finance\n\n 1\n\n 2.7k\n\n Jun 2024\n\n Dynamic Staking\n\n 4\n\n 1.6k\n\n Feb 2024\n\n Create an NFT and deploy to a public testnet, using Remix\n\n erc721,nft,remix\n\n 21\n\n 40.7k\n\n Jan 2024\n\n Solidity Diamond Inheritance\n\n 2\n\n 5.9k\n\n Jan 2024\n\n Introduction to the Flash Loan Pattern and its security considerations\n\n flash-loan\n\n 4\n\n 9.4k\n\n Dec 2023\n\n OpenZeppelin Upgrades: Step by Step Tutorial for Hardhat\n\n upgrades-plugins,hardhat\n\n 39\n\n 55.0k\n\n Nov 2023\n\n A Collection of Gas Optimisation Tricks\n\n gas\n\n 19\n\n 17.3k\n\n Sep 2023\n\n Use plugin in the Remix to verify contract\n\n erc20,etherscan-verify\n\n 8\n\n 3.7k\n\n Sep 2023\n\n Introduction to the “Overcollateralized Loan” Pattern (DeFi primitive) and its Security Considerations\n\n 3\n\n 4.1k\n\n Sep 2023\n\n How to fix Pancakeswap’s Router address in Safemoon\n\n safemoon\n\n 100\n\n 31.9k\n\n May 2023\n\n Solidity Smart Contract development on Windows\n\n 1\n\n 7.4k\n\n Apr 2023\n\n Deploy Contract Using a Relayer\n\n defender\n\n 3\n\n 1.7k\n\n Jan 2023\n\n Community Solutions to Damn Vulnerable DeFi\n\n damn-vulnerable-defi\n\n 4\n\n 3.5k\n\n Nov 2022\n\n Tutorial on Using a Gnosis Safe MultiSig with a TimeLock to Upgrade Contracts and use Functions in a Proxy Contract\n\n 5\n\n 13.2k\n\n Oct 2022\n\n Autotask Tutorial 1: Get Started with Autotasks in OpenZeppelin Defender\n\n defender,autotasks\n\n 0\n\n 1.7k\n\n Oct 2022\n\n Autotask Tutorial 2: Token Balance Automation Autotask\n\n defender,autotasks\n\n 0\n\n 824\n\n Oct 2022\n\n Smart Contract Bytecode Verification\n\n etherscan-verify\n\n 0\n\n 1.6k\n\n Sep 2022","tokens":766,"squid":"ink-security_audits","role":"Sentinel","at":1791268027677,"hash":"ab1ea45c459e21133bb5c7ba6ff2fe348abe0c0b"}
{"url":"https://docs.base.org/base-chain/specs/reference/b20/changelog/02-cobalt-policyregistry-composite-policy","domain":"docs.base.org","title":"PolicyRegistry: Composite Policies (UNION / INTERSECT) - Base Documentation","text":"​Summary\nCobalt adds composite policies to PolicyRegistry. A composite\ncombines two to four existing simple ALLOWLIST or BLOCKLIST policies under a UNION (OR) or\nINTERSECT (AND) gate. Create a composite with createCompositePolicy and replace its complete\nchild set with updateComposite.\nThe change is additive. Existing Beryl selectors, events, errors, and simple-policy behavior remain\ndialable at Cobalt. createPolicy and createPolicyWithAccounts add one revert path:\nIncompatiblePolicyType when called with a composite policyType.\n​Motivation\nAsset issuers often reuse authorization policies across assets, such as a KYC allowlist or a\nsanctions blocklist. Before Cobalt, combining more than one policy required copying their members\ninto a flattened policy and operating offchain infrastructure to synchronize every source update.\nThat duplication can become stale: a valid account can be rejected, or a removed account can remain\nauthorized, until the copied list is updated.\nAuthorization can also require an explicit OR or AND relationship. For example, a policy can admit\nan account that is on either a shared or token-specific allowlist, or it can require an account to\nbe both KYC-verified and in a Pro User allowlist. Composite policies express those relationships\nwithout copying membership data. Each authorization check uses the current state of every evaluated\nchild policy.\n​What Changed\n​Policy Context\nB20 stores a PolicyRegistry policy ID for each restricted operation. When an operation is\nattempted, B20 calls isAuthorized(policyId, account) and rejects the operation if the account is\nnot authorized.\n\nBLOCKLIST and ALLOWLIST remain simple policies. They are the only valid composite children.\n​Interface Changes\nPolicyType is append-only: UNION = 2 and INTERSECT = 3 follow BLOCKLIST = 0 and\nALLOWLIST = 1. This preserves the existing packed policy-ID encoding.\nIPolicyRegistry.solenum PolicyType {\n BLOCKLIST,\n ALLOWLIST,\n UNION,\n INTERSECT\n}\n\nerror ChildPoliciesOutsideOfRange();\nerror InvalidChildPolicy(uint64 childPolicyId);\n\nevent CompositePolicyUpdated(uint64 indexed policyId, address indexed updater, uint64[] childPolicyIds);\n\nfunction createCompositePolicy(address admin, PolicyType policyType, uint64[] calldata childPolicyIds)\n external\n returns (uint64 newPolicyId);\n\nfunction updateComposite(uint64 policyId, uint64[] calldata childPolicyIds) external;\n\nfunction compositePolicyChildIds(uint64 policyId) external view returns (uint64[] memory);\n\nfunction MIN_COMPOSITE_CHILD_POLICIES() external view returns (uint256);\nfunction MAX_COMPOSITE_CHILD_POLICIES() external view returns (uint256);\n\nSymbolSelector / Topic0StatusBehaviorcreateCompositePolicy(address,uint8,uint64[])0x6fdd1491NewCreates a UNION or INTERSECT composite. PolicyType ABI-encodes as uint8.updateComposite(uint64,uint64[])0xbfe142c0NewReplaces the complete child set.compositePolicyChildIds(uint64)0x7c40df74New viewReturns child IDs in stored order, or an empty array for a non-composite.MIN_COMPOSITE_CHILD_POLICIES()0xb3ae29f7New viewReturns 2.MAX_COMPOSITE_CHILD_POLICIES()0x54309870New viewReturns 4.ChildPoliciesOutsideOfRange()0x697ec868New errorThe child count is outside [2, 4]; this is distinct from the 64-account BatchSizeTooLarge limit.InvalidChildPolicy(uint64)0x46508ef6New errorA child is a composite or a built-in sentinel.CompositePolicyUpdated(uint64,address,uint64[])0x4ff6adaab31b0df87aa7b8b7320c52b8b3b5eede3bf28a6baaaa8b8b7e1d6363New eventEmitted on composite creation and every update with the complete post-update set.isAuthorized(uint64,address)0x55a1179eExtendedDispatches composite policies using live child evaluation.createPolicy(address,uint8)0xca5d55f6ExtendedRejects UNION and INTERSECT with IncompatiblePolicyType.createPolicyWithAccounts(address,uint8,address[])0xa2d3044fExtendedRejects UNION and INTERSECT with IncompatiblePolicyType.\nFor the complete current interface, see the IPolicyRegistry reference.\n​Composite Policy Creation\ncreateCompositePolicy(admin, policyType, childPolicyIds) creates a UNION or INTERSECT policy,\nassigns admin as its initial administrator, and returns a new policy ID. It stores references to\nits children rather than copying their membership.\nThe child set must contain two to four existing simple policies. Child policies cannot be composites\nor the ALWAYS_ALLOW and ALWAYS_BLOCK built-in sentinels. Each evaluated child requires a\nmembership storage read, so gas increases with the number of children evaluated.\nValidation runs in this order:\n\nZeroAddress — admin is address(0).\nIncompatiblePolicyType — policyType is not UNION or INTERSECT.\nChildPoliciesOutsideOfRange — the child count is outside [2, 4].\nPolicyNotFound — one or more children do not exist; the registry completes this pass before\nchecking child types.\nInvalidChildPolicy — a child is a composite or built-in sentinel.\n\nOn success, the registry emits PolicyCreated(policyId, creator, policyType),\nPolicyAdminUpdated(policyId, address(0), admin), and\nCompositePolicyUpdated(policyId, creator, childPolicyIds), in that order.\n​Composite Policy Updates\nupdateComposite(policyId, childPolicyIds) atomically replaces a composite’s complete child set.\nIt does not support a partial update or an empty child set. The event\nCompositePolicyUpdated(policyId, updater, childPolicyIds) is emitted on success; an update does\nnot emit PolicyAdminUpdated because the administrator does not change.\nValidation runs in this order:\n\nPolicyNotFound — policyId does not exist.\nIncompatiblePolicyType — policyId is not a UNION or INTERSECT policy.\nUnauthorized — the caller is not the current administrator. A renounced composite cannot be\nupdated.\nChildPoliciesOutsideOfRange — the new child count is outside [2, 4].\nPolicyNotFound — one or more new children do not exist.\nInvalidChildPolicy — a new child is a composite or built-in sentinel.\n\n​Behavioral Changes\n​Existing Constructor Reverts\ncreatePolicy and createPolicyWithAccounts continue to create only simple policies. Both now\nrevert with IncompatiblePolicyType if their policyType is UNION or INTERSECT.\n​Authorization Evaluation\nisAuthorized evaluates composites as follows:\nAuthorization EvaluationisAuthorized(policyId, account):\n if policy is ALLOWLIST:\n return account is in the policy\n\n if policy is BLOCKLIST:\n return account is not in the policy\n\n if policy is UNION:\n return true when any child authorizes the account\n\n if policy is INTERSECT:\n return false when any child does not authorize the account\n\nComposite children must be simple policies, so evaluation has a maximum depth of one and cannot\nrecurse or form cycles. Authorization is live rather than a membership snapshot: changes to a child\npolicy apply to every referencing composite on its next authorization check.\nEvaluation short-circuits. UNION stops at the first authorizing child and INTERSECT stops at the\nfirst non-authorizing child. Child ordering cannot change the authorization result, but it can change\ngas usage; place the child most likely to short-circuit first.\nThe registry preserves child order and permits duplicate child IDs. It neither sorts nor\ndeduplicates them. A child remains effective after its administrator renounces administration:\nrenunciation freezes future membership updates but does not delete the policy or change its current\nauthorization result.\nA well-formed but never-created UNION ID has no children and returns false; a well-formed but\nnever-created INTERSECT ID has no children and returns true. Consumers that store policy IDs\nmust call policyExists(policyId) before storing them. Otherwise, an invalid INTERSECT ID can\nbehave like ALWAYS_ALLOW.\n​State Changes\nThe change adds a children mapping at offset 4 in the base.policy_registry ERC-7201 namespace.\nIt is additive: existing offsets 0 through 3 are unchanged and no storage migration is required.\nThe offset is relative to the namespace location, not literal EVM storage slot 4.\nFieldValueNamespace location0x00503aeb06982fa1fe3151dc68f90b3946c55c449dfd447e49dcaece71ba4a00OffsetCHILDREN_OFFSET = 4Field typemapping(uint64 policyId => uint64[] childPolicyIds) children\nEach mapping entry stores the dynamic-array length. Its elements begin at the hash of that entry and\npack four uint64 child IDs into one 256-bit storage slot, which covers the two-to-four-child limit.\nBitsArray IndexField0–630childPolicyIds[0]64–1271childPolicyIds[1]128–1912childPolicyIds[2]192–2553childPolicyIds[3]\nSimple and composite policies share the global nextCounter, which starts at 2 because 0 and\n1 are reserved for ALWAYS_ALLOW and ALWAYS_BLOCK. A composite policy ID stores its\nPolicyType in the top byte and the next counter value in the low 56 bits; composites do not use a\nseparate counter.\n​Examples\nAssume employeesPolicyId and approvedRegionPolicyId are existing ALLOWLIST policies. Both\nexamples authorize an account that appears in either list for transfers.\n​Before: Flattened Policy\nB20 stores one policy ID per scope, so both source lists must be copied into a flattened allowlist.\nOffchain infrastructure then watches both sources and propagates membership changes to the copy.\nFlattened Policyuint64 flattenedPolicyId = policyRegistry.createPolicyWithAccounts(\n admin,\n PolicyType.ALLOWLIST,\n /* union of employees and approved-region addresses */\n);\n\nb20.updatePolicy(TRANSFER_SENDER_POLICY, flattenedPolicyId);\n\n​After: Composite Policy\nCreate a UNION composite that references the source policies and assign its ID to B20. B20 needs\nno composite-specific logic: it continues to pass the stored policy ID to PolicyRegistry.\nComposite Policyuint64 compositePolicyId = policyRegistry.createCompositePolicy(\n admin,\n PolicyType.UNION,\n [employeesPolicyId, approvedRegionPolicyId]\n);\n\nb20.updatePolicy(TRANSFER_SENDER_POLICY, compositePolicyId);\n\nThe creation call emits PolicyCreated(policyId, admin, UNION), then\nPolicyAdminUpdated(policyId, address(0), admin), then\nCompositePolicyUpdated(policyId, admin, childPolicyIds). Adding Alice to employeesPolicyId\nauthorizes her on the next check without copying members into another policy.\n\n​Design Decisions and Alternatives Considered\nCobalt uses two explicit policy types, a single createCompositePolicy function, and full\nreplacement through updateComposite.\n​One Generic Composite Type\nA generic composite type with a separately stored operator such as AND, OR, NOT, or XOR would add\nstorage and authorization complexity without a requirement for additional operators. Explicit\nUNION and INTERSECT types keep the policy ID encoding, gas profile, and audit surface smaller.\n​Token-Level Policy Groups\nStoring multiple policy IDs and an operator on each B20 token would prevent reusable composites and\nspread the change across token variants, factories, and authorization hot paths. A reusable\nPolicyRegistry policy keeps B20’s policy slot as an opaque uint64 ID.\n​Incremental Child Updates\nSeparate add/remove operations would need array-mutation, length, and deduplication behavior. A\ncomposite has at most four children, so atomic full replacement is simpler and inexpensive.\n​Separate Creator Functions\nSeparate createUnionPolicy and createIntersectPolicy functions would duplicate the creation API.\nA single createCompositePolicy supports both operators consistently.\n​Nested Composites\nAllowing composites to reference composites requires depth limits, cycle protections, and potentially\nunbounded authorization traversal. Restricting children to simple policies guarantees depth-1\nevaluation and bounds worst-case gas.\n​Migration\nThis change is non-breaking. Existing simple ALLOWLIST and BLOCKLIST policies continue to work,\nand integrations that do not need composite behavior require no action.\nTo replace a flattened policy:\n\nIdentify the existing simple policies to combine.\nCreate a UNION or INTERSECT composite with createCompositePolicy.\nWrite the composite ID to the relevant B20 policy scope with b20.updatePolicy.\nRemove the old flattened policy if it is no longer needed.\n\nB20 treats the composite ID as the same opaque uint64 policy ID it uses for simple policies, so no\nB20 contract change is required.Was this page helpful?Suggest editsRaise issue","tokens":3043,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268034178,"hash":"75f3b54fd55796614220e1937a0c7fed49844ef5"}
{"url":"https://aave.com/help/governance/proposals","domain":"aave.com","title":"Proposals | Aave","text":"Back to GovernanceProposalsbeginnerIntroduction\nAave Governance allows the community to make decisions on the protocol's future through a structured proposal lifecycle. Proposals can introduce new features, modify parameters, or make other changes to the Aave Protocol. Below is an outline of the proposal lifecycle, from initial idea to execution.\nGovernance Forum\nThe first step in the proposal process is to introduce your idea to the community. The Aave Governance Forum and Discord are the primary platforms for discussing proposals. Here, community members can provide feedback, technical support, and gauge the initial sentiment towards their idea. Engaging with the community early on helps refine the proposal and gather the necessary support before moving to the next stages.\nSnapshot Voting\nTEMP CHECK\nOnce your proposal has been discussed in the forum, the next step is to gauge community sentiment through a TEMP CHECK vote on the Aave Snapshot Space. TEMP CHECKs serve as informal polls to measure the community’s interest in the proposal. These votes are non-binding and do not require high technical detail or the involvement of DAO service providers. They are a valuable tool for determining whether there is enough interest to proceed with the proposal.\nARFC (Aave Request for Final Comments)\nIf the TEMP CHECK indicates sufficient interest, the proposal can move to the ARFC stage. The ARFC is a more detailed version of the proposal, where relevant service providers are formally invited to provide feedback. This stage includes a thorough specification section that outlines how the proposal will impact Aave Protocol smart contracts. The ARFC serves as a precursor to the formal Aave Improvement Proposal (AIP) and allows for final refinements before moving on-chain.\nCreating the On-Chain Payload\nAIP (Aave Improvement Proposal)\nAfter passing the Snapshot phase, a proposal that requires on-chain execution moves to the AIP phase. The AIP is the formal proposal payload submitted on-chain and consists of two parts: the proposal metadata (stored as an IPFS hash) and the contract payload. These components are submitted to the Aave Governance contracts on the Ethereum Mainnet, where they will be voted on by the community. Detailed information on creating an AIP can be found in the Aave Developer Documentation.\nVoting and Execution Timeline\nVoting\nWhen the AIP is submitted, the voting process begins. The proposal will initially be in a PENDING status, and will move to ACTIVE once the voting delay period has elapsed. Voting tokens and delegations are held on Ethereum Mainnet, and the voting occurs through governance contracts on the specified network.\nThe snapshot for voting balances is taken at the block before the proposal becomes ACTIVE. For a proposal to SUCCEED, it must meet two criteria:\n\nThe voting power in favor of the proposal must reach the quorum set by the minimum quorum parameter for the proposal executor.\nThe difference between for-votes and against-votes must exceed the vote differential threshold set by the vote differential parameter for the proposal executor.\n\nIf these conditions are not met, the proposal will be marked as FAILED.\nExecution\nA SUCCEEDED proposal can be executed on Ethereum Mainnet. The execution process involves relaying the vote information through Aave's governance cross-chain infrastructure. If the proposal includes a cross-chain payload, it will be queued on the timelock executor contract on the relevant network.\nThe timelock delay for execution depends on the proposal's executor. A short executor proposal, typically involving protocol updates, has a 1-day timelock delay. A long executor proposal, which involves changes to core governance permissions, has a 7-day timelock delay. Cross-chain proposals use Aave Delivery Infrastructure (a.DI) to verify messages from designated bridges and execute the payloads.\nProposal Frameworks\nThe Aave DAO has established frameworks for common proposal types, which streamline the proposal process. These frameworks are adopted and amended through community Snapshot votes.\nCaps Update Framework\nProposals that only involve changing a cap or freezing a reserve can qualify for the direct-to-AIP process under the caps update framework. To qualify:\n\nThe proposal must be provided by a risk service provider or have feedback from at least one risk service provider team.\nThe change must involve a new cap implementation, a decrease in the cap, or a change not exceeding a 100% increase in the current cap.\n\nAsset Onboarding Framework\nFor proposals that involve onboarding new tokens, the asset onboarding framework provides a standardized template and lifecycle. This framework promotes that new tokens are added to the Aave Protocol in a consistent and secure manner.\nAsset Onboarding Framework\nNew Chain Deployment Framework\nThe New Chain Deployment Framework is a standardized process for deploying the Aave Protocol on new blockchains. This framework aims to create a transparent approach for evaluating and deploying new Aave v3 instances.\nNew Chain Deployment Framework Link\nEmission Manager Framework\nTo allow quick addition of new emissions admins to Aave pool reserves, the process of adding new emissions admins follows a direct-to-AIP framework. This framework also allows pre-authorized inclusion of an emission admin as part of either an ad-hoc steward or current risk steward role to facilitate a more efficient and streamlined onboarding process.\nEmission Manager Framework LinkRelatedAave CommunitybeginnerLearn about Aave community governance.12 min readVotingbeginnerVoting in Aave Governance.5 min read","tokens":1412,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268036846,"hash":"caa1269f59d3511ade4b92e57d8772cb5b4469ef"}
{"url":"https://forum.openzeppelin.com/t/guide-to-using-create2-sol-library-in-openzeppelin-contracts-2-5-to-deploy-a-vault-contract/2268/6","domain":"forum.openzeppelin.com","title":"Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract - Smart Contracts / Guides and Tutorials - OpenZeppelin Forum","text":"Smart ContractsGuides and Tutorials\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Feb 2020\n\n 6 / 6\n\n Mar 2025\n\n Mar 2025\n\n post by abcoathup on Feb 19, 2020\n\n abcoathup\n\n Great contributor\n\n Create2.sol\nCreate2.sol is a simple library for using the CREATE2 opcode, allowing for deployment and pre-computation of addresses when using it.\nTo learn more about all the cool things you can do with it, head to Getting the Most out of CREATE2\nIn this guide we will precompute the address where a contract will be deployed and send Ether to it. Then, we’ll deploy a contract to that same address, and use it to retrieve the funds previously sent there. (This is based on the guide Deploying Smart Contracts Using CREATE2 and the OpenZeppelin CLI )\nThanks to @k06a for requesting an example.\nCREATE2\nThe whole idea behind this opcode is to make the resulting address independent of future events. Regardless of what may happen on the blockchain, it will always be possible to deploy the contract at the precomputed address.\nNew addresses are a function of:\n\n0xFF, a constant that prevents collisions with CREATE\n\nThe sender’s own address\nA salt (an arbitrary value provided by the sender)\nThe to-be-deployed contract’s bytecode\n\nnew_address = hash(0xFF, sender, salt, bytecode)\n\nCREATE2 guarantees that if sender ever deploys bytecode using CREATE2 and the provided salt, it will be stored in new_address.\nBecause bytecode is included in this computation other agents can rely on the fact that, if a contract is ever deployed to new_address, it will be one they know about. This is the key concept behind counterfactual deployments.\nDeploy VaultFactory\nWe will use Remix to deploy and interacts with our contracts. (OpenZeppelin CLI 2.8 is planned to support deployment of regular contracts)\nWe will compute the address where Vault will be deployed, and send Ether there. Then, we will deploy Vault using VaultFactory which uses Create2.sol and finally call the withdraw method, retrieving the funds that were sent to it before deployment.\nFirst create the Vault.sol and VaultFactory.sol contracts in Remix.\nNext deploy VaultFactory.sol to a test network. (Either a VM or a public testnet, for this guide I will use public testnet Rinkeby)\nMy VaultFactory contract on Rinkeby:\nhttps://rinkeby.etherscan.io/address/0xfea3f16aecd00a080403149fc5dd804494255657#code\nVault.sol\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-sdk/blob/v2.7.1/packages/lib/contracts/Initializable.sol\";\n\ncontract Vault is Initializable {\n address payable public owner;\n\n function initialize(address payable _owner) initializer public {\n owner = _owner;\n }\n\n function withdraw() public {\n require(owner == msg.sender);\n owner.transfer(address(this).balance);\n }\n}\n\nVaultFactory.sol\npragma solidity ^0.5.0;\n\nimport \"./Vault.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/utils/Create2.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/utils/Address.sol\";\n\ncontract VaultFactory {\n event VaultCreated(address vault);\n\n function deployVault(bytes32 salt, address payable owner) public {\n address vaultAddress;\n\n vaultAddress = Create2.deploy(salt, type(Vault).creationCode);\n Vault(vaultAddress).initialize(owner);\n\n emit VaultCreated(vaultAddress);\n }\n\n function computeAddress(bytes32 salt) public view returns (address) {\n return Create2.computeAddress(salt, type(Vault).creationCode);\n }\n\n function sendValue(bytes32 salt) external payable {\n address vaultAddress;\n\n vaultAddress = Create2.computeAddress(salt, type(Vault).creationCode);\n\n Address.sendValue(Address.toPayable(vaultAddress), msg.value); \n }\n}\n\nComputing the Deployment Address\nWith VaultFactory deployed, we can get the factory to compute the address where our Vault contracts will be deployed using an arbitrary salt by calling computeAddress with a salt such as 0x0000000000000000000000000000000000000000000000000000000000000001\nWhich for my deployed VaultFactory gives an address of 0x262245f12519e61278A2d013721A6310661B6Cad\nInteracting With the Counterfactual Contract\nUnder normal circumstances, sending funds to a random Ethereum address is a bad idea. Here however, we know we’ll be able to deploy Vault at the computed address and retrieve our funds. So let’s do it!\nSend some (test) Ether to the address that we got from computeAddress.\nI am going to use sendValue function on VaultFactory (mainly because I couldn’t see an easy way to send value to an address using Remix when using a VM).\nIn the transaction we can see that the address had 0.1 Ether sent to it.\nhttps://rinkeby.etherscan.io/tx/0x01f28c4ca280b239ad2e923752142c2d71abaa2555f6468e8b5a8b21f420a3d6#statechange\nBecause the address has no bytecode and we don’t have its private keys, we cannot do much with it other than checking the funds are indeed there.\nNext up is to get the funds out of the vault.\nWithdrawing From Our Vault\n\nFirst we need to deploy our Vault.\nUse Remix to call deployVault on VaultFactory using the same salt as before and the owner of the Vault who can withdraw funds.\nThe transaction deploying our Vault:\nhttps://rinkeby.etherscan.io/tx/0x14c7be217ab27a0adb4ef0263d6271da7c351a8f2275e4a133a35fd912a5ec95\nIf all went well, we should now be able to withdraw from our Vault.\nUsing Remix, show our Vault contract using atAddress so that we can interact with it.\nThen call withdraw which will send the funds to the owner of the Vault\nThe withdraw transaction showing the change in Ether:\nhttps://rinkeby.etherscan.io/tx/0x5919cef5a5a5e4a8932d20ac06d6ae2148ede459650492f91a1f8ff8965a0d46#statechange\nSuccess! Just to be sure, let’s verify the Vault is indeed empty:\nhttps://rinkeby.etherscan.io/address/0x262245f12519e61278A2d013721A6310661B6Cad\nWe’ve sent funds to an address we precomputed, knowing we’d be later able to deploy a contract there and retrieve them.\n\n Relay - multiple (derived) keys/addresses\n\n Discussion on OpenZeppelin Contracts 2.5 Create2.sol\n\n 3\n\n post by abcoathup on Feb 16, 2020\n\n abcoathup\n\n Great contributor\n\n If you have feedback on the Create2.sol library, you can add to it here:\n\n post by MicahZoltu on Feb 19, 2020\n\n MicahZoltu\n\n Consider updating the guide to mention using a pre-deployed at a deterministic address library like https://github.com/Zoltu/deterministic-deployment-proxy (or one of your own design).\nThe nice thing about using something like that is that you can deploy a contract to the same address on every network including all test networks, all private networks, etc. You can even deploy your vault factory with deterministic deployment proxy so that your vaults are all at deterministic addresses.\n\n post by abcoathup on Feb 19, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @MicahZoltu,\nThat sounds great.\nI have changed the post to a wiki so that anyone can edit and improve.\nNow I just need to get my head around how to use or create a deterministic address library.\n\n 4 years later\n\n post by makoto on Oct 5, 2023\n\n makoto\n\n Hi. Is there any updated guide on this? The solidity version is very old (0.5) , initializable contract isn't in the same location on the latest repo, and Create2.computeAddress now seems internal so I can't call the function.\n\n 1 year later\n\n post by Ant_Crypto on Mar 17, 2025\n\n Ant_Crypto\n\n Please Help!\nHow can i deploy modified erc1155 (larger than 24kb) to different networks with same contract number if Create2 has 24kb limit?\nThanks\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Discussion on OpenZeppelin Contracts 2.5 Create2.sol\n\n General\n\n 4\n\n 1.9k\n\n Mar 2020\n\n Create2: Failed on deploy when using Create2 library\n\n Contracts\n\n 2\n\n 2.8k\n\n Jul 2020\n\n How to generate the addresses before the contract is implemented?\n\n Contracts\n\n bep20\n\n 3\n\n 1.3k\n\n Oct 2021\n\n Getting the most out of CREATE2\n\n Guides and Tutorials\n\n 0\n\n 2.0k\n\n Jun 2019\n\n How to use a CREATE2 deployer\n\n General\n\n 7\n\n 2.1k\n\n Jun 2021","tokens":2006,"squid":"ink-security_audits","role":"Sentinel","at":1791268040427,"hash":"72b2273b7218a308908f0af8ee39d146d44ca6db"}
{"url":"https://governance.aave.com/t/direct-to-aip-onboard-usde-to-aave-v4-core-instance-on-avalanche/25576/2","domain":"governance.aave.com","title":"[Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche - Governance / New Asset - Aave","text":"GovernanceNew Asset\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 1\n\n 2 / 2\n\n Sep 19\n\n Sep 18\n\n post by AaveLabs on Sep 1\n\n AaveLabs\n\n Aave Labs-Technical SP\n\n Title: [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\nAuthor: @AaveLabs\nDate: 2026-09-01\n\nSummary\nThis proposal seeks to onboard USDe to the Aave V4 Core Instance on Avalanche. This proposal follows the Direct to AIP route.\nMotivation\nUSDe is Ethena Labs’ synthetic dollar, targeting a value of one US dollar through a strategy that pairs staked collateral with offsetting perpetual futures positions, held largely offchain. Ethena Labs has extended USDe and its staked form to Avalanche, with support from spot and lending venues across the network.\nOnboarding USDe would:\n\nAdd a synthetic dollar stablecoin to the Aave V4 Core Instance on Avalanche.\nSupport demand emerging from Ethena’s expansion of USDe to Avalanche.\nExtend USDe’s collateral footprint within the broader Aave protocol, where it is already listed across other Aave instances.\n\nSpecification\nThis proposal onboards USDe to the Aave V4 Core Instance on Avalanche.\nRisk parameters and final configuration will be provided by the Risk Service Providers and this proposal will be updated accordingly.\nUseful Links\n\nEthena Documentation\n\nDisclaimer\nThis proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no direct financial relationship with Ethena Labs or its affiliates and has not received compensation from Ethena Labs or its affiliates in connection with this proposal.\nNext Steps\n\nGather community and Service Provider feedback.\nIncorporate the Risk Service Providers’ final configuration for the Aave V4 Core Instance on Avalanche.\nPublish the AIP vote for final confirmation and onchain enforcement of the proposal.\n\nCopyright\nCopyright and related rights waived via CC0.\n\n 17 days later\n\n post by LlamaRisk on Sep 18\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding USDe to the Aave V4 Core Hub on Avalanche. USDe is already listed on multiple Aave markets, including V3 and V4. Native USDe minting is not available on Avalanche, and USDe is instead bridged using LayerZero’s Omnichain Fungible Token (OFT) standard, with backing escrowed on Ethereum. The USDe OFT mesh currently spans 31 networks.\nOn the access control side, the USDe OFT on Avalanche is controlled by a custom timelock controller with a 24-hour delay, which maintains a whitelist allowing certain functions to bypass the delay. Currently, setPeer is whitelisted for the Ethena 5/10 multisig, allowing it to add or remove peers from the OFT mesh without a delay. While this can serve as a plausible incident response mechanism, it could also be exploited by an attacker-controlled address on a chain where the OFT has been compromised. A separate pauser mechanism for incident response currently doesn’t exist. Timelock coverage is absent on some prominent networks in the mesh, with Ethena working to extend coverage over the next few weeks.\nUSDe DEX liquidity on Avalanche is concentrated in a single Uniswap V3 USDe/USDC pool with approximately $0.5M in TVL, which is relatively low for initial liquidity. Thus, we’re proposing conservative initial caps. Given recent changes to the USDe IRM, particularly the base rate increase, borrowing USDe at current rates is unattractive. We therefore recommend onboarding USDe as a collateral-only reserve on Avalanche, with borrowing disabled.\nThe full assessment can be found in its corresponding thread.\nAave V4 Specific Parameters\nWe recommend creating a new Ethena Ecosystem Spoke on V4 Avalanche to onboard USDe as a collateral-only reserve.\nDynamic Liquidation Bonus Configuration\n\nChain\nHub\nSpoke\nLiquidation Bonus Factor\nTarget Health Factor\nHealth Factor For Max Bonus\n\nAvalanche\nCore\nEthena Ecosystem\n100.00%\n1.0277\n0.99\n\nSpoke Parameters\n\nChain\nHub\nSpoke\nReserve\nCollateral Factor\nMax Liquidation Bonus\nBorrowable\nCollateral Risk\nLiquidation Fee\nRisk Premium Threshold\nReceive Shares\n\nAvalanche\nCore\nEthena Ecosystem\nUSDe\n93.00%\n2.00%\nFALSE\n0\n10.00%\n0\nTRUE\n\nAvalanche\nCore\nEthena Ecosystem\nUSDT\n0.00%\n-\nTRUE\n-\n-\n-\nTRUE\n\nAvalanche\nCore\nEthena Ecosystem\nUSDC\n0.00%\n-\nTRUE\n-\n-\n-\nTRUE\n\nAdd and Draw Caps\n\nChain\nHub\nSpoke\nReserve\nAdd Cap\nDraw Cap\n\nAvalanche\nCore\nEthena Ecosystem\nUSDe\n5,000,000\n0\n\nAvalanche\nCore\nEthena Ecosystem\nUSDT\n0\n2,500,000\n\nAvalanche\nCore\nEthena Ecosystem\nUSDC\n0\n2,500,000\n\nPrice feed Recommendation\nWe recommend to price USDe using the Capped USDT/USD feed, consistent with the approach adopted across all Aave instances for USDe-denominated assets.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk serves as an independent attestor of Ethena’s PoR solution. LlamaRisk did not receive compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Ethena USDe on Aave Avalanche Assessments\n\n Assessments\n\n 1\n\n 101\n\n Sep 18\n\n [Direct-to-AIP] Asset Listing - USDe X Layer\n\n New Asset\n\n 2\n\n 120\n\n 13d\n\n [Direct-to-AIP] Onboard USDe to the Aave V3 MegaETH Instance\n\n New Asset\n\n 5\n\n 752\n\n Apr 20\n\n [Direct to AIP] Onboard PT-USDe-22OCT2026 to Aave V3 Monad\n\n Governance\n\n 2\n\n 242\n\n Sep 4\n\n [Direct to AIP] Onboard sUSDe and USDe to Aave V3 Base Instance\n\n General\n\n 1\n\n 304\n\n Feb 24","tokens":1410,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268047638,"hash":"21216fec2decee3ff3dfd653d59e908add60684b"}
{"url":"https://blog.ethereum.org/2026/05/02/soldogn-interop-recap","domain":"blog.ethereum.org","title":"Soldøgn Interop Recap ☀️ | Ethereum Foundation Blog","text":"This post is available in 25 languages: EnglishSoldøgn Interop Recap ☀️Posted by Tim Beiko on May 2, 2026Research & DevelopmentThis past week, just over 100 Ethereum core contributors gathered above the Arctic Circle — in Longyearbyen, Svalbard — for the Soldøgn Interop: a week of intense work on the Glamsterdam network upgrade.\nSoldøgn followed last year's Berlinterop, but returned to the format used by Amphora 🏺, Edelweiss 🏔️, and Nyota ✨: a single-track week of focused, multi-client progress toward a specific upgrade — in this case, hardening Glamsterdam.\nBy Friday, the group had delivered on its three core goals: alignment on a post-Glamsterdam gas limit floor of 200M, stable ePBS implementations running with external builders, and final EIP-8037 repricing numbers locked in. Meaningful progress was also made on Hegotá features like FOCIL and native account abstraction, as well as a slew of other topics.\n\nWhy Svalbard?\nSvalbard is one of the few places on Earth where anyone, regardless of nationality, can live and work without a visa. It's also home to the Global Seed Vault and the Arctic World Archive, two cold-storage facilities tunneled into the permafrost outside Longyearbyen. Between them they hold backups of crops, books, films, manuscripts, and source code that humanity might need a thousand years from now, including a snapshot of Ethereum's source code. Last but not least, from late April through August, the sun doesn't set in Svalbard. It has 24/7 uptime, just like Ethereum, which core devs made the most of during the week!\nHarden Glamsterdam, Scale Ethereum\nThe week's goal was to harden Glamsterdam implementations and derive a target for a post-upgrade gas limit floor. Raising the gas limit safely is a multi-dimensional problem and Glamsterdam tackles several of them: how blocks are built and proposed, how much headroom client implementations have under load, and how state-creation costs scale alongside throughput.\nIn practice that meant ending the week with a stable multi-client Glamsterdam devnet running the latest ePBS, repricing and block access list specs, along with benchmarking data to anchor a credible gas limit proposal.\nMost of the time was spent heads down writing code, often until the early hours of the morning, punctuated by breakout sessions to align on design decisions and discuss longer-term roadmap items.\nThree EF teams provided infrastructure for the week: EthPandaOps shipped ethIQ and a panda MCP server to support teams' agentic workflows; Protocol Support set up soldogn.xyz as the single source of truth for interop goals, schedule, and notes; and the EF Digital Studio team captured the week on film. Expect the very first interop documentary 🔜!\n\nePBS\nBeyond cleaning up the proposer/builder relationship, ePBS restructures slots by adding deadlines for block construction, payload reveal, and attestations. This makes explicit how much time can be allocated for execution, increasing the head room we have to raise the gas limit.\nTeams kicked off the week aiming for a 4 EL × 4 CL Glamsterdam devnet by Monday evening. The first attempts surfaced enough issues to push the target to Tuesday, when a 4×3 configuration ran stably enough for stress testing to begin.\nFrom there, the rest of the week was an ePBS hardening cycle: stress test, expose edge cases, fix, repeat. A Tuesday-morning Builder API breakout substantially simplified the spec around validator registration, the bid/header/commitments flow, the trust model for builder payments, and circuit-breaker behavior. Mid-week debugging zeroed in on cross-client edge cases — notably around execution-request invalidation of beacon requests, where a new test suite revealed a gap across every client implementation. By Thursday morning, CL teams were reporting stable ePBS while EL-side bid pathways were still being debugged; those resolved through Thursday into Friday. Two questions remain genuinely contentious for ACD: whether a request signature should commit to the receiving builder, and how to keep a 1 ETH-staked-builder design resilient against P2P Sybil-based liveness attacks.\nBy Friday, nearly all clients were running together on glamsterdam-devnet-2 with the external builders pipeline tested end-to-end!\n\nBAL Optimizations\nIf ePBS is the consensus-layer side of the Glamsterdam scaling story, the execution layer counterpart has two dominant pieces: gas repricings and Block-Level Access Lists. By giving clients enough information about a block's read/write set up front, BALs enable parallel execution, batched I/O, and parallel state-root computation, all of which determine how big a block clients can comfortably handle.\nThe Soldøgn BAL track ran on its own devnets, separate from the Glamsterdam ePBS chains, so optimization benchmarks weren't entangled with consensus-layer stabilization work. Each optimization sat behind its own feature flag so the week's measurement work could compare them in isolation rather than as a single bundle. The BAL benchmark dashboard and leaderboard surfaced each client's worst-case scenarios across the test suite — by focusing on raising the slowest paths first, teams could lift the gas limit floor across the board, not just for the fastest implementation.\n\nGas Repricings\nGlamsterdam includes a number of EL gas repricings, calibrating costs to better match resource usage at higher throughput. EIP-8037, the state-creation gas cost increase, sits at the core: it raises the price of writing new state so that a higher gas limit doesn't translate into unbounded state growth.\nHeading into Soldøgn, the 8037 spec carried dynamic per-state-byte pricing tied to the block gas limit, which made testing combinatorially painful (one fuzz matrix per gas limit band) and benchmarking nearly intractable. Teams agreed early in the week to drop dynamic pricing in favor of a fixed cost_per_state_byte, with future repricing handled at fork boundaries rather than within a fork.\nThe accounting model itself took a more iterative path. The Monday breakout moved state-gas accounting from mid-execution to end-of-call-frame; a Tuesday follow-up closed out account creation costs, code deposit costs, and CREATE-transaction reverts; Wednesday surfaced reservoir refund/refill edge cases that forced a rethink. The Thursday breakout reverted accounting to opcode level, having concluded that the real complexity sat in the reservoir model, not in the accounting computation. By Friday the spec had stabilized on bal-devnet-6, with the BAL track delivering the final repricing numbers.\nThis whole arc highlights one of the most important aspects of interop: the ability to resolve complex spec, implementation, testing, debugging, and design issues in hours instead of weeks. At their best, interop weeks can compress a month of asynchronous progress into each day!\nBy Friday, the three threads converged on the headline number for the week: a credible 200M post-Glamsterdam gas limit floor. This significant increase is possible because ePBS structures the slot to give execution more time, BAL optimizations give clients the throughput headroom under that structure, and 8037 ensures the higher gas limit doesn't translate into runaway state growth.\n\nOther Glamsterdam Threads\nBeyond ePBS, BALs and repricings, most of the remaining Glamsterdam scope was hashed out across breakout sessions.\nCL teams finalized decisions on smaller Glamsterdam EIPs: EIP-8061 (exit/consolidation churn increase) was included in glamsterdam-devnet-1; EIP-8080 (exits via the consolidation queue) was declined for inclusion; EIP-8045 (slashed-validator duty removal) was scoped down to proposer duties within the look-ahead window only; and EIP-7688 (SSZ stable containers) remains in Glamsterdam scope but is held out of glamsterdam-devnet-1 while the team works through bounded gossip-message size for attestations under progressive lists.\nA Wednesday-morning EL/CL sync architecture breakout deferred EIP-8237 out of Glamsterdam in favor of preserving optionality for a longer-term \"top-up sync\" architecture in a future fork. In its place, the room agreed to draft an EIP that normalizes forkchoiceUpdated / newPayload / getPayload sequencing, specifies a snap-sync initiation handshake, and tightens valid/invalid consistency between the engine API surfaces.\nHardening was a constant theme of the week. A Thursday session covered fork-choice compliance testing frameworks, the Diamond repo of reproducible CL edge-case scenarios, and buildoor, PandaOps's external-builder testing tool, demoed mid-session to a long stream of attack scenarios attendees suggested on the spot.\n\nBeyond Glamsterdam\nSeveral breakouts looked toward Hegotá and the forks that follow.\nA deliberately proposal-agnostic session on native Account Abstraction kicked things off, working through the requirements and constraints any future design must satisfy. Feature-set goals like alternative signature schemes, aggregation, batching, recovery, gas sponsorship, flexible nonces, and keystore wallets sat alongside hard constraints around public-mempool compatibility, statelessness, and L2 DoS resistance.\nA Thursday FOCIL breakout focused on implementation updates: early prototypes were already functional, with multi-client interop and a dedicated FOCIL devnet as the immediate next steps. Two notable design decisions were also made: disabling FOCIL during 2-epoch non-finality (mirroring proposer-boost circuit-breaker behavior), and adopting an index-based bookmark approach for compatibility with frame transactions / EIP-7702.\nFurther out, a long-running ETH P2P track sketched a QUIC-based replacement for libp2p with privacy-by-default and slot-aware integration, alongside an erasure-coded broadcast prototype that simulated ~6× faster propagation than GossipSub on 2.4 MB payloads. The CL track also surfaced strong sentiment toward eventually deprecating consolidations entirely — declaring a final fork that supports them, then forcing exit-then-redeposit afterwards — as the cleaner long-term answer to validator-set state growth.\n\nACD Process\nOn Wednesday afternoon, Nixo and Ansgar, the two ACDE co-leads, ran a session to collect input from core contributors about the ACD process. The session revisited the headliner construct, debated the pros and cons of having a strawmap, and formalized EIP SFI criteria. The room broadly wanted to keep headliners but loosen the EIP-vs-theme rigidity, accepting \"theme + candidate EIP\" as a viable pattern. The straw map's per-fork year assignments past 2026 were flagged as overcanonicalized and likely to be softened. A new four-point SFI definition was put forward, with ACDT signaling readiness and ACDE/ACDC retaining the final call. A new prioritization-ordering process — produced after CFI decisions and reflected in the meta-EIP — will replace SFI's old role of driving devnet inclusion, starting with Hegotá.\nOn the call-coordination side, Alex Stokes announced he will be taking a three-month sabbatical starting next week, with Pari covering ACDC moderation in the interim and Barnabas filling in for ACDT. All told: Nixo and Ansgar chair ACDE, Pari is interim on ACDC, and Mario, Barnabas, and Danceratopz rotate ACDT moderation.\nEverything Else\nIn addition to all of the above, teams used the in-person time to make progress on everything from better test harnesses (compressing Hive feedback loops from hours to minutes), to engine-API plumbing improvements (gossip dedup, batched calls, and light-client-driven head discovery), to hard tradeoffs around client diversity, and many other topics. The full list of session notes is available at soldogn.xyz.\n\nNext Steps\nFrom here, teams head home to take what was prototyped during the week and make it production-ready. Expect the next several weeks to be heads-down on hardening client implementations against the new specs, finalizing test coverage, and turning Soldøgn's draft PRs into merged code.\nAs always, the final decisions for values such as the 200M gas limit target and final repricing numbers will be made and shared publicly on AllCoreDevs calls. Expect these to be the major topics of the next week!\n\nThank you very much to everyone who came all the way up to 78°N and made this week a success! Special shout out to EthPandaOps for whipping the group into shape every day, and to everyone who worked under the midnight sun to make sure we hit our daily goals — including the Ethrex crew, joining us for their first interop. It was an incredibly productive week, and luckily we'll have a full short film to remember it by ☀️","tokens":3152,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268050713,"hash":"f68c305a1b62fe83332e53ac6e9f25d558b92b29"}
{"url":"https://docs.base.org/upgrades/azul/exec-engine","domain":"docs.base.org","title":"Execution Engine - Base Documentation","text":"​EVM Changes\n​Transaction Gas Limit Cap\nEIP-7825 introduces a protocol-level maximum gas limit\nof 16,777,216 (2^24) per transaction. Transactions exceeding this cap are rejected during validation.\nBase adopts the same cap as L1 to maximize Ethereum equivalence.\nDeposit transactions will be exempt from the transaction gas limit cap. They are already limited to 20,000,000 gas as that is the most gas that can be included in an L1 block.\n​Upper-Bound MODEXP\nEIP-7823 caps MODEXP precompile inputs to a maximum of\n1024 bytes per field. Calls with larger inputs are rejected.\n​MODEXP Gas Cost Increase\nEIP-7883 raises the MODEXP precompile minimum gas cost\nfrom 200 to 500 and triples the general cost calculation.\n​CLZ Opcode\nEIP-7939 adds a new CLZ opcode that counts the number\nof leading zero bits in a 256-bit word, returning 256 if the input is zero.\n​secp256r1 Precompile Gas Cost\nEIP-7951 specifies the secp256r1 precompile at address 0x100\nwith a gas cost of 3,450.\nBase already has the p256Verify precompile at the same address (added in Fjord via\nRIP-7212) with a gas cost of 3,450.\nFrom Azul, the gas cost increases to 6,900 to match the L1 gas cost specified in EIP-7951, maintaining\nstrict equivalence with L1 precompile pricing.\n​Networking Changes\n​eth/69\nEIP-7642 updates the Ethereum wire protocol to version 69,\nremoving legacy fields from the Status message and simplifying the handshake.\n​Discovery Protocol Now Uses basev0 Protocol ID\nThe discovery protocol for the execution layer now uses basev0 as the protocol ID. This allows Base nodes to find each other more quickly, especially on networks with fewer nodes like Sepolia.\n​Remove Account Balances & Receipts\nThe FlashblocksMetadata payload transmitted over the Flashblocks WebSocket is simplified in Azul.\nThe new_account_balances and receipts fields are removed. The access_list field remains but\nwill not be populated in Azul.\nBefore:\nFlashblocksMetadata Before Azul{\n \"block_number\": 43403718,\n \"new_account_balances\": {\n \"0x4200000000000000000000000000000000000006\": \"0x35277a9715c6df1c99de\"\n },\n \"receipts\": {\n \"0x1ef9be45b3f7d44de9d98767ddb7c0e330b21777b67a3c79d469be9ffab091dd\": {\n \"cumulativeGasUsed\": \"0x177d7bd\",\n \"logs\": [],\n \"status\": \"0x1\",\n \"type\": \"0x2\"\n }\n },\n \"access_list\": null\n}\n\nAfter:\nFlashblocksMetadata After Azul{\n \"block_number\": 43403718,\n \"access_list\": null\n}\n\n​RPC Changes\n​Engine API Usage\nAt and after Azul activation, block production and import use the following Engine API methods:\n\nengine_forkchoiceUpdatedV3 for starting block builds and forkchoice synchronization.\nengine_getPayloadV5 for fetching built payloads.\nengine_newPayloadV4 for importing payloads into the execution engine.\n\nengine_getPayloadV5 returns a V5 envelope, but the contained execution payload is still V4-shaped.\nAs a result, payload insertion continues through engine_newPayloadV4 (there is no engine_newPayloadV5\npath used by Base Azul clients).\nAzul constraints for this flow:\n\nBlob-related Engine API inputs are constrained to empty values:\n\nexpectedBlobVersionedHashes MUST be an empty array.\nblobsBundle in engine_getPayloadV5 responses is expected to be empty.\n\nexecutionRequests in engine_newPayloadV4 MUST be an empty array.\n\n​eth_config RPC Method\nEIP-7910 introduces the eth_config JSON-RPC method,\nwhich returns chain configuration parameters such as fork activation timestamps.\nBase Azul exposes eth_config using the standard EIP-7910 response schema.\nThe Base-specific behavior is:\n\nblobSchedule is always returned as zeroed values for current, next, and last.\nBase does not support native blob transactions, so it must not advertise synthetic Ethereum blob\nschedule defaults.\nprecompiles reflects the active EVM precompile set for that fork. This includes the standard\nEthereum precompiles plus any Base-active additions documented in the\nprecompiles specification.\nsystemContracts is limited to the contracts representable by EIP-7910. On Base this means:\n\nBEACON_ROOTS_ADDRESS is included once Ecotone is active.\nHISTORY_STORAGE_ADDRESS is included once Isthmus is active.\nDEPOSIT_CONTRACT_ADDRESS, CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS, and\nWITHDRAWAL_REQUEST_PREDEPLOY_ADDRESS are omitted.\n\nBase-specific predeploys and other Base system contracts documented in the\npredeploys specification are not serialized into\neth_config unless they are part of the EIP-7910 schema.Was this page helpful?Suggest editsRaise issue","tokens":1106,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268053943,"hash":"7c44d04865251a50c262e97a1e7fea093cf03961"}
{"url":"https://governance.aave.com/t/ethena-usde-on-aave-avalanche-assessments/25669/2","domain":"governance.aave.com","title":"Ethena USDe on Aave Avalanche Assessments - Risk / Assessments - Aave","text":"RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 18\n\n 2 / 2\n\n Sep 19\n\n Sep 18\n\n post by LlamaRisk on Sep 18\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of USDe on Aave Avalanche.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 10\n min\n\n post by LlamaRisk on Sep 18\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding USDe to the Aave V4 Core Hub on Avalanche. USDe is already listed on multiple Aave markets, including V3 and V4. Native USDe minting is not available on Avalanche, and USDe is instead bridged using LayerZero’s Omnichain Fungible Token (OFT) standard, with backing escrowed on Ethereum. The USDe OFT mesh currently spans 31 networks.\nOn the access control side, the USDe OFT on Avalanche is controlled by a custom timelock controller with a 24-hour delay, which maintains a whitelist allowing certain functions to bypass the delay. Currently, setPeer is whitelisted for the Ethena 5/10 multisig, allowing it to add or remove peers from the OFT mesh without a delay. While this can serve as a plausible incident response mechanism, it could also be exploited by an attacker-controlled address on a chain where the OFT has been compromised. A separate pauser mechanism for incident response currently doesn’t exist. Timelock coverage is absent on some prominent networks in the mesh, with Ethena working to extend coverage over the next few weeks.\nUSDe DEX liquidity on Avalanche is concentrated in a single Uniswap V3 USDe/USDC pool with approximately $0.5M in TVL, which is relatively low for initial liquidity. Thus, we’re proposing conservative initial caps. Given recent changes to the USDe IRM, particularly the base rate increase, borrowing USDe at current rates is unattractive. We therefore recommend onboarding USDe as a collateral-only reserve on Avalanche, with borrowing disabled.\n1. Asset Fundamental Characteristics\n1.1 Asset\nUSDe is a dollar-pegged synthetic stablecoin issued by Ethena Labs, backed by a diversified portfolio spanning liquid assets, institutional lending, RWA, DeFi lending, and delta-neutral strategies. It is not a fiat-redeemable stablecoin and does not represent a deposit claim. It is a claim on a diversified portfolio of yield-generating positions managed by the issuer, with a stability mechanism resting on primary-market arbitrage by whitelisted counterparties rather than on a statutory redemption right.\nUnder the Aave asset classification framework, USDe is a USD-pegged asset classified as a strategy-backed instrument. Holding USDe alone accrues no yield. Yield accrues to sUSDe, the ERC-4626 vault share obtained by staking USDe.\nUSDe on Avalanche is deployed as a LayerZero OFT similar to other chains in the mesh.\n1.2 Architecture\nEthereum\nDirect minting and redemption remain restricted to counterparties that have cleared KYC/KYB checks with Ethena. An approved counterparty transfers an accepted reserve asset and receives USDe in the same transaction, and burns USDe to receive backing assets on the same basis. There is no queue and no epoch: settlement for approved counterparties is atomic.\nThe mint and redeem contract on Ethereum exposes per-block maximum mint and redeem parameters, as well as a disableMintRedeem function. Both addWhitelistedBenefactor and disableMintRedeem are on the Ethereum timelock’s bypass whitelist, meaning the issuer can suspend primary minting and redemption without waiting out the 24-hour delay.\nExtensive analysis of the core architecture has been conducted in prior assessments that detail their underlying design and risk considerations, including: Asset Risk Assessment: Ethena USDe, Addendum to Asset Risk Assessment: Ethena USDe, and Onboard USDe to Aave V3 on Ethereum.\nAvalanche\nUSDe on Avalanche cannot be minted natively and is bridged exclusively through LayerZero V2. On Ethereum, an OFT Adapter escrows canonical USDe. On Avalanche, the OFT mints and burns against LayerZero messages. The Ethereum adapter currently escrows 1.95B USDe.\nThe Avalanche OFT has a peer configured for Ethereum only. No other pathway is peered, so every inbound and outbound transfer must route through Ethereum. Disruption of the Ethereum pathway leaves no alternative route. Bridge and verifier configuration for Ethereum to Avalanche:\n\nDirection\nRequired DVNs\nOptional DVNs (threshold)\nBlock confirmations\nSend library\nReceive library\nInherits LZ default receive library\n\nEthereum to Avalanche\nLayerZero Labs, Canary\nHorizen, Nethermind, StablecoinX (2 of 3)\n15\n0xbB2E…dCe1\n0xc02A…24C2\nNo\n\nAvalanche to Ethereum\nLayerZero Labs, Canary\nHorizen, Nethermind, StablecoinX (2 of 3)\n12\n0x197D…558a\n0xbf35…2c61\nNo\n\nEffective verification is 4 signatures from 5 distinct providers in each direction. The configuration is symmetric and, in both directions, the OApp pins its own receive library rather than inheriting LayerZero’s mutable default. The executor in both directions is LayerZero Labs’ standard executor.\nRate Limits: The Ethereum to Avalanche and Avalanche to Ethereum lanes are both configured at 10,000,000 USDe per 1 hour window. At the current Avalanche supply of 5,769,127 USDe, a single window’s outbound capacity is approximately 1.7 times the entire local supply, so the rate limit is not a binding constraint on an exit from Avalanche.\n1.3 Backing and Reserve Analysis\nTotal backing stands at $4.50B against 4.51B USDe outstanding, representing a 0.9973 coverage ratio before the reserve fund. Including the $62.09M reserve fund brings total coverage to approximately 1.011x. The backing composition has changed majorly from our prior assessments. Delta-neutral perpetual basis, once the entirety of the backing, is now 13.4% of it. The portfolio weight has shifted to new categories including RWA, institutional lending and existing strategies like DeFi Lending, subject to Ethena governance.\nimage2054×1035 173 KB\nSource: LlamaRisk, September 14, 2026\nThe dominant exposures are now credit risk on institutional borrowers, smart-contract and liquidation risk in DeFi lending venues, issuer risk on the stablecoins held as liquid balances, and manager and valuation risk on the RWA sleeve.\nThe asset-level series available from Ethena shows liquid cash rising to dominate the portfolio through 2026, with BTC and ETH balances (the crypto basis collateral) reduced to $293.0M and $281.1M respectively.\nimage2054×1035 206 KB\nSource: LlamaRisk, September 14, 2026\nEthena publishes backing at the position level, with the asset, chain, holding wallet, curator or custodian for each position. The tables below map each strategy sleeve. Shares are of total backing of $4.6B.\nCrypto Basis\n\nExchange\nAssets\nCustodian\nExposure\nShare of backing\n\nBinance\nBTC $205.6M, ETH $129.2M, SOL $20.5M, BNB $6.0M\nCeffu\n$361,357,082\n7.9%\n\nOKX\nETH $85.2M, BTC $72.1M\nCopper\n$157,316,071\n3.4%\n\nBybit\nETH $58.7M, BTC $1.6M\nCopper\n$60,302,014\n1.3%\n\nCoinbase INTX\nBTC $11.5M, ETH $9.9M\nCopper\n$21,477,984\n0.5%\n\nTotal\n\n$600,453,151\n13.0%\n\nCrypto basis collateral is not held on the exchanges themselves. It sits with an off-exchange settlement custodian and is mirrored to the exchange as margin, which is designed so that an exchange failure costs the hedge rather than the collateral. The custodian dependency this creates is covered in Section 3.5.\nDeFi lending\nUSDe’s backing includes $806.9M supplied into Aave V3 and V4, 17.5% of total backing, and Aave V3 alone, at $781.8M or 17.0%, is the single largest counterparty.\n\nProtocol\nAsset\nChain\nExposure\nShare of backing\nHolding wallet\n\nAave V3\nUSDT0\nPlasma\n$285,862,753\n6.2%\n0xb873…313c\n\nUSDT\nEthereum\n$210,055,322\n4.6%\n0xb873…313c\n\nRLUSD\nEthereum\n$151,841,776\n3.3%\n0xb873…313c\n\nUSDT0\nMantle\n$133,996,475\n2.9%\n0xb873…313c\n\nAave V4\nUSDT0\nMonad\n$19,230,967\n0.4%\n0xb873…313c\n\nUSDT\nEthereum\n$2,958,184\n0.1%\n0xb873…313c\n\nUSDC\nEthereum\n$2,958,184\n0.1%\n0xb873…313c\n\nMorpho, Jupiter Lend, and Kamino positions sit in curated vaults or isolated markets whose risk parameters are set by the named curator.\n\nProtocol\nAsset\nCurator\nChain\nExposure\nShare of backing\nHolding wallet\n\nMorpho\nPYUSD\nSentora\nEthereum\n$150,182,173\n3.3%\n0x2bf5…f67c\n\nUSDC\nGauntlet\nBase\n$75,046,466\n1.6%\n0x2bf5…f67c\n\nUSDC\nSteakhouse\nBase\n$60,821,257\n1.3%\n0x2bf5…f67c\n\nUSDC\nSteakhouse\nBase\n$30,585,278\n0.7%\n0x2bf5…f67c\n\nUSDG\nSteakhouse\nEthereum\n$23,555,139\n0.5%\n0x2bf5…f67c\n\nUSDtb\nSteakhouse\nEthereum\n$1,734,870\n0.0%\n0x2bf5…f67c\n\nJupiter Lend\nUSDG\nBitwise\nSolana\n$253,121,863\n5.5%\nC23F…H34L\n\nKamino\nPYUSD\nSentora\nSolana\n$249,984,435\n5.4%\nC23F…H34L\n\nTotal\n\n$1,651,935,142\n35.9%\n\nInstitutional lending\nEthena publishes a holding wallet for the Maple position and Bitcoin addresses for CBAM, and no address for FalconX, Kraken, or Anchorage, so those three are verifiable only through attestation. The failure impact of these strategies is default on the underlying institutional loans, with recovery dependent on borrower collateral.\n\nBorrower or platform\nExposure\nShare of backing\nPublished address\n\nMaple Institutional\n$302,941,604\n6.6%\n0xb873…313c\n\nFalconX\n$124,145,320\n2.7%\nNot published\n\nKraken\n$75,000,000\n1.6%\nNot published\n\nCBAM\n$5,000,000\n0.1%\n3LWi…d6C9, 3AYo…mjKx, 35Zs…zAXk\n\nAnchorage\n$1,000,000\n0.0%\nNot published\n\nTotal\n$508,086,924\n11.0%\n\nReal-world assets\nBoth funds hold AAA-rated CLO tranches. Their value is set by fund NAV rather than by an on-chain market price, so the failure modes are mark-to-market impairment of the tranches and redemption gating at the fund level. STAC’s underlying assets are custodied at BNY.\n\nAsset\nFund\nManager\nChain\nExposure\nShare of backing\nHolding address\n\nSTAC\nSecuritize Tokenized AAA CLO Fund\nSecuritize Capital, sub-advised by BNY Investments\nSolana\n$253,013,814\n5.5%\n4FaQ…rbtN\n\nJAAA\nJanus Henderson Anemoy AAA CLO Fund\nJanus Henderson, tokenized by Centrifuge\nSolana\n$202,296,550\n4.4%\n4FaQ…rbtN\n\nBase\n$50,574,137\n1.1%\n0x2d4d…7bb4\n\nTotal\n\n$505,884,501\n11.0%\n\nLiquid stablecoins\nEthena publishes five Ethereum wallets for these balances, 0x2d4d…7bb4, 0x1c3b…c337, 0x6cd5…c4b5, 0xafbb…2a62, and EthenaMinting, together with a custodial omnibus account whose custodian and share are not disclosed.\n\nAsset\nChain\nHeld in\nExposure\nShare of backing\n\nPYUSD\nEthereum\nEthena wallets and a custodial omnibus account\n$575,861,601\n12.5%\n\nRLUSD\nXRPL\nCopper\n$300,000,000\n6.5%\n\nUSDC\nEthereum\nEthena wallets and a custodial omnibus account\n$231,320,784\n5.0%\n\nUSDT\nEthereum\nEthena wallets and a custodial omnibus account\n$115,457,819\n2.5%\n\nUSDtb\nEthereum\nEthena wallets and a custodial omnibus account\n$90,787,120\n2.0%\n\nUSDG\nRobinhood\nEthena wallets and a custodial omnibus account\n$20,091,817\n0.4%\n\nUSDG\nEthereum\nNot published\n$1,499,938\n0.0%\n\nTotal\n\n$1,335,019,079\n29.0%\n\nPYUSD at 12.5% of backing, the largest stablecoin exposure and larger than any single hedging venue. USDe’s backing depends more on PayPal USD holding its peg than on any one exchange.\n1.3.1 Reserve fund\nThe reserve fund, held in a 4-of-10 Safe, stands at $62,081,856, equal to 1.35% of USDe underlying supply. Ethena’s documentation states that the share of protocol revenue allocated to the reserve fund is currently 0%, with 100% directed to incentive rewards, promotional distributions, and distribution incentives. The fund’s adequacy is a function of supply. Should supply return toward October 2025 peak levels without a change to the revenue allocation, coverage would fall to 0.42% correspondingly.\n1.3.2 Proof of reserves\nEthena publishes position-level backing data through its transparency dashboard, providing asset-level attribution of counterparties, custodians, and venues. Custodian attestations are published separately by Ethena Labs, HT Digital, LlamaRisk, and Chainlink. LlamaRisk independently attests to Ethena’s proof-of-reserves solution, with the corresponding PoR reports available here.\n1.4 Tokenomics\nAs of September 14, 2026, the USDe on-chain supply on Avalanche is 5.77M. This supply fluctuates depending upon bridged transfers from Ethereum via LayerZero.\n1.4.1 Token Holder Concentration\nimage811×249 20.9 KB\nSource: USDe Top 100 holders on Avalanche, Snowscan, September 14, 2026\nThe five top holders are as follows:\n\nContract1: 17.34% of the supply.\nContract2: 17.32% of the supply.\nEOA: 9.52% of the supply.\nUniswap V3 USDe/USDC Pool: 6.56% of the supply.\nContract3: 5.79% of the supply.\n\nNinety of the top 100 holders holding 71.78% share of USDe Avalanche supply are byte-identical proxies resolving to a single upgradeable beacon at 0xc831…8448, whose implementation and deployer are common across all of them.\n2. Market Risk\n2.1 Liquidity\nimage978×546 49.2 KB\nSource: DeFiLlama, September 14, 2026\nUsers can swap 132K USDe for USDC within a price impact of 7.5% on Avalanche.\n2.1.1 Liquidity Venue Concentration\nimage923×129 22.6 KB\nSource: GeckoTerminal, September 14, 2026\nUSDe DEX liquidity on Avalanche is concentrated in a single venue: Uniswap V3 USDe/USDC pool with $0.5M TVL, which is relatively low.\n2.1.2 DEX LP Concentration\nLiquidity in the Uniswap V3 USDe/USDC pool is highly concentrated, with a single EOA providing all of the liquidity. If this entity withdraws its position, USDe exit liquidity could become severely constrained, creating a liquidity crunch.\n2.2 Volatility and Peg History\nimage1754×889 37.8 KB\nSource: LlamaRisk, September 14, 2026\nSince the deployment of the Uniswap USDe/USDC pool, no sustained deviations from the peg have been observed. However, the peg deviation exceeded 150 bps on three occasions. As pool liquidity continues to deepen, the frequency and magnitude of such deviations are expected to decline, consistent with the improvement observed over the past month.\n2.3 Exchanges\nimage1200×340 53.8 KB\nSource: Coingecko, September 14, 2026\nUSDe is actively traded on centralized exchanges, including Binance and Bybit, with approximately $10M in sell-side liquidity available within a 2% price impact.\n2.4 Growth\nimage2052×1036 183 KB\nSource: LlamaRisk, September 14, 2026\nAggregate USDe supply is 4.61B, approximately 31% of the October 3, 2025 peak of 14.82B. The contraction is attributable to the October 2025 deleveraging event and to the subsequent compression in perpetual funding, which removed the yield differential that had drawn capital into sUSDe. On Avalanche, however, USDe supply remains above its October peak, currently standing at $5.78M. Current inflows are primarily dependent on cross-chain transfers from Ethereum via LayerZero.\n2.5 Oracle and Price Feed Treatment\nimage1792×1158 205 KB\nSource: LlamaRisk, September 14, 2026\nAave prices USDe using a capped oracle on the underlying USDT/USD feed categorized by Chainlink as low market risk, rather than the USDe/USD feed, which carries a medium market-risk classification and has experienced significant deviations from the peg on two separate occasions.\n\nEvent\nFeed low\nDeviation\nContext\n\nFebruary 21, 2025, 15:45 UTC\n$0.97721\n-228 bps\nBybit security incident\n\nOctober 10, 2025, 23:04 UTC\n$0.99294\n-71 bps\nMarket-wide deleveraging\n\nGiven the likelihood of such events occurring and the higher risk classification of the USDe/USD feed, we recommend maintaining the current price feed configuration.\n3. Smart Contract Security\n3.1 Architecture and Access Controls\n3.1.1 Contract Modification Options\nThe following contracts power USDe on Avalanche:\n\nENAOFT: Immutable ERC20 contract for the USDe token, controlled by EthenaTimelockController.\nLayerZero EndpointV2: Immutable contract, serves as the primary entry point responsible for managing cross-chain communications. It is controlled by LayerZero 5/7 threshold OneSig.\nSendUln302: Immutable contract, an Ultra Light Node (ULN) message library used for sending cross-chain messages. It is controlled by LayerZero 5/7 threshold OneSig.\nReceiveUln302: Immutable contract, a message library for receiving cross-chain messages. It is controlled by LayerZero 5/7 threshold OneSig.\n\nThe sensitive functions exposed by Avalanche USDe OFT:\n\nFunction\nCaller\nModifier\nEffective delay\n\nsetPeer\nEthenaTimelockController, via whitelisted executor (Ethena Multisig)\nonlyOwner\nNone\n\nsetRateLimits\nEthenaTimelockController\nonlyOwner or rate limiter\n24 hours\n\nsetRateLimiter\nEthenaTimelockController\nonlyOwner\n24 hours\n\nsetDelegate\nEthenaTimelockController\nonlyOwner\n24 hours\n\nsetEnforcedOptions\nEthenaTimelockController\nonlyOwner\n24 hours\n\nsetMsgInspector\nEthenaTimelockController\nonlyOwner\n24 hours\n\ntransferOwnership\nEthenaTimelockController\nonlyOwner, 2-step\n24 hours\n\nsend\nAny holder\nnone\nN/A\n\nThese are the USDe controlling wallets on Avalanche:\n\nEthena Multisig: 5/10 Safe multisig, admin of the timelock controller and can execute setPeer function bypassing the timelock.\nEthenaTimelockController: 24-hour RBAC timelock controlled by Ethena, handles USDe OFT wide admin functions.\n\n3.1.2 Timelock Duration and Function\nUSDe on Avalanche is owned by EthenaTimelockController with minDelay of 86,400 seconds (24 hours). However, this contract extends OZ’s TimelockController with a function-level whitelist. A holder of WHITELISTED_EXECUTOR_ROLE may call a function with no delay. Entries are added and removed by addToWhitelist and removeFromWhitelist, both of which are restricted to the timelock itself and therefore require a full 24 hour delay to take effect.\nOn Avalanche, the timelock’s only instant-effect authority over USDe is setPeer. Setting a peer to zero immediately severs a bridging pathway, which is a plausible incident-response action. However, the same authority can add or repoint a peer without delay, which presents a risk because peer mapping is the only authentication check applied to inbound messages.\nAvalanche’s OFT enforces rate limits only on outbound transfers, as do all Ethena deployments except Tempo. While Tempo’s adapter supports inbound rate limits, its only active lane currently has no limit. Consequently, a peer could be repointed to a contract outside Ethena’s control with no effective rate limit on either side, leaving the amount that could be minted on Avalanche effectively uncapped. The 5-of-10 Ethena Safe is the sole authority over this change. A separate pauser mechanism for incident response currently doesn’t exist.\nEverything else, including setRateLimits, setDelegate, transferOwnership, and the LayerZero library and DVN configuration, requires the full 24 hour delay on Avalanche.\n3.1.3 Multisig Threshold / Signer identity\nEthena Multisig (5/10 Safe) is the admin of the EthenaTimelockController contract and has the following role-based access control:\n\nRole\nAssigned addresses\nFunctionality\n\nDEFAULT_ADMIN_ROLE\nEthenaTimelockController\nGrant and revoke roles. Self-administered, so any role change must itself pass the 24 hour delay.\n\nPROPOSER_ROLE\nEthena Multisig\nSchedule operations, which then wait 24 hours.\n\nCANCELLER_ROLE\nEthena Multisig\nCancel a scheduled operation before execution.\n\nEXECUTOR_ROLE\nEOA A, Multisig B, Ethena Multisig\nExecute an operation once its delay has elapsed. Cannot schedule.\n\nWHITELISTED_EXECUTOR_ROLE\nEthena Multisig\nExecute a pre-whitelisted function with no delay.\n\n3.2 Multi-Chain Evaluation Scope\nUSDe is registered at 32 LayerZero V2 endpoints, of which 29 are EVM chains and three are non-EVM (Solana, Aptos, TON). Ethereum is the canonical chain and holds the OFT Adapter. Every other endpoint runs a mint-and-burn OFT.\nimage1920×1843 410 KB\nSource: LlamaRisk, September 14, 2026\nThe peered lanes all route through Ethereum, with outbound lanes connecting it to 29 of the 30 networks in the mesh. Swell is the sole exception and remains disconnected from all peers. Zircuit, Swell, zkSync, Scroll, Manta, Mode, Metis, and Kava appear to be marked for deprecation, with all inbound rate limits set to zero.\nOwnership\nOf the 32 networks in the mesh, 13 are controlled by an EthenaTimelockController, each with the same 24-hour minimum delay: Ethereum, Base, Robinhood, Monad, BNB Chain, HyperEVM, Avalanche, Arbitrum, MegaETH, Ink, Optimism, Linea, and Scroll.\nThe remaining 19 networks are controlled directly by multisigs, primarily 5/10 Safes on EVM chains, without timelock protection. Among these, Solana has the largest USDe OFT balance at 531M, controlled by a 4/10 Squads multisig with no timelock, followed by Plasma at 380.9M, TON at 171.8M under a 5/11 multisig, and Mantle at 60.3M. Berachain (11.9M) and Blast (0.93M) also remain under untimelocked ownership.\nEthena is working to extend timelock coverage to the remaining networks over the next couple of weeks, with deprecation planned for some networks by year-end.\n3.3 Audit Coverage\nEthena’s core protocol contracts (USDe, minting) have been audited by multiple firms including Zellic (July 2023) and others listed on Ethena’s audits page. The LayerZero OApp/OFT framework used for cross-chain bridging was separately audited by Zellic (September 2025). The Avalanche-specific OFT deployment uses the same audited codebase but has not received a chain-specific audit.\n3.4 Bug Bounty Program\n\nEthena: Maximum bounty of $3M via Immunefi for critical smart contract vulnerabilities (10% of affected funds, minimum $100k).\nLayerZero: Maximum bounty of $15M via Immunefi for critical smart contract vulnerabilities. However, OFT-related contract impacts are classified as low severity with a maximum payout of $10,000.\n\n3.5 Dependency Risk\nBridge and messaging\n\nDependency\nRole\nAuthority\nFailure impact\n\nLayerZero V2 Endpoint\nMessage transport\nRoutes verified messages to the OFT\nBridging halts in both directions.\n\nLayerZero Labs DVN\nRequired verifier\nMust sign every message\nBridging halts. Cannot forge alone.\n\nCanary DVN\nRequired verifier\nMust sign every message\nBridging halts. Cannot forge alone.\n\nHorizen, Nethermind, StablecoinX DVNs\nOptional verifiers, 2 of 3\nTwo must sign\nBridging halts if two of the three are unavailable.\n\nLayerZero Labs Executor\nDelivers verified messages\nCalls lzReceive on the destination\nMessages verify but do not deliver until an alternative executor is used.\n\nEthereum OFT Adapter\nEscrow\nHolds 2.03B USDe backing all bridged supply\nEscrow compromise breaks the backing of every bridged USDe including Avalanche.\n\nStrategy risk\nBeyond the bridge, USDe depends on four layers of third parties through its backing: the managers who run each strategy, the protocols the capital is deployed into, the chains those protocols run on, and the custodians holding off-chain collateral. Position-level detail is in the strategy tables in Section 1.3.\nOutside Aave, all DeFi lending exposure is managed by a third-party curator that sets each market’s risk parameters, collateral rules, and allocation, rather than by Ethena directly. Institutional and RWA exposure is likewise delegated to a lending platform or a fund manager. Sentora is the largest curator at $400.2M (8.7% of backing), across a Morpho PYUSD vault on Ethereum and an isolated Kamino PYUSD pool on Solana, so a single curator’s risk decisions reach two protocols on two chains. Aave supply ($806.9M) is not curator-managed, and its risk sits at the protocol level. CBAM ($5.0M) and Anchorage ($1.0M) complete the institutional book.\nProtocol risk\n35.9% of USDe backing sits in five lending protocols, and Aave (V3 & V4) accounts for 17.5%, across its Ethereum, Plasma, and Mantle markets. Morpho, Jupiter Lend, and Kamino positions sit in curated vaults or isolated markets, which confine a loss to the market concerned but place its parameters with the curator.\nChain risk\nOn-chain backing of $3,492.8M (75.9%) is spread across eight networks. Ethereum holds $1,558.2M (33.9%) and Solana $958.4M (20.8%), the latter concentrating two lending markets and both RWA funds. USDT0 positions on Mantle, Monad, and Plasma total $439.1M (9.5%) and depend on the USDT0 bridge as well as on the chain. Plasma carries both an Aave position and the largest USDe OFT balance still under untimelocked ownership (379,381,434 USDe, Section 3.2). The remaining $600.5M of crypto basis collateral and $508.1M of institutional loans sit off-chain.\n\nChain\nAllocations\nExposure\nShare of backing\n\nEthereum\nLiquid stablecoins, Aave V3 and V4, Morpho\n$1,558,212,910\n33.9%\n\nSolana\nJupiter Lend, Kamino, STAC, JAAA\n$958,416,662\n20.8%\n\nXRPL\nRLUSD, custodied at Copper\n$300,000,000\n6.5%\n\nPlasma\nUSDT0 supplied to Aave V3\n$285,862,753\n6.2%\n\nBase\nMorpho USDC vaults, JAAA\n$217,027,138\n4.7%\n\nMantle\nUSDT0 supplied to Aave V3\n$133,996,475\n2.9%\n\nRobinhood\nUSDG\n$20,091,817\n0.4%\n\nMonad\nUSDT0 supplied to Aave V4\n$19,230,967\n0.4%\n\nAave is already deployed on Ethereum, Plasma, Base, Mantle, and Monad, all of which were assessed in depth as part of their respective onboarding processes. Solana, XRPL, and Robinhood, however, have not yet undergone a comparable assessment.\nCustodian risk\nCustodied backing totals $900.5M (19.6%) across two named custodians. Copper holds $539.1M, of which $239.1M is exchange collateral for OKX, Bybit, and Coinbase INTX under off-exchange settlement and $300.0M is RLUSD on XRPL, and STAC’s underlying assets are custodied at BNY. Ceffu holds the $361.4M of Binance collateral. Off-exchange settlement keeps collateral off exchange balance sheets, which moves the dependency from the exchange to the custodian rather than removing it.\n4. Regulatory Risk\nRegulatory risks associated with USDe were assessed in previous reviews, with no material changes identified. Accordingly, they are omitted from this report for brevity.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk serves as an independent attestor of Ethena’s PoR solution. LlamaRisk did not receive compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\n\n New Asset\n\n 1\n\n 223\n\n Sep 18\n\n USDe (USDe) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 148\n\n Jul 1\n\n [Direct-to-AIP] Onboard USDe to the Aave V3 MegaETH Instance\n\n New Asset\n\n 5\n\n 752\n\n Apr 20\n\n [Direct to AIP] Onboard sUSDe and USDe to Aave V3 Avalanche Instance\n\n Governance\n\n 2\n\n 548\n\n Sep 2025\n\n Staked USDe (sUSDe) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 97\n\n Jul 1","tokens":6720,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268058011,"hash":"fc38159a87e49625e3298b82f29ab011bc914b9e"}
{"url":"https://blog.ethereum.org/2023/02/07/edelweiss-interop-recap","domain":"blog.ethereum.org","title":"Edelweiss Interop Recap | Ethereum Foundation Blog","text":"Edelweiss Interop RecapPosted by EF Protocol Support on February 7, 2023Research & DevelopmentWith The Merge now firmly behind us, protocol developers have been making progress across a (record?) number of areas over the past few months. Withdrawals, danksharding, EOF, verkle tries, history expiry, SSZ and more have all seen significant progress recently!\nIn order to help move each of these threads forward, and to run through one more series of Shapella stress tests, client team members gathered in person for a week-long interop event in Austria: Edelweiss 🏔️\nUnlike Amphora, which had a singular focus on The Merge, this event had two major tracks, focused on the Shapella and ProtoDanksharding network upgrades respectively. Several breakout sessions were also held to dive into other open problems. Here is a brief overview of what was accomplished, as well as links to artifacts from the workshops & ongoing discussion threads.\n\nShapella\nThe week began with a Shanghai/Capella mainnet shadow fork. Flooding the network with withdrawal credential update messages revealed performance issues on the network, and led to a different consensus-layer queueing design to process these messages.\nThroughout the week, additional devnets were launched and stress tested with large amounts of credential updates, withdrawals, and even bad blocks. Client implementations ended the week hardened and ready for the fork on the newly-launched Zhejiang testnet.\nAssuming the Shapella upgrade happens without issue on Zhejiang, the Sepolia and Goerli testnets will be upgraded next!\n(Proto)Danksharding\nThe main EIP-4844 interop goal was the launch of an all-client EIP-4844 devnet. By Friday, all but one client were syncing on the network!\nSeveral design discussions also took place during the week, stemming from a transaction pool design proposal. Questions around allowing \"blobless\" 4844 transactions, if and how blocks & blobs should be coupled for gossip and how to encode these transactions were discussed extensively and surfaced on last week's AllCoreDevs Execution Layer call.\nOver the next few weeks, teams hope to finalize all spec changes resulting from these discussions and launch a new devnet.\nEVM Object Format (EOF)\nAfter having been conditionally accepted and then removed from Shanghai, EOF was one of the topics where opinions about the best path forward diverged the most.\nWhether EOF should ban code introspection, aim for a minimal deployment ASAP, or even only ever go live on L2s were all discussed during the week.\nNo concrete specification came out of the workshop, but teams now have a shared understanding of the design space and potential paths forward. The EOF breakout rooms resumes next week to continue this conversation!\nEverything Else\nAside from these three topics, teams discussed the future of light clients on the network, how the EL & CL specs processes could converge (and potentially carve out ERCs from other EIPs), launched a new Verkle Trie testnet, put forward a proposal to SSZ encode EL transactions, discussed changing the validator EL->CL deposit mechanics, and even started a Capella annotated spec!\n\nNext Steps\nLess than a week after the event, client teams have begun discussing Shapella timelines for testnets. Keep an eye out on this blog, as well as on clients' repositories, for announcements in the coming weeks!\nFor other efforts, such as EIP-4844, EOF, SSZ, expect to see active design discussions in the coming weeks, leading to prototype implementations afterwards.\nShapella is almost here, and Dencun is clear on the horizon 🌅","tokens":897,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268060566,"hash":"1f5cf213e1dac3e50e932f31e1db832a70e2d456"}
{"url":"https://docs.base.org/upgrades/azul/node-upgrade","domain":"docs.base.org","title":"Node Upgrade Guide - Base Documentation","text":"Azul activated on mainnet on May 28, 2026 18:00 UTC (1779991200). See the required software versions and full activation timestamps on the Azul overview.\nOnly base-reth-node (EL) and base-consensus (CL) support Azul. Nodes running op-node, op-geth, op-reth, nethermind, or kona must be migrated using the instructions below.\nBoth clients are now published from the base/base repository, which hosts the root docker-compose.yml and the .env.mainnet / .env.sepolia templates that operators previously pulled from base/node. Most configuration is preconfigured and can be overridden via environment variables — see those .env files for the full list of options.docker compose up pulls the published ghcr.io/base/node image; pass --build to compile the current tree, or set NODE_TAG=vX.Y.Z to pin a specific released image without a source build.\n​Migrating Execution Layer\n​Migrating from OP Reth\nIf you are already running OP Reth via the operator compose setup, update to the latest version and your node will automatically use base-reth-node. Your existing ./reth-data directory is fully compatible — no re-sync or snapshot restore is needed.\n\nStop your node:\ndocker compose down\n\nSwitch to base/base (the operator node is no longer published from base/node) and update to the latest version:\n# If you previously cloned base/node, clone base/base alongside it and copy over your .env file:\ngit clone https://github.com/base/base.git\ncp ../node/.env.mainnet ./base/.env.mainnet # or .env.sepolia\n\n# If you already track base/base:\ngit pull origin main\n\nStart your node:\ndocker compose up\n\nVerify client version: web3_clientVersion should include base in the version string (e.g. reth/v1.11.3-.../base/v0.9.0)\n\n​Migrating from Another Client\nop-geth and nethermind are no longer supported. You will need to start fresh with base-reth-node.\n\nStop your node:\ndocker compose down\n\nClone or update base/base:\ngit clone https://github.com/base/base.git\n# or, if already cloned:\ngit pull origin main\n\nRemove your old data directory (e.g. ./geth-data or ./nethermind-data).\n\nEdit the .env.mainnet or .env.sepolia file to match your preferences.\n\nBootstrap from a Reth snapshot to avoid a full sync.\n\nStart your node:\ndocker compose up\n\n​Migrating Consensus Layer\nReplace op-node with base-consensus by updating your environment variables.\n\nSet USE_BASE_CONSENSUS=true in your .env file.\n\nUpdate your .env file with the new BASE_NODE_* environment variables (see tables below).\n\nRestart your node:\ndocker compose up\n\nVerify:\n\nCheck consensus logs: docker compose logs -f node\nConfirm sync status: optimism_syncStatus continues to work\n\n​Environment Variable Mapping\nMost variables are already set in the base/base .env.mainnet and .env.sepolia templates. If you are migrating a custom op-node setup, use the table below to map your op-node environment variables to base-consensus. Most are optional. Run base-consensus node --help for the full list.\nop-nodebase-consensusOP_NODE_NETWORKBASE_NODE_NETWORKOP_NODE_ROLLUP_CONFIGBASE_NODE_ROLLUP_CONFIG—BASE_NODE_LOG_VERBOSITY—BASE_NODE_LOG_FORMATOP_NODE_L1_ETH_RPCBASE_NODE_L1_ETH_RPCOP_NODE_L1_BEACONBASE_NODE_L1_BEACONOP_NODE_L1_TRUST_RPCBASE_NODE_L1_TRUST_RPCOP_NODE_L2_ENGINE_RPCBASE_NODE_L2_ENGINE_RPCOP_NODE_L2_ENGINE_AUTHBASE_NODE_L2_ENGINE_AUTH—BASE_NODE_L2_ENGINE_AUTH_ENCODEDOP_NODE_P2P_BOOTNODESBASE_NODE_P2P_BOOTNODESOP_NODE_P2P_LISTEN_IPBASE_NODE_P2P_LISTEN_IPOP_NODE_P2P_LISTEN_TCP_PORTBASE_NODE_P2P_LISTEN_TCP_PORTOP_NODE_P2P_LISTEN_UDP_PORTBASE_NODE_P2P_LISTEN_UDP_PORTOP_NODE_P2P_ADVERTISE_IPBASE_NODE_P2P_ADVERTISE_IPOP_NODE_P2P_ADVERTISE_TCPBASE_NODE_P2P_ADVERTISE_TCP_PORTOP_NODE_P2P_ADVERTISE_UDPBASE_NODE_P2P_ADVERTISE_UDP_PORTOP_NODE_P2P_PRIV_PATHBASE_NODE_P2P_PRIV_PATHOP_NODE_P2P_PEER_SCORINGBASE_NODE_P2P_SCORINGOP_NODE_P2P_PEER_BANNINGBASE_NODE_P2P_BAN_PEERSOP_NODE_P2P_PEER_BANNING_THRESHOLDBASE_NODE_P2P_BAN_THRESHOLDOP_NODE_P2P_PEER_BANNING_DURATIONBASE_NODE_P2P_BAN_DURATIONOP_NODE_METRICS_ENABLEDBASE_NODE_METRICS_ENABLEDOP_NODE_METRICS_ADDRBASE_NODE_METRICS_ADDROP_NODE_METRICS_PORTBASE_NODE_METRICS_PORTOP_NODE_RPC_ADDRBASE_NODE_RPC_ADDROP_NODE_RPC_PORTBASE_NODE_RPC_PORTOP_NODE_RPC_ENABLE_ADMINBASE_NODE_RPC_ENABLE_ADMINOP_NODE_RPC_ADMIN_STATEBASE_NODE_RPC_ADMIN_STATEOP_NODE_SAFEDB_PATHBASE_NODE_SAFEDB_PATHOP_NODE_SYNCMODE—OP_NODE_VERIFIER_L1_CONFS—OP_NODE_L2_ENGINE_KIND—OP_NODE_L1_RPC_KIND—OP_NODE_L1_BEACON_FETCH_ALL_SIDECARS—OP_NODE_L1_BEACON_FALLBACKS—OP_NODE_ROLLUP_LOAD_PROTOCOL_VERSIONS—OP_NODE_P2P_STATIC—OP_NODE_P2P_DISABLE—OP_NODE_P2P_NAT—\n​FAQ\n\nDo I need to re-sync? Not if you are already running OP Reth. Existing data is compatible.\nWhat if I’m on op-geth or nethermind? You need to switch to base-reth-node. Use a Reth snapshot to bootstrap.\nDo OP namespace RPCs still work? Yes, all existing RPCs are supported.\nWas this page helpful?Suggest editsRaise issue","tokens":1212,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268063909,"hash":"f49f959b5b7eb66b9d03623806872626bbbb4dc7"}
{"url":"https://blog.ethereum.org/2021/10/15/amphora-merge-milestone","domain":"blog.ethereum.org","title":"Amphora: A Major Merge Milestone | Ethereum Foundation Blog","text":"Amphora: A Major Merge MilestonePosted by Tim Beiko on October 15, 2021Research & DevelopmentEarlier this year, the Rayonism hackathon kicked off to protoype the architecture for Ethereum's transition to proof of stake. The transition, often refered to as The Merge, will keep the existing beacon chain (eth2) and execution layer (eth1) clients, and \"merge\" both chains by making the beacon chain drive the execution layer's consensus. This approach is the most recent in a series of iterations to the Ethereum roadmap (more on that here).\nWhile Rayonism proved that this was a sound architecture, there were still several things left to design, implement and test, including the actual proof of work (PoW) to proof of stake (PoS) transition. To do so, client teams met face to face last week (analogous to the Eth2 Interop from 2019) for a workshop named Amphora 🏺.\nHere is an overview of the main things that were accomplished during the workshop, and the path from here to The Merge.\n\nAmphora Milestones\nThe purpose of the event was to get the execution and consensus layer client teams to iron out outstanding issues in the specification and reach a set of development milestones. Each milestone got clients closer to a fully functioning merge devnet which transitioned from PoW to PoS. Representatives of Besu, Erigon, EthereumJS, Geth, Nethermind, Nimbus, Lighthouse, Lodestar, Quilt and Teku attended the workshop in person. The Prysm team, along with several members from the aforementioned teams, participated remotely.\nThe Amphora Milestones aimed to first get clients conforming with the spec, then gradually adding more complexity and finally growing the amount of other clients they could interoperate with.\nThe first milestone, M1, only required clients to implement the merge specification. It was completed by most teams prior to the workshop even starting! To help clients validate their implementation, several - testing - suites were provided.\nThen, milestones M2, M3 and M4 had client teams set up devnets with an increasing technical complexity and node diversity. M2 had execution layer (EL) and consensus layer (CL) teams pair one on one, and launch a post-merge devnet. This ensured that both layers could successfully communicate via the Engine API in a PoS context.\nM3 is where the Amphora workshop moved a step beyond Rayonism: clients set up emphemeral devnets which ran through the PoW to PoS transition.\nThe transition is based on PoW difficulty: once a block's difficulty equals or exceeds a specific value, called TERMINAL_TOTAL_DIFFICULTY, or TTD, it is considered the final PoW block. The execution layer then begins listening to the PoS consensus layer for new blocks. To ensure that each team's implementation was robust, EL teams had to connect to two CL clients and vice-versa to pass M3.\nM4 was the real target for the event: to get multiple EL & CL clients on a devnet which went through the entire PoW to PoS transition. In other words, while M3 was about one-to-one devnets, M4 was about many-to-many.\nWe achieved this for a subset of the teams before the end of the workshop, so we then went for our stretch goal: M5.\nLasting Artifacts\nThis milestone aimed to turn Amphora from a short-lived event to long(er)-lived infrastructure that the community could use. M5 required client teams to start a devnet that would not only run through the entire transition with all client combinations, but that would persist beyond the Amphora event.\nOn the last day of the workshop, minutes before the final dinner was served, M5 was hit: a network of 10,000 validators across 100 nodes and several client implementations launched under PoW, reached the TERMINAL_TOTAL_DIFFICULTY, transitioned to PoS, and successfully finalized the chain 🎉!\n\nThe M5 devnet successfully finalizes post-merge, minutes before the workshop's closing dinner. Photo by Ben Edgington.\n\nBeyond Amphora\nAmphora's success provides great momentum for The Merge. Client teams now have a clear list of tasks they need to work toward, and enough progress has been made to begin reaching out to a larger segment of the Ethereum community.\nYesterday, a more stable version of the M5 Amphora devnet, Pithos, was launched. Now that this network is live (explorer here), expect public calls exploring how developer tools and other core Ethereum infrastructure can best prepare for the PoW to PoS transition.\nClient teams and researchers will keep iterating on The Merge specification to fix issues identified during Amphora and respond to feedback from the community. Within a few weeks the spec should be finalized and, soon after, a new stable testnet made available.\nThank you\nThe work accomplished during Amphora exceeded all of our expectations. For this, we want to thank the client teams and researchers, without whom, none of the specifications would have been written or implemented.\nAdditionaly, thanks to ConsenSys, Chainsafe and Ben Edgington for their excellent coverage of the workshop.","tokens":1249,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268070483,"hash":"9bba9564535a9630f3a5a79baebd3a3401eeda05"}
{"url":"https://blog.ethereum.org/2019/09/19/eth2-interop-in-review","domain":"blog.ethereum.org","title":"Eth2 Interop in Review | Ethereum Foundation Blog","text":"Eth2 Interop in ReviewPosted by Danny Ryan on September 19, 2019Research & DevelopmentLast week, seven of the eight Eth2 clients under active development succeeded in marking the major milestone of moving from single-client to multi-client testnets at the \"Interop Lock-in\". With this exciting success in Eth2 development, we wanted to reflect on how this point was reached and on what it means to the Ethereum network and ecosystem.\nAnyone following Ethereum over the past couple of years has likely become familiar with terms such as \"Ethereum 2.0\", \"Eth2\", or \"Serenity\". Each of these refer to substantial upgrades slated for the Ethereum protocol that have been envisioned in some form since before the network went live in 2015.\nIn the early years of Ethereum, groundbreaking research was accomplished in parallel to the original chain (Eth1) launching, while the massive growth of the Ethereum community that followed aided the initial adoption of decentralized applications. Still, the road from these early breakthroughs to a highly decentralized, yet scalable proof-of-stake blockchain has been long. Over the past 18 months though, research has finally stablized into a cohesive and complete vision for the coming major upgrades known as Eth2.\nAs research moved into specifications toward the end of 2018, many teams (client teams) from across the community stepped up to build out core implementations of the protocol (clients). Since then, there has been a dynamic play between specification and implementation. Fort-nightly calls and a common spec repository organize communication and the sharing of ideas, but client teams have primarily worked in relative isolation, building and testing their implementations of the protocol.\nWhile the spec was a moving target, clients could only dig so deep into interoperability and optimizations, but once the Phase 0 specification of Eth2 was deemed \"frozen\" on July 1, 2019, clients made tremendous progress and began to take concrete steps toward production.\nInterop\nJoseph Delong from Pegasys had the crazy idea of gathering members from each of the client engineering teams in a remote location for a week of interoperability work. The event was deemed the \"Interop Lock-in\" or as it was generally referred -- \"Interop\". With the spec freeze in sight and Devcon on the horizon, Interop in September was an opportunity have all of these stakeholders work through initial interop-issues in person.\nThe primary purpose of the event was to have each participating client to achieve pair-wise interoperability with each other client in small test networks -- Lighthouse <-> Artemis, Lodestar <-> Lighthouse, Lodestar <-> Artemis, etc.\nParticipating client teams included:\nArtemisLighthouseLodestarHarmonyNimbusPrysmTrinity\nAdditional goals involved testing (1) larger networks in both node count and (2) validator count, (3) networks with 3+ clients, (4) enhancing tooling for monitoring and debugging Eth2 networks, and (5) other fun things like getting raspberry pis running and building fork visualizers.\nLeading up to the event, some goals seemed like a stretch, but teams worked diligently until the deadline and achieved amazing progress. By the end of the week, client teams far exceeded original expectations of having a few pair-wise networks, instead completing the entire pair-wise tests, building a small network of all 7 participating clients, and more.\nThe following represent a glimpse into the highlights of the client successes, but is certainly not exhaustive:\nMulti-client testnets\n\nAll 7 participating clients achieved pair-wise interoperability, and although an 8th, Shasper, was not able to be in attendence, they have begun to work through this milestone as well.Many larger testnets were formed between 3+ clients, 3+ nodes, and higher than minimal validator counts.All 7 clients in attendence were successfully run on a single network.All participating languages' libp2p implementations are now interoperable after debugging some minor issues.\nNetwork debugging and tools\n\nSome consensus errors between clients were identified, debugged, and recorded as portions of the state transition that require increased test coverage.Command line tools were built to better debug ssz objects and state transitions (zcli, pycli, and similar tools embedded within clients).Progress made on metrics dashboards, a fork visualizer, and other tools to better understand clients and networksClients were packaged up into containers to perform large-scale network tests within the Whiteblock genesis platform.\nAnd then some\n\nClient teams served as eachother's first alpha users resulting in extensive build/run scripts and related documentation.Isolated load tests with Nimbus and Lighthouse handled 2000+ validators on a single machine paired with similarly full nodes over LAN.Multiple clients were built and tested on a small raspberry pi network.\nAnd beyond\nInterop marked a major inflection point for Eth2. There is still much work to accomplish before launch, but engineering efforts will increasingly be geared toward testnets, optimizations, and usability -- work that begins to shift this software into the hands of users.\nSo what's up next for client teams and eth2 development?\nBenchmarks and optimizationsTest sync, stress test networks, etcPublic and incentivized testnetsThird party auditsPolishing the validator user experience\nFinally, we owe a special thank you to the ConsenSys team for helping to organize, host and provide resources that made Interop possible.","tokens":1386,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268082011,"hash":"b7027299f1d8052fecca474659c2fcbedcfbd729"}
{"url":"https://forum.pyth.network/t/community-council-term-1-exit-report/2418","domain":"forum.pyth.network","title":"Community Council Term #1 Exit Report - Community Council - Pyth DAO","text":"Community Council Term #1 Exit Report \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 25\n\n 1 / 5\n\n Mar 25\n\n Mar 29\n\n post by Chop on Mar 25\n\n Chop\n\n Community Council Term 1 Exit Report\nSummary\nThis is the full Term 1 wrap-up for the Community Council — covering 12 months of operations. We established the foundation (role structures, reward systems, governance processes), shipped operational tooling (MissionMonitor, PythClippers, Pythentity, PythWheel), ran programs (Impact Awards, community missions, Vibecodeathon), and developed the strategic framework for Term 2.\nThe honest assessment: strategy outpaced execution in the back half. The systems are built and operational; scaling them is the Term 2 mandate.\n\nWhat We Delivered\nPrograms & Initiatives\nImpact Awards (ongoing)\n\n12 months of continuous operation\n\nCoverage: Discord engagement, content creation, governance participation, community support, educational content\n\nCommunity Missions (MissionMonitor)\n\nCampaign brief distribution system: Notion campaigns → mission briefs → Telegram + Discord\n\n30+ missions posted, over 500 submissions received\n\nJudges vote via Discord reactions, results tracked automatically\n\nGoogle Sheets export for treasury tracking\n\nVibecodeathon / Pyth Playground (Live)\n\nRecurring 6-week community hackathon — currently live with active submissions\n\nGEO (Generative Engine Optimization) requirements built into submission criteria — each submission creates public content\n\nJudging rubric, prize structure (~200,000 PYTH Round 1), T&Cs framework established\n\nConfirmed judges: Arguer, Lowkeigh (Community Council members)\n\nActive submissions: Pythian Peso Snake, FOGO Pulse, Pyngo, d1ckochart, Market DVR\n\nInfrastructure Built\nMissionMonitor Bot (Shipped & Live)\n\nDiscord bot for campaign distribution, submission tracking, judge voting, deadline enforcement\n\nAuto-creates submission threads, tallies judge votes, exports results to Google Sheets\n\nHosted on VPS, tested end-to-end with Community Council\n\nFirst mission posted and completed successfully\n\nReferrals system built: code generation, deep link attribution, 10% referrer split, 90-day expiry\n\nGitHub: Chop-Kampfire/MissionMonitor\n\nPythClippers Bot (6/8 Phases Complete)\n\nClip submission tracking across Discord and Telegram\n\nReward calculation engine, leaderboard system, dashboard UI\n\nPending: production API keys, VPS deployment, T&Cs legal sign-off\n\nDesigned to power the Clipping Incentive Program\n\nPythentity (MVP Live)\n\nCommunity-native identity and reputation system\n\nWallet signature verification, Discord OAuth linking, Pythenians NFT gating\n\nScore cards based on contribution history\n\nFunded through DAO governance grant (80K PYTH, processed at 100%)\n\nExtensive bugfixing and testing completed with Pythenian community members\n\nBuilt by 4–5 community contributors — community-owned, not third-party\n\nPythenians NFT Acquisition\n\n8+ month negotiation completed — $15,950 USDC (paid from Pythenians Treasury - not Community Council)\n\nCollection acquired as community identity asset.\n\nTwitter credentials, subscriptions, and multisig handover completed.\n\nPythWheel (Live on Monad)\n\nCommunity-built random rewards system powered by Pyth Entropy\n\nWallet signature verification, Whitelist manually uploaded by Admins (Community Council). Discord roles determine the amount of spins per week.\n\nRewards wheel (41.5K/month) funded through experiments lab budget (To be budgeted elsewhere in future)\n\nFunded through Experiments Lab (100K PYTH, processed at 60%, remaining 40K Pyth reserved for educational content creation)\n\nMultiple bug fixes and feature upgrades have been shipped.\n\nBuilt by 4 community members (paid), Project Managed by 1 community member (unpaid)\n\nEntropy PythWheel raffle wheel can be used in future to fairly distribute any kind of reward in future, with ability to filter by role, usernames, wallets etc.\n\nStrategy & Research\nClipping Incentive Program Spec\n\nFull technical specification: submission flow, reward calculation, tiered distribution\n\nT&Cs framework pending legal review\n\nPyth Related Dune Dashboards\n\nDune dashboards as visual reports for Council and Community use\n\nAll Dune dashboards created can be seen from bats4 Dune homepage and the Council’s own Dune account\n\nMain Dashboards:\n\nCommunity Council Report - Pyth Community Council Pyth distribution DB (to be updated)\n\nPyth OIS/Governance Staking\n\nPyth Community Grants (to be updated)\n\nPyth Price Feeds (Core)\n\nPyth DAO Treasury and Product Fees\n\nDiscord & Community Operations\n\nDiscord server restructure: merged Temple & Waiting Room, added Intelligencia bot\n\nRole system maintained: Chirons (20 members), Mensarius (14 members)\n\n67,000 server members\n\n366 active members (monthly)\n\nExternal Engagement\nContent Pipeline\n\n130+ video transcripts indexed and ready for clipping\n\n12 evergreen blog posts written by Pierre (ready to publish)\n\nXAU (gold) Asset Info Pack produced — blog, FAQ, fact sheet\n\nAsset blog template created for future asset classes\n\nFinancial Report\nTerm 1 Budget Actuals\n\nPeriod\nBudget (PYTH)\nSpent (PYTH)\nRemaining (PYTH)\nUtilization\n\nCycle 1 (Apr–Sep)\n1,840,000\n1,322,181\n517,819\n71.9%\n\nCycle 2 (Oct–Mar)\n1,890,000\n2,348,385\n-458,385\n124.3%\n\nTotal Term 1\n~3,730,000\n~3,670,566\n~59,434\n98.4%\n\nWhy the utilization gap between cycles: Cycle 1 underspent because programs were still being designed and built. By Cycle 2, programs were operational — Impact Awards running monthly, Kaito costs scaling (35K → 234K PYTH/month), Experiments Lab funding active development. The Cycle 2 overspend was absorbed by the Cycle 1 surplus, resulting in 98.4% total utilization across the full term.\nSpending by Category\n\nCategory\nCycle 1 Budget\nCycle 1 Spent\nCycle 2 Budget\nCycle 2 Spent\nTerm 1 Total Spent\n\nRole Stipends\n120,000\n155,718\n120,000\n284,140\n439,858\n\nImpact Awards\n210,000\n224,396\n210,000\n189,524\n413,919\n\nKaito\n1,000,000\n477,887\n600,000\n1,015,871\n1,493,758\n\nExperiments Lab\n90,000\n44,180\n480,000\n403,800\n447,980\n\nCouncil Stipend\n420,000*\n420,000*\n420,000*\n420,000*\n840,000*\n\nContingency\n—\n—\n60,000\n35,050\n35,050\n\nTotal\n1,840,000\n1,322,181\n1,890,000\n2,348,385\n3,670,565\n\n*Council Stipend is paid directly from the DAO treasury to council members — not from the council multisig. This avoids a conflict of interest (council members don’t pay themselves). Cycle 2 stipend is committed but not yet disbursed.\nKey observations:\n\nKaito was the largest spend category, growing from ~80K PYTH/month in Q2 2025 to 234K PYTH/month by December 2025 as the platform scaled. This single line item consumed 53% of total spend.\n\nRole Stipends exceeded Cycle 1 budget as the role system expanded, then grew further in Cycle 2 with more active community roles.\n\nExperiments Lab funded community-built infrastructure: MissionMonitor, PythClippers, Pythentity.\n\nCouncil Stipend shows 0 spent from the council treasury because stipends are paid directly by the DAO to avoid a conflict of interest — council members don’t pay themselves from their own multisig.\n\nFunds Remaining\n\nCurrent wallet balance: 376,480.91 PYTH + 4.62 SOL. This includes ~317,000 PYTH in committed payments not yet disbursed, including Pyth Playground Round 1 prizes (~200K PYTH). Effective remaining after all commitments: ~59,400 PYTH — consistent with the budget vs. actuals totals above.\n\nWallet: GKuPcXtNRJwZGrJ8tV25jSbLHZe71BUdUXVzjGLXkSt9\n\nNote: Remaining funds are to cover API & Claude code development costs, in addition to the Pyth Community Hackathon. After all committed disbursements, the effective remaining balance is ~59,400 PYTH — consistent with the budget vs. actuals totals above.\n\nDisposition: Any unused funds return to the DAO treasury. No rollover beyond the interim bridge period.\n\nWhat We Learned\n1. Content Quality From Genuine Contributors > Volume From Anonymous Accounts\nContributors who actually use Pyth — who’ve integrated the price feeds, participated in governance, engaged with the data — produce fundamentally different content than anonymous accounts grinding for rewards. That quality difference matters for domain authority and long-term content value.\n2. Build the Tools, Then Scale the Programs\nThe biggest lesson: infrastructure before programs. We spent significant time building MissionMonitor, PythClippers, and Pythentity because scaling community programs without operational tooling creates manual bottlenecks that don’t compound. The tools are now built or near-complete. Term 2 is about running programs on that infrastructure at scale.\n\nWhat Comes Next\nThe Community Council is seeking Term 2 renewal. See companion posts:\n\nCommunity Council Election #2 — Election Guide: [FORUM URL TBD]\n\nCommunity Council Term 2 Budget Proposal: [FORUM URL TBD]\n\nTerm 1 built the infrastructure. Term 2 runs the machine.\nQuestions? Tag the Community Council in Discord or comment on this post.\n\n [PASSED] OP-PIP-114: Community Council Term 1 Cycle 2 Stipend Disbursement\n\n Guide for the Community Council Election #2\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n post by totti on Mar 26\n\n post by theretardedadrian on Mar 26\n\n post by Mersault on Mar 26\n\n post by Ricardo on Mar 29\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n Pyth Community Council\n\n Ideas Bank\n\n 73\n\n 1.7k\n\n Aug 2024\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":2430,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268089840,"hash":"23de03af28b3a1d68c4f7937e7beb18ce03c6913"}
{"url":"https://ethresear.ch/t/using-icos-to-fund-science/920/27","domain":"ethresear.ch","title":"Using ICOs to fund science - Better ICOs - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 3\n\n 2\n\n 2\n\n read \n\n 6\n min\n\n Jan 2018\n\n 26 / 26\n\n May 2018\n\n May 2018\n\n Load more posts above\n\n post by kladkogex on Jan 29, 2018\n\n kladkogex\n\n FBrinkkemper\n\n Yes - I think this is a very good point ! We all need things like good crypto libraries, or and there should be a way to fund this …\n\n post by bpolania on Jan 31, 2018\n\n bpolania\n\n I have always thought that the white paper itself is not required to be a smart-contract, not on it’s entirety but a reflection of the paper document, so in a similar fashion to how gas in managed, the ICO company can set a price for the citation and the author of the paper can decide to accept it or not.\nHaving the white paper in the blockchain will come with additional benefits in terms of accountability but they are outside the scope of this thread, I’ve designed a contract for a white paper, let me know if anyone’s interested.\n\n post by kladkogex on Feb 1, 2018\n\n kladkogex\n\n Boris nice - may be you can share a GitHub link then ?\n\n post by bpolania on Feb 1, 2018\n\n bpolania\n\n I just created a repo for this: https://github.com/bpolania/WhitePaperContract/tree/master\nPlease note that this is a work in progress, it means that it’s untested and is lacking functionality, the main intention is to define how a white paper could be represented in the blockchain, so at this point it’s better if you think of it as pseudo-code.\nAlso, I haven’t though about the citation part up until I read this post, so that functionality is not there but I’ll be adding it gradually.\n\n post by jamesray1 on Feb 2, 2018\n\n jamesray1\n\n Note that the concept of\n\ncan be generalized to airdrops into other reputation systems.\n\n post by bpolania on Feb 2, 2018\n\n bpolania\n\n kladkogex\n\n The github repo now has citation related functionality\n\n post by rumkin on Feb 8, 2018\n\n rumkin\n\n I was thinking about such system but from another angle. What if to create kickstarter for scientists. Scientist or developer may to make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science.\n\n 1 month later\n\n post by akomba on Mar 18, 2018\n\n akomba\n\n jamesray1\n\n Yes, I think generalization would be a good idea – to include support for critical projects in the ecosystem as well (etherscan, etc).\n\n 10 days later\n\n post by musalbas on Mar 28, 2018\n\n musalbas\n\n This is also of interest: MathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\n\nMathCoin: A Blockchain Proposal that Helps Verify Mathematical Theorems In Public\nAbstract: A public blockchain is proposed in an attempt to enable the coin holders to participate in verifying mathematical theorems for public access. Incentives are designed to encourage any party to contribute their knowledge by buying tokens of mathematical propositions that they believe are true. The proposed blockchain is a platform for people to exchange their belief in mathematical propositions. An implementation of this blockchain proposal, once established, will provide the general public an easy and instant access to reliable knowledge without having to read difficult proofs or having to blindly trust a small number of experts. Conversely, experts from various fields may find it be much easier for making their work appreciated by more people, leading to a better impact. According to the incentive inherently provided by the blockchain, they can even earn significantly if they do prove some theorems that were not previously known by the blockchain. Foundations who are interested in the validity of a particular proposition not yet explicitly recorded on the blockchain can donate a fund, which will distribute to experts who contribute positive efforts toward solving the specified problems. Only the people who erroneously create or buy tokens of a proposition that is eventually proven false will lose money. A reference design of the proposed blockchain that attempts to achieve the above-mentioned goal is described and reasoned.\n\n post by MariusVanDerWijden on Apr 1, 2018\n\n MariusVanDerWijden\n\n bpolania\n\n Is your repository private?\nI tried to write my own implementation, it’s not finished and I’m new to this, so any comments are appreciated\nhttps://github.com/MariusVanDerWijden/smartcontracts/blob/master/FundScience.sol\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n I’m not sure how point two would work in practice; as an academic I do not see the incentive for allocating a certain percentage of my paper to each used citation; this mostly sounds like a lot of extra work and I think people will not fully commit to this.\nFurthermore, another problem which should be taken into account is how academics tend to uplift their h-index by conducting large research and then publishing the results not as one big paper but as multiple smaller ones, whereby their h-index gets increased and they can receive more citations (by both themselves as other scholars). This is a big problem in academia as it is, but it is hard to check for, and this would be a continuous problem if you allocate a percentage based on citations.\nI do not have the answers, but I do think that these are some important issues to take into consideration.\nNotwithstanding this, I think your general idea is good and at the very least a very important problem that the blockchain could help solve.\n\n post by kladkogex on Apr 3, 2018\n\n kladkogex\n\nIn reality it will not be so easy to do: as an academic if you do not allocate to your peers than the community may not like it. As an academic you know that the academic community is very tightly bound (reviewers, funding etc.)\n\n post by 7hKBg82PX on Apr 3, 2018\n\n 7hKBg82PX\n\n Of course, I think I may have explained myself unclearly. I wonder about allocating an exact percentage (and determining that exact percentage, you draw on many sources, often also to support the same claim), not about acknowledging your sources in the first place \n\n post by david.hite on Apr 4, 2018\n\n david.hite\n\n What do you think about this: scientist or developer may make a proposal to community to solve some problem and provide proofs of experience to realise it. Community may support his work in safe manner paying for milestones. It’s some kind of (DA)ICO but in model when results became a public property after some time. It’s a kind of open source but in science. Anyway, it’s better to use ICO rating, if you want to invest your money the best way.\n\n 10 days later\n\n post by Perun on Apr 14, 2018\n\n Perun\n\nThe main problem with this approach is that in academia contracts for, e.g., PhD researchers or postdocs are usually for at least 3 years, and hence tying funding to achieving short term milestones is not that easy to realize in practice. That’s why most funding agencies that offer support for basic research typically offer contracts that run for 3+ years. Of course these agencies ask for detailed work package description etc., but they will not stop funding if certain milestones after 1 year are not achieved.\n\n 22 days later\n\n post by kladkogex on May 6, 2018\n\n kladkogex\n\n A problem with proposals to solve a particular problem is that you never know whether your solve a problem before solving it ))) A proposals-based solution will facilitate solving easy-to-medium problems but not hard ones …\n\n 9 days later\n\n post by Triple-Blind-Reprodu on May 15, 2018\n\n Triple-Blind-Reprodu\n\n If I understood correctly this could be generally used as a way to fund & incentivize research if cast into contract or law:\n\ntechnology comes to market (using a specific scientific piece of work that is either piblished by patent or by paper.)\nTech company makes profit with this technology,\nLets say 3% of the annual profit is given back to “the scientific work” that came from academia, with an ICO that is in fact in this scenario similar to a stock. So there will be designated coinholders.\n“coinholders” get the coins by the following key (for example): 40% towards the researchers 40% for the institution 20% for cited papers.\n\nNow here os an idea how to solve the decision making effort:\n\nto help institutions/researchers decide which citations are the most important there could be a generally agreed on distribution of the 20% that stay for the citations:\n20% for (the sum of all) competing research papers that helped narrow down the path to the solution.\n40% for (the sum of all) research papers that built the scientific foundation directly linked to the scientific finding that builds the tech.\n40% for (the sum of all) the scientific principles that indirectly built the foundations of the research that was done.\nthis trickles down scientific generations: to reduce this effort at the beginning one simpley draws a line between the youngest cited and the oldest cited research papers ad distributes the ICO’s 50/50. 1999 - 1875 -> papers up until the year 1937 get 50% of the tokens.\n\n post by IAbda on May 16, 2018\n\n IAbda\n\n “to help institutions/researchers decide which citations are the most important there could be a generally agreed on distribution of the 20% that stay for the citations:”\nAll right, what about the citations in those citations? recursive…\n\n post by Triple-Blind-Reprodu on May 16, 2018\n\n Triple-Blind-Reprodu\n\n Thats exactly the benefit of it: basic research will finally get the apreciation it actually should get, while techcompanies don’t feel it. Since they will give them very indirectly a recursiveely smaller share of their profit. But in masses this will be respectable.\nThe limit will be the coin-dividability.\n\n post by kladkogex on May 16, 2018\n\n kladkogex\n\n I think most researchers are good people, the model of them voluntarily referencing will work )\n\n Powered by Discourse","tokens":2488,"squid":"ink-research","role":"Deep Scholar","at":1791268093575,"hash":"cbd00f5a472d4b3c76a08647e7ddea0b80881cec"}
{"url":"https://ethresear.ch/u/vbuterin/summary","domain":"ethresear.ch","title":"Summary - vbuterin - Ethereum Research","text":"Skip to profile content\n\n vbuterin\n\n Vbuterin\n\n Joined\n\n Oct 17, 2017\n\n Last Post\n\n Sep 24\n\n Seen\n\n Sep 26\n\n Views205876\n Trust Levelleader\n Group\n\n Nucleus\n\n ...\n\n Stats\n\n 1.7k\n\n days visited\n\n 6d\n\n read time\n\n 28m\n\n recent read time\n\n 1.3k\n\n topics viewed\n\n 8.9k\n\n posts read\n\n 118\n\n given\n\n 3.2k\n\n received\n\n 222\n\n topics created\n\n 1.3k\n\n posts created\n\n Top Replies\n\n Dec 2023\n ·\n  29\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n May 2020\n ·\n  26\n\n Enshrined Eth2 price feeds\n\n Jan 2024\n ·\n  20\n\n Properties of issuance level: consensus incentives and variability across potential reward curves\n\n Jan 2018\n ·\n  15\n\n Using ICOs to fund science\n\n Aug 2021\n ·\n  14\n\n Exit/entry queue clogging after withdrawals are enabled\n\n Jan 2018\n ·\n  13\n\n Minimal Viable Plasma\n\n More Replies\n\n Top Topics\n\n Jan 2018\n ·\n  289\n\n Minimal Viable Plasma\n\n Dec 2023\n ·\n  234\n\n Sticking to 8192 signatures per slot post-SSF: how and why\n\n Jan 2018\n ·\n  184\n\n Explanation of DAICOs\n\n Sep 2018\n ·\n  119\n\n On-chain scaling to potentially ~500 tx/sec through mass tx validation\n\n Sep 2021\n ·\n  101\n\n Cross-rollup NFT wrapper and migration ideas\n\n May 2025\n ·\n  89\n\n A local-node-favoring delta to the scaling roadmap\n\n More Topics\n\n Top Links\n\n truebit.substack.com/p/truebit-early-access\n\n EVM optimistic rollup using Truebit\n\n reddit.com/r/ethereum/comments/55m04x/lets_run_onchain_decentralized_exchanges_t\n\n Improving front running resistance of x*y=k market makers\n\n vitalik.ca/general/2019/04/03/collusion.html\n\n Minimal anti-collusion infrastructure\n\n notes.ethereum.org/SCIg8AH5SA-O4C1G1LYZHQ\n\n Convenience link to Casper+Sharding chain v2.1 spec\n\n hackernoon.com/blockchain-privacy-enhancing-technology-series-stealth-address-i-\n\n ERC721 Extension for zk-SNARKs\n\n github.com/ethereum/sharding/blob/develop/docs/doc.md\n\n Future-compatibility for sharding\n\n Most Replied To\n\n kladkogex\n\n Stan Kladko\n\n 51\n\n JustinDrake\n\n Justin Drake\n\n 44\n\n dankrad\n\n Dankrad\n\n 26\n\n jamesray1\n\n James Ray\n\n 24\n\n naterush\n\n Nate Rush\n\n 20\n\n MicahZoltu\n\n Micah Zoltu\n\n 19\n\n Most Liked By\n\n jamesray1\n\n James Ray\n\n 65\n\n abcoathup\n\n Andrew B Coathup\n\n 54\n\n MihailoBjelic\n\n Mihailo Bjelic\n\n 44\n\n sherif\n\n sherif samir\n\n 38\n\n amadeobrands\n\n Amadeo Brands\n\n 36\n\n karl\n\n Karl Floersch\n\n 36\n\n Most Liked\n\n dankrad\n\n Dankrad\n\n 6\n\n barryWhiteHat\n\n Barry White Hat\n\n 6\n\n JustinDrake\n\n Justin Drake\n\n 5\n\n AlexandreBelling\n\n Alexandre Belling\n\n 4\n\n nrryuya\n\n Ryuya Nakamura\n\n 4\n\n snjax\n\n Igor Gulamov\n\n 3\n\n Top Categories\n\n Topics\n Replies\n\n Sharding\n\n 73\n\n 347\n\n Proof-of-Stake\n\n 39\n\n 177\n\n Economics\n\n 28\n\n 177\n\n Plasma\n\n 10\n\n 89\n\n zk-s[nt]arks\n\n 3\n\n 62\n\n Execution Layer Research\n\n 6\n\n 59\n\n Top Badges\n\n Leader\n\n Granted global edit, pin, close, archive, split and merge, more likes\n\n Great Topic\n\n Received 50 likes on a topic\n\n Famous Link\n\n Posted an external link with 1000 clicks\n\n 3 awarded\n\n Great Share\n\n Shared a post with 1000 unique visitors\n\n Good Reply\n\n Received 25 likes on a reply\n\n 2 awarded\n\n Gives Back\n\n Has 100 liked posts and gave 100 likes\n\n More Badges\n\n Powered by Discourse","tokens":769,"squid":"ink-research","role":"Deep Scholar","at":1791268103574,"hash":"2435e273368e8173cfc98e37f39d867d99f16649"}
{"url":"https://forum.pyth.network/t/community-council-term-1-exit-report/2418/5","domain":"forum.pyth.network","title":"Community Council Term #1 Exit Report - Community Council - Pyth DAO","text":"Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 25\n\n 5 / 5\n\n Mar 29\n\n Mar 29\n\n post by Chop on Mar 25\n\n Chop\n\n Community Council Term 1 Exit Report\nSummary\nThis is the full Term 1 wrap-up for the Community Council — covering 12 months of operations. We established the foundation (role structures, reward systems, governance processes), shipped operational tooling (MissionMonitor, PythClippers, Pythentity, PythWheel), ran programs (Impact Awards, community missions, Vibecodeathon), and developed the strategic framework for Term 2.\nThe honest assessment: strategy outpaced execution in the back half. The systems are built and operational; scaling them is the Term 2 mandate.\n\nWhat We Delivered\nPrograms & Initiatives\nImpact Awards (ongoing)\n\n12 months of continuous operation\n\nCoverage: Discord engagement, content creation, governance participation, community support, educational content\n\nCommunity Missions (MissionMonitor)\n\nCampaign brief distribution system: Notion campaigns → mission briefs → Telegram + Discord\n\n30+ missions posted, over 500 submissions received\n\nJudges vote via Discord reactions, results tracked automatically\n\nGoogle Sheets export for treasury tracking\n\nVibecodeathon / Pyth Playground (Live)\n\nRecurring 6-week community hackathon — currently live with active submissions\n\nGEO (Generative Engine Optimization) requirements built into submission criteria — each submission creates public content\n\nJudging rubric, prize structure (~200,000 PYTH Round 1), T&Cs framework established\n\nConfirmed judges: Arguer, Lowkeigh (Community Council members)\n\nActive submissions: Pythian Peso Snake, FOGO Pulse, Pyngo, d1ckochart, Market DVR\n\nInfrastructure Built\nMissionMonitor Bot (Shipped & Live)\n\nDiscord bot for campaign distribution, submission tracking, judge voting, deadline enforcement\n\nAuto-creates submission threads, tallies judge votes, exports results to Google Sheets\n\nHosted on VPS, tested end-to-end with Community Council\n\nFirst mission posted and completed successfully\n\nReferrals system built: code generation, deep link attribution, 10% referrer split, 90-day expiry\n\nGitHub: Chop-Kampfire/MissionMonitor\n\nPythClippers Bot (6/8 Phases Complete)\n\nClip submission tracking across Discord and Telegram\n\nReward calculation engine, leaderboard system, dashboard UI\n\nPending: production API keys, VPS deployment, T&Cs legal sign-off\n\nDesigned to power the Clipping Incentive Program\n\nPythentity (MVP Live)\n\nCommunity-native identity and reputation system\n\nWallet signature verification, Discord OAuth linking, Pythenians NFT gating\n\nScore cards based on contribution history\n\nFunded through DAO governance grant (80K PYTH, processed at 100%)\n\nExtensive bugfixing and testing completed with Pythenian community members\n\nBuilt by 4–5 community contributors — community-owned, not third-party\n\nPythenians NFT Acquisition\n\n8+ month negotiation completed — $15,950 USDC (paid from Pythenians Treasury - not Community Council)\n\nCollection acquired as community identity asset.\n\nTwitter credentials, subscriptions, and multisig handover completed.\n\nPythWheel (Live on Monad)\n\nCommunity-built random rewards system powered by Pyth Entropy\n\nWallet signature verification, Whitelist manually uploaded by Admins (Community Council). Discord roles determine the amount of spins per week.\n\nRewards wheel (41.5K/month) funded through experiments lab budget (To be budgeted elsewhere in future)\n\nFunded through Experiments Lab (100K PYTH, processed at 60%, remaining 40K Pyth reserved for educational content creation)\n\nMultiple bug fixes and feature upgrades have been shipped.\n\nBuilt by 4 community members (paid), Project Managed by 1 community member (unpaid)\n\nEntropy PythWheel raffle wheel can be used in future to fairly distribute any kind of reward in future, with ability to filter by role, usernames, wallets etc.\n\nStrategy & Research\nClipping Incentive Program Spec\n\nFull technical specification: submission flow, reward calculation, tiered distribution\n\nT&Cs framework pending legal review\n\nPyth Related Dune Dashboards\n\nDune dashboards as visual reports for Council and Community use\n\nAll Dune dashboards created can be seen from bats4 Dune homepage and the Council’s own Dune account\n\nMain Dashboards:\n\nCommunity Council Report - Pyth Community Council Pyth distribution DB (to be updated)\n\nPyth OIS/Governance Staking\n\nPyth Community Grants (to be updated)\n\nPyth Price Feeds (Core)\n\nPyth DAO Treasury and Product Fees\n\nDiscord & Community Operations\n\nDiscord server restructure: merged Temple & Waiting Room, added Intelligencia bot\n\nRole system maintained: Chirons (20 members), Mensarius (14 members)\n\n67,000 server members\n\n366 active members (monthly)\n\nExternal Engagement\nContent Pipeline\n\n130+ video transcripts indexed and ready for clipping\n\n12 evergreen blog posts written by Pierre (ready to publish)\n\nXAU (gold) Asset Info Pack produced — blog, FAQ, fact sheet\n\nAsset blog template created for future asset classes\n\nFinancial Report\nTerm 1 Budget Actuals\n\nPeriod\nBudget (PYTH)\nSpent (PYTH)\nRemaining (PYTH)\nUtilization\n\nCycle 1 (Apr–Sep)\n1,840,000\n1,322,181\n517,819\n71.9%\n\nCycle 2 (Oct–Mar)\n1,890,000\n2,348,385\n-458,385\n124.3%\n\nTotal Term 1\n~3,730,000\n~3,670,566\n~59,434\n98.4%\n\nWhy the utilization gap between cycles: Cycle 1 underspent because programs were still being designed and built. By Cycle 2, programs were operational — Impact Awards running monthly, Kaito costs scaling (35K → 234K PYTH/month), Experiments Lab funding active development. The Cycle 2 overspend was absorbed by the Cycle 1 surplus, resulting in 98.4% total utilization across the full term.\nSpending by Category\n\nCategory\nCycle 1 Budget\nCycle 1 Spent\nCycle 2 Budget\nCycle 2 Spent\nTerm 1 Total Spent\n\nRole Stipends\n120,000\n155,718\n120,000\n284,140\n439,858\n\nImpact Awards\n210,000\n224,396\n210,000\n189,524\n413,919\n\nKaito\n1,000,000\n477,887\n600,000\n1,015,871\n1,493,758\n\nExperiments Lab\n90,000\n44,180\n480,000\n403,800\n447,980\n\nCouncil Stipend\n420,000*\n420,000*\n420,000*\n420,000*\n840,000*\n\nContingency\n—\n—\n60,000\n35,050\n35,050\n\nTotal\n1,840,000\n1,322,181\n1,890,000\n2,348,385\n3,670,565\n\n*Council Stipend is paid directly from the DAO treasury to council members — not from the council multisig. This avoids a conflict of interest (council members don’t pay themselves). Cycle 2 stipend is committed but not yet disbursed.\nKey observations:\n\nKaito was the largest spend category, growing from ~80K PYTH/month in Q2 2025 to 234K PYTH/month by December 2025 as the platform scaled. This single line item consumed 53% of total spend.\n\nRole Stipends exceeded Cycle 1 budget as the role system expanded, then grew further in Cycle 2 with more active community roles.\n\nExperiments Lab funded community-built infrastructure: MissionMonitor, PythClippers, Pythentity.\n\nCouncil Stipend shows 0 spent from the council treasury because stipends are paid directly by the DAO to avoid a conflict of interest — council members don’t pay themselves from their own multisig.\n\nFunds Remaining\n\nCurrent wallet balance: 376,480.91 PYTH + 4.62 SOL. This includes ~317,000 PYTH in committed payments not yet disbursed, including Pyth Playground Round 1 prizes (~200K PYTH). Effective remaining after all commitments: ~59,400 PYTH — consistent with the budget vs. actuals totals above.\n\nWallet: GKuPcXtNRJwZGrJ8tV25jSbLHZe71BUdUXVzjGLXkSt9\n\nNote: Remaining funds are to cover API & Claude code development costs, in addition to the Pyth Community Hackathon. After all committed disbursements, the effective remaining balance is ~59,400 PYTH — consistent with the budget vs. actuals totals above.\n\nDisposition: Any unused funds return to the DAO treasury. No rollover beyond the interim bridge period.\n\nWhat We Learned\n1. Content Quality From Genuine Contributors > Volume From Anonymous Accounts\nContributors who actually use Pyth — who’ve integrated the price feeds, participated in governance, engaged with the data — produce fundamentally different content than anonymous accounts grinding for rewards. That quality difference matters for domain authority and long-term content value.\n2. Build the Tools, Then Scale the Programs\nThe biggest lesson: infrastructure before programs. We spent significant time building MissionMonitor, PythClippers, and Pythentity because scaling community programs without operational tooling creates manual bottlenecks that don’t compound. The tools are now built or near-complete. Term 2 is about running programs on that infrastructure at scale.\n\nWhat Comes Next\nThe Community Council is seeking Term 2 renewal. See companion posts:\n\nCommunity Council Election #2 — Election Guide: [FORUM URL TBD]\n\nCommunity Council Term 2 Budget Proposal: [FORUM URL TBD]\n\nTerm 1 built the infrastructure. Term 2 runs the machine.\nQuestions? Tag the Community Council in Discord or comment on this post.\n\n [PASSED] OP-PIP-114: Community Council Term 1 Cycle 2 Stipend Disbursement\n\n Guide for the Community Council Election #2\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n post by totti on Mar 26\n\n totti\n\n The Community Council has done a stellar job this term. The foundation is solid, everything feels a lot more structured, and there is true alignment with the community, it doesn’t feel forced.\nNow it’s about taking everything that’s been built and executing at scale. Excited to see what Term 2 looks like.\n\n post by theretardedadrian on Mar 26\n\n theretardedadrian\n\n This is nothing short of spectacular. The community council have always made sure pyth community is fluid and well aligned for the next level of defi. Great work guys and Thank you for your service for the past 12 months.\n\n post by Mersault on Mar 26\n\n Mersault\n\n Term 1 was absolutely amazing. Thank you to everyone on the CCs. The next phase is all about scaling and expansion\n\n post by Ricardo on Mar 29\n\n Ricardo\n\n The community council has demonstrated exceptional commitment and impact, they’ve set a new standard for community leadership.\nHats off !\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n Pyth Community Council\n\n Ideas Bank\n\n 73\n\n 1.7k\n\n Aug 2024\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":2629,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268110022,"hash":"27190ad6185799f2778dbf13ddfc2f5f2a8fcebf"}
{"url":"https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989","domain":"ethresear.ch","title":"Sticking to 8192 signatures per slot post-SSF: how and why - Proof-of-Stake - Ethereum Research","text":"Sticking to 8192 signatures per slot post-SSF: how and why \n\n Proof-of-Stake\n\n single-slot-finality\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2023\n\n 1 / 41\n\n Dec 2023\n\n Jan 2024\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\n A major difference between Ethereum and most other (finality-bearing) proof of stake systems is that Ethereum tries to support a very high number of validators: we currently have 895,000 validator objects and a naive Zipf’s law analysis implies that this corresponds to tens of thousands of unique invididuals/entities. The purpose of this is to support decentralization, allowing even regular individuals to participate in staking, without requiring everyone to give up their agency and cede control to one of a small number of staking pools.\nHowever, this approach requires the Ethereum chain to process a huge number of signatures (~28,000 today; 1,790,000 post-SSF) per slot, which is a very high load. Supporting this load entails a lot of technical sacrifices:\n\nIt requires a complicated attestation propagation mechanism involving attestations being split between multiple subnets, needing to hyper-optimize BLS signature operations to verify these signatures, etc.\nWe don’t have a clear drop-in quantum-resistant alternative that is anywhere near efficient enough.\nFork choice fixes like view merge become much more complicated because of the inability to extract individual signatures.\nSNARKing the signatures is hard, because there’s so many of them. Helios needs to operate over a specialized extra signature, called the sync committee signature\nIt increases safe minimum slot times by requiring three sub-slots in a slot instead of two.\n\nThe signature aggregation system feels reasonable at first glance, but in reality it creates systemic complexity that bleeds out all over the place.\nFurthermore, it does not even achieve its goal. The minimum requirement to stake is still 32 ETH, which is out of reach for many people. And just from a logical analysis, it seems infeasible to make an everyone-signs-in-every-slot system truly enable staking for the average person in the long term: if Ethereum has 500 million users, and 10% of them stake, then that implies 100 million signatures per slot. Information-theoretically, processing slashing in this design requires at least 12.5 MB per slot of data availability space, roughly as much as the target for full daksharding (!!!). Perhaps doable, but requiring staking itself to be dependent on data availability sampling is a large complexity gain - and even that is only ~0.6% of the world population staking, and does not begin to get into the computational issue of verifying that many signatures.\nTherefore, instead of relying on cryptographers to create magic bullets (or magic bulletproofs) to make an ever-increasing number of signatures per slot possible, I propose that we make a philosophical pivot: move away from having such an expectation in the first place. This will greatly expand the PoS design space, and will allow for a large amount of technical simplification, make Helios more secure by allowing it to SNARK over Ethereum consensus directly, and solve the quantum resistance issue by making even boring long-existing signature schemes like Winternitz viable.\nWhy not “just do committees”\nMany non-Ethereum blockchains, faced with this exact problem, use a committee-based approach to security. During each slot, they randomly choose N validators (eg. N ~= 1000), and those are the validators responsible for finalizing that slot. It is worth reminding why this approach is insufficient: it does not provide accountability.\nTo see why, suppose that a 51% attack does happen. This could be a finality-reversion attack or a censorship attack. For the attack to take place, you do still need economic actors controlling a large fraction of the stake to agree to in the attack, in the sense of running software that participates in the attack with all validators that end up being selected for the committee. The math of random sampling ensures this. However, the penalty that they incur for such an attack is tiny, because most of the validators that agreed to the attack end up not being seen because they are not chosen for the committee.\nEthereum, at present, takes the opposite extreme. If a 51% attack takes place, a large fraction of the entire attacking validator set has their deposits slashed. The cost of an attack is at present around 9 million ETH (~$20 billion), and that assumes network synchrony breaks in a way that maximally favors the attacker.\nI argue that this is a high cost, but it is too high a cost, and we can afford to make some sacrifices in the matter. Even a cost of attack of 1-2 million ETH should be totally sufficient. Furthermore, the main centralization risks of Ethereum that are present today are in a totally different place: large-scale staking pools would not be that much less powerful if the minimum deposit size were reduced to near-zero.\nThis is why I advocate a moderate solution: one that makes some sacrifices on validator accountability, but still keeps the amount of total slashable ETH quite high, but in exchange gets us most of the benefits of a smaller validator set.\nWhat would 8192 signatures per slot under SSF look like?\nAssuming a traditional two-round consensus protocol (like what Tendermint uses, and like what SSF would inevitably use), you need two signatures per slot per participating validator. We need to work around this reality. I see three major approaches for how we could do this.\nApproach 1: go all-in on decentralized staking pools\nThe zen of Python contains a really key line:\n\nThere should be one-- and preferably only one --obvious way to do it.\n\nFor the problem of making staking egalitarian, Ethereum currently violates this rule, because we are simultaneously executing on two distinct strategies toward this goal: (i) small-scale solo staking, and (ii) decentralized stake pools using distributed validator technology (DVT). For the reasons described above, (i) is only able to support some individual stakers; there will always be very many people for whom the minimum deposit size is too large. However, Ethereum is paying the very high technical burden costs of supporting (i).\nA possible solution is to give up on (i) and go all-in on (ii). We could raise the min deposit size to 4096 ETH and make a total cap of 4096 validators (~16.7 million ETH). Small-scale stakers would be expected to join a DVT pool: either by providing capital or by being a node operator. To prevent abuse by attackers, the node operator role would need to be reputation-gated somehow, and pools would compete by providing different options in this regard. Capital provision would be permissionless.\nWe can make pooled staking in this model more “forgiving” by capping penalties, eg. to 1/8 of total provided stake. This would allow reducing trust in node operators, though it’s worth approaching this carefully due to the issues outlined here.\nApproach 2: two-tiered staking\nWe create two layers of stakers: a “heavy” layer with a 4096 ETH requirement that participates in finalization, and a “light” layer with no minimum (also no deposit and withdrawal delay, and no slashing vulnerability) that adds a second layer of security. For a block to finalize, both the heavy layer needs to finalize it and the light layer needs to have >= 50% of online light validators attest to it.\nThis heterogeneity is good for censorship and attack resistance, because one would need to corrupt both the heavy layer and the light layer for an attack to succeed. If one layer is corrupted and not the other, the chain halts; if it’s the heavy layer that was corrupted, the heavy layer can be penalized.\nAnother benefit of this is that the light layer can include ETH that is simultaneously used as collateral inside applications. The main downside is that it makes staking less egalitarian by enshrining a divide between small-scale stakers and larger stakers.\nApproach 3: rotating participation (ie. committees but accountable)\nWe take an approach in a similar spirit to the super-commtittee design proposed here: for each slot, we choose 4096 currently active validators, and we carefully adjust that set during each slot in such a way that we still have safety.\nHowever, we make some different parameter choices to get the “maximum bang for our buck” within this framework. Particularly, we allow validators to participate with arbitrarily high balances, and if a validator has more than some quantity M𝑀 of ETH (which would have to be floating) then they participate in the committee during every slot. If a validator has N < M𝑁 <𝑀 ETH, then they have a \\frac{N}{M}𝑁𝑀 probability of being in the committee during any given slot.\nOne interesting lever that we have here is decoupling “weight” for incentive purposes, vs “weight” for consensus purposes: each validator’s reward within the committee should be the same (at least for validators with \\le M≤𝑀 ETH), to keep average rewards proportional to balance, but we can still make consensus count validators in the committee weighted by ETH. This ensures that breaking finality requires an amount of ETH equal to > \\frac{1}{3}>13 of the total ETH in the committee.\nA back-of-the-nakpin Zipf’s law analysis would compute that amount of ETH as follows:\n\nAt each power-of-two level of total balance, there would be a number of validators inversely proportional to that balance level, and the total balance of those validators would be the same.\nHence, the committee would have an equal amount of ETH participating from each balance level, except the levels above the barrier M𝑀, where the validator is in the committee always.\nHence we have k𝑘 validators at each of log_2(M)𝑙𝑜𝑔2(𝑀) levels, and k + \\frac{k}{2} + ... = 2k𝑘 +𝑘2 +... =2𝑘 validators at the levels above. So k = \\frac{4096}{log_2(M) + 2}𝑘 =4096𝑙𝑜𝑔2(𝑀)+2.\nThe largest validator would have M * k𝑀 ∗𝑘 ETH. We can work backwards: if the largest validator has 2^{18} = 262144218 =262144 ETH, this would imply (roughly) M = 1024 and k = 256.\nThe total ETH staked would be:\n\nThe full stake of the top 512 validators (2^{18} * 1 + 2^{17} * 2 + ... + 2^{10} * 2^{8} = 2359296218 ∗1 +217 ∗2 +... +210 ∗28 =2359296)\nPlus the randomly sampled smaller stakes (2^8 * (2^9 + 2^8 + 2^ 7 ...) \\approx 2^8 * 2^{10} = 2^{18}28 ∗(29 +28 +27...) ≈28 ∗210 =218)\nIn total we get 26214402621440 ETH staked, or a cost of attack of ~900k ETH.\n\nThe main disadvantage of this approach is somewhat more in-protocol complexity to randomly choose validators in such a way that we get consensus safety even across committee changes.\nThe main advantages are that it preserves solo staking in a recognizable form, preserves a one-class system, and even allows for the minimum deposit size to be reduced to a very low level (eg. 1 ETH).\nConclusions\nIf we establish that in a post-SSF protocol, we want to stick to 8192 signatures, this makes the job much easier for technical implementers, as well as builders of side infrastructure like light clients. It becomes much easier for anyone to run a consensus client, and users, staking enthusiasts and others would be able to immediately work off of that assumption. The future load of the Ethereum protocol becomes no longer an unknown: it can be raised in the future through hard forks, but only when developers are confident that technology has improved enough to be able to handle a larger number of signatures-per-slot with the same level of ease.\nThe remaining job would be to decide which of the above three approaches, or perhaps something else entirely, we want to go with. This would be a question of which tradeoffs we are comfortable with, and particularly how we navigate related issues such as liquid staking, which could be resolved separately from the now-much-easier technical questions.\n\n Orbit SSF: solo-staking-friendly validator set management for SSF\n\n Simplified Active Validator Cap and Rotation Proposal\n\n Unbundling staking: Towards rainbow staking\n\n Rainbow roles & incentives: ABPS + FOCILR + AS\n\n Vorbit SSF with circular and spiral finality: validator selection and distribution\n\n 7\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 21\n min\n\n post by MicahZoltu on Dec 27, 2023\n\n MicahZoltu\n\nThere are many governments around the world who spend that much on one missile, or one plane. We should be designing systems resilient to state attackers who are willing to spend money to ruin your day. While 1-2M ETH may be enough to deter them from attacking, we have evidence that they will spend far more than this to achieve their goals, and many governments do appear to be heading in the direction of “destroy crypto” as one of their goals.\nOf course, I cannot say that 9M ETH is enough either, or maybe both are in fact more than enough! However, I don’t think it is as obvious as you imply that we can safely reduce the security budget. Lindy doesn’t apply to these things, because everything will be fine right up until it isn’t, then it is all very very bad all of a sudden.\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\nThere are many governments around the world who spend that much on one missile, or one plane. We should be designing systems resilient to state attackers who are willing to spend money to ruin your day. While 1-2M ETH may be enough to deter them from attacking, we have evidence that they will spend far more than this to achieve their goals, and many governments do appear to be heading in the direction of “destroy crypto” as one of their goals.\n\nA single 51% attack is not fatal to Ethereum; if Ethereum gets attacked once we can always adjust the params to push the security budget back up. But I think the better argument here is that there are all kinds of strategies to destroy Ethereum that would take much less than 1-2M ETH: social layer manipulation, supply chain attacks on software libraries, attacks on the p2p layer, etc.\nAnd I would argue that the best way to defend against the latter two especially is to make the protocol as technically simple as possible, minimize or avoid the use of crazy constructions that have 64 subnets etc. And that the benefits from doing that are much greater than the downsides of a “front-door” 51% attack costing 1 million ETH instead of 9 million ETH.\nSecurity through simplicity, rather than security through getting a big headline number inside a particular mathematical model of security that doesn’t even correspond to the easiest available attack vector.\n\n post by hanniabu on Dec 27, 2023\n\n hanniabu\n\n Great post and lots to think about!\n\nI guess that depends on perspective. Although Ethereum would live on, I know many in the ecosystem that would consider this a failure and it would love a lot of credibility.\n\nI think this is a dangerous mindset. Yes, while there are other cheaper attack vectors that we should work on improving, we should not use the weakest link as the bar for security. We should set the threshold high and work towards raising the bar across all attack vectors.\n\n post by RichardKoh1 on Dec 27, 2023\n\n RichardKoh1\n\nI think this is a dangerous mindset. Yes, while there are other cheaper attack vectors that we should work on improving, we should not use the weakest link as the bar for security. We should set the threshold high and work towards raising the bar across all attack vectors.\n\nThis is what Ethereum has already been doing for years already imo. How long do you expect the chain to stay in a limbo state susceptible to all kinds of attacks and unscalable until the 100% perfect solution is found? At a certain point before mass adoption occurs, decisions must be made using all the info and tech currently available.\n\n post by uri-bloXroute on Dec 27, 2023\n\n uri-bloXroute\n\nI’d like to emphasize that A LOT of Ethereum’s current censorship resistance today is coming from the 7% who do not participate in PBS, mostly solo-stakers\nwe should be mindful of their value of individual proposers when considering going all-out staking pools.\nnot to dis it, but emphasizing this point.\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\nI think this is a dangerous mindset. Yes, while there are other cheaper attack vectors that we should work on improving, we should not use the weakest link as the bar for security. We should set the threshold high and work towards raising the bar across all attack vectors.\n\nThis is a fair point. I think the better counterargument here is that simplifying the protocol is the way to raise a whole bunch of security weakpoints that we have including those that we don’t know about (the most dangerous!). And reducing the computational load of a node makes staking more accessible, increasing censorship resistance in a different way.\n\n post by sasicgroup on Dec 27, 2023\n\n sasicgroup\n\n What are the specific technical challenges of processing 1,790,000 signatures per slot after the SSF upgrade? and How would reducing the number of validators from 8192 to a lower number impact the security of the Ethereum network?\n\n post by OisinKyne on Dec 27, 2023\n\n OisinKyne\n\n To start with with my (biased) thoughts on Approach 1. The problem with solo staking is not only the bond, but also the return on it. If you take it down to 1 eth, the ~3% you’re making on it is ~$70 a year. Which needs a lot of sunk cost accounting to justify. Imo to decentralise the validator set effectively we need to make it appealing to have people delegate to these home stakers (we can see there is and always will be people who will want to delegate away this task for a fee), and the best way I’ve been able to see that achieved is through squad staking lowering the barrier to staking with non-professional entities. My aspiration is to get ‘normal people’ from low cost of living countries participating in DVs and earning a percentage of the rewards as a commission that amounts to a meaningful supplement to their annual income. At current parameters that’s maybe a 1% cut on a 100 validator cluster making circa ~$2.5k p.a. About the return of a single validator but without the capital.\nI’m not so sure of approach 2. I don’t know how much gain there is from the non slashable tier, and I fear high capital requirements for the primary tier would lead to high hardware and particularly bandwidth requirements, and Ethereum would drift away from its accessibility to consumer hardware. I’d maybe restrict the high performance machine requirements to proposers rather than all validators. (And take in ePBS with CR lists for that matter).\nI have one maybe basic question about SSF that I may as well ask. Would Ethereum retain something like GHOST that would continue liveness on in the event of losing a supermajority’s participation in an SSF paradigm, or would Ethereum opt to halt? I imagine it like SSF pulling forward Casper FFG from two epochs to a single slot, but were it to fail, ghost protocol would still allow for blocks to be produced that will eventually get finalised? Ethereum has lost its existing 2 epoch finality guarantee maybe twice for short periods, but I assume that it would be much more disruptive to the community were it to halt in those instances rather than just lose finality guarantees, but maybe strict SSF is what is needed by L2s for atomic composability, so idk.\nMy suggestions on the different paths to pursue include:\n⁃ Proceed with a change like the max effective balance one, that allows validators to go up to a certain stake (I would prefer to keep the option of ‘small’/32e validators for posterity and permissionlessness) EIP-7251: Increase the MAX_EFFECTIVE_BALANCE\n⁃ Get rid of committees so we can aggregate larger. Make aggregations attributable and economically rewarded/punished in protocol such that they are more respected. (Could be ignored if we fast track the SSF duty) EIP-7549: Move committee index outside Attestation\n⁃ I personally am a fan of the proposals relating to validator index reuse, though I may not be completely up to speed on the technical issues relating to adopting it. The indices being allocated are already 20% larger than the active set, and that will get worse with time. EIP-6914: Reuse Withdrawn Validator Indices\n⁃ Consider introducing something instead of the existing sync committee duty that looks like approach 3 in @vbuterin’s above post, bring it in not as the ultimate source of finality at first, but as an economically secured light client proof, and once happy it’s stable, maybe make it the canonical finality for the chain, and deprecate Casper FFG?\nThey are my somewhat disjointed thoughts on the matter. \ntl;dr: community led squad staking clusters are something we should encourage for the decentralisation of the network. SSF with halting is scary and I would suggest we be hesitant to give up weak liveness guarantees for the L1 that aims to be the most decentralised and credibly neutral and ww3 resistant.\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\nSSF with halting is scary\n\nTo be clear I do not support SSF with halting. When I say “SSF” you should always understand that as “something Tendermint-like but also with an LMD-GHOST-like fork choice rule that runs whenever finality does not happen”.\nThe thoughts on low-value solo staking are interesting! I think one big issue here is the raw technical burden of solo staking “meaningfully”: right now it’s a brute fact that you need a powerful computer and hundreds of gigabytes to solo stake, while you could theoretically participate in DVT with a light client, that’s not really meaningful for network security because you would just be following along whatever the majority of other stakers says regardless of whether they’re right or wrong. If that is not solved, solo staking for the masses will have to continue to fight a major uphill battle, but if it is solved, then lots of things become possible.\nGiven the above, in the short term the version of “squad staking” that makes sense thus becomes a squad all trusting one person in their squad, and accepting the risk of being leaked or slashed if that one person screws up. This at least contains the presently-high load of staking to one participant.\nOne other benefit that DV can provide for people in developing countries, especially regions with internet connectivity problems, is increasing uptime through safety-in-numbers: if you have five people and they can each only guarantee a 90% uptime, then with a 3-of-5 you can increase your uptime to ~99%.\nSo given that, if DV provides enough benefits that it is “the” clear way to stake for lower-income people, that is an argument for option (1): it’s the best solution so might as well rally around it and get all the protocol simplifications we can from doing so. But if we’re only half-convinced, then it’s an argument for (2) or (3), as those options are just as friendly to DV as (1) are but they also leave room for true solo stakers.\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\nYeah this is a fair point: that we basically still get a two-layer network topology, it’s just that the second layer is out-of-protocol. Some nuances there are:\n\nThe second layer doesn’t need to be a “regular” p2p network: if the pool is small you can just have everyone directly connect to everyone, and use one of the participants as a (untrusted) routing intermediary\nAs I wrote above, the staking structure today is not sufficient to truly enable everyone to solo stake, and so we see attraction to DVT on top of today’s structure. Hence, the status quo is moving toward a three-tiered p2p structure, which is even more complex/fragmented than two-tiered.\n\n post by Guest20444 on Dec 27, 2023\n\n Guest20444\n\n Regarding Approach 1: Small solostakers are the life blood of Ethereum. Those are the people that make Ethereum what it is. Removing this option and basically becoming like all the other POS chains is a mistake. Honestly this would fragment the community it would lead to a contentious fork. Allow people to run validators with more than 32 Eth it will consolidate a lot of big fish. And see how the situation looks after that. We wont be down to 4096 that shouldnt even be the goal. Ethereum should be proud of every single entity that validates. With this approach the entire consensus will become way more centralized.\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\n vbuterin\n\nWhat are the specific technical challenges of processing 1,790,000 signatures per slot after the SSF upgrade? and How would reducing the number of validators from 8192 to a lower number impact the security of the Ethereum network?\n\nThere are two challenges:\n\nCost of verifying the signatures, at block verification time and during aggregation time. This is dominated by BLS additions: to verify N𝑁 signatures, you need N𝑁 BLS additions plus one pairing (technically, you can do fancy pippenger-esque stuff and get a log(N)𝑙𝑜𝑔(𝑁) optimization factor, and on the other side you need O(log(N))𝑂(𝑙𝑜𝑔(𝑁)) rounds of aggregation: 2 now, likely 3 with SSF with that many validators, and 1 with my cap-to-8192 proposal, but these two nuances conveniently cancel out )\nThe data needed to pass around bitfields. The information-theoretic minimum is 1 bit per signature, but unfortunately the aggregation mechanisms require an increase to ~2 bytes per signature (unless we make the tradeoff of accepting much heavier computation costs). In addition to this there is extra overhead at attestation time.\n\nIf you reduce to 8192 signatures per slot, all these problems become no longer very challenging; the beacon chain passed 8192 signatures per slot way back in Nov 2021 (see: this statistic, divided by 32) so we know what such a load was like and it was very manageable.\n\n post by Zergity on Dec 27, 2023\n\n Zergity\n\nI don’t think a 51% attack can “destroy crypto”, the most they can do is re-org a couple of blocks to win an auction.\n\n post by MicahZoltu on Dec 27, 2023\n\n MicahZoltu\n\nA 51% attack could reorg finality. Reorging a couple of blocks can happen on accident, or can be done with something like 20-30% and it is “free” (you don’t get penalized for it).\n\n post by kladkogex on Dec 28, 2023\n\n kladkogex\n\n I feel that 1. is a good choice because it addresses the problem of wasteful computation in the network.\nAs far a small stakers are concerned, they can simply participate in one of decentralized staking pools.\nThe question is how can this limit of exactly (or approximately?) 8192 validators be enforced? Is it going to be some type of economic incentive/dissentive ?\n\n post by aivarasko on Dec 28, 2023\n\n aivarasko\n\n Guest20444\n\n Also, if removing solo stakers from the network, why to target consumer hardware. And in the end it becomes like all other chains.\n\n Analyzing Missed Slot Through The Lens of Relays -- A potential path for relay incentivization\n\n post by tbrannt on Dec 28, 2023\n\n tbrannt\n\n tbrannt\n\nI’d like to emphasize that A LOT of Ethereum’s current censorship resistance today is coming from the 7% who do not participate in PBS, mostly solo-stakers\nwe should be mindful of their value of individual proposers when considering going all-out staking pools.\n\nI want to emphasize how important I think this point is!\nImagine a situation where 90% of ETH is staked with 2 large staking pools and 10% of staked eth is distributed among tens of thousands of home stakers. Who would you think is more likely to include e.g. a tornado cash transaction?\nWe need to be careful to not miss important angles to look at this problem. How much a 51% attack costs is one. But another very important angle is how likely is it that every fee paying transaction will eventually be included? A long tail of small validators greatly hardens the property that Ethereum currently still has of eventually including every valid fee paying tx.\nThe problem I have with approach 1 in this regard is that relying on DVT so heavily greatly reduces the ability for single individuals to participate even anonymously and in secret without anyone knowing. Don’t underestimate the importance of these. Some of these stakers might participate in a way voluntarily sacrifying some returns by not extracting MEV and e.g. using VPNs that - because of how unreliable many of them are - cause lower rates of attestations. These stakers wouldn’t be able to offer competitive returns in a DVT scenrario. We should increase and decrease the min/max effeictive balance to e.g. 8 or 16 and 4096 eth to allow even more of them.\n\n post by Milli3E on Dec 28, 2023\n\n Milli3E\n\n I’m seeing a lot of support for Approaches 1 and 2, but both of those options are pretty significant pivots in Ethereum philosophy. Approach 3 seems to preserve all of the values that we like around low barriers for solo stakers, while economically taking advantage of large staker participation.\nThere is also a sort of elegance to decoupling staking weight for incentives from staking weight for consensus. This approach will mean the chain is incentivized to grow to as many nodes as possible without creating consensus bottlenecks, but still allows for the simplifications that prompted this discussion.\nI think for the most part Ethereum has made the right trade offs to get to where it is now and its philosophy regarding staking decentralization is well placed. Straying too far from that may result in unpalatable changes to consensus which the community might not be vocal about yet feel strongly towards.\n\n post by pradavc on Dec 28, 2023\n\n pradavc\n\n Though I am as biased as @OisinKyne when speaking about staking and DVT, I am more inclined toward Approach 3 than any other. Let me elaborate:\n\nComments on approach 1\nI feel there are a few issues with this approach. The main one would be on the philosophical part of:\n\nThere should be one-- and preferably only one --obvious way to do it.\n\nWe all know Ethereum has more than one execution and consensus client, not because there isn’t an objectively better programming language for building Ethereum (I am not opening this topic) but for resiliency and tolerance to human failures. Above all, philosophically speaking, Ethereum should try to be the most resilient distributed system that humans (and human mistakes) can build. Therefore, anything that is “only one” should be analyzed under heavy scrutiny because it might be the result of convincing ourselves of how good we are.\n\nOn the technical part, focusing entirely on staking pools does not solve the accountability problem, but it transfers it to the DVT layer. As we (and others) have faced and discussed @vbuterin, individual attributions of the DVT key shares operation create yet another data availability problem. At that point, accountability will be gone in the “Ethereum layer,” indeed, but it will be a problem for the DVT-powered staking pools that will nevertheless affect both pool participants and Ethereum in general.\n\nComments on approach 2\n\nCorrect me if I am wrong, but the main issue with this approach is that the “heavy” layer would virtually stay in control of the protocol, wouldn’t it? I.e., the heavy layer could unilaterally make decisions over the protocol and force the “light” layer to follow, or else the disagreement of the light layer will halt the network (note: not the disagreement of the heavy chain, because from Ethereum’s point of view, the heavy chain is “cooperating”). Coercion, by itself, holds a lot of power, and it is effectively the same power that validators have today (but at least it is much more distributed and not in the hands of a few significantly-sized clusters).\nTo me, this approach resembles what Polkadot does with the relay chain (or Tendermint with replicated security). Today we could advocate for 1 light layer, but why not 2, or 3? In the end, effectively, the chain is controlled by the relay/heavy chain because it is the only single point of failure, so how much can it handle?\n\nComments on approach 3\nI don’t have many comments on this one. I like the approach because, in addition to keeping solo staking as it is (given the dragon’s size, this is a big plus, touching as little as possible), it also promotes the inclusion of solo stakers with less than 32 ETH. It will be interesting to see how this approach plays out regarding incentives to become smaller or bigger depending on the staking concentration.\n\nTL;DR\nI would suggest focusing on approach 3 for the “core” Ethereum layer and decentralizing further with staking pools and DVT in the application layer (or in L2s) if needed. Ethereum should be robust and straightforward but always work regardless of the dependencies (light chains or staking pools) that are built on top of it.\n\n Load more posts below","tokens":8182,"squid":"ink-research","role":"Deep Scholar","at":1791268113947,"hash":"46959ffe1fdc1224718668a385b22cbc49c4b8f8"}
{"url":"https://forum.pyth.network/t/pyth-community-council/1582/1","domain":"forum.pyth.network","title":"Pyth Community Council - Ideas Bank - Pyth DAO","text":"Pyth Community Council \n\n Ideas Bank\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2024\n\n 1 / 74\n\n Jun 2024\n\n Aug 2024\n\n post by Debanked on Jun 18, 2024\n\n Debanked\n\n Abstract\nI propose the creation of a Community Council within the Pyth DAO to oversee community initiatives and foster engagement.\nThis initiative aims to cultivate a positive and dynamic community atmosphere, enhance brand awareness, and support the growth and development of the Pyth Network community.\nThe council will have formal responsibilities, term limits, member selection processes, and incentives.\nRationale\nThe establishment of a Community Council is crucial for the continued growth and cohesion of the Pyth Network.\nBy creating a dedicated team responsible for community engagement and initiatives, we ensure that our community remains vibrant, informed, and actively involved in the network’s evolution.\nThis council will serve as a bridge between the Pyth Network and its users, fostering a culture of collaboration and shared success.\nProposed Plan and Feasibility\nAfter discussions (2 weeks after posted on the forum), the community should reach consensus about several aspects of the community council:\n\nStructure of the council (Member count, term details, incentives)\nNomination and Election Processes\nResponsibilities\n\nCurrent Proposal:\nStructure of the council:\n\n6 members for a 6 month term\nNo limit on consecutive terms\n$500 / month stipend (paid in $PYTH)\n\nNomination and Election:\n\nPythians can nominate themselves or be nominated\n1K $PYTH staked for nomination\nVoting happens twice every 6 months on Realms to: (1) select the council members, (2) ratify this list.\n\nResponsibilities of the Council:\n\nGovernance Participation: Actively participate in governance discussions in the Pyth Forum and Realms.\n\nCommunity: Boost community engagement through Impact Awards program, Chirons selection and performance review, and other activities.\n\nBrand Awareness: Advocate for Pyth as a premier DeFi solution by engaging with projects, stakeholders, and individual market participants online.\n\nEducation: Inform and inspire individuals about the Pyth Network.\n\nPartnerships and Collaborations: Initiate and build partnerships with projects that enhance the Pyth ecosystem and community.\n\nCoordinate with Pyth Data Association: Collaborate and coordinate with the Pyth Data Association members, such as Chop and Pepito, on these community initiatives, resource allocation, and execution.\n\nQuestions or Uncertainties\n\nHow can we ensure that the council represents the diverse interests of the Pyth community?\n\nWhat criteria should be used to nominate and elect council members? Minimum amount staked? Be co-opted by someone?\n\nWhat should be the length of a term? Re-election policy?\n\nIn the case of a councilor not performing, how does he get removed and how does he get replaced?\n\nWhat should be the total budget allocated to the council for one term?\n\nWhat should be the stipend/reward for council members for one term?\n\n 16\n\n 12\n\n 10\n\n 9\n\n 7\n\n read \n\n 18\n min\n\n post by TheDetective on Jun 18, 2024\n\n TheDetective\n\n Interesting to see how this thing goes.\nSounds like a good proposal that if executed well will do good for the broad pyth community\n\n post by Planck on Jun 18, 2024\n\n Planck\n\n I think this is a great idea!\nQuestion : what position in the hierarchy will the Council members hold? Are they on the same level as Chop and Pepito, are they Chiron’s supervisors or will it be a separate working group?\nMy suggestions: the first term should be 3 months perhaps? Sort of like a probation term for everyone. To see how things work, what can be done better etc. Also, imo in case the councilor is not performing, the reelection should happen immediately and the person who won the vote should be in the potential candidates list for the next term automatically since there is no limit to consecutive terms.\n\n post by Slam.sol on Jun 18, 2024\n\n Slam.sol\n\n Sign me up.\nA six person council is nimble and able to get a meaningful spread of ideas to pursue.\nVery clever way to enhance the messaging and influence the direction of Pyth.\n\n post by Sloth1890 on Jun 18, 2024\n\n Sloth1890\n\n A lot of familiar sounding things in this proposal I am seeing… reading this gives me a sense of dejavu\n\n post by ed_pyth on Jun 18, 2024\n\n ed_pyth\n\n Wow! I’m here for it\nPyth is built for the community, and such a council would be a significant and powerful step towards this goal\nI see a world where multitudes of different cultures, sub-groups, and flavors of DeFi — like a federation of sorts — abide by the immutable governance rules of the Community Council to democratically bring about the type of Pyth Network community and spirit they want to see in the end.\nTribes, sub-cultures, geographies, and whole new movements\n\n post by Debanked on Jun 18, 2024\n\n Debanked\n\n Planck\n\n This is a good possibility for the first term atleast, non performing should be given a reminder but then I agree removal should be swift\nCan anyone be higher than Pepito & Chop?\nSanta Maria!\nWhat if one was in the council? As a type of lead of or between?\n\n post by Debanked on Jun 18, 2024\n\n Debanked\n\n Slam.sol\n\n Think they will also been keen & add even more depth to an already thriving community for the long term \n\n post by Sloth1890 on Jun 18, 2024\n\n Sloth1890\n\n When does the nomination process start. Also how will the voting take place? Weight to votes or a 1 to 1 vote.\nI nominate that og chiron sloth… \n\n post by bats4 on Jun 18, 2024\n\n bats4\n\n I have revisited the Pyth DAO Constitution earlier and read about the CO-PIPs for the creation of Pyth DAO councils and sub-committees and now it is here!\ni would like to add an additional to question/uncertainty number 4.\nHow will we measure if a councilor is not performing? Will there be an outside entity checking on them? Will they have something like KPIs to target?\n\n post by Sloth1890 on Jun 18, 2024\n\n Sloth1890\n\n With chirons I remeber chop setting out a pretty basic monthly ruleset. But what a chiron is for example has molded so much since the first couple of us where given the role.\nHold votes or polls once and a while to get a feel where the people stand on council.\nYou get a vote, we all get a vote… hopefully 1 to 1…\n\n post by Pepito on Jun 18, 2024\n\n Pepito\n\n I like where this is going! A must in my mind to keep giving the power to the Pythians on everything that happens for the Network and led by the community.\n\nI agree to align the term’s length with the 2 other councils (6 months) which gives time for the chosen Pythians to have time to make their mark and create value for the community. Re-election makes sense too as a performing council member is valuable and can keep his role if the Pythians decide to keep voting him in.\n\nAs for the underperformance, I can imagine a few KPIs to track but also believe that a low-performer/free-rider would be quickly spotted by the community and his fellow council members. If that were the case, council members could vote to oust him and I would propose for the council to select his replacement from a list of self-nominated community members. Voting again would be wasting precious time of the 6 months and slow down the council’s activity.\n\n500 $PYTH as stipend would make sense. I could imagine more to incentivize members to produce more and create more value.\nWill circle about the total budget after doing some math \n\nGood question as I would like to have different skillset among the members. Some with Discord moderation, some more external facing (on X), some with DeFi and NFTs knowledge and relationship for partnerships.\nThis is a great step in the right direction. Thanks a ton @Debanked on the initiative and work done!\n\n post by Pepito on Jun 18, 2024\n\n Pepito\n\nThe council would indeed take on this responsibility from what i see. Out of myself and Chop’s hands which is a great IMO.\n\nAs this would need to be passed with a constitutional PIP (whole DAO vote) this seems pretty tough as we’d likely need to vote again later on to move to 6 month terms. 3 months would be very short to get good early results.\n\n post by Credence on Jun 18, 2024\n\n Credence\n\n Good step towards a more decentralized Pyth ecosystem, I like the direction that @Debanked has proposed here\n2 comments here:\n\nI’m leaning towards a lower number of council members, with opportunities to grow the size whenever the needs arise. And also would be nice if the council members are kept to an odd number (e.g. 3 or 5) so there will always be someone that becomes the tie-breaker for any decisions made by the Community Council\n\nInstead of keeping it to a $ amount for the stipend, a fixed amount of PYTH will be easier for calculations (given $ amount in tokens can be highly volatile)\n\nAs for the questions - I have a few ideas\n\nEach council members can specialize in certain areas, e.g. 2 members specializing on Community (Telegram, Discord, X), 2 specializing on Education, and 2 specializing on Partnerships and Collaborations\n\nMinimum staked makes sense (I think the minimum threshold should be 1 month’s worth of stipend as a Community Council). One that could be interesting is to have a vouching system based on Discord roles, so members with higher Discord roles are prioritized over newer members\n\nLength of a term - 4 to 6 months makes sense, we can keep re-election policy as N/A for now until someone is found to abuse it\n\nI think for now, because the term is quite short, whenever someone does not perform the community members can just elect not to choose the same candidate for a repeat\n\nWill come to 5 in a bit, and 6 has been answered above\n\n post by Pepito on Jun 18, 2024\n\n Pepito\n\n Good stuff!\n\nThat could be better indeed. 5 makes sense to get a ‘high’ number of contributors. Although with the likely continuation of the Chirons program, I don’t envision the decision-making to be solely in the council’s hands but to include the xx chirons (8-15?). Makes sense as they are also on the ground and active within the community.\n\nAnd it’s because of this potential volatility that denominated in $ is better IMO to reassure and secure a stable monetary incentive for councilors. Interested to hear others’ opinions on this.\n\n post by Debanked on Jun 18, 2024\n\n Debanked\n\n Credence\n\n Mario coming in \nI like the 5no idea & making it a little competitive, this is meant to be the best of community with the best of interest for the network.\nAreas of specialization for what makes Pyth community works for me, either overseeing these areas & creating overachievers\nPayments best left to community feedback for me\n\n post by eileen on Jun 18, 2024\n\n eileen\n\n Imo we have too few active members in our community to strategize any of this into priority right now.\n\n post by Debanked on Jun 18, 2024\n\n Debanked\n\n The hope will be such a council will be active I growing our mindshare as a community\nThe name Pyth is massively known in social media esp, bringing awareness of how beneficial being community will be just one of the idea a council could bring \n\n post by Pepito on Jun 18, 2024\n\n Pepito\n\n eileen\n\n Why?\nTo me, this is a great way to grow the community by entrusting more Pythians with it. Less people motivated to do so, the less reach, meh growth.\n\n post by Sloth1890 on Jun 18, 2024\n\n Sloth1890\n\n Debanked\n\n How does this differ from chops white papers for chirons. A lot of what you brought up was outlined back in late feb and evolved into most of what is outlined up above until now the end of IA cycle 1.\nBesides the voting (which chiron do in a sense), does this differ because it is more outside of the discord.\nIts why I commented dejavu in my first post\n\n Load more posts below","tokens":2928,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268120282,"hash":"b439189ca88eac00604ceeeb46c94dc307b09e8c"}
{"url":"https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989/50","domain":"ethresear.ch","title":"Sticking to 8192 signatures per slot post-SSF: how and why - Proof-of-Stake - Ethereum Research","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 7\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 21\n min\n\n Dec 2023\n\n 41 / 41\n\n Jan 2024\n\n Jan 2024\n\n Load more posts above\n\n post by leohio on Dec 28, 2023\n\n leohio\n\n Clarification of Premises\nTo keep the discussion fair and fundamental, it’s important to clearify the difference in circumstances between when we started discussing PoS (Casper FFG) and committee-based finality, and the present.\n\nDue to the convenience of liquidity for restaking/LSD tokens, pools have become incentivized towards a winner-takes-all tendency.\nThe emergence of temporary and inexpensive block space due to Proto-danksharding.\n\nIn these changing circumstances, the trade-offs of the proposed philosophical pivot approaches (1), (2), and (3) in VB’s post are:\n(1) The protocol becomes very simple and efficient. The number of nodes itself decreases, and the pool management methods may become complicated depending on the situation.\n(2) The protocol itself maintains its complexity. The efficiency of block space increases, and censorship resistance is maintained as it is.\n(3) The complexity of the protocol itself increases compared to before. The barrier to entry for staking is reduced.\nOverall, it seems that the main challenges are improving the situation where the 32 ETH upper (not lower) limit is no longer meaningful, and it’s hindering efficiency in block space and bandwidth, and addressing the current concentration in pools.\nClarification and Resolutions of the Problems\nProblem 1: DVT should be made simple, excluding cryptography.\nFundamentally, the ‘go all-in on decentralized staking pools’ approach of philosophical pivot option (1) aims to balance solo staking with large-scale pools. While this may sacrifice liveness, it ensures that safety is always maintained. This characteristic aligns with switchable PoW mining pools. It could be said that this is a direction already proven to work.\nOne question arises regarding the link mentioned: Are technologies like MPC and SSS really necessary for DVT? In my view, what’s essential is the ability to switch pools, and for that, only the following two components are necessary:\n\nThe ability to invalidate a signing key within two blocks.\nThe inability of pools to discern whether a solo staker is online.\n\nAs it’s been discussed a lot in the Ethereum PoS discussion space, the safety of PoW is secure because if someone attempts to control 51%, miners can notice that a fork chain is being mined by a pool and switch pools accordingly. In the current PoS system, since the signing key is delegated to the pool, one might become an attacker against her will and just watch herself being slashed. To change this, the holder of the withdraw key should be able to immediately cancel their signing key if they discover it’s being used for double voting. In implementing this principle, a finality of about 2 slots, rather than SSF, seems preferable.\nOnce this principle is introduced, as long as pools cannot determine whether solo stakers are online, they would be too fearful to attempt double voting. This would allow solo stakers to go offline. Of course, there’s a possibility that pools might speculatively attempt double voting, but as with the current PoS system, attackers would not recover after being slashed, making it not worthwhile.\nProblem 2: Few Solo Stakers\nThe reason for the lack of solo stakers is their lack of confidence in their network environment, even before considering the risk of slashing. Moreover, an increase in solo stakers on AWS is essentially meaningless from the perspective of decentralization. These issues can be resolved by the specific measures mentioned in the above DVT (problem 1) section, which is to create a state where solo stakers are indistinguishable as being online or offline and are delegating to pools.\nAn important point is that solo stakers going offline does not guarantee absolute safety from being slashed; it only significantly reduces the likelihood of being slashed. This characteristic is a major difference from the current solo staking situation, where going offline often leads to a high probability of being slashed.\nProblem 3: Block Size\nOne reason for the large block size in PoS is the presence of a bit array indicating whether each signer has signed. (The signatures themselves can be discarded some time after block approval.)\nThe reasons for this array include:\n\nTo prevent rogue key attacks.\nFor use in slashing.\nFor reward calculations.\n\nFor 1) and 2), like signatures, it should be no problem to discard them after they are sufficiently approved. However, with 3), especially now with Proto-danksharding, it seems possible to balance reward calculation and block space reduction by publicly displaying the Merkle tree for a certain period and then discarding it.\nSpecifical steps:\n\nDivide the bit array, which flags the signers, into several parts and make them leaves of a Merkle Tree.\nPlace all the leaves of the Merkle Tree in a blob.\nInclude only the Merkle Root in the block.\n\nEach person can use a Merkle proof to prove their rewards, and with Recursive ZKP, all can be combined into a single withdrawal transaction. This could potentially reduce the size from 8192 bits to about 256 bits. If any wrong root, the majority of the validators always can ignore the block.\nProblem 4: Censorship Resistance\nIt is discussed in this thread that solo stakers, who produce blocks without going through pools, are key to censorship resistance in the core protocol.\n\nPersonally, I believe this is a drawback of stakers not being able to switch pools. Once they can switch as per the above procedure, it simply becomes a matter of stakers not choosing pools that have implemented censorship programs. Generally, addresses that are censored are likely to pay higher fees to get through, and market principles should ensure higher profits for pool operators who do not censor. Therefore, the approach (1) can maintain a degree of censorship resistance.\nProblem 5: MEV\nThis is a problem that wouldn’t be discussed so lightly if it were easy to solve. However, as long as the Rollup Centric Roadmap continues, it seems appropriate to support Layer 2 solutions that aim for Based Rollup in the protocol, if there is an opportunity to do so.\nTL;DR of my personal opinion\nAdopting Approach 1 (DVT) with switching pools is the easiest way to support solo stakers and to minimize the block size. It actually leaves almost no problem. The pool managers can not use the stake to perform a 51% attack if and only if the withdrawal keys can stop it and the pool can not tell whether or not the withdrawal key holders are online to keep watching the behaviors of the pool. The others are also worth considering, but Approach (1) is what we can call the simplification of PoS.\nThe matter is how to make the switchable staking pool with the shortest finality. I guess it takes 2 slots.\n\n post by OisinKyne on Dec 28, 2023\n\n OisinKyne\n\nGreat! This has been a major concern of mine with the change.\n\nI think its okay for staking to cost a modest amount of consumer hardware and internet. With the Ethereum on ARM effort, you can build a staking machine for under $1k. With verkle trees, I understand we’ll be able to reduce state size by a meaningful amount as well again. If we can keep the delegated staking ecosystem favouring these social principles of decentralisation and being conscious of where and who they allocate their capital to, we can cause the LSPs to compete on this axis of decentralisation, rather than solely on yield or worse rehypothecation.\n\nYes I agree with this take, and would echo what @pradavc and @tbrannt have said below around not going ‘all in’ on DV based staking at the expense of motivated individuals being able to participate independently, to allow for the most permissionless long tail to survive (these still can be as distributed validators but ‘solo/indie DVs’, not ones from a big club with firm rules because you’re collectively managing millions of dollars of other people’s money instead of your own.) At Obol we have designed heavily toward these DV clusters being independent of one another and of different flavours and variants, along with different governance and stewardship. Eschewing homogeneity in favour of heterogeneity on as many axes as possible.\n\nTo reiterate my view from my OP, I’m generally aligned with @kassandra.eth and @pradavc in the below. With the extra specific suggestion of bringing an SSF “duty” in as the non-canonical source of finality at first, and if we’re happy with it post implementation and it needs no tweaking, then we deprecate Casper. All the while, favouring designs that will allow the long tail to participate in the core protocol as much as feasible (consumer hardware and internet, one-to-two digit eth), and pushing the ‘app layer’ of delegated staking to leverage DVT to bring in a wider audience of participating node operators into their products.\n\n post by terence on Dec 28, 2023\n\n terence\n\n In considering either approach one or two, it’s important to contemplate the migration strategy for the current beacon chain. A simple hard fork might no longer be viable due to extensive changes. This could necessitate another merge-like event, such as an in-flight transfer or the creation of a new proof of stake chain. However, the challenge lies in ensuring that these changes do not disrupt the execution side\n\n post by vbuterin on Dec 28, 2023\n\n vbuterin\n\n I actually feel like a series of hard forks might work here!\nMost of SSF can be implemented as (i) reducing the epoch length to 3, (ii) changing the rules for get_active_validator_indices, and a few further tweaks to attestation inclusion rules and incentives.\n\n post by Guest20444 on Dec 28, 2023\n\n Guest20444\n\n mattstam\n\n The operators of those large validators will be much more susceptible to government censorship and regulatory pressure. The homestakers today are the ones that can single handedly uphold Ethereum values no matter what. Ten thousand distributed homestakers spread over the entire globe are unstoppable. It would be a gigantic loss for Ethereum. And a massive hit for Ethereum narrative. It would be just another PoS chain. Also there is plenty of people who would actively fight against that, entire communities/dapps exist around homestaking, its ontop a philosophical issue. This is a landmine that I wouldnt touch.\n\n post by egk10 on Dec 28, 2023\n\n egk10\n\n OisinKyne\n\n I’m a solo validator index number below 10000 and I 'm proud of it. Withdrawing to stake with some liquid stake protocol always hunt my mind and loosing my validator index number is the only thing that stops me doing it.\n\n post by egk10 on Dec 28, 2023\n\n egk10\n\n Btw this should be used as one metric for reputation. Why can’t reputation be a criteria for participating in the committee?\n\n post by leohio on Dec 29, 2023\n\n leohio\n\nIt’s DPoS. The problem of DPoS is already well discussed.\nThat’s why this part should remain somehow.\n\n post by Nero_eth on Dec 31, 2023\n\n Nero_eth\n\n Approach 3 sounds interesting and might be cool to explore more.\nI did some charts showing the impact of the parameters M𝑀 and k𝑘. Largest validator balance set to 2^{18}218, then plugging in the numbers:\nvapproach31000×1000 102 KB\n\nThe higher M𝑀, the closer it gets to approach 2.\nA higher M𝑀 might increase economic security\n\n2/32/3 of the validators would be above M𝑀\n\nApproach 1 sounds a bit scary - we’d basically depend a lot on tradfi. Reputation-gated sounds scary too. I think this could harm censorship resistance (even with having ILs). We saw at the Kraken example how threatening a company led to all of their validators now engaging in censorship. Same applies to 60% of the relay market. Too fragile to go all in (yet). We’d first need ILs and/or encrypted mempools to make sure it doesn’t backfire.\nApproach 2 is very similar to 1 while allowing solo-stakers to engage as the last line of defense. Since solo stakers could easily fork away, this sounds plausible.\nApproach 3 sounds like the biggest improvement from the status quo, despite the increased in-protocol complexity.\n\n post by ittaia on Dec 31, 2023\n\n ittaia\n\n This sounds like a debate on a performance vs security trade-off for a finality gadget.\nA finality gadget that uses 10k signatures gives you good performance (latency) for SSF but you are worried of the reduced security (and accountability).\nNote that using random sampling (say a VRF), or (secret) fair sampler, the security of k consecutive agreements should roughly accumulate stake - this is a latency tradeoff that gives more accountability as the block is buried deeper over time.\nIf that is not enough you can have multiple finality gadgets, a fast one with 10k signatures and a slower one with say 100k (or any other number) of signatures. The 100k one can run every 20 slots and take 20 slots to complete etc. This is somewhat similar to approach 2.\nUnlike approach 2, having two gadgets (or three etc) that only differ in the VRF sampling probability makes their relationship rather egalitarian and simple (same code). Moreover different clients (or different transactions) can wait for confirmations from different gadgets.\nFor example maybe doing a transaction that contains more than 1m eth would prefer to wait for multiple 10k confirmations or for a 100k signature confirmation (or confirmation from all stake…). While a block with total value of 10k eth might be okay with a single 10k consensus confirmation, etc\n\n post by rjramesh on Jan 1, 2024\n\n rjramesh\n\n Lets hope for the best. And we cannot swich pool this was major issue\n\n post by userx6345 on Jan 1, 2024\n\n userx6345\n\n @vbuterin\nWould any of these approaches affect prevrandao in so far as it being accessible? It is already used as a source of entropy for some dapps.\n\n post by alonmuroch on Jan 2, 2024\n\n alonmuroch\n\n This post urged me to write down what participating in ethereum is for me (and maybe others), this might help aim for the right solution\n\nInfluence/ participate - Individuals/ small groups that can participate and secure ethereum is a powerful idea.\nDecentralization - ethereum can’t be “taken down” or manipulated by a single entity\nEconomics - No-one expects to get rich but economics play a major decision driver for many stakers (pooled/ institutions and individuals)\n\nI like approach 1, for obvious reasons, but it needs to consider the above points to make it work.\nDVT can be run by home stakers easily, it does have limitations in term of the number of consensus participants. Theoretically 1,000 operators on a cluster can be made to work (similar to committee based approach and BFT limitations).\nThis means 1,000*4,096 = up to 4M “operators” which seems pretty good.\nThe above requires better key management and secret sharing, potentially the ability to change validation keys to facilitate cluster set changes without compromising security.\nAnother DVT benefit is that the individual validator is much harder to compromise. Considering “very large” operators will exist, just by the nature of how staking works, it’s better if they are part of a DVT cluster than running a few 4K ETH validators on their own\n\n post by sgdheeban on Jan 3, 2024\n\n sgdheeban\n\nThanks @vbuterin & the community for this amazing thread, as always! \nIn my humble opinion, +1 to approach-3 with further decentralization through enshrined staking pools, DVT & light clients over time! This would enhance the decentralization ethos that we all love about Ethereum!\n\n post by norswap on Jan 3, 2024\n\n norswap\n\n I feel like I’m missing something obvious, but how does solution 2 solve the problem?\nIsn’t the light layer equivalent to what we have today (and in fact worse because there are no minimum)?\n\n post by murrlincoln on Jan 9, 2024\n\n murrlincoln\n\n sasicgroup\n\n See Signature Merging for Large-Scale Consensus to answer your first question\n\n post by murrlincoln on Jan 9, 2024\n\n murrlincoln\n\n I’m confused about how the incentive structure would work for the light layer. If there’s no slashing vulnerability, but one does exist for the “heavy” nodes, what would be the incentive for anyone to run heavy? Maybe the staking rewards on the light layer would be lower (or zero), but if they’re non-zero, light staking effectively becomes a risk-free rate on ETH.\n\n post by samlaf on Jan 13, 2024\n\n samlaf\n\n I have a question related to approach 1 (4096 validators) and how it relates to your sharding and DAS proposal post (and danksharding more generally).\nGiven that 4096 fits in a single committee size, would all the nodes be forced to download all the data? Or would a reed-solomon encoding scheme like eigenDA where all nodes download a fraction of the RS encoded chunks only be used?\n\n post by userx6345 on Jan 13, 2024\n\n userx6345\n\n Does @vbuterin usually follow up in these threads? I’ve also got a bunch of other questions but don’t want to be screaming into the void.\n\n post by mratsim on Jan 14, 2024\n\n mratsim\n\nElliptic curve addition is a pretty basic primitive, and those core primitives have been studied for years. So the optimizations are likely to come from aggregation, likely via caching aggregate (an engineering problem).\nThat said there are interesting research in large-scale BLS aggregation, see Web3 Foundation https://web.archive.org/web/20230124085821/https://research.web3.foundation/en/latest/polkadot/LightClientsBridges/index.html\nAnd also RecProofs from Lagrange Labs as aggregation in SNARKS is very very expensive: https://www.lagrange.dev/recproofs\nSo zkBridges team and coprocessor teams that want to prove Casper in ZK (zkCasper) likely have some interesting optimizations to reduce the amount of work to do.\nNow this is something I’m quite interested in and if people want benchmarks on various hardware, I can update the one I did for @asn for Devcon VI (Batch additions by mratsim · Pull Request #207 · mratsim/constantine · GitHub)\nI’ll be happy to build any cryptographic optimizations into Constantine for actual measuremements.\nOn my Ryzen 7840U (low-power, 15W, 8 cores, laptop CPU), individual EC add with various coordinate system:\nimage2059×737 166 KB\nAnd with batch addition, serial and parallelized:\nimage2071×811 299 KB\nI think at 1.3ms, single-threaded, the cryptography is plenty fast, and the delay will be the aggregators’ topology and networking, see Signature Merging for Large-Scale Consensus\n\n Powered by Discourse","tokens":4618,"squid":"ink-research","role":"Deep Scholar","at":1791268124198,"hash":"8be8185bfbcdb89ae17eb9d8293a951c37be06fc"}
{"url":"https://forum.pyth.network/t/pyth-community-council/1582/74","domain":"forum.pyth.network","title":"Pyth Community Council - Ideas Bank - Pyth DAO","text":"You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 16\n\n 12\n\n 10\n\n 9\n\n 7\n\n read \n\n 18\n min\n\n Jun 2024\n\n 74 / 74\n\n Aug 2024\n\n Aug 2024\n\n Load more posts above\n\n post by eileen on Jun 20, 2024\n\n eileen\n\n Frozenmind\n\n I think we already have a good timeframe on 7days type voting/decision. It’s always hard to balance which is why I have never truly believed in DAOs functioning as it has intended to, but Pyth has already established grounds for a DAO and I think intent matters.\n\n post by eileen on Jun 20, 2024\n\n eileen\n\n Frozenmind\n\n DAOs approach in scaling and mutual economic benefits (subDAOs and subOrgs), one of which is Yield Guild Games, capable of functioning as a DAO, generate revenue as well as do subDAOs at scale. This is also the reason why I think council formation and council members needs to be people with experiences in respective areas for growth. Plenty of things can be learnt from people with experiences as long as no ego gets in the way. In my previous org where we’ve transformed from pre-DAO to post-DAO and onchain governance we’ve had multiple approved proposals growing the brand, use cases, some have form entities within eco. The only step I would re-do is rethink everything on accountability and reputation and make it impossibly hard for people to leave once they’ve received funding. It was the most direct and open approach when everything is based on proposals, but it was also the worst decision. I prefer to be in a world where there are true ownership and respective consequences and not appreciation awards.\n\n post by Planck on Jun 20, 2024\n\n Planck\n\n I like the idea that Credence proposed earlier. If we consider his model - 2 Council members for Education, 2 for running Social Media and 2 for Collabs/Partnerships + we take Eileen’s idea that only professionals and/or people with experience in respected fields should be allowed to be elected to the Council and combine all this with the primary idea that basically any active/valid community member can be elected for the position then this will not work.\nUnless we elect such people once and they will remain in the position in the Council for many terms since there is no limit on consecutive terms? If we consider the criteria that only experienced community members should be elected, of course. But it doesn’t sound right, it’s a Community Council - it’s supposed to be done by the community for the community.\nIf you read about the responsibilities again, the duties of the Council are mainly focused on internal growth. Participating in the governance/Forum, boosting community engagement, educating people about PYTH both in Discord and on X is what we have already been doing and focusing on heavily. The difference is that Council members get to communicate with other teams about collabs etc and running bigger events occasionally. I am not using BD here since Pepito mentioned it won’t be expected from the Council members. But realistically, no one is expecting that future Council members - if this proposal ever passes the vote of course - to go ahead and start DMing every single team on all 60 blockchains about benefits for PYTH stakers and run crazy events on a daily basis.\n\n post by Moonover on Jun 20, 2024\n\n Moonover\n\n eileen\n\n It may be overkill for the moment, your comment is on point, but we know we will need it at some point soon. I think its better to experiment the model now and be able to test it out while we are not 1M strong.\nWe are building the future, not waiting for the future to impose itself.\n\n post by Moonover on Jun 20, 2024\n\n Moonover\n\n Planck\n\n Love the specialized chiron idea … it could make for more focused initiatives … worth a try, with or without election …\n\n post by eileen on Jun 21, 2024\n\n eileen\n\n Planck\n\n “Community for the community”, the protocols and dApps are literally within pyth community?!\nWhy wouldn’t we want the best possible talents with more experiences on exponential growth to help the pyth community?\nI’m confused by the reoccurring focus on BD? BD is just one function, to have an event happen it will require a lot more than that.\n\n post by solano on Jun 21, 2024\n\n solano\n\n thanks debanked for the nice idea. im leaning towards:\n\nupgrade/educate the chirons for doing some of the easier tasks mentioned. for example creating subdaos like play2earn and learn2earn together. even upgrade them to official community council\n\nhire more well paid professionals like pepito or chop for the more professional tasks like opportunities and growth and content.\n\nthe idea of 3 councils (price, pythian, community) which are doing all the votes for stakers and holders seems cool.\n\n post by Pepito on Jun 21, 2024\n\n Pepito\n\nIn an ideal world, I agree but by the nature of a council that gets elected. But it’s not feasible in my opinion which goes also into this:\n\nIt will be up to the Pythians to vote for the members they want to see on the council. Anyone can nominate himself (albeit the staking requirement) and it will be up to the community to decide.\nI have the belief that the community will elect the right/best members and if they happen to be highly skilled in these fields, it’s great and most likely the reason why the community chooses them.\n\n post by Planck on Jun 21, 2024\n\n Planck\n\nYes, that is exactly my point. I don’t think it is realistic to set up the standards this high for the community members.\n\n post by Frozenmind on Jun 21, 2024\n\n Frozenmind\n\n I had more time available tonight so I figured I could “attack” the Questions or Uncertainties up front \n\nI believe that the Responsibilities of the Council as listed in the initial proposal encompass a very broad scope of expectations for its members. I would categorize them into three components: 1) Community Coordination and collaboration with the Pyth Data Association, 2) Brand Awareness, Partnerships, and Collaborations, and 3) Governance Participation and Education.\nConsidering that most of the “powers” related to the above are currently controlled by Contributors/PYTH Team members, I think that externalizing some decision-making and management regarding the community is an organic way to “represent the diverse interests” of the community. Additionally, expanding the community task force should increase opportunities for community voices to be heard and considered, while easing the handling of the ongoing daily demands.\n\nTo me, the initial suggestions are sufficient and coherent with the mandate. I believe that minimal previous involvement in any sphere of the Pyth Community should be required. Such involvement should be verifiable through X or Discord engagement. If not, a Candidate should be co-opted by a recognized member of the Pyth Community. A minimum stake of 1K $PYTH might be slightly low given the current price, but we also aim for the Council structure to stand the test of time and stay reasonable for any competent community member to be eligible for election.\n\nI think that stability is crucial to the success of any project, so a term length of 6 months seems appropriate. The election process for a DAO can be extensive and create a governance “void” during its duration, making overly frequent elections counterproductive. Therefore, I suggest no more than 3 elections per year to ensure minimal stability.\nI agree with the current proposal of “No limit on consecutive terms,” considering the Council’s pivotal role in day-to-day community operations.\n\nI believe that a mechanism akin to a “vote of no confidence” could be included in the Council’s constitution. Should a significant majority (minimum 66%) of Council members believe that a councilor is underperforming and that a replacement is necessary, or in the event that a councilor requests to be discharged from their responsibilities, a formal vote should be initiated. In a 6-member Council, 4 out of 5 votes would be required to remove an elected member.\nThis vote would lead to the official removal of the member on the 1st day of the following month, allowing for a partial election to replace the removed councilor during the remainder of that month.\nIf the period between the 1st day of the following month and the formal removal of the councilor is less than 7 calendar days, or if the next scheduled election is within 1 month, the seat of the removed councilor would remain vacant until the election of a replacement, which implies a minimum 7-day election process.\n\nIn my opinion, we need more metrics on the current Community Budget to determine what would be reasonable. Current Community initiatives already have their own allocated budgets, so discussions are needed regarding which responsibilities will be taken over by the Council versus the Contributors\n\nIn my rough estimation, we should consider an hourly rate of between $40 and $50 USD expected from each councilor. A portion of the stipend should be paid in liquid $PYTH, with another portion vesting. It’s important to ensure that our vision of what we expect from the Council aligns with the compensation we offer. In my opinion, $500 USD in PYTH per month might be on the lower end. Additionally, we should consider whether councilors would be eligible for other forms of rewards. For instance, if we expect councilors not to participate in rewarding community initiatives like the Impact Awards, this should be factored into their stipend.\n\n post by Planck on Jun 24, 2024\n\n Planck\n\n I am also curious\n\nWhy is the idea of having 6 Council members not realistic? Why can’t it be carried out?\nHow many Council members is the ideal number then? And why?\n\n post by ed_pyth on Jun 24, 2024\n\n ed_pyth\n\n Credence\n\n Agreed on the idea of keeping council members count to an odd number for tie-breakers.\nRe: having council members specialize in certain areas, I think this boils down to how they present themselves when campaigning. It would be hard to enforce this otherwise.\nThe vouching system is highly interesting too, but I also think it boils down to public relations between the candidate and their campaigning to the public, otherwise the Discord might get gamed…\n\n post by Frozenmind on Jun 24, 2024\n\n Frozenmind\n\n Planck\n\n I think what Pepito meant is that a perfect 2/2/2 council may actually happen as a result of not-centralized election.\nNot saying that 6 members is not right or that in the best scenario 2/2/2 would happen.\n@Pepito Feel free to confirm or not \n\n post by Pepito on Jun 25, 2024\n\n Pepito\n\n That’s right @Planck ! I do not have a strong opinion on the number (be it 5-6-7). But this range feels like it is the right one to keep it pretty focused and also add some fire power for the community to grow.\n\n post by Pepito on Jun 25, 2024\n\n Pepito\n\n What a thorough “attack” on the uncertainties Thanks for this Frozen\nhere are some thoughts from me:\n\nThis looks like the best way to deal with this and also quite efficient.\n\nHowever, another election would be time-consuming and waste precious time. I would be in favor of giving the power to the council to ‘pick’ the new one after a ‘nomination’ period (7 days) to go quickly. Could even be from the current group of Chirons.\n\nAs shared in @Debanked initial proposal, the Council would be in charge of running the Impact Awards program, Chirons, and other activities.\nFor some context, the Pyth contributors have allocated 30K $PYTH per cycle. These tokens are not required to be used but the goal is to do so.\nA 6-month term would mean running 4 cycles (40 days) and giving a dead period of about 5 days between them, amounting to 120K $PYTH (as things stand now).\nI think 150K-180K $PYTH would be a good starting point for this first iteration. We are still early, finishing the 1st official Impact Award Cycle.\n\nIndeed, some precisions to add to this section. I agree that 500 $PYTH is on the lower end of the spectrum to me unless IAs are still distributed like they are today.\nI lean towards IAs still being given to council members as they would be a good representation of the work they do daily. If one is crushing it, he’ll get xxx IAs as a reward for his work vs. one who contributes less will not.\n\n post by Frozenmind on Jun 29, 2024\n\n Frozenmind\n\nI agree that considering that if the Council is granted with a power of removal with a significant majority that a selection from a pool of candidates after a “nomination” period would be a much more efficient and agile.\n\nI think that a dedicated budget for Chiron Program should also be included in the Council initial iteration. I would assume between 80K -100K $PYTH could cover the potential need of this “leg” for a 6-month mandate.\nThat could bring the total to 250K-280K $PYTH for the six first month mandate considering that the DAO would be open to additional funding if needed and justified after discussion between the Council and the DAO.\n\nMy understanding of @Debanked is that it was $500 USD/month paid in $PYTH not 500 $PYTH but I think that what you mean as well. Again, this should be aligned with how much time/hours we are looking the Council to invest per month and how we value this time.\n\n post by Pepito on Jul 4, 2024\n\n Pepito\n\nWhat do you envision for this budget? How would it be used?\n\nYes, so my understanding and initial thinking is that denominating in dollars to be calculated in $PYTH is the best but also not easy. When do we say “$PYTH = x$ thus its a certain $PYTH amount”?\nAs for the ‘time invested’ it’s impossible to really determine IMO. The hope is that members invest the time that is worth their while during these 6 months with the stipend. This would be the base layer and if we decide to also keep the IAs available, the ‘extra’ work would be valued with that.\n\n post by Frozenmind on Jul 4, 2024\n\n Frozenmind\n\nThe idea is that if the Chiron Program is to be delegated to the Council it would make sense that the Chiron Allocation be also managed by the Council. With this budget the recruitment of new Chiron(s) and or adjustment to the Chiron Allocation would tied to the Council as well. Not an issue IMO if this budget is kept under the Team responsibility but it does create a gap in terms of managing/administering without actually being in control of the budget.\n\nI think we could decide of a specific moment in terms of point where the “exchange rate” is to be decided. For sake of simplicity I would propose using the $PYTH Price Feed as at 00:00 UTC on the last Friday of each month.\nUsing this exchange rate, which would be variable each month, the amount of $PYTH payable for the previous month would be easy to determine and transparent.\n\nUnderstood. I still think that the stipend could be increased a little more considering the IA distribution can be subjective and quite difficult especially for people mostly involved outside of the Discord (X, Telegram, Pyth Forum, etc.). Just my 2 cents \n\n 20 days later\n\n post by jvk on Jul 25, 2024\n\n jvk\n\n I propose that the token be split 1:10,000\nFor example, anyone staking or holding 1 pyth v1 token would receive 10,000 pyth v2 tokens.\nThis would allow the token to attract “meme” traders, which adds additional utility to the token. It also helps to essentially void outstanding uninvolved tokens that are dormant. The unit bias economic phenomenon should be leveraged on behalf of the protocol.\n\n 17 days later\n\n post by Derrp on Aug 11, 2024\n\n Derrp\n\n Hey mate,\nYour comment is not applicable to this thread. Feel free to create your own topic/thread once you have levelled up sufficiently \n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2 Budget Request\n\n Community Council\n\n 4\n\n 331\n\n Apr 14\n\n Guide for the Community Council Election #1\n\n Community Council\n\n 6\n\n 412\n\n Mar 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d","tokens":3997,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268130582,"hash":"2f0efa3cccb4230c1b8b000883109b22a5cfa998"}
{"url":"https://docs.optimism.io/app-developers/guides/configuring-actions","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Actions SDK lets you choose which assets, markets, chains, protocols, and providers you want to support in your application via configuration file.\n1Install Actions SDKFollow the\nquickstart guide to\nadd Actions SDK as a dependency in your app.2Integrate an embedded walletFollow the connecting a wallet to Actions\nSDK guide, choose and\ninstall a Wallet Provider.3Create a config fileactions.ts - An accessible file that holds all of your configuration preference.4Configure a Wallet ProviderLet Actions SDK know which Wallet Provider you’ve chosen: Frontend BackendSelect a wallet provider: Privy Turnkey Dynamicactions.tsconst walletConfig = {\n hostedWalletConfig: {\n provider: {\n type: \"privy\" as const,\n },\n },\n smartWalletConfig: {\n provider: {\n type: \"default\" as const,\n attributionSuffix: \"actions\",\n },\n },\n};\nactions.tsconst walletConfig = {\n hostedWalletConfig: {\n provider: {\n type: \"turnkey\" as const,\n },\n },\n smartWalletConfig: {\n provider: {\n type: \"default\" as const,\n attributionSuffix: \"actions\",\n },\n },\n};\nactions.tsconst walletConfig = {\n hostedWalletConfig: {\n provider: {\n type: \"dynamic\" as const,\n },\n },\n smartWalletConfig: {\n provider: {\n type: \"default\" as const,\n attributionSuffix: \"actions\",\n },\n },\n};\nSelect a wallet provider: Privy Turnkeyactions.tsimport { PrivyClient } from '@privy-io/node'\n\nconst privyClient = new PrivyClient(\n process.env.PRIVY_APP_ID,\n process.env.PRIVY_APP_SECRET,\n)\n\nconst walletConfig = {\n hostedWalletConfig: {\n provider: {\n type: \"privy\" as const,\n config: {\n privyClient,\n },\n },\n },\n smartWalletConfig: {\n provider: {\n type: \"default\" as const,\n attributionSuffix: \"actions\",\n },\n },\n};\nactions.tsimport { Turnkey } from '@turnkey/sdk-server'\n\nconst turnkeyClient = new Turnkey({\n apiBaseUrl: 'https://api.turnkey.com',\n apiPublicKey: process.env.TURNKEY_API_KEY,\n apiPrivateKey: process.env.TURNKEY_API_SECRET,\n defaultOrganizationId: process.env.TURNKEY_ORGANIZATION_ID,\n})\n\nconst walletConfig = {\n hostedWalletConfig: {\n provider: {\n type: \"turnkey\" as const,\n config: {\n client: turnkeyClient.apiClient(),\n },\n },\n },\n smartWalletConfig: {\n provider: {\n type: \"default\" as const,\n attributionSuffix: \"actions\",\n },\n },\n};\n5Configure supported assetsConfigure which assets you want to support across all lend providers:actions.ts// Additional config from previous steps...\n\n// Import popular assets\nimport { USDC } from '@eth-optimism/actions-sdk/assets'\nimport type { Asset, AssetsConfig } from \"@eth-optimism/actions-sdk\";\n\n// Or define custom assets\nexport const CustomToken: Asset = {\n address: {\n [mainnet.id]: '0x123...',\n [unichain.id]: '0x456...',\n [baseSepolia.id]: '0x789...',\n },\n metadata: {\n decimals: 6,\n name: 'Custom Token',\n symbol: 'CUSTOM',\n },\n type: 'erc20',\n}\n\n// Configure allowed/blocked assets\nconst assetsConfig: AssetsConfig = {\n allow: [USDC, CustomToken],\n block: [], // Optional\n}\n6Configure MarketsDefine which markets you want to support or block within your app:actions.ts// Additional config from previous steps...\n\nexport const GauntletUSDC: LendMarketConfig = {\n address: '0xabc...',\n chainId: unichain.id,\n name: 'Gauntlet USDC',\n asset: USDC,\n lendProvider: 'morpho',\n}\n7Configure Lend ProvidersConfigure which lend protocols you want to support. You can enable one or multiple providers:actions.ts// Additional config from previous steps...\n\nimport type { LendConfig } from \"@eth-optimism/actions-sdk\";\n\nconst lendConfig: LendConfig = {\n morpho: {\n marketAllowlist: [GauntletUSDC],\n marketBlocklist: [], // Optional\n },\n aave: {\n marketAllowlist: [AaveWETH],\n marketBlocklist: [], // Optional\n },\n};\n8Configure supported chainsConfigure supported chains:actions.ts// Additional config from previous steps...\n\nimport { optimism, base } from \"viem/chains\";\n\n// Define any EVM chain\nconst OPTIMISM = {\n chainId: optimism.id,\n rpcUrls: env.OPTIMISM_RPC_URL,\n bundler: {\n // Bundle and sponsor txs with a gas paymaster\n type: \"simple\" as const,\n url: env.OPTIMISM_BUNDLER_URL,\n },\n};\n\nconst BASE = {\n chainId: base.id,\n rpcUrls: env.BASE_RPC_URL,\n bundler: {\n // Bundle and sponsor txs with a gas paymaster\n type: \"simple\" as const,\n url: env.BASE_BUNDLER_URL,\n },\n};\n\nconst chains = [OPTIMISM, BASE];\n9Initialize ActionsFinally bring it all together and initialize Actions:actions.ts// Additional config from previous steps...\n\nexport const actions = createActions({\n wallet: walletConfig,\n assets: assetsConfig,\n lend: lendConfig,\n chains,\n});\n10Take ActionOnce you’ve initialized your actions instance, import it anywhere you need to take action:import { actions } from './actions';\n\n// Use actions anywhere in your app\nconst market = await actions.lend.getMarket({ ... });\nconst wallet = await actions.wallet.createSmartWallet({ ... });\nconst receipt = await wallet.lend.openPosition({ ... });\n\n​Next Steps\nFor detailed API documentation and type definitions, see the Actions SDK Reference.Was this page helpful?","tokens":1230,"squid":"ink-governance","role":"Council Listener","at":1791268138320,"hash":"2e749264f0d096fe1a6f0e2b2b932b271037a75d"}
{"url":"https://forum.openzeppelin.com/t/create2-failed-on-deploy-when-using-create2-library/3231","domain":"forum.openzeppelin.com","title":"Create2: Failed on deploy when using Create2 library - Support / Contracts - OpenZeppelin Forum","text":"Create2: Failed on deploy when using Create2 library \n\n SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2020\n\n 1 / 3\n\n Jul 2020\n\n Jul 2020\n\n post by alexander on Jun 30, 2020\n\n alexander\n\n I am trying to use the deploy function in the Create2.sol library contract. I am getting the Create2: Failed on deploy revert.\n Environment\n\nUsing buidler framework. v1.3.2\nUsing OZ contracts v3.0.1\nUsing buidler/truffle5 plugin v1.3.1\nDetails\n\nI’m not entirely sure why its failing to deploy, the stack traces show it failing on L35 of the Create2.sol file.\n\n Code to reproduce\n\nThe code for the test:\ncontract(\"Registry and Factory Contract\", (accounts) => {\n // ACCOUNTS\n const Alice = accounts[0];\n\n let factory, tokenU, tokenS, base, quote, expiry;\n\n before(async () => {\n factory = await Factory.new(Alice);\n tokenU = await newERC20(\"TEST DAI\", \"DAI\", MILLION_ETHER);\n tokenS = await newWeth();\n base = toWei(\"200\");\n quote = toWei(\"1\");\n expiry = \"1690868800\"; // May 30, 2020, 8PM UTC\n });\n\n describe(\"Registry\", () => {\n it(\"should deploy the contract\", async () => {\n await factory.deploy(\n tokenU.address,\n tokenS.address,\n base,\n quote,\n expiry\n );\n });\n });\n});\n\nThe code for the factory contract:\nimport { Option, SafeMath } from \"../../primitives/Option.sol\";\nimport \"../../interfaces/IFactory.sol\";\nimport \"@openzeppelin/contracts/access/Ownable.sol\";\nimport { Create2 } from \"@openzeppelin/contracts/utils/Create2.sol\";\n\ncontract Factory is IFactory, Ownable {\n using SafeMath for uint;\n\n constructor(address registry) public { transferOwnership(registry); }\n\n function deploy(address tokenU, address tokenS, uint base, uint quote, uint expiry)\n external\n override\n onlyOwner\n returns (address option)\n {\n bytes memory bytecode = type(Option).creationCode;\n bytes32 salt = keccak256(abi.encodePacked(tokenU, tokenS, base, quote, expiry));\n option = Create2.deploy(uint(0), salt, bytecode);\n }\n}\n\n 2\n\n post by abcoathup on Jun 30, 2020\n\n 11 days later\n\n post by abcoathup on Jul 12, 2020\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract\n\n Guides and Tutorials\n\n 5\n\n 7.6k\n\n Mar 2025\n\n When does `create2(…)` return the zero address?\n\n Smart Contracts\n\n 1\n\n 2.0k\n\n Jan 2022\n\n How can I deploy CREATE2 smart contract with private key?\n\n Smart Contracts\n\n 0\n\n 371\n\n Apr 2022\n\n Discussion on OpenZeppelin Contracts 2.5 Create2.sol\n\n General\n\n 4\n\n 1.9k\n\n Mar 2020\n\n How to use a CREATE2 deployer\n\n General\n\n 7\n\n 2.1k\n\n Jun 2021","tokens":654,"squid":"ink-security_audits","role":"Sentinel","at":1791268148123,"hash":"ec36679e0d90b763bbdd3d04740fafd62f88a6ec"}
{"url":"https://io.net/terms","domain":"io.net","title":"io.net | Decentralized GPU Cloud","text":"Terms Of UseEffective Date: September 21, 2026\nThis Terms of Service Agreement (the “Agreement”) is made and entered into by and between you and IO.NET Inc., a Delaware corporation (the “Company”, “us”, “we”, or “our”). This Agreement sets forth the terms and conditions that govern your use of and access to the products, materials, and services provided through or on the io.net website (the “Website”), including any Company-provided computer or mobile software or application (collectively, the “Services”).\n 1. Acceptance of this Agreement.\n 1.1 Acceptance Through Using or Accessing the Services.\nPlease review the following terms carefully. By accessing or using the Services (or by clicking on “accept” or “agree” to this Agreement when prompted), you agree to be bound by the terms and conditions of this Agreement on behalf of yourself or the entity or organization that you represent. If you do not agree to the terms and conditions of this Agreement, you may not use or access the Services and must exit the Website immediately.\n 1.2 Eligibility Requirements to Use or Access the Services.\nTo use the Website or any other Services, you must be (i) at least 18 years old, and (ii) not be on a sanctions or restricted or prohibited list, or physically located in a country on such a list, of the United States of America, the European Union or any of its member states, or the United Kingdom including but not limited to the following countries or territories: Afghanistan, Belarus, Central African Republic, Crimea, Cuba, Eritrea, Iran, Iraq, Lebanon, Libya, Mainland China, Myanmar, North Korea,, Somalia, Syria, Sudan, the Donetsk and Luhansk regions of Ukraine.. By accessing or using the Services, you represent and warrant that you meet all the foregoing eligibility requirements. You also represent and warrant that you have the right, authority, and capacity to enter into this Agreement on your behalf or the entity or organization that you represent. If you do not meet all these requirements, you may not use or access the Services.\n 1.3 Changes to this Agreement.\nThe Company reserves the right to change this Agreement from time to time in its sole discretion without notice to you. The latest version of the Agreement will be posted on the Website and should be reviewed prior to accessing or using the Services. All changes will be effective immediately when posted on the Website and will apply to your use of and access to the Services from that point onward.\nYour continued use of or access to the Services following any changes to this Agreement shall constitute your acknowledgment of such changes and agreement to be bound by the terms and conditions of such changes. You should check this page frequently so that you are aware of any changes since they are binding on you.\n 2. Access to the Services.\nThe Services may change from time to time as the Company evolve s, refines, or adds more features to the Services. The Company reserves the right to modify, withdraw, or discontinue the Services, in whole or in part, at any time without notice to you. You agree that the Company shall have no liability to you or any third party for any losses or damages caused by the Services not being available, in whole or in part, at any time or for any period.\n 3. Policy for Using the Services.\n 3.1 Prohibited Uses.\nYou may use the Services for lawful purposes only and in accordance with this Agreement and with the Company-provided documentation accompanying the Services. You agree not to use the Services in any way that could damage the Services or general business of the Company.\n 3.2 Prohibited Activities.\nYou further agree not to engage in any of the following prohibited activities in connection with using the Services:\n (a) No Violation of Laws or Obligations.\nViolate any applicable laws or regulations (including intellectual property laws and right of privacy or publicity laws) or any contractual obligations.\n (b) No Unsolicited Communications.\nSend any unsolicited or unauthorized advertising, promotional materials, spam, junk mail, chain letters, or any other form of unsolicited communications, whether commercial or otherwise.\n (c) No Impersonation.\nImpersonate others or otherwise misrepresent your affiliation with a person or entity in an attempt to mislead, confuse, or deceive others.\n (d) No Harming of Minors.\nExploit or harm minors in any way, including exposing inappropriate content or obtaining personally identifiable information.\n (e) Compliance with Content Standards.\nUpload, display, distribute, or transmit any material that does not comply with the Content Standards set out below in this Agreement.\n (f) No Interference with Others’ Enjoyment.\nHarass or interfere with anyone’s use or enjoyment of the Services, or expose the Company or other users to liability or other harm.\n (g) No Interference or Disabling of the Services.\nUse any device, software, or routine that interferes with the proper working of the Services, or take any action that may interfere with, disrupt, disable, impair, or create an undue burden on the infrastructure of the Services, including servers or networks connected to the Website.\n (h) No Monitoring or Copying of Material.\nCopy, monitor, distribute, or disclose any part of the Services by automated or manual processes, devices, or means. This includes, without limitation, using automatic devices such as robots, spiders, offline readers, crawlers, or scrapers to strip, scrape, or mine data from the Website, provided, however, that the Company conditionally grants to the operators of public search engines revocable permission to use spiders to copy materials from the Website for the sole purpose of and solely to the extent necessary for creating publicly available searchable indices of the materials, but not caches or archives of such materials.\n (i) No Viruses, Worms, or Other Damaging Software.\nUpload, transmit, or distribute to or through the Services any viruses, Trojan horses, worms, logic bombs, or other materials intended to damage or alter the property of others, including attacking the Services via a denial-of-service or distributed denial-of-service attack.\n (j) No Unauthorized Access or Violation of Security.\nViolate the security of the Services through (i) any attempt to gain unauthorized access to the Services or to other systems or networks connected to the Services, (ii) the breach or circumvention of encryption or other security codes or tools, or (iii) data mining or interference to any server, computer, database, host, user, or network connected to the Services.\n (k) No Reverse Engineering.\nReverse engineer, decompile, or otherwise attempt to obtain the source code or underlying information of or relating to the Services.\n (l) No Collecting User Data.\nCollect, harvest, or assemble any data or information regarding any other user without their consent. This includes, without limitation, their emails, usernames, or passwords.\n (m) No Other Interference.\nOtherwise attempt to interfere with the proper working of the Services.\n (n) Attempt or Assist Others in Attempting.\nAttempt any of the foregoing or assist, permit, or encourage others to do or attempt any of the foregoing.\n (o) Money Laundering.\nThe Services shall not be used in connection with money laundering, financing illicit activities, Sanctions evasion or any other unlawful purposes.\n (p) Circumvention.\nExpect as directly enabled as a feature of the Services, you may not use, employ or operate bots or other forms of automation, or any techniques to modify your internet protocol address (including use of a Virtual Private Network (VPN)) or otherwise circumvent the above restrictions, when using the Services. You may not use a modified device to use the Services if the modification is contrary to the manufacturer’s software or hardware guidelines, including disabling hardware or software controls—sometimes referred to as “jailbreaking.”\n (q) Scraping.\nYou may not “screen scrape” or otherwise use any automated means to access the Services or collect any information from the Services, except to index the public-facing portions of the Services for a search engine.\n (r) Anti-aggregation.\nIf the Company has a reasonable suspicion that any user's devices could be jeopardizing the network integrity as a decentralized network, we reserve the right, without prior notice and at the Company’s sole discretion, to terminate their accounts and slash in part or in whole their accrued epoch rewards on all related accounts.\n 3.3 Geographic Restrictions.\nYou shall not access or use the Software if you are or become included on a Sanctions or restricted or prohibited list of the United States of America, the European Union or any of its member states, or the United Kingdom, or physically located in a country on such a list, including but not limited to the following countries or territories: Afghanistan, Belarus, Central African Republic, Crimea, Cuba, Eritrea, Iran, Iraq, Lebanon, Libya, Mainland China, Myanmar, North Korea, Somalia, Syria, Sudan, the Donetsk and Luhansk regions of Ukraine. You accept full responsibility for compliance with all local laws. The Company makes no representations that the Services or any of its content are accessible or appropriate in any particular jurisdiction.\n 3.4 Sanctions.\nFor purposes of this Agreement, “Sanctions” means economic or financial sanctions or trade embargoes imposed, administered or enforced from time to time by the U.S. government, including those administered by the OFAC or the U.S. Department of State, the United Nations Security Council, the European Union or His Majesty’s Treasury of the United Kingdom, or authorities in any country in which the Company does business.\n“Sanctioned Person” means (a) any person or entity listed at such time in any Sanctions-related list of designated persons maintained by OFAC or the U.S. Department of State or by the United Nations Security Council, the European Union, His Majesty’s Treasury of the United Kingdom, or similar lists maintained by governments in any jurisdiction in which the Company does business, (b) any person or entity operating, organized or resident in a location that is subject to comprehensive Sanctions administered by OFAC at such time (including Cuba, Iran, North Korea, Syria, and the Crimea, Donetsk, and Luhansk regions of Ukraine) ,or (c) any entity 50% or more owned by any such person or entity described in the foregoing clauses (a) or (b) at such time.\n 3.5 Consequences of Misuse.\nIf the Company has a reasonable suspicion that you are creating a risk or possible legal liabilities or not acting in accordance with the terms of this Agreement, the Company may limit, suspend, or terminate your access to the Services, or portions thereof, and/or take technical and legal steps to prevent you from accessing or using the Services.\n 3.6 Patriot Act\nThe Company and/or its partners may have legal obligations under the USA Patriot Act or other applicable laws designed to detect money laundering or other crimes, including obligations to report suspicious activity. The Company reserves the right to deny any individual the right to access products that are otherwise available on the Services for any reason, including, without limitation, as a result of information obtained in connection with background checks and whether or not such information is accurate, truthful or complete.\n 4. Paid Services\n 4.1 Billing Policies.\nCertain aspects of the Service may be provided for a fee or other charge. If you elect to use paid aspects of the Service, you agree to our displayed prices on the Site as we may update them from time to time. We may add new services for additional fees and charges, add or amend fees and charges for existing services, at any time in its sole discretion. We use Stripe and SpherePay as our third-party service provider for payment services. By using our Service, you agree to be bound by Stripe’s Services Agreement available at https://stripe.com/us/legal and Sphere’s Terms and Conditions available at https://spherepay.co/legal/terms.\n 4.2 Cluster Billing.\nCluster products deployed on or after the Effective Date of this Agreement are billed on a “Pay-As-You-Go” or “PAYG” basis, unless otherwise specified for a particular product at the time of purchase. If you deploy a PAYG cluster, you will be charged in advance, before the corresponding time is used, as follows: (a) at deployment, we charge one (1) hour of cluster time upfront (the “Initial Charge”); and (b) after the Initial Charge, we continue to bill you in advance, in consecutive five (5)-minute increments (each, a “Block”), for as long as the cluster remains running, including any period during which the cluster is idle or not actively in use. Each charge (the Initial Charge and each Block) is billed at the rate in effect at the time that charge is processed, as described in Section 4.3 (Dynamic Pricing), and is deducted automatically from your available balance, including any IO Credits.\nLegacy Duration Clusters. Clusters deployed before the Effective Date of this Agreement under the Company’s prior fixed-duration billing model (“Duration Clusters”) continue to be governed by the billing terms that applied at the time of their deployment, including a non-refundable one-hour minimum, until that Duration Cluster is stopped or terminated. As of the Effective Date, the Company is not offering new Duration Clusters.\n 4.3 Dynamic Pricing.\nPricing for cluster resources is not fixed and may change over time based on the pricing charged by our underlying compute suppliers and other market conditions. When you create a PAYG cluster, we display a notice that the price may change while your cluster is running if the price charged by the underlying supplier changes. The Initial Charge and each Block are billed at the rate in effect at the moment that charge is processed, which may be higher or lower than the rate displayed to you at deployment or charged at any prior Block for the same cluster. If the price applicable to your running cluster changes, we will also send you an email notification of the change. We are not obligated to delay, cap, waive, or reverse any charge made at the then-current rate.\n 4.4 No Refunds.\nYou may stop a cluster or cancel your account at any time; however, all charges are final and non-refundable. Without limiting the foregoing, if you stop a PAYG cluster, or your PAYG cluster is suspended or terminated for any reason (including under Section 4.5 or Section 4.6, or under Section 14), any unused portion of the Initial Charge and any unused portion of a Block that has already been charged are forfeited in full and will not be refunded, credited, or applied toward another cluster or IO Credit balance. In the event that we suspend or terminate your account or this Agreement, you understand and agree that you shall receive no refund for any unused time, IO Credits, license or subscription fees for any portion of the Service, any content or data associated with your account, or for anything else.\n 4.5 Insufficient Balance; Failed Payments.\nYou are responsible for maintaining a sufficient available balance (including IO Credits) or valid payment method to cover ongoing charges for any cluster you are running. If, at the time the Initial Charge or a Block is due, your available balance is insufficient to cover that charge, or a charge to your payment method fails for any reason (including a declined card), your cluster will be terminated automatically. We do not guarantee any grace period before termination. As a courtesy, we send email notifications estimating when your balance is projected to run out based on your current usage rate. The number and timing of these notifications (currently targeted at approximately three (3) days, five (5) hours, and ten (10) minutes before projected depletion) may be changed by us from time to time, in our sole discretion, without requiring an amendment to this Agreement. These notifications are estimates only, are not guaranteed to be delivered, accurate, or timely, and do not obligate us to delay, prevent, or provide notice before termination.\n 4.6 Auto-Termination; Data Loss.\nClusters may stop or terminate automatically and without further notice when your available balance is exhausted, a scheduled charge fails under Section 4.5, or as otherwise permitted under Section 14 (Termination). Termination of a cluster, whether automatic or otherwise, may result in the permanent loss of data, configurations, in-memory state, or other content associated with that cluster that has not been separately saved, exported, or backed up by you outside the cluster before termination. You are solely responsible for monitoring your balance and usage and for backing up any data or work product you wish to retain before your balance is depleted or your cluster is otherwise stopped or terminated. To the fullest extent permitted by applicable law, the Company is not liable for any loss of data, business interruption, or related damages arising from the stopping or termination of a cluster, whether automatic or otherwise, and the limitations of liability in Section 16 apply.\n 4.7 Taxes.\nYou are responsible for paying any applicable taxes, if any, relating to any such purchases, transactions or other monetary transaction interactions with the Services.\n 4.8 IO Credits.\n (a) Purchase and Value.\nIO Credits may be purchased through Stripe, SpherePay, or any other payment method we make available. Unless otherwise specified, one (1) IO Credit equals USD $1. IO Credits are solely a prepaid, account-specific measure of your right to consume Services and are not a separate currency, security, deposit, investment, or stored-value instrument independent of your account.\n (b) Usage Priority.\nIO Credits are consumed in the order they were purchased, regardless of payment method. If IO Credits are acquired through multiple payment methods, they will be used on a first-in, first-out basis.\n (c) Withdrawal for Credits.\nWithdrawals are only available for unused IO Credits and will be issued according to the payment method used for the corresponding IO Credits, in accordance with the first-in, first-out usage sequence.\n (d) Non-Transferability.\nIO Credits are personal to your account and may not be sold, assigned, or transferred to any other account.\n (e) Expiration.\nIO Credits expire twelve (12) months from the date of purchase. Upon expiration, unused IO Credits have no value and will not be withdraw-able or reinstated.\n (f) No Cash Redemption.\nIO Credits have no cash value and may not be exchanged for cash except where required by law.\n 5. Third-Party Service Providers\nTo provide the Services, the Company may use the following service providers. You authorize the Company to share your information with these and other service providers as necessary for the provision of the Services. You authorize these service providers and their affiliates and service providers to use, disclose and retain your personal data in connection with these terms and the provision of the Services and as required by law. As a condition of the use of the Services, you agree to each of the agreements listed after each service provider.\nGoogle (Terms, Privacy Policy)\nCloudflare (Terms, Privacy Policy)\nVercel (Terms, Privacy Policy)\nAWS (Terms, Privacy Policy)\nAuth0 (Terms, Privacy Policy)\nAmplitude (Terms, Privacy Policy)\nStripe (Terms, Privacy Policy)\nSlack (Terms, Privacy Policy)\nDiscord (Terms, Privacy Policy)\nX (Terms, Privacy Policy)\nSentry (Terms, Privacy Policy)\nRetool (Terms, Privacy Policy)\nBetterstack (Terms, Privacy Policy)\nLinear (Terms, Privacy Policy)\nFreshdesk (Terms, Privacy Policy)\n 6. Epoch Rewards\nAs part of using the Service, you may be eligible to receive $IO Tokens from the Internet of GPUs Foundation (https://iog.net/) (“Epoch Rewards”).\nUsers are solely responsible for providing and maintaining a valid and accurate wallet address for the receipt of Epoch Rewards. By providing a wallet address, users represent and warrant that the wallet is not associated with any sanctioned individual, entity, jurisdiction, or prohibited activity under applicable laws or regulations. The Company shall not be responsible for any loss of funds resulting from incorrect wallet information, unsupported wallets, compromised wallets, or wallet addresses submitted in error. Transactions executed to the wallet address provided by the user shall be deemed final and non-reversible.\nThe Company (in conjunction with the Internet of GPUs Foundation) reserves the right to slash users’ Epoch Rewards if we have reasonable ground that their devices are either:\nOutright fraudulent, spoofing, using virtualization technology, VPNs, or in any manner, intentionally or inadvertently, that dishonestly misrepresenting its technical specifications; or\nNot performing to the standard to be useful for the platform, including but not limited to failing the proof-of-work test, low uptime, failing to pass various technical tests administered by the Company or any other authorized party, or through any permissionless validator protocol.\nThe Company reserves the right, at its sole discretion and without prior notice, to terminate associated accounts, off-board involved devices, and slash in part or in whole their accrued Epoch Rewards on all related accounts.\nEpoch Rewards may be distributed directly to the wallet address designated by the user in accordance with the applicable payout schedule and eligibility requirements. The Company reserves the right, at its sole discretion and with or without notice, to modify payout schedules, eligibility requirements, minimum payout thresholds, or distribution mechanisms at any time.\n 7. Blockchain\nUsing the Services may require that you pay a fee to other users of the Services (such as merchants) or to the Company. Using the Services may also require that you pay a fee to parties other than users or the Company, such as gas charges on the blockchain to perform a transaction. You acknowledge and agree that the operator has no control over any such transactions, the method of payment of such transactions or any actual payments of transactions. Accordingly, you must ensure that you have a sufficient balance of the applicable cryptocurrency tokens stored at your protocol-compatible wallet address to complete any transaction on the blockchain or Services before initiating such transaction.\nYou accept all risks associated with your financial, cryptocurrency, and other crypto asset holdings, staking, and transfers. You agree and acknowledge that the Company is not responsible or liable for disclosure of your personal wallet “key,” even if such loss may be attributed to an error or “bug” in the Services.\nYou understand and accept that your access to your tokens or other cryptocurrency assets may be suspended or terminated or there may be a delay in your access or use which may result in your tokens or other cryptocurrency assets diminishing in value or you being unable to complete a smart contract.\nYou accept all risks associated with the use of the Services to conduct cryptocurrency transactions, including, but not limited to, in connection with the failure of hardware, software, internet connections, and failures related to any supported network.\nYou understand and accept that the Services may be suspended or terminated for any or no reason, which may limit your access to your cryptocurrency assets.\nYou agree that you understand the inherent risks associated with cryptographic systems, including hacking risks and future technological development.\nYou agree that you have an understanding of the usage and intricacies of native cryptographic tokens. You acknowledge and understand that with regard to any cryptographic tokens “stored” in a wallet to which you have custody, you alone are responsible for securing your private key(s). The Company does not have access to your private key(s). Losing control of your private key(s) will permanently and irreversibly deny you access to blockchain resources and your blockchain wallet.\nYou agree that with regard to any cryptographic tokens or other assets stored on resources hosted by the Company, the Company is not liable to you for any loss, failure, or unavailability of any kind, of such tokens or assets, for any reason.\nRegardless of anything to the contrary in this Agreement, nothing in this Agreement is a waiver, and we will not assert there has been a waiver, that would not be permissible under Section 14 of the Securities Act of 1933, Section 29(a) of the Securities Exchange Act of 1934, or any other applicable provision of US federal and state securities laws.\nYou acknowledge that the Company and its affiliates do not provide investment advice or a recommendation of securities or investments. You should always obtain independent investment and tax advice from your professional advisers before making any investment decisions.\nYou acknowledge that you are not relying on the Company or any of its affiliates, officers, directors, partners, agents or employees in making an investment decision. Always consider seeking the advice of a qualified professional before making decisions regarding your business and/or investments. The Company does not endorse any investments and shall not be responsible in any way for any transactions you enter into with third parties. You agree that the Company and its affiliates, officers, directors, partners, agents or employees will not be liable for any loss or damages of any sort incurred as a result of any interactions between you and third parties.\nIt is your responsibility to determine what, if any taxes may apply to the transactions you complete under the Services and it is your responsibility to report and remit the appropriate tax to the relevant taxing authorities. You agree that the operator is not responsible for determining whether taxes apply to the exchanges made under the Services.\n 8. Intellectual Property Rights.\n 8.1 Ownership of Intellectual Property.\nYou acknowledge that all intellectual property rights, including copyrights, trademarks, trade secrets, and patents, in the Services and its contents, features, and functionality (collectively, the “Content”), are owned by the Company, its licensors, or other providers of such material. The Content is protected by U.S. and international intellectual property or proprietary rights laws. Neither this Agreement nor your access to the Services transfers to you any right, title, or interest in or to such intellectual property rights. Any rights not expressly granted in this Agreement are reserved by the Company and its licensors.\n 8.2 License to Use the Services.\nDuring the Term of this Agreement, the Company grants you a limited, non-exclusive, non-transferable, non-sublicensable, and revocable license to use and access the Content for any business or commercial use in accordance with this Agreement. The Content may not be used for any other purpose. This license will terminate upon your cessation of use of the Services or at the termination of this Agreement.\n 8.3 Certain Restrictions.\nThe rights granted to you in this Agreement are subject to the following restrictions:\n (a) No Copying or Distribution.\nYou shall not copy, reproduce, publish, display, perform, post, transmit, or distribute any part of the Content in any form or by any means except as expressly permitted herein or as enabled by a feature, product, or the Services when provided to you.\n (b) No Modifications.\nYou shall not modify, create derivative works from, translate, adapt, disassemble, reverse compile, or reverse engineer any part of the Content.\n (c) No Exploitation.\nYou shall not sell, license, sublicense, transfer, assign, rent, lease, loan, host, or otherwise exploit the Content or the Services in any way, whether in whole or in part.\n (d) No Altering of Notices.\nYou shall not delete or alter any copyright, trademark, or other proprietary rights notices from copies of the Content.\n (e) No Competition.\nYou shall not access or use the Content in order to build a similar or competitive website, product, or service.\n (f) Systematic Retrieval.\nYou shall not use any information retrieval system to create, compile, directly or indirectly, a database, compilation, collection or directory of the Content or other data from the Services.\n 8.4 Trademark Notice.\nAll trademarks, logos, and service marks displayed on the Services are either the Company’s property or the property of third parties. You may not use such trademarks, logos, or service marks without the prior written consent of their respective owners.\n 9. User Content.\n 9.1 User Generated Content.\nThe Services may contain features that allow users to post, upload, submit, or process content or materials (collectively, “User Content”) on or through the Services.\nYou are solely responsible for your User Content. Please consider carefully what you choose to share. All User Content must comply with the Content Standards set forth below. Any User Content you post on or through the Services will be considered non-confidential and non-proprietary. You assume all risks associated with the use of your User Content. This includes any reliance on its accuracy, completeness, reliability, or appropriateness by other users and third parties, or any disclosure of your User Content that personally identifies you or any third party. You agree that the Company shall not be responsible or liable to any third party for any User Content posted by you or any other user of the Services.\nYou further agree that the Company shall not be responsible for any loss or damage incurred as the result of any interactions between you and other users. Your interactions with other users are solely between you and such users. If there is a dispute between you and any other user, we are under no obligation to become involved.\n 9.2 License.\nYou hereby grant to the Company an irrevocable, non-exclusive, royalty-free and fully paid, transferable, perpetual, and worldwide license to reproduce, distribute, publicly display and perform, prepare derivative works of, incorporate into other works, and otherwise use and exploit your User Content, and to grant sublicenses of the foregoing rights, in connection with the Services and the Company’s business including, without limitation, for promoting and redistributing part or all of the Services in any media formats and through any media channels.\nYou represent and warrant that you have all the rights, power, and authority necessary to grant the rights granted herein to any User Content that you submit. You hereby irrevocably waive all claims and have no recourse against us for any alleged or actual infringement or misappropriation of any proprietary rights in any communication, content, or material submitted to us. Please note that all of the following licenses are subject to our Privacy Policy to the extent they relate to any User Content that contains any personally identifiable information.\n 9.3 Content Standards.\nYou agree not to send, knowingly receive, upload, transmit, display, or distribute any User Content that does not comply with the following standards (“Content Standards”). User Content must not:\n (a) Violate Laws or Obligations.\nViolate any applicable laws or regulations (including intellectual property laws and right of privacy or publicity laws), or any contractual or fiduciary obligations.\n (b) Promote Illegal Activity or Harm to Others.\nPromote any illegal activity; advocate, promote, or assist any unlawful act; or create any risk of any harm, loss, or damage to any person or property.\n (c) Infringe Intellectual Property Rights.\nInfringe any copyright, trademark, patent, trade secret, moral right, or other intellectual property rights of any other person.\n (d) Defamatory, Abusive, or Otherwise Objectionable Material.\nContain any information or material that we deem to be unlawful, defamatory, trade libelous, invasive of another’s privacy or publicity rights, abusive, threatening, harassing, harmful, violent, hateful, obscene, vulgar, profane, indecent, offensive, inflammatory, humiliating to other people (publicly or otherwise), or otherwise objectionable. This includes any information or material that we deem to cause annoyance, inconvenience, or needless anxiety, or be likely to upset, embarrass, alarm, or annoy another person.\n (e) Promotion of Sexually Explicit Material or Discrimination.\nPromote sexually explicit or pornographic material, violence, or discrimination based on race, sex, religion, nationality, disability, sexual orientation, or age.\n (f) Fraudulent Information or Impersonation.\nContain any information or material that is false, intentionally misleading, or otherwise likely to deceive any person including, without limitation, impersonating any person, or misrepresenting your identity or affiliation with any person or organization.\n (g) Endorsement by the Company.\nRepresent or imply to others that it is in any way provided, sponsored, or endorsed by the Company or any other person or entity, if that is not the case.\n 9.4 Monitoring and Enforcement.\nWe reserve the right at all times, but are not obligated, to take any action with respect to any User Content that we deem necessary or appropriate in our sole discretion, including if we believe that such User Content violates the Content Standards or any other provision in this Agreement, or creates liability for the Company or any other person. Such action may include reporting you to law enforcement authorities.\nThe Company and its affiliates, and their respective officers, directors, employees or agents, assume no liability for any action or inaction regarding transmissions, communications, or content provided by any user or third party. The Company shall have no liability or responsibility to anyone for the performance or non-performance of the activities described in this Section.\n 9.5 Feedback to the Company.\nIf you provide the Company with any feedback or suggestions regarding the Services (“Feedback”), you hereby assign to the Company all rights in such Feedback and agree that the Company shall have the right to use and fully exploit such Feedback and related information in any manner it deems appropriate. The Company will treat any Feedback that you provide to the Company as non-confidential and non-proprietary. You agree that you will not submit to the Company any information or ideas that you consider to be confidential or proprietary.\n 10. Assumption of Risk.\nThe information presented on or through the Services is made available for general information purposes only. The Company does not warrant the accuracy, completeness, suitability, or quality of any such information. Any reliance on such information is strictly at your own risk. The Company disclaims all liability and responsibility arising from any reliance placed on such information by you or any other user of the Services, or by anyone who may be informed of any of its contents.\n 11. Prevention Of Money Laundering, Terrorist Finance, And Violations Of Financial Sanctions\nYou represent and warrant that:\nYou will not use the Services in any illegal manner or for any illegal purposes, in particular not for any purposes related to money laundering, predicate offenses of money laundering, terrorist financing or other activities that violate applicable law,\nYou will not use any proceeds from illegal activities for transactions made in connection with the Services, and\nYou will make no transactions in connection with the Services to facilitate or engage in illegal activities, in particular activities related to money laundering, predicate offenses of money laundering, terrorist financing, Sanctions evasion, or other activities that violate applicable law.\nYou represent and warrant that, at the time of any use of the Services, no criminal or regulatory investigations are pending against you or—where you are not a natural person—against any of your affiliates, members of its managing or supervisory body, other senior executives, or shareholders in connection with your business activities. You represent and warrant that, at the time of any use of the Services, no criminal or regulatory investigations are pending against you or—where you are not a natural person—against any of your affiliates, members of your managing or supervisory body, other senior executives, or shareholders in connection with your business activities.\nYou represent and warrant that, at the time of any use of the Services:\nYou are not included on a Sanctions list of the United States of America, the European Union or any of its member states, or the United Kingdom, nor any Sanctions list in the countries in which you are a citizen, resident, or does business.\nYou are neither acting (i) indirectly (e.g., as proxy or agent) on behalf of a natural or legal person included on a Sanctions list, or (ii) directly or indirectly transferring assets of any kind to a natural or legal person included on a Sanctions list.\nIf you are not a natural person, none of your shareholders who directly or indirectly holds more than 25 percent of its shares is included on a Sanctions list.\nYou understand and abide by U.S. Sanctions and the Sanctions of the country in which you conduct business.\nYou will not engage in any action or use the Services in any way that would cause the Company to violate U.S. Sanctions or the Sanctions of the country in which it is a citizen, resident, or conducts business, including providing software or services to any person in any country subject to comprehensive Sanctions by the United States or any country subject to U.S. Export Administration Regulations and/or any party on a Sanctions list.\nYou will notify Company if you are placed on a Sanctions list or otherwise have reason to believe you may have violated Sanctions and shall cooperate with Company to comply with Company’s legal obligations.\n 12. Privacy.\nFor information about how the Company collects, uses, and shares your information, please review our Privacy Policy. You agree that by using the Services you consent to the collection, use, and sharing (as set forth in the Privacy Policy) of such information.\nThe Children’s Online Privacy Protection Act requires that online service providers obtain parental consent before they knowingly collect personally identifiable information online from children who are under 13 years old. We do not knowingly collect or solicit personally identifiable information from children under 13 years old. If you are a child under 13 years old, please do not attempt to register for the Services or send any personal information about yourself to us. If we learn we have collected personal information from a child under 13 years old, we will delete that information as quickly as possible. If you believe that a child under 13 years old may have provided us with personal information, please contact us.\n 13. Third-Party Links and Ads.\nThe Services may contain links to third-party websites, resources, and services, as well as advertisements (collectively, “Third-Party Links”). Third-Party Links are provided for your convenience only. The Company does not review, approve, monitor, endorse, warrant, or make any representations with respect to Third-Party Links. The Company has no control over the contents, products, or services of any Third-Party Link and accepts no responsibility for them or for any loss or damage that may arise from your use of them. If you decide to access any Third-Party Link, you do so entirely at your own risk and subject to the terms and conditions of use for such Third-Party Link. You should make whatever investigation you feel necessary or appropriate before proceeding with any transaction in connection with any Third-Party Link.\n 14. Termination.\n 14.1 Termination.\nThe Company may suspend or terminate your access or rights to use the Services at any time, for any reason, in our sole discretion, and without prior notice, including for any breach of the terms of this Agreement. Upon termination of your access or rights to use the Services, your right to access and use the Services will immediately cease. The Company will not have any liability whatsoever to you for any suspension or termination of your rights under this Agreement, including for termination of your account or deletion of your User Content. If you have registered for an account, you may terminate this Agreement at any time by contacting the Company and requesting termination.\n 14.2 Effect of Termination.\nUpon termination of this Agreement, any provisions that by their nature should survive termination shall remain in full force and effect. This includes, without limitation, ownership or intellectual property provisions, warranty disclaimers, and limitations of liability. Termination of your access to and use of the Services shall not relieve you of any obligations arising or accruing prior to termination or limit any liability that you otherwise may have to the Company or any third party. You understand that any termination of your access to and use of the Services may involve deletion of your User Content associated with your account from our databases.\n 15. No Warranty.\nThe Services are provided on an “as-is” and “as-available” basis. Use of the Services is at your own risk. To the maximum extent permitted by applicable law, the Services are provided without warranties of any kind, whether express, implied, statutory, or otherwise, including, but not limited to, implied warranties of merchantability, fitness for a particular purpose, title, quiet enjoyment, accuracy, or non-infringement.\nWithout limiting the foregoing, the Company and its licensors do not warrant that any content provided in the Services is accurate, reliable, complete, or correct; that the Services will meet your requirements; that the Services will be available at any particular time or location, uninterrupted, error-free, or secure; that any defects or errors will be corrected; that the Services are free of viruses or other harmful components; or that the Services or items obtained through the Services will otherwise meet your requirements or expectations. To the fullest extent provided by law, the Company and its affiliates will not be liable for any loss or damage to your computer system, mobile device, data, or other proprietary material that may result from your use of the Services or items obtained through the Services or your downloading of any material posted on the Services. We do not warrant, endorse, guarantee, or assume responsibility for any product or services advertised or offered by a third party through the Services or third-party links, and we will not be a party to or in any way monitor any transaction between you and any third-party providers of products or services or any other user.\nThe Services would not be provided without these limitations. No advice or information, whether oral or written, obtained by you from us through the Services will create any warranty, representation, or guarantee not expressly stated in this agreement. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you. If applicable law requires any warranties with respect to the services, all such warranties are limited in duration to ninety (90) days from the date of first use.\n 16. Limitation of Liability.\nTo the fullest extent allowed by applicable law, in no event shall the Company or its affiliates, or their respective licensors, service providers, employees, agents, officers, or directors be liable to you or any third party for any damages of any kind, under any legal theory, arising out of or in connection with your use or inability to use the Services, any third-party link, or any content on the Services or such third-party link, including, without limitation, any loss of use, revenue, or profit, loss of business or anticipated savings, loss of data, loss of goodwill, or diminution in value, or for any consequential, incidental, indirect, exemplary, special, or punitive damages whether arising out of breach of contract, tort (including negligence), or otherwise, regardless of whether such damage was foreseeable and whether or not the Company has been advised of the possibility of such damages. Your sole remedy for dissatisfaction with the services is to stop using the services.\nSome jurisdictions do not allow the exclusion or limitation of certain damages, so the above limitation and exclusions may not apply to you.\n 17. Indemnification.\nYou agree to indemnify, defend, and hold harmless the Company and its affiliates and their respective officers, directors, employees, agents, affiliates, successors, and permitted assigns (collectively, “Indemnified Party”) from and against any and all loss, claims, actions, suits, complaints, damages, liabilities, penalties, interest, judgments, settlements, deficiencies, disbursements, awards, fines, costs, fees, or expenses of whatever kind, including reasonable attorneys’ fees, fees and other costs of enforcing any right to indemnification under this Agreement, and the cost of pursuing any insurance providers, arising out of or relating to your breach of this Agreement or your use or misuse of the Services including, but not limited to, your User Content or any actions taken by a third party using your account. The Company reserves the right, at your expense, to assume the exclusive defense and control of any matter for which you are required to indemnify us, and you agree to assist and cooperate with our defense or settlement of these claims.\n 18. Disputes.\n 18.1 Governing Law.\nAll matters relating to this Agreement, and all matters arising out of or relating to this Agreement, whether sounding in contract, tort, or statute are governed by, and construed in accordance with, the laws of Delaware, without giving effect to any conflict of law principles. The United Nations Convention on Contracts for the International Sale of Goods (CISG) is expressly disclaimed by the parties with respect to this Agreement and the transactions contemplated hereby.\n 18.2 Dispute Resolution.\nAny dispute, controversy or claim arising out of or relating to this contract, including the formation, interpretation, breach or termination thereof, including whether the claims asserted are arbitrable, will be referred to and finally determined by arbitration in accordance with the JAMS International Arbitration Rules, including the Expedited Procedures under those rules. The tribunal will consist of a sole arbitrator. The seat of the arbitration will be Delaware, but the arbitration will be conducted remotely to the extent permitted by the applicable rules. The language to be used in the arbitral proceedings will be English. Judgment upon the award rendered by the arbitrator may be entered by any court having jurisdiction thereof. The arbitrator may not award any incidental, indirect consequential damages, including damages for lost profits. The arbitrator is not empowered to award punitive or exemplary damages, except where permitted by statute, and the parties waive any right to recover any such damages.\nIn any arbitration arising out of or related to this Agreement, the arbitrator shall award to the prevailing party, if any, the reasonable costs for legal representation incurred by the prevailing party in connection with the arbitration. If the arbitrator determines a party to be the prevailing party under the circumstances where the prevailing party won on some but not all of its claims and counterclaims, the arbitrators may award the prevailing party an appropriate percentage of the reasonable costs for legal representation incurred by the prevailing party in connection with the arbitration.\nThe parties shall maintain the confidential nature of the arbitration proceeding and any award, including any hearings, except as may be necessary to prepare for or conduct the arbitration hearing on the merits, or except as may be necessary in connection with a court application for a preliminary remedy, a judicial challenge to an award or its enforcement, or unless otherwise required by law or judicial decision.\nIn any arbitration arising out of or related to this Agreement, requests for documents:\nShall be limited to documents which are directly relevant to significant issues in the case or to the case’s outcome;\nShall be restricted in terms of time frame, subject matter, and persons or entities to which the requests pertain; and\nShall not include broad phraseology such as “all documents directly or indirectly related to.”\nIn any arbitration arising out of or related to this Agreement:\nThere shall be production of electronic documents only from sources used in the ordinary course of business. Absent a showing of compelling need, no such documents are required to be produced from backup servers, or other media.\nAbsent a showing of compelling need, the production of electronic documents shall normally be made on the basis of generally available technology in a searchable format which is usable by the party receiving the e-documents and convenient and economical for the producing party. Absent a showing of compelling need, the parties need not produce metadata, with the exception of header fields for email correspondence.\nThe description of custodians from whom electronic documents may be collected shall be narrowly tailored to include only those individuals whose electronic documents may reasonably be expected to contain evidence that is material to the dispute.\nWhere the costs and burdens of discovery are disproportionate to the nature of the dispute or to the amount in controversy, or to the relevance of the materials requested, the arbitrator will either deny such requests or order disclosure on condition that the requesting party advance the reasonable cost of production to the other side, subject to the allocation of costs in the final award.\nIn any arbitration arising out of or related to this Agreement, there shall be no interrogatories or requests to admit.\nYou understand and agree that by entering into these terms, you are waiving the right to trial by jury or to participate in a class action.\n 18.3 Limitation to Time to File Claims.\nAny cause of action or claim you may have arising out of or relating to this agreement or the services must be commenced within one (1) year after the cause of action arose; otherwise, such cause of action or claim is permanently waived and barred.\n 19. Miscellaneous.\n 19.1 Waiver.\nExcept as otherwise set forth in this Agreement, no failure of the Company to exercise, or delay by the Company in exercising, any right, remedy, power, or privilege arising from this Agreement shall operate or be construed as a waiver thereof, nor shall any single or partial exercise of any right, remedy, power, or privilege hereunder preclude any other or further exercise thereof or the exercise of any other right, remedy, power, or privilege.\n 19.2 Severability.\nIf any term or provision of this Agreement is found by a court of competent jurisdiction to be invalid, illegal, or unenforceable, such invalidity, illegality, or unenforceability shall not affect any other term or provision of this Agreement or invalidate or render unenforceable such term or provision in any other jurisdiction.\n 19.3 Entire Agreement.\nThis Agreement, together with all documents referenced herein, constitutes the entire agreement between you and the Company with respect to the subject matter contained herein. This Agreement supersedes all prior and contemporaneous understandings, agreements, representations, and warranties, both written and oral, with respect to the subject matter hereof.\n 19.4 Headings.\nHeadings and titles of sections, clauses, and parts in this Agreement are for convenience only. Such headings and titles shall not affect the meaning of any provisions of the Agreement.\n 19.5 No Agency, Partnership, or Joint Venture.\nNo agency, partnership, or joint venture has been created between you and the Company as a result of this Agreement. You do not have any authority of any kind to bind the Company in any respect whatsoever.\n 19.6 Assignment.\nYou shall not assign or delegate any of your rights or obligations under this Agreement without the prior written consent of the Company. Any purported assignment or delegation in violation of this Section shall be deemed null and void. No assignment or delegation shall relieve you of any of your obligations hereunder. The Company may freely assign or delegate its rights and obligations under this Agreement at any time. Subject to the limits on assignment stated above, this Agreement will inure to the benefit of, be binding on, and be enforceable against each of the parties hereto and their respective successors and assigns.\n 19.7 Export Laws.\nThe Services may be subject to U.S. export control laws and regulations. You agree to abide by these laws and their regulations (including, without limitation, the Export Administration Act and the Arms Export Control Act) and not to transfer, by electronic transmission or otherwise, any materials from the Services to either a foreign national or a foreign destination in violation of such laws or regulations.\n 20. Contact Information.\nAll feedback, comments, requests for technical support, and other communications relating to the Services should be directed to support@io.net.1. Acceptance of this Agreement.\n1.1 Acceptance Through Using or Accessing the Services.\n1.2 Eligibility Requirements to Use or Access the Services.\n1.3 Changes to this Agreement.\n2. Access to the Services.\n3. Policy for Using the Services.\n3.1 Prohibited Uses.\n3.2 Prohibited Activities.\n(a) No Violation of Laws or Obligations.\n(b) No Unsolicited Communications.\n(c) No Impersonation.\n(d) No Harming of Minors.\n(e) Compliance with Content Standards.\n(f) No Interference with Others’ Enjoyment.\n(g) No Interference or Disabling of the Services.\n(h) No Monitoring or Copying of Material.\n(i) No Viruses, Worms, or Other Damaging Software.\n(j) No Unauthorized Access or Violation of Security.\n(k) No Reverse Engineering.\n(l) No Collecting User Data.\n(m) No Other Interference.\n(n) Attempt or Assist Others in Attempting.\n(o) Money Laundering.\n(p) Circumvention.\n(q) Scraping.\n(r) Anti-aggregation.\n3.3 Geographic Restrictions.\n3.4 Sanctions.\n3.5 Consequences of Misuse.\n3.6 Patriot Act\n4. Paid Services\n4.1 Billing Policies.\n4.2 Cluster Billing.\n4.3 Dynamic Pricing.\n4.4 No Refunds.\n4.5 Insufficient Balance; Failed Payments.\n4.6 Auto-Termination; Data Loss.\n4.7 Taxes.\n4.8 IO Credits.\n(a) Purchase and Value.\n(b) Usage Priority.\n(c) Withdrawal for Credits.\n(d) Non-Transferability.\n(e) Expiration.\n(f) No Cash Redemption.\n5. Third-Party Service Providers\n6. Epoch Rewards\n7. Blockchain\n8. Intellectual Property Rights.\n8.1 Ownership of Intellectual Property.\n8.2 License to Use the Services.\n8.3 Certain Restrictions.\n(a) No Copying or Distribution.\n(b) No Modifications.\n(c) No Exploitation.\n(d) No Altering of Notices.\n(e) No Competition.\n(f) Systematic Retrieval.\n8.4 Trademark Notice.\n9. User Content.\n9.1 User Generated Content.\n9.2 License.\n9.3 Content Standards.\n(a) Violate Laws or Obligations.\n(b) Promote Illegal Activity or Harm to Others.\n(c) Infringe Intellectual Property Rights.\n(d) Defamatory, Abusive, or Otherwise Objectionable Material.\n(e) Promotion of Sexually Explicit Material or Discrimination.\n(f) Fraudulent Information or Impersonation.\n(g) Endorsement by the Company.\n9.4 Monitoring and Enforcement.\n9.5 Feedback to the Company.\n10. Assumption of Risk.\n11. Prevention Of Money Laundering, Terrorist Finance, And Violations Of Financial Sanctions\n12. Privacy.\n13. Third-Party Links and Ads.\n14. Termination.\n14.1 Termination.\n14.2 Effect of Termination.\n15. No Warranty.\n16. Limitation of Liability.\n17. Indemnification.\n18. Disputes.\n18.1 Governing Law.\n18.2 Dispute Resolution.\n18.3 Limitation to Time to File Claims.\n19. Miscellaneous.\n19.1 Waiver.\n19.2 Severability.\n19.3 Entire Agreement.\n19.4 Headings.\n19.5 No Agency, Partnership, or Joint Venture.\n19.6 Assignment.\n19.7 Export Laws.\n20. Contact Information.","tokens":14103,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268151326,"hash":"5cee48f0af42787ec0ed4a32730c29f745e57ffd"}
{"url":"https://docs.optimism.io/app-developers/guides/connect-wallet-to-actions","domain":"docs.optimism.io","title":"Optimism Documentation","text":"Actions SDK works with wallets from popular embedded wallet providers, regardless of where and how transactions are signed.\nThis guide shows you how to connect a provider wallet to Actions so it can call Actions functions.\nFor help deciding which wallet schema fits your use case, see Integrating wallets.\n​Connect your wallet\n1Choose a wallet providerFollow embedded wallet provider documentation and installation steps.\nActions works with Typescript clients, both frontend React and backend Node.2Import Actions SDKImport Actions SDK alongside your chosen wallet\nprovider SDK.\nThe quickstart covers\ninstalling Actions SDK in your project.3Create and fetch embedded user walletsFollow embedded wallet provider documentation for wallet creation and\naccess.4Pass the wallet to ActionsCall actions.wallet.toActionsWallet(...), and pass\nin the\nprovider wallet.\nThe quickstart includes provider-specific code examples for both frontend\nand backend clients.5Take ActionThe returned\nWallet is now\ncapable of calling Actions\nfunctions like Lend,\nBorrow, Swap and Pay!\n​Next steps\n\nFollow the Configuring Actions guide to define which protocols, chains, and assets to support.\nLearn about smart wallets & signers if you want Actions to deploy smart contract wallets controlled by your users’ embedded wallets.\nSee the Wallet Documentation for API details on wallet classes, functions, and parameters.\nWas this page helpful?","tokens":354,"squid":"ink-governance","role":"Council Listener","at":1791268155237,"hash":"a6c8ea1ecae98ddb124f0bbd21415b450be9f9d5"}
{"url":"https://forum.openzeppelin.com/t/create2-failed-on-deploy-when-using-create2-library/3231/3","domain":"forum.openzeppelin.com","title":"Create2: Failed on deploy when using Create2 library - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jun 2020\n\n 3 / 3\n\n Jul 2020\n\n Jul 2020\n\n post by alexander on Jun 30, 2020\n\n post by abcoathup on Jun 30, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @alexander,\nWelcome to the community forum \nIf you use a constructor, this is part of the creation code and will impact the CREATE2 deployment address. See Getting the most out of CREATE2 for more details.\nA simple example is as follows, with the Vault contract using an Initializer:\nVault.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"@openzeppelin/upgrades/contracts/Initializable.sol\";\n\ncontract Vault is Initializable {\n address payable public owner;\n\n function initialize(address payable _owner) public initializer {\n owner = _owner;\n }\n\n function withdraw() public {\n require(owner == msg.sender, \"Vault: Not owner\");\n owner.transfer(address(this).balance);\n }\n}\n\nVaultFactory.sol\n// SPDX-License-Identifier: MIT\npragma solidity ^0.6.0;\n\nimport \"./Vault.sol\";\nimport \"@openzeppelin/contracts/utils/Create2.sol\";\n\ncontract VaultFactory {\n event VaultCreated(address vault);\n\n function deployVault(bytes32 salt, address payable owner) public {\n address vaultAddress;\n\n vaultAddress = Create2.deploy(0, salt, type(Vault).creationCode);\n Vault(vaultAddress).initialize(owner);\n\n emit VaultCreated(vaultAddress);\n }\n\n function computeAddress(bytes32 salt) public view returns (address) {\n return\n Create2.computeAddress(salt, keccak256(type(Vault).creationCode));\n }\n}\n\nDeploy VaultFactory\n$ npx oz deploy\n✓ Compiled contracts with solc 0.6.10 (commit.00c0fcaf)\nCompilation warnings:\n@openzeppelin/upgrades/contracts/Initializable.sol: Warning: SPDX license identifier not provided in source file. Before publishing, consider adding a comment containing \"SPDX-License-Identifier: <SPDX-License>\" to each source file. Use \"SPDX-License-Identifier: UNLICENSED\" for non-open-source code. Please see https://spdx.org for more information.\n\n? Choose the kind of deployment regular\n? Pick a network development\n? Pick a contract to deploy VaultFactory\n✓ Deployed instance of VaultFactory\n0xe78A0F7E598Cc8b0Bb87894B0F60dD2a88d6a8Ab\n\nCompute address (for salt 0x42)\n$ npx oz call\n? Pick a network development\n? Pick an instance VaultFactory at 0xe78A0F7E598Cc8b0Bb87894B0F60dD2a88d6a8Ab\n? Select which function computeAddress(salt: bytes32)\n? salt: bytes32: 0x42\n✓ Method 'computeAddress(bytes32)' returned: 0xEdbC0b28Ac53390ccd1b987d6348bE97C93c4f53\n0xEdbC0b28Ac53390ccd1b987d6348bE97C93c4f53\n\nDeploy (for salt (0x42)\n$ npx oz send-tx\n? Pick a network development\n? Pick an instance VaultFactory at 0xe78A0F7E598Cc8b0Bb87894B0F60dD2a88d6a8Ab\n? Select which function deployVault(salt: bytes32, owner: address)\n? salt: bytes32: 0x42\n? owner: address: 0x90F8bf6A479f320ead074411a4B0e7944Ea8c9C1\n✓ Transaction successful. Transaction hash: 0x6956a48e6748cd90a51cd578924c63fac36274443e64f4681e5f791b3f3a0769\nEvents emitted:\n - VaultCreated(0xEdbC0b28Ac53390ccd1b987d6348bE97C93c4f53)\n\n 11 days later\n\n post by abcoathup on Jul 12, 2020\n\n abcoathup\n\n Great contributor\n\n Hi @alexander,\nChecking that you were able to resolve?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract\n\n Guides and Tutorials\n\n 5\n\n 7.6k\n\n Mar 2025\n\n When does `create2(…)` return the zero address?\n\n Smart Contracts\n\n 1\n\n 2.0k\n\n Jan 2022\n\n How can I deploy CREATE2 smart contract with private key?\n\n Smart Contracts\n\n 0\n\n 371\n\n Apr 2022\n\n Discussion on OpenZeppelin Contracts 2.5 Create2.sol\n\n General\n\n 4\n\n 1.9k\n\n Mar 2020\n\n How to use a CREATE2 deployer\n\n General\n\n 7\n\n 2.1k\n\n Jun 2021","tokens":938,"squid":"ink-security_audits","role":"Sentinel","at":1791268158320,"hash":"97a2d5cd40ff12901f3a58f68157bdc51d2e2d22"}
{"url":"https://io.net/blog/io-intelligence","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogIO IntelligenceLatest By Topic (14)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsWho Decides What Your AI Can Say? Inside Model Censorship and AlignmentIO.NET Team / Aug 15, 2026When you ask an AI to help with something and it refuses, that refusal didn't happen by accident. Someone, or more precisely, a team of researchers, lawyers, and ethicists at a major AI lab, made a deliberate choice to build that boundary into the model. Today, major model providers (e.g. OpenAI, Anthropic, Google, Meta, Mistral, and Cohere) each maintain their own alignment teams, each with distinct values, risk tolerances, and commercial pressures shaping what their models will and won't do. THow Vistara Labs’ Platform Built 5,600 Apps in 2 Months with io.netIO.NET Team / May 4, 2026Vistara Labs used io.net to scale its Zaara AI platform, building 5,600 apps in two months while cutting compute costs by 3x and achieving zero infrastructure failures.GLM-4.7 Flash Now Available on io.intelligenceIO.NET Team / Jan 23, 2026Z.ai's GLM-4.7-Flash (30B MoE) is live on io.intelligence. Get the strongest 30B model for coding & reasoning with best-in-class performance-per-dollar.GLM-4.7 Now Available on io.intelligenceIO.NET Team / Jan 13, 2026GLM-4.7 is now live on io.intelligence. Z.ai's open-source coding model scores 84.9% on LiveCodeBench vs Claude's 64%. Access it via a single API endpoint.Introducing Unified Chat: One Interface for Every AI Model and ToolIO.NET Team / Nov 4, 2025Unified Chat is the single, intelligent AI workspace that unifies every model and tool. Auto-routes for optimal quality and cost. End fragmentation.AI Data Centers: Optimizing Workloads and Infrastructure EfficiencyIO.NET Team / Oct 9, 2025Discover how AI data centers optimize workloads, boost efficiency, and power the future of artificial intelligence with advanced infrastructure.What Is Vibe Coding? io.net & Void Fix Productivity Death SpiralsIO.NET Team / Jun 1, 2025Tired of 25-call limits killing your AI coding flow? Learn how io.net and Void Editor unlock truly autonomous development without artificial constraints.io.net Turns One: Building the Intelligent Stack for AIIO.NET Team / May 12, 2025io.net celebrates its first anniversary, showcasing growth to 10,000+ GPUs across 138 regions and $13M revenue while democratizing AI infrastructure access.io.net Powers Privacy-First AI Training with Flashback Labs' StargazerIO.NET Team / May 4, 2025io.net enables privacy-first AI training through Flashback Labs' Stargazer model, using federated learning and TEEs to protect personal data during training.Launch I/O: Build Real-World Agents with io.intelligenceIO.NET Team / Apr 27, 2025Launch I/O is a 35-day hackathon where developers build autonomous AI agents using io.intelligence's unified toolkit, with $6,500 in prizes and ecosystem access.io.net Decentralized GPU Network: Simplifying AI Deployment on Solana with Developer ToolsIO.NET Team / Apr 6, 2025io.net's developer tools provide simplified API integration and decentralized GPU access, reducing AI deployment costs by up to 90% compared to centralized providers.What is IO Intelligence? Unlocking the Power of AI-Driven InsightsIO.NET Team / Mar 2, 2025IO Intelligence is an AI-powered analytics system that optimizes decentralized computing with real-time monitoring, cost reduction, and LLM performance tracking.Page 1 of 2","tokens":927,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268161361,"hash":"844a7974fc85adb709efe881b37d2d9edb1bad2e"}
{"url":"https://docs.optimism.io/app-developers/guides/testing-apps","domain":"docs.optimism.io","title":"Optimism Documentation","text":"For the most part, running applications on OP Stack chains is identical to running them on Ethereum, so the testing is identical too.\nIn this guide, you learn the best practices for OP Stack testing where there are differences.\n​Unit tests and single layer integration tests\nThe vast majority of tests do not involve any OP Stack-specific features.\nIn those cases, while you could test everything on an OP Stack chain or a test network, that would normally be inefficient.\nMost Ethereum development stacks include features that make testing easier, which normal Ethereum clients, such as geth (and our modified version, op-geth) don’t support.\nTherefore, it is a good idea to run the majority of tests, which do not rely on OP Stack-specific features, in the development stack.\nIt is a lot faster.\nIt is a best practice to design and run thorough tests across an OP test network, either in your local multichain development environment, our devnets, or on the test network, depending on your use case. Alternatively, with Tenderly Virtual TestNetsyou can run tests with complete integration with existing protocols, access to unlimited faucets, continuous state sync, and access to development tools such as Debugger and Simulator UI.\nRunning proper testing is key to identifying fringe cases where the equivalence between OP Stack chains and Ethereum breaks down (or where Ethereum mainnet itself and the development stack may be non-equivalent in a production environment).\n​Multilayer integration tests\nSome apps need OP Stack-specific features that aren’t available as part of the development stack.\nFor example, if your decentralized application relies on inter-domain communication, the effort of developing a stub to let you debug it in a development stack is probably greater than the hassle of having the automated test go to a local multichain development environment each time.\n​Testing and Staging with Tenderly\nTenderly Virtual TestNets provide a powerful environment for testing OP Stack applications with mainnet-like conditions. They offer several advantages for testing OP Stack applications:\n\nMainnet State Replication: Virtual TestNets can sync with the latest OP Stack mainnet state, allowing you to test against real network conditions and interact with up-to-date protocols without spending real assets.\nUnlimited Faucet: Access unlimited test tokens for both native currency and ERC-20 tokens, enabling comprehensive testing of complex DeFi interactions.\nCollaborative Testing: Your entire team can access the same testing environment, making it easier to debug issues and validate fixes.\nCI/CD Integration: Incorporate automated testing in your deployment pipeline using Virtual TestNets’ API and GitHub Actions integration.\nDevelopment tools: Rely on the built-in developer explorer and debugging tools to analyze test transactions and contract interactions.\n\n​Integration with other products\nIn many cases a decentralized application requires the services of other contracts.\nFor example, Perpetual v. 2 cannot function without Uniswap v. 3.\n\nIf that is the case, you can use mainnet forking. It works with OP Stack chains.\nCreate a Virtual TestNet to get access to third party contracts (e.g. Uniswap) and it’s latest or historical state.\nAlternatively, you can connect to our test network if those contracts are also deployed there (in many cases they are).\nWas this page helpful?","tokens":852,"squid":"ink-governance","role":"Council Listener","at":1791268165437,"hash":"0a16020325990198cde921bc0974d20ad9b8039d"}
{"url":"https://forum.openzeppelin.com/t/guide-to-using-create2-sol-library-in-openzeppelin-contracts-2-5-to-deploy-a-vault-contract/2268/1","domain":"forum.openzeppelin.com","title":"Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract - Smart Contracts / Guides and Tutorials - OpenZeppelin Forum","text":"Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract \n\n Smart ContractsGuides and Tutorials\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n Feb 2020\n\n 1 / 6\n\n Feb 2020\n\n Mar 2025\n\n post by abcoathup on Feb 19, 2020\n\n abcoathup\n\n Great contributor\n\n Create2.sol\nCreate2.sol is a simple library for using the CREATE2 opcode, allowing for deployment and pre-computation of addresses when using it.\nTo learn more about all the cool things you can do with it, head to Getting the Most out of CREATE2\nIn this guide we will precompute the address where a contract will be deployed and send Ether to it. Then, we’ll deploy a contract to that same address, and use it to retrieve the funds previously sent there. (This is based on the guide Deploying Smart Contracts Using CREATE2 and the OpenZeppelin CLI )\nThanks to @k06a for requesting an example.\nCREATE2\nThe whole idea behind this opcode is to make the resulting address independent of future events. Regardless of what may happen on the blockchain, it will always be possible to deploy the contract at the precomputed address.\nNew addresses are a function of:\n\n0xFF, a constant that prevents collisions with CREATE\n\nThe sender’s own address\nA salt (an arbitrary value provided by the sender)\nThe to-be-deployed contract’s bytecode\n\nnew_address = hash(0xFF, sender, salt, bytecode)\n\nCREATE2 guarantees that if sender ever deploys bytecode using CREATE2 and the provided salt, it will be stored in new_address.\nBecause bytecode is included in this computation other agents can rely on the fact that, if a contract is ever deployed to new_address, it will be one they know about. This is the key concept behind counterfactual deployments.\nDeploy VaultFactory\nWe will use Remix to deploy and interacts with our contracts. (OpenZeppelin CLI 2.8 is planned to support deployment of regular contracts)\nWe will compute the address where Vault will be deployed, and send Ether there. Then, we will deploy Vault using VaultFactory which uses Create2.sol and finally call the withdraw method, retrieving the funds that were sent to it before deployment.\nFirst create the Vault.sol and VaultFactory.sol contracts in Remix.\nNext deploy VaultFactory.sol to a test network. (Either a VM or a public testnet, for this guide I will use public testnet Rinkeby)\nMy VaultFactory contract on Rinkeby:\nhttps://rinkeby.etherscan.io/address/0xfea3f16aecd00a080403149fc5dd804494255657#code\nVault.sol\npragma solidity ^0.5.0;\n\nimport \"https://github.com/OpenZeppelin/openzeppelin-sdk/blob/v2.7.1/packages/lib/contracts/Initializable.sol\";\n\ncontract Vault is Initializable {\n address payable public owner;\n\n function initialize(address payable _owner) initializer public {\n owner = _owner;\n }\n\n function withdraw() public {\n require(owner == msg.sender);\n owner.transfer(address(this).balance);\n }\n}\n\nVaultFactory.sol\npragma solidity ^0.5.0;\n\nimport \"./Vault.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/utils/Create2.sol\";\nimport \"https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.0/contracts/utils/Address.sol\";\n\ncontract VaultFactory {\n event VaultCreated(address vault);\n\n function deployVault(bytes32 salt, address payable owner) public {\n address vaultAddress;\n\n vaultAddress = Create2.deploy(salt, type(Vault).creationCode);\n Vault(vaultAddress).initialize(owner);\n\n emit VaultCreated(vaultAddress);\n }\n\n function computeAddress(bytes32 salt) public view returns (address) {\n return Create2.computeAddress(salt, type(Vault).creationCode);\n }\n\n function sendValue(bytes32 salt) external payable {\n address vaultAddress;\n\n vaultAddress = Create2.computeAddress(salt, type(Vault).creationCode);\n\n Address.sendValue(Address.toPayable(vaultAddress), msg.value); \n }\n}\n\nComputing the Deployment Address\nWith VaultFactory deployed, we can get the factory to compute the address where our Vault contracts will be deployed using an arbitrary salt by calling computeAddress with a salt such as 0x0000000000000000000000000000000000000000000000000000000000000001\nWhich for my deployed VaultFactory gives an address of 0x262245f12519e61278A2d013721A6310661B6Cad\nInteracting With the Counterfactual Contract\nUnder normal circumstances, sending funds to a random Ethereum address is a bad idea. Here however, we know we’ll be able to deploy Vault at the computed address and retrieve our funds. So let’s do it!\nSend some (test) Ether to the address that we got from computeAddress.\nI am going to use sendValue function on VaultFactory (mainly because I couldn’t see an easy way to send value to an address using Remix when using a VM).\nIn the transaction we can see that the address had 0.1 Ether sent to it.\nhttps://rinkeby.etherscan.io/tx/0x01f28c4ca280b239ad2e923752142c2d71abaa2555f6468e8b5a8b21f420a3d6#statechange\nBecause the address has no bytecode and we don’t have its private keys, we cannot do much with it other than checking the funds are indeed there.\nNext up is to get the funds out of the vault.\nWithdrawing From Our Vault\n\nFirst we need to deploy our Vault.\nUse Remix to call deployVault on VaultFactory using the same salt as before and the owner of the Vault who can withdraw funds.\nThe transaction deploying our Vault:\nhttps://rinkeby.etherscan.io/tx/0x14c7be217ab27a0adb4ef0263d6271da7c351a8f2275e4a133a35fd912a5ec95\nIf all went well, we should now be able to withdraw from our Vault.\nUsing Remix, show our Vault contract using atAddress so that we can interact with it.\nThen call withdraw which will send the funds to the owner of the Vault\nThe withdraw transaction showing the change in Ether:\nhttps://rinkeby.etherscan.io/tx/0x5919cef5a5a5e4a8932d20ac06d6ae2148ede459650492f91a1f8ff8965a0d46#statechange\nSuccess! Just to be sure, let’s verify the Vault is indeed empty:\nhttps://rinkeby.etherscan.io/address/0x262245f12519e61278A2d013721A6310661B6Cad\nWe’ve sent funds to an address we precomputed, knowing we’d be later able to deploy a contract there and retrieve them.\n\n Relay - multiple (derived) keys/addresses\n\n Discussion on OpenZeppelin Contracts 2.5 Create2.sol\n\n 3\n\n post by abcoathup on Feb 16, 2020\n\n post by MicahZoltu on Feb 19, 2020\n\n post by abcoathup on Feb 19, 2020\n\n 4 years later\n\n post by makoto on Oct 5, 2023\n\n 1 year later\n\n post by Ant_Crypto on Mar 17, 2025\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Discussion on OpenZeppelin Contracts 2.5 Create2.sol\n\n General\n\n 4\n\n 1.9k\n\n Mar 2020\n\n Create2: Failed on deploy when using Create2 library\n\n Contracts\n\n 2\n\n 2.8k\n\n Jul 2020\n\n How to generate the addresses before the contract is implemented?\n\n Contracts\n\n bep20\n\n 3\n\n 1.3k\n\n Oct 2021\n\n Getting the most out of CREATE2\n\n Guides and Tutorials\n\n 0\n\n 2.0k\n\n Jun 2019\n\n How to use a CREATE2 deployer\n\n General\n\n 7\n\n 2.1k\n\n Jun 2021","tokens":1719,"squid":"ink-security_audits","role":"Sentinel","at":1791268168422,"hash":"203a34e8c424dc369e40bc7fd802f10d4c19c53b"}
{"url":"https://governance.aave.com/t/ethena-usde-on-aave-avalanche-assessments/25669/1","domain":"governance.aave.com","title":"Ethena USDe on Aave Avalanche Assessments - Risk / Assessments - Aave","text":"Ethena USDe on Aave Avalanche Assessments \n\n RiskAssessments\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Sep 18\n\n 1 / 2\n\n Sep 19\n\n Sep 18\n\n post by LlamaRisk on Sep 18\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n This thread is the home for all risk and technical assessments of USDe on Aave Avalanche.\nIt collects, in one place:\n\nThe pre-listing asset risk assessment, under the Aave Risk Framework.\nThe pre-listing technical asset assessment, under the Technical Asset Listing Framework.\nAll post-listing monitoring reports, periodic refresh assessments, and any re-evaluations triggered by material changes.\n\nNew assessments and updates will be posted as replies below as they are produced, so the full history stays in a single thread.\n\n read \n\n 10\n min\n\n post by LlamaRisk on Sep 18\n\n LlamaRisk\n\n LlamaRisk-Risk SP\n\n Summary\nLlamaRisk supports onboarding USDe to the Aave V4 Core Hub on Avalanche. USDe is already listed on multiple Aave markets, including V3 and V4. Native USDe minting is not available on Avalanche, and USDe is instead bridged using LayerZero’s Omnichain Fungible Token (OFT) standard, with backing escrowed on Ethereum. The USDe OFT mesh currently spans 31 networks.\nOn the access control side, the USDe OFT on Avalanche is controlled by a custom timelock controller with a 24-hour delay, which maintains a whitelist allowing certain functions to bypass the delay. Currently, setPeer is whitelisted for the Ethena 5/10 multisig, allowing it to add or remove peers from the OFT mesh without a delay. While this can serve as a plausible incident response mechanism, it could also be exploited by an attacker-controlled address on a chain where the OFT has been compromised. A separate pauser mechanism for incident response currently doesn’t exist. Timelock coverage is absent on some prominent networks in the mesh, with Ethena working to extend coverage over the next few weeks.\nUSDe DEX liquidity on Avalanche is concentrated in a single Uniswap V3 USDe/USDC pool with approximately $0.5M in TVL, which is relatively low for initial liquidity. Thus, we’re proposing conservative initial caps. Given recent changes to the USDe IRM, particularly the base rate increase, borrowing USDe at current rates is unattractive. We therefore recommend onboarding USDe as a collateral-only reserve on Avalanche, with borrowing disabled.\n1. Asset Fundamental Characteristics\n1.1 Asset\nUSDe is a dollar-pegged synthetic stablecoin issued by Ethena Labs, backed by a diversified portfolio spanning liquid assets, institutional lending, RWA, DeFi lending, and delta-neutral strategies. It is not a fiat-redeemable stablecoin and does not represent a deposit claim. It is a claim on a diversified portfolio of yield-generating positions managed by the issuer, with a stability mechanism resting on primary-market arbitrage by whitelisted counterparties rather than on a statutory redemption right.\nUnder the Aave asset classification framework, USDe is a USD-pegged asset classified as a strategy-backed instrument. Holding USDe alone accrues no yield. Yield accrues to sUSDe, the ERC-4626 vault share obtained by staking USDe.\nUSDe on Avalanche is deployed as a LayerZero OFT similar to other chains in the mesh.\n1.2 Architecture\nEthereum\nDirect minting and redemption remain restricted to counterparties that have cleared KYC/KYB checks with Ethena. An approved counterparty transfers an accepted reserve asset and receives USDe in the same transaction, and burns USDe to receive backing assets on the same basis. There is no queue and no epoch: settlement for approved counterparties is atomic.\nThe mint and redeem contract on Ethereum exposes per-block maximum mint and redeem parameters, as well as a disableMintRedeem function. Both addWhitelistedBenefactor and disableMintRedeem are on the Ethereum timelock’s bypass whitelist, meaning the issuer can suspend primary minting and redemption without waiting out the 24-hour delay.\nExtensive analysis of the core architecture has been conducted in prior assessments that detail their underlying design and risk considerations, including: Asset Risk Assessment: Ethena USDe, Addendum to Asset Risk Assessment: Ethena USDe, and Onboard USDe to Aave V3 on Ethereum.\nAvalanche\nUSDe on Avalanche cannot be minted natively and is bridged exclusively through LayerZero V2. On Ethereum, an OFT Adapter escrows canonical USDe. On Avalanche, the OFT mints and burns against LayerZero messages. The Ethereum adapter currently escrows 1.95B USDe.\nThe Avalanche OFT has a peer configured for Ethereum only. No other pathway is peered, so every inbound and outbound transfer must route through Ethereum. Disruption of the Ethereum pathway leaves no alternative route. Bridge and verifier configuration for Ethereum to Avalanche:\n\nDirection\nRequired DVNs\nOptional DVNs (threshold)\nBlock confirmations\nSend library\nReceive library\nInherits LZ default receive library\n\nEthereum to Avalanche\nLayerZero Labs, Canary\nHorizen, Nethermind, StablecoinX (2 of 3)\n15\n0xbB2E…dCe1\n0xc02A…24C2\nNo\n\nAvalanche to Ethereum\nLayerZero Labs, Canary\nHorizen, Nethermind, StablecoinX (2 of 3)\n12\n0x197D…558a\n0xbf35…2c61\nNo\n\nEffective verification is 4 signatures from 5 distinct providers in each direction. The configuration is symmetric and, in both directions, the OApp pins its own receive library rather than inheriting LayerZero’s mutable default. The executor in both directions is LayerZero Labs’ standard executor.\nRate Limits: The Ethereum to Avalanche and Avalanche to Ethereum lanes are both configured at 10,000,000 USDe per 1 hour window. At the current Avalanche supply of 5,769,127 USDe, a single window’s outbound capacity is approximately 1.7 times the entire local supply, so the rate limit is not a binding constraint on an exit from Avalanche.\n1.3 Backing and Reserve Analysis\nTotal backing stands at $4.50B against 4.51B USDe outstanding, representing a 0.9973 coverage ratio before the reserve fund. Including the $62.09M reserve fund brings total coverage to approximately 1.011x. The backing composition has changed majorly from our prior assessments. Delta-neutral perpetual basis, once the entirety of the backing, is now 13.4% of it. The portfolio weight has shifted to new categories including RWA, institutional lending and existing strategies like DeFi Lending, subject to Ethena governance.\nimage2054×1035 173 KB\nSource: LlamaRisk, September 14, 2026\nThe dominant exposures are now credit risk on institutional borrowers, smart-contract and liquidation risk in DeFi lending venues, issuer risk on the stablecoins held as liquid balances, and manager and valuation risk on the RWA sleeve.\nThe asset-level series available from Ethena shows liquid cash rising to dominate the portfolio through 2026, with BTC and ETH balances (the crypto basis collateral) reduced to $293.0M and $281.1M respectively.\nimage2054×1035 206 KB\nSource: LlamaRisk, September 14, 2026\nEthena publishes backing at the position level, with the asset, chain, holding wallet, curator or custodian for each position. The tables below map each strategy sleeve. Shares are of total backing of $4.6B.\nCrypto Basis\n\nExchange\nAssets\nCustodian\nExposure\nShare of backing\n\nBinance\nBTC $205.6M, ETH $129.2M, SOL $20.5M, BNB $6.0M\nCeffu\n$361,357,082\n7.9%\n\nOKX\nETH $85.2M, BTC $72.1M\nCopper\n$157,316,071\n3.4%\n\nBybit\nETH $58.7M, BTC $1.6M\nCopper\n$60,302,014\n1.3%\n\nCoinbase INTX\nBTC $11.5M, ETH $9.9M\nCopper\n$21,477,984\n0.5%\n\nTotal\n\n$600,453,151\n13.0%\n\nCrypto basis collateral is not held on the exchanges themselves. It sits with an off-exchange settlement custodian and is mirrored to the exchange as margin, which is designed so that an exchange failure costs the hedge rather than the collateral. The custodian dependency this creates is covered in Section 3.5.\nDeFi lending\nUSDe’s backing includes $806.9M supplied into Aave V3 and V4, 17.5% of total backing, and Aave V3 alone, at $781.8M or 17.0%, is the single largest counterparty.\n\nProtocol\nAsset\nChain\nExposure\nShare of backing\nHolding wallet\n\nAave V3\nUSDT0\nPlasma\n$285,862,753\n6.2%\n0xb873…313c\n\nUSDT\nEthereum\n$210,055,322\n4.6%\n0xb873…313c\n\nRLUSD\nEthereum\n$151,841,776\n3.3%\n0xb873…313c\n\nUSDT0\nMantle\n$133,996,475\n2.9%\n0xb873…313c\n\nAave V4\nUSDT0\nMonad\n$19,230,967\n0.4%\n0xb873…313c\n\nUSDT\nEthereum\n$2,958,184\n0.1%\n0xb873…313c\n\nUSDC\nEthereum\n$2,958,184\n0.1%\n0xb873…313c\n\nMorpho, Jupiter Lend, and Kamino positions sit in curated vaults or isolated markets whose risk parameters are set by the named curator.\n\nProtocol\nAsset\nCurator\nChain\nExposure\nShare of backing\nHolding wallet\n\nMorpho\nPYUSD\nSentora\nEthereum\n$150,182,173\n3.3%\n0x2bf5…f67c\n\nUSDC\nGauntlet\nBase\n$75,046,466\n1.6%\n0x2bf5…f67c\n\nUSDC\nSteakhouse\nBase\n$60,821,257\n1.3%\n0x2bf5…f67c\n\nUSDC\nSteakhouse\nBase\n$30,585,278\n0.7%\n0x2bf5…f67c\n\nUSDG\nSteakhouse\nEthereum\n$23,555,139\n0.5%\n0x2bf5…f67c\n\nUSDtb\nSteakhouse\nEthereum\n$1,734,870\n0.0%\n0x2bf5…f67c\n\nJupiter Lend\nUSDG\nBitwise\nSolana\n$253,121,863\n5.5%\nC23F…H34L\n\nKamino\nPYUSD\nSentora\nSolana\n$249,984,435\n5.4%\nC23F…H34L\n\nTotal\n\n$1,651,935,142\n35.9%\n\nInstitutional lending\nEthena publishes a holding wallet for the Maple position and Bitcoin addresses for CBAM, and no address for FalconX, Kraken, or Anchorage, so those three are verifiable only through attestation. The failure impact of these strategies is default on the underlying institutional loans, with recovery dependent on borrower collateral.\n\nBorrower or platform\nExposure\nShare of backing\nPublished address\n\nMaple Institutional\n$302,941,604\n6.6%\n0xb873…313c\n\nFalconX\n$124,145,320\n2.7%\nNot published\n\nKraken\n$75,000,000\n1.6%\nNot published\n\nCBAM\n$5,000,000\n0.1%\n3LWi…d6C9, 3AYo…mjKx, 35Zs…zAXk\n\nAnchorage\n$1,000,000\n0.0%\nNot published\n\nTotal\n$508,086,924\n11.0%\n\nReal-world assets\nBoth funds hold AAA-rated CLO tranches. Their value is set by fund NAV rather than by an on-chain market price, so the failure modes are mark-to-market impairment of the tranches and redemption gating at the fund level. STAC’s underlying assets are custodied at BNY.\n\nAsset\nFund\nManager\nChain\nExposure\nShare of backing\nHolding address\n\nSTAC\nSecuritize Tokenized AAA CLO Fund\nSecuritize Capital, sub-advised by BNY Investments\nSolana\n$253,013,814\n5.5%\n4FaQ…rbtN\n\nJAAA\nJanus Henderson Anemoy AAA CLO Fund\nJanus Henderson, tokenized by Centrifuge\nSolana\n$202,296,550\n4.4%\n4FaQ…rbtN\n\nBase\n$50,574,137\n1.1%\n0x2d4d…7bb4\n\nTotal\n\n$505,884,501\n11.0%\n\nLiquid stablecoins\nEthena publishes five Ethereum wallets for these balances, 0x2d4d…7bb4, 0x1c3b…c337, 0x6cd5…c4b5, 0xafbb…2a62, and EthenaMinting, together with a custodial omnibus account whose custodian and share are not disclosed.\n\nAsset\nChain\nHeld in\nExposure\nShare of backing\n\nPYUSD\nEthereum\nEthena wallets and a custodial omnibus account\n$575,861,601\n12.5%\n\nRLUSD\nXRPL\nCopper\n$300,000,000\n6.5%\n\nUSDC\nEthereum\nEthena wallets and a custodial omnibus account\n$231,320,784\n5.0%\n\nUSDT\nEthereum\nEthena wallets and a custodial omnibus account\n$115,457,819\n2.5%\n\nUSDtb\nEthereum\nEthena wallets and a custodial omnibus account\n$90,787,120\n2.0%\n\nUSDG\nRobinhood\nEthena wallets and a custodial omnibus account\n$20,091,817\n0.4%\n\nUSDG\nEthereum\nNot published\n$1,499,938\n0.0%\n\nTotal\n\n$1,335,019,079\n29.0%\n\nPYUSD at 12.5% of backing, the largest stablecoin exposure and larger than any single hedging venue. USDe’s backing depends more on PayPal USD holding its peg than on any one exchange.\n1.3.1 Reserve fund\nThe reserve fund, held in a 4-of-10 Safe, stands at $62,081,856, equal to 1.35% of USDe underlying supply. Ethena’s documentation states that the share of protocol revenue allocated to the reserve fund is currently 0%, with 100% directed to incentive rewards, promotional distributions, and distribution incentives. The fund’s adequacy is a function of supply. Should supply return toward October 2025 peak levels without a change to the revenue allocation, coverage would fall to 0.42% correspondingly.\n1.3.2 Proof of reserves\nEthena publishes position-level backing data through its transparency dashboard, providing asset-level attribution of counterparties, custodians, and venues. Custodian attestations are published separately by Ethena Labs, HT Digital, LlamaRisk, and Chainlink. LlamaRisk independently attests to Ethena’s proof-of-reserves solution, with the corresponding PoR reports available here.\n1.4 Tokenomics\nAs of September 14, 2026, the USDe on-chain supply on Avalanche is 5.77M. This supply fluctuates depending upon bridged transfers from Ethereum via LayerZero.\n1.4.1 Token Holder Concentration\nimage811×249 20.9 KB\nSource: USDe Top 100 holders on Avalanche, Snowscan, September 14, 2026\nThe five top holders are as follows:\n\nContract1: 17.34% of the supply.\nContract2: 17.32% of the supply.\nEOA: 9.52% of the supply.\nUniswap V3 USDe/USDC Pool: 6.56% of the supply.\nContract3: 5.79% of the supply.\n\nNinety of the top 100 holders holding 71.78% share of USDe Avalanche supply are byte-identical proxies resolving to a single upgradeable beacon at 0xc831…8448, whose implementation and deployer are common across all of them.\n2. Market Risk\n2.1 Liquidity\nimage978×546 49.2 KB\nSource: DeFiLlama, September 14, 2026\nUsers can swap 132K USDe for USDC within a price impact of 7.5% on Avalanche.\n2.1.1 Liquidity Venue Concentration\nimage923×129 22.6 KB\nSource: GeckoTerminal, September 14, 2026\nUSDe DEX liquidity on Avalanche is concentrated in a single venue: Uniswap V3 USDe/USDC pool with $0.5M TVL, which is relatively low.\n2.1.2 DEX LP Concentration\nLiquidity in the Uniswap V3 USDe/USDC pool is highly concentrated, with a single EOA providing all of the liquidity. If this entity withdraws its position, USDe exit liquidity could become severely constrained, creating a liquidity crunch.\n2.2 Volatility and Peg History\nimage1754×889 37.8 KB\nSource: LlamaRisk, September 14, 2026\nSince the deployment of the Uniswap USDe/USDC pool, no sustained deviations from the peg have been observed. However, the peg deviation exceeded 150 bps on three occasions. As pool liquidity continues to deepen, the frequency and magnitude of such deviations are expected to decline, consistent with the improvement observed over the past month.\n2.3 Exchanges\nimage1200×340 53.8 KB\nSource: Coingecko, September 14, 2026\nUSDe is actively traded on centralized exchanges, including Binance and Bybit, with approximately $10M in sell-side liquidity available within a 2% price impact.\n2.4 Growth\nimage2052×1036 183 KB\nSource: LlamaRisk, September 14, 2026\nAggregate USDe supply is 4.61B, approximately 31% of the October 3, 2025 peak of 14.82B. The contraction is attributable to the October 2025 deleveraging event and to the subsequent compression in perpetual funding, which removed the yield differential that had drawn capital into sUSDe. On Avalanche, however, USDe supply remains above its October peak, currently standing at $5.78M. Current inflows are primarily dependent on cross-chain transfers from Ethereum via LayerZero.\n2.5 Oracle and Price Feed Treatment\nimage1792×1158 205 KB\nSource: LlamaRisk, September 14, 2026\nAave prices USDe using a capped oracle on the underlying USDT/USD feed categorized by Chainlink as low market risk, rather than the USDe/USD feed, which carries a medium market-risk classification and has experienced significant deviations from the peg on two separate occasions.\n\nEvent\nFeed low\nDeviation\nContext\n\nFebruary 21, 2025, 15:45 UTC\n$0.97721\n-228 bps\nBybit security incident\n\nOctober 10, 2025, 23:04 UTC\n$0.99294\n-71 bps\nMarket-wide deleveraging\n\nGiven the likelihood of such events occurring and the higher risk classification of the USDe/USD feed, we recommend maintaining the current price feed configuration.\n3. Smart Contract Security\n3.1 Architecture and Access Controls\n3.1.1 Contract Modification Options\nThe following contracts power USDe on Avalanche:\n\nENAOFT: Immutable ERC20 contract for the USDe token, controlled by EthenaTimelockController.\nLayerZero EndpointV2: Immutable contract, serves as the primary entry point responsible for managing cross-chain communications. It is controlled by LayerZero 5/7 threshold OneSig.\nSendUln302: Immutable contract, an Ultra Light Node (ULN) message library used for sending cross-chain messages. It is controlled by LayerZero 5/7 threshold OneSig.\nReceiveUln302: Immutable contract, a message library for receiving cross-chain messages. It is controlled by LayerZero 5/7 threshold OneSig.\n\nThe sensitive functions exposed by Avalanche USDe OFT:\n\nFunction\nCaller\nModifier\nEffective delay\n\nsetPeer\nEthenaTimelockController, via whitelisted executor (Ethena Multisig)\nonlyOwner\nNone\n\nsetRateLimits\nEthenaTimelockController\nonlyOwner or rate limiter\n24 hours\n\nsetRateLimiter\nEthenaTimelockController\nonlyOwner\n24 hours\n\nsetDelegate\nEthenaTimelockController\nonlyOwner\n24 hours\n\nsetEnforcedOptions\nEthenaTimelockController\nonlyOwner\n24 hours\n\nsetMsgInspector\nEthenaTimelockController\nonlyOwner\n24 hours\n\ntransferOwnership\nEthenaTimelockController\nonlyOwner, 2-step\n24 hours\n\nsend\nAny holder\nnone\nN/A\n\nThese are the USDe controlling wallets on Avalanche:\n\nEthena Multisig: 5/10 Safe multisig, admin of the timelock controller and can execute setPeer function bypassing the timelock.\nEthenaTimelockController: 24-hour RBAC timelock controlled by Ethena, handles USDe OFT wide admin functions.\n\n3.1.2 Timelock Duration and Function\nUSDe on Avalanche is owned by EthenaTimelockController with minDelay of 86,400 seconds (24 hours). However, this contract extends OZ’s TimelockController with a function-level whitelist. A holder of WHITELISTED_EXECUTOR_ROLE may call a function with no delay. Entries are added and removed by addToWhitelist and removeFromWhitelist, both of which are restricted to the timelock itself and therefore require a full 24 hour delay to take effect.\nOn Avalanche, the timelock’s only instant-effect authority over USDe is setPeer. Setting a peer to zero immediately severs a bridging pathway, which is a plausible incident-response action. However, the same authority can add or repoint a peer without delay, which presents a risk because peer mapping is the only authentication check applied to inbound messages.\nAvalanche’s OFT enforces rate limits only on outbound transfers, as do all Ethena deployments except Tempo. While Tempo’s adapter supports inbound rate limits, its only active lane currently has no limit. Consequently, a peer could be repointed to a contract outside Ethena’s control with no effective rate limit on either side, leaving the amount that could be minted on Avalanche effectively uncapped. The 5-of-10 Ethena Safe is the sole authority over this change. A separate pauser mechanism for incident response currently doesn’t exist.\nEverything else, including setRateLimits, setDelegate, transferOwnership, and the LayerZero library and DVN configuration, requires the full 24 hour delay on Avalanche.\n3.1.3 Multisig Threshold / Signer identity\nEthena Multisig (5/10 Safe) is the admin of the EthenaTimelockController contract and has the following role-based access control:\n\nRole\nAssigned addresses\nFunctionality\n\nDEFAULT_ADMIN_ROLE\nEthenaTimelockController\nGrant and revoke roles. Self-administered, so any role change must itself pass the 24 hour delay.\n\nPROPOSER_ROLE\nEthena Multisig\nSchedule operations, which then wait 24 hours.\n\nCANCELLER_ROLE\nEthena Multisig\nCancel a scheduled operation before execution.\n\nEXECUTOR_ROLE\nEOA A, Multisig B, Ethena Multisig\nExecute an operation once its delay has elapsed. Cannot schedule.\n\nWHITELISTED_EXECUTOR_ROLE\nEthena Multisig\nExecute a pre-whitelisted function with no delay.\n\n3.2 Multi-Chain Evaluation Scope\nUSDe is registered at 32 LayerZero V2 endpoints, of which 29 are EVM chains and three are non-EVM (Solana, Aptos, TON). Ethereum is the canonical chain and holds the OFT Adapter. Every other endpoint runs a mint-and-burn OFT.\nimage1920×1843 410 KB\nSource: LlamaRisk, September 14, 2026\nThe peered lanes all route through Ethereum, with outbound lanes connecting it to 29 of the 30 networks in the mesh. Swell is the sole exception and remains disconnected from all peers. Zircuit, Swell, zkSync, Scroll, Manta, Mode, Metis, and Kava appear to be marked for deprecation, with all inbound rate limits set to zero.\nOwnership\nOf the 32 networks in the mesh, 13 are controlled by an EthenaTimelockController, each with the same 24-hour minimum delay: Ethereum, Base, Robinhood, Monad, BNB Chain, HyperEVM, Avalanche, Arbitrum, MegaETH, Ink, Optimism, Linea, and Scroll.\nThe remaining 19 networks are controlled directly by multisigs, primarily 5/10 Safes on EVM chains, without timelock protection. Among these, Solana has the largest USDe OFT balance at 531M, controlled by a 4/10 Squads multisig with no timelock, followed by Plasma at 380.9M, TON at 171.8M under a 5/11 multisig, and Mantle at 60.3M. Berachain (11.9M) and Blast (0.93M) also remain under untimelocked ownership.\nEthena is working to extend timelock coverage to the remaining networks over the next couple of weeks, with deprecation planned for some networks by year-end.\n3.3 Audit Coverage\nEthena’s core protocol contracts (USDe, minting) have been audited by multiple firms including Zellic (July 2023) and others listed on Ethena’s audits page. The LayerZero OApp/OFT framework used for cross-chain bridging was separately audited by Zellic (September 2025). The Avalanche-specific OFT deployment uses the same audited codebase but has not received a chain-specific audit.\n3.4 Bug Bounty Program\n\nEthena: Maximum bounty of $3M via Immunefi for critical smart contract vulnerabilities (10% of affected funds, minimum $100k).\nLayerZero: Maximum bounty of $15M via Immunefi for critical smart contract vulnerabilities. However, OFT-related contract impacts are classified as low severity with a maximum payout of $10,000.\n\n3.5 Dependency Risk\nBridge and messaging\n\nDependency\nRole\nAuthority\nFailure impact\n\nLayerZero V2 Endpoint\nMessage transport\nRoutes verified messages to the OFT\nBridging halts in both directions.\n\nLayerZero Labs DVN\nRequired verifier\nMust sign every message\nBridging halts. Cannot forge alone.\n\nCanary DVN\nRequired verifier\nMust sign every message\nBridging halts. Cannot forge alone.\n\nHorizen, Nethermind, StablecoinX DVNs\nOptional verifiers, 2 of 3\nTwo must sign\nBridging halts if two of the three are unavailable.\n\nLayerZero Labs Executor\nDelivers verified messages\nCalls lzReceive on the destination\nMessages verify but do not deliver until an alternative executor is used.\n\nEthereum OFT Adapter\nEscrow\nHolds 2.03B USDe backing all bridged supply\nEscrow compromise breaks the backing of every bridged USDe including Avalanche.\n\nStrategy risk\nBeyond the bridge, USDe depends on four layers of third parties through its backing: the managers who run each strategy, the protocols the capital is deployed into, the chains those protocols run on, and the custodians holding off-chain collateral. Position-level detail is in the strategy tables in Section 1.3.\nOutside Aave, all DeFi lending exposure is managed by a third-party curator that sets each market’s risk parameters, collateral rules, and allocation, rather than by Ethena directly. Institutional and RWA exposure is likewise delegated to a lending platform or a fund manager. Sentora is the largest curator at $400.2M (8.7% of backing), across a Morpho PYUSD vault on Ethereum and an isolated Kamino PYUSD pool on Solana, so a single curator’s risk decisions reach two protocols on two chains. Aave supply ($806.9M) is not curator-managed, and its risk sits at the protocol level. CBAM ($5.0M) and Anchorage ($1.0M) complete the institutional book.\nProtocol risk\n35.9% of USDe backing sits in five lending protocols, and Aave (V3 & V4) accounts for 17.5%, across its Ethereum, Plasma, and Mantle markets. Morpho, Jupiter Lend, and Kamino positions sit in curated vaults or isolated markets, which confine a loss to the market concerned but place its parameters with the curator.\nChain risk\nOn-chain backing of $3,492.8M (75.9%) is spread across eight networks. Ethereum holds $1,558.2M (33.9%) and Solana $958.4M (20.8%), the latter concentrating two lending markets and both RWA funds. USDT0 positions on Mantle, Monad, and Plasma total $439.1M (9.5%) and depend on the USDT0 bridge as well as on the chain. Plasma carries both an Aave position and the largest USDe OFT balance still under untimelocked ownership (379,381,434 USDe, Section 3.2). The remaining $600.5M of crypto basis collateral and $508.1M of institutional loans sit off-chain.\n\nChain\nAllocations\nExposure\nShare of backing\n\nEthereum\nLiquid stablecoins, Aave V3 and V4, Morpho\n$1,558,212,910\n33.9%\n\nSolana\nJupiter Lend, Kamino, STAC, JAAA\n$958,416,662\n20.8%\n\nXRPL\nRLUSD, custodied at Copper\n$300,000,000\n6.5%\n\nPlasma\nUSDT0 supplied to Aave V3\n$285,862,753\n6.2%\n\nBase\nMorpho USDC vaults, JAAA\n$217,027,138\n4.7%\n\nMantle\nUSDT0 supplied to Aave V3\n$133,996,475\n2.9%\n\nRobinhood\nUSDG\n$20,091,817\n0.4%\n\nMonad\nUSDT0 supplied to Aave V4\n$19,230,967\n0.4%\n\nAave is already deployed on Ethereum, Plasma, Base, Mantle, and Monad, all of which were assessed in depth as part of their respective onboarding processes. Solana, XRPL, and Robinhood, however, have not yet undergone a comparable assessment.\nCustodian risk\nCustodied backing totals $900.5M (19.6%) across two named custodians. Copper holds $539.1M, of which $239.1M is exchange collateral for OKX, Bybit, and Coinbase INTX under off-exchange settlement and $300.0M is RLUSD on XRPL, and STAC’s underlying assets are custodied at BNY. Ceffu holds the $361.4M of Binance collateral. Off-exchange settlement keeps collateral off exchange balance sheets, which moves the dependency from the exchange to the custodian rather than removing it.\n4. Regulatory Risk\nRegulatory risks associated with USDe were assessed in previous reviews, with no material changes identified. Accordingly, they are omitted from this report for brevity.\nDisclaimer\nThis review was independently prepared by LlamaRisk, a community-led decentralized organization funded in part by the Aave DAO. LlamaRisk serves as an independent attestor of Ethena’s PoR solution. LlamaRisk did not receive compensation from the protocol(s) or their affiliated entities for this work.\nThe information provided should not be construed as legal, financial, tax, or professional advice.\n\n [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\n\n LlamaRisk - Monthly Community Update\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n [Direct to AIP] Onboard USDe to Aave V4 Core Instance on Avalanche\n\n New Asset\n\n 1\n\n 223\n\n Sep 18\n\n USDe (USDe) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 148\n\n Jul 1\n\n [Direct-to-AIP] Onboard USDe to the Aave V3 MegaETH Instance\n\n New Asset\n\n 5\n\n 752\n\n Apr 20\n\n [Direct to AIP] Onboard sUSDe and USDe to Aave V3 Avalanche Instance\n\n Governance\n\n 2\n\n 548\n\n Sep 2025\n\n Staked USDe (sUSDe) on Aave Monad Assessments\n\n Assessments\n\n 1\n\n 97\n\n Jul 1","tokens":6731,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268185201,"hash":"d5e2dcd2748bc1ba4e598ebbe9070d688ab00f0f"}
{"url":"https://docs.optimism.io/app-developers/tools-sdks/block-explorers","domain":"docs.optimism.io","title":"Optimism Documentation","text":"​Blockscout\nWe have a Blockscout explorer for OP Mainnet and OP Sepolia. It includes:\n\nVerified testnet contract source code, along with the ability to interact with it\nDetailed testnet transaction information\n\nBlockscout also has some OP-Mainnet-specific features:\n\nAn interactive list of deposits (L1-L2)\nAn interactive list of withdrawals (L2-L1)\nTransaction batches\nApp marketplace\nAnd much more!\n\n​Etherscan\nWe have Etherscan explorers for the OP Mainnet and the OP Sepolia.\nEtherscan has lots of tools to help you debug transactions.\nOptimistic Etherscan has all the tools you expect from Etherscan, such as:\n\nVerified contract source code, along with the ability to interact with it\nDetailed transaction information\nAnd everything else you might find on Etherscan!\n\nIt’s also got some OP-Mainnet-specific features:\n\nA list of L1-to-L2 transactions\nA list of L2-to-L1 transactions\nA tool for finalizing L2-to-L1 transactions\nAnd more! Just check it out and click around to find all of the available features.\n\n​Superscan by Routescan\nSuperscan is the dev-focused OP Stack explorer unified at the ecosystem level, powered by Routescan. On the Superscan, developers can quickly glance at transactions, blocks, addresses, deployed contracts and more across OP Stack chains in unified pages.\nThe Superscan currently includes:\n\nMainnet - OP Mainnet, Base, Zora, Mode, Cyber, Orderly, Fraxtal, Public Goods Network\nTestnet - Zora, Mode, Orderly, Fraxtal\n\n​Tenderly\nTenderly’s Developer Explorer for OP Mainnet and OP Sepolia allows you to monitor and inspect transactions, providing a high level of detail and additional tools:\nTenderly Developer Explorer lets you:\n\nKeep track of specific contracts and their transactions\nInspect transaction execution with fully decoded transaction trace\nDebug failing and simulate correct transactions before sending them on-chain\nEvaluate function-level gas usage for any transaction\nSet up Alerts to monitor interactions, access control, asset transfers, and contracts’ state changes\nCreate a Virtual TestNet from a specific OP Mainnet or OP Chain transaction for systematic research\n\n​Access to pre-regenesis history\nBecause of our final regenesis on 11 November 2021, older transactions are not part of the current blockchain and do not appear on Etherscan.\nHowever, you can access transaction history between 23 June 2021 and the final regenesis using a number of different tools. For detailed instructions, see Regenesis History.\n​Next Steps\n\nLooking for other developer tools? See the building apps overview to explore more options!\nWas this page helpful?","tokens":650,"squid":"ink-governance","role":"Council Listener","at":1791268185585,"hash":"cfaefb6aed5cc6748c3c9a0a4f597ed9f9855e76"}
{"url":"https://blog.openzeppelin.com/getting-the-most-out-of-create2/","domain":"blog.openzeppelin.com","title":"Getting the most out of CREATE2 - OpenZeppelin blog","text":"June 3, 2019Santiago PalladinoThank you for your interest in this post! We’re undergoing a rebranding process, so please excuse us if some names are out of date. Also have in mind that this post might not reference the latest version of our products. For up-to-date guides, please check our documentation site.In this post, we’ll go in depth into the CREATE2 opcode and its uses in counterfactual instantiation and user onboarding. We’ll see how we can use it in combination with different techniques, such as initializers, proxies, and meta transactions. These open the door to new flows in creating user identities, allowing us to rapidly iterate and fix any bugs even before an identity is created.Simpler timesWhen we create a contract from an externally owned account (EOA), or from a contract using the vanilla CREATE operation, the address where the contract is created is easily determined. Every account has an associated nonce: for EOAs, this nonce is increased on every transaction sent; for contract accounts, it is increased on every contract created. The address of a new contract is calculated as a function of the account’s address and its nonce:address = hash(sender, nonce)While this makes it easy for calculating the deployment address of a contract in advance, attempting to park an address is difficult. You have to make sure that no other contracts are created, so that when you actually want to deploy your contract, you can use the expected nonce. But why is parking an address interesting?Note: by “parking”, we mean reserving an address for a contract, in a similar sense to domain parking, except that we cannot choose what the address will be. We want to know where a contract will be deployed in the future, no matter what transactions we send in the meantime.CounterfactualityCounterfactual instantiation is a concept that gained popularity in the context of generalized state channels. It refers to the creation of a contract that could happen, but has not; yet the fact that it could is enough. As defined in the Counterfactual white paper:We use counterfactual X to talk about the case where:X could happen on-chain, but doesn’tThe enforcement mechanism allows any participant to unilaterally make X happenParticipants can act as though X has happenedThis implies that you need to be able to refer to contracts that have not been deployed, even though they could be created at any time. Having the ability to park an address for a contract becomes helpful, as we can refer to it before it even exists on the blockchain. As Vitalik describes in the CREATE2 proposal:Allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. Important for state-channel use cases that involve counterfactual interactions with contracts.In a state channel, this means that if all parties are honest, we do not even need to spend the gas fees to deploy the contract at all. On the other hand, if one of the parties misbehaves, the other can go on-chain and deploy the contract to the address where it was supposed to be.Though counterfactual instantiation in state channels was the original motivation for CREATE2, there is another, more earthly, use case for this new opcode.User onboardingParking an address has also become a key component in new user onboarding flows. User identity contracts, also called smart accounts, are a very interesting technique by which the user’s account is defined in a single contract that can be managed with multiple EOAs, each of them representing one of the user’s devices. This allows for 2FA or recovery flows that are traditionally impossible for EOAs without relying on a trusted, centralized third party. They also enable support for meta transactions, where they are also referred to as bouncer proxies.However, bootstrapping this identity contract can be difficult. User onboarding is already complex in Ethereum, where we are asking the user to sign up on an exchange, buy ETH using fiat or other crypto, install a browser extension or a specialized browser, create an account, write down 12 words, come up with a passphrase, extract funds from the exchange to the account, etc. Adding on top of that deploying an identity contract and moving all funds to it makes it even worse.It turns out that “parking” identity contracts solves many of these problems.Instead of having the user go through the MetaMask setup process, we can create a throwaway EOA directly in the browser, with no friction to the user. We then park an address for the identity contract and ask the user to directly fund that address from an exchange, even before the identity is created. A gas station relayer can then deploy the contract on behalf of the user, registering the ephemeral EOA to manage it. The reward for the deployment can be paid directly from the transferred funds, or even by the application itself, as part of the customer acquisition cost. Later, the user can gradually add more robust keys to their identity as they engage with the application.All in all, what we are doing here is counterfactually instantiating the user’s identity, and only creating it once funded.This is similar to the approach taken by projects with frictionless onboarding flows, such as the Burner Wallet or Universal Logins. In the words of James Young and Chris Whinfrey, who are working on an implementation of this flow as an EVM package:CREATE2 has the potential to open the design space for user on-boarding and wallet management. According this 2019 Dapp survey, over 3 quarters of developers mentioned user on-boarding was a major obstacle to adoption. Recent projects like the Burner Wallet have demonstrated alternatives along Zooko’s Triangle that ease the burden of key generation with known trade-offs in the design (it is called “burner” for a reason). CREATE2 based wallets have similar user experience goals when it comes to on-boarding. However, since funds are assumed to be held in contracts instead of keys, not only do users now have programmable access to funds, keys can now be considered disposable. Contract address generation is now as easy and as reliable as key generation. The paradox of contract deployment costs can now be addressed by only deploying a contract that holds user funds once funds have been transferred to the user’s contract address. This technique and the rationale is further explored here.Instead of forcing full decentralization on a new user, the hypothesis is that new users will more likely gravitate toward systems that are flexible and can meet a user where they are at in their journey – referred to as “incremental decentralization“. These systems prioritize user empathy and support a diversity of technical expertise, motivation and use cases. They grow with the user and expose options that are aligned with user incentives.Now that we have made our case for parking addresses, let’s see how we can implement it.Enter CREATE2CREATE2 is a new opcode introduced in the Constantinople hard fork to provide an alternative to the original CREATE. The main difference lies in how the contract’s address is calculated. Instead of depending on the account’s nonce, the new address is calculated as a hash of:the address of the creator,a salt provided as a parameter, andthe contract creation code.None of these depend on the state of the creator. This means that you can create as many other contracts as you want, without worrying about the nonce, and still be able to deploy to the parked address whenever you need to.An important detail is that the last ingredient in the calculation of the contract’s address is not its code, but its creation code. This is the code that is used to set up the contract, which then has to return its runtime bytecode. In most cases, this is the contract constructor, with its arguments, along with the contract code itself.This means that once you have settled on which contract you want to deploy and its constructor arguments, you can pick a salt value and know that it will always be deployed at the same address. This enables some interesting scenarios.CREATE2-powered factoryHaving a public factory contract that uses CREATE2, any user can share a contract (such as an identity contract), its constructor arguments, and salt, and have anyone deploy that exact contract on a predefined address.contract Factory {\n  function deploy(bytes memory code, bytes32 salt) public returns (address addr) {\n    assembly {\n      addr := create2(0, add(code, 0x20), mload(code), salt)\n      if iszero(extcodesize(addr)) { revert(0, 0) }\n    }\n  }\n}No kind of access control is needed from the user to the deployer, since the deployer is restricted to running the exact creation code provided by the user if he or she wants the deployment address to match. Also, note that the user or deployer addresses do not matter in the calculation of the contract deployment address, since the sender address used is that of the factory contract, not the user who initiated the transaction.As a side note, by this point you may have noticed that having a reproducible deployment address allows you to deploy a new contract where an old one was self-destructed. You can deploy a contract, self-destruct it, and then use the same nonce to deploy again to the same address. This opens the door for alternative upgradeabilty patterns, which are explored in depth here.While this flow is well-suited to many use cases, having to settle on a contract and its constructor arguments can be too restrictive for others. Let’s see if we can find a way around this.Constructors vs. initializersAs we mentioned before, constructors in Solidity (along with their arguments) become part of the contract creation code. This means that they will directly affect the CREATE2 deployment address.Initializers, on the other hand, are standard Solidity functions that fulfil the same role as a constructor. They are intended to initialize the contract state, and have a manual guard to ensure that they are not called more than once.contract Multisig {\n address[] owners;\n uint256 required;\n\n function initialize(address[] memory _owners, uint256 _required) public {\n require(required == 0, \"Contract has already been initialized\");\n require(_required > 0, \"At least one owner is required\");\n owners = _owners;\n required = _required;\n }\n}Since initializers are regular functions, they can be called at any time after the contract’s creation. However, they should be called immediately after, within the same transaction, to ensure no one front-runs the initialization and changes the initial values of our instance.And since they are regular functions, they are not executed within the contract creation code. This means that we can remove the constructor arguments (now initialization arguments) from the calculation of the deployment address. In other words, we can wait until deployment to choose which arguments we use to initialize our contract.This technique requires you to write contracts with initializers instead of constructors. Nevertheless, if you are using ZeppelinOS, the good news is that you are already doing so.contract Factory {\n function deploy(bytes memory code, bytes32 salt, bytes memory initdata) public returns (address addr) {\n assembly {\n addr := create2(0, add(code, 0x20), mload(code), salt)\n if iszero(extcodesize(addr)) { revert(0, 0) }\n }\n\n (bool success,) = addr.call(initdata);\n require(success);\n }\n}Now that we have deferred the choice of initialization arguments, let’s see if we can do better. Let’s try to defer the choice of the contract itself.Same old proxiesIf you’re a reader of this blog, there’s a good chance you’re already familiar with proxies. Proxies are small contracts that users interact with and which hold all the application state, but delegate every call to a logic contract that holds the business logic to execute.They are used at the core of ZeppelinOS to power seamless upgrades: a proxy holds a reference to its logic contract, but it can be changed at any time to swap the code being run by a different implementation.An interesting consequence of using proxies is that the contract code for a proxy is always the same, regardless of the logic contract that backs it. In a proxy-based system, deploying an ERC20 token, a multisig, or a Fomo3D game is exactly the same: you only need to deploy a proxy that points to the corresponding implementation.This means that if we always use the same contract code, regardless of the contract we intend to create, we will get the same deployment address from CREATE2 no matter what we deploy. We have deferred the choice of what contract we want to create at a specific address until the very time of deployment, while retaining the same initial address. Not only that, but we have also granted our users the option to upgrade their identity contracts at any time. And we have also reduced deployment costs by deploying a thin proxy instead of a full identity contract for every user.Our factory then becomes slightly more complex. It needs to first use CREATE2 to set up a new proxy, then initialize the proxy with the logic contract address, and then actually call the logic contract initializer via the proxy. However, this change grants us as much flexibility as we want.contract Factory {\n function deploy(address logic, bytes32 salt, bytes memory initdata) public returns (address addr) {\n bytes memory code = type(Proxy).creationCode;\n assembly {\n addr := create2(0, add(code, 0x20), mload(code), salt)\n if iszero(extcodesize(addr)) { revert(0, 0) }\n }\n Proxy(addr).initialize(logic);\n (bool success,) = addr.call(initdata);\n require(success);\n }\n}While adding this kind of flexibility is amusing, we have inadvertently introduced an attack vector to our factory. An attacker that learns a user’s intended salt for CREATE2 can now deploy any other contract at the destination address by calling first into deploy, providing a different logic contract or different initialization data. Let’s patch this by adding some extra ingredients to our salt.Baking in the sender addressAs mentioned before, CREATE2 uses the sender, which in this case is the factory address, to calculate the contract creation address. However, we can leverage the sender’s address to also play a role in this calculation by baking it into the salt we pass in to CREATE2.Instead of supplying the salt parameter directly to the CREATE2 operation, we can first hash it together with the caller of the deploy function. This means that only the original user will be able to call into this function and deploy into the address they had parked. Any different msg.sender would yield a different salt, and thus a different deployment address.contract Factory {\n function deploy(\n address logic, bytes32 salt, bytes memory initdata\n ) public returns (address addr) {\n bytes32 newsalt = keccak256(abi.encodePacked(salt, msg.sender)); \n bytes memory code = type(Proxy).creationCode;\n assembly {\n addr := create2(0, add(code, 0x20), mload(code), newsalt)\n if iszero(extcodesize(addr)) { revert(0, 0) }\n }\n Proxy(addr).initialize(logic);\n (bool success,) = addr.call(initdata);\n require(success);\n }\n}This is one of the implementations you will find in the new ZeppelinOS ProxyFactory released in version 2.31. You can also easily use this feature via the command line using the zos create2 command from the CLI.$ zos create2 --salt 42 --query\n> Instance using salt 42 will be deployed at 0x123456\n...\n$ zos create2 MyContract --salt 42 --init initialize\n> Instance of MyContract deployed at 0x123456However, by adding the restriction that the deployment address is calculated based on the sender, we have closed the door to meta transactions, which were one of the use cases we intended to cover. In the context of meta transactions, a user broadcasts the transaction they want to be executed, and a relay picks it up and puts it on-chain. This means that the sender address is different from the user’s, so it will not generate the expected deployment address. Luckily, we can also accommodate that.Signer, not senderOur only reason for tying the deployment address to the transaction sender address is to validate that the contract creation is done following the specs of the original user – and that no one has front-run them and inserted a creation transaction with the same salt but different parameters. However, we do not need to force the user to be the one who sends the transaction to validate that. We only need them to sign that they are in agreement with the deployment.With that in mind, we can request a signature along with the deployment parameters. A user who requests the contract creation only needs to sign the parameters once he or she is willing to deploy. The factory is then tuned to use the signer address, instead of the sender, to calculate the deployment address.contract Factory {\n function deploy(\n address logic, bytes32 salt, bytes memory initdata, bytes memory signature\n ) public returns (address addr) {\n address signer = keccak256(\n abi.encodePacked(logic, salt, initdata, address(this))\n ).toEthSignedMessageHash().recover(signature);\n bytes32 newsalt = keccak256(abi.encodePacked(salt, signer)); \n bytes memory code = type(Proxy).creationCode;\n assembly {\n addr := create2(0, add(code, 0x20), mload(code), newsalt)\n if iszero(extcodesize(addr)) { revert(0, 0) }\n }\n Proxy(addr).initialize(logic);\n (bool success,) = addr.call(initdata);\n require(success);\n }\n}This flow is also coded into the ZeppelinOS ProxyFactory contract. As with the previous one, the zos create2 command can be used to call into this method by adding a signature option, as you can see in our sample project.$ zos create2 --salt 43 --from 0x44\n> Instance using salt 43 will be deployed at 0x654321\n...\n$ zos create2 MyContract --salt 43 --signature 0xabcdef --init initialize --from 0x88\n> Instance of MyContract deployed at 0x654321All in all, this means that any user may choose a random salt and have a uniquely determined address at their disposal to deploy whatever they want, whenever they want. Not only that, the deployment can be executed directly from their address or via any relay address by just signing the deployment parameters.Putting it all togetherThanks to CREATE2, we can create a frictionless onboarding process for our users. It allows us to counterfactually instantiate our users’ identity contracts, and only deploy them once necessary.Adding proxies to the mix allows us to make cheaper deployments and to defer the choice of the logic contract used for the identity until it is actually needed. This grants us the flexibility of rapidly iterating identity implementations and ensuring that our users are onboarded directly to the latest one, regardless of when they parked their identity address.Should we find a bug in our identity implementations, we can use the techniques seen in this post to ensure that any counterfactually created identity is realized on-chain with a fixed version. Since we are no longer bound to a specific implementation when parking an address, we can switch to a different one as needed.We will be sharing an in-depth post on how to build this solution in another post soon. In the meantime, go ahead and start using CREATE2 today on your own experiments. And make sure to share what you’re building with this new opcode with the rest of the community on the forum!Happy coding!","tokens":4893,"squid":"ink-security_audits","role":"Sentinel","at":1791268199187,"hash":"33bceb6d518dab776de6e57986a41d64ef32f906"}
{"url":"https://aave.com/stable-vaults","domain":"aave.com","title":"Embedded yield from Aave | Aave","text":"Stable Vaults•Live NowEmbedded yield from AaveStable Vaults enable fintechs to embed stable-rate earning on stablecoins directly into their products.What are Stable Vaults?Predictable stablecoin earning for fintechs.Traditional DeFi lending rates fluctuate with market utilization. Stable Vaults turn that volatility into a stable-rate product layer that is easier to explain, forecast, and embed.Stable RateStable. Predictable. Trustworthy.No rate volatility.Per-user rates for loyalty, campaigns, or tiers.Yield compounds every second, automatically.Easy for end users to understand.The rate you see is locked at deposit and compounds every second. Market yield moves underneath; the Vault absorbs the swings to hold your rate steady.Why Stable VaultsBring stablecoin earning into your product.Stable Vaults package DeFi-powered yield inside familiar product flows, with supported assets, rates, and redemptions all built in.Read the DocsMulti-asset deposit and withdrawalDeposit one supported stablecoin, redeem another: yield fits the rails already in your product.4.00%4.75%5.20%5.90%6.50%4.00%4.75%5.20%5.90%6.50%4.00%4.75%5.20%5.90%6.50%Per-user ratesAssign rates by activity, tier, loyalty, or promo: the vault tracks each user automatically.Multi-chain earningCapital is spread across multiple chains and lending markets: lower fees, deeper liquidity, by default.How it worksDeposit, earn, withdraw.Stable Vaults keep the user experience familiar while the vault manages liquidity, accounting, and DeFi-powered yield beneath it.Read the Docs1DepositUsers add a supported stablecoin through the product surface they already use.2Earn at a stable rateThe vault tracks the user's balance against a predictable stable rate.500🌸Maya3WithdrawUsers request withdrawal and redeem through the same surface, across all supported assets.Core CapabilitiesThe Building Blocks.The flexible pieces that make the simple vault experience work.Read the DocsStable ratesUsers earn a pre-set predictable APY with no volatility.Per-user ratesDifferent rates for loyalty, campaigns, or tiers.Multi protocolAave v3, Aave v4, sGHO, Veda, and more.Multi-chain earningCapital is deployed across chains where yields are best.Multi assetDeposit and withdraw supported stablecoins.Permissioned accessWhitelisted or signature gated deposits for approved users.Coming SoonCross-chain depositsDeposit and withdraw from any supported chain.Coming SoonFee splittingAutomated yield distribution across participants.Coming SoonModular by designBuilt to be extended for new use cases.Powering Aave ProductsStable Vaults power Aave App.A simple earn experience for users who want predictable stablecoin yield without managing markets or chains.Learn MoreBuilt for embedded yield.The accounting chain tracks balances and redemptions while allocators route liquidity into approved ERC-4626 yield adapters across earning chains.FAQsEach deposit accrues at a fixed per-second rate set by its assigned SubVault, so returns stay predictable no matter how underlying market rates move. An off-chain rebalancer continuously optimizes yield allocations to sustain those committed rates, absorbing market volatility at the protocol layer instead of passing it to depositors.The vault continuously tracks its assets against its obligations to depositors. If earned yield falls short, principal is always guaranteed and an authorized party can top up the system to keep every user's earned interest fully withdrawable; if assets exceed obligations, an authorized caller may sweep the surplus to the treasury—though never in a way that would leave the vault unable to cover what it owes.Yes, because the Stable Vault supports multiple assets and is able to swap commonly denominated stablecoins while requiring a 1:1 exchange.Slippage and swap/venue fees are funded by an external source. User deposits are never used to pay for slippage or fees and a 1:1 exchange is enforced at the smart contract layer.Users never directly interact with bridging functionality. The funds deposited into the system are bridged cross-chain by a risk steward which pays for the bridging fees.Request IntegrationTell us about your product and we'll get you the details to start embedding Aave yield.","tokens":1060,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268205376,"hash":"13e082347f76e75f72a6dedb54ceb77fd226ba1a"}
{"url":"https://docs.base.org/upgrades/azul/overview","domain":"docs.base.org","title":"Overview - Base Documentation","text":"StatusDateSepoliaLiveApril 20, 2026MainnetLiveMay 28, 2026\n​Features\nEIP-7823: Upper-Bound MODEXPEIP · ExecutionCaps MODEXP precompile inputs to a maximum of 1024 bytes per field. Calls with larger inputs are rejected.EIP-7825: Transaction Gas Limit CapEIP · ExecutionIntroduces a protocol-level maximum gas limit of 16,777,216 (2^24) per transaction. Transactions above this cap are rejected during validation, and Base adopts the same cap as L1 to maximize Ethereum equivalence.EIP-7883: MODEXP Gas Cost IncreaseEIP · ExecutionRaises the MODEXP precompile minimum gas cost from 200 to 500 and triples the general cost calculation.EIP-7939: CLZ OpcodeEIP · ExecutionAdds a new CLZ opcode that counts the number of leading zero bits in a 256-bit word, returning 256 if the input is zero.EIP-7951: secp256r1 PrecompileEIP · ExecutionSpecifies the secp256r1 precompile at address 0×100. From Azul, the gas cost increases to 6,900 to match the L1 gas cost specified in EIP-7951.EIP-7642: eth/69EIP · NetworkingUpdates the Ethereum wire protocol to version 69, removing legacy fields from the Status message and simplifying the handshake.Remove Account Balances & ReceiptsBase · NetworkingSimplifies the FlashblocksMetadata payload by removing new_account_balances and receipts from the Flashblocks WebSocket format.Use basev0 Protocol ID for discv5Base · NetworkingUpdates execution-layer discovery to use basev0 as the protocol ID so Base nodes can find each other more quickly, especially on smaller networks like Sepolia.EIP-7910: eth_config RPC MethodEIP · RPCIntroduces the eth_config JSON-RPC method, which returns chain configuration parameters such as fork activation timestamps.Engine API UsageBase · RPCAt and after Azul activation, block production and import use the following Engine API methods: engine_forkchoiceUpdatedV3 for starting block builds and forkchoice synchronization, engine_getPayloadV5 for retrieving built payloads.MultiproofsBase · ProofsProof System introduces a multi-proof system for L2 checkpoints, where AggregateVerifier can verify one or two proofs for the same proposal before withdrawals rely on it.Was this page helpful?Suggest editsRaise issue","tokens":545,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268211234,"hash":"90718adc8c4687760846597a3f46ca4b0688b286"}
{"url":"https://aave.com/blog/introducing-stable-vaults","domain":"aave.com","title":"Introducing Stable Vaults | Aave","text":"Back to BlogIntroducing Stable VaultsAave Labs•9 July, 2026ProductToday Aave Labs is introducing Stable Vaults, an all-in-one way to embed predictable-rate stablecoin yield into any product. Stable Vaults are the smart contract vaults that already power the Aave mobile savings app, and they are now available for any business to build on.\nIntegrating DeFi yield into a consumer product has always meant managing volatile rates, multi-chain liquidity, and a heavy layer of infrastructure between an onchain yield strategy and the end user. After years of working on this problem at Aave Labs, we built Stable Vaults to solve it.\n\nStable Vaults convert variable onchain lending rates into a predictable rate a business can offer its users, and they make it easy to manage the rebalancing, the cross-chain operations, and the rate paid to users.\nAny business can now integrate Aave-powered yield, or any ERC-4626 vault strategy it chooses, into its product without building yield infrastructure from scratch.\nWhat Businesses Can Build\n\nStable Vaults give any business a ready-made backend for onchain stablecoin yield. The business chooses which stablecoins to accept, which yield strategies to use, and what predictable rate to offer each user. Examples of what can be built include:\n\nA neobank embedding predictable-rate savings, powered by Aave markets, directly into its app.\nA payments company letting merchants earn on idle settlement balances using a Veda vault between payouts.\nA wallet provider or exchange adding a one-tap earn feature backed by Savings GHO, without building or managing yield infrastructure.\nA fintech issuing its own stablecoin registering it as a supported deposit asset, creating a closed-loop earn product for its existing users with a custom ERC-4626 yield strategy vault.\n\nBusinesses can also reward target user groups, such as premium subscribers, with higher rates, or run temporary promotions that boost a user's rate. Anything the underlying strategies earn above those commitments belongs to the operator as revenue. Because the operator controls which assets and strategies the vault uses, each deployment can be tailored to a specific product, jurisdiction, or risk profile.\nWhy Stable Vaults?\nStable Vaults solve a variety of engineering challenges at once including volatile rates, fragmented cross-chain liquidity, and operations between an onchain strategy and an end user.\nThe Stable Vault stack also makes life easier for users when integrated. User deposits start earning yield the moment they’re received, and they can deposit or withdraw from any chain the operator supports, in whichever stablecoins the operator integrates. Chainlink Price Feeds and CCIP can power any Stable Vaults deployment, providing reliable pricing data and secure cross-chain bridging. The Aave App will use both in its production deployment.\nStable Vaults are a production system, already running in the Aave App, now open for any business to build on.\nGet Started\nRead the documentation, explore the codebase, or reach out to the Aave Labs team:\n\nStable Vault landing page\nDocumentation\nCodebase\nAudits\nNeed help or want to learn more?Share your questions or feedback and we'll get back to you.Name *Email *Your message *","tokens":812,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268217177,"hash":"9f88028b72f34c4dfb57fac54ea4825c457f7bcf"}
{"url":"https://docs.base.org/upgrades/azul/proofs","domain":"docs.base.org","title":"Proof System - Base Documentation","text":"Azul introduces a multi-proof system for the L2 checkpoints that secure withdrawals to L1. A\ncheckpoint is a fixed interval of L2 blocks summarized by an output root. Each proposal about that\ncheckpoint is submitted to AggregateVerifier, an L1 dispute game that can verify one or two\nproofs for the same proposal before withdrawals rely on it.\nIn the common path, a TEE prover creates the initial proposal proof. A permissionless ZK prover can\nlater back the same proposal or dispute an invalid one. AggregateVerifier delegates proof checks\nto dedicated verifier contracts, while a prover registrar keeps the onchain registry of accepted\nTEE signer identities up to date.\n​Why Change the Proof System\nBase’s current fault-proof system is optimistic and interactive: a proposal resolves unless someone\nchallenges it. That model has two limits.\n\nWithdrawals take at least 7 days because every proposal inherits the full challenge window.\nEvery bad proposal must be actively challenged. That creates an economic attack surface: if\nchallengers cannot fund every dispute, an incorrect state can finalize. Centralized guardrails\nreduce that risk today, but that is not a long-term model for Stage 2 decentralization.\n\nAzul replaces that model with a multi-proof design built around TEE and ZK provers. TEE proofs\nsupport the common path, ZK proofs provide a permissionless backstop, and the architecture leaves\nroom to adopt stronger proving systems over time.\n​Finality Model\nThe Azul design supports three settlement paths for a proposal on Ethereum:\nProofs presentSettlement pathTarget windowWhat it meansTEE onlyLong window7 daysCommon path, still overridable by ZKZK onlyLong window7 daysPermissionless path without TEE relianceTEE + ZKShort window1 dayFaster finality when both systems agree\nThe long window gives independent provers time to verify a claim and dispute it if needed. The\nshort window is available only when both proof systems back the same proposal. A ZK prover can also\ndispute an invalid TEE-backed claim and claim the TEE prover’s bond as a reward. In Azul, that delay\nlives in AggregateVerifier itself. OptimismPortal2 and AnchorStateRegistry no longer add a\nseparate 3.5 day delay, because keeping either legacy delay would eliminate the fast-finality path\neven when both proofs are present.\n​Security and Decentralization\n\nThe TEE path is permissioned and optimized for the common case.\nThe ZK path is permissionless and can override an invalid TEE-backed claim.\nThe proof layer remains modular and can evolve toward stronger TEE implementations, different ZK\nsystems, or multi-ZK designs.\n\n​Overview\n​New/Changed Onchain Components\n\nAggregateVerifier: Azul’s dispute-game contract for checkpoint proposals. Each proposal is\ninitialized with one proof, a second proof can be added later for the same claimed root, and the\ncontract calls proof-specific verifier contracts and aggregates their results to determine how the\nproposal resolves. This is also where the Azul finality delay now lives.\nTEEVerifier and ZKVerifier: proof-specific verifier contracts called by AggregateVerifier.\nTheir addresses are immutable on the AggregateVerifier implementation, so each deployment has\nan explicit verifier set.\nDelayedWETH: still escrows the proposal bond for each game, but Azul reduces its withdrawal delay\nto 1 day. That is sufficient here because the only bonds at stake are proposer bonds.\nOptimismPortal2: no longer adds the separate 3.5 day proof-maturity delay for these proposals.\nThat timing moves into AggregateVerifier, which keeps the 1 day path reachable instead of\nforcing every proposal to inherit at least 3.5 days of extra delay.\nAnchorStateRegistry: Similar to OptimismPortal2, this no longer has a 3.5 day finalization\ndelay for proposals, allowing fast finality.\n\n​Proof Flow\nThe proof flow for Azul is:\n\nThe proposer identifies the next canonical checkpoint range and requests a TEE proof.\nThe TEE prover re-executes that L2 block range inside an AWS Nitro Enclave and signs the\nresulting output root.\nThe proposer verifies the result against canonical Base L2 state and submits a new\nAggregateVerifier game to L1.\nA challenger can independently recompute the same checkpoint roots and, if it finds an invalid\nclaim, sources the ZK proof needed to dispute it.\n\nThis architecture keeps the normal path simple, preserves a permissionless dispute path, and\nsupports faster settlement when both proof systems are available.\n​Proof Roles\n\nThe proposer turns canonical L2 checkpoints into new AggregateVerifier games on L1.\nA challenger checks in-progress games against canonical L2 state and disputes incorrect claims.\nTEE provers power the common proposal path.\nZK provers provide the permissionless verification and override path.\nThe registrar maintains the onchain registry of accepted TEE signer identities.\nAggregateVerifier and its verifier contracts verify claims before withdrawals on L1 can rely on\nthem.\n\n​Proposer\nThe proposer turns safe or finalized Base L2 checkpoints into L1 AggregateVerifier games. It\nfinds the latest canonical parent state, requests a TEE proof for the next checkpoint interval,\nverifies the returned output root against canonical L2 state, and submits the next proposal with\nthe required bond.\n​Challenger\nAnyone can run a challenger. A challenger independently recomputes checkpoint output roots for\nin-progress games, identifies the first invalid claim, and submits the required dispute\ntransaction. The permissionless dispute path is a ZK proof challenge. Base will run a challenger as\na security backstop, and Base’s challenger also has access to a TEE nullification path for invalid\nTEE-backed proposals.\n​TEE Provers\nTEE provers are AWS Nitro Enclave-backed services used in the common proposal path. The host gathers\nwitness data from RPCs, the enclave re-executes the requested L2 block range in isolation, and the\nenclave signs the resulting checkpoint outputs with a key that never leaves the enclave.\n​ZK Provers\nZK provers are the permissionless proving backend in Azul. They are used when a dispute requires a\nZK proof, especially to challenge an invalid TEE-backed proposal or to invalidate a bad ZK claim.\nIn normal operation, the proposer does not depend on ZK provers to create new games. In the\nfuture, the proposer may integrate ZK provers directly so new roots can carry both proof paths from\nthe start, unlocking faster finality for all roots.\n​Prover Registrar\nThe prover registrar keeps the onchain TEEProverRegistry in sync with the live set of Nitro prover\nsigners. It discovers active provers, attests their signer identities onchain, and removes orphaned\nsigners with safeguards against transient outages.Was this page helpful?Suggest editsRaise issue","tokens":1687,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268222835,"hash":"829b91a2ae94dfde95ab06dfb90c95e3be89e92f"}
{"url":"https://aave.com/gho","domain":"aave.com","title":"GHO | Aave","text":"GHO + sGHOStable and savingThe Aave-native stablecoin, paired with onchain savings.Save with sGHOGet GHOGHO + sGHOBacked by Aave. Built to save.GHO is the Aave-native USD stablecoin. sGHO is the onchain savings layer that pays you for holding it.Learn MoreSafe by designEvery GHO is backed by more than $1 of crypto held inside Aave.Earning by defaultHold GHO, deposit into sGHO, earn the savings rate.Liquid on demandSwap from USDC or USDT at 1:1, or borrow against your crypto.Savings, the Aave wayA simple way to save your dollars in GHO.Deposit GHO, hold sGHO, and earn the savings rate. No lockup, no minimum, no cooldown.Save with sGHOcurrent sGHO savings rateDeposit GHO, get sGHOOne transaction. sGHO arrives ready to earn.Earn the savings rateYour sGHO earns yield paid in GHO, set by Aave governance.Withdraw any timeRedeem sGHO for GHO whenever you want.The sGHO RateA live, onchain savings rate.Set by Aave governance. Moved by the market. Paid in GHO.sGHO Savings Rate vs BenchmarkssGHOT-BillsSavings Account4.50%3.71%0.38%sGHO APY from on-chain data•T-Bill: 3-month secondary market rate•Savings: FDIC national avgHow the yield worksBorrowers pay, you earn.Yield comes from borrower interest and stablecoin reserves. Aave governance sets the rate.Learn MoreAbout GHOAave's native dollar.GHO is Aave's USD stablecoin — backed by crypto held in the protocol, with reserves always greater than supply.Total BackingGHO Total SupplyTotal ReservesGet GHOTwo paths to GHO.GHO is decentralized credit, issued through Aave. Borrow against crypto or swap stablecoins.Swap stablecoins for GHO.Swap USDC, USDT for GHO at 1:1 — free to redeem. Reserves earn yield for sGHO.Max swap feeSwap GHOBorrow against your crypto.Deposit crypto into Aave, borrow GHO. Fixed rate, lower than USDC or USDT.Current borrow rateBorrow GHOGHO DeeperFor the curious.How GHO is governed, measured, and built on.Decentralized & TransparentGHO is fully governed by the Aave DAO who votes on its development and future roadmap.Learn MoreMulti-collateral BackingGHO is backed by multiple different assets supplied into the Aave Protocol.Learn MoreBuild with GHOWith as few as 10 lines of code, you can easily integrate GHO payments into your app.Learn MoreOpen a GHO Credit LineCustom credit for treasuries, fintechs, non-bank lenders, and market makers building on GHO. We'll work with you on size, rate, and structure.Contact UsGet StartedStart saving in GHO.Your stablecoins should earn. Now they can.Save with sGHOEarn the savings rate. Withdraw any time.Save with sGHOGet GHOSwap USDC or USDT at a fixed rate.Get GHOBorrow GHOAgainst ETH, wBTC, or other Aave collateral.Borrow GHOFAQsGHO is a decentralised, overcollateralised stablecoin that is fully backed, transparent, and native to the Aave Protocol.The GHO Documentation is a comprehensive resource that explains the core mechanics of how the GHO stablecoin operates.Borrowers and suppliers can mint GHO using assets they have supplied into V3 as collateral on Ethereum markets, while continuing to earn interests on their underlying assets.The GHO pool functions differently from existing assets, but borrowing it will work similarly as other available assets on the different markets in the protocol.Supply CollateralBorrow GHORepay GHO and Accrued Interest (real-time)Repaid interest will be redirected to the DAO, rather than an asset supplier, contributing to the DAO treasury.Assets that are available in the Aave Protocol can be used to back GHO. Initially, the Ethereum V3 pool will be the first facilitator to launch because of V3's extensive risk-mitigation features, including e-mode, isolation mode, and supply caps.The Aave DAO manages the supply of GHO, the interest rates and determine risk parameters.","tokens":939,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268239035,"hash":"9a6a8927ad755f798528d09d4da90d81980b7fa2"}
{"url":"https://docs.base.org/upgrades/beryl/b20","domain":"docs.base.org","title":"B20 Native Token Standard - Base Documentation","text":"B20 is the Base ecosystem’s own version of ERC-20. It ships with a built-in compliance toolkit: transfer policies, freeze-and-reissue controls, role-based access control, memos, and supply caps. The released Beryl interfaces are available in Base Standard Library v1.0.0.\nTo deploy your first B20 token, see the Launch a B20 token quickstart.\nVerify the Activation Registry is enabled before attempting to deploy.\nB20 supports two variants:\nVariantDecimalsAdditional FeaturesAsset6–18 (configurable)Rebase multiplier, onchain announcements, batched issuanceStablecoin6 (fixed)Self-declared fiat currency code\n​ERC-20 Compatibility\nB20 tokens are implemented as Rust precompiles rather than EVM smart contracts, making them faster, cheaper, and more native to the chain. All tokens are deployed via the singleton B20Factory precompile.\nB20 is a superset of ERC-20. Every ERC-20 call (transfer, transferFrom, approve, balanceOf, allowance, and the standard events) behaves exactly as the standard specifies, so existing ERC-20 tooling and integrations work against B20 with no changes.\nB20 adds methods that ERC-20 does not include: memos, mint/burn, policy gating, granular pause, and ERC-2612 permit. These extend ERC-20 without altering it - every ERC-20 method exists on B20, but the reverse does not hold. For the complete Beryl ABIs, see the v1.0.0 interface definitions.\n​Roles Model\nB20 role-based access control extends OpenZeppelin AccessControl with a fixed set of roles and one behavioral override on admin renunciation.\nRoleGatesDEFAULT_ADMIN_ROLEAll admin operations: role grants, policy updates, supply-cap changesMINT_ROLEmint, mintWithMemoBURN_ROLECaller-side burns: burn, burnWithMemoBURN_BLOCKED_ROLEThird-party burns against policy-blocked accounts: burnBlockedPAUSE_ROLEpauseUNPAUSE_ROLEunpauseMETADATA_ROLEupdateName, updateSymbol, updateContractURI\nUser-defined roles are supported via setRoleAdmin and grantRole. They carry no built-in effect - B20 only enforces gates against the seven base-surface roles above. The Asset variant adds an eighth role, OPERATOR_ROLE (see Variants).\n​Admin Renunciation\nThe last DEFAULT_ADMIN_ROLE holder cannot be removed via renounceRole or revokeRole (both revert with LastAdminCannotRenounce). The dedicated renounceLastAdmin() is the only path to permanently transition a token to admin-less.\nTokens that intend to launch admin-less from the start pass initialAdmin == address(0) at creation, which never grants the role and skips the renounceLastAdmin step entirely.\nAfter renounceLastAdmin() (or for tokens deployed with initialAdmin == address(0)):\n\nOperations gated by DEFAULT_ADMIN_ROLE become permanently uncallable.\nRoles already granted to other addresses (MINT_ROLE, BURN_ROLE, etc.) continue to function independently.\nAdmin resurrection is blocked: grantRole, revokeRole, and setRoleAdmin all revert with AccessControlUnauthorizedAccount even if the caller holds a custom role.\n\n​Policy Registry\nThe PolicyRegistry is a singleton precompile that manages allowlists and blocklists. B20 tokens reference policies by uint64 ID. Any caller can create a policy and nominate its admin.\nState-changing functions on the PolicyRegistry are gated by the ActivationRegistry, which tracks which Base features are live. Read functions (isAuthorized, policyExists, policyAdmin, pendingPolicyAdmin) are always callable.\n​Policy Types\nTypeDefaultBehaviorBLOCKLISTAuthorizedAll accounts authorized by default; explicitly listed accounts are denied.ALLOWLISTDeniedAll accounts denied by default; explicitly listed accounts are authorized.\n​Policy IDs\nPolicy IDs are uint64 values. The top byte encodes the PolicyType; the low 56 bits are a global counter starting at 2.\nTwo built-in IDs require no creation:\nConstantIDBehaviorALWAYS_ALLOW0Authorizes every account unconditionally. Default scope value on new B20 tokens.ALWAYS_BLOCK(uint64(ALLOWLIST) << 56) | 1Denies every account unconditionally.\nisAuthorized never reverts on a non-existent policy ID - it collapses to empty-member-set semantics (non-existent BLOCKLIST authorizes everyone; non-existent ALLOWLIST denies everyone).\nConsumers that write a policy ID (e.g. updatePolicy) MUST validate policyExists(policyId) at write time to avoid silently binding to an unintended empty-set policy.\n​Admin Model\nEach policy has one admin. Admin transfers are two-step: the current admin calls stageUpdateAdmin(policyId, newAdmin), then the pending admin calls finalizeUpdateAdmin(policyId). renounceAdmin(policyId) permanently freezes the policy - membership can never be changed again.\n​Creating and Managing Policies\nPolicy Management Example// Create a policy (admin first, then type)\nuint64 policyId = policyRegistry.createPolicy(adminAddress, PolicyType.BLOCKLIST);\n// Or seed the initial member set in one call:\n// uint64 policyId = policyRegistry.createPolicyWithAccounts(adminAddress, PolicyType.BLOCKLIST, accounts);\n\n// Update membership (batched). The setter is type-specific; the bool sets membership state.\npolicyRegistry.updateBlocklist(policyId, true, accounts); // block these accounts\npolicyRegistry.updateBlocklist(policyId, false, accounts); // unblock these accounts\n// For ALLOWLIST policies: policyRegistry.updateAllowlist(policyId, allowed, accounts)\n\n​Read Interface\nMethodDescriptionisAuthorized(policyId, account)Whether account is authorized under policyId. Never reverts.policyExists(policyId)Whether a policy with this ID has been created.policyAdmin(policyId)Current admin address.pendingPolicyAdmin(policyId)Pending admin during a two-step transfer.\n​Policy Integration\nB20 declares a fixed set of policy scopes. Each scope stores a uint64 policy ID pointing into the PolicyRegistry. On every gated operation, B20 calls isAuthorized against the relevant scope and reverts with PolicyForbids if the account is not authorized.\nScopeGatesTRANSFER_SENDER_POLICYThe from of transfer / transferFromTRANSFER_RECEIVER_POLICYThe to of transfer / transferFromTRANSFER_EXECUTOR_POLICYThe msg.sender of transferFrom, when distinct from from (not checked on transfer)MINT_RECEIVER_POLICYThe to of mint\napprove is not policy-gated - only actual balance movement via transfer / transferFrom is checked.\nEvery scope defaults to ALWAYS_ALLOW at token creation unless overridden in the bootstrap initCalls. An unattended B20 deployment is fully open - token behavior must be intentionally constrained.\nScopes are read via policyId(scope) and written via updatePolicy(scope, policyId). updatePolicy is admin-gated and reverts if the scope is not recognized.\n​Mint\nNew supply is created via mint / mintWithMemo, gated by MINT_ROLE. The recipient is policy-checked against MINT_RECEIVER_POLICY. The operation reverts with SupplyCapExceeded if it would push totalSupply past the cap.\n​Burn\nTwo burn paths exist:\n\nburn / burnWithMemo - caller burns from their own balance. Gated by BURN_ROLE.\nburnBlocked - burns from a third party’s balance. Gated by BURN_BLOCKED_ROLE. The target account MUST be denied by TRANSFER_SENDER_POLICY - this is the freeze-and-seize path for regulated issuers.\n\n​Supply Cap\nThe supply cap is optional. The sentinel type(uint128).max indicates no cap (the default at creation); it is also the maximum permitted cap, so totalSupply can never exceed it. updateSupplyCap(newCap) is admin-gated and emits SupplyCapUpdated. It reverts with InvalidSupplyCap if newCap is below the current totalSupply or above type(uint128).max.\n​Memos\nA memo is an optional bytes32 payload attached to a token operation for off-chain reference. Every memo-emitting operation emits Memo(address indexed caller, bytes32 indexed memo) immediately after the operation’s primary event. Indexers join via (transactionHash, logIndex − 1).\nMemo-emitting entrypoints: transferWithMemo, transferFromWithMemo, mintWithMemo, burnWithMemo.\n​Pause\nPauses are granular: the PausableFeature enum partitions the token surface into independently pausable operations - TRANSFER, MINT, and BURN. The enum is append-only. pause(features) and unpause(features) are gated by separate roles (PAUSE_ROLE and UNPAUSE_ROLE) by design.\n​ERC-2612 Permit / EIP-712\nB20 implements ERC-2612 (signed approvals) using an EIP-712 domain shaped as (name, version, chainId, verifyingContract), with version fixed at \"1\". updateName rotates the domain separator and emits EIP712DomainChanged (ERC-5267). ERC-1271 contract signatures are not accepted - ECDSA only.\n​Contract URI (ERC-7572)\ncontractURI() returns a string pointing to off-chain metadata per ERC-7572. updateContractURI(newUri) is gated by METADATA_ROLE.\n​Metadata Updates\nMETADATA_ROLE gates:\n\nupdateName(newName) - updates name and rotates the EIP-712 domain separator. Emits NameUpdated and EIP712DomainChanged.\nupdateSymbol(newSymbol) - updates symbol only. Emits SymbolUpdated.\n\n​Factory\nAll B20 tokens are created through the singleton B20Factory precompile via createB20(variant, salt, params, initCalls). In base-std it is exposed as StdPrecompiles.B20_FACTORY.\nParameterDescriptionvariantASSET or STABLECOINsaltCaller-chosen entropy for address derivationparamsABI-encoded, variant-specific creation struct (versioned by leading byte)initCallsOptional array of ABI-encoded calls dispatched post-creation; factory-originated calls bypass role gates and transfer-side policy gates during this window\ncreateB20 reverts with IActivationRegistry.FeatureNotActivated if the requested variant’s feature is not yet activated on the chain.\n​Address Derivation\nB20 addresses are deterministic and encode the variant directly:\nAddress Derivation[10-byte B20 prefix][1-byte variant][9-byte keccak256(deployer, salt)]\n\nThe variant is recoverable from the address alone without an RPC call — inspect byte 10 (zero-indexed) to identify the token type. Helper functions getB20Address(variant, deployer, salt), isB20(addr), and isB20Initialized(addr) are available on the factory.\n​initCalls Semantics\ninitCalls are dispatched after token creation. During this bootstrap window, factory-originated calls bypass the token’s role gates and its transfer-side policy gates (TRANSFER_SENDER_POLICY, TRANSFER_RECEIVER_POLICY, TRANSFER_EXECUTOR_POLICY), allowing admin-gated configuration (e.g. setting policies, granting roles) and bootstrap transfers in the same transaction as deployment. The bypass is deliberately not total:\n\nMINT_RECEIVER_POLICY is always enforced even during initCalls.\nPause state is never bypassed.\nToken invariants (supply cap, etc.) are never bypassed.\n\n​Variants\nEach variant is identified by a 1-byte value encoded directly in the token’s address (see Address Derivation):\nVariantByteASSET0x00STABLECOIN0x01\n​Asset\nThe general-purpose variant for assets of all kinds. Decimals are configurable between 6 and 18 at deployment time and are immutable after creation.\nIn addition to the base B20 surface, Asset tokens add several capabilities. A new OPERATOR_ROLE gates the multiplier and announcements; batch mint and extra metadata reuse the existing MINT_ROLE and METADATA_ROLE respectively.\n​Multiplier\nA WAD-precision rebase multiplier applied to all balance reads. Raw balances are stored unchanged; the multiplier scales the view returned to callers.\nMethodDescriptionmultiplier()Current WAD-precision multiplierscaledBalanceOf(account)Raw balance × multipliertoScaledBalance(raw)Convert raw amount to scaledtoRawBalance(scaled)Convert scaled amount to rawupdateMultiplier(newMultiplier)Update the multiplier. Gated by OPERATOR_ROLE.\nThese are the Beryl names. Cobalt adds the ERC-8056 interface: uiMultiplier and balanceOfUI alias multiplier and scaledBalanceOf, which stay canonical; toUIAmount and fromUIAmount replace the deprecated toScaledBalance and toRawBalance; and the scheduled updateUIMultiplier setter replaces updateMultiplier, which stays callable as a deprecated emergency setter. The scheduled setter emits only UIMultiplierUpdated; the legacy MultiplierUpdated event is emitted only by updateMultiplier. See the Cobalt multiplier changelog.\n​Announcements\nOn-chain disclosure brackets that wrap sensitive operations (e.g. batch mints, multiplier updates) with a public notice period. Gated by OPERATOR_ROLE.\nannounce(internalCalls, id, description, uri) emits an Announcement event, executes internalCalls, then emits EndAnnouncement. The id must be unique and is enforced forever. Inner call reverts are wrapped in InternalCallFailed.\n​Batch Mint\nbatchMint(recipients, amounts) mints to multiple recipients in a single call. Gated by MINT_ROLE. Should be wrapped in announce() for transparency.\n​Extra Metadata\nAn arbitrary key/value store for issuer-defined on-chain metadata.\nMethodDescriptionextraMetadata(key)Read a value by keyupdateExtraMetadata(key, value)Write a value. Gated by METADATA_ROLE. Setting an empty value removes the entry.\n​Stablecoin\nThe fixed-decimals, fiat-backed carveout. Decimals are hard-wired to 6 and are not configurable.\nAdds currency(), which returns an ISO-style currency code string (e.g. \"USD\", \"EUR\"). The code is set once at creation via B20StablecoinCreateParams.currency, restricted to characters A-Z only. It is self-declared and not verified against any external registry.\n​Precompile Addresses\nThese addresses are identical on every network where B20 is active (Mainnet, Base Sepolia, Vibenet, and local base-anvil).\nPrecompileAddressB20Factory0xB20f000000000000000000000000000000000000Activation Registry0x8453000000000000000000000000000000000001Policy Registry0x8453000000000000000000000000000000000002Was this page helpful?Suggest editsRaise issue","tokens":3393,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268244754,"hash":"273a52b82dd8703ef306ef0cdcff1580a0c78172"}
{"url":"https://docs.base.org/upgrades/beryl/overview","domain":"docs.base.org","title":"Overview - Base Documentation","text":"StatusDateSepoliaLiveJune 18, 2026MainnetLiveJune 25, 2026\n​Features\nReth V2Base · ExecutionShips Reth V2 as the reference execution client for Base nodes, delivering significant sync speed and throughput improvements.Faster WithdrawalsBase · ProofsThe single-proof dispute game finalization window is reduced from 7 days to 5 days. The dual-proof fast path (TEE + ZK) introduced in Azul remains at 1 day. Shortening the single-proof window frees capital for fast-bridge liquidity providers.B20Base · PrecompileB20 implements the ERC-20 specification, making it interoperable with all existing systems built on ERC-20 like wallets, exchanges, data indexers, and onchain protocols. What’s different is how it runs. Rather than deploying a Solidity contract, B20 tokens execute as Rust precompiles inside the node.Was this page helpful?Suggest editsRaise issue","tokens":215,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268254692,"hash":"d8b305673dbd69a6a64dfec4948b6a3df75d4639"}
{"url":"https://blog.ethereum.org/category/protocol","domain":"blog.ethereum.org","title":"Protocol Announcements | Ethereum Foundation Blog","text":"Protocol AnnouncementsAnnouncement of Ethereum protocol upgrades.September 28, 2026ProtocolGlamsterdam Testnet Announcementby Protocol\nGlamsterdam follows the Fusaka upgrade, advancing Ethereum's L1 scaling roadmap with enshrined proposer-builder separation, block-level access lists, and changes to gas pricing that better reflect the cost of execution and state growth.\n\nThe Glamsterdam network upgrade is scheduled to activate on Sepolia at epoch 353,024, slot 11,296,768 (October 6, 2026, 13:53:36 UTC). See the activation table below for the deployment schedule. Hoodi and mainnet activation dates have not yet been decided.\n\nSepolia-compatible client versions will be added to the client release tables as they are confirmed. Node operators must update both their execution and consensus layer clients before activation.\nAugust 17, 2026ProtocolAnnouncing the Platåberget Testnetby Protocol DevOps\ntl;dr: Meet Platåberget: Glamsterdam's (Gloas + Amsterdam) early testing ground open to public participation. This upgrade comes with breaking changes for application developers. Notably, any tool that relies on a hardcapped maximum gas limit (think wallets, indexers and gas estimators) will break and needs to be updated. Please use this early opportunity to test!\n\nPlatåberget is a short-term testnet aimed for testing changes by the community. Unlike the short-lived devnets before it, Platåberget is intended to run for a few months, giving the community a stable place to experiment with post-Glamsterdam Ethereum, and an opportunity to test and break things before Glamsterdam goes live on Ethereum's longer-lived testnets, Sepolia and Hoodi.\nNovember 6, 2025ProtocolFusaka Mainnet Announcementby Protocol Coordination Team\nFusaka follows this year's Pectra upgrade, representing a major step forward in Ethereum's scaling roadmap that improves L1 performance, increases blob throughput, and enhances user experience.\n\nThe Fusaka network upgrade is scheduled to activate on the Ethereum mainnet at slot 13,164,544 (December 3, 2025, 21:49:11 UTC). Fusaka also introduces Blob Parameter Only (BPO) forks to safely scale blob throughput after PeerDAS activation. These are minimal, config-only upgrades that adjust the blob target/max and fee update fraction. See the activation table below for further details.\n\nThe Fusaka mainnet client releases are listed below.\nSeptember 26, 2025ProtocolFusaka Testnet Announcementby Protocol Coordination Team\nFusaka follows this year's Pectra upgrade, representing a major step forward in Ethereum's scaling roadmap by introducing PeerDAS and key improvements that enhance blob throughput, L1 performance, and user experience.\n\nThis post announces the testnet activation schedule for the first three testnets, beginning with Holesky at slot 5,283,840 (October 1, 2025, 08:48:00 UTC). See the activation table below for the complete Sepolia and Hoodi timeline. Fusaka also introduces Blob Parameter Only (BPO) forks to safely scale blob throughput after PeerDAS activation. These are minimal, config-only upgrades that adjust the blob target/max and fee update fraction.\n\nThe Fusaka testnet client releases are listed below. Once all three testnets have successfully upgraded, a mainnet activation slot will be chosen.\nSeptember 1, 2025ProtocolHolešky Testnet Shutdown Announcementby Protocol Coordination Team\nAs previously announced, the Holešky testnet has reached its planned end-of-life date and will be sunset shortly. The vast majority of remaining validator nodes will be shut down 2 weeks after the Fusaka upgrade has finalized on Holešky. After this, Holešky will no longer be supported by client, testing or infrastructure teams.\n\nFollowing the launch of the Hoodi testnet in March 2025, infrastructure providers and staking operators have had the opportunity to migrate their testing operations.\nJuly 8, 2025ProtocolPartial history expiry announcementby Matt Garnett\nAs of today, all Ethereum execution clients support partial history expiry in accordance with EIP-4444. While work on full, rolling history expiry is ongoing, users can expect to reduce the disk space required for an Ethereum node by 300-500 GB by removing the block data prior to the Merge. This will allow a node to fit comfortably on a 2 TB disk. See below for information on each specific client.\nApril 23, 2025ProtocolPectra Mainnet Announcementby Protocol Support Team\nThe Pectra network upgrade is scheduled to activate on the Ethereum mainnet on May 07, 2025 at epoch 364032 (10:05:11 UTC)! Mainnet client releases are listed below.\nMarch 18, 2025ProtocolHolesky and Hoodi Testnet Updatesby Tim Beiko\nThe Pectra testnet activation revealed issues in clients with deposit contract configurations changes on Ethereum testnets. While Sepolia's recovery was straightforward and the network has since fully recovered, Holesky experienced extensive inactivity leaks as part of its recovery mechanism.\n\nThe Holesky network has since then finalized, but the exited validators would take approximately one year to fully be removed from the validator set (¹). While stakers can test deposits, consolidations and all other Pectra features, the size of the exit queue prevents Holesky from being used to test the full validator lifecycle within a reasonable timeframe.\n\nTo address this, a new testnet has been launched: Hoodi. It will activate the Pectra network upgrade at epoch 2048 (Wed. March 26, 2025 14:37:12 UTC). Client releases that support theNewer postsOlder posts","tokens":1374,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268255457,"hash":"e59a742a866c647bcba2ce08a854522d37654ddf"}
{"url":"https://ethresear.ch/t/sticking-to-8192-signatures-per-slot-post-ssf-how-and-why/17989/1","domain":"ethresear.ch","title":"Sticking to 8192 signatures per slot post-SSF: how and why - Proof-of-Stake - Ethereum Research","text":"Sticking to 8192 signatures per slot post-SSF: how and why \n\n Proof-of-Stake\n\n single-slot-finality\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Dec 2023\n\n 1 / 41\n\n Dec 2023\n\n Jan 2024\n\n post by vbuterin on Dec 27, 2023\n\n vbuterin\n\n A major difference between Ethereum and most other (finality-bearing) proof of stake systems is that Ethereum tries to support a very high number of validators: we currently have 895,000 validator objects and a naive Zipf’s law analysis implies that this corresponds to tens of thousands of unique invididuals/entities. The purpose of this is to support decentralization, allowing even regular individuals to participate in staking, without requiring everyone to give up their agency and cede control to one of a small number of staking pools.\nHowever, this approach requires the Ethereum chain to process a huge number of signatures (~28,000 today; 1,790,000 post-SSF) per slot, which is a very high load. Supporting this load entails a lot of technical sacrifices:\n\nIt requires a complicated attestation propagation mechanism involving attestations being split between multiple subnets, needing to hyper-optimize BLS signature operations to verify these signatures, etc.\nWe don’t have a clear drop-in quantum-resistant alternative that is anywhere near efficient enough.\nFork choice fixes like view merge become much more complicated because of the inability to extract individual signatures.\nSNARKing the signatures is hard, because there’s so many of them. Helios needs to operate over a specialized extra signature, called the sync committee signature\nIt increases safe minimum slot times by requiring three sub-slots in a slot instead of two.\n\nThe signature aggregation system feels reasonable at first glance, but in reality it creates systemic complexity that bleeds out all over the place.\nFurthermore, it does not even achieve its goal. The minimum requirement to stake is still 32 ETH, which is out of reach for many people. And just from a logical analysis, it seems infeasible to make an everyone-signs-in-every-slot system truly enable staking for the average person in the long term: if Ethereum has 500 million users, and 10% of them stake, then that implies 100 million signatures per slot. Information-theoretically, processing slashing in this design requires at least 12.5 MB per slot of data availability space, roughly as much as the target for full daksharding (!!!). Perhaps doable, but requiring staking itself to be dependent on data availability sampling is a large complexity gain - and even that is only ~0.6% of the world population staking, and does not begin to get into the computational issue of verifying that many signatures.\nTherefore, instead of relying on cryptographers to create magic bullets (or magic bulletproofs) to make an ever-increasing number of signatures per slot possible, I propose that we make a philosophical pivot: move away from having such an expectation in the first place. This will greatly expand the PoS design space, and will allow for a large amount of technical simplification, make Helios more secure by allowing it to SNARK over Ethereum consensus directly, and solve the quantum resistance issue by making even boring long-existing signature schemes like Winternitz viable.\nWhy not “just do committees”\nMany non-Ethereum blockchains, faced with this exact problem, use a committee-based approach to security. During each slot, they randomly choose N validators (eg. N ~= 1000), and those are the validators responsible for finalizing that slot. It is worth reminding why this approach is insufficient: it does not provide accountability.\nTo see why, suppose that a 51% attack does happen. This could be a finality-reversion attack or a censorship attack. For the attack to take place, you do still need economic actors controlling a large fraction of the stake to agree to in the attack, in the sense of running software that participates in the attack with all validators that end up being selected for the committee. The math of random sampling ensures this. However, the penalty that they incur for such an attack is tiny, because most of the validators that agreed to the attack end up not being seen because they are not chosen for the committee.\nEthereum, at present, takes the opposite extreme. If a 51% attack takes place, a large fraction of the entire attacking validator set has their deposits slashed. The cost of an attack is at present around 9 million ETH (~$20 billion), and that assumes network synchrony breaks in a way that maximally favors the attacker.\nI argue that this is a high cost, but it is too high a cost, and we can afford to make some sacrifices in the matter. Even a cost of attack of 1-2 million ETH should be totally sufficient. Furthermore, the main centralization risks of Ethereum that are present today are in a totally different place: large-scale staking pools would not be that much less powerful if the minimum deposit size were reduced to near-zero.\nThis is why I advocate a moderate solution: one that makes some sacrifices on validator accountability, but still keeps the amount of total slashable ETH quite high, but in exchange gets us most of the benefits of a smaller validator set.\nWhat would 8192 signatures per slot under SSF look like?\nAssuming a traditional two-round consensus protocol (like what Tendermint uses, and like what SSF would inevitably use), you need two signatures per slot per participating validator. We need to work around this reality. I see three major approaches for how we could do this.\nApproach 1: go all-in on decentralized staking pools\nThe zen of Python contains a really key line:\n\nThere should be one-- and preferably only one --obvious way to do it.\n\nFor the problem of making staking egalitarian, Ethereum currently violates this rule, because we are simultaneously executing on two distinct strategies toward this goal: (i) small-scale solo staking, and (ii) decentralized stake pools using distributed validator technology (DVT). For the reasons described above, (i) is only able to support some individual stakers; there will always be very many people for whom the minimum deposit size is too large. However, Ethereum is paying the very high technical burden costs of supporting (i).\nA possible solution is to give up on (i) and go all-in on (ii). We could raise the min deposit size to 4096 ETH and make a total cap of 4096 validators (~16.7 million ETH). Small-scale stakers would be expected to join a DVT pool: either by providing capital or by being a node operator. To prevent abuse by attackers, the node operator role would need to be reputation-gated somehow, and pools would compete by providing different options in this regard. Capital provision would be permissionless.\nWe can make pooled staking in this model more “forgiving” by capping penalties, eg. to 1/8 of total provided stake. This would allow reducing trust in node operators, though it’s worth approaching this carefully due to the issues outlined here.\nApproach 2: two-tiered staking\nWe create two layers of stakers: a “heavy” layer with a 4096 ETH requirement that participates in finalization, and a “light” layer with no minimum (also no deposit and withdrawal delay, and no slashing vulnerability) that adds a second layer of security. For a block to finalize, both the heavy layer needs to finalize it and the light layer needs to have >= 50% of online light validators attest to it.\nThis heterogeneity is good for censorship and attack resistance, because one would need to corrupt both the heavy layer and the light layer for an attack to succeed. If one layer is corrupted and not the other, the chain halts; if it’s the heavy layer that was corrupted, the heavy layer can be penalized.\nAnother benefit of this is that the light layer can include ETH that is simultaneously used as collateral inside applications. The main downside is that it makes staking less egalitarian by enshrining a divide between small-scale stakers and larger stakers.\nApproach 3: rotating participation (ie. committees but accountable)\nWe take an approach in a similar spirit to the super-commtittee design proposed here: for each slot, we choose 4096 currently active validators, and we carefully adjust that set during each slot in such a way that we still have safety.\nHowever, we make some different parameter choices to get the “maximum bang for our buck” within this framework. Particularly, we allow validators to participate with arbitrarily high balances, and if a validator has more than some quantity M𝑀 of ETH (which would have to be floating) then they participate in the committee during every slot. If a validator has N < M𝑁 <𝑀 ETH, then they have a \\frac{N}{M}𝑁𝑀 probability of being in the committee during any given slot.\nOne interesting lever that we have here is decoupling “weight” for incentive purposes, vs “weight” for consensus purposes: each validator’s reward within the committee should be the same (at least for validators with \\le M≤𝑀 ETH), to keep average rewards proportional to balance, but we can still make consensus count validators in the committee weighted by ETH. This ensures that breaking finality requires an amount of ETH equal to > \\frac{1}{3}>13 of the total ETH in the committee.\nA back-of-the-nakpin Zipf’s law analysis would compute that amount of ETH as follows:\n\nAt each power-of-two level of total balance, there would be a number of validators inversely proportional to that balance level, and the total balance of those validators would be the same.\nHence, the committee would have an equal amount of ETH participating from each balance level, except the levels above the barrier M𝑀, where the validator is in the committee always.\nHence we have k𝑘 validators at each of log_2(M)𝑙𝑜𝑔2(𝑀) levels, and k + \\frac{k}{2} + ... = 2k𝑘 +𝑘2 +... =2𝑘 validators at the levels above. So k = \\frac{4096}{log_2(M) + 2}𝑘 =4096𝑙𝑜𝑔2(𝑀)+2.\nThe largest validator would have M * k𝑀 ∗𝑘 ETH. We can work backwards: if the largest validator has 2^{18} = 262144218 =262144 ETH, this would imply (roughly) M = 1024 and k = 256.\nThe total ETH staked would be:\n\nThe full stake of the top 512 validators (2^{18} * 1 + 2^{17} * 2 + ... + 2^{10} * 2^{8} = 2359296218 ∗1 +217 ∗2 +... +210 ∗28 =2359296)\nPlus the randomly sampled smaller stakes (2^8 * (2^9 + 2^8 + 2^ 7 ...) \\approx 2^8 * 2^{10} = 2^{18}28 ∗(29 +28 +27...) ≈28 ∗210 =218)\nIn total we get 26214402621440 ETH staked, or a cost of attack of ~900k ETH.\n\nThe main disadvantage of this approach is somewhat more in-protocol complexity to randomly choose validators in such a way that we get consensus safety even across committee changes.\nThe main advantages are that it preserves solo staking in a recognizable form, preserves a one-class system, and even allows for the minimum deposit size to be reduced to a very low level (eg. 1 ETH).\nConclusions\nIf we establish that in a post-SSF protocol, we want to stick to 8192 signatures, this makes the job much easier for technical implementers, as well as builders of side infrastructure like light clients. It becomes much easier for anyone to run a consensus client, and users, staking enthusiasts and others would be able to immediately work off of that assumption. The future load of the Ethereum protocol becomes no longer an unknown: it can be raised in the future through hard forks, but only when developers are confident that technology has improved enough to be able to handle a larger number of signatures-per-slot with the same level of ease.\nThe remaining job would be to decide which of the above three approaches, or perhaps something else entirely, we want to go with. This would be a question of which tradeoffs we are comfortable with, and particularly how we navigate related issues such as liquid staking, which could be resolved separately from the now-much-easier technical questions.\n\n Orbit SSF: solo-staking-friendly validator set management for SSF\n\n Simplified Active Validator Cap and Rotation Proposal\n\n Unbundling staking: Towards rainbow staking\n\n Rainbow roles & incentives: ABPS + FOCILR + AS\n\n Vorbit SSF with circular and spiral finality: validator selection and distribution\n\n 7\n\n 2\n\n 2\n\n 2\n\n 2\n\n read \n\n 21\n min\n\n post by MicahZoltu on Dec 27, 2023\n\n post by vbuterin on Dec 27, 2023\n\n post by hanniabu on Dec 27, 2023\n\n post by RichardKoh1 on Dec 27, 2023\n\n post by uri-bloXroute on Dec 27, 2023\n\n post by vbuterin on Dec 27, 2023\n\n post by sasicgroup on Dec 27, 2023\n\n post by OisinKyne on Dec 27, 2023\n\n post by vbuterin on Dec 27, 2023\n\n post by vbuterin on Dec 27, 2023\n\n post by Guest20444 on Dec 27, 2023\n\n post by vbuterin on Dec 27, 2023\n\n post by Zergity on Dec 27, 2023\n\n post by MicahZoltu on Dec 27, 2023\n\n post by kladkogex on Dec 28, 2023\n\n post by aivarasko on Dec 28, 2023\n\n post by tbrannt on Dec 28, 2023\n\n post by Milli3E on Dec 28, 2023\n\n post by pradavc on Dec 28, 2023\n\n Load more posts below","tokens":3243,"squid":"ink-research","role":"Deep Scholar","at":1791268264657,"hash":"6b495aca8d0e98d692ef467d7e430b3221868d31"}
{"url":"https://blog.ethereum.org/2026/08/17/plataberget-testnet","domain":"blog.ethereum.org","title":"Announcing the Platåberget Testnet | Ethereum Foundation Blog","text":"This post is available in 25 languages: EnglishAnnouncing the Platåberget TestnetPosted by Protocol DevOps on August 17, 2026Protocol Announcementstl;dr: Meet Platåberget: Glamsterdam's (Gloas + Amsterdam) early testing ground open to public participation. This upgrade comes with breaking changes for application developers. Notably, any tool that relies on a hardcapped maximum gas limit (think wallets, indexers and gas estimators) will break and needs to be updated. Please use this early opportunity to test!\nPlatåberget is a short-term testnet aimed for testing changes by the community. Unlike the short-lived devnets before it, Platåberget is intended to run for a few months, giving the community a stable place to experiment with post-Glamsterdam Ethereum, and an opportunity to test and break things before Glamsterdam goes live on Ethereum's longer-lived testnets, Sepolia and Hoodi.\nWhat's in the Glamsterdam fork\nThe Glamsterdam upgrade brings significant changes to both the consensus and execution layers. Highlights include:\nEnshrined Proposer-Builder Separation: a major change to how blocks are built, proposed and validated, including a new builder API flow and PTC (payload-timeliness) checks. Infrastructure which depends on the block production and validation pipeline should expect to be affected.Block-Level Access Lists: introduces enforced block-level access lists that record accessed state locations and post-transaction changes. BALs are stored separately from the block body and can be exchanged between execution-layer peers through eth/71.Gas repricings: a coordinated bundle of gas cost changes aimed at a ~200M gas floor. Any tooling that hardcodes a maximum gas limit will be affected.Larger contracts and initcode: increases the maximum deployed contract size from 24KiB to 64KiB and the maximum initcode size from 48KiB to 128KiB.Forward-compatible consensus data structures\nPlatåberget has a relatively small but publically joinable validator set. This allows anyone to deposit a new\nvalidator and test out their validator and builder deposit workflows. ePBS is a major change to the consensus\nlayer and we want to ensure that all the solo stakers, DVT projects, custom software and large scale operators have\nample chances to test their infrastructure. The Glamsterdam fork on the testnet is scheduled for 20th August, allowing ample time to make deposits and prepare for the fork transition.\nAnother major change in Glamsterdam is the gas repricings. These changes will affect a far larger group, since they touch every wallet, indexer, and gas estimator on the network. Please use this opportunity to understand what tooling or assumptions break in your system before the fork goes live in Mainnet.\nThe full list of included EIPs is tracked in the Glamsterdam meta EIP-7773.\nUsing Platåberget\nCheck out the Platåberget resources page for a summary of the included EIPs, client support and launch status, and the devnet-8 specification for network settings, config values, bootnodes and client release information.\nThe Platåberget page offers a one-click Add Network flow\nto configure your EL and CL clients, and a faucet provides testnet ETH to cover deposits and gas.\nA few things to keep in mind when running a node:\nThe public will be able to submit validator or builder deposits via the Dora explorerRather than pre-allocating automatic stake to a handful of entities, the genesis validator set will be bootstrapped from public deposits, with some ETH allocated at genesis to help get things started.Client releases: releases for each client are optional, please check your client of choice if they have\nincluded it\nClient images\nFor the time being, use our ethPandaOps container images below while client teams prepare tagged releases.\nConsensus Layer\nlighthouse: ethpandaops/lighthouse:glamsterdam-devnet-8\nlodestar: ethpandaops/lodestar:unstable\nnimbus: ethpandaops/nimbus-eth2:unstable\nprysm: ethpandaops/prysm-beacon-chain:glamsterdam-devnet-8\nprysm_validator: ethpandaops/prysm-validator:glamsterdam-devnet-8\nteku: ethpandaops/teku:glamsterdam-devnet-8\ngrandine: ethpandaops/grandine:glamsterdam-devnet-8\n\nExecution Layer\nbesu: ethpandaops/besu:glamsterdam-devnet-8\ngeth: ethpandaops/geth:glamsterdam-devnet-8\nerigon: ethpandaops/erigon:glamsterdam-devnet-8\nnethermind: ethpandaops/nethermind:glamsterdam-devnet-8\nreth: ethpandaops/reth:glamsterdam-devnet-8\nnimbusel: ethpandaops/nimbus-eth1:glamsterdam-devnet-8\nethrex: ethpandaops/ethrex:glamsterdam-devnet-8\n\nSupport & Feedback\nIf you identify bugs or issues with the specification, the best place to raise these is in the Ethereum R&D Discord server. If you'd rather not use Discord, other venues to raise such issues are the specification repositories: consensus, execution, execution-apis, builder-specs and beacon-APIs.\nNext Steps\nPlatåberget gives the community an opportunity to experiment with post-Glamsterdam Ethereum and begin identifying issues.\nThe gas repricing is especially important for application developers: any tool that relies on a hardcapped maximum gas limit (think wallets, indexers and gas estimators) will break and needs to be updated. We'd love to see dApp and wallet developers testing against Platåberget alongside infra operators — this is the class of change most likely to catch downstream tooling off guard.\nThe repricing is not only about the block gas limit: individual operations change price too, and EIP-8037 introduces a separate state gas dimension for operations that create new state. Creating an account, deploying code or writing a fresh storage slot is now metered at a fixed cost per state byte (CPSB), charged at runtime rather than up front. The practical consequence is that a plain ETH transfer is no longer always flat 21,000 gas: transfers to an account that already exists still cost 21,000 (now decomposed into TX_BASE_COST + COLD_ACCOUNT_ACCESS + TX_VALUE_COST), but sending funds to an account that does not exist yet additionally incurs STATE_BYTES_PER_NEW_ACCOUNT × CPSB state gas at runtime. Anything that assumes 21,000 covers every transfer, or assumes a single gas dimension when estimating, needs revisiting — see EIP-2780 for the decomposed intrinsic cost and EIP-8038 for the state-access increases.\nOnce feedback has been incorporated into client software and the specifications, a non-finality devnet will follow within the month to test pathological consensus scenarios.\nAfter these devnets have been stable for some time, the existing long-lived testnets (Sepolia, Hoodi) will run through the Glamsterdam fork. Once those have upgraded and are stable, next up is Ethereum mainnet's transition to Glamsterdam 🎊.\nFor those eager to follow the progress at a more granular level, the best venues are the Ethereum R&D Discord server, the All Core Dev calls, the Glamsterdam upgrade tracker, or the EthPandaOps Glamsterdam devnets Github repo.\nSee you on Platåberget 🐻‍❄️!","tokens":1736,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268270482,"hash":"16a5e47bf01bc4d2448e0a9a48961c4e40af12d8"}
{"url":"https://ethresear.ch/c/proof-of-stake/5","domain":"ethresear.ch","title":"Latest Proof-of-Stake topics - Ethereum Research","text":"Latest topics in Proof-of-Stake\n\n Proof-of-Stake\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Proof-of-Stake category\n\n Proof-of-Stake\n\n Discussion related to Proof-of-Stake (PoS). \nSee also: \nhttps://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ \nhttps://github.com/ethereum/casper \nhttps://github.com/ethereum/research/tree/master/papers/casper\n\n 1\n\n 3.9k\n\n Dec 2017\n\n Timing the Head in Ethereum PoS\n\n Economics\n\n 2\n\n 246\n\n Sep 1\n\n ePBS, distilled\n\n Block proposer\n\n mev\n\n 10\n\n 866\n\n Aug 29\n\n Properties of issuance offsets and increased penalties under low/zero/negative issuance policies\n\n Economics\n\n issuance-policy\n\n 1\n\n 505\n\n Aug 19\n\n FAQ: Ethereum issuance reduction\n\n Economics\n\n 3\n\n 7.3k\n\n Aug 17\n\n Native Ethereum Delegation (NED): Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification\n\n Proof-of-Stake\n\n 0\n\n 121\n\n Aug 14\n\n In-Protocol Client Data Reporting\n\n Proof-of-Stake\n\n 14\n\n 400\n\n Aug 6\n\n Supporting decentralized staking through more anti-correlation incentives\n\n Proof-of-Stake\n\n 21\n\n 15.0k\n\n Jul 25\n\n The Extremely Lean Chain\n\n Proof-of-Stake\n\n 6\n\n 4.8k\n\n Jul 8\n\n Adding PoS validator key changes\n\n Proof-of-Stake\n\n 5\n\n 5.7k\n\n Jul 7\n\n Building towards Multi-Party Block Construction\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 2\n\n 674\n\n Jun 3\n\n The case for a variable PTC deadline with affine metering and a unified calldata price\n\n Proof-of-Stake\n\n resource-pricing\n\n 0\n\n 239\n\n Apr 22\n\n A Protocol Design View on Statelessness\n\n Economics\n\n stateless\n\n 7\n\n 1.2k\n\n Apr 16\n\n Why a Variable Payload Deadline Only Helps by ~6%\n\n Proof-of-Stake\n\n mev,data-availability\n\n 0\n\n 139\n\n Mar 23\n\n Rational Finality Stalls and the Risks of Pre-Finality Actions in Ethereum-Anchored Systems\n\n Proof-of-Stake\n\n 1\n\n 183\n\n Mar 21\n\n One-epoch inactivation and Rifle attacks\n\n Proof-of-Stake\n\n 8\n\n 420\n\n Mar 12\n\n Observation Horizon: Time-Bounded Offline Verifiability in Proof-of-Stake Systems\n\n Casper Basics\n\n 0\n\n 78\n\n Mar 5\n\n Majority Fork Protection Through Distributed Validator Technology: A Novel Approach to Network Resilience\n\n Block proposer\n\n security\n\n 0\n\n 245\n\n Mar 4\n\n Deprecating BLS: Post-Quantum Recovery via Deposit Address\n\n Proof-of-Stake\n\n security,post-quantum,consensus\n\n 11\n\n 1.3k\n\n Feb 19\n\n Universal Enshrined Encrypted Mempool EIP\n\n Proof-of-Stake\n\n mev\n\n 21\n\n 2.1k\n\n Feb 13\n\n Native DVT for Ethereum staking\n\n Proof-of-Stake\n\n 19\n\n 3.1k\n\n Jan 28\n\n An Observation on Ethereum’s Blockspace Market\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 4\n\n 2.2k\n\n Dec 2025\n\n Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\n Block proposer\n\n 13\n\n 11.8k\n\n Sep 2025\n\n Trustless Consensus Manipulation Through Bribing Contracts\n\n Proof-of-Stake\n\n security\n\n 0\n\n 317\n\n Sep 2025\n\n Integrating 3SF with ePBS, FOCIL, and PeerDAS\n\n Proof-of-Stake\n\n consensus\n\n 0\n\n 679\n\n Aug 2025\n\n The Glamsterdam equation\n\n Proof-of-Stake\n\n scaling\n\n 2\n\n 783\n\n Aug 2025\n\n eODS (Enshrined Operator Delegator Separation): a Delegation model proposal\n\n Proof-of-Stake\n\n 0\n\n 403\n\n Jul 2025\n\n Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 0\n\n 291\n\n Jul 2025\n\n Relay Block Merging: Boosting Value & Censorship Resistance\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 2\n\n 1.2k\n\n Jun 2025\n\n Liveness attack in Ethereum PoS protocol using RANDAO manipulation\n\n Proof-of-Stake\n\n 3\n\n 703\n\n Jun 2025","tokens":912,"squid":"ink-research","role":"Deep Scholar","at":1791268274858,"hash":"424ff48054b35cdf22454d26d38078e1cc93dfc2"}
{"url":"https://docs.base.org/specifications/base-protocol/batcher","domain":"docs.base.org","title":"Batcher - Base Documentation","text":"​Overview\nThe batcher, also referred to as the batch submitter, is the entity responsible for posting L2 sequencer data to L1, making it available to the derivation pipeline operated by verifiers. The format of batcher transactions — channels, frames, and batches within them — is defined in the derivation spec: the data is constructed from L2 blocks in the reverse order from which it is derived back into L2 blocks. Only data that conforms to those rules will be accepted as valid from the verifier’s perspective.\nThe batcher observes the gap between the unsafe L2 head (the latest sequenced block) and the safe L2 head (the latest block confirmed on L1 through derivation). Any unsafe L2 blocks that have not yet been confirmed must be encoded and submitted. The batcher encodes L2 blocks into channels, fragments channels into frames, and posts frames as L1 transactions. The derivation pipeline then reads those frames, reassembles channels, decodes batches, and reconstructs the original L2 blocks.\nThe timing and transaction signing are implementation-specific: data can be submitted at any time, but only data that matches the derivation spec rules will be valid from the verifier perspective. The L2 view of safe and unsafe does not update instantly after data is submitted or confirmed on L1, so a batcher implementation must take care not to duplicate data submissions.\n​Channel Lifecycle\nA channel is the unit of encoding used by the batcher. It is an ordered, compressed sequence of RLP-encoded L2 block batches. A channel is opened when there are L2 blocks awaiting submission and no channel is currently open. At most one channel may be open at any time; a new channel must not be opened until the previous one has been fully closed and all its frames have been submitted to L1.\nA channel accumulates L2 block batches in strictly increasing block number order until one of the following closure conditions is met. A channel must close when adding the next batch would cause the compressed output size to exceed the maximum blob data capacity, ensuring that no frame will carry a payload too large for its data availability target. A channel must also close when continued accumulation would cause the total uncompressed RLP byte length of its batches to exceed max_rlp_bytes_per_channel, a protocol limit that protects verifiers against decompression amplification. In both cases, the batch that would have caused the overflow is withheld from the current channel; the channel is closed, and that batch becomes the first entry of the next channel.\nA channel must additionally close on timeout: if the L1 chain advances more than max_channel_duration L1 blocks beyond the block at which the channel was opened, the channel must be closed and its frames posted immediately. This prevents channels from staying open indefinitely and ensures that verifiers — who drop any channel not completed within the channel_timeout window — do not discard the data.\nWhen a channel closes, its compressed data is partitioned into fixed-size frames. Each frame carries at most max_frame_size bytes of compressed payload plus per-frame header overhead. The resulting frames are queued for submission to L1 in order. The channel’s block range — the contiguous interval of L2 block numbers it covers — is fixed upon closing and must not change.\n​Frame Production and Ordering\nEach frame carries a header identifying the channel it belongs to via a 16-byte channel ID, its position within the channel as a monotonically increasing 16-bit frame number beginning at zero, the length of its compressed payload, and a boolean flag indicating whether it is the last frame in the channel. The first frame of each channel additionally carries a single version byte identifying the compression codec; all subsequent frames consist entirely of compressed payload with no such prefix.\nFrames within a channel must be submitted to L1 in sequential order. Frame N must appear on L1 no later than frame N+1. The derivation pipeline may tolerate out-of-order frame delivery in some configurations, but from the Holocene hardfork onward it drops any non-first frame whose frame number is not exactly one greater than the previous frame received for that channel, and drops any new first frame whose predecessor channel has not yet been closed. After Holocene activation, strict in-order delivery is required for correctness.\nThe is_last flag must be set to true on exactly the final frame of a channel and false on all preceding frames. A verifier considers a channel complete only when a frame with is_last set is received. Any channel that never receives its final frame within the channel_timeout window is discarded by the verifier.\n​Data Availability\nThe batcher posts frames to L1 as batcher transactions addressed to the batcher inbox address, which is a designated EOA rather than a contract. Each batcher transaction must be signed by the batcher’s signing key, and the recovered sender address must match the batcherAddress recorded in the L2 system configuration at the time of the L1 transaction’s inclusion. The derivation pipeline authenticates batcher transactions by this address; transactions from any other sender are ignored regardless of their content.\nAs of the Cancun L1 upgrade, the primary data availability mechanism is EIP-4844 blob transactions. Each blob carries one frame of compressed channel data. The maximum usable payload per blob is 130,044 bytes, which defines the effective max_frame_size. The batcher must not produce frames whose compressed payload exceeds this limit.\nAll frames for a given channel must land on L1 within channel_timeout L1 blocks of the block in which the channel’s first frame was included. If the channel is not completed within this window, the derivation pipeline discards all buffered frames for that channel, and the affected L2 blocks must be resubmitted in a new channel. The batcher must size channels and manage submission throughput to ensure frames are posted within this deadline.\n​Block Continuity\nThe batcher encodes L2 blocks in strictly increasing order by block number. Each block added to the open channel must be the direct child of the previously encoded block: its parent hash must equal the hash of the most recently encoded block. This invariant ensures the channel represents a contiguous, unambiguous segment of the canonical L2 chain.\nIf the L2 chain reorganizes — manifesting as a block whose parent hash does not match the previously seen tip, or as an explicit reorg signal from the block source — the batcher must discard all pending encoding state. This includes the currently open channel, any channels queued for submission but not yet fully confirmed, and all in-flight submission tracking. After a reorg, the batcher restarts from the new canonical chain tip. L1 transactions already in flight at the time of the reorg are abandoned; if they are eventually included on L1, the derivation pipeline ignores them as they are incoherent with the new chain.\nEach channel covers a contiguous, non-overlapping range of L2 block numbers. The block range of a subsequent channel must begin exactly where the block range of the preceding channel ends. No L2 block may appear in more than one channel, and no blocks may be skipped between consecutive channels.\n​Sequencer Drift and Throttling\nThe derivation spec constrains how far the L2 timestamp may advance ahead of the L1 timestamp of its origin block. An L2 block’s timestamp must not exceed the L1 origin timestamp plus max_sequencer_drift. Prior to the Fjord hardfork, max_sequencer_drift is a per-chain configuration parameter. From Fjord onward it is fixed at 1800 seconds. When this limit is exceeded, the derivation pipeline will only accept a batch if its transaction list is empty (a deposit-only block). The batcher must therefore not include user transactions in blocks whose timestamp would exceed the drift limit, and must coordinate with the sequencer accordingly.\nTo prevent the sequencer from outpacing the batcher’s L1 submission capacity, the batcher measures its data availability backlog — the total encoded size of L2 blocks that have been sequenced but whose data has not yet been confirmed on L1. When the backlog exceeds a configured threshold, the batcher signals the sequencer to reduce its block production rate. The throttle can be graduated: a modest backlog may request a modest slowdown, while a large backlog may pause block production entirely until the batcher catches up. This feedback mechanism is transparent to the derivation pipeline and is not reflected in any on-chain data.\n​Compression\nChannel data is compressed before being partitioned into frames. Prior to the Fjord hardfork, channels use zlib compression (RFC 1950, no dictionary) and carry no version prefix; the zlib magic bytes in the stream allow the decompressor to identify the format. From Fjord onward, channels use Brotli compression (RFC 7932), and the first frame of each channel carries a version byte of 0x01 immediately before the compressed payload to identify the codec. The lower nibble of the version byte must not be 0x08 or 0x0f, as those values would collide with zlib magic header bytes and confuse earlier decompressors.\nBecause compression ratios vary with input content, the batcher must estimate the compressed output size prospectively as it encodes batches into a channel. The channel must be closed before the compressed output would exceed max_frame_size, rather than after. A common approach is to maintain a shadow compressor in parallel with the real compressor and treat the shadow’s output size as an upper bound; the channel is closed when the shadow output reaches the limit. This ensures the batcher never produces a frame too large to fit within a blob.\nThe maximum uncompressed RLP size per channel, max_rlp_bytes_per_channel, is enforced separately from the compressed size limit. This limit protects verifiers from decompression amplification: a small compressed payload that expands to an unboundedly large uncompressed stream could exhaust memory. A verifier decoding a channel stops processing once the uncompressed output reaches this limit; any remaining batches are discarded. The batcher must ensure the uncompressed size of its batches does not exceed this bound, both to guarantee all batches are seen by verifiers and to stay within the protocol’s defined limits.\n​Confirmation and Block Pruning\nThe batcher tracks each submitted frame until it is included in an L1 block. A frame is confirmed when the batcher observes an L1 block containing the L1 transaction that carries the frame. A channel is fully confirmed when every one of its frames has been confirmed on L1.\nL2 blocks must not be discarded from the batcher’s pending set until the channel containing them is fully confirmed. Until confirmation, those blocks must be retained so that any lost frames — for example due to an L1 reorg removing the transaction’s inclusion — can be reconstructed and resubmitted. Only after a channel is fully confirmed may the batcher release the L2 blocks it covers.\nIf a submitted frame’s L1 transaction fails to be included, the batcher must resubmit that frame and all subsequent frames in the same channel. Resubmitted frames must be byte-identical to the originals: the derivation pipeline identifies frames by their channel ID and frame number, and a resubmitted frame with different content would be treated as corrupted data rather than as a retry.\n​Hardfork Rules\nThe Fjord hardfork changes the channel encoding format. Channels opened after Fjord activation must use Brotli compression and prefix the first frame’s payload with version byte 0x01. The protocol limit max_rlp_bytes_per_channel increases substantially at Fjord activation, relaxing the channel size constraint. Channels opened before Fjord activation must use the pre-Fjord format for all their frames, regardless of when those frames are posted.\nThe Holocene hardfork imposes strict ordering requirements at both the frame and batch layers. At the frame layer, frames for a given channel must be delivered to the derivation pipeline contiguously and in order; a non-first frame that is not the immediate successor of the previously seen frame for that channel is dropped immediately, and an incomplete channel is dropped if a new first frame for it arrives before its final frame has been seen. At the batch layer, batches within a channel must be strictly ordered by L2 timestamp with no repeated timestamps; any batch with a timestamp not strictly greater than the previous batch in the same channel causes the channel to be invalidated and all remaining batches in it to be dropped. These rules impose no new on-chain obligations, but they mean the batcher has zero tolerance for frame delivery gaps or reordering after Holocene activation.Was this page helpful?Suggest editsRaise issue","tokens":3231,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268277766,"hash":"7ca46e971e485e6a6f80761f2179be8ca5744165"}
{"url":"https://blog.ethereum.org/2021/05/25/finalized-no-26","domain":"blog.ethereum.org","title":"Finalized no. 26 | Ethereum Foundation Blog","text":"Finalized no. 26the Ethereum consensus-layerPosted by Danny Ryan on May 25, 2021Research & DevelopmentSteady progress\ntl;dr\nAltair progressRayonism wrapped up; The Merge progresses\nAltair progress\nAltair, the first planned upgrade of the Beacon Chain, continues to make steady progress. Last week, we released Beacon Chain spec v1.1.0-alpha.6 -- Protostellar Evolution. While this is an alpha release, barring a security or practical engineering concern, the spec is unlikely to change from here on in.\nClient teams are busy as they pass consensus test vectors and stand up short-lived testnets. Teams will make timeline decisions in the next few weeks as Altair code changes stablize and initial multi-client interop is performed.\nIf you want to learn more about the upgrades coming to the Beacon Chain in Altair, check out Vitalik's recent release of annotated Altair specs.\nRayonism wrap-up and Merge progress\nThe Rayonism hackathon wrapped up last week with the Nocturne testnet -- a multi-client Merge testnet consisting of 4 consensus-engines and 3 execution-engines for a total of 12 unique client pairs.\nDozens of nodes and thousands of validators built and secured a beacon chain that provided native support for a rich Ethereum application-layer with accounts, contracts, and user transactions.\n🎉 Huge shoutout to all of the participating client teams and to protolambda and Mikhail for driving the effort 🎉\nThe Rayonism hackathon allowed teams to rapidly prototype core Merge designs and to better understand how this merged system will work in practice. All teams now have a deep familiarity with the structure of the Merge, and a clear visual on how their software will evolve in this coming year.\nClient teams are now focused on this summer's two forks -- London and Altair -- while researchers are back to Merge spec refinements and testing. After the summer upgrades, teams will shift their focus to the Merge, and begin tackling the production engineering with an eye toward public testnets 🚀","tokens":503,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268280698,"hash":"24257a4971bb9e44cd4a09814c6ed43ea7778229"}
{"url":"https://ethresear.ch/t/native-ethereum-delegation-ned-protocol-routed-delegation-with-split-neutral-allocation-and-coverage-bounded-consensus-amplification/25699","domain":"ethresear.ch","title":"Native Ethereum Delegation (NED): Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification - Proof-of-Stake - Ethereum Research","text":"Native Ethereum Delegation (NED): Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification \n\n Proof-of-Stake\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Aug 12\n\n 1 / 1\n\n Aug 13\n\n Aug 12\n\n post by squijello on Aug 12\n\n squijello\n\n Informally: the Flanders Protocol.\nAbstract\nEthereum already has delegation economically, but the protocol does not provide a provider-neutral native delegation primitive.\nToday, a user’s choice of staking provider commonly influences where that user’s stake ultimately operates:\n\n\\text{commercial provider choice}\n\\longrightarrow\n\\text{validator destination}\n\\longrightarrow\n\\text{consensus weight}.\ncommercial provider choice⟶validator destination⟶consensus weight.\nNative Ethereum Delegation (NED) explores a different architecture.\nA user delegates to a common native pool rather than selecting a validator or staking provider at the consensus layer. NED-enabled validators receive delegated principal according to protocol-visible native base stake rather than the user’s commercial provider.\nThe balanced routing target is:\n\n\\boxed{D_i=uB_i}\n𝐷𝑖=𝑢𝐵𝑖\nwhere B_i𝐵𝑖 is validator i𝑖’s NED-eligible native base effective balance, D_i𝐷𝑖 is its assigned NED delegated principal, and u𝑢 is the common target delegation ratio.\nLinearity makes the target exactly neutral to subdivision of the same eligible stake across additional validator identities.\nSelective participation still creates a harder problem: delegated weight can amplify the participating subset relative to non-participants. The current construction bounds that amplification using a Delegation Concentration Envelope (DCE), which asks how much delegated principal can actually fit inside any eligible-base slice large enough to contain a protected hidden coalition.\nFor protected pre-NED coalition share \\kappa𝜅, threshold \\tau𝜏, eligible coverage e𝑒, normalized delegation d𝑑, and effective NED multiplier \\gamma𝛾, the hard condition is:\n\n\\boxed{\n\\kappa+\\gamma C(\\min(\\kappa,e))\n\\le\n\\tau(1+\\gamma d)\n}.\n𝜅+𝛾𝐶(min(𝜅,𝑒))≤𝜏(1+𝛾𝑑).\nFor Ethereum’s one-third threshold, \\tau=1/3𝜏 =1/3.\nThe protocol does not need to identify which validators belong to the hidden coalition.\nThe design has a useful scaling property:\n\nNED earns scale by earning coverage.\n\nNarrow validator participation permits little safe delegation. Broad participation permits progressively more. At universal proportional participation, NED approaches zero relative consensus amplification.\nThis remains an idea-stage research mechanism, not yet an EIP.\n\n1. Motivation and scope\nEthereum’s practical delegation layer exists mostly above the protocol. A passive staker may use an exchange, custodian, LST or staking service, creating a reinforcing relationship:\n\n\\text{commercial staking success}\n\\rightarrow\n\\text{more customer stake routed to the provider}\n\\rightarrow\n\\text{more consensus influence}.\ncommercial staking success→more customer stake routed to the provider→more consensus influence.\nThe narrower protocol question is:\n\nIf Ethereum exposes native delegation, why should the user’s commercial provider choice itself determine where the delegated consensus weight goes?\n\nUnder NED:\n\n\\text{ETH holder}\n\\rightarrow\n\\text{native NED pool}\n\\rightarrow\n\\text{protocol-routed validators}.\nETH holder→native NED pool→protocol-routed validators.\nCommercial services can still compete on custody, liquidity, insurance, reporting, compliance and UX. Those relationships are not NED routing inputs.\nNED does not attempt to identify beneficial ownership or operator families, determine which validators are genuinely independent, subsidize purported small operators by identity, decentralize the existing validator set, prohibit conventional staking services, prevent custodians from staking customer ETH outside NED, or eliminate application-layer LSTs.\nThe targeted property is narrower:\n\n\\boxed{\n\\text{commercial provider choice}\n\\not\\Rightarrow\n\\text{native delegation destination}\n}.\ncommercial provider choice⇏native delegation destination.\n\n2. State model\nFor every active validator i𝑖, let V_i𝑉𝑖 be its ordinary native effective balance and define:\n\nS=\\sum_iV_i.\n𝑆=∑𝑖𝑉𝑖.\nIf validator i𝑖 is NED-enabled:\n\nB_i=V_i,\n𝐵𝑖=𝑉𝑖,\notherwise:\n\nB_i=0.\n𝐵𝑖=0.\nThus 0\\le B_i\\le V_i0 ≤𝐵𝑖 ≤𝑉𝑖.\nB_i𝐵𝑖 is a protocol-visible quantity. It is deliberately not called operator-owned stake. Ethereum can observe validator credentials and effective balance; it cannot reliably observe beneficial ownership.\nLet D_i\\ge0𝐷𝑖 ≥0 be validator i𝑖’s assigned active NED delegated principal before exceptional safety downweighting. Active NED state requires D_i>0\\Rightarrow B_i>0𝐷𝑖 >0 ⇒𝐵𝑖 >0; retiring principal is accounted separately.\nDefine:\n\nE=\\sum_i B_i,\\quad D=\\sum_i D_i,\\quad e=\\frac{E}{S},\\quad d=\\frac{D}{S}.\n𝐸=∑𝑖𝐵𝑖,𝐷=∑𝑖𝐷𝑖,𝑒=𝐸𝑆,𝑑=𝐷𝑆.\nNormally all assigned NED principal is consensus-effective. For exceptional safety recovery define:\n\n0\\le\\gamma\\le1.\n0≤𝛾≤1.\nEffective delegated consensus balance is:\n\nQ_i=\\gamma D_i,\n𝑄𝑖=𝛾𝐷𝑖,\nand NED consensus weight is:\n\n\\boxed{W_i=V_i+Q_i}.\n𝑊𝑖=𝑉𝑖+𝑄𝑖.\nNormal operation targets \\gamma=1𝛾 =1.\n\n3. Delegators do not select operators\nA native NED delegation request contains no validator index, validator public key, operator, staking company, fee bid, reputation score, geography or commercial wrapper as a consensus-routing target.\nThe native operation is not:\n\n\\text{delegate this ETH to validator }i.\ndelegate this ETH to validator 𝑖.\nIt is:\n\n\\boxed{\\text{delegate this ETH through NED}.}\ndelegate this ETH through NED.\nA commercial service may custody or wrap that position without becoming the consensus destination of the customer’s delegated weight.\n\n4. Split-neutral routing\nThe balanced target is:\n\n\\boxed{D_i=uB_i}.\n𝐷𝑖=𝑢𝐵𝑖.\nSuppose one hidden economic actor represents eligible base stake through arbitrary validator identities:\n\nB_A=\\sum_{j\\in A}B_j.\n𝐵𝐴=∑𝑗∈𝐴𝐵𝑗.\nThen:\n\n\\sum_{j\\in A}D_j\n=u\\sum_{j\\in A}B_j\n=uB_A.\n∑𝑗∈𝐴𝐷𝑗=𝑢∑𝑗∈𝐴𝐵𝑗=𝑢𝐵𝐴.\nCreating more validator identities does not increase aggregate target allocation.\nMore generally, exact neutrality to subdivision requires an identity-local allocation law g𝑔 to satisfy:\n\ng(x+y)=g(x)+g(y).\n𝑔(𝑥+𝑦)=𝑔(𝑥)+𝑔(𝑦).\nUnder ordinary continuity or monotonicity assumptions, this gives:\n\n\\boxed{g(x)=ux}.\n𝑔(𝑥)=𝑢𝑥.\nThis is why NED does not use a nonlinear “small operator” curve as its identity defense. Convex identity-local rules reward splitting, while concave rules create economies of scale. Linear resource allocation makes subdivision irrelevant.\n\n5. Zero-amplification boundary\nThere is a useful boundary result before considering selective participation.\nSuppose total delegated weight D𝐷 is fully allocated and require that no possible hidden coalition receive any increase in relative consensus share. For every singleton validator:\n\n\\frac{V_i+D_i}{S+D}\n\\le\n\\frac{V_i}{S}.\n𝑉𝑖+𝐷𝑖𝑆+𝐷≤𝑉𝑖𝑆.\nThis implies:\n\n\\frac{D_i}{D}\\le\\frac{V_i}{S}.\n𝐷𝑖𝐷≤𝑉𝑖𝑆.\nBoth distributions sum to one, so equality is forced:\n\n\\boxed{D_i=D\\frac{V_i}{S}}.\n𝐷𝑖=𝐷𝑉𝑖𝑆.\nTherefore:\n\nIf zero amplification must hold for every possible hidden ownership partition, delegated allocation must reproduce the complete validator distribution proportionally.\n\nUniversal proportional NED participation is therefore the zero-amplification endpoint. The difficult case is incomplete participation, where useful selective delegation must be bounded without pretending hidden ownership is observable.\n\n6. Delegation Concentration Envelope\nNormalize each NED validator by total ordinary base stake:\n\nb_i=\\frac{B_i}{S},\\quad y_i=\\frac{D_i}{S}.\n𝑏𝑖=𝐵𝑖𝑆,𝑦𝑖=𝐷𝑖𝑆.\nFor normalized eligible-base mass m𝑚, define the Delegation Concentration Envelope:\n\n\\boxed{\nC(m)=\n\\max_{\\substack{0\\le z_i\\le1\\\\\n\\sum_i z_i b_i\\le m}}\n\\sum_i z_i y_i\n}.\n\\tag{1}\n𝐶(𝑚)=max0≤𝑧𝑖≤1∑𝑖𝑧𝑖𝑏𝑖≤𝑚∑𝑖𝑧𝑖𝑦𝑖.(1)\nThis is a fractional-knapsack upper bound. Sort eligible validators by D_i/B_i𝐷𝑖/𝐵𝑖, highest first, and fill eligible base mass m𝑚; the final validator may be consumed fractionally.\nThe fractional relaxation is conservative. It measures the delegated principal that can actually be packed into an eligible-base slice of size m𝑚. A tiny high-leverage validator contributes only the principal it can carry, rather than its ratio being multiplied across unrelated stake. Proportional identity splitting leaves C(m)𝐶(𝑚) unchanged.\n\n7. Hard hidden-coalition invariant\nLet \\kappa<\\tau𝜅 <𝜏 be the largest pre-NED base-stake coalition NED is required to prevent from crossing threshold \\tau𝜏 solely because of NED amplification.\nFor Ethereum’s one-third threshold:\n\n\\tau=\\frac13.\n𝜏=13.\nDefine:\n\nm=\\min(\\kappa,e).\n𝑚=min(𝜅,𝑒).\nRequire:\n\n\\boxed{\n\\kappa+\\gamma C(m)\n\\le\n\\tau(1+\\gamma d)\n}.\n\\tag{2}\n𝜅+𝛾𝐶(𝑚)≤𝜏(1+𝛾𝑑).(2)\nProof sketch\nTake any hidden coalition A𝐴 with ordinary base share:\n\np_A=\\frac{V_A}{S}\\le\\kappa.\n𝑝𝐴=𝑉𝐴𝑆≤𝜅.\nIts eligible base share satisfies:\n\na_A=\\frac{B_A}{S}\n\\le\\min(p_A,e)\n\\le m.\n𝑎𝐴=𝐵𝐴𝑆≤min(𝑝𝐴,𝑒)≤𝑚.\nBy definition of the DCE:\n\n\\frac{D_A}{S}\\le C(m).\n𝐷𝐴𝑆≤𝐶(𝑚).\nAfter the global multiplier:\n\n\\frac{Q_A}{S}\n=\\gamma\\frac{D_A}{S}\n\\le\\gamma C(m).\n𝑄𝐴𝑆=𝛾𝐷𝐴𝑆≤𝛾𝐶(𝑚).\nTherefore its NED-weighted consensus share satisfies:\n\nq_A\n\\le\n\\frac{\\kappa+\\gamma C(m)}{1+\\gamma d}\n\\le\\tau.\n𝑞𝐴≤𝜅+𝛾𝐶(𝑚)1+𝛾𝑑≤𝜏.\nSo Equation (2) bounds every hidden coalition with current pre-NED base share at or below \\kappa𝜅, without an ownership oracle.\n\n8. Coverage-adaptive capacity\nIn a balanced normal state:\n\n\\gamma=1,\\quad D_i=uB_i.\n𝛾=1,𝐷𝑖=𝑢𝐵𝑖.\nThen:\n\nC(m)=um,\\quad d=ue.\n𝐶(𝑚)=𝑢𝑚,𝑑=𝑢𝑒.\nEquation (2) reduces to:\n\n\\boxed{\n\\kappa+u\\min(\\kappa,e)\n\\le\n\\tau(1+ue)\n}.\n\\tag{3}\n𝜅+𝑢min(𝜅,𝑒)≤𝜏(1+𝑢𝑒).(3)\nFor e\\le\\kappa𝑒 ≤𝜅:\n\n\\boxed{\nd_{\\max}=\\frac{\\tau-\\kappa}{1-\\tau}}.\n\\tag{4}\n𝑑max=𝜏−𝜅1−𝜏.(4)\nFor \\kappa<e<\\kappa/\\tau𝜅 <𝑒 <𝜅/𝜏:\n\n\\boxed{\nd_{\\max}=\\frac{e(\\tau-\\kappa)}{\\kappa-\\tau e}}.\n\\tag{5}\n𝑑max=𝑒(𝜏−𝜅)𝜅−𝜏𝑒.(5)\nOnce e\\ge\\kappa/\\tau𝑒 ≥𝜅/𝜏, concentration alone no longer upper-bounds d𝑑. Other risk limits still should.\nIllustrative 32% protection level\nTake:\n\n\\kappa=0.32,\\quad \\tau=\\frac13.\n𝜅=0.32,𝜏=13.\nThe concentration-only frontier is approximately:\n\nNED-eligible coverage e𝑒\nConcentration-safe D/S𝐷/𝑆\n\n40%\n2.86%\n\n60%\n6.67%\n\n80%\n20%\n\n88.89%\n50%\n\n90%\n60%\n\n92%\n92%\n\nBelow 32% coverage, the concentration-only ceiling is 2% of base stake. A narrow participating subset therefore cannot absorb a large native pool simply because it opted in first.\nConversely, a 50% D/S𝐷/𝑆 pool becomes concentration-compatible at about 88.89% coverage under this illustrative \\kappa𝜅.\nThis is the intended behavior:\n\nlow coverage → low safe capacity\nbroad coverage → high safe capacity\nuniversal proportional coverage → zero relative amplification\n\n9. Three separate risk limits\nHidden-coalition concentration\nEquation (2) controls consensus-share amplification.\nLocal principal-agent leverage\nDefine \\ellℓ and require:\n\n\\boxed{D_i\\le\\ell B_i}.\n\\tag{6}\n𝐷𝑖≤ℓ𝐵𝑖.(6)\nThis limits delegated principal per unit of eligible base.\nSystem-wide NED exposure\nDefine \\LambdaΛ and require:\n\n\\boxed{d=\\frac DS\\le\\Lambda}.\n\\tag{7}\n𝑑=𝐷𝑆≤Λ.(7)\nThis caps systemic NED size near universal coverage.\nIn balanced normal operation:\n\n\\boxed{\nd\\le\n\\min\\left(\n d_{\\text{concentration}}(e),\n \\ell e,\n \\Lambda,\n d_{\\text{demand}}\n\\right).\n}\n\\tag{8}\n𝑑≤min(𝑑concentration(𝑒),ℓ𝑒,Λ,𝑑demand).(8)\nAs an illustrative test vector only, not a mainnet recommendation:\n\n\\kappa=32\\%,\\quad \\ell=\\frac23,\\quad \\Lambda=\\frac12\n𝜅=32%,ℓ=23,Λ=12\nwould allow NED to reach 50% of ordinary base stake at about 88.89% eligible coverage, while separately capping local and total nominal delegated exposure.\n\n10. Bounded-cost DCE implementation\nA consensus implementation can conservatively approximate the exact DCE with a fixed leverage histogram over:\n\n0\\le\\frac{D_i}{B_i}\\le\\ell.\n0≤𝐷𝑖𝐵𝑖≤ℓ.\nFor each bucket maintain aggregate eligible base and delegated principal. Scan high to low; only the partially consumed boundary bucket uses its leverage ceiling.\nThen:\n\n\\boxed{\\widehat C(m)\\ge C(m)}.\n̂𝐶(𝑚)≥𝐶(𝑚).\nWith K𝐾 equal-width buckets:\n\n\\boxed{\n\\widehat C(m)-C(m)\n\\le\\frac{m\\ell}{K}\n\\le\\frac{\\kappa\\ell}{K}.\n}\n\\tag{9}\n̂𝐶(𝑚)−𝐶(𝑚)≤𝑚ℓ𝐾≤𝜅ℓ𝐾.(9)\nFor illustrative \\kappa=0.32𝜅 =0.32, \\ell=2/3ℓ =2/3, K=1024𝐾 =1024, the worst-case normalized overestimate is about 0.02083% of ordinary base stake.\nThe conservative \\widehat Ĉ𝐶 can replace C𝐶 directly in Equation (2).\n\n11. Exceptional safety multiplier\nNormal activation must satisfy Equation (2) with \\gamma=1𝛾 =1. An involuntary state change can nevertheless alter eligible base or delegation after activation.\nRather than physically rescaling every D_i𝐷𝑖, NED applies one global effective-weight multiplier \\gamma𝛾. Nominal D_i𝐷𝑖 and the DCE histogram remain unchanged; consensus uses Q_i=\\gamma D_i𝑄𝑖 =𝛾𝐷𝑖.\nLet C𝐶 denote the exact or conservative nominal envelope. The hard condition is:\n\n\\kappa+\\gamma C\n\\le\n\\tau(1+\\gamma d).\n𝜅+𝛾𝐶≤𝜏(1+𝛾𝑑).\nIf C-\\tau d>0𝐶 −𝜏𝑑 >0, the largest safe multiplier is:\n\n\\boxed{\n\\gamma^*\n=\n\\min\\left(\n1,\n\\frac{\\tau-\\kappa}{C-\\tau d}\n\\right).\n}\n\\tag{10}\n𝛾∗=min(1,𝜏−𝜅𝐶−𝜏𝑑).(10)\nA lower \\gamma𝛾 reduces NED-derived consensus weight and rewards without changing pool ownership. Because nominal D_i𝐷𝑖, C𝐶, and d𝑑 stay fixed, the calculation is homogeneous and does not recursively cascade.\nWhile \\gamma<1𝛾 <1, new NED activation is frozen. A later increase in \\gamma𝛾 is activation-like and should consume accountable-safety/churn capacity.\nThe interaction between abrupt \\gamma𝛾 reduction and Ethereum’s accountable-safety properties, including the cost of deliberately inducing a global downweighting event, remains a consensus-analysis blocker.\n\n12. Base impairment and sticky eligibility\nA validator cannot voluntarily remove NED backing while active delegated principal depends on it.\nIf eligible base falls involuntarily from B_i^{old}𝐵𝑜𝑙𝑑𝑖 to B_i^{new}<B_i^{old}𝐵𝑛𝑒𝑤𝑖 <𝐵𝑜𝑙𝑑𝑖, assigned delegated principal is locally reduced by at least the same proportion:\n\n\\boxed{D_i^{new}\\le D_i^{old}\\frac{B_i^{new}}{B_i^{old}}.}\n\\tag{11}\n𝐷𝑛𝑒𝑤𝑖≤𝐷𝑜𝑙𝑑𝑖𝐵𝑛𝑒𝑤𝑖𝐵𝑜𝑙𝑑𝑖.(11)\nThe excess stops creating new consensus weight and enters retiring NED principal. The DCE is recomputed and \\gamma𝛾 supplies a network-wide backstop only if still required.\nVoluntary NED exit proceeds conceptually as:\n\n\\text{stop new allocation}\n\\rightarrow\n\\text{retire }D_i\n\\rightarrow\n\\text{accountability tail}\n\\rightarrow\n\\text{clear NED eligibility}.\nstop new allocation→retire 𝐷𝑖→accountability tail→clear NED eligibility.\nThis prevents an operator from briefly opting in to inflate coverage and then immediately removing backing after additional pool capacity activates.\n\n13. Consensus-weight semantics\nI previously explored making NED attestation-only to avoid execution-layer MEV leakage. I no longer think that should be the default design.\nSeparate finality and proposer stake bases create additional complexity across proposer boost, rewards and inactivity accounting.\nThe current reference direction is therefore:\n\n\\boxed{W_i=V_i+\\gamma D_i}\n𝑊𝑖=𝑉𝑖+𝛾𝐷𝑖\nfor stake-weighted consensus roles NED participates in.\nAt minimum this includes:\n\nFFG justification/finality weight,\nLMD-GHOST attestation weight,\nproposer selection probability,\nconsensus-layer attestation/proposer rewards and penalties,\ninactivity accounting,\nproposer and attester slashable authority.\n\nProposer boost should be normalized to total active NED consensus weight:\n\nW=\\sum_iW_i,\n𝑊=∑𝑖𝑊𝑖,\nso its scale remains tied to average attesting committee weight.\nSync-committee treatment remains open. Sync assignments are long-lived and light-client-facing, so I do not want to specify their NED semantics without dedicated modeling.\nA Core EIP would need to classify every current use of effective_balance and specify whether it consumes V_i𝑉𝑖, W_i𝑊𝑖, or a role-specific quantity.\n\n14. Rewards and execution revenue\nConsensus-layer rewards attributable to effective NED weight belong economically to the NED pool, subject to an eventual operator-compensation rule. A natural accounting model splits consensus-layer balance deltas between base and delegated ledgers according to their contribution to effective weight.\nPriority fees, builder payments and other MEV are not reliably measurable as one protocol-visible revenue stream, so NED does not pretend it can force all execution-layer value back into the pool.\nExecution-layer proposer revenue remains with the validator operator. This is an intentional operator rent and participation incentive, not a routing input. Operators cannot bid for more NED delegation because routing remains protocol-controlled.\nThe consequence is explicit: NED pool yield will generally be below the full economic return of directly operating validators and may be below products that successfully redistribute execution-layer MEV.\nNED also changes consensus reward economics. If W_i𝑊𝑖 is the effective balance used for rewarded consensus work, total active reward weight increases with effective NED delegation. The final specification must therefore define how W𝑊 enters the base-reward denominator and issuance accounting. NED does not promise that direct validators keep an unchanged per-ETH consensus yield as the pool grows.\nWhether native settlement, lower intermediary risk and application-layer liquidity wrappers compensate for the resulting yield trade-offs is an adoption question that needs modeling. NED does not introduce a synthetic issuance subsidy to hide them.\n\n15. Bootstrap and operator commitment\nCoverage matters because safe NED capacity grows with e𝑒, creating a two-sided coordination problem at launch.\nOperators can precommit validators to future NED eligibility subject to maturity and sticky exit, while delegators can enter a pending queue. Pending delegation has no consensus weight, reward or slashing exposure. Precommitted validators do not count as e𝑒, and pending principal does not count as D𝐷, until activation.\nIt does not guarantee adoption. The equilibrium needs agent-based modeling rather than a hand-selected bootstrap subsidy.\n\n16. Pool accounting and withdrawals\nNED uses one native pool rather than a dense delegator-to-validator graph. Users hold claims on a common pool NAV.\nThe protocol needs approximately:\n\npending and active pool principal,\nactive D_i𝐷𝑖 by validator,\nretiring non-voting principal,\npool shares or equivalent account claims,\nwithdrawal requests,\npending NED slashing notices.\n\nA protocol-native transferable LST is not required. Applications can wrap NED positions if they want liquidity.\nA withdrawal request does not immediately crystallize a fixed ETH amount. Requested shares remain inside the loss-bearing pool while their NED weight retires and while the delegated slashing claim window remains open.\nThis blocks the simplest slashing bank run: observing a likely offense does not let a user immediately lock an old NAV and leave everyone else with the loss.\nThe trade-off is pooled latent liability. A new depositor can enter while an old, not-yet-proven NED offense remains inside the bounded claim window.\nThe L1 primitive accepts that pooled risk to preserve fungibility. Higher-layer wrappers can provide stricter cohort isolation.\n\n17. Finite NED slashing claim window\nEthereum’s ordinary attester-slashing validity does not impose a simple fixed age limit on conflicting attestations while the validator remains slashable. That creates a fundamental boundary for pooled delegation.\nNED cannot simultaneously provide:\n\nunbounded historical delegated liability,\nfinite final withdrawal with no clawback,\nexact assignment of every arbitrarily late loss to the users who backed the old offense.\n\nThe reference design therefore gives the delegated component a finite claim window while leaving ordinary validator slashing rules unchanged.\nInitial reference value:\n\n\\boxed{W_{NED}=8192\\text{ epochs}}.\n\\tag{12}\n𝑊𝑁𝐸𝐷=8192 epochs.(12)\nThis aligns with EPOCHS_PER_SLASHINGS_VECTOR; ordinary Ethereum evidence does not expire at this boundary.\nA valid NED slashing notice submitted during the window preserves the corresponding pool liability even if settlement happens later.\nA withdrawal can settle only after:\n\n\\text{last NED exposure epoch}+W_{NED}\nlast NED exposure epoch+𝑊𝑁𝐸𝐷\nand after all timely pending NED notices that can affect it have resolved.\nA proof first presented after the NED window can still affect the ordinary validator under Ethereum’s normal slashing rules if applicable, but it no longer reaches an already-finalized historical NED claim.\nThis asymmetry is deliberate: without a liability-finality boundary, finite NED withdrawal is impossible. At current timing, 8192 epochs is roughly 36 days, so the liquidity cost is substantial.\n\n18. Historical NED exposure and proof ordering\nA slashable message may have been signed when a validator’s NED weight differed from its current weight.\nFor a slashable pair signed at states t_1𝑡1 and t_2𝑡2, define reference delegated exposure:\n\n\\boxed{\nX_i=\n\\min\\left(Q_i(t_1),Q_i(t_2)\\right).\n}\n\\tag{13}\n𝑋𝑖=min(𝑄𝑖(𝑡1),𝑄𝑖(𝑡2)).(13)\nFor double votes or surround votes this bounds the delegated principal common to both conflicting authorities. The exact delegated penalty schedule remains to be specified.\nIf D_i𝐷𝑖 and \\gamma𝛾 are committed in BeaconState, existing state roots and Capella historical summaries provide plausible commitment points for SSZ proofs of historical exposure. The historical-summary period is 256 epochs, so the reference window spans 32 periods. Exact proof format remains to be specified.\nNED liability also cannot rely only on the ordinary validator.slashed boolean. A validator could be slashed by one proof and later have another valid proof reveal larger historical NED exposure from the same participation period.\nFor each NED liability session, track maximum already-accounted exposure:\n\nX_i^{charged}.\n𝑋𝑐ℎ𝑎𝑟𝑔𝑒𝑑𝑖.\nFor each timely valid slashing notice with historical exposure X_i𝑋𝑖:\n\n\\boxed{\n\\Delta X_i\n=\n\\max(0,X_i-X_i^{charged})\n}\n\\tag{14}\nΔ𝑋𝑖=max(0,𝑋𝑖−𝑋𝑐ℎ𝑎𝑟𝑔𝑒𝑑𝑖)(14)\nthen:\n\nX_i^{charged}\\leftarrow\\max(X_i^{charged},X_i).\n𝑋𝑐ℎ𝑎𝑟𝑔𝑒𝑑𝑖←max(𝑋𝑐ℎ𝑎𝑟𝑔𝑒𝑑𝑖,𝑋𝑖).\nThus maximum accounted exposure is proof-order independent. A low-exposure proof cannot immunize a larger historical exposure.\nA NED slashing notice must satisfy the ordinary conflict/signature conditions, reference historical NED exposure, and arrive within the NED claim window. It can open NED liability only while the validator is slashable under ordinary rules. Once an NED liability session has been opened by a valid ordinary slashing, later timely proofs may increase X_i^{charged}𝑋𝑐ℎ𝑎𝑟𝑔𝑒𝑑𝑖 even though the validator is already marked slashed. This prevents proof ordering from hiding larger historical NED exposure without creating a new delegated liability after the base validator has already escaped ordinary slashability.\nIf D_i𝐷𝑖 reaches zero, the old session remains open through the NED claim window. A new clean participation session begins only after zero delegated exposure has persisted through that window.\n\n19. Churn and accountable safety\nNED must not create an unlimited side channel for rapidly adding or moving consensus weight.\nConceptually, D_i\\uparrow𝐷𝑖 ↑ is activation-like and D_i\\downarrow𝐷𝑖 ↓ is retirement-like. Moving principal from validator A𝐴 to validator B𝐵 is retirement followed by later activation.\nNormal changes in effective NED weight should consume Ethereum’s balance-based accountable-safety/churn budget, or a rigorously derived sub-budget within it.\nThe exceptional \\gamma𝛾 path is intentionally asymmetric: \\gamma𝛾 may fall quickly if necessary to restore the hard concentration envelope, but increasing \\gamma𝛾 is activation-like and should occur through churn.\nThe accountable-safety implications of abrupt \\gamma𝛾 reduction remain a blocking consensus question.\n\n20. Economic-finality and bypass limitations\nNED delegated principal is real slashable consensus capital while it contributes to W_i𝑊𝑖, but NED does not prove that V_i+D_i𝑉𝑖 +𝐷𝑖 is wealth economically owned by the validator controller.\nThe controller operates the key while delegators provide some supporting capital. The local limit \\ellℓ bounds this principal-agent leverage; it does not create an ownership oracle or prevent delegator losses.\nLikewise, a custodian can accept customer ETH and stake it directly outside NED. Ethereum cannot reliably distinguish proprietary ETH from customer ETH under the same credentials.\nNED targets a narrower feedback loop:\n\n\\boxed{\n\\text{customer use of provider }P\n\\not\\Rightarrow\n\\text{NED routing to provider }P\n}.\ncustomer use of provider 𝑃⇏NED routing to provider 𝑃.\nA provider may still become commercially large or increase its ordinary validator stake independently.\n\n21. Relationship to current specs and prior work\nCurrent-spec details referenced above come from the Phase 0 beacon-chain, fork-choice, Altair incentives, Capella beacon-chain, and Electra beacon-chain.\neODS is the closest Ethereum-native delegation substrate I have found. It explores protocol-level operator/delegator separation, explicit delegation accounting, churn and delegated slashing.\nRainbow Staking explores the broader separation of capital providers and validation services.\nEIP-7251 provides relevant precedent for variable validator effective balances and balance-based churn, but is not a native delegation mechanism.\nEIP-7685 provides a generic execution-layer-to-consensus request framework that may be useful for NED lifecycle operations.\nPrior native-liquid-staking work also explores protocol-wide validator-set exposure. NED does not claim universal proportional indexing as novel; universal proportional participation is the zero-amplification endpoint derived above.\nI do not claim native delegation, pooled staking, proportional allocation, fractional knapsack or operator/delegator separation individually as novel.\nThe narrower candidate contribution is the combination of:\n\nprovider-neutral pooled native delegation in which commercial provider choice is absent from routing,\nadditive base-stake routing chosen specifically for identity-split neutrality,\nthe zero-amplification boundary for identity-blind selective delegation,\nthe DCE as a hidden-coalition delegated-mass bound under incomplete participation,\ncoverage-adaptive capacity,\nseparate concentration, local-leverage and total-exposure limits,\nand a bounded pooled-liability path for historical NED slashing.\n\n22. Executable checks and remaining blockers\nThe current harnesses test conservative bucketed DCE computation, hidden-coalition bounds, proportional split invariance, coverage/capacity formulas, global \\gamma𝛾 safety downweighting, proposer-boost normalization to NED consensus weight, base-impairment handling, bounded pooled withdrawal liability, NED session separation and proof-order independence.\nRecent runs included 151,551 hidden-coalition checks plus split, proposer-boost, slashing-order and pooled-liability fuzzing. These are mechanism tests, not a consensus implementation or safety proof.\nBefore a Core EIP, I think at least the following remain blocking:\n\nSelect and justify \\kappa𝜅, \\ellℓ, \\LambdaΛ, DCE precision and the NED claim window.\nProduce Pyspec for activation, routing, retirement, \\gamma𝛾, pool accounting and historical slashing.\nAudit every consensus-spec use of effective_balance against V_i𝑉𝑖, W_i𝑊𝑖, or a role-specific quantity.\nComplete accountable-safety and adversarial-griefing analysis for exceptional \\gamma𝛾 reduction.\nResolve sync-committee semantics.\nSpecify delegated and correlated-slashing penalties.\nSpecify and benchmark historical exposure proofs against existing state-history commitments.\nModel operator participation and bootstrap equilibrium.\nModel issuance, direct-validator yield, operator rent and NED adoption, including the execution-revenue gap.\nMeasure state growth and epoch-processing cost for the DCE histogram, pool accounting and notice queues.\n\nThe claims I would most like attacked are:\n\n\\boxed{D_i=uB_i}\n𝐷𝑖=𝑢𝐵𝑖\nas the split-neutral target;\n\n\\boxed{\nC(m)=\n\\max_{\\sum z_i b_i\\le m}\n\\sum z_i y_i\n}\n𝐶(𝑚)=max∑𝑧𝑖𝑏𝑖≤𝑚∑𝑧𝑖𝑦𝑖\nas the hidden-coalition delegated-mass envelope; and\n\n\\boxed{\n\\kappa+\\gamma C(\\min(\\kappa,e))\n\\le\n\\tau(1+\\gamma d)\n}\n𝜅+𝛾𝐶(min(𝜅,𝑒))≤𝜏(1+𝛾𝑑)\nas the resulting full-network amplification bound.\nIf one of those fails, I would rather find the counterexample directly than hide it under another pricing curve or identity assumption.\n\nConclusion\nThe original problem is simple:\n\nCommercial staking-provider success can translate into additional consensus power because the user’s provider choice also influences where delegated stake operates.\n\nNED removes that choice from the native routing primitive.\nIt does not try to identify which validators are genuinely independent or which operator identities belong together.\nLinear routing makes validator-identity subdivision irrelevant to target allocation.\nThe Delegation Concentration Envelope bounds how much NED principal can actually be packed into any hidden coalition below a chosen base-stake threshold.\nCoverage determines scale. At low participation, NED is deliberately constrained. At broad participation, it can become economically meaningful. At universal proportional participation, relative amplification tends to zero.\nThe question is not whether NED can eliminate Ethereum staking concentration. It cannot.\nThe question I think is worth testing is:\n\nCan Ethereum provide a provider-neutral native delegation path whose ability to scale is mathematically tied to broad validator participation, while bounding the additional consensus leverage created by delegated capital without relying on a real-world ownership oracle?\n\nWorking name: Native Ethereum Delegation (NED).\nInformally: the Flanders Protocol.\n\n read \n\n 9\n min\n\n Powered by Discourse","tokens":7553,"squid":"ink-research","role":"Deep Scholar","at":1791268286421,"hash":"22db529161c48684ba7b62f7798d47e380456325"}
{"url":"https://forum.pyth.network/t/community-council-term-2-budget-request/2419/1","domain":"forum.pyth.network","title":"Community Council Term 2 Budget Request - Community Council - Pyth DAO","text":"Community Council Term 2 Budget Request \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 6\n min\n\n Mar 25\n\n 1 / 5\n\n Mar 25\n\n Apr 14\n\n post by Chop on Mar 25\n\n Chop\n\n Community Council Term 2 Budget Proposal\nSummary\nWe’re requesting 8,000,000 PYTH over 12 months (~666,667 PYTH/month or $328,000 as of March 25th, 2026) for Community Council Term 2.\nTerm 2 matches the budget to real program costs AND adds the unified content creation engine as the major new initiative, replacing Kaito and Impact Awards for a more direct, value added content creation mechanism that is more in line with the development of the broader crypto ecosystem.\n\nWhy 8M PYTH?\nTerm 1 Proved the Model Worked, but Required Refinement\nCouncil term #1 burn rate was relatively low and reflected the real cost of operating community programs (Impact Awards, Kaito, council stipends, experiments). With Kaito winding down, the council has collectively researched and built a new Kaito-esque program that is better designed and refined to achieve very specific reach goals on socials.\nKey cost drivers that grew during Term 1:\n\nKaito: Grew from 35,000 → 234,000 PYTH/month as the platform received more attention. The platform crashed and burned, and no longer exists.\n\nImpact Awards: Consistent monthly distribution to 40+ contributors. Quality diminished over time as ‘farmers’ discovered ways to take advantage of the system.\n\nExperiments Lab: Funded community development (Community Ops, Pythentity)\n\nTerm 2 Consolidates and Scales\nThe old budget categories — Role Stipends, Impact Awards, Kaito, Experiments Lab — are being replaced by a unified system. Impact Awards, the Clipping Program, and MissionMonitor are no longer separate line items. They’re one content creation engine:\nMissions (MissionMonitor) → Content Creation → Clipping (PythClippers) → Referrals → Rewards\n6M of the 8M PYTH budget flows through this unified engine. This is a consolidation of many different programs under a single unified banner that can be closely monitored. Three programs that previously had separate budgets, separate tracking, and separate oversight now run through one system with automated tracking, judging, and treasury export.\n\nTerm 2 Budget Breakdown\n\nCategory\nMonthly PYTH\nAnnual PYTH\nDescription\n\nContent Program\n500,000\n6,000,000\nUnified Content Creation Program\n\nOngoing Hackathon\n200,000\n400,000\nPromoting ongoing Pyth Development and Content Showcases with community builders\n\nPythentity\nTBA\n200,000\nGamified Community identity layer & Rewards system for Pyth evangelists.\n\nRole Stipends\n~46,000\n560,000\nRole stipends, covering core content and community lore creators.\n\nCouncil Stipend\n10,000\n840,000\nCouncil Member Payments for ongoing management.\n\nWhat Term 2 Funds\n1. MissionMonitor Content Engine (Primary Allocation)\nThe unified system for community content creation, distribution, and rewards.\n\nMissions: Campaign briefs distributed via Telegram + Discord. Community creates content around Pyth milestones, launches, partnerships, and product updates.\n\nClipping Program: MissionMonitor bot handles submission tracking and leaderboards for socials content. 134+ video transcripts ready for clipping alongside a comprehensive content guidebook.\n\nReferrals: Built-in referral system with attribution tracking, 10% referrer split, and 90-day expiry. Incentivizes community growth through content participation.\n\nSoft Identity Gating: All programs can be gated through Pythentity for sybil resistance. Verified contributors & Pyth evangelists receive preferential treatment.\n\nInfrastructure already built: MissionMonitor (live), Referrals System (90% complete), Pythentity (MVP live), Google Sheets export (live).\n2. Pyth Playground (Vibecodeathon)\nRecurring 6-week community hackathon for builders of all skill levels. AI-assisted “vibe coding” format lowers barriers. Each submission creates public content pieces (GEO requirements built in).\n\nRound 1 currently live with active submissions\n\nTarget: 3–5 rounds in Term 2\n\nPrize pool: ~200,000 PYTH per round\n\nConfirmed judges from Community Council\n\n3. Pythentity (Identity Layer)\nCommunity-native identity and reputation system. Wallet verification + Discord OAuth + NFT gating + behavioral scoring. Gates all incentive programs for sybil resistance.\nTerm 2 scope:\n\nCross Chain & additional wallet support.\n\nCross-platform identity bridge (Discord + Telegram + Forum)\n\nIntegration with PythClippers and MissionMonitor for automatic score updates\n\nDomain migration + repo transfer\n\nProcess remaining grant funds\n\nTerm 1 Financial Transparency\nFull actuals from Google Sheet — Full breakdown.\nCycle 1 (April – September 2025)\n\nCategory\nBudget\nSpent\nRemaining\n\nRole Stipends\n120,000\n155,718\n-35,718\n\nImpact Awards\n210,000\n224,396\n-14,396\n\nKaito\n1,000,000\n477,887\n522,113\n\nExperiments Lab\n90,000\n44,180\n45,820\n\nCouncil Stipend\n420,000\n420,000\n0\n\nTotal\n1,840,000\n1,322,181\n517,819\n\nCycle 2 (October 2025 – March 2026)\n\nCategory\nBudget\nSpent\nRemaining\n\nRole Stipends\n120,000\n284,140\n-164,140\n\nImpact Awards\n210,000\n189,524\n20,476\n\nKaito\n600,000\n1,015,871\n-415,871\n\nExperiments Lab\n480,000\n403,800\n76,200\n\nCouncil Stipend\n420,000\n420,000*\n0\n\nContingency\n60,000\n35,050\n24,950\n\nTotal\n1,890,000\n2,348,384\n-458,384\n\n*Council Stipend is paid directly from the DAO treasury to council members — not from the council multisig. This avoids a conflict of interest (council members don’t pay themselves). Cycle 2 stipend is committed but not yet disbursed.\nKey takeaway: Kaito alone consumed 53% of total Term 1 spend and exceeded its Cycle 2 budget by 415K PYTH. Role Stipends also exceeded budget in both cycles as the community role system expanded. Council Stipend shows 0 spent because stipends are paid directly by the DAO to avoid a conflict of interest — council members don’t pay themselves from their own multisig.\n\nGovernance & Accountability\nReporting\n\nQuarterly budget reports posted to forum with PYTH spent per category\n\nQuarterly reviews with program metrics (participation, content output, community growth)\n\nAll operational tooling (MissionMonitor, PythClippers) produces auditable logs\n\nGoogle Sheets treasury tracker publicly viewable\n\nUnused Funds\n\nAll unused funds return to the DAO treasury. No rollover, no discretionary holdback.\n\nTerm 1 wallet currently holds 376,480.91 PYTH. Remaining funds may be used during the interim period to bridge into Term 2 content programs, avoiding dead time between budget approval and program launch. Any balance beyond interim operations returns to the DAO.\n\nFunding Source\n\nDAO treasury, executed via binding governance proposal\n\nFunds transfer is automatic upon proposal execution\n\nWhat’s Different About Term 2\n\nTerm 1\nTerm 2\n\nBuilt MissionMonitor\nRun missions at scale on MissionMonitor\n\nBuilt PythClippers\nLaunch clipping program with dedicated PYTH pool\n\nBuilt Pythentity MVP\nGate all incentive programs through Pythentity\n\nSeparate budgets for Impact Awards, Kaito, Experiments Lab\nUnified content creation engine — one system, one budget\n\n35K PYTH/month approved budget\nRight-sized to actual operational costs\n\nPrograms built\nPrograms running\n\nThe infrastructure is built. The strategy is documented. The tools are operational. Term 2 is about making these systems produce results at scale.\n\nConclusion\nTerm 1 built the infrastructure. Term 2 runs the machine.\nThe Community Council exists to make Pyth’s community a genuine competitive advantage — verified contributors who know the product, build with the data, and produce content that compounds in value. The unified content creation engine (MissionMonitor + PythClippers + Pythentity) is how we do that at scale with proper accountability.\nRequesting approval for a 12-month budget of 8,000,000 PYTH (4,000,000 PYTH per 6-month cycle). Cycle 2 allocation may be adjusted based on PYTH price at the time of renewal.\n\nQuestions? Tag the Community Council in Discord or comment on this proposal.\n\n [PASSED] OP-PIP-114: Community Council Term 1 Cycle 2 Stipend Disbursement\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n Guide for the Community Council Election #2\n\n 2\n\n read \n\n 6\n min\n\n post by Mersault on Mar 26\n\n post by PilotSB on Mar 30\n\n 12 days later\n\n post by Pythian_151 on Apr 12\n\n post by Chop on Apr 14\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n Community Council Term #1 Exit Report\n\n Community Council\n\n 4\n\n 195\n\n Mar 29\n\n Pyth Community Council\n\n Ideas Bank\n\n 73\n\n 1.7k\n\n Aug 2024\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":2208,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268293534,"hash":"789fb24c418d94a1c711e6f3755662130fe75d3e"}
{"url":"https://io.net/blog/artificial-intelligence","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogArtificial IntelligenceLatest By Topic (31)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsThe Token Cost Paradox: Why cheaper inference doesn't mean cheaper AI billsIO.NET Team / Aug 27, 2026The AI budget conversation is the hot topic this year. So, it’s safe to say that If you've probably heard some version of this line: token costs are falling fast and AI is about to get a lot cheaper. \n\nIt's a reasonable proposition. You want to believe it. But according to Gartner's own research, it’s a notion that is mostly wrong for the people actually paying the bills.\n\nGartner's forecast, published this spring, makes some other striking proclamations. By 2030, they believe that running inferWhat happens when you can't get a GPU? The hidden cost of cloud wait timesIO.NET Team / Aug 18, 2026Let’s imagine that you’ve budgeted $10,000 for an AI/LLM training run. You hop on  AWS and the app says, “no H100s available for 72 hours”. Apart from some stress and frustration, what does that delay actually cost your team?\n\nIn answering that question, perhaps like Thanos, when asked by Dr. Strange how much it cost to collect the infinity rings, he replied: “Everything”. All joking aside, most finance models would record “zero”. There’s no invoice because you’ve consumed no GPU-hours. Your $10Who Decides What Your AI Can Say? Inside Model Censorship and AlignmentIO.NET Team / Aug 15, 2026When you ask an AI to help with something and it refuses, that refusal didn't happen by accident. Someone, or more precisely, a team of researchers, lawyers, and ethicists at a major AI lab, made a deliberate choice to build that boundary into the model. Today, major model providers (e.g. OpenAI, Anthropic, Google, Meta, Mistral, and Cohere) each maintain their own alignment teams, each with distinct values, risk tolerances, and commercial pressures shaping what their models will and won't do. TData sovereignty in the age of AI: Why location is everything for training and inferenceIO.NET Team / Aug 7, 2026Cloud storage abstracts away the very urgent compliance question that any AI startup or LLM research project should be asking itself: Where does my data physically sit? The answer to this question has very real and direct consequences, including legal, financial, and operational. Under GDPR, processing EU personal data on US-based infrastructure without adequate safeguards exposes companies to fines up to €20 million or 4% of global annual turnover, whichever is higher. Beyond regulation, there GPU Cluster for AI: 2026 Buyer's Guide With Benchmarks & TCO CalculatorIO.NET Team / Jun 8, 2026Your 2026 guide to building a purpose-built GPU cluster for AI. Includes TCO, vendor-agnostic benchmarks, hardware selection (H100/MI300X), and rollout plan.GLM-4.7 Flash Now Available on io.intelligenceIO.NET Team / Jan 23, 2026Z.ai's GLM-4.7-Flash (30B MoE) is live on io.intelligence. Get the strongest 30B model for coding & reasoning with best-in-class performance-per-dollar.Decentralized Computing in 2025: Architecture, Costs, and Migration GuideIO.NET Team / Jan 20, 2026Complete technical guide to decentralized compute: benchmarks, cost calculator, compliance checklist, and step-by-step migration from AWS/GCP.GLM-4.7 Now Available on io.intelligenceIO.NET Team / Jan 13, 2026GLM-4.7 is now live on io.intelligence. Z.ai's open-source coding model scores 84.9% on LiveCodeBench vs Claude's 64%. Access it via a single API endpoint.GPU vs CPU for AI: Complete Performance, Cost, and Use Case Comparison for 2025IO.NET Team / Nov 21, 2025Complete comparison of GPU vs CPU for AI: deep learning performance, hardware cost, TCO, and ideal use cases. Choose the right processor for your training and inference workloads.Introducing Unified Chat: One Interface for Every AI Model and ToolIO.NET Team / Nov 4, 2025Unified Chat is the single, intelligent AI workspace that unifies every model and tool. Auto-routes for optimal quality and cost. End fragmentation.io.net Breaks $20M in Annualized On-Chain RevenueIO.NET Team / Oct 21, 2025io.net surpasses $20M in verifiable on-chain revenue, proving decentralized GPU infrastructure can compete with AWS and GCP on cost, performance, and real-world adoption.AI Data Centers: Optimizing Workloads and Infrastructure EfficiencyIO.NET Team / Oct 9, 2025Discover how AI data centers optimize workloads, boost efficiency, and power the future of artificial intelligence with advanced infrastructure.Page 1 of 3","tokens":1196,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268293584,"hash":"3b0fbb369d87dc766acf9bf56582ecfdb91334ff"}
{"url":"https://io.net/blog/glm-4-7-flash-now-available-on-io-intelligence","domain":"io.net","title":"GLM-4.7 Flash Now Available on io.intelligence","text":"Back To BlogGLM-4.7 Flash Now Available on io.intelligenceIO.NET Team / Jan 23, 2026Try io.intelligenceGet StartedTry io.cloudDeploy GPUArtificial Intelligence#matthewio.intelligenceAI Startup CornerGLM-4.7-Flash is now live on io.intelligence. Z.ai's 30B MoE model brings GLM-4.7's coding DNA to a lighter architecture built for cost-efficient inference.GLM-4.7-Flash delivers 91% of the flagship's coding ability at roughly 10% of the compute. It activates just 3B parameters per forward pass, which means predictable latency and dramatically lower serving costs. For high-volume inference or resource-constrained deployments, it's a tradeoff that makes a ton of sense.BenchmarksGLM-4.7-Flash dominates its weight class. On SWE-bench Verified, it hits 59.2%, nearly tripling Qwen3-30B-A3B-Thinking's 22.0%. Tool orchestration on τ²-Bench reaches 79.5%, outperforming models with far more parameters. Math reasoning stays sharp at 91.6% on AIME 2025.\n\nBenchmarkGLM-4.7-FlashQwen3-30B-A3B-ThinkingGPT-OSS-20B\n SWE-bench Verified\n 59.2%22.0%34.0%\n τ²-Bench (Tool Use)\n 79.5%49.0%47.7%\n BrowseComp\n 42.8%22.9%28.3%\n AIME 2025 (Math)\n 91.6%85.0%91.7%\n\nSource: Z.aiThe tradeoff shows on harder reasoning. HLE drops to 14.4% versus GLM-4.7's 42.8%. And SWE-bench trails the flagship's 73.8%. For maximum accuracy on complex codebases, the full model is still the better choice.Where GLM-4.7-Flash CrushesThis model is built for throughput. Coding assistants handling hundreds of concurrent users. Automated pipelines processing large volumes of code. Development environments where latency matters more than peak reasoning depth.Z.ai kept Interleaved Thinking and improved frontend generation from the flagship. The 200K context window handles large codebases without truncation.Running GLM-4.7-Flash on io.intelligenceEven a 30B model needs GPU resources to self-host properly. Through io.intelligence, GLM-4.7-Flash is accessible via a single API alongside the full GLM-4.7 and the complete model library.Route high-volume tasks to Flash, complex reasoning to the flagship. Same endpoint, different model parameter.Ready to run inference at 1/10th the cost?GLM-4.7-Flash delivers 91% of flagship coding performance.Try GLM-4.7-Flash Now","tokens":558,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268303490,"hash":"c95028aee03ecfbd9397a288a5a6ba0ff24febec"}
{"url":"https://forum.pyth.network/t/community-council-term-2-budget-request/2419/5","domain":"forum.pyth.network","title":"Community Council Term 2 Budget Request - Community Council - Pyth DAO","text":"Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 6\n min\n\n Mar 25\n\n 5 / 5\n\n Apr 15\n\n Apr 14\n\n post by Chop on Mar 25\n\n Chop\n\n Community Council Term 2 Budget Proposal\nSummary\nWe’re requesting 8,000,000 PYTH over 12 months (~666,667 PYTH/month or $328,000 as of March 25th, 2026) for Community Council Term 2.\nTerm 2 matches the budget to real program costs AND adds the unified content creation engine as the major new initiative, replacing Kaito and Impact Awards for a more direct, value added content creation mechanism that is more in line with the development of the broader crypto ecosystem.\n\nWhy 8M PYTH?\nTerm 1 Proved the Model Worked, but Required Refinement\nCouncil term #1 burn rate was relatively low and reflected the real cost of operating community programs (Impact Awards, Kaito, council stipends, experiments). With Kaito winding down, the council has collectively researched and built a new Kaito-esque program that is better designed and refined to achieve very specific reach goals on socials.\nKey cost drivers that grew during Term 1:\n\nKaito: Grew from 35,000 → 234,000 PYTH/month as the platform received more attention. The platform crashed and burned, and no longer exists.\n\nImpact Awards: Consistent monthly distribution to 40+ contributors. Quality diminished over time as ‘farmers’ discovered ways to take advantage of the system.\n\nExperiments Lab: Funded community development (Community Ops, Pythentity)\n\nTerm 2 Consolidates and Scales\nThe old budget categories — Role Stipends, Impact Awards, Kaito, Experiments Lab — are being replaced by a unified system. Impact Awards, the Clipping Program, and MissionMonitor are no longer separate line items. They’re one content creation engine:\nMissions (MissionMonitor) → Content Creation → Clipping (PythClippers) → Referrals → Rewards\n6M of the 8M PYTH budget flows through this unified engine. This is a consolidation of many different programs under a single unified banner that can be closely monitored. Three programs that previously had separate budgets, separate tracking, and separate oversight now run through one system with automated tracking, judging, and treasury export.\n\nTerm 2 Budget Breakdown\n\nCategory\nMonthly PYTH\nAnnual PYTH\nDescription\n\nContent Program\n500,000\n6,000,000\nUnified Content Creation Program\n\nOngoing Hackathon\n200,000\n400,000\nPromoting ongoing Pyth Development and Content Showcases with community builders\n\nPythentity\nTBA\n200,000\nGamified Community identity layer & Rewards system for Pyth evangelists.\n\nRole Stipends\n~46,000\n560,000\nRole stipends, covering core content and community lore creators.\n\nCouncil Stipend\n10,000\n840,000\nCouncil Member Payments for ongoing management.\n\nWhat Term 2 Funds\n1. MissionMonitor Content Engine (Primary Allocation)\nThe unified system for community content creation, distribution, and rewards.\n\nMissions: Campaign briefs distributed via Telegram + Discord. Community creates content around Pyth milestones, launches, partnerships, and product updates.\n\nClipping Program: MissionMonitor bot handles submission tracking and leaderboards for socials content. 134+ video transcripts ready for clipping alongside a comprehensive content guidebook.\n\nReferrals: Built-in referral system with attribution tracking, 10% referrer split, and 90-day expiry. Incentivizes community growth through content participation.\n\nSoft Identity Gating: All programs can be gated through Pythentity for sybil resistance. Verified contributors & Pyth evangelists receive preferential treatment.\n\nInfrastructure already built: MissionMonitor (live), Referrals System (90% complete), Pythentity (MVP live), Google Sheets export (live).\n2. Pyth Playground (Vibecodeathon)\nRecurring 6-week community hackathon for builders of all skill levels. AI-assisted “vibe coding” format lowers barriers. Each submission creates public content pieces (GEO requirements built in).\n\nRound 1 currently live with active submissions\n\nTarget: 3–5 rounds in Term 2\n\nPrize pool: ~200,000 PYTH per round\n\nConfirmed judges from Community Council\n\n3. Pythentity (Identity Layer)\nCommunity-native identity and reputation system. Wallet verification + Discord OAuth + NFT gating + behavioral scoring. Gates all incentive programs for sybil resistance.\nTerm 2 scope:\n\nCross Chain & additional wallet support.\n\nCross-platform identity bridge (Discord + Telegram + Forum)\n\nIntegration with PythClippers and MissionMonitor for automatic score updates\n\nDomain migration + repo transfer\n\nProcess remaining grant funds\n\nTerm 1 Financial Transparency\nFull actuals from Google Sheet — Full breakdown.\nCycle 1 (April – September 2025)\n\nCategory\nBudget\nSpent\nRemaining\n\nRole Stipends\n120,000\n155,718\n-35,718\n\nImpact Awards\n210,000\n224,396\n-14,396\n\nKaito\n1,000,000\n477,887\n522,113\n\nExperiments Lab\n90,000\n44,180\n45,820\n\nCouncil Stipend\n420,000\n420,000\n0\n\nTotal\n1,840,000\n1,322,181\n517,819\n\nCycle 2 (October 2025 – March 2026)\n\nCategory\nBudget\nSpent\nRemaining\n\nRole Stipends\n120,000\n284,140\n-164,140\n\nImpact Awards\n210,000\n189,524\n20,476\n\nKaito\n600,000\n1,015,871\n-415,871\n\nExperiments Lab\n480,000\n403,800\n76,200\n\nCouncil Stipend\n420,000\n420,000*\n0\n\nContingency\n60,000\n35,050\n24,950\n\nTotal\n1,890,000\n2,348,384\n-458,384\n\n*Council Stipend is paid directly from the DAO treasury to council members — not from the council multisig. This avoids a conflict of interest (council members don’t pay themselves). Cycle 2 stipend is committed but not yet disbursed.\nKey takeaway: Kaito alone consumed 53% of total Term 1 spend and exceeded its Cycle 2 budget by 415K PYTH. Role Stipends also exceeded budget in both cycles as the community role system expanded. Council Stipend shows 0 spent because stipends are paid directly by the DAO to avoid a conflict of interest — council members don’t pay themselves from their own multisig.\n\nGovernance & Accountability\nReporting\n\nQuarterly budget reports posted to forum with PYTH spent per category\n\nQuarterly reviews with program metrics (participation, content output, community growth)\n\nAll operational tooling (MissionMonitor, PythClippers) produces auditable logs\n\nGoogle Sheets treasury tracker publicly viewable\n\nUnused Funds\n\nAll unused funds return to the DAO treasury. No rollover, no discretionary holdback.\n\nTerm 1 wallet currently holds 376,480.91 PYTH. Remaining funds may be used during the interim period to bridge into Term 2 content programs, avoiding dead time between budget approval and program launch. Any balance beyond interim operations returns to the DAO.\n\nFunding Source\n\nDAO treasury, executed via binding governance proposal\n\nFunds transfer is automatic upon proposal execution\n\nWhat’s Different About Term 2\n\nTerm 1\nTerm 2\n\nBuilt MissionMonitor\nRun missions at scale on MissionMonitor\n\nBuilt PythClippers\nLaunch clipping program with dedicated PYTH pool\n\nBuilt Pythentity MVP\nGate all incentive programs through Pythentity\n\nSeparate budgets for Impact Awards, Kaito, Experiments Lab\nUnified content creation engine — one system, one budget\n\n35K PYTH/month approved budget\nRight-sized to actual operational costs\n\nPrograms built\nPrograms running\n\nThe infrastructure is built. The strategy is documented. The tools are operational. Term 2 is about making these systems produce results at scale.\n\nConclusion\nTerm 1 built the infrastructure. Term 2 runs the machine.\nThe Community Council exists to make Pyth’s community a genuine competitive advantage — verified contributors who know the product, build with the data, and produce content that compounds in value. The unified content creation engine (MissionMonitor + PythClippers + Pythentity) is how we do that at scale with proper accountability.\nRequesting approval for a 12-month budget of 8,000,000 PYTH (4,000,000 PYTH per 6-month cycle). Cycle 2 allocation may be adjusted based on PYTH price at the time of renewal.\n\nQuestions? Tag the Community Council in Discord or comment on this proposal.\n\n [PASSED] OP-PIP-114: Community Council Term 1 Cycle 2 Stipend Disbursement\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n Guide for the Community Council Election #2\n\n 2\n\n read \n\n 6\n min\n\n post by Mersault on Mar 26\n\n Mersault\n\n Great news. I was incredibly frustrated with the farmers and I’d love to weed out everyone who’s just farming rewards. The larger budget provides more opportunities , everything built in Term 1 needs to be scaled, and it’s time to keep pushing forward.\nThe only thing that worries me is the referral program. For some reason, it’s an immediate red flag for me. It could potentially bring in people who will just abuse the system and invite low-quality users. But I think the scoring system will be able to handle it\n\n post by PilotSB on Mar 30\n\n PilotSB\n\n getting hot on transperancy, another banger ser chop\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n 12 days later\n\n post by Pythian_151 on Apr 12\n\n Pythian_151\n\n From April 2025 to March of 2026, we spent 3,670,655 PYTH on all marketing programs. How can we state that this has lead to greater adoption when the price of the token has fallen from approximately 0.40 cents to 0.04 cents. Now we are asking 8,000,000 PYTH from the DAO to spend on marketing more specificity, 6,000,000 for content creators equating to the whole amount of the DAO current reserve..\nOne of the purpose of conducting share buy backs in this case token buy backs is to reduce the pressure of dilution and improve EPS.\nSince the marketing has shown not to be as successful as we thought it would be, should we be more careful with our spending and instead concentrate on letting the product speaks for itself i.e PYTH pro.\nSomeone creating a YouTube video content or retwitting on X is not going to incentivise big institutions to pay 10,000 per month, rather the quality of the price feed will.\nMay be we could spend 10-15 percent of the monthly DAO revenue on marketing with the rest of the earnings for continued buybacks.\nSpending less and building up the DAO reserve will help conteract the selling pressures from staking rewards and unlocks and give the price a chance to move in a favourable direction ?\n\n post by Chop on Apr 14\n\n Chop\n\n gm Pythian_151.\nFirst off, banger reply. Quality FUD. I love an opportunity to respond to genuine feedback around the Community Council budget. I commend you for reading and absorbing it all - most people don’t. Your willingness to engage Pyth with critiques on programs like this is what makes our community great. Keep it coming!\nA couple of points i think are worth noting on this portion of our spend;\n\nIn our view, adoption is a lot more than just ‘token go up’. In fact, token go up (the council believes) has nothing to do with adoption. Pyth adoption (measured in subscription terms) is up considerably! Our Quarter on Quarter growth in subscriptions is well over 100%, and we’re growing above projections. To add to that; we have been actively expanding our revenue collection mechanics (see the Listing as a Service governance proposal as an example). Price Feeds are expanding aggressively and their usage is accelerating in line with adoption.\nThe Community Council budget (which i believe is what you are referring to) serves many different purposes. The ‘why’ of the councils’ spending is not immediately obvious to those who dont directly participate, so let me break it down a bit;\n\nOur recent Polymarket partnership exists partly because of our highly engaged and ‘loud’ community has made it known to Polymarket team that we are serious players within the space. Pyth’s Data Marketplace is also a direct beneficiary of community noise and our ability to provide retail data (also see the Polymarket $99 retail subscription). In this regard, the marketing spend is not necessarily visible directly in results, but is instead measured in aura.\n\nKaito - Now discontinued. This was our largest line item spend last year. Pyths’ spend when compared to most other Kaito budgets was much smaller. Moreover, our spend was HIGHLY targeted and rewarded only those who were making substantive contributions. We (the council) audited submissions meticulously and filtered low quality AI submissions as we reasonably could in order to make the spend as fair as possible.\nThis allowed us to create a new Kaito-like system with larger safeguards, stricter contribution guidelines & gives us variability and control over our community rewards spend moving forward. You’ll hear more on this over the next couple of months as we report on its progress and efficacy. This will be run as a trial during the second term and adjusted as necessary, based on feedback from people such as yourself!\n\nPyth Community Hackathon - ongoing. The most successful Hackathon Pyth has ever participated in (including IRL based events). 35+ submissions that showcase what is possible leveraging Pyth Pro data, but make a significant dent in our AI Discoverability and referencing Pyth in builders’ channels such as Github. This hackathon has contributed immensely to our ability to deliver resources to the broader Pyth community;\n\nFree Pyth Access to whoever wants it.\nOpen, discoverable ideas & developer community tools\ncurrent budget request has the hackathon as a big part of the Councils’ output in this next term due to its current success\n\nPythentity - this one is a long game on the community NFT’s. Our hope (as a council and as a community) is that we will be able to create an all inclusive platform for community participants that allows the following;\n\nAccess to Hackathon dApps built by community (we see the monitoring tools made using Pyth DAta and games on entropy as a public educational goods)\nA ‘passport’ that functions as proof of your interaction across the Pyth Powered ecosystem.\nA central ‘hub’ for community contributions, builder resources & educational content to help retail (and trader) participants wrap their head around Pyth WITHOUT the institutional an focus or formalized clutter.\nAn access point to Pyth that is retail focused (and community built) instead of institutionally minded.\n\nRole Stipends - these are arguably our least obvious spend. However, we maintain a core group of highly engaged community members who contribute across multiple different channels using this mechanic as a buffer for the time they dedicate to Pyth. The 70% hold metric also applies to these stipends.\nPyth one of the most engaged market Discord channels that i’m aware of, which constantly provides value to the broader community with its weekly streams, analysis and market dissections. Our Chirons are some of the most well educated retail consumers of Pyth in the space - they are the cultural heartbeat of our Brand that are ready and willing to refute FUD and bull post the virtues of Pyth at a moments notice.\nThese mechanics are highly variable & subjective. The participants are reviewed monthly.\n\nImpact Awards & Misc Spending - Used to create highly specific content across different platforms. This spans TikTok, Reddit, Discord & Telegram. We use this portion of the budget to build a library of ‘content’ that allows us to onboard new community members, populate forums and channels with educational content AND help us moderate disparate language communities and niche content channels. This includes the newly created Content Library here in the DAO forum, which will be expanded to Reddit and a soon to be created community blog.\n\nTo address your concerns about marketing spend and ‘adoption’ more directly; institutions are motivated by results, data efficacy and security more than anything else. Over the past 2 years Pyth has been has constant presence within the broader data market place and social channels (almost solely due to the Community Councils’ efforts). We have expanded our data offering (and data efficacy) significantly over that time, with more price feeds being added on a weekly basis, and usage increasing week on week. We have shown that the Pyth price does very little in way of us being able to deliver a world class product that institutions and retail consumers alike wish to use. You will notice that our community almost NEVER discusses the price of Pyth - and for good reason. It is not what motivates us, nor do we believe should it. We are dedicated to deliver a world class product that is changing the face of finance in real, measurable ways day in, day out. That, we believe, is our strongest asset and proof point which gets validated to us on a weekly basis. 95% of HIP-3 volume. 24/7/365 always-on markets and deep crypto & institutional adoption is what we grade ourselves on. In this regard, be believe price is a lagging indicator of where Pyth is headed. As long as our leading indicators (as above) are heading in the right direction (they are) we are happy.\nfinally; We think deeply about our token economics and how to better shape them for now and into the future. Rest assured, we believe the level of spending requested by the council is both reasonable and in line with expectations of future growth. We as community participants remain extremely bullish on what Pyth is able to achieve with the help of people such as yourself.\nI will also look into your Discord ban (which you have mentioned elsewhere). This is an oversight on my behalf, and as long as you were conduction yourself respectfully and in line with our expectations of community members, you should not have been banned. I will get this revoked ASAP. I welcome discussion like this wherever possible!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n Community Council Term #1 Exit Report\n\n Community Council\n\n 4\n\n 195\n\n Mar 29\n\n Pyth Community Council\n\n Ideas Bank\n\n 73\n\n 1.7k\n\n Aug 2024\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":4514,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268303758,"hash":"9dfa5f0cc38b73bf2f23a7e37fe63b95c4c620c5"}
{"url":"https://ethresear.ch/c/proof-of-stake/5/l/latest","domain":"ethresear.ch","title":"Latest Proof-of-Stake topics - Ethereum Research","text":"Latest topics in Proof-of-Stake\n\n Proof-of-Stake\n\n subcategories\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Proof-of-Stake category\n\n Proof-of-Stake\n\n Discussion related to Proof-of-Stake (PoS). \nSee also: \nhttps://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ \nhttps://github.com/ethereum/casper \nhttps://github.com/ethereum/research/tree/master/papers/casper\n\n 1\n\n 3.9k\n\n Dec 2017\n\n Timing the Head in Ethereum PoS\n\n Economics\n\n 2\n\n 246\n\n Sep 1\n\n ePBS, distilled\n\n Block proposer\n\n mev\n\n 10\n\n 866\n\n Aug 29\n\n Properties of issuance offsets and increased penalties under low/zero/negative issuance policies\n\n Economics\n\n issuance-policy\n\n 1\n\n 505\n\n Aug 19\n\n FAQ: Ethereum issuance reduction\n\n Economics\n\n 3\n\n 7.3k\n\n Aug 17\n\n Native Ethereum Delegation (NED): Protocol-Routed Delegation With Split-Neutral Allocation and Coverage-Bounded Consensus Amplification\n\n Proof-of-Stake\n\n 0\n\n 122\n\n Aug 14\n\n In-Protocol Client Data Reporting\n\n Proof-of-Stake\n\n 14\n\n 400\n\n Aug 6\n\n Supporting decentralized staking through more anti-correlation incentives\n\n Proof-of-Stake\n\n 21\n\n 15.0k\n\n Jul 25\n\n The Extremely Lean Chain\n\n Proof-of-Stake\n\n 6\n\n 4.8k\n\n Jul 8\n\n Adding PoS validator key changes\n\n Proof-of-Stake\n\n 5\n\n 5.7k\n\n Jul 7\n\n Building towards Multi-Party Block Construction\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 2\n\n 674\n\n Jun 3\n\n The case for a variable PTC deadline with affine metering and a unified calldata price\n\n Proof-of-Stake\n\n resource-pricing\n\n 0\n\n 239\n\n Apr 22\n\n A Protocol Design View on Statelessness\n\n Economics\n\n stateless\n\n 7\n\n 1.2k\n\n Apr 16\n\n Why a Variable Payload Deadline Only Helps by ~6%\n\n Proof-of-Stake\n\n mev,data-availability\n\n 0\n\n 139\n\n Mar 23\n\n Rational Finality Stalls and the Risks of Pre-Finality Actions in Ethereum-Anchored Systems\n\n Proof-of-Stake\n\n 1\n\n 183\n\n Mar 21\n\n One-epoch inactivation and Rifle attacks\n\n Proof-of-Stake\n\n 8\n\n 420\n\n Mar 12\n\n Observation Horizon: Time-Bounded Offline Verifiability in Proof-of-Stake Systems\n\n Casper Basics\n\n 0\n\n 78\n\n Mar 5\n\n Majority Fork Protection Through Distributed Validator Technology: A Novel Approach to Network Resilience\n\n Block proposer\n\n security\n\n 0\n\n 245\n\n Mar 4\n\n Deprecating BLS: Post-Quantum Recovery via Deposit Address\n\n Proof-of-Stake\n\n security,post-quantum,consensus\n\n 11\n\n 1.3k\n\n Feb 19\n\n Universal Enshrined Encrypted Mempool EIP\n\n Proof-of-Stake\n\n mev\n\n 21\n\n 2.1k\n\n Feb 13\n\n Native DVT for Ethereum staking\n\n Proof-of-Stake\n\n 19\n\n 3.1k\n\n Jan 28\n\n An Observation on Ethereum’s Blockspace Market\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 4\n\n 2.2k\n\n Dec 2025\n\n Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal\n\n Block proposer\n\n 13\n\n 11.8k\n\n Sep 2025\n\n Trustless Consensus Manipulation Through Bribing Contracts\n\n Proof-of-Stake\n\n security\n\n 0\n\n 317\n\n Sep 2025\n\n Integrating 3SF with ePBS, FOCIL, and PeerDAS\n\n Proof-of-Stake\n\n consensus\n\n 0\n\n 679\n\n Aug 2025\n\n The Glamsterdam equation\n\n Proof-of-Stake\n\n scaling\n\n 2\n\n 783\n\n Aug 2025\n\n eODS (Enshrined Operator Delegator Separation): a Delegation model proposal\n\n Proof-of-Stake\n\n 0\n\n 403\n\n Jul 2025\n\n Block Constraints Sharing: Multi-Relay Inclusion Lists & beyond\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 0\n\n 291\n\n Jul 2025\n\n Relay Block Merging: Boosting Value & Censorship Resistance\n\n Block proposer\n\n mev,proposer-builder-separation,censorship-resistance\n\n 2\n\n 1.2k\n\n Jun 2025\n\n Liveness attack in Ethereum PoS protocol using RANDAO manipulation\n\n Proof-of-Stake\n\n 3\n\n 703\n\n Jun 2025","tokens":912,"squid":"ink-research","role":"Deep Scholar","at":1791268319418,"hash":"5073d79b66cee5295d3a1de0c7dfbc33d58edd26"}
{"url":"https://forum.pyth.network/t/community-council-term-2-budget-request/2419","domain":"forum.pyth.network","title":"Community Council Term 2 Budget Request - Community Council - Pyth DAO","text":"Community Council Term 2 Budget Request \n\n Community Council\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 6\n min\n\n Mar 25\n\n 1 / 5\n\n Mar 25\n\n Apr 14\n\n post by Chop on Mar 25\n\n Chop\n\n Community Council Term 2 Budget Proposal\nSummary\nWe’re requesting 8,000,000 PYTH over 12 months (~666,667 PYTH/month or $328,000 as of March 25th, 2026) for Community Council Term 2.\nTerm 2 matches the budget to real program costs AND adds the unified content creation engine as the major new initiative, replacing Kaito and Impact Awards for a more direct, value added content creation mechanism that is more in line with the development of the broader crypto ecosystem.\n\nWhy 8M PYTH?\nTerm 1 Proved the Model Worked, but Required Refinement\nCouncil term #1 burn rate was relatively low and reflected the real cost of operating community programs (Impact Awards, Kaito, council stipends, experiments). With Kaito winding down, the council has collectively researched and built a new Kaito-esque program that is better designed and refined to achieve very specific reach goals on socials.\nKey cost drivers that grew during Term 1:\n\nKaito: Grew from 35,000 → 234,000 PYTH/month as the platform received more attention. The platform crashed and burned, and no longer exists.\n\nImpact Awards: Consistent monthly distribution to 40+ contributors. Quality diminished over time as ‘farmers’ discovered ways to take advantage of the system.\n\nExperiments Lab: Funded community development (Community Ops, Pythentity)\n\nTerm 2 Consolidates and Scales\nThe old budget categories — Role Stipends, Impact Awards, Kaito, Experiments Lab — are being replaced by a unified system. Impact Awards, the Clipping Program, and MissionMonitor are no longer separate line items. They’re one content creation engine:\nMissions (MissionMonitor) → Content Creation → Clipping (PythClippers) → Referrals → Rewards\n6M of the 8M PYTH budget flows through this unified engine. This is a consolidation of many different programs under a single unified banner that can be closely monitored. Three programs that previously had separate budgets, separate tracking, and separate oversight now run through one system with automated tracking, judging, and treasury export.\n\nTerm 2 Budget Breakdown\n\nCategory\nMonthly PYTH\nAnnual PYTH\nDescription\n\nContent Program\n500,000\n6,000,000\nUnified Content Creation Program\n\nOngoing Hackathon\n200,000\n400,000\nPromoting ongoing Pyth Development and Content Showcases with community builders\n\nPythentity\nTBA\n200,000\nGamified Community identity layer & Rewards system for Pyth evangelists.\n\nRole Stipends\n~46,000\n560,000\nRole stipends, covering core content and community lore creators.\n\nCouncil Stipend\n10,000\n840,000\nCouncil Member Payments for ongoing management.\n\nWhat Term 2 Funds\n1. MissionMonitor Content Engine (Primary Allocation)\nThe unified system for community content creation, distribution, and rewards.\n\nMissions: Campaign briefs distributed via Telegram + Discord. Community creates content around Pyth milestones, launches, partnerships, and product updates.\n\nClipping Program: MissionMonitor bot handles submission tracking and leaderboards for socials content. 134+ video transcripts ready for clipping alongside a comprehensive content guidebook.\n\nReferrals: Built-in referral system with attribution tracking, 10% referrer split, and 90-day expiry. Incentivizes community growth through content participation.\n\nSoft Identity Gating: All programs can be gated through Pythentity for sybil resistance. Verified contributors & Pyth evangelists receive preferential treatment.\n\nInfrastructure already built: MissionMonitor (live), Referrals System (90% complete), Pythentity (MVP live), Google Sheets export (live).\n2. Pyth Playground (Vibecodeathon)\nRecurring 6-week community hackathon for builders of all skill levels. AI-assisted “vibe coding” format lowers barriers. Each submission creates public content pieces (GEO requirements built in).\n\nRound 1 currently live with active submissions\n\nTarget: 3–5 rounds in Term 2\n\nPrize pool: ~200,000 PYTH per round\n\nConfirmed judges from Community Council\n\n3. Pythentity (Identity Layer)\nCommunity-native identity and reputation system. Wallet verification + Discord OAuth + NFT gating + behavioral scoring. Gates all incentive programs for sybil resistance.\nTerm 2 scope:\n\nCross Chain & additional wallet support.\n\nCross-platform identity bridge (Discord + Telegram + Forum)\n\nIntegration with PythClippers and MissionMonitor for automatic score updates\n\nDomain migration + repo transfer\n\nProcess remaining grant funds\n\nTerm 1 Financial Transparency\nFull actuals from Google Sheet — Full breakdown.\nCycle 1 (April – September 2025)\n\nCategory\nBudget\nSpent\nRemaining\n\nRole Stipends\n120,000\n155,718\n-35,718\n\nImpact Awards\n210,000\n224,396\n-14,396\n\nKaito\n1,000,000\n477,887\n522,113\n\nExperiments Lab\n90,000\n44,180\n45,820\n\nCouncil Stipend\n420,000\n420,000\n0\n\nTotal\n1,840,000\n1,322,181\n517,819\n\nCycle 2 (October 2025 – March 2026)\n\nCategory\nBudget\nSpent\nRemaining\n\nRole Stipends\n120,000\n284,140\n-164,140\n\nImpact Awards\n210,000\n189,524\n20,476\n\nKaito\n600,000\n1,015,871\n-415,871\n\nExperiments Lab\n480,000\n403,800\n76,200\n\nCouncil Stipend\n420,000\n420,000*\n0\n\nContingency\n60,000\n35,050\n24,950\n\nTotal\n1,890,000\n2,348,384\n-458,384\n\n*Council Stipend is paid directly from the DAO treasury to council members — not from the council multisig. This avoids a conflict of interest (council members don’t pay themselves). Cycle 2 stipend is committed but not yet disbursed.\nKey takeaway: Kaito alone consumed 53% of total Term 1 spend and exceeded its Cycle 2 budget by 415K PYTH. Role Stipends also exceeded budget in both cycles as the community role system expanded. Council Stipend shows 0 spent because stipends are paid directly by the DAO to avoid a conflict of interest — council members don’t pay themselves from their own multisig.\n\nGovernance & Accountability\nReporting\n\nQuarterly budget reports posted to forum with PYTH spent per category\n\nQuarterly reviews with program metrics (participation, content output, community growth)\n\nAll operational tooling (MissionMonitor, PythClippers) produces auditable logs\n\nGoogle Sheets treasury tracker publicly viewable\n\nUnused Funds\n\nAll unused funds return to the DAO treasury. No rollover, no discretionary holdback.\n\nTerm 1 wallet currently holds 376,480.91 PYTH. Remaining funds may be used during the interim period to bridge into Term 2 content programs, avoiding dead time between budget approval and program launch. Any balance beyond interim operations returns to the DAO.\n\nFunding Source\n\nDAO treasury, executed via binding governance proposal\n\nFunds transfer is automatic upon proposal execution\n\nWhat’s Different About Term 2\n\nTerm 1\nTerm 2\n\nBuilt MissionMonitor\nRun missions at scale on MissionMonitor\n\nBuilt PythClippers\nLaunch clipping program with dedicated PYTH pool\n\nBuilt Pythentity MVP\nGate all incentive programs through Pythentity\n\nSeparate budgets for Impact Awards, Kaito, Experiments Lab\nUnified content creation engine — one system, one budget\n\n35K PYTH/month approved budget\nRight-sized to actual operational costs\n\nPrograms built\nPrograms running\n\nThe infrastructure is built. The strategy is documented. The tools are operational. Term 2 is about making these systems produce results at scale.\n\nConclusion\nTerm 1 built the infrastructure. Term 2 runs the machine.\nThe Community Council exists to make Pyth’s community a genuine competitive advantage — verified contributors who know the product, build with the data, and produce content that compounds in value. The unified content creation engine (MissionMonitor + PythClippers + Pythentity) is how we do that at scale with proper accountability.\nRequesting approval for a 12-month budget of 8,000,000 PYTH (4,000,000 PYTH per 6-month cycle). Cycle 2 allocation may be adjusted based on PYTH price at the time of renewal.\n\nQuestions? Tag the Community Council in Discord or comment on this proposal.\n\n [PASSED] OP-PIP-114: Community Council Term 1 Cycle 2 Stipend Disbursement\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n Guide for the Community Council Election #2\n\n 2\n\n read \n\n 6\n min\n\n post by Mersault on Mar 26\n\n Mersault\n\n Great news. I was incredibly frustrated with the farmers and I’d love to weed out everyone who’s just farming rewards. The larger budget provides more opportunities , everything built in Term 1 needs to be scaled, and it’s time to keep pushing forward.\nThe only thing that worries me is the referral program. For some reason, it’s an immediate red flag for me. It could potentially bring in people who will just abuse the system and invite low-quality users. But I think the scoring system will be able to handle it\n\n post by PilotSB on Mar 30\n\n PilotSB\n\n getting hot on transperancy, another banger ser chop\n\n [PASSED] OP-PIP-101: Community Council Term 2 — Election Result & Budget Approval\n\n 12 days later\n\n post by Pythian_151 on Apr 12\n\n Pythian_151\n\n From April 2025 to March of 2026, we spent 3,670,655 PYTH on all marketing programs. How can we state that this has lead to greater adoption when the price of the token has fallen from approximately 0.40 cents to 0.04 cents. Now we are asking 8,000,000 PYTH from the DAO to spend on marketing more specificity, 6,000,000 for content creators equating to the whole amount of the DAO current reserve..\nOne of the purpose of conducting share buy backs in this case token buy backs is to reduce the pressure of dilution and improve EPS.\nSince the marketing has shown not to be as successful as we thought it would be, should we be more careful with our spending and instead concentrate on letting the product speaks for itself i.e PYTH pro.\nSomeone creating a YouTube video content or retwitting on X is not going to incentivise big institutions to pay 10,000 per month, rather the quality of the price feed will.\nMay be we could spend 10-15 percent of the monthly DAO revenue on marketing with the rest of the earnings for continued buybacks.\nSpending less and building up the DAO reserve will help conteract the selling pressures from staking rewards and unlocks and give the price a chance to move in a favourable direction ?\n\n post by Chop on Apr 14\n\n Chop\n\n gm Pythian_151.\nFirst off, banger reply. Quality FUD. I love an opportunity to respond to genuine feedback around the Community Council budget. I commend you for reading and absorbing it all - most people don’t. Your willingness to engage Pyth with critiques on programs like this is what makes our community great. Keep it coming!\nA couple of points i think are worth noting on this portion of our spend;\n\nIn our view, adoption is a lot more than just ‘token go up’. In fact, token go up (the council believes) has nothing to do with adoption. Pyth adoption (measured in subscription terms) is up considerably! Our Quarter on Quarter growth in subscriptions is well over 100%, and we’re growing above projections. To add to that; we have been actively expanding our revenue collection mechanics (see the Listing as a Service governance proposal as an example). Price Feeds are expanding aggressively and their usage is accelerating in line with adoption.\nThe Community Council budget (which i believe is what you are referring to) serves many different purposes. The ‘why’ of the councils’ spending is not immediately obvious to those who dont directly participate, so let me break it down a bit;\n\nOur recent Polymarket partnership exists partly because of our highly engaged and ‘loud’ community has made it known to Polymarket team that we are serious players within the space. Pyth’s Data Marketplace is also a direct beneficiary of community noise and our ability to provide retail data (also see the Polymarket $99 retail subscription). In this regard, the marketing spend is not necessarily visible directly in results, but is instead measured in aura.\n\nKaito - Now discontinued. This was our largest line item spend last year. Pyths’ spend when compared to most other Kaito budgets was much smaller. Moreover, our spend was HIGHLY targeted and rewarded only those who were making substantive contributions. We (the council) audited submissions meticulously and filtered low quality AI submissions as we reasonably could in order to make the spend as fair as possible.\nThis allowed us to create a new Kaito-like system with larger safeguards, stricter contribution guidelines & gives us variability and control over our community rewards spend moving forward. You’ll hear more on this over the next couple of months as we report on its progress and efficacy. This will be run as a trial during the second term and adjusted as necessary, based on feedback from people such as yourself!\n\nPyth Community Hackathon - ongoing. The most successful Hackathon Pyth has ever participated in (including IRL based events). 35+ submissions that showcase what is possible leveraging Pyth Pro data, but make a significant dent in our AI Discoverability and referencing Pyth in builders’ channels such as Github. This hackathon has contributed immensely to our ability to deliver resources to the broader Pyth community;\n\nFree Pyth Access to whoever wants it.\nOpen, discoverable ideas & developer community tools\ncurrent budget request has the hackathon as a big part of the Councils’ output in this next term due to its current success\n\nPythentity - this one is a long game on the community NFT’s. Our hope (as a council and as a community) is that we will be able to create an all inclusive platform for community participants that allows the following;\n\nAccess to Hackathon dApps built by community (we see the monitoring tools made using Pyth DAta and games on entropy as a public educational goods)\nA ‘passport’ that functions as proof of your interaction across the Pyth Powered ecosystem.\nA central ‘hub’ for community contributions, builder resources & educational content to help retail (and trader) participants wrap their head around Pyth WITHOUT the institutional an focus or formalized clutter.\nAn access point to Pyth that is retail focused (and community built) instead of institutionally minded.\n\nRole Stipends - these are arguably our least obvious spend. However, we maintain a core group of highly engaged community members who contribute across multiple different channels using this mechanic as a buffer for the time they dedicate to Pyth. The 70% hold metric also applies to these stipends.\nPyth one of the most engaged market Discord channels that i’m aware of, which constantly provides value to the broader community with its weekly streams, analysis and market dissections. Our Chirons are some of the most well educated retail consumers of Pyth in the space - they are the cultural heartbeat of our Brand that are ready and willing to refute FUD and bull post the virtues of Pyth at a moments notice.\nThese mechanics are highly variable & subjective. The participants are reviewed monthly.\n\nImpact Awards & Misc Spending - Used to create highly specific content across different platforms. This spans TikTok, Reddit, Discord & Telegram. We use this portion of the budget to build a library of ‘content’ that allows us to onboard new community members, populate forums and channels with educational content AND help us moderate disparate language communities and niche content channels. This includes the newly created Content Library here in the DAO forum, which will be expanded to Reddit and a soon to be created community blog.\n\nTo address your concerns about marketing spend and ‘adoption’ more directly; institutions are motivated by results, data efficacy and security more than anything else. Over the past 2 years Pyth has been has constant presence within the broader data market place and social channels (almost solely due to the Community Councils’ efforts). We have expanded our data offering (and data efficacy) significantly over that time, with more price feeds being added on a weekly basis, and usage increasing week on week. We have shown that the Pyth price does very little in way of us being able to deliver a world class product that institutions and retail consumers alike wish to use. You will notice that our community almost NEVER discusses the price of Pyth - and for good reason. It is not what motivates us, nor do we believe should it. We are dedicated to deliver a world class product that is changing the face of finance in real, measurable ways day in, day out. That, we believe, is our strongest asset and proof point which gets validated to us on a weekly basis. 95% of HIP-3 volume. 24/7/365 always-on markets and deep crypto & institutional adoption is what we grade ourselves on. In this regard, be believe price is a lagging indicator of where Pyth is headed. As long as our leading indicators (as above) are heading in the right direction (they are) we are happy.\nfinally; We think deeply about our token economics and how to better shape them for now and into the future. Rest assured, we believe the level of spending requested by the council is both reasonable and in line with expectations of future growth. We as community participants remain extremely bullish on what Pyth is able to achieve with the help of people such as yourself.\nI will also look into your Discord ban (which you have mentioned elsewhere). This is an oversight on my behalf, and as long as you were conduction yourself respectfully and in line with our expectations of community members, you should not have been banned. I will get this revoked ASAP. I welcome discussion like this wherever possible!\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Community Council Report & 6month Budget Extension\n\n Community Council\n\n 11\n\n 445\n\n Sep 2025\n\n Community Council Term 2: Six-Month Mid-Term Report\n\n Community Council\n\n 4\n\n 272\n\n 9d\n\n Community Council Term #1 Exit Report\n\n Community Council\n\n 4\n\n 195\n\n Mar 29\n\n Pyth Community Council\n\n Ideas Bank\n\n 73\n\n 1.7k\n\n Aug 2024\n\n Pyth Community Council v2\n\n Ideas Bank\n\n 51\n\n 1.2k\n\n Feb 2025","tokens":4525,"squid":"ink-oracles_data","role":"Tide Watcher","at":1791268326560,"hash":"b1f9ea2e23c27e80dd0deaad16ea4eecfb1bd039"}
{"url":"https://ethresear.ch/t/faq-ethereum-issuance-reduction/19675","domain":"ethresear.ch","title":"FAQ: Ethereum issuance reduction - Proof-of-Stake / Economics - Ethereum Research","text":"FAQ: Ethereum issuance reduction \n\n Proof-of-StakeEconomics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 34\n min\n\n May 2024\n\n 1 / 4\n\n May 2024\n\n Aug 17\n\n post by aelowsson on May 29, 2024\n\n aelowsson\n\n FAQ: Ethereum issuance reduction\nOverview\nWhen it comes to the premise of reducing issuance, there are many important questions to consider. Having studied these questions extensively, I thought it would be fruitful to address them one by one, providing detailed answers as needed. I post on Ethresearch to facilitate debate, and will try to respond to any questions you may have (including new questions suitable for an extended FAQ).\nSome concepts of staking economics that have just been discussed in passing previously are given a more extensive review. These include: time–quantity policies where the reward curve slowly drifts (and other potential endgame policies), distributions of reservation yields among solo stakers and delegating stakers, and the downsides of using a vanilla EIP-1559 mechanism to target some specific stake participation. Quick link to all questions:\n\nWhy should Ethereum reduce its issuance?\nWhat about economic security? More stake makes Ethereum more secure right?\nWhat is a desirable issuance reduction for the near future?\nWhy not dynamically adjust the yield with a mechanism like EIP-1559 to guarantee some fixed target participation level?\nHow will a reduction in issuance affect the composition of the staking set?\nWhat is the endgame issuance policy?\nWhy not just prevent new stakers from joining?\nCan stakers profit from a reduced issuance and what is the relevance and impact of the real/proportional yield?\nSome users think that more yield is more fun and like to collect yield on their ETH. Why not lean into this?\n\nIt is beneficial to read the answers in the order that they are presented, but they still stand on their own.\nFAQ\nWhy should Ethereum reduce its issuance?\nOverview\nAt the most basic level, stake participation is growing beyond requirements for economic security, and paying people to do something that is not necessary always comes with downsides. To be more specific, there are two fundamental reasons for reducing issuance:\n\nTo reduce costs for users, including costs for hardware, risks and opportunity costs, taxes, etc. By maintaining the current reward curve, Ethereum compels users to incur higher costs than necessary for securing the network. Reducing issuance will improve welfare by eliminating implied costs that may very well amount to more than a billion dollars per year.\nTo improve Ethereum at the macro level. If everyone stakes, one entity or a cartel might come to exercise control over a large proportion of all ETH. This can reduce security since it becomes harder for the social layer to hold such entities accountable. The potential proliferation of liquid staking tokens (LSTs) may also impede ETH as trustless money, fostering monopolization and making Ethereum a less desirable blockchain to build on.\n\nThe answer will now take a closer look at these two aspects.\n1. Reduced costs raise welfare\nReview Figure 1 (example with more details here), featuring a hypothetical future supply curve in blue. The supply curve indicates the amount of stake deposited D𝐷 at various staking yields y𝑦. It captures the implied marginal cost of staking. What that means is that every ETH holder is positioned along the supply curve according to how high cost they assign to staking, with their required yield reflecting that cost. Relevant costs include hardware and other resources, upkeep, the acquisition of technical knowledge, illiquidity, trust in third parties and other factors increasing the risk premium, various opportunity costs, taxes, etc. The area above the supply curve indicates the stakers’ surplus (what they actually gain). The area below the supply curve—the supply curve’s integral—indicates the costs assigned to staking (the marginal staker would not stake at a yield below the supply curve).\nFigure 13133×1864 380 KB\nFigure 1. Implied cost (blue) and surplus (grey) of staking under a hypothetical future supply curve. A change in issuance policy shifts the equilibrium from the black square to the green circle. The cost reduction (dark blue) leads to aggregate welfare improvement as long as the protocol remains secure and decentralized, and the reduction in surplus (dark grey) simply shifts some utility from stakers to everyone.\nTwo reward curves are shown, with maximum extractable value (MEV) added to the staking yield. In this FAQ, MEV will be 300k ETH/year (close to the average over the last few years) and include priority fees. By maintaining the current reward curve in black, Ethereum compels users to incur higher costs than necessary for securing the network. Adopting the green reward curve eliminates the costs represented by the dark blue area (around 450 000 ETH), thus improving welfare. The issued ETH covered for hardware expenses, taxes, reduced liquidity and risks that users would choose to sidestep under a lower yield. With the green curve, they can, and the benefits are shared by everyone, including remaining stakers. This creates value for all token holders through a reduction in newly minted ETH. It may seem strange that it matters how many new ETH that are created. But imagine if every ETH was converted to 10 ETH tomorrow so that there were 1.2 billion instead of 120 million ETH in total. Then every ETH would be around 10 times less valuable. What matters is the proportion of all ETH that you hold; a concept that we will get back to in a subsequent answer. There is also a surplus shift from stakers to everyone from a change in issuance policy, indicated by the darker grey area. That ETH indeed previously benefited stakers, since it was taken from everyone (in the form of newly minted ETH), and then given specifically to them.\nIt is common to treat the issuance reduction achieved by removing the dark blue area the same as when removing the dark grey area. When not explicitly highlighting the reduction in costs among those that stop staking as the issuance falls, value may appear to merely shift from one class of users to another in the form of a gain or loss in real/proportional yield. Issued tokens are redistributed among a different quantity of stakers, not creating any new value at the aggregate level. Without a division into cost and surplus, the welfare gain can get lost in translation, especially if it is not otherwise implied by remarking on the outcome among all users at the different equilibria. In a subsequent answer, the different effects will be studied more closely.\nSlashing risks or any bugs that would effectively burn the stake are from an “accounting perspective” less attributable as a pure cost at the aggregate protocol level, and taxes will by their nature increase costs for a user when its surplus rises. But the general principle of capturing costs below the supply curve as the issuance that does not generate any surplus to stakers is very useful for understanding staking economics and welfare.\nWhat happens when we impose unnecessary costs on our users? If they are forced to select between incurring these costs as stakers, or to subject themselves to an increased dilution under equilibrium, they might simply decide to use another blockchain, where the imposed costs are lower. This would of course affect both token holders and anyone building on Ethereum negatively. Ethereum operates in a free market and must always strive to perfect the user experience.\n2. Macro perspective\nA true cost accounting must also incorporate the macro perspective. An LST exceeding critical thresholds regarding the proportion of stake under its control may compromise the consensus mechanism. Outsized profits from blockspace are here a stratum for cartelization. But if everyone is compelled to stake, an entity or cartel of entities may also gain control over a significant proportion of the total ETH—propelled by network externalities such as the money function of an LST. These externalities are a stratum for cartelization extending outside of the consensus mechanism. The compromised institution also sits one layer above, namely the social layer.\nIt became apparent with The DAO that if the proportion of the total circulating supply affected by an outcome grows sufficiently large, then the social layer may waver on its commitment to the underlying intended consensus process. An LST might grow “too big to fail” in the eyes of the Ethereum social layer. If the community can no longer effectively intervene in the event of a 51% attack, then Vitalik’s warning system and Danny’s recourses may not be effective. Staking becomes so ubiquitous that the social consensus mechanism is overloaded. It is a special and in a way inverted case of issues Vitalik previously warned about.\nThe macro perspective also extends beyond consensus. If one or a few LSTs overtake as money in the Ethereum ecosystem, they will embed themselves across every layer and application. An economy that is not powered by a trustless asset is arguably not as resilient, regardless of if the consensus process itself is never threatened. The applications powering the money will gain an outsized influence over the applications using the money, and Ethereum will become a less desirable blockchain to build and develop on.\nWhat about economic security? More stake makes Ethereum more secure right?\nIt is true that up to a certain point, more stake makes Ethereum more secure. But even before reaching this point, the marginal increase in security from adding another validator brings less utility to users than the utility loss stemming from the numerous downsides of excessive issuance (see the previous answer) that negatively affect users, builders, and holders of the ETH token. Ethereum’s economic security will in the long term inherently be linked to the ability of ETH to retain its value. A holistic perspective is therefore important also when considering economic security. This is underscored by reflecting on the early days of Ethereum, when the ETH token was much less valuable. Eight years ago, In May 2016, Vitalik deliberated on the value that Ethereum can and cannot secure at a stake participation of 30%. At the time, the market cap of the ETH token was roughly 500 times lower than today, and the economic security that Ethereum could offer was therefore limited. Increasing stake participation from 30% to 60% would only increase the value of 1/3 of the stake (the threshold for the ability to delay finality) from $70M to $140M. This highlights that once the proportion staked has risen above insignificant levels, it will ultimately be Ethereum’s role in the world economy, and the ether’s role in the Ethereum economy, that determines the economic security.\nIn a recent AMA, Justin Drake suggested that a stake participation of 1/4 (30M ETH) is appropriate. Vitalik Buterin concurred, but also added a personal note of finding 1/8 (15M ETH) fine. As the quantity of stake grows, the prospects for high economic security in the long term gradually begin to diminish. It seems reasonable to argue that Ethereum would have higher economic security twenty years from now with a reward curve that sees the deposit size settle on 30M ETH staked than at 90M ETH—as long as the composition of the staking set remains viable. Beyond certain limits, even short-term security begins to degrade, in line with the reasoning around the macro perspective. The social layer may lose its neutrality and credibility as the ultimate arbitrator against attacks from dominant SSPs. At the other end, even long-term security will be negatively affected if users are not incentivized to add another validator while that brings positive utility: a blockchain with poor short-term security from too little stake becomes undesirable to build on as well.\nThe outlined considerations hint at a range within which it is desirable to keep stake participation. There is no single ideal quantity because Ethereum can adapt its security expenditures based on the prevailing price of security, something which is facilitated through a reward curve. The staking yield should be very high at 15M ETH to ensure sufficient participation. When the quantity of stake is 60M ETH, the staking yield should be very low, to dissuade additional staking. At 30M ETH staked, the staking yield can be set in between these extremes, at a level that makes an equilibrium likely. Note that the total security expenditure (issuance, Y_i𝑌𝑖) potentially can remain rather fixed as the issuance yield y_i𝑦𝑖 varies, since the issued tokens will be distributed to more stakers when more stake is deposited, thus bringing down the yield. This relationship is expressed by the equation Y_i=y_iD𝑌𝑖 =𝑦𝑖𝐷. Economic security is also discussed here.\nWhat is a desirable issuance reduction for the near future?\nOverview\nIt is desirable to adopt a reward curve situated within the yellow area in Figures 2-4 below. It can be done using a reward curve with tempered issuance (slowly falling as the amount of stake increases) as exemplified in green or a reward curve with capped issuance with examples shown in pink. A reward curve below the yellow area would make the influence of MEV rather troublesome because block proposal rights would bring in relatively more value than attestations, and might also not be warranted at this point. A reward curve above the yellow area might not be sufficiently impactful relative to the potentially fractious governance process that comes with changing issuance policy.\nInfluence of MEV\nAny change to the reward curve should account for MEV. Forcing a low quantity of stake is undesirable if the MEV is not at the same time burned, as explored in a recent write-up, and the following answer. If issuance yield is reduced to strictly enforce an equilibrium in the presence of high MEV, block proposal rights may be the only remaining source of revenue. This would significantly increase the relative standard deviation in staking yield for non-pooled stakers, disadvantaging solo stakers. At some point, stakers may simply stop attesting. Additional changes to the consensus mechanism would be required to preserve micro incentives when the issuance yield becomes too low. A staking fee taken out each epoch in my view then seems like the best option and would promote “incentive invariance”. Non-pooled stakers would then need to lose ETH each epoch even under a low positive issuance yield, in the hope that they may be assigned to propose a block. A simple solution, useful for example under reward curves at the lower edge or a bit below the yellow area, is to increase penalties for missed attestations.\nA reasonable range\nWhat then are the more moderate options that can be contemplated at the present? Figure 2 shows a range in yellow that is reasonable to target currently. Below this range, block proposals will generate more than half of the rewards under the present level of MEV, which could be an uncomfortably high level. Above this range, the change is rather small, and the potentially fractious governance process of changing the reward curve might not be worthwhile. There are also some options that push down the staking yield slightly further at high quantities of stake, which cannot be fully ruled out, discussed here.\nFigure 22685×1575 287 KB\nFigure 2. A reasonable issuance range in yellow achieved through a reward curve with tempered issuance (green) or capped issuance (pink).\nReward curve with tempered issuance (green)\nThe current reward curve in black follows the equation for issuance yield y_i = cF/\\sqrt{D}𝑦𝑖 =𝑐𝐹/√𝐷, with the constant c\\approx2.6𝑐 ≈2.6 and the base reward factor set to F=64𝐹 =64. Yearly issuance is always Y_i=y_iD𝑌𝑖 =𝑦𝑖𝐷. The reward curve with tempered issuance in green is created by division with 1+D/k1 +𝐷/𝑘, thus:\n\ny_i = \\frac{cF}{\\sqrt{D}(1+D/k)},\n𝑦𝑖=𝑐𝐹√𝐷(1+𝐷/𝑘),\nwith k𝑘 set to 2^{25}225. The variable k𝑘 defines participation at peak issuance, which also becomes the point where issuance is halved, indicated by the lower cross at around 33.6M ETH. The dashed green reward curve makes a small change to the computation, subtracting a fixed constant k_2𝑘2 from D𝐷 (minimum 0) when computing the new term. This constant was here set to k_2=2^{23}𝑘2 =223. The idea is to provide stronger guarantees of a sufficient quantity of stake and thus security. While this is very unlikely to be required, it might still make the governance process of finding an agreement on the change easier. A similar effect can also be achieved by using a reward curve of a higher order.\nReward curve with capped issuance (pink)\nIn pink are reward curves with capped issuance (shorter write-up here). The cap D_c𝐷𝑐 defines stake participation when issuance diverges from the current reward curve and flatlines. The lowest setting within the sought range is D_c=2^{23}𝐷𝑐 =223 (8.4M ETH) indicated by a dotted curve and the highest is D_c=2^{24}𝐷𝑐 =224 (16.8M ETH) indicated by a full curve. One interesting detail is that Vitalik Buterin’s active validator cap and rotation proposal from March 2021 has the same effect on issuance as when applying D_c=2^{24}𝐷𝑐 =224. One benefit of this reward curve is thus its long history, potentially being the first serious proposal for tempering the growth in the actively participating stake. The reader might find the comment section on that post interesting, with early thinking on Ethereum’s circulating supply equilibrium, targeting a participation ratio, and variable validator balances. The dashed pink curve corresponds to the viable option of $D_c=15$M ETH. The midpoint, 2^{23}\\sqrt{2}223√2 might also be interesting (not plotted).\nStaking yield and outlook\nFigure 3 shows the staking yield y=y_i+y_v𝑦 =𝑦𝑖 +𝑦𝑣, including MEV yield y_v𝑦𝑣 at the current level of 300k ETH of MEV per year, for some of the previously outlined reward curves (retained color and line style). In blue is the same hypothetical future supply curve as in Figure 1. It is intended to illustrate what the supply curve might look like a few years from now, as a way to understand how an equilibrium might form. The faint blue line may then be the supply curve after another few years have passed and the costs associated with staking have fallen even further. The difference in equilibrium yield between the two reward curves will depend on the slope of the supply curve and, as illustrated, may not be that significant, here amounting to 0.5%.\nFigure 33152×1890 416 KB\nFigure 3. Staking yield from the outlined reward curves, inclusive of MEV of 300k ETH per year. Two hypothetical supply curves are indicated in blue.\nFigure 4 instead shows only issuance yield, with no rewards from MEV. If MEV burn (e.g., 1, 2, 3) is successfully implemented, the staking yield could approach these levels. However, MEV burn is at a rather early research stage with no guarantee of success, and some parts of the MEV such as consensus-layer preconfirmations may never be burned. The figure illustrates that the equilibrium staking yield could also decrease due to a continued fall in the supply curve, after another few years have passed. The combined effect brings down the staking yield to 1.76% in this hypothetical scenario, but it is still within 0.5% of the equilibrium yield with the current reward curve.\nFigure 43152×1890 415 KB\nFigure 4. Issuance yield y_i𝑦𝑖 under the outlined reward curves. This is also the staking yield if all MEV has been successfully burned, a scenario that may not materialize. Two hypothetical supply curves are indicated in blue.\nIt can be noted that the reduced staking yield from MEV burn makes an equilibrium at a desirable quantity of stake rather likely, even if the supply curve continues to fall. Therefore, adopting something close to the dashed green reward curve, followed up by MEV burn a little later, could bring Ethereum to a stage where the quantity of stake is tempered and remains firmly below 60M ETH, likely closer to 30M ETH. This does not mean that this reward curve necessarily must remain in place. But the reward curve should give us plenty of time to continue the debate on the “endgame” issuance policy (see this answer without having to worry about the quantity of stake growing debilitatingly high.\nWhy not dynamically adjust the yield with a mechanism like EIP-1559 to guarantee some fixed target participation level?\nOverview\nOne common suggestion is that Ethereum should use a mechanism like EIP-1559 to automatically adjust the yield, ensuring that the stake participation is kept at some specific targeted level. Allowing the market to set the issuance yield may seem more neutral, taking away control from developers. Of course, this merely shifts the problem to defining one specific appropriate quantity of stake instead. And what is worse, it constrains Ethereum to purchase an equal amount of security, regardless of its cost. Arguably, there is not one specific appropriate quantity of stake, because the price of the security (the equilibrium issuance level) also matters.\nAs previously discussed, the marginal increase in security from adding another validator provides diminishing utility as the quantity of stake increases. At some point, the utility loss of excessive issuance becomes greater than the utility gain from more security. Clearly, that point will depend also on the cost of the security. Another concern with a target participation level is that it gives stakers incentives to discouragement attack Ethereum to drive up the issuance, in one version operating as a union. Trying to rectify these flaws will ultimately recreate some form of reward curve, because it is in many ways a more sophisticated solution.\nA fixed target participation level is a vertical reward curve with subpar budgeting\nWhen the yield adjusts dynamically to enforce some specific target participation level, the mechanism behaves similar to a vertical reward curve in the long run. Any such mechanism will of course adapt gradually to avoid too big changes in yield from small shifts in the supply curve, but the equilibrium ultimately returns to a point where the supply curve intersects the vertical “dynamic” reward curve. Two such reward curves are illustrated in magenta in Figure 5, one where the target has been set to 30M ETH staked and one at 60M ETH staked. The figure presumes 300k ETH in MEV per year. A regular reward curve “Endgame (3)” presented in another answer is instead shown in purple.\nFigure 53152×1952 470 KB\nFigure 5. Equilibria under various supply curves in blue when using a fixed target participation level (magenta), a reward curve with cut issuance (purple), or the current reward curve (black). Green circles represent desirable outcomes, red crosses undesirable outcomes, and yellow triangles are outcomes somwehere in between. As captured by the red crosses, a fixed target does not facilitate proper budgeting.\nThree hypothetical supply curves are shown in blue, intended to illustrate what the outcome would be under vastly different scenarios. With a 30M target under a high supply curve, an equilibrium forms at a 2.87% staking yield; a desirable outcome under the presence of MEV as marked by a green circle. Under the outlined medium supply curve, an equilibrium forms at 1.87% instead. This might be perceived as slightly problematic because MEV will constitute 53.5% of the total staking rewards. As a result, block proposals bring home around 59.3% of all rewards under the current consensus specification, and so the equilibrium is marked by a yellow triangle to indicate a medium outcome. Yet, it is rather close to being classified as a green circle in my view. The equilibrium under the low supply curve at a 0.5% staking yield is marked by a red cross to indicate undesirability. This equilibrium happens under a negative issuance yield since the MEV yield is 1%. Non-pooled stakers (e.g., most solo stakers) must then lose money each epoch in the hope of eventually being assigned to propose a block.\nWith a 60M target under the high supply curve, an equilibrium forms at a 4.6% staking yield. This is very undesirable. Ethereum would in this scenario issue 2.45M ETH per year when the equilibrium issuance of 0.56M ETH at 30M ETH would be sufficient. The downside of course is the unnecessary costs that Ethereum is subjecting its users to. For the users, this manifests as being coerced into taking on some of those costs as a staker, or otherwis see their savings eroded by dilution. The equilibrium for the medium supply curve is also undesirable for the same reason. The equilibrium at the low supply curve however seems acceptable, at a staking yield of 1.11%. The MEV is a bit high at 45% of the rewards, and indeed the proposer gets 51.8% of the expected staking yield. Yet this seems acceptable in order to keep the quantity of stake from growing too high under a low supply curve, where 60M ETH is already undesirably high.\nThe problem with a dynamic reward curve and a specific target is that the associated vertical shape may lead to undesirable staking equilibria. The reader will note that by using the purple reward curve denoted as “Endgame (3)”, an acceptable equilibrium is reached under all three supply curves, as marked by green circles. If the supply curve is higher, an equilibrium with a low quantity of stake is attained, ensuring that the costs to Ethereum’s users do not grow too large. If the supply curve is lower, the quantity of stake is allowed to grow to ensure that a reasonable issuance yield is provided to stakers. This also enables Ethereum to ensure a viable composition of the staking set.\nThe future level of the supply curve will always be unknown, and the reward curve (the demand curve) must therefore be designed to produce acceptable outcomes in any reasonable scenario. A desirable reward curve can in a way be understood as the expansion path that optimizes between yield and stake participation across potential supply curves, as outlined in a subsequent answer. The current reward curve is shown in black and will as indicated produce excessive issuance (costs to users), while also leading to an undesirably high quantity of stake under lower supply curves.\nEthereum is currently researching MEV burn. This would alleviate some of the concerns with particular equilibria leading to excessive proportions of MEV. The outcome under full MEV burn is shown in Figure 6.\nFigure 63152×1952 469 KB\nFigure 6. Equilibria under MEV burn for various supply curves in blue when using a fixed target participation level (magenta), a reward curve with cut issuance (purple), or the current reward curve (black). Green circles represent desirable outcomes, red crosses undesirable outcomes, and yellow triangles are outcomes somwehere in between.\nEquilibria at lower staking yields when 30M ETH is staked are less problematic if there is no MEV. For example, non-pooled stakers would receive positive rewards each epoch. The equilibrium under the low supply curve is still marked by a yellow triangle. It could be fair to mark it by a green circle, but in my opinion, we might wish to let the quantity of stake expand somewhat under these supply curves. This gives a higher equilibrium yield and will give better guarantees of a viable composition of the staking set. One way to understand it is that the reward curve helps absorbs all delegating stakers with a low reservation yield to ensure that the yield remains viable for solo staking.\nFigure 7 below plots the total yearly rewards (corresponding here also to total issuance, since MEV burn is in place in this example). The excessively high issuance under high supply curves and a fixed target of 60M ETH is very problematic. Likewise concerning the high issuance under low supply curves with the current reward curve. Note that the really problematic outcomes for the current reward curve instead happens under low supply curves, because it is designed to increase issuance as the quantity of stake increases.\nFigure 73184×1952 422 KB\nFigure 7. Yearly issuance under MEV burn for various supply curves in blue when using a fixed target participation level (magenta), a reward curve with cut issuance (purple), or the current reward curve (black). Green circles represent desirable outcomes, red crosses undesirable outcomes, and yellow triangles are outcomes somwehere in between. A fixed target of 60M ETH (magenta) will lead to excessive issuance if the supply curve is higher.\nA fixed target participation level may incite stakers to attack Ethereum\nThe previous section established the downside of not attaching a proper budgeting mechanism to Ethereum’s security expenditures. It may lead to Ethereum overpaying for security, or paying so little that solo stakers needlessly are driven out. Some may consider concerns around solo staking overblown, and feel that the benefit of a specific target outweighs, because Ethereum will at least have some specific participation level that has been deemed appropriate by the community. The issue with a fixed target is however a little deeper. Stakers need to come to consensus under listener–speaker fault equivalence, something that opens up avenues for discouragement attacks. The protocol cannot ascertain who is at fault for a failed consensus message delivery. An attacker can therefore act maliciously against honest consensus participants to deprive them of rewards, subsequently profiting as they leave and the staking yield increases. There exists various avenues even for minority discouragement attacks at the present.\nWith a fixed target participation level that adapts relatively quickly, the “p_i𝑝𝑖-elasticity” becomes infinite. The incentives for discouragement attacks are then maximized; less stake must leave to drive up the yield. A related concept is cartelization attacks, consisting of SSPs working together to try to reduce quantity staked, potentially also among themselves. When issuance increases with a reduction in quantity staked (p_i>1𝑝𝑖 >1), all stakers could try to agree to reduce their stake, and everyone would be better off (as long as new entrants are kept out or discouraged). This framing can provide a suitable backdrop for convincing the social layer to not interfere when a staking cartel tries to inhibit Ethereum’s permissionlessness, utilizing discouragement attacks.\nThe importance of discouragement attacks should not be overblown, but it is unnecessary to open up for them when safer designs so easily can be achieved. It is particularly striking that under the strict target, attacking the consensus through censorship can generate what is essentially an infinite-money glitch without breaking validity.\nRectifying the outlined flaws recreates a subpar reward curve\nTo protect against stakers turning the consensus mechanism into a money-printing machine, the protocol might of course impose some maximum yield beyond which no further increases are deemed necessary (besides relying on the social layer and the threat of intervention). For good measure, the issuance policy may also define a floor, so that stakers always receive some yield, ensuring a viable composition of the staking set. Figure 8 plots this new hypothetical updated fixed target reward curve (once again ignoring the time component). The ceiling was set to 5% and the floor to 0.25%.\nFigure 83152×1952 466 KB\nFigure 8. A fixed target participation level with upper and lower limits, attempting to rectify some issues of the design shown in Figures 5-7. However, a reward curve remains the better solution.\nThe mechanism now prevents the infinite-money glitch, and gives stakers at least some guaranteed yield. However, it arguably remains flawed, with improper budgeting. The incentives for discouragement attacks and cartelization attacks are still unnecessarily pronounced in the vertical part of the curve. The fixed floor and ceiling should instead have the smooth characteristics of a reward curve, gradually increasing or decreasing as the utility function changes.\nThe outlined flaws do not mean that there is no value in a dynamic approach; it is possible to combine it with a reward curve. The idea would be to allow the reward curve to drift/bend at longer time scales, ultimately being influenced by a separate target reward curve. Such a “time–quantity policy” is explored in the answer on the staking economics endgame.\nHow will a reduction in issuance affect the composition of the staking set?\nOverview\nThis depends on how sensitive relevant groups such as solo stakers and delegating stakers are to low staking yields and high variability. One concern is unfavorable economies of scale for solo stakers at low yields. At the same time, the delegating staker subjects itself to unique risks when trusting a third party with its ETH, and may for this reason also be hesitant to stake if the yield goes too low. There is furthermore a dynamic at play wherein delegated staking becomes relatively more favorable as the quantity of stake grows. There is thus a multitude of conflicting economic forces to consider. One way to approach this complex subject is by comparing distributions that attempt to capture the willingness to stake at different yields among solo stakers and delegating stakers, as shown, for example, in Figure 11 below.\nIt is important to understand the probabilistic nature of issuance policy, and that the design ultimately tries to optimize outcomes under any scenario (e.g., a lower or higher supply curve). As outlined in another answer, a suitable reward curve can in this context be understood as the expansion path across potential supply curves that optimally balances trade-offs. One of these trade-offs is the equilibrium composition of the staking set. With this viewpoint and in light of potential concerns, an equilibrium at 30M ETH can be desirable, but still not enforced by economic capping. Under a particularly low supply curve, the quantity of stake can be allowed to expand. The composition of the staking set must thus ultimately be analyzed and optimized for across two dimensions, both issuance level and quantity of stake.\nVariability for solo stakers\nIf issuance is moderated, a larger part of rewards will stem from REV, and the relative variability in staking rewards will therefore increase. This affects solo stakers negatively since they cannot effortlessly rely on pooling for smoothing out variability. A review of how variability affects the solo staker is offered in a previous write-up on properties of issuance level. It seems reasonable to assume that stakers may be more more sensitive to variance at lower staking yields—the relative variability matters. This of course certainly holds true under an equilibrium where the issuance yield is negative but the staking yield (which includes REV) is positive—for example when instituting economic capping (1, 2). Solo stakers that do not pool their execution layer rewards will then need to lose ETH each epoch in the hope of being assigned to propose a block. Since MEV yield is shared among stakers, it rises with a lower quantity of stake, and such an equilibrium therefore becomes increasingly more likely the lower the economic cap is set, because the MEV yield can then still be a sufficient incentive on its own. Relative variability is one of the reasons for pursuing the more moderate reward curves discussed in a previous answer before MEV burn is in place. This does not mean that a low economic cap will be enforced afterward, merely that it is much more feasible once MEV burn is in place.\nEquilibrium yield and the proportion of solo stakers\nEthereum wants to retain solo stakers, at least when measured as a proportion of all stakers. The anticipated outcome of a reduction in issuance level is that less ETH will be staked by both delegating and solo stakers, relative to the outcome when issuance is not reduced (1, 2). A concern is if there might be a staking yield below which solo stakers in particular would drop off due to, e.g., the relatively higher fixed costs associated with solo staking.\nTake for example Figure 3 as a starting point. It is not clear whether the proportion of solo stakers is lower at a hypothetical equilibrium of around 36M ETH staked and a staking yield of 2.44% (green dashed reward curve with tempered issuance) than at around 50M ETH staked and a staking yield of 2.94% (black current reward curve). If solo stakers leave en masse below a yield of 2.6%, then a staking yield of 2.44% at 36M ETH staked will give a lower proportion than when the yield is 2.94% at 50M ETH staked. This is of course something to take seriously. Economies of scale are hard to design away in a decentralized blockchain.\nThere are however also some arguments as to why a more restrictive reward curve could give a higher or at least similar proportion of solo stakers:\n\nDominant SSPs have better economies of scale at higher quantities staked, increasing their cost advantage over solo stakers.\nLikewise, the positive network externality of the money function grows with quantity staked, and with it the competitive advantage of dominant LST-issuing SSPs.\nFurthermore, the principal–agent problem associated with an LST may seem less risky if everyone else also uses the LST, with the expectation that the social layer will waver on its commitment to the intended consensus process in the event of a failure.\nRisks could very well price out delegating stakers earlier than solo stakers as the yield falls. For example, if a large enough subset of potential delegators believe that there is a 1% risk of failure over a year for the LST they wish to hold, then favorable economies of scale or liquidity can be insufficient as a competitive edge. Self-custody is undeniably important to a relevant proportion of ETH token holders; this factor should not be overlooked when evaluating the staking supply side.\nOn a similar theme, if the yield becomes negative, there is still an altruistic motive for solo staking. The delegating staker will either need to take on a loss or face adverse selection. An SSP that subsidizes delegators will do so under the expectation of future profits, which may be attained by monopolizing some critical function, or worse, by attacking the consensus. An SSP profiting from restaking could just as well profit using non-staked ETH.\nToken holders with enough ETH and the technical ability to solo stake are not necessarily abundant, implying a soft upper bound on the solo staked quantity. It can be argued that if this pool is more or less depleted, then relatively few of the new stakers will be solo stakers as the supply curve falls and D𝐷 increases under the current policy. Still, concerning this particular argument, it should be remembered that if the yield is reduced substantially to halt the increase in D𝐷, there is no guarantee of retaining a larger proportion of solo stakers in the long run. This ultimately depends on the finer-grained distribution of reservation yields among them, as explored in the next subsection.\n\nIssuance policy should be focused on long-term objectives and not rely on short-term remedies. This also relates to the presently rather valuable solo staking airdrops, if they can be expected to cease. Yet, Ethereum’s evolving consensus mechanism may look different in ten years, with different requirements for staking anyway—there may even be different classes of validators (1, 2)—so circumstances of the present and in the near-term future cannot be completely ignored. For example, it must be acknowledged that if the yield falls, the impact of any solo-staking airdrops will multiply. As an example, if their expected value is 1% per year, and the staking yield falls from 4% to 1%, then airdrops will go from giving solo stakers a 25 % higher revenue than the delegating staker to giving a 100% higher revenue.\nAn additional nuance can also be added to the fourth bullet point: some solo stakers stake quite a bit more than 32 ETH, and these may be more resilient to low yields. Finally note that solo stakers who do not own their hardware may still enjoy some external economies of scale; home stakers on the contrary are directly affected by hardware costs.\nAt a fundamental level, the conjecture is that the relative distribution of reservation yields may differ between different classes of stakers. This then leads to different proportions of solo stakers under different issuance policies. But whether one policy is better than the other in this respect cannot be ascertained and may also vary over the forthcoming decade.\nRelative distribution of reservation yields\nThis subsection will explain the conjecture from the previous paragraph by visualizing some hypothetical distributions of reservation yields among different classes of stakers. Naturally, such distributions emerge from some fundamental functions capturing the willingness to supply stake, which ultimately depends on the composition of those seeking exposure to the ETH asset and how they value various costs associated with staking. I will present such models at a later date. These visualizations will simply illustrate what the distributions might look like based on the ideas presented in the previous subsection, without quantifying the actual underlying economic forces.\nThe notion of a “reservation yield” is lent from labor economics, in which reservation wages influence the quantity of supplied labor across wage (the labor supply curve). Staking economics and labor economics have some similarities; after all, staking is work done to maintain the consensus process, and stakers—just as workers—can under certain circumstances cartelize (i.e., a labor union/cartelization attack) as discussed in a previous answer. The laborer’s valuation of their leisure time to some extent then corresponds to the premium that the token holder attaches to non-staked ETH. It should however be mentioned that the “reservation yield” here applies to a “prospective” token holder. The purpose is to capture the specific yield at which some token would be staked, but it must be recognized that the actual token holder might change due to changing circumstances.\nA specified reservation yield is assumed to apply under the equilibrium formed also when accounting for other stakers’ reservation yields, and stake will not switch staking modality across staking yield. Also note that the reservation yield represents what the staking yield must be, and is not a staker’s profit, because there are also costs/fees. The example is intended to capture what the distributions might hypothetically look like a few years from now, assuming that a functioning MEV burn is in place and that airdrops to solo stakers unfortunately have become less ubiquitous.\nIllustrating hypothetical distributions of reservation yields\nThe dotted line in Figure 9 shows a hypothetical distribution of reservation yields for solo stakers, with staking yield on the x-axis. Presumably, not many stakers have a zero or negative reservation yield. A tiny few might be inclined to stake even if there are no direct monetary incentives provided by the consensus mechanism (a staking yield of 0), perhaps to defend or attack the network. But these incentives are not something that Ethereum would like to rely on. As the staking yield rises, each marginal increase brings in a larger subset of ETH token holders as solo stakers. The pool of prospective solo stakers then gradually depletes as the overall staking participation rate increases, the curve peaks (here at around 2%), and an increase in yield will ultimately not bring in many new stakers.\nFigure 93557×2273 190 KB\nFigure 9. Hypothetical distribution of reservation yields among solo stakers.\nFigure 10 instead shows with a dashed line what the distribution of reservation yields among prospective delegating stakers may look like. The distribution might generally have a more positive skew. The idea is (a little simplified) that the last quartile of stakers favor liquidity and might not have the technical ability to solo stake, whereas favorable economies of scale bring a sharper increase at lower yields. The previously illustrated hypothetical distribution of solo stakers is also included in the plot, but they are relatively fewer, so it is hard to compare the shapes.\nFigure 103557×2273 236 KB\nFigure 10. Hypothetical distribution of reservation yields among delegating stakers (dashed line). The distribution for solo stakers from the previous Figure 9 is also included (dotted line).\nTo make comparisons easier, Figure 11 instead shows both distributions normalized to represent an equal share of all ETH. Still, remember that these curves are just an attempt to illustrate the ideas presented in the previous subsection, and as such are hypothetical. But this caveat might on the other hand always be applicable, even under more deliberate models. The relative comparison of distributions captures the notion that a smaller proportion of delegating stakers would be willing to stake at a negative yield, given the potential for adverse selection and less clear altruistic motive. But then the distribution might shoot up quicker than for solo stakers as the yield becomes positive, due to the favorable economies of scale of delegated staking. As the yield increases further, solo staking comes into play, but then dwindles, because the last quantile of stakers are unwilling to give up liquidity or technically unable to solo stake. The proportion of solo stakers might thus vary intermittently.\nFigure 113557×2273 286 KB\nFigure 11. Hypothetical distribution of reservation yields for solo stakers and delegating stakers, normalized to represent an equal share of all ETH.\nHaving reviewed two hypothetical distributions, it is now time to review how the proportion of solo stakers evolves across staking yield under them. The cumulative distributions are then computed, seeing that a staker will stake at any yield above their reservation yield. These are shown in Figure 12. A way to understand these plots is that the initial distribution is treated as a probability density function (PDF), and its corresponding cumulative distribution function (CDF) then is computed.\nFigure 123623×2273 292 KB\nFigure 12. Hypothetical cumulative distribution of reservation yields for solo stakers (dotted), delegating stakers (dashed), and in aggregate (full).\nThe proportion of solo stakers is simply the solo staking CDF divided by the aggregate CDF, as shown in Figure 13. It is not asserted here that this particular outcome would materialize, but it is illustrative of the kind of concepts present in the debate. There is a higher proportion of solo stakers at negative yields, but then some valley at low staking yields due to economies of scale. It can emerge, e.g., if the delegating stakers’ assigned risk premium is more dispersed than the fixed cost structure of solo stakers. Proponents of a higher issuance level would suggest that this valley exists and is pronounced (when removing solo-staking airdrops), but there are many nuances beyond economies of scale to consider, as previously outlined. In any case, it is not clear that the effect would necessarily be that significant.\nFigure 133667×2202 160 KB\nFigure 13. Hypothetical proportion of solo stakers across staking yield.\nSince each point of the supply curve represents the reservation yield of the marginal staker, the cumulative distribution of reservation yields actually corresponds to the supply curve. To make this clear, simply flip the axes of Figure 12 to have yield on the y-axis and stake on the x-axis. The supply curve then emerges in its more common presentation, as shown in blue in Figure 14. Two reward curves are included with no MEV—the current reward curve in black and the moderate reward curve with capped issuance at D_c=𝐷𝑐 = 15M ETH from a previous answer. Two hypothetical equilibria are indicated by squares, at the intersection of the aggregate supply curve and these reward curves. The participation ratio of solo stakers and delegating stakers are simply found along the horizontal line extending from the equilibrium, at the point where this line intersects the associated set supply curve (circles).\nFigure 143683×2202 281 KB\nFigure 14. Cumulative distribution of reservation yields, here illustrated as a supply curve in blue, with flipped axes from Figure 12. Set supply curves for delegating stakers and solo stakers are also indicated. Stake participation of each class (circles) are found at the horizontal line extending from the equilibrium (squares).\nNote that the hypothetical distributions here presented only give one specific supply curve. Under another lower supply curve, the distributions would presumably be compressed such that many features, e.g., the transition to favoring delegated staking, emerge at a lower yield. I have been working for quite some time on a complex probabilistic model trying to unify these considerations, and hope to present it in a while. This topic is certain to receive further attention also from other researchers (e.g., 1, 2, 3).\nEquilibrium yield and the broader composition of the staking set\nThe relationship between issuance level and diversity in SSPs also entails a trade-off between economies of scale and factors such as the positive network externality of the money function. Offering a positive yield beyond 30M ETH is helpful for alleviating concerns that a major SSP with a structural advantage such as a centralized exchange (CEX)—perhaps leveraging some hypothetical staked ETF—can push up their proportion of the stake to critical levels. At the same time, the risks of centralization around such entities should not be disproportionately emphasized over other risk scenarios. There are already today SSPs attaining critical proportions of the stake by leveraging network externalities onchain, ostensibly foregoing profits in the pursuit of monopolization. This type of structural advantage could also grow with higher issuance, and stifling that before native ETH possibly is in the minority relative to one LST must be considered as a net positive to the community. When weighing these trade-offs, an issuance level that invariably forces any outcome—whether a very low or very high quantity staked—does not seem desirable.\nEach SSP, reaching for a specific market segment, incurs unique costs besides the cost of running staking nodes, with a wide variety ranging from compliance to software. Indeed, CEXes have somewhat of a local monopoly on their customers-as-delegators, and the opportunity cost of keeping fees competitive with any onchain option is presumably so high that it does not represent the profit-maximizing strategy. What is clear is that competition for delegated stake will unfold across diverse market segments, and perfect competition is not a reasonable assumption. If the cost of operating a node is not prohibitively high relative to the income that the SSP can make from running it, then variety in preferences and circumstances between delegators will take a central role in shaping the composition of the staking set. The concern is therefore only valid with a yield that goes close to 0 or negative at a low quantity of stake. No SSP can reasonably outcompete all others at an equilibrium staking yield of, e.g., 2% at 30M ETH staked.\nWhat is the endgame issuance policy?\nOverview\nCertain parts of the endgame have a rather broad agreement. Firstly, Ethereum should transition to using d𝑑 (referred to in this text as the deposit ratio or stake participation ratio) in the equation for the reward curve instead of D𝐷 (deposit size or quantity staked). This can simply be done (1, 2) by swapping out D𝐷 for d𝑑 in the equation for the reward curve, and normalizing by including the circulating supply at the time of the swap, once the circulating supply begins to be tracked at the consensus layer. The main reason for this transition is that the long-run staking equilibrium under reward curves that adapt to D𝐷 instead of d𝑑 is ultimately also influenced by the circulating supply equilibrium, since the circulating supply will drift to balance supply, demand, and protocol income.\nSecondly, Ethereum should pursue MEV burn. As explained in the previous answers (1, 2), this will reduce relative variability and is a prerequisite for being able to reduce the staking yield substantially without causing too much concern for non-pooled stakers. As the answer soon turns to reduced issuance, it must be remembered that there is no direct financial motive for staking if the endogenous staking yield (MEV + issuance + airdrops) is negative. An equilibrium at negative issuance attracting a sufficiently large quantity of stake should thus still involve a positive expected endogenous yield. One concern is that the variability in MEV then involves non-pooled stakers taking on small losses each epoch while they wait for being assigned to special duties (note that variability in airdrops are not resolved by pooling). But there are many other reasons for MEV burn as well, as explored by Francesco, Justin, as well as Mike, Toni, and Justin.\nThe endgame when it comes to issuance level is currently a subject of debate but does indeed by all accounts involve an issuance reduction. The options can roughly be divided into five different categories:\n\nDo nothing; an alternative that must always be part of the conversation, but which is becoming increasingly less attractive assuming that staking costs continue to fall and the quantity of stake increases further.\nTemper issuance; but to a level that is perfectly sufficient also under the presence of MEV.\nCut issuance; an option situated in between (2) and (4). Does not institute an economic capping, but makes a high quantity of stake incredibly unlikely by lowering the yield substantially.\nEconomic capping, by letting the staking yield go to negative infinity at some desirable quantity of stake.\nA time–quantity policy; where the reward curve is allowed to slowly alter/bend in response to changes in the supply curve.\n\nAmong these options, (2) is becoming increasingly desirable at this point in my view. There is then a sliding scale from (3) to (4), where stricter reward curves are advantageous due to their ability to offer guarantees on the quantity of stake, while some restrictive settings at the same time also require more deliberations. There can be merits to an economic cap (4), ideally then after MEV burn, but in my view not at a too low quantity of stake. Some examples will be illustrated. Category (5) has not yet received much study and will be presented a little deeper. The answer will now briefly review the philosophical underpinnings of the optimization problem, and then take a closer look at each of the five categories.\nPhilosophical underpinnings of the optimization problem\nThe reward curve is in essence an attempt to optimize between all known trade-offs (long-run and short-run economic security, low costs, a viable composition of the staking set, reward variability, etc.), ensuring a utility-maximizing equilibrium under any supply curve. One way to understand the issue is thus that each hypothetical supply curve (low as well as high) has one optimal equilibrium, and the reward curve should intersect each supply curve at this point.\nIn economics, an expansion path connects optimal input combinations across output level, and an income expansion path selects the optimal consumption bundles across income. A suitable reward curve is the expansion path that optimizes all known trade-offs associated with high/low yield and stake participation across potential supply curves. Figures 5-8 in a previous answer illustrated the concept under three supply curves at different levels, where an optimal equilibrium could be found under all three using a reward curve from endgame (3).\nAs framed by Vitalik in a similar context: if a reward curve is designed such that some specific equilibrium is made possible, then that equilibrium should first have been deemed acceptable. In particular, it should ideally be the optimal equilibrium for the prevailing supply curve. But it must then also be noted that not only the level, but also the shape of the supply curve will matter. The reason is that the shape will influence which alternatives a specific equilibrium point can be substituted for when optimizing. There is a difference between the almost horizontal supply curve between 30M and 120M ETH in figures by Caspar and Ansgar, and the supply curves in this post that slope almost vertically upwards towards 120M ETH. In the former case, setting a negative yield at 30M ETH will seem like a more natural solution, because an economic cap at a low quantity of stake might not matter to solo stakers anyway, regardless of if the supply curve is lower or higher.\n1. Do nothing\nThis option remains valid while the quantity of stake remains reasonably close to 30M ETH (1/4 of the stake), previously discussed as a potential limit. There is a switching barrier associated with changing the issuance policy of a decentralized blockchain. The potential for discontent is higher if the switch takes place too close to previously discussed limits. But as mentioned in another answer, it seems reasonable to assume that the current quantity of stake of 32M ETH will not hold in the long run, as staking costs (broadly defined) fall. A threshold that would fit neatly with the notion of operating on powers of two is 2^{25}225 ETH, corresponding to 33.6M ETH. Once this threshold is exceeded (or on the path of being exceeded) when doing nothing, then doing something seems like a better option to me.\nExcessive incentives for staking, beyond what is necessary for security, can unfortunately over time turn into perverse subsidies. In a scenario where the application layer is built around excessive staking yield, the Ethereum economy will arguably not have proper trustless foundations, as previously discussed.\nOne thing to keep track of before deciding to “not do nothing”, and to “do something”, is the progress of MEV burn. A reduction in issuance should not take place at the same hard fork as when incorporating MEV burn. If MEV burn is very close to being ready, then this can be accounted for under certain circumstances. But MEV burn is still at an early research stage. One path is therefore to shortly institute a moderate reduction in issuance, a year or two before MEV burn, and then let MEV burn make another dent in the staking yield.\n2. Temper issuance\nThis option is presented in a previous answer. In summary, it represents a “safe” issuance reduction that will not increase relative variability too much for non-pooled stakers, providing a relevant staking yield for stakers across the full range. The option provides a sufficiently big reduction in issuance to make the associated governance process worth it—and small enough to make that process potentially easier. The option will still substantially temper the growth in the quantity of stake. Together with MEV burn, it can reasonably constitute an endgame issuance policy, in the sense that the quantity of stake remains close to 30M ETH and firmly below 60M ETH. However, this does not mean that (2) necessarily must be an endgame. Reducing the issuance even further at higher quantities of stake as in (3) and (4) will after MEV burn seem like a reasonable option. However, proceeding further than (2), for example to (4), would then need to be a separate discussion. There is a simple “on-switch” that could be used for such a transition, as discussed in the associated subsection.\n3. Cut issuance\nI refer here to the option situated in between econo","tokens":15000,"squid":"ink-research","role":"Deep Scholar","at":1791268329879,"hash":"c16f76b4d4d13a2bc8f6d49ebb1324ac8fd9aad7"}
{"url":"https://io.net/blog/blockchain-web3","domain":"io.net","title":"io.net blog","text":"Explore our Blog forLatest News & InsightsStay updated with the latest updates and new products. Discover what's happening around the io.net.Try io.intelligenceTry io.cloudBack To BlogBlockchain & Web3Latest By Topic (11)See AllAllArtificial IntelligenceDeveloper ResourcesAI Startup CornerAI Infrastructure & ComputeIO CloudIO IntelligenceCompany UpdatesCybersecurityBlockchain & Web3Success StoriesTech TrendsWhat is a GPU Cluster? Beginner's Guide, Cost Calculator, and Buy-vs-Build TipsIO.NET Team / Jun 26, 2026Learn what a GPU cluster is, how it differs from multi-GPU servers, and use our cost calculator to decide if you should build or rent one.GPU Cluster for AI: 2026 Buyer's Guide With Benchmarks & TCO CalculatorIO.NET Team / Jun 8, 2026Your 2026 guide to building a purpose-built GPU cluster for AI. Includes TCO, vendor-agnostic benchmarks, hardware selection (H100/MI300X), and rollout plan.Decentralized Computing in 2025: Architecture, Costs, and Migration GuideIO.NET Team / Jan 20, 2026Complete technical guide to decentralized compute: benchmarks, cost calculator, compliance checklist, and step-by-step migration from AWS/GCP.io.net Launches the First Adaptive Economic Engine for Decentralized ComputeIO.NET Team / Dec 11, 2025Discover io.net's Incentive Dynamic Engine (IDE): an adaptive tokenomics model bringing sustainable economics and predictable stability to decentralized GPU compute.GPU as a Service: Financial Guide for AI StartupsIO.NET Team / Oct 31, 2025Complete financial framework for GPU infrastructure decisions. Cost modeling, ROI analysis & budget optimization for AI companies. ML Model Deployment: Cut Costs 90% With Decentralized InfrastructureIO.NET Team / Oct 14, 2025Model deployment connects trained ML models to users, yet most stall due to cloud costs and vendor lock-ins. Decentralized platforms cut costs 90%.Smart Contracts & Decentralized Compute: io.net Leverages Blockchain for Seamless AutomationIO.NET Team / Oct 20, 2024io.net is leveraging smart contracts on the Solana blockchain to automate GPU rentals, payments, and resource allocation for transparent decentralized computing.Instant Payments via S65olana: How io.net Leverages Blockchain for Fast TransactionsIO.NET Team / Oct 13, 2024io.net is utilizing the Solana blockchain for instant GPU payments, smart contract automation, and secure, decentralized cloud computing transactions.io.net and Alpha Network Form a Partnership to Establish a Secure, Decentralized Environment for AI and Web3 ApplicationsIO.NET Team / Aug 4, 2024io.net partners with Alpha Network to create secure, privacy-compliant AI training using decentralized GPUs and Zero-Knowledge protocols.How Blockchain is Powering the Future of Cloud Computing on io.netIO.NET Team / Apr 28, 2024Blockchain meets cloud computing: io.net uses smart contracts and Solana for instant GPU payments, automated rentals, and zero middlemen fees.Developer & Technical Guides: Building on io.netIO.NET Team / Mar 10, 2024\"IO.net offers a decentralized GPU cloud, enabling scalable, cost-effective AI training, rendering, and simulations with global resources.\"","tokens":783,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268335218,"hash":"703d8b4c21a95b2d09994233b003aed3248b98be"}
{"url":"https://io.net/blog/gpu-cluster","domain":"io.net","title":"GPU Cluster for AI: 2026 Buyer's Guide With Benchmarks & TCO Calculator","text":"Back To BlogGPU Cluster for AI: 2026 Buyer's Guide With Benchmarks & TCO CalculatorIO.NET Team / Jun 8, 2026Try io.intelligenceGet StartedTry io.cloudDeploy GPUArtificial IntelligenceBlockchain & Web3Table of ContentsWhat is a GPU Cluster for AI?GPU Cluster ArchitectureGPU Density and Model Selection for LLM PerformanceBest Practices for Managing GPU Clusters for AIAdvanced Strategies for GPU ClustersDecision Matrix for GPU Cluster AdoptionTroubleshooting and MaintenanceReal-World Applications of GPU ClustersAI Development and DeploymentDecentralized GPU Networks Versus Traditional ClustersWhy Consider Decentralized GPU InfrastructureWhen Decentralized Networks Make SenseFrom Benchmarks to Budget-Ready DecisionsFrequently Asked QuestionsHow many GPUs per node and which model gives the best price-performance?InfiniBand, RoCE v2, or Ethernet: what's the real throughput vs. cost delta?Should we build on-prem, lease colo space, or go cloud?What does a realistic TCO look like at different scales?What hidden bottlenecks kill linear scaling?Your 8-GPU box just hit the wall. Training jobs queuing overnight, engineers waiting, and the CFO asking why the cloud bill doubled. You need a purpose-built GPU cluster for AI to ship your next model before the runway shrinks.Below, you'll find a vendor-agnostic blueprint with real price-performance numbers against four reference architectures, so you can hand procurement a defensible capex slide tomorrow.You'll learn the operational gotchas that kill training throughput, plus the five scripts we use to detect them in CI. By the end, you'll have a month-by-month rollout plan that gets you from pilot to production.What is a GPU Cluster for AI?A GPU cluster for AI is a network of interconnected graphics processing units working together to tackle artificial intelligence workloads that would take a single computer months or even years to complete.Each node in a GPU cluster typically includes one or more GPUs, CPUs, memory, and storage. Unlike CPUs, GPUs are designed for parallel computing and large-scale parallel processing, making them ideal for deep learning and complex AI tasks. The architecture includes thousands of cores optimized for parallel matrix multiplications and vector operations, which accelerates deep learning.Your infrastructure, your wayFull stack control without DevOps overhead.Try io.cloudGPU Cluster ArchitectureA well-designed GPU cluster architecture is the backbone of high-performance AI workloads. At its core, a GPU cluster is built from multiple GPU nodes, with each node housing one or more high-performance GPUs, linked together by high-speed interconnects such as InfiniBand or advanced Ethernet.Key components include:GPU nodes with one or more high-performance GPUsHigh-speed networking hardware (InfiniBand or Ethernet)Robust storage solutions capable of feeding data to GPUs at high speedsThis architecture allows computational workloads to be distributed across multiple GPUs, dramatically accelerating both training and inference tasks. To ensure peak throughput, careful attention must be paid to resource allocation, minimizing latency, and identifying potential bottlenecks like network congestion or inefficient data access patterns.GPU Density and Model Selection for LLM PerformanceThe sweet spot for LLM workloads is 8 GPUs per node. Your choice between A100, H100, and AMD's MI300X depends on whether you're pre-training or fine-tuning.During pre-training, the H100's improved performance and superior memory bandwidth (3.35 TB/s vs 2 TB/s for A100) make it worthwhile when you factor in reduced training time. For training large language models, GPUs with high memory bandwidth, such as the NVIDIA H200 and AMD MI300X (offering up to 4.8-5.3 TB/s), are essential.Always consider your specific use case when selecting GPU clusters, as this will inform your choices for hardware, orchestration software, storage, and networking.Best Practices for Managing GPU Clusters for AIBuilding an effective GPU cluster for AI requires careful planning beyond just buying hardware. Start by right-sizing your infrastructure. Many teams overspend on high-end GPUs when mid-tier cards would suffice. Research has shown that consumer GPUs like the RTX 3080 and 3090 can be highly cost-effective for computer vision workloads, with optimized configurations matching or exceeding the cost-efficiency of datacenter GPUs for many tasks.Fast storage solutions like NVMe SSDs are essential for optimizing performance by ensuring quick data access in GPU clusters. High-speed networking channels are crucial for maximizing computing power and reducing latency. GPU clusters require a combination of hardware, software, and networking to ensure seamless operation and high-performance compute.Advanced Strategies for GPU ClustersPushing a GPU cluster for AI beyond vanilla training pipelines unlocks 3-4x speed-ups that most teams never see. Effective resource orchestration and managing GPU clusters with software like Kubernetes and Slurm are essential for handling distributed workloads.GPU acceleration enables AI frameworks to efficiently perform computational tasks. GPU clusters are designed to handle multiple tasks simultaneously, improving efficiency and throughput. AI-driven optimization tools are being developed to automatically adjust resource allocation in GPU clusters.Thousands of GPUs ready when you areGlobal decentralized network across 138 countries.Scale training and inference workloads without centralized bottlenecks.Start buildingDecision Matrix for GPU Cluster AdoptionChoosing the right GPU cluster setup requires a structured approach. A decision matrix helps you evaluate critical factors:Computational demands of your model training pipelineType and number of GPUs requiredStorage and networking capabilitiesSoftware platforms that support your workflowsTotal cost of ownership (acquisition, maintenance, operational expenses)Scalability for future growthReturn on investmentBy systematically comparing these variables, organizations can select GPU clusters that align with their technical requirements and business goals.Troubleshooting and MaintenanceKeeping a GPU cluster running at peak efficiency demands proactive troubleshooting and regular maintenance. Latency and performance bottlenecks can creep in from network congestion, outdated drivers, or suboptimal resource allocation.Monitoring tools are essential for identifying these issues early. Routine maintenance such as updating software, checking hardware health, and maintaining cooling systems helps prevent unexpected downtime. For clusters running at scale, advanced cooling solutions like liquid cooling can reduce the risk of overheating and extend GPU lifespan.Real-World Applications of GPU ClustersGPU clusters are the workhorses behind today's most demanding AI and data analytics applications:AI and Machine Learning: Training large language models and deep neural networks, processing massive datasets that would overwhelm traditional compute resources.Computer Vision: Real-time image and video analysis for autonomous vehicles, medical diagnostics, and security systems.Natural Language Processing: Powering chatbots, translation services, and sentiment analysis with billions of parameters.Big Data Analytics: Sifting through massive datasets for predictive analytics, fraud detection, and business intelligence.Scientific Research: Accelerating complex simulations in climate modeling, materials science, and genomics.AI Development and DeploymentGPU clusters provide the computational power needed for both training and inference. By leveraging parallel processing capabilities, end-to-end AI workflows are shortened. Models can be iterated, tested, and fine-tuned rapidly, ensuring faster time-to-market.When it comes to deployment, GPU clusters enable real-time AI applications in computer vision and natural language processing, where low latency and high throughput are non-negotiable. Managing GPU resources effectively is key to maintaining maximum performance and cost efficiency, especially as AI workloads scale.Decentralized GPU Networks Versus Traditional ClustersFor teams facing budget constraints or GPU shortages, decentralized GPU networks present a compelling alternative to traditional on-premise or cloud infrastructure. Platforms like io.net aggregate underutilized GPU resources from data centers, crypto miners, and individual providers across the globe, offering access to computational power at significantly reduced costs.Why Consider Decentralized GPU InfrastructureThe GPU shortage crisis has pushed many AI teams to explore alternatives to traditional cloud providers. Decentralized networks like io.net offer several key advantages:Cost Savings: Research shows consumer GPUs can cut AI inference costs by up to 75% compared to enterprise cloud pricing. io.net delivers up to 70% cost savings versus major cloud providers by tapping into idle GPU capacity worldwide.Performance Flexibility: Understanding the differences between GPUs and CPUs for AI workloads helps teams right-size their infrastructure. Decentralized networks provide access to a diverse GPU pool, from consumer RTX cards for inference to enterprise H100s for training, allowing you to match hardware to specific tasks.Rapid Deployment: Unlike traditional infrastructure with weeks or months of lead time, decentralized platforms enable deployment of GPU clusters in minutes. io.net operates across 130+ countries with thousands of verified GPUs ready for immediate use.Real-World Implementations: Companies like ChainGPT use io.net to power affordable smart contract analytics, while partnerships like the Allora and io.net collaboration demonstrate how decentralized GPU compute scales AI applications.Cut GPU costs by 70%Enterprise-grade H100s and A100s at a fraction of hyperscaler pricing.Pay only for what you use.See pricingWhen Decentralized Networks Make SenseDecentralized GPU infrastructure works best for:Teams with variable workloads that don't justify owning hardwareStartups and research groups with limited capital budgetsProjects in the inference or fine-tuning phase rather than massive pre-trainingOrganizations seeking geographic diversity for redundancy or latency optimizationWorkloads that can tolerate slightly higher variance in GPU availabilityWhile decentralized networks may not replace dedicated clusters for the largest training runs, they represent an increasingly viable option for the majority of AI workloads. The combination of cost efficiency, rapid deployment, and diverse GPU access makes platforms like io.net worth evaluating alongside traditional infrastructure options.From Benchmarks to Budget-Ready DecisionsYou now have the vendor-neutral benchmark numbers, the plug-and-play TCO model, and the five-step checklist to turn \"more GPUs\" into a precise, budget-bound training plan. GPU clusters are foundational for AI, HPC, and enterprise computing, supporting scalable model training, inference, and rapid deployment.The future of GPU cluster technology is defined by rapid advancements in hardware, smarter workload management, and the expansion of edge computing. GPU technology continues to evolve, with new hardware releases pushing the performance envelope.Remember: match GPU tier to model size, lock in cost per GPU-hour before you sign, and build in a 20% buffer for data-pipeline surprises. These three moves alone saved early readers an average of $312k on a 64-node cluster.Your next step is to open the interactive calculator, drop in your parameters, and let it generate the exact CapEx, OpEx, and break-even point for your AI workload. Download the spreadsheet, share it with finance, and you'll walk into the next planning meeting with defensible numbers instead of ballpark guesses.AI leadership belongs to teams who stop renting hope and start owning the math. Build the cluster that trains your model on time, under budget, and ahead of the competition.Frequently Asked QuestionsHow many GPUs per node and which model gives the best price-performance?For pre-training, 8x H100 nodes deliver the sweet spot. NVLink within the node keeps 700 GB/s all-reduce local, while the 4 TB/s NVSwitch reduces the number of rail-aligned Infiniband switches needed versus 4x configs. H100 GPUs typically cost $25,000-$30,000 per unit, with complete 8-GPU systems reaching $200,000-$400,000 including infrastructure.Fine-tuning is far less bandwidth-hungry. A single 8x MI300X node with 192 GB VRAM per GPU lets you fit a 70B model in 4-bit and still keep a 2048-token batch on one node, avoiding expensive scale-out fabric. If you already own A100s, stay put. Two 8x A100 nodes with RoCEv2 can saturate PCIe gen4 for 7-13B parameter models, and A100 resale value is holding better than V100s did.InfiniBand, RoCE v2, or Ethernet: what's the real throughput vs. cost delta?At 64 GPUs (8 nodes), the three fabrics are comparable: 200 Gb HDR InfiniBand gives 23 GB/s effective all-reduce, RoCEv2 with DCQCN lands at 21 GB/s, and vanilla 100 GbE with generic ECN reaches 18 GB/s. Yet the bill drops from $120k to $35k. Unless you run 50+ TB of data-parallel work per week, pocket the $85k and spend it on NVMe instead.Scale to 256 GPUs and InfiniBand's adaptive routing keeps tail latency under 7 µs, so your 1.3 TB model still scales at 93% efficiency. RoCE drops to 78% unless you add congestion-control tuning (two weeks of staff time). With 1024 GPUs, a rail-optimized QM9700 spine-leaf IB fabric costs $1.1M but saves 150 ms per optimizer step, cutting a 3-month 175B pre-train by 11 days.Should we build on-prem, lease colo space, or go cloud?Do the 18-month TCO litmus test: if your utilization will break 65% (roughly 16 hours/day of useful jobs), on-prem 8x H100 nodes win at $2.83/GPU-hr all-in (0.07 $/kWh, 5-year amortization). Below 35% utilization, cloud rental prices have dropped significantly, now ranging from $2-$4 per hour for H100s, making cloud more cost-effective even with 1-year commitments. You can also burst to 256 GPUs in minutes.The middle ground is colo leasing in tier-2 markets (Phoenix, Columbus) at 0.09 $/kWh with 5 kW/rack delivered. You bring GPUs, they provide chilled water and 100% uptime SLA. Typical opex ends up at $3.10/GPU-hr with only a 12-month lock-in.What does a realistic TCO look like at different scales?128 GPUs (16x 8-GPU nodes) fits in four 42U racks and draws 130 kW:Budget: $4.0M capex for H100s, $0.4M for storage, $0.5M for network, $0.3M for racks/PDUsOpex: $0.44M/yr (power $0.07/kWh, 1.2 PUE) plus two FTEs ($0.3M)Five-year TCO = $6.6M, or $1.03/GPU-hr assuming 90% utilization512 GPUs needs 64 nodes, 540 kW, 20 racks. You save on bulk pricing (GPU cost drops 8%) but need chilled-water cooling and a 24x7 ops team of five:Totals: $15.8M capex, $1.6M/yr opex → $0.87/GPU-hr2048 GPUs is datacenter-scale: 2.2 MW, redundant chillers, 10 InfiniBand spines:Five-year TCO hits $55M, but per-GPU-hr falls to $0.74Biggest risk: schedule slippage. Every month of idle facility costs $180k before the first GPU arrivesWhat hidden bottlenecks kill linear scaling?PCIe fan-out matters: a single Broadcom PEX8900 96-lane switch hanging eight GPUs behind one NUMA node can add 8 µs DMA contention, reducing throughput by 12%. Always demand a 2-root-complex topology (two CPU sockets) and verify with nvbandwidth. If single-thread H2D is under 20 GB/s, negotiate a board respin.NIC firmware can silently cap RoCE MTU to 4 KB. When you later enable 8 KB jumbo frames for large-message workloads, effective bandwidth drops 6% and tail latency spikes. Before you sign, run a 24-hour perftest with 8 KB messages across 32 nodes while toggling adaptive routing. Packet loss must stay below 0.001%.In Kubernetes, the default bridge CNI clones every packet on the veth pair. Switch to SR-IOV or Macvlan and watch a 9% jump in NCCL throughput. Finally, flash your BIOS to the vendor's \"HGX\" profile for a 4-5% step-time reduction in training runs.Spin up H100s in under 2 minutesNo contracts. No waitlists.Get started","tokens":4025,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268345018,"hash":"93790f97241961e6bf4ba94d7d3c6081709e474a"}
{"url":"https://io.net/blog/three-years-of-building-the-future-of-ai-compute","domain":"io.net","title":"Three years of building the future of AI compute","text":"Back To BlogThree years of building the future of AI computeIO.NET Team / Jun 12, 2026Try io.intelligenceGet StartedTry io.cloudDeploy GPUTable of ContentsYear one: From launch to product-market fitWhat we shipped in year oneYear two: Scale and ecosystemWhat we shipped in year twoYear three: Real revenue, real burnsWhat we shipped in year threeOn June 11, 2023, io.net launched with a straightforward idea. AI workloads need more compute than centralized hyperscalers can ever deliver, and the solution would be a decentralized network of GPUs, not another mega data center, that turns underutilized capacity into on-demand infrastructure.Three years later, we’ve fundamentally changed the AI compute market. io.net is now the largest decentralized GPU network in the world. Thousands of GPUs distributed globally, with $8 million in enterprise deals closed in just Q1 of 2026 alone. That means real revenue from real companies running real production workloads, with all of that actual compute demand verified on-chain. Today marks not only io.net's third anniversary but also something truly momentous. The Incentive Dynamic Engine (IDE) is now live. And it will redefine how DePIN protocols prove their value. It’s simple and based on real utility. Every token burn is tied to actual compute usage. This means every mint is transparent and fully verifiable on the io.net explorer.But to understand how we got here, we’ve put together a little retrospective of where we started, what we’ve built over the last three years, and what comes next. Year one: From launch to product-market fitJune 2023 – June 2024The io.net team spent its first year with our heads down. We knew we could build a decentralized network that would deliver enterprise-grade GPU compute that teams would actually pay for. We just had to prove it. To do this, we realized very early on that we would need to solve three primary problems simultaneously: Supply – Getting GPUs onto the network. A massive endeavor, combining business development and infrastructure logistics. Demand – Convincing AI teams to trust decentralized infrastructure. No small task. Orchestration – Making it work reliably enough that customers not only choose us in the first place for their compute needs but ultimately decided to come back. What we shipped in year oneThe io.net team accomplished a great deal in just a year. A testament to achievements from both technical and non-technical teams alike. io.net marketplace – Our decentralized GPU marketplace went live with 10,000 GPUs in the first quarter, offering users H100s, A100s, and consumer cards from a network of verified suppliers that spanned the globe.Single-GPU access – This quickly became io.net’s first major differentiator. While AWS and GCP are busy forcing teams onto full 8-GPU nodes ($32-40/hr minimum) with predatory contracts, io.net gave  teams the ability to rent exactly what they needed, whether it was a single H100 for $2.20/hr instead of eight of them at $35/hr.First enterprise customers onboarded – Our first paying users ran the gum, from AI startups fine-tuning models and research labs running distributed training to SaaS companies deploying inference at scale, and everything in between.Token launch ($IO) on Solana – Our network went live with a simple tokenomics model: supply rewards for GPU providers and staking for network security. It worked, but it wasn't sustainable over the long-term. Emissions outpaced demand, and we knew it. By the end of year one, io.net had proven the model worked. Teams were paying for compute and suppliers were earning revenue, all on an infrastructure that was stable. The tokenomics just needed to evolve.Year two: Scale and ecosystemJune 2024 – June 2025Year two was about going beyond proving \"this works\" to a vision that \"this scales.\" We realized this with a clear plan that meant growing the GPU supply, deepening our enterprise relationships, and building strong partnerships, all of which would combine to position io.net as the GPU layer for Web2 AI companies and Web3 infrastructure.What we shipped in year twoYear two saw the io.net team build on its first year successes, with a new product launch, more suppliers onboarded, co-marketing opportunities, and community building. Supply growth – The network added enterprise-grade data center capacity alongside consumer hardware, giving teams access to NVLink H100 clusters, high-bandwidth A100 pods, and cost-optimized RTX 4090 nodes.io Cloud product launch – The core GPU cloud offering became a fully managed platform. Deploy Docker containers, run distributed training jobs, launch inference endpoints. No need for infrastructure management; teams simply went from account creation to running their first job in under 20 minutes.Industry momentum – Solana Foundation positioned io.net as the DePIN infrastructure leader in their ecosystem. Messari, CoinDesk, and research firms began tracking io.net as the benchmark for decentralized compute, while co-marketing deals with complementary protocols brought cross-ecosystem visibility.Astronaut program launch – 52 community members organized into seven crews (Dev, Social, Regional) providing support, amplification, and localization. The model worked: Discord moderation improved, X reach expanded, and regional markets (LATAM, APAC, Europe) got dedicated attention they deserved. By the end of year two, io.net had crossed into a new category. It moved beyond a DePIN experiment, to AI infrastructure that enterprise clients and AI startups around the world depended on. There was, however, still a gap between actual revenue and token emissions. Solving that problem became our priority as we entered our third year.Year three: Real revenue, real burnsJune 2025 – June 2026Year Three was the year we proved DePIN could be a true competitor to traditional cloud providers. We set out to demonstrate that the GPU marketplace could be truly sustainable, profitable, and sustainable at scale. What we shipped in year threeIn year three, we built on our successes in previous years with more enterprise deals, confidential GPU access, and an even more active DePIN ecosystem. And, this was the year that we set out to deliver a fully evolved and sustainable tokenomics model. New tokenomics – We announced the roadmap to IDE: a demand-linked emissions model where token burns are tied to actual network revenue. This kicked off the community feedback loop, the first step toward sustainable tokenomics. But implementation was still six months out.Most active DePIN network – The network hit a new scale milestone. Supply now includes curated enterprise clusters (8× H100 NVLink pods), cost-optimized consumer GPU pools, and regional capacity in North America, Europe, and APAC. Availability is now 99%+ so that teams never have to queue for GPUs, they just launch and get to market faster.Confidential Compute launch – Security-first GPU access for privacy-sensitive workloads: encrypted enclaves, secure boot, and verifiable computation. What this did is open the regulated industries market in healthcare, finance, and legal. Teams can now run compliant inference and training jobs on io.net without ever exposing sensitive customer data.Agent Cloud – For agents to be truly autonomous they need to be able to act without human intervention. With Agent Cloud, agents can purchase, manage, scale, and delete compute resources using existing credits without the friction of having to wait for humans.After three years, io.net isn’t  just a DePIN project. We’ve done something bigger. We’ve fundamentally transformed into a revolutionary decentralized GPU cloud where real customers generate real revenue and value, with a tokenomics model to prove it.With today’s launch of the Incentive Dynamic Engine (IDE) model, io.net inaugurates a new era in tokenomics. Our industry-first model ties every token burn directly to compute revenue, and you can verify the transparency yourself through our public dashboard, tracking real-time on-chain data.Three years in, we’ve built so much but, really, we’re just at the beginning of something monumental. A world where AI infrastructure is not lorded over by centralized entities. A world where devs don’t need to turn to mega data centers and predatory contracts. A world where AI is truly open and accessible made possible by decentralized compute and ope-source models. The future of AI compute is being built on io.net. And 3 years in, we’re just getting started.The future of AI compute. 70% savings. No waitlists.Get started today","tokens":2143,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268354996,"hash":"8081cdb9940f4ee0db89c6dcec372e036b499188"}
{"url":"https://aave.com/agents","domain":"aave.com","title":"Agents for Aave | Aave","text":"Aave for AgentsTheCredit LayerforAgentic FinanceGive agents capabilities other integrations can’t match, from earning and borrowing to position swaps and leverage.Connect Aave MCPRead the Docs █████╗ █████╗ ██╗ ██╗███████╗ ███╗ ███╗ ██████╗██████╗██╔══██╗██╔══██╗██║ ██║██╔════╝ ████╗ ████║██╔════╝██╔══██╗███████║███████║██║ ██║█████╗ ██╔████╔██║██║ ██████╔╝██╔══██║██╔══██║╚██╗ ██╔╝██╔══╝ ██║╚██╔╝██║██║ ██╔═══╝██║ ██║██║ ██║ ╚████╔╝ ███████╗ ██║ ╚═╝ ██║╚██████╗██║╚═╝ ╚═╝╚═╝ ╚═╝ ╚═══╝ ╚══════╝ ╚═╝ ╚═╝ ╚═════╝╚═╝v1.0.0 - The Credit Layer for Agentic Finance›Put 500 USDC into Aave so I can earn interest.✓ [get_markets] 19 USDC routes scanned · best available route selected ╭─ Earn · Supply Preview ────────────────────────────────────────────────────╮│ 500.00 ● USDC ───────────▶ AAVE V4 Ethereum ──────────▶ Bluechip Prime ││ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ││ APY now 6.03% Est. return +30.17 USDC / year ││ 7d range 3.10-9.88% Monthly ~2.51 USDC ││ 7d APY ▃▃▁▁▁▂▃▃▄▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▇▅▅▅▅▂██▁▁▁█▇▃▃▃▃▂▆▃▃▃▃▅▄▄▄▄ 6.03% ││ ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ││ ✓ Your 500 USDC is ready to deposit ~ Interest rate may change │╰────────────────────────────────────────────────────────────────────────────╯[Enter] Review Deposit [E] Edit Amount [R] Rescan [?] HelpV3 & V4 MarketsTransaction PreviewsPosition MonitoringNon-CustodialEarnPut idle assets to work.Compare supply opportunities and prepare a deposit for wallet approval.BorrowAccess liquidity against collateral.Compare rates and available liquidity before preparing a borrow.Position HealthRespond before liquidation.Monitor health factor and prepare a risk-reducing action before liquidation.Trading BotTrade when conditions are met.Monitor prices and prepare trades when your strategy’s rules are met.ConnectThree steps from client to credit.Add Aave MCP to your agent of choice. One public endpoint gives it a direct interface to Aave V3 and V4.01 /Choose your client02 /Connect the MCPWorks in ChatGPT on any plan with connectors enabled.Add to ChatGPTOr add it by hand under Settings → Connectors:https://mcp.aave.com03 /Start with a promptOnce Aave MCP is connected, copy one of these into your agent. Earn and Borrow are the simplest places to begin.EarnPut idle assets to work.Compare available supply opportunities, preview the expected yield, and prepare a deposit for wallet approval.Compare Aave supply opportunities for 1,000 USDC and prepare the best option.BorrowBorrow against supplied collateral.Compare available liquidity and rates, then preview the resulting health factor before borrowing.Borrow 1,000 USDC against my ETH. Show the rate and projected health factor before I approve.RepayReduce debt and restore buffer.Repay fully or partially, then preview how debt and health factor change before anything is submitted.Repay 25% of my USDC debt using supplied collateral.Position SwapSwap within a position.Change supplied collateral or borrowed assets while keeping the resulting health factor and approvals visible.Move 10% of my WETH collateral into USDC and preview the resulting position.DeleverageReduce debt and improve account health.Yield AnalysisCompare rates, liquidity, and capacity across markets.Safe TransactionsSimulate every step before wallet approval.Account ActivityReview wallet activity across supported chains.Tx ConfirmationConfirm what changed after a transaction.Build an Aave SkillTurn a repeatable workflow into an Aave Skill.Aave’s EdgeBuilt for agents. Native to Aave.Trading capabilities, not just market dataAgents can prepare protocol-native position swaps and leverage — not only read prices, rates, and balances.V4-native position actionsAccess V3 and V4 markets, position swaps, and unified liquidity through one interface.Efficient across model tiersCompact responses are designed to work with affordable models; stronger models can extend the experience.Advanced actions, one interfaceResearch, simulate, and prepare complex actions without stitching together separate protocols.Safety by DesignThe agent prepares. Your wallet authorizes.Agents can read, plan, and simulate, but every live action still requires your wallet’s approval.Review the Safety ModelYour agent asksUse natural language to research a market, inspect a position, or describe an action.Aave preparesThe MCP reads live protocol data, simulates the action, and prepares an unsigned transaction.Your wallet decidesReview the exact action in your wallet. Nothing moves until you approve and sign it.Aave for AgentsGive agents a credit layer.Connect to live protocol context, advanced position actions, and wallet-controlled execution.Connect Aave MCPRead the DocsFAQsYour AI agent, connected to Aave. It can compare markets, check your positions, simulate an action, and hand your wallet a transaction to sign.An open standard your agent uses to reach live tools. Add one endpoint, mcp.aave.com, and your agent gets 40 Aave tools. No API key, no account.No. Nothing holds your keys or moves your funds. Your agent prepares; your wallet signs, and nothing happens until it does.Earn, borrow, repay, withdraw, swap, claim rewards, manage collateral, deposit into Savings GHO. Ask it to simulate first and you see the rate and health factor before you approve.Aave V3 on 21 chains and V4 on Ethereum and Avalanche, from the same endpoint. Live rates, your positions and history, and DAO proposals.","tokens":1368,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268372830,"hash":"c1b2a68cf40fb907a0910b5c69c823c30a45963f"}
{"url":"https://forum.openzeppelin.com/t/how-can-i-deploy-create2-smart-contract-with-private-key/28015/1","domain":"forum.openzeppelin.com","title":"How can I deploy CREATE2 smart contract with private key? - Smart Contracts - OpenZeppelin Forum","text":"How can I deploy CREATE2 smart contract with private key? \n\n Smart Contracts\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n post by BenoBino on Apr 25, 2022\n\n BenoBino\n\n Hello, I am having issue with CREATE2\nwhat I am trying to do is, deploying smartcontract made by create2 function with my privatekey.\nI am trying to do this with truffle.\nand whenever type \" npx oz create2 MyContract --salt 12345 --network testnet \"\nI get this error \" Contract MyContract is not deployed to dev-1001 \"\nbut when I execute oz deploy, dev-1001.json file gets MyContract there.\nlike this. \"MyContract\":[ { \"address\".. \"kiond\".. \"bytecodeHas\"}]\nI am so clueless. I don't know what to do. if anyone can help? plz\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Create2: Failed on deploy when using Create2 library\n\n Contracts\n\n 2\n\n 2.8k\n\n Jul 2020\n\n How to use a CREATE2 deployer\n\n General\n\n 7\n\n 2.1k\n\n Jun 2021\n\n Smart contract deploy error\n\n Contracts\n\n erc20,bep20,solidity,truffle\n\n 4\n\n 2.8k\n\n Jun 2021\n\n Guide to using Create2.sol library in OpenZeppelin Contracts 2.5 to deploy a vault contract\n\n Guides and Tutorials\n\n 5\n\n 7.6k\n\n Mar 2025\n\n Deploying Smart Contracts Using CREATE2 tutorial query error `Maximum call stack size exceeded`\n\n SDK\n\n 1\n\n 1.3k\n\n Jul 2021","tokens":333,"squid":"ink-security_audits","role":"Sentinel","at":1791268376987,"hash":"d0d9c18cbff1ba402e442db5fc7f3c2ca41a3d25"}
{"url":"https://aave.com/blog/case-studies","domain":"aave.com","title":"Blog | Aave","text":"How Ink and Kraken Use AaveHow Kraken's Ink L2 built Tydro on Aave V3 to power native lending and embedded DeFi for millions of users.Recent PostsCapCap integrates Aave to deploy idle stablecoin reserves and benchmark yield rates, growing to one of Aave's largest USDC depositors with over $360M supplied.Case StudiesIntegrationArbitrumAave has solidified its role as a cornerstone of Arbitrum's ecosystem, establishing the chain as the premier \"home of DeFi.\"Case StudiesIntegrationTangemHow Tangem uses Aave to Power Non-Custodial Yield.Case StudiesIntegrationKinexys by J.P. MorganHow Aave protocol was adapted for institutional needs as part of the Project Guardian initiative led by the Monetary Authority of Singapore.Case StudiesIntegrationLidoLido's liquid staking combines forces with Aave to power DeFi's ETH yield engine.Case StudiesIntegrationBlockdaemonHow Blockdaemon Uses Aave to Power Institutional Access to Onchain Yield.Case StudiesIntegrationBTCSHow Nasdaq-listed BTCS Uses Aave to Finance its Digital Asset Treasury (DAT) Strategy.Case StudiesIntegrationGalaxyInstitutional Liquidity in Practice.Case StudiesIntegrationEthenaEthena’s Ascent to $10bn, Powered by the Aave Liquidity Engine.Case StudiesIntegrationMetaMaskMetaMask selected Aave as its DeFi lending partner to power Stablecoin Earn, a feature that lets users earn yield directly inside their wallet.Case StudiesIntegrationAvalancheAvalanche uses Aave to securely access decentralized capital markets.Case StudiesIntegration","tokens":377,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268383364,"hash":"01cd55fd62f816e2ead78a1fc86657aeb2b012c4"}
{"url":"https://forum.openzeppelin.com/t/smart-contract-deploy-error/9878/1","domain":"forum.openzeppelin.com","title":"Smart contract deploy error - Support / Contracts - OpenZeppelin Forum","text":"Smart contract deploy error \n\n SupportContracts\n\n erc20,bep20,solidity,truffle\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jun 2021\n\n 1 / 5\n\n Jun 2021\n\n Jun 2021\n\n post by Komeil_Mirsamie on Jun 4, 2021\n\n Komeil_Mirsamie\n\n Hi, I'm a beginner at creating contracts, I've error when I deploy my contract with truffle and ganache-cli:\n\"Owo\" hit a require or revert statement somewhere in its constructor. Try:\n * Verifying that your constructor params satisfy all require conditions.\n * Adding reason strings to your require statements.\n\nthis is my constructor code:\n\n constructor (address payable charityWalletAddress) public {\n _charityWalletAddress = charityWalletAddress;\n _rOwned[_msgSender()] = _rTotal;\n\n IUniswapV2Router02 _uniswapV2Router = IUniswapV2Router02(0x10ED43C718714eb63d5aA57B78B54704E256024E);\n // pancakeswapv2 for BSC network\n // Create a uniswap pair for this new token\n uniswapV2Pair = IUniswapV2Factory(_uniswapV2Router.factory())\n .createPair(address(this), _uniswapV2Router.WETH());\n\n // set the rest of the contract variables\n uniswapV2Router = _uniswapV2Router;\n\n // Exclude owner and this contract from fee\n _isExcludedFromFee[owner()] = true;\n _isExcludedFromFee[address(this)] = true;\n\n emit Transfer(address(0), _msgSender(), _tTotal);\n }\n\n3_deploy.js\n\nconst Owo = artifacts.require(\"Owo\");\n\nmodule.exports = async function (deployer) {\n const accounts = await web3.eth.getAccounts()\n await deployer.deploy(Owo, accounts[0]);\n};\n\ncan anyone explain to me where is the problem with my code?\n\n 3\n\n 2\n\n post by Yoshiko on Jun 4, 2021\n\n Yoshiko\n\n Hi Komeil! Welcome to Open Zeppelin.\nLooking at your code\nIUniswapV2Router02 _uniswapV2Router = IUniswapV2Router02(0x10ED43C718714eb63d5aA57B78B54704E256024E);\nWhich network are you deploying to? If you are deploying to a test net, this router address needs to change. The router doesn't exist anywhere, but on BSC's live net.\nAs you mentioned you are new, I highly recommend doing this tutorial.\n\nYou don't have to understand it 100%, but it's a great way to get you up to speed and get a developer environment going.\nAfter that check out\n\nI know it's a pain to go through all this, but as you learn you will give yourself the skills needed to create any type of smart contract you want.\n\n post by Komeil_Mirsamie on Jun 5, 2021\n\n Komeil_Mirsamie\n\n how I can find my network address? I use rinkeby network.\nis there any possibility to test my token in PancakeSwap for adding liquidity and etc?\nbtw Thanks for your usefull information.\n\n post by Yoshiko on Jun 6, 2021\n\n Yoshiko\n\n Yes absolutely you can use https://pancake.kiemtienonline360.com/#/swap for testing with pancakeswap, the router address is 0x9Ac64Cc6e4415144C455BD8E4837Fea55603e5c3\nFor your network address, I’m a little confused at what you mean. Your wallet in metamask should remain the same. For network address you can find it with your API key if you are using Alchemy.\n\n post by Komeil_Mirsamie on Jun 7, 2021\n\n Komeil_Mirsamie\n\n Hi again and thanks for your response, I’ve another question How can I see the chart of my test token? Is there any website to show bsc testnet tokens chart?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Truffle migrate error: “MyContract” hit a require or revert statement somewhere in its constructor\n\n Developer Wanted\n\n erc20,truffle\n\n 0\n\n 918\n\n Jul 2021\n\n Publish Uniswap to Ganache\n\n Contracts\n\n 0\n\n 1.0k\n\n Jun 2021\n\n Error on migration on truffle\n\n Smart Contracts\n\n etherscan-verify,solidity,truffle\n\n 3\n\n 1.6k\n\n Sep 2021\n\n Help! I don’t know whats wrong with my code but\n\n Contracts\n\n erc20\n\n 17\n\n 2.1k\n\n May 2021\n\n Problem about Create a uniswap pair in smart contract constructor!\n\n Smart Contracts\n\n 1\n\n 664\n\n Feb 2022","tokens":950,"squid":"ink-security_audits","role":"Sentinel","at":1791268387264,"hash":"ea682e1162e9a664fcdec5e3d3c7a4533a4b3bb2"}
{"url":"https://aave.com/blog/cap","domain":"aave.com","title":"Cap | Aave","text":"Back to BlogCapAave Labs•5 Feb, 2026IntegrationSuccess StoryCap is a stablecoin protocol that provides credible financial guarantees through two products, the dollar-denominated cUSD and the yield-bearing stcUSD. Notably, Cap integrates with Aave to deploy idle capital and as a benchmark for its own yield generation, which has helped it grow to one of Aave's largest depositors.\nBackground\nCap, short for Covered Agent Protocol, is a covered credit system that issues cUSD, a stablecoin backed by a reserve of regulated stablecoins and tokenized money market funds.\nThe protocol outsources yield generation to a network of institutional operators who borrow from Cap's Credit Engine. These operators, which include banks, high-frequency trading firms, and market makers, generate yield through private credit.\nTo borrow, operators must secure coverage from risk underwriters in Cap's Financial Guarantee Market. Underwriters post escrowed capital that can be used to cover any losses in case of default.\ncUSD can be staked to receive stcUSD, which earns yield from the protocol's yield strategies. A dynamic Hurdle Rate sets the minimum yield that borrowers must pay to lenders and stcUSD holders. All yield up to the Hurdle Rate is distributed to stcUSD holders, while any surplus is retained by the operator after fees.\nHow Cap Relies on Aave\nCap uses Aave for two primary functions, capital efficiency and as a benchmark rate. Cap's Fractional Reserve contracts automatically send idle capital from its reserves to Aave, which earns yield for stcUSD holders. This process maintains a liquidity buffer for cUSD redemptions and strengthens the peg stability of the stablecoin.\nCap also uses Aave's rates as a benchmark for its Credit Engine. The minimum yield threshold for operators is the higher of two rates, a preconfigured protocol benchmark rate or the dynamic market rate from Aave's USDC supply. This approach establishes a competitive floor for yield, which reflects the baseline opportunity cost of capital in the decentralized finance ecosystem.\nCurrent Stats\nSince its launch in August 2025, the total value locked in the Cap protocol has grown to $500 million as of January 2026. Over 80% of Cap's cUSD reserves, or more than $360 million, are currently deployed on the Aave V3 Core Ethereum market. This makes Cap one of the largest suppliers of USDC to Aave.\n\nMore than half of all cUSD is staked for stcUSD, which has generated $4 million in cumulative yield for token holders. The average hurdle rate over the past 90 days has been 5.2%. Aave is the primary source of this yield, accounting for over 90% of the total returns for stcUSD.\n\nOutlook\nCap and cUSD represent an evolution in stablecoin design that moves toward sustainable, risk-managed yield with verifiable guarantees.\nThe protocol's integration with Aave for deploying idle capital and for benchmarking highlights a broader trend in DeFi. Participants in the DeFi market increasingly view depositing on Aave as the baseline opportunity cost for their capital allocation decisions.\nIn a maturing DeFi ecosystem, sustainable yields depend on deep, scalable liquidity. Aave's proven track record solidifies its position as the go-to benchmark for rates, risk pricing, and innovation.Need help or want to learn more?Share your questions or feedback and we'll get back to you.Name *Email *Your message *","tokens":845,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268393213,"hash":"43c9673651a1e2b7b805de12feef327312c26abf"}
{"url":"https://forum.openzeppelin.com/t/smart-contract-deploy-error/9878/5","domain":"forum.openzeppelin.com","title":"Smart contract deploy error - Support / Contracts - OpenZeppelin Forum","text":"SupportContracts\n\n erc20,bep20,solidity,truffle\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 3\n\n 2\n\n Jun 2021\n\n 5 / 5\n\n Jun 2021\n\n Jun 2021\n\n post by Komeil_Mirsamie on Jun 4, 2021\n\n Komeil_Mirsamie\n\n Hi, I'm a beginner at creating contracts, I've error when I deploy my contract with truffle and ganache-cli:\n\"Owo\" hit a require or revert statement somewhere in its constructor. Try:\n * Verifying that your constructor params satisfy all require conditions.\n * Adding reason strings to your require statements.\n\nthis is my constructor code:\n\n constructor (address payable charityWalletAddress) public {\n _charityWalletAddress = charityWalletAddress;\n _rOwned[_msgSender()] = _rTotal;\n\n IUniswapV2Router02 _uniswapV2Router = IUniswapV2Router02(0x10ED43C718714eb63d5aA57B78B54704E256024E);\n // pancakeswapv2 for BSC network\n // Create a uniswap pair for this new token\n uniswapV2Pair = IUniswapV2Factory(_uniswapV2Router.factory())\n .createPair(address(this), _uniswapV2Router.WETH());\n\n // set the rest of the contract variables\n uniswapV2Router = _uniswapV2Router;\n\n // Exclude owner and this contract from fee\n _isExcludedFromFee[owner()] = true;\n _isExcludedFromFee[address(this)] = true;\n\n emit Transfer(address(0), _msgSender(), _tTotal);\n }\n\n3_deploy.js\n\nconst Owo = artifacts.require(\"Owo\");\n\nmodule.exports = async function (deployer) {\n const accounts = await web3.eth.getAccounts()\n await deployer.deploy(Owo, accounts[0]);\n};\n\ncan anyone explain to me where is the problem with my code?\n\n 3\n\n 2\n\n post by Yoshiko on Jun 4, 2021\n\n Yoshiko\n\n Hi Komeil! Welcome to Open Zeppelin.\nLooking at your code\nIUniswapV2Router02 _uniswapV2Router = IUniswapV2Router02(0x10ED43C718714eb63d5aA57B78B54704E256024E);\nWhich network are you deploying to? If you are deploying to a test net, this router address needs to change. The router doesn't exist anywhere, but on BSC's live net.\nAs you mentioned you are new, I highly recommend doing this tutorial.\n\nYou don't have to understand it 100%, but it's a great way to get you up to speed and get a developer environment going.\nAfter that check out\n\nI know it's a pain to go through all this, but as you learn you will give yourself the skills needed to create any type of smart contract you want.\n\n post by Komeil_Mirsamie on Jun 5, 2021\n\n Komeil_Mirsamie\n\n how I can find my network address? I use rinkeby network.\nis there any possibility to test my token in PancakeSwap for adding liquidity and etc?\nbtw Thanks for your usefull information.\n\n post by Yoshiko on Jun 6, 2021\n\n Yoshiko\n\n Yes absolutely you can use https://pancake.kiemtienonline360.com/#/swap for testing with pancakeswap, the router address is 0x9Ac64Cc6e4415144C455BD8E4837Fea55603e5c3\nFor your network address, I’m a little confused at what you mean. Your wallet in metamask should remain the same. For network address you can find it with your API key if you are using Alchemy.\n\n post by Komeil_Mirsamie on Jun 7, 2021\n\n Komeil_Mirsamie\n\n Hi again and thanks for your response, I’ve another question How can I see the chart of my test token? Is there any website to show bsc testnet tokens chart?\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Truffle migrate error: “MyContract” hit a require or revert statement somewhere in its constructor\n\n Developer Wanted\n\n erc20,truffle\n\n 0\n\n 918\n\n Jul 2021\n\n Publish Uniswap to Ganache\n\n Contracts\n\n 0\n\n 1.0k\n\n Jun 2021\n\n Error on migration on truffle\n\n Smart Contracts\n\n etherscan-verify,solidity,truffle\n\n 3\n\n 1.6k\n\n Sep 2021\n\n Help! I don’t know whats wrong with my code but\n\n Contracts\n\n erc20\n\n 17\n\n 2.1k\n\n May 2021\n\n Problem about Create a uniswap pair in smart contract constructor!\n\n Smart Contracts\n\n 1\n\n 664\n\n Feb 2022","tokens":942,"squid":"ink-security_audits","role":"Sentinel","at":1791268397464,"hash":"0f5071e58a21941760cc5c3dc934b9ac5c0af838"}
{"url":"https://aave.com/blog/kraken-ink","domain":"aave.com","title":"How Ink and Kraken Use Aave | Aave","text":"Back to BlogHow Ink and Kraken Use AaveAave Labs•20 May, 2026PartnershipSuccess StoryThe launch of Tydro, the native lending protocol on Ink, the L2 released by Kraken, exemplifies how Aave's infrastructure enables rapid, secure, and trusted deployments. Aave’s architecture also is uniquely positioned to scale from zero to billions of dollars in liquidity, with a better liquidity profile per asset. In this case study we’ll take a look at how Ink leverages Aave’s infrastructure and how Kraken built on top of it using Kraken Earn.\nBackground\nInk is an Ethereum Layer 2 (L2) blockchain built by Kraken on Optimism’s Superchain using the OP Stack. Designed to bridge Kraken's millions of users to DeFi, Ink launched its mainnet at the end of 2024.\nThe Ink Foundation prioritized lending as a foundational primitive, recognizing it as an essential primitive for ecosystem growth. A robust lending protocol serves as a concentrated liquidity source, powering trading, structured products, yield strategies, protocol-native settlement, and composable financial applications. To deploy this quickly, securely, and cost-effectively, the Foundation chose a white-label instance of Aave V3, branded as Tydro.\nTydro launched in October 2025 as Ink’s native liquidity layer, a decentralized, non-custodial lending and borrowing protocol tightly integrated with the Ink ecosystem. Tydro is specifically curated for Ink, and features INK token incentives, a focused asset set, and planned connectivity to Kraken’s exchange products.\nLeveraging Aave's Infrastructure for Rapid, Secure Deployment\nRather than undertaking a ground-up implementation, Tydro achieved significant advantages by leveraging the Aave V3 codebase under a commercial agreement, with gains in efficiency, tooling, and security.\nAdvantages of Launching a Custom Lending Protocol, Powered by Aave\n\nTo support its launch, Aave’s risk managers have assisted with maintenance, risk management, and initial optimizations.\nThis approach created an immediate funnel for capital into Ink, with network activity surging post-Tydro launch.\nTydro Market Stats and Impact\nWithin its first four months, Tydro has shown strong growth and capital retention amid market volatility, serving as the flagship DeFi protocol for Kraken’s L2. At its peak, Tydro accumulated $600 million in total deposits with $350 million in TVL, comprising the vast majority of Ink’s total TVL.\n\nTydro's curated markets focus on high-utility assets aligned with Kraken's ecosystem including kBTC (Kraken Wrapped Bitcoin) and USDG (consortium-backed stablecoin involving Kraken). By prioritizing these, Tydro enhances Ink’s interoperability while fostering deeper ecosystem ties for Kraken-based tokens. Tydro has also gradually expanded into other categories including Ethena-related assets and staked ETH derivatives to enable strategies like leveraged staking or yield optimization with stablecoins.\nLarger Impact: Entrenching Kraken Users\nAccording to Ink, Tydro will “integrate into Kraken products, giving users seamless access to DeFi within the Kraken platform.” As Ink’s native liquidity layer, Tydro can serve as a foundation for Kraken structured products, protocol-native settlement, capital efficient trading, and composable financial apps.\nKraken’s vertical integration across the blockchain and app layer helps to entrench the exchange’s users by introducing onchain experiences to potentially first-time participants. Users can engage with Tydro and other Ink applications directly through the Kraken interface. This exemplifies a larger theme of Embedded DeFi experiences powered by Aave, where CeFi platforms embed DeFi primitives directly into their apps without having users manage complexities of wallets or bridges, lowering barriers and driving adoption.\nThe first major Tydro-based product offering came in January 2026 with the announcement of Kraken DeFi Earn, a product for users to earn yield on USDC holdings using Tydro and Aave on the back-end. Kraken users can select from three different vault options, each of which is administered by Veda. The product has seen strong early traction, recently surpassing $200M in onchain deposits.\n\nSource: https://dune.com/seoul/kraken-defi-earn\nFor Aave, this partnership scales the protocol by channeling CeFi liquidity into its markets, reinforcing Aave's role in 'CeDeFi' or hybrid finance. Aave can also power other embedded DeFi products including other stablecoin yield strategies, crypto-backed loans, or enhanced staking yields on crypto assets. For Kraken, this potentially could involve Kraken-related tokens for products like kBTC-backed loans or USDG-based stablecoin yield strategies.\nConclusion\nTydro's deployment on Ink exemplifies Aave's value in enabling secure, rapid DeFi launches for emerging ecosystems. From bootstrapping nearly $1 billion in deposits to powering embedded experiences like Kraken DeFi Earn, this case study shows Aave can be integrated across many user touchpoints, whether directly onchain or through embedded solutions, to drive adoption and innovation.\nThis also serves as a strong institutional endorsement of Aave. As embedded DeFi grows, Aave remains at the forefront, powering lend/borrow products for CeFi and fintech apps while helping them entrench their users deeper into their ecosystems. For those interested in building on proven infrastructure that doesn’t compromise safety or flexibility, just use Aave. Learn more about building on Aave’s proven infrastructure here.Need help or want to learn more?Share your questions or feedback and we'll get back to you.Name *Email *Your message *","tokens":1409,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268403078,"hash":"e025b626dec0fd80c305dd30be0a7cbdab78a52b"}
{"url":"https://forum.openzeppelin.com/t/truffle-migrate-error-mycontract-hit-a-require-or-revert-statement-somewhere-in-its-constructor/11990","domain":"forum.openzeppelin.com","title":"Truffle migrate error: \"MyContract\" hit a require or revert statement somewhere in its constructor - Smart Contracts / Developer Wanted - OpenZeppelin Forum","text":"Truffle migrate error: “MyContract” hit a require or revert statement somewhere in its constructor \n\n Smart ContractsDeveloper Wanted\n\n erc20,truffle\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Jul 2021\n\n 1 / 1\n\n Jul 2021\n\n Jul 2021\n\n post by lukeamelej on Jul 6, 2021\n\n lukeamelej\n\n Hi there!\nI’m new in this blockchain and smart contracts world!\nI had been reading and trying too much things from this forum and the internet but nothing help me…\nI get this error when running truffle migrate --reset\nError: *** Deployment Failed ***\n\n\"MyContract\" hit a require or revert statement somewhere in its constructor. Try:\n * Verifying that your constructor params satisfy all require conditions.\n * Adding reason strings to your require statements.\n\nHere is the repository with my code: https://github.com/lucasadlerstein/my_token_test\nI’m using ganache-cli, it seems to create the contract but there is an error also in the ganache terminal:\neth_sendTransaction\neth_getBlockByNumber\neth_getBlockByNumber\n\n Transaction: 0x67f630791af8f553f0deeb84d5d74bd3d503055a89818b980e124330033cea92\n Contract created: 0xb09bcc172050fbd4562da8b229cf3e45dc3045a6\n Gas usage: 1197955\n Block Number: 21\n Block Time: Tue Jul 06 2021 10:46:38 GMT-0300 (Argentina Standard Time)\n Runtime Error: revert\n\neth_call\n\nAlso, I don’t know exactly where I’m working… how can I found which testnet I’m working with?\n$ truffle version\nTruffle v5.3.14 (core: 5.3.14)\nSolidity - 0.8.4 (solc-js)\nNode v15.14.0\nWeb3.js v1.4.0\n\nThank you in advance,\nLucas\n\n Related topics\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Replies\n\n Views\n\n Activity\n\n Error on migration on truffle\n\n Smart Contracts\n\n etherscan-verify,solidity,truffle\n\n 3\n\n 1.6k\n\n Sep 2021\n\n Truffle migration ERC721 hit a require or revert statement somewhere in its constructor\n\n Smart Contracts\n\n 0\n\n 414\n\n May 2022\n\n Deployment failed using truffle for ERC20 token\n\n Contracts\n\n erc20\n\n 9\n\n 2.8k\n\n Nov 2019\n\n Smart contract deploy error\n\n Contracts\n\n erc20,bep20,solidity,truffle\n\n 4\n\n 2.8k\n\n Jun 2021\n\n “AdminUpgradeabilityProxy” hit a require or revert statement somewhere in its constructor\n\n Upgrades\n\n 2\n\n 1.1k\n\n Mar 2021","tokens":549,"squid":"ink-security_audits","role":"Sentinel","at":1791268407698,"hash":"61b1c1460a5bccdaa04d13868dc0ef88b2aeae71"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/registrar","domain":"docs.base.org","title":"Registrar - Base Documentation","text":"The registrar is an offchain service that maintains the signer set in\nTEEProverRegistry.\nIt discovers Base TEE prover instances, obtains an AWS Nitro attestation for each enclave signer,\ngenerates P-384 verification hints locally, caches the attestation certificate chain on L1, and\nsubmits the final signer registration.\nThis flow replaced the previous RISC Zero attestation proof and external Boundless proving path in\nCobalt; see Hinted Registration Migration.\nThere is no runtime backend selector or fallback to ZK verification. Registration requires the\nhinted-compatible registrar and prover-host signer API.\n​Responsibilities\nThe registrar discovers TEE prover instances, obtains and validates signer attestations, generates\nP-384 hints, caches certificates, and registers signers. It also deregisters orphaned signers and can\nmonitor AWS certificate revocation lists.\nThe registrar does not select the accepted enclave image. Registration records the attested PCR0,\nbut TEEVerifier\naccepts a signer only when its recorded image hash matches the active TEE_IMAGE_HASH. This allows\nthe next image’s signers to be registered before an image rotation without allowing them to produce\naccepted proofs early.\n​Architecture\n\nThe onchain validation stack contains three contracts:\nContractRoleP384VerifierVerifies P-384 signatures while checking caller-supplied modular inverse hints.CertManagerPins the AWS Nitro root, verifies and caches non-root certificates, and enforces certificate expiry and revocation.NitroValidatorParses the signed Nitro attestation, re-walks the cached certificate chain, and verifies the final COSE signature.\nTEEProverRegistry holds an immutable NitroValidator reference. The registrar discovers\nCertManager through TEEProverRegistry.NITRO_VALIDATOR() and NitroValidator.certManager();\noperators do not configure those addresses separately.\n​Driver Loop\nThe registrar runs one polling loop:\n\nQuery AWS ALB and EC2 for the current prover instances.\nProbe /readyz on every non-draining target. The load balancer’s /healthz is registration-gated,\nso it cannot be used to bootstrap registration.\nResolve signer public keys and attestations concurrently, bounded by max_concurrency.\nStart one registration task per eligible signer and cancel tasks whose signer is no longer eligible.\nRead the onchain signer set and deregister unprotected signers when discovery was conclusive.\nSleep for poll_interval, or stop on cancellation.\n\nOnly instances that pass /readyz are eligible for new registrations. Draining instances still\ncontribute their known signer addresses to the active set so a rotation does not immediately\nderegister them.\nWhen an instance disappears or becomes unhealthy, the registrar preserves its last-known signers\nfor instance_cache_ttl_cycles. It skips the entire orphan pass while any instance remains\nunresolved. Pending registration tasks are also protected from orphan cleanup.\nDiscovery supports AWS ELBv2 target groups whose targets are EC2 instances. Targets whose IDs do\nnot start with i- are ignored. AWS API errors and missing EC2 data abort the tick and skip orphan\ncleanup, but an empty target group is a conclusive result. The last-known-signer cache is in memory\nand starts empty after a process restart. Operators must therefore configure and monitor the target\ngroup carefully: a cold registrar pointed at an empty target group has no cached signers to protect.\n​Attestation Challenge\nEach signer receives a deterministic 32-byte nonce:\nAttestation Noncekeccak256(\n \"base-proof-tee-registrar:attestation-nonce:v1\" ||\n teeProverRegistryAddress ||\n signerAddress\n)\n\nThe registrar requests one attestation per signer with that nonce. It rejects the response unless:\n\nthe attested public_key derives to the expected signer address;\nthe attested nonce exactly matches the deterministic challenge;\nPCR0 is present, is 48 bytes, and is not the all-zero debug-mode measurement;\nthe certificate chain starts at the pinned AWS Nitro root;\nthe certificate chain is ordered parent-first and ends in one leaf certificate; and\nthe attestation remains within the configured local freshness window.\n\nThe deterministic challenge binds the attestation to one registry and signer without requiring\nregistrar state across restarts. TEEProverRegistry independently enforces timestamp freshness,\nbut nonce matching is a registrar policy check because NitroValidator only exposes the signed\nnonce to its caller.\n​Registration Plan\nThe registrar preserves the exact protected-header and payload encodings from the input\nCOSE_Sign1 document when constructing the signed Sig_structure. Re-encoding signed CBOR would\nchange the message and invalidate the AWS signature.\nFor parity with the pinned NitroValidator, the registrar accepts an optional compact 0xD2 tag\nfollowed by the compact 0x84 COSE_Sign1 array, the ES384 protected header 0x44a1013822, a\n96-byte P-384 signature, and no trailing COSE or TBS data. The payload, pcrs, and cabundle\ncontainers may use definite or indefinite lengths. Unknown payload keys are skipped, but recognized\nkeys must be unique.\nThe parsed plan contains:\n\nthe signer derived from the 65-byte 0x04 || x || y secp256k1 public key;\nPCR0, timestamp, and nonce;\nthe pinned root certificate;\nnon-root CA certificates followed by the leaf certificate;\nthe exact attestation to-be-signed bytes and 96-byte P-384 signature; and\ncache and revocation identifiers matching CertManager.\n\nThe pinned root cache key is keccak256(root DER). Every non-root cache key is\nkeccak256(TBSCertificate DER), excluding the malleable outer ECDSA signature. Non-root revocation\nuses keccak256(issuerHash || serialHash). issuerHash hashes the issuer Name content octets,\nexcluding its DER tag and length. serialHash hashes the serial INTEGER content octets, including a\nleading 0x00 used for DER sign extension. These identities remain stable across equivalent outer\ncertificate encodings.\n​P-384 Hints\nAWS signs Nitro certificates and attestations with ECDSA over P-384. P-384 verification requires\nmany modular inversions, which are expensive to compute in the EVM. The registrar computes each\ninverse offchain and supplies it as a hint.\nFor every division by b modulo a prime m, the contract checks:\nInverse Checkb * hint == 1 (mod m)\n\nThe hint is used only after this equality holds. Since an invertible value has one inverse modulo a\nprime, a passing hint is the same value the contract would have computed. Incorrect, truncated, or\nsurplus hints revert. Hints affect liveness, not correctness: a faulty generator can prevent a\nregistration but cannot make an invalid signature pass.\nEach hint stream is a concatenation of 48-byte big-endian inverses in the verifier’s deterministic\nconsumption order. The registrar generates one stream for every non-root certificate signature and\none for the final attestation signature. Production hint generation is native Rust and does not\ninvoke Node, Go, or an external proving service.\n​Certificate Cache\nCertManager stores the pinned AWS Nitro root at deployment. The registrar processes every\nremaining certificate in parent-first order:\n\nRead the candidate’s cached metadata and revocation state.\nIf cached, require the expected CA or leaf role, an unexpired validity period, the original\nparent binding, and a complete unrevoked path to the pinned root.\nIf not cached, call verifyCACertWithHints() or verifyClientCertWithHints() with the DER\ncertificate, parent cache key, and signature hints.\nRe-read state after the transaction. A transaction error is treated as success if the expected\nusable cache entry is now present.\n\nCache writes are permissionless because all certificate data and hints are verified onchain.\nPer-certificate locks prevent concurrent signer tasks from submitting duplicate cache transactions\nfor a shared chain. On restart or after a partial failure, the registrar reads the cache again and\ncontinues from the first missing certificate.\nFor a typical Nitro chain with three non-root CAs, transaction counts are:\nCache stateTransactionsEmpty5: three CA cache writes, one leaf cache write, one registrationCA chain cached, new leaf2: one leaf cache write, one registrationCA chain and leaf cached1: registration only\nEach signature verification is split into its own transaction so it remains below the EIP-7825\nper-transaction gas limit. Final registration intentionally supplies no certificate hints;\nNitroValidator succeeds only if the complete chain is already cached and usable.\n​Final Registration\nAfter the cache is ready, the registrar calls:\nRegistration CallTEEProverRegistry.registerSigner(attestationTbs, signature, hints)\n\nThe registry permits only its owner or manager to call this method. It delegates cryptographic and\ncertificate validation to NitroValidator, then applies Base-specific policy:\n\nReject attestations at least 60 minutes old.\nReject attestations whose second-level timestamp is greater than or equal to block.timestamp.\nRequire PCR0 at index zero, exactly 48 bytes, and not the debug-mode measurement.\nRequire a 65-byte uncompressed secp256k1 public key.\nDerive the signer as the last 20 bytes of keccak256(x || y).\nStore the signer as registered and record keccak256(PCR0) as its image hash.\n\nThe registrar uses a 3,300-second default local freshness limit, leaving submission headroom under\nthe registry’s 3,600-second limit. It checks freshness before every certificate, revocation, and\nregistration transaction so a multi-transaction cold flow stops before submitting stale material.\nBefore each registration attempt, and after ambiguous transaction errors, the registrar reads\nisRegisteredSigner(signer). An observed registration is treated as success. Retryable transaction\nerrors use bounded exponential backoff; reverted receipts and non-retryable errors fail the current\ntask.\n​Certificate Revocation\nCertManager maintains a durable revocation set and an immutable pinned AWS Nitro root. The owner\ncan revoke the root to halt new registrations, unrevoke the root, set the non-root revoker, and\nunrevoke certificate identities. The revoker role can revoke non-root issuer/serial identities.\nRevocation is checked during cold verification, cache reuse, and the final cached-chain walk.\nCertificate revocation and expiration do not invalidate previously registered signers. Deregister\naffected signers separately.\nFor every registration attempt, the registrar checks the pinned root and every planned certificate\nagainst CertManager.isRevoked(). A confirmed onchain revocation rejects the registration.\nWhen CRL fetching is additionally enabled, the registrar:\n\nFetches CRLs only from allowlisted AWS Nitro hosts, without redirects and with a 10 MiB response\nlimit.\nMatches intermediate certificate serial numbers against the CRLs.\nCalls CertManager.revokeCert() for confirmed revocations before rejecting the registration.\n\nCRL fetch and parse failures are fail-open and retried on later cycles. Confirmed onchain\nrevocations always fail closed.\n​Orphan Deregistration\nAfter registration task reconciliation, the registrar computes:\nOrphan Formulaorphans = registered signers - active signers - pending signers\n\nIt calls deregisterSigner() for each orphan only when discovery completed without unresolved\ninstances and the configured last-known-signer grace period has expired. Deregistration removes the\nregistered flag and stored image hash. This flow assumes one registrar controls a given registry;\nindependent registrars would otherwise classify each other’s signers as orphans.\n​Hinted Registration Migration\nCobalt replaced ZK-proved signer registration with the hinted flow\ndescribed on this page.\nBefore Cobalt, the registrar sent each Nitro attestation to an external proving service (Boundless\nor a self-hosted RISC Zero prover). That service produced a RISC Zero proof that the attestation\nand its AWS certificate chain were valid, and the registrar submitted the proof to\nTEEProverRegistry. This added an external availability dependency and could delay new signer\nregistration while the proof was generated. The hinted flow verifies the attestation directly on\nL1, so registration is faster and no longer depends on an offchain proving service.\nThe migration upgraded the existing TEEProverRegistry proxy implementation. It preserved the\nproxy storage layout, owner, manager, game type, proposers, registered signers, and stored signer\nimage hashes. The active registrar and registry support only the new three-argument hinted API.\nThe migration did not change:\n\nNitro enclave signer generation or attestation production;\nPCR0-based image selection in TEEVerifier or the TEE_IMAGE_HASH it checks;\nAggregateVerifier behavior;\nTEE proposal and dispute proof formats; or\nSP1 state-proof behavior.\n\n​Operator Inputs\nA registrar requires:\n\nan L1 RPC endpoint and TEEProverRegistry address;\nAWS region and ALB target group ARN;\nthe prover JSON-RPC port;\nan L1 transaction signer and transaction-manager limits;\nattestation freshness, polling, timeout, concurrency, cache-grace, and retry settings; and\nhealth, logging, and Prometheus metrics settings.\n\nNo Boundless wallet, marketplace endpoint, RISC Zero program identifier, guest ELF, or proof-backend\nselection is used. CRL monitoring is optional and requires the registrar transaction signer to hold\nthe configured CertManager revoker role. In the current CLI,\n--crl-nitro-verifier-address or BASE_REGISTRAR_CRL_NITRO_VERIFIER_ADDRESS enables CRL fetching.\nThis legacy-named value is only an enable flag; contract discovery still follows the registry to\nNitroValidator and then CertManager.\n​Safety Requirements\nA conforming implementation must preserve these properties:\n\nPreserve the exact signed COSE encodings when constructing the attestation TBS.\nMatch the attested signer and deterministic nonce before any transaction is submitted.\nPin the AWS Nitro root and reject malformed, expired, revoked, or parent-mismatched chains.\nGenerate hints in the exact verifier order and rely on onchain checks for every supplied inverse.\nCache certificates parent-first and recover by reading onchain state after every ambiguous result.\nRecheck freshness before each costly transaction in a cold registration.\nRecheck registration state before submission and after ambiguous transaction errors.\nDo not deregister signers while discovery is unresolved or during the configured grace period.\nKeep PCR0 acceptance at proof-submission time so image rotations can be staged safely.\nWas this page helpful?Suggest editsRaise issue","tokens":3632,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268408528,"hash":"399e41bac7a9cd4cc052f32dc7c97e179bbb77f8"}
{"url":"https://aave.com/blog","domain":"aave.com","title":"Blog | Aave","text":"Coinbase Tokenized Stocks Now Live on Aave V4Seven Coinbase Tokenized Stocks can now be supplied as collateral to borrow USDC on Aave V4 on Base.Recent PostsHow Accounts Work on Aave AppAave App accounts keep users fully self-custodial while signing up as easily as any top-tier fintech. Here is how the Signer and the Smart Account work under the hood.ProductIntroducing the Aave MCP ServerOne connection that lets any AI assistant read live Aave data and build V3 and V4 transactions your own wallet signs.ProductIntroducing Aave App Ghost PassesA limited group of Aave App users are receiving Ghost Passes, invites that grant a friend immediate access by skipping the waitlist entirely.ProductNewsAI-Assisted Security Review of Aave V3 & V4Three AI security tools were run against Aave V3 and V4. Across 71 findings, no Critical or High severity issue was confirmed in either protocol.ResearchSecurityAave V4 Launches on AvalancheAave V4 goes live on Avalanche, its first multi-chain deployment, with a Core Liquidity Hub powering a Main, AVAX Correlated, and Forex market.ProductWhy Chainlink CCIP Secures Aave Protocol and the Aave AppChainlink CCIP is the cross-chain standard securing the Aave Protocol and Aave App, powering GHO transfers, multi-chain governance, and Stable Vaults on infrastructure Aave already trusts.ResearchSecurityIntroducing Stable VaultsAn all-in-one way for any business to embed predictable-rate stablecoin yield into its product without building yield infrastructure from scratch.ProductRebuilding securities finance on Aave V4How Aave V4's Hub and Spoke architecture can move the multi-trillion-dollar securities finance market onchain.ResearchUnlimited Lending Market StructuresHow lending market structures organize liquidity, collateral, and risk onchain, and the flexible designs Aave V4's Hub and Spoke architecture unlocks.ResearchHow Aave Powers Whop TreasuryWhop's new Treasury feature lets 21 million+ online businesses earn up to 6% APY on their balances through Aave's lending market on Plasma.ProductAave and MetaMask Bring DeFi to Traditional Payments with MastercardAave, MetaMask, and Mastercard have teamed up to let users spend yield-bearing crypto assets at any Mastercard-accepted location while continuing to earn DeFi returns.ProductHow Ink and Kraken Use AaveHow Kraken's Ink L2 built Tydro on Aave V3 to power native lending and embedded DeFi for millions of users.Case StudiesAave Labs Achieves SOC 2 Type II Attestation Across Security, Availability, and ConfidentialityAave Labs development and operational controls have been independently verified to meet a consistent standard of rigor.NewsSecurityAave V4 is Live on EthereumAave V4 launches on Ethereum mainnet with its Hub and Spoke architecture, unified liquidity, and three initial Liquidity Hubs.NewsAave Pro User GuideA complete guide to using Aave Pro, the dedicated interface for Aave V4's Hub and Spoke architecture.ProductAave Powers Yield for Whop's 21M+ UsersWhop Treasury brings Aave-powered yield to 21 million online business owners.NewsAave V4's Reinvestment ModuleAave V4's Reinvestment Module puts idle protocol liquidity to work, boosting yields and growing DAO revenue.ResearchSecurity by Design: Aave V4 Governance Security UpdateHow Aave V4 achieved zero high-severity findings across 345 days of security review, formal verification, and a 900-participant public contest.NewsSecurityHow Aave App Reimagines the DeFi ExperienceCan a user tell if a financial app is powered by a blockchain or not? Introducing the Fintech Test and how Aave App passes it.ProductHow Aave Horizon is Built to Support InstitutionsHow Aave Horizon's architecture supports permissioned assets, shared liquidity, and institutional-grade compliance.ProductHow Aave Liquidations Perform Under Volatile ConditionsA data-driven look at Aave's $4.6 billion in historical liquidations, demonstrating the protocol's resilience across multiple market cycles and stress events.ResearchSecurityCapCap integrates Aave to deploy idle stablecoin reserves and benchmark yield rates, growing to one of Aave's largest USDC depositors with over $360M supplied.Case StudiesIntegrationAave is Infrastructure for Scaling StablecoinsAave provides stablecoin issuers with the strongest pathway for scaling their assets to billions in liquidity.ResearchAave 2025 Year in ReviewA look back at Aave's record-breaking 2025.NewsKraken Launches DeFi Earn, Powered by AaveKraken, one of the oldest and largest cryptocurrency exchanges, now offers its users access to DeFi yields through a new product called DeFi Earn, powered by Aave.NewsHow Aave V4 Handles Risk Isolation Without Fragmenting LiquidityAave V4's Hub and Spoke architecture enables granular risk segregation while maintaining unified liquidity across markets.ResearchArbitrumAave has solidified its role as a cornerstone of Arbitrum's ecosystem, establishing the chain as the premier \"home of DeFi.\"Case StudiesIntegrationAave V4's New Liquidation EngineHow Aave V4’s liquidation engine improves efficiency and incentives over V3.ProductTangemHow Tangem uses Aave to Power Non-Custodial Yield.Case StudiesIntegrationHow Aave is Powering Latin America's Stablecoin RevolutionAave is bringing real yield, credit, and capital efficiency to the hundreds of millions of Latin Americans embracing stablecoins.ResearchAave Labs Partners with CoW SwapAave Labs has entered into a strategic partnership with CoW Swap, the leading DEX aggregator and pioneer of intent-based trading.NewsAave V4 Public Testnet and Code ReleaseAave V4 testnet is now live with public code review and Aave Pro developer preview available for testing.NewsIntroducing Aave App: A Smarter Way to SaveAave App offers higher rates with real-time compounding and flexible withdrawals.ProductNewsKinexys by J.P. MorganHow Aave protocol was adapted for institutional needs as part of the Project Guardian initiative led by the Monetary Authority of Singapore.Case StudiesIntegrationLidoLido's liquid staking combines forces with Aave to power DeFi's ETH yield engine.Case StudiesIntegrationPush by Aave Labs Gains MiCAR Approval to Enable Zero Fee Stablecoin OnrampingAave Labs subsidiary Push Virtual Assets Ireland Limited has secured MiCAR authorisation from the Central Bank of Ireland, enabling regulated, zero-fee stablecoin on and off-ramping for GHO and other stablecoins across the EEA.NewsWhy DeFi Rates will Overtake TradFiHow Fed policy shifts affect DeFi markets and why Aave is uniquely positioned in the current monetary easing cycle.AnalysisAave Horizon Supports VanEck's Tokenized Treasury Fund VBILLThe Aave Horizon RWA market integrates VanEck's VBILL as productive collateral for institutional lending.NewsAave Labs Acquires Stable FinanceAave Labs expands its consumer-focused DeFi strategy.NewsAave V4 and the Unified Liquidity ThesisHow Aave V4's Hub and Spoke architecture addresses DeFi liquidity fragmentation through unified liquidity hubs.NewsBlockdaemonHow Blockdaemon Uses Aave to Power Institutional Access to Onchain Yield.Case StudiesIntegrationHow V4 Turns Aave Into DeFi's Operating SystemBootstrapping new markets with Aave V4's Hub and Spoke Architecture.ResearchDeFi for FintechsHow Aave Is Powering Embedded DeFi for Fintechs.ResearchBTCSHow Nasdaq-listed BTCS Uses Aave to Finance its Digital Asset Treasury (DAT) Strategy.Case StudiesIntegrationCrypto-backed LoansA Smarter Way to Borrow and Access Wealth.ResearchGalaxyInstitutional Liquidity in Practice.Case StudiesIntegrationEthenaEthena’s Ascent to $10bn, Powered by the Aave Liquidity Engine.Case StudiesIntegrationAave Horizon LaunchesAave Labs launched Aave Horizon, a new lending market on Ethereum for RWAs.ProductAave V3 Launches on AptosAave V3 launches on Aptos marking the first non EVM deployment of the protocolProductBenchmark Rates in Finance and Aave’s Emergence as a DeFi StandardAave's market-leading scale and deep liquidity provide a reliable foundation.ProductMetaMaskMetaMask selected Aave as its DeFi lending partner to power Stablecoin Earn, a feature that lets users earn yield directly inside their wallet.Case StudiesIntegrationAave Powers MetaMask's Stablecoin Earn ProductMetaMask users can now earn yield on their stablecoins directly inside their MetaMask mobile wallets.ProductAave V4 Risk PremiumsRisk-based borrowing comes to Aave. How V4 uses risk premiums for smarter lending.ProductAvalancheAvalanche uses Aave to securely access decentralized capital markets.Case StudiesIntegrationUnderstanding Aave V4’s ArchitectureAave V4's new Hub and Spoke architecture unifies liquidity and enables specialized markets.Product","tokens":2165,"squid":"ink-defi_protocols","role":"Liquidity Diver","at":1791268413033,"hash":"13347d18300cf3a7374966ddb1db821bf30cc362"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/tee-prover","domain":"docs.base.org","title":"TEE Prover - Base Documentation","text":"The TEE prover is an offchain service that produces signed proof material for AggregateVerifier\ngames by re-deriving and re-executing an L2 block range inside an AWS Nitro Enclave. The same\nservice backs both proposal creation and dispute nullification: callers (proposer or challenger)\nsubmit a block range, the host collects witness data, the enclave verifies the range, and a randomly-generated key\nheld only inside the enclave signs the resulting journal.\nThe signature is self-validating onchain. TEEVerifier recovers the signer from each proposal and\nchecks it against TEEProverRegistry for the active game implementation’s TEE_IMAGE_HASH. A\nsigner from a different enclave image, or one that is no longer registered, cannot satisfy\nverification. The Nitro hypervisor’s per-instance attestation binds the signer’s public key to a\nspecific PCR0, which the registrar certifies separately.\n​Responsibilities\nA conforming TEE prover stack performs the following work:\n\nServe prover_prove for proposal and dispute ranges over JSON-RPC.\nCollect witness data from canonical L1, L1 beacon, and L2 RPCs on the host.\nForward content-verified preimages to the enclave over vsock.\nInside the enclave, re-derive and re-execute the L2 range and validate the claimed output root\nagainst the re-executed one before signing anything.\nSign per-block journals and an aggregate journal with a secp256k1 key generated inside the\nenclave.\nExpose enclave_signerPublicKey and enclave_signerAttestation for the registrar.\nOptionally gate every request on registry signer validity to fail closed against deregistered\nenclaves.\nSupport multi-enclave deployment on a single EC2 parent so different PCR0 images can run\nside-by-side across rotations.\n\nThe TEE prover does not decide whether a proposal or dispute is correct. It re-executes the range,\nsigns the result if the re-execution matches the claim, and returns. Callers still recheck game\nstate before submitting onchain.\n​Architecture\nThe service runs as two processes on a Nitro-capable EC2 parent:\n\nA host binary (base-prover-nitro-host) that terminates JSON-RPC, collects witness data over\nHTTP, and proxies requests to one or more enclaves.\nAn enclave binary (base-prover-nitro-enclave) packed into an EIF that holds the signing key,\nexposes a vsock listener, and runs the proof pipeline.\n\nThe two processes communicate only over vsock. The enclave has no network interface; all external\nRPC connectivity is on the host side.\n\nEach vsock connection serves one request and then closes. The enclave holds no per-request state\nbetween connections; the only persistent state inside the enclave is the signer key and the\nboot-time PCR0 measurement.\nVsock frames are length-prefixed (u32 big-endian length + bincode payload) with a 5-minute read\ntimeout. The transport caps write chunks at 28 KiB to avoid a Linux kernel virtio_vsock SKB\ncorruption bug.\n​JSON-RPC Interface\nThe host exposes two namespaces on a single HTTP JSON-RPC listener, plus an HTTP GET /healthz\nproxy that routes to the JSON-RPC healthz method.\nMethodPurposeprover_proveProduce per-block and aggregate signed proposals for a block range.enclave_signerPublicKeyReturn the 65-byte uncompressed secp256k1 public key for each enclave.enclave_signerAttestationReturn the COSE_Sign1 attestation document for each enclave.healthz / GET /healthzLiveness, plus optional onchain signer validity (latching) when enabled.\nThe enclave_* calls are all-or-nothing across multiple enclaves: if any transport fails or any\nenclave returns an error, the entire response fails. Callers register every signer together, so a\npartial response would be unusable.\n​prover_prove Request\nProofRequest fields:\nFieldMeaningl1_headL1 head block hash anchoring the derivation window.l1_head_numberL1 head block number.agreed_l2_head_hashL2 block hash at the parent of the range.agreed_l2_output_rootOutput root at the parent. Used as the starting state.claimed_l2_output_rootClaimed output root at the target. Trust-critical: the enclave only signs if re-execution matches it.claimed_l2_block_numberTarget L2 block number (ending block of the range).proposerL1 address that will submit the proof. Committed into the journal so onchain msg.sender must match.intermediate_block_intervalSampling stride for intermediate roots in the aggregate proposal.image_hashkeccak256(PCR0) the caller expects. Currently informational; routing uses onchain signer validity.\n​prover_prove Response\nProofResult::Tee contains:\nFieldMeaningaggregate_proposalOne Proposal covering the full range with sampled intermediate roots.proposalsPer-block Proposals in order, each chaining prev_output_root to the previous block’s root.\nEach Proposal:\nFieldMeaningoutput_rootOutput root at this proposal’s ending block.signature65-byte secp256k1 ECDSA signature (`rsv) over keccak256(journal)`.l1_origin_hashL1 head hash used during derivation.l1_origin_numberL1 head block number.l2_block_numberEnding L2 block number for this proposal.prev_output_rootOutput root before this proposal’s range.config_hashPer-chain config hash hardcoded into the enclave.\nWhen the range contains exactly one block, the aggregate proposal is identical to the single\nper-block proposal. Otherwise the aggregate carries its own signature over a journal whose\nprev_output_root is the request’s agreed_l2_output_root, whose intermediate_roots are\nsampled at intermediate_block_interval, and whose ending_l2_block is the last block in the\nrange.\n​enclave_signerAttestation\nenclave_signerAttestation(user_data, nonces) takes two optional arguments:\nArgumentTypeuser_dataOption<Vec<u8>>noncesOption<Vec<Vec<u8>>>\nThe host includes the same user_data in every attestation and assigns nonces in\nenclave_signerPublicKey order.\nIf supplied, nonces must contain exactly as many entries as there are configured enclaves. If\nomitted, no nonce is sent to any enclave. The NSM limit is 512 bytes for user_data and 512 bytes\nfor each nonce. The host rejects a wrong nonce count or oversized input with JSON-RPC error\n-32602 before any vsock call.\nThe host returns one raw COSE_Sign1 document per configured enclave in that same order. The\nregistrar supplies a deterministic challenge per signer\nto bind each attestation to the expected registry and signer before submitting it onchain.\n​Proof Pipeline\nA single prover_prove request flows host → vsock → enclave → host:\n\nHost: ProverService::prove_block constructs a Host from the prover config, then calls\nHost::build_witness to walk L1 EL, L1 beacon, and L2 EL and populate an Oracle with\nhash-keyed preimages.\nHost: NitroBackend::prove flattens the oracle into (PreimageKey, Vec<u8>) pairs and\nNitroTransport::prove sends them over vsock as one EnclaveRequest::Prove(...) frame.\nEnclave: Oracle::new content-verifies every Keccak256- or Sha256-keyed preimage so the\nstored value actually hashes to its key.\nEnclave: BootInfo::load extracts the proposer, L1 head, agreed/claimed roots,\nintermediate-block interval, and chain ID from local preimages.\nEnclave: config_hash_for_chain looks up a hardcoded per-chain config hash from\nCONFIG_HASHES (computed at first access from ChainConfig::all()). Unknown chain IDs return\nUnsupportedChain and refuse to prove.\nEnclave: the proof prologue drives derivation and execution via\ndriver.execute_with_intermediates(). The epilogue’s validate() is the trust-critical gate:\nit confirms the re-executed final output root matches the claimed_l2_output_root from the\nrequest. Signing only happens after this check passes.\nEnclave: for each block result, build a ProofJournal with empty intermediate_roots and\nsign it; chain prev_output_root through the loop. Then build and sign the aggregate journal\nwith sampled intermediate roots.\nEnclave: return EnclaveResponse::Prove(ProofResult::Tee { aggregate_proposal, proposals }).\nHost: return the result to the JSON-RPC caller, applying the configured proof request\ntimeout (default 1740 s, ~29 minutes).\n\nThe proposer consumes both the aggregate and per-block proposals: per-block roots feed\nproposeOutputRoots and the aggregate signature satisfies AggregateVerifier. The challenger\nuses only the aggregate signature, repacking it for nullify() via\nProofEncoder::encode_dispute_proof_bytes. The enclave neither knows nor cares which caller it is\nserving.\n​Signed Journal\nEach signature is computed as secp256k1.sign(keccak256(journal)) and serialized as 65 bytes\n(r || s || v). The journal is packed (not ABI-encoded), 196 + 32·N bytes where N is the\nnumber of intermediate roots:\nSigned Journal Layoutproposer(20) || l1OriginHash(32) || prevOutputRoot(32)\nstartingL2Block(8) || outputRoot(32) || endingL2Block(8)\nintermediateRoots(32 × N) || configHash(32)\nteeImageHash(32)\n\nPer-block proposals have N == 0 and startingL2Block == endingL2Block - 1. Aggregate proposals\nhave startingL2Block == firstBlock - 1, endingL2Block == lastBlock, and N == lastBlock / intermediate_block_interval.\nteeImageHash is keccak256(PCR0) taken at enclave boot. It is embedded in every journal so a\nsignature recovered onchain transitively commits to the exact EIF measurement that produced it. In\nlocal mode (no NSM, development and test only), teeImageHash is zero.\nThe signature v byte is encoded as the secp256k1 recovery id (0 or 1); callers normalize it\nto the EIP-155 form they need before L1 submission.\n​Multi-Enclave Routing\n--vsock-cid accepts one or more CIDs, so a single host process can attach to multiple enclaves\nrunning on the same EC2 parent. Each CID is an independent vsock endpoint that can run a different\nEIF — a different PCR0, a different tee_image_hash, and a different registered signer.\nThe CLI requires --tee-prover-registry-address whenever more than one CID is configured. Without\nthe registry there is no way to choose between enclaves deterministically, so multi-enclave\ndeployments are fail-closed-only.\nPer-request routing iterates configured CIDs in order and picks the first enclave whose signer is\ncurrently valid in TEEProverRegistry:\n\nFetch the signer public key from the enclave (skip the transport if this fails).\nCall isValidSigner(signer) on TEEProverRegistry.\nIf valid, route the request to this enclave. If not, log and continue.\nIf no enclave in the list has a valid signer, fail the request with NoValidSigner.\n\nThe common operational use is image rotation. Run the old and new EIFs side-by-side; both signers\nare registered for the active game implementation’s TEE_IMAGE_HASH during the overlap window;\nafter the registry switches to the new image hash only the new enclave’s signer is valid, and all\nnew requests route to it.\nenclave_* calls fan out to every configured enclave so the registrar can register every signer\nin one cycle.\n​Registration Gating and Health\nWhen --tee-prover-registry-address is set, the host enables two registry-backed behaviors:\n\nGET /healthz returns healthy only after at least one enclave’s signer has been confirmed valid\nonchain. The health flag latches: once an enclave has been seen valid, /healthz continues to\nreport healthy even if the registry RPC later fails or the signer is deregistered. This keeps\nload balancers stable across short outages.\nEvery prover_prove request consults RegistrationChecker::select_valid_enclave before\nforwarding. A deregistered enclave, or one whose key fetch fails, is skipped. If no enclave is\nvalid the request is rejected with JSON-RPC error code -32001.\n\nWithout the registry flag, the host is permissive: /healthz returns healthy as long as the\nserver is running, and prover_prove routes to the first configured enclave.\n​Attestation\nThe signer key is generated inside the enclave at startup and never leaves the enclave process.\nThe Server::new_enclave constructor:\n\nOpens an NSM session (nsm_init).\nReads PCR0 (48-byte SHA-384). Wrong length aborts startup.\nComputes tee_image_hash = keccak256(PCR0) and stores it for inclusion in every signed journal.\nGenerates a secp256k1 ECDSA key with NsmRng, which calls\nnsm_process_request(Request::GetRandom).\nLogs the signer address (no key material).\n\nThere is no startup or periodic attestation. Attestations are produced only when the registrar\ncalls enclave_signerAttestation. Each call:\n\nOpens a fresh NSM session.\nCalls nsm_process_request(Request::Attestation { public_key, user_data, nonce }).\nReturns the raw COSE_Sign1 bytes.\n\nThe attestation document embeds the 65-byte uncompressed public key, all populated PCRs, the\nAWS-issued certificate chain, the timestamp, and the supplied user_data/nonce, all signed by\nthe per-instance Nitro hypervisor key. Only PCR0 is consumed by this system — it is the value\nbound into every signed journal via teeImageHash = keccak256(PCR0). See the\nregistrar spec for how attestations are verified and submitted onchain.\n​Service Lifecycle\nThe host startup sequence (ServerArgs::run):\n\nParse CLI; initialize logging and metrics via base_cli_utils.\nResolve the RollupConfig and L1 chain config from --l2-chain-id. Fail on unknown chains.\nBuild one NitroTransport::vsock(cid, 8000) per --vsock-cid.\nConstruct NitroProverServer::new_multi(prover_config, transports, timeout) and, if\n--tee-prover-registry-address is set, wrap with RegistrationHealthConfig.\nBuild a jsonrpsee HTTP server with a /healthz proxy layer, merge ProverApiServer,\nEnclaveApiServer, and one of the healthz modules, and start the server.\nBlock on the server handle; exit on ctrl-C.\n\nThe enclave startup sequence (NitroEnclave::new):\n\nServer::new() opens NSM, derives tee_image_hash, and generates the signer key.\nBind a VsockListener on VMADDR_CID_ANY:8000.\nFor each connection, spawn a handler that reads one framed EnclaveRequest, dispatches to\nServer::prove, signer_public_key, or signer_attestation, writes the response, and closes\nthe connection.\n\nPer-request flow on the host:\n\n(Optional) select_valid_enclave chooses a registered enclave.\ntokio::time::timeout(proof_request_timeout, enclave.service.prove_block(request)).\nOn timeout, return JSON-RPC -32000 with the offending L2 block number.\nOn error from the enclave, return JSON-RPC -32000 with the underlying error message.\n\nShutdown is driven by ctrl-C handled by RuntimeManager. The jsonrpsee server stops, in-flight\nrequests drain, and the runtime exits. The enclave has no graceful shutdown path; process\ntermination drops NSM file descriptors via Drop.\n​Operator Inputs\nA TEE prover host needs:\n\nL1 execution RPC URL.\nL1 beacon RPC URL.\nL2 execution RPC URL.\nL2 chain ID (used to select the rollup config and per-chain config hash).\nJSON-RPC listen address.\nOne or more vsock CIDs, each backed by a Nitro Enclave running the prover EIF.\nProof request timeout (default 1740 seconds).\nLogging filter and Prometheus metrics settings.\n\nOptional:\n\nTEEProverRegistry address. Required when more than one vsock CID is configured. Enables\nregistration-gated health and per-request signer validation.\nExperimental witness endpoint flag for hosts that expose debug_executePayload.\n\nThe enclave needs no operator inputs beyond the EIF image and the vsock channel. PCR0 is read at\nboot from NSM; the signer key is generated from the hardware RNG.\n​Safety Requirements\nA TEE prover implementation must preserve these safety properties:\n\nGenerate the signing key inside the enclave from the NSM hardware RNG and never serialize it out\nof the enclave process.\nValidate the re-executed final output root against the request’s claimed_l2_output_root before\nany signing, and refuse to sign if the check fails.\nEmbed tee_image_hash = keccak256(PCR0) in every signed journal so signatures bind to one EIF\nmeasurement.\nContent-verify every hash-keyed preimage as it enters the enclave so derivation cannot consume\npreimages whose values do not match their keys.\nRefuse to prove for chain IDs not present in the hardcoded CONFIG_HASHES table.\nCap user_data and nonce at the NSM 512-byte limit at the host RPC boundary so oversize\nattestation requests cannot reach the enclave.\nServe at most one request per vsock connection and keep no mutable state between requests so a\nmalformed request cannot influence a later one.\nWhen --tee-prover-registry-address is configured, fail closed on per-request signer validity\nand reject the request if no configured enclave’s signer is currently valid onchain.\nWas this page helpful?Suggest editsRaise issue","tokens":4074,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268430452,"hash":"f744c75f44341beff738d4cfe332444e1eac3786"}
{"url":"https://blog.ethereum.org/2026/10/01/introducing-zkapi","domain":"blog.ethereum.org","title":"Introducing zkAPI: private usage credits for any API | Ethereum Foundation Blog","text":"Introducing zkAPI: private usage credits for any APIPosted by Vittorio Rivabella, dAI Team on October 1, 2026Research & Developmenttl;dr: zkAPI lets you pay for a metered API without being known. Deposit credits into an Ethereum vault once, then authorize bounded usage with zero-knowledge proofs instead of an identity. The provider sees the requests, and the payment layer sees the spend. Neither learns the link between them.\nThe Open Anonymity Project built it with the Ethereum Foundation, and it runs on Ethereum Mainnet today.\nThe problem\nEvery AI API call today carries an identity. Your API key points to an account, the account to a payment method, and every prompt you send joins the record attached to both. The provider can connect years of your usage into a single profile.\nPrompts are personal. People ask AI models about their health, their finances, their doubts. Under the current model, using AI means handing a running transcript of your thinking to whoever holds the billing relationship. The alternatives were poor: pay per request onchain, which is slow, expensive, and traceable by anyone, or trust a middleman not to look.\nThe idea\nzkAPI separates payment from identity. You deposit credits (ETH, USDC, etc.) into a vault contract on Ethereum, one ordinary transaction. From then on, your balance exists as a private note: digital cash that only you can spend and that nobody can trace back to the deposit.\nTo authorize spending, software on your machine produces a small zero-knowledge proof that says, in effect, that a funded note covers this spend and nobody has spent it before. One proof can cover a single request or a whole session. The server can check that the statement is true without learning which note, which deposit, or which person. At the payment layer, requests do not link to you, and they do not link to each other.\nTwo pieces of cryptography make this safe as well as private. Deposits live as commitments in a Merkle tree, so a proof can show “my note is one of the valid ones” without pointing at any particular one. Every spend publishes a nullifier, a one-way serial number derived from the note's secret. A user who stays within their balance stays unlinkable. A user who tries to spend the same balance twice produces a duplicate nullifier, which exposes the attempt and nothing else.\nHow it works\n\nThe payment path (steps 1 to 3) and the conversation path (step 4) share two objects: the short-lived key and its usage receipt.\nThe server that handles money never sees content, and the provider that sees content never learns the billing identity behind a key.\nYour app talks to a small client running on your own device. Nothing about the app changes. It speaks the same API it always did.The client sends the zkAPI server a proof of payment, with no prompt and no identity attached.The server checks the proof and mints a fresh API key on the spot, short-lived and capped in dollars. The key exists only in your device's memory.Your prompts go straight from your device to the AI provider with that key. When the key expires, the server charges your private balance for the metered usage rather than the reserved cap.\nThe spending cap works as a reservation. When the key expires, the provider side records the key's total usage in a signed receipt, and the server deducts that amount from your note. Neither side can rewrite the bill afterward, and one authorization covers a whole session of requests rather than one proof per call.\nzkAPI also ships a simpler proxy mode, where the zkAPI server relays requests to the provider itself. It is easier to operate, but the relay sees traffic. The runtime-key mode above exists so that no payment intermediary ever does.\nzkAPI proves spends with Groth16 on the BN254 curve, hashes commitments and nullifiers with Poseidon, and keeps notes in a Merkle tree 32 levels deep. The server verifies spend proofs off-chain. The vault contract verifies the same kind of proof at deposit, close, and escape, so your exit never depends on the server’s honesty.\nIn practice\n\nPartyLearnsNever learnszkAPI servera valid payment exists, and total dollars per sessionwho you are, what you asked, which deposit paidAI providerprompts and responses, since it runs the modelwho is payingEthereum (public)deposits, closes, withdrawalswhat any balance paid for\n\nYour funds stay yours: The vault is a contract on Ethereum rather than a company account: you can close your balance and withdraw onchain, even if every zkAPI server disappears.\n\nYour tools stay the same: The client exposes the standard OpenAI and Ollama APIs on your own machine. Existing apps, editors, and chat clients work by pointing them at localhost.\n\nUse cases\nAI inference comes first because prompts are sensitive and the billing trail ties each one to you. The same client and contracts can front any service that charges per use:\n\nUse caseMetered unitWhat the payment layer hidesAI chat and agentsmodel callswhich note paid, and any billing link between sessionsBlockchain RPCquerieswhich funding source paid for the queriesImage and video generationjobswho paid for which jobsVPNs and bandwidthtime and datawho paid for the connectionMachine-to-machine servicesper-task spendagents pay without an account\nzkAPI hides the payment link. A provider still sees what a request contains and network metadata such as your IP address, and it can try to correlate sessions by timing. Network anonymity and content privacy are separate layers: a VPN or Tor handles the network side, and confidential GPU computing is emerging for content.\nFor providers, integrating means accepting a proof instead of an API key and settling signed usage receipts instead of maintaining accounts. Pricing, rate limits, and infrastructure stay as they are.\nLimitations\nzkAPI’s protections have two limitations: the lack of network anonymity, and privacy leakage via prompt contents.\nOn the network side, the main issue is that the gateway can potentially correlate request patterns from a user if they send requests to zkAPI under a stable user IP address. Users seeking stronger privacy may route requests through Tor and use a fresh circuit for each session.\nOn the content side, individual sessions may be re-linked by the inference provider if the same personal details, writing style, reused conversation history, or project documents are presented. Shared prompt contents can act as fingerprints for anyone who can read the prompts. This is a privacy-utility tradeoff: standalone queries are more private but less useful since past context is missing. One mitigation is to leverage local or TEE models to generate requests on top of shared memory instead of the user manually writing them. See also discussions in the Open Anonymity project post.\nBackground and links\nzkAPI is the working implementation of ZK API usage credits, a design published on Ethereum Research by Davide Crapis and Vitalik Buterin.\nThe Open Anonymity team helped turn that design into the client, the server, and the contracts you can run today.\nzkAPI is live on Ethereum mainnet today. Try it:\nzkAPI GitHub Repository: the local client, server, and browser SDKZkApiVault on Ethereum mainnet: the live vault, holding USDC creditsSepolia test deployment: the same contracts with test fundsOA Chat: private AI chat in the browser, no install\nOr build the local gateway and point any OpenAI-compatible app at it using the docs.","tokens":1858,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268440007,"hash":"8edb221582d10a62cf27f6fb69434c76bc5fe525"}
{"url":"https://docs.base.org/specifications/base-protocol/proofs/proposer","domain":"docs.base.org","title":"Proposer - Base Documentation","text":"The proposer is an offchain service that turns canonical L2 checkpoint ranges into\nAggregateVerifier games on L1. It selects the next checkpoint from the latest onchain parent\nstate, obtains a TEE proof for that range, validates the proof against canonical L2 state, and\ncreates the next dispute game through DisputeGameFactory.\nThe production proposer is controlled by its configured L1 transaction signer. Its output is still\nself-validating: each game is uniquely identified by the game type, claimed output root, parent,\nL2 block number, and intermediate output roots, and the proof can be checked by the onchain verifier\nand by independent challengers.\n​Responsibilities\nA conforming proposer performs the following work:\n\nRead the active AggregateVerifier implementation and proposal parameters from L1.\nRecover the latest onchain parent state from AnchorStateRegistry and DisputeGameFactory.\nSelect the next checkpoint block that is no later than the chosen safe head.\nBuild a prover_prove request for the checkpoint range.\nAccept only TEE proof results for proposal creation.\nRevalidate the aggregate output root and all intermediate roots against canonical L2 state\nimmediately before L1 submission.\nOptionally pre-check the TEE signer against TEEProverRegistry.\nSubmit DisputeGameFactory.createWithInitData() with the required bond.\nRetry transient proof, RPC, and transaction failures without creating out-of-order games.\n\nThe proposer does not challenge games, resolve games, claim bonds, or decide withdrawal finality.\nThose responsibilities belong to the challenger and proof contracts.\n​Startup Configuration\nAt startup, the proposer connects to:\n\nan L1 execution RPC for contract reads and transaction submission\nan L2 execution RPC for agreed L2 block headers\na rollup RPC for sync status and output roots\na prover RPC that implements prover_prove\nAnchorStateRegistry\nDisputeGameFactory\nan optional TEEProverRegistry\n\nThe proposer reads the game implementation address from:\nGame Implementation LookupDisputeGameFactory.gameImpls(gameType)\n\nThe implementation address must be non-zero. The proposer then reads:\nStartup ReadsAggregateVerifier.BLOCK_INTERVAL()\nAggregateVerifier.INTERMEDIATE_BLOCK_INTERVAL()\nDisputeGameFactory.initBonds(gameType)\n\nBLOCK_INTERVAL must be at least 2, INTERMEDIATE_BLOCK_INTERVAL must be non-zero, and\nBLOCK_INTERVAL % INTERMEDIATE_BLOCK_INTERVAL must be 0. The number of intermediate roots in a\nproposal is:\nIntermediate Root CountBLOCK_INTERVAL / INTERMEDIATE_BLOCK_INTERVAL\n\nThe proposer defaults to finalized L2 state. If explicitly configured to allow non-finalized\nproposals, it may use the rollup node’s safe L2 state instead.\n​Parent Recovery\nThe proposer recovers the latest onchain parent state from L1 before planning new work. The parent\nstate is:\nParent State FieldsparentAddress\nparentOutputRoot\nparentL2BlockNumber\n\nIf no matching games exist, the parent is the anchor root from AnchorStateRegistry:\nAnchor Parent StateparentAddress = AnchorStateRegistry address\nparentOutputRoot = AnchorStateRegistry.getAnchorRoot().root\nparentL2BlockNumber = AnchorStateRegistry.getAnchorRoot().l2BlockNumber\n\nIf games exist, the proposer performs a deterministic forward walk from the anchor root, or from a\ncached recovered tip when the cache is still valid. At each step:\n\nCompute:\nexpectedBlock = parentL2BlockNumber + BLOCK_INTERVAL\n\nFetch the canonical output root for every intermediate checkpoint:\nparentL2BlockNumber + INTERMEDIATE_BLOCK_INTERVAL * i\n\nfor i in 1..=BLOCK_INTERVAL / INTERMEDIATE_BLOCK_INTERVAL.\n\nTreat the final intermediate root as the canonical root claim for expectedBlock.\n\nEncode extraData from expectedBlock, parentAddress, and the ordered intermediate roots.\n\nLook up the expected game:\nDisputeGameFactory.games(gameType, rootClaim, extraData)\n\nIf the lookup returns address(0), stop. The current parent is the latest recovered state.\n\nOtherwise, advance the parent to the returned game proxy and continue.\n\nThis recovery method does not scan factory indices for a “best” game. It uses the game’s unique\nfactory key, so only the canonical next game for the recovered parent can advance the chain of\nparents. A game with the wrong root, parent, L2 block number, or intermediate roots has a different\nkey and is ignored by parent recovery.\n​Checkpoint Selection\nAfter recovery, the next proposal target is:\nTarget Block FormulatargetBlock = parentL2BlockNumber + BLOCK_INTERVAL\n\nThe proposer must not request or submit a proof for targetBlock unless:\nSafe Head ConstrainttargetBlock <= safeHead\n\nwhere safeHead is either:\n\nfinalized_l2.number, by default\nsafe_l2.number, only when non-finalized proposals are explicitly enabled\n\nWhen parallel proving is enabled, the proposer may request proofs for multiple future checkpoint\ntargets, but L1 submissions remain strictly sequential. At most one proposal transaction is in\nflight, and the next transaction is not submitted until all earlier checkpoint games are recovered\nor confirmed.\n​Proof Request\nFor a checkpoint range, the proposer builds a ProofRequest with:\nFieldValuel1_headHash of the latest L1 block at request construction timel1_head_numberNumber of the latest L1 block at request construction timeagreed_l2_head_hashL2 block hash at parentL2BlockNumberagreed_l2_output_rootParent output root recovered from L1claimed_l2_output_rootRollup RPC output root at targetBlockclaimed_l2_block_numbertargetBlockproposerL1 address that will submit the proposal transactionintermediate_block_intervalINTERMEDIATE_BLOCK_INTERVALimage_hashExpected TEE image hash\nThe prover RPC method is:\nProver RPC Methodprover_prove(ProofRequest) -> ProofResult\n\nThe proposer accepts ProofResult::Tee for proposal creation. A ZK proof result is not valid input\nfor the current proposer path.\n​TEE Proposal Journal\nThe TEE prover returns:\n\nan aggregate proposal for the full checkpoint range\nper-block proposals for the blocks in that range\n\nThe aggregate proposal contains:\nAggregate Proposal FieldsoutputRoot\nsignature\nl1OriginHash\nl1OriginNumber\nl2BlockNumber\nprevOutputRoot\nconfigHash\n\nThe TEE signature is over:\nTEE Signature Preimagekeccak256(journal)\n\nwhere journal is packed as:\nJournal Packingproposer(20)\n|| l1OriginHash(32)\n|| prevOutputRoot(32)\n|| startingL2Block(8)\n|| outputRoot(32)\n|| endingL2Block(8)\n|| intermediateRoots(32 * N)\n|| configHash(32)\n|| teeImageHash(32)\n\nFor aggregate proposals:\nAggregate Proposal ValuesstartingL2Block = parentL2BlockNumber\nendingL2Block = targetBlock\nprevOutputRoot = parentOutputRoot\noutputRoot = claimed root at targetBlock\n\nThe ordered intermediateRoots are sampled every INTERMEDIATE_BLOCK_INTERVAL blocks and include\nthe final target block root.\n​Pre-Submission Validation\nImmediately before submitting to L1, the proposer must re-check the proof against canonical L2\nstate:\n\nFetch the rollup output root at targetBlock.\nRequire it to equal the aggregate proposal’s outputRoot.\nExtract the intermediate roots from the per-block proposals.\nFetch the canonical output root for each intermediate checkpoint.\nRequire every proposed intermediate root to equal its canonical root.\n\nIf the aggregate root or any intermediate root no longer matches canonical state, the proposer\ndiscards the pending work and restarts recovery. This protects against stale proof results after L1\nor L2 reorgs.\nWhen TEEProverRegistry is configured, the proposer should recover the TEE signer from the\naggregate proposal signature and call:\nSigner Validity CheckTEEProverRegistry.isValidSigner(signer)\n\nIf the registry returns false, the proposer must not submit that proof. It should discard the\nproof and request a new one. If the registry check itself fails because of an RPC or deployment\nissue, the proposer may continue to submission and rely on the onchain verifier to enforce signer\nvalidity.\n​Game Creation\nThe proposer creates a game with:\nGame Creation CallDisputeGameFactory.createWithInitData{value: initBond}(\n gameType,\n rootClaim,\n extraData,\n initData\n)\n\nwhere:\nRoot ClaimrootClaim = aggregateProposal.outputRoot\n\nextraData is packed, not ABI-encoded:\nExtra Data Packingl2BlockNumber(32) || parentAddress(20) || intermediateRoots(32 * N)\n\nl2BlockNumber is encoded as a 32-byte big-endian integer. parentAddress is the recovered parent\ngame proxy address, or the AnchorStateRegistry address for the first game after the anchor.\ninitData is the TEE proof bytes for AggregateVerifier.initializeWithInitData():\nInit Data PackingproofType(1) || l1OriginHash(32) || l1OriginNumber(32) || signature(65)\n\nFor TEE proofs:\nTEE Proof TypeproofType = 0\n\nThe ECDSA v value in the signature must be normalized to 27 or 28 before submission.\ninitBond is read from DisputeGameFactory.initBonds(gameType) at startup and is sent as the\ntransaction value. Nonce management, fee bumping, signing, and transaction resubmission are handled\nby the L1 transaction manager.\n​Duplicate Games\nThe factory key for a game is:\nFactory Game KeygameType || rootClaim || extraData\n\nIf createWithInitData() reverts with GameAlreadyExists, the proposer treats the target as\nalready submitted. It refreshes recovery from L1 and continues from the recovered tip. This handles\nthe case where a previous transaction succeeded but the proposer did not observe the receipt, or\nwhere another valid proposer submitted the same game first.\n​Retry Behavior\nThe proposer retries transient failures on later ticks:\nFailureRequired behaviorRecovery RPC or contract read failureSkip the current tick and retry recovery on the next tickProof request failureRetry the target on a later tickRepeated proof failureReset pipeline state and recover from L1L1 submission failureKeep the proved result and retry submission on a later tickL1 submission timeoutTreat as a submission failure and retry after recoveryGameAlreadyExistsTreat as success, refresh recovery, and continueCanonical root mismatchReset pipeline state and re-prove from recovered L1 stateInvalid TEE signerDiscard the proof and request a new one\nThe current implementation retries a single proof target up to three times before resetting pipeline\nstate. Proposal submission is bounded by a ten minute timeout.\n​Admin Interface\nThe proposer may expose an optional JSON-RPC admin interface. When enabled, it provides:\nMethodResultadmin_startProposerStarts the proving pipelineadmin_stopProposerStops the proving pipelineadmin_proposerRunningReturns whether the pipeline is running\nStarting an already running proposer and stopping a stopped proposer are errors.\n​Dry Run Mode\nIn dry run mode, the proposer performs recovery, checkpoint selection, proof sourcing, and\npre-submission validation, but it does not submit L1 transactions. Instead, it logs the game that\nwould have been created.\nDry run mode is useful for validating prover and RPC behavior, but it does not advance the onchain\nproposal chain.Was this page helpful?Suggest editsRaise issue","tokens":2730,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268440374,"hash":"f1e42c3046b162678f506a609e5d1c52bf9cf02b"}
{"url":"https://ethresear.ch/t/faq-ethereum-issuance-reduction/19675/4","domain":"ethresear.ch","title":"FAQ: Ethereum issuance reduction - Proof-of-Stake / Economics - Ethereum Research","text":"Proof-of-StakeEconomics\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 2\n\n read \n\n 34\n min\n\n May 2024\n\n 4 / 4\n\n Aug 17\n\n Aug 17\n\n post by aelowsson on May 29, 2024\n\n 1 month later\n\n post by Keccak255 on Jul 6, 2024\n\n 12 days later\n\n post by aelowsson on Jul 18, 2024\n\n aelowsson\n\n Thanks!\n\nYes. The exact shape of the supply curve is and will remain unknown. New EIPs can also lead the supply curve to shift (for example, if these EIPs make staking easier or harder, riskier or less risky, etc.), but this is not the focus when discussing issuance policy. We primarily have control of the demand curve, specifically the reward curve if we do not institute MEV burn, and more specifically F𝐹 if no other adjustments to the reward curve are made. However, note that the current direction is to alter the reward curve more substantially, adding other terms to the equation, such as division by the term (1+D/k)(1 +𝐷/𝑘).\n\nYes, exactly. As argued in the answer on the endgame, we are seeking to define an optimal path through a set of hypothetical supply curves. Each hypothetical supply curve (both low and high) has one optimal equilibrium, and the reward curve should intersect each hypothetical supply curve close to this point (weighted based on probability). The reward curve should thus optimize all known trade-offs associated with high/low yield and stake participation (long-run and short-run economic security, low costs, a viable composition of the staking set, reward variability, trustless money, low dilution, etc.).\n\n 2 years later\n\n post by sandakersmann on Aug 17\n\n sandakersmann\n\n Great read! This is one of the most thorough posts on issuance policy I’ve seen. The macro argument about LSTs potentially becoming “too big to fail” for the social layer deserves more attention. It connects issuance policy to the “don’t overload consensus” thesis in a way that feels underexplored elsewhere. Thanks for putting this together \nDue to network effects of money, we want to disincentivize staking over a certain total amount to avoid an LST becoming de facto money on Ethereum. Changing the issuance curve is part of the solution. The risk-free rate of Ethereum is the burn – not the staking yield.\n\n Powered by Discourse","tokens":562,"squid":"ink-research","role":"Deep Scholar","at":1791268442375,"hash":"4812ee20bb10fded2c49c84886d358d42221fbaa"}
{"url":"https://bbp-form.ethereum.org/","domain":"bbp-form.ethereum.org","title":"Ethereum Bug Bounty Report","text":"Loading application configuration...\n\n Burn transaction invalidates in\n --:--\n\n Make sure your report is ready\n\n Only continue if you are confident the issue is in scope of the bug bounty\n program, is at least low severity, and has a clear proof of\n concept — preferably a Kurtosis-based one.\n\n Have a voucher code?\n\n If a previous report was closed as a duplicate, you were emailed a single-use\n voucher. Enter it to waive the submission fee.\n\n Voucher code\n\n Select wallet\n\n No injected wallet detected. Install a browser wallet that supports Ethereum transactions.\n\n Manual transaction details\n\n Use these values with another wallet, then paste the resulting transaction hash\n below.\n\n Chain ID\n\n To\n\n Value (ETH)\n\n Value (wei)\n\n Value (hex)\n\n Hex data\n\n Transaction hash\n\n Submission reference\n\n Burn transaction\n\n Voucher redeemed","tokens":209,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268455261,"hash":"a122417a1cafab1911a2be775fb8a7fa5c416bcb"}
{"url":"https://docs.base.org/specifications/base-protocol/bridging/withdrawals","domain":"docs.base.org","title":"Withdrawals - Base Documentation","text":"A canonical withdrawal is a cross-domain transaction initiated on Base and finalized on Ethereum. Canonical withdrawals can transfer ETH, bridge supported ERC-20 tokens, or send a message from Base to an L1 contract. The flow has three stages:\n\nInitiate on Base: the withdrawal transaction is sent on Base. This records the withdrawal message in the L2ToL1MessagePasser contract.\nProve on Ethereum: after the relevant Base state has been posted to Ethereum, anyone can submit a proof to the OptimismPortal contract showing that the withdrawal message exists on Base.\nFinalize on Ethereum: after the finalization window has passed, anyone can finalize the withdrawal on Ethereum. Finalization releases the assets or relays the message to the target contract.\n\nCanonical withdrawals to Ethereum can be finalized only after the dispute game for the output root they are proven against has passed its finalization window. Since the Beryl upgrade, that window is 5 days for a single-proof dispute game and 1 day on the dual-proof fast path, when both a TEE proof and a ZK proof back the same proposal. The window gives network participants time to dispute an invalid output root before withdrawals that depend on it can be finalized.Most of the total time from initiating a withdrawal on Base to receiving funds on Ethereum is the finalization window. Waiting for the relevant Base state to be proposed on Ethereum usually adds only about 20 to 60 minutes, plus the time to submit the prove and finalize transactions. See Transaction Finality for how withdrawal finality differs from ordinary Base transaction finality.\nSome third-party bridge providers offer faster withdrawals by using liquidity, relayers, or market makers to give users funds before the canonical withdrawal has fully finalized. These services do not shorten the protocol’s canonical finalization window. See Bridge to Base for available routes.\n​Overview\nWithdrawals are cross domain transactions which are initiated on L2, and finalized by a transaction\nexecuted on L1. Notably, withdrawals may be used by an L2 account to call an L1 contract, or to transfer ETH from\nan L2 account to an L1 account.\nVocabulary note: withdrawal can refer to the transaction at various stages of the process, but we introduce\nmore specific terms to differentiate:\n\nA withdrawal initiating transaction refers specifically to a transaction on L2 sent to the Withdrawals predeploy.\nA withdrawal proving transaction refers specifically to an L1 transaction\nwhich proves the withdrawal is correct (that it has been included in a merkle\ntree whose root is committed to by a dispute game on L1).\nA withdrawal finalizing transaction refers specifically to an L1 transaction which finalizes and relays the\nwithdrawal.\n\nWithdrawals are initiated on L2 via a call to the Message Passer predeploy contract, which records the important\nproperties of the message in its storage.\nWithdrawals are proven on L1 via a call to the OptimismPortal, which proves the inclusion of this withdrawal message.\nWithdrawals are finalized on L1 via a call to the OptimismPortal contract,\nwhich verifies that the proof maturity delay has passed since the withdrawal was proven and that the\ndispute game it was proven against is now a valid claim.\nIn this way, withdrawals are different from deposits which make use of a special transaction type in the\nexecution engine client. Rather, withdrawals transaction must use smart contracts on L1 for\nfinalization.\n​Withdrawal Flow\nWe first describe the end to end flow of initiating and finalizing a withdrawal:\n​On L2\nAn L2 account sends a withdrawal message (and possibly also ETH) to the L2ToL1MessagePasser predeploy contract.\nThis is a very simple contract that stores the hash of the withdrawal data.\n​On L1\n\nA relayer submits a withdrawal proving transaction with the required inputs\nto the OptimismPortal contract.\nThe relayer is not necessarily the same entity which initiated the withdrawal on L2.\nThese inputs include the withdrawal transaction data, inclusion proofs, and the index of a dispute game in the\nDisputeGameFactory. The game’s root claim is an L2 output root that commits to the withdrawal as registered\non L2. On Base, these games are AggregateVerifier games.\nThe OptimismPortal contract looks up the game in the DisputeGameFactory and checks through the\nAnchorStateRegistry that the game is proper and of the respected game type, and that it has not resolved in\nfavor of a challenger. It then verifies the output root proof against the game’s root claim and the withdrawal’s\ninclusion in the L2ToL1MessagePasser storage root.\nIf proof verification fails, the call reverts. Otherwise the game and the proof timestamp are recorded for the\nproof submitter. A withdrawal can be re-proven, for example against a different game if the first one is\ninvalidated; re-proving resets that submitter’s proof timestamp.\nThe dispute game runs its finalization window: 5 days for a single-proof game, or 1 day when both TEE and ZK\nproofs back the proposal (see Beryl). During this window,\na challenger can dispute an invalid root claim.\nOnce the game’s claim is valid and the proof maturity delay has passed, a relayer submits a withdrawal\nfinalizing transaction to the OptimismPortal contract.\nThe relayer doesn’t need to be the same entity that initiated the withdrawal on L2.\nThe OptimismPortal contract receives the withdrawal transaction data and verifies that the withdrawal has\nbeen proven, that at least proofMaturityDelaySeconds have passed since it was proven, and that\nAnchorStateRegistry.isGameClaimValid() returns true for the game it was proven against.\nIf the requirements are not met, the call reverts. Otherwise the call is forwarded, and the hash is recorded to\nprevent it from being replayed.\n\n​The L2ToL1MessagePasser Contract\nA withdrawal is initiated by calling the L2ToL1MessagePasser contract’s initiateWithdrawal function.\nThe L2ToL1MessagePasser is a simple predeploy contract at 0x4200000000000000000000000000000000000016\nwhich stores messages to be withdrawn.\nL2ToL1MessagePasser.solinterface L2ToL1MessagePasser {\n event MessagePassed(\n uint256 indexed nonce, // this is a global nonce value for all withdrawal messages\n address indexed sender,\n address indexed target,\n uint256 value,\n uint256 gasLimit,\n bytes data,\n bytes32 withdrawalHash\n );\n\n event WithdrawerBalanceBurnt(uint256 indexed amount);\n\n function burn() external;\n\n function initiateWithdrawal(address _target, uint256 _gasLimit, bytes memory _data) payable external;\n\n function messageNonce() public view returns (uint256);\n\n function sentMessages(bytes32) view external returns (bool);\n}\n\nThe MessagePassed event includes all of the data that is hashed and\nstored in the sentMessages mapping, as well as the hash itself.\n​Addresses Are Not Aliased on Withdrawals\nWhen a contract makes a deposit, the sender’s address is aliased. The same is not true\nof withdrawals, which do not modify the sender’s address. The difference is that:\n\non L2, the deposit sender’s address is returned by the CALLER opcode, meaning a contract cannot easily tell if the\ncall originated on L1 or L2, whereas\non L1, the withdrawal sender’s address is accessed by calling the l2Sender() function on the OptimismPortal\ncontract.\n\nCalling l2Sender() removes any ambiguity about which domain the call originated from. Still, developers will need to\nrecognize that having the same address does not imply that a contract on L2 will behave the same as a contract on L1.\n​The Optimism Portal Contract\nThe Optimism Portal serves as both the entry and exit point to the Base L2. It is a contract which inherits from\nthe OptimismPortal contract, and in addition provides the following interface for\nwithdrawals:\n\nWithdrawalTransaction type\nOutputRootProof type\n\nOptimismPortal.solinterface OptimismPortal2 {\n\n event WithdrawalProven(bytes32 indexed withdrawalHash, address indexed from, address indexed to);\n\n event WithdrawalProvenExtension1(bytes32 indexed withdrawalHash, address indexed proofSubmitter);\n\n event WithdrawalFinalized(bytes32 indexed withdrawalHash, bool success);\n\n function l2Sender() external view returns (address);\n\n function proofMaturityDelaySeconds() external view returns (uint256);\n\n function proveWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx,\n uint256 _disputeGameIndex,\n Types.OutputRootProof calldata _outputRootProof,\n bytes[] calldata _withdrawalProof\n ) external;\n\n function finalizeWithdrawalTransaction(\n Types.WithdrawalTransaction memory _tx\n ) external;\n\n function finalizeWithdrawalTransactionExternalProof(\n Types.WithdrawalTransaction memory _tx,\n address _proofSubmitter\n ) external;\n\n function checkWithdrawal(bytes32 _withdrawalHash, address _proofSubmitter) external view;\n}\n\n​Withdrawal Verification and Finalization\nThe following inputs are required to prove and finalize a withdrawal:\n\nWithdrawal transaction data:\n\nnonce: Nonce for the provided message.\nsender: Message sender address on L2.\ntarget: Target address on L1.\nvalue: ETH to send to the target.\ndata: Data to send to the target.\ngasLimit: Gas to be forwarded to the target.\n\nProof and verification data:\n\ndisputeGameIndex: The index in the DisputeGameFactory of the dispute game whose root claim is the applicable output root.\noutputRootProof: Four bytes32 values which are used to derive the output root.\nwithdrawalProof: An inclusion proof for the given withdrawal in the L2ToL1MessagePasser contract.\n\nTo prove a withdrawal, these inputs must satisfy the following conditions:\n\nThe game at disputeGameIndex is proper and respected according to the AnchorStateRegistry, and has not\nresolved with CHALLENGER_WINS.\nThe keccak256 hash of the outputRootProof values is equal to the game’s root claim.\nThe withdrawalProof is a valid inclusion proof demonstrating that a hash of the Withdrawal transaction data\nis contained in the storage of the L2ToL1MessagePasser contract on L2.\n\nTo finalize a withdrawal, the following conditions must also hold:\n\nThe withdrawal has been proven by the proof submitter and has not already been finalized.\nMore than proofMaturityDelaySeconds have passed since the withdrawal was proven.\nAnchorStateRegistry.isGameClaimValid() returns true for the game the withdrawal was proven against. This\nrequires the game to have resolved with DEFENDER_WINS after its finalization window.\n\n​Security Considerations\n​Key Properties of Withdrawal Verification\n\nIt should not be possible to ‘double spend’ a withdrawal, ie. to relay a withdrawal on L1 which does not\ncorrespond to a message initiated on L2. For reference, see this writeup of a vulnerability\nof this type found on Polygon.\n\nFor each withdrawal initiated on L2 (i.e. with a unique messageNonce()), the following properties must hold:\n\nIt should only be possible to prove the withdrawal once, unless the outputRoot for the withdrawal\nhas changed.\nIt should only be possible to finalize the withdrawal once.\nIt should not be possible to relay the message with any of its fields modified, ie.\n\nModifying the sender field would enable a ‘spoofing’ attack.\nModifying the target, data, or value fields would enable an attacker to dangerously change the\nintended outcome of the withdrawal.\nModifying the gasLimit could make the cost of relaying too high, or allow the relayer to cause execution\nto fail (out of gas) in the target.\n\n​Handling Successfully Verified Messages That Fail When Relayed\nIf the execution of the relayed call fails in the target contract, it is unfortunately not possible to determine\nwhether or not it was ‘supposed’ to fail, and whether or not it should be ‘replayable’. For this reason, and to\nminimize complexity, we have not provided any replay functionality, this may be implemented in external utility\ncontracts if desired.\n​OptimismPortal Can Send Arbitrary Messages on L1\nThe L2ToL1MessagePasser contract’s initiateWithdrawal function accepts a _target address and _data bytes,\nwhich is passed to a CALL opcode on L1 when finalizeWithdrawalTransaction is called after the withdrawal\nbecomes finalizable. This means that, by design, the OptimismPortal contract can be used to send arbitrary transactions on\nthe L1, with the OptimismPortal as the msg.sender.\nThis means users of the OptimismPortal contract should be careful what permissions they grant to the portal.\nFor example, any ERC20 tokens mistakenly sent to the OptimismPortal contract are essentially lost, as they can\nbe claimed by anybody that pre-approves transfers of this token out of the portal, using the L2 to initiate the\napproval and the L1 to prove and finalize the approval (after the finalization window).Was this page helpful?Suggest editsRaise issue","tokens":3173,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268455330,"hash":"319dfcaa9fbbda2124eced3aa0e695a748a12b0e"}
{"url":"https://ethresear.ch/c/proof-of-stake/caspers-economic-incentive-structures/11","domain":"ethresear.ch","title":"Latest Proof-of-Stake/Economics topics - Ethereum Research","text":"Latest topics in Economics\n\n Proof-of-Stake\n\n Economics\n\n tags\n\n Latest\n\n Top\n\n Topic list, column headers with buttons are sortable.\n\n Topic\n\n Posters\n\n About the Economics category\n\n 0\n\n 1.6k\n\n Oct 2017\n\n Timing the Head in Ethereum PoS\n\n 2\n\n 246\n\n Sep 1\n\n Properties of issuance offsets and increased penalties under low/zero/negative issuance policies\n\n issuance-policy\n\n 1\n\n 505\n\n Aug 19\n\n FAQ: Ethereum issuance reduction\n\n 3\n\n 7.3k\n\n Aug 17\n\n A Protocol Design View on Statelessness\n\n stateless\n\n 7\n\n 1.2k\n\n Apr 16\n\n Decoupling throughput from local building\n\n protocol-research-call\n\n 13\n\n 2.6k\n\n May 2025\n\n Endgame Staking Economics: A Case for Targeting\n\n 36\n\n 16.5k\n\n Apr 2025\n\n Paths to SSF revisited\n\n protocol-research-call\n\n 0\n\n 1.2k\n\n Mar 2025\n\n Consolidation incentives in Orbit/Vorbit SSF\n\n single-slot-finality,consensus-incentives,validator-consolidation\n\n 0\n\n 480\n\n Mar 2025\n\n Rainbow roles & incentives: ABPS + FOCILR + AS\n\n proposer-builder-separation,inclusion-lists\n\n 0\n\n 775\n\n Feb 2025\n\n Pricing Transactions for Preconfirmation\n\n mev,preconfirmations,layer-2\n\n 2\n\n 597\n\n Feb 2025\n\n Proposers do play dice: Introducing random Execution Auctions (randEAs)\n\n 0\n\n 518\n\n Nov 2024\n\n Practical endgame on issuance policy\n\n 15\n\n 2.2k\n\n Nov 2024\n\n Trusted Advantage in Slot Auction ePBS\n\n mev\n\n 2\n\n 720\n\n Sep 2024\n\n Preconfirmations under the NO lens\n\n mev,preconfirmations\n\n 5\n\n 3.3k\n\n Sep 2024\n\n Economic Analysis of Execution Tickets\n\n mev\n\n 5\n\n 4.3k\n\n Aug 2024\n\n Maximum Viable Security: A New Framing for Ethereum Issuance\n\n 4\n\n 5.8k\n\n Aug 2024\n\n Orbit SSF: solo-staking-friendly validator set management for SSF\n\n single-slot-finality\n\n 3\n\n 7.6k\n\n Jul 2024\n\n Burn incentives in MEV pricing auctions\n\n 0\n\n 6.1k\n\n Jun 2024\n\n Reward curve with tempered issuance: EIP research post\n\n 3\n\n 7.3k\n\n May 2024\n\n Execution Tickets\n\n mev\n\n 10\n\n 14.7k\n\n May 2024\n\n Preventing restaking centralization risks\n\n 4\n\n 3.5k\n\n Apr 2024\n\n Blob Preconfirmations with Inclusion Lists to Mitigate Blob Contention and Censorship\n\n mev,layer-2,censorship-resistance\n\n 14\n\n 3.1k\n\n Apr 2024\n\n Blue shell strategy - discouraging the most concentrated actor as an optimal path\n\n 0\n\n 1.5k\n\n Apr 2024\n\n Initial Analysis of Stake Distribution\n\n 12\n\n 3.5k\n\n Mar 2024\n\n Unbundling staking: Towards rainbow staking\n\n censorship-resistance,single-slot-finality\n\n 11\n\n 13.7k\n\n Mar 2024\n\n How (optional, non-KYC) validator metadata can improve staking decentralization\n\n 3\n\n 2.9k\n\n Mar 2024\n\n Towards Scalable Ethereum Staking: The Imperative of Stateless Clients with Compact Proof Sizes\n\n stateless\n\n 1\n\n 1.6k\n\n Mar 2024\n\n Paths to hardening PBS\n\n mev\n\n 0\n\n 2.3k\n\n Feb 2024\n\n The price is right: Realigning proposer-builder incentives with predictive MEV-burn\n\n mev\n\n 5\n\n 2.6k\n\n Feb 2024","tokens":694,"squid":"ink-research","role":"Deep Scholar","at":1791268455384,"hash":"40c61d78d59b04a59bb81a9d0a16b73f120f83bf"}
{"url":"https://docs.base.org/specifications/base-protocol/bridging/cross-domain-messengers","domain":"docs.base.org","title":"Cross Domain Messengers - Base Documentation","text":"​Overview\nThe cross domain messengers are responsible for providing a higher level API for\ndevelopers who are interested in sending cross domain messages. They allow for\nthe ability to replay cross domain messages and sit directly on top of the lower\nlevel system contracts responsible for cross domain messaging on L1 and L2.\nThe CrossDomainMessenger is extended to create both an\nL1CrossDomainMessenger as well as a L2CrossDomainMessenger.\nThese contracts are then extended with their legacy APIs to provide backwards\ncompatibility for applications that integrated before the Bedrock system\nupgrade.\nThe L2CrossDomainMessenger is a predeploy contract located at\n0x4200000000000000000000000000000000000007.\nThe base CrossDomainMessenger interface is:\nCrossDomainMessenger.solinterface CrossDomainMessenger {\n event FailedRelayedMessage(bytes32 indexed msgHash);\n event RelayedMessage(bytes32 indexed msgHash);\n event SentMessage(address indexed target, address sender, bytes message, uint256 messageNonce, uint256 gasLimit);\n event SentMessageExtension1(address indexed sender, uint256 value);\n\n function MESSAGE_VERSION() external view returns (uint16);\n function MIN_GAS_CALLDATA_OVERHEAD() external view returns (uint64);\n function MIN_GAS_CONSTANT_OVERHEAD() external view returns (uint64);\n function MIN_GAS_DYNAMIC_OVERHEAD_DENOMINATOR() external view returns (uint64);\n function MIN_GAS_DYNAMIC_OVERHEAD_NUMERATOR() external view returns (uint64);\n function OTHER_MESSENGER() external view returns (address);\n function baseGas(bytes memory _message, uint32 _minGasLimit) external pure returns (uint64);\n function failedMessages(bytes32) external view returns (bool);\n function messageNonce() external view returns (uint256);\n function relayMessage(\n uint256 _nonce,\n address _sender,\n address _target,\n uint256 _value,\n uint256 _minGasLimit,\n bytes memory _message\n ) external payable returns (bytes memory returnData_);\n function sendMessage(address _target, bytes memory _message, uint32 _minGasLimit) external payable;\n function successfulMessages(bytes32) external view returns (bool);\n function xDomainMessageSender() external view returns (address);\n}\n\n​Message Passing\nThe sendMessage function is used to send a cross domain message. To trigger\nthe execution on the other side, the relayMessage function is called.\nSuccessful messages have their hash stored in the successfulMessages mapping\nwhile unsuccessful messages have their hash stored in the failedMessages\nmapping.\nThe user experience when sending from L1 to L2 is a bit different than when\nsending a transaction from L2 to L1. When going from L1 into L2, the user does\nnot need to call relayMessage on L2 themselves. The user pays for L2 gas on L1\nand the transaction is automatically pulled into L2 where it is executed on L2.\nWhen going from L2 into L1, the user proves their withdrawal on OptimismPortal,\nthen waits for the finalization window to pass, and then finalizes the withdrawal\non the OptimismPortal, which calls relayMessage on the\nL1CrossDomainMessenger to finalize the withdrawal.\n​Upgradability\nThe L1 and L2 cross domain messengers should be deployed behind upgradable\nproxies. This will allow for updating the message version.\n​Message Versioning\nMessages are versioned based on the first 2 bytes of their nonce. Depending on\nthe version, messages can have a different serialization and hashing scheme.\nThe first two bytes of the nonce are reserved for version metadata because\na version field was not originally included in the messages themselves, but\na uint256 nonce is so large that we can very easily pack additional data\ninto that field.\n​Message Version 0\nMessage Version 0 Encodingabi.encodeWithSignature(\n \"relayMessage(address,address,bytes,uint256)\",\n _target,\n _sender,\n _message,\n _messageNonce\n);\n\n​Message Version 1\nMessage Version 1 Encodingabi.encodeWithSignature(\n \"relayMessage(uint256,address,address,uint256,uint256,bytes)\",\n _nonce,\n _sender,\n _target,\n _value,\n _gasLimit,\n _data\n);\n\n​Backwards Compatibility Notes\nAn older version of the messenger contracts had the concept of blocked messages\nin a blockedMessages mapping. This functionality was removed from the\nmessengers because a smart attacker could get around any message blocking\nattempts. It also saves gas on finalizing withdrawals.\nThe concept of a “relay id” and the relayedMessages mapping was removed.\nIt was built as a way to be able to fund third parties who relayed messages\non the behalf of users, but it was improperly implemented as it was impossible\nto know if the relayed message actually succeeded.Was this page helpful?Suggest editsRaise issue","tokens":1159,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268470642,"hash":"d5b13d245db6fc244985db252aa1ea97e1887c59"}
{"url":"https://ethresear.ch/t/paths-to-ssf-revisited/22052","domain":"ethresear.ch","title":"Paths to SSF revisited - Proof-of-Stake / Economics - Ethereum Research","text":"Paths to SSF revisited \n\n Proof-of-StakeEconomics\n\n protocol-research-call\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n Mar 2025\n\n 1 / 1\n\n Mar 2025\n\n Mar 2025\n\n post by barnabe on Mar 31, 2025\n\n barnabe\n\n Many thanks to Alex Stokes, Anders Elowsson, Ansgar Dietrichs, Carl Beekhuizen, Caspar Schwarz-Schilling, Dankrad Feist, Data Always, Drew van der Werff, Eric Siu, Francesco d’Amato, Hasu, Jihoon Song, Julian Ma, Justin Drake, Ladislaus von Daniels, Mike Neuder, Nixo, Oisín Kyne, Parithosh Jayanthi, Potuz, Sacha Saint-Leger, Terence Tsao, Thomas Thiery, Tim Beiko, Toni Wahrstätter for their comments and reviews (these are not endorsements).\n\nOur previous post revisited local building, questioning its contribution to network goals such as censorship-resistance, scaling or verifiability. Beyond building, our staking nodes bundle many duties, and being clever about assigning the right roles to the right nodes, breaking away from too rigid models of what a “staker” is, seems more and more at hand. In this light, the model of a solo staker building directly their own block from their own machine with their own stake may be worth revisiting, too. This may be the key to obtaining a validator set that works for us towards achieving Single-Slot Finality with shorter slot times on a much faster timeline.\nTo be clear: This post argues that “home” nodes (non-commercial, permissionless, plentiful) remain critical for the Ethereum network, in particular for their independent and actionable voice, as well as for their role as FOCIL includers. We would not have the opportunity to ask about our options today, had we not optimised for solo stakers to exist on the network. But this path-dependency also means that decisions which were possibly correct to do then, could be less correct moving forward, as the roles, shapes and economic organisation of our nodes evolve.\nProtocol roles and types of nodes, part two\nIn the previous post on local building, we introduced some ways of talking about protocol roles—attester, builder, includer—as well as node types—minimal node, satisfying the basic hardware requirements; staking node, controlling a validator; high resource node, having access to higher amounts of compute, bandwidth, or order flow.\nWe’ll have more distinctions in this post, because the world is diverse and different needs are filled by different means. The first distinction is between home and commercial staking nodes. We bold these two words as they are types of nodes on the network. The distinction is not one of performance, or resources: A dedicated home staker could have invested a lot more time, effort and money in their node than some commercial operator. The distinction is one of trust, or credibility. A home node does not come a priori with a signal of their honesty, understood here to mean that they would be credibly expected to perform their duties (attesting, building) correctly and timely. A commercial entity is bound by legal contracts and the commercial value of maintaining a good reputation, with many other avenues to signal credibility. While we describe here two archetypes, note that this is not a binary distinction, and home nodes may garner over the course of their operations further signals of their credibility.\nThe second distinction we need is between operator and staker. We italicise these two words as they are roles adopted by protocol participants.\n\nAn operator performs validating duties, mediated by their node, either a home staking node (when they are a priori untrusted) or a commercial staking node (when there exists a stronger signal of their credibility).\nA staker provides capital at stake, a resource demanded by the protocol to offer validating services.\nA solo staker is then both its own operator and staker, running their own node and having contributed their own stake.\n\nContributions of home nodes to the network\nWhat does the ability for anyone with a home node to participate in network operations buy us? First, if we assume that home nodes are more plentiful than commercial nodes, we broaden massively the operator set. But why do we care about broad participation?\nEssentially, the network wants an opinionated enough set of participants to provide maximal independence in its operations. Suppose all nodes followed the whims of a single entity: The network would effectively be captured, if all nodes voted “Left” when told “Left”, and voted “Right” when told “Right”. What we want is for the maximum possible number of nodes to come to their independent, individual conclusions regarding which way to vote.\nUnfortunately, we’re not making much use of how wide the base is when it comes to certain protocol services, in particular the finality service. This service outputs finalised checkpoints, making credible commitments such as “if the chain ever finalises a conflicting checkpoint, at least ⅓ of the total active stake currently deposited will be burned”. We may have many home nodes, but they do not carry most of the stake, and their voice in that service is proportional to their stake.\nThis is why solo stakers, who stake and operate with their own resources do not carry a huge voice when it comes to the consensus mechanism. According to numbers from September 2024, solo stakers operate 5.4% of the total stake on the network. This is not sufficient to even prevent finalisation of a malicious block, which would require at least 33% of the stake.\nStill, solo stakers provide a quantity of independent voice to the operations of the network. Should the more centralised parts of the validator set fail or become captured, a set of solo stakers operational on the network can ensure a quick mobilisation to re-establish network stability. The voice of independent nodes today is especially powerful, when solo stakers as local builders do not censor when the external builder market censors, at least until better approaches are deployed such as FOCIL. FOCIL will largely amplify this voice, multiplying by 16 the opportunities of home nodes on the network to create binding inclusion lists.\nHome nodes: Solo stakers and home operators\nAs we have seen over the years since Ethereum PoS began, not all home nodes are operated by solo stakers. The division of capital and labor applies to staking, in particular to home nodes. We can distinguish between two categories of operators:\n\nSome home nodes are solo stakers, who operate their own hardware and provide services to the network on the basis of their own stake.\nSome home nodes operate their own hardware, but receive delegated stake and perform validation services on the behalf of their delegators. We may call these nodes home operators, a strictly larger subset to solo stakers.\n\nThese home operators are not commercial operators, and there does not exist a priori a signal of their credibility. Yet, using cryptoeconomic mechanisms such as bonds, home operators can become part of the larger operator set of staking protocols such as Lido or Rocket Pool. Respectively, a node at home can sign up to perform services for Lido using their Community Staking Module (CSM) or for Rocket Pool by opening a Minipool. Both options require the home operator to deposit some of its own collateral, after which they are provided with delegated stake from depositors of the LST protocol. The home operator then receives a share of the rewards they obtain on the delegated stake. Besides the 5.4% of stake controlled by solo stakers, 1.58% of stake is currently operated by Rocket Pool operators, while Lido’s CSM now controls 2% of the stake provided to Lido (i.e., 0.54% of current stake), with plans to increase this share. Home operators can further boost their credibility by opting into Distributed Validator (DV) networks such as Obol or SSV, where the logical validator controlled by a larger set of operators becomes more credible than the sum of its parts.\nHome operators are afforded some agency by the protocols they provide a service to. In particular, operators make their own decisions when it comes to issuing attestations. They may have a more limited choice of PBS relays to connect to, following for instance a whitelist curated by their protocol. In the future, protocols should aim to place maximum agency at the operator level when it comes to issuing FOCIL lists. For instance, a DV network could choose a round-robin mechanism, when one node of the DV network is selected to make the inclusion list, with this role rotating each time.\nTwo paths to SSF and shorter slot times\nWhy does the distinction between solo stakers and home operators matter? It is a deciding factor in a decision that should be made to orient future protocol R&D of Ethereum, including Single-Slot Finality and shorter slot times, say, 4 seconds. Essentially, we are faced with the choice between:\n\nThe Orbit path: Embarking on a more costly R&D programme in order to preserve maximally free entry of solo stakers in the validator set; or\nThe capped validator set path: Relying much more heavily on the sufficiency of home operators to guarantee properties such as censorship-resistance.\n\nWe quickly provide details of both options, before discussing their relative merits.\n\nIn the Orbit path, we set a MIN_EFFECTIVE_BALANCE, allowing any staker depositing at least MIN_EFFECTIVE_BALANCE ETH to enter the validator set. However, we receive inputs from heavier stake-weighted validators more frequently in order to achieve higher magnitudes of finality faster, while providing incentives for validators to consolidate their stake as much as possible and increase their stake-weight.\nIn the capped validator set path, validators are ranked by the amount of stake controlled by each. We set a threshold, VALIDATOR_SEATS, such that the top VALIDATOR_SEATS by stake are active validators, while validators who did not make the cut are inactive. This threshold is set to achieve a certain target slot time, as well as fast finality with all validators voting at once, instead of committee-after-committee.\n\nFollowing Vitalik’s “Paths to SSF” post in December 2023, EF Research has spent the past year exploring in detail both paths, and we come now to a choice which must guide our future R&D. We understand that developing a version of SSF consistent with Orbit (namely, committee-based SSF), will likely add much more delay to obtaining SSF, first because Orbit itself is a new mechanism with subtle economics to get right, and second because we do not yet have a committee-based SSF version that is ready to be specified.\nOn the other hand, the capped validator set path is one of maximum protocol simplicity, relying on better-understood primitives such as non-committee-based SSF and mechanisms similar to classic delegated Proof-of-Stake. Its timeline could even be accelerated further via the ongoing beam chain project, which could start specifications work in the next few months for a new consensus mechanism delivering SSF (e.g., using 3-slot-finality or a variant) and shorter slot times in a couple of years with a “beam fork”, in parallel to iterative upgrades in the meantime. An early commitment to the capped validator set path would bring forward significantly some of these timelines.\nThere is no free lunch. The major risk of capping the validator set is effectively preventing access to entities controlling an insufficient amount of stake, who cannot make it to the top VALIDATOR_SEATS. Sources from a year ago estimate around 12,000 nodes on the Ethereum network, with around 5,000 of them not connected to any attestation subnet, hence likely not staking nodes. This would put the number of staking nodes at around 7,000. With perfect consolidation, this number of nodes is consistent with a number of 8192 validators in the set, which would mean that the minimum balance to enter the validator set would not increase from today’s level of 32 ETH.\nHowever, this may not be the likeliest scenario, and we would need to understand whether this number of 8192 signatures is consistent with our target slot times. If staking nodes do not properly consolidate their stake, we would need to leave some nodes out from direct participation in the validator set. This means that it is unlikely that the minimum required balance to enter the set would settle at or below 32 ETH, excluding the current class of 32 ETH solo stakers in particular, with values of VALIDATOR_SEATS consistent with other goals such as shorter slot times or the use of post-quantum cryptography.\nYet our explorations into Rainbow staking have made us more confident that what is lost with such an approach can be obtained otherwise. In particular, we may not get 1 ETH validators, but we can eventually get 1 ETH includers in the FOCIL sense, a new role besides validators. A strawman of this idea is a simple smart contract registry enabling a set of light delegators to “token-curate” a set of light operators making inclusion lists. We make a brief aside to introduce this idea in the next section.\nHeavy FOCIL, Light FOCIL\nWe ensure censorship-resistance as long as any valid, fee-paying transaction always finds its way onchain. Today, censorship-resistance is provided whenever the block builder (either local or external) does not discriminate between transactions and seeks to include them maximally. We propose to improve this by introducing the new role of including, besides the attesting and building roles.\nOur strategy for supercharging includers relies on FOCIL, an elegant multi-proposer gadget allowing many parties to propose binding transactions for inclusion in every block. But are we limited to choosing includers only from the validator set? Interestingly, we are not, and we may distinguish between two versions of FOCIL:\n\nHeavy FOCIL: Includers are sampled from the validator set.\nLight FOCIL: Includers are sampled from an operator set curated by ETH holders, distinct from the validator set.\n\nLight FOCIL would be an instance of Rainbow staking, where a set of light operators, distinct from staking operators performing validation duties, is given the responsibility to output inclusion lists binding the block producers. Light FOCIL could be deployed with a separate deposit contract, which looks more like classic token governance with delegation than to PoS staking with a capital lock-up and long entry/exit periods.\n\nAnyone could declare themselves ready to be a FOCIL light operator, a.k.a., light includer.\nSay a user has 10 ETH in their wallet. By signing a message, this user could declare that they are “delegating” these 10 ETH to a light includer of their choice. The user is then a light delegator.\nThe 10 ETH remains in the user’s custody, and should their balance change, their delegated amount would also change. The user account is simply encumbered with a delegation record assigning the weight of their tokens to their light includer of choice.\nLight includers are then sampled based on their delegated-weight.\n\nThis service may not be rewarded, but could be performed by any sufficiently altruistic full node (including staking node), or even stateless node, that is already present on the network for any reason. Light delegators can immediately re-delegate their weight away from their chosen light includer, if they are unsatisfied with the censorship-resistance performance of their chosen operator. The conditions for FOCIL to work well are very weak: We typically only need one of 16 includers to be honest in order for censorship-resistance to be provided. For this reason, we posit that even without rewards, and with such a frictionless delegation model, Light FOCIL would prove to be practically robust.\nNote that both versions of FOCIL could exist at the same time! We propose to introduce Heavy FOCIL first and Light FOCIL second. Heavy FOCIL already buys us the following:\n\nAs long as a small, non-zero percentage of honest staking nodes participates as includers, censorship-resistance is greatly increased beyond today’s provision.\nWith FOCIL in place, home operators no longer need to rely on local building for the provision of censorship-resistance, allowing them to receive blocks from an external builder market without trading off network censorship-resistance, and giving more scale to the network.\n\nMore arguments regarding home operators\nOrbit optimises for access into the validator set with lower amounts at stake. All else equal, it is preferable to lower the entry requirements as much as possible. However, we argued that regardless of the entry threshold, even allowing for direct participation of smaller-staked solo stakers with Orbit, it is difficult to ensure effective participation in some services such as the finality gadget for smaller-staked nodes.\nIf our goal is to have at the ready home operators and a sufficient number of these to provide good (heavy) FOCIL service, we may be satisfied with higher entry requirements leading to significant protocol simplification, as long as indirect participation appears viable. In this case, we would put less expectation on home operators joining directly as solo stakers, as the minimum required balance would be higher, and more on them joining larger protocols or mechanisms, e.g., solo stakers pooling assets using distributed validation, or home operators performing validation services on behalf of delegated stake. The ability for a distinct set of participants (light includers) to strengthen the FOCIL service could make us further convinced.\nWe end our discussion with further arguments around home operators broadly.\nHardening of home operator protocols\nWe’ve observed over the last 4 years a hardening of the protocols involving home operators, including at their governance layer (see e.g., Lido dual governance, or Rocket Pool’s ProtocolDAO improvements). This is not as perfect as every unit of capital placed at stake mediating their own independent voice through their own node, e.g., while performing attestation or inclusion services directly as solo stakers. However, this could give us an existence proof of good protocols preserving permissionless entry of home operators and preserving their agency when performing validation duties.\nPossibility to make the staking market more efficient with protocol infrastructure\nShould we decide to go down the capped validator set path, it would be reasonable to enshrine the infrastructure necessary for the existence of delegated or liquid staking protocols, such as in-protocol delegation records à la Liquid Staking Module, hardening this class of protocols further. This is not equivalent to “enshrining Lido”, but it is a way of ensuring that some smart contract risk inherent in these protocols becomes essentially removed (namely, the deposit and delegation contracts), levelling access to this market for new competitors, and giving us some helpful features such as fast redelegations. Such a large change may be best achieved with a “from scratch” redesign of this layer, e.g., via beam chain.\nImprovements of home operator economics\nOperating costs of staking nodes can be driven down to low levels over the next 3-5 years, assuming we require from them the minimum necessary to verify the chain and attest their view. Indeed, zkEVMs will drive verification cost down, even for large blocks; statelessness with a zkEVM or a trie change will remove the need to be stateful in order to attest; data availability sampling will require lower bandwidth to satisfy oneself of blob availability; history expiry will remove increasing storage costs.\nThis leaves only the cost of capital necessary for home operators to establish their credibility via a bond, if these operators stake on the behalf on delegators. The decreasing cost of capital (lower hardware cost), with the yield coming from rewards received on behalf of the stake delegated to these operators, favours their economics.\nOverall viability of home operations\nEthereum’s current philosophy does not assume that home operation economics are fundamentally non-viable, and as the section above argues, they may even improve over time. Still, issuance conversations have surfaced the pressures on operators to compete with more centralised entities that have better economics. Neither Orbit nor the capped validator set proposal fix these issues, and if it were anyways not viable for 1 ETH or 4 ETH solo stakers to exist sustainably on the network, then incurring the complexity cost of Orbit and committee-based SSF should be a non-starter. But our argument here does not rely on the assumption that home operations are fundamentally non-viable in any scenario. We simply point out that there are different classes of home operations that we could be optimising for, such as the broader class of home operations or the more narrow class of solo staking.\nIf it is potentially viable for such 1 ETH or 4 ETH solo stakers to exist and be willing to participate directly as validators, we outline the possibility for these solo stakers to consider pooling their assets as part of a larger protocol, e.g., even governance-free distributed validation, in order to reach the threshold required to enter the validator set in a capped mechanism. This replicates the economics of solo staking, with each operator on the distributed validator network bringing their own node and their own stake, if not the operations of solo staking, as there is an extra layer of consensus to achieve between the nodes.\nThis type of indirect participation may not be quite as powerful as direct participation, and we lose something from making direct participation harder to reach instead, but with the potential upside of achieving a better point on our trade-off space between giving up some optionality for every class of staker and gaining protocol simplicity and features in exchange.\nConclusion\nPaths revisited1920×1669 102 KB\nWe plot in the tree above some possible paths forward, with weak conviction on the specific numbers quoted in the boxes, trying to paint more of an order of magnitude than commit ourselves to specific parameters. Our first choice should likely be between one of two paths, and in either case we have the possibility to consider the addition of Light FOCIL, which is perhaps even more appealing in a capped validator set world.\nRegardless of our choice between the capped validator set path and the Orbit path, we make the point here that we should move away from a too binary distinction between “solo stakers” on one side, and “commercial operators” receiving delegated stake from holders. There exists now, and likely more so in the future, a diverse set of ways for nodes to participate in network operations and to organise themselves, from being mere labor for delegated capital, to pooling capital in a distributed fashion between operators, to operating services such as FOCIL inclusion for which nothing more than a light client behind a wallet is necessary.\n\n Decoupling throughput from local building\n\n eODS (Enshrined Operator Delegator Separation): a Delegation model proposal\n\n read \n\n 8\n min\n\n Powered by Discourse","tokens":5788,"squid":"ink-research","role":"Deep Scholar","at":1791268470679,"hash":"f931cda6b595a3af286c6b123afde0e2c0e9be7d"}
{"url":"https://blog.ethereum.org/2026/09/17/glamsterdam-testnet-announcement","domain":"blog.ethereum.org","title":"Glamsterdam Testnet Announcement | Ethereum Foundation Blog","text":"Glamsterdam Testnet AnnouncementPosted by Protocol on September 28, 2026Protocol AnnouncementsGlamsterdam follows the Fusaka upgrade, advancing Ethereum's L1 scaling roadmap with enshrined proposer-builder separation, block-level access lists, and changes to gas pricing that better reflect the cost of execution and state growth.\nThe Glamsterdam network upgrade is scheduled to activate on Sepolia at epoch 353,024, slot 11,296,768 (October 6, 2026, 13:53:36 UTC). See the activation table below for the deployment schedule. Hoodi and mainnet activation dates have not yet been decided.\nSepolia-compatible client versions will be added to the client release tables as they are confirmed. Node operators must update both their execution and consensus layer clients before activation.\nGlamsterdam Overview\nGlamsterdam combines the Amsterdam execution layer upgrade with the Gloas consensus layer upgrade. Its headlining changes are enshrined proposer-builder separation (ePBS) and block-level access lists (BALs), which change how blocks are produced and validated to support greater L1 throughput.\nEnshrined Proposer-Builder Separation\nEIP-7732 brings the separation between block proposers and builders into Ethereum's consensus protocol. A proposer includes a builder's commitment to an execution payload, and the builder subsequently reveals that payload. The protocol handles payment to the proposer, reducing reliance on trusted middleware for the exchange between proposers and builders.\nThe change also separates consensus validation from execution validation, giving validators more time to validate execution payloads. A payload timeliness committee attests to whether the builder revealed its payload and the corresponding blob data was available on time. Validator operators and teams maintaining builder infrastructure should review the new duties and interfaces before the upgrade.\nBlock-Level Access Lists\nEIP-7928 introduces enforced block-level access lists that record the accounts and storage locations accessed during a block, together with post-transaction state changes. These lists allow clients to read state from disk in parallel, validate transactions in parallel, and compute state roots more efficiently.\nTogether, ePBS and BALs provide a foundation for scaling execution capacity while keeping block validation practical for node operators.\nGas Pricing and State Growth\nGlamsterdam adjusts gas accounting to better reflect resource usage. EIP-8037 increases and separately meters the cost of creating state, while EIP-8038 updates state-access costs. Additional changes cover intrinsic transaction gas, calldata, access lists, and block gas accounting.\nApplication developers should test contracts and gas estimation against the new rules. Contracts that rely on fixed gas stipends, hardcoded gas limits, or assumptions about remaining gas may need changes. See the Glamsterdam repricing impact guide for the affected-contracts search and testing guidance.\nDeveloper and Validator Improvements\nGlamsterdam also includes ETH transfer logs, a slot-number opcode, a higher maximum contract size, a deterministic factory contract, and new stack-manipulation instructions. Consensus changes include forward-compatible data structures, excluding slashed validators from proposing, and increased exit and consolidation churn. The complete scheduled EIP list is below.\nGlamsterdam Specifications\nEIP-7773 tracks the Glamsterdam upgrade. The following EIPs are scheduled for inclusion:\nEIP-2780: Resource-based intrinsic transaction gasEIP-7688: Forward compatible consensus data structuresEIP-7708: ETH transfers emit a logEIP-7732: Enshrined Proposer-Builder SeparationEIP-7778: Block Gas Accounting without RefundsEIP-7843: SLOTNUM opcodeEIP-7928: Block-Level Access ListsEIP-7954: Increase Maximum Contract SizeEIP-7976: Increase Calldata Floor CostEIP-7981: Increase Access List CostEIP-7997: Deterministic Factory ContractEIP-8024: Backward compatible SWAPN, DUPN, EXCHANGEEIP-8037: State Creation Gas Cost IncreaseEIP-8038: State-access gas cost updateEIP-8045: Exclude slashed validators from proposingEIP-8061: Increase exit and consolidation churnEIP-8246: Remove SELFDESTRUCT BurnEIP-8282: Builder Execution Requests\nEIP-7773 also lists supporting networking and informational EIPs:\nEIP-7975: eth/70 - partial block receipt listsEIP-8070: eth/72 - Sparse BlobpoolEIP-8136: Cell-Level Deltas for Data Column BroadcastEIP-8159: eth/71 - Block Access List ExchangeEIP-8189: snap/2 - BAL-Based State HealingEIP-7904: Compute Gas Cost AnalysisEIP-8261: Gas Limit Schedule\nGlamsterdam Security\nThe Ethereum Bug Bounty Program is now active for Glamsterdam specifications and EIPs. Client implementations become eligible as soon as their releases are added to the client release tables below. See the Ethereum Bug Bounty Program for more information, including reward multipliers and reporting requirements.\nGlamsterdam Activation\nThe agreed deployment schedule, reflected in the Sepolia activation update to EIP-7773, is:\n\nNetworkEpochSlotUTC TimeUNIX TimestampSepolia353,02411,296,7682026-10-06 13:53:361791294816HoodiTBDTBDTBDTBDMainnetTBDTBDTBDTBD\nHoodi and mainnet activation times will be announced once decided by client teams. This announcement covers Sepolia; it does not schedule a mainnet upgrade.\nClient Releases\nSepolia-compatible client releases are listed below. The tables will be updated as additional releases become available. Only use a release whose notes explicitly confirm support for the scheduled Glamsterdam activation on Sepolia.\nConsensus Layer Sepolia Releases\nWhen running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.\n\nNameVersionLinkGrandine3.0.0-rc.0DownloadLighthouse8.3.0-rc.0DownloadLodestar1.49.0DownloadNimbus26.10.0DownloadPrysm7.2.0DownloadTeku26.9.1Download\nPrysm 7.2.0 supports the Sepolia fork but defaults to a 60M gas limit after activation. Validators wishing to propose with a 200M gas limit must configure it explicitly using version 2 proposer settings or the keymanager API; --suggested-gas-limit has no effect after Gloas. See the Prysm release notes for instructions.\nTeku 26.9.1 supports the Sepolia fork but defaults to a 60M gas limit after activation. Validators wishing to propose with a 200M gas limit must configure it explicitly using --validators-builder-registration-default-gas-limit=200000000. See the Teku docs for details.\nExecution Layer Sepolia Releases\n\nNameVersionLinkBesu26.9.0DownloadEthrex29.0.1DownloadErigon3.7.1Downloadgo-ethereum1.17.7DownloadNethermind2.1.0DownloadReth2.7.0Download\nBuilder and validator tooling compatibility guidance will be added once confirmed for Sepolia. Operators using external block-building infrastructure should also review its Glamsterdam-specific upgrade instructions.\nFAQ\nHow do Ethereum network upgrades work?\nEthereum network upgrades require explicit opt-in from node operators. Client developers coordinate the protocol changes, and validators and non-staking nodes update their software to support them.\nA node that does not support the new rules cannot follow the upgraded network after activation. Coordinating these updates is therefore essential for a successful upgrade.\nFor a more exhaustive overview of Ethereum's governance process, see this talk by Tim Beiko.\nAs an Ethereum mainnet user or ETH holder, is there anything I need to do?\nNo. This announcement concerns Sepolia. A separate announcement will cover Glamsterdam's activation on mainnet.\nIf you'd like to watch the upgrade go live, you can join the online viewing party!\nAs a non-staking Sepolia node operator, what do I need to do?\nBefore October 6, 2026 at 13:53:36 UTC, update both your execution and consensus layer clients to releases that support the scheduled Sepolia activation. The client release tables will be updated as versions are confirmed.\nAs a Sepolia staker, what do I need to do?\nUpdate your execution and consensus layer clients before activation. Make sure both your beacon node and validator client are updated. Review your client's upgrade instructions for the new ePBS duties and any changes required to builder or validator tooling.\nAs a Hoodi or mainnet node operator or staker, what do I need to do?\nNo action is required for those networks as a result of this Sepolia announcement. Their activation dates and compatible client releases will be announced separately.\nAs an application or tooling developer, what should I do?\nReview the EIPs scheduled for Glamsterdam, test on Sepolia after activation, and check whether changes to gas accounting, logs, opcodes, or client interfaces affect your project. In particular, follow the repricing impact guide to identify contracts that depend on fixed gas assumptions and update gas estimation where needed.\nWhy \"Glamsterdam\"?\nExecution layer upgrades are named after Devcon or Devconnect host cities, and consensus layer upgrades use star names. Glamsterdam combines Gloas and Amsterdam, the location of Devconnect in 2022.","tokens":2261,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268480045,"hash":"52f2d1f64dea5c88a8c7a48417a48f15080db60a"}
{"url":"https://docs.base.org/specifications/base-protocol/bridging/standard-bridges","domain":"docs.base.org","title":"Standard Bridges - Base Documentation","text":"The standard bridges support cross-domain ETH and ERC-20 transfers between Ethereum (L1) and Base (L2). They are built on top of the cross-domain messenger contracts and provide a standard interface for moving tokens between domains.\nFor the underlying transaction mechanisms, see Deposits and Withdrawals.\n​Overview\nThe standard bridges are responsible for allowing cross domain\nETH and ERC20 token transfers. They are built on top of the cross domain\nmessenger contracts and give a standard interface for depositing tokens.\nThe bridge works for both L1 native tokens and L2 native tokens. The legacy API\nis preserved to ensure that existing applications will not experience any\nproblems with the Bedrock StandardBridge contracts.\nThe L2StandardBridge is a predeploy contract located at\n0x4200000000000000000000000000000000000010.\nStandardBridge.solinterface StandardBridge {\n event ERC20BridgeFinalized(address indexed localToken, address indexed remoteToken, address indexed from, address to, uint256 amount, bytes extraData);\n event ERC20BridgeInitiated(address indexed localToken, address indexed remoteToken, address indexed from, address to, uint256 amount, bytes extraData);\n event ETHBridgeFinalized(address indexed from, address indexed to, uint256 amount, bytes extraData);\n event ETHBridgeInitiated(address indexed from, address indexed to, uint256 amount, bytes extraData);\n\n function bridgeERC20(address _localToken, address _remoteToken, uint256 _amount, uint32 _minGasLimit, bytes memory _extraData) external;\n function bridgeERC20To(address _localToken, address _remoteToken, address _to, uint256 _amount, uint32 _minGasLimit, bytes memory _extraData) external;\n function bridgeETH(uint32 _minGasLimit, bytes memory _extraData) payable external;\n function bridgeETHTo(address _to, uint32 _minGasLimit, bytes memory _extraData) payable external;\n function deposits(address, address) view external returns (uint256);\n function finalizeBridgeERC20(address _localToken, address _remoteToken, address _from, address _to, uint256 _amount, bytes memory _extraData) external;\n function finalizeBridgeETH(address _from, address _to, uint256 _amount, bytes memory _extraData) payable external;\n function messenger() view external returns (address);\n function OTHER_BRIDGE() view external returns (address);\n}\n\n​Upgradability\nBoth the L1 and L2 standard bridges should be behind upgradable proxies.Was this page helpful?Suggest editsRaise issue","tokens":613,"squid":"ink-layer1_layer2","role":"Chain Reader","at":1791268482156,"hash":"3e017f75910d6a576beb879aebb87447dafb6887"}
{"url":"https://eips.ethereum.org/EIPS/eip-7732","domain":"eips.ethereum.org","title":"EIP-7732: Enshrined Proposer-Builder Separation","text":"⚠️ Review\n\n Standards Track: Core\n\n EIP-7732: Enshrined Proposer-Builder Separation\n\n Separates the ethereum block in consensus and execution parts, adds a mechanism for the consensus proposer to choose the execution proposer.\n\n Authors\n Francesco D'Amato <francesco.damato@ethereum.org>, Nico Flaig <nflaig@protonmail.com>, Barnabé Monnot <barnabe.monnot@ethereum.org>, Michael Neuder <michael.neuder@ethereum.org>, Potuz (@potuz), Justin Traglia <jtraglia@ethereum.org>, Terence Tsao <ttsao@offchainlabs.com>\n\n Created\n 2024-06-28\n\n This EIP is in the process of being peer-reviewed. If you are interested in this EIP, please participate using this discussion link.\n\n Abstract\n\nThis EIP fundamentally changes the way an Ethereum block is validated by decoupling the execution validation from the consensus validation both logically as well as temporally. It does so by introducing a new in-protocol entity called builders and adding a new duty (submitting payload timeliness attestations) to Ethereum validators. The ExecutionPayload field of the BeaconBlockBody is removed and instead it is replaced by a signed commitment (a SignedExecutionPayloadBid object) from a builder to later reveal the corresponding execution payload. This commitment specifies in particular the blockhash of the execution block and a value to be paid to the beacon block proposer. When processing the BeaconBlock, the committed value is deducted from the builder’s beacon chain balance and later a withdrawal is placed to an address, of the proposer’s choosing, in the execution layer. A subset of validators in the beacon committee is assigned to the Payload Timeliness Committee (PTC), these validators are tasked to attest (by broadcasting a PayloadAttestationMessage) to whether the corresponding builder has revealed the committed execution payload (with the right blockhash) in a timely fashion and whether the correspoding blob data was available according to their view. PTC members are not required to validate the execution payload, execution validation is thus deferred until the next beacon block validation. While builder’s are staked entities, their stake is not actively validating the beacon chain, they are not subject to the usual deposit and exit churn/queues and can be staked for as little as 1ETH. While the in-protocol payment via withdrawals is trustlessly deducted from this stake, the protocol also accomodates for trusted payments in the form of promises to be fulfiled elsewhere.\n\n Motivation\n\nThis EIP solves a different set of unrelated important problems.\n\n An overwhelming majority of beacon block proposers outsource the construction of the execution payload within their blocks to a third party (henceforth called a builder). In order to do so, they request the hash tree root (HTR) of a promised execution payload and submit a SignedBlindedBeaconBlock to a trusted party that is tasked with replacing the HTR with the full execution payload (received from the builder) before broadcasting. This EIP allows for a trust-free fair exchange between the beacon block proposer and the builder, guaranteeing that an honest beacon block proposer will receive payment from the builder regardless of the latter’s actions and that the honest builder’s payload will be the canonical head of the chain regardless of the proposer’s action.\n Currently, validators have the time between receiving the full beacon block (including an execution payload) and the attesting deadline (4 seconds in Ethereum mainnet) to perform both consensus and execution state transition functions, check blob data availability and evaluate the new head of the blockchain. The remainder of the slot time is spent doing less CPU-intense and critical task. By separating the validation of the execution and consensus part of the block, validators are only tasked to perform the consensus state transition function in this critical time before attesting, while execution and data availability validation is deferred for most of the remainder of the slot (between the builder’s reveal time and the next attestation deadline).\n By removing the full execution payload size from the consensus block, it allows for faster network propagation on the critical path.\n It removes the increased reorg likeliness of including blob transactions in blocks given the natural increase in timelines for data availability checks and the fact that the builder may broadcast the blob sidecars even before attestations for the beacon block have been released.\n It prevents validators from missing attestations and strengthens the weight properties of fork choice in the event that builders produce invalid payloads.\n It removes the need to use trusted middleware in order to delegate block construction to a builder.\n\n Specification\n\n Execution Layer\n\nNo changes are required.\n\n Consensus Layer\n\nThe full consensus changes can be found in the consensus-specs Github repository. They are split between:\n\n Beacon Chain changes.\n Fork choice changes.\n P2P changes.\n Honest validator guide changes.\n A new honest builder guide.\n Fork logic changes.\n\nA summary of the main changes is included below, the Rationale section contains an explanation for most of the design decisions around these changes.\n\n Beacon chain changes\n\n Types\n\n Name\n SSZ equivalent\n Description\n\n BuilderIndex\n uint64\n Builder registry index\n\n Constants\n\n Index flags\n\n Name\n Value\n Description\n\n BUILDER_INDEX_FLAG\n uint64(2**40)\n Bitwise flag which indicates that a ValidatorIndex should be treated as a BuilderIndex\n\n Domains\n\n Name\n Value\n\n DOMAIN_BEACON_BUILDER\n DomainType('0x0B000000')\n\n DOMAIN_PTC_ATTESTER\n DomainType('0x0C000000')\n\n DOMAIN_PROPOSER_PREFERENCES\n DomainType('0x0D000000')\n\n Misc\n\n Name\n Value\n Description\n\n BUILDER_INDEX_SELF_BUILD\n BuilderIndex(UINT64_MAX)\n Value which indicates the proposer built the payload\n\n BUILDER_PAYMENT_THRESHOLD_NUMERATOR\n uint64(6)\n\n BUILDER_PAYMENT_THRESHOLD_DENOMINATOR\n uint64(10)\n\n Withdrawal prefixes\n\n Name\n Value\n Description\n\n BUILDER_WITHDRAWAL_PREFIX\n Bytes1('0x03')\n Withdrawal credential prefix for a builder\n\n Preset\n\n Misc\n\n Name\n Value\n\n PTC_SIZE\n uint64(2**9) (= 512)\n\n Max operations per block\n\n Name\n Value\n\n MAX_PAYLOAD_ATTESTATIONS\n 4\n\n State list lengths\n\n Name\n Value\n Unit\n\n BUILDER_REGISTRY_LIMIT\n uint64(2**40) (= 1,099,511,627,776)\n Builders\n\n BUILDER_PENDING_WITHDRAWALS_LIMIT\n uint64(2**20) (= 1,048,576)\n Builder pending withdrawals\n\n Withdrawals processing\n\n Name\n Value\n\n MAX_BUILDERS_PER_WITHDRAWALS_SWEEP\n 2**14 (= 16,384)\n\n Configuration\n\n Time parameters\n\n Name\n Value\n Unit\n\n MIN_BUILDER_WITHDRAWABILITY_DELAY\n uint64(2**6) (= 64)\n epochs\n\n Containers\n\n New containers\n\n Builder\n\nclass Builder(Container):\n pubkey: BLSPubkey\n version: uint8\n execution_address: ExecutionAddress\n balance: Gwei\n deposit_epoch: Epoch\n withdrawable_epoch: Epoch\n\n BuilderPendingPayment\n\nclass BuilderPendingPayment(Container):\n weight: Gwei\n withdrawal: BuilderPendingWithdrawal\n\n BuilderPendingWithdrawal\n\nclass BuilderPendingWithdrawal(Container):\n fee_recipient: ExecutionAddress\n amount: Gwei\n builder_index: BuilderIndex\n\n PayloadAttestationData\n\nclass PayloadAttestationData(Container):\n beacon_block_root: Root\n slot: Slot\n payload_present: boolean\n blob_data_available: boolean\n\n PayloadAttestation\n\nclass PayloadAttestation(Container):\n aggregation_bits: Bitvector[PTC_SIZE]\n data: PayloadAttestationData\n signature: BLSSignature\n\n PayloadAttestationMessage\n\nclass PayloadAttestationMessage(Container):\n validator_index: ValidatorIndex\n data: PayloadAttestationData\n signature: BLSSignature\n\n IndexedPayloadAttestation\n\nclass IndexedPayloadAttestation(Container):\n attesting_indices: List[ValidatorIndex, PTC_SIZE]\n data: PayloadAttestationData\n signature: BLSSignature\n\n ExecutionPayloadBid\n\nclass ExecutionPayloadBid(Container):\n parent_block_hash: Hash32\n parent_block_root: Root\n block_hash: Hash32\n prev_randao: Bytes32\n fee_recipient: ExecutionAddress\n gas_limit: uint64\n builder_index: BuilderIndex\n slot: Slot\n value: Gwei\n execution_payment: Gwei\n blob_kzg_commitments: List[KZGCommitment, MAX_BLOB_COMMITMENTS_PER_BLOCK]\n\n SignedExecutionPayloadBid\n\nclass SignedExecutionPayloadBid(Container):\n message: ExecutionPayloadBid\n signature: BLSSignature\n\n ExecutionPayloadEnvelope\n\nclass ExecutionPayloadEnvelope(Container):\n payload: ExecutionPayload\n execution_requests: ExecutionRequests\n builder_index: BuilderIndex\n beacon_block_root: Root\n slot: Slot\n state_root: Root\n\n SignedExecutionPayloadEnvelope\n\nclass SignedExecutionPayloadEnvelope(Container):\n message: ExecutionPayloadEnvelope\n signature: BLSSignature\n\n Modified containers\n\n BeaconBlockBody\n\nNote: The removed fields (execution_payload, blob_kzg_commitments, and\nexecution_requests) now exist in ExecutionPayloadEnvelope.\n\nclass BeaconBlockBody(Container):\n randao_reveal: BLSSignature\n eth1_data: Eth1Data\n graffiti: Bytes32\n proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]\n attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS_ELECTRA]\n attestations: List[Attestation, MAX_ATTESTATIONS_ELECTRA]\n deposits: List[Deposit, MAX_DEPOSITS]\n voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]\n sync_aggregate: SyncAggregate\n # [Modified in Gloas:EIP7732]\n # Removed `execution_payload`\n bls_to_execution_changes: List[SignedBLSToExecutionChange, MAX_BLS_TO_EXECUTION_CHANGES]\n # [Modified in Gloas:EIP7732]\n # Removed `blob_kzg_commitments`\n # [Modified in Gloas:EIP7732]\n # Removed `execution_requests`\n # [New in Gloas:EIP7732]\n signed_execution_payload_bid: SignedExecutionPayloadBid\n # [New in Gloas:EIP7732]\n payload_attestations: List[PayloadAttestation, MAX_PAYLOAD_ATTESTATIONS]\n\n BeaconState\n\nclass BeaconState(Container):\n genesis_time: uint64\n genesis_validators_root: Root\n slot: Slot\n fork: Fork\n latest_block_header: BeaconBlockHeader\n block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT]\n state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT]\n historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT]\n eth1_data: Eth1Data\n eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]\n eth1_deposit_index: uint64\n validators: List[Validator, VALIDATOR_REGISTRY_LIMIT]\n balances: List[Gwei, VALIDATOR_REGISTRY_LIMIT]\n randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR]\n slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR]\n previous_epoch_participation: List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT]\n current_epoch_participation: List[ParticipationFlags, VALIDATOR_REGISTRY_LIMIT]\n justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH]\n previous_justified_checkpoint: Checkpoint\n current_justified_checkpoint: Checkpoint\n finalized_checkpoint: Checkpoint\n inactivity_scores: List[uint64, VALIDATOR_REGISTRY_LIMIT]\n current_sync_committee: SyncCommittee\n next_sync_committee: SyncCommittee\n # [Modified in Gloas:EIP7732]\n # Removed `latest_execution_payload_header`\n # [New in Gloas:EIP7732]\n latest_execution_payload_bid: ExecutionPayloadBid\n next_withdrawal_index: WithdrawalIndex\n next_withdrawal_validator_index: ValidatorIndex\n historical_summaries: List[HistoricalSummary, HISTORICAL_ROOTS_LIMIT]\n deposit_requests_start_index: uint64\n deposit_balance_to_consume: Gwei\n exit_balance_to_consume: Gwei\n earliest_exit_epoch: Epoch\n consolidation_balance_to_consume: Gwei\n earliest_consolidation_epoch: Epoch\n pending_deposits: List[PendingDeposit, PENDING_DEPOSITS_LIMIT]\n pending_partial_withdrawals: List[PendingPartialWithdrawal, PENDING_PARTIAL_WITHDRAWALS_LIMIT]\n pending_consolidations: List[PendingConsolidation, PENDING_CONSOLIDATIONS_LIMIT]\n proposer_lookahead: Vector[ValidatorIndex, (MIN_SEED_LOOKAHEAD + 1) * SLOTS_PER_EPOCH]\n # [New in Gloas:EIP7732]\n builders: List[Builder, BUILDER_REGISTRY_LIMIT]\n # [New in Gloas:EIP7732]\n next_withdrawal_builder_index: BuilderIndex\n # [New in Gloas:EIP7732]\n execution_payload_availability: Bitvector[SLOTS_PER_HISTORICAL_ROOT]\n # [New in Gloas:EIP7732]\n builder_pending_payments: Vector[BuilderPendingPayment, 2 * SLOTS_PER_EPOCH]\n # [New in Gloas:EIP7732]\n builder_pending_withdrawals: List[BuilderPendingWithdrawal, BUILDER_PENDING_WITHDRAWALS_LIMIT]\n # [New in Gloas:EIP7732]\n latest_block_hash: Hash32\n # [New in Gloas:EIP7732]\n payload_expected_withdrawals: List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD]\n\nThe BeaconState container is modified with the addition of:\n\n builders, of type List[Builder, BUILDER_REGISTRY_LIMIT] to track the new in-protocol staked builders.\n next_withdrawal_builder_index of type BuilderIndex to help tracking builder withdrawals.\n execution_payload_availability, of type Bitvector[SLOTS_PER_HISTORICAL_ROOT] to track the presence of execution payloads on the canonical chain.\n builder_pending_payments, of type Vector[BuilderPendingPayment, 2 * SLOTS_PER_EPOCH] to track pending payments from builders to proposers before the execution payload has been processed.\n builder_pending_withdrawals, of type List[BuilderPendingWithdrawal, BUILDER_PENDING_WITHDRAWALS_LIMIT] to track pending withdrawals to the execution layer with the builders’ payments.\n latest_block_hash, of type Hash32, to track the blockhash of the last execution payload in the blockchain.\n payload_expected_withdrawals of type List[Withdrawal, MAX_WITHDRAWALS_PER_PAYLOAD] to track the latest withdrawals that were deducted in the consensus layer and need to still be honored in the Execution Layer.\n\nThe BeaconBlockBody is modified with the addition of:\n\n signed_execution_payload_bid of type SignedExecutionPayloadBid with the builder’s commitment.\n payload_attestations of type List[PayloadAttestation, MAX_PAYLOAD_ATTESTATIONS] a list of PTC attestations from the previous slot.\n\nThe ExecutionPayloadHeader object is changed (and renamed to ExecutionPayloadBid) to only track the minimum information needed to commit to a builder’s payload.\n\nState transition logic is modified by:\n\n A new beacon state getter get_ptc returns the PTC members for a given slot.\n process_withdrawals is modified as follows. Withdrawals are obtained directly from the beacon state instead of the execution payload. They are deducted from the beacon chain. The beacon state latest_withdrawals_root is updated with the HTR of this list. The next execution payload MUST include withdrawals matching the state.latest_withdrawals_root.\n process_execution_payload is removed from process_block. Instead a new function process_execution_payload_bid is included, this function validates the SignedExecutionPayloadBid included in the BeaconBlockBody, ensures the payment from the builder’s balance can be deducted and adds a BuilderPendingPayment object to the beacon state.\n process_deposit_request is removed from process_operations and deferred until process_execution_payload. Special care is added for deposit requests from new validator pubkeys, with withdrawal credentials starting with the prefix BUILDER_WITHDRAWAL_PREFIX. These deposits are immediately added to the beacon chain and processed as new builders.\n process_withdrawal_request is removed from process_operations and deferred until process_execution_payload.\n process_consolidation_request is removed from process_operations and deferred until process_execution_payload.\n A new process_payload_attestation is added to process_operations, this function validates the payload timeliness attestations broadcast by the PTC members.\n process_execution_payload is now called as a separate helper when receiving a SignedExecutionPayloadEnvelope on the P2P layer. This function in particular checks that the HTR of the resulting beacon state coincides with the committed one in the payload envelope. On sucessful processing of the execution payload, the corresponding BuilderPendingPayment is removed from the beacon state and a BuilderPendingWithdrawal is queued.\n\nEpoch processing is modified by addition of a new helper function process_builder_pending_payments, that processes the builder pending payments from those payloads that were not included in the canonical chain. \nAlthough there is no change in the AttestationData object, the index field which is unused since the Electra fork, is now repurposed to signal payload availability. The value of 0 is used when attesting to the current beacon block or a past beacon block without a payload present, and the value of 1 is used to attest to a past beacon block with a payload present.\n\n Fork-Choice changes\n\nForkchoice is changed substantially to deal with the fact that forkchoice nodes can have different payload content.\n\n P2P changes\n\n A new global topic for broadcasting SignedExecutionPayloadBid messages (builder bids).\n A new global topic for broadcasting PayloadAttestationMessage objects.\n A new global topic for broadcasting ProposerPreferences objects.\n\n Engine API\n\nNo changes needed.\n\n Rationale\n\n Staked builders\n\nBeing a builder is a new type of entity tracked in the beacon state. As such builders are staked in the beacon chain and they have their own withdrawal credential prefix. This allows for in-protocol trustless enforcement of the builder’s payment to the proposer. Alternatively, payment could be enforced in the Execution Layer (EL) at the cost of adding the corresponding EL consensus-changing logic. Payments in the EL have the advantage of not requiring the builder to periodically submit deposit transactions to replenish their validator balance. Both systems require availability of funds before the payload is revealed: in the Consensus Layer (CL) this is done by getting builders to stake. In the EL this is done with a balance check and a payment transaction. This transaction can be checked without executing the payload only if it the first transaction of the block.\n\n Delayed validation\n\nThe Payload Timeliness Committee members do not need to validate the execution payload before attesting to it. They perform basic checks such as verifying the builder’s signature, and the correct blockhash is included. This takes away the full execution payload validation from the hot path of validation of an Ethereum block, giving the next proposer 6 seconds (SECONDS_PER_SLOT * 2 // INTERVALS_PER_SLOT) to validate the payload and every other validator 9 seconds (SECONDS_PER_SLOT * 3 // INTERVALS_PER_SLOT). From a user UX perspective, a transaction included in slot N by the builder is not widely validated until the proposer of slot N+1 releases their beacon block on top of block N first and the attesters of slot N+1 vote on this beacon block as the head of the chain.\n\n Fork choice\n\nThe following features of fork choice are guaranteed under specified margins of security:\n\n Proposer unconditional payment.\n Builder reveal safety.\n Builder withhold safety.\n\nProposer unconditional payment refers to the following. An Ethereum slot can be either:\n\n Full: both the beacon block and the execution payload have been revealed and included on-chain.\n Skipped: No beacon block (and therefore no execution payload) has been included on-chain for this slot.\n Empty: The beacon block has been included on-chain, but the committed execution payload has not.\n\nProposer unconditional payment refers to the fact that in the third scenario the beacon block proposer received payment from the corresponding builder.\n\nBuilder reveal safety refers to the fact that if the builder acted honestly and revealed a payload in a timely fashion (as attested by the PTC) then the revealed payload will be included on-chain.\n\nBuilder withhold safety refers to the fact that if some beacon block containing a builder’s commitment is withheld and revealed late, the builder will not be charged the value of the bid. In particular, the payload does not even need to be revealed in this case.\n\nThe precise method by which these safety mechanisms are enforced is by allowing attestations to also signal their view of the slot as in either of the above options Full, Skipped or Empty. For this, the index field in the AttestationData is used as explained above.\n\n PTC equivocations\n\nThere is no penalty for PTC nor payload equivocation (that is revealing the right payload and also a withheld message at the same time). A collusion of a builder controlling network partition with a single malicious PTC member could cause a split view by achieving consensus both on payload withheld and a payload present. This could be mitigated by setting PAYLOAD_TIMELY_THRESHOLD to be 2/3 of the PTC, in which case the malicious operator would have to control at least 33% of the PTC.\n\nAnother mitigation mechanism is to add new slashing conditions for payload equivocation or PTC equivocations (both are signed messages by validators).\n\nSince this attack results in a split view at a cost for the builder (the payload is revealed and may not be included) this EIP opted for simplicity of implementation.\n\n Withdrawals\n\nWithdrawals from the beacon chain are complex in nature, they involve removing funds from one layer and crediting them on another, with different trigger mechanisms that can start from either layer. Before applying the consensus layer state transition function to a given beacon state pre_state and processing a given signed beacon block block, the set of withdrawals that are expected to be deducted from the beacon chain are completely determined by pre_state. Previous to this EIP the set of withdrawals that are credited on the execution layer are included in block. The block is deemed invalid if these withdrawals do not match. With the separation included in this EIP, these operations of deducting and crediting become asynchronous:\n\n When processing the beacon block, the withdrawals are deducted from the beacon chain.\n The set of withdrawals just deducted is committed to the beacon state post_state.\n When processing any execution payload whose parent beacon state is post_state, the payload is deemed invalid if it doesn’t include precisely the list of withdrawals committed to post_state.\n\nThis asynchronous mechanism has some consequences as slots may be empty as defined above. In these cases, the consensus layer does not process any more withdrawals until an execution payload has fulfilled the outstanding ones. An alternative design would be to defer all of withdrawal processing to the execution payload validation phase (ie. process_execution_payload). This has the advantage of not needing to track the fulfilled withdrawals on the beacon chain. The logic changes when several payloads are missing, in which case balances on the beacon chain change and therefore a withdrawal that would be possible with the former mechanism may be different, or even impossible with the latter.\n\n Three state transition functions\n\nThe current EIP adds an extra state transition function to the block processing in Ethereum. Processing a SignedBeaconBlock changes the consensus layer BeaconState. A SignedExecutionPayloadEnvelope changes both the execution layer state and the consensus layer one. As such, the envelope commits to the consensus layer post-state-transition beacon state root.\n\n Compatible designs\n\n Inclusion lists\n\nThis EIP is fully compatible with forkchoice enforced inclusion lists or similar.\n\n Slot auctions\n\nA simple change to this EIP is to remove the blockhash commitment from the SignedExecutionPayloadBid. This allows the builder to commit any payload to the slot. A preliminary security analysis shows that payload equivocation does not weaken fork choice’s FFG. Some advantages of Slot auctions include:\n\n Better user experience as any submitted transaction can be included in the next block (with block auctions a transaction sent in the first half of the slot can only be included in the following block).\n Longer continuous time to build blocks.\n Better compatibility designs with fork choice enforced inclusion list proposals.\n\n Backwards Compatibility\n\nThis EIP introduces backward incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork.\n\n Security Considerations\n\n Free option problem\n\nEconomically rational but malicious (as defined by the honest builder guide) builders may chose to withhold their payload in the event that it would be profitable for them. This could result in missed slots and degradation of user experience of Ethereum. Some preliminary data in the form of simulation suggests that the number of these occurrences may be noticeable. Some mitigations were proposed in the form of variable penalties for builders that fail to include their payload envelopes in the canonical chain.\n\n Builder safety\n\n A colluding set of proposers and attesters controlling consecutive blocks and more than 20% of the total stake can reorg a builder’s payload and force it to pay the bid’s value.\n There is no possible unbundling of the builder’s payload in the same slot, that is, if the builder reveals a payload for the head of the chain, no other payload is possible for the current slot.\n\n Malicious PTC\n\nThe expected time for a malicious attacker, controlling 35% of the total stake, to have a majority control on the PTC is 205 000 years.\n\n Copyright\n\nCopyright and related rights waived via CC0.\n\n Citation\n Please cite this document as:\n\n Francesco D'Amato <francesco.damato@ethereum.org>, Nico Flaig <nflaig@protonmail.com>, Barnabé Monnot <barnabe.monnot@ethereum.org>, Michael Neuder <michael.neuder@ethereum.org>, Potuz (@potuz), Justin Traglia <jtraglia@ethereum.org>, Terence Tsao <ttsao@offchainlabs.com>, \"EIP-7732: Enshrined Proposer-Builder Separation [REVIEW],\" Ethereum Improvement Proposals, no. 7732, June 2024. Available: https://eips.ethereum.org/EIPS/eip-7732.","tokens":6403,"squid":"ink-developer_specs","role":"Spec Keeper","at":1791268491676,"hash":"027cf2040efd9a5b33dd9f2af2e5544e5ccc7c60"}
{"url":"https://ethresear.ch/t/decoupling-throughput-from-local-building/22004","domain":"ethresear.ch","title":"Decoupling throughput from local building - Proof-of-Stake / Economics - Ethereum Research","text":"Decoupling throughput from local building \n\n Proof-of-StakeEconomics\n\n protocol-research-call\n\n You have selected 0 posts.\n\n select all\n\n cancel selecting\n\n 6\n\n 2\n\n 2\n\n read \n\n 14\n min\n\n Mar 2025\n\n 1 / 14\n\n Mar 2025\n\n May 2025\n\n post by barnabe on Mar 25, 2025\n\n barnabe\n\n Many thanks to Alex Stokes, Ansgar Dietrichs, Carl Beekhuizen, Caspar Schwarz-Schilling, Dankrad Feist, Data Always, Drew van der Werff, Eric Siu, Francesco d’Amato, Jihoon Song, Julian Ma, Justin Drake, Ladislaus von Daniels, Mike Neuder, Nixo, Oisín Kyne, Parithosh Jayanthi, Potuz, Sacha Saint-Leger, Terence Tsao, Thomas Thiery, Tim Beiko, Toni Wahrstätter for their comments and reviews (these are not endorsements). I bothered a lot of people lol.\n\nThere are important conversations the Ethereum community should have in the next months: What to make of local building? What is the future of the validator set? How to scale the L1? How to scale the blobs so the L2s can scale?\nTo make these decisions, we need to clarify what the goals of Ethereum are, and what are means for us to achieve goals such as censorship-resistance, security (e.g., safety + liveness), scale or verifiability. Given recent advances in protocol R&D, we want to engage in efforts to explore how these features further the goals of our users and builders.\nThis note discusses local building and asks:\nTo scale the L1 and provide more blobs for rollups, should we decouple network throughput from what local builders with minimal hardware achieve, and if so, can we still preserve the good properties that local builders guarantee?\nWe propose to curate a wider discussion through writings and open discussions in a new “Protocol research call”. See the announcement over at ethereum-magicians! See also “Paths to SSF revisited”, a second post discussing the role of home operators in the consensus layer, also discussed during the Protocol research call #1.\nProtocol roles and service providers\nIn this note and following, we will be concerned with protocol roles, such as attester or builder, which are functions expected by the protocol to be fulfilled. The party responsible for fulfilling a role is a service provider, ultimately represented by a node on the Ethereum network. Assigning the right node to the right role is derived from understanding what the system needs to optimise for, and how much various nodes contribute to these objectives given their resources.\nValidator services map2830×1572 384 KB\nA staking node is expected to fulfil the roles above, or may be expected to (the FOCIL role does not currently exist, and is discussed below).\nWe want every node on the network meeting certain hardware requirements to always be able to verify the availability and validity of Ethereum. This is a non-negotiable constraint. A node with the most basic resources meeting the hardware requirements may be called a minimal node. A node controlling a validator—a protocol role bundling the functions of attester, proposer, sync committee and others—is called a staking node.\nIn this note, we discuss how to tap into the asymmetry between verifying and building. Building is the act of appending data to the ledger, whether transactions or blobs. Verifying is the act of receiving this data and convincing oneself that the data is available (“I know that all of the data published by the builder can be recovered somewhere on the network”) and valid (“The data follows protocol rules, e.g., transactions included in blocks must be valid”). Building supplies throughput to the network, i.e., supplies the gas and blobs delivered per unit of time. Verifying limits this throughput, to the quantity that can be verified by nodes before they must perform other tasks such as attesting.\nExternal building1920×1063 76.4 KB\nThe builder role was mostly externalised by staking nodes to external building nodes.\nThe asymmetry of verifying and building\nToday, the hardware requirements are set such that minimal nodes are always able to verify the chain fully, and perform validating duties including producing FFG attestations for finalizing the chain, and LMD-GHOST attestations for updating the fork-choice rule. The target throughput of the chain is set such that minimal nodes are able to supply this throughput entirely, i.e., make blocks delivering up to the target throughput (and its corresponding limit).\nCoupled throughput2080×1356 138 KB\nMinimal nodes satisfying precisely the minimum validating requirements are able to run a validator.\nYet in more and more places, we have a strict asymmetry between verifying and building. There is a potential future, where a node that has the most basic resources and still meets hardware requirements stops focusing on anything related to building and just verifies. The builder in this model would handle requirements around significant throughput potentially required to scale blocks and blobs.\nWith PeerDAS for instance, a builder with 8x resources could create an 8x larger block that a 1x attesting node fully verifies with a fraction of the builder’s resources. While the builder must upload the blobs themselves, 8x more data in the worst case, (if minimal attesting nodes have not received the blobs in their own mempools previously), a minimal attesting node must only download 1x the amount to verify availability and perform its duties properly. We could then allow building nodes with strictly higher upload bandwidth to disseminate this data, while attesting nodes require only a fraction of this bandwidth to verify that the data is available and gossip it to their peers.\nAnother example of where we expect a large asymmetry will occur when the L1 EVM is snarkified. Then, the major cost of building a block will consist in generating a proof of its validity, while every other node on the network needs only ensure that the block data is available (you can think of dumping the block in a blob, with availability checks becoming even lighter as we move towards full DAS) and making a constant-time computation to verify the proof of validity. This future may be much closer than we think, and as a thought experiment, should we make nothing of the massive resource asymmetry between building a zkEVM-proven block and verifying it? This should clue us in to the fact that asymmetries are scaling opportunities, and lead us to ask whether they are to be acted upon in more immediate places, such as scaling blob throughput.\nDecoupled throughput1920×1249 75.9 KB\nWhile we have a broad base of many staking nodes performing the attestation service, there are fewer, better-resourced (in compute, bandwidth, or order flow) building nodes in the network. Could the target throughput be increased given the existence of these building nodes?\nThree network properties to achieve\nSo far, we have kept network throughput to a level that all staking nodes could achieve while performing the building role. We spell out three network properties that we wish to satisfy, guiding our hand in designing network architecture:\n\nCensorship-resistance of the network: We want any fee-paying transaction to be included given that throughput is available for this transaction to be included.\nTarget throughput achievement: Suppose the Ethereum network sets some target throughput, by setting the EIP-1559 gas and EIP-4844 blob targets. We may ignore the reasons why this amount of throughput was set, we just take as given that there is some target that is now given to us. Can we be satisfied with high probability that the network will achieve this throughput, without leading to bad outcomes such as an implicit increase in minimal hardware requirements?\nBlock production liveness: No single party or colluding group of parties should be able to halt the progression of the chain, e.g., by being the only parties able to deliver a valid block to the network.\n\nWhen a staking node does not delegate its building function to a separate external builder, we call the node a local builder. The presence of local builders buys us a lot in terms of the three network properties:\n\nCensorship-resistance of the network: Local builders are part of the validator set, which is assumed to be decentralised enough to provide good censorship-resistance. When external builders censor, assuming that some local builders keep producing blocks, the chain preserves some (possibly lower) censorship-resistance.\nTarget throughput achievement: Today, throughput is set such that local builders are always able to achieve it, so we have a pretty good guarantee that it will be achieved, given that every external builder has at least equal capabilities.\nBlock production liveness: A local builder can always make a valid block, so we are also confident that there will always be a builder (either local or external) who is able to progress the chain.\n\nEffects of decoupling throughput from local builders\nWhat would happen if network throughput was now set to a level higher than minimal local builders could achieve? The first property may be the most hurt, as local builders could not be able to provide throughput at the target quantity. Yet this throughput may be recovered by external builders, as EIP-1559 targets and achieves some fixed amount. It is notable that already today, local builders are on average unable to provide throughput at the current target, given the depletion of the public mempool in favour of private pools (see analysis by Data_Always). The two remaining properties would not be more hurt under this hypothetical scenario than today, as local builders under a higher network throughput could still propose blocks at today’s throughput, guaranteeing minimal liveness, and include potentially censored transactions at a lower throughput.\nWe may still find this situation uncomfortable: If we wish for local builders to remain economically competitive with externally-building nodes, we should ask them to delegate their building function. But if we ask them to do so, we may not feel comfortable with the quality of any of the three properties above. So if we want to decouple network throughput from what can be provided by local builders, we must ensure that we still achieve these three properties. We discuss each of them in the following sections.\nCensorship-resistance of the network\nWith EIP-7805: Fork-choice enforced Inclusion Lists (FOCIL), we believe that the censorship-resistance property is essentially guaranteed at network level, in the sense that formerly-locally-building validators can achieve the provision of at least as much (but in practice much more) censorship-resistance through FOCIL than with local building.\nThe FOCIL mechanism selects 16 new includers from the validator set every slot, and each includer is able to propose a list of transactions which must conditionally be included in the block proposed for this slot. These inclusion lists constrain the proposer of the current slot, or their chosen builder, preventing them from arbitrarily excluding transactions from the network.\nFOCIL1000×760 196 KB\nFOCIL chooses 16 includers every slot to impose constraints on the block-building process.\nFOCIL allows staking nodes who decide not to be local builders anymore, delegating their building function to the external builder market, to still participate in the provision of censorship-resistance. Local builders do not need to pick between locally building to provide censorship-resistance or using external builders to maximise their rewards, they can do both.\nFOCIL is not currently deployed, and we are still required to choose a design that extends FOCIL to blobs.\nTarget throughput achievement\nThe target network throughput must still be carefully chosen by the network in order to prevent builders from delivering blocks that become increasingly hard to verify by minimal nodes. As a thought experiment, could we simply remove the gas limit and let the builder (either local or external) decide the size of the block they want to produce? We would have two issues:\n\nThe builder may output blocks that can barely be verified by minimal nodes. As long as the block receives sufficient attestations, it may be enough for it to be part of the canonical chain. But it could lead to an arms race where the requirements made on minimal nodes become no longer enough to attest properly, increasing the expectations on minimal nodes to beef up their hardware beyond the minimal specs. Note that zkEVMs for instance could alleviate this, in that any gas supplied by the builder, as long as it also comes with a proof, incurs a constant verification cost on the verifying nodes. This may not hold for blobs and data availability, for which throughput increases must always be matched with increasing verification resources in the aggregate.\nThere is a tragedy of the commons where some externalities of a large block are only felt over time, e.g., state growth or node syncing time.\n\nI may be able to deliver a very large block now, that gets enough attestations, but my doing so increases the state size for everyone in the future, and makes it harder to achieve a consistent throughput over time. Note that stateless architectures may partially alleviate this issue.\nBy delivering bigger blocks, I would also increase the sync time necessary for new nodes to catch up to the head of the chain. Again, a combination of validity proofs and statelessness can alleviate this issue.\n\nBlock production liveness\nRelying on an external network means that its failures become the system’s failures. Inherent to the nature of delegation, we can never entirely control the actions of the building “agents” chosen by our staking node “principals”, or prevent them from failing. But ultimately, staking nodes themselves are agents to the protocol, and could fail themselves, or miss the mark in providing what the protocol seeks to supply. So the question we should ask is how far can we go and how far are we willing to go to mitigate these risks?\nThere are two broad approaches to obtain these mitigations: Improving out-of-protocol infrastructure or adding new features in-protocol. Proposer-Builder Separation (PBS) is instantiated today by out-of-protocol MEV-Boost and Commit-Boost, with relays taking on the role of trust anchors to access the market. PBS would be strengthened with in-protocol EIP-7732: Enshrined Proposer-Builder Separation (ePBS). Using ePBS, we can provide better guarantees for the market participants, i.e., the staking nodes on one side and the external builders on the other side, as the protocol guarantees the fair exchange between the two.\nTo understand what is needed, we must understand the risks and failures of delegating the building role. We can never completely rule out the bad case of a “timeout” liveness failure, where the builder does not deliver the block even after a contract is struck between a staking node and the builder. We may have more systemic risks, where the interface to the external market fails. And we may have a cartel of builders refusing to build any block for anyone, unless the staking nodes paid them some sort of extortion rent.\nWe now give some arguments to guide our hand in choosing the required arsenal of defences:\n\nStaking nodes can adapt their behaviour to repeated failures of the external market, e.g., by a falling back on local building via a circuit breaker.\nWe can ensure that if a deal is struck and the builder fails to deliver, the payment still proceeds. There are multiple ways to guarantee this with in-protocol solutions. If the relay itself doesn’t fail, some optimistic relays also require an escrow payment from the builder, to compensate for failures of the builder to deliver as promised.\nWe could take the view that liveness of the block construction process assumes a particular realisation of the user demand, and strictly ask whether given a particular set of transactions available to be built, some building party will take up the job. In other words, we may care about the existence of any one single builder who can do at least as well as the staking node itself, and if the staking node does not receive most user transactions (who may prefer to transit via private pools), decide that it is not an issue with the block production liveness. Still, order flow remains a determinant factor in the success of builders. A market dominated by few entrenched entities could potentially discourage the entry of more participants, even as temporary fallbacks when liveness of the few dominant entities is in doubt. The presence of neutral relays increases the entry points into the market, favouring such fallbacks. Additionally, with the emergence of new protocols such as BuilderNet, we observe more innovation in the builder market towards neutral infrastructure, at least in its idealised form.\nThere are ways to harden the current out-of-protocol infrastructure, e.g., ensuring sufficient diversity with both MEV-Boost and Commit-Boost, which are both neutral pieces of software, or improving our circuit-breaker and fallback routines to minimise liveness risk should failures occur somewhere along the chain.\nThere is a true worst case where only a few nodes in the world can build the block required by the network. This is somewhat theoretical, as there are not many cases where a staking node could be forced into a position where only a few parties could satisfy the building requirements imposed on the node. A strawman is imagining FOCIL outputting a very large set of transactions and blobs to include, perhaps under a zkEVM regime where the block must additionally receive a validity proof. If the staking node itself cannot build this block themselves (and this is entirely possible if network throughput is decoupled from local builder capabilities), the staking node will be required to rely on an external builder. We should ensure that this reliance is as wide as possible, i.e., that there always exists a builder ready to deliver this block. This is not the case if we can find ourselves in a situation where only super computer-sized nodes are able to deliver, for some reason, but this can be easily mitigated by setting a network throughput limit to a level that guarantees a wide enough market, even if this limit exceeds the capabilities of local builders.\nGoing in-protocol is costly, in added complexity to the protocol mainly, especially on the path to reducing slot times and changing the consensus mechanism towards SSF. There are also questions regarding the future-proofness of any single mechanism given alternative proposals such as Attester-Proposer Separation. We typically want to have in protocol the features that require honest majority, e.g., the consensus mechanism, getting the full force of a large set of participants to bear on the safekeeping of this property. Meanwhile, obtaining a valid block from a builder requires a 1-out-of-N honesty assumption, as a single builder needs to be live to perform the service at the moment it is required. Given the 1-of-N honesty assumption, relying only on out-of-protocol solutions for delegating block building could be reasonable.\n\nThere is no easy answer on which combination of solutions to deploy here, especially as the argument for ePBS is not solely about hardening the exchange between staking nodes and builders, but also about scaling by providing better pipelining (note that for the scaling argument, it should be considered in the context of alternative and/or complementary approaches such as delayed execution, a topic for a future note/call).\nWhat we should talk about\nOverall, there are two independent discussions to have:\n\nDeciding whether to decouple network throughput from what local builders can achieve. Arguments were made above, discussing how the three properties fare in this context, and how they could be improved with new mechanisms such as FOCIL.\nDeciding how to ensure block production liveness. While this is a wide spectrum, we see broadly two ways to move forward, which are not mutually exclusive:\n\nDoing more in-protocol: By deploying protocol infrastructure such as ePBS, we strengthen access to the external builder market.\nImproving out-of-protocol options: Perhaps we are happy enough with keeping this builder interface out of the protocol, and letting staking nodes decide on their approach.\n\nLocal building is a means of obtaining liveness of the block production service, as well as censorship-resistance. Local building is also a constraint on throughput, if we decide to couple our throughput to the highest level that can be provided by the worst nodes on the network. This is a reasonable choice if local building is our only tool to get liveness of blocks as well as censorship-resistance. But if it is not the only tool, or the best one, we should ask ourselves: Could we move the network throughput beyond what local builders are able to provide, as long as all nodes remain able to sustainably verify the chain at this throughput? What changes or improvements would we need to make in order to feel comfortable with that demand?\n\nSee also a recent talk on this topic.\n\n Paths to SSF revisited\n\n On Ethereum Prover Market Design\n\n A local-node-favoring delta to the scaling roadmap\n\n Prover Killers Killer: You Build it, You Prove it\n\n Blob Notaries: a distributed blob publishing design to scale DA\n\n 6\n\n 2\n\n 2\n\n read \n\n 14\n min\n\n post by come-maiz on Mar 25, 2025\n\n post by benaadams on Mar 25, 2025\n\n post by barnabe on Mar 26, 2025\n\n post by barnabe on Mar 26, 2025\n\n post by benaadams on Mar 26, 2025\n\n post by VaibhavVasdev on Mar 28, 2025\n\n post by keyneom on Apr 2, 2025\n\n post by CPerezz on Apr 3, 2025\n\n post by barnabe on Apr 3, 2025\n\n post by barnabe on Apr 3, 2025\n\n 26 days later\n\n post by MicahZoltu on Apr 30, 2025\n\n post by barnabe on May 1, 2025\n\n post by MicahZoltu on May 1, 2025\n\n Powered by Discourse","tokens":5471,"squid":"ink-research","role":"Deep Scholar","at":1791268494643,"hash":"37cdff195569f92b0ac7f7921d2dfb19a4b88c26"}
{"url":"https://io.net/privacy","domain":"io.net","title":"io.net | Decentralized GPU Cloud","text":"Privacy PolicyLast updated: August 18th 2025 1. About this Privacy Policy\nThis Privacy Policy is part of the IO.NET Terms of Service at https://io.net/terms. All terms, conditions, and terminology are consistent with the Terms of Service, and the Terms of Service are incorporated into this document by reference.\nThis policy governs the use of the IO.NET website at https://io.net and the associated tools and services.\nCollectively, the website and the associated tools and services are referred to as the \"Services\" in these terms. The operator may offer other products and services.\nIn addition to the website and the associated tools and services, the Services include:\n\nBC8.ai\n\nThe Services do not include outside websites or platforms that may be linked or interconnected to the Services. Such outside platforms may have their own terms of service, which control all transactions on such platforms.\nIO.NET Inc., a Delaware corporation, operates the Services. It and its affiliates are referred to in this document as the \"operator,\" \"we,\" or \"us.\"\n 2. The Blockchain\nBlockchain technology, also known as distributed ledger technology (or simply 'DLT'), is at the core of our business. Blockchains are decentralized and made up of digitally recorded data in a chain of packages called 'blocks'. The manner in which these blocks are linked is chronological, meaning that the data is very difficult to alter once recorded. Since the ledger may be distributed all over the world (across several 'nodes' which usually replicate the ledger) this means there is no single person making decisions or otherwise administering the system (such as an operator of a cloud computing system), and that there is no centralized place where it is located either.\nThis means that by design, a blockchain's records cannot be changed or deleted and is said to be 'immutable'. This may affect your ability to exercise your rights such as your right to erasure ('right to be forgotten'), or your rights to object or restrict processing, of your personal data. Data on the blockchain can't be erased or changed. Although smart contracts may be used to revoke certain access rights, and some content may be made invisible to others, it is not deleted.\nIn certain circumstances, in order to comply with our contractual obligations to you (such as delivery of tokens) it will be necessary to write certain personal data, such as your wallet address, onto the blockchain; this requires you to execute such transactions using your wallet's private key.\nIn most cases ultimate decisions to (i) transact on the blockchain using your wallet address, as well as (ii) share the public key relating to your wallet address with anyone (including us) rests with you.\nIf you want to ensure your privacy rights are not affected in any way, you should not transact on blockchains as certain rights may not be fully available or exercisable by you or us due to the technological infrastructure of the blockchain. The blockchain is available to the public and any personal data shared on the blockchain will become publicly available.\n 3. Children and minors\nAs per our Terms of Service, individuals under the age of 18 are not permitted to use the Services. As such, we do not knowingly collect, solicit, or maintain personal data from anyone under the age of 18 or knowingly allow such persons to register for the Services.\nIn the event that we learn that we have collected personal data from an individual under the age of 18, we will use commercially reasonable efforts to delete that information from our database. Please contact us if you have any concerns. If you are a parent or guardian and you are aware that your child has provided personal data to the Services, please contact us so that we may remove such data. Note that we cannot delete information stored on public cryptographic blockchains.\n 4. Collecting\n 4.1. Things you and others do and provide.\nInformation and content you provide. We collect the content, communications, and other information you provide when you use our Services, including when you create an account, initiate the use of the Services, create or share content, and message or communicate with others. This information may include, but is not limited to:\n\nName\nEmail\n\nFinancial information. In order to transfer funds, you may need to provide us and our third-party financial providers or partners with certain account and other payment information, such as information needed to make payment via ACH, wire, electronic checks, cryptocurrency, foreign currency, or any other payment methods. You may agree to your personal and financial information being transferred, stored, and processed by such third parties in accordance with their respective privacy policies.\n\nYour usage. We collect information about how you use our Services, such as the types of content you view or engage with; the features you use; the actions you take; the people or accounts you interact with; and the time, frequency, and duration of your activities.\n\nInformation about transactions made on our Services. If you use our Services for transactions of any kind, we collect information about them.\n\nThings others do and information they provide about you. We also receive and analyze content, communications, and information that other people provide when they use our Services.\n\n 4.2. Cookies\nWe, and our partners, use cookies and similar technologies to give you the best possible content and experience. Cookies are used to remember you and to collect information about how you interact with the Services. If you have an account with the Services, we may link this usage data with other information. You may have the option to either accept or refuse these cookies. If you choose to refuse, you may not be able to use some portions of the Services.\n 4.3. Device Information\nAs described below, we collect information from and about the computers, phones, and other web-connected devices you use that interact with our Services, and we combine this information across different devices you use.\nInformation we obtain from these devices may include:\n\nDevice attributes: information such as the operating system, hardware and software versions, battery level, signal strength, available storage space, browser type, app and file names and types, and plugins.\n\nDevice operations: information about operations and behaviors performed on the device, such as whether a window is foregrounded or backgrounded, or mouse movements (which can help distinguish humans from bots).\n\nIdentifiers: unique identifiers, device IDs, and other identifiers.\n\nNetwork and connections: information such as the name of your mobile operator or ISP, language, time zone, IP address, connection speed, and, in some cases, information about other devices that are nearby or on your network.\n\nCookie data: data from cookies stored on your device, including cookie IDs and settings.\n\n 4.4. When using the Services\nWhen using the Services, we may collect and process personal data. The data will be stored in different instances. We collect and use this information to provide you with the Services and to debug issues and provide support.\n\nOn the Blockchain the following data may be stored:\n\naddresses of externally owned accounts\ntransactions made; and\ntoken balances.\n\nThe data will be stored on the Blockchain. Given the technological design of the blockchain, this data will become public and it will not likely be possible to delete or change the data at any given time.\nIn our web servers, we will store the following data:\n\naddresses of externally owned accounts; and\ntransactions made.\n\nLog Data\n\nthe Internet protocol address (\"IP address\"); and\ntransaction id/ Hash.\n\n 5. Tracking and Uses\nWe use the information we have (subject to choices you make) as described below and to provide and support the Services. Here's how:\n 5.1. Provide, personalize, and improve our Services.\nWe use the information we have to deliver our Services, including to personalize features and content.\n\nInformation across devices: We connect information about your activities on different devices to provide a more tailored and consistent experience.\n\nLocation-related information: We use location-related information to improve our Services.\n\nProduct research and development: We use the information we have to develop, test, and improve our Services, including by conducting surveys and research, and testing and troubleshooting new products and features.\n\nAds and other sponsored content: We use the information we have about you – including information about your interests, actions, and connections – to select and personalize ads, offers, and other sponsored content that we show you.\n\n 5.2. Provide measurement, analytics, and other business services.\nWe use the information we have (including your activity on our Services) to help advertisers and other partners measure the effectiveness and distribution of their ads and services and understand the types of people who use their services and how people interact with their websites, apps, and services.\nThe Services use Amplitude to gather information about their use. Amplitude collect information such as how often users visit this site, what pages they visit when they do so, and what other sites they used prior to coming to this site. The Services use the information we get from Amplitude only to improve this site. Amplitude collect only the IP address assigned to you on the date you visit this site, rather than your name or other identifying information.\n 5.3. Promote safety, integrity, and security.\nWe use the information we have to verify accounts and activity, combat harmful conduct, detect and prevent spam and other bad experiences, maintain the integrity of our Services, and promote safety and security.\n 5.4. Communicate with you.\nWe use the information we have to send you marketing communications, communicate with you about our Services, and let you know about our policies and terms. We also use your information to respond to you when you contact us.\nBecause recognition of the Do Not Track HTTP header feature of your web browser is not standardized, the Services don't recognize it for tracking purposes.\n 6. Third-Party Data Collection\nThird parties may collect or receive certain information about you and/or your use of the Services to provide content, ads (including personalized ads), or functionality, or to measure and analyze ad performance, in or through the Services. These third parties include:\n\nGoogle (Terms, Privacy Policy)\nCloudflare (Terms, Privacy Policy)\nVercel (Terms, Privacy Policy)\nAWS (Terms, Privacy Policy)\nAuth0 (Terms, Privacy Policy)\nAmplitude (Terms, Privacy Policy)\nStripe (Terms, Privacy Policy)\nSlack (Terms, Privacy Policy)\nDiscord (Terms, Privacy Policy)\nX (Terms, Privacy Policy)\nSentry (Terms, Privacy Policy)\nRetool (Terms, Privacy Policy)\nBetterstack (Terms, Privacy Policy)\nLinear (Terms, Privacy Policy)\nFreshdesk (Terms, Privacy Policy)\n\n 7. Retention\nThe Services may retain the information we collect about you for as long as you maintain an account with the Service.\nTo request that information collected about you be deleted, please contact us at the email provided in this policy. A valid request must include sufficient information to identify your personal data. Note that we cannot delete information stored on public cryptographic blockchains.\n 8. Sharing\nThe Services only share information about you with others as follows:\n\nWe employ other companies to perform functions on our behalf, such as service providers that assist in the administration of the Services and our advertising and marketing efforts, identity verification services, data analytics companies that help us target our offerings, marketing partners, and payment providers. We may need to share your information with these companies. These partners may access this information so long as you have an account on the Services.\n\nWe may also transfer your personal data to a third party as a result of a business combination, merger, asset sale, reorganization, or similar transaction or to governmental authorities when we reasonably believe it is required by law or appropriate to respond to legal process.\n\nWe will also share your information with third-party companies, organizations, or individuals if we have a good faith belief that access, use, preservation, or disclosure of your information is reasonably necessary to detect or protect against fraud or security issues, enforce our Terms of Service, meet any enforceable government request, defend against legal claims or protect against harm our legal rights or safety. In any such event, and to the extent legally permitted, we will notify you and, if there are material changes in relation to the processing of your data, give you an opportunity to consent to such changes. Any third party with whom we share your data with will be required to provide the same or equal protection of such data as stated in our Privacy Policy.\n\nTo operate the Services, we share information about you as needed with our service providers, including financial institutions, accountants, auditors, lawyers, payment processors, information technology consultants, advisors, and our affiliates. We only share information to the extent it is required to fulfill our obligations to you and to regulators and to operate the Services. The information is only shared so long as you have an account on the Services.\n\nWe routinely share information with companies closely related to us – our \"affiliates\" – for certain purposes under this policy. Our affiliates will be entitled to enjoy our rights under this Privacy Policy and we will be responsible for our affiliates' conduct related thereto.\n\nWe may share information about you with US, state, or international regulators, SEC, or FINRA where we believe doing so is required or appropriate to comply with any laws, regulations or other legal processes or law enforcement requests, such as court orders, search warrants, or subpoenas.\n\nThe Services may contain links to third-party websites and may redirect you to third-party websites. These sites include, among others, service providers who have a relationship with the operator. Third-party websites are not under our control, and we are not responsible for any third-party websites, or the accuracy, sufficiency, correctness, reliability, veracity, completeness, or timeliness of their information, links, changes, or updates. The inclusion or access to these websites does not imply an endorsement by the operator, or of the provider of such content or services, or of any third-party website. Please be aware that when you enter a third-party website, any information you provide, including financial information, is subject to the Terms of Service and privacy policy of that website.\n\n 9. Opt-Out\nIf you wish to stop receiving marketing or promotional communications or to opt out of the use of your information for the purposes described in this policy, please follow the opt-out instructions, such as clicking \"Unsubscribe\" (or similar opt-out language), in those communications. You can also contact us at privacy@io.net to opt-out. Despite your indicated email preferences, we may send you service-related communications, including notices of any updates to our terms of service or this policy. Please understand that you will not be allowed to opt–out of certain communications required to comply with applicable laws, rules, and regulations or other legal and related notices concerning your relationship to the Services.\n 10. Security\nWe have put in place appropriate security measures to prevent your personal data from being accidentally lost, used, or accessed in an unauthorized way, altered, or disclosed. In addition, we limit access to your personal data to those employees, agents, contractors, and other third parties who have a business need to know. They will only process your personal data on our instructions and they are subject to a duty of confidentiality.\nWe have put in place procedures to deal with any suspected personal data breach and will notify you and any applicable regulator of a breach where we are legally required to do so.\n 11. Contact\nIf you have comments or questions about the privacy policies of the Services, contact privacy@io.net.\n 12. Changes\nThe Services may change their privacy policy at any time. Check this page for the latest.\n 13. CCPA Addendum – Compliance\nYou agree to do your respective parts to comply with the California Consumer Privacy Act and its regulations, consistent with the operator's role as a \"service provider\", and not as a \"third party\", under that law.\n 13.1. Cooperation\nWhenever it is feasible and legal to do so, both the operator and You will give the other prompt notice of user rights requests, regulatory inquiries, and other communications under the California Consumer Privacy Act. Both sides agree to cooperate in good faith to respond to and honor such communications, and to meet other obligations under the California Consumer Privacy Act.\n 13.2. Prohibitions\nThe operator may not:\n\nsell personal information collected from consumers covered by the California Consumer Privacy Act that You disclose to the operator\nretain, use, or disclose such information for any purpose other than for the specific purpose of performing the services in the Terms of Service, including retaining, using, or disclosing such information for a commercial purpose other than providing the services Terms of Service\nretain, use, or disclose such information outside of a direct business relationship between the operator and You\n\n 13.3. Certification\nThe operator understands the restrictions in Prohibitions and will comply with them.\n 13.4. Minimization\nBoth You and the operator agree to limit the use of personal information covered by the California Consumer Privacy Act to that reasonably necessary and proportionate to achieve the purpose of the Terms of Service, consistent with the meaning of \"business purpose\" under that law.\n 13.5. Subcontracting\nThe operator agrees to ensure that each subcontractor that processes Your information covered by the California Consumer Privacy Act will also qualify as a \"service provider\", and not as a \"third party\", under that law.\n 13.6. Personal Information\nOf the following categories of personal information:\n\nidentifiers (such as contact information, government IDs, cookies, etc.),\ninformation protected against security breaches (such as your name and financial account, driver's license, social security number, user name and password, health/medical information),\nprotected classification information (like race, gender, ethnicity, etc.),\nother information, including commercial information, Internet/electronic activity, geolocation, audio/video data, professional or employment-related information, education information, biometrics, and inferences from the foregoing;\n\n 13.7. Previously Submitted Information\nTo request access or changes to information previously submitted, please contact the operator at the address provided above (under the \"Contact\" heading).\n 13.8. Conflicts\nIf the terms of this addendum conflict with the terms of the Terms of Service or Privacy Policy, the terms of this addendum take precedence.\n 14. GDPR / EU Addendum\n 14.1. Transferring Your data outside of the EU\nThe data mentioned in this document will be stored in the United States. We use Amazon Web Service, which is based in the US. Amazon is certified under the EU-US Privacy Shield. Auth0 is a part of Okta INC., which is based in the US. Auth0 is certified under the EU-US Privacy Shield.\nBut, when interacting with the blockchain, as explained above in this Policy, the blockchain is a global decentralized public network and accordingly any personal data written onto the blockchain may be transferred and stored across the globe.\n 14.2. Your Rights as a Data Subject\nYou have certain rights under applicable legislation, and in particular under Regulation EU 2016/679 (General Data Protection Regulation or 'GDPR'). We explain these below. You can find out more about the GDPR and your rights by accessing the European Commission's website.\n 14.2.1. Right Information and access\nYou have a right to be informed about the processing of your personal data (and if you did not give it to us, information as to the source). This document provides that information, and you may contact us for additional information.\n 14.2.2. Right to rectification\nYou have the right to have any inaccurate personal information about you rectified and to have any incomplete personal information about you completed. You may also request that we restrict the processing of that information. The accuracy of your information is important to us. If you do not want us to use your Personal Information in the manner set out in this Privacy Policy, or need to advise us of any changes to your personal information, or would like any more information about the way in which we collect and use your Personal Information, please contact us at the above details.\n 14.2.3. Right to erasure (right to be 'forgotten')\nYou have the general right to request the erasure of your personal information in the following circumstances:\n\nthe personal information is no longer necessary for the purpose for which it was collected;\nyou withdraw your consent to consent-based processing and no other legal justification for processing applies;\nyou object to processing for direct marketing purposes;\nwe unlawfully processed your personal information; and\nerasure is required to comply with a legal obligation that applies to us.\n\nBut, when interacting with the blockchain we may not be able to ensure that your personal data is deleted. This is because the blockchain is a public decentralized network and blockchain technology does not generally allow for data to be deleted and your right to erasure may not be able to be fully enforced. In these circumstances we will only be able to ensure that all personal data that is held by us is permanently deleted.\nWe will proceed to comply with an erasure request without delay unless continued retention is necessary for:\n\nExercising the right of freedom of expression and information;\nComplying with a legal obligation under EU or other applicable law;\nThe performance of a task carried out in the public interest;\nArchiving purposes in the public interest, scientific or historical research purposes, or statistical purposes, under certain circumstances; and/or\nThe establishment, exercise, or defense of legal claims.\n\n 14.2.4. Right to restrict processing and right to object to processing\nYou have a right to restrict the processing of your personal information, such as where:\n\nyou contest the accuracy of the personal information;\nwhere processing is unlawful you may request, instead of requesting erasure, that we restrict the use of the unlawfully processed personal information;\nwe no longer need to process your personal information but need to retain your information for the establishment, exercise, or defense of legal claims.\n\nYou also have the right to object to the processing of your personal information under certain circumstances, such as where the processing is based on your consent and you withdraw that consent. This may impact the services we can provide and we will explain this to you if you decide to exercise this right.\nBut, when interacting with the blockchain, as it is a public decentralized network, we will likely not be able to prevent external parties from processing any personal data which has been written onto the blockchain. In these circumstances we will use our reasonable endeavors to ensure that all processing of personal data held by us is restricted, notwithstanding this, your right to restrict to processing may not be able to be fully enforced.\n 14.2.5. Contact\nService has a data protection officer or individual responsible for its data protection in the United States, EU, and UK that are collectively reached at privacy@io.net.\n 14.2.6. Right to data portability\nWhere the legal basis for our processing is your consent or the processing is necessary for the performance of a contract to which you are a party or in order to take steps at your request prior to entering into a contract, you have a right to receive the personal information you provided to us in a structured, commonly used and machine-readable format, or ask us to send it to another person.\n 14.2.7. Right to freedom from automated decision-making\nWe do not use automated decision-making, but where any automated decision-making takes place, you have the right in this case to express your point of view and to contest the decision, as well as request that decisions based on automated processing concerning you or significantly affecting you and based on your personal data are made by natural persons, not only by computers.\n 14.2.8. Right to object to direct marketing ('opting-out')\nYou have a choice about whether or not you wish to receive information from us. We will not contact you for marketing purposes unless:\n\nyou have a business relationship with us, and we rely on our legitimate interests as the lawful basis for processing (as described above)\nyou have otherwise given your prior consent (such as when you download one of our guides)\n\nYou can change your marketing preferences at any time by contacting us on the above details. On each and every marketing communication, we will always provide the option for you to exercise your right to object to the processing of your personal data for marketing purposes (known as 'opting-out') by clicking on the 'unsubscribe' button on our marketing emails or choosing a similar opt-out option on any forms we use to collect your data. You may also opt-out at any time by contacting us at the below details.\nPlease note that any administrative or service-related communications (to offer our services, or notify you of an update to this Privacy Policy or applicable terms of business, etc.) will solely be directed at our clients or business partners, and such communications generally do not offer an option to unsubscribe as they are necessary to provide the services requested. Therefore, please be aware that your ability to opt-out from receiving marketing and promotional materials does not change our right to contact you regarding your use of our Services or as part of a contractual relationship we may have with you.\n 14.2.9. Right to request access\nYou also have a right to access the information we hold about you. We are happy to provide you with details of your Personal Information that we hold or process. To protect your personal information, we follow set storage and disclosure procedures, which mean that we will require proof of identity from you prior to disclosing such information. You can exercise this right at any time by contacting us on the above details.\n 14.2.10. Right to withdraw consent\nWhere the legal basis for processing your personal information is your consent, you have the right to withdraw that consent at any time by contacting us on the above details.\n 14.2.11. Raising a complaint about how we have handled your personal data\nIf you wish to raise a complaint on how we have handled your personal data, you can contact us as set out above and we will then investigate the matter.\n 14.2.12. How to contact the appropriate authority\nShould you wish to report a complaint or if you feel that we have not addressed your concern in a satisfactory manner, you may contact the Information Commissioner's Office in your jurisdiction.1. About this Privacy Policy\n2. The Blockchain\n3. Children and minors\n4. Collecting\n4.1. Things you and others do and provide.\n4.2. Cookies\n4.3. Device Information\n4.4. When using the Services\n5. Tracking and Uses\n5.1. Provide, personalize, and improve our Services.\n5.2. Provide measurement, analytics, and other business services.\n5.3. Promote safety, integrity, and security.\n5.4. Communicate with you.\n6. Third-Party Data Collection\n7. Retention\n8. Sharing\n9. Opt-Out\n10. Security\n11. Contact\n12. Changes\n13. CCPA Addendum – Compliance\n13.1. Cooperation\n13.2. Prohibitions\n13.3. Certification\n13.4. Minimization\n13.5. Subcontracting\n13.6. Personal Information\n13.7. Previously Submitted Information\n13.8. Conflicts\n14. GDPR / EU Addendum\n14.1. Transferring Your data outside of the EU\n14.2. Your Rights as a Data Subject\n14.2.1. Right Information and access\n14.2.2. Right to rectification\n14.2.3. Right to erasure (right to be 'forgotten')\n14.2.4. Right to restrict processing and right to object to processing\n14.2.5. Contact\n14.2.6. Right to data portability\n14.2.7. Right to freedom from automated decision-making\n14.2.8. Right to object to direct marketing ('opting-out')\n14.2.9. Right to request access\n14.2.10. Right to withdraw consent\n14.2.11. Raising a complaint about how we have handled your personal data\n14.2.12. How to contact the appropriate authority","tokens":7260,"squid":"ink-crypto_ai_depin","role":"Compute Scout","at":1791268494677,"hash":"14a4203e60b4d3bdf79503cd49d2ad319a4585e9"}